Vlákno názorů k článku IPv6: nechtěné dítě (pomalu) přichází od klokan - Záleží na tom, jak kdo a co používá....
-
Záleží na tom, jak kdo a co používá. Ono je to trochu jako s Flashem: pro někoho dávno mrtvá záležitost, někdo jiný si bez něj stále ani neškrtne. Já mám konkrétně doma IPv6 dual stack a komunikace s Googlem, Youtube, Wikipedií, Ubuntu repozitáři a dalšími významnými servery ho automaticky používá (jak jsem zjistil), takže celkově kolem 50% objemu veškerých přenášených dat mi jde přes IPv6. Je ale pravda, že na nějaký razantní nástup IPv6 Evropě a Severní Americe si ještě počkáme (kromě Belgie, tam už mají téměř polovinu uživatelů na 6). Hlavní růst šestky asi opravdu uvidíme především v rozvíjejících se zemích - v Indii, Africe apod. kde jsou obrovské rezervy potenciálních uživatelů a velice málo disponibilních bloků IPv4.
-
Nemyslím, že by tady byla nějaká snaha, natož důvod se "zbavit" V4. Pokud někdy zanikne, bude to v perspektivě desítek let. Otázka je spíš, co se stane, až přijde další vlna startupů, cloudů apod., které už budou mít problém získat potřebnou zásobu V4 adres a perspektivně jejich služby budou přístupné pouze přes IPv6.
-
Filip JirsákStříbrný podporovatelPush z webu ke klientovi na IPv4 nebo IPv6 vůbec nezávisí, protože se provádí tím spojením navázaným z klienta na server. Jinak by byl problém hlavně v proxy serverech a firewallech.
-
tnr (neregistrovaný)
Vetsinou s tebou celkem souhlasim,ale tady se dle meho nazoru pletez.
Ipv4 je dost problem pri pushingu na klienta kvuli ruznym nat po ceste. Tzn. Zde vznika nedeterministcnost kdy budou spojeni zavrena,coz u long pollingu (ale i treba ws) predstavuje zasadni problem. Nektere nat proste po urcitem timeoutu komunikace spojeni proste zahodi a neposlou ani ukonceni spojeni,tzn. browser o tom nevi...
U ipv6 routery (ci jejich fw) nat standardne neprovadi (ani dokonce nemusi delat conntrack),pakety posilaji cilove stanici,tudiz uzavreni spojeni je v rukou prohlizece/os, coz je mnohem spolehlivejsi.
-
Filip JirsákStříbrný podporovatel
Všechny mechanismy pro push na klienta používají nějaký ping pro udržování aktivního spojení. A klient musí počítat s tím, že se spojení může kdykoli přerušit a znovu ho navázat. NATy v IPv4 přidávají jen další důvod, proč se spojení může přerušit, v tom s vámi souhlasím, ale není to jediný důvod. Může to udělat kterýkoli prvek na trase, který sleduje spojení (třeba stavový firewall), může to udělat proxy server, může to způsobit výpadek mobilního signálu nebo WiFi.
Zrovna push z webového serveru je myslím technologie, která si s NATy poradí velice dobře. Mnohem hůř jsou na tom podle mne třeba služby pro IoT (routery, webkamery, NASy apod.), VoIP nebo sdílení souborů, které používají různá serverová a cloudová řešení jenom proto, aby se spolu domluvili dva klienti za NATy, kteří by jinak mohli komunikovat přímo. A to možná některým poskytovatelům cloudových služeb naopak nahrává, protože kdyby spolu mohla zařízení komunikovat přímo, nebudou potřebovat obezličky jako Skype.
-
tnr (neregistrovaný)
Samozrejme, ze se to musi resit i tak a ze je to jen jedna vec. Nejaka forma keep alive je samozrejme potreba tak ci onak.
Ale nesouhlasim s tim, ze si s tim NAT poradi uplne dobre... Docela jsme to resili na jednom projektu, kde mel uzivatel permanentne otevrenou stranku a notifikace chodili opravdu sporadicky a resili jsme mnoho ruznych incidentu, kde to problmy zpusobovalo (vetsinou tak, ze NAT proste spojeni tise zapomnel). Pravda, bylo to zejmena u mensich a obskurnich ISP, skoncilo to u uplne nesmyslneho aplikacniho keep alive (45 vterin).
Na IPv6 se to chovalo vsude dobre.
Samozrejme, i na IPv6 muze vzniknout podobny problem diky stavovemu firewallu, ale dle me zkusenosti je to mnohem mene caste reseni (proste proto, ze to neni nutne, tak ty FW na trase typicky stavove nejsou, coz je samo o sobe vyhoda) -
SB (neregistrovaný)
„A to možná některým poskytovatelům cloudových služeb naopak nahrává, protože kdyby spolu mohla zařízení komunikovat přímo, nebudou potřebovat obezličky jako Skype.“
Pochopitelně. Kdo někdy řešil Voip SIPem, zjistil, že většina operátorů Voipu nepřidělují klientovi sipovou adresu, ale jen tel. číslo jen proto, aby se nemohli klienti spojit přímo (vyjednáním spojení SIPem), ale museli přes operátora placeně, přestože je to zcela zbytečné. A to se ani nebavíme o přímé viditelnosti klientů, kteří by tak nepotřebovali ani prostředníka (SIP proxy).
Zrovna Voip je VZOROVÝM příkladem, jak triviálně může fungovat přímá komunikace a jak je na hovno, když to nejde. -
bflmpßwẓ (neregistrovaný)
Jenže u ipv6 routerů bude NAT nahrazen firewallem, který ke stanicím nepropustí spojení iniciované zvnějšku - nikdo rozumný tohle nenechá. (Mimochodem, to je i hlavní důvod nasazení NATu, protože určitou ochranu - přes ideologické žvásty IPv6 propagátorů - přeci jenom představuje. Nedostatek IPv4 adres je jen výmluva...)
-
Filip JirsákStříbrný podporovatel
NAT nenahrazuje firewall. Nevím, co je závadného na spojeních navázaných z venku – když pro vás má někdo zprávu, je rozumné, když může navázat spojení a předat vám jí.
-
Sten (neregistrovaný)
Je zde jeden zásadní rozdíl. Pokud na IPv6 chci otevřít UDP port (třeba pro VoIP), pošlu UDP paket na IPv6/port vyjednaný s druhou stranou, port se otevře pro příchozí spojení a vše funguje. Pokud to chci v IPv4 s NATem, tak jsou tři možnosti, jak to dopadne. Pošlu ten paket někomu jinému a ten port se otevře a namapuje pro všechny IP adresy. Pokud jej zrovna používá někdo jiný, tak mu ukradnu provoz. Bezpečnost hadr. Za to vám zákazníci určitě poděkují. Nebo to ten firewall namapuje jen pro daný IP/port, pak musím nějak zjistit, jakou veřejnou IP adresu má druhá strana (pokud má NAT, tak to neví). Anebo je tam „nejmodernější“ symetrický NAT, který mění číslo portu odchozích paketů, pak pokud má druhá strana též NAT, tak mám smůlu, protože není jak zjistit, jaký port má vlastně použít. A to pomíjím obrovské problémy, pokud bych chtěl ten provoz šifrovat pomocí IPSec či přesměrovávat u roamujících klientů (např. mobil přecházející mezi LTE a Wi-Fi).
-
xsouku04 (neregistrovaný)
O žádných zásadních problém nevím. Server prostě posílá RTP na por a ip adresu odkud dostává RTP sám. Tedy koncové zařízení musí posílat zvuk už i během vyzvánění. V SIP hlavičkách jsou pak nesmysly, který se ignorují. Kazí to celý koncept SIPu ale funguje to relativně dobře. Koncept SIPu jaksi na NATy zapomněl a má i jiné zásadní chyby.
-
Sten (neregistrovaný)
Kdo začne posílat, pokud jsou obě strany za NATem?
Pro zjištění portů v SIPu se používá TURN server a doufá, že tam není symetrický NAT, jinak musí jít veškerý provoz přes nějakého prostředníka. To je také důvod, proč se SIP prosazoval v 90. letech a pak už moc ne.
NAT není problém jenom SIPu, ale veškeré P2P komunikace. Třeba WebRTC naráží na ty samé problémy.
-
Mobilni operatori v CR (neregistrovaný)
Ti zamichaji leda simkartama. Uz v roce 2008 kdy Vodafone koupil firmu Broadnet jsme tam meli IPv6 v pateri, pripravovane na webhostingu a planovali jsme zacit nabizet i zakaznikum. Vodafone to pak cele stopnul, sliboval ze tak az rok atd... Dodnes nabizi leda kulovy. Zdejsi mobilni kartel se rozvoj jen brzdi tak jako to drive delal zluty smejd SPT Telecom. Vsechno je to stejna pakaz.
-
To se asi nedozvíme. Když se podíváme na IP 80.250.8.---, tak nám z ní sem se stejnou inteligencí píše kvákvá a bflmpßwẓ. A pro zajímavost to podle whois směřuje k firmě Gordic, tedy firmě už dlouho přisáté na státní peníze. Že by v některé ze smluv a tech. specifikací přehlédli zmínku o IPv6, teď to po zadavatel chtěl a proto tak kopou kolem sebe? ;-)
-
Hele, není třeba vymýšlet žádné další důvody. To už si vymysleli. Prostě jsme specifickej trh. Stačí.
Tohle se dá použít univerzálně, v potravinářství (prostě budeš chlastat fruktózu), při stavbě dálnic (nejdražší a ještě neustále v přestavbě), pro mobilní operatéry (nefunkční nejdražší s fupem na 10minut a když se ti to nelíbí, odstěhuj se do Polska), pro isp (nat stačí, veřejnou nikdo nechce a o šestce jsme v životě neslyšeli) a tak dále.
Prostě specifickej trh no.
-
tnr (neregistrovaný)
Nejsem priznivcem zakonnych opatreni / zasahu do soukromeho podnikani, ale na druhou stranu je pravda, ze tohle neco podobneho jako mobilni site. Dovedu si zde predstavit jistou regulaci ze strany CTU, regulace ISP uz nejakym zpusobem funguje. Kdyz je mozne zaukolovat ISP kvuli takove 3.14vine jako je blokovani hazardnich webu, tak tady by to bylo aspon ku prospechu veci. Ale samozrejme to neni v dusledku dobry napad, protoze by se rozjeli zaloby a napadani kvuli udajnemu zvysovani nakladu (ktere je povetsinou imaginarni).
-
Palo (neregistrovaný)
A kolko bolo zalob za kasy? Tie naklady nezvysili? Ak to proste nejde inac tak to CTU vynuti zakonom. Dalsi priklad su roomingove poplatky od EU. Ked to proste neslo, vsetkym na trhu to vyhovovalo tak to proste vynutili. Existujuce mozu nechat ale nove pripojenia musia ponukat aj IPv6. Ked nechcu investovat mozu pomaly umierat.
-
Petr M (neregistrovaný)
Na co? Já si nepamatuju ani svou veřejnou IPv4, a to je jenom jedna... zato dám z hlavy lokální IPv6 adrsy na domácí LAN.
Kde je v IPv4 192.168.1.10, tam můžu v IPv6 použít na lokální síti fe80::10 (prefix se zapamatovat dá, konec si dám v BCD to, co na 4ce a zbytek nulový, zajištěn pomocí dvojteček). A je to...
-
. . (neregistrovaný)
localhost mi je putna, mám co do činění s firemními sítěmi, kde jsou desítky tisíc koncových stanic a tisíce serverů, občas se řeší nějaký incident nebo se ladění routování. IPv4 se dá relativně snadno zkontrolovat a projít z hlavy, už mám vycvičený zrak, abych IP adresu našel v haldě textu v terminálu.
Nekritizuji IPv6, je v mnoha ohledech lepší a přínosem pro podobné sítě, ale tohle je pro mě její nevýhoda, toť vše.
