Názory k článku IPv6 Mýty a skutečnost, díl IV. - Podpora autokonfigurace

Určitě by se našlo něco co projde minimálně většinou stávající infrastruktury.

Všichni tady celí nažhavení očekáváme již několik týdnů tvoje geniální návrhy - a ono stále houno, že.

už se o tom rozhodlo a vy se můžete tak maximálně přizpůsobit.

Tak proč prostě nenapíšete, jak byste to udělal? Výkřiky o tom, jak je IPv6 špatně a mělo se udělat staré-nové-IPv4, jsou pod každým článkem o IPv6. Diskuse pravidelně končí tím, když se někdo zeptá na způsob realizace – odpověď pokaždé chybí. Co jiného než dehonestaci si zaslouží „nápad“, o kterém dotyčný musí vědět, že je to nesmysl?

Mnohe z toho co tady popisujete bylo pred 15 lety zvazovano v nekolika navrzich. IPv6 jak jej zname dnes nebyl jediny kandidat mozneho reseni (viz. http://tools.ietf.org/html/rfc1752#section-7- docela dlouhe pocteni, ale velice poucne).

Dnes uz jsme asi ve stavu kdy neni cesty zpet. IPv6 je naprosta katastrofa, ale na druhou stranu hodne prace do nej uz bylo investovano. Dnes uz je k mani fungujici routing, sockety, DNS, vyvinute chipy, implementovane firewally... Je toho vic nez se zda. U jinych reseni neni k mani ani nijaka specifikace a neni vylouceno ze by pripadne dopadla stejnou katastrofou jako dnesni IPv6.

Lepsi cesta se mi jevi jako dovedeni IPv6 do pouzitelneho stavu (byt to bude trvat jeste dalsich 20 let).

Ještě větší blbec než jsme doufali.

Můžete být trochu konkrétnější koho přesně myslíte tou mlčící většinou, která provozuje IPv6 ve vetší infrastruktuře?

Podle mě je zatím IPv6 všude maximálně jako experimentální hračka, která když přestane fungovat tak to nikomu příliš vadit nebude (pokud si toho někdo vubec všimne).

Ono je rozdíl mít "rozjeté" IPv6 někde na páteři a nebo provozovat IPv6 až k uživatelům. Je to asi stejný rozdíl jako mít vyřešenou veřejnou dopravu a nebo mít v poli postavené koleje které vedou od nikud nikam. Obojí můžete deklarovat jako dopravní řešení (=zavedené IPv6) s tím rozdílem, že druhou variantou nikoho nepřepravíte.

Tohle k ničemu nevede. Skrze tyhle hádanky se příliš daleko nedostaneme. Bohužel toto ja častý postoj IPv6 protagonistů. Tvrdí jak je všechno v pořádku a jak vše nádherně funguje, ale nesmíte to chtít vidět.

Tenhle postoj zavádění IPv6 ale příliš nepomáhá.

Příklad se školami je v pořádku. Kde jinde by ostatně měly tyto aktivity vznikat primárně. Ostatně i kedjaký ISP se prostě apoň nějak IPv6 zabývá. Problémem je, že nikdo dnes není na IPv6 závislý. Když se všude IPv6 zítra vypne tak se vůbec nic nestane - nikomu nebude chybět. Tím nevzniká žádný tlak na to aby se věci v IPv6 uvedly do použitelného stavu.

Mno uvidíme za dva tři roky...

Céče, ty jseš hotovej zneuznanej génius, tobě snad upřeli Nobelovku, ne? Zatímco na tom "IPV6-SHITU" jak říkáš se pracovalo přes 15 let, tak ty to zřejmě vyřešíš za 2-3 roky sám a daleko lépe. :-))))

Pardon, ale nechápu, proč přes DHCPv6 nejde předat výchozí bránu? Ten server ji zná (protože nějakou má a je ve stejné síti, tedy je stejná i pro ostatní nody v té síti) a tak ji může předat. Je problém v Implementaci IPv6 na strané klientů, kteří nepředpokládají, že můžou získat vvýchozí branánu od jinud než od směrovače? A proč toto chování klentů by nešlo změnit?

V siti kde se nepocita s ipv6 je vhodne ipv6 zakazat i z mnoha jinych duvodu.

Tak tu sit muzete proti nezadoucim klientum zabezpecit i radou jinych nastroju, napriklad 802.1x, poskytne vam to ostatne vyssi uroven zabezpeceni i pro IPv4. Samozrejme, utoku ze strany tech, kterym duverujete a do site je pustite, tim nezabranite.

Ještě máme blok E. Tam je 268435456 adres. Možná by stačilo to přidělit jako adresy sítí a adresy podsítí implementovat pomocí třeba Options.

Pokud jsem to z té diskuse správně pochopil, tak jedný důvod, proč výchozí bránu šířit SLAACem je ten, že pří pádu jednoho směřovače a připojení druhého se celá síť automaticky překonfiguruje. Jenže to jde přece zařítit i přes DHCPv6 - když klient nemůže komunikovat, požádá server o novou funkční konfiguraci. A DHCPv6 server se může autokonfigurovat SLAACem, ten toho více než prefix a výchozí bránu ke své práci nepotřebuje.

Nebo si napsat vlastni software, ktery bude mit jiny nazor...

a jak klient pozná, že nemůže komunikovat kvůli tomu, že vypadla default gw a ne třeba koncový uzel? Stejně by to vedlo pouze k duplikování protokolu RA. Něco jako ... nemůžu komunikovat... co s tím? Zeptám se jestli žije router. Router nežije, co teď? Zeptám se DHCP serveru na nový router. DHCP router musí vědět co udělat, když router vypadne (definujeme nový protokol)

No, asi bych přece jenom zůstal u toho RA.

sakryš... DHCP server musí vědět... (jak to zjistí? Asi pomocí RA).

Co se týče toho MikroTiku, přesněji RouterOS, tak volbu Autonomous tam vidím, stejně jako volbu "Advertise DNS" pod /ipv6 nd (a funguje). Takže možná koukat důkladněji.
Koukám do 5.0rc10, jeslti to je i ve stabilní řadě 4.x nevím.

A já bych šel ještě dál s tím, že takový nápad tady na Lupě pravidelně pod každým článkem o IPv6 předhazují jistý novacisko a admin.

Pokaždé se jim někdo pokusí vysvětlit, proč to je z hlediska kompatibility ještě větší problém, než IPv6 a hup, pod dalším článkem se vše opakuje.

A funkčního návrhu jsme se od něj opět nedočkali... to je překvapení. :-)

No, uprimne, ona se nabizi otazka, nakolik ti lide, co zastupovali ony firmy v IETF, skutecne stali za zajmy tech spolecnosti a nakolik jim slo o jejich vlastni ideje, ktere jen prosazovali pod neci hlavickou...

jediným zájmem firem je vydělávat peníze, nějaké altruistické snahy o lepší síťové zítřky bych jim rozhodně nepřisuzoval.

<blockquote>server ji zná (protože nějakou má a je ve stejné síti, </blockquote>

Chybný předpoklad. V IPv6 můžete mít DHCP server mimo linku. Proto DHCP nemůže přidělovat výchozí bránu.

Komu by to k čemu bylo? Facebook dlouhodobě poběží na IPv4 tak jak tak, stejně jako většina důležitých služeb (kdyby ne tak jejích provozovatelé můžou zrovna zavřít krám a jít na pracák). V takovém případě poskytovatel udělá raději 3 NATy za sebou, než by šel do IPv6 (protože jinak by také mohl jít rovnou na pracák).

Navíc při konverzi IPv4 na IPv6 musíte řešit konverzi DNS z AAAA na A, ale to jsou věci technické takže snad i řešitelné.

Aha, tak to bude asi hodně tajné, když vetšina z nás ani netuší...

Osobně si myslím, že v jisté míře to mají nasazené třeba vysoké školy. TUL, VŠB, VŠE, atd., ikdyž někdy s omezeními.

http://www.cesnet.cz/ipv6/wg/

mikrojehlu ve stohu?

Popravdě řečeno v podobné konfiguraci mám problémy spíše s mobilními klienty, kteří jsou připojeni různě přes IPv4, jak nejrůznější NATy se snaží intelignetně strkat pracky kam nemají, hlavně do VPN protokolů pro road-warriors. Je vtipné pozorovat, jak někde funguje PPTP, jinde zase jen IPsec, někde ani jedno. Jindy je síť, kde neprojde HTTPS (takže i SSTP je nepoužitelné), ale IPsec bez problémů. Jsou místa, kde z jednoho notebooku funguje PPTP, ale vedle připojený, prakticky identický notebook se nespojí, ten projde zase přes IPsec, ....
Podobně vesele se chová kolikrát SIPový VoIP, pokud klient má být mobilní a připojovat se přes růzé sítě (někde to NAT zprzní, někde ne, jednou je dostupný venkovní STUN, pak zase není, tak to některé položí a klient musí mít několik konfigurací podle toho, kde právě je).

4/ Radši pošleme pakety na disketě poštou, protože tahle nesmyslná splácanina samozřejmě nebude fungovat.

Jestli to chápu dobře, tak ty adresy v paketech bude měnit provider E1 na hranici své sítě do starého internetu a balit je do adres se zdrojovou adresou svojí.

1. potřebujete změnit DNS tak, aby existovala zpráva, která na dotaz www.Z3E2.cz odpoví IP_E2:IP_Z3 - takže to je první protokol, který musíme změnit

2. stále nám tu visí problém výkonu při přepisování hlaviček

3. nevím jakým způsobem rozliším IP adresu uvnitř E1 od adresy ze starého internetu, pokud budu chtít komunikovat se Z4 nebo Z2 a shodou okolností budou mít stejné adresy (nepředpokládám, že by se využily privátní adresy, protože to může být pro jednoho providera málo)

Dokážete si představit situaci bez relaye? Já v IPv6 ano.

RFC 1256

50% provozu mam na IPv6, a ano, jde o p2p site - konecne end to end konektivita, konecne postupne mizi neustale se opakujici dotazy jak nakonfigurovat NAT a proc to ci ono nefunguje …

Tomu nazoru rozmumim, nicmene svet neni staticky a prubezne se meni.

Je pouze otazka casu kdy nektere silenosti typu nastavovani adres pres SLAAC nebo DUIDy v DHCP budou pod vlivem praxe vykopnuty a nahradi je jiz dnes fungujici pouzitelne veci. Rada veci v IPv6 se da dovest do rozumneho stavu pouhym zrusenim pseudozlepseni (bude nekomu chybet SLAAC, nahodne generovane adresy atd., SEND ?)

Myslim, ze upinani se k "jinemu reseni" ktere je kdesi v oblacich je uplne totez jako tvrzeni, ze IPv6 je ok - akorat z druhe strany. Realita se zpravidla odebere nekde tim stredem.

Dalsi faktor je taky, ze firmy uz do IPv6 nainvestovaly nemale prachy a proste je budou chtit zpet. Nejaky zpusob jak to udelat si uz jiste najdou - nebudou to ostatne delat poprve :-)

Hmm, "moje" firmicka s par stovkami IP zarizeni ma (mimo jine) IPv6 a vpohode to funguje. Nikde zadny problem.

Na IPv4 maj vsici vsechno zakazany prave kvuli tomu podelanymu NATu. Kdyz maj jednu IPv4 adresu, tak se bojej, ze se dostane na blacklisty pokud jim tam nekdo prinese zacervenej stroj.

Pokud budu mi desitky prefixu IPv6, tak jednoduse jeden vyclenim pro anonymne dostupnou sit (napr v hotelu) a bude mi naprosto sumafuk co tam kdo dela.

Když odhlédnu od toho, že je to mrtvý návrh, tak vlastně žádnou výchozí bránu přes DHCP nekonfigurujete, protože se zjistí přes – chvilka napětí – ICMP. Co mi to připomíná? IPv6?

Ano, tuto úvahu také uvádím. Nepředpokládám, že to bude zcela bez firewallu a otevřeno všechno všem, to by blyo asi brzo pěkné semeniště. Ale je možné, že bude méně restriktivní, než současný stav. Přeci jen asi až dojde na strkání do blacklistů IPv6 prefixů, tka je otázka, zda blecklistaři budou strkat /64, pak takový guest segment je pro firmu relativně v pohodě nebo natvrdo bude strkat /48, což už by nebylo dobře (nebo inteligentně v DB hledat, do jakého segmentu daná IPv6 patří a ten blacknout celý, což by tkaé firmu nepotěšilo, případně celého ISP, pokud nemá publikovanou delegaci).
Samozřejmě asi pro krytí zad to bude chtít nějaký monitoring a logging, už jen kvůli případné buzeraci od státních ouřadů - jaká mac byla kdy připojena a s jakou veřejnou IP šla ven (takže pro nejmenší jednoduchost třeba firewall nedovolující privacy extensions a k tomu by byl fajn třeba příznak do RA nebo DHCPv6, že klient nemá používat PE a podobné).

Dobrá tedy,
zatím jste nesklouzl do příliš velkých invektiv, takže Vám ještě odpovím. Budu reagovat obecně na návrhy, které tady zazněly (házím to sem a ne pod Vaši odpověď, protože odpověď je dost dlouhá a vznikla by tam uprostřed nepěkná nudle).

1. Spousta lidí není ze současné podoby IPv6 a zejména její implementace nadšená, ale uvědomují si, že jde o výsledek jakéhosi konsensu a některé části se budou vylepšovat v okamžiku, kdy se objeví další problémy.
   
   Já sám nejsem nadšený z některých částí, zejména autokonfigurace a SOHO oblasti, ale jsem v tomto ohledu pragmatik. Vy jste příkladem zarytého odpůrce a nemá smysl Vás přesvědčovat, problémem je, že ale šíříte FUD mezi ostatními, a představujete si, že všichni, kdo nesdílí Váš názor musí nutně při vyslovení IPv6 skákat radostí do stropu a volat Haleluja.
2. Zavádění jakékoliv novinky znamená nové investice a vývoj v oblasti se neustále zrychluje. Tato "novinka" je tady dostatečně dlouho, ale nebyl o ni příliš velký zájem. V oblastech, kde už je nějakou dobu nasazena se už problémy snad odlaďují/odladily.
3. RFC se doplňují novými, některá se úplně ruší, apod. V případě IPv6 už se to stalo několikrát (kdo si dnes ještě pamatuje A6 a DNAME). Vývoj IPv6 může sice ukázat některé slepé uličky, které v době jeho vymýšlení vypadaly lákavě, ale vývoj takového alternativního protokolu by trval určitě min. kolem 3-5 let do nasazení.
4. Pokud bychom chtěli využít stávajícího IPv4 a doplnit ho o nějaké změny, bude to zasahovat do protokolů ostatních vrstev.
   • Starší návrhy, které zde zazněly v diskuzích od Vás a Vašich kolegů měly ten problém, že zřejmě nepůjde kvůli hloupým routerům zachovat č. verze na 4, ale bude nutno vytvořit jiné. Tím pádem bude asi vhodné změnit i ID protokolu v rámcích 2. vrstvy. Zvládnou to stávající směrovače bez výrazných zásahu do firmware?
   • IP options se nehodí, protože se jedná o strukturu proměnné délky a jejich pořadí na rozdíl od IPv6 Extension headers není zaručeno. Proto musíte procházet jejich celý blok, zkoumat je. Dalším problémem je jejich proměnná délka. Těch faktorů je více, ale tohle je asi hlavní důvod, proč nejsou zpracovány v HW.
   • Dále budou nutné změny v DNS. Kvůli kompatibilitě s legacy systémy to vidím buď na novou rodinu adres (místo IN), nebo reálněji na jiný typ záznamu. Opět Vás čeká standardizace.
   • Podpora v operačních systémech - vzpomeňte si, jak dlouho trvalo implementovat do koncových zařízení IPv6.
   • Podpora na síťových prvcích (neříkám, že u všech Vašich návrhů je nutno podporovat na úplně všech prvcích, ale bude to nezanedbatelné množství). Stačí si vzpomenout, jaké problémy dělalo kdysi, když se začal používat subnet zero a někým jiným zde již zmíněný CIDR. A to se neměnila podoba samotné adresy.
   • Podpora v programovacích jazycích - když už se musely překopat POSIXové sokety na IPv6, jsou sice struktury navrženy flexibilněji a šlo by to za cenu přidání dalších protokolů, ale bylo by stejně nutno doplnit podporu nového návrhu formou dalších tříd do všech edicí Javy, .NET, ... A hlavně přepsat stávající SW, aby s tím dokázal pracovat.

Ve výsledku bude dlouho trvat, než to dostanete do provozuschopného stavu a za pár let problémy převáží.

Ono obecně si hodně lidí neuvědomuje, že:

1. Co za IPv6 považují je spíše špička ledovce.
2. Spousta věcí je standardizována, ale není dostatečně podporována zařízeními nebo koncovými systémy (viz IPv6 mobilita, AH, ESP, ...). Předpokládám, že se povídání o některých z nich dočkáme v dalších částech tohoto seriálu.
3. Jádro standardu IPv6 (adresace, směrování, dělení adres) je vlastně jednoduché a do něj se už příliš zasahovat nebude. U zbytku (včetně přiřazování adres, apod.) je otázkou, jestli nebudou ještě některé věci předělány a doplněny do zařízení "za běhu" (jako např. ten nešťastný NAT pro SOHO).

Tak IRDP tady bylo dřív než IPv6 a nebo jsem nepochopil vaši otázku.

Mně se spíš zdá, že Váš (profesní) vývoj se zastavil před 16 lety.

BTW: "banda sebestředných magorů" ... od Vás to sedí

Na IPv4 maj vsici vsechno zakazany prave kvuli tomu podelanymu NATu.

To rozhodně není pravda. Jednak je možné, že na IPv6 se bude blacklistovat celý /48 segment.

A dále co mám zkušenost, tak restriktivní firewall pro příchozí spojení se používá např.: a) kvůli bezpečnosti (viry na windows), b) kvůli omezení p2p sharing sítí. Omezení odchozích portů na 80 a 443, někdy 21 apod. je také velmi efektivní nástroj k zamezení přetížení linky p2p aplikacemi. Ano, není to dokonalé, lze nasadit nějaký l7filter, ale zatím to funguje víc než dost.

Podle mě tedy IPv6 administrátorlm důvod k volnějšímu nastavení firewallů nepřinese.

Můj úplně první příspěvek byl o tom, že IPv6 má jeden zásadní problém a to zasahuje úplně do všeho. Nejde tedy jen o změnu adresace, ale mění se právě veci, které s adresací až tak nesouvisí. Třeba autokonfigurace, nepodporad DHCP (trvání na RA), nebo úplné zavržení NATu (symetrický NAT, čili pouhý překlad adres nebo prefixu smysl jistě má).

Smiřuji se s tím, že IPv6 přijde, i když asi nejspíš ne v této podobě, ale základ určitě zůstane.

U IPv6 mi vadí hlavně v současné době nedořešené poskytování adres. Kdo mi zaručí, že mi ISP nedá jednu IPv6 adresu a další si zákazníku zaplať. Ještě donedávna takto fungovaly tunely a funguje takhle i Teredo, aniž by k tomu byl nějaký důvod (posledních 48 bitů jsou víceméně volitelné, že se na ně mapuje lokální adresa a port nemá technický význam).

Pokud by IPv6 bylo jen o rozšíření adresového prostoru při zachování všech současných technologií, super, nemám problém. Pokud by akademici uměli navrhnout rozšíření tak, aby umožňovalo teoreticky nekonečně dlouhou síťovou adresu, bylo by to ještě lepší, protože by tím vzali snahy ISP rejžovat na zákazanících. Každý zákazník by si mohl dodat další bajt do své adresy a pak by teprve nebyly potřeba NATy.
Bohužel to tak není, takže nakonec nám IPv6 adresy opět dojdou. Kdo zabrání velkým ISP zabrat si pro sebe půlku IPv6 rozsahu s tím, že je budou poskytovat koncovým zákazníkům po jednom?

Navíc by taková adresa mohla být kratší, protože by neobsahovala potřebné rezervy pro případ, že by nějakým ISP došly adresy. zase by si jednoduše přidaly další bajt do prefixu. Takhle se nám velikost hlavičky pro IP adresy z původních 8 bajtů zvětšuje na 32 bajtů a pořád si myslím, že je škoda plýtvat pásmo na servisní informace. Pořád ještě máme rámce délky 1500bajtů a hlavičky se nám začínají dost nafukovat

Vážení, je třeba připustit, že ten problém nedostatku IP tu je. Jistě, že není všecko ideální, ale kdo může čekat, že bude něco ideální, když je to tu 16 let a jak už to padlo, těch 16 let se to sice vyvíjí, ale moc nepoužívá. Jinak měl sem možnost si s IPv6 hrát někde od roku 2005 tuším (?) a není to zase takový satan, jak se to tady líčí. Pokud si však někdo myslí, že tomu uteče, když tu bude klejt, tak se plete, protože to je prostě rozjetej vlak. Investovaného úsilí není málo a nikdo z výrobců hw nebude investovat do rádobyřešení. Hlavně proto, že do ipv6 už všichni hlavní výrobci routerů narvali docela dost peněz a nebudou se jich chtít tak lehko vzdát :) Rádobyřešení jménem nat už tu je dlouho, ale při stávajícím tempu zvyšování rychlostí přípojek je to cesta do pekel. Jakou má asi propustnost natující router a nenatující router, hm? :)

A za tohle by vás ekologové měli hnát! :D pač je prokazatelné, že na nat je třeba víc výpočetního výkonu, musí se víc topit a tím pádem se pouští více skleníkových plynů. Jestli chce někdo oponovat, že nákupem nového routeru budete zatěžovat životní prostředí víc, tak je potřeba říct, že ten router budete časem kupovat stejně nový, protože MTBF.

Samozřejmě, autokonfigurace má svoje mouchy. Zejména pokud se objeví win vista/win 7 se zapnutým sdílením. To se pak začnou dít věci. Hlavně je (nebo alespoň byl) to teda problém woken, protože si neuměj říct o fragmentaci paketů. Ale dá se to řešit.

IPv6 -> více připojených počítačů, více serverů, co je obsluhují -> více spotřebované elektřiny.
Čili jestli to chce nějaký soudruh vidět politicky-ekologicky, tak IPv6 je zlo. Je potřeba nechat IPv4 a výhledově se vrátit k IPX.

Tak oprava, uz si to ani neumim po sobe precits - /48 dostane 2 bajty pro podsite, /56 1 bajt pro podsite. Puvodne jsem to pocital pro /40, ale typicka alokace je /48, to jsem sice opravil, ale uz neprepsal.

Moznost prepnout autonomous byla uz ve trojce, jen to bylo oznaceny jako "autoconfig". Ve ctyrce (nebo mozna uz v nejaky pozdejsi trojce, nevim jiste) pak pribyla moznost nastavit i priznaky M a O.

Jak nikdy? Jediny, co mi v tom brani, je chybejici sitova karta u soucasny mikrovlnky. :)

Jinak souhlas, ze zrovna nad stavem autokonfigurace by po vsech tech letech clovek zaplakal. No ale porad lepsi vymyslet jen lepsi zpusob konfigurace, nez celej novej protokol.

Nepředbíhejte tolik.

<blockquote>[DHCP server mimo linku] může být i v IPv4 a přesto bránu přiděluje.</bloc­kquote>

Tak přiděluje, nebo nepřiděluje DHCP výchozí bránu, když je server mimo linku a na lince žádná relay není?

No zabránit jim v tom potenciálně nemůže nikdo, kromě zdravého rozumu. Spíše dají na celý segment /64 a Vy budete sdílet adresní prostor se sousedem a okolím a možná to uměle omezí kvůli účtování na 1 zákazník = 1 adresa. Tento přístup nevyřeší ale žádný protokol.

Když si uvědomíte, že poskytovatel od LIRa dostane prefix /48, tak vlastně dostává obdobu /8 v IPv4. Který český poskytovatel má tolik zákazníků, že by mu to nestačilo? Zatím to vypadá, že nikdo delší prefix ani nepotřeboval. I s /56 máte pořád regulerních ~ 64 tisíc stanic.

K vašemu nápadu s "nekonečnou délkou adresy" - praxe ukazuje, že cokoliv s dynamickou délkou v protokolu je špatné (více práce na CPU, horší realizace v HW), právě proto je nakonec IPv6 16 bajtů (overkill), i když půlku nám rovnou sebere autokonfigurace.

Trochu odlehčení, kdy dojdou IPv6 adresy (i když principielně špatné pro ten konkrétní případ):
http://xkcd.com/865/

v tom případě bych se vrátil ještě o krok zpět:
...
Chybný předpoklad. V IPv6 můžete mít DHCP server mimo linku. Proto DHCP nemůže přidělovat výchozí bránu.
...

moje reakce: DHCPv4 to za stejných okolností umí, takže není důvod, proč by to DHCPv6 nemělo umět.

jaké X.25? Ekologicky jedině RFC 1149!

Dobře, vypadá to, že nejsme ve většině věcí ve sporu, spíše se na stejné problémy díváme z jiných úhlů. Takže alespoň jednotlivé komentáře.

• Za jakési pokusy o "zpětnou kompatibilitu" se dá považovat mapování IPv4 adres do IPv6 rozsahu. Bitová kompatibilita na úrovni navržené IPv6 hlavičky není, a asi ani nebyla možná, teď už s ní každopádně nic nenaděláme.
• Pokud z důvodu kompatibility vezmeme v úvahu, že by se použily nealokované bloky z class E přímo (předpokládám, že je to to, co jste myslel) a vyřešíme směrování, viz výše tady v diskuzi, pak máme při zachování současné konzumace 2 bloky /8 za měsíc (vycházím z dnešní zprávičky, i když teď je to dáno i tím, že si každý chce nasyslit) cca 8 měsíců k dobru. Pokud by zájem v Asii opadl, což je nepravděpodobné, tak dejme tomu rok a půl. To asi příliš nepomůže. K využití IP options jsem se vyjádřil.
• S náklady a přechodem je to začarovaný kruh, dokud se IPv6 nerozšíří, tak se nepřejde, dokud se nepřejde, tak se nerozšíří...
  Zatím to ani nevypadá, že by se někdo z mobilních pracovníků ocitl v IPv6-only síti.
  Návštěva ale bude podle všeho stejně na samostatném segmentu s patřičným omezením ve FW, nebo je necháváte přistupovat do firemní infrastruktury?
  Ono kdyby vše fungovalo jak má a implementovala se správná RFC, tak by ti mobilní pracovníci mohli být přes MIPv6 přímo ve firemní síti a zvenku by nemuselo být nic přístupné. V podstatě se asi jedná o nomadické uživatele, že?
• Fakticky tady bude dual-stack trvat tak dlouho, dokud ho bude zapotřebí. Přirovnal bych to ke koexistenci IP a IPX na stejné síti. Na několik desítek let to nevidím, předpokládám, že mimo specifických sítí se odporoučí rychleji, ale nic nebrání tomu, aby se někde dál používal ještě za 40 let, předpokádám, že IPX také ještě někde běží.
  Narozdíl od DVB-T tady asi nikdo nevyhlásí, že 1.6.2016 bude proveden IPv4 switchoff a všechno se bude přenášet v IPv6. I když si dovedu takovou akci od některých (nad)vlád představit.
• K té mikrovlnce, předpokládám, že když už to bude zařízení, které bude IPv6 podporovat (jen doufám, že nebude připojena přes b/g/n WiFi, to by asi výrobce vyhořel), tak bude mimo IPv6 obsahovat i FW se zákazem příchozích spojení a konfigurovat půjde v továrním nastavení jen z lokálního segmentu s tím, že prvotní autentizace bude přes kód, zobrazený na displayi. Pak už půjde nastavit, odkud bude přístupná a pro co, něco jako Bluetooth párování nebo WPS u dnešních WiFi routerů...
• Hamachi je zrovna příkladem služby, která kašle na alokace, ale to dělá i T-mobile CZ a všichni, kdo využívali nealokované 1.0.0.0/8. Hamachi navíc využívá i alokované, ale na Internetu nepřístupné 5.0.0.0/8, ale co když se tyto sítě na Internetu objeví, a jeho klienti budou muset využít serveru v některé z těchto sítí.

Že cesta bude trnitá a implementátoři v různých OS ji ještě více komplikují, to je bohužel pravda. Vývoj okolo IPv6 také v některých oblastech před několika lety utichl/zpomalil se, prostě je to špatně načasováno. Očekávalo se, že už bude několik let IPv6 nasazeno, ale nikdo se do něj nepouštěl, protože se masivně rozšířil NAT a tak zájem upadl. Ony ze začátku byly i nějaké vlastnosti, které se vymyslely pro IPv6, ale velice rychle byly "backportovány" i do IPv4, často prakticky v okamžiku vydání RFC pro IPv6, viz IPSec.

A ještě na závěr - já osobně vidím v tuto chvíli největší problém v připojení malé domácí sítě s několika počítači přes "tu krabičku za 1500, co tu leží na stole", pokud nebude poskytovatel automaticky delegovat subnet přes DHCPv6: ta "krabička" možná sice půjde přepnout do režimu bridge pouze pro IPv6, ale pak tam zase nebude fungovat firewall.

zapomínáte na jednu věc :) ty počítače tu budou, ať tu bude ipv4 nebo ipv6... to je takový drobný detail ;) jinak stojím si za tím, že naty jsou neekologické :-P

Jinak tohle znáte? :) http://www.youtube.com/watch?v=phSpBCdWq1U

Prave ze by mel tu /48 bez kecu pridelit, stim se totiz tak nejak default pocita.

Nebude, protoze tech prefixu je vic nez IPv4 jednotlive.

a) v siti kam se pripojuji anonymni stroje, je mi jejich bezpecnost uprdele, at se staraji jejich uzivatele.
b) to je mi taktez ... jednoduse vyclenim nejake pasmo, nastavim rozdeleni 1:1 na IP a vyrizeno, nejaky L7 mi muze ... (resit provoz na L7 muze i na v4 opravdu jenom magor)

Specielne kvuli buzeraci od uradu je treba nelogovat vubec nic. Celkem by me zajimalo, jak na firewallu zakazete privacy extension ... ;D, bavime se stale o anonymne pristupnych sitich, ze ? Tedy hotely, restaurace ....

jj, nehlede na to, ze jeste hodne dlouho po te co se bezne pouzival IP protokol se zaroven na stejne siti pouzivalo i IPX (doom po siti po nicem jinym nejel ...).

/48 je alokace pro zakaznika, nikoli pro ISP.

a) v siti kam se pripojuji anonymni stroje, je mi jejich bezpecnost uprdele, at se staraji jejich uzivatele.

Vám možná ano, obecně to neplatí. Však výchozí blokování příchozích spojení na SOHO zařízeních doporučuje i jeden RFC. Ono vám pak budou chodit abuse reporty na ten "anonymní" segment. Je lepší se tomu vyhnout.

b) to je mi taktez ... jednoduse vyclenim nejake pasmo, nastavim rozdeleni 1:1 na IP a vyrizeno, nejaky L7 mi muze ... (resit provoz na L7 muze i na v4 opravdu jenom magor)

Jednak shaping fair-per-ip pro dynamický počet klientů není a nebude úplně standardní funkce v základních zařízeních - tak standardní jako prostý filtr na bázi portů. A i tak, L7 shaping není blbost. Záleží na situaci. Ale jsou sítě kde i při fair-per-ip shapingu pár uživatelů s torrentem vyvolá "nespravedlivou" situaci -- rozumějte že kdyby se všichni omezili na běžné používání a nestahovali na p2p, tak by ostatní měli mnohem rychlejší linku, hlavně subjektivně při načítání webů apod. Takže pak se hodí mít možnost veškeré P2P na L7 odfiltrovat do nejnižší priority. Dnes už to není tak akutní, páteřní konektivita je celkem levná a dostupná, ale pár let zpět tohle řešil každý druhý WiFi ISP.

A to opomíjím fakt, že zrovna v oblasti QoS je problém, že v Linuxu (a i v MK RouterOS) nejde do jedné fronty dávat společně pakety v4 i v6. Tj. nelze jednoduše např. konkrétnímu klientovi vyčlenit 2 Mb/s dohromady pro v4 a v6.

> Nove site proste budou IPv6 only, protoze ISP jednoduse nedostane zadne IPv4 adresy ktere by mohl pouzit. Tudiz ty stare budou muset nejakym zpusobem tak jako tak implementovat bud IPv6 nebo nejake konverzni rozhrani.

Nebude tam konverzní rozhraní, ale dualstack a IPv4 NAT. Protože tak je to nejjednodušší. A ISP bude doufat, že velká část provozu se přeleje na IPv6, aby ta NAT krabice nebyla moc drahá (nemá-li ji vyřešenou už dnes jinak a levněji). A na ISP, co bude v6-only si minimálně v ČR budeme muset počkat víc než 10 let.

> Az si za 5, mozna 10 let budete chtit zridit hosting, tak dostane jen IPv6 a nazdar.

Pouze za předpokladu rozšíření IPv6 konektivity k > 95 % lidí ze zájmové skupiny (dejme tomu BFU). A tady bych si nebyl jist ani těmi 10 lety. A vsadil bych se, že i za 10 let v datacentrech IPv4 budou k mání. Jen cena vzroste, třeba k 500 Kč / měsíc a jednu IPv4. Bude-li se v6 rozšiřovat, stávající projekty ztratí motivaci tolik platit za v4 adresy a budou je "vracet". Tady téměř jistě bude fungovat trh (v rámci jednoho DC, ale i mezi DC - nikdo nebude chtít být první, pro kterého je IPv4 no-way, ani za hodně peněz).

Ekologicky? Víte kolik metanu se uvolní při vylučování takové armády (asi) holubů?

Mate pravdu, nejdrive jsem to pocital s /40, pak jsem si jeste chtel overit presna cisla a spatne si precetl na RIPE odstavec 5.3. LIR-to-ISP allocation, kde se o /48 mluvi, ale jako o end site...

Mimochodem, jaka je aktualne v CR situace pri pridelovani IPv6 prefixu malym ISP od LIRu? Jaka delka prefixu se prideluje?

LIR a velky ISP predpokladam dostanou cely /32, ale co ostatni, mate nejakou presnejsi informaci?

Řekl bych, že jsem to pochopil, a na rozdíl od vás to vidím v souvislostech. Ale klidně vám to shrnu do jednoduchých otázek – pokud je problém v chápání opravdu na mé straně, nebude pro vás problém na ně odpovědět.

• Dokážete u vašeho protokolu zajistit pevné umístění všech informací potřebných pro směrování (všech částí adresy) na pevném místě v paketu (např. 4 bajty od offsetu 16)?
• Pokud ne, jak dokážete rozhodnout o směrování paketu stejně rychle a na stejně výkonném zařízení v případě dynamického umístění adresy v porovnání s fixním umístěním adresy?
• Jak zajistíte přidělení potřebných IPv4 adres tak, aby nedošlo k výraznému nárůstu routovacích tabulek?
• Jakým protokolem a s jakými adresami se bude komunikovat uvnitř sítě ISP? Budou počítače uvnitř sítě mezi sebou komunikovat přímo, nebo přes NAT ISP

Nikoli, je to naprosto to same, mozna v ponekud vetsim meritku, ale jde o totez. Navic IPX se dalo vpohode pres IP tunelovat a taky se to bezne delalo.

Jiste, me taky doma funguje cokoli co si usmyslim, umim si to nastavit, narozdil od tech milionu BFU, kteri neustale po netu resi jak to udelat a proc jim to ci ono nefunguje. Ostatne na nejmenovanem ceske trackeru poklesla frekvence techno dotazu po zprovozneni IPv6 na cca 1/5.

malý ISP dostane /32.

Asi je otázka, čemu říkáte malý ISP. /48 dostává koncový zákazník. ISP je standardně LIR, který dostane /32. (http://www.ripe.net/ripe/docs/ripe-512#lir)

Prdí holubi?

Je v civilisovaném světě ojedinělé, že firma připojující např. 5000 domácností nemá vlastní AS a tedy není "pravý" ISP? Např. takové o.s. Pilsfree má přes 14k připojených členů, a vlastní AS pokud vím nemají (snad se nepletu, mají společný v NFX). Pak je to tedy překupník? Já to chápu, ale jak takovou firmu nazývat? Vždyť takoví v ČR mají možná 30 % podíl na připojení domácností.

já bych to asi spíš rozdělil podle toho, jestli mají vlastní IP prostor a nebo používají IP prostor svého upstream providera. Existence vlastního IP prostoru není závislá na vlastním čísle AS.

Ti co mají vlastní IP prostor jsou ISP, ti co nemají jsou přeprodávači/pře­kupníci. Osobně bych to nevnímal nějak pejorativně. Nicméně jsou závislí na svém upstramovi a nejsou tedy plnohodnotní ISP.

Obvinovat CT a CTU samozrejme muzes, ale lepsi je se na to podivat z druhe strany -- diky jejich neschopnosti zde vzniklo nove, prosperujici odvetvi a mame moderni a v mezinarodnim srovnani pomerne konkurenceschopnou infrastrukturu. Pokud se podivas treba do Rakouska, kde ma inkumbent s ADSL velmi silne postaveni, do konkurencni infrastruktury se prakticky neinvestuje a srovnas to s CR, tak CR je na tom velmi dobre. A muzeme za to podekovat omezenosti a nenazranosti par smejdu, z nichz jeden se, vzpominam-li si spravne, chtel nekdy v roce 1994 dokonce veset, coz je na tom to nejzabavnejsi :-)

Třeba u dobytku se prý nejvíce metanu uvolňuje říháním, takže se ptejme spíše:

Říhají holubi?

Asi si zažádám o dotaci z ESF na provedení zevrubné studie. :-)

NO jistě by se našel někde ve standardní hlavičce IPV4 protokolu jeden významový bit, který by mohl rozlišit novou adresu od staré.

navrhuju významový bit v položce Version Number :-)

To HTTPS bloklé jsem psal já. A osobně s ním teď poslední 2 týdny bojuji v Rusku, na letištích SSL/TLS verze bloklé (šlo obejít změnou portu), posedávám po několik hodně velkých firmách a opět vše TLS/SSL bloklé, ale inteligentně, Hlídají to na L7, takže pokud si domluvím přehození TLS na jiný, neTLS port, tak to nepustí (ani DNS tunel nefunguje).
Po dotazu na adminy co to znamená, tak šifrované verze mají povolen jen jejich počítače (důvěryhodné). Návštěvním má smůlu. Respketive pro ten účel mají povolen IPsec, tak prý jeďte přes to. Ale ouha, ten jejich NAT do toho hrabe a způdsobí, že IPsec transport nefunguje, server nepozná korektně NAT protistranu (IPsec tunel to utojí, takže jejich IPsecové řešení s tím funguje, ale normální L2TP/IPsec klient z Windows ne a je jedno, zda server proti tomu zkusím nechat dát Windows/Linux/ROS). Takže takto mi třeba NATy aktuálně překáží...
A tu situaci, že mém aktuálně klienty v Číně, kde mají jen IPv6 konektivitu, musím řešit také (tam mi samozřejmě aktuálně stačí, abych přes IPv6 udělal tunel do firmy a tím protuneloval IPv4, takže nemiusím překlápět firmu na IPv6 celou, al emusím s tím nějak počítat).

ad 1) a 2) Takže místo porovnání 4 bajtů by router musel porovnat 4 a 4 bajty adresy (zdrojové a cílové) a podle ní rozhodnout, zda nejde o nový protokol. Pak porovnat 4 bajty cílové adresy, načíst délku hlavičky, podle ní určit umístění další části adresy (bajt 20 nebo 24) a tu pak porovnat s routovací tabulkou. To nebude stejně rychlé.

Navíc byste musel vyměnit veškerou infrastrukturu, která se nyní dívá i dovnitř paketu. Třeba tolik oblíbený NAT by vám najednou začal přepisovat část cílové adresy – stačí jediné zařízení v cestě, které by nerozumělo novému IPv4, a budou se dít věci.

ad 3) V návrhu je použít prázdné bloky, každý LIR by tedy nejspíš dostal svou část. Pokud by dnes každý LIR měl jeden blok, znamenalo by to tedy nárůst routovacích tabulek na dvojnásobek. Ve skutečnosti mají těch bloků více, ale i tak by to byl dost výrazný narůst. Současné přidělené adresy nejde pro nový protokol využít, protože nějak musíte identifikovat, že jde o ten nový protokol – chápal jsem to tak, že by to bylo právě podle příslušnosti adresy k onomu dříve prázdnému bloku.

ad 4) Takže opět by byla nutná podpora nového protokolu v celé infrastruktuře ISP. Pokud bude v síti jediný router, který protokol nebude znát, nepodívá se na rozšířenou adresu a podle cílové adresy pošle paket zpět na „bránu“ – takže by se paket zacyklil.

Když to shrnu – rozhodování o směrování by bylo náročnější na výkon, routovací tabulky by se výrazně zvětšily, to jsou oproti IPv6 nevýhody. Shodně s IPv6 by bylo nutné pro podporu nového protokolu vyměnit veškerou infrastrukturu. Oproti IPv6, jehož provoz není souběhem IPv4 rušen, by ten váš protokol byl navíc velmi náchylný k tomu, že ho stará zařízení budou poškozovat. Ve výsledku má tedy váš návrh všechny nevýhody IPv6, podstatné nevýhody navíc a žádnou výhodu. Už chápete, proč se vybralo menší zlo a vytvořil se nový protokol?

Vždyť jsem to psal. Takže zpětná kompatibilita žádná. Jakmile se paket ocitne v síti s novými zařízeními, nesmí se dostat na staré zařízení. Pořád tady ale hrozí to riziko, že se omylem provoz nového protokolu bude routovat přes staré zařízení, čímž ten provoz půjde do háje. To se u IPv6 stát nemůže.

aha a kolipa bajtíků musí porovnávat router při routerování IPV6 ?

Pokud chcete zvětšit adresní prostor, nezbývá než zvětšit adresu. Rozdíl je ale v tom, jak rychle ji dokážu porovnávat.

NO jistě by se našel někde ve standardní hlavičce IPV4 protokolu jeden významový bit

Tak ho najděte…

Takže žádné tragické zpomalení se nekoná...že ?

Koná. Místo jednoho porovnání jich musíte udělat několik, navíc ještě ve dvou variantách umístění v paketu. A všechno to má být implementováno hardwarově.

No a při přechodu na IPV6 to není nutné ?

Je. Já jsem netvrdil, že je váš návrh v tomto ohledu horší než IPv6, v tomto případě je jenom stejně špatný.

z tohoto je jasně vidět že tento princip nechcete pochopit...

Nikoli, z toho je vidět, že vy jste se nezkusil ani zamyslet nad tím, jak by to v praxi fungovalo. Protože:

i "nové" pakety projdou starou sítí

Neprojdou. NAT je přesměruje někam úplně jinam, staré zařízení je zacyklí. „Nové“ pakety projdou některými částmi staré sítě, když budete mít štěstí. Takže nejen, že to nebude fungovat správně, ale navíc prakticky nebude možné zjistit, kde je chyba – protože to nebude fungovat, i když všechna zařízení budou fungovat správně.

budou prostě směrovány stadnradními starými metodami až do té chvíle kdy vstoupí do nového zařízení...ale to dé doby právě mohou být směrovány "postaru" a to je ta kompatibilita s původním systémem

Dobře. Takže paket vstoupil do nového zařízení X, tam se podle rozšířené adresy zjistí, kam má být směrován dál. Pošle se tou linkou, na druhém konci ovšem bude staré zařízení Y. To podle cílové IP adresy zjistí, že má být paket směrován na zařízení X. Můžete si vybrat – buď zjistí, že odtud ten paket právě přišel, že je tedy někde chyba, a zahodí ho. Nebo ho pošle šupem zpátky. Tak jako tak, k cíli ten paket nikdy nedorazí.

Fungovalo by to jedině v případě, kdy by paket – jakmile jednou vstoupí do nového zařízení – nikdy nesměl opustit novou infrastrukturu, mohl by být předáván jenom mezi novými zařízeními. Tím ale máte opět kompatibilitu v tahu. Navíc je to jen záležitost konfigurace, ve které snadno může nastat chyba – s novým protokolem (IPv6) se vám ale nemůže stát, že se paket kvůli chybné konfiguraci dostane do IPv4 infrastruktury a tam se bude pohybovat dál.

(samozřejmě ne NATem i když možná by to přepisování cílové adresy nemuselo tolik vadit ale to nechme být)

No pokud vám nevadí, že se paket doručí někomu úplně jinému, tak nemá smysl se s vámi bavit o síťových protokolech. Tak si prostě představte, že se vám cílová adresa omylem přepisuje na 127.0.0.1, což vám přece nevadí, vytáhněte si síťový kabel z počítače, a budete spokojen.

NAT nemá smysl řešit

Ve vaší teorii možná. V praxi se ovšem NAT vyskytuje. Vaše řešení by tedy bylo možné použít jenom tam, kde je zaručeno, že cestou žádný NAT (ani nic podobného) není – nevím, jak byste to zařídil.

Na letišti asi ne. V těch firmách, pokud by byly na IPv6 a já měl IPv6 komunikující klienty a spojení až domů do firmy, tak se dostanu IPsecem ven bez problému k nám do firmy. Aktuálně nedostanou, protože jejich NAT bedna to przní.
Měli snahu to nastavit, aby to fungovalo, ale nedařilo se. Což znám celkem dobře i ČR, kde existují provideři, od kterých zkrátka IPsec přes NAT nefunguje a sami udávjaí, že jejich NAT bedna to przní a neví co s tím, připlattě si za veřejnou IP.

Jen pro upřesnění. Pilsfree není vhodný příklad překupníka konektivity. Sice nemá vlastní AS používá IP adresy z rozsahu NFX, ale zároveň je jedním ze zakladatelů NFX a generuje zhruba polovinu provozu a platí zhruba polovinu nákladů celého NFX. Takže je zákazníkem sdružení ve kterém má zároveň silné slovo. Rozhodně se nejedná o pozici jako má běžný malý ISP vs velký prodejce konektivity.

Víte, váš problém je, že jste jen praktik. Váš rozhled končí někde u malejch firemních sítí s pár počítači. Vaše řešení, která používáte vycházejí z toho, co je na trhu. Což vůbec neznamená, že to děláte špatně, a asi i lépe než teoretici.

V případě IPv6, a návrhu protokolů obecně, nestačí být ale jen praktik. Kdybyste byl trochu teoretik, tak byste ale věděl, že vaše IPv4 extension je jen lehce modifikovaný source routing, a sám byste si odpověděl, proč to nemůže obecně fungovat, ačkoliv pro vaše řešené problémy by to bylo dostačující, což se vám vytrvale snaží pan Jirsák.

Data IPv4 paketu mění většina NATů, váš určitě také – porty protokolu TCP jsou uloženy v datech IPv4 paketu, takže pokud NAT mění port, musí změnit data paketu.

To samozrejme nestaci, protoze 802.1x vam v siti eliminuje uplne nepatricne osoby, ale nevyresi jak v pripade potreby mezi vsemi temi opravnenymi a pripojenymi klienty identifikovat toho jednoho, ktery pachal nejake nepravosti.
802.1x nezabrani opravnenemu klientovi aby umyslne nebo neumyslne narusil konfiguraci cele site tim, ze se bude anouncovat jako router a/nebo DHCPv6 server a dokonce ani nepomuze takoveho klienta identifikovat (protoze 802.1x je svazane s MAC adresou karty, ale v prostredi IPv6 zname jen DUID) ...
Proste - 802.1x neni samospasitelne reseni - jen vhodna soucast opatreni, ktera ve vysledku sit zabezpeci.
A jelikoz na IPv6 ty ostatni nutne potrebne navazujici veci chybi je cele IPv6 na kocku.

Ale to jsme zasli HODNE daleko. Zatim se umi korektne autokonfigurovat pouze Windows. Operacni systemy UNIXoveho typu zvladaji autokonfiguraci vyhradne v sitich s maskou /64 (pokud toho DHCPv6 klienta, ktery na interface nakonfiguruje prave tuto masku bez ohledu na to jakou masku se ze site dozvi nekdo neopravil).

Nema smysl resit slozite veci okolo zabezpeceni u protokolu, ktery je natolik v plenkach, ze jeste nema spolehlive vyresene ani ty nejzakladnejsi operace.

DHCP umí konfigurovat i další routy, nešlo by do toho někam propašovat výchozí bránu?

Nic se nerozhodlo, zatím to vypadá, že existuje moře cest, ale trhu se nechce ani do jedné. Jediné, co tedy zatím umíme je IPv6 směrovat. Dostat ji až ke koncovým zákazníkům a do vnitřních sítí je problém. Zatímc se IPv6 tedy dá používat jen přes tunely a teredo, nedokážu si představit, že bych na IPv6 postavil celou vnitřní síť.

evidentně nemáte pravdu. Já žádný tunel nepoužívám. A naše tiskárna chce jako na sviňu používat IPv6 a skoro jsme ji nedonutili k IPv4.

Starou (stavajici) infrastrukturou by vam E class packet bohuzel neprosel. Prekazkou bude hned prvni linuxovy router (tam snad existuje od nejake nove verse kernelu nejaky patch), ale i hned prvni Cisco, Juniper nebo Brocade... Smula.

options mají nevýhodu v tom, že se špatně zpracovávají v hardware. V konečném důsledku by to neúnosně prodražilo směrovače, které by měly přehazovat větší provoz.

to může být i v IPv4 a přesto bránu přiděluje.

Ale skutečná potřeba zpracovat Options bude stejně až na branách ISP, tedy tam, kde teď má ISP stavový NAT. A nejsem si jist, že by stavový NAT byl jednodušší, než pouhé rozparsování nějakého pole v IP hlavičce.

Ale možná to dopadne tak, jak někdo psal dole. Bude tam IPv6/IPv4 brána, čili uživatel si udělá síť jakou chce na IPv4 a bude aktiv aspoň po IPv6. Dokonce i adresa stroje po IPv6 může být sestavena jako IPv6/96 + IPv4/32 v síti klienta.

To právě není pravda. Zpracovávat options se budou muset ve všech lokálních směrovačích místních sítí. Jinak nebudete vědět, kam to posílat.

Napište teda svůj návrh přesně a já vám ho zkritizuju taky přesně :-) Už teď z toho krátkého popisu bych viděl několik velmi těžko řešitelných problémů, třeba jak odlišit vnitřní a vnější síť, ale klidně se rozepište, ať máme jasno.

Co nechápete na návrhu místo portu u NATu použít pole Options? Jediný problém je, že zatímco port je pro druhou stranu transparentní, Options by musela druhá strana podporovat, takže vyžaduje celointernetovou dohodu.

Rozlišení vnitřní a vnější sítě? Co na tom nechápete. Třeba já jsem rozhodně uvnitř nějaké vnitřní sítě. V případě NATované sítě to snad je naprosto zřejmé.

Tak si to rozložme: máme ISP E1 a E2, což jsou poskytovatelé "rozšířeného" Internetu, Máme zákazníky Z1E1 , Z2E1 (oba zákazníci ISP E1), Z3E2 (zákazník E2) a Z4 ve starém internetu.
chci komunikovat:
- uvnitř mojí větší sítě rozdělené na podsítě
- Z1E1 přistupuje na web Z2E1
- Z1E1 přistupuje na web Z3E2
- Z1E1 přistupuje na web Z4

a současně to chceme udělat tak, aby nejvíce zatížené routery nemusely pracně zpracovávat options, protože se to hardwarově nedá dost dobře vyřešit. Tj. jsou to hlavně směrovač směrující pakety ve vnitřní síti k mému diskovému poli a páteřní směrovač providera.

zkuste čmuchat trochu inteligentněji, myslím, že zas tak moc se neschovávám.

V pripadech 1) a 2) uvadi klient adresu ve forme adresa brany ciloveho ISP:adresa serveru v siti

Pri komunikaci pres options jsem uvazoval, ze bude existovat ICMP zprava, ktera klientovi posle informaci o lepsi ceste nez puvodne zadal.

1) ICMP presmeruje klienta na adresu do vnitrni site bez options
2) ICMP presmeruje klienta na branu, ktera existuje mezi E1 a E2 namisto aby to slo venkovnim interneten
3) Tady nic, na brane se pouze prepise odesilatel.

(PS: vnitrni sit, porad uvazuju rozsahy 10/8, pripadne dnes rezervovany segment E)

Dekuji za dalsi dil.

Jistě, něco to nevyřeší (kde má někdo totálně restriktivní firewall, tak ho bude mít ais i na IPv6). ale problémy, kde mi do toho kecá NAT, by IPv6 v současném stavu pomohlo, ať už situace, že mám dva cesťaky někde spolu a oni současně se zkusí připojit na firemní PPTP a když pro to nemá NAT spešl podporu, tak si to vzájemně budou shazovat, stejně tak zas,e pokud půjdou přes IPsec, tak pokud NAT do toho bude aktivně hrabat, tak se spíše nespojí, další kapitolou je SIP ALG v NATech atd, takže tuto třídu problému IPv6 odstraní, pokud koncák dostane globální adresu.
Jistě je zajimavá otázka, jak se protokoly vyrovnají s variantou, která bude určitě také oblíbená, že bude v síti ULA a aplikaovaný překlad prefixů, takový IPsec by z toho v aktuálním stavu nemusel být nadšen (a nejsem si jist, že NAT-T rozšíření počítá s něčím takovým).
A myslím, že by částečně i IPv6 mohlo pomoci, aby někteří paranoici neměli tka restriktivní firewall, když budou mít dost adres, aby méně důvěryhodnou komunikaci návštěvníků vystrčili na samostatný prefix, místo součansého NATování na jendu adresu s celou firmou.
Nejsem nadšený propagátor IPv6, ale realista, který má dneska pod seobu road-warriors, kteří v cílovém místě pobytu překvapivě hlásí, že je k mání jen IPv6 konektivita a ať se něco udělá a dostaonu se do firmy k mailům, souborům, ... (zase to vypadá, že z Číny snad IPv6 konektivitu ani nefultrují, asi soudruzi usoudili, že IPv6 obsahu je tak málo, že se s ním zatím nemusí párat). Takže nezbývá než se se současným stavem vyrovnat a popasovat i když k některým věcem mám také výhrady.
Co se týká toho přidělení globální adresy, tak s ním jsem celkem srovnán. Ano, u RA byl dlouho problém to DNS, specifikaci to dneska má, podporu v reálném HW/SW zatím mizivou, to se asi napraví časem. Mám i aplikaci, kde se aktivně využívá toho (zaítm experimentálně), že dva routery do sítě dávají své prefixy (s relativně krátkým lifetimeme) a když jednomu chcípne konektivita, tak se přestane propagovat a jde to druhým segmentem. V IPv4 na to používám VRRP, ten je i rychlejší při výpadku než přepínání dle RA, ale VRRP jde nasadit iv IPv6 a v kombinaci s ULA/překlad prefixů bude zajimavý. Takže proto třeba i chápu, proč nepočítali s default routou v DHCPv6. Zase takové DUID místo klasické MAC už nadšení nesdílím po zjištění, že některé "IPv6 ready" krabičky s podporou DHCPv6 se chovají tak, že po každém zapnutí si vygenerují DUID nový, jak je právě napadne. Ale tady předpokládám, že implentátoři DHCPv6 serverů budou mít pochopení a půjde to nastavovat dle MAC. :-) A takto by šlo pokračovat.
Berme to, že IPv6 je stále nováček. IPv4 je tady 2x tak dlouho a kus a také trvlao dost dlouho, než si řada věcí sedla.
Jsem už mezeální kousek, takže pamatuji to prskání s přechodem na clasless routování a kolik problémů nadělalo toto v síti. I když z dálky jde o celkem nevinnou věc a neměl by být problém, aby si routery jdoucí podle tříd vedle těch maskových nějakou dobu vyžili.... Také to nebyla pravda (jak jsem si i sám experimentálně před skoro dvaceti lety ověřil při složení půlky Evropy). A případné současné upradování IPv4 by dneska na tom bylo asi dost podobně. :-( Takže nezbývý, než se vycvičit pro IPv6 a být připraven na tvrdý dopad reality. :-)

.... Dále mi nikdo nedokázal prakticky předvést, jak si připojím do té malé IPV6 sítě bez zlého NAPTu tu vytouženou mikrovlnku a ona bude okamžitě end-to-end dostupná odkudkoliv ze světa....

Jednoduše: zastrčím mikrovlnku do ethernetové zásuvky, ta z RA získá prefix a dopočítá si svůj EUI-64, čímž mu vznikne jeho globální adresa. Pokud bude chtít být dostupný z venku nějakým rozumným způsobem tak použije dynamický DNS update, aby se jmenovala třeba mikrovlnka.u.mne­.doma.cz. A pak dám do prohlížeče http://mikrovlnka.u.mne.doma.cz/

Co je na tom proboha, po takové sérii článků na téma autokonfigurace, nepochopitelného?

p2p JE standardni vyuziti linky, jde dokonce o nejzadanejsi sluzbu vubec, takze o tom nema vubec smysl diskutovat. Naopak, 99,9% zarizeni neumi cokoli na L7, je to vypocetne narocne a stejne to neni nijak zvlast pouzitelne, navic to muze narazit na pravni potize.

A to ze neco neumite neznamena ze to nejde, zrovna QoS specielne v Linuxu umi uplne vpohode definovat spolecnou rychlost pro IPv4 a 6 dohromady. Pouzivam to nekolik let.

Ne nebudou. Pokud by neexistoval IP (nebo podobný protokol) a existovalo mnoho roztříštěných sítí, tak v domácnostech a firmách nebude tolik počítačů, protože ty počítače nebudou nabízet všechno to co nám nabízí počítač připojený do dnešního internetu.
Pokud by se teoreticky zastavilo připojování počítačů k internetu (protože nevznikne žádný nástupce IPv4), tak počet počítačů prostě přestane růst dnešním tempem.
A naopak - pokud nastoupí IPv6, tak se začnou k internetu připojovat i zařízení, která k němu dneska připojená nejsou.

NAT je neekologický? Kvůli natu si někteří domácí uživatelé nejsou schopni správně nastavit P2P klienta, aby jim správně fungoval. A díky tomu počítač třeba přes den, nebo přes noc vypnou. Kdyby NAT neměli a P2P jim korektně fungoval, tak nechají běžet počítač se stahování třeba 24/7. Takže co se na routerech bez NATu ušetří, to se v množství o několik řádů větším spotřebuje v domácnostech. Pěkně děkuji za takovou ekologii :-)

to říká někdo, kdo IPv6 ani nezkusil. Nechováte se trochu jako vyděšený panic před prvním sexem? :-)

A pořád, že neznáte můj návrh a přitom ho znáte líp než já sám.

Při přechodu může dojít k překladu adresy jako u NATu, akorát nestavově, prostě se vezme info z options a přepíše se tím cílová adresa a paket se pošle do vnitřní sítě. Obráceným způsobem se zdrojová adresa uloží do options a za zdrojovou adresu se dosadí adresa brány. To se dělá dneska taky, ale místo toho se používá port. A protože porty jsou přidělovány dynamicky, musí být NAT stavový.

Jasněže, můj návrh je jen další vylepšení NATu. Na druhou stranu, je plně kompatibilní a řeší to, kvůli čemu se IPv6 vlastně nyní zavádí. Totiž kvůli adresaci počítačů ve vnitřní síti. IPv6 stále považuji za velice nedodělanou záležitost a tak předpovídám, že se alternativně objeví nějaké řešení v téhleté podobě, ne tedy nutně stejné, ale podobně. Možná že ekonomické řešení využije stávající investice do páteřní infrastruktury IPv6, ale koncovým zákazníkům bude stále dodávat IPv4 s nějakým IPv6-IPv4 překladem adres, tak, aby zákazník nemusel nic řešit.

Sory, ale vy nejste praktik, vy ste placal.

Domacnosti = p2p = potreba byt "aktiv" = potreba mit verejnou IP => reseni je IPv6. Kdyby nic jineho tak toto staci.

Domacnosti + male firmy = VoIP = potreba mit verejne IP (jinak se telefon s telefonem nespoji a opet se to resi pres ruzne zhuverilosti) => opet to resi IPv6.

Dale plkate z cesty, protoze existuji obousmerne konverze v4 to v6 i naopak, staci to zprovoznit trebas na GW, tudiz ciste IPv6 sit muze komunikovat s IPv4 siti a naopak, je ovsem daleko jednodusi na siti s IPv4 pridat IPv6. Nove site proste budou IPv6 only, protoze ISP jednoduse nedostane zadne IPv4 adresy ktere by mohl pouzit. Tudiz ty stare budou muset nejakym zpusobem tak jako tak implementovat bud IPv6 nebo nejake konverzni rozhrani.
Az si za 5, mozna 10 let budete chtit zridit hosting, tak dostane jen IPv6 a nazdar.

Tak schvalne, kde dostanu dnes IPv4 pro svuj AS ? Aha, nikde.

DHCP server vobec nemusi bezat v rovnakej sieti, takze urcite sa nerovna ip dhcp=gw...zvacsa sa pri vela roznych sietach pouziva jeden dhcp a vsetko sa na neho iba relay-uje...samozrejme sa mu preto musi pre kazdy subnet nastavit aku ma pridelovat.ja len tolko

Tedy u klienta, kde chceme mít jistotu, že se nestaneme obětí útoku s podvrženým rekurzivním DNS serverem prostřednictvím IPv6 (v síti, kde se s IPv6 zatím nepočítá), je nejlepší IPv6 zakázat. Takový já žel dělám závěr.

Nejasnosti (respektive příliš mnoho možností z nichž téměř všechny nejsou dotažené) v IPv6 jsou podle mne jednou z jeho velkých brzd. Obávám se, že tohle mělo být již dávno jasné a to zejména kvůli setrvačnosti výrobců HW a producentů OS.

Díky za články, tohle jsem opravdu nevěděl. Zdá se, že IPv6 má víc problémů, než přínosů. Proč zase někdo už po několikátý vynalézá kolo?

(a přitom by stačilo do DHCPv6 přidat výchozí bránu a celý problém s autokonfigurací je vyřešen)

To vypadá jako vtip: Víte jaký je rozdíl mezi (ne)použitelností DS a IPv6? Žádný, jen to první navrhovali právníci a druhou akademici.

Kdo to rozhodne? Nějaký genius? Nebo o tom necháme hlasovat? Evropská unie? Nebo Obama?

A routovat se to bude jak? To jako bude „pár“ páteřních routerů, na které se bude směrovat veškerý provoz, a ty pak budou každý paket obracet naruby a zase zpátky, aby našly adresu v Options? A přístup na internet bude na pořadník, aby to ty routery stíhaly, ne?

Jenom jestli to neřešíte jako v IT Crowds. Telefon nezvedají a volajícímu automat pouze přehraje "Zkuste to vypnout a znova zapnout.".

Dehonestovat nápad se dá i líp, než takhle trapně.

Paradoxní na to je to že dnes je k tomu v IPV4 zlém světě potřeba pouze jedno nastavení na domácím NAPTu.

Jak báječně ten tvůj NAT funguje tady už popisoval kolega níže. Ale chápu, on a celá jejich firma jsou neschopní pitomci, měli si pozvat tebe a jelo by to za pět minut z celého světa. :-D

Co vám na té části IPv6, která nahrazuje IPv4, připadá nefunkční?

1. Myslet znamena kulove vedet.

2. Kdybych to pred par tydny nezkousel, nepsal bych to.

3. IPv6 si tam samozrejme skrtne, IPv6 packety stavajici infrastruktura prenaset umi.

Jste si jist tim, ze stavajici smerovace snesou nasazeni IP options ve velkem meritku? Druha vec je, ze dnes se packety s IP options casto zahazuji, protoze nektere platformy je neforwardovaly v hardware, ale v CPU, coz oteviralo moznost zahlceni tech boxu. Cili vyuziti IP options bych take nevidel jako jednoduchou a jednoznacne funkcni cestu.

(zcela pomijim fakt, ze mi Vase argumentace pripomina znamy vtip, jak Americane volaji do Kremlu "Delame tu nejakou statistiku, prosim Vas, kolik si vydela mesicne delnik v Sovetskem svazu?" ... Ozve se dlouhe ticho a pak se z druhe strany telefonu ozve "A vy zase bijete cernochy!")

Ja nerozumim tomu, kde ma byt problem. Kdybych *ted* pichnul doma do switche IPv6-Ready mikrovlnku, tak dostane verejnou IPv6 adresu, na kterou se muzu bez jakykoliv dodatecny konfigurace pripojit odkud chci a jedinou vadou na krase zustava, ze je to zatim jen 6to4. Az ISP zavede nativni IPv6 (uz na tom pracuje), bude to fungovat uplne stejne. Jen mi mozna neda cely /48 jako mam ted, ale kdo potrebuje na doma 65 tisic podsiti. :)

Ja bych tedy navrhoval, ze kdyz to stejne vyzaduje celointernetovou dohodu, ze by mozna bylo lepsi doladit tech par drobnosti a dohodnout se rovnou na IPv6, nez vymyslet od zacatku neco uplne jinyho. :)

Neblázni, takové logické řešení? :-)

Oproti tomu nikde neimplementované návrhy vás dvou, vyžadující celointernetový konsensus, ty jsou v podstatě production-ready. :-)))))))))))

Vy byste tedy chtěl vedle sebe provozovat dva protokoly, jeden IPv6 a pak upravený IPv4, a odesílatel by si nejprve zjistil, který má použít? To je zajímavý nápad. Jenom – v čem se liší id současného IPv6 a jeho tunelování skrze IPv4?

asi nějaký tunelový server.

Ale jo. Na necem budou chtit vydelavat penize i zitra.

to je jako házet hrách na zeď. Už jsme mu to tady psali tisíckrát a nic. Pod dalším článkem o IPv6 to tu bude znovu a pořád dokola.

To můžeme s IPv6 tunelem taky. Ovšem ten váš protokol bychom mohli zavést až v okamžiku, kdy v obou sítích nebudeme mít žádný router, který nerozumí tomu novému protokolu. To je IPv6 víc zpětně kompatibilní, než to vaše řešení – IPv6 můžete začít nasazovat teď hned paralelně vedle IPv4, s vaším protokolem byste musel čekat, až se vyměníte všechny routery v síti.

A neni to nahodou presne to, co dela 6to4 (pokud pomineme propojeni s nativnim IPv6)? Tedy mam dve ruzny site na dvou ruznych mistech, ke kazdy mam jen jednu verejnou IPv4 adresu a aniz by kdokoliv dalsi musel neco udelat, tak za kazdou muzu schovat dokonce 2^80 zarizeni s neomezenou end-to-end komunikaci.
Jedinej problem je, pokud nemam verejnou IPv4 adresu, pak to nepujde. Ale na tom si uplne stejne vylame zuby i to navrhovany lepsi reseni, nebo snad ne?

Máte pravdu, není. 6to4 komunikaci vám nezlikviduje kdejaké standardní IPv4 zařízení po cestě.

Dobre, tak ne uplne presne to stejny, 6to4 bali jeden protokol do druhyho, zatimco tohle by jen prilepilo rozsirenou adresu do hlavicky. Ale z pohledu prenosu po stary siti, ktera stejne pochopi jen starou adresu a zbytku paketu nerozumi, v tom zadnej zasadni rozdil nevidim.

IPsec je schválený a povolený, když nefunguje, mohou řešit. Otevření TLS kanálu není schválené, nelajzne si z nich nikdo otevřít. Jen taková blbost, když potřebujete mezi dvěma LAN segmenty povolit FTP přenos, tak je to tu akce od října, završená minulý týden, než se to odsouhlasilo a nastavilo. A když mezitím se ukázalo, že třeba mezi těmi LAN segmenty za určitýck podmínek fungoval ping a neměl, tak si to admini šeredně odskákali. Takhle fungují velké firmy.
A co se TLS týče, tak jsem už musel řešit na mnoha místech řadu lahůdek. Včetně toho, že TLS povoleno, ale jen na servery, které předkládaly certifikát podepsaný některými cerifikačními autoritami, co si místní dali na whitelist, jinak se to blokovalo (takže žádný selfsigned certifikát na svém HTTPS/SSTP serveru, ale třeba oid Verisignu už OK). Další oblíbený případ je, že HTTPS ano, ale opravdu pro web, pokud spojení trvá déle a má chrakter tunelu, tak opět ustřižen...
Tohle jsou samozřejmě úlitby L7-firewallové, pokud se do toho přidají úlitby NATové, s kteýrmi obecně VPN protokoly mívají problém, tak opravdu nemám univerzální jendoduché řešení, co bych strčil cesťákovi do ruky a měl jistotu, že bude fungovat odkudkoliv. Pokud by mi IPv6 odboural aspoň ty NATové, co tvoří minimálně polovinu komplikací, tak to jen uvítám.

V tom, že je to na místě dat, je právě problém. Protože data IPv4 paketu se mohou při průchodu sítí měnit – dělá to třeba NAT.

Nevadí to, pokud se vám podaří tu novou infrastrukturu dostatečně oddělit od staré. S IPv6 je to zařízeno přirozeně, vy byste tu zpětnou nekompatibilitu musel zajišťovat nějak uměle a složitě. Výsledek by tedy byl stejný – dva nekompatibilní protokoly, ovšem ten váš je náročnější na zpracování i konfiguraci. Což ovšem není žádná novinka.

Co se vám na argumentaci IPv6 tunelem nezdá? Je to přesně to, co požadujete – propojení dvou bodů používajících nový protokol skrze infrastrukturu IPv4. Rozdíl je jen ve způsobu implementace – IPv6 tunel je daleko robustnější řešení, než to vaše.

6to4 tunel je IPv6 paket zabalený do IPv4 paketu a routovaný klasickým IPv4 routováním. Žádné obrovské ztráty na rychlosti se tedy nekonají. Nevím, co si mám představit pod plynulým přechodem, ale síť dostupná přes 6to4 je normálně dostupná z IPv6. U vašeho protokolu také neexistuje plynulý přechod do normálního provozu, protože by se provoz tuneloval skrze IPv4 už navždy.

My se bavíme o IPv4 paketu. Součástí dat IPv4 paketu je například zdrojový a cílový port TCP paketu. Takže běžný NAT, který mění zdrojový port TCP paketu, mění data IPv4 paketu. Shodou okolností je zdrojový port v IPv4 paketu uložen zrovna v tom místě, kam vy byste chtěl ukládat rozšířenou cílovou adresu.

Vy jste ale psal o „obrovských ztrátách na rychlosti“. Jak zvětšení paketu o hlavičku jiného protokolu způsobí obrovskou ztrátu rychlosti? Ostatně na to zabalení paketu do jiného paketu se taky můžete dívat jako na prodloužení hlavičky.

Na váš námět principu, jak by bylo možné rozšířit adresní prostor IPv4, vám bylo už několikrát vysvětleno, že vaše řešení by bylo několikanásobně složitější a dražší, než IPv6, a nic by to nepřineslo (stejně každý, kdo by chtěl komunikovat novým způsobem, by musel aktualizovat software nebo i hardware).

To, že zde bude existovat souběh obou protokolů, je od začátku zřejmé a od začátku se s tím počítá. Teoretik by řekl, že nejlepší by bylo udělat změnu jedním velkým třeskem – praktici vědí, že je to nemožné a o nic takového se nesnaží.

Čověče, tobě bych teda fakt svěřil síť. Chudáci zákazníci, co u nich "adminuješ".

Ale skutečná potřeba zpracovat Options bude stejně až na branách ISP

Co je to „brána ISP“?