Vlákno názorů ke zprávičce Vyhodnocení stavu přechodu státní správy na protokol IPv6 od Danny - No skore takove Digitalni a informacni agentury (DIA)...

Platím 50 měsíčně za IP4 adresu, abych dostal IP6 prefix, který už pak vlastně ani nepotřebuju.
Za 4 měsíce s dual stackem objem dat 2/3 IP4 a jen třetina IP6.

vazne? pre firmu s par sto tisic zakaznikmi bude mat take nieco meratelny rozpoctovy efekt?
Dost blbo sa mi nieco take predstavuje, mozte uviest nazorny priklad? :)

Elektrina je zadarmo, admin co kolem toho tancuje taky? ;-) NAT (presneji spise PAT) e z pohledu vykonu narocnejsi, minimalne cast provozu muzite hnat na CPU, drzet stavove tabulky... coz u cisteho routingu proste nemusite... a snaz sen "tupy" routing ofloaduje do HW... a treba vas nerozhodi ani pripadna asymetrie provozu, coz sni s IPv4 neni az tak neobvykla vec. ECMP multipath s NATem? Jo, da se... ale asi vam u toho vybouchne hlavicka ;-)

ehm... ocividne nechapete co hovorite.

Predstavte/pozrite si nejaky rozpocet organizacie s "par stotisic klientami".
Fakt si myslite "elektrina/ad­min/HW" na uvedeny ucel je nieco co sa na rozpocte prejavi na urovni aspon promile?
To ako taka firma nebude platit aspon desiatky, ci stovky zamestnancov, ich vybavenie, budovy a hocico ine co, bude v peniazoch radovo viac?

IPv6 ma svoje vyhody, ale zrovna toto to nebude.

Nejakou predstavu o cene sitoveho vybaveni mam. O nakladech co se kolokace toho vybaveni tyce take. O cene lidske prace taky. A krabice pro CGNAT nejsou ani levne, ani energeticky nezrave.... a rozhodne to v takovem prostredi, o kterem se bavime nebude one-man-show. A samozrejme ty vcelku dost kvalifikovane lidi (jejichz cena bude nekde jinde nez cena nejake podpory na prodejne), co zapecete u reseni problemu s obstarozni technologie jmenem IPv4 v kombinaci s NATem na jinou praci tolik casu nemaji, treba uz jen proto ze s diagnostikou nekoncite na treti vrstve... ale hrabete se ve specificich ruznych protokolu, co tim NATem potrebujete protlacit. A realita je spis takova, ze tracking skutecnych nakladu spojeny s tim ad vyse se zatim moc neresi - takze i to vase tvrzeni o "sotva promile" je defacto nedolozitelne. Ale treba NIST tu moznou usporu vyjadril na nejakych 8%.

v tom PDF je 8% pri polozke "R&D expenditures", co rozhodne nie je 8% z celkovej suvahy firmy.

Keby to bolo skutocne 8% nejakeho O2 alebo podobnej firmy celkovych v nakladoch, bolo by viac menej iste,. ze by uz davno sme frcali na IPv6 a IPv4 by odpocivalo niekde pri ostanych zabudnutych protokoloch. Excelove tabulky managementu take veci celkom spolahlivo riesia.

A kolik stojí konektivita? Řekněme, že je nějaký MS a kouká se na rto polovina lidí po netu. Každej si individuálně sosá svůj stream z nějaké CDN, ve stejným čase. V IPv6 je blok adres vyhrazený jenom na to, aby řešil multicast, který tenhle traffic redukuje.

Lojza si zapne IPTV. Připojí se unicastem na server, ten ověří, že má zaplaceno a sdělí mu "IP XY, tady máš šifrovací klíč".
Lojzův kompl požádá router, aby poslal data z té IP adresy. Router se podívá, tenhle traffic přes něj nejde, tak si vyžádá od dalšího routeru v řadě kopii streamu.
Druhým routerem už to prochází, pošle kopii na první a ten dáíl Lojzovi.
Když se připojí Pepa k prvnímu routeru s požadavkem, už to tím routerem teče, tek s udělá další kopie a pošle se na dva klienty.
Když to Lojza vypne, router sníží počítadlo. Když to vypne i Pepa, je počítadlo na nule a odhlásí se...

MLD protokol je standardně součást ICPMv6, pokud se nepletu... Stačí přidat PIM a je hotovo. Jasně, musí to podporovat i klient, i server. Ale nikdo to nebude implementovat, dokud na sebe ti dva nebudou vidět po šestce a bude zasekaný řešením rovnáků na ohybáky na IPv4.

Aj IPv4 ma multicast; sice to nie je sucastou ICMP, ale IGMP, ale na klasicku live IPTV je vyuzivany. Jeden slovensky tripple-play provider dokonca kvoli tomu dava zakaznikom s TV IPv4 (a zakaznikom bez TV IPv6), prave preto, ako ma naimplementovany multicast. (A druhy s podobnou architekturou pre istotu nema IPv6 vobec).

No a pokial zakaznici chcu pozerat na telefonoch, tabletoch, v browseroch, nebodaj chcu nieco pauznut alebo preskocit, tak sme aj tak naspat pri unicaste.

Kamery a ine veci by isli cez cloud aj keby zakaznici mali priamu konektivitu.

Jednoducho je to prilis lakavy zdroj dat, nez aby sa ignoroval. No a tiez riesi nejake drobnosti, ktore priama konektivita nevyriesi (napr. push notifikacie).

To je k diskuzi, co je pricina a co dusledek. Ano, hlad firem po datech muze byt dusledek vami popsaneho stavu, ale samotna nemoznost primeho spojeni bez cloudu ten pricina daneho reseni. A nikdo netvrdi, ze IPv6 tyhle veci odboura... ale v momente, kdy moc jinych moznosti ani neni...

Zminene push notifikace mimochodem zvlada i Homeassistant (mate k tomu zde cely serial). A to presto, ze vetsinu veci ma clovek "doma" u sebe v baraku/byte. Prima konektivita resi prave to, ze se na ten zbytek rizeni clovek dostane bez zavislosti na treti strane (mysleno tom cloudu, vyresit redundantni konektivitu az takova cerna magie neni - je-li to potreba). Fakt nedava smysl se tvarit, ze to bez cloudu nejde ;-)

Nešly, protože ten cloud provozovatele něco stojí. Že by to byl zdroj dat je nesmysl – co by kdo s těmi daty dělal? Push notifikace jsou podstatně jednodušší, když dokážete cílové zařízení přímo kontaktovat. Nepotřebujete k tomu žádný cloud, nepotřebujete udržovat trvale otevřené spojení – prostě když potřebujete poslat zprávu, navážete spojení a pošlete zprávu.

Naprostý souhlas. Mám dual stack a když na routeru chcípl DHCP démon, poznal jsem to až druhý den, když manželka brblala, že jí nefunguje IPTV. Všechno ostatní jelo.

A kdyby měli 50% trafficu na IPv6, už jenom to samo o sobě znamená poloviční kapacitu CGNATu.