IPv6 a magyar weben

Időről időre előjön az IPv6 penetráció téma itt a HUP-on, pl 3+ éve amikor Trey csinált egy listát az IPv6 képes oldalakról. Akkor össze is raktam egy scriptet ami leellenőrzi a top 500 magyar weboldal IPv6 elérhetőségét és azóta (többé kevésbé) rendszeresen futattam is.

Így néz ki a magyar top 20/100/500 weboldal IPv6 támogatásának alakulása az elmúlt 3 évben:

IPV6 timeline

 

Érdekes összevetni a bővülést a kliens oldallal, pl a Google IPv6 statjával ami szerint jelenleg a magyar kliensek majdnem 50%-a (48% pontosan) rendelkezik IPv6 címmel: https://www.google.com/intl/en/ipv6/statistics.html

Sajnos a DKT változtatott a top weboldal adatok publikálásán és most már nem elérhető a top 500 lista, így valószínűleg ezt az adatgyűjtést nem tudom tovább folytatni.

További adatok, infok a projekt github oldalán: https://github.com/atommaki/hungarian-web-ipv6

( trey | 2023. 01. 19., cs – 15:18 )

(Javítottam benne a DKT linket, mert hiányzott a protokoll, így pedig a HUP-ra mutatott.)

Sokat nem létünk előre, sőt.

trey @ gépház

( KicsiBocs | 2023. 01. 19., cs – 15:36 )

Elég baj, hogy még mindig sokan görcsösen ragaszkodnak az IPv4-hez, és/vagy lusták beállítani az IPv6-ot szolgáltatói szinten is. A KIFÜ sok szolgáltatónak példakép lehetne (ebben is).

Pedig első fázisban a kliensek oldaláról kellene elérni az IPv6-képességet, méghozzá a kliensek 100%-ánál.
Azaz https://test-ipv6.com/ szerinti 10/10-es pontszámot.

A következő lépés lehet, hogy megjelennek az IPv6-only kiszolgálók.
Másik teszt: https://ipv6.google.com - megnyílik nálad? Ha nem, akkor miért nem?

Nekem azert lennenek meg otleteim a terjedes gyorsitasara. Jelenleg igazabol nincs motivacio, inkabb csak amolyan felkeszules a jovore, de ha valaki egyaltalan nem tamogat IPv6-ot  (akar ISP, akar web szolgaltato) az nem veszit semmit, hisz minden elerheto IPv4-en.

Otleteim:

  • Kormanyzati/allami tamogatas, torvenykezes:
    • minden ISP koteles IPv6 cimet (is) adni a usereknek
    • minden IPv4-es csomag kap 1ms delay-t. Aztan jovore mar 10-et, aztan 20-at.
  • A nagy site-okon (Google, FB, stb) megjelenhetne egy banner ha IPv4-en nezed az oldalt, hogy "elavult protokolt hasznalsz". Minden mukodne ugyanugy, csak lenne egy banner. Kezdetben eleg lenne kampany jelleggel, pl csak havi egy nap amikor a banner ott van. Szerintem sokan hivnak az ISP-t hogy valami baj van. ;)

Szerver oldalon majd ezt is komolyan veszik abban a pillanatban, amikor a Google hátrasorolja az IPv4-only oldalakat, és a Chrome kidob egy figyelmeztetést, ahogy a HTTPS esetében is történt.

Mondjuk kb. két pillanat eléhúzni egy Cloudflare-t, és máris minden "meg van oldva".

btw amíg a sima szolgáltató ugyan ad olyan dobozt ami IPv6 képes (Technicolor IPTV Telekom), de nincs rajta aktiválva a szolgáltatás, akkor az elég nagy húzás lenne...

Persze én is betelefonálhatnék hogy aktiválják rajta az ipv6ot , vagy rakhatnék mögé saját cuccot.. de amíg az ISPk nem igazán adnak by-default ipv6ot addig ez eléggé necces lenne.

Google meg nem fogja ezt meghúzni, mert akkor egészen sok ISP _céggel_ találja magát szemben jogilag .. :Í

de fixme.

Szerintem is egy ilyen nagy óriáscég nyomása fog kelleni, hogy az IPv6-ra átállást komolyabban vegyék. Nem feltétlen csak Google, a MS, Meta is tud hasonló irányba terelni.

Egyébként ez a 40-50%-os elterjedtség nem is rossz, ha tippelni kellett volna, én 10%-ra tippeltem volna maximum. Legalább a globális szintet elérik a magyar oldalak. Nem mondom, hogy szuper arány, de ahhoz képest nem is olyan borzalmasan alacsony, hogy nincs még egyelőre IPv6-kényszer senki oldalán.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ne feledjük, az igazi előny akkortól lesz, ha kivétel nélkül minden internetet elérni szándékozó kliens IPv6-on is kommunikál már. Klienseknél az IPv4+IPv6 elérésének megoldása egyszerűbb eset.
Utána jöhet csak az a fázis, amikor az új szerverek tömege már IPv6-only módon építhető fel.

Szerver esetén az IPv4 + IPv6 a gyakorlatban több kockázattal jár. Ugyanis innentől mindent IPv4 és IPv6 protokollal is célszerű tesztelni.
Amiért ez kockázatos, mert emberi tulajdonság, hogy az egyik teszt ilyenkor elmaradhat. Ezért jobb csak az egyikkel üzemeltetni a szervert és arra tesztelni a kiszolgálást.

> Ne feledjük, az igazi előny akkortól lesz, ha kivétel nélkül minden internetet elérni szándékozó kliens IPv6-on is kommunikál már.

Ne kímélj: mi lesz az igazi előny? (De ha ezen múlik, adott esetben azt is el tudom képzelni, hogy kitalálunk valamilyen technikát, amivel IPv4 csak az utolsó mérföldön megy, mert az ISP valamilyen ravasz protokollfordítást végez, és IPv6-ot enged rá az internetre.)

Én sem látom az IPv6 igazi előnyét a nagyobb címtartományon kívül. Minden más komplexebb benne, mindenre van ezerféle lehetőség (SLAAC, DHCPv6, link-local addressing, neighbor discovery).
És ebből találj olyan kombinánciót, amit minden eszközöd egyformán ismer és ért.

Olyan ez, mint az IPSec. MIndenre jó megoldás, de semmire sem jó, mert túl komplex, és túl sok mindent enged meg, emiatt nehéz összehozni, hogy a kliens és a szerver kompatibilis legyen. Jó mindenkinek az OpenVPN meg a wireguard, sokkal kevesebb szopás.

... legalábbis a dokumentáció szerint.

Amikor megkérdezzük a szállítót, hogy IPv4/IPv6 feature parity megvan-e, akkor szinte kivétel nélkül mindegyik azt mondja, hogy igen. A részletes kérdésekre adott válaszoknál meg jönnek a csillagozott részek, pl. egy VPN-en belül nem mehet IPv4 és IPv6 együtt, vagy pedig IPv4 végpontok közti IPSec tunnelben csak IPv4 mehet, IPv6 végpontok közt meg csak IPv6 és hasonlók.

Aztán a POC teszt alatt az osfpv3 elszáll, a cég dolgozója is csak les, aztán valahol a privát support területen sikerrel előássa, hogy ez ebben a hardware-ben még nincs rendesen implementálva....

Mindez olyan cégnél amelyik a Gartner jobb felső mezőjében van. Akkor milyen a többi?

> Mindez olyan cégnél amelyik a Gartner jobb felső mezőjében van. Akkor milyen a többi?

hat egy neves tavolkeleti gyarto termekeivel jartunk ugy, hogy a feature listben minden is szerepel, es valoban tamogatja is azokat a protokollokat, csak ne akard oket egyszerre. szoval vagy GVRP _vagy_ LACP trunk, de ne akarj trunkon GVRP-zni mert az edge switchuk bugzik a core meg lefagy :)

Szerintem két nagyon fontos dolog vezetett ideáig:

1. Az IPv6 olyan problémát old meg, amit a világ megoldott nélküle is. ( lásd. CG-NAT)

2. A világ nem a decentralizáció irányába ment el, mint amire számítani lehetett (P2P technológiák térnyerése), hanem pont ellenkezőleg: az utolsó kenyérpirító is cloud vezérelt, ami nem indokolja, hogy publikusan elérhető legyen az internet felől.

Hogy most ez jó-e így, arról lehet vitatkozni, de a tény tény marad: a világnak valójában nincs szüksége az IPv6-ra. :(

Tipikus 'worksforme' hozzáállás.

https://en.wikipedia.org/wiki/List_of_countries_by_IPv4_address_allocat…

Mi jól állunk, mert 1000 lakosra >500 IP cím jut, így mondjuk ha a mobilok CGNAT-on vannak (végül is az még elmegy), akkor elvileg akár minden lakás juthat egy valós IPv4 címhez, tehát nincs rá szükség. Akik meg későn jöttek, így jártak, mi a fenének akarnának teljes értékű IP címhez jutni.

Hehe. Ez rendre előjön, de az egyik naaagy szolgáltatónál a szervereinkhez nem tudtunk "normálisan" IPv6-ot kérni, sőt szinte sértésnek vették, hogy ilyen felmerül. Amúgy akinek kell, az fogja, és CloudFlare-t tesz az oldala elé, és kész.

Az IPv4 egyébként nem avult el, simán elfogyott. :)

Még gyerek voltam amikor már ez a szöveg ment, hogy hamarosan elfogy az utolsó IPv4 cím is. Aztán a vlsm csak megoldotta a problémát úgy, hogy ma is van elég cím. 

Amíg nem lesz alapértelmezett a home routerekben az IPv6 NAT funkció, addig továbbra is csak elkötelezett geek hobbiprojekt marad. 
Lehet mondani, hogy a NAT nem security technológia, de mára lényegében a home routerek tűzfal-szerű elemévé vált.

A NAT elrejti az egész hálózatod, ami nem csak biztonsági szempontból jó, hanem lényegében fix, szolgáltatófüggetlen belső hálót alakíthatsz ki, mert bár elvileg egy tartománycsere esetén a router tudja értesíteni a klienseket a változásról valamint vannak/lehetnek többféle helyi címzések párhuzamosan a globális címzéssel a helyi szolgáltatásokhoz, gyakorlatban lehetnek gondok, valamint a FailOver&LoadBalance megoldása is nagyban egyszerűsödik NAT mellett.

Persze a sima masquerade-nál pl egy prefix translation lehet hogy egészségesebb, mindenesetre a routert kevésbé terhelné (bár otthonra a mai routerekkel már nem kellene gondnak lennie)...

Én anno csináltam ilyet ULA címekkel, aztán rájöttem hogy a Firefox az ULA címek esetén csatlakozni sem próbál IPv6-on ha visszakap IPv4-es címet is. Legalábbis anno amikor próbáltam. A logika mögötte valami olyan nyakatekert volt hogy lehet hogy az az ULA cím egy nem elérhető hálózaton van és a DNS-be véletlenül került be így biztosabb ha az IPv4-et használja. Ami baromság mert akkor ilyen logika alapján az RFC1918-as IPv4-es címekre sem kellene csatlakoznia.

A link local címek meg egyszerűen nem működtek mert nem szerette a zone indexet a végén. Meg úgy egyébként is kicsit érdekes lenne a laikusoknak elmagyarázni hogy ez a cím, igen az egész, igen hosszú, na és a végére a % jel után írd be a kimenő interface nevét... Az interface az az a hálózati csatlakozó amin... Hagyjad, majd én.

Ha nem akarsz webet akkor persze működnek a link local címek, én is használom őket ha nincs más, de erre nem építenék komolyabban.

Évekkel ezelőtt próbáltam, szóval azóta lehet már változott a világ, de nekem itthon van fix tartományom így nem érint jelenleg a dolog.

IPv6 NAT-ból sokféle van. Amire gondolsz az szerintem konkrétan a 6to6 NAT masqueradinggel, ami igazából RFC szerint tilos. Ennek az lett volna az értelme, hogy a protokoltervezőknek a jövőben már ne kelljen NAT-traversal megoldásokat beépíteni a mindenbe is. Helyette a kliens és a szerver is tetszőlegesen indíthasson oda-vissza kapcsolatot egymás felé, amikor csak akar. Ilyen dolgok, mint push notification például nagyságrendekkel egyszerűbb lenne.

"Lehet mondani, hogy a NAT nem security technológia" - pontosan. A NAT (mármint konkrétan a masquerading) valójában inkább privacy technológia. Amikor az IPv6-ot réges-régen kitalálták, még nagyon nem gondoltak erre, és akaratlanul túlságosan is könnyűvé tették az egyes kliensek szoros követhetőségét hálózatok között is. Aztán bevezetek egy csomó hacket ez ellen (temporary address, cryptographically generated address, privacy extension, meg hasonlók), ami azóta is bonyolítja az IPv6-ot.

Régóta vágyok én, az androidok mezonkincsére már!

Amíg sok végfelhasználói NAT-dobozka/WiFi AP nem képes normálisan kezelni a dual IPv4/IPv6 stackeket, addig ez nehéz lesz.

De ugyanez igaz szolgáltatói oldalon. Otthon én is bekapcsoltam az IPv6-ot, preferáltam is, de sokszor tapasztaltam hibás működést alkalmazásokban, weboldalakon stb. Amint kikapcsoltam az IPv6-ot, minden megjavult. Szóval lehetek én kliens oldalon IPv6 preferáló, de amíg ez rosszabb felhasználói élményt jelent, addig ki fogom kapcsolni.

Igy van, errol van szo. En vegfelhasznalokent ugralhatok, hogy jaj de jo az IPv6, adhat ilyet is nekem a szolgaltato, lehet az ISP IPv6 parti, de amig ez rosszabb minosegu szolgaltatast jelent nekem, nem fogok erte ugralni sem eszkozbeszerzes teren, sem az ISP-nel nem nyitok errol hibajegyet.

( janu v | 2023. 01. 19., cs – 19:24 )

Túl a technikai problémákon az IPv6-nak az is hibája, hogy tipikus szobatudós fejlesztés. Egyszerűen kezelhetetlen, de nagyon szép (valamilyen szemmel). De amíg ez a válasz a dig kérdésre:

$ dig aaaa 2600:1f18:1f:db00:807b:f1f4:d01b:30b1

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> aaaa 2600:1f18:1f:db00:807b:f1f4:d01b:30b1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 65033
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;2600:1f18:1f:db00:807b:f1f4:d01b:30b1. IN AAAA

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Jan 19 19:20:55 CET 2023
;; MSG SIZE rcvd: 66

akkor... na, ki ez a jó kis „könnyen megjegyezhető” cím tulajdonosa?

Registered Linux user #46079

Jó. Ettől sem lettem tájékozottabb:

# dig -x 2600:1f18:1f:db00:807b:f1f4:d01b:30b1

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> -x 2600:1f18:1f:db00:807b:f1f4:d01b:30b1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35923
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;1.b.0.3.b.1.0.d.4.f.1.f.b.7.0.8.0.0.b.d.f.1.0.0.8.1.f.1.0.0.6.2.ip6.arpa. IN PTR

;; AUTHORITY SECTION:
0.8.1.f.1.0.0.6.2.ip6.arpa. 612 IN      SOA     dns-external-master.amazon.com. root.amazon.com. 101 3600 900 604800 900

;; Query time: 348 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Jan 20 09:56:33 CET 2023
;; MSG SIZE  rcvd: 172

Registered Linux user #46079

Ez így van IPv4 esetén is. A legtöbb szolgáltató vagy nem állít reverse-t vagy pedig egy IP címből képzett valamit ad amiből semmi nem derül ki.

Ha azt akarod tudni hogy kié akkor nem dig, hanem whois. Elvileg, de mivel ez egy AWS-es cím így csak azt fogod visszakapni hogy Amazon ők meg nem fogják kiadni hogy melyik ügyfelükhöz tartozik. De ugyanez van IPv4-en is. IPv6-on annyival több az infód hogy az AWS /64-eket oszt így legalább azt tudod hogy bárki ki is az, de mindkét IP hozzá tartozik. IPv4-en /32-ket ad, azaz két egymást követő cím is tartozhat teljesen más ügyfélhez.

( khiraly | 2023. 01. 19., cs – 22:48 )

En mint végfelhasználó milyen előnyt kapok?

Ad nekem a szolgaltato mondjuk 16k db publikus ipv6 cimet? (adhatna, beleférne).

Nem, ad egyet ....

 

A fold minden lakojanak kellene szuletesekor 1024 db ipv6 cimet lefoglalni 120 evre.

Ne felj, akkor elterjedne...

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Milyen 1024 IP cím, az semmire se elég. :) Az ajánlás kezdetben az volt, hogy /48-at kapjanak a végfelhasználói oldalon, ami azóta rongyos /56-ra, vagy /64-re olvadt. Logikus, hogy mindenki szimulálni akarja a mostani internetet, azért kell ennyi.

Az alapprobléma az lesz, hogy minden jelenleg NAT mögötti (és arra képes) eszköz felszippant egy publikus ip6v címet. Nos ezzel nem kicsit, fog kinyilni a világ, és nem jó értelemben. Nem csak "carefully crafted" a v6, de eléggé idealisztikus is.

Logikus, hogy mindenki szimulálni akarja a mostani internetet, azért kell ennyi.

Nem, ezt sajnos a nagyokos protokolltervezők korai döntései miatt van így, akik egyszerűen úgy határoztak, hogy a legkisebb subnet legyen /64. Pontosabban inkább fordítva volt, azért lett 128 bites a cím, hogy garantáltan legyen szabadon legalább 64 bit állomáscímnek minden subnetben. Azért 64 bit, mert a leghosszabb fajta layer2 "MAC" cím (pl fibre channel WWN-ek ilyenek) 64 bites, így lehessen azt használni garantáltan egyedi állomáscímnek.

Emiatt sok alapvető IPv6-related protokoll támaszkodik arra, hogy egy subnet ne legyen szűkebb /64-nél. SLAAC (a MAC-címből generált címek, a temporary address-ek, crpytographic generated address-ek, és még tudjaisten hány ilyen hasonló üzemmód van) és NDP néhány funkciója (asszem pl prefix delegation). Ha ez nincs, akkor legfeljebb a stateful DHCPv6 vagy a manuális statikus IP marad, kb IPv4-hez hasonló, egy állomás - egy cím módon. Meg persze a kötelező link lokális cím, ami szintén /64-es subnetet használ, de ugye ott nincs választási lehetőséged a subnetre.

Ettől függetlenül egyébként el lehet lenni kisebb subneten is, legalábbis szerver oldalon (korábbi melóhelyen fejlesztett termékben) támogattuk és nem volt belőle probléma. A baj inkább abból volt, hogy az ügyfelek nem voltak képesek megérteni, hogy IPv6-on a dockernek is kifele route-olható subnet kell, ajánlás szerint legalább /80-as (egyébként ez is működik szűkebbel is - kikönyörögték hogy támogassuk), és nem lehet 1db /128-as állomáscímmel megúszni. A végén már komolyan gondolkodtam rajta, hogy hiába tilos RFC szerint, be kellett volna építeni 6to6 NAT-ot a dockernek, kevesebb support problémánk lett volna belőle.

Régóta vágyok én, az androidok mezonkincsére már!

Egyetlen publikus IPv6 címet ad a szolgáltató, vagy sok szolgáltató az ajánlott /56 helyett mindössze egyetlen /64-es tartományt ad? Nem mindegy.
Annak kiszámolását rád bízom, hogy a legszűkebbként adott egyetlen /64 tartomány hány darab publikus IPv6 címet jelent az otthonodban.

Egy könyvet ajánlok figyelmedbe és sokkal tisztább lesz a kép: https://mek.oszk.hu/23400/23433/23433.pdf

Igen, gyakorlatban azért elég jól elműködik /64-nél szűkebb tartomány is, főleg szerver oldalon. Ott amúgy sem igazán játszanak a SLAAC és társai. DHCPv6 - amennyire emlékszem - stateful módban simán működik kis subneten.

Kliens oldalon lehet problémásabb a dolog, amikor sok ilyen "IPv6-automagic" feature nem működik. Plusz a felhasználók sem nagyon értenek hozzá, azt várják, hogy bedugom és működik. Asszem pár OS szeret mindenféle temporary address-eket felvenni, jó kérdés azok mit csinálnak, ha a router advertisement /64-nél szűkebb tartományt hirdet meg.

Régóta vágyok én, az androidok mezonkincsére már!

Sokra mész vele

Hát, első blikkre sokkal többre IPv6 kommunikáció terén, ha teljesül az, hogy mindkét végponton van IPv6. Ma még igen gyakori, hogy egyik oldal IPv4 only.
A /56 ... álom sajnos nekem is (Digi GPON). A vendég WiFi hálózati kijáratára marad sajnos a NAT, mint egyetlen nem elegáns megoldás.

Mellesleg karácsonykor rokonlátogatás során megnéztem a Telekom GPON hálózati végpontját, mivel a Telekom oldalán örömmel láttam a /56-ot.
Kértem dhcpv6 klienssel még egy /64 prefixet. Sajnos ugyanazt a tartományt kaptam, mint a felettes hálózat.
Úgy néz ki, hogy a /56 és a több igényelhető /64 Telekom esetén is csak DOCSIS hálózati végpontra (kábelmodem) igaz. GPON hálózati végpontra nem.
Figyelmesen elolvasva az imént linkelt leírást, ez végülis benne van oly módon, hogy GPON esetén ezek a további /64 igényelhetőségre vonatkozó sorok nem szerepelnek.

Valakinek van lakossági /56-tal sikerélménye Telekom DOCSIS hálózaton kívül?
Illetve a Telekom DOCSIS-on tényleg működik a több önálló /64 prefix kérése?

( kruska v | 2023. 01. 19., cs – 23:13 )

Szerkesztve: 2023. 01. 19., cs – 23:13

Random belenézegettem a CSV-kbe, és elég sok host Cloudflare CDN mögött van, ergo fals eredményt látunk. 

Persze a látogató szempontjából nézve valóban elérhető IPv6-on az adott oldal, viszont a mögötte lévő hostra egyáltalán nem garantált, hogy IPv6-on kapcsolódik a Cloudflare felé (nem mintha ez bármilyen hátrányt is jelentene, csak ténymegállapítás).

( arpi_esp v | 2023. 01. 20., p – 00:27 )

Szerkesztve: 2023. 01. 20., p – 00:29

> magyar kliensek majdnem 50%-a

ez koszonheto annak, hogy a nagy otthoni szolgaltatok (upc/voda, telekom, yeti, digi) mind ipv6 adnak by default. meg az niif/kifu is tolta regebben nagyon az ipv6-ot (mostanaban mar nem annyira, sot eleg nehezkes uj helyen bevezetni), a kis helyi szolgaltatok es a ceges elofizetok meg v4-en vannak, meg az a par %-a az usereknek aki visszarakatja magat v4-re valamiert (torrent, vpn-ek stb).

covid alatt elkezdtunk bbb-t hasznalni az egyetemen, mikor a szerver halon bekapcsoltam a RA-t es a bbb szerver azonnal szerzett maganak v6 cimet, hirtelen a forgalom nagy resze atment v6-ra (a web v4-en volt ugye de a webrtc streaming mar v6-on epult fel, annak ellenere hogy a dns-be nem is szerepelt a v6 cime). visszakeresve a prefixeket kiderult hogy a nagy resze home isp-k.

> vagy lusták beállítani az IPv6-ot szolgáltatói szinten is

sajnos ez nagyon igaz, 1 eve kerestem VPS-t es fontos szempont volt az ipv6 prefix (legalabb /56). hat nem hogy ilyet alig talalni Mo-n (ugy remlik egyedul az ATW ad), de meg ipv6 supportot (akar csak 1 cimet) is alig ad valaki. az egyik legnagyobb hosting szolgaltatonal is mikor kertem v6 cimet 1 hetig ultek a ticketen, aztan kuldtek 1(!!!) db cimet (nem at /64 vagy nagyobb), de hibas gw beallitasokkal (RA vajonmi?), ugy kellett kikiserletezni mert fingjuk se volt rola...  kulfoldon jobb a helyzet, de az olcso VPS-ek kozul ott se mind ismeri a v6-ot.

( trey | 2023. 01. 20., p – 07:32 )

Én már úgy fogok megdögleni, hogy az IPv6 évére várok. Pedig mikor is kezdtem a várást? 20+ éve? 🤔 Igen.

trey @ gépház

Nem akarom leszukiteni a szintezis kinalt szolgatatasait a _csak_ rendszerintegrator/halozatuzemeltetes teruletre, de nem a rendszerintegrator feladata lenne ezek bevezetese az ugyfeleknel?
Az ilyen cegeknel az IT egy szukseges rossz es nem core tevekenyseg, ezert bizzak a kicsit is komplexebb dolgokat egy integratorra es nem tartanak fent egy sajat kompetens IT team-et (kihelyezik a felelosseget, cserebe lehet lobogtatni az SLA-kat), szoval ha ti nem foglalkoztok vele akkor valoban 0/20 lesz meg sokaig. Fontos, ez nem szemrehanyas akar lenni, mert nem tudom mennyire foglalkoztok vele vagy sem.

Nemszintézis, hanem általánosan... A kedves Ügyfél sehol sem fizeti ki, hogy elmakettezz az IPv6-tal. Minden dolog eredendően v4-re van kitalálva, alapinstallva, stbstb, és akkor az van és kész. Példul nagyon nem szeretnék egy menedzsment hálózaton, vagy storage hálózaton (iSCSI 10G) azzal tökörészni, hogy akkor vajon az IPv6 melyik része és hol fosta el magát, hol van gyengén implementálva, és így tovább.

Szóval amíg nincs masszív és stabil üzemeltetési tapasztalat, sokféle eszközzel, addig ez elég meredek dolog. Az hogy otthon vagy teszthálózaton összerakjuk (volt ilyen), az nagyonjó, de valahogy nem áll még igazán kézre, és "hátműködik" állapotban van, ha valami nyűg van, akkor nem biztos, hogy megéri belefeccölni a világ összes idejét.

de nem a rendszerintegrator feladata lenne ezek bevezetese az ugyfeleknel?

Akkor, ha megvan a szándék (gy.k.: a lóvé) a cégeknél. Ugye ... Ugye, ha ez nincs ... Meg legtöbbször ez nem a magyar leányvállalaton múlik. Vezess be pl. IPV6-ot egy német anyacég magyar leányánál a németek nélkül :D Sok sikert hozzá. A bevezetést megelőző 2 éves meetingsorozat másodikán nem fogsz túljutni, de lehet, hogy addig se, hogy egy meeting-et összeránts rá. :D

Kicsit több komolyságot pls. :D

trey @ gépház

Rohadt sok mindentől függ. Zöld mezős a téma, vagy nem, egy telephely, vagy több, netán multinacionális. Ki intézi az eszközbeszerzést, melyik országban. Ki végzi a dizájnt, kiknek mennyire kell alkalmazkodni hozzá. Erre szoktak csinálni egy projektet. Csak a döntés előkészítés lehet akár 6 hónaptól 3 évig bármi. Ha megvan a döntés, utána jön, hogy jelenleg a Cisco/HP akármi 1+ év szállítási időket ad meg. Ha ez megvan, utána jöhet az implementációs fázis, nyilván megfelelő tesztekkel, fokozatos rollout. Szóval egy nagyobb vállalatnál ez akár innen számított 10+ év is lehet :D Nekem a dolgok jelen állása szerint 15 évem van nyugdíjig. Bele kéne húzni.

De, elsőként azon a kérdésen kellene túljutni, hogy ebbe a projektbe miért is tegyenek humán erőforrást, plusz lóvét, amikor semmi sem kényszeríti rá őket. Mi a benefit, mik a rizikók. Kb. itt szokott elhalni a dolog.

trey @ gépház

Ezer dolog van. De ha valaki nem hiszi, legközelebb jelentkezzen, kérek neki belépőt a legnagyobb partnereinkhez, beviszem a mi sapkánkban és ha meg tudja győzni a céget, hogy fizessek az IPv6-ra átállás teljes költségét (T&M), annak szerződéskötés és sikeres projektlevezetés után sikerdíjat fizetek :D

(Na, ugye ...)

trey @ gépház

amig az ipv6 nem hoz egy cegnek kezzel foghato hasznot, kb le se fogjak sz@rni a bevezeteset, adott esetben az IT ha meg eroltetne is, nem fog ra penzt kapni, ha megis, akkor mindig lesz fontosabb es szep lassan elhal a projekt...jelenleg nem tudod megindokolni egy felso vezetonek, hogy Neki miert jo az, hogy egy valag penzt belelapatol egy projektbe, aminek nincs azonnali kezzel foghato haszna es a jovot is csak megtippelni tudjuk.

valjuk be, amikor az ipv6 -ot kitalaltak, jo otletnek tunt, hogy minden eszkoznek sajat publikus IP cime legyen az interneten, ez mara mar nem tunik annyira jo otletnek, sot az ipv6 bevezetessel jelenleg magadra huzol egy plusz layer-t amit security oldalrol vedeni kell.

nem vagyok az ipv6 ellen, viszont arrol sem vagyok meggyozodve, hogy ez a jovo es talan a szakma nagyresze is igy van vele, csinalja mert kell, terjesztik mert muszaj, de az, hogy ez biztos, hogy a jo irany, talan senki sem tudja...

FBK

Bár az IPv4 címek nem olyan mértékben fogynak, amennyire megjósolták (a címekben lévő tartalékok felélése zajlik igazából), de fogynak. Az előfizetők egyre nagyobb aránya kerül CGNAT mögé, ráadásul a szabad címek hiánya megnehezíti az új ISP-k piacralépését, ami viszont a piac koncentrálódása irányába hat (a verseny csökkenése pedig nem igazán vezet jóra). Ráadásul az egyenlőtlen címkiosztás miatt a régiók jó része eleve nem jut IPv4 címhez, emiatt a publikus oldalak szép lassan rákényszerülnek a dual stack-re, tehát az IPv6 nem jövő, hanem félig jelen.

Tehát ha úgy nézzük, ha globálisan akarsz szolgáltatni, akkor piacot vesztesz IPv4-only szolgáltatással. Ott lehet (és kell) egy cégnél az IPv6 bevezetését elkezdeni, hogy a DMZ egyes részeit kell dual stack-re átalakítani. És ez nem túl nagy költség, így el lehet kerülni egy globális v4-v6 átalakítás projektjét, ami tényleg évek, nagy költség, és várhatóan befejezetlen lenne.

Előfizetői oldalról az esetek többségében elég a CGNAT

Kivéve, ha egyre többen akarnak például otthoni kamerát elérni, anélkül, hogy cloudba akarnák csatornázni az adataikat. Ugyanez igaz a home automation dolgokra is. Ott már nem lesz elég a CGNAT, globálisan route-olt, állandó címek kellenek.

Szép kettősség ez - az állandó IPv4/v6 címek sokak szerint a privacy ellen szólnak, míg más tekintetben meg a privacy mellett.

Így van. Magam is csak own-hosted dolgokat használok. Dinamikus DNS-sel megtámogatva. Egyúttal azt is gondolom, hogy ez inkább a kivétel, mint a szabály.
A parasztok többsége megveszi a cloud-os fost, app felrak, oszt' csá. Nincs is neki szervere, amin hostolná a dolgait, VPN-t, port forward-ot meg azt se tudja, mi az. Egy dinamikus DNS, netán LetsEncrypt összelövése meg űrtechnika. Nekik pont jó lesz a cloud meg a CGNAT.

Na de érted, ha azt mondjuk, hogy a paraszt úgyis szar a privacyra, akkor a másik oldalról meg miért ódzkodunk az ellen, hogy IPv6-on ne legyen mindennek globális , állandó IP-je? Ezen is csak a privacy-freakek vekengenek, ami ugyanúgy eléri-e a 3%-ot? Nem hiszem. Akkor meg miért ne lehetne szépen IPv6-olni mindenhol? Sokan pont azt mondják, azért nem jó,mert nincs NAT, sőt, MAC alapú a címképzés, ami ugyanúgy rossz - miközben a userek nagy része azt sem tudja, mi az a NAT meg a MAC. Ugyanolyan álságos vekengés ez, mint azt mondatani, hogy a CGNAT mindenkinek jó.

Az egyik oldal akarna IPv6-ot, erre a másik leugatja, hogy minek, a másik oldal leugatja az IPv6-ot, őket meg a többiek kritizálják. Más-más nézőpontok vannak, az eredmény a jelenlegi felemás megoldás, ami viszont tényleg nem jó senkinek sem.

A bevezetést megelőző 2 éves meetingsorozat másodikán nem fogsz túljutni

Nah igen. Akkor úgy látszik nemcsak én voltam megverve ilyen ügyfelekkel. Kb az első meetingen az első kérdésemre kapott válasznál azonnal levágtam, hogy annyit tudnak az IPv6-ról, hogy "nagyon kell" és hogy "nagyon hosszú címek vannak benne". És akkor innen odáig kellett volna eljutni, hogy hogan live upgrade-elünk egy jelenleg pure-IPv4-es openstack-es környezetben futó szerver terméket egy pure-IPv6-os openstack-re (miközben az openstack akkori verziójában az API még nem is működött IPv6-on, nekünk viszont el kellett volna érni).

Régóta vágyok én, az androidok mezonkincsére már!

desktop ~ tablet, nagyképernyős telefon játszik ebben? Facebook-ra és fórumozásra mindegyik alkalmas, ez pedig a lakosság számítógép használatát nézve kb. 90%-ának elegendő.

Megdöbbentem, hogy covid alatt hány családnál a facebookra alkalmas telefon volt az össz informatika. Aztán beszállt az iskola, a rászorulók a távoktatás miatt kaptak tableteket.

Nem a cím ára a kérdés, azt ha tudsz 1x megveszed és kész, hanem a többi.

Igazából az ügyfelek 98% nak az kell, hogy bejöjjön a face/youtube stb. Azt se tudja mi a NAT/ipv4/ipv6 stb Amíg ez teljesül örül, amint nem akkor gond van és ez már költséget generál.

Az ipv6 -al tövább nő a hibaforrások száma. Bevezetés se triviális és költséges, pl.: minden vegponthoz kell CPE. stb

Fedora 40, Thinkpad x280

10 év alatt negyvenháromszorosára emelkedett a kliens oldali IPv6 penetráció. (~1%-ról ~43%-ra) A növekedés meglepően lineáris, és semmi esély nincs rá, hogy komolyabb törés következzen be az ütemében.

Én egyébként pont néhány hete állapítottam meg, hogy WAN viszonylatban már gyakorlatilag fel sem tűnne az IPv4 hiánya, mert a környezetemben kliens oldalon már 10+ éve van IPv6, kiszolgáló oldalon pedig az összes népszerűbb szolgáltatás már IPv6 képes. (Ha mást nem, Cloudflare mögül jön)

A LAN egy nehezebb dió, mert az IoT eszközök 99%-ban nem tudnak IPv6-ot. Sebaj, privát IP címből soha nem volt hiány.

Idősebb kolléga a soros portról mondta ezt. Csak az a különbség, hogy ő nem várja a megdöglését, inkább drukkol neki, hogy az ő idejében még tartson ki.

Én az IPv4-gyel vagyok így: remélem, hogy engem már kiszolgál. Fasznak kell a v6, csak a gond van vele, a benefit meg nem nagyon látszik.

Ez csak egy aktualis problema, ami hivatalosan is megerositettek. Kar, hogy ennyire elbagatellizalod, a felhasznalok ipv6 helyett a hasznalni kivant szolgaltatast valasztottak. En azt gondolom, ezek a problemak amik az ipv6 terjedeset gatoljak.

Kovezz meg, de ahol korabban tiltottam ipv6ot, ott nem is jott elo a thunderbird hiba, vagy emiatt mas hiba.

( khiraly | 2023. 01. 22., v – 00:30 )

Jolvan-jolvan. Menjen mindenki IPv6-ra, hogy vegre legyenek ujra szabad IPv4-es cimek!

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( NevemTeve | 2023. 01. 22., v – 17:37 )

Szerkesztve: 2023. 01. 22., v – 17:42

Ahogy én érteni vélem, az IPv6 által okozott problémák száma mára meghaladja az általa megoldottakét, pedig mindenki a legjobbat akarta és ráadásul nagyon sok bizottság is volt a szabványosítási folyamatban.... Várjunk csak, egész véletlenül nem az ilyesmit hívják 'fősodratú idealizmusnak'?

Komolyabban: harminc évvel ezelőtt még nem tudhatták, hogy jelenleg nem feltétlenül az a cél, hogy a legutolsó villanykörte is direktben elérhető/címezhető legyen kínai haxorok számára.

Ne is mondd, mire rájöttem, hogy rokonomnak ezért szakad a wifi kapcsolat a telefonján... (nem, nincs mac-re szűrés az ap-n). Látszólag kapcsolódva marad, de egyszercsak nem tud forgalmazni, manuálisan kell wifi ki-be kapcsolással visszahozni. Mióta letiltottam a mac randomizálást azóta teljesen stabil.

Régóta vágyok én, az androidok mezonkincsére már!

( kruska v | 2023. 01. 31., k – 13:59 )

Egyik régi ex-ügyfelem költözött a weboldalával A tárhelyszolgáltatótól B tárhelyszolgáltatóhoz. A DNS természetesen egy C szolgáltatónál van.

B szolgáltató megadta neki, hogy mit írjon át a DNS-ben - mi az új tárhely IP címe. C szolgáltató szépen megcsinálta.

Napokig ment a szenvedés / egymásra mutogatás, hogy miért nem megy. A látogatók egyik fele látta az új helyen az oldalt, másik fele pedig még a régi szolgáltatónál lévő utolsó állapotot látta - a karbantartás oldalt. Néhány nap után ügyfél kétségbeesetten felhív, hogy tudnék-e segíteni, mert A/B/C szolgáltató szerint minden oké, de mégsem tudják használni a weboldalt.

Mivel egy IPv6 topikba tettem a sztorit, figyelmes olvasó rájöhetett rögtön, hogy mi volt a baj: az A szolgáltatónál volt a tárhelynek IPv6 címe, B-nél nem. A C DNS szolgáltató csak A rekordot módosított (hiszen ezt kérték - fel sem merült, hogy van AAAA cím is), így az IPv6-ról érkező látogatók (akik azért voltak szép számmal) a régi oldalt láthatták.

Bevallom, nekem sem esett le rögtön, hogy hol keressem a problémát.