Vlákno názorů k článku IPv6 Mýty a skutečnost, díl IV. - Podpora autokonfigurace od Lol Phirae - Určitě by se našlo něco co projde minimálně...

Určitě by se našlo něco co projde minimálně většinou stávající infrastruktury.

Všichni tady celí nažhavení očekáváme již několik týdnů tvoje geniální návrhy - a ono stále houno, že.

Tak proč prostě nenapíšete, jak byste to udělal? Výkřiky o tom, jak je IPv6 špatně a mělo se udělat staré-nové-IPv4, jsou pod každým článkem o IPv6. Diskuse pravidelně končí tím, když se někdo zeptá na způsob realizace – odpověď pokaždé chybí. Co jiného než dehonestaci si zaslouží „nápad“, o kterém dotyčný musí vědět, že je to nesmysl?

Mnohe z toho co tady popisujete bylo pred 15 lety zvazovano v nekolika navrzich. IPv6 jak jej zname dnes nebyl jediny kandidat mozneho reseni (viz. http://tools.ietf.org/html/rfc1752#section-7- docela dlouhe pocteni, ale velice poucne).

Dnes uz jsme asi ve stavu kdy neni cesty zpet. IPv6 je naprosta katastrofa, ale na druhou stranu hodne prace do nej uz bylo investovano. Dnes uz je k mani fungujici routing, sockety, DNS, vyvinute chipy, implementovane firewally... Je toho vic nez se zda. U jinych reseni neni k mani ani nijaka specifikace a neni vylouceno ze by pripadne dopadla stejnou katastrofou jako dnesni IPv6.

Lepsi cesta se mi jevi jako dovedeni IPv6 do pouzitelneho stavu (byt to bude trvat jeste dalsich 20 let).

Ještě větší blbec než jsme doufali.

Můžete být trochu konkrétnější koho přesně myslíte tou mlčící většinou, která provozuje IPv6 ve vetší infrastruktuře?

Podle mě je zatím IPv6 všude maximálně jako experimentální hračka, která když přestane fungovat tak to nikomu příliš vadit nebude (pokud si toho někdo vubec všimne).

Ono je rozdíl mít "rozjeté" IPv6 někde na páteři a nebo provozovat IPv6 až k uživatelům. Je to asi stejný rozdíl jako mít vyřešenou veřejnou dopravu a nebo mít v poli postavené koleje které vedou od nikud nikam. Obojí můžete deklarovat jako dopravní řešení (=zavedené IPv6) s tím rozdílem, že druhou variantou nikoho nepřepravíte.

Tohle k ničemu nevede. Skrze tyhle hádanky se příliš daleko nedostaneme. Bohužel toto ja častý postoj IPv6 protagonistů. Tvrdí jak je všechno v pořádku a jak vše nádherně funguje, ale nesmíte to chtít vidět.

Tenhle postoj zavádění IPv6 ale příliš nepomáhá.

Příklad se školami je v pořádku. Kde jinde by ostatně měly tyto aktivity vznikat primárně. Ostatně i kedjaký ISP se prostě apoň nějak IPv6 zabývá. Problémem je, že nikdo dnes není na IPv6 závislý. Když se všude IPv6 zítra vypne tak se vůbec nic nestane - nikomu nebude chybět. Tím nevzniká žádný tlak na to aby se věci v IPv6 uvedly do použitelného stavu.

Mno uvidíme za dva tři roky...

Céče, ty jseš hotovej zneuznanej génius, tobě snad upřeli Nobelovku, ne? Zatímco na tom "IPV6-SHITU" jak říkáš se pracovalo přes 15 let, tak ty to zřejmě vyřešíš za 2-3 roky sám a daleko lépe. :-))))

Pardon, ale nechápu, proč přes DHCPv6 nejde předat výchozí bránu? Ten server ji zná (protože nějakou má a je ve stejné síti, tedy je stejná i pro ostatní nody v té síti) a tak ji může předat. Je problém v Implementaci IPv6 na strané klientů, kteří nepředpokládají, že můžou získat vvýchozí branánu od jinud než od směrovače? A proč toto chování klentů by nešlo změnit?

Ještě máme blok E. Tam je 268435456 adres. Možná by stačilo to přidělit jako adresy sítí a adresy podsítí implementovat pomocí třeba Options.

Pokud jsem to z té diskuse správně pochopil, tak jedný důvod, proč výchozí bránu šířit SLAACem je ten, že pří pádu jednoho směřovače a připojení druhého se celá síť automaticky překonfiguruje. Jenže to jde přece zařítit i přes DHCPv6 - když klient nemůže komunikovat, požádá server o novou funkční konfiguraci. A DHCPv6 server se může autokonfigurovat SLAACem, ten toho více než prefix a výchozí bránu ke své práci nepotřebuje.

a jak klient pozná, že nemůže komunikovat kvůli tomu, že vypadla default gw a ne třeba koncový uzel? Stejně by to vedlo pouze k duplikování protokolu RA. Něco jako ... nemůžu komunikovat... co s tím? Zeptám se jestli žije router. Router nežije, co teď? Zeptám se DHCP serveru na nový router. DHCP router musí vědět co udělat, když router vypadne (definujeme nový protokol)

No, asi bych přece jenom zůstal u toho RA.

sakryš... DHCP server musí vědět... (jak to zjistí? Asi pomocí RA).

A já bych šel ještě dál s tím, že takový nápad tady na Lupě pravidelně pod každým článkem o IPv6 předhazují jistý novacisko a admin.

Pokaždé se jim někdo pokusí vysvětlit, proč to je z hlediska kompatibility ještě větší problém, než IPv6 a hup, pod dalším článkem se vše opakuje.

A funkčního návrhu jsme se od něj opět nedočkali... to je překvapení. :-)

<blockquote>server ji zná (protože nějakou má a je ve stejné síti, </blockquote>

Chybný předpoklad. V IPv6 můžete mít DHCP server mimo linku. Proto DHCP nemůže přidělovat výchozí bránu.

Aha, tak to bude asi hodně tajné, když vetšina z nás ani netuší...

Osobně si myslím, že v jisté míře to mají nasazené třeba vysoké školy. TUL, VŠB, VŠE, atd., ikdyž někdy s omezeními.

http://www.cesnet.cz/ipv6/wg/

mikrojehlu ve stohu?

4/ Radši pošleme pakety na disketě poštou, protože tahle nesmyslná splácanina samozřejmě nebude fungovat.

Jestli to chápu dobře, tak ty adresy v paketech bude měnit provider E1 na hranici své sítě do starého internetu a balit je do adres se zdrojovou adresou svojí.

1. potřebujete změnit DNS tak, aby existovala zpráva, která na dotaz www.Z3E2.cz odpoví IP_E2:IP_Z3 - takže to je první protokol, který musíme změnit

2. stále nám tu visí problém výkonu při přepisování hlaviček

3. nevím jakým způsobem rozliším IP adresu uvnitř E1 od adresy ze starého internetu, pokud budu chtít komunikovat se Z4 nebo Z2 a shodou okolností budou mít stejné adresy (nepředpokládám, že by se využily privátní adresy, protože to může být pro jednoho providera málo)

Tomu nazoru rozmumim, nicmene svet neni staticky a prubezne se meni.

Je pouze otazka casu kdy nektere silenosti typu nastavovani adres pres SLAAC nebo DUIDy v DHCP budou pod vlivem praxe vykopnuty a nahradi je jiz dnes fungujici pouzitelne veci. Rada veci v IPv6 se da dovest do rozumneho stavu pouhym zrusenim pseudozlepseni (bude nekomu chybet SLAAC, nahodne generovane adresy atd., SEND ?)

Myslim, ze upinani se k "jinemu reseni" ktere je kdesi v oblacich je uplne totez jako tvrzeni, ze IPv6 je ok - akorat z druhe strany. Realita se zpravidla odebere nekde tim stredem.

Dalsi faktor je taky, ze firmy uz do IPv6 nainvestovaly nemale prachy a proste je budou chtit zpet. Nejaky zpusob jak to udelat si uz jiste najdou - nebudou to ostatne delat poprve :-)

Dokážete si představit situaci bez relaye? Já v IPv6 ano.

RFC 1256

50% provozu mam na IPv6, a ano, jde o p2p site - konecne end to end konektivita, konecne postupne mizi neustale se opakujici dotazy jak nakonfigurovat NAT a proc to ci ono nefunguje …

Když odhlédnu od toho, že je to mrtvý návrh, tak vlastně žádnou výchozí bránu přes DHCP nekonfigurujete, protože se zjistí přes – chvilka napětí – ICMP. Co mi to připomíná? IPv6?

Tak IRDP tady bylo dřív než IPv6 a nebo jsem nepochopil vaši otázku.

Mně se spíš zdá, že Váš (profesní) vývoj se zastavil před 16 lety.

BTW: "banda sebestředných magorů" ... od Vás to sedí

Jak nikdy? Jediny, co mi v tom brani, je chybejici sitova karta u soucasny mikrovlnky. :)

Jinak souhlas, ze zrovna nad stavem autokonfigurace by po vsech tech letech clovek zaplakal. No ale porad lepsi vymyslet jen lepsi zpusob konfigurace, nez celej novej protokol.

<blockquote>[DHCP server mimo linku] může být i v IPv4 a přesto bránu přiděluje.</bloc­kquote>

Tak přiděluje, nebo nepřiděluje DHCP výchozí bránu, když je server mimo linku a na lince žádná relay není?

v tom případě bych se vrátil ještě o krok zpět:
...
Chybný předpoklad. V IPv6 můžete mít DHCP server mimo linku. Proto DHCP nemůže přidělovat výchozí bránu.
...

moje reakce: DHCPv4 to za stejných okolností umí, takže není důvod, proč by to DHCPv6 nemělo umět.

Prave ze by mel tu /48 bez kecu pridelit, stim se totiz tak nejak default pocita.

DHCP umí konfigurovat i další routy, nešlo by do toho někam propašovat výchozí bránu?

Starou (stavajici) infrastrukturou by vam E class packet bohuzel neprosel. Prekazkou bude hned prvni linuxovy router (tam snad existuje od nejake nove verse kernelu nejaky patch), ale i hned prvni Cisco, Juniper nebo Brocade... Smula.

options mají nevýhodu v tom, že se špatně zpracovávají v hardware. V konečném důsledku by to neúnosně prodražilo směrovače, které by měly přehazovat větší provoz.

to může být i v IPv4 a přesto bránu přiděluje.

Ale skutečná potřeba zpracovat Options bude stejně až na branách ISP, tedy tam, kde teď má ISP stavový NAT. A nejsem si jist, že by stavový NAT byl jednodušší, než pouhé rozparsování nějakého pole v IP hlavičce.

Ale možná to dopadne tak, jak někdo psal dole. Bude tam IPv6/IPv4 brána, čili uživatel si udělá síť jakou chce na IPv4 a bude aktiv aspoň po IPv6. Dokonce i adresa stroje po IPv6 může být sestavena jako IPv6/96 + IPv4/32 v síti klienta.

To právě není pravda. Zpracovávat options se budou muset ve všech lokálních směrovačích místních sítí. Jinak nebudete vědět, kam to posílat.

Napište teda svůj návrh přesně a já vám ho zkritizuju taky přesně :-) Už teď z toho krátkého popisu bych viděl několik velmi těžko řešitelných problémů, třeba jak odlišit vnitřní a vnější síť, ale klidně se rozepište, ať máme jasno.

Co nechápete na návrhu místo portu u NATu použít pole Options? Jediný problém je, že zatímco port je pro druhou stranu transparentní, Options by musela druhá strana podporovat, takže vyžaduje celointernetovou dohodu.

Rozlišení vnitřní a vnější sítě? Co na tom nechápete. Třeba já jsem rozhodně uvnitř nějaké vnitřní sítě. V případě NATované sítě to snad je naprosto zřejmé.

Tak si to rozložme: máme ISP E1 a E2, což jsou poskytovatelé "rozšířeného" Internetu, Máme zákazníky Z1E1 , Z2E1 (oba zákazníci ISP E1), Z3E2 (zákazník E2) a Z4 ve starém internetu.
chci komunikovat:
- uvnitř mojí větší sítě rozdělené na podsítě
- Z1E1 přistupuje na web Z2E1
- Z1E1 přistupuje na web Z3E2
- Z1E1 přistupuje na web Z4

a současně to chceme udělat tak, aby nejvíce zatížené routery nemusely pracně zpracovávat options, protože se to hardwarově nedá dost dobře vyřešit. Tj. jsou to hlavně směrovač směrující pakety ve vnitřní síti k mému diskovému poli a páteřní směrovač providera.

zkuste čmuchat trochu inteligentněji, myslím, že zas tak moc se neschovávám.

V pripadech 1) a 2) uvadi klient adresu ve forme adresa brany ciloveho ISP:adresa serveru v siti

Pri komunikaci pres options jsem uvazoval, ze bude existovat ICMP zprava, ktera klientovi posle informaci o lepsi ceste nez puvodne zadal.

1) ICMP presmeruje klienta na adresu do vnitrni site bez options
2) ICMP presmeruje klienta na branu, ktera existuje mezi E1 a E2 namisto aby to slo venkovnim interneten
3) Tady nic, na brane se pouze prepise odesilatel.

(PS: vnitrni sit, porad uvazuju rozsahy 10/8, pripadne dnes rezervovany segment E)

to říká někdo, kdo IPv6 ani nezkusil. Nechováte se trochu jako vyděšený panic před prvním sexem? :-)

A pořád, že neznáte můj návrh a přitom ho znáte líp než já sám.

Při přechodu může dojít k překladu adresy jako u NATu, akorát nestavově, prostě se vezme info z options a přepíše se tím cílová adresa a paket se pošle do vnitřní sítě. Obráceným způsobem se zdrojová adresa uloží do options a za zdrojovou adresu se dosadí adresa brány. To se dělá dneska taky, ale místo toho se používá port. A protože porty jsou přidělovány dynamicky, musí být NAT stavový.

Jasněže, můj návrh je jen další vylepšení NATu. Na druhou stranu, je plně kompatibilní a řeší to, kvůli čemu se IPv6 vlastně nyní zavádí. Totiž kvůli adresaci počítačů ve vnitřní síti. IPv6 stále považuji za velice nedodělanou záležitost a tak předpovídám, že se alternativně objeví nějaké řešení v téhleté podobě, ne tedy nutně stejné, ale podobně. Možná že ekonomické řešení využije stávající investice do páteřní infrastruktury IPv6, ale koncovým zákazníkům bude stále dodávat IPv4 s nějakým IPv6-IPv4 překladem adres, tak, aby zákazník nemusel nic řešit.

DHCP server vobec nemusi bezat v rovnakej sieti, takze urcite sa nerovna ip dhcp=gw...zvacsa sa pri vela roznych sietach pouziva jeden dhcp a vsetko sa na neho iba relay-uje...samozrejme sa mu preto musi pre kazdy subnet nastavit aku ma pridelovat.ja len tolko

A routovat se to bude jak? To jako bude „pár“ páteřních routerů, na které se bude směrovat veškerý provoz, a ty pak budou každý paket obracet naruby a zase zpátky, aby našly adresu v Options? A přístup na internet bude na pořadník, aby to ty routery stíhaly, ne?

Dehonestovat nápad se dá i líp, než takhle trapně.

Paradoxní na to je to že dnes je k tomu v IPV4 zlém světě potřeba pouze jedno nastavení na domácím NAPTu.

Jak báječně ten tvůj NAT funguje tady už popisoval kolega níže. Ale chápu, on a celá jejich firma jsou neschopní pitomci, měli si pozvat tebe a jelo by to za pět minut z celého světa. :-D

Co vám na té části IPv6, která nahrazuje IPv4, připadá nefunkční?

1. Myslet znamena kulove vedet.

2. Kdybych to pred par tydny nezkousel, nepsal bych to.

3. IPv6 si tam samozrejme skrtne, IPv6 packety stavajici infrastruktura prenaset umi.

Jste si jist tim, ze stavajici smerovace snesou nasazeni IP options ve velkem meritku? Druha vec je, ze dnes se packety s IP options casto zahazuji, protoze nektere platformy je neforwardovaly v hardware, ale v CPU, coz oteviralo moznost zahlceni tech boxu. Cili vyuziti IP options bych take nevidel jako jednoduchou a jednoznacne funkcni cestu.

(zcela pomijim fakt, ze mi Vase argumentace pripomina znamy vtip, jak Americane volaji do Kremlu "Delame tu nejakou statistiku, prosim Vas, kolik si vydela mesicne delnik v Sovetskem svazu?" ... Ozve se dlouhe ticho a pak se z druhe strany telefonu ozve "A vy zase bijete cernochy!")

Ja nerozumim tomu, kde ma byt problem. Kdybych *ted* pichnul doma do switche IPv6-Ready mikrovlnku, tak dostane verejnou IPv6 adresu, na kterou se muzu bez jakykoliv dodatecny konfigurace pripojit odkud chci a jedinou vadou na krase zustava, ze je to zatim jen 6to4. Az ISP zavede nativni IPv6 (uz na tom pracuje), bude to fungovat uplne stejne. Jen mi mozna neda cely /48 jako mam ted, ale kdo potrebuje na doma 65 tisic podsiti. :)

Ja bych tedy navrhoval, ze kdyz to stejne vyzaduje celointernetovou dohodu, ze by mozna bylo lepsi doladit tech par drobnosti a dohodnout se rovnou na IPv6, nez vymyslet od zacatku neco uplne jinyho. :)

Neblázni, takové logické řešení? :-)

Oproti tomu nikde neimplementované návrhy vás dvou, vyžadující celointernetový konsensus, ty jsou v podstatě production-ready. :-)))))))))))

Vy byste tedy chtěl vedle sebe provozovat dva protokoly, jeden IPv6 a pak upravený IPv4, a odesílatel by si nejprve zjistil, který má použít? To je zajímavý nápad. Jenom – v čem se liší id současného IPv6 a jeho tunelování skrze IPv4?

asi nějaký tunelový server.

Ale skutečná potřeba zpracovat Options bude stejně až na branách ISP

Co je to „brána ISP“?