Ziggo begint met uitrol van ipv6

Ziggo is begonnen met de uitrol van ipv6. Zesduizend klanten hebben een ipv6-adres gekregen; de meeste klanten volgen in de rest van het jaar. Het gaat vooralsnog enkel om klanten uit het Ziggo-gebied, en niet om UPC-klanten.

ZiggoOp het forum 'Ziggo-gebruikers.nl' melden meerdere users dat ze een ipv6-adres hebben gekregen. Ziggo-woordvoerder Gradus Vos bevestigt desgevraagd dat Ziggo is begonnen met de uitrol van het nieuwe internetprotocol. "We zijn vorige week begonnen", bevestigt Vos. "Zesduizend gebruikers hebben nu een ipv6-adres gekregen."

Ziggo-klanten met een Cisco 3925, Cisco 3928, Ubee EVW 320 en Ubee EVW 321b zijn als eerst aan de beurt en krijgen dit jaar nog een ipv6-adres. De uitrol hangt af van het routertype en de regio, aldus Vos. "We kunnen mensen dus helaas niet eerder een ipv6-adres geven als ze daar om vragen." Klanten met een ouderwets kabelmodem, dat enkel als modem en niet als router dienstdoet, krijgen pas volgend jaar een ipv6-adres.

De provider rolt het nieuwe internetprotocol dual-stack uit: klanten krijgen dus zowel een ipv4- als een ipv6-adres. Dat moet ook wel, aangezien het gros van de websites nog niet via ipv6 te bereiken is. Ziggo schakelt de firewall standaard in; dat is nodig omdat interne apparaten ook een publiek ipv6-adres krijgen en daardoor zijn te bereiken vanaf het internet. Desgewenst kunnen ze de firewall uitzetten of anders configureren. Het is overigens onduidelijk hoe groot het subnet is dat klanten krijgen.

Hoewel Ziggo en UPC zijn gefuseerd tot één provider en de merknaam UPC volgende week verdwijnt ten gunste van Ziggo, geldt de ipv6-uitrol vooralsnog enkel voor Ziggo-klanten. UPC gaf eerder al aan snel te willen beginnen met de uitrol van ipv6, maar het is nog onduidelijk wanneer klanten een ipv6-adres krijgen.

Het aantal ipv4-adressen is aan het opraken; een overstap naar ipv6 wordt gezien als de enige optie om het internet te kunnen laten groeien. Waar er circa 4,3 miljard ipv4-adressen zijn, ligt het aantal ipv6-adressen fors hoger. Er zijn om en nabij de 340 sextiljoen ip-adressen - dat is een getal van 39 cijfers - wat betekent dat er per aardbewoner veel meer ipv6-adressen beschikbaar zijn dan dat er in totaal ipv4-adressen zijn. Een nadeel is echter dat ipv4- en ipv6-packets niet compatibel zijn; daardoor is het noodzakelijk dat het hele internet het nieuwe protocol in gebruik neemt.

Door Joost Schellevis

Redacteur

07-04-2015 • 12:06

267 Linkedin

Reacties (267)

267
266
213
4
0
0
Wijzig sortering
Ik wil geen IPv6, want dan heb ik ongeveer 3% minder bandbreedte (*). En ik heb al zo weinig.

(*) 3% is gebaseerd op de grootte van de IP header t.o.v. het maximale pakket van 1500 bytes.
Hoe heb je dat berekend? De IP header gaat van 20 naar 40 bytes. Ik kom dan op 1,33% minder bandbreedte uit bij pakketjes van 1500 bytes.

Overigens dwingt IPv6 een minimum pakket grootte (voor all betrokken routers) af van 1280 bytes, waar dat met IPv4 576 bytes is. Dit kan hier en daar weer wat overhead schelen.
Dan blijff jij lekker op IPv4 en heb je vroeg of laat helemaal geen internet meer.
Gezien het groeitempo van internet is die 3% niet echt interessant.
In theorie kan IPv6 ook sneller zijn omdat het makkelijker is om het in hardware af te handelen.
In theorie althans, in praktijk wordt de meeste energie nog in IPv4 gestoken en is de IPv6-hardware minder geoptimaliseerd.
Ergens heeft hij een punt(je): voor lang niet alle regios en gebieden geldt dat er snel internet beschikbaar is, lang niet iedereen kan zich een upgrade veroorloven.
Tegelijkertijd denk ik wel dat de optimalisaties in IPv6 er voor zorgen dat die 3% verlies (als het dat al is) echt merkbaar zal zijn... :)
Ik zie het punt wel hoor maar het is in minder gevallen van toepassing is dan je misschien zou denken. Internet werkt namelijk niet in losse bytes maar in pakketjes. In de meeste gevallen worden die pakketjes als geheel behandeld, onafhankelijk van hoe groot ze nu zijn. Of een pakketje nu 10 of 1000 bytes bevat, het wordt even snel behandeld en het kost even veel. Veruit de meeste pakketjes zijn klein. Als ik even naar de AMSIX kijk zie ik dat 40% van de pakketjes < 127 bytes is en minder dan 20% "vol" zit (strict genomen heb ik het over frames maar wie dat verschil kent die hoef ik niks uit te leggen).
Bij het allergrootste deel van de pakketjes is er dus nog ruimte over waardoor langere adressen geen effect hebben.
Hopelijk gaat TCP Fast Open hier een flinke impact op hebben.
Goed argument.

Misschien dat je SLIP kunt draaien ? :)
Serial Line IP is een oud protocol. Het is vervangen door PPP. Maar SLIP had header-compression. Wat heel erg hielp als je vroeger een 56k modem (of langzamer had).

Blijkbaar bestaat er SLIP voor IPv6.
https://github.com/maniac...igduino/wiki/Using%3ASLIP
Onduidelijk of het header-compression heeft. Dat artikel insinueert van wel.

Het grootste probleem wordt natuurlijk om je ISP te overtuigen ook SLIPv6 te doen. :)
Maar alles is mogelijk !
Mijn practische ervaring is dat IPv6 sneller is dan IPv4 en het bandbreedte verschil valt wel mee.
De IPV6 header kent veel meer optionele sub headers, die er alleen ingezet worden indien nodig, ipv een vast packet structuur zoals IPv4 heeft. Daardoor vervallen verplichte lege plekken.

Jij praat over het Ethernet pakket van 1500 bytes (wat niet veranderd) versus het IP packet dat in een of meer ethernet packets verpakt wordt.
Als de interne apparaten ook een ipv6 adres krijgen werk de router functionaliteit dus dan niet meer? Dus geen interne lan functionaliteit? En geen port forwarding etc?
Je verwart NAT en routeren. Als er méér dan één apparaat is aangesloten op je internetverbinding heb je hoe dan ook een router nodig. Deze routeert tussen je eigen subnet en het publieke internet. Voeg je daar NAT aan toe zoals op hedendaagse internetverbindingen gebruikelijk is, dan krijg je er zaken als port forwarding bij, omdat alle interne IP-adressen vertaald worden naar één publiek IP-adres en terug. Dat is met IPv6 niet meer nodig aangezien elk apparaat een publiek IPv6 IP-adres kan krijgen. Een gevolg daarvan is dat je theoretisch gezien vrij kwetsbaar bent, waardoor de port forwarding eigenlijk per direct vervangen dient te worden door een firewall in de router, die zorgt dat alleen poorten die explicitiet opengesteld zijn bereikbaar zijn. Dit wordt door, zoals in het nieuwsbericht te lezen is, ook standaard ingeschakeld bij Ziggo.

Een 'intern LAN', gedefinieerd als privé IP-adressen, hou je wel voor IPv4 maar niet voor IPv6. Al is het technisch gezien natuurlijk wel mogelijk. Echter, NAT gebruiken als security measure is sowieso een slecht idee, daar is het niet voor bedoeld, dan kun je beter gewoon een fatsoenlijke firewall-functie in de router hebben. Daarbuiten zijn er weinig bezwaren om publieke IPv6-adressen te hebben.
Betekent dit dat de modem/router die ik heb van ziggo dus niet meer als router zal gaan fungeren? Dus geen intern en externe ip-adressen meer dus. Dus in feite wordt het een switch
Portforwarding en NAT zal niet meer nodig zijn met IPv6.
Een fatsoenlijke firewall oplossing op je edge wel.

Ieder apparaat dat je thuis hebt krijgt gewoon zn eigen IPv6 adres.
Een nadeel is echter dat ipv4- en ipv6-packets niet compatibel zijn; daardoor is het noodzakelijk dat het hele internet het nieuwe protocol in gebruik neemt.
Hoe gaat dit dan precies in zijn werk? Kunnen er problemen optreden totdat de hele wereld over is op ipv6?
En wanneer is de wereld over op IPv6? Het duurt al een hele poos en ik schat zo in dat het ook nog wel ff kan duren.
Anoniem: 470811
@iAR7 april 2015 12:25
Ik schat in dat tussen de 4 en 8 jaar dat IPv6 de facto standaard is. Amerikaanse bedrijven zijn al ergens sinds begin 2000 verplicht om IPv6 ondersteuning aan te bieden in apparatuur en software met een netwerkkoppeling (wanneer ook IPv4 gebruikt wordt).

Als straks alle grote internet en hostings providers op IPv6 draaien dan wordt IPv6 al snel de default, en later de enige. De remaining IPv4 omgevingen hebben dan denk ik pech.
Heb je een bron? Ik ken genoemde verplichting niet. Ik twijfel er aan of je gelijk hebt.

Microsoft (redelijk Amerikaans) bood weliswaar IPv6 in XP aan, maar niet in 2000, en ook niet productierijp. Microsoft adviseerde zelf (bron heb ik even niet) Vista als minimum te gebruiken. Dus ik kan aan zekerheid grenzende waarschijnlijkheid vaststellen dat Microsoft zelf al geen IPv6 bood in Windows in 2000.

De markt waar IPv6 het meest gebruikt wordt, is de markt waar IPv4 het eerste op is. Dat lijkt in de APAC regio eerder geval te zijn dan US/Europe. Van Afrika weet ik niet hoe groot/klein de IPv4 voorraad nog is.

En uitzetten van IPv4 zie ik pas gebeuren als er geen significant gebruik van is. Ik schat in dat de termijn hiervoor eerder 10-tallen jaren is dan enkele jaren. Ik kan me niet voorstellen dat de stekker van IPv4 er uitgetrokken wordt, onder het motto 'pech hebben'. Er zal een regen aan klachten ontstaan.

En technisch: ik krijg het nu (nog) niet voor elkaar een Windows of Linux machine IPv6 only te laten werken. Het is of IPv4 only, of IPv4 + IPv6, maar niet alleen IPv6. Op dat gebied verwacht ik de komende jaren ook nog geen uitzetten van IPv4.

[Reactie gewijzigd door kdekker op 7 april 2015 16:30]

Heb je een bron? Ik ken genoemde verplichting niet. Ik twijfel er aan of je gelijk hebt.
De Amerikaanse overheid heeft een regel dat spullen voor de overheid in principe IPv6 moeten ondersteunen. In praktijk houdt lang niet iedereen zich daar even goed aan. De Nederlandse overheid heeft trouwens ook zo'n regel (https://lijsten.forumstan...en-standaard/ipv6-en-ipv4)
De markt waar IPv6 het meest gebruikt wordt, is de markt waar IPv4 het eerste op is. Dat lijkt in de APAC regio eerder geval te zijn dan US/Europe. Van Afrika weet ik niet hoe groot/klein de IPv4 voorraad nog is.
En uitzetten van IPv4 zie ik pas gebeuren als er geen significant gebruik van is.
Ik geloof niet dat er ooit een dag komt dat IPv4 "uit" gezet wordt. Het zal er langzaam uit groeien. Als je goed zoekt kun je vandaag de dag nog steeds tokenringnetwerken en 2400bps telefoonmodems vinden. Het wordt alleen steeds moeilijker om nog te kopen en er zijn steeds minder plekken waar het gebruikt wordt. Er is geen centrale baas op internet die IPv4 uit kan zetten, het zal stukje bij beetje gaan. Nu zijn er al budgethosters die je korting geven op IPv6-only hosts. In de toekomst zal je wel moeten gaan bijbetalen voor IPv4. Nog later zijn er nog maar een paar hosters over die IPv4 bieden. Echt helemaal "uit" is nog zo ver weg dat we er niet eens over kunnen speculeren.
En technisch: ik krijg het nu (nog) niet voor elkaar een Windows of Linux machine IPv6 only te laten werken.
Het kan wel. Kom anders even op het forum langs dan kijken we mee. Het is me al een paar keer overkomen dat onze DHCP stuk was en ik er pas veel later achter kwam dat ik een machine had gebouwd zonder werkende IPv4.
Dank voor je reactie. Het was voor mij geen doel op zich om een niet-IPv4 machine te maken. Onze eigen interne organisatie is onvoldoende IPv6 aware dat ik daarna nog een goed genoeg werkende machine zou overhouden :). Sowieso gedraagt Microsoft DNS zich met IPv6 records anders dan IPv4 (bijv. t.b.v. reverse lookup). Die details ken ik weer niet zelf, maar heb ik van onze DNS admin en MSDN documentatie.

In ieder geval weet ik zeker dat in 2000 geen enkel serieus software pakket IPv6 aware was. Ik verwacht ook een 'uitgroei' of sterfhuis constructie. Die wellicht nog wel 20 jaar of langer zal duren.

Die door jou genoemde IPv6 lijst van de NL overheid kende ik niet, maar lijkt (deels) uit 2010 te dateren. Dat is toch 10 jaar na 2000 :). Het EU besluit is zelfs 4 jaar ouder (2014). Ik heb zelf onze eigen C/C++ gebaseerde software IPv6 aware gemaakt, enkele jaren geleden, maar kende deze lijst niet (is ook niet zo heel praktisch).

[Reactie gewijzigd door kdekker op 7 april 2015 22:33]

In ieder geval weet ik zeker dat in 2000 geen enkel serieus software pakket IPv6 aware was.
Over Windows wil ik geen uitspraken doen, daar heb je vast helemaal gelijk in. Als ik zie hoe het in XP geregeld dan geloof ik het helemaal :)

In 2000 had ik thuis al IPv6. Ik weet niet meer zeker wat ik er mee deed maar usenet, mail, ssh en apache deden het toen al zonder problemen. Anderen van de computerclub waar ik toen bij zat gingen nog een heel stuk verder. In grote lijnen is IPv6 eigenlijk al best wel lang klaar voor gebruik. Er is de afgelopen 15 jaar nog wel aan de details geschaafd maar de basis was er al.
Anoniem: 470811
@kdekker7 april 2015 22:30
Helaas werkt de originele bron niet meer, dus even Wikipedia: http://en.m.wikipedia.org/wiki/IPv6_deployment

Daarin staat:
In the early 2000s, governments increasingly required support for IPv6 in new equipment. The U.S. government, for example, specified in 2005 that the network backbones of all federal agencies had to be upgraded to IPv6 by June 30, 2008; this was completed before the deadline.
De notitie in Wikipedia betreft alleen de backbones.

[Reactie gewijzigd door Anoniem: 470811 op 7 april 2015 22:32]

Het is logisch dat de netwerk backbone als eerste moet. Daarna de infrastructuur (DNS/DHCP). En daarna het OS. En als laatste de applicatiesoftware.

Het jaar 2000 was voor de meeste operating systems een jaar waar nog geen (volledige) IPv6 support zat. Ik denk dat de *NIX smaken het eerst waren met volledige IPv6 support, maar dan spreek je w.s. ook al over 2008.

Dat in 2005 XP al gedeeltelijk IPv6 support had (die datum vindt ik op internet) wil ook niet zeggen dat het werkte. Vista/Windows 2008 had een andere TCP/IP stack dan voorgaande versies, met een rijtje functies die het portable maken van C/C++ code m.b.t. IPv6 mogelijk maakte (bijv. getaddrinfo()).

Kortom, ik denk dat early 2000s slechts het idee was, en de daadwerkelijke complete uitvoering jaren later was. Daarmee was je eerste post iets te optimistisch met het noemen van een datum. Om enigszins te paraferen op 'congressen kopen geen straaljagers' maak ik de variant 'overheden maken geen IPv6' :).
Anoniem: 470811
@kdekker8 april 2015 08:30
Haha ja dat klopt :) . Wellicht wel dat IPv6 fors gebruikelijker gaat worden. Ik houd er zelf iig wel rekening mee.

Geen IPv6? Dan koop ik het niet (geen idee hoe dat over een paar jaar met mijn tv zit trouwens...)
Tussen de 4 en 8 jaar ?
Misschien krijg je gelijk.
IPv6 is twintig jaar oud !
Misschien ook niet.

[Reactie gewijzigd door 280562 op 7 april 2015 14:33]

Anoniem: 470811
@2805627 april 2015 16:01
Ik hoop het :). Zeker weten doe ik het niet uiteraard.
Wat is 'over'? Er zullen nu nog steeds netwerken te vinden zijn die nog niet over zijn op IPv4 (maar bijvoorbeeld nog IPX/SPX gebruiken). Voor IPv6 zal dat niet anders zijn. Er zullen nog jaren lang IPv4 adressen in gebruik zijn, ook als consumenten al lang IPv4 kunnen uitschakelen zonder het te merken.

Iemand met Dual Stack (IPv4+IPv6) die eigenlijk alleen YouTube, Facebook, Netflix en Google gebruikt zal het nu al amper merken als hij/zij IPv4 uitschakelt.

[Reactie gewijzigd door Maurits van Baerle op 7 april 2015 12:30]

Google, de zoekmachine, is meer een beginpunt voor het surfen naar andere websites die zoals het artikel noemt "nog niet via ipv6 te bereiken" zijn.
Met Google bedoel ik niet de zoekmachine maar het bedrijf. Voor zover ik weet zijn vrijwel al hun diensten over IPv6 bereikbaar. Ook Gmail, Google+, Hangouts etc.
Inderdaad. Op sommige onderdelen van DoubleClick/Ad Services na is alles van Google over IPv6 te bereiken. Geen ramp dus, als je IPv4 mist.
Behalve dat je die post niet had kunnen maken die je zojuist gemaakt hebt ;)
Gaat net zo lang duren als de wereld over zetten op SSL. IPv4 zal de komende 10 jaar nog wel supported zijn door de meeste devices.
En dan is de wereld eindelijk over, blijkt er een gat in SSL te zitten wat ons ertoe beweegt over te gaan op TLS. Kunnen weer van voor af aan beginnen :)

Gelukkig is dat probleem met IPv6 er niet.
De term SSL betekent meer dan alleen het outdated protocol. TLS is in dat opzicht nog steeds SSL te noemen ;)
Maar dat moet nog steeds geupgrade worden ;)
Ik denk dat Tweakers sowieso pas over 30 jaar over is, die zien de noodzaak nog steeds niet
Hier een berichtje via IPv6 van UPC naar Tweakers.net op IPv6.

Tweakers is bereikbaar op IPv6 maar gebruikt het nog niet (dns records) vanwege wat issues. Je kunt het echter zelf zo instellen in je hosts file

2001:990:6:31::140 tweakers.net
2001:990:6:31::140 gathering.tweakers.net
2001:990:6:31::141 tweakimg.net
2001:990:6:31::141 ic.tweakimg.net
2001:990:6:31::142 twk.rs
2001:990:6:31::143 tweakblogs.net
2001:990:6:31::144 tweakers.mobi
2001:990:6:31:1ce:c01d:12c:1337 irc.tweakers.net

[Reactie gewijzigd door randomnumber op 7 april 2015 13:26]

tweakblogs is een beetje zinloos trouwens daar elke tweakblog zijn eigen dubdomein heeft. Kan je enkel afvangen indien je zelf een dns server gaat draaien.
Leuk! Gelijk ingesteld. En mijn Chromium plugin IPvFoo meldt me dat ik tweakers.net nu bereik via IPv6. :)
Ik denk dat als een groot deel van de bezoekers van Tweakers via IPv6 komt dat IPv4 van de servers/ loadbalancers afgaat en er een SIIT oplossing komt. Een soort van DNS64 / NAT64.

Blijft alles voor de IPv4 gebruiker hetzelfde maar dan hoeft tweakers in hun software, monitoring en toegangs systemen alleen nog maar met IPv6 te werken. SIIT is een soort van NAT waarbij een IPv4 adres in een IPv6 adres wordt gestop aan de edge router / firewall. Het voordeel hiervan is dat het stateless is in tegenstelling tot IPv4 NAT. Dus de router hoeft geen sessies bij te houden.

En raar is het niet, is namelijk ook wat Facebook doet.
http://www.internetsociet...v6Congress-IPv6_LH-v2.pdf

[Reactie gewijzigd door randomnumber op 7 april 2015 13:51]

Het is meer dan alleen NAT. Want een TCP stream over IPv6 is niet hetzelfde als een TCP stream over IPv4. Het is meer een proxy.
Het is stateless, maar wel NAT. Het past de source / destination header aan en houd geen sessie bij. Als het pakketje terug komt wordt uit het IPv6 de nieuwe IPv4 destination gezet.

Een proxy houd een status bij, waarbij SIIT ook een verschillende terug route kan hebben. http://stream.ipspace.net.../3.1%20-%20SIIT%20101.mp4

Dit kan dus een groot volume aan packets aan en in de toekomst wordt de belasting minder naarmate er meer IPv6 clients komen. Dat is anders dan providers die CGN invoeren, waarbij meer content op IPv6 komt en meer clients die achter dubbel nat zitten.
Deze nat vorm zal wel werken omdat aan de IPv6 kant het eerst stiekem weer ongedaan gemaakt wordt naar IPv4... dus het is een
IPv4 - over IPv6 - IPv4 oplossing. Niet een IPv4 -> IPV6 native oplossing.

https://www.ietf.org/proc...des/slides-91-v6ops-3.pdf

En je hebt niet alleen te maken met IPv4 in headers maar ook met IPv4 in embedded pakketten zoals bij RPC protocollen en multi connection protcollen zoals FTP, SIP etc,
Klopt. Als je NU een vast IPv4 adres hebt, dat via IPv6 gewoon te bereiken is, waarom zou je dan?...
Je kunt niet (zonder meer) een IPv4-adres bereiken over IPv6. Maar omdat iedereen met IPv6 óók nog IPv4 heeft is het (vooralsnog) geen probleem.
Maar omdat iedereen met IPv6 óók nog IPv4 heeft is het (vooralsnog) geen probleem.
Ik geloof dat er in China en India al netwerken zijn waar dat niet het geval is. En in het Westen zijn er misschien netwerken voor mobiele telefoons die IPv6-only zijn ? (Misschien dat iemand anders daar voorbeelden van heeft ?)
In Azie waren ze 5 jaar geleden al door de IPv4 adressen heen.
Terwijl dat in EU nog "Maar" 3 jaar is.
Ben dat zelf niet tegenkomen op publieke netwerken, ook niet in China. Wel kom ik regelmatig systemen tegen die intern volledig IPv6 draaien en dan alleen extern (op web server of load balancers) IPv4 toevoegen.
Omdat veel problemen makkelijker worden als je meerdere IP-adressen kan gebruiken. We hebben allerlei trucks bedacht om IPv4 wat langer te rekken (zoals NAT en vhosts en SNI) maar die voegen complexiteit toe.
Wel heb je een overgangsperiode waarin je allebei moet doen maar dat is haast onoverkomelijk.
Beide protocollen zijn niet compatibel met elkaar. Je kunt dus niet IPv4 bereiken via IPv6 of omgekeerd. Tenzij je dus gebruik wilt maken van een proxy die op beiden is aangesloten en je verkeer vertaald, moeten je eigen systemen beide protocollen aankunnen. Dit noemt men dual-stack, en is de aanbevolen transitiemethode.
omdat het kan ... omdat we Tweakers zijn ....
Wij wel ja, de website al een tijdje niet echt meer... Jammer, maar het is tegenwoordig gewoon een handige site, maar niet echt meer een bron van nerderij.
Ik verwacht begin 2021. Als je hier voor 'Logistic (S-curve)' kiest, de meest relevante voor groei curves, dan zie je dat het 90% niveau daar ongeveer valt: https://www.vyncke.org/ipv6status/project.php?country=ww
Een paar jaar geleden had een provider in de forecast staan dat in 2022 IPv4 uitgezet zou worden. Echter, die provider loopt nu al een paar jaar achter op de destijds geplande invoering van IPv6 en ik vermoed dat de datum 2022 ook wel uit zal gaan lopen.
Wat gaat er eigenlijk gebeuren met Ipv4 applicaties die niet geupdate worden voor Ipv6. (denk bijvoorbeeld aan oudere games)
Kan Ipv4 voor de applicaties aan beide kanten worden geëmuleerd terwijl de communicatie tussen de twee hosts over ipv6 gaat?
Als men binnen IPv6 had gekozen voor bijvoorbeeld 96-bit addressen (genoeg om zo'n beetje elke electron op aarde van een eigen adres te voorzien) was er nauwelijks enige aanpassing nodig geweest in de meeste server software. Adressen tot die grootte hadden namelijk gewoon in bestaande structuren gepast. Een server gebruikt in het algemeen gewoon de "ik stuur mijn antwoord terug naar de zender" logica, en "ik luister op alle interfaces", en als men netjes geprogrammeerd heeft, hoef je de software geheel niet aan te passen, zelfs niet eens opnieuw te compileren.

Iemand vond het leuk om voor 128 bit te gaan, en dus moet nu alle software aangepast worden voor IPv6, omdat het afzender adres niet in de oude struct past. |:(
Dat snap ik niet, IPv4-adressen zijn 32-bit. Waar haal jij die 64bit extra vandaan om op 96bit te komen?
struct sockaddr

Totaal 16 bytes, namelijk 14 bytes adres en 2 bytes voor het poortnummer. Van die 14 heb ik voor 't gemak 12 genomen omdat IPv6 ook nog bits voor interface keuze wil hebben (daarvoor zouden 16 bits wel genoeg moeten zijn, wie heeft er >64k netwerk interfaces in een machine?)

Deze struct werd in alle socket software gebruikt, en daarmee was je meteen op de toekomst voorbereid. Dacht men.
Je vergeet dan alleen de bytestructuur van een IP header,,, die heeft geen 14 bytes ruimte. De C code is een implementatiedetail
Er is voor 128 bit gekozen om van NAT af te komen.
Dit geeft de mogelijkheid om iedere organisatie op de wereld een 64 bit access point adres te geven, met binnen de betreffende accessoint nog een 64 bit om uit te delen.
Hierdoor is het niet meer nodig om netwerken a la class-A, class-B en class-C netwerken te hebben.

Overigens moet alle software alsnog aangepast worden omdat interfaces toch echt slecht s met 4 byte adressen werken, ZELFS als het netjes geprogrammeerd is.
Van NAT af komen is niet gelukt. NAT is gewoon te handig, dus ook IPv6 heeft nu weer NAT gekregen (ondanks boude "over my dead body" uitspraken van een van de grondleggers).

Zelf met 64 bits zou je aan een willekeurig object op aarde (bijvoorbeeld een badspons) een IP adres kunnen toewijzen op grond van welke molecule er in zit. Je kunt namelijk alle moleculen op aarde een statisch IP adres geven met 64 bit ruimte.

Voor een IPv4 adres in socket interface (wat door alle OSsen gebruikt wordt) heb je overigens minstens 8 bytes nodig (2 voor type, 2 voor poortnummer en 4 voor het adres).
NAT is helemaal niet handig, het is een ~10 bit uitbreiding van de 32bit address space en veroorzaakt veel meer hoofdpijn dan nodig is.
Er zijn veel protocollen waarbij adressen intern mee liften die helemaal niet goed geNAT kunnen worden (RPC), die waarbij de nodige trukendozen opengehaald moeten worden (FTP), en de protocollen waarbij complete extra diensten en workarounds nodig zijn voor het blijven werken. (SIP) waarbij STUN nodig is om en waarbij inmiddels een 4 tal smaken STUN bestaan door implementatie fouten/ concept fouten en fouten geintroduceerd om gebruik door concurrenten te bemoeilijken....
En als kers op de cake..., voor analyze en reparatie mag dat verkeer niet encrypted worden verzonden...,

In alle gevallen had zonder NAT alles 100% functioneel gewerkt zonder aanpassingen, net volledig ingepakt kunnen worden in ee beveilingsschil.
OH, NAT is geen beveiliging, een firewall met filter/proxy poort wel.

[Reactie gewijzigd door tweaknico op 10 april 2015 16:27]

Je kiest nu een willekeurig punt van abstractie. Een 96-bit adres verandert het probleem niet, het verlegd het hooguit een klein beetje.

Enerzijds is het nu ook al zo dat niet alle applicaties aangepast hoeven te worden. Als jouw applicatie een library gebruikt die HTTP requests uitvoert hoeft jouw applicatie niet noemenswaardig aangepast te worden voor IPv6. De library zal het werk doen.

Anderzijds is IPv6 veel meer dan alleen maar "meer adressen". Als je op een laag niveau programmeert heb je dus met veel meer te maken dan alleen maar een "nieuwe struct voor langer adres".
Probleem is nou net dat op "library" niveau - namelijk "sockets" - ooit 16 bytes is gereserveerd om een "adres" in op te slaan. Alle bestaande software werkte met die struct. Als IPv6 nu gewoon wat minder bits had verspild, had het IPv6 adres gewoon in die 16 bytes gepast, en was de adoptie ervan veel, veel, veel en veel sneller gegaan.
Veel applicaties gebruiken gewoon hostnames en laten het IP verkeer afhandelen over aan het onderliggende OS. Een applicatie die iets opvraagt van een server op connect.example.com zal niets merken van of het over IPv4 of IPv6 binnenkomt, daar zorgt het OS voor.

Het enige waar je problemen kunt zien zijn applicaties die zelf op een laag niveau hun netwerkverkeer afhandelen. Browsers en FTP clients bijvoorbeeld. En inderdaad misschien sommige games. Gelukkig ondersteunen vrijwel alle OS-en en applicaties al jaren IPv6.
Veel applicaties gebruiken gewoon hostnames en laten het IP verkeer afhandelen over aan het onderliggende OS. Een applicatie die iets opvraagt van een server op connect.example.com zal niets merken van of het over IPv4 of IPv6 binnenkomt, daar zorgt het OS voor.
Onjuist. Een applicatie geeft aan voor welke address family hij de names resolved wil hebben en wat voor sockets er aangemaakt moeten worden. Voor IPv6 moet je andere parameters meegeven dan voor IPv4 (het zijn immers verschillende soorten adressen), dus nee, dat gaat niet automatisch.
Dan heb jij nog nooit met sockets geprogrammeerd zeker.

IPv4 versus IPv6 is niet transparant voor applicaties. Als je programma niet geprogrammeerd is voor IPv6, kan het ook geen IPv6 gebruiken. Dat heeft bv te maken met de lengte van addressen. Het is niet iets dat het OS zomaar kan spoofen. Ook als er IPv4-addressen in de inkomende data zitten (een eigen name-server protocol bv) dan houdt alles op.

Je applicatie zal echt IPv6-aware moeten zijn.
Het adres moet zelf opgelost worden met een gethostbyname() in een address structure en dat kan aan de socket() call worden aangeboden.

De applicatie maakt verbinding met een socket() call. Dat gewoon een adres verwacht.
er is een verschil in parameters voor een socket op IPv4 en IPv6, inclusief een expliciete vermelding van de IP versie.

Dus de applicatie is wel degelijk betrokken bij dit proces.
Wat gaat er eigenlijk gebeuren met Ipv4 applicaties die niet geupdate worden voor Ipv6. (denk bijvoorbeeld aan oudere games)
Kan Ipv4 voor de applicaties aan beide kanten worden geëmuleerd terwijl de communicatie tussen de twee hosts over ipv6 gaat?
Zoals Maurits al aangeeft valt dit over het algemeen wel mee. Om het laatste deel van je vraag te beantwoorden: je kan natuurlijk een VPN draaien over IPv6. Over deze verbinding heen kan je IPv4 gebruiken voor bijvoorbeeld oude spellen en andere applicaties die IPv4 adressering hard-coded hebben ingebakken. Zo zou je ook klassieke FTP kunnen draaien, wat soms nodig is voor interactie met oude software en embedded devices.

[Reactie gewijzigd door The Zep Man op 7 april 2015 13:46]

Zo speelden we vroeger DOOM via een IPX tunnel over het Internet.

Overigens denk ik dat tegen de tijd dat IPv4 echt wordt uitgezet het aantal mensen dat IPv4-only spellen speelt verwaarloosbaar is. (Al zullen deze mensen daar zelf natuurlijk anders over denken.)
Ja, vanaf ipv4 adres kan je een ipv6 adres niet bereiken, andersom is geen probleem.

Dus alles moet zo snel mogelijk naar ipv6 omdat de ipv4 adressen op* zijn.

* op alsin de bedrijven die ipv4 adressen uitgeven zijn door de voorraad heen, de providers zelf hebben nog wel een eigen voorraad maar die zijn niet oneindig.
Andersom is net zo hard een probleem, maar daar zijn technieken voor uitgevonden om die problemen te (proberen te; 't lukt niet altijd 100%) omzeilen. Het helpt dat de IPv4-address space ruimschoots in de IPv6-address space past dus je kunt wat netwerktruuken uithalen met NAT om van IPv6 naar IPv4 te vertalen. Maar ik wil het gebruik van NAT64 niet scharen onder 'geen probleem'.
NAT is altijd een probleem, dat was ook het grootste gezeik met IPV4.

Maar een gebruiker zal het niet merken, zeker met dual-stack.

De dual-stack wordt vanzelf optioneel, en dat wordt het inderdaad NAT.
In de meeste operating systems krijgt IPv6 prio over IPv4 wanneer beide beschikbaar zijn. Het is dus de bedoeling dat we de komende jaren steeds meer en meer traffic op IPv6 gaan zien net zo lang tot het moment daar is dat IPv4 "uitgeschakeld" kan worden.
Niet helemaal waar. IPv6 krijgt voorang op v4 op voorwaarde dat de IPv6 een native verbinding is. Maak je gebruik van een IPv6 tunnel omdat je ISP het nog niet ondersteund dan zal onder meer in Linux standaard je v4 verbinding voorrang krijgen op je v6.
En dat is weer afhankelijk van het soort tunnel. Een Teredo-tunnel wordt als onstabiel beschouwd en krijgt inderdaad géén voorrang. Een 6in4-tunnel, zoals bijv. door Sixxs.net of he.net worden uitgegeven, krijgt wél voorrang boven IPv4.

Mijn provider ON biedt op aanvraag IPv6 via 6rd (IPv6 rapid deployment), een variant op 6to4. Ook deze verbinding krijgt automatisch voorrang in mijn Linux routertje. Andere apparaten in mijn netwerk geven IPv6 sowieso voorrang want die weten niet beter dan dat het native is.
Dual stack, modem krijgt dus zowel een ipv4 als ipv6 ip.
Nee. JIJ krijgt van de modem IPv4 en IPv6 adressen uitgereikt, maar je verliest jouw "eigen" IPv4 adres aan de buitenkant (lees: het internet). Ziggo gebruikt, net als UPC, het DS-LIte protocol, wat ervoor zorgt dat je aan de providerkant achter een NAT router zit, die gebruik maakt van een gedeelde pool IPv4 adressen. Dit heet CGN (Carrier Grade NAT). Jij hebt nu geen "vast" variabel ipv4 adres, maar iedere keer een ander IPv4 adres.
Nee, dat doet upc idd met ds-lite, ziggo maakt gebruik van dual stack en dan krijg je gewoon een ipv4 als ipv6 vanuit dhcp server ziggo.
is dat met PD (Prefix delegation) of met DHCPv6?
Ziggo doet dual-stack, gezien het IPv4 adres in de screenshots: http://ziggo-gebruikers.n...thread.php?t=49125&page=2 en UPC is aan het testen met DS-lite. Waarbij je WAN IPv4 adres een 10.x adres is uit de private range.

Aangezien ze samen zijn gegaan en het in Ziggo overgaat denk ik dat het allemaal dual-stack wordt gezien de issues met ds-lite. (verlies van toegang tot thuis systemen over ipv4)
XS4ALL fiber (dsl weet ik niet) heeft al langer ipv6 maar ik heb wel degelijk een ipv4 adres.

Er word trouwens al jaren geroepen dat ipv4 opraakt. Maar jaren later is ipv6 nog altijd bijzaak. Zeker geen hoofdzaak.

[Reactie gewijzigd door Jack Hair op 7 april 2015 17:59]

De oplossing is dual stack. Je krijgt zowel een IPv4 adres als een IPv6 adres. Voor de gebruikers in dual stack zal zij ten allen tijde heel het internet bereikbaar blijven. Voor gebruikers die enkel IPv4 of enkel IPv6 hebben kan er een moment komen waarop een dienst voor hen niet bereikbaar is.
Dual, beide soorten. Als je het bericht goed had gelezen had je dat gezien
Ben redelijk goed in het onthouden van ip-adressen. Nu gebruik ik het huidige ipadres om extern te connecten naar wat serverapplicaties thuis. Heb dus geen DDNS. Wil ik ook eigenlijk niet.. :)

Geeft het nog problemen als je overgaat naar zo n nieuw ipv-6 adres aangezien je ook het ipv-4 adres behoudt. Of betekent dat, dat je twee ip-adressen hebt om extern te verbinden met je servers.
ze bieden t dualstack aan. Dat moet ook wel, omdat het leeuwendeel van de servers en services op internet alleen via IPv4 bereikbaar zijn.

Het antwoord is dus ja, je hebt dan meer dan 1 adres waarop je extern bereikbaar bent.

( Waarschijnlijk heb je zelfs 18,446,744,073,709,552,001 adressen waarop je kunt verbinden, als ze voor een /64 gaan ;-) )
Één /64 is één netwerk, dus da's nogal karig. De standaard hiervoor is een /48 of een /56 aan te bieden aan de klant. Ziggo is voor de /56 gegaan.
/64 is 1 netwerk met nog een 64 bits aan local adressen... wat je karig noemt.
(prive meer dan het kwadraat van het originele internet... )

/56 betekend dat iedereen 256 netwerken van ieder 64 bits adressen heeft.

De /48 was gebruikelijk voor providers waar de redeniring was dat een IPv4 adres gemapt wordt op een IPv6 adres reeks. dan is de 2001: prefix + mapped adres samen /48.
/64 is 1 netwerk met nog een 64 bits aan local adressen... wat je karig noemt.
De officiele recommendation uit RFC 3177 was om standaard een /48 voor elke "end site", inclusief thuisgebruikers. De nieuwere RFC 6177 zwakt dit enigszins af en suggereert een /56 voor thuisgebruikers.

Dus ja, een /64 zou wel wat karig zijn. Een /56 (wat Ziggo lijkt te doen) lijkt mij prima.
De /48 was gebruikelijk voor providers waar de redeniring was dat een IPv4 adres gemapt wordt op een IPv6 adres reeks. dan is de 2001: prefix + mapped adres samen /48.
Nee, de /48 kwam vanuit de redenering dat gebruikers niet om netwerken en adressen verlegen moeten zitten, dat partitionering makkelijk is als iedereen een /48 krijgt, en om administratie makkelijker te maken. Zie ook bovengenoemde RFC.
Dat is afhankelijk hoe je dit opvat en uitlegt:
(uit rfc 3177:

- Similarly, if the 6to4 proposal is widely deployed, migration
from a 6to4 prefix, which is /48 by construction, to a native
IPv6 prefix will be simplified if the native prefix is /48.
Ik doelde op passages als deze:
- Home network subscribers, connecting through on-demand or always-on connections should receive a /48.
En:
The arguments for the fixed boundary are:
  • That only by having a provider-independent boundary can we guarantee that a change of ISP will not require a costly internal restructuring or consolidation of subnets.
  • That during straightforward site renumbering from one prefix to another the whole process, including parallel running of the two prefixes, would be greatly complicated if the prefixes had different lengths (depending of course on the size and complexity of the site).
  • ...
  • To allow easy growth of the subscribers' networks without need to go back to ISPs for more space (except for that relatively small number of subscribers for which a /48 is not enough).
  • ...
  • ...

[Reactie gewijzigd door deadinspace op 7 april 2015 20:33]

Ja ik weet hoe 't werkt maar toch bedankt.

Ik zeg karig omdat ik al 15 jaar met IPv6 werk en dus niet meer in "aantallen adressen" denk zoals bij IPv4 moet, en de "/64" eigenlijk al niet meer als een enorm ding zie waar je oneindig subnets uit kan halen, maar als één enkel subnetje wat niet meer onder te verdelen is. En ja, dan is dat karig.

ISP's krijgen /32's of kleiner.

[Reactie gewijzigd door CyBeR op 7 april 2015 17:02]

Helder...
Dual-stack betekend dat je ipv4 houdt er er ipv6 bijkrijgt.

Uiteindelijk zal de dual-stack wel een keer verdwijnen, maar dat kan nog decenia duren.
Eh...dan registreer je voor paar euro per jaar een 'echte domeinnaam', hoef je nooit meer een IP adres te onthouden.
In de overgangsperiode (die nog jaren kan duren) zul je inderdaad beide adressen naast elkaar hebben.

IPv6-adressen onthouden is even wennen maar in praktijk niet zo erg als het soms lijkt. Hele stukken hoef je niet echt te onthouden. Net zoals een beetje IT'er weet dat lokale netwerkjes bijna altijd met '192.168' beginnen zo zijn er in IPv6 patronen die je helpen met onthouden.
De kreet IP6 adres is helemaal fout.
Het is een reeks van adressen die NAT overbodig maakt.
Een enkele computer kan een meerdere adressen in gebruik hebben.
Een /64 zou wel best practise zijn
Ik hoop eerder een /56 of nog beter, een /48. Zo kan je intern ook weer losse subnets aan maken.

Subnet voor:
- Guest WiFi
- Domotica
- PC's, laptops, tablets

Dat is juist het voordeel, subnetting zodat je alles kan scheiden en filteren.
Jij wilt elke cel van je lichaam een eigen IP-adres kunnen geven ofzo?
Lijkt me wel eerlijk.

De IPv6 range is voldoende om pakweg elke molecuul uit dit zonnestelsel een eigen adres te geven.

Het lijkt me dan vanzelfsprekend dat ik alle moleculen die inherent van "mij" zijn, ook een eigen adres in mijn range kan geven.
De IPv6 range is voldoende om pakweg elke molecuul uit dit zonnestelsel een eigen adres te geven.
Nou, nee hoor ;)

De Zon weegt ongeveer 1.99 · 1030kg. Een neutron/proton ongeveer 1.67 · 10-27kg. Dat betekent dat de zon ongeveer 3.3 · 1057 protonen/neutronen bevat.

IPv6 biedt 2128 ≈ 3.4 · 1038 adressen. Dat betekent dat IPv6 ongeveer een factor 9 779 854 390 084 251 163 te weinig adressen heeft ;)

(Ik weet dat je moleculen zei, en niet neutronen/protonen, maar aangezien de Zon hoofdzakelijk uit waterstof en helium bestaat gaat dat hoogstens een factor 2 schelen)
Nee, maar het hele idee van IPv6 is autoconfiguration, meer subnetting en nooit meer met een tekort zitten.

Het is niet dat ik elk adres uit de /64 gebruik, maar mijn /48 van ZeelandNet heb ik in 3 stukken opgedeeld thuis:

- Guest
- Domotica
- PC's, laptops, ed.

Aan de hand van het subnet kan ik dus al direct zien wat voor een type apparaat het was. Ook kan ik op basis daarvan firewall policies maken.
dit dus, en het 'internet of things' wat eraan schijnt te komen ;-)
mijn /48 van ZeelandNet heb ik in 3 stukken opgedeeld thuis
Filosofisch gezien helemaal fout.
Adressen hebben 1 enkele functie: het aangeven van de locatie.
Jij gebruikt adressen voor administratieve doeleinden.
Fout, imho.

IPv6 heeft de kans gehad om dingen goed te doen.
Bijvoorbeeld door "identifier/location separation".in te bouwen. Dat had heel mooi geweest. Helaas niet gebeurd. De IPv6-crowd vond langere addresen mooi genoeg. En daar is het zo'n beetje bij gebleven.
En daarmee heb je zelf de mogelijkheid om op basis van de subnetten je identifier/location-seperation in te bouwen :)
Kwestie van verdelen:
Eerste 32 bits: woonkamer/studeerkamer/slaapkamer kind 1 of 2, 2e 32 bits: tv-kast, buffetkast of whatever, 3e 32 bits: wireless of bedraad, 4e 32 bits: adres van apparaat :)

Edit: bij wijze van spreken natuurlijk: de eerste x-bits liggen vast natuurlijk :)

[Reactie gewijzigd door Pietervs op 7 april 2015 19:11]

Wat jij doet is heel anders als wat Snow King doet. Jij deelt op in locaties. Helemaal goed. Snow King deelt zijn adressen op in functie.

Da's een beetje alsof je iedereen in Nederland postcodes geeft, en dan gebruiken sommige mensen dezelfde postcode voor hun huis in Utrecht, hun vakantie-huisje op Texel, hun caravan-stalling in Brabant, en de studentenkamers van hun kinderen in Groningen en Maastricht. Op die manier heeft de postcode weinig waarde meer voor de postbodes.

Nogmaals, alles vanuit een filosofisch standpunt bekeken. :)
Iedere beheerder heeft weer een andere filosofie :)
Ik begrijp zijn wens om een verdeling te maken naar functionaliteit.
En aparte subnetten voor domotica en gast-toegang kan ik ook alleen maar toejuichen.

En netwerken kunnen verdeeld worden over locaties. Dat is dan weer het voordeel van techniek: er wordt afgeleverd op adres zonder dat er een postcode bij nodig is. :)
Iedere beheerder ?
Technologie moet ook nog ooit geimplementeerd worden. Daarvoor moet het logisch en efficient zijn. Adressen zijn adressen. Misschien wil je ze als label gebruiken, als identifier, als wachtwoord, whatever. Maar uiteindelijk zijn adressen alleen maar adressen.
Misschien ook nog wel een keer. Maar ik wil wel alles in m'n huis een nummer kunnen geven. Ieder meubelstuk, iedere gloeilamp, ieder stopcontact en ieder pak melk dat ik de rest van m'n leven ooit nog ga kopen.
Waar dat precies voor gebruikt gaat worden weet ik nog niet maar ik vind het wel fijn om de mogelijkheid open te houden.
Mijn FritzBox geeft een apart netwerk aan ons guestlan als ik meer dan een /64 krijg. Best tof. Dus ik had graag meer dan een /64.
Waarom gaat dat niet met een /64? Je hebt dan al meer adressen dan er in ipv4 zitten. Ik kan me niet inbeelden dat je ooit zoveel adressen en subnets nodig gaat hebben...
Omdat /64 de de-facto minimale groote voor een subnet. Zie RFC5375. En SLAAC (waarbij een apparaat zelf een IPv6 adres berekent) werkt alleen met subnetten van 64-bits.
Voor SLAAC (Auto configuration) met IPv6 heb je minimaal een /64 nodig. Wil je meerdere subnets, dan heb je dus iets nodig wat groter is dan een /64.

Uit een /48 komen 64k /64 subnets. Als je dat aan je klanten geeft, weet je zeker dat ze nooit meer terug komen met vragen om subnets.

Een /56 kan ook nodig, daar komen er dan 256 uit, dat kan ook nog.
Voor het genereren van een Modified EUI-64 adres heeft het host gedeelte 64 bit nodig. Er zullen vast wel methodes zijn waarbij dat niet nodig is alleen is het een beetje jammer als by default dit soort standaard methodes al onmogelijk gemaakt worden door de ISP
En hoeveel gebruikers gaan daar nut van hebben? Het toont vooral aan dat IPv6 slechts is ontworpen. Met 1 enkele /64 heb je al een veelvoud aan IP adressen dan dat er in de hele IPv4 range zitten. Het is onzinnig om een particulier meer adressen te geven imho.
http://www.networkworld.c...6-address-management.html

Uit een ander stuk wat ik helaas zo niet terug kon vinden was de berekening of (vrij vertaald uit mijn gedachte) je nu 0,001% of 0,0000000001% aan adressen weggooit, wat maakt het nog uit ten opzichte van de eenvoud dat iedereen een /48 heeft ipv een /48 / 56 /60 /64 ?

/48 klant
/64 subnet
/128 end-point

Met name voor blocking rules / fora, etc.

Het had ook te maken dat een thuis netwerk ook kan uitgroeien tot een multi-site bedrijf waardoor het hernummeren zou voorkomen. Tevens vanuit die gedachte dat je geen onderscheid als ISP zou willem moeten maken tussen een thuis aansluiting en een "zakelijke" aansluiting want dat kon nog wel eens wisselen.

Met deUPC ipv6 testt Xs4all komt het erop neer dat door prefix-delegation ik 4 voorgekozen subnetten kan gebruiken. Nu zal 4 subnetten voor een hoop mensen genoeg zijn maar ik zit er al aan.

[Reactie gewijzigd door randomnumber op 7 april 2015 16:34]

Het is niet direct de Pefix delegation, maar de UPC instelling.
Ik krijg van XS4ALL met PD een /48. (Al jaren).
Mijn fout, het ging niet over UPC maar over Xs4all.

De Prefix Delegation van de Fritzbox is een /62 wat dus op de 4 mogelijke subnetten neerkomt.

2001:0981:XXXX:00f8:0000:0000:0000:0000
2001:0981:XXXX:00fb:ffff:ffff:ffff:ffff

Ondanks dat ik een /48 heb kan ik bij de Fritzbox geen statische routes aangeven dus alle andere subnetten die buiten de bovengenoemde reeks vallen worden niet door de Fritzbox gerouteerd.

Dit ligt overigens bij AVM, maker van de Fritzbox. Dat ze in plaats van alleen bij IPv4 statische routes mogelijk maken, dit ook voor IPv6 doen, ik kies namelijk andere subnet benamingen op basis van doel.
Oh, ik gebruik geen fritzbox, dus ook niet voor de termination maar een zelfbouw Linux firewall, vandaar dat ik deze beperking niet herken ;)
Jij denkt dat gebruikers geen nut hebben van autoconfiguration? Behalve misschien voor een enkele techneut die verstand heeft van IP networking zal het voor vrijwel iedereen een vooruitgang zijn.

Daarnaast, Ziggo geeft nu iedereen de mogelijkheid om 256 subnetten achter één aansluiting te hebben. Met de opkomst van bijvoorbeeld IPTV, The Internet of Things, Domotica, guest wifi, public wifi over consumenten routers etc. is het juist erg handig dat het veilig en handig te splitsen is zonder hoofdpijn. Ook voor mensen zonder kennis van IP netwerken.
Jij denkt dat gebruikers geen nut hebben van autoconfiguration?
Nee maar wel dat het onzinnig is dat je daar zoveel adress space voor nodig hebt. Autoconfiguration zou als IPv6 wat slimmer beter was ontworpen ook op kleine subnetten hebben moeten werken.
Je denkt op te korte termijn. Zelfs als je aan iedere aardbewoner meerdere /48's uitdeelt heb je nog onnoemelijk veel adresruimte over. De IPv6 adresruimte is niet voor niks zo groot gemaakt. Een /48 is dan ook de officiële aanbevolen grootte voor eindgebruikers.

Men wil voor eens en altijd af zijn van workarounds zoals NAT. Waarom dan door verkeerder zuinigheid het risico lopen dat men weer zoiets moet gaan toepassen. Door de opkomst van het Internet of Things kunnen we nog niet inschatten hoeveel adressen elk individu nodig gaat hebben.
Anoniem: 80466
@Yggdrasil7 april 2015 15:18
De IPv6 adresruimte is niet voor niks zo groot gemaakt
Eigenlijk dus juist wel voor niks omdat 99,999% van de uitgedeelde adressen nooit gebruikt zullen worden.
De insteek is dat je altijd, in ieder subnet, praktisch oneindig veel adressen hebt. Om verschillende redenen is /64 een handige grens. Het is inderdaad wel heel erg veel, misschien was /32 beter voor nu, maar er is gekozen om heel ruim te zijn zodat we er niet over 15 jaar achter komen dat het toch te krap is.
SLAAC is stateless autoconfiguratie. Dus een host kan zichzelf configureren zonder dat daar een (stateful) server zoals DHCP voor nodig is. Maakt 't hele zooitje een stuk simpeler.

Plus, als je een /64 als netwerk gebruikt kun je gebruik maken van extra adressen voor privacy. Wat dus gebeurt (aangezien dat in de major OS'en default aan staat) is dat je uitgaand steeds een ander, random, adres gebruikt. Dat heeft weinig nut als je maar 255 adressen kunt kiezen.
Omdat je dan geen subnets kan maken
Telenet (ook Liberty Global, al komt dat natuurlijk niet overeen met het oude Ziggo) geeft iedereen een /60. Niet wauw, maar een goed begin.
Voor de tweakers onder ons zou een /56 beter zijn, kun je nog wat subnets zelf bouwen.
Iemand informatie over wat Ziggo uitdeelt ?
Uit betrouwbare bron heb ik dat er /56 subnetjes uitgedeeld worden. Dus daar kunnen de tweakers onder ons wel wat mee.
Een klein minpunt is dat op dit moment alleen de modems die in router modus staan een IPv6 adres / subnet zullen krijgen. Misschien gaat dat in de toekomst nog wijzigen.
Dit betekent ook dat juist de mensen die vanaf het begin schreeuwen om IPv6 dit nu nog niet krijgen (dit jaar, zoals de afgelopen paar jaar). Ik heb een modem van Ziggo zonder router functie en heb geen opt-in voor IPv6 omdat? Bang voor problemen met unmanaged routers? Security?
Ik denk dat het meer te maken heeft met een soort van "zorg plicht". Stel dat Ziggo nu iedereen met een modem zonder router functie een IPv6 adres of subnet zou geven, dan staat bij een heleboel klanten ineens het complete interne netwerk "open". Devices die eerst vanwege NAT niet direct bereikbaar waren hebben dan een publiek IPv6 adres.
Voor de tweakers is dit natuurlijk geen probleem, maar voor de minder technisch begaafden kan dit een behoorlijk security risk zijn.
En wanneer is dit probleem opgelost? Jammergenoeg niet in de nabije toekomst lijkt me... Daarom stel ik dat deze gebruikersgroep in de kou blijft staan zonder opt-in mogelijkheid.
Waarom zouden ze in de kou blijven staan? Ze zijn alleen niet als eerste aan de beurt.

Ik begrijp best dat Ziggo eerst de standaardconfiguraties uitrolt en daarna pas naar de speciale gevallen kijkt. Die speciale gevallen hebben ook meer risico op complicaties dus zorg je dat je eerst meer ervaring hebt met je eigen IPv6 systemen als ze in gebruik zijn door 100.000+ gebruikers en als je helpdesk betere support kan leveren.
Ziggo support de routers van deze groep niet en rolt dus als eerste IPv6 uit naar de managed routers. Dat is leuk, maar de unmanaged routers zijn over 5 jaar nog net zo 'lek'/'verkeerd geconfigureerd' als nu. Met het tempo waarop Ziggo tot voor kort bezig was hoef je dus niet veel te verwachten voor deze gebruikersgroep, terwijl andere providers al ruim tien jaar dit hebben gedaan voor hun gehele klantenbestand.

Het is niet alsof een opt-in totaal nieuw zou zijn voor Ziggo. Hetzelfde werd gedaan met de (faal)Ziggo-hotspots en extra tv pakketten.

De schijnveiligheid van NAT bij ip4 moet niet de enige reden zijn om uitstel van ipv6 uitrol te verdedigen.
Oh, ik denk dat die opt-in ook wel komt. Waarschijnlijk ook met tips zoals zorg je de nieuwste firmware draait en je je firewall aan zet. Linkje erbij naar een IPv6 portscanner en een disclaimer dat Ziggo de opt-in uit kan schakelen bij misbruik of gevaarlijke instellingen.

Maar ik vind het ook logisch dat die groep niet bij de eerste batch zit. Later dit jaar zou me niets verbazen.
Ik denk dat ze het rustig aan willen uitrollen. Eerst de modems die ze het beste kennen in hun standaardconfiguratie. Daarna geleidelijk naar oudere modems en pas later complexere configuraties. Dan is de helpdesk ook iets beter gewend aan rare vragen, weten ze zeker dat een probleem niet bij hen zelf zit etc.
Andere providers kiezen ook wel voor /48 zodat je zelf nog iets van 2000+ subnets kunt bouwen. Dat zou voor ziggo ook een optie zijn

maar met /64 heb je alsnog 18,446,744,073,709,552,000 hosts tot je beschikking... Best veel in 1 subnet, dat wel natuurlijk :p
dat lijkt mij niet. met stateless auto address configuration (SLAAC) heb je dan maar 1 vlan. het zal wel een /60 of /56 worden. met /64 kun je thuis geen vlan's maken in combi met SLAAC.
Hier een cisco ip plan white paper.
Nee, dat zou een /48 of /56 zijn, volgens de RFC > https://tools.ietf.org/html/rfc6177

Dit vanwege de eerder genoemde zaken van het automatisch kunnen configureren van apparaten in verschillende sub-netten voor scheiding van gast, wifi, test en andere doeleinden en systemen.
Mijn modem krijgt een /56 volgens de management interface, het modem maakt hier een enkel /64 van op het LAN segement. Het modem staat in router modes in mijn geval.
De zakelijke klanten zijn overigens allang over. Volgens mij zijn ze twee jaar geleden al begonnen met het uitrollen van IPv6 voor zakelijke klanten.
Ik heb hier een zakelijke aansluiting van Ziggo (kabel), maar nog niks gehoord over ipv6!
Geen idee hoe het met kabel zit. Bij glasvezel kan IPv6 al enkele jaren.
Dat heeft Ziggo 1,5 jaar geleden inderdaad gecommuniceerd. Eind 2013 zouden alle zakelijke abonnementen ipv6 supporten.

Na een belletje medio november 2013 (eind 2013 kwam in zicht) naar Ziggo was ik wat wijzer. Het betrof niet alle zakelijke abonnementen, maar slechts enkele. Maar die van mij zou in 2014 ipv6 gaan ondersteunen. Onduidelijk was echter wanneer in 2014.

Affijn, om een lang verhaal kort te maken: ik mag nu ergens in mei 2015 op eigen kosten (opnieuw aansluitkosten betalen dus, 249,- ex BTW geloof ik) migreren van Internet Plus naar Internet Plus Extra.

Ik denk dat ik dus nog lang plezier zal hebben van mijn ipv6 tunnel naar SixXs....
Die 249 euro waar je het over hebt, daarover moet je 249 euro korting onderhandelen. Dat hebben wij ook gedaan en toen was IPv6 gratis.
Met andere woorden: het zaakje stinkt, echte IPv6 support moet je afdwingen, en van een massale ondersteuning en migratie is geen sprake. Leuk.
Neehoor, ze zijn daar pas net begonnen met uitrollen. Men heeft al 1 1/2 jaar geroepen dat ze het gingen doen, maar de daadwerkelijke uitrol voor bestaande klanten van zakelijke verbindingen (in elk geval Internet Plus) is pas afgelopen maand begonnen. Na herhaaldelijk uitstellen, en dan ook nog enkel maar voor de klanten die aangeven dat ze graag willen, en dan nog mag je er normaal gesproken een paar honderd euro voor neertellen (installatiekosten) omdat het alleen gebeurd bij de overgang van Internet Plus naar Internet Plus Extra.
"Het is overigens onduidelijk hoe groot het subnet is dat klanten krijgen"

Ik verwacht dat het een /56 word of /48. Dat is de meest gebruikte vorm in IPv6 setups. Groter hoeft echt niet voor normale thuis situatie.

Ben erg benieuwd, heb net op mijn pfSense firewall ook dhcp6 aangezet. We shall see :) Zou lekker wezen. Kan ik m'n colocatie eindelijk bereiken op de IPv6 adressen (/48) die ik daar heb :*)
Blijkbaar zijn eer meedere providers druk bezig. Ik zie net dat ik van Zeelandnet ook een IPv6 adres met /48 subnet heb gekregen. Blijkbaar vindt pfSense dat allemaal tof, nog even kijken hoe ik een IPv6 adres aan mijn clients toegewezen krijg :)
Klopt, Zeelandnet is in december begonnen met het stapje voor stapje uitdelen van IPv6. Als je er niet uitkomt, kom eens kijken in Het grote IPv6 topic.
De IETF-richtlijnen bevelen aan eindgebruikers te voorzien van meerdere /64-netwerken. De gedachtengang daarachter is dat het aantal apparaten in huis dat verbonden is met internet snel toe zal nemen en eindgebruikers daardoor behoefte krijgen aan meerdere IP-netwerken thuis om bepaalde zaken te kunnen scheiden. Als gebruikers maar één /64 krijgen, dan zullen ze die gaan opdelen in kleinere netwerken, terwijl de ipv6-autoconfiguratie uitgaat van netwerken van /64. Het is de bedoeling dat eindgebruikers autoconfiguratie gaan gebruiken, dus eindgebruikers dienen meerdere /64-netwerken te krijgen, aldus de IETF.

In een oorspronkelijk richtlijn werd een /48 genoemd, wat geïnterpeteerd werd dat de IETF een /48 toegewezen wilde hebben aan iedere eindgebruiker. De IETF heeft dat later rechtgezet: De /48 was genoemd om internetaanbieders aan te sporen niet te krenterig te zijn met ip-toewijzingen, maar mag niet geïnterpreteerd worden als een advies om nodeloos ip-ruimte te verspillen. Als duidelijk is dat een /48 nooit gebruikt zal worden is het niet tegen de richtlijnen om eindgebruikers kleinere netwerken toe te kennen.

Ik denk dat je in praktijk iets tussen de /48 en de /64 in kunt verwachten.

[Reactie gewijzigd door dmantione op 7 april 2015 13:57]

Het kan zijn dat de IP range via PD (Prefix Delegation) gegeven wordt en niet via dhcpv6...
Google heeft een pagina waar duidelijk te zien is dat IPv6 in rechte lijn aan populariteit aan het winnen is: http://www.google.com/int...cs.html#tab=ipv6-adoption
Je kan ook per land zien http://www.google.com/int...per-country-ipv6-adoption (onderaan kan je de werelddelen selecteren)

Met vele andere landen en providers die op het punt staan IPv6 uit te rollen wordt stilaan IPv6 werkelijkheid.

Tegen de huidige groei, zal eind 2015 +- 9% van de wereldweide google gebruikers dit doen via IPv6.

[Reactie gewijzigd door xp65 op 7 april 2015 12:36]

De lijn zou exponentieel moeten verlopen! (Zoals de eerste jaren) Dat het momenteel slechts lineair gaat is een teken dat zaken veel te langzaam gaan!

En dat is best triest, wanneer je bedenkt dat IPv6 al vele jaren aanwezig is, en het laatste IPv4 adressen een jaar geleden al vergeven zijn. (Aan de grote providers, niet de particulieren)

Het gaat allemaal veel te langzaam. En de belangrijke reden is natuurlijk dat beiden niet compatible zijn. Dat is echt een enorm slechte keuze geweest!
En de belangrijke reden is natuurlijk dat beiden niet compatible zijn. Dat is echt een enorm slechte keuze geweest!
Dat heeft inderdaad zijn nadelen, maar met NAT is een hoop op te vangen. En daarmee wordt voorkomen dat er nog tientallen jaren allerlei legacy-meuk mee sleept in IPv6. Dus beter 1x de pijn dan nog decennialang overbodige compatibiliteitsellende meeslepen, wat mij betreft :)
Dat het lineair is komt met name doordat grote providers het lang hebben proberen tegen te houden. Toen XS4ALL ermee uitkwam (jaren geleden), durfden diverse KPN medewerkers mij te vertellen dat IPv6 belachelijk was. KPN had IPv4 adressen zat..
(Klopt enkele grote EU ISP's hebben vele kleine ISP's opgericht en die hebben adres reeksen geclaimed bij RIPE en de mini-ISP's zijn langzamerhand allemaal door de grote broers opgeslokt. (Inclusief de adressen) Dit hamsteren heeft een jaar of 10 geleden plaatsgevonden.

Probleem voor de grote ISP's dat hoewel ZIJ veel adressen hebben anderen dat niet hebben en naar IPv6 gaan en al een jaar of 5 bezig zijn. Ook zijn allerlei applicaties inmiddels ipv4/ipv6 aware dus de trein is in beweging, en de rem is bijna versleten.
Vergeet niet dat dit een percentage is, geen absoluut getal. De groei van internet als geheel (inclusief IPv4) moet je ook meetellen. Ik zou natuurlijk liever nog meer groei zien maar zolang het percentage IPv6-gebruik ieder jaar meer dan verdubbelt maak ik me niet zo'n zorgen. We hebben een heel erg lange aanloop gehad, maar nu gaat het vlot.
Als de grote ISPs beginnen dan gaat het hard. We hebben gezien hoe het in Belgie ging. In een paar weken tijd zat men daar opeens van niks op 30%. Als Ziggo een beetje doorzet zal ook Nederland in die buurt komen te zitten.

[Reactie gewijzigd door CAPSLOCK2000 op 7 april 2015 20:07]

Nederland staat nu nog op zo'n 2%, ik ben benieuwd hoe snel Ziggo de uitrol zal doen en wat de impact daarvan zal zijn op dit percentage. Belgie staat op 31%, ik vermoed dat Nederland ineens best snel in de buurt kan komen.
Ziggo en UPC samen hebben volgens mij iets tussen de 40 en 50% van de breedbandinternetverbindingen dus als IPv6 grootschalig wordt uigerold zullen we of belgie inhalen of daar vlak onder staan.
Ik heb mijn modem thuis bridged staan (Ook ZIggo) in combinatie met een router die alleen IPv4 ondersteund en via NAT kan alles dat achter dat ding zit het internet bereiken. Maar wat ik mij af vraag, kan ik vanachter die router (het is een D-Link DIR-855) zo via IPv6 het internet op, krijgen mijn apparaten ondanks de NAT en firewall toch een extern IPv6 adres of laat het ding niks door omdat hij er niks mee kan?
Kan iemand hier wat zinnigs over zeggen? Ik ben hier toch erg benieuwd naar.
Anoniem: 55563
@Justin0137 april 2015 14:19
Als een ISP je een IPv6 block uitdeelt dan krijg je in feite een prefix die elk IPv6-apparaat op je netwerk zelf aanvult tot een volledig IPv6-adres.

De router past een soort DHCP toe met deze prefix en broadcast deze op het lokale netwerk. Als de router geen IPv6 ondersteunt dan gebeurt dit niet en kun je ook intern niet van IPv6 gebruik maken. Als je router wel IPv6 ondersteunt maar je provider niet dan is er nog zoiets als link-local adressen zodat je intern wel van IPv6 gebruik kan maken.

Overigens kun je je D-Link prima geschikt maken voor IPv6 als je tenminste niet terugschrikt van alternatieve firmware. Lees eens op het forum van DDWRT welke recente beta build goed werkt. Als het eenmaal is geflasht dan werkt het met wat inlezen vrij makkelijk. En dan heb je er ineens een wat geavanceerdere router bij die nog meer nieuwe trucjes kan dan IPv6. Maar lezen en nog eens lezen want je wilt voorkomen dat je je router brickt!!

[Reactie gewijzigd door Anoniem: 55563 op 7 april 2015 17:01]

Ik ken DD-WRT en varianten wel, heb op wat oude hardware een tijdje hiermee gedraait. Alleen is er voor mijn DIR-855 geen support vanuit DD-WRT, door de gebruikte chipset |:(

Toch bedankt voor je reactie!
Alle apparaten moeten ipv6 kunnen en aan hebben staan, dus ipv6 is alleen bereikbaar in je interne netwerk als je router dit actief doorzet.

Dus dat hangt van de instellingen van je router af.
Nou was er sprake van dat klanten die hun modem/router in bridge zouden hebben laten zetten, geen IPv6 adres zouden krijgen. Echter:
Klanten met een ouderwets kabelmodem, dat enkel als modem en niet als router dienstdoet, krijgen pas volgend jaar een ipv6-adres.
... betekent dat dat op termijn iedereen een IPv6-adres zal krijgen, ook als je je modem/router in bridge hebt?
Nou was er sprake van dat klanten die hun modem/router in bridge zouden hebben laten zetten, geen IPv6 adres zouden krijgen. Echter:

[...]

... betekent dat dat op termijn iedereen een IPv6-adres zal krijgen, ook als je je modem/router in bridge hebt?
Of dat betekent dat Ziggo gepland heeft om komend jaar die modems te vervangen.
Dat zal wel moeten, als ze snelheden omhoog willen gooien naar 50Mbit heb je de nieuwe DOCSIS modems sowieso nodig. Ze stellen IPv6 uit zolang het kan natuurlijk want modems vervangen kost nogal wat geld.
Er is een verschil tussen de hele oude modems die puur modem zijn en een moderne die zijn nat/router functie uit heeft staan.
Die laatste kan prima met IPv6 overweg.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee