Het grote IPv6 topic

[Verwijderd]

Missschien dat de UBEE inmiddels wel ICMPv6 door laat en dat OS firewall issue is?

[Jerrythafast]

Mijn Ubee 321b laat het met default instellingen niet door in ieder geval.

[Rainboww]

Ziggo is in Maastricht ook bezig met IPv6 uit te rollen!

Ging vandaag om 20u Chrome updaten, toen mijn firewall opeens wilde connecteren met een IPv6 adres van Google. ipconfig toonde idd aan dual stack aan.
http://ipv6-test.com geeft een score van 16 / 20
edit1: na aanpassing van de firewall (ICMPv6) wel 19 / 20 (alleen DNS6 + IP4 niet).
edit 2: 20 / 20 lukt ook, maar dan moet ik in de firewall een 'allow' rule maken voor ICMPv4 echo_request.
Maar dat is een security risk (ping flood).
Vreemd dat DNS6 + IP6 passed terwijl ik geen echo_request allow rule heb voor ICMPv6?

[ Voor 50% gewijzigd door Rainboww op 18-02-2016 23:27 ]

[Snow_King]

Op het gebied van mobile gebeurd er alleen nog helemaal niets. Zowel KPN, Vodafone en T-Mobile hebben nog geen stap in die richting gezet.

Heeft iemand ergens ingangen of informatie over IPv6 op 4G?

Vodafone announced nog niet eens een prefix: http://bgp.he.net/AS15480

In dat AS zit mijn 4G verbinding

[ Voor 21% gewijzigd door Snow_King op 18-02-2016 23:15 ]

[Zr40]

Vreemd genoeg is er wel een prefix announced vanuit de andere AS van Vodafone: http://bgp.he.net/AS33915

[ Voor 3% gewijzigd door Zr40 op 18-02-2016 23:24 ]

[Dutch2007]

Rainboww schreef op donderdag 18 februari 2016 @ 22:03:
Ziggo is in Maastricht ook bezig met IPv6 uit te rollen!

Ging vandaag om 20u Chrome updaten, toen mijn firewall opeens wilde connecteren met een IPv6 adres van Google. ipconfig toonde idd aan dual stack aan.
http://ipv6-test.com geeft een score van 16 / 20
edit1: na aanpassing van de firewall (ICMPv6) wel 19 / 20 (alleen DNS6 + IP4 niet).
edit 2: 20 / 20 lukt ook, maar dan moet ik in de firewall een 'allow' rule maken voor ICMPv4 echo_request.
Maar dat is een security risk (ping flood).
Vreemd dat DNS6 + IP6 passed terwijl ik geen echo_request allow rule heb voor ICMPv6?

Maybe soon dan toch maar us die technicolor laten laten activeren, kijken hoever 't is met IPv6 in regio kerkrade

[Zr40]

Rainboww schreef op donderdag 18 februari 2016 @ 22:03:
edit 2: 20 / 20 lukt ook, maar dan moet ik in de firewall een 'allow' rule maken voor ICMPv4 echo_request.
Maar dat is een security risk (ping flood).
Vreemd dat DNS6 + IP6 passed terwijl ik geen echo_request allow rule heb voor ICMPv6?

Klinkt eerder als toeval, je firewall aanpassing heeft waarschijnlijk geen invloed gehad op dat laatste punt.

offtopic:
Overigens valt ping flood onder 'denial of service'. Om dat een security risk te noemen vind ik eigenlijk te ver gaan. En daarnaast is een flood niet te voorkomen met firewall rules; je voorkomt hooguit dat je replies terug gaat sturen.

[Rainboww]

Verwijderd schreef op donderdag 18 februari 2016 @ 21:07:
Missschien dat de UBEE inmiddels wel ICMPv6 door laat en dat OS firewall issue is?

Jerrythafast schreef op donderdag 18 februari 2016 @ 21:23:
Mijn Ubee 321b laat het met default instellingen niet door in ieder geval.

Ik heb ook die Ubee 321b, bij mij werkt het gewoon?
Ik zou idd even in je firewall kijken, de enige allow rules voor ICMPv6 die nodig zijn:
- 1. adress unreachable
- 3. time exceeded

[Maurits van Baerle]

Rainboww schreef op donderdag 18 februari 2016 @ 23:46:
[...]


[...]

Ik heb ook die Ubee 321b, bij mij werkt het gewoon?
Ik zou idd even in je firewall kijken, de enige allow rules voor ICMPv6 die nodig zijn:
- 1. adress unreachable
- 3. time exceeded

Volgens moet mij je
Packet Too Big
ook doorlaten anders krijg je fragmentatieissues.

[CyBeR]

Rainboww schreef op donderdag 18 februari 2016 @ 23:46:
[...]


[...]

Ik heb ook die Ubee 321b, bij mij werkt het gewoon?
Ik zou idd even in je firewall kijken, de enige allow rules voor ICMPv6 die nodig zijn:
- 1. adress unreachable
- 3. time exceeded

Als je wilt dat je verbinding fatsoenlijk werkt moet je alle ICMPv6 door laten. Dat bestaat niet zonder reden.

[Rainboww]

CyBeR schreef op vrijdag 19 februari 2016 @ 00:16:
Als je wilt dat je verbinding fatsoenlijk werkt moet je alle ICMPv6 door laten. Dat bestaat niet zonder reden.

Nee dat klopt niet,
De IETF geeft dit zelf ook aan: het is een balance tussen stabiele communicatie en veiligheid.

Overly aggressive filtering of ICMPv6 by firewalls may have a detrimental effect on the establishment and maintenance of IPv6 communications.
On the other hand, allowing indiscriminate passage of all ICMPv6 messages can be a major security risk.
This document recommends a set of rules that seek to balance effective IPv6 communication against the needs of site security: http://tools.ietf.org/html/rfc4890
Zie eventueel ook : http://www.dslreports.com/forum/r2649460-Example-ICMP-rules

Maurits van Baerle schreef op vrijdag 19 februari 2016 @ 00:05:
Volgens moet mij je Packet Too Big ook doorlaten anders krijg je fragmentatieissues.

Ja ik heb het gevonden in de bovengenoemde IETF site, onder sectie 4.3.1.

[CyBeR]

Rainboww schreef op vrijdag 19 februari 2016 @ 00:31:
[...]

Nee dat klopt niet,
De IETF geeft dit zelf ook aan: het is een balance tussen stabiele communicatie en veiligheid.

Overly aggressive filtering of ICMPv6 by firewalls may have a detrimental effect on the establishment and maintenance of IPv6 communications.
On the other hand, allowing indiscriminate passage of all ICMPv6 messages can be a major security risk.
This document recommends a set of rules that seek to balance effective IPv6 communication against the needs of site security: http://tools.ietf.org/html/rfc4890
Zie eventueel ook : http://www.dslreports.com/forum/r2649460-Example-ICMP-rules

Fine, d'r zijn er twee die je mag droppen: echo request en (uitgaand) time exceeded, beide welke gebruikt kunnen worden om te scannen of hosts bestaan en hoe je netwerk in elkaar zit, als je dat belangrijk vindt. (Voor een publieke dienst is 't niet zo nuttig.)

Maar verder zie ik geen enkele reden om de normale ICMPv6 messages te droppen. Dat iets in een RFC staat maakt 't nog geen wet.

[Rainboww]

CyBeR schreef op vrijdag 19 februari 2016 @ 00:45:
Fine, d'r zijn er twee die je mag droppen: echo request en (uitgaand) time exceeded, beide welke gebruikt kunnen worden om te scannen of hosts bestaan en hoe je netwerk in elkaar zit, als je dat belangrijk vindt. (Voor een publieke dienst is 't niet zo nuttig.)

Maar verder zie ik geen enkele reden om de normale ICMPv6 messages te droppen. Dat iets in een RFC staat maakt 't nog geen wet.

Er zijn toch meer security risico's als ik het doorlees:
4.4.4. Traffic for Which a Policy Should Be Defined
Redirect messages (type 137) provide a significant security risk

Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)
There is a small risk that such messages could be used to provide a covert channel or form part of a DoS attack.

Administrators may also wish to consider providing rules in firewall/routers to catch illegal packets sent with hop limit = 1 to avoid ICMPv6 Time Exceeded messages being generated for these packets.
en zie verder ook nog 4.4.5.

Dus waarom zou je niet alles blokken behalve de essentials? Lijkt me zowel veiliger als makkelijker dan 1 voor 1 exceptions in te stellen.

[CyBeR]

Rainboww schreef op vrijdag 19 februari 2016 @ 00:55:
[...]

Er zijn toch meer security risico's als ik het doorlees:
4.4.4. Traffic for Which a Policy Should Be Defined
Redirect messages (type 137) provide a significant security risk

Werkt alleen link-local dus daar doet je router weinig tegen. Op een host firewall in een untrusted netwerk zou 't nuttig zijn ja. Een compliant implementatie van de IPv6 stack verifieert ICMPv6 redirects al zodanig dat je ze niet vanaf het internet kunt sturen en dat ze dan iets doen.

Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)
There is a small risk that such messages could be used to provide a covert channel or form part of a DoS attack.

Dat geldt net zo hard voor elk ander type, net als elke andere vorm van communicatie die je firewall wel toestaat.

Administrators may also wish to consider providing rules in firewall/routers to catch illegal packets sent with hop limit = 1 to avoid ICMPv6 Time Exceeded messages being generated for these packets.
en zie verder ook nog 4.4.5.

Dat is ook link-local want een packet met hop-limit = 1 komt niet door het internet heen.

Dus waarom zou je niet alles blokken behalve de essentials? Lijkt me zowel veiliger als makkelijker dan 1 voor 1 exceptions in te stellen.

Ik blacklist liever ipv te whitelisten en tot dusverre ben ik niet overtuigd van je argumenten om dat om te draaien.

[ Voor 10% gewijzigd door CyBeR op 19-02-2016 02:27 ]

[Compizfox]

Ik heb ICMP ook gewoon openstaan (zowel IPv4 als IPv6). Laat ze maar lekker pingen, ik zie het probleem niet.

Sterker nog, ik vind het erg vervelend als een host ICMP blokkeert omdat je dan ping niet als diagnostische tool kunt gebruiken of zelfs op het verkeerde spoor wordt gezet.

[ Voor 44% gewijzigd door Compizfox op 19-02-2016 02:36 ]

[Wildy]

stormfly schreef op donderdag 18 februari 2016 @ 20:12:
[...]


Je kan "iets" zien als je een traceroute doet naar nu.nl oid. Welke hostnamen zie je dan voorbij komen? MND HVS ?

Traceroute via IPv6 naar google.nl:

code:

Tracing route to google.nl [2a00:1450:4013:c00::5e]
over a maximum of 30 hops:

  1     6 ms     8 ms     6 ms  ipv6.dynamic.ziggo.nl [2001:1c02:2e00::1]
  2     7 ms     5 ms     7 ms  hvs-rc0002-cr102-xe-1-3-1-0.core.as9143.net [2001:b88:0:d03::1]
  3     8 ms     6 ms     7 ms  asd-tr0610-cr101-ae57-0.core.as9143.net [2001:b88:0:116::1]
  4     7 ms     9 ms     7 ms  2001:b88:0:40d::2
  5     7 ms     8 ms    10 ms  2001:4860::1:0:87ab
  6     8 ms    46 ms     8 ms  2001:4860::8:0:87b0
  7    11 ms    12 ms    17 ms  2001:4860::8:0:519e
  8    14 ms    13 ms    10 ms  2001:4860::2:0:8651
  9     *        *        *     Request timed out.
 10    11 ms    11 ms    10 ms  ee-in-x5e.1e100.net [2a00:1450:4013:c00::5e]

IPv4 traceroute:

code:

Tracing route to google.nl [74.125.136.94]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.178.1
  2     6 ms     5 ms     5 ms  10.254.221.1
  3     5 ms     7 ms    10 ms  mnd-rc0001-cr101-xe-1-3-1-0.core.as9143.net [213.51.189.252]
  4    17 ms    19 ms     5 ms  asd-tr0042-cr101-ae7-0.core.as9143.net [213.51.158.2]
  5     6 ms     6 ms     6 ms  72.14.203.144
  6     7 ms     6 ms     8 ms  209.85.143.181
  7    14 ms     8 ms     8 ms  209.85.248.247
  8    22 ms     9 ms     9 ms  66.249.95.21
  9    10 ms     8 ms    12 ms  216.239.49.30
 10     *        *        *     Request timed out.
 11    12 ms     9 ms    10 ms  ea-in-f94.1e100.net [74.125.136.94]

Ik heb dus bij IPv4 mnd en bij IPv6 hvs.

[Verwijderd]

De link die ik gebruikte voor de KPN nummer (naam) centrales waar veel van deze router hops op gebaseerd zijn doet het helaas niet meer. En ook DDEC resolved niet meer voor core.as9143.net http://ddec.caida.org/

Maar hier is een nieuwe: http://hulpvanstudenten.nl/wijkcentrales/

Nu is dit ook geen exacte wetenschap, op basis van de RCM LC, TR in de naam in combinatie met wat je ziet bij welke steden lijkt het op regio, stad en wijk centrales te duiden.

[Snow_King]

Zr40 schreef op donderdag 18 februari 2016 @ 23:24:
Vreemd genoeg is er wel een prefix announced vanuit de andere AS van Vodafone: http://bgp.he.net/AS33915

Klopt, als je dat AS echter goed bekijkt is dat Vodafone Zakelijk. Lijkt de zakelijke glasverbindingen van hen te zijn.

[stormfly]

Wildy schreef op vrijdag 19 februari 2016 @ 07:55:
[...]


Traceroute via IPv6 naar google.nl:

code:

Tracing route to google.nl [2a00:1450:4013:c00::5e]
over a maximum of 30 hops:

  1     6 ms     8 ms     6 ms  ipv6.dynamic.ziggo.nl [2001:1c02:2e00::1]
  2     7 ms     5 ms     7 ms  hvs-rc0002-cr102-xe-1-3-1-0.core.as9143.net [2001:b88:0:d03::1]
  3     8 ms     6 ms     7 ms  asd-tr0610-cr101-ae57-0.core.as9143.net [2001:b88:0:116::1]
  4     7 ms     9 ms     7 ms  2001:b88:0:40d::2
  5     7 ms     8 ms    10 ms  2001:4860::1:0:87ab
  6     8 ms    46 ms     8 ms  2001:4860::8:0:87b0
  7    11 ms    12 ms    17 ms  2001:4860::8:0:519e
  8    14 ms    13 ms    10 ms  2001:4860::2:0:8651
  9     *        *        *     Request timed out.
 10    11 ms    11 ms    10 ms  ee-in-x5e.1e100.net [2a00:1450:4013:c00::5e]

IPv4 traceroute:

code:

Tracing route to google.nl [74.125.136.94]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.178.1
  2     6 ms     5 ms     5 ms  10.254.221.1
  3     5 ms     7 ms    10 ms  mnd-rc0001-cr101-xe-1-3-1-0.core.as9143.net [213.51.189.252]
  4    17 ms    19 ms     5 ms  asd-tr0042-cr101-ae7-0.core.as9143.net [213.51.158.2]
  5     6 ms     6 ms     6 ms  72.14.203.144
  6     7 ms     6 ms     8 ms  209.85.143.181
  7    14 ms     8 ms     8 ms  209.85.248.247
  8    22 ms     9 ms     9 ms  66.249.95.21
  9    10 ms     8 ms    12 ms  216.239.49.30
 10     *        *        *     Request timed out.
 11    12 ms     9 ms    10 ms  ea-in-f94.1e100.net [74.125.136.94]

Ik heb dus bij IPv4 mnd en bij IPv6 hvs.

Tnx helder, dan is de POP (HVS en MND) al voorbereid. Dan zijn de activatie handeling dus lokaal in de steden op de overgang van coax naar glas (CMTS en HFC)

Dan is het afwachten wanneer Utrecht oost aan de beurt is.

[Maurits van Baerle]

Voor wie zich zorgen maakt over het doorlaten van ICMP verkeer en het risico op DOS attacks, ping floods etc, je zou natuurlijk inkomend verkeer kunnen rate-limitten.

De firewall in OpenWRT laat bijvoorbeeld standaard ICMPv6 verkeer door maar niet meer dan 1000 packets per seconde. Dat is voldoende voor veel thuissituaties en andere kleine netwerken. Voor bedrijfstoepassingen moet het misschien wel hoger worden ingesteld.

[Snow_King]

Snow_King schreef op donderdag 18 februari 2016 @ 23:13:
Op het gebied van mobile gebeurd er alleen nog helemaal niets. Zowel KPN, Vodafone en T-Mobile hebben nog geen stap in die richting gezet.

Heeft iemand ergens ingangen of informatie over IPv6 op 4G?

Vodafone announced nog niet eens een prefix: http://bgp.he.net/AS15480

In dat AS zit mijn 4G verbinding

T-Mobile Nederland is het zelfde verhaal: http://bgp.he.net/AS31615

KPN ook: http://bgp.he.net/AS1134

Dus zowel Vodafone, KPN en T-Mobile announcen nog geen IPv6 prefix...

[ Voor 4% gewijzigd door Snow_King op 19-02-2016 12:31 ]

[Zr40]

Tele2 heeft wel IPv6 prefixes, maar niet voor Nederland: http://bgp.he.net/AS1257

[Verwijderd]

Snow_King schreef op vrijdag 19 februari 2016 @ 12:29:
[...]

T-Mobile Nederland is het zelfde verhaal: http://bgp.he.net/AS31615

KPN ook: http://bgp.he.net/AS1134

Dus zowel Vodafone, KPN en T-Mobile announcen nog geen IPv6 prefix...

En t-mobile heeft het makkelijk omdat t-mobile usa grotendeels IPv6 only is. Een paar mensen vanuit de USA laten meedenken in het plan en de opzet en het zou snel kunnen gaan.

[Snow_King]

Zr40 schreef op vrijdag 19 februari 2016 @ 12:42:
Tele2 heeft wel IPv6 prefixes, maar niet voor Nederland: http://bgp.he.net/AS1257

Dus daar schieten we ook niets mee op..

Dit was overigens het antwoord van Vodafone (waar ik klant ben): https://twitter.com/vodafoneNL/status/700601524074979328

Hier heb ik helaas geen informatie over. ^LM

Nou, wie wel?

Verwijderd schreef op vrijdag 19 februari 2016 @ 12:51:
[...]


En t-mobile heeft het makkelijk omdat t-mobile usa grotendeels IPv6 only is. Een paar mensen vanuit de USA laten meedenken in het plan en de opzet en het zou snel kunnen gaan.

Uit goede bronnen heb ik vernomen dat T-Mobile USA met zijn 50 miljoen klanten de aanjager is waarom WhatsApp IPv6 aan het inschakelen is. VOIP heeft nu de hoogste prioriteit, want VOIP + UDP + CGNAT werken niet lekker.

De user-experience bij T-Mobile USA is voor WhatsApp nu slecht en dat willen ze snel oplossen.

Zo zien we maar weer, IPv6 is beter.

[Maurits van Baerle]

Ik maak me totaal geen zorgen over de uitrol van IPv6 op mobiele netwerken, dat komt wel goed.

1) Het is veel makkelijker om bestaande mobiele netwerken om te zetten omdat ze veel moderner zijn. Bij de recente upgrade van het Circuit Switched 3G naar het Packet Switched 4G zal een hoop van de apparatuur vernieuwd zijn. Bovendien zijn ze een stuk homogener dan vaste netwerken die veel meer een aan elkaar geknoopt zooitje zullen zijn.
2) Het client landschap (de telefoons en dongles) zal ook veel homogener zijn met veel minder configuraties om rekening mee te houden. Hoeveel verschillende modem+router combinaties zullen er wereldwijd wel niet mogelijk zijn met vaste aansluitingen, honderduizenden? Mobiel heeft bijna iedereen een Qualcomm modem. Nu Apple IPv6 support in apps verplicht stelt zal het helemaal hard gaan. Waarom zou je als app developer dan niet ook niet alles op Android in een keer IPv6 compatible maken? Je back-end moet het toch al ondersteunen voor iOS.
3) Vanwege de relatief late opkomst van het mobiele internet, toen de IPv4 adressen al bijna op waren, zit daar nu veel achter complexe CGNAT of XLAT constructies. Hoe eerder dat naar gewoon dual stack kan hoe eerder de operators van de complexe (en dure) constructies af kunnen. Ze hebben een goede reden voor dual stack of DS Lite te gaan.

Ik denk dat de wereldwijde overstap naar IPv6 op mobiel al op 90% zal zitten voordat IPv6 op vaste lijnen de 50% zal hebben gehaald. Het zou me helemaal niets verbazen als ten minste één Nederlandse telco voor het eind van dit jaar helemaal over is op IPv6 zonder dat ze nu ook maar iets hebben aangekondigd.

[ Voor 5% gewijzigd door Maurits van Baerle op 19-02-2016 13:45 ]

[Snow_King]

Maurits van Baerle schreef op vrijdag 19 februari 2016 @ 13:43:
Ik maak me totaal geen zorgen over de uitrol van IPv6 op mobiele netwerken, dat komt wel goed.

1) Het is veel makkelijker om bestaande mobiele netwerken om te zetten omdat ze veel moderner zijn. Bij de recente upgrade van het Circuit Switched 3G naar het Packet Switched 4G zal een hoop van de apparatuur vernieuwd zijn. Bovendien zijn ze een stuk homogener dan vaste netwerken die veel meer een aan elkaar geknoopt zooitje zullen zijn.
2) Het client landschap (de telefoons en dongles) zal ook veel homogener zijn met veel minder configuraties om rekening mee te houden. Hoeveel verschillende modem+router combinaties zullen er wereldwijd wel niet mogelijk zijn met vaste aansluitingen, honderduizenden? Mobiel heeft bijna iedereen een Qualcomm modem. Nu Apple IPv6 support in apps verplicht stelt zal het helemaal hard gaan. Waarom zou je als app developer dan niet ook niet alles op Android in een keer IPv6 compatible maken? Je back-end moet het toch al ondersteunen voor iOS.
3) Vanwege de relatief late opkomst van het mobiele internet, toen de IPv4 adressen al bijna op waren, zit daar nu veel achter complexe CGNAT of XLAT constructies. Hoe eerder dat naar gewoon dual stack kan hoe eerder de operators van de complexe (en dure) constructies af kunnen. Ze hebben een goede reden voor dual stack of DS Lite te gaan.

Ik denk dat de wereldwijde overstap naar IPv6 op mobiel al op 90% zal zitten voordat IPv6 op vaste lijnen de 50% zal hebben gehaald. Het zou me helemaal niets verbazen als ten minste één Nederlandse telco voor het eind van dit jaar helemaal over is op IPv6 zonder dat ze nu ook maar iets hebben aangekondigd.

Dat ben ik ook wel met je eens, maar waarom duurt het allemaal zo lang? Ik wil gewoon IPv6 op mijn telefoon, kan ik gewoon fatsoenlijk SIP gebruiken bijvoorbeeld.

[agresionpower]

Er staan weer nieuwe meet resultaten op: http://www.worldipv6launch.org/measurements/

Ziggo is van 0.37% naar 1.21% gegaan.

edit: de resultaten zijn wel al van 10 feb. dus nog voor de uitrol van deze week.

[ Voor 25% gewijzigd door agresionpower op 20-02-2016 01:02 ]

[Jerrythafast]

agresionpower schreef op zaterdag 20 februari 2016 @ 00:57:
Er staan weer nieuwe meet resultaten op: http://www.worldipv6launch.org/measurements/

Ziggo is van 0.37% naar 1.21% gegaan.

edit: de resultaten zijn wel al van 10 feb. dus nog voor de uitrol van deze week.

Ik ontdekte dat ik IPv6 had op 7 februari, dus ik heb in ieder geval bijgedragen aan die getallen

[Maurits van Baerle]

agresionpower schreef op zaterdag 20 februari 2016 @ 00:57:
Er staan weer nieuwe meet resultaten op: http://www.worldipv6launch.org/measurements/

Ziggo is van 0.37% naar 1.21% gegaan.

edit: de resultaten zijn wel al van 10 feb. dus nog voor de uitrol van deze week.

APNIC laat ook een forse stijging zien:


Bron (even op de maand view klikken):
http://stats.labs.apnic.n...&c=NL&x=1&s=1&p=1&w=1&s=0

[Roetzen]

Maurits van Baerle schreef op zaterdag 20 februari 2016 @ 12:24:
[...]
APNIC laat ook een forse stijging zien:

Het lijkt nu inderdaad op gang te komen. Maar voor mij is het echt nog te vroeg om te gaan juichen. We hebben bij Ziggo al eerder gezien dat het weer teruggedraaid werd, Dus ik wacht het nog even af.

Jerrythafast schreef op zaterdag 20 februari 2016 @ 09:54:

Ik ontdekte dat ik IPv6 had op 7 februari, dus ik heb in ieder geval bijgedragen aan die getallen

Is je IPv6 adres stabiel? Het is al die tijd hetzelfde gebleven?

[Verwijderd]

Roetzen schreef op zaterdag 20 februari 2016 @ 12:31:
[...]

Het lijkt nu inderdaad op gang te komen. Maar voor mij is het echt nog te vroeg om te gaan juichen. We hebben bij Ziggo al eerder gezien dat het weer teruggedraaid werd, Dus ik wacht het nog even af.

[...]

Is je IPv6 adres stabiel? Het is al die tijd hetzelfde gebleven?

Zover ik weet is een IPv6 statis bij UPC / Ziggo tenzij er een failover van wijkcentrale is. Iets wat weinig voorkomt, maar kan gebeuren. Net zo als bij ipv heb je dan dat het static is zolang je modem niet voor lange tijd uit staat.

[Jerrythafast]

Roetzen schreef op zaterdag 20 februari 2016 @ 12:31:
[...]

Het lijkt nu inderdaad op gang te komen. Maar voor mij is het echt nog te vroeg om te gaan juichen. We hebben bij Ziggo al eerder gezien dat het weer teruggedraaid werd, Dus ik wacht het nog even af.

[...]

Is je IPv6 adres stabiel? Het is al die tijd hetzelfde gebleven?

Kort nadat ik het die dag ontdekte ging mijn modem rebooten voor een firmware-update. Toen hij weer online kwam kreeg ik een ander IPv6-prefix. Ik heb mijn huidige adressen even (digitaal) opgeschreven, kijken hoe lang ik deze houd.

[Roetzen]

Jerrythafast schreef op zaterdag 20 februari 2016 @ 12:47:
[...]

Kort nadat ik het die dag ontdekte ging mijn modem rebooten voor een firmware-update. Toen hij weer online kwam kreeg ik een ander IPv6-prefix. Ik heb mijn huidige adressen even (digitaal) opgeschreven, kijken hoe lang ik deze houd.

Ik vroeg er naar omdat het gerucht gaat dat Comcast in de VS en ook ISPs in Duitsland en Oostenrijk geen statische IPv6 prefixen uitgeven. Ze veranderen niet zo heel vaak, in de orde van een maand, maar wel vaak genoeg om hinderlijk te zijn voor wie servers draait.

[Jerrythafast]

Roetzen schreef op zaterdag 20 februari 2016 @ 12:52:
[...]

Ik vroeg er naar omdat het gerucht gaat dat Comcast in de VS en ook ISPs in Duitsland en Oostenrijk geen statische IPv6 prefixen uitgeven. Ze veranderen niet zo heel vaak, in de orde van een maand, maar wel vaak genoeg om hinderlijk te zijn voor wie servers draait.

Op de DDNS pagina in het modem staat in ieder geval alleen mijn IPv4-adres vermeld. Al heb ik geen idee of no-ip.com en DynDNS.org ook IPv6-support hebben.

[Raven]

Jerrythafast schreef op zaterdag 20 februari 2016 @ 13:09:
DynDNS.org

Tegenwoordig http://dyn.com

[Jerrythafast]

Raven schreef op zaterdag 20 februari 2016 @ 13:12:
[...]

Tegenwoordig http://dyn.com

Klopt, al redirect DynDNS.org naar die website. In het modem kun je alleen kiezen voor no-ip.com of DynDNS.org dus vandaar dat ik het bij die naam noemde.

[andy88]

Sinds dat Ziggo bij mij afgelopen week IPv6 heeft geactiveerd geven Google diensten volledig willekeurig een time out. Het resolven lukt dan niet en een trace loopt gelijk dood. Andere IPv6 services zoals Youtube werken op dat moment wel.

Vraag me af wat dit kan zijn.

[Raven]

Mijn 1e gedachte: MTU probleem. Laat je firewall ICMPv6 packet-too-big door? Of is dat alleen een probleemgeval bij tunnels

[stormfly]

andy88 schreef op zaterdag 20 februari 2016 @ 20:41:
Sinds dat Ziggo bij mij afgelopen week IPv6 heeft geactiveerd geven Google diensten volledig willekeurig een time out. Het resolven lukt dan niet en een trace loopt gelijk dood. Andere IPv6 services zoals Youtube werken op dat moment wel.

Vraag me af wat dit kan zijn.

Laat eens zien wat je aan dns servers krijgt? Iemand op het ziggo forum kreeg ook een :: naast de reguliere dns servers. En melde dat hij daardoor ook vreemd gedrag had (op een Mac).

[CyBeR]

Raven schreef op zaterdag 20 februari 2016 @ 21:05:
Mijn 1e gedachte: MTU probleem. Laat je firewall ICMPv6 packet-too-big door? Of is dat alleen een probleemgeval bij tunnels

Dat is voornamelijk, doch niet alleen, een probleem bij tunnels. Maar uiteindelijk is dat overal waar ergens een MTU-afknijper tussen zit een probleem. De minimaal gegarendeerd bruikbare MTU is 1280, waar ethernet 1500 doet.

Overigens is 't een probleem andersom dan meestal bij dit soort dingen: als jij praat met iemand die een MTU-limitatie heeft op traffic die jij verstuurt, moet je die ICMP kunnen ontvangen. M.a.w., de verzender moet de ICMP niet blokkeren.

[ Voor 20% gewijzigd door CyBeR op 20-02-2016 21:26 ]

[ik222]

Ik heb in het verleden willekeurige IPv6 timeouts gehad vanwege een gare D-Link router, zelfs alleen als Wi-Fi AP raakte deze voor wat betreft IPv6 meerdere keren per uur de weg kwijt.

Oplossing was uiteindelijk het ding afschrijven.

[Raven]

CyBeR schreef op zaterdag 20 februari 2016 @ 21:24:
[...]


Dat is voornamelijk, doch niet alleen, een probleem bij tunnels. Maar uiteindelijk is dat overal waar ergens een MTU-afknijper tussen zit een probleem. De minimaal gegarendeerd bruikbare MTU is 1280, waar ethernet 1500 doet.

Ok.

CyBeR schreef op zaterdag 20 februari 2016 @ 21:24:
Overigens is 't een probleem andersom dan meestal bij dit soort dingen: als jij praat met iemand die een MTU-limitatie heeft op traffic die jij verstuurt, moet je die ICMP kunnen ontvangen. M.a.w., de verzender moet de ICMP niet blokkeren.

Dat doet Google nog wel eens heb ik gemerkt

[CyBeR]

Google doet 't goed tegenwoordig (heb ik namelijk geen last meer mee) maar Tumblr is nog problematisch bijvoorbeeld. Die kan ik over IPv6 niet laden omdat ik een tunnel heb en zij die ICMP blijkbaar blokkeren.

[Raven]

Nu je het zegt, het gebeurt hier ook regelmatig dat Tumblr niet werkt (blijft laden zonder dat er wat weergegeven wordt) en de fallback naar IPv4 werkt bij Tumblr ook niet. Laatst maar een van de image-servers met IPv4 adres in de hostfile gezet, als ik er weer wat tegenkom, komen die er ook in te staan.

Heb overigens al wel een mail die kant op gestuurd met de vraag hun IPv6-config te checken of die helemaal te disablen

[ Voor 28% gewijzigd door Raven op 20-02-2016 21:38 ]

[andy88]

stormfly schreef op zaterdag 20 februari 2016 @ 21:23:
[...]


Laat eens zien wat je aan dns servers krijgt? Iemand op het ziggo forum kreeg ook een :: naast de reguliere dns servers. En melde dat hij daardoor ook vreemd gedrag had (op een Mac).

Ik verkrijg (via dhcp) netjes de adressen van OpenDNS, zie ipconfig /all:

code:

   DNS Servers . . . . . . . . . . . : 2001:b88:1002::10
                                       2001:b88:1202::10
                                       208.67.222.222
                                       208.67.220.220

Vreemde is ook dat het driekwart van de tijd wél goed werkt.

Ben er inmiddels achter dat het probleem breder is:
Als ik op dergelijke momenten ipv6-test.com bezoek krijg ik een score van 4/20 waar dat normaal 19/20 of 20/20 is (browser afhankelijk).

Hoop dat ik er snel achter ben wat dit is anders mogen ze het weer uitschakelen

[ Voor 16% gewijzigd door andy88 op 20-02-2016 22:19 ]

[Maurits van Baerle]

Heb je misschien nog ergens DNS caches met oudere informatie? Heb je sinds je IPv6 hebt al eens alles herstart (modem, evt. router achter modem, alle clients etc)?

[Verwijderd]

Is het ds of ds-lite? Wat voor OS, komt het ook op andere os'en voor? Lijkt me erg belangrijk om dit op te lossen, ziggo draait anders zo weer hun uitrol terug als ze het niet snappen. Zou niet voor het eerst zijn.

[databeestje]

Ik wacht stilletjes af tot mijn pfSense achter een bridge modem een prefix oppikt. Misschien gaat dat nog vlot gebeuren als deze uitrol voorspoedig gaat.

Op een gegeven moment gooien ze die knop wel om. Ook handig voor de mensen die nog een motorola surfboard hebben.

[Roetzen]

databeestje schreef op zaterdag 20 februari 2016 @ 22:58:
IOp een gegeven moment gooien ze die knop wel om. Ook handig voor de mensen die nog een motorola surfboard hebben.

Ik heb er nog een. Maar ik verwacht niet dat ik ooit native IPv6 kan doen met dat ding.

[Verwijderd]

andy88 schreef op zaterdag 20 februari 2016 @ 22:17:
[...]


Ik verkrijg (via dhcp) netjes de adressen van OpenDNS, zie ipconfig /all:

code:

   DNS Servers . . . . . . . . . . . : 2001:b88:1002::10
                                       2001:b88:1202::10
                                       208.67.222.222
                                       208.67.220.220

Vreemde is ook dat het driekwart van de tijd wél goed werkt.

Ben er inmiddels achter dat het probleem breder is:
Als ik op dergelijke momenten ipv6-test.com bezoek krijg ik een score van 4/20 waar dat normaal 19/20 of 20/20 is (browser afhankelijk).

Hoop dat ik er snel achter ben wat dit is anders mogen ze het weer uitschakelen

Al iets kunnen vinden? Heb je al eens geprobeerd om zelf de DNS servers op te geven en bv die van google te gebruiken?

2001:4860:4860::8888
2001:4860:4860::8844

[Zsub]

databeestje schreef op zaterdag 20 februari 2016 @ 22:58:
Ik wacht stilletjes af tot mijn pfSense achter een bridge modem een prefix oppikt. Misschien gaat dat nog vlot gebeuren als deze uitrol voorspoedig gaat.

Op een gegeven moment gooien ze die knop wel om. Ook handig voor de mensen die nog een motorola surfboard hebben.

Volgens mij zijn de Ubee's zonder wifi de oudste modems die Ziggo uitgegeven heeft die überhaupt een kans maken, omdat IPv6-ondersteuning pas bij DOCSIS3 gekomen is, en die Surfboards DOCSIS2 modems zijn.

[Maurits van Baerle]

databeestje schreef op zaterdag 20 februari 2016 @ 22:58:
Ik wacht stilletjes af tot mijn pfSense achter een bridge modem een prefix oppikt. Misschien gaat dat nog vlot gebeuren als deze uitrol voorspoedig gaat.

Op een gegeven moment gooien ze die knop wel om.

Hoe beperkend is die Router Mode in de verschillende Ziggo modems?

Zou je bijvoorbeeld het modem terug in Router Mode kunnen laten zetten, zelf de router er achter in de DMZ van het Ziggo modem kunnen zetten, misschien wat met Static Routes aan de slag gaan en de router er achter publieke IP adressen uit de PD kunnen laten uitdelen? Dan zou je met een eigen router toch nu al gebruik kunnen maken van IPv6.

[Roetzen]

Zsub schreef op zondag 21 februari 2016 @ 12:56:
[...]

Volgens mij zijn de Ubee's zonder wifi de oudste modems die Ziggo uitgegeven heeft die überhaupt een kans maken, omdat IPv6-ondersteuning pas bij DOCSIS3 gekomen is, en die Surfboards DOCSIS2 modems zijn.

Er is een extensie voor DOCSIS 2.0 die IPv6 toevoegt. In theorie zou het misschien mogelijk zijn de Surfboards van een firmware upgrade te voorzien.

Maar ik verwacht niet dat dat zal gebeuren omdat de laagste snelheid die Ziggo nu aanbiedt 40 Mbps is. En dat kunnen de surfboards niet aan. Die houden het bij 30-35 Mbps voor gezien. Dus dat handjevol dat nog in omloop is zal hoe dan ook vervangen worden.

[ Voor 28% gewijzigd door Roetzen op 21-02-2016 13:25 ]

[Verwijderd]

Is er ondertussen eigenlijk al bekend wat Ziggo gaat doen voor bestaande klanten in oud-UPC-gebied? Want als ik zo de reacties op fora en nieuwssites lees, is echt niemand het daar over eens.

Ik zit in de regio Rijnmond (allemaal UPC tot maart vorig jaar), en ik heb een Ubee EVW3226 in bridge mode. In de Ubee-firmware uiteraard nog niets te zien over IPv6, maar als ik het zo hoor, is Ziggo wel overal bezig om de CMTS'en gereed te maken. (Of is dat ook alleen maar in oud-Ziggo-gebied?)

Het enige dat ik vooralsnog heb gehoord is dat nieuwe oud-UPC-klanten een IPv6-adres zouden krijgen met IPv4 achter CGNAT. Uit oud-Ziggo-gebied hoor ik dan wel weer mensen die nu ineens een IPv6-blok hebben, en dan ook nog hun oude IPv4-adres als echte dual stack. Maar ik hoor ook weer van ze dat modems in bridge mode dus niet ondersteund gaan worden, terwijl anderen weer beweren dat ze het wel werkend hebben. (En andere DOCSIS-providers doen dit toch wel gewoon?)

Verder lijkt iedereen te vallen over GCNAT voor IPv4. Dat maakt mij dan weer niets uit. Servers horen in een datacenter en spelcomputers zijn stom. Verder moet iedere site gewoon IPv6 doen.

Waar ik meer over val is die onduidelijke berichtgeving over ex-UPC en bridge mode (in alle regio's), omdat ik niet snap waarom dat niet zou kunnen. Met IPv4 doet een modem niets anders dan een QAM-signaal omzetten in ethernet en reageren Ziggo's servers op een DHCP-request van je eigen router. Waarom zouden ze dan niet reageren op een DHCPv6-request? Ik ben geen expert op het gebied, maar ik snap niet echt wat daar zo lastig aan zou zijn..

Ziggo-medewerkers zeggen ook allemaal iets anders (en de meesten hebben geen idee wat IPv6 is), dus ik word er wel een beetje moe van zo..

[Jerrythafast]

Ik heb vandaag in ieder geval mijn domeinnaam overgezet naar een IPv6-enabled club. Site staat wel nog op de servers van mijn oude webhostingprovider, want dat abonnement loopt nog een maandje. Heb ik intussen de tijd om een eenvoudig webservertje thuis op te zetten. Welke dankzij mijn dual stack verbinding in theorie straks op beide protocollen kan serveren

Ik heb het nu zo ingesteld dat het DNS A-record verwijst naar het IP van mijn oude webhostingprovider. Het AAAA-record heb ik nog even op de default laten staan, wat deze mooie pagina* oplevert via IPv6. Op een of andere manier krijg ik toch steeds netjes de website geserveerd over IPv4 als ik hem opvraag in Firefox of Edge. Zal wel weer de magie van de happy eyeballs implementaties van beide browsers zijn. In theorie is mijn domein nu toch erg slecht bereikbaar voor de IPv6-enabled 8% van het internet?

*http://[2a01:7c8:1337::3:7005:3691]/

[ Voor 13% gewijzigd door Jerrythafast op 21-02-2016 16:34 . Reden: Tweakers ondersteunt geen IPv6 HTTP links :/ ]

[Dutch2007]

databeestje schreef op zaterdag 20 februari 2016 @ 22:58:
Ik wacht stilletjes af tot mijn pfSense achter een bridge modem een prefix oppikt. Misschien gaat dat nog vlot gebeuren als deze uitrol voorspoedig gaat.

Op een gegeven moment gooien ze die knop wel om. Ook handig voor de mensen die nog een motorola surfboard hebben.

Als die mensen bellen naar ziggo, krijgen ze gewoon gratis een ubee/cisco

Zet 't beesie in bridge mode heb je meer snelheid voor zelfde geld ;-) (wel mogelijk pas later IPv6)

[Verwijderd]

http://ziggo-gebruikers.n...hread.php?t=49125&page=23

Interessant, Ziggo met router achter router. Standaard prefix delegation aan of zou hij het hebben aangezet? Dan vervolgens een /59 voor lan prefix.

[tcviper]

Verwijderd schreef op zondag 21 februari 2016 @ 20:13:
http://ziggo-gebruikers.n...hread.php?t=49125&page=23

Interessant, Ziggo met router achter router. Standaard prefix delegation aan of zou hij het hebben aangezet? Dan vervolgens een /59 voor lan prefix.

Ja maar dan is het dus niet bridge mode en dat maakt sommige dingen niet zo fijn voor IPv4 (NAT).

[easyriider]

Verwijderd schreef op zondag 21 februari 2016 @ 20:13:
Interessant, Ziggo met router achter router. Standaard prefix delegation aan of zou hij het hebben aangezet? Dan vervolgens een /59 voor lan prefix.

Hij heeft alleen het connection type op native gezet en de rest van de opties op de standaardwaarden laten staan.



Het Ubee modem krijgt een /56 van Ziggo, maar als die dat zou weggeven houdt hij zelf niets over, dus een /59 prefix voor één of meerdere aangesloten routers lijkt me redelijk.

[Verwijderd]

In principe zouden thuis apparaten zoals routers en accesspoints zonder aanpassingen ipv6 pd moeten doen, zodat het plug en play is. Ipv4 is en blijft niet ideaal (nat op nat op nat) maar uitgaande van meer IPv6 zou dit wel uit zichzelf moeten werken. Het is dan in iedergeval routing.

[ Voor 10% gewijzigd door Verwijderd op 21-02-2016 21:33 ]

[Verwijderd]

tcviper schreef op zondag 21 februari 2016 @ 20:49:
[...]
Ja maar dan is het dus niet bridge mode en dat maakt sommige dingen niet zo fijn voor IPv4 (NAT).

Dat niet alleen; je kunt bijvoorbeeld ook niet met tcpdump en iftop aan de echte WAN-zijde kijken, en ik wil precies weten wat er vanaf het Ziggo-netwerk m'n huis binnenkomt. Zet je router achter router, schermt zo'n Ubee/Technicolor van alles af. Daarom moet bridge mode gewoon werken.

[CyBeR]

Dat kun je met een kabelmodem in bridge ook niet. Of heb jij een DOCSIS sniffer?

[Verwijderd]

Ik zie bijvoorbeeld gewoon ARP-requests uit de hele router pool hoor. Uiteraard alleen multicasts en niet andermans TCP/UDP-traffic (dat hoef ik ook niet te zien, want dat zijn mijn zaken niet), maar ik wil wel weten wat er 'voor de deur' gebeurt. Lees: "waarom knippert dit ledje?"

In bridge mode kan dat redelijk transparant (al ben ik er niet 100% van overtuigd dat de firmware in dat modem geen nare dingen doet). In router mode zie je alleen jouw traffic op de WAN van en naar 192.168.0.1 op de andere router, die je dan maar moet vertrouwen. Zonder broncode.

[CyBeR]

Kijk hier maar 's naar: https://media.ccc.de/v/32c3-7133-beyond_your_cable_modem. Dat is allemaal shit die je met jouw tcpdump aan een kabelmodem nooit kunt zien.

[Roetzen]

Verwijderd schreef op zondag 21 februari 2016 @ 15:38:

Verder lijkt iedereen te vallen over GCNAT voor IPv4. Dat maakt mij dan weer niets uit. Servers horen in een datacenter en spelcomputers zijn stom. Verder moet iedere site gewoon IPv6 doen.

Mooi dat jij tevreden bent met een RFC1918 of RFC6598 adres, maar dat servers in een datacenter thuis horen en dat spelcomputers stom zijn is wat kort door de bocht. Ik ben ook geen gamer, maar ik zal niet zeggen dat het stom is. En ik vind het gewoon leuk om voor mijn hobby thuis wat servertjes te draaien. Tja, en zolang mijn vriendjes nog niet allemaal IPv6 hebben, kan ik nog niet zonder globaal routeerbaar IPv4 adres.

[Verwijderd]

Roetzen schreef op zondag 21 februari 2016 @ 23:49:
[...]
Tja, en zolang mijn vriendjes nog niet allemaal IPv6 hebben, kan ik nog niet zonder globaal routeerbaar IPv4 adres.

Dat is dan ook het hele probleem. Ik ben niet per se tevreden met een RFC1918- of RFC6598-adres, maar heel IPv4 voor non-LAN-toepassingen had allang niet meer moeten bestaan. Ieder huishouden en iedere server had al jaren IPv6-capable moeten zijn; dan hebben we helemaal geen "dual stack" nodig.

Dat spelcomputers stom zijn, vind ik niet kort door de bocht. Het is 2016 en ze hebben over het algemeen helemaal geen IPv6-support. Hoe is dat niet stom? (Dat staat helemaal los van wat je vindt van volwassen mannen die computerspelletjes aan het spelen zijn.)

En goed, voor servers thuis is het je eigen keuze. Ik merk geen verschil of ik SSH naar een VPS in een datacenter of SSH naar een fysiek apparaat in m'n LAN, behalve dan dat ik in de eerste situatie geen buitenstaanders op m'n thuisnetwerk hoef toe te laten, wat ik toch erg prettig vind.

Dus ik zou thuis best zonder IPv4-adres kunnen. Ik zou er op m'n servers helaas niet zonder kunnen.
Maar nogmaals, dat is het probleem. Iedereen zou zonder moeten kunnen (ook datacenters), en dat kan dus nog lang niet.. En als we ons dan ook nog massaal gaan verzetten tegen GCNAT, gaan ISP's nog meer noodsprongen zoeken om IPv4 in leven te houden en duurt het allemaal nóg langer.

[Roetzen]

Verwijderd schreef op zondag 21 februari 2016 @ 23:59:
[...]
Dat is dan ook het hele probleem. Ik ben niet per se tevreden met een RFC1918- of RFC6598-adres, maar heel IPv4 voor non-LAN-toepassingen had allang niet meer moeten bestaan. Ieder huishouden en iedere server had al jaren IPv6-capable moeten zijn; dan hebben we helemaal geen "dual stack" nodig.

Ik roep ook al jaren dat we met z'n allen veel te laat zijn met de uitrol van IPv6. Het had vijf jaar geleden toen IANA door zijn voorraad heen was al klaar moeten zijn. Maar ja, zo is het niet gegaan, men heeft het voor zich uit geschoven en nu zitten we met de gabakken peren. We kunnen nog niet zonder IPv4, maar de IPv4 adressen zijn op. Maar ja, ze luisteren niet naar mij

En als we ons dan ook nog massaal gaan verzetten tegen GCNAT, gaan ISP's nog meer noodsprongen zoeken om IPv4 in leven te houden en duurt het allemaal nóg langer.

Dat kan zijn, maar dat is dan niet mijn schuld. Ik ben al vijf jaar klaar voor IPv6. Als de rest van de wereld dat ook was, had ik geen globaal routeerbaar IPv4 adres meer nodig. Ja, zelfs helemaal geen IPv4, ook niet RFC1918 of RFC6598. Maar zo is het dus niet gegaan....

[easyriider]

Een grafiekje van State of the internet met data van 15/2:



In het begin de stapsgewijze invoering van IPv6 vorig jaar. Toen was ik ook nog één van de gelukkigen met IPv6 wat halverwege dat jaar weer was uitgeschakeld in het modem.

[Orion84]

Dat ziet er spectaculair uit, tot je ook de schaalverdeling bekijkt die in jouw afbeelding is weggevallen

Die piek representeert 1,3% IPv6 Adoption

[Jerrythafast]

CyBeR schreef op zondag 21 februari 2016 @ 23:38:
Kijk hier maar 's naar: https://media.ccc.de/v/32c3-7133-beyond_your_cable_modem. Dat is allemaal shit die je met jouw tcpdump aan een kabelmodem nooit kunt zien.

Wat een geweldig goeie video/presentatie is dat, hilarisch gewoon
Vooral mooi hoe hij aan het einde van zijn presentatie zegt "To my best of knowledge, the knowledge I just gave you is useless because all of these issues have been fixed." Lijkt een beetje een "eind goed, al goed" afsluiting.

spoiler:

Komt er vervolgens een joekel van een Q&A sessie achteraan, met echt in de voorlaatste minuut van het filmpje een antwoord dat eindigt met "...and that means you can probably still get someone else's provisioning file this way."

[ShadowLord]

CyBeR schreef op zondag 21 februari 2016 @ 23:38:
Kijk hier maar 's naar: https://media.ccc.de/v/32c3-7133-beyond_your_cable_modem. Dat is allemaal shit die je met jouw tcpdump aan een kabelmodem nooit kunt zien.

Als je graag wilt zien wat er 'achter' je kabelmodem gebeurt op de COAX kun je ook dit topic eens bekijken: [EuroDOCSIS] Capaciteit monitoren met een DVB-C PC-TV tuner

[stormfly]

Even over Ziggo

De Cisco stuurt nu (ik heb dual stack maar nog geen WAN prefix) een lege RA. Dat vindt de Apple tv 4 niet zo leuk en Netflix klapt er steeds uit. Nu even ip op handmatig gezet in de Apple tv en dat lijkt te werken.

Een lege RA sturen is niet zo smart van het Cisco modem maar het blijkt dus ook OS afhankelijk of het impact heeft of niet.

Overigens is het uitzetten van de IPv6 lan tab nog geen reden voor de Cisco firmware om te stoppen met lege RA's

[Hipska]

ShadowLord schreef op dinsdag 23 februari 2016 @ 13:54:
[...]

Als je graag wilt zien wat er 'achter' je kabelmodem gebeurt op de COAX kun je ook dit topic eens bekijken: [EuroDOCSIS] Capaciteit monitoren met een DVB-C PC-TV tuner

Dat is ook best een interessant topic, thanks!

[Maurits van Baerle]

Hoe bedoel je dat je Dual Stack hebt zonder WAN prefix? Bedoel je dat je nu een IPv6 compatible firmware hebt maar verder nog geen IPv6 verbinding van Ziggo hebt gekregen?

Het lijkt me dat je zonder prefix nog niet kunt zeggen dat je Dual Stack hebt...

[stormfly]

Hoi Maurits

Cisco had al hun modems voorheen in "IPv4 only" staan voor fZiggo klanten. Nu zijn zover ik kan lezen alle modems aangepast (moet je voor rebooten). Zodra hij de nieuwe config file ophaalt de IPv4 mode aangepast is naar de letterlijke tekst "Dual Stack"

Echter lijken ze per CMTS/Coax gebied de WAN prefix aanpassingen te doen, zoals ik in Utrecht Oost nog geen IPv6 WAN prefix heb. Hebben gebruikers in Nieuwegein dit al wel, beide modems routeren via hoofd POP De Meern. Waardoor ik concludeer dat de handeling om een IPv6 WAN prefix actief te krijgen een lokale handeling is welke niet op de POP hoeft te gebeuren, maar lokaal aan de CMTS oid.

Firmware Version: e3928A-E10-5-c3220r5592-150612c-ZIG
Current Time: Wed. Feb 24 09:19:31 2016
Router Mode: Dual Stack


Internet IPv4 Connection
IPv4 Address: 84.foobar
Subnet Mask: 255.255.254.0
Default Gateway: 84.foobar
DNS IPv4 1: 208.67.222.222
DNS IPv4 2: 89.101.251.229
DNS IPv4 3: 0.0.0.0

Internet IPv6 Connection
WAN DUID: 00:03:00:01:c8:fb:foobar
Global IPv6 Address: ::
Link-Local IPv6 Address: fe80::cafb:26ff:foobar/64
DNS IPv6 1: ::
DNS IPv6 2: ::
DNS IPv6 3: ::


Als je dan kijkt naar ondertaande screenshot, stond het vinkje ENABLED en RAPID aangevinkt by default. Maar dat heb ik uitgezet teneinde de AppleTV 4 NetFlix problemen op te lossen. Echter blijft hij RA's sturen en daar gaat de AppleTV 4 slecht mee om. Ik had deze problemen niet voordat mijn modem in DS gereboot was.

Ik zal vanavond even een Wireshark capture maken voor het topic hier, wel leuk toch bitjes en bytes analyseren. Ben benieuwd naar jullie visie op deze problematiek.

[Zr40]

Welke firmware versie heeft de TC7210 van Ziggo wanneer hierop IPv6 is ingeschakeld?

[stormfly]

Zr40 schreef op woensdag 24 februari 2016 @ 09:38:
Welke firmware versie heeft de TC7210 van Ziggo wanneer hierop IPv6 is ingeschakeld?

Ik denk niet dat dit samenhangt, de configuratie template vereist niet altijd een firmware update bij elk modem. De TC7210 is vrij recent dus ik zou eerder aannemen dat hier niet direct een firmware update nodig is tov de al jarenlange uitgedeelde Cisco modems.

Bijvoorbeeld de Cisco 3928 heeft vorig jaar bij uitzondering een firmware update gehad en pas vele maanden later kwam er een IPv6 DS reboot, zonder WAN prefix.

[Bigs]

stormfly schreef op woensdag 24 februari 2016 @ 09:27:
[..]

Als je dan kijkt naar ondertaande screenshot, stond het vinkje ENABLED en RAPID aangevinkt by default. Maar dat heb ik uitgezet teneinde de AppleTV 4 NetFlix problemen op te lossen. Echter blijft hij RA's sturen en daar gaat de AppleTV 4 slecht mee om. Ik had deze problemen niet voordat mijn modem in DS gereboot was.

Ik zal vanavond even een Wireshark capture maken voor het topic hier, wel leuk toch bitjes en bytes analyseren. Ben benieuwd naar jullie visie op deze problematiek.


[afbeelding]

Dat is vreemd.. wat voor prefix stuurt hij dan mee in die RA's?

[Maurits van Baerle]

stormfly schreef op woensdag 24 februari 2016 @ 07:42:
De Cisco stuurt nu (ik heb dual stack maar nog geen WAN prefix) een lege RA. Dat vindt de Apple tv 4 niet zo leuk en Netflix klapt er steeds uit. Nu even ip op handmatig gezet in de Apple tv en dat lijkt te werken.

Een lege RA sturen is niet zo smart van het Cisco modem maar het blijkt dus ook OS afhankelijk of het impact heeft of niet.

Aangezien ik vermoed dat Apple sneller zal zijn in het fixen dan Ziggo (die een bug report naar Cisco zal moeten sturen om een obscuur probleem in een oud model op te lossen) denk ik dat het na je wireshark zin heeft om alle bevinden te delen via https://www.apple.com/feedback/appletv.html

Zeker nu Apple IPv6 als een prioriteit heeft bestempeld (en de Apple TV actief gesupport wordt) kan het misschien makkelijk meegenomen worden in andere IPv6 ontwikkelingen.

[stormfly]

Bigs schreef op woensdag 24 februari 2016 @ 11:34:
[...]


Dat is vreemd.. wat voor prefix stuurt hij dan mee in die RA's?

Zoals ik op het eerste gezicht zag "leeg" ;-) daarom is het volgens mij OS afhankelijk hoe dat verwerkt wordt. Bij een lege prefix zou ik in de eerste instantie denken, dan kan je beter RA uitschakelen. Als het OS met die insteek ontworpen is dan heb je nu dus kans dat hij die lege RA toch gaan processen met een wat instabiel resultaat.

[Osxy]

Van mij mag IPV6 weg blijven, niet vanwege de techniek maar omdat ik in oud UPC gebied zit en dus op DSLite zal komen. Ben erg gehecht aan mijn echte externe IPV4 adres...

[Snow_King]

Osxy schreef op woensdag 24 februari 2016 @ 15:00:
Van mij mag IPV6 weg blijven, niet vanwege de techniek maar omdat ik in oud UPC gebied zit en dus op DSLite zal komen. Ben erg gehecht aan mijn echte externe IPV4 adres...

Jammer voor jou, maar het gaat echt komen. Een internet met enkel IPv4 is niet houd en werkbaar. Je zal binnenkort echt IPv6 gaan krijgen.

Waarom daar dan niet gewoon direct gebruik van maken? Heb je geen gedoe meer met IPv4 en de horror die NAT heet.

[Raven]

Osxy schreef op woensdag 24 februari 2016 @ 15:00:
Van mij mag IPV6 weg blijven, niet vanwege de techniek maar omdat ik in oud UPC gebied zit en dus op DSLite zal komen. Ben erg gehecht aan mijn echte externe IPV4 adres...

Dan neem je toch een tunnel? Dan behoud je voorlopig je IPv4 adres nog.

[agresionpower]

Osxy schreef op woensdag 24 februari 2016 @ 15:00:
Van mij mag IPV6 weg blijven, niet vanwege de techniek maar omdat ik in oud UPC gebied zit en dus op DSLite zal komen. Ben erg gehecht aan mijn echte externe IPV4 adres...

Het is denk ik vooral hopen dat content providers ook snel overstappen naar IPv6.
Zodra dat gebeurd is en het merendeel van de verbindingen in Nederland IPv6 heeft maakt het natuurlijk niet meer uit dat je geen eigen publieke IPv4 hebt.

[Zr40]

Osxy schreef op woensdag 24 februari 2016 @ 15:00:
Van mij mag IPV6 weg blijven, niet vanwege de techniek maar omdat ik in oud UPC gebied zit en dus op DSLite zal komen. Ben erg gehecht aan mijn echte externe IPV4 adres...

De grap is, DSlite komt er niet vanwege IPv6 maar juist vanwege een tekort aan IPv4. Het levert je dus niets op om IPv6 te ontwijken.

agresionpower schreef op woensdag 24 februari 2016 @ 15:21:
Het is denk ik vooral hopen dat content providers ook snel overstappen naar IPv6.
Zodra dat gebeurd is en het merendeel van de verbindingen in Nederland IPv6 heeft maakt het natuurlijk niet meer uit dat je geen eigen publieke IPv4 hebt.

Het zal bij ISPs pas hard gaan zodra de content providers geen IPv4 adressen meer kunnen toewijzen aan nieuwe servers. Helaas zien we dat in Nederland de IPv6 uitrol nog niet echt op gang is gekomen, ondanks de beschikbaarheid van IPv6 bij content providers.

[ Voor 49% gewijzigd door Zr40 op 24-02-2016 15:29 ]

[Osxy]

@hierboven, klopt helemaal wat jullie zeggen.

Begrijp me niet verkeerd, ik heb allang al een IPV6 tunnel draaien voor mijn IPV6 connectiviteit maar voorlopig wil ik alleen niet mijn externe IPV4 inleveren, deze is nog dagelijks in gebruik en zolang er op meer plaatsen geen IPV6 is dan wel behoud ik deze graag.

[agresionpower]

Zr40 schreef op woensdag 24 februari 2016 @ 15:23:
[...]

De grap is, DSlite komt er niet vanwege IPv6 maar juist vanwege een tekort aan IPv4. Het levert je dus niets op om IPv6 te ontwijken.


[...]

Het zal bij ISPs pas hard gaan zodra de content providers geen IPv4 adressen meer kunnen toewijzen aan nieuwe servers. Helaas zien we dat in Nederland de IPv6 uitrol nog niet echt op gang is gekomen, ondanks de beschikbaarheid van IPv6 bij content providers.

Die beschikbaarheid van content providers valt heel erg tegen.
Van de top 1000 websites heeft slechts ~16% IPv6. (tweakers zelf bijvoorbeeld draait ook nog niet op ipv6)

[stormfly]

Eigenlijk is Akamai de grootste, maar zoals al eerder gemeld. Als je IPv4 nu uitzet is het internet doodsaai en stil, dat is echt niet gek veel anders eind dit jaar ;-)

Als ik DS-Lite van fUPC zou krijgen, dan zou ik hem laten rebooten met een IPv4 config via de klantenservice en IPv6 laten vervallen. Heb mee behoeft aan open IPv4 poortjes om vanaf het internet thuis te komen dan IPv6 uitgaand.

Daarom ben ik wel blij dat bij fZiggo DualStack wordt uitgerold dan kan je zelf kiezen per device wat je gaat configureren.

[Verwijderd]

agresionpower schreef op woensdag 24 februari 2016 @ 15:58:
[...]


Die beschikbaarheid van content providers valt heel erg tegen.
Van de top 1000 websites heeft slechts ~16% IPv6. (tweakers zelf bijvoorbeeld draait ook nog niet op ipv6)

Hier wel, maar het probleem is monitoring. Kees in "IPv6"

De IP adressen voor IPv6 van tweakers staan bij mij gewoon in de hosts file.

[Zr40]

stormfly schreef op woensdag 24 februari 2016 @ 16:22:
Als ik DS-Lite van fUPC zou krijgen, dan zou ik hem laten rebooten met een IPv4 config via de klantenservice en IPv6 laten vervallen. Heb mee behoeft aan open IPv4 poortjes om vanaf het internet thuis te komen dan IPv6 uitgaand.

Dit kan alleen werken als de noodzaak voor DSlite er niet is; namelijk het tekort aan IPv4 adressen. IPv6 uitschakelen verandert niets aan het tekort.

Heeft Ziggo ooit bevestigd dat bestaande klanten hun routeerbare IPv4 adres zullen verliezen zodra ze voor nieuwe klanten overstappen naar DSlite? En hebben ze ooit bevestigd dat je het adres terugkrijgt als je geen IPv6 wilt?

Nogmaals, het probleem waar jij tegenaan loopt zit in het tekort aan IPv4 adressen, en juist niet in het aanbieden van IPv6. Jij hebt geen enkel voordeel aan het door Ziggo laten uitschakelen van IPv6.

[ Voor 32% gewijzigd door Zr40 op 24-02-2016 18:08 ]

[Paul]

Jullie luisteren niet naar wat Osxy en wopper zeggen. Ik heb het idee dat dat wel vaker gebeurt hier wanneer iemand iets negatiefs uit over IPv6 of de gekozen implementatie daarvan.

Ze zeggen beiden dat wanneer ze overgezet worden op DSlite dat ze dan graag teruggezet willen worden naar iets met een volwaardig IPv4-adres. Dan heeft het weinig zin om nog maar een keer IPv6 de hemel in te prijzen of op het tekort aan IPv4-adressen te wijzen, dat veranderd namelijk niks aan het feit dat ze bij DSlite geen globaal routeerbaar IPv4-adres zouden hebben. En Ziggo lijkt nu eenmaal de invoering van GCNAT gekoppeld aan hun uitrol van IPv6...

Als ik _nu_ overgezet zou worden op DSlite dan zou ik ook a la minute terug gaan, dan maar geen IPv6. Heeft eigenlijk helemaal niks met IPv6 te maken, maar aangezien Ziggo die wel aan elkaar koppelt heeft het dus wel met IPv6 te maken...

[Zr40]

Paul schreef op woensdag 24 februari 2016 @ 18:21:
Jullie luisteren niet naar wat Osxy en wopper zeggen. Ik heb het idee dat dat wel vaker gebeurt hier wanneer iemand iets negatiefs uit over IPv6 of de gekozen implementatie daarvan.

Ik vermoed dat je mijn reactie niet goed gelezen hebt. Het probleem van Osxy en wopper is dat ze als bestaande klant mogelijk hun IPv4 adres verliezen. Wie zegt dat als dat gebeurt, er überhaupt een mogelijkheid is om dat adres terug te krijgen als ze IPv6 uit laten schakelen?

Het probleem is het tekort aan IPv4 adressen, niet het aanbod van IPv6. De suggestie dat men hun IPv4 adres terug zou kunnen krijgen is nergens onderbouwd en zorgt alleen maar voor verwarring. Het zou mij niets verbazen als je dan IPv4-only achter dezelfde CGNAT terecht komt als de DSlite gebruikers...

Het wijzen op het tekort is door mij bedoeld als uitleg op de tekst die ik daaropvolgend geschreven heb. Het gaat niet over 'IPv6 is helemaal geweldig', het gaat over waarom het uitschakelen van DSlite hoogstwaarschijnlijk niet het gewenste resultaat zal behalen.

[ Voor 36% gewijzigd door Zr40 op 24-02-2016 18:51 ]

[agresionpower]

Zr40 schreef op woensdag 24 februari 2016 @ 18:23:
[...]

Ik vermoed dat je mijn reactie niet goed gelezen hebt. Het probleem van Osxy en wopper is dat ze als bestaande klant mogelijk hun IPv4 adres verliezen. Wie zegt dat als dat gebeurt, er überhaupt een mogelijkheid is om dat adres terug te krijgen als ze IPv6 uit laten schakelen?

Het probleem is het tekort aan IPv4 adressen, niet het aanbod van IPv6. De suggestie dat men hun IPv4 adres terug zou kunnen krijgen is nergens onderbouwd en zorgt alleen maar voor verwarring. Het zou mij niets verbazen als je dan IPv4-only achter dezelfde CGNAT terecht komt als de DSlite gebruikers...

Je kan gewoon ipv4 terug krijgen zoals je het nu hebt. Dat is al bevestigd.

Hoe lang die situatie blijft is alleen niet duidelijk. Ooit wil je natuurlijk wel naar ipv6. De vraag is dan of ziggo dat moment voor jouw kiest of dat je dat zelf kan bepalen.

[Zr40]

agresionpower schreef op woensdag 24 februari 2016 @ 18:51:
Je kan gewoon ipv4 terug krijgen zoals je het nu hebt. Dat is al bevestigd.

Waar is dat bevestigd?

Het feit dat Ziggo in het oud-UPC segment voor DSlite gaat in plaats van dual-stack geeft aan dat ze wel degelijk een tekort verwachten aan IPv4 adressen in dat segment. Als het inderdaad mogelijk is om een routeerbaar IPv4 adres terug te krijgen na de migratie, dan spreekt dit de noodzaak van DSlite weer tegen.

[ Voor 104% gewijzigd door Zr40 op 24-02-2016 19:03 ]

[Paul]

Zr40 schreef op woensdag 24 februari 2016 @ 18:23:
Ik vermoed dat je mijn reactie niet goed gelezen hebt.

Nogmaals, het probleem waar jij tegenaan loopt zit in het tekort aan IPv4 adressen, en juist niet in het aanbieden van IPv6. Jij hebt geen enkel voordeel aan het door Ziggo laten uitschakelen van IPv6.

Iedereen die je van (volwaardig) IPv4 overzet naar DSlite levert je (99.9999% van) een IPv4-adres op. Volgens mij heb ik in meerdere berichten Ziggo zien bevestigen dat mensen terug over kunnen naar dual stack via het piep-systeem. Of je dan dus zegt "IPv6 uitschakelen" of "DSlite uitschakelen", voor een Ziggo-klant heeft dat (zo goed als) hetzelfde effect, waarbij de eerste uitspraak natuurlijk vooral gestoeld is op het feit dat ze hun IPv4-adres kwijt zijn geraakt toen ze IPv6 kregen. Dan is het niet vreemd om het tegenovergestelde te willen om de oude situatie terug te krijgen: IPv6 erin == IPv4 kwijt => IPv6 eruit == IPv4 terug...

Osxy en wopper geven zelfs expliciet de schuld aan DSlite (ipv IPv6), dus het lijkt me dat ze best weten wat het verschil is...

[ Voor 6% gewijzigd door Paul op 24-02-2016 19:11 ]

[Zr40]

Paul schreef op woensdag 24 februari 2016 @ 19:10:
Iedereen die je van (volwaardig) IPv4 overzet naar DSlite levert je (99.9999% van) een IPv4-adres op. Volgens mij heb ik in meerdere berichten Ziggo zien bevestigen dat mensen terug over kunnen naar dual stack via het piep-systeem. Of je dan dus zegt "IPv6 uitschakelen" of "DSlite uitschakelen", voor een Ziggo-klant heeft dat (zo goed als) hetzelfde effect, waarbij de eerste uitspraak natuurlijk vooral gestoeld is op het feit dat ze hun IPv4-adres kwijt zijn geraakt toen ze IPv6 kregen. Dan is het niet vreemd om het tegenovergestelde te willen om de oude situatie terug te krijgen: IPv6 erin == IPv4 kwijt => IPv6 eruit == IPv4 terug...

En dat is dus een zeer vreemde situatie. IPv6 zelf verhindert niet dat je een routeerbaar IPv4 adres kan hebben. Daarentegen heb je met de mogelijkheid om te kiezen tussen DSlite en IPv4-only twee verschillende configuraties waarmee IPv4-toegang geboden kan worden. Aangezien deze scheiding bestaat (mits het inderdaad mogelijk is om te kiezen, daarvan heb ik nog steeds geen bevestiging vanuit Ziggo gezien), wat weerhoudt ze er van om het deel dat kiest voor een routeerbaar IPv4 adres ook IPv6 te bieden? Er is namelijk geen technische reden om dat niet te doen.

Daarentegen wordt het verhaal opeens een stuk logischer wanneer je veronderstelt dat de mogelijkheid voor niet-DSlite in het DSlite-gebied niet aangeboden zal worden.

Los hiervan; we hebben het hier vaak over eigen IPv6 tunnels over een IPv4-only verbinding. Bestaat dit ook omgekeerd? Dat zou wellicht het grootste probleem van DSlite kunnen wegnemen.

[ Voor 12% gewijzigd door Zr40 op 24-02-2016 19:45 ]

[Maurits van Baerle]

Zr40 schreef op woensdag 24 februari 2016 @ 18:51:
[...]
Als het inderdaad mogelijk is om een routeerbaar IPv4 adres terug te krijgen na de migratie, dan spreekt dit de noodzaak van DSlite weer tegen.

Hoezo? Maar een klein deel van de mensen die zijn overgezet naar DS-Lite zullen klagen dat het teruggedraaid moet worden. De meeste klanten zullen het helemaal niet doorhebben. Dat kan dus betekenen dat Ziggo misschien maar 20% van de hoeveelheid IPv4 adressen gebruikt die ze voor de overstap naar DS-Lite in gebruik hadden. Een flinke besparing dus.

[stormfly]

Paul schreef op woensdag 24 februari 2016 @ 18:21:
Jullie luisteren niet naar wat Osxy en wopper zeggen. Ik heb het idee dat dat wel vaker gebeurt hier wanneer iemand iets negatiefs uit over IPv6 of de gekozen implementatie daarvan.

Ik herken dat gevoel, alsof ik "Feyenoord" schreeuw in een overvolle Arena in hartje Amsterdam. Waarbij Feyenoord dan het IPv4 kamp is en direct wordt aangevallen door het IPv6 kamp Ajax. En ik de harde kern van IPv6 over me heen krijg, en blij mag zijn als ik daarna nog zelfstandig naar huis kan lopen

Haha ik noemde het pas "hobby of iets van hobby blindheid" maar jullie zijn zo bloed fanatiek, de enige die mij echt overtuigde was de hoster die voor 10K+ aan IPv4 adressen gekocht had en een belemmering in de groei van zijn bedrijf zag. Door jullie hobby fanatisme "denken" jullie velen jaren verder dan de huidige networking wereld op dit moment is.

Ik werk voor een van de top 3 network integrators van Nederland en ben dagelijks met netwerken bezig, maar er is nog geen enkele klant die vraagt " goh ik wil IPv6 op mijn LAN gaan implementeren" sterker nog het gros heeft nog niet eens IPv6 in hun DMZ/Internet. Ik ben op Cisco Live Berlijn bij diverse IPv6 sessies geweest en die zijn gewoon heel matig bezocht het is daar zeker niet druk te noemen in de trend van " het is 2016 men maakt zich zorgen".

Als ik dan DS-Lite zou krijgen dan zou ik de TC72xx om laten zetten naar native IPv4 zonder IPv6, dat is gewoon mogelijk en blijf ook mogelijk de vele komende jaren trustme. Ziggo en UPC hebben miljoenen IPv4 adressen, en als Henk en Ingrid of Opa en Oma lekker via DS-LITE tevreden browsen blijf ik graag Tweaker en op IPv4 mijn inkomende poortjes openzetten.

En als we dan echt vele jaren verder zijn en IPv4 is, zoals nu het IPv6 internet op dit moment, lees IPv4 is echt uitstervend want het IPv6 internet op dit moment is nog crappy. Dan, ja dan, zal ik heel graag mijn DS-Lite aansluiting in native IPv6 met een CGNAT breakout voor het legacy IPv4.

Maar ik ben nu kalend, ik weet zeker dat ik heel kaal ben tegen die tijd

Ik ga mijn volgende post schrijven over de routeradvertisements, back to techniek

[stormfly]

Zr40 schreef op woensdag 24 februari 2016 @ 19:22:
[...]

En dat is dus een zeer vreemde situatie. IPv6 zelf verhindert niet dat je een routeerbaar IPv4 adres kan hebben. Daarentegen heb je met de mogelijkheid om te kiezen tussen DSlite en IPv4-only twee verschillende configuraties waarmee IPv4-toegang geboden kan worden. Aangezien deze scheiding bestaat (mits het inderdaad mogelijk is om te kiezen, daarvan heb ik nog steeds geen bevestiging vanuit Ziggo gezien), wat weerhoudt ze er van om het deel dat kiest voor een routeerbaar IPv4 adres ook IPv6 te bieden? Er is namelijk geen technische reden om dat niet te doen.

Eens je hebt 2 mogelijkheden voor IPv4 toegang maar bij slechts 1 kan kan je zelf porten openzetten voor bijvoorbeeld thuisgebruik van een NAS. frigo klanten krijgen een Dual Stack configuratie en dan heb je naast je IPv4 adres ook tegelijk een IPv6 adres, dat is eigenlijk de mooiste oplossing voor een Tweaker een volledige Dual Stack implementatie

Ja je kunt echt kiezen, er is zelfs een (hidden?) page beschikbaar op de Ziggo site waarin ze beschrijven wat je moet doen als de KS je modem terug heeft gezet naar IPv4. Als je echt tijd over hebt kan je hem wel zoeken in dit topic, ik kreeg hem niet gevonden.

https://community.ziggo.n...773/index1.html#post73441

[Jerrythafast]

Zr40 schreef op woensdag 24 februari 2016 @ 18:51:
[...]

Waar is dat bevestigd?

Het feit dat Ziggo in het oud-UPC segment voor DSlite gaat in plaats van dual-stack geeft aan dat ze wel degelijk een tekort verwachten aan IPv4 adressen in dat segment. Als het inderdaad mogelijk is om een routeerbaar IPv4 adres terug te krijgen na de migratie, dan spreekt dit de noodzaak van DSlite weer tegen.

stormfly schreef op woensdag 24 februari 2016 @ 21:18:
Ja je kunt echt kiezen, er is zelfs een (hidden?) page beschikbaar op de Ziggo site waarin ze beschrijven wat je moet doen als de KS je modem terug heeft gezet naar IPv4. Als je echt tijd over hebt kan je hem wel zoeken in dit topic, ik kreeg hem niet gevonden.

www.ziggo.nl/ipv6-uit