Het grote IPv6 topic

[Jaap-Jan]

Gelukkig is Caiway zoveel verder. Ze geven zelfs al de tip om een tunnel broker te gebruiken.

En ze zijn nog maar 4 maanden aan het inventariseren wat er moet gebeuren aan hun eigen infrastructuur en de CPE's.

[CAPSLOCK2000]

Als CAPSLOCK2000 niet naar Zeeland wil verhuizen dan moet de glasvezel maar naar CAPSLOCK2000 toe komen. En dat vond Reggefiber ook. Ik ben naar XS4All verhuisd. Omdat ik nu niet langer hoef te betalen voor een TV waar ik toch niet naar kijk ben ik netto zelfs goedkoper uit voor veel meer bandbreedte.

[Snow_King]

Roetzen schreef op donderdag 12 maart 2015 @ 16:50:

En wie is dat?

Xenosite. Ze leverden een SDSL verbinding voor ons op kantoor. Daar gaat de VOIP over, maar die wil ik naar IPv6, gaat nog dit jaar gebeuren: SIP telefoons met IPv6 en TLS ondersteuning

Roetzen schreef op donderdag 12 maart 2015 @ 16:50:
Wat ik me wat betreft DS-lite afvraag is of het opgelegd pandoer is dat je er nooit een publiek IPv4 adres bij krijgt. Het verschil tussen full DS en DS-lite is dat bij DS-lite er alleen IPv6 pakketjes over de lijn naar de ISP gaan en IPv4 pakketjes via een 4in6 tunnel naar de ISP gaan. Dat is volgens mij de essentie van DS-lite. Technisch gesproken hoeft het niet samen te gaan met CGNAT. Toch?

Dat hoeft denk ik niet. Maar de DS-Lite verhalen uit Duitsland klinken wel heel erg als CGNAT in de oren.

CyBeR schreef op donderdag 12 maart 2015 @ 23:20:
Moet wel zo ongeveer Zeeland of regio Delft zijn want anders heb je alsnog met ze te maken

Laat ZeelandNet nu native IPv6 leveren

[ik222]

DS-Lite gaat wel degelijke ook technisch altijd samen CGN. Immers bij DS-Lite gaat de CPE private IPv4 adressen aan de binnenkant uitgeven. En in het DS-Lite protocol is vastgelegd dat de CPE zelf geen NAT doet voor IPv4 maar dat deze alleen maar de IPv4 pakketjes encapsulate in IPv6 pakketten en ze dan naar buiten stuurt. Dat betekent dus dat er altijd bij de provider dan CGN gedaan moet worden om dit te laten werken.

De enige manier om DS-Lite te deployen zonder CGN is dus de CPE aan de binnenkant globaal unieke IPv4 adressen laten uitdelen. Los van dat dit niet in het protocol staat is het gebrek aan globaal unieke IPv4 adressen nu juist de reden om naar IPv6 te gaan. DS-Lite zonder CGN gaat hem dus niet worden

Maar goed er is ook geen reden waarom je DS-Lite zou uitrollen als je geen CGN wilt doen. Immers zolang je als ISP voor elke klant een IPv4 adres hebt kun je gewoon dualstack uitrollen.

[ Voor 12% gewijzigd door ik222 op 13-03-2015 08:49 ]

[tweegroenethee]

Snow_King schreef op vrijdag 13 maart 2015 @ 08:07:
Xenosite. Ze leverden een SDSL verbinding voor ons op kantoor. Daar gaat de VOIP over, maar die wil ik naar IPv6, gaat nog dit jaar gebeuren: SIP telefoons met IPv6 en TLS ondersteuning

Toevallig, ons kantoor zit ook bij Xenosite. Onlangs hebben we nog contact opgenomen met ze over IPv6, was nog niks over bekend. Goede reden voor opzegging volgens de manager. Als meerdere bedrijven dit doen met reden IPv6 gaan ze het hopelijk wat serieuzer nemen..

[Snow_King]

ik222 schreef op vrijdag 13 maart 2015 @ 08:45:
DS-Lite gaat wel degelijke ook technisch altijd samen CGN. Immers bij DS-Lite gaat de CPE private IPv4 adressen aan de binnenkant uitgeven. En in het DS-Lite protocol is vastgelegd dat de CPE zelf geen NAT doet voor IPv4 maar dat deze alleen maar de IPv4 pakketjes encapsulate in IPv6 pakketten en ze dan naar buiten stuurt. Dat betekent dus dat er altijd bij de provider dan CGN gedaan moet worden om dit te laten werken.

De enige manier om DS-Lite te deployen zonder CGN is dus de CPE aan de binnenkant globaal unieke IPv4 adressen laten uitdelen. Los van dat dit niet in het protocol staat is het gebrek aan globaal unieke IPv4 adressen nu juist de reden om naar IPv6 te gaan. DS-Lite zonder CGN gaat hem dus niet worden

Maar goed er is ook geen reden waarom je DS-Lite zou uitrollen als je geen CGN wilt doen. Immers zolang je als ISP voor elke klant een IPv4 adres hebt kun je gewoon dualstack uitrollen.

Maar wacht even, je gaat dus IPv4 IN IPv6 stoppen. Dat wordt mega veel MTU fragmentatie, want MTU Path Detection is bij IPv4 niet verplicht en wordt vaak niet gedaan.

Dan gaat je IPv4 "experience" nóg harder achteruit.

Daan87423 schreef op vrijdag 13 maart 2015 @ 09:46:
[...]

Toevallig, ons kantoor zit ook bij Xenosite. Onlangs hebben we nog contact opgenomen met ze over IPv6, was nog niks over bekend. Goede reden voor opzegging volgens de manager. Als meerdere bedrijven dit doen met reden IPv6 gaan ze het hopelijk wat serieuzer nemen..

Opzeggen dus Als maar genoeg mensen dat doen, dan wordt IPv6 vanzelf belangrijk voor ze.

[ik222]

Snow_King schreef op vrijdag 13 maart 2015 @ 10:08:
[...]

Maar wacht even, je gaat dus IPv4 IN IPv6 stoppen. Dat wordt mega veel MTU fragmentatie, want MTU Path Detection is bij IPv4 niet verplicht en wordt vaak niet gedaan.

Dan gaat je IPv4 "experience" nóg harder achteruit.

In principe klopt dat inderdaad. Alleen staat MSS Clamping op IPv4 bij bijna alle huis tuin en keuken routers sowieso standaard aan. Daardoor hebben eindgebruikers hier waarschijnlijk geen last van.

[Roetzen]

Snow_King schreef op vrijdag 13 maart 2015 @ 10:08:
[...]
Opzeggen dus Als maar genoeg mensen dat doen, dan wordt IPv6 vanzelf belangrijk voor ze.

Ik vrees dat aan "als genoeg mensen dat doen" niet snel voldaan zal worden. De doorsnee klant weet waarschijnlijk niet eens wat IPv6 is. Zolang als alles maar werkt is het best. En het probleem is dat bijna alles nog werkt zonder IPv6. Dat een paar nerds, zoals jij en ik opzeggen maakt denk ik toch niet heel veel indruk. Dat wordt gewoon geïncasseerd onder "je kan het niet iedereen naar de zin maken".

ik222 schreef op vrijdag 13 maart 2015 @ 08:45:
Maar goed er is ook geen reden waarom je DS-Lite zou uitrollen als je geen CGN wilt doen. Immers zolang je als ISP voor elke klant een IPv4 adres hebt kun je gewoon dualstack uitrollen.

Als ze nu DS-lite en dus CGNAT gaan doen omdat ze niet meer voor iedere klant een IPv4 adres hebben, dan hebben ze ons wel verkeerd ingelicht. Ze hebben immers allemaal om het hardst geroepen dat ze nog ruim genoeg IPv4 adressen hebben...

ik222 schreef op vrijdag 13 maart 2015 @ 11:05:
[...]

In principe klopt dat inderdaad. Alleen staat MSS Clamping op IPv4 bij bijna alle huis tuin en keuken routers sowieso standaard aan. Daardoor hebben eindgebruikers hier waarschijnlijk geen last van.

Plus dat die 4in6 tunnel alleen actief is op het stukje van de ISP naar de (door de ISP geleverde) CPE. Dus dat moet in de hand te houden zijn.

[ Voor 59% gewijzigd door Roetzen op 13-03-2015 14:28 ]

[ik222]

Roetzen schreef op vrijdag 13 maart 2015 @ 14:14:

Plus dat die 4in6 tunnel alleen actief is op het stukje van de ISP naar de (door de ISP geleverde) CPE. Dus dat moet in de hand te houden zijn.

Dat maakt niet uit, als ergens in het pad een MTU probleem is dan gaat het zonder correcte PMTU (of een workarround als mss clamping) gewoon fout.

Dat is ook wat je ziet bij 6rd of bij andere tunnels, ook daar is de tunnel alleen actief tussen de CPE en de ISP. Maar dat wil niet zeggen dat je dan geen MTU problemen hebt als ergens bijvoorbeeld bij een webhoster PMTU fout gaat (vanwege een te strakke ACL meestal) en je zelf mss clamping niet aan hebt staan.

[ Voor 5% gewijzigd door ik222 op 13-03-2015 17:02 ]

[CyBeR]

ik222 schreef op vrijdag 13 maart 2015 @ 17:00:
[...]

Dat maakt niet uit, als ergens in het pad een MTU probleem is dan gaat het zonder correcte PMTU (of een workarround als mss clamping) gewoon fout.

Dat is ook wat je ziet bij 6rd of bij andere tunnels, ook daar is de tunnel alleen actief tussen de CPE en de ISP. Maar dat wil niet zeggen dat je dan geen MTU problemen hebt als ergens bijvoorbeeld bij een webhoster PMTU fout gaat (vanwege een te strakke ACL meestal) en je zelf mss clamping niet aan hebt staan.

Meh, als die tunneldingen gewoon fragmenten dan kom je er wel. De performance zal alleen niet zijn om naar huis te schrijven.

[Verwijderd]

Zijn er nog mensen die software gebruiken die nog geen IPv6 ondersteund of niet voldoende? Ben benieuwd hoe groot de lijst is.

Zelf wacht ik met smart op:
- fail2ban
- ossec-hids
- mariadb-galera

Heb nu op diverse backend servers alleen IPv6 draaien en dat maakt het beheer wel aardig makkelijk(er). Minder DNS entries (ten opzichte van dualstack) minder iptables/firewalld regels, minder ACL's, monitoring en voor deze servers geen VPN nodig, alleen firewall regel voor mijn IPv6 subnetten thuis en op kantoor.

[Snow_King]

ik222 schreef op vrijdag 13 maart 2015 @ 17:00:
[...]
Dat is ook wat je ziet bij 6rd of bij andere tunnels, ook daar is de tunnel alleen actief tussen de CPE en de ISP. Maar dat wil niet zeggen dat je dan geen MTU problemen hebt als ergens bijvoorbeeld bij een webhoster PMTU fout gaat (vanwege een te strakke ACL meestal) en je zelf mss clamping niet aan hebt staan.

Bij 6rd, dus IPv6 is PMTU verplicht en werkt het vaak wel. Bij IPv4 niet, dus gaat het best vaak stuk. MTU fragmentatie is niet leuk als dat plaats vind.

Verwijderd schreef op zaterdag 14 maart 2015 @ 08:40:
Zijn er nog mensen die software gebruiken die nog geen IPv6 ondersteund of niet voldoende? Ben benieuwd hoe groot de lijst is.

Zelf wacht ik met smart op:
- fail2ban
- ossec-hids
- mariadb-galera

Heb nu op diverse backend servers alleen IPv6 draaien en dat maakt het beheer wel aardig makkelijk(er). Minder DNS entries (ten opzichte van dualstack) minder iptables/firewalld regels, minder ACL's, monitoring en voor deze servers geen VPN nodig, alleen firewall regel voor mijn IPv6 subnetten thuis en op kantoor.

Galera ben ik helemaal met je eens. Al kwam dit door SST meen ik. Waren wat work-arounds voor.

Verder kom ik weinig tegen wat geen IPv6 doet, alleen haat ik het wanneer je IPv6 moet enablen. Dat moet gewoon default zijn.

Ik probeer ook steeds meer infrastructuur IPv6-only op te bouwen.

Dual-Stack is gewoon veel werk en daarmee duur.

[ik222]

Snow_King schreef op zaterdag 14 maart 2015 @ 09:04:
[...]

Bij 6rd, dus IPv6 is PMTU verplicht en werkt het vaak wel. Bij IPv4 niet, dus gaat het best vaak stuk. MTU fragmentatie is niet leuk als dat plaats vind.

Dat klopt inderdaad maar ook al is het verplicht dan nog gaat het helaas regelmatig mis zoals we in dit topic ook al een paar keer gezien hebben. Ik denk dat dit vaak komt omdat mensen bij de dualstack implementatie simpelweg IPv4 ACL's naar IPv6 kopiëren zonder zich bijvoorbeeld de prominentere rol van ICMP bij IPv6 te realiseren.

Overigens poste ik bovenstaande als reactie op een bericht dat PMTU bij DS-Lite een beperkt probleem zou zijn omdat de tunnel IPv4 in IPv6 tunnel alleen actief is tussen de CPE en de ISP en dat je op dat stukje PMTU wel moet kunnen laten werken. Dat maakt dus niets uit aangezien je daarmee al de maximale MTU van het path naar beneden hebt gehaald. En als dan ergens in het pad (wat dus ook nog ver na de ISP kan zijn) PMTU niet toestaat dan heb je dus MTU fragmentatie.

[Verwijderd]

Snow_King schreef op zaterdag 14 maart 2015 @ 09:04:
[...]


Ik probeer ook steeds meer infrastructuur IPv6-only op te bouwen.

Dual-Stack is gewoon veel werk en daarmee duur.

Check ook dit https://twitter.com/toreanderson/status/575191375198683136 mocht je nog ipv4 afhankelijkheden hebben.

[Roetzen]

ik222 schreef op zaterdag 14 maart 2015 @ 09:17:
[...]
Overigens poste ik bovenstaande als reactie op een bericht dat PMTU bij DS-Lite een beperkt probleem zou zijn omdat de tunnel IPv4 in IPv6 tunnel alleen actief is tussen de CPE en de ISP en dat je op dat stukje PMTU wel moet kunnen laten werken. Dat maakt dus niets uit aangezien je daarmee al de maximale MTU van het path naar beneden hebt gehaald.

Mijn gedachtengang was niet dat je op dat stukje PMTU wel zou kunnen laten werken, maar dat je op dat stukje de MTU zo groot kan nemen, dat dàt nooit de bottleneck zal zijn.

[Raven]

Verwijderd schreef op zaterdag 14 maart 2015 @ 08:40:
Zijn er nog mensen die software gebruiken die nog geen IPv6 ondersteund of niet voldoende? Ben benieuwd hoe groot de lijst is.

Zelf wacht ik met smart op:
- fail2ban
- ossec-hids
- mariadb-galera

Heb nu op diverse backend servers alleen IPv6 draaien en dat maakt het beheer wel aardig makkelijk(er). Minder DNS entries (ten opzichte van dualstack) minder iptables/firewalld regels, minder ACL's, monitoring en voor deze servers geen VPN nodig, alleen firewall regel voor mijn IPv6 subnetten thuis en op kantoor.

eMule, die gebruik ik nog wel eens voor de wat lastiger te vinden dingen en die doet voor zover ik weet nog altijd niet aan IPv6.

[CAPSLOCK2000]

Nagios is bij ons een pijnpunt. Er zijn wel verschillende hacks en trucks om toch iets met IPv6 te doen maar geen daar van bevalt ons.

[databeestje]

Snow_King schreef op vrijdag 13 maart 2015 @ 08:07:
[...]
Xenosite. Ze leverden een SDSL verbinding voor ons op kantoor. Daar gaat de VOIP over, maar die wil ik naar IPv6, gaat nog dit jaar gebeuren: SIP telefoons met IPv6 en TLS ondersteuning

Snom? We hebben er een aantal op het werk waar IPv6 firmware voor beschikbaar is (Snom 720).

Als is 3CX misschien nog niet klaar, die moeten we nog inventariseren.

CAPSLOCK2000 schreef op zaterdag 14 maart 2015 @ 14:40:
Nagios is bij ons een pijnpunt. Er zijn wel verschillende hacks en trucks om toch iets met IPv6 te doen maar geen daar van bevalt ons.

We draaien op het werk al meer dan een jaar met Nagios met patches. Het werkt. Kon me niet druk genoeg maken om de exact implementatie. Sommige dingen wil ik expliciet op 6 testen, dus ervoer het niet als lastig.

Wat ik wel een drama vindt is dat je niet via SNMP de BGP peer status kan opvragen bij redelijk courante Cisco's en dat Cisco daar niks aan doet. Stom. Cisco 2921 met 15.4. Is hier al een keer verbetering in gekomen?

[ Voor 41% gewijzigd door databeestje op 14-03-2015 22:16 ]

[Snow_King]

databeestje schreef op zaterdag 14 maart 2015 @ 22:11:
[...]

Snom? We hebben er een aantal op het werk waar IPv6 firmware voor beschikbaar is (Snom 720).

De Snom 715 is het idd geworden. Ding heeft nog wel IPv4 nodig voor zijn provisioning en lijkt ook IPv4 te preferreren over IPv6, maar dat is met software updates recht te zetten.

De VOIP/SIP gaat gewoon netjes over IPv6.

[Maurits van Baerle]

Maurits van Baerle schreef op donderdag 25 september 2014 @ 15:08:
[...]

Ze staan sinds gisteren in de overzichtstabel:

Participating Network.............ASN(s).........................IPv6 deployment
ZeelandNet............................15542............................32.46%

Snow_King schreef op vrijdag 26 september 2014 @ 10:07:
[...]

32%! Dat is best wel netjes

Vreemd genoeg lijkt Zeelandnet nu te zijn teruggevallen tot 4,20%. Ik vraag me af waar dat door komt...

XS4ALL staat steeds op ruim 55% dus het lijkt me geen aanpassing van de meetmethode.

[ Voor 45% gewijzigd door Maurits van Baerle op 22-03-2015 14:26 ]

[Verwijderd]

Maurits van Baerle schreef op zondag 22 maart 2015 @ 14:14:

Vreemd genoeg lijkt Zeelandnet nu te zijn teruggevallen tot 4,20%. Ik vraag me af waar dat door komt...

XS4ALL staat steeds op ruim 55% dus het lijkt me geen aanpassing van de meetmethode.

Het data volume op de Ams-Ix is ook aardig ingestort, geen idee waarom. Wel raar om te zien, zeker omdat ik al 2 weken bezig ben om al mijn interne systemen IPv6 only te maken. Ik kom genoeg ellende tegen overal blijft er voortgang in zitten want de voordelen doen me nog steeds deugd.

[Hipska]

Blij dat we in bepaalde dingen wel voorlopen: nieuws: Akamai: een derde dataverkeer uit België verloopt via ipv6

[St00mwals]

Hipska schreef op woensdag 25 maart 2015 @ 12:01:
Blij dat we in bepaalde dingen wel voorlopen: nieuws: Akamai: een derde dataverkeer uit België verloopt via ipv6

Jullie wel ja.....


maar wacht maar totdat dit jaar, of volgend jaar, of dat jaar daarop, of dat jaar..... enz. enz. enz. enz. enz. enz. enz. enz. enz. enz.


UPC/Ziggo IPv6 uit gaan rollen, dan gaat het in NL ook ineens heel hard

[Raven]

En dan de rest van de providers nog. Zit op dit moment bij Tweak, maar die doet volgens mij net als Telfort (en Concepts voor de overname) vooralsnog niet aan IPv6.

[Snow_King]

St00mwals schreef op woensdag 25 maart 2015 @ 19:50:
UPC/Ziggo IPv6 uit gaan rollen, dan gaat het in NL ook ineens heel hard

Uiteraard In 2025 waarschijnlijk.

Raven schreef op woensdag 25 maart 2015 @ 21:05:
En dan de rest van de providers nog. Zit op dit moment bij Tweak, maar die doet volgens mij net als Telfort (en Concepts voor de overname) vooralsnog niet aan IPv6.

Het was een behoorlijke zoektocht om naast XS4All nog een andere VDSL provider te vinden die IPv6 aan biedt. Uiteindelijk kwam ik bij Solcon terecht.

Wel blij dat ZeelandNet het al een tijdje levert op mijn thuis verbinding.

[Raven]

VDSL? Ik heb 1Gbps down/up via glas

[Snow_King]

Raven schreef op donderdag 26 maart 2015 @ 08:47:
VDSL? Ik heb 1Gbps down/up via glas

Helaas


Net trouwens de update 2.50 van mijn PS4 geïnstalleerd. Mijn PS4 heeft nog steeds geen IPv6-adres, maar ik kan hem wel pingen via zijn Link Local address.

Hij neemt geen adres aan via de RA's in mijn netwerk... Kom op Sony, ik wil Netflix via IPv6 kijken op mijn PS4!

[XVI]

Raven schreef op woensdag 25 maart 2015 @ 21:05:
En dan de rest van de providers nog. Zit op dit moment bij Tweak, maar die doet volgens mij net als Telfort (en Concepts voor de overname) vooralsnog niet aan IPv6.

Toen ik nog bij ze zat boden ze IPv6 aan via 6rd.
Ik moest een mailtje naar ze sturen en na ongeveer een maand kreeg ik de gegevens toegestuurd.
Tuurlijk, het is niet native, maar wel de next best thing.

[Raven]

Dan kan ik net zo goed mijn HE-tunnel blijven gebruiken

[eymey]

Hehe.... Telfort (KPN ITNS) geeft ook IPV6 via 6RD. Maar het nadeel daar is dat men de laatste tijd nogal eens met IP block assignments per PoP gebied schuift en dan verandert dus ook je hele ipv6 prefix.

Zelf werk ik daarom ook alweer een tijdje met een SIXXS tunnel. Ook een tijdje he.net geprobeerd, overigens.

Jammer genoeg kennen beiden zo hun nadelen, waarvan ik nou nog steeds niet weet of m'n Fritz!box het niet helemaal lekker afhandelt of dat het algemeen is:

* bij HE.net (amsterdam PoP) heb ik een buitenlandse IPV6 prefix wat in sommige gevallen een nadeel kan zijn.
* Bij Sixxs was de tunnel de laatste tijd schijnbaar zo instabiel dat alle ipv6 enabled sites (en dat zijn er nogal wat tegenwoordig) intermittent connection failures opleverden. Facebook en Google waren hierdoor soms gewoon niet te gebruiken.

[Raven]

Kwam dat niet door het blokkeren van packettoobig-pakketjes? Of was het alleen Google die meerdere keren dat geintje uithaalde?

[eymey]

Ik heb wel een poging gedaan het uit te zoeken. Bij he.net had ik er overigens zo nu en dan ook flink last van (vooral ook bij SSH sessies naar een VPS die ik bij Transip heb, met geregelde intervallen 4-5 sec helemaal geen verkeer).

Maar mijn kennis, zeker op dat niveau, schiet te kort om echt grondig tcpdumps te kunnen analyseren.

[ Voor 9% gewijzigd door eymey op 26-03-2015 15:37 ]

[Raven]

Op dergelijke momenten zou je die ipv6-test sites eens moeten proberen te openen, dankzij die sites kwam ik er een keer achter dat ik zelf die packettoobig-pakketjes (net als alle andere icmpv6 pakketten) zat te blokkeren. Maar dat staat los van het feit dat sommige firewalls van webservers ook niet altijd goed geconfigureerd zijn.

[eymey]

Inderdaad.

Het bizarre aan dat transip verhaal is trouwens: Ik heb ook nog een VPS bij "cloudvps" dat ook native ipv6 biedt. Op zowel transip als cloudvps heb ik zelf een identieke firewall configuratie opgezet. En bij cloudvps treedt die intermittent packet loss niet op, bij transip dus wel (ook met firewall helemaal uit).

Maar goed, op dit moment heb ik sowieso ff weinig tijd vrij dus ipv6 staat nu maar tijdelijk uit.

[Verwijderd]

eymey schreef op donderdag 26 maart 2015 @ 15:54:
Inderdaad.

Het bizarre aan dat transip verhaal is trouwens: Ik heb ook nog een VPS bij "cloudvps" dat ook native ipv6 biedt. Op zowel transip als cloudvps heb ik zelf een identieke firewall configuratie opgezet. En bij cloudvps treedt die intermittent packet loss niet op, bij transip dus wel (ook met firewall helemaal uit).

Maar goed, op dit moment heb ik sowieso ff weinig tijd vrij dus ipv6 staat nu maar tijdelijk uit.

Misschien is de tool "tracebox" interessant, daarmee heb ik al wat tussenliggende apparaten in kaart gebracht die je met reguliere tools niet ziet.

https://github.com/tracebox/tracebox

[eymey]

Thanks! Ik zal hier zeker eens naar gaan kijken.

[databeestje]

eymey schreef op donderdag 26 maart 2015 @ 15:54:
Inderdaad.

Het bizarre aan dat transip verhaal is trouwens: Ik heb ook nog een VPS bij "cloudvps" dat ook native ipv6 biedt. Op zowel transip als cloudvps heb ik zelf een identieke firewall configuratie opgezet. En bij cloudvps treedt die intermittent packet loss niet op, bij transip dus wel (ook met firewall helemaal uit).

Maar goed, op dit moment heb ik sowieso ff weinig tijd vrij dus ipv6 staat nu maar tijdelijk uit.

Helaas is niet alle bcp documentatie up-to-date, soms worden ook de ip4 limiter instellingen gebruikt voor ip6, en dat is niet correct.

De meeste documentatie laat de ICMP limiter op IP6 nu varen, omdat deze met enige significante hoeveelheden verkeer gewoon te veel problemen veroorzaakt.

Het klinkt alsof transip hier een icmp limiter op 1 van de routers heeft staan voor IPv6, en dan krijg je exact dat soort intermittent problemen.

Het is niet alsof huidige routers niet tegen een 100mbit stroompje icmp kunnen ofzo, het is gerommel in de marge.

[eymey]

Misschien moet ik het toch maar eens aan ze vragen dan .

Echter, het wordt nog gekker: Als ik eerst SSH naar mijn VPS bij CloudVPS en van daaruit weer naar mijn VPS bij Transip, dan heb ik het probleem óók niet.....

[Hipska]

En komt die misschien binnen via een andere route?

[databeestje]

eymey schreef op vrijdag 27 maart 2015 @ 08:30:
Misschien moet ik het toch maar eens aan ze vragen dan .

Echter, het wordt nog gekker: Als ik eerst SSH naar mijn VPS bij CloudVPS en van daaruit weer naar mijn VPS bij Transip, dan heb ik het probleem óók niet.....

Dat is gegarandeerd een 1500 byte MTU clean pad

En je sessie naar Cloudvps heeft werkende PtB

[eymey]

Hmm, zit wat in ja

[Raven]

Zou iemand kunnen verklaren waarom de plaatjes in in "Het grote topic voor nette lan afwerking thuis deel 3" het niet doen met IPv6 ingeschakeld (not found error) en wél via IPv4? Met als aanvulling dat https via IPv6 een ongeldig certificaat melding geeft en via IPv4 niet

[ Voor 2% gewijzigd door Kees op 13-03-2018 14:45 ]

[databeestje]

Omdat de virtual host instellingen van zijn webserver niet overeen komen, dat is een veel voorkomend probleem. Je kan deze aan ip4:80 binden, of *:80 of ip6:80, elke kan dan in een ander root terecht komen, en dus een andere site, of certificaat.

Dat je meld dat het certificaat anders is voor 4 en 6 is hier een goede indicatie van, al zag ik het al bij de 404.

[CyBeR]

Of de adressen wijzen naar verschillende servers.

[Raven]

Weet niet wat de oorzaak was, maar heeft het na mijn melding gefixed

[ Voor 27% gewijzigd door Kees op 13-03-2018 14:45 ]

[KroontjesPen]

Ziggo gaat voorlopig niet over op IPv6.

http://www.coax.nl/news/2...-Ziggo-COAX-10-3-2015.pdf

C. IPv6: Ziggo geeft aan klaar te zijn voor IPv6, maar op dit moment is er nog geen vraag naar. Als die vraag komt zal Ziggo IPv6 aanbieden.

[ Voor 3% gewijzigd door KroontjesPen op 01-04-2015 15:01 ]

[Keiichi]

KroontjesPen schreef op dinsdag 31 maart 2015 @ 21:48:
Ziggo gaat voorlopig niet over op IPv6.

http://www.coax.nl/news/2...-Ziggo-COAX-10-3-2015.pdf

C. IPv6: Ziggo geeft aan klaar te zijn voor IPv6, maar op dit moment is er nog geen vraag naar. Als die vraag komt zal Ziggo IPv6 aanbieden.

Hoe kunnen ze het onderzoeken dat er geen vraag naar is? De gemiddelde consument zou zeggen: "Ei Pie Vee WAT?!!?". Ze zullen ook niet om IPv4 vragen

[CAPSLOCK2000]

Ik ken tenminste 1 persoon die ziggo heeft opgezegd omdat ze nog steeds geen IPv6 leveren. Ik vrees dat iedereen die IPv6 nodig heeft ofwel naar een andere provider overstapt ofwel zelf een tunnel op zet.

[Roetzen]

CAPSLOCK2000 schreef op woensdag 01 april 2015 @ 00:43:
Ik ken tenminste 1 persoon die ziggo heeft opgezegd omdat ze nog steeds geen IPv6 leveren. Ik vrees dat iedereen die IPv6 nodig heeft ofwel naar een andere provider overstapt ofwel zelf een tunnel op zet.

Dat er geen vraag naar zou zijn is ook niet waar. Ik vraag er al jaren om. Ik ben niet de enige. Maar ja, het is natuurlijk maar een kleine minderheid die er expliciet om vraagt. De meerderheid weet niet eens wat het is. Als je maar lang genoeg de vraag van de minderheid negeert, verdwijnt die vanzelf wel omdat ze hun heil elders gaan zoeken.

Een puur technische kwestie als de invoering van IPv6 zou ook niet gedreven moeten zijn door de vraag van de eindgebruikers. Men zou het gewoon moeten doen omdat het voor het voor de continuiteit van het netwerk noodzakelijk is. KLM gaat er toch ook niet zitten wachten met het vervangen van 30+ jaar oude toestellen door iets moderners tot de reiziger daar expliciet om vraagt? Ze doen het gewoon om concurrerend te blijven draaien.

[CyBeR]

De volgende stelling in die PDF is dat er geen vraag zou zijn naar hogere upstreamsnelheden dus ik zou dat allemaal met een flinke korrel zout nemen.

[databeestje]

CyBeR schreef op woensdag 01 april 2015 @ 01:20:
De volgende stelling in die PDF is dat er geen vraag zou zijn naar hogere upstreamsnelheden dus ik zou dat allemaal met een flinke korrel zout nemen.

Dan is de video stream van mijn camera ook meteen een stuk sneller!

(zegt de minderheid)

[Osiris]

Of zou je tenminste fatsoenlijk een VPN kunnen draaien vanuit thuis! Oh wacht, dat wordt ongetwijfeld toch wel geblokkeerd

[Demo]

Als er volgens Ziggo geen vraag is, dan zullen we die moeten stellen, toch? Tweet naar @ZiggoWebcare is verstuurd

[Snow_King]

Demoniac schreef op woensdag 01 april 2015 @ 10:13:
Als er volgens Ziggo geen vraag is, dan zullen we die moeten stellen, toch? Tweet naar @ZiggoWebcare is verstuurd

Heb ik ook gedaan

[Zsub]

Yup, tweet ook hier de deur uit. Wat een heerlijke redenering ook. Overigens hoop ik nog steeds op een nette prefix met mijn modem in bridge, en niet verplicht een Ziggo-router ertussen.

[Keiichi]

Snow_King schreef op woensdag 01 april 2015 @ 10:45:
[...]

Heb ik ook gedaan

Ik heb een mail naar helpdesk gestuurd. Ook even gewezen op dit topic

[Verwijderd]

Demoniac schreef op woensdag 01 april 2015 @ 10:13:
Als er volgens Ziggo geen vraag is, dan zullen we die moeten stellen, toch? Tweet naar @ZiggoWebcare is verstuurd

Hierbij ook verstuurd

[Roetzen]

Ook gedaan...

[Verwijderd]

Zojuist werd ik erop gewezen dat ook een melding op chelloo.com is gedaan binnen de UPC ipv6 test groep.

[Paul C]

De trendlijn is nog niet helemaal bijgewerkt, want die zegt 13 juni 2015 als exhaustion date voor ARIN, maar als ik naar dit plaatje kijk zie ik toch echt wat anders:


Dat betekend dat er binnen nu en een paar dagen alleen nog in Afrika een beetje fatsoenlijk IP4 adressen te verkrijgen zijn.

[CyBeR]

RIPE zie ik ander beduidend verder doorgaan dan AFRINIC?

maar wtf ARIN nou weer uit aan 't spoken is…

[Paul C]

Zo te zien heeft RIPE een paar keer flinke blokken terug gekregen:
https://www.ripe.net/inte...ipv4-available-pool-graph

Als je naar de 24 maanden grafiek kijkt, dan zie je die een paar keer omhoog springen. Ze hanteren echter wel al een paar jaar een schaarste beleid.

[Maurits van Baerle]

Verwijderd schreef op woensdag 01 april 2015 @ 12:54:
Zojuist werd ik erop gewezen dat ook een melding op chelloo.com is gedaan binnen de UPC ipv6 test groep.

Heb je een linkje? Dit zou wel eens een Frontpage bericht kunnen worden aangezien het een wijziging is van hun oorspronkelijke strategie. Op z'n beurt kan zo'n nieuwsbericht weer extra druk op de ketel zetten.

[CyBeR]

Paul C schreef op woensdag 01 april 2015 @ 13:06:
Zo te zien heeft RIPE een paar keer flinke blokken terug gekregen:
https://www.ripe.net/inte...ipv4-available-pool-graph

Als je naar de 24 maanden grafiek kijkt, dan zie je die een paar keer omhoog springen. Ze hanteren echter wel al een paar jaar een schaarste beleid.

Ze hoeven die niet zozeer "terug" gekregen te hebben, alsmeer dat ze die toegewezen gekregen hebben van IANA.

[Roetzen]

CyBeR schreef op woensdag 01 april 2015 @ 13:00:
RIPE zie ik ander beduidend verder doorgaan dan AFRINIC?

RIPE hanteert een "last /8 policy". In 2011 was er nog één /8 over en toen ging die policy in. Ieder lid kon dan nog één /22 krijgen op voorwaarde dat je ook een IPv6 allocatie aanvraagt of al hebt aangevraagd. En dat is het dan.

Dus dat laatste /8 kan dan nog heel lang meegaan, maar in feite is de koek al op.

ARIN hanteert geen "last /8 policy". Die blijven gewoon uitgeven als iemand er om vraagt totdat het echt op is. Wat we bij ARIN nu zien is mogelijk de "last minute run".

Ze hoeven die niet zozeer "terug" gekregen te hebben, alsmeer dat ze die toegewezen gekregen hebben van IANA.

Nee, IANA geeft niets meer uit, daar was het vijf jaar geleden al op.

[ Voor 13% gewijzigd door Roetzen op 01-04-2015 13:27 ]

[Verwijderd]

Maurits van Baerle schreef op woensdag 01 april 2015 @ 13:10:
[...]

Heb je een linkje? Dit zou wel eens een Frontpage bericht kunnen worden aangezien het een wijziging is van hun oorspronkelijke strategie. Op z'n beurt kan zo'n nieuwsbericht weer extra druk op de ketel zetten.

Is een besloten deel op het forum, alleen voor IPv6 testers van UPC. Maar hierbij toch de link: https://chelloo.com/forum/index.php?topic=54657.0

[CyBeR]

Roetzen schreef op woensdag 01 april 2015 @ 13:24:
[...]

Nee, IANA geeft niets meer uit, daar was het vijf jaar geleden al op.

Vijf jaar is overdreven maar 't was idd niet de laatste 24 maanden.

[Jaap-Jan]

CyBeR schreef op woensdag 01 april 2015 @ 15:45:
[...]


Vijf jaar is overdreven maar 't was idd niet de laatste 24 maanden.

4 jaar en 2 maanden komt wel een eind in de richting.

quote: http://en.wikipedia.org/wiki/IPv4_address_exhaustion

On 31 January 2011, the last two unreserved IANA /8 address blocks were allocated to APNIC according to RIR request procedures. This left five reserved but unallocated /8 blocks.[4][14][15] In accord with ICANN policies, IANA proceeded to allocate one of those five /8s to each RIR, exhausting the IANA pool,[16] at a ceremony and press conference on 3 February 2011.

[Roetzen]

CyBeR schreef op woensdag 01 april 2015 @ 15:45:
[...]
Vijf jaar is overdreven maar 't was idd niet de laatste 24 maanden.

Het is inderdaad maar 4 jaar en twee maanden.

http://www.potaroo.net/tools/ipv4/

[CyBeR]

Ja, dus overdreven

[Hipska]

Vraagje ivm omschakeling IPv4 naar IPv6:

Het publiek IPv4 adres van ons kantoor is toegelaten om bepaalde servers te bereiken van een klant. Wij zitten op een private network dat naar buiten toe geNAT is, waardoor wij gewoon allemaal die servers kunnen bereiken. Ook als we thuis zitten is dit geen probleem, we hebben VPN naar kantoor en dmv een route toe te voegen voor het subnet van de servers via de gateway van de tunnel werkt ook alles probleemloos.

Stel nu dat beide bedrijven IPv6 hebben.

Intern, naar de klant servers is geen probleem, het /64 of /48 van kantoor kan toegestaan worden. Ook als we vanaf thuis werken en een server van op kantoor willen bereiken kan het /64 van thuisverbinding een toegang verkrijgen.

Maar hoe zou je dan van thuis uit aan die klant servers kunnen geraken?

[CyBeR]

Ofwel door die thuis-adressen ook toe te voegen (net als nu, zonder vpn) ofwel door met een VPN te blijven werken. Dit verandert eigenlijk niet wezenlijk.

[databeestje]

CyBeR schreef op woensdag 01 april 2015 @ 16:45:
Ofwel door die thuis-adressen ook toe te voegen (net als nu, zonder vpn) ofwel door met een VPN te blijven werken. Dit verandert eigenlijk niet wezenlijk.

Dat, voor ons kantoor doen we het met IPv6 hetzelfde als IPv4. We gebruiken OpenVPN op pfSense met Viscosity als client voor een Dual Stack VPN.

Daar kan je ook makkelijk extra routes aan toe voegen alswel brede client ondersteuning voor allerlei apparaten zoals Android en IOS en dergelijke.

[CAPSLOCK2000]

Verwijderd schreef op woensdag 01 april 2015 @ 15:24:

Is een besloten deel op het forum, alleen voor IPv6 testers van UPC. Maar hierbij toch de link: https://chelloo.com/forum/index.php?topic=54657.0

Zou je een samenvatting kunnen geven? Ik gok zo iets als "het project was een groot succes, nu leggen we alles weer op de plank en gaan zitten wachten".

[Verwijderd]

CAPSLOCK2000 schreef op woensdag 01 april 2015 @ 19:02:
Zou je een samenvatting kunnen geven? Ik gok zo iets als "het project was een groot succes, nu leggen we alles weer op de plank en gaan zitten wachten".

Het was een melding van een tester met de vraag/opmerking over het bericht van coax.nl dus niet een reactie van UPC zelf (helaas).

[Hipska]

CyBeR schreef op woensdag 01 april 2015 @ 16:45:
Ofwel door die thuis-adressen ook toe te voegen (net als nu, zonder vpn) ofwel door met een VPN te blijven werken. Dit verandert eigenlijk niet wezenlijk.

Thuis subnets zullen niet toegestaan worden.

Bij de tweede optie, versta ik het dan goed dat OpenVPN dan een public /64 reeks (vanuit de /48 reeks) verspreid naar zijn clients, samen met de routes net als bij IPv4?

[databeestje]

Hipska schreef op donderdag 02 april 2015 @ 10:14:
[...]

Thuis subnets zullen niet toegestaan worden.

Bij de tweede optie, versta ik het dan goed dat OpenVPN dan een public /64 reeks (vanuit de /48 reeks) verspreid naar zijn clients, samen met de routes net als bij IPv4?

Yup

[Hipska]

Oké bedankt, dat lijkt me duidelijk. Dan zou je zelfs kunnen verbinden op een locatie die enkel IPv4 heeft lijkt me. (Want IPv6 adres via tunnel)

[Maurits van Baerle]

Verwijderd schreef op donderdag 02 april 2015 @ 09:40:
[...]


Het was een melding van een tester met de vraag/opmerking over het bericht van coax.nl dus niet een reactie van UPC zelf (helaas).

Ah, dus de enige bron waar alles op gebaseerd is zijn de notulen van een vergadering gemaakt door een medewerker van COAX? Dan is er dus nog een kans dat het een misverstand of bewust vaag antwoord was.

Aangezien ze op dit moment druk bezig zijn met allerlei technische integratie van hun andere diensten kan ik me voorstellen dat IPv6 even een lagere prioriteit heeft. Maar, het is nu bijna vier maanden geleden dat ze hun aangekondigde uitrol in de ijskast zetten dus is het geen gek idee als over een maandje of twee een FP redacteur eens contact zoekt om te vragen hoe het er nu voor staat.

[CyBeR]

Hipska schreef op donderdag 02 april 2015 @ 13:17:
Oké bedankt, dat lijkt me duidelijk. Dan zou je zelfs kunnen verbinden op een locatie die enkel IPv4 heeft lijkt me. (Want IPv6 adres via tunnel)

Correct.

Of je een /64 op je tunnel zet of niet is overigens een implementatiedetail. Je kunt ook een enkel IP-adres toewijzen bijvoorbeeld.

[databeestje]

CyBeR schreef op donderdag 02 april 2015 @ 14:10:
[...]


Correct.

Of je een /64 op je tunnel zet of niet is overigens een implementatiedetail. Je kunt ook een enkel IP-adres toewijzen bijvoorbeeld.

OpenVPN (client) wijst standaard 1 /128 adres uit een /64 toe, als je meer wil routeren dan kun je uiteraard meer routes mee sturen (en dat doen we dan ook).

[Snow_King]

Net de VOIP/backup lijn van Solcon aangesloten. En ja, mét IPv6!

Wel jammer dat de MTU 1452 is in plaats van 1500 zoals bij XS4All / ZeelandNet. Schijnt iets met PPP te zijn?

[CyBeR]

Niet 1492? Dat is de MTU van een PPPoE-verbinding namelijk.

[Snow_King]

CyBeR schreef op donderdag 02 april 2015 @ 17:32:
Niet 1492? Dat is de MTU van een PPPoE-verbinding namelijk.

Juist, 1492 inderdaad. Maar dat is dus normaal?

Ik test net op onze XS4All VDSL verbinding en daar zegt tracepath6 dat de MTU 1500 is naar mijn destination.

[CAPSLOCK2000]

XS4All gebruikt RFC 4638 om toch een MTU van 1500 aan te kunnen bieden. Het zijn soort jumbo-frames die zo gekozen worden dat de overhead van pppoe/vlans wegvalt en je netjes op 1500 uit komt.

[CyBeR]

Snow_King schreef op donderdag 02 april 2015 @ 17:48:
[...]

Juist, 1492 inderdaad. Maar dat is dus normaal?

Yep. Dat is 1500 bytes ethernet min 8 bytes voor PPPoE.

[Snow_King]

CAPSLOCK2000 schreef op donderdag 02 april 2015 @ 17:57:
XS4All gebruikt RFC 4638 om toch een MTU van 1500 aan te kunnen bieden. Het zijn soort jumbo-frames die zo gekozen worden dat de overhead van pppoe/vlans wegvalt en je netjes op 1500 uit komt.

Aha, dat maakt een hoop duidelijk!

CyBeR schreef op donderdag 02 april 2015 @ 18:01:
[...]


Yep. Dat is 1500 bytes ethernet min 8 bytes voor PPPoE.

Weer wat geleerd. Tnx

Goede is in ieder geval dat er weer een IPv6 verbinding bij is in Nederland.

Solcon geeft overigens een /56, geen /48 zoals XS4All. Moet ik iets zuiniger gaan zijn met subnets

[databeestje]

Snow_King schreef op donderdag 02 april 2015 @ 19:47:
[...]

Weer wat geleerd. Tnx

Goede is in ieder geval dat er weer een IPv6 verbinding bij is in Nederland.

Solcon geeft overigens een /56, geen /48 zoals XS4All. Moet ik iets zuiniger gaan zijn met subnets

Beetje aparte keuze voor een zakelijke (?) verbinding al zeg ik het zelf.

Die lagere MTU ga je op langere termijn wellicht wel last van ondervinden, dat geeft toch her en der problemen waar path MTU niet werkt, en dat is vaak buiten je macht.

Ga je NAT66 NPt gebruiken voor failover?

[Snow_King]

databeestje schreef op donderdag 02 april 2015 @ 20:00:
[...]

Beetje aparte keuze voor een zakelijke (?) verbinding al zeg ik het zelf.

Ja, ik had groter dan een /56 ook wel fijn gevonden.

Maar ach, ik kan /60's uitdelen en daar weer /64's uit halen.

databeestje schreef op donderdag 02 april 2015 @ 20:00:
[...]
Die lagere MTU ga je op langere termijn wellicht wel last van ondervinden, dat geeft toch her en der problemen waar path MTU niet werkt, en dat is vaak buiten je macht.

Ben ik ook bang voor. Maar we verbinden vooral met onze eigen servers vanaf ons kantoor. Zeker via deze verbinding.

databeestje schreef op donderdag 02 april 2015 @ 20:00:
[...]
Ga je NAT66 NPt gebruiken voor failover?

Nee. Deze verbinding is primair voor onze VOIP die we naar IPv6 gaan over zetten.

Op de WiFi komt ook een tweede SSID, mocht XS4All er uit vallen, dan kan je daar naar verbinden. Normaal gaat alles via kabel overigens.

Als de VOIP weg valt hebben we nog paar toestellen die via XS4All gaan of we routeren telefonie naar ander kantoor toe.

[CyBeR]

Lagere MTU is redelijk veelvoorkomend hoor. TCP MSS clamping instellen en je hebt nergens last van.

[databeestje]

Snow_King schreef op donderdag 02 april 2015 @ 20:53:
[...]

Nee. Deze verbinding is primair voor onze VOIP die we naar IPv6 gaan over zetten.

Op de WiFi komt ook een tweede SSID, mocht XS4All er uit vallen, dan kan je daar naar verbinden. Normaal gaat alles via kabel overigens.

Als de VOIP weg valt hebben we nog paar toestellen die via XS4All gaan of we routeren telefonie naar ander kantoor toe.

Thuis op pfSense heb ik een NPt entry gemaakt en een gateway group die de default omzet als HE.net eruit valt. De default route gaat dan naar de Sixx6 tunnel, door de NPt mapping is er een 1:1 mapping voor de gehele /48.

Ook al gebruik ik intern de prefix van HE.net, deze kan ik ook bereiken via de Sixx6 prefix, simultaan. Dus zowel inbound als outbound werkt het vrijwel transparant. Voip zal zoals gebruikelijk wel weer een probleem zijn omdat ze het IP in het pakketje steken (bedacht door een comittee).

Zeker voor backup toepassingen (zoals met HE.net tunnel via 3G als backup) is dit een uitkomst. Omdat er verder geen cheap-ass multihoming in de IPv6 spec zit is dit 1 van de weinige oplossingen zonder ingrijpende oplossingen.

Voor een hele grote groep mensen is BGP geen oplossing. Onder andere omdat providers daar geen zin in hebben zonder een financiele compensatie. Ook BGP is niet geschikt, dat is gebouwd op wederzijds vertrouwen, dus ongeschikt voor thuis toepassingen.

Anno 2015 een bedrijfsvoering laten lopen over 1 verbinding is Russische roulette.

[CyBeR]

databeestje schreef op donderdag 02 april 2015 @ 21:11:
[...]
Voip zal zoals gebruikelijk wel weer een probleem zijn omdat ze het IP in het pakketje steken (bedacht door een comittee).

Dat is om de control info te scheiden van het datapad. Iets wat in de telecom heel gebruikelijk is.

Ook BGP is niet geschikt, dat is gebouwd op wederzijds vertrouwen, dus ongeschikt voor thuis toepassingen.

Nee hoor. Je kunt prima wat de andere kant lult wantrouwen en 't filteren.

[databeestje]

Volgens mensen op de IPv6 TF is Ziggo begonnen met het activeren van IPv6 voor klanten in Noord Holland.

Nou zie ik thuis nog geen verandering, maar dat kan te maken hebben met de bridge modus van mijn modem. Tevens zal deze wel een reload nodig hebben voordat deze de settings oppikt.

[Raven]

TF?

[databeestje]

Raven schreef op vrijdag 03 april 2015 @ 16:02:
TF?

TaskForce

[Raven]

Ah

....

Firefox kan de server op www.ipv6tf.org niet vinden.
edit: (na lang wachten) " It's not just you! http://ipv6tf.org looks down from here. "

[ Voor 38% gewijzigd door Raven op 03-04-2015 16:12 ]

[databeestje]

http://new.ipv6-taskforce.nl/

[Osiris]

databeestje schreef op vrijdag 03 april 2015 @ 16:13:
http://new.ipv6-taskforce.nl/

"Agenda 2014"..

Beetje jammer jongens

[Snow_King]

databeestje schreef op vrijdag 03 april 2015 @ 15:54:
Volgens mensen op de IPv6 TF is Ziggo begonnen met het activeren van IPv6 voor klanten in Noord Holland.

Nou zie ik thuis nog geen verandering, maar dat kan te maken hebben met de bridge modus van mijn modem. Tevens zal deze wel een reload nodig hebben voordat deze de settings oppikt.

Klinkt goed! Heb je ook een directe bron en kunnen we ergens achterhalen of dit weer een pilot is?

Is het native IPv6, 6RD, etc. Ik ben héél erg benieuwd namelijk.

[KroontjesPen]

De link van
http://new.ipv6-taskforce.nl/ --> http://new.ipv6-taskforce.nl/ipv6-nieuws/
is deze:

http://www.nu.nl/internet...nten-ipv6-overzetten.html

Gepubliceerd: 04 februari 2013 14:24
Laatste update: 04 februari 2013 16:07

Lekker bij de tijd.

[ Voor 13% gewijzigd door KroontjesPen op 03-04-2015 16:45 ]