Het grote IPv6 topic

[Snow_King]

stormfly schreef op zondag 24 mei 2015 @ 21:37:
Erger vind ik anno 2015 dat redelijk gerenommeerde sites een AAAA record hebben, de webserver luistert op de juiste TCP porten maar dat de server niet juist geconfigureerd is om content te mogen afleveren op die adapter...

Omwille van die reden, weet ik nog niet of ik het echt aan ga zetten thuis. Op kantoor zijn we terug naar IPv4 prefererd ipv IPv6 prefered, er kwamen teveel klachten dat sommige sites niet meer werkte.

Ik push juist op ons kantoor IPv6 keihard om iedereen er zo maximaal ervaring mee op te laten doen. Dat geeft je juist op langere termijn technisch een gigantische voorsprong.

Wij merken overigens weinig wat niet lekker over IPv6 werkt.

Bigs schreef op zondag 24 mei 2015 @ 22:32:
Klopt je komt in de praktijk behoorlijk wat misconfiguraties tegen. Ik merk er zelf weinig van, waarschijnlijk omdat ik eigenlijk uitsluitend OS X gebruik dat toch al vaak terugvalt naar IPv4 (soms midden in een sessie wat bij veel websites ook voor problemen zorgt). Overigens merk ik in onze organisatie dat er soms sluipende IPv6 problemen zijn die we niet doorhebben, simpelweg omdat onze monitoring totaal niet op ingericht is om beide stacks apart in de gaten te houden. Dat is ook de reden dat we nog niet standaard alle hosting klanten op IPv6 hebben zitten. Vind het wel eens tijd worden, maarja zoals altijd is de business case minimaal..

Wij zien juist wel veel klanten specifiek om IPv6 vragen, maar wellicht ook omdat we juist dat type klant trekken.

Je moet je processen er nu al voor in regelen. Dan kan je zelfs op veel plekken IPv4 er al uit gooien. Dat is heerlijk om te kunnen doen.

[Verwijderd]

stormfly schreef op zondag 24 mei 2015 @ 21:37:
Erger vind ik anno 2015 dat redelijk gerenommeerde sites een AAAA record hebben, de webserver luistert op de juiste TCP porten maar dat de server niet juist geconfigureerd is om content te mogen afleveren op die adapter...

http://alkmaar.nl/

[ Voor 21% gewijzigd door Verwijderd op 26-05-2015 09:22 ]

[databeestje]

Mailtje naar het Whois technisch contact gestuurd, ik ben benieuwd, in ieder geval een ticket teruggekregen van de hoster.

[CyBeR]

Verwijderd schreef op dinsdag 26 mei 2015 @ 09:19:
[...]


http://alkmaar.nl/

www.alkmaar.nl doet 't wel goed via ipv6, 't is alleen de redirect op 'alkmaar.nl' die stuk is.

[Verwijderd]

Het zou een standaard onderdeel moeten zijn van IP6 testen zoals op http://ip6.nl/ en https://internet.nl/ dat er wordt gekeken of de website over IPv4 en over IPv6 qua data -met een marge- ongeveer gelijk is. Niet alleen op een HTTP status code want dan zou alkmaar.nl ook door de test komen.

Ik heb dit overigens niet nagekeken voor de bovengenoemde sites, misschien gebeurd dit al.

[CyBeR]

Verwijderd schreef op dinsdag 26 mei 2015 @ 10:06:
Het zou een standaard onderdeel moeten zijn van IP6 testen zoals op http://ip6.nl/ en https://internet.nl/ dat er wordt gekeken of de website over IPv4 en over IPv6 qua data -met een marge- ongeveer gelijk is. Niet alleen op een HTTP status code want dan zou alkmaar.nl ook door de test komen.

Ik heb dit overigens niet nagekeken voor de bovengenoemde sites, misschien gebeurd dit al.

Alleen bij een rare check:

$ curl -vvv -6 http://alkmaar.nl/
* Hostname was NOT found in DNS cache
*   Trying 2001:1af8:4101:1::1:1...
* Connected to alkmaar.nl (2001:1af8:4101:1::1:1) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.37.1
> Host: alkmaar.nl
> Accept: */*
> 
< HTTP/1.1 404 Not Found

404 is typisch gezien een reden om te zeggen 'dit is stuk'.

[Maurits van Baerle]

Maar stel dat je via IPv4 de juiste pagina krijgt terwijl je via IPv6 bijvoorbeeld een standaard webserver configuratiepagina krijgt of, zoals eerder aangehaald, de oude site. Daarvoor zul je toch naar de inhoud van de site moeten kijken voordat je kunt vaststellen dat het werkt.

[ Voor 14% gewijzigd door Maurits van Baerle op 26-05-2015 10:26 ]

[Ximon]

Maar hoe gaat dat script weten wat 'correct' is? De websites checken of de infrastructuur werkt, en dat is zo: de webserver is keurig te vinden en benaderen via IPv6. Dat deze vervolgens "buh?" als antwoord geeft is niet het probleem van het netwerk (de -beheerder) maar van de webserver (beheerder).

quote: https://internet.nl

Werken jouw internetverbinding, website en e-mail wel met moderne internetstandaarden?
Test het hier en zorg ervoor dat je up-to-date bent.

Antwoord: ja. De rest is out-of-scope

[Verwijderd]

Het script kan niet weten wat werkelijk correct is, maar als de site data bijvoorbeeld 1800Kb is en over ipv6 120Kb dan lijkt me dat niet de juiste output terug is gegeven.

Ik heb sites gezien over IPv6 waarbij je de standaard apache site terug kreeg, ook zelfs een reactie als "het werkt". Natuurlijk kan er verschil in zitten door oa advertenties enzo vandaar dat er een marge nodig zou zijn van? 10% groter of kleiner.

[Ximon]

Dat zou idd mooi zijn maar het geeft misschien nogal ondoorzichtige foutmeldingen. Ik zou dan eerder een hash maken van de default pagina op ipv4 en ipv6, en die vergelijken. Als dat te zwaar is voor de tool zou er in plaats daarvan een waarschuwing weergeven kunnen worden bij HTTP 400 en 500-codes.

Uiteindelijk is het volgens mij geen IPv6 probleem. Ik heb IPv4-only websites gezien waarbij ik via https:// een heel andere site te zien kreeg dan via http://, of waarbij http://example.com inderdaad zo'n hoera-pagina liet zien terwijl http://www.example.com wel goed werkte.

[Maurits van Baerle]

Een hash lijkt me nou juist het minst geschikte. De kleinste afwijking (andere advertentie) geeft dan al een 100% afwijking.

Een combinatie van site grootte en misschien een paar standaard assets (favicon, css, bestandsgrootte van grootste plaatje?) zal al een redelijk betrouwbaar resultaat geven.

Edit: Of bedoel je een hash van bijvoorbeeld index.html? Dat zou inderdaad wel kunnen werken.

[ Voor 13% gewijzigd door Maurits van Baerle op 26-05-2015 10:56 ]

[Ximon]

Met default bedoelde ik de index.html of een variant daarvan, oftewel de pagina die je te zien krijgt als je zelf niets specificeert. Als het goed is wordt allerlei dynamische content apart geladen in de vorm van CSS, Flash objecten en andere externe meuk. Als je vervolgens de scripts in index.html niet rendert maar in plaats daarvan de hash uitrekent van de code zelf zou je een redelijk statische vergelijking moeten krijgen.

Het gaat inderdaad nogal snel de mist in, dus misschien is een test van het grootste plaatje dat op hetzelfde domein staat als de hoofdpagina zelf misschien een beter plan. Dat is dan weer niet echt een goede test voor 'bruikbare pagina' dus op zich is alleen HTTP status codes toch niet zo'n slecht idee. Dat heeft ook problemen maar kost een stuk minder resources.

Edit: inderdaad

[Eärendil]

Overijssel.nl is nog erger, er wordt wel een IPv6-verbinding geaccepteerd op poort 80, maar er gebeurt daarna niks. Geen foutmelding, geen standaard lege pagina, gewoon niks. Omdat er wel een verbinding is wordt IPv4 niet geprobeerd.

[Maurits van Baerle]

Ximon schreef op dinsdag 26 mei 2015 @ 11:11:
[..]
Dat is dan weer niet echt een goede test voor 'bruikbare pagina' dus op zich is alleen HTTP status codes toch niet zo'n slecht idee. Dat heeft ook problemen maar kost een stuk minder resources.

Maar HTTP status codes zullen je altijd minder vertellen dan een hash op de default pagina. En in dit geval heb je liever dat hij af en toe ten onrechte zegt dat er een probleem is dan andersom. Het hoeft niet 100% fail-safe te zijn maar enkel een HTTP status is wel érg onbetrouwbaar.

Naar mijn idee zou een prima script het volgende doen:

Ongeacht of de gebruiker example.com of www.example.com invoert zou het script altijd de volgende vier testen uitvoeren.
1) example.com over IPv4
2) example.com over IPv6
3) www.example.com over IPv4
4) www.example.com over IPv6

Alle vier testen moeten dezelfde hash opleveren. Als één test afwijkt van de andere drie moet er aangegeven worden welke afwijkt (zo voorkom je het alkmaar.nl probleem). Als twee afwijken van de andere twee moet dan ook aangegeven worden, alleen zal de beheerder dan moeten bepalen welke de goede is.

Deze test maakt HTTP status testen ook overbodig.

[Snow_King]

Zie het positief, mijn klant voegde vanmorgen direct het AAAA-record voor zijn website toe. Bioscoopketen hier in de buurt is nu ook over IPv6 bereikbaar!

Ik zie al direct ZeelandNet IPv6 connecties. Zo'n 3% aan het verkeer is daar nu IPv6.

[CAPSLOCK2000]

Statuscodes zijn ook niet perfect maar als je een 404 krijgt weet je zeker dat het niet goed is. Als je wel een nette 200 krijgt kun je verder kijken naar geavanceerdere vergelijkingen.

Collega's komen spontaan vertellen dat ze thuis opeens IPv6 hebben. Ze weten dat ons team daar hard voor heeft gewerkt maar ik vind het toch tof dat ze het ons komen vertellen.

Overigens ervaar ik maar weinig IPv6-gerelateerde problemen. Er zijn inderdaad wat sites die niet werken maar het aantal problemen is behoorlijk verwaarloosbaar in verhouding tot alle andere problemen die ik tegen kom. Als meer mensen IPv6 gaan gebruiken zal er meer aandacht voor komen en zullen die problemen wel weer verdwijnen. Een paar jaar geleden had je hetzelfde met HTTP en HTTPs sites die niet gelijk waren. Tegenwoordig zie je dat veel minder.

[Snow_King]

CAPSLOCK2000 schreef op woensdag 27 mei 2015 @ 00:09:
Statuscodes zijn ook niet perfect maar als je een 404 krijgt weet je zeker dat het niet goed is. Als je wel een nette 200 krijgt kun je verder kijken naar geavanceerdere vergelijkingen.

Collega's komen spontaan vertellen dat ze thuis opeens IPv6 hebben. Ze weten dat ons team daar hard voor heeft gewerkt maar ik vind het toch tof dat ze het ons komen vertellen.

Overigens ervaar ik maar weinig IPv6-gerelateerde problemen. Er zijn inderdaad wat sites die niet werken maar het aantal problemen is behoorlijk verwaarloosbaar in verhouding tot alle andere problemen die ik tegen kom. Als meer mensen IPv6 gaan gebruiken zal er meer aandacht voor komen en zullen die problemen wel weer verdwijnen. Een paar jaar geleden had je hetzelfde met HTTP en HTTPs sites die niet gelijk waren. Tegenwoordig zie je dat veel minder.

Idd. Ik ervaar ook echt héél weinig IPv6 problemen. Ligt eigenlijk nooit aan IPv6, maar eerder aan de beheerders er achter.

Dit is ook een kwestie van tijd, dan is het vanzelf opgelost zodra hier meer aandacht voor komt.

[Dennis]

Even een korte vraag, maar er is niet ergens een pagina van Ziggo waar je kunt zien welke gebieden inmiddels IPv6 hebben toch, of wel? En vooralsnog is alles alleen het originele Ziggo netwerk zover ik begreep en niet het voormalige UPC.

[Dutch2007]

Dennis schreef op woensdag 27 mei 2015 @ 11:05:
Even een korte vraag, maar er is niet ergens een pagina van Ziggo waar je kunt zien welke gebieden inmiddels IPv6 hebben toch, of wel? En vooralsnog is alles alleen het originele Ziggo netwerk zover ik begreep en niet het voormalige UPC.

nee staat momenteel nergens....

- Groningen
- Heerhugowaard
- Tilburg
- Zwolle

dat zijn iig momenteel de bekende regio's voor zowel de 320 als de 321 ubee modems..

[ Voor 49% gewijzigd door Dutch2007 op 27-05-2015 12:04 ]

[Maurits van Baerle]

Verder weten we dat op 30 april 14.000 abonnees over waren gezet in die vier regio's. Ziggo heeft verder niets bekend gemaakt.

Wat er na 30 april is gebeurd is een kwestie van afgaan op meldingen van mensen die zeggen nu een 2001:1c00 adres te hebben gekregen of mensen die webserver beheren die ineens Ziggo IPv6 verkeer uit nieuwe regio's zien komen.

Zo lijken Den Haag en Zoetermeer aan te staan afgaand op dat soort meldingen.

[Roetzen]

Ik heb vandaag twee van mijn domeinen verhuisd van Starthosting naar een andere DNS provider. Reden: onvoldoende IPv6 support van Starthosting.

[Maurits van Baerle]

Roetzen schreef op woensdag 27 mei 2015 @ 16:49:
Ik heb vandaag twee van mijn domeinen verhuisd van Starthosting naar een andere DNS provider. Reden: onvoldoende IPv6 support van Starthosting.

Ik hoop dat je ze ook verteld hebt dat dat de reden is van de verhuizing? Dit soort bedrijven moet wel te horen krijgen dat ze klanten verliezen door achter te lopen anders blijft het een verhaal als "de klanten vragen niet om IPv6"...

[Roetzen]

O zeker heb ik ze dat verteld. En niet alleen dat ik dat verteld heb bij het afscheid, maar ik had het ook al maanden van te voren aangekondigd. Het enige wat ze aan IPv6 ondersteuning konden bieden was dat je via het support formulier kon vragen om toevoegen van een AAAA record. Dat deden ze dan handmatig. Soms duurde dat een paar dagen. Al rond Kerstmis had ik verteld dat ik dat niet goed genoeg vond and dat als ze niet voor 1 maart zorgden dat ik zelf via de hosting manager AAAA records kon toevoegen, dat ik dan als klant zou vertrekken. Ik heb ze nog bijna drie maanden extra gegeven, maar ze deden niks. Nu was mijn geduld op en dat heb ik ze verteld. Ik vind dat ik ze ruim de kans heb gegeven, maar het houdt echt een keer op.

[CAPSLOCK2000]

Mooi, laat het ze maar voelen waar het pijn doet.

Nu hier een gevalletje met en levancier die via een VPN-verbinding aan ons netwerk wordt gekoppeld. Het internet netwerk van die leverancier gebruikt helaas dezelfde RFC1918 range als dat VPN. Dat is niet handig. Nadat er van beide kanten een hoop was gevloekt en gescholden heb ik gezegd dat ze dan maar IPv6 moeten gebruiken maar daar stonden ze niet voor open Veel plezier met NATten.

[Roetzen]

CAPSLOCK2000 schreef op woensdag 27 mei 2015 @ 18:45:
Mooi, laat het ze maar voelen waar het pijn doet.

Ik weet niet of het ze veel pijn doet. Misschien doet het ze wel niet zo veel pijn. Ik ben maar een heel klein klantje, ik had twee domeinen bij ze ondergevracht. Meer dan een paar tientjes per jaar hebben ze nooit aan mij verdiend. Maar ja, vele kleintjes maken ook een grote natuurlijk.

[CAPSLOCK2000]

Dat je hier post dat je bent vertrokken is nog een extra prikje.

[Jerrythafast]

Dutch2007 schreef op woensdag 27 mei 2015 @ 12:03:
- Groningen
- Heerhugowaard
- Tilburg
- Zwolle

dat zijn iig momenteel de bekende regio's voor zowel de 320 als de 321 ubee modems..

Volgens mij alleen de EVW3200 en EVW321B. Je hebt ook nog een EVM3200, dat is een ouder modem zonder WiFi/routerfunctie.

Maurits van Baerle schreef op woensdag 27 mei 2015 @ 12:28:
Zo lijken Den Haag en Zoetermeer aan te staan afgaand op dat soort meldingen.

Ik lees dit inderdaad ook sinds een tijdje, maar gv-rc0052-cr102-xe-1-0-5-0.core.as9143.net is dat in ieder geval niet: ik krijg nog steeds geen IPv6 prefix.

[Roetzen]

CAPSLOCK2000 schreef op woensdag 27 mei 2015 @ 19:10:
Dat je hier post dat je bent vertrokken is nog een extra prikje.

Daar was het niet om begonnen. Natrappen hoeft nou ook weer niet en ik moet ze nagaven dat ze verder netjes meegewerkt hebben aan de verhuizing, En waarschijnlijk lezen ze hier toch niet mee, gezien het feit dat IPv6 bij hen kennelijk geen prioriteit heeft.

Het hier melden was meer bedoeld als aansporing aan anderen om het voorbeeld te volgen.

[Verwijderd]

Hoe het proces achter de metingen werkt is mij onbekend, maar even met de goede hoop dat de ISP's nieuwe informatie blijven aanleveren.

http://www.worldipv6launch.org/measurements/

Ziggo staat nu op 0.53%
KPN staat er helaas niet tussen.

[Maurits van Baerle]

Verwijderd schreef op donderdag 28 mei 2015 @ 07:49:
Hoe het proces achter de metingen werkt is mij onbekend, maar even met de goede hoop dat de ISP's nieuwe informatie blijven aanleveren.

http://www.worldipv6launch.org/measurements/

Ziggo staat nu op 0.53%
KPN staat er helaas niet tussen.

Het heeft even geduurd maar volgens mij begrijp ik nu hoe het werkt.

Volgens mij zit het als volgt in elkaar:
Ze werken op dit moment samen met vijf partners: Akamai, Facebook, Google, LinkedIn en Yahoo!. Dat waren er vroeger minder dus er kan er best af en toe nog eentje bij komen. Deze partners doen de feitelijke metingen.

Dan kunnen netwerkbeheerders hun eigen netwerk aanmelden door een naam, land, contact adres, en het AS nummer van hun netwerk(en) op te geven. Daarna hoeven zij niets meer te doen.

De vijf partners kijken dan naar al het verkeer dat zij hebben met gebruikers uit de deelnemende AS(-en) en meten hoeveel procent daarvan over IPv6 binnen komt. Dan wordt er waarschijnlijk een gemiddelde genomen van de hele afgelopen maand en dit wordt gepubliceerd in de tweede week van iedere maand.

Aangezien de vijf partners redelijk breed zijn en een flink deel van het internationale internet verkeer ontvangen kan het een redelijke indicatie geven van hoe groot het IPv6 verkeer afkomstig van dat netwerk is (en als afgeleide hoeveel hosts op dat netwerk IPv6 gebruiken). De 0,53% van Ziggo is waarschijnlijk voor een deel gemeten voordat er meer klanten waren aangesloten dus bij de resultaten van volgende maand zal het waarschijnlijk een redelijke sprong hebben gemaakt.

Kortom, een KPN netwerkbeheerder moet AS1136 even aanmelden. Daarna hoeven ze niets meer te doen en verschijnen ze een maand of wat later in de statistieken.

[databeestje]

De eerste KPN klant gesignaleerd uit 2001:0838::/29, daarnaast 2 van de Ziggo prefix, 1 Solcon en de rest Xs4all.

[Verwijderd]

Roetzen schreef op woensdag 27 mei 2015 @ 16:49:
Ik heb vandaag twee van mijn domeinen verhuisd van Starthosting naar een andere DNS provider. Reden: onvoldoende IPv6 support van Starthosting.

Je zou verwachten dat de webhosters hierin voorop lopen, maar helaas zie ik nog dagelijks webhosters die geen IPv6 ondersteuning aanbieden.

[Maurits van Baerle]

databeestje schreef op donderdag 28 mei 2015 @ 11:46:
De eerste KPN klant gesignaleerd uit 2001:0838::/29,

Volgens mij moeten de klanten van deze laatste pilot uit 2a02:a440::/26 komen. Ik denk dat je Telfort verkeer hebt gemeten.

daarnaast 2 van de Ziggo prefix

Zitten er nog gemeenten tussen waarvan we niet wisten dat ze al aangesloten waren?

[ Voor 27% gewijzigd door Maurits van Baerle op 28-05-2015 11:55 ]

[Verwijderd]

Maurits van Baerle schreef op donderdag 28 mei 2015 @ 11:49:
Zitten er nog gemeenten tussen waarvan we niet wisten dat ze al aangesloten waren?

Niet bij mij, heb wel uit de bekende regios diverse -tientallen- bezoekers gehad (Groningen, Tilburg, Zwolle) heb er nog specifiek naar gezocht om nieuwe regios te ontdekken.

[easyriider]

Verwijderd schreef op donderdag 28 mei 2015 @ 07:49:

http://www.worldipv6launch.org/measurements/

Ziggo staat nu op 0.53%
KPN staat er helaas niet tussen.

Van 13 mei, dus de resultaten worden niet vaak geactualiseerd.

Heb je een bepaalde website waar je het IPv6 bezoek meet?

[ Voor 9% gewijzigd door easyriider op 28-05-2015 12:51 ]

[Maurits van Baerle]

easyriider schreef op donderdag 28 mei 2015 @ 12:48:
[...]

Van 13 mei, dus de resultaten worden niet vaak geactualiseerd.

Eén keer per maand om precies te zijn.

[Snow_King]

Maurits van Baerle schreef op donderdag 28 mei 2015 @ 11:49:
[...]

Volgens mij moeten de klanten van deze laatste pilot uit 2a02:a440::/26 komen. Ik denk dat je Telfort verkeer hebt gemeten.

[...]

Zitten er nog gemeenten tussen waarvan we niet wisten dat ze al aangesloten waren?

Ik ben weer even aan tracen. Ik zie:

* zl-lc0003-ubr001-te0-0-0-201.core.as9143.net (?)
* gn-lc0002-ubr006-te0-1-0-202.core.as9143.net (Groningen)
* tb-rc0001-ubr053-te0-0-1.core.as9143.net (Tilburg)
* hhw-lc0001-ubr002-te0-0-0-209.core.as9143.net (Heer Hugo Waard)

[Maurits van Baerle]

Ik neem aan dat 'zl' Zwolle is.

[Verwijderd]

Maurits van Baerle schreef op donderdag 28 mei 2015 @ 12:53:
Ik neem aan dat 'zl' Zwolle is.

Correct, het meeste komt overeen met http://www.actw.nl/kpn%20nummercentrales.htm

Ik zag op twitter dat er wat afwijkende zijn: HLO (Heillo) en VNN (vermoedelijk Velsen Noord)

[easyriider]

Een tracert naar Heerhugowaard:

  2     7 ms     7 ms     6 ms  ipv6.dynamic.ziggo.nl [2001:1c00:1010::1]
  3     8 ms     7 ms     7 ms  zl-rc0001-cr102-irb-202.core.as9143.net [2001:b88:0:9fd::1]
  4     9 ms     8 ms     8 ms  asd-tr0610-cr101-ae3-0.core.as9143.net [2001:b88:0:10d::1]
  5    10 ms    10 ms     9 ms  hlo-rc0001-cr102-ae0-0.core.as9143.net [2001:b88:0:110::2]
  6    13 ms     7 ms     8 ms  hhw-lc0001-ubr002-te0-0-0-209.core.as9143.net [2001:b88:0:cfe::3]

[CAPSLOCK2000]

Ik voel me een oude zeikerd en een rupsje-nooit-genoeg maar ik baal van "ipv6.dynamic.ziggo.nl" . Zo komen we nooit meer van het éénrichtingsverkeer op internet af.

[databeestje]

Wel, de reverse DNS is dynamisch gegenereerd aangezien een reverse DNS aanmaken per host zoals we dat voor IPv4 ookwel deden volkomen onwerkbaar is.

Meerder DNS servers hebben nu de mogelijkheid voor een standaard resultaat waar je later een specifiek adres kan bijvoegen voor hosts met RDNS.

[CyBeR]

Ja dat heet wildcard dns. Reverse maar 's een zakelijk kpn IP.

[ShadowLord]

Als ON klant (OnsBrabantNet, maar dan in Eindhoven ) gebruik ik nu al een maand IPv6 via hun 6rd oplossing (https://www.on.nl/IPV6/) in combinatie met mijn Asus router.
Voor IPv4 heb ik een vast IP bij ON en dus (als ik goed begrijp hoe 6rd werkt) een vaste prefix.

Wat ik niet helemaal volg is hoe mijn apparaten een IPv6 adres toegewezen krijgen. Ik kan op mijn router geen DHCP instellingen doen voor IPv6. Komen deze IP's dan direct van mijn provider? Of doet mijn router de toewijzing automatisch zonder mij hierover controle te geven?
De reden dat ik dit vraag is omdat ik graag mijn thuisserver een vast IPv6 adres geef zodat ik eenmalig een DNS verwijzing kan maken hiernaar zonder moeilijk te hoeven doen met dynamische DNS oplossingen.

[CyBeR]

Dat gebeurt met SLAAC aan de hand van je MAC-adres.

[easyriider]

Mijn aangesloten apparaten hebben twee IPv6 adressen, één is gebaseerd op het MAC-adres, de andere een tijdelijk adres waarbij de laatste 64 bits geheel willekeurig zijn en dat adres veranderd iedere dag. Alleen met dat tijdelijke adres ben ik zichtbaar op internet.

[Verwijderd]

Ik zie nu IPv6 verkeer van KPN uit Overijssel komen:
2a02:a400::

[Jaap-Jan]

En om even verder te borduren op CyBeR en easyriider: op zich veranderd dat SLAAC- adres niet zolang je je MAC- adres niet veranderd (MAC- adres spoofing of een andere netwerkkaart), maar je kunt ook wel een statisch IPv6- adres instellen als je dat liever hebt.

[ Voor 10% gewijzigd door Jaap-Jan op 28-05-2015 19:52 ]

[Maurits van Baerle]

Nou ja, het mooiste is waarschijnlijk zowel een statisch als een SLAAC adres. Zoals easyriider dat heeft.

De diensten die dan op je server draaien laat je dan alleen luisteren op dat statisch adres (dat moet wel in te stellen zijn). Al het andere verkeer doe je via je SLAAC adres.

[eymey]

databeestje schreef op donderdag 28 mei 2015 @ 13:38:
Wel, de reverse DNS is dynamisch gegenereerd aangezien een reverse DNS aanmaken per host zoals we dat voor IPv4 ookwel deden volkomen onwerkbaar is.

Meerder DNS servers hebben nu de mogelijkheid voor een standaard resultaat waar je later een specifiek adres kan bijvoegen voor hosts met RDNS.

Weet je toevallig een DNS hosting dienst waar je zo'n "standaard resultaat" kan instellen?

Ik heb de DNS voor 1 van mijn domains nu onder gebracht bij he.net. Op zich spartaanse maar wel complete interface waar je nagenoeg alles kan instellen, maar reverse DNS voor bv. je eigen /48 bij he.net lijkt een crime te zijn, omdat het eigenlijk bijna alleen maar per IP te doen is.

[ShadowLord]

Jaap-Jan schreef op donderdag 28 mei 2015 @ 19:52:
En om even verder te borduren op CyBeR en easyriider: op zich veranderd dat SLAAC- adres niet zolang je je MAC- adres niet veranderd (MAC- adres spoofing of een andere netwerkkaart), maar je kunt ook wel een statisch IPv6- adres instellen als je dat liever hebt.

Maar ik neem aan dat ik niet een random IPv6 adres kan pakken toch? Of is alles binnen mijn /56 subnet vrij te kiezen? Ik wil voorkomen dat ik een adres pak wat later ineens een conflict heeft met een nieuw apparaat.

[ Voor 9% gewijzigd door ShadowLord op 28-05-2015 22:14 ]

[CAPSLOCK2000]

Alles binnen jouw subnet is van jou en mag je vrij gebruiken zoals je wil. Als je een adres willekeurig kiest is de kans dat je er eentje dubbel neemt zo gigantisch klein dat het haast onmogelijk is. Voor het adres in gebruik wordt genomen hoort je OS overigens nog even te checken of het ook echt vrij is maar ik weet niet of alle OS'en dat ook echt doen. Linux in ieder geval wel.

Overigens is het gebruikelijk om de adresruimte in subnetten van /64 op te hakken. Je moet dan wel het juiste subnet gebruiken maar dat is eigenlijk niet anders dan bij IPv4.

Helaas zijn er een aantal veel gebruikte routers die alleen het eerste subnet doorrouten.

Samengevat is het zeer waarschijnlijk dat je het eerste subnet van /64 in jouw /56 moet gebruiken.

[CyBeR]

ShadowLord schreef op donderdag 28 mei 2015 @ 22:13:
[...]

Maar ik neem aan dat ik niet een random IPv6 adres kan pakken toch? Of is alles binnen mijn /56 subnet vrij te kiezen? Ik wil voorkomen dat ik een adres pak wat later ineens een conflict heeft met een nieuw apparaat.

Lekker SLAAC gebruiken. Is simpel en (binnen je prefix) statisch. En mocht je prefix toch veranderen dan verandert 't automatisch mee.

[ShadowLord]

CyBeR schreef op vrijdag 29 mei 2015 @ 03:43:
[...]


Lekker SLAAC gebruiken. Is simpel en (binnen je prefix) statisch. En mocht je prefix toch veranderen dan verandert 't automatisch mee.

Als het SLAAC adres statisch is zolang ik dezelfde machine blijf gebruiken (m'n prefix is statisch) dan lijkt me dat inderdaad het makkelijkste. De DNS updaten wanneer ik nieuwe hardware koop is een kleine moeite

Nu alleen de firewall van de router aanpassen dat hij het IPv6 van de server ook naar buiten open zet, dan kan ik de DNS van mijn domein ook updaten zodat ik naast 'ipv6.[domein].com' er ook via de normale adressen bij kan

CAPSLOCK2000 schreef op vrijdag 29 mei 2015 @ 00:31:
Alles binnen jouw subnet is van jou en mag je vrij gebruiken zoals je wil. Als je een adres willekeurig kiest is de kans dat je er eentje dubbel neemt zo gigantisch klein dat het haast onmogelijk is.

Maar er is dus geen 'gereserveerd' deel binnen het eigen /64 subnet waar je statische toewijzingen kan doen zonder bang te zijn dat er een dynamische (zoals SLAAC) overheen komt?

[Hipska]

ShadowLord schreef op vrijdag 29 mei 2015 @ 10:15:
Maar er is dus geen 'gereserveerd' deel binnen het eigen /64 subnet waar je statische toewijzingen kan doen zonder bang te zijn dat er een dynamische (zoals SLAAC) overheen komt?

Niet echt, maar SLAAC heeft altijd FF:FE in het midden van het hostgedeelte zitten. Zie Wikipedia: IPv6 address

[Jaap-Jan]

ShadowLord schreef op vrijdag 29 mei 2015 @ 10:15:
[...]

Als het SLAAC adres statisch is zolang ik dezelfde machine blijf gebruiken (m'n prefix is statisch) dan lijkt me dat inderdaad het makkelijkste. De DNS updaten wanneer ik nieuwe hardware koop is een kleine moeite

Nu alleen de firewall van de router aanpassen dat hij het IPv6 van de server ook naar buiten open zet, dan kan ik de DNS van mijn domein ook updaten zodat ik naast 'ipv6.[domein].com' er ook via de normale adressen bij kan


[...]

Maar er is dus geen 'gereserveerd' deel binnen het eigen /64 subnet waar je statische toewijzingen kan doen zonder bang te zijn dat er een dynamische (zoals SLAAC) overheen komt?

Het 6e bit (van links gezien) is het universal/ local bit en wordt wordt altijd op 1 gezet bij het genereren van een adres uit het MAC- adres, dus als het tweede teken van het adres (niet de prefix, maar de identifier) geen (2, 3, 6, 7, A, B, E or F) is zit je veilig. Ook zijn de middelste 4 tekens van de identifier altijd FF:FE.

Zie: http://www.tcpipguide.com...sicalAddressMapping-2.htm.

Dit is de complexe technische uitleg. De praktische uitleg is: gebruik simpele adressen als 2001:xxxx:yyyy:zzzz::1 en je zit safe.

[easyriider]

Hipska schreef op vrijdag 29 mei 2015 @ 10:33:
[...]


Niet echt, maar SLAAC heeft altijd FF:FE in het midden van het hostgedeelte zitten. Zie Wikipedia: IPv6 address

Alleen als het MAC-adres gebruikt wordt, maar bij privacy extensions wat standaard is bij Windows, Android en iOS kan een random adres gelijk zijn aan een statisch adres.

http://www.internetsociet...xtensions-for-ipv6-slaac/

Een host met statisch adres kan offline zijn terwijl een andere host een random adres krijgt waarbij die dus niet kan constateren dat het adres al gebruikt wordt. Als die host vervolgens wordt ingeschakeld kunnen ze, hoewel de kans nihil is, beide hetzelfde adres hebben.

[Maurits van Baerle]

Jaap-Jan schreef op vrijdag 29 mei 2015 @ 10:37:
Dit is de complexe technische uitleg. De praktische uitleg is: gebruik simpele adressen als 2001:xxxx:yyyy:zzzz::1 en je zit safe.

Hoewel uitgerekend een adres eindigend in ::1 niet zo handig is. Dat is het loopback adres.

[ Voor 57% gewijzigd door Maurits van Baerle op 29-05-2015 12:19 ]

[Jaap-Jan]

Maurits van Baerle schreef op vrijdag 29 mei 2015 @ 12:17:
[...]


Hoewel uitgerekend een adres eindigend in ::1 niet zo handig is. Dat is het loopback adres.

Dat zeg je verkeerd. ::1/128 is het loopback adres.

[joopv]

Mijn Usenet provider is over aan het gaan naar IPv6. Hoera, maar niet echt want deze gigabytes bulk traffic gaat nu door mijn SixXs tunnel en dat is niet goed voor de troughput (10Mbit ipv 100Mbit). Het lijkt me ook niet echt de bedoeling van de tunnelprovider om er bulk data overheen te pompen.
Dus moet ik daar een workaround voor zien te verzinnen. Iemand een idee?

Mijn IPv6 tunnel wordt opgebouwd vanaf mijn cisco router, voor de hosts binnenshuis is er niets speciaals ingeregeld dus.

[Ximon]

Usenet client instellen zodat deze alleen IPv4 gebruikt?

Overigens heeft Leasenet geen issue met meer dan 10 Mbit/s bandbreedte (zie maximum inbound):


Misschien staan ze alleen hogere bandbreedte in burst toe? Ik kon in ieder geval niet zo snel een policy vinden hierover.

[ Voor 27% gewijzigd door Ximon op 29-05-2015 13:04 ]

[Orion84]

Ik haal over mijn sixxs tunnel echt wel meer dan 10 mbit. Wellicht verschilt dit nog per PoP, maar de surfnet PoP die ik gebruik geeft volgens mij gewoon minstens 100mbit door.

[easyriider]

Het IPv6 verkeer bij Akamai afkomstig van Ziggo. In April is de eerste groep ingeschakeld, in mei meer dan verdubbeld. Dus zal in juni wel weer een grote uitbreiding plaatsvinden denk ik.

http://www.stateoftheinte...-country-growth-data.html

[St00mwals]

easyriider schreef op vrijdag 29 mei 2015 @ 14:13:
[afbeelding]

Het IPv6 verkeer bij Akamai afkomstig van Ziggo. In April is de eerste groep ingeschakeld, in mei meer dan verdubbeld. Dus zal in juni wel weer een grote uitbreiding plaatsvinden denk ik.

http://www.stateoftheinte...-country-growth-data.html

Wel typisch dat de grafiek iets daalt naarmate de maand vordert....

Wat is KPN aan het doen dan? IPv6 aan het uitzetten, ipv uitrollen???


En UPC is ineens heel hard aan het rollen, 8%

[Snow_King]

St00mwals schreef op vrijdag 29 mei 2015 @ 14:49:
[...]


En UPC is ineens heel hard aan het rollen, 8%
[afbeelding]

Vergeet niet dat UPC óók in het buitenland op veel plaatsen actief is zoals Oostenrijk en Tsjechië.

XS4All doet het met 55% dan bijvoorbeeld véél beter. ZeelandNet zit inmiddels op een 4.2%. Ook niet heel slecht, maar kan veel beter.

[CAPSLOCK2000]

easyriider schreef op vrijdag 29 mei 2015 @ 12:17:
Een host met statisch adres kan offline zijn terwijl een andere host een random adres krijgt waarbij die dus niet kan constateren dat het adres al gebruikt wordt. Als die host vervolgens wordt ingeschakeld kunnen ze, hoewel de kans nihil is, beide hetzelfde adres hebben.

Het is theoretisch mogelijk maar het is toch wel zo enorm onwaarschijnlijk dat je je beter zorgen kan maken over de kans dat je server door de bliksem wordt getroffen.

joopv schreef op vrijdag 29 mei 2015 @ 12:50:
Mijn Usenet provider is over aan het gaan naar IPv6. Hoera, maar niet echt want deze gigabytes bulk traffic gaat nu door mijn SixXs tunnel en dat is niet goed voor de troughput (10Mbit ipv 100Mbit).

Misschien eens van endpoint wisselen. Mijn tunnel deed probleemloos 180Mbit.

Het lijkt me ook niet echt de bedoeling van de tunnelprovider om er bulk data overheen te pompen.

Jawel hoor, dat mag en ze vinden het zelfs leuk. Op hun website roepen ze iedereen op om er zo veel mogelijk data door heen te pompen.

[ Voor 36% gewijzigd door CAPSLOCK2000 op 29-05-2015 15:10 ]

[St00mwals]

Snow_King schreef op vrijdag 29 mei 2015 @ 14:56:
[...]

Vergeet niet dat UPC óók in het buitenland op veel plaatsen actief is zoals Oostenrijk en Tsjechië.

Oh ja, natuurlijk...

[Dutch2007]

het zijn nu trouwens ~16000 abonnees ipv6..

volgens ziggo zit daar den haag en die andere regio niet bij...

[Jerrythafast]

Zo te zien zetten ze steeds op de eerste van de maand een nieuwe regio aan. Ik zal morgen eens kijken of er beweging in zit hier in de regio

[Verwijderd]

Dutch2007 schreef op zondag 31 mei 2015 @ 15:32:
het zijn nu trouwens ~16000 abonnees ipv6..

volgens ziggo zit daar den haag en die andere regio niet bij...

Het lijkt me stug dat ze met hun deployment met een marginaal getal van 2000 aansluitingen verhogen, waar zijn deze cijfers op gebaseerd?

[Dutch2007]

Ik heb wat navraag gedaan ;-)

Een van de voordelen van de helpdesk zullen we maar zeggen

[easyriider]

Misschien gaat het om een toename van 16000 abonnees in plaats van een stijging tot 16000.

[Dutch2007]

easyriider schreef op maandag 01 juni 2015 @ 11:55:
Misschien gaat het om een toename van 16000 abonnees in plaats van een stijging tot 16000.

Goeiemiddag ,

We hebben antwoord van de kenniseigenaar van dit onderwerp.
IPv6 is nog niet beschikbaar in Den Haag en Zoetermeer. We hebben sinds deze week circa 16.000 klanten actief op IPv6. Het kan wel zo zijn dat de klant al in de Ubee-modems de functionaliteit van IPv6 ziet, maar dat is nog niet geactiveerd.

Hopelijk heb je voldoende aan dit antwoord.

Groeten,
xxxxx

Dus +- 16000 totaal niet d'r bij..

zag wel een aantal technicolor modems rond assen die ipv6 aan hadden staan trouwens..

[CyBeR]

blaat. wil ik twee load balancers een ip laten delen met uCARP, blijkt dat nog steeds geen IPv6 te ondersteunen.

keepalived dan maar.

[Jerrythafast]

Nou, zoals beloofd heb ik het geprobeerd. Modemrouter gereset. Geen IPv6. Buh. Volgende maand nieuwe ronde nieuwe kansen

[ Voor 22% gewijzigd door Jerrythafast op 01-06-2015 22:40 ]

[CAPSLOCK2000]

Even de helpdesk bellen en klagen dat je IPv6 niet werkt, dan kunnen ze alvast een beetje wennen.

[Snow_King]

CyBeR schreef op maandag 01 juni 2015 @ 20:30:
blaat. wil ik twee load balancers een ip laten delen met uCARP, blijkt dat nog steeds geen IPv6 te ondersteunen.

keepalived dan maar.

Dat heb ik 3 jaar geleden nog in keepalived laten inbouwen

CAPSLOCK2000 schreef op maandag 01 juni 2015 @ 23:54:
Even de helpdesk bellen en klagen dat je IPv6 niet werkt, dan kunnen ze alvast een beetje wennen.

De ZeelandNet helpdesk snapt ook nog weinig van IPv6 helaas. Ze dachten laatst dat ik het had over een 'vast IP-adres'. Achja.

[Jeroen_R]

easyriider schreef op vrijdag 29 mei 2015 @ 14:13:
[afbeelding]

Het IPv6 verkeer bij Akamai afkomstig van Ziggo. In April is de eerste groep ingeschakeld, in mei meer dan verdubbeld. Dus zal in juni wel weer een grote uitbreiding plaatsvinden denk ik.

http://www.stateoftheinte...-country-growth-data.html

Jerrythafast schreef op zondag 31 mei 2015 @ 19:32:
Zo te zien zetten ze steeds op de eerste van de maand een nieuwe regio aan. Ik zal morgen eens kijken of er beweging in zit hier in de regio

Volgens mij is rond 1 mei niet een nieuwe regio aangezet, maar werd de IPv6 firmware voor de Ubee EVW320 uitgebracht.

[ Voor 40% gewijzigd door Jeroen_R op 04-06-2015 12:12 ]

[CAPSLOCK2000]

Iemand nog nieuwe regio's gespot sinds 1 juni?
De AMSIX lijkt weer een tikke meer IPv6 te zien maar het verschil is zo klein dat het ook natuurlijke variatie kan zijn.

[Verwijderd]

CAPSLOCK2000 schreef op donderdag 04 juni 2015 @ 17:51:
Iemand nog nieuwe regio's gespot sinds 1 juni?
De AMSIX lijkt weer een tikke meer IPv6 te zien maar het verschil is zo klein dat het ook natuurlijke variatie kan zijn.

In welke IPv6 prefixes is Ziggo op dit moment actief? Dan zal ik eens kijken in de logs.

[CAPSLOCK2000]

Ziggo gebruikt 2001:67c:1b9c::/48, 2001:b88::/33, 2001:1c00::/23, 2001:41f0::/32.
KPN gebruikt 2a02:a400::/25, 2a02:a400::/26, 2a02:a407:fffc::/48, 2a02:a407:fffd::/48, 2a02:a440::/26

We weten niet hoe die ranges precies gebruikt worden al geeft de grote wel een idee. Zo'n /48 is te klein om veel klanten te bevaten, daar zal de /23 wel voor zijn. 2001:b88::/33 lijkt te worden gebruikt door de apparatuur van Ziggo zelf.

Voor ons is het interresant om te achterhalen uit welke regio's de gebruikers komen. Als je een traceroute doet naar zo'n adres kun je aan de hostnames van de gebruikte adressen zien waar ze vandaan komen.


Snowking gaf eerder het volgende lijstje:
* zl-lc0003-ubr001-te0-0-0-201.core.as9143.net (Zwolle)
* gn-lc0002-ubr006-te0-1-0-202.core.as9143.net (Groningen)
* tb-rc0001-ubr053-te0-0-1.core.as9143.net (Tilburg)
* hhw-lc0001-ubr002-te0-0-0-209.core.as9143.net (Heer Hugo Waard)

[easyriider]

Verwijderd schreef op donderdag 04 juni 2015 @ 18:21:
[...]

In welke IPv6 prefixes is Ziggo op dit moment actief? Dan zal ik eens kijken in de logs.

Volgens tcpiputils.com:

2001:67c:1b9c::/48 Gemeente Breda
2001:b88::/33 Ziggo B.V.
2001:1c00::/23 Ziggo Consumers
2001:41f0::/32 Day by day bv

http://www.tcpiputils.com/browse/as/9143

[Maurits van Baerle]

Volgens mij wisten we al zeker dat alle adressen voor Ziggo consumenten uit 2001:1c00::/23 komen. Alle tot nu toe gerapporteerde adressen beginnen ook met 2001:1c00.

Qua KPN is het iets onduidelijker hoewel dat waarschijnlijk 2a02:a440::/26 is. Die klant uit het KPN forum had ook een blok uit die range.

[ Voor 38% gewijzigd door Maurits van Baerle op 04-06-2015 19:54 ]

[Verwijderd]

CAPSLOCK2000 schreef op donderdag 04 juni 2015 @ 18:45:
Ziggo gebruikt 2001:67c:1b9c::/48, 2001:b88::/33, 2001:1c00::/23, 2001:41f0::/32.
KPN gebruikt 2a02:a400::/25, 2a02:a400::/26, 2a02:a407:fffc::/48, 2a02:a407:fffd::/48, 2a02:a440::/26

We weten niet hoe die ranges precies gebruikt worden al geeft de grote wel een idee. Zo'n /48 is te klein om veel klanten te bevaten, daar zal de /23 wel voor zijn. 2001:b88::/33 lijkt te worden gebruikt door de apparatuur van Ziggo zelf.

Voor ons is het interresant om te achterhalen uit welke regio's de gebruikers komen. Als je een traceroute doet naar zo'n adres kun je aan de hostnames van de gebruikte adressen zien waar ze vandaan komen.


Snowking gaf eerder het volgende lijstje:
* zl-lc0003-ubr001-te0-0-0-201.core.as9143.net (Zwolle)
* gn-lc0002-ubr006-te0-1-0-202.core.as9143.net (Groningen)
* tb-rc0001-ubr053-te0-0-1.core.as9143.net (Tilburg)
* hhw-lc0001-ubr002-te0-0-0-209.core.as9143.net (Heer Hugo Waard)

Helaas Voor Ziggo heb ik nog geen onbekende plaatsen zien binnenkomen (enkel degene die hier al bekend zijn).

Van KPN zie ik helemaal niets heel weinig binnenkomen.

De logs zijn echter alleen maar van vandaag, ik zal het morgenavond dus nog eens checken

[Jerrythafast]

Jeroen_R schreef op donderdag 04 juni 2015 @ 12:08:
[...]


[...]


Volgens mij is rond 1 mei niet een nieuwe regio aangezet, maar werd de IPv6 firmware voor de Ubee EVW320 uitgebracht.

Oohja, dat zou natuurlijk ook nog kunnen. Nouja, dan moeten we maar gewoon afwachten of ze d'r nog aan denken nieuwe regio's aan te zetten

[easyriider]

Bij State of the internet zijn vandaag de IPv6 cijfers weer geactualiseerd. Ziggo is sinds de laatste week van mei omhoog gegaan van 0.4 naar 0.6 procent. Als er niet een nieuwe groep abonnees is ingeschakeld komt het misschien doordat de Technicolor modems een update naar IPv6 hebben gekregen.

http://www.stateoftheinte...growth-data.html#networks

[CAPSLOCK2000]

Allemaal een fijne IPv6-dag!


editEn niemand die even zegt dat ik een dag te laat ben

[ Voor 56% gewijzigd door CAPSLOCK2000 op 08-06-2015 18:48 ]

[Maurits van Baerle]

CAPSLOCK2000 schreef op zondag 07 juni 2015 @ 18:39:
Allemaal een fijne IPv6-dag!


editEn niemand die even zegt dat ik een dag te laat ben

Ha ha, ik dacht het wel aangezien de zesde dag van de zesde maand veel logischer leek maar dacht dat ik het wel fout zou hebben. Desondanks, het helpt niet dat het dit jaar in een weekend viel als het voornamelijk bedrijven zijn die IPv6 Day moeten trekken.

[CAPSLOCK2000]

Historisch gezien was het nog niet eens zo heel gek. In 2011 was het daadwerkelijk op 8 juni.

[CyBeR]

Je liet mij denken dat 't 6 juni was juist, was me niet opgevallen

[Verwijderd]

Er was een world IPv6 launch, testen 24 uur daarna uit en reviewen (8 juni 2011) en een world IPv6 day (6 juni 2012) aanzetten en aanlaten.

Vandaag is er weer een > http://www.internetsociet...aunch-day-on-9-june-2015/

[ Voor 12% gewijzigd door Verwijderd op 09-06-2015 05:53 ]

[Verwijderd]

CAPSLOCK2000 schreef op zondag 07 juni 2015 @ 18:39:
Allemaal een fijne IPv6-dag!


editEn niemand die even zegt dat ik een dag te laat ben

Ipv6 day was op 8 juni, dus eigenlijk was je te vroeg. Ik nam maar even aan dat je misschien op 8 juni het niet kon plaatsen

Je was idd te laat. Ik blijf ook day en launch day door elkaar halen.

[ Voor 10% gewijzigd door Verwijderd op 09-06-2015 05:56 ]

[Freee!!]

CAPSLOCK2000 schreef op zondag 07 juni 2015 @ 18:39:
Allemaal een fijne IPv6-dag!


editEn niemand die even zegt dat ik een dag te laat ben

Nee, niemand die het (direct) zegt, maar genoeg die het wel gezien hebben (en je niet direct af wilden zeiken).

[CAPSLOCK2000]

Verwijderd schreef op dinsdag 09 juni 2015 @ 05:52:
Er was een world IPv6 launch, testen 24 uur daarna uit en reviewen (8 juni 2011) en een world IPv6 day (6 juni 2012) aanzetten en aanlaten.

Vandaag is er weer een > http://www.internetsociet...aunch-day-on-9-june-2015/

Ah, ik was dus gewoon te vroeg
Ik zit vandaag in een kantoor met IPv6 dus ik kan mooi meedoen.
De treinreis ernaartoe zal wel een uitdaging worden maar dan kan ik weer eens met tunnels spelen.

Zoals ik het me herinner was het in 2011 overigens niet de bedoeling om IPv6 weer uit te zetten. Dat hebben ze er achteraf bij verzonnen toen bleek dat allerlij partijen het inderdaad weer uit hadden gezet en toen deed men maar of dat altijd al de bedoeling was geweest.

Freee!! schreef op dinsdag 09 juni 2015 @ 08:42:
Nee, niemand die het (direct) zegt, maar genoeg die het wel gezien hebben (en je niet direct af wilden zeiken).

Ik zou jullie er nooit mee weg laten komen

[ Voor 31% gewijzigd door CAPSLOCK2000 op 09-06-2015 08:54 ]

[St00mwals]

Verwijderd schreef op dinsdag 09 juni 2015 @ 05:52:
Er was een world IPv6 launch, testen 24 uur daarna uit en reviewen (8 juni 2011) en een world IPv6 day (6 juni 2012) aanzetten en aanlaten.

Vandaag is er weer een > http://www.internetsociet...aunch-day-on-9-june-2015/

Nou KPN, Ziggo en de rest:
Kom d'r maar in met IPv6

[Verwijderd]

St00mwals schreef op dinsdag 09 juni 2015 @ 10:31:
[...]
Nou KPN, Ziggo en de rest:
Kom d'r maar in met IPv6

Ziggo en KPN zijn bezig met een uitrol. Misschien niet in het tempo dat we graag hadden gezien maar mogelijk zijn er zaken ontdekt die ze eerst willen oplossen.

[St00mwals]

Verwijderd schreef op dinsdag 09 juni 2015 @ 10:34:
[...]


Ziggo en KPN zijn bezig met een uitrol. Misschien niet in het tempo dat we graag hadden gezien maar mogelijk zijn er zaken ontdekt die ze eerst willen oplossen.

Klopt, maar het is dan toch wel een mooie dag om IPv6 voor een nieuw/ander model modem aan te zetten of er weer een regio aan toe te voegen.

Zou op zich wel graag meer info willen van Ziggo of KPN hoe het gaat bij de regio's waar IPv6 aan staat. Zijn er veel problemen, bellen klanten vaker of gaat alles juist helemaal goed en merkt niemand iets??

[Osiris]

St00mwals schreef op dinsdag 09 juni 2015 @ 10:31:
[...]

Nou KPN, Ziggo en de rest:
Kom d'r maar in met IPv6

Tsktsk, vergeten we provider nr. uno, XS4ALL, nu alweer?

Sinds jaren native IPv6 op hun consumentenlijnen..

[CAPSLOCK2000]

So far so good, de curusleider knipperde niet eens met z'n ogen toen ik om een IPv6-adres vroeg voor de oefenomgeving

Grumble, m'n eigen webmail heeft nog geen IPv6

(ik maak er maar een live-blog van

Software stack geinstalleerd, ip-adressen aangepast om alleen IPv6 te binden en het werkt gewoon.
* CAPSLOCK2000 is tevreden

Nu moet ik herokuapp.com bezoeken maar die doet nog geen IPv6. Dan maar heel snel het voorbeeld van de sheet overtikken.

[ Voor 66% gewijzigd door CAPSLOCK2000 op 09-06-2015 11:45 ]

[Maurits van Baerle]

St00mwals schreef op dinsdag 09 juni 2015 @ 10:40:
[...]
Zou op zich wel graag meer info willen van Ziggo of KPN hoe het gaat bij de regio's waar IPv6 aan staat. Zijn er veel problemen, bellen klanten vaker of gaat alles juist helemaal goed en merkt niemand iets??

Ik vermoed dat dat precies is waar Ziggo op dit moment mee bezig is. Twee verschillende modems met een maand er tussen aangezet. Kijken wat voor vragen en problemen dat oplevert. Die kun je dan fixen, de helpdesk scripts aanpassen etc. Best kans dat ze eerst nog een of twee Cisco modellen aanzetten om te kijken wat die eventueel voor vragen en problemen opleveren.

Als ze dan in de huidige vier regio's een reeks modems hebben getest en goed gevonden zou het daarna vrij makkelijk kunnen zijn om nieuwe regio's toe te voegen.