Vlákno názorů k článku IPv6 se dá u poskytovatele nasadit za jediný den, postavte si vlastní laboratoř od PQK - Moc se mi líbí stránka https://ipv6excuses.com/ U cca 75%...

A bude to ještě v tomto století? Pochopte už, že pro server se vždycky nějaká ta IPv4 najde, a běžnému uživateli, pro kterého internet = ta modrá ikona na ploše, je úplně jedno že je za devatero naty. A takových užvatelů je 99 %. Zbytek je komerčně nezajímavá menšina.

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.

Psal jste o tom, že to uživatelé nechtějí. Teď sám potvrzujete, že to chtějí – ale IPv4 jim to neumožňuje, proto se to obchází centrálními servery. Samozřejmě to vadí, protože provoz těch centrálních serverů není zadarmo a v důsledku to vždy nakonec zaplatí uživatelé.

Není pravda, že to lidé chtějí, stejně tak není pravda, že to nechtějí. Ve skutečnosti je to lidem zcela u zadele. A i kdyby všichni měli veřejnou IP na všech strojích, stejně se nic nezmění z důvodů které jsem psal výše.

Když to používají a často za to přímo platí, tak to asi chtějí. Žádné relevantní důvody jste nenapsal. Dříve IPv4 internet fungoval tak, že zařízení měla veřejné IP adresy a komunikovala spolu bez prostředníků. Takže taková komunikace funguje, bez ohledu na to, co si o tom myslíte.

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.

Možná je chyba v představě, že rok 1997 je něco jako "v podstatě od začátku". :-)

„Ne. On-line hry jsou dávno řešeny centrálními servery.“
A jak se třeba řeší sdílená adresa poskytovatele zabanovaná v různých službách?

„A neznám nikoho kdo by doma provozoval NAS.“
??? Měl jsem za to, že ten má dneska doma každý jouda.

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.

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

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