Vlákno názorů k článku
Letošní seminář IPv6 má program a podtitul deset let poté
od miho - Mám laický dotaz. Fakt to nešlo udělat jednodušeji?...
-
Mám laický dotaz. Fakt to nešlo udělat jednodušeji? Prostě přidat adresní prostor a vykašlat se na složitosti okolo? Aby se to dalo snadno implementovat v zařízeních. Abych nemusel studovat hromadu nudné síťařiny, která mě nezajímá, jen abch to rozchodil v homelabu. Aby mi mohl isp přidělit jednoduše pár adres jako v případě ipv4 bez subdelegování prefixu, které skoro nikomu z isp dobře nefunguje. Aby fungoval NAT.
Třeba by pak zavádění netrvalo 30 let?
-
Filip JirsákStříbrný podporovatelNešlo. Žádné složitosti, které by nebyly potřeba, tam nejsou. Naopak oproti IPv4 je to jednodušší.
-
Vaše tvrzení je v přímém rozporu s mým empirickým pozorováním. Dám 2 příklady.
1) Pro ISP je zjevně mnohem jednodušší poskytnout veřejnou IPv4 než IPv6 páč dávají paskvily typu ds-lite. Návody jak zprovoznit ipv6 u PODA/bývalé UPC/... po přepnutí modemu do bridge jsou sáhodlouhé a ne u každého funkční (závislé na kombinaci modemu a routeru, s levným ne-OpenWRT routerem, který si s IPv4 v takovém režimu poradí levou zadní máš většinou smůlu). Když se sejde správná kombinace směru větru, stavu přílivu a Merkur není zrovna retrográdní, tak to je navíc defaultně nebezpečné oproti defaultně bezpečnému IPv4 za NATem, kde si nasměruju jen ten port, který chci.
2) Proxmox server u OVH (podporovaná věc, mají na to i autoinstall). IPv4 zprovozní každý. Jen se základní znalostí síťařiny i bez návodu, pro ostatní s jednoduchým návodem: v rozhraní OVH se přiřadí virtuálním MAC adresám přidělené IP, v proxmoxu se nastaví tyto adresy jako statické, nastaví gateway a jede to. V samotných kontejnerech není třeba dělat nic. Na IPv6 jsou návody plné nějakých post-up /sbin/ip -f inet6 route add uvnitř kontejnerů a... nefungují. Fakt ne. Po několika hodinách pokusů a študování záludností IPv6 jsem to vzdal.Nějak tu jednoduchost tedy nevnímám.
-
To, co považujete za normální, ze světa IPv4, rozhodně v pořádku není. Různé "rovnáky na vohejbáky", nejsou u IPv6 potřeba a vše jde řešit víc přímočaře.
DS-Lite je pouze přechodový mechanizmus, který jednou přestane být potřeba. To, co popisujete, je spíš problém implementace, nikoli standardu IPv6.
S názorem, že NAT je "dafaultně bezpečný", bych byl opatrný. Říkáte, že si na IPv4 nasměruju port kam chci... A co když veřejnou IPv4 nemám, protože poskytovatel jich nemá dost pro všechny zákazníky? Co když chci mít z internetu přístupný NAS, web server na Raspberry Pi a třeba ještě meteostanici? Pro NAS můžu mít standardní port pro HTTPS 443/tcp, ale ostatní musím používat na nestandardních portech, takže třeba 80443 a 81443. Komplikuju tím přístup IT-nezdatným uživatelům a sám si musím zbytečně pamatovat, který port je k čemu.
To ani nemluvím o tom, že zevnitř sítě budu na tyto služby chodit přes jinou adresu než z venku. -
Smazaný profil
to je sice hezký, ale žijeme v reálnym světě a člověk s jednou přidělenou veřejnou IPv4 na tom může být v některých scénářích líp než když dostane jenom /64. btw více web serverů na standardním portu na jediné veřejné IPv4 přes kterou se leze zevnitř i zvenčí s těmi rovnáky na ohejbáky řešitelné nějak je, ale s /64 když budu chtít víc sítí tak jak to autoři geniálně vymysleli mám bez rovnáků smůlu.
-
Máte pravdu, že /64 je neskutečně omezující, ale jsou i poskytovatelé, kteří přidělují /56. Pokud bych si měl vybrat mezi jednou veřenou IPv6 nebo /56 IPv6, tak bez váhání berz IPv6.
Ano, přístup zvenčí i zevnitř přes veřejnou IP řeší NAT hairpinning, ale nepřijde mi to jako dobré řešení.
Jak byste chtěl řešit více web serverů za jednou veřejnou IP, aby byly na standardních portech?
-
Já ale netvrdím, že máme zůstat u IPv4. Tvrdím, že se měl IPv4 rozšířit jednodušeji. Zachovat všechny principy jen ke stávající adrese přidat 2 bajty prefixu třeba. IANA by měla dost adres na přidělování, ISP by neměl důvod škudlit - hlavní problém vyřešen. Úprava IPv4 stacku v OS a aktivních síťových prvcích rozhodně menší, změny v DNS, DHCP, ... drobné. Jediná věc k přeučení, že subnet mask má o dvě 255. zleva navíc.
Místo toho máme megalomanství, pač každý prý potřebuje /64 ale dočkáme se ho buhvíkdy.
-
Filip JirsákStříbrný podporovatel
Ty principy, které se z IPv4 nezachovaly, se v IPv6 zjednodušily. Nebyl důvod to dál udržovat složité, když se ukázalo, že to jde jednodušeji.
V tom vašem případě by úpravy stacku by byly úplně stejné, jako s IPv6, to samé DNS, DHCP.
To, že by se adresy rozšířily o menší počet bajtů, by vůbec ničemu nepomohlo. Způsobilo by to jedinou věc – že už teď bychom řešili nový protokol, který by měl více adres. Tím pádem by se na IPv6 přecházelo ještě méně, protože proč by někdo přecházel na IPv6, když už by se vědělo, že nestačí a že se vyvíjí nový protokol.
-
Tvrdíte, že v ideálním světě s ideální implementací s ideálními lidmi by to fungovalo krásně a jednoduše... a já vám věřím. Za těch podmínek by i komunismus možná fungoval ;-) V praxi je ale ta idea, o které tvrdíte, že je jednodušší... mnohem složitější. Můžete to svést na nedokonalost světa. ale jen takový máme.
Tak přidejme bajty 4, ať nežeru ;-) pokud teda tvrdíte, že 2^48 - nějaká režie, tj. nějakých 20k adres na člověka, nestačí.
-
Šestka funguje dobře i v reálném světě. To, že je někdo matlák a naimplementuje to špatně, není chyba protokolu. T-Mobile má bez problémů použitelnou implementaci.
O2 u svého xDSL přiděluje routeru adresu z rozsahu 10.0.0.0/8, který je určen pro privátní adresy, místo toho, aby použil shared addr space 100.64.0.0/10, jak má být dle RFC. Když se trefíte do stejné adresy, máte problém. Viní z toho někdo protokol IPv4? Ne. Viníkem je O2.
V čem má být výhoda, že se adresa roztáhne na 48 nebo 64 bitů místo 128?
-
Filip JirsákStříbrný podporovatel
miho: Ne, já netvrdím nic o ideálním světě. Já jsem napsal, že ty problémy, které jsou s nasazením IPv6, jsou problémy s nasazením nového protokolu. Takže by úplně stejné problémy byly, i kdybyste adresní prostor IPv4 rozšířil jenom o jediný bit. Protože by to pořád byl nový protokol.
Vy se pořád tváříte, že problémy jsou způsobené tím, o kolik bajtů se adresní prostor rozšířil. Ale to je úplně jedno. A nedává smysl přidávat teď trochu a za pár let zase. Problém je s přechodem na nový protokol (jak plyne i z vašich příkladů), takže je logické přejít teď na nový protokol, na který pokud možno nebudeme muset sáhnout už „nikdy“ (tj. kam až si dokážeme představit). Proto se teď například z adresního prostoru IPv6 záměrně používá jen malá část. Protože když se ukáže, že je to špatně, máme pořád v adresním prostoru IPv6 (a tedy se zachováním stejného protokolu, což je to nejdůležitější) spoustu prostoru na jiná řešení. (Mimochodem, na tomhle končí všechny návrhy na to, že by se „jen rozšířil“ adresní prostor IPv4 – tedy že by se do IPv4 paketů přidala další hlavička, která by upřesnila adresu. Aby bylo možné tohle realizovat, bylo by potřeba k tomu v IPv4 vyhradit nějaký prostor – a v době, kdy se začal řešit nedostatek IPv4 adres, už takovýhle prostor v IPv4 neexistoval.)
Zdá se, že nechápete, k čemu adresní prostor slouží. Není podstatné, kolik adres vychází na člověka. To, na co padne nejvíc adres, je nevyužitý prostor – tedy ty adresy, které jsou někam přidělené, ale kvůli rozumné implementaci routování se nevyužijí.
Stále se na to díváte jen z pohledu koncových domácích zařízení, jenže internetový protokol musí také zvládat páteřní routery.
-
Já netvrdím, že problémem je počet bajtů adresy navíc. To jste si domyslel a upnul ste se na to, jako by na tom záleželo. Já tvrdím, že se měly zachovat původní (prý složitější) principy aby byl přechod ve výsledku snazší. Kdyby byla prostě jen delší adresa a všechno ostatní by bylo zachováno, tak by z principu byla konfigurace stejná, jako v IPv4 až na tu delší adresu, delší gateway a delší subnet mask.
A nemluvte mi, že z hlediska implementačního je to stejné. Už samotný SLAAC musí být opruz implementovat. O těch skupinových multicast adresách ani nemluvě.
-
Filip JirsákStříbrný podporovatel
Já tvrdím, že se měly zachovat původní (prý složitější) principy aby byl přechod ve výsledku snazší. Kdyby byla prostě jen delší adresa a všechno ostatní by bylo zachováno, tak by z principu byla konfigurace stejná, jako v IPv4 až na tu delší adresu, delší gateway a delší subnet mask.
Ano, to píšete už poněkolikáté. A já se poněkolikáté ptám, co je tedy podle vás konkrétně na IPv6 jiného.Už samotný SLAAC musí být opruz implementovat.
Tohle nahrazuje ARP a DHCP. SLAAC je jednodušší než ARP+DHCP. I ve vašem řešení by bylo nutné to implementovat. Vy si myslíte, že implementace nějakého ARPv6+DHCPv6 by byla jednodušší, než implementace SLAAC?O těch skupinových multicast adresách ani nemluvě.
Jaký problém v tom vidíte? -
ARP je nahrazen NDP. ARP fungoval skvěle s libovolným subnetem. NDP funguje jen s /64 subnetem. To je jedna konkrétni věc, která je jiná a zcela jasně horší protože na některé věci kvůli tomu ani /64 nestačí páč se to nedá subnetnout a musím tedy doufat, že dostanu bloků víc. A kromě toho to je složitější.
-
Filip JirsákStříbrný podporovatel
Když je nový protokol založen na tom, aby už nikdy nebyl problém s nedostatkem adres, nedává smysl navazující protokoly založit na předpokladu, že máte nedostatek adres. Pokud nedostanete od ISP dostatek adres, je to chyba toho ISP a ne protokolu. NDP je lepší, protože je to založené pořád na stejném protokolu IPv6, nepotřebujete k tomu úplně nový protokol (jako ARP).
-
Filip JirsákStříbrný podporovatel
miho: Ne, neshodneme. Předpoklad, že máte dostatek IPv6 adres, je slučitelný s realitou. To, že je ISP zmatený a nedá vám dostatek IPv6 adres, je chyba ISP a ne chyba protokolu. Původně jste tvrdil, že jsou některé věci v IPv6 komplikované. Tady je to ale tak jednoduché, jak jen to může být. Nikdo netvrdil, že je to úplně bez komplikací – ale řešení je to nejjednodušší možné, tedy vyžádáte si větší blok IPv6 adres od ISP. Pořád je to jednodušší řešení, než navěky zaplevelit protokol obezličkami kvůli tomu, že vám ISP dal málo IP adres.
-
Filip JirsákStříbrný podporovatel
bez přezdívky: Víte, v čem je problém? Že vůbec netušíte, o čem píšete. Kdybyste totiž chtěl začít popisovat, jak konkrétně by vypadalo to „rozšíření adresy o pár bajtů“ a které jsou ty komplikované věci, které v IPv4 nejsou, dospěl byste k IPv6 – nebo spíš k něčemu mnohem složitějšímu.
Není vám to nápadné, že pořád někdo píše o tom, že je v IPv6 přidaná spousta věcí navíc, a není schopen přitom pojmenovat ani jedinou tu údajně přidanou věc?
-
Co je na IPv6 tak složité oproti IPv4?
Adresa se roztáhla na 128 bitů a zjednodušila se hlavička. Zjednodušení je i to, že koncová síť má být /64. Velké plus jsou LL a ULA adresy a také možnost mít na jednom rozhraní více adres.
Místo ARP máme NDP. Je v něčem horší nebo složitější?
Stavové DHCP zůstalo, přibyla možnost bezestavové konfigurace přes SLAAC.
Co se podle vás tak zásadního změnilo v DNS?
Pořád nevidím nic složitěšího. Mám pocit, že nechuť k IPv6 spíš způsobuje zápis pomocí hexačísel.
"Místo toho máme megalomanství, pač každý prý potřebuje /64 ale dočkáme se ho buhvíkdy."
Chcete tvrdit, že prefix koncové sítě /64 může za pomalé nasazení IPv6?
-
Filip JirsákStříbrný podporovatel
Ani jeden bod se netýká protokolu. Obojí se týká implementace, konkrétně pravděpodobně toho, že IPv6 ještě není považován za běžnou věc, takže se tolik nedbá na to, aby nastavení bylo snadné. Což by se ovšem týkalo jakéhokoli nového protokolu.
-
BobTheBuilderStříbrný podporovatel@miho: Pro ISP je zjevně mnohem jednodušší poskytnout veřejnou IPv4 než IPv6 páč dávají paskvily typu ds-lite.
No nevím, po přechodu na VDSL (T-mobile) IPv6 začalo fungovat celkem slušně. Jako tak, že nikdo si ničeho nevšiml.
Další přechod, UPC (DS-Lite) to samé.
Zprasený firmware routerů je jiná věc (exUPC): ale to se týká i IPv4. Např. nemůžete změnit subnet vnitřní sítě buď vůbec, nebo ano, ale nefunguje port mapping NAT (veřejná IPv4 - pro mapování používají natvrdo 192.168.0.x). Bridge mode u Vodafone Station není vůbec, u Compalu zařízne tunel na 20mbit... Tohle třeba byl hodně velký problém u manželky, která měla VPN do práce - ovšem taky u UPC.
Vidíte - problémy nebetyčné a vůbec se netýkají IPv6!
Ale ne, nepropadejte panice, u IPv6 se taky něco najde, a v neposlední řadě to, že mobilní síť Vodafone vůbec IPv6 nemá, takže z ní se domů nedostanete. -
Problem u OVH je ve zprasene implementaci IPv6 u OVH. A vlastne i IPv4 u OVH, pokud nekde musite nastavovat nejake MAC adresy.
V normalnich resenich se pro kontejnerizaci i virtualizaci vytvari uvnitr hostitelske node samostatna L2 sit. Tu musite nejak adresovat.
V pripade IPv6 tak, ze nadrazeny router na hostitelskou node naroutuje nejaky blok adres (treba /56) a vy mensi blok (napr. /64) z tohoto bloku pridelite na onu L2 sit pro kontejnery/virtualy. Totez plati pro nektere VPN servery (OpenVPN, Wireguard v tomhle pripade mam overene).
Pokud nepotrebujete na virtualni siti SLAAC, funguji dobre i mensi site (napr. /96). Napr. rozjet IPv6 v docker kontejnerech jde na AWS, Google Cloudu nebo treba u Hetznera, kde jsou routovane prefixy dostupne, celkem dobre.
OVH to ma cele roky blbe...
-
Prave kvoli takymto ‘laickym’ dotazom to meska - nebudte laik, trosku si uvedomte binarnu, decimalnu a hexa sustavu a uvidite vsetko jasnejsie. Teda nic v zlom - ale ak by ste v minulosti bol chovatelom koni a vyrobcom konskych povozov, a nepochopite princip a vyhody motora, tak bohuzial casom zaniknete a skrachujete. A slavny NAT nie je nicim inym, ako stiplave korenie hodene do konskeho zadku, ale nie je trvalym riesenim nizkej konskej rychlosti, hospodarnosti atd… Apropo: “pridat adresny prostor..” - Co tym myslite? ze zrazu vyhlasit, ze broadcast nebude 255.255.255.255 , ale napr 512.512.512.512, a vsetko pod tym adresovatelne endpointy? :)
-
Filip JirsákStříbrný podporovatel
Dotaz byl na to, zda to nešlo udělat jednodušeji. To akademické cvičení je implementačně podstatně složitější.
-
L.Stříbrný podporovatel
Jenže ony jsou různé složitosti:
1) Složitost implementace v síťových prvcích
2) Složitost postavení IPv6 sítě na zelené louce
3) Složitost převedení IPv4 sítě na IPv6
Složitost ad 1 má IPv6 opravdu nízkou.
Složitost ad 2 taky celkem jde, byť bez NATu jste více závislý na externích faktorech, viz zmiňované problémy s tím, že vám někdo přidělí /64, takže si nemůžete udělat interní síť a nejede přes to vlak.
Problém je ale složitost ad 3, kde vás IPv6 nutí prakticky zahodit všechno, co jste měl a udělat to úplně znova, což je pokud ne přímo složité, tak dost pracné. A to je důvod, proč konverze IPv4 na IPv6 probíhá tak pomalu.
Můžete se stále tvrdit, že to tak není a že za pomalým nástupem IPv6 je tajné spiknutí ISP nebo co, ale je to jako tvrdit, že ten zelený čtvereček je ve skutečnosti červené kolečko.
17. 5. 2022, 10:11 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Váš komentář k 2 je nesmysl. NAT není nic, co by bylo do IPv4 vestavěné, je to hack. Úplně stejný hack můžete udělat s IPv6 – ten protokol vám v tom nijak nebrání. Jenom to prostě nikdo nedělá, protože je to jen zbytečná komplikace.
Ad 3) Ano, tohle je pracné. A bylo by to stejně pracné, ať by ten nový protokol vypadal jakkoli. Protože ta pracnost není daná vlastnostmi nového protokolu, ale faktem, že potřebujete provozovat dva protokoly vedle sebe.
Můžete se stále tvrdit, že to tak není a že za pomalým nástupem IPv6 je tajné spiknutí ISP nebo co, ale je to jako tvrdit, že ten zelený čtvereček je ve skutečnosti červené kolečko.
Ale já nic takového netvrdím. Já tvrdím jenom to, že tohle je důsledek zavádění nového protokolu. A byly by úplně stejné problémy se zaváděním jakéhokoli jiného protokolu. Vlastně ne – pokud byste se pokoušel zavádět něco jako IPv4v2, což jsou časté návrhy, bylo by to ještě daleko složitější. Protože by to byl nový protokol, způsobilo by to stejné problémy – ale navíc byste měl ještě problémy s tím, že by se vám to míchalo se starým protokolem. Takže byste to musel pracně rozlišovat, a kdybyste udělal nějakou chybu, rozbilo by vám to nejen nový protokol, ale i původní IPv4.
ČLÁNKY DO MAILU