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.
+1
velemenyem szerint az IPv6 meg mindig nem all keszen a vilagszintu bevezetesre, mindenki az ISP -k stb... is tul lazan veszi ahhoz, hogy ez megtortenjen. jelenleg inkabb szivni lehet vele, mint hasznalni.
FBK
Míg olcsóbb, venni v4 címeket, vagy akár NAT olni, addig nem is fogják komolyan venni.
Fedora 38, Thinkpad x280
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
Egy Class C IPv4 blokk ára 1000 euró + évi 400 bérleti díjj. IPv6 esetén egy /48-as osztály 50+50 euró. 10 éve az IPv4 kb 200+50 euró volt.
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 38, Thinkpad x280
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 38, Thinkpad x280
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.
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 38, Thinkpad x280
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
Es onnantol mar csak 5-10 ev kell, mire a forgalomban levo eszkozok kritikus tomegen lesz olyan patchlevel, amiben mar benne van a feature. :)
Mert nincs rá kényszer, hogy váltsanak. Olvasd el a hozzászólásom minden részét.
Az igaz, hogy DHCPv6-ot nem támogat, de SLAAC-RDNSS-t igen, és az pont elég is.
Otthon lehet, de egy cégnél/intézmény stb ahol szeretik kontrollálni a dolgokat már nem feltétlen.
Fedora 38, Thinkpad x280
Nem nagyon értem, hogy mit keres egy céges hálózaton Android telefon (meg más se). Max. guest hálón, de azon se. Ott a publikus IPv6 címe, a levelezést el lehet érni kívülről, teljesen felesleges beengedni a hálózatra. Több okból sem.
trey @ gépház
Attól, hogy te nem érted az nem jelenti, hogy nincsen :D
Szóval ha nem is saját telefonod, de a céges eszközök mehetnek a hálózatba, mert kell(het) :D
Fedora 38, Thinkpad x280
Elnézést, hogy értetlenkedek, de minek kellenek a céges androidos eszközök a céges hálózatba? Mit jelent itt a "hálózat"?
trey @ gépház
Akkor csak egy hirtelen példa, ami nem is messze van tőled: https://youtu.be/P7fon3hE26g?t=763
Fedora 38, Thinkpad x280
Megyek egy megbeszélésre, nem az asztali gépet :-) / nótost viszem, hanem a mobilt, ami úgy is a zsebemben van. Nem, a mobilnet nem nyert, mert belső chat platformot, levelezést, akármit is el kell közben érni.
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.
Hát, OK. Nekem szimpatikusabb megoldás, hogy mindenki mobilneten + egy guest hálón van. Mindenkinek joga van megválasztania a maga mérgét :)
trey @ gépház
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.
Nálunk fejek hullanának a porba ha kipörgetnénk a belső hálót wifire...
"A megoldásra kell koncentrálni nem a problémára."
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.
Cert alapon authentikáló wifi, ami nem direktben a "melós" vlan-ba rak bele teljesen vállalható megoldás egyébként.
Ennyire azért nem durva a helyzet, de lássuk be elegáns lenne. ;)
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.
Amíg van... :D
https://hup.hu/node/166776
Bocs, ha voltmár.
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 38, Thinkpad x280
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
Mert így olcsóbb.
Fedora 38, Thinkpad x280
+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.
Az még odébb van, egyelőre szégyenszemre a google compute engine sem támogatja a ipv6-it a VPS-eken.
Fedora 38, Thinkpad x280
Engem eddig a hibás berögződés (is) megvédett. :)
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.
Ha csak link-local IPv6 címeket használunk a belső hálózatban, akkor az nem routolható kifelé, nem? Tehát ezzel szintén megvalósul, hogy kintről nem elérhető az adott eszköz. De lehet, hogy rosszul értelmezem, akinek van ezzel kapcsolatban tapasztalat, kérem ossza meg!
Ez engem is érdekelne. Alapjában véve két probléma van itt: Nem tudom, hogy mi a szolgáltatómnál a default, és nem biztos, hogy van lehetőségem ezt szabályozni az általa adott eszközön. Így aztán az ember eljut oda, hogy inkább tiltással oldja meg az egészet.
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 38, Thinkpad x280
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.
És miből gondolod, hogy a fent említett opció nem default beállítás ? Mondjuk ezt valaki megleshetné :>
Fedora 38, Thinkpad x280
ASUS Router-eken alapból tiltva van a külső hozzáférés, a kivételeket kell hozzáadni. Meglepne, ha nem ez lenne SOHO kategóriában a default (helyesen).
https://naszta.hu
> 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
É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
"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett"
és 100 éve még boszorkányt is égettek
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.
Ez egyre furcsább. Bár én T-től ADSL netet kapok, lehet ez is számít.
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.
http://www.hit.bme.hu/~lencse/publications/IPv6-konyv.pdf
http://ipv6forum.hu/sites/ipv6forum.hu/files/03.Mohacsi_Janos_ipv6_diohej.pdf
https://www.tilb.sze.hu/tilb/targyak/GKNB_TATM004/09-IPv6.pdf
https://www.tilb.sze.hu/tilb/targyak/GKNB_TATM004/10-IPv6-transition.pdf
http://www.cabrillo.edu/~rgraziani/ipv6/Rick-Presentations/IPv6-Fundame…
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
Igy ha nem tudnak a gondokrol nem is fogjak kijavitani, nagyon hasznos :)
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
> bizonyos DNS szerverek egyszerűen nem adnak AAAA rekordot, emiatt bekapcsolt IPv6-tal akadozik az elérés
He?
Ha a DNS szerver csak "A" rekordot old fel, akkor a forgalom el sem indul IPv6 irányba, tehát nagyjából olyan, mintha az IPv6 be sem lenne kapcsolva.
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.
"Ami még eszembe jut: IPv6 nagyobb overhead, ami mobilon már számít."
Ezt, hogy érted ? A mai csúcs mobilok erősebbek mint 10éve a pc-k :D Az ipv6 kb 20 éve létező dolog, nem hinném, hogy bármelyik mai értelmes hw-nek gondot jelentene.
Fedora 38, Thinkpad x280
A traffic overhead-re gondoltam. Az ipv6 ip header 40byte, az ipv4 20byte.
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.
Szép, szép, de minden ilyennél a protokoll két oldalú: a szerver oldalon tömörít, a kliens oldalon kitömörít. Vagyis a web szervert és a böngészőket is fel kell rá készíteni.
Másrészt általában nincs hardver gyorsítás.
Szerintem félreérted ezt a technológiát. A böngésző és a webszerver semmit sem tud erről.
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.
IPv6 validation for https://hup.hu
trey @ gépház
bad c0de :D
Így biztos beugrik a cím.
dead:beef is kedvelt marker
És tényleg! 10x!
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
Boldogok a tudatlanok? Egyszer kéne beállítani az IPv6-ot rendesen, és nem lenne vele gondod.
Mert (feltéve ha ha valóban nincs jól beállítva) akkor Hirtelen szükségem lesz rá? :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Kérdés, hogy SOHO kategóriában miért kell akár egyszer is beállítani? Miért nem elég a "bedugom és működik" elv?
Off: Ja, hogy rendesen kell, ez a nyitja! Te lennél az én barátom, hozzám is folyton olyan felhasználói igények jönnek, hogy "nem érdekelnek a részletek, csak jó legyen"... Azt szoktam mondani, hogy a registry-be írják be, hogy "troubles=disabled"
> "nincs szükségem rá"
Mindig károgok akkor, amikor a Google visszaél az erőfölényével, de egyszer mondhatná már azt a Google és a Facebook, hogy fél év múlva már csak IPv6-on lesznek elérhetőek. Egyből lenne motiváció...
Igazából akkor sem lenne szükségem rá. :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
A "lusta" szolgáltatóknak hirtelen nagy szüksége lenne rá.
Ezt nem tudom, azt tudom, hogy nekem több mint felesleges. Inkább csak árt, ha engedélyezve van.
"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.)
azert annyira rosszul meg nem allunk ip cimmel hogy tobb szervernek kelljen 1 ip-n osztoznia :)
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
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 38, Thinkpad x280
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
Attól, hogy nincsen NAT, még tűzfal igencsak lesz előttük. Csak nem a MASQUERADE védi meg őket a NAT láncon, hanem -J DROP a FORWARD láncon.
Azt meg már a rendszergazda tudja, hogy az Ő eszközében mit neveznek FORWARD láncnak.
Fedora 38, Thinkpad x280
Oké, akkor kérnék egy listát 100%-ban IPv6 képes, minden hazai előírásnak megfelelő, enterprise szintű tűzfalgyártóról, ami tud site-to-site VPN-t kialakítani tisztán IPv4 hálózattal. :)
trey @ gépház
Azt kérdezd a salsesektől. Nekem eddig/ügyfeleknek megfelelt a mikrotik, openwrt vagy csak sima linux :D
Fedora 38, Thinkpad x280
Hát, ezen már túl vagyunk. Akiktől én megkérdeztem, azok kacaját még mindig viszi a szél. A Mikrotik, OpenWrt és random Linux box nem mindenhol opció.
trey @ gépház
Úgy érted, hogy egy pl.: Cisco ASA ezt a mai napig nem támogatja ?
Fedora 38, Thinkpad x280
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
Persze, ezért is mondtam, hogy amíg olcsóbb lesz lesz NAT-olni, IP-t venni stb addig nagy változásra nem kell számolni. ISP/otthoni szektor, a céges berkek meg ahogy mondod simán +10 év.
Fedora 38, Thinkpad x280
Megnyugtató a Google válasza egyébként :)
Már csak 129 év ;)
trey @ gépház
Mire ért a fully implemented alatt ?
Ugyanis a mai napig nincsen ipv6 címre lehetőség a GCP-ben natív v6-ra, csak http/https proxy-ra. Vicc.
https://cloud.google.com/load-balancing/docs/ipv6
Fedora 38, Thinkpad x280
- nem ide -
https://pcforum.hu/hirek/21903/hivatalos-teljesen-elfogytak-az-internetes-cimek-europaban-is
Hát, akkor lássuk:
IPv6 validation for https://pcforum.hu
This website is not ready for IPv6
:(
trey @ gépház
Mekkora oltás ez már! LOL! Király vagy, és király a Hup!
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 :)
Nem bukott meg, csak az üzemeltetők/szolgáltatók nagyon lusták. Majd fognak szívni jó sokat, és ezáltal a felhasználók is. Lesznek még anyázások rendesen...
Inkább csapatják a dupla NAT-os ipv4-es homenetet, mert az jó...
Nálam szerintem tripla van, de amíg nem akarok online lövöldözni, addig kb mindegy. Lehetne 10 is sorban, azt sem venném észre.
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.
"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett"
és 100 éve még boszorkányt is égettek
"Majd elmentem a sarki pc boltba és vettem 2db ipv6 kompatibilis switchet:)"
Bámulatos hol tart már a tudomány.
Az semmi, de nekem IPv6 kompatibilis Ethernet kábelem van.
É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.
"IPv6 kompatibilis Ethernet kábelem van."
milyen színű? félig fény áteresztő? vagy 80%-s
Robbanás álló vagy csak tűzálló?
"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett"
és 100 éve még boszorkányt is égettek
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.
Mert a LAN-LAN az switch, a LAN-WIFI és LAN-WAN az meg a CPU-n keresztül megy.
Valóban!
Aki tehát arra panaszkodik
annak egy db 4.000 Ft-s eszköz tökéletes megoldás. Nekem még sosem volt vele probléma.
"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett"
és 100 éve még boszorkányt is égettek
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, raspbian, os x~
Ez, ahogy nézem, van Firefoxra is. Thx!
trey @ gépház
+1 rackforest.hu ad mindenkinek aki kéri ipv6 tartományt is az ipv4 mellé, gyorsan felsetupolható; én mindegyik projektemnél használom
~ubuntu, raspbian, os x~
es a docler/servergarden ? a menukben nem latok ilyesmit.
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)
"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett"
és 100 éve még boszorkányt is égettek
Felbuzdúlva, gyorsan be is üzemeltem éjszaka a digis netemen az ipv6-ot! :)
Szolgáltatói támogatás híján a HE tunnelbrokert kötöttem be a routerembe ma délután, egész elfogadható a sebessége a Budapesti PoP-pal, pedig az itthoni dinamikus IP miatt trükkös lett: HE <--6in4--> Linux VPS <--OpenVPN--> OpenWRT.