Názory k článku IPv6 Mýty a skutečnost, díl VIII. - Přechodové mechanizmy
-
Zprovoznění 6to4 na CZ-NIC je bezesporu záslužnou záležistostí, která aspoň tlumí problémy spojené s provozem 6to4. Nicméně všechny možné problémy spojené s touto technikou vedly k tomu, že na posledním zasedání IETF (minulý týden v Praze) bylo rámcově podstoupeno převedení technologie 6to4 do stavu historic (http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic-01). Bude následovat další proces zpracování draftu, nicméně trend byl jasně naznačen - do budoucna s 6to4 příliš počítat nelze.
Obecně k tomuto tématu lze doporučit prezentace s související z jednání IETF http://tools.ietf.org/wg/v6ops/agenda?item=agenda80.html. Případně pro ty odolnější zvukový záznam, který je k nalezeni na http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch3-thurs-am.mp3, http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch3-thur-pm.mp3.1.
V rámci v6ops byla právě problematika 6to4 poměrně žhavým tématem. K celkovému negativnímu postoji jistě příspělo vystoupení Geoffa Hustona, které má mezi komunitou jistě velkou váhu.
-
NCP/TCP (neregistrovaný)
No, něco podobného už tu bylo… a bylo to efektivní. Ovšem tehdy Internet vypadal o hodně jinak než dnes.
http://www.faqs.org/rfcs/rfc801.html -
x (neregistrovaný)
Systemovy sluzby u XP na IPv6 neposlouchaji, to ale neznamena, ze vsechny normalni aplikace pres to nebezi - kdyz si nainstalujete ftp server, bude vyuzivat IPv6, utorrent taktez, firefox, ....
Co se RDP a dalsich tejce, je to jako spousta jinych veci ciste veci licencni politiky - XP taky neumi bez zasahu vic nez 4GB RAM (stejne jako VGisty a 7dmi), pritom serverovy widle to umi (mluvim ve vsech pripadech o 32bit systemech). Uprava by byla trivialni, ale pro M$ je vyhodnejsi, kdyz si koupite novy widle.
-
no (neregistrovaný)
Nesouhlasím, jak jsem psal, ale dobře. Pak se aspoň nikdo nedivte, že nasazení IPv6 se bude táhnout jako smrad léta, a hlavně nesepsávajte (od slova sepsut) kritiky, co tuhle alfa verzi nasadit nechtějí, a ještě dlouho ji nenasadí, protože mají pravdu: Zatím je to šmejd a nedopečenej pokus, vůbec ne nic komplexního nasazení hodnýho. A uživatelé za to rozhodně nemůžou, to jen odborníci se nemůžou dohodnout nebo na to kašlou. Jedno nebo druhý má ovšem stejnej výsledek.
-
ZP (neregistrovaný)
Tak ona to neni alfaverze, ono to funguje, ano, rada vyrobcu tu a tam neco nepodporuje, ale to vycitejte tem vyrobcum, stejne veci pro IPv4, ktere se masove pouziva 15 let, zacali podporovat pred tremi ci peti lety. Jedina akceptovatelna vytka je k tomu sireni adres nameserveru pri autoconfigu, ale to zase v dual-stack prostredi tolik nevadi (proste si tam ty sestkove adresy DNS serveru nasypete pomoci "ctyrkoveho" DHCP) a az budete nekdy casem IPv4 rusit, tak uz tuhle vec ra/nd podporovat bude.
-
ondra.novacisko.cz (neregistrovaný)
Ad 3) Už delší čas se chystám s IPv6 experimentovat. Zatím jsem narazil na dva teoreticky kladné body
1) WinInet defaultně IPv6 podporuje, pokud mu někdo předhodí request na IPv6 server, tak si DNSko přeloží a naváže spojení. Na vnějším rozhraní pak aplikace nemá šanci poznat, zda spojení jde přes IPv4, IPv6, proxyserver, jestli náhodou nejede po SSL, a kýho čerta.
2) Mám pocit, že otevření portu na IPv4 otevře port i na IPv6, akorát accept bude v SOCKADDR_IN vracet nějakou šílenost. Mnohem pravděpodobněji to funguje opačně, pokud aplikace otevře port na IPv6, dorazí tam i IPv4 připojení. Typuji, že stejně tak lze udělat connect na IPv4 adresu přes IPv6 socket, pokud je adresa v rozsahu vyhrazeném pro IPv4 adresy.
-
Hynek (neregistrovaný)
No, přechodové mechanismy a zpětná kompatibilita byla zkrátka vyřešena špatně. Navíc se o tom vědělo dávno, viz např. http://cr.yp.to/djbdns/ipv6mess.html
IPv6 odpovídá na jeden důležitý problém, nedostatek adresního prostoru, ale bez toho všeho ostatního, co IPv6 poskytuje, bychom mohli žít - já osobně raději než vysoká cena za implementaci stávajícího IPv6. Co IPv6 neposkytuje, a bylo by potřeba, jsou různé anti-spoofing apod. bezpečnostní prvky, naopak mi přijde že v tomhle nové problémy přidává - viz ostatně tento seriál.
-
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.
-
Petr Bedle (neregistrovaný)
IPSec v tomto smeru moc neresi. Pokud mam zamorene Windowsy tak si skrze stack vyrobim zdrojovou adresu jaka se mi hodi a IPSec to vesele zasifruje.
Druha vec je autentizace, tam by se o tom dalo uvazovat o podepisovani adres ale je to absolutne nepouzitelne napriklad pro podepisovani RA, ND, DAD.
-
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.
-
ondra.novacisko.cz (neregistrovaný)
Postupně zkoušet připojení je hoooodně na dlouho. Tož už doporučuju to pustit paralelně a sebrat první připojení, které se ozve. Ani nejsou potřeba thready, stačí asynchroní connect a pak select a zbytek descriptorů pozavírat. Jo nevýhodou je, že to vyrobí docela solidní trafic u serveru, ale to není moje starost :-D
Né dobře, aspoň tedy vzít dva seznamy IPv4 a IPv6 a ty zkoušet postupně paralelně (tedy vždy jedno spojení v rámci stacku, a tedy maximálně dva connecty současně)
-
Sob (neregistrovaný)
1) Mapovany adresy ve Windows podporovany jsou, i kdyz az od NT6. Staci pres setsockopt() vypnout IPV6_V6ONLY. Ve starsich verzich nebyly proste proto, ze oba protokoly byly implementovany jako uplne nezavisly, takze prehazovat (mapovat) pripojeni dost dobre neslo.
2) Hromada problemu s prioritou protokolu by odpadla, kdyby aplikace nevymyslely zadny vlastni genialni reseni a jednoduse pouzivaly getaddrinfo(). Staci zavolat, a pak postupne zkouset jednu adresu po druhy, dokud se pripojeni nepodari. To je ostatne rozumna vec i bez IPv6, protoze tradicni pristup, kdy server ma sice deset adres, ale klient to vzda hned jak se nepodari pripojit k prvni, je docela trapnej. ;) Windows navic inteligentne seradi adresy podle toho, jakou konektivitu maji k dispozici. Takze napr. nehrozi, aby se primarne zkouselo pripojeni pres IPv6, kdyz ma klient jen Teredo.
3) Prechodovym mechanismum fandim, hlavne 6to4. Diky nemu mam IPv6 uz skoro deset let. Kdybych mel cekat na ISP, nez zavede nativni, tak nemam nic doted, protoze neverim, ze by se snazil i jen o chlup vic nez ted. Vzdyt prece tech volnych IPv4 adres bylo porad tolik a vycerpani v nedohlednu...
4) Naopak mi vubec neni sympaticky DNS64. NAT64 v pohode, k tomu to smeruje, ze az zustane par IPv4-only zpatecniku, tak aby se k nim dalo dostat. Ale vymysleni neexistujich adres je cunarna. Kdyz uz neco takovyho delat, tak radsi primo v OS a namapovat IPv4 do nejakyho konkretniho, vsude stejnyho prefixu, kterej si ISP na hranici svy site odchyti a zNAT64uje.
-
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 :-)
-
Vladimír (neregistrovaný)
Autor zopakoval všeobecně známou věc. Spíš bych uvítal malou analýzu
proč tomu tak je.
Dobrou cestu ukázalo CZ-NIC, kdy před časem zprovoznilo 6to4 relay
a nyní i teredo relay. Když pominu počáteční ping (64ms), kterým se
navazuje spojení, tak ostatní pingy na lupu.cz se teď pohybují mezi
devíti až jedenácti milisekundami proti 45 ms v minulosti. Tomu se nedá
nic vytknout nebo snad ano? -
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.
-
Ano v tomto máte naprostou pravdu. Uvedeným nastavením je možné potlačit dotazy na AAAA záznamy. Obávam se ovšem, že tímto nastavením ztratíte přístup na IPv6 only weby (které pravda zatím jaksi nejsou). Toto nastavení je pro běžného uživatele (např. sekretářku) poměrně hodně zamaskované.
Osobně bych ocenil aby použitý protokol bylo možné ovlivnit například formátem URL anebo snadno dostupným přepínačem/tlačitkem.
Takto je diagnostika u běžného užívatele poměrně problematická už jen proto, že vám není schopen zjistit zda na příslušný web přistupuje protokolem IPv4 anebo IPv6.
Přesto děkuji za věcnou připomínku. Ještě pro úplnost doplním, že s nastavením souvisí volba network.dns.ipv4OnlyDomains, kde je možno výčtem definovat domény, kde se vždy přispupuje po IPv4.
-
1) S mapováním adres máte pravdu. Novější verze Windows (Vista, 7) již mapované adresy podporují, viz. http://msdn.microsoft.com/en-us/library/bb513665%28v=vs.85%29.aspx
2) S tím by až tak problém nebyl. Řada aplikací se takto chová. Problémem je dostatečně rychlá identifikace, že cíl je daným protokolem (či obecně na dané IP adrese) nedotupný. Pokud jsou pakety zahozeny firewallem aniž by byla vegenerována ICPM zpráva anebo pakety někde mizí vlivem chyby v routingu, tak je třeba počkat na timeout. Poblémem se zabýva právě draft draft-ietf-v6ops-happy-eyeballs-01 (http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-01), který věc řeší současným navazováním více spojení. Související prezentace je k dispozici na http://tools.ietf.org/agenda/80/slides/v6ops-21.pptx .
3) Co se týče 6to4 tak vás asi nepotěším. Do budoucna s touto technologii příliš počítat nelze, nicméně do té doby snad už bude většina ISP podporovat nativní IPv6, takže problém bude bezpředmětný.
4) Namapování IPv4 vždy do stejného prefixu vyžaduje podporu na všech klientských systémech, takže zde vidím jistý problém v masovém rozšíření. Jinak souhlasím, že myšlenka to není uplně špatná akorát tady měla být tak před 10 lety, aby současné systémy již tuto techniku podporovaly. Jinak v samotném NAT64 je hned několik, na první pohled ne zcela zřejmých, záludností. Jak například řešit fragmentaci, překlad kompletního ICMP na ICMPv6 atd. Pozitivní je, že již existují implementace (Ecdysis, Juniper, ci pozůstatek NAT-PT na zařízeních CISCO), takže technologie se asi bude docela využívat. Mnohé diskuse tomu nasvědčují.
-
Sob (neregistrovaný)
2) Bohuzel ne uplne vsechny aplikace to tak delaji. Opravdu se najdou takovy, ktery zkusi IPv6 a v pripade neuspechu uz na IPv4 kaslou. A rozdil mezi (velmi) otravnym zdrzenim a kompletnim selhanim je zasadni. Ale do budoucna by se to melo zlepsovat. Jak se postupne zacne brat IPv6 jako bezna vec a ne jen takova hracka bokem, tak se pak temer vzdy chyti hned prvni adresa.
3) Je to prechodovej mechanismus, od zacatku se pocita s tim, ze casem zmizi. Sice bych zatim s jeho rusenim zbytecne nespechal, ale ono to nebude tak zhavy, par let urcite jeste vydrzi.
4) Trosku vic jsem se zacetl a ono uz to existuje, prefix 64:ff9b::/96 (RFC 6052, sekce 2.1). I kdyz to neni tak uplne ono, protoze ISP muze pouzit prefix vlastni, a tak na to nejde spolihat. Coz je skoda, protoze mi prijde, ze snadna detekce takovych prekladanych adres, ktery nejsou plnohodnotny IPv6, by vubec nebyla spatna.
-
ZP (neregistrovaný)
1. prechodove mechanismy ve forme vsemoznych 6to4, Teredo apod. nejsou dulezitym prvkem, jsou prvkem skodlivym. Pokud je mozne IPv6 tunelovat nad IPv4, snizuje to tlak na nativni implementaci, ktera, jak autor sam uvadi, jako jedina relativne rozumne funguje. Krome toho celou problematiku IPv6 tyto prechodove mechanismy nesmyslne komplikuji, kazdy, kdo o IPv6 pise, se jimi zabyva namisto toho, aby se zabyval tim, jak nakonfigurovat IPv6 spolehlive (nektere platformy vyzaduji v pripade staticke konfigurace explicitni vypnuti autokonfigurace, protoze jinak si drive ci pozdeji vymysli vlastni zcela nefunkcni default route, kterou zacnou pouzivat namisto te nakonfigurovane -- to je napriklad problem starsich linuxovych jader. Nikde se to ovsem onen sestkovy zacatecnik nedozvi a pak se divi, proc to uz zase nefunguje).
2. koexistence IPv6 vedle IPv4 prinasi ten problem, ze vetsina subjektu, provozujicich dual stack sit, ji sice provozuje, ale funkcnost IPv6 obvykle neni dohledovana. Je to dano tim, ze to je proste druhy protokol s nejakym marginalnim tokem, ktery lze kdykoli nahradit a pristupuje se k nemu jako k cemusi zbytnemu. To samozrejme neni problem designu IPv6, ale pristupu operatoru, dodavatelu dohledovych systemu atd. Pokud bychom se zitra rozhodli podporu IPv4 zrusit, spolehlivost IPv6 se okamzite zlepsi o nekolik radu.
3. Co se tyce Windows a aplikaci -- byl jsem az prekvapen, kdyz jsem kdysi pre lety nainstaloval do WinXP podporu pro IPv6, jak se s tim vicemene vsechny aplikace, ktere jsem na XP tehdy pouzival, vyrovnaly a zacaly ten protokol naprosto prirozene pouzivat. Na Linuxu to tak snadne nebylo, tam jsem vetsinu veci musel kompilovat znovu s podporou AF_INET6.
Cili, abychom to shrnuli -- nekomplikovat sestku nejakymi prechodovymi mechanismy vyjma dual stack, ten, kdo dual stack provozuje, by k tomu mel pristupovat tak, ze provozuje dve site a ne jednu a s temi aplikacemi, pokud nejsou deset let stare, to neni zase takovy problem.
-
no (neregistrovaný)
Mě spíš překvapuje, že komunita za těch několik let už dávno nevyřešila všechny ty věci a problémy (a chyby), které zaznívají v tomto seriálu (a že jich není málo), a protokol není použitelný zcela plně už dnes. Pak by se i dnešní hw vyráběl s podporou prakticky stable verze IPv6, stejně jako to tak je např. u Wi-Fi a jeho šifrování, a podpora by mohla narůstat geometrickou řadou.
Zatímco co tak čtu tenhle seriál, tak takovejch věcí je zatím nevyřešenejch nebo dokonce vyřešenejch blbě + všude samý "zkusíme tohle, aha, mrtvá větev, tak jinak..." nebo "existuje pouze testovací implementace této zásadní funkčnosti, kterou na koleně napsal maník z garáže ve verzi 0.1 alpha", že zatím by třeba firmy musely bejt padlý na hlavu, aby si něco takovýho bugovýho a nedořešenýho nechaly kolovat sítí.
To se opravdu nemůže s těma problémama a chybama hejbnout, a všechny je konečně uzavřít rozumným řešením? To se to bude táhnout jak šnek, léta? Kdyby takhle pracovali např. kodéři linuxovýho jádra, tak jsme ještě na stromech... -
sojkovec (neregistrovaný)
Ale ona je to opravdu takova pitoma kauzalni smycka, zacarovanej kruh... Bejvavalo by nejlip, kdyby se IPv6 zacalo hromadne nasazovat v dobach, kdy internet byl jen akademickou zalibou a spis nadstandardem nez samozrejmosti (a ano, opravdu je tak stary). Jo, ted jsem po bitve general Laudon :-) Ale ona to vyresi evoluce sama jako vsechno. Az se zacnou IPv4 rozsahy jeste vice tristit, zacne se s nima kseftovat a globalni routovaci tabulky pujdou takrikajic do kopru a s nimi veskera efektivita, nic jinyho nezbyde. Takze neni duvod k panice, vono se to nak vystribri, rekl byl Holzmann.
-
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.
-
Možná někoho napadne, že než velmi bolestivej přechod trvající několik desítek let by bylo doplnit IPV4 o nějakou tu adresní extenzi a na iPV6 se vykašlat.
Co se týče toho "po vojně generál" přesně tak uvažovali pachatelé IPV6shitu...totiž že na IPV6 lidé přejdou sami a rádi (před 16 lety to prostě bylo jiné) tím, že vyřeší některé neduhy IPV4..jenže IPV4 se vyvíjel dál a jaksi ploloživý/polomrtvý protokol IPV6 je nyní víceméně zastaralý.
Rozsah fragmentace IPV4 rozsahů v dnešní podobě by před 16 lety používaný HW nestrávil a za 5 let zase stráví mnohem víc.
Osobně si myslím, že IPV6 bude slepou kolejí. -
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