Vlákno názorů k článku Tak jsme na suchu! od Ray - Zdar a sílu, nemám zájem rozpoutávat flame, nicméně, jako...

Zdar a sílu,

nemám zájem rozpoutávat flame, nicméně, jako člověk, kterej implementoval v4 a v6 stacky mám silnej pocit, že IPv6 je fail právě pro překombinovanost a složitost implementace. Kdyby pánové a organizace, co to tvořili, nebyly zhulení a nesnažili se každej prosadit "něco svého" (často i snad jen proto aby tam od nich něco bylo), věřím, že by v6ka už dávno okolo byla. V embeded oblasti, kde neběží "kernel" (bsd,linux, ...) a počítá se každej Kb RAM nebo fleše, je to neuvěřitelnej rozdíl. A tím nemyslím to, že je adresa o něco málo větší. Množství "věcí" ktere se musí implementovat a nakolik jsou sami rozsáhlé, aby to jelo.

Nemám nic proti změnám a novím věcem :) Jen musí mít hlavu a patu. IPV6ka je někde na úrovni snahy ekologů vyřešit spotřebu a ruť tím, že zakážou klasické žárovky.... To tu ale každej určitě ví, jak totok funguje.

To je myslím zcela základní důvod failu ipV6ky, jíž jsme svědky. A že to fail je, je zjevné. Kolik by asi bylo procent domén, kdyby se nepředělali na základě automatizovaného robota a web hostingů ?

Časem nezbude nic jiného, to je bohužel pravda. A tak nám nezbyde, než kočkopsa ipV6 mít všude...

Chápu, že lidi z NICu a podobní, jejiž rozlišovací schopnost v6ky končí na úrovni kabelu (nemysleno špatně, pouze kosntatování, že na věci koukají z jiného úhlu) určitě nebudou souhlasit. Přece to tak krásně funguje. Jenže za tím funguje, je nechutně překombinovanej kočkopes.

Ale ty množsštví energie navíc, ve formně instrukcí, tepla a flesh buňěk, která se kvůlu 6ce bude muset vyzářit a posléze ochadit, se někde vyrobit musí. A nějaka elektrárna navíc to bude :)

Škoda, že místo jednoduché věci, jakou v4ka je, udělali překombinovaného kočkopsa, který "umí věchno" a tím z velké části zabili jeho nástup... Ne každej je happu s tím, že "linux kernel to umí".

Proto nemám rád IPV6. A nikdy nebudu.

Vývoj jde od věcí primitivních přez složité k jednoduchým. 6ka bohužel tto rčení přesně reflektuje...

Můj názor, nic víc :) A nechci rozpoutávat flame a dohadovat se, která featura je taková nebo maková a že je vlastně skvělá. Protože vždy záleřží "jak pro koho". Pro správce sítaře to bude rozhodně něco jiného, než pro někoho, kdo počítá spotřebu na desetiny watu.

R.

Nejake konkretnejsi argumenty by nebyly? (Napr. ktera featura konkretne zvysuje naklady co do prikonu ci narocnosti implementace.) AFAIK je tam naopak docela dost veci, ktere to zjednodusuji (zruseni fragmentace na routerech ci zruseni potreby prepocitavat konktrolni soucet pri forwardingu).

Co do narocnosti implementace jednoznacne zvysuje naklady nutnost znovu implementovat ARP, ktery se jen jmenuje NDP, ma nekolikanasobne vic podminek a okrajovych pripadu, se kterymi se MUSI pocitat (RFC4861) a oproti ARP neprinasi nic noveho. ICMPv6 jako "formalizace nekolika starych protokolu do jednoho" je teoreticky pekny napad, ale sam jiste vis, ze implementace rozhodne stejne slozite nejsou.
Na co potrebujeme 24 strankove RFC 3484 (default address selection)? Na co potrebujeme vynucovat v krajnich pripadech link-local adresy, takze kdyz je nepouziju jako gateway, nektere nahodne featury (napr. ICMPv6 Redirect) prestanou fungovat? Na co potrebujeme svetu diktovat jakym zpusobem si ma generovat adresy? Proc vlastne DHCPv6 a RA nemaji od zacatku stejne opsny pro zjednoduseni implementace? A proc vlastne nemuze RA podporovat generovani mensich adres nez 64 bitu? (ne, alignment tady fakt nehraje roli, adresu generujeme jednou za pet minut a zamaskovat pul adresy nas fakt nezabije, navic mame DAD a ani trefit se dvakrat stejne do 2^32 neni tak lehke)

Proc je SeND patentovane a neni to volitelna soucast IPsec? Proc se vubec nekolik let resilo jestli AAAA nebo A6? Proc je tolik prechodovych mechanismu a NAT64 implementace pokud vim jen jedna?

Prepocitavani checksumu, "variabilni" hlavicky co nejsou zase tak variabilni, konecne reseni fragmentace, anycast "v zakladu" -- tyhle featury jsou sice fajn (s tou fragmentaci jim to teda trvalo, diky F. Gonte!), ale zdaleka to nevyvazi ten bordel, ktery vznikl praci ve stylu "jenom to prepiseme do uhledne formy... a tohle by chtelo zmenit". IPsec se taky docela povedl, ale je malo jednoduchych implementaci, takze se nerozsiril. Hlavni problemy do budoucnosti, mobilita a rust routovacich tabulek, jsou ponechany "for further study". Takhle se da pokracovat dal a dal...

IPv6 je "fail" hlavne proto, ze blbci jsou dvou typu. Jedni {neumi|nechte­ji|odmitaji racionalne} navrhnout protokol a druzi se vymlouvaji, ze se jim neco nelibi a tedy to nebudou pouzivat. Takze na jedne strane mame desitky naprosto zbytecnych, komplikovanych a casto nedostatecne otestovanych RFC, ktere tu druhou stranu absolutne nezajimaji, protoze to pro ni "je zlo" ;-)

Jen dopním pár věcí, co řekl kolega, protože se nezbvývá, než pod to podepsat... Další ztěžující věc jsou různá rozhraní (z hlediska adres), které jsou navěšené na jedno (třebas místní linky při autokonfiguraci). 1 rozhraní tak nakonec může komunikovat s větším množstvím měnících se adres (rostou nároky na pamět, ARP tabulky, ...).

Fragmentování ? To jsem ještě nikdy neřešil, pakety s fragmentem zásadně zahazuju (není RAM kam si to uložit a čekat) a zatím jsem nikdy nenarazil na situaci, kdy by to zpusobovalo problém. Ona většina zařízení s fragmentovanejma paketama stejně dělat neumí a na směrovaších ISP se obvykle zahazujou. Takže opět něco, co se vyřešilo samo historicky tím, že HW překonal nutnost cokoliv fragmentovat. Zkus si poslat fragmentovanej paket z jednoho konce světa na druhej... Došel ? :)

Nepřítomnost součtu, že něco zjednodušuje ? Přepočítat kontrolni součet neni problém a to, že ho odebrali, je dle mého názoru, taky chybou. Ne všude pakety jedou po ETH, ne každý protokol, kterým se tuneluje je málochybový. Ne všechny kabely jsou duělné jak by měli, sem tam se vyskytují i v provoze a zarušených oblastech... A tam fakt chyba není něco, na co by se muselo čekat dlouho... Stačilo ho definovat rozumně, nikoliv jako ve V4, kde se vytváří virtuální hlavičky, je jich tam několik atp.... Tak či tak, tohle v podstatě není zjednodušení, protože při tunelování se musí přidat "vrstva" navíc. To teď stačilo prohnat paket kudy člověk potřeboval a nemusel řešit nějak spešl CRC. Určitej význam to má když se implementují věci na úrovni FPGA, což se týká lepších swtichů. Tam pro změnu ale mají FPGA takovej hrubej výkon, že to CRC už zase moc nemění. Stejně tam CRC jednotka pro V4 být musí, leda že by to byl V6 only HW.

Potom fine věci, jako že do stejné skupiny patří 2 rozhraní, jedno WAN a druhé LAN. To všechno zesložiťuje logiku "routování" paketů. Je sice krásné, že zákazníkovi přidělí operátor 1 subnetu a on pro WAN použije rovnou tu subnetu stejně jako pro LAN, nicméně... Proč ? Pak s takovo hovadinou musí počítat každé zařízení. Notabene, operátor stejně musí vědět kam naroutovat daný rozsah, takže se ani nakonec neuštetří ani záznam v routovacích tabulkách. Pouze nebude "transportní" subneta.

Pak namátkou zónové rejstříky, nejednoznačnost routování dle samotných RFC, kvůli kterým se pak píšou další RFC (2462 a 4007). Ono celkově ta autokonfigurace je lahůdka.

Nebo další drobnůstka, routing hlavičky. Ve V4 se fakt neosvědčili a sloužili akorát k útokům, takže ve V6 se udělali také aby je pak s velkou slávou zrušili (5095). Tak at mi nikdo neříká, že nebyli zhulení :)

Identifikace toku (flow label). Krásná myšlenka, která by fungovala v dokonalém světě... Jenže, realita je jiná. Dodnes je to nevyužívaná položka a nejspíše zůstatne, protože jak by mol hraniční směrovač věřit této položce, když útočník tam může strčit co bude chtít a dostat se tam kam nemá? Do sitě bych si nedal zařízení, které by této položce důvěřovaloa nedalo se to vypnout. Radší ať si udělá lokální cache, když už nemá výkon na to, aby při každém paketu prozkoumala "kam s ním".

Jak říkám, pro někoho to můžou být úžasný featury, pro mně jsou tyto věci V6 killery.

Kdyby se z V6ky nesnažili udělat kočkopsa co má v sobě všechno, definovaly rozumej základ funkčnosti a zbytek nechali na "protokolech" (v obecné rovině), věřím tomu, že by dneska V6 adresu měl kde kdo. IpSec je součástí hlaviček, bla bla bla...

Náklady, které stoji implementace V6 zabíjí jeji rozšiření a ještě pěkných pár let bude. Náklady zbytečné... Bude jednodušší (čti: levnější) obchodovat s adresama, kterých je více než dostatek alokován mezi členy RIPE... Až skutečně někomu začnou odebírat nevyužívaný vě větší míře, pak můžeme teprve začít říkat, že nám dochází adresy. Do té doby je to čistě akademická debata.... Nám se také vyplatí stavět V4kovou síť a tunelovat, než překopávat tisíce zařízení na V6ku...

Je to jak poměřování pindíků u piva... Dřív se poměřovali pindíci, potom mobili a dneska délka IP adresy :)

R.

> Další ztěžující věc jsou různá rozhraní (z hlediska adres), které jsou navěšené na jedno (třebas místní linky při autokonfiguraci). 1 rozhraní tak nakonec může komunikovat s větším množstvím měnících se adres (rostou nároky na pamět, ARP tabulky, ...).

Nejsem si jist, ze rozumim co mas na mysli, ale pokud tim myslis proste vic IP prefixu na jednom sitovem rozhrani, tak to je featura, ktera puvodne v IPv4 nebyla, ale je natolik potrebna, ze ji dneska (pro IPv4) stejne umeji skoro vsichni, ale proto, ze puvodne nebyla ve standardu, tak mohou byt potize s kompatibilitou (napr. v OSPFv2, kde rozumne chovani pri vice IP na rozhrani snad nikdo nedefinuje). Proto je vcelku rozumne, ze pri navrhu IPv6 to tam rovnou dali.

> Fragmentování ? To jsem ještě nikdy neřešil, pakety s fragmentem zásadně zahazuju. .. Takže opět něco, co se vyřešilo samo historicky tím, že HW překonal nutnost cokoliv fragmentovat.

Problem s fragmenty v IPv4 neni ani v tom, ze bys je musel spojovat (to stejne dela koncovy stroj), ale ze je musis po ceste rozdelovat, kdyz je predavas na linku s mensim MTU.

Ono to je trochu jinak - prave proto, ze v IPv4 je fragmentace docela dost rozbita, tak se lide moc neodvazuji pouzivat jine (vetsi) MTU nez 1500, i kdyz pro moderni hardware a rychlosti by to bylo vhodnejsi.

Problem s fragmenty v IPv4 neni ani v tom, ze bys je musel spojovat (to stejne dela koncovy stroj), ale ze je musis po ceste rozdelovat, kdyz je predavas na linku s mensim MTU. Jak je to s pruchodnosti fragmentu Internetem nevim, nicmene problem byva spis na opacne strane - router predavajici pakety, ktere maji zakazanou fragmentaci po ceste (typicky TCP), vygeneruje ICMP zpravu, kterou nekde sezere pitome nastaveny firewall.

> Nepřítomnost součtu, že něco zjednodušuje ? Přepočítat kontrolni součet neni problém a to, že ho odebrali, je dle mého názoru, taky chybou. Ne všude pakety jedou po ETH, ne každý protokol, kterým se tuneluje je málochybový.

Kontrolni soucet samozrejme neodbrali, pouze z nej vyjmuli TTL, takze ho neni treba pregenerovat pri kazdem forwardovani paketu.

> Potom fine věci, jako že do stejné skupiny patří 2 rozhraní, jedno WAN a druhé LAN. To všechno zesložiťuje logiku "routování" paketů. Je sice krásné, že zákazníkovi přidělí operátor 1 subnetu a on pro WAN použije rovnou tu subnetu stejně jako pro LAN, nicméně... Proč ?

To, zda mezi LAN a WAN se routuje (a pouzivaji odlisne prefixy) nebo bridguje/proxy­arpuje (a pouzije se stejny), preci vubec nesouvisi s IPv6 - obe varianty se pouzivaji jak na IPv4 tak na IPv6 (nicmene bridging jako optional). A fakt nevim, ze by nejaky IPv6 RFC specifikoval, ze to IPv6 implementace musi umet. Odkaz?

Logika routovani/for­wardovani je vicemene stejna - vyberu best-matching routu a pouziji interface a next-hop, ktery ta routa specifikuje.

Ad více rozhraní: nejde o to, jesli existuje více IP adres na jednom rozhraní, ale způsob, jakým IPv6 k tomu přistupuje. Minimálně bych měl rozpoznat link local, nějakej muj unicast, loopback a páš dalších (nodes na ifacu, linku, ...). A to pomíjím privacy extensions, kde se mi buduo měnit IPčka klientlů nazdařbůh. Další věc nutná k ošetření. A minimálně jeden nejmenovaný OS to má ve výchozím stavu zaplé...

Ad fragmenotování: přesně jak říkáš, 1536 batů "musí stačit každému"... Ono to souvisí ještě z dob 10base a sdíleným médiem... Těch 1500 se tak nějak vžilo jako standard, že s tím tak nějak všici počítají. A když ne, máme jumbo framy. A vzheldem k tomu, že já jsem koncovej stroj, je spojování na mně.

Ad CRC: vyjmuly kompletní hlavičku, to znamená, že část paketu prostě *nemá* CRC. Čili, je na mně si to ověřit, protože pokud chybuje médium, tak můžu posílat pakety na nějakou rand() adresu danou chybou.

Ad LAN/WAN: na IPV4 nejde jednouše mít směrovač, kterej dostane od operátora 192.168.1.1/24 tak, že on sám bude mít ".1" a klienti (na jiném rozhraní) 2-254. U IPV4 se používaj tansportní subnety /30, nebo přislušnost k vetší tansportní subnetě. U IPV6 je možné mít přesně tuhle konfiguraci (analogicky). A to u IPV4 není možné.

A best match ? Když je víc rozhraní, tak už nemusí být jednoduché určit, kam paket poslat (vic RFC4007).

IPv6, co se týče kódu, je minimálně 2x tak náročná než IPV4 a to režie 32->128 (zvětšení IP) je znedbatelná.

R.

Diky za zajimavy pohled na vec z jineho uhlu. Muzete se mi prosim ozvat tpoder@cis.vut­br.cz. Predem diky.