Vlákno názorů k článku Evropě došly volné IPv4 adresy, všechny jsou v rukou trhu od lzap - Problém IPv6 je ten, že se autoři snažili...

Problém IPv6 je ten, že se autoři snažili vyřešit deset věcí najednou, místo toho aby udělali nějaký minimální set funkčnosti s možností nějakého rozumného rozšíření v budoucnu a tlačili na rychlé zavedení toho minima. Ve srovnání s IPv4 je to příliš složité, klade to vysoké nároky na know-how i změny softwaru a hardwaru. Věřím, že to šlo udělat lépe a rychleji ale recept na úspěch upřímně nemám - bylo zcela jistě velmi těžké najít ten správný balanc a ne vše lze zavést později. Něco ale určitě ano.

Tohle tvrzení platí tak maximálně o automatické konfiguraci. Všechny ostatní části IPv6 jako mobilita, IPSEC, nebo třeba multicast jsou od jádra protokolu do jisté míry oddělené a je možné je zavádět kdykoli později. Bohužel, nejsložitější pro spoustu lidí je vymyslet znovu síť tak, aby byl všude přidělen dostatečný počet adres a nebylo tak nutné někde adresy sdílet. A to se ukazuje jako kámen úrazu zvlášť u celé generace ajťáků, kteří nikdy nezažili internet bez NATu a je to pro ně integrální součást návrhu sítí.

Stejný problém by ale musel řešit jakýkoli protokol s větším adresním rozsahem.

Automatickou konfiguraci jsem měl přesně na mysli, bohužel je to něco bez čehož je IPv6 nepoužitelné protože statické adresy by snad chtěl jen masochista (máme zákazníky se striktně statickými IPv4 sítěmi takže je to možné). Nicméně úplně tak nesouhlasím s tím že "ostatní části" jsou odděleny. Technicky možná ano, problém je že věci jako lokální link adresa (spojená s RADVD) je standardně v OS přítomna a správce to musí řešit, a to dokonce už v ranné fázi návrhu nebo implementace. Hned na to se dozví a tragedii s nutností kombinace IPv6 a RADVD z čehož mi zkrátka plyne že RADVD je slabým článkem celého IPv6 problému nasazení. Bohužel je to snad nejdůležitější součást protože tu, na rozdíl od mobility nebo IPSEC, potřebují s tak velkými rozsahy adres úplně všichni.

S tou generací ajťáků kteří zažili jen NAT máš pravdu, zajímavá myšlenka. Každopádně aby to neukončil tak černě, oceňuju práci kterou děláš nejen na root.cz a i ostatních včele s Petrem. Myslím si že se to nakonec podaří protlačit, jediná správná cesta je asi už jen osvěta protože vše je dané.

Jenže RADVD nepotřebuješ. Je to jenom jedna z možností, jak konfigurovat. Ještě je tady DHCPv6, AHCP a manuální konfigurace. A posílání RA z routeru se dá jednoduše vypnout (jediná možnost je to totiž jenom u Androidu, pokud mě paměť neklame).

AHCP vypada dost obskurne. Jaka je podpora v operacnich systemech?
Rucni konfigurace pravda RA nepotrebuje, DHCPv6 se ale pro nastaveni default gateway bez RA (a tedy i nejakeho RA demonu, napr. RADVD) neobejde.

RA nemusi obsahovat informaci o linkovem prefixu. Bez RA ovsem automaticky koncovym zarizenim nedokazete rict, jakou adresu ma Vase gateway.

Samozrejme pokud se nebavime o koncove LAN, jsou ve hre i routovaci protokoly, ktere informaci o sitovych cestach predaji (BGP, OSPFv3, IS-IS, ...).

> Jenže RADVD nepotřebuješ

No ale to já přece vím (platí to jen do jisté míry - když nepotřebuješ DNS), vždyť je to pointa mého komentáře. Je to balast který by tam neměl být, přesto v každé knize, příručce, školení atd atp se o RADVD dozvíš. K ničemu, celé to ten proces zpomalilo.

30. 11. 2019, 18:40 editováno autorem komentáře

Tak já mám nativně od ISP prefix /56. A jediná komplikace, na kterou jsem narazil (a zatím nevyřešil), je jak naprat mašiny do lokálního DNSka, abych se třeba z noťasu dostal na konzolu manželčinýho stroje a nemusel ji kvůli záplatování vyhánět. Bohužel, tohle je vlastnost docela zásadní, takže ačkoliv mám nativní IPv6, interně pro SSH vede IPv4 :( Zatím totiž byly k řešení důležitější věci, než konfigurování a vynucování DHCPv6.

No a k tvrzení "Ve srovnání s IPv4 je to příliš složité, klade to vysoké nároky na know-how i změny softwaru a hardwaru" - je tam několik nepravd:
1) Není to složité, je to jednodušší, než IPv4. Jenom to dělali jinak a lidi na to zatím nejsou zvyklí. Třeba konfigurace routeru. U IPv4 nastavím IP adresu WAN nebo metodu jejího získání, pak DHCP pool (velikost, masku, IP adresy), konfigurovat VPN. A řešit, že někdo jede někdo se stejným privátním rozsahem, takže se nedostanu do jeho VPN. U IPv6 stačilo zapnout router, dostal od ISP přes PD prefix, z něho vyloupl jednu /64 a poslal do LAN. Který klient chce, ten využije RA, kdo nechce, nechá se obsloužit DHCPv6. Pokud nechceš něčemu delegovat pevnou adresu, nemusíš o IP adresách nic vědět. A protože je prefix unikátní, můžu se bavit i s mašinou v jiné síti napřímo. A problém nastavení firewallu je všude stejný.
2) Nároky na know-how jsou menší. U IPv6 si nemusíš pamatovat finty na tunelování CGNATu, nemusíš si udržovat přehled o VPSkách a platbě za VPS, ...
3) Změny softwaru - Apple to umí, Android to umí, Linux to umí, BSD to umí, Widle od sedmiček výš to umí, OpenWRT/LEDE/Tu­rrisOS to umí, ... Co to neumí, to jsou většinou nepodporovaný zastaralý krámy a pokud jedeš na dual stack, bolí zatím spíš jejich díry, než absence IPv6.
4) Hardware měnit nemusíš. Jediný, co je potřeba, je, aby router dokázal na firewallu filtrovat IPv6, dokázal si převzít od ISP prefix a poslat ho dál. Zbytek tě netrápí. V pracovně třeba používám managovaný L2 switch TP Link TL-2218WEB, co si pamatuje ještě jak jsem ke komplu dostal OEM licenci na XPčka (na hraní s dev kitama a RPi bohatě stačí)). O IPv6 nemá jeho firmware ani tucha a stejně to proleze, dokonce i VLANama (jenom ten management je po IPv4 - v dual stack to není problém). Prozradím ti totiž tajemství, na téhle úrovni je IP protokol jenom payload a jede se jenom na MAC adresy. Takže L2 beze změny, L3 chce jenom update firmwaru. HW to s přehledem dá, pokud to není úplná troska, které se do paměti nevejde vlastní IPv6 adresa (a taková troska je na výmenu i bez přechodu na IPv6).
5) Spoustu HW můžeš s IPv6 prostě zahodit. Pokud máš třeba zvonkový tablo s VoIP, domácí router (+NAT), síť ISP (+CGNAT) a mobil (NAT na BTSce), musíš mít ještě někde server s veřejnou IP adresou, se kterým tablo i mobil udržují spojení a přehazuje to pakety z jednoho soketu do druhýho i v době, kdy nezvoní návštěva, protože NAT (a jsme zase u bodu 2 - jak to železo navíc konfigurovat?) Stojí to za to? Nebylo by lepší, kdyby se tablo s mobilem prostě viděli a po zazvonění návštěvy se tablo s mobilem spojilo třeba přes domácí router v roli home agenta (RFC3775 + RFC3776) místo udržování soketu přes prostředníka 24/7? Rozhodně by to zmenšilo traffic v sítích, ušetřilo energii i práci s VPSkou a samozřejmě náklady na to všechno... O železe u ISP (CGNAT, evidence trafficu kvůli policii,...) ani nemluvím.

(1), (2), (3) by řešil jednodušší protokol který by dal lidem jen větší rozsah, tudíž by byly přidělovány sítě a zmizela by téměř NAT. Bez jakýchkoliv dalších serepetiček typu lokální link adresy a RADVD. Moje tvrzení není žádná nepravda, je to jen jiný úhel pohledu.

(4) a (5) už se téměř dnes vyřešilo, to ano, taky to trvalo 25 let! Jak se říká po bitvě je každý generál. Moje poznámka směřuje k tomu, že kdyby býval byl protokol navržen jednoduše prostě jen jako IPv4 s větším rozsahem, tak by software a hardware mohl být k dispozici už po deseti letech. Třeba ano, třeba ne. Nepravda? Těžko.

Moje tvrzení že IPv6 klade vyšší nároky na know-how protože by mohl být vymyšlen daleko jednodušší přístup se těžko vyvrátí a stojím si za ním. Musím souhlasit že je to taková divoká teorie a spíš takový povzdech, prostě bych si přál si aby to bylo celé jednodušší. Já IPv6 myslím rozumím (základům), implementoval jsem IPv6 do velkého projektu a produktu pro správu serverů a sítí (ještě úplně není hotova integrace s ISC DHCP kvůli Kea) a můžu s klidem říct že zákazníci s tím mají problém. A strašně, strašně málo jich IPv6 v datacentrech má.

Je to přesně jak říkáš. Kdyby IPv6 bylo jen o rozšíření adresního prostoru, dávno už bychom ho nejspíš všichni používali. Jenže tím, jak se kromě tohohle zásadního problému pokusilo ještě vyřešit Všechny Myslitelné Problémy Lidstva(tm), se to celé zkomplikovalo. Je to složitější na naučení a pochopení, pokud teda nebereme jako postačující možnost, že to připojím a ono to nějak bude fungovat. Dalším problémem je, že čím je to celé košatější a čím víc možností to nabízí, tím větší prostor to taky skýtá pro všemožné bezpečnostní problémy, ať už z hlediska nějaké chyby v návrhu, implementaci nebo kvůli špatnému nastavení.

Pořád tu opakujete, že problém IPv6 je, že řeší úplně všechno, místo aby jen prodloužilo IP adresy. Jako příklad přitom uvádíte jen autokonfiguraci. To mi jednak jako úplně všechno nepřipadá, jednak ze své praxe vidím, že autokonfigurace není ani zdaleka takový problém jako nutnost uvědomit si povinnosti vyplývající z neexistence NATu.

Tedy například to, že na domácnost nestačí přidělit jen jednu adresu na WAN rozhraní domácího routeru. A když už to pochopí a adresy pro LAN přidělí (a pochopí, že /64 je fakt málo), nepochopí, že adresy nestačí jen přidělit, ale je potřeba taky přidat patřičný záznam do směrovací tabulky, aby provoz mířící na tyto adresy skončil tam, kde má. A nebo jako PODA nechtějí chápat, že existuje netriviální množství zákazníků, kteří si za jejich povinnou krabičku (ONT, DSL modem, DOCSIS modem) připojí svůj vlastní router a chtějí mít veřejné adresy i za ním.

Tohle všechno jsou problémy, které by bylo úplně stejně potřeba řešit i v jakékoli „IPv4 s delší adresou.“

Nic jsi nepochopil. Čím víc toho chceš umět nastavit a nakonfigurovat, tím víc toho musíš umět, tak už to v životě chodí. Když se ti to nelíbí, dělej něco, kde ty standalone znalosti nepotřebuješ, třeba zakopávej optiku do země. A pokud se rozhodneš věnovat něčemu odbornýmu, tak právě vědomosti jsou ta věc, za kterou jsi placený. Kdyby tvoje odborný znalosti mělo 95% populace, tak bys dělal za minimálku. Nechme autokonfiguraci těm, komu stačí a prodávejme naše znalosti těm, kdo by chtěli něco víc. BFU budou bez znalostí IP adresy klidně spát a my se znalostí, co je pod pokličkou, budeme mít vyšší kapesný.

V IPv4 je kolem vědomostí defakto socialismus, kdy BFU, power user a senior admin musí mít ty samý znalosti, aby to vůbec mohli používat a když se jako začátečník prokoušeš tím balastem, který by normálně měl jít mimo tebe, nabýváš pocitu, že se už dál nic učit nemusíš... Protože i ta blonďatá účetní v IPv4 světě musí vědět, co je to IP adresa a kde ji najít, aby se dostala přes VPN k serveru s účetnictvím, když má home office.

Připojím to a nějak to bude fungovat" je úroveň pro BFU, kterou tam dali schválně, právě aby se BFU nemuseli nic učit. Kdo chce víc, musí se to naučit, nebo zaplatit někomu, kdo se to naučil za něho. A tak to má být.

Ach jo, tak znovu.

"Moje tvrzení že IPv6 klade vyšší nároky na know-how protože by mohl být vymyšlen daleko jednodušší přístup se těžko vyvrátí a stojím si za ním."
V čem jsou ty vyšší nároky? Není to jenom obecný nepodložený blábol?
Z pohledu aplikace, když chci komunikovat v jakékoliv IP síti, prostě si otevřu soket, řeknu mu IP adresu a port protistrany a sypu/přijímá data. IP protokol je jenom jedna vrstva z celýho stacku, nad ním máš ještě TCP nebo UDP, pod ním stejnou MAC a PHY. Je to úplně stejný, až na délku adresy.
Nebo je snad složitější nakonfigurovat DNS, když místo A záznamu dáváš AAAA záznam a jinak se to neliší?
Nebo je potřeba rok studovat a dělat zkoušky z toho, že zařízení chytne RA paket, vezme z něj gateway a prefix, vygeneruje si zbytek adresy, zeptá se okolí, jestli to někdo používá a když ne, tak to začne používat samo?
Aha, ty myslíš CIDR notaci, když místo psaní ffff:ffff:fff­f:ffff:: stačí napsat /64 a je to.

" a můžu s klidem říct že zákazníci s tím mají problém."
Zvyk je železná košile. Třeba u nás v bývalé práci se používal Lync. Při připojování to chtělo IP adresu protistrany, takže když někdo svolával meeting, musel mailem rozeslat pozvánku s IP adresou jeho PC. Pokud to poslal ve čtvrtek, o víkendu stroj vypnul a v pondělí pak dostal jinou IP adresu, nastal obrovský problém s organizací meetingu. Takže obrovský problémy jsme měli i s IPv4. IPv6 by už byla jenom třešnička na dortu, protože by se opisovalo 4x delší hexa číslo, ale nebyl by to vůbec nový problém, jenom by to zviditelnilo stávající.
Prostě se furt nemůžu zbavit pocitu, že libovolná verze IP protokolu může přinášet problémy, pokud aplikaci nad ním píše pitomec. S IP protokoly obecně mám jenom čtyři problémy - NATy v IPv4, chybějící multicast v IPv4, autokonfiguraci v IPv6 a používání i tam, kde to není efektivní (např. udržování TCP/IP přes WiFi v bateriové aplikaci).

"A strašně, strašně málo jich IPv6 v datacentrech má." Nediv se. Pokud bys byl podnikatel, nerozuměl IT, najal si odborníka a ten tvrdil, že jsou dva protokoly a jeden z nich nefunguje, tak zvolíš ten druhý. Takže tímhle arguementem ses pěkně střelil do nohy.

Co se té správy serverů týká, všichni víme, že ta úplně nejhorší vlastnost IPv6 je nefunkční přidělování IP adres koncovýmu zařízení. Tohle kdyby pořádně (nebo aspoň trochu) fungovalo, po IPv4 neštěkne pes (mimo kompatibility s historií). Pokud je to tvoje jediná zkušenost, tak tvůj postoj docela chápu. Nemocný DHCPv6 podle DUID nebo RA+ND, u kterýho nevíš, co, kde a jestli vůbec v síti je, je peklo. Kdyby aspoň stroj po autokonfiguraci místnímu DNSku ohlásil "Tady stroj jménem ABC123, mám adresu 2001:1234:...", tak by šlo klidně nechat i servery na RA a řídit se tímhle.

To bol asi ešte NetMeeting, nie?

Nepovinny dhcpv6 je feature, nie bug. Android nepodporuje dhcpv6 zamerne, pretoze ten umoznuje pridelit jedinu /128 a zariadenie s tym nic nespravi.

Co je sice fajn pre spravcov siete, ale uplne zle pre pouzivatelov mobilnych telefonov, ktori by si v celularnej sieti chceli urobit tethering. Pretoze ano, prva vec co by mobilni operatori zaviedli, je povinny dhcpv6 a tethering za priplatok. Takto s RA si pre kazde tetherovane zariadenie vymyslia dalsiu ipv6 adresu a vsetko funguje.

Podobne je to s DNS: nechcete, aby sa vam kazde zariadenie registrovalo, alebo nebodaj aby registrovalu kazdu zo svojich ip adries. V manazovanych sietach je toto vyssie v stacku, pri AD alebo RH IdM zariadenie musi mat spravny keytab (joinute v domene), aby to vobec dokazalo spravit. Ano, cena toho je to, ze v logoch su ip adresy, ktore nejdu reverzne resolvnut. Pokial chcete mat prehlad, kto sa vam potuluje po sieti, tak 802.1x.

Ze vy pouzivate nieco od Turrisu?

Tam to maju chlapci trocha rozbite, kresd pri starte nacita aktualne zname ipv6 adresy a tym to konci, cokolvek sa rozda po starte kresd, uz sa resolvovat nebude.. Plati pre AAAA, pre A forwarduje na dnsmasq.

Ked sa vypne kresd a pouzije dnsmasq ako resolver, lokalny resolving funguje ako ma. Za cenu straty podpory DNNSEC. No, treba si vybrat svoje priority ;).

Jo, mám T1.0, ale takhle do hloubky jsem to nezkoumal.

Je fakt, že Linuxový stroje v LUCI vidím, ale z DNSka IP6 adresu nedostanu.
Taky je fakt, že jsou tam dva resolvery, jeden hlavní a druhý pro doménu .lan, ale pokud ten IPv6 ignoruje, tak je celkem jasno... Jenomže jak z toho ven?

Ako z toho von je presne to, co som napisal ako druhu moznost: vypnut kresd, obetovat DNSSEC, zapnut odhcpd (dhcpv6, pozor, nechat aj RA, ked mate v sieti androidy, a RA adresy nebudu mat dns zaznam). Plus po updatoch TurrisOS treba skontrolovat, ci ten nezapol kresd naspat, velmi rad to robi.

Aspon takto som to kedysi pouzival, potom som sa prestahoval, novy isp mi dal na vyber verejnu ip4 bez ipv6 alebo ds-lite, takze som zobral prvu moznost a po rokoch som zase bez ipv6.