Jak se v ČR řeší přechod na IPv6

9. 6. 2010 | Robert Krátký

Články - Jak se v ČR řeší přechod na IPv6  

V rámci konference Internet a Technologie 10, kterou pořádalo sdružení CZ.NIC, správce domény .cz, proběhla také diskuze na téma přechodu na IPv6 v České republice. Zúčastnili se jí zástupci významných firem (Seznam.cz, O2) a státní správy (Ministerstvo průmyslu a obchodu), kteří nastínili, jaké kroky ve svých oborech podnikají, aby byl přechod z IPv4 na IPv6 v ČR pokud možno hladký.

Obsah

• Situace
• IPv6
• Jak je na tom ČR
  • Co na to Seznam.cz?
  • Co na to Telefónica O2?
  • Co na to Ministerstvo průmyslu a obchodu?
  • Co na to D-Link?
• Závěr a zhodnocení

Situace

IP adresy přidělované prostřednictvím stávajícího protokolu IPv4 docházejí, a proto je nutné tuto záležitost neprodleně řešit. CZ.NIC uvádí, že „Podle současných odhadů zmizí za rok veškeré volné bloky IP adres využívajících stávající protokol IPv4. Během první poloviny roku 2012 pak IP adresy postupně dojdou i na regionální úrovni a u jednotlivých poskytovatelů internetového připojení, kteří adresy přidělují koncovým uživatelům.“

Pokud by v době, kdy IPv4 adresy dojdou, nebylo implementováno řešení, které nedostatek volných adres odstraní, způsobilo by to velmi vážné problémy při dalším rozšiřování internetu jak z hlediska dostupného obsahu, tak připojených zařízení. Vzhledem k tomu, že je dnes k internetu připojeno stále více počítačů, telefonů, spotřební elektroniky i dalších zařízení, byla by taková situace mnohem bolestivější, než by se mohlo na první pohled zdát. Totéž platí pro obsah – množství informací a služeb zpřístupňovaných přes internet stále stoupá, takže by vyčerpání IPv4 adres bez dostupné alternativy znamenalo velký problém.

Ondřej Filip, ředitel CZ.NIC: „Dnes z původního objemu IPv4 adres zbývá pouhých šest procent a jejich počet klesá rychleji, než se předpokládalo ještě před rokem. Rok 2012 se může zdát daleko, ale kompletní přechod na IPv6 je záležitost let – co do technologické složitosti jde o proces podobný například digitalizaci televizního vysílání. Lze to stihnout, ale je třeba začít s nasazením řešení co nejdříve, a to ve vzájemné součinnosti zejména poskytovatelů připojení a obsahu, státní správy, ale i koncových uživatelů.“

IPv6

Řešení je přitom známé již mnoho let. Zastaralý protokol IPv4, který vznikl již v 70. letech v prvopočátcích internetu, je nutné nahradit protokolem novým: IPv6. Ten nabízí 128bitový adresní prostor, takže bez potíží pokryje stávající i budoucí (alespoň v dohledné budoucnosti) požadavky na IP adresy. IPv6 poskytuje z hlediska uživatele stejné funkce, takže by se mohlo zdát, že jeho nasazení nic nebrání.

Háček je v tom, že jsou protokoly vzájemně nekompatibilní. Zjednodušeně řečeno to znamená, že se zařízením, které „umí“ pouze IPv4, si nepřečtete obsah poskytovaný přes IPv6 a zařízení s podporou IPv6 vám neposlouží v případě naprosté většiny současného obsahu, který je zpřístupněn přes IPv4. Tento problém má být řešen pomocí tzv. přechodového období, kdy budou poskytovatelé obsahu i výrobci zařízení podporovat oba protokoly. Nemilé je, že toto přechodové období již mělo dávno nastat.

Jak podotkl Ondřej Filip ve své úvodní přednášce, jde o problém vejce-slepice. Zatímco poskytovatelé internetového připojení čekají, až bude k dispozici obsah, ke kterému by šlo prostřednictvím IPv6 konektivity přistupovat, poskytovatelé obsahu čekají, dokud nebude dostatek uživatelů, kteří by chtěli k obsahu přistupovat přes IPv6.

Jak je na tom ČR

Připravenost České republiky na nevyhnutelný přechod na IPv6 lze nahlížet dvěma způsoby:

• Na straně jedné můžeme s potěšením konstatovat, že doména .cz a její správce CZ.NIC jsou zcela připraveni na IPv6. Totéž platí pro NIX.CZ (společnost sdružující české i zahraniční poskytovatele internetových služeb za účelem vzájemného propojení jejich sítí) – základní infrastruktura je na svém místě a připravena na provoz s protokolem IPv6.

• Druhá věc je připravenost uživatelů a poskytovatelů obsahu. V současné době je pouze 1,5 % webových stránek dostupných přes IPv6. Datové toky v rámci NIX.CZ také vypovídají o tom, jak málo rozšířený je IPv6. Nová verze protokolu tvoří přibližně 0,1 % z celkového objemu dat.

Ve srovnání s ostatními evropskými zeměmi je na tom ČR přibližně stejně jako její sousedé, možná máme lehce navrch. Výjimka je Slovinsko, které všechny ostatní státy v oblasti implementace IPv6 výrazně předběhlo.

Co na to Seznam.cz?

Ing. Michal Feix, provozní ředitel Seznam.cz, vystoupil s krátkou prezentací, která shrnovala, jak je na tom největší český poskytovatel obsahu s připraveností na IPv6. Mimo jiné v úvodu uvedl několik zajímavých statistik, které ukazují, jaký je výchozí stav a jakou infrastrukturu bude potřeba na IPv6 nachystat:

• Přes 1100 serverů na platformě Linux Debian.
• Přes 50 % serverů virtualizováno na platformě OpenVZ.
• Přes 7 Gbps internetového provozu.
• IPv4 rozsah 77.75.72.0/21 obsazen z víc jak 50 %.
• IPv6 rozsah 2a02:0598::/32 v ostrém provozu nevyužíván.

Pan Feix dále vysvětlil, jaké má Seznam.cz plány ohledně postupného posilování IPv6 konektivity (v současné době disponuje pouze tranzitním IPv6 spojením, nikoliv do NIX.CZ) a příprav pro překlopení webových serverů do duálního režimu. Pokud se chcete přes IPv6 podívat na seznam.cz už dnes, využijte adresu ipv6.seznam.cz (kromě toho, že půjde vaše komunikace přes zahraničí, tak na IPv6 stále nejsou připraveny DNS Seznamu – probíhá tedy překlad do IPv4).

Zajímavým aspektem plánů Seznamu je to, že po zprovoznění externích IPv6 DNS budou zprvu tyto servery vydávat IPv6 záznamy jen pro předem vybrané a otestované (IPv6) sítě – jinak budou dále vracet IPv4. Seznam chce spolupracovat s jednotlivými poskytovateli připojení a zajistit tak, že se IPv6 použije výhradně tam, kde je IPv6 konektivita správně a spolehlivě nastavena.

Již v roce 2010 chce Seznam zavést překlad protokolů na svých loadbalancerech a spustit informační podporu pro přechod na IPv6. V roce 2011 chce celou akci dokončit, včetně přečíslování svých interních sítí.

Co na to Telefónica O2?

Pan Jakub Votava představil plány Telefóniky O2, největšího českého poskytovatele připojení k internetu. Hned na úvod zmínil, že O2 předpokládá problémy s dalšími alokace od RIPE, takže pro jistotu počítá s tím, že už žádné nedostane. V tuto chvíli má jejich stávající nedočerpaný blok ještě 131 tisíc adres. Výhled na tento a příští rok pro nové zákazníky vypadá takto:

• 2010/100 tis. + 2011/90 tis. – Internet Express
• 2010/50 tis. + 2011/100 tis. – Mobile Broadband

Z toho je zřejmé, že IPv4 již Telefónice dlouho nevydrží. O2 je podle slov pana Votavy připraveno na nasazení duální konektivity na pevných i mobilních linkách. Konkrétně mají alokované IPv6 adresy, mají IPv6 v internetovém PoPu (Point of Presence), mezinárodní peering a jsou připraveni na národní peering s NIX.CZ. Takto vypadá plán dalších příprav:

• IPv6 DNS: 9/2010 hotovo
• IPv6 VPNs – 6VPE: 7/2010 hotovo
• IPv6 BRAS: 10/2010 testy, 3/2011 hotovo
• IPv6 GGSN: 12/2010 testy
• NAT 444: 12/2010 testy, 5/2011 hotovo

Za nejsložitější považují převod informačních systémů (tj. v systémech zákaznické podpory, objednávkových systémech atd.). Drobnost na okraj: O2 provozuje svoji IPTV na vlastních adresách, takže tam k žádným změnám nedojde.

V průběhu roku 2011 hodlají upravit svou nabídku datových služeb (rozšířit o nabídku plné podpory IPv6), přičemž od počátku roku poběží technické pilotní projekty a do konce roku má být hotová finální nabídka. Noví zákazníci budou automaticky dostávat koncová zařízení s podporou obou protokolů. Stávající zákazníci budou mít možnost o migraci na IPv6 požádat, což bude zahrnovat buď upgrade softwaru, nebo hardwaru na jejich koncovém zařízení. Ostatní budou i nadále připojeni s původními modemy a nebudou mít přístup k IPv6 obsahu.

Co na to Ministerstvo průmyslu a obchodu?

Ing. Mgr. Monika Pochylá z odboru elektronických komunikací seznámila přítomné s tím, jak se na IPv6 chystá MPO a co dělá proto, aby nebyla Česká republika jako celek zaskočena, až k přechodu z IPv4 bude muset dojít. Hned první slajd z její prezentace si zaslouží vystavení, protože lakonicky, leč výstižně ukázal, jaká je situace MPO a celé státní správy.

V dalších částech své prezentace slečna/paní Pochylá informovala o aktivitách týkajících se příprav na IPv6 v rámci Evropské unie, především jmenovala dvě sdělení Evropské komise zaměřená na povzbuzení států, aby nezanedbaly potřebné kroky k úspěšnému přechodu na novou verzi protokolu. Rovněž zmínila přípravné workshopy na téma IPv6, které EK pořádá.

Další organizace, které se podílejí na plánování nasazení IPv6, jsou Mezinárodní telekomunikační unie (International Telecommunication Union, ITU) a Organizace pro hospodářskou spolupráci a rozvoj (Organisation for Economic Co-operation and Development, OECD). Zatímco ITU například poskytuje podporu pro rozvojové země, OECD v roce 2010 měří úroveň nasazení IPv6.

V České republice je základní dokument určující postup přechodu státní správy na IPv6 usnesení vlády č. 727 (PDF) ke Zprávě o přechodu na internetový protokol verze 6 (Ipv6) (již vypracovalo právě MPO). Vláda tímto usnesením:

ukládá ministrům a vedoucím ostatních ústředních orgánů státní správy (a doporučuje hejtmanům a primátorovi hl. města Prahy) zajistit:

• od 30. června 2009 při pravidelné obnově síťových prvků jejich kompatibilitu s IPv6
• do 31. prosince 2010 přístup k internetovým stránkám a veřejně dostupným službám e-Governmentu IPv4 i IPv6

Ačkoliv to zní akčně a vzhledem k uvedeným termínům i poměrně slibně, sl./paní Pochylá upřesnila, že se naneštěstí jedná pouze o „usnesení“, takže nikomu nehrozí v případě nedodržení žádný postih, ani neexistují páky, jak příslušné úřady přinutit k poslušnosti. Ministerstvo průmyslu a obchodu se však bude po uplynutí termínu dotazovat jednotlivých ministerstev a úřadů, jak jsou s implementací daleko – a v případě zjištění nedostatků bude tyto prezentovat vládě.

Na závěr zazněla tzv. základní teze připravované vládní strategie „Digitální Česko“ (vizte zatím prázdný web http://digitalnicesko.cz): „Podporovat správu internetu zaměřenou na zavádění internetového protokolu Ipv6 a zabezpečeného systému DNSSEC“.

Co na to D-Link?

Jako poslední vystoupil Aleš Pícl, zástupce společnosti D-Link, tedy výrobce síťových zařízení, včetně domácích switchů, routerů a modemů, které bude nutné postupně vyměnit či upgradovat jejich firmware, aby si s IPv6 rozuměly. Podle slov pana Pícla je D-Link samozřejmě na protokolovou revoluci připraven – jejich firmwary již nyní nabízejí několik možností využití IPv6 konektivity, včetně tunelování IPv6 do IPv4, které umožní ve vnitřní síti dále využívat IPv4 zařízení.

Podstatným bodem této prezentace bylo upozornění na logo IPv6-ready, které D-Link a další výrobci používají k usnadnění jednoznačné a okamžité identifikace hardwaru použitelného s novou verzí IP.

Závěr a zhodnocení

Přestože jsem si od tohoto tzv. kulatého stolu příliš nesliboval, musel jsem opravit svůj prvotní pesimistický náhled – nakonec šlo o zajímavé a podnětné setkání, které může dopomoci k tomu, aby si alespoň někteří z hlavních aktérů nadcházející IPv4 apokalypsy ujasnili, jaká je situace v jednotlivých oborech. CZ.NICu tedy patří dík za to, že se snaží nastartovat debatu o tom, kudy se přípravy budou ubírat. A vzhledem k tomu, že se setkání účastnili i zástupci České televize, lze doufat, že se nějaké informace dostanou i k masám uvažujícím podle schématu „éčko=internet, web=seznam“.

Diskuse k tomuto článku

[Käyttäjä 11133]

A kdy bude ábíčko IPv6 ready? :)

[houska]

ipv6.abclinuxu.cz ti nejde? ;)

nejde prihlaseni :/

[pavlix]

Mimochodem samostatná doména a IPv6 ready je podle mě rozdíl.

[trekker.dk]

No ještě včera večer článek končil takhle:

Mimochodem, už jste zkusili ipv6.abclinuxu.cz?

Po jemném upozornění, že to jaksi nemá AAAA záznam, Robert odpověděl, že

Mám od adminů potvrzeno, že ipv6 funguje.

Museli jsme ho ukecávat dva, že to opravdu nejde.

Když jsme tak u toho, zajímalo by mě, kterýho experta napadlo používat pro abclinuxu.cz DNS servery, které jsou podle traceroute a pingu někde v Americe. OK, ta latence je asi zanedbatelná, jednak se projeví jenom občas a druhak oproti těm zbylým deseti vteřinám, kdy se stránka v Opeře deset vteřin nevykresluje kvůli různým googleanalytiksům, není moc významná.

Nicméně to není poprvé, co tyhle DNS servery vrací úplné nesmysly - včera záznam nebyl, dneska už je*. Minulý víkend bylo ábíčko půl dne nedostupné, protože nameservery vytrvale tvrdily, že www.abclinuxu.cz neexistuje (Samozřejmě bez zprávičky, která by upozorňovala, že se A záznam bude měnit). Opravdu si myslím, že tady v Čechách jsou poskytovatelé, kteří nabídnou lepší služby...

* Btw., nejsem expert na RFC, ale když už je něco CNAME, nemělo by to jméno, na které ten CNAME ukazuje, existovat?

[Robert Krátký]

No ještě včera večer článek končil takhle:

Ano, spletl jsem se. Ještě před vydáním článku byla chyba odstraněna.

Robert odpověděl, že

Ehm, odpověděl jsem přesně definovanému okruhu adresátů. Tato diskuse na seznamu příjemců nebyla.

Minulý víkend bylo ábíčko půl dne nedostupné, protože nameservery vytrvale tvrdily, že www.abclinuxu.cz neexistuje

DNS byly nedostupné. Všech 5. Nemohli jsme s tím nic dělat, nejsou pod naší správou.

Samozřejmě bez zprávičky, která by upozorňovala, že se A záznam bude měnit

Minulý týden se nic neměnilo. Jen došlo k výpadku, za který jsme se prostřednictvím FB, Twitteru a Identi.ca omlouvali (protože Abc bylo v tu dobu nedostupné).

[Käyttäjä 11133]

DNS byly nedostupné. Všech 5. Nemohli jsme s tím nic dělat, nejsou pod naší správou.

A vy jste ještě u stejného DNS providera? :)

[trekker.dk]

Ano, spletl jsem se.

No jestli ti řekli, že to funguje, tak se asi spletl někdo jiný, ale OK

Ehm, odpověděl jsem přesně definovanému okruhu adresátů. Tato diskuse na seznamu příjemců nebyla.

Měl jsem za to, že bude hezké vytáhnout na světlo, jak funguje správa abclinuxu. Od velkých pitomostí jako migrace na Xen, aby se o dva dny později napůl migrovalo zpátky, po malé, jako že Ti admin něco řekne, aniž by si to ověřil. Jestli s tím máš problém, můžeš mě s klidem vyjmout ze seznamu adresátů konference.

DNS byly nedostupné. Všech 5. Nemohli jsme s tím nic dělat, nejsou pod naší správou.

Což je přesně to, na co se ptám: proč si necháváte vést DNS záznamy u jakési společnosti v Americe, zvlášť poté, co se stane něco takového, jako že jim vypadne pět serverů. Tady v Čechách najdeš podstatně spolehlivější služby, nezávislé na zahraniční konektivitě a zadarmo nebo za mírný bakšiš.

Minulý týden se nic neměnilo. Jen došlo k výpadku, za který jsme se prostřednictvím FB, Twitteru a Identi.ca omlouvali

OK, beru, možná se ta adresa měnila už dřív. A když jsem koukal na Twitter, nebylo tam nic.

[Robert Krátký]

Měl jsem za to, že bude hezké vytáhnout na světlo, jak funguje správa abclinuxu.

Budeš se divit, ale nepřipadá mi to hezké. Snažíme se dělat, co je v našich silách a možnostech, takže sice oceňujeme podnětnou kritiku, ale nijak nás netěší podobné pranýřování - navíc založené na neúplných informacích.

Tady v Čechách najdeš podstatně spolehlivější služby

Já o tom nerozhoduji. A ti "admini", které jsem tu zmínil, také ne.

A když jsem koukal na Twitter, nebylo tam nic.

http://twitter.com/abclinuxu/status/15113537864 -- jsem si vědom, že Twitter není nejvhodnější komunikační kanál - na každý to čte. Ale ten výpadek nakonec nebyl tak dlouhý (např. můj poskytovatel to měl keši většinu doby výpadku), aby mi připadalo vhodné k tomu ještě psát zprávičku na web.

[Leoš Literák]

Ta pitomost s Xenem už nějaký ten rok funguje.

[trekker.dk]

Pokud si dobře vzpomínám, poslední informace byla, že následně poté se musela databáze vrátit na samostatný stroj. Takže jaký smysl mělo odstěhování kusu ábíčka na virtuál? IMO žádný.

[Dan Ohnesorg]

Napr. je mozne oddelit vyvojove veci do samostatneho prostedi, kde pripadna chyba nijak neovlivni produkci, pro kazdy virtual je mozne nastavovat veci odlisne, treba mit ruzne javy a nebat se, kdy nejaka aktualizace sahne do te nespravne. Virtualizace ma sve vyhody i pod linuxem, byt ne tak masivni jako pod Windows, kde adminy trapi potreba unifikace HW. Linuxovy kernel se spravnymi udev pravidly najede na jakemkoliv zeleze kam se da stejnym zpusobem.

Na druhou stranu virtualizace je strasne narocna na propustnost diskovych poli, protoze virtualy nedokazi adekvatne spolupracovat, radit pozadavky na disky, kazdy ma vlastni diskovou cache. Takze skutecne si ji uzijete jen s diskovymi poli na ktere abicko nevydela ani za 100 let. A je tam samozrejme problem s segmentaci pameti, kdyz bezi vsechny sluzby nahromadce, tak se o pamet podeli dynamicky, virtualy maji pridel pameti pevne dany pri startu.

[default]

oproti těm zbylým deseti vteřinám, kdy se stránka v Opeře deset vteřin nevykresluje kvůli různým googleanalytiksům

Na to existuje velice elegantní řešení.

[trekker.dk]

Vzhledem k tomu, že Opera je IMO co se použitelnosti (UI) týče nejlepší dostupný prohlížeč, řešením je pro abclinuxu (a jenom pro abclinuxu) používat něco jiného, což moc elegantní není.

[default]

Content Blocker?

[Dan Ohnesorg]

Ono to neco na co ukazuje CNAME existuje, ale ma to jen AAAA zaznam, protoze jinak by se nepoznalo, jestli se jde po IPv6 nebo IPv4.

Cili aktualne pokud vam nejde adresa ipv6.abclinuxu.cz, tak to znamena, ze nemate IPv6 konektivitu a nebo nekde chybi routa. Ev. v krajnim pripade dostavate z cache nejake stare veci, ale TTL byla takova, ze melo vsechno nabehnout nejpozdeji nekdy kolem 1:00.

Jestli pujde nejak osefovat prihlasovani se podivam.

Nicmene mame tady zaznamenanych 33 unikatnich IPv6 adres, takze to neni zadna masovka

[trekker.dk]

Ono to neco na co ukazuje CNAME existuje, ale ma to jen AAAA zaznam

Což to vím, jenom mi přišlo divné, že když se pošle dotaz na A záznam že to vrátí CNAME, který už neexistuje.

[Dan Ohnesorg]

Premyslim o tom a rekl bych, ze tohle je proste neco na co si budeme muset s IPv6 zvyknout. Neexistuje zadne CNAME pro IPv6.

[petr_p]

A kde má čtenář čuchat, že existuje ipv6.abclinuxu.cz? Kdybyste hodili AAAA pro www, tak by se vaše statistika dala brát vážně.

[Robert Krátký]

Viz #6.

[Dan Ohnesorg]

To je jen takova hracka - experiment.

[petr_p]

Nevím, kam až váš experiment sahá, ale hlásím, že nesedí doménové jméno v X.509 certifikátu.

[Dan Ohnesorg]

Tak urcite nesaha tak daleko, aby mi nekdo schvalil nakup dalsiho certifikatu, dam tam nejaky mene duveryhodny.

[xkucf03]

Třeba CAcert, ten už mám nainstalovaný.

[Dan Ohnesorg]

Zkusime startcom, ten by melo mit o neco vice lidi nez CAcert. Cekam na validaci vlastnictvi domeny.

[xkucf03]

jj, startcom znám taky. BTW: jaké s nimi máš zkušenosti? Uvažuji o placeném certifikátu od nich.

[Dan Ohnesorg]

Jako Verisign a Thawte partner musim rict, ze je to spinava konkurence

Obecne nejsou moc znami/duveryhodni, coz ovsem postihuje 90% implicitne duveryhodnych autorit. Samozrejme ne kazdy instaluje do windows i nepovinne aktualizace, takze nemusi mit jejich autoritu mezi duveryhodnymi. Ted aktualne me rozciluji, ze uz druhy zaslany autorizacni kod konci pri validaci tim, ze jejich web toci hodinami az do timeoutu. A samozrejme kdyz vlezu znova do overeni, tak zase poslou dalsi, zase budu muset shanet majitele domeny, aby mi jej predal.

Cena jejich certifikatu je ovsem neodolatelna. Jsou schopni vystavit EV certifikat s nekolika SAN za cenu nejlevnejsiho Thawte certifikatu.

[xkucf03]

Zatím od nich využívám jen ty neplacené certifikáty a zatím s těmi kódy a validacemi nikdy nebyl problém.

Ta cena je fajn a hlavně: pokud jsem dobře pochopil jejich podmínky, tak platíš za ověření totožnosti, ne za doménu – takže si teoreticky můžeš vydat kolik certifikátů chceš, jen musí být tvoje – nemůžeš si z toho zřídit živnost a přeprodávat je (na to mají nějaký partnerský program). Jediné, co mě trochu odrazuje je, že chtějí poslat ofocené doklady. Ale tomu se asi nevyhnu nikde, co? A taky vypadají celkem linux-přátelsky

[Dan Ohnesorg]

Ofocene doklady zase tak moc CA nechce, mohou pozadovat pro spoustu lidi vetsi opruz, napr. byt uveden v oficialnim telefonnim seznamu daneho statu nebo byt drzitelem bankovniho uctu a dokazat o tom poslat potvrzeni.

Certifikat vypada potom takto:

openssl x509 -in all.rudna.net.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3024 (0xbd0)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing,\
 CN=StartCom Class 2 Primary Intermediate Server CA
        Validity
            Not Before: Nov 19 00:00:01 2009 GMT
            Not After : Nov 19 23:40:17 2011 GMT
        Subject: C=CZ, ST=Stredocesky Kraj, L=Rudna, O=Dan Ohnesorg,\
 OU=StartCom Verified Certificate Member, CN=*.rudna.net/emailAddress=hostmaster@rudna.net
.....

Cili v kazdem certikatu je obcanske jmeno, potazmo jmeno firmy, ale to je zase dalsi platba, protoze oni to kumuluji, overi osobu, pak overi, ze nekde pracuje, za kazde z techto overeni se plati.

[Limoto]

Tak jsem to "vyřešil" po svým:

2a01:430:10::1 abicko.abclinuxu.cz abclinuxu.cz www.abclinuxu.cz

[Dan Ohnesorg]

Udelejme to jinak, zmenil jsem IPv6 na adresu 2a01:430:10:ab::1 a udelam z toho rozsah jen pro abicko, stavajici IP se pouziva i jinde. Tim padem budu moct ten rozsah libovolne smerovat nezavisle na jinych sluzbach.

[Limoto]

No nepřijde mi, že by tahle adresa fungovala...

[Limoto]

Teda ping jde, ale web na ní neběží...

[Dan Ohnesorg]

Uz jo, to je tak kdyz mi furt nekdo telefonuje v pulce rozdelane prace

[tito]

A přesně o tom to je. Až na IPv6 přejdou velcí provideři typu Telefonica O2, tak se to rozjede. Nějaká státní správa je z tohoto hledidska naprosto nezajímavá.

A co na to akademicka obec ? Nevíte někdo jak je na tom AVČR, velké univezity (UK, MUNI, ČVUT ...) či Cesnet ?

[janosh]

FIT VUT Brno je IPv6 ready, viz uvodni strana. Predpokladam, ze i cele VUT je pripraveno, ale to nemam overene.

[yac]

Dokonce i věhlasné studentské fórum FIT podporuje IPv6 (nebo se tak alespoň tváří) ;]

[petr_p]

Yenya se chlubí (2010-02): We have finally got some time to work on native IPv6 inside a faculty network (which includes rewriting the iptables configuration to be protocol-neutral)… For now, we want to create 3rd-layer infrastructure for IPv6, and then the services will follow.

[SAM:]

ČVUT je co se týče IPv6 na bodu mrazu i VŠE je na tom lépe. Není pracovní skupina, není koncepce, není chuť. Totální bída. Snažíme se teď vlastními silami rozjet alespoň něco na karláku.

[xkucf03]

i VŠE je na tom lépe.

Teda ty o nás musíš mít mínění Náhodou jsme celkem pokroková škola. No i když asi jenom v tomhle, pak je spousta věcí o kterých radši nemluvit.

[SAM:]

No určitě znáte ten vtip: Když se polovina studentů FELu odejde na VŠE, tak se průměrná inteligence zvýší na obou školách s MFF -> FEL to platí taky

[tomfi]

Chápu to dobře, že studenti FELu jsou inteligenčně podpůměrní studenti CVUT?

Ohledně srovnání FEL vs. VŠE to přesně nechápu... pro studium ekonomiky je myslím třeba jiné nadání než pro studium elektro.

[pavlix]

Chápu to dobře, že studenti FELu jsou inteligenčně podpůměrní studenti CVUT?

To tam nikde nevidím.

Ohledně srovnání FEL vs. VŠE to přesně nechápu... pro studium ekonomiky je myslím třeba jiné nadání než pro studium elektro.

To vychází z toho, že tvůj předřečník možná ani netuší, že se na VŠE nějaká ekonomie učí. On zná VŠE zřejmě pouze jako fakultu informatiky a statistiky, což je jedna z těch slabších infomatických fakult v republice.

[corwin78]

Mám od D-Linku NASku a APčko. Pevně doufám, že ty firmwary upraví na IPv6 (přece jen je v tom Linux) a nevybodnou se na SOHO segment. Nerad bych kupoval nová zařízení.

[Mti.]

jenze oni by radi abys kupoval...

[corwin78]

No to je mi jasné, ale moje železo je spíše to lepší z jejich nabídky, a tak by mě to moc nepotěšilo.

[xkucf03]

V tom problém nevidím – já klidně tu tisícovku za nový modem dám, nebo trochu víc, tentokrát bych asi koupil verzi i s Wifi ať mám místo dvou krabiček jen jednu. Pokud tohle má být brzda rozšíření IPv6, tak to je to nejmenší. A ať si D-Link klidně nahrabe, já bych jim to i přál , hlavně ať tady tu IPv6 máme co nejdřív.

Na druhou stranu, pokud je v tom zařízení Linux (jako že většinou je), tak by sis do něj měl mít možnost tu IPv6 podporu dodělat i sám, zdrojáky bys měl dostat.

[the.max]

tak na tohloe rovnou zapomen, firmware by sice udelat mohli, ale proc by to delali? Pokud o IPv6 stojis, urcite si rad koupis i novy router s podporou IPv6

Uz bys mohl vedet, ze o prachy jde vzdy az v prvnim miste.

Nicmene toto je pouze d-link, co ostatni vyrobci? btw vi nekdo o nejakem wifi routeru s IPv6 podporou a idealne Atheros cipsetem? (tim nemyslim nejake Asusy ci Linksysy s OpenWRT, potrebuju proste jednoduse spravovatelnou (prez web) krabicku, kterou budu moci davat zakaznikumzatim to resim tak, ze pokud je zakaznik pripojeny na wifi (ma mikrotika sam pro sebe), tak 6ka je na mikrotikovi a domaci wifi router stavim do pozice hloupeho 4portoveho switche s APckem. Vypnu DHCP a mikrotika pripojim do LANu. WAN zustava nezapojeny. Pokud je nekdo v panelaku na optice nebo TPcku, ma bohuzel smulu, pripadne si musi poridit vedle wifi routeru navic jeste mikrotika RB-750...

[cejvik]

Myslíte něco jako CC&C: WA-6201-V5 150 Mbps AP/Kl/Router/Switch, USB (2,4 GHz, 802.11n, IPv6)

http://www.i4wifi.cz/?cls=stoitem&stiid=1752

[the.max]

mozna, ale tohle urcite ne ze dvou duvodu: Cipset a prodejce. Ani jedno opravdu neprekousnu. Jak uz jsem psal, preferuji Atheros a v i4 odmitam koupit i kus kabelu, byt by to byl posledni kus kabelu na svete.

[the.max]

navic jen 2 LAN porty je opravdu zoufalost, to k tomu musim dokoupit switch, takze v konecnym vysledku se dostanu na podobnou cenu jako rb-750 + nejake AP.

[Grunt]

Jednoduchá odpověď.

[vencour]

Do Linksyse WRT54GL (wifi AP) ho dam ... do Linksyse WAG160N (adsl modem s wifi) nee. V nouzi bridge.

[Grunt]

Zvláštní. V rukách to určitě nebude, že?

[vencour]

Žůžo, dík ...

Malá změna ... vedu WAG54G2 a zatím ještě podporovaný není. Na WAG160N jsem "jen" mlsně koukal ... když jsem vybíral. A o2tv neumí ani jeden z nich, jelikož neumí atm multipvc.

[FOK]

Velký propagátor IPv6 není dostupný přes IPv6?

No AAAA records were found for www.nic.cz
No AAAA records were found for ipv6.nic.cz

IPv6 u D-Linku znamená, že u daného zařízení lze flashovat bios. Nikoli však reálnou oficiální podporu IPv6. Pokud tedy nepočítáme firmware třetích stran. Takže o nějaké připravenosti nemůže být ani řeč.

Situace s přechodem na IPv6 docela tristní. Myslím si, že by měli co nejdříve přejít na duální provoz poskytovatelé obsahu . Jedině tak lze očekávat, že se o IPv6 začnou zajímat i uživatelé, pro které nebude přechod znamenat krok zpět. Ti snad svým zájmem poté přinutí své providery k přechodu na IPv6. A především je potřeba, aby se do IPv6 vrhli výrobci síťových prvků, protože to je v současné době asi největší brzda rozvoje IPv6.

Masám, pro které éčko=internet je naprosto jedno jaký protokol používají. Oni ani netuší, že nějaké IP existuje, protože používají to co jim řekne jejich provider. Je opravdu potřeba začít u poskytovatelů obsahu a providerů. Oni jsou totiž ti, na koho vyčerpání IP adres dopadne nejvíce. Obyčejný uživatel si vystačí s NATem. Ale zkuste si provozovat webserver bez veřejné IP adresy. A nebo je současný liknavý přístup spíše úmyslem, aby se v budoucnu elegantně zamezilo vzniku nové konkurence? Nejsou IP adresy, nejsou nové konkurenční weby .

[Käyttäjä 11133]

marek@tebook:~> host www.nic.cz
www.nic.cz has address 217.31.205.50
www.nic.cz has IPv6 address 2001:1488:0:3::2
marek@tebook:~> 

hmm?

[FOK]

Koukám, že závada byla na mém přijímači. To je tak, když se někdo spoléhá na webové nástroje. Jinde už je výsledek lepší.

name	class	type	data	time to live
nic.cz	IN	AAAA	2001:1488:0:3::2	1800s	(00:30:00)

[Conscript89]

Bohuzel, v TV to nakonec dopadlo takto:
http://www.youtube.com/watch?v=YH7ZeOUbwIQ

[H0ax]

svatá makrelo, bradu mam až na zemi

[xxx]

LOL

[linear]

Vsak Policie take pouziva IP adresy, ve sve blbosti nakonec rika pravdu

[houska]

to ano ale, stejne tak tam mohli rict ze ip adresy pouzivaji hasici/rusove/zide/arabove/severni korejci/knezi/hackeri/pedofilove/ucitele/duchodci/americani/indiani/gambleri ... mam pokracovat?

[kralyk z abclinuxu]

Měli si napsat GUI ve VB, a hned by bylo po problémech...

[the.max]

kristova noho!!!

ja to rikam jiz nekolik let. Pokud maji nase televize (a je jedno jestli verejnopravni ci soukrome) potrebu sdelit verejnosti vzdy nejakou informaci z oblasti IT, meli by to nejdrive nechat schvalit nejakemu opravdovemu IT odbornikkovi a az pak to teprve pustit. Z te reportaze bych snad i uveril, ze ja zadnou IP adresu nepouzivam, ze je pouziva jen policie.

Je fakt, ze ja vidim do IT, ale co nam treba predkladaji i ve zpravach z jinych oblasti, kdyz o IT nam tvrdi takoveto bludy??? K cemu mame RRTV? Nemela by na takoveto hlouposti dohlizet?

[Jakub Lucký]

RRTV nemá expertní tým na všechno... Pokud na něco narazíte, napište do ČT nebo RRTV slušně ohlas. Nikdo tam moc nepíše a třeba 5 dopisů k jednomu pořadu je považováno za velký divácký ohlas...

[xkucf03]

Papírových nebo e-mailů?

[Jakub Lucký]

Tohle už je trochu zpátky, ale mám za to, že to bylo obojí dohromady...

[Stan.]

Velký operátor JE dostupný přes IPv6 !

[root@server ~]# ping6 www.nic.cz -n
PING www.nic.cz(2001:1488:0:3::2) 56 data bytes
64 bytes from 2001:1488:0:3::2: icmp_seq=0 ttl=61 time=0.560 ms
64 bytes from 2001:1488:0:3::2: icmp_seq=1 ttl=61 time=0.415 ms

A záznam ipv6.nic.cz nikde v článku není uveden že vůbec existuje. To si asi pletete se Seznamem. Ten uvedl ipv6.seznam.cz a ten funguje

[root@server ~]# ping6 ipv6.seznam.cz -n
PING ipv6.seznam.cz(2a02:598:1::101) 56 data bytes
64 bytes from 2a02:598:1::101: icmp_seq=0 ttl=60 time=0.728 ms

[wasabi1]

Tu odpoved mas hodne slusnou, ze ty sedis nekde na serverovne v Praze?

[Stan.]

tak tak .. IPv6 do Nixu (gw2-v6.nix.cz) to mám přes 2 hopy :)

[Petr Maleček]

 
traceroute6 www.nic.cz
traceroute to www.nic.cz (2001:1488:0:3::2), 30 hops max, 40 byte packets
 1  router-garfield.v6.pilsfree.net (2a01:490:11:7::1)  0.433 ms  0.342 ms  0.376 ms
 2  router-nfx-1.v6.pilsfree.net (2a01:490:11:1::1)  0.571 ms  0.560 ms  0.539 ms
 3  l3sw-nfx1.v6.nfx.cz (2a01:490:0:1::1)  3.315 ms  3.237 ms  3.150 ms
 4  nix6-s.nic.cz (2001:7f8:14::e:2)  2.998 ms  2.923 ms  3.046 ms
 5  nix6-s.nic.cz (2001:7f8:14::e:2)  2.998 ms !X  3.048 ms !X  2.995 ms !X

Ej copak ten konec, něco je tady špatně :D

traceroute to ipv6.seznam.cz (2a02:598:1::101), 30 hops max, 40 byte packets
 1  router-garfield.v6.pilsfree.net (2a01:490:11:7::1)  0.392 ms  0.364 ms  0.351 ms
 2  router-nfx-1.v6.pilsfree.net (2a01:490:11:1::1)  0.524 ms  0.498 ms  0.600 ms
 3  l3sw-nfx1.v6.nfx.cz (2a01:490:0:1::1)  3.285 ms  3.277 ms  3.254 ms
 4  l3sw-nfx2.v6.nfx.cz (2a01:490:0:1::b:1)  3.224 ms  3.245 ms  3.220 ms
 5  2001:4de8:b0ba:3fd5:1::1 (2001:4de8:b0ba:3fd5:1::1)  3.801 ms  3.877 ms  3.899 ms
 6  2001:4de8:b0ba:deac::2 (2001:4de8:b0ba:deac::2)  4.506 ms !X * *

Kurnik co ty "X"ka s vykřičníkama :D

[houska]

Kurnik co ty "X"ka s vykřičníkama :D

!X  (communication  administratively prohibited)

[Petr Maleček]

Aha, díky. Já už jsem se s tím někde setkal ale nějak jsem to neřešil. Až teď mi to nějak přišlo divný. Každopádně jsem zvědav na tu odezvu večer, teď tu každej torrentí, tak jsou ty odezvy příšerný, ale kolem půlnoci by to nemuselo bejt zlý.

[zajdee]

Zkuste traceroute s parametrem -6 -I:

# traceroute -6 -I ipv6.seznam.cz
traceroute to ipv6.seznam.cz (2a02:598:1::101), 30 hops max, 80 byte packets
(...)
 6  76sit-te2-4.dialtelecom.cz (2001:4de8:d1a1:1111:d::2)  9.460 ms  6.000 ms  6.047 ms
 7  2001:4de8:d1a1:1111:20::2 (2001:4de8:d1a1:1111:20::2)  7.117 ms  7.381 ms  7.630 ms
 8  2001:4de8:b0ba:deac::2 (2001:4de8:b0ba:deac::2)  7.771 ms  5.734 ms  6.179 ms
 9  ipv6.seznam.cz (2a02:598:1::101)  6.254 ms  6.605 ms  6.709 ms

ICMP traceroute projde bez problémů, linuxový traceroute ovšem ICMP standardně nepoužívá, musíte si ho vynutit.

A ještě k poznámce v článku, že IPv6 provoz do Seznamu jde přes zahraničí - to není pravda, IPv6 provoz jde přes NIX do Dial Telecomu a z Dial Telecomu pak do Seznamu :)

[Petr Maleček]

Máte pravdu, to jsem netušil. Díky za info.

server:~# traceroute6 -I ipv6.seznam.cz
traceroute to ipv6.seznam.cz (2a02:598:1::101), 30 hops max, 40 byte packets
 1  router-garfield.v6.pilsfree.net (2a01:490:11:7::1)  0.449 ms  0.428 ms  0.413 ms
 2  router-nfx-1.v6.pilsfree.net (2a01:490:11:1::1)  0.801 ms  0.798 ms  0.787 ms
 3  l3sw-nfx1.v6.nfx.cz (2a01:490:0:1::1)  3.392 ms  3.395 ms  3.389 ms
 4  l3sw-nfx2.v6.nfx.cz (2a01:490:0:1::b:1)  3.290 ms  3.304 ms  3.308 ms
 5  2001:4de8:b0ba:3fd5:1::1 (2001:4de8:b0ba:3fd5:1::1)  3.573 ms  3.742 ms  3.743 ms
 6  2001:4de8:b0ba:deac::2 (2001:4de8:b0ba:deac::2)  3.716 ms  3.687 ms  3.693 ms
 7  ipv6.seznam.cz (2a02:598:1::101)  3.407 ms  3.377 ms  3.413 ms

[wasabi1]

Tak to já těch hupů do Prahy mám víc...

[Jiří J.]

Víte, co může taky tak trochu bránit nasazení IPv6? Nepodpora NAT v Linux kernelu. Jistí lidé pro to mají jistě dobré úmysly, bohužel v praxi by to (pozitivní) využití našlo. Abych citoval: "Not gonna happen". Problém je, že to implikuje i věci jako REDIRECT - ano, máme tu TPROXY, ale ta potřebuje speciální socket option, což u binárních aplikací znamená použití emulační vrstvy (wrapperu), která nastaví IP_TRANSPARENT. To u REDIRECT targetu není potřeba.

[H0ax]

NAT je humus v ipv4, k čemu by měl být v ipv6 dobrý?

[VSi]

Měl bych 2 příklady:

- V jedné síti řeším "vypínání přístupu k internetu" pro určité uživatele. U nich jsou všechny požadavky na port 80 mimo LAN pomoci Destination NAT (DNAT) přesměrovány na interní webserver, takže v browseru se jim zobrazí na jakýkoliv požadavek informační stránka. Jinak by to šlo řešit pomocí transparentní proxy, a to i na IPv6, ale to je o dost složitější.

- Pochopil jsem, že u IPv6 bych od providera pomocí něčeho jako DHCP měl dostat ne 1 adresu, ale celý subnet. Pak můžu použít adresy z toho subnetu pro svojí LAN. Je otázka, zda bude třeba u různých wifi sítí (v hotelu, ve škole ap.) stejná situace. Tipuju, že většinou dostanu spíš 1 IPv6 adresu zase pomocí něčeho jako DHCP. No a teď budu chtít z připojeného notebooku "sdílet internet" pro další zařízení, třeba mobilní telefon přes bluetooth, nebo pro virtualizované OS na tom notebooku. Opět to můžu řešit jen pomocí NATu nebo proxy (coč je o hodně víc omezující než ten NAT). Teoreticky můžu udělat nějaký bridge a požádat o další IPv6 adresu, ale pokud bude použita 802.1x wifi autentizace (nebo něco takového), tak mám smůlu.

Můj závěr je, že na IPv6 bude NAT stále užitečný, i když v mnohem méně případech než u IPv4.

[SAM:]

IPv6 bylo koncipováno tak, že bude jeden svět bez NATů a NAT pro IPv6 nikdy nebude. Uvědomte si, že NAT je síťové zlo. Jeho původní poslání bylo šetřit drahocenné IPv4 adresy. Až postupně se jeho použití zvrhlo k jiným účelům, zejména k domnělému pocitu, že zvyšuje bezpečnost. Neříkám to nijak dogmaticky, ale čistě prakticky. Přidělování IPv6 vypadá tak, že většinou dostanete od poskytovatele celý prefix, třeba 2^64 adres.

[linear]

To se divim ze IPv6 adresa se vubec prideluje. Jednodussi reseni by bylo ze si kazde zarizeni samo vygeneruje nahodnou adresu. Pravdepodobnost kolize je nulova.

[Heron]

Potřebuje ale znát subnet a ten musí o něčeho na síti získat -- to už je jednodušší, když mu to něco rovnou pošle celou adresu, místo náhodného zkoušení a detekování kolize.

[SAM:]

Prefix a jeho délku dostane klient od routery ve zprávě Router Advertisement, kterou se router ohlašuje do sítě a kterou odpovídá na zprávu Router Solicitation. Nic nemusí zkoušet.

[Filip Jirsák]

IP adresy nejsou jen tak nějaké zbytečné označení zařízení, ale slouží ke směrování. Což by s náhodně generovanými adresami nebylo možné. Tedy pokud byste nechtěl s každým připojením zařízení k internetu poslat oznámení celému internetu, kde se momentálně ta která IP adresa nachází, a zároveň v každém zařízení udržovat komplet routovací tabulku pro všechna zařízení momentálně připojená k internetu. Jenže na takovýhle nesmysl nemáme ani dostatečné přenosové kapacity, ani dostatečný výpočetní výkon zařízení, resp. hlavně paměť pro ty obrovské routovací tabulky – jenom v obyčejném pracovním počítači, který má typicky dvě spojení (do lokální sítě a na bránu), takže by stačil pro každou adresu mít v tabulce jeden bit, byste potřeboval routovací tabulku velkou až 2¹²⁸ bitů, to je víc jak 4 × 10³⁷ bajtů.

[linear]

samozrejme, to by znamenalo routovani podle textove (DNS) adresy. Kazde zarizeni by melo jedinecne ID (128-bit) + textovou adresu, napr. "ferda.o2.cz" ktery si vyjednam u providera. Kazdy pocitac by hledal vzdy "nadrazeny" server, v tomto pripade o2.cz. IP adresa by v tomto pripade byla jen ID proto aby se nepresela cela textova adresa. Mozna by to mohl byt hash z textove adresy.

[Filip Jirsák]

Takže IP adresa je v tom vašem schématu vlastně zbytečná, můžeme ji zahodit. Textová DNS adresa je pro počítačovou komunikaci nevhodná, můžeme ji nahradit číselnou adresou – třeba 128 bitů, to by mohlo stačit. No a ještě té „textové DNS adrese“ potřebujeme nějak jednoduše říkat – třeba IP adresa. A máme IPv6.

A teď vážně. Celý vtip routování na internetu – tedy to, aby to bylo vůbec technicky proveditelné – spočívá v tom, že si routery neuchovávají informace o routování každé adresy zvlášť, ale o celých blocích. Routovací tabulky se tím řádově zmenší (do zvládnutelných rozměrů) a mnohem rychleji se v nich vyhledává. Proto je potřeba, aby počítače, které jsou v jedné síti, měly také adresy z jednoho bloku. Takže ISP někde na druhém konci světa nemusí vůbec nic vědět o síti mého ISP a zda mám zrovna připojen počítač do jeho sítě, ale prostě má velký blok IP adres, pro které vše posílá „do Evropy“. Podrobnost směrovacích informací se pořád zpřesňuje, až můj ISP ví, kam přesně má paket pro mou IP adresu poslat.

[Heron]

Jen doplním pro lineara. IP adresa a routování v IP síti je navržené tak, aby se daly použít bitové funkce, které jsou pekelně rychlé a lze tak postavit levný a výkonný HW router. Zatímco porovnávání řetězců (a to ještě různé délky) je naopak příšerně pomalé.

[linear]

za poslednich 40 let co existuje IP protokol pocitace trochu zrychlili. Routovani textovych adres by v pohode zvladal i levny 200MHz procesor z mobilu. Sice by router byl o chlup slozitejsi (a mozna i drazsi, ale mozna ani ne) ale z pohledu end-usera by to byla parada a to vcetne administratoru.

[Piškot]

To jseš značně naivní 200Mhz ti neuroutuje desetitisíce paketu za sekundu ...při jednoduchém routování třeba do dvaceti sítí.

[Filip Jirsák]

To běžte vysvětlovat výrobcům routerů, které se používají na páteřních sítích. Zkuste si jen tak cvičně spočítat, jak velkou paměť byste k tomu potřeboval. Zkuste to třeba jenom pro IPv4 – tam můžete mít teoreticky 2³² adres, dejme tomu, že jedna textová adresa bude mít 10 bajtů, to dělá nějakých 43 gigabajtů jen pro seznam adres. To máte ve vašem mobilu?

[Heron]

Fajn, tak mi na procesoru z mobilu odroutuj gigabitovou síť na textových adresách.

680MHz MIPS uroutuje cca 500Mbit a to hovořím o IPv4 (tj. 32 bitů -- kolik by měli textové adresy? 64B tj 16x tolik?), a o funkcích vykonávaných v čase 1T. Pro textové řetězce to jsou stovky cpu cyklů (a to nehovořím o paměti a nutnosti velké cache). I kdyby jen 100T, tak jsme na 5Mbitech.

Router, který by zvládl tvůj nápad, by musel mít ekvivalentní takt 136GHz pro gigabitovou síť. To moc levné nebude (a to se ještě držím při zemi).

[linear]

IP adresa neni v tomto schematu zbytecna, je to kratsi verze adresy pro prenaseni paketu. Kazdy paket musi vedet kam jde a proto je vhodny ID pevne delky (napr. 128 bit) ktery se na zacatku komunikace spocita z textove adresy hashovaci funkci. Vlastne jsem dnes vymyslel uplne genialni nahradu pro zastaraly IPv6

[Filip Jirsák]

Paketu stačí IP adresa, ale router musí vědět, kterou cestu k té IP adrese má zvolit. A k tomu právě slouží routovací tabulky.

Ano, vymyslel jste úplně geniální náhradu, a dokud si o TCP/IP a routování nezjistíte alespoň základy, budou asi marné moje pokusy vysvětlit vám, že ta náhrada není ani tak geniální, jako úplně nepoužitelná.

[Heron]

Hashovací funkcí? A jak se budou řešit kolize? Tedy dvě různé textové adresy se spočtou do stejné hash?

[Jakub Lucký]

Se to prostě pošle oběma

[SAM:]

U bezstavové konfigurace se generuje jen druhá část IPv6 adresy. Je to MAC adresa o něco doplněná. První číst je prefix a ten je pevně daný. Takže automaticky generované IPv6 adresy routovací mechanismy neovlivňují. Navíc IPv6 se snaží implementovat tzv. Mobility. Když s vaší IPv6 adresou někam odcestujete, tak existuje cesta, jak zjistit dostupnost pod touto IP i v jiné síti.

[x]

Jo, jenze to musi podporovat vas domaci router => v 99% pripadu router vaseho ISP. Uz vidim jak to maji nakonfigurovano ....

[pavlix]

Nevím v čem vidíš problém? :)

[SAM:]

S tím automatickým generováním to tak jednoznačné není. Například virtuální stroje využívající jednu síťovku. Nikdo negarantuje, že ji fakt bude mít každý jinou. Že to tak většinou funguje je jiná věc.

[pavlix]

NAT pro IPv6 nikdy nebude.

Odvážné to tvrzení.

Navíc tady se mluvilo o redirectech, což je v podstatě jednoduché tcp proxy, které průměrný admin nastaví s pomocí inetd+netcat nebo nějaké obdoby.

[xkucf03]

S tím „malým“ rozdílem, že v případě inetd+netcat se cílová aplikace nedozvídá adresu klienta a komunikuje s localhostem (nebo prostě proxy). S tímhle jsem trochu bojoval – aplikaci nemůžu/nechci pouštět na privilegovaném portu, ale pro klienty na něm má být přístupná – v ip(4)tables jsem jednoduše přesměroval a aplikace ví, s kým mluví – v ip6tables to nejde a musím to řešit pomocí proxy na aplikační úrovni (což má zase i nějaké výhody, ale v tomhle i nevýhody).

[Heron]

No a teď budu chtít z připojeného notebooku "sdílet internet" pro další zařízení, třeba mobilní telefon přes bluetooth, nebo pro virtualizované OS na tom notebooku.

Bridge na tu síťovku a to zařízení si pak vyžádá od stejného "DHCP" další IP. To znamená, že každé tvé zařízení bude mít vlastní globální IP ve stejném subnetu.

[VSi]

Bridge je asi ideální možnost. Nevím, ale jestli by fungoval rozumně bridge WiFI<>PPP, prostě mezi linkovými vrstvami úplně jiné povahy (PPP zařízení nemá v linuxu ani MAC adresu). Další věc je, jestli by to fungovalo se zmíněnou 802.1x autentizací - teoreticky to asi není problém, ale když vidím, jaká kouzla dělá třeba Eduroam na ZČU (každý klient má linkovou vrstvu tunelovanou na nějaký Access Controller), tak nevím jestli to bude podporovaná věc.

[Jimmy]

První příklad máme v síti IPv4 nastaven pro všechny nové a tedy neznámé počítače na všech routerech a přesto NAT děláme na úplně jiných routerech. Přesměrování je totiž věc firewallu a ne NATu. Jedná se o síť kde je cca 25 000 PC a asi 350 routerů a cca 20 NAT routerů.

Druhý příklad. V hotelech i na IPv4 neřeší omezení 1LAN zásuvka - jedna IP adresa. V hotelu jakékoliv PC v interní síti přihlásí o IP adresu, tak ji dostane. Mám to vyzkoušeno u virtuálního PC v módu bridge, které opravdu dostane jinou IP než fyzické PC a internet jde na obou. Takže k připojení dalšího PC stačí v PC nastavit bridge a NAT opět už dnes není potřeba.

[VSi]

Přesměrování je totiž věc firewallu a ne NATu. Jedná se o síť kde je cca 25 000 PC a asi 350 routerů a cca 20 NAT routerů.

Vycházel jsem z prvního komentáře ve vlákně, ze kterého jsem pochopil, že absence NATu pro IPv6 v linux kernelu znamená i to, že nejde použít REDIRECT/DNAT pro přesměrování.

Druhý příklad. V hotelech i na IPv4 neřeší omezení 1LAN zásuvka - jedna IP adresa. V hotelu jakékoliv PC v interní síti přihlásí o IP adresu, tak ji dostane. Mám to vyzkoušeno u virtuálního PC v módu bridge, které opravdu dostane jinou IP než fyzické PC a internet jde na obou. Takže k připojení dalšího PC stačí v PC nastavit bridge a NAT opět už dnes není potřeba.

V "jednoduché" síti to tak asi bude. Měl jsem na mysli obecně "více zabezpečené sítě", kde jsou L2 switche nastaveny s omezeními jako 1MAC/port, 802.1x autentizace a podobně.

U virtuálního PC jde v podstatě o SW ethernet<>ethernet bridge, to odpovídá fyziskému "rozbočení" zásuvky pomocí switche. Když budu ale připojen přes ethenet do nějaké cizí hodně zabezpečené sítě, a budu mít 1 IPv6 adresu (třeba proto, že správce té sítě to tak chce), a budu mít k PC připojeno jiné zařízení přes protokol PPP nebo SLIP (prostě něco, co neemuluje ethernet), tak mám s nějakým bridgem smůlu.

Jiný příklad může být třeba smartphone s 3G připojením (PPP linkový protokol), kde dostanu 1 IPv6 adresu, protože operátor nechce, abych přes to připojoval jiná zařízení. A já budu chtít "nasdílet internet" do počítače - na IPv4 to udělám NATem.

Dobrý příklad je i to zmíněné záložní připojení (bez vlastního AS). Jak by se to mělo řešit bez nějakých složitostí typu VPN server na páteřní síti?

Vím, že NAT je "zlo" a v IPv6 nemá místo. Ale prostě mě napadají určité speciální situace, kdy by se NAT užil. Bohužel čistota návrhu musí někdy ustoupit realitě.

[Filip Jirsák]

Popsal jste vlastně jen případy,kdy správce sítě něco chce, a vy to chcete obejít. Pak je ale otázka, proč správce sítě chce něco, co lze snadno obejít, případně proč to vy chcete obcházet – a zaměřil bych se spíš na to, než řešit, jak se podrbat leovu rukou za pravým uchem.

[Jiří J.]

Popsal jste vlastně jen případy,kdy správce sítě něco chce, a vy to chcete obejít.

Protože správce sítě má na hlavě desetidolarovku, na rameni papouška a mluví italsky.

Pak je ale otázka, proč správce sítě chce něco, co lze snadno obejít,

Protože to pro něj vyjde ekonomicky výhodněji - 95% uživatelů to dělat nebude a finance vynaložené na vývoj a nasazení lepšího řešení by se nevrátily (4% z těch 5% by si našly způsob, jak nové řešení obejít).

případně proč to vy chcete obcházet

Pohodlí. Možnosti. Alias "proč ne, když by se mi to hodilo a můžu". Taky se tu může vyskytnou souvislost s první citací (tedy nemožnost domluvy s ISP).

a zaměřil bych se spíš na to, než řešit, jak se podrbat leovu rukou za pravým uchem.

Já osobně se raději podrbu levou rukou za pravým uchem a pravou rukou na levé noze, než bych měl vstát a zajít k sousedovi, aby mě podrbal jeho pravou rukou za mým pravým uchem nebo se svíjet svěděním, odstaven od možnosti pracovat.

[Filip Jirsák]

Pohodlí. Možnosti. Alias "proč ne, když by se mi to hodilo a můžu".

Jinými slovy chcete dělat blázniviny, a vadí vám, že pro to někde není dostatečná podpora. Tak si tu podporu do jádra dopište, nebo počkejte, až ji dopíše někdo jiný. Aneb klidně si používejte hrábě jako lopatu, ale nestěžujte si, že se vám to používá blbě a že by to chtělo ty hrábě upravit, aby fungovaly víc jako lopata.

[Jiří J.]

Pokud jsem správně pochopil tzv. Tethering, jde v podstatě taky o použití NATu a "schování" dalšího zařízení za smartphone.

Jistě, jsou i možnosti, jak připojit třeba notebook bez NATu, pokud by to ISP podporoval, ale dovedu si představit dva tarify "internet pro smartphone" a "internet pro smartphone a jeden laptop", kde je druhá varianta o 50% dražší. Člověk si pak rozmyslí, zda použít NAT (+ firewall) nebo ne.

[Jendа]

Jak byste řešil tu záložní konektivitu?

[Filip Jirsák]

Já jsem nepochopil, v čem je u záložní konektivity problém. Dostanu přidělen rozsah IP adres, a ty používám jako zdrojové při komunikaci přes internet. Pak se přepnu na záložní konektivitu, dostanu jiný rozsah, a ty zase používám jako zdrojové IP adresy. NAT mi v tom nijak nepomůže.

[VSi]

A když mám takhle připojenou síť se stovkami počítačů a jiných zařízení? Ta zařízení, i kdyby každé mělo přiřazené po 1 IPv6 adrese pro každou konektivitu, se namají šanci dozvědět, že mají najednou používat jako zdrojovou adresu tu druhou. Řešením jsou teoreticky a "čistě" provider-independent adresy, ale to je pro uvažovaný problém mimo.

[Filip Jirsák]

Proč by neměla šanci se to dozvědět? Router je o tom bude informovat.

[VSi]

To je nějaká standardní funkcionalita IPv6, resp. DHCP nebo co se tam používá pro autokonfiguraci? Samotné DHCP tohle tedy neumí, vnutit klientovi novou IP, když se na ni zrovna neptá. Musely by to navíc podporovat naprosto všechna zařízení v síti, které by IPv6 využívaly.

Pro mě je tedy představa, že při přepnutí na záložní konektivitu dojde k přeadresování celé LAN o stovkách nebo tisících zařízení, dost děsivá. Muselo by to být provázáno s DNS servery, musely by se v té chvíli vyprádnit všechny DNS cache. Firewally by se musely nastavit pro oba adresní rozsahy. Buď to nechápu, nebo je to prostě neskutečně složitější, než přehození NATu. I když NAT je fuj, s tím souhlasím, v 99% současného nasazení je NAT zybtečný, pokud by bylo dost IP adres.

Přijde mi, že vášniví odpůrci jakýchkoliv NATů v IPv6 vidí situaci až moc ideálně. V realitě prostě dochází k situacím, kdy čisté řešení z nějakého důvodu není proveditelné, i když by bylo lepší.

[Filip Jirsák]

Pokud vím DHCPv6 by tohle měl umět.

Pokud vám to přečíslování připadá děsivé, asi bude jednodušší mít pro takovou síť vyhrazený blok adres a řešit to na úrovni routování. Vy se na to pořád díváte jako na IPv4 s delšími adresami, IPv6 ale ve skutečnosti přidává mnoho dalších věcí – a mnoho jich je také v různých fázích rozpracovanosti, a teprve čas ukáže, co se osvědčí a co se bude skutečně používat. Ale předpokládám, že když se spolu s IPv6 řeší třeba i dostupnost mobilních zařízení, pokud jsou mimo svou domácí síť, předpokládám, že se podobným mechanismem dá řešit i vícenásobná konektivita.

[VSi]

Vyhrazený blok je možné mít už u IPv4. Pokud jde o 2 různé ISP, tak k tomu potřebuju vlastní AS (autonomní systém), součinnost obou ISP (aby mi umožnili BGP propojení), a přidělený dost velký rozsah IP adres od RIPE (to s IPv6 v podstatě odpadne). Tohle lze dělat v případě, když mám nějakou "lepší" konektivitu, tj. platím ISP aspoň pár tisíc měsíčně aby se o tom se mnou vůbec bavil. Uvažuju situaci, kdy mám 2 "obyčejné" připojení, kde toho po ISP nemůžu moc chtít. Navíc tohle řešení stejně neumožňuje rychlé přeroutování z jedné konektivity na druhou - nějakou dobu trvá propagace IP prefixů do globálních routovacích tabulek po celém světě.

O řešeních pro mobilitu se zachováním adresy u IPv6 vím. Jde ale pořád o nějaký princip VPN/tunelování/speciálního routování, i když lepší, a standardně podporovaný přímo IPv6 protokolem. Záložní připojení jde taky takhle řešit už teď, ale musím mít někde stabilní a vždy dostupý server, ke kterému budu mít navázané tunely skrz obě připojení.

Otázkou je, jak budou tyhle speciální IPv6 funkce v reálném nasazení dostupné, až se IPv6 konečně rozšíří. Podívejte se na situaci s IPv4 multicastem - pro mnoho aplikací skvělá a čistá technologie, reálně v prostředí Internetu nepoužitelné. Jde hlavně o to, které části specifikace budou u routerů "povinně podporované", a které jen volitelné.

[Filip Jirsák]

Psal jsem právě o tom, že s IPv6 by to mělo být jednodušší, tj. nebudete k tomu potřebovat „lepší“ konektivitu, ale mělo by tu fungovat na každé „rozumné“ konektivitě.

[frr]

Osobně provozuju v malé firmě zdvojenou IPv4 konektivitu do internetu s dvěma NATy. Provideři o ničem nevědí - jsou spokojení, že vědět nemusí, a já taky. FUNGUJE TO VELMI DOBŔE. Od chvíle, kdy jsem to spustil, neznáme výpadek internetu. Dokonce nemám ani automatické překlápění na zálohu - je nás ve firmě několik, kdo to umí přehodit manuálně. Stačí na to login a třípísmenný příkaz v shellu, který v podstatě jenom přehodí default route. Funguje to i v kombinaci s redundantními openVPN tunely mezi pobočkami, nad kterými se routují interní bloky pomocí iBGP...

Svého času jsem se pohyboval na druhé straně barikády - a mám velmi dobrou představu, co za administrativní opruz a technické obtíže znamená PI alokace, nebo klidně PA s alternativním routováním přes cizí AS. Rozhodně nevidím jako reálné, že bych takto řešil dvojitou konektivitu pro mého současného zaměstanavatele!!! Příchozí spojení routuju podle CONNMARKu, to by na IPv6 bez NATu mohlo zůstat. Pro odchozí spojení je naprosto ideální, pokud mohu mít v interní síti privátní adresy a ven lézt přes dva NATy. Dokonce i servery v DMZ mají jako default privátní subnet a jejich odchozí spojení lezou skrz NAT.

V porovnání s viditelností mé malé firmy v globálním BGP, a v porovnání s přečíslováním interní sítě při přepnutí na zálohu, dvojitý NAT považuji za duševně zdravější řešení. Když si vezmu, že by mi při přepnutí na zálohu všecky servery ve vnitřní síti změnily IP adresu... brr.

Tak mě napadá... co třeba mít na mašinách ve vnitřní síti na všech trvale dvě rovnocenné IP adresy? Pokud by to DHCPv6 nebo "přirozený IPv6 autoconfig" uměly přidělovat, tak proč ne... mohl bych zase měnit jenom default route, tentokrát ale na všech mašinách v interní síti. To zní duševně o něco zdravěji, než přečíslovat. Předpokladem je, že by TCP/IPv6 stacky počítačů musely spolehlivě přidělovat lokální adresu odchozích spojení "podle default routu" - maličko ve mě hlodá pochybnost, nakolik je toto transparentní, zda si to nemůže aplikace sama určit při otvírání klientského socketu. Ve výsledku by komunikace v rámci interní (privátní) sítě mohla běhat dál bez přerušení, spojení by se nerozpadla, servery by měly pořád stejné adresy, jenom po přehození na zálohu by se klienti začli připojovat i na lokální servery "z druhého subnetu" (v tuto chvíli je přehození na zálohu pro interní provoz neviditelné, pokud se nezeptáte Quaggy kudy routuje).

Jak se na to tváří RIPE? Je ochoten přidělovat jedné koncové firmě dva bloky IPv6? Vlastně proč ne - na IPv4 se taky běžně dává blok na každou konektivitu / regionální pobočku, pokud si to umíte obhájit (= pokud to má opodstatnění). Osobně bych se klidně obešel i s mnohem menším přídělem než /64 I takových /112 by bylo na celou firmu (těch pár poboček dohromady) až až. Kolik mi dá můj WISP na domácí síťku? Dostanu jednu IPv6 adresu a půjdu na párek?

Zaujala mě Yenyova poznámka ohledně "protokolově neutrálních" filtrů pod Linuxem. Je fakt, že už teď mám IPtables postavené pokud možno především podle rozhraní a TCP portů, podle IP adres pouze v minimální nutné míře. Navíc mám konkrétní jména rozhraní a IP adresy substituované z externího konfiguráku přes shellové environment proměnné. Nicméně si myslím, že tohle mi na "protokolově neutrální iptables" stačit nebude. Když bude logika IPv6 tolik jiná než logika IPv4, budou nutně vypadat jinak celé skripty (resp. celá konkstrukce řetězců IPtables pravidel). Takže prostě budu mít dvě sady pravidel - jednu pro IPv4, druhou pro IPv6...

[frr]

Tahle "redundance pomocí dvou veřejných bloků adres" (i na IPv4) kulhá v jedné věci: jste v internetu zvenčí vidět jako dvě různé / nesouvisející sítě. Takže když klekne primární konektivita, pro mnoho služeb není na první pohled patrné, že jsou servery dostupné ještě na sekundární adrese. Moji interní uživatelé jsou ještě schopni se naučit, že mají na výběr dva různé přístupové body pro RDP a pro VPN (opakování je matka moudrosti). Pokud v době výpadku zavolá nějaký zákazník telefonicky, dá se mu říct alternativní jméno webu po telefonu. Jediná služba, která jede opravdu furt, je SMTP e-mail - a tam ještě některé cizí servery pindají, že mi nesedí EHLO proti DNS reverzi (na serveru běží jediná instance Postfixu).

Jedna věc, po které dlouhodobě toužím, je zobecnění logiky MX záznamů z pouhého SMTP na ostatní služby. Aby se dalo říct, že službu WWW lze získat na několika konkrétních IP adresách, odstupňovaných podle priority - a aby to tak klientské aplikace chápaly (jako vzájemnou redundanci). V tuhle chvíli jistě je možné dát do DNS víc A záznamů z téhož jména na různé IP adresy, ale aplikace to jako redundanci nechápou - prostě si vyberou jednu adresu a na tu se tvrdošíjně snaží dostat. Výrobci content switchů by možná přišli o část zisku.

[xkucf03]

odstupňovaných podle priority - a aby to tak klientské aplikace chápaly (jako vzájemnou redundanci). V tuhle chvíli jistě je možné dát do DNS víc A záznamů z téhož jména na různé IP adresy, ale aplikace to jako redundanci nechápou

+1, to určení priorit mi tam taky chybí. V současnosti jde ty DNS záznamy použít leda tak k rozložení zátěže.

[petr_p]

SRV. I A je možné chápat jako zálohu (a rozumné programy zkouší všechny adresy). Ale tak jako tak to je problém aplikace a obávám se, že v zájmu zpětné kompatibility nikdy nevznikne RFC, které by něco takového nařizovalo.

[Filip Jirsák]

Myslím, že jste si sám odpověděl. NAT je určitým řešením „problému“ dvou konektivit – ale zároveň to neřeší hned tu druhou nejpodstatnější nevýhodu, totiž že s výpadkem konektivity se síť stává z venku nedostupná do té doby, než se změní údaje v DNS a staré údaje se zneplatní v cache. To, co tady celou dobu píšou odpůrci NATu na IPv6 je následující – ano, můžeme to nad IPv6 dělat stejně „hloupě“ jako nad IPv4, to „řešení“ bude mít i stejné neduhy. Teď tady ale máme nové IPv6, které má jiné možnosti. Takže se pojďme podívat na to, zda by se to dalo s IPv6 vyřešit jinak a lépe.

K tomu zobecnění logiky záznamů – takhle pokud vím fungují SRV záznamy, které navíc přidávají informaci o portu (to je další důležitá věc, která u „běžných“ DNS záznamů chybí).

[frr]

Díky oběma za pointer na SRV - je vidět, že se nad tím kdosi zamyslel dávno přede mnou To je odpověď na spoustu mých otázek.

[houska]

nevim jak moc je slozite ho ziskat, ale tohle by melo byt mozne resit pres ziskani vlastniho ASka ne?

[frr]

Pokud bych se já osobně pro firmu o 20 lidech s vlastním webserverem, dvěma mailservery a nějakým interním IT snažil zařizovat subjektivitu v globálním routingu, připadal bych si nutně jako nedouk/vychcánek/přizdisráč/managor. V tomhle patře routování se posledních 15 let bojuje s ustavičným bobtnáním routovacích tabulí, trafficem "změn topologie" apod. - prostě se stabilitou / konvergencí té obrovské dynamické sítě. "Pořiďte si vlastní ASko" je asi taková odpověď, jako když člověku, který na nádraží zvažuje dvě varianty vlakového spojení, poradíte "kupte si vrtulník". To přirovnání pochopitelně kulhá - v oblasti IP routingu se malé kličkující vrtulníky v mezinárodním vzdušném prostoru už mnoho let běžně sestřelují - pro jistotu, aby nezacláněly v cestě velkým dopravním strojům a nehltily řízení letového provozu. Osobně si radši koupím dvě jízdenky na vlak a nakonec tam nějak dojedu, třeba se rozhodnu až cestou, která varianta trasy se vyvrbila jako sjízdnější...

BTW, ještě pořád platí, že "AS number" je 16bitové číslo? Pokud se správně pamatuju, ASka docházely už někdy v roce 2003...

[Käyttäjä 11133]

AS je 32 bitů teďka.

[frr]

Takže byla nová revize BGP? Aha, RFC 4893 a 5668...

Nicméně to řeší jenom problém s tím identifikátorem - nijak to nepomůže řešit konvergenci neustále rostoucí/houstnoucí globální sítě (možná spíš naopak)

[x]

Tohle je spis chyba organizace site jako takovy. Pokud totiz nekdo resi zalohovani konetivity, tak to stejne v 99% pripadu resi lokalne (= nepronajima si optiku na druhej konec zemekoule). Tudiz by bohate stacilo vice peer uzlu, a ven by se nic propagovat nemuselo.

[xkucf03]

Kolik mi dá můj WISP na domácí síťku?

Dobrá otázka. Pokud by každý dostal „spoustu IPv6 adres“, tak bychom za chvíli dopadli jako s IPv4, kvůli neuvěřitelnému plýtvání by těch IPv6 najednou nebylo tak nekonečně mnoho, jako se to zdá teď. Na druhou stranu jedna IPv6 adresa je málo i pro běžnou domácnost – stolní počítač, několik notebooků, VoIP telefon, PDA/chytrotelefon… Takže by asi bylo potřeba vymyslet nějaký systém přidělování – IPv6 adres bys mohl dostat, kolik bys chtěl, ale musel by sis o ně říct – ne že je každá přípojka dostane automaticky a pak budou nevyužité.

[Dan Ohnesorg]

Jednak jich je blizko k tomu nekonecne mnoho a jednak tohle jsou veci, ktere uz jsou dohodnute a v podstate se ceka na nekoho, kdo to natlaci k lidem.

Zhruba je to tak, ze kazdy zakaznik dostane na svuj "modem" pres IPv6 delegaci prefixu delky /64 nebo /48, podle toho jestli se bude jednat o zakaznika obycejneho nebo kvalifikovaneho (treba takoveho co ma dneska vice nez jednu IP adresu).

[frr]

Když to tak počítám, ono nebude hned tak zle. Lidí je něco pod 10 mld. Kdyby měl každej na hlavu příděl /64 doma a druhej /64 v práci (což mít nebude), tak by to bylo 20 mld přídělů = 2x 10^10. Pokud nezohledním různé special-purpose prefixy, tak /64 přídělů je k dispozici řádově 10^19. Tam ještě pár nul na plejtvání zbejvá Přitom třeba mě osobně by doma stačila /120 i pokud bych nechal vnitřní WiFi bez zabezpečení a pučoval adresy na potkání každýmu kdo jde kolem...

Spíš mi šlo o to, jestli se s tím bude někdo ručně správcovat/routovat, káždému zákazníkovi extra subnet, když dřív stačilo pustit zákošům vzduchem DHCP, jeden subnet přes celé sídliště, a případný login vyžadovat webovým ksichtem někde kus dál...

[frr]

Hmm... dostanu /64 i na mobil přes GPRS?

[Dan Ohnesorg]

Ty /64 subnety prideluje DHCPv6, takze je to uplne stejne o pusteni DHCP pres cele sidliste jako u IPv4.

Mobil pres GPRS podle me presne spada do kolonky zarucene jedno koncove zarizeni a tak podle RFC dostane /128. Ale jak se k tomu postavi operatori se uvidi casem, nejdrive zrejme v cine, kde uz nemaji moc na vyber a IPv6 v mobilnich sitich nasazuji. Coz paralelne vede k tomu, ze ZTE a Huawei budou mit brzo odladenejsi IPv6 stack nez Nokie a Cisco.

[frr]

Líznout celý subnet přes DHCP? To je maso

Proč se ptám na mobily: v průmyslovém nasazení vidím dost často malé routery s GPRS uplinkem. Za routerem uvnitř je pochopitelně privátní subnet. Což na IPv6 znamená, že by tam musel být nějaký příděl.

Zkusím uvažovat o kus dál: GPRS PDP kontext je vlastně point-to-point spoj mezi MT (resp. koncovým počítačem) a GGSN. Pokud pomineme úchylné detaily vespod, jako je transparentní relay na GTP a LLC, tak se to chová jako PPP dial-in z mobilního počítače do GGSN. Pokud si v roli GGSN představím Cisco router (svého času šlo údajně použít např. Cisco 7200 series), tak mi to tam vyplave jako PPP interface/template, která jde připojit na Radius. A přes Radius můžu per-user nastavit spoustu věcí - pokud se nepletu, můžu do té nově navázané relace i poslat statický route, který zároveň na GGSN vyplave v OSPF.

Ostatně pokud přidělování subnetů funguje přes DHCPv6, tak by to asi šlo i tudy - DHCP relay byl odjakživa základním způsobem, jak si z tepla své kanceláře přidělovat svá privátní IPčka do privátní GPRS APN.

Když o tom tak přemejšlím, pokud bych dostal na GPRS modem jenom jednu IPv6 adresu, tak bych z toho routeru pořád mohl otevřít "4-over-6" VPN tunel někam "domů". Což je beztak topologie, která je čím dál populárnější i na holém IPv4. A stejně ty průmyslové automaty nebudou hned všechny umět IPv6, když v dnešní době horko těžko zvládají IPv4.

A taky mě hned napadá zádrhel: i pokud GPRS modem nemá vlastní IP stack, tak to PPPčko pořád vyrábí modem (proti připojenému počítači). Takže pro připojení k IPv6 bude potřeba upgrade GPRS modemu, aby uměl nabídnout IPv6CP. V lepším případě to půjde upgradem firmwaru. Ale když si vzpomenu na několik historických předělů, kdy se starý hardware (modemy) přes noc po tichu přestal dodávat, a nové firmwary do starého hardwaru se zároveň přestaly dělat, začínám tušit zradu... No vzhledem k tomu, že Wavecom (Sierra) má několik velkých odběratelů právě v Asii, nemusel by tentokrát být až tak pozadu.

Huawei? Viděl jsem jednou nějakou malou plastovou oblou růžovou krabičku, která měla tohle logo a fungovat se jí moc nechtělo. Brr...

[petr_p]

Ve Slovinsku už dva mobilní operátoři nabízejí IPv6. Mobitel na APN rozdává adresy z 56bitového prefixu, takže předpokládám, že na zařízení deleguje více jak jednu adresu.

[Ondrej 'SanTiago' Zajicek]

a mám velmi dobrou představu, co za administrativní opruz a technické obtíže znamená PI alokace,

Administrativni mozna, technicky je to uplne normalni poskytovani tranzitni konektivity - neni rozdil, zda se jedna o klienta s PI adresama nebo o LIRa s vlastnima PA adresama.

[x]

Na IPv6 min nez /64 pridelit nelze, viz generovani IP adresy. Pokud chcete svuj rozsah ktery budete routovat, prideluje se normalne /48. IMo se moc nepocita s rofrcavanim siti na male routovane pidisite, ale spis s tim, ze v jednom subnetu budou stovky stroju.

[Filip Jirsák]

Na IPv6 min nez /64 pridelit nelze, viz generovani IP adresy.

Myslíte vytvoření Ip adresy na základě MAC adresy? To je jen jeden z mnoha způsobů přidělení IP adresy, nevidím důvod, proč by měl omezovat velikost přidělovaných bloků.

[Ondrej 'SanTiago' Zajicek]

Je pravda, ze tohle je jen jeden z mnoha zpusobu prideleni IP adresy a neni to tedy primarni duvod, proc min nez /64 pridelit nelze, v kazdem pripade ale RFC 4291 rika, ze sitovy prefix je vzdy /64.

[petr_p]

Jestli myslíte 2.5.4. Global Unicast Addresses, tak to tam sice takto napsané je, ale psali to lidi z Cisca. Oni mají vždy takové divné představy o tom, jak by měl Internet fungovat. Třeba toto RFC. Zajímavé je, že se v něm vyskytuje i slovo point-to-point. Asi už neschopnost udržet myšlenku.

[Ondrej 'SanTiago' Zajicek]

Spis 2.5.1. :

For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format.

[frr]

V tomto bodě s Vámi musím souhlasit. Nemám čas studovat jednotlivá RFCčka, ale i Satrapova bible toto tvrdí dostatečně jasně. Jedině pokud je naprosto jisté, že se přiděluje adresa koncovému počítači, má se přidělit /128. Pokud se přiděluje adresa obecně síti, kde je jisté, že se bude jednat o právě 1 subnet, přiděluje se /64. Čili tohle bych čekal od kabelovek/wifinářů pro domácí použití (ach jo, budu muset bridgnout wifinu a metaliku). Pro firmy všech velikostí, kde bude potřeba víc než 1 subnet, se přiděluje /48. LIR dostává standardně /32, maximální nenažranci můžou dostat i víc.

Čili prakticky, pokud chci DMZ oddělenou od vnitřní sítě, neudělám to na levné službě za pár korun - budu si muset pořídit "podnikovou" službu, abych dostal /48. Proč ne - tu potřebuju i kvůli slušné kapacitě směrem ven (pro servery). V podstatě se nic nemění.

Když si vezmu, jak mám postavenou síť na IPv4, a zapomenu na dvojitý NATovaný uplink na centrále, tak mám pár poboček s konektivitami od různých providerů, na některých z nich mám DMZ, mezi nimi VPNku (point-to-point tunely). Čili dostanu zřejmě 1 či více přídělů /48 plus možná nějaké /64. Rozumím tomu správně, že každému point-to-point tunelu budu muset dávat /64? Kudla v kapse se mi otvírá, radši bych to udělal unnumbered... Ale fakt je, že jestli na těch pár spojů dostanu /48, tak si klidně můžu číslovat tunely /64.

Pak mi vrtalo hlavou, jestli vlastně má smysl provozovat dál tunelovou VPNku - co mi vlastně přináší? Přináší mi autentikaci uživatelů, kteří se přihlašují odevšud možně (nemůžu filtrovat podle veřejných IPček), plus nějakou enkrypci jejich provozu - a nad tím si můžu provozovat jakoukoli službu, která nativně tyhle dvě vlastnosti nevykazuje (třeba Telnet). Tady mě napadlo, natahat si přes IPv6 OpenVPN, venkovní adresy použít IPv6, ale uvnitř tunelů používat spokojeně dál IPv4. No to si ještě rozmyslím. A nechoďte na mně s nativním IPsecem v IPv6 - na IPv4 se orosím pokaždé, když IPsec někde potkám, a nemám důvod se domnívat, že to na IPv6 bude lepší (vrozené vady + kompatibilita mezi implementacemi a verzemi). OpenVPN je ZLATÁ.

[xkucf03]

Což se moc nehodí pro domácí ADSL modemisty – leda, že by ten modem fungoval jako bridge a IP adresy by přiděloval centrální DHCP server poskytovatele. Pak je ještě otázka, jak by se to účtovalo – jestli podle přenosů, nebo připojených zařízení… aby někdo na jednu linku nepřipojil celý panelák. Dneska mají ISP většinou v podmínkách, že tu konektivitu nebudeš přeprodávat dál – a pak ti „velkoryse“ mohou nabídnout neomezené přenosy.

[frr]

Ohledně trvalého přidělení dvou IP adres všem koncovým mašinám: koukám do konfigurace ISC DHCPd 4.1. a novějších a konkrétně option limit-addrs-per-ia vypadá docela slibně (přidělování stavovým DHCPv6). Pak mě ještě čistě teoreticky "od stolu" napadá, nakonfigurovat na routeru bezstavovou konfiguraci pro dva subnety na jediném L2 rozhraní, a přidat k tomu jediný default route - ať už skrz "router advertisement" nebo skrz bezstavovou variantu DHCPv6. Ale tuto druhou možnost jsem nijak nezkoumal z hlediska konfigurací, dost možná je to halucinace.

[x]

Ehm, pokud mate stovky pocitacu za NATem, tak jste trouba. Zalohovani konektivity je v takovem pripade resitelne jedinym rozumnym zpusobem a to preroutovanim adres, coz prave s NATem udelat nelze, kdezto bez nej s verejnym rozsahem to lze velmi snadno, aniz by koncova zarizeni vubec nejaky vypadek zaznamenala.

[VSi]

Sorry, ale ty PC fakt ne vždy potřebují veřejné IPv4, a poskytovatel mi nějaké 2 C subnety nedá. Nebo by to nebylo za ty peníze co teď. A kdyby ano, stejně nějaká domluva na "přeroutování" nehrozí.

Kterýkoliv větší ISP nám rád udělá failover řešení včetně přeroutování, třeba okruh na optice + SHDSL backup. Bude to ale tak 20× dražší, než současné řešení s dvěma "komoditními" konektivitami.

Je třeba si uvědomit, že ceny "obyčejného" připojení jsou na současné úrovni jen proto, že se z toho stala služba pro masy. V tom případě ale po ISP nemůžete chtít nic moc navíc.

K tomu zálohování už tu diskuse proběhla. Pokud to chci řešit "správně" přeroutováním, tak buď musí jít o stejného ISP, nebo je potřeba značná spolupráce obou ISP, nebo potřebuji nějaký tunelovací server na stabilní konektivitě. Pokud v té síti nejsou nějaké zvenku dostupné služby, pak 2×NAT je v současnosti podle mě rozumné řešení.

Ptám, jestli IPv6 reálně nabízí lepší řešení tohoto problému. Prosím nepište, že na to existuje X specifikací nebo RFC. Důležitá je reálná použitelnost v kontextu konfigurace sítí ISP bez potřeby nějakého speciálního domlouvání.

[Filip Jirsák]

Sorry, ale ty PC fakt ne vždy potřebují veřejné IPv4

Tahle věta v normálním světě nedává smysl. Je to jenom výmluva pro případ, že už došly IPv4 adresy. Srovnejte to třeba s větou „autem lze dojet i na prázdné pneumatice“, která je sice také pravdivá, ale nezpůsobuje, že velká část aut jezdí na prázdných pneumatikách, nezvniká celý průmysl kolem toho, jak lépe jezdit na prázdných pneumatikách, neprodávají se auta s prázdnými pneumatikami s tím, že to tak stačí, a s příchodem nové generace aut se nenajde spousta těch, kteří si stěžují, že ta nová auta mají neprorazitelné pneumatiky a že tak přicházíme o úžasnou možnost jezdit na prázdných pneumatikách.

[xkucf03]

+1

BTW: přirovnání počítačů k autům je vděčné téma

[x]

Chapes blbe. Na IPv6 funguje bud klasicky DHCP nebo automaticky generovani adresy (muze se pocitat furt stejna z MAC nebo pokazdy jina nahodne). Komp si jen poslechne prefix(y). Pokud budes chtit prefix pro sebe, nejspis si o nej proste reknes a dostanes ho = potrebujes aspon jednu statickou IPv6, na kterou se naroutuje.

[VSi]

Není to vždy tak jednoduché, protože sítě nejsou na linkové úrovni jenom Ethernet. Třeba GPRS/3G, ale i ADSL (možná ne vždy) používá linkový protokol PPP, tam žádnou MAC nemáte a autokonfigurace probíhá jinak.

Komp si jen poslechne prefix(y). Pokud budes chtit prefix pro sebe, nejspis si o nej proste reknes a dostanes ho

Budou takto nastavené "povinně" (podle specifikace IPv6) všechny sítě? Jak to bude fungovat přesně?

Příklad: mám doma ADSL modem, ten si řekne o /nn IPv6 rozsah pro LAN (ten je dále nedělitelný). V LAN budu mít připojený počítač, který z toho /nn rozsahu dostane jednu IPv6 adresu. A k němu bude připojené "něco dalšího", a ještě třeba přes PPP, takže bridge nejde dost dobře udělat. A ten PC vezme další prefix pro to "neco dalšího" odkud? Jde o různé dočasné situace, které se teď řeší NATem. (Není to plnohodnotné řešení, spíš pro speciální situace, ale má určité výhody, které tu někteří nevím proč ignorují).

[petr_p]

Řetězení NATu je administrativně jednoduché. Na druhou stranu Internet je o 3. vrstvě a na ní si jiný než symetrický NAT neuděláte (respektive bude fungovat jen jeden směr).

K vašemu příkladu: nedělitelný rozsah nedostanente, právě proto že je nedělitelný.

Pokud si ve své síti vypnete bezstavovou konfiguraci, můžte prefixy delegovat (ať už automaticky přes DHCP nebo ručně).

Pokud připustíme situaci, že máte nedělitelný prefix, ještě stále zbývá NBD proxy. Protože v IPv6 máte vždy linkové adresy (i na point-to-point), lze takto propojit sítě i které nemají stejnou linkovou vrstvu.

[Ondrej 'SanTiago' Zajicek]

Na preadresovani pri zmene providera. Pokud stredne velka firma s rozsahlou a komplikovanou siti meni providera, tak precislovani (i kdyz jde jen o servery a routery) muze byt dost narocna cinnost, ze ji nepujde udelat naraz pri prepojeni, tak je dobre, aby ve vnitrni siti bylo mozne chvili mixovat adresy a premigrovat sit na nove adresy postupne.

Druha moznost je pro pseudo-multihoming (zalozni konektivita bez vlastnich adresovych rozsahu) - pri vypadku primarni linky se prepne na sekundarni a tam bude NAT, aby fungovaly adresy pouzite ve vnitrni siti.

[Jiří J.]

Tak mi přijde, že si tu někteří přečetli první dvě věty z mého postu a hned se pustili do flamewar za zničení toho hnusného NATu.

Pochopitelně NAT na straně ISP je na IPv6 hnus (je to hnus i na IPv4), každý by měl dostat /48 nebo alespoň /64, nicméně i přesto by měl NAT zůstat kvůli flexibilitě pro koncové uživatele, tzn. ne kvůli úspoře adres, ale kvůli řešení specifických problémů.

Alternativně je možné použít userspace implementaci něčeho jako "transparentní SOCKS proxy", ale uvítal bych podobnou vlastnost i v kernelu.

[Limoto]

NAT není řešení problémů!

[Jiří J.]

Vážně? Přijel jsem s kamarádem do Brna - Žabětína asi půl roku zpátky, plánovali jsme tam zůstat na víkend u známých a poté pokračovat směrem na Plzeň. Zmíněný "známý" má internetové připojení od (teď si nevzpomenu na jméno) providera X, u kterého má "registrovanou" svoji MAC adresu a musí kontaktovat providera při každé změně MAC adresy (což je v pátek v noci a vůbec o víkendu docela obtížné). Já i můj kamarád jsme se (ze svých notebooků) ale chtěli dostat na internet, který byl řešen propojením kabelu od ISP s 5port ethernet switchem Edimax u stolního počítače (ke kterému si "známý" připojoval občas také notebook s MAC registrovanou u providera). Řešení bylo tedy jednoduché - zapojit můj notebook s Linuxem do switche, zfalšovat MAC notebooku známého a přes NAT pod jednou IP/MAC (v rámci jiného subnetu, ale přes stejný switch) "nasdílet připojení" pro kamaráda (winXP/7).

Ano, NAT tedy vyřešil můj problém! Což vyvrací tvrzení, že "není řešení problémů". Šlo by to řešit pěkněji, šlo by mít inteligentního providera, šlo by dalších milion věcí (třeba oficiální opensource ovladače ati/nvidia), které by návrháři "no NAT" IPv6 navrhnuli, to ale nic nemění na faktu, že pokud výrobci implementují IP/MAC modely i u IPv6 krabiček, někteří ISP je budou používat a v takovém případě je filosofie o bezNATovosti IPv6 pěknou pohádkou.

Nevěřím, že se Linux kernel IPv6 NATu vyhne, pokud se dostane do "krabiček" ve formě vlastní implementace / jiného firmwaru, který to umí (BSD?) a pokud ano, pravděpodobně se najde někdo, kdo napíše userspace (třeba libpcap + interakce s conntrack) implementaci pro výjimečné a dočasné případy, kdy se NAT opravdu hodí.

... tedy pokud to už nějaká zmiňovaná proxy neumí.

Takže prosím, než začnete (mířím hromadně, nejen na jeden příspěvek) vyprávět o hnusnosti NATu, o tom, že to není řešení problémů, chytat se za hlavu, že jej někdo považuje za bezpečnostní řešení, filosofovat o ideálním fungování internetu (fungoval původní koncept komunismu?), zkuste popřemýšlet nad realitou. Raději použiji NAT a připojím sebe + pár kamarádů v hotelu, než bych se rozplýval nad nepotřebou NAT a učil ostatní, jak změnit MAC adresu v jejích OS, který neznám tak dobře + řešil možné kolize source portů a anomálie switche/bridge, který by měl na 4 portech hlášenou stejnou MAC. Ten časový rozdíl je 1-2 minuty versus asi půl hodina (UAC win7 je fakt labůžo).

Navíc se nemusí jednat jen o "MAC filter" na straně ISP, vizte zmíněný příklad s PPP připojením, někde se dokonce používá ještě 56k modem.

Ještě jednou opakuji, že jsem silně proti jakémukoli nucenému NATu ze strany ISP nebo jeho ISP, stejně tak jsem proti omezování technologie jen kvůli teoretickému modelu.

[Heron]

Hezké, takže jsi vlastně vyřešil problém, který by neměl ani existovat. Místo jednoduchého: FUCK OFF! tomuto "ISP", si libuješ, jak jsi to krásně vyřešil. Gratuluji.

Přitom by stačilo, kdyby ten kamarád měl skutečného poskytovatele (případně tlačil na současného), céčkový v4 nebo /64 v6 subnet a vy byste se pohodlně připojili do switche.

Ano vím, že jsi psal ať ti předchozí dva řádky nikdo nepíše. Naopak, psát je je potřeba. Pokud by každý (nebo alespoň dostatečně velký počet lidí), tlačil na své poskytovatele, nemohli by se na síti chovat jako prasata. "Vyřešit" to natem není úspěch, je to prohra. Já svého ISP požádal u subnet, dostal jsem jej. Když ke mě přijdeš na návštěvu, nebudeme řešit MAC ani NAT, prostě od DHCP dostaneš veřejnou. Ostatní na stejné síti (také mohou požádat) to řeší hororovými pravidly v iptables. I díky těmto lidem se brodíme v marasmu natV4 a to i na serverech. Ale co, už jsem to psal.

[default]

Jenže realita je drobátko jiná.

Já bych chtěl třebas mít na svém laptopu jednu jedinou IP adresu ať se připojuji odkudkoli. Když mají být IP adresy všechny veřejné, pak chci mít ve všech sítích jednu!

Jde toto zařídit?

[Filip Jirsák]

Ano, IPv6 na tohle pamatuje a poskytuje pro to podporu.

[default]

Jenže, jak se dočteme tady, teoretické poskytování nestačí.

Takže když budu chtít mít stejnou veřejnou IP adresu za stálého počasí, i nadále budu muset používat workaroundy ve formě VPN či mobilního připojení s pevnou IP adresou s šukáním s routovací tabulkou.

Je to fakt výhra. Jen co je pravda.

Ale fandím tomu. Rád se směju bordelu, který je okolo mě.

[Filip Jirsák]

Vzhledem k tomu, že teprve samotné IPv6 právě přechází ze stadia teorie do pomalého nasazování v praxi, asi těžko očekávat, že hned budou fungovat všechny technologie s tím spojené. Každopádně je dobré, že je snaha s IPv6 řešit spoustu věcí, na které se teď používají různé obezličky. A připadá mi lepší snažit se vyřešit to rovnou pořádně, když je k tomu příležitost, než vylepšovat ty obezličky.

[default]

Aha! Takže když se přechází z funkčního modelu na nedodělek, tak si mam jako rozmrdat funkční infrastrukturu?

Dobrá. Stačí mi jedno zařízení připojené do internetu, takže nějaký NAT mě netrápí. VPN a původní "obezličky" mi budou taky fungovat. Ale mi jde spíš o princip. Nová verze by měla nabízet víc nebo alespoň to samé. Nikoli původní funkcionalitu bez náhrady očesat.

[Filip Jirsák]

To je otátzka, čemu kdo říká funkční infrastruktura. Já třeba takovou infrastrukturu sítě, která při výpadku jedné konektivity k internetu přestane být z internetu normálními prostředky dostupná, považuju za mnohem méně funknčí, než takovou infrastrukturu, která při výpadku jedné konektivity dokáže přejít na záložní konektivitu, aniž by to někdo poznal. Vy to rozlišení zřejmě máte opačně.

[default]

Kdybyste sem radši místo filozofie pejstnul konfigurák, abychom i my jednodušší jedinci viděli, jak se to dělá.

[Filip Jirsák]

Třeba IP adresami nezávislými na ISP. IPv6 má spoustu adres, takže je tam mnohem větší prostor pro to přidělit jedné firmě třeba tři rozsahy – po jednom u každého ISP a pak jeden nezávislý. Routovat se to nemusí nijak šíleně, mohou se třeba provideři na půdě NIXu dohodnout, takovéhle bloky alokovat společně a dohodnout se, že v případě výpadku primární konektivity zákazníka budou tu záložní routovat v NIXu.

[VSi]

Tohle jde udělat už dnes s IPv4, kde je ovšem problém s volnými IP adresami. Tím, že u IPv6 je adres dost, ale nemizí všechny problémy tohoto řešení.

Jak už to jeden pán pěkně napsal, tak pro firmu o 20 lidech je tohle v realitě trhu ISP nesmyslná věc. Takové řešení vždy bude vyžadovat konfiguraci na straně obou ISP, a to pro každého zákazníka zvlášť. U připojení za pár stovek měsíčně se o tom s nikým nebudou bavit. Jednal jsi někdy s větším ISP o něčem podobném? Technicky to může být triviální, ale u firem jako O2 to je "administrativní" problém, různí malí poskytovatelé zas často nemají takové znalosti nebo možnosti (nejsou přímo v NIXu, museli by to dojednávat přes X dalších lidí).

Rád bych se samozřejmě dožil okamžiku, kdy by tohle fungovalo nějak "samo", resp. by to byla samozřejmá součást i levného připojení. Myslím, že to ale jen tak nebude. I kdyby nakrásně existovalo technické řešení, nebude to masová záležistost, a poskytovatelé si za tyhle "speciality" rádi nechají zaplatit.

[Filip Jirsák]

S IPv6 to jde snáz, protože je dost IP adres. takže je šnace, že se to bude víc používat, ISP si pro to vytvoří standardní postupy a klidně to udělají pro firmu o 20 lidech, protože to bude znamenat jedno kliknutí myší.

Navíc se tady bavíme o problému „firma o 20 lidech má dvě konektivity, a potřebuje, aby se v případě výpadku primátní konektivity zaměstnanci dostali na web“. NAT ale není jediné řešení – ta firma stejně nejspíš má proxy server, takže stačí změnit routování na tom serveru.

[Ondrej 'SanTiago' Zajicek]

S IPv6 to jde snáz, protože je dost IP adres.

S IPv4 a IPv6 to jde uplne stejne snadno - podas zadost splnujici pozadavky a dostanes adresy.

Pridelovani PI adres se omezuje nikoliv kvuli nedostatku adres (tam je celkem jedno, zda jde o PI nebo PA adresy), ale kvuli omezovani rustu globalnich routovacich tabulek, takze tezko to bude bezna praxe u firem o 20 lidech.

Napr. v soucasne dobe chce RIPE stejny rocni poplatek za PI prefix bez ohledu na to, zda jde o IPv4 nebo IPv6 adresy.

[Filip Jirsák]

Já jsem ale také nepsal o PI adresách, to je pro síť s dvaceti počítači opravdu trochu moc. Mohou to být pořád PA adresy, které ale ISP v případě výpadku poslední míle přeroutuje přes záložní konektivitu. Sice se to dá dělat i s jednou sadou IP adres, ale není to moc čisté. Každopádně metody řešení takového problému jsou různé, a NAT je ta nejhorší z nich. Sice se teď NAT používá jako univerzální lék na jakékoli problémy se síťovou infrastrukturou, to ale ještě neznamená, že je to tak správně a že se v tom má pokračovat.

[Ondrej 'SanTiago' Zajicek]

Mohou to být pořád PA adresy, které ale ISP v případě výpadku poslední míle přeroutuje přes záložní konektivitu

Huh? Bavime se o pripade, kdy organizace chce mit z duvodu spolehlivosti konektivitu pres vic nezavislych ISP a v pripade vypadku primarni prepnout na zalozni. To lze resit v podstate dvema zpusoby:

- pres BGP a PI adresy (nebo rovnou byt LIRem), coz je kanon na vrabce

- mit od kazdeho ISP jeden PA sitovy prefix (od kazdeho jiny). Pak je ale otazka, ktere adresy pouzivat ve vnitrni site. Tam me napadaji tyto moznosti:

1) pouzit primarni adresy a NATovat v pripade komunikace pres zalozni linku (nebo rovnou privatni adresy a NATovat v obou pripadech). Problematicke pro externi servery (to ale vsechny varianty).

2) vzdy pri zmene primarni-sekundarni precislovat adresy. Pouzitelne pouze pro nejtrivialnejsi pripady (jeden router, jedna lokalni sit s klienty, zadne interni servery), jinak nerealne - sitova infrastruktura (routery a servery) je obvykle konfigurovana staticky, nevim o zadnych protokolech, ktere by zajistily automatickou zmenu prefixu v cele siti (napr. zmenily konfiguraci router advertisement demonu na odlehlych routerech).

3) mit nakonfigurovane vsude v siti oba prefixy paralelne, pak staci akorat presvedcit vsechny pocitace, aby pri komunikaci s vnejskem pokazde pouzily spravnou zdrojovou adresu. Mene problematicka varianta nez 2) (zato asi narocnejsi na konfiguraci), ale opet v pripade komplikovanejsi site nevim o protokolech, ktere by tohle zajistily.

[frr]

No zrovna ty obezličky v oblasti "mobility" s trvalou IP adresou mi připadají mozkově mrtvé v principu a odzačátku. Na tom není co vylepšovat. Provozně to bude nutně problematické a nespolehlivé, kromě vybraných případů, kdy se bude "cestovat" jenom mezi několika sítěmi navzájem přátelskými a dobře správcovanými. Problém s mobilitou pevné IP adresy je v tom, že v globále nelze routovat miliardy adres individuálně.

[frr]

IPv6 pozoruju z povzdálí, a docela jsem se uchechtl, když po několika letech standardizace se oficiálně upustilo od záznamů A6 a návazných "nepřímých odkazů" - ve prospěch přímočarého AAAA. Trochu doufám, že podobně vychcípou některé další "vychytanosti" IPv6. Bohužel jich tam asi i tak dost zůstane. Namátkou mě napadá relativní složitost rozborky paketu do vyšších vrstev, když chce člověk trochu pokročileji firewallovat... (zlaté IPv4) Viz Satrapova Bible.

[petr_p]

Co je na tom chorého? Buď to fungovat nebude, a tak se spojení bude přes domácího agenta tunelovat (nemá vůbec žádný vliv na nespolupracujícího klienta), nebo to fungovat bude. A kdo se toho stále bojí, nemusí se na domácího agenta registrovat a mobilní nebude.

[mrzout]

Snůška keců. Tlačit může, mít technické prostředky musí. Nerozumím problematice IP6 ani tomuto sporu, ale tohle je absolutní pravda.

Pokud nějaké zařízení (systém) bude schopno nějakou situaci řešit a jiné ne, pak to první je lepší. Vůbec nezáleží na tom, co je norma nebo jak by to mělo být správně.

[Jiří J.]

Ten problém neměl existovat, ale existoval, v tom to je. Až za *pár* let bude ipv6 všude a pokud to bude vypadat jak dnes s ipv4 (1 IP adresa na 1 MAC), řeknu "jó, za dob ipv4 bychom se připojili přes NAT, takhle si utřem nos a jdem spát, doufám Franto, že si tu necháš natáhnout za těch pár tisíc kabel od jinýho providera, ať se příště můžem připojit".

Nezbývá než doufat, že výrobci a ISP neudělají stejnou chybu podruhé, tzn. že se tyto věci nebudou muset řešit. Proto je ipv6 NAT asi tak hromadně odmítán (i přes svých pár specifických užití) - aby to tlačilo ISP udělat alespoň něco správně.

[R]

A ako to funguje na Slovensku?

http://www.ipv6forum.sk/ - posledny prispevok z dna 03.06.2008! To je asi jediny relevantny link, co vyjde z Google: http://www.google.com/search?q=ipv6+site%3a.sk

Tu sa mozeme pozriet, v akom krasnom stave je IPv6 peering v SIXe...: http://www.six.sk/aktual_peering.php

[asdfg]

Tie data su tam neni uplne 100%. Niektori ISP maju medzi sebou prepoj a tam si bezia po IPv6.

[2010]

kdybyste sem radsi dali foto te slecny/pani ze statni spravy

[houska]

amigo ... priste se alespon prihlas ;)

[mrzout]

Co takhle nějaký jednoduchý tutoriál/článek o nastavení firevallu při použití IP6. Za předpokladu, že mám v systému rozhraní s IP6 a IP6, jsou pravidla firewallu společná?

např. na desktopu běžně používám:

iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
iptables -F -t nat
iptables -F -t filter
iptables -X
# loopback
iptables -A INPUT -p ALL -i lo -j ACCEPT
# navazana spojeni
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Kdybych měl možnost se připojovat v síti s IP6, bude mne to chránit? Nebo musím nastavovat něco jiného? Jak se zadávají pravidla, jestli je tam nějaká odlišnost, atd.

Obecně soudím, že podpora IP6 je mizerná i proto, že o tom fakticky něco ví jenom pár lidí. ABC jako technický server má jen nějakou experimentální adresu, místo aby toto podporovalo natvrdo. Atd.

[Limoto]

Nastavuje se přes ip6tables, možná existuje něco co to sjednotí, to by mě taky docela zajímalo.

[Petr Maleček]

Docela by mi zajímalo jak to bude v budoucnu. Jestli o svoje současné IPv4 přijdu a zůstanou mi jen současné IPv6, nebo budu mít oboje :D ... moc se těším na dobu až budou jen čistě IPv6 a ip6tables se prejmenujou zpet na iptables.

[xkucf03]

Mně by spíš přišlo logičtější, kdyby byl jen jeden příkaz iptables a pomocí přepínače bys mu určoval, s kterou verzí IP má pracovat. Jako to má třeba ssh, wget atd. (což jsou sice aplikace na úplně jiné úrovni, ale řešit by to šlo stejně).

[xkucf03]

BTW: je tu nějaký optimista, který si myslí, že v dohledné době budeme mít čisté IPv6 (tzn. bez duálního 6/4 IP)?

[default]

LinMuck, WinFuck :-P

[x]

IPv4 tu bude jeste desitky let, jen proste novi zakaznici uz IPv4 dostavat nebudou a jak bude postupne rust % IPv6 only bodu v siti, bude upadat IPv4 a duvody ho dal provozovat. Jakmile provoz na IPv4 klesne pod nejakou mez, zacnou ho provideri rusit, aby usetrili za spravu. Samo, uplne nezmizi nikdy, i dneska se jeste gamesi po IPX.

[VSi]

jen proste novi zakaznici uz IPv4 dostavat nebudou

On už je nějaký použitelný mechanismus na přístup k IPv4-only obsahu z IPv6-only sítě?

Jinak si neumím nejmíň v příštích 10 letech představit, že by si někdo platil "připojení k internetu", a měl by přístup jen k IPv6 obsahu. Podle mě tam pořád bude dual-stack a IPv4 budou přes NAT. Ale pravda, veřejné IPv4 noví zákazníci nedostanou, ale to hodně často nedostanou ani teď.

Mnoho ISP nemá dost veřejných adres už pár let. Takže až dojdou všechny, skoro nic se nezmění. Jen dojde k doplnění o IPv6, které také v současnosti už u některých ISP běží.

[Jendа]

jen proste novi zakaznici uz IPv4 dostavat nebudou

On už je nějaký použitelný mechanismus na přístup k IPv4-only obsahu z IPv6-only sítě?

Nemyslel tím, že budou do IPv4 lézt přes NAT?

[Dan Ohnesorg]

Situace, ze zakaznik dostane IPv6 v podstate jako jedinou plhonodnotnou adresu nutne nastane a v asii i nastava.

Urcite k tomu muze dostat paralelne natovanou IPv4 adresu z privatniho rozsahu. Ale pocet zakazniku, ktere muzete natovat na jednu verejnou IP je omezen a zpohledu providera tam vznika nemaly problem s tim, ze prijde stiznost nahravaci firmy a jak on zjisti, koho na tu danou IP zanatoval? To neni v pripade, ze mate 100k zakazniku zadna sranda. On ani samotny NAT neni v takovych rozmerech zadna sranda, conntrack tabulky zacnou nechutne bobtnat, v dobach ruznych utoku viru nutne pretecou a cela IPv4 konektivita pujde do kytek.

A jeste tu nikdo nezminil jeden efekt. Mnoho provideru ma tendenci drzet lidi jen ve sve siti. U nas to delal dlouha leta Volny, ktery se snazil udelat vsechno, postu, webhosting, portal, zpravodajstvi, chtel aby jeho zakaznici generovali dalsi prijmy z jeho vlastnich zdroju. Pro providera, ktery bude nabizet jen IPv6 to bude bonus, lide budou mit na inetu malo zdroju a budou pouzivat ty jeho. A on pri tom bude ten hodny, ktery nemuze jinak.

[pavlix]

IPv4 tu bude jeste desitky let

Jak moc velké desítky let? Jedna? Dvě? Víc?

IPX není protokol, který běhá po celém Internetu. Ať si každý doma (na komunitní síti) provozuje co chce. Na Internetu je do jisté míry potřeba protokol sjednotit.

[frr]

Takže pokud by pravidla byla skutečně protokolově neutrální, dalo by se v shellovém skriptu psát

# Toto případně načíst z příkazové řádky
#IPTABLES_CMD=iptables
IPTABLES_CMD=ip6tables

$IPTABLES_CMD -F
$IPTABLES_CMD -X
$IPTABLES_CMD -A INPUT -i lo -j ACCEPT

a pak to jenom spustit dvakrát, pokaždé s jiným příkazem dosazeným do IPTABLES_CMD.

[Jiří J.]

Případně (čistěji) udělat jeden iptables-save skript (automaticky vygenerovat nebo napsat ručně) a pak ho předat iptables-restore a ip6tables-restore.

[frr]

Dovolím si nesměle akademicky namítnout, že do "iptables-save skriptů" nemohu substituovat konkrétní IPčka/interfejsy pomocí proměnných. Na rozdíl od shellového skriptu. Nebo se pletu? Shellový skript umí taky nahazovat a shazovat interfejsy, upravovat routovací tabulku, měnit nastavení v /proc/sys/net atd.

Co že je nakonec čistší?

[pavlix]

Jde to obojí i kombinovat.

[Jiří J.]

Jak psal kolega podemnou, jde to kombinovat, přes "here document". Tedy něco jako

#!/bin/bash
INTERFEJS="eth0"

iptables-resotre <<KONEC
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0
-A INPUT -i $INTERFEJS -d 1.2.3.4 -j ACCEPT
-A OUTPUT -o $INTERFEJS -s 1.2.3.4 -j ACCEPT
KONEC

Nevýhod shell skriptu pro iptables je hned několik, mezi dvě největší (které mě teď napadají) patří nutné načtení a zápis celého rulesetu při každém volání iptables (což u větších setů pravidel značně zpomaluje), druhou nevýhodou je pak atomicita - se shell scriptem není moc těžké si uříznout větev pod sebou (ssh) kvůli jenomu špatnému řádku, kdežto iptables-restore buď obnoví všechno, nebo nic. V jednom kroku. Dokonce mám pocit, že je tam lock, kdy kernel nepustí další packet na zpracování, dokud není nahraný nový ruleset, tedy není možnost, aby nějaký packet proklouzl těsně po flushnutí pravidel.

[frr]

Díky za podrobnosti. Přijde mi, že "here document" je taková ta kombinace, která má nevýhody obojího Pokud se týče atomicity a "uříznutí větve", jasně že se mašina při reloadnutí firewallu na chvíli odmlčí - ale protože to na tom firewallu běží jako shellový skript na lokále, tak ten shellový skript doběhne celý. Alespoň já jsem si nikdy nenaběhl na -J REJECT nebo tak něco, co by shodilo SSH relaci uprostřed skriptu. Možná je taky důležité, že ten můj shellový skript nic nevypisuje na stdout, takže se na tom nezablokuje Ale souhlasím, že 100% atomicita může být v mnoha případech užitečná.

Pro mě z toho plyne jiná kombinace: shellovým skriptem vygenerovat konfigurák v syntaxi iptables-save a ten pak restornout

[pavlix]

Přijde mi, že "here document" je taková ta kombinace, která má nevýhody obojího

Důvod?

Pokud se týče atomicity a "uříznutí větve", jasně že se mašina při reloadnutí firewallu na chvíli odmlčí

Když je to napsaný dobře, tak si odmlčení nevšimneš. Atomicita tady má význam přesně opačný. Měla by ti zajistit, aby nebyl systém ani chvíli děravý. Manuálová stránka k iptables-save neříká o atomicitě nic (Fedora 13).

Alespoň já jsem si nikdy nenaběhl na -J REJECT nebo tak něco, co by shodilo SSH relaci uprostřed skriptu.

Buď jsi hodně dobrý, nebo moc často nenastavuješ firewall vzdálených strojů.

Pro mě z toho plyne jiná kombinace: shellovým skriptem vygenerovat konfigurák v syntaxi iptables-save a ten pak restornout

To mi přijde ekvivalentní té možnosti, kterou kritizuješ. Nějaký praktický rozdíl?

[xkucf03]

Já se tedy zatím držím ručně psaných skriptů a staré dobré sériové linky, tu si člověk jen tak neodřízne Ale uvažuji, že si pravidla budu definovat v XML* a z nich ten skript generovat :-P

*) pro rýpaly: iptables-xml, ale to dělá jen přepis toho skriptu, posloupnost příkazů a ne nějakou logickou definici toho, co má být povolené a co ne.

[pavlix]

Tak zrovna v tomhle případě nevidím jediný přínos XML syntaxe.

[xkucf03]

A vidíš ho vůbec někde?

[pavlix]

Na to můžeš založit samostatné vlákno nebo nový blogpost :).

[frr]

Pokud si správně pamatuju, aby nebyl systém ani chvíli děravý, to se řešívalo organizací skriptů (sekvencí postupného zřizováním chainů) a tím, že se na dobu aktualizace firewallu nastavovala "policy" na všech tabulkách na "drop", případně se dal vypnout IP forwarding. Popravdě řečeno jsem si s tím moc hlavu nelámal a neměl jsem nikdy problém - asi jsem před lety ještě v dobách IPchains oprásknul "ideový základ" svých skriptů ze správného zdroje

"HERE document" pokud vím neinterpretuje proměnné prostředí (jsem si jistý tak na 70%). Čili bych na tom byl stejně, jako se standalone konfigurákem ve formátu iptables-save, akorát bych to vcelku zbytečně navíc vkládal do skriptu jako "HERE document".

Pokud si shellovým skriptem vygeneruji konfigurák iuptables-save a ten pak restornu, mám možnost použít proměnné prostředí a nakonec konfigurák atomicky natáhnout.

[pavlix]

"HERE document" pokud vím neinterpretuje proměnné prostředí (jsem si jistý tak na 70%).

Kdybysis aspoň přečetl ten příklad z proměnnými výše. Heredoc se k proměnným chová tak jak si sám zvolíš.

Na zbytek nemá cenu reagovat, protože to vychází ze špatného předpokladu.

[frr]

Ajooo... budu muset k očnímu... Díky

[pavlix]

Já už tam taky dlouho nebyl.

[default]

Já se úspěšně vyhejbám všem doktorům a je mi nejlíp.

[Bilbo]

co by shodilo SSH relaci uprostřed skriptu

Když se skript pustí ve screenu, tak se se nestane, že by se v půlce kvůli ztrátě spojení přerušil...

[Mrkva]

No, ptal jsem se dvou svých ISP (oba wifi)- ten v Praze mi odpověděl, že IPv6 neplánuje a jestli chci veřejnou IPv4, mám si připlatit 50Kč měsíčně, ten tady v prdelákově na severu ohlásil, že v první polovině 2011 to plánuje spustit na ostro a v současnosti už probíhá testovací implementace. (IPv4 jsem dostal zadarmo). Takže ono nakonec vypadá tak, že ani menší ISP na tom nebudou tak špatně :)

[houska]

napis o nich sem

[Mrkva]

Uloženo. Mimochodem, ta captcha mi dala fakt zabrat... Došlo mi to, až když jsem se vracel s hrnkem s kávou a monitor viděl z větší dálky.

[houska]

tak ta captcha je fakt maso .... :)

[Jendа]

Já to pochopil hned. Asi jsem nadprůměrně inteligentní .

[xkucf03]

Ti menší na tom budou pravděpodobně líp, protože tam jsou lidi, které to baví a kteří to dělají i pro radost. Kdežto např. Volny.cz mi odpověděl:

„O IPv6 aktualne neuvazujeme. Resit ji teoreticky zacneme v moment, kdy bude realna hrozba vycerpani kapacity IPv4.“

Je to naprostá ignorance nebo jen neznalost?

[x]

Praskni toho co chce 50Kc RIPE, kdyz si postezuje dost lidi, tak jim seberou prefix ;D.

[Mrkva]

To jsem si říkal, ale nenašel jsem nikde konkrétní bod v podmínkách RIPE, který by to zakazoval.

[xkucf03]

Co pak se nesmí účtovat za IPv4 adresy? To bych se taky přihlásil, ušetřili bychom dost peněz Ale obávám se, že to neprojde.

[vencour]

Chybělo mi v té diskusi na IT10 něco na téma "a co budete dělat, když to nestihnete, nesplníte, bude větší nouze, než čekáte?"

[xkucf03]

NATovat přece :-/

[vencour]

Já čekal spíš slova "dávám hlavu na špalek, že to naše firma zvládne".

Mimochodem, v té diskusi byli spíše technici než obchodníci ... ?

[xkucf03]

Jo, to by řekli, ale ve skutečnosti by pak NATovali.

[x]

Zakaznik: Umite IPv6 ?
Obchodnik: No jiste, zadny problem ...

(po uzavreni smlouvy)
Zakaznik: Mohli by jsme tedy dostat IPv6 prefix ?
Obchodnik: A co ze to je ?
Zakaznik: ...
Obchodnik: Jo, technici rikali ze to nanic nepotrebujete a ze to nikdo nechce
Zakaznik: Ale vzdyt jste tvrdil ze to neni zadny problem ?
Obchodnik: ... nj, ja myslel ze chcete 6 IP adres

=> ruce pryc od GTS, jsou to lhari a podvodnici.

[Mrkva]

Tak tohle je perla dne!

[kralyk z abclinuxu]

Počkat, počkat, počkat... chceš mi říct, že to cos napsal nebyl vtip, ale opravdu se to stalo?!?

[the.max]

takhle nejak to bylo i u nas pred 2ma lety, nicmene ke smlouve jsme se nastesti uz nedostali.

[houska]

sup tam s nima

[Samae1]

I přesto, že to obchodník slíbil "pouze" ústně, má dle zákona povinnost to dodržet.

[xkucf03]

To je sice hezké, ale když mu to nemáš jak dokázat, tak u soudu moc neobstojíš, to je tvrzení proti tvrzení – leda že by se našlo hodně zákazníkům, kterým to nasliboval…

[zde]

Co řešíte, copak není /29 lepší než /64 ? :-P