Vlákno názorů k článku IPv6 Mýty a skutečnost, díl IV. - Podpora autokonfigurace od Zelik - DHCP server vobec nemusi bezat v rovnakej sieti,...
-
Sob (neregistrovaný)
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. :)
-
petr_p (neregistrovaný)
<blockquote>[DHCP server mimo linku] může být i v IPv4 a přesto bránu přiděluje.</blockquote>
Tak přiděluje, nebo nepřiděluje DHCP výchozí bránu, když je server mimo linku a na lince žádná relay není?
-
ZP (neregistrovaný)
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!")
-
Jo chlapče, já to prostě umím ale Ty vypadáš, že nevíš o čem je tady řeč.. Mí zákazníci se do svých sítí připojují odkudkoliv a pokud je dnes v některé síti zakázán port 443, (já tedy o takové nevím) pak pochybuji, že by na tomhle problému IPV6 něco změnilo, neb by tam byly jiné restrikce. prostě pokud bude správce sítě chtít blkovat provoz, pak prostě a jednoduše blokovat provoz bude a je jedno jestli to bude síť IPV4 nebo IPV6 nebo jiná. Takže prostě a jednoduše IPV6 v tomto naprosto nic neřeší.
Problém IPV6 je v tom že banda sebestředných magorů se před 16 lety vydala řešit neduhy IPV4 tehdejšího světa ale během těch 16let se vývoj nezastavil a většina tehdejších neduhů IPV4 je dávno neaktuální a vyřešená. Další spousta problémů vznikla a IPV4 svět i s nenáviděným NATem je dokáže vyřešit elegantněji. -
Petr Bedle (neregistrovaný)
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 :-)
-
Lol Phirae (neregistrovaný)
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
-
O tom, zda je či není cesta zpět je možno polemizovat. NIcméně již dnes je zcela jisté, že ten tajný vlhký sen IPV6-Jasánků o tom jak přinesou z obchodu mikrovlnnou troubu, stisknutím jednoho tlačítka jí připojí do domácí WI-FI sítě a druhý den si při odchodu z práce vzdáleně naprogramují večeři - protože IPV6 je end-to-end ready - nikdy nenastane.
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. V IPV6 světě je to v současném stavu nemožné......ano ono se to časem nějak vyřeší, a místo nastavení NAPTu bude potřeba nějak nastavit stavový firewall nebo mapování adres, nebo něco jiného. V síti bude 25 různých služeb nahrazovat to co dneska umí pitomé DHCP a než se přes tyhle služby dopátá zařízení jak a kudy má komunikovat, budete možná mít uvařené kafe.... -
Petr Bedle (neregistrovaný)
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).
-
Mno uvidíme za dva tři roky..... nicméně ty "naše" návrhy jsou jenom odpovědí na řev naivních IPV6-Jasánků na jejich ichtylské řeči o tom, že IPV6 není ani částečně s IPV4 kompatibilní protože to je nemožné. Nic víc. Tyhle návrhy nejsou nic jiného než nástřel toho jak by mohl být řešen problém nedostatku adres podle našeho názoru mnohem lépe než mizerným IPV6. To že jakékoliv řešení vyžaduje konsensus je snad jasné každému. No a jestliže nelze konsensus najít ani po 16 letech usilovného snažení mám pocit, že je někde něco špatně a jaksi mi to implikuje, že ten problém možná ani praktické řešení prostě nemá.
-
davro (neregistrovaný)
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)
-
ondra.novacisko.cz (neregistrovaný)
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)
-
davro (neregistrovaný)
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 Z4a 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.
-
ondra.novacisko.cz (neregistrovaný)
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é.
-
Petr Bedle (neregistrovaný)
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.
-
ondra.novacisko.cz (neregistrovaný)
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.
-
ondra.novacisko.cz (neregistrovaný)
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.
-
Petr Bedle (neregistrovaný)
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.
-
davro (neregistrovaný)
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.
-
Filip Jirsák (neregistrovaný)
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?
-
Pavel (neregistrovaný)
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.
-
...z vicemene ideovych duvodu...
ANO a já bych zase pachatele SHITu zvaného IPV6 zcela neideologiky ale za to velmi prakticky pověsil za koule do průvanu...Já velmi děkuji za tuto pro mne poučnou sérii článků, která pravdivě a z praktického hlediska popisuje stav implementace a (ne)stardadizace IPV6-SHITU.
Jsem rád, že se dál a dál potvrzují všechny moje praktické připomínky k IPV6 a že si to přečtou i ti IPV6-Jasánci, co mne v diskuzích pod jinými články kamenovali, že když ve svých (mnou spravovaných) sítích důsledně zakazuji IPV6, že jsem neschopa, a že IPV6 znamená jenom samé pozitiva a lepší zítřky a a že dualstack neznamená sebemenší nebezpečí....
Byl jsem označován za pomali ideologického nepřítele, když jsem tvrdil, že tvůrci IPV6 udělali valkou chybu, že vůbec nepřemýšleli o tom, jak by měl vypadat postupný přechod mezi IPV4 a IPV6 a že se záměrně (tedy z ideologických důvodů) nezabývali zpětnou kompatibilitou s IPV4Opravdu děkuji a vidím, že jsem měl pravdu v tom, že IPV6 nabízí oproti IPV4 jediné pozitivum a to je dostatek adres...jinak jsou to samá negativa. Navíc to vyřešení nedostatku adres je navíc velmi problematické, neb každý kdo bude chtí oboustranně komunikovat s celým internetem bude muset do poslední chvíle k IPV6 nějakým způsobem držet i IPV4 adresu a to bude v praxi opravdu velmi obtížné a jak jsem již namítal žít několik desetiletí s dualstackem bude dřina a nadejdou nevídané žně pro útočníky.
Podle mne by bylo nejlepší IPV6 zcela překovpa t neby přijít s nějakým systémem externí adresace nad IPV4, ale to by musely zůstat alespoň nějaké volné celé bloky IPV4 adres.
-
Ten problem neni v technicke neproveditelnosti - ostatne v DHCP(v4) to tak leta funguje. Problem je v tom, ze (nekteri) tvurci DHCPv6 se domnivaji, ze tento udaj do DHCPv6 nepatri a udaj se ma predavat prostrednictvim SLAAC. Lidove receno - problem neni v tom, ze by to neslo, ale ze to nekdo nechce do specifikace DHCPv6 (z vicemene ideovych duvodu).
Nekolik argumentu k tomuto je mozne najit na http://www.ietf.org/mail-archive/web/dhcwg/current/msg09799.html
-
Pavel (neregistrovaný)
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?
