World IPv6 Lunch! (diskuse)

[Bedňa]

Však to spustite a netrolujte tu s tým furt

[Ondrej 'SanTiago' Zajicek]

Myslim, ze to vidis zbytecne cerne. Me prevazna vetsina IPv6 veci v systemu funguje bez potizi a prakticky stejne jako na IPv4.

Jak je na tom NetworkManager to netusim (nepouzivam), nicmene podle ruznych komentaru to vypada na pekne obsurni kus software, ktery byl nasazovan vyrazne drive, nez vubec splnoval zakladni pozadavky na IPv4, takze ze podobna situace je u IPv6 by me ani neprekvapilo.

Co se tyce DNS v RA, tam zaspalo hlavne IETF, kdyz to standardizovali az pred par lety. To tedy v Linuxu bezne nefunguje, nicmene to neni zas tak dulezite (malokdo hned pocita s IPv6-only rezimem, takze DNS pres IPv4 je prijatelny kompromis).

DHCPv6 jsem nezkousel, na IPv6 si plne vystacim s RA.

[pavlix]

Myslim, ze to vidis zbytecne cerne. Me prevazna vetsina IPv6 veci v systemu funguje bez potizi a prakticky stejne jako na IPv4.

Nevidím to černě :). Máme už opravy pro všechny problémy, které brání běžnému provozu IPv6-only stanice. Jen ještě nejsou všechny ani v upstreamovém Gitu, a počítám, že to během nejbližších měsíců proteče přes upstream alespoň do Fedory.

Jak je na tom NetworkManager to netusim (nepouzivam), nicmene podle ruznych komentaru to vypada na pekne obsurni kus software, ktery byl nasazovan vyrazne drive, nez vubec splnoval zakladni pozadavky na IPv4, takze ze podobna situace je u IPv6 by me ani neprekvapilo.

Bez userspace démona nelze na Linuxu vůbec konfigurovat DNS. Kernel nemůže zasahovat do /etc/resolv.conf ani jinak předávat informace o DNS místnímu resolveru. Pokud na IPv6-only síti nepoužíváš NetworkManager, musíš používat nějakou jinou alternativu. Výjimkou jsou staticky konfigurované DNS.

Co se tyce DNS v RA, tam zaspalo hlavne IETF, kdyz to standardizovali az pred par lety. To tedy v Linuxu bezne nefunguje, nicmene to neni zas tak dulezite

Ten standard už má druhou iteraci. Navíc ten standard je napsaný s předpokladem, že se neztrácejí pakety. Co víc, on je napsaný s předpokladem, že se neztrácejí multicastové pakety. Na multicastu na wifi jsme docela slušně pohořeli i s IPv4 OSPF.

RFC 6106 je třeba opravit, aby fungovalo i na něčem jiném než 100% spolehlivých sítích.

(malokdo hned pocita s IPv6-only rezimem, takze DNS pres IPv4 je prijatelny kompromis).

Právěže mnoho firem a případně i ISP z mého okolí nechce o dualstacku ani slyšet a mnohem spíše by šli do IPv6-only režimu s NAT64 a DNS64. Tím se zbaví potřeby spravovat duální síť.

V tomto směru tedy přijetí IPv4 DNS jako kompromisu jde přímo proti spuštění IPv6, natož světovému. Bavíme se samozřejmě o klientské straně, na serverech je dualstack přirozeným řešením. Naštěstí RDNSS funguje a DHCPv6 Information Request taky.

DHCPv6 jsem nezkousel, na IPv6 si plne vystacim s RA.

Ne všichni chtějí nechat přidělení adres na klientských stanicích. Řízená konfigurace adres je pro mnoho provozovatelů sítí důležitá a bez ní do IPv6 nepůjdou. Na dualstacku se navíc selhání IPv6 konfigurace může projevit sestřelením celého rozhraní včetně IPv4.

Mimochodem, DHCPv6 Prefix Delegation je killer feature pro centrálně řízenou konfiguraci sítě většího rozsahu. Můžeš tak naadresovat celou síť z jednoho serveru napojeného na jednu databázi (replikovanou kvůli redundanci).

[Ondrej 'SanTiago' Zajicek]

Bez userspace démona nelze na Linuxu vůbec konfigurovat DNS. Kernel nemůže zasahovat do /etc/resolv.conf ani jinak předávat informace o DNS místnímu resolveru. Pokud na IPv6-only síti nepoužíváš NetworkManager, musíš používat nějakou jinou alternativu. Výjimkou jsou staticky konfigurované DNS.

No, proto jsem taky psal, ze (mi) DNS z RA nechodi. Prirozene by asi bylo rovnou fixnout ten resolver v libc, aby si mohl brat konfiguraci primo z jadra.

Navíc ten standard je napsaný s předpokladem, že se neztrácejí pakety. Co víc, on je napsaný s předpokladem, že se neztrácejí multicastové pakety. Na multicastu na wifi jsme docela slušně pohořeli i s IPv4 OSPF.

A nestaci proste nastavit parametry tak, aby se RA posilaly vyrazne casteji? Odobne s OSPF, to pouzivam na wifi s hello 5 a dead 60 a vcelku bez potizi.

Jinak, pokud jsou potize se ztracejimi se pakety, tak ten problem ma cele RA, ne jenom RFC 6106, ne?

[pavlix]

No, proto jsem taky psal, ze (mi) DNS z RA nechodi. Prirozene by asi bylo rovnou fixnout ten resolver v libc, aby si mohl brat konfiguraci primo z jadra.

To by bylo přirozené, a zrušení resolv.conf a převedení seznamu nameserverů do kernelu bych uvítal. Ale je to obrovská změna, která by se týkala všeho možného bez ohledu na IPv6 či IPv4. Dotkla by se i možnosti používat lokální resolver místo toho ze seznamu (při zachování seznamu). To by ovlivnilo i novinky jako třeba DNSSEC v podobě v jaké je dostupný ve Fedoře 17.

A nestaci proste nastavit parametry tak, aby se RA posilaly vyrazne casteji? Odobne s OSPF, to pouzivam na wifi s hello 5 a dead 60 a vcelku bez potizi.

Jasně, dead interval se dá zvyšovat, ale to zase zhoršuje reakci sítě na skutečný výpadek. Navíc to není jenom wifi, jsou to i některé switche. A může se ti stát, že máš takovou smůlu, že se ti ty špatné prvky sejdou pohromadě. NBMA to jistí.

Jinak, pokud jsou potize se ztracejimi se pakety, tak ten problem ma cele RA, ne jenom RFC 6106, ne?

Ty problémy se opravdu objevují i mimo RFC 6106, ale zcela minimálně. RFC 6106 speciálně nastavuje parametry tak, že to srovnání s OSPF opravdu nesnese. Zatímco default OSPF je čtyřnásobek, ty sám píšeš, že používáš dvanácti násobek, tak RFC 6106 explicitně specifikuje jednonásobek jako spodní hranici a dvojnásobek jako horní.

Doporučuju překousnot to, že je to XML nebo si ho nechat převést na některý RFC formát a přečíst si ten odkazovaný rozpracovaný dokument.

Budu rád za každý nápad a komentář k tomu, co je tam popsáno.

[Ondrej 'SanTiago' Zajicek]

Strucne jsem to proletl (kdyz jsi postnul ten odkaz poprve, tak jsem si vsiml jen weboveho rozhrani gitu a ani mne nenapadlo, ze se pod tim schovava textovy dokument).

Puvodni RFC 6106 jsem zatim nestudoval. Nekdy bych si mel najit chvili casu a pridat pro to podporu do me imlementace RA demona.

To omezeni lifetime v RFC 6106 naprosto nechapu, ten argument pro to se mi zda dost nesmyslny (pokud dojde k nejake mobilite, tak je treba zneplatnit vsechny udaje ziskane ze stareho RA, ne jenom adresu DNS serveru).

Komentare k textu:

The default value of AdvRDNSSLifetime and AdvDNSSLLifetime MUST be at least 5*MaxRtrAdvInterval so that there are enough Router Advertisements recieved by the host to avoid this. When the administrator sets a lower value, the system SHOULD issue a warning.

Tohle me prijde jako overkill. Vzhledem k tomu, ze nejdulezitejsi lifetime AdvDefaultLifetime je defaultne 3*MaxRtrAdvInterval a RFC 4861 nespecifikuje zadne warningy pro nizsi hodnotu, prijde mne rozumne, aby AdvRDNSSLifetime a AdvDNSSLLifetime bylo handlovano naprosto stejne.

Use Router Solicitations as a last resort

To mne prijde vcelku zbytecne.

Use DNS even after Lifetime

To mne naopak prijde jako pomerne smysluplne reseni, i kdyz pokud vyprsi default routa, tak uz to je vcelku stejne jedno, a pokud nevyprsi, tak rouzmna hodnota AdvRDNSSLifetime a AdvDNSSLLifetime zajisti nevyprseni DNS, takze to je taky vcelku zbytecne.

Hosts with automatically configured DNS SHOULD use DNS servers provided by the current local network (RA or DHCPv6). It MUST NOT use servers automatically configured in other networks.

Tohle je dobry a smysluplny postreh, nicmene ta formulace je priserna - ty DNS servery nemusi byt 'provided by the current local network' (mohou byt nekolik hopu dal), ale spis jde o to, ze by mely byt pouzity ty DNS servery, ktere jsou konzistentni s aktualne pouzivanou konfiguraci site (napr. byly doporuceny skrz RA od stejneho routeru, ktery slouzi jako default gw).

[pavlix]

Tohle me prijde jako overkill. Vzhledem k tomu, ze nejdulezitejsi lifetime AdvDefaultLifetime je defaultne 3*MaxRtrAdvInterval a RFC 4861 nespecifikuje zadne warningy pro nizsi hodnotu, prijde mne rozumne, aby AdvRDNSSLifetime a AdvDNSSLLifetime bylo handlovano naprosto stejne.

Díky za názor, všechno v tom textu je třeba brát jen jako sebrané nápady, ne finální podobu. Tohle je v podstatě opsáno z jednoho z mých prvních mailů na IETF, ještě než jsem se celou věcí stihl probrat.

Tohle je dobry a smysluplny postreh, nicmene ta formulace je priserna - ty DNS servery nemusi byt 'provided by the current local network' (mohou byt nekolik hopu dal), ale spis jde o to, ze by mely byt pouzity ty DNS servery, ktere jsou konzistentni s aktualne pouzivanou konfiguraci site (napr. byly doporuceny skrz RA od stejneho routeru, ktery slouzi jako default gw).

Jo, to bude nejspíš formulace od Fernanda Gonta. On ten text začal psát původně, než mi nabídl se na tom účastnit. Já teda doufám, že se brzo objeví, on je nejspíš někde na dovolené či co. Až se to trochu prodiskutuje, tak si stejně myslím, že to získá úplně jinou podobu než je ta současná.

[Ondrej 'SanTiago' Zajicek]

Mimochodem, DHCPv6 Prefix Delegation ...

BTW, netusis, jaky je stav s podporou prefix delegation ve stavajicim software? Napr. Linuxove DHCP servery? To primo vytvareji routy do kernelu, nebo nejak komunikuji s routovacim software?

A jak to funguje na ADSL ci jinych linkach fungujicich pres PPP, tam se taky pouziva DHCPv6, nebo se to konfiguruje pres PPP, jako autokonfigurace na IPv4?

Premyslim, co nasadit ve wifi sitich jako klientske krabicky s podporou IPv6. Dost pochybuju, ze nejake takove bez potizi fungujici (zvladajici napr. autokonfiguraci s prefix delegation) se bezne prodavaji. Takze zatim spis uvazuju o semistaticke konfiguraci v kombinaci s RIP - prefix rucne nastaven v krabicce, ta ho pres RA propaguje na downstream (LAN) interface a pres RIP ho propaguje na upstream (WAN), kde ho RIP demon prijme a nastavi routu.

[pavlix]

BTW, netusis, jaky je stav s podporou prefix delegation ve stavajicim software? Napr. Linuxove DHCP servery? To primo vytvareji routy do kernelu, nebo nejak komunikuji s routovacim software?

ISC DHCP by to mělo umět, ale zatím jsem neměl čas to nějak více testovat.

A jak to funguje na ADSL ci jinych linkach fungujicich pres PPP, tam se taky pouziva DHCPv6, nebo se to konfiguruje pres PPP, jako autokonfigurace na IPv4?

Pokud vím, tak se PPP by se mělo umět nějak kombinovat s DHCPv6 a nebo přidělovat rovnou jako u IPv4. Nepracoval jsem s tím, ale něco málo se řeší právě v NetworkManageru.

prefix rucne nastaven v krabicce, ta ho pres RA propaguje na downstream (LAN) interface a pres RIP ho propaguje na upstream (WAN), kde ho RIP demon prijme a nastavi routu.

Jojo, to chápu, v malém měřítku bych šel do toho samého.

[petr_p]

Pokud se štítíš NetworkManageru, ale chceš brát konfiguraci resolveru z oznámení směrovače, tak vyzkoušej rdnssd z balíku ndisc6. Je to drobný démon, který bere RDNS záznamy z jádra přes netlink a cpe je do /etc/resolv.conf nebo nepřímo skrze správce resolvconf.

[pavlix]

Díky za info, já se sice NetworkManageru štítit nemůžu, ale rdnssd taky budu muset testnout aspoň pro zajímavost.

[pavlix]

Mimochodem rdnssd implementuje RFC 5006, ne současné RFC 6106. Tím pádem je DNSSL automaticky mimo hru, což sice není tragédie, ale je to regrese oproti IPv4.

[petr_p]

Ano, autor již dlouho nevydal novou verzi. Ale v gitovém stromě má podporu RFC 6106, a nedávno si hrál s autotools, takže bychom se mohli brzo dočkat.

[pavlix]

A... díky za info, to se hodí vědět.

[Heron]

Neviděl bych to tak černě. Jestli něco neumí NetworkManager, no tak se to prostě časem dodělá. Statické nastavení funguje, RA funguje, programy vesměs fungují. A že se na to ISP vysrali? No je třeba je neustále bombardovat! Dokonce i GTS po "pouhých" 2 letech dovezla schopný router a po výměně několika emailů z jejich "Senior network specialist" jsme se konečně dostali ke skoro správnému subnetu -- tímto před GTS varuji.

Takže se na to těším (obzvláště na oběd) a možná bychom mohli vypnout všechny IPv4 only servery, ať máme 100% v6!

[pavlix]

Neviděl bych to tak černě. Jestli něco neumí NetworkManager, no tak se to prostě časem dodělá.

Vždyť jsem jen napsal, že to nestihneme do šestého června tohoto roku. Nic víc, nic míň :).

A že se na to ISP vysrali?

To jsem nepsal.

Takže se na to těším (obzvláště na oběd) a možná bychom mohli vypnout všechny IPv4 only servery, ať máme 100% v6!

+1

Škoda, žádné IPv4-only servery nevlastním a neprovozuju, takže je nemůžu ani vypnout.

[Heron]

To jsem nepsal.

Ale já jo

Škoda, žádné IPv4-only servery nevlastním a neprovozuju, takže je nemůžu ani vypnout.

Se musí chlubit. Když ono je to při počtech několika set webů poněkud složitější. Ale LE už jede na šestce něco přes rok a půl (ani nevím, jestli jsme z velké trojky ABC, Root, LE nebyli první, nejspíš to bylo abc), po linuxáře je to tedy dobré.

Jinak opravdu maximálním možný způsobem naléhejte na své poskytovatele připojení a tam, kde to ještě není i na poskytovatele hostingových služeb. Na tomhle pomalém přechodu je jednou z nejhorších věcí (pro mě) fakt, že si stále více lidí a techniků zvyká na to, že jediné správné a bezpečné připojení je přes NAT. A vy poskytovatelé, vypněte maškary a adresujte.

[pavlix]

Ale já jo

Ti, se kterými spolupracuju, IPv6 v síti mají a na požádání ho i přidělují. Ale to není World IPv6 Launch, že.

Když ono je to při počtech několika set webů poněkud složitější.

Mě to z pohledu hostingu přijde stejně jednoduché jako u jednoho webu. Prostě ke každé IPv4 adrese přijde jedna IPv6, ideálně podle nějakého deterministického mapování. To je spíš horší řešit to, že aplikace někdy pracují s IP adresami.

Když ono je to při počtech několika set webů poněkud složitější. Ale LE už jede na šestce něco přes rok a půl (ani nevím, jestli jsme z velké trojky ABC, Root, LE nebyli první, nejspíš to bylo abc), po linuxáře je to tedy dobré.

Měl jsem pocit, že iinfo to zvládlo dřív, ale jistý si nejsem. Ještě tu chybí single sign on v podobě OpenID :).

Jinak opravdu maximálním možný způsobem naléhejte na své poskytovatele připojení a tam, kde to ještě není i na poskytovatele hostingových služeb.

U poskytovatele připojení jsem IPv6 konfiguroval vlastníma rukama. V hostingu je taková konkurence, že není problém se prostě obrátit na ty, co nejsou úplné lamy (na to samozřejmě nestačí mít IPv6, ale nemít ho už něco naznačuje).

Na tomhle pomalém přechodu je jednou z nejhorších věcí (pro mě) fakt, že si stále více lidí a techniků zvyká na to, že jediné správné a bezpečné připojení je přes NAT.

Tohle řeším na úrovni školení a přednášek. Lameřiny typu používání maškarády jako bezpečnostní techniky se snažím předcházet už v začátku.

[Heron]

Prostě ke každé IPv4 adrese přijde jedna IPv6, ideálně podle nějakého deterministického mapování.

V přiřazení adrese serveru opravdu problém není, že ano. Tím práce začíná, je třeba přidat dns záznamy (ne všechny spravujeme), je třeba mít podporu v app apod. Jde to, ale je to pomalý proces. Pomalejší, než jsem si na počátku představoval. Ono už jen třeba dřívější přeadresování na vlastní subnet ipv4 se vleklo právě k vůli pomalým externím správcům dns.

To je spíš horší řešit to, že aplikace někdy pracují s IP adresami.

Tak tak.

single sign on v podobě OpenID

Z toho tedy tak odvázaný nejsem. Měl jsem na vlastním serveru vlastního poskytovatele idenity (nebo jak se to jmenuje), na těch pár serverech, což OpenID umějí, jsem to používal a nějak jsem nepoznal rozdíl. Stejně si tam člověk musí vytvořit účet, který jen spáruje s OpenID. Hmm. To už by se mi líbilo (ale to by dost lidí prskalo z hlediska anonymity), mít automatické přihlašování a vytvoření účtu při první návštěvě pomocí klientského certifikátu v prohlížeči.

U poskytovatele připojení jsem IPv6 konfiguroval vlastníma rukama.

Nápodobně.

V hostingu je taková konkurence, že není problém se prostě obrátit na ty, co nejsou úplné lamy (na to samozřejmě nestačí mít IPv6, ale nemít ho už něco naznačuje).

Souhlas, asi bych musel hodně dlouho přemýšlet, jestli jsem vůbec někde zavadil o hosting bez šestky.

Tohle řeším na úrovni školení a přednášek. Lameřiny typu používání maškarády jako bezpečnostní techniky se snažím předcházet už v začátku.

A díky ti za to.

[xHire]

V hostingu je taková konkurence, že není problém se prostě obrátit na ty, co nejsou úplné lamy (na to samozřejmě nestačí mít IPv6, ale nemít ho už něco naznačuje).

Souhlas, asi bych musel hodně dlouho přemýšlet, jestli jsem vůbec někde zavadil o hosting bez šestky.

Není třeba chodit daleko. (Pravda, je to trošku zanedbané, v létě to budu dohánět.)

[pavlix]

V přiřazení adrese serveru opravdu problém není, že ano. Tím práce začíná, je třeba přidat dns záznamy (ne všechny spravujeme), je třeba mít podporu v app apod. Jde to, ale je to pomalý proces. Pomalejší, než jsem si na počátku představoval. Ono už jen třeba dřívější přeadresování na vlastní subnet ipv4 se vleklo právě k vůli pomalým externím správcům dns.

Tak to řeknu, že jde o záznamy na cizích DNS serverech :). Musím se přiznat, že ty taky řeším laxně. Zákazník, který nechá veškerou správi „na nás“ (tedy na mém zákazníkovi, provozovateli služby), má prostě určitou výhodu.

To už by se mi líbilo (ale to by dost lidí prskalo z hlediska anonymity), mít automatické přihlašování a vytvoření účtu při první návštěvě pomocí klientského certifikátu v prohlížeči.

To bych považoval za další stupeň SSO, který má své výhody i nevýhody.

A díky ti za to.

Zpravidla si za to nechávám děkovat na účet :). Ale je fakt, že naposled jsem se zákazníky při velkém zájmu zůstal do sedmi do večera, akorát jsme se museli přesunout do KFC ke stolu u zásuvky. Škoda, že nemáme fotku, na stole rozložené tři notebooky, nějaká deska od Mikrotika a kabeláž.

[Jendа]

Měl jsem pocit, že iinfo to zvládlo dřív, ale jistý si nejsem.

Root jako takový byl přes IPv6 přístupný docela brzo, ale stylospis a obrázky to tahalo z nějakého jiného serveru, který IPv6 neměl.

[xkucf03]

To je nápad! V ten den shodit* všechny IPv4 adresy ze spravovaných serverů a nechat jen šestkové

*) nebo spíš zablokovat na firewallu, ať se nemusejí restartovat démoni

[pavlix]

Mám pocit, že se mi tahle agresivní metoda tak úplně nehodí :). Mohl bych IPv4 vypnout tak na svém serveru s webovkama, ale pochybuju, že si toho vůbec někdo všimne :D.

[Migi]

hehe, jen vidim IPv6 je mi jasne že pavlix :D

[Migi]

respektive:

Jak se do lesa IPv6, tak se z lesa pavlix.

[pavlix]

Tak kdo jiný by měl tohle téma komentovat, že? :)

[pavlix]

:)

[Begleiter]

Nevíte někdo víc informací o UPC versus IPv6? Na jejich stránkách je jenom toto: Obecné prohlášení + otázky a odpovědi ohledně IPv6.

[pavlix]

Na konferenci loni v létě v Sušici mi někdo z UPC tvrdil, že za pár měsíců budou mít nabídku pro firmy. Ale zase na druhou stranu, kdo by chtěl internet od UPC, že.

[Begleiter]

Díky za info. Já Internet od UPC mám a to z toho důvodu, že u nás de facto nic jiného nepřipadá v úvahu.

[pavlix]

Kde to je?

[Begleiter]

Kutná Hora

[Begleiter]

Bohužel KH net nemůžu použít.

[ludvik]

Můžeš to rozvést? Moc míst, kde je UPC a my ne tu není ... A pokud to tak je, tak si za to mohou ty domy sami Případně emailem, ať to tu nesviníme ... jsem k nalezení na pár kliků.

[Begleiter]

Není nikdo dostatečně blízko, abych se přes něj kabelem (ethernet) připojil. O bezdrátové připojení nemám zájem.

[pavlix]

O bezdrátové připojení nemám zájem.

Chyba.

[Begleiter]

Moje jediná praktická zkušenost s bezdrátovým Internetem je Internet mého šváry na vesnici. Tam když se připojí víc lidí současně, tak rychlost (download) jde "do háje" takovým způsobem, že např. wwww.seznam.cz aj. se načítá neúměrně dlouho.

Momentálně mám Internet od UPC (dowload až 60 Mb/s, upload až 6 Mb/s) a vlastně (zatím) jediné, co mi na něm vadí, je, že o zavedení IPv6 (zdá se) zatím pouze píšou. Chtěl bych jednu nebo víc veřejných IPv6 adres, ale zatím mám houby.

[georgius]

Tak já jsem na wifině (pravda 5G s airmaxem, ale zase v maximálně zarušené Praze) s maximem mrzkých 73/57 Mbit, když pár lidí sosá tak se to fakt zpomaluje až někam k 30/16 , což je ale furt víc než UPC. Ono taky záleží na tom, jakou značku párků má rád Tvůj poskytovatel

[Käyttäjä 11133]

Tak třeba zmigrovat z 5G na 10G.

[pavlix]

Takhle?

[Begleiter]

Pochlub se, kolik platíš.

[Georgius]

Kdybych nebyl APčkář tak 400,- Kč měsíčně ...

[SPM]

To já mám na 5G 10M/10M - zashapovaný a dává to obouma směry naráz :) Jsem tam jeden ze dvou klientů, takže to jede pořád :) a zadarmo neber to ;D

[pavlix]

Moje jediná praktická zkušenost s bezdrátovým Internetem je Internet mého šváry na vesnici. Tam když se připojí víc lidí současně, tak rychlost (download) jde "do háje" takovým způsobem, že např. wwww.seznam.cz aj. se načítá neúměrně dlouho.

Moje praktická zkušenost s bezdrátem je zcela bezproblémová přípojka, která zvládá v součtu cca 70 mbit max, latence naprázdno je do 3 ms.

IMO tvé zdůvodnění je něco jako kdybych už nikdy nechtěl drát, protože jsem měl jednou drát přestřižený. Ale každému, co jeho jest.

Mně osobně vyhovuje, když je provozovateli sítě možné zavolat a třeba ho i potkat osobně.

[pavlix]

Já bych na tvém místě zkusil kontaktovat okolní providery, kteří poskytují bezdrátově (předpokládám, že kdybys tam měl natažený jiný drát než UPC, že bys o tom už věděl).

http://www.internetprovsechny.cz/wifi/kraj/stredocesky/?obec=Kutn%E1%20Hora&oid=ob50733

Kolikrát jsou schopni poskytnout stejnou nebo vyšší rychlost jak na uploadu, tak na downloadu, nižší latence a můžeš si trochu víc vymýšlet (IPv4 adresy, IPv6 adresy, reverzy, ...).

[Begleiter]

Díky. Popřemýšlím o tom.

[pavlix]

Doporučuju předtím proměřit skutečnou rychlost tvého připojení oproti něčemu, co nefunguje jako veřejný speedtest, abys neočekával od případného nového ISP podmínky, které máš pouze na papíře. Zopakuj test v různých denních dobách apod.

[Begleiter]

OK

[St4nd3l]

Na firmě máme od UPC optiku IPv4/IPv6. Poslední výpadek ani nepamatuju. Jako podporu mám číslo na technika ktery je velice ochotny. Podle mne to není tak špatné. Lokalita Ostrava

[pavlix]

Já neříkám, že je to špatné. Jen jsem zvyklý na trochu lepší reakční dobu než obvykle UPC má. Naposledy jsem musel po týdnu volat znovu se stejným požadavkem a ten člověk věnoval mnoho úsilí tomu, aby mi vysvětlil, že změnit IP tak, aby zákazník měl obě ze stejného rozsahu je hrozně složité a nebezpečné. Navíc mi trochu nevyhovuje mnohonásobný rozdíl mezi rychlostí stahování ze speedtest.net a stahování z nějakého skutečného zdroje.

Your mileage may vary.

[Karel Peran - Nunak]

Ahoj,

ma zkusenost s IPv6 na UPC je takova, ze sem kontaktoval technickou podporu, s tim ze bych se mel zajem zapojit i do testovani IPv6 a toto je odpoved:

dovolte, abychom reagovali na Váš e-mail ze dne 31. 5. 2012.

Náš DHCP server zatím nepřiděluje IP adresy IPv6. Budete ale s velikým předstihem kontaktován v budoucnu.

Děkujeme.

V případě, že budete reagovat na tento e-mail, využijte prosím opět standardního formuláře, který naleznete na http://web.upc.cz/klpoz/cz/

S pozdravem a přáním příjemného dne

Tomáš Lejčko Specialista technické podpory datových služeb UPC UPC Česká republika, s.r.o.

Tzn, zda se ze uz ani o nadsence a "testery" nemaji zajem jak tvrdili ve vyjadreni k IPv6 Launch :(

Karel Peran - Nunak

[Heron]

Nemělo by být na to IPv6 Lunch šest chodů?

[pavlix]

To už bych asi odpoledne neodpřednášel :).

[Habo]

Skôr 16, nie?

[xHire]

V tomhle ohledu je zajímavý počin IPv6-only FreeBSD, ale ještě jsem to neměl možnost otestovat. Je možné, že tam ještě něco nefunguje, ale už jen to, že tenhle projekt existuje, dává signál, že na tom cíleně pracují.

[pavlix]

Ono vůbec FreeBSD má mnohem lepší podporu IPv6 třeba i v podobě getaddrinfo a patchů do nss-mdns, s tím je v glibc trochu problém.

[zdenek-hbr]

vyuziju tema a zeptam se. funguje vam justice.cz pres IPv6? Mam na kompu (nativni) ipv6 i ipv4 a kdyz chci vlizt na justice.cz tak nic. bila stranka. server neodpovida. zakazu ipv6 a vse frci.

[Heron]

Na šestce mají restriktivnější firewall:

nmap scan report for 2001:af0:ffee:200::c2d5:2917
Host is up.
PORT    STATE    SERVICE
80/tcp  filtered http
443/tcp filtered https

Nmap scan report for www.justice.cz (194.213.41.145)
Host is up (0.010s latency).
PORT    STATE    SERVICE
80/tcp  open     http
443/tcp filtered https

[zdenek-hbr]

:-0

a ja si myslel ze mam asi neco spatne ja. tohle me fakt nenapadlo. tak k cemu ty ipv6 adresy vubec maji...no jo statni sprava...

dik

[pavlix]

Mně se zdá, že (už) to funguje.

tak k cemu ty ipv6 adresy vubec maji...

Tohle je problém dualstack světa. Lidé jsou zvyklí funkčnost webu testovat tím, že se na něj podívají. To zvládne každý. Otestovat jednotlivě IPv4 a IPv6 už ne.

Zvykej si, už teďka se ti může stát stejná věc u IPv4, když se na stránky budou lidé dívat z organizace, kde IPv6 je a nenapadne je testovat IPv4.

[Heron]

Jop, teď už tu 80 mají otevřenou i na v6.

[zdenek-hbr]

ale stranka se nacita nepouzitelne pomalu..

[zajdee]

Mají tam pravděpodobně MTU problém. Tzn. pokud doma máte šestku přes tunel, nebo váš ISP v cestě používá MTU<1500, tak vám nebude fungovat Justice ani tamní rejstřík. A nepomáhá ani úprava MSS (což třeba u o2.cz zabralo) Z firemního nativního připojení s MTU=1500 není problém.

Když loni (nebo předloni?) na IT11 vystupovala paní ze státní správy, vyzývala, abychom jí problémy s IPv6 ve státním hlásili. Tak jsem jí tenhle problém tenkrát poslal mailem a zůstalo to bez odpovědi.

Kontakty na správce Justice.cz prakticky dohledat nejdou (nebo se mi to nepovedlo).

Na obranu státních institucí musím říct, že ne všechny reagují takhle šíleně pomalu. ČTÚ jeden čas po v6 vracelo 404, opravili to po cca týdnu od nahlášení, cuzk.cz, cermat.cz, vlada.cz pro změnu měli buď zavřený port 80, nebo nedostupnou serverovou síť - ti opravili problémy myslím ještě dřív, než ČTÚ.

Občas se objeví i MTU problémy zaviněné extrémně restriktivním firewallem (oblíbené dropování ICMPv6)...

Nezbývá než správcům cpát do hlavy, že je potřeba testovat a monitorovat oba protokoly.

[Jendа]

Mají tam pravděpodobně MTU problém. Tzn. pokud doma máte šestku přes tunel, nebo váš ISP v cestě používá MTU<1500, tak vám nebude fungovat Justice ani tamní rejstřík. A nepomáhá ani úprava MSS (což třeba u o2.cz zabralo) Z firemního nativního připojení s MTU=1500 není problém.

Není to způsobené takovými těmi experty, co zakážou ICMP, takže pak nechodí pakety o překročení MTU?

[Ondrej 'SanTiago' Zajicek]

Tipoval bych, ze ano. Pred radou let jsme s tim meli stejny problem (na IPv4), tehdy jsme psali kvuli tomu desitkam (komercnich) serveru, odepsal snad jediny a ani ten to neresil, takze se to nakonec resilo upravou MSS pomoci iptables.

[pavlix]

IPv4 má tenhle problém horší o to, že má DF bit.

[Ondrej 'SanTiago' Zajicek]

Pokud vim, tak IPv6 se chova vicemene stejne jako IPv4 s nahozenym DF bitem a dnesni implementace IPv4 obvykle pouzivaji nahozeny DF bit, takze v tomhle ohledu nevidim rozdil.

[pavlix]

Nevím, jak dnes, ale ve své době Windows nahozený DF bit nepoužívaly, takže pokud byla síť testovaná s windows, tak se problém týkal pouze alternativ.

[zajdee]

Asi. A ještě tam nejspíš mají extrémně pomalou reverzní proxynu, která požadavky po IPv6 proxuje na IPv4 adresu webserveru.

Po roce jsem se tedy dokopal k tomu, abych zkusil dohledat kontakt. V Linksu se mi web nakonec načetl, ale jediný použitelný mail je na podatelnu Ministerstva spravedlnosti. Tak jsem sepsal popis problému, poslal ho tam a uvidíme, jak to budou řešit.