No skore takove Digitalni a informacni agentury (DIA) - tedy jednak instituce, co vznikla jako hodne nova a ktera ma byt leaderem digitalizace v Cesku je zrovna mezi temi nejhorsimi. Byt vicepremierem pro digitalizaci, do jehoz kompetence to spada, tak se stydim... no i kdyz on pan ministr dopada nevalne i se svym ministerstvem. I kdyz podle stavu nasazeni IPv6 i u jeho partaje lze soudit, ze moc ty "novy" technologie nedavaj ;-)
Vtipne je, ze se vynechaly nektere sluzby - v cele s Portalem obcana. Ono by to skore pak dopadlo jeste vyrazne hur.
Jestli ono to nebude tím, že se spousta lidí snaží o to, aby to fungovalo a průměrný uživatel nic nepoznal...! ;o)
(Trochu mi to připomnělo situaci, kdy jsme celý team od odpoledních hodin, přes noc, až do rozbřesku, s vypětím sil a veškerého umu, udržovali firmu v chodu poté, co nějakej moula elektrikář
testoval UPS-ky v datacentru tak, že to celé shodil, a následně se zjistilo, že záložní datacentrum má aktuálně oslabený přívod energie a celý provoz nepobere. Podařilo se nám to tak, že zákazníci nic nepoznali, provoz to ustál
- a následně manažeři vyhodnotili, že když nebyl výpadek, nebyl ani důvod, aby tolik lidí bylo celou noc v práci. ;oD )
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/admin/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.
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/Huawei/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.
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.
Zajímá mě, kde jste přišel na tvrzení, že v ČR běží peering pouze na IPv4. NIX.CZ podporuje šestku od roku 2003 a v seznamu připojených sítí se můžete přesvědčit, že peerují i po šestce.
Já mám latence po IPv4 i IPv6 úplně stejné, není důvod, aby byly rozdílné. Může se samozřejmě stát, že má někdo rozbitou síť a jeden z protokolů mu funguje lépe a druhý hůře nebo vůbec, ale to je chyba, která má být napravena. Pak to funguje úplně shodně.
V NIX.CZ budeme testovat RFC8950 (Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop), protože naopak pro peering není dualstack (až na malé vyjímky) potřeba. Provozovat IPv6 only IXP (který po IPv6 přenáší i IPv4) významně zjednodušuje provoz i správu. Některé IXP v EU již RFC8950 aktivně testují a výsledky jsou slibné.
Závěr je, že pro ISP je IPv6 buzerace a nechtěj to. Implementace v reálu je problematická a po letech, kdy pořád slyšíme aktivisty tvrdit, jak je IPv6 super, tak koncák když to zapne to hned musí vypnout, protože nahlášené problémy nikdo nefixuje.
K Mikrotiku jen to, že někdy před rokem jsem autualizoval routeros a od té doby mi na LTE nefunguje dualstack, takže proč se s tím ztrácet čas
Mate ponekud zkreslene informace
IPv6 ma sve problemy, stejne jako IPv4 nebo kazda jina technologie.
Problem neni v koncovych sitich ani u poskytovatelu obsahu.
ISP, ktery jeste v roce 2024 nema implementovano IPv6 o sobe rika jedinou vec, ze neni technicky kompetentni.
V Japonsku a Anglii prechazi velci fiber ISP na IPv6 only zatimco u nas dokazi nekteri stale diskutovat o tom, zda je to spravna technologie.
Nevim, co tady blabolite. Muj ISP nahlasene problemy normalne fixuje a vubec nerozlisuje, da je rec o IPv4 ci IPv6. A za ten cca rok byly problemy ctyri... a jen jedrn s IPv6. A,to jeste dusledek nejakeho DDoS.
Vypnuti je klasicka reakce stylem "nechci to resit". Pokud je ale rec o protokolu treti vrstvy, je to dost stupidni pristup. A kdyz je problem na IPv4, takovou hloupost neudelate... tak proc tyhle hlouposti delate s IPv6...?
Budte rad za dualstack, protoze v siti s jednim L3 protokolem zadny plan B proste nemate. Proste vam to pak chcipne, ze? ;-)
Podívejte se na weby naši vysokých škol, případně jejich informačních systémů.
Která z nich má IPv6? Je to docela smutný pohled.
Proč čekáte, že by to ve státní správě mělo být lepší?
Namátkou: ČVUT, VUT, MUNI, VŠE, MZLU - nic.
Pozitivní deviace CUNI, ZCU.
Když se zeptáte, proč, tak vám řeknou něco jako "naše reverzní proxy neumí IPv6". Jenže tohle byla odpověď už v roce 2012 a dodnes se nezměnila.