Ipv6-verkeer op internetknooppunt AMS-IX neemt weer af

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.

Reacties (120)

[erikmeuk3]

Als ik de totalen bekijk inclusief IPv4 neemt de traffic ook af.
https://www.ams-ix.net/te...al-traffic-data?year=2013

[MuVo]

Bezuinigen op vernieuwing... dus bezuinigen op IPV6 als IPv4 het ook nog kan doen..

[firest0rm]

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
abc.abc.abc.abc
123.123.123.123

[Reactie gewijzigd door firest0rm op 22 juli 2024 16:11]

[Qaatloz]

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.

[woutervh]

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? :-)

[dirkpostma]

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!

[justinkb]

2 tot de macht 128, niet 128 tot de macht 2...

[mvdejong]

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)⁴, 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.

[CyBeR]

- 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 22 juli 2024 16:11]

[Mr.Monk]

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.

[raphidae]

'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 22 juli 2024 16:11]

[Blokker_1999]

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.

[raphidae]

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 22 juli 2024 16:11]

[Bl@ckbird]

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 22 juli 2024 16:11]

[raphidae]

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 22 juli 2024 16:11]

[erikmeuk3]

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?

[Mr_Light]

Treenaks in 'nieuws: Voorstel: in 2011 alle internetservers over op IPv6'

Dit is IPv4 all over again; "zooooooveeeeel adressen die raken 'nooit' op!"

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

[SnowDude]

Alleen de header is even lang bij elk ipv6 pakket de pakketten zelf hebben geen vaste lengte.

[Countess]

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.

[Verwijderd]

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 Verwijderd op 22 juli 2024 16:11]

[Freeaqingme]

@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 22 juli 2024 16:11]

[marcelvb]

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 22 juli 2024 16:11]

[slaapkopje]

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.

[Verwijderd]

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.

[cyberstalker]

Forwarding hoeft helemaal geen memory copy in te houden. Dit kan gewoon door de kernel met tcp splicing gedaan worden.

[!null]

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.

[TvdW]

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.

[Iblies]

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 22 juli 2024 16:11]

[dwilmer]

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.

[arjohn]

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 22 juli 2024 16:11]

[databeestje]

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.

[Rmg]

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.

[goldrnr]

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.

[marcelvb]

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 (2⁸).

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 22 juli 2024 16:11]

[Durandal]

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

[roberttttt]

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

[Verwijderd]

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.

[mae-t.net]

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.

[bzerk]

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.

[Aikon]

Dat zou enkel een stagnering verklaren, geen daling.

[flipjevandejam]

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

[Trinitronic]

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 22 juli 2024 16:11]

[MrDummy]

Ik kan wel voorstellen op paar punten:

1. IPv4 is makkelijker te onthouden en te noteren.
2. Er is nog veel oude apparatuur in gebruik (vooral via marktplaats, veilingen, dumpzaken etc) waardoor aantal steeds weer gebruikt worden onder armere mensen. Verouderde firmwares en zo, mensen zijn al blij genoeg dat internet werkt... Zelfs Win XP computers komen regelmatig terug!
3. Bezuinigingen en vertragingen door de crisis. Providers gaan minder snel aanpassen.
4. Teveel mensen met weinig tech kennis: dat IPv6 wat voordelen heeft zegt hen weinig. IPv4 is voor hen eerst makkelijker om te onthouden en in te stellen (zie punt 1)

Ik ga daarom van uit dat IPv4 nog vele jaren door blijft lopen. En het is verder zonde dat veel (goede) oude apparatuur weggegooid wordt omdat hun firmware IPv6 niet kent.

[Blokker_1999]

Maar geen 1 van die punten verklaard een daling van het verkeer.

En ja, IPv4 zal niet snel verdwijnen, maar imho moeten ISPs wel dringend werk maken van de uitrol. Niets houd je tegen om thuis zelf een router te zetten die met IPv6 aan het internet hangt maar intern in huis wel alles netjes op IPv4 houd.

De dag dat een ISP zelf NAT moet gaan toepassen omdat deze geen IP adressen meer overheeft zitten we pas echt in shit.

[Jermak]

Daar zit nou het probleem een duidelijke, eenvoudige, uitleg van hoe je van IPv4 naar IPv6 kan omschakelen/netwerk opbouwen.

XS4All bied all jaren de Ipv6 mogelijkheid aan. Mijn routers en modems ook.

Maar Hoe moet ik dat IPv6 addres door lussen naar mijn computer.

je kunt genoeg info vinden maar dat is min 400 pagina's lang. http://www.getipv6.info/

Daarom zullen weinig mensen overstappen.

Heeft iemand een leesbare handleiding /schema?

[CAPSLOCK2000]

Als je provider het levert hoef je zelf niks te doen. Alle moderne computers ondersteunen IPv6 en gebruiken het automatisch als het beschikbaar is. Als IPv6 aan staat op je verbinding (zie het controlepaneel van XS4All) dan zou het vanzelf moeten werken.

[be_bert]

1. IPv4 is makkelijker te onthouden en te noteren.
--> onderhoud is gelijk, router blijven routers, datacenters blijven datacenters, computers blijven computers
2. Er is nog veel oude apparatuur in gebruik
--> ipv4 apparatuur kan in een ipv6 netwerk gebruikt worden, daarenboven veel producten hebben al zeer lang ipv6 en ipv4 ondersteuning. Producenten zijn hier al lang mee bezig. Het is de infrastructuur die achter loopt. Logisch aangezien zij de grootste kost moeten dragen en dit het meest ingrijpend is.
3. Bezuinigingen en vertragingen door de crisis. Providers gaan minder snel aanpassen.
--> correcte reden, ze gaan investeringen uitstellen. Ook al zijn ze onvermijdelijk
4. Teveel mensen met weinig tech kennis: dat IPv6 wat voordelen heeft zegt hen weinig. IPv4 is voor hen eerst makkelijker om te onthouden en in te stellen (zie punt 1)
--> Mensen met weinig tech kennis kennen ipv4 noch ipv6, dat is het net het mooie aan de omschakeling. enkel de technische mensen die voor de infrastructuur zorgen, hebben kennis nodig.

[sfranken]

@be_bert
Ik vind 192.168.x.x toch veeeel makkeklijker onthouden dan 3ffe:6a88:85a3:08d3:1319:8a2e:0370:7344

[Blokker_1999]

Alleen zal je thuis op je intern netwerk helemaal zo geen lang adres moeten onthouden. Je zou zelfs perfect thuis elk apparaat een extern EN intern adres kunnen geven waarbij het intern adres zelfs eenvoudiger te onthouden is dan vandaag.

Localhost veranderd bijvoorbeeld van 127.0.0.1 naar ::1
Link local veranderd van 169.254.0.0/16 naar fe80::/10
Local network gaat van 192.168.0.0/16 naar fc00::/7

Maw, vele adressen worden met ipv6 zelfs korter dan wat ze vandaag zijn! Mede dankzij het mogen laten vallen van 0 blokken.

[Maurits van Baerle]

@sfranken
Daar pak je ook wel twee extreme voorbeelden. Mijn vaders externe IPv6 adres is korter en makkelijker te onthouden dan zijn externe IPv4 adres.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 16:11]

[CAPSLOCK2000]

Je doet het verkeerd. Waarom gebruik je niet fe80::xx als adres?

[comecme]

Een IPv4-adres is makkelijker te onthouden ja. Maar hoevaak moet je een ip-adres onthouden? Meestal gebruik je toch gewoon een hostname of dns?

[databeestje]

Mwah, dat onthouden is een kwestie van wennen, het eerste stukje is thuis altijd hetzelfde. En het laatste nummertje in IPv4 is ook het laatste nummertje in IPv6.

Dus 192.168.11.233 is 2001:470:d72c::233

Maar, ik geef toe, ik heb een knakkie voor nummers, "waarom onthou je dat" zouden mijn collegas zeggen

Als je er dagelijks mee omgaat komt het als vanzelf, gek genoeg heb ik minder problemen met het onthouden van de IP range van de colo, als de v6 range bij Xs4all.

Thuis heb ik een tunnelbroker prefix, deze wijzigt niet. Hoef ik me daar ook niet meer druk over te maken. Thuis server win.

[Jermak]

bedankt voor het antwoord , maar dat geeft nog geen inzicht in de oplossing.

[Maurits van Baerle]

@MrDummy
Geen van jouw punten kunnen logischerwijs een verklaring zijn voor een afname van het verkeer, hooguit voor een stagnerende groei.

Als er er op piekmomenten 9Gbps door de AMS-IX heen ging omdat mensen waren overgestapt en nu minder dan zouden jouw punten 1, 2 en 3 alleen te verklaren zijn als mensen IPv6 ingeschakeld en toch weer uitgeschakeld hebben, nieuwere apparatuur vervangen hebben door oudere, of ineens vergeten hoe ze hun bestaande IPv6 verbinding in de lucht moeten houden.

Kortom, er moet een andere reden zijn.

[MAX3400]

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 22 juli 2024 16:11]

[firest0rm]

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.

[rc5proxy]

Via IPV6 is juist TPB wel bereikbaar IPv4 heeft brein dicht laten timmeren maar ipv6 zijn geen blokkade's voor opgelegt.

[Henk Poley]

Zover ik het kan zien heeft TBP geen IPv6 adres meer op het moment.

[erikmeuk3]

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%

[TheKmork]

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.

[Maurits van Baerle]

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.

[TheKmork]

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

[Kevinp]

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.

[wjn]

In hoeverre is dit gerelateerd aan spam verkeer, is dat ook gedaald soms?

[mashell]

IPv6 heeft een slechte naam maar het v6 verkeer spam noemen gaat zelfs mij als niet-IPv6-believer te ver

[windwarrior]

Huhwat, hoezo heeft IPv6 een slechte naam? De adaptie is ronduit laag te noemen, maar IPv6 fixt wel vrij veel problemen van IPv4. Ik kan gebruik van de nieuwe standaard alleen naar aanraden, en ben zelf sinds een jaar of wat te bereiken over IPv6. Niet geloven in IPv6 is gewoon onzin, het is de oplossing voor het probleem, simple as that.

[Verwijderd]

Niet IPV6 believer? Volgens mij is het een redelijk objectief feit dat IP Adressen aan het opraken zijn en dat daar wat voor in de plaats moet gaan komen.

Dat je er niet nu, honderdmiljard euro in gaat rammen oké, maar we ontkomen er niet aan om over te stappen gezien straks zelfs je electrische tandenbortel een IP wil.

[erikmeuk3]

Ik heb een goed werkende IPv6 vebinding, met uitzondering van...
SMTP is een dienst die bij mijn provider niet op IPv6 beschikbaar is.
De reden hiervoor is, dat de globale spam filtering hier nog niet klaar voor is.

[Reactie gewijzigd door erikmeuk3 op 22 juli 2024 16:11]

[marcelvb]

Mijn mailserver is bereikbaar via IPv4 en IPv6. Ik gebruik een spamhaus blacklist en wat andere filtertjes die naar inhoud kijken. Ik krijg nooit spam. Ik vind het een beetje een slappe reden om geen IPv6 in te voeren.

[Verwijderd]

Dat hangt voor de volle 100% af van de software die je gebruikt. Ik zou niet weten waarom IPV6 moeilijker zou zijn om spam op te filteren. Die globale spamfiltering zijn dus gewoon bedrijven die er nog geen geld aan uit willen geven hun programmatuur bij te werken.

[LD1995]

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.

[timberleek]

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.

[Eloy]

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.

[timberleek]

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"

[Blokker_1999]

NAT is GEEN veiligheidsfunctie. Zet het daar dan ook niet voor in.

[timberleek]

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

[CAPSLOCK2000]

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.

[comecme]

Waarom zou ondoorzichtig glas beter of slechter zijn dan vitrage?

[Mijzelf]

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?

[Verwijderd]

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

[Ultraman]

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 22 juli 2024 16:11]

[Mijzelf]

Of ik nu moet port-forwarden of poorten moet vrijgeven in de firewall, dat lijkt me evenveel geklooi.

[NLAnaconda]

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?

[Maurits van Baerle]

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 22 juli 2024 16:11]

[Dual Infinity]

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

[shredder]

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.

[dmantione]

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.

[TheKmork]

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.

[be_bert]

"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 22 juli 2024 16:11]

[TheKmork]

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 22 juli 2024 16:11]

[sfranken]

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

[Maurits van Baerle]

Aangezien een aantal grote sites zoals Facebook en YouTube verantwoordelijk zullen zijn voor een hoop van het IPv6 dataverkeer (veel mensen zullen niet eens doorhebben dat ze via IPv6 hun YouTube filmpjes binnenhalen) vraag ik me eerder af of sommige grote dataverkeerveroorzakers iets hebben verandert.

Het zou wat dat betreft interressant zijn om de Amsterdam te vergelijken met Londen, Parijs en Frankfurt of die ook een daling hebben gezien.

[CAPSLOCK2000]

Google ziet ook een dip begin deze maand maar stijgt daarna wel verder door: http://www.google.com/ipv6/statistics.html#tab=ipv6-adoption

Akamai heeft ook wat verstoringen begin deze maand, al zijn ze niet zo significant.
http://www.akamai.com/ipv6

In Duitsland zie je de grafiek plat gaan.
http://www.de-cix.net/about/statistics/

Ik vermoed dat het probleem zit in de update van Apple's Airport die een maand geleden uit kwam. Apple doet het nogal goed in NL en daarom is het effect hier groter.

[Maurits van Baerle]

Zie mijn uitleg hierboven, die Apple Airport update heeft helemaal niets verandert aan native IPv6 verkeer (alleen aan IPv6 over IPv4 bij sommige configuraties) dus dat kan het nooit geweest zijn.

[CAPSLOCK2000]

Waarom niet? Het aantal native IPv6 verbindingen in NL is nog zo klein. Ik vind het heel aannemelijk dat een groot deel van de IPv6 verbindingen in NL niet native is, maar via een tunnel loopt. Nadat het verkeer die tunnel weer verlaat zie je het als gewoon IPv6 verkeer in de statistieken.

Daarbij zijn de mensen die de moeite nemen om een tunnel te bouwen vaak ook internet-grootverbruikers. Die kunnen dus best een flinke invloed hebben op het totale verkeer. Aan de tijden van pieken op de AMSIX kun je duidelijk zien dat het Nederlandse IPv6 verkeer voor het grootste deel van consumenten afkomstig is, en die gebruiken voornamelijk tunnels.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 16:11]

[Maurits van Baerle]

Ik heb het hierboven iets verduidelijkt. Tunnel verkeer is IPv4 (ook al zitten er IPv6 pakketjes in verstopt) en wordt dus door AMS-IX niet tot IPv6 gerekend.

Overigens verwacht ik dat in Nederland er aanzienlijk meer mensen Native IPv6 gebruiken dan een tunnel. Een tunnel is iets voor hobbyisten maar zul je andere mensen niet snel mee zien experimenteren.

Mijn vader heeft geen flauw idee wat IPv4 of IPv6 is maar sinds XS4ALL hem vorig jaar heeft overgezet van IPv4 naar dual-stack gaat een groot deel van z'n verkeer nu via IPv6, zonder dat hij dat door heeft.

Ik denk dat er voor iedere tien mensen die zonder het te weten op IPv6 zitten er misschien één ooit van tunnels heeft gehoord.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 16:11]

[CAPSLOCK2000]

Ik heb het hierboven iets verduidelijkt. Tunnel verkeer is IPv4 (ook al zitten er IPv6 pakketjes in verstopt) en wordt dus door AMS-IX niet tot IPv6 gerekend.

Tot aan het eindpunt van de tunnel, vanaf daar is het wel degelijk IPv6. Aangezien Nederland nogal goed voorzien is van tunnel-endpoints blijft het meeste tunnelverkeer binnen NL. Sterker nog, er zullen een hoop tunnels uit het buitenland hier eindigen, en dan als IPv6 over de amsix gaan.