Vlákno názorů k článku 6rd – nový koncept nasazení IPv6 od ZP - Pochopte uz konecne, ze cim dele se bude...

Pochopte uz konecne, ze cim dele se bude blbnout s tunely a jinymi podfuky, jak tahat IPv6 over IPv4, tim bude mensi tlak na skutecne nativni nasazeni IPv6. No a k tomu, aby ten tlak byl skutecne takovy, aby vznikl zajem o nasazeni v6 ze strany uzivatelu, musi skutecne v4 adresy dojit (resp. jejich trzni cena musi byt dostatecne vysoka, aby vznikl zajem o substitut).

Rekl bych, ze tahle mince ma dve strany. Tou druhou stranou je absence infrastruktury/hardware, ktera je schopna IPv6 end-to-end prenaset. Obnova sitoveho hardware s sebou prinasi nemale naklady a s cenami paternich routeru te jiste seznamovat nemusim :) Klasicka slepice-vejce otazka je o tom, kdo to zaplati. Zakaznici tlaci na ceny konektivity pomalu se priblizujici nule (coz imho take znas) a pak asi take moc penez na obnovu HW nezbyva - kdyz vetsina prijmu se utopi v provoznich nakladech a subjekt je velmi casto rad, ze aspon nekonci v cervenych cislech...
Rust "ceny" IP adresy nemusi vest k masivnejsimu nasazeni IPv6, ale treba k jeste masivnejsimu nasazeni prekladu adres.

Jiste, ty substituty mohou vypadat ruzne. Ale zase tak zle to neni, nejaky trend rustu uzivatelu IPv6 pozoruji v CZ.

Mno, ke me tak sdilne UPC nebylo, defakto mi napsalo, ze supportovat IPv6 nebude protoze to rozhodlo vedeni. Coz jsem zustal civet. Sestku bych ocenil, je potreba jako sul. Uz aby to bylo ...
f.

Otazkou jest, cemu rikate "zakladni parametry". Kdyz se podivame na male L3 switche od firmy "C", tak se zapnutim IPv6 se pomerne drasticky zhorsi celkove systemove parametry daneho boxu. A to se bavim o L3 switchich, ktere jsou stare 3 roky...
Pak tu mame hromady dalsich veci kolem - DSL, kabelovky, SoHo routery... a tam je podpora IPv6 v zarizenich (a zejmena dostupnych CPE) dost tragicka. Bohuzel...

Tak lusknutím prstu jo ? A co jako budete dělat se zbytkovými IPv4 subnety ? Všude nasazovat konverze nebo je odřezat a dělat, že tam nejsou ?

Já bych třeba zájem měl, ale nedaří se mi najít nějaký prakticky použitelný tutorial na to, jak přemigrovat hardware i software - tzn. které routery podporují IPv6, které firewally podporují IPv6, co udělat s FTP, VNC, IRC..., jaký použít DNS klient, jak v IPv6 dosáhnout stavu známého z IPv4+NAT (odchozí komunikace funguje všechna, příchozí komunikace z místní sítě taky všechna, z internetu jen odpovědi na odeslané packety nebo spojení, která jsem explicitně nadefinoval někde v konfiguraci) atd. Kdykoliv jsem hledal řešení, nalezl jsem buď to, že to jde (ale ne JAK to udělat, leda odkazem typu "viz specifikace", který je sice přesný, ale úplně k ničemu, pokud se nechci převáděním IPv4 sítí na IPv6 živit), nebo že to nejde (což technicky vzato chápu, rozchodit FTP na IPv6 je zřejmě zhruba stejně problematické jako ho rozchodit na IPX, ale pokud FTP potřebuju, je mi to taky k ničemu). V nejlepším případě (byly snad dva, možná jen jeden) jsem se dozvěděl aplikaci, která se použít dá, ale svými parametry mi nevyhovuje. A to se prosím považuji za uživatele, který do protokolu TCP/IP poměrně dost vidí a nemám problémy nastudovat si technický text. Jak za těchto okolností přesvědčit uživatele, kteří v životě neslyšeli termín "IP adresa", aby hromadně přešli na IPv6, netuším.

Myslím, že Pepák myslel SOHO uživatele, tedy uživatele nějakého "Tesko počítače" s MS Windows. Ten si opravdu nebude kupoval nový router \ AP , nebo modem v ceně jeho dvou počítačů :-) , měnit SW který prostě s IP6 nepočítal atd...

Tedy problém není u firem, a velkých ISP. Problém je v tom, že se v nejspodnějších patrech projeví to že to není zadarmo , lidé se budou bránit. Jim je jedno co je zatím, že mu funguje ten seznam.cz, hlavně že nemusí vyhazovat dalších 1000 kč za nějakou krabičku.

ad bod 3 - je vhodne uznat, ze starsi linuxovske aplikace vyuzivaji stack, ktery je v4 only a pro ten v6 kompatibilni se musi pouzit trochu jine API. Realne treba serverove programy rozezname nasledovne:

# netstat -pan

v4 only:
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      427/mysqld      
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN      506/xinetd      

dual stack:
tcp6       0      0 :::587                  :::*                    LISTEN      1486/sendmail: MTA:
tcp6       0      0 ::1:53                  :::*                    LISTEN      350/named       
tcp6       0      0 :::22                   :::*                    LISTEN      496/sshd        
tcp6       0      0 :::25                   :::*                    LISTEN      1486/sendmail: MTA:
udp6       0      0 :::58769                :::*                                350/named

Na OS/X a tusim ze i na Windows (od XP nahoru) podporuji aplikace v6, aniz by o tom explicitne musely vedet...

V první řadě děkuji za odpověď. A teď k jednotlivým bodům: 1. Firewallem myslím aplikační firewall pro Windows. Stejně jako ostatní aplikace se ptám pro Windows - považoval jsem za samozřejmé, že když není uvedeno jinak, předpokládá se nejrozšířenější systém. 5. Nemám na mysli jenom stavový firewall, ale celou NAT funkčnost (mimo jiné skrývání komunikujícího počítače). NAT traversal bych do toho netahal, že jsou NATující routery pitomě napsané a přijímají privátní IP adresy z WAN portu je úplně jiná záležitost.

Hmm, měl jsem použít náhled. No nic.

Mimo jiné bych si uvědomil, že NAT traversalem myslíte něco jiného než já. Nicméně bych podotkl, že moje otázka vůbec nebyla směřována na to, jestli je "ochrana" pomocí NAT dostatečná nebo ne - byla směřována na to, jak dosáhnout stejného efektu.

Pokud chci mít možnost připojení k IPv6, potřebuju nějakou formu tunelu. Způsob 6rd není zas tak špatný v tom, že poskytovatel může umožnit svým lidem využít jeho páteřního připojení (kde v peeringových centrech a páteřních sítích už často ipv6 reálně funguje). Pěkné na tom je, že pouze ti, kteří IPv6 chtějí, jej mohou použít. Poskytovatel tedy nemusí naráz přemigrovat celou svoji síť. Přitom zákazníci nejsou odkázaní na nějaké zahraniční tunel servery, které by jim poskytnou nižší rychlost i spolehlivost, protože chodí přes mnohem více sítí a přes zahraniční (dražší) linky. Kouzelná vlastnost tohoto způsobu je i v tom, že provozovatel má na páteři IPv6 router, ale sítí mu to chodí přes IPv4 adresy, na které už má monitoring, omezování rychlosti, další věci. Nemusí to řešit podruhé pro IPv6, protože to řeší už v rámci IPv4. Stačí kontrolovat, zda jeho centrální brána má správné v6 routy. Ono je moc pěkné řešit tohle na úrovni, kdy rychlost omezujete pouze pomocí rychlosti portu, jako v serverovně. Máte za to, že lokální wifi provideři mají svoje shapery IPv6 ready? Já myslím, že nemají.

Jistě, jako plnohodnotná náhrada to je nahouby. Z možností, které znám, je to ovšem nejlepší možnost, pokud z nějakého důvodu nemůžu mít nativní IPv6 síť. Alespoň z mého pohledu je anycastová adresa 6to4 nejblíž někde v Německu, tedy přes pomalejší linku. I když ono by asi celkem stačilo, kdyby poskytovatelé měli alespoň pro svoje zákazníky relay. No, minimálně u nás na to serou. Takže asi budou srát i na 6rd...

Mimochodem, je nějaký zavedený standard na šíření IPv6 do domácností? Tedy jak bez ručního nastavování získám IPv6 adresu nejen pro ADSL modem/wifi router/kabelový modem/whatever, ale i pro subnet doma? IPv4 s NATem má tu výhodu, že poskytovatel nemusí (nemůže?) dělat vůbec nic, kromě přidělení jedné adresy routeru. Pokud by poskytovatel chtěl, jak vlastně zákazníkovi doručí jeho IPv6 prefix? Jde to pomocí DHCPv6? Pokoušel se vůbec o něco podobného některý poskytovatel u nás? Funguje to prakticky někde jinde? Já teda neviděl žádný router do domácnosti, který by něco takového umožňoval, ale nepohybuju se v tom denně.

Ano, to je na tunelech to "krasne". A strasne zaroven, protoze nikoho nic netlaci k tomu, aby tu sestku implementovali nativne. Uvedomte si, ze u vetsiny (nejen) ceskych ISP, kteri IPv6 podporuji, je ta IPv6 podpora iniciativa par jednotlivcu (mozna CESNET je vyjimka, to nevim) a ze kdyz se to delalo, tak to vubec nikdo realne nechtel -- a nechtel by dal, kdyby tu neexistoval treba tlak CZ.NIC na registratory domen. Neexistence tunelu by Vam sice zabranila IPv6 pouzivat, tedy ten start by byl o neco pomalejsi, ale zato pozdeji by se implementace sestky rozjela naopak rychleji. Dnes Vam naopak jeden nejmenovany Tier1 s trimistnym ASN rekne, ze mate pouzit tunel.

Jinak nevim jak wifi ISP, kazdopadne profesionalni reseni je shaping ci policing na interface/subinterface, aplikujici se na veskery provoz, i kdyby tam teklo treba X.25. Lokalni wifi provideri maji casto reseni, ktera nejsou poradne ani IPv4 ready ;-)

Standard zde neni ani na IPv4 do domacnosti. ADSL modemy se konfiguruji jinak, kabelove modemy take jinak, wifi routery take jinak, navic se to lisi vyrobce od vyrobce a radu od rady. Proc by tomu melo byt u IPv6 jinak? pochopitelne, pomoc DHCPv6 jde udelat temer vse, pokud to CPE podporuje... No a provisioning pochopitelne vyrobci zarizeni postupne resi, Fritz uz jej kuprikladu ma a existuji prvni, bohuzel opet tunelove, implementace (XS4ALL a free.fr).

Myslím, že podobné argumenty by platily i o PPPoE a podobných vymyšlenostech, kdy se něco zabaluje do vyšších vrstev. Provozovatel pravděpodobně nebude dlouhodobě přenášet po vnitřní síti data s režií vyšší, než musí, kdy zákazník platí za rychlost datovou a režii navíc platit nechce. Pokud by víc zákazníků IPv6 opravdu začalo využívat, poskytovateli se nevyplatí to tahat přes celou síť přes IPv4. Jenže aby mohli začít využívat, musí nejprve dostat alespoň trochu použitelnou IPv6 kontektivitu, která zatím obvykle chybí. I když chápu, že po ní mnoho zákazníků nekřičí. Bohužel bude asi fakt, že za IPv6 si málokdo bude chtít připlatit. Koncovým uživatelům bude jedno, jak si to poskytovatel přenáší, pokud jim to jede stejně rychle a +- se stejnou odezvou.

Co já vím, tak místní poskytovatelé častěji omezují provoz centrálně na několika místech v síti, než na každém rádiu samostatně, i když to je pravděpodobně lepší řešení. Cenově to vyjde mnohem levněji, krabice jsou sice neuvěřitelně hloupé, ale zákazníkovi je to naprosto šumák. Jistě, to nebude řešení pro firmu přes 50 zaměstnanců nebo s vysokými nároky na kvalitu kontektivity, profesionální řešení s opovídající pořizovací cenou bude spíš na závadu. Tohle myslím platí nejenom u Wifi poskytovatelů.

U těch modemů jsem nemyslel ani tak přímo provisioning. Spíš nutnost aktivní spolupráce poskytovatele na jeho straně, aby mě to reálně routovalo i počítače na mé vnitřní síti. Pravda, ona by stačila klidně kolonka na LAN interface: šířit prefix XY/64, který mi poslal poskytovatel. Ovšem to by ty jednoduché routery musely IPv6 brát v potaz, momentálně je úspěch, když to tam jde nacpat aspoň nějak přes konzolu/telnet. U natu si na vnitřní síti nastavím co chci, aniž bych se poskytovatele musel ptát, nebo on mě to musel nastavit. Častěji to nechám tak, jak jsem to koupil. Těžko říct, jak moc souvisí nepřipravenost koncových zařízení a neochota poskytovatelů IPv6 nabízet.

Tak to je prave resitelne tim provisioningem a nejakym dynamickym routovacim protokolem (samozrejme osetrenym tak, aby se z nej nic nesirilo dal) pro komunikaci CPE s BRAS, treba EIGRP nebo OSPF.

Broadcastování prefixů mě funguje naprosto spolehlivě. Jenom jej neřeší ospf6d, ale démon zebra. Funguje mi už na debianu etch, alespoň pro základní nastavení bez problémů.

Zebra vam broadcastuje prefixy? Wow. Muzete osvetlit, co myslite tim "broadcastovanim prefixu" a jaky ze protokol k tomu ten "demon zebra" pouziva, kdyz sam zadny nepodporuje a je navrzena tak, aby vyuzivala prave demony jako ospf6d, ripd nebo bgpd?