Názory k článku IPv6 Mýty a skutečnost, díl II. - Adresový prostor

obecně tato situace pouze znamená to, že zdroje jsou připraveny a čekají na vhodnou příležitost, kdy to spustit. Jediné, co musejí udělat, je přidat do patřičného www.xxx.yy i ten AAAA záznam. Všechno je u nich už připraveno, stačí mávnout. Někteří čekají třeba na World IPv6 day (http://isoc.org/wp/worldipv6day/)

ono je to relativní, protože se snažím využívat IPv6 zdroje pokud jsou. Tj. lupa je jasná, ale třeba IPv6 xichtokniha taky existuje (na v6.facebook.com) a podobně je to s jinými zdroji.

řekl bych, že to znamená, že bt zdrojů na IPv4 je přece jenom ještě trošku víc než v IPv6.

Vetsina koncovych uzivatelu ovsem nejsou firmy, navic firemni zakaznici vetsinou stejne maji verejne IPv4. Zde je tutiz videt, ze IPv6 resi onen zasadni problem koncovych zakazniku - end to end konektivitu, aneb neco co prave na tom proklinanem NATu jednoduse nefunguje.

Ve chvíli, kdy jsem to měřil, byl můj IPv6 provoz bez bt přes 65 %. Ale nevím, jestli je to údaj, který bys chtěl slyšet :-)

Ale samozřejmě máme ještě mezery, zatím nemáme funkční SMTP nebo IMAP po IPv6 a většina IPv6 provozu je tedy generována na cizí zdroje.

mně přes IPv6 jede tak polovina provozu, pokud počítám bittorrent.

No, uz se tesim to na IPv4 jiste udelat nemuzou ...

to samozřejmě žádnou analogií není, protože router si nemusí udržovat tabulku spojení a případně se hrabat uvnitř protokolu.

Pokud IP adresu nechcete měnit, nemusíte, nic vás k tomu nenutí. Pokud chcete přijímat komunikaci zvenčí, asi přidělíte počítači i stálou IPv6 adresu. Při změně IP adresy žádná spojení nespadnou, protože se nejprve přidělí nová adresa, ze které se navazují nová spojení, a teprve když jsou všechna spojení na staré adrese ukončena a uplyne dostatečná doba, stará IP adresa se přestane používat.

nevím jestli je NAT nejhorší mor, ale určitě vím, že soukromí chránící náhodná IPV6 adresa je dokonalou analogii dvojice veřejná IP+port na NATu.

Veškerou komunikaci stejně musím iniciovat já.

Jako "bonus" mi při změně IP spadnou navázaná spojení i na vnitřní síti.

Vždyť tak to probíhá dnes. Zařízení musíte vyměnit jen tehdy, když chcete začít používat IPv6 – nebo „upravené IPv4“, takže zařízení by se musela vyměnit v každém případě. Jenom v případě páteřních sítí by ta zařízení byla v případě „upraveného IPv4“ podstatně komplikovanější a dražší, než v případě IPv6 – místo jednoduchého směrování podle IP adresy by musela lézt dovnitř paketu a v něm složitě část adresy hledat. Shrnuto a podtrženo – nákup nových zařízení je nutný v každém případě, ale zařízení pro IPv6 jsou mnohem levnější, než by byla zařízení pro „upravený IPv4“.

Ja dva prefixy najednou zkousel (jeden ULA a jeden 6to4) a Windows 7 se na to moc netvarily. Adresy sice nastavily spravne, ale tvrdosijne pouzivaly ULA jako zdrojovou adresu pro veskerou komunikaci, takze to moc funkcni nebylo.
Ale podle dokumentace by to melo fungovat, protoze by se mela pouzivat ta adresa, ktera se nejvic podoba cilovy (nejvic shodnych bitu na zacatku). A 2002: ma rozhodne podstatne bliz k produkcnimu 2xxx: nez fdxx:. Asi jsem tam mel neco blbe..

Proc ze dne na den zahazovat vsechny zarizeni? Pekne pomaloucku, polehoucku, nikdo nikoho do niceho nenuti. Musi to resit zatim pouze ti, ktery to zacina tlacit, u ostatnich je to zcela dobrovolny. Treba jak byly zpravy, ze O2 resi IPv6 se Seznamem, kam od nich jde nejvic provozu. Verejny IPv4 adresy jim za chvili dojdou a nezbyde nez strcit uzivatele za NAT. A NAT je narocnej, takze nahodi IPv6 a budou doufat, ze se toho na nej prelije co nejvic.
Naproti tomu nejakej malej mistni poskytovatel, kterej ma zakazniku hrstku a je zvyklej zit s NATem od zacatku, se nikam hnat nemusi. Rozsireni IPv6 je zatim tak maly, ze zadnou IPv6-only sluzbu v dohledny dobe nikdo nerozjede. A i kdyby snad nahodou ano, tak se tam pravdepodobne prokouse Teredo. Nevyhnutelny to zacne byt teprve ve chvili, kdy takovych sluzeb bude hodne a uzivatele si zacnou stezovat, ze jim to jede mizerne. A to jeste chvili potrva.
Pokud nekdo chce IPv6 bojkotovat, tak klidne muze a dalsich par let s tim bez vyraznych problemu vydrzi.

Verejny adresy na kazdym zarizeni byvaly normalni vec i u IPv4. Ze to dneska nekterym lidem prijde divny, je dany pouze tim, ze celej vetsi rozmach Internetu se odehraval az v dobe, kdy verejnych adres nebylo uz tak moc, musel se pouzivat NAT, a tak ho mnozi berou jako naprostou samozrejmost.
Druha vec je autokonfigurace, ktera do IP adresy cpe MAC adresu sitovky, to mi opravdu jako prilis stastny reseni neprijde. Meli radsi tech poslednich 64 bitu ziskat nejakym jednosmernym algoritmem, kterej by sikovne zkombinoval MAC adresu s prefixem. To by zajistilo, ze ve stejny siti bude mit zarizeni stejnou adresu a zaroven nepujde sledovat jeho pohyb v jinych sitich. Motivaci pro zavedeni Privacy Extensions by to sice uplne neodbouralo, ale urcite by byla podstatne mensi.

Nj. Když mě se to jeví tak nějak provázané. Aby mělo koncové zařízení adresu a nebylo s nic proti ničemu, tak to musí být z nějakého povoleného seznamu, podle nějakých pravidel. Ted´si od té krabičky od ISP směrem domů, můžu postavit LAN a v ní co chci a ničemu to nevadí. Chápu to tak, že když by teď po novu byla adres spousta a každé zařízení může mít svojí vlastní unikátní adresu na celém širém světě, ukazuje se, že ta logistika přidělování je komplikovanější než se myslelo a názory na to zda to postaru bylo úplně špatně nebo naopak celkem chytře se dost různí. No o no se to nějak vyvrbí, ale spíše jsem se utvrdil v tom, že kolem IPV6 je řada otevřených otázek, které vyplývají přímo z podstaty věci a ne z toho, že je třeba zajistit souběh s IPV4 a další "relikty minulost a současnosti".

Já myslím, že se ví. Ona je to opět specifická otázka toho, jak je Internet do domácností dneska v ČR a jak ve zbytku světa.

Například u kabelových sítí je to definováno v DOCSIS3 a modemy to umí a umí to i celá síťová infrastruktura pro kabelovky. DOCSIS3 modem si žádá pomocí DHCPv6 pro WAN IP a následně si přes DHCPv6-PD žádá o LAN segment a začne na něm přidělovat adresy sám jako lokání DHCPv6 server a i RA funguje. Toto platí, pokud je pro daný modem nastavneo, že má být L3 prvek, Může být i L2 a pak je to jinak, lze to různě kombinovat.

Takže otázka je, jak to řešit hlavně u ISPček typu wifi na RouterBoardech a případně switchích po barákách, tam není v této chvíli nic implementováno. Pokud by RouterOS uměl DHCPv6, DHCPv6-PD s následnou autopropagací do routovacích tabulek, tak také není co řešit (údajně na tom v Litvě zuřivě pracují).

Zda se, ze v pozadi vyvoje definice IPv6 byla hlavne snaha, aby kazde zarizeni melo unikatni "verejnou" adresu. Z cele zalezitosti a vyvoje specifikaci je citit dost velky tlak na moznost snadne lokalizace kazdeho zarizeni. NAT a podobne technologie pro IPv6 by technicky nebyly zadny problem a tvrzeni, ze by se tim plytvalo casem vyvojaru, je naprosto absurdni. Zatim se to bohuzel trochu vymklo z rukou - jako reakce na tendenci specifikace "odprivatizovat" a globalizovat adresovy prostor vznikly ony "Privacy Extensions", ktere jsou ovsem zase opacnym extremem, komplikujici radnou spravu i v ramci lokani site. Snad to casem nejak zkonverguje ...

Kdybyste se nad tím jenom trochu zamyslel, zjistil byste, že nejjednodušší řešení rozšíření adresního prostoru a snížení jeho fragmentace je právě IPv6 nebo něco tomu podobného. Všechny myslitelné varianty toho, jak to vyřešit v rámci IPv4, jsou nesrovnatelně složitější a dražší.

V té kapitole "Domácí sítě" to tak optimisticky a jistě nezní :-)
Domácí sítě
Stále otevřenou záležitostí je přidělování adres menším anebo domácím sítím...
A pak už je to jen jedna potíž za druhou...

<blockquote>jakysí jednosměrný firewall, který vyplývá z funkce NAT</blockquote>
Zřejmě se držíte pravidla, že stokrát opakovaná lež se stává pravdou. Můžete nám tedy aspoň prozradit, kolikrát tu lež ještě hodláte opakovat, a kdy už s tím dáte konečně pokoj? Pokud jste od minulého článku zapomněl, proč NAT není firewall, najděte si to v libovolné diskusi o IPv6, pokaždé je potřeba to vysvětlovat někomu, kdo o tom vůbec nic neví.

<blockquote>Ko­nečně, velmi často řeším dotazy typu "chci z vnitřní sítě na internet" právě NATem. Nebo varianta: "chci ze své VPN na internet". Použití NATu je přitom to nejjednoduší, ať už je ten Internet připojen kteroukoliv branou.</bloc­kquote>
Použití NATu není to nejjednodušší. Nejjednodušší je použití protokolu IP, který komunikaci mezi zařízeními v internetu řeší odjakživa.

Tady prave zalezi, jestli Vam provider bude pridelovat primo adresy na koncova zarizeni nebo dostanete prefix a s tim si to pak dal oadresujete sam, jak bude vyhovovat Vam.

To imho jeste dneska nikdo poradne nevi.

Kazdopadne pokud dostanete prefix delky /64, tak si to pak dal stejne nebudete moci oddelit pomoci routovanych siti.

za 20 let se nikomu interoperabilní řešení nepodařilo najít. Ale stále máte šanci.

Když to tedy vezmu tak, že IPV6 řeší komunikaci v síti tak jak by se mělo, nerozumím tomu jak se v článku píše, že není dořešeno jak se vlastně budou ty adresy přidělovat koncovým zařízením. Čekal jsem, že když už se tedy posuneme k tomu správnému řešení, že to je připraveno. A zjevně to není problém souběhu IPV4 a 6, ale problém toho celého konceptu. Řešení se určitě najde, ale překvapilo mě, že to není jasné, průzračné a jednoduché už teď.

ano.

ty úpravy by byly úplně stejné.

tak to jste zaspal, asi tak 10 let.

No, s překvapením musím konstatovat, že zrovna výrobce těch jeho krabiček je na tom dobře. U novějších modelů není IPv6 sprosté slovo, stejně tak věci jako DHCPv6, DHCPv6-PD, ...
Ale jednak to je trošku vyšší cenová hladina (kolem 5 kKč) a pro starší krabice nový firmware s IPv6 samozřejmě nebude.

Pokud mate vic nez jednu linku, tak distribuujete dva a vice prefixu.

Ono to taky jednoduše pochopitelné není. Nejde o velké sítě, kde to lze řešit jednoduše OSPF + BGP a multihoming mě nijak zvlášť netrápí. Ale jde spíš o ty trochu větší než úplně mrňavé, které třeba potřebují nějaký poloautomatický failover. Pro IPv4 změní NATku. Je to hned, datové ztráty nijak extrémní, vnitřní provoz (tiskárny, servery) to neovlivní vůbec - což je většinou extrémně důležité.

Pro IPv6 je to také teoreticky jednoduché - přes RA ohlásí prefix nového poskytovatele. Možná to také bude rychlé a bezbolestné. Ale komplikuje se to v případech, kdy uvnitř té malé sítě routuju. Takže už musím (dle mě) změnit RA do každého z routříků. Na každém dalším routříku taktéž. Plus možná i DHCP. To nebude hned a pochybuju, že na to existuje jednoduchá možnost automatizace. Do quaggy se to píše ručně. Neznám možnost převzetí prefixu na základě jiného příchozího RA. A když už to nějak třeba nascriptuju, tak je problém se zdroji uvnitř té sítě. Prostě se změní IP. Přestanou fungovat tiskárny, sdílené disky. Všechny konexe se musí navázat znovu. Což může být problém, protože se vsadím, že všichni klienti si při startu služby přeloží DNS a pak už jedou jen po IP. A v případě routingu nemusím mít možnost všude používat link-local adresy, které se obecně nemění.

Teď jsem se nad tím ale trochu zamyslel ... že by přesně na toto byly Unique-local adresy? Pokud bych byl schopen přes RA ohlašovat dva prefixy zároveň (což je možné, nevím), tak by to polovinu tohoto problému řešilo. Teď ještě tu automatickou redistribuci prefixů na podsítě ... A doufat, že výběr source adresy u klienta funguje správně a očekávatelně.

Ale musím říct, že nějaký stateless nat by to asi řešil o dost jednodušeji.

No a takhle je to s námi všemi, kdo nemáme IPv6 denním chlebem ... Pokud je potřeba něco trochu odlišnějšího od zaběhlé praxe, je problém ... byť většinou mezi židlí a klávesnicí.

Z trochu jiného soudku - existují vůbec už spolehlivé domácí routříky, které zvládnou přijmout prefix-delegation? Nemyslím možnost nacpat tam jiný firm, třeba openWRT, ale prostě od výroby, pro obyčejné lidi.

Předně jsem rád za tento seriál, IPv6 je jasně nyní jediná cesta, o tom žádná. Ačkoli bych řekl, že IPv4 ovládám na poměrně slušné úrovni (spravuji pár serverů a VPN síť), IPv6 nepoužívám. Je to z toho důvodu, že skripty pro iptables mám poměrně propracované, ale obávám se, že pro iptables6 bych něco přehlédl a zle by to dopadlo (právě neznám věci jako lokální adresy v IPv6, DHCPv6/RA atd.) Proto tento seriál vítám.

Co se NAT týče. Nelíbí se mi, jak se zde o NAT píše vždy pejorativně. Používám na domácí (rozsáhlé) síti FW a za ním NAT. Nestydím se za to. Nepoužívám jej jako obezličku k bezpečnosti, nýbrž proto, že mi řeší např. zmíněný problém se zálohou konektivity aj. Jednotlivá zařízení mají forwardován vždy daný rozsah portů. Není to ideální jako všechny adresy veřejné, ale nemyslím si, že bych to měl tajit.

Vím, že je to nereálné, vím i proč je to nereálné, ale čistější by mi připadalo, kdybych mohl přemigrovat svou síť čistě na IPv6 a nějak připojit do IPv4 a IPv6, než provozovat dual stack. Právě proto, že principy nastavení jsou pro každý protokol jiné (DHCP vs. přidělování adres v IPv6...) Zkusím něco do budoucna vymyslet. :-)

Ve vyčíslení počtu adres je chyba, 2¹²⁸ není 3.4³⁸ ale 3.4⋅10³⁸.

Co je to "naprosto odlišný způsob adresace"?

V malé síti přepisování IPv6 adres nemá smysl, protože je jednoduché přidat další prefix. Ve větší síti je NAT nepoužitelný.

Je pravda, že by se NAT dal použít například k zálohování provozu, k jinému providerovi, ale to opět můžete udělat dvěma IPv6 prefixy, od každého providera jeden.

A proc by ste neco preadresovaval ? Opet a dokola porat ty samy scestny nazory od stejnych lidi. IPv6 adres muze mit kazdy rozhrani N. Pokud zmenite ISP, jediny co menite je prefix (v nejhorsim pripade). Nic vic. Tudiz jeden radek v ra/dhc, jeden radek v dns a jeden ve firewallu. TECKA.

Kromě rozšíření počet zařízení běžící pod jednou IP adresou a jakysí jednosměrný firewall, který vyplývá z funkce NAT, má NAT ještě několik dalších výhod. Přirovnal bych to oddělovacímu transormátoru.

Například lze propojit dvě naprosto samostatné sítě s naprosto odlišným způsobem adresace, bez nutnosti jednu sít readresovat. Není tako tuto síť nikde oznamovat a upravovat vnější směrovače, aby tuto síť našli. Konečně, velmi často řeším dotazy typu "chci z vnitřní sítě na internet" právě NATem. Nebo varianta: "chci ze své VPN na internet". Použití NATu je přitom to nejjednoduší, ať už je ten Internet připojen kteroukoliv branou.

Ano, funguje kaskádově. Je tak standardní jako DHCP, protože to je DHCP.

A přes do toho IPv4 paketu bude ty IPv6 adresy cpát kam? Koncové stanice už dnes IPv6 většinou umí, tam problém není. Tzn. v NATovém scénáří by mohlo fungovat IPv6 <=> IPv6. Doufejme, že se tak nestane a výrobci a tvůrci standardů se domluví.

Když si výrobci začnou dělat, co chcou a standardy je netrápí, to je ten nejhorší stav. Pak neexistuje interoperabilita různých zařízení.

ovšem link-local adresa funguje současně s případnou globální nebo site-local adresou, zatímco 169.254.x.x je jakási autokonfigurace pro izolovaný stroj/síť, aby pro komunikaci mohly použít TCP/IP bez konfigurace, ale i bez přístupu k internetu.

Jenže tohle všechno jsou jenom představy vývojářů v oblacích svojí technologické bubliny. Ve skutečnosti implementaci diktuje trh, ne tvůrci standartů.

A tady vidim dva tlaky, které nastanou:
1. uživatel bude chctít pokud možno toho muset co nejmíň měnit a ISP ho v tom bude podporovat, aby mu nedejbože nemusel něco doma řešit
2. ISP se bude snažit vydělat, a tak poskytne jenom jednu adresu a další za peníze

Výsledkem toho bude boom krabiček za pár stovek, které budou dělat NAT ven IPv6, dovnitř IPv4 a ty si budou všichni kupovat, i kdyby po nich přitom házeli všechny RFC vytesané na hliněných destičkách.

Viděl bych jako lepší řešení toto předvídat, než se tomu zubynehty bránit.

Tak jednoduché to není. Ten mobil je připojen obvykle přes PPP, a tam to bude fungovat podstatně jinak, naž na ethernetu s RA a DHCP. PPP zařízení třeba nemá MAC adresu.

Obecně dělat switch/bridge přes různá L2 média (ethernet / PPP / SLIP ...) je buď problém, nebo je to prasárna a obcházení problému. Firewall se na tom dělá taky docela blbě.

Problém klientských zařízení a přidělování prefixů vnímám jako dost zásadní. Omezit možnosti klienta jen na L2 bridge asi není dobrý nápad, pro mě je zásadní možnost mít HW firewall, který si můžu nastavit jak chci. Taky ne vše je Ethernet nebo jako-ethernet, aby se dal rozumným způsobem dělat bridge.

Ideální se jeví prefix delegation. Ovšem ukazuje se žalostný stav toho, co znamená "podpora IPv6" - standard je pořád živý / doplňuje se / obsahuje spoustu volitelných částí... Velcí operátoři zas mohou mít problém s tím, jaká bude podpora prefix delegation u carrier-grade zařízení.

Funguje prefix delegation kaskádově? Tj. že když zapojím ty "domácí" routery 2 za sebe, 1. si vezme přes DHCP info od ISP -- dostane ten 2. před DHCP z prvního další prefix? Když jo, tak ten 1. ho oddělí z první delegace (resp. na LAN tu delegaci nevyplácá celou, půjde-li to) nebo si požádá o další delegaci?

A bude tohle standardní config ze strany ISP? Tak standardní, jako je dnes DHCP? Co když budou třeba mobilní operátoři tohle schválně nepodporovat, a přes PPP mi dají 1 IPv6 a konec? A já budu chtít připojení z mobilu nasdílet dál...

Multihoming je trochu problém i mimo korporace. Mnoho lidí má 2 obyčejná připojení a failover přes IPv4 NAT.

Prave ze IPv6 odstranuje spoustu problemovych veci - napriklad nejhorsi mor s nazvem NAT, ktery muze za 90% potizi koncovych uzivatelu.

No a jelikoz je treba nejak zajistit prechodne obdobi, tak soucasti IPv6 jsou i zpusoby, jak komunikovat z IPv4 site do IPv6 site a naopak + moznost provozu obou protokolu zaroven po stejne infrastrukture.

IPv6 zaroven umoznuje spoustu novych veci, ktere ale pro zakladni provoz vubec nepotrebujete.

Tu krabicku klidne muzete mit, ale z hlediska domaciho uzivatele je to prakticky nesmysl, neznam moc kritickych domacich prostredku, ktere by bud neumeli IPv6 primo nebo nebyly nahraditelne za jednotky stokorun.

Nac ? Ten mobil muze fungovat jako switch/bridge => zarizeni za nim si rekne o IP DHCPku ISP nebo si poslechne RA. Nepotrebuje zadny prefix ktery bude dal routovat.

V IPv4 byla řada věcí komplikovaná, a tak se je IPv6 snažilo udělat lépe / začlenit. Popisované problémy tím ale nejsou způsobeny. Část problémů plyne přímo z toho, že IPv6 adres je dostatek: věci jako NAT & dynamická veřejná adresa jsou v IPv4 dodatečně vymyšlené komplikované obezličky, které obcházely nedostatek adres => v IPv6 logicky nemají co dělat (bylo by to zbytečné plýtvání časem vývojářů a výkonem směrovačů) => nově vyvstávají problémy typu ochrana soukromí, které jsme dřív nemuseli řešit. Část problémů nejsou ani tak problémy, jako spíš "chtěli jsme to a to zjednodušit, ale ještě jsou tu ty a ty výjimky, kvůli kterým to [zatím] musí jet stejně neefektivně jako IPv4". No a nakonec je tu problém přechodu z IPv4 na IPv6, jehož problematičnost spočívá v nutnosti obměnit infrastrukturu jiným způsobem než "v 18:00 vypneme IPv4 a zapneme IPv6".

Z mých povrchních znalostí problematiky jsem nabyl dojmu, že jde hlavně o problém s počtem adres. Teď jak to tak čtu se to nějak komplikuje. Jsem si představoval, že domácí síť bude pořád IPV4 a "ven" bude připojena krabičkou, která zvládne řídit komunikaci tak aby ven měla IPV6 a dovnitř IPV4. samozřejmě s možností i zařízením v domácí síti přidělovat IPV6 adresy, měl jsem na mysli pevné adresy, abych mohl zařízení "nabídnout" světu...Článek je na mě moc odborný, ale získal jsem z něj dojem, že se k řešení počtu adres přistoupilo stylem, když už se v tom vrtáme, pojďme udělat ještě tohle, tamto a tohle...a to nikdy nedopadne úplně dobře. Jsem mimo nebo to tak nějak je?

Nojo, ale jsou situace, kdy to nelze použít. Vezměte si třeba mobil, který zároveň funguje jako wifi AP (např. v posledních verzích Androidů a podobně). Co s ním? V IPv4 se to řeší NATem, ale v IPv6 je potřeba mu nějak automaticky přidělit prefix, ručně to nastavíte stěží.

Nevidim v tom nijaky zasadni problem. Aktualni stav = nekdo musi sednout a k uzivateli/jeho zarizeni pripsat parametry linky, nekdy i IP, tak tam pripise jeste prefix. Samozrejme si to uzivatel bude muset na sve strane nastavit sam, pripadne mu to za nejaky baksis udela ISP. Pripadne posle nejakym scriptem konfiguraci do zarizeni, ktere je v jeho sprave.

Opravte si tabulku s typy adres. Pro IPv4 take existují lokální adresy, je to rozsah 169.254.0.0/16 viz RFC 3927.