IPv6

IPv6 i TCP / IP-protokollstakken :

applikasjon	HTTP	IMAP	SMTP	DNS	...
transportere	TCP			UDP
Internett	IPv6
Nettverkstilgang	Ethernet	Token buss	Token ring	FDDI	...

The Internet Protocol versjon 6 ( IPv6 ), tidligere også kalt Internet Protocol Next Generation (IPng), er en metode for overføring av data i pakkesvitsjede datanettverk , spesielt internett, standardisert av Internet Engineering Task Force (IETF) siden 1998 . I disse nettverkene sendes dataene i pakker der, ifølge en lagmodell, kontrollinformasjon fra forskjellige nettverksprotokoller er sammenflettet og overført rundt de faktiske brukerdataene . IPv6 er en protokoll for nettverkslaget (lag 3 av OSI-modellen som en del av) Internett-protokollfamilien er gyldig på tvers av subnett over 128- bit - adressering av de deltakende nettverkselementene ( verter eller rutere ) siden. Den bruker også disse adressene for å regulere videresendingsprosessen mellom subnettverk ( ruting ). Delnettverkene kan således drives med forskjellige protokoller for de nedre lagene, som tar hensyn til deres forskjellige fysiske og administrative forhold.

I løpet av tiden, er IPv6 å erstatte versjon 4 av den Internet Protocol på den Internett , som tilbyr et betydelig større antall mulige adresser som truer med å eksos med IPv4. Kritikere frykter at anonymitet på Internett vil bli presset tilbake av den mer stabile og mer omfattende offentlige taler som nå er mulig. Talsmenn kritiserer den nølende innføringen av IPv6 med tanke på utløpet av IPv4-adressetildeling på alle kontinenter unntatt Afrika . Tilgang til Google fra brukere fra Tyskland brukte IPv6 for rundt 50% i oktober 2020.

Årsaker til en ny internettprotokoll

Teoretisk sett tilbyr IPv4 en adresseplass på litt over fire milliarder IP-adresser (2 ³² = 256 ⁴ = ⁴ 294 967 296), som IANA deler inn i 256/8 nettverk, hvorav 221 i stor grad frigjøres for bruk, dvs. tildelt RIR, for eksempel var. De resterende 35/8 nettverkene var reservert for spesielle formål (f.eks. 127/8 for loopback) eller for fremtiden, noe som matematisk reduserer det tilgjengelige området til 3707,764,736. Etter at noen underområder (for eksempel 100.64.0.0/10) av / 8-nettverkene som faktisk er utgitt, er reservert for andre formål, reduseres denne beholdningen med ytterligere 5.506.830 IP-adresser. B. Å adressere datamaskiner og andre enheter direkte, faller til slutt til 3.702.257.906 IP-adresser. I begynnelsen av Internett , da det bare var noen få datamaskiner som trengte en IP-adresse, var dette helt tilstrekkelig. Man hadde til og med større adresser, blant annet. reservert for store organisasjoner, som etterlot enda færre gratis adresser for privatpersoner.

I løpet av tiden ble imidlertid Internett mer og mer utbredt, og verdens befolkning har lenge vært større enn antall tilgjengelige IPv4-adresser. I tillegg har et nettsted blant annet allerede permanent en eller flere adresser. Så det var behov for et bedre system som kunne gi mange flere adresser uten tekniske midlertidige skift. For mer informasjon, se Adresseknapphet på IPv4 .

På grunn av kortsiktig tildelingspraksis er det sterk fragmentering i IPv4-adresserommet . Med IPv6 ble imidlertid en mer fremsynt praksis brukt.

Av disse grunnene begynte IETF arbeidet med IPv6 allerede i 1995. I desember 1998 ble IPv6 offisielt kåret til etterfølgeren til IPv4 med utgivelsen av RFC 2460 på Standards Track . I juli 2017 publiserte IETF RFC 8200 , som erstatter den originale versjonen.

De viktigste nye funksjonene i IPv6 inkluderer:

• Utvidelse av adresseplassen til IPv4 med 2 ³² (≈ 4,3  milliarder = 4,3 · 10 ⁹ ) adresser til 2 ¹²⁸ (≈ 340  sekstitillion = 3,4 · 10 ³⁸ ) adresser for IPv6, dvs. H. Forstørrelse med en faktor på 2 ⁹⁶ (≈ 7,9 · 10 ²⁸ ).
• Forenkling og forbedring av protokollrammeverket ( header data ); dette avlaster rutere for databehandling.
• statsløs automatisk konfigurasjon av IPv6-adresser; Stateful prosesser som DHCP er dermed overflødige i mange applikasjoner når du bruker IPv6
• Mobil IP samt forenkling av nummerering og multihoming
• Implementering av IPsec innenfor IPv6-standarden. Dette muliggjør kryptering og verifisering av ektheten til IP-pakker.
• Støtte av nettverksteknologier som Quality of Service og Multicast

Hovedmotivasjonen for å øke adresseplassen er å opprettholde end-to-end-prinsippet , som er et sentralt designprinsipp på Internett: Bare sluttnodene i nettverket skal utføre aktive protokolloperasjoner, nettverket mellom sluttnodene er bare for videresending av de ansvarlige datapakkene. (Internett her skiller seg betydelig fra andre digitale dataoverføringsnettverk som GSM .) For dette er det nødvendig at hver nettverksnode kan adresseres unikt globalt.

Vanlige metoder i dag, som Network Address Translation (NAT), som for øyeblikket omgår mangelen på IPv4-adresser, bryter med end-to-end-prinsippet. De gjør det bare mulig for datamaskiner som er koblet på denne måten å etablere utgående forbindelser. På den annen side kan de ikke lett kontaktes fra Internett. Stol også IPsec eller protokoller på høyere lag slik. B. FTP og SIP delvis på end-to-end-prinsippet og er bare funksjonelle med NAT i begrenset grad eller med tilleggsløsninger.

Spesielt for hjemmebrukere betyr IPv6 et paradigmeskifte: I stedet for bare å bli tildelt en enkelt IP-adresse av leverandøren og koble flere enheter til Internett via NAT, blir det globalt unike IP-adresserommet gjort tilgjengelig for et helt undernett slik at hver av enhetene kan få en IP-adresse fra dette. Dette gjør det lettere for sluttbrukere å delta aktivt i nettverket ved å tilby tjenester. I tillegg elimineres problemene som oppstår med NAT på grunn av omskriving av adresser.

Ved valg av adresselengde og dermed størrelsen på tilgjengelig adresseplass, måtte flere faktorer tas i betraktning. På den ene siden må kilde- og destinasjons-IP-adressene også overføres for hver datapakke. Lengre IP-adresser fører til økt protokollomkostning, dvs. H. forholdet mellom de faktiske brukerdataene og protokolldataene som kreves for overføringen, reduseres. På den annen side bør den fremtidige veksten av Internett tas i betraktning. I tillegg, for å forhindre fragmentering av adresseområdet, bør det være mulig å bare måtte tildele adresseområdet til en organisasjon en gang. For å forenkle den automatiske konfigurasjonsprosessen samt omnummerering og multihoming , var det også ønskelig å reservere en fast del av adressen for nettverksuavhengig, unik identifikasjon av en nettverksnode. De siste 64 bitene av adressen består derfor vanligvis av EUI-64 i nodenes nettverksgrensesnitt.

Adressestruktur for IPv6

IPv6-adresser er 128  bits lange (IPv4: 32 bits). De første 64 bitene utgjør det såkalte prefikset , de siste 64 bitene utgjør spesielle tilfeller, en for nettverksgrensesnittet ( engelsk nettverksgrensesnitt ) unik grensesnittidentifikator . Et nettverksgrensesnitt kan nås under flere IP-adresser; dette gjøres vanligvis ved hjelp av sin link-lokale adresse og en globalt unik adresse . Den samme grensesnittidentifikatoren kan således være en del av flere IPv6-adresser som er koblet til det samme nettverksgrensesnittet med forskjellige prefikser. Spesielt gjelder dette også prefikser som kan komme fra forskjellige Internett-leverandører; dette forenkler multihoming- prosessen.

Siden genereringen av grensesnittidentifikatoren fra den globalt unike MAC-adressen gjør det mulig å spore brukere , ble personvernutvidelsene (PEX, RFC 4941 ) utviklet for å fjerne denne permanente koblingen mellom brukeridentiteten og IPv6-adressene. Ved å generere grensesnittidentifikatoren tilfeldig og endre den regelmessig, skal en del av anonymiteten til IPv4 gjenopprettes.

Siden i den private sektoren i IPv6-adressen både grensesnittidentifikatoren og prefikset alene trygt kan identifisere en bruker, av hensyn til databeskyttelse i forbindelse med personvernutvidelsene, en dynamisk tildelt av leverandøren, f.eks. B. Et daglig skiftende prefiks er ønskelig. (En statisk adressetildeling ledsages vanligvis av en oppføring i den offentlige Whois- databasen.) Som beskrevet ovenfor er det i utgangspunktet mulig å bruke både IPv6-adresser fra dynamiske og fra permanent tildelte prefikser parallelt på samme nettverksgrensesnitt. I Tyskland har det tyske IPv6-rådet formulert retningslinjer for databeskyttelse som også gir dynamisk tildeling av IPv6-prefikser.

Adressenotering

Tekstnotasjonen av IPv6-adresser er beskrevet i avsnitt 2.2 i RFC 4291 :

1. IPv6-adresser er vanligvis notert i heksadesimal (IPv4: desimal ), med tallet delt inn i åtte blokker med 16 bits hver (4 heksadesimale sifre). Disse blokkene er atskilt med kolon: oppført separat (IPv4-poeng) 2001:0db8:85a3:08d3:1319:8a2e:0370:7344.
2. Ledende nuller i en blokk kan utelates: 2001:0db8:0000:08d3:0000:8a2e:0070:7344er synonymt med 2001:db8:0:8d3:0:8a2e:70:7344.
3. En eller flere påfølgende blokker med verdien 0 (eller 0000 ) kan utelates. Dette er indikert av to påfølgende kolon: 2001:db8:0:0:0:0:1428:57aber synonymt med 2001:db8::1428:57ab.
4. Reduksjonen med regel 3 kan bare utføres en gang, det vil si at maksimalt en sammenhengende gruppe med null blokker kan erstattes i adressen. Adressen 2001:0db8:0:0:8d3:0:0:0kan derfor enten forkortes 2001:db8:0:0:8d3::eller 2001:db8::8d3:0:0:0reduseres; 2001:db8::8d3::er ikke tillatt da dette er tvetydig og feil z. B. kunne også 2001:db8:0:0:0:8d3:0:0tolkes som. Reduksjonen må ikke utføres flere ganger selv om resultatet ville være entydig fordi nøyaktig en enkelt 0 ble forkortet i hvert tilfelle. Det anbefales å forkorte gruppen med flest null blokker.
5. Den konvensjonelle desimalnotasjonen med prikker som separatorer kan også brukes for de to siste blokkene (fire byte , dvs. 32 bit) av adressen. Så er ::ffff:127.0.0.1en alternativ stavemåte for ::ffff:7f00:1. Denne notasjonen brukes hovedsakelig når IPv4-adresseplassen er innebygd i IPv6-adresseplassen.

URL-notering av IPv6-adresser

I en URL er IPv6-adressen lukket i parentes, f.eks. B.:

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

Denne notasjonen forhindrer feil tolkning av portnumre som en del av IPv6-adressen:

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

Nettverksnotasjon

IPv6-nettverk er skrevet i CIDR- notasjon. For å gjøre dette blir den første adressen (eller nettverksadressen) og lengden på prefikset i biter notert, atskilt med en skråstrek. Står 2001:0db8:1234::/48for eksempel for nettverket med adresser 2001:0db8:1234:0000:0000:0000:0000:0000til 2001:0db8:1234:ffff:ffff:ffff:ffff:ffff. Størrelsen på et IPv6-nettverk (eller subnett) når det gjelder antall tildelbare adresser i dette nettverket, må derfor være en kraft på to. Siden en enkelt vert også kan sees på som et nettverk med et 128-biters prefiks, blir vertsadresser noen ganger skrevet med et vedlagt “/ 128”.

Inndeling av IPv6-adresserommet

Adressetildeling

Vanligvis mottar en Internett-leverandør (ISP) de første 32 bitene (eller mindre) som et nettverk fra et Regional Internet Registry (RIR). Dette området er videre delt inn i delnett av leverandøren . Lengden på tildelingen til sluttkunder overlates til ISP; minimumsallokering av et / 64-nettverk kreves. Eldre dokumenter (f.eks. RFC 3177 ) antyder tildeling av / 48 nettverk til sluttkunder; I unntakstilfeller kan nettverk som er større enn / 48 eller flere / 48 nettverk, tildeles en sluttkunde. Informasjon om tildeling av IPv6-nettverk kan fås fra Whois- tjenestene til de respektive RIR-ene. I deres RPSL- databaser er det inet6num og route6-objekter, og i mange andre objekttyper er det attributter for multiprotokollutvidelse (mp) med spesifikasjon av adressefamilien (afi) for å spesifisere den nye protokollen.

Et 64-bits langt prefiks tilordnes vanligvis til et individuelt nettverkssegment , som deretter danner adressen sammen med en 64-bit lang grensesnittidentifikator. Grensesnittidentifikatoren kan enten opprettes fra MAC-adressen til nettverksgrensesnittet eller på annen måte tilordnes unikt; den nøyaktige prosedyren er beskrevet i RFC 4291 , vedlegg A.

Har z. B. en nettverksenhet IPv6-adressen

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

det er prefikset

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

og grensesnittidentifikatoren

1319: 8a2e: 0370: 7347 .

Leverandøren har sannsynligvis fått nettverket fra RIR

2001: 0db8 :: / 32

tildelt og sluttkunden fra leverandøren muligens nettverket

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

eller bare

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

Adresseområder

Det er forskjellige IPv6-adresseområder med spesielle oppgaver og forskjellige egenskaper. Disse er vanligvis allerede signalisert av de første bitene i adressen. Om ikke annet er spesifisert, er områdene definert i RFC 4291 og RFC 5156 . Unicast- adresser karakteriserer kommunikasjon mellom en nettverksnode og nøyaktig en annen nettverksnode; En-til-mange-kommunikasjon kartlegges ved hjelp av multicast- adresser.

Spesielle adresser

• ::/128eller i den skriftlige varianten 0:0:0:0:0:0:0:0/128, er den uspesifiserte adressen. Det må ikke tildeles en vert, men indikerer heller fraværet av en adresse. Den brukes for eksempel av en initialiserende vert som avsenderadresse i IPv6-pakker så lenge den ennå ikke har mottatt sin egen adresse. Men ved å spesifisere denne adressen kan serverprogrammer også få dem til å lytte til alle adressene til verten. Dette tilsvarer 0.0.0.0/32under IPv4.
• ::/0eller i den skriftlige varianten 0:0:0:0:0:0:0:0/0betegner standardruten (standardrute) som brukes hvis ingen oppføring er funnet i rutetabellen. Dette tilsvarer 0.0.0.0/0under IPv4.
• ::1/128eller i den skriftlige varianten 0:0:0:0:0:0:0:1/128, er adressen til din egen plassering ( loopback- adresse, som vanligvis er knyttet til localhost ). For dette formålet brukes IPv4 nesten utelukkende 127.0.0.1/32fra adresseområdet 127.0.0.0–127.255.255.255, selv om ikke bare en IP-adresse, men et helt / 8 undernett er reservert for loopback-nettverket.

Link-lokale unicast-adresser

Link-lokale adresser er bare gyldige innenfor lukkede nettverkssegmenter. Et nettverkssegment er et lokalt nettverk, dannet med brytere eller nav , opp til den første ruteren. Området " fe80::/10" er reservert for dette . Disse 10 bitene blir etterfulgt av 54 bits med verdien 0, slik at de link-lokale adressene alltid har prefikset " fe80::/64":

10 biter	54 bits	64 bits
1111111010	0	Grensesnitt-ID

Link-lokale adresser brukes til å adressere noder i lukkede nettverkssegmenter så vel som for automatisk konfigurering eller nabooppdagelse. Dette betyr at det ikke er behov for å konfigurere en DHCP-server for automatisk adressetildeling i et nettverkssegment. Link-lokale adresser er sammenlignbare med APIPA- adresser i nettverket 169.254.0.0/16.

Hvis en enhet skal kommunisere ved hjelp av en av disse adressene, må også Zone ID spesifiseres, siden en link-lokal adresse kan eksistere mer enn en gang på en enhet. For et enkelt nettverksgrensesnitt vil en adresse se ut slik: eller . fe80::7645:6de2:ff:1%1fe80::7645:6de2:ff:1%eth0

Nettsted Lokal Unicast (utfaset)

fec0::/10( fec0…bis feff…), også lokale adresser , var etterfølgerne til de private IP-adressene (for eksempel 192.168.x.x). De fikk bare rutes innenfor samme organisasjon. Valget av adresserommet som ble brukt i fec0::/10var vilkårlig for en organisasjon. Ved sammenslåing av tidligere separate organisasjoner eller når det ble opprettet en VPN-forbindelse mellom faktisk separate nettverk nummerert med stedslokale adresser, kunne adresseområdene på de forskjellige stedene derfor overlappe hverandre. Av denne og andre grunner er lokale adresser i henhold til RFC 3879 avviklet siden september 2004 og vil forsvinne fra fremtidige standarder. Nye implementeringer må behandle dette adresseområdet som en global unicast-adresse. Etterfølgeren til de stedslokale adressene er de unike lokale adressene , som er beskrevet i neste avsnitt.

Unik lokal unicast

fc00::/7( fc00…til fdff…). For private adresser er det Unique Local Addresses (ULA), beskrevet i RFC 4193 . For øyeblikket er bare prefikset fdfor lokalt generert ULA ment. Prefikset fcer reservert for globalt tildelte, unike ULAer. Prefikset blir deretter fulgt av 40 biter, som fungerer som en unik side-ID. Denne side-ID- en skal genereres tilfeldig med ULA med prefikset fd og er derfor bare veldig sannsynlig å være unik. Når det gjelder den globalt tildelte ULA, er den imidlertid definitivt unik ( RFC 4193 spesifiserer ikke noen konkret implementering av tildelingen av globalt unike ID-er). Nettsted-ID etterfølges av en 16-biters nettverks-ID, som spesifiserer et nettverk på nettstedet.

Et eksempel ULA ville være fd9e:21a7:a92c:2323::1. Her er fdprefikset for lokalt genererte ULAer, 9e:21a7:a92cen unik tilfeldig generert 40-biters verdi og 2323en vilkårlig delnett-ID.

Bruk av sannsynlige unike ID-er for nettet har fordelen at for eksempel når du setter opp en tunnel mellom separat konfigurerte nettverk, er adressekollisjoner svært usannsynlige. Videre oppnås det at pakker som sendes til et nettsted som ikke kan nås, sannsynligvis ender forgjeves i stedet for å bli sendt til en lokal vert som tilfeldigvis har samme adresse.

Hvis bare ULA-adresser brukes i en dobbel stabel med IPv4 i et privat nettverk, foretrekker flertallet av klienter IPv4-adressen med en DNS-oppløsning, selv om det finnes en AAAA-post, siden det kan antas at med en ULA-adresse den offentlige IPv6 adresseområdet kan aldri nås. I praksis betyr dette at i private nettverk (spesielt når du bruker NAT6) i den dobbelte stakken, anbefales ikke ULA-adresser.

Det er et internettutkast som beskriver retningslinjer for registratorer (IANA, RIR), spesielt deres drifts- og adressetildelingsregler. Imidlertid er en slik "ULA-Central" ennå ikke etablert.

Både RFC 4193 og Internet Draft er identiske med hensyn til adresseformat og generasjonsalgoritmen nevnt ovenfor.

Multicast

ff00::/8( ff…) står for multicast-adresser. Multicast-prefikset følges av 4 bits for flagg og 4 bits for omfanget.

Følgende kombinasjoner er for tiden gyldige for flaggene:

• 0: Permanent definerte, kjente multicast-adresser (tildelt av IANA )
• 1: (T-bit sett) Forbigående (midlertidig) eller dynamisk tilordnede multicast-adresser
• 3: (P bit sett, tvinger T bit) Unicast prefiksbaserte multicast adresser ( RFC 3306 )
• 7: (R bitsett, tvinger P- og T-bit) Multicast-adresser som inneholder adressen til møtepunktet ( RFC 3956 )

Følgende gyldighetsområder er definert:

• 1: interface-local, disse pakkene forlater aldri grensesnittet . ( Loopback )
• 2: link-local, blir aldri videresendt av rutere og kan derfor ikke forlate undernettet.
• 4: admin lokalt, det minste området, hvis avgrensning må administreres spesielt i ruterne.
• 5: Sitelocal kan rutes, men ikke ved grensen rutere .
• 8: lokalt for organisasjonen, kan pakkene også videresendes av grenseruter, men forbli "i selskapet" ( ruteprotokollen må ta passende forholdsregler for dette).
• e: global multicast som kan rutes hvor som helst.
• 0, 3, f: Reserverte områder
• de resterende områdene er ikke tildelt og kan brukes av administratorer for å definere ytterligere multicast-regioner.

Eksempler på kjente multicast-adresser:

• ff01::1, ff02::1: Alle noder adresser. Tilsvarer sendingen.
• ff01::2, ff02::2, ff05::2: Alle ruteradresser, tar for seg alle rutere i et område.

Global unicast

Alle andre adresser regnes som globale unicast- adresser. Av disse er det imidlertid bare følgende områder som hittil er tildelt:

• ::/96(96 0 bits) sto for IPv4-kompatibilitetsadresser, som inneholdt IPv4-adressen i de siste 32 bitene (dette gjaldt bare for globale IPv4 unicast-adresser). Disse ble definert for overgangen, men erklært avviklet i RFC 4291 fra februar 2006 .
• 0:0:0:0:0:ffff::/96(80 0 bits, etterfulgt av 16 1 bits) står for IPv4-tilordnede (vist) IPv6-adresser. De siste 32 bitene inneholder IPv4-adressen. En passende ruter kan konvertere disse pakkene mellom IPv4 og IPv6 og dermed koble den nye med den gamle verden.
• 2000::/3( 2000…til 3fff…; som tilsvarer det binære prefikset 001) står for de globale unicast-adressene tildelt av IANA , dvs. rutbare og globalt unike adresser.

• 2001-Adresser tildeles leverandører som distribuerer dem til kundene sine.

• Adresser fra 2001::/32(dvs. starter med 2001:0:) brukes til Teredo- tunnelmekanismen .
• Adresser fra 2001:db8::/32brukes til dokumentasjonsformål, for eksempel i denne artikkelen, og utpeker ikke faktiske nettverksdeltakere.

• 2002-Forhåndsinnstillinger angir adressene til tunnelmekanismen 6to4 .
• Med 2003, 240, 260, 261, 262, 280, 2a0, 2b0og 2c0starter adresser til regionale registrene tildelt (RIR); disse adressene er z. I noen 2001::/16tilfeller er imidlertid ikke allokert til aksjen ennå som tilfellet er med.
• 3ffe::/16-Adresser ble brukt til testnettverket 6Bone ; dette adresseområdet ble returnert til IANA i samsvar med RFC 3701 .

• 64:ff9b::/96kan brukes til oversettelsesmekanismen NAT64 i henhold til RFC 6146 .

Funksjonalitet

Autokonfigurasjon

Ved å bruke Stateless Address Autoconfiguration (SLAAC, spesifisert i RFC 4862 ), kan en vert automatisk sette opp en fungerende internettforbindelse. For å gjøre dette kommuniserer han med rutere som er ansvarlige for sitt nettverkssegment for å bestemme den nødvendige konfigurasjonen.

fremgangsmåte

For den første kommunikasjonen med ruteren tildeler verten seg selv en link-lokal adresse som, for eksempel et Ethernet- grensesnitt, kan beregnes ut fra maskinvareadressen. Dette gjør det mulig for en enhet å søke etter rutere i sitt nettverkssegment ved hjelp av Neighbor Discovery Protocol (NDP, se også ICMPv6-funksjonalitet ). Dette gjøres ved å sende en forespørsel til multicast- adressen ff02::2der alle rutere i et segment kan nås ( routeroppfordring ).

Som svar på en slik forespørsel sender en ruter informasjon om tilgjengelige prefikser , dvs. informasjon om adresseområdene som en enhet får lov til å tildele unicast- adresser til seg selv . Pakkene som bærer denne informasjonen kalles ruterannonser . De har ICMPv6 type 134 (0x86) og har informasjon om levetiden, MTU og prefikset til nettverket. Verten legger til grensesnittidentifikatoren som også brukes for den lokale linkadressen til et slikt prefiks.

Mekanismen duplikatadressedeteksjon (DAD - gjenkjenning av dobbelt tildelte adresser) er gitt for å forhindre at en adresse blir tildelt to ganger. En enhet kan bare velge ikke tilordnede adresser under automatisk konfigurasjon. DAD-prosessen kjører også uten brukerinnblanding via NDP.

Gyldighetsinformasjon

Rutere kan spesifisere begrensede gyldighetstider ved tildeling av adresseprefikser: Gyldig levetid og foretrukket levetid . Det spesifiserte prefikset kan brukes til kommunikasjon innen gyldig levetid; Innen den foretrukne levetiden bør dette prefikset foretrekkes fremfor en annen hvis foretrukne levetid allerede er utløpt (men hvis gyldig levetid ennå ikke er utløpt). Rutere sender jevnlig ruteannonser til alle verter i et nettverkssegment som de er ansvarlige for, ved hjelp av hvilke prefiksets gyldighetstider oppdateres; Ved å endre annonsene kan vertene nummereres på nytt. Hvis ruterannonsene ikke er autentisert via IPsec, er det ikke mulig å redusere gyldighetstiden til et prefiks som en vert allerede kjenner til mindre enn to timer.

Forholdet mellom automatisk konfigurasjon og DHCPv6

IPv6-autokonfigurasjonen skiller seg konseptuelt fra DHCP eller DHCPv6 . Mens adressetildelingen av DHCPv6 (definert i RFC 3315 ) blir referert til som " Stateful Address Configuration" (analogt: logget adressetildeling, for eksempel av en DHCP-server), er autokonfigurasjonen en " Stateless Address (Auto) Configuration" , siden enhetene selv tilordner en adresse selv og denne oppgaven ikke logges.

Ved hjelp av den automatiske konfigurasjonen kan ingen informasjon om vertsnavn, domenenavn, DNS, NTP- servere osv. Kommuniseres til klienter med mindre de støtter spesifikke NDP-utvidelser. Den ekstra bruken av en DHCPv6-server har etablert seg som et alternativ; dette gir den nødvendige tilleggsinformasjonen, men tar ikke vare på adressetildelingen. I dette tilfellet snakker man om statsløs DHCPv6 (se RFC 3736 ). Det administrerte flagget i svaret på en NDP-ruteanmodning kan brukes til å indikere overfor klienten at den skal sende en DHCPv6-forespørsel og dermed få ytterligere informasjon.

Omnummerering og multihoming

Under IPv4 er nummerering (endring av IP-adresseområdet) problematisk for nettverk av en viss størrelse, selv om mekanismer som DHCP hjelper. Spesielt er overgangen fra en leverandør til den neste uten en "hard" overgang på et fast tidspunkt vanskelig, da dette bare er mulig hvis nettverket er multihomed i en viss tidsperiode, dvs. et nettverk fra mer enn ett leverandør med Internett-tilgang samtidig. Tilkoblings- og IP-adresseområder leveres. Omgå omnummerering under IPv4 ved bruk av Border Gateway Protocol (BGP) fører til fragmentering av adresseområdet. Så mange, relativt små nettverk kommer inn i rutetabellene i kjerneområdet på Internett, og ruterne der må utformes deretter.

Prosessen med å omnummerere ble imidlertid tatt i betraktning ved utforming av IPv6; den behandles i RFC 4076 . Mekanismer som IPv6 automatisk konfigurering hjelper til med dette. Den parallelle driften av flere IP-adresseområder er også lettere under IPv6 enn under IPv4, som beskrevet i avsnittet om adressestruktur ovenfor. I RFC er 3484 satt slik at valget av kilde- og destinasjonsadresser skal gjøres i kommunikasjonen og hvordan de kan bli påvirket hvis de nå er mer tilgjengelige. I tillegg kan dette valget også gjøres på applikasjonsnivå eller gjennom ennå å opprettes, f.eks. B. tilkoblingskvaliteten under hensyntagen til mekanismer. Målet er blant annet å gjøre det mulig for operatøren av et nettverk å enkelt bytte mellom leverandører eller til og med permanent operere flere leverandører parallelt for å fremme konkurranse, øke påliteligheten eller distribuere datatrafikk over linjer fra flere leverandører.

Mobil IPv6

Mobile IP ble integrert i IPv6 som en utvidelse av IPv6-standarden under navnet "Mobile IPv6" ( RFC 6275 ). Kommunikasjon skjer alltid praktisk talt uavhengig av nodenes nåværende posisjon. Dette betyr at mobile IP-sluttapparater kan nås på samme IP-adresse hvor som helst, for eksempel i hjemmenettverket og på en konferanse. Rutetabeller må normalt endres på en møysommelig måte. I stedet bruker Mobile IPv6 en skyggedatamaskin (" hjemmeagent ") som representerer mobilenheten i hjemmenettverket. Innkommende pakker blir tunnelert av denne skyggecomputeren til den gjeldende adressen (“care-of-address”) til den mobile enheten. Hjemmeagenten mottar den nåværende pleieadressen til den mobile enheten ved hjelp av "bindende oppdateringer", som enheten sender til hjemmeagenten så snart den har mottatt en ny adresse i det besøkte utenlandske nettverket. Mobil IP er også spesifisert for IPv4; I motsetning til denne spesifikasjonen krever imidlertid ikke mobil IPv6 en utenlandsk agent som registrerer tilstedeværelsen av mobile enheter i det utenlandske nettverket.

Topptekstformat

I motsetning til IPv4 har IP- overskriften i IPv6 en fast lengde på 40 byte (320 bits). Valgfritt, sjelden benyttede informasjon såkalte forlengelse overskrifter (GER. Forlengelse overskrifter (Engl) mellom IPv6-hodet området og den faktiske nyttelast. Nyttelast ) innleiret. I følge RFC 2460 består overskriftsdataområdet til en IPv6-pakke av følgende felt:

felt	lengde	innhold
versjon	4 bit	IP-versjonsnummer (6)
Trafikk klasse	8 bit	Tjenestekvalitet : Bitt 0–5 brukes til DSCP , bit 6–7 for ECN . Ifølge IANA gjelder den samme tildelingen som for IPv4 ToS .
Flyteetikett	20 biter	Brukes også til QoS eller sanntidsapplikasjoner . Pakker med samme flytetikett behandles likt.
Nyttelastlengde	16 bit	Lengde på IPv6-pakkeinnholdet (uten topptekstdataområde, men inkludert topptekstdata) i byte
Neste overskrift	8 bit	Identifiserer typen for neste header dataområde , dette kan enten betegne et utvidelses header dataområde (se neste tabell) eller en protokoll for et høyere lag (engelsk: Upper Layer Protocol ), for eksempel B. TCP (type 6) eller UDP (type 17).
Hoppgrense	8 bit	Maksimalt antall mellomtrinn via ruteren som en pakke kan reise; reduseres med en når du går gjennom en ruter ("hop"). Pakker med null som humlegrense kastes. Det tilsvarer Time to Live (TTL) -feltet i IPv4.
Kildeadresse	128 bit	Avsenderadresse
Ankomstadresse	128 bit	adressen til mottakeren

Som det er referert til i Neste topptekst , er noen utvidelsesoverskrifter og en plassholder definert:

Etternavn	Type	størrelse	beskrivelse	RFCer
Hop-by-hop-alternativer	0	variabel	Inneholder alternativer som må overholdes av alle IPv6-enheter som pakken krysser. Er z. B. brukt til jumbogrammer .	RFC 2460 , RFC 2675
Rute	43	variabel	Ruten til pakken gjennom nettverket kan påvirkes av denne overskriften; den brukes blant annet for mobil IPv6 .	RFC 2460 , RFC 6275 , RFC 5095
fragment	44	64 bit	Parametrene til en fragmentering kan spesifiseres i denne overskriften .	RFC 2460
Autentiseringshode (AH)	51	variabel	Inneholder data som kan sikre konfidensialiteten til pakken (se IPsec ).	RFC 4302
Innkapsling av sikkerhetsnyttelast (ESP)	50	variabel	Inneholder data for kryptering av pakken (se IPsec ).	RFC 4303
Destinasjonsalternativer	60	variabel	Inneholder alternativer som bare må tas i betraktning av måldatamaskinen til pakken.	RFC 2460
Mobilitet	135	variabel	Inneholder data for mobil IPv6 .	RFC 6275
Ingen neste overskrift	59	tømme	Denne typen er bare en plassholder for å indikere slutten på en topptekst.	RFC 2460

De fleste IPv6-pakker bør gjøre uten utvidelsesoverskrifter ; bortsett fra Destination Options-overskriften , kan disse bare vises en gang i hver pakke. Hvis det er en ruteutvidelseshode i pakken, kan det hende at en annen destinasjonsalternativet blir plassert foran den . Med unntak av det ovennevnte er sekvensen i en kjetting sekvensen til tabellen. Alle utvidelseshoder inneholder et neste topptekstfelt der neste utvidelseshode eller øvre lagprotokoll heter.

Størrelsene på disse topptekstene er alltid multipliser på 64 bits, og de fleste feltene i topptekstdataene er justert til 64-biters grenser for å akselerere minnetilgang i ruteren. I tillegg (i motsetning til IPv4 ) beregnes ikke kontrollsummer lenger over IP-headerdata, bare feilkorreksjon i lag 2 og 4 brukes.

Pakkestørrelser

Den Maximum Transmission Unit (MTU) må ikke være mindre enn 1280 byte i et IPv6-nettverk. Dette betyr at Path MTU (PMTU) ikke faller under denne verdien heller, og pakker opp til denne størrelsen kan garanteres overføres uten fragmentering . Minimal IPv6-implementering er avhengig av denne saken.

En IPv6-kompatibel datamaskin må kunne motta pakker sammensatt av fragmenter med en størrelse på minst 1500 byte. For IPv4 er denne verdien bare 576 byte. På den annen side må en IPv6-pakke, til og med fragmentert, i henhold til nyttelastfeltet i IPv6-overskriften, ikke overstige størrelsen på 65 575 byte inkludert topptekstdata, siden dette feltet er 16 bits langt (2 ¹⁶  - 1 byte pluss 40 bytes header data). Imidlertid gir RFC 2675 muligheten for hop-by-hop-utvidelseshode for å lage pakker med størrelser på opptil 4,294,967,335 byte, såkalte jumbograms . Dette krever imidlertid justeringer i protokoller på høyere nivå, som f.eks B. TCP eller UDP , da disse ofte bare definerer 16 bits for størrelsesfelt. I tillegg må nyttelastlengden settes til 0 i IPv6-overskriften for hver pakke som inneholder et jumbogram .

Utvidet ICMP-funksjonalitet

ICMPv6 ( protokoll type 58 ) gir viktige funksjoner for å fungere for IPv6. Å forby alle ICMPv6-pakker i et IPv6-nettverk ved hjelp av filtre er derfor normalt ikke mulig.

Spesielt blir Address Resolution Protocol (ARP) erstattet av NDP ( Neighbor Discovery Protocol ), som er basert på ICMPv6. Dette bruker intensiv bruk av link-lokale unicast-adresser og multicast , som må beherskes av hver vert. Som en del av NDP håndteres også den automatiske adressetildelingen og den automatiske tildelingen av en eller flere standardruter via ICMPv6, så den gir de fleste funksjonene som ble forklart ovenfor under IPv6 -autokonfigurasjon . NDP kan referere til muligheten for ytterligere konfigurering gjennom DHCPv6 , som imidlertid bruker UDP- pakker.

De rutere ikke lenger fragment lange IPv6-pakker , men i stedet blir ICMPv6 meldinger som brukes for å be om senderen til å sende mindre pakker, også ved hjelp av fragmentet forlengelse overskriften (se maksimal overføringsenhet (MTU) i denne sammenheng ).. Ideelt sett bør en IPv6-vert eller en applikasjon utføre en Path MTU Discovery i samsvar med RFC 1981 før de sender et stort antall IPv6-pakker for å kunne sende pakker med størst mulig størrelse.

IPv6 og DNS

På grunn av lengden på IP-adressene, som stiller høyere krav til menneskelig minne enn IPv4-adresser, er IPv6 spesielt avhengig av et fungerende Domain Name System (DNS). RFC 3596 definerer ressursposten (RR) type AAAA (les: Quad-A ), som, i likhet med en A-ressurspost for IPv4, løser et navn til en IPv6-adresse. Det omvendte oppslaget , dvs. oppløsningen til en IP-adresse til et navn, fungerer fremdeles via RR-typen PTR , bare for IPv6 er det omvendte domenet ikke lenger IN-ADDR.ARPA som for IPv4, men IP6.ARPA og delegering av underdomener gjøres ikke lenger på 8-bit, men på 4-biters grenser.

En IPv6-kompatibel datamaskin søker vanligvis etter et navn ved hjelp av DNS først for RR-typen AAAA, deretter for RR-typen A. I henhold til Standard Policy Table i RFC 3484 foretrekkes kommunikasjon via IPv6 fremfor IPv4 hvis det blir funnet at begge protokollene er tilgjengelige for tilkobling. Rekkefølgen for anvendelse av protokollene er for det meste også i operativsystemet og på applikasjonsnivå. B. i nettleseren , justerbar.

Alle tretten rotnavneservere og minst to navneservere på de fleste toppnivådomener kan nås via IPv6. Den overførte protokollen er uavhengig av den overførte informasjonen. Spesielt kan du be en navneserver om AAAA RR-er via IPv4. Imidlertid tenker leverandører av store portalsider bare å svare på DNS-spørsmål som blir gjort via IPv6 med AAAA-ressursposter for å unngå problemer med feil programmert programvare.

Overgangsmekanismer

IPv6-overgangsmekanismer
4in6	Tunneler fra IPv4 til IPv6
6in4	Tunneler fra IPv6 til IPv4
6over4	Transport av IPv6 -datapakker mellom dual-stack noder over et IPv4- nettverk
6to4	Transport av IPv6-datapakker over et IPv4-nettverk (foreldet)
AYIYA	Alt i noe
Dobbel stabel	Nettverksnoder med IPv4 og IPv6 i parallell drift
Dual-Stack Lite (DS-Lite)	Som dual stack, men med global IPv6 og operatør NAT IPv4
6.	IPv6 rask distribusjon
ISATAP	Intra-Site Automatic Tunnel Addressing Protocol (avviklet)
Teredo	Innkapsling av IPv6-pakker i IPv4 UDP- Datapakker
NAT64	Oversettelse av IPv4-adresser til IPv6-adresser
464XLAT	Oversettelse fra IPv4 til IPv6 til IPv4-adresser
SIIT	Statsløs IP / ICMP-oversettelse

IPv4 og IPv6 kan drives parallelt på samme infrastruktur, spesielt på Internett . Som regel kreves ingen nye linjer, nettverkskort eller enheter for overgangen, forutsatt at egnede operativsystemer er tilgjengelige. Det er for tiden knapt noen enheter som kan håndtere IPv6, men ikke IPv4 samtidig. Men slik at enheter som er koblet utelukkende via IPv4 også kan kommunisere med enheter som utelukkende er koblet til via IPv6, trenger de oversettelsesprosedyrer .

Ulike mekanismer er utviklet for å muliggjøre en enkel overgang fra IPv4 til IPv6-kommunikasjon på Internett. IPv6 er vanligvis slått på uten å slå av IPv4. Det skilles mellom følgende tre mekanismer:

• Parallell drift ( dobbel stabel )
• Tunnelmekanismer
• Oversettelsesprosess

Parallell drift og tunnelmekanismer krever at operativsystemene til de tilkoblede datamaskinene kan håndtere begge protokollene.

Det er allerede områder på Internett som bare kan nås ved hjelp av IPv6, andre deler som er koblet til både protokoller og store deler som utelukkende er avhengige av IPv4. I det følgende blir de to første områdene samlet referert til som IPv6-internett.

Dobbel stabel

Med denne prosedyren tildeles alle involverte grensesnitt minst en IPv6-adresse i tillegg til IPv4-adressen, og den nødvendige rutingsinformasjonen tildeles datamaskinene. Datamaskinene kan da kommunisere uavhengig ved å bruke begge protokollene, dvs. H. Utveksle data med både IPv4- og IPv6-kompatible systemer. Denne prosedyren bør være regelen, den mislykkes for øyeblikket fordi noen rutere (for det meste tilgangsserverne til Internett-leverandøren eller hjemmeruterne til kundene) på vei til IPv6-internett ennå ikke har slått på eller ikke støtter IPv6- videresending .

Dual-Stack Lite (DS-Lite)

På grunn av de knappe IPv4-adressene har IETF utviklet "Dual-Stack Lite" ( RFC 6333 ) -mekanismen . Kunden får bare globalt rutbare IP-adresser via IPv6. (Både IPv6 og IPv4 tilbys i vanlig dual-stack-drift.)

Private IPv4-adresser brukes i kundens LAN (analogt med NAT- prosedyren ). I stedet for en NAT-oversettelse blir IPv4-pakkene deretter innkapslet i IPv6-pakker av Customer Premises Equipment (CPE) . CPE bruker sin globale IPv6-tilkobling til å transportere pakkene til transportør-NAT (CGN) til Internett-leverandøren , som har globale IPv4-adresser. Her pakkes IPv6-pakken ut og den opprinnelige IPv4-pakken gjenopprettes. Deretter konverteres IPv4-pakken til en offentlig IP-adresse med NAT og dirigeres til det offentlige IPv4 Internett. NAT-operatøren identifiserer økter unikt ved å registrere den offentlige IPv6-adressen til CPE, den private IPv4-adressen og TCP- eller UDP-portnumrene.

Imidlertid fører denne DS-Lite-implementeringen til problemer for sluttkunden: På den ene siden er ikke IPv4-baserte portutgivelser lenger mulig med portbaserte protokoller (f.eks. TCP, UDP), siden pakkene til den offentlige IP-adressen er allerede filtrert ut av leverandøren. Tjenester som tilbys på en DS-Lite-tilkobling kan ikke nås av enheter som ikke kan opprette IPv6-tilkoblinger. Bare visse protokoller blir forstått og videresendt av CGN-gatewayen , noe som gjør bruken av andre IP-baserte protokoller vanskelig eller helt umulig.

Tunnelmekanismer

For å bygge bro over rutere som ikke videresender IPv6 på vei til IPv6 Internett, er det en rekke tunnelmekanismer . Her overføres IPv6-pakker i brukerdataene til andre protokoller, for det meste IPv4, til et eksternt tunnelnettsted som ligger på IPv6-internett. Der blir IPv6-pakkene hentet ut og overført til destinasjonen via IPv6-ruting. Veien tilbake fungerer på samme måte. Hver tunnelmetode avhenger av kvaliteten på tunnelprotokollen: pakkenes rute til destinasjonen er vanligvis ikke optimal på grunn av omkjøringen via tunnelens eksterne ende, og den mulige nyttelasten reduseres fordi flere overskriftsdata må overføres.

Den klassiske måten er å søke en såkalt tunnelmegler om en slik ekstern stasjon for privat bruk gratis. Denne eksterne stasjonen forblir fast, og det samme IPv6-adresseområdet tildeles alltid via tunnelen. For eksempel bruker 6in4 protokoll type 41 for å kapsle IPv6 direkte i IPv4. For Linux kan en slik tunnel opprettes ved hjelp av konfigurasjonsverktøyene for grensesnittet . Med Windows er dette ikke lenger mulig siden Windows 10. april 2018 (1803). 6over4- eller ISATAP- prosedyrene er mer kompliserte .

6to4- mekanismen krever ingen avtale med en ekstern stasjon, fordi den bruker ( anycast ) IPv4-adresser definert på Internett , og de tunneliserte pakkene leveres til nærmeste eksterne stasjon og behandles der. Et IPv6-adresseområde er da tilgjengelig for den tilkoblede datamaskinen, som beregnes fra den offentlige IPv4-adressen. En slik tunnel kan også settes opp på nåværende Linux-datamaskiner med en offentlig IPv4-adresse i noen få enkle trinn.

Hvis en datamaskin er i et privat IPv4-adresseområde og NAT finner sted når du kobler til Internett , kan mekanismer som AYIYA eller Teredo hjelpe. Disse protokollene innkapsler vanligvis IPv6-pakker som brukerdata i UDP- pakker. Hvis en administrator tillater disse protokollene, kan nettverkssikkerhet raskt være i fare hvis pakkefilteret ikke kan tolke brukerdataene som IPv6-pakker, og dermed kan andre pakkefilterregler omgåes.

Det er også mulig å transportere IPv6 via mer generelle tunnelmetoder som GRE , L2TP eller MPLS , spesielt hvis ruteprotokoller som IS-IS må overføres parallelt.

Oversettelsesprosess

Hvis IPv6 ikke kan aktiveres på en enhet, eller hvis det ikke lenger er nok IPv4-adresser tilgjengelig, kan metoder som nettverksadresseoversettelse / protokolloversettelse (NAT-PT, RFC 2766 , nå utfaset), eller transportreléoversettelse (TRT, RFC 3142 ) kan brukes. bli nødvendig å oversette mellom de to protokollene. Proxy-servere gir også muligheten for kommunikasjon mellom de to verdenene for noen protokoller med høyere lag.

NAT64- metoden tilbyr en ganske tilfredsstillende løsning så lenge hovedkravet er å videresende tilkoblinger initiert av IPv6-verter til IPv4-verter.

Teknisk implementering

Den RFC 6434 (IPv6 Node Krav) gir en oversikt over funksjonene som skal gjennomføre alle IPv6-enheter for å sikre maksimal interoperabilitet. Dette dokumentet refererer til respektive spesifikasjoner.

Operativsystemer

Mange operativsystemer støtter nå IPv6, følger en oversikt. Støtten som tilbys av firmware eller operativsystemene på (DSL) rutere hos sluttkunder og tilgangsserverne hos leverandørene er også avgjørende for en tunnelfri tilkobling . Systemer (f.eks. CDN ) for lastbalansering , slik de er f.eks. B. brukes til store nettsteder, ble og vil bli supplert stykke for stykke for å inkludere IPv6.

AIX

IPv6 har blitt implementert siden AIX 4 versjon 4.3, og mobil IPv6 har også blitt implementert siden AIX 5L versjon 5.2.

Android

Android støtter IPv6 siden versjon 2.1, men ikke via 3GPP- grensesnittet. IPv6 APN har blitt støttet siden 2.3.4. Imidlertid manglet de fleste sluttapparatene støtte i UMTS-brikkesettet (eller fastvaren). Fra og med versjon 4.0 Ice Cream Sandwich er personvernutvidelser aktivert som standard.

BSD-varianter

IPv6 har blitt støttet av BSD-ene i veldig lang tid og veldig omfattende (for eksempel på FreeBSD siden mars 2000, på NetBSD siden desember 2000 og på OpenBSD siden midten av 2000). Støtten er i stor grad takket være KAME-prosjektet , som har utviklet en gratis protokollstabel for IPv6 og IPsec for BSD-operativsystemer siden 1998 .

Cisco

IPv6 støttes eksperimentelt fra IOS versjon 12.2T og produktivt fra versjoner 12.3 og 12.4. På eldre enheter og kort, på grunn av maskinvareutstyret, er IPv6-videresending imidlertid bare mulig i programvare, dvs. ved hjelp av hovedprosessoren, noe som reduserer ytelsen betydelig sammenlignet med IPv4.

HP-UX

IPv6 har vært en del av det grunnleggende systemet siden versjon 11iv2, tidligere 11.x-versjoner kan gjøres IPv6-kompatible med TOUR (Transport Optional Upgrade Release).

iOS (Apple iPhone, iPad, iPod Touch, Apple TV)

Apple-enheter med iOS versjon 4 eller høyere støtter IPv6 i dual-stack modus. Imidlertid støttes personvernutvidelser bare fra versjon 4.3.

Enebær

Produsenten støtter IPv6 på rutere i JunOS- operativsystemet fra versjon 5.1. IPv6-videresending skjedde tidlig i maskinvare, dvs. uten å laste rutemotoren (hovedprosessoren). For brannmursystemer, både på ScreenOS-serien (ScreenOS <6.x) og på SRX-serien (JunOS <10.x), støttes IPv6.

Linux

Den kjerne siden versjon 2.6 tilbyr en produktiv brukbar IPv6 støtte på et tilsvarende nivå som BSD derivater. 2.4-kjernen tilbyr støtte for IPv6, som har vist seg å være eksperimentell, men fortsatt mangler viktige egenskaper som IPSec og databeskyttelsesutvidelser (Privacy Extensions, RFC 4941 ). De fleste Linux-distribusjoner har personvernutvidelser slått på i leveringstilstand med kjerner fra versjon 3.x, men disse kan deaktiveres manuelt. En eksperimentell IPv6-implementering er også inkludert i kjerneversjon 2.2.

Mac OS X

Siden versjon 10.2 inkluderer Mac OS X også støtte for IPv6 basert på KAME . Det har bare vært mulig å konfigurere IPv6 via GUI siden versjon 10.3 . IPv6 er aktivert som standard og støtter DNS AAAA-poster. Airport Extreme forbrukerrutere som tilhører Apple-produktfamilien, oppretter som standard en 6to4- tunnel og fungerer som en IPv6-ruter. Personvernutvidelsene er aktivert som standard siden 10.7 (Lion) .

OpenVMS

Med HP TCP / IP-tjenester for OpenVMS versjon 5.5 støtter HP OpenVMS (versjon 8.2 eller nyere) IPv6.

Solaris

Siden versjon 8 har støtte for IPv6 også blitt inkludert i begrenset form i operativsystemet fra Sun Microsystems (implementeringen og store deler av operativsystemapplikasjonene krever fortsatt at IPv4 skal konfigureres), som er tilgjengelig for SPARC og i386 dataarkitekturer . Konfigurasjonen utføres på samme måte som for Linux- og xBSD-systemene.

Symbian OS

IPv6 har vært en integrert del av systemet siden versjon 7.0. Bare noen få parametere må konfigureres via GUI .

Windows

Siden Windows XP Service Pack 1 har Windows tatt med seg en protokollstabel for IPv6. Siden den gang har støtten for IPv6 blitt utvidet jevnlig av Microsoft og tilpasset dagens utvikling. Siden Windows 8 har IPv6 blitt brukt som den foretrukne protokollen hvis verten er koblet til et dual-stack nettverk.

Windows Server

Fra og med Windows Server 2003 inkluderer Windows Server en "Production Quality" -protokollstabel. Støtte for IPv6 har kontinuerlig blitt utvidet av Microsoft i versjonene av Windows Server som har blitt gitt ut siden den gang.

Windows telefon

Windows Phone 7 og 7.5 støtter ikke IPv6. En IPv6-stabel er bare integrert i versjon 8 og nyere.

z / OS

IBM z / OS har støttet IPv6 fullt ut siden september 2002, og i 1998 var det en eksperimentell stabel for forgjengeren, OS / 390.

Rute

Mens statisk ruting for IPv6 kan settes opp på samme måte som IPv4, er det noen endringer for de dynamiske rutingsprotokollene . Den Border Gateway Protocol med Multi Extensions (definert i RFC 4760 ) blir også brukt mellom autonome systemer . Ettersom den indre gateway-protokollen er OSPF versjon 3, IS-IS med støtte fra IPv6 TLV og RIPng som åpne standarder. De fleste produsenter støtter multitopologiruting for IS-IS , dvs. samtidig ruting for begge adressefamiliene, selv om IPv4- og IPv6-nettverk ikke akkurat overlapper hverandre. OSPFv3 implementerer dette i en helt ny standard ( RFC 5838 ) via forskjellige forekomster for de forskjellige protokollene, men var opprinnelig bare ment for IPv6. En annen måte er å bruke forskjellige rutingsprotokoller for de to topologiene , for eksempel OSPFv2 for IPv4 og IS-IS for IPv6.

En eller flere standardruter kan overføres til sluttanlegg via autokonfigurasjon eller DHCPv6. Med DHCPv6-PD ( prefiksdelegasjon ) kan også prefikser distribueres for videre ruting, for eksempel til kunderutere.

Siden verken RSVP eller LDP er tilstrekkelig standardisert for IPv6, må MPLS- nettverk fortsette å stole på signalering ved hjelp av IPv4, men kan, avhengig av implementeringen, transportere IPv6-trafikk. PIM er egnet for IPv6 multicast-ruting .

Pakkefiltre og brannmurer

For IPv6 må alle filterregler i brannmurer og pakkefiltre gjenopprettes. Avhengig av om filtreringsprosessen i det hele tatt behandler IPv6-datatrafikken, og avhengig av standardpolicyen, kan en brannmur slippe IPv6 gjennom uhindret. Noen antivirusprogrammer har også tillegg som blokkerer trafikken, f.eks. B. Søk etter signaturer på visse TCP- porter. For Linux kan filtrering av IPv6 konfigureres med programmet ip6tables (siden versjon 3.13 av Linux-kjernen også er nft / nftables ).

Vesentlige endringer i strukturen av filtrene i forhold til IPv4 kan resultere hvis de håndtere ICMP eller ICMPv6 , som sin protokollnummer , typen og kode oppgaver og funksjoner forandring.

Den Neste topptekst -feltet i IPv6-hodet er ikke egnet for identifisering av høyere-lags protokoller på samme måte som den protokoll -feltet i IPv4-hodet, fordi når utvidelsen overskriftene benyttes, deres verdiendringer, for eksempel i tilfelle av fragmentering.

Tidligere ble noen aspekter av NAT ofte sett på som en sikkerhetsfunksjon; I IPv6 er NAT imidlertid bare gitt i unntakstilfeller. RFC 4864 beskriver prosedyrer som kartlegger disse aspektene av NAT med IPv6-teknikker; For eksempel kan den eksisterende NAT-funksjonen i noen implementeringer av ikke videresending av nye innkommende tilkoblinger til datamaskiner i hjemmenettverket erstattes av et stateful pakkefilter i ruteren. Dette kan vanligvis avvise innkommende tilkoblinger eller bare tillate dem for bestemte områder i hjemmenettverket.

Applikasjonsprogramvare

For applikasjoner som nettlesere eller e-postprogrammer er det nødvendig med endringer i programmeringen slik at de kan kommunisere via IPv6. Dette har allerede skjedd for de viktigste programmene som leveres med dagens operativsystemer, men ikke for mindre brukte applikasjoner.

I de fleste tilfeller er det bare mindre endringer som er nødvendige, ettersom programmene er basert på protokoller på høyere nivå, og disse knapt endres. I mange operativsystemer krever programmeringsgrensesnittene imidlertid at applikasjonen eksplisitt ber om stikkontakter for IPv4-kommunikasjon. Nyere grensesnitt er vanligvis utformet på en slik måte at IPv6-støttende applikasjoner automatisk også støtter IPv4. Hvis applikasjonene behandler innhold med URL-er slik de forekommer i HTTP eller Session Initiation Protocol (SIP), må de støtte URL-noteringen av IPv6-adresser .

I noen tilfeller er det nødvendig med endringer for ikke å redusere ytelsen til applikasjonen. For eksempel kan en mulig bestemt, redusert Path MTU overføres til applikasjonen for å unngå fragmentering, eller Maksimal segmentstørrelse (MSS) i TCP- overskriften må reduseres med IPv6 sammenlignet med IPv4. Mange programmeringsspråk gjør spesielle biblioteker tilgjengelige for å forenkle bruken av den nye protokollen.

administrasjon

Hovedarbeidet med implementeringen er på administrativt nivå: Administrasjon og støtte må trenes, dokumentasjon og konfigurasjoner, f.eks. B. for ruting , brannmurer , nettverksovervåking , domenenavnsystemet og muligens DHCP , må opprettes og vedlikeholdes for begge protokollene i overgangsfasen. I mange dokumentasjoner eller feilmeldinger må det skilles mellom IPv4 og IPv6, der bare noen få år siden ble nevnt IP. Strukturen til IP-nettverket vil i utgangspunktet bli doblet.

Ofte har IP-adresser høyere betydning. De vises i loggfiler eller netflowdata , hvorav noen viderebehandles med skript som Webalizer for å generere visninger, statistikk eller kontoer. Oppsettet og skriptene for å generere sider som Wikipedia's "versjonshistorikk" måtte også tilpasses IPv6-notasjonen, ettersom brukere noen ganger blir identifisert av deres IP-adresse. Er en rettighetsforvaltning basert, for eksempel B. i mange databaser, til tilgang gjennom faste IP-adresser, må dette tas i betraktning når du aktiverer IPv6.

Formidling og prosjekter

IPv6 får bare sakte aksept i praktisk bruk. Adressetildeling for IPv6 gikk fra eksperimentell til vanlig drift i juli 1999, og flere og flere Internett-leverandører driver IPv6 så vel som IPv4 i nettverket.

I topptider transporteres 150 GBit / s IPv6-trafikk via internettnoden AMS-IX , som er rundt 3% av den totale trafikken på 5 TBit / s som oppstår der. På nettsteder i dual-stack-drift måles 27% av tilgangene over hele verden via IPv6, for tilgang fra Tyskland er IPv6-andelen 46%.

Den globale IPv6-rutetabellen inneholdt rundt 33 000 prefikser per oktober 2016, og omtrent 26% av alle autonome systemer tilgjengelig på Internett deltar i global IPv6-ruting. De fleste av de store utvekslingspunktene for internettrafikk tillater og fremmer utveksling av IPv6 via deres infrastruktur i tillegg til IPv4. På DE-CIX brukte rundt 70 til 80 av totalt 240 leverandører IPv6 i april 2008.

Den IPv6 Forum ble stiftet i juli 1999, den tyske IPv6 Rådet i desember 2007. IPv6 Forum Project IPv6-Ready tildeler IPv6-logoen i tre forskjellige trinn, som måler implementeringen av protokollen. Nettstedet viser også alle IPv6-kompatible operativsystemer.

74% av alle IPv4-adresser er for øyeblikket tildelt direkte til de nordamerikanske internettregistrene og noen amerikanske institusjoner og selskaper, mens for eksempel hele Kina - med over 250 millioner Internett-brukere (fra juni 2008) - for mange år siden bare om denne mange IP adresser som eies som en campus i University of California (desember 2004).

Fra sluttbrukerens side er IPv6 heller ikke nødvendig fordi de nå er blitt mer eller mindre vellykket portert ut av det større adresseområdet med viktige nye funksjoner i IPv6 til IPv4 (som IPsec , QoS , multicast , omnummerering og automatisk konfigurasjon er bruker også DHCP mulig) - det er ikke noe utbredt program som bare fungerer med IPv6.

Tidlige prosjekter

I Tyskland var JOIN-prosjektet ved Universitetet i Münster ansvarlig for eksperimentene på IPv6. JOIN og Association for the Promotion of a German Research Network ( DFN ) har satt opp "6WiN", den første IPv6-ryggraden i Tyskland. 6WiN var en ringformet ryggrad gjennom Tyskland med en tverrforbindelse mellom Essen og Berlin. Samtidig satte Deutsche Telekom opp sin egen IPv6-ryggrad mellom Darmstadt, Münster og Berlin og tilbød sine forretningskunder en forbindelse til den som en del av et utstillingsprosjekt. Dette nettverket var koblet til 6WiN i Münster og Berlin. Den tyske sentrale tilgangen til det eksperimentelle IPv6-nettverket 6Bone , som ble slått av 7. juni 2005 som en del av den planlagte gradvise avslutningen av den verdensomspennende 6Bone-operasjonen, var også lokalisert i Münster . 1. januar 2006 ble IPv6-drift i det tyske forskningsnettverket overlevert fra JOIN-prosjektet til DFN-NOC.

Den Universitetet i Wien , som også opererer i Wien Internet Exchange (VIX) og flere DNS- servere for “.at” sonen, spilte en avgjørende rolle i IPv6 migrasjon i Østerrike. Begge fasilitetene kan nås via IPv6 eller tilby akademiske kunder en IPv6-forbindelse. Den første kommersielle leverandøren i Østerrike var neste lag .

Tilkobling av sluttbrukere

Den såkalte World IPv6 Day fant sted 8. juni 2011 , hvor dual-stack-drift ble testet på flere store nettsteder. Testen gikk stort sett uten problemer. På DE-CIX Internett- hub ble det målt et betydelig økt volum på IPv6-trafikk, som fortsatte etter 8. juni.

Som en del av en annen handlingsdag 6. juni 2012, verdens IPv6-lanseringsdag , har mer enn 1400 selskaper over hele verden konvertert sine nettsteder permanent til den nyeste standarden, slik at de kan nås med IPv4 og IPv6.

Siden 25. september 2012 har Deutsche Telekom også levert IPv6 til DSL-sluttkundeforbindelser. Først og fremst ble de såkalte IP-tilkoblingene gjort IPv6-kompatible, først med nye kunder. De nå deaktiverte analoge og ISDN-tilkoblingene mottok ikke IPv6. I den nåværende beskrivelsen av tjenester for bruk av LTE på en fast avtalt adresse (“MagentaZuhause via radio” som et alternativ til DSL), gir Deutsche Telekom bl.a. For eksempel er det klart at bare IPv4-adresser kan nås via denne Internett-tilgangen.

Brukere av andre tilkoblingstyper som mobilnettverket eller kabelen får i økende grad IPv6.

Problemer

Historisk

Spesielt i begynnelsen ble IPv6-standardene endret ofte, noe som medførte at allerede fullførte implementeringer måtte tilpasses flere ganger.

Adressering av nettverksnodene

Den største endringen var innføringen av IEEE- standarden EUI-64 for grensesnittidentifikatoren som en del av adressene. For å garantere unikheten til en adresse i nettverket på en enkel måte, ble MAC-adressen til et grensesnitt tidligere vedtatt uendret i IPv6-adressen, nå er MAC-adressen skrevet til IPv6-adressen i en modifisert form i samsvar med EUI -64; På grunn av en blanding i RFC 3513 blir algoritmen for beregning av EUI-64-navn fra EUI-48-navn feil brukt på MAC-48-navn.

Fremgangsmåtene som er beskrevet fører til en statisk vert-spesifikk del av IPv6-adressen til en automatisk konfigurert IPv6-node. Databeskyttelsesaktivister var bekymret for at dette ville tillate brukere å bli identifisert på tvers av forskjellige nettverk, og at dette for eksempel kunne utnyttes til markedsføringstiltak eller statlige inngrep. Den IETF derfor senere definert databeskyttelse forlengelser ( personvern utvidelser ) i henhold til RFC 3041 , senere RFC 4941 (se også adressestrukturen av IPv6 ). Disse personvernutvidelsene genererer en tilfeldig vertsspesifikk del under automatisk konfigurasjon via SLAAC. Siden de første 64 bitene av IPv6-adressen til et nettverk (f.eks. En husholdning) beholdes, må ytterligere beskyttelse sikres ved å endre den nettverksspesifikke delen regelmessig (slik det er tilfelle i dag med DSL-tilkoblinger).

Integrering i domenenavnsystemet

I lang tid var DNS-tilpasningen for integrering av IPv6 inkonsekvent. I 1995 ble platetypen AAAA opprinnelig definert i RFC 1886 for oppløsning av DNS-navn til IPv6-adresser, som funksjonelt tilsvarer A-posten for IPv4. I 2000 ble AAAA erstattet i RFC 2874 av platetype A6, som primært var ment å forenkle omnummerering ved å kartlegge IP-adressen stykke for bit til DNS, men var aldri fri for tekniske problemer. I 2003 ble A6-metoden nedgradert til "eksperimentell" i RFC 3596 , og AAAA ble den nye, gamle standarden.

Den omvendte oppløsningen ("omvendt" oppløsning) av IPv6-adresser forårsaket enda flere vanskeligheter, ettersom endringen i standarder betydde at PTR-poster eksisterte i to forskjellige soner, under ip6.arpa og ip6.int. På grunn av den tradisjonelle bruken av TLD .arpa for bakoveroppløsning i IPv4, vant den første varianten mot ip6.int, hvorpå delegasjonen til ip6.int ble slettet i juni 2006.

Oppløsningen er helt uavhengig av forespørselens protokolltype: Hvis en DNS-forespørsel blir gjort via IPv4, kan en AAAA-post også returneres, og navneservere som er tilgjengelige via IPv6, gir også informasjon om IPv4-adresser (A-poster).

Nåværende

Link-lokale adresser

En mulig svakhet ved utforming av IPv6 er at adresseområdene for link-lokale adresser generelt ikke er atskilt. Hvis du vil bruke link-lokale adresser på applikasjonsnivå for kommunikasjon mellom datamaskiner i samme nettverkssegment, oppstår problemet at det ikke er tilstrekkelig for dem å legge inn IP-adressen i målfeltet, men også en soneindeks iht. RFC 4007 (i de fleste tilfeller et grensesnitt ) må spesifiseres, siden den link-lokale adresseplassen til flere grensesnitt overlapper hverandre. Det avhenger derfor av om IPv6-støtten til applikasjonen som brukes kjenner begrepet soneindekser, om link-lokale adresser kan brukes til dette formålet.

Autokonfigurasjon og DNS

Samspillet mellom IPv6-autokonfigurasjonsmekanismen og Domain Name System har ført til problemer den dag i dag. Opprinnelig var det ingen mulighet til å informere nettverksnoder om DNS-serverne som skulle brukes og annen DNS-relatert informasjon som DNS-søkeveier som en del av autokonfigurasjonen, som er vanlig for IPv4 i sammenheng med DHCP . I dag er det egentlig to løsninger på problemet:

• Ved å bruke det administrerte flagget i ruteannonser kan nettverksnoder instrueres om å be en DHCPv6- server om videre konfigurasjon. DHCPv6-serveren kan bruke multicast-adressen ff02::1:2og ff05::1:3adresseres. I motsetning til DHCP, trenger ikke DHCPv6-serveren å føre logger over slike forespørsler, så konfigurasjonen kan fortsatt være statsløs.
• NDP-spesifikasjonen gjør det mulig å spesifisere flere felt i ruteannonser. De såkalte RDNSS-utvidelsene ( Recursive DNS Server ) og DNSSL ( DNS Search List ) angir en måte å sende DNS-servere og DNS-søkeveier som en del av ruteannonser.

Spesielt ble RDNSS og DNSSL bare standardisert i november 2010 med utseendet til RFC 6106 .

Støtte for ovennevnte løsninger er inkonsekvent blant forskjellige implementeringer. For eksempel støtter Microsoft Windows Vista og 7 bare DHCPv6, og selv om alle metodene er tilgjengelige for Linux-systemer, er de ofte ikke forhåndsinstallert av distributører. Siden versjon 10.7 (Lion) støtter Mac OS X imidlertid både DHCPv6 og RDNSS.

personvern

Databeskyttelse klager over IPv6 at hver enhet som er koblet til Internett, kan få en fast IP-adresse, slik at alle besøkte sider kan bestemmes år senere og besøkende kunne identifiseres. Teknisk sett kan dette vanskeliggjøres av personvernutvidelsene.

Selv 64-biters adresser ville ha representert en ufattelig tilførsel av godt over 10 ¹⁹ adresser - en milliard ganger 10 milliarder, nesten en milliard generasjoner av menneskeheten. Med de 128 bitene som brukes i IPv6, er det til og med 10 ³⁸ . I teorien betyr dette at hvert atom i hver person i verden kunne tildeles sin egen adresse.

Siden det aldri kan være mangel, har tekniske enheter som IPv4 blitt overflødige, som et resultat av at en Internett-bruker noen ganger ble tildelt en annen IP-adresse noen få timer. Med IPv6 har privatpersoner praktisk talt en fast IP-adresse, noe som er en velsignelse for nettsporing . Hver IPv6-adresse kan tildeles en husstand eller til og med en mobiltelefon veldig pålitelig. Dette tillater z. B. en søkemotor eller nettbutikk identifiserer personer og lenker informasjon om dem uten å få tilgang til eksterne datasystemer. Dette krevde opprinnelig såkalte " tracking cookies ". Med tilstrekkelig spredning av IPv6-adresser blir denne prosedyren foreldet.

For å omgå dette problemet ønsker databeskyttelsestjenestene å forplikte internettleverandører ved lov å tilby dynamiske adresser også under IPv6.

IPv5

Det er ingen protokoll som heter IPv5. Imidlertid har IANA reservert IP-versjon nummer 5 for Internet Stream Protocol Version 2 (ST2, definert i RFC 1819 ), som burde ha forbedret sanntidsfunksjoner sammenlignet med IPv4, men deretter avviklet utviklingen til fordel for IPv6 og RSVP av kostnads-nyttehensyn har vært.

Se også

• Liste over IPv6 tunnelmeglere
• M6Bone
• Peer Name Resolution Protocol
• Internett-protokollfamilie
• Tunnelmegler
• Hurricane Electric , en ISP kjent for tunnelmegleren og v6-ryggraden

litteratur

Grunnleggende spesifikasjoner

• RFC 2460 . - Internet Protocol, versjon 6 (IPv6) spesifikasjon . (Oppdatert av RFC 8200  - erstattet i juli 2017 - engelsk).
  • RFC 8200 . - Internet Protocol, versjon 6 (IPv6) spesifikasjon . Juli 2017. (Erstatter RFC 2460 - engelsk).
• RFC 4861 . - Neighbor Discovery for IP versjon 6 (IPv6) . (Engelsk).
• RFC 4862 . - IPv6 Stateless Address Autoconfiguration . (Engelsk).
• RFC 4291 . - IP-versjon 6 som adresserer arkitektur . (Engelsk).
• RFC 5942 . - IPv6-delnettmodell . (Engelsk).

Sekundær litteratur

• Reiko Kaps: WAN-rampe - gå online med IPv6-nettverket . I: c't , Heise, Hannover 2008.6.
• Silvia Hagen: IPv6. Grunnleggende - funksjonalitet - integrasjon . Sunny Edition, Maur 2009, ISBN 978-3-9522942-2-2 .
• Joseph Davies: Forstå IPv6 . 2. utgave. Microsoft Press, Redmond 2008, ISBN 978-0-7356-2446-7 (engelsk).
• Anatol Badach: IP-nettverkens teknologi. TCP / IP inkludert IPv6. Hvordan det fungerer, protokoller og tjenester . Hanser oppslagsbok. 2. utgave. Hanser, München 2007, ISBN 3-446-21935-8 .
• Mathias Hein: IPv6, The Migration Guide . Franzis, Punkt 2003, ISBN 3-7723-7390-9 .
• Herbert Wiese: Den nye internettprotokollen IPv6 . Hansers oppslagsbok. Hanser, München 2002, ISBN 3-446-21685-5 .
• Hans P. Dittler: IPv6. Den nye internettprotokollen. Teknologi, applikasjon, migrasjon. 2. utgave. Dpunkt, Heidelberg 2002, ISBN 3-89864-149-X .
• Christian Huitema: IPv6 - den nye generasjonen . Addison-Wesley, München 2000, ISBN 3-8273-1420-8 .

weblenker

• Tildeling av IPv6-adresseplass Oversikt (engelsk)
• CRE197 IPv6 Detaljert, tyskspråklig podcast om IPv6
• Målinger av Hurricane Electric til spredning av IPv6 (engelsk)
• Regionspesifikk IPv6-tilgang og latensstatistikk for Google-tjenester (krever aktivert JavaScript )
• Test din IPv6 - IPv6-tilkoblingstestside (krever JavaScript aktivert )
• IPv4 / IPv6-test for innebygging på ditt eget nettsted (krever aktivert JavaScript )

Individuelle bevis