Vzdy jsem myslel/doufal, ze GNU/Linux je v podobnych vecech dost napred.
Viz treba historicky Interner Explorer.
Nevím ale Linuxové GUI mě přijde použitelnější než Windows GUI. A podporu podnikových aplikací? Co si představujete pod "podnikovými" aplikacemi. Jestli např. office, tak můžete třeba používat GSuite, ten funguje všude. Pokud centrální autentifikaci/autorizaci tak OAuth + ldap/kerberos/whatever.
Řekl bych že to je spíš problém výběru nástrojů a případně výrobců že to nepíšou přenositelně a zamrzli v 90-tkách než problém Linuxu (navíc dnes je téměř standard že všechny aplikace (až na specializované, třeba grafika, CAD, videoeditory etc. -- i když to taky už není zcela pravda) mají webový ksicht -- nebo můžou mít kdyby výrobci nezamrzli v 90-tkách -- který funguje všude).
Těch 95% uživatelů mimo linixovou bublinku to vidí jinak. Linux na serverech a iot je skvělý, na desktopu hodně slabý.
By me docela zajimalo, k cemu je to dobry ... nevidim jednak zadny vyuziti, druhak nevidim ani zadnou moznost ze to bude fungovat (pokud teda soudruzi z MS nebudou veskerej traffic posilat k sobe).
Je to dobré pro stavbu sítě, kde běží jen IPv6 a přístup do světa IPv4 je realizován jako služba na okraje sítě. Zařízení pak o IPv4 nic nevědí a pomocí DNS64 se jim tvrdí, že celý svět má IPv6 adresu.
Problém nastává, když potřebujete provozovat nějakou starou aplikaci, která vyžaduje spojení po IPv4. To v takto organizované síti není možné realizovat, protože na rozhraní není vůbec nastavena IPv4 adresa. Proto je na koncovém počítači (kde běží ta aplikace) tento zmíněný CLAT, který na rozhraní nahodí vlastní IPv4 adresu, pohltí všechnu komunikaci na ni a pošle ji přes IPv6 do sítě. Pro okrajové případy se tak emuluje plnohodnotné prostředí obsahující IPv4.
Funguje to překvapivě dobře, existují ve světě mobilní sítě, které takhle fungují a pokud se na mobilu spustí nějaká aplikace vyžadující IPv4, tak to krásně funguje, přestože mobilní síť o žádné IPv4 nic neví.
"Je to dobré pro stavbu sítě, kde běží jen IPv6 a přístup do světa IPv4 je realizován jako služba na okraje sítě"
Az na ten drobny detail, ze presne k tomuto to vubec neni. Clat nema zhola nic spolecnyho s provozem 6to4 GW.
Pricemz kdyz potrebuju provozovat 4kovou aplikaci, dam ji 4kovou konektivitu, klidne prostrednicvim nejakyho tunelu, kterej muze bezet po v6.
Jinak bych chtel videt tu mobilni aplikaci dozadujici se v4 adres ...
Jenže ten klient s mobilem na mobilní síti žádný tunel stavět nechce a operátor nechce provozovat dual-stackovou síť s IPv4 konektivitou, protože to znamená udržovat dvě sítě. Tohle je přesně k tomu, aby existovala jen jedna síť s IPv6 a klienti ji dokázali použít správně ve všech případech, aniž by něco museli dělat.
Operátor, jehož zákazníci si pro fungující přístup přes IPv4 pro staré aplikace musí u sebe instalovat nějaké speciality, je ve značné konkurenční nevýhodě. Navíc když ty nutné speciality nebudou zákazníkům fungovat na jejich existujících zařízeních tak mu zákazníci rychle utečou. To je důvod proč operátoři radši provozují dual stack jako ověřené fungující řešení (což je víc práce pro operátora, ale míň práce pro zákazníky a o ty jde především).
Az ti zakaznik, ktery pozaduje pripojeni na jeho sluzbu, da misto fqdn pouze ipv4, tak velmi rychle zjistis, proc to potrebujes.
Velmi rychle zjistuju, ze pro konektivitu k cemukoli na ipv4 nepotrebuju zadny clat, protoze proste funguje ... uplne vsude.
Navic ty zjevne vubec nevis o cem se tu vede diskuse. Protoze tady se bavime o tom, ze na OBOU stranach jsou v4 aplikace a MEZI nima je v6 ONLY sit. Coz znamena, ze na OBOU stranach musi byt neco, co bude ten v4 provoz zabalovat a vybalovat z v6 provozu. Coz znamena provozovat neco jeste silenejsiho nez je NAT.
Ne, na obou stranách bude většinou jenom IPv6 a jenom pro nějaký obskurní server, který neumí IPv6, se využije CLAT jako služba.
To jiste, chapes to uplne spravne ... a proto to MS dodava do klientskych widli ... lol.
Takze pro ty co nezvladaj jednu vetu ... bavime se tu o prekladu 4to6to4. Na OBOU stranach se primarne komunikuje Z a DO v4 site. A mezi nima je v6 sit.
A kdyz ... budu adresovat 4kovou adresu ... tak ji muzu previst na 6tku ... to neni problem. Jen chci videt, KAM mam ten paket poslat ??? Kam poslu pakety s adresou ::ffff:0:0/96 ??? No jiste ... uzasny ... musim mit nekde krabici, ktera MA ipv4 ze?
Takze znova, kcemuj je to dobry? A odpoved je, ze naprosto knicemu! Proc bych ty veci ktera potrebuje 4kovou konektivitu tu 4ku nedal? Je to o rad jednodussi a o 10 radu spolehlivejsi. Nemluve o tom, ze to ve skutecnosti resi problem na tema kdy bude 30tyho unora uplnek, protoze o asi tak 10 radu castejsi problem je ten, ze najaka ta krabice v6 vubec neumi. Klidne i vcera dodana.
Cílem celé té věci je, aby síť poskytovatele připojení a moje síť mohly jet čistě po IPv6. Takové sítě existují a používají se a budou pravděpodobněji čím dál častější. Celé mobilní sítě takhle fungují. Telefon nemá čtyřku, baví se pouze po šestce. Cílem je jednodušší síť.
Může se ale stát, že mám na tom zařízení aplikaci, která čtyřku vyžaduje. Pak je na tom zařízení CLAT, který čtyřkový provoz zabalí do šestky a pošle. Na okraji operátorovy sítě je dostupná konektivita jak do IPv6, tak ale i do IPv4. To je místo, kde se ten provoz vybalí a pošle se normálně po IPv4 do starého světa.
Aplikace o tom neví, protože jí to zakryl místní CLAT. Síť to ale řešit nemusí, protože ta je stále na šestce. Tohle může dobře fungovat v mobilní síti, protože jak Android, tak iOS ten CLAT mají. Kdyby to neměly bude většina věcí fungovat správně, protože těm stačí šestka. Jen malé množství aplikací tu čtyřku bude potřebovat.
Totéž ale může platit o programech na počítačích, které se můžou chtít v síti pouze s IPv6 spojovat na čtyřkovou adresu. V macOS je tohle zvládnuté, protože tam CLAT je. Uživatel si ničeho nevšimne. Řeší se to teď ve Windows a v Linuxu, aby to bylo dotažené i tam a uživatelé neměli problém s několika aplikacemi.
Druhým řešením samozřejmě je používat v síti dual-stack, ale to si třeba jako klient mobilní sítě moc vybrat nemůžu. Tam to za mě určil poskytovatel. Doma si vybrat obvykle můžu, ale bylo by mi příjemnější nemuset řešit dvě sítě. Proto je vymyšlený CLAT, je to ověřená věc a funguje to. Pokud nemám žádnou aplikaci, která by vyžadovala výhradně čtyřku, pak CLAT vůbec není třeba.
11. 6. 2026, 22:57 editováno autorem komentáře
Tohle je mnohonasobne horsi nes NAT a dualstack (kterej ve skutecnosti je daleko mensi problem nez ten NAT). NAT je problem proto, ze to na ty NATujici krabici meni IPcka paketu, tohle je radove horsi, protoze se to deje na klientech.
Řada provozovatelů sítí si nemyslí, že je 464XLAT horší než dual-stack, právě proto, že chtějí mít jednodušší síť a nechtějí se starat o dva protokoly. Ale samozřejmě ta možnost tu pořád je, pokud vám vyhovuje dual-stack, tak ho používejte. Je tu jen nabídka jiného řešení.
CLAT je každopádně jen pro pár podivných aplikací, které nepoužívají DNS, ale trvají na spojení na IPv4 literály. Moc takových ale naštěstí není, takže drtivá většina provozu projde po IPv6 a nemusí nic řešit.
Slušná aplikace se ke slušnému serveru využívajícímu IPv6 připojí přímo bez překladu čehokoliv, takže všechny tyhle pomocné vrstvy obejde a prostě se komunikuje. Všechny zmíněné věci jsou jen přechodovými mechanismy, které budou postupně nahrazeny přímou komunikací po šestce. Tím se bude provoz zjednodušovat, překlady méně zatěžovat, až tu zůstanou pro velmi okrajové případy.
To není úplně pravda že to řeší problém na téma 30tyho února úplněk ...
Před několika lety jsem zkoušel IPv6 only síť doma. Přesně z důvodu jaký se tu píše: proč bych se měl starat o dvě sítě? Dvoje adresování, dvoje nastavování pevných IP adres na DHCPku u věcí které nechci aby měnili IPčka, složitejší firewall, nat, port forwardy etc.
Pohořel jsem na třech věcech:
- tehdy jsem dělal ve společnosti která měla v konfiguraci Jitsi IPv4 natvrdo. To šlo vyřešit, prosadil jsem si i IPv6.
- Horší byl Steam který do dneška má otevřený bug že nefunguje na IPV6 only. A to ani když používáte věci jako DNS64 a NAT64 (nehledě na to že DNS64 má jiné problémy, třeba DNSSec).
- SLAAC na Androidu a nefunkčnost DHCPv6
Dneska díky CLATu bych vyřešil první 2 problémy a třetí mě už netrápí, protože jsem díry na firewallu mezi VLANy vyřešil jinak