No, ještě by to někdo mohl vysvětlit našim mobilním operátorům.
Zase jsem zkusil Vodafone, když teď koupili UPC, kde dávají (pouze) veřejnou IPv6, tak by to mohli zapnout i v mobilní síti - a ve vší slušnosti mi odpověděli, že až naprší a uschne.
Majorita zákazníků českýho ISP má přípojku nebo žije na území EU. A tady je mj. legislativně dáno, že ISPík nesmí blokovat provoz zákazníka jenom na základě bla, bla, protokolu, bla, bla, pokud k tomu není zákonný, technický nebo vážný důvod. "Mysleli jsme, že to nikdo nechce" do této kategorie nespadá.
Takže zákazník na to má právo. Když ho nevyužije, jeho věc. Když to chce, nemělo by mu to býti upíráno.
Nemuze to souviset s tim, ze pro nasazeni IPv6 u velkeho operatora nestaci nejaka teoreticka predvadecka v laboratornich podminkach? Sam jsem podobnou situaci resil u stredne velkeho operatora a ukazalo se, ze IPv6 na tom v realu neni tak dobre, jak to vypada na papire... Je to prinejmensim nedotazene nebo nedomyslene. Na pateri to chodi hezky, ale resit koncaky je hrozny opruz.
No jo, naši velcí operátoři s tím mají v roce 2020 problém a moc práce, zatímco zahraniční malí operátoři to provozují od roku 2014:
https://www.internetsociety.org/resources/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/
Ona je totiž každá přístupová síť jiná. A proto musíte řešit specifika.
Na DSL to je ze síťového pohledu triviální, RADIUS server posílá Framed-IPv6-Prefix a Delegated-IPv6-Prefix, k tomu řešíte routování mezi vaší sítí a sítí CETINu. Databáze, ze které bere data RADIUS server, pak musí mít informace o přidělených prefixech, ideálně agregovaných podle regionů (kterých má CETIN několik). Zbytek je na straně CETINu - jeho přístupová síť je (pro přístup k Internetu) hloupá, přenáší jen PPPoE rámce. Chytré jsou uživatelské routery (ty musíte jako ISP vyřešit) a PPPoE koncentrátory u CETINu (BRAS), které musí mít aktivní IPv6 v profilu toho kterého ISP. Pro identifikaci zákazníka se u CETINu používá unikátní identifikátor linky, takže vy jako koncový operátor nemusíte řešit MAC adresu zákazníkova routeru, DUID, IAID, nemusíte řešit first hop security (tu řeší BRAS a DSLAMy pro PPPoE už od přechodu z PPPoA na PPPoE).
A samozřejmě to musíte mít v CRM, musíte vyřešit na své straně odposlechy, data retention (=kdo měl kdy jaký prefix, protože není třeba logovat NAT sessions). Ale je to řešitelné.
V sítích s PPPoE se celkově IPv6 nasazuje snáz, protože většinu problémů už máte vyřešenou od dob IPv4 právě tím PPPoE. IPv6 pak musí podporovat hlavně váš koncentrátor (BRAS). RADIUS, CRM, odposlechy a data retention jsou víceméně shodné s tím, co má TM na DSL.
Vždycky se proto divím, proč na DSL nenabízí IPv6 víc operátorů - ekosystém je stabilní, cesty prošlapané a implementace celkem jednoduchá. Jenže se buď nechce (např. Vodafone) nebo "ISP" nemá dostatek IPv6 prefixů např. proto, že není LIR nebo nemá od svého LIRa dostatečně velký příděl (např. 365internet).
Oproti tomu přístupové sítě založené na IPoE (tj. adresy získáváte z DHCP a jste na stejném switchi/optickém koncentrátoru s ostatními zákazníky) musí vyřešit identifikaci zákazníka pro IPv6 (circuit ID v DHCPv6), IPv6 first hop security, DHCPv6 relay se správnou instalací prefixů delegovaných pomocí DHCPv6 do routovací tabulky... a to typicky levná zařízení ne-operátorského typu (např. optický koncentrátor od Ubiquiti a pod., levné přístupové ethernet switche) neumí.
V takové síti se IPv6 nasazuje opravdu špatně. Je to vidět třeba u Netboxu, který má IPoE, a doteď nabízí IPv6 jen jako ručně konfigurované 6rd tunely.
Přestože všemu nerozumím, pěkná odpověď, děkuji.
Takže jestli to chápu, PPPoE (jako dvojbodové spojení) končí až v BRASech, které si řeší CETIN, takže tam si ohlídá zařízení řešící PD atd., kdežto IPoE troskotá na nevhodných zařízeních někde na konci, odkud vedou kábly k jednotlivým zákazníkům.
Otázky:
1. Chápu to správně, že to, co by ta zařízení potřebovala umět v IPv6, již logicky umějí (obdobně) v IPv4?
2. Dá se hloupost těch zařízení nahradit ruční/skriptovací administrací (doplnění směrování a PD pro jednotlivá rozhraní, ...)?
Chápete to naprosto správně.
Ad 1: obvykle ano, často ale mnohem jednodušším způsobem, např. DHCPv4 relay k DHCP serveru s registrací MAC adresy -> není třeba řešit DUID, operátor ne nutně řeší identifikaci zákaznického portu a to i za cenu menší bezpečnosti; DHCPv4 relay taky obvykle nemusí řešit routování prefixu, protože tahle vlastnost se v IPv4 obvykle nepoužívá, i když existuje RADIUS atribut Framed-Route, který umožňuje na přístupovém prvku instalovat routu na konkrétního klienta (tj. nadelegovat/naroutovat blok IPv4 adres na konkrétního DHCPv4 klienta). Jiné funkce jsou na zařízeních přítomny pro IPv4, ale ne pro IPv6 (a to i na novém hardwaru), zejm. tu narážíme na first hop security (aby si klient na WAN straně svého routeru nespustil DHCPv6/RA server a nestrhl k sobě provoz, aby klient nepoužil adresu, která mu nepatří, atp.).
Ad 2: často ne (např. first hop security se špatně nahrazuje, i když některá zařízení umožňují filtrovat nepovolený provoz na L2/L3 a vytvořit tak částečně funkční first hop security). Některé vlastnosti jdou částečně naskriptovat, např. přidávání routovacích záznamů pro delegované prefixy do routovací tabulky na first hop routeru, ale je to takové... neohrabané. Statické routování (pevně definovaná adresa na WAN, pevně definovaná adresa routeru, statická netmaska, ručně nakonfigurovaný IPv6 prefix u klienta v routeru i na operátorském routeru) možné je, ale zase to dost ztěžuje automatický provisioning.
Děkuji.
Poprosím ještě dotazy, když na ně budete mít čas:
1. Takže je možno říci, že DSL s IPv6 v ČR není problémem, protože veškeré(?) přípojky DSL má CETIN, a ten to má pořešené? Zde jde už jen o neochotu přeprodávačů?
2. Předpokládám tedy, že pro IPoE je třeba v celé cestě k zákazníkovi vhodných routerů (síť je hierarchická), které postupně distribuují a dělí prefix. To stačí, nebo je tam ještě nějaký jiný zádrhel pro poskytovatele? A existuje v ČR nějaký takový poskytovatel, který to má a IPv6 mu funguje?
3. Měli poskytovatelé IPoE příležitost při poslední výměně HW již vybrat vhodná zařízení? Kolikrát jsou dražší?
4. Čím se od předchozích 2 řešení liší nasazení IPv6 u telefonního operátora? Blíží se to spíše DSL, nebo těm IPoE?
1. Ano (viděl jsem chybně nastavený profil na BRASu u CETINu, kdy se na PPPoE neaktivovala IPv6, ale tiket na podporu to vyřešil).
Týká se to i optiky od CETINu.
2. First hop security a DHCPv6-PD se typicky řeší na posledním routeru před zákazníkem, uvnitř sítě se routy distribuují nějakým routovacím protokolem (OSPFv3, BGP).
Uvnitř sítě je to celé jednodušší, nejtěžší je ta část mezi ISP a zákazníkem. Neznám sítě všech ISP, ale vím, že jsou ISP, kteří nepoužívají PPPoE, a mají nasazeno (GRAPE SC, například).
3. Měli (někteří). U GPONu může jít o násobky (resp. pokud někdo kupuje Huawei GPON, zaplatí za to desítky tisíc Kč, pokud chce ušetřit a koupí Ubiquiti, zaplatí třeba čtvrtinu).
U ethernetových switchů úplně nevím o funkčních lowcostech. Juniper, Cisco podporu mají, ale to není úplně lowcost. EdgeCore občas podporu má, ale člověk musí explicitně chtít IPv6 nasadit a pídit se po konkrétních vlastnostech. Tedy pokud staví síť jako operátorskou, tj. s first hop security, identifikací zákazníka pomocí ID portu, atp.
Na bezdrátovém IPoE je ovšem nejčastěji Mikrotik nebo Ubiquiti, a to je z pohledu operátorského IPv6 jedno velký špatný.
4. Pokud myslíte mobilního operátora, tak to je úplně jiná liga.
Mobilní sítě jsou jeden velký balík tunelů, z pohledu mobilu se datové spojení navazuje jako tunel mezi mobilem a jádrem sítě (PGW/v pre-LTE terminologii GGSN).
Řeší se typické problémy jako billing a accounting, ale neřeší se first hop security (protože tu řeší síť na nižší úrovni). IPv6 se tak obvykle nasazuje rekonfigurací jádra sítě (PGW/SGW/GGSN/SGSN/MME/PCRF/...).
IPv6 (dual-stack i single-stack) je součástí 3GPP standardů už dlouho, všechny LTE krabice ho umí. Problémy občas nastanou s legacy zařízením (charging) nebo proprietárními aplikacemi (data warehouse, kukátka do provozu, ...) - ale to je řešitelné a náklady nejsou v desítkách milionů Kč, spíš v jednotkách.
Z pohledu IP se na PGW nakonfiguruje velký IPv6 prefix a z něj se přidělují bloky /64 každému tunelu (tj. každému telefonu). Mobilní telefony často mají víc paralelních datových relací - jednu pro Internet, jednu pro VoLTE, občas jednu pro odesílání MMS - technicky je možné je spojovat, a často se to v zahraničí děje pro MMS a Internet; VoLTE obvykle má svou relaci.
Každá relace má svůj routovaný /64 prefix (nebo IPv4 adresu, nebo obojí). Mobil si tak může vzít jakoukoli IPv6 adresu z toho prefixu a použít ji např. na 464XLAT (resp. CLAT) funkci, nebo celý prefix nasdílet do LAN.
Dual-stack formou jedné relace ovšem není preferován, protože se ve standardech objevil až se zpožděním a můžou s ním být problémy v roamingu (pokud síť navštíveného operátora nepodporuje dual-stack). Naopak s čistou IPv6 obvykle v roamingu problémy nejsou.
Operátoři v zahraničí tak obyvkle nasazují IPv6-only na mobilu s tím, že do IPv4 světa se dostanete pomocí NAT64/DNS64. Povídal jsem o tom trošku na CESNETím Semináři o IPv6 v roce 2017. :-) https://www.cesnet.cz/akce/ipv6-2017/
Souhlas. Jen o té sítí Cetinu, respektive jsme si to vyzkoušel na DSLkách v přeprodeji od T-Mobilu, tak síť hlídá DUID koncových zařízení. Pokud do sítě připojím 2 zařízení hlásící se stejným DUID (jedno třeba v Táboře a druhé v Brně), tak to později připojené nedostane IPv6 příděl dokud se to první nevypne.
Takto jsem si naběhl paár lez zpět, když jsem si naklonoval pomocí backup/restore z jednoho Mikrotik routeru do druhého (což se nemá dělat) a
ono to přenese DUID a nejde pak už zresetovat.
Díky, tohle je zajímavé - bude to nejspíš vlastnost/vada implementace IPv6 na konkrétních koncentrátorech (BRAS), nejspíš jste se oběma zařízeními připojil na stejný koncentrátor (to se v rámci regionu může stát) a on si s touhle situací neporadil.
CETIN koncentrátory někdy před dvěma lety kompletně vyměnil (nově používají Nokie), tak možná to ty nové už nedělají - ale vyzkoušeno to nemám.
Na straně prodejce konektivity (v tomhlě případě TM) se DUID neřeší vůbec.
Tak za chybu bych to nepovažoval, jen mi chvilku trvalo, než mi došla podstata problému. :-)
Ty zařízení asi nebyla na jednom koncentrátoru. Přeci jen z centra Tábora do Brna je dost daleko od sebe? A jinak ty zařízení sdílela i stejný IPv6 příděl /56. Zkrátka to dříve zapnuté ho dostalo, druhé čekalo s tím, že DHCPv6-PD se snaží získat příděl, když se první vypnulo, tak během pár sekund to druhé dostalo daný příděl a takto hezky se příděl přetahoval, než jsem jedno přeflashoval od nuly a tím se DUID shodilo na jeho "správnou" hodnotu.
Nezačali. Ale na straně sítě tehdy nebylo co rozbít. Až při integraci s GTS to v TM někdo rozbil... https://www.root.cz/zpravicky/t-mobile-mel-mnoho-mesicu-vazne-problemy-s-ipv6-na-dsl/
Největší problém v roce 2014 byl, jako už tradičně, se stabilitou IPv6 na CPE.
Co já jsem viděl, tak to nejčastěj končilo řešení IPv6 u neschopnosti pochopit prostý fakt, že:
- prvních řekněme 29 bitů je od RIPE a odpovídá jejich prefixu ISP ve světě IPv4, ze kterýho dávají veřejný adresy
- Dalších 19b (pro /48) nebo 27b (pro /56) je jejich obdoba CGNATu a je v jejich režii. Ideální pro definici trasy v síti a současně identifikaci zákazníka.
- dalších 8b (u /56) nebo 16b (pro /48) je obdoba x u 192.168.x.y a jako nestrkají prsty do toho, kolik sítí si doma za jednou veřejnou IP adresou provozuje zákazník, nemají co strkat prsty do tohohle.
- a posledních 64b je obdoba toho y v 192.168.x.y a na jejich straně je mají prostě ignorovat, protože jsou čistě věcí SLAAC v koncovým zařízení, nebo zákazníkova DHCPv6, nebo zákazníkova manuálního nastavení.
A při nepochopení tohohle se pak řeší nesmysly, jak filtrovat zařízení na úrovni /128, když si ty potvory furt mění adresy a podobně...
USA, Japonsko, Nemecko, Francie, Belgie nebo Arabske Emiraty nevypadaji zrovna jako strelci, kteri radi testuji neco v produkci a pritom je u nich nasazeni na velkych cislech procentualne i absolutne.
Stav deploymentu ve Vietnamu, Indii nebo Malaysii je dokonce jeste vyssi.
Operatori v Cechach trpi na nedostatek kvalifikovanych lidi a nekdy si clovek rika, ze se u nich moc nezmenilo od dob, kdy nasazovali anteny sita s Orinocco nebo ZCom PCMCIA kartama.
Odpoved "nikdo to nechce" je jakoby rikali "nerozumime tomu, nejak jsme to rozchodili a nejak ten nas byznys funguje".
Ve firemnim prostredi je to v blede modrem. Nneumime pouzivat nove technologie a nasleduje kopa "argumentu" proti (cas, penize, atd..).
A to se pak cloveku chce parafrazovat jisteho Milose na Hradecku : "...a kdyz s nima mluvi nakonec, tak se nevi ani, proc tak argumentuji, a co vlastne nefunguje, protoze si to nikdy ani nevyzkouseli a skoncili u toho, ze si tu v6 adresu nikdo nezapamatuje"