IPv6 is de meest recente versie van het internetprotocol. Oorspronkelijk officieel gemaakt op 6 juni 2012, is het het resultaat van de inspanningen van de IETF om de “nieuwe generatie IP” (IPng: Internet Protocol next generation) te creëren, waarvan de richtlijnen werden beschreven door Scott Bradner en Allison Marken, in 1994, in de RFC 1752. De belangrijkste specificatie is te vinden in RFC 2460.
Het protocol wordt geleidelijk op internet geïmplementeerd en zou enige tijd naast IPv4 moeten werken, in een situatie die technisch “dual stack” of “dual stack” wordt genoemd. Op de lange termijn is IPv6 bedoeld om IPv4 te vervangen, dat slechts ongeveer 4 miljard (short scale)/miljard (long scale) (4×109) IP-adressen ondersteunt, tegenover ongeveer 340 undeciljoen (short scale)/sextillion (long scale) (3,4×1038) van de adressen van het nieuwe protocol.
Het onderwerp is zo relevant dat sommige regeringen deze implementatie hebben gesteund. Zo heeft de regering van de Verenigde Staten in 2005 bepaald dat al haar federale instanties in juni 2008 moeten bewijzen dat ze met het IPv6-protocol kunnen werken. In juli 2008 is een nieuwe herziening van de aanbevelingen voor de adoptie van IPv6 uitgebracht. bij federale agentschappen, waarbij een datum in juli 2010 werd vastgesteld voor het garanderen van IPv6-ondersteuning.
Motivaties voor het inzetten van IPv6
IPv4-uitputting en de behoefte aan meer internetadressen
De belangrijkste reden voor het inzetten van IPv6 op internet is de behoefte aan meer adressen, omdat de beschikbaarheid van gratis IPv4-adressen is beëindigd.
Om de redenen voor deze uitputting te begrijpen, is het belangrijk om te bedenken dat internet niet is ontworpen voor commercieel gebruik. In het begin van de jaren tachtig werd het beschouwd als een overwegend academisch netwerk, met een paar honderd onderling verbonden computers. Desondanks kan worden gezegd dat de IP-versie 4, 32-bits adresruimte niet klein is: 4.294.967.296 adressen.
Toch geloofde men al bij het begin van het commerciële gebruik ervan, in 1993, dat de adresruimte van internet in een periode van 2 of 3 jaar zou kunnen zijn uitgeput. Maar niet vanwege het beperkte aantal adressen, maar vanwege het aanvankelijke toewijzingsbeleid, dat niet gunstig was voor een rationeel gebruik van deze middelen. Deze ruimte was verdeeld in drie hoofdklassen (hoewel er momenteel strikt genomen vijf klassen zijn), namelijk:
- Klasse A: met 128 segmenten/netwerken, die afzonderlijk kunnen worden toegewezen aan entiteiten die ze nodig hebben, met elk ongeveer 16 miljoen adressen. Deze klasse werd geclassificeerd als /8, omdat de eerste 8 bits het netwerk of segment vertegenwoordigden, terwijl de rest vrij kon worden gebruikt. Het gebruikte de spatie tussen de adressen 00000000.*.*.* (0.*.*.*) en 01111111.*.*.* (127.*.*.*).
- Klasse B: met ongeveer 16 duizend segmenten van elk 64 duizend adressen. Deze klasse werd beoordeeld met /16. Het gebruikte de spatie tussen de adressen 100000000000000.*.* (128.0.*.*) en 10111111.111111111.*.* (191.255.*.*).
- Klasse C: met ongeveer 2 miljoen segmenten van elk 256 adressen. Deze klasse werd geclassificeerd als /24. Het gebruikte de spatie tussen de adressen 11000000.0000000.00000000.* (192.0.0.*) en 110111111.11111111.11111111.* (213.255.255.*).
De overige 32/8 blokken waren gereserveerd voor Multicast en voor de Internet Assigned Numbers Authority (IANA), de entiteit die de wereldwijde toewijzing van nummers op internet controleert.
De ruimte gereserveerd voor klasse A zou slechts 128 entiteiten bedienen, maar het nam de helft van de beschikbare adressen in beslag. Bedrijven en entiteiten zoals HP, GE, DEC, MIT, DISA, Apple, AT&T, IBM, USPS ontvingen echter onder meer dergelijke toewijzingen.
De aanvankelijke voorspellingen van een bijna onmiddellijke uitputting van hulpbronnen kwamen echter niet uit door de ontwikkeling van een reeks technologieën, die als een palliatieve oplossing werkten voor het probleem dat werd veroorzaakt door de versnelde groei:
- CIDR ( Classless Inter Domain Routing ) of classless routing , beschreven door RFC 1519 . Met CIDR werd het klassenschema afgeschaft, waardoor adressenblokken met willekeurige grootte konden worden toegewezen, indien nodig, wat een rationeler ruimtegebruik tot gevolg had.
- Het gebruik van NAT ( Network Address Translation ) en RFC 1918, die privé-adressen specificeren, niet geldig op internet, in bedrijfsnetwerken. NAT maakt het mogelijk, met slechts één geldig adres, een heel netwerk op basis van privé-adressen een, zij het beperkte, verbinding met internet te hebben.
- Het Dynamic Host Configuration Protocol (DHCP), beschreven door RFC 2131. Dit protocol maakte het voor providers mogelijk om de aan hun klanten verstrekte internetadressen te hergebruiken voor niet-permanente verbindingen.
De combinatie van deze technologieën verminderde de vraag naar nieuwe IP-nummers, waardoor de verwachte uitputting voor de jaren negentig werd uitgesteld naar de jaren 2010. De wereldwijde adoptie van IPv6 verloopt echter traag: volgens Google was de adoptie van IPv6 wereldwijd 2% in 2014, 5% in 2015, 8% in 2016, 14% in 2017, 20% in 2018, 25% in 2019, 30 % in 2020, 33% in 2021 en 35% in 2022; volgens APNIC was de wereldwijde IPv6-adoptie 2% in 2014, 3% in 2015, 5% in 2016, 9% in 2017, 16% in 2018, 19% in 2019, 24% in 2020, 27% in 2021 en 29% in 2022.
Andere motiverende factoren
De belangrijkste factor die de inzet van IPv6 stimuleert, is de behoefte aan de internetinfrastructuur. Het is een kwestie van bedrijfscontinuïteit, voor providers en tal van andere bedrijven en instellingen.
Er zijn echter nog andere factoren die de implementatie ervan motiveren:
- Internet of Things: in een toekomst waarin computers alomtegenwoordig is, zal de technologie aanwezig zijn in verschillende apparaten die momenteel nog niet intelligent zijn en die autonoom met elkaar kunnen communiceren: onzichtbare computers die zijn verbonden met internet, ingebed in de voorwerpen die dagelijks worden gebruikt – waardoor het leven nog vloeibaarder wordt. Denk aan geconnecteerde huishoudelijke apparaten, auto’s, slimme gebouwen, medische bewakingsapparatuur, enz. In elk huis en kantoor zullen tientallen, misschien zelfs honderden of duizenden apparaten worden aangesloten. IPv6, met overvloedige, vaste, geldige adressen, is noodzakelijk om deze toekomst te realiseren.
- Uitbreiding van netwerken: Verschillende factoren motiveren een steeds snellere uitbreiding van het internet: digitale inclusie, mobiele netwerken (3G, 4G, 5G), enz. Er zijn meer IP’s nodig.
- Kwaliteit van de dienstverlening: de convergentie van toekomstige telecommunicatienetwerken naar de gemeenschappelijke netwerklaag, IPv6, zal de rijping van diensten die vandaag beginnen, zoals VoIP, real-time videostreaming , enz., bevorderen en nieuwe diensten doen verschijnen. IPv6 heeft verbeterde ondersteuning voor verschillende serviceklassen, afhankelijk van de vereisten en prioriteiten van de service in kwestie.
- Mobiliteit: Mobiliteit is een zeer belangrijke factor in de huidige samenleving. IPv6 ondersteunt de mobiliteit van gebruikers, ze kunnen op elk netwerk worden gecontacteerd via hun IPv6-bronadres.
Wat is er nieuw in IPv6-specificaties
- Adres ruimte . IPv6-adressen zijn 128 bits lang.
- Adres autoconfiguratie . Ondersteuning voor automatische toewijzing van adressen in een IPv6-netwerk, de DHCP-server die we gewend zijn in IPv4 kan worden weggelaten.
- Hiërarchische adressering . Het vereenvoudigt de routeringstabellen van netwerkrouters en vermindert zo hun verwerkingsbelasting.
- Koptekst formaat . Volledig vernieuwd ten opzichte van IPv4: eenvoudiger en efficiënter.
- Extensie headers . Optie om aanvullende informatie op te slaan.
- Gedifferentieerde kwaliteitsondersteuning . Audio- en videotoepassingen beginnen geschikte verbindingen tot stand te brengen, rekening houdend met hun vereisten op het gebied van Quality of Service (QoS).
- Uitbreidingsmogelijkheid . Hiermee kunt u op een eenvoudige manier nieuwe specificaties toevoegen.
- encryptie . Verschillende extensies in IPv6 bieden vanaf het begin ondersteuning voor beveiligingsopties zoals authenticatie, gegevensintegriteit en vertrouwelijkheid.
IPv6-datagramformaat
Een IPv6-datagram bestaat uit een basisheader, geïllustreerd in de onderstaande afbeelding, gevolgd door nul of meer extension-headers, gevolgd door het datablok.
IPv6 datagram base header-formaat:
- Het heeft minder informatie dan de IPv4-header. De checksum is bijvoorbeeld uit de header verwijderd, omdat deze versie de foutafhandeling op de lagere laag als betrouwbaar beschouwt.
- Het veld Verkeersklasse (8 bits) wordt gebruikt om de serviceklasse aan te geven waartoe het pakket behoort, waardoor verschillende behandelingen mogelijk zijn voor pakketten die afkomstig zijn van toepassingen met verschillende vereisten. Dit veld dient als basis voor het functioneren van het quality of service (QoS) mechanisme in het netwerk.
- Het veld Flow Label (20 bits) wordt gebruikt bij nieuwe toepassingen die goede prestaties vereisen. Hiermee kunnen datagrammen worden gekoppeld die deel uitmaken van de communicatie tussen twee applicaties. Wordt gebruikt om datagrammen langs een vooraf gedefinieerd pad te verzenden.
- Het veld Payload Length (16 bits) vertegenwoordigt, zoals de naam al aangeeft, het gegevensvolume in bytes dat het pakket bevat.
- Het veld Next Header (8 bits) wijst naar de eerste extensieheader . Wordt gebruikt om het type informatie op te geven dat volgt op de huidige kop.
- Het veld Hop Limit (8 bits) bevat het aantal hops dat is verzonden voordat het datagram wordt weggegooid, dat wil zeggen dat dit veld het maximale aantal hops (door routers passeren) van het datagram aangeeft voordat het wordt weggegooid. Dit veld overschrijft de IPv4 TTL.
- Het veld Bronadres (128 bits) geeft het bronadres van het pakket aan.
- Het veld Destination Address (128 bits) geeft het bestemmingsadres van het pakket aan.
Fragmentatie en koersbepaling
In IPv6 is de host die het datagram verzendt verantwoordelijk voor fragmentatie, niet de tussenliggende routers zoals in het geval van IPv4. In IPv6 negeren tussenliggende routers datagrammen die groter zijn dan de netwerk-MTU. De MTU is de maximale MTU die wordt ondersteund door de verschillende netwerken tussen de bron en de bestemming. Hiervoor verzendt de host ICMP-pakketten van verschillende groottes; wanneer een pakket bij de bestemmingshost aankomt , worden alle te verzenden gegevens gefragmenteerd in de grootte van dit pakket dat de bestemming heeft bereikt.
Het MTU-ontdekkingsproces moet dynamisch zijn, omdat het pad tijdens de verzending van datagrammen kan veranderen.
In IPv6 wordt een niet-gefragmenteerd voorvoegsel van het originele datagram naar elk fragment gekopieerd. Fragmentatie-informatie wordt opgeslagen in een aparte extensiekop. Elk fragment begint met een niet-fragmenteerbare component gevolgd door een fragmentkop.
Meerdere koppen
Een van de nieuwigheden van IPv6 is de mogelijkheid om meerdere chained headers te gebruiken. Deze extra maaiborden zorgen voor meer efficiëntie, omdat de grootte van het maaibord naar behoefte kan worden aangepast, en voor meer flexibiliteit, omdat er altijd nieuwe maaiborden kunnen worden toegevoegd om aan nieuwe specificaties te voldoen.
De huidige specificaties bevelen de volgende volgorde aan:
- IPv6
- Koptekst hop-by-hop-opties
- Kop van bestemmingsoptie
- Routeringskop
- Fragmentkoptekst
- Authenticatie Beveiliging Payload Header
- Koptekst Bestemmingsopties
- Koptekst bovenlaag
Blokken en toewijzingen
De verantwoordelijkheid voor het toewijzen en beheren van de pool van IPv6-adressen werd in december 1995 gedelegeerd aan de IANA. Sindsdien heeft de IANA de blokken zo nodig naar de RIR’s gedistribueerd voor latere delegatie naar andere entiteiten.
Voorvoegsel | Toewijzing | Gegevens | observatie |
---|---|---|---|
0000::/8 | Gereserveerd door de IETF | ||
0100::/8 | Gereserveerd door de IETF | ||
0200::/7 | Gereserveerd door de IETF | Afgeschreven in december 2004 | |
0400::/6 | Gereserveerd door de IETF | ||
0800::/5 | Gereserveerd door de IETF | ||
1000::/4 | Gereserveerd door de IETF | ||
2000::/3 | Wereldwijde Unicast | ||
2001:0000::/23 | IANA | 01/07/1999 | |
2001:0200::/23 | APNIC | 01/07/1999 | |
2001:0400::/23 | ARIN | 01/07/1999 | |
2001:0600::/23 | RIJPE NCC | 01/07/1999 | |
2001:0800::/22 | RIJPE NCC | 11/02/2002 | |
2001:0c00::/23 | APNIC | 02-05-2002 | |
2001:0e00::/23 | APNIC | 01/01/2003 | |
2001:1200::/23 | LACNIC | 01-11-2002 | |
2001:1400::/22 | RIJPE NCC | 01/07/2003 | |
2001:1800::/23 | ARIN | 01/04/2003 | |
2001:1a00::/23 | RIJPE NCC | 01/01/2004 | |
2001:1c00::/22 | RIJPE NCC | 05/04/2004 | |
2001:2000::/19 | RIJPE NCC | 03/12/2013 | |
2001:4000::/23 | RIJPE NCC | 06/11/2004 | |
2001:4200::/23 | AFRINI | 01/06/2004 | |
2001:4400::/23 | APNIC | 06/11/2004 | |
2001:4600::/23 | RIJPE NCC | 17-08-2004 | |
2001:4800::/23 | ARIN | 24/08/2004 | |
2001:4a00::/23 | RIJPE NCC | 15-10-2004 | |
2001:4c00::/23 | RIJPE NCC | 17-12-2004 | |
2001: 5000::/20 | RIJPE NCC | 09/10/2004 | |
2001:8000::/19 | APNIC | 30/01/2004 | |
2001: a000 :: / 20 | APNIC | 30-11-2004 | |
2001:b000::/20 | APNIC | 03/08/2006 | |
2002:0000::/16 | 6to4 | 01/02/2001 | |
2003:0000::/18 | RIJPE NCC | 01/12/2005 | |
2400:0000::/12 | APNIC | 10/03/2006 | |
2600:0000::/12 | ARIN | 10/03/2006 | |
2610:0000::/23 | ARIN | 17-11-2005 | |
2620:0000::/23 | ARIN | 12-09-2006 | |
2630:0000::/12 | ARIN | 11/06/2019 | |
2800:0000::/12 | LACNIC | 10/03/2006 | |
2a00: 0000 :: / 12 | RIJPE NCC | 10/03/2006 | |
2a10:0000::/12 | RIJPE NCC | 05/09/2019 | |
2c00:0000::/12 | AFRINI | 10/03/2006 | |
2d00:0000::/8 | IANA | 01/07/1999 | |
2e00:0000::/7 | IANA | 01/07/1999 | |
3000:0000::/4 | IANA | 01/07/1999 | |
3ffe::/16 | IANA | 01/04/2008 | |
4000::/3 | Gereserveerd door de IETF | ||
5f00::/8 | IANA | 01/04/2008 | |
6000::/3 | Gereserveerd door de IETF | ||
8000::/3 | Gereserveerd door de IETF | ||
a000 :: / 3 | Gereserveerd door de IETF | ||
c000::/3 | Gereserveerd door de IETF | ||
e000::/4 | Gereserveerd door de IETF | ||
f000 :: / 5 | Gereserveerd door de IETF | ||
f800 :: / 6 | Gereserveerd door de IETF | ||
fc00::/7 | Unieke lokale Unicast | ||
fe00::/9 | Gereserveerd door de IETF | ||
fe80::/10 | Unicast met link-scope | gereserveerd voor protocol | |
fec0::/10 | Gereserveerd door de IETF | Verouderd door RFC3879 | |
ff00 :: / 8 | Multicast | Opdrachten voor dit blok geregistreerd door de IANA |
Adressering
Adressering in IPv6 is 128 bits (vier keer zoveel als IPv4) en omvat netwerkprefix en hostachtervoegsel . Er zijn echter geen adresklassen, zoals in IPv4. De grens van het voorvoegsel en het achtervoegsel kan dus overal in het adres zijn.
Een standaard IPv6-adres moet bestaan uit een provider-ID , abonnee-ID , subnet-ID en node-ID . De node-ID (of interface-ID) moet 64 bits lang zijn en kan worden gevormd uit het fysieke adres (MAC) in EUI 64-formaat.
Volg deze stappen om de node-ID te verkrijgen via het fysieke adres in EUI 64-indeling:
- Splits het fysieke (MAC) adres in tweeën in twee groepen van 24 bits.
- Voeg het FFFE (16-bits) hexadecimale getal toe tussen deze twee groepen bits.
- Keer de waarde van het zevende bit om van links naar rechts van het getal gevormd door de tweede stap.
IPv6-adressen worden meestal geschreven als acht groepen van 4 hexadecimale cijfers. Bijvoorbeeld,2001:0db8:85a3:08d3:1319:8a2e:0370:7344
Voor het gemak van schrijven kunnen voorloopnullen en reeksen nullen worden afgekort. Bijvoorbeeld,2001:0db8:85a3:03fa:0000:0000:0000:7344
is hetzelfde IPv6-adres als in het vorige voorbeeld:2001:db8:85a3:3fa::7344
Er zijn speciale soorten adressen in IPv6:
- unicast – elk adres komt overeen met een interface (apparaat).
- multicast – elk adres komt overeen met meerdere interfaces. Er wordt een kopie naar elke interface gestuurd.
- anycast – komt overeen met meerdere interfaces die een gemeenschappelijk voorvoegsel delen. Er wordt een datagram naar een van de apparaten gestuurd, bijvoorbeeld het dichtstbijzijnde.
In tegenstelling tot IPv4 heeft IPv6 geen broadcast-adres, dat verantwoordelijk is voor het doorsturen van een pakket naar alle nodes in hetzelfde domein.
Met IPv6 moeten alle LAN’s /64-prefixen hebben. Dit is vereist om automatische configuratie en andere functionaliteit te laten werken.
Gebruikers van elk type zullen /48 netwerken van hun providers ontvangen, dat wil zeggen dat ze een voldoende aantal IP’s tot hun beschikking hebben om ongeveer 65.000 netwerken te configureren, elk met {\displaystyle 2^{64}}adressen (18 triljoen) . Er moet echter worden opgemerkt dat sommige providers overwegen om thuisgebruikers netwerken met een /56-grootte te geven, zodat ze kunnen worden opgedeeld in slechts 256/64-netwerken.
Interface-ID’s (IID)
IPv6-adressen zijn verdeeld over netwerk- en machine-identificatie. Volgens de CIDR-standaard zijn de eerste 64 bits voor het netwerk en de laatste 64 bits voor de machine. Deze laatste zijn de interface identifiers (IID). Op deze manier zijn ze gereserveerde{\displaystyle 2^{64}}(18.445.744.073.709.551.616) machines per netwerk, wat meer dan genoeg is voor de huidige en toekomstige vraag.
Interface-ID’s (IID), die worden gebruikt om interfaces binnen een link te onderscheiden, moeten uniek zijn binnen hetzelfde subnetprefix. Dezelfde IID kan op meerdere interfaces op een enkel knooppunt worden gebruikt, maar ze moeten aan verschillende subnetten zijn gekoppeld.
De IID wordt normaal gesproken gevormd door het fysieke adres van de machine ( MAC ), dus het is niet nodig om DHCPv6 te gebruiken, wat optioneel wordt als de beheerder meer controle over het netwerk wil hebben.
De IID op basis van een 48-bits MAC-adres wordt als volgt gemaakt:
- Voeg eerst de FF-FE hexadecimale cijfers toe tussen de derde en vierde bytes van het MAC-adres (waardoor het een 64-bits adres wordt).
- Vervolgens moet u het zevende bit, van links naar rechts, van het MAC-adres aanvullen (de U/L – Universal/Local bit genoemd), dat wil zeggen, als het 1 is, wordt het omgeschakeld naar 0, en als het is 0, wordt omgeschakeld naar 1.
- Als de interface is gebaseerd op een 64-bits MAC-adres, is de eerste stap niet nodig.
Overgangsadresstructuren
IPv6-adressen kunnen worden toegewezen aan IPv4 en zijn ontworpen voor routers die beide protocollen ondersteunen, waardoor IPv4 door een IPv6-backbone kan “tunnelen”. Deze adressen worden automatisch samengesteld door routers die beide protocollen ondersteunen. Naast elkaar bestaan is mogelijk door tunneling in beide segmenten – IPv6 ingekapseld in IPv4 en IPv4 ingekapseld in IPv6, hoewel de eerste veel gebruikelijker is en afhankelijk is van gratis diensten van “Brokers”. De rol van de “Broker” is precies om de toegangspoort tot de IPv6-wereld te zijn via de IPv4-verbinding. Er zijn enkele veelvoorkomende soorten tunneling, zoals TunTap en 6to4.:
Hiervoor zijn de 128 bits van IPv6 als volgt verdeeld:
- 80-bits veld ingesteld op ‘0’ (nul), 0000:0000:0000:0000:0000 …
- 16-bits veld ingesteld op ‘1’ (één), … FFFF …
- 32 bit IPv4-adres
IPv6-adressen toegewezen aan IPv4:::FFFF:<endereço IPv4>
Andere IPv6-adresstructuren
Er zijn andere IPv6-adresstructuren:
- ISP-adressen – formaat dat is ontworpen om individuele gebruikers van een ISP verbinding te laten maken met internet.
- Site-adressen – voor gebruik op een Local Area Network.
Wereldwijde adoptie van IPv6
Zelfs met de voorspelling en volledige uitputting van IPv4-adressen in verschillende delen van de wereld, vindt de acceptatie van IPv6 op een discrepante manier plaats in de landen van de wereld. Google is slechts een van de bedrijven die voortdurend statistieken verzamelt over de acceptatie van IPv6 op internet, met een grafiek van het percentage gebruikers dat toegang heeft tot Google via IPv6 en een kaart van de acceptatie van het protocol door ouders.
Het land met het grootste aantal Google-gebruikers dat IPv6 heeft aangenomen, is België, waarvan 52% toegang heeft tot het protocol. Akamai, een ander bedrijf dat statistieken levert met betrekking tot IPv6-adoptie, wijst naar India als het land met de hoogste implementatie, met 62,4% van de adoptie. Op beide sites zijn de laagste adoptiepercentages in verschillende landen in het Midden-Oosten, Noord- en West-Afrika, waarvan vele op 0%.
Hoewel de inzet van IPv6 een trend is vanwege de uitputting van IPv4, is het in de meeste landen niet de verplichting van ISP’s om dit internetprotocol te ondersteunen. Wit-Rusland was het eerste land dat een wetgevend standpunt innam en bepaalde dat vanaf 1 januari 2020 alle providers verplicht zouden zijn om het IPv6-protocol te ondersteunen en IPv6-adressen aan al hun klanten te verstrekken. Volgens Google-analyse is het percentage Wit-Russische gebruikers dat op IPv6 vertrouwt om toegang te krijgen tot de site slechts 4,67%.
Momenteel vertrouwen de meeste webservers en datacenters naast IPv6 op IPv4. De trend is echter dat, met de voortdurende toename van het gebruik van het meest recente protocol, wordt gekozen voor het gebruik van alleen dit protocol, waardoor de bedrijfskosten kunnen worden verlaagd, de complexiteit kan worden verminderd en de bedreigingsvectoren kunnen worden geëlimineerd die verband houden met het werken met twee protocollen. . Het Amerikaanse Office of Budget Management (OMB) plant een IPv6-implementatieplan voor het jaar 2021, met als doel dat tegen het einde van 2025 80% van de federale IP-netwerken alleen het IPv6-protocol zullen gebruiken.