Názory k článku Den IPv6 proběhl a ke kolapsu nedošlo

DHCP snooping

DHCP snooping pouze blokuje odpovědi od neautorizovaných DHCP serveru.

Nicméně na lepších přepínačích od Cisca, H3C, apod. Je možné zapnout funci, kdy si uživatel nejprve MUSÍ vyžádat adresu od DHCP serveru, nebo se nikam nedostane.

Zatial existuje iba RA guard - blokovanie "bogus" ipv6 smerovacov. Pracuje sa na implementacii "ip source guard" pre IPv6 podobne ako to funguje na IPv4 (pustaju sa iba dvojice ip-mac, ktore autorizoval dhcp server). Linux ma uz niekolko rokov v iptables modul eui64, ktory pusti iba IPv6 adresy v EUI64 formate (ip adresa odvodena z MAC) - nevyhoda je, ze na windows sa musi explicitne vypnut nahodne generovanie IPv6 adresy (privacy extension), aby sa pouzivala ako primarna ta EUI64, co v sietach, kde je velka migracia roznych klientov je dost problematicke.

DHCP snooping nijak nebrání klientovi nastavovat si MAC i IP adresy ;-)

Nejak nevidim, v cem je problem. Pokud mate tabulku MAC - IPv4, tak z ni muzete snadno vygenerovat lektorske IPv6 adresy (ktere se prideli pres SLAAC/RA) a ty povolit na proxy. Nebo jeste lepe oddelit lektorske PC do samostatne vlan a pridelit jim jiny prefix.

Souhlasim, ze DUID namisto MAC adresy u DHCPv6 je pitome reseni.

Jak už jsem psal, RA se dají použít k tomu, aby se zakázala bezstavová autokonfigurace a povolila se jen stavová (DHCP).

Proxy: ověřování přes AD (nebo jinak) podle uživatelského účtu. Transparentně přes IP je bezpečnostní riziko.

Autokonfigurace: Na switchích nastavit ACL na podle tabulky port/IP/MAC - když máte takový pořádek, jistě takovou tabulku již někde máte, jen s IPv4 (při troše snahy to lze automatizovat). Ale jinak stejně nechápu proč to řešíte, protože pokud máte 802.1x tak máte jistotu, že se do sítě připojuje stroj, který spravujete a tam nastavíte DHCP a vypnete stateless ;) ACL připadá v úvahu u ISP..

DUID: počítače spravujete, máte možnost DUID nastavit/zjistit - takže v tom problém nevidím (určitě také nebude větší problém to automatizovat). Naopak nespojenost s MAC vidím jako výhodu (vyměním počítač, tak akorát nastavím stejné DUID jako starý, vyřazený)

Souhlasím s Vámi, že IPv6 přináší nové a jiné vlastnosti než IPv4. Ale podle mě je potíž v tom, že lidé jsou na něco zvyklí a nechtějí to měnit. Když se nad některými věcmi zamyslíte, zjistíte, že jsou třeba lepší. Mluvit o tom, že lidé tvořící IPv6 nejsou/nebyli při smyslech, bych řekl, Vám nepřísluší ;)

Dovolim si par komentaru:

ad 1 - Autokonfigurace: tabulka port/IP/MAC je sice hezke tvrzeni ma nekolik problematickych ale. Prvne musim mit koncove prepinace s podporou IPv6 ACL. Tech je jaksi na trhu za rozumne penize pomalu. I kdybych tohle dokazal, tak ve svete IPv6 vznikaji napriklad LL adresy nahodile (Windows 7). 802.1x mi problem prilis neresei, protoze zajistuje autentizaci pouze na linkove vrstve - viz. thread http://www.root.cz/clanky/den-ipv6-probehl-a-svet-se-nezboril/nazory/387080/. Pokud vychazite z predpokladu, ze do site pripojuju pouze stoje ktere spravuju pak tyhle veci ani resit nemusim - mam nad vsim kontrolu. Nicmene zde se prave snazime resit mechanizmus pripojovani PC/zakazniku napriklad v panelakove siti, kde jaksi nad temi koncovymi zarizenimi z principu neni zadna kontrola, resp. neda se prilis zasahovat do jejich konfigurace.

ad 2 - DUID : nastavovani/meneni DUID je vec hodne problematicka. Schvalne zkuste si pohledat jak to udelat treba na Windows 7. Tohle rozhodne neni provozne pouzitelne.

ad 3 - nove vlastnosti : je to velice diskutabilni. Kdyz se na nektere veci podivate, tak na prvni pohled vypadaji nesmirne lakave (rozsirene hlavicky, likvidace broadcastu, diskutovana autokonfigurace, bezpecnost, ...), nicmene pokud jdete do hloubky, tak zjistite ze maji nektera velice problematicka ale. Jenze prave na tech detailech po certech zalezi. Samotnou skutecnost, ze jsou lide na neco zvykli a to ze se neco dela nejak v IPv4 vic nez 10 let (napr. autokonfigurace) nelze zkratka ignorovat. Naopak to svedci lecos jiste vyzralosti tohoto postupu. Bohuzel tyto zkusenosti jsou v ipv6 casto ignorovany s ideologickou vidinou neceho lepsiho. A vysledek je jednoduchy. Spravci/firmy radeji blokuji/nezavadeji IPv6 jako celek, protoze se tech novych veci proste boji (a chapu je). Vysledkem je, ze dnes mame v koncovych sitich cca 0,3% penetraci IPv6 i presto, ze tak odhadem 30 - 40% systemu v nejake podobe podporuje IPv6 (Win Vista/7, MAC OS, Linux/BSD).

V pripade autokonfigurace - co je napriklad tak strasne spatneho na DHCP(v4) ? Proc se tento koncept musel zcela zaslapat v podobe SLACu a pak prostrednictvim DHCPv6, ktere vypada jak vypda? Pricemz pridani DUIDu jako dalsi volby by rozhodne nebyl problem (klidne i do DHCPv4). Kazdy by si pak vybral, kterou polozku vyuzije pro identifikaci klientu - jinymi slovy vlk by se nazral a koza zustala cela.

Souhlas.

Prostě jde především o to, že vývoj protokolu v budoucnu doiteruje buď k úplné funkčí autokonfiguraci včetně potřebných bezpečnostních mechanizmů, nebo se začne používate dhcpv6. Záleží především na tom jaké mechanismy bude podporovat OS Windows.

Velkým problémem IPv6 jsou také rozšířené hlavičky, které dnes nejdou rozumně parsovat v hardware (kvůli plovoucí délce a možnosti jejich nekonečného opakování).

Jako by se na IPv4 běžně parsovaly v hardware rozšířené volby.

Souhlas. Autokonfigurace v IPv6 je naprosty des a osobne to vidim jako celkem velkou prekazku zavadeni IPv6.

K tomuto tematu se posledni dobou pomerne casto vynoruji diskuse (s cca mesicni periodou) tech kteri pozaduji aby DHCPv6 zaclo fungovat jak se ocekava, a tech kteri si za zadnym koncem nechteji nechat vyvratit, ze bezstavova autokonfigurace (SLAAC) je uzasna vec.

Posledni takova dikuse se odehrala behem poslednich tri dnu v listu operatoru severni ameriky - viz. http://seclists.org/nanog/2011/Jun/657, kde padaji i pomerne hodne kriticka slova smerem k IETF.

Bohuzel i pres VELKE vyhrady ke SLACu ze strany operatoru a pomerne jasnych prikladu toho, ze je to velike nestesti si stale nekteri nechteji tuto "hracku" nechat vzit.

Ale to je holt realita IPv6. Vymysleji se veci typu SLAAC, 6to4, teredo, rozsirene hlavicky, SEND ktere praxe tak jak tak zavrhne, nicmene vzdy trva cca 10 az 15 let se takovycho "vylepseni" zbavime.

To samozrejme neni pravda. Vnucuje. V okaziku kdy se do site pripojuji nejroztodivnejsi zarizeni, tak autokonfiguraci vypnout nemuzu. Jak se pak koncova zarizeni dozvi udaje o konfigurace site? Nastavim to vse rucne? Nebo pouziju DHCPv6 a rucne nastavim jen default GW? Bohuzel autokonfigurace je vec na ktere se musi shodnout fakt vsichni aby byla rozumne pouzitelna - tak jak to postupem casu doiterovalo v IPv4 k DHCP.

Dalsi problem je, ze SLAAC tak jak je navrzeny tak se prakticky neda zabezpecit a ma to pomerne fatalni presahy i na IPv4. Bohuzel tohle jsou argumenty, ktere se neustale bagatelizuji. Mnozi IPv6 protagoniste namisto aby pripustili, ze na tech problemech fakt neco bude, tak neustale opakuji, ze problemy vlastne nejsou problemem, zabezpeceni je stejne jak v IPv4 a za vse muzou jen nechopni spravci, zli vyrobci a nevim kdo jeste...

Je jasne, ze tyto problemy se casem vyresi akorat nemuzu pochopit, proc je snaha si v IPv6 nektere veci zamerne komplikovat, kdyz existuji jiz casem overena a pomerne primocara reseni.

Autokonfiguraci jde vypnout pomoci flagu v rozesilanych RA.

DHCP stejně neřeší to, že si může uživatel nastavit IP adresu sám, stejně tak i MAC adresa se dá změnit a nakonec ani DHCP protokol není zabezpečený. Pokud to někdo s bezpečností myslí vážně tak se stejně musí autorizovat uživatel a né počítač např. na linkové vrstvě pomocí 802.1X nebo nějaký proxy server a při autorizaci se může rovnout spojit MAC/IP adresa s konkrétním uživatelem a to funguje stejně s IPv4 i IPv6.

A co 802.1x a radius.

Bohuzel to je caste a mylne dogma, ktere kolem 802.1x koluje. 802.1x mi resi autentizaci pouze na linkove vrstve. Dozvim se tedy, ze za PC s MAC adresou XY-XY-XY-XY-XY-XY sedi uzivatel ABC, pripadne autentizoval se na portu D switche E.

To samozrejme samo o sobe nic nerika o tom jakou IPv4/IPv6 adresu uzivatel pouzil - obecne vzato muze pouzit jakoukoliv. V IPv4 je mnohdy donucen k tomu (konfiguraci port security na switchi), aby mu fungovala IPv4 adresa pridelena jen DHCP serverem. Tim padem je mozne na DHCP serveru spojit autentizacni informace radius serveru a DHCP databazi a mam co jsem chtel.

V IPv6 na tohle muzeme zapomenout. Pro identifikaci klienta v DHCPv6 se pouziva DUID, ktery nema vztah k MAC adrese pouzitou ke komunikaci. Takze nemohu provest ono propojeni mezi udaji na radiusu a DHCPv6 databazi, protoze nemam zadny udaj, kterym bych veci dokazal propojit.

Reseni je sbirani obsahu Neighbor Cache na smerovaci. Nicmene to ovsem vyzaduje pomerne vyrazne poupravovat systemy, ktere se pouzivaji pro IPv4. Nastroju, ktere by to dokazaly delat neni mnoho (zatim co znam tak system NAV http://metanav.uninett.no/, system netdisco ve vyvojove verzi http://www.netdisco.org/ ci ubastlit si neco vlastniho). V kazdem pripade to nnei vec na jedno dopoledne.

Takze zaver: 802.1x neni vsespasitelne. Je to technologie ktera dela co se od ni ocekava, ale z principu fungovani pochopitelne nic nerika o identite uzivatele na vyssich protokolovych vstvach.

1) Autokonfigurace jde lehce vypnout na routeru. Jediný problém je, pokud se někdo jiný vydává za router. Tento problém je přímou obdobou problému, kdy se na IPv4 někdo vydává za DHCP server. Lze řešit například filtrováním na switchi, stejně jako na IPv4.

Nový vývoj IPv6 přináší ještě experimentální na switchi nezávislé řešení v podobě SEND. Buď se to ujme nebo ne.

2) DUID je velmi dobrý nápad, pokud by to jeho implementace dotáhly do konce a ukládalo se například v nastavení BIOSu nebo v jiném trvalém úložišti, jako je to s MAC adresami.

Lidi, kteří potřebují MAC adresy k přidělování adres a zároveň jim z nějakého důvodu nevyhovuje bezstavová automatická konfigurace, se měli zajímat o IPv6 daleko dřív a včas připomínkovat. Teď už bohužel vznikly implementace bez toho.

Ale nasazení IPv6 je zatím malé, takže doporučuju tlačit na IETF, ať ještě informaci o MAC adrese do protokolu doplní, nebo tlačit na implementátory, aby DUID odvozovali z něčeho, co je pevně svázané s počítačem nebo našli způsob, jak DUID trvale ukládat.

3) Přesně tak to je, správce rozhoduje, jestli počítače budou používat autokonfiguraci (je to flag v router advertisement), DHCP na základě MAC jde teoreticky v lokální síti implementovat, ale musí se vyčíst MAC adresa z ethernetového rámce. Ale nebude to fungovat s relay servery.

RA určuje, která konfigurace se provede.

Ty fltrace, SEND - vyz. vyse. Neni to zas tak uplne snadne.

Jinak naprosty souhlas. Pokud ale sledujete deni v IETF, tak jakekoliv zmeny jsou hodne problematicke a mnohe byt dobre napady jsou mnohdy zatracovany. Ono na ne driv nebo pozdeji dojde (namatkou DHCPv6, NAT66, likvidate automatickych tunelu, Default GW v DHCPv6, Unifikace rozsirenych hlavicek, ...), ale jsou s tim spojeny zbytecne prodlevy - v lepsim pripade nekolik let.

Ale rozhodne souhlasim, ze vytvareni tlaku na zaklade praktickych zkusenosti je jedina cesta jak veci dat do nejakeho pouzitelneho stavu. To ovsem vyzaduje hodne namahy, casu a trpelivosti ze strany tech co se snazi na techto hladinach neco prosadit. To je kritika smerem k IETF, ktera zazniva i z rad vyrobcu, rady velkych operatoru atd. Viz. treba Juniper, ktery odmita opravovat problemy s RA s tim, ze si to ma opravit nejdrive IETF ve svych standardech.

Chápu a nemyslím, že bysme byli ve sporu.

Podle statistik NIX.CZ (http://zajic.v.pytli.cz/nixcz/) to nevypadá, že by až tolik AAAA záznamů skončilo v šuplíku. IPv6 provoz se rozhodně nevrátil na původní hodnoty a dokonce to vypadá, že byla neděle využita k dalším testům (proto opět výrazně naskočily IPv6 toky), takže nejspíš leckde zjistili, že není třeba se IPv6 bát.

Ještě je možné zkusit OpenWRT nebo něco podobného. K tomu stačí router za pár korun. Ale zase konfigurace není pro obyčejného usera.

Klasický záchranný argument. Jenže cokoliv s OPenWRT nefunguje staží se podívat na stránky projetu.

Smiřte ses tím, že Vám lidé tak rychle za nový router s IPv6 peníze nedají a nechají HW dožít. To v jejich řeči znamená několik let po záruku, tedy cca 4-5let.
Stejně tak nedají peníze někomu, kdo by jim nakonfiguroval OPenWRT. To je realita tomu se říká tržní prostředí.

Obyčejní lidé přejdou jen, pokud jim IPv6 přinese nějakou opravdu velkou přidanou hodnotnou, nebo je někdo na IPv6 pře migruje násilím.
To první určitě nejsou pohádky geeků o VPN, webkamerách , FTýpku. Podobné věci ty lidi nezajímají. Pokud zůstaneme v české kotlině stále jim seznam, icq, rajce a podobné půjde stejně.
To druhé je vyhánění čerta ďáblem. Jako odstrašující případ bych já viděl UPC a jejich dle statistik "úspěšnou" migraci zákazníků analogové televize nedigitální. U ISP byto mohlo dopadnou víc než pravděpodobně stejně jde tam o peníze zákazníků a větší.

Já jsem za padesáti NATy lokálního CZFree. IPv6 adresa by byla paráda, ale obávám se, že to ještě hodně let nebude. Holt síť budovaná chaoticky z HW, který byl zrovna k mání. Z toho důvodu se domnívám, že CZFree bude nakonec poslední, kdo toto umožní (čest výjimkám).

Od CZ.NIC bych taky zmínil teredo.nic.cz, což je prakticky jediná možnost, jak já se dostanu k IPv6 bez nepoužitelných prodlev ve spojení. Díky za něj.

Osobně si ale myslím, že by to chtělo i opačnou službu. Pro někoho, kdo bude mít IPv6 only připojení, dostat se transparentně na IPv4 obsah. Takový NAT :)
Protože jakmile by toto například CZ.NIC nebo poskytovatel zprovoznil, mohl by nabízet nativní IPv6 konektivitu, IPv4 zcela zahodit a jen někde na hranicích překládat. Tedy miredo/teredo naruby.

A jak je to se SIP? Jde to normálně provozovat přes IPv6? Umí to nějaké běžné telefony?

SIP by měl přes IPv6 běhat zcela normálně. Základní definice protokolu verzi IP vůbec neřeší, a SDP (protokol, který se při sestavení hovoru využívá pro určení společných médií a transportu) IPv6 explicitně podporuje.

Jak jsou na tom konkrétní implementace ... toť jiná otázka. Když jsme si ve firmě psali vlastní SIP stack v C++ pro Symbian OS, tak jsme s tím počítali. Knihovna pjsip to teoreticky umí taky. Prakticky ovšem nevím, zda to bylo vyzkoušeno v praxi.

Sítě CZFree budou nabízet masivně IPv6 chvíli po té co bude Mikrotik umět DHCP i pro IPv6. Tam kde routery běží na linuxu už IPv6 mnohde funguje, ale částech sítě běžící na Mikrotiku zatím nelze IPv6 rozumně nasadit. A u menších a středních routerů nemá Mikrotik konkurenci, takže běží na opravdu velké části sítí CZFree a malých ISP.

Nezvládnou.

Pokud se bavíme o "páteři" nebo MAN tak tam již IPv6 mají. IPv6 bude největší problém na poslední míli.Oba ISP mají totiž v oběhu veliké množství HW, který je IPv6 nekompatibilní a žádné jednoduchá výměna firmware nehrozí. Takže do roka to považuji za naprosto nereálné.

Bavíme se o CZFree ?

Sítě typu CZFree používají masivně dva druhy systémů na router. PC+linux a Routerboard+Mi­krotik. Obojí lze bez problémů upgradovat na novější verzi systému (Linux je jasný, Mikrotik lze updatovat na aktuální verzi 5,04 i v prastarém RB133). V CZFree je standardně zakázaný NAT, takže domácí wifi u uživatelů běží v režimu bridge a to že do jeho administrace se člověk dostane pouze přes IPv4 je úplně jedno, protože se jednou nastaví a pak na něj uživatel zapomene. DHCP zařízení u uživatele doma nedělá, takže to zda umí či neumí IPv6 nehraje roli. Takže k rozjetí IPv6 v takovéto síti stačí zprovoznit nějakou autentizaci uživatelů aby bylo možné poznat komu pustit internet a komu ne. A k tomu hodně pomůže DHCP, který ale zatím v mikrotiku pro IPv6 nefunguje.

Zasadni problem ve wifi sitich je v tom, ze ty klientske krabicky, ktrere delaji u uzivatelu pseudobridge (nejedna se o skutecny bridge, ten je mozny jen u AP, nebo u klientu v kombinaci s WDS) wifi a ethernetu, casto s IPv6 kloudne nefunguji (nebot tyhle pseudobridge prepisuji MAC adresy v ARP paketech a tedy jsou narozdil od skutecnych bridgu protokolove zavisle). Problem je take v tom, ze tato nefunkcnost je toho nejhorsiho druhu - RA paket projde, pocitace si IPv6 adresy nastavi, ale skutecna IPv6 komunikace uz nefunguje.

Na druhou stranu, u IPv6 je asi nejrozumnejsi, aby se ta wifi krabicka chovala jako router a naroutoval se na ni cely /64 prefix pro daneho uzivatele.

Opačný překlad existuje už dlouho a je poměrně primitivní (DNS64 a NAT64). Testoval jsem a funguje to dobře.

S clanku jsem pochopil, ze vse probehlo naprosto bez problemu. Vysledek je celkem dobry, ale problemy se vyskytly.

Treba OpenSuse vydal peknou zpravu, kde priznava probemy na US serverech (stejne jako zduvodnuje, proc nektere sluzby nemohl prepnout na IPv6)
http://news.opensuse.org/2011/06/09/world-ipv6-day-results/

Ale ubuntu.com se urcite nezucastnilo...