Telekom IPv6 a láthatáron?

IPv6

http://www.telekom.hu/rolunk/ipv6

Belefutottam ebbe a linkbe. Azt írják, 2016 végétől a lakossági ügyfelek minden technológián (mobilon is) kaphatnak IPv6-ot. Ezen a linken aránylag részletesen leírják a szolgáltatás műszaki részleteit. Én nem értek nagyon az IPv6-hoz, de ez alapján elég korrekt szolgáltatásnak tűnik. Hozzáértők leírhatnák a véleményüket.

( hzsolt94 v | 2016. 10. 25., k – 21:11 )

A műszaki leírásból igazából csak az utolsó pár pont érdekes:

- A HGW Internet felőli oldalára egy /64-es IP subnetből 1 db. IPv6 címet kap.

Korrekt, bár nem tudom minek, de így szokás. (A link-local címek erre tökéletesen elegek lennének, szokott is velük működni, de mégis adnak mellé publikusat.)

- A HGW 1db /56 prefixet is kap, melyből az első /65 prefix a LAN oldalon kerül felhasználásra

Ez vélhetően elírás, a LAN oldalnak /64-nek kellene lennie. (Ha valóban /65 akkor lényegében használhatatlan.) Viszont a /56 előrelépés, rendes saját router esetén ez azt jelenti hogy több belső subnetet is meg tudsz címezni IPv6-tal. (Az egyetlen lakossági IPv6-ot nyújti DIGI-nél erre nincs lehetőséged.)

- A kiosztott /56 prefixek és az Internet felőli 1 db. IPv6 cím csak addig maradnak változatlanok az adott végponton, amíg a kapcsolat meg nem szakad, ezt követően újracsatlakozáskor új cím kerül kiosztásra

Ez szívás, és nem igazán értem az okát. DIGI-nél is így van, egy csomót kell hekkelni mire az eszközök rájön hogy új címe van. Remélhetőleg az IPv6 terjedésével ezt alapból jobban fogják kezelni az eszközök.

- HGW-ekben alapértelmezetten az IPv6 tűzfal úgy van konfigurálva, hogy internet felől ne lehessen IPv6 kapcsolatot létrehozni ügyfeleink helyi hálózata felé. Ez a funkció a HGW beállításaiban, jellemzően kikapcsolható.

Korrekt, bár ha egybites a kikapcsolás (vagy minden vagy semmi sem érhető el) akkor lényegében nem szabad kikapcsolni. Fehérlistáról nincs szó, de remélhetőleg lesz rá valami ügyes megoldás. (IPv6 címet ugye nem tudsz statikusan fehér-listázni, mert mint fentebb jelezték változnak. Szóval ehhez valamilyen trükkös MAC vagy DNS vagy esetleg "fordított maszkolás" kell.)

Összefoglalva nagyjából rendben van. Számomra egyébként nehezen érhető, hogy a szolgáltatók miért nem szeretnének statikus IPv6-ot nyújtani.

"Számomra egyébként nehezen érhető, hogy a szolgáltatók miért nem szeretnének statikus IPv6-ot nyújtani. "

mint ahogy v4-en se kapsz statikus ip-t.
Gondolom lehet érte jó pénzt kérni, másrészt minek statikus ? Mivel lakossági neten elvileg nem nagyon szolgáltathatnál szerver ilyenek, így nem kell statikus ip sem.

Fedora 24, Thinkpad x220

IPv4-en a belső hálód NAT mögött van, ezért házon belül tudsz statikus (privát) címeket osztani.

IPv6 esetén normális esetben nem használsz NAT-ot, így a prefix változásakor az egész belső hálód átszámozódik, és mondjuk a WAN kapcsolat leszakadásakor lerohad a belső gépeid közötti kommunikáció is, ha nem Unique Local vagy Link Local felett megy. (SLAAC mellett ki tudsz szórni Uniqe Local és Global prefixet a belső gépeknek egyaránt, viszont DHCPv6 esetén a kliensek "by default" csak egyféle címet tudnak kérni maguknak, kivéve ha hegesztesz a kliensen - és, ha a kliens egyáltalán lehetővé teszi.)

Az IPv6 szabvány is változott menet közben, a "nagyon nagy valószínűséggel egyedi" unique local / site local címek koncepcióját elvetették. Maradtak a link local címek, amik viszont ugye nem igazán routeolhatóak. Ez azt jelenti hogy ha dinamikus /56-ot kapsz, akkor két /64-es subneteid között az átjárást egészen konkrétan nem tudod megoldani hacsak nem konfigurálod azt is újra minden címváltáskor.

De a legnagyobb probléma az, hogy mivel az IPv6-nál a router nem fedi el a címváltozást, ezért egy belső eszköz számára egészen addig elérhetetlen az egész internet, amíg rá nem talál az új címére. Hogy ez ne okozzon gondot, az IPv6 címeknek testing-preferred-deprecated-invalid életciklusa kellene legyen, amit persze a szolgáltatók nem tartanak be. Következmény a usability fail: a legtöbb eszközt egy címváltás után rá kell erőszakolni az új címére, pl. a WiFi ki-be kapcsolásával.

IPv4 esetén ugye ilyen gond nincs, mert a NAT ápol és eltakar. Egy címváltás a nyitott kapcsolatok szétesését okozza ugyan, viszont az esetek 99%-ában a szoftverek ezt maguktól a háttérben egy újracsatlakozással lekezelik, és a felhasználó meg sem érzi a döccenést.

> Következmény a usability fail: a legtöbb eszközt egy címváltás után rá kell erőszakolni az új címére, pl. a WiFi
> ki-be kapcsolásával.

Na, de a kliens miért nem hallja meg a router advertisementet az új prefix-szel? (Én teszt jelleggel váltogattam prefix-eket, és a kliensek jellemzően 1-2 másodperc alatt átálltak. Csak szerencsém volt?)

> Egy címváltás a nyitott kapcsolatok szétesését okozza ugyan, viszont az esetek 99%-ában a
> szoftverek ezt maguktól a háttérben egy újracsatlakozással lekezelik, és a felhasználó meg sem
> érzi a döccenést.

Ezt kérlek magyarázd el a stateful tűzfalaknak is, mert ők nem tudnak róla. Oké, ha a kliens teljes újracsatlakozást (SYN...) csinál, akkor újra átmegy a tűzfalon. De a teljes újracsatlakozásról meg az SSH, SIP és társai nem tudnak.

> Na, de a kliens miért nem hallja meg a router advertisementet az új prefix-szel?
> (Én teszt jelleggel váltogattam prefix-eket, és a kliensek jellemzően 1-2 másodperc alatt átálltak. Csak szerencsém volt?)

Tapasztalatom szerint felveszik az újat, de nem dobják el a régit mert nem járt le. Ennek következményeként egyrészt ha valaki megkapja a régi címtartományodat azt te nem éred el (nyilván ennek kicsi az esélye), másrészt az alkalmazások küzdhetnek tovább a régi címmel, ha akarnak.

> Ezt kérlek magyarázd el a stateful tűzfalaknak is, mert ők nem tudnak róla. Oké, ha a kliens teljes újracsatlakozást (SYN...) csinál, akkor újra átmegy a tűzfalon.

Teljes újracsatlakozás úgyis kell, mert a túloldal más címről lát téged, tehát ott mindenképpen szakad, tűzfal nélkül is. (A tcp kapcsolatot ugye 2 cím + 2 port határozza meg.)

> De a teljes újracsatlakozásról meg az SSH, SIP és társai nem tudnak.

Igen, ők az 1%. A 99% meg HTTP, és különböző http jellegű zárt protokolok.

Mivel lakossági neten elvileg nem nagyon szolgáltathatnál szerver ilyenek, így nem kell statikus ip sem.

Mert valamiért az terjedt el, hogy bár te internet-kapcsolatot veszel, ez lassan kimerül a http-ben...
Hát az nem internet-kapcsolat!
Egyébként nem értem, hogy miért fájna a szolgáltatónak, hogy én az 5/0.5 ADSL-emmel szervert üzemeltetek. Megy is már jópár éve, soha nem szóltak érte.

Már bocsánat, de mit nevezünk jelen esetben szervernek? Mert nekem pl. az az igényem, hogy:

1.) Haza tudjak SSH-zni
2.) Haza tudjak VPN-ezni
3.) Az otthoni "okos" rendszereket (pl. kazánvezérlés) tudjam távolról basztatni (Web szerver!)

Egy élmény volna, ha ezeket nem dinamikus IP felett, dyndns-sel kellene megoldani. (Persze valójában hazatunnelezek egy fix IP címet, mivel "hobbiból" ISP vagyok és van saját IPv4 prefixem, csakhát akkor meg ugye nincs natív/optimális routing.)

Nyilván a legjobb az volna, ha adnának a 4500 Ft-os otthoni csomaghoz BGP peering lehetőséget :)))

> Viszont a /56 előrelépés, rendes saját router esetén ez azt jelenti hogy több belső subnetet is
> meg tudsz címezni IPv6-tal. (Az egyetlen lakossági IPv6-ot nyújti DIGI-nél erre nincs
> lehetőséged.)

FYI: a UPC-nél is van már DS-Lite alapú "lakossági" IPv6, ahol pedig kizárólag SLAAC /64 van. Annál valóban jobb.

Hozzáteszem, hogy a UPC-féle DS-Lite implementáció külön szívás azért, mert a DS-Lite alapjaiban véve egy natív IPv6 fölött kitunnelezett IPv4-et jelent - és ezáltal a technológia lehetővé tenné publikus IPv4 cím kitunnelezését is, de a UPC kizárólag privát IP-t hajlandó rajta szolgáltatni. Magyarul, választhatsz:
- publikus IPv4 (MTU 1500), IPv6 nélkül,
vagy
- privát IPv4 (MTU 1460), IPv6-tal.

> Külön pikáns ízt kölcsönöz ennek a UPC peering-politikája

Na, meg a Telekomé. Nézd meg a Telekom BGP hirdetését a BIX-en. Annyiféle "érdekes" community van rajta, hogy csak na. A Hurricane Electric BIX POP például csak Prágán át érhető el Telekom hálózatból, Budapestről.

Lehet, pont ez a baj. Minden porszem forgalmát már nem bírnák, a NAT meg visszafogja a dolgokat :) Esetleg megnövekedett adminisztrációs terhek és a szakik tömeges képzése. Az eszközcserét ne is említsük, bár azért már illene mindnek támogatnia, kivéve a legolcsóbb otthoni routerek, amiket kiszórtak nagy kegyesen a szolgáltatók "ingyen".

Köszönöm a választ (a többieknek is)!
A leírás szerint különbség van a DOCSIS és az egyéb technológiájú hálózatok között, pl. DOCSIS esetén nem változik az IP cím:
"A kiosztott /56 prefixek általában változatlanok hosszú ideig egy adott végponton, de bármilyen Telekom oldali hálózati átalakítás vagy HGW csere esetén a delegált /56 prefix megváltozhat"

A másik, hogy én eddig azt hittem (ez az IPv6 marketingszöveg) hogy minden eszköznek egyedi, fix IP címe lesz. Ezek szerint ez nem így van, továbbra is szívni kell DynDNS szerű dolgokkal.

--
Soli Deo Gloria

Ezek szerint ez nem így van, továbbra is szívni kell DynDNS szerű dolgokkal.

Ha jól értem, akkor nem feltétlenül kell, hiszen nem arról van szó, hogy akár naponta kétszer is megváltozna, hanem arról, hogy X évente, ha változik a hardver, akkor változhat a cím is.
Egyébként a céges fix IPv4 címünk is ~10 év alatt változott egyszer.

Ez szívás, és nem igazán értem az okát. DIGI-nél is így van, egy csomót kell hekkelni mire az eszközök rájön hogy új címe van. Remélhetőleg az IPv6 terjedésével ezt alapból jobban fogják kezelni az eszközök.

A leírás szerint nem változik sűrűn. Nálam pl. évek óta nem változott az IP. Ha ez így lesz a tartománnyal is, akkor nem lesz ez rossz (egyébként már megy itt DOCSIS-en is):

- A kiosztott /56 prefixek általában változatlanok hosszú ideig egy adott végponton, de bármilyen Telekom oldali hálózati átalakítás vagy HGW csere esetén a delegált /56 prefix megváltozhat

--
http://naszta.hu

Azt nem értem, miért éri meg nekik szórakozni a dinamikus kiosztással??

IPv4 esetén elfogadható indok, hogy kevés a cím, és spórolnak vele, de v6-nál semmi értelme a dinamikus játéknak, megoldható lenne, hogy mindig ugyanaz cím/tartomány kerüljön kiosztásra.

Marhára úgy tűnik, hogy Nat6 lesz az egészből!

Irgalmatlanul idegesítő, hogy a modem napi 6x-8x újracsatlakozik, és minden alkalommal több perc, mire észreveszi magát a v6 hálózat...

( mauzi v | 2016. 10. 25., k – 22:11 )

> Kábelmodem vagy bridge módban használt HGW esetén a modemre kapcsolódó ügyfél eszköznek
> kötelezően DHCPv6-ot kell használnia, ott az SLAAC nem támogatott
> ...
> (ADSL/GPON) Modem esetén a modemre kapcsolódó ügyfél eszköznek DHCPv6-ot kell használnia

Modem (bridge) módban használt GPON HGW-m van. Az IPv4 PPPoE fölött érkezik.

1.) A "tesztidőszak" alatt kellett csinálni egy második PPPoE session-t, amin lehetett DHCPv6 PD kérést csinálni. Ezentúl nem kell majd második session, hanem egy dual-stack PPPoE session fölött érkezik majd az IPv4 és az IPv6?

2.) A "tesztidőszak" alatt statikus /56-ot adtak. Ha ez most tényleg dinamikus lesz (és igényelni sem lehet statikusat) akkor szüljenek farfekvéses tarajos sült a DIGI-vel együtt! (Főként, hogy a DIGI a céges, fix IPv4 címet tartalmazó feláras csomaghoz is dinamikus IPv6 prefixet ad!) REGRESSZIÓ!

Nekem a "tesztidőszakos" második PPPoE session továbbra sem megy (a PAP authentikáció sikeres, de nem jön meg a linkre a prefix IPV6CP-vel) illetőleg az első (IPv4-es) PPPoE sessionra sem sikerül IPV6CP-zni. Ezek szerint nálam még nem aktív a szolgáltatás? (Gondolom, nem a nyers ethernet interfészen kell DHCPv6 PD-t küldeni, hanem ez is PPPoE-be lesz enkapszulálva)

( bennyh | 2016. 10. 26., sze – 09:37 )

Nézegettem, hogy kis céges környezetben hogy lehetne legegyszerűbben elérni az IPv6-ot. Lehet egy ideig a belső hálót IPv4-en kellene hagyni és kifele az IPv6 elérést pl web proxy-n keresztül, az átjáróra telepített SMTP proxy-val és más proxy/repeater alkalmazásokkal megoldani. IPv4-es kliensről squid segítségével tudtam böngészni az IPv6-os oldalakat. Levélküldésnél is a DNS név a fontos. SIP esetén is vannak proxy-k meg egyszerűbb szerveralkalmazások.
Biztos jó dolog az IPv6 a világhálón, de kis helyi hálón nem tudom, van-e sok értelme. De tényleg, ha van, akkor írjátok meg nekem, mert még nem jöttem rá. A NAT léte-nem léte nem izgat annyira, a helyi szolgáltatások szempontjából érdekelne.

Sok előnye van azért ezen kívül is, alapjában véve fejlettebb technológia.

Egy érdekes példa a broadcast storm IPv4-en: A gyakorlatban pár ezer gépnél többet egy v4-es lanra nem igazán lehet kötni, mert a hálózat önmagának generált broadcast forgalma (ARP, DHCP) olyan nagy lesz, hogy jelentős processzor erőforrásokat esz meg, az olcsóbb routerek le is döglenek tőle. Kolégiumokban ez úgy szokták workaroundolni hogy mesterségesen feldarabolják a hálót /24-22 darabokra, de persze ennek routingban fizetik meg az árát. IPv6-nál ilyen probléma nincsen: mivel broadcast helyett solicited-node multicast van, ezért egy IPv6-os hálózat nagyságrendekkel jobban skálázódik.

Persze a nem romlott el ne javítsd meg elvet követve nem fogsz belátható időn belül átállni IPv6-ra :-)

Nincs itt nem hogy ezer, még száz gép se és még a LanSweeper 100-as korlátjába se ütköztünk bele. De azért nem baj, ha egyes szolgáltatások kilátnának az IPv6-os Internetre.
Tényleg amúgy az IPv6-os része a világhálónak az már az Internet 2? Valamikor régen bedobták ezt a nevet, de nem tudom, hogy most mit értenek alatta.

( Gaab | 2016. 10. 27., cs – 13:09 )

A telekom oldalon nincs konkret datum - van, akinel mar el ez a szolgaltatas?

( Zozz | 2016. 11. 20., v – 19:30 )

Sajnos globális IPv6 címem még mindig nincs, de próbálkoztam a belső hálózaton játszani kicsit: minden eszközömnek van link local IPv6 címe (fe80:: kezdetű) és ezen próbálom őket elérni. Pingetni lehet is, de a router weboldala nem érhető el, ha az IPv6 címmel próbálom: "A webhely nem érhető el ERR_INVALID_ARGUMENT" a hibaüzenet. Ez mitől lehet? Chrome böngésző, a címet szögletes zárójelek közé írtam.

--
Soli Deo Gloria

Kis háttérolvasmány, miért nem praktikus a link local irány: https://en.wikipedia.org/wiki/Link-local_address
Helyette adj (akár a routeredből automatikusan) "192.168.x.x"-jellegű belső Unique local címet az fd00::/8-ból.
Bővebben: https://en.wikipedia.org/wiki/Unique_local_address

Azért a link-local cím sem tökéletes. Több hálókártya esetén (WiFi+LAN) már kérdés, hogy melyik kártya legyen a feladó? Mindkettő ugyanabban a tartományban van, ugyanazt a tartományt látja - de csak IP címek tekintetében. Innen kezdve egy link-local IP-t csak maga az IPv6 cím nem azonosít egyértelműen, azt is tudni kell, hogy melyik local linken lehet elérni!

Azért ennyire nem rossz a helyzet: valamelyiken! Mivel a link-local címek is általában MAC-ből vannak számolva, nem valószínűbb hogy lesz ütközés mint hogy L2 ütközés lenne. Persze vannak kivételek, de 99%-ban egyértelmű egy cím. Simán jó lenne ha hálókártya infó hiányában azon a linken érnénk el a címet amelyiken először találunk megfelelőt.

A fenti wikipedia cikk szerint a megoldás ki van találva: az interfész azonosítóját a cím mögé kell írni % jellel elválasztva (fe80::3%eth0). Persze hzsolt94 fenti ötlete is működhetne, az esetek 99%-ban ha van is két hálózati interfész, csak az egyik működik, így lehetne tudni merre kell küldeni.
Sajnos úgy látom a Chrome-ban ezt nem akarják támogatni, pedig ahogy az utolsó hozzászóló írja, sokszor szükség lenne rá (persze amíg van IP4 is, addig nem égető...)

--
Soli Deo Gloria

Egyébként akkor is jól jön az Unique local, ha a szolgáltató dinamikus IPv6-ot ad.
Miért? Mert a fránya LAN-os eszközeidnek mindig változik a publikus IPv6 címe. Jó ha van belül valami állandó, könnyebb belső DNS-t csinálnod, stb.

Ezért az eszközök nálam IPv6-on:
- Digi-s publikus IP-t megkapják - minden napra másikat.
- Unique localt - ez van a belső DNS szerverben feloldva.
- Link local meg adott a hálózati háttérszolgáltatáshoz, másra mint fentebb írtam nem praktikus erőltetni.

$ ping6 raspberrypi3
PING raspberrypi3(raspberrypi3.lan (fdee:f362:64f7::839)) 56 data bytes
64 bytes from raspberrypi3.lan (fdee:f362:64f7::839): icmp_seq=1 ttl=64 time=1.44 ms

( uid_395 v | 2016. 11. 21., h – 17:54 )

btw, tegnap belőttem OpenWRT-re, mondom teszek egy próbát, hátha bekapcsolták már itt is.

És igen!

Bár alapvetően egy DIGI* howto-t követtem a beállításhoz, de az mellékes.

https://logout.hu/bejegyzes/slug/digi_ipv6_over_pppoe_openwrt.html

konkrétan ezt itt ^^

https://1drv.ms/f/s!AmKObYSrI5vilwNieqcWeULvrN7m

kicsit kimaszatolva, de műxik (fentebb pár kép). Gyakorlatban az összes eszköz kapott rendes "kintről" látható v6 címet, hogy "hülyén" fogalmazzam meg.

by-default openwrt firewall tilt minden féle cuccost befele.

Ami próbáltam, ipv6 szerver pingek, ipv6 oldalak, chrome-hoz leszedtem egy kis extensiont, ami mutatja hogy az adott oldalon épp mi jön v6-on és mi jön v4-en.

klienseken gyakorlatilag semmit nem kellett állítani. A DHCP-t sem csesztettem, kapok egy local v6 címet ha jól láttam, amit kioszt a wrt dhcpje + megkapja a kliens a t-online által kioszott "külső" v6 címet is.

Kis teszteket végezve. OpenWRT "net felöli lába" válaszol pingre (így van belőve).
Kipróbáltam a saját gépemen egy apache-ot 80-as porttal + a saját v6 külső címével. OpenWRTben itt csak annyit kellett engedélyeznem a tűzfalba, hogy bejövő v6 (azaz wan6) esetén a 80-as portot engedje be bárhova. Teszt jelleg volt.

Külső v6-os szerverről meghívtam a gépem v6 címét 80-as portra és tádám, fogadott egy apache.
Tök független webes ipv6 portscanről direktbe scanneltettem a 80-as portot a kliens v6 IPre, ment.

Csak egy kis összegzés hogy elkezdett működni. :)

ps.: jah, Kecskemét helyileg.
ps2.: btw kissé összekavarodtam, mert ma már tökmás a vége a saját gép v6jának (a net felöli WRT-n maradt). Tény, ennek még utána kell olvasnom rendesen :)

üdv
-krix-

"btw, tegnap belőttem OpenWRT-re, mondom teszek egy próbát, hátha bekapcsolták már itt is.

És igen!"

Ejjjh, de várom már a szülők telefonhívását otthonról... Náluk Sagemcom doboz van, a beépített szolgáltatások felét ki kellett lőni (de még a DHCP is idetartozik ám), mert használhatatlanok voltak, a másik felét nem használom, szóval a mögé rakott rendes router, na meg az NMHH mérőbox, meg a wifis multinyomtató.
"Remélem" tényleg tolt egy új firmwaret a T, gyári beállításokkal, és minden romokban odahaza... :) :/

Szerintem az hogy magán a T* vagy bármi más modemen bekapcsolják az ipv6ot, semmit nem fog eredményezni a "szülők" routerén :)

Mivel ahhoz hogy az ipv6ot használjon, kell egy kicsit heggeszteni azért :)

Bár ha nincs saját router és a ISP* routere oszt mindent, nos, akkor valóban lehet gond :)

Amikor a T bekapcsolta az IPv6-ot nálunk, akkor semmit nem kellett hegeszteni, a router mögötti gépek automatikusan kaptak IPv6 címet és tudtak kifelé IPv6-on kommunikálni. A befelé irányhoz, hogy kintről elérhessék a router mögötti gépet, kellhet esetleg hegeszteni.

hadd kérdezzem meg, hogy kinek milyen Telekom által adott GPon gateway-e van?
nekem HG8245 - anno a 120mbps nethez ilyet adtak, és állítólag viszi a gigás netet is.

Viszont ez csak router módban tud működni, bridge-ben nem...
Illetve láttam valami olyan trükköt,h Firebug-ban átheggeszteni html form-ot,de ehhez nem voltam elég bátor :-)

vagy másnak másik CPE van?

( uid_395 v | 2016. 11. 25., p – 17:18 )

Csak egy keresztkérdés a nagynéphez.

Android telefonoknál tapasztaltam ipv6 beállítás után, hogy ipv6 és ipv4 címet is kap a droid (ami nem baj), viszont ipv6 óta nagyon sűrűn "kis felkijáltójeles ikonná" alakul a WIFI jel. Ami gyakorlatban annyit takar, hogy azt érzékeli, hogy nincs internet kapcsolat.

Ezek amúgy Android 5.0.X -ek. kettő Sony teló + egy LG.

Ami érdekes, hogy az én Xiaomi mi4c -m (szintén android, bár ez 5.1) nem csinál ilyet.

A laptopok sem csinálnak ilyet + a fix gépek sem.

Ötlet esetleg? Arra tippelek, hogy valahogy valahol a 3 telefon "eltéved v6 és v4 között" valahogy és úgy érzékeli mintha nem lenne net.

Amint átállok routerileg csak ipv4 -re, akkor megszűnik minden gond.

Előre is kösz :)

Üdv
-krix-

OpenWRT van 15.05.1 verzió van. Mint fentebbi hozzászólásokban látszik, hogy hogyan kapja meg a v6ot.

router dhcpv6 osztotta ki a címeket mindenkinek. normál gépen kaptam egy ideiglenes címet, ami a belső cím + egy rendes telekom által publikált címet is.

+ ezt megkapták a droidok is.

5.0 - 5.1 között csak nincs annyi különbség hogy ilyen gondok előjöjjenek.

Bár passz. Mind1 is, visszaraktam v4re, majd később WIFI fele tiltom az ipv6 dhcpt azt jóvan.

( wpeople v | 2016. 11. 28., h – 21:14 )

rákérdeztem - az IPv6 csak magánelőfizetők részére érhető el, közületek még nem kérhetik.
Van valakinek ezzel ellenkező infója?

( Gaab | 2016. 11. 29., k – 23:27 )

Hogy-hogynem, most latom hogy a tamogatott eszkozok listajarol lekerult a Sagemcom HGW. Ami szomoru, mert az enyemet nemreg erre csereltek le.

Na ez vajon typo vagy ennyi volt? :)

( naszta v | 2016. 12. 01., cs – 09:48 )

Egy dolgot nem értek: az iPhone-omnak miért van 3 IPv6 címe? 2 rendben lévőnek tűnik: 1 link local és egy globális. De minek a 3-ik (ránézésre az is globális)?
--
http://naszta.hu

( medve540 | 2016. 12. 04., v – 14:50 )

Úgy néz ki a T-Home bekapcsolta nálam is a dual-stack módot. Ha a Cisco EPC3925 kábel modem WIFI-jére csatlakozok tudok is kapcsolódni IPv6 hálózatokhoz.

Viszont van egy TP-Link router-em OpenWrt 15.05.1-el, amit próbáltam beállítani, hogy rajta keresztül is menjen, de nem sikerült. Állítólag csak akkor működne, ha a kábel modem bridge módba lenne állítva. Most router módban van és a T nem engedi átállítani. Az ügyfélszolgálat azt mondja, hogy letiltották, mivel bridge módban nem működne az IPTV.

Sikerült már valakinek ilyet beállítani?

De az átkacsoláshoz nem kell kiszállnia senkinek, azt központból át lehet kacsolni.

Anno nekem egy szerelő elmesélte, hogy ő, a központból mindet lát a kapott modemen, az összes rákötött számítógépet, nyomtatót, iptv-boxot, a wifire csatlakozó, és egyéb eszközt, a mac-címek szintjén.

Pont azért, mert ha az átlagfelhasználó, (a nem tipikusan hup olvasó...) betelefonál, hogy "nem megy a wifi, vagy ez nem látja azt, nem megy a nyomtató, stb." problémákkal, akkor ők ezt, az ügyfélhez való kiszállás nélkül is meg tudják oldani.

Mondjuk ebben semmi meglepö sincs. Most is szól a fejem mellett több rádióadás, csak egy antenna kell ahhoz kb. hogy halljam.
Ahol meg átfolyik az adat, ott figyelhetö, lopható, menthetö, eladható, és a többi.
Akik hisznek a biztonságos hálózatokban, azok naívak.

De ha pl. mondjuk letiltod a Telnet-et, SSH-t a szolgáltató cuccában, akkor... jó pénzért kiszállnak, hogy visszaállítsák ;)

--
robyboy

„De ha pl. mondjuk letiltod a Telnet-et, SSH-t a szolgáltató cuccában, akkor... jó pénzért kiszállnak, hogy visszaállítsák ;)”

Nálam a szolgáltató cuccában semmilyen WAN oldali beállítás nem lehetséges. Tehát nem tudok olyat beállítani, hogy ők távolról ne tudják menedzselni a gateway-t. Van olyan szolgáltató (Magyarországon) aki megengedi a WAN oldal konfigurálását az általa adott, és kötelezően használandó eszközön?

igen, Telekom.
a Telekom által adott ONT-n sokkal több dolog konfigurálható, mint a Digi által biztosított eszközön.
A telekomnak ellenben olyan provision rendszere van ehhez, hogy a kolléga amikor telepít, az ONT-t a mobiljáról programozza provision-ön keresztül, nem LAN ról...
felteszem, ha valamit elba**ol rajta, távolról felküldik újra az alap provision konfigot és kész...

Ez a telnet/ssh letiltás nettó hülyeség!
Ők a központól nem telneten, vagy ssh-n mennek be, hanem erre külön port van nyitva, amit az user nem tud letiltani.
Amikor távolról állítják, akkor nem egy terminálból teszik, hanem egy GUI-s programmal, illetve webes felületen.
Pl: egyszer nézz rá portcsannal, egy iptv boxra, van egy nyitott TCP port (10000, vagy 8000 környékén), ami erre való.
A DOCSYS-os és a GPON-os szabványok támogatják a HGW-re való távoli firmware feltöltést, nem csak a konfig feltöltését.

A Telekom oldalán ezt írják: "A HGW 1db /56 IPv6 prefixet is kap, melyből az első /64 prefix a LAN oldalon kerül felhasználásra. A /56 prefix többi részét az ügyfeleink által telepített plusz routerek használhatják (kérhetik DHCP-vel) prefix delegálás keretében további interfészeik IP címmel ellátására"
Ezek szerint a routerednek DHCP-vel kellene ebből a tartományból címet kérni.
Vagy van egy IP Pass-through opció is az Applications & Gaming menüben, ez nem használható?

--
Soli Deo Gloria

Köszi az infót. Most már értem minek kéne történnie. Látszólag az OpenWrt jól teszi a dolgát, mert a router /64-es címet kapott (2001:4c4c:14dc:8c00::), amíg a router-re kapcsolódó eszközöknek /54-eset osztott ki (2001:4c4c:14dc:8c80::). Viszont nem jön válasz a kábel modem felől, olyan mintha blokkolná a 8c80-as címeket. IPv6 tűzfal ki van kapcsolva a kábelmodemben.

Nálam egy Cisco EPC3925 eszközt szereltek be, ennél nincs IP Pass-through opció. Mióta dual stack módba kapcsolták, annyit vettem észre, hogy megjelent egy Lan IPv6 setup menü. Más állítási lehetőség nincs.

( uid_6201 v | 2016. 12. 26., h – 14:09 )

Na puding próbája: Zalaegerszeg, T-Com hálózata, lakossági előfizetés, ADSL.

Device Type: Speedport Entry 2i
Hardware Version: V1.0.1
Software Version: V1.0.0_HU_T2P3

IPv6 Connection Status: Connecting
IPv6 Online Duration: 0 h 0 min 0 s

A DHCPv6 be van pipálva a T által kihelyezett eszközön. Egyelőre NINCS ipv6 rajta, csak a 84.1.x.x -ből IPv4.
... bár a hirdetésükben említett 2016 végéig végülis még van 5 napjuk.

( krooarbo | 2017. 01. 15., v – 17:34 )

Sziasztok,

Előre leszögezem, hogy nem értek az IPv6-hoz, de lenne pár kérdésem.
A Telekom nálunk is bevezette az IPv6 dual stack megoldását. Cisco EPC3925 HGW-nk van, s hiába kapcsolom ki a LAN IPv6 menüben, az Android-os mobil eszközeim ugyanúgy kapnak IPv6-os címet is. Ami elsősorban azért gáz, mert a Telekom IPv6-os DND szervereivel borzasztó lassú a névfeloldás. Hogyan lehet átírni a DNS szervert nem routeolt eszköz esetében, vagy csak szimplán kikapcsolni az IPv6-ot? Routeolni nem tudom, ugyanis céges eszköz.
Egyébként, hogy működik dual stack esetében a priorizálás? Mi dönti el, hogy IPv6-os vagy IPv4-es címzést használ?

> Routeolni nem tudom, ugyanis céges eszköz.

Akartad mondani, rootolni, mert vagy ötször elolvastam, mire leesett, hogy mit kérdezel.

> Egyébként, hogy működik dual stack esetében a priorizálás? Mi dönti el, hogy IPv6-os vagy IPv4-es címzést használ?

Ha van (rendes) IPv6 címed, akkor az a preferált az IPv4 fölött.

Az IPv6-ot az alkalmazásnak támogatnia kell, rajta múlik hogy hogyan használ IPv6-ot. A megszokott eljárás az, hogy ha egy domain névhez tartozik AAAA rekord, akkor arra IPv6-tal megpróbálunk csatlakozni, és időtúllépés esetén visszaváltunk IPv4-re (ha van).

Biztos hogy az IPv6-os névfeloldással van gondod? Azzal nem szokott probléma lenni. Nem lehet hogy az IPv6-os kapcsolatoddal van probléma, és ezért várnod kell amíg az alkalmazás feladja az IPv6-ot, és IPv4-en próbálkozik helyette?

Próbáld inkább kideríteni hogy mi a baj a v6-tal, ne kikapcsolással kezd. Másold be a http://test-ipv6.hu http://test-ipv6.com tesztek eredményeit, valószínűleg segíteni fog.

Az Androidos eszközök egyébként nem támogatják a DHCPv6-ot*, úgyhogy RA-ból veszik a címet SLAAC-vel. Ezt az Androidos eszközön a WiFi hálózat beállításai között letilthatod ha muszáj.

A fenti tesztoldalak szerint minden rendben, viszont azt vettem észre, hogy a DNS szerverek (2001:4c48:1::1 és 2001:4c48:2::1) pl. laptopról pingenek, meg feloldás is működik , viszont egyik Androidos cuccról sem megy a ping sem. Szóval gondolom az a helyzet, amit írtál, hogy timeout-ol IPv6-on és utána próbálkozik IPv4-gyel. Csak nem tudom mit lehetne tenni, meg hogy hol a hiba.

IPv4-es névszervereket nem oszt a router? DHCPv6 hiányában az androidok csak RFC6106-al tudnak IPv6-os névszerver beállítást átvenni. (RA DNS extensions) Igazából normális DHCPv6 hiányában fixen IPv4-en szokott menni a DNS lekérdezés, még akkor is ha működő IPv6 van a hálózatban.

Olyan eszközről nyisd meg a tesztoldalt, amin a hibát tapasztalod, működnek mobilról is. (Másold be légyszi a kimenetet, ha minden rendbent ír akkor is van benne diagnosztikai infó bőven.)

getprop net.dsn1 2001:4c48:2::1
getprop net.dsn2 2001:4c48:1::1
getprop net.dns3 8.8.8.8

A tesztoldal (Android 6.0.1) :

Tesztelés IPv4 DNS rekorddal
rendben (0.214s) kapcsolat: ipv4
Tesztelés IPv6 DNS rekorddal
rendben (0.232s) kapcsolat: ipv6
Tesztelés Dual Stack DNS rekorddal
rendben (0.230s) kapcsolat: ipv6
Dual Stack DNS és nagy csomag tesztelése
rendben (0.229s) kapcsolat: ipv6
IPv4 teszt DNS nélkül
rendben (0.223s) kapcsolat: ipv4
IPv6 teszt DNS nélkül
rendben (0.229s) kapcsolat: ipv6
Nagy IPv6 csomag tesztelése
rendben (0.248s) kapcsolat: ipv6
Az internetszolgáltató IPv6 DNS tesztje
rendben (0.226s) kapcsolat: ipv6
Find IPv4 Service Provider
rendben (0.156s) kapcsolat: ipv4 ASN 5483
Find IPv6 Service Provider
rendben (0.181s) kapcsolat: ipv6 ASN 5483

Viszont az http://ipv6-test.com/ oldalon a droidok az alábbiakra unreachable-t mondanak:

DNS6 + IP4 Unreachable
DNS6 + IP6 Unreachable

Ubuntu-n Reachable. Ezen az oldalon nincs details szóval egyebet nem mond.

Úgy tűnik hogy a routered beállít IPv6-on elérhető DNS szervereket, de utána ezek mégsem működnek. Így az operációs rendszered minden egyes DNS lekérdezésnél megvárja amíg a v6 sikertelen.

Próbáld a routereden a névszervereket átállítani, és kivenni közülük az IPv6 címmel rendelkezőket.

Úgy tűnik, másnál is van ilyen: http://www.hwsw.hu/hirek/56684/telekom-ipv6-ip-android-wifi.html
Én nem tapasztalok problémát, itt is Cisco HGW van és két Androidos telefon (5.1.1 és 7.1.1 verziók)

"Frissítve: “Adatközponti konfigurációs hiba” okozta a hibát a Telekom hozzánk eljuttatott álláspontja szerint. “Ezt a hibát a mai nap során a Magyar Telekom szakemberei elhárították” - mondja a vállalat, a hálózat a cég szerint az eszközök újraindítása nélkül újra rendeltetésszerűen működik. A cég elismerte, hogy a problémát az IPv6-os DNS-feloldás okozta, azt nem tudni, hogy pontosan mekkora felhasználói bázist érintett."

--
Soli Deo Gloria

( naszta v | 2017. 05. 17., sze – 20:57 )

Jelenleg a Cisco EPC3925-ön teljesen ki van kapcsolva az IPv6, viszont a mobil hálózaton már kap az iPhone-om is címet. (Mondjuk azt, hogy miért nem carrier NAT van, azt nem értem, 10.xxx.xxx.xxx a címem.)

Van akinek működik kábelen az IPv6?
--
http://naszta.hu

Hello,
A 10/8, az a HGW belső oldalán van, azaz a HGW NAT-ol neked...;
Ennek by the way az az oka, hogy a DOCSIS forgalom elég combos, a CGNAT meg elég drága..., szval nem nagyon éri meg az ED3-at NAT-olgatni;
Van kis gond ezeknek a Modemeknél a ipv6 támogatással, ezért javításig ki van kapcsolva, ha javítódik, akkor lesz megint ipv6.

Szia,

igen, furcsáltam is a 10/8-at a DOCSIS mögött :)
A Mobile-ban van CGN, azaz megkapod a Cellular interface-re a 10/8-at, majd ott az internet és a VRF között ott van a CGN, mert máshogyan nem nagyon működhetne a világ felé...

De miért zavar, ha 10.x.y.z/32-t kapsz a PDP session-ödre?
Valami spéci "split-tunnel" VPN van a cégben, ami ennek ellenére, hogy /32-t kap a mobile-od, beállít valami nagyobb prefixet "helyinek"?

Most akkor képzeld el, hogy a DNS server az 10.1.1.1 a céges hálózaton. A telefon keresi: melyik interface-hez menjen? Mindkettőn lehet ez az IP. Vagy más az átjáró címe a céges és mobil szolgáltató által adott neten. Hova menjen a telefon alapesetben? Stb. Pontosan ezért van a carrier grade NAT, saját lefoglalt IP blokkal (100.64.0.0/10). Egyébként néha a T is ezt ad. Pl. most ilyen címem van: 100.113.109.23.
--
http://naszta.hu

Hello,
Hát az IP routing egész jó megoldást erre a problémára...:)
Van egy PDP interface-ed, ott van egy /32-...lehet az bármilyen cím...10/8 vagy 100/10, mind1..., a lényeg, hogy a routing hogy áll.
Ha pl oda mutat - Celluar felé- egy default route...mondjuk a VPN tunneled irányába meg egy specifikus RFC1918, akkor
ez elvileg nem okozhat gondot...
a routing táblát nézted már, amikor ilyen gondod van ?

Nem akarok találgatni, mert ezer dolog lehet, de indulj a routing tábla irányából a problémának...
A 10/8 még marad egy darabig a CGN előtt...sorry :( mindamellett a 100/10 is használva van, GW függő...hogy milyen pool-ból kapcsz címet...;