Co pořád máte s tou IPv6? Jenom sebevrah připojí každé své lokální zařízení přímo na WAN. Bez NAT, hw firewallu či alternativy to nikdo svéprávný neudělá.
Pamatuji, že jsem někdy před mileniem pročítal nějaké texty(už si nepamatuji kde, které) a v nich se počítalo, že IPv6 bude hlavně pro nové oblasti (Asie, Afrika) a že starý svět pojede na IPv4.
Hlavně když IPv6 nic nového kromě množství IP adres nic nepřináší. V těch rozvíjejíchc světových světadílech se počítalo s velkým množstvím IP.
PS. připomínám fakt, že pokud vám doma skončí IPv4 všechna starší zařízení smartTV, VoiP telefony, sítové tiskárny, tablety, web kamery, set-top-boxy, satelity DVT-S, apod.. které nepodporují IPv6 můžete vyhodit. Tedy za předpokladu, že nebudete mít nějaký router který bude podporovat paralelně oba protokoly najednou v rámci vaší LAN ale kdoví jak to bude pak s překladem požadavku z IPv4 na IPv6 do WAN.
A to ani nemluvím o tom, že 60% populace ČR vůbec netuší že něco jako IP existuje.
Nedostatek adres trápí především provozovatele služeb. Adresy jsou příplatková služba a bude se to zhoršovat – za poslední dva roky vyletěla cena na burzách na dvojnásobek. Přitom velká většina infrastruktury je na IPv6 dávno připravena a stojí to na uživatelích. Jakmile uživatelé budou schopni přistupovat ke službám po IPv6, může se čtyřka zahodit a všichni si oddechnou, protože ke své službě dostanou libovolný počet adres. Tak už je to dnes, ale bez čtyřky se ještě pro uživatele fungovat nedá.
Třeba Facebook se rád chlubí tím, že ve svých datacentrech už vůbec IPv4 nemá a překládá do ní jen na okraji sítě pro uživatele, kteří přijdou právě po čtyřce. Podobně to můžete zařídit třeba s CloudFlare – vaše služba běží kompletně na šestce a pro čtyřkové uživatele máte CDN, která umí oba protokoly.
Trapi to nove potencionalni poskytovatele sluzeb, ti soucasni uz IP adresy maji a radi se s nimi za priplatek podeli. Jedinou nasilnou moznost, jak prejit na IPv6 je zdrazit registraci IPv4 natolik, ze se to nevyplati a i tak si myslim, ze dokud to pujde, tak se bude prechazet na (CG)NAT.
Druha vec je, ze treba prejitim na IPv6 u nekterych poskytovatelu ztratite moznost mit verejnou IPv4, takze proc by to nekdo delal ?
8. 6. 2021, 12:00 editováno autorem komentáře
Myslím, že je to taková domněnka, že IPv4 adresy velcí poskytovatelé mají a mají jich dostatek. Ano, mají jich dostatek, protože překotně adresy skupují, ale tempem, jakým se adresy konzumují ani to skupování není udržitelná strategie.
Třeba AWS má přes 100 milionů IPv4 adres a tu a tam přikoupí několik dalších milionů. To se rozebíralo např. zde: https://news.ycombinator.com/item?id=24839887
Faktem je, že právě Amazon IPv6 postupně zavádí na více a více službách. Kdyby o to nebyl zájem/ kdyby to nepotřebovali, tak by to nedělali - zrovna Amazon je silně zaměřený na to, co zákazníci vyžadují a jsou za to ochotní platit/ kvůli tomu službu používat.
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.
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...
No a to je jedna z nejčastějších chybných domněnek pramenících v 20 let zastaralých představách o počítačových sítích. Je totiž jaksi potřeba ustoupit z původní představy, že má vnitřní síť je bezpečné hradní nádvoří a všichni ti škaredí a zlí útočníci jsou někde na druhé straně hradního příkopu.
Útoky mohou totiž snadno přicházet zevnitř sítě. A nemusí to být nutně přímo útočník, který se napojil přes WiFi, bohatě stačí přinést si domů zavirovaný mobil.
Zabezpečit je potřeba každé připojené zařízení a nespoléhat se jen na jeden hraniční firewall.
Jenomže on má do jisté míry pravdu. Drtivé většině koncových uživatelů to skutečně je naprosto jedno. A NAT si stejně vyrobím už prostě proto, abych měl za firewallem (tedy za jednou zafirewallovanou gateway) celou síť, kde běží spoustu dalších služeb, nad jejich zabezpečením nemám vůbec žádnou kontrolu. O ten NAT jako takový přílši nejde.
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í.
Že to bez překladu bude jednodušší a přehlednější atokonto opravdu není pravda. To platí pouze pokud potřebujete nějakou speciální konfiguraci. Jenomže to většinu lidí fakt nezajímá. Hřebík, kladivo, hotovo. Stačí.
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.
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?
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.
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.
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...
> 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.
blbosť a NAT vždy bude potrebný,... už z princípu ako sieť funguje nemôže byť každé zariadenie pripojené na WAN. Neviem si predstaviť tlačiareň pripojenú do WAN a hocikto na nete by mi tlačil doma papiere, a firewall? To není úplne to isté a ani by v tomto nepomohlo... potrebuješ mať izolovanú (vnútornú) sieť v ktorej budú mať zariadenie prístup k iným zariadeniam v rámci tejto siete, ale nikto z WAN nebude mať prístup k zariadenia v tejto vnútornej siete, a to je čo NAT robí a veľmi dobre. Firewall je dobrá vec, ale toto nevyrieši, lebo v rámci vnútornej siete môžu pribúdať aj ubúdať zariadenia v čase sa rôznak pripájať, a teraz si predstav prekonfigurovávať firewall pre každé zariadenie zvlášť... to by sme dopadli. NAT toto perfektne rieši. Ono NAT a firewall riešia sieť z opačných koncov a dosť odlišne.
8. 6. 2021, 15:57 editováno autorem komentáře
„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?
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á.
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.
@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šině koncových uživatelů to skutečně je naprosto jedno."
Jo, stejně jako jestli pošťačka přiveze dopis autem nebo na kole. Ale musí ten dopis dojít.
Když kamarád brečel do telefonu, že nemůže pařit onlajnovku a zjistilo se, že herní server zvládne max. čtyři připojení z jedné IP adresy a on je za CGNATem... Nebo když kvůli jednomu zavirovanýmu komplu za pěti NATy nejdede nějaká služba půlce okresu. Nebo když vypadl server Amazonu a kamarád si nemohl rozsvítit na WC, protože bez čmoudu se nepřipojil vypínač ke světlu. Tak to jsou přesně situace, kdy užitečnosti NATu velmi silně pochybuju.
Nebo když vypadl server Amazonu a kamarád si nemohl rozsvítit na WC, protože bez čmoudu se nepřipojil vypínač ke světlu.
Něco mi říká, že by pravděpodobně to samé nastalo, i kdyby ten krám komunikoval přes IPv6. On totiž zmíněný přístup umožňuje parádní vendor lock-in a šmírování spousty dat a nezdá se mi, že by si to někdo jako Amazon nechal ujít.
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/zigbee/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í.
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/toggle/edge/ignore).
> 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+asistentami (Google Assistant/Alexa/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).
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).
NAT není totéž co firewall.
NAT byl určen původně na něco zcela jiného, než je jeho dnešní implementace na SOHO zařízeních.
IPv6 se naopak snaží vyřešit mraky problémů, které přinesl právě NAT a jeho současné nasazení. Jenže nastal druhý problém, operátoři prostě poředpokládají, že máte v SOHO přesně asi jedno zařízení, což je bohužel také hodně špatně.
Pto koncového uživatele je NAT stejně nepochopitelný jako firewall. Ani jedno nepoužívají a ani nevědí, že něco takového existuje. Koncoví uživatelé chtějí přístup na internet (myšleno web) a to je vše, nedělají žádnou "černou magii" s přesměrováváním portů, nastavování pravidel provozu, a podobně. Jednak nevědí, co to je, a druhak je to uráží.
Jistě, je to pochopitelnější, ale jen proto, že to znají, používají a ví, že to funguje, tedy nebojí se toho. V tom je celé jádro pudla. Jsem si vcelku jistý, že kdyby IPv6 znamenalo "jen víc adres a jiný formát adresy", tak by s jeho zavedením nebyl jediný problém.
Jenže celý problém s nasazením IPv6 u koncových uživatelů podle mě selhává ani ne tak na technice, jako spíš na faktu že neexistuje jednoduchý způsob, jak ten přechod z IPv4 udělat. Opakování faktu, že "je to moderní, do budoucna nutné" tomu nepomůže, dokud budou návody mnohem delší a s dovětkem, že se to stejně bude způsobovat problémy. Vážně.
Dohledávat informace k tomu, jak IPv6 vlastně funguje je nervy drásající proces: oproti IPv4, kde je cesta vcelku přímočará (mnohokráte a na mnoha místech popsaná) a pro spoustu lidí snadno uchopitelná (protože ji znají a používají), tak se tady dozvíte především co kde nefunguje, že je to všechno jinak atd. ale že by existoval nějaký návod, podle kterého by si mohli během deseti minut nastavit ten či onen domácí router? Nejsou.
Jsem zvědav, kdy se najde odborník, který si lajzne vytvořit pro většinu uživatelů srozumitelný návod, který nebude prošpikovaný technikáliemi, které koncové uživatele nezajímají. A i když třeba nebude tak obecný a do detailu přesný, bude použitelný. Můj tip je spíš nikdy, protože by byl okamžitě v diskuzi roztrhán na cucky za nedostatečnou technickou úroveň návodu. A tak se zase holt nehneme z místa.
Měl by to udělat výrobce zařízení. Ostatně, má povinnost dodat k zařízení návod k použití ze zákona. Nic mu nebrání napsat dva odstavečky o tom, co je modul zač, na co se používá,... A může to být i marketingový trik, že možnost se něco naučit bude motivovat lidi i ke koupi výrobku, se kterým se dostanou k vědomostem a zvládnou to sami.
A pokud jde o princip srozumitelně a do hloubky, co knížka o IPv6 od Pavla Satrapy? https://www.root.cz/knihy/internetovy-protokol-ipv6/
V čem je pochopitelnější?
IPv6: Na večírek pro býložravce přijde krokodýl. Nechci tem krokodýla, nepustím tam krokodýla.
IPv4: Na večírek přijde krokodýl, ale převleče se v šatně za zebru. Nechci tam krokodýla, ale mám vyhodit krokodýla, nebo zebru? Zastavuju je před, nebo za šatnou? A proč se vlastně převlíká?
IPv4: Na večírek přijde krokodýl, ale převleče se v šatně za zebru. Nechci tam krokodýla, ale mám vyhodit krokodýla, nebo zebru? Zastavuju je před, nebo za šatnou? A proč se vlastně převlíká?
Nerozumím, jak je myšleno to převlečení krokodýla za zebru. Jako že na server se službou NAT přijde z WAN podstrčená odpověď na žádost některého stroje z LAN a ta je předána tomu stroji? Nebo že na NAT z WAN přijde žádost, která je podle pravidla přeložena a poslána některému stroji do LAN?
Není lepší NAT přirovnávat k podatelně či telefonní ústředně v podniku?
IPv4: Na večírek přijde krokodýl, ale převleče se v šatně za zebru. Nechci tam krokodýla, ale mám vyhodit krokodýla, nebo zebru? Zastavuju je před, nebo za šatnou? A proč se vlastně převlíká?
Keby sme aspom tusili ako NAT funguje, vsak. ;)
Ked uz to mame nejako napasovat na zvieratka, tak skor takto:
Zebra ani krokodyl a ine zvieratka nejazdia na vylet kazdy vlastnou karou ale spolocne nasadnu do kary spz ZOO. Takto jazdia hore dole, nikto s tym nema problem. Iba ak filzi po ceste, pretoze vidia len spz ZOO, ale netusia kto konkretne sa vezie. Tak je to dobre a tak to ma byt ;)
9. 6. 2021, 21:20 editováno autorem komentáře
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? ;)
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...
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 ;)
Firewall vám nic neřiká? Přece žádné zařízení by němělo být jentak připojené do internetu bez FW a IDS.
A na druhou stranu u jednoúčelových triviálních gadgetů typu IoT je to fuk, ty mají stejně třeba jen jeden port a pokud mají korektně nastavené šifrování, není šance to nějak narušit (kromě DDOS). A pokud nemusí komunikovat navenek, tak vždy postačí je nechat fungovat na privátní síti v rámci svého serveru, čímž se to řeší.
Navíc z článku docela jasně vyplývá, že funguje už i NAT64, takže se ta privátní síť pak může připojit přes nějaké zařízení nebo ten server ven a s pořádným firewallem.
Rovnou říkám, že na toto nejsem odborník, ale výrazy typu sebevrah opravdu nechápu... v domácnosti mám poměrně dost připojených zařízení, a jsem si skoro jist, že všechna už dávno umí Ipv6 (od mobilů přes pc až po STB)... a pokud neumí, bude to 15 let stará plečka, které se rád zbavím (myslím třeba síťová tiskárna nebo nějaký wifi repeater). U té tiskárny jde stejně tisknout i lokálně přes USB (případně to elegantně řešit přes wifi router s USB portem).
Mé servery bez problému poběží na IPv6 i třeba na "IPv10", právě kvůli používání getaddrinfo, což ve srovnání s původním způsobem vyplňování sockaddr je ohromná úleva.
Nicméně u IPv6 mám pořát pocit, že je tam hodně věcí nedodělaných, které brání finálnímu nasazení.
Co mám našemu ISP poradit (soused a správce našeho sdružení), aby v síti začalo chodit IPv6? Co mám nastavit na routeru, aby začal propouštět IPv6. Mám rok starý router od ASUS a IPv6 se tam nikde nevyskytuje. Zato tam je hromada nějakých cloudových aplikací, které nikdy nevyužiju
Já to třeba rozjel s tunelem od Vpsfree.
Vše funkční, až na ty služby, co funkční nejsou. Na Netflix se nedostanu, zřejmě má dojem, že dělá Vpsfree tunel pro lidi (což je přesně to, co dělá) a že se tím nejspíš obchází místní restrictions, takže to prostě nepustí. Občas problém s náhodným webem, ne všude to debuguji, ale bude to podobné.
Nemám DHCP, takže nevím, které PC si vyžádalo jakou adresu. To abych je obcházel a opisoval IP? Nebo jak toto řešíte? Mám MikroTik. Potřebuji povolovat na FW porty, ale neznalostí interní adresace jsem dost ztracen.
Já potřebu IPv6 chápu, ale také mě dost bolí.
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/ipv6/. Technicky vzato openVPN to podporuje a wireguard taktéž, nevidím problém...
Řešil jsem něco podobného. Mám ISP který oficiálně podporuje IPv6 ale dává /64 adres, k tomu Mikrotik který neumí ND proxy. Takže používám IPv6 tunel brokera a pro Netflix jsem někde v Kalifornii. Jako rovnák na obejbák jsem použil statické AAAA záznamy na DNSku kdy pro regexp Neflix domény vracím IPv6 na kterou mám FW6 pravidlo, které pošle "Reject". Netflix udělá fallback na IPv4 a funguje. Není vidět žádné zpoždění pro fallback.
Stavové DHCPv6 je nepovinná položka, takže jej řada zařízení nepodporuje a podporuje jen povinné SLAAC, která zajistí přidělení stejné IPv6 adreys v rámci LAN také, takže pro příchozí provoz je dostupná pevně daná IPv6 adresa (daná prefixem sítě a MAC adresou), pro odchozí spojení ale většinou se používá nějaké náhodná IPv6 adresa (privacy extension, pokud jej nevypnu).
> Co mám našemu ISP poradit (soused a správce našeho sdružení), aby v síti začalo chodit IPv6?
Jestli chce někdy připojovat školy, které budou na připojení pobírat dotace, měl by mít IPv6. Viz např. https://www.standardkonektivity.cz
Co by měl udělat?
No právě. Základní problém ISP podle mých zkušeností není nepodpora kvůli technické zastaralosti prvků. Ty už musel vyměnit dávno, aby rozumně zvládal větší počet zákazníků. Hlavním nedostatkem je velký znalostní dluh v oblasti IPv6. Technici ISP čekají, že se to bude chovat stejně nebo hodně podobně jako čtyřka. Nemají většinou potřebný rozhled, aby věděli, jak to dělat správně. Takže se radši nikdo do ničeho nepouští. Přece jenom jim doteď stačily skoro padesát let staré znalosti, které se příliš neměnily (beru začátek IPv4 jako rok 1975). Akorát tam v podstatě přibyl NAT v roce 1998, jinak až na drobnosti je to pořád totéž.
Ano. Ale na ty techniky zároveň ani neexistuje tlak od jejich zaměstnavatele protože na toho neexistuje příliš tlak od zákazníků. Protože většině z nich je to naprosto jedno. Ostatně mně je taky úplně jedno, jestli budu za jedním NATem nebo třemi. Co potřebuji si stejně proženu přes VPN z VPS do lokální sítě za NATem a firewallem. A jestli pod tím poběží IPX, IPv4 nebo IPv6 mě fakt nezajímá. A to skutečně nepařím mezi BFU, co potřebují maximálně tak aby se z prohlížeče dostali na internet.
Samozřejmě jsou především firemní zákazníci, pro které to podstatné je, Kvůli těm se to přeci jen někam pomalu posouvá, ale na jakýkoliv rychlejší postup je jich prostě příliš málo.
A jak si představujete to "rozvedení po sousedech"? Při počtu desítek domácností klidně můžete koupit službu od normálního ISP, nechat si přidělit blok /48 a z něj rozdávat /56 každé domácnosti. Zabezpečení, přidělování adres, routování, stejně musíte řešit.
Ale jestli myslíte "přeprodej jedné linky pro domácnost za šest stovek mezi sousedy v činžáku", tak to je určitě jednodušší, než navrhovaný plán, i když i v extrémním případě jednoho velkého L2 subnetu budete mít v LAN automaticky IPv6.
Ptal jste se nicméně na ISP, ne na přeprodejce, který porušuje zákon o elektronických komunikacích, živnostenský zákon a/nebo podmínky služby skutečného ISP (zákaz přeprodeje).
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
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árna/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í.
Některé mobily s Androidem mají ve výchozím nastavení APN "internet" v režimu dual-stack. Pak skutečně není potřeba nic nastavovat. Většina ale bude ve výchozím operátorském nastavení, kde je pouze režim IPv4 (https://twitter.com/zajdee/status/1386939934716616706?s=20).
V iOS je výchozí podpora pro dual-stack až od iOS 14.5 a jen pro iPhone. Předchozí verze systému měly v operátorském profilu povoleno pouze IPv4 (https://twitter.com/zajdee/status/1386930736389840899?s=20).
8. 6. 2021, 11:29 editováno autorem komentáře
Přiznám se, že nerozumím, jakou venkovní adresu myslíte. Zkusím to celé znovu popsat.
Na mobilu mám od O2 přidělenu IPv4 adresu 10.x.y.z, ta se samozřejmě NATuje, takže třeba www.mojeip.cz vidí 37.188...., což je jedna z řady veřejných IPv4, na kterou O2 překládá.
Pak mám přidělenu veřejnou IPv6 adresu 2a00:102a:4011:47de:... a tu vidím i na www.mojeip.cz... Adresa je sice veřejná, ale standardně za firewallem a není dovoleno se zvenku na ni připojit (resp. jsem zkoušel jen pingnout, nevím, jestli případně otevřené porty na mobilu jsou přístupné).
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.
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:4011: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.
Tak tohle musím vyzkoušet, mám v šuplíku občasně používanou Datamanii a tohle by byl důvod proč to začít přednostně používat... Prozatím mi totiž v pohodě stačí Kaktus, kde se člověk dostane na podstatně menší platby za data, pokud teda nepotřebuje extra měsíční objem ;)
Tak to jen na okraj k tématu.
Používání IPv4 je v poslední době děsné peklo, hlavně jak se rozmáhá CGNAT. Někdo má na počítači malware, který buď sám nebo jako součást botnetu útočí na jiné stroje, na základě toho pak servery přímo nebo přes blacklisty danou adresu blokují. To odnesou všichni, kdo jsou schováni za stejnou veřejnou adresou jako ten nakažený počítač, přestože sami nic neudělali.
Kdo si myslí, že k ničemu IPv6 nepotřebuje, tak obvykle potřebuje, jen to ještě neví. Pokud nemá vlastní pevnou veřejnou adresu IPv4, platí odstavec výše. A pokud ji zatím má, tak ji brzy mít už nemusí, případně za ni bude platit čím dál víc.
Ceterum autem censeo IPv4 esse delendam.
Pouzivani IPv4 pro lidi, co maji verejnou a vicemene statickou IP adresu (moc se to nemeni, proc taky), pro ty to zadne peklo neni. Pro ty, co si plati i statickou, tak pro ty uz to vubec zadne peklo neni. Peklo to je pro ty, co ji nemaji a duvod proc se to u nas moc neposunuje je ten, ze to zase takove peklo, jak tvrdis, neni.
Kdyby to bylo takove peklo (pro koncove uzivatele), tak uz jsme davno na vyssich procentech IPv6, asi holt maji nasi poskytovatele adres dostatek a ti co ne, tak ti radi daji IPv6.
Za me je naopak u UPC peklo prechod na IPv6, protoze ti za a) vezmou verejnou IPv4 adresu a za b) nenechaji te pouzit jejich router jako bridge ... jako ne, ze bych to asi nejak zvlast potreboval no - tu verejnou IPv4, ale ten jejich router je docela bida...a IP ban, tak ten prijde pravdepodobneji na sluzbe, co bezi pres IPv4, takze naopak tim, ze si u UPC prejdes na IPv6, tak to je potencialne vetsi problem.
Pro ty, co si plati i statickou, tak pro ty uz to vubec zadne peklo neni. Peklo to je pro ty, co ji nemaji a duvod proc se to u nas moc neposunuje je ten, ze to zase takove peklo, jak tvrdis, neni.
Což o to, doma ji mám - ale jen jednu, takže ne že by nebylo co zlepšovat. Jenže když vyrazím kamkoli jinam, ať už je to někde v hotelu, v nákupním centru, na letišti nebo koneckonců třeba v práci, tak tam nemám veřejnou adresu skoro nikde. Samozřejmě jsem se s tím naučil žít a omezení z toho vyplývající různě obcházet, ale to neznamená, že to není problém a že to nikomu nevadí.
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)...
Ale tohle je jenom blbost UPC/Vodafone, že to neumí udělat pořádně. (
(...) Nevím proč se u nás vždy objeví nějaký exoti, co dokáží zmastit to co normálně všude jinde funguje viz O2 a UPC.
Technici 100% vědí a věděli, že se jedná o hloupě kompromisní řešení. Ale firma tu není od toho, aby dělala radost technikům, ale aby vydělávala. Takže se spočítají náklady variant a) zůstat na IPv4, b) udělat blbou IPv6 a c) udělat IPv6 pořádně. Vyhraje to, co má nejvyšší šanci na komerční úspěch. Takové řešení je současně i nejlevnější pro zákazníka, byť si technici malují vzdušné zámky o tom, jak by byl svět růžovější, kdyby všichni přešli na IPv6.
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?
U Vodafone resp. celého DOCSIS je problém, že to je obskurní technologie, kde je typicky příšerný firmware a kvalita je tam neznámé slovo. Tam se samozřejmě věci dělají "správně" blbě, protože problém je především ten firmware, kde prostě není potřebná volba nebo má bugy. Tam tedy udělat IPv6 pořádně obsahuje i vyžadovat kvalitní firmware a to je běh na dlouhou trať i kdyby byl zájem to posunout.
Dlouhodobě jsem si na 100% jistý, že DOCSIS je mrtvá technologie, takže jakékoliv investice do této infrastruktury jsou v podstatě vyhozené peníze. 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.
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.
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.
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.
Nejvetsi problem u IPv6 je ten, ze vsechny ty domaci blbiny, pro ktere by to puvodne melo byt idealni, tak jej nakonec vubec nepotrebuji. Tam staci nejaky mini"server" doma, ktery to vsechno ovlada a je potreba se dostat jen na nej.
To, ze nekdo nema verejnou IP je ale strasne vyhodne pro poskytovatele techto chytrych reseni, protoze ti udelaji vlastni verejny server, ktery ale slouzi jenom proto, aby se pripojil na ten miniserver uvnitr insfrastuktury a nasel jej (dostal se za NAT). To ale znamena, ze pak musite mit vsechno od te stejne firmy nebo nemusite, ale vetsina lidi a mozna i vetsina lidi tady uz se ve vecech nechce zase tak moc stourat, ale potrebuje, aby fungovaly.
Pak je tu jeste ta "bezpecnost", hele mas IPv4, domaci zarizeni za NATem a pravdepodobne i firewallem, prece bys to nechtel mit na IPv6, aby ti nekdo rozsvicoval a zapinal pracku ...
A podle me nejvetsi chyba, ktera se stala, byl velmi pozdni prichod NAT6to4(nebo 4to6?), proste ted doma bezim na privatni IPv4, jenze proc bych nemohl bezet na IPv6 nebo aspon ji mit zapnutou a hezky by se mi to mapovalo na IPv4 verejnou adresu. Ja vim, ze uz toto existuje, ale podpora je zalostna, zvlast na routrech od poskytovatele. Jasne je to hack, ktery u IPv6 neni potreba. Ale takhle by proste domacnosti presly na IPv6, pribyla by spousta testovacich zarizeni a pak by se to proste preplo jednoduse zmenou prefixu, hotovo.
Přesně tak. To jsou zákony trhu - nikoliv zákony techniky. Uživatelé z nějaké části cloud nebo domácí mini servery používají z donucení, vzdáleně by se dalo říct, že s IPv6 by tato zařízení ani nevznikla. Na druhou stranu, lidé taky přišli cloudovým a hybridním službám na chuť. I dřívější zarputilí odpůrci cloudu, co jsem znal, to dnes přijímají, a berou jako výhodu to, že doma nemusejí mít velké krabice s mnoha závislostmi.
6to4 podle mě nejde dost daleko. Úplně se zapomnělo od počátku vymyslet takové řešení, které by umělo transparentně provozovat služby na IPv4 a IPv6 konektivitě současně, aniž by se o to uživatel musel zajímat. Aby uživatel mohl do stejné sítě připojit IPv4 a IPv6 zařízení, a technologie se postarala o to, aby si toho starší zařízení ani nevšimlo. To šlo řešit více způsoby. Jenže ti, co nový standard navrhovali, nechtěli dělat kompromisy hned od počátku. Stejně jsme jich museli udělat hodně, jen nás to zdrželo.
Jak kteří. Já jsem třeba stále nepochopil, k čemu by mi cloud měl vlastně být přesně dobrý. Jakkoliv proti němu obecně nic nemám. Ten cca milion souborů co k práci používám přes něj stejně nějak rozumně snadno nesesynchronizuji protože na to už je lepší a hlavně spolehlivější starý dobrý rsync a na zbytek cloud fakt nepotřebuji.
Totéž platí pro zálohování, pro fotografie, pro cokoliv.
Uplne transparentni reseni nikdo nevymyslel nejspis proto, ze to jednoduse nejde. Vzdycky tam musi byt "neco mezi", protoze IPv4 se s IPv6 z principu domluvit nemuze. Pro spojeni IPv6->IPv4 se sice da IPv4 namapovat do IPv6 (klidne natvrdo bez hacku jako DNS64), ale porad se nekde musi vzit dalsi IPv4 adresa, ze ktery se to tomu cilovymu zarizeni posle. A to musi resit nejaka brana. Pro spojeni IPv4->IPv6 to takhle jednoduse nejde, protoze IPv6 se do IPv4 nevejde, takze jedine mit nejakou jeste slozitejsi branu, ktera by vytvarela dynamicky mapovani do nejakyho vyhrazenyho rozsahu. V mensim meritku by to fungovat mohlo. Ale porad zustava hlavni problem, kde ma tahle brana byt.
Presne na to dojelo 6to4. To je v zakladu genialni myslenka, ze kazdy s verejnou IPv4 adresou ma automaticky krasny velky rozsah IPv6. Jenze i to vyzaduje branu. Jednoduchou, nestavovou, ale byt tam musi. Nejspis v zajmu toho, aby to nebrzdili poskytovatele zpatecnici, se udelala anycast adresa 192.88.99.1, s tim ze kdyz ji nezridi muj poskytovatel, automaticky se pouzije nejaka jina. V praxi to dopadlo tak, ze branu nezridil temer nikdo a spolehlivost sla do haje, protoze se pouzivala brana klidne na druhym konci sveta, ktera mohla a nemusela fungovat. K tomu asymetrie a absence kontroly odkud co tece a nemohlo to dopadnout jinak nez dopadlo (spatne). Spolehlivost by se byvala dala vyresit tim, ze by kazdej ISP mel povinne branu u sebe a poustel pres to jen svoje zakazniky. Plus idealne i routovani na IPv6 by vedelo, kde je ktera cast 6to4 rozsahu (i kdyz z toho by IPv6 routery uplne radost nemely). Jenze pak by se to zase nehlo z mista, protoze by to vetsina stejne neudelala, i kdyz ve srovnani s jakoukoliv jinou formou zavadeni IPv6 by to pro ne bylo naprosto primitivni.
Vzniklo by to aj s IPv6. BFU potrebuje BFU riesenie, co prave ponukaju tie cloudy alebo mini servery.
Bez toho by BFU musel riesit zabezpecenie siete/routra, co vobec nieje vec pre BFU. S cloudom je tato starost na pleciach prevadzkovatela cloudu.
BFU takto staci byt na interente(akomkolvek).
K tej druhej casti.
IPv6 nieje novy standard ale stary s kopou nedokonalosti(aj tu na rootu bol pred niekolkym rokmi serial o nedokonalostoach IPv6). Vznikol este pred rozmachom interetu internetu a tak to aj vyzera. Pomohlo tomu aj fakt, ze to bolo prisli akdemicky projekt, kde sa nebral dostatocny ohlad na sposob nasadenia/prechodu. Inzieri sa "vyradili" a zabudlo sa na prakticku stranku/realny svet.
Mne pride, ze IPv6 je riesenie z nudze cnost. Problem IPv4 sa zanedbal a potom sa narychlo zobralo IPv6 ako existujuce riesenie s dostatocnym poctom adries.
Pomohlo tomu aj fakt, ze to bolo prisli akdemicky projekt, kde sa nebral dostatocny ohlad na sposob nasadenia/prechodu.
Docela by mne zajímalo, kde se tenhle neustále dokola opakovaný nesmysl vlastně vzal.
Problem IPv4 sa zanedbal a potom sa narychlo zobralo IPv6 ako existujuce riesenie s dostatocnym poctom adries.
Naopak, jednou z hlavních motivací pro vznik IPv6 bylo právě to, že už na počátku 90. let bylo jasné, že adresní prostor IPv4 je nedostatečný a že i přes CIDR je jen otázkou času, kdy to začne být problém. A protože bylo zároveň jasné, že přechod nemůže být jednoduchý ani rychlý, přidalo se i řešení dalších problémů. Ale je pravda, že tehdy měl málokdo představu, jak moc se ten přechod potáhne a jaké míře pasivní i aktivní rezistence bude čelit.
@Michal Kubeček
Nevím proč se říká, že se jedná o akademický projekt, protože to správně není. Nicméně, když se člověk podívá na to, čím si IPv6 muselo projít a jaký je stav, tak si to opravdu nic nezadá s takovým akademickým projektem. Nedomyšlené do praxe, nevymyšlené přechodové cesty, nevymyšlený způsob souběhu (místo souběhu se řeší přechod 6-4, 4-6 et vice versa).
Výsledek je, že se na to těší jen ISP. 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. Jsme už tak otupělí, že si ani neklademe otázku, proč ta technologie neumožňuje posouvat hranici tohoto ostrova dál. FB si pevně drží přechod 4-6 ve svých rukou, protože si nemůže dovolit posouvat hranici přechodu dál. To kvůli tomu, že není zajištěno, že by v cizí síti došlo k přechodu správně.
To jsou hrubé koncepční nedostatky. Ano, byla teze, že všichni přejdou rychle a IPv6 se uchytí a převezme vedení. Proto byla navržena bez ústupků tehdejšímu stavu. Dnes se snažíme aspoň vykompenzovat dvacetiletý vývoj (ohejbáků pro) IPv4, aby byl přechod vůbec možný. Současně se však odhaluje, kolik je toho potřeba dodělat.
Světu, lidem, uživatelům je šum a fuk, jestli jsou na vině líní vendoři, kteří v6 celou dobu ignorovali a ne protokol samotný. Prostě to nefunguje dobře a tím úvaha končí. Už před dlouhými roky bylo jasné, že by bývalo bylo prospěšnější zavést technicky méně dobrý, ale pro přechod snadnější protokol. 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.
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ě.
@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.
Chci tím jen ukázat, jak by zhruba vypadat přemýšlení o přechodové cestě.
Vypadáte jako prvňáček, který přišel na Matfyz vykládat, jak může vypadat přemýšlení o číslech. Ona totiž o tom vašem nápadu spousta lidí přemýšlela alespoň trochu dál, než vy – a zjistili, že by to nefungovalo.
Jednak IPv6 nezvětšuje je velikost IP adresy, ale hlavně zvětšuje její síťovou část. Takže je možné nějak rozumně obsloužit daleko větší počet subjektů připojených k internetu. Ten váš „nápad“ totiž předpokládá, že každý zákazník ISP dostane jednu veřejnou IP adresu (aby mohli i zákazníci komunikovat mezi sebou). Jenže kdyby dnes bylo dost IPv4 adres na to, aby ISP mohl každému svému zákazníkovi přidělit jednu veřejnou IPv4 adresu, neřeší se všude problémy s NATem.
Dále jste zapomněl na to, že jakékoli smysluplné prefixování a routování vyžaduje, aby celá IP adresy byla na přesně daném místě v paketu, pokud možno celá a na začátku.
IPv6 bylo vymyšleno jako náhrada za IPv4, jehož základní předpoklad je „každé zařízení v internetu může přímo komunikovat s každým jiným zařízením v internetu“. Zvětšit adresní prostor IPv4 (to, o co jste se pokoušel vaším nápadem) by bylo možné za předpokladu, že by se od toho základního předpokladu upustilo a z IPv4 internetu by se stalo takové globální propojení VPN, které by tunelovalo nějaký jiný protokol. Tj. zařízení by zahájilo komunikaci IPv6 protokolem, paket by dorazil na nějaký hraniční bod, tam by se zabalil do IPv4, jako IPv4 by putoval IPv4 internetem, dorazil by na druhý hraniční bod, tam by se vybalil a dál by putoval zase jako IPv6. Takže by to bylo něco jako Tor nebo jako 6in4. Akorát už by to nikdy nešlo přepnout na nativní IPv6 a místo jednoho Internetu byste měl spoustu malých IPv6 internetů propojených jedním IPv4 internetem. No, a celé by to záviselo na tom, že ISP začnou klientům poskytovat ty brány mezi IPv6 a IPv4 – přičemž tady celou dobu tvrdíte, že ISP nemají k investicím do nových technologií žádný důvod.
@Filip Jirsák
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.
Ne, nemusí. Stačilo by, aby to zařízení umělo interpretovat oba případy. Statefull NAT, než se naváže spojení. Pokud se naváže na rozšířeném protokolu, může state klidně zahodit (pokud ho nepotřebuje k něčemu jinému).
Jednak IPv6 nezvětšuje je velikost IP adresy, ale hlavně zvětšuje její síťovou část. Takže je možné nějak rozumně obsloužit daleko větší počet subjektů připojených k internetu. Ten váš „nápad“ totiž předpokládá, že každý zákazník ISP dostane jednu veřejnou IP adresu (aby mohli i zákazníci komunikovat mezi sebou). Jenže kdyby dnes bylo dost IPv4 adres na to, aby ISP mohl každému svému zákazníkovi přidělit jednu veřejnou IPv4 adresu, neřeší se všude problémy s NATem.
Ano, místo toho si vysnili, že každý dostane prefix /64. Krásná myšlenka, na kterou si svět počkal dalších 20 let.
Dále jste zapomněl na to, že jakékoli smysluplné prefixování a routování vyžaduje, aby celá IP adresy byla na přesně daném místě v paketu, pokud možno celá a na začátku.
Stačilo by, aby z počátku nebylo prvních 64 bitů využívaných, a začít je používat pro to, co píšete, až by zařízení doběhly dobu, což by bylo rychleji, než sledujeme nyní.
Zvětšit adresní prostor IPv4 (to, o co jste se pokoušel vaším nápadem) by bylo možné za předpokladu, že by se od toho základního předpokladu upustilo a z IPv4 internetu by se stalo takové globální propojení VPN, které by tunelovalo nějaký jiný protokol.
Asi nechápete význam slov "přechodová cesta". Takže po lopatě. V první fázi by stačilo jen rozšířit prostor, ale stále směrovat postaru. Nové směrování a všechny výhody začít používat až ve chvíli, kdy by byla zcela přirozeně vyměněná většina zařízení.
No, a celé by to záviselo na tom, že ISP začnou klientům poskytovat ty brány mezi IPv6 a IPv4 – přičemž tady celou dobu tvrdíte, že ISP nemají k investicím do nových technologií žádný důvod.
Pokud by to byla v první fázi jen drop-in náhrada, nikdo by se toho moc nebál. Velice rychle by se pak dva peerující ISP dohodli, že oba už mají na hranici nové zařízení, a že by se jim z mnoha důvodů vyplatilo rozšířit konfiguraci o peering plných vlastností.
Jak by přibývaly směry s podporou, racionalizovalo by se i směrování prefixů, aby nebylo roztříštěné tak, jako na IPv4. Byl by to postupný proces, ale probíhal by hladčeji.
Rozhodně by to byla lepší cesta, než současný stav, kdy mnoho ISP má škatule, které umějí IPv6, ale pustit se do něj znamená celý okruh nových problémů, zcela nezávislých na problémech IPv4, kterých se tak jako tak zbavit nemohou. Spousta z nich má škatule s podporou IPv6, ale podle standardů, které za tu dobu stagnace zastarali. To nemotivuje.
Ale popsal jste úplně přesně tu chybu, kterou v návrhu IPv6 udělali. Ne technickou chybu, technicky tomu moc vytknout nelze. Ale obchodní - ekonomickou chybu. Škoda, že jsou technici tak přezíraví k realitě.
Ne, nemusí. Stačilo by, aby to zařízení umělo interpretovat oba případy. Statefull NAT, než se naváže spojení. Pokud se naváže na rozšířeném protokolu, může state klidně zahodit (pokud ho nepotřebuje k něčemu jinému).
Když chcete kritizovat IPv6, musel byste navrhnout nějaké lepší řešení. Ne podstatně horší a pak ho ještě pořád zhoršovat. IP protokol přenáší pakety, není tam žádný stav. Ten se řeší až na vyšších vrstvách. Navíc tvrdíte, že problém je, že ISP nechtějí investovat do IPv6, a sám navrhujete řešení, které by záviselo na investici ISP do zařízení, které by bylo řádově složitější, než dnešní NAT.
Stačilo by, aby z počátku nebylo prvních 64 bitů využívaných, a začít je používat pro to, co píšete, až by zařízení doběhly dobu, což by bylo rychleji, než sledujeme nyní.
Tvrdíte, že ISP nechtějí investovat do nových technologií. A sám navrhujete řešení, že by nejprve investovali do drahých zařízení, která by podporovala jakýsi váš protokol TCP/IPv4inIPv4, a pak, až by zjistili, že na tom nic nefunguje, by konečně investovali do zařízení na podporu IPv6. Takže bychom byli tam, kde jsme dnes, ovšem s jedním nesmyslným mezikrokem.
V první fázi by stačilo jen rozšířit prostor, ale stále směrovat postaru.
Odpusťte si ty komentáře, že něco nechápu, když vymýšlíte koniny, protože vůbec nechápete, o co se jedná. Směrování je založené na adresách. Nemůžete změnit adresy a směrovat postaru. Zkuste si to představit na něčem, co snad pochopíte. Třeba byste chtěl změnit adresy na poštovních obálkách, začaly by se tam používat třeba IP adresy. Takže byste na obálku napsal 195.12.76.127 a hodil ji do poštovní schránky. Myslíte, že by se dopis doručil, kdyby pošta směrovala pořád postaru, tj. hledala by na té obálce PSČ?
Pokud by to byla v první fázi jen drop-in náhrada, nikdo by se toho moc nebál.
Ale proč by do toho investoval?
Jak by přibývaly směry s podporou, racionalizovalo by se i směrování prefixů, aby nebylo roztříštěné tak, jako na IPv4.
Jak, když by to bylo založené na IPv4? To byste jako IPv4 pakety směřoval různě podle toho, jestli by to bylo původní IPv4 nebo vaše zmaštěné IPv4.1? Víte, co by se stalo, kdyby v té nové cestě bylo jediné zařízení, které by váš protokol nepodporovalo? Pakety by se zacyklil.
Byl by to postupný proces, ale probíhal by hladčeji.
No zatím tu máme akorát n důvodů, proč by to vůbec nefungovalo. To se dá těžko nazývat „probíhal“, natož „hladčeji“.
Ale popsal jste úplně přesně tu chybu, kterou v návrhu IPv6 udělali. Ne technickou chybu, technicky tomu moc vytknout nelze. Ale obchodní - ekonomickou chybu. Škoda, že jsou technici tak přezíraví k realitě.
Přezíravý k realitě jste vy. Je sice hezké vymyslet si něco, co by obchodně možná fungovalo – ale když to nebude fungovat technicky, je to celé nesmysl.
To, o co jste se zřejmě pokoušel tím vaším nesmyslným nápadem, bylo umožnit dočasně pakety IPv6 v části trasy přenášet i protokolem IPv4. Funkční řešení tohoto problému existuje, jsou to různé tunelovací mechanismy, např. 6in4, 6over4, ISATAP. Proč to tedy podle vás ISP nepoužívají?
Filipe, taháte za slovíčka, snad aby se diskuse vzdálila od podstaty problému. Podstata problému je, že nový IP protokol nebyl navržený s přednostním ohledem na snadný a transparentní souběh se starým protokolem. Souběhem nemyslím, že mohou fungovat vedle sebe jako dual stack, ale naprosto přirozené spojení současného s běžícím protokolem, a s vizí následného přechodu. Ano, bylo by to z počátku plné nepohodlných kompromisů a nějakou dobu by to nepřineslo nic navíc, než jen operační rezervu na dobu, až nastane čas. Ten by nastal, jsem o tom přesvědčený, dřív než tohle, co zažíváme.
Do historie se můžeme podívat třeba na přechod na beztřídové směrování IPv4. To byla taky změna, na kterou nikdo nebyl nejdřív připravný, ale najednou a postupně to šlo.
Filipe, taháte za slovíčka, snad aby se diskuse vzdálila od podstaty problému. Podstata problému je, že nový IP protokol nebyl navržený s přednostním ohledem na snadný a transparentní souběh se starým protokolem.
Ne, podstata problému je, že vy o problému moc nevíte. Protokol IPv6 byl navržen s přednostním ohledem na snadný a transparentní souběh se starým protokolem v maximální míře jak jen je to možné. Ještě lepší zajištění souběhu není technicky realizovatelné. Zatím pokaždé, když někdo (včetně vás) přišel s nápadem, jak zajistit ještě lepší souběh, při bližším prozkoumání jeho řešení se ukázalo, že by to vůbec nefungovalo. Zdá se, že stále nechápete, že IPv6 je v tomto ohledu maximum možného.
Nikdo nezpochybňuje, že je možné vymýšlet teoretické koncepty, která by zajistily lepší zpětnou kompatibilitu. Jejich nevýhoda je, že by v praxi nefungovaly.
Celá debata s vámi vypadá, jako kdybychom se bavili o běhu na 100 metrů a vy byste neustále tvrdil že 9,58 s není světový rekord, protože se to dá zaběhnout za daleko lepší čas. Ano, teoreticky dá, ale zatím to nikdo za daleko lepší čas nezaběhl, takže to v tuto chvíli je světový rekord. Stejně tak je IPv6 nejlepší známé řešení problému s nedostatkem IPv4 adres a zatím nikdo nenavrhl lepší řešení, které by bylo prakticky realizovatelné.
@Filip Jirsák
Ale kdepak. Stačí se podívat na to, jaké koncepční nedomyšlenosti se řešily a řeší, jakého typu jsou nejběžnější problémy a podívat se na dobu, která uplynula. Nakonec se všichni vzájemně přesvědčujeme, jak to bude super, až to někdy v nedohlednu nahradí IPv4. Pár jedinců se na IPv6 těší, daleko víc děsí problémy, které přinese něco, co je skoro 20 let odtržené od reality. Uživatelům je to fuk.
To JE špatný výsledek.
Pořád vedete jen plané řeči. Nenapsal jste jedinou věc, kterou by bylo možné koncepčně řešit lépe (tak, aby reálně fungovala). A vedle toho píšete spoustu nesmyslů, teď jste přidal ten o 20 let odtržení od reality.
Klidně si běh na 100 metrů za 9,58 s označujte za špatný výsledek. Jak jsem psal, svědčí to akorát o vaší odtrženosti od reality.
Mne pride, ze IPv6 je riesenie z nudze cnost. Problem IPv4 sa zanedbal a potom sa narychlo zobralo IPv6 ako existujuce riesenie s dostatocnym poctom adries.
Ono je to složitější. IPv4 se nezanedbal, nikdy nebyl plánovaný pro užití miliardami přípojek. Nejprve armádní, pak akademická síť.
IPv6 byl opravdu navržen bez ohledu na bezproblémový přechod, souhlas.
"Jenže ti, co nový standard navrhovali, nechtěli dělat kompromisy hned od počátku. Stejně jsme jich museli udělat hodně, jen nás to zdrželo."
Lepe bych to nerekl, jasne 6to4 taky neresi vsechno a pro soucasne provozovani obou stacku potrebujes dalsi veci a zarizeni, ale misto jednech hacku tady mame jine no. Asi tak :)
To si myslíš, nebo to víš?
Dělal jsem před osmi lety firmware do domácí automatizace a jeden z požadavků byl "reakce na povel a mobilu do 5s". V praxi to znamenalo povel (velikost 1kB) poslat na server (latence sítě pro jistotu počítaná na 0.5s) a zařízení se musí dotazovat, jestli je tam pro ně nějaký povel. A musí to během těch 5s zvládnout 2x.
A při té příležitosti pošle status, aby ho mobil po připojení viděl. No a protože se server sdílí pro hodně domácností, musí tam být i nějaký ID... Takže na server jsou 2kB dat co 2s.
Počítalo se s prodejem 10k/rok během pěti let. To je 50k*1kb/s = 50Mb/s jenom reporty o stavu automatizace. Není v tom připojení mobilů, nejsou v tom aktualizace SW, není v tom vzdálený servis,...
Server fungoval tak, že report se rozparsoval a narval do DB. Když se připojil mobil, z té DB si to vytáhl a poslal povely. Ty se uložily do druhé DB a když přišel UDP paket z cílovýho zařízení, odeslala se odpověď. TCP bylo nepoužitelný úplně, protože omezený počet portů na jeden server...
Bylo v tom 3/4 roku práce několika lidí, nákup železa, konektivita, energie, další člověk na IT oddělení a proškolení zbytku kvůli zastupitelnosti. 1/3 ceny výrobku tak padla jenom na blbý překonání NATu. Místo toho, že by doma krabička poslouchala a mobil se připojil po TCP a řekli si, co potřebují bez tlumočníka.
A zákazník si nejenom připlatil, ale ještě měl řešení, který stálo na jednom racku kdoví kde a pokud se v něm něco rozbilo nebo někdo překopl kabel, tisíce domácností měly smůlu. Nakonec tu firmu koupil někdo jiný, cvakl vypínačem... A kup si od nás nový hardware s novým protokolem, blbečku. Takže tak...
Á jé, zase tahle storka, kterou jsme tu vyvraceli už několikrát. Takže znovu:
Tohle se řeší tak, že si otevřeš spojení (TCP nebo UDP, pro UDP se inspiruj jak to dělá OpenVPN, kde klient za NATem samozřejmě dostane příchozí paket hned a nemusí se 100x za sekundu dotazovat) a pak ho necháš otevřené a maximálně jednou za minutu pošleš keepalive, aby NAT to mapování nezahodil. Pokud to chceš super-úsporné, můžeš keepalive interval automaticky prodlužovat a až detekuješ ztrátu, tak víš, jaké je nastavení NATu po cestě a kolik tedy potřebuješ.
Právě jsem vám ušetřil mnoho milionů korun. Dovoluji si nabídnout vám své konzultační služby: moje cena za manday se sice může zdát vysoká, ale jak vidíte, dokážu poskytnout takové rady a služby, že se mnohonásobně vyplatí. Pokud jste měli v síti tohle, je pravděpodobné, že vám dokážu zařídit i další podobné úspory.
Aha, takže pokud to chápu dobře, tak správné řešení je že místo pravidelného pingání se tím vzdáleným rackem udržuje těch odhadovaných ~50k otevřených spojení?
Zdá se mi to, nebo je to úplně na jedno kopyto jen s rozdílem ve velikosti datového toku? Mně jako potenciálního zákazníka trápí hlavně ta závislost na vzdáleném serveru. To, že ho nový vlastník může jen tak vypnout, je kurvítko jako máloco.