Přestaňme už konečně řešit IPv4 – kde je sehnat, kdo jich kolik nasyslil a kolik ještě půjde přeprodat. Tohle není budoucnost, to je jen drahé udržování minulosti při životě.
Budoucnost je dostupná **už dnes** a jmenuje se **IPv6**.
Ne „jednou“, ne „až bude čas“, ne „až to budou podporovat všichni“. Podpora tu je, funguje to a ve velkých sítích už dávno běží.
Místo spekulací nad tím, kdo vlastní milion IPv4 adres, bychom se měli soustředit na:
* návrh sítí bez NATu
* end-to-end konektivitu
* jednodušší architekturu
A buďme upřímní: největší brzdou dnes často nejsou technologie, ale **síťoví administrátoři**, kteří se drží zažitých postupů a odmítají změnu, i když nástroje i znalosti už dávno existují.
Vývoj standardu IPv4 byl dávno zastaven. Jakékoliv pokusy o jeho „resuscitaci“, ať už dalšími úpravami nebo snahou o „lepší“ přerozdělování stávajících adres, jsou jen **pálením peněz a energie**. Směr už se nezmění a snaha ho ohnout nemá smysl.
Takže méně nostalgie po IPv4 a víc odvahy začít používat to, co máme k dispozici už teď.
Tohle je nesmysl hned z několika důvodů.
Za prvé, kdo je "běžný uživatel"? Je to kdokoliv, kdo neví, co je IP adresa, nebo jakýkoliv koncový zákazník?
Za druhé, mělo by snad být v pořádku a dobrá praxe za všech okolností nasypat veškerá zařízení v síti do jedné jediné podsítě bez rozumné možnosti je izolovat?
Za třetí, proč by tohle měli proboha zpoplatňovat? Z jakého titulu? Náklady na přidělení opravdu velkých bloků (bavíme se o něčem kolem /30) jsou v přepočtu na jednu trochu rozumnou podsíť (alespoň /56) zanedbatelné, takže není žádný rozumný důvod to nezahrnout do samotné ceny služby. To je buď ignorance nebo snaha nahrabat další peníze ( za IPv4 adresy, které jsou ale opodstatněné jejich nedostatkem), žádný ospravedlnitelný důvod to nemá.
To je podle mě právě základní omyl IPv6 aktivistů / NAT haters hnutí. V jejich teoretickém světě to funguje perfektně, každý jednoduše dostane kolik adres potřebuje, protože to protokol umožňuje a to přece stačí.
Ale my žijeme v reálném světě s reálnými lidmi a tam je to horší. Výhodou NATu není ani tak řešení problému nedostatku IPv4 adres celkově, ale možnost udělat si síťovou architekturu za tím podle svých potřeb bez toho, že se musím s někým dohadovat a zdůvodňovat mu, proč to potřebuju zrovna takhle a ne podle jeho knížecích rad.
5. 1. 2026, 16:41 editováno autorem komentáře
když dostanu od providera víc než /64, tak natovat nemusim, ale můžu když budu chtít a možnosti udělat si to podle svých představ jsou větší než když dostanu /64, tam se můžu dostat do stavu, že to bez natu nejde i když ho nechci. Nevidim jedinej důvod, proč bych pro přidělení třeba /56 měl něco někomu zdůvodňovat. ISP na to má těch adres dost
Výhodou NATu není ani tak řešení problému nedostatku IPv4 adres celkově, ale možnost udělat si síťovou architekturu za tím podle svých potřeb
To můžete s IPv6, které vám dává mnohem víc možností, než kolik máte s NATem.
bez toho, že se musím s někým dohadovat a zdůvodňovat mu, proč to potřebuju zrovna takhle
To ale není problém IPv6. To je problém těch, kdo u ISP rozhodnou, že se v rozporu se standardy bude přidělovat méně než /56.
Když na to nemám dost adres, tak nemůžu.
Děkuji za hezkou živou ukázku onoho mylného technokratického přístupu, o kterém jsem mluvil. Dost mi to připomíná jednu aktuální situaci z jiného oboru, kde dost lidí tvrdí, že co dva týdny zastavený koridor v Roudnici není problém nevhodně použité hákovnice, ale strojvedoucích, kteří nezvládnou včas stáhnout sběrač. Stejná ignorace lidského faktoru problému.
Když na to nemám dost adres, tak nemůžu.
2121 IPv6 adres v V fc00::/7 vám nestačí? Chcete tvrdit, že v IPv4 síti máte těch adres k dispozici víc?
Děkuji za hezkou živou ukázku onoho mylného technokratického přístupu, o kterém jsem mluvil.
Já myslím, že je to spíš hezká živá ukázka IPv6 haters / NAT hnutí. Prostě vychvalujete svůj IPv4 NAT do nebes a nepřemýšlíte nad tím, jestli to, co píšete, náhodou není nesmysl.
Stejná ignorace lidského faktoru problému.
Ale nikdo přece netvrdí, že lidé jako vy nebudou dělat IPv6 problémy. Budou. Ale to není problém technologie. Vy byste dělal problém čemukoli novému. A vy nebo někdo vám podobný by dělal problémy i kdyby Pentagon uvolnil třeba 6.0.0.0/8, protože zařízení v jeho síti přece s Pentagonem nekomunikujíj, tak začal tyto adresy používat ve své síti.
To je hezké, že "mám" dostat. Ale mnohdy nedostanu - o tom je tenhle thread.
Ale tak v tom případě si stěžujte na svého ISP. Mám IPv4 adresy někdy od roku asi 2003 a už tehdy si lidé stěžovali, že mají nat a nejedou jim peer-peer služby. Hned po škole jsem chvíli pracoval u ISP a každý zákazník dostával samozřejmě vlastní IP adresy. Prostě slušný ISP rozdává co má rozdávat.
Dnes má každý ISP /32 a může rozdávat /48 nebo /56 v podstatě v neomezeném počtu a pokud mu adresy dojdou, tak dostane další /32.
Dnes ma ISP dokonce /29 - od roku 2012 si o to staci rict. Jen to teda soucasne neznamenalo vraceni te "minimalne /48" k end-userum (ad nize) ;-) Jinak teda spis nez plac v diskuzi zde bych vam doporucil se vrhnout na IPv6 WG... :) Je to otevrene, zmenu politiky tam muze navrhnout fakticky kdokoliv.
Jo, bejvavalo, aktualni RIPE politiky rozhodne tak striktni nejsou. Uz v roce 2007 se v politikach objevilo, ze minimum je /64 - a v teto podobe to tam vydrzelo az do roku 2020, teprve pak se tam objevilo to "n-krat" s odkazem na BCOP, ktera na domaci pripojky mj. pripousti /56.... a delsi se sice "durazne nedoporucuje", ale zakazane to jaksi take neni. Zmineno tam je i minimum doporucene broadband forem (/60). A dokonce tam mate zminene i mobilni telefony kde se ta /64 bere explicitne jako postacujici.
Tim chci rict, ze to s tou /48 rozhodne tak jednoduche neni a samotny vyvoj RIPE politik (kterymi se nas region ridi) to jen doklada. Muze se nam to nelibit, ale tak to proste je. Ten striktni pozadavek na /48 vysumel uz davno tomu.
Tak moment. IPv6 aktivista nejsem ani omylem. Osobně za jedinou výhodu IPv6 považuji enormní adresní prostor, zbylé "vlastnosti" oproti IPv4 spíš za složitosti a potenciální komplikace (čímž si také vysvětluji, proč nasazení trvá tak dlouho). A s NATem v principu taky nemám problém, problém mám s tím, když potřebuji někde veřejnou adresu a nejde to, jde to složitě, nebo to je drahé. To by IPv6 mělo teoreticky řešit - kdyby ISP nebyli naprostí diletanti.
Slozitost? A v cemze presne? :-) Vzdyt zakladni hlavicka IPv6 se jednodussi nez u IPv4. Vlastnosti extension header vubec nemusim pouzivat, pokud je nepotrebuju, tim "next" headerem muze byt rovnou TCP hlavicka, zejo. A co jsou v IPv4 v hlavicce promenne delky treba takove "option", hmm? To razem tu IPv4 hlavicku mate ne 20 bajtu... ale treba 60 :-) Ono spis lidi neznaji slozitosti a temna zakouti IPv4, kdyz hovori o "slozitosti" IPv6.
> Výhodou NATu není ani tak řešení problému nedostatku IPv4 adres celkově, ale možnost udělat si síťovou architekturu za tím podle svých potřeb bez toho, že se musím s někým dohadovat
Jo, aspoň do chvíle kdy potřebuju VPN někam jinam a začnou mi kolidovat adresy sítě. A ještě to přidá opruz s nutností port forwardu místo triviálního otevření firewallu. A že to běžný uživatel nepotřebuje? Třeba multiplayer hry od Nintenda se připojují P2P.
NAT v IPv6 bolo dlhu dobu nedporucovane, a nepotrebnost NAT bol uvadzany ako jeden z dovodov na prechod k IPv6.
Potom sa objavil NAT66, ktory bol dlho v experimentalnom stave. V tom je snad dodnes? (Neviem, naozaj sa pytam, konkretne toto nesledujem).
V kazdom pripade viem, ze ked si kupim bezny Mikrotik/Ubiquiti/whatever, tak tam NAT66 nerozchodim.
Nedoporučované je to stále, protože pro drtivou většinu use-case, kde by někdo chtěl s IPv6 použít NAT, existují podstatně lepší řešení, než je NAT. Nicméně pokud ho někdo opravdu použít chce, může. Ale nemůžete se divit, že když se někdo chce střelit do kolene, nenajde k tomu vhodné prostředky v každé trafice. Pokud máte opravdu tak specifickou situaci, že je nejlepší řešení NAT, pak stejně nebudete používat běžná SOHO zařízení.
Lokalita, kde je v lan víc oddělených sítí a celé je to připojeno LTE jednotkou od mikrotiku, která dostane jednu IPv6 adresu. Plus je tam ještě jedno připojení přes hodně mizerný adsl připojení použitelné jen jako hodně nouzová záloha v případě výpadku LTE. Tak by mě zajímalo, jak by se to dalo řešit bez NAT
Předpokládám, že se ptáte spíš na hotfix, ne na dlouhodobé řešení. Jako hotfix mne napadá ten NAT nebo VPN někam, kde je normální implementace IPv6.
Řešení je samozřejmě tlačit na operátora, aby poskytl normální IPv6 a poskytoval to jako standard. A pokud bude tvrdit, že to neumí, tak zveřejnit jeho jméno, ať všichni vědí, komu se vyhnout.
V idealnim svete :-) Ale jak patrno vyse, pravidla a politiky jsou gumove a umoznuji dlouhodobe tem ISP byt vselimozne kreativni. Navic ono ani s tim "libovolnym" pridelovanim to neni tak jednoduche... s tim, jak dochazeji IPv4 se v ramci RIPE objevuje tlak na to diverzifikovat platby podle "velikosti" a poctu alokovanych zdroju (tedy vratit se k modelu, ktery se pred lety opustil) - ale soucasti toho napadu je mj. tez i zpoplatneni dle toho, kolik IPv6 LIR alokuje. Jakapak bude asi ochota "rozhazovat" a k tomu zdarma, kdyz se to z druhe strany casem muze odrazit na vysi poplatku?
Byl to navrh, co neprosel... zatim. Ale je to proste prvek nejistoty, ktery tu je a ktery muze byt prekazkou v tom "byt stedry". Ono RIPE NCC se svymi dnesnimi 41 miliony EUR vydaju rocne holt take hleda zdroje sveho financovani... a pokud se skutecne vydame cestou zpoplatneni dle alokovanych zdroju, tak uz ani to rozhazovani s IPv6 bude mit dopad na kasu ISP. A byt se dnes klade duraz spise na zpoplatneni IPv4, ta karta se jednou taky muze otocit, az se stane jednou IPv4 rekneme obsolentni (byt je to asi jeste daleko).
Nejvíc by se mi líbilo, kdyby byl poplatek odvozený od počtu IPv4 adres dělený změřeným IPv6 provozem. Aby byli ISP finančně tlačení k tomu, aby se v jejich síti IPv6 používalo (ne že jen někde deklarují, že IPv6 podporují, ale uživatelům pak hází klacky pod nohy).
Zpoplatnění podle množství alokovaných adres je logické (proč by měl malý ISP platit stejně, jako někdo tisíckrát větší), ale dá se to vyvážit nějakými požadavky. Třeba právě požadavkem na politiku přidělování koncovým zákazníkům – že ISP musí přidělovat minimálně /56, jaká je politika přidělení většího rozsahu. Jistě, znamenalo by to trochu nárůst administrativy na straně RIPE NCC – ale to to nemusí kontrolovat aktivně, může jednat až na udání, že nějaký ISP pravidla nedodržuje.
Až na to, že zpoplatnění adres jde proti myšlence, že adres je dostatek a není jimi třeba šetřit.
Navíc, jak vůbec nastavit ceny. Lineárně to být nemůže. Z pár drobných u /64 by byl u /32 brutální ranec.
Strašně by záviselo na nastavení a hlídání pravidel. Protože ISP by samozřejmě operovali v těch nejlevnějších částech šedé zóny.
A ten udaj o "zmerenem" IPv6 provozu se vezme kde? Z dat toho, co zverejni Cloudflare ci Google fakt nejde automaticky dovozovat vubec nic, to je udaj priblizny a ciste orientacni... a RIPE zadne takova data nema, urcite ne v kvalite, na zaklade ktere by bylo mozne jakkoliv navazat na billing.
A jinak viz vyse, policy development je otevreny proces, nic vam nebrani tam ty svoje "napady" predlozit. I samotna policy k IPv6 je dokument, co ma dnez uz dvacatou patou verzi. A ze to neni proces vubec jednoduchy jde demonstrovat mj. prave na tom, ze nejen ze vypadla zminka o minimu /48, ale neni tam ani to /56, ale horkotezko jen ten odkaz na dalsi dokument, ktery nahradil to puvodni "minimum je /64". Ono holt nalezeni konsensu neni zas tak jednoduche, jak se na prvni pohled muze jevit. Klidne si to vyzkousejte :-)
A ten udaj o "zmerenem" IPv6 provozu se vezme kde? Z dat toho, co zverejni Cloudflare ci Google fakt nejde automaticky dovozovat vubec nic, to je udaj priblizny a ciste orientacni... a RIPE zadne takova data nema, urcite ne v kvalite, na zaklade ktere by bylo mozne jakkoliv navazat na billing.
Ty údaje má k dispozici daleko víc subjektů. A ty údaje přesné být nemusí, protože je úplně jedno, jestli by ten ISP platil celkově o jeden cent víc nebo míň.
Běžnému uživateli těch /64 stačí
Čekal jsem to tady a nebyl jsem zklamán.
Mytickému „běžnému uživateli“ je to opravdu jedno. Asi tak, jako je mu jedno, jestli je jeho EV 800V. Hlavně je ale jeho názor úplně irelevantní, podobně jako jeho názor na brzdovou soustavu toho EV.
Takže přestaňte vytahovat tento pseudoargument a v rámci sebevzdělávání si dohledejte, jakého argumentačního faulu jste se dopustil.
Ještě štěstí že máme experta jako jsi ty. Díky tobě můžeme :
* vyhodit všechty SmartTV a telefony např. s Androidem které nepodporují IPv6
* vyhodit všechy VoIP telefony které nepodporují IPv6
* apod. vyhodit všechna stará zařízení např. tiskárny, smart home zařízení, web kamery, atd..
Jde vidět že ti jde fakt o ekologii.
Tobě asi nikdo neřekl, že "původní plán" zněl že USA + EU pojedou na IPv4 a Asie + Afrika na IPv6. Pro "euro část" 4giga WAN adres docela stačí, což znamená cca 4 adresy na každého vč. kojenců.
IPv4 zariadenia v sieti s IPv6 konektivitou nemaju problem. Zvycajne je podporovany nejaky prechodovy mechanizmus, moznosti je mnoho, od plnokrvneho dualstacku az po NAT64.
Okrem toho:
* smarttv a telefony s Androidom podporuju IPv6. Nepodporuju DHCPv6, co je rozdiel.
* VOIP telefony vyraduju ich majitelia preto, lebo su zastarale. Podpora IPv6 je pri nich bezpredmetna.
* dnesne smart home zariadenia uz byvaju aj IPv6-only (Matter).
(A to pisem ako niekto, kto vo svojej vlastnej sieti IPv6 nema a ani neriesi; nie som ani fanusik, ani hater).
Blablabla
1) Kolik aktuálních domácích routerů např. NAT64 zvládá? Když by každá domácnost měl jenom WAN v IPv6 a nikoliv v IPv4 ?
Takže to zase vyřešíme "ekologicky" že je všechny vyhodíme a všichni nakoupíme nové routery které to podporují?
2) Dobře IPv6 Android podporuje (info dle AI) :
Základní IPv6 stack Android 4.1 / 4.2
IPv6 na mobilních sítích (LTE) Android 5.0
DHCPv6-PD Android 11 (reálně až 2025 update)
Nicméně jsou pořád starší Android zařízení které nikoliv. Dokonce si myslím že má Sony TV z roku 2019 pokud bych měl WAN i LAN na IPv6 prostě nepojede(resp. bude fungovat ale nebudou mě fungovat služby se sítí). Budu muset mít na LAN i s IPv4 a na routeru NAT64 + DNS64.
1) Vsetky, ktore poskytovatel internetu dodal k sluzbe. Okrem toho, tieto mechanizmy nemusia bezat nutne na routeri. Pokial mate oblubeny historicky router, ktoreho sa nechcete vzdat, tieto sluzby vam zabezpeci aj nejaka malina v sieti.
2) Android 4.x aj 5.x su davno obsolete a to nielen moralne. Aj moja manzelka mala oblubeny tablet s 6.0 (Xperia Z3 Compact), ale ked bateria vydrzala radovo v minutach, tak to vzdala. Nas Nvidia Shield TV (Android TV, 2019) s IPv6 nema a nemal problem, takze ked vas TV nie, tak je to otazka na jeho vyrobcu, nie na Android.
Co sa tyka streamovacich sluzieb, ziadny ISP nechce byt problemom, kedze je to oblast vysoko viditelna beznymi pouzivatelmi. Obzvlast, ked im tieto sluzby prepredava.
DHCPv6 nepotrebujete; PD uz duplom nie. V Androide 11+ je to kvoli tetheringu a kontajnerom.
3) Ked mate LAN s IPv4, tak na routeri uz NAT64+DNS64 nepotrebujete. Staci DS-lite, operator vam poskytnuje AFTR servis, vy budete mat na routeri B4 (router zabali IPv4 paket do IPv6, operator ho u seba rozbali a posle do sveta). Co sa tyka podpory v routeroch, pozri bod 1.
Hej len ten vyber dost biedny a casto za zbytocne vysoke sumy.
Modemov/routrov je vela ale tych s (funkcnou) podporou DS-lite(alebo ineho prechodoveho mechanizmu) je ako safranu.
Snazil som sa najst nejaky za rozumnu cenu a nic som nenasiel. Chcel som rozbehat Orange internet vzduchom a neslo to. Ani nic rozumne som nenasiel. Skoncilo to nakoniec kupou ich 5G modemu/routra s kopou zbytocnosti, ktory dava za 7eur mesacne.
Neviem ako v pripade inych sposobov pripojenia ale v pripade internetu vzduchom su to vsetko zariadenia s custom FW. Pricom tie prechodove mechanizmy nieje ziadna raketova veda ale zariadenia s nimi niesu.
2) Ta podpora DHCPv6 je v kontextu adres /64 nezřídka přidělovaných od ISP (jak se tu zmiňuje na jiných místech v diskuzi) spíš taková parodie. Jen s DHCPv6-PD a prefixem /64. Kdyby to mělo řešit problémy s přidělováním adres od lakomých ISP (byť by to byl samozřejmě "rovnák na ohýbák"), bylo by potřeba podpory DHCPv6 bez nějakých "ale", aby nebylo třeba vůbec delegovat prefixy a aby bylo možné si postavit přidělování adres bez SLAAC a s libovolnou délkou masky.
6. 1. 2026, 23:45 editováno autorem komentáře