Dotaz: IPv6 -- RA vs DHCPv6

[elenril]

Hraju si takhle v domácí síti s IPv6 a vznikly mi tyto otázky:

1) Chápu to správně, že je není možné provozovat pouze DHCPv6 bez RA (protože neumí distribuovat routy)? Jestli ano, má to nějaký dobrý důvod?

2) Je nějaký dobrý důvod, proč nejmenší možná podsíť je /64? Chápu, že je potřeba předejít vyčerpání jako v IPv4, ale /64 je pro účely jedné jediné podsítě strašný overkill -- stejně dobře by stačilo /80 nebo dokonce /96. Na druhou stranu zbývajících 64 bytů pro číslování sítí už tak moc není, obzvlášt vzhledem k tomu, že i pro běžného smrtelníka není problém získat /48.

Odpovědi

[Jendа]

2) Je nějaký dobrý důvod, proč nejmenší možná podsíť je /64? Chápu, že je potřeba předejít vyčerpání jako v IPv4, ale /64 je pro účely jedné jediné podsítě strašný overkill -- stejně dobře by stačilo /80 nebo dokonce /96. Na druhou stranu zbývajících 64 bytů pro číslování sítí už tak moc není, obzvlášt vzhledem k tomu, že i pro běžného smrtelníka není problém získat /48.

Podle mě můžeš mít podsíť, jakou chceš, akorát pokud bude menší než /64, nebudeš moct používat autokonfiguraci s EUI-64, ne?

[Ondrej 'SanTiago' Zajicek]

RFC 4291, bod 2.5.1. specifikuje, ze fyzicka sit ma vzdy prefixy (pokud tedy nejake ma) /64:

2.5.1.  Interface Identifiers

 ...
 For all unicast addresses, except those that start with the binary
 value 000, Interface IDs are required to be 64 bits long and to be
 constructed in Modified EUI-64 format.
 ...

[pavlix]

Nicméně za porušení nedefinuje žádný trest :), podobně jako z dosazeném nulové hodnoty za náhodnou část ULA adres.

[couker]

Ahoj, 1) Ano, chápete to správně. DHCPv6 je v IPv6 celkem k ničemu. Teď ho akorát potřebujete, pokud chcete klientům sdělit adresu DNS serverů, protože ty zatím v RA nejsou. Sice teď se schválilo rfc, které přidává i DNS zprávy do RA, ale ještě to není implementované. Důvod nevím, celé DHCPv6 je vymyšlené totálně na<>.

2) Aby správně fungovala autokonfigurace. Lze přidělit i delší prefix, ale nedoporučuje se to, protože to není třeba. Koncový zákazník by měl podle RFC dostat /56, z čehož si uděláte podsítí dost a dost, takže není důvod používat delší prefixy než /64.

[petr_p]

Schválený standard vychází z experimentálního, který například radvd coby server a rdnssd coby klient implementují už hodnou dobu.

[couker]

To ano. Je podpora v jednom sw klientovi. Není ale podpora v hw, který se typicky stará o RA, není podpora u klientů ve Windows. V praxi se to tedy zatím nedá použít.

[MaSo]

1) proč je DHCPv6 k ničemu, jak jinak si serverem přidělit klientům IPv6 aby měly nějaký smysl (nikoliv podle MAC)?
2) co je RA?

snažím se zprovoznit domácí síť přes IPv6, ale zatím neúspěšně (server již běží přes he.net), na serveru mám wide-dhcpv6-server

[couker]

RA = Router Advertisement, bezestavová konfigurace.

DHCPv6 je těžké v praxi použít kvůli tomu, že nedokáže přidělit default gw a prefixy. Je tedy nutné použít jak DHCPv6, tak bezestavovou konfiguraci pomocí RA. Pokud si k síti připojíte windows vista a vyšší, tak adresu z dhcpv6 serveru dostane. Taky si ale vygeneruje IPv6 adresu z RA. Díky tomu, že má adresu z RA, tak si vygeneruje náhodnou pomocí privacy extensions. Jelikož privacy extensions adresa má nejvyšší prioritu, použije se pro komunikaci tu a ne tu přidělenou DHCPv6. Navíc jsou ještě problémy s flagy u RA, Windowsy nemají rády některé kombinace M/O flagu. U linuxu je to trošku lepší, tam jsou privacy extension default zakázané. Ve větší síti tedy dhcpv6 nemá téměř cenu. V menší síti to možná nějak jde, ale zatím jsem neměl tu snahu to řešit. Ještě před nedávnem totiž isc dhcp6 nedokázal vypsat DUID do logu jako string, ale jako binární smetí. Tudíž to nemělo cenu dál testovat, dokud to neodladí.

V praxi se tak typicky nasazuje pouze RA a klienti si generují adresy sami. Pokud potřebujete jiné, tak buď staticky, nebo si je hodit do dns, nebo zkusit nějak rozchodit to dhcpv6. Bude to ale boj.

[MaSo]

ok, díky za osvětlení...
pokusím se nahodit HDCPv6, takže ještě musím prozkoumat, jestli jsem správně pochopil, radvd.
Ještě jak jsi psal o prioritách IPv6 adres (RA vs. DHCPv6), tak toto platí jen pro windows nebo je to dáno všeobecně "standardem". A tedy se ze serveru nedá PC donutit, aby používal prioritně mou IPv6 na místo z RA?

[couker]

Platí pro windows. Linux a MAC má zatím privacy adresy defaultně zakázány. Tedy tam by to teoreticky mohlo fungovat s přidělenou adresou ze DHCPv6. Vnutit klientům adresu pouze z DHCPv6 by mělo jít pro win i pro Linux pomocí nastavení prefix information option na onlink. V bsd rtadvd.conf tedy pinfoflags#128. Problém je pak v tom, že u všech klientů potřebujete mít zprovozněného dhcpv6 klienta, což někteří implicitně nemají a někteří nemají vůbec(WindowsXP). Jestli ale nad tou sítí máte plnou kontrolu a můžete si to dovolit, tak by tohle mohl být směr, kterým se vydat.

[pavlix]

Obecně je nesmysl nechat konfigurovat oba druhy adres zároveň, takže priority jsou pak zbytečné. Součástí RA jsou flagy, zda si má klient konfigurovat adresu sám, případně zda má použít DHCPv6 ke konfiguraci adresy, případně zda ho má použít pouze k získání ostatních informací o síti.

A tedy se ze serveru nedá PC donutit, aby používal prioritně mou IPv6 na místo z RA?

Při správné implementaci a konfiguraci se na serveru volí, jestli součástí RA je svolení, aby si klienti volili adresy sami.

[Oskar]

Je tedy nutné použít jak DHCPv6, tak bezestavovou konfiguraci pomocí RA.

Není. Pokud používáte DHCPv6 k přidělování IPv6 adres, nemá smysl zprovozňovat zároveň bezestavovou konfiguraci, stačí pouze generovat RA pro nastavení směrování.

Pokud si k síti připojíte windows vista a vyšší, tak adresu z dhcpv6 serveru dostane. Taky si ale vygeneruje IPv6 adresu z RA. Díky tomu, že má adresu z RA, tak si vygeneruje náhodnou pomocí privacy extensions. Jelikož privacy extensions adresa má nejvyšší prioritu, použije se pro komunikaci tu a ne tu přidělenou DHCPv6.

V tom případě to máte špatně nastavené. Chtete-li používat adresy z DHCPv6, musíte v RA u každého ohlášeného prefixu vynulovat příznak A. Tím se klientům zakáže použít daný prefix pro bezestavovou autokonfiguraci. Například v konfiguraci radvd:

        prefix 2001:1:2:3::/64
        {
                AdvAutonomous off;
                ...
        };

[MaSo]

jaj, tak to se mi zamlouvá, jak bude více času a budu doma, pohraji se serverem, až vyřeším jeden problém s IPv6

[pavlix]

až vyřeším jeden problém s IPv6

Snad ne konektivitu? :)

[MaSo]

ne, tu "mám" přes tunel he.net.
řeším trabl, že když na serveru na LAN nastavím IPv6 a na PC (Ubuntu) IPv6, tak se navzájem nepingnou. Jednou se mi to "nějak" povedlo, musím si s tím ještě pohrát, nejspíše dneska, trocha toho času tu je
Psalo mi to, unreachable. Mrknu na to později, teď jdu měnit CCFL podsvícení u notebooku, ámen

[pavlix]

Hmm, tak asi klasicky zkouknout ip, délku prefixu, automaticky vzniklou routu, firewall na obou, kdyby nepomohlo, tak sledovat tcpdumpem na obou :).

[MaSo]

nahozen radvd a wide-dhcpv6-server a chodí vše, jak má, akorát ještě musím doladit DUID...
a musel jsem vyhodit (G)UFW, což je snad ten nejhorší SW, co jsem kdy viděl... Zkusím firestarter a pokud neklapne ani ten, jen klasické ip(6)tables...

[elenril]

Doporučuju shorewall, výborně mi slouží na routeru jak ve v4, tak v6 verzi.

[MaSo]

shorewall jsme používali v bývalé práci na konfiguraci routerů, já však tomuhle moc nepřišel na chuť, shorewallu se chci obloukem vyhnout (no---ještě uvidíme). Fakt je, že tenhle FW má jak IPv4, tak i 6. FW6 potřebuji každopádně, co jsem si rozchodil IPv6 v celé domácí síti...

[couker]

Není. Pokud používáte DHCPv6 k přidělování IPv6 adres, nemá smysl zprovozňovat zároveň bezestavovou konfiguraci, stačí pouze generovat RA pro nastavení směrování.

Přijde mi to stejné jako jsem napsal já. Možná jsem to blbě formuloval, ale myslel jsem to tak, že nemůžu mít pouze DHCPv6 server, ale musím mít zprovozněného i RA démona.

V tom případě to máte špatně nastavené. Chtete-li používat adresy z DHCPv6, musíte v RA u každého ohlášeného prefixu vynulovat příznak A. Tím se klientům zakáže použít daný prefix pro bezestavovou autokonfiguraci. Například v konfiguraci radvd:

        prefix 2001:1:2:3::/64
        {
                AdvAutonomous off;
                ...
        };

Tj. dívám se, že jsem v předchozím příspěvku napsal blbě flag. ne onlink, ale autonomous. Je to tak jak říkáte. Akorát je pak problém, že dost často na macu nebo linuxu není defaultně dostupný dhcpv6 klient, ale to se snad změní a v domácí síti, kde si to můžu nakonfigurovat jak chci, to asi nevadí.

[Oskar]

Není. Pokud používáte DHCPv6 k přidělování IPv6 adres, nemá smysl zprovozňovat zároveň bezestavovou konfiguraci, stačí pouze generovat RA pro nastavení směrování.

Přijde mi to stejné jako jsem napsal já. Možná jsem to blbě formuloval, ale myslel jsem to tak, že nemůžu mít pouze DHCPv6 server, ale musím mít zprovozněného i RA démona.

Souhlasí. Já poukazoval na to, že bezestavová konfigurace není totéž co RA. Jinými slovy: bezestavová konfigurace je jedna z (volitelných) funkcí RA, kteréžto je (zatím) povinné pro všechny ne-manuální konfigurace IPv6 na ethernetu.

[pavlix]

Vidím, že jdu s křížkem po funuse a jak čtu diskuzi odshora, tak mi nedošlo, že už to někdo takhle pěkně vysvětlil :).

[pavlix]

RA = Router Advertisement, bezestavová konfigurace.

Router Advertisement se překládá jako oznámení či ohlášení routeru. Bezstavová konfigurace související pojem, ale jako překlad je to nesmysl.

DHCPv6 je těžké v praxi použít kvůli tomu, že nedokáže přidělit default gw a prefixy.

Citation needed.

Pokud si k síti připojíte windows vista a vyšší, tak adresu z dhcpv6 serveru dostane. Taky si ale vygeneruje IPv6 adresu z RA.

Pokud je tomu tak, tak je někde chyba, a RFC to není. Osobně bych to hádal na špatně nakonfigurovaný server, na druhém místě bych se teprv zajímal o klienta.

Ve větší síti tedy dhcpv6 nemá téměř cenu.

Spíš IMO nemá cenu v menší síti, kde stačí sesbírat MAC adresy dodatečně a nechat vše na automatice, ale to je jen můj názor. Mluvím o technologii, ne o chybách současných implementací.

V praxi se tak typicky nasazuje pouze RA a klienti si generují adresy sami. Pokud potřebujete jiné, tak buď staticky, nebo si je hodit do dns, nebo zkusit nějak rozchodit to dhcpv6. Bude to ale boj.

Boj to bude, ale neviděl bych to tak černě.

[couker]

Router Advertisement se překládá jako oznámení či ohlášení routeru. Bezstavová konfigurace související pojem, ale jako překlad je to nesmysl.

Ach, dobře. Je to sice podle mě slovíčkaření, protože router advertisement slouží v současné době výhradně k bezstavové konfiguraci, takže z jednoduchosti, jsem to tak použil. Pokud budeme důslední, tak máte pravdu.

DHCPv6 je těžké v praxi použít kvůli tomu, že nedokáže přidělit default gw a prefixy.

Citation needed.

Proč? DHCPv6 tyto možnosti konfigurace prostě v sobě neobsahuje a počítá se s koexistencí s RA. Pokud chcete tedy něco oficiálního tak problémy jsou třeba trochu popsány tady

3.10. Add Default Gateway/Prefix Options to DHCPv6

Adding Default Gateway and Prefix options for DHCPv6 would allow network administrators to configure hosts to only use DHCPv6 for default gateway and prefix configuration in managed networks, where RAs would be required today. A new draft has proposed such a default router option, along with prefix advertisement options for DHCPv6 [I-D.droms-dhc-dhcpv6-default-router]. Even with such options added to DHCPv6, an RA is in principle still required to inform hosts to use DHCPv6.

Problém je prostě v tom, že RA mi podvrhne kdejaká trubka třemi řádky ve scapy a teď ho prostě nejde filtrovat. Snooping na L2 není, IPv6 ACL L2 prvky neumí. DHCPv6 nemůže fungovat samo. Stačí jeden upravený paket, který pomíchá flagy M/O a v síti je bordel jedna dvě.

[Oskar]

...router advertisement slouží v současné době výhradně k bezstavové konfiguraci...

s/výhradně/také/

[pavlix]

A... to slovíčko "také" mění celý význam a je přesně důvod, proč je podle mě potřeba rozlišovat stavovou konfiguraci, bezstavovou konfiguraci a jednotlivé formáty paketů k tomu používané.

[pavlix]

Ach, dobře. Je to sice podle mě slovíčkaření, protože router advertisement slouží v současné době výhradně k bezstavové konfiguraci

Pokud by tomu tak bylo, tak ano... ale tohle je právě ten klíčový omyl.

RA v současné době slouží k ohlášení routeru, což se používá jak k bezstavové, tak ke stavové konfiguaci. V obou případech je získání RA klientem (ať už čekáním nebo na vyžádání), první krok ke konfiguraci sítě.

Proč? DHCPv6 tyto možnosti konfigurace prostě v sobě neobsahuje a počítá se s koexistencí s RA. Pokud chcete tedy něco oficiálního tak problémy jsou třeba trochu popsány tady

Díky, tuhle část si budu muset ještě projít, moc jsem se soustředil na konfiguraci adresy... když se na to tak dívám, přijde mi konfigurace gateway v DHCPv6 v podstatě zbytečná.

Problém je prostě v tom, že RA mi podvrhne kdejaká trubka třemi řádky ve scapy a teď ho prostě nejde filtrovat.

Stejně jako DHCPv4 a DHCPv6?

Mě přijde z tohoto pohledu úplně jedno, jestli se první paket stavové konfigurace zabalí jako ICMP nebo jako UDP.

[couker]

přijde mi konfigurace gateway v DHCPv6 v podstatě zbytečná.

S tím jde do jisté míry souhlasit. V IPv6 je třeba trochu změnit zažité zvyky a nemám nic proti tomu. Každopádně mi ale nepřijde jako příliš velká výhoda tyto informace z DHCPv6 odstranit.

Stejně jako DHCPv4 a DHCPv6?

To ano, ale jedním podvrženým paketem neovlivníte všechny na síti jako v případě RA (neberu bezstavové dhcpv6, kdy to do jisté míry jde taky). Teď prostě jedním odpojíte všechny od IPv6 internetu. A současnými prostředky tomu nelze skoro zabránit. SeND nemáme, acl většinou tohle moc neumí, snooping není. Já vím, časem bude, ale už aby to bylo.

Mě přijde z tohoto pohledu úplně jedno, jestli se první paket stavové konfigurace zabalí jako ICMP nebo jako UDP.

To samozřejmě jedno je. Až budou dostupné možnosti filtrování, jaké jsou teď u IPv4, tak se těmto problémům budeme jen smát. Teď ale nezbývá než skřípat zuby a nasazovat obezličky, které fungují jen silou vůle a cílenému útoku neodolají.

[pavlix]

S tím jde do jisté míry souhlasit. V IPv6 je třeba trochu změnit zažité zvyky a nemám nic proti tomu. Každopádně mi ale nepřijde jako příliš velká výhoda tyto informace z DHCPv6 odstranit.

Tak pokud by se člověk na DHCPv6 díval jako na postup konfigurace, tak odstraněny nebyly. Spíš by se tomu ale mělo říkat stavová autokonfigurace, jejíž součástí jsou pak i data z RA.

Podle mě to logiku má.

To ano, ale jedním podvrženým paketem neovlivníte všechny na síti jako v případě RA (neberu bezstavové dhcpv6, kdy to do jisté míry jde taky). Teď prostě jedním odpojíte všechny od IPv6 internetu. A současnými prostředky tomu nelze skoro zabránit. SeND nemáme, acl většinou tohle moc neumí, snooping není. Já vím, časem bude, ale už aby to bylo.

Tak to rozbiju v další fázi, tedy ARP/NDP, a vyjde to na stejno, ne?

To samozřejmě jedno je. Až budou dostupné možnosti filtrování, jaké jsou teď u IPv4, tak se těmto problémům budeme jen smát. Teď ale nezbývá než skřípat zuby a nasazovat obezličky, které fungují jen silou vůle a cílenému útoku neodolají.

Tak ony někde dostupné jsou :).

[pavlix]

Ahoj, 1) Ano, chápete to správně. DHCPv6 je v IPv6 celkem k ničemu.

Omyl. DHCPv6 je dobré řešení pro všechny, kterým vyhovovalo DHCP a nevyhovuje jim bezstavová autokonfigurace.

Koncový zákazník by měl podle RFC dostat /56

Já měl za to, že /48 pro obecnou síť, /64 pro síť s jediným segmentem a /128 pro jediný stroj.

[couker]

Omyl. DHCPv6 je dobré řešení pro všechny, kterým vyhovovalo DHCP a nevyhovuje jim bezstavová autokonfigurace.

Ach. O tomto lze vést dlouhou debatu, proč je DHCPv6 zatím těžké použít, pokud chcete zachovat stejnou funkčnost jak s DHCPv4 - tedy mít fixní adresu pro uživatele. Teď to kvůli DUID jde velice špatně a navíc DHCPv6 klient není defaultně ve všech systémech.

Já měl za to, že /48 pro obecnou síť, /64 pro síť s jediným segmentem a /128 pro jediný stroj.

Ano. Tak to je. Ale domácí uživatel je v tomto případě to, co vy nazýváte obecná síť, kde je původně navrhované /48 pro všechny viz. RFC3177. Teď to upravuje zatím draft. http://tools.ietf.org/html/draft-ietf-v6ops-3177bis-end-sites-01#page-4

The above-mentioned RFC3177 goals can easily be met by giving home users a default assignment of less than /48, such as a /56.

[pavlix]

Jo, ten draft vypadá jako důsledek přesunu od teorie k praxi.

[xHire]

ad 1. Zatím není. IETF k tomu dobrý důvod zřejmě měla, ale člověk by pro něj asi musel někam do archívu diskusí… Každopádně je rozpracován koncept, který by měl umožnit se bez RA úplně obejít (ač je tento dokument expirovaný, měl by být v blízké době revidován).

ad 2. Cituji z knihy IPv6 od Pavla Satrapy:

Motivací k takto velkorysému dimenzování podsítě byla snaha o maximální zjednodušení automatické konfigurace počítačů. Nicméně nelze přehlížet, že AppleTalk zvládal automatickou konfiguraci s jediným bajtem a IPv4 stačí čtyři bajty pro celosvětově jednoznačné adresy. Investovat osm bajtů na dosažení jednoznačnosti v jediné podsíti je zkrátka plýtvání.

Také mi 64 bitů ze 128 přijde docela šílených na jednu podsíť a jsem rád, že s tímhle názorem nejsem sám, nicméně je to tak nějak houby platné…

Každopádně člověka těžko může někdo donutit k tomu, aby dával takové nebo makové rozsahy. Je pak však otázkou, co s ušetřenými adresami, když už stejně byl příslušný rozsah alokován?

[begSh]

Co je špatné na tom, aby se o všechno staral DHCP server? Pak má správce kontrolu co komu přiděluje a hlavně funguje DNS. Jakým způsobem se dá zprovoznit DDNS při IPv6 autokonfiguraci?

[pavlix]

Pak má správce kontrolu co komu přiděluje

Osobně mi nepřijde moc výhodné, když správce musí vytvářet celé mapování mezi MAC a IP, když to mapování může fungovat zcela samo.

funguje DNS

DNS funguje nezávisle na způsobu přidělení adres.

Jakým způsobem se dá zprovoznit DDNS při IPv6 autokonfiguraci?

Určitě se dá, ale autokonfigurace má na výstupu statické adresy, tudíž DDNS ani není potřeba.

Místo DDNS ze záznamů na dhcp serveru bych zvolil statické mapování, což je podobná práce, jako by člověk měl s DHCP statickým mapováním.

Místo DDNS ze záznamů ohlášených klienty bych třeba já osobně použil multicast DNS, případně nechal posbírat multicast DNS jména a ohlašoval je po klasickém DNS. Tahle možnost je mimo konfiguraci klientů úplně bez udržovacích prací.

[the.max]

Daji se pridelit i mensi subnety nez /64. Bezne se delaji 'spojovaci' /126, pouzivajito i nekteri tunel brokeri. Je to stejne jako /30 na IPv4. Je to ale proti doporuceni a zamyslenemu vyuziti /64 pro autokonfiguraci.

[SAM:]

Existuje tento draft, který pojednává o využití prefixu /127 pro point to point linky.

[pavlix]

To vypadá zajímavě, snad jediné, co mě na tom mrzí je, že jsou to výjimky, tzn implementace se k těm PTP linkům musí chovat odlišně od PTMP. Ale to platí i u IPv4.

[Petr Tomášek]

Je nějaký dobrý důvod, proč nejmenší možná podsíť je /64? Chápu, že je potřeba předejít vyčerpání jako v IPv4, ale /64 je pro účely jedné jediné podsítě strašný overkill

Celé IPv6 je strašný overkill (a to je taky důvod, proč se tenhle přebobtnalý moloch dosud nerozšířil...)

[f.v.]

Jako hlavni duvody, proc IPv6 jeste masivne nejede vidim: * neochota cokoliv menit * nekompatibilita s IPv4 (jeste ze tak) * zoufale male znalosti o IPv6 mezi spravci * nesmyslne clanky a komentare, ktere odrazuji ostatni lidi * blbe psany SW, ktery by mel bezet na aplikacni vrstve a vubec by nemel sahat do vrstvy L3 (coz u velke casti SW bohuzel neplati) * miziva podpora od ISP

... a klidne se na mne sesypte... za timhle si stojim.

f.v.

[Chulda]

Víte, proč ISP IPv6 ještě nemaj? Zkuste se podívat na podporu IPv6 u cisca. Pro některé jejich železo IPv6 ještě vůbec není.

[pavlix]

Potom mi spíše vysvětlete, proč mnoho ISP včetně těch mých (jak domov, tak serverhouse) IPv6 mají. Váš komentář vyznívá, jako by to byl nějaký problém.

[Chulda]

Ano, pokud máte pár routerů/switchů, tak IPv6 dotáhnete. Pokud budete mít síť složitější, narazíte na problém - vyhodit relativně nové a drahé železo nebo čekat, až tam dopytlikujou IPv6, které bude fungovat bez negativních vedlejších efektů (obvykle omezena funkčnost)

[pavlix]

Ano, pokud máte pár routerů/switchů, tak IPv6 dotáhnete. Pokud budete mít síť složitější, narazíte na problém - vyhodit relativně nové a drahé železo nebo čekat, až tam dopytlikujou IPv6, které bude fungovat bez negativních vedlejších efektů (obvykle omezena funkčnost)

Postěžování hezké, ale obávám se, že to není můj problém.

Jakožto zákazník si vybírám z nabídky, která na trhu je, a tedy IPv6 mám. Jestli některý poskytovatel má problém IPv6 zavést, to je mi vcelku jedno (aspoň z pohledu zákazníka).

V pozici člověka z oboru pro mě potíže se zaváděním IPv6 obvykle znamenají možná přísun (často dobře zaplacené) práce. Nad tím taky brečet nebudu, že.

A jako příznivec migrace na IPv6 jsem samozřejmě rád za každou službu či síť, která se součástí v6 Internetu stane. Ani z tohoto pohledu nebudu hořekovat nad vyhozeným IPv4-only hardware.

[pavlix]

Shrnuto a podtrženo, IPv6 mám, denně používám, pomáhám zavádět, a komu se to nelíbí, ať...

[Chulda]

Ptal jste se, jestli je to problém. Pak řeknete, že vás to nezajímá. Proč tedy reagujete?

[pavlix]

Ptal jste se, jestli je to problém. Pak řeknete, že vás to nezajímá.

Neptal, viz:

Potom mi spíše vysvětlete, proč mnoho ISP včetně těch mých (jak domov, tak serverhouse) IPv6 mají.

Proč tedy reagujete?

Abych to upřesnil, problémy s nasazením IPv6 mě zajímají u těch, kteří hledají řešení. U těch, kteří hledají jen výmluvy, mě opravdu nezajímají.

[Chulda]

Neptal, viz:

Potom mi spíše vysvětlete, proč mnoho ISP včetně těch mých (jak domov, tak serverhouse) IPv6 mají.

Což jsem udělal.

Abych to upřesnil, problémy s nasazením IPv6 mě zajímají u těch, kteří hledají řešení. U těch, kteří hledají jen výmluvy, mě opravdu nezajímají.

Ale řešení jsou 2 - počkat, až cisco udělá IOS s podporou anebo vyhodit několik set tisíc a koupit něco jiného (skvěle to bude pasovat mezi ostatní cisca). Na tom nic jiného nevymyslíte.

Ale chápu, že máte progresivní tah na branku, proto je to pro vás jen výmluva.

[pavlix]

Což jsem udělal.

V podstatě ano, i když musím říct, že finanční náklady a problémy s výrobcem síťových prvků nejsou nějaká závratná novinka, která by mě zvedla ze židle.

Ale řešení jsou 2 - počkat, až cisco udělá IOS s podporou anebo vyhodit několik set tisíc a koupit něco jiného (skvěle to bude pasovat mezi ostatní cisca). Na tom nic jiného nevymyslíte.

Jo já to chápu, každá sranda něco stojí.

Ale chápu, že máte progresivní tah na branku, proto je to pro vás jen výmluva.

Tak je pravda, že já to nemusím příliš řešit. Starám se maximálně o technickou stránku, ne o finanční.

[SAM:]

Souhlas. Btw. na CISCO jsme se vykašlali a nasadili jsem Accton Edge-Core.

[Heron]

Aniž bych chtěl vyvolávat další flame, tak proč hned overkill?

Úplně stupidně bych si to představil následovně. Dva týmy, jeden bude řešit globální routing. Zachováme binární strom, to se osvědčilo. Tak kolik těch bitů by se hodilo? Hmm, eeehm, co takhle 64? Schváleno.

Druhý tým, pro jednu jedinou síť. Musí fungovat autokonfigurace, musí to jít zvolit náhodně, musí to mít nějaké security nesmysly apod. Hmmm, 64b, sice to není nic moc pro náhodné generování, ale třeba se to nebude trefovat tak často a přes multicast se to vyřeší.

Pak se ty dva týmy sešly a vznikla z toho 128b adresa, 64b na identifikaci sítě, 64b na indentifikaci v síti.

Já osobně v tom overkill nevidím. Ty hodnoty dávají smysl a třeba takové UUID je 128b samo pro sebe (122b náhody). Což už by mimochodem bylo pro hash a ověřování velmi málo (já teď třeba řeším, jak efektivně ukládat a vyhledávat hashe funkce SHA-512), protože díky narozeninovému paradoxu se u UUID dostaneme na pouhých 2^61, jako kryptografické minimum se udává pravděpodobnost 2^80.

Takže 64b zas tak moc není. Pokud to člověk přestane počítat na počet adres na jeden atom a zamyslí se nad tím rozumně, ty hodnoty jsou tak akorát a v serverovně si s tím jde opravdu pohrát a mít to logicky rozdělené.

[Petr Tomášek]

Jenže já nemluvím o 128 bitech, ale technologii IPv6 jako takové. Prostě věci, které se u IPv4 řešily jednoduše, mají u IPv6 několik sobě si konkurujících a nekompatibilních standardů; případně některé věci pro jistotu nejdou udělat vůbec.

[Michal Kubeček]

Příklad?

[pavlix]

Jenže já nemluvím o 128 bitech, ale technologii IPv6 jako takové.

Tohle by měl člověk říkat jen z hluboké znalosti technologie, jinak ze sebe udělá osla... takže uvidíme, jak to dopadne u vás :). Nesoudím předem.

Prostě věci, které se u IPv4 řešily jednoduše, mají u IPv6 několik sobě si konkurujících a nekompatibilních standardů

Komentáře na ABCLinuxu umožňují zadávat body. Zkuste aspoň tři skutečné věci, které mají několik nekompatibilních standardů (Autokonfigurace a DHCPv6 rovnou vylučuju, ty jsou mezi sebou dobře sladěné).

Pokud mě nějaké napadnou u IPv6, vymyslím jich u IPv4 nejméně třikrát tolik.

případně některé věci pro jistotu nejdou udělat vůbec.

Taky bych prosil tak tři skutečné příklady. Tohle je jak když Microsoft tvrdí, že (pan) Linux porušuje jeho patenty.

[pavlix]

Tak s odstupem času vidím, že se žádných konkrétních věcí nedočkám.

[Petr Tomášek]

Sorry, ale bohužel nemám se často vracet na starší diskuze. Naštěstí se jiní rozepsali za mě, viz seriál „IPv6 mýty a skutečnosti“...

[pavlix]

Ten seriál celkem sleduju. Netvrdím, že je bez chyby, ale řekl bych, že je celkem realistický.

Nicméně, přestože jsem nějaké ty díly seriálu četl, musím se opakovat:

Taky bych prosil tak tři skutečné příklady. Tohle je jak když Microsoft tvrdí, že (pan) Linux porušuje jeho patenty.

[couker]

64b si myslím je pro náhodné generování víc než dostatečné. Viz. třeba RFC4429

Even if the node moves into networks of 50000 nodes once per minute for 100 years, the probability of it causing or suffering a collision at any point are a little over 1 in a million.

[pavlix]

Celé IPv6 je strašný overkill (a to je taky důvod, proč se tenhle přebobtnalý moloch dosud nerozšířil...)

Za nějakou dobu se tahle věta zařadí mezi slavné věty typu že 640kB musí každému stačit :).

Přebobtnalé molochy jsou spousty manažery vychvalovaných systémů, IPv6 trochu volněji nakládá s adresním prostorem, ale to si myslím, že je jenom dobře. Jinak podle mě nevykazuje známky overkillu, a už vůbec ne v dnešních podmínkách.

[f.v.]

ad1) RA je docela fajn vec, kdyz napr. potrebujete zajistit redundanci spojeni u koncovych segmentu. Kdyby se pridelovala GW jen DHCP-ckem, pak moc variant nemate - proste prijede jedna default-routa a konec (resp. jinak by se musela dynamicky menit konfigurace DHCP). Na IPv6-segmentu muze byt nekolik routeru, ktere produkuji sve RA. Client-PC zachytava vsechny (pokud je rucne nefiltrujete) a vybira si nejvhodnejsi cestu. Je to jakesi STP dotazene az na koncove PC. A podobnych vychytavek se da najit vic...

ad2) Jak jiz bylo zmineno - zakladnim duvodem je EUI-64, tj. mechanismus, jak z MAC odvodit spodni pulku IPv6-adresy. Rozhodne nedoporucuji davat na koncove segmenty mensi masku - kdyz se hloubeji podivate napr. na format local-link adres, tak tam je /64 VZDY nutne dodrzet (jinak na sebe nektere PC nemusi na segmentu videt). A po local-link adresach toho beha na IPv6 docela hooodne.

f.v.

[Sten]

1. Existuje draft voleb pro DHCPv6, který umožní obejít se bez RA. Ale nenašel jsem, že by jej někdo implementovat. Původní důvod ale byl ten, že se klienti nebudou nijak nastavovat a z RA zjistí, jestli mají použít DHCP nebo si adresu vymyslet.
2. Ano, protože je tak navrženo fungování IPv6, konkrétně autokonfigurace. Overkill to je, ale na druhou stranu se tím minimalizuje pravděpodobnost kolize i v případě, že je síť při připojení klienta rozpadlá, takže NDP nedorazí ke všem klientům. Pokud by autokonfigurace nebyla, úplně by stačilo 64 bitů, protože to je více než 18 trilionů kombinací, i těch 48 bitů je 65 536× víc než IPv4 adres a /48 sítí může každý člověk na Zemi získat rovnou 40 000 a ještě hodně zbude .

[pavlix]

Pokud by autokonfigurace nebyla, úplně by stačilo 64 bitů

Nechci to zpochybňovat... ale pozor na to, že tady kupecké počty selhávají. Jedním z hlavních úkolů IP adresace (vedle unikátní identifikace, na kterou IPv6 opravdu 64 bitů používá), je hierarchický routing, díky kterému sítě nemusí udržovat informace o všech počítačích (či koncových sítích) na světě.

Já považuju za dobrý pohled na IPv6 adresy to, že prvních 16 bitů se dá používat a opakované pokusy o lepší způsoby adresace bez změny velikosti adresního prostoru... následujících 32 bitů je IPv4 internet pro poskytovatele, místo dřívějšího pro všechny, dalších 16 bitů nahrazuje druhý a třetí bajt v lokálních sítích 10.0.0.0/8, a 64 bitů je tu pro samotnou identifikaci.

Tzn... na IPv6 by mělo jít adresovat to, co šlo dřív na IPv4, s tím, že máme možnost zahodit NAT, začít používat automatickou konfiguaci a začít experimentovat s globálním multicastem. Vše ostatní jsou už takové drobné bonusy.

[kibec]

Docela zajímavá diskuse, abych to shrnul podle toho co jsem se dočetl jak to celé v praxi může fungovat (prosím opravte mě, jen teoretizuju a možná dost špatně ):
1/ Internet provider mi do sítě přidělí určitý prefix
2/ Nakonfiguruju router aby posílal RA a dynamicky ("staticky") přiděloval strojům stejné IP podle přiděleného prefixu
3/ Celé se to hroutí pokud se v síti používají "rozšířené" možnosti dhcp - pxe boot apod., takže nezbude nic jiného než provozovat současně IPv4 - komunikaci uvnitř sítě a IPv6 - komunikace ven
=> RA + DHCP pro IPv4, DDNS pro IPv4, mDNS pro IPv6 ... no to bude hezkej bordel

[pavlix]

Body 1 a 2 jsou OK.

3/ Celé se to hroutí pokud se v síti používají "rozšířené" možnosti dhcp - pxe boot apod., takže nezbude nic jiného než provozovat současně IPv4 - komunikaci uvnitř sítě a IPv6 - komunikace ven => RA + DHCP pro IPv4, DDNS pro IPv4, mDNS pro IPv6 ... no to bude hezkej bordel

Bordel v tom nebude, prostě se bude bootovat z IPv4 tak dlouho, dokud nezmizí IPv4-only zařízení bootovaná po síti. Za běhu už stroje IPv4 v podstatě nepotřebují (když se zvládne překlad mezi 4 a 6 pro spojení se stávajícími stroji na Internetu).

Za nějaký čas se může i bootovat po IPv6, zcela jistě to půjde :).

Zdánlivý bordel vzniká spíše potřebou přecházet postupně a tedy používat dvojí adresaci souběžně, ale tomu se nedá vyhnout.

[kibec]

No jenže takové nejčistší řešení pro IPv6 je RA. Ale i kdybych nemusel bootovat stanice přes ipv4, tak budu potřebovat ještě navíc DHCPv6 které by posílalo třeba "PXE konfig".

[pavlix]

No jenže takové nejčistší řešení pro IPv6 je RA. Ale i kdybych nemusel bootovat stanice přes ipv4, tak budu potřebovat ještě navíc DHCPv6 které by posílalo třeba "PXE konfig".

Nevím jestli nejčistší, jen je jednodušší oproti všemu, co tu dřív bylo.

Tak pokud se definuje pole pro RA, nebyl by problém poslat IP a jméno souboru stejně dobře v RA. No a pokud výjimečně potřebuješ různé stroje poslat na různé boot servery, tak nezbývá nic jiného než DHCPv6.

Ale přiznejme si narovinu, tohle je lokální záležitost... takže zatímco v globálu je potřeba zavést IPv6 co nejdříve, tak i kdyby se bootování dělalo příštích dvacet let po DHCPv4 a TFTP/IPv4, tak se nic tak hrozného nestane.

Na lokálních sítích IPv4 adresy nedojdou :).