Het grote IPv6 topic

[Maurits van Baerle]

Zeeland gaat voor IPv6! In 2014 gaan wij voor alle klanten IPv6 beschikbaar maken. Er zijn al een aantal pilots/tests uitgevoerd binnen de ISP en zakelijke omgeving en nu is het tijd voor de volgende stap.

Wil jij ook meedoen aan de deze pilot? Vanaf heden kun aangeven dat je mee wilt doen aan de dual-stack test!

** Bestaande 6RD testers krijgen 4 juni 2014 een bericht! **

Ik ben niet zo bekend met ZeelandNet. Hoe zit dit nou? Hebben ze al een 6RD pilot met wat testers er in die nu een pilot voor Native Dual Stack krijgen? Is de Dual Stack pilot ook open voor mensen die nu nog geen 6RD hebben?

[Snow_King]

Maurits van Baerle schreef op dinsdag 03 juni 2014 @ 12:31:
[...]

Ik ben niet zo bekend met ZeelandNet. Hoe zit dit nou? Hebben ze al een 6RD pilot met wat testers er in die nu een pilot voor Native Dual Stack krijgen? Is de Dual Stack pilot ook open voor mensen die nu nog geen 6RD hebben?

Ja, zo ongeveer. Als je echter contact op neemt met Martijn van Dorst dan kan hij je helpen. Zie die test pagina van ZeelandNet.

Hoe meer mensen er testen, hoe beter!

[Maurits van Baerle]

Ik begrijp het. Voor mij persoonlijk is het niet zo geschikt aangezien ik aan de verkeerde kant van de Noordzee zit Maar, ik ben altijd geïnteresseerd in NL ISP's die ook IPv6 implementeren.

[CAPSLOCK2000]

Raven schreef op dinsdag 03 juni 2014 @ 10:11:
[...]

Tsja, als je het zo bekijkt

Trouwens, hoe zit het met het openen van poorten in ip6tables (voor uTorrent/(S)FTP/etc) als je privacy extensions enabled hebt?

Privacy extensions zijn alleen voor uitgaande verbindingen. Voor inkomende verbindingen heb je een ander, vast, adres.

[Raven]

Snow_King schreef op dinsdag 03 juni 2014 @ 10:22:
[...]
Errr, dat is een goede.

Sowieso weet ik niet of uPNP al lekker werkt met IPv6.

Google levert iig niets nuttigs op, of ik zoek niet goed.

Overigens verschijnen er wel wat ipv6 peers in uTorrent, dus het lijkt niet perse nodig te zijn om een inkomende poort open te zetten. Al vraag ik mij wel af hoe dat kan, voor zover ik kan terugvinden is uPNP niet aanwezig in IPFire.

Snow_King schreef op dinsdag 03 juni 2014 @ 10:22:
Ik kan in ieder geval niet wachten op IPv6 via ZeelandNet. Al onze 18 verbindingen krijgen nog deze maand native-IPv6

Ik ben allang blij dat de HE-tunnel die ik heb goed werkt, mocht Telfort ooit aan ipv6 gaan doen, dan kan ik gaan uitzoeken hoe ik de WAN-interface van IPFire zover kan krijgen dat ie een ipv6 adres accepteert. IPFire ondersteund namelijk out of the box geen ipv6 en ik ben allang blij dat ik een tunnel aan de gang heb weten te krijgen.

CAPSLOCK2000 schreef op dinsdag 03 juni 2014 @ 12:59:
[...]


Privacy extensions zijn alleen voor uitgaande verbindingen. Voor inkomende verbindingen heb je een ander, vast, adres.

Heb je daar toevallig details over?

[ Voor 11% gewijzigd door Raven op 03-06-2014 13:03 ]

[Paul]

Maar als uTorrent over PE naar buiten gaat dan probeert de andere kant naar datzelfde IP terug te verbinden lijkt me

[Raven]

Daar gaat het niet om, het gaat erom hoe je met privacy extensions een inkomende poort in ip6tables openzet naar een specifieke client

[ Voor 20% gewijzigd door Raven op 03-06-2014 13:13 ]

[Paul]

Daar gaat het wel om, het voorbeeld noemt specifiek uTorrent Als je zelf een SFTP-server opzet dan doe je dat uiteraard naar je permanente adres, maar bij torrent zet je niet 'zelf' een server op, torrent geeft door aan de trackers (of whatever) waarmee ze moeten verbinden. Het kan goed zijn dat het daarbij óók je permanente adres doorstuurt, maar bij dit soort UPNP-achtige tijdelijke poorten wil je natuurlijk je RFC 4941-adres gebruiken

[Raven]

Ik dacht dat je doelde op het veranderen van ipv6 adressen, hoe uTorrent daar mee omgaat. Terwijl ik doelde op hoe je in ip6tables een poort openzet (bijv. voor uTorrent inderdaad) terwijl de client geen vast ipv6 adres heeft, althans, ik dacht dus dat die geen vast adres had. Maar blijkbaar wel

[ Voor 13% gewijzigd door Raven op 03-06-2014 13:31 ]

[Osiris]

CAPSLOCK2000 schreef op dinsdag 03 juni 2014 @ 12:59:
[...]

Privacy extensions zijn alleen voor uitgaande verbindingen. Voor inkomende verbindingen heb je een ander, vast, adres.

Mjah, maar dan zou je iedere PC een non-SLAAC-IP moeten geven..

[Snow_King]

Raven schreef op dinsdag 03 juni 2014 @ 13:29:
Ik dacht dat je doelde op het veranderen van ipv6 adressen, hoe uTorrent daar mee omgaat. Terwijl ik doelde op hoe je in ip6tables een poort openzet (bijv. voor uTorrent inderdaad) terwijl de client geen vast ipv6 adres heeft, althans, ik dacht dus dat die geen vast adres had. Maar blijkbaar wel

Ja, met privacy extensions heb je ALTIJD een vast adres, maar daarnaast ook dynamische.

Op mijn laptop achter XS4All verbinding zie ik nu dit:

wlan0 Link encap:Ethernet HWaddr XX:XX:5a:80:fb:d8
inet addr:192.168.5.64 Bcast:192.168.5.255 Mask:255.255.255.0
inet6 addr: 2001:980:XXX:0:8e70:5aff:fe80:fbd8/64 Scope:Global
inet6 addr: fe80::8e70:5aff:fe80:fbd8/64 Scope:Link
inet6 addr: 2001:980:XXX:0:f94b:b9bd:3088:4a82/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:292161 errors:0 dropped:0 overruns:0 frame:0
TX packets:184771 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:283181622 (283.1 MB) TX bytes:28668927 (28.6 MB)

Zoals je kunt zien is 2001:980:XXX:0:8e70:5aff:fe80:fbd8 het adres wat gebaseerd is op mijn MAC-adres en 2001:980:XXX:0:f94b:b9bd:3088:4a82 is een tijdelijk adres.

Kijk ik met 'ip -6 addr list' dan zie ik:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:980:XX:0:f94b:b9bd:3088:4a82/64 scope global temporary dynamic
valid_lft 591674sec preferred_lft 72674sec
inet6 2001:980:XX:0:8e70:5aff:fe80:fbd8/64 scope global dynamic
valid_lft 2591981sec preferred_lft 604781sec
inet6 fe80::8e70:5aff:fe80:fbd8/64 scope link
valid_lft forever preferred_lft forever

Dat tijdelijke adres heeft een hogere prioriteit om mee naar buiten te verbinden, dus als ik naar Facebook of Google ga dan zien ze dat adres en net mijn 'vaste' adres.

Na een X periode genereert mijn kernel weer een nieuw tijdelijk adres wat dan de hoogste prioriteit naar buiten krijgt.

[Raven]

Ah okee. Maar als ik het goed begrijp, dan heeft het geen zin om het vaste adres in te vullen in een ip6tables forward regel omdat het tijdelijke adres gebruikt wordt met het verbinding maken?

Het vaste ipv6 adres op deze W7 pc heeft trouwens geen overeenkomsten met het mac-adres.

code:

C:\Users\Raven>ipconfig /all

Windows IP-configuratie

   Hostnaam  . . . . . . . . . . . . : EyesOnly
   Primair DNS-achtervoegsel . . . . :
   Knooppunttype . . . . . . . . . . : hybride
   IP-routering ingeschakeld . . . . : nee
   WINS-proxy ingeschakeld . . . . . : nee

Ethernet-adapter voor LAN-verbinding:

   Verbindingsspec. DNS-achtervoegsel:
   Beschrijving. . . . . . . . . . . : ******
   Fysiek adres. . . . . . . . . . . : **-**-**-5F-47-0B
   DHCP ingeschakeld . . . . . . . . : nee
   Autom. configuratie ingeschakeld  : ja
   IPv6-adres. . . . . . . . . . . . : ****:****:****:****:ac25:****:20b6:ad66(voorkeur)
   Tijdelijk IPv6-adres. . . . . . . : ****:****:****:****:10bd:****:4b35:4a85(voorkeur)
   Link-local IPv6-adres . . . . . . : fe80::****:****:****:ad66%11(voorkeur)
   IPv4-adres. . . . . . . . . . . . : 192.168.1.11(voorkeur)
   Subnetmasker. . . . . . . . . . . : 255.255.255.0
   Standaardgateway. . . . . . . . . : fe80::****:****:****:4970%11
                                       192.168.1.1
   DNS-servers . . . . . . . . . . . : 8.8.8.8
                                       8.8.4.4
   NetBIOS via TCPIP . . . . . . . . : ingeschakeld

C:\Users\Raven>

[Osiris]

Snow_King schreef op dinsdag 03 juni 2014 @ 13:59:
[...]
Ja, met privacy extensions heb je ALTIJD een vast adres, maar daarnaast ook dynamische.

Op mijn laptop achter XS4All verbinding zie ik nu dit:


[...]


Zoals je kunt zien is 2001:980:XXX:0:8e70:5aff:fe80:fbd8 het adres wat gebaseerd is op mijn MAC-adres en 2001:980:XXX:0:f94b:b9bd:3088:4a82 is een tijdelijk adres.

Kijk ik met 'ip -6 addr list' dan zie ik:


[...]


Dat tijdelijke adres heeft een hogere prioriteit om mee naar buiten te verbinden, dus als ik naar Facebook of Google ga dan zien ze dat adres en net mijn 'vaste' adres.

Na een X periode genereert mijn kernel weer een nieuw tijdelijk adres wat dan de hoogste prioriteit naar buiten krijgt.

En welk IP-adres gebruikt je uTorrent om te advertisen?

Het idee van die Privacy Extension is júist om géén MAC-adressen meer in je IP's op te nemen.. Dus dan moet je ook JUIST niet meer je SLAAC-IP's advertisen in programma's als uTorrent.

[ Voor 9% gewijzigd door Osiris op 03-06-2014 14:11 ]

[Snow_King]

Osiris schreef op dinsdag 03 juni 2014 @ 14:11:
[...]

En welk IP-adres gebruikt je uTorrent om te advertisen?

Helemaal mee eens Dat is je tijdelijke adres.

Osiris schreef op dinsdag 03 juni 2014 @ 14:11:
[...]
Het idee van die Privacy Extension is júist om géén MAC-adressen meer in je IP's op te nemen.. Dus dan moet je ook JUIST niet meer je SLAAC-IP's advertisen in programma's als uTorrent.

Duidelijk, alleen ik wil aan tonen dat het adres er wel degelijk is.

[Osiris]

Raven schreef op dinsdag 03 juni 2014 @ 14:09:
Ah okee. Maar als ik het goed begrijp, dan heeft het geen zin om het vaste adres in te vullen in een ip6tables forward regel omdat het tijdelijke adres gebruikt wordt met het verbinding maken?

Het vaste ipv6 adres op deze W7 pc heeft trouwens geen overeenkomsten met het mac-adres.

code:

C:\Users\Raven>ipconfig /all

Windows IP-configuratie

   Hostnaam  . . . . . . . . . . . . : EyesOnly
   Primair DNS-achtervoegsel . . . . :
   Knooppunttype . . . . . . . . . . : hybride
   IP-routering ingeschakeld . . . . : nee
   WINS-proxy ingeschakeld . . . . . : nee

Ethernet-adapter voor LAN-verbinding:

   Verbindingsspec. DNS-achtervoegsel:
   Beschrijving. . . . . . . . . . . : ******
   Fysiek adres. . . . . . . . . . . : **-**-**-5F-47-0B
   DHCP ingeschakeld . . . . . . . . : nee
   Autom. configuratie ingeschakeld  : ja
   IPv6-adres. . . . . . . . . . . . : ****:****:****:****:ac25:****:20b6:ad66(voorkeur)
   Tijdelijk IPv6-adres. . . . . . . : ****:****:****:****:10bd:****:4b35:4a85(voorkeur)
   Link-local IPv6-adres . . . . . . : fe80::****:****:****:ad66%11(voorkeur)
   IPv4-adres. . . . . . . . . . . . : 192.168.1.11(voorkeur)
   Subnetmasker. . . . . . . . . . . : 255.255.255.0
   Standaardgateway. . . . . . . . . : fe80::****:****:****:4970%11
                                       192.168.1.1
   DNS-servers . . . . . . . . . . . : 8.8.8.8
                                       8.8.4.4
   NetBIOS via TCPIP . . . . . . . . : ingeschakeld

C:\Users\Raven>

Hmm, Windows, tja tja..

quote: http://blogs.technet.com/...and-ipv4-comparisons.aspx

Specific autoconfiguration behaviors of IPv6 for computers running Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7, or Windows Vista:

· Generate random interface IDs for non-temporary autoconfigured IPv6 addresses, including public and link-local addresses, rather than using EUI-64–based interface IDs.

(…)

Die implementeert dus sowieso geen MAC-based adressen, maar RIID's. Of die na een reboot nog hetzelfde zijn, zou je moeten uitproberen of zelf even moeten Googlen though. Want ze hebben 't wel over non-temporary.

[Raven]

Hmm....

Maar de originele vraag staat echter nog open (of ik moet wat gemist hebben), welk adres vul ik in ip6tables in bij het openzetten van een poort? Of kan ik dat vergeten met privacy extensions en moet ik een rule zonder specifiek adres aanmaken zodat de betreffende poort voor alle clients ongeacht adres openstaat?

[Paul]

Ik denk dat ze met het bij non-temporary hebben over de tijdspanne tussen reboots of zo? PE-adressen 'verlopen'. Met "netsh interface ipv6 set global randomize­identifiers=disabled" kun je overigens afdwingen dat Windows wel je MAC-adres gebruikt

Ik zou dus even testen of je na een reboot nog steeds *::ac25:****:20b6:ad66 hebt en anders dat netsh-commando uitvoeren

[Osiris]

Kun je uTorrent niet binden aan je "IPv6-adres" (en dus niet aan je "Tijdelijk IPv6-adres")? En dat gewoon gebruiken in ip6tables?

Hmm, blijkbaar verandert 't niet:

quote: http://lists.cluenet.de/p...ps/2010-March/003265.html

Based upon my own Win7 observations, the default random IID is at least
somewhat permanent (In that it survives across reboots), and that it is
stored somewhere (as the random IID is the same even after disabling and
re-enabling randomization via netsh)

Based upon a document from MS:
http://download.microsoft...a60-3aa3abc2b2e9/ipv6.doc

I think the default Vista/Win7 IID is a "permanant" randomized identifier.
See snippet below:

- It is a permanent interface identifier that is randomly generated to
mitigate address scans of unicast IPv6 addresses on a subnet. This is the
default behavior for IPv6 in Windows Vista and Windows Server 2008. You can
disable this behavior with the netsh interface ipv6 set global
randomizeidentifiers=disabled command.�

Good Luck.

[ Voor 78% gewijzigd door Osiris op 03-06-2014 15:01 ]

[Raven]

Paul schreef op dinsdag 03 juni 2014 @ 14:55:
Ik denk dat ze met het bij non-temporary hebben over de tijdspanne tussen reboots of zo? PE-adressen 'verlopen'. Met "netsh interface ipv6 set global randomize­identifiers=disabled" kun je overigens afdwingen dat Windows wel je MAC-adres gebruikt

Ik zou dus even testen of je na een reboot nog steeds *::ac25:****:20b6:ad66 hebt en anders dat netsh-commando uitvoeren

Ik reboot Windows niet zo vaak, dus dat wordt wachten tot er de nodige updates zijn

Osiris schreef op dinsdag 03 juni 2014 @ 14:55:
Kun je uTorrent niet binden aan je "IPv6-adres" (en dus niet aan je "Tijdelijk IPv6-adres")? En dat gewoon gebruiken in ip6tables?

Bij mijn weten niet, zie trouwens ook eerder genoemde link http://forum.utorrent.com/topic/84584-clean-up-ipv6/ , uTorrent gebruikt blijkbaar alle beschikbare adressen en ik kan volgens mij niet van mijn kant zien of ie dat hier ook doet.

[Paul]

uTorrent -> Preferences -> Advanced -> net.bindip aanpassen? Al gaat dat natuurlijk ook alleen goed totdat je PE-ip veranderd...

[Raven]

Is die optie niet ipv4 only? Overigens gaat dit niet specifiek over uTorrent, er zijn meer programma's die (nog wel eens) een gaatje in de firewall vereisen

[ Voor 4% gewijzigd door Raven op 03-06-2014 15:07 ]

[Roetzen]

Die Privacy Extension adressen zijn volgens mij alleen zinvol als je met een notebook, tablet of smartphone de wereld rondreist. Je kan dan niet aan de hand van het MAC adres gevolgd worden.

Voor een vaste aansluiting op een vast adres is het IMNSHO zinloos en is het alleen maar lastig. De prefix blijft immers hetzelfde, dus kan je toch altijd daaraan herkend worden. Weliswaar niet herleidbaar naar de individuele machine in je LAN, maar wel naar je huisadres, net als nu bij IPv4.

Wie meer wil dan alleen een beetje surfen of e-mailen, kan het beter uitzetten IMHO.

[ Voor 8% gewijzigd door Roetzen op 03-06-2014 15:09 ]

[Osiris]

Paul schreef op dinsdag 03 juni 2014 @ 15:02:
uTorrent -> Preferences -> Advanced -> net.bindip aanpassen? Al gaat dat natuurlijk ook alleen goed totdat je PE-ip veranderd...

...dus daarom niet je PE-IP invullen hè

[Paul]

Jawel, je wilt toch niet dat Brein je MAC-adres achterhaalt Want die instanties zullen alles toch wel per /64 op een hoop gooien en op de eigenaar van de verbinding afstappen lijkt me

[Osiris]

Maar Windows maakt geen gebruik van het MAC-adres om het random "vaste" IPv6-adres te berekenen, althans, wat iemand in de quote wat ik hierboven quotte zei. (Over dat 't vast is.. Dat het geen gebruik van het MAC-adres maakt is sowieso zeker)

[ Voor 21% gewijzigd door Osiris op 03-06-2014 15:23 ]

[Roetzen]

Paul schreef op dinsdag 03 juni 2014 @ 15:21:
Jawel, je wilt toch niet dat Brein je MAC-adres achterhaalt

Ik heb het liefst dat Brein zo weinig mogelijk van mij weet. Maar ik zou eigenlijk niet weten wat ze met mijn MAC adres aan zouden kunnen vangen. Ja, dan weten ze het fabrikaat van mijn netwerkkaart. Nou en?

[Osiris]

Roetzen schreef op dinsdag 03 juni 2014 @ 16:03:
[...]

Ik heb het liefst dat Brein zo weinig mogelijk van mij weet. Maar ik zou eigenlijk niet weten wat ze met mijn MAC adres aan zouden kunnen vangen. Ja, dan weten ze het fabrikaat van mijn netwerkkaart. Nou en?

<Brein> "Meneer <eigenaar van huis>, we hebben bemerkt dat er vanaf uw internetverbinding illegale films geupload zijn, of u eventjes €€€ wil dokken."
<Eigenaar> "Ammehoela, dat was ik niet, dat waren de huurders!"
<Huurder> "Há, bewijs 't maar eens, jij bent als contracthebbende verantwoordelijk *steekt tong uit*"
<Eigenaar/Brein> "Nouhou, kijk, we hebben hier MAC-adressen die overeenkomen met jouw PC…"
<Huurder> "Oh crap… [rml]:/[/]"

Zoiets?

[CyBeR]

Roetzen schreef op dinsdag 03 juni 2014 @ 15:07:
Die Privacy Extension adressen zijn volgens mij alleen zinvol als je met een notebook, tablet of smartphone de wereld rondreist. Je kan dan niet aan de hand van het MAC adres gevolgd worden.

Voor een vaste aansluiting op een vast adres is het IMNSHO zinloos en is het alleen maar lastig. De prefix blijft immers hetzelfde, dus kan je toch altijd daaraan herkend worden. Weliswaar niet herleidbaar naar de individuele machine in je LAN, maar wel naar je huisadres, net als nu bij IPv4.

Wie meer wil dan alleen een beetje surfen of e-mailen, kan het beter uitzetten IMHO.

Je vergeet dat IP niet alleen gebruikt wordt door mensen thuis maar ook bij grotere organisaties waarbij je op het moment dat je je IP verandert wél verdwijnt in de massa.

Plus dat je door gebruik te maken van tijdelijke adressen minder vatbaar bent voor inkomende aanvallen van buiten. Een heel /64 scannen is namelijk niet te doen, maar als je vaste adressen gebruikt zoals de EUI-64 adressen dan is 't vrij simpel om een lijst werkende adressen met een computer erachter uit een log ofzo te halen.

[Roetzen]

Osiris schreef op dinsdag 03 juni 2014 @ 16:06:
[...]

<Brein> "Meneer <eigenaar van huis>, we hebben bemerkt dat er vanaf uw internetverbinding illegale films geupload zijn, of u eventjes €€€ wil dokken."
<Eigenaar> "Ammehoela, dat was ik niet, dat waren de huurders!"
<Huurder> "Há, bewijs 't maar eens, jij bent als contracthebbende verantwoordelijk *steekt tong uit*"
<Eigenaar/Brein> "Nouhou, kijk, we hebben hier MAC-adressen die overeenkomen met jouw PC…"
<Huurder> "Oh crap… [rml]:/

"

Zoiets?
[/quote]
Geen probleem, ik heb nog nooit een illegaal filmpje geupload en ik heb geen huurders.. Maar ik denk dat als ik dat wel zou doen, het verbergen van mijn MAC adres mij niet tegen Brein zou beschermen. Als er vanaf mijn internet verbinding iets illegaals gebeurt, en ik wordt betrapt, ben ik sowieso de sjaak denk ik. Met of zonder MAC adres.

[Roetzen]

CyBeR schreef op dinsdag 03 juni 2014 @ 16:08:
[...]

Je vergeet dat IP niet alleen gebruikt wordt door mensen thuis maar ook bij grotere organisaties waarbij je op het moment dat je je IP verandert wél verdwijnt in de massa.

Dat had ik inderdaad even vergeten. Ik ben te lang uit het arbeidsproces.
Maar ja, als je met je eigen device op het netwerk van de baas of de campus zit, telt dat eigenlijk als "met je laptop, tablet of smartphone de werled rond reizen". Toch?

Plus dat je door gebruik te maken van tijdelijke adressen minder vatbaar bent voor inkomende aanvallen van buiten. Een heel /64 scannen is namelijk niet te doen, maar als je vaste adressen gebruikt zoals de EUI-64 adressen dan is 't vrij simpel om een lijst werkende adressen met een computer erachter uit een log ofzo te halen.

Vind ik niet zo'n sterk argument. De meeste gevaren komen toch door acties van de gebruiker zelf. Ook als de adressen bekend zijn, zou een aanvaller gewoon tegen de firewall aan moeten lopen. Tenzij er poorten open staan, maar dat zou normalier alleen het geval moeten zijn als je servers draait. En als je zoals ik een server draait, dan moet je sowieso je adres bekend maken. Denken dat je veilger bent als je steeds van adres wisselt is denk ik schijnveiligheid.

[Verwijderd]

Even snel en dus in het kort -met de kans dat ik iets overlezen heb-

Ik denk dat je je meer zorgen moet maken over tracking cross-netwerk op basis van je IPv6 adres in combinatie met je mac adres hoewel dat ook niet waterdicht / veilig is en daar ook "excuus" argumenten voor zijn.

Voor wat betreft tracking door "gewone" sites, dan moet je volgens mij je veel meer zorgen maken op cookie level, waar een stuk meer info kan worden opgeslagen (os, browser, enz) dan dat ze je volgen op IP level.

[PenguinPower]

CAPSLOCK2000 schreef op maandag 02 juni 2014 @ 12:34:
[...]


Dat ziet er erg interessant uit. We overwegen iets dergelijk voor onze client-netwerken. Bij ons loopt het momenteel stuk omdat we geen on-the-fly DNSSEC-signing hebben. Ik weet dat PowerDNS dat zou moeten kunnen. Hebben jullie toevallig ook DNSSEC aan staan en werkt dat goed samen met deze oplossing?

PowerDNS kan dat inderdaad on-the-fly. DNSSEC staat bij ons op de todo list,eerst moet PowerAdmin stable support hebben hiervoor (op dit moment maakt PowerAdmin de zone steeds stuk icm met DNSSEC).
Geen idee of het zonder aanpassingen gaat werken. PowerDNS icm een pipe en DNSSEC is partial supported. In het ergste geval moet de dns geproxyed worden om dnssec werkend te maken (ivm een 2e powerdns of phreebird server)

[Verwijderd]

Snow_King schreef op dinsdag 03 juni 2014 @ 10:22:
Ik kan in ieder geval niet wachten op IPv6 via ZeelandNet. Al onze 18 verbindingen krijgen nog deze maand native-IPv6

Ik weet niet of je bekend bent met RIPE atlas, maar als ik zo op de kaart van de probes kijk https://atlas.ripe.net/results/maps/network-coverage/ zie ik maar bar weinig probes in Zeeland.

In het kort, je vraagt RIPE een aantal probes en die sturen je kostenloos toe. Deze devices hang je aan je netwerk en verzamelen informatie over de latency van je verbinding, worden gebruikt om test te doen naar DNS servers enz, geen interne informatie van je eigen netwerk. Meer op https://atlas.ripe.net/about/faq/

Je zou misschien wel een mooie kandidaat zijn, mochten deze locaties allemaal internet toegang hebben (misschien dat ze via een VPN / MPLS het internet opgaan, dan niet).

[CAPSLOCK2000]

Osiris schreef op dinsdag 03 juni 2014 @ 13:48:

Mjah, maar dan zou je iedere PC een non-SLAAC-IP moeten geven..

SLAAC is wat anders dan Privacy Extensions. Zolang je MAC-adres niet verandert zal het SLAAC-adres ook niet veranderen. Als dat niet vast genoeg is zou je nog DHCPv6 kunnen gebruiken om machines hetzelfde adres te geven, zelfs wanneer het MAC-adres verandert.

Dat uTorrent z'n PE-adres publiceert is een bug, al weet ik niet of het aan uTorrent ligt of aan Windows. Die PE-adressen kunnen ieder moment veranderen. Als trackers dat adres gaan onthouden is het mogelijk al weer veranderd tegen de tijd dat iemand het wil gebruiken. Zo'n adres in je firewall opnemen is dus ook zinloos.

[Snow_King]

Verwijderd schreef op woensdag 04 juni 2014 @ 10:11:
[...]


Ik weet niet of je bekend bent met RIPE atlas, maar als ik zo op de kaart van de probes kijk https://atlas.ripe.net/results/maps/network-coverage/ zie ik maar bar weinig probes in Zeeland.

In het kort, je vraagt RIPE een aantal probes en die sturen je kostenloos toe. Deze devices hang je aan je netwerk en verzamelen informatie over de latency van je verbinding, worden gebruikt om test te doen naar DNS servers enz, geen interne informatie van je eigen netwerk. Meer op https://atlas.ripe.net/about/faq/

Je zou misschien wel een mooie kandidaat zijn, mochten deze locaties allemaal internet toegang hebben (misschien dat ze via een VPN / MPLS het internet opgaan, dan niet).

Ik ken het inderdaad. In ons datacenter in Amsterdam hebben we er een paar hangen, maar ik kan er op onze locaties in Zeeland ook wel 1 of 2 kwijt denk ik.

[Verwijderd]

Snow_King schreef op woensdag 04 juni 2014 @ 13:54:
[...]
Ik ken het inderdaad. In ons datacenter in Amsterdam hebben we er een paar hangen, maar ik kan er op onze locaties in Zeeland ook wel 1 of 2 kwijt denk ik.

Reden dat ik het noemde is ook omdat als je IPv6 daar hebt, ze kunnen worden meegenomen in een nieuwe test van RIPE NCC waarbij IP routering inkaart gebracht wordt (tot op stad niveau).

Heeft wat weg van geo loc, echter dit gaat meer om routering in kaart te brengen (niet waar is de website gehost of eindstations), zowel voor IPv4 als IPv6. Is nu nog in beta fase maar kan mogelijk opensource worden zoals openstreetmap. Er zijn al wat interessante routeringens verschillen te zien tussen ipv4 en ipv6 hoewel dat een erg vroege constatering is met veel voorbehoud. Maar naarmate de gegevens beter worden zal dit later zeker kunnen helpen met troubleshooten bij bv performance issues.

https://labs.ripe.net/Members/emileaben/infrastructure-geolocation-plan-of-action

In de RIPE meeting vorig jaar en vorige maand was de response op het idee groot. Heeft leuke potentie.

[Paul]

Verwijderd schreef op woensdag 04 juni 2014 @ 14:45:
Er zijn al wat interessante routeringens verschillen te zien tussen ipv4 en ipv6

Is dat wel of niet gecorrigeerd voor het gebruik van tunnels? Iedereen met SixXS gaat namelijk over Amsterdam, Haarlem of Ede, terwijl bijvoorbeeld een Ziggo of UPC waarschijnlijk veel meer PoP's heeft.

[Roetzen]

Verwijderd schreef op woensdag 04 juni 2014 @ 14:45:
[...]

Reden dat ik het noemde is ook omdat als je IPv6 daar hebt, ze kunnen worden meegenomen in een nieuwe test van RIPE NCC waarbij IP routering inkaart gebracht wordt (tot op stad niveau).

Ik doe ook mee. Mijn probe is IPv6 pingbaar op: atlas.vlist.eu. (Helaas nog geen native IPv6 )

[Verwijderd]

Paul schreef op woensdag 04 juni 2014 @ 15:11:
[...]
Is dat wel of niet gecorrigeerd voor het gebruik van tunnels? Iedereen met SixXS gaat namelijk over Amsterdam, Haarlem of Ede, terwijl bijvoorbeeld een Ziggo of UPC waarschijnlijk veel meer PoP's heeft.

Zover ik zie nog niet op dat niveau, het is wereld omvattend en dan zijn de routers/hops en steden volgens mij nog iets interessanter dan waar de tunnel clients van komen. Maar ik kan het mishebben, want er wordt wel rekening gehouden met private IP reeksen.

Ik heb vandaag zitten kijken wat de routering is vanuit Spanje (diverse plaatsen) naar Amsterdam. Dat is vooral om te kijken waar je tegenaanloopt (bv ontbrekende PTR records). Van een aantal hops wist ik waar ze zich fysiek bevinden. Als de werking zich ontwikkeld kunnen anderen deze informatie updaten of corrigeren.

Is zoals gezegd nog erg beta. Ik ben overigens niet de initiatiefnemer of aanstuurder van deze test, ik ben maar een test monkey

[ Voor 5% gewijzigd door Verwijderd op 04-06-2014 15:24 ]

[Paul]

Ik heb net ook een probe aangevraagd, interessant 'experiment' / project, en ik wil best iets terugdoen voor 'het internet'

De dichtstbijzijnde probe met dezelfde IPv4 ASN zit 13 km verderop, die probe heeft echter wel een ander IPv6 ASN. Ben benieuwd, als ze vinden dat het de kort op elkaar is vind ik het ook goed, alleen een beetje jammer dat ze aangeven afwijzingen niet te melden. Hoeveel moeite is het om een mailtje terug te sturen met "Helaas, je bent het niet geworden."?

[Snow_King]

Ik heb de afgelopen dagen rare ding mee gemaakt die je alleen met IPv6 ziet en niet met IPv4.

Twee hosts in een lokaal netwerk konden maar half verkeer met elkaar uit wisselen. ping6 (echo / echo-reply) werkte, SSH connecties ook, maar zodra je verkeer wilde uitwisselen ging alles kapot.

Twee dagen aan het zoeken geweest, wat bleek: De netwerk admin had Jumbo Frames niet aan gezet op de betreffende poorten terwijl wij aan namen dat het wel gedaan was.

MTU stond op onze hosts op 9k, dus die gingen 9k packets uit wisselen indien nodig.

IPv6 zet een "Do Not Fragment" bit, dus de switch discard een pakket wat te groot is ipv de fragmenteren zoals bij IPv4.

MTU Path Detection werd in dit geval niet gedaan, dus daarom werd de MTU niet kleiner.

Zo kan je even bezig zijn!

[databeestje]

Snow_King schreef op woensdag 04 juni 2014 @ 16:44:
Ik heb de afgelopen dagen rare ding mee gemaakt die je alleen met IPv6 ziet en niet met IPv4.

Twee hosts in een lokaal netwerk konden maar half verkeer met elkaar uit wisselen. ping6 (echo / echo-reply) werkte, SSH connecties ook, maar zodra je verkeer wilde uitwisselen ging alles kapot.

Twee dagen aan het zoeken geweest, wat bleek: De netwerk admin had Jumbo Frames niet aan gezet op de betreffende poorten terwijl wij aan namen dat het wel gedaan was.

Uhm, met mijn vSphere gaat het in combinatie met IPv4 en een MTU mismatch ook niet goed. Bijvoorbeeld de verkeerde MTU op 1 van de vswitches van het storage netwerk. (niet de vswitch, wel de management port bv.)

Ook in een lokaal LAN gaat het al snel de mist in als de MTU van 1 van de machines anders is. Zeker ook met IPv4 heb ik hier de nodige perikelen gezien, en dan voornamelijk als een switch de grotere maat niet doorlaat. Dat kan een host niet makkelijk detecteren.

Ook als er gefiltered wordt op icmp breekt in IPv4 de boel snel af als de MTU geen 1500 is.

[Mafketel]

Snow_King schreef op woensdag 04 juni 2014 @ 16:44:
Ik heb de afgelopen dagen rare ding mee gemaakt die je alleen met IPv6 ziet en niet met IPv4.

Twee hosts in een lokaal netwerk konden maar half verkeer met elkaar uit wisselen. ping6 (echo / echo-reply) werkte, SSH connecties ook, maar zodra je verkeer wilde uitwisselen ging alles kapot.

Twee dagen aan het zoeken geweest,

Leer momentje bovenstaande beschrijving is de hint dat de mtu fout staat.

wat bleek: De netwerk admin had Jumbo Frames niet aan gezet op de betreffende poorten terwijl wij aan namen dat het wel gedaan was.
...
Zo kan je even bezig zijn!

De volgende keer wordt dat het volgende item op je checklist

[Nakebod]

LACNIC heeft nog maar iets meer dan 4 miljoen IPv4 adressen over. Waarvan als ik het goed lees 2 miljoen voor bestaande LACNIC leden zijn, die een block van max 1024 adressen kunnen krijgen per 6 maanden. Als die 2 miljoen adressen op zijn dan worden de overige 2 miljoen gereserveerde adressen beschikbaar gesteld aan nieuwe leden, met maximaal 1024 adressen, eenmalig.

Geen idee of ze ook eisen dat je IPv6 ready bent voordat je een IPv4 block krijgt, lijkt mij een mooie voorwaarde voor het verkrijgen van IPv4 eigenlijk.

No more IPv4 addresses in Latin America and the Caribbean

Latin America and the Caribbean have entered the IPv4 exhaustion phase; the delay in deploying Internet Protocol version 6 in our region is cause for concern.

[Maurits van Baerle]

Ik heb deze gisteren op de Frontpage gepost onder het IPv6-artikel-du-jour maar hier is hij eigenlijk ook wel nuttig.

Facebook is druk bezig om intern volledig IPv6 te gaan en IPv4 ondersteuning wordt op dit moment intern verwijdert. Ze willen dit jaar nog alle PC's van developers geen IPv4 adres meer geven zodat ze gedwongen worden om alleen nog maar voor IPv6 te ontwikkelen en te testen. Aan de rand van het netwerk wordt er dan een vertaalslag gemaakt voor Facebook gebruikers die nog geen iPv6 hebben.

Hier kun je hun presentatie bekijken over de problemen die ze hebben gehad met het deprecaten van IPv4.

[Snow_King]

Maurits van Baerle schreef op donderdag 12 juni 2014 @ 11:52:
Ik heb deze gisteren op de Frontpage gepost onder het IPv6-artikel-du-jour maar hier is hij eigenlijk ook wel nuttig.

Facebook is druk bezig om intern volledig IPv6 te gaan en IPv4 ondersteuning wordt op dit moment intern verwijdert. Ze willen dit jaar nog alle PC's van developers geen IPv4 adres meer geven zodat ze gedwongen worden om alleen nog maar voor IPv6 te ontwikkelen en te testen. Aan de rand van het netwerk wordt er dan een vertaalslag gemaakt voor Facebook gebruikers die nog geen iPv6 hebben.

Hier kun je hun presentatie bekijken over de problemen die ze hebben gehad met het deprecaten van IPv4.

Super!

Ik ben op kleinere schaal met het zelfde bezig. Inmiddels hebben wij binnen ons bedrifj (hosting, duizenden servers) al een groot deel op IPv6-only draaien.

Alle services die we intern draaien kunnen prima op IPv6 en scheelt ons een hoop IPv4 space.

Werkt prima en eigenlijk weinig problemen tegen gekomen.

[Raven]

Maurits van Baerle schreef op donderdag 12 juni 2014 @ 11:52:
Ik heb deze gisteren op de Frontpage gepost onder het IPv6-artikel-du-jour maar hier is hij eigenlijk ook wel nuttig.

Facebook is druk bezig om intern volledig IPv6 te gaan en IPv4 ondersteuning wordt op dit moment intern verwijdert. Ze willen dit jaar nog alle PC's van developers geen IPv4 adres meer geven zodat ze gedwongen worden om alleen nog maar voor IPv6 te ontwikkelen en te testen. Aan de rand van het netwerk wordt er dan een vertaalslag gemaakt voor Facebook gebruikers die nog geen iPv6 hebben.

Hier kun je hun presentatie bekijken over de problemen die ze hebben gehad met het deprecaten van IPv4.

Gaan ze IPv4 gebruikers dan een melding geven dat hun ISP geen IPv6 ondersteund? Misschien dat mensen dan bij hun ISP aan de bel trekken waarna die hopelijk iets meer moeite gaan doen om IPv6 deze eeuw uit te rollen.

[Maurits van Baerle]

Raven schreef op donderdag 12 juni 2014 @ 12:09:
[...]

Gaan ze IPv4 gebruikers dan een melding geven dat hun ISP geen IPv6 ondersteund? Misschien dat mensen dan bij hun ISP aan de bel trekken waarna die hopelijk iets meer moeite gaan doen om IPv6 deze eeuw uit te rollen.

Ik denk niet dat gewone gebruikers er veel van zullen merken. Aan de buitenkant van hun netwerk maken ze een vertaalslag zodat hun voorkant gewoon dual-stack is. Mensen met alleen IPv4 zullen dus nog steeds met IPv4 kunnen verbinden terwijl mensen die al dual-stack of IPv6-only hadden nog steeds IPv6 gebruiken.

Als iemands browser dus via IPv4 een object aanvraagt dat op een IPv6-only Facebook server staat zal er ergens een batterij routers staan die alles omzet.

[Raven]

Nee okee. Maar isp's stimuleren om ondersteuning te bieden voor IPv6 is denk ik wel een goed idee. Heb net via de Facebook feedback-pagina een bericht ingestuurd met het idee om tijdens het inloggen een pop-up te geven als je Facebook via IPv4 ipv IPv6 opent met daarbij het bericht de ISP daar op te wijzen.

Als alle IPv4 gebruikers dat nou gaan doen, misschien dat dat genoeg stimulans is voor ISP's om over IPv6 na te gaan denken

[tlpeter]

Wanneer Facebook IPv6 only wordt dan breekt de pleuris uit en moeten de providers wel om

[CyBeR]

Snow_King schreef op donderdag 12 juni 2014 @ 12:08:
[...]
Super!

Ik ben op kleinere schaal met het zelfde bezig. Inmiddels hebben wij binnen ons bedrifj (hosting, duizenden servers) al een groot deel op IPv6-only draaien.

Alle services die we intern draaien kunnen prima op IPv6 en scheelt ons een hoop IPv4 space.

Werkt prima en eigenlijk weinig problemen tegen gekomen.

En gebruik je dan NAT64 o.i.d. om die machines bij het internet te laten kunnen?

[JackBol]

tlpeter schreef op donderdag 12 juni 2014 @ 16:01:
Wanneer Facebook IPv6 only wordt dan breekt de pleuris uit en moeten de providers wel om

Met alle IPv4 adressen die vrij komen als ze hun hele datacenter op IPv6 laten draaien, kunnen ze nog 100 jaar hun frontproxies op IPv4 laten werken.

Facebook is de komende 20 jaar niet IPv6 only...

[Roetzen]

_DH schreef op donderdag 12 juni 2014 @ 16:57:
[...]
Met alle IPv4 adressen die vrij komen als ze hun hele datacenter op IPv6 laten draaien, kunnen ze nog 100 jaar hun frontproxies op IPv4 laten werken.

Nee. want die IPv4 adressen die vrijkomen zijn interne RFC1918 adressen.

Facebook is de komende 20 jaar niet IPv6 only...

We zullen zien. Ik denk dat het eerder gebeurt. Veel eerder...

[CAPSLOCK2000]

Ik zou liever hebben dat Google IPv6 laat meetellen in z'n zoekmachine zodat al die SEO- & communicatie-figuren een reden hebben om IPv6 te willen.

[Raven]

Dien het in als featurerequest

[Maurits van Baerle]

_DH schreef op donderdag 12 juni 2014 @ 16:57:
[...]


Met alle IPv4 adressen die vrij komen als ze hun hele datacenter op IPv6 laten draaien, kunnen ze nog 100 jaar hun frontproxies op IPv4 laten werken.

Facebook is de komende 20 jaar niet IPv6 only...

Sowieso acht ik het uitgesloten dat Facebook over 20 jaar nog bestaat. Zelfs 10 jaar lijkt me erg lang (hoeveel internetdiensten kun je noemen die het langer dan vijf jaar enigszins aan de top hebben volgehouden?). Maar goed, stel dat ze over 10 jaar nog bestaan (MySpace en Orkut bestaat immers ook nog steeds) dan is het de vraag of ze nog IPv4 aanbieden.

Ten eerste zal IPv4-only apparatuur vrijwel niet meer door consumenten gebruikt worden. En diegene die heel zuinig zijn geweest op hun spullen zullen dat toch niet gebruiken om Facebook te bezoeken. Moet je voor de lol eens FB bezoeken met een vijf jaar oude browser, laat staan 10 jaar oud.

Daarnaast heb je het over tien jaar waarschijnlijk over minder dan 1% van het verkeer dat nog IPv4 is. Er komt natuurlijk een moment dat nieuwe features compatible maken of het in stand houden van die apparatuur met IPv4 simpelweg te duur wordt.

[Roetzen]

Iljitsch heeft er weer wat over gezegd:

With the Americas running out of IPv4, it’s official: The Internet is full
Where did all those IP addresses go?

lees meer: http://arstechnica.com/in...ial-the-internet-is-full/

[Nakebod]

_DH schreef op donderdag 12 juni 2014 @ 16:57:
[...]


Met alle IPv4 adressen die vrij komen als ze hun hele datacenter op IPv6 laten draaien, kunnen ze nog 100 jaar hun frontproxies op IPv4 laten werken.

Facebook is de komende 20 jaar niet IPv6 only...

Maar ze willen dit jaar al wel beginnen met IPv6 only cluster(s). En IPv6 gebruikers zullen ze vast wel zoveel mogelijk naar dat IPv6 only cluster pushen. Dus als gebruiker zou je dan als het goed is al geen IPv4 verkeer mogen zien.

Neemt niet weg dat facebook naar verwachting steeds meer IPv4 adressen over gaat houden naar verloop van tijd. Maar dat gaat feitelijk iedere grote hoster/dienst/etc krijgen, hoe meer je de "interne" structuur via IPv6 laat lopen, des te minder IPv4 je nodig hebt. Een "paar" publieke front ends/proxies erbij en je blijft dualstack.

[databeestje]

CyBeR schreef op donderdag 12 juni 2014 @ 16:12:
[...]


En gebruik je dan NAT64 o.i.d. om die machines bij het internet te laten kunnen?

Het is intern, dus geen NAT64 nodig, alles wat IPv6 heeft kan er prima mee communiceren. Dit is een goed voorbeeld van een gecontroleerde omgeving.

Dat wat geen IPv6 heeft, heeft dan nog een IPv4, dus geen vertaling nodig.

Inzake Facebook, daar staat heel veel infrastructuur achter loadbalancers welke de website serveren, deze zijn Dual Stack.

Nu geven ze aan om het netwerk achter de load balancer (proxy) om te zetten naar IPv6, aangezien de mensen alleen tegen de LB praten zullen ze nooit zien met welk protocol de LB naar de webserver verbindt.

[Snow_King]

CyBeR schreef op donderdag 12 juni 2014 @ 16:12:
[...]


En gebruik je dan NAT64 o.i.d. om die machines bij het internet te laten kunnen?

databeestje schreef op vrijdag 13 juni 2014 @ 09:01:
[...]

Het is intern, dus geen NAT64 nodig, alles wat IPv6 heeft kan er prima mee communiceren. Dit is een goed voorbeeld van een gecontroleerde omgeving.

Dat wat geen IPv6 heeft, heeft dan nog een IPv4, dus geen vertaling nodig.

Correct.

Deze machines draaien interne databases, API's, etc.

Alles wát ze nodig hebben is over IPv6 beschikbaar:
- Ubuntu Apt repositories
- NTP servers

Wij beheren die machines ook over IPv6, dus er is geen spoor van IPv4 danwel NAT64 te vinden op die machines.

Eén bijkomend voordeel: Je hebt geen portscans of andere onzin die je NIC onnodig bezig houdt. IPv6 is best wel héél erg clean.

[databeestje]

Wat leuk, om maar met je VM's in de braziliaanse sfeer te komen.
nieuws: Microsoft heeft geen Amerikaanse ipv4-adressen voor Azure meer

Kon het ook niet laten om op deze reply te antwoorden "Er is geen shortage?":
0vestel0 in 'nieuws: Microsoft heeft geen Amerikaanse ipv4-adressen voor Azure meer'

Edit: Nee, de reactie op mijn antwoord is al veel beter. "NAT is een oplossing want je kan meerdere sites op 1 IP adres hosten".

Uhm, niet als je VPSje afneemt denk ik. Of je moet als hostingprovider een Varnish/HAproxy/Loadbalancer hebben en tegen alle klanten zeggen dat ze het WWW record daar naar moeten verwijzen. Tuurlijk, wenselijk?

Daarnaast ook een beetje klok klepel, er is een apart range apart gezet voor NAT, maar niet voor je hosting

[ Voor 29% gewijzigd door databeestje op 13-06-2014 13:47 ]

[Roetzen]

databeestje schreef op vrijdag 13 juni 2014 @ 13:39:
Wat leuk, om maar met je VM's in de braziliaanse sfeer te komen.
nieuws: Microsoft heeft geen Amerikaanse ipv4-adressen voor Azure meer

Die Braziliaanse IPs zijn binnenkort ook op. http://www.lacnic.net/en/...s-direcciones-ipv4-en-lac

IPv4 adressen "lenen" van andere Regios is weer het zoveelste lapmiddel om het onvermijdelijke nog een paar maandjes uit te stellen. Het stuurt ook regio gebonden diensten in de war...

[FatalError]

Kennen jullie speedtest6.ziggo.nl al? Draait bij Ziggo zelf zo te zien.
Ik trek mijn XS4ALL 100/100 lijntje dicht met deze test.

[ Voor 29% gewijzigd door FatalError op 16-06-2014 11:57 ]

[Raven]

Kende 'm niet en mijn 50/50 lijntje kan die zo te zien met gemak bijbenen, kan ook niet anders als ie jouw 100/100 lijntje kan bijbenen , maar nu weet ik ook dat ik net zo snel via de IPv6-tunnel kan down/uploaden als via IPv4.

Maar een IPv6-speedtest terwijl de klanten van Ziggo voor zover ik weet nog altijd geen IPv6 hebben

[ Voor 44% gewijzigd door Raven op 16-06-2014 10:48 ]

[FatalError]

Raven schreef op maandag 16 juni 2014 @ 10:44:
Maar een IPv6-speedtest terwijl de klanten van Ziggo voor zover ik weet nog altijd geen IPv6 hebben

Zakelijke glasvezelklanten kunnen al vrij lange tijd IPv6 krijgen bij Ziggo. En ik weet dat ze intern met consumentenmodems en zakelijke modemklanten IPv6 aan het testen zijn.

[Nakebod]

Zakelijk doet Ziggo toch al wel aan IPv6, op aanvraag?

[Paul]

Big bang in één keer alle DNS-wijzigingen zou ook kunnen natuurlijk, maar ik verwacht dat ze gewoon één voor één alles aan het bijwerken / upgraden zijn

[Raven]

FatalError schreef op maandag 16 juni 2014 @ 10:52:
[...]


Zakelijke glasvezelklanten kunnen al vrij lange tijd IPv6 krijgen bij Ziggo. En ik weet dat ze intern met consumentenmodems en zakelijke modemklanten IPv6 aan het testen zijn.

Geen idee, ken geen mensen met zakelijk abo

[Roetzen]

Raven schreef op maandag 16 juni 2014 @ 10:44:
maar nu weet ik ook dat ik net zo snel via de IPv6-tunnel kan down/uploaden als via IPv4.

Ik haal bij lange na niet de IPv4 snelheid:

code:

via mijn SixXs tunnel :  ping 19 ms, Down  8.97 Mbps, Up 2,42 Mbps.
via mijn he.net tunnel:  ping 16 ms, Down 15,12 Mbps, Up 2,50 Mbps.
via IPv4              :  ping 16 ms, Down 31,54 Mbps, Up 2.96 Mbps.

[Raven]

code:

he.net tunnel:  ping 10 ms, Down 45,97 Mbps, Up 48,75 Mbps.

Kan ietsje sneller, heb uTorrent nog aanstaan maar heb 50/50 abo, dus is best netjes

[CyBeR]

Raven schreef op maandag 16 juni 2014 @ 10:54:
[...]

Geen idee, ken geen mensen met zakelijk abo

Ik heb bij een zakelijk abo wel 's IPv6-gegevens meegeleverd zien worden maar die leken op dat moment niet daadwerkelijk iets te doen…

UPC heeft er overigens ook een:

http://speedtest-ipv6-1.upc.nl

[ Voor 10% gewijzigd door CyBeR op 16-06-2014 12:58 ]

[elsinga]

Hier ook vrijwel dezelfde 90/9 via ipv6 6-to-4: 87.7/8.4.

Zou Ziggo al een eigen 6-to-4 proxy/gateway/router hebben staan? Want een tijd geleden kwam ik nog op de SARA 6-to-4 dinges uit.

[Roetzen]

Raven schreef op maandag 16 juni 2014 @ 11:59:

code:

he.net tunnel:  ping 10 ms, Down 45,97 Mbps, Up 48,75 Mbps.

Kan ietsje sneller, heb uTorrent nog aanstaan maar heb 50/50 abo, dus is best netjes

Ik heb het vermoeden dat mijn slechte resultaten komen doordat mijn WRT54GL met OpenWrt het niet bij kan houden. Ik heb geprobeerd dat te testen door de router te omzeilen en deze computer direct op het modem aan te sluiten. Dan zou ik in elk geval mijn SixXs tunnel kunnen testen, want die heeft zijn eindpunt op deze machine.

Maar wat vroeger wel ging, gaat nu niet meer. Ik krijg geen IP adres van Ziggo. Kennelijk hebben ze iets veranderd en is mijn aansluiting nu gelockt op het MAC adres van mijn router.

[Zsub]

Roetzen schreef op maandag 16 juni 2014 @ 15:11:
[...]

Ik heb het vermoeden dat mijn slechte resultaten komen doordat mijn WRT54GL met OpenWrt het niet bij kan houden. Ik heb geprobeerd dat te testen door de router te omzeilen en deze computer direct op het modem aan te sluiten. Dan zou ik in elk geval mijn SixXs tunnel kunnen testen, want die heeft zijn eindpunt op deze machine.

Maar wat vroeger wel ging, gaat nu niet meer. Ik krijg geen IP adres van Ziggo. Kennelijk hebben ze iets veranderd en is mijn aansluiting nu gelockt op het MAC adres van mijn router.

Beetje OT, maar dan moet je je modem ook even uitzetten, dan werkt het afaik wel.

[Raven]

Roetzen schreef op maandag 16 juni 2014 @ 15:11:
[...]

Ik heb het vermoeden dat mijn slechte resultaten komen doordat mijn WRT54GL met OpenWrt het niet bij kan houden. Ik heb geprobeerd dat te testen door de router te omzeilen en deze computer direct op het modem aan te sluiten. Dan zou ik in elk geval mijn SixXs tunnel kunnen testen, want die heeft zijn eindpunt op deze machine.

Maar wat vroeger wel ging, gaat nu niet meer. Ik krijg geen IP adres van Ziggo. Kennelijk hebben ze iets veranderd en is mijn aansluiting nu gelockt op het MAC adres van mijn router.

Dat zou heel goed kunnen, de WRT54GL is geen recente router toch? .... Pricewatch: "Eerste prijsvermelding donderdag 12 januari 2006", dat is niet recent nee De enige router die ik ooit heb gehad kwam ook rond die tijd uit dacht ik, alhoewel: "Eerste prijsvermelding vrijdag 25 februari 2005", aldus de pricewatch hier.

Maar goed, mijn router had een max throughput van zo'n 25Mbps, als jouw router dat ongeveer ook heeft en dan ook nog eens een tunnel moet gebruiken, dan zou dat wel eens te veel kunnen zijn.

Wat betreft de mac-lock in de modem: De modem moet je dan een flinke (figuurlijke) schop onder de kont geven, in het geval van de modem even een minuutje ofzo de stekker eruit.

[Roetzen]

@Zsub
Inderdaad, modem resetten, dat werkt. Maar helaas, kinderpaas, het maakt voor de snelheid niets uit.

code:

SixXs:  ping 19 ms, Down  5,54, Up 2,11
Ipv4:   ping 16 ms, Down 31,53, Up 2,94

Dus het ligt ergens anders aan als aan mijn router....

@Raven

Dat zou heel goed kunnen, de WRT54GL is geen recente router toch?

Klopt, hij is van 2006. Al bejaard dus eigenlijk. Maar ja met de 30+ download snelheid die Ziggo mij biedt heeft ie geen moeite. Dat mijn he.net tunnel vertraging oploopt zou kunnen, die eindigt immers in de WRT54GL. Maar voor mijn SixXs tunnel zou het niks uit moeten maken, die gaat dwars door de router heen, de WRT54GL ziet alleen maar IPv4 pakketjes...

[ Voor 49% gewijzigd door Roetzen op 16-06-2014 16:18 ]

[CAPSLOCK2000]

Iljitsch van Beijnum heeft wat geschreven over IPv6-beveiliging, ook interessant als je (denkt dat je) nog geen IPv6 op je netwerk hebt. http://www.bgpexpert.com/...20force%20beveiliging.pdf

[Keiichi]

Heeft er iemand toevallig een TransIP VPS met ipv6?

De connectiviteit is belabberd en hun NOC kan niets vinden!

[Verwijderd]

Keiichi schreef op dinsdag 17 juni 2014 @ 22:16:
Heeft er iemand toevallig een TransIP VPS met ipv6?

De connectiviteit is belabberd en hun NOC kan niets vinden!

Is dit met "alles" of naar specifieke gebieden? Anders kan ik als je een adres heb dat een ping reply geeft een bulkje probes uit heel Europa laten meten wat de tijden zijn en hoe hun routeringen lopen.

Ik heb al wat bizarre routeringen gezien binnen IPv6, waarschijnlijk door tijdelijke tunnels of het nog niet peeren op bepaalde knooppunten.

/Edit

Als ik www.transip.nl gebruik (2a01:7c8:1337::1337) met 47 probes uit NL dan zijn er 3 die rond de 3 seconden response zitten. De rest zit zo tussen de 5 en 25ms response, 80% heeft 6 hops nodig om bij de site te komen.

De 3 die niet lekker gaan komen uit Den Haag (klant van isp ziggo), Amsterdam (klant van isp Quanza) , Eindhoven (klant van Xs4all). Dit is op basis van hun IPv4 ASN, van IPv6 is deze onbekend dus ik vermoed dat het tunnels zijn, wat opvallend zou zijn bij Xs4all.

Dit wat natuurlijk maar een eenmalige meting, maar het lijkt niet echt provider issue.

Het kan natuurlijk zijn dat de VPS'sen achter andere infra zitten, maar die info had/heb ik niet.

[ Voor 37% gewijzigd door Verwijderd op 18-06-2014 09:17 ]

[DennusB]

Keiichi schreef op dinsdag 17 juni 2014 @ 22:16:
Heeft er iemand toevallig een TransIP VPS met ipv6?

De connectiviteit is belabberd en hun NOC kan niets vinden!

Jep, mijn bedrijf heeft er een VPS (www.deyron.nl & www.kilometertje.nl). Alle 2 bereikbaar via IPv6 en dat gaat als een trein. Wat voor problemen heb je precies?

[Roetzen]

Verwijderd schreef op woensdag 18 juni 2014 @ 08:36:
Als ik www.transip.nl gebruik (2a01:7c8:1337::1337) met 47 probes uit NL .

Hoe heb je die 47 probes geselecteerd? Op IPv6 uiteraard, maar dan zijn er nog meer dan 500 in NL. Ik kan niet zien of de mijn (probe #2462) er ook bij was. Maar ja, die heeft IPv6 via een he.net tunnel dus qua locatie komt die uit Amsterdam...

[Verwijderd]

Roetzen schreef op woensdag 18 juni 2014 @ 13:02:
[...]

Hoe heb je die 47 probes geselecteerd? Op IPv6 uiteraard, maar dan zijn er nog meer dan 500 in NL. Ik kan niet zien of de mijn (probe #2462) er ook bij was. Maar ja, die heeft IPv6 via een he.net tunnel dus qua locatie komt die uit Amsterdam...

Random, want ik weet niet welke server / site hij problemen mee heeft vandaar deze kleine test naar de website van de leverancier. Er is niet zoveel bekend over wat zijn problemen zijn, dus om er gelijk heel europa op los te laten gaat wat ver.

[Snow_King]

ZeelandNet heeft Dual-Stack aan gezet voor een select aantal klanten.

Op mijn verbinding werkt het (nog) niet, maar mijn collega's hebben al netjes IPv6 native richting hun routers gekregen en hebben IPv6 connectiviteit.

[Orion84]

FatalError schreef op maandag 16 juni 2014 @ 10:37:
Kennen jullie speedtest6.ziggo.nl al? Draait bij Ziggo zelf zo te zien.
Ik trek mijn XS4ALL 100/100 lijntje dicht met deze test.

Hmm, ergens vormt een van de schakels in mijn sixxs tunnel een beetje een bottleneck:

IPv6

vs

IPv4


Die IPv6 snelheid komt overeen met wat ik via IPv6 nieuwsgroepen haal (zo'n 10MB/s). Maar blijft dus ruim achter bij mijn IPv4 bandbreedte.

[Paul]

Het blijft natuurlijk een tunnel, de bandbreedte die zo'n PoP belangeloos beschikbaar stelt is ook niet oneindig kan ik me zo indenken, en alle tunnels naar een PoP komen op dezelfde plek uit lijkt me

[Maurits van Baerle]

Snow_King schreef op donderdag 19 juni 2014 @ 15:43:
ZeelandNet heeft Dual-Stack aan gezet voor een select aantal klanten.

Op mijn verbinding werkt het (nog) niet, maar mijn collega's hebben al netjes IPv6 native richting hun routers gekregen en hebben IPv6 connectiviteit.

Wanneer is dat precies gebeurd, weet je dat? Misschien verklaart dat wel de plotselinge groei in IPv6 verkeer op de AMS-IX. Er was gisteravond zelfs ineens een korte spike van zo'n 4Gb/s! Het was de afgelopen dagen zo rond de 20 Gb/s en dan ineens een piek naar bijna 26 Gb/s.

[ Voor 10% gewijzigd door Maurits van Baerle op 19-06-2014 16:31 ]

[Snow_King]

Maurits van Baerle schreef op donderdag 19 juni 2014 @ 16:29:
[...]

Wanneer is dat precies gebeurd, weet je dat? Misschien verklaart dat wel de plotselinge groei in IPv6 verkeer op de AMS-IX. Er was gisteravond zelfs ineens een korte spike van zo'n 4Gb/s! Het was de afgelopen dagen zo rond de 20 Gb/s en dan ineens een piek naar bijna 26 Gb/s.

Is in de afgelopen 24 uur gedaan. Weet niet exact hoe veel verbindingen het zijn.

[Maurits van Baerle]

Hoe zit het eigenlijk in dit geval? Ik neem aan dat ZeelandNet al een tijdje (jaren?) IPv6 compatible modems aan de klanten heeft geleverd. Moeten die klanten dan nog een handeling uitvoeren, stond hij automatisch al naar IPv6 te luisteren of moest er vanaf ZeelandNet een profiel gepusht worden?

Met andere woorden, zal binnen afzienbare tijd bijna iedere ZeelandNet abonnee automatisch op IPv6 zitten? Misschien zelfs zonder dat ze het weten?

[Snow_King]

Maurits van Baerle schreef op donderdag 19 juni 2014 @ 16:37:
Hoe zit het eigenlijk in dit geval? Ik neem aan dat ZeelandNet al een tijdje (jaren?) IPv6 compatible modems aan de klanten heeft geleverd. Moeten die klanten dan nog een handeling uitvoeren, stond hij automatisch al naar IPv6 te luisteren of moest er vanaf ZeelandNet een profiel gepusht worden?

Met andere woorden, zal binnen afzienbare tijd bijna iedere ZeelandNet abonnee automatisch op IPv6 zitten? Misschien zelfs zonder dat ze het weten?

De situatie wisselt, maar veel klanten hebben een Cisco modem+wifi router en daar kunnen ze dat profiel heen pushen.

[Verwijderd]

Snow_King schreef op donderdag 19 juni 2014 @ 15:43:
ZeelandNet heeft Dual-Stack aan gezet voor een select aantal klanten.

Op mijn verbinding werkt het (nog) niet, maar mijn collega's hebben al netjes IPv6 native richting hun routers gekregen en hebben IPv6 connectiviteit.

Ha nieuws, mooi! want ik hoorde vrij weinig en zag ook geen twitter updates Hey updates op Martijn van Dorst.


Ben benieuwd of zeeland net ook stats heeft, ik zal eens zoeken.

[ Voor 7% gewijzigd door Verwijderd op 19-06-2014 17:03 ]

[Nakebod]

Denk niet dat die piek van AMS-IX van dat selectief groepje zeelandnet gebruikers is tho.
Of het selectieve groepje is wel erg groot
Vanaf ~18.00 begint het lijntje omhoog te gaan, en rond ~20.00 is de piek. Stiekem zou ik zeggen dat het WK er iets mee te maken had. Allemaal facebook checken!

[Verwijderd]

Het lijkt erop dat UPC is begonnen met het uitrollen van IPv6 in Oostenrijk, wat meldingen van mensen op twitter, wat issues en een artikel http://derstandard.at/200...Pv6-bereits-teilweise-aus

Ben benieuwd

[Maurits van Baerle]

Verwijderd schreef op donderdag 19 juni 2014 @ 17:15:
Het lijkt erop dat UPC is begonnen met het uitrollen van IPv6 in Oostenrijk, wat meldingen van mensen op twitter, wat issues en een artikel http://derstandard.at/200...Pv6-bereits-teilweise-aus

Ben benieuwd

Ik ben ook benieuwd. Volgens Wikipedia heeft UPC in Oostenrijk zo'n half miljoen breedbandklanten. Dan zou de schamele 0,23% wel eens flink omhoog kunnen schieten.

[WouterG]

Ik had me aangemeld voor de IPv6 test van zeelandnet en daarom is nu ook dual-stack IPv4/6 bij me aangezet. Helaas werkte het bij mij niet out-of-the-box.

Van zeelandnet krijg ik een /48 maar daar lijkt mijn router (Zyxel NBG 6716) niet mee om te kunnen gaan. Ik kreeg de volgende foutmelding: daemon.warn radvd[xxx]: prefix length should be 64 for br-lan
Wat opvalt is dat de LAN interface van de router ook een /48 adres krijgt. Volgens mij zou dat sowieso een /64 (een enkel segment) moeten zijn toch?

Als workaround heb ik het adres van de LAN interface handmatig ingevuld als /64 in de network configuratiefile /etc/config/network waarna het wel werkte.

Nu maar even kijken hoe de support van Zyxel is.

[Verwijderd]

Een beetje afhankelijk van hoe zeelandnet werkt, je router zal volgens mij niet zelf een /48 gaan ophakken in /64 segmenten, want wat voor logica zou deze dan aanhouden voor het subnet adres?

Misschien een twitter naar https://twitter.com/martijnvandorst ?

[CyBeR]

Verwijderd schreef op vrijdag 20 juni 2014 @ 10:39:
Een beetje afhankelijk van hoe zeelandnet werkt, je router zal volgens mij niet zelf een /48 gaan ophakken in /64 segmenten, want wat voor logica zou deze dan aanhouden voor het subnet adres?

Dat is wel de bedoeling. De logica is meestal bij simpelere routers '0' voor het subnet.

[WouterG]

Ik heb Martijn van Dorst al via de mail op de hoogte gesteld van deze issue in het kader van de test. En daarnaast deze issue gemeld bij Zyxel, ben benieuwd naar hun reactie.

Naar mijn mening moet een consumenten-router zonder bijzondere configuratieaanpassingen een /48 omzetten naar een /64 en dat lijkt nu niet te gebeuren.

[Bigs]

Dit is een beetje willekeurig, maar wellicht dat iemand er via de zoekfunctie toch iets aan heeft (het was wat uitzoekwerk).

Als je merkt dat je via je Netgear XAVN2001 (of een soortgelijk Powerline AV access point) geen IPv6 verbinding krijgt dan is dat eenvoudig te verhelpen door verbinding te maken via telnet (met behulp van een telnetenable tool als deze) en het volgende commando te geven:

code:

nvram set wan_enable_ipv6_passthrough 1

Na een powercycle van het access point werkt IPv6 zoals je zou verwachten. De reden dat dit access point IPv6 compleet blokkeert is omdat het zo te zien nogal wat firmware deelt met routers die dit standaard doen maar een optie in de web interface hebben om het uit te schakelen.

_{Naar aanleiding van deze post uit september vorig jaar waarin ik het probleem constateerde}

[ Voor 9% gewijzigd door Bigs op 22-06-2014 19:59 ]

[moppentappers]

Is er eigenlijk ook een mogelijkheid om mer een ipv6 tunnel bijvoorbeeld tegen betaling wel meer bandbreedte te krijgen? Ik haal nu via hurricane electric zo'n 85Mbit, terwijl ik een glasvezel verbinding van 400/400 heb, eigenlijk dood zonde natuurlijk van al die beschikbare bandbreedte.

[Raven]

[e-mail] ?