Přechod z IPv4 na IPv6

Přechod z IPv4 na IPv6 je proces, který má za cíl postupně nahradit IPv4 s IPv6 na internetu .

Fáze přechodu

Adresy IPv4 a IPv6 nejsou kompatibilní, takže komunikace mezi hostitelem, který má pouze adresy IPv6, a hostitelem, který má pouze adresy IPv4, je problém.

Pro umožnění komunikace jsou možné dva přístupy:

Překlad protokolu může probíhat na několika úrovních: síť (NAT-PT, NAT64), transport (TRT, RFC 3142 ) nebo aplikace (DNS-ALG, RFC 2766 ). I když jej lze použít k zajištění připojení pro omezený počet hostitelů nebo aplikací, překlad čelí problémům s měřítkem ( RFC 4966 ).

V přístupu s dvojitým zásobníkem je první fází přechodu vybavení hostitelů IPv4 a zejména serverů adresami IPv6 i IPv4 tak, aby mohli komunikovat s hostiteli IPv4 i IPv6. Tyto ostrovy IPv6 jsou propojeny IPv6 přes IPv4 tunelů.

Ve druhé fázi dochází ke zobecnění dvojitého zásobníku na většinu internetu. Použití tunelů IPv6 přes IPv4 je proto stále méně nutné.

V závěrečné fázi dochází k postupnému opuštění protokolu IPv4 na internetu. Některé soukromé sítě jej nadále používají, protože připojení k internetu není nutné.

První fáze tohoto přechodu probíhá od počátku XXI th  století, nasazení IPv6 je pomalejší, než se původně očekávalo. Vzhledem k tomu, že první dvě fáze nepomáhají snižovat poptávku po adresách IPv4, vede blížící se vyčerpání veřejných adres IPv4 k vývoji mechanismů pro sdílení adres.

Přechod pro jednotlivé hostitele a podnikové sítě

Nejjednodušší způsob přístupu k protokolu IPv6 je, když se přihlásíte k odběru ISP, který nativně nabízí IPv6 , to znamená bez použití tunelů.

Jinak a během přechodové fáze je možné získat připojení IPv6 prostřednictvím tunelu. Pakety IPv6 jsou poté zapouzdřeny do paketů IPv4, které mohou procházet sítí ISP na server, který podporuje IPv6 a IPv4, a kde jsou dekapsulovány. Použití tunelů, a tedy i překryvné sítě , může být na újmu výkonu. RFC 4213 popisuje přechodové mechanismy.

Explicitně nakonfigurované tunely

K dispozici je několik služeb typu „  tunelový broker  “, které obvykle vyžadují registraci. Můžeme citovat SixXS, Freenet6 nebo Hurricane Electric.

Používané protokoly mohou být:

Setup Tunnel Protocol ( RFC je 5572 ) usnadňuje vytváření tunelu a umožňuje mobilitu a ověřování. Protokol Tunnel Information and Control , používaný AICCU  (in) , automatizuje vytváření tunelů.

Automatické tunely Překlad protokolu v sítiPřeklad protokolu v hostiteli

Není vždy možné rychle upravit aplikace, aby byly kompatibilní s IPv6, například když není k dispozici zdrojový kód .

Následující techniky umožňují aplikaci IPv4 pracovat v systému s duálním zásobníkem a komunikovat s klienty IPv6. Tyto techniky se používají ve spojení s překladačem DNS k automatickému přiřazení fiktivních adres IPv4 a jejich přiřazení k adresám IPv6, které se ve skutečnosti používají v síti.

Aplikační brány

Je možné použít servery, které mají dvojitý zásobník a které fungují jako brána na úrovni aplikace (ALG), například webový proxy server .

NAT64 a DNS64

RFC 6146 a RFC 6147 popisuje překladač protokolu, který umožňuje IPv6 hostitelům přístup k IPv4 serverů.

DNS64 provádí manipulaci s názvem domény a poskytuje ve své odpovědi klientovi adresu IPv6 (AAAA) na název hostitele, který má adresu IPv4 (A), ale žádnou adresu IPv6. To je vytvořeno s vyhrazenou předponou 64: ff9b :: / 96, ke které přidáme 32 bitů adresy IPv4 (jsou možné i jiné metody, pokud je zapouzdření adresy IPv4 konzistentní mezi NAT64 a DNS64). Když NAT64 přijme připojení s adresou typu 64: ff9b :: / 96 jako cíl, vytvoří záznam ve stavové tabulce a přiřadí tomuto výstupu číslo portu (překlad portů) nebo adresu IPv4 ze skupiny (překlad adresy), který bude považován za zdroj toku IPv4. NAT64 pracuje s TCP, UDP a ICMP.

NAT64 a DNS64 nemusí komunikovat. Pokud klient používá DNSSEC a ověří samotnou odpověď, pak DNS64 nemůže správně fungovat. Stejně tak je aktivní Asec IPsec a chrání záhlaví, NAT64 nebude fungovat správně.

464XLAT ( RFC  6877) je technika úpravy operačního systému tak, aby aplikace měly zjevně funkční adresu IPv4, zatímco překlad adres je aktivní na hostiteli, který má pouze adresy IPv6.

Přechod pro operátory a poskytovatele přístupu

Tváří v tvář vyčerpání adres IPv4 a potřebě poskytovat služby IPv6 svým zákazníkům přizpůsobují operátoři svou síť IP. Hlavní obavy z nich jsou následující:

Existuje řada studovaných scénářů, které jsou předmětem internetových návrhů. Ty se liší v progresivitě nasazení a trvanlivosti řešení.

Nosná třída NAT

Použití rozsáhlého NAT ( Carrier Grade NAT , Large Scale NAT nebo NAT44) překonává problém nedostatku adresy IPv4, kterou by bylo možné klientům přiřadit. Spočívá v distribuci soukromých adres na bránu nových zákazníků místo veřejné adresy a v překladu těchto adres na veřejné adresy do Internetu.

CGN používá překlad portů, takže mnoho klientů používá jednu veřejnou adresu. Pro všechny klienty je na veřejných adresách vyhrazeno několik bran TCP a UDP . Vezmeme-li v úvahu, že existuje 65535 čísel portů, a za předpokladu, že veřejnou adresu používá 100 klientů, má každý klient přibližně 650 čísel portů, tedy co nejvíce simultánních připojení. Neexistuje shoda ohledně minimálního počtu portů, které mají být přiřazeny každému klientovi. Některé aplikace, které vytvářejí více připojení paralelně, mohou být nepříznivě ovlivněny, pokud je toto číslo příliš nízké.

I když výrazně snižuje potřebu adresy IPv4, CGN není přechodný systém jako takový, ale používá se v kombinaci s jinými přístupy k zajištění nepřetržitého připojení k internetu IPv4.

CGN pro přechod na IPv6

CGN lze použít pro plynulý přechod na IPv6 zapouzdřením provozu IPv6 v tunelu IPv4, ve schématu podobném 6rd.

A + P

A + P je metoda, která umožňuje použití určitého počtu bitů čísla portu TCP nebo UDP pro směrování. Je to popsáno v RFC  6346.

Několik CPE může proto používat stejnou IP adresu, ale s různými rozsahy portů. Směrování na CPE využívá nejen IP adresu, ale také několik bitů čísla portu.

Stejně jako CGN, A + P řeší vyčerpání IP adres, ale není to metoda přechodu na IPv6.

NAT-PT ( Protocol Translation ), NAT64, NAT46 nebo AFT ( Address Family Translation ) mohou překládat IPv4 a IPv6. Pokud je bez státní příslušnosti, nazývá se také IVI.

To umožňuje přiřazovat adresy IPv6 klientům při zachování připojení k internetu IPv4.

Musí však existovat způsob, jak přidružit určité adresy IPv4 a IPv6 známé NAT64, například prostřednictvím systému doménových jmen .

NAT-PT je spojen s DNS v RFC 2766, ale byl zastaralý RFC 4966 kvůli problémům.

6.

6. (rd pro rychlé nasazení , RFC 5569 ) je varianta 6to4, která zahrnuje spíše ISP než internetové brány. Předpona 2002 :: / 16 vyhrazená pro 6to4 se nepoužívá, ale adresní prostor IPv6 poskytovatele přístupu. Směrovač klienta ( domácí brána , HG) zapouzdřuje provoz IPv6 v tunelu určeném pro známou adresu 6. brány ISP.

Může být použit v kombinaci s CGN.

6. byl nasazen prodejcem Free v roce 2007.

Dual-Stack Lite

Dual-Stack Lite je přístup, při kterém je síť poskytovatele internetových služeb původně migrována na IPv6. Přenos IPv4 brány zákazníka je zapouzdřen v tunelu IPv6 zvaném softwire a končí u brány ISP DS-Lite. To funguje jako CGN pro IPv4. To eliminuje potřebu přidělovat veřejné směrovače IPv4 směrovačům zákazníků.

MPLS

VPLS

Ethernetové rámce lze přenášet na úrovni 2 v síti MPLS.

6PE

V síti MPLS umožňuje technika 6PE ( RFC 4798 ) propojit klienty IPv6 s směrovači PE při zachování jádra sítě (P) v protokolu IPv4.

Základní směrovače P si vyměňují štítky a nemají žádné znalosti IPv6. Řídicí rovina MPLS zůstává v IPv4 (propojení směrovačů MPLS , IGP , LDP a / nebo RSVP a transport MP-BGP ).

Předpony IPv6 jsou vyměňovány prostřednictvím MP-BGP mezi 6PE, přičemž dalším skokem je adresa IPv6 mapující IPv4 ve tvaru :: ffff: 0: 0/96 následovaná 32 bity adresy IPv4 PE. Předpony jsou však zahrnuty v GRF a nikoli v VPRN IPv6.

Předposlední Hop Popping (PHP) na posledním P router objevit paket IPv6 před jeho přenosem do Eler EP (výtok Label EDGE router), i když router P se neočekává, že mají znalosti o IPv6. Proto v 6PE je vždy přidán další štítek (například štítek Explicit-Null IPv6) směrovačem PE iLER (ingress Label Edge Router), takže se vždy používá Ultimate Hop Popping (UHP).

Tato technologie je efektivnější než tunel IPv6 přes IPv4 a umožňuje postupné nasazení. Omezením však může být nedostatek skutečné VPRN protokolu IPv6.

6 VPE

6VPE ( RFC 4659 ) umožňuje vytvoření skutečného protokolu IPv6 VPRN a je jednoduchým funkčním ekvivalentem protokolu IPv6 k protokolu IPv4 VPRN: protokol L3VPN MPLS IPv6.



4. místo

4. umožňuje operátorům nasazovat domény, kde je použitým protokolem pouze IPv6, přičemž pro uživatele udržuje zbytkovou službu IPv4.

Aby bylo možné vyrovnat se s nedostatkem adres IPv4, lze veřejné adresy sdílet mezi několika uživatelskými weby, přičemž každému je vyhrazena podmnožina portů na úrovni přenosu (UDP, TCP atd.). Stejně jako v 6. případě je provoz bez státní příslušnosti (brány operátorů, na hranicích mezi doménami IPv4 Internet a IPv6, nemusí udržovat stavy specifické pro konkrétní uživatele).

Specifikace 4. je předmětem RFC 7600 . Je v experimentální kategorii od IETF .

Ostatní služby

Nasazení protokolu IPv6 v síti operátora zahrnuje také změny:

Ve Francii

Ve Francii ARCEP vydala zprávu o přechodu z IPv4 na IPv6 v roce 2006října 2016.

Tato zpráva se zaměřuje na následující otázky prostřednictvím akcí: závazek státu zpřístupnit všechny státní weby a online služby v IPv6, výuka IPv6, zavedení výměn o osvědčených postupech a zkušenostech, koordinace stran zveřejněním záměrů aktéři přechodu, informace uživatele o trvanlivosti terminálů a dysfunkcích souvisejících s přídělovými mechanismy adres IPv4 a přípravou konce IPv4.

V roce 2016 vedl nedostatek adres IPv4 k vytvoření neprůhledného trhu, kde se adresy IPv4 obchodují za cenu kolem 10 EUR za adresu.

RIPE NCC-na , která France závisí předpokládá globální konec dostupnost IPv4 adres do roku 2021. Nicméně, mnoho hráčů jsou již zbaven způsobilosti k získání nové adresy IPv4.

Ve Francii jsou řešení implementována, například prostřednictvím NAT, ale tyto opravy mají různé nevýhody: selhání určitých aplikací, nedostatek odolnosti, zejména náklady na implementaci a údržbu.

Ve Francii  činil podíl autoritativních serverů DNS na doménách „  .fr “, které jsou kompatibilní s IPv6, na konci roku 2014 přibližně 63%.

Servery AFNIC se pro přenos IPv6 používají pouze do 18%.

Poskytovatel obsahu vidí v době zprávy pouze 10,5% uživatelů ve Francii, kteří používají technologii IPv6 z pohledu Google, a mezi 10 a 12 z pohledu Akamai .

Pro společnost Cisco je 50% online obsahu k dispozici v protokolu IPv6, ale některé vládní weby s vyšším provozem nelze zobrazit v protokolu IPv6, stejně jako některé weby veřejných služeb, například ty, které se používají pro zdravotní pojištění, nebo do fondu rodinných příspěvků.

Podle společnosti Cisco je podíl tranzitních sítí využívaných poskytovateli přístupu a obsahu ve Francii přibližně 70% pro kompatibilitu s IPv6.

ARCEP rovněž uvažuje o zřízení národní observatoře, která by byla schopna vydávat roční statut vývoje těchto metrik.

Mezinárodní srovnání

Zdroj Arcep.


Zdroj Arcep.
Zdroj Arcep.

Poznámky a odkazy

  1. SixXS
  2. Freenet6
  3. Hurricane Electric
  4. (in) Christian Huitema <[email protected]> , „  An Anycast Prefix for 6to4 Relay Routers  “ na tools.ietf.org (přístup 12. března 2018 )
  5. (in) Carpenter, Brian and Troan, Ole , „  deprecating the Anycast Prefix for 6to4 Relay Routers  “ na tools.ietf.org (přístup 12. března 2018 )
  6. (in) Kidney, Rick van and Steffann, LSU , „  A Comparison of IPv6-over-IPv4 tunnel Mechanisms  “ na tools.ietf.org (přístup 12. března 2018 )
  7. miredo
  8. Dual Stack IPv6 Dominant Transition Mechanism (DSTM) Internet Draft, 2005
  9. (in) Request for Comments n °  6877 .
  10. Incremental Carrier-Grade NAT (CGN) pro IPv6 Transition
  11. (in) Randy Bush, "  The Address více Port (A + P) Přístup k IPv4 adres Nedostatek  " Request for Comments n o  6346,srpna 2011.
  12. Dual-stack lite širokopásmové nasazení po vyčerpání protokolu IPv4
  13. (in) Farinacci, Dino a Fedorkow, Guy , „  MPLS Label Stack Encoding  “ na tools.ietf.org (přístup 12. března 2018 )
  14. (in) Horse, Pierrick a Krishnan Ram , „  Shahram Davari PMC-Sierra Inc.  “ na tools.ietf.org (přístup 12. března 2018 )
  15. (in) „  6PE FAQ: Proč 6PE používá v datové rovině dva štítky MPLS?  » , Na platformě Cisco (přístup 13. března 2018 )
  16. IPv6 - Pohled poskytovatele služeb v Pokroku v sítích MPLS , Internet Protocol Journal, červen 2005
  17. (in) Rosen, Eric C. a Rekhter, Yakov , „  BGP / MPLS IP Virtual Private Networks ( VPNs )  “ na adrese tools.ietf.org (přístup 12. března 2018 )
  18. Arcep chce podpořit IPv6 Christophe Lagane, silicon.fr, 3. října 2016
  19. „  Zpráva vládě o stavu nasazení protokolu IPv6 ve Francii  “ [PDF] ,28. června 2016( ISSN  2258-3106 , přístup 29. prosince 2017 )

externí odkazy