Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 120, views: 32.187 •

Het volume aan ipv6-verkeer dat over het Amsterdamse internetknooppunt AMS-IX vloeit, is de afgelopen maand afgenomen tot circa 4Gbps. Daar ging juist een periode van groei aan vooraf; in januari kwam het ipv6-verkeer in pieken tot ruim boven de 6Gbps uit.

De daling in het ipv6-verkeer werd opgemerkt door de vaksite Ispam. Waar het ipv6-verkeer in januari nog rond de 5 gigabit per seconde zat en bij pieken zelfs 6,5Gbps haalde, is dat in februari en maart weer afgenomen. In maart wordt meestal om en nabij de 4Gbps getransporteerd met pieken richting de 4,5Gbps. De omvang van het ipv6-verkeer is wel nog altijd hoger dan een halfjaar geleden, toen het volume aan ipv6-verkeer tussen de 2Gbps en 3Gbps uitkwam.

Waardoor het ipv6-verkeer nu weer afneemt, is niet te zeggen; een woordvoerster van de AMS-IX kan daar geen verklaring voor geven. Ze tekent echter aan dat de daling pas twee maanden duurt, en dat het dus nog te vroeg is om te spreken van een trend. Bekend is wel dat Nederlandse providers treuzelen met de invoering van ipv6; van de grote internetproviders is Xs4all de enige die ipv6-connectiviteit aanbiedt aan zijn klanten. Een overstap naar ipv6 is noodzakelijk omdat er te weinig ipv4-adressen zijn om verdere groei van het internet aan te kunnen.

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.

ipv6 traffic ams-ix

Reacties (120)

Reactiefilter:-11200118+1102+212+31
Bezuinigen op vernieuwing... dus bezuinigen op IPV6 als IPv4 het ook nog kan doen..
kan het niet IPv4 raakt op en op = op dus we zullen wel moeten overstappen als er steeds meer apparaten/mensen op het internet willen komen

wat ik alleen niet snap is waarom het nummer gebonden moet zijn
kunnen ze IPv4 niet een update geven waardoor ook het alfabet gebruikt kan worden?
of is dat juist IPv6 :S
abc.abc.abc.abc
123.123.123.123

[Reactie gewijzigd door firest0rm op 29 maart 2013 11:16]

Nee dat gaat niet even. IPv6 is de verbeterde versie van v4. v6 werkt ook nog efficienter omdat bv alle v6 pakketjes even lang zijn, en v4 niet. Dat scheelt onder andere een checksum.
Alleen de header is even lang bij elk ipv6 pakket de pakketten zelf hebben geen vaste lengte.
klopt. maar per (normaal) ipv6 packet hoeft een router minder werk te verzetten om hem te verwerken en door te sturen. wat denk ik is waar mr monk op doelt.
per ipv6 packet hoeft een router minder werk te verzetten
Hoe kom je daar nou bij ?

IPv4 en IPv6 gebruiken precies dezelfde architectuur. Longest-match prefix routing, hop-by-hop. Het enige verschil is dat IPv4 32 bits heeft voor een adres, en IPv6 heeft 128 bits.

In de praktijk is het zelfs zo dat IPv6 forwarding meer resources kost dan IPv4 forwarding. Bv omdat forwarding tables (de zgn. FIB) wordt opgeslagen in duur geheugen (TCAM memory). Met grotere adressen, kun je minder entries in je tabel opslaan. Dus met andere woorden, je moet duurdere routers bouwen om IPv6 te kunnen forwarden.

Als je denkt dat het anders is, leg me dan alsjeblieft uit welk technisch detail daar dan voor zal zorgen. (IP header checksum is geen argument. Dat kost niks bij forwarden).

[Reactie gewijzigd door gryz op 29 maart 2013 13:53]

@gryz, ipv6 pakketten (en headers) zijn inderdaad groter dan met ipv4. Dat an sich zorgt niet voor minder belasting. Echter, doordat er zoveel meer ip-adressen mogelijk zijn, hoeven deze minder gesegmenteerd te worden. Zo wordt er nu een /8 (geloof ik) per continent uitgedeeld. Hierdoor worden routingtabellen kleiner (of ze groeien minder snel), en daardoor zorgt ipv6 minder belasting op routers.

Dat heeft overigens vooral betrekking op grote WAN routers. Een router in een huis- en tuinsetup zal hier weinig van merken. Die heeft twee routes: 1 range naar binnen toe, de rest naar buiten toe.

[Reactie gewijzigd door Freeaqingme op 29 maart 2013 20:45]

Met IPv6 zijn de adressen langer, maar het aantal entries in de routing table is veel kleiner (door grotere blokken, minder fragmentatie).

Tevens zijn de IPv6 headers simpeler (minder velden), dus ja, minder werk voor de router.

[Reactie gewijzigd door marcelvb op 29 maart 2013 21:21]

Lijkt me ook niet dat alle IPv6 pakketjes even lang zijn, erg onhandig. En hoe een vaste (van de header) lengte een checksum scheelt begrijp ik ook niet echt.
IPv4 en IPv6 werken met het "one's complement" checksum-algoritme. Dit is een heel simpel algoritme, maar bij IPv4 kan de lengte van de header van een pakketje varieren, waardoor er veel meer CPU-instructies nodig zijn om de checksum te verifiëren.
IPv4 header heeft altijd 20 bytes tenzij er opties in zitten, maar die worden zelden gebruikt, IPv6 heeft 40 bytes en eventueel extension headers. Het voordeel van IPv6 is dat er een stuk minder velden in de header zitten, Dat is voor een router dus minder werk om een pakketje te routen. De IPv4 checksum is een kostbare check die niet altijd uitgevoerd wordt, In IPv6 heeft men die check overgelaten aan de hogere layers.
De IPv4 checksum is een kostbare check die niet altijd uitgevoerd wordt
Myth.
De IPv4 checksum is helemaal geen kostbare check.
Het is letterlijk een checksum, je telt gewoon alle 20 bytes bij elkaar op. Simpele instructies. Weinig bytes, die allemaal in een cache-line passen.

En bovendien hoef je de checksum niet bij iedere hop te checken. Je moet hem wel aanpassen. Omdat de TTL verandert. Maar dat is simpel. Omdat de checksum echt een som is. Als je de TTL met 1 verminderd, dan verminder je de checksum ook met 1. Omdat het een som is. Dus met 2 decrement instructies heb je je header (checksum en TTL) aangepast.

De kosten van pakketforwarding zitten voornamelijk in 3 zaken.
1) memory copies
2) destination address lookup
3) alle extra features, ACLs, QoS, NAT, etc.

De header checksum is verwaarloosbaar. Het zijn enkel IPv6 fanaten die denken dat dat wat uitmaakt. En zoals gewoonlijk hebben de IPv6 fanaten het weer eens mis.
Forwarding hoeft helemaal geen memory copy in te houden. Dit kan gewoon door de kernel met tcp splicing gedaan worden.
'De verbeterde versie'... Hmm, daar wil ik toch wel over twisten hoor.

Er zijn wel heel veel ipv6 adressen, maar er zitten een paar addertjes onder het gras:
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.
Zo wordt het vaak uitgelegd. Of dat er meer ipv6 adressen zijn dan zandkorrels op aarde, etc. etc.

Maar je moet ze wel kunnen gebruiken, en daar zit 'em het probleem. De minimale prefix voor een routeerbaar ipv6 blok is /64 (de helft van het totale aantal bits dus). Dit is omdat autoconfig en dergelijke er een MAC adres in kwijt moet kunnen (zo'n 'verbetering' van ipv6).

Dat betekent dan ook weer dat een provider in theorie minimaal een /52 nodig heeft om /64's uit te kunnen geven aan klanten.

In theorie, want een /52 is niet globally routable, dwz dat een /52 altijd weer binnen een grotere wel globally routable prefix moet vallen. Dit maakt een /52 nutteloos voor netwerken die multihomen met bgp.

De minimal globally routable prefix was eerst een /48, maar nu het hele aggregation principe dat ipv6 zo geweldig zou moeten maken in de praktijk niet blijkt te werken en de global route-tables exploderen door de fragmentatie is dit door RIPE eerst bijgesteld naar een /32 en nu zelfs naar een /29.

Als je het nog volgt: voor een netwerk, elk netwerk, dat multihomed heb je minimaal één /29 nodig, en grotere providers meerdere.

Van de 128 bits zijn er dus al 99 voor host addressing en downstream subnetting en maar 29 voor network addressing. En dat is nu, dat zal nog gaan schuiven in de toekomst als het meer gebruikt wordt en dus meer fragmenteert (als dat ooit gebeurd).

Even vergelijken: de minimal globally routable prefix in ipv4 is /24, zoveel verschil is dat niet met een /29, en al helemaal niet zo'n verschil als het totaal aantal ipv6 adressen doet lijken.

Er worden gewoon met een noodvaart ipv6 adressen weggepist, iemand met een home netwerk die een blokje wil moet een /64 krijgen, wat neerkomt op 18.446.744.073.709.551.616 adressen. Ook al gebruik je er maar twee.

Dit doet denken aan hoe ze ooit begonnen met ipv4 adressen uitgeven, in blokken van /8 tegelijk, omdat er toch genoeg waren...

Daarom investeren bedrijven niet in ipv6, de problemen rijzen de pan al uit voor het goed en wel gebruikt wordt. Ze investeren liever in het aankopen van ipv4 blokken, want dat werkt in ieder geval. Bij ipv6 is het nog maar afwachten of die nog wel allemaal routeerbaar zijn over 5 jaar.

Er wordt al gediscussieerd over een NAT66/NPT66 implementatie om deze problemen het hoofd te bieden.

Dus 10 voor effort, 0 voor implementation. Overigens een beetje jammer dat zelfs tweakers.net het alleen heeft over het totale aantal adressen, en niet hoeveel er daadwerkelijk bruikbaar zijn.

Zie ook:
http://blog.ioshints.info...endent-ipv6-prefixes.html
https://labs.ripe.net/Mem...ibility-of-prefix-lengths
http://blog.ioshints.info...ust-might-need-nat66.html

PS. Wat ze hadden moeten doen is gewoon vier, acht of twaalf octets prefixen aan ipv4 (eventueel eerst vier en dan later wanneer nodig nog vier, etc). De al in gebruik zijnde ipv4 adressen kunnen dan bereikt worden over 0.0.0.0.v4.v4.v4.v4. Maar men wilde graag slim zijn.

[Reactie gewijzigd door raphidae op 29 maart 2013 13:58]

Wat verwacht jij dan dat ze gaan doen? IP¨v6 is naar ICT standaarden vandaag al antiek te noemen. Reeds meer dan 20 jaar geleden is men begonnen met IPv6 om uiteindelijk halverwege de jaren 90 tot een standaard te komen. Dat pas je nu niet zomaar even opnieuw aan.

En 29bits is nog altijd enkele duizenden keren groter dan 24bits. Het mag niet veel lijken, maar het maakt wel een wereld van verschil.

En de reden waarom er discussie is rondom NAT op IPv6 is net omdat sommige mensen er het nut niet van inzien en net willen voorkomen dat een adresseringssysteem met zoveel adressen ooit in dezelfde problemen komt als IPv4 vandaag. Want geloof het of niet, sommige zien in NAT nog de oplossing voor het opgeraken van IPv4 adressen.
Ik voorspel het volgende:

Grote ISP's en hosters gaan niet direct overstappen op ipv6, want zij hebben meestal al veel meer ipv4 dan dat ze nodig hebben, al groeien ze 500% over de komende jaren. Ze zullen eerder investeren in meer ipv4, wat nu al duidelijk aan de gang is (bijvoorbeeld Microsoft heeft niet al te lang geleden een /8 gekocht voor iets van $20 miljoen). /22 ipv4 blokken gaan nu voor zo'n $8 per IP op de vrije markt, dat zal natuurlijk nog sterk stijgen als ze daadwerkelijk op zijn.

Er is geen enkele motiviatie voor die partijen om een heleboel geld uit te geven om hun services over v6 aan te bieden, vooral omdat ze dan in feite twee netwerken naast elkaar moeten gaan draaien. Kost dus dubbel geld voor geen winst voor hen.

Dat 29 bits meer is dan 24 bits doet er niet toe, als India en China eenzelfde dekking willen als het westen nu dan is dat gewoonweg niet genoeg. Nog een reden om niet in v6 te investeren. Daarbij is /29 de minimal globally routable prefix, ze geven veel grotere prefixes uit natuurlijk (/12 en /8 zijn er al heel wat van uitgegeven geloof ik). Net als dat /24 het minimum bij ipv4 is, maar grote providers een /8 hebben.

Startups (ISPs/Hosters) die alleen v6 aanbieden komen daardoor niet van de grond, want ze zullen toch echt ipv4 connectiviteit moeten bieden. Dat betekent extra investeren om ipv4 tegen woekerprijzen te kopen/huren of investeren in translation hardware en een niet volwaardige service bieden.

Die kosten (en ook de investeringen van de gevestigde partijen) zullen aan de klant doorgerekend worden.

Dit zal de situatie de komende 10-15 jaar zijn. Ergens in die periode zal de Amerikaanse overheid onder internationale druk een gedeelte van de 40% van de ipv4 space die ze nu in bezit hebben teruggeven aan RIRs (USPS: /8, DoD: /8, Airforce: /8, DARPA: /8, Army: /8, SIGINT: /8, etc. etc.).

Ook zullen dan de grote providers door regulering gedwongen worden in ipv6 te investeren (denk aan de FCC die bijvoorbeeld geen frequentie spectra meer gaat geven als er geen ipv6 gebruikt wordt).

Als dat niet snel genoeg gaat zullen landen als China, die vanwege hoe hun landelijk netwerk is opgezet heel makkelijk hun internet kunnen afsluiten van de buitenwereld, zich IP blokken gaan toeeigenen die aan partijen zijn toegewezen die ze toch al blokkeren (Google, Youtube, etc.). Andere landen (vooral die met een staatsbedrijf als enige tier0) zullen volgen. Dit proces wordt versneld als de v4 ranges die zijn toegewezen aan de overheid van de VS niet eerlijk verdeeld worden over de RIRs als ze vrijgegeven worden.

Dan krijg je fragmentatie in het internet en in DNS. Doemscenario, maar goed mogelijk zoals het er nu voorstaat met ipv6.

[Reactie gewijzigd door raphidae op 29 maart 2013 17:19]

Het is nu al zo dat als je wil aanbieden op RFP's / tenders van de Amerikaanse overheid, dat dit IPv6 moet ondersteunen.

Voor startup ISP's heeft men een blok adressen gereserveerd om NAT te kunnen doen tussen IPv4 en IPv6.

De economische groei is in de US en Europa relatief klein en we zijn ruim bedeelt in IPv4 adressen. In Zuid-Amerika en Azië is de krapte veel groter. Grote delen van het Internet draait daar op IPv6. Als Westerse bedrijven zaken willen blijven doen met Azië en Zuid-Amerika moeten ze IPv6 implementeren of iets als NAT gebruiken.

Voor fragmentatie van het internet ben ik niet zo bang. De business driver om IPv6 in te voeren is veel belangrijker geworden: Namelijk met je klanten kunnen blijven communiceren.

[Reactie gewijzigd door Bl@ckbird op 30 maart 2013 00:23]

Goed, misschien loopt het niet zo'n vaart. Daarom zeg ik ook doemscenario. Maar deze scenario's worden wel degelijk behandeld in operator kringen en dat schrikt erg af.

Hoe het nu (en al 20 jaar) loopt is verre van ideaal, de (kleine) problemen met ipv6 stapelen zich op en dat maakt grotere en kleinere partijen afwachtend, zeker als zoals het eruit ziet ipv4 de komende 20 jaar nog gaat voldoen voor connectiviteit.

En dat zie je direct terug in het afnemende verkeer. Als ik een gok moet wagen is de afname die nu te zien is te wijten aan early adopters en nerds die thuis een he.net tunneltje hadden en het nu weer laten vallen omdat je er nog vrijwel geen reet mee kan.

Mensen hebben ermee gexperimenteerd en hebben kennis opgedaan hoe het werkt, maar als je er dan verder weinig mee kan en je traffic gaat langzamer over ipv6 omdat dat op veel punten nog in software geswitched wordt dan ga je weer terug naar ipv4 totdat je er wel wat aan hebt.

Dit heb ik uit persoonlijke ervaring, ik heb ons netwerk twee jaar geleden volledig dual-stack gemaakt (bgp en endpoints), maar ik zie nu de noodzaak niet om nieuwe rommel nog dual-stack te maken. Ik weet nu hoe het moet als het later nuttig gaat zijn, tot dan ga ik geen tijd meer besteden aan iets wat maar 0.01% traffic voor de rekening neemt.

PS. Je hebt gelijk dat LACNIC relatief meer ipv6 adressen allocated heeft, maar dat vertaalt niet direct in meer gebruik. Veruit de meeste allocaties zijn voor dual-stack gebruik.

Zie bijvoorbeeld: Google: Per-Country IPv6 adoption

Verdere info:
http://meetings.ripe.net/..._ordinary_users_.7gzD.pdf
http://www.apnic.net/publ...hts/stats/ipv6-geographic
http://www.apnic.net/publ...s/stats/ipv6-distribution

Oh, en nog een punt: al was het dat het westen naar ipv6 gedwongen wordt door regulatie en omdat ze moeten kunnen communiceren met bepaalde gebieden waar alleen ipv6 gebruikt wordt: het probleem van de fragmentatie van de global route-table blijft, en dat is een technisch probleem waar niet zo 1-2-3 een oplossing voor is.

Behalve het splitsen van de route-table zelf per regio, en dus het internet.

In theorie is ipv6 geweldig te aggregeren waardoor de globale route-table klein kan blijven, in de praktijk is de fragmentatie nu al erger dan in de ipv4 tables en is er geen zicht op verbetering. Dat is waarom de minimal globally routable prefix steeds groter wordt.

Het is nu al een probleem, hoe zie je het voor je als ipv6 dadelijk "echt" gebruikt wordt? Dat alle routers maar gewoon vervangen worden?

Nee, dan komt er een stop-gap oplossing in de vorm van translation en dergelijke hacks. Eigenlijk weer precies zo'n hack als classless (CIDR) addressing was voor ipv4 toen de ipv4 route-tables uit de hand liepen.

[Reactie gewijzigd door raphidae op 29 maart 2013 17:20]

Mijn provider geeft mij een /48 reeks.
Als ik mijn fritz!box mag geloven gebruikt 1 pc een hele lange lijst met IPv6 adressen.
Waarom dit zo is ben ik benieuwd naar?
Treenaks in 'nieuws: Voorstel: in 2011 alle internetservers over op IPv6'
Dit is IPv4 all over again; "zooooooveeeeel adressen die raken 'nooit' op!"
8)7 :9

Ik had overigens niet gedacht deze discussie nu al te voeren, aan de andere kant we zijn al weer 5,5 jaar verder.

Gezien de investering in hard en software die al gedaan en hoeveel tijd het kost om een nieuwe spec te schrijven waar iedereen het zo'n beetje mee eens is; lijkt me het eerder dat ze bepaalde stukken afgeschreven(deprecated) worden om problemen op andere plekken op te lossen.

Dingen als openflow geven aan dat er continue wel over het hele gebeure nagedacht wordt maar ik mis nog een oplossing en leiderschap voor tussen hier en 'utopia'.
Omdat de getallen slechts een weergave zijn van de acht bits die gebruikt worden in een IPv4 adres ;) . Een IPv4 adres is in feite een combinatie van vier keer 8 bits. Als je die omzet kun je die in getallen weergeven van 0-255.

Het idee van IPv6 is, dat ze over gaan op een adressering met meer bits (4x 32 bits) waarbij die weergegeven worden in hexadecimalen. (met dus ook letters omdat je anders tot 2^32 getallen moet gebruiken 0-4294967295)

Het is dus helemaal niet mogelijk om letters te gebruiken in IPv4 omdat de getallen die je ziet slechts een weergave van bits zijn en niet het echte adres zelf.
Wel, in principe wel, je kunt evengoed die decimalen als HEX weergeven
enkel heb je dan ipv 255.255.255.255, FF.FF.FF.FF

C0.A8.00.01 iemand? :-)
Een IPv4 adres is een binair 32-bits getal; 123.123.123.123 is slechts de tekstuele representatie van dat nummber. Zie ook http://en.wikipedia.org/wiki/IP_address.

[Reactie gewijzigd door arjohn op 29 maart 2013 11:22]

Nee zo werkt dat niet :-)

Een IPv4 adres wordt gerepresenteerd door 4 bytes, of 32 bits. 123.123.123.123 is slechts een representatie van een IPv4-adres met decimalen. Als je ook letters zou gebruiken, zou je veel meer bits nodig hebben om deze adressen op te kunnen slaan.

En dat is eigenlijk precies wat IPv6 doet. Deze heeft niet slechts 32 bits voor de adressen, maar maarliefst 128 bits, en maakt 128 tot de macht 2 mogelijke adressen mogelijk, is... miljardmiljardmiljoenen en dan nog meer! Het opschrijven van adressen wordt wel een stukje lastiger, bv.

3ffe:6a88:85a3:0:1319:8a2e:0370:7344 (hexadecimale notatie)

Jouw voorgestelde abc.abc.abc.abc wordt mogelijk gemaakt door IPv6! :+
2 tot de macht 128, niet 128 tot de macht 2...
Juist ja, dus alle apparaten ter wereld moeten een nieuwe IPv4 stack hebben om elkaar te verstaan. Alle routers, operating systemen, mobiele telefoons, alles moet bijgewerkt worden.

En dan is er nog niets een enkele regel code gemaakt, nee, gewoon over naar IPv6.

De nieuwe IPv4 stack is er al sinds 2001, dat is IP versie 6 geworden.

- Routers doen al IPv6
- Firewalls doen al IPv6
- Switches doen al IPv6
- Alle grote globale kruispunten doen al IPv6.
- Sommige mobieltjes doen al IPv6.

Maak geen vergissing, men doet het voorkomen of een extensie toepassen op IPv4 een optie is, maar dan moet iedereen dezelfde extensie ondersteunen.

En wat heb je aan een internet verbinding met een IPv4 adres die maar met een select stukje van het "grotere" IPv4 internet kan praten? Dat is geen fundamenteel andere situatie dan de huidige stand van IPv6, het is er al, maar nog niet overal geimplementeerd.

Op het werk hebben we IPv6, en circa 60% van ons verkeer bestaat eruit door het overschakelen van een paar grote partijen zoals google, youtube en facebook.

De nummers van de AMS-IX zijn de cijfers over heel Nederland, let wel, als mensen IPv6 thuis aangezet krijgen gaat direct een zeer groot deel van het verkeer hier wel over.
Nee, bij IPv4 is een adres een 4-byte integer, je kunt er niet zomaar letters aan toevoegen. (Bijna) alle implementaties van IPv4 slaan de adressen dus ook op in 4 bytes/32 bits, en ze zijn ook niet ingesteld op het vertalen van letters, dus je zou 99.99 % van de aan het internet hangende systemen, en ALLE routers enz. moeten herprogrammeren om dit te doen. En aangezien voor (snelle schatting) 30-40 % van deze apparaten en/of hun operating systems geen nieuwe versies meer worden uitgebracht, zou je het internet aardig slopen.

Bij IPv6 wordt het niet een getal van 4 bytes/32 bits maar 16 bytes/128 bits, wat dus niet 4 miljard mogelijke adressen oplevert, maar (4 miljard)4, dat hierboven genoemde hele grote getal. Overigens hebben we ook niet echt 4 miljard IPv4 adressen beschikbaar, er vallen er veel af :
- er zijn 3 reeksen die "private" zijn, die niet op het internet gerouteerd worden, maar handig zijn om binnen je eigen netwerkje te gebruiken zonder dat je een conflict kunt krijgen tussen een systeem met een adres op jouw netwerkje en een systeem op het internet met datzelfde adres;
- er zijn reeksen gereserveerd voor speciale toepassingen, zoals 224.*.*.*, dat wordt gebruikt voor multicast-toepassingen (1 pakketje dat wordt verwerkt door alle systemen die zich daarop hebben "geabonneerd");
- alle adres-reeksen waarvan het eerste getal <127 is, zijn klasse A adressen, die dus als 1 blok van 16 miljoen adressen zijn toegekend, meestal aan grote Amerikaanse bedrijven en overheids-instanties;
- datzelfde geldt voor de adressen die beginnen met 128-192, klasse B adressen die als blok van 65536 adressen zijn vergeven.

Maar ik denk dat de behoefte aan nieuwe adressen momenteel wat minder is, omdat we een zekere mate van verzadiging bereikt hebben : in de ontwikkelde landen hebben alle mensen ondertussen wel een eigen adres, dus daar zit niet veel groei in, en veel bedrijven die vroeger meerdere, soms vele, IP-adressen gebruikten hebben nu 1 IP-adres, waarbij de rest via NAT erachter verborgen zit, en laten het verdelen van het verkeer op basis van de gevraagde service (HTTP/HTTPS/FTP, enz.) en eventueel server-/domeinnaam door frontend-routers uitvoeren.
- er zijn reeksen gereserveerd voor speciale toepassingen, zoals 224.*.*.*, dat wordt gebruikt voor multicast-toepassingen (1 pakketje dat wordt verwerkt door alle systemen die zich daarop hebben "geabonneerd");
Dat is nog erger, dat is heel 224.0.0.0/4, oftewel 224.0.0.0 tot en met 239.255.255.255. Dat is de oude "Class D", voor multicast inderdaad. En nóg erger, achter de multicastadressen zit de oude "Class E", dus 240.0.0.0/4, en dat is gewoon compleet "reserved for future use", welk gebruik echter nooit gaat komen, en onbruikbaar als gevolg daarvan.
- alle adres-reeksen waarvan het eerste getal <127 is, zijn klasse A adressen, die dus als 1 blok van 16 miljoen adressen zijn toegekend, meestal aan grote Amerikaanse bedrijven en overheids-instanties;
Dat is een simplificatie van wat er gebeurt. In de basis is dat waar, maar we gebruiken al jaren geen classful netwerken meer. Dus veel van die netwerken zijn gewoon weer uitgegeven voor CIDR routing aan de verschillende RIRs in de wereld. Wel zijn er nog een aantal die daadwerkelijk gebruikt worden, waar inderdaad één organisatie een of zelfs meerdere /8 netwerken heeft. Bijvoorbeeld MIT (18.0.0.0/8), Apple (17.0.0.0/8), de US DoD heeft er een stuk of 8 geloof ik, etc.
- datzelfde geldt voor de adressen die beginnen met 128-192, klasse B adressen die als blok van 65536 adressen zijn vergeven.
Ook outdated informatie, zelfde als hierboven.

[Reactie gewijzigd door CyBeR op 29 maart 2013 16:32]

Ervan uitgaande dat elk apparaat een uniek IP-adres krijgt. Kijken we naar Nederland dan zien we dat de groei in mobiel internet wordt geremd door de kosten. Providers hanteren een dynamisch adres en met de limiet loopt de vraag (hard?) terug. In mijn eigen omgeving zie ik dat steeds meer mensen gebruik maken van wifi. En die router heeft maar 1 ip-adres.


Wtf :?
Reactie @ firestorm

[Reactie gewijzigd door Iblies op 29 maart 2013 12:17]

Nu heeft je router inderdaad 1 IP-adres, anders waren de adressen al lang op. Het idee is (als ik het goed heb gelezen) dat je router bij IPv6 een /64-blok krijgt, en je dus zelf 2^64 adressen hebt om thuis te verdelen. Dan heeft elk apparaat echt een uniek IP-adres.
Zeker geen Informatica op je VO school gehad

Voordat je neerbuigend doet eerst je eigen facts straight hebben he? 4 bytes != 16 bits. Een byte bestaat uit 8 bits.
een ipv4 adres bestaat uit 4x 8 bits

8bits.8bits.8bits.8bits.

je kan in elk deel dus maar tot 255 tellen. ( 0b11111111 )

Letters toevoegen kan niet. Omdat letters ook maar een nummerieke waarde is waar je een afspraak over hebt gemaakt. Als er de afspraak is gemaakt dat het ascii is dan is bijvoorbeeld het getal 65 (0x41) als een A gedisplayed moet worden.

Het ip adres 10.1.1.124 bijvoorbeeld kan je dotted quad decimaal schrijven.
als hexadecimaal 0A01017C je weet dat het groepen van 4 bits zijn dus dit is om te rekenen naar een dotted quad.

of binair : 00001010 00000001 00000001 01111100
of zelfs als decimaal zonder punten: 167838076

De enige oplossing is meer bits toevoegen. Ipv6 doet dat dus door het volgende te gebruiken

16bits.16bits.16bits.16bits.16bits.16bits.16bits.16bits.
Nein... dat kan niet... ipv4-addressen zijn 4 bytes groot (dus 4 getallen van 0-255)
wat ik logischer had gevonden was dat men gewoon ipv 4 bytes er bijvoorbeeld 8 had gepakt waardoor ipv4 automatisch een subset was geworden van ipV8; waarschijnlijk was de apdaptatie dan groter geweest dan nu bij de van ipv6.
We schijven een IPv4 adres als 4 getallen tussen de 0 en 255 met een punt er tussen. In werkelijkheid zijn het 4 bytes (32 bits) in de header van het pakketje. In 1 byte (8 bits) past alleen maar een getal tussen de 0 en 255 (28).

Dus om er meer in op te slaan, moet je de structuur van de header aanpassen zodat er meer in past. En dat is dus IPv6, waar een adres 16 bytes (128 bits) is. We noteren dat als 8 x 2 bytes in hexadecimale notatie (0..9a..f). Bv. 2a03:2880:2110:df01:face:b00c:0000:0008 (facebook.com).

[Reactie gewijzigd door marcelvb op 29 maart 2013 21:30]

wat ik alleen niet snap is waarom het nummer gebonden moet zijn
kunnen ze IPv4 niet een update geven waardoor ook het alfabet gebruikt kan worden?
of is dat juist IPv6 :S
abc.abc.abc.abc
123.123.123.123
Die 123.123.123.123 is slechts de weergave die je ziet. Het getal wordt opgeslagen/verwerkt als 4 bytes (0-255), dus letters gaat niet passen.
de vier cijfergroepen bij IPv4 zijn representaties van de 8 bits codering per onderdeel. Dus 001 is eigenlijk 00000001 en 256 is eigenlijk 11111111
De volledige reeks van 256 mogelijkheden per IPv4-deel/getal is dus al benut.
Om zo iets als abc te kunnen gebruiken zouden 3x8 bits nodig zijn per onderdeel en dus een nog veel grotere verandering dan IPv4 naar IPv6
Routers werken met enen en nullen, 123 vertaald naar 1111011. Als je letters wil gaan gebruiken moet je deze dus vertalen naar enen en nullen, dit gaat niet lukken omdat er in een ipv4 header maar 32 bit gereserveerd is voor een adres.
Dat kan niet; elk groepje dat jij als nummers ziet is geen willekeurig 3-cijferig getal, maar precies 1 byte in het protocol. In 1 byte passen 256 verschillende getallen. Van die beperking wordt in films ook dankbaar gebruik gemaakt; zoals je geen echte telefoonnummers hebt die met 555 beginnen, zo heb je geen echte IP-adressen waarvan een van de posities een grotere waarde heeft dan 255.
Dat zou enkel een stagnering verklaren, geen daling.
De kans is groot dat er één of meerdere Newsservers minder bereikbaar zijn met gratis IPv6 pilots (e.g. xsnews, xs4all, Tele2?).

Dit was in eerdere nieuwsberichten over IPv6 veelal 80% van de 'groei' in dataverkeer: nieuws: µTorrent draagt bij aan 1400 procent toename in ipv6-verkeer
Bezuinigen op harddisks, maar ik zal binnenkort nog eens een 2 GB erbij halen, en mee helpen aan IPV6 downloads :-)

[Reactie gewijzigd door Trinitronic op 29 maart 2013 19:52]

Laten we het erop houden dat de afsluiting van TPB misschien iets te maken heeft met de afname van verkeer? Daarnaast, maar dat is puur gebaseerd op marktwerking die ik zo om me heen zie, zijn een aantal grote hosters aan het uitbreiden naar het buitenland en zal hun verkeer niet meer direct over de AMS-IX gaan maar mogelijk over andere IX'en in het land van het (nieuwe) datacenter.

/edit 11:14: eigenlijk is dit artikel niet geheel volledig want ondanks de zogenaamde uitputting van IPv4-adressen, is de totale doorvoer over het afgelopen jaar juist enorm gestegen. Geen idee welke protocollen nog meer voor een hogere throughput kunnen zorgen maar het grafiekje spreekt boekdelen: https://www.ams-ix.net/statistics

[Reactie gewijzigd door MAX3400 op 29 maart 2013 11:14]

Nee hoor, want de maanden hiervoor was er een stijging. Je bent gebrainwashed door brein misschien.

Waar het aan ligt weet ik niet, mogelijk doordat vele mobiele abbonementen die onbeperkt of grote databundels hadden langzaam omgezet gaan worden naar(belachelijk) kleine bundels waardoor mensen minder gebruik maken van internet.

Mogelijk bezuinigen mensen op internet en gebruiken ze het minder.

Een andere mogelijkheid is dat een groot deel kwam van failliete bedrijven. Of dat het weer beter gaat met de economie waardoor mensen thuis minder tijd hebben om te internetten.

Ook een gebrek aan nieuwe films in het begin van het jaar kan daar een gevolg van zijn.

Uiteindelijk zuig ik hier nu al een aantal redenen uit mijn duim welke tegenstrijdig zijn. En allemaal waar kunnen zijn (niet te gelijk).

Het is niet te zeggen onder destination en afkomst te weten. En ik ga er vanuit dat de AMS-IX dat niet monitort.

Daarnaast gaat het specifiek over ipv6 verkeer. Iets wat wel vreemd is, en zonder ipv4 grafiek erbij kan je dus niets zeggen. Mogelijk neemt gewoon het internet verkeer af. Alsmede daardoor ipv6.
Laten we het erop houden dat de afsluiting van TPB misschien iets te maken heeft met de afname van verkeer?
TPB heeft hier vrijwel geen invloed op ik snap ook niet waarom je dit aankaart als reden

alsof de hele wereld constant op the pirate bay zit?

vind het een zwak argument.
Via IPV6 is juist TPB wel bereikbaar IPv4 heeft brein dicht laten timmeren maar ipv6 zijn geen blokkade's voor opgelegt.
Zover ik het kan zien heeft TBP geen IPv6 adres meer op het moment.
Gebruik al heel lang een IPv6 mirror van de TPB werkt goed.
Maar het aantal verbingen die ontstaan in IPv6 als je deelneemt is minder dan 1%
TPB draait misschien wel op dual stack (zowel IPv4 en IPv6), maar aangezien de meeste thuisgebruikers nog geen toegang hebben tot IPv6 en dus via IPv4 met de site connecten lijkt het me bijzonder sterk dat dit enige merkbare invloed zal hebben op het IPv6 dataverkeer op de AMS-IX.

Wat dan wel de verklaring is dat weet ik uiteraard ook niet precies. Het kan natuurlijk ook juist zo zijn dat de verspreiding van IPv6 juist toeneemt, waardoor er meer routes op het internet vormen die je IPv6 data kan nemen. Hierdoor hoeft het dus niet meer per sé via de AMS-IX peers te lopen, maar ook bijvoorbeeld via de private peering en directe upstream transit verbindingen van een provider.
TPB produceert ook niet veel dataverkeer. Het is een website met wat torrentbestandjes en een tracker. Allemaal relatief weinig data.

Al het feitelijke Torrent verkeer gaat P2P en niet via the servers van TPB.
Ja, maar aangezien die thuisgebruikers die dat P2P verkeer doen grotendeels nog op IPv4 draaien zal het gros van dat P2P verkeer dus op IPv4 plaatsvinden en vrijwel niet op IPv6
Waardoor het ipv6-verkeer nu weer afneemt, is niet te zeggen; een woordvoerster van de AMS-IX kon daar niet direct een verklaring voor geven. Bekend is wel dat Nederlandse providers treuzelen met de invoering van ipv6; van de grote internetproviders is Xs4all de enige die ipv6-connectiviteit aanbiedt aan zijn klanten.
Dat heeft toch geen invloed op het op dit moment "afnemende" dataverkeer?
Zie de relatie niet?
Klopt, het zou hoogtens een afname van de groei verklaren.

Overigens is de piek niet 6,5Gbps zoals het artikel vermeld, dat lijkt zo op bovenstaande grafiek die erg uitgezoomd is. Als je inzoomt (door oudere week- of maandgafieken te bekijken) zie je hogere pieken, er zijn in december pieken boven de 9Gbps gehaald

[Reactie gewijzigd door Maurits van Baerle op 29 maart 2013 12:50]

Zelf vermoed ik dat het seizoensgerelateerd is. Als in: meer traffic in de wintermaanden dan in de zomermaanden.

Hier wat meer grafiekjes e.d.:
http://solusns.com/world-...ent-have-on-the-internet/

Opvallend daar zijn twee specifieke grafieken:
1. AMS-IX IPv6 2011-2012
2. De 5-year traffic (IPv4+IPv6) growth van DE-CIX

In (2) is vrij duidelijk te zien dat elk jaar na de winter de hoeveelheid traffic daalt met ~10% of meer. Dat is een minder grote daling dan de ~20% waar dit artikel over gaat, maar gezien de grotere volumes is dat logisch.
Zie ook: http://www.de-cix.net/about/statistics/

Bij de laatste link zie je ook dat het IPv6-verkeer voor de 'world launch' een vergelijkbaar verloop heeft als (1) en dat de invloed van hoe internet door de meeste mensen gebruikt wordt gedurende het jaar nog niet van invloed was op de traffic.

Het is wat lastig grafieken van de AMS-IX te vinden, maar hier zie je een vergelijkbaar seizoenseffect in 2009: http://blog.sflow.com/2010/02/ams-ix.html
Wellicht dat er iets gewijzigd in de infrastructuur? Niet alle infrastructuur kan v6 pakketjes aan. Het kan zo een vertekend beeld geven door bv ipv6 over ipv4.
Wat ik niet begrijp is dat IPv6 niet Backwards compatible is met IPv4. Is het bijvoorbeeld niet mogelijk om een range van 4,3 miljard IPv6 adressen te reserveren en die direct mappen met IPv4 adressen?
Dat wil dan zeggen dat die gereserveerde adressen direct vertalen naar IPv4 adressen en visa versa.
Ja, dat kan met NAT64, maar moet je ze zelf (of je ISP) doen. Software die je daarvoor kunt gebruiken vind je op http://www.litech.org/tayga/ Zodra je een dergelijke router in de lucht hebt kun je met V4-machines communiceren vanaf machines die enkel V6 hebben.
Het probleem is dat het niet alleen een kwestie is van een langere reeks cijfertjes. De hele header van een IPv6 packet ziet er anders uit, dus een device dat alleen IPv4 praat snapt helemaal niks van de header dat hij binnenkrijgt.
Hoe verhoudt dit zich tegenover het "normale" IPv4 verkeer?
Als dat net zo hard daalt is er misschien iets totaal anders aan de hand. Je kan niks afleiden uit de informatie in dit bericht als je de context niet weet.
Totaal gemiddeld verkeer: 1092 Gb/s
Gemiddelde IPv6 verkeer: 4.1 Gb/s
Gemiddelde IPv4 verkeer: 1088 Gb/s
Gebaseerd op het jaarlijkse gemiddelde verkeer.
Bron: https://www.ams-ix.net/technical/statistics

[Reactie gewijzigd door LD1995 op 29 maart 2013 11:33]

"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."

ipv4- en ipv6-packets zijn wel compatibel. ipv6 kan ipv4 aan. ipv4 kan ipv6 verkeer aan. De packets worden echter wel omgevormd indien nodig door machines die tussen ipv6 en ipv4 netwerken staan. Hierdoor moet geen enkel netwerk zich zorgen maken over het andere protocol, enkel de apparatuur aan de rand van de netwerken moet de 2 'talen' spreken.

Onder niet compatibel zou ik verstaan dat ipv6 apparatuur enkel kan communiceren met ipv6 apparatuur over een ipv6 verbinding; Dit scenario zou betekenen dat het ipv4 internet op een gegeven moment uit zou worden gezet en dan weer aan als het ipv6 internet. Dit is dus niet het geval.

[Reactie gewijzigd door be_bert op 29 maart 2013 11:26]

Aangezien IPv4/IPv6 sowieso bij grote providers alleen aan de randen van netwerken gebruikt worden is de situatie sowieso al zoals jij die schetst. De meeste providers gebruiken bijvoorbeeld MPLS in hun backbone, waardoor er totaal niet gekeken wordt naar de IP header van het pakketje.
Alleen aan de rand van het netwerk wordt er gekeken in de IP header om te zien waar het pakketje heen wil, dan wordt er een MPLS header op geplakt, en gaat hij aan de hand van de MPLS headers door het netwerk naar zijn eindbestemming binnen dat netwerk. Pas daar wordt er weer naar het IP pakketje gekeken om het verder te routeren naar een naburig netwerk, of naar de eindbestemming.
In feite gaat het dus sowieso alleen om de edge routers die IPv4/IPv6 moeten spreken. De core routers kunnen IPv4 of IPv6 praten, zolang het MPLS protocol zijn weg maar kan vinden.

Dit is dan even een voorbeeld obv MPLS, er zijn ook wel andere varianten, maar de meeste grote transit netwerken maken gebruik van MPLS.

Kortom: Een IPv6 pakketje kan prima over een IPv4 netwerk reizen, zolang de eindpunten binnen dat netwerk maar IPv6 praten.

[Reactie gewijzigd door TheKmork op 29 maart 2013 11:53]

@be_bert
Zonder vertaal machines ertussen kan een v6 netwerk niet met eeen v4 network of andersom babbelen. Dat word er in het artikel bedoeld.
En de datacenters providers profiteren hier als een malle van, vragen 2,50 ex btw per ipv4 adres per maand!

[Reactie gewijzigd door Navi op 29 maart 2013 11:57]

Ik kan gewoon IPv4 adressen krijgen voor nop dus dat ligt er maar aan bij welke ISP je zit. Een datacenter zelf doet niks met IP adressen.
Leaseweb bijvoorbeeld.
Ik ben benieuwd wanneer de totale overstap er door is. Het moment dat NAT overbodig is en elk apparaat een eigen public-adres heeft. Geen gekloot meer met port-forwarding. Het enigste wat je dan nog nodig hebt is een goede firewall.
De NAT zal nog wel even blijven, zeker ivm veligheid.

Steeds meer apparaten hangen aan het netwerk, en de meeste zijn slecht beveiligd.
NAT is nu net een mooi stukje bescherming voor de gemiddelde gebruiker.
Helaas ja, imv veiligheid...

De developers van netwerk apparaten zijn zich laks gaan gedragen qua veiligheid, 'want dat ding hangt toch achter NAT'... |:(

Als er geen NAT was geweest dan zat er waarschijnlijk veel betere beveiliging op printers, NAS'en, enz.
Dat klopt zeker, maar die apparatuur is er nu eenmaal. En als je mensen gaat vertellen dat je over wilt naar een nieuw protocol, maar dat dat wel betekend dat een deel van hun apparatuur beter niet meer aan het internet kan hangen, dan denk ik toch dat het slecht of niet geaccepteerd gaat worden.

Men zal er weinig voor voeren om nu ineens, tv's, printers etc te gaan vervangen. "omdat die lui iets raars willen doen"
NAT is GEEN veiligheidsfunctie. Zet het daar dan ook niet voor in.
het is zeker geen veiligheidsfunctie, maar zo werkt het nu wel een beetje.

Hoewel het geen goede zaak is, is veel apparatuur nu toch wat beter afgeschermd. als die spullen rechtstreeks aan het grote boze internet hangen kun je leuke dingen doen.

Ik noem maar een smart tv van een vriend van me. Binnen het huisnetwerk kun je gewoon films etc starten zonder verdere authenticatie. Ook kun je de volledige status van de tv uitlezen en waarschijnlijk via een omweg ook wel aan de instellingen zitten.

Hang dat direct aan het internet en je kan leuke geintjes uithalen...
Niemand zegt dat je die TV onbeveiligd aan internet moet knopen. NAT is alleen niet de juiste techniek om te beveiligen. Je moet een firewall hebben, die geeft precies dezelfde beveiliging en meer, en het is nog een eenvoudiger apparaat ook.

NAT gebruiken voor beveiliging is zoiets ondoorzichtig glas in je ramen te zetten in plaats van vitrage op te hangen.
Waarom zou ondoorzichtig glas beter of slechter zijn dan vitrage?
En dus? Mijn router doet NAT (natuurlijk) en een logisch gevolg is dat mijn firewall dus geen inkomende poorten hoeft te blokkeren. Moet ik nu die firewall toch aanzetten omdat NAT niet ontworpen is voor veiligheid?
NAT is GEEN veiligheidsfunctie. Zet het daar dan ook niet voor in.
NAT is niet bedoeld als veiligheid, maar werkt in veel gevallen prima.

Als ik een Windos XP machine zonder patches een 192.168.1.0/24-adres geef en achter mijn NAT-router zet, kan je hoog en laag springen, maar je komt er niet zomaar op. Geef ik hem een publiek-adres dan logt de eerste script-kiddie binnen een uur aan...
Niet als de firewall in een router ervoor in het netwerk juist is geconfigureerd.
Zolang de firewall in de huis-tuin-keuken router overweg kan met IPv6 en goed is ingesteld (wat maar weinig verschilt van IPv4) dan kan er nog steeds geen verkeer van buiten zomaar bij jouw ongepatchte Windows XP machine komen als deze keurig een publiek IP heeft.
De firewall kijkt of inkomend verkeer te relateren is aan een bestaande verbinding of gerelateerd is aan een uitgaande verbinding. Dit is exact wat een IPv4 firewall ook al doet en die schiet het ongewenste verkeer af. Nog voordat het uberhaupt kan stuiteren op de NAT laag, welke enkel adressen vertaald.

Ik heb zeker apparaten in mijn netwerk hangen die zelf geen firewall draaien voor zover ik weet of in ieder geval geen firewall die ik kan besturen of van weet. Denk aan mobiele apparatuur, mediaspeler/internetradio, TV, printer, etc, maar een PC zou ook prima kunnen. Die krijgen keurig een (publiek) IPv6 adres bij mij thuis als ze de Router Advertisement accepteren. Maar vanaf de buitenwereld kun je daar echt niet zomaar bij zonder dat ik een poortje open zet in de firewall op de router. Alleen wat ICMP verkeer (de ongevaarlijke en/of noodzakelijke varianten er van) komt aan. Je kunt ze pingen als je het adres weet.
Dat is trouwens wel een verschil t.o.v. IPv4. IPv6 is niet gewoon IPv4 met een grotere adres range, er zijn wel degelijk verschillen. Je kunt niet zomaar alle ICMPv6 verkeer blokkeren zoals je alle ICMPv4 verkeer kon blokkeren, en een keurig werkende verbinding overhouden. Dit zie je sommige (verouderde en/of slecht geimplementeerde) firewall software namelijk nog wel eens doen en dan krijgt IPv6 de schuld, terwijl het daar niet aan ligt.

[Reactie gewijzigd door Ultraman op 18 april 2013 06:28]

Of ik nu moet port-forwarden of poorten moet vrijgeven in de firewall, dat lijkt me evenveel geklooi.
IPv6 infrastructuur blijft IPv6 infrastructuur. Die is niet ineens weg. Dus verminderd gebruik in combinatie met minder uitrol is de enige juiste reden van deze trend. Dit kan legio redenen hebben.

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013