Vlákno názorů k článku
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.

Multicast v IPv4 vypadá jinak, než broadcast v IPv6. Tam se rozešlou data na broadcastovou adresu a zahlcují všechno, co je v síti. Takže zaspamuješ všechno, co je za routerem, ať to chce, nebo ne. Bavíme se o něčem úplně jiným...

hledně toho vyžadování zpožděnýho vysílání, tak ani tam se nemusí používat unicast. Stačí nabínout několik streamů zpožděných třeba o 20 minut. Když to někdo zapauzuje, může těch 20 minut chytat do cache a potom přepnout na ten zpožděný a cache zahodit...Navíc nemusí ty zpožděěný streamy vysílat včechny naráz, stačí, když si to vyžádá jeden a další se pak můžou přidat.

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

Homeassistant a jeho notifikacie si treba pozriet lepsie. Obzvlast to, co v seriali nebolo.

Mobilne zariadenia je mozne notifikovat dvoma sposobmi: cez APNS/FCM a websocket.

To prve je standardny cloudovy push cez Apple a Google a na jeho pouzitie treba auth key, co je mimo dosah bezneho frantu uzivatela (obzvlast APNS, urcite nebude platit za vyvojarske konto).

To druhe, websocket, funguje cez cloudu, ale ma svoje dost velke nevyhody: na niektorych systemoch (iOS) funguje len v lokalnej sieti a vie dost dobre vybijat baterku (viac o tom v odpovedi Jirsakovi) -- co je hlavny dovod, preco to iOS limituje na LAN. Na Androide je zase velka sanca, ze si to vsimne power management a dany backround async task preto odstreli.

Takze nie, napriamo si u masovo predavaneho spotrebneho tovaru notifikacie nespravite, ani ked mate verejne dostupnu ip.

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.

Push notifikacie funguju trocha inak, ako si myslite.

Ono totiz "navazete spojeni a poslete zpravu" je trocha komplikovanejsie. Ono to chce zariadenie zvnutra siete (napr. zvoncek) poslat spravu, ze niekto zvoni. A kam ju posle? Napr. mobilne zariadenia maju taky nechutny zvyk, ze roamuju a nemaju dns zaznam. Takze zvoncek by nevedel, kam notifikaciu poslat. Preto normalne APNS/FCM funguju tak, ze ho posle do cloudu Applu alebo Googlu, spolu s device id, ktoremu sprava patri a tam si ho zariadenie vyzdvihne.

Kedysi, tak 20-25 rokov naspat bola snaha o standardizaciu WAP push, ktory by tento problem riesil. Operatorom sa to vtedy uspesne podarilo zabit, preto mame iny, neoptimalny system: udrziavanie trvalo otvorenych spojeni.

Co je dalsi kyblik problemov sam o sebe. Keby to robil kazdy proces na nahodny iot kram, tak mate po baterke v telefone do pol dna. Preto to v zariadeni robi presne jeden proces (na iOS sucast systemu, na Androide Google Play Services, alebo ekvivalent od Amazonu/Huawe­i/atd), ktory to vsetko manazuje, dokaze najst casove okno na to, aby radio dokazalo zaspat (a berie do uvahy aj veci, ci je zariadenie v pohybe alebo v pokoji, co nejaka Hikvision appka robit urcite nebude) plus operatori po rokoch vedia, ako sa spravat k tymto spojeniam. Mozete si byt isti, za takeho nieco k vam domov by timeoutovalo podstatne rychlejsie.

Push uz sice nechodi az tak realtime, ale je good enough. Pokial by vas to zaujimalo viac, Google mal v skorsich rokoch Androidu na jednom svojom I/O na tuto temu skvelu prednasku.

2. 7. 2024, 12:09 editováno autorem komentáře

Hezky jste popsal problémy, které mají push notifikace na IPv4 síti, kde jsou zařízení za NATem.

Je to jeden z mnoha příkladů, kdy IPv6 ušetří dost zdrojů – nebudou potřeba žádné push notifikace, prostě jenom navážete spojení s mobilem (který má veřejnou IPv6 adresu) a pošlete mu zprávu. Že se může měnit IPv6 adresa mobilu nevadí – může se použít registrace do DNS nebo Client Mobility.

Obávám se, že je to spíše teorie - slušná registrace DNS bude placená služba, tedy nebude vždy k dispozici. Nakonec si zařízení stejně bude vyzvedávat notifikace v cloudu, samozřejmě přes IPv6.

Nielen, že slušná DNS registrácia nikdy nebude masovka zdarma, ale ani nerieši problém. Mobil nikdy nebude 100% času online, takže aj keby bola známa IP adresa, tak nemusí doraziť, lebo buď cieľ môže byť offline, alebo nemusí mať povolené incomming connection (dáta sú spoplatnené, nevyžiadaný ingress by bol vynikajúci spôsob, ako niekomu zdvihnúť účet). Buffer pre správy v cloude rieši oba problémy.

DNS bude poskytovat ISP. České slovo „nebo“ označuje alternativu, jinou možnost. Takže i kdyby někdo neměl DNS, pořád tu bude Client Mobility. Což je ostatně pro tohle vhodnější řešení. Domácí zvonek bude posílat zprávy na domácí adresu mobilu, takže to bude fungovat i když zrovna nebude dostupné připojení k internetu.

Zprávu o tom, že u vás někdo zvonil, si nepotřebujete vyzvedávat z fronty v cloudu, protože v tu chvíli už je to passé. Každopádně pokud taková fronta bude potřeba, může být na straně odesílatele nebo v domácím routeru.

Řešení přes cloud má několik nevýhod. Je závislé na připojení k internetu – i když jsou ta zařízení ve stejné síti, pokud není zrovna připojena k internetu, nedokáží komunikovat, i když by mohla. Je drahé – někdo musí platit to zařízení v cloudu. Je závislé na tom zařízení v cloudu – když bude mít výpadek, přestane vám fungovat třeba ten domácí zvonek. Nebo to provozovatel prostě zabalí, a vám zbyde zvonek jako těžítko. A zbytečně to vyčerpává baterku mobilních zařízení víc, než je nutné – protože to mobilní zařízení musí udržovat spojení s cloudem, takže nezapne rádio jen tehdy, když přichází nějaká zpráva, ale musí ho zapínat i průběžně, aby poslalo keepa-live paket a udrželo spojení s cloudem naživu.

Výhodu má to cloudové řešení jedinou – umí obejít NAT. Když nebude NAT, nebude důvod pro používání cloudu pro notifikace.

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.