IPv6 er en oppgradering til IPv4- protokollen , designet for å løse problemet med adresseutmattelse . Utviklingen begynte i desember 1998 da Steve Deering og Robert Hinden, ansatte i Cisco og Nokia publiserte en formell spesifikasjon av protokollen gjennom en RFC [ 1 ] [ 2 ] og implementeringen av den pågår fortsatt.
Designet av Steve Deering fra Xerox PARC IPv6, var målet å til slutt erstatte IPv4 , [ referanse nødvendig ] hvis grense for antall tillatte nettverksadresser begynner å begrense veksten av Internett og bruken av det, spesielt i Kina , India og andre tettbefolkede asiatiske land. Den nye standarden søker å forbedre tjenesten globalt; for eksempel ved å gi fremtidige mobiltelefoner og mobile enheter sine egne, permanente adresser.
IPv4 muliggjør 4 294 967 296 ( 232 ) forskjellige enhetsadresser, et antall mindre enn verdens befolkning og mindre enn antall enheter totalt. Ved begynnelsen av 2010 forble mindre enn 10 % av IP-adressen utildelt. [ 3 ] I uken 3. februar 2011 [ 4 ] leverte IANA (International Agency for Assigned Internet Numbers, for sitt akronym på engelsk) den siste blokken med adresser tilgjengelig (33 millioner) til organisasjonen som er ansvarlig for å tildele IP-er i Asia, et marked som blomstrer og snart vil konsumere dem alle.
I motsetning til dette støtter IPv6 340.282.366.920.938.463.463.374.607.431.768.211.456 ( 2.128 eller 340 sextillioner adresser ), omtrent 6,7 × 10 17 (670 millimeter) av jordens kvadratiske areal . [ 5 ]
I løpet av det første tiåret med drift av Internett basert på TCP/IP, på slutten av 1980-tallet, ble det klart at metoder måtte utvikles for å spare adresseplass. På begynnelsen av 1990-tallet, selv etter introduksjonen av klasseløst nettverksredesign, ble det klart at det ikke ville være nok til å forhindre utmattelse av IPv4-adresser, og at ytterligere endringer var nødvendig. Tidlig i 1992 sirkulerte flere systemforslag, og på slutten av 1992 kunngjorde IETF en oppfordring til hvitebøker ( RFC 1550 ) og opprettelsen av arbeidsgrupper "IP Next Generation" eller "IP Next Generation"
IPng ble foreslått av Internet Engineering Task Force (IETF) 25. juli 1994 , med dannelsen av flere IPng-arbeidsgrupper. Fram til 1996 ble flere RFC-er som definerer IPv6 publisert, og startet med RFC 2460 . [ referanse nødvendig ]
Den tekniske diskusjonen, utviklingen og introduksjonen av IPv6 var ikke uten kontrovers. Designet ble sterkt kritisert for mangel på interoperabilitet med IPv4 og andre aspekter av blant andre ingeniør DJ Bernstein. [ 6 ]
Forresten, IPng (IP Next Generation) var ikke i stand til å bruke versjonsnummer 5 ( IPv5 ) som en etterfølger til IPv4, siden den hadde blitt tildelt en eksperimentell streaming -orientert protokoll beregnet på å støtte tale, video og lyd.
IPv6 er allment forventet å bli støttet i forbindelse med IPv4 i nær fremtid. Kun IPv4-noder er ikke i stand til å kommunisere direkte med IPv6-noder, og vil trenge hjelp fra en mellommann.
På mange måter er IPv6 en konservativ utvidelse av IPv4, som beholder de mest brukte funksjonene, andre som ikke er så viktige eller lite brukte er fjernet eller gjort valgfrie, og nye funksjoner er lagt til. De fleste transport- og applikasjonsprotokoller krever få eller ingen endringer for å fungere over IPv6; Unntakene er applikasjonsprotokoller som integrerer nettverkslagsadresser, for eksempel FTP eller NTP .
IPv6 spesifiserer et nytt pakkeformat, designet for å minimere pakkehodebehandling. Fordi IPv4- og IPv6-pakkehodene er vesentlig forskjellige, er de to protokollene ikke interoperable.
Noen av de mest relevante endringene fra IPv4 til IPv6 er:
Designernes interesse var at lengre adresser ville tillate bedre hierarkisk, systematisk og definitiv levering av adresser og effektiv ruteaggregering. Med IPv4 ble komplekse Classless Interdomain Routing (CIDR)-teknikker distribuert for å bedre utnytte den lille adresseplassen. Innsatsen som kreves for å omnummerere et eksisterende nettverk med forskjellige ruteprefikser er svært stor, som diskutert i RFC 2071 og RFC 2072 . Med IPv6 er det imidlertid i prinsippet mulig å omnummerere hele nettverket ved å endre prefikset som annonseres av noen få rutere , siden nodeidentifikatorene (de minst signifikante 64 bitene av adressen) kan konfigureres uavhengig av en vertsnode. .
Størrelsen på et undernett i IPv6 er 2 64 (64-bits nettverksmaske), kvadratet på størrelsen på hele IPv4 Internett. Dermed vil bruksraten for adresserom sannsynligvis være lavere i IPv6, men nettverksadministrasjon og ruting vil være mer effektiv på grunn av designbeslutninger som ligger i større subnettstørrelser og hierarkisk ruteaggregering.
IPv6-noder kan automatisk konfigurere seg selv når de er koblet til et IPv6-rutet nettverk ved hjelp av ICMPv6 - ruteroppdagelsesmeldinger . Første gang de er koblet til et nettverk, sender noden en lenkelokal " ruteranmodning " (RS: Router Solicitation ) ved å bruke multicast som ber om konfigurasjonsparametere; og hvis rutere er konfigurert til å gjøre det, vil de svare på denne forespørselen med en "ruterannonse" ( RA ) som inneholder konfigurasjonsparametere for nettverkslag.
Hvis autokonfigurasjon av tilstandsløs adresse ikke er passende for en applikasjon, kan Dynamic Host Configuration Protocol for IPv6 ( DHCPv6 ) brukes, eller noder kan konfigureres statisk.
Multicast, muligheten til å sende en enkelt pakke til flere destinasjoner, er en del av IPv6-grunnspesifikasjonen. Dette er forskjellig fra IPv4, hvor det er valgfritt (selv om det vanligvis er implementert).
IPv6 implementerer ikke kringkasting , som er muligheten til å sende en pakke til alle noder på den tilkoblede koblingen. Den samme effekten kan oppnås ved å sende en pakke til den link-lokale multicast-gruppen alle verter . Derfor er det ikke noe konsept for en kringkastingsadresse, og derfor anses den høyeste adressen i nettverket (kringkastingsadressen i et IPv4-nettverk) som en normal adresse i IPv6.
Mange miljøer har imidlertid ikke nettverkene sine konfigurert til å rute multicast-pakker, så i disse vil det være mulig å gjøre " multicasting " i det lokale nettverket, men ikke nødvendigvis globalt.
IPv6 multicast deler vanlige protokoller og funksjoner med IPv4, men inkluderer også endringer og forbedringer. Selv når en organisasjon er tildelt det minste av IPv6 globale rutingprefikser, gis den også muligheten til å bruke en av de 4,2 milliarder kildespesifikke ruterbare IPv6 multicast-gruppene for å tildele for intra-domene eller inter-domene multicast-applikasjoner. domener ( RFC 3306 ). I IPv4 var det svært vanskelig for en organisasjon å få til og med en enkelt rutebar multicast-gruppe på tvers av domener, og implementeringen av løsninger på tvers av domene var utdatert ( RFC 2908 ). IPv6 støtter også nye multicast-løsninger, inkludert Embedded Rendezvous Point ( RFC 3956 ), som forenkler utrullingen av løsninger på tvers av domene.
Internet Protocol Security ( IPsec ), protokollen for IP-kryptering og autentisering, er en integrert del av basisprotokollen i IPv6. IPsec-støtte er obligatorisk i IPv6; i motsetning til IPv4, hvor det er valgfritt eller ble lagt til senere (men vanligvis implementert). Imidlertid er IPsec for øyeblikket ikke i vanlig bruk bortsett fra for å sikre IPv6 BGP-trafikk mellom rutere, selv om den også kan brukes i OSPFv3- og IPv6-mobilitet .
Ulike forenklinger ble gjort i pakkehodet så vel som i pakkevideresendingsprosessen for å gjøre pakkebehandlingen enklere og dermed mer effektiv. Spesifikk:
I motsetning til Mobile IPv4 (MIPv4), unngår Mobile IPv6 (MIPv6) triangulær ruting og er derfor like effektiv som vanlig IPv6. IPv6-rutere kan også støtte Network Mobility (NEMO ) ( RFC 3963 ), som lar hele nettverk flytte til nye rutertilkoblingspunkter uten omnummerering. Imidlertid er verken MIPv6 eller MIPv4 eller NEMO mye spredt eller brukt i dag, så denne fordelen er ganske teoretisk.
Endringer i måten IP-header-alternativer er kodet på, tillater løsere grenser for alternativlengde, og mer fleksibilitet til å introdusere nye alternativer i fremtiden.
IPv4 begrenser pakker til 64 KiB nyttelast . IPv6 har valgfri støtte for at pakker overskrider denne grensen, såkalte jumbogrammer , som kan være opptil 4 GiB . Bruken av jumbogrammer kan i stor grad forbedre effektiviteten i høye MTU-nettverk. Bruken av jumbogrammer er angitt i den valgfrie overskriften Jumbo nyttelastalternativ .
Den største endringen fra IPv4 til IPv6 er lengden på nettverksadresser. IPv6-adresser, definert i RFC 2373 og RFC 2374 , men omdefinert i april 2003 i RFC 3513 , er 128 biter; dette tilsvarer 32 heksadesimale sifre , som vanligvis brukes til å skrive IPv6-adresser, som beskrevet i neste avsnitt.
Antall mulige IPv6-adresser er 2128 ≈ 3,4 x 10 38 . Dette tallet kan også representeres som 16 32 , med 32 heksadesimale sifre, som hver kan ha 16 verdier (se kombinatorikk ).
I mange tilfeller består IPv6-adresser av to logiske deler: et 64-bits prefiks og en annen 64-bits del som tilsvarer grensesnittidentifikatoren, som nesten alltid genereres automatisk fra MAC -adressen til grensesnittet den er koblet til adresse tildelt.
I følge RFC 5952 skrives IPv6-adresser, 128 bit lange, som åtte grupper med fire heksadesimale sifre . For eksempel,
2001:0db8:85a3:08d3:1319:8a2e:0370:7334er en gyldig IPv6-adresse.
En gruppe på fire sifre kan komprimeres hvis den er null (det vil si at den tar verdien "0000"). For eksempel,
2001:0db8:85a3:0000:1319:8a2e:0370:7344 ---- 2001:0db8:85a3::1319:8a2e:0370:7344Etter denne regelen, hvis mer enn to påfølgende grupper er null, kan de også komprimeres som " ::". Hvis adressen har mer enn en rekke påfølgende nullgrupper, er komprimering kun tillatt på én av dem. Følgende er derfor mulige representasjoner av samme adresse:
2001:0DB8:0000:0000:0000:0000:1428:57ab 2001:0DB8:0000:0000:0000::1428:57ab 2001:0DB8:0:0:0:0:1428:57ab 2001:0DB8:0::0:1428:57ab 2001:0DB8::1428:57aber alle gyldige og betyr det samme, men
2001::25de::kade ---er ugyldig fordi det ikke er klart hvor mange nullgrupper det er på hver side.
Innledende nuller i en gruppe kan også utelates:
2001:0DB8:02de::0e13 2001:DB8:2de::e13Når det som ønskes er å identifisere et differensierbart adresseområde ved hjelp av de første bitene, legges dette antallet bits til etter skråstreken "/". For eksempel:
2001:0DB8::1428:57AB/96 vil tilsvare 2001:0DB8:: 2001:0DB8::874B:2B34/96 vil tilsvare 2001:0DB8:: og selvfølgelig også 2001:0DB8::1428:57AB/96' IPv4 - adresser som er kompatible med IPv6-adresser' er en spesiell klasse med IPv6-adresser. De er IPv6-adresser der de første 96 bitene er null, mens de siste 32 bitene representerer en IPv4-adresse.
IPv6- overgangsmekanismer bruker ikke lenger kompatible IPv4-adresser. Den eneste påminnelsen om bruken av denne typen adresser er i representasjonen av IPv4-adresser i en tabell med medlemmer av fast størrelse som også må kunne lagre IPv6-adresser.
Det skal bemerkes at den udefinerte IPv6-adressen :: og tilbakekoblings - IPv6 -adressen ::1 faktisk ikke er IPv4-kompatible adresser, til tross for at de er inkludert i IPv6 ::/96-adresseområdet.
For eksempel, i en innebygd IPv4-adresse, kan de siste 32 bitene skrives med desimal, slik:
::ffff:192.168.89.9 ::ffff:c0a8:5909Ikke å forveksle med:
:: 192.168.89.9 ::c0a8:5909Formatet ::ffff:1.2.3.4 kalles en " tilordnet IPv4-adresse ", og formatet ::1.2.3.4- kompatibel IPv4-adresse .
IPv4 - adresser kan enkelt konverteres til IPv6-format. For eksempel, hvis IPv4-desimaladressen er 135.75.43.52 (i hex, 0x874B2B34), kan den konverteres til 0000:0000:0000:0000:0000:0000:874B:2B34 eller ::B874B:2. Så man kan bruke den blandede IPv4-kompatible adressenotasjonen , i så fall bør adressen være ::135.75.43.52. Denne typen kompatibel IPv4 -adresse brukes knapt i praksis, selv om standardene ikke har erklært den foreldet.
IPv6-adressetyper kan identifiseres ved å ta hensyn til områdene definert av de første bitene av hver adresse.
::/128 Helt-null-adressen brukes til å indikere ingen adresse, og ingen node er tildelt. :: 1/128 Loopback -adressen er en adresse som en node kan bruke til å sende pakker til seg selv (tilsvarer 127.0.0.1 i IPv4). Den kan ikke tilordnes til noe fysisk grensesnitt. ::1.2.3.4/96 Den IPv4-kompatible adressen brukes som en overgangsmekanisme i doble IPv4/IPv6-nettverk. Det er en mekanisme som ikke brukes. ::ffff:0:0/96 " IPv4-tilordnet adresse " brukes som en overgangsmekanisme i doble terminaler. fe80::/10 Koblingen - lokalt prefiks spesifiserer at adressen kun er gyldig på den lokale fysiske lenken. fec0:: " nettsted - lokalt prefiks " spesifiserer at adressen kun er gyldig innenfor en lokal organisasjon. RFC 3879 gjorde den foreldet, og sa at fremtidige systemer ikke må implementere noen støtte for denne spesielle adressetypen. De må erstattes av lokale IPv6 Unicast-adresser. fc00::/7 Det unike lokale adresseprefikset . _ _ Det er definert av RFC 4193 . Den brukes i stedet for stedslokale adresser .ff00::/8
Multicast-prefikset. Den brukes for multicast- adresser .Det bør bemerkes at kringkastingsadresser ikke eksisterer i IPv6 , selv om funksjonaliteten de gir kan emuleres ved å bruke multicast -adressen FF01 ::1/128 , kalt "alle noder " .
En pakke i IPv6 består hovedsakelig av to deler: headeren (som har en fast del og en annen med alternativene) og nyttelasten (dataene).
De første 40 bytene (320 biter ) er pakkeoverskriften og inneholder følgende felt:
| Byte Offset | 0 | 1 | to | 3 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| litt offset | 0 | 1 | to | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | elleve | 12 | 1. 3 | 14 | femten | 16 | 17 | 18 | 19 | tjue | tjueen | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |
| 0 | 0 | Versjon | trafikkklasse | flyt tag | |||||||||||||||||||||||||||||
| 4 | 32 | Datafeltlengde | neste overskrift | hoppgrense | |||||||||||||||||||||||||||||
| 8 | 64 | opprinnelsesadresse | |||||||||||||||||||||||||||||||
| C | 96 | ||||||||||||||||||||||||||||||||
| 10 | 128 | ||||||||||||||||||||||||||||||||
| 14 | 160 | ||||||||||||||||||||||||||||||||
| 18 | 192 | Ankomstadresse | |||||||||||||||||||||||||||||||
| 1 C | 224 | ||||||||||||||||||||||||||||||||
| tjue | 256 | ||||||||||||||||||||||||||||||||
| 24 | 288 | ||||||||||||||||||||||||||||||||
Det er to litt forskjellige versjoner av IPv6. Den nå avviklede innledende versjonen, beskrevet i RFC 1883 , skiller seg fra den nåværende foreslåtte versjonen av standarden, beskrevet i RFC 2460 , på to områder: det er 4 biter som har blitt omtilordnet fra " flytetikett " til "trafikkklasse" ( trafikk ). klasse ). Resten av forskjellene er små.
I IPv6 utføres fragmentering kun ved kildenoden til pakken, i motsetning til i IPv4, hvor rutere kan fragmentere en pakke. I IPv6 forsvinner også alternativene fra standardoverskriften og spesifiseres av feltet "Neste overskrift" , tilsvarende funksjonalitet i IPv4 som protokollfeltet. Et eksempel: i IPv4 vil man legge til alternativet "rute fikset fra kilde" ( Strict Source and Record Routing ) til IPv4-headeren hvis man ønsker å tvinge en bestemt rute for pakken, men i IPv6 vil man endre "Next Header" feltet som indikerer at det kommer en ruteoverskrift. Rutinghodet kan da spesifisere ytterligere rutinginformasjon for pakken, og indikere at for eksempel TCP-hodet vil være neste. Denne prosedyren er analog med AH og ESP i IPsec for IPv4 (som også gjelder for IPv6, selvfølgelig).
Bruken av et fleksibelt format for valgfrie utvidelseshoder er en innovativ idé som gjør det mulig å legge til inkrementell funksjonalitet. Denne utformingen gir stor effektivitet og fleksibilitet siden de kan defineres når som helst etter behov mellom den faste overskriften og nyttelasten.
Så langt er det 8 typer utvidelseshoder, der de faste overskriftene og de valgfrie utvidelseshodene inkluderer det neste overskriftsfeltet som identifiserer typen utvidelseshoder som kommer neste eller protokollidentifikatoren på øvre nivå. Utvidelseshodene blir deretter lenket ved hjelp av det neste overskriftsfeltet som vises både i den faste overskriften og i hver av de nevnte utvidelseshodene. Som et resultat av sekvensen ovenfor, må disse utvidelseshodene behandles i samme rekkefølge som de vises i datagrammet. Hovedoverskriften, i motsetning til overskriften til IPv4-versjonen, har en fast størrelse på 40 oktetter. Spesifikt for å tildele dem for intra-domene eller inter-domene multicast-applikasjoner ( RFC 3306 ). I IPv4 var det veldig vanskelig for en organisasjon som dette.
Alle eller deler av disse utvidelseshodene må være plassert i datagrammet i den angitte rekkefølgen:
| Utvidelseshode | Fyr | Størrelse | Beskrivelse | RFC |
|---|---|---|---|---|
| Hop - By-Hop- alternativer | 0 | variabel | Inneholder data som må undersøkes av hver node langs banen til en pakkevideresending | RFC 2460 |
| Ruting _ _ | 43 | variabel | Metoder for å spesifisere hvordan et datagram skal rutes. (Brukes med mobil IPv6 ) | RFC 2460 , RFC 6275 , RFC 5095 |
| Fragmentoverskrift ( Fragment ) | 44 | 64 bit | Inneholder parametere for datagramfragmentering | RFC 2460 |
| Autentiseringshode ( AH ) | 51 | variabel | Inneholder informasjon for å bekrefte autentiseringen av de fleste pakkedataene (se IPsec ) | RFC 4302 |
| Encapsulating Security Payload (ESP) | femti | variabel | Den bærer kryptert informasjon for sikker kommunikasjon (se IPsec ) | RFC 4303 |
| Alternativer for destinasjonen ( Destinasjonsalternativer ) | 60 | variabel | Informasjon som bare må undersøkes av destinasjonsnodene til pakken | RFC 2460 |
| Ingen neste overskrift | 59 | tømme | Indikerer at det ikke er flere overskrifter | RFC 2463 |
Hver utvidelsesoverskrift må vises maksimalt én gang, bortsett fra overskriften for destinasjonsalternativet, som kan vises maksimalt to ganger, én gang før ruteoverskriften og én gang før overskriften på det øvre laget.
Pakkenyttelasten kan være opptil 64 KB i størrelse i standardmodus, eller større med et jumbonyttelastalternativ i den valgfrie Hop-By-Hop-overskriften.
Fragmentering håndteres kun hos avsenderverten i IPv6: rutere fragmenterer aldri en pakke, og verter forventes å bruke Path MTU discovery .
IPv6-adresser er representert i Domain Name System (DNS) av AAAA -poster (også kalt quad-A- poster , fordi de er fire ganger lengden på IPv4 A-poster).
AAAA-konseptet var ett av to forslag på det tidspunktet IPv6-arkitekturen ble designet. Det andre forslaget brukte A6 -poster og andre innovasjoner som bitstrengetiketter og DNAME- poster .
Mens ideen om AAAA er en enkel generalisering av IPv4 DNS, var ideen om A6 en revisjon og finjustering av DNS for å være mer generisk, derav kompleksiteten.
RFC 3363 anbefaler bruk av AAAA-poster inntil bruken av A6-poster er grundig testet og studert. RFC 3364 sammenligner fordelene og ulempene ved hver posttype .
Stilt overfor utmattelsen av IPv4-adresser og problemene dette allerede forårsaker, spesielt i fremvoksende asiatiske land som India eller Kina, har endringen til IPv6 allerede begynt. Begge protokollene forventes å eksistere side om side i ett år, selv om det antas at den verdensomspennende og totale implementeringen av IPv6 på Internett vil bli en realitet mot slutten av 2012, gitt hastigheten som IPv4-adresser blir brukt opp med. Nettverket vil ikke kunne vare stort lenger uten endringen, og dersom det ikke gjennomføres snart kan konsekvensene bli svært alvorlige. Det er en rekke mekanismer som vil tillate sameksistens og progressiv migrering av både nettverk og brukerutstyr . Generelt kan overgangsmekanismer klassifiseres i tre grupper:
"Dual-stack" refererer til en "dual-stack IP-level solution" ( RFC 4213 ), som implementerer både IPv4- og IPv6-protokollstablene på hver node på nettverket. Hver dual-stack node på nettverket vil ha to nettverksadresser, en IPv4 og en IPv6.
"Tunneler" lar deg koble til IPv6-nettverk ved å "hoppe" over IPv4-nettverk. Disse tunnelene fungerer ved å kapsle inn IPv6-pakker i IPv4-pakker med protokollnummer 41 som neste IP-lag, derav navnet proto-41 . På denne måten kan IPv6-pakker sendes over en IPv4-infrastruktur. Det er mange tunnelteknologier tilgjengelig. Hovedforskjellen ligger i metoden som de innkapslende nodene bruker for å bestemme adressen ved utgangen av tunnelen.
Oversettelse"Oversettelsen" er nødvendig når en node som kun støtter IPv4 prøver å kommunisere med en node som kun støtter IPv6. Oversettelsesmekanismene kan deles inn i to grupper basert på om tilstandsinformasjonen er lagret eller ikke:
Flere av mekanismene nevnt ovenfor er implementert for å få fart på utrullingen av IPv6. De forskjellige Internett-kontrolltjenestene har innlemmet støtte for IPv6, så vel som kontrollerene for domenene på overordnet nivå (eller TLD, på engelsk). Det dukker også opp som en ny idé for å forbedre utvidelsen som dekker adressering av mobile enheter.
For å estimere antallet IP-adresser som IPV6 kan gi, er det nok å si at denne protokollen kan tildele et tall nær 670 milliarder adresser for hver kvadratmillimeter av jordoverflaten, noe som vil gjøre det mulig for hver person å tildele en unik IP til hver av enhetene dine. En annen fordel med å bruke IPV6 er sikkerhetsnivåene, siden det inkluderer informasjonskrypteringsprosesser og verifisering av ektheten til opprinnelsen innenfor spesifikasjonene; IPV6 tillater bruk av Jumbograms (større datapakker, opptil 64 bits). Innenfor fordelene som IPV6 tilbyr oss, er også Plug and play -mekanismen inkludert , og forenkler dermed umiddelbar tilkobling av enheter til nettverket, takket være det faktum at konfigurasjonen utføres automatisk, tillater Plug and play at når en enhet kobles til et nettverk med IPV6 er tildelt en eller flere adresser, noe som letter nettverksadministrasjonen; IPV6 ble designet og utviklet for å være skalerbar, slik at forbedringer kan gjøres i fremtiden. Ved å inkorporere IPv6 med et stort antall adresser, vil det ikke være nødvendig å bruke NAT Network Address Translation , og dens nye Plug and Play-, sikkerhet- og QoS-funksjoner vil bety bedre taleforbindelser.
Behovet for å utvide permanent støtte krever en IPv4 -adresse eller en form for NAT Network Address Translation på gateway-ruterne. På den annen side, på arkitektonisk nivå, er IPv6-adresser vanskeligere å huske. De fleste nettverk er IPv4 , så full implementering av IPv6 vil være svært kostbart og vil ta lang tid.I mellomtiden kreves implementering av overgangsmekanismer for samspillet mellom de to nettverkene. Inkludert dette er det fortsatt lite teknisk kunnskap om rutingprotokoller når det gjelder organisasjoner eller lokale ISPer i visse regioner.
Selv om IPv6 ble opprettet med behov for å øke antall adresser, siden IPv4-adresser begynte å gå tom, tilpasser den seg ikke særlig godt. Fra begynnelsen gikk ikke tilpasningen hans i det tempoet som var forventet og ønsket. Det er sant at det har vært perioder da tilpasningen vokste eksponentielt, men disse periodene var kortvarige og den ble raskt redusert.
Mange leverandører, selskaper og brukere fullfører ikke steget til IPv6 og forblir i IPv4, på grunn av inkompatibiliteten mellom de to. Andre årsaker til fraværet av IPv6 er gjenbruk av IPv4-adresser, enkelte adresser som ikke brukes selges til bedrifter og organisasjoner som trenger dem. På grunn av dette har tilpasningen avtatt mye, og den vil kanskje aldri bli fullført.
Den amerikanske regjeringen ga mandat til å distribuere IPv6 av alle sine føderale byråer i 2008 . [ 13 ]
I følge BitTorrent - administratorer i 2017 representerte IPv6-tilkoblinger 9,67 % av totalen. [ 14 ] Implementeringen av IPv6 i Spania i juni 2019 er 2,28 % [ referanse nødvendig ] . I følge Google var adopsjonen i 2020 2,96 %. [ 15 ] Dette tallet fortsetter å vokse, men ikke i samme hastighet som forventet for noen år siden.
Denne adopsjonen er ikke veldig regelmessig. De mest tilpassede områdene er Amerika, noen europeiske land, Sør-Asia og Australia. [ referanse nødvendig ]