Názory k článku Česká republika jako IPv6 velmoc?

Zatím jsem pro něj našel jen velmi málo argumentů a šlo o dost specifické případy. Takže ano, ale ve většině případů lze jednoduše vypustit.

No, třeba na takové síti bych čekal krabičky co řeší dneska věci kolem DHCP snoopingu, ARP snoopingu, IGMP snooping, inspekce paketů, .... Problém bude řešit potřebné ekvivalenty pro IPv6, když řada výrobců nezvládla ještě korektně implementovat ani podpru na IPv4.

Zrovna překlad adres bych do IPv6 netahal. Ale takový překlad prefixů se pro tuto situaci hodí a doufejme, že dozná brzo rozumné implementace.
Jinak co jsem zkoušel, tak za takovéto situace funguje i teď relativně OK, Router přestane propagovat pčíslušný segment a překlopí se to na druhý. Aspoň kde je použita bezestavová konfigurace. Nicméně ot trvá nějakou dobu, než vychcípají timeouty, záleží, jak je mám nastaveno.
Varianta s překladem prefixů (a případně VRRP pro zálohu celého routeru) je rychlejší náhrada chcíplé cesty.

No, ehm, takze postupne:

> A jéje IPv6 hater, který si neumí ani nastavit server či síť, tak raději
> zůstává u zastaralé technologie, kde si už zvyknul na vohejbáky a
> narovnáváky, že áno.

Co je na IPv4 tak strasne zastaraleho a IPv6 to resi novym skvelym zpusobem? Muzete uvest konkretni priklady? (pomineme-li delku adresy).

> Osobně nevím, co by bylo na IPv6 nedokončené, po 16 letech to je
> logické. Třeba zmiňované přidělování adres je funkční, možná ho jen
> neumíš nastavit?

Ta autokonfigurace nevim. Az mi ukazete MAC OS, iPad, Win XP nebo i Linux s nakonfigurovanou IPv6 adresou vcetne DNS serveru aniz by jste si musle najdriv doinstalovavat nejaky SW tak vam to budu verit. Ostatne http://www.lupa.cz/clanky/ipv6-myty-a-skutecnost-dil-iv-podpora-autokonfigurace/

To s tim neumenim neco nakonfigurovat - asi uz se resilo munily tyden v threadu: http://www.lupa.cz/clanky/ipv6-myty-a-skutecnost-dil-ix-quo-vadis-ipv6/nazory/380356/

> NAT je jen obezlička z důvodů omezení zastaralých technologií, V IPv6
> není něco takého potřeba. Z tohoto důvodu je zjednodušení sítě a
> vzájemné dostupnosti výhoda, nikoliv naopak.

NAT i pres mnohe problemy prinasi prvky, ktere maji svuj smysl a tim, ze neco oznacime za zastarale tim ty pozitivni vlastnosti do noveho protokolu tezko preneseme.

switche bez DHCP snoopingu už nekupuji. Sice to nepoužívám v té nejsložitější variantě (tedy s ARP inspection) ale jenom pro blokaci nechtěných DHCP serverů. User X má pravdu - v nějaké firemní síti (nějaké běžné, střední) mám velkou kontrolu nad tím, co tam zapojím. Ale v metropolitní síti už ne (trochu nadnesený název třeba pro panelák o deseti vchodech). Stačí jeden trouba s ADSL routerem z bazaru a má problém desítky lidí jenom proto, že to používá jako switch a DHCP tam nejde vypnout ...

A používám i IP source guard (což lze použít i pro blokování DHCP). Nemám rád, když někdo používá IP která není jeho ... Nasazení nějaké pokročilejší kontroly přístupu (802.1x apod.) zatím totiž bohužel nepřipadá v úvahu.

To mi chybí pro IPv6. Kde je k tomu potřeba ještě RA guard. Takových switchů bohužel moc nexistuje.

Ano, pouzivam. DHCP snooping je v siti, kde se pripojuji uzivatele nad jejichz PC nemate kontrolu, naprosta nutnost. Nastesti rada zarizeni to uz dnes umi za relativne prijatelne ceny.

Motani DNS hijacking s tim uzce souvisi. Jednou z technik nasackovani do klientu falesneho DNS serveru je prave zneuziti DHCP. Zamorene PC si odposlechne odpoved DHCP serveru a vymeni v ni adresy DNS serveru (samozrejme pod utocnikovou kontrolou). To prosim neni nejaky hypoteticky problem. Toto se na siti bezne deje! Viz DNSChsanger - http://isc.sans.edu/diary.html?storyid=5434

Trebas pomoci prislusnych routovacich protokolu?

Jestli ti staci firma s +-150 desktopy a +- 20ti servery, kde je provozovano IPv4/IPv6 spolecne, tak jednu takovou mam jako zakaznika. Uzivatelum je to celkem jedno a me celkem tesi ze to funguje a predevsim ze se muzu zvenku pripojit na cokoli, aniz bych musel pro kazdej stroj nastavovat forward.

A opravdu nejaky routovaci software neco takoveho umi?
V OSPFv3 se zadna informace, ktera by se k tomu primo dala snadno pouzit, neni (napr. asociovat default routu s prislusnym prefixem), mozna by to slo naskriptovat, ale nevim o tom, ze by to nejak standardne fungovalo (ci ze by bylo nejake RFC, ktere by rikalo, jak to fungovat ma).

Záleží, co daný router umí. Některé to umí jen dle toho, zda je aktivní upstream linka, v RouterOS jde snadno svázat s ping6, kdy klidně testuji až dostupnost nixu. Teď jsem to řešil v nějakém ruském blackboxu a tam šlo volit s jakou routou v ospf3 svázat propagaci lokálního prefixu.
Ale stejný problém musíte řešit i při použití vrrp, aby daný router odpadnul (zmšnil svoji váhu), pokud nemá upstream linku, což opět není nijak ujednoceno, ale používá se obvkyle výše zmíněné a je jendo, zda IPv4/6.

Jenže na to není žádný standsrd ani v IPv4 světě, takže kdo si to nenastaví, tak tomu to nepojede. Tím pádem je to 1:1.

Pokud na tom trváte, tak je tu na to překlad prefixů v Ipv6.
Apropo, jak ta NAT krabičká se dozví, že má NATovat na něco jiného, že přes linku A na které umřelo někde něco dál? Tohle je snad stejný problém pro IPv4/6 a i v IPv4 si to krabička řeší nějka po svém a musí se to v ní nastavit.
Navidím rozdíl v tom, kdy musím řešit tuto detekci NAT box nebo pro ukončneí propagace routeru/prefixu do sítě.

Ty odpovedi se unicastem dorucuji velice spatne, kdyz zarizeni jeste zadnou adresu nema, takze prvnidotaz/odpoved jde pochopitelne broadcastem. Obnovovani adresy se uz pak deje naprimo mezi klientem a serverem. Rozumny zpusob zasazeni do tohoto procesu je v dobe prvni vymeny (napr. po zapnuti PC).

Mimochodem to je zase neco co se zrejme nekomu v ramci IPv6 jevilo jako vhodne ke zmeneni a DHCPv6 se vzdy dotazuje pres multicastovou skupinu - komunikace naprimo tam uz neni. Takze opet o neco bohatsi moznosti pro utocnika.

Jen by me zajimalo jestli na tech zasedani IETF se na vymysleni tech "vylepseni" stridaji a nebo je to dilo nejakolika jedincu. A teda u autokonfigurace se vyradili o 106. Skoda je ze pak stoji extremne hodne usili ostatni lidi aby se to z tech standardu dostalo pryc.

Slušný DHCP server pochopitelně odpověd pošle unicastem neb adresu dotazujícího se klienta zná.

Je otázka, jak to myslel. Některé DHCP krámy dělají to, že je broadcast adresa je v IP záhlaví (což musí být), ale v Ethernetu je už unicast na danou stanici a ne broadcast.
Jinak neplatí ani to o té obnově. Je pár DHCP serverů, které odpovídají vždy broadcastem, a to i při obnově adresy (např v ROSu je to i konfigurovatlené jak to má dělat).
Nutno podoktnout, že tyto optimalizace mají občas nehezké vedlejěší dopady. Pokud třeba klient má wokna s ESETetem, v něm zapnutou kontolu ARP, tak občas toto vede k tomu, že nedostane IP adresu, ale přitom úspěšně vyčerpá celý dynamický pool na DHCP serveru opakovanými dotazy. :-)

Když jsem u nás v naší Wi-fi síti nedávno přecházel na 5 GHz, tak jsem si jen v domácích počítačích s XP doinstaloval protokol IPv6 a ono to bez problémů funguje. Já jsem v tomhle vcelku amatér, takže jsem čekal, že to bude nějaký problém. A on nebyl.

Prepokladam, ze firma pouziva firewall a tudiz je stejne nutne udelat v nem diru.

I lidé, co nevidí dál, než na zápěstí své ruky, jsou na světě potřeba.

On je ovsem celkem rodil povolit prichozi komunikaci z XYZ vs pridavat N forwardu, navic (narodil od toho natu a forwardu) muzu pouzivat DNS => nemusim si pamatovat porty jednotlivych stroju.

O prehlednosti (bordelu) radsi nemluve.

Jiste, pokud provozujete VPN pres http na portu 80, tak vam mozna bude i temer vsude fungovat.

Ale to, zda je aktivní PPPoE vrstva/dostnau IP adresu řeší jen tu poslední míli (to je stejné jako u ethernet připojení/optiky testovat, zda je linka aktivní a dostanu IP adresu). Tazateli šlo o to, jak detekovat, zda linka umřela někde dál (třreba až propoj od daného nadřazeného carriera někam k backbone). Což pomocí informací z routovacích protokolů je celkem logické, ale asi pro většinu takovýchto koncových routerů není dostupné. Většina těch SOHO multiwan to umí řešit pingem někam (některé jen pomocí pingu na degault gate, což je nedostatečné).

Jenze v tom je prave ten problem. Zprovozneni IPv6 na mensi siti (rekneme domaci) neni zadna katastrofa. Problemy prichazeji v trosku slozitejsim prostredi, kde jde prave o ty detaily a hlavne spolehlivost. Tam IPv6 neskutecne pokulhava.

To je ale argument kteri ruzni IPv6 protagonisti nechteji slyset. Kdyz prirovnam vas pripad tak zapnuti IPv6 ve win XP je ekvivalentem nakonfigurovani IPv4 adresy. A jak jiste vime chod dnesnich siti neni jen o nakonfigurovani IPv4 adresy, ale je to vec ponekud slozitejsi.

Ano, výměna prefixu je skoro NAT, ale proti klasickému NAPT v IPv4 je tu dost rozdílů, je to bezestavové a mnohem rychlejší, jen tupě nahrazuji prefix, nemusím šaškovat s protokoly vyšší vrstvy (snad, praxe ukáže). Ale,určitě bude nějaká aplikace, co to špatně ponese.
Standardní protokol pro odstranění RA není a asi nebude, stejně jako není v IPv4 světě (pro odstranění routy přes chcíplého ISP, změnu VRRP váhy, ...). Je tojak který výrobce routeru si to naimplementuje a pomocí čeho. :-(
Jinak bych se rád zaptal zásupců primárně NAT řešení, zda mi můžou říci, čím ty toky NATovat, aby to mělo rozumnou odezvu a koncová stanice to nepocítila? Bavíme se řekněme o tocích 500 Mbps až 8 Gbps. Pohled na tu farmu krabic, které to musí řešit, co stály, co sežerou elektriky, tak výpočtem člověk zjistí, že platit si IPv4 adresy je nakonec ekonomičtější. :-)

Podle me to je ponekud umely priklad. Pokud bych mel zprovoznovat IPv6 presne kvuli tomu tak si najdu radeji jiny zpusob jak vec vyresit. V IPv4 si zprovoznim VPN (coz mi dneska umoznuje prakticky kdejaka krabice, ktera soucasne resi firewall pro firemni sit). V pripade IPv6 zadnu resit pridelovani adres, tedy zprovozneni DHCPv6, evidenci DUIDu (protoze o databazi adres z IPv4 se oprit nemuzu) a vytvareni der do firewallu. Nejak v tom nevidim ten benefit. Navic vsechny WinXP jsou timto mimo hru (leda ze bych do nich naklapal adresu rukama). Takze IPv6 v tomto smeru bude mozna prinosem, ale tak za 10 let.

Jasne rada siti toto nepouziva, protoze to zkratka neni potreba. Nicmene kdyz vec nekdo potrebuje, tak v IPv4 ma tu moznost za relativne dostupne penize. V IPv6 jsou tyhle veci zatim dost chabe. V tom je ten problem, protoze kdyz chci koupit switch dneska a pozaduju tyto funcionality tak na vyber moc nemam anebo si musim priplatit.

Takze kdyz to vezmu ryze z ekonomickeho hlediska je pro me lepsi koupit switch, ktery ma tyhle feature pro IPv4 a protokol IPv6 odfiltrovat jako celek - coz rada operatoru dela.

Pro nat neexistuje jediny smysluplny argument, protoze vse co prinasi nat jsou jen a jen problemy. Uz se tesim az nebudu muset denne vysvetlovat nekomu proc mu nefunguje VoIP, hra s kamosem, ...

Existuje v ČR firma o velikosti řekněmě 700-1000 PC, s dvěma desítkami svých serverů pro interní potřeby, možností práce na VPN z domova, vlastním mail serverem, vlastním nameserverem která UŽ jede kompletně na IPv6? Pořád se tu bavíme o SOHO nebo backbone, ale "zatím" si nedokáži (a nejsem rozhodně sám) představit "implementaci" IPv6 do nějakého takového podniku...rozhodně ne v téhle chvíli. Jen vysvětlování svému nadřízenému, že potřebujeme x novývh boxů za desítky nebo stovky tisíc, když to vlastně teď vše šlape tak jak má... Počítá se vůbec s přechodem stávajícíh IPv4 sítí na IPv6?

To je porad dokola. Kdyz nekdo rekne, ze DHCP snooping a odvozene bezpecnostni prvky jsou dulezite, tak se vzdy najde nekdo kdo tvrdi ze se to vlastne nikde nepouziva. Budete se divit, ale pouziva. Je rozdil mit firemni sit, kde je nad vsim jakz takz kontrola a pripojovat sit rekneme v panelaku. Pokud tam tyto ochrany nemate, tak staci jedno zamorene PC, ktere vam ovlivni chovani vsech ostatnich (= platicich zakazniku). Uz vubec neresime spoofovani adres a ruzne ARP (ND) utoky.

Tyhle ochrany jsou v rade siti dneska nutnost uz jen proto, ze DNS Hijack vyuzivaji lecktere viry/trojany (coz pred 10 lety napriklad nebylo). Problem je ze na IPv6 tyhle veci zatim poradne nefunguji a tak je v takove siti pak lepsi odfiltrovat IPv6 jako celek a je klid (coz zvladne dneska switch byt jen se zakladni filtraci).

Naprosty souhlas vcetne tech problemu, ktere popisujete. Mnozi vyrobci skutecne maji problem uvedene veci odladit uz treba jen proto, ze tech stavu a kombinaci, ktere v siti muzou nastat neni zrovna malo.

A presne proto je to v IPv6 pro jistotu 2x abychom se pri sprave siti prilis nenudili. Takze krome dohadovani se vyrobci ze nefunguje dobre ochrana na bazi DHCPv6, tak si k tomu jeste prihodime ochrany na bazi SLAAC (RA a spol.) a samozrejme kombinace uvedeneho. Aby to bylo jeste veselejsi tak SLAAC i DHCPv6 pouziva zcela jiny protokol a jinou logiku pristupu k problemu.

Ano, provozuji. A to jak ve firmách, tak i u ISP. Nejen DHPC snooping, ale IP guard, ARP inspekce, IGMP/multicast snooping, ve firmách i 802.1x, v roli ISP je místy jen ověření MAC proti Radiusu, dynamciké VLANy atd.
Někdy je oddělení (panelák) řešeno tak, že switch je nastavne pro izolaci jednotlivých portů a komunikace mezi sousedy musí jít přes L3 prvek před ním, což také řeší řadu nepříjemností atd.
Switche různé - Cisco, HP Procurve, 3Com/H3C, Allied Telesis, . Nutno poznamenat, že souhlasím, že to není jendoduché, protože v řadě z nich jsou chyby a složka emailů diskusí s tech supporty je hodně tlustá. Zvláště fáze, než se člověk probije přes vrstvu neschopných tech supportů a managerů až k vývojáři v Indii/Číně a vysvětlí si o co jde a doufá, že to pak snad trošku vylepší.... Protože dost často vše nefunguje jak má nebo kombinace některých věcí spolu (a v tom mají máslo na hlavě tak všichni výše zmínění výrobci, každý má nějaké ale, dost často i závislé na produktové řadě), a to je teprve IPv4 svět. V IPv6 toto bude dlouho ještě horší.

A jéje IPv6 hater, který si neumí ani nastavit server či síť, tak raději zůstává u zastaralé technologie, kde si už zvyknul na vohejbáky a narovnáváky, že áno.

Osobně nevím, co by bylo na IPv6 nedokončené, po 16 letech to je logické. Třeba zmiňované přidělování adres je funkční, možná ho jen neumíš nastavit?

NAT je jen obezlička z důvodů omezení zastaralých technologií, V IPv6 není něco takého potřeba. Z tohoto důvodu je zjednodušení sítě a vzájemné dostupnosti výhoda, nikoliv naopak.