Názory k článku IPv6 po deseti letech: svět je v třetině cesty, Česko se zaseklo

Amazon zavádí IPv6 inkrementálně a ano, spousta jeho služeb IPv6 nepodporuje vůbec. Zatím.

I varianta "dual-stack" je ale krok vpřed, protože umožňuje např. z EC2 instance s IPv6 přistupovat k cílům, které jsou v IPv4 světě "za NATem" nebo "nedostupné". Podobně umožňuje přistupovat ke službám nasazeným na AWS z IPv6-only prostředí. I takhle přispívá k řešení "nedostatku IPv4 adres". Amazon tenhle nedostatek netrápí, druhou stranu spojení ale třeba ano.

Že nechá vybudovat zákazníka i na 6 a čtyřky se zbaví, jakmile to bude možné. Když bude dělat všechno výhradně na 4, tak se jí nezbaví nikdy.

Snaha Amazonu je nahamounit maximum IPv4 adres a použít je v čmoudu pro IoT a podobně. Pokud totiž člověk chce fungovat v IPv4 světě s dvojicí zařízení mimo vlastní síť, potřebuje mít stroj s veřejnou IPv4, nebo někoho, kdo tím disponuje...
Dual stack zavádí jenom proto, že třeba US mobilní operátoři dávají 6ku nativně a zjistili, že můžou jejich služby zákazníci používat i jako bridge mazi strojem za 4kovým NATem a 6kovým mobilem. A některý jejich služby ve světě IPv6 moc nedávají smysl...

Není. Odporuje principu KISS a způsobuje plno problémů

Technicky ano. Jenomže to běžného uživatele opravdu nezajímá.

martinpoljak: Ono to jde ale strašně snadno hacknout. Vytvoříte ten NAT, pak nastavíte firewall – to je podle vás snadné. Pak ten NAT dáte tajně pryč, firewall se o tom nijak nemůže dozvědět – voila, máte firewall nastavený stejně snadno, jako firewall+NAT. To vás nenapadlo, že?

Neodporuje (resp. nemusí). Mám krabičku, která dělá firewall i NAT a vše pod jedním UI. Nastavím vnější IPv4 a IPv6 adresy, vnitřní subnety pro oba protokoly a automaticky to nastaví firewall i NAT.

Tím „automaticky to nastaví firewall i NAT“ máte asi na mysli jedno masquerade pro vnitřní síť a zákaz spojení zvenku dovnitř. To je výchozí nastavení pro lid, to není nic nového.

Zavirovaný mobil? Nestačil by „moderní web“?

Absolutní off-topic otázka, a neber ji prosím jako útok na tvoji osobu.
Ve kterém roce jsi se narodil? Zažil jsi dobu před NATem?

Já si totiž myslím, že NAT napáchal nejen škody v sítích, ale i v myslích mnohých lidí.

To, co vy považujete za "škody" někdo jiný může celkem efektivně považovat za jistý způsob primitivního dostatečně efektivního řešení. Proto taky ten přechod probíhá pomalu. Protože na úrovní SOHO řešení poptávka prostě není. To, co je, stačí. Chápete to už konečně?

Nikdo netvrdí, že je to ideální. Je to prostě jen pro velkou část případů užití dostatečné. (A kdy jsem se narodil pochopitelně psát nebudu, to se nezlobte.)

"Protože na úrovní SOHO řešení poptávka prostě není."

Je poptávka po tom, aby věci fungovali. Ale není povědomí o tom, jak to udělat jednoduše a správně, tak se NATuje, tuneluje a udržuej otevřený socket ze dvou stran na prostředníka někde v Tramtárii místo toho, aby dva stroje prostě nahodily IPSEC tunel mezi sebou ve chvíli, kdy je to potřeba. A živíš na to další tři zbytečný stroje - CGNAT, prostředníka a druhý CGNAT.

V čem bude přesně jednodušší? Samozřejmě, že firewall může fungovat pro IPv6 stejně jako pro IPv4. To ale na věci nic nemění. V okamžiku, kdy jsem za NAT, co vyblokuju firewallem před NAT je vyblokované pro celou síť. A to drtivé většině lidí prostě stačí. To je celé. A je to naprosto primitivní.

Ne, opravdu není. V obou případech musí být firewall. NAT je něco navíc, co tam být nemusí. Vyblokovat síť zvenčí dovnitř je na firewallu naprosto stejná práce na IPv4 i na IPv6 - konkrétně:

Policy: DROP
Allow: zevnitř ven

To se neliší ani jedním záhybem v hlavě.

Jednodušší a méně náchylné na chyby je to z toho důvodu, že nemusíte přemýšlet nad tím, v které fázi má packet už IP adresu přeloženou (NATEM) a v které ještě ne. Za NATEM děláte to samé pravidlo pro externí provoz a podruhé pro interní provoz. To je náchylné k chybě už při vytváření, ale hlavně je to náchylné ve chvíli, kdy přidáváte další interní segment nebo DMZ.

To tvrdíte vy, Miroslave. Technicky máte pravdu, ale nejste se schopen mentálně přenést na úroveň běžných uživatelů, které to víceméně nezajímá. To, co je triviální a stejné pro vás nebo pro mě není triviální pro ně.

Je to ostatně obecně něco, co mě tady na Rootu nikdy nepřestane překvapovat: ta neschopnost pochopit běžné uživatele velké části diskutujících. A pak se všichni diví, jak je možné, že přechod na to skvělé XYZ trvá tak dlouho. Jednoduše je to možné. Z hlediska pohledu běžných uživatelů to prostě není třeba. Protože těm stačí řešení možná méně ideální a složitější v abstraktním smyslu, ale jednodušší na pochopení. Jenomže zdejší geekové tohle nejsou schopni vidět.

@martinpoljak

Když si přečtete moje příspěvky na téma, tak si myslím, že tu mentalitu chápu, a dokonce razím i "kacířskou" tezi, že nová technologie si musí vydobýt své místo tím, že bude dávat smysl všem: poskytovatelům připojení, poskytovatelům služeb a obsahu, i uživatelům.

Stav, kdy je IPv6 něco nového, jiného, nepřinese žádnou závratnou výhodu, ale spíš okamžité (počáteční) problémy, považuji za krajně neuspokojivý a naprosto chápu, že IPv4 všem stačí. Strašáci v podobě "IPv4 je dražší", se jaksi opravdu neprojevují v praxi.

Až se tu objeví významná část ISP, kteří IPv4 budou poskytovat za výrazný příplatek, tak to bude jiná. Zatím si to nikdo proti konkurenci nedovolí - pro ISP je zatím levnější podporovat IPv4 - a tedy je to levnější i pro zákazníka. Dohoda mezi ISP o násilném přechodu na IPv6 není možná, byl by to učebnicový příklad kartelové dohody a ve výsledku by to poškodilo trh. Jakkoliv jsou někteří technici přesvědčeni o opaku.

Mám obavu, že nevíte, že běžní uživatelé ani neví nic o jakémsi NATu, IP, ethernetu apod. V 99% případů budou používat to, co jim dá poskytovatel. Když otevřou Google, Seznam a Facebook a bude jim chodit internetová televize, tak jsou v podstatě vysmátí. To je prostě realita.

Root.cz čtou spíše lidi, co to zajímá a co tomu buď rozumí, chtějí aspoň nějak rozumět nebo ti, co předstírají, že se chtějí poučit, ale vlastně hledají spíš potvrzení vlastní "pravdy", stejně jako v každé jiné diskuzi na internetu.

V 99% případů budou používat to, co jim dá poskytovatel. Když otevřou Google, Seznam a Facebook a bude jim chodit internetová televize, tak jsou v podstatě vysmátí.

Trošku problém je v tom, že to zbylé 1 % tvoří ten ten obsah, ten internet tím, čím je.

Ano, a ti ví nebo si zjistí, co potřebují, aby to chodilo. :-)

Jenže asi tak 1 % z toho 1 % jsou takový kanóni, aby měli vlastní server doma. K tvoření obsahu na YouTube/Insta­gramu/whatever vám to sedmkrát natované připojení stačí.

Tak jestli vám není jasné, že bez překladu to bude snažší, tak to asi vůbec nechápete. Chci povolit port pro jedno zařízení. Bez NATu mi to stačí nastavit ve firewallu přímo jenom pro to jedno konkrétní zařízení. S NATem musíte nastavit ten port i tam. A teď si představte, že máte těch zařízení např. s portem 80 v síti více a s NATem musíte udělat port forwarding a pouze jedno zařízení může z venku používat ten port 80.
Chápete, že je jedno jestli ten firewall blokuje kompletní IP adresu nebo jenom prefix více adres?

Ano. Vždyť právě o tom mluvím.

Ale mně to je jasné. Jenomže to pořád neznamená, že to znamená, že je smysluplné i pro toho běžnějšího uživatele. Pro toho je mentálně podstatně jednodušší prostě port zakázat nebo povolit v celé síti i když je to vlastně složitější technicky. Koncepčně je to primitivní a nic víc obvykle nepotřebuje.

Víte co, nechápejte to (já vlastně chápu proč to nechápete, ono to technicky nemá logiku ale to na věci nic nemění), ale pak se nedivte, že zářný svět IPv6 a čehokoliv dalšího prostě běžné uživatele vůbec nezajímá. Mají doma šroubovák a kladivo a to jim k zařízení toho, co potřebují stačí.

Nestačí to možná tak vám. Ale to na věci nic nemění.

Právě naopak pro uživatele je mnohem jednoduší pochopit, že na routeru mají firewall, který všechny příchozí spojení blokuje a že když chtějí něco mít dostupné z internetu, tak to stačí povolit ve firewallu. Chcete povolit nějaký port na všech zařízeních žádný problém stačí nastavit firewall. A teď jim to samé zkuste vysvětlit s NATem. Už slyším ty dotazy proč se ty adresy musí měnit a proč když mám adres 192.168.0.1, tak mi to ukazuje 82.82.0.54.
A ještě jednou NAT je jenom stupidní překlad jedné adresy na druhou nic víc nic míň nemá to s bezpečností nic společného.
Jenže tady nejde o uživatele (těm je to opravdu šumák, protože netuší, že tam něco jako IP adresa vůbec je), ale hlavně o poskytovatele, kteří nyní platí velké peníze za veřejné IPv4 i když by mohli mít veřejné IPv6 zadarmo. IPv6 only bude nakonec výhra pro všechny.

Nebude. Není potřeba. Na jeho adopci je to vidět. Tyhle teorie jsou přesně ty teorie lidí, co tomu sice rozumí, ale běžné uživatele vůbec nejsou s to pochopit.

Je potřeba, a potřebuje to i běžný uživatel. Jenom neví, že se to jmenuje IPv6, protože tomu nerozumí (stejně tak, jako neví, že potřebuje TCP, ale kdyby se mu vypnulo, tak si hned půjde stěžovat).

Pro toho je mentálně podstatně jednodušší prostě port zakázat nebo povolit v celé síti i když je to vlastně složitější technicky. Koncepčně je to primitivní a nic víc obvykle nepotřebuje.

Nic přeci nebrání výrobcům zařízení (krabiček, routerů), aby takto zjednodušenou správu udělali i na IPv6. Na IPv4+NAT je to technická nutnost, ale na IPv6 to není nijak vyloučené.

Dokonce by bylo docela prospěšné, kdyby se to stalo nepsaným standardem na přechodnou dobu, než lidé objeví nové možnosti.

Neodpustím si poznámku o tom, že stejná nevole byla, když přišli výrobci modemů a SOHO routerů s touto zjednodušenou správou pro NAT. Mnoho polo-lajko-šťouralo-profesionálů tehdy brblalo, jak je šílené nastavit router, když každý výrobce k tomu přistupuje jinak. Jeden jen podle portů, druhý pokročilejší konfigurací s nějakou vnitřní magií. Jeden to nazývá NAT, druhý PAT, třetí NAPT. Další zavádí označení DMZ. Někteří umožňují zapínat a vypínat aplikační helpery, jiní je mají nevypnutelné (a jiní nezapnutelné).

Nic přeci nebrání výrobcům zařízení (krabiček, routerů), aby takto zjednodušenou správu udělali i na IPv6

Výrobcům v tom "brání" cena. Místo 4kbit flashky tam budou muset dát 32kbit a místo SoC za 10 centů tam bude muset být soc za dolar aby se tam vůbec ty IPv6 adresy vešly a aby to to zařízení vůbec zvládlo s rozumnou propustností obsloužit. Pak bude muset najmout druhého vývojáře, protože znalosti toho současného píšícího to celé v JavaScriptu edice rok 1995 už na IPv6 nestačí. Takže ve výsledku router s designem klingonské bitevní lodě podporující Wifi7 nebude stát 500,- ale verze s podporou IPv6 bude za 2000,- a to si přece koncový uživatel nekoupí, protože ani neví, co to IPv6 je. (Tento text berte prosím s nadsázkou).

Tak jo, jenže on si uživatel koupí router za 4 stovky a ten má mizernou wifi, a tak si pořídí nějaký extender, a ten moc nepomůže... až si nakonec stejně koupí ten router za ~2 tisíce, kde už zase IPv6 obvykle je.
Kromě toho si významná část nic nekoupí, protože to dostanou od providera (O2, ... a u UPC ani není jiná možnost - no dostanou, mají pronajato). Ale tyhle routery/modemy už dost dlouho IPv6 mají a out-of-the-box fungující. Sice tam jsou mouchy (O2: máte prefix /64; UPC: sice máte /56, ale není jak to delegovat na další router, takže efektivně stejně máte /64).
Nicméně vám zařízení fungují a v lokální síti máte dual stack.

Já nechápu, proč tohle výrobci vyvíjejí (a asi všichni víme, že ten výsledek v SOHO routerech je velmi často strašný zprasek). Já kdybych dělal router, tak tam dám OpenWRT a nastavím to jejich „Luci pro BFU“ a ještě ušetřím, protože nebudu muset psát webové konfigurační rozhraní. No a OpenWRT samozřejmě IPv6 podporuje, a to i na historických routerech s 4 MB flash a 32 MB RAM, takže žádné dražší komponenty se nekonají.

Opravdu rád bych viděl router pro IPv4 s firmwarem, který se vejde do 512B FLASH. A ještě psaný v JavaScriptu.

Opravdu rád bych viděl router pro IPv4 s firmwarem, který se vejde do 512B FLASH. A ještě psaný v JavaScriptu.

Hlavně ty úvahy typu "na IPv6 by byl potřeba silnější (dražší) hardware zcela ignorují skutečnost, že za tu dobu, co se tenhle argument pořád dokola opakuje, se velikosti pamětí všeho druhu i výkony procesorů, které lze koupit za stejné peníze, narostly o několik řádů. Když jsem poprvé slyšel o tom, že se pracuje na nové verzi IP protokolu, měl jsem v počítači 4MB RAM a 80MB disk - a to tehdy patřilo k nadprůměru. Dneska mám přímo v procesoru 6MB L2 cache a 64MB L3 cache, RAM narostla o více než čtyři řády a diskový prostor o více než pět. Takže i kdyby bylo skutečně potřeba čtyřikrát víc paměti a čtyřikrát vyšší výkon procesoru (což ani jedno samozřejmě není pravda), bohatě by se v tom ztratilo.

Nemluvě o tom, že cena pamětí (a hardware vůbec) u konzumního routeru stejně tvoří poměrně malou část koncové ceny.

Jednodušší na straně provozovatele služby to bude v tom, že IPv4 nejsou a nemusí je shánět.

Jednodušší pro ISPíka to bude, že se nemusí starat o CGNAT a podobný pitomosti. Nemusí logovat, kdo kam lezl, prostě přidělí prefixy a když dojdou benga, sdělí, na koho je prefix psaný a hotovo. Taky může díky multicastu během olympiády ušetřit kapacitu uplinku a páteře.

Jednodušší pro výrobce IoT je to v tom, že nepotřebuje server, přes který se jeho výrobky domlouvají. Nemusí ho kupovat, živit, vyvíjet appku ani platit hotový řešení v čmoudu.

Jednodušší pro koncáka je to v případě, že chce něco rozchodit. Chceš se dostat na domácí NAS? Nepotřebuješ tunelovat porty a složitě konfigurovat NAT, jenom si blikneš QR kód s IP adresou a klíčem do mobilu a hotovo. Připojíš se odkudkoliv

Horší to mají zlí hoši. Není tam SPOF, který by vyřadil polovinu kamer ve městě tím, že se kamery přes NAT nepřipojí k DVR. Není tam jeden provozovatel služby, na kterýho by zaklekli chlápci v uniformách. A 128+16b se skenuje hůř, než 32+16b, že...

u toho IoT je trochu potíž v tom, že Tasmota IPv6 by default neumí a i když si to člověk zkompiluje s podporou, tak management je dostupný po http a musí řešit, jak se k tomu vlastně zabezpečeně připojit. Ale řeší se to, jen to bude na dlouho.

No protože je 99% jistota, že ISPík propustí IPv4 a 20% jistota, že si to čuchne k IPv6. Protože ISPíci jsou lemry a SOHO krabičky jsou na tom s podporou bídně... Dokud se tohle nezlepší, tak tak se podporou jenom IPV6 ořízneš od většiny zákazníků a dual stack zbytečně žere paměť a výkon CPU.

Jednodušší pro výrobce IoT je to v tom, že nepotřebuje server, přes který se jeho výrobky domlouvají.
Jak se bez serveru ty IoT výrobky najdou a nakonfigurují, aby to zvládl běžný uživatel? Jak bude výrobce bez serveru šmírovat... pardon, sbírat data pro účely zlepšování služeb?

> Jak se bez serveru ty IoT výrobky najdou a nakonfigurují, aby to zvládl běžný uživatel?

Dnes na to zvyčajne používajú mDNS-SD. Používateľ si stiahne appku a tá má workflow, aby sa pripojila na SSID zariadenia, používateľ nastavil svoju wifi, zariadenie sa prehodí a appka nájde zariadenie v používateľovej sieti. Následne ho pridá do zoznamu používateľových aplikácií, ktoré môže ovládať. To všetko samozrejme mobilom; pre desktopové systémy sa SSID prehadzuje ručne, pripája na well-known ip adresu z browseru a cez browser nastaví SSID a prípadná statická ip adresa.

Tak to funguje pre IoT čo podporujú wifi. Tie, čo majú iné rádio, napríklad zigbee, tam je to väčšia sranda. Skenujú sa QR kódy na zariadeniach, stláčajú párovacie tlačidlá, atď.

Spárovat to jde i jinak - připojím to do sítě, připíchnu se s USB klíčenkou, zmáčknu tlačítko a zapíše se soubor s IP adresou a vygenerovaným tokenem pro přihlášení. Ten pak dá přechroupat prográmku v PC nebo v mobilu a je to. Pokud se to udělá dobře, tak se do zařízení nikdo bez fyzickýho přístupu k němu nebo bez platnýho tokenu nedostane.

Nachápu, jak se na základě dat od uživatele zlepšuje služba pro něj, když se výrobce neobtěžuje ani s bezpečnostním updatem a pokud vyjde nový FW, je většinou horší než ten starý. Ale pokud někdo věří, že svět bude hezčí, nikdo mu nebrání posílat jednou týdně výrobci report jako opt-in.

To právě NAT vůbec nedělá. NAT jen tupě přepisuje adresy v hlavičce tam a zpět. Žádné oddělení a filtraci nezajišťuje. To dělá právě ten firewall.

„už z princípu ako sieť funguje nemôže byť každé zariadenie pripojené na WAN. Neviem si predstaviť tlačiareň pripojenú do WAN.“

Přestaň si myslet, že budeš mít tiskárnu zapojenou do WAN. Pořád to bude LAN, akorát s globálními veřejnými adresami. A to kdo se odkud kam dostane je jen a pouze záležitost firewallu.

To máte marné. Je to jako vysvětlovat proč jezdím do práce na koloběžce na serveru pro automobilisty. Lidé zde sítím rozumí a tak nerozumí, že pro někoho, kdo sítím nerozumí je NAT jako nástroj podstatně pochopitelnější takže když se pak ve výsledku zkombinuje s firewallem, je to pro něho jednoduché a bezpečné řešení, které je schopen triviálně a intuitivně chápat bez toho, aby se musel zabývat dalšími detaily.

martinpoljak: Co je na NATu pro běžné uživatele pochopitelné? Jak to může být lepé pochopitelné, než nic? Podle vás běžný uživatel snáze nastaví firewall+NAT než firewall? Nemyslím si, že tady nikdo kromě vás nerozumí tomu, jak běžní uživatelé přistupují k sítím. Zatím to spíš vypadá, že píšete nesmysly.

Zkusil bych to uvést na konkrétním příkladu. Uživatel má NAS s adresou 2001:db8::10. Chce na něj povolit HTTPS provoz z internetu. Povolí tedy na routeru komunikaci na 2001:db8::10 na port 443. Jak jednodušeji to nastaví, když na tom routeru bude mít i NAT?

Možná vás to překvapí, ale ano. Nesmysly, pane Jirsáku, píšete vy a nejen tady a teď. A to si klidně berte osobně.

martinpoljak: Nějak jste zapomněl uvést ten příklad, jak si uživatel zpřístupní z internetu svůj NAS, když ho má za firewallem a za NATem.

Použije forwardované porty. To, že to nefunguje, není problém vyčerpání adres; neexistuje důvod, aby ISP nemohl každému říct „venkovní adresa je 1.2.3.4 a forwarduju vám porty 14520 až 14540“. Ten problém bude někde hlouběji a úplně vidím, jak po zavedení IPv6 budou běžné podobné zprasky: ISP bude blokovat příchozí provoz „protože bezpečnost“; ISP přidělí /120 (zdravíme do Wedosu); ISP přidělí _jednu_ adresu (třeba na mobilech přes PPP, protože datový tarif pro notebooky je dražší než datový tarif pro mobily). Atd.

To je jak s komunismem - když tu byl NAT (myšleno především masquerade) 20 let, tak bude dalších 20 let trvat, než se podaří jej z myšlení vymýtit. Soudobá představa, že NAT je něčím zcela přirozeným, co tu bylo vždy a nedá se bez toho obejít, mezitímco přímé adresování je zbytečností, výstřelkem, hipsterstvím či kratochvílí znuděných akademiků, přetrvává.

Nikdo neříká, že se bez toho nedá obejít. Ale málokdo potřebuje cokoliv lepšího. To je rozdíl.

Lidé zde sítím rozumí a tak nerozumí, že pro někoho, kdo sítím nerozumí je NAT jako nástroj podstatně pochopitelnější takže když se pak ve výsledku zkombinuje s firewallem, je to pro něho jednoduché a bezpečné řešení, které je schopen triviálně a intuitivně chápat bez toho, aby se musel zabývat dalšími detaily.

Nechápu, co tím chcete říct. Abyste povolil provoz, musíte znát IP adresu, protokol a u některých protokolů port. Např.:

IPv4:
Veřejná IP adresa 195.88.64.12. Port tcp/80 povolit na vnitřní 172.16.0.1.

IPv6:
Veřejná IP adresa 2001:470:5a28:16::1 povolit port tcp/80.

Uživatel nemusí vůbec vědět, že existuje něco, co se nazývá "NAT" - ani v jednom případě. Prostě vidí informaci o tom, jaký provoz je povolený a jakou IP adresu má nahlásit protějškům. Pokud o pojem "NAT" zavadil, tak v tom může žít dál, i když přejde na IPv6 a NAT tam technicky nebude.

Zatim teda vidim nekolikrat za sebou ze lidi nechapou predevsim ten NAT (a dost si ho pletou s firewallem).

@mlocik97 Fakt, jo? Doma mám rozdělený zařízení do několika skupin:
- IPTV - tam jsou jenom set-top-boxy. Nemám kontrolu nad FW a nevyužívá to nic ve vnitřní síti, tak jsem to odsekl a nevidí to nic bokem.
- LOCAL - jsou zařízení jako tiskárna, který nechci, aby někdo používal zvenčí, něco stahovaly nebo odesílaly a aby se dostaly na jinou skupinu zařízení.
- DIRTY - věci, kde není update a nejsou pod kontrolou ( telka s HBB,...). Můžou na net a nikam jinam.
- LAN - normální počítače, co můžou do DMZ a LOCAL
- DMZ - zatím 1ks HC2 s NextCloudem, dostupný zvenku i z LAN a DIRTY

Jede to všechno na dual stack. NAT je jenom na IPv4 a jenom proto, že mám jenom jednu veřejnou IP adresu a několik sítí. Na IPv6 to jede krásně bez NATu (mám od ISP prefix /56). Hádej, jak jsem to udělal?

-> Petr M:
Mám to podobně, ale dual stack jen v nutnosti, jinak pouze IPv6, kde to jde, s možností NAT64 (hodně provozu přes to jde, také 4->6 zvenku).

IPTV: pozor, settopboxy (obzvlášť androidí, ale i Enigma) těžká šmíra, je třeba masivně blokovat (masivní biče).
LOCAL: Můžou mít ULA, případné aktualizace pak lze řešit ven přes proxy, nebo vlastní cache uvnitř sítě.
DIRTY: TV Hbbtv - stejný drek jako settopboxy, patří do podsítě IPTV.
LAN: Mám jako 2 podsítě - bezpečnou (linuxové počítače s aktualizacemi) a nebezpečnou (widle ap.), liši se pochopitelně filtrováním.

Mimoto další, např. několik VLAN pro wifi dle rozsahu přístupu a použití.

Ono NAT a firewall riešia sieť z opačných koncov a dosť odlišne.
Zde je to pěkně vysvětlené:
https://www.root.cz/clanky/proc-neni-nat-totez-co-firewall/

Drtivá většina zažívá to samý, akorát to neumí pojmenovat a nezná příčinu, takže nemůže ISPíka nakopat do koulí

Jak ten vendor lock-in Amazon monetizuje? Provoz cloudových serverů něco stojí, takže Amazon potřebuje minimálně pokrýt tyto náklady.

1. To záleží na tech. provedení.
2. To má především ukázat, až do jakých uchýláren se může zvrhnout zbytečná, umělá závislost.

Ono je aj otázka, čo je to za vypínač, že potrebuje mať prístup ku cloudu, aby zapol svetlo.

"Normálny smart" vypínač je relé, ktoré monitoru stav fyzického vypínača, skombinuje ho so svojim interným stavom (ktorý je možné meniť mobilom/nejakým gatewayom/z cloudu/atď) a následne kontroluje stav pripojeného spotrebiča tak, že mu do kábla pustí/nepustí 220V - ako klasický vypínač. V prípade, že sa nevie pripojiť do cloudu/wifi/zig­bee/atď, funguje úplne klasicky, ako keby smart nič nebolo.

Potom sú tu však rozličné tlačidlá/vypí­nače/apod, ktoré nie sú zapojené do elektroinštalácie (tá je napevno zapnutá) a fungujú len cez cloud/lokálnu gateway/atď. Toto sa zvyčajne používa, pokiaľ sa dorába smart funkčnosť v existujúcich priestoroch a majiteľ sa nechce dotýkať elektroinštalácie. Je to lacnejšie, ale s kompromismi a práve toto ide do tých úchylární.

@bez přezdívky

Ještě jste zapomněl na chytré vypínače, které fungují peer to peer, spíš jako stavový automat. Nemají potřebu žádné gateway, mohou ji mít a nemusí. Ty jsou v profesionálních instalacích nejčastější, protože neobsahují SPOF.

A zapomněl jste na světlo, které má trvalý přívod elektřiny a vypínač přímo na svítidle. Stropní svítidla na řetízek.

To je ale vedlejší, jaké různé systémy existují. Nemá smysl se pozastavovat nad tím, že každé řešení má své nevýhody. Má i své výhody. Zadavatel má možnost si to zvážit a rozhodnout se. Je hloupé kritizovat druhého, proč si pořídil něco, co se zrovna Vám nelíbí.

Ja som nikoho nekritizoval; chápem, že lepšie sa predávajú krabice, ktoré zákazník doma vybalí a nejako to funguje, ako keď pri kúpe krabice musí naplánovať a vykonať rekonštrukciu domu.

No ale potom sa môže stať, že si nerozsvieti na záchode, keď vypadol hub.

To, co jste popsal jako „normální smart vypínač“ moc smart není. Aby to bylo smart, nemůže mít fyzický vypínač svůj stav, nýbrž jen posílá informaci „změň stav“.

Přístup do cloudu se používá proto, že to celé chcete ovládat z mobilu, který je připojený do sítě operátora – a musí komunikovat s domácí branou. A pak už je to jen otázka implementace. Pokud se aktuální stav světel drží někde v cloudu a vypínač posílá do cloudu událost „změň stav“, na základě které cloud změní stav a pošle zpět zprávu „sepni relé“, výpadek cloudu bude znamenat, že si nerozsvítíte. (Naříkám že je to rozumná implementace, ale je možná.)

> Aby to bylo smart, nemůže mít fyzický vypínač svůj stav, nýbrž jen posílá informaci „změň stav“.

Ešte raz: ...relé, ktoré monitoruje stav (pripojeného) fyzického vypínač, skombinuje ho so svojim interným stavom (ktorý je možné meniť mobilom/nejakým gatewayom/z cloudu/atď) a následne kontroluje stav pripojeného spotrebiča tak, že mu do kábla pustí/nepustí 220V...

T.j. stav relé/chytrého vypínača/výstupu na spotrebič nie je rovnaký, ako stav pripojeného fyzického vypínača. Fyzický vypínač vie ovplyvniť stav relé, relé sa rozhodne, ako zmenu stavu bude interpretovať (napr. momentary/tog­gle/edge/igno­re).

> Přístup do cloudu se používá proto,

Ja viem, prečo sa to používa. Aktuálny stav sa v cloude nedrží, je to zbytočné (ok, možné to je, ale nezmyselné), cloud je proxy medzi aplikáciou+asis­tentami (Google Assistant/Ale­xa/Homekit) a zariadením. Pokiaľ vypínač zvláda wifi (ako shelly alebo sonoff) a nepotrebuje zigbee/z-wave, tak sa to dá predať zákazníkovi aj bez hubu.

Fyzický vypínač má dva stavy – zapnuto a vypnuto (podle toho má své jméno). Ty stavy jsou fyzicky vyjádřené překlopením kolébky vypínače. Samozřejmě můžete udělat „smart“ instalaci, že vypínač v poloze „zapnuto“ bude někdy znamenat, že světlo svítí a někdy, že nesvítí, stejně tak i opačný stav. Ale taková instalace by byla na pěst.

Ve smart instalaci dává fyzický vypínač smysl jako bypass. Jinak je podstatně lepší fyzický přepínač, který pošle signál, že se má změnit stav, a případná indikace stavu indikuje skutečný stav vyhodnocený nějakým řadičem.

> Samozřejmě můžete udělat „smart“ instalaci, že vypínač v poloze „zapnuto“ bude někdy znamenat, že světlo svítí a někdy, že nesvítí, stejně tak i opačný stav. Ale taková instalace by byla na pěst.

Problém je v tom, že vypínač je možné preklopiť len fyzicky, nedá sa mu povedať, aby sa preklopil. Preto napr. shelly má pre vypínač dva režimy: toggle a edge. Edge je presne to, čo popisujete, toggle treba vrátiť najprv do polohy ktorá zodpovedá aktuálnemu stavu až potom ďalšia akcia zapne/vypne zariadenie.

Väčšina používateľov preferuje Edge, to že vypínač fyzicky nezodpovedá stavu im nevadí, sú na to zvyknutí zo schodišťákov.

Alternatívou je vymeniť vypínače za spínače, aj dvojpolohové (jedným zapnúť, druhým vypnúť). Pre väčšinu inštalácií to nie je problém, ale niekedy nájsť relé ktoré vie obslúžiť viac ako 2 spínače na jednom okruhu už problém môže byť (pri prepínačoch 2 x č. 5B+N x č. 7 to nevadí, celá séria sa tvári ako jeden).

Jenom upřesním, že schodišťák je také spínač. Indikace u spínače může být řešena například LEDkou (u schodišťáku dříve doutnavkou). A ano, ovládání bez indikace stavu je pro lidi pořád daleko přijatelnější, než indikace, která ukazuje naprosto náhodně.

Jenom upřesním, že schodišťák je také spínač. Indikace u spínače může být řešena například LEDkou (u schodišťáku dříve doutnavkou).

Tady jste se spletl v elektrikářských pojmech. Schodišťový vypínač ("schodišťák") je technicky přepínač nebo dvojpřepínač, pokud slouží jako vložený.

Spínač na schodišťový automat elektrikáři označují jako "tlačítko" (případně s tou doutnavkou).

Řeč byla o tom, na co jsou lidé zvyklí. Ne jak to nazývají elektrikáři.

Řeč byla o tom, na co jsou lidé zvyklí. Ne jak to nazývají elektrikáři.

Ano, na toto jsou lidi zvyklí. Schodišťák byl a je přepínač.
Vložený je křížový vypínač ("křížák").

Ovladač schodišťového automatu je "tlačítko".

Viz zde (sekce řazení 6 a 7 + oddíl "tlačítko"):

https://cs.wikipedia.org/wiki/Vyp%C3%ADna%C4%8D#Z%C3%A1kladn%C3%AD_proveden%C3%AD_sp%C3%ADna%C4%8D%C5%AF

Tak znovu. Konfiguruješ firewall. Víš o tom jenom to, že od někud přijde balíček dat, má nějakou adresu odesílatele, adresu příjemce a pár dalších atributů.

Adresa příjemce je pro tebe stejně viditelná, jako v přírodě druh zvířete. A najednou se ti tahle vlastnost změni pod rukama a při tom je to ten samý balíček dat,...

No... destination nat...
1. klient za natom posle paket na sever
2. Pravidlo v prerouting tabulke paket odchyti a kedze je to dnat pravidlo tak zmeni src adresu na svoju ip a tuto skutocnost si poznaci vo svojej nat tabulke.
3. Paket poputuje podla routovacej tabulky k cielovemu servru
4. Server vytvori na poziadavku odpoved, src adresu nastavi svoju a dst adresu nastavi NAT.
5. Pravidlo vo firewalli odchyti prichadzajuci paket, porovna ho so svojou tabulkou a ak najde zhodu tak nastavi dst adresu klienta ktory poziadavku poslal.
6. Paket poputuje podla routovaciej tabulky cez urceny interface na interface zariadenia ktore ma bindnutu dst adresu

Kde je v tom problem, server ani len netusi ze komunikuje s NATom, clovek ktory vie co robi si nastavi routovanie a pravidla vo firewalli natu tak aby sa kazda odpoved dostala tam kam ma.

Preberieme aj source nat? ;)

dw: A pak zjistíte, že se na ten server nedostanete z vnitřní sítě. Navíc jste to napsal špatně, DNAT je Destination NAT, tedy se mění adresa cíle, ne zdroje.

njn, moja chyba, malo tam samozrejme byt dynamic nat. Zrejme ta pozdna hodina.

s destination nat sa pouzije conntrack aby to fungovalo.

Mam DNS recursory ve vnitrni siti na "interni" ipv4+ipv6. Mam DMZ sit, ktera ma pouze public ipv4+ipv6. Mam DMZ2 sit, ktera ma pouze public ipv4+ipv6.

Ted mi vysvetlete, jak server v DMZ a v DMZ2 pripojim po ipv4 na ty rekurzory (port 53).

Mam DNS recursory ve vnitrni siti na "interni" ipv4+ipv6. Mam DMZ sit, ktera ma pouze public ipv4+ipv6. Mam DMZ2 sit, ktera ma pouze public ipv4+ipv6.

Ted mi vysvetlete, jak server v DMZ a v DMZ2 pripojim po ipv4 na ty rekurzory (port 53).

Ak izolujete DMZ a DMZ2 uplne izolujete od intranetu tak preco by nejakym sposobom mali vidiet do intranetu? Ak maju servre v DMZ a v DMZ2 vidiet rekurzor tak ho nemozete strkat tam kde by k nemu nemali mat pristup. Alebo si trochu nastudovat sietovanie a na serveroch v DMZ a v DMZ2 pridat interface ktore su v "internej" sieti.

10. 6. 2021, 18:00 editováno autorem komentáře

Ja nemluvim o uplne izolaci DMZ. Ja potrebuji, aby sluzby v DMZ komunikovaly s intranetem s tim, co maji povolene na firewallu.

Aha, takze kvuli tomu, aby videli na 4ce do interni site, tak musim pridat interface s prechodovou ipv4 sit. Pro kazdou takovou DMZ vlastni prechodovou sit. A pro kazdou takovouhle prechodovou sit extra pravidla na firewallu. Komplexita administrace a bezpecnosti nasobne roste.

Je videt, ze jste rozsahlou sit nikdy nespravoval.

Pokud píšete, že vnitřní síť máte na na neveřejných IPv4+v6 (ULA?) a v DMZ a DMZ2 máte vše na veřejných IPv4+global IPv6, tak není snad problém to zaroutovat dovnitř i bez nějakých přechodových mechanizmů, když si to povolím ve firewallu. Nic nebrání přeci tomu, aby mezi sebou komunikovaly neveřejné/veřejné IPv4 globální/ULA IPv6 adresy, pokud si nastavím patřičně směrování a firewall.
Pokud pominu, že bych viděl jako chybu, aby z DMZ sítí se sahalo na DNS do vnitřní sítě (řešil bych drouhou sadou v DMZ, kam se tlačí DNS data z vnitřku a všechny DMZ sítě vyyužívají tuto sadu serverů v DMZ).

Pro mne je mnohem bezpecnejsi, kdyz nedovolim verejnym IP komunikovat s rfc1918 sitemi by default. Eliminuje to chybu, kdy se z verejne IP da dostat do interni site nejakym budoucim nastavenim firewallu.

Ano, extra rekurzory jsem jiz zvazoval. Ale to byl jen priklad. Mam ruzne sluzby, ktere potrebuji komunikovat z DMZ do intranetu a ne kazdou sluzbu lze pushovat do DMZ. Treba reverzni proxy, centralni logy, monitoringy, backupy...

Tak pak mám možnost v té DMZ, která ,má jít ven nebo i dovnitř, aby hosti měli vedle sebe veřejnou a neveřejnou IPv4 adresu, podobně globální a ULA IPv6 adresu a nastavním preferencí pak komunikace ven půjde z veřejné/globální adresy a komunikace proti vnitřní síti bude používát neveřejnou/ULA a hranice mezi DMZ a vnitřkem nemusí překračovat mišmaš adres.

Ve Vasem vysledku tam pak budou nejmene 4 adresy, tedy 2 nebo 4 interface(vlan):

1] GUA ipv6
2] ​public ipv4
== prvni fqdn
3] ULA ipv6
4] rfc1918 ipv4
== druhe fqdn

Na firewallu = mismas. Routovani mismas. Preference vyberu zdrojove adresy kvuli ULA mismas. Nutnost nasadit ULA do vnitrni site. RFC1918 a ULA jdouci na tu 1]2] se NAT na ip interface firewallu. Ta ip je pro kazdou dmz jina. Ble.

Mam to udelane takto na 1 ci 2 interface(vlan):
1] GUA ipv6
2] public ip4
== jedno fqdn

Na firewallu = mene pravidel nez v prvnim pripade. Jistota, ze mi z public IP neprojde nic do rfc1918 (+1 pravidlo na fw). NAT z vnitrni site do 1]2] dokud nebude mit interni klient GUA ipv6.

Tak ta komplikace s dvěma IPčky na serverech DMZ je proto, ať nemusím NATovat na přechodu DMZ a intranetem v obou směrech. Pokud mermomocí chcete NATovat, tak pak je zbytečné do DMZ cpát neveřejky/ULA adresy. A pokud nechcete propouštět pakety přes hranici kde zdroj/cíl není oboje veřejka nebo neveřejka, tak si to musíte NATnout.
Pořád vidím nejčistější nechaz v DMZ veřejky/global a pouštět to dovnitř a ven do DMZ bez NATu (pokud v DMZ mají servery jen jednu síť, skrz kteoru jdou do internetu i do intranetu). Řešení s NATem bych u tohot odmítl, NATovt na veřejku až jen odchozí provoz, co jde mimo firmu a její DMZ. A pokud je to větší síť tak očekávám, že je jiný router/firewall pro cestu internet/DMZ a přes jiný jde provoz DMZ/intranet.

„Pro mne je mnohem bezpecnejsi, kdyz nedovolim verejnym IP komunikovat s rfc1918 sitemi by default. Eliminuje to chybu, kdy se z verejne IP da dostat do interni site nejakym budoucim nastavenim firewallu.“

Na to stačí 1 (v úplném provedení 4) pravidlo na firewallu, ale když si chcete přidělávat práci a vymýšlet ony rovnáky...

Ano, mam na to 1 pravidlo. Je skoro na vrcholu seznamu pravidel ve fw.

Nebo snad z toho meho komentare vyplyva neco jineho?

Ale stjený počet pravidel mi vyjde pokud začnu dropni pakety nemající zdrojovou adresu z DMZ přídělu a mířící dovnitř. A za tím mohu dál pokračovat povolováním vyjímek...

Na to, aby mi ULA nelezly přes rozhraní do inetu, stačí 1 pravidlo!!!!! Na to není potřeba zakazovat komunikaci mezi veřejnými adresami a ULA.

Já to chápu tak, že czechsys neřeší pimárně to, aby mu neutíkaly ULA a neveřejné IP adresy do Internetu. On řeší to, že chce, aby uvnitř DMZ zón se vyskytovaly jen pakety, kde zdroj i cíl je veřejná IPv4/globální IPv6 adresa? Takže při přístupu z intranetu do DMZ zón provádí srcnat na veřejnou adresu routeru a všechny přístupy z intranetu tak vůči serverům v DMZ vystupují s veřejnou IP routeru. Jen netuším, jak řeší přístup z těch serverů z DMZ do intranetu, což požaduje také? To pak leda musí se spojovat na IP adresu routeru do intranetu a něm dělat dstnat na interní IP adresu? To se mi jeví jako dost neštastné řešení už jen z důvodu, že pokud hovoří o větším systému, tak budu určitě chtít sledovat i toky v jednotlivých semgentech a takto si komplikuji párování spojení, musím k tomu přikládat i vyčítáno stavů NAT stroje přes flow, taktéž logy v DMZ budou ochuzeny o info IP adresy klienta atd.
Ale pokud to tak má vyřešeno pro IPv4, tak pokud na tom mermomocí trvá pro IPv6, tak to jde řešit překladem prefixů na hraniční bráně mezi DMZ a intranetem (NPTv6), ale rozhodně je to něco, co se silně nedoporučuje dělat.

Pro mne je mnohem bezpecnejsi, kdyz nedovolim verejnym IP komunikovat s rfc1918 sitemi by default. Eliminuje to chybu, kdy se z verejne IP da dostat do interni site nejakym budoucim nastavenim firewallu.

Podle mě je to přesně naopak. Odfiltrovat síť (i veřejnou) je otázka jednoho pravidla, nebo celkové policy.

Díky NATU naopak máte mišmaš pravidel - např. z vnitřní sítě - via vlastní veřejnou adresu - zpět do vnitřní sítě. Nebo odlišná pravidla z vnitřní sítě 1 do vnitřní sítě 2 vs. z internetu do vnitřní sítě 2 (obvykle to, co je přístupné zvenčí, chcete mít přístupné i z ostatních vnitřních sítí)... Na firewallu pak musíte zběsile nakombinovat pravidla...

Častým výsledkem je, že je tam díra, kterou nikdo nevidí, nebo naopak je něco z různých směrů dost nelogicky nedostupné (nejčastější je obrácení NATU z vnitřní do vnitřní).

Je videt, ze jste rozsahlou sit nikdy nespravoval.

No, co taky server hosting. Spravovali ju hlavne kolegovia. Ja som sa k tomu dostal ak bola treba nejaka specialitka, inak som bol ako admin nerentebilny, pretoze som ako admin nebol plateny. Ansible je dobry kamarat ak ho zvladate na pokrocilejsej urovni ;)

Když ta VPN bude mít úplně jiný výstupní server v jiné zemi (podle potřeby) a jinak řešenou routu, tak proč by ne ? Jinak řečeno, jste si jist, že Ipv6 u Netflixu nefunguje ostatním ? Neblokuje to třeba váš výstupní server resp. fw českého poskytovatele ? Já bych začal tím, že bych si nejdřív prošel příslušná fóra...
Ale samozřejmě to píšu s vědomím, že Ipv6 zatím neprovozuju a ani Netflix předplacený nemám... Dal jsem si teď vpn do vyhledávání a mělo by to fungovat viz třeba restoreprivacy­.com/vpn/best/ip­v6/. Technicky vzato openVPN to podporuje a wireguard taktéž, nevidím problém...

Že? A přitom by to mělo fungovat z fleku, hned a napřímo. Kde se asi stala chyba...

Já ale bohužel tuhle možnost nemám. Lokální Wifi i kabelovka jsou na tom s nepodporou IPv6 stejně. Nevědí, že to existuje.

prudil jsem 1x ročně a bylo to zbytečné. Naštěstí se mezi wifináři rozjel trend nabízet náročnějším uživatelům řádově vyšší rychlosti na 60GHz a občas k tomu přidávají i IPv6.

To bohužel není pravda.

Platba za vodu nebo elektřinu se skládá z provoz přípojky a za měřidlem si náklady nese zákazník - v tom je si to rovno s rozdělením konektivity mezi sousedy.

Druhá složka je za spotřebu. U vody či elektřiny to dodavatel spočítá z měřidla. U připojení k internetu ale převažuje koncept, kdy se spotřeba dat nepočítá a ISP ji má zahrnutou v ceně. To mu funguje jen díky tomu, že může počítat s tím, že "spotřeba" internetu v domácnosti se pohybuje v určitých mezích.

Pokud byste od vodáren zaplatil přípojku před hranicí obce a po obci si natahal a udržoval trubky sám, vodárnám by to víceméně nevadilo. Osadí měřidlo před obec a ještě sníží cenu, protože nebudou mít na hrbu údržbu kilometrů potrubí.

Pokud byste si koupil jednu gigabitovou SOHO přípojku a rozvedl ji po celé obci, ISP zkrachuje, protože za SOHO cenu to připojení dodat nedokáže.

Proto mají ISP v podmínkách docela přirozený požadavek, že přípojka slouží jedné domácnosti. Kdyby došlo na spor, budou argumentovat ad absurdum tak, jak jsem popsal já a pravděpodobně spor vyhrají. Neznám však případ, že by to kdy došlo až k soudu, obvykle se skončí na dohodě, že přeprodejce bude platit nějakou kompromisní částku, nižší než by byl součet tržních cen.

Ve tvem pripade platis za spotrebu 1GBit a neco za pripojku (kdyz uz to je v baraku, tak ti kabel natahnou zadarmo, to se jim v mesicnich splatkach vrati, ale kdyz maji kopat kabel, tak uz vas musi byt hodne nebo si to zaplatite a predpokladam, ze udrzba se v mesicni platbe taky schova), tu pak rozvedes po baraku a zdarec, jasne poskytovatel moc nepotita s tim, ze vsichni v baraku budou naraz stahovat 1GBit a tim padem treba na 8mi bytech by mel dodavat minimalne 8GBit. Ale ty resis uplne to stejne, proste pocitas s tim, ze kazdy dostane nejaky pomer a budes doufat, ze duchodci to moc nevyuziji. Jako ono to je docela blbost, taky z duvodu, co pise nize Jimmy. Ale podle me v takovem pripade nejsi poskytovatel internetu, ale asi fakt zalezi jake budes mit podminky.
Spise nez domacnosti, ktere jsou dost casto i tak za NATem je to otazka pro firmy, ktere nemaji ten luxus, ze byly u rozdelovani IPv4 adres a predpokladam, ze za kazdou verejnou IPv4 adresu si zaplati.

Ve tvem pripade platis za spotrebu 1GBit a neco za pripojku

Ne, naprosto to není pravda. ISP počítá s tím, že provoz se zcela přirozeně agreguje. U některých se to projeví snížením rychlosti, ale u některých ne (nemají to tak nastavené). Ti pak za každý megabit peaku zaplatí dodavateli zcela konkrétní peníze.

Možná Vás to překvapí, ale ISP za svoji konektivitu platí právě od toho, kolik pásma spotřebují. Možná Vás překvapí i to, že pokud linku vytížíte abnormálně (co je normální průběh řeknou statistiky), dostáváte často připojení levněji, než je nákup. To ISP dokáží podržet, s určitým počtem excesivně vytížených přípojek se v ekonomice provozu počítá.

To je stejné, jako s pojišťovnami. Každému, kdo má pojistnou událost, proplatí škodu. Nikdy by však žádná pojišťovna neutáhla zaplatit škodu všem naráz, a zákazníkovi s výrazně vyšším škodním průběhem i vypoví smlouvu. Už nevím u které pojišťovny jsem to viděl, ale byl to cca desetinásobek pojistné částky.

Ale tady se nebavime o ISP, ale o jednom konkretnim baraku. Ono to nemusi byt ani nejaky podnikavy nadsenec z prvniho poschodi, ale proste z nejakeho duvodu se v baraku domluvi, ze se jim soucasne podminky nelibi, tak vsichni vypovi smlouvy a domluvi se, ze budou poptavat nejlepsi nabidku dohromady. A tu jim nekdo proste doda. Bud ta puvodni firma nebo tam treba nekdo kopne optiku, napriklad a budou mit nejake podminky - treba takove, ze dole bude router s NAT s jednou verejnou IP adresou, vlastne stejne reseni, jake by zvolil ten podnikavec z prvniho poschodi. Kdyz jim k tomu jeste prihodi /56, tak je mozna i lepsi, nez to co ti daji ted :D ...

Uplne stejny pripad, jako s vodou. Kdyz se vsichni zacnete koupat naraz, tak to taky jde poznat na tlaku teple vody u tech nahore.

Ono to nemusi byt ani nejaky podnikavy nadsenec z prvniho poschodi, ale proste z nejakeho duvodu se v baraku domluvi, ze se jim soucasne podminky nelibi, tak vsichni vypovi smlouvy a domluvi se, ze budou poptavat nejlepsi nabidku dohromady.

Tak to ano, to jde. Jen Vás možná zaskočí, že ta cena nebude už tak zajímavá. Např. za 1 Gbps pro domácí přípojku zaplatíte 500 Kč, zatímco za "ostrou" přípojku 1 Gbps zaplatíte od ISP třeba 5000 Kč.

To jste hodně v levném kraji. Za symetrický Gigabit, kde můžu jet skutečně naplno spíš tak 30 000 Kč nebo i výrazně víc/ měsíc, pokud se nepletu a to by ještě bylo celkem v pohodě. Mimochodem ten Gigabit celkem v pohodě můžete agregovat 1:100 nebo víc i v době WFH. Řekněme, že byste potom prodával "Gigabit" pro koncové uživatele za něco jako 600 Kč měsíčně, z čehož by ca. polovina byly reálné náklady na přípojku (která by prakticky vždycky měla fakt slušné parametry).
Samozřejmě s větším uplinkem rozpustíte i peak a můžete agregaci úplně v pohodě šroubovat nahoru. Když má nějaký poskytovatel třeba 300 000 přípojek, tak nemá 3 Tb spoj do internetu (kdybych bral v úvahu stejný agregační faktor jako u toho Gigabitu). Spíš tak 200-300 Gbps... na lokální úrovni ale potřebujete prostě o něco větší rezervu, kterou rozpustíte na dalším agregačním uzlu.

@Adam Kalisz

Jasně, díky za upřesnění. Vzpomínal jsem (možná špatně), že někdy před deseti lety byl gigabit tranzitu asi za 1000 EUR, ale samozřejmě se počítá s velkým odtokem do NIXU. Je pravda, že kdyby to měl být opravdu "ostrý" internet, muselo by se počítat se 100 % tranzitního přenosu.

Pointa byla v tom, že ISP do domácnosti přivede internet a počítá s agregovatelností provozu. Pokud to dodává velkoobchodně, musí počítat s opakem a díky tomu roste cena. Jiná cena bude pro firmu s přibližně odhadnutelným provozem, a jiná bude pro přeprodejce konektivity.

Přišlo mi, že pan kolega si myslí, že je gigabit jako gigabit, a nehraje roli účel přípojky.

To si samozrejme nikdo nemysli, ja puvodne jenom reagoval na to, zda si myslim, ze v tom konkretnim pripade pak jsi sam ISP a to podle me pri splneni nejakych podminek nejsi. To by pak musela byt ISP kazda druha firma nebo hospoda, co poskytuje Wi-Fi.

A zkuste si vsichni, pokud bydlite v baraku pustit najednou teplou vodu .... kdyz se bavime o te agregaci.

9. 6. 2021, 07:59 editováno autorem komentáře

Firmy a hospody, ktere poskytuji wifi pro navstevy, jsou v sede zone. Pokud z techto siti nekdo zacne skodit, kdo za to bude zodpovedny? Jak dohledate vinika?
Podobna otazka se objevuje i u te "sousedske" site.

Dalsi otazka tu uz padla a nikdo na ni neodpovedel - jak byste resil rozuctovani, kdyby se pocet ucastniku v prubehu casu menil? Kdo zaplati vyber penez, kdo zaplati sluzbu za neplatice a vymahani? A vymahani ceho, pokud to neni sluzba s jasnym dodavatelem, odberatelem a pisemnou smlouvou?

Jaka sluzba je podle Vas vhodna pro takovou "sdilecku" (rychlost down/up, agregace, IP adresace, technologie) a kolik by mela stat penez?

Kolik realne znate pripadu podobnych "sdilecek"?

Ja osobne zadnou, pro vsechny strany je jednodussi vzit si od operatora, ktereho si sami vyberou, sluzbu s rychlosti a IP parametry podle vlastniho vyberu, za cenu, jakou si dohodnou, s garancemi a redundanci, jakou ten ktery operator poskytuje.

To by pak musela byt ISP kazda druha firma nebo hospoda, co poskytuje Wi-Fi.

Zrovna tohle je docela velký problém. Zákony kladou na poskytovatele připojení spoustu povinností (mj. logování provozu). Hospody a podobní to nedělají, ale přitom to jsou místa, která nabízejí připojení bez identifikace nebo jiného právního vztahu s příjemcem služby. Je to trochu časovaná bomba, podle mě přijde doba, kdy se to bude řešit.

Ono je vůbec v životě spousta situací, kde lidé "běžně" něco nedodržují a nikdo je s bičem v ruce nehlídá. Tradiční, a srovnatelná je kontrola technického stavu před jízdou a svěření vozidla druhé osobě. Kromě půjčoven to nikdo nedělá, ale když pak přijde průšvih (nehoda, řidič nemá řidičák, přebíral auto pod vlivem, ...), tak to opravdu odnese i ten, kdo svoji povinnost nesplnil. Nic na věci nemění že "se to běžně nedělá".

5k je porad velmi slusna cena. Resil jsem rozvod pripojky od UPC - panelak - historicky cinzak. Do vedlejsiho panelaku vedlo upc, do cinzaku nikoliv ( prduchove - prazsti duchodci) . Na panelak se na sdruzeni napsala UPC business firemni pripojka a pripojil cinzak pres laserovy spoj a je to jen pro cleny.
Funguje dodnes a UPC o tom vi. Nicmene stale nema zajem jit pres tramvajove koleje a stromky v parku k individualnim klientum.

Akorat je nejaka rezie na sber dat z netflow kdyby zaklepali benga.

9. 6. 2021, 18:21 editováno autorem komentáře

Uprimne receno pokud by mel ISP v miste sit nerikam ani popel a je to fer.

Pokud mne ale zrizeni pripojky pro rezidencniho zakose stoji vic jak 1 milion korun tak byt na jeho miste trikrat zvazil takove jednani.

Jinak se poustim do vyjednavani o sdileni nakladu na budovani mezi isp a sousedy pripadne odchod ke konkurenci.

9. 6. 2021, 18:36 editováno autorem komentáře

Pokud na tom přeprodeji nebudete mít žádný "zisk", tak vás to do dvou let přestane bavit (dělat "IT servis" zadarmo). Pokud budete mít nějaké neplatiče nebo zpožděné platiče, tak ještě dříve. A také bude velká zábava při každé změně počtu připojených měnit platební příkaz u všech zůčasněných tak aby celková částka akorád vyšla.

Zisk je. Platim o dost mene do fondu oprav a mam tam zalohy.

Neplatici se resi bezne i za jine rozpocitavane sluzby a neni to muj problem ale predsedy. Resilo se i par soudu a exekuci. Nicmene ne za konektivitu ale vodu a teplo.

Az se vzpamatuje nejaky ISPik a natahne tam slusnou pripojku tak cela vec zanikne přirozenou cestou.

10. 6. 2021, 09:11 editováno autorem komentáře

To je presne to, co jsem se tady snazil ostatnim vysvetlit, dekuji :)

A taky tady na to máte odpověď, že je to jakási šedá zóna, včetně vyjmenovaných argumentů. Že to ISP neumí detekovat, nebo nechce detekovat, nebo dokonce i vědomě připouští, o tom se nikdo nepře.

Kdyby se to křížilo se zájmy ISP, tak má možnost se domáhat škody. Dokud to nenastane, tak asi v pohodě. Kde není žalobce, není ani soudce. Kdyby to ale nastalo, tak se může domáhat škody i zpětně (až do lhůty promlčení nároku).

Ještě daleko zajímavější je to z pohledu odpovědnosti. Dokud se nic nestane, tak asi taky není žádný problém - stejně, jako když svěříte auto někomu bez řidičáku, protože jste prostě předpokládal, že ho má. Ve chvíli, kdy skrz takovouto sousedskou síť proběhne útok, nebo dojde k nějakému zločinu, dopadne to stejně jako s tím řidičákem. Bude se někdo ptát, jestli máte záznamy o provozu, jako musí mít každý ISP.

To jsou rizika, která si nejsem jistý, že všichni členové (např. SVJ, nebo sdružení zájemců o připojení) kvalifikovaně posoudili, že jim to vůbec bylo k posouzení předloženo. Člen takového spolku by se pak asi úspěšně domáhal škody na vedení takového spolku (což může být i prostý organizátor akce, bez jakéhokoliv úředního statutu). Dovozovat by se mohlo, zejména ze vztahu k předpisům, které musí ISP plnit, že jde i o nedovolené podnikání.

Je to celé na vodě a funguje to jen díky tomu, že se (zatím) neobjevily popsané problémy. Osobně bych do toho s cizími lidmi (ani sousedy) nešel.

Nepřéhánějte s těmi logy. Povinnost mít záznamy o provozu mají jen provozovtelé veřejných telekomunikačních sítí. Takováto koncová síť (včetně těch wifi hotspotů v hospodách), stejně tak jako jakýkoliv ISP, který se registruje jako neveřejná telekomunikační síť, tak takovou povinnost nemá.
Je pak věcí Police dokázat, který konkrétní uživatel takové sítě byl ten škodič. Jiná věc je odpovědnost za škody - provozovatel koncové sítě, stejně tak provozovatel neveřejné telco sítě, tak nemá zákonem danou garanci, že neopdovídá za škody způsdobené datovým provozem z jeho sítě a za obsah přenášených zpráv.

Povinnost mít záznamy o provozu mají jen provozovtelé veřejných telekomunikačních sítí. (...) Je pak věcí Police dokázat, který konkrétní uživatel takové sítě byl ten škodič.

To záleží na charakteru služby. WiFi v hospodě není neveřejná telekomunikační síť. Neveřejná telekomunikační síť je telefon mezi kanceláří a kuchyní, která slouží pro interní potřebu provozovatele. Neveřejná telekomunikační síť je rozvod telefonu v administrativní budově, přes místní pbx. Specifikem neveřejné telekomunikační sítě je právě to, že odpovědnost lze dovozovat souhrnně (není potřeba hledat konkrétní osobu, škodu zaplatí ten provozovatel).

Na tom nic nemění, že se tím snaží spousta provozovatelů zaštítit. Když se zamyslíte, proč by zákazník kavárny měl být účastníkem neveřejné sítě, zatímco zákazník s DSL přípojkou měl být účastníkem veřejné sítě? Charakter je stejný: vždy se jedná o obecnou veřejnost, která se k užívání přihlásí. DSL uživatel se přihlásí objednávkou, zákazník kavárny tím, že se usadí a objedná si jídlo.

Mimochodem, i provozovatel neveřejné sítě (ať už to znamená cokoliv) musí mít právní subjektivitu a oprávnění takovou službu provozovat.

Ne, kavárna a hospoda s wifi není veřejná telko síť. Stejně jako ta síť v baráku. Z pohledu telko zákonů jde primárně o koncové sítě.
Neveřejná síť telekomunikací se z toho stane v okamžiku, kdy její provozovatle vyhlásí a zaregistuje na ČTU (aktuálně registrováno 320 subjektů pro poskytování služby přístupu k Internetu v režimu neveřejná síť), že jde o neveřejnou síť a stanoví omezující podmínky pro použití (např stanoví, že síť je určena jen pro návštěvníky hospody, kavárny, nájemníky v baráku) - jde o síť, která obecně slouží k poskytování služeb i za úplatu, ale jen pro omezený okruh učástníků (dopředu je z jejího použití někdo vyloučen - na rozdíl od veřejné sítě, kde z ní dopředu nikdo není vyloučen z užívání a deklaruje svoji veřejnost služby komukoliv, ale může pak dojít k vloučení na základě technických omezení, zájemce je třeba mimo dosah sítě).
Opravdu ta hospoda/kavár­na/sousedká síť nesplňuje podmínky pro veřejnou telko síť.
Samozřejmě jiná věc je z pohledu živnostenského zákona a případně neoprávněného podnikání atd, ale to už není primárně problém ZoEK. Jiná vc je také odpovědnost z provozování takových sítí.

Vypnutí firewallu jsem řešil s O2 infolinkou, a bylo mi řečeno, že je to možné, že je potřeba zaplatit jednorázový aktivační poplatek 500 Kč a pak ti firewall odblokují. Jo a nedělají to na předplacených kartách, jen na paušálech. Do spotřebovaných dat se ti pak počítá i příchozí provoz.

Tak pokud je adresa veřejná a není na možné se ni se zvnějšku připojit, tak není veřejná :))) To by byl jasný protimluv. A tak nějak funguje asi Ipv6 firewall, který člověk nemá pod kontrolou, tj. nepustí nic - a v podstatě to pak funguje postaru jako v Ipv4, jen na jiném protokolu.

Jinak řečeno, veřejná adresa je veřejná proto, že je veřejná, ne že je z globálního rozsahu IpvX, to je jen nějaké číslo.

To je ale samozřejmě v pořádku, že IPv6 adresa se chová stejně. Pouze u adres, kde potřebuji komunikovat dovnitř, tak je explicitně povolím. Hlavně odpadá přiblbé mapování jako na jedné IPv4 veřejné adrese 22->ip1:22, 222->ip2:22, 2222->ip3:22, atd.

Jako běžný uživatel na mobilu nechcete otevřený příchozí provoz. Všudypřítomný šum internetu, který síť neustále doručuje na váš mobil dost výrazně vybíjí baterii. Shodou okolností mám jednu SIM kartu s veřejnou IPv4 adresou bez filtrace a nedá se to kvůli tomu používat :). Dokonce nestačí vypnout mobilní data, je třeba zapnout režim letadlo.

Není pravda, že je to stejné jako na IPv4, díky absenci NATu je možné stavový firewall na IPv6 triviálně otevřít, takže třeba dvě instance Tailscale běžící na dvou různých mobilech se okamžitě bez problému spojí napřímo. V případě CGN to není úplně jisté, záleží na spoustě faktorů a vyžaduje to výrazně vyšší úsilí.

Tak ta adresa 2a00:102a:401­1:47de:... je globílně routovatelná adresa. :-)
Že se na ty adresy nejde spojit je dáno tím, že předřečník asi používá v mobilu APN "internet", tam je na straně O2 nastaven firewall, který blokuje příchozí spojení. Pokud by chtěl, aby se dalo spojit na ty adresy, tak O2 nabízí k použití APN jménem "internet.open", ale o jeho zpřístupnění je třeba zažádat a byl za to asi jednorázový poplatek. Jen nevím, zda na APN internet.open už je i IPv6 podpora.

Na akci padlo, že jiná APN než internet, tedy internet.open, internet.s a internet.open.s dosud IPv6 nepodporují. Zase na nich pravděpodobně stále fungují veřejné IPv4 adresy.

Aha, dík za info, tušil jsem, že IPv6 na ty další nedorazilo. Jak to vypadá v případně privátních firemních APN, tam asi také stále IPv4 only? :-(

A uz to chapu, ty myslis vylozene mobilni pripojeni, ne pevny internet od O2.

Má to více výhod - výstupní server v geolokaci, kde potřebujete. A nemusíte řešit NAT a veřejné adresy, aspoň pro vlastní zařízení (teda pokud je ta adresa krkolomná a mimo systém DNS). Jinak řečeno, když vám zrovna nepoběží veřejná IP ať už v4 nebo v6, tak to pro vlastní zařízení obsloužíte jinak (ideální když vše funguje přes fallback)...

Děkuji za potvrzení toho, co jsem už napsal: každý vidíme problém v něčem jiném.

Nejsem si jistý, že by udělat IPv6 slušně stálo v případě O2 peníze navíc. Ostatní to zvládli, tak proč ne O2?

Hm, chtělo by to tedy asi najít správný tým, který navrhne a realizuje projekt s nulovými náklady :-).

Ví to i Vodafone, ale nic moc s tím nedělají, protože zatím je to celé "good enough". Mimochodem stejný přístup je i v Německu, DOCSIS se prostě začíná rozkládat pod vlastním technologickým dluhem.

No jo. Pitomci. Ale bohatí pitomci.
Nebo na to jdou dobře?

Přesně víte, jak to bylo myšleno. Styl Vaší komunikace v tomto ohledu byste mohl zlepšit.
Když už v O2 zaváděli IPv6, mohli tam dát ten prefix /56 místo /64. T-Mobile a jiní to dokázali. Mám pocit, že spíše než nějaké technické omezení to bude "šetřivost" obchodního oddělení, aby se náhodou zákazníkovy nedalo něco, kde by už potom nešlo vyextrahovat další peníze za příplatkovou službu - třeba větší počet adres. Tohle je veřejné fórum, a klidně tady můžou lidi, co u toho byli napsat, že to třeba v té době technicky byla schůdnější varianta, protože třeba nějaký hardware neuměl dobře např. prefix delegation o té velikosti nebo něco.

Vodafone/ UPC na tom zase tak suprově nejsou. Výhled s tím, co předvádí není obecně tak růžový a to se netýká zdaleka jen IPv6 nebo DOCSIS. Třeba jen jednání zákaznické podpory je absolutně otřesné, nejsou schopni třeba na vyžádání zrušit přerušování hovoru z mobilu po hodině. Některá zařízení, která nabízí, nejsou stabilní při letních teplotách v běžném paneláku. Pravděpodobně přerušují delší TCP spojení dříve než po 2 hodinách 4 minutách, což je v rozporu s RFC a přerušuje např. dlouhá SSH sezení. (Nedostal jsem se k tomu, to měřit.) Podobný jev u jiných ISP se rozebíral tady: https://news.ycombinator.com/item?id=25737611
Od té doby, co jsem u T-Mobile na optice CETINu jsem přerušování nevnímal.

Cože, tohle dělají ??? Něco takového jsem, když jsem u nich byl, nikdy nezkoušel měřit, to by mně vážně nenapadlo že se to děje... výpadky jednou za čtvrt roku na den, dva to byla normálka. Ale tohle je ještě horší než by se dalo čekat, no!

Mně to přijde očekávané, naopak mě překvapilo, že to je tak dlouho, čekal bych pár minut.

Horší je, že se mi zdá, že omezují počet spojení. Když pustím "gsutil -m rsync -r", tak se podivně „rozbije internet“.

V režimu kabelového modemu "bridge", "IPv4 router" nebo "IPv6 router + DS-Lite router"?

V DS-Lite jsem experimentálně ověřil, že při pár stovkách spojení začne DS-Lite AFTR (router/NAT u operátora) další spojení odmítat: https://twitter.com/zajdee/status/1298152024102572032?s=20

V případě Compalu v režimu IPv4 router uživatelé reportují dost crappy chování, spojení se ztrácejí, rozpadají, ...
V případě Compalu v režimu bridge jsou zase omezené IPv6 tunely a další non-TCP/non-UDP protokoly (před časem o tom vyšel i článek tady na Rootu).

Tyhle povinná zařízení jsou spíš na zlost. Kvalitu kabelovky je jedno koncové zařízení úplně schopné zabít.

Asi DS-Lite, režim tam nejde nastavit (CH7465VF). Je to UPC instalované loni v létě a už dávali pouze toto. Zkusím si vypnout precedenci IPv4 a třeba to celkově bude lepší.

Prosím zkuste měření z https://anderstrier.dk/2021/01/11/my-isp-is-killing-my-idle-ssh-sessions-yours-might-be-too/ ať se můžeme podívat na současný stav. :-)
Přímo nástroj je dostupný zde:
https://github.com/AndersTrier/NAT-TCP-test

Mám pocit, že spíše než nějaké technické omezení to bude "šetřivost" obchodního oddělení, aby se náhodou zákazníkovy nedalo něco, kde by už potom nešlo vyextrahovat další peníze za příplatkovou službu - třeba větší počet adres.

Vidíte, já takový přístup považuji legitimní a jeden ze "zdravých" přístupů. Řeší to konkurenční prostředí. Smůla je, že IPv6 zákazník s přípojkou obvykle neocení. V lepším případě je mu jedno, v horším případě znamená zhoršení služby. Ze strany ISP to znamená vyšší složitost při hledání příčin hlášených incidentů. Každý problém musíte ověřovat dvěma cestami a výsledky se často liší. Proto nesouhlasím s tím, že by to nebylo pro ISP dražší. Bylo. Aby zavedl IPv6 musí tyto nevýhody vyrovnat nějaký přínos.

Co se týče srovnání kvalit ISP, tam má náš obor obrovské mezery. Ani odborníci se neshodnou na tom, co by měla standardní přípojka splňovat, aby se jí dalo říkat "internetová přípojka". RFC někdy pomohou, ale jako každá norma, nejsou závazné. Dost často jsou dvě RFC neslučitelná (každé řeší jinou situaci) a často jsou neslučitelná RFC z různých roků (elektřinu doma taky nepřesekáváte, když vyjde nová norma).

Ale to je přece jasný.
1) Internet je síť sítí. Takže musí být možnost připojit se zvenčí -> veřejný adresy. Bez nich je to "připojení k síti poskytovatele" a ne "připojení k internetu"
2) Na internetu platí síťová neutralita. Obsah musí přípojkou projít bez ohledu na protokol, pokud je standardní -> TCP i UDP na IPv6 i IPv4, neblokovat žádný porty, pokud pro to není technický důvod. Pokud zákazník něco z toho nechce, ať si to zabije na routeru.
3) V dnešní době je potřeba data přijímat i vysílat, takže rozdíl uplink / downlink max. 20% rychosti
4) V případě IPv6 je doporučení pro domácnost min. /56, pro firmu min. /48 a není technický důvod to nedodržet. Tím pádem není ani důvod, proč by to zákazník neměl požadovat.

Cokoliv jinýho není internet, ale nepoužitelná prasárna.

@Petr M

...a pak narazíte na realitu. ISP řekne "bez problémů, tady je cenovka". Ta cenovka bude taková, že se raději znovu zvážíte tu "nepoužitelnou prasárnu", protože je z 80 % použitelná, ale za 20 % ceny.

Pozor, znovu upozorňuju na neúplnost bodu 2 - připojení musí přenášet právě protokol IP (teď neřeším, zda 4 nebo 6) bez ohledu na obsah užitečných dat, tzn. nejen TCP a UDP! Tj. např. protokol 41 tak, jak to umí např. CETIN.

Nedomyšlené do praxe
Napříkald?

nevymyšlené přechodové cesty
https://en.wikipedia.org/wiki/IPv6_transition_mechanism

nevymyšlený způsob souběhu
IPv4 a IPv6 vedle sebe normálně funguje, v zařízeních i sítích.

Výsledek je, že se na to těší jen ISP.
Aha, a proto to ISP nejvíc brzdí.

Po dvaceti letech považujeme za úspěch, že se jednomu jedinému významnému poskytovateli obsahu (Facebook) podařilo přejí v rámci vnitřní infrastruktury na v6-only.
To, že vy jste se teď dozvěděl o jedné věci, neznamená, že se ta věc stala teď a že je jediná.

Za tu dobu se vyměnilo několik generací hardwaru, že by se dávno vyplatil protokol, který by nativně podporoval společné směrování a přechod pro v4. Mohli jsme být dál.
Mělo by to jeden drobný zádrhel – nefungovalo by to.

Mělo by to jeden drobný zádrhel – nefungovalo by to.

Proč by nemělo? Ano, pokud berete současné IPv6 jako jediné možné řešení, tak by to opravdu nefungovalo. Navrhnout protokol, který by stavěl na IPv4 ale rozšiřoval ho o další 96 bitů, které by mohly, ale nemusely suplovat přesměrování portů by šlo a bylo by zavedené rychle. Stejné rozšíření by ale mohlo v nativní síti fungovat bez obezličky natu.

Tedy např. situace: chci se dostat na stroj 10.0.0.1 schovaný za adresou 195.84.63.21, tcp/80 na IPv4 mapovaný na port tcp/8888.

Takový souběžný protokol by nakrásně mohl adresovat:

195.84.63.21.10­.0.0.1 tcp/8888.80

Všechna zařízení, která by tento nový protokol podporovala, by předávala tuto informaci. Až poslední, které by už hraničilo s legacy IPv4 by odřízlo tu rozšířenou část a holt by se jelo "po staru". Tak, jak by se u poskytovatelů vyměňovaly zařízení, ta cesta, po které by se plná informace šířila, by se rozrůstala, aniž by si toho někdo všiml. Až jednoho dne bychom zjistili, že ořez na tradiční IPv4 nastává už jen u malého procenta zařízení, až by úplně zanikl.

Takovou interpretaci by mohla zajišťovat i L2 zařízení (switche nebo vložené prvky zajišťující toto rozšíření - např. pro standalone legacy gadgety).

Pochopitelně jsem to vypsal jen velmi zjednodušeně, v praxi by bylo potřeba interpretaci adres udělat tak, aby následně umožnila přechod na smysluplnější prefixování a směrování, což by šlo. Chci tím jen ukázat, jak by zhruba vypadat přemýšlení o přechodové cestě.

A nedělá v podstatě toto 6to4 (ve WAN ) / 6over4 (v LAN)? :-) Ale minimálně 6to4 dojel na dostupnosti bran z nativného IPv6 světa a nedostupnosti aspoň jedné IPv4 adresy u koncáků... Teredo také cesta, ale ta spolehlivost. :-(

@M_D

Měl to být základní stavební kámen a ohled měl být prán právě na ten snadný přechod. IPv6 na to šlo opačně. Navrhlo se velkoryse a teprve následně se řešil omezený přechod.

Navíc směrování prefixů je na IPv4 nezávislé. To je technická výhoda, ale v praxi to přináší problémy. Z dual stack stroje Vám jedno spojení jde úplně jinou cestou než druhé. Žádný vyšší protokol to nikdy nedá do kupy, pokud si spojení ještě neoznačí na aplikační úrovni...

Skoro bych řekl, kdo chtěl víc, nemá nic. Naštěstí se IPv6 nakonec uchytává, díky síle pár statečných hráčů, ale bylo to tak tak.

Proč by nemělo?
Protože jste to nedomyslel.

Ano, pokud berete současné IPv6 jako jediné možné řešení, tak by to opravdu nefungovalo.
Ne, já neberu současné IPv6 jako jediné možné řešení. Je spousta daleko horších – jedno z nich jste vy popsal.

Navrhnout protokol, který by stavěl na IPv4 ale rozšiřoval ho o další 96 bitů, které by mohly, ale nemusely suplovat přesměrování portů by šlo a bylo by zavedené rychle.
Navrhnout by to šlo. Zavedené by to nebylo vůbec, natož rychle – protože by těm, kteří by se nad tím zamysleli, došlo, že by to nefungovalo.

Až poslední, které by už hraničilo s legacy IPv4 by odřízlo tu rozšířenou část a holt by se jelo "po staru".
Takže by to postaru dorazilo na IP adresu 195.84.63.21 na port 8888, kde by žádný server nenaslouchal a zařízení by odpovědělo port unreachable. Ne, ten příklad jste hodně nedomyslel – pokud mají zařízení komunikovat novým protokolem, musí ho umět zařízení na obou koncích.