Vlákno názorů k článku Proč 18 trilionů adres domácnosti nestačí od Jenda - > Existují sice aplikace, kdy je přidělení jednoho...
-
Jenda (neregistrovaný)
> Existují sice aplikace, kdy je přidělení jednoho síťového prefixu /64 ospravedlnitelné (například mobilní sítě, ve kterých každý připojený telefon obdrží svůj /64 prefix)
Tethering? (pokud tím myslíš přímo prefix a ne adresu na rozhraní k operátorovi + prefix na wifi)
Jinak bylo by možné uvést nějaké příklady nasazení, kde je výhodné to rozdělení 64:64 oproti třeba 80:48 (když se pro SLAAC používá typicky EUI48) nebo ještě menšímu?
-
Ad příklady nasazení, kde je výhodné 64:64 - no já jich vlastně asi moc nemám. Kdysi některé routery (Cisco?) prý při routování v hardwaru braly v potaz jen horních 64 bitů, což by jim brutálně snížilo výkon v případě nasazení jiných prefixů než /0 až /64
LAN by určitě fungovaly s jiným rozsahem než /64 (menším i větším) - a některé implementace SLAAC to podporují. Jenže ne všechny - a v tom je ten kámen úrazu. Pokud nemám vyhrazenou síť s plnou kontrolou nad nasazeným HW/SW, na kterém zároveň funguje jiná velikost než /64, tak se mi SLAAC bude na klientech rozbíjet/nefungovat. A to přirozeně nechci.
Ad tethering a mobilní sítě: to je kapitola sama pro sebe. IPv6 v mobilních sítích už od počátku počítá s tím, že mezi mobilem a jádrem sítě bude síť nesdílená s jinými zařízeními; jádro sítě přidělí telefonu /64 a telefon si s prefixem může dělat, co uzná za vhodné. Jádro sítě posílá všechen traffic směrem do telefonu a samo adresy z toho prefixu nevyužívá. Časem některé implementace postoupily do fáze, že posílají směrem do telefonu traffic jen pro IPv6 adresy, které se objevily ve směru zevnitř ven - tím se zabrání zahlcení mobilní sítě např. při DDoS útoku na náhodné adresy z /64 subnetu.
Telefon pak může prefix (nebo jeho menší část, klidně /128) přiřadit na jakýkoli interface - toho se ostatně využívá při tetheringu (prefix se přiřadí na rozhraní směrem do "LAN") a při 464XLATu (CLAT démon přijímá/odesílá data na/z adresy, kterou si sám vymyslí, ale je z onoho přiděleného /64 prefixu).
Pro případy, kdy má mobilní terminál vystupovat jako router, pak je v 3GPP release 10 definován mechanismus, jak si požádat o další adresy pro LAN. Nepřekvapivě je to pomocí delegace prefixu v DHCPv6. :-) A pak samozřejmě záleží na operátorovi, jak velký prefix terminálu v DHCPv6 PD přidělí.
Oproti pevným sítím je ale v 3GPP pevně stanoveno, že prefix pro spojení s jádrem sítě a prefix pro LAN musí být agregován do jednoho většího prefixu. Mobilní síť, která podporuje DHCPv6 PD, tak musí mít pro každého klienta, kterému umožní delegaci prefixu, vyhrazen prefix o velikosti alespoň /63 (z něj se jeden použije pro spoj s jádrem sítě a jeden pro LAN, takže zase žádná výhra). Lepší design samozřejmě počítá s tím, že síť přidělí např. /56, z které se použije jeden /64 pro spoj s jádrem sítě a zbytek bude k dispozici uživateli. Přirozeně se nabízí využití /64 pro (každou) LAN, ale i podpora subdelegace /60 podřízeným routerům.
(Detaily k tomuto najde laskavý čtenář např. na https://tools.ietf.org/html/rfc7066#page-10) -
Jenda (neregistrovaný)
> Ad příklady nasazení, kde je výhodné 64:64 - no já jich vlastně asi moc nemám.
No právě. Mě to přijde jako dost špatné rozhodnutí při návrhu, které nepřináší žádné výhody. Kromě nafukování adresního prostoru bychom měli předpokládat že stoupne i hloubka zanoření sítí a umožnit to. Na IPv4 má teď ISP až 24 bitů, které může použít na rozdělení své sítě (10.0.0.0/8, zákazník má druhý NAT (ano, děje se)). Na IPv6 dostane takový ISP třeba /32 a když chce zákazníkům dávat /56, tak má 24 bitů volnosti… zase.
Navíc mě trochu děsí, že jak je zmíněno v článku nějaký ISP dostane /19 - to znamená, že takových ISP může být na světě 260 tisíc (za předpokladu využití poloviny adresního prostoru pro unikátní adresy), což je sice hodně, ale už to není nijak astronomické číslo.
Abychom za 40 let neřešili přechod „ze zařízení která umí masku /64 na zařízení která umí /96“…
-
Abys dostal /19, musíš svou žádost náležitě zdůvodnit. Například počtem existujících zákazníků. Podle zprávy o účetním roce 2017 (https://www.telekom.com/resource/blob/512798/3accce9a6968ba72b7bc3b63ffa31e02/dl-180222-q4-17-pdf-data.pdf str. 50) mají v Německu (kam ten příděl patří) 41,8 mio mobilních zákazníků a 12,9 fixních datových přípojek. 260 tisíc poskytovatelů s 13 mio fixními přípojkami. Pokud bych vzal 260k takových poskytovatelů, museli by mít 3 354 mld. fixních přípojek - na každého obyvatele planety ~445. To jen tak nevyčerpáme. :-)
A kdyby jo, tak prostě IANA otevře 4000::/3 a bude zase místa dost. -
Jenda (neregistrovaný)
> Proč sem píšou lidi, co neznají 4ku ani 6ku?
Tak jako nějaký guru na sítě nejsem, ale doufám, že jsem za těch pár let adminování něco pochytil…
> 10.0.0.0/8, 172.16.0.0/12 a 192.168.0.0./16 je "private use" a před routerem zákazníka nemá co dělat. Nikdy a za žádných okolnotí.
Ano, podle RFC ne. A teď vyjdi ven a rozhlídni se. Btw. tohle je relativně nové, dost těch sítí vznikalo před tím když bylo platné jenom RFC 1918 a nikomu se už nechce přečíslovávat.
-
Petr M (neregistrovaný)
Já jo.
1. Routery.
Pokud vím, že v dolních 64b není nic, co by router zajímalo, tak to nemusí řešit. Odpadne kus paměti (kdybys routoval /80, potřebuješ 80b RAM pro routovací tabulky, takhle vystačíš s 64b). Navíc stačí menší a jednodušší FPGAčko,... Obdobně BGPčko když ví, že AS má min. /32, tak mu stačí v routovací tabulce kulatých 32b.2. Koncový zařízení - výkon a paměti.
S 64:64 to stačí vytvořit adresu takhle:
MOV R0, prefix
MOV @ip_hi, R0
MOV R0, adr_podsite
MOV @ip_lo, R0
Kdežto s 80:48 by to už bylo
MOV R0, prefix_hi
MOV @ip_hi, R0
MOV R0, prefix_lo
MOV R1, adr_podsite
MOV R2, #000000000000ffffh
AND R1,R2
NOT R2
AND R0,R2
OR R0, R1
MOV @ip_lo, R0
pro 64b CPU. Variabilní délka je ještě horší, tam musíš navíc pomocí shiftování vytvářet masku v R2 za běhu, potřebuješ na prefix 16B místo 8B,...3. Management sítě
Víš, že /64 je jedna síť a s tím můžeš pracovat. Máš jistotu, že třeba blokováním toho prefixu nezařízneš nějaký "CGNAT" u potroublýho ISP, který přiděluje /96 koncákům.
4. Zjednodušení autokonfiguračních protokolů.
Ty "krabičky za 300" nemusí řešit délku prefixu v koncové síti.
-
... (neregistrovaný)
Tak a teď se podívejte do reálné routovaci tabulky. Jsou tam /29, /31, /32, /36, /47, /48 i /127. Tech 16 bajtů v TCAM pro jeden v6 záznam prostě mít musíte, ať chcete nebo nechcete, protože prostě může přijít prefix s libovolnou délkou adresy (klidně i /1, když se někdo rozhodne rozdělit ::/0 na dvě půlky) a zařízení se s tím prostě musí vypořádat.
Ta vaše superoptimalizace vypadá na papíře hezky, ale takových teorií, co na papíře vypadají hezky, už tu bylo.
-
... (neregistrovaný)
“pokud toho není moc, stihne to vyřídit CPU“
To jsem rad, ze nenavrhujete routery. Dichotomie routingu HW/SW jednak zvysuje komplexitu kodu a tim i sanci, ze to bude zabugovane. Dale je ten router nepredikovatelny — nikdy nevite predem, jakou ma realnou kapacitu. Kazdy, kdo ma zkusenost s tim, co provadely Cat6500 pri prepnuti do sw routingu, zajiste potvrdi, ze to byla vazne chutovka. To uz je lepsi, kdyz definitivne spadne.
No a vy samozrejme predem nevite, kolik toho bude, cili musite pocitat s nejhorsim, tj. plnymi porty 64B packetu. Prostudujte si pro zacatek RFC1925 chapter 4 a chapter 8, pak se nad tim hluboce zamyslete a pak ma mozna smysl se bavit dal.
