Názory k článku Den IPv6 proběhl a ke kolapsu nedošlo
-
IPv6 jako takové není až tak špatný protokol. Ale kvůli věcem ohledně autokonfigurace ho prostě v koncových sítích nemůžu nasadit. Potřebuju filtrovat počítače s konkrétními adresami a ne aby se mi počítače konfigurovaly samovolně. V tom vidím jediný zásadní problém s nasazováním IPv6 v koncových sítích. Kdyby nic jako autokonfigurace neexistovalo, nebo to šlo lehce vypnout, mám pocit, že IPv6 by bylo daleko jednodušší na nasazení, než je teď.
S tím souvisí i to, že měl být zachován DHCP server ve stávající podobě, jako ho známe teď. A ne nějaké nesmysly s DUID. MAC adresa je přeci taky unikátní a dostanu stejnou adresu pro Windows, tak pro Linux. Navíc, při reinstallu systému se nemění.
Kdyby IPv6 fungoval tak, že budeme mít jak DHCP, tak RA, přičemž by bylo na správci, pro co se rozhodne, bylo by to fajn. DHCP by fungoval na základě MAC, uměl by nějakým parametrem vypnout autokonfiguraci a vše by běželo "podobně" jako na IPv4.. Kdežto přes RA by se sdělil jen prefix podsítě a autokonfigurace by mohla svištět vesele dál. Toho by se např. dalo využít u Wifi sítí v budově. S tím samozřejmě, že při použití obou systémů by mělo mít prioritu DHCP a nebo by byla volitelná přes DHCP či RA
-
f. (neregistrovaný)
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.
-
Bezpečnost je v tomto případě stejná, jako je ve světě IPv4. Zkusím to vysvětlit na následujícím modelu....
Ačkoliv jsem maturoval před pár týdny, spravuju síť na jedné menší obchodní akademii (cca 200 žáků). Naši síť tvoří 7 Cisco SW, 2 linux routery a asi 120 počítačů plus tiskáren. V současné době je stav takový, že mám síť rozdělenu do 6 VLAN a v každé z nich mám jinou adresaci. Toť asi k současném stavu, kdy chodí vše jak má.
Nyní si vemte, že bych chtěl zavádět IPv6. No fajn, takže to znamená získat nejlépe native konektivitu od providera (není problém) a začít rozdělovat podsítě. Taky v pořádku. Ale jak jsem psal výše. Nejhorší na IPv6 je právě a jen jeho spravování. Nyní mám všechno děláno přes DHCP s tím, že mám vytvořeny rezervace na základě MAC. To je na systému nezávislé a chodí to naprosto spolehlivě a JEDNODUŠE. Teď si vemte, že bych tam měl nasadit IPv6. V tu chvíli se ze sítě, která je srovnaná a přehledná stane síť naprosto rozházená a nesrovnaná. Proč ? Odpovím si sám. Autokonfigurace.
Současný stav je takový, že fajn, použiju RA, ale v tu chvíli si PC vygeneruje pseudonáhodnou síťovou část adresy. No fajn, ale jak poznám, které PC je lektorské, abych si ho povolil na proxy ? To to mam hledat podle MAC adresy a přepočítávat si ji do IPv6 ? no to snad ne. V IPv4 kouknu a vidim, že adresa 192.168.x.100 je lektorské PC.... A nebo mohu použít DHCPv6, které ovšem nesdělí default-gateway a stejně pracuje na základě nějakého DUID, které se ovšem s reinstalací systému mění a není pro všechny systémy stejné.
Z toho jasně plyne, že jediný opravdu reálný problém nasazení IPv6 v koncových sítích je jen a jen jeho složitost na autokonfiguraci a tím pádem i bordel v síti. Obcházet 120 zařízení a všude nastavit statickou IP, to opravdu nee. Pokud by byli lidé, kteří IPv6 vymýšlí při smyslech, stačilo by to implementovat tak, jak jsem psal výše a většina složitostí by byla eliminována.
Navíc, píšete tu o bezpečnosti. To je ale prašť jako uhoď v IPv4. Klient si může změnit MAC adresu, může změnit IP a může změnit i DUID. To je fakt. Ale na toto stačí podle mě 3 písmenka - ACL. Pokud uživateli na klientské stanici nedáte práva k těmto změnám, tak nic z toho nehrozí. Tím myslím i zabezpečení biosu, bootování, DVD mechaniky apod. V tu chvíli si nikdo neškrtne ani s LIVE CD. Můžete namítnout, že v tu chvíli si přinese někdo svůj PC a tohle vše obejde. To ano. Ale proto existuje věc jako 802.1X a RADIUS.
Nejsem sice žádný bezpečnostní fanatik, ale u nás ve škole to mám takto.
1) na žákovských PC vypnuty USB, DVD mechaniky, zaheslovaný BIOS, zašroubovanou case
2) studenti i učitelé mají omezená práva, tudíž změna MAC, IP či DUID je vyloučena.
3) celá drátová síť je zabezpečena pomocí 802.1X, kdy se ověřuje proti Active Directory identita počítače. Jakmile není v AD, tak si prostě neškrtne. Linux na desktopech nepoužívám a ve velkém prostředí ani používat nehodlám, takže tohle neřešim.Můžete mi dát za pravdu, můžete se mnou nesouhlasit. Takhle to prostě vidím já. Dokud nebude možnost volit mezi RA+SLAAC a DHCPv6, jak jsem psal výše, tak se IPv6 budu bránit zuby nechty. Podle mě má RA+SLAAC odůvodnění jen v podnikových wifi sítích a v nezabezpečených sítích. Ale v sítích, kde potřebujem pořádek mi lépe vychází použití DHCPv6 tak, jak to navrhuju.
Můžu se zeptat, jak pořádek v koncových sítích řešíte vy ?
-
Santiago (neregistrovaný)
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.
-
Tak jediné k čemu je DUID dobré, je, že vím, komu tu danou adresu dávám. Takže pokud mám tu potřebu registrovat DUID a reagovat na změny v případě přeinstalování OS, tak všem neregistrovaným DUID přidělím adresy z nějakého poolu a pak je při přístupu na web transparentně přesměruju na webserver, kde si zaregistrují/přeregistrují svoje DUID. Stejně jako bych to udělal v případě, že si někdo vyměnil síťovku v počítači a chce stejnou IPv4 adresu. (a to se ještě nebavíme o různých windowsových přihlašovacích skriptech, kde se to dá určitě udělat automaticky při přihlášení do domény)
-
TP (neregistrovaný)
Myslenka dobra az na jeden problem, ze tohle ten uzivatel bude muset absolvovat hned 2x. Jednou pro IPv4 a pak pro IPv6.
Asi se to da poresit nejakym sikovnym javascriptem ktery si na tom registracnim webu jednou tapne na IPv6 a jednou na IPv4 adresu.
Mimochodem, tohle vytvari zajimave kombinace, protoze napriklad google uzivateli funguje (po IPv4), ale na imap server se z neznameho duvodu nedostane, protoze ten uz je napriklad dostupny po ipv6 - urcite se to bude dobre diagnostikovat :-).
A pritom stacila takova drobnost - zanechat v pozadavcich DHCPv6 klientu i MAC adresu a razem by bylo vse jednoduche.
-
TP (neregistrovaný)
Ta souvislost je velice prosta. Pokud by byla krome DUIDu (ten mi nijak nevadi) v pozadavcich zachovana i linkova adresa zadajiciho rozhrani tak si jednoduse vygeneruju dhcpdv6.conf po vzoru dhcpd.conf tedy:
host pcXXX {
hardware ethernet 08:00:09:aa:f4:cf;
fixed-address 2001:aaa:bbb::<napr. nejak zakleta IPv4>;
}a hodne veci se mi s tim zjednodusi. Takto musim vymyslet zcela novy mechanizmus jak se dostat k tomu DUIDu, coz nemusi byt ve vesech prostredich uplne snadne.
Prave to, ze je mnohdy mechanizmy v siti hodne prekopat, docela dost lidi od zavadeni IPv6 odrazuje :-(.
-
Aha, taková trivialita mne teda nenapadla. V tom případě se to holt udělá na dva kroky. V prvním kroku z DHCP serveru přidělím adresu z poolu, tím vznikne vazba DUID-IPv6 adresa, následně z neighbour-cache vytáhnu vazbu IPv6 adresa - MAC. Zbytek řešení je stejně triviální a můžeme nechat za domácí úkol :-)
-
tomfi (neregistrovaný)
Nevím kde přesně je problém.
Ve firemním prostředí dělá registraci administrátor.V domácím prostředí zákazník dostane celý prefix na router. Jak si přiděluje adresy svým zařízením doma, to je jeho věc.
V těch řídkých případech, kdy bude zákazník požadovat připojení PC přímo "do zdířky" ISP (tedy bez možnosti využít jednou zaplacený internet pro připojení mobilu, telefonu, televize, herní konzole apod.) si to holt bude muset řešit nějakou "registrací".
Pokud jsem se trefil s tím ISP tak jenom dotaz...
To zase chcete zákazníkům "prodávat" adresy a limitovat počet zařízení a jako "extra službu" budete prodávat připojení celé domácnosti?... to už můžete rovnou dodat, že IETF vám limituje příjmy, protože chcete klientům přidělovat IPv6 privátní natované adresy. (Aby dostal opravdu tu "nejkvalitnější" službu) -
TP (neregistrovaný)
Pravda, v samotnem DUID je zakleta MAC adresa a vetsina systemu je takto i vyvari, ale nemusi (viz. http://www.ietf.org/rfc/rfc3315.txt). Nicmene ma tom (jak uz to tak v IPv6 chodi) jsou 2 hacky:
- s DUID by se melo vzdy pracovat jako s celym retezcem viz. prislusne RFC:
Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs for equality. Clients and servers MUST NOT in any
other way interpret DUIDs.To by jeste nevadilo. Zadne RFC neni svate tak ta moznost teoreticky prichazi v uvahu. Ale
- DUID nemusi byt vytvoren na zaklade MAC adresy karty kterou komunikujete. Takze pokud jste na Ethernetu muze DUID obsahovat MAC adresu WiFi a obracne. Takze celkove receno i kdybyste se pokusil vycenichat MAC adresu z DUIDu tak vam ten udaj je stejne k nicemu, protoze koncovy system pouzije ke komunikaci jinou linkovou adresu nez je v DUIDu.
-
To stejné dělají překvapivě i současné počítače na IPv4. Do jednoho z těch vnitřních polí (myslím, že GIADDR) klidně narvou adresu bezdrátové síťovky, ačkoliv používají drátovou síť (a switch se vzteká a dál nepustí). Takže nic nového pod sluncem v IPv6.
DUID se pro DUID-LL vytváří správně z built-in síťovky. Nakonec chcete registrovat počítač, ne síťovku.
Pořád mně nedochází, jakým zásadním způsobem se liší GIADDR v DHCPv4 a DUID v IPv6. Jediné, co mne napadá, že OS se přeinstalovává častěji než síťovka.
-
Pavel Šimerda (pavlix) (neregistrovaný)
„DUID se pro DUID-LL vytváří správně z built-in síťovky. Nakonec chcete registrovat počítač, ne síťovku.“
Na kterých systémech to tak je? Protože tohle by stačilo jako řešení (skoro) celého problému.
„Pořád mně nedochází, jakým zásadním způsobem se liší GIADDR v DHCPv4 a DUID v IPv6. Jediné, co mne napadá, že OS se přeinstalovává častěji než síťovka.“
Říká ti něco bootování ze sítě?
-
> Na kterých systémech to tak je? Protože tohle by stačilo jako řešení (skoro) celého problému.
RFC 3315, 9.4.
> Říká ti něco bootování ze sítě?
Jo, a co má být? Pokud chce počítač nabootovat ze sítě přes IPv6, tak si DUID vytvoří nezávisle na OS, bude aso DUID-LL, tedy jiný než má OS, ale to neznamená, že ho v DHCPv6 nemůžu mít nabindovaný na stejnou IPv6 adresu. Pak je ovšem otázka, jak se s tím vypořádá OS. IMHO až to bude aktuální, tak se výrobci hardware a OS dohodnou, jak to DUID budou tedy dělat. Osobně bych to viděl na malý patch, který OS řekne "pokud už mám nabootováno ze sítě, tak DUID neměň".
-
Lukáš Doležal (neregistrovaný)
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ší ;)
-
TP (neregistrovaný)
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.
-
orim (neregistrovaný)
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í).
-
TP (neregistrovaný)
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.
-
TP (neregistrovaný)
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.
-
TP (neregistrovaný)
Bohuzel je. DHCPv6 je postaven tak, ze prakticky nemuze fungovat bez SLAAC, resp. sireni RA (flag M). Nemam totiz cestu jak sdelit klientovi default GW. Snaha propasovat default GW byla v roce 2009 navrzena, nicmene IETF ji shodilo ze stolu (viz. http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00)
Tak utekly 3 roky, nez se problem podarilo do agendy IETF propasovat dalsi navrh dhcpv6-route-option (viz. http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-01), ktery uz nastesti nebyl shozen ze stolu v samem zarodu a pokracuje do dalsiho zpracovani. Draft je sice k dnesnimu dni vyexpirovany, nicmene je naplanovan v agende na 81. meeting IETF. Musime tedy doufat.
Problem je, ze i kdyz bude prijat, tak bude trvat radu let nez se dostane do implementaci OS. Problem je take se soucasnou podporou DHCPv6, ktera prakticky rozumne funguje jen v MS produktech, jakz takz v UNIX-like produktech. V OS X mate napriklad smulu. Takze pokud chci dnes zavest IPv6 fungujici ve vetsine OS nemam jinou moznost nez SLAAC.
Mezi dalsi lahudky patri, ze jsem schopen 1 vhodnym RA paketem (slovy jednim) zcela zrusit konektivitu vsem klientum v lokalni siti podporujici SLAAC - coz nampriklad naprosto s klidem udelaji Win Vista se zaplym Internet Connection Sharing.
Takze z celeho toho vyplyva, ze volba vhodneho prostredku autokonfigurace tak aby nad siti byla jakz takz kontrola a aspon primerena uroven zabezpeceni je prakticky neresitelna uloha. Pokud chce spravce rozumne zabyzpecit sit tak mu nezbyva nez zakazat IPv6 protokol jako celek idelane na accesovem portu a je po problemech. Bohuzel - hodne spatne vysvedceni pro IPv6... :-(
Co me na tom stve je to cele zpusobene tim, ze je odmitano zapracovat reseni, ktere je jiz praxi proverene a leta pouzivane bez vetsich vyhrad.
-
TP (neregistrovaný)
Heh... mi to fakt zkratka neda... :-)
Ty implemetacni detaily jsou dost problem. Ono tem vselek jmenem RA guard neni zas tak vsespasitelny. Staci ten paket nafragmentovat anebo podstrcit vhodnou hlavicku, ktere ten fitrujici switch nerozumi, nicmene koncovy system ano.
Viz. http://www.networksecurityarchive.org/html/FullDisclosure/2011-05/msg00446.html .
Takze s celyma RA Gaurdama se muzou jit vsichni klouzat a delat packet reassembling asi nebude uloha vhodna pro accesovy switch. Reseni je proste. Prohlasime ze urcite ICMPv6 zpravy nesmi byt fragmentovane a nesmi obsahovat rozsirene hlavicky. Viz. http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt
Akorat zas bude trvat dlouho nez ty implementace OS budou tyto pakety interpretovat spravne. Takze vyrobce switche vas odkaze na toto RFC (az bude RFC) a vyrobce OS vam sdeli, ze toto RFC nepodporuje. No a spravce si to muze resit jak chce.
Btw. u vyrobce si stezovat muzete. Pak si ale nestezujte, ze switch, ktery podporuje tyhle prvky bude o neco drazsi. Takze si cilove koupite msito gigabitovych portu jen stovkove. Odmenou za to je ze budete mit napr. RA guarda, ktery vas stejne neochrani proti cilenemu utoku. No... nevim teda...
-
TP (neregistrovaný)
No - jenze ono fakt podle me horsi je. Pokud si na notasu zapnete DHCP server tak tim budou postizeni jen nove pripojeni klienti, protoze ti existujici si jiz budou prodluzovat adresu primo u DHCP serveru. Jeste neni 100% jistota, ze vas DHCP server odpovi rychleji nez ten spravny. Navic ty ochranne prvky jsou dneska uz docela znamy/bezne pouzivane.
Pokud takove RA pustite v IPv6 siti, tak jsou vsichni klienti vyrizeni prakticky okamzite. Faktem je, ze kdyz se neco takoveho stane tak se tenhle stav da lepe opravit nez podvrzeny DHCP server s nastavenym dlouhym casem :-)
Ochrana zatim... hmm no, spise je to spatne
RA guard - obejitelny viz. problemy s fragmentaci a rozsirenymi hlavickami
SEND - neni nativne podporovan zadnou platformou
ACL - jista sance je, musi to podporovat prvek a fragmentaci musi resit reasemblng :-(Takze realita je takova, ze na takovy typ cileneho utoku dneska muzete tak akorat bezradne koukat. Resp. dokazete to resit s naprosto silenymi naklady. A to zatim jen blokujeme RA. Ani jsme se nepriblizili k vecem jako je validace komunikujicich IP/MAC adres.
-
Santiago (neregistrovaný)
No, pokud si v (IPv4) siti nastavim stejnou IP jako brana, taky okamzite zacne mit problem znacna cast klientu (a dalsi se brzy pridaji).
Zakladni problem vidim v tom, ze na sitove vrstve (a to jak v IPv4 tak v IPv6) neni rozumne resena bezpecnost zakladni infrastruktury (ARP, pridelovani adres ..), cele je to navrzene spis pro site nezavislych pocitacu nez pro centralne spravovane site. Pak se to obchazi silenymi hacky jako RA/DHCP guard ve switchich.
-
mb (neregistrovaný)
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.
-
TP (neregistrovaný)
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.
-
Pavel Šimerda (pavlix) (neregistrovaný)
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.
-
TP (neregistrovaný)
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.
-
Luk (neregistrovaný)
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.
-
Martin P. (neregistrovaný)
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ší. -
> 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.Obyčejní lidé přemigrují tak, že jim operátor nabídne rychlejší internet, oni si prodlouží smlouvu na další rok a jako bonus ta nová krabice už bude umět IPv6 (Comtrend VR-3026e i Huawei HG622u).
Nedělal bych z toho takovou vědu... zjevně to operátoři umí už dneska.
-
Martin P. (neregistrovaný)
Ano jenže já mám opačný názor.
A to já z toho nedělám vědu, ale druhá strana to zjednodušuje, bagatelizuje. Jako oponent bych asi říkal, že schválně to zametá pod koberec aby protlačila to svoje.
Máte odhad jak velké množství lidí se tohle netýká? Musíte si uvědomit že zákazníci jsou ještě popuzeni z toho kdy jim někdo jiný nedávno slibovali settopboxem lepší výběr kanálů kvalitu u televize.... ...a moc to očekávání nevyplnilo.
Opět opakuji, že tady jde o to kdo to zaplatí. Nadšeně lidi kteří tvoří 80% trhu do toho první nepůjdou. ISP zdarma k připojení zařízení pro IPv6 nenabízí.
Řešení, které vychází z toho co píšete je drbst se pravou rukou na levém uchu. Modemy, které jste vypíchnu jsou v nabídce jednoho operátora a ten nenabízí přechod z ADSL na VDSL 1:1. Můžete přejít z ADSL na VDSL jen s nárůstem ceny. Klasika sleva je omezená na časový půl nebo rok pak za plnou palbu + modem za 1kč.
Ale co ostatní a nejen ADSL ISP?
To že na většinu lidí čeká nový router za 1/5 ceny obyčejného PC je zatím realita.
-
TP (neregistrovaný)
> Máte odhad jak velké množství lidí se tohle netýká? Musíte si uvědomit že
> zákazníci jsou ještě popuzeni z toho kdy jim někdo jiný nedávno slibovali
> settopboxem lepší výběr kanálů kvalitu u televize.... ...a moc to
> očekávání nevyplnilo.No i pres tohle tak i moji prarodice si vsimli, ze ten obraz je jakysi lepsi nez kdysi byval a navic se jim libi ze v ovladaci na jedno stisknuti vidi nabidku vsech programu. Par jich taky pribylo atd. Reknete si - pche takova blbost. Jenze IPv6 pro tuhle kategorii lidi nenabizi ani tohle :-( Hmm, dost mrzute. Navic za digitalizaci stala pomerne masivni kampan vysvetlujici uzivatelum, ze vse bude skvele. Netroufam si odhadnout kdo ji bude delat v IPv6 (a hlavne za co).
-
> Modemy, které jste vypíchnu jsou v nabídce jednoho operátora a ten nenabízí
> přechod z ADSL na VDSL 1:1. Můžete přejít z ADSL na VDSL jen s nárůstem ceny.Píšou:
"Naši stávající zákazníci si mohou zrychlit svůj internet bez navýšení ceny."
Ale pravda podrobně jsem se v podmínkách nehrabal...
> Klasika sleva je omezená na časový půl nebo rok pak za plnou palbu + modem za 1kč.
A to je argument proti čemu? To je standardní praxe snad u všech...
Já jsem psal, že operátoři zjevně umí protlačit ke svým zákazníkům nové krabičky.
> Ale co ostatní a nejen ADSL ISP?
Nikdo nečeká velký třesk...
Kabelové modemy jdou aktualizovat na dálku, a pak to bude vždycky o vyvážení nákladů mezi Carrier-Grade NAT (+ správa všech těch NATů) a rozdání/aktualizace IPv6 krabiček (+ správa dual stacku).
-
TP (neregistrovaný)
> Nedělal bych z toho takovou vědu... zjevně to operátoři umí už dneska.
Dokazete byt v tomto konkretnejsi? Kteri operatori dnes dokazou nabidnout masivne IPv6 konektivitu? Divaje se na statistiky google to nevypada, ze by tech klientu bylo prilis mnoho - 0.33% je fakt dost nizke cislo na to, ze je to tak strasne bezproblemove.
viz. http://www.google.com/intl/en/ipv6/statistics/
U operatoru vidim velice opatrna tvrzeni u tech kteri se problemem uz zacali zabyvat a paradoxne velice odvazna tvrzeni u tech kteri IPv6 jeste poradne nevideli (patrne zatim jeste nevi co je ceka :-)) ).
-
TP (neregistrovaný)
No s tim vytrhavanim z kontextu nevim - kdyz nekdo tvrdi neco o novych krabicich a ze neco neni problem a ze by z toho nedelal vedu tak na to musim reagovat protoze si myslim, ze to problem je a rada lidi si migraci na IPv6 predstavuje velice zjednodusene.
- IPv6 u ISP je znacny problem a jsou s tim spojene nemale nahlady. Rozhodne se zalezitost neda zjednodusovat na vymenu firmware v krabicce. V tomto smeru dost kvituji snahy O2, kde z tech prezentaci, mam skutecne dojem ze ti lide vi o cem mluvi a plany miprijdou dost realisticke.
- Zapnuti IPv6 uzivatelum ze dne na den nevidim realne. Takova zmena muze mit na klienta pomerne vyznamny dopad a v dnesni dobe, kdy se staci na zakaznika spatne podivat, a uz je u konkurence si jiste jen tak nejaky ISP nedovoli pristoupit k takovemu kroku. Zatim vetsina ISP blokuje IPv6 jako celek. Osobne vidim relane zavadeni IPv6 spis u novych zakazniku.
- Dovolil bych si take upozornit, ze vetsina velkych ISP jeste nepristoupila ani k testovacimu provozu a tech veci, ktere musi ISP upravit neni malo. Neni to jen infrastruktura, jsou to IS, mechanizmy pridelovani adres, monitorovoaci a dohledove systemy, navody pro reseni problemu, personal, firemni procesy atd.
A vysledek je zkratka videt. IPv6 je natolik (mnody nezdrave a zbytecne) komplikovany protokol, ze tech koncovych IPv6 siti je jak safranu. To jsou proste jasna cisla, ktera nepusti.
-
Martin P. (neregistrovaný)
Pravdě podobně jste nepochopil mou uštěpačnou poznámku.
Pointa je v tom, že zrovna Vám funguje měl být objektivní argument? Určitě ne. A pokud vezmu váš proti argument, proč bych zase měl pomáhat lidem co chtějí IPv6? Mě IPv4 funguje.Jinak zpět k projektu OpenWRT.
Každý modem, router, AP není podporován. Někde je podpora podle revize, jinde zase není podpora kompletní a jak OpenWRT přinese nějaké vlastnosti, jiné zase sebere. Nelze vycházet z toho, že OpenWRT je nějaké východisko. Protože postihuje možná do 20% zařízení v SOHO segmentu. -
anonym (neregistrovaný)
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?
-
Marian Kechlibar (neregistrovaný)
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.
-
Jimmy (neregistrovaný)
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.
-
Martin P. (neregistrovaný)
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é.
-
Jimmy (neregistrovaný)
Bavíme se o CZFree ?
Sítě typu CZFree používají masivně dva druhy systémů na router. PC+linux a Routerboard+Mikrotik. 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.
-
Santiago (neregistrovaný)
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.
-
Santiago (neregistrovaný)
Tak sis jen pravdepodobne nevsiml, ze se jedna o pseudobridge a ne o skutecny bridge (ackoliv je to tak obvykle oznacovane). Dobre to je videt treba na (skutecnem) AP, kdy v ARP tabulce jsou IP pocitacu klientu s MAC adresou klientske krabicky, namisto primo MAC adresy pocitace. Delaji to prakticky vsechny krabicky, s kteryma jsem se setkal.
Samozrejme, v te krabicce muze byt implementovany pseudobridge, ktery ma osetrenou podporu IPv6, takze IPv6 skrz nej bude fungovat (aniz by mel jakoukoliv 'viditelnou' podporu IPv6.
-
- (neregistrovaný)
před x lety ano, leckterý krabky měli jen pseudobridge, ale už pár let mají všechny krabičky co si členové pořizují, které se mi dostali do rukou možnost poctivého bridge, tj. wds klient+bridge_mode.
Největší boj bývá zjistit, jak se ku.va ten full-bridge režim u danného výrobce jmenuje v web xichtu (nebo ještě hůř, v nějakým windows-only klikadle). Ale i to se zlepšuje.Takže tohle přestává být problém, prostě admin_apka_2_člen: máš-li tam NAT nebo pseudobridge, je to tvůj boj, pokud tam máš bridge (takže si tvůj domácí comp pingu a vidím na ap jeho macku), tak ti rád pomůžu v případě problémů :-)
Aktuálně vidím jako největší problém brutální nedostatek ipv6 ready 1gbps smart switchu (optimálně s možností napájet přes poe) v dostupné cenové hladině. Typicky všechny ty 5-8-12 portový smarty rozesetý po sklepech-půdách-světlících-stoupačkách... tipycky pro jednotlivé vchody domů. Před 5 lety tam byli tupé switche, ale s růstem sítě byla nezbytná alespoň základní segmentace a management...
Nebýt tohoto problému, tak by se dalo velmi vážně už teď uvažovat o překlopení sítě na ipv6 only (minimálně u nových členů) a ponechat nat jen na igw ve formě 6to4 - páteřní spoje sítě, compy/apka s linuxem už jsou ready dost dlouho, L3 switche měníme za ipv6 ready právě v těchto dnech. -
TP (neregistrovaný)
Mimochodem ten nedostatek smart switchu muzete zminit az vam nekdo bude vykladat jak uz dneska vetsina zarizeni IPv6 podporuje a jak se vse vyresi prirozenou obmenou hardware :-) Ale to bylo jen rypnuti bokem.
Nicmene proc reaguju. Zminujete se o vaznem prekopeni na IPv6 only sit, ci aspon pripojovani novych lidi. To je vec v rovine uvah anebo uz to mate vyzkousene aspon v nejakem testovacim prostredi? Pochopitelne predpokladam v kombinaci s NAT64/DNS64. Jak se planujete v takovem prostredi vyrovnat se zarizenimi, ktere IPv6-only prakticky nepodporuji (MAC OS, Win XP, ...), ci s vetsinou aplikaci, ktere IPv6 zatim proste neumi (skype, MSN, ICQ)? Jsou s tim uz nejake zkusenosti? Diky.
-
Jimmy (neregistrovaný)
Zapomeňte na uživatele připojené přes wifi. Ve větších CZFree sítích už lidé připojení přes wifi na nějaký sektor jsou už v menšině a do budoucna jich bude dále relativně a možná i absolutně ubývat. Standart připojení u CZfree už je UTP kabel přivedený do bytu a končící v PC uživatele, jeho SOHO switchi nebo v poslední době ve wifi routeru TP-link, kde není využit WAN port a wifi router delá opravdu pouze bridge. V takové konfiguraci bridge není problém, protože to wifi běží v režimu AP.
-
me (neregistrovaný)
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/
ČLÁNKY DO MAILU