Het grote IPv6 topic

[Nakebod]

Kees komt zometeen met een officiele verklaring. _{For real.}
De IPv6 range bij TRUE is aangepast, hij wordt nu echt 1337!

Ah daar is ie al!

[ Voor 7% gewijzigd door Nakebod op 22-07-2015 15:41 ]

[Kees]

Verwijderd schreef op woensdag 22 juli 2015 @ 14:58:
voorbode voor veranderingen

Dat is het effect als je in de nieuwe firewall ipv6 'all' op DENY zet.

Sowieso ben ik van plan die allemaal te veranderen naar een andere range (een waar ik wel reverse dns kan zetten), dus 2001:990:6::/48 ga ik niet meer publiek aanbieden (ik blijf het nog wel intern gebruiken, maar de firewall houd dat ook intern).

Telecity staat al wel goed, en daar heeft staat de firewall ook al volledig ingesteld (zowel ipv4 als ipv6);

2a00:1188:8:31:140 tweakers.net secure.tweakers.net gathering.tweakers.net
2a00:1188:8:31::141 tweakimg.net ic.tweakimg.net
2a00:1188:8:31::143 tweakblogs.net
2a00:1188:8:31::145 static.tweakers.net
2a00:1188:8:31::147 error.tweakers.net
2a00:1188:8:31::171 irc.tweakers.net

Dit alles onder voorbehoud; ik ben de komende tijd er druk mee bezig, en als er dingen stuk gaan of nu nog niet werken dan mag je niet roepen dat tweakers down is

[ Voor 8% gewijzigd door Kees op 22-07-2015 15:42 ]

[.oisyn]

Ik gok dat die eerste regel 2a00:1188:8:31::140 moet zijn? (dus een :: voor de 140 ipv een enkele : )

[Maurits van Baerle]

Kees schreef op woensdag 22 juli 2015 @ 15:41:
[...]

2a00:1188:8:31:140 tweakers.net secure.tweakers.net gathering.tweakers.net

Geen kunstjes als 2a00:1188:8:1337::140 ?

Dat doet Facebook wel leuk met hun 2620:0:1cfe:face:b00c::3

[Kees]

.oisyn schreef op woensdag 22 juli 2015 @ 15:44:
Ik gok dat die eerste regel 2a00:1188:8:31::140 moet zijn? (dus een :: voor de 140 ipv een enkele : )

Ja, klopt. (dit was de comment van de firewall rule, dus de rule staat zelf wel goed )

Overigens gaan die IP's binnenkort ook klapperen want ik moet intern ook omnummeren. Ik gebruik nu 2 ranges door elkaar intern en dat werkt wel, maar beheert niet lekker.

[Verwijderd]

Kees schreef op woensdag 22 juli 2015 @ 16:09:
[...]

Ja, klopt. (dit was de comment van de firewall rule, dus de rule staat zelf wel goed )

Overigens gaan die IP's binnenkort ook klapperen want ik moet intern ook omnummeren. Ik gebruik nu 2 ranges door elkaar intern en dat werkt wel, maar beheert niet lekker.

Maar stiekum is het wel prettig dat je zelf de boel kan omgooien, probeer dit maar eens met IPv4. Kun je nare situaties aan overhouden.

[Kees]

Verwijderd schreef op woensdag 22 juli 2015 @ 16:11:
[...]
Maar stiekum is het wel prettig dat je zelf de boel kan omgooien, probeer dit maar eens met IPv4. Kun je nare situaties aan overhouden.

Daar lukt het ook wel mee hoor, dat heb ik ook al eerder gedaan

[databeestje]

Kees schreef op woensdag 22 juli 2015 @ 17:23:
[...]

Daar lukt het ook wel mee hoor, dat heb ik ook al eerder gedaan

Goed bezig Kees, ik wacht in spanning af!

[Verwijderd]

Traffic op de AMS-IX loopt de laatste tijd weer wat terug, behalve gisteren. Erg frappant.

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

[agresionpower]

Verwijderd schreef op donderdag 23 juli 2015 @ 13:49:
Traffic op de AMS-IX loopt de laatste tijd weer wat terug, behalve gisteren. Erg frappant.

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

ik vermoed dat dat voornamelijk met de vakantie te maken heeft.
het algehele verkeer op de AMS-IX is ook een beetje terug gelopen de laatste weken.

[CAPSLOCK2000]

Verwijderd schreef op donderdag 23 juli 2015 @ 13:49:
Traffic op de AMS-IX loopt de laatste tijd weer wat terug, behalve gisteren. Erg frappant.

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

Dat zien we iedere grote vakantie. Tegen de tijd dat de universiteiten weer beginnen dan vliegt het weer om hoog. Vermoedelijk omdat er dan grote groepen nieuwe studenten beginnen die voor het eerst op zichzelf wonen en eindelijk zoveel kunnen internetten als ze willen en daarbij gebruik maken van de universiteitsnetwerken.

[Compizfox]

CAPSLOCK2000 schreef op donderdag 23 juli 2015 @ 17:06:
[...]

Vermoedelijk omdat er dan grote groepen nieuwe studenten beginnen die voor het eerst op zichzelf wonen en eindelijk zoveel kunnen internetten als ze willen

Ik vermoed dat het meer te maken heeft met de hoge bandbreedte die universiteitsnetwerken vaak bieden. Of hoe zie je dat voor je, een bijna-student van ~18 jaar die door z'n moeder van de computer af wordt geschopt?

[Dennis]

Ik kwam gisteren dit topic tegen op Serverfault en misschien is dat iets voor mij. Ik wil dus juist wat de auteur daar niet wil: een vast adres op de clients op basis van DHCPv6 (en dus bekend in de DNS-server) terwijl als je op het internet gaat er met de privacy extensions gewerkt wordt. Beste van twee werelden dus denk ik.

Van het weekend maar eens implementeren!

[databeestje]

DHCP6 icm met Active directory werkt zakelijk prima, alles registreert netjes in de DNS en kan ik de PC's gewoon met VNC overnemen. Handig.

[Dennis]

databeestje schreef op vrijdag 24 juli 2015 @ 07:47:
DHCP6 icm met Active directory werkt zakelijk prima, alles registreert netjes in de DNS en kan ik de PC's gewoon met VNC overnemen. Handig.

Ik gebruik weliswaar geen Active Directory, maar inderdaad dat je alles kan overnemen is voor mij een must.

Hebben jouw clients als ze gaan internetten wel alsnog een RFC 4941 adres of gaan ze ook het internet op met het adres van jouw DHCP? Of is het niet van toepassing omdat je een proxy gebruikt?

[databeestje]

Dennis schreef op vrijdag 24 juli 2015 @ 09:00:
[...]

Ik gebruik weliswaar geen Active Directory, maar inderdaad dat je alles kan overnemen is voor mij een must.

Hebben jouw clients als ze gaan internetten wel alsnog een RFC 4941 adres of gaan ze ook het internet op met het adres van jouw DHCP? Of is het niet van toepassing omdat je een proxy gebruikt?

Uitgaand verkeer is standaard geblokeerd voor zowel v4 als v6, er is een WPAD autoconfig host en proxy gebruik wordt op die manier afgedwongen. Als iemand de laptop mee naar huis neemt werkt het dan ook gewoon.

De proxy's hebben ook IPv6, behalve 1 apart proxy, die doet alleen IPv4 zodat we bij het CBS kunnen komen

[Tomsworld]

databeestje schreef op vrijdag 24 juli 2015 @ 09:29:
[...]

De proxy's hebben ook IPv6, behalve 1 apart proxy, die doet alleen IPv4 zodat we bij het CBS kunnen komen

Ik weet niet wat jullie van product gebruiken, maar onze proxies doen prefer ipv6 en natuurlijk een broken site kunnen we niet bezoeken, daarvoor hebben we een rule waar we voor die sites prefer ipv4 doen, en een mailtje sturen naar de beheerder.

Geen nood om een hele proxy zonder ipv6 in te richten.

Op zich valt het aantal problemen mee vooral gezien de 10000 en gebruikers achter onze proxies denk ik dat we een goede mix hebben van bezochte websites.

[databeestje]

Tomsworld schreef op vrijdag 24 juli 2015 @ 11:50:
[...]


Ik weet niet wat jullie van product gebruiken, maar onze proxies doen prefer ipv6 en natuurlijk een broken site kunnen we niet bezoeken, daarvoor hebben we een rule waar we voor die sites prefer ipv4 doen, en een mailtje sturen naar de beheerder.

Geen nood om een hele proxy zonder ipv6 in te richten.

Op zich valt het aantal problemen mee vooral gezien de 10000 en gebruikers achter onze proxies denk ik dat we een goede mix hebben van bezochte websites.

De kapotte websites worden bij ons naar de IPv4 proxy gestuurd door middel van de Wpad, er zit afaik geen per domein optie in Squid 3.x.

Vrijwel alle sites doen het verder prima overigens met een stuk of wat gebruikers. Vrijwel allemaal niet technisch personeel.

Het CBS probleem is overigens wel een heel specifieke, onze firewall dropt IPv6 fragmenten, en CBS ontsluit de IPv4 site via een Juniper die IPv4 -> IPv6 NAT doet. En deze zet het fragmentatie bit op alle packets inclusief SYN. Effectief geen verbinding mogelijk.

[Tomsworld]

Ik vraag me af wie het dan fout doet jullie of CBS :

RFC : https://tools.ietf.org/html/rfc6145

When the IPv4 sender does not set the DF bit, the translator SHOULD
always include an IPv6 Fragment Header to indicate that the sender
allows fragmentation. The translator MAY provide a configuration
function that allows the translator not to include the Fragment
Header for the non-fragmented IPv6 packets.

Stuur jij efectief dan dat je geen fragmented packets aanvaard ?

Het is weer een vrij vage rfc en ik ben nog niet goed wakker.

[Maurits van Baerle]

Verwijderd schreef op donderdag 23 juli 2015 @ 13:49:
Traffic op de AMS-IX loopt de laatste tijd weer wat terug, behalve gisteren. Erg frappant.

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

En gisteravond was hij weer bijna zo hoog, twee dagen achter elkaar dus. Dat soort patronen blijven me verbazen...

[.oisyn]

Tja, er hoeft maar een grote internationale partij voor interne communicatie over te stappen op IPv6 en je hebt er al meteen een hele hoop bandwidth bij. Vergeet niet dat het totaal op 3,2Tb/s peakt he, bijna 100x zoveel als IPv6-only.

[ Voor 7% gewijzigd door .oisyn op 24-07-2015 13:02 ]

[databeestje]

Precies, dat is dus een grijs gebied. Juniper zegt dat ze het volgens de RFC gemaakt hebben, maar zet het Fragment bit voor alles, inclusief verkeer dat binnen de MTU valt.

In mijn geval dropt pfSense gefragmenteerd verkeer omdat pf(4) in FreeBSD 8.3 nog geen ondersteuning hiervoor had. In een nieuwere versie is het wellicht opgelost, maar dan moet er eerst weer het e.e.a. getest worden

[Dennis]

Ik heb gisteren mijn radvd aangepast en inderdaad gaat het nu deels zoals ik wil. Ik krijg nu op clients 3 IP-adressen: van de DHCP-server, een SLAAC adres en een RFC4941-adres. Als ik ga surfen wordt keurig het privacy extensions-adres gebruikt.

Hoelang blijven die privacy adressen eigenlijk geldig? Ik las ergens dat het een dag is, maar dat lijkt mij vrij lang.

Tweede punt waar ik nog mee zit is de voorspelbaarheid van de isc-dhcpv6 adressen. Ik kon niet iets vinden waardoor dat meer random is, dus ik twijfel nog aan de wenselijkheid hiervan. Misschien wil ik toch wel een ULA-range hiervoor gebruiken, want het gaat me tenslotte om het intern benaderbaar zijn.

[CyBeR]

Da's OS-specifiek.

[Snow_King]

Dennis schreef op zaterdag 25 juli 2015 @ 09:44:
Ik heb gisteren mijn radvd aangepast en inderdaad gaat het nu deels zoals ik wil. Ik krijg nu op clients 3 IP-adressen: van de DHCP-server, een SLAAC adres en een RFC4941-adres. Als ik ga surfen wordt keurig het privacy extensions-adres gebruikt.

Hoelang blijven die privacy adressen eigenlijk geldig? Ik las ergens dat het een dag is, maar dat lijkt mij vrij lang.

Tweede punt waar ik nog mee zit is de voorspelbaarheid van de isc-dhcpv6 adressen. Ik kon niet iets vinden waardoor dat meer random is, dus ik twijfel nog aan de wenselijkheid hiervan. Misschien wil ik toch wel een ULA-range hiervoor gebruiken, want het gaat me tenslotte om het intern benaderbaar zijn.

ULA gebruiken is imho een beetje IPv4 denken. Gewoon publieke adressen gebruiken en firewallen op je routers.

[Dennis]

Snow_King schreef op zaterdag 25 juli 2015 @ 12:15:
ULA gebruiken is imho een beetje IPv4 denken. Gewoon publieke adressen gebruiken en firewallen op je routers.

Dat is ook nog een idee, ja. Maar dan in een andere /64 dus.

IPv6 is toch lastiger dan versie 4. Je hebt gewoon zoveel mogelijkheden .

[ik222]

Snow_King schreef op zaterdag 25 juli 2015 @ 12:15:
[...]
ULA gebruiken is imho een beetje IPv4 denken. Gewoon publieke adressen gebruiken en firewallen op je routers.

Daar ben ik het niet altijd mee eens, als het puur gaat om intern verkeer dan kan ik me voorstellen dat er geen enkele reden is deze adressen afhankelijk te maken van de provider prefix.

[Snow_King]

ik222 schreef op zaterdag 25 juli 2015 @ 13:45:
[...]

Daar ben ik het niet altijd mee eens, als het puur gaat om intern verkeer dan kan ik me voorstellen dat er geen enkele reden is deze adressen afhankelijk te maken van de provider prefix.

Er zijn altijd redenen, maar het gros grijpt naar ULA omdat het met IPv4 ook zo werkte.

Je kan intern bijna gebruik maken van link local als je wil:

code:

ping6 fe80:xx:xxx%eth0

ULA heeft vast zijn voordeel, maar zoals ik al aan gaf, het wordt imho te vaak gekozen omdat het een IPv4 gedachte van interne netwerken is.

[Paul]

Snow_King schreef op zaterdag 25 juli 2015 @ 14:32:
Je kan intern bijna gebruik maken van link local als je wil:

Een beetje bedrijf heeft meerdere VLAN's / subnetten, dan ga je het met Link Local niet redden. Je wilt ook niet je hele bedrijf omnummeren wanneer je van access provider veranderd, en provider independent krijgt ook niet iedereen (nog los van hoe wenselijk het is heel veel PI-adressen / subnetten uit te delen)...

Ik hoor graag een andere optie als die er is, want dit is wel (een van) de reden(en) waarom men bij ons nog niet aan IPv6 gaat (dat, en druk met zaken die belangrijker zijn voor de business).

[databeestje]

PI aanvragen is niet zo bijzonder hoor, 2 weken geleden nog gedaan.

ULA gebruiken voor meer dan een subnet is lastig, omdat het routering impliceert, de kans is groot dat een apparaat gaat proberen met zijn ULA op het internet te komen.

Daarnaast, niet alleen een IPv4 routing tabel, maar ook nog 2 verschillende IPv6 routing tabellen. Ik weet niet waarom dat een voordeel zou zijn.

De firewall rules voor IPv6 zijn imho niet zo moeilijk, en met maar 1 range is het iig doorzichtig. Beter iig dan met IPv4 waar bij de 1:1 NAT het externe adres gebruikt en de firewall rule weer voor het interne (prive) adres is. Nu alleen nog maar rules, lekker overzichtelijk.

Bij ons op het werk en de andere locaties gebruiken we gewoon een PI IPv6 prefix, ik heb daar helemaal geen moeite mee. Ik kan, als het echt allemaal zo'n punt is, altijd nog NPt gaan gebruiken met de "oude" prefix, maar dan blijft het bij 1 routing tabel. ULA met NPt kan ook, maar niet alles ondersteunt dat.

[Snow_King]

Paul schreef op zondag 26 juli 2015 @ 19:37:
[...]
Een beetje bedrijf heeft meerdere VLAN's / subnetten, dan ga je het met Link Local niet redden. Je wilt ook niet je hele bedrijf omnummeren wanneer je van access provider veranderd, en provider independent krijgt ook niet iedereen (nog los van hoe wenselijk het is heel veel PI-adressen / subnetten uit te delen)...

Ik hoor graag een andere optie als die er is, want dit is wel (een van) de reden(en) waarom men bij ons nog niet aan IPv6 gaat (dat, en druk met zaken die belangrijker zijn voor de business).

Pi space is zo gefixed bij RIPE. Hoef je nooit meer om te nummeren.

[Paul]

databeestje schreef op zondag 26 juli 2015 @ 19:49:
PI aanvragen is niet zo bijzonder hoor, 2 weken geleden nog gedaan.

Snow_King schreef op zondag 26 juli 2015 @ 20:16:
Pi space is zo gefixed bij RIPE. Hoef je nooit meer om te nummeren.

Je hebt een access provider nodig die BGP met je wil praten, dat hoeft geen probleem te zijn, maar volgens mij blijf je zitten met het 'probleem' dat je met (veel) PI weer hele versnipperde routingstabellen krijgt, iets wat ze met IPv6 afaik juist proberen te voorkomen Bij ULA + NPT / NAT (als je maar loskoppelt van je externe prefix) speelt dat niet en heeft provider X (en daarmee de rest van de wereld) alleen zijn eigen prefix, ipv zijn eigen prefix en een paar duizend PI-prefixen...

[Snow_King]

Paul schreef op maandag 27 juli 2015 @ 11:03:
[...]


[...]
Je hebt een access provider nodig die BGP met je wil praten, dat hoeft geen probleem te zijn, maar volgens mij blijf je zitten met het 'probleem' dat je met (veel) PI weer hele versnipperde routingstabellen krijgt, iets wat ze met IPv6 afaik juist proberen te voorkomen Bij ULA + NPT / NAT (als je maar loskoppelt van je externe prefix) speelt dat niet en heeft provider X (en daarmee de rest van de wereld) alleen zijn eigen prefix, ipv zijn eigen prefix en een paar duizend PI-prefixen...

Die paar /48's is niet echt het probleem. We adverteren met IPv6 véél minder subnets dan met IPv4.

Jij wil dus een 1:1 NAT doen vanaf publieke IPv6 naar ULA? Het kán wel, maar ik ben er gewoon geen fan van.

[Paul]

Het is niet zozeer dat ik per se wil NATten (liever niet zelfs), ik wil vooral onafhankelijk zijn van mijn provider

"Die paar /48's", volgens mij worden dat er wel meer dan 'een paar'? Maar goed, als de mensen die daar over gaan (IETF?) vinden dat PI de oplossing is, wie ben ik dan om het mezelf moeilijk te maken?

[Verwijderd]

Paul schreef op maandag 27 juli 2015 @ 11:57:
Het is niet zozeer dat ik per se wil NATten (liever niet zelfs), ik wil vooral onafhankelijk zijn van mijn provider

"Die paar /48's", volgens mij worden dat er wel meer dan 'een paar'? Maar goed, als de mensen die daar over gaan (IETF?) vinden dat PI de oplossing is, wie ben ik dan om het mezelf moeilijk te maken?

Ik heb ook een tijd met die vraag geworsteld. Het lijkt me ook iets urgenter als je niet gelukkig bent bij je huidige provider, zovaak wissel je immers niet met een grote omgeving. Bij een kleine omgeving valt het nog te overzien.

Aan de andere kant, als ik een grote omgeving van provider wissel dan is er een overgangs periode. Je kan natuurlijk een extra IP aan de systemen geven en de RA een lagere prio en zo gefaseerd overgaan.

Zaken zoals firewall rules op (linux) hosts zijn te managen met bv puppet, in windows zou je een GPO kunnen toepassen voor de nieuwe ranges.

Zelf denk ik dat een PI meer iets is voor overheden en multi-nationals die ook multi-homing doen. Voor het MKB zie ik eigenlijk geen toegevoegde waarde.

[databeestje]

Verwijderd schreef op maandag 27 juli 2015 @ 12:58:
[...]

Zelf denk ik dat een PI meer iets is voor overheden en multi-nationals die ook multi-homing doen. Voor het MKB zie ik eigenlijk geen toegevoegde waarde.

Ik ben bang dat je jezelf tekort doet

Als je het eenmaal hebt snap je meteen waarom. Het is voor ons even duur om 2 glas verbindingen met BGP te doen als gewoon 2 glas internet verbindingen (100Mbit). Daarnaast blijven TCP sessies met BGP failover heel, iets wat bij ouderwets dual WAN altijd stuk gaat.

Overigens is het IPv6 route tabel verhaal helemaal geen probleem. De IPv4 tabel is een veel groter probleem, deze zal de komende jaren nog veel verder versnipperen.

Neem de tabel van de KPN als voorbeeld.
http://bgp.he.net/AS1136

Prefixes Announced (all): 383
Prefixes Announced (v4): 363
Prefixes Announced (v6): 20

Alle bestaande klanten van consument tot zakelijk passen allemaal met hun eigen /48 prefix in de 2a02:a400::/25. Stel dat de KPN ooit zou verdubbelen in grote, dan komt er in het ergste geval nog een 2e prefix bij. Dat gaat meteen met een paar miljoen klanten aan ruimte in 1 keer, dat in tegenstelling tot een /20 oid die je kan "kopen" voor 4096 adressen.

Als je kijkt naar de huidige distributie tussen 4 en 6 dan zien je dat we op dit moment op 1/5e van het aantal IPv6 announcements zitten.
http://bgp.he.net/report/prefixes#_networks
Als je dat versimpelt extrapoleert zal de routetabel groeien van 23k naar circa 100k routes. Het zal niet veel schelen.

Tegen de tijd dat alle 50k ASN's ook een v6 prefix hebben zal de v4 tabel wel tegen de 800k lopen gok ik.

[Verwijderd]

"Update" over KPN.

Er is op het moment nog niet heel veel informatie beschikbaar over de status van de IPv6 pilot en verdere uitrol, maar de planning is dat dit jaar het grootste deel van de klanten netwerktechnisch gezien (aan onze kant, dus niet in de grond e.d.) omgezet worden zodat ze IPv6 aankunnen. Afhankelijk van de pilotresultaten zullen we dan de verdere uitrol van IPv6 gaan doen. In eerste instantie bij glas en VDSL verbindingen, daarna de rest. Deze uitrol is dual stack, dat wil zeggen dat IPv4 en IPv6 naast elkaar actief zullen zijn. Als klant zijnde zul je hier in de praktijk eigenlijk niets van merken.

http://forum.kpn.com/t5/I...ol-IPv6/m-p/348796#M43845

[MegaTronics]

Vandaag aan Helden van Nu gevraagd om IPv6 te activeren op mijn verbinding, binnenkort maar eens gaan experimenteren.

[Maurits van Baerle]

Ziggo zet uitrol ipv6 tijdelijk op lager pitje

Was te verwachten. In ieder geval een heldere uitleg.

[Verwijderd]

Maurits van Baerle schreef op maandag 27 juli 2015 @ 20:31:
Ziggo zet uitrol ipv6 tijdelijk op lager pitje

Was te verwachten. In ieder geval een heldere uitleg.

Zo helder vind ik de uitleg niet, zie Verwijderd in 'nieuws: Ziggo zet uitrol ipv6 tijdelijk op lager pitje'

Het is niet alsof ze voorop lopen en totaal nieuw terrein aan het ontdekken zijn.

[Onbekend]

Dit is gewoon een actie-reactie. Veel telefoontjes naar de helpdesk met internetproblemen, en dan kijken ze of het zonder ipv6 nog steeds problemen geeft.

Werken trouwens ipv4 en ipv6 volledig identiek naast elkaar?

[databeestje]

Tja, het valt in de categorie, mijn modem is herstart voor de firmware update en nu doet mijn printer het niet meer. Niet noodzakelijk en ook maar iets gerelateerd maar gewoon de zielige staat van de meeste software in de consumenten apparatuur.

Het is 1 van de redenen dat sommige andere providers het wel aanzetten bij een nieuwe levering, maar niet een bestaande.

Zo heeft mijn router vandaag spontaan bedacht om de dyndns bij te werken met 192.168.1.1 in plaats van mijn publieke adres. Handig!

[Snow_King]

databeestje schreef op maandag 27 juli 2015 @ 21:47:
Tja, het valt in de categorie, mijn modem is herstart voor de firmware update en nu doet mijn printer het niet meer. Niet noodzakelijk en ook maar iets gerelateerd maar gewoon de zielige staat van de meeste software in de consumenten apparatuur.

Het is 1 van de redenen dat sommige andere providers het wel aanzetten bij een nieuwe levering, maar niet een bestaande.

Zo heeft mijn router vandaag spontaan bedacht om de dyndns bij te werken met 192.168.1.1 in plaats van mijn publieke adres. Handig!

CPE devices voor bij mensen thuis zien echt dramatisch van kwaliteit. Ook Cisco lijkt zijn goede naam (bij mij althans) te grabbel hebben gegooid met de troep die ze leveren met die EPC modems/routers.

Daardoor krijgen ISP's vaak de schuld terwijl die CPE's eigenlijk dramatisch zijn. Dat zien we nu dus ook.

[Verwijderd]

Snow_King schreef op dinsdag 28 juli 2015 @ 09:12:
[...]

CPE devices voor bij mensen thuis zien echt dramatisch van kwaliteit. Ook Cisco lijkt zijn goede naam (bij mij althans) te grabbel hebben gegooid met de troep die ze leveren met die EPC modems/routers.

Daardoor krijgen ISP's vaak de schuld terwijl die CPE's eigenlijk dramatisch zijn. Dat zien we nu dus ook.

Grotendeels mee eens.

Echter, UPC heeft tijdens een IPv6 pilot behoorlijk wat feedback gekregen waarmee ze naar de CPE leverancier zouden gaan. Een stap terug zoals nu is dus nooit gebeurd. Als Ziggo ook een pilot was gestart dan waren dit soort zaken waarschijnlijk wel boventafel gekomen en dan nog bij mensen die er begrip voor hebben.

Nu zijn "onwetende" klanten slachtoffer geworden, dat is geen technisch issue maar slecht management en planning.

[Ximon]

Dit klinkt nogal als geen commitment denk ik. Het doet het niet? En met IPv6 uit doet het het wel? Dan zetten we IPv6 uit, hebben we toch niet nodig. Helaas hoor ik dit soort redenatie op de werkvloer ook heel vaak

[eymey]

Dat. Bovendien is het bij UPC na de pilot verder volgens mij ook doodstil gebleven rondom ipv6. In ieder geval als ik m'n collega moet geloven. Dus of je nou oud-Ziggo of oud-UPC zit, volgens mij is bij beiden de huidige stand van zaken dat er geen ipv6 is. Alleen is het bij UPC in een pilot geweest en heeft het bij consumenten even 'gewoon aan' gestaan. (correct me if I'm wrong).

[ Voor 45% gewijzigd door eymey op 28-07-2015 11:55 ]

[Verwijderd]

eymey schreef op dinsdag 28 juli 2015 @ 11:54:
Dat. Bovendien is het bij UPC na de pilot verder volgens mij ook doodstil gebleven rondom ipv6. In ieder geval als ik m'n collega moet geloven.

Dat was ook het moment dat UPC en Ziggo samengingen. Dat begrijp ik dan nog wel, ook dat dat de hele IPv6 pilot ongeldig maakte omdat de UPC test voor DS-lite was en de Ziggo uitvoering Dual-stack. Een aantal gemelde problemen met de DS-lite opzet waren niet van toepassing met de Dual-stack opzet.

Blijft de vraag natuurlijk waarom Ziggo niet gewoon een pilot start, feedback van testers verwerkt en als de issues inkaart zijn gebracht, prioriteit en impact hebben gekregen men beslist of de rest van de klanten IPv6 (gefaseerd) krijgen toegewezen.

[Bigs]

Ximon schreef op dinsdag 28 juli 2015 @ 11:49:
Dit klinkt nogal als geen commitment denk ik. Het doet het niet? En met IPv6 uit doet het het wel? Dan zetten we IPv6 uit, hebben we toch niet nodig. Helaas hoor ik dit soort redenatie op de werkvloer ook heel vaak

Als een significant deel van je klanten problemen ervaart doordat je iets aanzet waar ze niet om gevraagd hebben dan snap ik wel dat je het terug draait. De extra kosten van zo'n actie lopen namelijk best wel op (denk aan de inzet van de helpdesk e.d.).

Volgens mij zet XS4ALL IPv6 standaard aan op nieuwe aansluitingen maar moesten bestaande klanten het zelf inschakelen. Dat is een betere aanpak.

[eymey]

@ randomnumber: Dat ben ik helemaal met je eens.

Sowieso, start inderdaad gewoon een pilot, waarbij je om te beginnen technisch onderlegde mensen (zoals de doelgroep in dit topic) mee laat doen. Maak desnoods 1 groep met mensen die zelf wel weten hoe ze een router inrichten met dual stack en 1 groep waarbij Ziggo het zelf op de CPE beheert (zoals bij een doorsnee consument).

[Verwijderd]

Bigs schreef op dinsdag 28 juli 2015 @ 12:02:
[...]


Als een significant deel van je klanten problemen ervaart doordat je iets aanzet waar ze niet om gevraagd hebben dan snap ik wel dat je het terug draait.

True, echter het bericht citeert Gradus Vos

We willen onderzoeken of de activatie van ipv6 daar de oorzaak van is

En dat vind ik een vreemde gang van zaken, dat laat zien dat je op het moment van de beslissing eigenlijk niet weet wat er aan de hand is. Tuurlijk wordt de soep niet zo heet gegeten als deze wordt op gediend maar met een betere aanpak blijf je uit dit soort situaties.

Dit is wat ik aanneem op basis van de door Gradus gegeven informatie, mocht er dus wel een IPv6 probleem zijn dan zou ik de eerste zijn om de firmware of functionaliteit terug te rollen. Echter hij gaf aan dat de oorzaak nog niet bekend is of was.

Maar toch nog goed nieuws vandaag, voor het eerst tot (ik denk 1 week geleden?) is er iets over IPv6 op de ziggo site te vinden.

https://www.ziggo.nl/klantenservice/internet/verbinding/ipv6

[ Voor 24% gewijzigd door Verwijderd op 28-07-2015 12:46 ]

[Dennis]

Verwijderd schreef op dinsdag 28 juli 2015 @ 12:05:
Maar toch nog goed nieuws vandaag, voor het eerst tot (ik denk 1 week geleden?) is er iets over IPv6 op de ziggo site te vinden.

https://www.ziggo.nl/klantenservice/internet/verbinding/ipv6

Euh... van de website:

IPv6 bij Ziggo
IPv6 werkt nog niet met alle apparaten en websites. Natuurlijk ondersteunt Ziggo IPv4 én IPv6.

Wat een onzin. Ze ondersteunen het helemaal niet .

[Bigs]

Verwijderd schreef op dinsdag 28 juli 2015 @ 12:05:
[...]

En dat vind ik een vreemde gang van zaken, dat laat zien dat je op het moment van de beslissing eigenlijk niet weet wat er aan de hand is. Tuurlijk wordt de soep niet zo heet gegeten als deze wordt op gediend maar met een betere aanpak blijf je uit dit soort situaties.

[...]

Als je dat een vreemde gang van zaken vindt dan onderschat je denk ik de complexiteit en omvang van een organisatie als Ziggo. Ik kan me goed voorstellen dat ze ineens een stijging zien in support calls die samenvalt met het grootschalig inschakelen van IPv6. Er komen duizenden calls per dag binnen en er wordt per call maar beperkt gelogd (waarbij de probleemanalyse van eerste lijns agents waarschijnlijk ook nog eens te kort schiet). Het kan wel even duren om in al die informatie uit te zoeken of er een verband is, het is niet dat ze even de call database doorzoeken op 'ipv6 issue' en dan het probleem te pakken hebben. Dat je dan een niet-essentiële feature weer uitschakelt vind ik dan wel begrijpelijk.

Onvoorziene problemen heb je overigens met elke technische aanpassing, groot of klein. Noem maar het voorbeeld van een printer die zich ineens anders gedraagt doordat er IPv6 in het thuisnetwerk wordt aangekondigd. Je kunt als provider niet alles voorzien, maar je klanten komen wel bij jou aankloppen.

(aldus de ex UPC storingsdienst medewerker)

[ Voor 31% gewijzigd door Bigs op 28-07-2015 13:28 ]

[eymey]

@Bigs: Wat mij betreft sla je de spijker op z'n kop.

Ik weet inmiddels ook al te goed de nadelen en uitdagingen van een grote complexe organisatie.

En van daaruit kan ook ik alleen maar begrip hebben voor het geheel terugdraaien van ipv6.

Sowieso merk ook ik zelf nog geregeld dat ipv6 niet altijd even soepel werkt, bv. bij Google en Facebook. Laat dat voor consumenten nou 2 van de meest essentiele diensten zijn

Dit doet trouwens niets af aan mijn vorige reactie: Beter hadden ze dit gewoon op kleine schaal middels een pilot kunnen testen.

[ Voor 13% gewijzigd door eymey op 28-07-2015 13:38 ]

[Maurits van Baerle]

Als ik dit verhaal zo lees dan zouden het best wel eens problemen met de MTU kunnen zijn. Ofwel in het modem, ofwel een router ergens in het Ziggo netwerk.

[MegaTronics]

Ik ben met mijn Asus RT-AC68U aan het testen met IPv6. Vanuit mijn provider (Helden van Nu) heb ik een blok toegewezen gekregen welke ik opvoer in de Asus:



Alleen heb ik nu een keer IPv6 verbinding gehad, maar die was maar van tijdelijke aard en nu weigert die dienst.. Toen die wel een verbinding had, kreeg ik een 10 uit 10 op http://test-ipv6.com/

Ik vermoed zelf dat onder anderen de IPv6 gateway niet juist is. HvN meld daarover dit:

Er moet bij de GW waarschijnlijk een route worden ingesteld (standaard staat dit niet ingesteld bij sommige routers) dit zal iets in de trant van “::/0” die dan verwijst naar de PPP sessie op Ipv6 zodat deze wel de route snapt, bij Mikrotik die wij configureren is dit “::/0” route naar de PPP-out sessie, zodat deze goed routeert naar de PPP sessie Ipv6.

Met ::0 werkt het sowieso niet, dus de vraag is nu wat is de instelling voor een Asus router om hem te laten wijzen naar de PPPv6 sessie. ::1 lijkt mij ook localhost

En de vraag is wat ik dan bij de LAN kant moet invullen. Daar staat nu ook het externe blok maar dat lijkt mij ook niet geheel correct.

Is er iemand die mij een zetje in de juiste richting kan geven?

[Compizfox]

Bigs schreef op dinsdag 28 juli 2015 @ 13:26:
[...]
Onvoorziene problemen heb je overigens met elke technische aanpassing, groot of klein. Noem maar het voorbeeld van een printer die zich ineens anders gedraagt doordat er IPv6 in het thuisnetwerk wordt aangekondigd. Je kunt als provider niet alles voorzien, maar je klanten komen wel bij jou aankloppen.

Da's wat mij betreft dan ook onzin. Een ISP zou niet verantwoordelijk moeten zijn voor het thuisnetwerk van de klant. (al roepen ze dat wel een beetje over henzelf af, door o.a. routers te leveren en in sommige gevallen die zelfs verplicht te maken)

[Bigs]

Compizfox schreef op dinsdag 28 juli 2015 @ 18:41:
[...]

Da's wat mij betreft dan ook onzin. Een ISP zou niet verantwoordelijk moeten zijn voor het thuisnetwerk van de klant. (al roepen ze dat wel een beetje over henzelf af, door o.a. routers te leveren en in sommige gevallen die zelfs verplicht te maken)

Maakt niet uit. Mensen kloppen bij hun ISP aan / geven hen de schuld en dat kost zo'n partij geld.

[Jaap-Jan]

MegaTronics schreef op dinsdag 28 juli 2015 @ 18:13:
(..)

Als je Static IPv6 moet gebruiken, moet je die gegevens hebben gekregen van je provider. De gegevens die je moet hebben zijn het WAN IP, het WAN gateway IP en je geassignede prefix. Ik gok dat je ook de WAN prefix length moet hebben gekregen. 1 IP- adres waarvan moet je gebruiken als LAN ip voor je router. Je WAN ip ligt meestal in een andere reeks als je LAN/ routed prefix.

Er wordt trouwens niet bedoeld dat je WAN gateway address ::0 moet zijn, maar dat je ::0 moet routeren naar je PPP- interface. Vaak wordt dit door de router al voor je gedaan, net zoals 0.0.0.0 naar je PPP- interface gerouteerd wordt.

Werkt HvN niet met DHCPv6 prefix delegation en moet je alles echt statisch configureren?

[databeestje]

De Asus zou de RA op moeten pikken vanaf de zijde van HvN, zeker als het semi statisch geconfigureerd is moet daar ook een announcement vandaan komen. De gateway is normaal gesproken een fe80::1 link-local adres. Al staan sommige ook een publiek adres hier toe, dit is niet strikt noodzakelijk.

fe80::1 wordt vaak voor de gateway gebruikt, deze kan je zonder problemen op meerdere interfaces gebruiken.

[MegaTronics]

Jaap-Jan schreef op dinsdag 28 juli 2015 @ 19:54:
[...]
Als je Static IPv6 moet gebruiken, moet je die gegevens hebben gekregen van je provider. De gegevens die je moet hebben zijn het WAN IP, het WAN gateway IP en je geassignede prefix. Ik gok dat je ook de WAN prefix length moet hebben gekregen. 1 IP- adres waarvan moet je gebruiken als LAN ip voor je router. Je WAN ip ligt meestal in een andere reeks als je LAN/ routed prefix.

Er wordt trouwens niet bedoeld dat je WAN gateway address ::0 moet zijn, maar dat je ::0 moet routeren naar je PPP- interface. Vaak wordt dit door de router al voor je gedaan, net zoals 0.0.0.0 naar je PPP- interface gerouteerd wordt.

Werkt HvN niet met DHCPv6 prefix delegation en moet je alles echt statisch configureren?

Goeie vraag, ik heb van HvN een adresblok gekregen abcd.efgh.ijkl.mnop::/64 een tweetal DNS servers en een SMTP server.Met die gegevens zou je denken dat het toch geen static IPv6 zou zijn.

Ik heb vanavond het een en ander zitten knoeien, waarbij ik soms heel even een IPv6 met de buitenwereld heb. In dat geval heb de WAN gateway ingesteld op het LAN adres en dan zie ik in de routetabel dat er het een en ander word gerouteerd naar de ppp0 interface. Maar zoals gezegd is dat heel tijdelijk en daarna is de pc ook weer de verdwenen uit het IPv6 DHCP overzicht.

databeestje schreef op dinsdag 28 juli 2015 @ 20:14:
De Asus zou de RA op moeten pikken vanaf de zijde van HvN, zeker als het semi statisch geconfigureerd is moet daar ook een announcement vandaan komen. De gateway is normaal gesproken een fe80::1 link-local adres. Al staan sommige ook een publiek adres hier toe, dit is niet strikt noodzakelijk.

fe80::1 wordt vaak voor de gateway gebruikt, deze kan je zonder problemen op meerdere interfaces gebruiken.

Nu fe80::1 ingesteld als gateway en daarna wel meteen weer een IPv6 verbinding. nu kijken of die stand houd.

[ Voor 18% gewijzigd door MegaTronics op 28-07-2015 20:18 ]

[databeestje]

Is er niet een firmware update voor de Asus? Of is dit al de meest recente?

[MegaTronics]

databeestje schreef op dinsdag 28 juli 2015 @ 20:22:
Is er niet een firmware update voor de Asus? Of is dit al de meest recente?

De laatste Merlin staat erop. Het lijkt erop dat de fe80::1 gateway de oplossing was voor de connectie problemen. Tot nu toe nog steeds IPv6 online.

[MegaTronics]

Jaap-Jan schreef op dinsdag 28 juli 2015 @ 19:54:
Je WAN ip ligt meestal in een andere reeks als je LAN/ routed prefix.

Is dat dan een compleet ander IP adres of is het een aanpassing op het externe blok?

Het zijn misschien beginnersvragen, maar ik moet toch ergens beginnen .

[Verwijderd]

MegaTronics schreef op dinsdag 28 juli 2015 @ 20:36:
[...]


Is dat dan een compleet ander IP adres of is het een aanpassing op het externe blok?

Het zijn misschien beginnersvragen, maar ik moet toch ergens beginnen .

Dat is een compleet ander adres als je WAN IP een unicast adres is (bv 2001:xxx:xxxx::1). Maar omdat je een link local adres gebruikt (FE80::1) maakt dit niet uit.

[MegaTronics]

Ondertussen bokt de verbinding weer, dus iets zit er nog niet goed. Ik ga verder experimenteren.

[Jaap-Jan]

Kun je niet gewoon DHCPv6 prefix delegation instellen i.p.v. Static IPv6? Of misschien iets van native IPv6? Zo'n optie zit er bij mij in bij Tomato.

[ Voor 34% gewijzigd door Jaap-Jan op 28-07-2015 20:55 ]

[MegaTronics]

Jaap-Jan schreef op dinsdag 28 juli 2015 @ 20:54:
Kun je niet gewoon DHCPv6 prefix delegation instellen i.p.v. Static IPv6? Of misschien iets van native IPv6? Zo'n optie zit er bij mij in bij Tomato.

Ondertussen werkt het weer via de static settings. Er bleek een VPN client gestart te zijn wie roet in het eten gooide.

De optie Native heb ik ook geprobeerd, maar daar gebeurt weinig.

[ Voor 8% gewijzigd door MegaTronics op 28-07-2015 21:04 ]

[Jerrythafast]

Verwijderd schreef op dinsdag 28 juli 2015 @ 12:05:
Maar toch nog goed nieuws vandaag, voor het eerst tot (ik denk 1 week geleden?) is er iets over IPv6 op de ziggo site te vinden.

https://www.ziggo.nl/klantenservice/internet/verbinding/ipv6

Lijkt erop dat dat gewoon gekopieerd is van een oude pagina van de UPC-website.

Verandert de stabiliteit van mijn UPC-verbinding na de invoering van IPv6?
De invoering van IPv6 heeft geen invloed op de netwerkstabiliteit.

Waarom zei ik specifiek "een oude pagina"?

Welke besturingssystemen ondersteunen IPv6?
Vrijwel alle besturingssystemen kunnen omgaan met IPv6. Hieronder ziet u een beknopt overzicht van de meest voorkomende besturingssystemen die IPv6 ondersteunen:

• Windows 8
• Windows 7
• Windows XP (vanaf SP1)
• Windows Vista
• OS X (vanaf versie 10.7)
• De nieuwste versies van Android en iOS

Windows 10 en zelfs 8.1 worden niet genoemd, en het al lange tijd afgeschreven Windows XP staat er wel tussen

Misschien hebben ze deze pagina er even vlug opgegooid omdat ze wel errug veel vragen kregen van klanten die ergens hadden gelezen dat Ziggo "IPv6" op hun verbinding ging uitzetten en bang waren dat ze van internet zouden worden afgesloten ofzo

[Verwijderd]

Even positief bekeken, het is meer dan "IPv6 > niets gevonden" en er is omdat er een pagina is nu een mogelijkheid om feedback te geven.

Het blijft verwondelijk dat het allemaal zo moeizaam gaat bij Ziggo.

[Jerrythafast]

Absoluut mee eens hoor! Net zoals een firmware in mijn Ubee 321b die wel IPv6-opties heeft toch een stap verder is dan een firmware zonder IPv6-opties. Dat er nou nog steeds geen prefix is uitgedeeld is dan weer jammer

[CyBeR]

Bleh, het vol zitten van de IPv6 space is ook alweer in zicht: https://samsclass.info/ipv6/exhaustion.htm

[MegaTronics]

Als het systeem net is opgestart dan werkt de IPv6 gewoon, maar naar verloop van tijd is de connectie niet meer bruikbaar. Het betreffende systeem is dan ook verwijderd uit de lijst van IPv6 DHCP clients van de router. Hij heeft het wel even gedaan want bijvoorbeeld newszilla van Xs4All werkte gewoon.

[ Voor 44% gewijzigd door MegaTronics op 29-07-2015 07:30 ]

[databeestje]

Het klinkt als een hele vreemde situatie, het verdwijnen van de client uit de dhcp6 lijst doet me voorkomen dat het probleem misschien niet de router of de verbinding is. Kan het zijn dat je een firewall hebt die IPv6 ICMP blokkeert.

Als die RA blokkeert dan snap ik wel dat de PC op een gegeven moment na het verlopen van de RA timer de lease en adressen opgeeft.

Ik doel dan op de software firewall op de PC.

[MegaTronics]

Volgens de Windows firewall staat dat RA deel gewoon open en IPv6 ICMP staat ook open door de File sharing. Of er moet nog een extra optie open in de firewall voor een succesvolle IPv6. We gaan weer Googlen.

[ Voor 32% gewijzigd door MegaTronics op 29-07-2015 08:32 ]

[Ximon]

Bigs schreef op dinsdag 28 juli 2015 @ 13:26:
[...]


Als je dat een vreemde gang van zaken vindt dan onderschat je denk ik de complexiteit en omvang van een organisatie als Ziggo. Ik kan me goed voorstellen dat ze ineens een stijging zien in support calls die samenvalt met het grootschalig inschakelen van IPv6. Er komen duizenden calls per dag binnen en er wordt per call maar beperkt gelogd (waarbij de probleemanalyse van eerste lijns agents waarschijnlijk ook nog eens te kort schiet). Het kan wel even duren om in al die informatie uit te zoeken of er een verband is, het is niet dat ze even de call database doorzoeken op 'ipv6 issue' en dan het probleem te pakken hebben. Dat je dan een niet-essentiële feature weer uitschakelt vind ik dan wel begrijpelijk.

Onvoorziene problemen heb je overigens met elke technische aanpassing, groot of klein. Noem maar het voorbeeld van een printer die zich ineens anders gedraagt doordat er IPv6 in het thuisnetwerk wordt aangekondigd. Je kunt als provider niet alles voorzien, maar je klanten komen wel bij jou aankloppen.

(aldus de ex UPC storingsdienst medewerker)

Dat bedoel ik dus met geen commitment. Het lijkt alsof ergens in het bedrijf een IPv6 testtrajectje opgestart is, maar de servicedesk schijnbaar niet goed genoeg getraind werd om met deze nieuwe techniek om te gaan. Dan wordt het inderdaad als niet-essentiële feature gezien, en dat zou ik erg teleurstellend vinden. IPv6 bestaat al erg lang, en de uitrol ervan wordt al bijna net zo lang aan de kant geschoven onder dit motto. Als ze gaan wachten totdat Ziggo een minder grote en complexe organisatie is duurt het ook nog wel even voordat IPv6 uitgerold kan worden.

Misschien speelt er iets wat niet in de pers gemeld wordt, bijvoorbeeld dat de stabiliteit of beveiliging van het core netwerk in gevaar is. Ziggo zou dat dan beter moeten communiceren, dat kan ook zonder in detail uit te leggen wat er aan de hand is. Wat er nu verteld wordt leidt alleen maar (i.i.g. bij mij) tot onbegrip.

[Paul]

CyBeR schreef op woensdag 29 juli 2015 @ 02:54:
Bleh, het vol zitten van de IPv6 space is ook alweer in zicht: https://samsclass.info/ipv6/exhaustion.htm

Volgens die site wordt er maar één IPv6-verbinding opgeleverd per 2,9*10¹¹ jaar... Dat moet sneller mensen!

[Verwijderd]

Bigs schreef op dinsdag 28 juli 2015 @ 13:26:
[...]


Als je dat een vreemde gang van zaken vindt dan onderschat je denk ik de complexiteit en omvang van een organisatie als Ziggo. Ik kan me goed voorstellen dat ze ineens een stijging zien in support calls die samenvalt met het grootschalig inschakelen van IPv6. Er komen duizenden calls per dag binnen en er wordt per call maar beperkt gelogd (waarbij de probleemanalyse van eerste lijns agents waarschijnlijk ook nog eens te kort schiet). Het kan wel even duren om in al die informatie uit te zoeken of er een verband is, het is niet dat ze even de call database doorzoeken op 'ipv6 issue' en dan het probleem te pakken hebben. Dat je dan een niet-essentiële feature weer uitschakelt vind ik dan wel begrijpelijk.

Onvoorziene problemen heb je overigens met elke technische aanpassing, groot of klein. Noem maar het voorbeeld van een printer die zich ineens anders gedraagt doordat er IPv6 in het thuisnetwerk wordt aangekondigd. Je kunt als provider niet alles voorzien, maar je klanten komen wel bij jou aankloppen.

(aldus de ex UPC storingsdienst medewerker)

Als dingen complex zijn, moet je het gefaseerder voorbereiden en meer testen. Tevens bv een helpdesk voorzien van een aantal basis stappen waardoor kan worden vastgesteld of het een IPv6 uitrol probleem is. Tevens zou je verwachten dat een senior uit het IPv6 project voor een x periode wordt toegewezen aan een servicedesk zodat deze zelf direct kan inschatten hoe de uitrol verloopt en zelf de instructies van de servicedesk eventueel kan uitbreiden in overleg met de servicedesk coordinator. Verder dat deze contact heeft met zijn eigen IPv6 projectteam om hun op de hoogte te houden van wat er speelt.

Dit is pro-actief een project in productie brengen, niet reactief iets starten en bij problemen eens kijken of er iets te vinden valt en als je dat niet lukt zaken terugdraaien.

Over hypothetische situaties met thuis aparaten die mogelijk anders zouden werken heb ik zelf nog maar bar weinig gelezen mbt tot IPv6 uitrol. Die moeten dus ook als incident worden aangemerkt totdat een oorzaak gevonden is.

Het is nu niet echt dat Ziggo voorop loopt, Xs4all, Telenet en diverse grote Amerikaanse ISP's hebben dit al lang gedaan en blijkbaar is het mogelijk. Vele van deze partijen zijn overigens gewoon gestart met een pilot traject / opt-in waardoor zoals eerder gemeld mensen met iets meer goodwill en kennis al een hoop, zo niet alle issues op de kaart kunnen zetten.

[Roetzen]

Paul schreef op woensdag 29 juli 2015 @ 10:19:
[...]
Volgens die site wordt er maar één IPv6-verbinding opgeleverd per 2,9*10¹¹ jaar... Dat moet sneller mensen!

s/,/./

Dan worden het er twee per seconde.

[Verwijderd]

Iemand een windows 10 download gestart?
https://ams-ix.net/techni.../sflow-stats/ipv6-traffic

[Nakebod]

* Nakebod steekt hand op
Dat zal inderdaad wel een leuk grafiekje worden vandaag / de komende dagen.

[Paul]

Roetzen schreef op woensdag 29 juli 2015 @ 10:47:
[...]

s/,/./

Dan worden het er twee per seconde.

Input Exception: Too many decimal seperators...

Er gaat twee adressen per seconde vanaf. Iedere verbinding krijgt één subnet (en dan heb ik het nog niet over subnetten die naar je toe worden gerouteerd) en ieder subnet bevat minimaal 2^64 adressen. 2^64 / 2 per seconde = 2^63 seconde of 2,9 * 10¹¹ jaar

[Snow_King]

Verwijderd schreef op woensdag 29 juli 2015 @ 11:55:
Iemand een windows 10 download gestart?
https://ams-ix.net/techni.../sflow-stats/ipv6-traffic

[afbeelding]

Gaaf! Zo zien we het graag. Méér IPv6 verkeer, méér.

Al kan de stijging hard gaan zodra consumenten online gaan. Youtube en Netflix zijn volledig over IPv6 bereikbaar.

[.oisyn]

Nakebod schreef op woensdag 29 juli 2015 @ 12:26:
* Nakebod steekt hand op
Dat zal inderdaad wel een leuk grafiekje worden vandaag / de komende dagen.

D'r zit momenteel iemand van Microsoft bij ons op kantoor, hij zei dat ze iets van 12TB/s de deur uit deden door de Windows 10 downloads (in totaal, natuurlijk niet op 1 locatie)

[Freeaqingme]

Terabit per second, of Terabyte per seconde?

[Roetzen]

Paul schreef op woensdag 29 juli 2015 @ 12:56:

Er gaat twee adressen per seconde vanaf. Iedere verbinding krijgt één subnet (en dan heb ik het nog niet over subnetten die naar je toe worden gerouteerd) en ieder subnet bevat minimaal 2^64 adressen. 2^64 / 2 per seconde = 2^63 seconde of 2,9 * 10¹¹ jaar

Ah, bedoel je het op die manier. De teller geeft waarschijnlijk het aantal daadwerkelijk in gebruik genomen IPv6 adressen weer. Hoe ze dan aan twee per seconde komen is me ook niet duidelijk. Maar ja, als het inderdaad het aantal daadwerkelijk in gebruik genomen adressen is, dan is het natuurlijk geen goede maat voor de snelheid waarmee ze opraken. Want inderdaad, het gaat minimaal met een /64. Daarvan zal de overgrote meerderheid van de adressen ongebruikt blijven, maar ze zijn dan wel "op" in de zin dat je ze niet alsnog aan iemand anders kan geven.

Ach, het is maar een grapje. De getallen die aangevoerd worden ter vergelijking zijn ook maar een slag in de lucht. Die van de leeftijd van de zon zal er geen factor twee naast zitten, maar de rest kan best een paar ordes van grootte afwijken. Als het heelal al niet op een andere wijze voortijdig aan zijn eind komt...

[.oisyn]

Freeaqingme schreef op woensdag 29 juli 2015 @ 14:20:
Terabit per second, of Terabyte per seconde?

Ja daar twijfelde ik dus nog even over. Volgens mij zei ie byte, niet bit. 12 Terabyte/s klinkt wel wat veel

[martijnr17]

databeestje schreef op zondag 26 juli 2015 @ 19:49:
PI aanvragen is niet zo bijzonder hoor, 2 weken geleden nog gedaan.

ULA gebruiken voor meer dan een subnet is lastig, omdat het routering impliceert, de kans is groot dat een apparaat gaat proberen met zijn ULA op het internet te komen.

Daarnaast, niet alleen een IPv4 routing tabel, maar ook nog 2 verschillende IPv6 routing tabellen. Ik weet niet waarom dat een voordeel zou zijn.

De firewall rules voor IPv6 zijn imho niet zo moeilijk, en met maar 1 range is het iig doorzichtig. Beter iig dan met IPv4 waar bij de 1:1 NAT het externe adres gebruikt en de firewall rule weer voor het interne (prive) adres is. Nu alleen nog maar rules, lekker overzichtelijk.

Bij ons op het werk en de andere locaties gebruiken we gewoon een PI IPv6 prefix, ik heb daar helemaal geen moeite mee. Ik kan, als het echt allemaal zo'n punt is, altijd nog NPt gaan gebruiken met de "oude" prefix, maar dan blijft het bij 1 routing tabel. ULA met NPt kan ook, maar niet alles ondersteunt dat.

Ik ben me ook een beetje aan het verdiepen in ipv6 voor ons bedrijf. 1 hoofdlocatie en 12 kleine buitenlocaties.
En je kan natuurlijk de ip adressen gebruiken van je provider maar zeker op de hoofdlocatie wordt ik daar ook niet echt gelukkig van.
Zon PI wat zijn daar nou de nadelen van en kosten?

Verder zat ik ook nog in het hokje van site to site vpn wat dus geen goede oplossing is. Maar nu moet ik me dus gaan verdiepen hoe je ipsec aanzet op ipv6, niet al het verkeer tussen locaties is versleuteld dus dan wil ik over die verbindingen wel ipsec daar kan ik helaas nog weinig over vinden.

Heb nu ook 2 ipv6 boeken voor me liggen die ik maar rustig moet gaan doorspitten.

[ Voor 12% gewijzigd door martijnr17 op 29-07-2015 15:51 ]

[Snow_King]

martijnr17 schreef op woensdag 29 juli 2015 @ 15:45:
[...]


Ik ben me ook een beetje aan het verdiepen in ipv6 voor ons bedrijf. 1 hoofdlocatie en 12 kleine buitenlocaties.
En je kan natuurlijk de ip adressen gebruiken van je provider maar zeker op de hoofdlocatie wordt ik daar ook niet echt gelukkig van.
Zon PI wat zijn daar nou de nadelen van en kosten?

Verder zat ik ook nog in het hokje van site to site vpn wat dus geen goede oplossing is. Maar nu moet ik me dus gaan verdiepen hoe je ipsec aanzet op ipv6, niet al het verkeer tussen locaties is versleuteld dus dan wil ik over die verbindingen wel ipsec daar kan ik helaas nog weinig over vinden.

Heb nu ook 2 ipv6 boeken voor me liggen die ik maar rustig moet gaan doorspitten.

Als je Pi space wil kan dat, maar je ISP op ELKE locatie moet BGP voor je kunnen routeren.

Je kan dan bij RIPE deze space aanvragen en vervolgens je ISP verzoeken deze voor je te adverteren.

[databeestje]

martijnr17 schreef op woensdag 29 juli 2015 @ 15:45:
[...]


Ik ben me ook een beetje aan het verdiepen in ipv6 voor ons bedrijf. 1 hoofdlocatie en 12 kleine buitenlocaties.
En je kan natuurlijk de ip adressen gebruiken van je provider maar zeker op de hoofdlocatie wordt ik daar ook niet echt gelukkig van.
Zon PI wat zijn daar nou de nadelen van en kosten?

Hier worden de jaarlijkse kosten verrekend met de glas aansluitingen, ik zou uit moeten zoeken wat de fee is die we betalen, als deze al gespecificeerd is. We betalen ongeveer 1700 per maand voor 2 100Mbit aansluitingen met BGP. In september wordt er een nieuw opgeleverd en gaan we terug naar 1200 euro per maand, deze moet nog gegraven worden.

PI is gewoon IPv6. Ben je niet van plan om ooit van ISP te veranderen dan kan je bijvoorbeeld ook PA space aanvragen. Deze zal jouw provider dan adverteren en toekennen aan jouw aansluitingen. Maar je krijgt dan wel een aparte prefix, je kan deze alleen niet makkelijk overzetten.

De PI kan je als bedrijf blijven gebruiken, maar ben je wel vrij bij welke partij je de bandbreedte inkoopt. De tarieven daarvan verschillen nogal.

Overigens, maakt het echt uit wat voor prefix de andere aansluitingen hebben. De hoofdlocatie is hier de grotere uitzondering denk ik. Een satteliet kantoor hernummeren met ~10 pc's en een printer en een server is niet zo spannend. Waarschijnlijk veroorzaakt door het wisselen van provider oid. Als je mazzel hebt kan je uberhaupt de eigen CPE kiezen (KPN Zakelijk internet, ik kijk naar jou)

Verder zat ik ook nog in het hokje van site to site vpn wat dus geen goede oplossing is. Maar nu moet ik me dus gaan verdiepen hoe je ipsec aanzet op ipv6, niet al het verkeer tussen locaties is versleuteld dus dan wil ik over die verbindingen wel ipsec daar kan ik helaas nog weinig over vinden.

Net als met IPsec onder 4? Ik heb een IPsec IPv6 tunnel met pfSense tussen een paar locaties. Maar eerlijk gezegd gebruik ik tegenwoordig liever OpenVPN hiervoor. Dan kan ik makkelijker meer netwerken toevoegen en verwijderen. En het beheert ook een stuk prettiger.

pfSense ondersteunt OpenVPN met een dual-stack tunnel waarbij je zelf kan bepalen of je deze over een 4 of 6 drager stuurt.

In de Draytek vigor daarentegen heb ik ze niet gezien. Daar is het misschien makkelijker om firewall rules aan te maken voor de externe prefixen. Wellicht dat nieuwere kastjes dan de 2850 dit wel ondersteunen.

Heb nu ook 2 ipv6 boeken voor me liggen die ik maar rustig moet gaan doorspitten.

Van het boek hier heb ik maar een stukje gebruikt, toen viel het kwartje, de rest gebruik ik als naslag.

Zo is het gebruikelijke /24 - /22 LAN nu een /64.
De gateway definieer je niet meer in een config, deze kondigt zichzelf aan via een RA.
Linker 64 bits = netwerk, rechter 64 bits doet er niet toe.

Lees zeer zeker het stukje over route aggregatie, dat helpt enorm, dit ivm routeren in plaats van plat toewijzen. Route aggregatie is een ding.

Ik krijg een /48, ik buig een /52 af naar het firewall cluster, hiervan alloceer ik een /56 uit voor het DMZ, een /56 voor VPN en een /56 voor de VLAN netwerken. Hierdoor kan ik 256 netwerken (of 2 hex posities) gebruiken voor VLAN identificatie.

Door deze constructie is firewallen intern ook makkelijk, het is onderdeel van verschillende /56 prefixes.

[CAPSLOCK2000]

De data over de AMS-IX is weer spectaculair gegroeid. We hebben deze week een verdubbeling gezien. Misschien is er weer een ISP aan het experimenteren of misschien ligt het aan Windows 10. Het gaat in ieder geval wel lekker.

[Raven]

Ik gok W10

[Roetzen]

Als het W10 is, dan zou de data voor IPv4 ook moeten toenemen. De meeste klanten hebben immers nog geen IPv6.

[Verwijderd]

Roetzen schreef op woensdag 29 juli 2015 @ 18:36:
Als het W10 is, dan zou de data voor IPv4 ook moeten toenemen. De meeste klanten hebben immers nog geen IPv6.

Ik denk dat een eventuele 100Gb/sec niet echt opvalt in TB/sec gegevens.

[CyBeR]

Inderdaad. Daar moet je goed je best doen om op te vallen.

[Maurits van Baerle]

Het enige wat mij doet denken dat het niet Windows 10 verkeer is is dat het zo aan/uit is. Als het inderdaad een hoop mensen waren geweest die vandaag W10 downloaden zouden hun individuele downloads bij elkaar opgeteld toch een soort geleidelijke toename moeten laten zien.

Dit lijkt er eerder op alsof iemand (een ISP? Hele grote peeringklant?) steeds ergens een schakelaar aan, uit, aan, uit zet...

[ Voor 3% gewijzigd door Maurits van Baerle op 29-07-2015 19:05 ]

[Verwijderd]

Met een 72Gb/sec piek is het toch wel een speciale dag. Relatief gezien tot IPv4 is het maar weinig maar absoluut is het wel een gigantische hoop data iedere seconde.

[ Voor 4% gewijzigd door Verwijderd op 29-07-2015 22:15 ]

[Roetzen]

Paul schreef op woensdag 29 juli 2015 @ 12:56:
[...]
Er gaat twee adressen per seconde vanaf. Iedere verbinding krijgt één subnet (en dan heb ik het nog niet over subnetten die naar je toe worden gerouteerd) en ieder subnet bevat minimaal 2^64 adressen. 2^64 / 2 per seconde = 2^63 seconde of 2,9 * 10¹¹ jaar

Klik even op "Alternate Method: Allocated /48 Prefixes" onder aan de pagina. Dan krijg je een aftelling die je meer zal bevallen denk ik.

[Raven]

Hmm, de Windows 10 VM krijgt een hogere score op ipv6-test.com dan de host

Score 18 / 20

How can you improve your score ?

1. Upgrade your web browser
Your web browser won't fall back to the other protocol in a timely manner when its default is advertised by a website but happens to be unavailable. Recent versions of Firefox or Chrome can deal with this transparently.

2. Get a reverse DNS record

Blijkbaar laat de W10 firewall ICMPv6 door, iets dat ESS op W7 nog altijd niet wil doen. (ESET over gemaild, waar die instellingen zijn te vinden, willen ze met TeamViewer de pc overnemen )

Puntje 1 is een verbeterpunt voor Edge, blijkbaar moeten ze op dat gebied er nog wat aan sleutelen. Feedback ingestuurd via de daarvoor bedoelde knop in Edge.

[ Voor 18% gewijzigd door Raven op 30-07-2015 20:59 ]

[Bigs]

Klopt die ICMP beoordeling van ipv6-test.com wel? Het lijkt me niet eenvoudig die packet too big meldingen vanuit hun positie te testen. Ik heb soms het vermoeden dat ze gewoon ICMP PING testen en op basis daarvan hun conclusie trekken, wat niet correct hoeft te zijn.

Weet iemand een publieke host met met een lage Path MTU (<1444 bytes) waarmee ik eens kan testen of de melding van ipv6-test.com klopt?

[Raven]

De melding is reproduceerbaar en verdwijnt als ik de ESET firewall uitzet. Plus het zou kunnen verklaren waarom ik een paar maand terug weer MTU-issues leek te hebben. Als die pakketjes inderdaad geblokkeerd worden... In de router-pc worden ze iig doorgelaten naar de clients.


Na wat geGoogle kwam ik http://www.letmecheck.it/mtu-test.php tegen, die doet het niet met de ESET firewall ingeschakeld. Zet ik 'm uit, dan doet de test prima.