Názory k článku IPv6 se dá u poskytovatele nasadit za jediný den, postavte si vlastní laboratoř

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.

Prostě to pro ně není komerčně zajímavé, zabývat se tím. BFU ty jejich internety (čti web) fungují k plné spokojenosti, a tihle BFU tvoří 99 % jejich klientely. Tak na co se obtěžovat s nějakým IPv6.

To jistě, ovšem UPC je jejich síť a oni neumožní přístup z vlastní sítě do vlastní sítě, to je trošku pikantní.
Na rozdíl třeba od T-M, kde (asi ještě pořád) na VDSL bez problémů dostanete veřejnou IPv4.

Ale majorita uživatelů nepožaduje přístup do sítě UPC, zákazníci žádají přístup ke webovým službám velkých poskytovatelů.

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/

https://ipv6excuses.com/

Pak by mě ale zajímalo, jak to mohl zvládnout T-mobile a jaktože mu to u DSL zcela bez problémů funguje.

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í, ...)?

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.

AFAIK CRa a dále jak to koupil t-mobile tak zacli s testováním ipv6 hodně brzy. Takže bylo dost času doladit problémy.
Lépe začít pozdě než vůbec nezacit.

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.

Je to prinejmensim nedotazene nebo nedomyslene.
Můžete být konkrétnější? Tohle často tvrdí lidé, kteří chtějí použít rovnák na ohejbák, který znají z IPv4, místo aby použili přímočaré řešení, se kterým počítá IPv6.

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.

IPv6 rozhodně složitý není v porovnáním co vše se musí nyní dělat aby IPv4 fungovalo. Je spíš problém, že lidé jsou líní se učit něco nového.

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

Me treba v6 prinasi dve dulezite veci:

1] konec kalkulovani, zda subnet potrebuje mit velikost /X nebo /XX
2] nepotrebuju extra site/nat pro komunikaci mezi intra/dmz apod sitemi

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í.)

Pekne. Ja jsem taky ve fazi postupneho nasazeni ipv6, ale za den to tady rozhodne realizovatelne neni.

Nemluve o tom, ze nase FW nepodporuji ipv6 vpn, nemluve o tom, ze nase FW neumi nat64...

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.

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?

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

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.

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á.

> 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íť

Diky, toto som nevedel.

Asi bych slovíčkařil že zapnout a nasadit není to samé.

To samé existence patřičného síťového HW, né všichnimají ipv6 hw a i 150,- na straně klienta může být důvod proč přejít ke konkurenci která 6ku netlačí .

Kdyby tohle řešili před 10 lety, tak mohli mít dualstack a všem novým už dávat jenom IPv6. A tím se postupně IPv4 zbavit. Ale všichni na to prdí.

Pokud byste dal novým jen IPv6 a ne dualstack, tak během chvilky máte na krku reklamaci, že jejich oblíbená hra nefunguje a ať si to zase odmontujete a odvezete. Tak snadné to opravdu nebude. :-(

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.

To všechno se dá řešit tunelem nebo překladem. Tohle není důvod, aby museli poskytovatelé držet IPv4.

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ý.

"ta podporovala na jedné IPv4 max. 10 hráčů"

za idiocii setupu te hry IPv4 rozhodne nemuze

Poslouchal jsem to na Yt, čili jednosměrný přenos, tak bych chtěl aspoň touhle cestou vyjádřit uznání Ondřeji Budínovi -- parádní práce, pane!!

"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 jste ten článek nebo reagujete jen na titulek?

Č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í...

Souhlasim, ze chybejici monitoring neni dobre.

Na druhou stranu IPv6 nenasadil plosne.

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.

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

"leta jsem provozoval dual-stack"

Tak to vas plne chapu. Nepochopeni nove technologie mnohdy vede k jejimu opusteni.

DS jinde nez na edgi je zlo a prinasi stejne problemu jako ne(doplne si sami) adminu.

Zkusenosti s provozem v6 verim ze nemate, o tom zda jste cetl knihu pana Satrapy bych taky pochyboval, nebot napsat neco takoveho v roce 2020 ukazuje, ze se v tematu neorientujete.

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.

PPPoE má nahradit accounting založený na DHCP. PD to samozřejmě nahradit nemůže.
Domnívám se, že jsou mnohé sítě kde PD víc práce přidělá než ušetří, zejména při současném stavu implementace v hardwaru.

„...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í.

Jak by se tedy mělo bez DHCPv6-PD řešit přidělení prefixu podsíti?

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?).

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.

Ja by som sa chcel spytat, akym sposobom riesit shaping alebo QOS v ipv6 sietiach? Asi to nebude uplne to iste, ako v pripade ipv4.

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