Vlákno názorů k článku Univerzitní eduroam pouze na IPv6: CLAT, DHCPv6 a logování od Ondřej Caletka - Několik poznámek: Doména ipv4only.arpa existuje ve veřejném DNS, o...

• Doména ipv4only.arpa existuje ve veřejném DNS, o přidání správných AAAA záznamů se postará DNS64. Nevidím žádný důvod, proč zónu lokálně přepisovat vlastní autoritativní zónou.
• S tím souvisí, že objevování NAT64 prefixu pomocí DNS je dnes již překonané, ta správná cesta vede prostřednictvím volby PREF64 v ohlášení směrovačů.
• Kea a VRRP: nemyslím si, že je to zamýšlený způsob použití. Při zapojení do stejné podsítě jako klienti stačí jednoduše nechat běžet obě instance. Při použití relay agenta by měl relay agent předávat DHCP zprávy explicitně oběma serverům, oni sami mezi sebou vyřeší, který z nich klientovi odpoví. VRRP bych používal jen na služby, které nejsou navržené pro současný běh více instancí, což není případ DHCP.
• Když už máte tohle všechno rozchozené a narážíte na absenci CLATu na některých platformách, je jenom krůček k tomu, jak ušetřit kolem 80% IPv4 adres. Stačí do takto zprovozněné sítě přidat IPv4 a na DHCP serveru nabízet volbu číslo 108. Díky tomu všechna moderní zařízení s CLATem budou fungovat v režimu IPv6-only, zatímco stará zařízení bez CLATu stále dostanou plnohodnotný dual-stack. Díky tomu můžete dramaticky zmenšit pool IPv4 adres a někdy v budoucnu, až množství použitých IPv4 adres klesne k nule, IPv4 konečně vypnout.

A zapomněl jsem napsat: díky za články i za přednášku! :)

Dal jsem vyhledat v FortiOS 7.4.5, 7.6.0 retezec "pref64" na strankach Fortinetu, vysledek 0.
Tolik asi k tehle moznosti...

tak u Forty muzes rovnou filtrovat ktere RFC maj implementovane :

https://docs.fortinet.com/document/fortigate/7.6.0/supported-rfcs/700325

a 8781 tam neni

Děkuji za poznámky, jsou pro mě užitečné.

Objevování NAT64 pomocí dns bylo dle doporučení od Jool, ale je to už dva roky zpátky. Ohlášením směrovače je rozhodně lepší cesta, ale vzpomeňte jak dlouho jsme museli čekat než uměl směrovač poslat dns.

Kea a VRRP, děkuji za potvrzení, také jsem si to myslel. Vypadá to jako by dhcp relay nechtěli podporovat.

Asi si na to dhcp IPv6-mostly udělám lab, zajímá mě jestli to vyřeší problém s IPv4 only VPN :-) Tady se názorově rozcházíme, nevadí :-)

To mi připomnělo: Jool sídlí už několik let na jiné webové adrese - ta původní je zombie, ke které zřejmě nemá nikdo přístup a nemůže ji tedy ani vypnout. Odkazy jsem v obou článcích nechal opravit (a záměrně sem tu starou adresu nepíšu protože jí nechci zvyšovat page rank). Ani tam jsem ale nenašel žádnou zmínku o ipv4only.arpa.

Kea nepochybně je stavěná pro práci s relay agenty, ale ne s VRRP. Já s relay agenty nemám zkušenosti, ale náhodné hledání v návodech na Cisco ukazuje, že DHCP Relay agent má seznam Relay destinations:, tedy počítá se s tím, že agent bude předávat požadavky na víc než jeden server.

IPv6-Mostly lab: Už pár let takový lab vozíme po Evropě, připojuje se nám tam kolem 800 zařízení, naposledy před pár týdny v Praze. Jediný problém, který stále přetrvává, jsou vskutku některé VPNky, konkrétně pak jejich implementace na macOS. Jde povětšinou o komerční VPN typu NordVPN, SurfShark, ProtonVPN a podobné, které mají vestavěnou ochranu proti IPv6 leak. Ta funguje tak, že VPN klient jednoduše znefunkční IPv6 stack, protože předpokládá, že není potřebný pro spojení s VPN koncentrátorem, který je k dispozici pouze prostřednictvím IPv4. Tenhle předpoklad samozřejmě u IPv6-only zařízení s CLATem neplatí, VPN klient si jednoduše odřízne větev sám pod sebou.

Pokud však VPN klient IPv6 stack neznefunkční, fungují bez problému i IPv4-only VPNky a to jak split tunel tak full tunel. Zajímavé je, že problémy se objevují jen na macOS, nejspíš to souvisí s tím, že mobilní operační systémy VPNkám neumožní dělat tak brutální zásahy do síťového subsystému operačního systemu, takže i kombinace IPv4-only VPN s prevencí IPv6 leak + CLAT + IPv6-only síť funguje.

Kea je nedodělaná zabugovaná srágora, ale tak hlavně, že to je módní...

Zasadni prece je, aby henta konfigurace byla v json. To se totiz uzasne cte, jeste lip se to nastavuje a vubec nejlip se v tom kontroluje, jestli to ma spravnou syntax, protoze to je prece u jsonu nativni vlastnost ze ....

"serveru nabízet volbu číslo 108"

2020 ... chtel bych videt aspon jednu vec ktera to podporuje.

Zrovna Ondra o tom pravidelně přednáší, píše články a má to v praxi nasazené. Podporuje to dnes většina zařízení a na konferenční síti, kam přijde náhodná směs lidí s náhodnou množinou zařízení, si přes 80 % zařízení vůbec nepožádá o IPv4 adresu a jedou čistě na IPv6. Takže to je velmi dobře podporovaná varianta.

Ptáte se na podporu volby 108 na DHCP serveru? To podporuje každý, který podporuje uživatelské DHCP volby. Ty se už léta využívají pro automatickou konfiguraci nejrůznějších síťových zařízení typu IP telefony, takže podpora je celkem široká - namátkou ISC dhcpd a Kea, dnsmasq, Windows DHCP.

Co se týká podpory v klientech jde o všechna zařízení od Apple v posledních několika letech a všechna zařízení s Androidem tuším od verze 11.

Co znamená číslo 2020 jsem nedekódoval.

:roll: TO RFC vyslo 2020, takze klientu ktery to umej bude 00nic. Na serveru si muzu posilat co chci, ale to je mi uplne naprd ze?

Takze bych chtel videt tech poslednich nekolik let, kdyz to RFC je z rijna 2020.

Mnoho takových věcí se často implementuje dřív, než vyjde oficiální RFC. Navíc, jak už bylo řečeno, reálné zkušenosti ukazují, že to dnes používá 80 % klientů.