Vlákno názorů k článku IPv6 Mýty a skutečnost, díl IV. - Podpora autokonfigurace od Pavel - Pardon, ale nechápu, proč přes DHCPv6 nejde předat...

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.

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.

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.

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!")

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

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?

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í. :-)

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

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

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

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.

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?

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.

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 …

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.

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.

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.

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.

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)

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)

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. :-)))))))))))

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).

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

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

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í

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 :-)

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.

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. :)

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

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. :-))))

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

Co je to „brána ISP“?

asi nějaký tunelový server.

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?

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.

<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.