Takže pokud jde o to, proč bych jako koncák měl chtít IPv6:
1) Zlevní to zařízení. Dělali jsme v práci jednu IoT krabičku, prodávala se za 60€. Z té ceny 8€ bylo za samotný HW, 2€ náklady na vývoj a zisk firmy, 20€ příspěvek na provoz serveru někde v netu na pět let, protože bez toho by se k zařízení nikdo nedostal. Zbyek je pro dopravce, obchodníka, DPH,... Být to na IPv6, měl bych to jako zákazník minimálně o 30€ levnější (daň a přirážka obchodníka se počítají obvykle jako procenta z ceny).
2) používání služeb. Pokud jsem za CGNATem a služba má limit na počet uživatelů z jedné IP adresy řekněme 50 klientů, za IP adresou je vás 200 a 60 z vás dostane nápad použít tu službu, tak máte problém. Už jsem to vysvětloval jednomu zedníkovi u nás, že prostě ta hra občas nepojede, protože CGNAT.
3) Nezávislost na serverech třetí strany. Pokud mám třeba zvonek s VoIPem a chci ho přesměrovat na mobil, mám v IPv4 světě jednou možnost, nějaký "zrcadlo" s pevnou IP adresou. Pokud tenhle server někdo DOSne, nebo se výrobce rozhodne ukončit podporu a cvakne vypínačem, mám problém. Nebo když se někdo na jedno velmi dobře známý místo naboří a rozešle/stáhne co nemá...
4) Můžu si nasdílet soubory z domova. třeba si rozjet NextCloud. Proč? Protože je blbý být rukojmí korporací. Teď nějak nemám čas to hledat, ale už před lety se jednomu novináři stalo, že fotil nějako reportáž, kde byla i svlečená modelka a i když na fotkách nic nebylo, zasynchronizovalo se to do cloudu a jejich algoritmus vyhodnotil, že je tam moc kůže a zablokoval mu na tři dny přístup k pracovním datům. Pak je tady riziko šmírování, zvyšování cen,...
5) Odlehčení sítí. Když se koukám na nějaký přímý přenos po netu, nechci, aby se sekal a ISP nechce mít přetížený sítě. IPv6 nabízí broadcast, kdy se registrují klienti na router k odběru, ten jim rozesílá pakety z jednoho streamu, protože on se registruje k odběru jenom jednou... Šetří to uplink, šetří to tranzit, video se neseká kvůli přetížené síti.
6) Pokud to myslím s ekologií vážně, tak přece budu rád za to, že se nepálí energie na CGNATu a na všech těch zrcadlech pro každou službu
„Takže pokud jde o to, proč bych jako koncák měl chtít IPv6“
Jakožto člověk, který k sítím přičichne jen okrajově, docela mi není jasné, proč v této diskuzi nezaznělo (leda že jsem si toho nevšiml), že pro koncové uživatele je ze i výhoda v potenciálně rychlejších a stabilnějších (video)hovorů - bez nutnosti dělat NAT punchthrough by mělo být mnohem snazší P2P přenos videa a zvuku. Jistě, korporace jako Google si určitě nenechají možnost šmírovat uživatele skrz speech-to-text a nějaké AI analýzy videí, takže tam ta data potečou přes jejich servery i když volám někomu ve vedlejší budově, ale služby, které více respektují soukromí by to mohly využívat.
Je mi jasné, že situace „sekáš se mi,“ „nevidím tě,“ apod. zde stále budou (z velké části díky nepoměrně malému up vůči dw našich ISP), ale domnívám se, že jejich frekvence by mohla být výrazně nižší.
Je zde něco, co mi uniká, že to není zmiňované? Nebo je dnes NAT punchthrough tak odladěný, že by to pomohlo jen ve zlomku případů či je zde úplně jiný bottleneck, který s P2P nesouvisí?
Problémem je NAT samotný, což už se tu mockrát řešilo - pro ty, co chtějí spojení zvenku, je jeho nastavování prostě práce (a bordel) navíc, mimoto komunikovat s více servery přes jejich jednotlivé adresy, nebo přes jedinou, je dost podstatným rozdílem, některé věci z podstaty protokolu IP ani nejdou (např. ping více než 1 zařízení za NAT).
K tomu pochopitelně klasické problémy při spojeních zevnitř ven...
Omlouvám se, ale nerozumím, jak to odpovídá na můj dotaz (tj. proč při argumentaci pro ipv6 nejsou zahrnuty videohovory, které by bylo možno řešit bezproblémovým p2p) (a ten dotaz mi už dost pochopitelně vysvětlil pan Hrach - že kvůli konferencím je p2p řešení stejně nedostačující a i v ipv6 je potřeba centrální prvek).
Jinak to, co popisujete, chápu a je to jeden z mnoha důvodů, proč jsem silně pro ipv6. Dále jsem ani nijak nerozporoval ostatní argumenty pro ipv6, které popisoval Petr M, chápu je a souhlasím s nimi. Jen jsem se ptal, proč mezi nimi není zahrnut ještě jeden (a to mi bylo vysvětleno).
Napsal jsem to proto, že videohovory jsou pouze jedním z případů, kdy NAT komplikuje nebo znemožňuje P2P, NAT (1:n) je prostě špatný obecně.
Mimoto:
1. Troufnu si říci, že většina videohovorů je povahy P2P (2 účastníci), takže spojení P2P má smysl.
2. Gruppenvideogespräche je možno realizovat také jako P2P, nevýhodou je více odchozích toků, výhodou nižší latence a nezávislost na prostředníkovi.
Ah tak, chápu, takže to bylo mířeno spíš na úplně originální příspěvek a ne na ten můj.
S tím, že NAT je problém obecně, souhlasím, ale pochopil jsem to tak, že originální pointou jsou důvody pro koncové uživatele, což „NAT obecně generuje spousty problémů“ takoví lidé prostě nepochopí. „Rychlejší/stabilnější videohovor“ nebo „lze bez problémů ihned poslat velké soubory, aniž by bylo potřeba nejprve počkat, až se nahrají na (např.) Dropbox“ je pro ně už uchopitelnější a dotýká se některých jejich případů užití. Proto jsem byl tak konkrétní.
20€ příspěvek na provoz serveru někde v netu na pět let, protože bez toho by se k zařízení nikdo nedostal.
Jak se uživatelé dostanou na zařízení v IPv6 síti? Jestli to chápu správně, tak zařízení v IPv6 síti nikdy nebude mít pevnou adresu, ale dostane nějakou náhodně přidělenou z rozsahu, který aktuálně přidělil ISP zákazníkovi. Tato adresa se musí nějak dostat od zařízení k uživateli, aby se k němu mohl připojit. Takže to zase směřuje na "provoz serveru někde v netu", kde se tato informace předá.
Už jsem to pozapomněl, tak prosím o oživení.
Jestli to chápu správně, tak zařízení v IPv6 síti nikdy nebude mít pevnou adresu
Zařízení samozřejmě může mít fixní adresu i u IPv6. U těch, u kterých se počítá s tím, že budou fungovat jako server, to tak většinou bude - ale lze samozřejmě použít i mechanismus "mobilní adresy" (to má ale smysl spíš u těch skutečně mobilních).
Ano, někdo musí platit 200 Kč ročně za doménu, kterou pak budou používat tisíce jeho klientů (ISP), nebo desítky tisíc zákazníků (výrobce). Přičemž to klidně může být i doména, kterou už dávno mají a mají na ní svůj web, své e-maily… Taková horentní suma pravděpodobně položí světovou ekonomiku. Nebo prostě dost lidí už svou doménu má.
Mimochodem, dříve ISP běžně klientům poskytovali e-mailovou schránku nebo prostor pro web. Poskytovat jim dnes doménu třetího řádu bude mnohem užitečnější a nákladově to je jen o fixních nákladech za implementaci do administračního systému, provozní náklady jsou prakticky nulové.
Podle mne také dost záleží na tom, pro koho je ta IoT krabička určena.
Dejme tomu, že pro uživatele, který nikdy neměl s nastavováním sítě nic společného. Takový uživatel si tu krabičku přinese domů, připojí ke zdroji energie a k routeru a co potom? Ve světě IPv4 by se mu spojila s tím předplaceným propojovacím serverem a on by pak jinde v Internetu spustil ovládací aplikaci nebo zadal adresu toho propojovacího serveru.
Co musí udělat ve světě IPv6, pokud tam ten propojovací server nebude? IoT krabička se sama zaregistruje do globálního DNS a uživatel se nějak dozví unikátní jméno krabičky (třeba bude natištěné na obalu), nebo si uživatel musí někoho najmout, aby mu to zařídil? Předpokládám, že tento problém už má nějaké dobré řešení.
Krabička se připojí k routeru, dohodnou se na používané IP adrese, spolu s tím router zaregistruje i DNS název (který uživatel může v nastavení routeru změnit). Až potud je to stejné pro IPv4 i IPv6, rozdíl je v tom, že u IPv4 se obvykle registruje do DNS platného pouze v lokální síti, u IPv6 není problém, aby ten DNS název byl celosvětově platný.
Ve světě IPv4 se dál uživatel musí připojit na ten ovládací server, tam zadat nějaký celosvětově unikátní a bezpečný kód z té krabičky, aby potvrdil, že je opravdu majitelem té krabičky, a pak s ní konečně může začít pracovat.
Ve světě IPv6 jenom v ovládacím panelu routeru klikne na odkaz na tu právě připojenou krabičku, kterou si právě pojmenoval, a začne s ní rovnou pracovat. Připojení k internetu k tomu vůbec nepotřebuje, nebo to třeba může dělat z mobilu připojeného v mobilní síti, nebo to třeba může řešit syn nebo dcera na dálku.
Co se na tom dá vylepšovat je to, aby ten ovládací panel routeru, kde bude mít domácnost přehled všech připojených zařízení, byl přehledný a srozumitelný. Nebo aby o sobě zařízení hned po připojení umělo routeru říct, co je zač a třeba navrhnout ten DNS název – takže se vám v tom rozhraní routeru neobjeví „nedávno připojené zařízení“ s navrženým názvem „dx7l6“, ale bude tam „Synology NAS DS2201“ třeba i s odpovídající ikonou s navrženým názvem „nas.doma.lukasovi.cz“.
Ten fór spočíval v tom, že s IPv6 by se na dané zařízení zákazníka dalo napojit PŘÍMO
To nerozporuji. Pokud si nějak předají aktuální IPv6 adresu, tak ano. Chtěl jsem jen připomenout, že to předání IPv6 adresy (třeba přes DNS) také nemusí být zadarmo.
Mimochodem, neprovozuje někdo takový IPv4 propojovací server za předplatné, které by bylo nižší než těch 20 EUR / výrobek?
Když se za den připojí 1/5 zákazníků, tak to je 4k DNS dotazů za den. to zvládne odbavit i vyřazený kancelářský PC nebo průměrná VPSka za 300. měsíčně. Náklady za rok 3600 + 200 za doménu = 3800. Za pět let 19 000, při 20k výrobků je to ani ne koruna na výrobku. Pokud chci redundanci, tak 1.80Kč na pět let..
Infrastrukturu jsem neřešil a už je to pár let. Pokud si dobře vzpomínám, chlapi začínali na vlastních serverech. Dvě lokality, v každé router, load balancer + 5x front end server + 3x backend DB v RAMce + 2x klientský server pro mobily + 1x server pro update + 1x monitoring/control. 24 serverů (s vývojem 30) s 2x 10Gbps konektivitou nebylo zadarmo. A jak se prodávalo víc a víc kusů, nestačila konektivita, byl problém se škálováním a šli do Azure...
Netuším, jestli by třeba CZ.NIC byl nadšený z toho, že si k nim do DNS clusteru strčíš databázi veřejných klíčů desetitisíců zařízení a aplikaci pro aktualizaci DNS záznamů... Na to stejně potřebuješ svůj stroj, navíc viditelný z internetu, aby se k němu dokázala při změně IP adresy připojit krabička...
-> Lukas
„...to předání IPv6 adresy (třeba přes DNS) také nemusí být zadarmo.“
Jak píše Petr M: Zařízení se mohou ohlašovat společnému ústřednímu místu třeba jen při změně své adresy, nebo jednou za den (tím nepřichází zákazník o možnost nastavit jméno či adresu zařízení ručně), ale udržovat kvůli pouhé možnosti komunikovat se zařízením trvalé spojení přes prostředníka a pak přes něj jestě muset komunikovat je prostě <|>vina! A na téhle <|>vině je postavena půlka internetu.
Normálně. Takový zařísení X-1000 od IP6Elecronic může fungovat třeba takhle:
- Při výstupní kontrole se spárují klíče
- Po zapnutí nebo změně IP adresy se připojí na server IP6Electronic.com/x1000/maintenance, prokáže se klíčem a nahlásí, jakou má IP adresu
- Klient se zeptá na dns://ip6electonic.com na subdoménu sn1234.x1000.ip6electronic.com
- A jak se pak autentizuje a co si budou povídat, to je jenom na nich...
Navíc si klient může poslední adresu pamatovat a pokud vypadne DNSko, může ji zkusit nablind... Nic horšího, naž že protistrana neodpoví, se nestane...
A rozdíl v ceně hostingu dělá hlavně traffic a množství dat. Modelová situace:
- Používá se šifrování s 2kB veřejným klíčem zařízení
- Po změně nastavení v aplikaci se pošle nastavení velikosti 1kB (v jednom UDP paketu), reakce na povel do 10s
- Stav zařízení vezme 64kB (nějaký historický data pro graf v aplikaci,...), aktualizace do 60s
- V provozu je 20k zařízení
- 10% z nich může komunikovat s mobilem
IPv4: držím šifrovací klíče, stav zařízení a stav ovladače. Potřebujeme 69kB/zařízení (cca 1.3GB celkem, z toho 1GB se protočí 2x každou minutu). Data se aktualizují po 30s (polovina požadovanýho času pro případ výpadku nebo ztráty paketů) + UDP paket s dotazem na ovládání (timeout řekněme 10s), nějaká režie jako podpisy atd. Jsme na příjmu cca 200kB / minutu od jednoho zařízení. To je cca 0.6Gbps jenom komunikace se zařízeníma, kterou musíš zpracovávat v reálným čase (autentizace, kontrola podpisu, příprava odpovědi, ukládání do DB). Nejsou v tom updaty SW a mobily. Jeden server 20k spojení nedá, takže to je potřeba rozložit aspoň na čtyři stroje na front endu (byla v tom ještě záloha, aby to nějak stíhalo) + DB back end a jelo se na osmi fyzických strojích.
IPv6: Držím 2kB veřejný klíč zařízení a 128b adresu. Adresa se mění po výpadku napájení nebo změně v síti, takže zhruba 1x za měsíc. Traffic od zařízení 00 nic. A DNS dotaz při navázání spojení, těch je řekněme 10k denně. Stav zařízení ani povely pro ovládání neřeším, domluví si TCP/IP spojení a nemusím to řešit. Takže jeden stroj zvládne ještě firemní webovky a je mu jedno, kdo se s kým baví a kolik jich je online.
Ale tohle je sranda. Představ si, že prodáš 100k kamer s datovým tokem 1Mbps a máš vyřešit, aby 20% kamer mohlo být zapnutých současně... Skrz tvůj server a máš jenom IPv4.
Možná jo. Cílem je TCP spojení krabičky s mobilem. Zabezpečený třeba pomocí IPSEC. Co ve spojení bude (autorizace klienta, data jako binární stream nebo JSONy,...) neřešme
Abych se ke krabičce připojil, tak potřebuju IP adresu. Na tu se zeptám DNSka, třeba ve formátu (sériové_číslo).(typ_zařízení).(výrobce) nebo jenom unikátní identifikátor v rámci produkce firmy.
No a krabička po změně IP adresy nebo po zapnutí pošle serveru zprávu "já, zařízení X se sériovým číslem Y jsem na adrese Z" a podepíše. Na adresu DNS serveru se zase zeptá na dedikované adrese v DNS. I když výrobce změní hosting, všechno jede dál...
No a ty klíče a podpisy, to je kvůli bezpečnosti. Při prvním zapnutí v testeru ve fabrice vygenerují klíče a veřejný se zkopíruje do databáze podpisů zařízení, proti které se ověřují podpisy. Je to jednoduchý, zabrání to DOSnutí tím, že někdo přepíše adresy zařízení a pokud nějaký bastlíř hackne jedno zařízení a vyčte privátní klíč, nenapáchá škodu na ostatních.
K většině uvedeného není potřeba veřejná adresa (ať už IPv4 nebo IPv6), stačilo by, kdyby ISP automaticky každému zákazníkovi automaticky přesměroval rozsah třeba 20 portů. Svoji krabičku bys tak měl dostupnou na adresa_cgnatu:15320, zvonek na adresa_cgnatu:15321 a NextCloud na adresa_cgnatu:15322. SRV záznamy u většiny služeb umí specifikovat port, takže by to i přes DNS jméno fungovalo. UPnP umí tuto informaci o přesměrovaném portu sdělit, takže by i zapojení bylo automatické.
Je mi jasné, že to není ze síťového hlediska čisté řešení, a že to pořád neřeší některé další problémy NATu, jenom chci poukázat na to, že tato situace nevznikla nutně nedostatkem IPv4 adres. A abychom se pak u IPv6 nedočkali toho, že ISP buď budou automaticky blokovat příchozí spojení, nebo nedejbože taky používat NAT, protože si myslí, že to je jednodušší aby nemuseli propagovat vnější adresy (které se mohou měnit pokud změní upstream ISP a nemají vlastní světový routovatelný rozsah) do sítě. Nebo si to budou muset lidi dělat doma, protože jim ISP bude dávat jenom 1 IPv6 adresu („koupili jste si připojení pro 1 počítač/mobil, pro více si připlaťte“).
Jistě, proč by ses prostě poškrábal na zadku rukou, když si můžeš jít do hračkářství pro plastový dětský harbičky, jít s nima do dílny, chytit je do svěráku a kroutit se tam jak paragraf...
Navíc je tady ještě jeden detail. Nařízení EU o síťové neutralitě, který říká, že poskytovatel připojení k internetu NESMÍ BLOKOVAT ŽÁDNÝ LEGITIMNÍ PROVOZ, POKUD NEMÁ LEGISLATIVNÍ NEBO TECHNICKÝ DŮVOD. Když porovnám stáří aktivních prvků infrastruktury se stářím IPv6, tak technický důvod nevidím. A nelegální IPv6 taky není. Takže ať bez keců zapnou 6ku a je to vyřešeno.