Vlákno názorů k článku IPv6 po deseti letech: svět je v třetině cesty, Česko se zaseklo od jdsulin - Nejvetsi problem u IPv6 je ten, ze vsechny...
-
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.
-
Filip JirsákStříbrný podporovatelNedomyšlené do praxe
Napříkald?nevymyšlené přechodové cesty
https://en.wikipedia.org/wiki/IPv6_transition_mechanismnevymyš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.
-
Filip JirsákStříbrný podporovatel
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ě.
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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ákStříbrný podporovatel
Kritizovat samozřejmě můžete co chcete, třeba to, že Země obíhá kolem Slunce. Akorát když kritizujete něco, co se velmi přibližuje maximu možného, vypovídá to akorát o vás, ne o předmětu kritiky. Zvlášť když pak sám navrhnete „řešení“, které by vůbec nefungovalo.
-
@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.
-
Filip JirsákStříbrný podporovatel
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...
-
Jan HrachStříbrný podporovatelÁ 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. -
Jan HrachStříbrný podporovatel
> Zdá se mi to, nebo je to úplně na jedno kopyto jen s rozdílem ve velikosti datového toku?
Předřečník si stěžoval na datový tok.
-
Mně naopak přijde, že předřečník si stěžoval na spoustu věcí co dohromady stojí ranec: "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." Nerozpočítával náklady na jednotlivé položky, ale já bych hádal, že tomu bude dominovat ten "další člověk na IT oddělení".
-
Datový tok je detail, to bylo jenom pro představu. Když je potřeba tahat víc dat, radosti úměrně přibývá.
Update po minutě neprojde, pokud zákazník chce aktuální stav se zpožděním max. 5s a reakci na nastavení z mobilu do 5s.
1/3 ceny zařízení je reálně v nákladech na průstřel NATů. Někdo musí vyvinout řešení (sw na tom serveru), musí to někdo hlídat (i kdyby to bylo hotový řešení v čmoudu, někdo to musí monitorovat, rezervovat kapacitu,...) a za provoz serverů se platí. A fakt to není sranda...
Kdyby se to prodávalo za řekněme 30€ a IPv6 stack si vyžádal o 2€ dražší paměti a procák, tak by zákazník byl furt o 8€ na kusu v plusu. Nehledě na jednodušší testování, kratší time to market a nemožnost nasimulovat plnou zátěž toho serveru ve stývajícím řešení...
-
Takže:
1) Spojení po IPv4 na mobil nenavážete. Mobil je v síti operátora, kde je nějaký NAT a zařízení se s ním nespojí, pokud ho nekontaktuje mobil.
2) Zařízení je sice připojeno pevně, ale na 99,99999% samo nemá veřejnou adresu a musí fungovat za NATem. A požadavek je, aby to fungovalo i za CGNATem nebo routerem od ISP, do kterýho nemůže pan domácí vrtat. Takže spojení z mobilu taky nenavážete.
3) Udržovat trvale desetitisíce spojení je fakt, vzhledem k počtu portů na jednu IP adresu, super nápad. Ještě že to nejde realizovat, protože ty spojení se nedají otevřít.
4) Nedotazuje se 100x za sekundu, ale je to jeden UDP paket za 2s (počítá se s MTU > 1000).
5) Takhle rada je opravdu cenná. Kolik zaplatíš, abys se mnou mohl dělat na projektu?Čistý řešení = krabička má veřejnou IP adresu, mobil se prostě připojí k ní. A nepotřebuju platit experta, aby řekl, že to IPv4 v současným stavu neumí.
-
Jan HrachStříbrný podporovatel
1,2) Nechápu jak souvisí s diskutovaným problémem.
3) Spojení není definováno jen portem, ale také zdrojovou IP adresou.
4) To byl příklad jak funguje OpenVPN, přes kterou je běžně ping pod 10 ms. Aby toto bylo možné s tvým dotazováním, musela by se dotazovat 100x za sekundu.
> Čistý řešení = krabička má veřejnou IP adresu, mobil se prostě připojí k ní. A nepotřebuju platit experta, aby řekl, že to IPv4 v současným stavu neumí.
Ano, já vím, jaké je čisté řešení. Ale to ani jeden nemůžeme ovlivnit, a ty jsi ten, co posílá ze všech zařízeních pakety každé dvě sekundy, i když by stačilo jednou za minutu.
-
1, 2 - to je důvod, proč to nejde udělat jednoduše a správně
3 - to samozřejmě vím. Akorát je lepší každý soket spustit ve vlastním vlákně (nebo ideálně procesu) a pak je v DB a v paměti celkem mela...Není radno jich tam mít moc.
4 - OpenVPN navazuje spojení proti pevné IP adrese. A tu nemá ani jedna ze stran, co chtějí komunikovat. Takže to je blbý příklad... A nejde o rychlost, stačí o doručit do 5s, takže střelit status v UDP po 2s je akorát. Udělalo se pár testů a UDP střely byly ten lepší způsob. Čas nebyl problém, gigová linka to taky utáhla, šlo o zpracování dat... -
Jan HrachStříbrný podporovatel
> Čas nebyl problém, gigová linka to taky utáhla, šlo o zpracování dat...
To pak ale nevypadá jako problém s absencí přímé konektivity, že? (zpracování dat by šlo zrušit tím, že by server pouze tupě přehazoval pakety a zpracování by si řešilo koncové zařízení jako kdyby přímé spojení existovalo)
