V podcastu IPv6 Buzz se v podslední 55. epizodě rozmluvil Geoff Huston z Regionálního Internetového Registru (RIR) APNIC na téma The Good, Bad, And Ugly Of IPv6, což by se dalo přeložit jako „Co je dobré, špatné a ošklivé na IPv6“, protože doslovný český název odkazovaného kultovního westernu Hodný, zlý a ošklivý se do nadpisu jako překlad úplně nehodí.
Tradiční propagátor se do IPv6 tak opřel, že přednáška Radka Zajíce z roku 2019 Co je špatně na IPv6 ve srovnání vyznívá skoro až nadšeně. Kritika Geoffa Hustona se zakládá na pozorování, že rozšiřující hlavičky fragmentace asi ve 20 % případů způsobí zahození paketu na cestě, ale informace o zahození se často nemůže dostat k odesílateli.
Nedoručení Packet Too Big je způsobeno několika skutečnostmi a obyčejně je to mix politiky poskytovatele neodesílat na určitých zařízeních ICMP. Ať už z bezpečnostních důvodů nebo protože generování ICMP zpráv se realizuje softwarově a je tedy z hlediska výpočetního výkonu nákladné. Druhým důvodem může být to, že je zpětná cesta vedena asymetricky úplně jinudy a router na ni nemá přístup.
Pakety s rozšiřující hlavičkou jsou na zpracování v hardwaru poměrně nevhodné resp. náročné, možná se tedy posílají do tzv. slow path, ke softwarovému zpracování a proto je některé, v ten moment možná přetížené, síťové prvky nejspíše zahazují.
Problémy s fragmentací potom způsobují, že v IPv6 je problém doručit správně UDP pakety velikosti nad 1280 bytů (minimální MTU u IPv6), což je často případ např. DNS odpovědí podepsaných DNSSEC. Geoff Huston o tomto tématu přednáší přinejmenším od roku 2017, např. IPv6, the DNS and Big Packets a The Internet Protocol Journal (duben 2018). Problém je, že tento fakt se nedá jednoduše obejít. Potřebné změny v tak základní součásti IPv6, jako je přístup k fragmentaci je prakticky nerealizovatelný. Přejít s DNS na TCP by řádově zvýšilo náklady na provoz DNS serverů.
Další kritika je více fundamentální. Pro pochopení argumentace je potřeba mít povědomí o několika faktech. V IPv6 byla myšlenka 128bitový prostor IPv6 adresy dělit na dvě 64bitové poloviny, kdy první polovina měla poskytovat lokátor a druhá identitu (mj. viz poslední odstavec před 5.4 Multi-homing: Identity Protocol Element (RFC4177, rok 2005). Toto dělení v praxi není aktuální, část myšlenky je ale stále očividná i v moderním dělení na globální směrovací prefix (obyčejně 48 bitů), identifikátor podsítě (16 bitů) a identifikátor rozhraní (posledních 64 bitů) podle knihy IPv6 – Čtvrté vydání Pavla Satrapy z roku 2019, strana 71.
Posledních 64 bitů využíváme i kvůli ochraně soukromí jinak resp. jen velmi omezeně z hlediska efektivity. Většina sítí by si bohatě vystačila i s 32 nebo 48 bity pro identifikátor rozhraní, poslední by dobře korelovalo s MAC adresou, kterou některá zařízení stejně generují v určitých případech náhodně. Současně jsme kvůli NATu pro praktické účely v současné architektuře internetu, podobající se více modelu client-server než tzv. peer-to-peer síti, získali zhruba dalších 20 bitů díky využití několika bitů ze zdrojového a cílového portu v UDP a TCP hlavičkách.
Konzervativní odhad je, že se adresní prostor IPv4 pro většinu účelů efektivně rozšířil na 48–53 bitů. Zároveň se s NATem odpovědnost za komunikaci převedla ještě více na provozovatele datacenter a CDN, kdy běžný klient díky regionální replikaci dat pomocí triků s DNS a anycastem komunikuje jen s malým výřezem celkové infrastruktury. Velké firmy typu Facebook, Amazon, Apple, Netflix a Google (FAANG) přitom NAT tolik nebolí, protože přinejmenším v jádru sítě mají plnou kontrolu nad veškerou technologií a mají možnost zajistit si dostatek IPv4 adres pro komunikaci s vnějším světem. Zároveň rozdáváme prefixy /48 i firmám o pár zaměstnancích, kterých by se několik mohlo schovat za jednu veřejnou IPv4 adresu. Tam už prý tedy najednou rozdíl mezi IPv4 a IPv6 není tak drastický. Geoff Huston toto téma popisuje detailněji ve článku In Defence of NATs na straně 29 listopadového vydání The Internet Protocol Journal z roku 2017.
Zbylá kritika se vztahovala na dynamické příděly prefixů od poskytovatelů internetu podobně jako tradičně přidělují dynamicky veřejné IPv4. U IPv4 je díky NATu přečíslování prakticky nepozorovatelné, u IPv6 má změna prefixu prý větší důsledky.
Můj názor je, že s fragmentací jistě problémy jsou, ale v době, kdy stejně DNS informace zabezpečujeme i pomocí DNS over TLS a DNS over HTTPS mi argumentace s náročností DNS přes TCP přijde trochu úsměvná. Ano, DNS obsahuje i jiné informace, které je jistě dobré podepsat, např. záznam SSHFP pro otisky SSH klíčů, TLSA pro DANE apod. a potom na tyto účely nepotřebujeme drahé spojení pomocí TLS.
Postřehy Geoffa Hustona k NATu mi přijdou trochu mimo, protože se mi zdá, že plete víc věcí dohromady a realita je jiná. Fakt je, že pokud chcete, aby se někdo připojoval k vám napřímo, tak ve světě IPv4 je jediná možnost získat jednu ze zhruba 3 miliard platných IPv4 adres a své služby na této adrese vystavit. Možná vzniknou služby, které vám umožní vystavit třeba i jen konkrétní port a za každý další bude podle poptávky požadována platba. TCP port 443 v takové šedivé budoucnosti bude asi hodnocený dráž, než port 25.
Běžné firmy ale IPv4 veřejné adresy v omezené míře potřebují, protože přes tyto přistupují např. obchodní zástupci a správci industriálních zařízení pomocí VPN do sítě. Faktem je, že možnosti sdílení IPv4 na straně serveru jsou dost omezené. Přirozeně tedy většina adres nakonec skončí jako „serverové“ a jen minimum adres budou nějaké obří (CG)NAT brány. Částečně tomuto vývoji možná uleví nasazení HTTP/3, resp. QUIC na bázi UDP, protože se část TCP provozu přelije tam, to je ale pořád maximálně faktor 2×, co ještě lze dost reálně vydolovat bez většího omezení kvality služby běžného klientského připojení za NATem.
Naproti tomu IANA přiděluje IPv6 globální unicastové adresy z prefixu délky /3 jednotlivým RIRům. Evropský RIPE NCC jeden příděl délky /12 již spotřeboval.
Z jednoho prefixu /12 je možné obsloužit ca. milion menších poskytovatelů s přídělem /32, 64 miliard firem většinou menší velikosti se standardním přídělem /48 nebo ještě 256× tolik koncových spotřebitelů, když uvažujeme příděl velikosti /56, což je ~16 bilionů. Jak je tedy možné, že jsme v Evropě už jeden prefix rozdali? Ne všechno je při adresování efektivní, dokonce se od přílišné efektivity odrazuje. To je mj. proto, že je jednodušší firmě dát příděl takový, aby reálně neměla potřebu si říkat v dohledné době o větší. Tím je tedy pro většinu podniků téma adres vyřešených.
Podniky, které mají více poskytovatelů mají na IPv6 o něco více práce situaci řešit (např. pomocí tzv. Provider Independent adres nebo delegaci problémů s redundantním připojením na jednoho poskytovatele korporátní sítě, který na pozadí pronajímá linky více poskytovatelů ale z hlediska adres terminuje připojení z typicky MPLS sítě sám, pro domácí sítě Radek Zajíc a jiní mají taky sbírku triků, jak tento problém řešit).
Myslím, že Geoff Huston je vlastně spíš mrzutý, že nasazení IPv6 trvá tak dlouho a správně upozorňuje na opravdové problémy této technologie. Taky je fakt, že bez NATu bychom za posledních 20 let internet nerozšířili a nekonzumovali tak rychle. Realita ale je, že nedostatek IPv4 skutečným firmám a o něco méně hmatatelně i jedincům znepříjemňuje život i když to jsou vlastně jen hloupá čísla. Nic není ideální a IPv6 je ideálu rozhodně vzdáleno, je to ale v mnoha ohledech funkční a udržitelnější řešení než IPv4. Buďme tedy opatrní a řešme problémy, ale ukončeme prosím už to divadlo s IPv4!
ČLÁNKY DO MAILU