Vlákno názorů k článku IPv6 je jako mexická chřipka od Ondrej SanTiago Zajicek - Co treba radsi: Dam "ADD" a ke vsem...

Co treba radsi: Dam "ADD" a ke vsem adresam v siti pribydou jejich dvojnici s jinym prefixem. Dam "SWITCH" a defaultne (jako src a dst pro spojeni uvnitr site) se zacnou pouzivat ty nove (ale stare stale funguji pri explicitnim pouziti). a pak dam "REMOVE" pro odstraneni tech starych.

... ale byla by to super adrenalinova jizda. Dam "SUBMIT" a pak uz jenom cekam, esli se mi vsechny krabice v siti propoji :-)

To tak mozna v pripade domacnosti ci minifirmy. V pripade vetsi organizace to znamena minimalne prenastavit IP adresy vsech routeru a serveru a vyskyty IP adres v konfiguracich sluzeb a prekonfigurovat DNS.

No, to se ale vyjadrujete o necem o dost jednodussim - jen o zmene routovani a zadnem preadresovani. Pod preadresovanim si predstavuju situaci, kdy prechazim od jednoho ISP k jinemu (novemu) a tedy musim prejit na jine, uplne nove (PA) adresy. Reseni takove situace AFAIK neni v IPv6 o moc jednodussi nez v IPv4 (snad az na to, ze na IPv6 budu mit v obou pripadech jeden stejne dlouhy prefix, takze preadresovani bude mozne delat uniformne).

To asi mame. Samozrejme pokud mame velkou sit, pouzijeme jine reseni, napriklad klasicky multihoming a BGP.

Tady je spise rec o necem vyrazne jednodussim - mam dva routery, kazdy pripojeny k jinemu ISP, oznamujici do jednoho lokalniho segmentu pomoci ra tu svoji pridelenou /64 od toho konkretniho ISP. Na segmentu jsou uz jednotlive koncove hosty (ale teoreticky by asi nevadilo, kdyby tam byly i routery, me tak napada).

V pripade, ze dojde k vypadku jedne z konektivit, prestane tento router oznamovat, ze je router a "preadresovani" (ac o preadresovani de facto hovorit nelze, nebot ty adresy jsou v beznem provoznim stavu na kazdem interface dve ruzne globalni plus jeste link local) si udelaji ty stroje na tom segmentu samy tim, ze ztrati danou ipv6 adresu na interface a tedy i cestu k dane default gw a musi pouzit tu druhou. To je cele, zadny specialni protokol na to neni potreba ;-)

> Vnitrni sit by z principu nemela obsahovat desitky routeru.

Asi mame jinou definici 'vnitrni site'. Nevidim duvod, proc by se vnitrni sit vetsi organizace nemohla skladat z desitek L2 siti a routeru mezi nima. Routery klidne muzou pouzivat dynamicke routovani (treba OSPFv3). To ale nezajisti automaticke preadresovani.

> Síť s desítkami routerů bez jejich automatické aktualizace je podle mne asi amatéřina.

Porad tu nezminil nikdo zadny protokol, ktery by zajistil automatickou readresaci rozsahlejsi site. IMHO to je chimera a nic takoveho se prakticky nepouziva.

> některé routovací protokoly vůbec nevyžadují žádné adresování (OSPFv3).

OSPFv3 sice nepotrebuje verejne IPv6 adresy pro spoje mezi routery, ale aby melo OSPFv3 nejaky smysl, pak routery musi mit nejake sitove prefixy, ktere skrz OSPFv3 propaguji.

> jedinou adresu, kterou router potřebuje je ta na Loopbacku, kterou si skriptem změníte na stovkách routerů během minuty.

Tedy zadne automaticke preadresovani, ale rucni.

A jo, to mě nenapadlo.

S privacy extensions to muze byt docela orisek :-)

Ano, souhlasím, zakázání veškerého příchozího provozu je prasárna a můj počítač by měl alespoň odpovídat na echo request. Ale cílem bylo demonstrovat, že to jde, ne ctít RFC :-).

Řešením je přidat do netfilteru ještě jedno pravidlo, které povolí ICMP.

No vždyť já nemám zapnutý firewall na tom vnitřním počítači. To zablokování provozu jsem nastavoval na routeru, který je na lince k mému ISP. Pokud chceš zablokovat komunikaci na všechny počítače, tak do parametru -d dej místo jednoho počítače celou podsíť.
„navíc se skrytím veškeré informace o struktuře té vnitřní sítě, včetně třeba počtu počítačů.“
Tohle půjde jenom IPv6 1:n NAT nebo SOCKS proxy - stejný princip, jako u IPv4. A stejně jako u IPv4 pak analýzou provozu půjde s velmi vysokou pravděpodobností určit, jestli tam těch počítačů víc je.

Tak se podobny pravidla strci na router, tu samou skatuli co dneska dela NAT. ESTABLISHED a RELATED bez omezeni a NEW pouze zevnitr. A bezpecnost "aby nekdo nevlezl dovnitr" je vyresena. Zbyva jen "aby nam nekdo nespocital pocitace", a na to by mohly stacit Privacy Extensions, tj. casto se menici nahodny adresy. Pozorovatel uvidi milion adres, ale kolik tam je ve skutecnosti pocitacu, muze jen hadat. Pravda, v podani NATu tohle tajnustkarstvi funguje lip. Ale on stejne nakonec nekdo udela NAT i pro IPv6, i kdyz je to prisernej napad.

Nikoliv "na stroj". Na všechny stroje ve vnitřní síti (a podotýkám, že zdaleka ne na všechny si uživatel může firewall nainstalovat) a navíc se skrytím veškeré informace o struktuře té vnitřní sítě, včetně třeba počtu počítačů.

> Co se stane, když komunikuji s nějakým cočítačem ve vnitřní síti a dojde k readresaci? Nezačnou se ztrácet data když dejmetomu jeden už bude readresovaný ale druhý bude posílat data na původní IP?

Obecně je to tak, že počítač může mít několik IPv6 adres z různých sítí. Router ohlašuje všechny sítě s různými prioritami a časem životnosti. Ve fázi přechodu máte dvě IPv6 adresy, pak změníte všechno co potřebujete v DNS a nakonec vyhodíte starou adresu, až ji nikdo nepoužívá.

> A co celá infrastruktura DNS? Je nějak specifikováno, jak se mají chovat DNS servery (lokální) v případě readresace? A co DNS cache na klientech, je zaručeno že se vyprázdní aby nevrecely staré IP?

Opět řeší souběžná existence adres a DNS cache se vyprázdní po uplynutí TTL.

Co se týká zbytku, tak ta klientská část může zůstat stejná (pokud ovšem nemáte zapnutou privacy extension, kdy se adresa mění každých pár minut :-)

A pokud má někdo zafixované adresy v konfiguráku, tak pokud to ví, může ve své organizaci používat i ULA adresy (obdoba privátních adres). Jinak mu samozřejmě nezbývá než to změnit v konfiguraci.

Síť s desítkami routerů bez jejich automatické aktualizace je podle mne asi amatéřina.
Co by mě ale zajímalo je probíhající komunikace počítačů během readresace.
Co se stane, když komunikuji s nějakým cočítačem ve vnitřní síti a dojde k readresaci? Nezačnou se ztrácet data když dejmetomu jeden už bude readresovaný ale druhý bude posílat data na původní IP?
A co celá infrastruktura DNS? Je nějak specifikováno, jak se mají chovat DNS servery (lokální) v případě readresace? A co DNS cache na klientech, je zaručeno že se vyprázdní aby nevrecely staré IP?
Jinak by mě ještě zajímalo, jak je to s privátní částí IP. Přiřadí se při readresaci stejná? Eventuelně jde nastavit jako fixní a vrámci vntiřní sítě pouižívat pro adresaci jen tuto část (bez části přidělené providerem). Pokud ne, mohl by to být problém v menší síti, kde se nepoužívá DNS svázané s MAC adresou síťovky. Musely by se všude přepisovat IP.

ty firewally jsou svině, co? :-)

No právě. Vždyť vlákno začalo tím, jak udělat, aby se na stroj v IPv6 nešlo zvenku připojit.

Pokračujeme! Web server běží, adresu má a poslouchá a čeká na vaše telefonáty! Tak volejte 2001:470:9b01:1:1e4b:d6ff:fe1f:da37 a první šťastlivec možná něco vyhraje!

To je jak v nějaké televizní soutěži…

hahahahah.. to bylo fakt moc dobré.. dobře jsem se zasmál (".. přerušujeme soutěž.. musím někam běžet". :))))

Mně se po zadání www.lupa.cz objevila normální adresářová struktura, prostě IPv6 lupa zřejmě běží na jiném stroji než www.lupa.cz a požadavek určený pro ipv6.lupa.cz s hlavičkou GET http://www.lupa.cz/ jej natolik vyvedl z míry, že mi normálně zobrazil adresář s jeho obsahem, takže jsem si mohl prohlédnout návrh nové verze lupy, stažený web nějakého ministerstva atd :-)

A co je na tom k pobavení? Objeví se normální lupa.cz, jen přes IPv6.

Jinak články hlásající "IP adresy dojdou" a zároveň "Ne, prostě jen doba nenazrála." jsou bohužel typickou dnešní praxí. Všechny běžně používané operační systémy IPv6 zvládají bez problémů a tak nezbývá, než se vymlouvat na čínské krabičky, místo kterých už mohlo dávno běžet cokoliv funkčního (osvědčení výrobci nebo OpenWRT). I ten Mikrotik by IPv6 podporu mohl dotáhnout do konce, kdyby na něj šel tlak od zákazníků. Je to přece jen Linux obalený spoustou tlačítek a vybrané modely stojí pod 2 tisíce...

V naší síti jsem IPv6 nasadil až ke klientům za pár dní, běžně jej používám a už přes 2 roky všechna nově pořizovaná zařízení umějí IPv6 aspoň propustit. Ono totiž stačí jít něco udělat, místo psaní nesmyslů typu "nepoužívejte, dokud nebudete muset". Když bude každý čekat, ono se to samo nenasadí :-)

V současnosti je většina providerských sítí konstruovaná pomocí MPLS, čili tato otázka je poněkud zbytečná.

A i kdyby, je několik možností, jak to udělat:
1. některé routovací protokoly vůbec nevyžadují žádné adresování (OSPFv3)
2. může se použít ULA (varianta privátních adres) a jedinou adresu, kterou router potřebuje je ta na Loopbacku, kterou si skriptem změníte na stovkách routerů během minuty.

Routerboardy se dají sehnat za 1500 i s krabičkou a IPv6 podporují už poměrně dlouho.

Ale už tam může spadnout divize Cisca - Linksys. Třeba můj prehistorický Linksys nemá s IPv6 problém. Vzhledem k tomu, že customizace fw u dodávaných routerů není našim velkým ISP cizí, tak si dokážu představit i možnost, že by zákazníkům dodávali routery s DD-WRT (například).

> Readresace vnitrni site muze/ma probihat na IPv6 automaticky.

A ktery protokol zajisti readresaci (zmenu prefixu a prislusnou rekonfiguraci routeru) ve vnitrni siti obsahujici desitky routeru?

Zkus si zapsat adresu www.lupa.cz s IPv6 adresou do /etc/hosts a pobavíš se. Já jsem se teda pobavil celkem dost :-) (sice nechápu, jak to mají udělané, ale i tak je to zajímavé)

dyť píše, že u malých krabiček. Do této kategorie ještě cisco ani juniper nespadá. Tj. do krabiček okolo 2kKč.

Přerušujeme soutěž o ascii tučňáka, počítač s web serverem je totiž notebook a já s ním teď musím někam jít… Budeme pokračovat odpoledne :-).

Readresace vnitrni site muze/ma probihat na IPv6 automaticky. Dokonce ta sit teoreticky muze pouzivat vice ruznych prefixu zaroven a na tom ma byt postaven multihoming (s tim, ze router, ktery nema upstream, by mel prestat oznamovat, ze je router).

Ale jinak samozrejme nikomu nikdo nebrani, aby do linuxoveho jadra dopsal podporu pro ip6tables tabulku NAT :-)

No já mám pocit, že ten NAT nakonec do nějaké specifikace dostal.

Ono to má i jiné použití, než falešný fw. Třeba je pak možné měnit poskytovatele připojení bez readresace vnitřní sítě, ne?

Souhlas. A co se routeru tyce, s Linuxem neni problem, s Cisco ani s Juniper krabicemi take neni problem... Proste Patrick to nezvladl, to je cele :-)

c, d) Já po IPv6 používám hlavně SSH, protože mám pár strojů za NAT a nedá se na ně tedy po v4 dostat. Funguje to tak transparentně, že člověk v podstatě ani nemá šanci zjistit, že je připojen po IPv6 (musí si dát who na vzdáleném stroji).

Predpokladal jsem, ze Patrik uz dokaze odlisit problem infrastruktury od toho, ze nekteri vyrobci pisou do svych materialu veci, ktere nemaji s realitou co delat.

Nicmene diky za clanek, je na nem videt (i kdyz clovek musi pouzit lupu), kde je doopravdy problem - v nedostatecne podpore koncovych zarizeni a v posledni mili.

(bohuzel na lupe opet nebezi autentizace uzivatelu)

Mně všechno funguje, tak jestli to není rukama :-) (nebo operačním systémem…).

Ke krytí: To, co způsobuje nedosažitelnost počítače, je firewall. Ten není problém v IPv6 světe div se normálně použít.

Na http://[2001:470:9b01:1:1e4b:d6ff:fe1f:da37]/ na portu 80 běží webserver. Poskytuje jediný statický soubor s nějakým textem. Na routeru před ním jsem napsal:

ip6tables -A FORWARD -d 2001:470:9b01:1:1e4b:d6ff:fe1f:da37 -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A FORWARD -d 2001:470:9b01:1:1e4b:d6ff:fe1f:da37 -j DROP

Kdo sem první postne obsah poskytovaného souboru, vyhraje asciiartového Tuxe :-P.

Párkrát jsem si říkal, že tedy aspoň experimentálně vyzkouším přechod na IPv6, abych byl připraven, až dojde na lámání chleba. Vždycky jsem skončil na tom, že sice všechno je teoreticky připraveno, ale prakticky není použitelné nic od providera přes routery a firewally až po aplikace. Navíc s neřešenými problémy typu "jak zajistit stejnou funkcionalitu jako u IPv4/NAT, tzn. např. skrytí detailů sítě před vnějším prostředím nebo nebo nedosažitelnost vnitřního počítače, dokud sám spojení neiniciuje" (jasně, každý druhý napíše, že to se přece dělá tak a tak, ale, pánové, zkusili jste si někdy svoje rady provést v praxi? Abyste měli ověřeno, že to OPRAVDU funguje a není to jen teorie, že by to tak MĚLO FUNGOVAT?)

Technická: Jsem si dost jistý, že tohle není "tiára" o použitelnosti IPv6, ale spíš "tiráda". Ať žijí cizí termity ;-)