Zásadní nepochopení IPv6

22.3.2012 14:26 | Přečteno: 2264× | Gentoo

Asi před 14ti dny jsem začal zkoumat možnost zda by můj ISP (budeme ho označovat ISP X) nedokázal prostřednictvím svého LIRa (LIR Z) dotlačit ke mne nativní IPv6 konektivitu. Připojení získávám přes ISP X, se kterým je výborná spolupráce, komunikace, atd. Vznesl jsem tedy dotaz na LIRa Z úrpstřednictvím ISP X, zda jsou schopni dodat nativní IPv6 konektivitu a dorazila mi uspokojivá odpověď, v kterou jsem ani moc nedoufal:

"IPv6 mame nasazene a neni problem Vam blok pridelit."

Můj ISP X nemá zatím s IPv6 zkušenosti a tak mne požádali o konzultace a pomoc s implementací. Formulovali jsem tedy žádost na LIRa Z, kde jsme žádali přidělení jednoho bloku s prefixem: /48 s tím, že vetší zákazníci ISP X budou dostávat prefix /56 a malí domácí zákazníci budou dostávat jeden /64. Usoudil jsem, že takové rozsahy budou vzhledem k množství a povaze zákazníku ISP X ideální. Reakce z LIRa Z na sebe nedala dlouho čekat. S rychlou odpovědí přišlo i rychlé vystřízlivění. V odpovědi stálo zhruba následující:

1. dvě IPv6 adresy přidělené na spojku mezi LIRem Z a ISP X s tím, že délka prefixu je /120 - to jsem nějak zkousnul
2. pro celého ISP X byl ne konec spojky naroutován jeden prefix /64 s krátkou poznámkou, že tolik adres musí stačit pro všechny zákazníky ISP X - zde jsem málem spadl ze židle.

Když pominu, že je zde nějaké RFC6177 a RIPE 545, tak mi to přijde jako totální nepochopení IPv6.

P.S. prosím nerozvíjejte v diskuzi téma, že v IPv6 se s adresami plýtvá. Kdo si není něčím jistý, nechť se seznámí s dílem Pavla Satrapy: IPv6.        

Komentáře

[dad]

smime se my, co tomu moc nerozumime zeptat i na uplne zacatecnicke veci nebo je diskuze otevrena jen pro ty, co uz precetli a pochopili tu Satrapovu knizku?

[mess]

Jde hlavně o to, že systém přidělování adres se mezi IPv4 a IPv6 liší. Zatímco u IPv4 si můžeš vyhradit libovolně velkou část adresy jako adresu sítě (tedy od 1 do 30 bitů, ale doufám, že chápeš, co tím myslím), tak u IPv6 má nejmenší vytvořitelná síť (podle nynější specifikace) prefix adresy 64 bitů a zbývajících 64 bitů je tzv. "interface identifier", tzn. adresa rozhraní v rámci této sítě. Tento identifikátor se buď generuje z MAC adresy nebo se generuje náhodný (tak to dělají např. Windows).

I když je tedy v této síti 2⁶⁴ adres (+- autobus), tak tuto síť už není možné rozdělit na menší. Proto je nesmysl, pokud ISP dostane 1 prefix délky 64. Prostě už ho nemůže nijak přerozdělit svým zákazníkům.

[xkucf03]

Tento identifikátor se buď generuje z MAC adresy nebo se generuje náhodný (tak to dělají např. Windows).

Ne, taky se může nastavovat IPv6 adresa staticky.

(tím neříkám, že /64 není pro poskytovatele málo, jen doplňuji)

[pavlix]

Nebo se může půjčovat z rozsahu jako IPv4.

[kralyk z abclinuxu]

No anebo DHCPv6, ne? Nebo upadlo DHCP s příchodem IPv6 v nemilost?

[xkucf03]

jj, DHCP taky. Chtěl jsem prostě poukázat na to, že to není "buď ... a nebo ...", ale že těch možností je víc.

[SAM:]

Pozice DHCPv6 je v IPv6 taková, zvláštní. Kamenem úrazu je navázání identifikace stanice na DUID a ne na MAC adresu. Pracuje se snad na nějakém rozšíření, že by se jako identifikátor mohla používat MACka, ale zatím jsem to nikde neviděl implementované. Když tak mne opravte. U SLAAC (bezstavová autokonfigurace) je implementováno distribuování seznamu DNS serverů ve zprávě Ohlášení směrovače (RA), takže pro velkou část aplikací vlastně ani DHCPv6 není potřeba.

[Jendа]

A co stanici brání odvozovat DUID z MAC?

[Heron]

Proč by se mělo DHCP vázat na MAC, když autokonfigurace už pomocí mac ip určuje? Jsou dokonce lidé, kteří nechtějí používat klasickou autokonfiguraci a argumentují tím, že při změně MAC se změní IP (jako kdyby to snad vadilo) a současně požadují navázání DHCP na MAC a ne na DUID (které lze kopírovat). A při změně mac...

[sigma]

Nebude to souviset s tím, že jsou systémy, kde se DUID změní při reinstalaci, přičemž MAC se samozřejmě nezmění? DUID teoreticky může jít ovlivnit, ale je to systémově specifická věc a práce navíc. Autokonfigurace sice definuje jasnou vazbu MAC-IP, ale nelze ji ovlivnit. Proč bych to chtěl? Třeba proto, že v jednom subnetu mám nějaké skupiny počítačů, pro které mají platit různá pravidla na firewallu, a tak se hodí mít IP adresy jedné skupiny v jednom bloku, a ne "náhodně" rozprostřené po adresním prostoru celého subnetu.

A při změně mac... Ji změním v databázi DHCP. Což u autokonfigurace není možné. Existují nasazení, kde je IP adresa využívána pro identifikaci počítače v různých systémech, a pomocí DHCP se ta IP adresa drží stabilní napříč změnami HW. Proč s IPv6 zahazovat i tohle?

[Heron]

DUID se dá nastavit / ten soubor nakopírovat. Je to nastavení jako kterékoliv jiné.

MAC se samozřejmě změní například při výměně HW a měnit MAC sice jde, ale...

Třeba proto, že v jednom subnetu mám nějaké skupiny počítačů, pro které mají platit různá pravidla na firewallu, a tak se hodí mít IP adresy jedné skupiny v jednom bloku, a ne "náhodně" rozprostřené po adresním prostoru celého subnetu.

Co takhle pro každou skupinu mít vlastní subnet? Potom by krásně fungovala autokonfigurace a mnohem snadněji by se nastavoval i ten firewall (x/64 může tohle, y/64 může támhleto).

[sigma]

DUID se dá nastavit / ten soubor nakopírovat. Je to nastavení jako kterékoliv jiné.

Ve všech OS to nemusí být tak snadné, resp. nemusí jít jen o počítače, ale i nějaká jiná zařízení, u kterých výrobce konfiguraci DUID neumožňuje. Plus je to další místo, kde může být chyba.

S IPv4 a DHCP vím, že když počítač přeinstaluju beze změny HW, dostane stejnou IP, a to třeba nějakou se speciálním významem. S IPv6 musím NAVÍC řešit konfiguraci DUID, pokud to vůbec snadno jde. Nemůžu si pomoct, ale vidím to jako zbytečnou komplikaci.

Část problémů může řešit DNS, ale zas mi to v případě toho firewallu přijde jako zbytečná komplikace. Jiný příklad - odejde tiskárna, vymění se za stejný typ s jinou MAC = musím v DB DHCP serveru udělat změnu MAC na novou, která je napsaná na štítku tiskárny. Nic jiného se nezměnilo. DUID ve firmwaru tiskárny konfigurovat nejde.

Co takhle pro každou skupinu mít vlastní subnet? Potom by krásně fungovala autokonfigurace a mnohem snadněji by se nastavoval i ten firewall (x/64 může tohle, y/64 může támhleto).

To je jistě taky možnost. Ale má to i nevýhody - provoz mezi subnety musí téct přes nějaký router, který na to musí být výkonově dimenzovaný + je třeba zohlednit to v topologii sítě, aby nedocházelo k přetížení linky k tomu routeru. Pokud chci použít autokonfiguraci, musí jít o oddělené L2 segmenty - třeba musím mít VLAN switche až k poslednímu bodu, kam jsou připojené počítače z obou skupin.

Chápu, že příchod IPv6 vyžaduje nebo potřebu trochu změnit myšlení. Ale zrovna v tomto případě nechápu, proč se tak komplikuje scénář, který je na IPv4 často používaný. A to ne zrovna z důvodu omezeného adresního prostoru, takže není důvod jeho podporu zahazovat nebo tak komplikovat.

[Sten]

Ale on se ten scénář nekomplikuje, spíše naopak:

Přeinstalace systému = (pravděpodobně) změna významu počítače = změna DUID.

Změna síťové karty = stejný počítač = stejné DUID.

Při výměně tiskárny dojde ke změně jak MAC, tak DUID, takže do DHCP budete muset zasáhnout stejně.

[pavlix]

Přeinstalace systému = (pravděpodobně) změna významu počítače = změna DUID.

Reinstalace počítače nemá vést na změnu DUID. Je to implementační nedostatek.

[xkucf03]

že při změně MAC se změní IP (jako kdyby to snad vadilo)

No, někdy to vadit může – dejme tomu, že vyměníš síťovku, pak jsou asi tři možnosti:

• nastavit nově vygenerovanou IP adresu do DNS a počkat na jeho aktualizaci
• nastavit nové kartě původní MAC adresu
• na DHCP serveru přiřadit nové MAC adrese původní IP adresu

Z toho mi přijde taková „nejpříjemnější“ ta třetí možnost – ty první dvě jsou trochu problematické, protože musíš buď chvíli čekat nebo máš bordel v MAC adresách.

[Heron]

Jaký je rozdíl mezi nastavit DNS a nastavit DHCP? Obojí je zásah někam do DB / konfiguráku.

[sigma]

Jenže já tam mám někde firewall, nebo ve větší síti víc firewallů. A jejich konfigurace do teď byla nezávislá na změnách v DNS. Když udělám změnu v DNS, musím překonfigurovat i všechny firewally, kterých se daná změna týká.

Představte si třeba, že jde o firewall pro přístup na management rozhraní tiskáren v nějakém uživatelském subnetu - chci ho povolit z nějakého mgmt serveru, a zakázat z nějakých ostatních subnetů. Teď mám vyhrazen blok IP adres pro tiskárny (s velkou rezervou), a pro celý blok udělaná pravidla na fw. Samostatný segment pro tiskárny nechci, protože jsou často připojené přes hloupý switch někde v kanceláři, kde je jedna zásuvka a 3 PC + ta tiskárna.

[xkucf03]

DNS se projeví se zpožděním (byť malým, ale nemáš to úplně pod kontrolou, protože staré IP adresy můžou být někde v mezipaměti), zatímco nová IP adresa načtená z DHCP se projeví okamžitě a přesně ve chvíli, kdy chceš.

+ Firewally někdy pracují přímo s IP adresami, nebo s doménovými jmény, ale je potřeba jim říct, aby si je znovu přeložily pomocí DNS. A i někde jinde můžou být natvrdo IP adresy (byť uznávám, že tohle by se používat nemělo).

[pavlix]

+1

[Sten]

Pokud je nějaký server navázán na DNS, asi by neměl používat autokonfiguraci

[Sten]

Anebo čtvrtá možnost: použije se DUID, které se při výměně síťovky nemění

[pavlix]

Pozice DHCPv6 je v IPv6 taková, zvláštní.

Pozice DHCPv6 je naprosto srozumitelná :).

Kamenem úrazu je navázání identifikace stanice na DUID a ne na MAC adresu.

To je kamenem úrazu špatných implementací. Návrh je dobrý. Bohužel.

Pracuje se snad na nějakém rozšíření, že by se jako identifikátor mohla používat MACka, ale zatím jsem to nikde neviděl implementované.

Tak on je to tak trochu krok zpět.

U SLAAC (bezstavová autokonfigurace) je implementováno distribuování seznamu DNS serverů ve zprávě Ohlášení směrovače (RA), takže pro velkou část aplikací vlastně ani DHCPv6 není potřeba.

DHCP je potřeba pouze pokud adminovi vadí, když si počítače volí adresu samy.

[SAM:]

Diskuze je samozřejmě otevřená. :) Snažím se jen vyhnout debatám na téma, proč nelze mít prefix delší než /64.

[pavlix]

Tak ono lze mít prefix delší než /64, technicky vzato to funguje, akorát to tak trochu odporuje RFC :).

[SAM:]

Teoreticky určitě, prakticky to tak už ale není. Setkal jsem se zařízeními (tiskárny, IP kamery), kde se natvrdo počítá s /64 prefixem a cokoliv jiného je blbě.

Je to prostě o změně myšlení. Za ty roky jsme se všichni naučili bruslit v těsném adresním prostoru a rvát se o každou adresu a šetřit kde to jde. A najednou je tu něco, kde toto šetření vůbec není na místě.

[pavlix]

Teoreticky určitě, prakticky to tak už ale není. Setkal jsem se zařízeními (tiskárny, IP kamery), kde se natvrdo počítá s /64 prefixem a cokoliv jiného je blbě.

Tak, je to určité zjednodušení.

[Sten]

+1. Nejmenší nedělitelnou jednotkou IPv6, která by odpovídala jedné IPv4 adrese, je síť /64.

[xkucf03]

Myslíš ve smyslu: IPv4 síť za NATem ~ IPv6 síť /64? To možná, ale ve smyslu jednotlivých IP adres nikoli -- např. doma mám: co počítač, to IPv4 adresa + IPv6 adresa z /64 -- ne /64 pro každý počítač.

[Sten]

Myslel jsem to v teoretické rovině. Zatímco směrování pro IPv4 vychází z otázky, jak dostat pakety na určitou adresu, tak u IPv6 jde o to, jak dostat pakety do určité /64 sítě, s tím, že tam už si s těmi pakety poradí.

[pavlix]

Je to u IPv6 a IPv4 řešeno úplně stejně, až na hojný výskyt IPv4 maškarády.

[Pindal]

Třeba je LIR Z takový chudák, že sám dostal /48 a o d(a|e)lší neumí požádat

[SAM:]

LIR dostal podle RIPE 1x /32 Takže může rozdělovat, jak chce. :)

[pavlix]

+1

LIR dostává /32.

[Sten]

To jedině, že by LIR nebyl LIR, ale byl prachsprostý ISP.

[danysek]

Nechapu "anonymizovani" onoho ISP/LIR... konkretni problemy je treba konkretne pojmenovavat, jinak se nikdy nevyresi...

[Luboš Doležel (Doli)]

Jo. ISP se zveřejňovat nemusí, ale LIR by si tu ostudu zasloužil.

[SAM:]

Zatím jsem od LIRa Z nedostal vyjádření, o které jsem požádal. Pokud nebudou ochotni nějak rozumně dodat přijatelná prefix, tak zveřejním jméno.

[pavlix]

Na to se docela těším.

[Xerces]

Ja se spíš těším, že ty adresy dodaj, jméno se tu nezveřejní a pravda a láska zvítězí nad lží a nenávistí.

[pavlix]

pro celého ISP X byl ne konec spojky naroutován jeden prefix /64 s krátkou poznámkou, že tolik adres musí stačit pro všechny zákazníky ISP X - zde jsem málem spadl ze židle.

Tak LIRem se může stát kdokoli, kdo na to vyhradí pár desítek tisíc Kč ročně. Jinak k tomu není potřeba vůbec nic. Možná bych tomu tvému LIRovi mohl nabídnout slevu na školení :).

[SAM:]

Tak já jsem jim napsal, že je klidně proškolím zadarmo, když přestanou páchat takovéto síťové porno. :)

[Jendа]

e je klidně proškolím zadarmo

Proškolení okovanou holí?

[pavlix]

Tak takový idealista zase nejsem :).

[kralyk z abclinuxu]

Tak já jsem jim napsal, že je klidně proškolím zadarmo, když přestanou páchat takovéto síťové porno. :)

Nezapomeň, že tady seš v Čechách, takže pravděpodobně nebudou tvou nabídku brát stylem "Upozornění na chybu a školení zdarma - to berem!", nýbrž "Někdo po nás chce, abychom správně dělali svoji práci - to si dělá srandu ne? A ještě si myslí, že nás bude poučovat, chytrolín".

(Sorry za cynický stereotyp, nedalo mi.)

[SAM:]

Jo, máš pravdu. V Čechách to hned každý vidí jako útok na svoje administrátorské EGO. Ale jako člen akademické instituce jejíž účelem je šířit vzdělanost, se musím alespoň pokusit s tím něco udělat :)

[xkucf03]

IMHO nejen v Čechách. Ono je sice důležité uznat chybu a doplnit si znalosti, ale zase není nic příjemného nechat se poučovat a školit někým, kdo na tebe mluví z pozice: "jo to jsou ti blbci, co neví ani základní věci o IPv6, a přitom ho nabízejí". Když to bude někdo z akademické instituce, tak je to snesitelnější, ale i tak. Takže bych se jim vůbec nedivil, kdyby si pro proškolení svých zaměstnanců vybrali někoho úplně jiného, komu klidně i zaplatí, ale kdo o tomto jejich pochybení neví a bude s nimi jednat jinak.

[pavlix]

+1

I když, na druhou stranu, já jsem na základě požadavku na IPv6 u ISP už vydělal docela dost peněz :).

[xkucf03]

Ono taky dost záleží, jaký máte vztah – jestli dlouhodobější a dobrý, tak celkem v pohodě. Ale když se s někým vidíš prvně a hned tě zbuzeruje, jak děláš svoji práci špatně, a následně ti nabídne školení, aby tě v tom ještě víc vymáchal, tak ho asi pošleš do háje, ne?

[pavlix]

Tak u nás to bylo jinak. Nebyl jsem dost drzý, abych nabídl placené školení někomu jen pro to, že mi nedal IPv6. Neplacené školení nedávám z důvodu toho, že by si ho dotyční nevážili. To už je lepší udělat placené školení a dát výtěžek na charitu či oblíbený OSS projekt, než někomu dávat něco zadarmo. Pouze jsem se slušně zeptal na možnost získat IPv6 adresu. A dopadlo to tak, že jsem dostal přístupy, instrukce ipro jiná vylepšení než IPv6, peníze za práci, a kontakty na další lidi, kteří mě potřebovali.

Jenže toho jsem nedosáhl drzostí, ale spíš intenzivní prací :).

[Heron]

Tak oni to berou jako útok na svoje administrátorské ego, protože nic jiného často neumí a někdo ještě tvrdí, že to umějí špatně.

Ale tohle je také otázkou osobního rozvoje. Když už člověk začne mít nějakou pověst, tak má stále menší problém přiznat, že něco neumí (prostě proto, že se i něm nikdo už neřekne, že je to lempl, lidé vědí, co všechno ten člověk udělal). Krásně je to vidět i v té akademické sféře. Snad nejvíce odpovědí, že něco neznají jsem slyšel od Prof., kteří toho fakticky vědí nejvíce.

[kralyk z abclinuxu]

pro celého ISP X byl ne konec spojky naroutován jeden prefix /64 s krátkou poznámkou, že tolik adres musí stačit pro všechny zákazníky ISP X - zde jsem málem spadl ze židle.

No zřejmě to bylo myšleno tak, že ISP X je celej jedna IPv6 síť a nemá vytvářet podsítě. Takže zákazník nedostane IPv6 subnet, ale nějakej počet IPv6 adres v rámci ISP X, protože 640k ought to be enough for anyone

Čili nemusí to být nutně porušení RFC (ale neznám všechna pravidla), no ale přiblblé to je každopádně, o tom žádná...

[pavlix]

ili nemusí to být nutně porušení RFC (ale neznám všechna pravidla)

Ono tu nejde o RFC. Dodržování RFC a používání zdravého rozumu sice má docela vysokou korelaci, ale zdaleka ne 100%.

[SAM:]

Tak situace se vyjasnila. Komunikace a dohoda s LIRem byla nakonec rozumná a přímočará. Došlo k nějakému komunikačnímu šumu, kdy přehlédli, že v našem požadavku jsme specifikovali prefix 1x /48. Za to se omluvili a nyní máme na konci tranzitní spojky naroutován požadovaný prefix.

[pavlix]

Výborně.