Overgang fra IPv4 til IPv6

Den overgangen fra IPv4 til IPv6 er en prosess som tar sikte på å gradvis erstatte IPv4 med IPv6Internett .

Faser av overgangen

IPv4- og IPv6-adresser er ikke kompatible, så kommunikasjon mellom en vert med bare IPv6-adresser og en vert med bare IPv4-adresser er et problem.

To tilnærminger er mulig for å muliggjøre kommunikasjon:

Protokolloversettelse kan finne sted på flere nivåer: nettverk (NAT-PT, NAT64), transport (TRT, RFC 3142 ) eller applikasjon (DNS-ALG, RFC 2766 ). Selv om det kan brukes til å gi tilkobling for et begrenset antall verter eller applikasjoner, står oversettelse overfor stordriftsproblemer ( RFC 4966 ).

I dual-stack- tilnærmingen er den første fasen av overgangen å utstyre IPv4-verter, og spesielt servere, med både IPv6- og IPv4-adresser, slik at de kan kommunisere med både IPv4- og IPv6-verter. De øyene IPv6 er forbundet med IPv6 over IPv4 tunneler.

Den andre fasen ser generaliseringen av dobbeltstakken til det meste av Internett. Bruk av IPv6 over IPv4-tunneler er derfor mindre og mindre nødvendig.

En siste fase ser på at IPv4 gradvis blir forlatt på Internett. Noen private nettverk fortsetter å bruke den, ettersom Internett-tilkobling ikke er nødvendig.

Den første fasen av denne overgangen er i gang siden begynnelsen av XXI th  århundre, er IPv6 utrulling tregere enn opprinnelig forventet. Siden de to første fasene ikke bidrar til å redusere etterspørselen etter IPv4-adresser, fører den forestående utmattelsen av offentlige IPv4-adresser til utvikling av mekanismer for deling av adresser.

Overgang for individuelle verter og bedriftsnettverk

Den enkleste måten å få tilgang til IPv6 er når du abonnerer på å velge en ISP som tilbyr IPv6 naturlig , det vil si uten å ty til tunneler.

Ellers, og i løpet av en overgangsfase, er det mulig å få IPv6-tilkobling via en tunnel. IPv6-pakkene blir deretter innkapslet i IPv4-pakker, som kan krysse Internett-leverandørens nettverk til en server som støtter IPv6 og IPv4, og hvor de blir avkapslet. Bruken av tunneler, og derfor av et overleggsnettverk , kan skade ytelsen. Den RFC 4213 beskriver transmisjonsmekanismer.

Eksplisitt konfigurerte tunneler

Flere tjenester av typen "  tunnelmegler  " er tilgjengelig, som vanligvis krever registrering. Vi kan sitere SixXS, Freenet6 eller Hurricane Electric.

Protokollene som brukes kan være:

Den Tunnel Setup Protocol ( RFC 5572 ) letter tunnel opprettelse og muliggjør bevegelighet og autentisering. Den Tunnel Information and Control Protocol , som brukes av AICCU  (i) , automatiserer opprettelse av tunneler.

Automatiske tunneler Protokolloversettelse i nettverketProtokolloversettelse i verten

Det er ikke alltid mulig å endre applikasjoner raskt for å gjøre dem kompatible med IPv6, når kildekoden ikke er tilgjengelig, for eksempel.

Følgende teknikker tillater at et IPv4-program fungerer på et dual stack-system og kommuniserer med IPv6-klienter. Teknikkene brukes sammen med DNS- oppløseren for å tilordne fiktive IPv4-adresser automatisk og matche dem til IPv6-adressene som faktisk brukes i nettverket.

Søknadsportaler

Det er mulig å bruke servere som har en dobbel stabel og som fungerer som en applikasjonsnivå gateway (ALG), en web proxy server for eksempel.

NAT64 og DNS64

Den RFC 6146 og RFC 6147 beskriver en protokoll oversetter som tillater IPv6 verter for å få tilgang IPv4-servere.

DNS64 utfører domenenavnemanipulering og gir, som svar på klienten, en IPv6 (AAAA) -adresse til et vertsnavn som har en IPv4 (A) -adresse, men ingen IPv6-adresse. Dette er bygget med det reserverte prefikset 64: ff9b :: / 96 som vi legger til de 32 bitene av IPv4-adressen (andre metoder er mulige, så lenge innkapslingen av IPv4-adressen er konsistent mellom NAT64 og DNS64). Når NAT64 mottar en forbindelse med en adresse av type 64: ff9b :: / 96 som destinasjon, oppretter den en oppføring i en tilstandstabell og tilordner et utgangsportnummer til denne strømmen (portoversettelse) eller en adresse IPv4 fra en gruppe (adresseoversettelse) som vil bli tatt som kilden til IPv4-strømmen. NAT64 fungerer med TCP, UDP og ICMP.

NAT64 og DNS64 trenger ikke å kommunisere. Hvis klienten bruker DNSSEC og validerer selve responsen, kan ikke DNS64 fungere skikkelig. På samme måte, hvis IPsecs AH er aktiv og beskytter toppteksten, vil NAT64 ikke fungere ordentlig.

464XLAT ( RFC  6877) er en teknikk for å modifisere operativsystemet slik at applikasjoner tilsynelatende har en fungerende IPv4-adresse, mens adresseoversettelse er aktiv på en vert som bare har IPv6-adresser.

Overgang for operatører og tilgangsleverandører

I møte med utmattelsen av IPv4-adresser og behovet for å tilby IPv6-tjenester til sine kunder, tilpasser operatørene IP-nettverket. Hovedproblemene med disse er som følger:

Det er en rekke scenarier som studeres og som er gjenstand for internettutkast. Disse varierer i progresjonen til distribusjonen og holdbarheten til løsningen.

Carrier Grade NAT

Bruken av storskala NAT ( Carrier Grade NAT , Large Scale NAT eller NAT44) overvinner problemet med manglende IPv4-adresse å tilordne til klienter. Den består i å distribuere private adresser til gatewayen til nye kunder i stedet for en offentlig adresse og oversette disse adressene til offentlige adresser til Internett.

CGN bruker portoversettelse, så en enkelt offentlig adresse brukes av mange klienter. Et antall TCP- og UDP- porter er reservert i de offentlige adressene for hver av klientene. Med tanke på at det er 65535 portnumre, og forutsatt at en offentlig adresse brukes av 100 klienter, har hver klient omtrent 650 portnumre, det vil si så mange samtidige forbindelser som mulig. Det er ingen enighet om minimum antall porter som skal tildeles hver klient. Noen applikasjoner som oppretter mange tilkoblinger parallelt, kan påvirkes negativt hvis dette tallet er for lavt.

Selv om det i stor grad reduserer behovet for en IPv4-adresse, er CGN ikke et overgangssystem i seg selv, men brukes i kombinasjon med andre tilnærminger for å sikre fortsatt tilkobling til IPv4 Internett.

CGN for overgangen til IPv6

CGN kan brukes til en jevn overgang til IPv6 ved å kapsle IPv6-trafikk i en IPv4-tunnel, i en ordning som ligner på 6..

A + P

A + P er en metode som gjør det mulig å bruke et visst antall biter av TCP- eller UDP-portnummeret til ruting. Det er beskrevet i RFC  6346.

Flere CPE-er kan derfor bruke samme IP-adresse, men med forskjellige portområder. Routing til CPE bruker ikke bare IP-adressen, men også flere biter av portnummeret.

I likhet med CGN adresserer A + P IP-adresseutmattelse, men er ikke en metode for overgang til IPv6.

NAT-PT ( Protocol Translation ), NAT64, NAT46 eller AFT ( Address Family Translation ) kan oversette IPv4 og IPv6. Hvis den er statsløs, kalles den også IVI.

Dette gjør at IPv6-adresser kan tildeles klienter samtidig som tilkoblingen til IPv4 Internett bevares.

Imidlertid må det være en måte å knytte visse IPv4- og IPv6-adresser kjent til NAT64, for eksempel via Domain Name System .

NAT-PT er tilknyttet DNS i RFC 2766, men har vært foreldet av RFC 4966 på grunn av problemer.

Sjette

6rd (rd for rask distribusjon , RFC 5569 ) er en variant av 6to4 som involverer Internett-leverandøren i stedet for Internett-gateways. Forvalget 2002 :: / 16 reservert for 6to4 brukes ikke, men IPv6-adresseplassen til tilgangsleverandøren. Klientens ruter ( hjemmegateway , HG) innkapsler IPv6-trafikken i en tunnel som er bestemt for den velkjente adressen til ISPs 6. gateway.

Den kan brukes i kombinasjon med CGN.

6. ble distribuert av leverandøren Free i 2007.

Dual-Stack Lite

Dual-Stack Lite er en tilnærming der ISP-nettverket opprinnelig migreres til IPv6. Kundens gateway IPv4-trafikk er innkapslet i en IPv6-tunnel kalt softwire og slutter ved ISP's DS-Lite gateway. Dette fungerer som CGN for IPv4. Dette eliminerer behovet for å tildele offentlige IPv4-adresser til kundereutere.

MPLS

VPLS

Ethernet-rammer kan transporteres på nivå 2 i et MPLS-nettverk.

6PE

I et MPLS- nettverk gjør 6PE-teknikken ( RFC 4798 ) det mulig å koble IPv6-klienter til PE-rutere, samtidig som kjernen i nettverket (P) holdes i IPv4.

Kjernereuterne P utveksler etiketter og har ingen kunnskap om IPv6. MPLS-kontrollplanet forblir i IPv4 (sammenkoblingene mellom MPLS- ruterne , IGP , LDP og / eller RSVP og transport av MP-BGP ).

IPv6-prefikser utveksles via MP-BGP mellom 6PE-ene, neste hop er en IPv6-adressekarting av IPv4 av form :: ffff: 0: 0/96 etterfulgt av de 32 bitene av IPv4-adressen til PE. Prefiksene er imidlertid inkludert i GRF og ikke i en IPv6 VPRN.

Den nest siste hoppoppingen (PHP) på den siste P-ruteren oppdager IPv6-pakken før den sendes til EP Eler (egress Label Edge Router), selv om ruteren P ikke forventes å ha kunnskap om IPv6. Derfor blir det i 6PE alltid lagt til en ekstra etikett (for eksempel Explicit-Null IPv6-etiketten) av PE iLER-ruteren (ingress Label Edge Router), slik at Ultimate Hop Popping (UHP) alltid brukes.

Denne teknologien er mer effektiv enn en IPv6 over IPv4-tunnel og gir mulighet for gradvis distribusjon. Mangelen på en faktisk IPv6 VPRN kan imidlertid være en begrensning.

6VPE

6VPE ( RFC 4659 ) tillater oppretting av en ekte IPv6 VPRN og er den enkle funksjonelle IPv6-ekvivalenten til IPv4 VPRN: en L3VPN MPLS IPv6.



4. plass

4. gir operatører muligheten til å distribuere domener der protokollen som brukes bare er IPv6, mens de opprettholder en resttjeneste for IPv4.

For å takle mangelen på IPv4-adresser, kan offentlige adresser deles mellom flere brukersteder, som hver er reservert en delmengde av portene på transportnivå (UDP, TCP, etc.). Som i 6. , er operasjonen statsløs (carrier gateways, på grensene mellom IPv4 Internet og IPv6-bare domener, trenger ikke å opprettholde tilstander som er spesifikke for bestemte brukere).

Spesifikasjonen av 4. er gjenstand for RFC 7600 . Det er i eksperimentkategorien til IETF .

Andre tjenester

Distribusjonen av IPv6 i en operatørs nettverk innebærer også endringer:

I Frankrike

I Frankrike utstedte ARCEP en rapport om overgangen fra IPv4 til IPv6 ioktober 2016.

Denne rapporten adresserer følgende spørsmål gjennom handlinger: Statens forpliktelse til å gjøre alle statlige nettsteder og elektroniske tjenester tilgjengelige i IPv6, undervisning i IPv6, etablering av utvekslinger om god praksis og erfaringer, koordinering av partene ved publisering av intensjonene om aktørene i overgangen, informasjonen til brukeren om terminalenes holdbarhet og dysfunksjonene knyttet til rasjoneringsmekanismer for IPv4-adresser og forberedelse av slutten av IPv4.

I 2016 førte mangelen på IPv4-adresser til at det eksisterte et ugjennomsiktig marked der IPv4-adresser handles til en pris på rundt € 10 per adresse.

Den RIPE-NCC på som Frankrike avhenger forutser globale slutten av tilgjengeligheten av IPv4-adresser innen 2021. Men mange spillere allerede fratatt evnen til å tilegne seg nye IPv4-adresser.

I Frankrike implementeres løsninger, for eksempel gjennom NAT, men disse oppdateringene har forskjellige ulemper: funksjonsfeil i visse applikasjoner, mangel på motstandskraft, spesielt implementeringskostnader og vedlikehold.

I Frankrike var andelen autoritative DNS- servere på “ .fr  ” -domener  som er IPv6-kompatible, rundt 63% ved utgangen av 2014.

AFNIC- servere brukes bare opptil 18% til IPv6-transport.

En innholdsleverandør ser bare 10,5% av brukere i Frankrike som bruker IPv6-teknologi fra Googles synspunkt, og mellom 10 og 12 fra Akamais synspunkt , på tidspunktet for rapporten.

For Cisco er 50% av onlineinnholdet tilgjengelig på IPv6, men noen offentlige nettsteder med høyere trafikk kan ikke vises i IPv6, så vel som noen offentlige tjenestesider, som de som brukes til helseforsikring. Eller til familietillatelsesfondet.

Ifølge Cisco er andelen transittnettverk som brukes av tilgangs- og innholdsleverandører i Frankrike, rundt 70% for IPv6-kompatibilitet.

ARCEP vurderer også å opprette et nasjonalt observatorium som kan publisere en årlig lov om utviklingen av disse beregningene.

Internasjonal sammenligning

Kilde Arcep.


Kilde Arcep.
Kilde Arcep.

Merknader og referanser

  1. SixXS
  2. Freenet6
  3. Hurricane Electric
  4. (in) Christian Huitema <[email protected]> , "  An Anycast Prefix for 6to4 Relay Routers  "tools.ietf.org (åpnet 12. mars 2018 )
  5. (i) Carpenter, Brian og Trøan, Ole , "  avvikler Anycast Prefix for 6to4 Rele Rutere  "tools.ietf.org (åpnes 12 mars 2018 )
  6. (in) Kidney, Rick van and Steffann, LSU , "  A Comparison of IPv6-over-IPv4 tunnel Mechanisms  "tools.ietf.org (åpnet 12. mars 2018 )
  7. miredo
  8. Dual Stack IPv6 Dominant Transition Mechanism (DSTM) Internet Draft, 2005
  9. (in) Forespørsel om kommentarer nr .  6877 .
  10. En inkrementell bærergrad NAT (CGN) for IPv6-overgang
  11. (i) Randy Bush, "  The Address more Port (A + P) Approach to the IPv4 Address Mangel  " Forespørsel om kommentarer nr .  6346,august 2011.
  12. Dual-stack lite bredbåndsdistribusjoner gir IPv4 utmattelse
  13. (in) Farinacci, Dino og Fedorkow, Guy , "  MPLS Label Stack Encoding  "tools.ietf.org (åpnet 12. mars 2018 )
  14. (in) Horse, Pierrick og Krishnan Ram , "  Shahram Davari PMC-Sierra Inc.  "tools.ietf.org (åpnet 12. mars 2018 )
  15. (in) "  6PE FAQ: Hvorfor bruker 6PE to MPLS-etiketter i dataplanet?  » , På Cisco (åpnet 13. mars 2018 )
  16. IPv6 - En tjenesteleverandørvisning i fremrykkende MPLS-nettverk , Internet Protocol Journal, juni 2005
  17. (in) Rosen, Eric C. og Rekhter, Yakov , "  BGP / MPLS IP Virtual Private Networks (VPNs)  "tools.ietf.org (åpnet 12. mars 2018 )
  18. Arcep ønsker å gi IPv6 et løft Christophe Lagane, silicon.fr, 3. oktober 2016
  19. "  Rapport til regjeringen om tilstanden for implementering av IPv6-protokollen i Frankrike  " [PDF] ,28. juni 2016( ISSN  2258-3106 , åpnet 29. desember 2017 )

Eksterne linker