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"
Předně bych IPv6 nenazýval moderním protokolem. Je starý 24 let a ani za tu dobu se mu nepodařilo rozšířit, protože je prostě příliš komplikovaný. Je to jedna z věcí, která je skvělá v akademické sféře. Když máte neomezený čas s tím hrát, laborovat, psát o tom články. V praxi, kde se vše točí kolem peněz a hlavně času, nedává implementace IPv6 smysl. Zavedení IPv6 vám nic neusnadní, spíše naopak, vše bude složité, nepřehledné, atd. A z hlediska peněz, vám to jen peníze odčerpá, ale žádné nepřinese. Chápu, že tohle může být pro akademiky nepochopitelné, ale je to tak.
Evidentně neznáš enterprise prostředí, když si myslíš, že je to o lenosti lidí. Zkus si v labu nasimulovat stovky routerů, stovky switchů, stovky vlan (subnetů), tisíce FW pravidel, FW zóny, ... stovky DHCP scopů, 802.1x skupiny,..... A teď to zkus BEZ PŘERUŠENÍ provozu přemigrovat na IPv6. A ne, nemáš na to 8hod denně, protože všem ostatním je nějaká migrace na IPv6 úplně jedno, protože business musí jet dál.
Představit si to umím. V síti, kterou mám na starosti já tedy stovky routerů nemáme a obecně tam některé věci, které by v síti měly být chybí (pracujeme na tom), ale myslím, že faktor 10x víc si představit umím.
Mě se zdá, že s IPv6 se dá začít po troškách. Nemusíte přece rozchodit všechno najednou. Začněte třeba web stránkou nebo email serverem. Aspoň lidi, co se připojují ze světa použijí IPv6 a provoz tím skoro na 100% rušit nebudete. Tyhle věci často bývají venku/ v nějakém hostingu nebo cloudu a interní enterprise sítě se dotýkají minimálně. Radek Zajíc o Happy Eyeballs, které případné chyby docela slušně přechází, včera přednášel na RIPE NCC Educa [0]
Rozchodíte spoje mezi hlavními routery a můžete pokračovat třeba v management sítích zařízení nebo guest WiFi a nějaké separátní VLAN pro testovací stroje. Postupujete po troškách, tak nějak organicky. Získáváte zkušenost a snižujete riziko.
Neznám jedinou společnost, kde by musel být skutečně nepřetržitý provoz. Znám společnosti, kde se i na měsíce předem ohlášenou/ domluvenou odstávku kouká skrz prsty, ale prostor pro odstávku je resp. musí být. Nic nefunguje 100%, ani mainframe, ani HW load-balancer a i sebelepší failover prostě kratičký výpadek či zhoršení služby způsobí. Všechna zařízení, dokonce i kardiostimulátory, mají omezenou životnost a (u podobně důležitých věcí) existuje definovaný způsob výměny. Pokud systém podobné možnosti nemá, tak je to chybný návrh a jenom se čeká na pohromu/ nedefinovanou výměnu/ záchranu.
Fakt je, že dříve či později na IPv6 budete muset aspoň částečně přejít, abyste se domluvil nějak rozumně nebo ekonomicky se zbytkem světem. Je na vás, za jakých podmínek to bude - jestli pozvolna a vklidu nebo "honem rychle" a více pod tlakem. Zvládli to větší a složitější sítě před Vaší společností, tak to zvládne i Vaše společnost - trik je asi v tom někde začít a ne si jen vsugerovávat, že to nejde.
Myslím, že tu v diskuzi je několik lidí, kteří praktické zkušenosti mají a když se jich slušně zeptáte a poskytnete nějaké info, tak Vám kvalifikovaně mezi čtyřma očima a důvěrně poradí, kde a jak by se dalo začít. Já jsem u svého zaměstnavatele s IPv6 taky na začátku, ale po ca. dvou letech chození kolem horké kaše se věci dávají pomalu do pohybu. Bude to maraton na druhou? Ano. Bude to příležitost jisté věci uklidit/ zlepšit? Snad. Ušetří nám to peníze? Těžko říct, dlouhodobě asi ano resp. bude to nutné pro bezproblémovou komunikaci s dceřinými společnostmi v Asii.
[0] https://www.ripe.net/support/training/ripe-ncc-educa/ripe-ncc-educa-ipv6-2020
Otazne je, ci bezna korporatna siet, dnes najcastejsie riesena ako 10.X.X.X "intranet" s par strojmi v DMZ, ktore maju aj verejnu IP adresu, toto potrebuje, za cenu "prekopania" celej sietovej infrastruktury.
Porusujuc tak "zakladne pravidlo vyhoreneho korporatneho ajtaka" - "Nesahaj na to, co funguje!" :-)
Problém je, že IPv4 ve skutečnosti na spoustě míst nefunguje a nevíte o tom, protože tu nefunkčnost nějak maskujete. Nebo Vy označujete auto, které musíte tlačit aby jelo, za funkční? Ano, hýbe se a dá se v něm pohodlně sedět. Možná i hraje rádio. Ale hlavní důvod existence toho auta není plnohodnotná. Přesně tak, jako není plnohodnotné adresování, které funguje jen v určitém kontextu, když to není jeho účel. A u RFC1918 adres na rozdíl od UL Adres není účel omezovat se na LAN, ale je to rovnák na ohýbák!
Nefunkčnost adresování IPv4 maskujete tehdy, pokud stavíte už druhý NAPT a vyhlížíte třetí nebo když musíte síť nové dceřiné společnosti přečíslovávat resp. když tohle dělá někdo za Vás. Víte kolik práce za tím vším u IPv4 je? Je to jako kdybyste začal stavět v centru města jezdící vozovky po vzoru jezdících chodníků na letištích, aby tam ta "špinavá auta se spalovacími motory" nejezdila ale centrum bylo pořád pro auta "průpohybné" (protože průjezdné to tedy není). Jistě vidíte, že už z toho slova je jasné, že takhle dokonce ani Čeština nefunguje. :-)
Pokud ty IPv4 nejsou skutečně Vaše (máte ASN? nebo máte ještě IPv4 PI?), tak za každou z nich platíte roční obolus v nějaké formě nebo toho je v rámci nějaké paušalní platby omezený počet. Pokud za něco platíte, tak tam vzniká nepříjemné tření s účetním oddělením, pokud toho potřebujete víc. Abych to tak řekl, tak platíte za pitomé číslo!
Nevím jak u Vás, ale tady v Německu byla většina firem a jiných organizací karanténou překvapena. Zjistila, že komerční VPN je a) pro tolik uživatelů moc drahé b) neohebné/ těžko spravovatelné c) není dostatek prostředků a do toho počítám i IPv4 adresy. Kamarád tohle řešil na TU-Dresden pro stovky až tisíce nových uživatelů VPN, kdy komerční řešení už bylo dostupné, ale dodatečné licence by byly příliš drahé a hlavně nejspíš nedostupné včas a kde je stále ještě dost veřejných IPv4 na realizaci. (I tak plánují přechod na IPv6.) Nakonec nasadil OpenVPN cluster, který ten nápor úplně pohodlně zvládá a bez problémů škáluje. Všechno zautomatizované a nasazené do produkce za 3-4 dny. Kdyby nebyly ty adresy, tak by asi měli kolegové problém - jen tak si říct o 20+ nových adres za něco jako 2000 € ročně (100 €/adresa/rok, což je celkem běžná částka pokud Vám ty adresy nepatří) není v takový moment nejrychlejší způsob, jak se dopracovat k cíli. Říct si ale o dejme tomu 10 000 €/ rok na dodatečné licence + dodatečný hardware za násobek té ceny na rozšíření jednoho komerčního VPN clusteru, aby se nemusely dokupovat adresy je ještě méně smysluplné. (Proto se taky zvolila cesta první.)
U mendich isp to dost brzdi mikrotik, ktery uz nekolik let ignoruje nalehani uzivatelu na rozjezd delegovaneho prefixu pres pppoe https://forum.mikrotik.com/viewtopic.php?f=2&t=89443
No u firemních nasazení tomu pro změnu nasadil korunu Google dlouhodobým ignorováním DHCPv6 v Androidu, což spoustu adminů nepotěšilo (velmi slabé slovo).
Že je i ve "větších" zařízeních podpora pro šestku zjevně dodělávaná hlavně aby byla je vidět nejen na Fortinetu zmíněném v článku, stačí třeba kouknout do release notes u Checkpointu (a dost pravděpodobně u dalších, které tolik neznám).
Android ignoruje DHCPv6 zcela záměrně a důvod je dlouho znám. Telefon potřebuje mít přidělených víc adres, třeba kvůli kvůli tetheringu, aby je mohl předávat dalším zařízením za sebou. To DHCPv6 neumožňuje, protože přiděluje vždy jen jednu adresu na zařízení.
Když se zeptáte, proč správce vlastně podporu DHCPv6 na těch zařízeních potřebuje, tak se dozvíte, že chce přidělit právě jednu adresu na zařízení. To je přesně ten důvod, proč ho Android neumí.
Problém nepodpory DHCPv6 je to, že je pak téměř nemožné zařízení v síti detekovat. Současně pak nemůže fungovat ani lokální DNS, jak jsme zvyklí u IPv4.
Ještě navíc s DHCP lze zařízením přiřazovat adresy podle nějakého schématu, při použití SLACC je to akorát bordel, ve kterém se nikdo nevyzná.
9. 6. 2020, 11:19 editováno autorem komentáře
Detekovat ich mozne je, uplne rovnako ako v IPv4 sieti ked si zariadenie priradi staticku IP adresu. Ano, nie je to take pohodlne ako zobrat state file z DHCP servera, ale je to spolahlivejsie, pretoze zachyti pripady aj ked zariadenie nekooperuje po dobrom.
Lokalna DNS fungovat moze, annoncne ju RDNSS.
V normální firemní síti (čtěte: 802.1x + DHCP snooping etc) to zařízení se statickou adresou sice připojíte, ale to je tak všechno co s ním uděláte.
A nejde o to, že sledujete co komu DHCP přiřadilo, to bychom si moc nepomohli, ale obvykle se to dělá opačně - určité skupině zařízení se dá konkrétní pool a/nebo fixed adresa (via DHCP), a prostup se nastaví na konkrétní range.
L2 security tam musíte mít tak jako tak, ať je ta síť čtyřková nebo šestková (a pokud nemáte, máte mnohem větší problém)
Je. Existuje spousta options, které jinak než přes DHCPv6 nepředáte. Vizte např. https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml
Například jde o bootfile
pro startování po síti, remote ID/subscriber ID
pro identifikaci portu, ke kterému je zákazník připojen, hostname AFTR (DS-Lite) nebo BR (MAP-E/MAP-T/lw4o6) koncentrátoru, parametry nastavení pro MAP-E/MAP-T/lw4o6, atp.
Samozřejmě se pomocí DHCPv6 předává i delegovaný prefix a seznam DNS serverů pro klienty, kteří nepodporují předávání seznamu DNS serverů v router advertisementech.
Pomocí DHCPv6 se i konfigurují přístupové sítě, např. DOCSIS routery mají na WAN straně IPv6 adresu přidělenou právě pomocí DHCPv6.
Pokud vystačíte s granularitou VLAN == subnet, tak to stačí, v kombinaci s fixní rezervací v DHCPv* to stačívá vždycky.
Jinak prosím, pusťte mě někam do sítě, kde si (po 802.1x autentizaci) můžu na L2 dělat z autentikované MAC co chci... A je mi jedno jestli na IPv4 nebo IPv6.
Technická otázka 1: Dojdu někam, kde je veřejná WiFi, připojím se mobilem a podívám se, že mám adresu 192.168.123.45. Za týden si nastavím na noťasu ručně adresu 192.168.123.67, přijdu tam a začnu používat WiFi. Pokud má někdo stejnou adresu, hodí mu to chybu , odpojí a připojí se a dostane jinou adresu, nebo si já ručně změním poslední byte v adrese. A začnu dělat nějaký lumpárny. Bude můj noťas v tom DHCP logu? Na takový podfuck totiž ani nemusí být člověk extra génius.
Technická otázka 2: Pokud mám obecný protokol na Ethernetu, zdroj a cíl v rámci segmentu sítě se předává pomocí MAC adresy. Že ji IPv4 zneužívá jako identifikátor zařízení v DHCP nechme stranou. Dejme tomu, že máme L2 switch, schopný udržovat tabulku MAC adres, spárovaných s konkrétní VLAN (802.1q). A po uplinku jdou v trunku pakety pěkně otagovaný - neznámý zařízení VLAN1, (klidně i soukromý) stroje zaměstnanců (po registraci na IT) jdou do VLAN10 - VLAN20 podle oddělení, třeba tiskárny a firemní stroje ve VLAN5,... No a v té chvíli se už dá hodit router mezi sítě s tím, že návštěva se dostane jenom ven, zaměstnanci můžou tisknout, ale nedostanou se na jiný oddělení. Potřebuju v té chvíli vědět, jakou adresu si nastavil Pepův noťas, když si chce stáhnout maily a stejně se ještě identifikuje nějakým tokenem na mail server? A je taa potřeba větčí, než když to udělá z obýváku za CGNATem a NATem ve světě IPv4?
Technická otázka 3: Nějaký šílenec zapojí firemní NTB do firemní Ethernetové zásuvky a nasdílí spojení přes vlastní WiFi návštěvám a ti se dostanou k něčemu, k čemu nemají. V IPv4 dostane jednu adresu a udělá si NAT, ostatní se protunelují (a teoreticky jich může být klidně 50k, pokud ignorujeme prostupnost WiFi). Je to horší, než když udělá to samý v síti IPv6, jeho NTB pošle RA s prefixem, klienti si pomocí SLAAC vytvoří adresy a on je pomocí ND zkontroluje v síti?
Technická otázka 4: K čemu potřebuju vědět IP adresu zařízení v síti, pokud se nechci s tím zařízením spojit jako se serverem? Kvůli policajtům to není, pokud nejsi ISP.
Technická otázka 5: Proč potřebuješ mobilům přiřazovat adresy na WiFI podle nějakýho komplexního schématu? Na to nestačí schéma "tady máte X/64 a dělejte, co umíte" dle pana Occama? Prostě neřešit bordel v jednom rozsahu X/64 a říct si, že to jsou jenom návštěvy, který neznám, nebudu je kontaktovat a nepustím do soukromí... ISP taky neřeší bordel za každou krabičkou v domácnosti, i když má sebepromakanější adresní schéma páteře.
Technická otázka 6: WiFi i s jeho parodiema na šifrování je takový nějaký ne moc bezpečný. WPA se hodí tak akorát k tomu, aby puberťáci z okolí neposedávali okolo firmy s mobilama v prackách. Proč ho nehodit prostě jako síť pro hosty s tím, že citlivý data z prověřených strojů po autentizaci zabalím do IPSEC tunelu nebo VPN či podobmé krávoviny a pak teprve pak pustím do privátní sítě? Hraje v tom scénáři nějakou roli verze IP protokolu?
Ideálně u 1) neprojdete přes první switch/ AP, protože komunikujete z IP, která Vám nebyla přidělena nakonfigurovaným DHCPv4 serverem. Myslím, že je to v podstatě kombinace DHCP snooping, IP source guard a možná dodatečně ARP snooping.
https://networklessons.com/cisco/ccie-routing-switching-written/ip-source-guard-ipsg
Podobné věci jde dělat s DHCPv6 a snad i SLAAC /NDP do jisté míry - tam snad potvrdí místní experti jako Radek Zajíc apod. jestli neblábolím.
2) možná nerozumím dotazu správně, ale pokud se připojil, byl strčen do nějaké VLAN a dostal IP z určitého rozsahu a spadá tedy do určitých pravidel, která umožňují přístup na email server, tak asi logging není potřeba, resp. bude se nejspíš logovat jaký uživatel se připojil. Kdyby připojení na email vícekrát selhalo, asi by se nějak genericky na určitou dobu účet zablokoval a možná i IP a v logu se vygeneroval nějaký přiměřeně výstražný záznam.
3) ta pravděpodobnost je dost nízká, ale dejme tomu, že se povede vytvořit takovou WiFi síť a ještě se přes takto nasdílenou WiFi chce vést útok. Nejjednodušší bridge mód samozřejmě lze omezit tím, že limituju počet MAC na jednom portu. (Takže IPv6 "bridge" tímhle asi není problém.) Vy říkáte u IPv4 NAT, tedy router. Hmm. Některé switche (Aruba) umí dnes vytvořit profil zařízení, které si připojuje a tím automaticky házet zařízení do určité VLAN a tedy IP rozsahu. Možná by tohle tedy vyhodilo nějaké hlášky, ale spíš o tom pochybuju/ neviděl jsem tohle v praxi. Rozhodně by ale Aruba AP s kontrolérem viděly, že je v oblasti nová neautorizovaná WiFi síť a tohle by hlášku vyhodit určitě mělo (ono to totiž ruší a u větších firem nejsou na pozemku cizí WiFi moc běžné, resp. tam budete mít slovíčko s adminem).
Všechno tohle je taky otázka perzonálu. Když si najímáte idioty nebo nekompetentní uživatele, tak jim nedávejte do rukou přílišné možnosti. Např. by měli vyfasovat notebook, kde je holt v korporátní síti možnost vytváření WiFi AP např. pomocí GPO nebo možná pomocí Intele ME, vPro nebo co já vím, jestli tam taková možnost je zakázaná. Takoví lidé by se svým notebookem měli vždy skončit v celkem neškodné VLAN s minimálním přístupem.
Když budete mít kompetentnější uživatele, tak tam můžete nad lecčíms přivřít oči - ale jde jim to na triko. Rizikové chování zaměstnance a tedy ztráta důvěry je důvod k okamžitému rozvázání smlouvy a náhradě škody myslím do výše 3 měsíčních platů (v rámci splátkového kalendáře). To si leckdo rozmyslí, vytvářet něco na vlastní triko.
4) možná kvůli push konfigurace, ale tam IP vím z několika míst, když je v takovém případě zařízení nejspíš v doméně.
5) Lepší WiFi AP (třeba i OpenWRT) umí klienty separovat. Dál je Vám asi jedno co dělají, protože ta celá síť má "00nic" oprávnění, kromě přístupu do internetu. Když je tam WPA2 Enterprise, tak mám u každého zařízení jednoznačný login, kdyby na firmu přišla policie, že host dělal na internetu nějaké nepravosti. V reálu ale tohle myslím střední a menší firmy neřeší dokud to není nutné.
6) Tak WPA2 Enterprise a lepší se dá asi nastavit poměrně bezpečně. Ale jinak ano, cest je mnoho.
Ad 1) neblábolíš, říkáš to naprosto přesně.
Dokonce by i síť, která nemá nasazenou IPv6 adresaci, měla používat IPv6 ochrany, aby si v síti kdokoli nemohl spustit RA/DHCP server. Analogicky i síť, která je interně IPv6-only, by měla mít aktivní IPv4 DHCP/ARP ochrany.
Cisco má k First hop security hezkou dokumentaci, která v podstatě shrnuje všechno, co potřebujete: https://www.cisco.com/c/en/us/td/docs/routers/7600/ios/15S/configuration/guide/7600_15_0s_book/IPv6_Security.pdf
1) Kolik drobných sítí typu kavárna, kde to dělal bratranec a středoškolský student, tohle asi bude mít? A je to jinak třeba v účetní firmě, která sedí s dalšíma deseti podobnýma firmičkama někde v pronájmu v paneláku, kdokoliv se může vydávat za potenciálního klienta a takhle čobnout bankovní údaje zákazníků?
2) Uživatel chce zadat příkaz k úhradě. Vezme mobil, spustí aplikaci, ta se připojí po síti [tady se to láme] k bankovnímu systému, který spravuje transakce. Bankovní aplikace je prostředek ke komunikaci s bankovním systémem. Obojí musí běžet na nějakým "železe". Prostě Učko jako u ISO/OSI. Vespod je síť, řekněme TCP/IP. Autentizaci klienta a jeho požadavků musí banka řešit na aplikační úrovni, IP stack je až pod tím. Nemusí a ani by neměl řešit protokol, kterým to teče, pokud je šifrovaný. Je jedno, jakou to teče sítí. Je jedno, kolik dalších strojů je u transakce v síti. Je jedno, jestli se mobil připojil přes LTE nebo WiFi... Tak proč se tady někteří snaží stavět bezpečnost na identifikaci HW, která se dá podvrhnout, zařízení se dá ztratit nebo s někým sdílet,...? Nebo jich mít několik (PC, tablet, mobil). Nemělo by se primárně řešit ne kolik je zařízení v síti a kolik mají spojení, ale kdo se zařízením pracuje a jestli smí dělat to, co chce udělat?
3a) Lidský článek bývá nejslabší. Stačí, aby IT oddělení zavedlo přísný pravidla připojení návštěv, obchodník byl líný deseti lidem žádat o tokeny a zapnul si na nudnou tříhodinovou prezentaci sdílení přes svůj noťas. A cizinci jsou, kde být nemají. WiFi pro návštěvy s heslem na cedulce u dveří a binec na jednom /64 prefixu pro hosty by ušetřil práci IT s vydáváním tokenů i obchoďákovi se sdílením sítě. Nebo se pletu?
3b) NAT nemusí být router jako fyzický HW. Když si spustím virtuálku, hypervizor jí IPv4 NATuje. Když sdílím na WiFi drátový připojení, tak těm na WiFi jede internet (s jiným prefixem) a při tom mám jednu IP adresu. Že by "překlad adres"?
3c) Omezení MAC na portu nic neřeší. Pamatuju, jak na kolejích v Brně omezovali net na jednu konkrítní MAC asresu / pokoj. Stačila krabička za 300 a nastavit správnou MAC na WAN a pařilo se na čtyřech strojích. Stavět na tom bezpečnost je mimo.
IP protokol je jenom o předávání dat. Tam má cenu max. klasický firewall (nikdo z venku nesmí na tiskárnu apod.). Jádro bezpečnosti služby musí stát na tom, že služba rozhodne, jestli se s klientem bude bavit nebo ne.. Takže bych neřešil počty strojů nebo přidělení adres, ale aby skončili ve správné zóně firewallu. Na to stačí hodit podle MAC do VLANy, v každé VLANě jiný prefix pro RA a zbytek už dá firewall. Šifrování nechat na IPSEC a oveření uživatele na příslušné službě. Proč to dělat složitě...
Snažil jsem se Vám co nejlépe odpovědět na to, jak jsem chápal Vaše otázky. Teď má z Vaší odpovědi pocit, že jste myslel při dotazech něco jiného, než na co jsem odpovídal. "Jeden o voze, druhý o koze."
Ano, spoustu věcí taky tak vidím, ale např. u 1) jsem neměl dojem, že bychom se bavili u sítí efektivně bez administrátora. Na druhou stranu nějaký lepší wifi router nejspíše některé z těch funkcionalit bude mít jako checkbox ve webovém rozhraní. Třeba v rozhraní LuCI z projektu OpenWRT je boxík na oddělení klientů bezdrátové sítě a jistě tam někde bude i DHCP snooping a možná i další. Nějaký FritzBox tohle jistě bude mít taky.
2) Asi jsme mluvili oba o něčem jiném. Samozřejmě banka nebude řešit nějaké VLAN v cizí síti, to je Vám ale určitě jasné. Mně ale nepřipadalo, že byste mluvil o nějaké bankovní aplikaci...
3a) Ano, lidé jsou často nejslabší článek. To jsem ale psal. Když je obchodník nezodpovědný/ jde proti pravidlům, tak podle stupně prohřešku z toho může vyjít bez problému, s upozorněním a nebo něčím pro něj horším. Obyčejně se prezentace sdílí vizuálně přes projektor a lidi na to koukají a když se něco domluví, tak se k tomu pošle email nebo tak něco.
Generovat příjemně jednorázové, třeba i skupinové účty na např. 12-24 hodin jde. Musí se vyjasnit, jaký problém chcete řešit.
3b) Ano, já to nevylučoval, ale mám pocit, že tu zase rozšiřujete zadání.
3c) Ano, vím. Taky vím o možnosti změny MAC atd. Mluvíme zde pořád ještě o stereotypu netechnického obchoďáka nebo někom, kdo tomu už celkem rozumí a dělá něco naschvál s dodatečným hardwarem/ softwarem místo nevědomky/ bez domyšlení důsledků?
S 802.1X lze autentifikovat i pomocí robustnějších údajů než MAC, ale už i ta MAC hodně věcí minimálně detekuje a víte, kam máte jít, protože si tam někdo hraje s kabely.
Poslední odstavec: Ano, psal jsem snad něco, co by tomu odporovalo? Bezpečnost se řeší ve vrstvách, já mluvil především o L2, L3 a podpůrných protokolech, jsme pod článkem o světě bez IPv4 a s IPv6-only.
Někdy je výhodné nebo i nutné brát informace z více míst a rozhodnout potom, resp. povolit více než je nějaký základ.
Vtip je v tom, vyfiltrovat spojení, která prostě s určitou službou vůbec nemají co mluvit. Někdy na to stačí info z L3, ale hlavně u sdílených počítačů to může vypadat už jinak. S některým např. Active Directory účtem se dostanete maximálně na email a s jiným můžete na celý internet a několik interních služeb a u těch se musíte dodatečně autentifikovat např. druhým faktorem nebo tak. Někde to bude dávat smysl, jinde ne.
Obyčejně se prezentace sdílí vizuálně přes projektor a lidi na to koukají
A nebo se prostě použije nějaké cloudové řešení, které možnost zapojení všech účastníků nabízí. Pokud někdo není schopen něco nabídnout, lidé si poradí a vyřeší to jinak. Pokud internet není schopen nabídnout přímé propojení počítačů v jedné místnosti, nabídne to někdo jako cloudové řešení. Síťově je to velmi neefektivní, ale funguje to. A správci sítě nad tím pak budou fňukat, že nad tím nemají kontrolu. Ale můžou si za to sami.
Ano, vím jaký je ten "důvod", ale to neznamená že to nevzbudilo odpor, a že jsou to naprosto zbytečné další klacky pod nohy. Pak se nelze divit proč je zavádění tak pomalé.
Kromě toho ten argument je přinejmenším velmi sporný - konkrétně tethering na WiFi interfacu zrovna moc smysl nedává (a i v případě privátního APNka by se dalo říct, že je vyloženě nechtěný, ale to odskakujeme od tématu), privacy extensions v korporátním prostředí taky nejsou to pravé ořechové.
Do toho si připočítejme omezení existujících firewallů v používání identit (ne všichni to dělají dobře, ne všichni to dělají rychle...).
@Jouda
Takže v ideálním případě vzít MAC adresu (kterou si můžu změnit) a na jejím základě přidělit IPv4 adresu. A ideálně se pak autentizovat MAC adresou do CRMka, mailů,... Ať má zaměstnanec pohodlí.
A pak se ani nemusí zloděj namáhat s kradením notebooku. Stačí mu vyfotit si výrobní štítek notebooku třeba někde na jednání. Ani silný heslo uživatele, šifrování disku a Kensington dohromady pak nezabrání, aby si dotyčný agent nedal na svůj notes nafocenou MAC adresu a v autě zaparkovaným v dosahu firemní WiFi si sosnul, co ho zajímá.
Prostě brzdou není IPv6, brzdou je víra, že jedno zařízení má jednu (nebo dvě, druhou pro WiFi) fixní MAC adresy, DHCP mu podle ní dá IP adresu a je to OK. Není. Furt totiž funguje i mechanismus přidělování, co byl ještě ped DHCP a vždycky platilo, že počet strojů v síti byl vyšší, než počet DHCP přídělů. A holt to platí i teď. Jenom se to /64 nevyčerpá tak rychle, jako 255.255.255.0
Ale no tak, straw man argument snad nemáme zapotřebí.
- Nikdo netvrdí že DHCP je všelék.
- Řeč byla o běžném setupu to znamená 802.1x, na switchích zapnuty všechny L2 ochrany co umí etc, na NB patrně zapnutý secureboot. Myslíte opravdu že opsání štítků stačí?
- Defense in depth je celkem fungující koncept, a jestli má mít na citlivější interní systém přístup 1000 userů nebo tři (resp zařízení) může docela snížit riziko při nějaké 0-day zranitelnosti (opakuji snížit, ne zabránit a určitě ne zabránit targeted útokům).
Tak secure boot je zrovna v tomhle případě vlatsňák. Když si přinesu vlastní železo, tak můžu bootovat z čeho chci, klidně z SD karty. Že má NTB, jehož parametry zneužiju, secure boot, nemusím nijak řešit.
Připojím stroj do sítě, ten se oznámí switchi/AP svou MAC. Protože ji síť zná, hodí ji do odpovídající VLANy a pokud je někde v těch mechanismech sebemenší díra, jsem v cizí síti (= za firewallem, oddělujícím vnější svět) a můžu se rozhlídnout. Poskenovat pěkně IPv4, podívat se po web serverech (třeba si pročíst wiki s interní dokumentací), mrknout na SMB sdílení bez hesel, projet NFS a když něco nechce heslo, tak to sosnout. Zjistit verze SW v síti, zmapovat topologii, nechat tam dáreček,...
To, že na svým stroji nemám token a některý systémy mě jako útočníka nepustí dál, u toho nemusí vadit.
Ohledně bezpečnosti se hodí každá překážka, o tom žádná. Ale jde o to, že nepřítel může být i ve vnitřní síti. Několik autentizačních mechanismů otráví uživatele a centrální bezpečnostní mechanismus vytvoří SPOF a když selže, firma nejede, nebo má nepřítel vše. Lepší je, když server bere všechny jako nepřítele, dokud neprokáže, že je přítel (ve smyslu SSH, tomu je jedno, jak se připojím, ale bez certifikátu mám smůlu). Potom i když někdo pronikne perimetrem, jsou mu informace o službě X na Y:Z k ničemu, pokud nemá token nebo nezná nějakou použitelnou zranitelnost.
Prostě jak mají IT v bývalé práci nad stolem, "paranoidnější přežije".
Navíc TCP/IP je rodina protokolů, která je univerzální a používá se nejenom v korporátech, kde platí specialistu na zabezpečení DNS, specialistu na zabezpečení ICMP,... A nikdo tady netvrdí, že zabezpečuje korporát na Ciscu, Juniperu atd. Ne všude bude všechno dostupný, aktuální a zapnutý.
No to, aby zariadenie fungovalo v IPv6 sieti netreba DHCPv6. To je v 99% pripadoch zbytocne, staci SLAAC. DHCPv6 chcu len ti, co su zvyknuti na DHCP v IPv4 sieti a myslia si, ze v IPv6 to musi byt uplne rovnako. Riesenim je doucit sa o moznostiach SLAAC a RDNSS.
Google ma zaroven velmi dobry dovod, preco DHCPv6 nepodporuje, ktori tito nariekajuci admini radi ignoruju. Je to tym, ze DHCPv6 umoznuje prevadzkovatelovi siete (teda aj mobilnym operatorom) limitovat zariadenie na presne jednu IP adresu a takto odpalit tethering. V IPv4 sa dal pouzit NAT, v IPv6 si na kazde tetherovane zariadenie alokuje extra IP adresu. Google samozrejme nedovoli tretim stranam odpalit popularnu featuru v jeho systeme a preto DHCPv6 nebude.
Zajimava teorie. Ale v praxi potrebujes oboje. SLAAC mas na domaci wifi. Ale ta wifi musi odnekud dostat prefix, kterej pres to SLAAC anoncuje a to pres SLAAC nejde, takze nastupuje DHCPv6 s prefix delegaci. To je bohuzel absolutni peklo, pokud mas dynamicky routovanou pater a i na staticky routovany pateri bys furt resil, ze DHCPv6 relaye neumi pri PD vytvaret routy. A samozrejme potrebujes nakej trochu lepsi SOHO router u zakaznika.
Pak je jeste reseni pres ebtables nastavit aby se v4 routovala a v6 bridgeovala, ale to uz musi bejt hodne specializovanej HW a napsat si na to nejakej vlastni framework, kterym to budes cely spravovat, bez toho se v nakym vetsim meritku neobejdes.
Pak jsou jeste nejaky ty pppoe, ale to je podle me brutalni retro prezitek, zbytecnej overhead a vlastne tim jen problem presunes na jinej stroj.
Ta wifi dostane prefix cez DHCP-PD. To, ci klientske zariadenia v sieti vedia DHCPv6 jej moze byt uplny sumak, oni si svoje prefixy pytat nebudu.
Podpora PD je vo vseobecnosti velmi slaba a zvycajne konci na tom, ze si CPE vypyta svoj prefix. Na tvorbu rout na chrbtici by som sa pri tom nespoliehal a pouzil nieco, co je na to urcene.
Tu sa ale dostavame velmi daleko od problemu, ze za nenasadzovanie IPv6 moze nepodpora DHCPv6 v Androide.
Nie, za nenasadzovanie IPv6 v CR/SR moze to, ze nasi ISP maju dostatok IPv4 adries a nasadzovat IPv6 (=davat peniaze, riesit problemy co teraz nemaju) teda nepotrebuju.
Ona IPv6 adresa se získává postupně. Od RIPE k LIRovi (řekněme ISP), přes páteř ISP (bity v IP adrese určují koncový bod a přípojku) k routeru zákazníka, pak ve vnitřní síti a nakonec mezi posledním routerem / APčkem ke koncovýmu zařízení. A v tomto platí následující pravidla:
1) Adresu /128 dostane koncový zařízení. Tím může být i router po cestě.
2) Koncový zařízení si může adresu vytvořit (např. SLAAC), nebo ji dostat (AHCP, DHCPv6,...), nebo ji může někdo nakonfigurovat ručně (obejde řetězec nebo jeho část ručně).
3) Pokud si generuje adresu, potřebuje si doplnit něco za prefix. Ten získá zase z DHCP nebo z RA.
4) Pokud dostane prefix z DHCP, nemůže jeho dárce použít autokonfiguraci (musel to někdo zadat ručně, nebo dostat pomocí DHCPv6 PD).
Android do toho vnesl postup, že pokud adresu někomu zprostředkovává, tak mu řekne prefix z RA, zařízení si vytvoří adresu, pomocí ND ověří její existenci (Android tlumočí do sítě, ve které je připojen) a adresu vezme na sebe. A pakety pro zařízení jenom přehazuje sem a tam. Takže se obejde PD i ruční zadávání. No problem. Specifikace přece říká, že v IPv6 zařízení může mít (resp. vždycky má) několik IPv6 adres.
ad.1 - Jak prosím pěkně SLAAC a RDNSS řeší to, aby určitá skupina zařízení v rámci jedné sítě měla přístup někam a optimálně o tom zvládl rozhodnout i ASIC? U rozumně implementované IPv4 (802.1x +DHCP snooping) je to celkem snadné.
s tím že v 99% je to zbytečné nepolemizuju.
ad.2 Ehm, Tethering funguje i na IPv4 a tam máte zaručeně jedinou adresu.
ad1) na zaklade 802.1x ich hodite do nejakej VLANy, ktora ma svoj subnet a z neho source ip su pustane tam, kam mozu? V tomto pripade nezalezi ci je to IPv4 alebo IPv6, funguje to presne rovnako.
Dobre chapem vas problem?
ad2) Na IPv4 mate NAT. Ved som o tom pisal:
V IPv4 sa dal pouzit NAT, v IPv6 si na kazde tetherovane zariadenie alokuje extra IP adresu.
V IPv6 NAT pouzit nemozete. Cisco malo chabe pokusy nejakych 10 rokov naspat, dnes to uz nikto neriesi a NAT66 je delegovany ako hracka pre geekov co nemaju co robit s volnym casom.
Cisco tam bolo spomenute v kontexte ze oni s ideou NAT66 prisli a zacali presadzovat, oni spisali IETF draft, atd.
To, ze je implementovany v linuxovom jadre nezmanena, ze to niekto aj realne pouziva a ze su vychytane problemy, ktore by NAT66 so sebou priniesol.
A okrem toho, nie je jedna z point nasadenia IPv6 to, ze netreba robit NAT? Tak pokial ho teda aj tak musime robit, naco vobec IPv6 nasadzovat a nezostat pri IPv4?
802.1x jede na L2 (MAC), IPv4 a IPv6 se rozlišuje až na L3.
MAC adresa se používá na L2 v rámci segmentu sítě. Stejně jako VLAN tag. IP protokol je až nad tím. V pracovně mám starý (cca 10 let) TP-Link TL2218 a budeš se divit, i na něm ta IPv6 projde a dokonce i do správné VLANy na uplinku.
Btw, nechceš po tom IP protokolu trochu moc?
1) SLAAC a RDNSS tohle neřeší. Myslím, že idea je (aspoň u kabelové infrastruktury), že je dost prefixů/ subnetů na to, aby bylo možné vytvořit dostatek sítí/ skupin nebo i hierarchii sítí/ skupin, aby se tyto požadavky uspokojily. Problém je tedy možná spíše ve Vaší koncepci než v technologii. U IPv6 máte dostatek adresního prostoru, tak ho můžete taky využít a potom nemusíte myslet v jednotlivých IP adresách. ACL mezi sítěmi samozřejmě ASIC zvládá a nebo můžete síť protáhnout na nějaký firewall pro jemnější nastavení, DPI apod.
U prefixu /48 máte dejme tomu 4 úrovně (když dělím na doporučených hexadecimálních cifrách, tedy nible a nejmenší síť je /64) a u každé úrovně 16 skupin. Když by to např. u velké společnosti nestačilo, tak jistě bude možné vyžádat si subalokaci větší, získat PI adresy nebo se stát LIRem.
DHCPv6 umoznuje prevadzkovatelovi siete (teda aj mobilnym operatorom) limitovat zariadenie na presne jednu IP adresu a takto odpalit tethering.
Provozovateli ethernetové/Wi-Fi sítě ano.
Provozovateli mobilní sítě ne, protože každý mobil získává od sítě pro každé připojené APN právě jednu routovanou /64 síť, takže si může použít adres kolik chce. Na tom je založena funkčnost 464XLAT v mobilní síti (zařízení použije pro 464XLAT další IPv6 adresu), na tom je založen tethering (technicky se to např. na Androidu realizuje tak, že se IPv6 /64 prefix přehodí z WAN rozhraní na LAN rozhraní; síť routuje veškerý provoz do APN tunelu a co s tím telefon udělá, to je jí jedno).
DHCPv6-PD v mobilní síti použít jde, ale obvykle to nikdo nedělá.
Keby len hry, tie ako tak IPv6 daju. Ale rozlicne modbus-tcpip alebo ems-tcpip bridge, ktore su kto vie kde vsade povesane. Vseobecne operacne systemy IPv6 vedia, ale rozlicne embedded hracky s proprietarnymi alebo minimalnymi tcp/ip stackmi su problem.
A ako perlicka: v IPv-6 only sieti nefunguje Chromecast.
Ano dá. Ale Vy jako poskytovatel potřebujete, aby to každému fungovalo pokud možno na první zapojení, aby většinu problémů kdy něco nefunguje odfiltroval levný L1 support a aby i ten byl pokud možno omezený.
Takže pokud "rozkaz ten zněl jasně, popíliť IPv4", tak ten důvod není, ale všude jinde rozhodnou ekonomické aspekty.
Jasně, všechno chceme levně, budeme na IPv4:
- "Lojzo, nestíhá CGNAT, přikup další mašinu. A zvedni zálohu na elektriku."
- "Haló, je tam ISPv4? Proč se nemůžu dostat z mobilu do domácí sítě? Zapnul jsem si podle návodu na routeru VPN a ono nic..." "Jo že jsem za CGNATem? A co to vlastně je?" Půl člověkohodiny v záchodě.
- "Pepo, už máme poslední tři IPv4 adresy, nevíš, kde levně sehnat další? Už je poptávalo 10 lidí." "Nevím, ale tuhle jsem viděl 16 adres za 15000."
- "Pepo, dneska to divadlo s Máňou budeš muset zrušit. Máme tady 20 nevyřízených tiketů na protunelování portů CGNATem k zákošům. Tn litr za propadlý lístky budeš mít v příplatku za přesčas."
Zatímco s IPv6 nepotřebuje mašiny na CGNAT, zákoš má veřejný adresy a nepotřebuje otravovat kvůli NATu a tunelování portů a adres jsou tři zadnice a ještě kousek - zadarmo. Bych rád věděl, co ja ne tom dražšího. Asi ty příplatky za přesčas, protože kvůli průšvihům se 4kou není na 6ku v normální pracovní době čas.
Ad divadlo...
Vyborne. V takovem pripade mate na krku v prvni instanci inspekci z uradu prace za zneuzivani prescasu a pokud se nespokojite s mensi pokutou soud vas nemine. Obvykle lidi pracujici v IT maji i penize na slusneho pravnika.
Jsem zvedav jak postavite nevyrizene tickety na protunelovani portu na uroven, kdy je treba udelat skutecne nutny zasah - zcela nefunkcni konektivita u zakaznika, prekopnuty kabel,na PoPu vyhorel router...
To ze mate SLA na tyto tickety postavene tak, ze zamestnanci nestihaji neni samozrejme problem zamestnancu ale jejich zamestnavatele v organizaci prace.
Byt zamestnancem tak dam samozrejme pri takovem jednani upozorneni zamestnavatele a okamzitou vypoved.
Asi v různých produkčních prostředích. A umí to různé bezpečnostní gatewaye dokonce v několika variantách, tady třeba FUDO Security PAM:
http://download.wheelsystems.com/documentation/fudo/4_2/online_help/en/intro/en/supported_protocols.html#
Známej asi před pěti rokama šel kvůli hraní hry k ISPíkovi a snažil se ho donutit políbit letící pěst. Chtěl pařit jakousi online gamesu a ta podporovala na jedné IPv4 max. 10 hráčů a ISPík měl za jednou adresou pět vesnic... Takže se sluníčkem bez mráčků nad světem her v IPv4 bych byl hodně opatrný.
"Dá nasadit za jediný den". Vím, že je to jen titulek, ale takováto formulace mě vždycky rozpálí do běla...
Příklad z práce. Přijde akademik, koukne se na kus softwaru, který má 1.5 milionu řádek a řekne "Vy ještě používáte XY na odesílání mailů? Proč? Dá se přece jednoduše za jediný den nasadit nový nástroj YZ."
Tak mu trpělivě začnete vysvětlovat, protože A, protože B, protože C... Všechno vyvrací, že to není problém. Ok, tak se ukaž. Zítra ráno ti to poběží všechno alespoň na lokále.... Uběhne 14 dní a akademik se drbe na hlavě a neví... Vymlouvá se na A, B, C a k tomu i D, E a F....
9. 6. 2020, 11:14 editováno autorem komentáře
Četl a stačilo mi prečist si "Přesto zůstala ještě nějaká další práce: zajistit monitoring IPv6 služeb....".
Takže takové 80/20. Ano za 1 den uděláme 80% "triviální" práce, ale to nepříjemné, ale zároveň extrémně důležité, to nám zabere dalších X dnů.
Tzn. odpověď je nedá. Protože bez rozumného monitoringu si solidní ISP netroufne cokoliv spustit. Chudáci lidi na 1st level supportu a vlastně i zákazníci, kteří nejsou znalí problematiky....
Zákazník: "Dobrý den, mě nejde youtube, ale stránky našeho hasičckého sdružení se mi načítají."
1st level support: "Restartujte router"
Zákazník: "Stále nejde".
1st level support: "To je chyba ve vašem PC"
A ono prd, vypadla IPv6 konektivita, protože na ní není monitoring a nikdo to neví...
Nevím, proč tady vedete třídní válku proti skupině lidí, které označujete akademiky. Víte, rodiče a prarodiče mi říkali, že tohle bylo populární za socialismu (ať už levý, nebo pravý extrém). Každý člověk je jiný a byl bych opatrný s tím házet lidi do jednoho pytle, i když k tomu často (i já) tíhneme pro zjednodušení popisu námi vnímaného problému.
U softwaru především záleží, jakou metodikou (pokud nějakou) se software programoval, jak to viděl management v té době, jestli to byli zkušení inženýři nebo spíš nějací kodéři za babku z nějakého *istánu, jak si lidi představovali nasazení toho softwaru a tisíc dalších aspektů apod.
Pohled z venčí od někoho, kdo má třeba robustnější teoretický základ a hlavně různorodé zkušenosti je často k nezaplacení. Že všechno nejde úplně podle odhadu i těch největších odborníků je důvod, proč jsou delší a větší projekty pocitem exponenciálně složitější a prakticky neodhadnutelné z hlediska náročnosti. To je mj. důvod pro vznik různých agilních vývojových metod místo vodopádu.
Konečně k jádru věci, já si vážím toho, že to Blažej Krajňák zkusil, na rovinu svoje zkušenosti (podle mého pěkně) popsal a očividně dotáhl za jeden den hodně daleko. Možná, kdyby mu někdo pomohl nebo na tom seděl ještě později do noci, tak by těch zbylých +-20% taky dal(i).
Třeba u Icingy (a u Zabbixu to asi bude podobně) je u každého hosta políčko IPv6, a to políčko skriptem analogicky k IPv4 doplnit je otázka tak hodiny dvou i s psaním toho skriptu. To by jistě pokrylo aspoň relevantní vzorek.
Ono taky je otázka, co si pod nasadit představujete. Jestli je to 100% funkčnosti všeho tzv. do poslední mrtě, tak to u různých projektů nemusí být reálné resp. to není cíl. Když stavíte dům, tak taky neříkáte, že je hotový až když jsou lidé nastěhovaní i nábytkem, mají navrtané všechny poličky a tráva kolem je vzrostlá. Ale to je cíl těch lidí, co si ten dům koupili a obyčejně až tehdy pozvou svoje přátele na "kolaudaci".
Nebo jinak vyhledávač Google taky nevypadal pořád tak, jak vypadá. Některé věci jsou prostě hotové, když jsou použitelné a ne až když jsou dokonalé, protože dokonalost je subjektivní a hlavně pohyblivý cíl. Asi chci napsat, že s jedním "hotovo" často vzniká nový úkol. A taky, že "existence určitého software/ systému mění předpoklady pro svojí existenci". (Což řekl někdo, kdo o tom přemýšlel ještě předtím, než já jsem nastoupil na základku.) Nebo taky "po bitvě je každý generál", ale předchozí myšlenka je hlubší.
Bohužel srovnáváte nesrovnatelné. Dům je soukromá záležitost, nemusí být dokonalá aby byla obyvatelná, protože vy jste uživatelem a akceptujete to. Pokud jste developer a dům stavíte pro někoho jiného, a chcete za to peníze, tak nedodělky nejsou přípustné. Zmíněný sw google nebyl dokonalý, nicméně, v rámci návrhu, byl 100% funkční a veškerý další vývoj byl o opravách drobných chyb (v obchodě se tomu říka reklamace produktu), a o přidávání nových věcí které v původním návrhu nebyly.
Pisatele, s veškerou úctou a respektem k přednášejícím a autorovi článku, chápu. IPv6 za jediný den nasadit nelze, přinejmenším ne u ISP který chce poskytovat spolehlivé a bezpečné služby, včetně podpory koncového klienta a to zejména na heterogenních sítích typu wifi+FTTB+FTTH, s xPON jako bonus. Mne to taky trochu nakrklo, protože takové dezinformace pak vedou ke zcela zbytečným konkfliktům se zákazníky typu "ale na rootu psali....." Root.cz považuji za relativně seriózní médium.
Jsme regionální ISP a IPv6 máme nasazeno, pro všechny klienty na vyžádání a otevřeně říkám, politika ke klientům je: pokud IPv6 nepotřebujete k něčemu konkrétnímu nechte to vypnuté, ušetříte sobě i nám bolení hlavy s diagnostikou problémů které bez IPv6 nejsou.
Zdaleka nejhorším problémem je tristní stav podpory a zabezpečení v CPE. Jediným slušným řešením je trvat na námi dodaném CPE pod naší správou, ovšem to sebou nese náklady které nejsou v současné situaci na trhu únosné. Podívejte se pravdě do očí, žádný běžný uživatel nezaplatí 2000.- ihned, nebo 50,- měsíčně navíc, jen proto aby měl nějaké IPv6 které evidentně nepotřebuje, když to jede i bez toho.
Bezpečný provoz IPv6 v komerčních zařízeních typu antispam, VPN koncentrátory, streaming servery, CCTV a bůhví co ještě, je iluze, bez otestování v reálných podmínkách je zapnutí IPv6 hazard s daty klientů, protože navzdory marketingovým ujištěním prodejců je skutečná podpora IPv6 v plném rozsahu funkčnosti spíše výjimka, dual-stack navíc krajně komplikuje konfiguraci, protože většina techto věcí má IPv6 programovánu jako add-on, nikoliv jako organickou součást návrhu od začátku. To se podepisuje na nepříjemně vysoké míře zabugovanosti i u renomovaných výrobců.
Monitoring služeb nelze udělat za den. Rozšířit doménový systém o IPv6 včetně PTR a naplnit horelevantními daty, nelze za den. Proškolení technícké podpory nelze za den.
Pokus jak u ISP, tak ve zmiňované škole je rozhodně kus dobře odvedené práce a před správci smekám, že se do toho pustili a hlavně to zdokumentovali. Ovšem zapnout [IPv6] a poskytnout kvalitní službu jsou dvě diametrálně odlišné věci.
no, to že se to dá nasadit za jediný den, to je trestuhodné zjednodušení. Jinak je ten článek celkem zajímavý, bohužel titulek je značně zavádějící.
Chápu že v žurnalistice je nutné čtenáře upoutat titulkem. Přesnější bylo nasadit za jeden den po několikatýdenní přípravě a je to skoro funkční, ale takový titulek neupoutá, že?
Vede to ovšem k tomu že geekové kteří chtějí IPv6, z libovolného důvodu, nadávají technické podpoře proč tahle, z pohledu 99% platících klientů postradatelná věc, nefunguje.
Z mých zkušeností technický personál u ISP většinou opravdu chce zavést IPv6, ale uvědomují si že to nelze metodou hop na krávu, ale musí tomu předcházet důkladná analýza, většinou simulace v labu a pak na omezeném vzorku klientů a nezbytný je poměrně dlouhý zkušební běh, minimálně v řádu týdnů, spíše měsíců a to u klientů kteří jsou srozuměni s tím, že občas bude potřeba řešit problémy.
Klienti nechtějí slyšet, že nejde odeslat mail na google, protože mají zapnutou IPv6 a mailserver si vybral špatnou IP, když je na multihome.
Nezajímá je, že nezobrazí seznam.cz, protože DNS resolver má problém s DNSSEC na IPV6, která je najednou primární.
Budou se zlobit, že se nedostanou na své intranetové stránky přes VPN, protože jejich VPN není nakonfigurována pro IPv6, ale prohlížeč má IPv6 funkční, takže nějaké směrování přes VPN ignoruje.
Jsou to stovky drobností, které je nutné vyřeši před nasazením a to prostě nejde udělat za den.
10. 6. 2020, 11:13 editováno autorem komentáře
MKA252: Kdyby bylo možné obsah článků vtěsnat do nadpisu, nebylo by potřeba psát ty články. Titulek je vždy zjednodušení. A podle mne ten titulek článku odpovídá. Není tam nic o plánování nebo přípravách, jenom o samotném nasazení. Ta hlavní informace je, že při nasazování IPv6 není potřeba mít síť měsíce v nějakém rozvrtaném stavu, kdy se IPv6 nasazuje postupně na jednotlivá zařízení. Ale ISP téhle velikosti zvládl to skutečné nasazení za jediný den – a není to žádná teorie, je to popis akce, která skutečně proběhla. Já na tom nic trestuhodného nevidím.
Podle mne zkrátka polemizujete s něčím, co v tom článku ani v titulku není.
:-) to chcete říct, že ten ISP nestrávil nějaký čas plánováním a přípravou? jenom se pořádně vyspal, vypucoval si zuby a vrhnul se na to? Tomu přece sám nevěříte. Ano malý ISP s limitovaným počtem technologií a CPE kompletně ve své správě může aktivovat konektivitu za jediný den. Další hromadu dní stráví řešením problémů u klientů kterým něco nejede.
Stojím si za tím, že "IPv6 se dá u poskytovatele nasadit za jediný den" je zavádějící a silně zjednodušující titulek. Na druhou stranu mne motivoval si to přečíst, protože mám dost přesnou představu jak vypadalo nasazování IPv6 u nás. Chtěl jsem vědět, jestli jsme takové lamy. Z tohoto pohledu je je titulek zvolený vhodně, přitáhlo to čtenáře, :-)
I zde v diskusi je ostatně jako první komentář proč to nemá mobilní operátor - poměrně jasný důkaz jak zjednodušující dojem to vyvolává. No prostě proto, že nemá motivaci vyhodit hromadu člověko-hodin na aktivaci služby s minimální komerční hodnotou v rozsahu sítě s stovkami tisíc zařízení. Zcela ponechávám stranou bezzubé implementace typu DS-Lite, nebo přidělění jednoho /64. To je jen marketingový pokus aby se geek nažral a síť zůstala funkční. Vodafon se rozhodnul IPv6 nenasadit a možná proto, že pokud to nemůže/nechce udělat pořádně, nedělá to vůbec.
Ještě jednou opakuji, smekám před těmi, co IPv6 nasadili a jede jim to. Navzdory tomu co se tvrdí na fórech, udělat IPv6 v komerční sféře dobře, spolehlivě a bezpečně, není jednoduchá věc. Komu se to podaří, tomu fandím.
Taky by mě to zajímalo. V Německu má určitě tak 90%+ lidí s připojením WiFi router, který stojí kolem 150 €. Kabelové routery pro DOCSIS taky nejsou zrovna za babku. Skoro bych si troufl tvrdit, že 2000 Kč je spodní hranice nabídky za router od běžného poskytovatele. Ne, že by to nešlo levněji, ale i to má svou cenu.
https://www.telekom.de/zuhause/geraete-und-zubehoer/wlan-und-router
Aktuálně nejlevnější zařízení v naší nabídce s podporou IPv6 jsou mtiky řady 951/952. Záleží na klientovi jak moc chce řešit řízení vnitřní sítě a domácí wifi, jak moc potřebuje třeba wifi distribuci přes několik pater RD přes CAPs a podobně. S prvotní konfigurací asistujeme vždy, abychom měli jistotu že si tam nenastaví nějaké nesmysly třeba v OSPF nebo mcast routingu.
V základní ceně je zahrnuto dovezení, zprovoznění, konfigurace klientova zařízení (obvykle hlavně telefony).
Routování se řeší staticky, bez PD, prostě proto, že mtik tohle neumí *spolehlivě* a při nezbytném výjezdu technika na místo je v pekle příjem od klienta za několik měsíců. Do zařízení má pak přístup technická podpora a většinu požadavků klienta řešíme na dálku. Většinou je to zapomenuté heslo k wifi.
Co se týče IPv6, do LAN se v základu pustí jedna /64 a SLAAC.
Ve chvíli kdy má klient složitější požadavky a evidentně ví co chce, končíme s dálkovým dohledem, předáváme přístupy do zařízení (je jeho) a necháváme to zcela na klientovi - jeden router, jeden správce.
Levnější routery třeba od TP-Linku a podobných mají sice podporu pro IPv6, ale zásadně ji vypínáme, protože ty hračky zpravidla nelze rozumně konfigurovat.
Moc se mi líbí stránka https://ipv6excuses.com/
U cca 75% těch "excuses" NENÍ odkaz na zdroj který by tu výmluvu vyvracel.
Já to čtu tak, že to teda není výmluva, ale fakt o IPv6. ;-)
Strávil jsme pěkných pár chvil nad knížku IPv6 od páně Satrapy (tímto děkuji NIC.cz) a dospěl jsem k závěru, že protokol který měl našlápnuto změnit Internet, je nepodařený, zaplevelený, záplatovaný a zfušovaný paskvil.
Snad IPv6 uzraje, ale za 25 let se mu to nepovedlo což ukazuje i tento článek. Článek nepopisuje jak nasadit IPv6, ale že s IPv6 jsou stále, stále, stále a pořád potíže.
No nic, počkám na IPv7 nebo IPv8.
11. 6. 2020, 13:50 editováno autorem komentáře
Máte pravdu, pokud za „krásně napsáno“ považujete to, že je to čistě sbírka dojmů, že počet argumentů, které by se dali ověřit nebo vyvrátit je čistá nula, a že je to tvrzení, kterému můžete jen slepě věřit. Pokud by odpůrci IPv6 opravdu neměli žádné argumenty proti IPv6, byla by to vlastně dobrá zpráva. Obávám se, že že ve skutečnosti je to jen tak, že někdo prostě nemá žádné argumenty ani pro jednu ani pro druhou stranu, tak se prostě náhodně přikloní k jedné straně – a o to tvrdším zastáncem pak je, protože si potřebuje dokázat, že si vybral správně. Akorát ti, kteří se takhle přikloní k IPv6, to mají horší – protože brzo narazí na „tak to předveď“, musí se IPv6 reálně zabývat, takže konečně nějaké argumenty získají a nemají pak potřebu obhajovat svou volbu výroky bez argumentů.
Já zkušenosti s IPv6 mám a právě proto jsem napsal, že souhlasím s komentářem uživatele PQK.
Léta jsem provozoval dual-stack na serverech a v několika propojených sítích, ale časem mě to přestalo bavit, protože jsem musel všechno nastavovat dvakrát (adresy, firewall, OSPF, BGP, DNS, ...) a nic mi to reálně nepřinášelo, jen zbytečnou práci.
Ano, zkušenost s IPv6 provozem nemám, nikdy za 25 let jeho existence jsem nenarazil na službu kterou bych potřeboval a ona nefungovala na IPv4. Pokusy o zprovoznění IPv6 - většinou dlouhé, bolestné a končící návratem k původní konfiguraci - nepočítám.
Knihu pana Satrapy jsem četl dvakrát a to před RFC 8200 i její update po RFC 8200.
A stále si myslím, že IPv6 mohlo změnit Internet, bohužel ho tvůrci efektivně zmrzačili, záplatovali, zkriplili a RFC 8200 na tom mnoho nezměnilo.
PQK: To teda moc zkušeností nemáte. Jenom když si přečtete aktuální výpis dotazů zde na fóru, narazíte minimálně na jeden dotaz, jehož příčina je v nefunkčnosti IPv4, protože IPv4 nemá dostatek adres – Z domova, se nedostanu na svou doménu, která má směrovat ke mě domu. A takovéhle problémy řeší pořád někdo.
A stále si myslím, že IPv6 mohlo změnit Internet, bohužel ho tvůrci efektivně zmrzačili, záplatovali, zkriplili a RFC 8200 na tom mnoho nezměnilo.
Nevím, jestli lze „myšlením“ nazývat opakování nic neříkajících frází. Klidně můžu tvrdit, že zmrzačené, záplatované a zkriplené je IPv4. A podle mne to mnohem víc sedí na IPv4 než na IPv6. Dokud se ale budeme pohybovat jen v rovině nicneříkajících nálepek, nedá se to rozhodnout.
:-) no většina toho co tam je uvedeno opravdu jsou výmluvy, některé dost hloupé, nicméně pořád chybí ta hlavní motivace k nasazení IPv6 - něco co funguje na IPv6, nefunguje na IPv4 a zároveň to lidi (čti: významné procento platících zákazníků) chtějí. Tahle "killer app" se prostě neobjevila, třeba v budoucnu.
Mimochodem ne-podpora DHCPv6 v androidu. Myslím že je to dobrá věc. DHCPv6 bylo dlouho mimo návrh IPv6 a kdyby nebylo v původním návrhu ignorováno DNS-RNS a DNS-SL, nejspíš by stále bylo mimo hru. Android je platforma která může přimět výrobce routerů ke správné implementaci SLAAC. V sítích kde je nutný accounting lze DHCPv6 nahradit pomocí PPPoE, které je na to ostatně vhodnější.
Z DHCPv6-PD mám smíšené pocity. Ano může to pomoci při přeadresaci bloků, například při migraci sítě z jednoho AS do jiného. Ve všech ostatních případech mi to přijde jako "něco dalšího co se může pokazit".
Kdykoliv pracujete s páteří a platícími klienty by mělo platit KISS - keep it simple stupid.
Nu, zatím všechny killer apliakce skončily dříve, než se ujaky (jako bylo ipv6porn.com a spol. :-) ). Je to o tom, že majoritu zákazníků necítí potřebu IPv6.
Bez toho DHCPv6-PD to bohužel nejde. I v tom PPPoE spojení bez něj nedostanete prefix pro LAN. Že je zpraseně implementováno v řadě zařízení, tak o tom by se daly psát romány. I v tom Mikrotku trvalo dost dlouho, než se dostalo do "akceptovatelné" úrovně a stále to neumí vše.
„...pořád chybí ta hlavní motivace k nasazení IPv6 - něco co funguje na IPv6, nefunguje na IPv4 a zároveň to lidi (čti: významné procento platících zákazníků) chtějí. Tahle "killer app" se prostě neobjevila, třeba v budoucnu.“
Už se to tu řešilo - není to úplně pravda. Jsou věci, které fungují lépe či levněji přes IPv6, např. bittorrent (NAT), hry (NAT, blokování adres), VoIP (STUN), sítě bez NATu obecně (náklady). Ale asi to ještě není dost killer, možná jen proto, že to za uživatele obvykle vyřeší někdo jiný. Ale taky právě proto nepřísluší uživateli rozhodovat, co se kde v inetu bude přenášet kterým protokolem.
Jenže taková "killer app" se pravděpodobně ani neobjeví. Pokud významné procento zákazníků něco chce, tak dává ekonomicky smysl to ohákovat pro IPv4 a ne čekat na prostředníky, kteří z toho vlastně nic nemají.
Že se IPv6 neujalo není díky vlastnostem IPv6 ale díky tomu, že se IPv4 stále daří tak nějak udržovat v chodu. A náklady na to udržování IPv4 v chodu musí platit všichni. Jakýkoliv nový protokol jsou dodatečné náklady a je úplně jedno, jestli jsou velké nebo malé.
Na IPv6 (a jakýkoliv jiný protokol) se bohužel kompletně přejde až ve chvíli, kdy se IPv4 rozbije tak, že už to nepůjde poslepovat.
Presne tak, zadna killer app se neobjevi.
Vzdy se objevi neco jak resusitovat IPv4.
At uz jsou jsou Facebook ci LinkedIn takovi nebo makovi, tak zcela spravne uz pochopili status v4 vs v6 a uz se preklopili do modu nativni v6 vsude, v4 pouze jako sluzba.
Proc? Protoze je v4 pro ne omezujici a resuscitace v4 / vymysleni berlicek nedava smysl technicky ani ekonomicky.
Stejně, jako se nejspíš neobjeví žádná „killer app“, která bude fungovat jen na IPv6, neobjeví se nejspíš ani žádný jeden velký problém, který by najednou zabil IPv4. Spíš se postupně začnou objevovat služby, které budou dostupné jen po IPv6. Nejdřív to bude vědomé rozhodnutí („platit za IPv4 adresy se nám nevyplatí“) a pak už to čím dál častěji bude brané jako samozřejmost („o IPv4 jsme ani neuvažovali, kolik promile lidí vlastně nemá IPv6?“). Podobně jako se třeba na webu vytrácí podpora pro MSIE.
Už dnes je u levných VPS IPv4 adresa za příplatek. A jsou trhy, kde se dá na podporu IPv6 spolehnout – mobilní sítě v USA, nejspíš některé asijské trhy. Takže si provozovatelé zákonitě začnou klást otázku, proč by si vlastně měli připlácet za IPv4, když to nepotřebují.
Ne, pro server se nějaká ta IPv4 nenajde. Pro server se nějaká ta IPv4 zaplatí. A bude čím dál dražší.
Těch 99 % je také číslo vycucané z prstu. Jeden uživatel chce hrát on-line hry, další se chce dostat na domácí NAS i z mobilu, jiný chce s někým komunikovat přes videochat přímo, ještě další chce přes internet ovládat domácí topení.
Ne. On-line hry jsou dávno řešeny centrálními servery. Stejně tak všechny ty nesmysly typu "chytré" zásuvky. Normální člověk (nikoli geek) fakt nemá ovládní baráku postavené na RPi a desce s relátky. A ani ty torrenty už netáhnou jako kdysi. A neznám nikoho kdo by doma provozoval NAS. Takové věci z pohledu běžných lidí smrdí černou magií.
Navíc i kdyby všichni měli veřejnou IP, tak u chytré zásuvky bude uživaelsky přívětivější řešení přes server výrobce, které funguje out-of-the-box, než aby uživatel musel zjišťovat IP toho bazmegu, povolit ve firewallu pro zařízení příchozí komunikaci,... Umíte si představit, že to dělá vaše matka?
Je třeba vylézt z ajťácké sociální bubliny a přijmout realitu. Prostě internet se změnil. Už to není o komunikaci každý s každým, je to celkem jasně rozděleno na poskytovatele služeb a konzumenty služeb. Konzumenti spolu obvykle přímo komunikovat nemohou, ale současně to nikomu vlastně nevadí. Může se nám to nelíbit, můžeme protestovat, ale to je všechno.
Mno ... na Internetu jsem od roku 1997 a mimo akademickou sféru to neplatilo ani tehdy ... Možná u EUnetu, ale ty ceny efektivně blokovali uživatele mimo státní správu a firmy které to fakt, ale fakt nutně potřebovaly. U běžných firem to fakt bylo jinak.
Ano přístup k IP byl bezplatný, ale určitě ne neomezený. Spousta firem neprošla byrokracií u RIPE a upstream provideři taky nebyli úplně vstřícní.
Pokud mluvíte o předkomerční (akademické) éře, tak možná jinak by Internet doménizovaný NATem velice brzo.
Jak bylo řečeno, pro uživatele může být IPv6 přínosem, aniž by to věděli, ale o přínosu poskytovatelům se taky mluvilo. Osobně si myslím, že lámat se to začne, až se u většiny zákazníků objeví zařízení, která IPv6 propustí, jinak je tam IPv6 jen, aby tam bylo. Myslím si, že další věc, která by pomohla, by byl poskytovatel služby tunelu/překladu, který by odlehčil poskytovatelům ve správě - zjevně amatérských poskytovatelů, co nemají veřejné IPv4 a perou se s provozem a nastavením CGNATu, je dost.
Tohle asi mělo být na mne. Ve světě od LIR nahoru je všechno statické a provázané s routovacími protokoly (BGP). DHCP (4 i 6) byla vždycky záležitost konfigurace koncového stroje a měla patřit do LAN. SLAAC to nijak nemění. DHCP-PD svět LAN opouští a chápu že je to pro malé ISP lákavá alternativa.To že u nás existuje obrovská hromada malých ISP, kteří by se z toho zbláznili kdyby měli každou minisíť konfigurovat ručně, je neoddiskutovatelný fakt. To že jim DHCP-PD zpříjemní a zjednoduší konfiguraci CPE které jsou zvyklí konfigurovat dynamicky je taky fakt. Systémové to ale není, ISP tím prohlašuje předposlední hop za de-facto LAN, což je špatně. Internet má končit na rozhraní CPE.
Bohužel uznávám, že v současné době neexistuje rozumná alternativa. U velkých ISP to řeší tr069, mnohem komplexněji než nějaké DHCP-PD. Pro ty menší toto není cesta. Nejsou kvalitní free servery, není dostatek cenově dostupných CPE které by to podporovaly.
I v naší síti jsou klienti s IPv6 konfigurováni staticky - spojovák /64, přidělená síť /48, nazdar bazar, tady to máte a je to trotlfest. Ve chvíli kdy naroste míra požadavků na IPv6 nad míru spravovatelnou ručně, půjdeme pravděpodobně do tr069 provisioningu. Aktuálně se ovšem zájem o IPv6 pohybuje někde okolo 0,02% koncových zákazníků. Nepočítám server a webhosting, to je úplně jiná pohádka, ale i tam je pochopitelně vše staticky.
„Aktuálně se ovšem zájem o IPv6 pohybuje někde okolo 0,02% koncových zákazníků.“
Tato věta je nesmyslná. Kdybyste se zeptal, jaký je podíl IPv6 v provozu zákazníků, kterým jste to zavedli, tak to jsme někde jinde, ale ptát se zákazníka, zda chce IPv6, když neví, co je to IPv4, je hovadina. To není argument, to už se tu řešilo.
„Systémové to ale není, ISP tím prohlašuje předposlední hop za de-facto LAN, což je špatně. Internet má končit na rozhraní CPE.“
Tomuto jako neznalý nerozumím, ocenil bych, kdyby to tu někdo znalý rozebral - proč zrovna předposlední, proč LAN a co zde znamená slovo „internet“ (administrace poskytovatelem?).
Skoly nemam, ale RFC v podstate realne pocitaji jen s DHCPv6-PD pro ziskani prefixu od ISP a naslednou konfiguraci LAN. RFC pro prefix delegation explicitne zminuji jako priklad nasazeni DHCPv6-PD klienta na CPE.
Znate nejakeho operatora, ktery by prefixy konfiguroval pomoci tr-069? Ja ne.
Rucne? Mozna, ale neskaluje to.
https://tools.ietf.org/html/rfc7084
https://tools.ietf.org/html/rfc8415
https://tools.ietf.org/html/rfc3633
upřímne, neznám.
Na školení GPON nám to bylo prezentováno jako možnost konfigurace ONT a zdá se to celkem reálné, ale tr069 nasazeno nemáme, takže vycházím z informací od školitelů (2018). Hlavně proto že TR-069 server jako třeba Genius ACS je pro naše potřeby moloch a podpora v CPE je minimální.
Zmiňované RFC samozřejmě znám, ale vznikly jako víceméně jako škálovací mechanismus pro DHCPv6, když se ukázalo že o DHCPv6 opravdu je zájem a správci si chtějí zjednodušit práci s konfigurací CPE routerů. To je legitimní požadavek, do té doby se (v IPv4) na LAN stranu prostě plesklo IP podle RFC1918, pokaždé stejné a bylo hotovo. S IPv6 kde by měly být všechny IP veřejné toto již nebylo možné. Taky vznikly pokusy typu site-local IP, NAT66 a podobně, naštěstí to neprorazilo. Díky nefunkčnímu RDNSS a DNSSL se DHCPv6 ujalo, ale pořád je to kočkopes, dva mechanismy na zprovoznění jedné konektivity. DHCPv6-PD je logickým rozšířením a řekněme funkčním, leč nikoliv nezbytným.
Nijak nerozporuji platnost RFC pro DHCPv6-PD. Je funkční dostalo se to do světa a používá se to, stejně jako DHCPv6 pro koncové stanice. Nebylo ale součástí původního návrhu, tam se pro konfigurace koncové stanice používala výhradně statika nebo SLAAC. To je prostě vývoj. U nás jsme nikdy neměli potřebu používat DHCP pro přidělování IP, ani pro accounting. Statická konfigurace je pro nás prostě alfa a omega, síť je přehledná a stabilní, nezávislá na funčním DHCP na úrovni ISP, není ohrožena rogue DHCP z vadných a špatně konfigurovaných klientských CPE, prostě to funguje.
IPv6 funguje, věřte nebo ne, úplně stejně, bez DHCP mechanismu.
Škálování prefixů. Pořád nechápu, proč bychom to měli dělat. Přidělíme klientovi /48 za spojovákem, přesně podle doporučení RIPE, a fertich. Škálovat dolů nemá smysl, adres je dost. Škálovat nahoru taky ne, pokud někdo potřebuje více než jednu /48, tak je to sakra velká organizace a nepotřebuje obezličky jako DHCP na management vlastních adres.
Klient typu ISP by si měl zaregistrovat vlastní rozsah, je to ostatně i doporučení RIPE, rádi mu to propojíme.
0,02% klientů se zájmem o IPv6 není kec, je to naprosto přesné číslo, dnes jsem to pro jistotu počítal. A půlku z toho dělají státní příspěvkové organizace které musí mít IPv6 kvůli dotacím a ve skutečnosti je jim to celkem fuk. IPv6 aktivně nenabízíme, protože podle našeho pohledu nepředstavuje přidanou hodnotu. Zájemce ale neodmítáme.
Serverhostingy do toho nepočítám, je to úplně jiná část klientely.
Tahle odpoved mi unikla, pardon.
Diky za komentar k TR-069, cas ukaze, jestli to bude/nebude realne nasazovana varianta konfigurace delegovaneho prefixu. Zatim neni.
Kockopes dvou mechanismu pro konfiguraci adres se mi nelibi, ale nezbyva mi nez s nim zit, protoze jsou scenare, kdy se bez jednoho nebo bez druheho neobejdu. Bohuzel.
Skalovanim jsem nemel na mysli skalovani velikosti prefixu (/48, mensi, vetsi), ale skalovani konfigurace. Pokud mate jednotky klientu, tak rucni konfigurace mozna je. Hromadne jednorazove nasazeni IPv6 by se asi dalo naskriptovat (a mozna to bude jednodussi nez implementovat funkcni DHCPv6-PD). Nasledny rucni provisioning IPv6 kazdemu novemu klientovi by nicmene zabral cas technika, ktery by v souctu udelal velkou nakladovou polozku, na rozdil od automatizovanych procedur typu DHCPv6-PD nebo i toho TR-069. To jsem mel na mysli tim, ze rucni konfigurace neskaluje.
Nizky pocet klientu, kteri si aktivne reknou o IPv6, je normalni. Stejne jako si vetsina nerekne o konektivitu do IPv4 sveta, a presto ji dostava. Nebo si nerekne o eCall v novem aute, a presto ho dostava. To je rozvoj.
Už jen krátce, článek stárne :-)
Statická konfigurace pro nás není problém, přestože se počet klientů pohybuje v pětimístných číslech. Nepředpokládám že by měla být pro IPv6, protože reálně přidaný čas je maximálně tak minuta - vyzkoušeno. Je ovšem pravda, že nezanedbatelnou část práce za nás dělá informační systém, který se stará o zavedení klienta do účetního, evidenčního a shapovacího systému včetně nalezení volné IP na základě vybrané lokality. Úplně úplně ručně bych to řešit rozhodně nechtěl.
Zájem je pro mne požadavek na přidělení IPv6 rozsahu. V tomto je to poměrně přesný podíl přípojek s a bez IPv6. Podíl provozu u dual-stack přípojek je pro změnu irelevantní pro nás. Transportujeme data a jestli to bude pomocí IPv4, IPv6 nebo CPIP, je nám úplně jedno, proč by nemělo být?
V tom druhém. Omlouvám se za vágní termíny. Je nám proti srsti (dynamicky a kontinuálně) konfigurovat hraniční zařízení které patří klientovi. Mezi námi a klientem je přesně definované statické rozhraní a pro jeho změnu je potřeba vědomá akce obou stran. LAN je pro mne část sítě spravovaná koncovým uživatelem, který dále nepřeprodává konektivitu. Předposlední hop je mezi CPE a prvním routerem ISP. Považuji to za nejzažší bod veřejného internetu, protože na CPE končí síťová neutralita.
Dynamická konfigurace CPE které není naše nutně bude dříve nebo později předmětem konfliktu a nejasností kdo je je za co zodpovědný.
Vedlejším problémem je závislost na funkčním DHCP serveru. Proč přidávat další věc která se může pokazit, když to není potřeba.
-> MKA252:
„Zájem je pro mne požadavek na přidělení IPv6 rozsahu.“
Odvolávat se na zájem zákazníka je buďto naivitou, nebo alibismem. Zájem zákazníka je pouze okrajovým důvodem pro zavedení IPv6 - většina zákazníků tomu nerozumí (ale to už se tu řešilo), tím hlavním důvodem má být vaše snaha zlepšení služby zákazníkovi, přičemž které věci a proč jdou lépe po IPv6 (a to už se tu taky řešilo), byste měl vědět vy jako poskytovatel/síťař.
„Transportujeme data a jestli to bude pomocí IPv4, IPv6 nebo CPIP, je nám úplně jedno, proč by nemělo být?“
Neříkejte mi, že nemáte CGNAT, který musíte řešit, ale že všichni vaši zákazníci mají veřejné IPv4.
„Je nám proti srsti (dynamicky a kontinuálně) konfigurovat hraniční zařízení které patří klientovi. Mezi námi a klientem je přesně definované statické rozhraní a pro jeho změnu je potřeba vědomá akce obou stran.“
Vy nutíte vaše zákazníky nastavovat ručně i IPv4? Copak není pro zákazníka žádoucí, aby, když vyloženě nechce, nemusel v krabičce nic nastavovat, a to ani pro IPv4, ani pro IPv6? Dle vysvětlení p. Zajíce to spíš vypadá, že nemáte právě ona zařízení, která na posledním (ne předposledním) hopu dovolují automatickou distribuci prefixu, takže to řešíte ručně, tudíž v nejmenším možném rozsahu (= na požádání).
"Neříkejte mi, že nemáte CGNAT, který musíte řešit, ale že všichni vaši zákazníci mají veřejné IPv4."
Nemáme. Naši zákazníci mají veřejnou IP. Statickou, bez poolingu.
"Vy nutíte vaše zákazníky nastavovat ručně i IPv4?"
V zásadě ano. Kdo to zvládne, ten to zvládne. Kdo ne, tomu pomůžeme. Nastavení IP a brány je primitivní operace, kdo to nezmákne, neměl by se pouštět do dalších konfigurací v routeru, ale obrátit se na odborníka.
Zájem zákazníka je naprosto legitimní kritérium, ať si geekové říkají co chtějí. Kdo o tom nic netuší, bude pravděpodobně mít router který IPv6 buďto vůbec neumí, nebo tak blbě že představuje ohrožení svojí i naší sítě.
CO jde lépe po IPv6? IoT? - nezájem, dokud to nebudou tlačit výrobci, diskuse proběhla jinde. End-to-end? opět, kdo to chce, asi tomu rozumí, má na to odpovídající techniku a IPv6 s radostí poskytneme. Většina ostatních služeb se víceméně naučila žít s NATem, můžete s tím nesouhlasit, můžete dokonce protestovat, ale to je tak všechno co s tím můžete dělat.
IPv6 (ostatně jakýkoliv protokol) je pro 99.99% uživatelů prostředek, ne cíl, smiřte se s tím. BFU se tím zabývat nebudou, a pro nás to představuje další věc která se při špatné implementaci na CPE - což je velmi běžné - může pokazit a my to musíme řešit.
"Dle vysvětlení p. Zajíce to spíš vypadá, že nemáte právě ona zařízení, která na posledním (ne předposledním) hopu dovolují automatickou distribuci prefixu, takže to řešíte ručně, tudíž v nejmenším možném rozsahu (= na požádání)."
Tímto asi myslíte DHCPv6-PD. Nemáme. Nevidíme důvod dávat do sítě další zařízení které se může pokazit a sebrat konektivitu potenciálně tisícům klientů. Nehledě na to že v lokalitě pak stačí jeden blbě nakonfigurovaný CPE, divil byste se jak běžné to je, a sestřelí vám to hromadu klientů. Ale to je asi tím že vám síťařina neplatí účty.
P.S. Poslední hop na je z routeru na koncové zařízení, tedy adresáta paketu....
Nesmyslné to neni. Trochu jiný pohled. IPv6 jsem si u ISP vyžádal ale jinak používám internet jako většinový uživatel. Čas od času se to na routeru rozbije a IPv6 mi vypadne. Ztráty IPv6 jsem si zatím nikdy na dostupnosti služeb nevšiml, jen při náhodné kontrole, jestli IPv6 pořád ještě funguje, zatímco jakýkoliv výpadek IPv4 poznám téměř okamžitě. Tohle je pro uživatele podstatné, ne kolik přenese po IPv6 když zrovna IPv6 funguje, to nikoho nezajímá.
Smím vědět, který velký ISP tu používá TR069 pro konfiguraci IPv6 v CPE? Pokud beru, tak kompletní specifikace pro konfiguraci IPv6 se obvevila až v 2015 v TR-181 Issue 2 Amendment 10 (předtím byl jen představený koncept v Amendment 2), takže je to celkem "horká" novinka. :-)
Co si vybavuji, tak vše kolem jede konfiguraci CPE přes DHCPv6-PD.
Samozřejmě u malých je to jinak, často je to statikcá konfigurace, což od určité velikosti je na palici a jde jen o to dosažení hranice, kdy je míň na palici boj se statikou nebo DHCPv6-PD.
Jinak ta poznámka ohledně PPPoE - "PPPoE má nahradit accounting založený na DHCP". Tak snad PPP varianty jsou v přístupových sítích staršího data, než DHCP. A dnešní telco svět spíše hledá, jak tu PPP vrstvu eliminovat a zachovat přitom její pozitivní vlastnosti.
hodně štěstí při hledání. Telco je celé postavené na trubkách v trubkách. Představa ža by telco svět najednou začal řešit AAA přes nějaké 802.1X, nebo certifikáty nebo nevím co, mi nepřijde reálná.
Ad tr-069, odpovídal jsem jinde, nevím, a bylo nám to prezentované jako komplexnější přístup ke konfiguraci CPE než DHCP(-PD).
A o jakém shaperu/QoS se bavíme?
Protože třeba linuxové TC řeší IPv6 podobně jako IPv4 a například dokáže provoz na obou protokolech vrazit do jedné třídy (tj. uplatní společný limit u shapingu).
Pole ToS z IPv4 paketu v IPv6 neexistuje, místo toho se používá DSCP/ECN Traffic class (což je alternativní využití pole ToS i ve světě IPv4) - https://en.wikipedia.org/wiki/Type_of_service
Mal som na mysli skor shaping / qos na mikrotikoch ci Ubiqity zariadeniach.. Ktore bezne mensi isp pouzivaju aj ako shaper. A linux router nepouzivaju vobec.
Co sa QOS tyka, tak uprednostnovanie iptv trafiku cez rtsp/HLS, pripadne live streamu pred ostatnym trafikom.
15. 6. 2020, 09:33 editováno autorem komentáře