Vyhledávač mi na dotaz "o2 ipv6" našel tohle:
https://www.o2.cz/osobni/pevna-ip-adresa-pro-internet-na-doma
Za IPv6/64 se platí. 119,80 (včetně DPH).
čtu root.cz dlouho. Ale po velmi dlouhé době se musím ozvat.
cituji - "Nejlepší je Indie." "Česká republika je na to špatně."
Proč kazíte normální a také zajímavou informaci takovými manipulativními hodnoceními?
Co je "nejepšího" na tom, že má nědko hodně připojení přes IPV6 a ne přes IPV4?
Proč je špatně, že nám v ČR stačí k provozu IPV4?
Prostě začali jsem dříve něž Indie a proč měnit /opravovat/ něco co funguje?
To je jen o dosažení bodu zlomu. Pak to půjde skokově.
ČR je trochu specifická tím, že velká část přípojek je sociálních, bez koncového zařízení od poskytovatele, takže naplánovat zavedení je docela náročné. Obnáší to statisíce drobných kooperaci, obvykle s nějakým technickým jelitem na druhé straně.
Velcí se na to připravují, a u nich je to taky jen o vhodném okamžiku, s jakou změnou v infrastruktuře to spojí. IPv4 adresy jsou zatím ještě příliš levné, aby to bylo dostatečnou motivací.
Vidíte, a já bych naopak chtěl aby mi poskytovatel vrazil do ruky kabel s RJ45 koncovkou a já si tam mohl zapojit co chci. Jenže tu možnost nemám a musím používat křáp od poskytovatele s nevypnutelným NATem (bez možnosti bridge mode). A ještě lepší je to u rodičů kde je UPC - ta jejich věc neumí zhola nic. Statické DHCP? Nemožné. Povolení přístupu z internetu do LAN přes IPv6? Nemožné. Fakt s tímhle ať jdou poskytovatelé do (_!_).
Tak nevím, UPC mám to "nové", tj. IPv4 přes CGNAT, IPv6 veřejná.
Povolit přístup jde, je tam IPv6 firewall, kde stačí nastavit pravidlo.
DHCPv6 tam je pitomý, to je pravda - např. si přes restart nepamatuje stateful/staless mode, a ani mu nejde dát pevný záznam. Takže můj server je na IPv6 nakonfigurovaný ručně, aby mohl být v DNS a měl certifikát od Let's Encrypt.
Jo, krám mizerný to je, ale veřejná IPv6 tam funguje.
To, že firewall out-of-the-box má všechno zakázáno, je naprosto v pořádku.
Chtěl jsem po nich ten upgrade na gigabit (za 50% napořád), došly modemy a slíbili mi, že na podzim mi to dají. Tak uvidíme, co ten nový modem bude zač - ale zlepšení nečekám.
23. 8. 2021, 13:51 editováno autorem komentáře
Ono je to těžké. Kdyby se tu pronajímala/ prodávala od velkého poskytovatele skutečně dobrá a výhodná zařízení, tak by to vypadalo hodně jinak. Máme tu ale stav, že zařízení od velkých poskytovatelů mají prakticky vždy dost zásadní technické nedostatky ať už protože se např. přehřívají, nebo zahazují pakety, nebo mají opravdu mizerný firmware nebo kombinaci těchto aspektů. Některá z těchto zařízení měla problémy v dohledné době splnit závazky dané např. GPLv2, což se potom muselo obšírně řešit a k úplné spokojenosti to rozhodně nevedlo, viz https://www.phoronix.com/scan.php?page=news_item&px=Technicolor-Opens-TC72
A co si budeme povídat, ono ta Omnie nebo nedejbože LUCI/ OpenWRT apod. taky nejsou něco pro typickou českou rodinu. Zařízení typu FritzBox by byla určitým evolučním krokem vpřed, protože mají tendenci aspoň fungovat a ten firmware je docela přehledný. Bohužel jako všude, i zde je značný prostor pro zlepšení z hlediska jednoduchosti. To vše a ještě finanční situace běžné české domácnosti oproti např. Německu vede k tomu, že tu prostě nějaký zásadní vývoj nelze čekat. Jedna světlá výjimka je teda z plošného hlediska podle mě trochu paradoxně CETIN, který zvyšuje takovou tu základní laťku na poměrně pěknou úroveň, když od nich máte FTTH.
Protože bylo mnohokrát vysvětleno, že to nestačí. Nestačí to k dalšímu rozvoji internetu. IPv4 adresy dávno došly, není možné běžnou cestou získat další. Jejich cena na volném trhu letí prudce vzhůru, za dva roky se zdvojnásobila. To společně se spekulanty zhoršuje dostupnost adres a ty pak zdražují i pro zákazníky. Způsobuje to kromě jiného také další centralizaci internetu, nahrává to velkým globálním hráčům, kteří mají miliardy dolarů na nákup vzácných adres. Spustit dnes vlastní větší projekt je problém, protože za adresy budete draze platit. Bude hůř, dokud nepřejdeme plně na IPv6, kde tyhle potíže zmizí.
Třeba vlastní datacentrum, poskytovatele připojení nebo větší projekt poskytující obsah. Nedostanete se k většímu množství IPv4 adres.
Já třeba některé servisní servery čistě na IPv6 provozuju, ale nejde to s těmi, kam chodí uživatelé. Právě proto, že oni se na IPv6 nedostanou. Jen proto je potřeba držet se IPv4, jiný důvod dávno není.
Odříznout si dobrovolně 85% zákazníků ?
Nevím, jestli by jich bylo 85%. To záleží na typu projektu.
Když na to koukám z pohledu běžného uživatele, tak proč bych chtěl IPv6, když mi IPv4 funguje? Abych byl cool? Nebo abych byl solidární s projekty, na které se nedostanou IPv4 adresy? Musel by to někdo vnutit jako jízdu vpravo nebo digitální pozemní vysílání.
Přesně. Drtivé většině lidí je nějaké IPv4 či IPv6 naprosto srdečně jedno stejně, jako je jim jedno, že jsou za pěti NATy.
Mně je to osobně ostatně jedno taky a to fakt nejsem drtivá většina lidí. Co potřebuju, to si naforwarduju přes VPN z VPS za 80 Kč za měsíc. Mě může potenciálně postihnout to, že mi provozovatel toho VPS zpoplatní veřejnou IPv4 adresu. Ale to většinu lidí fakt netrápí.
Zásadní chyba je už ve zcela zcestné představě, že to funguje. Nefunguje. IPv4 adresy nejsou a kvůli tomu se prasí podobné věci, jako je několikanásobný NAT... Ale v situaci, kdy se najdou i lidi, kteří spravují třeba školní sítě a myslí si, že NAT je dobrá metoda zabezpečení vnitřní sítě, tak je darmo o tom mluvit.
Situace v ČR je vzhledem k zavádění IPv6 objektivně špatná - zavádí se málo a pomalu a je zcela nedostatečná osvěta, která by vysvětlila, proč je nezbytné na novější systém adresování přejít - vy jste toho důkazem.
Věci fungují, pokud uspokojují zákazníka a ten je ochotný platit takovou cenu, že se jinému vyplatí službu poskytovat.
Řeči o NAT a zabezpečení jsou dobré do technického fóra, ale technici by měli přestat být nabubřelí. Funguje to, co lidi kupují. Nejlepší je to, co kupují nejvíc. I ten technik je z peněz vydělaných tímto principem placený.
IPv6 je po patnácti letech pěkný průšvih. Mohlo by to vstoupit do učebnic, jak se technologie zavádět nemá. Přesto se dokola píše o tom, kdo jiný za nezájem o IPv6 může.
Teď už bych si klidně vsadil na to, že její rozšíření je už nezastavitelné. Před pěti lety bych si to netroufl.
V dobe, kdy vsechny bezne sluzby kvuli vsudypritomnemu IPv4 NATu nepouzivaji peer to peer spojeni, ale vsechno tlaci skrz ruzne prehlcene prostredniky, skutecne vetsina uzivatelu nepotrebuje pristupovat z telefonu k domacimu pocitaci/serveru,
To neznamena, ze bychom se se soucasnym stavem veci meli nutne smirit. Byly doby, kdy peer to peer spojeni bylo normalni. Zaslapal je IPv4 NAT.
Ja se bezne pripojuji k domacim zdrojum. Nebo ke zdrojum, ktere kvuli NATu nejsou z IPv4 internetu primo dostupne, zatimco v IPv6 internetu dostupne jsou.
NAT hole punching nie je zdaleka jediny sposob. Su aj novsie napr. ICE https://datatracker.ietf.org/doc/html/rfc8445
Lepsie riesenie je ale sprevadzkovat vlastny VPN alebo PROXY server, napr. na aws. Vyjde to na niekolko desiatok kc za mesiac. Len treba vediet ako. To ako staci vediet aj ako googlit, myslim ze clanok venujuci sa tejto teme vysiel aj tu na roote...
ICE je zase jen o UDP.
Routovani vybraneho provozu do vnitrni site skrz VPN je mozne, ale pokud ve vnitrni siti chcete videt zdrojovou IPv4 adresu provozu a prizom neroutovat vsechen odchozi provoz skrz VPN, musite nasadit source routing. To rozhodne neni bezny skill.
Proxy asi fungovat bude, pokud mate proxovatelny provoz, ale nedej boze, aby nekdo na ten AWS-proxovany endpoint zacal utocit. To pak k Vam domu zacne odchazet spousta provozu, ktery je v pripade AWS placeny. Pri konstantnich 25 Mbps (nemusite si vsimnout) je to 7 TB mesicne, z Frankfurtu za $645 (tvrdi AWS pricing calculator; bez slev).
A to jsme u dalsiho problemu: je to ve Frankfurtu, coz pridava dalsi latenci.
VPN/PROXY jsou v tomhle pripade proste jen rovnak na ohybak (NAT). (Been there, done that.)
> V dobe, kdy vsechny bezne sluzby kvuli vsudypritomnemu IPv4 NATu
> nepouzivaji peer to peer spojeni...
Nepleťte si NAT a firewall. Ty krásné doby, kdy se běžně používalo P2P spojení pamatuju, to bylo před rozšířením firewallů. I kdybychom přešli komplet na nenatované IPv6, tak se nevrátí, protože firewally zůstanou a dál budou blokovat spojení. BFU si ho nenastaví a standardy pro jeho vypnutí "zevnitř" existují, ale (jako u NATu) nefungují vždy a všude.
Ja si NAT a firewall nepletu.
Rozdil mezi svetem IPv4 a IPv6 je ten, ze v pripade IPv6 sveta peer to peer spojeni je technicky mozne pro vsechny protokoly, pokud se povoli na firewallu. U IPv4 nekdy/mozna/snad pro nektery druh NATu a jen pro UDP provoz. Pripadne s rucnim nastavenim DNATu, pokud je ten NAT ve Vasi sprave (coz casto neni),
(Ano, "otevirani firewallu" pro IPv6 je sice v UPnP podporovano, ale typicke domaci routery ho nejspis funkcni nemaji, tady je co zlepsovat.)
Ano, je jim to jedno. Oni to jen potřebují zapojit a aby to fungovalo.
Stejně je většině lidí jedno, co je v kódu na vajíčkách - pokud se nesetkají s drastickou realitou klecového chovu.
Kdyby každý mohl používat jen to, čemu rozumí, většina lidí by ani nemohla telefonovat.
Neznamená to ale, že nepocítí důsledky. Jedním z nich je, že třeba každá kamera komunikuje přes server výrobce - a až ten zkrachuje nebo to jen vypne, kameru si můžou strčit za klobouk.
Když jsem si před necelým rokem dělal průzkum o možnostech připojení ve vesnici na Vysočině, vyšel mi nejlépe T-mobile (DSL). Dával jednu veřejnou IPv4 a IPv6 /56, vše zahrnuto v paušálu. Modem nic moc, ale přihodili k němu LTE modem jako záložní spojení, což se osvědčilo při výkopových pracích v ulici.
Ok, povedzme ze to urobime nenormalne.
Aby fungoval NDP tak kazdy interface dostane link local adresu z rozsahu fe80::/64. Takze pravda je ze v jednom L2 segmente nemozem mat viacero subnetov z ktorych kazda by mal vlastnu branu. Pretoze SLAAC. To ale neznamena ze adresy ktore sa pridelia musia byt nutne podmaskou /64. Nepomoze ani to ze zapnem stateful konfiguraciu, pretoze DHCPv6 nevie oznamit klientovi adresu brany, tu sa dozvie len cez NDP, takze zase SLAAC.
To vsetko ale neznamena ze L2 segment musi mat prideleny prefix s maskou /64. Link-local adresa bude mat vzdy masku /64. Takze to znamena, ze pre jeden L2 segment je pouzitelna siet s maskou najvic /64, nie prave. Ak budem mat na linke router s prefixom 2001:db8::/96 tak ho tak klient pri prefix discovery dostane a nastavi adresu z rozsahu 2001:db8::0 az 2001:db8::ffff:ffff.
Cize nakoniec budem mat L2 segmente minimalne 2 podsiete:
jednu s prefixom fe80:: a maskou prave /64
druhu s prefixom 2001:db8:: a maskou /96
V konecnom dosledku to znamena ze na jeden L2 segment mozete pridelit aj prefix 2001:db8:: s maskou /32 ale maximum adries v tom L2 segmente nepresiahne 2^64 pretoze link-local ma masku prave /64.
Takze ak vam poskytovatel da prefix 2001:db8:: s maskou /64 tak si ho kludne mozete rozdelit na 2 siete s prefixmi 2001:db8::/65 a 2001:0db8:0:0:8::/65 len pre to aby to fungovalo tak potrebujete dva L2 segmenty. Alebo link-local adresy rucne konfigurovat tak aby boli rozdelene do 2 subnetov. Pretoze SLAAC.
Tak přiznám se, že jsem v původním příspěvku měl na mysli autokonfiguraci (SLAAC) s prefixem /64.
SLAAC nemá na link-local adresy žádný dopad, ty jsou vždy s maskou /64. Bavíme se o globálně routova(tel)ných adresách z prefixu 2000::/3, tedy např. 2001:db8::/64.
SLAAC démon (třeba radvd) často technicky umožňuje nastavit i jinou masku než /64, klidně /65. Pak by se z jednoho přiděleného bloku o velikosti /64 daly udělat dvě podsítě o velikosti /65, tj.:
- 2001:db8:0:0:0000::/65
- 2001:db8:0:0:8000::/65 (Vám asi vypadlo pár nul)
Klidně můžete mít i SLAAC s prefixem /56 i větším, a např. v OVH to tak jeden čas dělali (nevím, jestli to takhle prasí pořád). Ale není to standardní a není garantovná funkčnost.
Problém je v tom, že u takhle ohnuté konfigurace nemáte garanci, že jí bude rozumět každé zařízení v síti, a že ji přijme. Existuje sice RFC draft, který by umožnil proměnnou délku prefixu, ale zatím je to stále jen draft - a i kdyby vyšel jako RFC, tak potrvá roky, než taková funkcionalita bude možná.
(I když to RFC draft v sekci 8 explicitně zakazuje, nakonec by jeho schválení nejspíš stejně vedlo k prasení, kdy operátoři budou přidělovat /120 na domácí síť, protože k čemu /64, když 256 adres musí stačit každému...)
https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/
(Kde se nepoužívá SLAAC, ale nějaká jiná forma provisioningu/konfigurace adres, tam můžete mít prakticky libovolnou masku sítě, klidně /126 nebo i /32. To samozřejmě neznamená, že do jedné L2 sítě připojíte 2^96 strojů a všechno bude fungovat.)
Mate svym zpusobem pravdu. Nejsem si ale jisty, jestli v drivejsich RFC nebylo, ze se bude /64 pridelovat a pak se to nemenilo.
Ja se spis pozastavuji nad tim, proc je proste podle toho RFC 18,446,744,073,709,551,616 adres vice nedelitelnych pomoci autokonfigurace. Je to az za mym routerem, nikoho tim neobtezuju, navenek mam porad /64. Mam takovehle mnozstvi adres, ale pouze pro jednu podsit (stale mluvime o SLAAC). Nerikam, ze by se nutne melo adresovat az nekam /127, ale proste /64 je docela extrem.