Het grote IPv6 topic

[Vorkie]

Ze hebben Amsterdam afgeschreven op de statuspagina

Een echte managementview, wat niet ziet wat niet weet

[Raven]

Vorkie schreef op dinsdag 15 augustus 2017 @ 20:41:
Ze hebben Amsterdam afgeschreven op de statuspagina

Een echte managementview, wat niet ziet wat niet weet

... and it's back (op die pagina) , nog steeds down.

edit: Ik lees net in de mail dat de tunnels gemigreerd zijn naar een London server.

[ Voor 18% gewijzigd door Raven op 15-08-2017 21:05 ]

[MrNGm]

Raven schreef op dinsdag 15 augustus 2017 @ 20:56:
[...]

... and it's back (op die pagina) , nog steeds down.

Works not for me

Vanaf 14 augustus 23:44 kwamen pings van extern niet altijd even goed aan; sinds 15 augustus 01:20 geen pongs meer vanaf extern.

edit: @Raven krijgt iedereen zo'n e-mail? Lijkt me wel relevant als het IPv4-endpoint verandert namelijk.

[ Voor 14% gewijzigd door MrNGm op 15-08-2017 21:11 ]

[Gogol]

Raven schreef op dinsdag 15 augustus 2017 @ 20:56:
[...]

... and it's back (op die pagina) , nog steeds down.

edit: Ik lees net in de mail dat de tunnels gemigreerd zijn naar een London server.

Hier werkt nog steeds niets. Moet ik iets veranderen denk je?

[Roetzen]

Paul schreef op dinsdag 15 augustus 2017 @ 18:06:
[...]
Dat was het wel, want fZiggo had Dual Stack...

Dat hebben ze nog steeds. De infrastructuur van Ziggo is geschikt voor CPEs die Ipv4 only, Dual stack en DS-Lite doen. Dat wil niet zeggen dat er voor elke modem/router zowel een firmware voor Dual Stack als voor DS-Lite beschikbaar is. En al was die er wel, dan zie ik nog niet hoe je Dual Stack en DS-Lite in één apparaat door elkaar kunt gebruiken. Als een apparaat meed dan één IPv4 adres heeft, dan zijn de allebei publiek of allebei CGNAT. Door elkaar lijkt me niet mogelijk. .

[...]
Natuurlijk wel... IPv4-adressen worden niet verbruikt, het is niet alsof er steeds minder zijn. Het zijn en blijven er ~4 miljard. Als je er te weinig _vrij_ hebt, dan is DS Lite zeker wel een manier om IPv4-adressen vrij te spelen...

IPv4 adressen zijn inderdaad niet als olie wat je verbrandt en dan is het weg. Het zijn er inderdaad altijd 4 miljard. Maar als de vraag bllijft toenemen ben je er op een gegeven moment doorheen. Ze zijn dan "op" in de zin dat er geen nieuwe meer bijkomen. Wie er dan nog om vraagt krijgt nul op het request. Dat probleem is onoplosbaar. Dat nieuwe klanten dan DS-Lite krijgen (nul op het IPv4 request) is geen oplossing voor dat probleem, maar een gevolg er van.

Je zou ze wel anders kunnen gaan verdelen. Maar dat betekent dan dat je van bestaande klanten IPv4 adressen moet gaan afnemen. En dat wilde je nu juist niet....

[...]
Dat besef ik me. Je ziet me echter nergens vragen om dat voor iedereen te doen...

Maar hoe ga je dan zorgen dat alleen degene die het echt nodig heeft het krijgt? Ik zie geen andere oplossing door er extra voor te laten betalen. Hetzij in geld, hetzij door de straf van "dan geen IPv6".

[MrNGm]

HE lijkt het weer te doen sinds 00:00



Met trace van $ergens

code:

$ mtr -6trw ...g.nl
Start: Wed Aug 16 01:31:55 2017
HOST: ...                            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ...                           0.0%    10    0.1   0.1   0.1   0.1   0.0
  2.|-- ...                           0.0%    10    0.3   0.3   0.3   0.3   0.0
  3.|-- core24.fsn1.hetzner.com       0.0%    10    0.3   0.3   0.3   0.4   0.0
  4.|-- core4.fra.hetzner.com         0.0%    10    5.1   6.4   5.0  16.7   3.5
  5.|-- 100ge7-2.core1.fra1.he.net    0.0%    10   50.8  43.8   5.7  59.9  19.8
  6.|-- 100ge6-1.core1.lon2.he.net    0.0%    10   29.7  24.3  17.9  39.2   6.8
  7.|-- tserv1.lon1.he.net            0.0%    10   26.5  25.3  23.3  26.8   1.0
  8.|-- ....tserv11.ams1.ipv6.he.net  0.0%    10   29.7  29.6  29.5  29.8   0.0
  9.|-- ...g.nl                       0.0%    10   28.8  29.3  28.8  33.8   1.5

... dus de tunnels zijn overgeplaatst naar London.

[ Voor 84% gewijzigd door MrNGm op 16-08-2017 02:03 . Reden: mtr toegevoegd ]

[Paul]

Roetzen schreef op dinsdag 15 augustus 2017 @ 22:26:
Dat wil niet zeggen dat er voor elke modem/router zowel een firmware voor Dual Stack als voor DS-Lite beschikbaar is.

Ongetwijfeld, maar ze doen ook niet bijzonder moeilijk over een modemswap

Als een apparaat meed dan één IPv4 adres heeft, dan zijn de allebei publiek of allebei CGNAT. Door elkaar lijkt me niet mogelijk

Waarom niet? Zelfs nog voordat je bij zaken als VLANs uit komt kun je onder Windows al probleemloos meerdere IP-adressen en routes opgeven, laat staan op een apparaat wat specifiek bedoeld is om netwerkzaken te regelen (en zelf al trucjes uithaalt om altijd op adressen als 192.168.100.1 te luisteren, ook als dat buiten het subnet ligt of het modem zelfs in bridge staat).

Je zou ze wel anders kunnen gaan verdelen. Maar dat betekent dan dat je van bestaande klanten IPv4 adressen moet gaan afnemen. En dat wilde je nu juist niet....

Ik dacht dat ik het over de migratie naar IPv6 toe had, maar mogelijk heb ik dat niet expliciet genoeg gezegd. De enige manier waarop ik bij Ziggo IPv6 kan krijgen is door mijn IPv4-adres in te leveren.

Maar hoe ga je dan zorgen dat alleen degene die het echt nodig heeft het krijgt?

echt nodig is daarmee niet 100% bewezen maar de huidige manier werkt toch prima? M.a.w. piepsysteem? Het enige risico dat ik daarmee zie is wanneer mensen niet weten waar ze het over hebben, het aan elkaar door gaan vertellen en denken dat ze dan iets meer of extra kunnen. Wat in theorie ook waar is maar wat niet wil zeggen dat ze dat dan ook nodig hebben.

Ik zou, mocht het zo ver komen, voorlopig op zich best bereid zijn er voor te betalen. Ik kom online bedragen tegen tussen de € 4 en € 15 eenmalig dus € 1 per maand lijkt me goed verdienen voor Ziggo (de huidige infra kan blijkbaar ook uit met het huidige abonnementsgeld, en als je de retentiedesk belt kan er nog flink wat van af ook).

[elsinga]

* elsinga heeft een Connect Box en die staat in bridge ivm de er achter hangende router. Dus (gelukkig) IPv4. had liever dual stack gehad, maar fUPC dus niet mogelijk. Router kan het prima aan en draait nu een 6in4 tunnel.

Een niet routeerbaar IPv4 adres (CGNAT dus) of geen IPv4 adres (IPv6 only) gaat voor mij nu nog niet werken. Ik draai thuis websites (poorten 80 en 443), SFTP (poort 22 en nog een paar), VPN (ook een zooi poorten) en meer. Een proxy waar ik op hostname mee kan connecten en die dan IPv4 -> IPv6 doet zou helpen, zolang die proxy maar alle poorten doorstuurt en voldoende bandbreedte heeft. Ik heb niets aan een service die ik op poortnivo moet aansturen...

Ziggo kan overigens vrij eenvoudig kijken of een aansluiting DS_Lite geschikt is of niet. Elke aansluiting waarbij er inkomend verkeer is op IPv4 is in elk geval niet geschikt. Totaal geen inkomend verkeer zou geschikt kunnen zijn.

[Raven]

Gogol schreef op dinsdag 15 augustus 2017 @ 22:03:
[...]

Hier werkt nog steeds niets. Moet ik iets veranderen denk je?

MrNGm schreef op dinsdag 15 augustus 2017 @ 21:07:
edit: @Raven krijgt iedereen zo'n e-mail? Lijkt me wel relevant als het IPv4-endpoint verandert namelijk.

Ik heb geen flauw idee of er aan de kant van de eindgebruiker wat verandert moet worden, die vraag stuurde ik gister terug voor ik naar bed ging.

edit: Ze waren op het moment van die mail nog aan het migreren, er hoeft bij de eindgebruiker niets verandert te worden.

MrNGm schreef op dinsdag 15 augustus 2017 @ 21:07:
edit: @Raven krijgt iedereen zo'n e-mail? Lijkt me wel relevant als het IPv4-endpoint verandert namelijk.

Geen idee, dat kreeg ik als antwoord toen ik vroeg waarom ie van de statuspage af was.

MrNGm schreef op woensdag 16 augustus 2017 @ 01:12:
HE lijkt het weer te doen sinds 00:00

[afbeelding]

Met trace van $ergens

code:

$ mtr -6trw ...g.nl
Start: Wed Aug 16 01:31:55 2017
HOST: ...                            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ...                           0.0%    10    0.1   0.1   0.1   0.1   0.0
  2.|-- ...                           0.0%    10    0.3   0.3   0.3   0.3   0.0
  3.|-- core24.fsn1.hetzner.com       0.0%    10    0.3   0.3   0.3   0.4   0.0
  4.|-- core4.fra.hetzner.com         0.0%    10    5.1   6.4   5.0  16.7   3.5
  5.|-- 100ge7-2.core1.fra1.he.net    0.0%    10   50.8  43.8   5.7  59.9  19.8
  6.|-- 100ge6-1.core1.lon2.he.net    0.0%    10   29.7  24.3  17.9  39.2   6.8
  7.|-- tserv1.lon1.he.net            0.0%    10   26.5  25.3  23.3  26.8   1.0
  8.|-- ....tserv11.ams1.ipv6.he.net  0.0%    10   29.7  29.6  29.5  29.8   0.0
  9.|-- ...g.nl                       0.0%    10   28.8  29.3  28.8  33.8   1.5

... dus de tunnels zijn overgeplaatst naar London.

Verbinding lijkt hier ook weer up te zijn

edit: En inmiddels weer terug naar IPv4 omdat IPv6 weer plat lijkt te liggen.

[ Voor 4% gewijzigd door Raven op 16-08-2017 09:42 ]

[Zr40]

Raven schreef op woensdag 16 augustus 2017 @ 09:28:
[...]

edit: En inmiddels weer terug naar IPv4 omdat IPv6 weer plat lijkt te liggen.

Hier werkt de tunnel op dit moment wel. Met een Ziggo verbinding, als dat uitmaakt. Inderdaad wel met tserv1.lon1 in de IPv6 traceroute.

[Raven]

Nu werkt het weer wel. Vaag gedoe. Hier zit ik bij Tweak overigens.

[Zr40]

@Raven Waarom eigenlijk geen 6rd van Tweak zelf? Bij mij werkt dat uitstekend. (Op de MTU van 1480 na bij sites met defecte PMTUD, maar dat geldt voor elke 6in4 tunnel...)

[Raven]

Zr40 schreef op woensdag 16 augustus 2017 @ 10:55:
@Raven Waarom eigenlijk geen 6rd van Tweak zelf? Bij mij werkt dat uitstekend. (Op de MTU van 1480 na bij sites met defecte PMTUD, maar dat geldt voor elke 6in4 tunnel...)

Ehm, omdat ik toen ik mij aanmeldde bij HE niet wist dat dat kon? Plus ik heb mijn IPFire router-pc nog steeds niet met pensioen gestuurd, dat ik de HE-tunnel daar werkend in wist te krijgen was al opvallend omdat IPv6 officieel niet eens wordt ondersteund. Ik heb geen flauw idee hoe 6rd daar in werkend te krijgen...

Maar goed, mijn HE-tunnel werkt over het algemeen prima. Misschien dat @Tweak ooit native IPv6 gaat aanbieden?

[Roetzen]

Paul schreef op woensdag 16 augustus 2017 @ 07:21:
[...]
Ongetwijfeld, maar ze doen ook niet bijzonder moeilijk over een modemswap

Ik heb ook niet de indruk dat het erg makkelijk gaat. In elk geval kun je door een modem swap geen Dual Stack krijgen. Het enige consumentenmodem met een stabiele firmware voor Dual Stack is de Ubee EVW321B, maar die wordt door Ziggo niet meer uitgeleverd. Logisch want met zijn acht down kanalen is dat al weer achterhaalde techniek. Ik heb verleden jaar nog net op tijd op de juiste knoppen kunnen drukken en mijn op marktplaats verkregen EVW321 nog aangemeld kunnen krijgen, maar ik meen dat dat nu niet meer kan.

[...]
Waarom niet? Zelfs nog voordat je bij zaken als VLANs uit komt kun je onder Windows al probleemloos meerdere IP-adressen en routes opgeven, laat staan op een apparaat wat specifiek bedoeld is om netwerkzaken te regelen (en zelf al trucjes uithaalt om altijd op adressen als 192.168.100.1 te luisteren, ook als dat buiten het subnet ligt of het modem zelfs in bridge staat).

Mijn ervaring is dat het met Windows helemaal niet zo makkelijk gaat. Je kunt wel handmatig een vast adres invoeren, maar dan verdwijnt meteen DHCP en alle adressen die door DHCP zijn verkregen. Als één adres statisch is. moeten ze dat allemaal zijn.

Ik sluit niet uit dat het technisch wel mogelijk is, maar ik vermoed dat er geen bussines case is om voor die paar uizonderingen weer extra truken in te bouwen met alle kans op weer nieuwe bugs.

[...]
Ik dacht dat ik het over de migratie naar IPv6 toe had, maar mogelijk heb ik dat niet expliciet genoeg gezegd. De enige manier waarop ik bij Ziggo IPv6 kan krijgen is door mijn IPv4-adres in te leveren.

We waren even afgedwaald doordat DS-Lite werd gepresenteerd als oplossing voor het probleem van opraken van IPv4 adressen. En inderdaad, je kunt nu bij Ziggo op een consumentenaansluiting alleen nog IPv6 krijgen door je IPv4 adres in te leveren. Wil je Dual Stack dan moet je naar een (duur) zaken abonnement. Ik vermoed dat dat over niet al te lange tijd bij alle providers zo zal zijn.

[...]
echt nodig is daarmee niet 100% bewezen maar de huidige manier werkt toch prima? M.a.w. piepsysteem?

Het werkt omdat je middels dat piepsysteem geen Dual Stack kunt krijgen. Het is DS-Lite of IPv4 only. Zou Dual Stack ook een optie zijn, dan wil natuurlijk iedereen dat. Nu dwing je mensen een afweging te maken of ze echt wel IPv4 nodig hebben

Ik zou, mocht het zo ver komen, voorlopig op zich best bereid zijn er voor te betalen. Ik kom online bedragen tegen tussen de € 4 en € 15 eenmalig dus € 1 per maand lijkt me goed verdienen voor Ziggo (de huidige infra kan blijkbaar ook uit met het huidige abonnementsgeld, en als je de retentiedesk belt kan er nog flink wat van af ook).

€2/maand zou ik ook wel een goede deal vinden mocht dat aangeboden worden. Maar ik betwijfel dat Ziggo daar een Business case in ziet. Ik denk niet dat ze daar wat op verdienen. Te veel investering voor te weinig aantallen.

[Zr40]

Roetzen schreef op woensdag 16 augustus 2017 @ 15:19:
[...]
Het werkt omdat je middels dat piepsysteem geen Dual Stack kunt krijgen. Het is DS-Lite of IPv4 only. Zou Duals Stack ook een optie zijn, dan wil natuurlijk iedereen dat. Nu dwing je mensen een afweging te maken of ze echt wel IPv4 nodig hebben

De afweging die mensen in de praktijk maken is of ze echt wel IPv6 nodig hebben.

Daarom hebben we IPv4-only met fZiggo hier op kantoor

En klagende mensen wanneer ik de router advertisement voor de HE tunnel weer aan zet

[ Voor 7% gewijzigd door Zr40 op 16-08-2017 15:33 ]

[Roetzen]

elsinga schreef op woensdag 16 augustus 2017 @ 07:53:
Een niet routeerbaar IPv4 adres (CGNAT dus) of geen IPv4 adres (IPv6 only) gaat voor mij nu nog niet werken. Ik draai thuis websites (poorten 80 en 443), SFTP (poort 22 en nog een paar), VPN (ook een zooi poorten) en meer. Een proxy waar ik op hostname mee kan connecten en die dan IPv4 -> IPv6 doet zou helpen, zolang die proxy maar alle poorten doorstuurt en voldoende bandbreedte heeft. Ik heb niets aan een service die ik op poortnivo moet aansturen...

festeip.net biedt ook een volledige VPN tunnel aan met vast IPv4 adres. Er zijn meerdere aanbieders. Ik heb me daar niet echt in verdiept,omdat ik genoeg heb aan een paar poorten, maar ik weet dat ze er zijn.

Ziggo kan overigens vrij eenvoudig kijken of een aansluiting DS_Lite geschikt is of niet. Elke aansluiting waarbij er inkomend verkeer is op IPv4 is in elk geval niet geschikt.

Dat hoeft niet zo te zijn. Misschien komt het alleen maar op IPv4 binnen omdat er geen IPv6 is.

Zr40 schreef op woensdag 16 augustus 2017 @ 15:29:
[...]
De afweging die mensen in de praktijk maken is of ze echt wel IPv6 nodig hebben.

Daarom hebben we IPv4-only met fZiggo hier op kantoor

Kantoor? En geen Business Abo met Dual stack? Het mocht zeker weer niks kosten.

En klagende mensen wanneer ik de router advertisement voor de HE tunnel weer aan zet

Waarover klagen ze dan?

[ Voor 18% gewijzigd door Roetzen op 16-08-2017 16:07 ]

[Zr40]

Roetzen schreef op woensdag 16 augustus 2017 @ 16:03:
[...]
Kantoor? En geen Business Abo met Dual stack? Het mocht zeker weer niks kosten.
[...]

Juist. Connect ZZP is het abonnement. De benodigde port forwarding met dat enkele IPv4 adres is ook een drama. Maar de meerprijs van € 54/mnd voor Connect MKB weegt in de ogen van de verantwoordelijke daar niet tegen op.

Maar dan wel upgraden van 300/40 naar 500/40. Want dát scheelt in de praktijk veel tijd

Waarover klagen ze dan?

Bijvoorbeeld dat de downloadsnelheid van Debian mirrors veel lager is dan via IPv4 en dat 'het internet in het algemeen langzamer voelt'.

[ Voor 14% gewijzigd door Zr40 op 16-08-2017 16:26 ]

[Vorkie]

Zr40 schreef op woensdag 16 augustus 2017 @ 16:20:
[...]

Juist. Connect ZZP is het abonnement. De benodigde port forwarding met dat enkele IPv4 adres is ook een drama. Maar de meerprijs van € 54/mnd voor Connect MKB weegt in de ogen van de verantwoordelijke daar niet tegen op.

Maar dan wel upgraden van 300/40 naar 500/40. Want dát scheelt in de praktijk veel tijd


[...]

Bijvoorbeeld dat de downloadsnelheid van Debian mirrors veel lager is dan via IPv4 en dat 'het internet in het algemeen langzamer voelt'.

Dat laatste kunnen ze best zo ervaren toch? Wordt wel netjes Icmpv6 doorgelaten etc (denk stomme vraag )? Verder blijft het een tunnel, dus er zit altijd een extra latency bij en je deelt die tunnel server toch met velen.

[CyBeR]

Roetzen schreef op woensdag 16 augustus 2017 @ 16:03:
[...]

Kantoor? En geen Business Abo met Dual stack? Het mocht zeker weer niks kosten.

Ik heb thuis (en trouwens op kantoor ook) een zakelijk abo maar dan moet ik kiezen tussen m'n IPv4 /29 of IPv6. Ik wil natuurlijk allebei, maar dat lijkt nog niet te gaan.

[Roetzen]

Zr40 schreef op woensdag 16 augustus 2017 @ 16:20:
[...]

Juist. Connect ZZP is het abonnement. De benodigde port forwarding met dat enkele IPv4 adres is ook een drama. Maar de meerprijs van € 54/mnd voor Connect MKB weegt in de ogen van de verantwoordelijke daar niet tegen op.

Voor een beetje bedrijf met personeel is €54/mnd natuurlijk peanuts. Als je op die manier aan het beknibbelen bent op een essentiële voorziening, doe je iets verkeerd. Als het er een halve dag uit ligt kost het vele malen meer.

Maar dan wel upgraden van 300/40 naar 500/40. Want dát scheelt in de praktijk veel tijd

Helaas ben ik niet] onbekend met het verschijnsel van bezuinigen op de verkeerde zaken

Bijvoorbeeld dat de downloadsnelheid van Debian mirrors veel lager is dan via IPv4 en dat 'het internet in het algemeen langzamer voelt'.

Jammer want zo krijgt IPv6 een slechte naam.

CyBeR schreef op woensdag 16 augustus 2017 @ 18:24:


Ik heb thuis (en trouwens op kantoor ook) een zakelijk abo maar dan moet ik kiezen tussen m'n IPv4 /29 of IPv6. Ik wil natuurlijk allebei, maar dat lijkt nog niet te gaan.

Hmmm.. Ik meende dat je bij Connect MKB een /29 én een /48 kreeg. Misschien verschil tussen fZiggo en fUPC?

[ Voor 16% gewijzigd door Roetzen op 16-08-2017 18:33 ]

[CyBeR]

Zr40 schreef op woensdag 16 augustus 2017 @ 16:20:
[...]
Bijvoorbeeld dat de downloadsnelheid van Debian mirrors veel lager is dan via IPv4 en dat 'het internet in het algemeen langzamer voelt'.

Dat ligt aan jullie denk ik hoor…

[cyber@helene ~]$ wget -6 ftp://ftp.nl.debian.org/debian-cd/9.1.0/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso 
--2017-08-16 19:07:01--  ftp://ftp.nl.debian.org/debian-cd/9.1.0/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso
           => 'debian-9.1.0-amd64-netinst.iso'
Resolving ftp.nl.debian.org (ftp.nl.debian.org)... 2001:67c:2564:a120::21
Connecting to ftp.nl.debian.org (ftp.nl.debian.org)|2001:67c:2564:a120::21|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /debian-cd/9.1.0/amd64/iso-cd ... done.
==> SIZE debian-9.1.0-amd64-netinst.iso ... 304087040
==> EPSV ... done.    ==> RETR debian-9.1.0-amd64-netinst.iso ... done.
Length: 304087040 (290M) (unauthoritative)

debian-9.1.0-amd64-netinst.iso      100%[==================>] 290.00M  97.2MB/s   in 3.0s   

2017-08-16 19:07:04 (97.2 MB/s) - 'debian-9.1.0-amd64-netinst.iso' saved [304087040]

Roetzen schreef op woensdag 16 augustus 2017 @ 18:24:
[...]

Hmmm.. Ik meende dat je bij Connect MKB een /29 én een /48 kreeg. Misschien verschil tussen fZiggo en fUPC?

Wellicht. In ieder geval waren dat mijn opties op fUPC. Ik heb inderdaad beide gezien op Ziggo vroeger, ondanks dat het IPv6-deel toen nog niet werkte.

[ Voor 18% gewijzigd door CyBeR op 16-08-2017 19:09 ]

[elsinga]

Ach, ik zit momenteel (nou ja, al 2 jaar) op een project bij onze grote groene telecom provider en daar intern is het strikt IPv4 en niks IPv6. Een DS-Lite aansluiting kun je daar vandaan dus niet eens bereiken...

[Vorkie]

elsinga schreef op woensdag 16 augustus 2017 @ 19:32:
Ach, ik zit momenteel (nou ja, al 2 jaar) op een project bij onze grote groene telecom provider en daar intern is het strikt IPv4 en niks IPv6. Een DS-Lite aansluiting kun je daar vandaan dus niet eens bereiken...

Je bent niet zo 1 2 3 om naar Ipv6 hoor al helemaal niet in een infrastructuur welke meermaals is samengevoegd, vervangen en beheerd door meerdere partijen.... en de daarbij behorende ontbrekende stukken documentatie en "legacy" applicaties.

Verder kan er zo maar ergens een core team met Ipv6 bezig zijn en deze pas naar de organisatie breed uitrollen als er voldaan is aan een zooi voorwaarden mbt applicaties.

IPv6 heeft natuurlijk wel zo zijn keuzes binnen grote, bewegelijke, organisaties. In tegenstelling tot een 192.168.x.x subnetje.

[Zr40]

CyBeR schreef op woensdag 16 augustus 2017 @ 19:07:
[...]


Dat ligt aan jullie denk ik hoor…

[cyber@helene ~]$ wget -6 ftp://ftp.nl.debian.org/debian-cd/9.1.0/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso 
--2017-08-16 19:07:01--  ftp://ftp.nl.debian.org/debian-cd/9.1.0/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso
           => 'debian-9.1.0-amd64-netinst.iso'
Resolving ftp.nl.debian.org (ftp.nl.debian.org)... 2001:67c:2564:a120::21
Connecting to ftp.nl.debian.org (ftp.nl.debian.org)|2001:67c:2564:a120::21|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /debian-cd/9.1.0/amd64/iso-cd ... done.
==> SIZE debian-9.1.0-amd64-netinst.iso ... 304087040
==> EPSV ... done.    ==> RETR debian-9.1.0-amd64-netinst.iso ... done.
Length: 304087040 (290M) (unauthoritative)

debian-9.1.0-amd64-netinst.iso      100%[==================>] 290.00M  97.2MB/s   in 3.0s   

2017-08-16 19:07:04 (97.2 MB/s) - 'debian-9.1.0-amd64-netinst.iso' saved [304087040]

Vergelijk:

...@router:~$ curl -4 ftp://ftp.nl.debian.org/debian-cd/9.1.0/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  290M  100  290M    0     0  16.1M      0  0:00:17  0:00:17 --:--:-- 20.2M
...@router:~$ curl -6 ftp://ftp.nl.debian.org/debian-cd/9.1.0/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  9  290M    9 27.3M    0     0  1247k      0  0:03:58  0:00:22  0:03:36 1997k^C

Al komt IPv4 met die 20.2 MB/s ook lang niet in de buurt van 500 Mbit/s.

[Compizfox]

Zr40 schreef op woensdag 16 augustus 2017 @ 10:55:
@Raven Waarom eigenlijk geen 6rd van Tweak zelf? Bij mij werkt dat uitstekend. (Op de MTU van 1480 na bij sites met defecte PMTUD, maar dat geldt voor elke 6in4 tunnel...)

Kan ik bevestigen, ben laatst ook overgegaan naar 6rd van Tweak nadat SixXS ermee stopte.

Problemen met PMTUD-blackholes kun je trouwens vermijden d.m.v. MSS clamping op je router.

[MrNGm]

Zr40 schreef op woensdag 16 augustus 2017 @ 19:52:
[...]


Vergelijk:

...@router:~$ curl -4 ftp://ftp.nl.debian.org/debian-cd/9.1.0/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  290M  100  290M    0     0  16.1M      0  0:00:17  0:00:17 --:--:-- 20.2M
...@router:~$ curl -6 ftp://ftp.nl.debian.org/debian-cd/9.1.0/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  9  290M    9 27.3M    0     0  1247k      0  0:03:58  0:00:22  0:03:36 1997k^C

Al komt IPv4 met die 20.2 MB/s ook lang niet in de buurt van 500 Mbit/s.

mrngm@oreokoekje2:~$ curl -4 ftp://ftp.nl.debian.org/debian-cd/9.1.0/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  290M  100  290M    0     0  11.1M      0  0:00:26  0:00:26 --:--:-- 11.1M
mrngm@oreokoekje2:~$ curl -6 ftp://ftp.nl.debian.org/debian-cd/9.1.0/amd64/iso-cd/debian-9.1.0-amd64-netinst.iso -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  290M  100  290M    0     0  10.5M      0  0:00:27  0:00:27 --:--:-- 10.8M

Bovenste is (uiteindelijk) een Ziggo Grootzakelijk-aansluiting (studentencomplex), onderste is een (inmiddels naar London-gemigreerde) HE-tunnel (via dezelfde aansluiting natuurlijk ). De host zit via een switch aan de router, vanuit daar gaat het naar het Grote Boze Internet.

Sta je bepaalde ICMPv6-berichten niet toe? Het grote PMTUD-verhaal wat wel vaker wordt gebezigd...

[Zr40]

Aan deze kant wordt geen ICMPv6 tegengehouden. (Ik leg dit zelf nog regelmatig uit aan anderen )

Maar waar het dan wel door komt is mij een raadsel... Er zit verder ook niets bijzonders tussen de router (een EdgeRouter lite, waar ook de HE tunnel op geconfigureerd is) en het Ziggo modem (een Connect Box in bridge modus).

Misschien een brakke ethernetkabel, maar dat zou dan de eerste zijn die extra gevoelig is voor IPv6

[ Voor 5% gewijzigd door Zr40 op 16-08-2017 21:51 ]

[MrNGm]

Enige wat ik me dan kan voorstellen is dat de MTU van de tunnel te hoog staat, óf er ergens verderop in het netwerk aan QoS wordt gedaan voor 'vreemd traffic' (wat niet zou mogen). In mijn geval (Mikrotik RB750GL) staat ie op 1280.

Maar goed, works for me

[elsinga]

Vorkie schreef op woensdag 16 augustus 2017 @ 19:37:
[...]

Je bent niet zo 1 2 3 om naar Ipv6 hoor al helemaal niet in een infrastructuur welke meermaals is samengevoegd, vervangen en beheerd door meerdere partijen.... en de daarbij behorende ontbrekende stukken documentatie en "legacy" applicaties.

Verder kan er zo maar ergens een core team met Ipv6 bezig zijn en deze pas naar de organisatie breed uitrollen als er voldaan is aan een zooi voorwaarden mbt applicaties.

IPv6 heeft natuurlijk wel zo zijn keuzes binnen grote, bewegelijke, organisaties. In tegenstelling tot een 192.168.x.x subnetje.

Ik weet dat IPv6 implementeren tijd kost, maar zonder IPv6 (en dat was mijn argument om geen DS-Lite te willen) op de werkvloer kan ik met DS-Lite niet bij mijn thuisnetwerk. En een IPv4->IPv6 proxy is ook niet ideaal, want bandbreedte beperking van de proxy. Ik zou dan liever 1 euro per maand meer aan Ziggo betalen voor echte dual stack of de huidige IPv4 only versie. Dan maar een 6in4 tunnel zoals ik die nu gewoon draai, iemand met alleen IPv6 komt er dan wel (zij het met de bandbreedte beperking van de tunnel host).

[Zsub]

Zr40 schreef op woensdag 16 augustus 2017 @ 21:46:
Aan deze kant wordt geen ICMPv6 tegengehouden. (Ik leg dit zelf nog regelmatig uit aan anderen )

Maar waar het dan wel door komt is mij een raadsel... Er zit verder ook niets bijzonders tussen de router (een EdgeRouter lite, waar ook de HE tunnel op geconfigureerd is) en het Ziggo modem (een Connect Box in bridge modus).

Misschien een brakke ethernetkabel, maar dat zou dan de eerste zijn die extra gevoelig is voor IPv6

Ik zie het nu al voor me, ethernetkabels speciaal voor IPv6, net zoals van die HDMI kabels die speciaal voor HD zijn

[Roetzen]

Zsub schreef op donderdag 17 augustus 2017 @ 08:21:
[...]

Ik zie het nu al voor me, ethernetkabels speciaal voor IPv6, net zoals van die HDMI kabels die speciaal voor HD zijn

offtopic:
In de jaren 60 van de vorige eeuw waren er slimmerikken die kleurenTV antennes verkochten...

[kdbruin]

Zoals al enige malen hier is genoemd, is het nogal een uitdaging om een beetje recente informatie omtrent IPv6 te vinden. Ik heb een XS4All abonnement en heb hierbij dus ook een IPv6 adres gekregen. In de Fritz!Box heb ik voor IPv4 DHCP uitgezet en dit via m'n eigen ISC DHCP server geregeld (op een FreeBSD server). Ik kan dan gemakkelijk op basis van MAC adressen IPv4 adressen uitdelen.

Nu wil ik op m'n thuisnetwerk (combinatie FreeBSD, macOS, iOS, Android) ook IPv6 gaan configureren maar waar vind ik nu een beetje up-to-date informatie? Het liefst in combinatie met wat XS4All nu levert.

[Roetzen]

elsinga schreef op donderdag 17 augustus 2017 @ 06:47:
Ik weet dat IPv6 implementeren tijd kost, maar zonder IPv6 (en dat was mijn argument om geen DS-Lite te willen) op de werkvloer kan ik met DS-Lite niet bij mijn thuisnetwerk.

Is het voor je werk essentiëel dan dat je vanaf de werkvloer bij je thuisnetwerk kan? Want in dat geval zou ik zeggen dat het een probleem van je baas is. Moet ie maar zorgen dat er IPv6 op de werkvloer is. *1)

En een IPv4->IPv6 proxy is ook niet ideaal, want bandbreedte beperking van de proxy.

Gelukkig ben ik gepensioneerd en heb ik al die problemen niet meer. Voor mij is het genoeg als ik vanaf de camping bij mijn servers thuis kan en dan is een proxy niet de bottleneck, dat is meestal de WiFi op de camping. Maar op de camping heb ik geen haast.

*1) Tenzij je eigen baas bent natuurlijk. Dan heb je een probleem.

[MrNGm]

Zsub schreef op donderdag 17 augustus 2017 @ 08:21:
[...]

Ik zie het nu al voor me, ethernetkabels speciaal voor IPv6, net zoals van die HDMI kabels die speciaal voor HD zijn

Ik heb nog wel ergens een stukje IPv6-compatible CAT5e liggen van har2009! The future is now

[JackBol]

elsinga schreef op donderdag 17 augustus 2017 @ 06:47:
[...]


Ik weet dat IPv6 implementeren tijd kost, maar zonder IPv6 (en dat was mijn argument om geen DS-Lite te willen) op de werkvloer kan ik met DS-Lite niet bij mijn thuisnetwerk. En een IPv4->IPv6 proxy is ook niet ideaal, want bandbreedte beperking van de proxy. Ik zou dan liever 1 euro per maand meer aan Ziggo betalen voor echte dual stack of de huidige IPv4 only versie. Dan maar een 6in4 tunnel zoals ik die nu gewoon draai, iemand met alleen IPv6 komt er dan wel (zij het met de bandbreedte beperking van de tunnel host).

Neem een vps van €1 per maand en zet je eigen v4 naar v6 proxy op.

[elsinga]

@JackBol, dat kan ook prima, maar dan nog kunnen (zullen, gok ik) bandbreedte en traffic beperkt zijn. Naast uiteraard diezelfde beperkingen op het netwerkpad van <extern> naar mijn Ziggo modem, maar die heb ik altijd al. Nu zou ik met een proxy extra beperkingen (kunnen) introduceren.

[hkoster1]

@Roetzen Ik heb nu met hulp van @VodafoneZiggo een ConnectBox gekregen, en deze startte inderdaad met DS-Lite. Eind goed, al goed. Voor zover ik kan nagaan (heb nog niet alle instellingen van de CB doorgenomen) heb ik nu een /64 aansluiting.

[Roetzen]

hkoster1 schreef op donderdag 17 augustus 2017 @ 15:57:
@Roetzen Ik heb nu met hulp van @VodafoneZiggo een ConnectBox gekregen, en deze startte inderdaad met DS-Lite. Eind goed, al goed. Voor zover ik kan nagaan (heb nog niet alle instellingen van de CB doorgenomen) heb ik nu een /64 aansluiting.

Je hebt waarschijnlijk een /56 waarvan alleen de eerste /64 door de connect box voor het LAN wordt gebruikt. Bij het doorspitten van de configuratie zal je dat wel ergens tegenkomen.

Ik ben benieuwd hoe je ervaringen met DS-Lite zijn.

We wachten het af.

[hkoster1]

Mijn DS-Lite ConnectBox gebruikt (geanonimiseerd) LAN-prefix 2001:1c01:yyyy:zz00::/64.
Met een /56 zijn er 256 mogelijke LANs, zz00-zzff.

Ik heb net een andere router (een Fritz!Box 7490 die ik nog had liggen) achter de ConnectBox geplaatst, deze heeft LAN-prefix zzf0 en krijgt dus kennelijk een /60 van de ConnectBox.

Dit alles is voor een eenvoudige consumentenaansluiting maar een beetje Spielerei...

[Roetzen]

hkoster1 schreef op vrijdag 18 augustus 2017 @ 11:49:
Mijn DS-Lite ConnectBox gebruikt (geanonimiseerd) LAN-prefix 2001:1c01:yyyy:zz00::/64.
Met een /56 zijn er 256 mogelijke LANs, zz00-zzff.

Ik heb net een andere router (een Fritz!Box 7490 die ik nog had liggen) achter de ConnectBox geplaatst, deze heeft LAN-prefix zzf0 en krijgt dus kennelijk een /60 van de ConnectBox.

En van die /60 pakt de Fritz dan weer een of meer /64s voor zijn eigen LAN(s) en de rest van de /60 kan ie weer uitdelen aan een router die daar weer achter hangt

Ja, zo is het inderdaad bedoeld met die subnetten. Leuk dat het ook echt werkt!

Dit alles is voor een eenvoudige consumentenaansluiting maar een beetje Spielerei...

Leuk om mee te spelen toch?

[St00mwals]

Tomsworld schreef op dinsdag 15 augustus 2017 @ 17:27:
DS-Lite is ook problematisch, wij hebben @ work op dit moment contact met Telenet voor klanten die achter ds-lite zitten waar sommige applicaties breken. Ondertussen wel al een paar pistes gevonden. Maar in de praktijk is het DS-Lite uitzetten op die lijnen.

Daarentegen leveren telenet / proximus hier in België wel full dual stack en is de discussie enkel de weg indien de ipv4 op is.

Voor de eigen ipv4 loze connecties :
Proximus doet CGNAT.
Telenet doet DS-Lite.

Volgens mij heb je dan ook een mooie business case richting het management om aan de buitenkant IPv6 in te richten.
Of hebben jullie dit al?

[Tomsworld]

St00mwals schreef op vrijdag 18 augustus 2017 @ 13:08:
[...]

Volgens mij heb je dan ook een mooie business case richting het management om aan de buitenkant IPv6 in te richten.
Of hebben jullie dit al?

Wij hebben al ipv6 aan de buitenkant volop aan het uitrollen. Maar soit business moet ook meewillen en sommige dingen vervangen duurt iets langer ( tenders etc etc). Maar ik kan niet veel in detail gaan snel gezegd met dslite ipv4 komt mtu weer heel hard in het vizier, als je dan ergens als provider een machine heeft in je path die zo'n packet too big niet goed behandeld ...

[agresionpower]

Interessant, volgens Akamai heeft de VS Belgie ingehaald:
https://www.akamai.com/us...doption-visualization.jsp

[Roetzen]

Inderdaad opmerkelijk. Vooral omdat men in de VS als een van de laatsten door het IPv4 heen was.

En Nederland bungelt met 7% op een eerloze 28e plaats. Waar blijven we nou met Nederland kennis- en innovatieland??

[darkrain]

Roetzen schreef op zaterdag 19 augustus 2017 @ 11:56:
En Nederland bungelt met 7% op een eerloze 28e plaats. Waar blijven we nou met Nederland kennis- en innovatieland??

Gelukkig hangt dat niet alleen van IPv6 af

[Raven]

Roetzen schreef op zaterdag 19 augustus 2017 @ 11:56:
Inderdaad opmerkelijk. Vooral omdat men in de VS als een van de laatsten door het IPv4 heen was.

En Nederland bungelt met 7% op een eerloze 28e plaats. Waar blijven we nou met Nederland kennis- en innovatieland??

offtopic:
En het is ook nog eens het land waar inbelverbindingen niet uitgestorven zijn, althans, een paar jaar terug nog niet.

In 2014 was er een nieuwsuitzending op RTL4 dat 1 op de 7 Amerikanen in de VS geen (fatsoenlijke) internetverbinding heeft. De reporter zat bij iemand die voor €30 (of was het $30) per maand een inbelverbinding heeft en gewoon 5 minuten moet wachten tot Google geladen is Die vroeg zijn familie geen foto's meer te emailen omdat ie ze toch niet kan openen.
Het linkje naar het beeldmateriaal doet het helaas niet meer.

Maar het valt wel op dat de providers daar wat ijveriger lijken te zijn: https://medium.com/@Gtwy/...-to-the-home-f106d64d5f51 Als ze met IPv6 ook zo ijverig bezig zijn

[RedShift]

agresionpower schreef op zaterdag 19 augustus 2017 @ 11:46:
Interessant, volgens Akamai heeft de VS Belgie ingehaald:
https://www.akamai.com/us...doption-visualization.jsp

Neeeeeeeeeeeeeee

* RedShift is Belg

[agresionpower]

De website van apnic heeft wel vaker wat heftige uitslagen, maar ik vraag me toch af wat er hier gebeurd is:
https://stats.labs.apnic....1136?c=NL&p=1&v=1&w=1&x=1

[Dreamvoid]

agresionpower schreef op zaterdag 19 augustus 2017 @ 11:46:
Interessant, volgens Akamai heeft de VS Belgie ingehaald:
https://www.akamai.com/us...doption-visualization.jsp

Interessant inderdaad - op 25 Mei is Cloudflare overgeschakeld naar always-on ipv6 op hun domeinen, en direct schiet de hele VS omhoog.

Andere lollige stats zie je bij het minuscule tropische eilandje Tokelau (bekend van het .tk domein), nummer 10 op de lijst, waar ipv6 deze maand van 0.0% naar 19.9% gestegen is

[ Voor 17% gewijzigd door Dreamvoid op 22-08-2017 11:53 ]

[Roetzen]

Verleden keer leek het even de goede kant op te gaan. Maar nee, helaas.

[valkenier]

Roetzen schreef op dinsdag 22 augustus 2017 @ 22:14:
Verleden keer leek het even de goede kant op te gaan. Maar nee, helaas.

[afbeelding]

Al 1,5 jaar geen enkele ontwikkeling als je het goed bekijkt. best wel treurig voor zo'n grote provider.

[Ivar1984]

valkenier schreef op dinsdag 22 augustus 2017 @ 22:31:
[...]
Al 1,5 jaar geen enkele ontwikkeling als je het goed bekijkt. best wel treurig voor zo'n grote provider.

Aangezien er in die tijd ook geen publieke vooruitgang in fZiggo's (AS9143) IPv6 uitrol zit lijkt die daling me vrij voorspelbaar, nu die Ubee 321b's langzaamaan vervangen worden door Connectboxen (met alleen IPv4?).
aan de andere kant, ze waren Dual Stack op de Cisco 3928 aan het testen en ook de TC7210 heeft net een update gehad, er is dus nog een sprankje hoop

Wat ik me afvraag is: nu DS-Lite (op de CB) blijkbaar ook de nieuwe standaard is in fZiggo gebied, gaat dat dan via 'het UPC netwerk' (Liberty Global AS6830)?
Om dat te beantwoorden, kan iemand met DS-Lite in fZiggo melden welke prefix je krijgt? een /56 uit de 2001:1c00/23 of 2a02:a200/27 range?

Voor zover ik weet is er voor AS6830 niet zo'n maandelijkse meting van alleen NL, alleen bij APNIC kun je dat wel makkelijk filteren en dan krijg je dit:
https://stats.labs.apnic....c=&x=0&s=0&p=1&w=1&ccc=NL
daar zie je (met een hoger 'avg interval days') over de afgelopen maanden toch een toename.

[stormfly]

Ivar1984 schreef op woensdag 23 augustus 2017 @ 00:13:
[...]

Aangezien er in die tijd ook geen publieke vooruitgang in fZiggo's (AS9143) IPv6 uitrol zit lijkt die daling me vrij voorspelbaar, nu die Ubee 321b's langzaamaan vervangen worden door Connectboxen (met alleen IPv4?).
aan de andere kant, ze waren Dual Stack op de Cisco 3928 aan het testen en ook de TC7210 heeft net een update gehad, er is dus nog een sprankje hoop

Wat ik me afvraag is: nu DS-Lite (op de CB) blijkbaar ook de nieuwe standaard is in fZiggo gebied, gaat dat dan via 'het UPC netwerk' (Liberty Global AS6830)?
Om dat te beantwoorden, kan iemand met DS-Lite in fZiggo melden welke prefix je krijgt? een /56 uit de 2001:1c00/23 of 2a02:a200/27 range?

Voor zover ik weet is er voor AS6830 niet zo'n maandelijkse meting van alleen NL, alleen bij APNIC kun je dat wel makkelijk filteren en dan krijg je dit:
https://stats.labs.apnic....c=&x=0&s=0&p=1&w=1&ccc=NL
daar zie je (met een hoger 'avg interval days') over de afgelopen maanden toch een toename.

De ConnectBox Compal en de ConnectBox Arris (beta) zijn nagenoeg gelijk en kunnen dus dezelfde diensten faciliteren inclusief de reeds bekende IPv6 smaken. Je theorie zal kloppen dat er steeds minder UBEE modems zijn, en de Cisco 3928 is nog in software ontwikkeling mbt IPv6.

Wat meet de grafiek, want prefix toename zal je niet snel zien met de uberblokken met IPv6? Meet hij hits op bepaalde servers? Want voor IPv4 is het al zeer geruime tijd zo, dat al het verkeer waar fZiggo lokale peerings mee had via AS9143 uitbreekt. Al het transit verkeer (of een optimaler pad op de fUPC core) zal via 6830 naar buiten gaan.

Uiteindelijk zal jouw prefix aan een bepaald AS toebehoren, ik ben dus ook wel benieuwd naar de test die je vraag.

code:

traceroute to nunl.aws.sanomaservices.nl (54.230.128.37), 64 hops max, 52 byte packets
 1  [AS0] 172.16.1.1 (172.16.1.1)  3.180 ms  2.794 ms  3.412 ms
 2  * * *
 3  [AS9143] hvs-rc0002-cr102-xe-3-1-4-0.core.as9143.net (213.51.190.157)  10.731 ms  10.513 ms  10.428 ms
 4  [[b]AS9143[/b]] asd-tr0610-cr101-ae57-0.core.as9143.net (213.51.158.4)  11.425 ms  6.572 ms  11.539 ms
 5  [AS1200] ams1-br-tra-r2.amazon.com (80.249.210.217)  12.980 ms  10.443 ms  10.307 ms
 6  * * *

Of via 6830

code:

traceroute to espncseonesitealb-5974746.us-west-2.elb.amazonaws.com (35.166.107.102), 64 hops max, 52 byte packets
 1  [AS0] 172.16.1.1 (172.16.1.1)  140.732 ms  3.526 ms  2.478 ms
 2  * * *
 3  [AS9143] hvs-rc0002-cr102-xe-3-1-4-0.core.as9143.net (213.51.190.157)  10.555 ms  11.010 ms  11.149 ms
 4  [AS6830] nl-ams02a-rc2-lag-7-0.aorta.net (84.116.134.90)  11.576 ms  14.384 ms  11.525 ms
 5  [AS6830] nl-ams04a-ri2-ae7-0.aorta.net (84.116.134.89)  12.584 ms  10.988 ms  11.355 ms
 6  [AS1200] ae-6.r25.amstnl02.nl.bb.gin.ntt.net (80.249.208.36)  11.741 ms  11.075 ms  198.233 ms
 7  [AS2914] ae-5.r23.asbnva02.us.bb.gin.ntt.net (129.250.6.162)  276.748 ms  234.830 ms  187.286 ms
 8  [AS2914] ae-10.r22.snjsca04.us.bb.gin.ntt.net (129.250.6.237)  181.110 ms  309.445 ms  183.884 ms
 9  [AS2914] ae-40.r02.snjsca04.us.bb.gin.ntt.net (129.250.3.121)  182.392 ms  178.330 ms
    [AS2914] ae-19.r01.snjsca04.us.bb.gin.ntt.net (129.250.3.27)  317.078 ms
10  [AS2914] ae-0.a02.snjsca04.us.bb.gin.ntt.net (129.250.2.3)  183.463 ms  311.461 ms
    [AS2914] ae-1.a02.snjsca04.us.bb.gin.ntt.net (129.250.3.103)  169.690 ms
11  [AS2914] ae-0.amazon.snjsca04.us.bb.gin.ntt.net (128.241.219.18)  180.190 ms
    [AS2914] ae-1.amazon.snjsca04.us.bb.gin.ntt.net (128.242.179.50)  173.129 ms
    [AS2914] ae-0.amazon.snjsca04.us.bb.gin.ntt.net (128.241.219.18)  178.695 ms
12  [AS16509] 54.240.242.112 (54.240.242.112)  184.307 ms
    [AS16509] 54.240.242.152 (54.240.242.152)  190.104 ms
    [AS16509] 54.240.242.112 (54.240.242.112)  179.515 ms
13  [AS16509] 54.240.242.121 (54.240.242.121)  181.518 ms
    [AS16509] 54.240.242.117 (54.240.242.117)  181.044 ms
    [AS16509] 54.240.242.119 (54.240.242.119)  182.949 ms
14  * * [AS16509] 205.251.229.202 (205.251.229.202)  203.636 ms
15  * * *
16  [AS16509] 205.251.232.82 (205.251.232.82)  182.564 ms * *
17  * * *
18  * * *
19  * * *
20  * [AS16509] 205.251.232.255 (205.251.232.255)  268.830 ms  321.605 ms

[darkrain]

valkenier schreef op dinsdag 22 augustus 2017 @ 22:31:
[...]


Al 1,5 jaar geen enkele ontwikkeling als je het goed bekijkt. best wel treurig voor zo'n grote provider.

Dit is niet helemaal juist, er zijn wel ontwikkelingen alleen die zien we nog niet in deze grafiek...
Er lopen testen voor diverse modems om ze op IPv6 te krijgen bij Ziggo. Gelukkig maar want er zijn toch al wat problemen naar voren gekomen in deze testen, die wil Ziggo graag eerst oplossen voor ze het overal uitrollen.

Ik ben met je eens dat ze veel te laat zijn, maar er is wel degelijk ontwikkeling.

[valkenier]

darkrain schreef op woensdag 23 augustus 2017 @ 10:34:
[...]

Dit is niet helemaal juist, er zijn wel ontwikkelingen alleen die zien we nog niet in deze grafiek...
Er lopen testen voor diverse modems om ze op IPv6 te krijgen bij Ziggo. Gelukkig maar want er zijn toch al wat problemen naar voren gekomen in deze testen, die wil Ziggo graag eerst oplossen voor ze het overal uitrollen.

Ik ben met je eens dat ze veel te laat zijn, maar er is wel degelijk ontwikkeling.

Voor zover ik weet is ipv6 alleen actief op de ubee modems, en nu op de connectbox. Er is een recent een test geweest met nieuwe firmware voor de cisco's, maar volgens mij ook niet succesvol, en ook niet voor andere modems.
In de grafiek zie ik zelfs een langzaam dalende trend, ondanks de korte piek op het eind. Er is een nieuwe firmware voor de TC7210, maar die heeft nog lang niet iedereen, en ik heb niet vernomen dat hiermee ipv6 wordt geïmplementeerd. Voor klanten met modem in bridge wordt helemaal niets uitgerold of getest. Reden? Weten we niet.
Ik ben het met je eens dat er eerst getest moet worden, maar dat had toch al veel eerder/sneller gekund. Deze grafiek laat echt zien dat Ziggo het afgelopen 1,5 jaar geen concrete vooruitgang heeft geboekt. (behoudens een test op de cisco, wat ik niet meer dan beperkte ontwikkeling zou willen noemen).

[ik222]

De realiteit is helaas dat IPv6 in professionele netwerkapparatuur gebruikt door ISP's nog lang niet altijd uitontwikkeld is. Ik kom nog steeds regelmatig IPv6 specifieke bugs tegen, en om daar dan een fix voor te krijgen kan zo weer maanden duren waarna het testen weer opnieuw begint etc. De basis werkt vaak allemaal wel maar als ISP gebruik je veel meer en specifieke features en zodra je die aanzet gaat het nog regelmatig mis.

Het is bijvoorbeeld ook geen toeval dat bijna overal waar IPv6 wel op grote schaal uitgerold is dit op basis van PPP gaat, met die oplossing is er simpelweg minimale / geen IPv6 specifieke ondersteuning nodig op de access laag.

Er wordt echt wel vooruitgang geboekt hoor maar dat is niet altijd terug te zien in uitrol cijfers. IPv6 uitrollen op alle type netwerken zonder de kwaliteit van de dienstverlening te raken kost gewoon veel tijd.

[darkrain]

valkenier schreef op woensdag 23 augustus 2017 @ 12:07:
[...]


Voor zover ik weet is ipv6 alleen actief op de ubee modems, en nu op de connectbox. Er is een recent een test geweest met nieuwe firmware voor de cisco's, maar volgens mij ook niet succesvol, en ook niet voor andere modems.
In de grafiek zie ik zelfs een langzaam dalende trend, ondanks de korte piek op het eind. Er is een nieuwe firmware voor de TC7210, maar die heeft nog lang niet iedereen, en ik heb niet vernomen dat hiermee ipv6 wordt geïmplementeerd. Voor klanten met modem in bridge wordt helemaal niets uitgerold of getest. Reden? Weten we niet.
Ik ben het met je eens dat er eerst getest moet worden, maar dat had toch al veel eerder/sneller gekund. Deze grafiek laat echt zien dat Ziggo het afgelopen 1,5 jaar geen concrete vooruitgang heeft geboekt. (behoudens een test op de cisco, wat ik niet meer dan beperkte ontwikkeling zou willen noemen).

Die test met Cisco ben ik van op de hoogte, sterker nog daar doe ik aan mee... Die test loopt overigens nog steeds, maar er zijn problemen gevonden die nu opgelost moeten worden door Cisco. Dat is trouwens een langdurig proces helaas.

De Connectbox heeft ook even geduurd omdat ze daar ook een gedegen test mee hebben gedaan, die is nu klaar voor zover ik weet (wel DS-lite maar goed).

Tuurlijk had het allemaal veel eerder gemoeten, IPv6 bestaat al ff (1998 uit mijn hoofd), maar ik blijf erbij dat Ziggo wel degelijk in de goede richting aan het werken is. Het is nou eenmaal geen makkelijke opgave om dit te doen naast alle andere veranderingen en upgrades die Ziggo aan het doen is op zijn netwerk (Docsis 3.1...).

ik222 schreef op woensdag 23 augustus 2017 @ 12:33:
Er wordt echt wel vooruitgang geboekt hoor maar dat is niet altijd terug te zien in uitrol cijfers. IPv6 uitrollen op alle type netwerken zonder de kwaliteit van de dienstverlening te raken kost gewoon veel tijd.

Precies dit.

[ANdrode]

stormfly schreef op woensdag 23 augustus 2017 @ 02:47:
[...]
Wat meet de grafiek, want prefix toename zal je niet snel zien met de uberblokken met IPv6? Meet hij hits op bepaalde servers? Want voor IPv4 is het al zeer geruime tijd zo, dat al het verkeer waar fZiggo lokale peerings mee had via AS9143 uitbreekt. Al het transit verkeer (of een optimaler pad op de fUPC core) zal via 6830 naar buiten gaan.

Uiteindelijk zal jouw prefix aan een bepaald AS toebehoren, ik ben dus ook wel benieuwd naar de test die je vraag.

Dit lijkt inderdaad net zo te gaan als bij IPv4. Ik heb twee ripe atlas probes gedaan (traceroute, ipv6) met alle probes met IPv6 in fZiggo/fUPC ASN. Naar www.nos.nl en www.kame.net.

Via de links kan je in alle data speuren. Maar hieronder staan twee screenshots van de 'tracemon' tool waarop ik mijn conclusies baseer.

www.kame.net:
Het internationale verkeer gaat via AS6830/Aorta


www.nos.nl:
fZiggo verkeer gaat via peering op AMS-IX. fUPC verkeer gaat via transit (KPN Eurorings?!). AMS-IX - NOS gaat via Surfnet,


Wie kijkt er even naar het lijstje v6 peers van AS6830?

[Teleflubbie]

IPv6 Firewall van de Ziggo Ubee EVW321 lijkt niet te werken?

Zag dat al enige tijd IPv6 was geactiveerd op mijn Ziggo EVW321. Ik zie dat mijn servers op het thuisnetwerk netjes een global ipv6 (2001:...) krijgen.

Echter, wat mij zorgen baart is dat ik deze servers vanaf het internet direct benaderbaar zijn (ping).
Dit terwijl de optie "IPV6 firewall" in de Ubee EVW321 op "ON" staat.

Wat gaat er hier niet goed?

[Vorkie]

Randy.W schreef op dinsdag 29 augustus 2017 @ 08:17:
IPv6 Firewall van de Ziggo Ubee EVW321 lijkt niet te werken?

Zag dat al enige tijd IPv6 was geactiveerd op mijn Ziggo EVW321. Ik zie dat mijn servers op het thuisnetwerk netjes een global ipv6 (2001:...) krijgen.

Echter, wat mij zorgen baart is dat ik deze servers vanaf het internet direct benaderbaar zijn (ping).
Dit terwijl de optie "IPV6 firewall" in de Ubee EVW321 op "ON" staat.

Wat gaat er hier niet goed?

Kennis van IPv6 gaat hier niet goed


Als je er zin in hebt
https://tools.ietf.org/html/rfc4443

[Teleflubbie]

Vorkie schreef op dinsdag 29 augustus 2017 @ 08:25:
[...]

Kennis van IPv6 gaat hier niet goed


Als je er zin in hebt
https://tools.ietf.org/html/rfc4443

Dat kan best, want ik ben me er net in aan het verdiepen......

Uit het document, haal ik niet zo snel waar mijn denkfout zit.
Uit andere artikelen heb ik begrepen, dat een IPv6 firewall dit zou moeten kunnen afschermen.

Heb je een meer concrete hint voor me???

[Vorkie]

Randy.W schreef op dinsdag 29 augustus 2017 @ 08:41:
[...]

Dat kan best, want ik ben me er net in aan het verdiepen......

Uit het document, haal ik niet zo snel waar mijn denkfout zit.
Uit andere artikelen heb ik begrepen, dat een IPv6 firewall dit zou moeten kunnen afschermen.

Heb je een meer concrete hint voor me???

ICMPv6 is een "vereiste" voor IPv6, de problemen met NOS.nl waren hier een goed voorbeeld van, hun firewalls blokkeerden ICMPv6, waardoor o.a. Packet-too-big niet juist werd uitgevoerd en daardoor dus de site onbereikbaar was.

In tegenstelling heb je met IPv6 geen NAT, maar publiekelijk routeerbare adressen. In plaats van dat je dus een NAT rule maakt om een poort te openen, maak je een firewall regel aan dat verkeer naar je IPv6 server mag plaatsvinden. (Bij NAT deed je WAN ip naar 192.168.2.5, bij IPv6 forward je het verkeer)

[Teleflubbie]

Vorkie schreef op dinsdag 29 augustus 2017 @ 08:54:
[...]

ICMPv6 is een "vereiste" voor IPv6,

Ik was er vanuit gegaan dat de firewall ook ICMPv6 zou blokkeren.
Maar alle porten op deze servers staan wel default geblokkeerd in de firewall.
Dank!

[stormfly]

Ja een of twee subsets zijn een vereiste, de ICMP echo/reply zou je gewoon weg mogen filteren.

[Roetzen]

Ping response is inderdaad niet nodig voor correct functioneren van IPv6, maar de Ubee EVW321 biedt niet de mogelijkheid echo reply selectief weg te filteren. Je kunt de firewall aan of uit zetten en poorten vrijgeven. Verder kun je nog fragmented packets blokkeren, en IP flood detection en port scan detection aan zetten
Dat is het.

[stormfly]

Zo Ziggo blaast nog even een lading van 57K nieuwe IPv4 adressen de wereld in, @Roetzen @ANdrode

https://bgpmon.net/

code:

====================================================================
New prefix for AS9143 (Code: 60)
====================================================================
Detected new prefix:  80.112.32.0/19
Update time:          2017-08-31 08:34 (UTC)
Detected by #peers:   1
Announced by:         AS9143 (Ziggo)
Upstream AS:          AS6830 (Liberty Global Operations B.V.)
ASpath:               131477 38478 3491 6830 9143


====================================================================
New prefix for AS9143 (Code: 60)
====================================================================
Detected new prefix:  82.217.64.0/18
Update time:          2017-08-31 08:34 (UTC)
Detected by #peers:   1
Announced by:         AS9143 (Ziggo)
Upstream AS:          AS6830 (Liberty Global Operations B.V.)
ASpath:               131477 38478 3491 6830 9143


====================================================================
New prefix for AS9143 (Code: 60)
====================================================================
Detected new prefix:  80.112.0.0/19
Update time:          2017-08-31 08:34 (UTC)
Detected by #peers:   1
Announced by:         AS9143 (Ziggo)
Upstream AS:          AS6830 (Liberty Global Operations B.V.)
ASpath:               131477 38478 3491 6830 9143


====================================================================
New prefix for AS9143 (Code: 60)
====================================================================
Detected new prefix:  82.217.0.0/18
Update time:          2017-08-31 08:34 (UTC)
Detected by #peers:   1
Announced by:         AS9143 (Ziggo)
Upstream AS:          AS6830 (Liberty Global Operations B.V.)
ASpath:               131477 38478 3491 6830 9143

====================================================================
New prefix for AS9143 (Code: 60)
====================================================================
Detected new prefix:  80.115.144.0/20
Update time:          2017-08-31 08:33 (UTC)
Detected by #peers:   1
Announced by:         AS9143 (Ziggo)
Upstream AS:          AS3491 (Beyond The Network America, Inc.)
ASpath:               131477 38478 3491 9143


====================================================================
New prefix for AS9143 (Code: 60)
====================================================================
Detected new prefix:  80.115.128.0/20
Update time:          2017-08-31 08:33 (UTC)
Detected by #peers:   1
Announced by:         AS9143 (Ziggo)
Upstream AS:          AS3491 (Beyond The Network America, Inc.)
ASpath:               131477 38478 3491 9143

[stormfly]

Overigens zijn dit alle prefixen van Ziggo die nu live zijn, mooi he 4 regels IPv6 bevatten meer adressen dan alle IPv4 regels ;-)

code:

46.129.128.0/17
46.129.128.0/18
46.129.192.0/18
62.145.192.0/18 ZIGGO
80.112.0.0/17 ZIGGO
80.112.0.0/18 ZIGGO
80.112.64.0/18 ZIGGO
80.112.128.0/18 ZIGGO
80.112.128.0/19 ZIGGO
80.112.160.0/19 ZIGGO
80.114.0.0/17 ZIGGO
80.114.0.0/18 ZIGGO
80.114.64.0/18 ZIGGO
80.114.128.0/18 ZIGGO
80.114.128.0/19 ZIGGO
80.114.160.0/19 ZIGGO
80.114.192.0/18 ZIGGO
80.114.192.0/19 ZIGGO
80.114.224.0/19 ZIGGO
80.115.0.0/17 ZIGGO
80.115.0.0/18 ZIGGO
80.115.64.0/18 ZIGGO
80.115.128.0/18 ZIGGO
80.115.128.0/19 ZIGGO
80.115.160.0/19 ZIGGO
80.115.224.0/19 ZIGGO
80.115.224.0/20 ZIGGO
80.115.240.0/20 ZIGGO
80.242.224.0/19 ZIGGO
80.242.224.0/20 ZIGGO
80.242.240.0/20 ZIGGO
82.72.0.0/14 ZIGGO
82.72.0.0/15 ZIGGO
82.74.0.0/15 ZIGGO
82.101.192.0/18 ZIGGOMOBILE
82.101.192.0/19 ZIGGO
82.101.224.0/19 ZIGGO
82.217.0.0/16 ZIGGO
82.217.0.0/17 ZIGGO
82.217.128.0/17 ZIGGO
83.80.0.0/13 ZIGGO
83.80.0.0/14 ZIGGO
83.84.0.0/14 ZIGGO
84.24.0.0/13 ZIGGO
84.24.0.0/14 ZIGGO
84.28.0.0/14 ZIGGO
84.104.0.0/14 ZIGGO
84.104.0.0/15 ZIGGO
84.106.0.0/15 ZIGGO
85.147.0.0/16 ZIGGO
85.147.0.0/17 ZIGGO
85.147.128.0/17 ZIGGO
91.236.83.192/28
91.236.83.208/28
91.236.83.224/28
91.236.83.240/28
94.170.0.0/15 ZIGGO
94.170.0.0/16 ZIGGO
94.171.0.0/16 ZIGGO
94.208.0.0/13 ZIGGO
94.208.0.0/14 ZIGGO
94.212.0.0/14 ZIGGO
134.188.0.0/16 IPT_OCE
145.46.128.0/18 IPT_ESSENT
145.46.192.0/18 IPT_ESSENT
195.35.128.0/17 ZIGGO
195.35.128.0/18 ZIGGO
195.35.192.0/18 ZIGGO
195.85.128.0/18 ZIGGO
195.85.128.0/19 ZIGGO
195.85.160.0/19 ZIGGO
212.54.32.0/19 ZIGGO
212.54.32.0/20 ZIGGO
212.54.48.0/20 ZIGGO
212.120.64.0/18 ZIGGO
212.120.64.0/19 ZIGGO
212.120.96.0/19 ZIGGO
212.127.128.0/17 ZIGGO
212.127.128.0/18 ZIGGO
212.127.192.0/18 ZIGGO
212.178.64.0/18 ZIGGO
212.178.64.0/19 ZIGGO
212.178.96.0/19 ZIGGO
212.178.128.0/19 ZIGGO
212.178.128.0/20 ZIGGO
212.178.144.0/20 ZIGGO
212.178.192.0/19 ZIGGO
212.178.192.0/20 ZIGGO
212.178.208.0/20 ZIGGO
212.203.0.0/19 ZIGGO
212.203.0.0/20 ZIGGO
212.203.16.0/20 ZIGGO
212.204.128.0/18 ZIGGO
212.204.128.0/19 ZIGGO
212.204.160.0/19 ZIGGO
213.34.64.0/19 ZIGGO
213.34.64.0/20 ZIGGO
213.34.80.0/20 ZIGGO
213.34.96.0/19 ZIGGO
213.34.96.0/20 ZIGGO
213.34.112.0/20 ZIGGO
213.34.160.0/19 ZIGGO
213.34.160.0/20 ZIGGO
213.34.176.0/20 ZIGGO
213.51.0.0/16 ZIGGO
213.73.128.0/17 ZIGGO
213.73.128.0/18 ZIGGO
213.73.192.0/18 ZIGGO
213.124.0.0/17 ZIGGO
213.124.0.0/18 ZIGGO
213.124.64.0/18 ZIGGO
213.124.128.0/19 ZIGGO
213.124.128.0/20 ZIGGO
213.124.144.0/20 ZIGGO
213.125.0.0/16 ZIGGO
213.125.0.0/17 ZIGGO
213.125.128.0/17 ZIGGO
213.126.0.0/17 ZIGGO
213.126.0.0/18 ZIGGO
213.126.64.0/18 ZIGGO
213.132.160.0/19 ZIGGO
213.132.160.0/20 ZIGGO
213.132.176.0/20 ZIGGO
217.62.0.0/16 ZIGGO
217.62.0.0/17 ZIGGO
217.62.128.0/17 ZIGGO
217.63.0.0/18 ZIGGO
217.63.0.0/19 ZIGGO
217.63.32.0/19 ZIGGO
217.63.192.0/18 ZIGGO
217.63.192.0/19 ZIGGO
217.63.224.0/19 ZIGGO
217.100.0.0/16 ZIGGO
217.100.0.0/17 ZIGGO
217.100.128.0/17 ZIGGO
217.101.0.0/16 ZIGGO
217.101.0.0/17 ZIGGO
217.101.128.0/17 ZIGGO
217.102.0.0/17
217.102.0.0/18
217.102.64.0/18
217.102.128.0/18 ZIGGO
217.102.128.0/19 ZIGGO
217.102.160.0/19 ZIGGO
217.102.192.0/19 ZIGGO
217.102.192.0/20 ZIGGO
217.102.208.0/20 ZIGGO
217.102.224.0/21 ZIGGO-B2B
217.104.0.0/17 ZIGGO
217.104.0.0/18 ZIGGO
217.104.64.0/18 ZIGGO
217.105.64.0/18 ZIGGO
217.105.64.0/19 ZIGGO
217.105.96.0/19 ZIGGO
217.105.128.0/18 ZIGGO
217.105.128.0/19 ZIGGO
217.105.160.0/19 ZIGGO
217.105.192.0/19 ZIGGO
217.105.192.0/20 ZIGGO
217.105.208.0/20 ZIGGO
217.120.0.0/14 ZIGGO
217.120.0.0/15 ZIGGO
217.122.0.0/15 ZIGGO
2001:1c00::/23 ZIGGO
2001:1c00::/24 ZIGGO
2001:1d00::/24 ZIGGO
2001:41f0::/32 ZIGGO
2001:41f0:8000::/33 ZIGGO
2001:41f0::/33 ZIGGO
2001:b88::/33 ZIGGO

[Zr40]

stormfly schreef op donderdag 31 augustus 2017 @ 11:19:
Overigens zijn dit alle prefixen van Ziggo die nu live zijn, mooi he 4 regels IPv6 bevatten meer adressen dan alle IPv4 regels ;-)

Dat is niet moeilijk, één IPv6 /32 bevat al evenveel /64s als dat er IPv4 adressen bestaan... en ik zie daar een IPv6 /23 tussen staan

[ANdrode]

En nog even CC hier: De ziggogo.tv streams gaan via IPv6. De stream die ik keek verbruikte ongeveer 450 kbit/s vanaf 2001:730:3400:8000::14/AS6830/fUPC.

[stormfly]

Nog een leuke site

https://bgpview.io/asn/6830#prefixes-v4
11,301,376 IPv4 adressen voor UPC wereldwijd

https://bgpview.io/asn/9143#prefixes-v4
3,762,176 IPv4 adressen voor Ziggo wereldwijd

Met 3 miljoen klanten, die ook een publiek adres op hun TV box krijgen en op hun modem....lijkt dit niet te kloppen.

[stormfly]

En nog +/- 150K stuks ;-) iemand heeft even een bezem door de reserve prefixen gehaald

Wat leuk is om te zien, deze komen bij UPC Polen vandaan ze zijn dus echt aan het uitwisselen.

https://apps.db.ripe.net/....128.0%2F17#resultsAnchor

code:

====================================================================
New prefix for AS9143 (Code: 60)
====================================================================
Detected new prefix:  83.81.0.0/17
Update time:          2017-08-31 09:23 (UTC)
Detected by #peers:   1
Announced by:         AS9143 (Ziggo)
Upstream AS:          AS3491 (Beyond The Network America, Inc.)
ASpath:               131477 38478 3491 9143


====================================================================
New prefix for AS6830 (Code: 60)
====================================================================
Detected new prefix:  89.65.128.0/17
Update time:          2017-08-31 09:23 (UTC)
Detected by #peers:   1
Announced by:         AS6830 (Liberty Global Operations B.V.)
Upstream AS:          AS3491 (Beyond The Network America, Inc.)
ASpath:               131477 38478 3491 6830


====================================================================
New prefix for AS6830 (Code: 60)
====================================================================
Detected new prefix:  89.65.0.0/17
Update time:          2017-08-31 09:23 (UTC)
Detected by #peers:   1
Announced by:         AS6830 (Liberty Global Operations B.V.)
Upstream AS:          AS3491 (Beyond The Network America, Inc.)
ASpath:               131477 38478 3491 6830


====================================================================
New prefix for AS9143 (Code: 60)
====================================================================
Detected new prefix:  83.81.128.0/17
Update time:          2017-08-31 09:23 (UTC)
Detected by #peers:   1
Announced by:         AS9143 (Ziggo)
Upstream AS:          AS3491 (Beyond The Network America, Inc.)
ASpath:               131477 38478 3491 9143

====================================================================
New prefix for AS6830 (Code: 60)
====================================================================
Detected new prefix:  188.142.176.0/21
Update time:          2017-08-31 09:29 (UTC)
Detected by #peers:   1
Announced by:         AS6830 (Liberty Global Operations B.V.)
Upstream AS:          AS3491 (Beyond The Network America, Inc.)
ASpath:               131477 38478 3491 6830


====================================================================
New prefix for AS6830 (Code: 60)
====================================================================
Detected new prefix:  188.142.184.0/21
Update time:          2017-08-31 09:29 (UTC)
Detected by #peers:   1
Announced by:         AS6830 (Liberty Global Operations B.V.)
Upstream AS:          AS3491 (Beyond The Network America, Inc.)
ASpath:               131477 38478 3491 6830

[ Voor 22% gewijzigd door stormfly op 31-08-2017 11:48 ]

[ANdrode]

stormfly schreef op donderdag 31 augustus 2017 @ 11:04:
Zo Ziggo blaast nog even een lading van 57K nieuwe IPv4 adressen de wereld in, @Roetzen @ANdrode

https://bgpmon.net/

Leuke data!

En dan voor de vorm ook even de allocaties van fUPC/fZiggo uit de RIPE allocation list:

code:

nl.benelux
    Ziggo B.V.

    19981119    212.127.128.0/17    ALLOCATED PA
    19990128    212.120.64.0/18 ALLOCATED PA
    19990301    212.54.32.0/19  ALLOCATED PA
    19990629    212.204.128.0/18    ALLOCATED PA
    19990916    213.34.96.0/19  ALLOCATED PA
    20000125    213.51.0.0/16   ALLOCATED PA
    20000828    213.73.128.0/17 ALLOCATED PA
    20001123    217.62.0.0/16   ALLOCATED PA
    20001123    217.63.0.0/18   ALLOCATED PA
    20001123    217.63.192.0/18 ALLOCATED PA
    20001205    217.101.0.0/16  ALLOCATED PA
    20001205    217.102.128.0/18    ALLOCATED PA
    20001205    217.102.192.0/19    ALLOCATED PA
    20001205    217.104.0.0/17  ALLOCATED PA
    20001205    217.105.64.0/18 ALLOCATED PA
    20001205    217.105.128.0/18    ALLOCATED PA
    20001219    217.120.0.0/14  ALLOCATED PA
    20010725    80.112.0.0/17   ALLOCATED PA
    20010725    80.114.0.0/17   ALLOCATED PA
    20010725    80.114.192.0/18 ALLOCATED PA
    20010725    80.115.0.0/17   ALLOCATED PA
    20010725    80.115.128.0/18 ALLOCATED PA
    20021125    62.145.192.0/18 ALLOCATED PA
    20030704    82.72.0.0/14    ALLOCATED PA
    20031027    82.217.0.0/16   ALLOCATED PA
    20031128    83.80.0.0/13    ALLOCATED PA
    20031223    82.101.192.0/18 ALLOCATED PA
    20040426    84.104.0.0/14   ALLOCATED PA
    20040701    84.24.0.0/13    ALLOCATED PA
    20041006    85.147.0.0/16   ALLOCATED PA
    20080722    94.208.0.0/13   ALLOCATED PA
    20151209    185.130.168.0/22    ALLOCATED PA
    20030317    2001:b88::/32
    20040510    2001:1c00::/23

...

nl.chello
    Ziggo Services B.V.

    19970730    62.108.0.0/19   ALLOCATED PA
    19971013    24.132.0.0/17   ALLOCATED PA
    19990203    212.83.64.0/19  ALLOCATED PA
    19990210    212.142.0.0/18  ALLOCATED PA
    19990526    212.187.0.0/17  ALLOCATED PA
    19990623    212.178.32.0/19 ALLOCATED PA
    19990916    213.34.0.0/19   ALLOCATED PA
    19990916    213.124.160.0/19    ALLOCATED PA
    19990916    213.124.192.0/18    ALLOCATED PA
    19990916    213.126.128.0/17    ALLOCATED PA
    19990916    213.127.0.0/16  ALLOCATED PA
    19991108    213.46.0.0/16   ALLOCATED PA
    20000117    24.132.128.0/17 ALLOCATED PA
    20000410    213.160.192.0/19    ALLOCATED PA
    20000509    213.93.0.0/16   ALLOCATED PA
    20001010    62.194.0.0/15   ALLOCATED PA
    20001123    217.63.128.0/18 ALLOCATED PA
    20001127    62.163.0.0/16   ALLOCATED PA
    20001205    217.102.0.0/17  ALLOCATED PA
    20001205    217.103.0.0/16  ALLOCATED PA
    20001205    217.104.128.0/17    ALLOCATED PA
    20001205    217.105.0.0/18  ALLOCATED PA
    20001205    217.105.224.0/19    ALLOCATED PA
    20010516    80.56.0.0/15    ALLOCATED PA
    20010725    80.113.0.0/16   ALLOCATED PA
    20020906    213.160.248.0/21    ALLOCATED PA
    20030603    81.175.64.0/18  ALLOCATED PA
    20060220    89.98.0.0/15    ALLOCATED PA
    20070126    77.248.0.0/14   ALLOCATED PA
    20071023    92.108.0.0/14   ALLOCATED PA
    20090112    95.96.0.0/15    ALLOCATED PA
    20091219    178.84.0.0/15   ALLOCATED PA
    20101004    46.129.0.0/16   ALLOCATED PA
    20110217    31.151.0.0/16   ALLOCATED PA
    20160208    185.137.200.0/22    ALLOCATED PA
    20110926    2a02:a200::/27

...

nl.chellomedia
    Digital Media Centre B.V.

    20140903    185.68.240.0/22 ALLOCATED PA
    20140903    2a03:2da0::/32

...

nl.workbenelux
    Ziggo B.V.

    19990326    195.85.128.0/19 ALLOCATED PA
    19990623    212.178.64.0/18 ALLOCATED PA
    19990623    212.178.128.0/19    ALLOCATED PA
    19990623    212.178.192.0/19    ALLOCATED PA
    19990916    213.34.64.0/19  ALLOCATED PA
    19990916    213.34.160.0/19 ALLOCATED PA
    19990916    213.124.0.0/18  ALLOCATED PA
    19990916    213.124.64.0/18 ALLOCATED PA
    19990916    213.124.128.0/19    ALLOCATED PA
    19990916    213.125.0.0/17  ALLOCATED PA
    19990916    213.125.128.0/18    ALLOCATED PA
    19990916    213.125.192.0/18    ALLOCATED PA
    19990916    213.126.0.0/18  ALLOCATED PA
    19990916    213.126.64.0/19 ALLOCATED PA
    19990916    213.126.96.0/19 ALLOCATED PA
    20000330    195.35.128.0/18 ALLOCATED PA
    20000330    195.85.160.0/19 ALLOCATED PA
    20000808    212.203.0.0/19  ALLOCATED PA
    20001205    217.100.0.0/17  ALLOCATED PA
    20001205    217.100.128.0/18    ALLOCATED PA
    20001205    217.100.192.0/18    ALLOCATED PA
    20001205    217.102.224.0/20    ALLOCATED PA
    20001205    217.105.192.0/19    ALLOCATED PA
    20010725    80.112.128.0/18 ALLOCATED PA
    20010725    80.114.128.0/18 ALLOCATED PA
    20010725    80.115.224.0/19 ALLOCATED PA
    20010925    195.35.192.0/18 ALLOCATED PA
    20011029    80.242.224.0/20 ALLOCATED PA
    20030128    213.132.160.0/19    ALLOCATED PA
    20030514    80.242.240.0/20 ALLOCATED PA
    20151209    185.130.172.0/22    ALLOCATED PA
    20041203    2001:41f0::/32

...of zoals @stormfly net deed via een kant en klaar tooltje

[ Voor 31% gewijzigd door ANdrode op 31-08-2017 11:52 ]

[stormfly]

Waarom ik dit hier post, omdat IPv6 niet gaat vliegen in Nederland als IPv4 aangevuld blijft worden. Voor mij heeft het 1op1 relatie met elkaar, ook gezien de vele gevoerde discussies in het verleden.

Ik zou wel willen weten wat de geregistreerde IP space is tov de geadverteerde IP space...dat is voor AS9143 misschien nog wel te scripten door jou @ANdrode ? Maar voor AS6830 heb je alle landen, en zoals je nu ziet gaan ze internationaal prefixen uitwisselen dat is niet meer van elkaar af te trekken in een script schat ik in.

[ANdrode]

stormfly schreef op donderdag 31 augustus 2017 @ 11:46:
Waarom ik dit hier post, omdat IPv6 niet gaat vliegen in Nederland als IPv4 aangevuld blijft worden. Voor mij heeft het 1op1 relatie met elkaar, ook gezien de vele gevoerde discussies in het verleden.

Ik zou wel willen weten wat de geregistreerde IP space is tov de geadverteerde IP space...dat is voor AS9143 misschien nog wel te scripten door jou @ANdrode ? Maar voor AS6830 heb je alle landen, en zoals je nu ziet gaan ze internationaal prefixen uitwisselen dat is niet meer van elkaar af te trekken in een script schat ik in.

Ik heb net inderdaad de allocaties bij elkaar opgeteld. Ik kom tot 5515264 ge-alloceerde adressen in Nederland. Puur op basis van de prefixes die ik in die RIPE lijst zie.

En de volgende oneliner:

code:

cat alloclist.txt  | grep ALLOCATED | sed -e "s/\t/ /g" | cut -d " " -f6 | cut -d "/" -f2 | sed -e "s/^/(2**(32-/g" | sed -e "s/$/\))/g" | tr '\n' '+' | sed -e "s/+$//" | sed -e "s/\(.*\)/print(\1)/g" | python

offtopic:
Ja kan met minder sed aanroepen, maar wat werkt werkt :-P

stormfly schreef op donderdag 31 augustus 2017 @ 11:37:
Nog een leuke site

https://bgpview.io/asn/6830#prefixes-v4
11,301,376 IPv4 adressen voor UPC wereldwijd

https://bgpview.io/asn/9143#prefixes-v4
3,762,176 IPv4 adressen voor Ziggo wereldwijd

Met 3 miljoen klanten, die ook een publiek adres op hun TV box krijgen en op hun modem....lijkt dit niet te kloppen.

3.471.360 in de RIPE allocaties die ik heb ingedeeld als fZiggo (nl.benelux, nl.workbenelux)

[ Voor 21% gewijzigd door ANdrode op 31-08-2017 12:24 ]

[Roetzen]

stormfly schreef op donderdag 31 augustus 2017 @ 11:04:
Zo Ziggo blaast nog even een lading van 57K nieuwe IPv4 adressen de wereld in, @Roetzen @ANdrode

De laatste restjes worden van de plank geschraapt.

Waarom zeg ik dat? Ik zie de versnippering als een aanwijzing dat het nu echt bijna op is. Die twee /18s waren kennelijk de twee grootste blokken die er nog waren. Want als ze nog een /16 of een /17 hadden, dan was dat wel in de strijd geworpen. En die twee /19s zijn kennelijk ook de laatsten, anders waren ze nog niet met /20 begonnen. Dus er ligt vermoedelijk niks groter dan /20 meer op de plank.

Het is en aanwijzing, geen hard bewijs.

stormfly schreef op donderdag 31 augustus 2017 @ 11:46:
Waarom ik dit hier post, omdat IPv6 niet gaat vliegen in Nederland als IPv4 aangevuld blijft worden.

Maar waarom denk je dat IPv4 aangevuld blijft worden? Dat men nu internationaal met de laatste restjes aan het schuiven is, zie ik juist als een aanwijzing dat het nu echt bijna op is.

[ Voor 21% gewijzigd door Roetzen op 31-08-2017 12:57 ]

[stormfly]

Roetzen schreef op donderdag 31 augustus 2017 @ 12:26:
[...]

De laatste restjes worden van de plank geschraapt.

Waarom zeg ik dat? Ik zie de versnippering als een aanwijzing dat het nu echt bijna op is. Die twee /18s waren kennelijk de twee grootste blokken die er nog waren. Want als ze nog een /16 of een /17 hadden, dan was dat wel in de strijd geworpen. En die twee /19s zijn kennelijk ook de laatsten, anders waren ze nog niet met /20 begonnen. Dus er ligt vermoedelijk niks groter dan /20 meer op de plank.

Het is en aanwijzing, geen hard bewijs.

Kleinere prefixen worden gebruikt om Traffic Engineering toe te passen, dan ben je flexibeler in hoe je extern bekend bent. Doen ze ook al met de huidige prefixen, ik zit thuis in een /13 die ook als /14 op de wereld leeft. Het lijkt dat een groot deel al weg te scharen is onder een grotere prefix, voor ons niet na te gaan of ze ooit gebruikt zijn.

Roetzen schreef op donderdag 31 augustus 2017 @ 12:26:
Maar waarom denk je dat IPv4 aangevuld blijft worden? Dat men nu internationaal met de laatste restjes aan het schuiven is, zie ik juist als een aanwijzing dat het nu echt bijna op is.

Misschien heb je gelijk, misschien niet ;-) daar komen we niet achter. Wat opvalt is dat 6830 ook flink gestart is met adverteren. Ik heb deze vandaag pas toegevoegd dus ik weet niet wat ze normaal doen...maar ook daar zijn prefixes verschenen die onder grotere prefixes zijn te scharen.

[ Voor 36% gewijzigd door stormfly op 31-08-2017 13:48 ]

[Roetzen]

stormfly schreef op donderdag 31 augustus 2017 @ 13:02:

Misschien heb je gelijk, misschien niet ;-)

Tja, één van de twee zal het wel zijn.

daar komen we niet achter

Als het een keer echt op is, kan dat niet eeuwig geheim blijven. Maar misschien weten we het eerder doordat iemand met inside informatie wat loslaat....

[stormfly]

Ik heb nog een gekeken maar het gros, zo niet alles, lijken toch wel more specific routes te zijn. Dus niet zo zeer nieuwe IP space. Maar kleinere blokken die door bgpmon als nieuw worden aangemerkt omdat ze nooit eerder gezien zijn.

[Roetzen]

Dus toch bijeenschrapen en herverdelen van de restjes?

[ANdrode]

stormfly schreef op donderdag 31 augustus 2017 @ 18:48:
Ik heb nog een gekeken maar het gros, zo niet alles, lijken toch wel more specific routes te zijn. Dus niet zo zeer nieuwe IP space. Maar kleinere blokken die door bgpmon als nieuw worden aangemerkt omdat ze nooit eerder gezien zijn.

Wat trouwens niet betekende dat de adressen ook actief gebruikt werden door klanten.

Ik heb zelf het gevoel dat de ranges die actief gebruikt worden al met kleinere prefixes ge-announced werden.
Zo kan je ook in je eigen netwerk met BGP routeren?

[Roetzen]

nos.nl is nu al wel geruime tijd via IPv6 bereikbaar, maar dat is dan alleen de hoofdingang, Een klik op het groene 6je van IPvFox geeft dit:


https://nos.nl 2a02:458:101:28:100:28:0:af
https://sb.scorecardresearch.com 23.206.93.157
https://static.chartbeat.com 151.101.36.249
https://nos.dmdelivery.com 91.197.72.25
https://cookiesv2.publiekeomroep.nl 2a02:458:101:28:100:29:0:88
https://creatives.ancoraplatform.com 54.230.128.30
https://divolte.nos.nl 145.58.84.16
https://adserving.ancoraplatform.com 52.57.220.42
https://ping.chartbeat.ne t23.21.240.128
https://ib.adnxs.com 37.252.172.27
https://px.moatads.com 23.206.80.124
https://optimized-by.rubiconproject.com 213.19.162.41
https://beacon-eu-ams3.rubiconproject.com 213.19.162.37
https://gce-be.bidswitch.net 35.189.227.45
https://ads.creative-serving.com 130.211.51.215
https://creative-a.akamaihd.net 88.221.254.168
https://m.exactag.com 85.14.248.91
https://eu-sync.bidswitch.net 35.189.227.45
https://ws1.rqtrk.eu 185.19.219.27
https://secure.adnxs.com 185.33.223.197
https://ws2.rqtrk.eu 185.19.219.27
https://x.bidswitch.net 130.211.65.163
https://px.powerlinks.com 52.212.92.97
https://tags.bluekai.com 23.206.93.162
https://c.betrad.com 23.206.96.254
https://l.betrad.com 34.200.50.12
https://ping.chartbeat.net 107.20.191.152

Toch nog voornamelijk IPv4...

[Bigs]

Als je IPv6-only surft krijg je dus ineens wel een stuk minder advertenties en trackers op nos.nl..

[darkrain]

Roetzen schreef op woensdag 6 september 2017 @ 12:47:
nos.nl is nu al wel geruime tijd via IPv6 bereikbaar, maar dat is dan alleen de hoofdingang, Een klik op het groene 6je van IPvFox geeft dit:


https://nos.nl 2a02:458:101:28:100:28:0:af
https://sb.scorecardresearch.com 23.206.93.157
https://static.chartbeat.com 151.101.36.249
https://nos.dmdelivery.com 91.197.72.25
https://cookiesv2.publiekeomroep.nl 2a02:458:101:28:100:29:0:88
https://creatives.ancoraplatform.com 54.230.128.30
https://divolte.nos.nl 145.58.84.16
https://adserving.ancoraplatform.com 52.57.220.42
https://ping.chartbeat.ne t23.21.240.128
https://ib.adnxs.com 37.252.172.27
https://px.moatads.com 23.206.80.124
https://optimized-by.rubiconproject.com 213.19.162.41
https://beacon-eu-ams3.rubiconproject.com 213.19.162.37
https://gce-be.bidswitch.net 35.189.227.45
https://ads.creative-serving.com 130.211.51.215
https://creative-a.akamaihd.net 88.221.254.168
https://m.exactag.com 85.14.248.91
https://eu-sync.bidswitch.net 35.189.227.45
https://ws1.rqtrk.eu 185.19.219.27
https://secure.adnxs.com 185.33.223.197
https://ws2.rqtrk.eu 185.19.219.27
https://x.bidswitch.net 130.211.65.163
https://px.powerlinks.com 52.212.92.97
https://tags.bluekai.com 23.206.93.162
https://c.betrad.com 23.206.96.254
https://l.betrad.com 34.200.50.12
https://ping.chartbeat.net 107.20.191.152

Toch nog voornamelijk IPv4...

Tsja op een enkele na kan NOS daar niet direct iets aan doen zo te zien...

[Roetzen]

darkrain schreef op woensdag 6 september 2017 @ 12:54:

Tsja op een enkele na kan NOS daar niet direct iets aan doen zo te zien...

Het is ook niet direct een verwijt aan NOS, het is meer een constatering dat IPv6 nog niet zo ver is gevorderd als het op het eerste gezicht lijkt. Veel onder de oppervlakte is kennelijk nog IPv4 only.

[darkrain]

Roetzen schreef op woensdag 6 september 2017 @ 12:59:
[...]

Het is ook niet direct een verwijt aan NOS, het is meer een constatering dat IPv6 nog niet zo ver is gevorderd als het op het eerste gezicht lijkt. Veel onder de oppervlakte is kennelijk nog IPv4 only.

Ah ja, die constatering is zeker juist. Dat zal ook nog wel even zo blijven, hoe jammer dat ook is...

[hkoster1]

Ik draai een Debian VM die alleen IPv6 doet, en als ik dan met Firefox wat aan het surfen ga is het resultaat nog niet bemoedigend: NOS, Tweakers en ZiggoGebruikers zijn OK; Macrumors en 9to5Mac niet, om maar eens een paar van mijn favoriete sites te noemen.

[ANdrode]

hkoster1 schreef op woensdag 6 september 2017 @ 15:03:
Ik draai een Debian VM die alleen IPv6 doet, en als ik dan met Firefox wat aan het surfen ga is het resultaat nog niet bemoedigend: NOS, Tweakers en ZiggoGebruikers zijn OK; Macrumors en 9to5Mac niet, om maar eens een paar van mijn favoriete sites te noemen.

Als je het zelf inricht: Ik heb op events een testnetwerk gezien dat NAT64 gebruikte. Dit werkte [bij een ondersteund os] goed.

Voor een netwerk waar je intern IPv6 only wil zijn maar wel externe IPv4 connectiviteit hebt is dit een mooie oplossing.

Zelfs bij DS-Lite zou ik dit willen gebruiken (en dan translaten op mijn eigen router). Mijn provider hoeft niet te weten vanaf welk verkeer het traffic komt. Privacy extensions helpen daar gedeeltelijk tegen,
maar devices/personen tracken blijft dan te doen voor de ISP.

DHCPv6 maakt voor providers "toestemming om het verkeer te gebruiken voor analyses" veel waardevoller. Wat dat betreft ben ik ook blij met XS4ALL boven {KPN, XS4ALL} #fanboy

[ Voor 9% gewijzigd door ANdrode op 06-09-2017 15:11 ]

[Dreamvoid]

Dit heeft wel als nadeel dat providers enkel de botte bijl methode kunnen gebruiken bij constatering van botnet verkeer bij een klant - als ze het verkeer kunnen herleiden tot 1 device kunnen ze die gericht offline halen.

[hkoster1]

@ANdrode Mmm... NAT64 met DS-Lite zie ik niet zo, want dan is er immers geen IPv4 externe connectiviteit. Als het niet de ISP is met CG-NAT, dan moet het toch een andere server zijn "ergens" op het IPv6-web die naar IPv4 vertaalt? Die moet je dan meer vertrouwen dan de eigen ISP.

[ANdrode]

Dreamvoid schreef op woensdag 6 september 2017 @ 15:35:
Dit heeft wel als nadeel dat providers enkel de botte bijl methode kunnen gebruiken bij constatering van botnet verkeer bij een klant - als ze het verkeer kunnen herleiden tot 1 device kunnen ze die gericht offline halen.

Dat is vooral een hypothetisch nadeel. Ten eerste werkt deze mitigatie al niet meer als je privacy extensions gebruikt. Het is dus een beveiligingsmaatregel die in een adversarial scenario geen waarde bied. Ten tweede verwacht ik domweg niet dat providers op dit niveau kijken.

De praktijk lijkt "aansluiting uit en misschien een mailtje" te zijn.

hkoster1 schreef op woensdag 6 september 2017 @ 15:37:
@ANdrode Mmm... NAT64 met DS-Lite zie ik niet zo, want dan is er immers geen IPv4 externe connectiviteit. Als het niet de ISP is met CG-NAT, dan moet het toch een andere server zijn "ergens" op het IPv6-web die naar IPv4 vertaalt? Die moet je dan meer vertrouwen dan de eigen ISP.

Vanaf de eigen router zou je DS-Lite kunnen gebruiken mits de details beschikbaar zijn.

Ik maakte trouwens een denkfout: Als je de identiteit van apparaten in je eigen netwerk wilt maskeren dan zijn privacy extensions de enige optie. Dan breng je de informatie terug tot alleen de prefix. Hetzelfde effect als wanneer je IPv4 NAT doet (ook één effectief extern adres).

NAT64 via een gateway helpt niet, je zou de vertaling moeten doen voordat het verkeer het eigen netwerk verlaat. En zelfs dan verwacht ik dat je met een model de pseudoniemen kan onderscheiden.

Wat ik liever niet heb is dat mijn provider makkelijk, zonder DPI, kan zien wat voor apparaten ik bezig en op basis daarvan beslissingen kan nemen. Om dat te gebruiken voor aanbiedingen, voorspellingen te doen over inkomen, etc.

Dus DHCPv6 vind ik matig. IPv6 zonder privacy extensions lekt misschien nog meer. Bij IPv6 met privacy extensions (+ random mac adres) leert een tegenstander alleen iets over het gedrag van een hele prefix.

[Dreamvoid]

De praktijk lijkt "aansluiting uit en misschien een mailtje" te zijn.

Nee de praktijk is zeker niet dat de aansluiting eruit gaat, dat gebeurt in de praktijk bijna nooit - dit kost ze nl in de meeste gevallen een lucratieve klant. Als Ziggo 1 of andere bejaarde zou afsluiten vanwege botnet verkeer, dan gaat die niet zijn PC ontsmetten, maar met een KPN abonnement gewoon verder.

[hkoster1]

Vreemd ConnectBox-gedrag (DS-Lite) met een IPv6-bridged Debian VMware VM op mijn iMac.

Wanneer ik inlog op de ConnectBox dan is er geen melding van de VM onder de aangesloten apparaten, niet onder de ikonen en ook niet de gedetailleerde lijst van aangesloten apparaten. Het IPv6-adres van de iMac in die lijst is echter wel veranderd naar dat van de VM. De iMac krijgt het eigen IPv6-adres terug in die lijst als de VM wordt uitgezet.

Dit speelt alleen met betrekking tot de weergave van de aangesloten apparaten, de iMac en de VM hebben wel de correcte IPv6-adressen. Er is geen probleem met het IPv4-adres (192.168.178.xxx/24) van de iMac in de lijst.

Geen probleem, alles werkt zoals het zou moeten, alleen een slordigheidje van de Compal of Ziggo devs...

[Raven]

Het viel mij op dat http://ipv6-test.com/ een lagere score geeft dan gebruikelijk:

DNS4 + IP6 Reachable
DNS6 + IP4 Unreachable
DNS6 + IP6 Unreachable

Google gaf aan dat er sinds W10's AU update een probleem was (zou sinds maart gefixed zijn) met de DHCPv6 client, zie bijv. https://social.technet.mi...orum=win10itpronetworking , MSDN: Windows 10 Anniversary Update breaks DHCPv6 client , https://forums.he.net/index.php?topic=3606.0 , https://lists.gt.net/nsp/ipv6/60142 en https://community.ubnt.co...10-computers/td-p/1847052

Helaas lijkt mijn uptodate W10 LTSB N 1607 (14393.1715) install dat probleem nog steeds te hebben. Iemand enig idee of dat probleem alleen voor Home/Pro gefixed is?

[Zr40]

De "DNS6" tests gaan over de IPv6 connectiviteit van je DNS resolver. Niet over je Windows machine.

Dat resultaat zegt alleen dat de door jou gebruikte DNS resolver zelf alleen IPv4 connectiviteit heeft en geen lookups kan doen voor domeinen waarvan de DNS server alleen via IPv6 bereikbaar is.

Ik raad altijd aan om http://test-ipv6.com/ te gebruiken. Die geeft wat gedetailleerdere informatie en je kan ook de testresultaten delen bij de 'For the Help Desk' tab.

[ Voor 21% gewijzigd door Zr40 op 16-09-2017 23:15 ]

[Raven]

Zr40 schreef op zaterdag 16 september 2017 @ 22:55:
De "DNS6" tests gaan over de IPv6 connectiviteit van je DNS resolver. Niet over je Windows machine.

Dat resultaat zegt alleen dat de door jou gebruikte DNS resolver zelf alleen IPv4 connectiviteit heeft en geen lookups kan doen voor domeinen waarvan de DNS server alleen via IPv6 bereikbaar is.

Maar de bug die ik noemde is DNS gerelateerd, dat er geen IPv6 DNS servers worden opgepikt door Windows.

Zr40 schreef op zaterdag 16 september 2017 @ 22:55:
Ik raad altijd aan om http://test-ipv6.com/ te gebruiken. Die geeft wat gedetailleerdere informatie en je kan ook de testresultaten delen bij de 'For the Help Desk' tab.

Test met een IPv4 DNS record
goed (0.046s) gebruik makend van ipv4
Test met een IPv6 DNS record
goed (0.049s) gebruik makend van ipv6
Test met een Dual Stack DNS record
goed (0.084s) gebruik makend van ipv6
Test met een Dual Stack DNS en grote pakketten
goed (0.062s) gebruik makend van ipv6
Test IPv4 zonder DNS
goed (0.036s) gebruik makend van ipv4
Test IPv6 zonder DNS
goed (0.079s) gebruik makend van ipv6
Test IPv6 met grote pakketten
goed (0.449s) gebruik makend van ipv6
Test of uw ISP's DNS server IPv6 gebruikt
slecht (0.031s)
Vind IPv4 Service Provider
goed (0.474s) gebruik makend van ipv4 ASN 25596
Vind IPv6 Service Provider
goed (0.232s) gebruik makend van ipv6 ASN 6939

[Zr40]

Raven schreef op zondag 17 september 2017 @ 10:12:
[...]
Maar de bug die ik noemde is DNS gerelateerd, dat er geen IPv6 DNS servers worden opgepikt door Windows.

Ja, maar dat is niet hetgeen dat getest wordt. Er wordt getest of de gebruikte DNS resolver IPv6 connectiviteit heeft, niet of jij via IPv6 verbinding maakt naar die DNS resolver. (Dat laatste kan ook niet getest worden via een website.)

Als je bijvoorbeeld als DNS resolver alleen 8.8.8.8 gebruikt, dus via IPv4, dan zul je zien dat de test zal slagen. Want deze DNS resolver heeft wel IPv6 connectiviteit en kan dus wel verbinden met IPv6-only DNS servers.

[ Voor 24% gewijzigd door Zr40 op 17-09-2017 11:00 ]

[Ivar1984]

Ziggo start weer een IPv6 test via hun community, dit keer op de Technicolor TC7210:

quote: Ziggo Community

We willen graag met een besloten groep IPv6 in combinatie met de laatste firmware voor het Technicolor TC7210 modem testen. Bij deze test zetten we IPv6 aan. Wanneer je je hebt aangemeld door middel van een reactie op dit topic, geven wij jou toegang tot het besloten forum en zetten we IPv6 voor je aan. In de besloten groep vind je alle informatie over de test en wat er van je verwacht wordt.

Aanmelden kan via een reactie in dit topic op de Ziggo Community

[lonaowna]

Ivar1984 schreef op maandag 18 september 2017 @ 21:15:
Ziggo start weer een IPv6 test via hun community, dit keer op de Technicolor TC7210

Het lijkt erop dat de vorige (met de Cisco EPC3928) is afgelopen (de Ziggo Community topic is namelijk weg). Weet iemand hoe die is afgelopen?

[darkrain]

lonaowna schreef op dinsdag 19 september 2017 @ 18:19:
[...]


Het lijkt erop dat de vorige (met de Cisco EPC3928) is afgelopen (de Ziggo Community topic is namelijk weg). Weet iemand hoe die is afgelopen?

Ja dat weet ik wel...

De test is niet afgelopen, er zijn alleen een paar issues gevonden die men nu aan het oplossen is samen met de fabrikant. Ik ga er zelf nog steeds vanuit dat we, als die issues zijn opgelost, verder gaan met testen.

[Zsub]

Ik ben eigenlijk wel benieuwd naar die TC710 test, maar het is jammer dat ik m'n modem uit bridge zou moeten laten halen.