Digi IPv6 elindult

 ( spymorass | 2015. december 3., csütörtök - 12:19 )

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

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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.

Azt a digitől kéne megtudnod, milyen formában kapod meg, és attól függően tudod majd beállítani a routeredben.

Fedora 22, Thinkpad x220

"ppp-n ip6cp vel kapsz ip-t a linkre, es utana van PD dhcpv6-al"

:D

autentikus forrasbol ideztem :-)

Közben megcsinálták a netet, és próbálkoztam vele. Azt írják, hogy dual-stack-ben üzemel. Viszont PPPoE-n nem kapok IPv6 címet, az option 'ipv6' '1' be van állítva a kapcsolatra. Valaki tud megoldást rá?

Én is idáig jutottam sajnos. Nincs v6-os cím a pppoe alatt.

Allitolag nem minden teruleten kapcsoltak be meg,fokozatosan lesz elerheto mindehol...

Ez hasznos infó.
Köszi! Akkor türelem!
Szerk: Nálunk már elvileg elérhető, de nem kapok címet :(

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

Probaltad mar ujrainditani?

Naná! =)

sub

sub

+1

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

Címed már van vagy csak pingelsz?:)

Ez jogos kérdés, van, kapott vmit a gép. Aztán a fene tudja, h az jó-e, túl sokat ipv6-al még sajna nem volt dolgom. De érdekel a dolog. :)

feliratkozom

Működik otthon vagy két éve Mikrotikkel.

http://www.techtorials.ro/2012/06/28/mikrotik-routeros-ipv6/
vagy valami hasonló alapján lőttem be, megnézem ma.

Romániában már évek óta van IPv6, itt most a magyar Digi-ről van szó.

Ami miben is különbözhet technikailag? Ugyanaz a mese, itt is ott is PPPoE.

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

Tul sok tűzfalazás nem kell, kb tiltasz mindent befele és kész :D

Fedora 22, Thinkpad x220

Valószínűleg firmware függő egyéb SOHO routeren. Újabb routerekben lehet bekapcsolták, viszont érdemes megvizsgálni hogy a firewall-nál mit állítottak be.

Nincs semmi bonyolult a tűzfalba, annyi hogy nem inputra kell tenni a szabalyokat, meg dst-nat-ot, hanem simán forwardra.
--
The Community ENTerprise Operating System

Kellett valamit állítani a routeren?

sub.

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

subscribe

+1;

+1

+

+1

Juhúú!

Statisztika képpen megírhatnák, hogy hányan hányszor érdeklődtek emiatt....
--
The Community ENTerprise Operating System

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.

Érdeklődés biztos hogy volt és van, máshol is.
Csak azért kérdezem, mert mióta digi van, én is kb. félévente megkérdeztem őket. :)
--
The Community ENTerprise Operating System

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?

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

/64-et allokál a Digi, de miért kéne ezt állítani és hol?

A tomato firmware-ben van ilyen opció és nem akartam rosszul beállítani ezért kérdeztem.

Pontosabban a "DHCPv6 with Prefix Delegation" alatt van ez az opció.

Ezt írja a http://digi.hu/ipv6 :

IPv6 tartományok

kliens - 2a01:36c::/32
delegated - 2a01:36d::/32

Ez a global pool lesz, innen vagdossa ki a /64-eket amit allokál a belső hálózatodnak.

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

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

Most néztem apámnál, gyári tp-link fw-vel, neki se jön semmi, nálam se indult még be a 15-ben owrt-vel. Én visszatettem a tunnelt addigis.

Koszonom, akkor meg "turelmesen" varok :)

Megy az IPv6 itt is. Csak tunneles címet kapok, 2002:* kezdetűt, nem olyat mint ami a http://digi.hu/ipv6 alatt van.

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

Eddig nekem is megy, de a LANon (wifi) logo klienseknek mar nem adja tovabb dhcp-n az infot, azok tovabbra is fe80::-juk van csak.
Ezt hogyan lehet beallitani? Koszi!

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

Nekem a WRT54GL-en abszolút nem megy... Próbálkozik, nem is kapcsolódik a PPPoE, majd egyszer csak újraindul.
Ehhez már kevés a broadcom 200Mhz. :(
Van az irodába egy kukázott mikrotik, megpróbálom majd azzal.
--
The Community ENTerprise Operating System

É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-MIPSR1-132-MiniIPv6.zip

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.

Egy 200-as downlink azért így is sok lesz neki...

+1

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 elég neked 18,446,744,073,709,551,616 db IP?

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.

Technikalag teljesen valid, amit írsz. Alternatívaként felmerülhet DHCPv6 SLAAC helyett, és akkor lehet a /64-et szabdalni.
DE az android - szinte egyedüliként - nem támogatja a DHCPv6-ot Wifi hálózatok esetén (sz*rjon sünt a Google). :(

> DE az android - szinte egyedüliként - nem támogatja a DHCPv6-ot Wifi hálózatok esetén

Az a sok kínai kvarcjáték valószínűleg ennyit érdemel :))

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-13-0-t3265044
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.

> 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á!

Gondolom, SLAAC-vel kapta. Arról volt szó, hogy DHCPv6-ot nem tud az Android.

Oké, de nem értem, hogy ki beszélt neked SLAAC-ről? :) Meg ki adta ezt az ajánlást neked? :))

RFC 3177
RFC 6177

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

Kösz, mindez nagyszerű, de akkor most válaszolj a kérdésemre is ;)

Egyelőre még annak örülök, hogy már-már működget.
Most az IPv6 alapértelmezett tűzfallal kell megküzdenem, mert látszik hogy OpenWRT-15.05 esetén az fog meg.

Szóval szépen sorjában. Még én sem tudom a választ, de szerintem jövő hétre már tudni fogjuk.

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.

Szia,

Kérhetnénk egy tcpdump pcap-et a sikeres dhcpv6 forgalmazásról? Sajnos mi hiába próbáljuk, a válasz minden esetben: "(server-ID hwaddr/time type 1 time 478104455 000000000000) (status-code no prefixes) (DNS-server 2a01:368:a::2 2a01:368:a::1))"

Köszönjük.

Szia,

Milyen dhcpv6 kliens es milyen beallitasokkal? pcap-et tudsz mutatni?

Megirnad kerlek az /etc/config/dhcp 'lan' reszet? Koszi!

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?

Ha az upstream szolgáltató visszavonja a globális prefixedet (leszakad a WAN kapcsolatod, stb.) attól még tudsz helyi hálózaton ULA címekkel routeolni.

Vannak ULA prefix generátorok, gyárts magadnak egy prefixet.

openwrt gyartott egy ULA prefixet, nem gond.
A bajom az, hogy ebbol megy ki egy subnet dhcp-n a klienseknek, nem pedig a globalis tartomanybol. Lenyegeben natolas tortenik, azaz nem tortenik, mert a kliensek nem latnak ki a netre. Vagy ez igy jo es mindig route-olni kell kifele?

> 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 barmelyik megoldas megfelel, csak mukodjon :)
Legyen akkor a SLAAC. Erre tudnal openwrt /etc/config/{network,dhcp} peldat irni (nyilvan csak a relevans sorokat)? Koszi!
Jelenleg ott tartok, hogy wan oldalon kapok ipv6-os subnetet (/64). Es openwrt-bol megy kifele jol az ipv6.

Sajnos nincs működő OpenWRT-s konfigom, OpenWRT-s dobozokat csak WiFi accesspointnak használok, routing funkcionalitás nélkül.

Cisco, Linux (radvd, isc-dhcp) illetőleg NetBSD (rtadvd, isc-dhcp) van kéznél. Na, meg Mikrotik, de azon meg nem használok IPv6-ot.

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

Openwrt CC-t hasznalok, igy ezzel sokra nem megyek. De azert koszi!

Ha nem titok mi volt az a dhcpv6 kliens, ami nem tudott egyszerre több címdelegálót fogadni?

én úgy látom, hogy némelyik reconnect után változik a prefix. és amúgy is 7 nap lease van.

én úgy látom, hogy némelyik reconnect után változik a prefix. és amúgy is 7 nap lease van.

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.

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?

1.) változik

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.

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.

A válasz a problémádra: "Tomato by Shibby"
Innen: http://tomato.groov.pl/download/K26ARM/132/
vadászd le ezt: tomato-RT-N18U-ARM--132-AIO-64K.zip
és rakd fel, jól:)


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

Nekem is ilyen routerem van, neked nem volt problémád cpu load-al ? Elvileg NOSMP verzió valami ilyesmit javít.

Szerk: megkérdezhetem tomato-ban hogy állítottad be ipv6 ot ?
köszi

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)

Igen, én is ezt tapasztaltam a CPU load-nál, biztos csak a mérés rossz. IPv6-al sajnos nekem is ugyanaz a tapasztalatom mint neked :( Ha sikerül majd beírjuk és akkor a másik embernek még marad haja :D

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)

+k*rv@sok! Ez még azóta is probléma!

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.

Nincs is sok értelme, ha van mögötte "infrastruktúra".
Tomato és társai két dologra jók: hibás fw, amit biztosan nem javít a gyártó vagy ha nincs szervered, de szükséged lenne saját log szerverre, dns-re, radius-ra stb. Esetleg egyedi tűzfalszabályokra.

eddig nekem se müködött AC-56U routeren de mostmár valamit csinált a digi mert csont nélkül megy: IPv6 Connection Type: Native with DHCP-PD beállítással

Tippre az itt említett DUID követeleményeket szüntették meg, de valaki erősítse meg. (nekem nincs Digi-m)

valami más lesz, tegnap még elég sokaknak nem ment, mára meg már szinte mindenkinek megy (többek közt nekem is, és nálam jó volt a DUID pl.)

én semmi DUID-os varázslást nem csináltam, és ment.

É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.

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?

Ugyanilyen routerrel ugyanez a probléma. Vagy v4 vagy v6. A kettőt egyszerre még nem sikerült belőni.

És tényleg, ha csak v6-ot kérek működik. Valószínűleg ez a router egy-egy külön PPPoE kapcsolatot akar nyitni a v4-nek és a v6-nak, ezt pedig a DIGI nem engedni. Valószínűleg frissítem a routert DD-WRT-re (kár hogy openwrt nincs rá)

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

PPPoE, és az így létrejött PPP interfészre (aminek van már fe80:: link local-ja) DHCPv6?
Legalábbis OpenWRT alatt így jön létre a kapcsolat és így kap a pppoe-wan interfész IPv6-os global címet (2a01:36c:...).

ugyan ez érdekelne xviii kerületre:)


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

X. ker tegnap délután óta működik.
http://prntscr.com/9bqcfh

igazán kirakhattak volna egy listát, hol és mikor kapcsolják be:D A dhcpc6 tcpdump-al kap választ a request-re, viszont csak a v6-os névszerverek adatait kapom.


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

XVII. ker. FTTH - Mikrotik nem igazán akar ipv6 címet kapni. Van akinek sikerült errefelé?

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

Nem. pfSense sem kap IPv6 címet.

Köszönöm a visszajelzést, akkor még várok :)

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

Ahogy nézem, nem hálózatonként hanem ppp accountonként kapcsolják be folyamatosan. Másik végponton azonos házban már megy, nálam még nem


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

Ha nalad nem mukodik valoszinueg a te eszkozod miatt nem mukodik, nem pppoe loginhez kotott az ipv6.

"nem loginhoz van allitva, ha a csatlakozas felepulesenel ker a kliens v6-ot akkor kap"

Mivel mindket eszkozt en adminisztralom es mindket eszkoz tokeletesen megegyezik, nala megy, nalam nem, a dhcp6c viszont csak ipv6-os nevszervereket ad vissza


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

sajnos én is ezt tudom megerősíteni:
- szomszéd házsorban ~2 évvel régebbi szerződés (-> régebbeb létrehozott ügyfél/radius login), működik
- nálam csak v6-os dns opció jön, prefix delegálás nem :(

Békéscsabán is elindult.

http://img2.ipv6-test.com/speedtest/result/2015/12/08/5ebee87f53c202c827d372d95f7c03f7.png

Belső hálón lévő gépek is rendesen mennek IPv6-tal.

Aztán kapott a Mikrotik pár sort:
/ipv6 firewall filter
add action=drop chain=input
add action=drop chain=forward
add action=drop chain=output

: )))

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

Nekem sajnos nem kap v6-ot a router :(

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

Nekem csak ma indult el.

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....

Idézet:
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.

Egyetértünk, a DUID szerintem is baromság, de ettől még a Digi szabály nem követése okozta a fenti a problémát.

Erre amúgy odafönt is rájöttek, ezért van az RFC 6939, amiben van link-layer mac opció.

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*/

> csak a ping-ig jutok. Oldalak nem toltenek be.

ha ping van, akkor a hangszórókábelt már megnyerted, és közel jársz a hangszóróhoz.

ipv6 tcp adjust-mss 1432

öööö... OpenWRT? akkor:

ip6tables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Koszonom jelenleg sikerult szarra kattintgatni a gepemet igy most elobb azt hegeszthetem meg :D

Kene egy pi sandboxnak. Erre (is) tokeletesen jo lenne.

Javitanek. ping6 addig van, hogy mutatja:

"ping6 hup.hu
PING hup.hu(2001:4c48:2:a33e::6) 56 data bytes"

szerk: A lan interface-rol lemaradt a relay mode. Amint ezt beallitottam egybol eszheztert. Koszonom a segitsegeteket!

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...

nekem wan6-nal az ifname '@wan' es az utolso 2 sor nincs bent. igy kapok ipv6 cimet. + 15-os openwrt

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)

nagyon gyerekcipoben jarok v6-al. Sajnos nem mond sokat a logbejegyzes. Azt tudom csak megosztani ahogy nalam jelenleg "megy"

A logból az látszik, hogy kimegy tőled az első DHCPv6 üzenet, de válasz nincs rá. Ahogy lent írták, ellenőrizni kellene a tűzfalbeállításokat.

Szerk: nyilván eggyel feljebb.

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

Akinek megy az IPv6 milyen régi az előfizetése?

Nekem nagyjából 3-4 hónapos, még nincs ipv6

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

Kb 6-7 hónapos, 100/50-es csomag.
Szerintem inkább terület függő a dolog.

http://ipv6.co.hu/tag/digi/ - végülis azt írták, hogy lesznek területek, amit ezen a héten engedélyeznek csak.

Soma is csak a hivatalos infót osztotta meg, a gyakorlat viszont mást mutat

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.

Itt még mindig nem megy, próbáltam ezt a megoldást többször is, nem ment, Mikrotikkel sem működik. Úgyhogy egyelőre nálam szerintem még nem kapcsolták be. IX. kerület.

Próbáld meg esetleg így:
config interface 'wan6'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'try'
option ifname '@wan'
option clientid '00:03:00:01:xx:xx:xx:xx:xx:xx'

Az xx:xx -ek helyére kerüljön az internetre néző interfészed mac címe.

Beírtam a clientid-t. Ugyanaz történik:
odhcp6c[22532]: (re)starting transaction on eth0.2
Command failed: Not found
odhcp6c[22532]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0)

Van ilyen benne default:

config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fe80::/10'
option src_port '547'
option dest_ip 'fe80::/10'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'

Nézd meg, hogy engedélyezve van-e (webes felületen pipa mellette)

Megnéztem még régebben, amikor olvastam itt a topicban azt a rule-t. Volt pipa mellette, azért megnéztem újra, van pipa. =)

option src_port '547'

Ezt vedd ki, és úgy próbáld!

Ugyanaz a jelenség, nem változott semmi.

Megérkezett végre ide is. Jöhet a beállítása. =)

IX. kerületben nekem sem megy még.

a het vegeig mindenhol engedelyezve lesz

kiveve kabelmodemes teruletek - lasd pl IX keruletben nekem ;-)

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. :)

Ez alapján sikerült, nekem is megjött az ipv6 címem:) 1031

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é.

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?

;)

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-for-home-users-are-evil/

Annyi előnye azért van, hogy a P2P kapcsolatok jobban működnek (torrent, VoIP), ha van publikus IP címed.

Az, hogy nem fix cím szerintem egyszerű üzleti döntés.

Torrentet nalam nem befolyasolja upnp miatt. VOIP-ot szinten nem befolyasolja, mert egyik szolgaltatom sem enged direkt RTP kapcsolatot, hanem a szolgaltaton keresztul megy a forgalom.

A post utolso sora:
"Update Sep 2014: I’ve rewritten a lot of outdated and poorly written crap in this post."

egyebkent milyen elonnyel jarna szamodra a fix v6 tartomany?
Maskepp hasznalnad?

Peldaul nem vpneznek, hanem ipsecet hasznalnek a dvr es a szinten digi teruleten levo kliens kozott.

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)

LAN oldalon mit szeretnél?

1.) Kizárólag SLAAC-t, és a DNS és egyebeket kézzel konfigurálod a kliensen,
2.) vagy SLAAC + stateless DHCPv6-ot a DNS-hez,
3.) vagy nem szeretnél SLAAC-t, hanem mindenre stateful DHCPv6-ot szeretnél?

A konfigod alapján én a 2.-ra tippelek.

Nem szeretnék kézzel állítani a klienseken semmit se...
Meg miért nem látom, mit delegál a digi? Elviekben a 'show ipv6 interfaces dialer1' outputjában szerepelnie kellene...

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

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?

ndp-re nincs szükséged. Így kell hogy kinézzen:

/etc/config/dhcp:


config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '1h'
option ra 'server'
option dhcpv6 'server'

Köszi, próbálkoztam már ezzel a configgal, akkor nem ment. Reboot segített.
Androidnál ez az app segítségével megy (root kell hozzá): https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client

Nem kellene semmi trükközés az androidhoz, ezért van az 'ra' server módban, ilyenkor slaac segítségével beállítják az eszközök magukat.

Valóban, bezavart, hogy a wifi beállításoknál csak a IPv4-es címet írja ki.

Nem is kell trükközni, a gyári rom sokszor nem up to date, ha van a telefonra CM13 érdemes azzal próbálkozni, nálam kapott v6 címet a Redmi 1S CM13 alatt. A telefonról/állapot menüben írja ki.

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.

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"

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'

A clientid-t kihagytam, de a többit beírtam és most működik a dolog :)

Koszi! Most mar nekem is mukodik a lan oldalon is.
A gond az volt, hogy hiaba allitok be mindent LuCin, egy reboot kell neki, hogy minden valtoztatas ervenyre keruljon.
A clientid-t en is kihagytam, anelkul is megy...

Nem kell reboot, a webes felületen apply (interfész, tűzfal), aztán újrarúgja, amit kell.

Mar napokkal korabban beallitottam igy -> Save&Apply -> kliens oldalon dhcp renew (szerintem meg wifi ki-bekapcs is volt), es nem ment.
Ma reggel ujra szantam ra idot, elotte raneztem, tovabbra se volt lanon ipv6 cimem -> router reboot -> es lett :)

Köszi, megy a dolog, szintén clientid nélkül.

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

IPv6-on csak a küldő törheti a csomagot, amit az ICMP üzenetek alapját tud megtenni. Ha nem tudja, hogy törni kell, akkor elküldi max MTU-val de nyilván el lesznek dobva azon az eszközön, ahol annál kisebb az MTU.

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.

Sok fórumon nagy vita van a hwnat hiányáról, de szerintem ha nincs nagyon gyors neted, akkor lehet élni nélküle.
Gyári TPLink firmware-ben is van Hwnat, de mégse szívesen váltanék rá vissza.

100 Mbit netet a HWnat kb. 92-93 megabitig tud terhelni, míg az OpenWrt kb. 42-45 megabitig....100/100-as netem van.

Szintén 100/100-as neten owrt-vel (tp-link WDR4300) lazán jön a torrent 100-al. És az owrt még nem tartalmazza a hwnatot.
http://www.speedtest.net/my-result/4924373777

Nem tudom mennyi a CPU igénye a routing-nak de a mai kb 700Mhz-es routerek már csak elbírnak 100/100 Mbit-tel dedikált chip nélkül is.

IPv6-tal ugye megszűnik az igény a NAT-ra. Ez vajon csökkenti majd a CPU leterheltséget mondjuk kemény torrentezés közben?

Attól függ. Ha PPPoE-n keresztül jön a net, akkor annak a CPU terheléséhez képest úgyis semmi a NAT terhelés.

Mesélj, miért gondolod ezt?

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.

Nos top-al lestem a cpu használatot egy speedtest közben, és 2-5% közötti emelkedést észleltem csak az alam 15%-os kihasználtsághoz. A speedtest magában futott. Tehát a pppoe nem terhelte agyon a vasat.

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.

+1, bele sem gondoltam eddig hogy az escape-szekvencia ilyen gondot okoz, érdekes tudni.

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-conntrack-kernel-module-in-centos-5-3-without-recompilin

ip6tables --> ip6tables v1.4.21: Couldn't load target `NOTRACK'.

Addig is segítségül a contrack tábla:
cat /proc/net/nf_conntrack | grep ipv6 | wc -l

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.

Idézet:
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

Köszi! Erre nem is gondoltam, az RB850Gx2-vel fogok mérni "natúr" PPPoE-t :-)

Köszi, mértem is vele!

pppoe+IPv6-ra is van ötleted?

Gugli barátunknak van egy pár ötlete, én magam sose próbáltam.

Van hozza beta firmware... mert a gyari nem tud dual-stacket egy ppp session-on
http://prohardver.hu/tema/digi_lan_pppoe/hsz_39093-39093.html

Kösz, de beta firmwarrel nem szarakodok. Sokszor home office van, nem lenne jó, ha cask az IPv6 miatt kockáztatnám, hogy egyszer csak megadja magát a router, amikor kell a net.

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

Fasza, pont Cisco-hoz nincs... :)
Küzdök, mint malac a jégen, egyelőre a jég a befutó :)

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.

dynv6.com tudja az IPV6-ot is, de még nem tudtam mivel kipróbálni. A kacsa tényleg nemeszik 6-ot.

mydns.jp nekem megy.

Én nem kerestem még dyndns szolgáltatót, helyette egyelőre írtam egy egysoros PHP weboldalt egyik webszerverre, ahova 10 percenként feljelentkezik wget segítségével az otthoni SBC és az IP címe így bekerül egy txt fájlba.
Innentől tudom, mi az otthoni IPv6 cím.

Szekercével fogpiszkálót...

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.

Amúgy minek címzik meg a PPPoE linket? Link-local címek tökéletesen alkalmasak erre. Nekem így működik most, bár csak azért mert a Mikrotik (még) nem tudja fogadni egyszerre a címet és a prefixet.

Én arra tippelek, hogy a CPE-nek (home router), tudnia kell ICMP üzeneteket küldeni a világ felé (pl. PMTUD miatt).

Szerk: közben rájöttem, hogy ezt küldheti a belső publikus címről is.

Single host esetén teljesen felesleges DHCPv6 IA_NA / IA_PD kérést csinálni.

Engem inkább az érdekel, hogy mi a bús répáért nem képesek legalább /56-ot delegálni. Címük van elég...

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.

Jé, ez szép, ezek szerint implementálták a Carrier Grade NAT-ot.

Felhívod őket és visszakéred tőlük a publikus IP-t a NAT-olás helyett. Én szeptemberben futottam bele.

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...

Sehol semmi... :(
Békéscsaba

Lecseréltem az állítólag IPv6 képes TP-Linkem gyári firmwarét OpenWRT-re és láss csodát... különösebb mókolás nélkül jön is az IPv6 natívan...

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?

Hallgatsz a router advertisementekre?

(sysctl net.ipv6.conf.ppp0.autoconf és társai)

Egyébként, DHCPv6 IA_NA-val is tudsz címet kérni a pppoe linkre, ha a router advertisement nem oldható meg.

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.

Gondolom, ha elegen kérik, akkor változtatnak ezen.

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?

http://s13.postimg.org/yf2u8c6if/Shutter_2016_01_05_001.png

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

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-attackers-start-targeting-ipv6-networks.html

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...

A héten a Linuxakadémiás képzésen valaki említette, hogy kb. idén november-december környékére várható a fix IPv6. Aztán meg ugye majd látjuk...

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.

Ja, hogy jaa... Kösz!

--
openSUSE 13.1 x86_64

De lehet, csak akkor DHCP-t kell használni, a SLAAC nem működik.

Ezért lepődtem meg, mert én DHCP és fix címzést használok. Bár nem is bontogattam fel a tartományom.
A fentebb kapott linkről amúgy eljutottam arra, hogy autoconfigon nem úgy megy ám...

--
openSUSE 13.1 x86_64

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.

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.

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

Köszi, elsiklottam felette.

Már szidtam is a kurva anyjukat emiatt. Ha már fizetős a fix ip, meg van v6, mi a fasz olyan nehéz egy fix v6-ban?... Gondolom a Román anyacégnél nincs ilyen cigánykodás az IP-kkel...

--
openSUSE 13.1 x86_64

"mi a fasz olyan nehéz egy fix v6-ban"

Például egyik dolog: hardvereszköz hiányában az IPv6-os vonal DDoS védelme.
(IPv4-re megoldott)

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

Annak idején lehet.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Kicsit konstruktívabb reakció? Milyen megoldás van, amit nem lehet v6-ra betolni?

--
openSUSE 13.1 x86_64

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?

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... :/

worksforme:

$ telnet google.com 80
Trying 2a00:1450:400d:807::200e...
Connected to google.com.
Escape character is '^]'.

és tudom pingelni a Te címed. Traceroute szerint Békéscsaba felé megy.

Köszi!

Szerverről én is meg tudtam pingelni magamat, de visszafele már nem megy és vhol Diginél akad el... :/

Bp.-ről megy, test-ipv6.com 10/10

Nálam 0/10. :) PPPoeconf-ot nem tudom belőni, nem lelek hozzá normális howtot, a man-t meg nem fogom bogarászni, ráér a dolog.

Openwrt-t használok, az itt leírtak is segítettek abban, hogy menjen - nem nagy varázslat egyébként :)

Nálam egy ubuntu a router. :) Nyilván meg lehetne csinálni, de nincs nálam prioritása.

Úgy látszik dolgoznak valamin, mert én most pl. nem kapok IPv6 címet, pedig ugyanezzel a konfiggal egész eddig rendben volt.

Úgy látszik dolgoznak valamin, mert én most pl. nem kapok IPv6 címet, pedig ugyanezzel a konfiggal egész eddig rendben volt.

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

Úgy látszik én ds-lite-ra kerültem diginél, mivel kaptam publikus v6-os címet, de cserébe a v4-es címem 100.66-tal kezdődik, amit az ISP-k használhatnak carrier grade NAT-ra.

Nálunk mióta bekötötték rendes publikus IPv4 cím van. Pedig kb. 2 hónapja van. Mondjuk ez családi ház és közvetlen jön be az optika.

Dupla - törölve

Az ügyfélszolgálaton kérni kell a publikus IP-t (saját server, nas, kamera, stb. indokkal) és visszakapcsolják.

Köszi, el is intéztem az ügyfélszolgálatos hívást, elvileg 72 órán belül beállítják és kapok róla egy értesítő SMS-t.

SMS-t nem biztos, hogy kapsz róla. (Nekem legalábbis annó nem jött.) Illetve a telefon után pár órával érdemes a routeren egy PPPoE újracsatlakozást kérni.

Én kaptam SMS-t ma 8:34-kor, s egy pppoe reconnect után valóban vissza is kaptam a publikus címem. Néha megdöbbenek azon, hogy a dolgok mennyire simán is tudnak menni. :)

Diginél nincs DS-Lite. Dual-stack lesz az, csak a v4-es címed CGN mögé került. Kérésre visszakapod a nyilvánosat.

Igen, sorry, hülyeséget írtam. Túl sokat olvastam UPC-témában és rám ragadt...

Nekem is most lett digi, az ONT ad IPv6 címet (/64), a mögött lévő OpenWrt-s router meg is kapja, de nem oszt, csak fdc... -s címet. Akár hybrid/server/relay a DHCPv6, akármi. Mit kell tennem, hogy a LAN is kapjon publikus IPv6 címet?

Az ONT bridge módban van, és te hívod be a PPPoE kapcsolatot az OpenWrt dobozról?

Sajna nem, router módban üzemel, és a digi nem a default jelszavakkal adja...

Ügyfélszolgálati kérésre átteszik bridge módba.

Köszi, megpróbálom.

Mi az az ONT?
szerk: közben googleval megtaláltam.
--
"Sose a gép a hülye."

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.

Valahol olvastam régebben hogy a load-balancing miatt nem megoldott rendesen a statikus IPv6 tartományok ruteolása.

Ettől persze még én is a normális szabványos megoldás fix /56-ot szeretnék dinamikus /64 helyett...

+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."

Bentre van link-local cím, ami fix. miért nem használod azt?

1. Egynél több interfacenél szívás
2. Split-brain DNS kell hozza
3. Egy csomó program by design nem támogatja

Ezen felül a tűzfal problémát nem oldja meg a local cím.

Nekem semmi probléma a prefix váltással. Újracsatlakoztam routeren, Windows egyből felvette az új címeket, és minden megy tovább.

Bejövőhöz nem egyszerűbb kinyitni azt az egy portot?

É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