Názory k článku Univerzitní eduroam pouze na IPv6: CLAT, DHCPv6 a logování

Tak to je tedy "prekvapive" zjisteni, ze ani po 25 letech vyvoje se to proste pouzivat neda.

Ale cenim si vase aktivity - snaha byla! (a vypada to jako rozumne - ciste reseni, mit po dratech jenom jeden protokol, a tuneluje/natuje se jen "legacy" - ipv4, pro ktery byl vyhrazen rozsah v ipv6).

Tohle meli udelat i hostingy na druhem konci (ipv6 only, s malym vredem ve vlozene ipv4 podsiti)

13. 11. 2024, 03:11 editováno autorem komentáře

Ono je to dany spis tim, ze tohle je "reseni" problemu, kterej neexistuje a proto ho nikdo neresi.

Ta realita spociva v tom, ze uvnitr siti budes mit ipv4 jeste desitky let. A smerem ven proste postupne umre. Takze zadny preklady ze 4ky na 6tku a zpet nebudes proste resit.

Ten problem samozrejme existuje a je spousta firem, ktere ho resi. 464XLAT je uz vic nez dekadu popularni v mobilnich sitich, kde pomohl operatorovi zbavit se IPv4 v pristupove ("last mile") siti a zaroven zachranit kompatibilitu s opravdu spatne napsanymi aplikacemi nebo pristupy (pripojujete se nekdy treba pomoci SSH primo na IP adresu misto hostname?). Tenhle pristup uz na svete pouzivaji stovky milionu uzivatelu.

Cilem je dostat se do stavu, kdy uz prave uvnitr site (temer) zadnou IPv4 nepotrebujete. Az bude podpora CLATu ve Windows a zaroven built-in v Linuxu, razem vetsina organizaci s nasazenym 464XLATem zjisti, ze ctyrku v sitich s beznymi uzivateli uz pro koncove stanice a mobily prakticky nepotrebuje.

Mobilni sit = venku. Neexistuje zadna firma ktera by si mohla dovolit provozovat interni sit jako ipv6 only. Ani jedna. Minuly tyden mi dodali otevirani dveri na chip. Myslis si ze to vubec tusi neco o existenci ipv6? ...

Jiste, mohl bych si dat do zadavacich podminek ze to bude umet ipv6, a vyradim tak 98% dodavatelu cehokoli. Pricemz z pohledu funcionality je to to uplne posledni, co me zajima.

Tak zrovna otevirani dveri by melo mit vlastni kabelaz, nebo alespon VLAN a nedavat ji do site s pracovnimi stanicemi.

To, ze sem prodejci vozi kramy, ktere by jinde treba prodavali hur opravdu neznamena, ze zarizeni podporujici IPv6 nejsou. Ano, pokud si do pozadavku na zarizeni jako zakaznik (stale) IPv6 nedavate, nemuzete se pak divit tomu, ze vam dodaji kram bez IPv6 :-)

Nedávno jsem řešil zákazníka v Itálii, co byl IPv6 only (ale prý je jich po světě již víc). Očividně to tady v bublině Německo+Česko vnímáme jinak. Dělám v německo-české firmě, kde IT odmítá povolit IPv6, protože "počítače jsou vidět z venku a šíří se tím viry". IPv6 nemám ani doma (vesnická WiFi). Problém zákazníka jsem vyřešil proxy stránkou na hlavním web serveru, z které na staré web servery s mojí aplikací už IPv4 funguje v pozadí ok. Po dovolené jsem požádal servis, aby mu zavolali, jestli to funguje, a naštěstí jo. Předtím byl naštvaný, že si platí službu, která mu nefunguje.

Po znovupřečtení vašeho příspěvku jsem pochopil, že mluvíte o vnitřní síti. Pokud ale to otevírání dveří leze i na server v internetu (např. synchronizace klíčů, záloha pro obnovení v případě selhání lokálního serveru, např. disku, nebo řešení pro více budov firmy najednou, klidně i v jiných městech/státech), tak by s IPv6 only poskytovatelem stejně nefungovalo.

Tak ono taky eduroam je dost specialni pripad, protoze je to univerzitni sit, kde jsou aktivni vselijake studentske pokusy a take vedci ze zahranici a tak. Takze zatimco ve firme normalni velikosti jde casto neco vyresit zmenou nastaveni/politik, v eduroamu je to slozitejsi.

Ani v ty firme to nevyresis. Protoze firma nejsou jen PC. V kazdy normalni mas hromadu krabic, ktere nejak neco posilaji po siti a o v6 nemaji ani paru. Takze se proste provozu 4ky uvnitr te site nevyhnes.

Krasny priklad na konkretni krabici ... platebni terminal.

Ovšem, ale díky režimu IPv6-mostly (464XLAT spolu s DHCPv4 Option 108) těch zařízení, která v takové síti budou stále ještě používat IPv4, bude po nasazení CLATu ve Win 11 minimum.
Ve firmě to vyřešíš tím, že budeš po dodavateli "krabiček" vyžadovat podporu fungování v IPv6-only režimu.

"Ve firmě to vyřešíš tím, že budeš po dodavateli "krabiček" vyžadovat podporu fungování v IPv6-only režimu."

To jiste, ona se s tebou treba banka bude bavit o tom, ze jejich servery jsou ipv4 only, a jejich terminaly pouzivajici DES jako nejuzasnejsi zpusob sifrovani ... neumi pouzit ani v4 dhcp.

@bez_prezdivky

Videl jsi nekdy v reale v6 mostly/only lokalni sit?
Zkousel sis to v testovaci siti?

IPv6 sit lze provozovat a deje se tak delsi dobu.

S v4 only zarizenimi lze pracovat nekolika zpusoby.
Tak jako mame legacy app/servery tak lze provozovat legacy vlan(y) kde je v4 only. Neni potreba to demonizovat.

Ve vetsine siti by jsi dnes po zavedeni dualstacku videl majoritu provozu po v6.

"Videl jsi nekdy v reale v6 "

Narozdil od tebe, kdybys umel cist, provozuju ve vsech sitich ipv6 20+let. Opakovane to tu pisu. Neni s tim problem, ale vsude se provozuje dualstack.

A kdybys umel cist trochu vic, tak by ses treba i docet, ze v nekterych sitich mam v6 provoz 80%+. Jenze to se bavime o provozu ven. Nikoli o provozu uvnitr.

Bez v4 se zadna firemni sit provozovat neda. Pricemz jak zjistil sam autor clanku, ani sit skolni.

Oba články parádní. Ohledně CLAT to vypadá, že nějaké vlaštovky jsou na obzoru.
https://techcommunity.microsoft.com/blog/networkingblog/windows-11-plans-to-expand-clat-support/4078173

https://github.com/toreanderson/clatd
Zde jsem koukal, že jsou i script pro NM.

Na test ipv6-only se už chystám déle a tento článek mě zas nakopnul. Díkes

Mezi nama, uz jen napad, ze budes cokoli resit na klientovi, je zcela uchylnej. To totiz zaroven znamena, ze to budes resit na nejmin desitkach ruznych systemu ruznych verzi. A i kdybys mel takovej system jeden jedinej, tak to porad znamena, ze budes mit ( i ve velmi malem rozsahu) desitky klientu, kdy budes resit, proc to na kazdym jednom nefunguje jinak.

Takze ve vysledku se priprav na to, ze budes mit stovky vsemoznych scriptu ktere budou kazdy jeden nefungovat v zavislosti na fazi mesice, rocnim obdobi, pocasi, ...

Ne to není uchylný nápad. To je jenom další krok se zbavení IPv4. Je potřeba projít několik fází.

1. Přidat podporu IPv6 jako doplněk k IPv4
2. Provozovat IPv6 a IPv4 jako dual-stack a rovnocenně
3. Vypínat IPv4 a mít jenom IPv6 a mít jenom NAT64
4. Úplné vypnutí IPv4 a NAT64

V tuhle chvíli jsme (podle mě) mezi prvním a druhým bodem (už jsme k tomu druhému bodu hodně blízko).

Spíš je blbost koukat na bod 3. tj. ukončování IPv4 s nějakou fallback podporou, z dnešního pohledu a tvrdit, že je úchylné. CLAT je řešení, kdy už všechno až na nějaké opravdu obskurní výjimky funguje nativně na IPv6 a z nějakého důvodu neumí použít IPv6. Vidím to pořád dokola, že lidé nechápou, k čemu vlastně CLAT je a motají to s NAT64 resp. jako jeho náhradu. Nikdo nenutí mít CLAT v klientech rovnou, klidně to může běžet na nějakém síťovém prvku. Tj. mít jenom interní dual-stack a ven už vše jen přes IPv6.

To vypada, ze nechapes ani nejzakladnejsi zaklady.

Ten clat na klinetovi potrebujes proto, ze na nem mas neco, co neumi v6. A tudiz to ve v6 only siti musis nejak zkonvertovat z v4.

A dalsi vec kterou zjevne vubec nechapes je ta, ze ucelem je prave to zbaveni se v4 provozu uvnitr site. Knicemu jinemu to neni.

To co ty vymejslis je totiz naprosta kravina. Jako ze budu nekde na gw ven prekladat 4ku do 6tky aby ji pak nekde cestou treba isp rekladal zpet do 4ky ...

Zkus si pak adminovat sit ve ktery jsou alespon nizky stovky stroju a krabic. Ano pro dualstack to znamena ze mas vse 2x, pro clat to znamena, ze ti to nebude fungovat. Jak ostatne je popsano i v clanku.

Opět totální nepochopení. Bavíme se o velkých sítí typu eduroam. Celá síť běží IPv6 only s NAT64. Pak máš zařízení, které IPv6 neumí. Prostě jiné řešení než nahrazení nebo překladač ti nezbývá.

Tohle řešení resp. CLAT nemá být univerzální řešení. Je to poslední záchrana, když to již jinak nejde.

Mimochodem tahle varianta je zmíněná i v článku v poznámce. Nic nevymýšlím, už je to dávno vymyšlené.

Bohužel clatd i se skriptem pro NM je stále jen tayga a to je pro širokou veřejnost nepoužitelné. Zkoumal jsem to ale netestoval, nestálo to za to.

Ale možná něco začíná, viz. poslední příspěvek, od Ondry Caletky https://ripe89.ripe.net/programme/meeting-plan/ipv6-wg/
Jestli jsem to správně pochopil, kontaktovali ho vývojáři NM ohledně pomoci, aby ipv6 only sítě v NM dobře chodily, a to včetně clatu.

Koukněte aj na tu prezentaci. Je tam až děsivá podpora pro IOT a chytrá zařízení.

ostatne soudim, ze podpora IPv6 na IOT bude kapitola sama za sebe (a ta kapitola zatim temer neexistuje :)

Myslím, že ta kapitola se už trošku otevřela. Zrovna protokol Matter používá IPv6 adresy.

Jinak tu prezentaci nevidim, je to spravny odkaz?

Aha, je to ta posledni (jak rikate), nazvana "Thanks, Wrap Up and Rate the Talks", moje chyba

V delší verzi je to tady: https://youtube.com/watch?v=q1AWWB-HmH4

Zrovna řeším návrh sítě kde bude i Eduroam a IPv6, a čekal jsem jak bude vyřešené logování provozu, protože to je docela bolest... Ukládat ND tabulku beru jako hodně minimalistické řešení, jeho nedostatky jsou nakonec pod článkem zmíněny.

U IPv4 jde spolehlivě nasadit na access síti IP Source Guard, takže od klienta neprojde jiná zdrojová IP než přidělil DHCP server. Pak stačí flow monitoring na úrovni IP adres, doplněný o logy DHCP serveru (vazba na MAC) a Radiusu (vazba na identitu).

U IPv6 se nevyhneme podpoře autokonfigurace (Android), a pak jediné plně spolehlivé řešení je sbírat NetFlow/IPFIX data včetně MAC adres. Tj. součástí identifikace flow jsou nejen IP adresy ale i MAC adresa klienta, podle které se dělá vazba na identitu.

Problém je, že ne každý netflow probe toto umí. Nejelegantnější je sbírat netflow data přímo na routeru. Třeba FortiGate umí netflow probe v HW, což je fajn, a když se na něm zároveň dělá IPv4 NAT, tak mám data rovnou včetně informací z NAT tabulky. Jenže neumí v netflow posílat ty MAC adresy. Nasazením externí flow probe se všechno dost komplikuje a prodražuje, protože to v tomto případě vede na monitorování 4x 10Gb/s portů (HA setup) a stejně z routeru potřebuju dostávat data NAT tabulky...

Jasně, tohle je třeba nedokonalost FortiGate, jenže prostě ani v roce 2024 nejsou všechny produkty v konečném důsledku tak IPv6 ready, aby to nepřinášelo dodatečné komplikace a náklady.

Tak ona vam ani ta MAC adresa zrovna v pripade Androidu (a zrovnatak IOSu) moc nepomuze, kdyz uz se anonymizace dnes standardne povadi uz na druhe vrstve - ta adresa je proste nahodna (maximalne semi-nahodna, tzn. pro jedo AP se dlouhodobe nemeni). Tzn. ten problem s problematickou vazbou na indentitu, co se tu snazite popsat mate tak jako tak a bez ohledu na verzi IP.... a pouzivat MAC jako identifikator je dnes stejne useless jako mit IP jako nejaky identifikator...

V případě 802.1x tohle zrovna není problém, protože stejná MAC adresa, kterou zařízení používá k posílání dat zároveň musí být použita pro autentizaci, jinou autentikátor do sítě nepustí. Takže bez ohledu na to, jakým způsobem MAC adresa vznikla a jak často se mění tu bude vždy vazba mezi MAC adresou a 802.1x identitou.

Akorat ze o 802.1x v tom komentovanem prispevku rec vubec nebyla, ze? ;-) A rozhodne bych netvrdil, ze ti zapskli odpurci IPv6 kverulujici nad problemy bezne tohle v danych sitich opravdu resi... spis tam je zvyk mit staticke DHCP leases na MAC, protoze to tak delaji uz tricet let a prece to nebudou delat jinak...

Byla tam zmínka o eduroamu, ten funguje jen s 802.1x. :)

MAC samozřejmě není trvale persistentní identifikátor. To ale vůbec nevadí. V rámci jedné 802.1x session se měnit nemůže, to hlídá access vrstva. Při příští autentizaci ať si ji klient klidně změní. Netflow collector to spojí s logem z Radius serveru, ale k tomu potřebuje mít právě tu informaci o MAC adrese - ideálně přímo ve flow datech, nebo nějak z ND tabulky routeru (ale pak spíš real-time sledováním změn, ne dumpem jednou za hodinu jak to popisuje článek).

Možná kdybyste napsal jak to tedy řešit lépe, pomohlo by to všem kdo řeší problém efektivní implementace identifikace IP provozu s identitou uživatele v přístupové síti typu Eduroam.

A co se presne loguje? Objem, nebo cilove adresy? Specialne pri provazani na identitu to vypada jako strasak typu.. radeji si udelam hotspot z mobilu.

Standardní netflow data - session je kombinace zdrojová/cílová ip/port/protokol, k tomu čas začátku a konce komunikace a objem dat.

Nevím jak je to teď u ISP s Data Retention, dřív měli povinnost cca tohle ukládat po dobu 6 měsíců (ukládání provozních a lokalizačních údajů za účelem vyšetřování trestné činnost).

Ještě mě napadlo, že jedna z možností, jak párovat MAC adresy a IP adresy je utilita addrwatch. Nemusí běžet přímo na routeru a dokonce zvládne sama zpracovat 802.1q tagy, takže může logovat pro víc VLAN zároveň. Vazby se logují v jednoduchém textovém formátu. Není to tak ideální řešení jako exportování MAC adres do Netflow, ale je to lepší než nic.

Díky, vypadá to celkem použitelně. I když poslední aktivita skoro 5 let zpět neukazuje na úplně aktivně udržovaný projekt.

Několik poznámek:

• 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ů.

Přes SNMP jsme sbírali tabulky sousedů taky. Má to nevýhody, že při každé změně prvku jsme měnili OID a nakonec to začalo CPU vyžíralo tolik, že to dělalo výrazné problémy. Lepší to máte brát přes SSH. Command je na to všude stejný a na CPU to nemá měřitelný vliv.