Mi a helyzet az ipv6 támogatással?

Előjáróban: Nem egy konkrét problémát szeretnék megoldani, csak meg akarom érteni mi van a dolgok hátterében. Kb megoldásom van, az alábbi "problémaleírás" csak témaindító :)

---

A topicot azért nyitottam, mert a tervezett HUP leállás témájában szóba került egy IP cím váltás, majd Zozz kommentje, miszerint: "Az IPv6 konfigurálás kifelejtődött...". Oda nem akartam szemetelni, de a kérdés (ismét) felmerült bennem, miszerint: Mégis mi baj van az ipv6-tal?

Egy éve a T-nél vagyok előfizető (tudom) és a szolgáltatói routert használom (tudom). Bekötés után szembesültem vele, hogy a weboldalak nagyon nyögvenyelősen töltenek be. Addigra már tudtam a megoldást, letiltottam a gépemen az ipv6-ot, és azóta lényegében nincs gond. Hasonlóan szívtam egyszer a UPC-vel is, amikor a ConnectBox-ot kaptam tőlük. A jelenség hasonló volt, a megoldásra én akkor nem jöttem rá, a szolgáltató se tudott segíteni, lényegében a szerencsének köszönhető, hogy amikor (mindettől függetlenül) kértem a privát IP-t, kikapcsolták az ipv6-ot is az előfizetésemen. Mondanom se kell, hogy onnantól sokkal jobb lett a helyzet.

És most, hogy belegondolok fiatal siheder koromban is mint ha alap lett volna azzal kezdeni a friss telepítést, hogy az ember blacklisteli az ipv6-os modulokat...

Szóval, hogy van ez? Mit tudtok erről a jelenségről? Más is tapasztalja? Mi állhat a hátterében? 

Btw, ugyanezeken a hálózatokon Windows-nak semmi baja nem volt...

Hozzászólások

Mai napig úgy állítok be mindent, h ipv6 off. :) Itthon digi van, elvileg működnie kell, de inkább kiirtottam.

igy van, NAT -olni mindig joval egyszerubb marad, annak az 1% -nak kb. akinek szuksege van (fix) publikus cimre, igy mindig jutni fog. ez a reteg akinek egyaltalan szuksege van publikus IP -re nagyon szuk, az emberek 99%-nak kimerul az Internet abban, hogy bejon a Facebook...a munkahelyi kliens VPN, ami altalaban mar SSL VPN legyen az barmelyik gyarto implementacioja is, mukodni fog NAT mogott is, igy mindenki boldog a szolgaltatokkal az elen, akik egy vagon penzt sporolnak a NAT-al.

FBK

Ok, de ez az összeg csak dolog kisebbik oldala. Ugyanis be kell vezetni v6 ot. Eszközök kellenek, konfolni kell, új problémák merülnek fel, új eljárások vannak/lehetnek. Képezni embereket stbstb.

Ezek azok a dolgok amik sokba kerülnek. A v4 már ezer éve megy stabilan, megszokták, tudják milyen gondok lehetnek, nincsen nagy meglepi stb. Minden fos eszköz támogatja viszonylag jól :D

Fedora 31, Thinkpad x220

A IP kapcsán korlátos a tudásom, ezért javíts ki, ha tévedek!

Az IPv6 és IPv4 között a tényleges eltérés az, hogy a címet az egyik 4 míg a másik 16 byte területen ábrázolja, de minden másban lényegében megegyező módon működnek az egyik és a másik szabvány szerint is az eddig megszokott dolgok. Ezt szerintem igazolja az is, hogy ha egy eszköz "érti" az IPv6-os címeket, akkor lényegében ugyanazon hálózaton, azonos módon működik, mint IPv4 címmel. Ez nekem azt jelenti, hogy kb. Mondom kb. ugyanazok a jelenségek fognak előkerülni IPv6 esetén is, csak "csúnyább" a cím human readable formátuma. 

Ergo innentől indulva - ha igaz, amit fent írtam! - az átállás csak akarat kérdése. Egyszerűen el kell dönteni pl. hogy a top level vagy ha úgy jobban tetszik a root névszerverek 2025 december 31-én fognak utoljára feloldott nevekre IPv4-es címeket - és fordítva is - adni válaszul és pl. 2021 január 1-től tökéletesen lekezelik az IPv6 forgalmat. Ha ezt meghirdeted, mindenki ész nélkül elkezd IPv6-ra átállni. Kényszerítő erőt kell alkalmazni. Ilyen erő utoljára a 2000-es "probléma" volt. 

Ha az első bekezdésben az ismereteim hiánya miatt nem igaz az alapvetés, akkor tárgytalan a második bekezdés.

Igen nagyjából, ugyanaz, de azért van pár különbség. Ha jól tudom az android mai napig nem támogatja a DHCPv6 ot. Vagy pl.: user beszól, hogy nem megy a face ? Akkor eddig ipv4en nem ment, most akkor mehet a matek hogy v6 on nem megy? v4 en nem megy stb. Szóval csak így kapásból már plusz gond lehetőség. Holott igazából nagyobb előnnyel az ügyfél számára nem jár a v6. Neki mind1 hogy v4 vagy v6 on de bejöjjön a facse.

Fedora 31, Thinkpad x220

Oké, az android jelenleg nem támogatja...de ha van kényszerítő erő, akkor elkezdi majd támogatni. Az ügyfelek számára is van előnye, hogy mondjuk háztartásonként nem egy IP-jük van, gondoljunk csak a robbanás előtt álló okos otthon piacra. Átmeneti időszakban meg úgy, mint most, paralell kell mennie a kettőnek.

gondoljunk csak a robbanás előtt álló okos otthon piacra

Jó lassan robban :D Ez azért erősen marginális %, és jelenleg is v4 en oldják meg. Sőt lehet sok mikrokontrollerben lehet még a v6 stack sincsen megvalósítva, hogy spóroljanak. 

Fedora 31, Thinkpad x220

Mert nincs rá kényszer, hogy váltsanak. Olvasd el a hozzászólásom minden részét. Ami pedig az okos otthonok kérdését illeti, nem magyarország a minta. És valóban most úgy tűnik, hogy jó lassan robban. Ezért írtam azt, hogy robbanás előtt álló. Az ugye jövő idő, ami a jelenben tűnhet lassúnak is, bár inkább nem létezik. :) 

Hasogassuk a szőrszálat! :D

Miközben nyersz valamit azzal, hogy engeded a BYOD-ot telefon szinten, számtalan gondot veszel vele a nyakadba. Elhiszem, hogy vannak nyakatekert use case-ek, de az én véleményem az, hogy nincs helye a céges hálózaton ilyesminek. Hogyan működik nálatok a karanténozás? Pl. valaki behoz egy Android 4.x full sebezhető, tele malware-es valamit a hálózatra?

trey @ gépház

"valaki behoz egy Android 4.x full sebezhető, tele malware-es valamit a hálózatra" - Céges eszközről volt szó. Ilyet már nem kap. És ha van céges mobilja, amin egyébként a hagyományos telefonálás mellett viber/slack/matrix/satöbbi kommunikációt is folytat a munkatársakkal, akkor azt miért is para beengedni cert-tel azonosítva egy céges wifire, ahonnan a legfontosabb dolgok (pl. mail szerver) elérhetők?
Egyébként meg a BYOD-ra lehet (és kell) korrekt szabályozást _is_ csinálni, és annak megfelelően eljárnva csak az elvárásoknak megfelelő eszközre kap a dolgozó certet, illetve az a MAC lesz beengedve.

Igen, lehetne azt mondani, hogy tessen mobilnet+vpn, vagy publik wifi+vpn, de nincs mindenkinek vpn hozzáférése, és nem is cél mindenkinek osztogatni - viszont olyannak is kell bárhol (bent a cégen belül tartózkodva) látnia a belső ticketinget, levelezést, chat-et, akinek egyébként munkaidőn kívül nem kell távoli elérés.

Csak ha a dolgozó egyszer az egyik irodában ük, másszor meg fél napot tárgyalók között mozok, este meg a projektszobában van dolga, akkor azért elvárt, hogy wifi-t tudjon megfelelő megbízhatósággal és biztonságosan használni.

No erre a wifi-re, a laptophoz hasonló (cert az AD-s userhez plusz MAC) authentikációval egy céges Android-os eszköz nem igazán értem, miért nem mehetne fel? Ha meg paranoidandroidfóbia van, akkor tényleg nem marad más, mint guest wifi meg vpn.

Gondolom a tárgyalókban lévő fizikai végpontokat is csak akkor és csak addig meg csak arra a vlan-ra kattintjátok fel, amikor/ameddig/amelyikre kell.

Ennyire azért nem durva a helyzet, de lássuk be elegáns lenne. ;)

Cert alapon authentikáló wifi, ami nem direktben a "melós" vlan-ba rak bele teljesen vállalható megoldás egyébként.

Nálunk az a döntés született, hogy a telephelyen a wifi fizikailag független az intrától, egy sima modem mögött van mintha a saját előfizetőnk lennénk. :)
Nem kell extra tűzfalazás, vlanos trükközés, bár akár az is lehetne egy irány. Csak ahhoz szabályok kellenének (ki merre nézhet), ami alól aztán lesznek kivételek... meg ott van ennek a nyilvántartása, fluktuáció kezelés... gondolom nem kell sorolnom. Nyilván vannak sokkal szofisztikáltabb megoldások, de ha egy problémára több jó megoldás is van, akkor a legegyszerűbb a legjobb. ;)
 

"A megoldásra kell koncentrálni nem a problémára."

Tehát ha bemegyek egy tárgyalóba, akkor nincs wifi, de be tudom dugni a laptopomat olyanlukba, ami valamelyik belső hálózatra "lát rá"... És ha a tárgyalóban 5-6-8 ember ül, és mindegyik előtt ott a nótos, akkor van 5-6-8 "luk" a falban, és ugyanennyi kábel, hogy a gépeik lássák a szükséges dolgokat.

Nálatok egy munkára nem használatos wifi van, ami akkor lehet jó, ha nincs igény mobilis munkavégzésre laptoppal.  A szabályozás relative egyszerű: a certes wifi-ről az alap hálózati szolgáltatások elérhetőek, de pl. a "külvilág" csak korlátozottan (akár a desktop zónánál szigorúbb korlátozásokkal). A fluktuáció kezelése egyszerűen megy: a certje és a teljes wifi-s auth az AD-s useréhez van kötve. usere letiltva, wifi-s certje visszavonva, ennyi meg egy bambi.

Szerintem nem is fogja támogatni, mert a dhcpv6 másképp van kitalálva mint a v4, inkább arra van kiélezve, hogy helyi hálózati csomópontokank (jellemzően router) osszon ki IP tartományokat (NEM egyedi címeket), amelyeket a hálózati csomópont oszt tovább RA/ND-n.

Az globális internetforgalom 30%-a IPv6, tehát átgondolnám a "az IPv6 meg mindig nem all keszen a vilagszintu bevezetesre" kijelentést. Én legalább 2-3 éve használok IPv6-ot szinte minden gépemen, elsődlegesen 6to4 tunnel formájában, de direkt szolgáltatótól kapott címmel is használtam és mindig tökéletesen működött.

Nálam kettős a helyzet. UPC és DIGI is van.

IPv4 UPC felé megy IPv6 DIGI.

Minden oldal ami IPv6-os az ott is megy - jön. Semmi gondom nincs vele.

Nekem egyelőre only v4 az otthoni netem, de hoztam haza v6-ot. Semmi gondom vele. Csak a hup.hu nem bírkózik meg vele :D

Fedora 31, Thinkpad x220

Sose értettem, hogy ha van lehetőség (Natív) IPv6-ot használni, akkor miért nem élnek vele az emberek. Miért ragaszkodik, még mindig mindenki az IPv4-hez? Még minidig az az ősrégi hibás berögződés van, hogy az IPv4-es NAT megvéd minket a gonosz internettől. Sokkal több előnye van az IPv6-nak, mint az IPv4-nek. A 2008-as Pekingi olimpián is használták már, és az nem tegnap volt. Ha van mód és lehetőség, akkor tessék használni az IPv6-ot.

http://www.hit.bme.hu/~lencse/publications/IPv6-konyv.pdf 

+1

Kertem volna Telekomnal serverhez ipv6ot, kozoltek, hogy masik vlanon van, igy masik uplinket kell kernem, ami legolcsobb esetben is 6000forint + afa.

Penzbe kerul, munka van vele, es semmi ertelme nincsen.

Majd ha chrome ki fogja irni, hogy nem biztonsagos weblap, mert nem erheto el ipv6on is, na akkor lesz itt valtozas, vagy google hatrebb sorolja emiatt.

"Majd ha chrome ki fogja irni, hogy nem biztonsagos weblap, mert nem erheto el ipv6on is, na akkor lesz itt valtozas, vagy google hatrebb sorolja emiatt."

Az még odébb van, egyelőre szégyenszemre a google compute engine sem támogatja a ipv6-it a VPS-eken.

Fedora 31, Thinkpad x220

Azt azert tudomasul kell venni, hogy IPv6-nal nincs NATolas, tehat a routered mogotti minden kliensnek publikus IPv6 cime van, kivulrol elerhetove valik minden (is). Ezzel szemben IPv4 eseten csak a routernek van publikus cime (az se feltetlen), ezert kivulrol csak azon szolgaltatasok elerhetoek, amikhez portforwardolsz a routeren.

Igy aztan IPv6-nal sokkalta fontosabb a jo firewallozas (a routeren).

Szerencsere openwrt alapbol tartalmaz egy halom firewall rule-t IPv6-ra. Bizom benne, hogy az elegseges.

A forward láncnál kell a new csomagokat eldobni, és a bejövő (in) interfész pedig az internet-es (wan) interfész. Így vmennyire védve vannak a kliensek a külső kapcsolódásoktól (kísérletektől). Persze az alapelv továbbra is az, hogy mindent tiltunk/eldobunk, ami nem szükséges.

Van NAT ipv6-ra is már. Más kérdés, hogy nem szükséges. Elég ha a routerben megmondod, hogy belső hálózat felé semmi se mehet és kész. Hiába lesz publikus ip-je minden gépnek kívülről nem fogja elérni semmi. 

Annó 2x éve mikor az összes  gépnek publik IP-je volt senkise félt :D Bezzeg most, elkényelmesedtek a NAT tól :>

Fedora 31, Thinkpad x220

Elég ha a routerben megmondod, hogy belső hálózat felé semmi se mehet és kész.

Ha van a routernél ilyen beállítási opció. Induljunk ki egy átlagos userből. Szolgáltatói hardverrel nyomul, és a routert soha nem piszkálja. Számára jobb védelem az, amit a NAT az, mint az, ha van egy ilyen opciód, amit talán be tudsz kapcsolni ha értesz hozzá, és tudod, hogy van ilyen opció egyáltalán. 

> Sokkal több előnye van az IPv6-nak, mint az IPv4-nek

Ténylegesen van valami haszna az IPv6-nak, vagy csak azért jó, mert jó?

Szerk: bár igaz, hogy magam is sokat dolgozgattam a saját kis programkáim IPv6 kompatibilitásán, pl.: https://hup.hu/node/151955

Kieg: http://forum.index.hu/Article/viewArticle?a=64967307&t=9028250

Szerkesztve: 2019. 11. 24., v - 10:40

Én még nem tapasztaltam a szívás részét. Digi van nálunk ami eleve a saját Digi Wifi használatával 32 ip címet oszt gond nélkül. Vezetéken nem is figyeltem a címek számát lehet a szokásos. Az is igaz hogy ahol tehetem, ott IPv6-s nameserver-t használok.

Az IPv6-s nameserver ugyanúgy szolgáltatja az IPv4-s címeket ha csak az van. Sőt az eszközökben késleltetés is van beállítva az AAAA címek javára. Lehet ezt érezte a topic nyitó, de ez a folyamatos napi használat mellett kikopik. Esetleg Dnscrypt proxy vagy unbound.

# nano /etc/resolv.conf
nameserver ::1
(nameserver fe80::1%enp3s0)
nameserver 127.0.0.1
options edns0
# chattr +i /etc/resolv.conf

Nekem is T-s előfizetésem van, de nem tapasztalok hibát a weboldalak elérésénél IPv6 miatt. Van egy Chrome extension (IPvFoo) ami kiírja, hogy az aktuális weboldalt v6-on vagy v4-en érem el. Innen tűnt fel, hogy a HUP megint nem v6-on van.

Engem az érdekelne a kérdés felvetése után/alapján, hogy létezik-e (informatikus számára) érthető alapozó leírás az IPv6-ról. Mármint nyilván létezik, de amit valamelyikőtök ajánlana is.

Bevallom, én olvasgattam a témában többször mert érdekel, az itthoni Digi-n bekapcsoltam és lett is IPv6 címe minden belső eszköznek (némi kínlódás után, OPNsense-ben nem annyira egyértelmű nekem az egész IPv6 kezelés), de mivel az ismereteim nem terjedtek tovább, inkább csak a baj volt miatta (ahogy az eredeti kérdező is mondja), és egyszerűbb volt kikapcsolni, mint nyomozni valami értelmes tananyag után, erre szánható szabadidő hiányában.

Pedig engem nagyon érdekelne, ráadásul idővel muszáj is lenne komolyabban belefolyni, mert egy kis ISP-nél is dolgozok, és nyilván megjön majd az igény az IPv6 bevezetésére, és nem akkor kellene 0-ról kezdenem.

Tapasztalatom szerint a szolgáltatók ugyan bevezették sok helyen az IPv6-ot, viszont bizonyos DNS szerverek egyszerűen nem adnak AAAA rekordot, emiatt bekapcsolt IPv6-tal akadozik az elérés. Roppant egyszerű megoldással, én sehol nem használom a szolgáltató cuccát. 

--
openSUSE Leap 15

Egyrészt a dual stack általánossá vált. (Tehát mind ipv4 és ipv6 IP-d van.) Evvel nem mondtam újat. De ezáltal ipv6 nem kiváltó technológia, -mint ahogy indult- hanem párhuzamos.
Következésképp az IPv4 hosszabb távon kell, és olyan borzalmak születnek, mint a carrier-grade NAT. 
Továbbá a szolgáltatók sem  mindig tartják be az IPv6 ajánlásokat.
A Telekom korrekt IPv6-ot adott, de avval másmiatt szakitottam.
Pl. DIGI, ami /64-es prefixet delegál, /56 kellene.
És elveszi a prefixet hetenként, pedig az ajánlás állandó prefixet mond. (Nehogy má'  fix IP-d legyen!)
A szolgáltatáshoz adott doboz nem tud IPv6-ot. Bizonyára 5 centnyi RAM-ot lehetett vele spórolni.

Általában a SOHO routerek IPv6 támogatása gyatra. A felhasználók ismerete is hiányos.

És a nagy kérdés: Ki lesz az első NAGY szolgáltató, aki CSAK IPv6-on szolgáltat?

A nagyok példamutatóak, az IPV6 napon preferálttá tették az IPv6-on szolgáltatást. https://en.wikipedia.org/wiki/World_IPv6_Day_and_World_IPv6_Launch_Day
Ami aztán kliens oldalon okoz meglepetéseket.
És még egyebek.
Ami még eszembe jut: IPv6 nagyobb overhead, ami mobilon már számít.
 

https://carrier.huawei.com/en/technical-topics/wireless-network/VoLTE/2

Key VoLTE Technologies
Robust Header Compression (ROHC)

"ROHC compresses RTP/UDP/IP headers of voice packets and uses fewer fragmented packets to efficiently ensure the correct transmission of voice data packets and increase the cell edge coverage of voice services. ROHC uses different header compression algorithms for data flow based on different protocols. The ROHC compression efficiency varies based on the ROHC operating mode and changes of dynamic domains of packet headers at the application layer. Therefore, compressed packets appear in a variety of sizes. Packet headers can be compressed up to one byte, effectively reducing the size of voice data packets."

https://en.wikipedia.org/wiki/Robust_Header_Compression

In streaming applications, the overhead of IP, UDP, and RTP is 40 bytes for IPv4, or 60 bytes for IPv6. For VoIP, this corresponds to around 60% of the total amount of data sent. Such large overheads may be tolerable in local wired links where capacity is often not an issue, but are excessive for wide area networks and wireless systems where bandwidth is scarce.[1]

ROHC compresses these 40 bytes or 60 bytes of overhead typically into only one or three bytes, by placing a compressor before the link that has limited capacity, and a decompressor after that link. The compressor converts the large overhead to only a few bytes, while the decompressor does the opposite.

Miertis kellene IPv4-nek meghalnia? Vagy akkor a vezetekes telefonokat is le kellett volna mar lőni, mert van mobil? Miert hasznalunk meg belso egesu autokat, ha mar evek eve van elektromos? Stb, stb.

Miert kellene az ISP-nek csak IPv6-ot adnia? Ugyanigy... Diginek megvan a fix IP cime, sajat halon azt csinal, amit akar. Vegyel Vegyel magadnak Te is egy PI poolt...

A vezetékes és mobiltelefonok nem zárják ki egymást. Habár a gyakorlatban külön címtartományuk szokott lenni, mégis ugyanazt a címzési szabványt használják, gond nélkül tudják egymást hívni.

IPv4 és IPv6 együttélésére ez már annyira nem mondható el. Egyrészt azért, mert az IPv4 kifutott a címzési tartományból és egyre több népség fog kimaradni belőle, nem lehet igazságosan szétosztani. Másrészt azért, mert IPv4 és IPv6 hosztok nem tudnak minden probléma nélkül egymással beszélgetni. Ha még 2060-ban is IPv4-only lesz a sok kontent, akkor az ISP-knek még 2060-ban is kell IPv4-es címet IS adniuk (CGNAT-tal kevesebbre van szükség, de akkor is kell), és akkor még 2060-ban is az lesz a szopás, hogy ember/cég IPv4-es címhez jusson. Ha már minden hoszt (kontent és fogyasztó is) tud IPv6-ot, akkor tök fölösleges az IPv4.

Szerkesztve: 2019. 11. 25., h - 14:21

IPv6 validation for https://hup.hu

Tested on   Mon, 25 Nov 2019 13:18:22 GMT
AAAA DNS record   2a01:6ee0:1:201::bad:c0de
IPv6 web server   Apache/2.4.38 (Debian)
IPv6 DNS server   sns1.rackforest.hu,ns1.rackforest.hu

trey @ gépház

ha mar itt tartunk. UPC lakossagi net eseten, modem bridge modban, egy linux pc a router. public ipv4 cimet kapok dhcp-n (eleg regota ugyanazt), de ipv6-ot hogy kene kapjak? vagy az csak akkor van, ha a szolgaltato routeret hasznalom? vagy akkor se? :)

A'rpi

UPC-nél vagy "IPv4" módban van a végpont (ilyenkor publikus IPv4 címet kapsz, és egyáltalán nincs IPv6), vagy pedig "DS-Lite" módban van (ilyenkor natív IPv6 van, és az IPv4-et - nem publikus IPv4 címmel - egy IPv4-over-IPv6 tunnel fölött kapod.)

Mivel utóbbinál az IPv4-over-IPv6 tunnelt a nálad lévő végberendezés (router) végződteti, ezért az nem lehet "modem" módban.

Én mindenhol tiltom, nincs szükségem rá, viszont gondot már okozott.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Nos, akkor nyitok egy új szálat...

Internet-szolgáltatóként a '90-es évek végében kezdtünk el játszani az IPv6-tal, nagyjából 2009-től kezdtünk el mindent dual-stackre átültetni, és 2012 óta minden dual-stack, kivéve egy-két nagyon egzotikus alkalmazást, amit kénytelenek voltunk máig IPv4 only meghagyni.

Szolgáltatóként az elején gyakran beleütköztünk abba, hogy néhány, IPv4-en megszokott megoldás teljesen másképp implementálható IPv6 felett, valamint van néhány olyan, IPv4 fölött régóta használt megoldás, ami gyakorlatilag implementálhatatlannak bizonyult IPv6 felett.

Azóta jópár év eltelt, és azt kell mondanom, hogy az utóbbi kb. 6-8 évben a megoldások annyira kiforrottak, hogy részemről akár végleg le is kapcsolhatnánk az IPv4-et. (Szolgáltatói oldalról még picit szopok a router advertisement és a DHCPv6 RADIUS-szal való összeházasításával, de nagyjából ennyi.)

Ezek a kliens (átlag felhasználó) szemszögéből viszont teljesen irrelevánsak. Ha a szolgáltató normálisan konfigurálta a routert, akkor a kliensnek (a mai oprendszerekkel) pöcc-röff mindennek simán mennie kellene.

A Google pedig tolja föl a seggébe a DHCPv6-nemtámogatást.

Az az igazság, hogy a NAT miatt nem szorulnak rá se az emberek, se a szolgáltatók az IPv6 használatára.
Azt gondoltam, hogy ez egy idő után majd probléma lesz az eszközök számának állandó növekedésével, de közben bejött ez a felhős trend.
A felhőnek pedig mindegy a NAT/CGNAT, sőt így nem kell a technikusnak hálózati beállítással ügyködnie, csak bedugni az eszközt és működik.
A felhő pedig jó, mert bezárja a felhasználót, állandó díj szedhető utána (előfizetéses konstrukció), bármikor lekapcsolható (avultatás, vegyél újat, pörögjön a gazdaság).
Ha ez mind nem lenne elég, ehhez jön hogy a szolgáltatók nem adnak fix IPv6 tartományt, hanem azt is dinamikusan osztják, ami még rosszabbá teszi az eszközök számára, mintha IPv4-et használnának. Ugyanis olcsó (értsd <100e Ft) routerekben nincsen NAPT IPv6 esetén, így minden egyes eszközre fizetni kell valamilyen dinamikus DNS-t, ha nem cloud-ból akarjuk elérni (hanem direkten). Ráadásul vannak eszközök, amik nem is támogatják ezt, csak a router tudná, de IPv6 esetén azzal sem tudsz mit kezdeni.

Az egész mögött tehát - mint mindig - most is pénz van.

Mára a tartalomszolgáltató és a hozzáférés-szolgáltató piac eléggé erősen kettévált. A tartalomszolgáltatóknak szükségük van kellő számú publikus IP címre, de az már nincs. Én is szolgáltató vagyok, nálam is elfogytak az IPv4 címek. Új IPv4 tartományokhoz csak ügynökökön keresztül lehet hozzájutni, heroin-árban. Ezzel szemben, az IPv6 címek gyakorlatilag "ingyen", korlátlanul rendelkezésre állnak.

A hozzáférés-szolgáltatónak arra van szüksége, hogy az ügyfele elérje a tartalomszolgáltató szerverét. Jelen esetben, a tartalomszolgáltatóknak kell kierőltetni az IPv6-ra váltást, onnantól a hozzáférés-szolgáltató kénytelen lesz alkalmazkodni - vagy, elveszíti az ügyfeleit.

Ha minden felhasználónál CGNAT lenne, akkor annyi IPv4 cím állna rendelkezésre, amennyi tartalomszolgáltató az elkövetkező 100 évben sem lesz (mivel több nagyságrendbeli különbség van a szolgáltatók és a fogyasztók között). Ráadásul ennél az új Facebook generációnál már a tartalom is sokszor a Facebook-ra korlátozódik, így egy rakás cég jelen van ott és már van olyan cég is akinek nincs is saját honlapja. Ráadásul egy csomó tartalom is CDN-eken keresztül jön, amin osztozik egy rakás szolgáltató.

Ha a publikus IPv4 címeknek globálisan lenne egy havidíja, mondjuk egy jelképes 1 $/hó, akkor az egész IPv4 cím mizériát megoldaná a piacgazdaság. Az összeg pedig infrastruktúra fejlesztésre lenne elköltve mondjuk egy globális és a helyi lokális alapítványok által.

Igazából az is gond, hogy ahhoz, hogy mondjuk egy weboldalt szolgáltathass, ahhoz szükséged van egy publikus IP címre. Ha lehetne https-t másik porton is szolgáltatni - például a DNS-ben benne lenne, hogy melyik IP melyik portja szolgálja a HTTPS-t az adott DNS néven - , akkor nem lenne szüksége a tartalom szolgáltatónak egy teljes IP címre, elég volna neki egy IP-cím:port páros. És máris meg lehetne osztani az IP címeket a szolgáltató oldalon is.

(DNS név szerinti elágaztatással most is ki lehet 1 IP-n akárhány teljesen független oldalt is szolgálni, de nyilván ilyen szinten nem akar senki közösködni, mert a DNS név szerinti elágaztatás már erősen a http szerver beállítását érinti.

De ha a VPS szolgláltatómnál  és az Internet szolgáltatómnál kaphatnék pár public bejáratot pár szolgáltatáshoz, amiket nevekhez globális tudok rendelni, az már elég is volna a boldogságomhoz.)

Gondolom, segítené az elterjedést, ha pl. lennének olyan, széles körben elterjedt, valóban használható HOWTO-k, amik pl. elmagyaráznák, a sokak által szajkózott "nem kell a NAT" és társai mondásokat.

Pl. egy egyszeri rendszergazda nem biztos, hogy el tudja képzelni, hogy a cégénél az egyes kliens gépek hogyan lesznek védve, ha nem lesz előttük egy tűzfal.

Én nem tudok ilyen nem száraz szakmai, inkább gyakorlatias gyűjteményről, amiben nem 30 oldalon keresztül taglalják a IPv6 csomag fejlécének formátumát meg egyéb dolgokat, hanem valóban hasznos tanácsokkal szolgálnak.

trey @ gépház

Az egyszeri rendszergazda nem biztos,

Azt se tudja mi a különbség a tűzfal, és a router között. Minap is jött kérés, hogy nekik kell tűzfal, mondom jó és bővebben mit ért alatta, mert ez így kevés ? Már nem tudott mit rá mondani :D Szóval az efféle "rendszergazdáknak" mind1, hogy milyen doksit adsz.

Fedora 31, Thinkpad x220

Oké, de tegyük fel, hogy van egy ilyen rendszergazda (tele van vele az ország, btw). Mit mondasz neki? Mivel győzöd meg? A bevezetéssel járó kurva nagy melóval mit fog nyerni? Vannak olyan gyártók, akiknek feltettem az IPv6 támogatás kérdést és csak nevettek? Ezekkel mit kezdjünk vállalati környezetben?

trey @ gépház

Nem használok Cisco eszközöket. Amiket használok, azok nem tudták (stabilan), ezért nem is foglalkoztam vele. E beszélgetés hatására néztem egy státuszt, úgy fest változott a helyzet. Vagyis van remény. Mindazonáltal, ha mostanra lett egy ilyen támogatás, az azt jelenti, hogy ebben a szférában kb. 10 éven belül várható valami. Nem gondolod, hogy egy komolyabb Windows AD forest-et hétfőről keddre valaki csak úgy átállít? :) Főleg ott, ahol még olyan régi szarokat is támogatni kell, ami nem is beszéli rendesen az IPv6-ot?

Ezek mind akadályok az IPv6 elterjedése előtt.

trey @ gépház

Megnyugtató a Google válasza egyébként :)

Will IPv6 ever happen?

At our current rate of progress, IPv6 will be fully implemented on May 10, 2148. IPv6 (Internet Protocol version 6) is more efficient, more secure, and more mobile-friendly than IPv4.

Már csak 129 év ;)

trey @ gépház

Szerkesztve: 2019. 11. 25., h - 23:54

- nem ide -

Az ipv6 tulajdonképpen megbukott szerintem.

Ha a technológia jó lenne, már rég ez hajtana mindent.

Jönnek évröl évre az újabb technológiák kérdés nélkül, mindenki a megváltást várja az újtól, meg a csodát, aztán kiderül, hogy szar az egész. Ez van. A lényeg, hogy csináljunk valamit :)

robyboy

Jaham, az úgy van ám, hogy a rencergazda józsi kitalálja, hogy ő bevezeti a v6-ot jövő kedden :D

A valóság inkább úgy néz ki, hogy leteszik a vezetőség elé a következőket:

- várható plusz gazdaságilag:  semmi

- várható minusz gazdaságilag: sok, mert mindenkit ki kell képezni ipv6-ból az utolsó telefonos operátorig, időt kell szánni a gyakorlásra, és hónapok-évek kellenek ahhoz, hogy ugyanúgy rutinból menjen a v6 kezelése, mint most a v4-é, amivel van pár évtizedes tapasztalat

- várható kockázatok: hát, nem lesz mindenki boldog, ez kb. biztos.

Ez alapján pedig megszületik a döntés, hogy nem hajt a tatár...

Plusz várható kockázat, hogy senki nem érti mi ez a tűzfal VS NAT, és esetleg emiatt lesz pár sikeres támadás. Én bevallom, hogy ezen a ponton kapcsoltam ki, amikor rádöbbentem, hogy én ezt nem értem, ez itt egy kockázat, és a semmiért kellene felfognom és bekonfolnom.

Nagyon nem bukott meg, a technológia nagyon jó.

De még az informatikusok is idegenkednek tőle,  3 ip cím minden eszköznek + 1 ipv4

Otthon elkezdtem tanulgatni, a routereket macerálni, őszülni

Majd elmentem a sarki pc boltba és vettem 2db ipv6 kompatibilis switchet:)

Azóta is tökéletesen műkszik.

És a törésgátló gumi v6-os-e :) ?

Én is otthon hurrikánozok, régi melóhelyet meg úgy hagytam ott, hogy ULA tartományban majd minden szerver és kliens tudott egymással dumálni v6-on is.

Egy ideig futott olyan http proxy, amin át ki lehetett kukkantani az IPv6-os nagyvilágba, szintén hurrikánon, mert a két szolgáltatótól egy se adott v6-ot.

A kisebbik meg is mondta, minek az. 

Nem nevetni. 5-6 éves TP-Link SOHO "wifirouter", bridzselsz vele a LAN csati és a WiFi között ... LAN, broadcast minden kimegy.
Az IPv6 meg cseszik átmenni. Layer 2 ? WTF?

Megoldás: azonnal OpenWRT rá, ahol a bridzs az tényleg L2-ben megvalósított cucc. Jé, kimegy WiFi-re az IPv6 is. Bámulatos hol tart már a tudomány.

Ok de pl nekem DLNA-val is gondom volt a Wifi és a LAN között mert nem minden forgalmat passzol át a valszeg szoftveres bridge a wifi és a LAN között, valamint Debian alatt a bridgelt kártyák között csak mindenféle kernel opciók belövése után ment át a PPPoE. Úgy nézki, némelyik (vagy az összes?) disztró alatt nem enged át eszetlenül mindent az sw bridge, hanem csak amit a fejlesztők annak idején szükségesnek tartottak. Nem mentem utána mélyebben

OpenWRT-n meg figyeltek arra, hogy az NDP meg ami kell még a v6-hoz felderítő protokollok átjussanak a bridge-n (ha már egy példásan v6-ra felkészített fw, amit sok gyártó is példaként vehetne). A v6-ot az is megtörte nálunk wifi-n, mikor próbaképp bekapcsoltam a kliensek szeparációját, míg v4-en minden müxött tovább (azóta lehet javítottak ezen a Unifi-ben).

Viszont egy hót buta ASIC alapú sw-nek nem kéne beakasztania az IPv6-ot, bár lehet valami nagyon tacskó gazdaságos vagy nagyon kőkorszaki cucc.

Mármint hogy egy Ethernet-továbító készülék nem továbbít minden Ethernet csomagot, csak ami tetszik neki? Most mondanám, hogy nem hiszem, de az az igazság, hogy ez csodás IT-ipar tele van olyan termékekkel, amik nem azt csinálják, ami a specifikált feladatuk, hanem mindenféle mást, amit a fejlesztő épp kigondolni vélt.

IPv6 validation for http://www.digi.hu

Tested on        Tue, 26 Nov 2019 16:35:51 GMT
AAAA DNS record        2a01:368:a:201::1000
IPv6 web server        Apache
IPv6 DNS server        ns1.hdsnet.hu,ns2.digi.hu

IPv6 validation for http://www.telekom.hu

Tested on        Tue, 26 Nov 2019 16:36:59 GMT
AAAA DNS record        2001:4c48:2:1::1
IPv6 web server        Apache
IPv6 DNS server        This domain has no IPv6 DNS server, this may prevent some IPv6-only users from reaching it.

Digin vagyok, full IPv6, régen Hurricane tunnellel. A chrome-hoz van egy kiegészítő IPvFoo néven, ott látom, hogy v4 vagy v6 alól nézelődök éppen. 4-5 év alatt kb 2-szer volt probléma, hogy leállt a v6 szolgáltatás, de csak a router hibájából.

~ubuntu, os x~

+1 rackforest.hu ad mindenkinek aki kéri ipv6 tartományt is az ipv4 mellé, gyorsan felsetupolható; én mindegyik projektemnél használom

~ubuntu, os x~

Még egy pozitív érték:)

[2019-11-30 21:44:12] [NOTICE] Sorted latencies:
[2019-11-30 21:44:12] [NOTICE] -     1ms quad9-dnscrypt-ip6-filter-pri
[2019-11-30 21:44:12] [NOTICE] -     8ms quad9-dnscrypt-ip6-filter-alt
[2019-11-30 21:44:12] [NOTICE] Server with the lowest initial latency: quad9-dnscrypt-ip6-filter-pri (rtt: 1ms)