Hlavní navigace

Co je dobré, špatné a ošklivé na IPv6, vysvětluje Geoff Huston

13. 7. 2020

Sdílet

Ethernet IPv6 only Autor: Pixabay

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!

Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 13. 7. 2020 12:39

    Libor Peltan

    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á

    Tak se přestaňte usmívat a nejdřív si něco zjistěte. DoT a DoH jsou dosud naprosto marginální záležitostí, a hlavně se týkají komunikace jednotlivých uživatelů s DNS resolvery. Ale ty problémy s DNSSEC-over-UDP jsou hlavně mezi resolvery a autoritativními servery, kde je to výkonově největší maso.

  • 13. 7. 2020 13:44

    Adam Kalisz

    To jste mi to nandal. :-) U DoH se pokud vím komunikuje na rozdíl od tradičního DNS rovnou s resolverem někde u Cloudflare, Google apod. a krok lokálního síťového resolveru se přeskakuje. Cílové resolvery velkých společností tento problém samozřejmě budou dál muset nějak řešit, ale možná tam už hraje větší roli caching a taky latence k root a autoritativním serverům bude možná nižší, čímž se zase hlavně u TCP sníží náročnost. Možná je tedy náročnost DoH Cloudflare, Google apod. jedno resp. se jim to nějak vyplatí? Předpokládám, že jinak by to tak vehementně netlačili.

    Já neříkám, že je to blbost nebo že nemá Geoff Huston pravdu (jinak bych o tom asi nepsal článek), jenom říkám, že tady jsou určité konflikty ve směru vývoje IETF, kde se čím dál více dbá na nějakou formu TLS a DNS možná i s ohledem na IPv6 a problematice náročnosti toho všeho v praxi. Nebo mi chcete tvrdit, že v IETF neví, co dělají?

    Nakonec jistě můžete prezentovat Vaše data k té náročnosti nebo třeba nabídnout řešení fragmentace na IPv6 při použití UDP a DNSSEC přímo v DNS resolveru nebo autoritativním serveru.

    Jedno možné řešení vidím třeba v tom, snížit MTU na 1400 nebo dokonce 1280 bytů při použití IPv6. Tak to dočasně řešil např. zmíněný Cloudflare: https://blog.cloudflare.com/increasing-ipv6-mtu/. Hlavně pro zákazníky UPC/ Vodafone by mohl být zajímavý nástroj a návod na zjištění MTU mezi Cloudflare a klientem: http://icmpcheckv6.popcount.org/ Více k těmto testům je taky napsáno na blogu Cloudflare: https://blog.cloudflare.com/ip-fragmentation-is-broken/
    Ano, snižování MTU asi nezlepší výkon, ale pořád to je UDP a ne TCP... Jedno řešení by také mohlo být neodesílat tak velké DNS odpovědi, třeba využitím ECDSA a jiných algoritmů než RSA v DNSSECu. Rozhodně je to celé zajímavé téma a zase jeden příklad toho, jak je prakticky každá technologie v praxi do nějaké míry rozbitá.

  • 13. 7. 2020 16:12

    bez přezdívky

    DoH má jediný důvod, získat uživatelské metriky, aniž by používali něco tak okatého jako cookies (a neposkytnout je ISP). A celé to schovat za "lepší soukromí".
    Z tohoto pohledu je investice Googlu do open DNS, stejně jako do DoH velmi dobrý tah. DNS query víceméně mapují celý váš pohyb na internetu, minimálně tedy tu komerčně zajímavou část. Kombinace vlastního prohlížeče a vlastního DNS resolveru efektivně prodlužuje Google CDN až ke klientovi. Google je v tomto ovšem extrém, CloudFlare takové možnosti nemá. Zatím.
    DoT je možná, podle toho komu věříte více, lepší cesta co se týče soukromí, ale ostaní problémy jsou stejné, příliš velký paket, nutná fragmentace, overhead TCP spojeni => latence DNS query a opticky pomalý internet.
    HTTPs over QUIC, nebo redukce objemu dat v UDP paketu může řešit problém s overheadem, ale problém s předstíráním soukromí to nevyřeší ani omylem. Vždycky to nakonec spadne na rozhodování, kterému pošťákovi svěříte svůj nezalepený dopis, tedy, DNS query.
    A mimochodem, myslím že Geoff Houston opravdu nemá valné mínění o IETF, jeho kritika je na jeho blogu více než kousavá Measuring IPv6.

    13. 7. 2020, 16:14 editováno autorem komentáře

  • 17. 7. 2020 0:29

    SB

    Sice netuším, co je pan Huston zač (a ani mě to nezajímá), ale takovou horu sraček, co z něj vypadla, nemá smysl ani komentovat. Potřebuje-li se za každou cenu zviditelnit, měl by si najít jiné téma.

Byl pro vás článek přínosný?

Autor zprávičky