Digi IPv6 elindult

IPv6

Sziasztok!

Friss hír, hogy a Digi elindította az IPv6 szolgáltatását: https://digi.hu/hirek/ipv6-mar-ugyfeleink-reszere
Sajnos kipróbálni nem tudom, mert reggel a lépcsőházi eszközük lehalt és nincs internetem.

Ügyintéző elmondta, hogy minden IPv6 képes routerrel menni fog.

Próbálta már valaki?

Üdv!

Update1: http://digi.hu/ipv6

( zeller | 2015. 12. 03., cs – 11:32 )

Nesze nekem... Megint meló lesz vele... :-P

Hát én most próbálgattam kicsit rugdosni az openwrt-s vasat, Wan6 pppoe kapcsolatot nem tud nyitni, túl sok kapcsolat hibával eldobja.
Ha a Wan porton kapcsolom be az ipv6 stacket, akkor semmi eredmény.
6to4 automatice építi nálam a tunnelt, de az nem a digié.
mással eddig nem sikerült semmit felhúzni.
Ha valakinek van ötlete owrt setupban, az megoszthatja azt.

Megnéztem a Mikrotikemen.

PPPoE kapcsolat default profillal (ebben szerepel az, hogy ipv6-ot engedélyezze).
Úgy a WAN mint a PPPoE interfészen csak link local cím szerepel (mac-ból származtatott), ha jól emlékszem a Cisco-s tanfolyamra (fe80...).

Van még egy extra DHCPv6 kliens processz a PPPoE interfészen, ez nyomja át egy ipv6-pool nevű cuccba a kapott prefix-et.

RIPE szerint jó nagy blokkjuk van: route6: 2a02:2f00::/28

( ncc1701 | 2015. 12. 03., cs – 12:11 )

Na, erre kíváncsi leszek. Egyelőre tiltottam a full ipv6 forgalmat tűzfalon.

Engedélyeztem, kíváncsiságból:
ping6 -I em1 ipv6.google.com
connect: Network is unreachable

( petyasoft27 | 2015. 12. 03., cs – 14:53 )

Wow, köszi az infót, tényleg megy (Zalaegerszeg amúgy, és Mikrotik router).
Lehet nekiállni v6-on tűzfalazni..
Lesznek még itt meglepetések tűzfal szempontból, pár helyen szerintem.. én pl a Digitől nem értesűltem erről a dologról, az oldalukat meg kb. nem nézem soha..

Amúgy egy TP-Link vagy társai SOHO routeren, ez automatikusan megtörténik? Kap v6-on címet amint a DIGI bekapcsolta?

ping hup.hu

Pinging hup.hu [2001:4c48:2:a33e::6] with 32 bytes of data:
Reply from 2001:4c48:2:a33e::6: time=7ms
Reply from 2001:4c48:2:a33e::6: time=7ms
Reply from 2001:4c48:2:a33e::6: time=8ms
Reply from 2001:4c48:2:a33e::6: time=8ms

Ping statistics for 2001:4c48:2:a33e::6:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 8ms, Average = 7ms

( Pene | 2015. 12. 03., cs – 17:29 )

na, érdemes volt őket pingelni januárban ezügyben :)

En ha jok az emlekeim az IPv4 countdown ideje irtam egyet nekik erdeklodes kepp. Akkor sablon szoveg volt a valasz. Nagyjabol fel eve ismet felkeltette erdeklodesem es erdeklodtem, akkor is irtam hasonlo eredmennyel. Ettol fuggetlen minden tiszteletem az Ovek (roman-magyar huszarkodast tegyuk felre mert nem mervado) a nativ IPv6 es igenyles nelkuli bevezetes miatt. Mindenhonnet csak a majd, meg minek, felesleges, nincs erdeklodes hozzaallas latszik. Jo, hogy van(nak) ilyen beallitottsagu ceg(ek). Hatha ezzel rakenyszeritik a tobbit, amik mar most futnak utana sebesseg ugyileg.

( kbalint v | 2015. 12. 03., cs – 18:28 )

eddig tunnelem volt, kiszedtem, de se kép se hang :( ha külön ipv6 kapcsolatot csinálok, a pppoe fel se connecttel, automatic módban sem megy sehogy.. az gond lehet, hogy 10.0.0.x a digi default gateway az iptelefon miatt itt a házban?

( mikabak | 2015. 12. 03., cs – 18:35 )

Tudja valaki, hogy a "Prefix Length"-et mire kell állítani?
Köszi!

( elod v | 2015. 12. 03., cs – 19:11 )

Érdekességképpen épp megfogta a firewall: 2a03:2880:f01c:1e:face:b00c:0:25de

( Rill | 2015. 12. 03., cs – 20:24 )

En rontok el valamit vagy a 14 kerbe (meg) nem megy. OpenWRT-s router.

( uid_6201 v | 2015. 12. 04., p – 16:17 )

Siker. Budapest III. kerület GPON

Ami kellett hozzá az eddigi IPv4-es 'wan' sorok után:

root@OpenWrt:~# tail -n 4 /etc/config/network 

config interface 'wan6'
	option ifname '@wan'
	option proto 'dhcpv6'

ifconfig kimenete: 

pppoe-wan Link encap:Point-to-Point Protocol  
          inet addr:100.65.12.75  P-t-P:10.0.0.1  Mask:255.255.255.255
          inet6 addr: 2a01:36c:103:2065:d98a:725d:2cb2:3f1/64 Scope:Global
          inet6 addr: fe80::d98a:725d:2cb2:3f1/10 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1

( mikabak | 2015. 12. 04., p – 18:23 )

Sikerült valakinek Tomato firmware-el?

Basic->IPv6 alatt
IPv6 Service Type = "DHCPv6 with Prefix Delegation"
Prefix Length = 64
Static DNS = üres
Accept RA from (x)WAN (_)LAN

Csatlakozik, kapok IPv6-os címet. De a számítógépek a tomato mögött nem kapnak v6-os címeket. Tomato log-ja tele van ilyenekkel:
Dec 4 13:18:58 tomato daemon.warn dnsmasq-dhcp[583]: no address range available for DHCPv6 request via br0

A teszt oldal (http://test-ipv6.hu/) azt mondja nincs IPv6-om.

A routerről tudok IPv6 címeket pingelni (pl. ipv6.google.com).

Mit rontok el?
Köszi

Én is pont egy ilyen eszközzel próbálkozom. Annyi a különbség, hogy a CPU freq-et átállítottam 250MHz-re:

# nvram set clkfreq=250
# nvram commit
# reboot

Tomato shibby legfrissebb firmware-el. Pontosabban ezzel:
http://tomato.groov.pl/download/K26/build5x-132-EN/tomato-K26-1.28.RT-M…

A csatlakozás megy. A routerről tudok ipv6-ot pingelni. De a belső hálózaton nem üzemel. Szerintem valami dnsmasq mágia hiányzik. Ha rájövök a trükkre akkor itt posztolom.

Update: Már szépen üzemel ezzel a firmwarrel kb. 2 hete az IPv6. A beállításokat nem kellet piszkálni. A PPPoE link kap 2a01:36c: címet a belső gépek pedig 2a01:36d: címeket. Az IPv6 tesztoldal azt mondja 10/10. Tehát a régi WRT54GL-el is lehet szépen IPv6-ozni.

( mauzi v | 2015. 12. 04., p – 21:46 )

Akinek már megy a prefix delegáció, kérem, mondja meg hogy:

1.) dinamikusan változik-e a prefix minden PPPoE kapcsolódásnál, vagy egy PPPoE accounthoz mindig ugyanazt adják?

2.) mekkora prefixet delegálnak? Tényleg csak /64-et?

Tényleg nem hallottál még subnetekről és SLAAC-ről?

Segítek. Az SLAAC működéséhez minden subnetben legalább /64 szükséges. Ha nincs SLAAC, akkor sem illik a subnetet /64 alá törni. Persze technikailag lehet.

Ha viszont egyetlen /64 prefixet ad a szolgáltató, akkor - feltételezvén a 64 bites hoszt címeket - nem lehet vele 1-nél több subnetet csinálni.

Az ajánlás szerint minden háztartásnak legalább /56-ot illik adni (max. 256 subnet), de mivel a /48 valószínűleg minden végfelhasználónak elég (közepes és nagyobb cégeknek is elég 65536 subnet) ezért célszerű lehet egységesen mindenkinek /48-at adni, mert prefix bőven rendelkezésre áll.

Nálam Marshmallow 6.0.1 van fenn Redmi 1S-en, igaz nem hivatalos hanem Cyanogenmod. A telefonról/állapot menüben látszik hogy a v4 mellett kapott v6 címet is. Szóval nem igaz hogy az android ne tudná! Akinek Redmi 1S van és meg akar róla győződni, itt a CM13 rom: http://forum.xda-developers.com/redmi-1s/orig-development/cyanogenmod-1…
Telepítés előtt, ha még nem volt fenn a gyári stabil miui7 rom, akkor fel kell rakni a miui Firmware 7.0.5.0-t(KitKat bootloader/modem files), a második postban linkelte a rom készítője.

OpenWRT esetén a /etc/config/network fájlban
config interface 'lan'
résznél hozzá kellett adnom:

option ip6assign '64'
option ip6hint '2a01:36c::/32'

És amin sokat szívtam: ip6tables és első körben ki kellett ütnöm a tűzfalat. A default tűzfal sorokkal még nem néztem meg, mi a probléma.

Megy, kapott a laptopom 2a01:36d:.... IP címet.

$ ping6 -n time.kfki.hu
PING time.kfki.hu(2001:738:5001::1) 56 data bytes
64 bytes from 2001:738:5001::1: icmp_seq=1 ttl=54 time=6.62 ms
64 bytes from 2001:738:5001::1: icmp_seq=2 ttl=54 time=3.99 ms
64 bytes from 2001:738:5001::1: icmp_seq=3 ttl=54 time=3.80 ms

A routerből pingelve itt még eggyel nagyobb a TTL, tehát ez is stimmel:

root@OpenWrt:~# ping6 -n time.kfki.hu
PING time.kfki.hu (2001:738:5001::1): 56 data bytes
64 bytes from 2001:738:5001::1: seq=0 ttl=55 time=2.753 ms
64 bytes from 2001:738:5001::1: seq=1 ttl=55 time=2.763 ms
64 bytes from 2001:738:5001::1: seq=2 ttl=55 time=2.787 ms

Csinálj egy disconnect - connect párost, és máris meglátod, hogy ugyanazt a prefixet kapod-e vissza...

Másrészt, ezt írod:

> option ip6hint '2a01:36c::/32'

Ez szerintem nem jó. A doksi szerint az ip6hint a subprefix ID-t adja meg, tehát ha neked az upstream delegál mondjuk /56-ot vagy /48-at, akkor azt adod meg vele, hogy ebből a nagyobb prefixből melyik /64 subprefixet delegálja a klienseidnek.

Az sem tiszta meg, hogy a 'Global Network Options'-ban meg szokas adni az 'IPv6 ULA-Prefix'-et (/48). Ekkor a 'lan' interface ebbol vesz fel egy kisebb subnetet (/64). Viszont - ha jol tudom - ipv6 eseten nem kellene natolni, hanem a szolgaltatotol kapott tartomanybol kellene IP-t osztani a klienseknek. Ezesetben mit irjak az 'IPv6 ULA-Prefix'-be?

> A bajom az, hogy ebbol megy ki egy subnet dhcp-n a klienseknek, nem pedig a globalis tartomanybol.

Az előzményekből nem derül ki számomra, hogy LAN oldalon SLAAC-t vagy DHCPv6-ot használsz. SLAAC-vel minden további nélkül kellene tudnod több prefixet kiszórni egyszerre. A DHCPv6 esete már nem olyan egyszerű, mert magam is találkoztam már olyan DHCPv6 klienssel, ami out-of-box nem tudott egynél több címdelegációt fogadni.

Ha a DHCPv6 klienst nem tudod megszelidíteni, jobb híján szórd az ULA-t SLAAC-vel. (Ettől a Global-t oszthatod még DHCPv6-tal.) Persze, kompromisszum. Vagy, ne használj ULA-t... a világ sajnos nem tökéletes.

Nekem most ATW-től van ipv6 tunnelem, egyelőre a t-com nem üzemel. Jelenlegi konfig:
/etc/config/network -ben

config interface 'wan6'
option proto 'static'
option ifname 'atw6'

Ugye az atw6 maga az 6in4 tunnel az atw-felé.

Az atw6-interface megkapom /64 első IP-jét /128 ként, Így a /64 SLAAC val tolom a lan-ra következőképpen:
/etc/config/radvd

config interface
option interface 'lan'
option AdvSendAdvert '1'
list client ''
option ignore '0'
option IgnoreIfMissing '1'
option AdvSourceLLAddress '1'
option AdvDefaultPreference 'medium'

config route
option interface 'lan'
option AdvRoutePreference 'medium'
option ignore '0'
list prefix '2a01:270:dd02:2700::/64'

config rdnss
option interface 'lan'
list addr ''
option ignore '1'

config dnssl
option interface 'lan'
list suffix ''
option ignore '1'

config prefix
option ignore '0'
option interface 'lan'
option AdvOnLink '1'
option AdvAutonomous '1'
list prefix '2a01:270:dd02:2710::/64'
option AdvRouterAddr '1'

Az ujabb openwrt-ekben már nem ajnlák a radvd-t, hanem az odhcpd, meg mert az tud dhcpv6, SLAAC-t is. Az előző t-com os konfigom azzal volt, de az most nincsen meg.

Fedora 22, Thinkpad x220

( uid_6201 v | 2015. 12. 05., szo – 10:35 )

Most már biztos, hogy az OpenWRT-15.05 esetén valami nem kerek az IPv6 tűzfallal, a belső hálózat akkor állt mindig össze, amikor átengedőre "átütöttem".

Áthidaló megoldás: gyári helyett saját szabályok a /etc/firewall.user fájlba.
Ebben a fájlban a gyáriak kiütésével kezdeni (-F, -X) és berakni a saját INPUT és FORWARD szabályokat.

Amire még oda kell figyelned, ha saját útra lépsz: dhcpv6-ot is engedned kell, hogy a szolgáltatódtól kapjál IPv6 címet.
ip6tables -A INPUT -p udp -d fe80::/16 --dport 546 -j ACCEPT

A többi hasonló, mintha IPv4-es tűzfalat csinálnál, csak ip6tables-sel.

( atomheart v | 2015. 12. 05., szo – 11:03 )

Ti akik itt atalltok ipv6-ra, milyen elonyt nyujt szamotokra..?

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Első körben a kísérletezés örömét.

Továbbá annak a tapasztalatnak a megszerzését, amely ahhoz kell, hogy a hostingos szervereinket is IPv6-ra beállíthassuk, IPv6-on tátongó lyukait távolról felderíthessük.

Egyébként lesz szívás vele. Első kérdés az itthoni IPv6-hoz: minden csatlakozáskor új IP címet kapok. Hogyan állítandó be a routerben tűzfalszabály arra, hogy egy bizonyos belső eszköz egy bizonyos portja felé engedje csak például az OpenVPN UDP portját át? Hiszen a tűzfalszabályok közé fix DST IP-t nem tudok beütni, mert ez az IP cím mivel szintén publikus dinamikus cím, új címosztással változik.

Hosszabb távon az előny: a jövőben sok újonnan beállított szerver majd csak IPv6-on lesz elérhető, mivel egyszerűen nincs több IPv4 cím. De ez csak néhány év távlatában lesz észrevehető. Egyelőre te nem fogod semmiféle előnyét érezni, inkább csak a szívás oldalát.

Az hogy mindig más IP-t kapsz sokmindentől függhet. Elsőnek milyen módon osztod az IP-t (SLAAC/DHCPv6), ha SLAAC akkor ugye több algoritmus van a cim generalasahoz, többek közt a mac címből, viszont mivel ez nyomon követhető ezért kitalálták, hogy random cimeket is felvehetsz, persze ez kikapcsolható, és akkor kb ugyanaz lesz a címed SLAAC-val.
DHCPv6 nál hasonlóan lehet fixálni ahogy sima DHCP-nél, valamin itt is van akár statikus address is.

Mivel itt nincsen port forwad, így forward láncon kell mindent megoldani. Azaz mondhatod hogy /64-re nem jöhet befele semmi kivéve bizonyos IP-kre stb.

Fedora 22, Thinkpad x220

> minden csatlakozáskor új IP címet kapok

Most akkor felteszem újra a korábbi kérdésemet, hátha választ kapok rá... :)
A prefix statikus vagy dinamikus?

1.) a PPPoE újracsatlakozásnál változik-e a kapott prefix?
2.) a DHCPv6 prefix delegációnál, változatlan DUID-ot elküldve változik-e a kapott prefix?

Az IPv6 olyan, mint kisgyermeknek a járás: elméleti síkon nem lehet megtanulni. Én 2000-2001 óta használok IPv6-ot, ebből az első pár év inkább csak kisérletezés volt, és kb. 2009 óta építek mindent dual stackre, amit csak lehet.

- Sokat tanultam
- Sok új szoftvert kezdtem el használni, ezekben rengeteg gyermekbetegséget találtam, amit jelentettem a fejlesztőknek, és segítettem a hibák kijavításában
- Sok, korábban járatlan utat jártam ki

Jelenleg ott tartunk, hogy a munkahelyemen az adatforgalom több, mint fele IPv6 felett megy ki a külvilágba. Házon belül a szolgáltatások kb. 90%-a elérhető IPv6 felett.

Szintén teszt jelleggel, elkezdtem IPv6-only hálózatokat építeni. Az ugyanis egy dualstack környezetben nem derül ki könnyen, hogy mi az, ami még mindenáron függ az IPv4-től.

Eddig az volt a koncepció, hogy az IPv4 tengerben voltak IPv6-os szigetek, amiket tunnelekkel kötöttünk össze. Most már ott tartunk, hogy az IPv6 tenger közel összefüggő, amiben IPv4 szigetek keletkeznek. Lásd: UPC DS-Lite.

Hogy mikor fogjuk végleg lekapcsolni az IPv4-et? Megjósolni sem tudom.

Utolsó mondatodra: biztos hogy gondolkodhatunk a lekapcsolásán? Vagy inkább csak szigethálózattá formálása a valószínűbb?

Miért kérdezem így? Sokan PC-kkel és szerverekkel találkoznak, ott néhány év alatt lemehet egy teljes átállás. Én sok beágyazott cuccal is találkozok munkám során (ICOM ipari VHF sávú IP rádió, DIN sínes IP-s eszközök). Ezek ha valahol telepítésre kerülnek, bármilyen meglepő akár 2 évtizedig is a kültéri szekrényben maradnak. És ezeket ha ma megveszed és telepíted, kizárólag IPv4-et tudsz rajta felkonfigurálni.

A szigeteden te a világ végéig ott IPv4-ezel, ahol akarsz. Sőt, felőlem IPX-et és NetBEUI-t is használhatsz :)

Én a szolgáltató-oldalon dolgozom - a globális hálózatokban a dual-stack után egyre jobban a single stack IPv6 fog teret hódítani. A dual-stack ugyanis csak az átállási időszakra jó - a fő probléma fennmarad vele, miszerint nincs elég IPv4 cím.

Otthon, átlagos felhasználóként pedig azért fogom kiszorítani a "kis szigetemből" az IPv4-et, hogy a rendszerem minél egyszerűbb legyen. A dual-stack nyilván dupla nyűg.

Egyelőre persze IPv4 szigetek lesznek. Aztán majd egyre kevesebb lesz belőlük.

( nagyorgy v | 2015. 12. 05., szo – 19:42 )

Két éve vártam ezt a pillanatot, erre kiderült, hogy az ASUS RT-N18U eszközöm 3.0.0.4.376_3754 firmwarrel nem kezeli rendesen az IPV6 -ot a belső hálózaton.

Mindenféle bizonytalan béta frissítéseket ajánlanak.

Régebbi verzióval nem ment, 2 vagy 3 verzióval voltam lemaradva. Felfrissítettem, basic -> ipv6 alatt bekapcsoltam a "dhcpv6 with prefix delegation"-t és működött out of the box. Igaz, csak a wan interface kapta meg az ipv6 címet, lan oldalra még nem sikerült áttuszkolnom, de 4-5 percnél többet nem is foglalkoztam a dologgal. Most hétvégén meg akartam csinálni, de sajnos jutott meló a hétvégére bőven, így nem maradt rá időm, majd a jövő héten:)
CPU load valóban magas (2 környékén mozog) de a gyakorlatban semmilyen problémát nem okozott, a cpu usage 2-5% környékén mozog alapból

// Happy debugging, suckers
#define true (rand() > 10)

Közben lett egy icipici idő. Láttam hogy mások is szívnak azzal, hogy a duid rossz fizikai címből generálódik, így gyorsan összedobtam egy progit amivel ki tudom dumpolni a dhcp6c_duid tartalmát. Egyértelmű hogy nem a kívánt tartalommal volt, így a progit módosítva visszaírtam bele azt, amit szeretnék. A dhcp6c-t ujrainditva mar szepen megkapta a lan a delegalt prefix-et, network restart utan pedig a windowsos gepek is osszeszedtek a helyuket.
Amit ki kell talalni, hogy lehet ravenni magat a dhcp6c -t hogy onnan akarja osszerakni a duid-ot

// Happy debugging, suckers
#define true (rand() > 10)

RT-N18U, gyári firmware, talán egy verzióval a legutolsó előtt (sárgán pislog, hogy van frissítés): normálisan megy, nincs extra cpu-használat, a LAN-on szépen ott figyelnek az IPv6-os címek, sebesség nagyjából "ami a csövön kifér".
Innentől kezdve nem sok értelmét látom a 3rd party firmware-rel történő barkácsolásnak.

Én azt tapasztaltam tegnap éjjel fél egy után, hogy elhagyta magát a router IPV6 tudása. Akármit csináltam nem akart újra rákapcsolódni. 2* is újraindítottam direkt. Reggel megnéztem megint, továbbra se megy semmi. Akkor is kapott egy rebootot. Bejöttem dolgozni, és a céges vpn-en kicsit benéztem, hogy mi a helyzet, és azt látom, hogy ott figyel a v6 a cuccon.

( hzsolt94 v | 2015. 12. 05., szo – 23:38 )

Nekem egy Archer C9 van, (gyári fw, elvileg tudnia kellene) de nem sikerült beállítani.
Végigpörgettem az összes IPv6-os lehetőséget (DHCPv6, PPPoEv6, PPPoE+DHCPv6 stb) de vagy szimplán nem kap v6-os címet a router, vagy (az internet szerint helyes (PPPoE+DHCPv6+Prefix-delefation) beállítással még a v4 címemet is elveszíti.

Vajon nálunk még nem megy a v6, vagy valami más gond van?

( stanci | 2015. 12. 07., h – 20:37 )

Valakinek XVII. kerületben GPON access-ről megy?
Cisco router-rel tolnám, de IPV6CP-re protocol reject-et kapok.
köszi

El tudnád mondani hogy csináltad Mikrotiken? Én a következőket tettem működő IPv4 PPPoE mellett:

- Bekapcsoltam az ipv6 csomagot
- A használt PPPoE Profile-ban a "Use IPv6"-ot yes-re állítottam
- Az IPV6 - DHCP Client-ben hozzáadtam egy újat 64-es prefix length-el a pppoe-out interfészre

Így a dhcp client status: error-t ír, több infóm nincs. Tovább nem tudtam menni, mert már ip-t sem kapok.

Valami kimaradt volna? :)

---
http://www.vultr.com/?ref=6814182

1-ok
2-ok
/ipv6 dhcp-client
add add-default-route=yes disabled=no interface=Digi pool-name=Digi_ipv6

/ipv6 address
add disabled=no from-pool=Digi_ipv6 interface=ether2
/ipv6 nd
set [ find default=yes ] interface=Digi
add hop-limit=64 interface=ether2

Interface:
Digi: PPPoE
Digi_ipv6: ipv6 dhcp client
ether2: belső háló

ezzel a belső hálón is kapnak ip címet a kliensek

DHCPv6 PD működéshez a következőkre jöttünk rá:

- RFC3315 Type 3 DUID kell (DUID-LL), ahol is az iftype értéke '1'.
- A DUID-ban link-layer addressként a kimenő, pppoe-t kezelő ethernet IF mac-jét kell megadni. Hogy miért az kell, azt nem tudom, mert elvileg nem is látszódik a ppp kapcsolaton belül ez, de mindegy.
- 64-es prefixet kell kérni, az IAID értéke látszólag mindegy.

A pppoe-t termináló HP desktopon a 21-es VLAN subineterfészt használom:

# ip link sh dev eth0.21
7: eth0.21@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 00:11:85:75:4b:07 brd ff:ff:ff:ff:ff:ff

A DUID nálam így a következő: 00:03:00:01:00:11:85:75:4b:07

TCPdumpban kb ez fog látszódni:

10:06:21.660688 Out ethertype IPv6 (0x86dd), length 206: (hlim 1, next-header UDP (17) payload length: 150) fe80::c1a:473b:74a3:c6.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=c89ef6 (client-ID hwaddr type 1 001185754b07) (elapsed-time 0) (vendor-class) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)) (reconfigure-accept) (option-request opt_82 opt_83))
10:06:21.665344 In ethertype IPv6 (0x86dd), length 181: (hlim 64, next-header UDP (17) payload length: 125) fe80::cd99:e689:7b3b:776e.54081 > fe80::c1a:473b:74a3:c6.546: [udp sum ok] dhcp6 advertise (xid=c89ef6 (client-ID hwaddr type 1 001185754b07) (server-ID hwaddr/time type 1 time 478104455 000000000000) (DNS-server 2a01:368:a::2 2a01:368:a::1) (IA_PD IAID:0 T1:302400 T2:483840 (IA_PD-prefix 2a01:36d:115:4446::/64 pltime:604800 vltime:604800)))
10:06:21.665731 Out ethertype IPv6 (0x86dd), length 253: (hlim 1, next-header UDP (17) payload length: 197) fe80::c1a:473b:74a3:c6.546 > ff02::1:2.547: [udp sum ok] dhcp6 request (xid=4654ef (client-ID hwaddr type 1 001185754b07) (server-ID hwaddr/time type 1 time 478104455 000000000000) (elapsed-time 0) (vendor-class) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0) (IA_PD-prefix 2a01:36d:115:4446::/64 pltime:604800 vltime:604800)) (reconfigure-accept) (option-request opt_82 opt_83))
10:06:21.668169 In ethertype IPv6 (0x86dd), length 181: (hlim 64, next-header UDP (17) payload length: 125) fe80::cd99:e689:7b3b:776e.54081 > fe80::c1a:473b:74a3:c6.546: [udp sum ok] dhcp6 reply (xid=4654ef (client-ID hwaddr type 1 001185754b07) (server-ID hwaddr/time type 1 time 478104455 000000000000) (DNS-server 2a01:368:a::2 2a01:368:a::1) (IA_PD IAID:0 T1:302400 T2:483840 (IA_PD-prefix 2a01:36d:115:4446::/64 pltime:604800 vltime:604800)))

logban meg ez:

dhcpcd 15927 ppp0: unsupported interface family 00
dhcpcd 15927 DUID 00:03:00:01:00:11:85:75:4b:07
dhcpcd 15927 ppp0: IAID 00:00:00:01
dhcpcd 15927 ppp0: soliciting a DHCPv6 lease
dhcpcd 15927 ppp0: ADV ::/64 from fe80::cd99:e689:7b3b:776e
dhcpcd 15927 ppp0: REPLY6 received from fe80::cd99:e689:7b3b:776e
dhcpcd 15927 eth0.15: loading for delegation
dhcpcd 15927 eth0.15: IAID 85:75:4b:07
dhcpcd 15927 eth0.15: adding delegated prefixes
dhcpcd 15927 eth0.15: adding address 2a01:36d:115:4446::1/64
dhcpcd 15927 ppp0: adding reject route to 2a01:36d:115:4446::/64 via ::1
dhcpcd 15927 eth0.15: adding route to 2a01:36d:115:4446::/64
dhcpcd 15927 ppp0: renew in 302400 seconds, rebind in 483840 seconds
dhcpcd 15927 ppp0: deleting reject route to 2a01:36d:115:4446::/64 via ::1
dhcpcd 15927 forked to background, child pid 15983
dhcpcd 15983 eth0.15: removing route to 2a01:36d:115:4446::/64

vegyük észre ugyanakkor, hogy a dhcpcd még mindig egy fos, mert annak ellenére, hogy a doksiban 0-s slaid mellett nem vesz fel reject routeot, mégis megteszi, emiatt a eth0.15-re már nem kerül fel a route:

dhcpcd 15927 ppp0: adding reject route to 2a01:36d:115:4446::/64 via ::1
dhcpcd 15927 eth0.15: adding route to 2a01:36d:115:4446::/64

Ezer köszönet az infóért, az én problémám megoldódik így:
Nem szúrtam ki, hogy a DUID a másik interface MAC-jét tartalmazza. A Mikrotik-ek valamiért egy konkrét iface MAC-jét használják DUID képzésére. Nekem meg régebben szükségem volt a passzív POE-in -re, így megcseréltem két portot a konfigomban.
Az alap konfig szerint eth1 a wan oldali iface, ami most lan oldalon van, na az ő MAC-je van a DUID-ban.....

> A Mikrotik-ek valamiért egy konkrét iface MAC-jét használják DUID képzésére.

Nem csak a Mikrotik, (sajnos) ezt előírás szerint így kell csinálni: az előírás szerint a DUID perzisztens, és a DHCP klienst annak teljes élettartama alatt azonosítja, tehát nem változik hálókártyacserével sem, marad a legelőször generált DUID akkor is, ha a generálása alapjául szolgáló hálókártya már rég nincs jelen a gépben.

Persze, ha kipucolod a korábban generált DUID-ot a rendszerből, és újat generálsz...

Na úgy verifikáltam a kérdéskört, hogy távolról ipv4-en bevpn-eztm, majd a két fizikai iface mac-jét megcseréltem.
Így a "DUID-konzisztens" MAC a PPPoE alatti fizikai iface MAC-je lett, azonnal kaptam prefix-et :)

Tehát tényleg az volt a gond, hogy nem a PPPoE parent iface MAC-je volt a DUID substringje....

" - A DUID-ban link-layer addressként a kimenő, pppoe-t kezelő ethernet IF mac-jét kell megadni. Hogy miért az kell, azt nem tudom, mert elvileg nem is látszódik a ppp kapcsolaton belül ez, de mindegy."

Ezért azért járna a tudjákmi....

RFC3315

Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs for equality. Clients and servers MUST NOT in any
other way interpret DUIDs. Clients and servers MUST NOT restrict
DUIDs to the types defined in this document, as additional DUID types
may be defined in the future.

The DUID is carried in an option because it may be variable length
and because it is not required in all DHCP messages. The DUID is
designed to be unique across all DHCP clients and servers, and stable
for any specific client or server - that is, the DUID used by a
client or server SHOULD NOT change over time if at all possible; for
example, a device's DUID should not change as a result of a change in
the device's network hardware.

Én alapjaiban véve egy szabály- és RFC követő ember vagyok, de mivel az elmúlt 20 évben minden gépet a MAC címe alapján azonosítottunk a rendszerünkben (és az alapján osztottunk DHCP-vel IPv4-es címeket) ezért kizártuk azt, hogy minden gép esetében még a DUID-ot is rögzítsük, és kezeljük azt a szituációt, hogy az egyik megváltozott, a másik pedig nem.

A Windows meg külön passza mek, hogy csak DUID-LLT-t tud generálni. Sebaj, csak az utolsó 48 bitet használjuk azonosításra (= MAC) a többi kuka. A gép indításakor pedig mindig új DUID-ot generálunk, és az eszközkezelőből mindig automatikusan eltávolítjuk a már jelen nem lévő hálózati eszközöket.

( Rill | 2015. 12. 08., k – 19:54 )

Nagy a valoszinusege en baszok el valamit mert most laptopon (Xubuntu) minden gond nelkul megy atlagos pppoe kapcsolat letrehozasa utan. OpenWRT-n csak a ping-ig jutok. Oldalak nem toltenek be.

/*megjegyzes magamnak es esetleg segitseg masoknak*/

( zeller | 2015. 12. 08., k – 20:42 )

Még nem ért ide... Vagy én rontok el valamit? 


config interface 'wan'
        option ifname 'eth0.2'
        option _orig_ifname 'eth0.2'
        option _orig_bridge 'false'
        option proto 'pppoe'
        option username '...'
        option password '...'
        option ipv6 '1'

config interface 'wan6'
        option proto 'dhcpv6'
        option ifname 'eth0.2'
        option reqaddress 'try'
        option reqprefix 'auto'

OPenWRT, Barrier Breaker 14.07...

Negatív - a logban ennyi releváns infó kerül...:

Tue Dec 8 20:50:10 2015 daemon.notice netifd: Interface 'wan6' is setting up now
Tue Dec 8 20:50:10 2015 daemon.notice odhcp6c[10849]: (re)starting transaction on pppoe-wan
Tue Dec 8 20:50:10 2015 daemon.notice odhcp6c[10849]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0)

( TommyB | 2015. 12. 08., k – 20:48 )

Ez a szabály aktív? ( /etc/config/firewall )


config rule
option target 'ACCEPT'
option src 'wan'
option proto 'udp'
option name 'dhcp6'
option family 'ipv6'
option dest_ip 'fe80::/16'
option dest_port '546'

Köszi, alakul, de routing infót még nem kapok, az ifstatus wan6 kimenetében a route üres :(

Valami tényleg nem volt kerek - interfész le/föl, tűzfal le/föl, és most megy :) 


root@janus:~# ping6 ipv6.test-ipv6.com
PING ipv6.test-ipv6.com (2001:470:1:18::119): 56 data bytes
64 bytes from 2001:470:1:18::119: seq=0 ttl=52 time=162.138 ms
64 bytes from 2001:470:1:18::119: seq=1 ttl=52 time=161.589 ms
64 bytes from 2001:470:1:18::119: seq=2 ttl=52 time=161.278 ms

Bentről is megy :-) De ez miért is jó nekem...? :-P

Ma ismét nem volt routing infó az ifstatus wan6 parancs kimenetében, a ping6 "ping6: sendto: Operation not permitted" hibaüzenetéből derült ki, hogy miért bűn lassú a böngésző - egy csúnya hack megoldotta, de ennek nem így kéne működni...: 


ip -6 route add default dev pppoe-wan

( Chas | 2015. 12. 09., sze – 21:35 )

Megszületett a megoldás OpenWRT 15.05-re:
Miután a pppoe kapcsolat felépült, ne várj IPv6 címre!
A WAN6 kapcsolatot állítsd DHCPv6-ra, és a fizikai interfésznek kösd be (kézzel) a pppoe-wan nevű eszközt.
Reconnect és megy is minden.

húzzák az optikát folyamatosan, üllőin kb klinikáknál nekem már augusztusban átkötötték (igaz, akkor még hivatalosan nem is lehetett volna, csak megszopatta őket a koax :) )
De v6 még nekem sem volt reggel, viszont ma elindult zuglóban az irodában is már, mikrotikkel megy szépen. :)

Megint eltűnt a jó kis v6 címem. Ennyire kísérleti a szolgáltatás jellege, vagy én kattintgattam el valamit? Tegnap kikapcs előtt még volt címem. A logban van egy ilyen sor:
daemon.warn netifd: You have delegated IPv6-prefixes but haven't assigned them to any interface. Did you forget to set option ip6assign on your lan-interfaces?
Ez akármit is jelentsen (úgyse értem:)

Azon azért elgondolkoztam, hogy ehhez az egész IPv6 bekapcsoláshoz nem lett volna jó a Diginek valami komolyabb tájékoztatást nyújtania a felhasználók számára? Mert szép, hogy itt szájhagyomány útján terjednek a beállításhoz szükséges részletek, de izé.

( sirgeoff | 2015. 12. 10., cs – 21:40 )

Sziasztok!

Köszönet gigalomania-nak, szmiatf-nek és sibikének, nálam is működik az ipv6 a mikrotikemen.
A DUID és az ethernet MAC address kicsit megdolgoztatott, de már minden rendben van.
A helyszín Bp. XX. kerület, az előfizetést 2010. novemberben kötöttem.

Van fix ip(v4) címem, kérdés, hogy ez a szolgáltatás kiterjed-e az ipv6-ra is?

( stanci | 2015. 12. 11., p – 00:02 )

Elindult a XVII. kerületben is!
Cisco konfigban tudok segíteni ha kell, bár elég könnyen megtalálható mi kell hozzá.

Megerősítem. Elindult a XVII. kerület FTTH területén is.

Azonban szomorúan vettem tudomásul, hogy nem fix IPv6 tartományt kapok, hanem minden feljelentkezéskor mást.
Így semmilyen előnye számomra nincsen, le is tiltottam az eszközben. Majd ha bármilyen számomra fontos tartalom csak IPv6-on lesz elérhető vagy fix címeket kezdenek osztani, akkor újra előveszem a kérdést.

https://jeremy.visser.name/2009/06/why-dynamic-ipv6-subnet-allocations-…

Szia!
Kérnék egy kis segítséget.
A Dialer interface kap v6 címet, de a belső hálózattal nem boldogulok...

#sh ipv6 int di1
Dialer1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::..
No Virtual link-local address(es):
Description: ---
Stateless address autoconfig enabled
Global unicast address(es):
2A01:36C:..:5E70, subnet is 2A01:36C:..::/64 [EUI/CAL/PRE]

####################################################################

#ping ipv6 hup.hu

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4C48:2:A33E::6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

####################################################################

#sh run int di1
Building configuration...

Current configuration : 487 bytes
!
interface Dialer1
ipv6 address dhcp
ipv6 address autoconfig
ipv6 enable
ipv6 dhcp client pd PD rapid-commit

####################################################################

#sh run int bvi1
Building configuration...

Current configuration : 414 bytes
!
interface BVI1
description --- INET BRIDGE IP IFACE ---
ipv6 address PD ::1/64
ipv6 enable
ipv6 nd other-config-flag

####################################################################

Mit rontok el? (a bridge interfészre nem ér panaszkodni, ugyanez van SVI-n is. Amúgy 1812W advipservicesk9-mz.124-24.T3)

( dNi | 2015. 12. 11., p – 12:20 )

Miközben én is próbálom megbűvölni a v6-ot, elfogott az érzés, hogy már 20 éves az ipv6 és még csak most szenvedünk a bevezetésével/komolyabb használatával. Amire minden v6-ot fog használni, már rég elavult lesz, esetleg olyan probléma lesz vele amiről még nincs tudomásunk. :))

---
http://www.vultr.com/?ref=6814182

( spymorass v | 2015. 12. 11., p – 13:59 )

Azt sikerült elérnem, hogy a router wan oldala megkapja az IPv6-os címet. OpenWRT alatt milyen beállításokkal lehet megoldani, hogy a belső hálózatos eszközök is kapjanak IPv6 címet?
Igazából nem nagyon értem még a működését, így fogalmatlanul keresgélek. Mivel /64-et kapunk, ezt hogy adjuk tovább? Egy csomó megoldásról olvasgattam, de nem tudom, hogy melyik kellene ide.
Jelenleg ez a beállításom:

network config:

config interface 'lan'
option ifname 'eth0.1'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '64'

config interface 'wan'
option ifname 'eth0.2'
option _orig_ifname 'eth0.2'
option _orig_bridge 'false'
option proto 'pppoe'
option username '***'
option password '***'
option ipv6 '1'

config interface 'wan6'
option proto 'dhcpv6'
option ifname '@wan'
option reqaddress 'try'
option reqprefix 'auto'

dhcp config:

config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option ra 'relay'
option dhcpv6 'relay'
option ndp 'relay'

config dhcp 'wan6'
option dhcpv6 'relay'
option ra 'relay'
option ndp 'relay'
option master '1'

odhcpd, odhcp6c csomag telepítve van. Kell még ezeken kívül más?

Kettő /64 tartományról beszélünk.
A routered PPPoE interfészére a 2a01:36c:xxxx:yyyy/64-ből
A routered mögötti lan-ra a 2a01:36d:xxxx:yyyy/64-ből

OpenWRT-15.05 esetén a gyári tűzfalszabályok mellett nálam nem delegált LAN oldalra semmit. Így én saját tűzfalszabályt írtam a /etc/firewall.user-be. Onnantól delegál rendesen. A FORWARD táblába az élesztéshez minimumnak csak ennyi került.

ip6tables -I FORWARD 1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -I FORWARD 2 -i br-lan -j ACCEPT
ip6tables -I FORWARD 3 -j REJECT

Sziasztok!

Én is kapok ipv6-ot a pppoe-wan interfészre, de nem látom, hogy a belső hálozaton kiosztana IPv6-os belső címeket.
Mit lehetne még tenni a firewall.user-en kívül?
Nekem is openwrt CC van.

inet addr:92.249.OOO.ZZZ P-t-P:10.0.0.1 Mask:255.255.255.255
inet6 addr: fe80::70da:727e:364b:b7fe/10 Scope:Link
inet6 addr: 2a01:36c:109:XXXX:70da:766e:364b:b7fe/64 Scope:Global

Esetleg kézzel próbáld meg beütni a 3 sort parancsként (reboot-ig marad érvényben). Ha ez segít, akkor nálad is tűzfalprobléma van. Ekkor eldöntöd hogyan tovább. Én egyelőre nem vettem a fáradságot hogy kifésüljem a gyári szabályrendszert és megkeressem hol a problémája, inkább miután ez működött beírtam a /etc/firewall.user -be. Egyelőre.

Továbbá: webfelületen a LAN-on:
IPv6 assignment length: 64
Router Advertisement-Service: server-mode a másik kettő (dhcp és ndp) disabled
Always announce default router - pipa
A két DNS szerver be van írva nálam: 2a01:368:a::1 és 2a01:368:a::2

Így legalábbis működik az OpenWRT-15.05 a TP-Linken, minden megkapja az IPv6-ot.
Érdekességként megjegyzem: Androidos telefon felülete csak IPv4 címet ír ki, a a böngészőben a whatismyip.com viszont "lebuktatja". Megkapja az is.

( Turion | 2015. 12. 12., szo – 20:20 )

Direktbe rádugtam a hálókártyára a Digis kábelt és működik az ipv6. (százhalombattai vagyok)

Linux Mint 17.2 "Rafaela"

( Morc001 | 2015. 12. 13., v – 21:24 )

Nekem is megy szépen múlt hét óta, igaz az utolsó lépéshez kellett ez az info: http://hup.hu/node/144314#comment-1936996

OpenWRT Chaos Calmer van fent a router-en, előtte Barrier Breaker volt az első openWRT firmware rajta. Sosem állítottam a tűzfalon, a default-tal megy, és ha jól emlékszem a WAN6 is default DHCPv6 client-re van téve . Amit csináltam (TP-Link TL-WR741ND!):

SSH-val beléptem a router-re, és az ifconfig eth1 (az eth1 a WAN oldali interface) paranccsal megnéztem a WAN interface HWAddr (aka MAC) címét; pl. HWaddr F4:EC:38:aa:bb:cc. Utána beléptem a LuCI-be, és a HWAddr értéke elé írva a 00030001-et beírtam az értéket a Network -> Interfaces -> WAN6 -> Advanced Settings -> Client ID to send when requesting DHCP mezőjébe; pl. 00030001f4ec38aabbcc. A LAN interface-en IPv6 assignment length 64, és a DHCP IPv6 beállításoknál a Router Advertisement-Service server mode, DHCPv6-Service server mode, NDP-Proxy relay-mode, DHCPv6-Mode stateless + stateful, Always announce default router pedig nincs bepipálva. Ez után a LAN oldal is kapott IPv6 címet, és a router mögötti eszközök is boldogok.

Ugyanez config file-okban:

/etc/config/dhcp

config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '105'
option leasetime '1h'
option ra 'server'
option dhcpv6 'server'
option ndp 'relay'

/etc/config/network

config interface 'lan'
option force_link '1'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option stp '1'
option _orig_ifname 'eth0 wlan0'
option _orig_bridge 'true'
option ifname 'eth0'
option ipaddr '192.168.x.1'
option ip6assign '64'

config interface 'wan'
option ifname 'eth1'
option _orig_ifname 'eth1'
option _orig_bridge 'false'
option proto 'pppoe'
option username '*****'
option password '*****'

config interface 'wan6'
option ifname '@wan'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option clientid '00030001f4ec38aabbcc'

( guyee | 2015. 12. 17., cs – 18:29 )

Ubiquiti EdgeRouter Lite-tal ha valakinek gondja van az IPv6-tal, az szóljon, de ha már írok...

A http://ipv6-test.com oldal levon 2 pontot, ha nem megy a befele ICMPv6. Kb 3 órát szívtam mire rájöttem, hogy a saját jó kis win10-em tűzfala nem engedi be, de mindegy, most már megy... :D

Viszont felmerült bennem, hogy jó-e ez így... mondanám, hogy a PMTU miatt esetleg a Packet Too Big-et engedni kéne, de mondjuk mindegy, a saját hálómon úgysem lesz kisebb MTU, mint a pppoe miatt beszűkült upstream, szóval az sem kell.

Akkor viszont kérdés, hogy van valami plusz (lényeges, a működéséhez szervesen kapcsolódó, de az IPv4-től eltérő) értelme IPv6-on az ICMP-nek? Vagy ha csak a PMTUD, akkor miért szeretné annyira az a másik oldal, hogy megkapjam azt a nyüves ICMP-t? 20 pontból 2, az 10%... az elég fontosnak tűnik. :D

A PMTUD mellett még az IPv6 -> IPv4 fallbackhez is erősen szükséges ICMP. (Pl. távoli hostnak van IPv6 címe, de egyes szolgáltatásai csak IPv4-en érhetőek el. Destination port/host/network unreachable és társai.)

Egyébként pedig mindig utáltam, ha valahol globálisan tiltva volt az ICMP, IPv4 esetében is. Tessék rá rate limitet tenni flood ellen.

Ja, jó, én is idegbajt kapok, amikor mindenféle csatolt hálókon tiltják, és amikor nálam (vagy mégjobb, máshol!) failover van vpn-re kisebb mtu-val, akkor megy a pislogás, hogy pingik, de amint forgalom indulna, az nem megy. :D

Na jóvan, én engedélyeztem, de akkor ezek szerint win10-en (meg 2k8R2-n, más nincs itthon) alapból tiltva van, és az nem jó...

Csak valahogy ezekből az jön le, hogy oké, hogy így összevadásszuk magunknak, működik is, de mintha valahogy nem lenne eléggé kitalálva ez az egész... a win szűri amit nem kéne, junos-szal 1 napig szívtam, normálisan sehogy nem jött össze, most ezzel a ubiquitivel egész jól összeállt, de ahogy a fórumon olvasom, a szívás az platformfüggetlen.

Mindegy, nekem megy, köszi! :)

"Viszont felmerült bennem, hogy jó-e ez így... mondanám, hogy a PMTU miatt esetleg a Packet Too Big-et engedni kéne, de mondjuk mindegy, a saját hálómon úgysem lesz kisebb MTU, mint a pppoe miatt beszűkült upstream, szóval az sem kell."

Ezt nem értem. Mivel csomag darabolás csak a végpontokon történik, ezért nagyon fontos, hogy a végpontokig el is jussanak az PMTU üzenetek. Hogy jön ide a helyi háló MTU-ja?

A helyi háló MTU-ja azért lehet fontos (bejövő csomagra gondoltam, ahol én küldöm a too biget), mert ha a nálam lévő (tegyük fel hogy überkomplex) massza egress oldalán szűröm a packet too big ICMP-ket, és van nálam egy olyan szegmens, ahol az MTU kisebb, mint a path külső szakaszán, akkor annak az eszköznek, ami a kisebb MTU-jú szegmensre pakolná a nagy csomagot, annak el kell dobnia azt, és vissza kéne küldenie egy packet too big ICMP-t a forrásnak. Ami viszont soha nem érne célba, mert ugye szűrve van. Ez esetben nem menne a PMTUD, és a kedves család engem anyázna, hogy kellett nekünk digire váltani, meg drága routert venni. :D

Viszont mivel nálam tény, hogy nincs 1500-nál kisebb MTU, a PPPOE miatt meg ennél kisebb az upstream MTU, ICMPv6 packet too big nálam nem fog generálódni, tehát akár szűrhetném is (persze nem teszem).

Kimenő csomagnál meg nyilvánvaló, hogy be kell jönnie a packet too bignek...

Ismereteim szerint IPv6-on nincs is fragmentation, csak PMTUD alapján csökkentett csomagméret.

Aztán lehet hogy valamit félreértek, végülis még csak 2 napot töltöttem az IPv6 világában. :D

( persicsb | 2015. 12. 17., cs – 20:13 )

NetGear WNDR4300-as routerem van, az eredetileg rajta lévő OpenWRT-alapú cuccal. Saját OpenWRT-t nem használok rajta, mivel a HW NAT hiánya miatt csapnivaló a teljesítménye.
Nem tudtam életrekelteni még a saját UI-on keresztül az IPv6-ot, sem PPPoE, sem Passthrough, sem DHCP módban. Mi lenne a megfelelő?
Veszprémben vagyok, bár talán most már a földrajzi hely nem számít, és mindenhol engedélyezve van az IPv6.

Első hallásra nem tűnik logikusnak, mert a PPPoE egy relatíve egyszerű enkapszuláció, míg a NAT egy komplex dolog (rule matching, state table lookup, header rewrite, stb.) Ennek ellenére meg tudom erősíteni: egyes PPPoE implementációk CPU igényéhez képest a NAT igénye alacsonyabb.

A Linuxos, userspace PPPoE (rp-pppoe) ilyen szempontból tragikus, egy Core2 Duo notebookon 140 megabites adatforgalom PPPoE fölött 100% CPU usage-t csinál. A Windows-féle PPPoE sem túl rózsás. A Linuxos kernel PPPoE egészen jó, a NetBSD kernel PPPoE pedig remek. (Egyébként mindkettő utóbbi is rp-pppoe-n alapul)

Hogy az OpenWRT-ben milyen PPPoE van, azt így látatlanban passzolom, remélhetőleg Linux kernel PPPoE. Az nem rossz, de szerintem egy 700-as router procin az is 50% fölötti CPU-t ehet 100 megabit fölött. Ha valakinek van kéznél, és lebenchmarkolja, azt köszi előre is.

PPP mint a PPPoE is azzal nyűglődik, hogy escape-szekvenciás protokoll, karakterbeszúrással, amit a CPU-nak vételkor byte-ról byte-ra át kell nézni. És nem csak a fejlécet, hanem mind az 1500 byte-ot+beszúrt karaktert egyesével összehasonlítani.

A NAT esetén keresni kell az IP:PORT táblában, ami ha nagyon sok aktív kapcsolatot tartalmaz, akkor erősebben lassít.
Viszont a csomagot nem kell végigmazsolázni, csak a fejlécben szereplő byte-okat kell kikapni. Az 1500 byte-os csomag 99%-a a proci terhelése nélkül DMA-ból mehet. Ez azt is jelenti, hogy kisebb csomagoknál (pl. VoIP) persze jobban terheli a NAT-ot ugyanaz az adatsebesség, de jellemzően 1500 byte-os keretek vannak.

IPv6: NAT nincs, otthonod tűzfalazása miatt conntrack van. Ennek terhelése sok aktív kapcsolatnál kb. ugyanannyi. Ha az eszközeid védelme meg van oldva, akkor végülis elhagyhatnád a tűzfalazást elvileg. A gyakorlatban franc tudja, mikor támadnák be pl. a SMART TV-t.

Nagyon jó összefoglaló. :)

NAT esetében még két faktor játszhat be:
- UDP/TCP-nél a cheksumot újra kell számolni a megváltozott forrás/célcím miatt, ehhez muszáj a teljes csomagot újra felolvasni.
Ezen tud segíteni egy TCP/UDP offload, kérdés, hogy a SOHO routerekben van-e erre céláramkör.
- Bizonyos protokollok esetén (FTP, SIP) a csomag payload-ba is be kell nyúlni, ott nem lehet DMA-zni.

IPv6:
- Mi csináltuk régen, amikor nem bírta a router a conntrack-et, hogy szűrtük a befelé jövő TCP SYN csomagokat, ezzel a bejövő kapcsolatokat. Nyilván ez nem működik UDP/ICMP-re. :(

Mértem OpenWRT-vel IPv6 vs. IPv4 routing perfomanciát, meglepő eredményekkel, majd írok róla egy rövid blogbejegyzést.

De jó ötletet adtál:
- conntrack csak UDP és ICMP-nél.
- tcp esetén pedig syn szűrés
Ez így talán takarékosabb lesz. Ki is próbálom az OpenWRT-s cuccban.

ip6tables -A FORWARD -p udp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i br-lan -j ACCEPT
ip6tables -A FORWARD -i pppoe-wan -p tcp ! --syn -j ACCEPT
ip6tables -A FORWARD -j REJECT

Kérdés, hogy ez esetben a conntrack csak UDP-re tölti az IP:PORT táblázatot, vagy TCP kapcsolatok esetén is?

Nekünk nem kellett UDP, TCP, tehát a teljes conntracket ki tudtuk kapcsolni, de úgy látom ezek még kellenek:

iptables -t raw -I PREROUTING -p tcp -j NOTRACK
iptables -t raw -I PREROUTING -p tcp -j NOTRACK
iptables -t raw -I OUTPUT -p tcp -j NOTRACK
iptables -t raw -I OUTPUT -p tcp -j NOTRACK

http://serverfault.com/questions/72366/how-do-i-disable-the-nf-conntrac…

Tapasztalatból sajnos.

RB850Gx2(RouterOS):
Routing: 900-1000 Mbps
NAT: 750-1000 Mbps
NAT+PPPoE: 500-550 Mbps

ArcherC9(gyári):
NAT: 850-1000 Mbps
NAT+PPPoE: 750-850 Mbps

RB2011(RouterOS):
Route: 1000 Mbps
NAT: 400-600 Mbps
NAT+PPPoE: 200-250 Mbps

Az igazsághoz hozzá tartozik, hogy PPPoE-t nem tudok NAT nélkül mérni, mert ugye szerverem nincsen.

PPPoE-t nem tudok NAT nélkül mérni, mert ugye szerverem nincsen

Ezen ne muljon :-)

/etc/ppp/pap-secrets-be: 

# client        server          secret          Allowed IP addresses
"username"      *               "password"      *

/etc/ppp/pppoe-server-options-be: 

mru 1492
mtu 1492
default-asyncmap

lcp-echo-interval 10
lcp-echo-failure 3

auth
require-pap

ms-dns <DNS-szervered-cime>
proxyarp

Szerver indítása: 

# pppoe-server -k -C "$HOSTNAME" -S "PPPoE-teszt" -L 10.255.255.255 -N 256 -R 10.0.0.1

( sibike | 2015. 12. 23., sze – 08:40 )

A főbb router típusokhoz itt egy beállítási segédlet.

( nagyorgy v | 2015. 12. 27., v – 22:34 )

Tud valaki megbízható ddns szolgáltatást IPV6 alá?
Semmi komoly, csak hogy elérjem az otthoni gépem a nagyvilágból.
IPV4 alatt a duckdns.org -ot használtam eddig, de náluk nem találtam IPV6 támogatást.

( mauzi v | 2015. 12. 28., h – 19:39 )

Jól látom, hogy IPCP-vel nem osztanak globális IPv6 címet a PPPoE linkre? (Link local-on tudom pingelni a túloldalt.)

Visszaszívtam. router advertisementtel jönne autoconfos global cím, viszont én nem fogadom (szándékosan) az autoconfot.

Igen, a /64 delegációval én is szívok, emiatt ha IPv6-ot akarok akkor csak bridge módú VPN-t tudok csinálni :-/

Az okokra visszatérve, szerintem szándékos üzletpolitikai döntés, hogy ilyen módon korlátozza a "nem-lakossági" jellegű használatot. Ez rímelne arra ahogy statikus IPv4 címet sem adnak a 100Mbps feletti csomagjaihoz, még ha pluszba fizetnél érte sokat, akkor sem. (Gondolom elég nagy érvágás lenne nekik ha valaki a 4000Ft-ért 1000/200 Mbps-en elkezdene sufnituning szerverszolgáltatásokat üzemeltetni.)

Üzleti csomagom van, fix IP címmel.

IPv4 címből bitang nagy hiány van, azért nem választható opcióként az olcsóbb csomagokhoz. Sőt, én kértem bérelt vonali árajánlatot tőlük (100e Ft fölötti havidíj kategória) és ott is nagyon húzták a szájukat, amikor egynél több IPv4 címet (prefixet) kértem volna.

A /64 nekem konkrétan nem lesz elég. (20+ VLAN van a telephelyen belül) - rá fogok kérdezni a /56-ra.

Ebben az esetben jó esélyt látok a /56-ra :-) Ha esetleg megoldanák neked, jelezd itt is, hátha rajtunk is segít.
(Időközben megnéztem, hogy a fix IP-re vonatkozó megjegyzéseim már nem biztos hogy igazak, mert ez a kitétel azóta eltűnt a DIGI honlapról és megjelentek a 100/100-nál gyorsabb kisvállalati csomagok)

Szerintem nincs összefüggésben a hiány és a fix IP-cím - ezek tipikusan 0-24 üzemelő kapcsolatok egy címet mindenhogyan folyamatosan fogvatart, akár DHCP akár statikus.

Az IPv4 címek hiánya elég relatív, valószínűleg hely és szolgáltató függő. Másik (kis) szolgáltatónál gond nélkül kaptam 4 IP-címet egy telephelyre, felár nélkül. A sulinet/niifi meg egész /27-et delegál az iskolába ahol használjuk. Szóval nem mindenütt van akkora nagy hiány. És akkor még az igazi pazarlásokról nem is szóltunk, mint pl. a BME-n ahol minden - már 2 éve nem használt - újjlenyomat olvasónak is publikus címet mutatott a kijelzője.

Már vannak KKV díjcsomagok, ahol akár 1000/200 hoz is rendelhető fix IP cím.
(egészen pontosan, már csak ezekhez lehet rendelni, lakosságihoz nem)
Egyébként én a héten futottam bele abba hogy a DIGI 100.64.x.x/10 tartományból
osztott IP címet az egyik kollégának, amit valahol kiNATolt a nagyvilág felé,
de "városon belül" a 100.70.x.x IP címmel forgalmazott, ezért a szintén
DIGI előfizetésen lévő céges tűzfal nem engedte be.

Gondolom van olyan üzleti ügyfél, akinek a szolgáltató üzemelteti a CPE-jét, azt pedig kívülről egy meghatározott mgmt tartományból el kell tudni érni. Meg amúgy is, sokan mondják, hogy van elég v6-os cím. Én személy szerint linknek publikus /128-at használnék PPPoE esetén...

( uid_558 | 2016. 01. 04., h – 13:12 )

Sikerult mar valakinek osszehoznia a digi-s IPV6-ot debian jessie alatt rendes kezimunkazos /etc/network/interfaces, /etc/ppp/... modon nem pedig kattingatos-networkmanageres-semmiresejo modon (ugy ubuntu 15.10 alatt nekem is osszejott)? Nalam valahogy mindig fe80::... ip cimet kap a ppp interface :(

/etc/ppp/options vegen ott a +ipv6 ipv6cp-use-ipaddr, tudtommal kb ennyi kellene. En cseszek el valamit? Es ha nem akkor mit?

( mauzi v | 2016. 01. 05., k – 12:18 )

Nos, hát akkor kiugrott a szög a zsákból: üzleti előfizetés, fix IP cím felárral. Az IPv6-on delegált prefix viszont dinamikus, ami jelen formájában (/64, tehát még subnetelni sem tudom, pedig kéne) kb. semmire sem jó.

Kértem, hogy a fix IP címes szerződéshez legalább fix IPv6 prefixet adjanak. Ez jött:

> Tisztelt Ügyfelünk!
>
> FIX IP címet kizárólag IPv4-est szolgáltatunk,
> IPv6-on dinamikus IP cím kerül kiosztásra.
> A kettő teljesen független egymástól.
> Ezért a kérdéseire nem tudunk érdemben válaszolni.

Politikailag korrekten: ez így konkrétan egy darab méretes lóf*sz.

Cool. Akkor mondom, hogy mit kíván a magyar nemzet:

1.) Statikus IPv6 prefixet!

- A statikus IP címes (feláras) csomagokhoz mindenképp
- Opcionálisan egyéb csomagokhoz, akár minden szerződéshez is. A dinamikus IP cím a takarékosság egyik eszköze, amire IPv6 esetében nincs szükség!

2.) Subnetelhető prefix delegációt!

- Minden végfelhasználónak legalább /56-ot, szükség esetén /48-at! (RFC 5375)
- Inkább minden felhasználónak /48-at! (RFC 6177)

3.) Reverse DNS delegációt!

- Tartományok esetén a végfelhasználó tudja delegálni a saját reverse zónáját a saját DNS szerverein!

Hogyan kell manapság aláírást gyűjteni? peticiok.com?

Na, akkor Te sem vagy DIGI ügyfél. DIGI ügyfélszolgálat = /dev/null.

Telefonon azt mondják, hogy ha gondom van, küldjem el emailben, az emailre pedig nem reagálnak. Amikor újra felhívod őket telefonon, hogy miért nem reagálnak az emailre, akkor azt mondják, hogy nem tudnak válaszolni, mert ők nem látják az emaileket.

GOTO 10

Azért ha belegondoltok, ez is szép karácsonyi ajándék volt hogy végre játszhatunk natív IPv6-tal. Hiszen nem sok szolgáltatónál van ma még erre lehetőség.
Sőt bérelt vonali előfizetés esetén sem. És szerverhosting esetén is kevés helyen.

Én reménykedem, hogy a Digi hamarosan tud adni FIX IPv4 mellé FIX IPv6-ot.
És reménykedem, hogy másik szolgáltatók is hamarosan követik a Digi példáját, beleértve a mobilszolgáltatókat is.

Szép ajándék, hogy játszhatunk vele, viszont így főként csak játékra jó, mi viszont dolgoznánk vele, elvégre 2016-ot írunk.

Ha már valamit implementálnak, és nincs technikai akadálya(!) akkor miért ne legyen a végfelhasználónak jó? Nem az ügyfél-elégedettségért dolgoznak?

Számomra például szomorúbb, mint írtam, hogy se a havi százezres árban levő bérelt vonali szolgáltatóknál, se a legtöbb hostingban nem lehet még igényelni IPv6 címet. Ahogy a mobilnetről sem érjük el az IPv6-os hálózatunkat.

Egyébként biztos vagy benne, hogy nincs a Digi-nél technikai, pusztán csak személyi akadálya?

Hogy láss a háttérproblémákról olyat, amire én sem gondoltam: egyik hostingszolgáltatónál mondták, hogy amíg nem tudnak IPv6-ra DDOS védelmi eszközt az internetkapcsolatukhoz beépíteni, addig nem kínálnak IPv6 szolgáltatást. Oka: a DDOS nem csak az adott szervert fekteti le, hanem a teljes hosting internet kapcsolatát tartósan ki tudja nyírni.

Jó hogy eszembejutott a probléma: gugliztam egyet. Nem elméleti probléma az IPv6-DDOS.
http://www.computerworld.com/article/2501708/network-security/ddos-atta…

A DDoS kérdésre adott választ el tudom fogadni.

Hogy egy prefix poolból egy ügyfélnek fixen osztják a címet, vagy pedig statikusan, az nem nagyon technikai kérdés, amíg a pool-ban van kellő számú delegálható prefix.

A /64 vs. /56 delegáció felvethet routing kérdéseket, ha rugalmatlanul alakították ki a rendszerüket. Ha nem, akkor szintén nem kellene gondot jelentsen, amíg van kellő szabad prefix.

Van a "spájzban" egy Internet/infrastruktúra szolgáltató cégem, mi is hasonlókat csinálunk, én itt nem technikai kérdésekre gyanakszom. Hanem üzletpolitikaira...

Mondjuk a v6-nak pont az a lényege, hogy ne kelljen dinamikus címekkel szopni... Nem igazán értem mit cigánykodik vele a upc is... (mintha náluk is dinamikus lenne, ráadásul natolt v4-gyel.)

Mellesleg nem fogtam fel valamit. A /64-et miért nem lehet subnetelni?

--
openSUSE 13.1 x86_64

Kis háttérinformáció: https://en.wikipedia.org/wiki/IPv6_subnetting_reference
Egyébként jó kérdés, hogy miért nem elég például /79 a legkisebb subnetnek, hiszen

a.) 48 bites ethernet MAC-ból tud generálni automatikusan IPv6 suffixet.
b.) 32 bites IP-ből is tud képezni dinamikusan IPv6-os címsuffixet.

Viszont például a FireWire vagy ZigBee 64 bites MAC-cel dolgozik. Valószínűsítem hogy ezért van 64 bitnyi autoconfig céljára fenntartott suffix.

( LiRul | 2016. 01. 06., sze – 18:56 )

Egy kis plusz infó annak aki NetworkManager-en keresztül használja a hálókártyáit.

Én Fedora 22 alatt abba futottam bele, hogy nem volt aktív a ipv6 privacy extension. Emiatt az ipv6-test.com figyelmeztetett is.

guglizás után kiderült, hogy az /etc/sysctl.d mappában lévő beállítások nem hatnak ki a NM-re. Az alábbi fájlba kell beírni egy plusz blokkot:


/etc/NetworkManager/NetworkManager.conf

[connection]
ipv6.ip6-privacy=2

Ha a fájl nem létezik vagy egyáltalán nincs benne connectoin blokk, akkor létre kell hozni a fájlt és betenni így a két sort.

Ezután systemctl restart NetworkManager.service és a

net.ipv6.conf.IFACE.use_tempaddr

alatt már 2-es értéket kell látnod. (Értelemszerűen IFACE helyére illesztsd be a saját hálókártyád iface nevét.)

És így már az ipv6-test.com SLAAC sornál nem fog sárgán világítani.

( nagyorgy v | 2016. 01. 06., sze – 19:10 )

Kíváncsiságból letiltottam az IPV4 -et.
Ahol VPS -s bérlek, ott már nem újdonság az IPV6. (thnx)

Youtube, Google, Yahoo, stb ( szóval akinek szakmailag is ciki lenne ha nem menne ) hibátlanul muzsikál.

A hírportálok közül a Kuruc.info és az Origo IPV6 ready!
Index.hu, 444.hu, stop.hu meg sem nyikkan.
Nagy előny, hogy a reklámszolgáltatók sem készültek, így adblock nélkül eltűnt a reklámok nagy része.

( poperator v | 2016. 01. 24., v – 11:43 )

Esetleg valaki kipróbálta/megkérdezte, akinek fix ip-s pppoe szolgáltatása van a DIGI nél, hogy az ipv6 is fix ebben az esetben? Bónusz kérdés hogy mekkora prefixel.

Olvass vissza pár hozzászólással feljebb. Kb. 2-3 darab <PgUP>-ot kell nyomni.

Hint: dinamikus a prefix, a linkre NDP-vel vagy DHCPv6 IA_NA-val kapsz dinamikus címet, és a belső hálódnak egy /64-es prefixet kérhetsz DHCPv6 IA_PD-vel, ami szintén dinamikus.

Szó szerint idézem az ügyfélszolgálat állásfoglalását:

| Tisztelt Ügyfelünk!
|
| FIX IP címet kizárólag IPv4-est szolgáltatunk,
| IPv6-on dinamikus IP cím kerül kiosztásra.
| A kettő teljesen független egymástól.
| Ezért a kérdéseire nem tudunk érdemben válaszolni.
|
| Tisztelettel:
| ---------------------------
| J***** A******
|
| Ügyfélkapcsolati ügyintézõ
| Customer Service
| ---------------------------
| DIGI Kft.
| Levelezési cím: 1384 Budapest, Pf.:739.
| Tel: 1272
| Fax: +3617070009

Mert, ha a nem fix, akkor nem fogják le dosolni, mi? Értem...

Na, Troll off... Miből gondolod, hogy a diginél van v4-re DDoS védelem? Annak idején úgy kellett IP cserét kierőszakolnom, mert a fixip-s "bérelt vonalam" DDoS alatt állt és mivel az is egy GPON-ra volt baszva a többi felhasználóval, szét volt esve a net a többieknél is. Azóta mi változott? Semmi? meglepődnék...

--
openSUSE 13.1 x86_64

( virgagabi | 2016. 05. 05., cs – 21:17 )

Be lehet állítani az radvd-t, hogy induláskor minden korábbi címet vonjon vissza? Vagy mit csináljak, hogy a router újraindulásakor a kliensek ne akarjanak a régi prefixen próbálkozi?

( djsilas | 2016. 07. 12., k – 17:26 )

Az remek, hogy elindult, de már le is állt? :/

tracert google.com
Tracing route to google.com [2a00:1450:400d:806::200e]
over a maximum of 30 hops:

1 1 ms 1 ms 2 ms 2a01-036d-1301-1332-0000-0000-0000-0001.pool6.digikabel.hu [2a01:36d:1301:1332::1]
2 4 ms 4 ms 3 ms 2a01-036c-1301-1332-d4b0-8012-7653-3755.pool6.digikabel.hu [2a01:36c:1301:1332:d4b0:8012:7653:3755]
3 * * * Request timed out.
És eddig tart az IPv6... :/

( ladanyid | 2016. 11. 15., k – 11:32 )

Én tegnap kapcsoltam be és működik. Valakinek van valamilyen új tapasztalata?

( uid_6201 v | 2016. 12. 03., szo – 10:13 )

Napra pontosan 1 éve van lehetőségünk a Digi hálózatán az IPv6 tapasztalatszerzéssel. :)

A 12 hónap alatt összegyűlt tapasztalatok:

1. működik, https://www.whatismyip.com a laptop IPv6-os címét írja.
2. A belső kapcsolatokhoz helyi címeket használok, így a belülről történő elérhetőségét nem érinti a publikus IP váltás.

$ ping 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.38 ms

3. a publikus IPv6 címek rendszeres megváltoztatásával (dinamikus IP) mégis jár néhány probléma, amire a korrekt megoldás még nincs meg.

a.) tűzfal - nem tudod a routerben egyszerűen megadni hogy az XY immáron publikus IPv6 című gépre akarod csak kinyitni az adott portot, hiszen a publikus címe a végberendezésnek változik.
b.) IP váltás után a benti eszközök sok-sok percen keresztül nem kommunikálnak kifelé, mert nem tudnak az IP cím váltásról és így még hosszú ideig a régi IPv6 címükkel próbálnak kommunikálni.

Erre a két problémára van esetleg valami korrekt megoldás, ami elkerülte a figyelmemet, vagy csak barkács-módszer létezik?
Egyáltalán mi szükség arra, hogy a jövőben is változtassák az IPv6-os címet?

"DeprecatePrefix on" nem segít?

> Egyáltalán mi szükség arra, hogy a jövőben is változtassák az IPv6-os címet?

Nevezzük üzletpolitikai okokból történő sz.patásnak. Főként, hogy az üzleti, fix IP cím feláras csomagokhoz is csak IPv4 címből adnak fixet, az IPv6 prefix ott is dinamikus.

+1
Azért használom belül én is v4-et, mert a v6 változik, és így kb se fixen, se dns-sel nem lehet rá hivatkozni.

Az IP váltásos problémával én is találkoztam, ezzel meg a router advertisement időköze miatt van fennakadás, illetve amiatt, hogy a dhcp kliens 7 napra kapja a tartományt... Nekem mikrotikem van, én úgy oldottam meg, scheduler-ből egy script figyeli a saját v6-os címét, és ha változik, akkor nyom egy dhcp disable-enable-t. Az ra intervalt meg lentebb kell venni. Mikrotik-en azt hiszem 10 perc a defaultja.
--
"Sose a gép a hülye."

( djsilas | 2017. 03. 28., k – 22:51 )

Ébren lévő Digis Hupperek: nálatok van IPv6? :) :(

tracert google.com

Útvonal követése a következőhöz: google.com [2a00:1450:400d:807::200e]
legfeljebb 30 ugrással:

1 <1 ms 1 ms <1 ms 2a01-036d-1300-455b-0000-0000-0000-0001.pool6.digikabel.hu [2a01:36d:1300:455b::1]
2 8 ms 6 ms 6 ms 2a01-036c-1300-455b-116f-4d4d-9554-b1d9.pool6.digikabel.hu [2a01:36c:1300:455b:116f:4d4d:9554:b1d9]
3 * * * A kérésre nem érkezett válasz a határidőn belül.
4 * * * A kérésre nem érkezett válasz a határidőn belül.
5 * * * A kérésre nem érkezett válasz a határidőn belül.
6 * * * A kérésre nem érkezett válasz a határidőn belül.
7 * * * A kérésre nem érkezett válasz a határidőn belül.
8 * * * A kérésre nem érkezett válasz a határidőn belül.
9 * * * A kérésre nem érkezett válasz a határidőn belül.
10 * * * A kérésre nem érkezett válasz a határidőn belül.

Nálam van:

$ ping6 google.hu
PING google.hu(bud02s21-in-x03.1e100.net (2a00:1450:400d:806::2003)) 56 data bytes
64 bytes from bud02s21-in-x03.1e100.net (2a00:1450:400d:806::2003): icmp_seq=1 ttl=54 time=2.61 ms
64 bytes from bud02s21-in-x03.1e100.net (2a00:1450:400d:806::2003): icmp_seq=2 ttl=54 time=1.85 ms
64 bytes from bud02s21-in-x03.1e100.net (2a00:1450:400d:806::2003): icmp_seq=3 ttl=54 time=1.36 ms

$ ping6 hup.hu
PING hup.hu(hup.hu (2a01:6ee0:1::bad:c0de:113)) 56 data bytes
64 bytes from hup.hu (2a01:6ee0:1::bad:c0de:113): icmp_seq=1 ttl=56 time=2.93 ms
64 bytes from hup.hu (2a01:6ee0:1::bad:c0de:113): icmp_seq=2 ttl=56 time=2.91 ms
64 bytes from hup.hu (2a01:6ee0:1::bad:c0de:113): icmp_seq=3 ttl=56 time=3.06 ms