Vlákno názorů k článku IPv6: konec místních adres od Zdenek Pavlas - .. proc ne. Kdyz zbuhdarma a zcela zbytecne...
-
Článek je starý, nové názory již nelze přidávat.
- Podle hodnocení
- Podle vláken
- Nejnovější
-
Michal Kubeček (neregistrovaný)Zbůhdarma určitě ne. Za prvé při rozdělování rozsahů dochází k principiálním ztrátám. Za druhé je efektivní velikost adresního prostoru IPv6 výrazně omezena tím, že nejmenší delegovaný rozsah je /64. A hlavně vzhledem k tomu, že přechod na IPv6 už trvá několik let a konec (a dost možná i začátek :-) ) je stále v nedohlednu, je velmi žádoucí co nejvíce potlačit riziko, že tuto anabázi budeme muset za 20-30 let absolvovat znovu.
-
Zdenek Pavlas (neregistrovaný)> Za prvé při rozdělování rozsahů dochází k principiálním ztrátám.
I kdyby se používalo jen 1% z každého přiděleného prefixu,
je to stále zbytečně moc.
> Za druhé je efektivní velikost adresního prostoru IPv6 výrazně omezena tím, že nejmenší delegovaný rozsah je /64.
..což jen potvrzuje názor že adresní prostor je zbytečně velký.
> je velmi žádoucí co nejvíce potlačit riziko, že tuto anabázi budeme muset za 20-30 let absolvovat znovu.
Ještě nedošly 32-bitové adresy a 64 bitů by bylo na příštích 20-30 let málo? Očekáváte zdesetinásobení počtu nodů, které potřebují veřejnou adresu, každé 3 roky, po dobu 30 let? Jestli se bojíte takhle nepravděpodobných věcí, tak z vás musejí mít pojišťováci fakt radost :))) -
Michal Kubeček (neregistrovaný)..což jen potvrzuje názor že adresní prostor je zbytečně velký. ... Ještě nedošly 32-bitové adresy a 64 bitů by bylo na příštích 20-30 let málo?
Zřejmě jste dosud neslyšel o automaticky přidělovaných link-local adresách a bezstavové autokonfiguraci (router advertisement). Jinak byste věděl, proč je nejmenší delegovaný rozsah /64 a proč by 64-bitové adresy nestačily.
Mimochodem, občas s trochou nadsázky tvrdím, že IPv4 adresy už pravděpodobně došly, jen jsme si toho pro samé maškarády zatím nevšimli...
-
PaJaSoft (neregistrovaný)Z tohoto pohledu skutecne dosly jiz v pulce 90-tych let. Staci se podivat na prirustky v pripojenych strojich (tenkrat jeste IP aliasing v podstate neexistoval) a exponencialnimu rustu od 2. poloviny 80-tych let, kdy se vycerpa(l) adresni rozsah lze vcelku jednoduse aproximovat...
-
Zdenek Pavlas (neregistrovaný)Jasně- ale pořád nějak nechápu důvod Vašeho nadšení. Když si dáte MAC adresy do /etc/ethers, nebo přes nějaký extension do DNSky, tak je to úplně to samé, akorát nemůžete vytrubovat jak je IPv6 geniální věc. Prostě by bylo:
www.seznam.cz -> 212.80.76.3.00:A0:24:0B:24:74
..což je defacto rozšíření IPv4 z 32 na 80 bitů. Pokud jsem "pod stejnou /32 adresou", můžu použít MAC část adresy, a komunikovat přímo.
Pokud je cílový host jinde, prostě strčím svou a cílovou MAC adresu do vyhrazeného místa v IP headerech, a pošlu IP packet na svůj router. Packet se doroutuje na 212.80.76.3, tam router vyzvedne cílovou MAC adresu, a tam packet přepošle.
Tahle metoda, zavést sub-IPv4 adresování, je pro současnou infrastrukturu mnohem schůdnější, protože je s ní kompatibilní, stačil by drobný upgrade SW v routerech.
-
Zdenek Pavlas (neregistrovaný)Minimálně se autokonfigurovaný host musí dozvědět onen /64 prefix subnetu kam je připojen, a adresy DNSek. Takže samo to nepůjde, něco jako DHCP potřebujete. Jediná úspora je že pro IPv6 se nemusí dělat dynamická komprese 48-bitového prostoru MAC adres do typicky 4-8-bitového prostoru volných IP adres.
-
Michal Kubeček (neregistrovaný)Co je nebo neni v kterem RFC je vcelku lhostejne.
IPv6 vyzaduje aktivni ucast routeru pro autokonfiguraci, proto je IM(NS)HO ekvivalentni DHCPku.
Za prvé: bezstavová autokonfigurace sice vyžaduje aktivní účast routeru, ale na rozdíl od DHCP ale nevyžaduje aktivní účast klienta. Za druhé: slovo bezstavová vyjadřuje skutečnost, že na rozdíl DHCP serveru nepotřebuje router udržovat žádné tabulky toho, co a na jak dlouho komu přidělil a co má ještě volné. Router neví a ani nepotřebuje vědět, kdo si co autokonfiguroval (klienti se mu nehlásí). Takže ekvivalentní to rozhodně není,
radvdje naprosto triviální, přesněji řečeno, byl by, kdyby zároveň neimplementoval ještě další věci, např. podporu pro mobilní klienty.Implementace přidělení nameserverů by byla hodně nesystémovým krokem, protože by se tím otevřela pandořina skříňka. Za půl roku by někdo přišel s tím, že stejným způsobem by se mohly šířit i informace o přidělených MTA, za dalších půl roku POP3 servery a nezastavilo by se to nejspíš nikdy. Proto je IMHO lépe, že bezstavová autokonfigurace řeší pouze přidělení adresy a směrování, tedy informace podstatné pro síťovou vrstvu. Problém s konfigurací DNS by se dal řešit jinak, napadá mne třeba vyhrazená anycast adresa pro tyto účely (ale detaily jsem nerozmýšlel, možná tam bude nějaký háček).
-
Zdenek Pavlas (neregistrovaný)Router stále musí udržovat fůru stavových informací, proto jedna velmi malá, zřídka užívaná tabulka přidělených IP adres hraje nulovou roli. DHCP se díky tomu sice snadno DOSuje, ale když máte útočníka ve vnitřní síti, jste v háji s DHCP i bez něj.
Co je u routeru hlavně důležité je routování. A to je při daném počtu uzlů tím pomalejší, čím je adresní prostor řidší. A že u autokonfigurovaného IPv6 bude ZATRACENĚ řídkej nemusím zdůrazňovat.
-
Michal Kubeček (neregistrovaný)Router stále musí udržovat fůru stavových informací
Pokud se nejedná o dynamické směrování, pak nemusí udržovat žádné stavové informace. A i v případě, že se routuje dynamicky, je množství těchto informací dáno množstvím routerů, ne množstvím klientských stanic. Spousta stavových informací naopak odpadne díky tomu, že nebude potřeba stavový NAT.
Co je u routeru hlavně důležité je routování. A to je při daném počtu uzlů tím pomalejší, čím je adresní prostor řidší.
Můžete tuhle úvahu nějak blíže vysvětlit? Nenapadá mne jediný důvod, proč by to měla být pravda.
-
Zdenek Pavlas (neregistrovaný)> nemusí udržovat žádné stavové informace
Statistiky, accounting, MIBky, management sessions, dale autentizace, a sposta dalsich veci na ktere si nevzpomenu.. to vsechno je stavove. Ano, usetri se ARP a connection tracking pro NAT, ale to je jen nepatrny vrchol ledovce, a cena je vysoka.
>> A to je při daném počtu uzlů tím pomalejší, čím je adresní prostor řidší.
> Nenapadá mne jediný důvod, proč by to měla být pravda.
Me to naopak prijde naprosto intuitivni. Pokud pri stejnem poctu hostu (a routovanych prefixu) zvysim 4x adresni prostor, 4x vzrostou naroky na pamet, kterou ty prefixy zabiraji, a 4x se zpomali routovaci algoritmus (4x pomalejsi spocitani hashe, 4x pomalejsi overeni shody). Pokud to potrebujete rigorozne, tak treba:
http://citeseer.ist.psu.edu/waldvogel97scalable.html
http://citeseer.ist.psu.edu/478262.html
-
Michal Kubeček (neregistrovaný)Me to naopak prijde naprosto intuitivni. Pokud pri stejnem poctu hostu (a routovanych prefixu) zvysim 4x adresni prostor, 4x vzrostou naroky na pamet, kterou ty prefixy zabiraji, a 4x se zpomali routovaci algoritmus (4x pomalejsi spocitani hashe, 4x pomalejsi overeni shody). Pokud to potrebujete rigorozne, tak treba:
Ano, určitá část operací s paketem bude trvat čtyřikrát déle. Ale bude to jen velmi malá část. V žádném případě to nebude tak, že by routing běhal čtyřikrát pomaleji. Spíš bych se hodně divil, kdyby to zpomalení bylo více než v řádu jednotek procent. Dokonce přímo jeden z vámi zmíněných odkazů uvádí, že při použití vhodného algoritmu je například časová náročnost vyhledání nejvhodnější položky úměrná logaritmu délky adresy, tj. i tato specifická operace se prodlouží v poměru 7:5, ne vámi uváděných 4:1.
-
Michal Kubeček (neregistrovaný)Co je nebo neni v kterem RFC je vcelku lhostejne.
Doufám, že jste to myslel úplně jinak, než jak jste to napsal. Z takového přístupu by mi totiž docela běhal mráz po zádech. Stačí, že je většině autorů webových stránek lhostejné, co je ve specifikacích HTML, CSS, DOM apod. Neláká mne představa, že by stejně měly dopadnout síťové komunikační protokoly.
ČLÁNKY DO MAILU