Het grote IPv6 topic

[tlpeter]

ANdrode schreef op vrijdag 19 augustus 2016 @ 09:58:
[...]


Ik heb gehoord dat in ieder geval twee ISP's in Nederland de meldingen van security issues in hun modems actief oppakken en samen met hun leverancier oplossen. Dat *moet* wel gedekt zijn. Anders ben je imo een cowboy, geen professionele organisatie.

Ik weet van Xs4all dat er een tijd terug een bug was in de https teogang vanaf extern naar het modem toe.
Dit werd door Xs4all zelf uitgezet en een mail met uitleg waarom.
Paar weken later was het modem geupdate door Xs4all en weer een mail er achter aan dat het opgelost was.
Ik hou er niet zo van dat providers zomaar updaten en instellingen wijzigen maar in dit geval vind ik het tp dat het gedaan is.

[Belgar]

eymey schreef op vrijdag 19 augustus 2016 @ 09:09:
[...]
Dat is jammer genoeg de realiteit Bedrijven die écht technology-driven werken zijn een utopie, helemaal zodra er in ze geïnvesteerd wordt door winstbeluste investeerders of als ze op de beurs zijn.

Toch gebeurt het met onderdelen wel, als de druk maar groot genoeg is en je kunt investeren in talent. Voorbeelden van bijvoorbeeld Google met het maken van hun eigen switches, storage protocols, drivers, no-sql database ontwikkeling, etc. Een aantal daarvan hebben ook vervolgens weer een grote invloed op de rest van IT.

Ik zie het niet zo negatief. Wat ik wel denk is dat je vaak een visionair en advocaat in je organisatie moet hebben die zoiets wil oppakken en uitdragen. Als je het wil en het talent hebt, heb je ook niet zoveel nodig (bovenstaande Google dingen begonnen allemaal met een team van minder dan 20 mensen).

Het feit dat xs4all wel IPv6 heeft en veel andere providers niet, is waarschijnlijk de instelling en enthousiasme van de juiste 4-7 mensen binnen de organisatie.

[Olaf van der Spek]

Belgar schreef op vrijdag 19 augustus 2016 @ 12:21:
Toch gebeurt het met onderdelen wel, als de druk maar groot genoeg is en je kunt investeren in talent. Voorbeelden van bijvoorbeeld Google met het maken van hun eigen switches, storage protocols, drivers, no-sql database ontwikkeling, etc. Een aantal daarvan hebben ook vervolgens weer een grote invloed op de rest van IT.

Dat is (ook) omdat het uiteindelijk goedkoper is..
Google etc zijn natuurlijk ook megabedrijven, niet te vergelijken met veel kleinere 'normale' bedrijven.

[ANdrode]

Olaf van der Spek schreef op vrijdag 19 augustus 2016 @ 12:29:
[...]
Dat is (ook) omdat het uiteindelijk goedkoper is..
Google etc zijn natuurlijk ook megabedrijven, niet te vergelijken met veel kleinere 'normale' bedrijven.

Maar connectiviteit is als internet provider jouw core business. Dan moet je daar toch wel 'innovatie' zoals IPv6 binnen afzienbare tijd, zeg het 5 jaar na introductie in NL bij jouw klanten thuis, volgen?

[Olaf van der Spek]

ANdrode schreef op vrijdag 19 augustus 2016 @ 12:52:
[...]


Maar connectiviteit is als internet provider jouw core business. Dan moet je daar toch wel 'innovatie' zoals IPv6 binnen afzienbare tijd, zeg het 5 jaar na introductie in NL bij jouw klanten thuis, volgen?

Niet als er geen echte business case voor is..

[Belgar]

Gaan wel behoorlijk off-topic maar in mijn ervaring is het maar deels de grootte van het bedrijf. Ik heb netwerk consultancy gedaan met een hoop grote bedrijven in de telecom (internationaal) en in mijn ervaring is de "core" groep, de mensen die echt weten hoe alles werkt en alles met elkaar praat, nagenoeg altijd even groot. Of het nu een bedrijf is met 500k klanten of 50mln.

En dit soort groepen hebben een ongelofelijke buiten-proportionele invloed op zaken als de invoering van IPv6 en andere netwerk dingen zoals SDN, datacenter bouw/beheer, etc. De dynamiek binnen deze teams heeft dan ook vaak bijna net zoveel invloed als geld. Helaas is men vaak conservatief maar als zo'n groep eenmaal om is kan het vaak buitengewoon snel gaan.

(full disclosure: wat in principe ook mijn werk is. Binnen de industrie is het gegeven van de invloed van deze mensen ook heel goed gekend. Als eerste weten dat een groep "omgaat" voor een bepaalde technologie heeft een extreem voordeel in het beïnvloeden van het eropvolgende inkoopproces en daarmee de kans om de order binnen te halen)

[ANdrode]

Olaf van der Spek schreef op vrijdag 19 augustus 2016 @ 12:53:
[...]
Niet als er geen echte business case voor is..

Als het een risico is voor de essentie van jouw dienstverlening op de lange termijn dan is dat risico een business case. Je moet dit wel op de goede manier presenteren binnen de teams en binnen de organisatie.

Weinig IT-ers noemden vijf jaar geleden het 'negeren' van IPv6 als een risico voor de dienstverlening.

Dat is denk ik @Belgar zijn rol

[agresionpower]

nog meer goed nieuws over ipv6 gebruik op mobiele netwerken in amerika:
http://www.worldipv6launc...s-pass-50-ipv6-threshold/

[stormfly]

agresionpower schreef op zaterdag 20 augustus 2016 @ 13:52:
nog meer goed nieuws over ipv6 gebruik op mobiele netwerken in amerika:
http://www.worldipv6launc...s-pass-50-ipv6-threshold/

Het lijkt in de USA vooral vanuit de mobiele netwerken voort te komen. Afgelopen periode in dit topic meer posts van het kantelen van de IPv6 stack naar primair.

Ben benieuwd hoe de USA cable providers omgaan met IPv6?

[CyBeR]

Comcast gebruikt iig IPv6 voor management van hun kabelmodems, want ze hebben er te veel om rfc1918 te kunnen gebruiken.

[Maurits van Baerle]

CyBeR schreef op zaterdag 20 augustus 2016 @ 14:18:
Comcast gebruikt iig IPv6 voor management van hun kabelmodems, want ze hebben er te veel om rfc1918 te kunnen gebruiken.

Comcast geeft hun klanten ook Dual Stack. Ze hebben nu al 80% van hun klanten Dual Stack aangesloten en ze verwachten dat eind dit jaar 50% van al hun verkeer over IPv6 gaat.

Dit is hun klanteninfo portal voor IPv6.
http://www.comcast6.net

[RedShift]

Ik heb in de rapte even een vergelijking gemaakt tussen de IPv6 en IPv4 performance op een Cisco 2821: https://endeavour.webmind...Pv4vsIPv6-performance.pdf

Resultaten gemeten met iperf:
IPv4 met NAT: 244 megabits per seconde
IPv4 zonder NAT: 418 megabits per seconde
IPv6: 460 megabits per seconde

[ANdrode]

RedShift schreef op zondag 21 augustus 2016 @ 20:40:
Ik heb in de rapte even een vergelijking gemaakt tussen de IPv6 en IPv4 performance op een Cisco 2821: https://endeavour.webmind...Pv4vsIPv6-performance.pdf

Resultaten gemeten met iperf:
IPv4 met NAT: 244 megabits per seconde
IPv4 zonder NAT: 418 megabits per seconde
IPv6: 460 megabits per seconde

Interessante metingen met onverwacht resultaat! En goed onderbouwd

Twee vragen:
• MTU in beide gevallen gelijk (en dus packets per second)? Jumboframes/Jumbograms kunnen een groot verschil maken
• iperf3 print bij mij (alleen op linux) de grootte van het command window, daarmee kan je (indirect) packet loss zien

Deze twee vragen kan je trouwens ook met een 10s test controleren, die 10 minuten is heel degelijk maar duurt een half uur...

[RedShift]

ANdrode schreef op zondag 21 augustus 2016 @ 20:57:
[...]


Interessante metingen met onverwacht resultaat! En goed onderbouwd

Twee vragen:
• MTU in beide gevallen gelijk (en dus packets per second)? Jumboframes/Jumbograms kunnen een groot verschil maken
• iperf3 print bij mij (alleen op linux) de grootte van het command window, daarmee kan je (indirect) packet loss zien

Deze twee vragen kan je trouwens ook met een 10s test controleren, die 10 minuten is heel degelijk maar duurt een half uur...

MTU is in beide gevallen gelijk, heb geen jumboframes toegepast, alle interfaces staan op hun standaard wat 1500 bytes is.

Grootte van het command window, bedoel je daarmee de MSS (Maximum Segment Size) of de TCP window size?

[ANdrode]

RedShift schreef op zondag 21 augustus 2016 @ 21:11:
[...]
MTU is in beide gevallen gelijk, heb geen jumboframes toegepast, alle interfaces staan op hun standaard wat 1500 bytes is.

Grootte van het command window, bedoel je daarmee de MSS (Maximum Segment Size) of de TCP window size?

Ik bedoelde inderdaad TCP window size . Zou niets uit moeten maken hoor (schaalt toch heel ver door als er geen packet loss is). Als er wel packet loss is dan maakt het congestion control algoritme misschien wél uit tijdens een langere test

[RedShift]

ANdrode schreef op zondag 21 augustus 2016 @ 21:17:
[...]


Ik bedoelde inderdaad TCP window size . Zou niets uit moeten maken hoor (schaalt toch heel ver door als er geen packet loss is). Als er wel packet loss is dan maakt het congestion control algoritme misschien wél uit tijdens een langere test

Heb de window size vastgelegd met "-w 64k" en op de 10 seconden test maakte dit maar een paar megabit verschil voor alle drie de testen.

Edit: Een UDP test zou betrouwbaarder zijn om de echte ruwe performance te meten van de router, maar UDP wordt ook niet zo vaak gebruikt in een netwerk...

[ Voor 13% gewijzigd door RedShift op 21-08-2016 21:30 ]

[ik222]

Op zich een interessante vergelijking alleen heb je natuurlijk te maken met meer factoren dan alleen de router voor wat betreft de vergelijking tussen IPv4 en IPv6.

Ik bedoel het performance verlies bij NAT in de router is duidelijk (daar veranderd op de server / clients verder ook niets t.o.v. van de IPv4 test zonder NAT)

Maar de 10% verschil tussen IPv4 en IPv6 kan natuurlijk door veel meer factoren veroorzaakt worden dan door de router.

[RedShift]

ik222 schreef op zondag 21 augustus 2016 @ 21:35:
Op zich een interessante vergelijking alleen heb je natuurlijk te maken met meer factoren dan alleen de router voor wat betreft de vergelijking tussen IPv4 en IPv6.

Ik bedoel het performance verlies bij NAT in de router is duidelijk (daar veranderd op de server / clients verder ook niets t.o.v. van de IPv4 test zonder NAT)

Maar de 10% verschil tussen IPv4 en IPv6 kan natuurlijk door veel meer factoren veroorzaakt worden dan door de router.

Klopt, technisch gezien heb je gelijk aangezien niet alle factoren die mogelijks kunnen van invloed zijn, zijn uitgeschakeld. Ik heb de situatie zuiver proberen te houden door alles direct met elkaar te verbinden en geen tweaking te doen van buffers of dergelijke. Ook loopt de test 10 minuten wat het effect van eventuele window scaling minimaliseert, want eenmaal de TCP window aan het maximum zit dan is het echt nog maar pakketjes versluizen en valt een bottleneck tussenin veel meer op. Vergeet ook niet dat in de testen zonder NAT, TCP er eigenlijk zelf niet toe doet, routing gebeurt op laag 3 dus bij zuivere routing is er geen enkele reden waarom de router de payload van de IP pakketjes zou moeten beginnen inspecteren, dus eventuele performance verschillen verschuift dan terug naar de eindhosts, en zowel de client als de server stonden met hun vingers te draaien tijdens deze test, dus capaciteitsproblemen aan client/server kant waren er niet. Dus in dit geval denk ik dat het toch wel aantoont dat de router voor het performanceverschil zorgt.

Nu, op mijn Facebook post in de IPv6 groep heeft er iemand gereageerd die meegewerkt heeft aan de CEF (Cisco Express Forwarding) software in de routers, en hij was iets verbaasd dat IPv6 een performance winst gaf. Ik heb hem nog wat details doorgestuurd, we zullen zien wat hij er van vindt...

Iemand anders opperde dat het verschil misschien zit in het feit dat in IPv4 er nog een checksum berekend moet worden en in IPv6 die checksum weggevallen is. Dat in combinatie met het minder moeten parsen van verschillende opties geeft misschien die performance winst.

EDIT: Om 100% zeker te zijn dat de hosts niet de bottleneck zijn, bij een directe verbinding tussen de client en de host haalde ik 902 megabits/s via IPv4 en 922 megabits/s via IPv6.

Grappig genoeg, mijn laptop maakt een (amper hoorbaar) fluittoontje als de netwerkkaart zwaar gebruikt wordt, en dit gefluit was een toontje hoger bij de IPv6 test vergeleken met de IPv4 test... Helaas heb ik hier geen microfoon die gevoelig genoeg is om het op te nemen.

[ Voor 9% gewijzigd door RedShift op 21-08-2016 22:12 ]

[ik222]

Je test is ook zeker interessant alleen zoals je laatste test ook al laat zien heb je bij een directe verbinding ook een verschil met weliswaar hogere waardes. Dat betekent wel dat de hosts niet de bottleneck zijn in termen van absolute doorvoer. Maar dat betekent nog niet dat de netwerkkaart of het OS van server of clients niet op lagere snelheden ook voor een verschil kunnen zorgen.

[ANdrode]

RedShift schreef op zondag 21 augustus 2016 @ 21:57:
[...]
Ook loopt de test 10 minuten wat het effect van eventuele window scaling minimaliseert, want eenmaal de TCP window aan het maximum zit dan is het echt nog maar pakketjes versluizen en valt een bottleneck tussenin veel meer op.

Mits er geen packet loss is?

Ik krijg zelf wat meer output van iperf3. Daarin kan je dus het tcp window en aantal retransmits zien. Zoals je ziet zit er een dipje in de gemeten bandbreedte in de seconde waarin er een erg klein (~ 1 op 1260) aantal pakketten wegvalt.

code:

▶ iperf3 -c 192.168.178.171
Connecting to host 192.168.178.171, port 5201
[  4] local 192.168.178.17 port 56080 connected to 192.168.178.171 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   114 MBytes   953 Mbits/sec   19    451 KBytes
[  4]   1.00-2.00   sec   112 MBytes   944 Mbits/sec    0    495 KBytes
[  4]   2.00-3.00   sec   112 MBytes   944 Mbits/sec    0    495 KBytes
[  4]   3.00-4.00   sec   112 MBytes   944 Mbits/sec    0    495 KBytes
[  4]   4.00-5.00   sec   112 MBytes   944 Mbits/sec    0    495 KBytes
[  4]   5.00-6.00   sec   111 MBytes   933 Mbits/sec    0    495 KBytes
[  4]   6.00-7.00   sec   110 MBytes   923 Mbits/sec   61    451 KBytes
[  4]   7.00-8.00   sec   112 MBytes   944 Mbits/sec    0    451 KBytes
[  4]   8.00-9.00   sec   112 MBytes   944 Mbits/sec    0    563 KBytes
[  4]   9.00-10.00  sec   112 MBytes   944 Mbits/sec    0    563 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec   80             sender
[  4]   0.00-10.00  sec  1.09 GBytes   939 Mbits/sec                  receiver

iperf Done.

Realtek USB ebay NIC <-> Intel i210

[RedShift]

ANdrode schreef op zondag 21 augustus 2016 @ 22:29:
[...]


Mits er geen packet loss is?

Ik krijg zelf wat meer output van iperf3. Daarin kan je dus het tcp window en aantal retransmits zien. Zoals je ziet zit er een dipje in de gemeten bandbreedte in de seconde waarin er een erg klein (~ 1 op 1260) aantal pakketten wegvalt.

code:

▶ iperf3 -c 192.168.178.171
Connecting to host 192.168.178.171, port 5201
[  4] local 192.168.178.17 port 56080 connected to 192.168.178.171 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   114 MBytes   953 Mbits/sec   19    451 KBytes
[  4]   1.00-2.00   sec   112 MBytes   944 Mbits/sec    0    495 KBytes
[  4]   2.00-3.00   sec   112 MBytes   944 Mbits/sec    0    495 KBytes
[  4]   3.00-4.00   sec   112 MBytes   944 Mbits/sec    0    495 KBytes
[  4]   4.00-5.00   sec   112 MBytes   944 Mbits/sec    0    495 KBytes
[  4]   5.00-6.00   sec   111 MBytes   933 Mbits/sec    0    495 KBytes
[  4]   6.00-7.00   sec   110 MBytes   923 Mbits/sec   61    451 KBytes
[  4]   7.00-8.00   sec   112 MBytes   944 Mbits/sec    0    451 KBytes
[  4]   8.00-9.00   sec   112 MBytes   944 Mbits/sec    0    563 KBytes
[  4]   9.00-10.00  sec   112 MBytes   944 Mbits/sec    0    563 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec   80             sender
[  4]   0.00-10.00  sec  1.09 GBytes   939 Mbits/sec                  receiver

iperf Done.

Realtek USB ebay NIC <-> Intel i210

Tiens, ik krijg niet dezelfde output op mijn Windows laptop. Dit is de iperf dat ik gebruikt heb: https://iperf.fr/ Ik weet niet precies hoe iperf die verliesstatistieken berekent, misschien is het op Windows niet mogelijk om dit per TCP verbinding op te vragen (ik weet dat linux het allesinds ergens onder /proc of /sys het bijhoudt). Zal eens een linux PC er bij halen en herhalen, maar lig nu al met een oog toe in men bed dus het zal voor later zijn.

[agresionpower]

BT is in Engeland inmiddels ook met de uitrol begonnen en hoopt begin volgend jaar alle klanten met een "homehub 5" van ipv6 voorzien te hebben.
http://www.ispreview.co.u...-live-network-autumn.html

[tcviper]

Even een vraagje, is het zo dat als je puur een lokale router als DNS gebruikt (via DHCP) dat deze blijkbaar ook voor IPv6 werkt? Ik lees op het net dat: IPv4 DNS servers can provide IPv6 addresses. Dat werkt dus blijkbaar want op alle LAN computers staat puur 192.168.1.1 als DNS (dat is de router). Op de router zelf staan natuurlijk IPv6 en IPv4 DNS servers (opendns), maar clients krijgen puur 192.168.1.1.

[CyBeR]

Ja. Mits de host v4-connectiviteit heeft natuurlijk.

[ Voor 89% gewijzigd door CyBeR op 22-08-2016 11:39 ]

[Verwijderd]

Ik heb nu een pfsense firewall draaien, echter de IPv6 verbinding valt na x aantal uren weg. Iemand ervaring hiermee? ISP Xs4all.

De default route is nog hetzelfde, MTU ook. Adres via prefix delegation dus verwacht ik dat de sessie met xs4all actief blijft. De pfsense box zit achter een vdsl modem (vigor 130). Rebooten lost het niet op.

[ Voor 13% gewijzigd door Verwijderd op 22-08-2016 11:16 ]

[Maurits van Baerle]

agresionpower schreef op maandag 22 augustus 2016 @ 10:20:
BT is in Engeland inmiddels ook met de uitrol begonnen en hoopt begin volgend jaar alle klanten met een "homehub 5" van ipv6 voorzien te hebben.
http://www.ispreview.co.u...-live-network-autumn.html

Tja, ik heb zelf BT met een HomeHub 5 en zit met smart te wachten. Jammer dat het vertraging heeft opgelopen...

[Out.of.Control]

Verwijderd schreef op maandag 22 augustus 2016 @ 11:14:
Ik heb nu een pfsense firewall draaien, echter de IPv6 verbinding valt na x aantal uren weg. Iemand ervaring hiermee? ISP Xs4all.

De default route is nog hetzelfde, MTU ook. Adres via prefix delegation dus verwacht ik dat de sessie met xs4all actief blijft. De pfsense box zit achter een vdsl modem (vigor 130). Rebooten lost het niet op.

Je moet de prefix om de zoveel tijd opnieuw aanvragen met dhcp6, anders stopt de routering vanuit XS4ALL naar jouw kant.

[agresionpower]

Maurits van Baerle schreef op maandag 22 augustus 2016 @ 11:19:
[...]
Tja, ik heb zelf BT met een HomeHub 5 en zit met smart te wachten. Jammer dat het vertraging heeft opgelopen...

Waarschijnlijk heb je alsnog eerder ipv6 dan de gemiddelde ziggo klant

[Roetzen]

agresionpower schreef op maandag 22 augustus 2016 @ 12:38:
[...]


Waarschijnlijk heb je alsnog eerder ipv6 dan de gemiddelde ziggo klant

Dat is nog maar afwachten. Net als Ziggo roept BT ook al jaren dat ze het "later dit jaar" gaan uitrollen. Eerst zien, dan geloven zou ik zeggen...

[agresionpower]

Roetzen schreef op maandag 22 augustus 2016 @ 13:54:
[...]

Dat is nog maar afwachten. Net als Ziggo roept BT ook al jaren dat ze het "later dit jaar" gaan uitrollen. Eerst zien, dan geloven zou ik zeggen...

Toch is er in de laatste maanden wel wat veranderd bij BT.
http://stats.labs.apnic.n...2856?c=GB&p=1&v=1&w=1&x=1

Zegt natuurlijk niet heel veel want bij ziggo gingen ze ook van 0 naar 6% en toen hield het ook op.

Maarja, de "autumn" waar over gesproken word begint al bijna natuurlijk, dus we zullen het snel weten.


Edit: Bij de concurrent sky is het trouwens wel heel vlot gegaan: http://stats.labs.apnic.net/ipv6/AS5607
Wellicht speelt dat nog een rol?

[ Voor 10% gewijzigd door agresionpower op 22-08-2016 16:45 ]

[Dutch2007]

Roetzen schreef op maandag 22 augustus 2016 @ 13:54:
[...]

Dat is nog maar afwachten. Net als Ziggo roept BT ook al jaren dat ze het "later dit jaar" gaan uitrollen. Eerst zien, dan geloven zou ik zeggen...

Ziggo doet 't al uitrollen, dus daar zijn ze sneller mee, iedereen IPv6 bij ziggo (incl mensen met een bridge-only modem of klanten die 't modem op bridge only zetten.... Dat zal anno 2017? 2018? hoop ik iets worden...)

[Verwijderd]

NAT64/DNS64 testen?

http://www.internetsociet...public-testing-in-go6lab/

[CAPSLOCK2000]

Out.of.Control schreef op maandag 22 augustus 2016 @ 11:37:

Je moet de prefix om de zoveel tijd opnieuw aanvragen met dhcp6, anders stopt de routering vanuit XS4ALL naar jouw kant.

Zolang XS4All maar af en toe en DHCP-request ziet is het goed. Niemand dwingt je om er iets mee te doen.

Dus:
1. Installeer DHCPv6.
2. Gooi het antwoord weg (vervang het script door /dev/null).
3. Configureer je verbinding statisch.

[Verwijderd]

CAPSLOCK2000 schreef op dinsdag 23 augustus 2016 @ 16:09:
[...]


Zolang XS4All maar af en toe en DHCP-request ziet is het goed. Niemand dwingt je om er iets mee te doen.

Daar lijkt het inderdaad op, het werkt op dit moment nog steeds gelukkig. Ik denk dat ik de delegation ga verplaatsen naar een dummy interface ipv mijn lan interface zodat ik zelf mijn eigen gekozen subnet kan invoeren, want hoewel er staat dat ik zelf een prefix kan opgeven lijkt dit na vele uren niet te werken.

[ Voor 10% gewijzigd door Verwijderd op 23-08-2016 16:19 ]

[duvekot]

Verwijderd schreef op dinsdag 23 augustus 2016 @ 15:29:
NAT64/DNS64 testen?

http://www.internetsociet...public-testing-in-go6lab/

Hoe lastig is het om zelf een NAT64/DNS64 installatie te maken zodat je bijvoorbeeld thuis een single stack IPv6 netwerk zou kunnen opstellen, waarbij het verkeer naar het "oude" IPv4 via je eigen "legacy" IPv4 adres gerouteerd wordt?

Of is het een idee om met alle kennis hier aanwezig om een instructie te maken om bijvoorbeeld een OpenWRT router zo in te richten dat je echt een single stack IPv6 netwerk hebt thuis, maar toch met toegang tot het IPv4 netwerk via je eigen NAT64/DNS64 gateway.

Of is het teveel moeite? en is een dual stack netwerk voor nu gewoon het meest eenvoudigste/verstandigste?

[Verwijderd]

duvekot schreef op woensdag 24 augustus 2016 @ 00:02:
[...]


Hoe lastig is het om zelf een NAT64/DNS64 installatie te maken zodat je bijvoorbeeld thuis een single stack IPv6 netwerk zou kunnen opstellen, waarbij het verkeer naar het "oude" IPv4 via je eigen "legacy" IPv4 adres gerouteerd wordt?

Of is het een idee om met alle kennis hier aanwezig om een instructie te maken om bijvoorbeeld een OpenWRT router zo in te richten dat je echt een single stack IPv6 netwerk hebt thuis, maar toch met toegang tot het IPv4 netwerk via je eigen NAT64/DNS64 gateway.

Of is het teveel moeite? en is een dual stack netwerk voor nu gewoon het meest eenvoudigste/verstandigste?

Dat is niet zo moeilijk, ik heb deze tutorial wel eens gebruikt, is inmiddels wel een tijdje geleden maar misschien lukt het met kleine aanpassingen nog.

http://namsep.blogspot.nl...n-nat64-dns64-joolmx.html

[RedShift]

Verwijderd schreef op dinsdag 23 augustus 2016 @ 16:19:
[...]


Daar lijkt het inderdaad op, het werkt op dit moment nog steeds gelukkig. Ik denk dat ik de delegation ga verplaatsen naar een dummy interface ipv mijn lan interface zodat ik zelf mijn eigen gekozen subnet kan invoeren, want hoewel er staat dat ik zelf een prefix kan opgeven lijkt dit na vele uren niet te werken.

Het zou ook dit kunnen zijn? https://redmine.pfsense.org/issues/6691

[CAPSLOCK2000]

Verwijderd schreef op dinsdag 23 augustus 2016 @ 16:19:

Daar lijkt het inderdaad op, het werkt op dit moment nog steeds gelukkig. Ik denk dat ik de delegation ga verplaatsen naar een dummy interface ipv mijn lan interface zodat ik zelf mijn eigen gekozen subnet kan invoeren, want hoewel er staat dat ik zelf een prefix kan opgeven lijkt dit na vele uren niet te werken.

Ik weet niet zeker of ik je goed begrijp. Probeer je via prefix-delegation een range voor je subnet aan te vragen bij XS4All? Dat hoeft helemaal niet, je hele /48 wordt naar je toe geroute. Je mag het lokaal allemaal statisch inrichten.

[Verwijderd]

CAPSLOCK2000 schreef op vrijdag 26 augustus 2016 @ 00:40:
[...]


Ik weet niet zeker of ik je goed begrijp. Probeer je via prefix-delegation een range voor je subnet aan te vragen bij XS4All? Dat hoeft helemaal niet, je hele /48 wordt naar je toe geroute. Je mag het lokaal allemaal statisch inrichten.

Dat is precies wat ik eerst ook dacht, maar na het starten via prefix delegation en het overgaan naar static config viel na een paar uur de verbinding weg. Na diverse testen en het vervolgens weer aanzetten van pd aanvraag werkte het weer (even).

Omdat ik er al aardig wat tijd had inzitten heb ik het voor nu zo opgelost, ik heb op mijn andere subnetten (nas, wifi, camera's) wel static IPv6 ingesteld. Vind ik wel zo leuk ivbm het zelf maken van prefixes het is nu meerdere dagen stabiel.

Misschien dat ik over een paar weken het nog eens probeer om te kijken of ik kan nagaan wat er misging.

[HSL]

Ik heb sinds een tijdje een ubnt edgerouter X (sfp) staan en heb ook sinds 2 maanden 500/500 van XS4ALL.
Nu heb ik deels aan de praat, op de switch0 in de router heb ik nu de juiste ipv6 range en die wordt ook goed uitgedeeld naar de clients, maar op één of andere manier krijg ik het uitgaand niet aan de praat.

Heeft iemand een soortgelijke setup en het wel werkend gekregen?

[jk-5]

HSL schreef op vrijdag 26 augustus 2016 @ 13:01:
Ik heb sinds een tijdje een ubnt edgerouter X (sfp) staan en heb ook sinds 2 maanden 500/500 van XS4ALL.
Nu heb ik deels aan de praat, op de switch0 in de router heb ik nu de juiste ipv6 range en die wordt ook goed uitgedeeld naar de clients, maar op één of andere manier krijg ik het uitgaand niet aan de praat.

Heeft iemand een soortgelijke setup en het wel werkend gekregen?

Heb je een static ipv6 default route naar buiten toe gezet? Ook is het nodig om een ipv6 ip uit de /64 op de switch0 interface op de router te setten. Als je dan router advertisements naar de interface werkend hebt zou ipv6 moeten werken

code:

set interfaces switch switch0 address xxxx:xxxx:xxxx::1/64
set protocols static route6 ::/0 next-hop <ipv6 gateway ip van next-hop van xs4all>

[tcviper]

CyBeR schreef op maandag 22 augustus 2016 @ 10:53:
Ja. Mits de host v4-connectiviteit heeft natuurlijk.

Als dat zo is, is het dan niet beter om de 'other' flag mee te sturen zodat clients een echte ipv6 dns mee krijgen (opendns bijv), of is dat via de lokale router (en dus via ipv4 look ups neem ik dan aan) net zo prima?

[CyBeR]

tcviper schreef op zaterdag 27 augustus 2016 @ 09:26:
[...]


Als dat zo is, is het dan niet beter om de 'other' flag mee te sturen zodat clients een echte ipv6 dns mee krijgen (opendns bijv), of is dat via de lokale router (en dus via ipv4 look ups neem ik dan aan) net zo prima?

Het maakt niet uit of je DNS lookups via v4 of v6 doet. Je bevraagt dezelfde database. Als je een v6 DNS server opgeeft gaan (gezien de voorkeur voor v6) je niet-v6 queries ook meestal gewoon naar de v6 server. Dan heb je dezelfde situatie maar dan dus andersom. (Beetje afhankelijk van hoe je resolver omgaat met meerdere opgegeven adressen of dat daadwerkelijk zo is; sommige doen ze allemaal tegelijk bijvoorbeeld.)

De enige reden om 't een of 't ander te doen is een gebrek aan connectiviteit via een van de protocollen; met een v6 nameserver kun je niks als je alleen v4 hebt en vice versa.

[tcviper]

Nou de router geeft, als ik dat aanzet eerst 192.168.1.1 (zichzelf dus) en daarna de ipv6 dns servers mee aan clients. Ik dacht dat als je beiden hebt staan het misschien voor ipv6 net iets sneller zou zijn ivm look ups en als het ipv4 stuk plat ligt kan die nog altijd via ipv6 etc etc.

[SampleUser]

KPN is weer verder aan het gaan met IPv6. Heb een Experia Box V10 en heb de eerste verbindingen met IPv6 die gelogd zijn ongeveer 12 uur geleden gemaakt toen ik een reboot deed.

http://flippylosaurus.eu/noindex/fotos/1472504531989.png

[CAPSLOCK2000]

Altijd fijn om te horen.

[Melantrix]

SampleUser schreef op maandag 29 augustus 2016 @ 23:03:
KPN is weer verder aan het gaan met IPv6. Heb een Experia Box V10 en heb de eerste verbindingen met IPv6 die gelogd zijn ongeveer 12 uur geleden gemaakt toen ik een reboot deed.

http://flippylosaurus.eu/noindex/fotos/1472504531989.png

Ook ik sinds deze week ipv6 vanuit KPN op mijn Experiabox v10. Nu heb ik verder (nog) weinig verstand van ipv6 e.d. Maar ik vroeg me af hoe jouw netwerk eruit ziet, en of je achter de experiabox nog een router hebt hangen. Zo ja, hoe heb jij alles werkend gekregen?

[SampleUser]

melantrix schreef op woensdag 31 augustus 2016 @ 09:26:
[...]

Ook ik sinds deze week ipv6 vanuit KPN op mijn Experiabox v10. Nu heb ik verder (nog) weinig verstand van ipv6 e.d. Maar ik vroeg me af hoe jouw netwerk eruit ziet, en of je achter de experiabox nog een router hebt hangen. Zo ja, hoe heb jij alles werkend gekregen?

Ik heb zelf geen andere routers achter mijn Experiabox, het werkte simpelweg gewoon direct.

Enige wat ik moest doen is wat poorten openzetten op v6 en wat DNS werk op mijn domeinen doen.

[Melantrix]

SampleUser schreef op woensdag 31 augustus 2016 @ 09:28:
[...]


Ik heb zelf geen andere routers achter mijn Experiabox, het werkte simpelweg gewoon direct.

Enige wat ik moest doen is wat poorten openzetten op v6 en wat DNS werk op mijn domeinen doen.

He, shit Ik heb op de devices die direct op mijn experiabox zitten inderdaad gewoon ipv6 werkend, maar achter mn tweede router niet Waarschijnlijk komt dit om dat het erop lijkt dat kpn een /64 adres geeft en dit volgens mij een /48 of /56 moet zijn om te kunnen subnetten en het daardoor dus mogelijk wordt om meerdere routers te kunnen plaatsen, maar dat weet ik niet zeker. Als hier mensen zijn die me kunnen corrigeren/helpen graag

[SampleUser]

melantrix schreef op woensdag 31 augustus 2016 @ 09:33:
[...]

He, shit Ik heb op de devices die direct op mijn experiabox zitten inderdaad gewoon ipv6 werkend, maar achter mn tweede router niet Waarschijnlijk komt dit om dat het erop lijkt dat kpn een /64 adres geeft en dit volgens mij een /48 of /56 moet zijn om te kunnen subnetten en het daardoor dus mogelijk wordt om meerdere routers te kunnen plaatsen, maar dat weet ik niet zeker. Als hier mensen zijn die me kunnen corrigeren/helpen graag

Laat je DHCP achter je 2e router door de 2e router of de Experia Box doen?

[Melantrix]

SampleUser schreef op woensdag 31 augustus 2016 @ 09:38:
[...]

Laat je DHCP achter je 2e router door de 2e router of de Experia Box doen?

ehm.. Als ik goed begrijp wat ik alles probeerde, dhcp vanuit de Experiabox, om het in ieder geval werkend te krijgen. Uiteindelijk wil ik naar een eigen dhcpv6 server, maar dat is met mijn huidige kennis nog flinke toekomst muziek

-----------------------------
edit:

Ik heb kpn even gemaild en gevraagd wat voor adressen we precies krijgen, het volgende kreeg ik terug. Ik dacht wellicht handig voor anderen hier

KPN levert een /48 adres, dit wordt door de V10 aangevuld tot 64.
Waarbij het subnet 2axx.xxxx.xxxx.0:: dus de WAN kant van de V10 is.
Subnet 2axx.xxxx.xxxx.1:: is dan de LAN kant.
Dit laatste zal dus aangeboden worden aan je router op de WAN kant, die vult dat dan aan met zijn eigen lokale deel.
Ik gok dus dat je router dit zelf ook moet zien als een /48 (of misschien toch /64) waarbij je achter je eigen router weer een subnet kan maken.
Bijvoorbeeld 2axx.xxxx.xxxx.10:: op zijn LAN kant.
Neem dit niet aansluitend, want het kan zijn dat we dat zelf nog willen aanvullen voor toekomstig diensten.

[ Voor 47% gewijzigd door Melantrix op 31-08-2016 10:56 ]

[CAPSLOCK2000]

Dat is een redelijke uitleg. lang niet perfect, maar de helpdesker in kwestie weet in ieder geval een beetje hoe het zit.

Je eigen router zal een andere /64 uit je /48 moeten krijgen, bijvoorbeeld 2axx:xxxx:xxxx:10::/64 .
Vervolgens moet je een route instellen instellen op je primaire router die aangeeft dat dit subnet via je tweede router bereikbaar is.

Idealiter regelt DHCP dat zelf voor je maar dat werkt blijkbaar nog niet.

[Tales]

Wow. Vanochtend toen KPN een storing had zag ik in mijn modem al dat IPv6 beschikbaar was. Lijkt er op dat KPN een knop om gezet heeft voor Experiabox 10 eigenaren. Straks maar even kijken hoe en wat.

[Tom Paris]

Tales schreef op zaterdag 03 september 2016 @ 19:57:
Wow. Vanochtend toen KPN een storing had zag ik in mijn modem al dat IPv6 beschikbaar was. Lijkt er op dat KPN een knop om gezet heeft voor Experiabox 10 eigenaren. Straks maar even kijken hoe en wat.

Klopt, dat zag ik ook. Gisteren geen IPv6, vandaag sinds/tijdens de storing ineens wel... Nu weer niets.

[agresionpower]

Tom Paris schreef op zaterdag 03 september 2016 @ 21:03:
[...]


Klopt, dat zag ik ook. Gisteren geen IPv6, vandaag sinds/tijdens de storing ineens wel... Nu weer niets.

zou de storing misschien IPv6 gerelateerd zijn? Als in, ze hebben het aangezet en vervolgens werkte dingen niet meer?

[Zr40]

Eerder toeval denk ik. IPv4 routing op de backbone gaat niet stuk door het uitrollen van IPv6 configuratie naar modems.

Wellicht hadden ze inderdaad bedoeld om IPv6 in te schakelen en daarbij per ongeluk IPv4 uitgeschakeld. Maar dat noem ik 'human error', niet 'het komt door het inschakelen van IPv6'

[ Voor 69% gewijzigd door Zr40 op 04-09-2016 13:05 ]

[TD-er]

IPv4 "uitschakelen" is dan ook heel snel weer ongedaan te maken lijkt mij. Dat hoeft niet een halve dag te duren.

[Jerrythafast]

Zou me wel kunnen voorstellen dat het een halve dag heeft geduurd voordat iemand zich realiseerde dat er zoiets bestaat als "IPv4 uitzetten"

[Keiichi]

agresionpower schreef op zondag 04 september 2016 @ 12:32:
[...]


zou de storing misschien IPv6 gerelateerd zijn? Als in, ze hebben het aangezet en vervolgens werkte dingen niet meer?

Op een interne storingsstatuspagina van KPN was dit te lezen: "Een mogelijke oorzaak is gevonden in een corrupt routeringsplan. Het technisch team is bezig met de herstelwerkzaamheden"

[Snow_King]

Keiichi schreef op maandag 05 september 2016 @ 08:20:
[...]


Op een interne storingsstatuspagina van KPN was dit te lezen: "Een mogelijke oorzaak is gevonden in een corrupt routeringsplan. Het technisch team is bezig met de herstelwerkzaamheden"

Als dit IPv6 zou zijn geweest is dat dus een drama. Want hoewel het protocol het probleem niet was, maar een admin of iets dergelijks gaat IPv6 waarschijnlijk wél de schuld krijgen.

Het woord IPv6 wordt dan bij management direct gelijk gezet aan "storing".

[Keiichi]

Snow_King schreef op maandag 05 september 2016 @ 10:52:
[...]

Als dit IPv6 zou zijn geweest is dat dus een drama. Want hoewel het protocol het probleem niet was, maar een admin of iets dergelijks gaat IPv6 waarschijnlijk wél de schuld krijgen.

Het woord IPv6 wordt dan bij management direct gelijk gezet aan "storing".

Ik denk dat we niet moeten gaan gissen wat het was. Er zijn uiteraard mensen die exact weten wat er mis was, maar die ken ik niet en die gaan het ook niet naar buiten brengen. Hoop inderdaad wel als het iets met ipv6 te maken had, dat het niet als veroorzaker te boek komt te staan.
Heb in de wandelgangen zo wel eens gehoord dat KPN niet heel actief bezig is met IPv6 voor consumten, omdat ze zat IPv4 adressen hebben....

[Snow_King]

Keiichi schreef op maandag 05 september 2016 @ 11:01:
[...]


Ik denk dat we niet moeten gaan gissen wat het was. Er zijn uiteraard mensen die exact weten wat er mis was, maar die ken ik niet en die gaan het ook niet naar buiten brengen. Hoop inderdaad wel als het iets met ipv6 te maken had, dat het niet als veroorzaker te boek komt te staan.
Heb in de wandelgangen zo wel eens gehoord dat KPN niet heel actief bezig is met IPv6 voor consumten, omdat ze zat IPv4 adressen hebben....

Nee, zeker niet. Maar in het algemeen krijgt iPv6 vaak de schuld en daarmee een slechte naam. Daar ben ik altijd een beetje bang voor.

[agresionpower]

APNIC heeft een tool waarmee ze per land bij houden wat het verschil in round trip time tussen IPv4 en IPv6. Best aardig, alleen hebben sommige landen nog niet zo veel samples.

http://stats.labs.apnic.net/v6perf

[databeestje]

Keiichi schreef op maandag 05 september 2016 @ 08:20:
[...]


Op een interne storingsstatuspagina van KPN was dit te lezen: "Een mogelijke oorzaak is gevonden in een corrupt routeringsplan. Het technisch team is bezig met de herstelwerkzaamheden"

Het interne netwerk van de KPN is vrij complex, het is veel te simpel om aan te nemen dat het IPv6 is. Met de mensen die ik ken uit het IPv6 Pilot traject 4 jaar geleden is er echt wel kennis en mensen die het serieus nemen.

Overigens zijn er in het verleden al issues geweest met de grote van de IPv4 tabel (niet IPv6) waarbij routers uit het geheugen liepen. Hierdoor zijn veel (oudere) routers wel opnieuw opgedeeld in IPv4 en IPv6 en herstart, maar kan het alsnog een issue worden als 1 van de 2 tabellen uit zijn geheugen loopt en het platform naar software routing gaat.

Nu is het wel een standaard praktijk bij veel grotere providers om alleen alle routes op de edge op te vangen, en een versimpelde aggregatie intern te gebruiken. Bij Vodafone is het zelfs zo extreem dat ik alleen een default gw route via BGP kon krijgen, de KPN biedt in ieder geval full routes.

[agresionpower]

Ongeacht of er iets mis ging bij het aanzetten van IPv6 of niet, ik zie dat KPN wel de hoogste piek in een jaar tijd neerzet bij de apnic meting http://stats.labs.apnic.net/ipv6/AS1136

Maar die grafiek schommelt wel vaker heen en weer.

[Roetzen]

Maar opvallend is die piek in elk geval wel. Overigens betekent een correlatie nog niet altijd een oorzakelijk verband. In plaats van dat aanzetten van IPv6 een oorzaak van de storing was, zou de piek in IPv6 ook een bijeffect van de storing kunnen zijn. Of er is een gemeenschappelijke oorzaak voor de storing en de piek. Of... het is gewoon toeval..

Zonder meer informatie blijft het gissen...

[Jerrythafast]

Jerrythafast schreef op donderdag 26 mei 2016 @ 22:33:
[...]

Vandaag mijn Ubee321b herstart omdat de WiFi instabiel was (symptomen waren exact gelijk aan die van de TC7210 WiFi-bug, namelijk wel bereik en connectie maar verkeer komt niet meer aan op de bestemming). En na de herstart is mijn IPv6 prefix, die ik al had sinds 7 februari, veranderd Is dus ruim 3,5 maanden hetzelfde gebleven.

IPv4 adres is nog dezelfde.

Gisteravond is bij een (door mij geïnitieerde) reboot van mijn Ziggo-modem de IPv6 prefix weer gewijzigd. Is 3,5 maanden geleden voor het laatst veranderd. IPv4 adres veranderde een maand geleden, maar is gisteren niet veranderd.

Sinds 28 februari 2016:
26 mei 2016 nieuw IPv6
13 augustus 2016 nieuw IPv4
10 september 2016 nieuw IPv6

[ Voor 7% gewijzigd door Jerrythafast op 11-09-2016 12:25 ]

[Roetzen]

Al met al valt het nog wel mee dus.

Gingen die wijzigingen van IPv6 adres samen met een frimware update?

[Jerrythafast]

Roetzen schreef op dinsdag 13 september 2016 @ 14:24:
Al met al valt het nog wel mee dus.

Gingen die wijzigingen van IPv6 adres samen met een frimware update?

Nee, heb al sinds 7 februari 2016 versie 9.12.7009.

[Verwijderd]

https://ams-ix.net/techni.../sflow-stats/ipv6-traffic

Flinke piek gisteren en voor best lange tijd. Routerings foutje, monitoring foutje of goed nieuws?

[Vinnienerd]

Verwijderd schreef op woensdag 14 september 2016 @ 07:57:
https://ams-ix.net/techni.../sflow-stats/ipv6-traffic

Flinke piek gisteren en voor best lange tijd. Routerings foutje, monitoring foutje of goed nieuws?

iOS 10 OTA update

[stormfly]

Vinnienerd schreef op woensdag 14 september 2016 @ 08:25:
[...]


iOS 10 OTA update

Hmmm daar lijkt het iets te laat voor, als je de IPv4 graph pakt zie je wel de IOS10 update terug 200G verkeer exact om 19:00.

[Vinnienerd]

stormfly schreef op woensdag 14 september 2016 @ 08:42:
[...]


Hmmm daar lijkt het iets te laat voor, als je de IPv4 graph pakt zie je wel de IOS10 update terug 200G verkeer exact om 19:00.

Hier begint het verkeer ook precies om 19.00 te klimmen:

[stormfly]

Hmmm nee ik ben niet overtuigd;-) in jouw grafiek klimt hij pas echt om 20:30.

Check de IPv4 grafiek maar die is zo stijl om 1900 als de IPv6 grafiek van 20:30.

[Maurits van Baerle]

Aangezien Apple nu IPv6 compatibility eist van apps zou het misschien kunnen dat de golf van nieuwe apps die rond iOS10 uitkomen (ik denk dat ik gisteravond een stuk of twintig apps kon updaten) voor een permanent hogere hoeveelheid IPv6 verkeer zorgen.

Als het de komende dagen hoger blijft dan zou dat een oorzaak kunnen zijn. Als het vanavond weer normaal is dan was het iets anders.

[agresionpower]

ik verwacht zelf dat een partij die op meerdere plaatsen interconnect met de rest van de wereld gewoon tijdelijk zijn route over de ams-ix had staan. misschien onderhoud op een van zijn andere poten.
Pas als we vanavond weer de zelfde hoeveelheid zien ben ik er van overtuigd dat er daadwerkelijk ergens iets met ipv6 aan is gezet.

[agresionpower]

Ik weet niet of deze site al bekend is hier, maar ik vind het best wel stuitend om te zien dat sites als twitter, microsoft en amazon nog altijd niet op ipv6 bereikbaar zijn.

https://ipv6wallofshame.com/

[Raven]

Microsoft's site opent toch echt via IPv6 hier

[ Voor 7% gewijzigd door Raven op 15-09-2016 11:34 ]

[Maurits van Baerle]

Het viel me bij apple.com ook al op dat ik twee IPv6 adressen zie als ik er naar toe ga (2a02:26f0:b8:296::1aca en 2a02:26f0:b8:2a3::1aca) terwijl hij in de lijst rood is.

Het idee van die site is goed, overigens, zou graag nog hebben dat het uitgebreid werd naar top 1000 o.i.d.

[ Voor 41% gewijzigd door Maurits van Baerle op 15-09-2016 12:54 ]

[Keiichi]

Maurits van Baerle schreef op donderdag 15 september 2016 @ 12:53:
Het viel me bij apple.com ook al op dat ik twee IPv6 adressen zie als ik er naar toe ga (2a02:26f0:b8:296::1aca en 2a02:26f0:b8:2a3::1aca) terwijl hij in de lijst rood is.

Het idee van die site is goed, overigens, zou graag nog hebben dat het uitgebreid werd naar top 1000 o.i.d.

Denk dat het hier in zit:

code:

frank@venus:~$ host apple.com
apple.com has address 17.178.96.59
apple.com has address 17.142.160.59
apple.com has address 17.172.224.47
;; Truncated, retrying in TCP mode.
apple.com mail is handled by 20 mail-in21.apple.com.
apple.com mail is handled by 10 nwk-aaemail-lapp02.apple.com.
apple.com mail is handled by 20 mail-in24.apple.com.
apple.com mail is handled by 100 mail-in100.apple.com.
apple.com mail is handled by 10 nwk-aaemail-lapp03.apple.com.
apple.com mail is handled by 10 nwk-aaemail-lapp01.apple.com.
apple.com mail is handled by 20 mail-in25.apple.com.
apple.com mail is handled by 20 mail-in22.apple.com.
apple.com mail is handled by 20 mail-in23.apple.com.
frank@venus:~$ host www.apple.com
www.apple.com is an alias for www.apple.com.edgekey.net.
www.apple.com.edgekey.net is an alias for www.apple.com.edgekey.net.globalredir.akadns.net.
www.apple.com.edgekey.net.globalredir.akadns.net is an alias for e6858.dscc.akamaiedge.net.
e6858.dscc.akamaiedge.net has address 104.111.234.213
e6858.dscc.akamaiedge.net has IPv6 address 2a02:26f0:6a:297::1aca
e6858.dscc.akamaiedge.net has IPv6 address 2a02:26f0:6a:296::1aca

apple.com vs www.apple.com

Idem voor microsoft:

code:

frank@venus:~$ host microsoft.com
microsoft.com has address 23.96.52.53
microsoft.com has address 104.40.211.35
microsoft.com has address 23.100.122.175
microsoft.com has address 104.43.195.251
microsoft.com has address 191.239.213.197
microsoft.com mail is handled by 10 microsoft-com.mail.protection.outlook.com.
frank@venus:~$ host www.microsoft.com
www.microsoft.com is an alias for www.microsoft.com-c-2.edgekey.net.
www.microsoft.com-c-2.edgekey.net is an alias for www.microsoft.com-c-2.edgekey.net.globalredir.akadns.net.
www.microsoft.com-c-2.edgekey.net.globalredir.akadns.net is an alias for e2847.dspb.akamaiedge.net.
e2847.dspb.akamaiedge.net has address 104.102.42.198
e2847.dspb.akamaiedge.net has IPv6 address 2a02:26f0:f4:284::b1f
e2847.dspb.akamaiedge.net has IPv6 address 2a02:26f0:f4:295::b1f
e2847.dspb.akamaiedge.net has IPv6 address 2a02:26f0:f4:2a0::b1f

[ Voor 22% gewijzigd door Keiichi op 15-09-2016 13:38 ]

[agresionpower]

Er is dinsdag een update uitgekomen voor de ps4 en sinds dat moment zie ik veel ipv6 gerelateerde klachten, met name uit duitsland.
Lijkt er bijna op dat de ps4 iets met ipv6 wil doen maar dat het playstation netwerk daar nog niet klaar voor is.

[TD-er]

Of de gebruikte routers die niet helemaal lekker werken met IPv6.
Met DD-WRT op mijn TP-link WR1043ND moest ik ook een foward script actief zetten om IPv6 te kunnen gebruiken via dat accesspoint.
Ik kan me zo voorstellen dat er in heel veel routers nog verouderde firmware zit die ook dergelijke issues heeft.

[Snow_King]

agresionpower schreef op vrijdag 16 september 2016 @ 00:04:
Er is dinsdag een update uitgekomen voor de ps4 en sinds dat moment zie ik veel ipv6 gerelateerde klachten, met name uit duitsland.
Lijkt er bijna op dat de ps4 iets met ipv6 wil doen maar dat het playstation netwerk daar nog niet klaar voor is.

Zijn dat niet mensen achter CGNAT in Duitsland?

Ik heb net de PS4 4.0 update geïnstalleerd en terwijl dat gebeurde een pcap draait op mijn router:

code:

$ tcpdump -i eth1.100 -n -w eth1.100.ps4.pcap -s 2048 ether host 70:9e:29:9d:22:25

De pcap is 3MB groot (update was al gedownload), maar ik zie eigenlijk niets nieuws aan IPv6 verkeer.

Via RA/SLAAC krijgt de PS4 een IPv6 adres en vraagt via DHCPv6 om de DNS gegevens. Daarna een HTTP call naar ena.net.playstation.net waar een 403 forbidden op terug komt.

Dat is alles wat ik zie.

[agresionpower]

Snow_King schreef op vrijdag 16 september 2016 @ 11:42:
[...]

Zijn dat niet mensen achter CGNAT in Duitsland?

Ik heb net de PS4 4.0 update geïnstalleerd en terwijl dat gebeurde een pcap draait op mijn router:

code:

$ tcpdump -i eth1.100 -n -w eth1.100.ps4.pcap -s 2048 ether host 70:9e:29:9d:22:25

De pcap is 3MB groot (update was al gedownload), maar ik zie eigenlijk niets nieuws aan IPv6 verkeer.

Via RA/SLAAC krijgt de PS4 een IPv6 adres en vraagt via DHCPv6 om de DNS gegevens. Daarna een HTTP call naar ena.net.playstation.net waar een 403 forbidden op terug komt.

Dat is alles wat ik zie.

Dat zou uiteraard kunnen. En het lijkt me dat hun update niet opeens iets anders met ipv6 gaat doen als de update die jij binnen hebt gehaald.
Het is wel opvallend dat de problemen die ze hebben pas ontstaan zijn na het binnen halen van de update.

[Maurits van Baerle]

agresionpower schreef op vrijdag 16 september 2016 @ 11:45:
[...]


Dat zou uiteraard kunnen. En het lijkt me dat hun update niet opeens iets anders met ipv6 gaat doen als de update die jij binnen hebt gehaald.
Het is wel opvallend dat de problemen die ze hebben pas ontstaan zijn na het binnen halen van de update.

Het lijkt me goed mogelijk dat na de update de PS4 prima overweg kan met IPv4-only en met Dual-Stack maar toevallig net niet met DS-Lite omdat de verbinding dan net iets anders reageert dan de PS4 verwacht.

Iemand met een echte Dual Stack verbinding en een PS4 met de nieuwe firmware zou nu eens moeten kijken of de PS4 nog werkt als je IPv4 uitschakelt en of er meer IPv6 verkeer te meten valt.

[ Voor 14% gewijzigd door Maurits van Baerle op 16-09-2016 11:59 ]

[Keiichi]

fsck! De corerouter in datacenter van m'n server lijkt instabiel te zijn door de IPv6 implementatie....
Het gaat volgens mij om brocade routers.

Hopelijk komt de fabrikant er snel achter wat er precies aan de hand is, zodat alles nog stabieler dan voorheen wordt ;-)

[agresionpower]

Het PS4 probleem bij kabeldeutschland zou inmiddels opgelost moeten zijn (als ik het goed begrijp, mijn duits is niet zo heel goed):
https://forum.vodafone.de...-Network/m-p/1317823#M575

In die thread word nergens IPv6 genoemt, maar playstation duitsland heeft het zelf wel over een ipv6 probleem:
"An alle, die von dem IPv6 Problem bei @vodafone_de bzw. Kabel Deutschland betroffen sind: http://bit.ly/2d1zKRJ "

https://twitter.com/PlayStationDE/status/777806602233577472

[Hipska]

Zo zorgt Apple dat meer content providers IPv6 zullen ondersteunen: https://github.com/spotify/web-api/issues/270 De eerste tekenen zijn er al.

[ Voor 15% gewijzigd door Hipska op 19-09-2016 14:34 ]

[ANdrode]

Hipska schreef op maandag 19 september 2016 @ 13:06:
Zo zorgt Apple dat meer content providers IPv6 zullen ondersteunen: https://github.com/spotify/web-api/issues/270 De eerste tekenen zijn er al.

In het algemeen ben ik het hier mee eens. Maar er zijn hier natuurlijk partijen.

Het kan ook een keuze van Spotify zijn die zo hun users zo indirect dwingt om terug te gaan naar de native API en/of eigen apps, waardoor ze meer trainingsdata krijgen.

Dit is een stuk subtieler dan hoe Twitter dat deed met third party apps

[Roetzen]

Maurits van Baerle schreef op woensdag 14 september 2016 @ 09:18:
Aangezien Apple nu IPv6 compatibility eist van apps zou het misschien kunnen dat de golf van nieuwe apps die rond iOS10 uitkomen (ik denk dat ik gisteravond een stuk of twintig apps kon updaten) voor een permanent hogere hoeveelheid IPv6 verkeer zorgen.

Als het de komende dagen hoger blijft dan zou dat een oorzaak kunnen zijn. Als het vanavond weer normaal is dan was het iets anders.

Het was dus kennelijk iets anders...

[ Voor 87% gewijzigd door Roetzen op 19-09-2016 17:25 ]

[Zr40]

Nee, voor app review is het niet noodzakelijk dat de servers waar de app mee probeert te verbinden bereikbaar zijn via IPv6. Wél noodzakelijk is dat de app kan functioneren in een NAT64 omgeving.

quote: https://developer.apple.c...uid/TP40010220-CH213-SW12

Compatibility with IPv6 DNS64/NAT64 networks will be an App Store submission requirement, so it is essential that apps ensure compatibility. The good news is that the majority of apps are already IPv6-compatible. For these apps, it’s still important to regularly test your app to watch for regressions. Apps that aren’t IPv6-compatible may encounter problems when operating on DNS64/NAT64 networks. Fortunately, it’s usually fairly simple to resolve these issues, as discussed throughout this chapter.

[ Voor 79% gewijzigd door Zr40 op 19-09-2016 18:57 ]

[Verwijderd]

Er heeft weer een UKNOF plaats gevonden.

IPv6 addressplanning: YouTube: UKNOF35 - The Top 5 Things You need to keep in Mind when preparing y...

[dion_b]

Hmm, nieuwe IPv6-gerelateerde troubleshooting issue gevonden:

- laptop is bedraad aangesloten op IPv4 only-verbinding.
- WiFi staat ook aan en is verbonden met een verbinding die ook (native) IPv6 heeft.

Wat doet laptop (met Windows 7 in dit geval, maar heb bij 10 hetzelfde gedrag gezien)?

Standaard wordt bedraad boven draadloos geprerfereerd, maar blijkbaar gaat de v6 over v4 preference daarvoor. Gevolg is dat resources die over v6 beschikbaar zijn over WiFi benaderd worden, maar v4-only resources bedraad benaderd worden.

Duurde even voor ik doorhad waarom niets leek te kloppen van performance en IP-reeksen enzo.

Moraal van het verhaal is natuurlijk aloud: als je iets test, zorg dat je alleen verbonden bent op interfaces waar je de tests op uitvoert

[Freee!!]

Dat is inderdaad een leuke.

[agresionpower]

Het lijkt er op dat KPN afgelopen maand weer wat mensen op ipv6 heeft gezet
http://www.worldipv6launc...ent/images/graphs/KPN.png

[Raven]

agresionpower schreef op zaterdag 24 september 2016 @ 17:40:
Het lijkt er op dat KPN afgelopen maand weer wat mensen op ipv6 heeft gezet
http://www.worldipv6launc...ent/images/graphs/KPN.png

Over KPN en IPv6 gesproken, hoe kun je erachter komen wanneer je aan de beurt bent?

[Verwijderd]

Nu ook IPv6 in Azure.
https://azure.microsoft.c...ncer-ipv6-overview/?rnd=1

[Nakebod]

dion_b schreef op dinsdag 20 september 2016 @ 14:02:
Hmm, nieuwe IPv6-gerelateerde troubleshooting issue gevonden:

- laptop is bedraad aangesloten op IPv4 only-verbinding.
- WiFi staat ook aan en is verbonden met een verbinding die ook (native) IPv6 heeft.

Wat doet laptop (met Windows 7 in dit geval, maar heb bij 10 hetzelfde gedrag gezien)?

Standaard wordt bedraad boven draadloos geprerfereerd, maar blijkbaar gaat de v6 over v4 preference daarvoor. Gevolg is dat resources die over v6 beschikbaar zijn over WiFi benaderd worden, maar v4-only resources bedraad benaderd worden.

Duurde even voor ik doorhad waarom niets leek te kloppen van performance en IP-reeksen enzo.

Moraal van het verhaal is natuurlijk aloud: als je iets test, zorg dat je alleen verbonden bent op interfaces waar je de tests op uitvoert

Niet IPv6 specifiek, maar dat is o.a. wel de reden dat wij op alle laptops standaard Wireless Autoswitch installeren. Of WLAN, of LAN. Nooit alle 2. WLAN is bij ons in principe ook alleen internet, en LAN geeft ook toegang tot interne zaken.

[agresionpower]

Ik weet niet of deze seminar hier al voorbij was gekomen, maar hij lijkt mij in ieder geval erg interessant:
https://www.stipv6.nl/ipv6-is-er-kan-ipv4-nu-uit/

[HenkPiet]

agresionpower schreef op donderdag 29 september 2016 @ 10:14:
Ik weet niet of deze seminar hier al voorbij was gekomen, maar hij lijkt mij in ieder geval erg interessant:
https://www.stipv6.nl/ipv6-is-er-kan-ipv4-nu-uit/

Als iedereen die gaat ook z'n T-shirt aandoet https://www.huza.ro/wp-co...electric_t-shirt_back.jpg

[ Voor 2% gewijzigd door HenkPiet op 03-10-2016 15:32 . Reden: Afbeelding onjuist geplaatst ]