Vlákno názorů k článku
6rd – nový koncept nasazení IPv6

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.

No to neni tak uplne pravda. Napriklad UPC - tam se pokud vim porad ceka na novej software od motoroly to tech uzasnejch kabelovejch modemu.

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

Nicmene v nasich koncinach jsou tyto jedny z nejrozsirenejsich... z toho je potreba vychazet, pokud se poustime do polemiky, jak uz je roky ten hardware a software pripraven. On si treba taky kazdy rozmyslel, zda do IPv6 pujde, pokud mel kvuli tomu zaplatit extra licenci navic (ale toto uz se nastesti meni)...

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.

Tak to vezmem postupne...

1. Routery podporujici IPv6 - prakticky vsechny nevjejsi modely Cisco, Juniper, H3C... Z mensich funguje celkem dobre IPv6 na Mikrotiku (ikdyz tam nekdy byvaji zahadne problemy s ND). Tipuju ze Vas bude asi zajimat podpora zejmena v mensich routerech a firemnich firewallech, tak celkem zajimave a cenove velice prijatelne je napr neco z teto rady: http://www.juniper.net/us/en/products-services/security/srx-series/ Co se tyka software firewallu, tak Linux, Solaris, BSD a dalsi mji porpodu IPv6 a firewallingu uz dlouho.

2. FTP - vzhledem k tomu ze tam se IP adresa dostava az do komunikacniho protokolu, je potreba aby byla podpora jak na strane serveru tak na strane klienta. V dnesni dobe uz bezproblemove.... (prakticky odzkouseno Proftpd a nekolik stovek uzivatelu s IPv6).

3. VNC - minimalne na MacOS X funguje... Proste "Just works". A pokud vim, tak VNC je uplne jedno po jakem protokolu jde, jedine co musi jit je otevrit TCP socket a to je u obou protokolu stejne.

4. DNS klient? Ehm, tady Vam nerozumim... Podpora IPv6 v DNS resolverech je dnes na vsech modernich operacnich systemech na urovni prakticky 100%.

5. IPv4+NAT? Mate na mysli stavovy firewall? Tady zalezi na cem konkretne ten firewall mate. Ale rovnou Vas upozornim ze NAT NENI FIREWALL!!!!! To je velice rozsireny omyl a natem jde prochazet. Pokud na to nekde spolehate, tak doporucuju prostudovat jak funguje NAT traversal... Jinak nejjednodnuzsi ukazka stavovyho firewallu na routeru, ktery dela to co myslite pro Linux:

ip6tables -A FORWARD -i eth1 -m state --state NEW -j ACCEPT
ip6tables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -P FORWARD DROP

Co se tyka dokumentace k IPv6 tak podle meho nazoru i pro prumerne zdatneho sitare je vice nez dostatecna, takze v tom opravdu nevidim zadny problem pokud dotycny zvlada cist a umi alespon trochu anglicky.

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.

SW ktery by neumel IPv6 pouziva naproste minimum osob (vsechny prohlizece webu IPv6 umi, vetsina ftp klientu, uTorrent, Azureus, .... co vic BFU pouziva ?). Dobře. Já používám software, který neumí IPv6. Jak to mám řešit, když se toho SW nemůžu nebo nechci vzdát, třeba proto, že "alternativy" nemají požadovanou funkčnost?

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

Tak v tom Vasem netstatu - MySQL opravdu IPv6 defaultne neumi. Musi ze spanout pri kompilaci, ale neni to doporucovano, protoze pak miva problem s autorizaci... Je to zpusobeny tim hnusnym hakem kdy zadate jako adresu serveru localhost tak se nepripojuje na 127.0.0.1 ale na UNIX socket. Pro programatory s dobrym zaludkem doporucuju k nahlednuti odpovidajici kus kodu v libmysqlclient.c. Takovahle prasecina se jen tak nevidi. Ale xinetd s IPv6 nema zadny problem, staci to zapnout v konfiguraci.

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.

Takze firewall co je soucasti windows s IPv6 samozrejme pracovat umi a je i pomerne dost konfigurovatelnej pomoci netsh (http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/netsh.mspx?mfr=true). A co se tyka NATu a schovani site za jednu IP, tak takova funkcnist v IPv6 puvodne byt nemela, ale pokud vim, tak se ji nakonec do standartizace podarilo dostat. Pokud Vam ale jde o anonymizaci pristupu z nejake site tak aby nebylo mozne dohledat ktery konkretni pocitac spojeni navazoval a pripadne kolik pocitacu v te siti je, tedy to cim si tyto informace nektere firmy chrani pouzitim NATu, tak to je resitelne. Viz. RFC3041

IPv6 nativne podporuje anonymni komunikaci, napr XP to maji defaultne zapnuto. Jednoduse receno se vam nahodne meni IP adresa (zustava samozrejme prefix) => v tomhle ohledu je NAT pitomost.

To se na tom musí nádherně provozovat servery.

Jedina NAT funkcnost je prave a vyhradne resit nedostatek IP.

To je naprostý nesmysl. Chtělo by se říct, "Chjo, ze by ste si zjistil neco o fungovani NAT?" "resit nedostatek IP" je tak nanejvýš "primární účel" (spíš jenom "účel"), ale rozhodně ne "jediná funkčnost"

Privacy Extension na serveru zapne jen blbec...

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.

Zbynku places na spatnem hrobe.

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.

Zrovna OSPF, které neumožňuje příliš dobře filtrovat šířené informace po vnitřní síti asi nemá šanci tam, kde je uživatel oprávněn nebo schopen místo dodaného zařízení nasadit své vlastní a měnit jeho nastavení. Asi málokdo by čekal na vhodnou příležitost, kdy mu zákazník položí síť zevnitř, když se mu podaří propagovat síť, která rozhodně nemá být směrována přes něj. Vhodnější varianta podle mě je použít DHCP, a v nějakém dohodnutém parametru předat rozsah k použití pro interní síť, který bude na tuto IP routován. Problém je, že tohle nebude fungovat v kaskádě za sebou, i když z pohledu poskytovatelů to bude asi žádoucí, z pohledu sousedů sdílejících připojení nepříjemné omezení. Zase pravda statické routování není to pravé, pokud domácí router neumí potvrdit použití té sítě, bude se na něj směrovat něco, co potom bude vracet zpět přes default routu.

Dynamické routování pro levné krabičky není zrovna něco, co by měly provádět, nebo byly schopny to dělat spolehlivě. Kromě toho domácí router by možná ani neměl znát detaily o OSPF poskytovatele, jemu stačí default routa, kam poslat všechno mimo interní síť. Zkrátka tady se mi zdá, že nejde jednoduše udělat plug&play se zařízením, které poskytovatel nenastavil před předání zákazníkovi. S NATem tohle jde, koupím si někde na webshopu krabici levněji a prostě zapojím a funguju, bez ručního nastavování parametrů providera (jak kde, někde musím měnit MAC).

Jiste, kazde reseni je kompromis. Kdyby tam bylo BGP, zase by bylo nutne generovat pro kazdy peer extra filtr a jeste jej konfigurovat, zase by to mohl delat provisioning system, ale sprava relace stoji systemove zdroje atd. atd. Takze asi nejmene skodila varianta je nejake *zakryptovane* IGP a CPE ve sprave poskytovatele. Nikdo netvrdi, ze to musi byt prave OSPF a nikdo netvrdi, ze se do te zakaznicke krabicky ma posilat neco jineho, nez ::/0.

Já netvrdím autentizační mechanismy. Já mám (možná mylně) za to, že link-state protokol vyžaduje v celé skupině konzistentní, shodnou databázi. Nevím o tom, zda OSPF umí na základě různé autentizace povolit přijetí cesty od souseda, nebo pouze mu cesty poslat a nic od něj nebrat. Tedy ne bavím se s tebou/nebavím, ale nějaké úrovně oprávnění, co vlastně posílat smí a jak se s ním mám bavit. Tohle, myslím, quagga neumí. Taky uchovávat kompletní databázi celé sítě na každém koncovém zařízení mi přijde zbytečné, levné krabičky by se mohly na velké síti sekat pro vyčerpanou paměť.

> Nevím o tom, zda OSPF umí na základě různé autentizace povolit přijetí cesty od souseda, nebo pouze mu cesty poslat a nic od něj nebrat.

Neumi. Autentizace v OSPF slouzi jen k rozliseni 's tebou se bavim/nebavim'.

Zrovna DHCPv6 umí delegaci prefixu a to i kaskádovitě. Nic není třeba nikam dodělávat, už to existuje. Co se týče bezpečnosti, tak třeba u DSL stejně máte ethernetovou linku izolovanou až do koncentrátoru. Prostě místo PPPoE by byl DHCPv6 server.

Zrovna na tom mikrokliku ta sestka neni zas tak super... Problemy s ND a s omezovanim rychlosti. Pokud vim, tak nejde nastavit ze klient ma v souctu rychlost X Mbps, ale musi se nastavit ze tolik ma pro ctyrku a tolik pro sestku. Zkratka neda se rict, ze ma bejt napt. tolik Mbps na tomhle portu. Nebo pokud to nahodou jde a ja jsem jenom trosku blbej, tak mi sem hodte kus konfigurace, kterej to resi...

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?

broadcastovani prefixu jsem pochopil jako Router Advertisement. Presne jmeno protokolu jiste znate sam, kterou variantu a ktere vsechny ficury umi netusim. V configu mam neco takoveho:

interface eth0
no ipv6 nd suppress-ra
ipv6 nd prefix 2001:dead:cade::/64

Tohle se nepouziva pro vymenu smerovacich informaci, ale jako konfigurace IP adres a statickych cest, kterou lze provadet v demonu zebra. Quagga, ktera to dela u me, je 0.99.5, predpokladam, ze novejsi to umi stale. Jestli me neduverujete, konzultujte samostatne manual.

Ale to nebroadcastujete prefix, to broadcastem oznamujete adresu smerovace. Dost bych se primlouval za pouzivani obvykle terminologie, jinak se nemame sanci domluvit.

A jak se tedy počítač dozví svůj prefix, když se používá autokonfigurace?

Z router advertismentu... coz je icmpv6 multicast. V IPv6 broadcasty neexistuji.

To je slovíčkaření.

Zebra (quagga) to skutečně zvládá samostatně.
Konfigurace:
!
interface xl0
description Spojeni do Internetu
no ipv6 nd suppress-ra
ipv6 nd ra-interval 30
ipv6 nd managed-config-flag
ipv6 nd prefix 2001:7b8:3e2::/64
!