Vlákno názorů k článku IPv6 Mýty a skutečnost, díl I. - Jak jsme na tom od Pepa - No jo, ale u siti je to trosku...

No jo, ale u siti je to trosku jinak ne?

"Nebo je to jen plácání, protože k tématu nemáš co konkrétního řícht?"

No já myslím, že právě na toto tvůj předřečník narážel.

Tohle je pravda pouze vetsinou, ne vzdy.

Význam to opravdu nemá. Protože okna jsou sice zazděná, ale o obýváku a kuchyni stejně víte – protože nějakou jejich formu má v bytě snad každý. V tom je právě ten vtip – NATem skrýváte informace, které se dají snáz a podrobněji získat jinak.

Jen pro zajímavost. Enigma je stroj pro kódování, nikoliv pro šifrování. Dnešní šifrovací algoritmy nejsou náchylné na "plaintext attack".

NAT ale stejně tak není o skrývání identity komunikující entity. Byl vymyšlen pouze pro potřeby omezení spotřeby veřejných IP adres a pro snazší připojení sítí, které do té doby do globální sítě nebyly připojeny. Prostě byla síť postavená na privátních adresách a přes NAT ji bylo možné okamžitě připojit do internetu bez nutnosti readresace. Na to samozřejmě při návrhu IPv6 bylo myšleno také.

Proč se příslušné RFC o bezpečnosti zmiňuje až kdesi na konci?:
6. Security Considerations
Security issues are not addressed in this memo.

viz. http://tools.ietf.org/html/rfc1918
Nejspíš proto, že se o bezpečnosti při návrhu NATu vůbec nemluvilo.

Ale všechny ty informace co píšete mají téměř stejnou hodnotu, bez ohledu na to, zda jste, nebo nejste za NATem. Speciálně v případě, že za NATem budete mít malou domácí síťku. Naopak, budu mít práci usnadněnu, protože mi stačí filtrovat pouze IP vašeho NATu.

To ze je to jedno vam, neznamena ze to nema vyznam. Pro mnoho lidi to muze byt duvod proc nebydlet v prizemi. Ale hlavne pro odeleni ve firme kde se pracuje se "strategickym" materialem je to standard.

Ne, podle mé logiky nemá smysl zazdít okna, aby náhodou někdo nezjistil, že máme doma obývák a kuchyň a koupelnu. A já si opravdu myslím, že to smysl nemá, že daleko lepší ochrana je zamykat.

Já teda bezpečnost domu řeším tak, že si pořídím na dveře zámek, ne tak, že bych zazdil okna, aby náhodou někdo nezjistil, že máme doma obývák.

Vaše analogie je díivná. Vy nezamykáte (protože to dělá firewall), vy jen svůj dům zakryjete maskovací plachtou, takže bombardér nevidí, barvu vaší střechy, barvu omítky a zloděj neuvidí číslo vašeho domu na omítce, ale to mu vůbec nezabrání Váš dům vykrást.

s tim alarmem jsem to myslel jinak. Jde o vnejsi zasah do systemu ktery vyprovokuje nejakou akci. Spojenci takto napriklad za WW2 pokladaly miny na domluvene souradnice aby odposlouchavaly nemecke hlaseni a ze znalosti souradnic zjistiti denni sifrovaci klic.

Asi vetsina lidi tu vi, ze NAT neni o tom "vse ven, dovnitr nic". Tady jde o skryti ktere zarizeni komunukuje ven, prestoze vim, ze pri surfovani toho browser vykeca podstatne vic. Napriklad muze byt zajimave kdy si vas telefon aktualizuje informace o predpovedi pocasi u vas doma.

Konecnym cilem utocnika neni vas pocitac, ale penize. Bud vase, muzu vas vykrast, nebo napriklad zjistit co chysta konkurence na pristi rok.

A jsme zpět na začátku.
Tímto nastavením se ale okamžitě vracíme do stavu bez NATu, kde jsou všechny čtyři parametry spojení jednoznačně identifikované.
Ostatně jaký je rozdí, když ta super citlivá komunikace pochází z nějakého serveru uvnitř sítě a nebo z NAT serveru?

Ano, i v IPv6 síti můžete server umístit do DMZ. A jak sám píšete, filtraci paketů provádí Firewall.

Je NAT bezpečnostní prvek? Není.
Například tady http://msmvps.com/blogs/alunj/archive/2007/12/29/1425918.aspx se dozvíte, že NAT nebyl vůbec zamýšlen jako bezpečnostní prvek sítě. Ale to ostatně jistě víte při Vašich dlouholetých zkušenostech. Dále se také dozvíte, že v některých případech NAT naopak bezpečnosti háže klacky pod nohy, viz. IPSec. A takto bychom mohli pokračovat dál.

Pokud se budu držet Vašeho příkladu s alarmem, tak se pokusím pro porovnání nastínit možný průběh útoku v IPv4 s NATem a v IPv6.
Předpokládejme, že útočník má k dispozici botnet, kterým může provést DDOS útok na Vaši síť, ale o její vnitřní struktuře neví nic. Pošle Vám tedy takový e-mail, na který odpovíte. Tím získal IP adresu Vašeho NATu a navíc pravděpodobně i vnitřní IP adresu vašeho PC. to pro začátek není špatné. Už zná částečně strukturu vnitřní sítě. Tedy za předpokladu, že není příliš obskurně nakonfigurována. I když tu vůbec nepotřebuje. Spustí DDOS útok na IP toho NATu a už se o alarm nemusí starart, protože ví, že alarm, který komunikuje přes ten NAT si prostě nezakomunikuje.
A jak to bude v případě IPv6? Bohužel úplně stejné. Protože tím DDOS útokem vám nejspíš zahltí linku, takže je jedno jestli zná, nebo nezná vnitřní strukturu sítě. Ale vy se nemusíte zabývat nějakým obskurním překladem adres.

Prostě se smiřte s tím, že v IPv6 NAT nebude, protože nepřináší žádnou přidanou hodnotu. Mimochodem, v lednu bylo zveřejněno RFC zabývající se defaultním nastavením síťových prvků určených pro domácí uživatele s ohledem na bezpečnost vnitřní sítě. Pokud se tím budou výrobci řídit, tak to bude by default, jako kdyby uživatelé byli za NATem. Tj. ven povoleno vše, dovnitř pouze navázaná spojení.
http://tools.ietf.org/html/rfc6092

IPv4 asi moc neznate, jinak byste vedel, ze neni problem tunelovat IP v IP. Takze byste tech vasich 200 pocitacu schoval za jeden router. Pak by vas taky mozna napadlo, ze vse krome vnejsi IP hlavicky jde sifrovat, takze byste elegantne skryl celou vasi vnitrni sit.

Kdybyste pak znal i IPv6, tak byste vedel, ze ten protokol je narozdil od IPv4 navrzen tak, aby to vyse uvedene umel bez proprietarnich obezlicek.

a MRP a GARP a ...

To je úhel pohledu, jak vnímáte nebezpečí znalosti nějakých IP adres vnitřní sítě venkovním světem. Uznávám, že NAT je jednoduché řešení pro skrytí vnitřní IP sítě před vnějším světem, ale v reálu to stejně není nějaká velká překážka k tomu zjistit nějaké podrobnější informace o vnitřní síti a zdrojové IP.

Problém je v tom, že pokud nějaký systém komunikuje do internetu, tak stavový firewall otevírá stejně zpětná spojení na vnitřní IP a cílovému systému (nebo nějakému útočníkovi po cestě) je proto úplně jedno, jestli je IP NATovaná. Firewall zkrátka cílovému systému tu komunikaci dovnitř na tom otevřeném portu povolí. Nikdo se nebude náhodně pokoušet komunikovat na známé IP do vnitřní sítě, když je jasné, že ta komunikace bude na firewallu zakázána. (A pokud ano, tak by to dle mých zkušeností byla spíš výhoda, vědět na jakou vnitřní IP se někdo pokouší útočit)

Z pohledu bezpečnosti je totiž už i dne s NATem na IPv4 důležitější zajistit to, aby důležité systémy sami přímo do internetu vůbec nekomunikovali a pro přístup z venčí (jak píše v následujícím komentáři FOK) používají tzv. Management station stroje.

Pokud je potřeba z nějakých takto důležitých systémů zajistit přenos dat mimo vlastní síť do nějakého neznámého prostředí, mělo by se to realizovat výhradně pomocí nějakých aplikačních proxy v DMZ, nebo replikací dat do DMZ a následně dál mimo síť. To je podle mě jediné rozumné řešení.

no, upřimně řečeno, ono mnohdy není příliš velký rozdíl mezi IPv6 multicastem a broadcastem, zvlášť, když switche neumějí ty různé MLD snoopingy a pod.

V IPv6 opravdu ne. Musíte mít ale čistě IPv6 síť, jakmile máte na sítovém adapteru povolenou IPv4 nebo nějaké jiné IPv4 zařízení, zřejmě se nějaký objeví.

Zase tak nevzdělaný nejsem, jenom trošku. Jak NAT funguje a že nic nefiltruje dokonce vím, zase tak jedinečná a překvapivá informace to není zřejmě ani pro ostatní. Nastavení pravidel firewallu, které omezí veškerý provoz zvenčí a následně se povoluje jen to co chci považuji za tak standardní věc, že jsem to jaksi opoměl pro všechny rýpaly několikrát zdůraznit.
Nechme zbytečných diskuzí, třeba nám skutečně zkreslený pohled na věc, třeba ne. Praxe ukáže.

Zalezi na tom o jakou sit jde, pokud jsou tam nejaka alespon trochu citliva data tak jedine VPN. Nebo je to pocitac primo urceny pro poskytovani sluzeb ven a je v DMZ bus s verejnou IP nebo DNAT.
V kazdem pripade to IPv6 neresi, protoze pro vsechna nevyjmenovana spojeni z venku smerem dovnit konci na firewall pravidle DROP.
PS: NAT u poskytovatelu = problem pro zakaznika. Tam je to jasne, jde o uzavrene site.

Podle podobne logiky nema smysl zamykat, protoze zlodej to stejne prekona.
PS: v pripade web browseru s JS nema NAT vyznam, zjistite toho daleko vic, ale web browser neni internet.

Jaké informace o vnitřní síti skrývané pomocí NATu nejdou zjistit snadno jiným způsobem? Stačí do vnitřní sítě přes klíčenku, neaktualizovaný prohlížeč nebo jen zvědavého uživatele klikače dostat trojského koně, a získáte daleko víc informací, než co skryjete NATem. Ty informace skrývané NATem zjistíte i sledováním NATovaného provozu, pohledem do rejstříků a map atd.

A jak v NATu řešíte případ, kdy se potřebujete zvenčí připojit na to zařízení schované za NATem?

Totez co zakazem foceni v arealu. Fotka vam take zadnou skodu nedela. Duvody jsou podobne.

V IPv6 zadne broadcasty nejsou... :-)

Tohle pomuze k identifikaci OS, ne konkretniho pocitace, to uz je lepsi resit velikost paketu, skusit podstrcit navnadu napriklad zamernym spustenim napriklad alarmu, atd. Moznosti je spousta. Ale proc to utocnikovy usnadnovat a dobrovolne odhalit vnitrni strukturu site? Proc si domu davate zamek, kdyz to zlodej stejne prekona? Kazdy zpusob jak omezit postranni kanal je dobry, i kdyz neni 100% spolehlivy, zvysuje pro utocnika cenu utoku.

Opravdu by mne zajímalo, co tím „nevytrubováním“ získáte.

NAT s tim souvisi podstatne. "Každá síť je jasně definovaná adresním prostorem a mezi nimi jsou samozřejmě firewally a to bez NATu." To je presne ono, a ted me reknete, potrebujete vytrubovat mapu vnitniho usporadani site do sveta, nebu bede lepsi aby se to tvarilo jako jedna IP?

PS: vim ze NAT neni firewall, ze to neni zabezpeceni site. Ale jak to sakra chcete dokazat bez nej?

To, že schováte IP adresu, vůbec neznamená, že znemožníte identifikaci. Pořád ještě máte spoustu dalších možností – časování, způsoby generování sekvenčního čísla, rozšiřování okna, reakce na chyby…

"NATem schováte pouze polovinu identifikace." - to je pravda ale take je pravda ze prave tuhle polovinu nedokazu bez NAT skryt. NAT nestaci, ale bez nej to nekdy nejde (ne vsude je mozne pouzit proxy)

PS: veci kolem IPv4 znam uz skoro 20 let (NAT od jeho zacatku)

"Nestojím o to, aby mi výpadek jmenného serveru zrušil provoz"
Pokud jste někdy registroval doménu, tak víte, že se to řeší redundancí DNS serverů.

"nestojím o to, aby mi do sítě lezly multicasty a broadcasty ...."
Co jiného, než oddělení firewallem by jste na to chtěl nasadit?

"Do technologické sítě je potřeba přístup zvenčí (Internet, LAN)."
Pro přístup zvenčí se používají VPN koncentrátory. A pro takovéto technologické celky se vcelku úspěšně používají tzv. Management station stroje. To je počítadlo, na které se přihlásíte a až odsud máte přístup do řízené sítě. Navíc může mít tato izolovaná síť i jiný síťový protokol (IPv4, IPX/SPX, SNA, ...). Na takovém stroji múžete samozřejmě řešit přístup dle libosti.

"mít šifrované propojení na velín, který může být v normální síti"
Velín takto kritického technologického celku nemá co dělat v nezabezpečené síti!!!

"Tak a teď nastavte bezchybně firewall tak, ať se v tom vyzná i někdo jiný než vy"
V mnou popsaném řešení firewall vůbec nepotřebujete. Tedy abych byl přesný, nepotřebujete jej k ochraně daného technologického celku. Jediný firewall, který tu asi bude je ten, který chrání přístup na Management stanici, kde bude vše zakázáno, kromě VPN spojení z vnějšího světa a potom asi z vnitřní sítě pro potřeby dávkového přenosu dat. Ta management stanice bude mít dvě síťovky, jednu připojenou do firewallu a druhou do technologické sítě.
NAT alespoň ten který máte nejspíš na mysli, Vás z principu ochrání proti DOS útoku ještě méně než firewall. Ono ve skutečnosti pokud se mluví o NATu, tak se má na mysli NAT + Firewall.

Doufám, že než se dovzděláte, tak nebudete zodpovědný za nějakou podobnou síť. To by byla totiž tragédie. Alespoň co se otázky bezpečnosti týče.

Mám na starosti komunikaci v poměrně velké průmyslové firmě s mnoha oddělenými technologickými sítěmi a taky nechápu, jak s těmito požadavky souvisí NAT ??? Každá síť je jasně definovaná adresním prostorem a mezi nimi jsou samozřejmě firewally a to bez NATu. To platí nyní pro IPv4, tak by to platilo i pro IPv6. NAT by byl dokonce pro definice komunikací na takovéto síti dost velkou překážkou pro přehlednost v pravidlech na firewallech.

A to si myslíte, že Vás NAT před únikem informací postranním kanálem ochrání? Těžko. V IP sítích je každé spojení definované zdrojovou IP a portem a cílovou IP a portem. NATem schováte pouze polovinu identifikace.

Pokud jste opravdu dostatečně paranoidní, tak se poinformujte u lidí, kteří danému tématu rozumí (armáda, ...). Tam se rovněž používá šifrovaná komunikace a proti přesně takovému útoku, jaký popisujete existuje naprosto jednoduché řešení. V době informačního klidu se kanálem prostě posílá nějaký balast, aby to vypadalo, že se komunikuje.

A pokud ani to nebude dostačující, tak můžete měnit IP adresy těch svých zařízení. Nebo třeba použít proxy server.

Než začnete NAT prohlašovat za bezpečnostní zařízení, zkuste si někde vyhledat vysvětlení pojmů jako DNAT, SNAT, PNAT, symetrický NAT. Možná budete zděšen.

Některé z vašich bodů bude NAT komplikovat, žádný nezjednoduší. Takže když se vyhnete NATu, bude konfigurace celkově jednodušší.

Vy tam někde vidíte něco, co by záviselo na NATu? Já tedy vůbec.

Ono vše vypadá strašně jednoduše, než se s tím člověk doopravdy potká. Přípklad technologické sítě a požadavků na ni:
- Musí být zajištěn bezproblémový provoz technologie. V některých provozech není odstávka myslitelná. Znovunahození ropné plošiny po výpadku trvá desítky hodin, odstavený reaktor nemůžede obratem opět nahodit a namíchaný roztok krátkodobou použitelností za pár miliónů můžete kvůli výpadku vyhodit....
- Takže budu odkazovat zařízení na sebe přímo IP adresou. Nestojím o to, aby mi výpadek jmenného serveru zrušil provoz. Zařízení tedy potřebují pevné IP. Ty se nesmí "hádat" s okolním světem.
- Technologická síť je opravdu jen a pouze pro technologii, nestojím o to, aby mi do sítě lezly multicasty a broadcasty a cokoli nežádoucího z okolí, co mi může dělat neplechu.
- Do technologické sítě je potřeba přístup zvenčí (Internet, LAN). Málokdy složitější technologii spravuje nějaký zaměstnanec dané firmy ale dost často její dodavatel. Ten nemusí být jen jeden, technologie se může inovovat a doplňovat. Každého dodavatele pustím, ať už SSH nebo VPN jen na zařízení na která se má dostat. Nestojím o to, aby se šťroural kde nemá.
- Kromě servisu je potřeba z firemní LAN zabezpečným spojením tahat data např. z MySQL na technologickém serveru, mít šifrované propojení na velín, který může být v normální síti a spoustu dalších požadavků.

Tak a teď nastavte bezchybně firewall tak, ať se v tom vyzná i někdo jiný než vy, zajistěte individuální adresování technologie s IPv6, zamezte kolizím a garnatujte svému zaměstnavateli, že jste nikde nenechali skulinku. Zajistěte firewall proti DOS (DDOS, obecně Flood) útokům, s tím, že mohou přijít i z vlastní LAN. A to bez NATu. Příjemnou zábavu. Až to vyřešíte dejte vědět, strašně rád se přiučím.

NAT ten postranní kanál nijak neskryje. Skryje konkrétní IP adresy, ale to je mezi těmi informacemi prkotina.

Jediný rozdíl je v tom, že u firewallu ten postranní kanál jako správce hned vidíte, ale spousta „správců“ si neuvědomuje, že u NATu existuje ten postranní kanál. Problém je, že si taky spousta lidí myslí, že NAT nahrazuje firewall, takže na správné nastavení firewallu se vykašlou – a přitom je pak možné využitím vlastností NATu navázat i komunikaci, která by měla být filtrovaná, dokonce někdy i zvenku dovnitř.

A zase ... placate nesmysly, takovyho sitare ktery ma takto zasadni neznalosti bych na minutu vyhodil.

a) NAT neskryje vubec nic, tech postranich kanalu mate tisice - napr kazdy prohlizec s povolenym scriptovanim (90%) na sebe praskne vnitrni IP a spoustu dalsich informaci.

NAT je nastroj, jak pripojit do netu vice zarizeni, kdyz mam nedostatek IP adres. NIC VIC.

b) adresy se mohou v ramci vaseho prefixu prakticky libovolne casto menit, takze zvenku pozna dotycny kulovy jestli to, co prave nekam komunikuje je to, co kumunikovali pred minutou.

d) pokud chci provozovat utajeny provoz kamsi, tak se na to pouzije sifrovany tunel.

e) na siti kterou spravuju nepotrebuju aby zarizeni melo nejakou konkretni IP, existuje hromada jinych zpusobu jak zarizeni identifikovat.

=> snazite se jen vymyslet naprosto debilni a v praxi neexistujici duvod, proc pouzivat NAT.

tak vy žádnou linku nemáte a příklad jste si vycucal z prstu. Jestli máte problémy s postranním kanálem, tak prostě šifrujte tunel. Tam se vám vnitřní adresy neobjeví.

To byl jen priklad, zadnou takovou linku nemam a bez VPN je to pitomost.
Nicmene nenni to odpoved na problem, kterym je unik informaci pres postrani kanal predstavovany IP adresou. Argumet ze totez zjisti utocnik inspekci paketu neberu, mluvim o dokonale nastavenem firewalu a sifrovani. Bez NAT to nejde

pokud máte totiž někde výrobní linku posílající nějaká data na server, tak vám NAT stejně nepomůže, pokud ten útočník vidí provoz, tak vidí i dovnitř paketů a pak už si velmi lehce odvodí, co je výrobní linka a co je zaměstnanec bloudící po pornostránkách.

tak pokud chcete provozovat takový provoz přes standardní internet bez VPN, tak jste směšný.

Samotny NAT bez firewalu na to nestaci, ale bez nej to udelat nejde.
Predstavte si sit, ktera obsahuje spoustu pocitacu nebo technologickych zarizeni. Kazde zarizeni posila svoje hodnoty (nekdy se tomu rika telemetrie) samozrejme sifrovane kamsi na server na internetu. Nastavite pravidla firewalu ze kazda z masinek se muze pripojit pouze na server, prichozi spojeni konci na DROP. Z pohledu bezpecnosti podle vas idelani, ale bohuzel je tu "postranni kanal" (zjistete si co ten termin znamena), kdy se ven dostavaji adresy pocitacu kdy a kdo komunikuje. Utocnik muze zjistit kdy je vyrobni linka v provozu, jak dlouho, jake je vytizeni, kdy chodeji zamestanci do prace atd. Navrhnete jine reseni nez NAT.

VPN lze pouzit pouze v popsanem pripade, zkuste totez pokud dodavetel technologie zajistuje napriklad i distribuovane servery pro aktualizace.

IPv6 Privacy extensions take neni reseni, uvnitr zabezpecene site potrebujete nezpochybnitelne vedet kdo je kdo.

Nejaky jiny napad krome NAT?

a to si vážně myslíte, že NAT je prostředek k oddělení síťových aplikací od okolního světa? :-)))

Pozor na zamenu pojmu NAT a Firewall. Firewally samozrejme IPv6 podporuje, pouze neni potreba schovavat x IP adres za jednu verejnou.

Jen pro úplnost, NAT v IPv6 má určitě opodstatnění, Na toto téma už bylo napsáno hodně. Vždy se najdou síťové aplikace, které je potřeba oddělit od okolního světa. Nelíbí se mi moc představa, že bych měl spravovat například 200 síťových zařízení řídících technologii na výrobu léků nebo jadernou elektrárnu a měl je zapojené tak, že každý bude mít vlastní pravidla na firewallu. A co zařízení, která nebudou IPv6 podporovat, tam bude také docela problém. Zmíněný NAT64 je určen k propojení sítí IPv6 a IPv4, není určen pro klasické natování v dnešním slova smyslu.

Ne že bych rozuměl tvé reakci. Pokud víš jak na to, zřejmě jsi měl všem těm hloupým specialistům a liden stanovujícím standardy geniálně poradit, oni by určitě hned všechny tvé připomínky hned akceptovali. Nebo je to jen plácání, protože k tématu nemáš co konkrétního řícht?
Takže podle tebe bych si měl vymyslet vlastní síťový protokol a odpovídající atandardy, vyrobit zařízení, která s nimi budou fungovat a přesvědčit všechny ostatní aby to používali. Nebo jak to bylo myšleno? Já ale nechci nic vyvíjet a vymýšlet. Pokud napíšu do fóra že něco vidím jako problém, očekávám, že mi třeba někdo chytřejší či znalejší poradí řešení které já nenašel. Průpovídky o pomocném orgánu mezi ušima jsou příkladem reakce "musím něco napsat ať vypadám chytře ale nevím co".

Blah, dalsi co nechape, ze NAT do IPv6 nepatri a nikdy patrit nebude.

Jednim z duvodu vyvoje IPv6 bylo prave odstraneni tohodle hnusu.

>... po 15 letech vývoje bylo vše okolo dotaženo do konce...

V sitovani je jaksi zvykem nespolehat, ze se veci vyresi magicky samy. Pokud hledas pomocny organ, hledej ho mezi svyma usima.
Osvedceny postup je najit skupinu lidi s podobnym problemem a resit. Managersky je zkontrolovat jestli budou problemy driv nez za dve ctvrtleti a do te doby zvanit.
Moc sympatii na technickem serveru nenajdes.

Díky za tento "pilotní" díl seriálu. Konečně se snad doškáme článků, které nebudou vidět problematiku IPv6 černobíle a pomohou orientovat se v problematice všem nešťastníkům "odsouzeným" k přechodu z IPv4 na IPv6 . Proti IPv6 bych nic nenamítal pokud by, jak je zmíněno ve článku, po 15 letech vývoje bylo vše okolo dotaženo do konce. Příklad nepoužitelného NAT-PT a nedotaženého NAT64 jako jeho nástupce mluví za vše. A co zařízení v LAN, která umí pouze IPv4, například kamerové systémy, měřící a regulační technika nebo celé technologie? Prostě vezmu nemalou částku a koupím vše znovu, Ale na trhu ještě nabídka takových zařízení není... Nezájem o přechod na IPv6 je jen logickým důsledkem nekompatibility, kdy se "pachatelé" IPv6 rozhodli ignorovat existující protokoly....