IPv6

Van Wikipedia, de gratis encyclopedie
Spring naar navigatie Spring naar zoeken
IPv6 in de TCP / IP-protocolstack :
gebruik maken van HTTP IMAP SMTP DNS ...
vervoer- TCP UDP
internet IPv6
Netwerktoegang Ethernet token
bus
token
ring
FDDI ...

Het Internet Protocol versie 6 ( IPv6 ), voorheen ook wel Internet Protocol Next Generation (IPng) genoemd, is een methode voor de overdracht van gegevens in pakketgeschakelde computernetwerken , met name het internet, gestandaardiseerd door de Internet Engineering Task Force (IETF) sinds 1998. In deze netwerken worden de gegevens verzonden in pakketten waarin, volgens een laagmodel, besturingsinformatie van verschillende netwerkprotocollen wordt verweven en rond de daadwerkelijke gebruikersgegevens wordt verzonden. Als protocol van de netwerklaag (laag 3 van het OSI-model ) creëert IPv6 een 128- bits adressering van de betrokken netwerkelementen ( computers of routers ) die geldig is over subnetten binnen het raamwerk van de internetprotocolfamilie . Het gebruikt deze adressen ook om het proces voor het doorsturen van pakketten tussen subnetwerken ( routing ) te regelen. De subnetwerken kunnen dus worden bediend met verschillende protocollen van de lagere lagen, die rekening houden met hun verschillende fysieke en administratieve omstandigheden.

IPv6 moet op termijn versie 4 van het Internet Protocol op internet volledig vervangen, omdat het een aanzienlijk groter aantal mogelijke adressen biedt die met IPv4 uitgeput dreigen te raken [1] . Critici vrezen dat de anonimiteit op internet zal worden teruggedrongen door de stabielere en uitgebreidere public addressing die nu mogelijk is. [2] Voorstanders bekritiseren de aarzelende introductie van IPv6 gezien de verlopen IPv4-adrestoewijzing in alle continenten behalve Afrika . [3] [4] Toegang tot Google door gebruikers uit Duitsland gebruikten IPv6 tot ongeveer 50% in oktober 2020. [5]

Redenen voor een nieuw internetprotocol

Aantal beschikbare IPv4-adresblokken sinds 1995
Dagelijks toegewezen IPv4-adressen volgens RIR's (Regional Internet Registries)

Theoretisch biedt IPv4 een adresruimte van iets meer dan vier miljard IP-adressen (2 32 = 256 4 = 4.294.967.296), die de IANA opdeelt in 256/8 netwerken, waarvan 221 [6] grotendeels worden vrijgegeven voor gebruik, bijvoorbeeld toegewezen aan RIR's. De resterende 35/8-netwerken waren gereserveerd voor speciale doeleinden (bijvoorbeeld 127/8 voor loopback) of voor de toekomst, waardoor het beschikbare gebied wiskundig wordt teruggebracht tot 3.707.764.736. Nadat echter enkele subgebieden (zoals 100.64.0.0/10) van de /8 netwerken die daadwerkelijk zijn vrijgegeven, zijn gereserveerd voor andere doeleinden, wordt deze inventaris met nog eens 5.506.830 IP-adressen verminderd. B. Het rechtstreeks aanspreken van computers en andere apparaten daalt uiteindelijk naar 3.702.257.906 IP-adressen. [7] In de begindagen van internet , toen er nog maar een paar computers waren die een IP-adres nodig hadden, was dit perfect geschikt. Grotere adresbereiken werden zelfs voorbehouden aan onder meer grote organisaties, waardoor er nog minder vrije adressen overbleven voor particulieren.

In de loop van de tijd is het internet echter steeds wijder geworden en is de wereldbevolking al lang groter dan het aantal beschikbare IPv4-adressen. Daarnaast bezet een website onder meer al permanent één of meerdere adressen. Er was dus een beter systeem nodig dat veel meer adressen zou kunnen bieden zonder technische provisorische aanpassingen. Zie IPv4-adresschaarste voor meer informatie.

Door een kortzichtige allocatiepraktijk is er sprake van sterke fragmentatie in de IPv4-adresruimte. Met IPv6 is echter een meer vooruitziende praktijk gebruikt.

Om deze redenen begon de IETF al in 1995 met werken aan IPv6. In december 1998 werd IPv6 officieel uitgeroepen tot opvolger van IPv4 met de publicatie van RFC 2460 op de Standards Track . In juli 2017 publiceerde de IETF RFC 8200 , die de originele versie vervangt.

De belangrijkste nieuwe functies van IPv6 zijn onder meer:

De belangrijkste motivatie voor het vergroten van de adresruimte is het handhaven van het end-to-end-principe [10] , een centraal ontwerpprincipe van internet: [11] Alleen de eindknooppunten van het netwerk moeten actieve protocolbewerkingen uitvoeren, de netwerk is tussen de eindknooppunten alleen verantwoordelijk voor het doorsturen van de datapakketten. (Het internet verschilt hier aanzienlijk van andere digitale datatransmissienetwerken zoals GSM .) Hiervoor is het noodzakelijk dat elk netwerkknooppunt wereldwijd uniek kan worden geadresseerd. [10]

Veelgebruikte methoden van vandaag, zoals Network Address Translation (NAT), die momenteel het tekort aan IPv4-adressen omzeilen, schenden het end-to-end-principe. [12] Ze stellen alleen de computers die op deze manier zijn aangesloten in staat om uitgaande verbindingen tot stand te brengen. Aan de andere kant zijn ze niet gemakkelijk te bereiken via internet. IPsec of protocollen zijn ook afhankelijk van hogere lagen zoals: B. FTP en SIP deels volgens het end-to-end principe en zijn slechts beperkt functioneel met NAT of met aanvullende oplossingen. [13]

Vooral voor thuisgebruikers betekent IPv6 een paradigmaverschuiving: in plaats van een enkel IP-adres door de provider toegewezen te krijgen en meerdere apparaten via NAT met internet te verbinden, wordt de wereldwijd unieke IP-adresruimte beschikbaar gesteld voor een heel subnet, zodat elk van zijn Apparaten kan hiervan een IP-adres verkrijgen. Dit maakt het voor eindgebruikers gemakkelijker om actief deel te nemen aan het netwerk door diensten aan te bieden. Bovendien worden de problemen die zich voordoen met NAT als gevolg van het herschrijven van adressen geëlimineerd.

Bij het kiezen van de adreslengte en daarmee de grootte van de beschikbare adresruimte moest met verschillende factoren rekening worden gehouden. Enerzijds moeten voor elk datapakket ook het bron- en bestemmings-IP-adres worden verzonden. Langere IP-adressen leiden dus tot hogere protocoloverhead, dwz de verhouding tussen de werkelijke gebruikersgegevens en de protocolgegevens die nodig zijn voor de overdracht neemt af. [14] Anderzijds moet rekening worden gehouden met de toekomstige groei van internet. Om versnippering van de adresruimte te voorkomen, zou het daarnaast mogelijk moeten zijn om slechts één keer adresruimte aan een organisatie toe te wijzen. Om het eenvoudiger automatische configuratie proces als opnieuw te nummeren en multihoming , was het ook gewenst een vast deel van het adres voor het netwerk-onafhankelijke, unieke identificatie van een netwerkknooppunt reserveren. De laatste 64 bits van het adres bestaan ​​dus meestal uit de EUI-64 van de netwerkinterface van de node.

Adresstructuur van IPv6

IPv6-adressen zijn 128 bits lang (IPv4: 32 bits). De eerste 64 bits vormen het zogenaamde voorvoegsel , de laatste 64 bits vormen in bepaalde gevallen een voor de netwerkinterface ( Engelse netwerkinterface) unieke interface-ID . Een netwerkinterface is onder meerdere IP-adressen te bereiken; dit wordt meestal gedaan door middel van het link-local adres en een globaal uniek adres . Dezelfde interface-identifier kan dus deel uitmaken van meerdere IPv6-adressen die met verschillende prefixen aan dezelfde netwerkinterface zijn gekoppeld. Dit geldt in het bijzonder ook voor voorvoegsels die van verschillende internetproviders kunnen zijn; dit vereenvoudigt het multihoming- proces.

Omdat het genereren van de interface-identifier van het wereldwijd unieke MAC-adres het mogelijk maakt om gebruikers te volgen, zijn de privacy-extensies (PEX, RFC 4941 ) ontwikkeld om deze permanente koppeling tussen de gebruikersidentiteit en de IPv6-adressen te verwijderen. Door de interface-ID willekeurig te genereren en regelmatig te wijzigen, moet een deel van de anonimiteit van IPv4 worden hersteld.

Omdat in de privésector in het IPv6-adres echter zowel de interface-ID als het voorvoegsel alleen een gebruiker veilig kunnen identificeren. B. Een dagelijks wisselend voorvoegsel is wenselijk. (Een statische adrestoewijzing gaat meestal gepaard met een vermelding in de openbare Whois- database.) Zoals hierboven beschreven, is het in principe mogelijk om zowel IPv6-adressen van dynamische als permanent toegewezen prefixen parallel op dezelfde netwerkinterface te gebruiken. In Duitsland heeft de Duitse IPv6-raad richtlijnen voor gegevensbescherming opgesteld die ook voorzien in de dynamische toewijzing van IPv6-prefixen. [15]

Adresnotatie

De tekstuele notatie van IPv6-adressen wordt beschreven in paragraaf 2.2 van RFC 4291 :

  1. IPv6-adressen worden meestal genoteerd in hexadecimaal (IPv4: decimaal ), waarbij het nummer is verdeeld in acht blokken van elk 16 bits (4 hexadecimale cijfers). Deze blokken worden genoteerd, gescheiden door dubbele punten (IPv4: dots): 2001:0db8:85a3:08d3:1319:8a2e:0370:7344 .
  2. Voorloopnullen binnen een blok kunnen worden weggelaten: 2001:0db8:0000:08d3:0000:8a2e:0070:7344 is gelijk aan 2001:db8:0:8d3:0:8a2e:70:7344 .
  3. Een of meer opeenvolgende blokken met een waarde van 0 (of 0000 ) kunnen worden weggelaten. Dit wordt aangegeven door twee opeenvolgende dubbele punten: 2001:db8:0:0:0:0:1428:57ab komt overeen met 2001:db8::1428:57ab . [16]
  4. De reductie door regel 3 mag slechts één keer worden uitgevoerd, dat wil zeggen dat er maximaal één aaneengesloten groep van nulblokken in het adres mag worden vervangen. Het adres 2001:0db8:0:0:8d3:0:0:0 kan daarom ofwel worden afgekort tot 2001:db8:0:0:8d3:: ofwel 2001:db8::8d3:0:0:0 ; 2001:db8::8d3:: is niet toegestaan ​​omdat dit dubbelzinnig is en ten onrechte z. B. kan ook worden geïnterpreteerd als 2001:db8:0:0:0:8d3:0:0 . De reductie mag niet meerdere keren worden uitgevoerd, ook al zou het resultaat ondubbelzinnig zijn, omdat telkens precies één enkele 0 werd ingekort. Het is raadzaam om de groep met de meeste nul blokken in te korten.
  5. De conventionele decimale notatie met punten als scheidingstekens kan ook worden gebruikt voor de laatste twee blokken (vier bytes , d.w.z. 32 bits) van het adres. Dus ::ffff:127.0.0.1 een alternatieve notatie voor ::ffff:7f00:1 . Deze notatie wordt voornamelijk gebruikt wanneer de IPv4-adresruimte is ingebed in de IPv6-adresruimte.

URL-notatie van IPv6-adressen

In een URL staat het IPv6-adres tussen vierkante haken, [17] e. B .:

  • http://[2001:0db8:85a3:08d3::0370:7344]/

Deze notatie voorkomt een verkeerde interpretatie van poortnummers als onderdeel van het IPv6-adres:

  • http://[2001:0db8:85a3:08d3::0370:7344]:8080/

Netwerknotatie

IPv6-netwerken worden geschreven in CIDR- notatie. Hiervoor worden het eerste adres (of het netwerkadres) en de lengte van de prefix in bits genoteerd, gescheiden door een schuine streep. Bijvoorbeeld 2001:0db8:1234::/48 voor het netwerk met de adressen 2001:0db8:1234:0000:0000:0000:0000:0000 tot 2001:0db8:1234:ffff:ffff:ffff:ffff:ffff . De grootte van een IPv6-netwerk (of subnet) in termen van het aantal toewijsbare adressen in dit netwerk moet daarom een ​​macht van twee zijn. Omdat een enkele host ook kan worden gezien als een netwerk met een 128-bits prefix, worden hostadressen soms geschreven met een toegevoegd "/ 128".

Verdeling van de IPv6-adresruimte

Adrestoewijzing

Gewoonlijk ontvangt een internetprovider (ISP) de eerste 32 bits (of minder) als een netwerk van een regionaal internetregister (RIR). [18] Dit gebied wordt door de provider verder onderverdeeld in subnetten . De lengte van de toewijzing aan eindklanten wordt overgelaten aan de ISP; de minimale toewijzing van een / 64 netwerk is vereist. [19] Oudere documenten (bijv. RFC 3177 ) suggereren een toewijzing van / 48 netwerken aan eindklanten; In uitzonderlijke gevallen kunnen netwerken groter dan / 48 of meerdere / 48 netwerken worden toegewezen aan een eindklant. [20] Informatie over de toewijzing van IPv6-netwerken kan worden verkregen bij de Whois- diensten van de respectieve RIR's. In hun rpsL databases er inet6num en route6 voorwerpen en in vele andere objectkenmerken voor multi-protocolextensiepakket (mp) de specificaties van de adresfamilie (afi) voor het specificeren van het nieuwe protocol.

Een 64-bits lange prefix wordt meestal toegewezen aan een individueel netwerksegment , dat vervolgens het adres vormt samen met een 64-bit lange interface-ID. [21] De interface-identificatie kan ofwel worden gemaakt op basis van het MAC-adres van de netwerkinterface of op een andere manier uniek worden toegewezen; de exacte procedure is beschreven in RFC 4291 , Bijlage A.

Heeft z. B. een netwerkapparaat het IPv6-adres

2001:0db8: 85a3: 08 d3: 1319:8a2e:0370:7347 /64 ,

dat is het voorvoegsel

2001: 0db8: 85a3: 08d3 :: / 64

en de interface-ID

1319: 8a2e: 0370: 7347 .

De provider heeft het netwerk waarschijnlijk van de RIR . gekregen

2001: 0db8 :: / 32

toegewezen en de eindklant van de provider eventueel het netwerk

2001: 0db8: 85a3 :: / 48 ,

of gewoon

2001: 0db8: 85a3: 0800 :: / 56 .

Adresbereiken

Er zijn verschillende IPv6-adresbereiken met speciale taken en verschillende eigenschappen. Deze worden meestal al gesignaleerd door de eerste bits van het adres. Tenzij anders aangegeven, zijn de gebieden gedefinieerd in RFC 4291 en RFC 5156 . Unicast- adressen kenmerken de communicatie tussen een netwerkknooppunt en precies één ander netwerkknooppunt; Een-op-veel-communicatie wordt in kaart gebracht met behulp van multicast- adressen.

Speciale adressen

  • ::/128 of in de geschreven variant 0:0:0:0:0:0:0:0/128 , is het niet-gespecificeerde adres. Het mag niet aan een host worden toegewezen, maar geeft de afwezigheid van een adres aan. Het wordt bijvoorbeeld gebruikt door een initialiserende host als afzenderadres in IPv6-pakketten, zolang deze nog geen eigen adres heeft ontvangen. [22] Door dit adres op te geven, kunnen serverprogramma's er echter ook voor zorgen dat ze naar alle adressen van de host luisteren. Dit komt overeen met 0.0.0.0 /32 onder IPv4.
  • ::/0 of in de geschreven variant 0:0:0:0:0:0:0:0/0 geeft de standaardroute (standaardroute) aan die wordt gebruikt als er geen vermelding in de routeringstabel wordt gevonden. Dit komt overeen met 0.0.0.0/0 onder IPv4.
  • ::1/128 of in de geschreven variant 0:0:0:0:0:0:0:1/128 , is het adres van je eigen locatie ( loopback- adres, dat meestal is gekoppeld aan localhost ). Onder IPv4 wordt 127.0.0.1/32 uit de adresruimte 127.0.0.0–127.255.255.255 bijna uitsluitend voor dit doel gebruikt, hoewel niet alleen een IP-adres maar een heel / 8-subnet is gereserveerd voor het loopback-netwerk.

Link-lokale unicast-adressen

Link-local-adressen [23] zijn alleen geldig binnen gesloten netwerksegmenten. Een netwerksegment is een lokaal netwerk, gevormd met switches of hubs , tot aan de eerste router. fe80::/10 gebied " fe80::/10 " gereserveerd. [24] [25] Deze 10 bits worden gevolgd door 54 bits met de waarde 0, zodat de link-local adressen altijd het voorvoegsel " fe80::/64 " hebben:

10 bits 54 bits 64 bits
111111010 0 Interface-ID

Link-local-adressen worden gebruikt om knooppunten in gesloten netwerksegmenten te adresseren, maar ook voor automatische configuratie of detectie van buren. Dit betekent dat het niet nodig is om een ​​DHCP-server te configureren voor automatische adrestoewijzing in een netwerksegment. Link-local-adressen zijn vergelijkbaar met APIPA- adressen in het 169.254.0.0/16 .

Als een apparaat via een van deze adressen moet communiceren, moet ook de Zone-ID worden opgegeven, omdat een link-local adres meer dan één keer op een apparaat kan voorkomen. Met een enkele netwerkinterface ziet een adres er ongeveer zo uit: fe80::7645:6de2:ff:1 %1 of fe80::7645:6de2:ff:1 %eth0 .

Site Lokale Unicast (verouderd)

fec0::/10 ( fec0… tot feff… ), ook lokale adressen van de site , waren de opvolgers van de privé IP-adressen (bijvoorbeeld 192.168.xx ). Ze mochten alleen binnen dezelfde organisatie worden gerouteerd. De keuze van de gebruikte fec0::/10 binnen fec0::/10 was arbitrair voor een organisatie. Bij het samenvoegen van voorheen afzonderlijke organisaties of bij het tot stand brengen van een VPN-verbinding tussen feitelijk afzonderlijke netwerken genummerd met Site Local Addresses, zouden de adresruimten op de verschillende locaties elkaar dus kunnen overlappen. Om deze en andere redenen zijn de lokale adressen van de site volgens RFC 3879 sinds september 2004 verouderd en zullen ze uit toekomstige standaarden verdwijnen. Nieuwe implementaties moeten dit adresbereik behandelen als een globaal unicast-adres. De opvolger van de site-local-adressen zijn de Unique Local Addresses , die in de volgende sectie worden beschreven.

Unieke lokale unicast

fc00::/7 ( fc00… naar fdff… ). Voor privé-adressen zijn er de Unique Local Addresses (ULA), beschreven in RFC 4193 . Momenteel is alleen het voorvoegsel fd bedoeld voor lokaal gegenereerde ULA's. Het voorvoegsel fc is gereserveerd voor globaal toegewezen, unieke ULA's. Het voorvoegsel wordt dan gevolgd door 40 bits, die fungeren als een unieke site-ID. Deze site-ID moet willekeurig worden gegenereerd met de ULA met het voorvoegsel fd [26] en is daarom zeer waarschijnlijk uniek. In het geval van de globaal toegewezen ULA is deze echter absoluut uniek ( RFC 4193 specificeert geen concrete implementatie van de toewijzing van globaal unieke site-ID's). De site-ID wordt gevolgd door een 16-bits subnet-ID, die een netwerk binnen de site aangeeft.

Een voorbeeld ULA is fd9e:21a7:a92c:2323::1 . Hier is fd het voorvoegsel voor lokaal gegenereerde ULA's, 9e:21a7:a92c een eenmalige, willekeurig gegenereerde 40-bits waarde en 2323 een willekeurig geselecteerde subnet-ID.

Het gebruik van waarschijnlijk unieke site-ID's heeft het voordeel dat, bijvoorbeeld bij het opzetten van een tunnel tussen afzonderlijk geconfigureerde netwerken, adresbotsingen zeer onwaarschijnlijk zijn. Bovendien wordt bereikt dat pakketten die naar een onbereikbare site worden gestuurd, zeer waarschijnlijk tevergeefs zijn in plaats van naar een lokale host te worden gestuurd die toevallig hetzelfde adres heeft.

Als alleen ULA-adressen worden gebruikt in een dual-stack met IPv4 in een particulier netwerk, geeft de meerderheid van de klanten de voorkeur aan het IPv4-adres met een DNS-resolutie, zelfs als er een AAAA-record bestaat, aangezien kan worden aangenomen dat met een ULA-adres het openbare IPv6-adres adresruimte kan nooit worden bereikt. In de praktijk betekent dit dat in private netwerken (vooral bij gebruik van NAT6) in de dual stack, ULA-adressen niet worden aanbevolen. [27]

Er is een internetconcept dat richtlijnen beschrijft voor registrars (IANA, RIR), met name hun werking en regels voor adrestoewijzing. Zo'n "ULA-Centraal" is er echter nog niet. [28]

Zowel RFC 4193 als de Internet Draft zijn identiek wat betreft het adresformaat en het hierboven genoemde generatie-algoritme.

Multicast

ff00::/8 ( ff… ) staat voor multicast-adressen. Het multicast-voorvoegsel wordt gevolgd door 4 bits voor vlaggen en 4 bits voor de scope.

De volgende combinaties zijn momenteel geldig voor de vlaggen: [29]

  • 0 : Permanent gedefinieerde, bekende multicast-adressen (toegekend door de IANA ) [30]
  • 1 : (T-bit set) Tijdelijk (tijdelijk) of dynamisch toegewezen multicast-adressen
  • 3 : (P bit set, forceert de T bit) Unicast prefix-gebaseerde multicast adressen ( RFC 3306 )
  • 7 : (R bit set, forceert P en T bit) Multicast adressen die het adres van het rendez-vous punt bevatten ( RFC 3956 )

De volgende geldigheidsgebieden zijn gedefinieerd: [29]

  • 1 : interface-local, deze pakketten verlaten de interface nooit. ( Loopback )
  • 2 : link-local, worden nooit door routers doorgestuurd en kunnen daarom het subnet niet verlaten.
  • 4 : admin local, het kleinste gebied waarvan de afbakening speciaal in de routers moet worden beheerd.
  • 5 : sitelocal, kan worden gerouteerd, maar niet door grensrouters .
  • 8 : lokaal bij de organisatie, de pakketten mogen ook door border routers worden doorgestuurd, maar blijven “in the company” (het routeringsprotocol moet hiervoor gepaste voorzorgsmaatregelen nemen).
  • e : globale multicast die overal kan worden gerouteerd.
  • 0 , 3 , f : gereserveerde gebieden
  • de overige gebieden zijn niet toegewezen en kunnen door beheerders worden gebruikt om verdere multicast-regio's te definiëren. [31]

Voorbeelden van bekende multicast-adressen: [32]

  • ff01::1 , ff02::1 : Alle Nodes- adressen. Komt overeen met de uitzending.
  • ff01::2 , ff02::2 , ff05::2 : Alle routers adressen, adressen alle routers in één gebied.

Wereldwijde unicast

Alle andere adressen worden beschouwd als globale unicast- adressen. Hiervan zijn echter tot nu toe alleen de volgende gebieden toegewezen:

  • ::/96 (96 0 bits) stond voor IPv4-compatibiliteitsadressen, die het IPv4-adres in de laatste 32 bits bevatten (dit gold alleen voor globale IPv4-unicast-adressen). Deze werden gedefinieerd voor de overgang, maar verouderd verklaard in RFC 4291 van februari 2006.
  • 0:0:0:0:0:ffff::/96 (80 0 bits, gevolgd door 16 1 bits) staat voor IPv4 toegewezen (weergegeven) IPv6-adressen. De laatste 32 bits bevatten het IPv4-adres. Een geschikte router kan deze pakketten omzetten tussen IPv4 en IPv6 en zo de nieuwe met de oude verbinden.
  • 2000::/3 ( 2000… tot 3fff… ; wat overeenkomt met het binaire voorvoegsel 001) staat voor de globale unicast-adressen die zijn toegewezen door de IANA , d.w.z. routeerbare en globaal unieke adressen.
  • 2001 adressen worden gegeven aan providers die ze aan hun klanten distribueren.
  • Adressen uit 2001::/32 (vanaf 2001:0: worden gebruikt voor het Teredo- tunnelmechanisme.
  • Adressen uit 2001:db8::/32 worden gebruikt voor documentatiedoeleinden, zoals in dit artikel, en duiden niet op daadwerkelijke netwerkdeelnemers.
  • 2002 prefixen geven adressen aan van het 6to4- tunnelmechanisme.
  • 2c0 beginnen met 2003 , 240 , 260 , 261 , 262 , 280 , 2a0 , 2b0 en 2c0 worden ook toegewezen door Regional Internet Registries (RIR's); deze adresbereiken zijn z. In sommige gevallen echter nog niet toegewezen aan het aandeel, zoals het geval is met 2001::/16 . [33]
  • 3ffe::/16 adressen werden gebruikt voor het 6Bone testnetwerk ; dit adresbereik is teruggestuurd naar de IANA in overeenstemming met RFC 3701 .
  • 64:ff9b::/96 kan worden gebruikt voor het vertaalmechanisme NAT64 volgens RFC 6146 .

Functionaliteit

Automatische configuratie

Met behulp van Stateless Address Autoconfiguration (SLAAC, gespecificeerd in RFC 4862 ), kan een host automatisch een werkende internetverbinding opzetten. Hiervoor communiceert hij met de routers die verantwoordelijk zijn voor zijn netwerksegment om de noodzakelijke configuratie te bepalen.

volgorde

Voor de eerste communicatie met de router wijst de host zichzelf een link-local-adres toe , dat bij een Ethernet- interface bijvoorbeeld uit zijn hardware-adres kan worden berekend. Hierdoor kan een apparaat routers in zijn netwerksegment zoeken met behulp van het Neighbor Discovery Protocol (NDP, zie ook ICMPv6-functionaliteit ). Dit doet u door een request te sturen naar het multicast adres ff02::2 , via welke alle routers in een segment bereikbaar zijn ( router solicitation ).

Als reactie op een dergelijk verzoek stuurt een router informatie over beschikbare prefixen , d.w.z. informatie over de adresbereiken van waaruit een apparaat unicast- adressen aan zichzelf mag toewijzen. De pakketten die deze informatie bevatten, worden routeradvertenties genoemd. Ze hebben ICMPv6 type 134 (0x86) en hebben informatie over de levensduur, de MTU en de prefix van het netwerk. De host voegt de interface-identifier die ook wordt gebruikt voor het link-local-adres toe aan een dergelijk voorvoegsel.

Het mechanisme Duplicate Address Detection (DAD - herkenning van dubbel toegewezen adressen) is voorzien om te voorkomen dat een adres twee keer wordt toegewezen. [34] Een apparaat mag alleen niet-toegewezen adressen selecteren tijdens automatische configuratie. Het DAD-proces verloopt ook zonder tussenkomst van de gebruiker via NDP.

Geldigheidsinformatie

Routers kunnen beperkte geldigheidstijden specificeren bij het toewijzen van adresvoorvoegsels: Geldige levensduur en Voorkeurslevensduur . [35] Het gespecificeerde voorvoegsel mag worden gebruikt voor communicatie binnen de geldige levensduur; Binnen de Voorkeurslevensduur moet dit voorvoegsel de voorkeur krijgen boven een ander voorvoegsel waarvan de Voorkeurslevensduur al is verlopen (maar waarvan de Geldige Levensduur nog niet is verstreken). [36] Routers sturen regelmatig routeradvertenties naar alle hosts in een netwerksegment waarvoor ze verantwoordelijk zijn, waarmee de geldigheidstijden van de prefix worden ververst; Door de advertenties te wijzigen, kunnen hosts worden hernummerd. Als de router-advertenties niet worden geverifieerd via IPsec, is het niet mogelijk om de geldigheidsduur van een voorvoegsel dat al bekend is bij een host te verminderen tot minder dan twee uur. [37]

Relatie tussen automatische configuratie en DHCPv6

De automatische configuratie van IPv6 verschilt conceptueel van DHCP of DHCPv6 . Terwijl de adrestoewijzing door DHCPv6 (gedefinieerd in RFC 3315 ) wordt aangeduid als " Stateful Address Configuration" (analoog: gelogde adrestoewijzing, bijvoorbeeld door een DHCP-server), is de autoconfiguratie een " Stateless Address (Auto) Configuration" , aangezien de apparaten zelf een adres toewijzen en deze toewijzing niet wordt gelogd.

Met behulp van de automatische configuratie kan geen informatie over hostnamen, domeinnamen, DNS, NTP- servers, enz. aan clients worden gecommuniceerd, tenzij ze specifieke NDP-extensies ondersteunen. Het extra gebruik van een DHCPv6-server heeft zich als alternatief bewezen; deze geeft de benodigde aanvullende informatie, maar zorgt niet voor de adrestoewijzing. In dit geval spreekt men van stateless DHCPv6 (zie RFC 3736 ). De beheerde vlag in het antwoord op een NDP-routerverzoek kan worden gebruikt om aan de client aan te geven dat deze een DHCPv6-verzoek moet doen en zo de aanvullende informatie te verkrijgen.

Hernummeren en multihoming

Onder IPv4 is hernummeren (het wijzigen van het IP-adresbereik) problematisch voor netwerken van een bepaalde grootte, zelfs als mechanismen zoals DHCP helpen. Met name de overgang van de ene aanbieder naar de andere zonder een "harde" omschakeling op een vast tijdstip is moeilijk, omdat dit alleen mogelijk is als het netwerk voor een bepaalde tijd multihomed is, d.w.z. een netwerk van meer dan één provider met tegelijkertijd internettoegang Verbindings- en IP-adresbereiken worden geleverd. Het omzeilen van hernummering onder IPv4 met behulp van het Border Gateway Protocol (BGP) leidt tot fragmentatie van de adresruimte. Zoveel, relatief kleine netwerken komen in de routeringstabellen in het kerngebied van internet terecht en de routers daar moeten dienovereenkomstig worden ontworpen.

Der Vorgang der Umnummerierung wurde beim Design von IPv6 hingegen berücksichtigt, er wird in RFC 4076 behandelt. Mechanismen wie die IPv6-Autokonfiguration helfen dabei. Der parallele Betrieb mehrerer IP-Adressbereiche gestaltet sich unter IPv6 ebenfalls einfacher als unter IPv4, wie im Abschnitt Adressaufbau oben beschrieben. In RFC 3484 wird festgelegt, wie die Auswahl der Quell- und Zieladressen bei der Kommunikation geschehen soll und wie sie beeinflusst werden kann, wenn nun jeweils mehrere zur Verfügung stehen. Darüber hinaus darf diese Auswahl auch auf Anwendungsebene oder durch noch zu schaffende, z. B. die Verbindungsqualität einbeziehende Mechanismen getroffen werden. Das Ziel ist unter anderem, dem Betreiber eines Netzwerkes den unkomplizierten Wechsel zwischen Providern oder gar den dauerhaften Parallelbetrieb mehrerer Provider zu ermöglichen, um damit den Wettbewerb zu fördern, die Ausfallsicherheit zu erhöhen oder den Datenverkehr auf Leitungen mehrerer Anbieter zu verteilen.

Mobile IPv6

Mobile IP wurde als Erweiterung des IPv6-Standards unter dem Namen „Mobile IPv6“ ( RFC 6275 ) in IPv6 integriert. Die Kommunikation erfolgt dabei virtuell immer unabhängig von der aktuellen Position der Knotenpunkte. [38] Somit erlaubt Mobile IP Endgeräten, überall unter der gleichen IP-Adresse erreichbar zu sein, beispielsweise im heimischen Netzwerk und auf einer Konferenz. Normalerweise müssten dazu aufwändig Routing-Tabellen geändert werden. Mobile IPv6 benutzt stattdessen einen Schatten-Rechner („ Home Agent “), der das Mobilgerät in seinem Heimnetz vertritt. Eingehende Pakete werden durch diesen Schattenrechner an die momentane Adresse („Care-of-Address“) des Mobilgeräts getunnelt. Der Home Agent bekommt die aktuelle Care-of-Address des Mobilgerätes durch „Binding Updates“ mitgeteilt, die das Gerät an den Home Agent sendet, sobald es eine neue Adresse im besuchten Fremdnetz erhalten hat. Mobile IP ist auch für IPv4 spezifiziert; im Gegensatz zu dieser Spezifikation benötigt Mobile IPv6 jedoch keinen Foreign Agent , der im Fremdnetz die Anwesenheit von Mobilgeräten registriert.

Header-Format

Der Kopfdatenbereich eines IPv6-Paketes

Im Gegensatz zu IPv4 hat der IP-Kopfdatenbereich ( Header ) bei IPv6 eine feste Länge von 40 Bytes (320 Bits). Optionale, seltener benutzte Informationen werden in so genannten Erweiterungs-Kopfdaten (engl.: Extension Headers ) zwischen dem IPv6-Kopfdatenbereich und der eigentlichen Nutzlast (engl. Payload ) eingebettet. Der Kopfdatenbereich eines IPv6-Paketes setzt sich laut RFC 2460 aus den folgenden Feldern zusammen:

Feld Länge Inhalt
Version 4 Bit IP-Versionsnummer (6)
Traffic Class 8 Bit Quality of Service : Die Bits 0–5 werden für DSCP verwendet, die Bits 6–7 für ECN . Laut IANA gilt die gleiche Zuteilung wie für IPv4 ToS .
Flow Label 20 Bit Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.
Payload Length 16 Bit Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte
Next Header 8 Bit Identifiziert den Typ des nächsten Kopfdatenbereiches , dieser kann entweder einen Erweiterungs-Kopfdatenbereich (siehe nächste Tabelle) oder ein Protokoll höherer Schicht (engl.: Upper Layer Protocol ) bezeichnen, wie z. B. TCP (Typ 6) oder UDP (Typ 17).
Hop Limit 8 Bit Maximale Anzahl an Zwischenschritten über Router, die ein Paket zurücklegen darf; wird beim Durchlaufen eines Routers („Hops“) um eins verringert. Pakete mit null als Hop Limit werden verworfen. Es entspricht dem Feld Time to Live (TTL) bei IPv4.
Source Address 128 Bit Adresse des Senders
Destination Address 128 Bit Adresse des Empfängers

Wie im Next Header Feld verwiesen, sind einige Extension Headers und ein Platzhalter definiert:

Name Typ Größe Beschreibung RFCs
Hop-By-Hop Options 0 variabel Enthält Optionen, die von allen IPv6-Geräten, die das Paket durchläuft, beachtet werden müssen. Wird z. B. für Jumbograms benutzt. RFC 2460 , RFC 2675
Routing 43 variabel Durch diesen Header kann der Weg des Paketes durch das Netzwerk beeinflusst werden, er wird unter anderem für Mobile IPv6 verwendet. RFC 2460 , RFC 6275 , RFC 5095
Fragment 44 64 Bit In diesem Header können die Parameter einer Fragmentierung festgelegt werden. RFC 2460
Authentication Header (AH) 51 variabel Enthält Daten, welche die Vertraulichkeit des Paketes sicherstellen können (siehe IPsec ). RFC 4302
Encapsulating Security Payload (ESP) 50 variabel Enthält Daten zur Verschlüsselung des Paketes (siehe IPsec ). RFC 4303
Destination Options 60 variabel Enthält Optionen, die nur vom Zielrechner des Paketes beachtet werden müssen. RFC 2460
Mobility 135 variabel Enthält Daten für Mobile IPv6 . RFC 6275
No Next Header 59 leer Dieser Typ ist nur ein Platzhalter, um das Ende eines Header-Stapels anzuzeigen. RFC 2460

Die meisten IPv6-Pakete sollten ohne Extension Headers auskommen, diese können bis auf den Destination Options Header nur einmal in jedem Paket vorkommen. Befindet sich nämlich ein Routing Extension Header im Paket, so darf davor ein weiterer Destination Options Header stehen. Die Reihenfolge bei einer Verkettung ist bis auf die genannte Ausnahme die der Tabelle. Alle Extension Headers enthalten ein Next-Header -Feld, in dem der nächste Extension Header oder das Upper Layer Protocol genannt wird.

Die Größen dieser Header sind immer Vielfache von 64 Bit, auch sind die meisten Felder der Kopfdatenbereiche auf 64-Bit-Grenzen ausgerichtet, um Speicherzugriffe im Router zu beschleunigen. Außerdem werden (im Gegensatz zu IPv4 ) keine Prüfsummen mehr über die IP-Kopfdaten berechnet, es wird nur noch die Fehlerkorrektur in den Schichten 2 und 4 genutzt.

Paketgrößen

Die Maximum Transmission Unit (MTU) darf in einem IPv6-Netzwerk 1280 Byte nicht unterschreiten. Somit unterschreitet auch die Path MTU (PMTU) diesen Wert nicht und es können Pakete bis zu dieser Größe garantiert ohne Fragmentierung übertragen werden. Minimale IPv6-Implementierungen verlassen sich auf diesen Fall.

Ein IPv6-fähiger Rechner muss in der Lage sein, aus Fragmenten wieder zusammengesetzte Pakete mit einer Größe von mindestens 1500 Byte zu empfangen. Für IPv4 beträgt dieser Wert nur 576 Byte. Im anderen Extrem darf ein IPv6-Paket auch fragmentiert laut Payload-Length -Feld im IPv6-Header die Größe von 65.575 Byte einschließlich Kopfdaten nicht überschreiten, da dieses Feld 16 Bit lang ist (2 16 − 1 Bytes zzgl. 40 Bytes Kopfdaten). RFC 2675 stellt aber über eine Option des Hop-by-Hop Extension Headers die Möglichkeit zur Verfügung, Pakete mit Größen bis zu 4.294.967.335 Byte, sogenannte Jumbograms zu erzeugen. Dies erfordert allerdings Anpassungen in Protokollen höherer Schichten, wie z. B. TCP oder UDP , da diese oft auch nur 16 Bit für Größenfelder definieren, außerdem muss bei jedem Paket, welches einen Jumbogram beinhaltet, im IPv6-Header die Payload-Length auf 0 gesetzt werden.

Erweiterte ICMP-Funktionalität

ICMPv6 ( Protokolltyp 58 ) stellt für das Funktionieren von IPv6 unverzichtbare Funktionen zur Verfügung. Das Verbieten aller ICMPv6-Pakete in einem IPv6-Netzwerk durch Filter ist daher im Normalfall nicht durchführbar.

Insbesondere wird das Address Resolution Protocol (ARP) durch das Neighbor Discovery Protocol (NDP) ersetzt, welches auf ICMPv6 basiert. Dieses macht hierbei intensiv Gebrauch von Link-Local-Unicast-Adressen und Multicast , das von jedem Host beherrscht werden muss. Im Rahmen des NDPs werden auch die automatische Adressvergabe und die automatische Zuordnung einer oder mehrerer Default-Routen über ICMPv6 abgewickelt, so stellt es die meisten Funktionen zur Verfügung, die oben unter IPv6-Autokonfiguration erklärt wurden. NDP kann auf die Möglichkeit weiterer Konfiguration durch DHCPv6 verweisen, welches allerdings UDP -Pakete benutzt.

Die Fragmentierung überlanger IPv6-Pakete erfolgt nicht mehr durch die Router , der Absender wird stattdessen mit Hilfe von ICMPv6-Nachrichten aufgefordert, kleinere Pakete, auch unter Zuhilfenahme des Fragment Extension Headers , zu schicken (siehe in diesem Zusammenhang Maximum Transmission Unit (MTU)). Idealerweise sollte ein IPv6-Host, bzw. eine Anwendung vor dem Versenden einer großen Anzahl von IPv6-Paketen eine Path MTU Discovery gemäß RFC 1981 durchführen, um Pakete mit maximal möglicher Größe verschicken zu können.

IPv6 und DNS

Wegen der Länge der IP-Adressen, die an das menschliche Erinnerungsvermögen höhere Anforderungen stellt als IPv4-Adressen, ist IPv6 in besonderem Maße von einem funktionierenden Domain Name System (DNS) abhängig. RFC 3596 definiert den Resource Record (RR) Typ AAAA (sprich: Quad-A ), der genau wie ein A Resource Record für IPv4 einen Namen in eine IPv6-Adresse auflöst. Der Reverse Lookup , also die Auflösung einer IP-Adresse in einen Namen, funktioniert nach wie vor über den RR-Typ PTR , nur ist für IPv6 die Reverse Domain nicht mehr IN-ADDR.ARPA wie für IPv4, sondern IP6.ARPA und die Delegation von Subdomains darin geschieht nicht mehr an 8-Bit-, sondern an 4-Bit-Grenzen.

Ein IPv6-fähiger Rechner sucht in der Regel mittels DNS zu einem Namen zunächst nach dem RR-Typ AAAA, dann nach dem RR-Typ A. Laut der Default Policy Table in RFC 3484 wird die Kommunikation über IPv6 gegenüber IPv4 bevorzugt, falls festgestellt wird, dass für eine Verbindung beide Protokolle zur Verfügung stehen. Die Anwendungsreihenfolge der Protokolle ist meistens aber auch im Betriebssystem und auf der Anwendungsebene, also z. B. im Browser , einstellbar.

Alle dreizehn Root-Nameserver und mindestens zwei Nameserver der meisten Top-Level-Domains sind über IPv6 erreichbar. Das übertragende Protokoll ist unabhängig von den übertragenen Informationen. Insbesondere kann man über IPv4 einen Nameserver nach AAAA-RRs fragen. Anbieter großer Portalseiten denken jedoch darüber nach, nur DNS-Anfragen, die über IPv6 gestellt werden, auch mit AAAA Resource Records zu beantworten, um Probleme mit fehlerhaft programmierter Software zu vermeiden. [39]

Übergangsmechanismen

IPv6-Übergangsmechanismen
4in6 Tunneling von IPv4 in IPv6
6in4 Tunneling von IPv6 in IPv4
6over4 Transport von IPv6- Datenpaketen zwischen Dual-Stack Knoten über ein IPv4- Netzwerk
6to4 Transport von IPv6-Datenpaketen über ein IPv4-Netzwerk (veraltet)
AYIYA Anything In Anything
Dual-Stack Netzknoten mit IPv4 und IPv6 im Parallelbetrieb
Dual-Stack Lite (DS-Lite) Wie Dual-Stack, jedoch mit globaler IPv6 und Carrier-NAT IPv4
6rd IPv6 rapid deployment
ISATAP Intra-Site Automatic Tunnel Addressing Protocol (veraltet)
Teredo Kapselung von IPv6-Datenpaketen in IPv4- UDP -Datenpaketen
NAT64 Übersetzung von IPv4-Adressen in IPv6-Adressen
464XLAT Übersetzung von IPv4- in IPv6- in IPv4-Adressen
SIIT Stateless IP/ICMP Translation

IPv4 und IPv6 lassen sich auf derselben Infrastruktur, insbesondere im Internet , parallel betreiben. Für den Übergang werden also in der Regel keine neuen Leitungen, Netzwerkkarten oder Geräte benötigt, sofern dafür geeignete Betriebssysteme zur Verfügung stehen. Es gibt zurzeit kaum Geräte, welche IPv6, aber nicht gleichzeitig auch IPv4 beherrschen. Damit jedoch Geräte, die ausschließlich über IPv4 angebunden sind, auch mit Geräten kommunizieren können, die ausschließlich über IPv6 angebunden sind, benötigen sie Übersetzungsverfahren .

Um einen einfachen Übergang von IPv4- zu IPv6-Kommunikation im Internet zu ermöglichen, wurden verschiedene Mechanismen entwickelt. IPv6 wird dabei in der Regel hinzugeschaltet, ohne IPv4 abzuschalten. Grundlegend werden folgende drei Mechanismen unterschieden:

  • Parallelbetrieb ( Dual-Stack )
  • Tunnelmechanismen
  • Übersetzungsverfahren

Parallelbetrieb und Tunnelmechanismen setzten voraus, dass die Betriebssysteme der angebundenen Rechner beide Protokolle beherrschen.

Es gibt bereits heute Bereiche des Internets, die ausschließlich mittels IPv6 erreichbar sind, andere Teile, die über beide Protokolle angebunden sind und große Teile, die sich ausschließlich auf IPv4 verlassen. Im Folgenden werden die ersten beiden Bereiche zusammen als IPv6-Internet bezeichnet.

Dual-Stack

Bei diesem Verfahren werden allen beteiligten Schnittstellen neben der IPv4-Adresse zusätzlich mindestens eine IPv6-Adresse und den Rechnern die notwendigen Routinginformationen zugewiesen. Die Rechner können dann über beide Protokolle unabhängig kommunizieren, dh sowohl mit IPv4- als auch mit IPv6-fähigen Systemen Daten austauschen. Dieses Verfahren sollte der Regelfall sein, es scheitert derzeit oft daran, dass einige Router (meistens die Zugangsserver des Internetproviders oder die Heimrouter bei den Kunden) auf dem Weg zum IPv6-Internet noch keine IPv6- Weiterleitung eingeschaltet haben oder unterstützen.

Dual-Stack Lite (DS-Lite)

DS-Lite

Aufgrund der knappen IPv4-Adressen hat die IETF den Mechanismus „Dual-Stack Lite“ ( RFC 6333 ) entwickelt. Hierbei werden dem Kunden nur via IPv6 global routbare IP-Adressen bereitgestellt. (Im regulären Dual-Stack-Betrieb werden sowohl IPv6 als auch IPv4 zur Verfügung gestellt.)

Im LAN des Kunden werden private IPv4-Adressen benutzt (analog zum Vorgehen beiNAT ). Statt einer NAT-Übersetzung werden die IPv4-Pakete dann durch das Customer Premises Equipment (CPE) in IPv6-Pakete gekapselt . Das CPE benutzt seine globale IPv6-Verbindung, um die Pakete in das Carrier-grade NAT (CGN) des Internet Service Providers zu transportieren, welches über globale IPv4-Adressen verfügt. Hier wird das IPv6-Paket entpackt und das originale IPv4-Paket wiederhergestellt. Danach wird das IPv4-Paket mit NAT auf eine öffentliche IP-Adresse umgesetzt und ins öffentliche IPv4-Internet geroutet. Das Carrier-grade NAT identifiziert Sitzungen eindeutig mittels Aufzeichnungen über die öffentliche IPv6-Adresse des CPEs, die private IPv4-Adresse und TCP- oder UDP-Portnummern.

Diese DS-Lite-Umsetzung führt allerdings beim Endkunden zu Problemen: Zum einen sind bei portbasierten Protokollen (z. B. TCP, UDP) keine IPv4-basierenden Portfreigaben mehr möglich, da die Pakete an die öffentliche IP-Adresse bereits beim Provider ausgefiltert werden. Dienste, die an einem DS-Lite-Anschluss angeboten werden, können also von Geräten, die keine IPv6-Verbindungen aufbauen können, nicht erreicht werden. Auch werden vom CGN-Gateway nur bestimmte Protokolle verstanden und weitergeleitet, was die Nutzung anderer IP-basierter Protokolle erschwert oder völlig unmöglich macht.

Tunnelmechanismen

Protokoll 41: IPv6-Pakete werden direkt in IPv4-Pakete gepackt, die dann zu einem speziellen Tunnelserver geschickt werden

Um Router, die IPv6 nicht weiterleiten, auf dem Weg zum IPv6-Internet zu überbrücken, gibt es eine Vielzahl von Tunnelmechanismen . Dabei werden IPv6-Pakete in den Nutzdaten anderer Protokolle, meist IPv4, zu einer Tunnelgegenstelle übertragen, die sich im IPv6-Internet befindet. Dort werden die IPv6-Pakete herausgelöst und zum Ziel via IPv6-Routing übertragen. Der Rückweg funktioniert analog. Jedes Tunnelverfahren ist abhängig von der Qualität des tunnelnden Protokolls: der Weg der Pakete zum Ziel ist wegen des Umwegs über die Tunnelgegenstelle meistens nicht optimal und die mögliche Nutzlast sinkt, da mehr Kopfdaten übertragen werden müssen.

Der klassische Weg ist es, bei einem so genannten Tunnelbroker eine solche Gegenstelle für den privaten Gebrauch gebührenfrei zu beantragen. Diese Gegenstelle bleibt fest, und man bekommt über den Tunnel immer den gleichen IPv6-Adressbereich zugewiesen. 6in4 benutzt zum Beispiel den Protokolltyp 41 , um IPv6 direkt in IPv4 zu kapseln. Für Linux ist die Erstellung eines solchen Tunnels mit den Interface -Konfigurationswerkzeugen möglich. [40] Bei Windows ist dies seit Windows 10 April 2018 (1803) nicht mehr möglich. Komplizierter sind die Verfahren 6over4 oder ISATAP .

Der Mechanismus 6to4 benötigt keine Absprache mit einer Gegenstelle, denn diese benutzt im Internet definierte ( Anycast )-IPv4-Adressen, und die getunnelten Pakete werden zur nächstgelegenen Gegenstelle zugestellt und dort verarbeitet. Dem angebundenen Rechner steht dann ein IPv6-Adressbereich zur Verfügung, der sich aus dessen öffentlicher IPv4-Adresse errechnet. Auch ein solcher Tunnel kann auf aktuellen Linux-Rechnern mit öffentlicher IPv4-Adresse durch wenige Handgriffe eingerichtet werden. [41]

Befindet sich ein Rechner in einem privaten IPv4-Adressbereich und findet beim Verbinden mit dem InternetNAT statt, so können Mechanismen wie AYIYA oder Teredo helfen. Diese Protokolle kapseln IPv6-Pakete als Nutzdaten meist in UDP -Paketen. Erlaubt ein Administrator diese Protokolle, kann schnell die Netzwerksicherheit in Gefahr geraten, wenn der Paketfilter die Nutzdaten nicht als IPv6-Pakete interpretieren kann und somit eventuell andere Paketfilterregeln umgangen werden.

Es ist auch möglich, IPv6 über allgemeinere Tunnelverfahren wie GRE , L2TP oder MPLS zu transportieren, insbesondere, wenn noch Routingprotokolle wie IS-IS parallel übertragen werden müssen.

Übersetzungsverfahren

Kann auf einem Gerät IPv6 nicht aktiviert werden oder stehen nicht mehr genügend IPv4-Adressen zur Verfügung, können Verfahren wie Network Address Translation/Protocol Translation (NAT-PT, RFC 2766 ; inzwischen missbilligt [42] ), oder Transport Relay Translation (TRT, RFC 3142 ) nötig werden, um zwischen beiden Protokollen zu übersetzen. Auch bieten Proxy-Server für einige Protokolle höherer Schichten die Möglichkeit einer Kommunikation zwischen beiden Welten. [43]

Das Verfahren NAT64 bietet eine recht befriedigende Lösung, solange die Hauptanforderung darin besteht, von IPv6-Hosts initiierte Verbindungen an IPv4-Hosts weiterzuleiten.

Technische Umsetzung

Die RFC 6434 (IPv6 Node Requirements) gibt einen Überblick über Funktionen, die alle IPv6-Geräte umsetzen sollten, um eine maximale Interoperabilität zu gewährleisten. In diesem Dokument wird auf die jeweiligen Spezifikationen verwiesen.

Betriebssysteme

Viele Betriebssysteme unterstützen inzwischen IPv6, ein Überblick folgt. Entscheidend für eine tunnelfreie Anbindung ist aber auch die Unterstützung durch die Firmware , bzw. die Betriebssysteme, auf den (DSL-) Routern bei Endkunden und den Zugangsservern bei den Providern. Systeme (z. B. CDN ) zur Lastverteilung , wie sie z. B. für große Webseiten eingesetzt werden, wurden und werden stückweise um IPv6 ergänzt. [44] [45] [46] [47]

AIX
Seit AIX 4 Version 4.3 ist IPv6 implementiert, seit AIX 5L Version 5.2 ist auch Mobile IPv6 implementiert.
Android
Android unterstützt IPv6 seit Version 2.1, jedoch nicht über die 3GPP -Schnittstelle. [48] Seit 2.3.4 werden IPv6 APN unterstützt. Es fehlte allerdings bei den meisten Endgeräten die Unterstützung im UMTS Chipset (bzw. der Firmware). Ab Version 4.0 Ice Cream Sandwich sind Privacy Extensions standardmäßig aktiviert. [49]
BSD-Varianten
IPv6 wird von den BSDs bereits sehr lange und sehr umfassend unterstützt (zum Beispiel bei FreeBSD seit März 2000, bei NetBSD seit Dezember 2000 und bei OpenBSD seit Mitte 2000). Die Unterstützung ist zu großen Teilen dem KAME-Projekt zu verdanken, das seit 1998 einen freien Protokollstapel für IPv6 und IPsec für BSD-Betriebssysteme entwickelt hatte.
Cisco
IPv6 wird ab IOS Version 12.2T experimentell, ab den Versionen 12.3 und 12.4 produktiv unterstützt. Auf älteren Geräten und Karten ist das IPv6-Forwarding aufgrund der Hardwareausstattung jedoch nur in Software, also mit Hilfe des Hauptprozessors möglich, was die Leistung gegenüber IPv4 deutlich vermindert.
HP-UX
Seit der Version 11iv2 ist IPv6 Bestandteil des Basissystems, frühere 11.x-Versionen können mit TOUR (Transport Optional Upgrade Release) IPv6-fähig gemacht werden.
iOS (Apple iPhone, iPad, iPod Touch, Apple TV)
Apple-Geräte mit iOS ab Version 4 unterstützen IPv6 im Dual-Stack-Modus. [50] Privacy Extensions werden jedoch erst ab Version 4.3 unterstützt. [51] [52]
Juniper
Der Hersteller unterstützt IPv6 auf seinen Routern im Betriebssystem JunOS ab Version 5.1. Das IPv6-Forwarding geschah hier schon früh in Hardware, also ohne die Routing Engine (den Hauptprozessor) zu belasten. Für Firewall-Systeme, sowohl auf der ScreenOS Serie(ScreenOS <6.x), als auch auf der SRX Serie(JunOS <10.x) ist IPv6 unterstützt.
Linux
Der Kernel bietet seit Version 2.6 eine produktiv einsetzbare IPv6-Unterstützung auf ähnlichem Niveau wie die BSD-Derivate. Der Kernel 2.4 bietet eine als experimentell ausgewiesene Unterstützung für IPv6, der jedoch noch wichtige Eigenschaften wie IPSec und Datenschutzerweiterungen (Privacy Extensions, RFC 4941 ) fehlen. Die meisten Linux-Distributionen haben im Auslieferungszustand mit Kerneln ab Version 3.x die Privacy Extensions eingeschaltet, diese können jedoch manuell deaktiviert werden. Eine experimentelle IPv6-Implementation ist auch in der Kernel-Version 2.2 enthalten.
Mac OS X
Seit Version 10.2 enthält auch Mac OS X Unterstützung für IPv6 auf der Basis von KAME . Erst seit Version 10.3 lässt sich IPv6 auch über die GUI konfigurieren. IPv6 ist standardmäßig aktiviert und unterstützt DNS-AAAA-Records. Die zur Apple-Produktfamilie gehörenden Airport-Extreme -Consumer-Router richten standardmäßig einen 6to4 -Tunnel ein und fungieren als IPv6-Router. Die Privacy Extensions sind seit 10.7 (Lion) per Default aktiviert.
OpenVMS
Mit HP TCP/IP Services for OpenVMS Version 5.5 unterstützt HP OpenVMS (ab Version 8.2) IPv6.
Solaris
Seit der Version 8 ist die Unterstützung von IPv6 auch in dem Betriebssystem der Firma Sun Microsystems in begrenzter Form enthalten (die Implementierung und große Teile der Betriebssystemapplikationen erfordern immer noch, dass IPv4 konfiguriert ist), das für SPARC- und i386-Rechnerarchitekturen zur Verfügung steht. Die Konfiguration erfolgt analog zu den Linux- und xBSD-Systemen.
Symbian OS
Seit der Version 7.0 ist IPv6 fester Bestandteil des Systems. Es sind nur wenige Parameter über die GUI zu konfigurieren.
Windows
Seit Windows XP Service Pack 1 bringt Windows einen Protokollstapel für IPv6 mit. Die Unterstützung für IPv6 ist seither durch Microsoft stetig ausgebaut und aktuellen Entwicklungen angepasst worden. Seit Windows 8 wird IPv6 als bevorzugtes Protokoll verwendet, falls der Host an ein Dual-Stack-Netzwerk angeschlossen ist. [53]
Windows Server
Seit Windows Server 2003 enthält Windows Server einen „Production-Quality“-Protokollstapel. Die Unterstützung für IPv6 ist in den seither erschienenen Versionen von Windows Server kontinuierlich von Microsoft ausgebaut worden.
Windows Phone
Windows Phone 7 und 7.5 unterstützen IPv6 nicht. Erst ab Version 8 ist ein IPv6-Stack integriert. [54]
z/OS
IBM z/OS unterstützt IPv6 seit September 2002 vollständig, schon 1998 gab es für den Vorgänger OS/390 einen experimentellen Stack.

Routing

Während statisches Routing für IPv6 analog zu IPv4 eingerichtet werden kann, ergeben sich für die dynamischen Routingprotokolle einige Änderungen. Zwischen Autonomen Systemen wird das Border Gateway Protocol mit den Multiprotocol Extensions (definiert in RFC 4760 ) eingesetzt. Als Interior Gateway Protocol stehen OSPF in der Version 3, IS-IS mit Unterstützung von IPv6- TLVs und RIPng als offene Standards zur Verfügung. Die meisten Hersteller unterstützen für IS-IS Multi-Topology Routing , also gleichzeitiges Routing für beide Adressfamilien auch dann, wenn IPv4- und IPv6-Netz sich nicht genau überdecken. OSPFv3 realisiert dieses in einem sehr neuen Standard ( RFC 5838 ) über verschiedene Instanzen für die verschiedenen Protokolle, war ursprünglich aber nur für IPv6 vorgesehen. Ein anderer Weg ist es unterschiedliche Routingprotokolle für die beiden Topologien zu verwenden, also etwa OSPFv2 für IPv4 und IS-IS für IPv6.

An Endsysteme können eine oder mehrere Default-Routen per Autokonfiguration oder DHCPv6 übergeben werden. Mit DHCPv6-PD ( Prefix Delegation ) können auch Präfixe zwecks weiteren Routings zum Beispiel an Kundenrouter verteilt werden.

Da weder RSVP noch LDP für IPv6 ausreichend standardisiert sind, [55] [56] müssen sich MPLS -Netze weiter auf die Signalisierung mittels IPv4 verlassen, können jedoch, abhängig von der Implementierung, IPv6-Verkehr transportieren. Für IPv6 Multicast-Routing ist PIM geeignet.

Paketfilter und Firewalls

Für IPv6 müssen alle Filterregeln in Firewalls und Paketfiltern neu erstellt werden. Je nachdem, ob der filternde Prozess den IPv6-Datenverkehr überhaupt verarbeitet und abhängig von ihrer Default-Policy kann eine Firewall IPv6 ungehindert durchlassen. Auch einige Antivirenprogramme haben Zusätze, welche den Verkehr z. B. auf bestimmten TCP -Ports nach Signaturen durchsuchen. Für Linux kann die Filterung von IPv6 mit dem Programm ip6tables (seit Version 3.13 des Linux-Kernels auch nft / nftables ) konfiguriert werden.

Deutliche Veränderungen in der Struktur der Filter gegenüber IPv4 können sich ergeben, sofern sie ICMP bzw. ICMPv6 behandeln, da sich dessen Protokollnummer , Type- und Code -Zuordnungen sowie die Funktionalität verändern. [57]

Das Feld Next Header im IPv6-Header eignet sich nicht in gleicher Weise wie das Protocol -Feld im IPv4-Header zum Identifizieren von Protokollen höherer Schicht, denn im Falle der Verwendung von Extension Headers verändert sich dessen Wert, beispielsweise bei Fragmentierung.

Einige Aspekte von NAT wurden in der Vergangenheit oft als Sicherheitsfunktion verstanden; NAT ist in IPv6 jedoch höchstens in Ausnahmefällen vorgesehen. RFC 4864 beschreibt Vorgehensweisen, welche diese Aspekte von NAT mit IPv6-Techniken abbilden; [58] so kann etwa die bei einigen Implementierungen bestehende Funktion von NAT, neu eingehende Verbindungen nicht an Rechner des Heimnetzes weiterzuleiten, durch einen zustandsbehafteten Paketfilter im Router ersetzt werden. Dieser kann nach Wunsch neu eingehende Verbindungen generell abweisen oder diese nur für bestimmte Bereiche des Heimnetzes zulassen.

Anwendungssoftware

Für Anwendungen wie Webbrowser oder E-Mail-Programme sind Änderungen in der Programmierung notwendig, damit sie über IPv6 kommunizieren können. Dies ist für die wichtigsten Programme, die mit aktuellen Betriebssystemen ausgeliefert werden, bereits geschehen, nicht aber bei weniger häufig benutzten Anwendungen. [59] [60]

In den meisten Fällen sind nur kleinere Änderungen notwendig, da die Anwendungen auf Protokolle höherer Schicht aufsetzen und diese sich kaum ändern. In vielen Betriebssystemen forderten die Programmierschnittstellen jedoch von der Anwendung, Sockets explizit zur IPv4-Kommunikation anzufordern. Neuere Schnittstellen sind in der Regel so gestaltet, dass IPv6-unterstützende Anwendungen automatisch auch IPv4 unterstützen. Verarbeiten die Anwendungen Inhalte mit URLs , wie sie in HTTP oder im Session Initiation Protocol (SIP) vorkommen, so müssen sie die URL-Notation von IPv6-Adressen unterstützen.

Zum Teil sind Änderungen notwendig, um die Leistung der Anwendung nicht zu mindern: So muss z. B. eine eventuell ermittelte, verminderte Path MTU an die Anwendung übergeben werden, um Fragmentierung zu vermeiden oder die Maximum Segment Size (MSS) im TCP -Header muss bei IPv6 gegenüber IPv4 verringert werden. Viele Programmiersprachen stellen spezielle Bibliotheken zur Verfügung, um den Umgang mit dem neuen Protokoll zu vereinfachen.

Administration

Die Hauptarbeit der Umsetzung liegt auf der Verwaltungsebene: Administration und Support müssen geschult, Dokumentationen und Konfigurationen, z. B. für Routing , Firewalls , Netzwerküberwachung , das Domain Name System und evtl. DHCP , müssen während der Übergangsphase für beide Protokolle erstellt und gepflegt werden. In vielen Dokumentationen oder Fehlermeldungen muss im Nachhinein zwischen IPv4 und IPv6 unterschieden werden, wo noch vor einigen Jahren nur von IP die Rede war. Die Struktur des IP-Netzes wird zunächst quasi verdoppelt.

Oft haben IP-Adressen eine Bedeutung auf höherer Ebene. So tauchen sie in Logdateien oder Netflow -Daten auf, die teilweise mit Skripten wie beispielsweise Webalizer weiterverarbeitet werden, um Ansichten, Statistiken oder Abrechnungen zu erzeugen. Auch das Layout und die Skripte zur Erzeugung von Seiten wie Wikipedias „Versionsgeschichte“ mussten an die IPv6-Notation angepasst werden, da hier Nutzer zum Teil mit ihrer IP-Adresse identifiziert werden. Basiert eine Rechteverwaltung, wie z. B. in vielen Datenbanken, auf dem Zugriff durch festgelegte IP-Adressen, muss dies beim Zuschalten von IPv6 berücksichtigt werden.

Verbreitung und Projekte

Anzahl der Autonomen Systeme mit publizierten IPv6-Routen und Anzahl der publizierten Präfixe seit 2003
Anzahl der neuen Zuweisungen von IPv6-Adressraum an ISPs seit 2000

IPv6 setzt sich im praktischen Einsatz nur langsam durch. Die Adressvergabe für IPv6 ist im Juli 1999 vom experimentellen in den Regelbetrieb übergegangen [61] und immer mehr ISPs betreiben neben IPv4 auch IPv6 in ihrem Netz.

Über den Internetknoten AMS-IX werden zu Spitzenzeiten 150 GBit/s IPv6-Traffic transportiert, [62] das sind etwa 3 % des dort anfallenden Gesamtverkehrs von 5 TBit/s. [63] Auf Webseiten im Dual-Stack Betrieb werden weltweit 27 % der Zugriffe über IPv6 gemessen, [64] für Zugriffe aus Deutschland liegt der IPv6-Anteil bei 46 %. [5]

Die globale IPv6-Routingtabelle umfasste im Oktober 2016 etwa 33000 Präfixe, [65] und ungefähr 26 % aller im Internet verfügbaren Autonomen Systeme beteiligen sich am globalen IPv6-Routing. [66] Die meisten der großen Austauschpunkte für Internetverkehr erlauben und fördern neben IPv4 auch den Austausch von IPv6 über ihre Infrastruktur. Beim DE-CIX nutzten im April 2008 etwa 70 bis 80 von insgesamt 240 Providern IPv6. [67]

Das IPv6 Forum [68] wurde im Juli 1999, der Deutsche IPv6 Rat im Dezember 2007 gegründet. Das IPv6 Forum Projekt IPv6-Ready [69] vergibt das IPv6-Logo in drei verschiedenen Stufen, die die Implementierung des Protokolls messen. Die Webseite listet dazu auch alle IPv6-fähigen Betriebssysteme auf.

Derzeit sind 74 % aller IPv4-Adressen den nordamerikanischen Internet Registries und einigen US-amerikanischen Institutionen und Unternehmen direkt zugewiesen, während beispielsweise ganz China – mit inzwischen über 250 Millionen Internet-Benutzern (Stand: Juni 2008 [70] ) – vor Jahren noch nur über etwa so viele IP-Adressen verfügte wie ein Campus der University of California (Dezember 2004). [71]

Von Seiten der Endbenutzer wird IPv6 auch deshalb nicht gefordert, weil außer dem größeren Adressbereich die wesentlichen neuen Eigenschaften von IPv6 inzwischen mehr oder weniger erfolgreich nach IPv4 zurückportiert wurden (beispielsweise IPsec , QoS , Multicast ; Umnummerierung und Autokonfiguration sind auch mittels DHCP möglich) – es gibt keine weitverbreitete Anwendung, die nur mit IPv6 funktionieren würde.

Frühe Projekte

In Deutschland federführend bei den Versuchen zu IPv6 war das JOIN-Projekt der Universität Münster. JOIN und der Verein zur Förderung eines Deutschen Forschungsnetzes ( DFN ) haben mit dem „6WiN“ einen ersten IPv6-Backbone in Deutschland aufgebaut. Das 6WiN war ein ringförmiger Backbone durch Deutschland mit Querverbindung zwischen Essen und Berlin. Parallel dazu baute die Deutsche Telekom einen eigenen IPv6-Backbone zwischen den Standorten Darmstadt, Münster und Berlin auf und bot ihren Geschäftskunden im Rahmen eines Showcase-Projektes Anschluss daran an. Dieses Netz war in Münster und Berlin mit dem 6WiN verbunden. Ebenfalls in Münster lag der deutsche zentrale Zugang zum experimentellen IPv6-Netzwerk 6Bone , der am 7. Juni 2005 im Rahmen der planmäßigen sukzessiven Beendigung des weltweiten 6Bone-Betriebs abgeschaltet wurde. Zum 1. Januar 2006 wurde der IPv6-Betrieb im Deutschen Forschungsnetz vom JOIN-Projekt an das DFN-NOC übergeben.

Die Universität Wien , die auch den Vienna Internet Exchange (VIX) [72] und mehrere DNS -Server für die Zone „.at“ betreibt, spielte eine entscheidende Rolle bei der IPv6-Migration in Österreich. Beide Einrichtungen sind über IPv6 erreichbar bzw. bieten akademischen Kunden IPv6-Anbindung an. Der erste kommerzielle Anbieter in Österreich war das Unternehmen next layer .

Anbindung von Endnutzern

Am 8. Juni 2011 fand der sogenannte World IPv6 Day statt, an dem der Dual-Stack-Betrieb auf mehreren großen Webseiten getestet wurde. [73] Der Test verlief weitestgehend problemlos. [74] Am Internetknotenpunkt DE-CIX war ein deutlich erhöhtes IPv6-Verkehrsaufkommen zu messen, das auch nach dem 8. Juni anhielt. [75]

Im Rahmen eines weiteren Aktionstages am 6. Juni 2012, dem World IPv6 Launch Day , haben mehr als 1400 Unternehmen weltweit ihre Webseiten dauerhaft auf den neuesten Standard umgestellt, so dass sie mit IPv4 und IPv6 erreichbar sind. [76] [77]

Seit dem 25. September 2012 leistet die Deutsche Telekom IPv6 auch an DSL-Endkundenanschlüssen. [78] Zunächst wurden erst die sogenannten IP-Anschlüsse IPv6-fähig gemacht, wobei zunächst mit Neukunden begonnen wurde. Die mittlerweile deaktivierten Analog- und ISDN-Anschlüsse erhielten kein IPv6. [79] In der aktuellen Leistungsbeschreibung für die Nutzung von LTE an einer fest vereinbarten Adresse („MagentaZuhause via Funk“ als Alternative zu DSL) stellt die Deutsche Telekom z. B. klar, dass über diesen Internetzugang nur IPv4-Adressen erreichbar sind. [80]

Nutzer weiterer Anschlussarten wie beispielsweise dem Mobilfunknetz [81] oder Kabel [82] werden zunehmend mit IPv6 versorgt.

Probleme

Historisch

Gerade zu Anfang wurden die IPv6-Standards häufig geändert, was dazu führte, dass bereits fertiggestellte Implementierungen mehrfach angepasst werden mussten.

Adressierung der Netzknoten

Der größte Einschnitt bestand in der Einführung der IEEE -Norm EUI-64 für die Interface-Identifier als Teil der Adressen. Um die Einzigartigkeit einer Adresse im Netzwerk auf einfache Weise zu garantieren, wurde vorher die MAC-Adresse einer Schnittstelle unverändert in die IPv6-Adresse übernommen, nun wird die MAC-Adresse gemäß EUI-64 in veränderter Form in die IPv6-Adresse geschrieben; dabei wird aufgrund einer Verwechslung in RFC 3513 der Algorithmus, um EUI-64-Namen aus EUI-48-Namen zu berechnen, fälschlicherweise auf MAC-48-Namen angewandt. [83]

Die beschriebenen Verfahren führen zu einem statischen hostspezifischen Teil der IPv6-Adresse eines autokonfigurierten IPv6-Knotens. Datenschützer waren besorgt, dass auf diese Weise Nutzer über unterschiedliche Netzwerke hinweg identifizierbar werden und dies beispielsweise für Marketingmaßnahmen oder staatliche Interventionen ausgenutzt werden könnte. Die IETF definierte deshalb nachträglich die Datenschutzerweiterungen ( Privacy Extensions ) gemäß RFC 3041 , später RFC 4941 (siehe auch Adressaufbau von IPv6 ). Diese Privacy-Extensions generieren bei der Autokonfiguration via SLAAC einen zufälligen hostspezifischen Teil. Da aber die ersten 64 Bit der IPv6-Adresse eines Netzes (z. B. eines Haushaltes) weiterhin erhalten bleiben, muss ein weiterer Schutz durch regelmäßiges Wechseln des netzspezifischen Teils gewährleistet sein (wie heute bei DSL-Anschlüssen).

Integration ins Domain Name System

Lange Zeit war die DNS-Anpassung zur Eingliederung von IPv6 uneinheitlich. 1995 wurde in RFC 1886 zunächst der Record-Typ AAAA für die Auflösung von DNS-Namen in IPv6-Adressen definiert, der funktional äquivalent zum A-Record für IPv4 ist. Im Jahr 2000 wurde AAAA in RFC 2874 durch den Record-Typ A6 abgelöst, der vor allem das Umnummerieren vereinfachen sollte, indem die IP-Adresse stückweise auf das DNS abgebildet wurde, jedoch nie frei von technischen Problemen war. 2003 wurde das Verfahren A6 daher in RFC 3596 wieder nach „experimentell“ zurückgestuft, und AAAA wurde der neue, alte Standard.

Noch mehr Schwierigkeiten bereitete die Rückwärtsauflösung („Reverse“-Auflösung) von IPv6-Adressen, da es aufgrund der Wechsel der Standards PTR-Records in zwei verschiedenen Zonen gab, unterhalb von ip6.arpa und ip6.int. Aufgrund der traditionellen Nutzung der TLD .arpa für die Rückwärtsauflösung bei IPv4 hat sich die erstere Variante gegen ip6.int durchgesetzt, woraufhin die Delegierung von ip6.int im Juni 2006 gelöscht wurde.

Die Auflösung ist vom Protokolltyp der Anfrage völlig unabhängig: Wird eine DNS-Anfrage über IPv4 gestellt, so kann auch ein AAAA-Record zurückgegeben werden, und über IPv6 erreichbare Nameserver geben auch über IPv4-Adressen (A-Records) Auskunft.

Aktuell

Link-lokale Adressen

Eine mögliche Designschwäche von IPv6 ist, dass die Adressräume für link-lokale Adressen grundsätzlich nicht getrennt sind. Will man link-lokale Adressen also auf Anwendungsebene zur Kommunikation zwischen Rechnern im selben Netzwerksegment verwenden, ergibt sich das Problem, dass es für diese nicht ausreichend ist, die IP-Adresse im Ziel-Feld einzutragen, sondern auch ein Zone Index nach RFC 4007 (in den meisten Fällen ein Interface ) angegeben werden muss, da sich der link-lokale Adressraum mehrerer Interfaces überschneidet. Es hängt daher davon ab, ob die IPv6-Unterstützung der verwendeten Anwendung das Konzept der Zonen-Indizes kennt, ob link-lokale Adressen zu diesem Zweck eingesetzt werden können.

Autokonfiguration und DNS

Im Zusammenspiel des IPv6-Autokonfigurationsmechanismus mit dem Domain Name System ergeben sich bis heute Probleme. Ursprünglich fehlte die Möglichkeit ganz, im Rahmen der Autokonfiguration Netzknoten auch zu verwendende DNS-Server und weitere DNS-bezogene Informationen wie DNS-Suchpfade mitzuteilen, wie das für IPv4 im Rahmen von DHCP üblich ist. Heute bestehen im Wesentlichen zwei Lösungen für das Problem:

  • Mittels des Managed -Flags in Router-Advertisements können Netzknoten angewiesen werden, bei einem DHCPv6 -Server nach weiterer Konfiguration zu fragen. DHCPv6-Server können über die Multicastadressen ff02::1:2 und ff05::1:3 angesprochen werden. Im Gegensatz zu DHCP muss der DHCPv6-Server keine Protokolle über solche Anfragen führen, die Konfiguration kann also weiterhin zustandslos erfolgen.
  • Die NDP-Spezifikation erlaubt die Angabe zusätzlicher Felder in Router Advertisements. Die so genannten RDNSS- ( Recursive DNS Server ) und DNSSL-Erweiterungen ( DNS Search List ) spezifizieren eine Möglichkeit, DNS-Server und DNS-Suchpfade im Rahmen der Router Advertisements zu versenden.

Insbesondere RDNSS und DNSSL sind erst im November 2010 mit Erscheinen von RFC 6106 standardisiert worden.

Die Unterstützung für die obengenannten Lösungen ist unter den verschiedenen Implementierungen uneinheitlich. Beispielsweise unterstützen Microsoft Windows Vista und 7 nur DHCPv6 und für Linux-Systeme sind zwar alle Verfahren verfügbar, jedoch oft von Distributoren nicht vorinstalliert. Mac OS X unterstützt allerdings seit der Version 10.7 (Lion) sowohl DHCPv6 als auch RDNSS.

Datenschutz

Datenschützer bemängeln an IPv6, dass hier jedes mit dem Internet verbundene Gerät eine fixe IP-Adresse bekommen könnte, wodurch alle besuchten Seiten noch Jahre später eruiert und der Besucher identifiziert werden könnte. [84] [85] [86] [87] Technisch kann dies durch die Privacy Extensions erschwert werden.

Bereits 64 Bit große Adressen hätten einen unvorstellbaren Vorrat von weit über 10 19 Adressen dargestellt – eine Milliarde mal 10 Milliarden, quasi eine Milliarde Generationen der Menschheit. Mit den 128 Bit, die man bei IPv6 verwendet, sind es sogar 10 38 . Damit könnte man theoretisch jedem Atom jedes Menschen auf der Welt eine eigene Adresse zuteilen.

Da es so niemals zu einer Verknappung kommen kann, sind technische Vorrichtungen wie bei IPv4 überflüssig geworden, wodurch ein Internetnutzer teilweise alle paar Stunden eine andere IP-Adresse zugewiesen bekam. Bei IPv6 haben Privatpersonen praktisch eine feste IP-Adresse, die für Webtracking ein Segen ist. Jede IPv6-Adresse kann sehr zuverlässig einem Haushalt oder sogar Mobiltelefon zugeordnet werden. Dadurch kann z. B. eine Suchmaschine oder Onlineshop Personen identifizieren und Informationen über sie verknüpfen, ohne sich Zugriff auf fremde Rechnersysteme zu verschaffen. Dies erforderte ursprünglich so genannte „ Tracking Cookies “. Mit genügend Verbreitung von IPv6-Adressen wird dieses Verfahren obsolet.

Um dieses Problem zu umgehen, wollen Datenschützer Internet Service Provider per Gesetz dazu verpflichten, auch unter IPv6 dynamische Adressen anzubieten. [88]

IPv5

Ein Protokoll mit dem Namen IPv5 gibt es nicht. Allerdings hat die IANA die IP-Versionsnummer 5 für das Internet Stream Protocol Version 2 (ST2, definiert in RFC 1819 ) reserviert, das gegenüber IPv4 verbesserte Echtzeitfähigkeiten haben sollte, dessen Entwicklung dann aber aus Kosten-Nutzen-Erwägungen zugunsten von IPv6 und RSVP eingestellt wurde.

Siehe auch

Literatur

Grundlegende Spezifikationen

  • RFC 2460 . – Internet Protocol, Version 6 (IPv6) Specification . (Aktualisiert durch RFC 8200 – im Juli 2017 abgelöst – englisch).
    • RFC 8200 . – Internet Protocol, Version 6 (IPv6) Specification . Juli 2017. (Löst RFC 2460 ab – englisch).
  • RFC 4861 . – Neighbor Discovery for IP version 6 (IPv6) . (englisch).
  • RFC 4862 . – IPv6 Stateless Address Autoconfiguration . (englisch).
  • RFC 4291 . – IP Version 6 Addressing Architecture . (englisch).
  • RFC 5942 . – IPv6 Subnet Model . (englisch).

Sekundärliteratur

  • Reiko Kaps: WAN-Auffahrt – Mit dem IPv6-Netz online gehen . In: c't , Heise, Hannover 2008,6.
  • Silvia Hagen: IPv6. Grundlagen – Funktionalität – Integration . Sunny Edition, Maur 2009, ISBN 978-3-9522942-2-2 .
  • Joseph Davies: Understanding IPv6 . 2. Auflage. Microsoft Press, Redmond 2008, ISBN 978-0-7356-2446-7 (englisch).
  • Anatol Badach: Technik der IP-Netze. TCP/IP incl. IPv6. Funktionsweise, Protokolle und Dienste . Hanser Fachbuch. 2. Auflage. Hanser, München 2007, ISBN 3-446-21935-8 .
  • Mathias Hein: IPv6, Das Migrationshandbuch . Franzis, Point 2003, ISBN 3-7723-7390-9 .
  • Herbert Wiese: Das neue Internetprotokoll IPv6 . Hanser Fachbuch. Hanser, München 2002, ISBN 3-446-21685-5 .
  • Hans P. Dittler: IPv6. Das neue Internet-Protokoll. Technik, Anwendung, Migration. 2. Auflage. Dpunkt, Heidelberg 2002, ISBN 3-89864-149-X .
  • Christian Huitema: IPv6 – die neue Generation . Addison-Wesley, München 2000, ISBN 3-8273-1420-8 .

Weblinks

Commons : IPv6 – Sammlung von Bildern, Videos und Audiodateien

Einzelnachweise

  1. IPv4-Adress-Pool in Nordamerika endgültig erschöpft .
  2. Datenschützer besorgt über IPv6 . Heise.de
  3. AFRINIC .
  4. NRO and OECD Highlight that IPv6 Deployment is Too Slow . Regional Internet Registries, Pressemitteilung.
  5. a b Google per country IPv6 Adoption .
  6. iana.org .
  7. IPv4 – Charts and Explanations | CIDR/EU: siehe Abschnitte IV.–V. .
  8. RFC 6434 Abschnitt 11 (englisch).
  9. IPsec wurde zusätzlich auch für IPv4 spezifiziert, dort ist die Umsetzung aber optional, während sie für IPv6 zunächst in RFC 4294 vorgeschrieben war. Diese Vorschrift wurde aber mit RFC 6434 zurückgenommen.
  10. a b siehe etwa RFC 2775 Abschnitt 5.1 (englisch).
  11. RFC 3724 Abschnitt 2 (englisch).
  12. RFC 2993 Abschnitt 6 (englisch).
  13. Stefan Wintermeyer: Asterisk 1.4 + 1.6 . 1. Auflage. Addison-Wesley, München 2009, Kapitel 8. das-asterisk-buch.de .
  14. Eine Diskussion des Problems findet sich in einem Internet-Draft von W. Eddy: Comparison of IPv4 and IPv6 Header Overhead .
  15. Leitlinien IPv6 und Datenschutz . ( Memento vom 7. Dezember 2012 im Internet Archive ) German IPv6 Council.
  16. S. Kawamura: RFC 5952A Recommendation for IPv6 Address Text Representation . August 2010. Abschnitt 4.2.2 (englisch).
  17. RFC 3986 Abschnitt 3.2.2 (englisch).
  18. IPv6 Address Allocation and Assignment Policy von APNIC , ARIN , RIPE NCC , Abschnitt 4.3.
  19. IPv6 Address Allocation and Assignment Policy , Abschnitt 5.4.1 .
  20. IPv6 Address Allocation and Assignment Policy , Abschnitt 5.4.2 .
  21. RFC 4291 Abschnitt 2.5.4 (englisch).
  22. RFC 4291 Abschnitt 2.5.2 (englisch).
  23. RFC 4291 Abschnitt 2.5.6 (englisch).
  24. IPv6-Adressen. In: heise online. Abgerufen am 9. November 2018 (deutsch).
  25. Internet Protocol Version 6 Address Space. Abgerufen am 9. November 2018 .
  26. Dazu siehe auch das Skript auf kame.net ( Memento vom 1. Juni 2009 im Internet Archive ) (Online-Version: sixxs.net ).
  27. IPv6 Masquerading Router – Why should the ULA prefix be changed? NAT6, openwrt.org
  28. Centrally Assigned Unique Local IPv6 Unicast Addresses ( englisch ) tools.ietf.org. Abgerufen am 10. Mai 2019.
  29. a b RFC 2373 Abschnitt 2.7 (englisch).
  30. RFC 3307 Abschnitt 4.1 (englisch).
  31. RFC 4291 Abschnitt 2.7 (englisch).
  32. Internet Protocol Version 6 Multicast Addresses . IANA.
  33. IPv6 Unicast Address Assignments . IANA.
  34. RFC 2462 Abschnitt 5.4 (englisch).
  35. RFC 2461 Abschnitt 4.6.2 (englisch).
  36. RFC 2462 Abschnitt 4 (englisch).
  37. RFC 4862 Abschnitt 5.5.3 (Punkt e) – englisch).
  38. Herbert Wiese: Das neue Internetprotokoll IPv6 . Hanser Verlag , München 2002. ISBN 3-446-21685-5 , S. 197.
  39. „Hack“ für IPv6-Erreichbarkeit großer Content-Anbieter . heise.de
  40. Peter Bieringer: Linux IPv6 Howto, Kapitel 9.3 .
  41. Peter Bieringer: Linux IPv6 Howto, Abschnitt 9.4 .
  42. RFC 4966 . – Reasons to Move the Network Address Translator – Protocol Translator (NAT-PT) to Historic Status . (englisch).
  43. IPv6-Testbetrieb für heise online – Web-Site per Proxy IPv6-fähig machen .
  44. AKAMAI (PDF)
  45. AWS .
  46. azure .
  47. Cloudflare .
  48. Android Issue 3389: Full IPv6 Android support .
  49. Susanne Kirchhoff: Datenschutz und IPv6: So anonym surfen Sie wirklich. 3. Juni 2014, abgerufen am 29. März 2015 .
  50. Iljitsch van Beijnum: iOS 4 IPv6 ( Memento vom 14. Mai 2012 im Internet Archive ).
  51. iOS 4.3: Apple bessert beim Datenschutz nach . heise Netze.
  52. IPv6: Privacy Extensions einschalten . heise Netze.
  53. Connecting with IPv6 in Windows 8. MSDN Blog, abgerufen am 12. August 2012 (englisch).
  54. IPv6 Support in Microsoft Products and Services. MS TechNet, archiviert vom Original am 22. April 2016 ; abgerufen am 11. September 2013 (englisch).
  55. Vishwas Manral: RSVP-TE IPv6 .
  56. Vishwas Manral: Updates to LDP for IPv6 .
  57. RFC 4890 . (englisch).
  58. IPv6 Local Network Protection with Cisco IOS Routers and Switches . ( Memento vom 8. Juni 2009 im Internet Archive ) Cisco Systems.
  59. Apple erzwingt IPv6-Kompatibilität bei iOS-Apps .
  60. Supporting IPv6-only Networks .
  61. Delegation of IPv6 address space . IANA, Mailinglistenbeitrag vom 14. Juli 1999.
  62. AMS-IX sFlow Statistics .
  63. AMS-IX Traffic Statistics .
  64. Google IPv6 Adoption .
  65. Geoff Huston: AS2 IPv6 BGP Table Data .
  66. RIPE NCC. RIPE .
  67. APA, AP: Internet-Protokoll IPv6 kommt endlich in Bewegung . derstandard.at, 6. Mai 2008.
  68. Website des IPv6 Forums .
  69. Website IPv6ready .
  70. China hat nun weltweit die meisten Internetnutzer . Heise Online, 4. Juli 2008.
  71. Liu Baijia: China launches new generation Internet . In: China Daily , 27. Dezember 2004.
  72. Vienna Internet Exchange .
  73. Offizielle Website des World IPv6 Days .
  74. World IPv6 Day: Viel Aufmerksamkeit und kaum Probleme . heise Netze.
  75. World IPv6 Day: Unerwartete Nachwirkungen . heise Netze.
  76. World IPv6 Launch Day: Inhalteanbieter schalten IPv6 dazu . heise.de, 5. Juni 2012, abgerufen am 6. Juni 2012.
  77. IPv6-Standard: Eine unsichtbare Revolution für das Internet bei welt.de, 5. Juni 2012, abgerufen am 6. Juni 2012.
  78. Twitter-Meldung der Telekom .
  79. Telekom: Kein IPv6 für Verträge mit Analog- und ISDN-Telefonie . heise.de, 6. Dezember 2012.
  80. Leistungsbeschreibung MagentaZuhause via Funk; Stand Februar 2020 ( Memento vom 15. Februar 2020 im Internet Archive ; PDF).
  81. Telekom startet IPv6-Einführung im Mobilfunknetz .
  82. Kabel Deutschland stellt Internetzugänge auf IPv6 um .
  83. Diskussion über EUI-64, EUI-48 und MAC-48 auf der IETF-IPng-Arbeitsgruppen-Mailingliste.
  84. Datenschützer besorgt über IPv6 . Heise.de
  85. IPv6 – Das Internet-Protokoll der nächsten Generation .
  86. IPv6 ( Memento vom 20. Dezember 2013 im Internet Archive ) datenschutzraum.de
  87. IP Adressen werden knapp – IPv6 die Zukunft .
  88. Dynamische Adressvergabe per Gesetz auch unter IPv6 . golem.de