UPC IPv6

IPv6

Kis összefoglaló lenne a témában, amelyet frissítenék, jelenleg az alábbi információk állnak rendelkezésemre,

Ahogyan itt már volt róla szó: http://hup.hu/node/127426#comment-1925950
Facebook-on írtam a https://www.facebook.com/upcmagyarorszag oldalán üzenetet, ahol pár üzenetváltás után kaptam egy telefonos visszahívást.

A megbeszéltek szerint jelenleg a UPC DS-Lite megoldást használ,
https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite…
és szükséges a modem csere nálam, mert elméletileg csak a Ubee EVW3226 használat esetén tudják "bekapcsolni", ha netán nem tetszene, akkor bármikor vissza lehet állítani a "régi" rendet.

A megvalósításról bővebben majd akkor, ha megjött a modem, de addig is már látszik pár megkötés IPv4 fronton,
- a modem/router nem lehet bridge mode-ba kapcsolni
- nincs IPv4 port-forward, mivel maga a router sem kap publikus IPv4 címet

Valószínűleg az alábbiak itthon is érvényesek,
https://support-en.upc-cablecom.ch/app/answers/detail/a_id/1259/~/ipv6-…

Tehát a facebook-os megkeresés nem urban legend, bár nem értem, hogy miért nincs erről bővebb információ.

( mauzi v | 2015. 11. 17., k – 12:53 )

Az egy komoly dilemma, hogy melyik a jobb:

- IPv6 lehetősége azzal a kompromisszummal, hogy IPv4 esetén carrier-grade NAT mögé dugnak
- Van rendes IPv4, de nincs IPv6

Kérdés az, hogy mi lesz hosszú távon.

- A UPC dönthet úgy is, hogy mivel a júzereinek nagy részét úgyis átrugdossa carrier-grade NAT-ra, ezért a fennmaradó néhány felhasználónak maradhat a rendes IPv4, hiszen felszabadul egy rakás IPv4 cím.
- Meg dönthet úgy is, hogy előbb-utóbb a homogén környezet elérése érdekében kivétel nélkül mindenkit átrak carrier-grade NAT-ra.

Ha az utóbbi forgatókönyv valósul meg majd meg, akkor tulajdonképpen bármikor jöhet a DS-Lite, csak szóljanak előtte, és felkészülünk rá.

Egyébként:
Ha a DS-Lite úgy működik, hogy a CPE/felhordó infrastruktúra IPv6 only, és az IPv4 egy tunnelben megy ki az endjúzernek, akkor miért nem lehet úgy implementálni, hogy a tunnelben ne csak a carrier-grade NAT-olt v4 prefix tudjon kimenni, hanem igény esetén rendes publikus v4 prefix is? A tunnelnek tök mindegy, mit visz.

( vl v | 2015. 11. 17., k – 14:26 )

Hát, kis túlzással élve: ez nem sok mindenre jó ebben a formában. Mármint az r=1bit júzereknek nyilván jó, de nekik kb. minden mindegy.

Nem, de amíg ilyen gyér az ipv6 penetráció, nem nyírhatod ki az ipv4-et. Először párhuzamosan kell tolni, aztán pár év múlva mikor már mindenhol lesz ipv6, akkor el lehet kezdeni natos ipv4-et adni, aztán 10 év múlva meg teljesen meg is lehet szüntetni akár.

Ja, csak hát nem most kéne elkezdeni a töküket vakarni, ezt már a upc-nek is 5 éve el kellett volna kezdenie csinálni. A té is megrekedt ennél a béta dolognál, pedig az elején nagy dirrel durral mentek bele, csak mintha elfogyott volna a lelkesedés. Bár legalább a szervereik ipv6 kompatibilisek nagyrészt.

"A té is megrekedt ennél a béta dolognál," Roszabb, ugyanis ez is véget ért, most a NAT olás miatt nincsen ipv6, hivatalosan a test véget ért és ennyi, ha lesz valami majd szólnak.

Gondolom annyira nem releváns az ipv6, hogy ami működött, azzal se foglalkoznak hogy tovább menjen.

Fedora 22, Thinkpad x220

De hiába kéred, nem adják. Itt most nem arról van szó, hogy technikailag nem lehet, hanem hogy mit adnak. És a fentiek alapján avgy ipv4 only van (akár 3 ip címmel ugye!), vagy van natív ipv6 de natolt ipv4. És ha mindenki natolt ipv4 mögött lesz, akkor ki lesz az aktív seeder ugyebár? Ez már az átlagjózsit is érinteni fogja.

Nem, de itt több szempontból sem ez a kérdés.

Az IPv4 címek elfogyását elég hosszú időre tökéletesen megoldja a szolgáltató-szintű NAT - sajnos. Sajnos, mert ez hátráltatja az IPv6 szolgáltatói terjedését, nincs elég motiváció.

Másrészt meg itt az a kérdés, hogy hogyan tudna mindenhol IPv6 lenni, ha egyszer nem adunk azoknak IPv6-ot, akinek rendes IPv4 címre van szüksége - ez ugye azért gázos így, mert ezek kb. pont azok az emberkék, akiknek amúgy az IPv6 a leginkább kellene, így most tunnelezgethetnek...

"Az IPv4 címek elfogyását elég hosszú időre tökéletesen megoldja a szolgáltató-szintű NAT"

Pár száz millió torrentező azért bánni fogja, hogy nincs hova csatlakozni. Erre megoldás lehet olyan technológia, ami CGN esetén is tud portot nyitni (PCP). Más kérdés, hogy ezek mennyire terjednek el.

"Másrészt meg itt az a kérdés, hogy hogyan tudna mindenhol IPv6 lenni, ha egyszer nem adunk azoknak IPv6-ot, akinek rendes IPv4 címre van szüksége - ez ugye azért gázos így, mert ezek kb. pont azok az emberkék, akiknek amúgy az IPv6 a leginkább kellene, így most tunnelezgethetnek..."

Ebben akár még igazad lehet, viszont a szolgáltatók rühellik a DS-t, az üzemeltetési overhead miatt (pl. dupla monitoring)

Azért rühellik, mert nincs mögötte business case, ezért csak business-as-usual tudják bevezetni. Az, hogy hosszútávon ezzel mindenki rosszabbul jár, meg a jelek szerint senkit sem érdekek.

Itt lenne a felelőssége a tövényalkotóknak, hogy ebben az esetben szabályozzák a piacot, és kikényszerítsék a változásokat.

"Pár száz millió torrentező azért bánni fogja"

Vajon ez érdekli a szolgáltatót? Aki ért hozzá kéri vissza majd az ipv4 címét. Én is így tettem, bár más okból (használhatatlan volt a net engedélyezett ipv6-tal). Aki pedig nem ért hozzá max morgolódik hogy gyenge a net, de a szolgáltatónak nem fog sírni hogy nem tud illegálisan töltögetni.

( Sanya v | 2015. 11. 17., k – 15:09 )

akkor a tplink 1043nd v2.1 routeremet lassan frissíthetem 3.0-ra

( uid_15480 v | 2015. 12. 03., cs – 20:49 )

Eddig jutottam FB oldalukon.

"Az IPV6 jelenleg tesztelés alatt áll, a széleskörű bevezetésre pontos dátum jelenleg nem ismert."

Majdecce' :D

Üdv. bnv

( 1soproni | 2015. 12. 07., h – 12:00 )

Bekapcsoltattam ma a ds-lite opciót. Először az ügyintézőt kellett meggyőznöm, hogy az én modemem (ubee evw3226) is képes az ipv6-ra, mert ő csak valami új Hitron modemekről tudott.
Ahogy látom, a modemem kapott 2 IPv6 címet. Egyik /64-es, a másik /128-as.
Ha minden igaz, akkor a belső gépek kapnak (privát) ipv4 és (/64-es) ipv6 címet is.
DNS-ként csak IPv4-en működik a modem. Nem is enged ipv6-os dns-t kiosztani, mert azt mondja hibás DNS-t adok meg.

A böngészős tesztek azt írják, fel vagyok készülve az IPv6-ra.
"ping6 hup.hu" működik.
"nslookup hup.hu" nem ír ki ipv6-os címet.

Most akkor alapból ipv4-et, vagy ipv6-ot használok?

Mert ahhoz olyan NAT-oló berendezés kell, ami képes a GRE tunnelt NAT-olni. Ezek szerint a szolgáltató szara nem ilyen... Tessék bejelenteni, hátha megcsinálják. Amúgy fent valaki kérdezte, hogy miért nem jó a privát IPv4 cím, hát többek között az ilyen szopások miatt.

El kell, hogy keserítselek!
A pptpd (ubuntu 12.04|16.04) csak ipv4-en listenel.
Amíg nincs a szerver oldalon v6 listener implementálva, addig bármilyen kliens készítése is felesleges.
Gyorsan körbenéztem, a legtöbb esetben inkább az volt a cél, hogy V6-os címet kapjon (és tudjon tunnelezni magának) pptp kapcsolaton keresztül.
Esetleg lehet egy patchet írni a gyári pptpd brachba ami ipv6 listenert is tartalmaz.

( Fisher v | 2015. 12. 08., k – 07:37 )

Nálam egy Cisco EPC3212 van, ezzel megy valakinek az IPv6? Elsősorban az érdekel hogy működik-e, nem az, hogy elvileg mennie kell :D
Mögötte saját debianos router van, szóval az meg majd az én problémám lesz.

A MyUPC nekem is azt írja, hogy "Tájékoztatjuk, hogy a Protokoll beállítások módosítása nem lehetséges.", pedig ezzel a modemmel volt már bekapcsolva az IPv6.
Kérdeztem a UPC-t a facebook oldalon, hogy egyáltalán mire való ez a Protokoll beállítás, mire ez írták: "Jelenleg nincs pontos információnk, hogy az általad leírt menüpontban milyen lehetőség lesz elérhető, azonban az IPv6 funkció jelenleg is bekapcsolható, amennyiben olyan eszközzel rendelkezel. A korábban megírt ügyfélszám alapján, úgy látjuk, hogy a nálad kint lévő eszköz képes, ezen funkció működésére. Amennyiben szeretnénk beállítani ezt a protokollt, kérjük, jelezd felénk, hogy megtehessük azt."

( csardij v | 2016. 12. 01., cs – 13:07 )

A mai nap bekapcsoltattam én is az IPv6-ot. A myupc-n a Protokoll beállítások alatt nem volt semmi, de az ügyfélszolgálat gyorsan megcsinalta. Ahogy nézem most annyiba módosult a dolog, hogy a Protokoll beállítások alatt ki tudom kapcsolni az ipv6-ot, de azt írja is, hogy vissza már nem lehet itt.

TECHNICOLOR TC7200 modem routerem van. Amit meg kellett tenni, hogy a modem admin felületén a Basic > Local Area Network alatt megadni IPv6-os DNS szervereket (a googleet adtam meg).

Párszar restartolt a router, aztán utána már wifi-n keresztül is ipv6-os cím jött ahogy kell.

Alapból be nem enged semmit IPv6-on és lehet felvenni szabályokat (mint a port forward), vagy akár az egészet kikapcsolni és akkor mindent el lehet érni közvetlenül a netről.

pptp-s vpn nem megy ipv4-en, de ez várható volt, viszont ipv6-on se megy, gugli alapján ez viszont a windows-ba lévő valami hiba.

szerk.: hát, elég nagy hiba, úgy tűnik, hogy nem tudja a windows 10 a pptp-t ipv6-on. Ha ipv6-os címet megadom kiszolgálónak, kiveszi a listából a pptp-t.

Ezt most cáfolnám: ma kapcsoltak át IPv6 konfigra, és ezt írja a LAN oldalra a router (Technicolor TC7200):

IPv6 Address: 2a02:ab88:6385:xxxx:xxxx/64
IPv6 Prefix: 2a02:ab88:6385:xxxx::/57

Gyorsan belőttem egy eszközt, annak rendje és módja szerint kapott egy prefixet DHCP-PD-vel, minden szép és jó.

A DS-Lite MTU dolgot egy rohadt nagy gányolásnak tartom (ha jól értelmezem az RFC-t, ezt teljesen el kéne rejtenie, és a dont fragment csomagokat is transzparensen megoldani az infrastruktúrának).

Elég kulturált, hogy alapesetben egy bekapcsolt ipv6 tűzfallal jön az eszköz, és az ICMPv6 korrektül megy. (szívtam sokat konzumer routerekkel, vagy a tűzfal konfigurálhatóság, vagy icmpv6 működés miatt)

Értem, hogy Te csalódtál benne, vagy visszaraktad Ipv4-re, de nekem most lett beállítva a ds-lite, és az openwrt config-ba kérnék egy kis segítséget.

Mekkora ranget ad végül is a UPC? /57-et ?

A ' option ip6assign ' -be te mennyit írtál?
A ' option ip6prefix ' -be te mennyit írtál?
A '
config globals globals
option ula_prefix ' -be írtál valamit?

Köszi szépen!

Szerintem előbb nézd meg, hogy a te esetedben milyen címzést kapsz és működik-e a dhcp-pd. Itt az elbeszélések alapján az én technicoloros 2 hetes időszakom az egyetlen, amikor volt ilyen :)
Ha csak a LAN-ra kapsz egy /64 -et, akkor nincs más út, mint a szolgáltatói eszközt használni.

Nos, így egy nap alatt, arra jutottam, hogy valami nem kóser. IPv6 teljesen okés, de az ipv4-es dolgok nagyon akadoznak. VPN (l2tp/ipsec ipv4 felett) állandóan ledobál (előtte soha nem volt ilyen, most sincs ha upc wi freevel megyek), a SIP-es asztali telefon elveszti a kapcsolatot, bejövő hívások sokszor nem jönnek meg a telefonra (még ha a telefon szerint regisztrálva is van).

Még vizsgálom mi lehet pontosan, de mivel semmi más nem változott erre a NAT-os ipv4 dologra tudok tippelni.

(nincs semmilyen saját router, stb. csak a UPC által adott eszköz van, az volt eddig is és most is a router)

A NAT egy dolog, de az MTU sem 1500 bájt a DS-Lite tunnel miatt. (hanem 1460 bájt)
Path MTU discovery működik, vagy szűrsz ICMP-t?
(A TCP alapú dolgoknak pedig elvileg mennie kellene, mert a UPC eszközén van adjust-mss)

A dolog nem túl logikus, mert L2TP esetén csak UDP van az IPSec protokolljain kívül. Meg aztán a SIP is UDP fölött rohangál...

A VPN szerverre gondolsz, hogy ICMP szűrve lenne? Tudtommal nincs (nem az enyém a szerver), pingetni lehet, tehát ez a része megy.

Azt vettem észre, hogy ipv4-es oldalak esetén is ha egy nagyobb post menne, akkor is beáll mint a gerely.

Lehet a windowson is kéne ilyen MTU dolgot állítani, mint anno az ADSL korszakba? Mert tisztára olyan érzése van az embernek.

szerk.: ahha, átállítottam a wifi adapteren az MTU-t 1400-ra, így már tudok nagy POST-ot küldeni hiba nélkül.

Azt vettem észre, hogy ipv4-es oldalak esetén is ha egy nagyobb post menne, akkor is beáll mint a gerely.

Ez a tipikus esete a "nem megy a PMTU discovery" c. történetnek. Jellemzően valahol valaki útközben Túlokos Tibit játszik, és eldobálja az ICMP fragmentation needed csomagokat, "merazicmpnembiztonságos!"

( norbertkiss | 2016. 12. 16., p – 15:35 )

Hát én ma reggel próbáltam tőlük ipv6-ot szerezni nem sok sikerrel.
Az első kollégának halvány lila gőze se volt, hogy miről vakerolok neki, így átadott egy másiknak.
Ő már sejtette mit szeretnék, azt mondta 5 perc múlva lesz ipv6-om. Kérdeztem tőle, hogy milyen tartományt kapok, marad-e publikus ipv4 címem, hogyan kapom az ipv6 címeket (slaac, dhcp), de ezt egy kínos csönd követte. Semmi gond, gondoltam, majd meglátjuk.
A modememmel (ubee evw3226) csináltak valamit, mert újraindult. Viszont az égvilágon sehogy nem sikerült ipv6-ot kicsalni belőle, viszont maradt publikus ipv4-em. Jó sokszor újraindítottam a routert (modemet), de semmi változás.
Délután ismét felhívtam őket a problémámmal, átkapcsoltak egy szakihoz, aki közölte velem, hogy csak néhány optikán van ipv6, nem az összesen. Nekem csak az ő berendezéseikre raktak ipv6-ot, nekem olyanom nem lesz, viszont átraknak privát tartományba ipv4-en is. Mondtam neki, hogy meg ne próbáld, vissza mindent!!! Azt mondta OK, akkor visszacsinálja, ami meg is történt. Kérdeztem mikor lesz normális ipv6, azt mondta nem mostanában, viszont mindez az ügyfelek védelme érdekében van. Ekkor búcsúztam el tőle, hogy engem ezzel a baromsággal ne etessenek, tartogassák a r1 júzereknek...
Fuck UPC!!!

Ja, és mindezek után kaptam tőlük egy e-mailt, amiben sajnálkoztak, hogy nem tudtak segíteni, és volt benne egy rahedli link videókra, ami totál kezdőknek való. Ez kb olyan érzés volt, hogy nesze hülye tanulj, ha már ilyen alap vagy, hogy ipv6-tal akarod szennyezni a hálózatodat!

( xc0m v | 2017. 04. 10., h – 09:51 )

Érdemes lehet váltani public ipv4-ről ds-lite-ra? On-line játékok, SIP, Skype, Steam stb. működnek már ipv6-on?
A NAT megszűnése mondjuk pozitív, de tűzfal oldalról így több biztonságra intézkedésre van szükség, nem?

( lcsaszar v | 2020. 01. 07., k – 12:02 )

Sziasztok! Mi a helyzet így 3 év után UPC/IPv6 fronton? Ügyfélszolgálat nekem valami zavaros választ adott ez irányú kérdésemre, miszerint tudnak adni IPv6-ot, de akkor az IPv4-et elveszik (ami egyébként NAT-olva van, nem publikus címen). Szerintem ez marhaság, de kérdés, hogy van-e olyan eszközük, ami támogatja, jelenleg Technicolor TC7200U megy, az adja a VoIP-t is.

Nalam december 19-en kotottek be a szolgaltatast, Compal ch7465lg modemet kaptam. Alapbol IPv6 engelyezett volt, a WAN oldali /128 cim mukodott is, de a LAN oldalra prefix delegation-el kapott /64 nem mukodott es hiaba mondtam az ugyfelszolgalatnak, hogy ez egy routing hiba az UPC sajat rendszereben, nem ertettek a problemat es mindenki vissza akart rakni IPv4-re. A problema vegul megoldodott, azota rendben mukodik.

( lcsaszar v | 2020. 01. 27., h – 19:45 )

Én is kértem az ügyfélszolit, hogy adjanak IPv6-ot (pontosabban hibabejelentést tettem, hogy nem működik). Telefonon azt a választ kaptam, hogy akkor most melyiket kérem, IPv4-et, vagy IPv6-ot, mert ezek egymást kizárják. Mondtam, hogy ezt nem értem, ezek tudtommal párhuzamosan működhetnek. Az ügyintéző szerint nem, döntsem el, hogy melyik kell. Mondtam, akkor maradjon az IPv4.

Bár egy próbát megért volna, hogy kérem az IPv6-ot, tényleg megszűnt volna az IPv4?

A másik: lehet, hogy a modem (Technicolor TC7200U) nem képes rá, akkor hoznak másikat, azt nem tudom bridge-be tenni, szóval el szeretném kerülni a macerát. Nekem ilyen Connect Box-ot ne adjanak, el sem fér, ránézésre is utálom.

Bah, hülyén van nekik megfogalmazva. Kétféle profilt tudnak beállítani a végpontra:

1.) "IPv4-es profil": natív IPv4 publikus IP címmel, nincs IPv6

2.) "IPv6-os profil": DS Lite - natív IPv6, az IPv4 pedig kitunnelezve IPv6 fölött, privát IP címmel.

IPv6-os profilnál a DS Lite tunnelét a végberendezés (a "modem", azaz valójában: router) végződteti, tehát nem lehetséges vele "bridge" mód.

#facepalm... Nem mondta még nekik senki, hogy rá kéne nézni arra a krva naptárra, hogy 2020-at írunk? Ilyen tunnelezzük az egyiket a másikban megoldás akkor, amikor a legfosabb SoHo szutyok is natívan dual stack képes minimum szégyenmozdonyt érdemel...

A tunnelezésből az átlagjúzernek sok baja nem lesz. Az MTU kisebb lesz 1500-nál, de az ICMP-t szarul beszélő hostok problémáját az adjust-mss/mssclamp tűrhetően áthidalja.

Két baj van:

  • a tunnelben csak CGNAT címet adnak, elvi lehetősége sincs a publikus IP-nek,
  • az IPv6-ra egyetlen /64-et kapsz, így nem tudsz saját routert/hardveres tűzfalat sem használni.

A Digi meg tudja csinálni normálisan

Ezt majd akkor írd le, ha az üzleti, feláras fix IPv4 címes előfizetéshez hajlandóak lesznek fix IPv6 prefixet adni...

Másrészt, a PPPoE túlvégére szintén csak egy darab /64-et adnak - így a saját routeredet ugyan tudod használni, de további subneteket már nem tudsz csinálni - mintha az RFC-ben is végfelhasználóknak ajánlott /56 mérhetetlenül drága volna.

Miért ne tudnál? Mi az akadálya? (tényleg érdekel) 

A 6177-es RFC-ben írnak az ajánlott kiosztásról és ott a /64-et is kielégítőnek találják, de ezen is lehet változtatni.

Tulajdonképpen nincs kőbe vésve, hogy mekkorát kell adnia az ISP-nek. 

...úgyis jönnek...

IPv6 esetén a LAN szegmens /64, ellenkező esetben nem működik a SLAAC.
IPv6 nem a NAT-olásról szól.
--------- Hálózatok otthon (power user) -----------
- otthoni belső hálózat
- otthoni kütyühálózat
- otthoni vendég WiFi
- ...

RIPE ajánlás: minimum /56 átadás a szolgáltató részéről a végfelhasználónak. Végülis egy kisebb szolgáltató is kap /32 vagy szélesebb tartományt, amiből 16 millió háztartásnak tud adni /56-ot. Hangsúlyozom, kisebb szolgáltató.

Miért ne tudnál? Mi az akadálya? (tényleg érdekel) 

Az SLAAC úgy működik, hogy az IPv6 cím első 64 bitjét kapod a hálózattól, az utolsó 64 bitjét Te határozod meg magadnak. (pl. Ethernet hálózaton a host MAC címéből képződik.)

SLAAC használata mellett tehát nem lehetséges a /64-et tovább felosztani. Manapság az SLAAC a legelterjedtebb címosztási mód. (A DHCPv6-ot pl. az Android egyáltalán nem támogatja.)

Egyébként azt nagyon szeretem, hogy ezt nagyjából minden egyes IPv6 topicban le kell írni, mert minden alkalommal megkérdezi valaki. Az összes IPv6 tutorial az ehhez hasonló alapvető információk leírásával kezdődik. (RTFM)

Igen, le kell írni, hogy te SLAAC-ot szeretnél használni és neked ebben az esetben nem jó. 

Mivel vannak más esetek (említett DHCPv6 pl.), így arra megfelelő lehet a /64 is.

Mivel nem vagyok gondolatolvasó (szerencsére), így nem tudhatom, hogy neked mi a megfelelő megoldás és miért. Most, hogy leírtad az egyik szükséges feltételt, így érthető.

Az RTFM-re nincs szükség, elég az RTM. 

...úgyis jönnek...

Ez azert nem annyira nezopont kerdese. Miutan a SLAAC a legelterjetteb IPv6-on egy SLAAC mentes alhalozatot gyakorlatilag nem lehet teljesertekunek tekinteni. Ahogy mar irtak fent ebben a thread-ben, egyszeruen vannak olyan eszkozok amik nem fognak mukodni enelkul. Ettol meg csinalhatsz alhalot es az lehet, hogy neked pont jo lesz, de az eredeti problema fenn all, aki _ugy_altalaban_ alhalot szeretne annak tobb kell mint /64, vagyis ertheto az igeny, hogy lehessen nagyobbat kerni a szolgaltatotol (vagy hogy keres nelkul is nagyobbat adjon).

Ez azert nem annyira nezopont kerdese.

No igen, meg az RFC-k sem csak dísznek születnek, remélhetőleg. Egyértelműen meg vannak fogalmazva az alábbiak:

- Tényleg ne csináljunk /64-nél kisebb alhálózatot, még akkor se, ha nem használunk benne SLAAC-t. Egyrészt azért, mert hátha egyszer mégis szükség lesz SLAAC-re, másrészt, kerüljük el az IPv4-nél előállt, kényszerű fragmentációt, törekedjünk az egységes, átlátható konfigokra.

- (régebbi RFC) - A végfelhasználónak adjunk legalább /56-ot, mert a végfelhasználó magától értetődő igénye lehet egynél több subnet létrehozása. A nagyobb végfelhasználóknak, akinek a 256 darab subnet kevés lehet, adjunk /48-at, mert 65536 subnet tényleg elég "mindenre".

- (újabb RFC) - Minden felhasználónak adjunk /48-at, hogy ne kelljen mérlegelni, hogy a végfelhasználó kicsi-e vagy nagy, és hogy szép, egységes konfigokat gyárthassunk.

- Fölösleges az IPv6 címek pazarló kiosztásáról beszélni, mert minden ISP-nek kényelmesen allokálható akkora prefix, hogy az összes végfelhasználójának vígan tudjon akár /48-at adni.

Értem én, de az előbbi 2 mondatom együtt értelmezzétek.

Az a Digi elhibázott lépése, hogy /64-et osztanak az RFC ellenére.

Arra akartam rávilágítani a fenti 2 mondattal, hogy lehet, hogy a /64 az eset 99,9%-ban nem jó, de lesz 0,1%-akinek jó lehet.
Ezért nem zárnám ki a 0,1%-t, annak ellenére hogy a többségnek nem jó és szembe megy az RFC-vel.

Remélem, így már érthetőbb a mondanivalóm.

...úgyis jönnek...

( lcsaszar v | 2020. 01. 30., cs – 19:35 )

Sikerült megértenem a UPC-t. Tehát tényleg csak IPv4-et, vagy csak IPv6-ot szolgáltatnak. Utóbbi esetben ők tunnelezik az IPv4-et az IPv6-os hálózatukon. Gondoltam, nem kísérletezek, maradtam az IPv4-en.

Az IPv6-ot jelenleg tunnelbrokeren keresztül érem el, amire a routerem kapcsolódik. Tesztelés indul :-)

https://hup.hu/cikkek/20191205/hogy_tudnek_elkezdeni_legegyszerubben_is…

"Hogy tudnék lekezdeni legegyszerűbben ismerkedni az IPv6-tal?

...

Ebben az írásban azt mutatom be, hogy hogyan lehet egy Tunnel Broker segítségével IPv6-os kapcsolatot létesíteni a nagyvilág felé."

( fairlane | 2020. 02. 01., szo – 10:38 )

Szerkesztve: 2020. 02. 01., szo – 10:39

törölve

...úgyis jönnek...

( fairlane | 2020. 02. 01., szo – 13:57 )

Szerkesztve: 2020. 02. 01., szo – 13:57

törölve

...úgyis jönnek...

( asm v | 2020. 04. 01., sze – 18:18 )

UPC internetre fizettem elo, kaptam egy Connect Box-ot hozza. IPv6 mod aktivalva by default.

Akkor ezzel nem oldhato meg, hogy egy openwrt routert is rakotve az openwrt-re kapcsolodo kliensek kapjanak IPv6-os cimet?

Ha ilyet tennek, akkor mi ertelme megtartani az openwrt-t? Hiszen a kliensek a Connect Boxra kapcsolodhatnanak direktben.

Azert szeretnek openwrt-t hasznalni, hogy eros kontroll alatt tartsam a kulonfele IoT eszkozoket es kamerakat (VLANok, firewall, stb.).

Most ebbe ugy tunik, hogy jol belerondit a UPC. Valoszinu vissza kell valtanom a publikus IPv4-re (hogy tudjak DDNS-t hasznalni), amit nem tudok most elvegezni, mert a Vodafone-os rebranding miatt szetesett a weboldal.