Názory k článku IPv4 adresy definitivně došly a další nebudou
-
Kokos99 (neregistrovaný)
A proč by to vyžadovali? Veřejnou IP adresu skutečně potřebuje maximálně tak jeden uživatel ze sta. Navíc vyžadovat ji můžeš už i teď, jenom si většinou připlatíš tak okolo stovky měsíčně ke stávající ceně internetového připojení (tzn. kdo ji skutečně nepotřebuje, ten si ji jen tak zřídit nenechá).
-
Filip JirsákStříbrný podporovatelDynamické DNS stejně musí směřovat na veřejnou IP adresu. Dynamické DNS řeší pouze to, pokud veřejná IP adresa není pevná ale mění se. Jenže tím dnes prakticky žádné adresy neušetříte, protože většina klientů je připojena stále. Dynamické IP adresy měly smysl v době, kdy se někdo připojil jen na omezenou dobu a počet aktivních klientů tedy byl menší, než celkový počet klientů.
-
M. (neregistrovaný)
Upřimně řečeno, pokud se zákazník o IP adresu a jaká bude zajímal, tak chce, aby byla neveřejná, než primární požadavek na veřejnou adresu.
Obvkyle se tak cítí bezpečneji v případě šmírování, že když je s neveřjekou, mám o něm data za půl rok a po tu dobu dokážu obvkyle při požadavku soudu dohledat o koho šlo. Pokud mám zákazníka na veřejce, tak historii vím roky zpět, protože IPčka mají lidi napevno a i nebyl proto problém odpovědět a identifikovat požadavke soudu ptající ho přes rok zpětně.
Alespoň torentisti vypadají, že jsou za CGN raději než se svoji veřejkou.
Takže stále platí, že někdo vdolky a jiný holky... -
M. (neregistrovaný)
Nu, jen popisuji zkušenost ze sítě ISPíka okresního formátu, kde se v nabídkách i na webu taktně mlčí o tom, zda veřejná/neveřejná IPv4/IPv6.
Pokud se lidi aktivně zajímali, tak spíše v tom, že chtějí být za NATem, než s požadavkem na veřejku (ta se dfává zdarma na žádost za asi 300 Kč jnorázový poplatek). Jako zdůvodnění, když se člověk ptal, tak to co jsme uvedl o dohledatelnosti.
Torrent jed ei za tím blbým NATem, pokud ne, tka je spíše na vině dneska snaha ISPíka prznit a utlačovat torrent jako takový nejrůzněšjšíma nesmyslama v řezání rychlostí atd. -
j (neregistrovaný)
Torrent za NATem nefunguje, funguje v pasivnim rezimu => nede se sosat od vsech se stejnou chorobou. A presne jako chorobu je treba NAT vymytit.
Pokud si nejakej mamlas mysli, ze je za NATem nedohledatenej, tak to maximalne svedci o jeho IQ houpaciho kone. Pokud chci bejt (realtivne) v bezpeci, koupim si VPS na predplacenou kartu nekde ve Svycarsku.
-
M. (neregistrovaný)
Tak tohle snad záleží i na druhu NATu a čím je aplikován, V kombinaci s Torentem, pokud jede µTP protokol (nad UDP) a použije se STUN, tak celkem OK to prolézá. S TCP je problém, tak tam NAT traversal je na tom mnohem hůře a přes některé není šanci (např přes FreeBSD PF). Druhá věc je, jak jsou na tom klienti s implementací těchto volovin (µTP). Nicméně se tohle obvkyle řeší, ze zákazník fasuje blok portů, který se na něj forwarduje a s tím němá Torrent nejmenší problém.
Jistě, s IPv4 veřejkama až na router zákoše je život jednodušší (a ten home NAT pořeší UPnP), ale život není ideání... :-)
Onoani s IPv6, co jsem si všiml, zaítm řada Torrent klientů moc nefungovala OK.Argument nebyl tak vysledování aktuálně, to samozřejmě jde, ale to zpětné dohledání. U NATu jde po omezenou dobu, co mám netflow 6 měsíců (a pokud bych ukládal data jen striktně dle požadavku vyhlášky, tak to občas ani dohledat nejde). Ale pokud má svoji veřejku, dokážu ho identifikovat roky zpětně velice snadno...
-
Ne. Když chci stahovat data, musím si o ně říct, samy nepřijdou. A pokud je vlastník dat za NATem, tak není cesta, jak mu přímo říct, aby poslal data.
Jedině to spojení tunelovat. Nechat mu někde na serveru vzkaz, ať na mou IP adresu něco pošle. Takže tydýt za NATem se furt musí ptát, jestli po něm někdo něco nechce a kam to má případně poslat. A pokud jsou za NATem oba, tak musí nechat odpověď v nějaké cache s veřejnou adresou...
Takže traffic navíc s dotazama, nutnost prostředníka, který, pokud je v oblasti jediný a má prostupnost 5Gbps,omezí v oblasti všechny torrenty na 5Gbps. Když stahuje 1000 lidí, dá průměr 5Mbps. Bez ohledu na to, že sousedi mají mezi sebou gigovou optiku místního ISP a (teoreticky) by to nasdílení filmů mohlo jet 200x rychlej...
-
Kokos99 (neregistrovaný)
Super díky za vysvětlení. Já si právě říkal, jak je tohle možné, když já jsem za NATem a normálně lidi se ke mě na P2P připojí a stahují od mne. A ještě zajímavější je to, že to funguje automaticky, tzn. nic jsem na klientovi nemusel nastavovat a ono to funguje. No nic, díky za objasnění. :)
-
ebik (neregistrovaný)
Ad domlouvani se pres verejny server: vsechny P2P site, ktere se autokonfiguruji (skype, torrent, ...), potrebuji prostrednika, pres ktereho si ty aplikace sdeli ze jsou online, a co poskytuji za sluzby (V pripade torrentu je to tracker). Pokud mam nat, na kterem se da "otevrit UDP port", tak mne muze kdokoli kontaktovat (aktualni cislo toho UDP portu vystavim na tom trackeru). To jsou naty ktere port na vnejsi ip adrese mapuji na port+adresu na vnitrni siti bez ohledu na adresu opacneho konce spojeni. Nektere "chytrejsi" naty klidne prideli spojenim ktere se lisi pouze vzdalenou adresou/portem ruzne vnejsi porty i kdyz vnitrni adresa/port je stejna, pak je to teprve tak jak tu tvrdite, ale rozhodne se tak vsechny naty nechovaji (ono to muze zamezit fungovani nekterych obskurnich UDP aplikaci).
P.S. spojenim zde myslim i "nespojovanou" komunikaci po UDP mezi dvema aplikacemi.
-
M. (neregistrovaný)
Ono to záleží na tom, jaký protokol Torerent klient podporuje, pokud už umí uTP s UDP, tak to funguje trošku jinak, kde to UDP s esnaží i obejít limitace na TCP ohledn řízení propustnosti.
uTP protokol nad UDP umí i přímou komunikaci mezi dvěmi koncovými stanicemi, co jsou za NATem, ten prostředník se použije jen k počátečnímu domluvneí a proražení UDP portů ven na obou stranách a pak už se posílají data přímo. Podmínka je, že když už je použit CGN NAT, tka nesmí být dementní, aby prostřeník v roli STUN nedokázal určit vnější porty, co se použijí pro P2P komunikaci.
Takže ano, koncák za NATem si drží otevřené spojení na tracker, kde čaká, zda někdo o něco požádá a až jop a pokud oba umí uTP, tak proveodu pomocí STUN otevření UDP portů na svých NATech a data pak tečou přímou mezi nima (pokud jsou na obou stranách rozumné typy NATů - ne symetrický a randomizující). -
Fakt?
Torrent je o tom, že vystavím svoje soubory veřejně a někam na "centrálu" publikuju jejich seznam. Když ho někdo potřebuje, připojí se na můj kompl a stáhne si to. Jenomže když budu sedět z NATem, nikdo e na můj kompl nepřipojí. Z venku vidí třeba 121.121.121.121, žádost dorazí na NAT a ten neví, na koho z 10.0.0.0/8 to přeposlat. Takže bych jenom sosal a nic za to nedával. To je nefér, že?
Navíc jenom pitomec si může myslet, že za NATem je anonymní.
ISP má ze zákona povinnost evidovat provoz skrz NAT, však o tom tady byl tenhle týden článek. Pokud vyšetřovatele zajímá stahování hudby a vyžádá si seznam spojení na nějaký adresní rozsah třeba 16 adres, protože je v něm šest pirátských serverů s hudbou, vidí i to dětský porno, co trůní na jiné adrese v tom rozsahu... S veřejnou IP jenom ISP sdělí jméno, komu IP adresa patří a hotovo.
Další "drobnost" je, že služby jako VoIP, inteligentní domácnost, VPN apod. musí jet přes server třetí strany. A je jednodušší traffic sledovat tam a hromadně, než nasazovat štěnici mezi dva sousední baráky, co si povídají v rámci jednoho ISP...
-
M. (neregistrovaný)
Ohledně toho zpětného dohledání - za NATem je víc chráněn. Pokud má zákazník svoji veřejku, tak dokáži na dotaz soudu identifikovat některé 5 i 8 let zpětně (občas jde dotaz od soudu i rok zpětně). Pokud je zákazník za NATem, tak držím informaci jen 6 měsíců, na starší odpověď je sorry NAT, smazáno.
Od soudu nepřijde žádost, vypište mi spojení a kam se spojval někdo, protože aktuální prováděcí vyhláška toto neumožňuje. Já mám jen u sebe držet informace o stavu NATu, to jest v jaký čas, jaká vnitřní IP adresa:zákazník na co byl NATován na veřejnou IP:port:protokol, ale už ne informaci o tom, kam šlo spojení! (Pomiňme, že pokud něco už korektně sbírá netflow z NATu, tak to uládá i cíl). Takže přijde požadavke, kdo měv v čase X, IP adresu Y? Je to věřejka koncáká, předávám, je to NAT - sorry, NAT, půlka okresu, dojde upřesnění čas X:Y:Z až X:Y:Z.zzz,IP Xm port P, protokol Q. Pokud dle toho dohledám, kdo měl spojení z této kombinace, tak prásknu, ale může se stát, že i tak to odpovídá víero lidem a odpovídám - sorry, cca 5 lidí. Bez informace o tom, kam to spojení šlo to nejde jendoznačně určit a tuto informaci o cíli spoejní já (správně) ukládat nemám. Proto soud nemůže žádat o seznam spojení a ani to aktuálně nedělá, protože je správně nemám mít uloženy...
Je nyní požadavek Bezpečnostní rady státu, aby ISP měl povinnost ukládat i adresu:port kam spojení šlo (což fakticky dělají často už teď v netflow datech), pak teprve půjde jednoznačně vždy dohledávat lidi. Ten návrh současného evidentně dělal někdo, kdo nepočítal s NATy, co pro každé spojení neotvírají nový port. -
M. (neregistrovaný)
Tohle jsem úplně nepochopil?
Jako ISPík dávám IPv6 segment na zákazníka, domácnost dostane /60, já si jen vedu, kdo má jakou /60 přidělenou. Co si s tím doma dělá je mi fuk, Klidně ať použije privacy extensions, aby měl IPv6 adresu na konci náhodnou, to mi je jendo.
Při požadavku na identifikaci já hledám jen dle toho /60 prefixu a sdělím na koho je daná smlouva/přípojka, co se dělo tam, to mi je zcela fuk....Pokud jsi to navrhoval tak, že mám třeba panelák s 50-ti byty a přípojkami, s koro každým mám smlouvu a schovám je tak, že dám všechny jejich přípojky do jednoho L2 segmentu a na něj pustím jednu /64, tak si já jako ISPík život komplikuji, protože koncový bod sítě je ta přípojka na bytě a já pak budu muset sbírat jednotlivé linky a vést si seznam jaké IPv6 adresy na jakém portu byly a dle toho pak dohledám o koho šlo. Což je zbytečná práce navíc. Protože jaksi pokud v tomto případě řeknu, sorry, je to panelák, co má jendu /64 a v něm je 40 přípojek, tak se soud také může naštvat, podat stížnost k ČTU a můžu mít na krku správní delikt v neplnění požadavku zákona s pokoutou 5 MKč. Navíc z takového je spousta komplikací, kdy buď se musí ty byty vzáájemně vidět v jedom segmentu a polezou si tam nebo udělám izolaci portů a sousedi k sobě pak nemůžou vůbec, pak leda to dát jako offlink adresy, aby to šlo skrz router a tam firewall, to zase způsobí i lokální domácí provz skrz router, ....
Takže do tohodle jao ISP nepůjdu.Jiná je, když je ten panelák třeba bytové družstvo a družstvo si objedná přípojku na barák, já končím na patě baráku jednou veřejkou a blokem /56, co jim předám, tam ať si s tím udělají, co chtějí.... Při požadavku na indetifikaci mám smlouvu s družstvem na předávací bod a udávám jako majitele přípojky družstvo, ať si dál s tím naloží vyšetřovatel jak chce, já si své splnil.
-
Jenda (neregistrovaný)
> Při požadavku na identifikaci já hledám jen dle toho /60 prefixu a sdělím na koho je daná smlouva/přípojka, co se dělo tam, to mi je zcela fuk....
No a ten prefix můžeš po půl roce „zapomenout“ stejně jako dneska po půl roce zapomínáš seznam přeložených spojení na NATu.
> protože koncový bod sítě je ta přípojka na bytě a já pak budu muset sbírat jednotlivé linky a vést si seznam jaké IPv6 adresy na jakém portu byly a dle toho pak dohledám o koho šlo. Což je zbytečná práce navíc.
No ale to teď když je máš za NATem musíš dělat ještě víc (nestačí ti trackovat IP adresy, ale musíš ukládat všechna překládaná spojení).
> Navíc z takového je spousta komplikací, kdy buď se musí ty byty vzáájemně vidět v jedom segmentu a polezou si tam nebo udělám izolaci portů a sousedi k sobě pak nemůžou vůbec
Jak tohle řešíš když máš ten panelák za NATem? Tam na sebe v té privátní síti taky vidí, ne?
-
M. (neregistrovaný)
> No a ten prefix můžeš po půl roce „zapomenout“ stejně jako dneska po půl roce zapomínáš seznam přeložených spojení na NATu.
Legislativa je tak, že informac,e co zbírám primárně za účelem vyhovění data retention, tak ty musím po 6-ti měsících mazat, což snad i všichni činí. Informace, co vznikají a udržuji primárně z jiných důvodů, ty si mohu držet jak dlouho potřebuji, takže pokud mají zákazníci veřejné adresy IPv4 i IPv6 bloky roky, tak za tyto roky zpětně dokážu odpovědeť na idnetifikační požadavek a odpovídá se (reálně se nešlo zpětně dál, jak rok). Protože tak to po mě žádá i obecná legislativa.
Nehodlám koncáky krýt a vystavovat sebe riziku, za těch pár korun od nich mi to nestojí. Nemám zájem na sebe poštvat ČTU na téma auditu mých systémů a podobných vylomenin, protože tohle krytí se dá relativně snadno odhalit...> No ale to teď když je máš za NATem musíš dělat ještě víc (nestačí ti trackovat IP adresy, ale musíš ukládat všechna překládaná spojení).
Ano, pro lidi za CGN musím ukladat stav NATu. A proto nehodlám si prznit konfiguraci IPv6 tak, abych musel ukládat podobné ptákoviny, když se jich chci zbavit. A už vůbec ne jen proto, abych tím kryl identitu koncáků....
> Jak tohle řešíš když máš ten panelák za NATem? Tam na sebe v té privátní síti taky vidí, ne?
Provozuji snad přístupovou síť k Internetu a ne LAN pro panelák. Klienti se samozřejmě přímo nevidí. Je aplikována izolace portů od sebe. Spojit se na sebe mohou, ale jde to přes L3 prvek a trochu delší cestou než jen dva sousendí porty mezi sebou na tom switchi v baráku. Ať mají IPv4 veřejky nebo neveřejky, či IPv6, je to stejné. A už vůbec proto nebudu síť přestavovat na barákové L2 segmenty.
(Někdo to tak má, že panelák je jeden L2 segment a lidi se vzájemně vidí, je víc metod, jak to dělat, záleží na použité technologii a co jak chci dělat. A někdo izoluje natvrdo, že se sousedi na sebe vůbec nemohou přímo spojit.) -
Filip JirsákStříbrný podporovatel
Obvykle se dá docela dobře odhadnout, který počítač komunikuje i kolik jich je.
-
M. (neregistrovaný)
Nu, kombinace neveřejná IPv4 a k tomu veřejný IPv6 prefix se začíná celkem prosazovat i v Česku.
Ono to spíše začíná smrdět, že koncová veřejná IP adresa jako povinnost bude možná přání EU po ISPících v EU. Takže hrozí, že řada lidí čeká budoucnost s IPv6 only síti, pokud ISPík nebude mít dost globálních IPv4 adres (možný následek, pokud by prošel některých návrhů, jak vyřešit námítky EU soudů na data retention - uděá se z toho velk ý online dynamický registr IP-zákazník k nahlížneí ouřadům, jak registr aut). -
Petr M (neregistrovaný)
Jenomže veřejnou IP adresu budou vyžadovat až ve chvíli, kdy budou potřebovat komunikaci se zařízeníma doma, třeba s topením.
Tohle jde ale řešit pomocí šmíruňk serveru s pevnou IP adresou, kdy jedna IP zvládne kontrolovat data tisíců domácností a při tom pořizovat "big data". Takže v zájmu prodejců IoT je udržet IPv4, aby měli "důvod".
ISP by se museli něco naučit, vyměnit IPv4-only krabičky a to je bude stát čas a peníze. Takže IPv6 není v jejich zájmu.
V zájmu spekulantů je nemít k IPv4 alternativu a vyhnat cenu public adres do astronomické výšky. Ti jsou zásadně proti IPv6.
V zájmu poskytovatelů obsahu je dostupnost jeich stránek pro většinu lidí. I kdyby chtěli jet na IPv6, stejně se bez IPv4 neobejdou, přišli by tak o 90% čtenářů nebo zákazníků.
A BFU nemá páru ani o IPv6, ani o tom, že ho vlastně má chtít... Otázka je, kdo zaplatí spoty na TV Noha...
-
j (neregistrovaný)
BFU uz davno neco nejde - proto sou vsude kolem mililony dotazu, proc nefunguje to ci ono. Jen me osobne se ptaly uz minimalne stovky lidi, jak se treba pripojit domu a stahnout si fotky, jak si sosnout knizku ze svyho domaciho uloziste, jak zapnout topeni, jak prijmout soubor pres IM ... protoze to vse mohli videt u me. A odpoved v 50% pripadu byla "jo, kdyz ty nemas internet, tak smula".
-
XD (neregistrovaný)
> V zájmu spekulantů je nemít k IPv4 alternativu a vyhnat cenu public adres
> do astronomické výšky. Ti jsou zásadně proti IPv6.Jak se to veme. Spekulanti protrebuji jakousi latentni existenci IPv6, protoze to je skvely argument jak nekoho presvedcit ze ma IPv4 adresy prodat dokud je cas.
-
Petr M (neregistrovaný)
Ale v síti přece můžou jet IPv6 a IPv4 současně. Jenom to musí podporovat routery a další blbiny.
Představte si vesnickýho WiFi ISP, který má infrastrukturu bez podpory IPv6 (ta jde nahrát / zapnout maximálně někde na centrálních serverech). Kdyby měl najednou zavést IPv6, mění komplet hardware v terénu. Zkuste to, když od každýho koncáka přiletí do kasičky 300-500Kč za měsíc a jenom APčko na baráku zákazníka bude řekněme za dvojku + montáž... Půlroční obrat jde do krabiček u zákazníků, další půlrok do infrastruktury... Kdo by z toho byl nadšený? A kdo ho donutí, aby dobrovolně na routeru vzal IPv6, zabalil do IPv4 a u zákazíka zase rozbalil, než se přirozeně obmění železo?
-
Ale no tááák. Právě ti malí ISP jsou na tom často nejlépe, protože to dělá někdo nadšený, kdo chce mít šestku doma. I kdyby ne, tak stejně ty krabičky, co kupuje už 10 let, šestku stejně umí (nehledě na to, že při jejich životnosti to už stejně 3x vyměnil, takže ta přirozená výměna už dávno proběhla). Stačí to nastavit.
-
M. (neregistrovaný)
Add vnitrofiremní provoz, pokud mám implemetováno vnitřně i IPv6 (třeba na ULA adresách), tak pak mám interní IPv6 provoz dneska majoritní, je ho 80+%. V IPv4 už je snad jen VoIP a video, plus pár starých tiskáren.
V sítích ISP - s tím MPLS jsme se nasmál. To plátí pro pár největších. Většina těch malých to poctivě routuje, protože nemá technbologii/lidi pro MPLS (a implementace MPLS v u nich oblíbném RouterOS není zrovna terno), takže musí řešit routing uvnitř své sítě, pokud přehlédu skupinu, co to má celé L2 switchované, maximáně segmenty přes VLANy, ale těch je menšina. -
Trident (neregistrovaný)
Aha. No koukám ze každý asi fungujeme v jiném rozměru. Mne stačilo když jsem byl rád že se sajty v USA zbavily ATM. Ono taky když si k vám zakos přinese malej dslam a vy nemáte žádnou jinou možnost než ATM tak zamrzi. Tohle je usa. Tam dozivaj vsechny historické IT technologie.
S tou MPLS siti nevím čemu se říká par velkých hráčů. Z celosvětového měřítka to není až zas tak malé cislo. U nás ruzovouckej, bublina, nadrazaci asi taky to už máš tři subjekty v bananistanu.
Na firmě jsem koukal ze na menší pobočky do stovek lidí a pár vyzkumaku není ani nakoupeno nic jiného, než ipv4 konektivita, shnila cisca od místní staré bely napojena přes hromádku T1ckovych spoju. A fakt netuším jak se s tím kluci sitovi poperou.
Většina vnitrniho trafficu je IPv4 a IPv6 jde jen ze serveru v DMZ a to jaksi nepočítám. Rozkaz zněl jasně. Musí to fungovat I na ty starý ipv4 telefony a vopicarny na převod TDMckovych rozhraní do ip. -
MilanK (neregistrovaný)
Tohle jde ale řešit pomocí šmíruňk serveru s pevnou IP adresou, kdy jedna IP zvládne kontrolovat data tisíců domácností a při tom pořizovat "big data". Takže v zájmu prodejců IoT je udržet IPv4, aby měli "důvod".
Výrobcům IoT bude debata IPv4 vs v6 nejspíše úplně jedno, protože pro ně je jednodušší napsat hloupého klienta na Android/iOS/WhatEver a sofistikovanější zpracování dat provádět na svém serveru (a současně sbírat big data, pochopitelně). Zkuste se mrknout na většinu nových hraček do domácností na Kickstarteru - z těch, co mne poslední dobou zaujaly, všechny vyžadují pro fungování šmírovací server. Ti hodnější výrobci plánují zveřejnit API - ale k tomu serveru, nikoliv k hračičce do domácnosti. Čest světlým výjimkám.
-
Filip JirsákStříbrný podporovatel
Aneb jak dát nenápadně najevo, že nevíte, o čem je řeč… Protokol IPv5 nikdy neexistoval.
-
Filip JirsákStříbrný podporovatel
Kód 5 v hlavičce IP protokolu byl přidělen protokolu ST, jak správně píšete, ale to nebyl protokol IPv5.
-
Filip JirsákStříbrný podporovatel
Neprosadí, protože v dohledné době žádný nástupce IPv6 nebude. On totiž zatím nikdo nepřišel na to, jak to dnes udělat výrazně lépe. Akorát v internetových diskusích je spousta nápadů, jak to udělat výrazně hůře.
-
Unknown (neregistrovaný)
"On totiž zatím nikdo nepřišel na to, jak to dnes udělat výrazně lépe."
Pokud je ovsem potreba to delat nejak "vyrazne lepe". Nestacilo proste jen vzit to co funguje (IPv4) a protahnout adresu na 128 bitu? Az tohle nekomu dojde, tak se to velmi rychle nasadi bez ohledu na to zda se to jmenuje IPv6 nebo IPv17....
-
XD (neregistrovaný)
No tohle existuje a dokonce si to muzete prakticky vyzkouset, viz. http://ip45.org/
-
Jenda (neregistrovaný)
No dobře, není (mimochodem tyhle věci by bylo taky potřeba upravit protože počítají s 32b adresou -- a když už jste v tom tak předělat to aby z ARPu bylo ND a z DHCP DHCPv6 už takový rozdíl není :). Ale v čem je to navržené řešení lepší než současné IPv6? Umožňuje jednodušší implementaci v zařízeních (stačí jen trochu přiohnout současný IPv4 stack), jinak žádnou výhodu nevidím. A přitom podpora v zařízeních není to, co by nás brzdilo - IPv6 podporuje kde co už kdovíjak dlouho.
-
Unknown (neregistrovaný)
Je to slozitejsi.
Nevim jak na implementaci ale na pochopeni laiky je urcite snazsi. Z pusobeni v komunitni siti (ktera se snazila edukovat cleny) vim, ze lidi kteri horko tezko pochopi logiku fungovani IPv4 budou mit s IPv6 novy problém, ktery (prevazne Ti starsi) uz nerozchodi a padnou (v tomto smeru) zpet do stupne bezvedomych lam. A pochopeni technologii lidmi mi prijde v dnesni dobe zvlaste dulezite.
-
Filip JirsákStříbrný podporovatel
IPv6 samotný není o nic složitější, než IPv4 - rozdíl tam je opravdu jenom v délce adresy. Rozdíly jsou až v podpůrných technologiích - a to především v tom, že to, co se u IPv4 vyvíjelo živelně a není to považováno za součást technologie IPv4, je v případě IPv6 standardizováno od začátku a považuje se to za součást IPv6.
Obávám se ale, že to, co je u IPv4 jednoduché na pochopení, je dnes pro reálný svět stejně nedostačující. Do toho, co je potřeba znát k IPv4, je potřeba zahrnout třeba i NAT - a obávám se, že tím se složitostí dostáváme daleko za celý IPv6.
-
Filip JirsákStříbrný podporovatel
Ano, to je právě jeden z těch nápadů, jak to udělat výrazně hůře.
-
ebik (neregistrovaný)
No, mě to přijde místy přeinženýrované. Daleko větší chybou jsou podle mně ty dynamický zapouzdřovací hlavičky, který by měly routery umět rozparsovat všechny. (A obecným alogritmem to nejde, právě kvůli vámi zmíněné chybě.) Ostatní chyby se vyskytují většinou i v IPv4 světě, což ale neznamená, že jsme se z toho nemohli poučit a nasadit něco co odpovídá na dnešní problémy (nebo na problémy před deseti lety) a neřeší to problémy které tu byly (jen) před pětadvaceti lety (třeba ta autokonfigurace mi přijde zbytečně složitá, když tu máme DHCP, o kterém i poučení laici zhruba tuší jak funguje.)
-
Kolemjdoucí (neregistrovaný)
Můžete prosím hodit link na nějaký senzor, která umí SLAAC pro IPv6 a neumí DHCP(v4) klienta.
To čím argumentujete jsou, dle mého názoru, takové nepodložené báje zastánců bezstavové konfigurace, která se ostatně neujala ani v IPv4 (ani pro ty senzorové sítě). Složitost IPv6 stacku je taková, ze existence/neexistence DHCPv6 to už nezachrání.
-
specifikace se překvapivě dělá dřív než samotná implementace. A to obvykle podle stavu stávajících technologií. Psát specifikaci pro neexistující technologie je o ničem.
Takže ano, současné sensorové sítě mohou umět DHCP, nicméně v době, kdy IPv6 vznikala, byla poměrně jiná situace. Pro SLAAC nepotřebujete v podstatě vůbec nic, pro DHCP potřebujete mnohem složitější logiku (např. hodiny), která něco stojí.
-
j (neregistrovaný)
Routeru ve skutecnosti staci taky jen minimalni cast. IPv6 standardizuje hromadu veci, ktery jsou routeru u rite. Podstatny je, ze ty veci jsou nejak standardni => neni to jako u 4ky kazdej pes jina ves ...
Ve skutecnosti je implementace zakladni IPv4 funcionality na IPv6 standardu radove jednodussi, prave proto, ze je spousta veci sjednocenych a zjednodusenych doslova na dren. Zadny broadcasty, zadny arp, zadny dhcp, zadny miliardy pidisubnetu (v optimalnim pripade samo) ...
-
Kolemjdoucí (neregistrovaný)
IP se přiděluje všemu co je určeno ke komunikaci na protokolu IP a tak je to správně. To že se v ČR zhusta používá NAT není normální fungování internetu.
Že IPv4 adresy dojdou byla v roce 1974 naprosto neuvěřitelná věc, protokol byl předimenzován milionkrát nad tehdejší potřeby.
-
Rozdělování IP na veřejné a neveřejné a přístroje na potřebují a nepotřebují je největší zvěrstvo, které v hlavách některých lidí ip maškaráda napáchala.
Na přidělení IP zařízení, které to potřebuje, není nic špatného, naopak, je to tak správné. A pokud to zařízení nemá být dostupné odkudkoliv, tak se to zařídí na firewallu. Pokud někdo řeší problémy na jiné vrstvě, než vznikly, koleduje si o problémy mnohem větší.
-
Vanamond (neregistrovaný)
No, ve firmě s 100 IP zařízeními a IPV4 s NATem je konfigurace routeru na IPV4 na tři řádky - server a terminál server přístupné zvenku a třetí pro kompletní zbytek ( zvenku nepřístupné).
(+ konfigurace skupin v content filteru a skupin v SSL VPNkách, jasně, u IPV6 to není jinak)v IPV6 je to 100 řádků, neboť jsem nucen konfigurovat každou zmrvenou tiskárnu a to v návaznosti na polofunkční SLAAC, který kvůli demenci autorů musím kombinovat s dhcpv6 apod. A to tak, že to díky neexistenci NATu musím mít routované jen na jednu externí linku a nemohu to balancovat mezi více providery. A to celé musím komplet předělat, když si šéf změní providera.
A to nemluvím o tom faktu, na kterém je to celé zavěšeno, že obecně pro gamesy s IPV6 musím mít funkční IPV4, takže celkově nevidím žádný důvod pro existenci IPV6 ve firmě.
( jestliže po dvaceti letech vývoje je protokol IPV6 tak zoufale špatný a prakticky nenasaditelný, tak jej opravdu nepotřebuji ). -
M. (neregistrovaný)
Co se games týče, tak situace je také ve vývoji - viz Xbox one, ten jede hry skrz IPv6 a pokud IPv6 nemá, tak tuneluje přes Teredo, takže když je za x NATy má problém, když se mu podhodí přímo IPv6, spokojeně ožije. Jalko bonus je to navíc i balenoi do IPsec. (XBox 360 mebo PS4 IPv6 nepodporuje)
Ohledně firemního nasazení, tak tam se snad jede kombinace ULA adres pro vnitřní provoz, které jsou interní a nezávislé na změnách IPv6 konektivity providera a k tomu případně má zařízeí i globální IPv6 adresy, pokud konektivitu ven potřebuje (u nás je politika, že zařízení vyžadující spojení ven typu tískátrny a spol je zakázáno, všechny jsou v DMZ a dá se spojovat jen na ně z vnitřku firmy/VPNek).
Load sharing mezi víc uplinků (kde mám od každého jiný prefix) je možný ale dosti kompliovanější. My to máme nasazeno v koncových pobočkách v režimu, že různé VLANy používají růné prefixy od různých uplinků, takže každá část firmy jde jinou linkou a když daná linka vypadne, provádí se dynamický renumbering na tu fungující (k tomu mají zařízení i ty ULA adresy, které jsou poříád stejné).
-
Sten (neregistrovaný)
v IPV6 je to 100 řádků, neboť jsem nucen konfigurovat každou zmrvenou tiskárnu a to v návaznosti na polofunkční SLAAC, který kvůli demenci autorů musím kombinovat s dhcpv6 apod
Já jsem žádnou tiskárnu pro IPv6 konfigurovat nemusel, nastavily se samy přes SLAAC a dohledaly přes mDNS, ale používáme jen normální tiskárny, ne zmrvené ;-)
Polofunkční SLAAC mají tak akorát Windows. Všechny ostatní normální systémy umí i RDNSS.
A to tak, že to díky neexistenci NATu musím mít routované jen na jednu externí linku a nemohu to balancovat mezi více providery.
- Site-wide NAT existuje
- Balancování umí IPv6 by default tak, že vysíláte víc RA
A to celé musím komplet předělat, když si šéf změní providera.
Ano, když neumíte konfigurovat síť z RA, musíte to měnit všude.
obecně pro gamesy s IPV6 musím mít funkční IPV4, takže celkově nevidím žádný důvod pro existenci IPV6 ve firmě
Kvůli hrám je zbytečné ve firmě zavést IPv6. LOL!
-
j (neregistrovaný)
Viz nekde kolem, firewall s natem na ipv4 ma +- 3x tolik pravidel pro zajisteni tehoz jako firewall na IPv6. Pokud nekdo konfiguruje appky a cpe do nich IPcka, nabehne si pri prvni prilezitosti kdy bude potrebovat pripojit dalsi sit podobne postizenyho ...
Precislovat sit na dhcp = vsechno povypinat, precislovat sit na ra = zacit posilat misto staryho novej prefix.
BTW: Tech vic RA bude ale fungovat spis pseudonahodne, neni to zadnej rizenej balanc. Ten se dela routovanim.
BTW2: cenzore vis kam bez? Jo, presne tam!
-
Coze ? Cenzuru ? Pod kloboukem ? [Tri Veterani] (neregistrovaný)
Tak ty chces komunikaci bez cenzury ?
A uvedomil sis dusledky ? To by pak ale mohli lide rikat cistou pravdu, a klidne i nevybiravymi slovy.
A protoze se svinim nelibi kdyz je nekdo svinemi nazve => kazda spravna svine bojuje za cenzuru / politickou korektnost (a kazda spravna ovce zabeci podporu) ...
-
Trident (neregistrovaný)
Njn chlapi. To jsme se pred 20ti lety u PVTky o IPv6 na certifikacich neucili ze? Ale darovanymu koni... Sroubovat pro vary a okoli je docela dobrej dzob na to aby byly prachy ne nejaky lepsi reseni. Uz za mne jste byli dost nakontaktovany.
Pokud si to chcete balancovat mezi vic provideru tak si poridte vlastni ASko nebo PI adresy. Pro IPv6 ty adresy dostanete.
Pokud na to nemate, tak si dejte na konec nejakej tunel server a neremcejte pokazdy kdyz menite ISP. Naposledy si stejne pamatuju(leta pane to uz bude vic jak 10let) ze jste stejne meli nakou mizernou mikrovlnu takze jaka redundance pres litaci trpasliky... V miste stejne podle mapy siti optiku nemate a je tam jen blba metalika od O2. Pokud jste se tedy neprestovali k nadrazi protoze tam je jedina poradna konektivita v tom mem rodnem zapadoceskem bananistanu.Jak jsem byl na vas jeste nastvanej tak mi nekteri chlapi schazej... kurna... nostalgie...slza ukapla...
-
Petr M (neregistrovaný)
Tak tak.
Potřebuju komunikovat po síti -> připojím to k síti
Musím na té síti mít unikátní identifikaci -> přidělím tomu nějaký ID.
Potřebuju omezit traffic, aby byla rozumná latence na síti -> rozsekám to na segmenty a ty spojím nějakým zařízením, říkejme mu router (nebo repeater, bridge,...).
Potřebuju, aby některý zařízení v segmentu nebyly příztupný z venku -> zakážu ho na routeru.
Chci, aby to bylo bezpečný a nikdo se v tom nevrtal -> zakážu na routeru vše a povolím jenom to, co potřebuju. -
Jenda (neregistrovaný)
Jak „nepotřebují“? Potřebují IP konektivitu. Že jim můžeš dát privátní rozsah? _To_ vede k tomu plýtvání zdroji - protože musíš všude nastavit extra routování do toho privátního rozsahu, a když pak někdo bude chtít tisknout přes VPN ze sítě kde měl někdo ten stejný geniální nápad a zrovna použil stejný privátní rozsah, tak se z toho zblázníš.
Uvědomuje si tu ještě někdo absurditu tvrzení „neplýtvat čísly“?
-
zoudel (neregistrovaný)
Nadpis bulvarne uvadi, ze IP adresy definitivne dosly, ale z textu vyplyva, ze jen konci stav kdy se rozdavaly zdarma kazdemu kdo si o ne rekl.
Rovnez lze asi polemizovat se zaverem, ze IPv4 je mrtve. Podle google je pocet IPv6 klientu nekde pod 8%, v nekterych zemich sice 40%, jenze pocet IPv4 klientu je vsude 100%. Takze vam jen preju at si nekdy nesahnete na podobne "mrtve" rozvody elektriny.
IPv6 zacne rozumne fungovat az v okamziku kdy bude davat podstatny ekonomicky smysl, tj. naklady a mira opruzu s IPv6 budou mensi nez s IPv4. Zatim je IPv6 ciste domenou nadsencu a firem se zoufalymi prebytky penez. Postoj zbytku sveta je k IPv6 zatim velmi vlazny, coz lze v praxi pocitovat od vyvojaru, pres vyrobce HW az po ISP. Vsichni sice svorne tvrdi ze IPv6 "maji", nebo budou mit, jen neni radno to prilis pouzivat (zabugovane implementace, neschopnost plnit SLA atd.).
Ale celkove hezky clanek. Diky.
-
M. (neregistrovaný)
Ale jen pro ty, co mají android 4.3+ telefony s podporou 464XLAT, ne?
Jinak pěkný popis, jak ta IPv6 only s tím 464XLAT funguje je zde:
https://conference.apnic.net/data/37/464xlat-apricot-2014_1393236641.pdf -
j (neregistrovaný)
Proc? Na webu nakousnutyho jabka se da trebas dohledat, ze GSM je nepodporovana zastarala technologie. Tudiz velmi brzo zacnou prodavat founy, ktery to ani nebudou umet. Nasel sem pri hledani postupu jak vypnout 3G, nebot pri "cesky specifickem 100% pokryti" se z toho kramu nedalo telefonovat.
-
Sten (neregistrovaný)
464XLAT pro Android 4.3+. Od příští verze iOSu zřejmě bude IPv6-only i pro ně (jestli s 464XLAT nebo bez není jasné, ale všechny aplikace pro iOS budou od září muset umět fungovat v IPv6-only sítích). Jak to bude řešit Windows Phone, se mi dohledat nepodařilo, ale AFAIK stejně jako Verizon už vyžadují pro nové LTE telefony podporu IPv6-only (systému, zatím ne aplikací). Snahou T-Mobile je mít za několik let LTE bez IPv4.
-
j (neregistrovaný)
Aby ne, nikdo pri smyslech nehodla dlouhodobe provozovat vsechno 2x, ci spis 3x. 4ka bude do par let minoritni platforma, se kterou se BFU setka uz tak maximalne pres preklad. Sak TV uz taky nevysila analogove ... a za rok, ci dva budou vsici muset vyhodit i ty stavajici ... nebo k nim prikupovat dalsi krabice na t2.
BTW: firemni sit, ipv6 cca 25%. Soho cca 15% (nektery typy provozu jsou ale % na 6tce vyrazne vic). Jakmile to vseobecne preleze 30%, zacne se ipv4 likvidovat.
-
TP (neregistrovaný)
Podle nedávného vyjádření vývojářů apple (https://www.ietf.org/mail-archive/web/v6ops/current/msg22324.html) 464XLAT v IOS nebude. Bude zajimavé sledovat jak věc dopadne vůči aplikacím typu skype nebo whatsapp. Buď ustopí tvůrci aplikaci a začnou IPv6 podporovat (už by bylo na čase) nebo ustoupí apple.
ČLÁNKY DO MAILU