"On totiž zatím nikdo nepřišel na to, jak to dnes udělat výrazně lépe."
Pokud je ovsem potreba to delat nejak "vyrazne lepe". Nestacilo proste jen vzit to co funguje (IPv4) a protahnout adresu na 128 bitu? Az tohle nekomu dojde, tak se to velmi rychle nasadi bez ohledu na to zda se to jmenuje IPv6 nebo IPv17....
No tohle existuje a dokonce si to muzete prakticky vyzkouset, viz. http://ip45.org/
No dobře, není (mimochodem tyhle věci by bylo taky potřeba upravit protože počítají s 32b adresou -- a když už jste v tom tak předělat to aby z ARPu bylo ND a z DHCP DHCPv6 už takový rozdíl není :). Ale v čem je to navržené řešení lepší než současné IPv6? Umožňuje jednodušší implementaci v zařízeních (stačí jen trochu přiohnout současný IPv4 stack), jinak žádnou výhodu nevidím. A přitom podpora v zařízeních není to, co by nás brzdilo - IPv6 podporuje kde co už kdovíjak dlouho.
Je to slozitejsi.
Nevim jak na implementaci ale na pochopeni laiky je urcite snazsi. Z pusobeni v komunitni siti (ktera se snazila edukovat cleny) vim, ze lidi kteri horko tezko pochopi logiku fungovani IPv4 budou mit s IPv6 novy problém, ktery (prevazne Ti starsi) uz nerozchodi a padnou (v tomto smeru) zpet do stupne bezvedomych lam. A pochopeni technologii lidmi mi prijde v dnesni dobe zvlaste dulezite.
IPv6 samotný není o nic složitější, než IPv4 - rozdíl tam je opravdu jenom v délce adresy. Rozdíly jsou až v podpůrných technologiích - a to především v tom, že to, co se u IPv4 vyvíjelo živelně a není to považováno za součást technologie IPv4, je v případě IPv6 standardizováno od začátku a považuje se to za součást IPv6.
Obávám se ale, že to, co je u IPv4 jednoduché na pochopení, je dnes pro reálný svět stejně nedostačující. Do toho, co je potřeba znát k IPv4, je potřeba zahrnout třeba i NAT - a obávám se, že tím se složitostí dostáváme daleko za celý IPv6.
No, mě to přijde místy přeinženýrované. Daleko větší chybou jsou podle mně ty dynamický zapouzdřovací hlavičky, který by měly routery umět rozparsovat všechny. (A obecným alogritmem to nejde, právě kvůli vámi zmíněné chybě.) Ostatní chyby se vyskytují většinou i v IPv4 světě, což ale neznamená, že jsme se z toho nemohli poučit a nasadit něco co odpovídá na dnešní problémy (nebo na problémy před deseti lety) a neřeší to problémy které tu byly (jen) před pětadvaceti lety (třeba ta autokonfigurace mi přijde zbytečně složitá, když tu máme DHCP, o kterém i poučení laici zhruba tuší jak funguje.)
Můžete prosím hodit link na nějaký senzor, která umí SLAAC pro IPv6 a neumí DHCP(v4) klienta.
To čím argumentujete jsou, dle mého názoru, takové nepodložené báje zastánců bezstavové konfigurace, která se ostatně neujala ani v IPv4 (ani pro ty senzorové sítě). Složitost IPv6 stacku je taková, ze existence/neexistence DHCPv6 to už nezachrání.
specifikace se překvapivě dělá dřív než samotná implementace. A to obvykle podle stavu stávajících technologií. Psát specifikaci pro neexistující technologie je o ničem.
Takže ano, současné sensorové sítě mohou umět DHCP, nicméně v době, kdy IPv6 vznikala, byla poměrně jiná situace. Pro SLAAC nepotřebujete v podstatě vůbec nic, pro DHCP potřebujete mnohem složitější logiku (např. hodiny), která něco stojí.
Routeru ve skutecnosti staci taky jen minimalni cast. IPv6 standardizuje hromadu veci, ktery jsou routeru u rite. Podstatny je, ze ty veci jsou nejak standardni => neni to jako u 4ky kazdej pes jina ves ...
Ve skutecnosti je implementace zakladni IPv4 funcionality na IPv6 standardu radove jednodussi, prave proto, ze je spousta veci sjednocenych a zjednodusenych doslova na dren. Zadny broadcasty, zadny arp, zadny dhcp, zadny miliardy pidisubnetu (v optimalnim pripade samo) ...