Het grote IPv6 topic

[Snow_King]

Verwijderd schreef op vrijdag 28 november 2014 @ 14:27:
KPN: Begonnen met pilot in de consumentenmarkt in 2014. Het streven is om 70% op IPv6 te hebben eind 2015.

Ziggo: Voor Kerst 2014 wordt een tweede poging gedaan om firmware met IPv6 werkend te krijgen bij 1200 klanten. Klanten krijgen /56 prefix en Dual stack, dus met behoud van het IPv4-adres.

Aparte keus om voor een /56 te gaan. Al is dat best groot, een /48 is makkelijker zodat je die intern weer kan opknippen in een /56 en /64.

[Osiris]

Snow_King schreef op vrijdag 28 november 2014 @ 15:20:
[...]

Aparte keus om voor een /56 te gaan. Al is dat best groot, een /48 is makkelijker zodat je die intern weer kan opknippen in een /56 en /64.

En dat opknippen helpt.... hóeveel % van KPN's niet-zakelijke klanten precies?

[Snow_King]

Osiris schreef op vrijdag 28 november 2014 @ 15:25:
[...]

En dat opknippen helpt.... hóeveel % van KPN's niet-zakelijke klanten precies?

Ik gok 0.01% in het begin. Het is alleen dat we op termijn applicaties kunnen krijgen die het wél gebruiken.

Denk aan slimme domotica thuis waar de "gateway" van alle sensoren via DHCPv6-PD om een subnet vraagt en die intern weer verdeeld aan zijn sensoren.

[CAPSLOCK2000]

Osiris schreef op vrijdag 28 november 2014 @ 15:25:
[...]

En dat opknippen helpt.... hóeveel % van KPN's niet-zakelijke klanten precies?

Nit-pick: Ziggo, KPN geeft wel een nette /48.

[CyBeR]

Snow_King schreef op vrijdag 28 november 2014 @ 15:20:
[...]

Aparte keus om voor een /56 te gaan. Al is dat best groot, een /48 is makkelijker zodat je die intern weer kan opknippen in een /56 en /64.

Waarom zou je zelf in een /56 willen opknippen? Gewoon /64's routen is zo lastig niet…

[databeestje]

CyBeR schreef op vrijdag 28 november 2014 @ 17:24:
[...]


Waarom zou je zelf in een /56 willen opknippen? Gewoon /64's routen is zo lastig niet…

Route aggregatie is een ding dat routers doen, wat makkelijk is voor mensen is lastig voor computers over het algemeen.

Dat wil zeggen in een geautomatiseerde manier zonder tussenkomst van mensen. Dus DHCP-PD van de klant CPE naar een eigen aangeschafte wifi router b.v.

Edit: Yay, na een Tweet van Sander Steffan naar de Nuon hebben ze daadwerkelijk het kapotte AAAA record van Nuon.nl weggehaald.

Leuk dat er commentaar van de IPv6-TF kwam dat er vaak via twitter dit soort dingen opgelost worden, maar nadat ik het anderhalf jaar geleden aangekaart had via de email en klantenservice had ik toch iets meer ... klantenservice verwacht.

Kunnen we in 2015 dit soort dingen niet gewoon zonder twitter ook oplossen?

[ Voor 31% gewijzigd door databeestje op 28-11-2014 21:34 ]

[CAPSLOCK2000]

't is natuurlijk treurig dat de oplossing is dat ze het AAAA-record hebben verwijderd, maar het is in ieder geval beter dan dat mensen klagen dat internet stuk is door IPv6.

[Verwijderd]

databeestje schreef op vrijdag 28 november 2014 @ 17:35:
[...]
Kunnen we in 2015 dit soort dingen niet gewoon zonder twitter ook oplossen?

Blijkbaar niet, zelf denk ik dat als een probleem "pubiek" wordt neergezet men dingen iets voortvarender oppakt om een eventuele twitter storm te voorkomen. Zeker als er meerdere mensen klagen.

[Snow_King]

CyBeR schreef op vrijdag 28 november 2014 @ 17:24:
[...]


Waarom zou je zelf in een /56 willen opknippen? Gewoon /64's routen is zo lastig niet…

Nee, maar je wil wel weer een /64 hebben voor SLAAC.

We weten nu niet direct de toepassing, maar in de toekomst gaat er zeker een toepassing zijn waar iemand zijn /48 weer wil door routeren in /56's naar devices die er weer /64's van maken.

Daarom geeft een /48 alle vrijheid aan de gebruiker en kan je zelf helemaal los gaan met routeren.

[Verwijderd]

Vanwege het enorme aantal adressen zou het fijn zijn dat partijen dezelfde prefixen uitdelen, dus /48. Is wel zo fijn voor zaken als fail2ban / forum blocks enzovoort. Zodat je met redelijke zekerheid kan zeggen dat je 1 klant/ aansluiting blokkeert in plaats van meerdere.

[Tomsworld]

Blijkbaar is de free xsnews server via ipv6 ook afgelopen.

om$ telnet reader.ipv6.xsnews.nl 119
Trying 2001:67c:174:101::1337...
Connected to reader.ipv6.xsnews.nl.
Escape character is '^]'.
500 Thank you for testing IPv6. XSNews now offers IPv6 on all packages. Register now at www.xsnews.com use code ipv6tester to get a 30% discount on a year account!
Connection closed by foreign host.

Straks es vergelijken wat we gaan nemen.

[Snow_King]

Ik hoorde dat UPC, KPN en Ziggo idd zijn begonnen met de IPv6 uitrol. In 2015 moet 60% van de klanten via IPv6 kunnen internetten.

Twee problemen:
- Oude routers bij klanten
- Websites waar AAAA-record niet van klopt.

IPv6 zelf werkt prima, maar het is de boel er omheen.

[Verwijderd]

Snow_King schreef op maandag 01 december 2014 @ 13:21:
- Websites waar AAAA-record niet van klopt.

Daar zijn wat initiatieven voor, zoals contact met overkoepelende organisaties voor ISP's. Tevens is er een check gedaan op NL domein namen door iemand bij sidn. Misschien dat daar nog iets uit te automatiseren valt qua rapportage / maandelijkse checks.

Hoe kleiner de site, des te minder mensen hebben er last van. Bij grote sites zijn ze vaak ook op twitter te vinden en dan is een berichtje zo gestuurd. Zo zijn er dit weekend al wat sites gefixed.

[Raven]

Tomsworld schreef op maandag 01 december 2014 @ 11:26:
Blijkbaar is de free xsnews server via ipv6 ook afgelopen.


[...]


Straks es vergelijken wat we gaan nemen.

Oud nieuws volgens mij Osiris in "Het grote IPv6 topic"

[Verwijderd]

Snow_King schreef op maandag 01 december 2014 @ 13:21:
- Oude routers bij klanten

Ik zie dat als een kort durend probleem, waar voor IPv6 vaak geen business case is, is dat er wel voor docsis 3 modems omdat er dan meer bandbreedte beschikbaar komt.

Docsis 3 heeft als vereiste IPv6 ondersteuning. Oude routers worden tzt vervangen wat mogelijk nog door de provider wordt geinitieerd. Denk niet dat het voor het gros (de 90%) nog langer dan een jaar zal duren voordat er modems/routers staan die IPv6 in iedergeval aan kunnen.

[Snow_King]

Verwijderd schreef op maandag 01 december 2014 @ 14:24:
[...]


Ik zie dat als een kort durend probleem, waar voor IPv6 vaak geen business case is, is dat er wel voor docsis 3 modems omdat er dan meer bandbreedte beschikbaar komt.

Docsis 3 heeft als vereiste IPv6 ondersteuning. Oude routers worden tzt vervangen wat mogelijk nog door de provider wordt geinitieerd. Denk niet dat het voor het gros (de 90%) nog langer dan een jaar zal duren voordat er modems/routers staan die IPv6 in iedergeval aan kunnen.

Klopt, is ook zo. Maar genoeg mensen hebben weer eigen routers er tussen zitten en die zijn het probleem.

Daarom doelen ze op 60% in 2015. Het netwerk is er klaar voor, dan de CPE's nog.

[Maurits van Baerle]

Snow_King schreef op maandag 01 december 2014 @ 13:21:
Ik hoorde dat UPC, KPN en Ziggo idd zijn begonnen met de IPv6 uitrol. In 2015 moet 60% van de klanten via IPv6 kunnen internetten.

Als in dat ze vanochtend zijn begonnen omdat het 1 december is? Dat zou nog best wel eens kunnen, het is een logische datum vanuit projectmanagement gezien. Even de AMS-IX statistieken in de gaten houden...

Snow_King schreef op maandag 01 december 2014 @ 14:28:
[...]
Klopt, is ook zo. Maar genoeg mensen hebben weer eigen routers er tussen zitten en die zijn het probleem.

Daarom doelen ze op 60% in 2015. Het netwerk is er klaar voor, dan de CPE's nog.

Weet je, ik denk dat dat nog best wel eens mee kan vallen. 2012 was het-jaar-van-IPv6-in-de-consumenten-router toen vrijwel alle consumentenmerken standaard IPv6 in hun spul begonnen te leveren. Vrijwel iedereen die sinds 2012 een router heeft gekocht of sindsdien een firmware update heeft gedraaid (of gepusht heeft gekregen) heeft IPv6 ondersteuning. Vaak zonder het te weten. Het zou me niets verbazen als 30% van de installed base nu al standaard op een Prefix Delivery staat te wachten.

[Snow_King]

Maurits van Baerle schreef op maandag 01 december 2014 @ 16:13:
[...]

Als in dat ze vanochtend zijn begonnen omdat het 1 december is? Dat zou nog best wel eens kunnen, het is een logische datum vanuit projectmanagement gezien. Even de AMS-IX statistieken in de gaten houden...

Ik vernam dit uit Vereniging ISPConnect. Het is niet zo zeer 1 december, maar ze zijn inmiddels langzaam bezig.

Maurits van Baerle schreef op maandag 01 december 2014 @ 16:13:

Weet je, ik denk dat dat nog best wel eens mee kan vallen. 2012 was het-jaar-van-IPv6-in-de-consumenten-router toen vrijwel alle consumentenmerken standaard IPv6 in hun spul begonnen te leveren. Vrijwel iedereen die sinds 2012 een router heeft gekocht of sindsdien een firmware update heeft gedraaid (of gepusht heeft gekregen) heeft IPv6 ondersteuning. Vaak zonder het te weten. Het zou me niets verbazen als 30% van de installed base nu al standaard op een Prefix Delivery staat te wachten.

Laten we vooral hopen dat ze hoger dan 60% deployment uit gaan komen in 2015.

Dit nieuws klinkt in ieder geval al goed.

[Roetzen]

Snow_King schreef op maandag 01 december 2014 @ 16:50:

Dit nieuws klinkt in ieder geval al goed.

Het klinkt inderdaad goed. Maar ja, dat klonk het vijf jaar geleden ook toen ze zeiden dat het "einde dit jaar, begin volgend jaar" uitgerold zou worden.

Dus eerst zien, dan geloven. Laat de eerste Tweaker die spontaan IPv6 ziet verschijnen zich melden...

Ik vrees overigens dat ik voorlopig nog niet aan de beurt ben. Omdat ik bij Ziggo de laagst mogelijke snelheid heb. (30/3) is er geen aanleiding mijn oude Motorola SVB te vervangen. 30 MBps download kan ie nog wel aan.

[Snow_King]

ZeelandNet heeft het in ieder geval overal aan gezet: https://twitter.com/marti...status/539883990032084992

Nog wel een MAC Adres filtering voor bepaalde vendors zo te zien, maar als je de juiste router hebt staat het aan

[Maurits van Baerle]

De voorwaarden waar een CE/Router aan moet voldoen:

• De CE/router moet IPv6 standaard ingeschakeld hebben
• Het apparaat moet online komen middels de gebruikte standaard in ons netwerk. (DHCPv6 + PD)
• De IPv6 firewall moet standaard ingeschakeld zijn

De huidige "goedgekeurde" lijst:
20:aa:4b:* | Cisco-linksys
48:f8:b3:* | Cisco-linksys
58:6d:8f:* | Cisco-linksys
c8:b3:73:* | Cisco-linksys
c8:d7:19:* | Cisco Consumer products
b4:75:0e:* | Belkin
6c:70:9f:* | Apple
90:72:40:* | Apple
b8:8d:12:* | Apple
Whitelisting middels DUID in combinatie met mac-vendor

http://www.ipv6.zeelandnet.nl/testing/

Wel netjes geregeld, zeker dat de firewall standaard aan moet staan. Zouden ze dat testen of zouden ze afgaan op of het standaard aan staat bij de apparaten op hun whitelist? Jammer dat de whitelist nog klein is.

Ik zie overigens een lichte maar consistente groei bij het AMS-IX IPv6 verkeer de laatste paar dagen. Die gaat waarschijnlijk vandaag nog door de 44 Gbps heen.

[Verwijderd]

Maurits van Baerle schreef op woensdag 03 december 2014 @ 14:18:
[...]
Ik zie overigens een lichte maar consistente groei bij het AMS-IX IPv6 verkeer de laatste paar dagen. Die gaat waarschijnlijk vandaag nog door de 44 Gbps heen.

Zo 08-12-14 45,4
Ma 09-12-14 47,9
Di 10-12-14 45

2 Weken geleden tipte het af en toe 40Gb aan, dit lijkt wel structureel. Jammer dat niet in te zien is wie / wat dit veroorzaakt.

Ik zie op een van mijn webservers een bezoek van http://bgp.he.net/net/2001:1c00::/23 (ziggo) gisteren. Misschien dat ze hun trial weer gestart zijn.

[databeestje]

Verwijderd schreef op woensdag 10 december 2014 @ 07:36:
[...]


Zo 08-12-14 45,4
Ma 09-12-14 47,9
Di 10-12-14 45

2 Weken geleden tipte het af en toe 40Gb aan, dit lijkt wel structureel. Jammer dat niet in te zien is wie / wat dit veroorzaakt.

Ik zie op een van mijn webservers een bezoek van http://bgp.he.net/net/2001:1c00::/23 (ziggo) gisteren. Misschien dat ze hun trial weer gestart zijn.

Zou best kunnen
src-error.log:[Wed Dec 10 08:33:34 2014] [error] [client 2001:1c00:13:7800:7044:1706:4281:b9b1] File does not exist: /var/www/src/favicon.ico

/var/log/apache2# grep 2001:1c * |wc -l
14

Allemaal van vandaag.

[Verwijderd]

Test van SIDN over sites met incorrecte IPv6 configuratie:
https://www.sidnlabs.nl/l...problematiek-op-websites/

[Jaap-Jan]

Hebben ze die laatste URL nou willen blurren of niet.

[Maurits van Baerle]

Overigens best een interessant punt dat hij maakt dat IP6.nl geen vijf sterren zou moeten geven als een site wel een AAAA IPv6 entry heeft maar toch eigenlijk niet werkt omdat de site erachter niet goed geconfigureerd is of het AAAA record naar de verkeerde site wijst.

[Verwijderd]

Maurits van Baerle schreef op donderdag 11 december 2014 @ 11:56:
Overigens best een interessant punt dat hij maakt dat IP6.nl geen vijf sterren zou moeten geven als een site wel een AAAA IPv6 entry heeft maar toch eigenlijk niet werkt omdat de site erachter niet goed geconfigureerd is of het AAAA record naar de verkeerde site wijst.

Het zou kunnen dat IP6.nl kijkt naar een valide HTTP response. Misschien alleen DNS record. Indien het eerste dan zou het al een deel afvangen en zou het misschien kunnen worden uitgebreid dat de response size binnen bepaalde grenzen gelijk is als de response over Ipv4.

Vooralsnog lijkt me dat nog wat overkill, het onderzoek van SIDN zal meer zoden aan de dijk zetten omdat er actief gekeken wordt naar mis-configuraties, waarbij IP6.nl alleen kijkt naar sites die door iemand worden opgegeven.

[Maurits van Baerle]

Ja, ik weet ook niet of IP6.nl veel energie moet stoppen in het aanpassen van hun methodiek. Ik denk sowieso dat dit probleem binnen een jaar amper nog bestaat. Als er, met het recente KPN/ZIGGO/UPC nieuws, over zes maanden pak-em-beet 2 miljoen Nederlanders over IPv6 surfen dan worden dit soort dingen snel genoeg ontdekt (en serieus genomen door betreffende bedrijven).

[Osiris]

020wonen.nl heeft hun 'probleem' nu al aangepast. Zowel IPv6 als IPv4 verwijzen nu naar 020makelaars.nl.

Even aangenomen dat ik "20w" goedgegokt heb onder het geblurde

[Maurits van Baerle]

Ah, het eerste waar ik aan dacht was vtwonen.nl...

[Verwijderd]

Maurits van Baerle schreef op donderdag 11 december 2014 @ 14:31:
(en serieus genomen door betreffende bedrijven).

Behalve..................... Alkmaar.nl ondanks berichten via twitter.

[Verwijderd]

nieuws: UPC stelt uitrol ipv6 uit

Dat was te verwachten. Jammer.

[St00mwals]

Verwijderd schreef op donderdag 18 december 2014 @ 12:17:
nieuws: UPC stelt uitrol ipv6 uit

Dat was te verwachten. Jammer.

Omdat het een groot en complex proces is...

Ze zijn dus gewoon te laat begonnen, sukkels.

Ben benieuwd wat Ziggo nu gaat doen. Als die ook uit gaan stellen verbaast het me niks dat de overname er al iets mee te maken zal hebben.

[ Voor 18% gewijzigd door St00mwals op 18-12-2014 12:36 . Reden: Stukje over Ziggo toegevoegd ]

[Snow_King]

St00mwals schreef op donderdag 18 december 2014 @ 12:27:
[...]

Omdat het een groot en complex proces is...

Ze zijn dus gewoon te laat begonnen, sukkels.

Ben benieuwd wat Ziggo nu gaat doen. Als die ook uit gaan stellen verbaast het me niks dat de overname er al iets mee te maken zal hebben.

Inderdaad, geen andere woorden voor. Ze zijn gewoon te laat begonnen en nu is het ineens allemaal erg moeilijk.

Keiharde faal dus.

[Olaf van der Spek]

Zijn ze uberhaupt al begonnen?
Hebben ze wel tunnel servers trouwens?

[Verwijderd]

UPC is bezig met het testen, met testen komen dingen naar voren. Liever deze eerst optelossen dan een uitrol die issues meebrengt.

[Roetzen]

Verwijderd schreef op donderdag 18 december 2014 @ 13:17:
UPC is bezig met het testen, met testen komen dingen naar voren. Liever deze eerst optelossen dan een uitrol die issues meebrengt.

Op zich wel waar, maar dat neemt niet weg dat ze gewoon te laat begonnen zijn. Dat testen hadden ze vijf jaar geleden moeten doen, dan waren nu de kinderziektes er uit.

[Verwijderd]

Roetzen schreef op donderdag 18 december 2014 @ 13:58:
[...]

Op zich wel waar, maar dat neemt niet weg dat ze gewoon te laat begonnen zijn. Dat testen hadden ze vijf jaar geleden moeten doen, dan waren nu de kinderziektes er uit.

Helemaal mee eens.

Het is helaas niet anders, maar ook ik test mee dus zit er bovenop. Hoe graag ik ook zou starten met de uitrol, het is op dit moment nog geen goed plan.

[Maurits van Baerle]

Toen het begin december nog niet operationeel was hadden we dat natuurlijk wel aan kunnen zien komen. Als grote ISP ga je natuurlijk niet vlak voor de feestdagen nog even zo'n ingrijpende wijziging doorvoeren voor al je klanten. Vlak voor een periode waarop je klanten thuis waarschijnlijk meer gebruik gaan maken van internet terwijl je eigen support medewerkers en je leveranciers waarschijnlijk op een lagere feestdagenbezetting zitten.

Wat dat betreft doe je het ofwel begin december of pas weer ergens in januari. Daarom is het niet ondenkbaar dat het ergens begin volgend jaar wel lukt. Ik vind het jammer dat ze het niet hebben gehaald maar zo somber hoeven we het (voorlopig) nog niet in te zien. Ze zijn in ieder geval bezig met testen bij echte klanten, dat is al heel wat als je naar de geschiedenis van UPC en IPv6 kijkt.

[CAPSLOCK2000]

Roetzen schreef op maandag 01 december 2014 @ 17:09:
Dus eerst zien, dan geloven. Laat de eerste Tweaker die spontaan IPv6 ziet verschijnen zich melden...

nubro01 in 'nieuws: UPC stelt uitrol ipv6 uit'

Maurits van Baerle schreef op donderdag 18 december 2014 @ 14:48:
Wat dat betreft doe je het ofwel begin december of pas weer ergens in januari. Daarom is het niet ondenkbaar dat het ergens begin volgend jaar wel lukt. Ik vind het jammer dat ze het niet hebben gehaald maar zo somber hoeven we het (voorlopig) nog niet in te zien. Ze zijn in ieder geval bezig met testen bij echte klanten, dat is al heel wat als je naar de geschiedenis van UPC en IPv6 kijkt.

Volgens het artikel zijn ze nog niet eens begonnen met een planning te maken. Ik zit het ook in 2015 dus niet gebeuren. Dan vrees ik dat de fusie met Ziggo ook nog eens prioriteit gaat krijgen. Het samenvoegen van de netwerken en achterliggende systemen zal wel alle beschikbare capacitiet opslokken en er moeten vast ook nog wat mensen ontslagen worden om geld te besparen.

[ Voor 54% gewijzigd door CAPSLOCK2000 op 18-12-2014 21:37 ]

[Osiris]

Die heeft vast een link-local of Teredo-adresje op z'n OS-je staan

[Verwijderd]

CAPSLOCK2000 schreef op donderdag 18 december 2014 @ 21:33:
Volgens het artikel zijn ze nog niet eens begonnen met een planning te maken. Ik zit het ook in 2015 dus niet gebeuren. Dan vrees ik dat de fusie met Ziggo ook nog eens prioriteit gaat krijgen. Het samenvoegen van de netwerken en achterliggende systemen zal wel alle beschikbare capacitiet opslokken en er moeten vast ook nog wat mensen ontslagen worden om geld te besparen.

Ik denk dat ze nu voorzichtig met datums zijn, echter ze werken er wel aan. In het nieuwsbericht las ik een reactie van iemand met UPC en IPv6 in Oostenrijk. Verwijderd in 'nieuws: UPC stelt uitrol ipv6 uit' Deze heeft een modem gelijk aan in de UPC NL IPv6 test.

Blijkbaar is voor/door UPC Oostenrijk deze modem al wel goed bevonden en hier in NL niet. Hieruit zou je kunnen opmaken dat de gewenste veranderingen aan het modem in NL dermate belangrijk zijn dat ze deze eerst willen doorvoeren.

Je zou nog kunnen speculeren dat op basis van de uitrol in Oostenrijk er mogelijk door sommigen (binnen UPC) te snel is aangenomen "dan kan het hier nu ook".

Als je kijkt naar de Fritzbox van Xs4all, dan zijn daar ook nog wat zaken die je graag zou zien maar die er nog niet zijn.

Met IPv6 zou je gezien de mogelijkheden juist wat meer je netwerken willen scheiden, ook thuis, zoals in een gast-wifi, prive reeks voor je thuis pc / nas enzovoort.

Met een Fritzbox / Xs4all kun je wel IPv6 prefix-delegation doen maar dit dicteerd wel hoe je subnet genummerd wordt. Je kunt bijvoorbeeld niet zelf een statische route aanmaken.

Het is in de firewal wel mogelijk om een poort naar een adres te openen, mits dit adres in het default subnet van de fritzbox zit. Als je met prefix-delegation een eigen subnet start (Bv omdat je een eigen firewall wilt gebruiken) dan kun je in de Fritzbox daar geen poort voor openen. Ik weet niet of je de firewall als geheel kunt uitschakelen.

[ Voor 24% gewijzigd door Verwijderd op 19-12-2014 05:58 ]

[Verwijderd]

Sinds kort heb ik een IPv6 tunnel van HE in gebruik en die was opvallend makkelijk op te zetten in een recente build van DD-WRT. Die heeft tegenwoordig een eigen Setup > IPV6 tabblad, vlak naast Basic Setup, en simpelweg de adresblokken copy-pasten vanuit de HE website naar de juiste velden was voldoende. DDNS garandeert vervolgens een ononderbroken service.

IPv6 begint eindelijk wat meer vorm te krijgen binnen de DD-WRT interface. Ik ben geen wizkid en al die regels code om routers en firewalls in te stellen gaan al snel dansen voor mijn ogen. Ik snap het concept maar een relatief eenvoudige click-and-go manier bevalt mij wel. Ik hoop dan ook dat DD-WRT en andere routersoftware straks zover evolueert dat je heel makkelijk in de interface met /48, /56 en /64 onderverdelingen aan de slag kunt zonder het overzicht kwijt te raken. Niet dat ik dat thuis allemaal direct nodig heb maar het gaat om het principe. Het wat serieuzere IPv6 beheer zit nu nog in de command line verstopt.

Het valt me op hoe makkelijk alle devices in huis IPv6 oppakken. Apart om te te zien dat de consument er qua gebruiks-devices eigenlijk allang klaar voor is. Alleen de mediaplayer thuis ondersteunt geen IPv6. De Windows en Android devices doen het meteen goed. Nu inderdaad de ISP nog...

Omdat IPv4 en IPv6 in principe prima naast elkaar kunnen bestaan zonder elkaar in de weg te zitten dacht ik altijd dat invoering van v6 niet bijster lastig zou zijn. Blijkbaar kampen ISP's toch met tegenslag. Kan iemand vanuit een professioneel oogpunt eens beschrijven wat die knelpunten precies zijn? Want dit stukje achtergrondinformatie blijft in de berichtgeving meestal achterwege. Dat de v4-adressen opraken weten we inmiddels wel. Maar als IPv6 dat in principe zo eenvoudig oplost waarom is het dan niet allang wereldwijd in gebruik? Even los van het feit dat consumentenrouters het vaak nog niet ondersteunen maar die hebben er ook geen last van dus dat kan geen reden zijn.

En waarom is deze site eigenlijk nog niet via IPv6 bereikbaar? Uitgerekend tweakers zou je toch anders van verwachten...

[ Voor 5% gewijzigd door Verwijderd op 19-12-2014 21:13 ]

[Raven]

Delen van Tweakers zijn via IPv6 bereikbaar, maar niet alles nog geloof ik.

edit: Zie ook Verwijderd in "Het grote IPv6 topic"

Verwijderd schreef op vrijdag 04 januari 2013 @ 21:09:
Is iemand http://ipv6.tweakers.net al opgevallen

In hosts bestand (onder windows) volgende regels toegevoegd, lijkt tot nog toe goed te werken.

code:

2001:990:6:31::140  tweakers.net
2001:990:6:31::140  gathering.tweakers.net
2001:990:6:31::141  ic.tweakers.net
2001:990:6:31::142  vc.tweakimg.net
2001:990:6:31::143  tweakimg.net
2001:990:6:31::144  ic.tweakimg.net

[ Voor 95% gewijzigd door Raven op 19-12-2014 21:14 ]

[Verwijderd]

Ok. Is er dan een reden waarom de reguliere domeinnamen nog niet als AAAA records zijn ingesteld?

[Verwijderd]

Verwijderd schreef op vrijdag 19 december 2014 @ 22:01:
Ok. Is er dan een reden waarom de reguliere domeinnamen nog niet als AAAA records zijn ingesteld?

Die uitleg is ergens in dit topic verstopt, ik meen door Kees. Was iets met dat nog niet alle code zover is of mogelijk dat niet alle rapportage (statistieken) zover zijn waardoor ze nog niet grote(re) aantallen over ipv6 willen hebben.

[Raven]

@2fish: leesvoer: IPv6

[ Voor 57% gewijzigd door Raven op 20-12-2014 16:03 ]

[St00mwals]

Zal het dan toch (een van) de reden zijn???

nieuws: Ziggo en UPC beginnen voorzichtig met fuseren diensten

[Verwijderd]

Een kleine praktische vraag. Ik heb al enige tijd een 6in4 tunnel van HE open staan. Die werkt tot dusver bijzonder goed. Echter zag ik dat utorrent geen verbinding maakt met IPv6 clients. Teredo heb ik niet aanstaan omdat me dat met een 6in4 tunnel overbodig lijkt. De adapter krijgt gewoon een v6 adres en ik kan prima met v6 hosts op het internet verbinden. Waarom werkt het dan niet in utorrent?

[Raven]

uTorrent doet het hier perfect via een HE tunnel en daar heb ik helemaal niets voor hoeven doen , zie gewoon IPv6 seeds/peers verschijnen.

[ Voor 17% gewijzigd door Raven op 28-12-2014 22:07 ]

[LauPro]

Wel een kanttekening voor mensen die IPv6 via een tunnel gebruiken: Het kan je internetervaring hopeloos traag maken. Ik heb bij een aantal tests gemerkt dat er vaak geknepen wordt op zo'n tunnel en dat het aanzienlijk trager is dan direct op IPv4. Ook bijv. DNS-lookups worden vertraagd, wat bijvoorbeeld de snelheidsbeleving in een browser niet ten goede komt. Zeker als je bijvoorbeeld 200 Mbit hebt, dan ga je nooit 200 Mbit via zo'n tunnel halen, misschien 20-50 Mbit - vaak nog lager.

Bovendien blijft het een extra laag over je IPv4 verbinding, en is IPv6 inherent ook al iets trager omdat je meer headerdata verstuurt (64 bit addressen ipv 32 bit).

Eigenlijk zijn de IPv6-tunnels en POP's niet echt een oplossing. Het is leuk om mee te experimenteren maar ik ga niet met allemaal hoge pings werken.

Het is echt zaak dat providers dit gaan aanbieden. En wat dat betreft is het een kip-ei verhaal. Veel websites zijn nog niet IPv6 omdat ze nauwelijks publiek hebben en omdat IPv4 leidend is zit er her en der ook nog wel eens een foute config wat de algehele IPv6-ervaring niet beter maakt.

Toch blijf ik er bij dat een 'technologiewebsite' hierin voorop moet lopen . Is er nog een update jongens?

[Raven]

LauPro schreef op maandag 29 december 2014 @ 12:39:
Toch blijf ik er bij dat een 'technologiewebsite' hierin voorop moet lopen . Is er nog een update jongens?

Daar vroeg ik laatst in het MF-topic nog naar Raven in "IPv6"

Helaas geen antwoord.

[ Voor 3% gewijzigd door Raven op 29-12-2014 13:23 ]

[Verwijderd]

@LauPro je hebt natuurlijk helemaal gelijk. Het is ook niet meer dan een experiment. Ik heb net even IPv6 uitgezet en o.a. Google reageert meteen een stuk sneller. De ping naar google.com is ook minimaal 100 ms lager.

Maar hoe meer ik me bewust word van IPv6 des te minder ik begrijp waarom dit zoveel vertraging oploopt. Dat de IPv4-adressen opdrogen is een aardige stok achter de deur maar wellicht niet eens de belangrijkste reden om over te stappen. Het feit dat we NAT ermee de nek kunnen omdraaien is denk ik nog veel belangrijker. Het maakt een point-to-point internet, zoals het altijd bedoeld is, voor de hele wereld mogelijk. Ik begrijp dat het aanzetten van IPv6 nogal wat planning vergt voor ISP's e.d. maar als ze daar nu eens 5 jaar geleden al massaal mee waren begonnen dan waren de kinderziektes er allang uitgeweest. En van een iets andere invalshoek zou je zelfs kunnen beargumenteren dat het vertraagd invoeren slechte klantenservice is. Slecht omdat NAT voor problemen kan zorgen voor o.a. VoIP-toepassingen en slecht omdat een enkelvoudig, vaak dynamisch IP-adres nogal karig is.

En inderdaad, kom op tweakers met jullie IPv6 site. Want als zelfs een van dé tech sites van Europa het ondanks de uitdagingen nog steeds niet voor elkaar heeft, hoe kunnen we dan verwachten dat andere sites het wél kunnen?

[Keiichi]

Verwijderd schreef op maandag 29 december 2014 @ 17:34:
En inderdaad, kom op tweakers met jullie IPv6 site. Want als zelfs een van dé tech sites van Europa het ondanks de uitdagingen nog steeds niet voor elkaar heeft, hoe kunnen we dan verwachten dat andere sites het wél kunnen?

Misschien omdat er een commercieel belang is van mensen die zekerheid van inkomsten boven nieuwe techniek stellen?

Ik denk zodra er een punt is dat als je door geen IPv6 te hebben, inkomsten misloopt, dat het dan heel hard gaat

[Osiris]

LauPro schreef op maandag 29 december 2014 @ 12:39:
Bovendien blijft het een extra laag over je IPv4 verbinding, en is IPv6 inherent ook al iets trager omdat je meer headerdata verstuurt (64 bit addressen ipv 32 bit).

Euh, een IPv6-adres is 128 bits groot hè..

LauPro schreef op maandag 29 december 2014 @ 12:39:
Eigenlijk zijn de IPv6-tunnels en POP's niet echt een oplossing. Het is leuk om mee te experimenteren maar ik ga niet met allemaal hoge pings werken.

Ligt eraan waarvoor 't als 'oplossing' dient te fungeren. Standaard IPv6-implementatie? Natuurlijk niet.. Bij gebrek aan beter, sure, why not?

En die pings, euh, kweenie hoor.. 6,0 ms average naar ping.xs4all.nl, 6,7 ms average naar POP endpoint (SurfNet). Wauw, wat een verschil

[ Voor 6% gewijzigd door Osiris op 29-12-2014 21:14 ]

[Brahiewahiewa]

Verwijderd schreef op maandag 29 december 2014 @ 17:34:
@LauPro je hebt natuurlijk helemaal gelijk. Het is ook niet meer dan een experiment. Ik heb net even IPv6 uitgezet en o.a. Google reageert meteen een stuk sneller. De ping naar google.com is ook minimaal 100 ms lager...

Merkwaardig:

C:\Users\Brahiewahiewa>ping -4 google.com

Pinging google.com [173.194.65.139] with 32 bytes of data:
Reply from 173.194.65.139: bytes=32 time=14ms TTL=49
Reply from 173.194.65.139: bytes=32 time=15ms TTL=49
Reply from 173.194.65.139: bytes=32 time=21ms TTL=49
Reply from 173.194.65.139: bytes=32 time=15ms TTL=49

Ping statistics for 173.194.65.139:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 14ms, Maximum = 21ms, Average = 16ms

C:\Users\Brahiewahiewa>ping -6 google.com

Pinging google.com [2a00:1450:4013:c01::71] with 32 bytes of data:
Reply from 2a00:1450:4013:c01::71: time=16ms
Reply from 2a00:1450:4013:c01::71: time=16ms
Reply from 2a00:1450:4013:c01::71: time=16ms
Reply from 2a00:1450:4013:c01::71: time=16ms

Ping statistics for 2a00:1450:4013:c01::71:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 16ms, Maximum = 16ms, Average = 16ms

Ook via hurricane

[Verwijderd]

^ Ik ben hier in ZO Azië en de tunnel server staat over de grens. Desondanks vind ik het verschil in pingtijd wel groter dan verwacht. Opvallend dat IPv6 bij jou juist sneller is.

[ Voor 14% gewijzigd door Verwijderd op 29-12-2014 22:09 ]

[LauPro]

Ligt er wel aan waar je heen pingt met IPv6. Het kan best zijn dat het IPv6 verkeer via een andere (snellere) route loopt dan IPv4, als er bijvoorbeeld veel hops zijn. IPv6 is makkelijker te routen uiteindelijk.

Het kiezen van de juiste POP is zeer belangrijk!

[Verwijderd]

HE heeft in Azië alleen POPs in Hong Kong, Singapore en Japan. Vrij karig voor zo'n groot continent. De meeste dichtbevolkte gebieden liggen niet eens in de buurt.

Ik ping naar google.com.

[CAPSLOCK2000]

LauPro schreef op maandag 29 december 2014 @ 12:39:
Wel een kanttekening voor mensen die IPv6 via een tunnel gebruiken: Het kan je internetervaring hopeloos traag maken. Ik heb bij een aantal tests gemerkt dat er vaak geknepen wordt op zo'n tunnel en dat het aanzienlijk trager is dan direct op IPv4. Ook bijv. DNS-lookups worden vertraagd, wat bijvoorbeeld de snelheidsbeleving in een browser niet ten goede komt. Zeker als je bijvoorbeeld 200 Mbit hebt, dan ga je nooit 200 Mbit via zo'n tunnel halen, misschien 20-50 Mbit - vaak nog lager.

Hier herken ik niet veel van. Mijn sixxs-tunnel kan mijn 180Mbit verbinding probleemloos verzadigen en pings gaan via IPv6 regelmatig sneller dan IPv4. DNS kan ik niet zeggen, dat host ik lokaal, maar alle grote DNS-servers ondersteunen IPv6, volgens mij is dat probleem al lang niet meer relevant.

[alm]

Verwijderd schreef op dinsdag 30 december 2014 @ 20:49:
Ik ping naar google.com.

Dat zegt niet zoveel, google.com wijst naar verschillende IP-adressen en is afhankelijk waar je vandaan komt. Google zit wereldwijd en je gaat meestal naar het dichtstbijzijnde of snelst bereikbare serverpark.

Als de DNS die je gebruikt wel AAAA records teruggeeft (dus naar IPv6 adressen wijst), dan zijn dat meestal adressen die naar lokale servers wijzen. Als jouw tunnel via HE loopt en zij hun verkeer via hun hoofd-locatie laten lopen dan loopt jouw verkeer via een langere weg naar die server...

Dit zou een verklaring kunnen zijn van het verschil tussen IPv4 en IPv6 in jouw geval.

[Verwijderd]

^ Hier wordt echter Google's clouddienst veelvuldig gebruikt. Zelfs de new tab page in Chrome laadt sneller als IPv6 uit staat. De route via IPv6 zal inderdaad een stuk langer zijn. Vermoedelijk heeft Google in de meeste landen wel servers staan.

Voor zowel IPv4 als IPv6 worden de Open DNS servers gebruikt dus zowel 208.67.222.222 en 208.67.220.220 als 2620:0:ccc::2 en 2620:0:ccd::2.

[Verwijderd]

Verwijderd schreef op maandag 29 december 2014 @ 22:08:
^ Ik ben hier in ZO Azië en de tunnel server staat over de grens. Desondanks vind ik het verschil in pingtijd wel groter dan verwacht. Opvallend dat IPv6 bij jou juist sneller is.

Ik zie dagelijks tientallen traceroutes van willekeurige sources en destinations over IPv6 van allerlei gebruikers en isp's. Er zijn diverse situaties die ver van optimaal zijn.

* Traceroutes waarbij de source of destination achter een tunnel zit waardoor de route bounced (europa / amerika / europa / amerika) of dat men door grote providers via een ander continent wordt gerouted.

* ISP's die op een locatie zelf veel latency toevoegen door het gebruik (vermoedelijk) van een translation devices om binnen hun eigen netwerk IPv4 only devices te overbruggen.

* Latency door tunnels, routes van/naar asie die het pad maskeren waardoor niet zichtbaar is wat er gebeurd.

[Raven]

Hmm, Google opent ineens niet meer via IPv6 hier (blijft maar laden), andere IPv6 sites werken wel

http://test-ipv6.com/ heeft het over MTU-issues, geen flauw idee hoe ik dat moet troubleshooten bij mijn HE-tunnel die tot nu toe probleemloos heeft gewerkt

edit: Wat geGoogleBing() later:

code:

ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

lijkt het opgelost te hebben, nadat ik dit zag op http://test-ipv6.com/ :

LET OP! IPv6 werkt een beetje, maar grote pakketten lijken niet aan te komen, waardoor websites stuk kunnen lijken te zijn als deze IPv6 gebruiken. Vraag uw ISP over MTU problemen, mogelijk gerelateerd aan uw tunnel. Check your firewall to make sure that ICMPv6 messages are allowed (in particular, Type 2 or Packet Too Big).

[ Voor 56% gewijzigd door Raven op 03-01-2015 10:41 ]

[Ultraman]

Toevallig dat ik hier kijk en ook net heb gemerkt dat Google (Search) niet werkt. Bij mij klaagt test-ipv6.com niet over MTU en geeft alles groen, behalve ISP DNS IPv6 en dat ik een tunnel gebruik.
Maar ik kan bevestigen dat Google nu even niet werkt over IPv6. Lijkt mij dan ook niet dat je direct het probleem bij jezelf dient te zoeken in dit geval.

[edit]
En nu werkt het ineens wel hier

[ Voor 8% gewijzigd door Ultraman op 03-01-2015 10:46 ]

[Raven]

Het was niet alleen Google, Facebook en HE.net gaven even later hetzelfde probleem. Maar wel apart dat het na het invoeren van die ip6tables regels meteen weer werkt

[ Voor 20% gewijzigd door Raven op 03-01-2015 10:58 ]

[Snow_King]

Ik ving net wat op over KPN, ze zijn op de achtergrond wel met migraties bezig om IPv6 mogelijk te maken.

Ze hadden nog wat uitdagingen met apparatuur die er moeite mee had. Er wordt aan gewerkt, maar ik ving echt maar even een kort stukje van de conversatie op. Verder niet door gevraagd.

[databeestje]

Aankomende februari volgens de laatste geruchten voor de dual stack bgp peering in aanbouw.

Van dual stekker naar dual stack.

[Maurits van Baerle]

databeestje schreef op woensdag 14 januari 2015 @ 22:12:
Aankomende februari volgens de laatste geruchten voor de dual stack bgp peering in aanbouw.

Van dual stekker naar dual stack.

KPN is de aanbieder waar het voor mij het onduidelijkst is. Ik neem aan dat ze voor zakelijke klanten al IPv6 kunnen bieden. Hun dochter XS4ALL kan het ook al tijden voor consumenten. Is het KPN gedeelte dat direct aan consumenten verkoopt (dus niet wholesale) het enige wat nog niet klaar is? Waar ligt dat dan aan?

[databeestje]

Goede vraag, hier heb ik helaas geen inzicht in, voor ons betreft het een Corporate Internet glas verbinding waar het om draait. We gebruiken nu al bijna 2 jaar de IPv6 Pilot verbinding, echter, deze maakt verbinding met het Eurorings netwerk van de KPN.

Zoals het er nu naar uit ziet wordt in februari onze IPv4 Corporate internet aangepast met IPv6 addressen voor de IPv6 BGP peering. Lijkt simpel maar is het niet, we gaan van het Eurorings netwerk naar het KPN NL netwerk.

Ik weet van de IP-Office van de KPN dat deze al 2 jaar IPv6 netwerk blokken reserveren voor alle diensten, inclusief consumenten in afwachting van de leverstraat en infra om deze aan de klant te leveren. Het protocol dat er gevolgd wordt klopt zondermeer, maar de voortgang ervan is slecht in te schatten.

XS4ALL is wel een dochter bedrijf maar is technisch volledig gescheiden, vanaf de wijkcentrale begint deze al. Dat is dus de DSLAM voor de meeste klanten. Vanaf daar gaat het direct de eigen XS4ALL backbone op naar hun datacenter. Dit betekent dat er gewoon zoveel meer vrijheid is om andere services te implementeren, dat is niet grappig.

Door een veel minder sterke drang om per kwartaal te opereren zoals veel ondernemingen met aandeelhouders is er daadwerkelijk een lange termijn plan dat uitgevoerd wordt. Veel minder bureaucratische lagen. Leuke club, aardige mensen op het hoofdkantoor. Ze weten echt waar ze het over hebben.

[tcviper]

Hallo all, sinds vandaag via Ziggo zakelijk nu Internet Plus Extra geactiveerd thuis en tot nu toe werkt alles perfekt. Nu is het zo dat mijn Cisco RV325 router kan werken via SLAAC of een Statisch WAN IP met daarbij Configure to RA and DHCPv6 automatically of alleen DHCPv6 of alleen RA.

Op dit moment doe ik dus statisch en daarbij DHCPV6, alle lan apparaten krijgen netjes een IP (binnen de range) en ik kan natuurlijk handmatig een statisch IPV6 instellen voor static apparaten.

However, ik lees ook veel over SLAAC en hoeveel makkelijker dat is vnl in combinatie met DHCPV6. Is dat iets wat jullie aanraden om te gebruiken of SLAAC absoluut niet gebruiken?

Overigens voor degene die het willen weten ze rollen standaard met /64 uit.

Bvd

[ Voor 5% gewijzigd door tcviper op 15-01-2015 16:09 ]

[Snow_King]

tcviper schreef op donderdag 15 januari 2015 @ 16:01:
Hallo all, sinds vandaag via Ziggo zakelijk nu Internet Plus Extra geactiveerd thuis en tot nu toe werkt alles perfekt. Nu is het zo dat mijn Cisco RV325 router kan werken via SLAAC of een Statisch WAN IP met daarbij Configure to RA and DHCPv6 automatically of alleen DHCPv6 of alleen RA.

Op dit moment doe ik dus statisch en daarbij DHCPV6, alle lan apparaten krijgen netjes een IP (binnen de range) en ik kan natuurlijk handmatig een statisch IPV6 instellen voor static apparaten.

However, ik lees ook veel over SLAAC en hoeveel makkelijker dat is vnl in combinatie met DHCPV6. Is dat iets wat jullie aanraden om te gebruiken of SLAAC absoluut niet gebruiken?

Overigens voor degene die het willen weten ze rollen standaard met /64 uit.

Bvd

Je Cisco moet denk ik DHCPv6 doen op zijn WAN om via Prefix Delegation een prefix te krijgen.

Dat je een /64 krijgt lijkt me stug? Ik denk eerder een /56 of /48?

[tcviper]

Noop staat zo in de beschrijving van Ziggo dat je op LAN /64 gebruikt, zelfde met de externe IP's ook /64. Maar goed, wel of geen SLAAC (heb voorbeeld hieronder gegooit, uiteraard IP's gewijzigd)

IPV6 adres gegevens direct achter modem:

Netwerk adres: 2001:44f0:3071:0:0:0:0:0 ip subnet -mask: /64
Gateway ziggo: 2001:44f0:3071:0:0:0:0:1 ip subnet -mask: /64
Vrij te gebruiken: 2001:44f0:3071:0:0:0:0:2 ip sunet mask: /64
t/m
Vrij te gebruiken: 2001:44f0:3071:0:ffff:ffff:ffff:fffe ip subnet mask: /64

IPV6 adres gegevens achter router (voorbeeld):

Netwerkadres: 2001:44f0:3071:1:0:0:0:0 ip subnet mask: /64
Gateway LAN: 2001:44f0:3071:1:0:0:0:1 ip subnet mask: /64
Vrij te gebruiken: 2001:44f0:3071:1:0:0:0:2 t/m 2001:44f0:3071:1:ffff:ffff:ffff:fffe subnet mask: /64

Ik heb dus bij mijn router dit ingesteld (Cisco RV325) maar kan daar ook kiezen voor SLAAC:
WAN INTERFACE IPV6 Static: 2001:44f0:3071:0:ffff:ffff:ffff:fffe
Prefix length: 64
Default gateway: 2001:44f0:3071:0:0:0:0:1

LAN IPV6 address: 2001:44f0:3071:1:0:0:0:0
Prefix length: 64

LAN IPV6 DHCP: 2001:44f0:3071:1::1
Prefix length: 64

Ik neem aan dat dat goed moet zijn (pc's krijgen ip's dus)

Dit krijg je van hun zo.

[ Voor 89% gewijzigd door tcviper op 15-01-2015 17:17 ]

[Osiris]

Mja, subnet is wellicht (by default bij IPv6) een /64, maar je toegekende prefix kan probleemloos groter zijn.

[tcviper]

Naja ik volg wat er in de documentatie staat, en SLAAC op WAN bij IPV6 werkt zeker bij Cisco RV series, je kunt kiezen tussen static ip, dynamic ip, slaac of 6to4tunnel. wat raden jullie aan? of het laten zoals het nu is (statisch IP naar buiten voor router) en dan RA + DHCPv6 of alleen DHCPV6 en statisch?

[ Voor 23% gewijzigd door tcviper op 15-01-2015 17:49 ]

[databeestje]

Wellicht dat een apparaat dat een DHCP-PD request doet ook daadwerkelijk een prefix krijgt, zoals het er boven uitziet krijg ik de indruk dat de Ziggo enkel een /64 geeft.

Bij sommige providers routeren ze de rest van de /48 of /56 naar ::2 toe, maar of dat hier zo is?

[Freeaqingme]

Waarom zou een consumenten ISP die van oudsher altijd 1 IPv4 adres aan ieder huishouden heeft toegekend op een consumentenlijn spontaan een /48 of /56 aanbieden? Ik snap dat het voor tech-users leuk is, maar het lijkt me dat je er - again, voor een consumentenlijn - niet echt een businesscase van kan maken. Effectief heb je hier mee al 2^(128-64) ip's, dus tenzij je 'complexe' netwerksetups gaat maken heb je daar niets aan.

[Sendy]

RFC https://tools.ietf.org/html/rfc6177 schrijft

Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either.

Deze RFC suggereerd dat /56 wellicht beter is:

The above-mentioned goals of RFC 3177 can easily be met by giving home users a default assignment of less than /48, such as a /56

Maar geeft dit verder uit handen aan de "operational community."

[ Voor 25% gewijzigd door Sendy op 17-01-2015 00:45 ]

[databeestje]

Freeaqingme schreef op zaterdag 17 januari 2015 @ 00:08:
Waarom zou een consumenten ISP die van oudsher altijd 1 IPv4 adres aan ieder huishouden heeft toegekend op een consumentenlijn spontaan een /48 of /56 aanbieden? Ik snap dat het voor tech-users leuk is, maar het lijkt me dat je er - again, voor een consumentenlijn - niet echt een businesscase van kan maken. Effectief heb je hier mee al 2^(128-64) ip's, dus tenzij je 'complexe' netwerksetups gaat maken heb je daar niets aan.

Er is geen NAT maar routering, hence moet in ieder geval 2 lagen DHCP-PD functioneren zodat routers achter de ISP router gewoon functioneren en IPv6 hebben. Het gaat niet om het aantal hosts dat je erachter aan kan sluiten, dat is nu ook geen issue. Het gaat om de netwerk nummers, dat linker deel van 64 bits, die bepaalt of je het kan routeren, dat moet dus meer dan 1 bit zijn voor knappe route agggregatie.

Dat heeft niets met business case en tech-users te maken. Als bob met de korte achternaam een extra wifi router bij de mediamarkt haalt en deze achter zijn Ziggo modem aansluit dan kan deze via DHCP-PD gewoon een prefix krijgen en werkt IPv6 "gewoon".

Daar heeft hij geen moment bij stil gestaan, dus het tech users argument is kul.

De onderliggende router krijgt een /64 uit de /56 die de ISP aan je toewijst en laat de volledige afhandeling ervan over aan de klant. Zo moet het werken volgens de RFC's.

De "business case" is een flauw argument, elke europese ISP die een verzoek bij RIPE indient voor een prefix en aangeeft 2 Miljoen klanten te hebben *krijgt* een /48 per end-user. No questions asked.

[Raven]

Hmm, Google doet (weer) niet meer via IPv6, pings/traceroutes doen het prima, maar openen in browsers niet tenzij ik IPv6 disable in de netwerkinstellingen.

[Snow_King]

Freeaqingme schreef op zaterdag 17 januari 2015 @ 00:08:
Waarom zou een consumenten ISP die van oudsher altijd 1 IPv4 adres aan ieder huishouden heeft toegekend op een consumentenlijn spontaan een /48 of /56 aanbieden? Ik snap dat het voor tech-users leuk is, maar het lijkt me dat je er - again, voor een consumentenlijn - niet echt een businesscase van kan maken. Effectief heb je hier mee al 2^(128-64) ip's, dus tenzij je 'complexe' netwerksetups gaat maken heb je daar niets aan.

Heeft zoals aangegeven hier boven niets met tech-users te maken. Het internet moet gewoon werken en kunnen groeien.

Elk apparaat krijgt zijn eigen, unieke adres op het internet zoals het hoort.

Peer-to-peer kan weer beter plaats vinden, denk aan VOIP en gaming. Geen NAT meer, dat maakt de boel kapot.

Netwerken worden JUIST simpeler wanneer NAT een stille dood sterft, routering, zo moet het internet werken.

Raven schreef op zaterdag 17 januari 2015 @ 11:48:
Hmm, Google doet (weer) niet meer via IPv6, pings/traceroutes doen het prima, maar openen in browsers niet tenzij ik IPv6 disable in de netwerkinstellingen.

Hier via ZeelandNet werkt het prima. Geen enkel probleem.

[Raven]

Hmm, hier iemand met hetzelfde: http://forums.whirlpool.net.au/archive/2360847

Ik zit nu te wisselen tussen google.nl en google.com. De ene keer werkt de ene wel en de ander niet, soms beide niet en soms beide wel. Ipv6 uit en werkt weer normaal. Andere ipv6 sites geen probleem zo te zien.

[ Voor 14% gewijzigd door Raven op 17-01-2015 12:45 ]

[tcviper]

Voor nu gebruik ik DHCPv6 omdat ik wil zien welke LAN apparaten een IP krijgen en die krijgen dan via die DHCPV6 op de router meteen hun DNS settings etc. Ra heb ik dus uitgegooid omdat ik daar het nut niet van zie (automatisch IP nav mac adres). Als er een server intern is geef ik die gewoon een eigen vast IP en daar zet ik dan poorten van buiten naar binnen bij open.

[ Voor 20% gewijzigd door tcviper op 17-01-2015 13:51 ]

[Snow_King]

tcviper schreef op zaterdag 17 januari 2015 @ 13:51:
Voor nu gebruik ik DHCPv6 omdat ik wil zien welke LAN apparaten een IP krijgen en die krijgen dan via die DHCPV6 op de router meteen hun DNS settings etc. Ra heb ik dus uitgegooid omdat ik daar het nut niet van zie (automatisch IP nav mac adres). Als er een server intern is geef ik die gewoon een eigen vast IP en daar zet ik dan poorten van buiten naar binnen bij open.

RA is juist geweldig! Super simpel en krachtig. DHCPv6 maakt de boel een stuk complexer.

[tcviper]

DHCPV6 is met 1 druk op de knop van de Cisco RV320 router en het werkt meteen, alle pc's krijgen nu een 1::xx adres en alle juiste data doorgegeven. Overigens kan ik ook nog altijd zowel RA als DHCPV6 aangooien.

[ Voor 17% gewijzigd door tcviper op 17-01-2015 13:56 ]

[CAPSLOCK2000]

tcviper schreef op zaterdag 17 januari 2015 @ 13:51:
Voor nu gebruik ik DHCPv6 omdat ik wil zien welke LAN apparaten een IP krijgen en die krijgen dan via die DHCPV6 op de router meteen hun DNS settings etc. Ra heb ik dus uitgegooid omdat ik daar het nut niet van zie (automatisch IP nav mac adres). Als er een server intern is geef ik die gewoon een eigen vast IP en daar zet ik dan poorten van buiten naar binnen bij open.

Ik denk dat je SLAAC (Stateless Address Autoconfiguration) bedoelt, en niet RA (Router Advertisements) want bij DHCPv6 heb je nog steeds RA nodig om je gateway te vinden.

Ik maak gebruik van alle drie de mogelijkheden (statisch, slaac, dhcpv6). Alles heeft z'n plek.
- Servers doe ik statisch. Die hebben niks te winnen en veel te verliezen met dynamische configuratie.
- SLAAC gebruik ik voor simpele clients die verder niks over mijn netwerk hoeven te weten en alleen een beetje willen internetten.
- DHCPv6 is voor router-achtigen. Mijn eigen routers heb ik statisch geconfigureerd, maar als jij met een laptopje vol VM's en virtuele netwerkjes bij mij komt dan kan je een hele range krijgen om zelf verder te verdelen.
- Er zijn nog wat devices die geen SLAAC en/of RDNSS snappen, die mogen ook DHCPv6 gebruiken.

[tcviper]

Ja precies, nou ik heb nu dus RA+DHCVP6 aangegooid en dat werkt prima

[Raven]

Raven schreef op zaterdag 17 januari 2015 @ 12:38:
Hmm, hier iemand met hetzelfde: http://forums.whirlpool.net.au/archive/2360847

Ik zit nu te wisselen tussen google.nl en google.com. De ene keer werkt de ene wel en de ander niet, soms beide niet en soms beide wel. Ipv6 uit en werkt weer normaal. Andere ipv6 sites geen probleem zo te zien.

Inmiddels zijn daar wat meldingen met identiek probleem bijgekomen, valt een verbindingsprobleem met een specifieke website en via IPv6 op de een of andere manier te troubleshooten? Het enige dat ik op dit moment kan zien is dat het specifiek aan het gebruiken van IPv6 ligt en Google als specifieke website.

Iemand heeft 't daar over routing problemen, maar een tracert ziet er volgens mij gewoon normaal uit:

code:

C:\Users\Raven>tracert google.nl

Traceren van de route naar google.nl [2a00:1450:4013:c01::5e]
via maximaal 30 hops:

  1   <1 ms   <1 ms     1 ms 2001:****:****:****::1
  2     8 ms     7 ms     8 ms  Raven-1.tunnel.tserv11.ams1.ipv6.he.net [2001:****:****:****::1]
  3    12 ms     4 ms    18 ms  v213.core1.ams1.he.net [2001:470:0:7d::1]
  4     5 ms     5 ms     6 ms  core1.ams.net.google.com [2001:7f8:1::a501:5169:2]
  5     5 ms     5 ms     5 ms  2001:4860::1:0:4b3
  6     5 ms     5 ms     5 ms  2001:4860::8:0:51a0
  7     8 ms    14 ms     8 ms  2001:4860::8:0:517a
  8     8 ms     8 ms     8 ms  2001:4860::2:0:8651
  9     *        *        *     Time-out bij opdracht.
 10     8 ms     8 ms     8 ms  ea-in-x5e.1e100.net [2a00:1450:4013:c01::5e]

De trace is voltooid.

C:\Users\Raven>tracert google.com

Traceren van de route naar google.com [2a00:1450:4013:c01::8a]
via maximaal 30 hops:

  1   <1 ms   <1 ms   <1 ms 2001:****:****:****::1
  2     8 ms     8 ms     8 ms  Raven-1.tunnel.tserv11.ams1.ipv6.he.net [2001:****:****:****::1]
  3     7 ms     5 ms     4 ms  v213.core1.ams1.he.net [2001:470:0:7d::1]
  4     5 ms     5 ms     5 ms  core1.ams.net.google.com [2001:7f8:1::a501:5169:2]
  5     5 ms     5 ms     6 ms  2001:4860::1:0:4b3
  6     5 ms     5 ms     5 ms  2001:4860::8:0:519f
  7    12 ms     9 ms    18 ms  2001:4860::8:0:517a
  8     8 ms     8 ms     8 ms  2001:4860::2:0:8652
  9     *        *        *     Time-out bij opdracht.
 10     8 ms     8 ms     8 ms  ea-in-x8a.1e100.net [2a00:1450:4013:c01::8a]

De trace is voltooid.

C:\Users\Raven>

[eymey]

Hier dan ook maar even een "me too" melding . Had het aanvankelijk in het Telfort Glasvezel topic gemeld maar @Raven deed de suggestie het ook even hier te melden

Zelf merk ik via een he.net tunnel (Amsterdam endpoint) icm. een Fritz!box 7490 als router al geruime tijd intermittent problemen met IPV6. Verbinding opzetten lukt eigenlijk altijd wel maar tijdens een TCP sessie (bv. SSH naar VPS hosts) merk ik wel geregeld packet drops en dus haperende terminals. En Google, Facebook, etc. zijn af en toe erg traag / hebben meerdere retry's van requests nodig.

Maar goed, vanmiddag gebeld door m'n schoonouders. Die hebben ook Telfort Glasvezel icm. een Sitecom WLR-4004. En maken gebruik van de IPV6 connectiviteit van Telfort / ITNS zelf. Dat werkt met 6rd configuratie.

En zij hebben dus sinds gisteravond met name problemen met de Google diensten. Heb bij hen via een teamviewer sessie voorlopig ipv6 maar uitgeschakeld.

[databeestje]

Wellicht zijn er wel weer google diensten geactiveerd op hosts welke niet Packet too Big/PMTU ondersteunen waardoor dit problemen geeft. Dit is recent al eerder naar voren gekomen bij IPv6 problemen met Google.

Als de internet verbinding geen 1500 byte MTU heeft, zoals 6rd of een andere tunnel variant, dan gaat dit stuk.

[Raven]

Toevallig hier ook Telfort glasvezel (voorheen Concepts), maar ik maak dus niet gebruik van Telforts IPv6 verbinding of routers geleverd door Telfort.

databeestje schreef op zondag 18 januari 2015 @ 21:35:
Wellicht zijn er wel weer google diensten geactiveerd op hosts welke niet Packet too Big/PMTU ondersteunen waardoor dit problemen geeft. Dit is recent al eerder naar voren gekomen bij IPv6 problemen met Google.

Als de internet verbinding geen 1500 byte MTU heeft, zoals 6rd of een andere tunnel variant, dan gaat dit stuk.

Weer? Toevallig of niet, dit had ik vorige week met verschillende websites (waaronder Google en Facebook) en dat kwam omdat ip6tables hier die packets niet doorliet.

[Raven]

HE heeft inmiddels bevestigd dat het niet aan mijn kant of aan hun kant misgaat, op verzoek nog mtu verlaagt maar hielp niet, daarnaast komen op steeds meer sites meldingen binnen:
- Eerdergenoemde http://forums.whirlpool.net.au/forum-replies.cfm?t=2360847
- http://www.dslreports.com...Google-connection-hanging
- http://www.gossamer-threads.com/lists/nsp/ipv6/53248
- https://forums.he.net/index.php?topic=3342

Het lijkt er steeds meer op dat Google de IPv6 toegankelijkheid weer verkloot heeft. Nu wachten tot ze daar wakker worden.

edit:

@Prolixium
Sigh.. Google is again ignoring ICMPv6 PTBs. Really, it's too early in the game to completely break tunnel users. #ipv6 #google #fail

Blijkbaar is er al een ticket: https://twitter.com/wesgeorge/status/557171667697672193

[ Voor 22% gewijzigd door Raven op 19-01-2015 20:25 ]

[Hipska]

Dus native IPv6 naar Google zou wel moeten lukken, enkel als het via een tunnel als bijvoorbeeld HE gaat, dan werkt google soms wel soms niet?

[Raven]

Als het inderdaad dat probleem weer is, dan hebben (van wat ik heb gelezen) alleen tunnels er last van ja. Straks maar weer eens rondneuzen om te kijken of er al wat meer bekend is.

[ Voor 7% gewijzigd door Raven op 20-01-2015 10:23 ]

[anboni]

Ik kan over m'n native verbindingen in ieder geval gewoon bij Google diensten, dus zal inderdaad wel iets met tunnels te maken hebben.

[Raven]

Nou nee, niet met tunnels, afhankelijk van hoe je het bekijkt. Google heeft al eerder mtu-issues gehad en met die specifieke mtu-waardes "blokkeren" ze heel toevallig alleen tunnels.

[ Voor 20% gewijzigd door Raven op 20-01-2015 11:43 ]

[anboni]

Mja, ik drukte me wat onzorgvuldig uit ja, 'zal wel iets zijn wat vooral/alleen tunnel gebruikers raakt' was beter geweest

[databeestje]

Raven schreef op dinsdag 20 januari 2015 @ 11:42:
Nou nee, niet met tunnels, afhankelijk van hoe je het bekijkt. Google heeft al eerder mtu-issues gehad en met die specifieke mtu-waardes "blokkeren" ze heel toevallig alleen tunnels.

En iedereen die PPPoA/PPPoE gebruikt met een DHCP6 client, dat zijn er nogal wat. Er zijn behoorlijk wat providers die deze opzet gebruiken, maar weinig providers die er zorg voor dragen dat de MTU binnen de PPPoE ook 1500 bytes.

De gewoonte is ontstaan om op IPv4 de MSS te clampen waardoor dit niet zo een probleem is, het probleem is dat bijna niemand dit nog ondersteunt onder IPv6.

Ook voor IPsec tunnels en andere VPN protocollen wordt dit nog wel een ding.

[Hipska]

databeestje schreef op zaterdag 17 januari 2015 @ 09:04:
[...]

Er is geen NAT maar routering, hence moet in ieder geval 2 lagen DHCP-PD functioneren zodat routers achter de ISP router gewoon functioneren en IPv6 hebben. Het gaat niet om het aantal hosts dat je erachter aan kan sluiten, dat is nu ook geen issue. Het gaat om de netwerk nummers, dat linker deel van 64 bits, die bepaalt of je het kan routeren, dat moet dus meer dan 1 bit zijn voor knappe route agggregatie.

Dat heeft niets met business case en tech-users te maken. Als bob met de korte achternaam een extra wifi router bij de mediamarkt haalt en deze achter zijn Ziggo modem aansluit dan kan deze via DHCP-PD gewoon een prefix krijgen en werkt IPv6 "gewoon".

Daar heeft hij geen moment bij stil gestaan, dus het tech users argument is kul.

De onderliggende router krijgt een /64 uit de /56 die de ISP aan je toewijst en laat de volledige afhandeling ervan over aan de klant. Zo moet het werken volgens de RFC's.

De "business case" is een flauw argument, elke europese ISP die een verzoek bij RIPE indient voor een prefix en aangeeft 2 Miljoen klanten te hebben *krijgt* een /48 per end-user. No questions asked.

Dat is de eerste keer dat ik dit op die manier hoor. Lijkt me ook goed en logisch en beter dan telkens opnieuw PAT te doen.

Dit wil ik wel eens testen op een Linux host (Raspberry, VM). Hoe ga ik dan te werk zodat het even automagisch werkt als die router van de MediaMarkt?

[d--amo]

Wat is de ervaring met de doorsnee consumentenrouters, zoals D-Link, TP-Link, Linksys ed mbt tot IPv6?
Wat is daar vaak de default config? Doen zulke routers (default) goed aan prefix delegation?

Ik zou verwachten dat ze default vaak DHCPv6 hebben aanstaan op de WAN, maar dan geen PD. In de meeste gevallen zal er dus een config aanpassing nodig zijn als de ISP DHCPv6 en PD gebruikt. Of heb ik dat fout?