Názory k článku IPv6 Mýty a skutečnost, díl I. - Jak jsme na tom

Milý ondra.novacisko.cz,
přesně takhle jsem já již před řadou let tady argumentoval, že IPv6 je pragmatický nesmysl, neboť nerespektuje vývoj a skutečnosti v IPV4-Internetu. A všichni teoretici na mě uštěkali přesně jako nyní.
IPv6 je ukázka upachtěného protokolu bez zásadní myšlenky na kompatibilitu s IPv4. Proto se nemůže 15 let prosadit a moc by mě zajímalo, jak to jsou schopni jeho obhájci vyvrátit. Poukazování na to, že implementátoři a správci jsou přihlouplí, když nerozvíjí IPv6, právě ukazuje na to, jak nevhodně je IPv6 navrženo, protože průměrní lidé ho nejsou schopni pochopit a zrealizovat. Ale právě na těchto lidech stojí rozvoj celého Internetu, což si pár zaslepených teoretiků při návrhu IPv6 zapomnělo uvědomit. Hlavně že oni si připadají daleko chytřejší než ostatní - akorát že jim nikdo nechce nebo není schopen jejich výtvory zrealizovat.

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

Jednim z duvodu vyvoje IPv6 bylo prave odstraneni tohodle hnusu.

Proč musí weby, který jedou na IPv4 přejít na IPv6?

Jaktože ten přechod je tak složitý? Můžete mi prosím vás říct pár příkladů, co se musí udělat, abych si konečně uvědomil ten problém přechodu? :-)

Díky

Nesmyslne proc? Argument s MAC adresou je - ehm, zvlastni. IPv6 je protokol treti vrstvy, na druhe vrstve muze byt jakekoliv medium a ne zrovna ethernet (se 48bit MAC), kupodivu... :)) EUI64 neni zdaleka jen pro ethernet...
A potreba curat proti vetru od tebe dnes uz neprekvapi nikoho... :)

Bohužel ještě nikdo nepřišel na to, jak rozšířit adresový prostor a současně zachovat zpětnou kompatibilitu. Ale můžete se u IETF, Cisca, Juniperu nebo někoho dalšího přihlásit se svým geniálním nápadem, tam totiž pracují ti teoretici, kteří nemají s praxí nic společného.

možná se zabýváte programováním, ale to je jako byste chtěl kombajnérovi radit jak jezdit s kombajnem, když vy jezdíte s jeřábem.

I velké routery mají paměť maximálně na 1M záznamů v routovacích tabulkách. Navíc se dost často nepoužívá klasická RAM, ale TCAM, která vám vyplivne výsledek během jednoho taktu procesoru.

A vy si zkuste vypočítat, jaký algoritmus pro vyhledávání byste musel použít, abyste dokázal vytáhnout z takové tabulky 400 milionů správných záznamů za sekundu - tj. vytáhněte jeden záznam za 10 taktů procesoru.

Protokol pro vyhledávání nejlepších cest je to nejmenší, to zvládne každý procesor s prstem v nose. Je to záležitost control plane, ale ten největší problém je v data plane, kam se ty správně vypočítané cesty překopírovávají.

jestli myslíte vyhledávání v TCAM, která má opravdu složitost 1, tak tam jste bohužel omezen technickými možnostmi konstrukce CAM pamětí. Pokud myslíte vyhledávání pomocí hashovacích funkcí, tak to taky není tak triviální. Pokud myslíte, že vyrobíte pevnou tabulku, tak si uvědomte, že musíte vyhledat podle nejdelší netmasky. Ukažte mi ten algoritmus, ať se můžeme bavit konkrétně.

No a s tím vyměňováním sítí - to jste pěkný vtipálek. Jak chcete přinutit všechny uživatele, aby si přečíslovali svoje sítě jenom proto, aby ubyl jeden záznam někde v BGP tabulkách? Jste opravdu spadl z višně.

Můžete mi říct, které normální vyhledávání má složitost 1?

"No osobně mi IPv6 přijde tak 10x složitější, než IPv4"

To ale není chyba IPv6, ale vaše.

"žerou větší výkon a víc topí :-)"

Nějaký zdroj?

Me by spis zajimalo % komunikace po IPv6 po ty lokalni siti. Komunikace smerem ven je celkem nezajimava, protoze hodne zavisi na DNS a dalsich okolnostech. Ovsem problem vidim v tom, ze ac RFC rika pravy opak, spousta aplikaci pouzije primarne IPv4 a to i v pripade, ze existuje IPv6 konektivita a protistrana ji disponuje taktez.
Ciste teoreticky by v takove siti melo to % odpovidat tomu grafu ohledne pridelenych adres, ale ciste prakticky to bude IMO diametralne jinde.

BTW: Mate to dnes poranu nejake zabrzdene, obcas se ani stranka nenacte cela ... (a ne neni to na moji strane, jinde mi vse funguje)

Nezdá se mi to tak: přesunul jsem Windows Update Services na server Windows 2008R2 a zároveň jsem mu dal i IPv6 adresu. Výsledkem je, že všechan Win Vista+ se zaregistrovala přes IPv6 a skoro všechna WinXP, na kterých je IPv6 taky.
Potíž může být v tom, že WinXP, ač mají IPv6, tak přes IPv6 sice komunikují, ale služby na IPv6 neposlouchají - což je celkem logické, protože IPv6 je tam jen dobastlené a aplikace s tím nepočítají, takže by je asi trošku překvapila IP adresa v jiném formátu.

Weby nemusí. Ale státní weby ano. A to z důvodů toho, že za chvíli třeba v Číně IPv4 adresy nebudou a jak se pak dostane takový nebohý Číňan na web našeho ministerstva zahraničí?

Ale když se podíváš na http://213.251.145.96/Mirrors.html ,tak maj u některých napsaný IPv6 a v pohodě se tam můžeš dostat, tak jaktože?

Myslel jsem právě to přidělení IPv6 weboovému serveru. Nějak mi nepřišlo důležité se zabývat přímo internetovými stránkami, protože to už je pak boj toho správce webu, aby si rozšířil tabulky v DTB a právě to mi nepřijde jako velký problém. Proto mi přijde, že mi stálo něco uchází, když je okolo toho takový povyk.

já klidně, když mám IPv6 adresu :-)

No a ostatní asi proto, že jim IPv6 prostě běží přes nějaký Teredo tunel a oni si ani neuvědomují, jakým způsobem to narušuje jejich bezpečnost. Mimochodem, ikdyž jste za NATem, tak s Teredo tunelem máte problém, protože tam jste úplně otevření a bez ochrany.

IPv6 adresa v databazi efektivne = 16 bajtu. V cem je problem? ;) Nepodareni konverze z retezce na cislo hrozi jak u IPv4, tak u IPv6 - ale to je blbost implementujiciho programatora, ne vada IPv6 ;)

Otazka je spatne formulovana. Nikdo nikoho netlaci k prechodu na IPv6 (coz vyznamove znamena ze serveru vyhodit IPv4 a mit jen IPv6). Ve skutecnosti se bavime jen o tom, aby weby byly pristupne take po IPv6 (nejen po IPv4). Bohuzel zadny "killer" IPv6-only web tu nemame... to by se ISP asi jinak s implementaci otaceli... :-)

Problem neni samotny webserver - ty bezne pouzivane IPv6 podporuji bez problemu davno. Problem jsou provozovane aplikace a jiz zminene potreby logovani v nich - kde programatori - ac jde o aplikace casto stare jen jednotky let ignorovali elementarni existenci IPv6...a dnes se vsichni "divi" a delaji z toho problem. Trosku mi to pripomina paniku kolem problemu Y2k... to take byla spousta programatoru prekvapena ;)

Ano, presne totez bys mi rikal v roce 1992, kdybych oznacoval za neefektivni classful routing :-)

To vypadá na velmi přínosnou sérii článků. Už se těším.

K některým naznačeným tematickým celkům bych měl nápady, co bych tam rád viděl rozebrané:

# Lepší podpora end-to-end služeb - jak se na toto díváte z pohledu přítomnosti stavového firewallu, u kterého v korporátním prostředí očekávám blokování příchozích spojení. Nemusí jít jen o firemní prostředí, ale takové nastavení bych očekával i u různých free wifi sítí, a to např. kvůli omezení p2p sdílecích programů. Podpora end-to-end bude jistě lepší, ale jak to s ní bude v praxi?

# Podpora autokonfigurace - v jakém je to reálně stavu na WinXP / Win7, pokud chci docílit stejného chování jako u v4 DHCP se statickým přidělováním podle MAC. Hlavně ve vztahu k privacy ext. Privacy extensions bych rád využil pro komunikaci "ven", aby vnější pozorovatel nemohl sledovat jednotlivé PC, ale v rámci LAN bych zase o tom chtěl mít přehled... jak na to?

# Podpora multicastu a anycast provozu - lze očekávat podporu u tranzitních operátorů? Resp. jsou nějaké zkušenosti s tímto z komerčních sítí? Ze strany tranzitních operátorů jsem slyšel o problémech s účtováním / vyhrazením kapacity na páteřních linkách v případě multicastu.

# Podpora mobility - tady bych rád viděl popsáno, jak to přesně funguje, zejména v jakých případech musí téct veškerý provoz přes home gateway, což je kapacitně problém. MobileIP bych nejvíce využil zase v těch typicky "zafirewallovaných" sítích, kde asi nějakou extra podporu mobility nemůžu čekat. Nebo je to "povinná" / integrální součást IPv6 konfigurace. Ono IPv6 toho slibuje velmi mnoho, ale rád bych viděl, co je "povinně" implementováno, a hlavně u čeho lze očekávat, že to v každé druhé síti nebude v konfiguraci vypnuto.

Ale nejde jen o system, existuje spousta aplikaci, dokonce i FF napriklad umoznuje nastavit protokol, ktery bude pouzivan primarne, i kdyz default je podle rfc.

To ze na XP se neda pripojit pres IPv6 (napr na RDP) je vec jina a s "dobastlenym" protokolem to ma malo spolecneho, protoze ten bez problemu funguje (FF a dalsi vpohode po IPv6 z XP komunikuji). To je ciste vec nejakyho backportu novejsi verze RDP a dalsich. A IMO se k tomu M$, pokud ho nebude tlacit hodne velky zakaznik, postavi tak, ze si kupte novy OS. Pricemz backport/patch na IPv6 by nebyl zadny zasadni problem (existujou na to "home made" leciva).

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

Problém je v tom, že někdo musí upravit tu databázi a aplikaci. Ono se to neudělá samo…

Myslel jsem zvyklosti na každé úrovni. Mění se třeba zápis adresy, která propadne až do aplikační úrovně (jiné znaky než tečky a čísla). mění se způsop přidělování adresy, způsob oznamování cest a směrovačů, způsob překladu adresy na linkové vrstvě. Změny jsou na všech úrovních. A to je ta komplikace.

Nějak nechápu, proč všichni ignorují základní problém IPv6 - od počátku není zpětně kompatibilní s IPv4, není jeho rozšířením. Je potřeba od nuly vytvořit nový paralelní Internet, a teď se všichni diví, proč to jde tak pomalu, proč ti co IPv4 mají IPv6 nepotřebují a naopak, a proč je o dost jednodušší dělat hacky v rámci stávajícího IPv4.

Už před 10 lety o tom psal Dj Bernstein: http://cr.yp.to/djbdns/ipv6mess.html

Jsem zvědav, jestli se prosadí spíše další hacky do IPv4 nebo zkompatibilnění IPv6 prostoru s IPv4 prostorem. K prosazení současného IPv6 jsem skeptický..

jenomže když už uděláte i tak drobný zásah, jak popisujete, tak se dostanete do úplně stejné situace jako s IPv6. Jistou dobu budete muset běžet současně obě verze. A zkuste to udělat nějak rozumně. Budete muset vyměnit protokolové stacky na všech připojených počítačích, atd. Prostě jste na tom stejně jako s IPv6.

Já třeba připojení pomocí IPv6 mám vypnuté, a jen občas testuji/zkontroluji zda nedošlo k nějaké změně. Můj nejběžnější ISP (Telefonica O2) totiž tento protokol nepodporuje a při pokusu použít IPv6 trvá vyjednávání při připojení docela dlouho a hlavně s nulovým výsledkem. U WiFi mám podporu aktivní, ale ještě jsem takovou síť nepotkal (k mnoha sítím se ale nepřipojuji).

U firemnich a dalsich siti je veci spravy co dovoli a co ne, IPv6 resi predevsim problemy BFUcek. Neustale dotazy jak udelat aby mi fungovalo .... pricemz se vzdy narazi na konfiguraci NATu, to, ze uzivatel nema NAT ve sve moci ... a pak se hledaji vsemozna zrudna reseni typu "protunelujeme sshcko pres http".

Aktualni zkusenosti - MMO hra s integrovanou audio komunikaci. Cca 1/3 hracu to proste nefunguje a vysvetlovat jim co a kde maji nakonfigurovat, jake porty forwardovat ... .

DHCP na IPv6 normalne funguje. Muze se chovat uplne stejne jako na IPv4 - tedy pridelovat podle MAC. Kazdy stroj muze ovsem mit vice adres, takze principielne muzete jednu pridelovat pres DHCP a dalsi jako autokonfiguraci + na FW zakazete odchozi provoz z tech DHCP adres.

Multicast a dalsi bych zatim moc nevidel ....

Mobilita by mela fungovat zhruba nasledovne. Vase mobilni zarizeni da vasi domaci GW vedet, kde se prave nachazi (praskne na sebe svoji IP) a domazi GW na ni bude preposilat vsechny pakety + samozrejme preda tuto IP dal, takze pripadni zajemci o komunikaci "zvenku" by meli byt schopni kontaktovat ono mobilni zarizeni obratem primo.

Samozrejme to predpoklada, ze mate pripojeni k netu, ne nejake zmrzacene cosi. A jelikoz toto je finalni rana pro klasickou telefonii, tak si sem na 100% jist ze se tomu budou operatori branit zuby nehty.

Kdy naposledy bylo tolik volných IPv4 adres, že byste je mohl takhle rozdat ISP tak, aby routovací tabulky nenabobtnaly na několikanásobné velikosti? Jak byste prakticky řešil komunikaci? Třeba v případě, že jde o staršího klienta (třeba starší verze prohlížeče), který o nějakých číslech počítače v options nemá vůbec tušení – uživatel napíše do prohlížeče www.seznam.cz, počítač se zeptá na A záznam, dostane IPv4 adresu, podle té se doroutuje až na hranici sítě ISP, tam se zjistí, že není vyplněno options, tak se zpátky pošle ICMP zpráva "sorry, nedostupné". A klient musí jít a vyměnit své zařízení za nové, které rozumí té options. No jo, ale když už bude měnit to zařízení, to už se ta změna protokolu dá udělat rovnou pořádně, ne? Tak, aby to nepřekáželo dalších padesát let.

IPv6 kromě velikosti adres řeší ještě něco dalšího, ale kdo vás nutí to používat?

Porovnat číslo na pevné pozici v paketu s nějakou tabulkou je docela jednoduchá úloha, která se dá dobře implementovat na hardwarové úrovni. Řešit nějaké posouvání čísel a jejich přepisování a hledání té správné délky, to je mnohem náročnější operace.

Našel jsem option 19 - Address Extensions
Vede to sem: http://tools.ietf.org/html/draft-ullmann-ipv7-03

No pokud nemate net = nejde se na vas pripojit zvenku, tak vam vase domaci GW muze pakety preposilat, ale paj jste (logicky) omezen nejen aktualni konektivitou, ale i dostupnou kapacitou vasi domaci linky.

To ze je hromada siti blbe nakonfigurovana zadny protokol vyresit nemuze.

Jop a na lokalni (neroutovane) siti muzete pouzivat linkove adresy, ony se taky by default pouzivaji.

Teď popisujete IPv4 s options, nebo IPv6? Co se týče nutnosti aktualizovat, je to stejné, akorát IPv6 je mnohem snáz a rychleji routovatelné, než ten váš návrh.

Zapomněl jste také odpovědět na otázku, kdy se to naposledy dalo udělat.

To mate pravdu, ale IPv6 neni novinkou tohoto roku... kolik programatoru relativne novych aplikaci (5 a mene let) bralo IPv6 vubec v potaz?

U firemnich a dalsich siti je veci spravy co dovoli a co ne, IPv6 resi predevsim problemy BFUcek.

Tak ono nejde jen o firemní sítě. Sám se často dostávám do situace, kdy se mohu připojit k nějaké cizí síti, a přes ni do "internetu". Typicky různé WiFi v hotelech, restauracích, Eduroam ve škole apod. Je to v daném místě a čase nejkvalitnější dostupné připojení, navrch zdarma. Jen je "blbě" nakonfigurované - nejdou příchozí spojení, přestože dostanu veřejnou IP apod. Proto ten internet v uvozovkách. Nechci-li řešit nějakou VPN (mám-li ji kam otevřít), tak jsem rád, že většina aplikací dnes s tímto počítá. Ať už Skype, nebo i SIP telefon, nebo mnoho dalších služeb, které se postupem času začaly spoléhat na "půjde jen port 80/443 ven, jinak nic". To jsou reálné případy, a můžete říkat, že taková síť je zkriplená, ale já nejsem v pozici, kdy bych si mohl diktovat, jak ta síť má vypadat.

DHCP na IPv6 je nutno kombinovat s RA, správně vše nastavit. Do toho různé OS mají různé chování a výchozí nastavení. Zas tak jednoduché to potom v praxi není. Když tomu PC teda přidělím 2 adresy, jednu pro LAN a druhou pro internet s PE, jakým mechanismem on pozná kterou má použít pro komunikaci ven. Až uvidím na routeru, že nějaký stroj s privacy IP adresou zahlcuje síť, jak jednoduše zjistím, o který jde ... zas na to musím mít nějaký extra mechanismus, co jsem do teď nepotřeboval.

Ad Mobile IP takze pripadni zajemci o komunikaci "zvenku" by meli byt schopni kontaktovat ono mobilni zarizeni obratem primo -- mobilní zařízení je v síti, která blokuje příchozí spojení (není to neobvyklé, viz výše).

Co se týče "klasicné" telefonie, až tak bych nesouhlasil. Ale to je na jinou diskusi.

Vzhledem k tomu, ze IPv6 vlak je dost dobre rozjety pochybuju o tom, ze se dockate nejakych dalsich hacku v IPv4. Nevybavuju si zadnou svetovou aktivitu, ktera by se snazila o reinkarnaci IPv4 :D
Nasazovani IPv6 je fakt. IPv6 nemusi v prvnich fazich IPv4 nahradit, staci jej doplnit paralelne k IPv4. Tak ostatne probiha v drtive vetsine realnych nasazeni. V korporatnich sitich casto analogicky koexistovalo IP s IPX a myslim, ze nekde by se naslo dodnes... :) Problem spousty lidi je ten, ze na IPv6 koukaji jako na okamzitou nahradu IPv4. Jenze tak tomu neni...

Jen nebojte, i O2 IPv6 podporovat zacne. Ostatne, to probehlo i Lupou: http://www.lupa.cz/zpravicky/o2-a-seznam-cz-nabidnou-ipv6-pristi-rok/

vy budete muset při přechodu na IPv6 měnit kabeláž? IPv6 pakety přes Cat5e neprojdou? :-)

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.

Novell je s dvěma l :)

Změnit pár struktur a jednu drobnou technologii vs zmenit celou infrastrukturu from scratch? Nejsem si jist, jestli můj návrh je tak komplikovaný jako bezproblémový přechod na plnohodnotné IPv6.

Jen se podívejte, kolik RFC bylo o IPv6 napsáno. Já svůj návrh vecpal do příspěvku na lupě.

Jenomže jste jaksi opominul praktické důsledky:

- všechny programy musíte znovu přeložit
- máte od všech programů zdrojáky?
- musíte upravit DNS - už to samo o sobě znamená všude implementovat znovu všechny resolvery

Když se začnete dívat víc do hloubky, tak se vám najednou vynoří problémy, které jste předtím nějak "přehlédl"

Vy jste vměstnal svoji úpravu IPv4 do jednoho příspěvku. Já dokážu vměstnat IPv6 do jedné věty: Rozšíříme adresový prostor na 128bitů. To je vše.

„Změnit pár struktur“ rovná se vyhodit zařízení za miliony (které ty struktury mají vypálené v hardwaru) a nahradit je novými. Kdo v takové chvíli chce ta nová zařízení komplikovat a zdražovat složitým způsobem zpracování paketu?

Routování je softwarová záležitost.

Routování si představuju jednoduše. Přijde paket, kouknu do tabulky a vyběhne na mě číslo určující jakým kabelem mám paket poslat dál. Co je na tom komplikovaného?

Fragmentace adresového prostoru a velikosti routovacích tabulek? IPv4 může routovat 32bitové adresy, v praxi maximálne 24. IPv6 routuje 64bitové adresy. Za sebe bych řekl, že 64 > 24, a tedy že routovací tabulky IPv6 budou mnohonásobě větší.

A jaký jiný současný problém IPv6 řeší?

Jinak ISP může mít víc rozhraní se stejnou IPv4 adresou. Já vím, že to je kacířská myšlenka, ale zhlediska směrování není problém v duplicitně rozhraních, pokud jsou identická. Pokud má vnější svět přístup do vnitřní sítě stejný bez ohledu, z jakého směru požadavek jde, pak není problém nasměrovat pakety na nejblížší rozhraní mající danou adresu. Na vnitřní síti samozřejmě budou mít ta rozhraní brán různé adresy.

Pokud to znamená zásah do routovacích algoritmů, tak je to jen softwarová záležitost a opět, uplatní se jen tam, kde to je potřeba se zachováním zpětné kompatibility.

Řeší fragmentaci adresního prostoru a nárůst routovacích tabulek.

Nevím, co byste chtěl řešit více rozhraními se stejnou IP adresou, ale dobře to ilustruje váš chybný pohled na věc. ISP nepotřebuje routovat každou IP adresu zvlášť, on potřebuje routovat co největší blok adres najednou.

Pokud to znamená zásah do routovacích algoritmů, tak je to jen softwarová záležitost
Nesmíte si pořád routování představovat jako linuxové pécéčko se dvěma kartami a routováním pár Mbit/s. Ono je potřeba umět routovat taky kapánek větší provoz – a tam zásah do routovacích algoritmů je hardwarová záležitost, a když už tedy ten hardware musím vyměnit za nový, chci, aby ten nový byl co nejlevnější, měl nízkou spotřebu a byl rychlý. Tedy aby měl co nejméně práce, a ne že bude muset každý paket osmkrát obrátit sem a tam než zjistí, co s ním má vlastně dělat.

IPv6 tohle potřebuje, stejně jako váš návrh. Takže HW musíte vyměnit v obou případech. Rozdíl je v tom, že hardware pro IPv6 může být mnohem jednodušší.

Nejspíš proto, že ty weby už dávno nejsou jen statické stránky, které jsou naprosto imunní vůči takovým změnám. Stačí se porozhlédnout. Třeba tady na lupě je u každého příspěvku jméno a IP adresa pisatele. Bez změny systému be se prostě ty IPv6 adresy nezobrazovaly. Nebo takový internetový provider má nejaký systém, kde si udržuje informace o tobě a mimo jiné tam má políčko s IP adresou. Ale historicky jsou to vlastně políčka čtyři akceptující pouze číslice do 255. Jak si asi zapíše, že ti přidělil IPv6 adresu? A takových příkladů by se dala najít spousta. Nezbývá než doufat, že se s tím už něco dělá.

Jo, routování je softwarová záležitost tak maximálně na PC.

A i to routování v IPv4 si představujete jako hurvínek válku. Co třeba source routing? Zpracování dodatečných hlaviček pro routing?

Co se týká fragmentace adresového prostoru, tak se obávám, že jste nepochopil podstatu. Nezáleží na velikosti jednoho záznamu, ale na množství záznamů. A tam IPv4 kvůli adresové roztříštěnosti jednoznačně vede. Ani největší routery dneška nedokáží zpracovávat víc jak 1M záznamů v routovacích tabulkách. A to je to rozhodně méně než 2^24

a pozorujete nějaké problémy, když teď přispíváte přes IPv6?

Na vašem PC je routování softwarová záležitost. Na páteřních sítích je to hardwarová záležitost, jinak byste se nedočkal.

Ta tabulka ovšem nemá pro každou IP adresu jeden řádek, ale IP adresy se tam seskupují do větších celků, aby bylo vůbec proveditelné takovou tabulku někam uložit a v rozumném čase v ní něco najít. Podstatná tedy není délka adresy, ale to, aby tím jedním kabelem vedlo co nejméně různých bloků adres. Takže to, co vám v IPv6 vyřeší jeden routovací záznam, to musíte v IPv4 vyřešit větším množstvím záznamů, které zohlední které různé pidisítě se routují jinudy.

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…

Tak pan "Admin ." ma mozna specialni kabelaz, ktera IPv6 packety filtruje, co my muzeme vedet...

No nevím, pořád je to hledání nekratší cesty a stavět to na současné hierarchické organizace, kdy "kdo není v NIXU, neexistuje" a "provideři jsou klienti jiních providerů, kteří jsou připojení do NIXu." je krátkozraké. Stejně se ukládáním delších prefixů nevyhnete. Nebo za cenu nižší propustnosti.

Upřímě, kdekdo si tady stěžuje, že překupování rozsahů IPv4 způsobí fragmentaci, ale nemyslím si, že existuje algoritmus, který by dokázal přidělovat adresy s ohledem na budoucí topologii sítě. Takže ta fragmentace tam bude taky.

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

Vyhnout se tomu ale nejde. Kdo nevymění krabičku, nedostane se na nový internet. Takže jde jenom o to, jak drahé ty krabičky budou.

V IPv6 zadne broadcasty nejsou... :-)

Právě že to není stavěno na hierarchickou síť, hierarchii vyžaduje ten váš NAT.

Fragmentace tam z vámi uváděného důvodu nebude. IPv6 adres je dost, takže když se změní topologie sítě, starý rozsah se přestane používat a požádá se o nový. Nebude důvod držet se za každou cenu toho starého, protože nový už bych nemusel dostat.

Tak si zmente mac adresu sitovky nebo si nastavte IPv6 adresu staticky nejakou jinou, nez tu, kterou vygeneruje EUI...

Jak vidno, o routovani vite prd, protoze velke routery maji zakladni routovani zadratovano do HW. To ze se tam nasledne daji nastavit SW pravidla, je vedlejsi, protoze pravidla resi vyjimky, kterych neni mnoho a tudiz nijak zvlast nezatezuji CPU.

Uvedomte si, ze to "kouknu do tabulky" musite delat pro miliony paketu za sekundu. Velke routery maji rychle pameti ktere jsou svym rozsahem primo dimenzovane na IPv4 nebo ty novejsi uz i na IPv6 (= neztraci vykon, IPv6 lze na nekterych starsich resit SW cestou, ale za cenu 1/10 vykonu)

A opet, dalsi neznalost, IPv4 klidne muze routovat jednu konkretni IP, jenze cim vic je prostor fragmentovan, tim vic zaznamu v te tabulce musi router prohledat, nez najde spravny smer. A IPv4 je fragmentovan prave kvuli nedostatku adres - nelze pridelit /16 s dostatecnou rezervou pro danou lokalitu do budoucna => prideluje se trebas /20, coz znamena, ze ve finale ma lokalita nekolik prefixu a pro kazdy musi byt zaznam v routovaci tabulce, pricemz pri dostatecnem dimenzovani predem by stacil zaznam jediny. Proto na prvni pohled prehnane pridelovani ohromnych prefixu na IPv6. Je totiz dost pravdepodobne, ze providerovi takovy prefix bude stacit navzdy.

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.

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.

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

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.

a MRP a GARP a ...

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ť udělám cokoliv, pořád to bude adresa mého počítače :-)

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

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 proto existuje moudry rozhodnuti, ze nerozfofrujeme najednou celej IPv6 rozsah, ale pouze 2000::/3 a zbytek zustane jako rezerva, kdyby se pozdeji ukazalo, ze napr. ty lokalni /64 nebyly uplne nejlepsi napad. Pokud se neco takovyho za sto let stane, tak taky nebude uplne nejjednodussi s tim neco delat, kdyz bude vsechno s /64 pocitat. Ale porad by to melo byt snadnejsi nez dneska s prechodem z IPv4.

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.

„(upřímě, nejsem moc šťastnej, že někdo zná adresu mého počítače)“

A jakpak to vadí? Mně je to celkem fuk, dokonce už mám i DNS záznam - ee.hrach.eu

Jo a kdybyste se divili, proč je v hlavičce komentáře můj IPv4 ISP, tak je to proto, že jsem si nastavil preferenci IPv4, protože tunel bývá přes den přetížený :-(.

„Nějak nechápu, proč všichni ignorují základní problém IPv6 - od počátku není zpětně kompatibilní s IPv4“

Protože zpětně kompatibilní protokol prostě navrhnout nejde.

Zachování adresy mobilních zařízení se ovšem neřeší změnou routování na páteřních sítích. To zachování adresy by bylo klidně možné implementovat i nad IPv4 – jenže je to poněkud zbytečné, když ta mobilní zařízení nemají veřejnou IP adresu. Nějaká ta komunikace navíc, když si chcete sesynchronizovat kontakty v mobilu, ničemu nevadí. Ale když se routuje provoz YouTube, to musí odsejpat. Na DNS jsme závislí dávno – třeba bez vyvažování zátěže realizovaného i pomocí DNS by Google negoogloval.

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.

Casto jsou ty specializovane cipy programovatelna hradlova pole, takze novy firmware do nich nejake ty nove funkce dostat umi, na druhou stranu je treba rici, ze to mnozstvi implementovatelnych funkci neni diky omezenim vyplyvajicim z architektury toho hradloveho pole neomezene (co se neda udelat temi hradly, co v tom hradlovem poli jsou, to udelat zkratka nejde -- a je jich pochopitelne jen omezeny pocet).

a můžu se zeptat jak budu přijímat digitální televizi na svém analogovém televizoru bez jakékoliv investice? Prosím poraďte.

No a digitální televize taky nepotřebuje změnu infrastruktury? Žádná nová zařízení na vysílačích?

DJB o tom sice psal, ale zadny kouzelny reseni stejne nevymyslel. A ve skutecnosti ani neprosazuje primou zpetnou kompatibilitu (tj. aby v novym netu mohlo byt i stary IPv4-only zarizeni, ktery o existenci IPv6 vubec netusi).

Pokud jde o teoretickou stranku, dlouho jsem se nemohl zbavit dojmu, ze ta jeho analogie s MX zaznamama je uplne mimo. Ve skutecnosti neni, on se s tim proste jen prilis nestve a rika, ze zadnej mailserver si nemuze dovolit nebyt na A, dokud budou existovat klienti, kteri neznaj MX. A v uplne stejnym duchu pristupuje k IPv6. Komunikace mezi IPv4 a IPv6 adresou ano, ale automaticky predpoklada, ze i ten stroj s IPv4 musi mit poneti o existenci IPv6, tj. je nutnej upgrade SW. Ze to vubec neresi problem tech, kteri prave do niceho hrabat nehodlaji, to ho netrapi. Proste se to musi udelat a tecka, konec.

Prakticky pak navrhoval, aby kazdej stroj s IPv4 automaticky nahodil 6to4 a byl tak dostupnej i po IPv6. Tohle mu splnil MS s Windows, ktery to delaj. Ten navrh ale sel dal a pozadoval, aby si to system nejak automaticky zaridil, aby to i ve vsech aplikacich fungovalo bez dodatecny konfigurace (tj. zadalo by se jen IPv4 nastaveni a komplet IPv6 by se odvodilo automaticky). Kdyby to vsichni udelali, tak by to bylo skvely, protoze vsechny zdroje by se staly pristupny pres IPv6 (i kdyz jen 6to4) a nebyl by problem napr. koncovym klientum dat pouze nativni IPv6 bez IPv4. Jenomze to opet neresi hlavni problem, ze nikomu se do niceho hrabat nechce.

Tohle je pravda pouze vetsinou, ne vzdy.

Heh, to je easy.

a) mate win vista/7 a mate alespon trochu rozumnou konektivitu (muze byt i za NATem) ? = mate (defaultne) IPv6 tunel pres M$
b) Mate svoji routokrabku s verejnou IPv4 ? Regnete se trebas u http://tunnelbroker.net/ defaultne dostanete /64 na pozadani dalsi /48, hnedlne tam mate cudlik ktery vygeneruje konfiguraci pro vybrany OS.

Vy jste případ. Nechcete své rozumy poslat Ciscu nebo Juniperu? Jistě vám zaplatí milióny. Nebo vám nedochází, že ta cena za takové řešení může být vyšší než nasazení IPv6? Véte kolik teď stojí páteřní routery pro Tier 1 hráče? A do IPv6 se nastrkalo tolik peněz, že alternativa se vymýšlet natož nasazovat určitě nebude. S tím se smiřte, je to to jediné co s tím můžete udělat. Teda kromě odpojení :-)

Hlavně není důvod adresovat spojovačky jinak než link local. Takže máš adres neomezeně a můžes své Global Aggregatable soustředit tam kde mají své opodstatnění, tedy na koncové VLAN a zařízení.

Pomíjím zmínku o /32. Ne každý je ISP...

Ta jednotna netmaska je navrzena i kvuli celkovemu zjednoduseni administrace. Jinak si nemyslim, ze se svymi /80 na spojovackach spasis svet... nebo dokonce sit sveho zamestnavatele ;) Jen v jedne /48 mas tech spojovacek 65536... a tech /48 bloku mas 65536. Vynasobit tyhle cisla myslim zvladnes... schvalne zkus spocitat, kdy ti dojde /32 ve tve siti. A kdyz si vsimnes, RIPE dnes dela pridely tak, abys mohl dostat minimalne jednu dalsi /32 bezprostredne nasledujici po te, kterou mas dnes... proste se bavime o uplne jinych cislech.

Jeste zajimavejsi je do poctu vztahnout pocet obyvatel na zemi... to je teprve zajimave srovnani, pokud se bavime o tom, kolik IPv4 a IPv6 adres je k dispozici na jednoho obyvatele zemekoule :-) Docela me zajima tva analyza na tema kdy podle tebe dojdou a proc...

No, podstata mého komentáře byla, že ODCHOZÍ komunikace z XP přes IPv6 je v pohodě, ale SLUŽBY (systémové) na IPv6 neposlouchají (a ani tam není firewall). Takže: WinXP se přes IPv6 spojí třeba se system update serverem, ale k jejich sdílené tiskárně se přes IPv6 připojit nedá.
Dále jim schází DHCPv6 a již zmíněné DNS dotazy (ovšem adresu serveru by musely získat přes DHCP, které nemají...).

obecně IPv6 opravdu stávajícím uživatelům nic nepřináší. Myslím tak, že nikdo netvrdí, že něco přináší.

Důležité je, že na své zprovoznění čekají asi další 3 miliardy různých zařízení, která chtějí být k internetu připojena.

Jak budete z domova spravovat síť svého zákazníka, když ani jeden z vás nebude mít veřejnou IP adresu? (v budoucnosti se prostě stane, že zákazník opravdu takovou adresu nedostane)

Já jsem nevyhrožoval, jen popsal pravděpodobný scenář za pár let a tak aby to pochopili i Natvrdlíci. No alespoň, že uznáváte, že IPV6 bude potřeba :-)

tak pokud se rád škrábete sousedovou levou nohou za svým pravým uchem, tak proč ne.

Já osobně netvrdil, že přejít máte všude už včera :-) Vy jste, ale IPv6 tvrdošíjně úplně odmítal. A ne, jeden hráč na Internet opravdu s ničím jiným přijít nemůže. Zbyl by mu jen ostrůvek pro pláč :-) Alternativa prostě není a nebude. Implementace IPv6 už je prostě moc daleko.

Zadny problem, navic pokud vase krabicka neni za kilco od vietnamce, tak se na da nastavit tak, ze ono IPv4 only zarizeni bude umet komunikovat i s IPv6 only ucastniky site.

IPv4 je totiz soucasti IPv6.

To mi připadá argumentaci z Otce prasátek:

Zuzanka: Tohle byla poslední chvíle
Smrt: VŽDYCKY JE ČAS NA DALŠÍ POSLEDNÍ CHVÍLI

Ano z jeho pohledu to tak vypadá :-) Navrhuji provést AškEnte a zeptat se ho na IPv6 :-)

Tak bohužel:

[root@server ~]# ping6 DEAD::1
PING DEAD::1(dead::1) 56 data bytes
From 2001:4860::1 icmp_seq=0 Destination unreachable: No route

Možná před tím provést ten rituál, ale okolo čeho mám nakreslit ten kruh? :-)

Ne nakreslit, natáhnout TokenRing okolo sálového počítače :-)

Ah tak! Nějaké MAU bych tu snad i splašil, ale sálový počítač? Bude muset stačit zaprášená 286. A to by bylo, aby se Smrť nezachvěl, až tam uvidí běžící Windows 7! :-)

To je sice hezke, ale to jsou tunelovana reseni a k tomu jsem uplne nesmeroval.

Me by proste zajimalo, jestli ja, jakozto domaci uzivatel muzu mit uz nekde nativni IPv6 konektivitu a s jakym scenarem nasazeni pocitaji ISP.

Tj. budeme dostavat na domaci krabicku /64 prefix a ten si doma ocislujem a rozvedem jak chceme nebo nam budou domaci pocitace dostavat adresy primo od routeru/dhcp isp?

Ono uz jenom od teto drobnosti se odviji spousta dalsiho planovani a nastavovani treba toho zmineneho firewallu.

možností je několik, záleží na tom, jak se provider rozhodne.

- může poskytovat DHCPv6 s prefix delegation
- může vám to staticky naroutovat
- může vám poskytnout normální DHCPv6

... Až Vám provider sebere veřejné IPv4 adresy a strčí Vás za váš oblíbený NAT

Tak nebude problém za nějaký poplatek si tu IPv4 adresu u něj koupit. Bude ji pro mě mít, protože jiní zákazníci ten poplatek nebudou ochotni dát. V nejhorším této příležitosti rád využije jiný provider.

Proč by "všem sebrali IPv4"? Oni na tom budou chtít vydělat. Co nejvíc. Mnohem pravděpodobnější je, že poplatek za adresu bude třeba 200 Kč, 400 Kč, 600 Kč / měsíc. Až se najde nějaký rovnovážný stav. Když se půlka lidí s domácím ADSL veřejné IPv4 vzdá, protože pro ně bude moc drahá, tak pro firmy za klidně 500 Kč / měsíc bude adres dost ještě 20 let.

Každý druhý lokální ISP má naalokováno tolik IPv4 adres, že při nějakém očekávaném růstu mají adres dost taky na 20 let. A to často dokonce ani za veřejnou IPv4 nechtějí peníze navíc. Jen by-default dávají domácí uživatele za NAT. Jo, je to asi síťové zlo, ale je tu taky ekonomická realita.

Rád to třeba nedělám, ale je to tak nejlevnější, a nikdo mi nic dražšího nezaplatí. Síťové ideály se střetávají s ekonomickou realitou.

Je ho potřeba konfrontovat s modrou smrtí?

Při vší úctě - proč se sám shazujete?! Celou dobu se tady bavíme o tom, že v IPv6 _nejde_ jen o zvětšení adresního prostoru a že podle některých ta ostatní vylepšení nestojí za námahu!
Což nás přivádí k těm ostatním bodům - platí přece pro IPv6 úplně stejně!
Sorry že křičím, ale zdá se mi, že to berete nějak moc "politicky"...

Ano. To ze je moznosti nekolik to vim.

Ale rikam, rad bych si nekde precet jaka je praxe nebo jak to isp planuji.

všechny ostatní věci jsou totiž ve srovnání s rozšířením adresového prostoru marginální. Samozřejmě, že se můžeme bavit o autokonfiguraci, fragmentaci pouze end-to-end, podpoře mobility, multihomingu, anycastu, ale to jsou z mého pohledu celkem drobnosti.

IPv6 by totiž vůbec nikoho nezajímala, kdyby nám adresy nedocházely. IPv6 je třetí vrstva ISO/OSI modelu a uživatele zajímá tak maximálně ta sedmá.

Jak tady můžete číst: co mi přechod na IPv6 přinese? No, když zakonzervujeme internet v současné podobě, tak mu IPv6 nepřinese vůbec nic. Problém je v tom, že internet v současné podobě zakonzervovat nemůžeme.

Jeden křičí, že je IPv6 jediná cesta, jak překonat došlé adresy, druhý křičí že nejde jen o zvětšení prostoru.
To se přece vzájemně vůbec nevylučuje.

Já vím, že IPv6 přináší tisíce a jedno vylepšení navíc, ale v tom je ten největší problém, prostě se bude hůře prosazovat. Zvedá to cenu toho HW a tím snižuje ochotu ISP do toho investovat.
Můžete uvést příklad alespoň jednoho takového vylepšení, které někdo musí povinně implementovat a zvyšuje to cenu HW? Dnešní krabička u koncového zákazníka musí umět routovat IPv4, filtrovat, DHCP a NAT. Nová krabička u zákazníka musí umět routovat IPv6, filtrovat a získání a přidělení IPv6 adresy, plus dnes by ještě měla umět vše, co IPv4 krabička. Kde tam vidíte co navíc?

takže nic, co by zvedalo cenu HW, protože síťový stack, přidělování adres i firewal budou muset být v té krabičce vždy, ať už bude implementovat jakýkoli protokol. A dvakrát to tam bude muset být do té doby, než se z IPv4 přejde zcela na něco nového.

Neni slozitejsi. V nekterych ohledech je dokonce jednodussi. Nicmene to nesouvisi s architekturou smerovacu ani trochu.

A take na loopbacky. Takze /32...

pardon, 4G IPv4 adres, preklep.

U zmíněných firem pracují výborní kodéři, ale každý nový systém potřebuje měkolik jednoduchých chytrých myšlenek, které může udělat jen pár lidí. (Já je nazývám ideovým křížem systému.) Prý se na nich nemůže podílet více než 7 lidí, protože jinak nedokáží spolu udržet všechny souvislosti. A přesně to se při návrhu IPv6 nestalo, proto 15 let se tento "vlak" nemůže pořádně rozjet.
Je samozřejmě otázka, zda právě tahle situace s IPv6 nebude konečně stropem v dalším rozvoji celosvětového Internetu. Já si klidně dovedu představit, že Čína by si mohla udělat svou IPv4-síť, kde by používala již jinde ve světě přidělené adresy. A navíc by tím krásně zpřístupnila celosvětový Internet jen tam, kde by to bylo dovolené.

tech /48 bloku sice je v /32 tech 65536, ale uvedom si, ze nemohu celou /32 pouzit jen na spojovacky, neco musi zbyt i na zakaznicke alokace, tedy /48. Jiste, mohu tu alokaci zvetsit, jenze pak uz je ve 2000::/3 misto zase na mene alokaci (budeme-li mit vsichni /31, bude jich polovina, budeme-li mit vsichni /30, pak ctvrtina atd.) Momentalne se za kazdou /32 alokaci nechava sedm dalsich volnych, takze realne je misto na 2^26 takovych alokaci, coz je nejakych 66 milionu. Muze to byt dost, dnes. Pred dvaceti lety se lidem take zdalo, ze 2G IPv4 adres je dost. Ale co az kazdy residencni a mobilni zakaznik bude chtit tu pro nej urcenou /56, aby tam mel dostatecny prostor pro vice svych /64 subnetu? (typicky uzivatel bude mit patrne pevne pripojeni a k nemu jeste nejmene jedno mobilni, spise se da cekat, ze ke kazde aktivovane simkarte bude /56 a tech simkaret ma mnoho lidi vice nez jednu).

Nedam ti analyzu, kdy podle mne dojdou. To totiz nemuzeme vedet, nemuzeme vedet, jake se v budoucnu objevi aplikace a jak budou ty adresy vyuzivat. A proto je rozumne se k tem adresam uz dnes chovat hospodarne.

ano, všechno je to o penězích. A udržování toho vašeho řešení je patrně dražší než zavedení IPv6.

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

Az na to, ze jemu to jedno neni protoze to vecne nefuguje.

IPv6 v dohledné době přinese normálnímu uživateli to, že bude moci s ostatními přes internet zadarmo telefonovat bez nějakých pochybných programů a prostředníků (jejichž síť se tu a tam na pár hodin rozpadne), že se odkudkoli dostane k dokumentům a fotkám, které má doma na počítači, že mu technická podpora nebo kamarád pomůže s počítačem rovnou na dálku přes internet, že si informace v mobilu bude pohodlně on-line editovat ze svého počítače nebo že si z mobilu do svého počítače pohodlně stáhne fotky. Dneska to sice může přes nějaké prostředníky a registrace dělat také, ale je to zbytečně složité, a ještě složitější pro autora takového programu – musí zajistit a zaplatit i tu zprostředkova­telskou službu.

Myslíte, že Skype bude chtít sám sebe zahubit? Proč by se Skype zabýval IPv6, když to znamená jeho konec?

Kde berete tu jistotu, že ta příchozí spojení budou blokována i nadále? Provozovatel sítě, který zakáže věc, která je jinak normálně dostupná a ničemu nevadí, asi moc dlouho provozovatelem nebude.

To, že vy jste v životě neslyšel o technologii wake-on-lan, ještě neznamená, že taková technologie neexistuje.

Kdybyste si přečetl můj komentář, dočetl byste se tam, že uživatelům jsou prostředníci jedno do té doby, dokud ta síť funguje. A taky že jde především o vývojáře – aplikaci pro P2P telefonování, pro sdílení souborů, pro on-line ovládání mobilního telefonu, dokáže napsat kde kdo. Jenže zaplatit k tomu infrastrukturu zprostředkovatelů, na to už je potřeba pořádná investice, je potřeba z něčeho platit provoz atd.

Zrovna ten váš problém s voláním z mobilu by nějaká taková aplikace mohla řešit – když budete volat na mobil kolegy či na pevnou od zaměstnavatele, telefonát přepojí přes WiFi a VoIP. Jenže k tomu je potřeba umět se na ten cílový telefon nějak jednoduše přes IP připojit…

Ono nejde o provozovatele site. Velkou cast techto zarizeni si kupuji a instaluji sami koncovi uzivatele. A pokud tato zarizeni budou defaultne prodavana s aktivovanym firewallem pro prichozi spojeni (jak uz to vypada z ruznych naznaku), tak to v prevazne vetsine pripadu tak zustane nastavene (uzivatele tomu povetsinou nerozumi a instaluji to zpusobem zapoji-funguje).

Se mi zdá, že diskuse byla nějak promazána...

P.S. Tohle klidně smažte taky.

Jistotu? Nebude to všude. Ale mnohde stále ano. Protože ty důvody, které provozovatel sítě pro takový setup má, s IPv6 nepominou.

Jistě, že normální ISP si to nedovolí. Ale mluvím zejména o případech, kdy se obvykle zdarma připojuji do nějaké cizí sítě, které nabízí v daném místě a čase nejlepší konektivitu (rychlost, latence), ale má jistá omezení. A nejsem v pozici, abych mohl provozovateli diktovat, jak to má fungovat. Jde-li o službu popsaného typu (WiFi v hotelu, restauraci, na letišti, ve škole) pak provozovatel na tomhle fakt neskončí. A ta věc se zakazuje např. jako nejjednodušší a celkem funkční metoda omezení extrémního vytížení sítě P2P aplikacemi. Na té univerzitě to musí být fakt dementi, když mi na WiFi dají veřejnou IPv4 a zakáží věc, které je normálně dostupná a ničemu nevadí.

Pravda, využít na toto wake-on-lan mě nenapadlo. Ale nemusíte hned usuzovat, že jsem o něm v životě neslyšel. Stejně ale. Pro kolik procent uživatelů toto je významný use-case?

tak to jste nepochopil. Usilovné lpění na IPv4 a čekání na zázrak je otázka slepé víry :-)

konečně rozumné slovo :-)

Máte v diskusích nějakou chybu. Stránkování nefunguje jak má. když zadám požadovanou stránku ručně
ipv6-myty-a-skutecnost-dil-i-jak-jsme-na-tom/nazory/?pio=2 (váš default)
ipv6-myty-a-skutecnost-dil-i-jak-jsme-na-tom/nazory/?pi=2 (můj pokus)
ipv6-myty-a-skutecnost-dil-i-jak-jsme-na-tom/nazory/?pi=3 (můj pokus)

dostanu vždy jen první stránku diskusí (ipv6-myty-a-skutecnost-dil-i-jak-jsme-na-tom/nazory), strom diskuse jen po "Re:otázky od Karla Zajíce" http://www.lupa.cz/uzivatel/88582/

Zobrazit vybrané, ve stromu diskuse pod článkem se zdá fungovat normálně.

Kolik velkých výpadků měla síť Skype za poslední dva roky?

IPv6 je potřeba k tomu abyste mohl snadno navázat komunikaci s cílovým telefonem. Dneska se taková aplikace nerozšíří, pokud není schopná poradit si s NATem. A aby si s ním poradila, musí buď autor zaplatit infrastrukturu zprostředkovatelů, nebo se ta aplikace musí složitě konfigurovat.

Ty důvody pominou. Dnes se navazování komunikace z venku zakazuje, protože ji nedokážete kontrolovat. Běžná dostupnost koncových zařízení z internetu to změní. Zřízení se připojí do sítě a do DNS publikuje IP adresu a porty, na kterých jsou nějaké služby – na portu XY očekává příchozí VoIP spojení atd. Spolu s tou registrací není problém povolit komunikaci i na firewallu.

Už teď se prodávají mediální servery, NAS servery nebo set-top-boxy, ke kterým se dá přistupovat z internetu. Proč by to někdo řešil, když by po to nebyla žádná poptávka? Za pár let to bud úplně normální a lidi se budou divit,jak mohl být někdy internet tak omezený, že dovoloval navazovat komunikaci jen jedním směrem.

Dnes se navazování komunikace z venku zakazuje, protože ji nedokážete kontrolovat

Nejen proto. Tohle je jeden z mnoha důvodů.

Zřízení se připojí do sítě a do DNS publikuje IP adresu a porty, na kterých jsou nějaké služby

Odkaz na nějaký standardní mechanismus, co tohle řeší a je implementován v použitelné podobě? Vím jen o UPNP, a to jsem na moc místech funkční neviděl.

Vy mi tady předkládáte případy ala NAS nebo set-top-box, ale tam nejsme ve sporu. Já celou dobu mluvím o tom, že dnes lidé s notebooky nevyuživají jen domácí sítě, kde rozhodují o konfiguraci a poskytovateli služeb. Ne nevýznamná část uživatelů se někdy pohybuje v prostředí, jak jsem naznačil výše. Tam sice lze udělat všechno, co píšete, ale správce sítě to z nějakého důvodu dnes nepovoluje. A přidání IPv6 to má řešit? Jde o určitý security mechanismus, a i když ho možná odsoudíte jako nesmyslný, obrovské množství lidí, kteří rozhodují o konfiguraci konkrétních sítí, toho názoru evidentně nejsou.

Potom, co jsem se seznámil z důvody, proč jsou příchozí spojení blokována na našem univerzitním Eduroam, rozhodně nejsem přesvědčen, že s přidáním IPv6 tyto zmizí. Že si bude moci endpoint publikovat k firewallu, co chce mít dovnitř otevřené, o to administrátor právě nestojí.

Uvidíme, jak se to vyvine. Ale já takový optimista jako vy nejsem. A neočekávám, že IPv6 ty hromady administrátorů přesvědčí změnit jejich zvyklosti v tomto směru.

V prostředí, o kterých píšete, si klientské zařízení (třeba obil) požádá o registraci portu pro VoIP, SOAP a Torrent. Správce bude mít nastavena taková pravidla, že první dvě registrace projdou, třetí se zamítne. To je jedna varianta. Druhá varianta je, že zakáže vše, a klient to bude tunelovat přes VPN apod. Rozumný administrátor si logicky vybere tu první variantu, protože pak má nad komunikací mnohem větší kontrolu, může zakázat ty služby, které mu síť přetěžují apod. Administrátor, který provoz blokuje jen tak, bezdůvodně, si zvolí druhou variantu, a brzy bude spokojen, protože v síti nebude mít jediného uživatele.

Aplikace a mechanismy využívající IPv6 a otevřeného internetu budou postupně vznikat, jak se bude IPv6 rozšiřovat mezi lidi – do teď nebyl důvod tohle řešit, protože spousta zařízení je za NATem.

To je chyba úvahy. Kdyby teď přišel s podporou IPv6, tak má strejčka a jestě mu to vylepší kvalitu spojení. Naopak, až se objeví software schopné hovorů a videokonference přes IPv6, bude pro Skype příliš pozdě.

Jak jsem si už vyzkoušel, z hlediska aplikace je přechod na IPv6 hračka. Pokud to hoši mají v objektech, určitě jim postačí nahradit objekt s "IPAddr" na "IP6Addr" a vnitřnosti síťového engine upraví tak, aby ve výsledku se vytvářel IPv6 socket a zbytek je stejný.

Jak mám chapat citát níže? Je to tedy standard nebo neni a jen se to snaží standardizovat

cituji:
"První díl dnešního seriálu zahájíme krátkým exkurzem do historie IPv6. Celá historie protokolu IPv6 sahá do roku 1992, kde byla konsorciem IETF, jako důsledek rozrůstajícího se Internetu, vyhlášena prostřednictvím RFC 1550 výzva pro podávání návrhu Internetového protokolu nové generace (pracovně pojmenovaného IPng). Základní požadavky byly následně vyhodnoceny (viz. RFC 1752) a byly ustanoveny pracovní skupiny. V roce 1995, byla uvolněna první sada RFC dokumentů, počínající RFC 1883, definující Internetový protokol nové generace – již pod názvem, jakým jej známe dnes – IPv6. Cílem tvůrců nebylo řešit pouze problém nedostatečného adresového prostoru, ale současně také vyřešit tehdy známé nejpalčivější problémy dosud používaného IP (IPv4) protokolu."

To je super vtip dne - neprovereny dualstack... muzete mi rict, co je na nem za ty roky neprovereneho? :-) Vite vubec, kolik webu kolem Vas, vcetne nekterych webu statni spravy dualstack dneska ma? Existuji komercni poskytovatele hostingu, ktere dlouhodobe cpou IPv6 ke svym sluzbam standardne...

Vzhledem k tomu, ze s IPv4 i IPv6 se pohybujeme na treti vrstve ISO/OSI, je logicke, ze neexistuje realna IPv6-only aplikace. Kdo na ni ceka, OSI model nikdy nepochopil :) Uz na ctvrte vrstve neni rozdil - TCP, UDP jsou porad stejne. Aplikacni vrstva je az ta sedma... a tu opravdu nemusi zajimat, co je hluboko dole pod ni... :) Uzivatele skutecne zajimaji aplikace, ne to, jakym zpusobem se dopravuji data...

Chaos zpusobi maximalne notoricti odmitaci IPv6, ale ten chaos bude jen lokalni - v jejich sitich. Ale nemyslim si, ze by jich byla vetsina... je to IMHO z pohledu sitove velikosti ukricena mensina lidi - inu, jejich boj :) Ve velkych sitich se IPv6 postupne objevuje - samozrejme to nebude ze dne na den vsude, ale podstatne je, ze tam se na to nekasle a nevedou se nesmyslne debaty o tom, jak se bez IPv6 obejit.

Dukaz, ze jsem plne premigroval na IPv6; muj system o IPv4 uz ani nevi:

$ wtf ipv6
ipv6: ipv6 (7) - Linux IPv6 protocol implementation
$ wtf ipv4
Gee... I don't know what ipv4 means...

Az muj zakaznik bude pozadovat IPv6 kvuli bonusovym mecum ve wow na tech stovkach pocitacu, co mu spravuju, tak se tim zacnu zabyvat.
Realisticky to prijde na radu nedlouho pote, co voda zacne tect do kopce a peceni holubi sami letat do ust.

Neco je spatne?

$ host ipv6.lupa.cz
ipv6.lupa.cz has address 67.215.65.132
ipv6.lupa.cz has IPv6 address 2001:67c:68::18

Pokud ale zadam do WWW prohlizece http://[2001:­67c:68::18], tak skoncim na:

http://www.iinfo.cz/

A pokud zadam
http://[2001:­af0:fffe:2::d42f:1774]/
tak skoncim na webu vlady

$ host www.vlada.cz
www.vlada.cz has address 212.47.23.116
www.vlada.cz has IPv6 address 2001:af0:fffe­:2::d42f:1774

I odkazy funguji dobre, z rychleho testu se mi zda, ze ten vladni web je implementovany na IPv6 korektne...

Mohl byste napsat, co jsou to ty „všechny cíle“, vedle zvětšení adresního prostoru? A alespoň jedno z těch tisíce a jednoho řešení, jak se to dalo udělat lépe, když máte po světě miliardy zařízení, které umí jen současné IPv4 a máte rozebránu většinu adresního prostoru IPv4? Já si totiž myslím, že když vezmete v úvahu realitu, nakonec stejně dojdete k něčemu velmi podobnému IPv6. Ale možná se pletu…

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

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

Vy jste, jak se tak dívám, chytřejší než celé IETF. Nejste taky náhodou nějaký managor?

Myslíte co je nutné udělat pro spuštění webu na IPv6 jiného, než přidělit IPv6 adresu webovému serveru? Podívejte se třeba na komentáře tady na Lupě. Zobrazuje se tu část IP adresy. Pokud je IP adresa ukládána v databázi efektivně, jsou to 4 bajty. Když do toho pustíte IPv6 adresu, nepodaří se to někde správně zkonvertovat či uložit, a zpracování požadavku končí. A s IP adresami uvnitř pracuje spousta webů – minimálně kvůli logování.

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

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.

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

No tohle je softwarový problém. Protože aktualizace prohlížeče a operačního systému si uživatelé zvládnou vyřešit sami.

Seznam.cz asi bude mít ještě dlouho veřejnou adresu "bez options". Uživatelé, kteří budou mít starý systém budou používat starou IPv4 a ISP je bude routovat přes NAT. Uživatelé s novým systémem bude routovat přes router co umí options. Uživatel bude moci otevřít port na své lokální síti adresované v poli options, ale to už bude vyžadovat, aby protistrana měla novější operační systém. Tady vidím jednoznačnou motivaci, kdy uživatel bude nucen aktualizovat.

Pro BFU může příslušný ISP zřídit informační stránku s informací, co ma BFU udělat, aby se na svou pornostránku dostal (které budou prvními na tomhle systému)

Protože můj návrh je routovatelný s IPv4 routery bez nutnosti číst options, můj návrh se routuje stejně rychle, jako obyčejná IPv4. Drobná komplikace bude jen na bráně ISP

Nevidel bych problem ani v CAT3 :D

Co vím, tak celý standard je jen o tom, že se něco vymudrovalo. Praxe posléze začala ukazovat, že tam jsou velké problémy.

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

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?

Tady ne, tady sedím na páteři. Doma ano. Veškerý obsah, co nabízí IPv6 konektivitu je pomalý, protože to musím tunelovat (přestože stejný obsah běží i po IPv4 rychle). Takže to mám vypnuté.

(upřímě, nejsem moc šťastnej, že někdo zná adresu mého počítače)

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.

Ano, je to protokol treti vrstvy, ale ta netmaska /64 byla navrhovana s ohledem na to, ze druhou vrstvou je nejcasteji ethernet (na POS jaksi potreba neni)... Alespon to tak vzdycky kazdy zduvodnoval.
Krome toho, na jinych L2 technologiich si nikdo na autokonfiguraci bud prilis nehraje, nebo, ac se to nezda, je to zase de facto ethernet (802.11 apod.) a delsi identifikatory, nez 48 bitu, se prakticky nevyskytuji.

IPv6 adres je hodne, ale pokud s nimi budeme plytvat, muzeme za par let zjistit, ze jich neni *zas tak* moc. A EUI-48 take existuje...

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

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

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.

Dobrá schíza. Na jedné straně možnost změna adresy při změně topologie (závislost na DNS?), na druhé straně požadavek na zachování adresy u mobilních zařízení, které topologii dynamicky narušují každým okamžikem. Vidím to bledě.

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.

"Ono se něco takového časem určitě objeví, až skutečně dojdou adresy"

Adresy už došli. A obávám se, že se nic kromě IPv6 neobjeví. A důvod:
Všichni do IPv6 už vložili tolik finančních prostředků, že zahodit IPv6 a začít s něčím novým je holý nesmysl.

Není potřeba vyměnit všechny krabičky. Předpokládám, že budu provozovat IPv4 uvnitř sítě minimálně dalších 10 roků a to i v době, kdy nebudu mít IPv4 připojení ven.

V případě většiny technologických prvků (kamery, přístupový systém, tel. ústředny, ...) nepotřebuji, aby byly dostupné přímo z Internetu, takže je nemusím měnit. A pokud z nich budu potřebovat přistupovat ven mimo svoji síť, tak použiji proxy či NAT64.
Pro správu z domova již nyní používám VPNku, takže ani zde nebude v budoucnosti problém - pouze při případném upgradu VPNky musím dávat pozor na to, aby uměla tunelovat i IPv4.

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.

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.

Tak hlavním smyslem je lépe sledovat pohyb uživatelů... pokud bude mít každý jednoznačnou IP adresu :-)

privacy extensions?

A pak si o tom něco přečetli a zjistili, že existují Privacy Extensions.

Jehoz opakovany vypocet v kazdem IPv4 routeru znamenal dalsi vypocetni zatez a tedy i zdrzeni? V IPv6 toto odpada.

Hledání ve statické tabulce má složitost 1. Nezáleží na počtu záznamů. Technologie existuje, takže je to jen otázka ceny.

Jinak i v obchodu s IPv4 si dokážu představit výměnu rozsahů. Pokud ISP dostane přidělený rozsah 123.1.0/17 následně 123.15.0/17 a následně, nevidím důvod, proč by si ho nemohl vyměnit za 123.1.128/17 a získat 123.1/16. Na obchod s adresami ještě dojde a bude se řešit přesně takto. Když lze měnit prefixy v IPv6, lze to dělat i u IPv4.

No normální vyhledávání má složitost 1. Pokud máte různě dlouhé prefixy, lze všechny zarovnat na nějakou optímální délku a záznamy pro kratší prefixy duplikovat. A těch pár, co jsou delší pak řešit jako výjimku, třeba tak, že tabulka je úrovňovaná. Například (netuším, jak je to udělaný, ale jak bych to dělal já) pokud mám většinu záznamů s prefixem do 16 a pár záznamů 18, kouknu podle 16bitů do tabulky co má 65536 záznamů. Tam kde se mapují ty 18bitové prefixy najdu odkaz na další tabulku, kde podle zbývajícíh dvou bitů najdu 4 záznamy.

Naopak prefix /14 vložím do tabulky 4 stejné záznamy pro všechny kombinaci zbývajícíh bitů

Výměna sítí předpokládá, že ISP domluví (nikoliv donutí). Narážíte ale na jiný problém a to že IPv4 neumí přidělovat adresy dynamicky. Ale to není problém protokolu samotného, ale neexistence přidružené technologie, která je zahrnuta v IPv6, ale mohla by fungovat samostatně.

(upřímě, vždycky mě naštve, že ve veřejné Wifi síti nemají ani DHCP, když ho má kdejaká krabička s anténkou).

InterfaceDef interfaces[256];
unsigned char routingTable[65536];

InterfaceDef &lookup(Prefix16 &prefix} {
  return interfaces[routingTable[prefix]];
}

Už jsem to udělal nahoře. ale udělám to ještě jednou:
/16 = 64KB
/17 = 128KB
/18 = 256KB
/19 = 512KB
/20 = 1MB
/21 = 2MB
/22 = 4MB
/23 = 8MB
/24 = 16MB

Dvoúrovňové hledání má také konstantní složitost. V první úrovni mohu hledatr /16, a pokud k záznamu napíšu počet dalších bitů, vyjde mi délka tabulku v druhé úrovni, kde hledám taky konstantní složitosti. Je pravdou, že v tom případě bych asi záznam nemohl být jednobajtový, ale třeba 4 bajtový (/16 = 256KB), ale zas bych měl víc možností. Klidně Vám to napíšu jako aplikaci v C++. Chcete?

Nikoli může. Cena za takové řešení by byla o dost vyšší, než IPv6 řešení, a platila by se do té doby, než by se z IPv4-s-komplikacemi přešlo na IPv6. Když se řešilo, co s nedostatkem adres a rostoucí fragmentací v IPv4, odpovědní lidé to naštěstí dobře věděli, proto zvolili jednodušší a levnější řešení – tedy nový protokol, pojmenovaný pak IPv6.

Naiva si myslí, že IPv6 vyřeší nějakou fragmentaci :-D

Pokud se nebudou ručně rozsahy defragmentovat, tak fragmentace hrozí i na IPv6. To je základní pravidlo jakéhokoliv systému rozdělování velkého bloku na malé kousky. Můžeš dostat větší kus, nebo dva malé, záleží na tom, jak si o ně řekneš. Nikdo ti nezaručí, že ty dva malé kousky půjdou pak spojit do jednoho velkého. A nepomůže tomu ani to, že zjemním dělení, nebo že si od začátku budu dělat rezervu, kdyby náhodou každý chtěl ještě kousek. IPv6 adresy dojdou, zaručeně. A dojdou stejně rychle, jako IPv4 adresy. Dokud jich bude hodně, objeví se způsoby, jak s nimi plejtvat, a až začnou docházet, narazíme na fragmentaci.

Až Vám provider sebere veřejné IPv4 adresy a strčí Vás za váš oblíbený NAT, tak celá vaše VPN a OWA Vám bude na dvě věci. Kapišto?

Ty adresy totiž nejsou vaše víte? A dokonce ani providera. A proč by to dělal? No možná neudělá, když zaplatíte.

Vtip je v tom, že s IPv6 si každý požádá o dostatečně velký rozsah, aby nemusel za chvíli žádat znova (existuje spousta nástrojů, jak to zařídit – třeba poplatek za jednu žádost). Navíc teď se přiděluje jenom menší část adresního prostoru IPv6, takže pokud by se ukázalo, že strategie přidělování je špatná, může se zvolit jiná strategie a začne se rozdělovat další část adresního prostoru – se zachováním protokolu IPv6, takže nebude nutné měnit infrastrukturu.

IPv6 adresami se bude plýtvat. Ale uvědomte si, kolik jich je – pokud vezmu celý adresní prostor, připadá na jeden mikrometr zemského povrchu přes 600 miliard IPv6 adres. Já bych tedy na to, že dojdou za 25 let, nesázel.

Smrťova IP adresa je: DEAD::1
:-)

Jeden křičí, že je IPv6 jediná cesta, jak překonat došlé adresy, druhý křičí že nejde jen o zvětšení prostoru. Lidi dohodněte se! Já vím, že IPv6 přináší tisíce a jedno vylepšení navíc, ale v tom je ten největší problém, prostě se bude hůře prosazovat. Zvedá to cenu toho HW a tím snižuje ochotu ISP do toho investovat.

No vidím tam navíc IPv6 :-) A pokud tam je navíc IPv6, vidím tam navíc DHCP a NAT a minimální možnost využít existující technologie v krabičce na nový protokol. Takže tam nakonec bude 2x stack, 2x Firewall, 1x NAT, 2x DHCP (no dobře, to druhé se jmenuje oznamování směrovače)

No a už si Skype vsimnul, ze některé sítě jsou komplet IPv6 schopné provozu? Nebo pořád budu z Brna do Prahy telefonovat přes Oslo, jenom proto, že tam někde byl volný node s veřejnou IPv4 adresou.

Uz se tesim, az zacne RIPE odebirat IPv4 adresy vsem kteri se je pokousi prodavat, to bude teprve prdel.

Asi ste poslednich 10 let encet zadny diskusni fora nebo nebyl na netu, Denne se na milionech strankach resi, proc uzivateli nefunguje to ci ono (libovolna sitova sluzba, od VoIP, pres p2p po hry a dalsi) a vzdy je navine NAT. Je celkem jedno jestli si to blbe nastavil uzivatel nebo jestli mu to blbe nastavil ISP ... vzdy je NAT pricinou toho, ze neco nefunguje uzivatelsky privetive = nestaci to zapojit s spustit.

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

Nejak sem si nevsim, zeby "pred koncem roku 2010" === "postupne se na tom pracuje", kdyz mame 10.2.2011.

Jinak receno statni sprava sere nejen na ovcany, ale i na narizeni, ktery prijdou shora (ono aby ne, kdyz to uz nikdo nekontroluje a nikdo za to neodpovida).

Ale co si budem rikat, jeste donedavna chodila kovarova kobyla .... ze Lupo ?

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

Ne, Lupa je v tom nevinně - už dost dlouho byla dostupná přes ipv6.lupa.cz ale samotné www.lupa.cz nemělo AAAA záznam. A z dobrého důvodu, stejně, jako třeba Google taky nemá AAAA záznam pro všechny. Důvody jsou zmíněny v tomto článku: spousta té IPv6 konektivity je přes automatické tunely a proto buď nepříliš efektivní, nebo špatně fungující až po "unesené" IPv6 routery, tedy nespolehlivé.
Lupa a Root to nakonec riskly, ale pro Google (hlavně Youtube) by případná snížená přenosová rychlost mohla mít nepříjemné důsledky.

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

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

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.

Pletete, tak například IP adresa by se dala rozsat jen ISP a číslo počítače v podsíti by se dalo hodit třeba do options.

IPv6 řeší kromě adres i routování, oznamování cest, autokonfiguraci, broadcast a multicacast, hledání nejbližšího a podobně, což se dneska dá docílit i jinak a funguje to.

Zlaté pravidlo platí, pokud to funguje, tak se v tom nehrabat.

„Drobná komplikace“ znamená několikanásobně náročnější zpracování. Vypadá to, že si představujete, že internet je nějaká hierarchická struktura, kde každý ISP má jednu bránu, kterou je připojen k internetu. Tak to ale není.

Ten váš návrh znamená jen konvzervaci současného stavu NATů, jenom byste přidal možnost adresace strojů za jedním NATem. To by ale současný problém nevyřešilo.

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) nemáte pravdu. Protože můj návrh používal dál IPv4 a u systému, kde nebylo třeba přecházet ze sítě do podsítě by se fungovalo postaru (návrh zněl dát ADREXT do options, což většina krabiček zvládne transparentně)

b) IPv6 tohle nepotřebuje?

- všechny programy musíte znovu přeložit
to IPv6 taky, navíc, tam dokonce musím i ty, které bych tady nemusel. To že mohu v síti IPv6 dál fungovat na IPv4 je dáno podmínkou dualstacku.

- musíte upravit DNS
Nemusím, současné služby zůstanou nezměneny, přidají se jen záznamy u služeb, na které už nevystačily normální adresy. U IPv6 musím všechny záznamy a ještě pořád nemám jistotu, že se ke mě klient dovolá

Rozdíl mezi mým návrhem a IPv6 je tím, že IPv6 vyžaduje hromadné nasazení, zatímco můj návrh umožňuje postupný přechod. Ten největší argument: nepoužívají to uživatelé => není motivace pro ISP => není motivace vytvářet služby => nepoužívají to uživatelé, to je nekonečný cyklus, který se bude jen velmi obtížně překonávat... je to dáno nutností hromadného nasazení.

Dokonce už vznik článku "rychle zaveďme IPv6, než nám to nařídí stát" jasně dokazuje, v čem je problém. A bojím se, že nakonec někdo přijde a vydá na to zákon, protože bude mít pocit, že trh selhal. Jenže trh neselhal, jen nasazení IPv6 je tak komplikované, že je levnější hackovat současnou technologii. Že to je přirozený vývoj, zatímco celý humbuk kolem IPv6 je uměle nafouknutá bublina. Teď když došly IPv4 adresy se zase o tom mluví. Ale bude následovat pár let, kdy to ještě bude takhle pomalinku hnít.

To si nemyslím, navíc u IPv6 musíte vyměnit všechno do poslední krabičky. Já jsem se tomu chtěl vyhnout.

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.

Ony se ty svody na spouste mist kvuli digitalu menily stejne, protoze puvodni byly ladeny na jine frekvence a 30let stara kabelaz taky uz ma nejlepsi leta za sebou.

Zpetna kompatibilita neexistuje, kdyby to slo, tak to tak nekdo udela. Flakat kamkoli cokoli do paketu je hovadina, kterou muze vymyslet jen totalni hlupak ktery o routovani netusi ani zbla. Naopak, zpetna kompatibilita je prokleti, na ktery dojede x86. Aktualne to vypada ze ji tezce prevalcuje ARM.

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

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.

Ale nic noveho.

Ackoliv si to asi serial neklade za cil, primlouval bych se spis za clanek ve stylu IPV6 bfu end user connectivity cookbook(nejlepe s konkretnimi priklady z ceske kotliny), at uz na lupe nebo na jinem spratelenem serveru, coz by imho prispelo rozsireni IPv6 vic nez technicke predstavovani noveho protokolu a nasledna megadiskuze na 2 hlavni tema proc to nema nat, popr. ja bych IPv6 designoval mnohem lepe.

Je videt, ze moc zakazniku nemate .... pri vasich nazorech a nejspis i vedomostech a sluzbach, se neni co divit.

A nebojte se, oni vas zakaznici do IPv6 dotlaci, a nebo skoncite uplne. Ono by trebas stacilo, aby WoW preslo na IPv6, klidne i nepovine s tim, ze kdo pojede po IPv6 dostane bonusovej mec. A hnedle by se ozvalo par milionu zakazniku co pozaduje IPv6 a vcera bylo pozde.

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.

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?

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

Ad dynamická délka adresy. totiž ono o to velké routování jde. Síť nikdy nebude každý s každým, ale nějaká hierarchická úroveň tam bude. Pokud si velké routery budou všímat například prvních 4 čísel, nepotřebují vědět, že paket obsahuje další upřesnění v rámci podsítě. Organizace od ISP k uživateli a jeho pěti domácím počítačům pak bude umožňovat právě další čísla v adrese. ISP si třeba vezme další tři, podle počtu zákazníků, a uživatel si přidá jedno, nebo dvě, nebo taky pět, podle svých potřeb.

Podle délky adresy by se pak poznalo, do které podsítě se paket má vydat. Při průchodu sítí se pak adresa přijemce upravuje podle aktuální podsítě a adresa odesílatele se doplňuje tak, aby jednoznačně identifikovala zdrojovou podsíť aktuální síti. Nevím, ale jestliže současné routery zvládnou implementovat složitosti IPv6, nějaké šoupání s čísly v rámci nemůže být problém.

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

Ono se něco takového časem určitě objeví, až skutečně dojdou adresy

- přidá se nové options do paketu (ADREXT)
- přidá se položka do SOCKADDR možnost toto ADREXT nastavit
- upraví se existující NAT, který umožní vytvořit spojení s počítáčem vnitřní síti podle adresy v ADREXT a přepíše adresu příjemce podle ADREXT... a odebere ji z options.
- do DNS se přidá možnost zadávat rozšířené adresy, třeba takto 77.74.72.76.10­.0.1.20 (DestAddr: 77.74.72.76, ADREXT: 10.0.1.20)

Počítač vnitřní síti může mít klasické IPv4 rozhraní.

Provoz sítě IPv4-ADREXT v IPv4.
Pakety po starém protokolu nemají Options: ADREXT
Pakety v novém protokolu mají vždy Options: ADREXT
Pokud odesílatel má ADREXT a posílá paket přes NAT který to neumí, dochází ke klasickému překladu adres a portů. NAT by měl options zachovat.
Pokud odesílate má ADREXT a posílá paket pres NAT, který to umí, NAT přeloží poze SRCADR, aby umožnil routování paketu po IPv4 a odpověď došla zpět na NAT.
Pokud příjemce neumí ADREXT, používá jen IPv4 adresu
Pokud příjemce umí ADREXT, použije rozšířenou adresu. Pokud náhodou leží na veřejném uzlu (nebo v DMZ), bude ADREXT rovno nule, což je adresa samotného uzlu.
Při zpětném překladu z veřejné IP do lokální se ADREXT přepisuje do DESTADR a nastavuje na nulu, protože v rámci lokální sítě je takový počítač sám sobě uzlem.

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

No osobně mi IPv6 přijde tak 10x složitější, než IPv4, takže chápu, proč nové routery jsou násobně dražší a žerou větší výkon a víc topí :-)

Obrovskou chybu se tvůrci dopustili úplně na začátku a to snahou vyřešit všechny cíle v jednom balíku (all-in-one). To nikdy nefunguje. Kdyby šlo jen o množství adres, dokázal bych si představit 1000 a 1 alternativní řešeních. Od prostého zvětšení prostoru na zápis adresy, až po nějakou formu relatovního adresování s dynamickou délkou adresy, ve kterém by adresy nikdy (!) nedošly.

Bohužel, výsledkem je "úplně jiný protokol" nejen nekompatibilní se současným HW architekturou, ale i s typickými zvyklosti na všech vrstvách ISO OSI. Nedivte se, že existuje taková neochota. Rozběhat služby na IPv6, tak aby to fungovalo všem, i těm, kde IPv6 protokol je "zapnut", ale nefunguje, kde provideři neimplementují všechny aspekty toho velkého all-in-one balíčku, to stojí hodně úsilí a prostředků

Účtuje se to třeba jako administrativní poplatek spojený s evidencí přidělené adresy. Jo, a vy fakt věříte, že k tomu dojde?

Vy jste asi nikdy nepracoval s enterprise softwarovým systémem, že? Ano, stačí nahradit třídu za třídu. A pak najít všechny zdroje ke všemu a doufat, že všechny sedm let staré zdrojáky půjdou přeložit současným kompilátorem. A že všechny 3rd party libraries taky umějí IPv6, protože upgrade na novou 3rd party je kompletní nový projekt. A modlit se, aby se nerozhodila interoperabilita s COBOLovými komponentami. A pak provést kompletní otestování celého systému aplikací, vyřešit deployment a vymyslet, jak tu aplikaci přepnout bez odstávky. A celou dobu tiše doufat, že v miliónech řádek zdrojového kódu je jen málo míst, která fungovala jen náhodou a při změně čehokoliv se rozsypou.

A pak se uživatel s bájnou IPv6 konektivitou připojil přes CPE nakonfigurované dle rfc6092, připojil se na WiFi v hotelu nebo na Eduroam ve škole, kde z mnoha důvodů příchozí spojení jsou zablokována. A nic s tím neudělá. A seznal, že bez prostředníků si ˇ(nebo jemu) stejně nezavolá. A přes Skype jo. A seznal, že aby měl doma pořád zapnutý počítač proto, že jednou za měsíc potřebuje jeden dokument nebo fotku, je stejně trochu luxus. To fakt není IPv6 killer-use-case.

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

Zadrátovanou? To znamená, že třeba je tam zadrátováno, že prefix 7.0.0.0/8 jde vždycky na interface já nebo 4?

prefix /16 znamená 65536 adres. Nemám představu, kolik mají routery interfaců, ale pokud by jich měli méně než 256, stačí mi 64KB paměti. To je opravdu náročné.

prefix /24 znamená 16mil adress. I tam si vystačím s 16MB. Hustý

prefix /32 by znamenal mít 4GB paměti.

To jsou kupecké počty. Netuším, jak dlouhý záznam musí v tabulce být, ale statická tabulka by přesně takhle mohla vypadat. Říkáte rychlé paměti, dobře, to nejspíš zvedne cenu. Na druhou stranu, tabulka bude nejspíš po většinu času R/O, takže bezkolizní přístup je jednodušší.

Neučte mě to, zabývám se programováním, dokážu si to představit.

Chápu, že náročný může být protokol pro sestavování tech tabulek, který neustále vyhodnocuje provoz na síti a hledá rychlejší cesty. Ale ten může fungovat vedle bez zatěžování vlastního routování.

Gratuluji, vymyslel jste něco, co je ještě mnohem komplikovanější než nasadit IPv6 :-))

Jo, pán je teoretik :-) To jste mohl říct rovnou a nemuseli jsme dál pokračovat

- v současnosti je v BGP tabulkách >300 000 záznamů, tj. jsou tam sítě rozhodně delší než /16, pokud chcete složitost O(1), tak musíte počítat se sítěmi alespoň /24, tj. routingTable[16777216­]. Protože pokud jinak uděláte odskok do menší tabulky a tam budete vyhledávat, tak dostanete složitost třeba O(1+log2(256))
- toto rozhodování nemůžete dělat centrálně ale decentralizovaně, většinou pro každou kartu v routeru zvlášť.

Spočítejte si jenom množství spotřebované paměti pro router s 256 interfacy a pak pokračujte v mudrování.

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.

A co vas nuti to takto vnimat? Pokud se podivate na IPv6 velmi zjednodusenou optikou, tak se adresni prostor proste jen zvetsil z 32 na 128 bitu. A nejen to, pro sitove spravce prinasi dalsi zjednoduseni v podobe ujednoceni sitove masky - zjednodusene receno naopak odpada dumani nad tim, zda je na subnetu /30, /28, /26, /24... vsude s IPv6 mate mit /64, tedy pokud nejste RFC ignorant... :-)

Dynamicka delka adresy se velmi slozite implementuje v praxi. Ted opravdu nemam na mysli nejake softwarove routery (aka krabicky u lidi doma), ale velke platformy routujici desitky-stovky gigabit... kde se pouziva ponekud jinych technologii.

Muzete mi rict, se kterym soucasnym HW neni IPv6 kompatibilni? :-) A ze IPv6 neni kompatibilni s ISO/OSI? V tom pripade si dovoluji prohlasit, ze ISO/OSI model vubec nechapete. Realita je takova, ze vyssi i nizsi vrstvy jsou nedotceny, jedine co se meni je treti - sitova - vrstva.

Tak neco takoveho zkuste postavit... pokud mozno na HW :) Na papire se mudruje dobre... horsi je to prevest do bezneho zivota.

Don't feed the troll

Přijde správce sítě k Bohu a ptá se: Bože, proč jsi mne nezachránil, když docházely IP adresy?
Bůh: když docházely adresy poprvé, poslal jsem ti CIDR. Ale ty jsi nic nevnímal. Když docházely IP adresy podruhé, seslal jsem ti NAT, to už ti opravdu teklo do bot, ale stále jsi nic nedělal. Pak došly IP adresy potřetí. A ty jsi také nic neudělal. Proč se tedy divíš?

:-)

Mimochodem, pouzivani /64 je ponekud nesmyslne, kdyz mac adresa ma 48 bitu. Nepovazuji za nezbytne vedet, ze IPv6 adresa byla pridelena pomoci EUI-64 (ono to ani neni spolehlive, protoze IPv6 adresu, ktera jako pridelena by EUI-64 vypada, mohu nakonfigurovat i staticky), cili /80 mi prijde jako vyrazne logictejsi i efektivnejsi rozsah pro takove ucely. Cili ja mam pro RFC ignoranty pochopeni, dokonce lze rici, ze i jiste sympatie... ;-)