Vlákno názorů k článku IPv6 Mýty a skutečnost, díl VIII. - Přechodové mechanizmy od admin. - No já zde nemluvím o připojení jednoho kopíku...
-
Michal Kára (neregistrovaný)
Ale tvrdil - vy :-D "Sice tím ztratíme další technologický náskok a za chvíli se z nás stane lokální džamahirie..." Možná jste myslel "a když to tak půjde dál i s dalšími technologiemi" - ale nenapsal. A hlavně, o žádných dalších technologiích řeč nebyla. Tady se bavíme o IPv6, kde, troufám si tvrdit, by Číně více pomohlo, kdyby Evropa jeho problémy vyřešila za svoje peníze, sobě tím moc nepomohla a Čina to pak okopírovala, než když si to Číňani budou muset řešit na svoje vlastní náklady.
-
Michale, predpokladam, ze jsi plne zasvecen do struktury nakladu, ktery do IPv6 venuje Cina a Evropa, kdyz si dovolujes takove soudy :-)
Stejne tak predpokladam, ze vis, jaky je pokrok v instalaci a objemu provozu IPv6 v Cine a v Evrope :-)
V opacnem pripade se obavam, ze se poustis na hodne tenky led.
-
ZP (neregistrovaný)
DNS servery samozrejme mohou byt take dualstackove, cili v tomto smeru nevidim duvod, proc jejich mnozstvi dale zdvojnasobovat (presneji duvod vidim, ale je uplne jiny a s problematikou nejakych L3 protokolu vubec nesouvisi). Firewall nastavit dvakrat samozrejme musite, dokonce na masinach v DMZ na kazdem hostu, ale to jednak je pomerne jednoducha zalezitost a druhak to muzete zobecnit a mit script, ktery pustite pro oba protokoly, jen s tim, ze sikovne pracujete s promennymi (ano, chce to u psani neceho takoveho trochu myslet, ale zase, udela se to jednou, pouzije se to mnohokrat). Podobne se daji psat protokolove nezavisle treba i route-mapy pro BGP apod.
Dokumentace se dvakrat vede, ale to je opet to nejmensi. Vice prace to sice je, ale protoze stejne clovek stravi vice casu nad logikou struktury dotycne site, neni ji zdaleka dvakrat tolik. Mnohem vic casu zabere treba ladeni velikosti MTU, ktere ruzni vendori pocitaji jinym zpusobem atd.
Pravdepodobnost chyb se pri pouziti dvou ruznych protokolu nenasobi (a dokonce ani nescita). Chceme-li byt presni, tak se jich scita jen mala cast, referencni model ISO-OSI ma sedm vrstev, v praxi vyuzivame ctyri, z toho IP(v4/v6) je jen jedina a rozhodne to neni ta vrstva, s niz by v praxi byly nejvetsi potize. Pokud se chyba naleza na vrstvach nizsich nebo naopak vyssich (a ten dual-stacking je dusledny), je uplne jedno, zda mam na treti vrstve protokoly dva nebo jen jeden.
-
Petr Bedle (neregistrovaný)
Otazka jak dlouho toto pujde provozovat. Zatim s tim neni problem, ale obavam se ze do budoucna M$ to jen tak nedovoli.
Dalsi vec, je ze tohle se da udelat v omezene mire. Pokud je tech koncovych zakazniku vice, tak se to musi resit jinak, protoze neni v nicich silach dekativovat IPv6 na stovkach koncovych systemu. Proste vypinani IPv6 casem bude tak trochu "hlavou proti zdi" (ono uz to tak je trochu dnes).
-
Tady píšou, alespoň pro Visty, něco jiného:
The Teredo client in Windows Vista is enabled but inactive by default. The feature becomes active if someone installs an application that needs to use Teredo, or chooses to change firewall settings to allow an application to use Teredo.
-
ZP (neregistrovaný)
Jaka polovina veci je v alfaverzich? Budte konkretni. Ja o nicem takovem v zadne existujici produkcni dual-stack siti nevim.
Zkusenosti s tim mate malo mozna Vy, ale to nemuzete klast za vinu navrhu protokolu... Ja treba uz davno zapomnel vsechno kolem IPX/SPX taky to tomu protokolu nevycitam ;-)
Pokud jednu z vrstev rozdvojime, mame zcela logicky kombinace dve :-) Kazdopadne nemuzeme nasobit problemy ruznych vrstev, nizsi vrstva je vzdy uceleny komplex funkci, ktere pro vyssi vrstvu predstavuji blackbox a ten se chova stejne, at nad nim pouzivame protokol takovy nebo makovy.
Takze uz ne doomsaying ohledne globalniho oteplovani, ale ohledne IPv6 ve Win7? No fajn, konecne aspon nejaka zmena :-)
-
ZP (neregistrovaný)
No jak chcete. Autokonfigurace -- chodi a v soucasnem dual stack prostredi je pouzitelna (byt to neni uplne ciste). Bezpecnostni mechanismy -- lepe nepouzivat, stejne jako na IPv4. Co mate za problem s podporou end-end sluzeb, to opravdu netusim (jiste, nesmite se divit, ze to prestane fungovat, kdyz neco zablokujete na firewallu).
Ano, prvotni konfiguraci IPv6 na male testovaci siti (od public v6 Internetu samozrejme oddelene) jsem, vcetne nastudovani problematiky, zvladl nekdy v roce 1998 za to jedine odpoledne. To jen pro upresneni, od kdy se s tim protokolem da realne experimentovat. No a v profesionalnim vyuziti samozrejme nikdo nebude konfigurovat vsechno, co v6 umoznuje, realne se skonci na nejakem dynamickem routingu, konfiguraci rozhrani, mozna autoconfigu, filtrovani a (mozna) DNS. Mozna to je asketicky pristup, ale ja od toho vic nechci a necekam... :-)
Musim se pozastavit nad tim vasim "je zcela jasne" apod., chtel bych mit Vasi jistotu. Ja vidim, ze provoz roste, pocet uzivatelu roste a cele se to zkratka pouziva. A ze to je snad betaverze? Asi tolik, jako IPv4 v roce 1995...
-
ZP (neregistrovaný)
Vetsina s toho, co uvadite, jsou zalezitosti sedme vrstvy, kterym proste musi byt jedno, co pouzivaji jako prenosovy protokol (stejne, jako jim je/melo by byt jedno, co se pouziva na prvni a druhe vrstve). Takze zbyva jen nastaveni tech zarizeni samotnych a reseni komunikace mezi nimi, tedy pustit to do vnitrniho DNS. Ze rada z tech zarizeni IPv6 nepodporuje, neznamena, ze by soucasne IPv6 bylo nejakou betaverzi, kdysi takova zarizeni nepodporovala ani IPv4 a nijak nam to nebranilo v tom, abych z prostredi, kde behalo IPX/SPX, udelali prostredi heterogenni. Jenze tehdy to uzivatel chtel, ted nechape, proc by to mel chtit, to je jediny rozdil.
Sice mame rok 2011, ale protokol TCP/IP(v4) se od roku 1995 nezmenil vubec nijak.
-
Ale no tak, zapojit 5 kompů do switche, zakázat IPV4 a kochat se IPV6kou se opravdu dá zvládnout za odpoledne a také jsem si takhle hrál. Ale já se bavím o reálných produkčních sítích, o síťových tiskárnách, skenerech, mailserverech, o pobočkách, homeworkingu, cesťácích, úložištích, aplikacích ,SQL serverech a pod.
> Asi tolik, jako IPv4 v roce 1995...
NO PRÁVĚ PROTO !!!!!! máme rok 2011 :) -
Ano jistě to nebude matematicky přesný dvojnásobek práce ale já také počítám s tím, že nejsem génius jako Vy a přecijenom mi práce s IPV6 půjde pomaleji...zvlášť když polovina věcí je v nějakých alfaverzích a zkušeností s tím je málo. Ale více práce to bude zcela jistě, na tom se doufám shodneme.
V čem nemáte pravdu je tvrzení že "Pravdepodobnost chyb se pri pouziti dvou ruznych protokolu nenasobi (a dokonce ani nescita)."....tohle nemůžete myslet vážně...i kdyby měl ISO-OSI model milión vrstev tak pokud jednu vrstvu rozdvojíme logicky nám vzniknou čtyři kombinace a tím pádem je potencionální možnost vzniku nějakého BUGu nebo bezpečnostní díry v dané vrstvě čtyřnásobná.
No a že jakmile se více rozšíří W7 s defaultně zapnutým IPV6, tak si myslím, že na sebe dají různé kombinace bezpečnostních děr a hlavně jejich využívání celkem masivně očekávat. -
Pak musíte uznat, že musíte (předpokládám dual stack) nastavovat dva firewaly, dvakrát DNS. Když zavádíte novou službu (in nebo out) musíte místo jednoho ověření udělat nejméně čtyři (ověřit všechny možné kombinace uvnitř i vně sítě). Musíte vést dvě dokumentace atd. Čili práce (pokud jí budete dělat poctivě) Vám bude trvat déle a zákazník bude platit více. No a pak tady máme různé bugy a díry kterých je potencionálně 4x (dvě na druhou) více než při jednom protokolu.
Když Vám zavolá uživatel že mu něco nejde musíte jít a ověřit místo jedné minimálně dvě kombinace spojení atd. atd. -
No pokud nečtete články pod kterými diskutujete to je s Vámi pak těžké :)
http://www.lupa.cz/serialy/pohneme-s-ipv6/
Zejména články o autokonfiguraci, bezpečnostních mechanizmech a podpora end-to-end služeb.
No a to, že pokud nemáte IPV6 konektivitu, že je lepší IPV6 povypínat není žádná novinka a ví se o tom od uvedení W7 na trh.Já nedávám za vinu protokolu že s ním mám malé zkušenosti - i když jsem možná teoreticky i prakticky vyzbrojen více než někteří (tím nemyslím zrovna Vás) IPV6-Jasánci co vykřikují po diskuzích jak je IPV6 IN a IPV4 OUT a NAPt je zhouba a pod. Nicméně stojím na zemi a jsem soudný, takže vím, že se budu muset probrodit ještě mnoha problémy než budu mít problematiku IPV6 zvládnutou stejně jako IPV4 (a ani tady se nebudu pasovat za nějakého síťového guru).
Ovšem předpokládám, že Vy jste podle všeho IPV6 zvládl za jedno krátké odpoledne (možná jste se s těmi znalostmi dokonce už narodil) a už všechno znáte, takže nezbývá než Vám pogratulovat ....ovšem přiznám se, že Vám ani za mák nevěřím, že Vás při konfiguraci IPV6 nic nezarazí a že je pro Vás vše naprostá a jednoduchá rutina.Opět se budu přít o ten počet kombinací...Vy máte ten pohled že jde o dva oddělené protokoly, které spolu vůbec nesouvisí a které jsou bezchybné....já to ovšem vidím z praktického hlediska, kdy například útočník může využít chyby v IPV6 protokolu, která sice komunikaci po IPV6 neohrozí nicméně mu to pomůže napadnout IPV4 komunikaci. Takže kombinace je kombinace (2x2=4) a uvidíte, že jakmile se dualstack dostatečně rozšíří v domácnostech a SOHO sektoru budou těhle "vychytávek" mraky.
Doomsaying je spíše to co rozpoutávají IPV6-Jasánci tím, že konzerativní a k IPV6 skeptické lidi dokážou akorát tak nařknout z toho, že něco neumí a tím jak "vyhrožují", že kdo již včera nepřešel na IPV6 je pomalu odsouzen k zániku a pod. Přitom je zcela jasné, že v současné době je ve v Evropě nesmysl se touto betaverzí IPV6 vůbec zabývat, natož do ní investovat peníze.
-
Tak mi tedy řekněte jak mám své zákazníky přesvědčit aby investovali do přechodu na IPV6 svoje peníze když jim to přinese jedině komplikace a nevýhody dualstacku kdy dvě sítě a dvojí nastavování podle mne nese (2*2=4) čtyřikrát větší nebezpečí, dva až čtyřikrát více peněz na správu sítě přičemž benefity jsou jen velmi velmi neurčité výhody v budoucnosti.
IPV6 je SHIT a hrob internetu.
ČLÁNKY DO MAILU