IPv6 ( Internet Protocol version 6 ) je síťový protokol bez připojení k vrstvy 3 z OSI (Open Systems Interconnection).
IPv6 je vyvrcholením prací provedených v rámci IETF v 90. letech za účelem úspěchu protokolu IPv4 a jeho specifikace byly dokončeny v RFC 2460 vprosince 1998. IPv6 byl standardizován v RFC 8200 včervence 2017.
Díky 128-bitové adresy namísto 32-bit, IPv6 má mnohem větší adresní prostor než IPv4 (přes 340 sextillion nebo 340.10 36 , nebo téměř 7,9 × 10 28 krát více než v předchozím). Tento značný počet adres umožňuje větší flexibilitu při přidělování adres a lepší agregaci tras ve směrovací tabulce Internetu . Překlad adres , který byl vyrobený populární nedostatek IPv4 adres již není nutné.
IPv6 má také mechanismy automatického přidělování adres a usnadňuje přečíslování. Velikost podsítě , proměnná v IPv4, byla opravena na 64 bitů v IPv6. Bezpečnostní mechanismy jako IPsec jsou součástí základních specifikací protokolu. Záhlaví paketu IPv6 bylo zjednodušeno a typy místních adres usnadňují propojení soukromých sítí.
Nasazení protokolu IPv6 přes internet je komplikované kvůli nekompatibilitě adres IPv4 a IPv6. Automatické překladače adres čelí významným praktickým problémům ( RFC 4966). Během přechodové fáze, kdy IPv6 a IPv4 koexistují, mají hostitelé duální zásobník , to znamená, že mají adresy IPv6 i IPv4 a tunely procházejí skupinami směrovačů , které zatím nepodporují IPv6.
V roce 2011 se zavázalo nasadit technologii IPv6 do své interní sítě, zejména Google , jen několik společností .
Na začátku roku 2016 bylo nasazení protokolu IPv6 stále omezené, podíl uživatelů internetu využívajících protokol IPv6 se odhaduje na 10%, a to navzdory naléhavým výzvám k urychlení migrace zaměřené na poskytovatele internetových služeb. Poskytovatelé internetu a obsahu z regionálních internetových registrů a ICANN , protože vyčerpání dostupných veřejných IPv4 adres je na spadnutí.
Protokol IPv4 umožňuje použít k připojení počítačů a dalších zařízení v síti více než čtyři miliardy různých adres. Když internet začal v 70. letech, bylo téměř nepředstavitelné, že v jedné síti bude někdy dost strojů na to, aby se vyčerpaly dostupné adresy.
Některé ze čtyř miliard teoreticky dostupných IP adres nelze použít k číslování počítačů, buď proto, že jsou určeny pro konkrétní použití (například vícesměrové vysílání nebo soukromé sítě ), nebo proto, že byly přiděleny neefektivně.
Do 90. let byly adresy distribuovány ve formě tříd , žadatelům byly přiděleny bloky 16 milionů ( třída A ), 65 536 ( třída B ) nebo 256 adres ( třída C ), někdy i nad rámec skutečných potřeb. Například prvním velkým organizacím připojeným k internetu bylo přiděleno 16 milionů adres.
V časných 1990, čelí vyčerpání adresního prostoru, zejména sítí třídy B ( RFC 1338), regionální internetové registry objevil a rozdělení adres do tříd byl zrušen ve prospěch nejvíce flexibilní. CIDR . Alokace adres je zefektivněna a zohledňuje skutečné potřeby, přičemž umožňuje určitou úroveň agregace nezbytnou pro správné fungování směrování na internetu, přičemž tyto dva principy jsou protichůdné.
Rostoucí poptávka po adresách pro nové aplikace, mobilní zařízení a trvale připojená zařízení vede k rostoucímu využívání soukromých adres , překladu síťových adres (NAT) a dynamickému přidělování datových adres.
Navzdory těmto snahám je vyčerpání veřejných adres IPv4 nevyhnutelné. To je hlavní důvod pro vývoj nového internetového protokolu prováděného v rámci Internet Engineering Task Force (IETF) v 90. letech.
The 3. února 2011„ Internet Assigned Numbers Authority (IANA) oznamuje, že posledních pět bloků adres bylo rovnoměrně rozděleno do pěti regionálních internetových registrů (RIR), a proto již nemá žádné volné bloky adres. The15. dubna 2011, APNIC se RIR porce asijsko-tichomořském regionu, oznámila, že má nyní pouze jeden / 8 blok (16,7 milionů adres) a nyní se prodávají pouze omezené množství adres pro žadatele. Totéž učinila RIPE NCC, která slouží Evropě a na Středním východě14. září 2012. Zbývající RIR vyčerpají přidělení adres IPv4 pro místní internetové registry (LIR) v letech 2013 až 2015. LIR začne vyčerpávat adresy IPv4, které budou přiděleny jejich klientům v roce 2012.
Protokol IPv6 také na základě minulých zkušeností vylepšuje některé aspekty fungování protokolu IP.
Hlavní specifikace pro IPv6 byly publikovány v roce 1995 IETF. Z novinek můžeme zmínit:
Na počátku 90. let bylo jasné, že vývoj internetu povede k vyčerpání dostupných adres ( RFC 1752). V roce 1993 vyhlásila IETF výzvu k podávání návrhů ( RFC 1550) a oznámila vytvoření pracovní skupiny IP Next Generation (IPng) .
Nejprve se jmenoval Simple Internet Protocol Plus (SIPP, RFC 1710), poté IP Next Generation (IPng), tento byl vybrán v roce 1994 mezi několika kandidáty a v roce 1995 získal svůj konečný název IPv6 (IP verze 6), přičemž IP verze 5 byla vyhrazeno pro Internet Stream Protocol verze 2 (ST2) podle RFC 1819. Specifikace protokolu IPv6 byly původně publikovány v prosinci 1995 v RFC 1883 a finalizovány v RFC 2460 vprosince 1998.
Fungování protokolu IPv6 je velmi podobné fungování protokolu IPv4. Protokoly TCP a UDP se prakticky nezmění. To shrnuje vzorec „96 dalších bitů, nic magického“.
Adresa IPv6 je 128 bitů nebo 16 bajtů , ve srovnání s 32 bitů / 4 bajty pro IPv4. Tečkované desítková soustava používá pro IPv4 adresy (například 172.31.128.1) je opuštěné ve prospěch hexadecimálním psaní , kde 8 skupin 2 bajty (16 bitů na skupinu), jsou odděleny dvojtečkou:
2001: 0db8: 0000: 85a3: 0000: 0000: ac1f: 8001Z každé skupiny čtyř hexadecimálních číslic lze vynechat jednu až tři úvodní nuly. Výše uvedená adresa IPv6 je tedy ekvivalentní následující:
2001: db8: 0: 85a3: 0: 0: ac1f: 8001Kromě toho lze vynechat jednu sekvenci jedné nebo více po sobě jdoucích skupin 16 všech nulových bitů, avšak zachování dvojteček na obou stranách vynechané sekvence číslic, tj. Dvojice dvou. -Bodů „::“ ( RFC 2373 a RFC 4291). Výše uvedenou adresu IPv6 lze tedy zkrátit na následující:
2001: db8: 0: 85a3 :: ac1f: 8001Jedna adresa IPv6 může být zastoupena několika různými způsoby, například 2001: db8 :: 1: 0: 0: 1 a 2001: db8: 0: 0: 1 :: 1. RFC 5952 doporučuje kanonické reprezentaci.
Je třeba poznamenat, že v adrese IPv6 lze vynechat pouze jednu sekvenci nulových bitů. Jinak by bylo nemožné určit počet nula bitů mezi každou dvojicí dvojtečky „:“.
Sítě jsou identifikovány pomocí zápisu CIDR : za první síťovou adresou následuje lomítko „/“ a poté celé číslo mezi 0 a 128, které označuje délku síťové předpony v bitech , konkrétně část společných adres určených uvedenou sítí.
Následují příklady síťových adres IPv6 s jejich určenými sadami adres:
Určité předpony adres IPv6 hrají speciální role:
Předpona | Popis | |
---|---|---|
:: / 8 | Rezervované adresy | |
2000 :: / 3 | Směrovatelné adresy unicast pro internet | |
fc00 :: / 7 | Jedinečné místní adresy | |
fe80 :: / 10 | Odkaz na místní adresy | Unicast na místním odkazu ( RFC 4291) |
ff00 :: / 8 | Multicast adresy | Vícesměrové vysílání ( RFC 4291) |
Lze si všimnout dvou vyhrazených adres z :: / 8:
Adresy 2000 :: / 3 lze rozlišit takto:
pole | globální předpona směrování | identifikátor podsítě | identifikátor rozhraní |
---|---|---|---|
bity | ne | 64-n | 64 |
Globální předpona směrování s proměnnou velikostí představuje veřejnou topologii adresy, jinými slovy ta, která je viditelná mimo web. Část podsítě představuje soukromou topologii . RFC 4291 udává, že všechny globální unicast adresy musí mít velikost identifikátor rozhraní (IID) o velikosti 64 bitů, s výjimkou těch, které začínají binární 000. Pro odkazy typu point-to-point je však možné použít / 127 ( RFC 6164). RFC 7421 popisuje architektonický výběr této jednotné velikosti identifikátoru rozhraní, která se jeví podstatně přesahovat adresování potřeb v podsíti.
RozsahRozsah IPv6 adresy tvoří svém oboru platnosti a jedinečnosti, podle RFC 4007.
Rozlišujeme:
Všechna rozhraní, kde je aktivní IPv6, mají alespoň jednu adresu lokálního oboru odkazu (fe80 :: / 10); adresa označená fe80 :: / 10 označuje unicast na místním odkazu ( RFC 4291).
Index zónyNa různých odkazech na stejném stroji může být několik adres lokálních adres, nejasnosti odstraníme poskytnutím indexu zóny ( RFC 4007), který přidáme na adresu po znaku procenta: fe80 :: 3% eth0 bude odpovídat místní adresa odkazu fe80 :: 3 například na rozhraní eth0.
Přiřazení bloků adres IPv6V globálním unicastovém adresním prostoru (2000 :: / 3) přiděluje IANA bloky v rozsahu od / 12 do / 23 regionálním internetovým registrům , jako je RIPE NCC v Evropě. Tyto distribuují předpony / 32 do místních internetových registrů, které je pak přiřadí jako blok / 48 až / 64 koncovým uživatelům ( RFC 6177).
Každému koncovému uživateli je přiřazen blok o různé velikosti od / 64 (jedna podsíť ) do / 48 (65 536 podsítí), přičemž každá z podsítí pojme prakticky neomezený počet hostitelů ( 264 ). V roce 2000 :: / 3 bloku, který reprezentuje ⅛ th adresního prostoru k dispozici v IPv6, můžeme tedy vytvořit 2 29 nebo 500 mil / 32 bloků pro poskytovatele internetových služeb, a 2 45 nebo 35,000 miliardy typické podnikové sítě (/ 48).
Záhlaví paketu IPv6 má pevnou velikost 40 bajtů, zatímco v IPv4 je minimální velikost 20 bajtů, přičemž možnosti se pohybují až 60 bajtů, přičemž tyto možnosti jsou v praxi vzácné.
Význam polí je následující:
Je možné, že jedna nebo více záhlaví rozšíření následuje záhlaví IPv6. Směrovací hlavička umožňuje například zdroji určit určenou cestu, po které se má vydat.
Srovnání s IPv4V IPv4 mají směrovače, které musí přenášet paket, jehož velikost přesahuje MTU cílového spoje, jeho fragmentaci, to znamená segmentaci na několik menších IP paketů. Tato složitá operace je nákladná z hlediska CPU pro router i pro cílový systém a nepříznivě ovlivňuje výkon přenosů, na druhou stranu jsou fragmentované pakety citlivější na ztráty: pokud dojde ke ztrátě pouze jednoho z fragmentů, celý počáteční paket musí být znovu vyslán.
V protokolu IPv6 zprostředkující směrovače již nefragmentují pakety a místo toho odesílají zpět paket ICMPv6 Packet Too Big , za fragmentaci paketu je odpovědný odesílající stroj. Použití Path MTU discovery se však doporučuje, aby nedocházelo k fragmentaci.
Tato změna zjednodušuje práci směrovačů a vyžaduje méně výpočetního výkonu.
Minimální povolená MTU pro odkazy byla také zvýšena na 1280 bajtů (ve srovnání s 68 pro IPv4 , RFC 791, RFC určuje, že hostitel musí být schopen přijímat znovu sestavený paket 576 bajtů.). Pokud žádné odkazy nemohou podporovat tuto minimální MTU, musí existovat konvergenční vrstva odpovědná za fragmentaci a opětovné sestavení paketů.
Stejně jako u protokolu IPv4 je maximální velikost paketu IPv6 mimo záhlaví 65 535 bajtů. IPv6 má však možnost jumbogram me ( RFC 2675), která umožňuje zvětšit maximální velikost paketu na 4 GB a těžit tak ze sítí s vyšší MTU.
Prodloužení záhlavíZa záhlavím IPv6 může následovat řada záhlaví rozšíření. Ty následují jeden za druhým, přičemž každý nadpis označuje povahu dalšího. Jsou-li přítomni, jejich pořadí je následující:
Francouzské jméno | anglické jméno | Typ | Střih | Popis | RFC |
---|---|---|---|---|---|
chmel za chmelem RFC 2460 | Možnosti hop-by-hop | 0 | proměnná | Obsahuje možnosti, které musí respektovat všechny tranzitní směrovače, například možnost jumbogram. | RFC 2460, RFC 2675 |
Směrování | 43 | proměnná | Umožňuje upravit směrování ze zdroje, který používá zejména Mobile IPv6 | RFC 2460 RFC 3775, RFC 5095 | |
Fragment | 44 | 64 bitů | Obsahuje informace o fragmentaci. | RFC 2460 | |
Ověřovací hlavička (AH) | 51 | proměnná | Obsahuje informace nezbytné pro ověřování záhlaví, viz IPsec . | RFC 4302 | |
Zapouzdření bezpečnostního užitečného zatížení (ESP) | 50 | proměnná | Obsahuje informace o šifrování obsahu, viz IPsec . | RFC 4303 | |
Možnosti cíle | 60 | proměnná | Možnosti, které musí zpracovat konečný cíl. | RFC 2460 | |
Žádné záhlaví podle RFC 2460. | Žádné další záhlaví | 59 | prázdný | Označuje, že následuje žádné užitečné zatížení. | RFC 2460 |
Další možné hodnoty se řídí stejnou konvencí jako pole Protocol v záhlaví IPv4.
Protokol „ Neighbor Discovery Protocol nebo ND, RFC 4861“ sdružuje adresy IPv6 s adresami MAC v segmentu, například ARP pro IPv4. Umožňuje také objevit směrovače a směrované předpony, MTU, k detekci duplicitních adres, hostitelů, kteří se stali nepřístupnými, a autokonfiguraci adres a případně adres rekurzivních serverů DNS (RDNSS, RFC 5006). Je založen na protokolu ICMPv6 .
V podsíti existuje několik metod přiřazování adres:
Ruční konfigurace správce opraví adresu. Adresy složené výhradně z 0 nebo 1 nehrají v protokolu IPv6 konkrétní roli. Automatická konfiguraceStateless ( Stateless Address Autoconfiguration , SLAAC):
Se stavem:
Když byl tento protokol vyvinut v 90. letech, nebyl internet tak rozvinutý a nebyly vyřešeny otázky ochrany osobních údajů a soukromí. V roce 2010 však použití adresy MAC síťové karty k vytvoření adresy IPv6 vyvolalo obavy z ochrany osobních údajů, protože adresa MAC je jednoznačně identifikovatelná. K překonání tohoto dohledu se vyvinul protokol a byly zavedeny další metody generování adres, nazývané rozšíření ochrany osobních údajů :
Je možné použít dočasné adresy, které jsou pseudonáhodně generovány a pravidelně měněny ( RFC 4941). Pro potřebu stabilní adresy v průběhu času je možné a dokonce se od roku 2017 doporučuje používat adresu odvozenou z tajného klíče a síťové předpony (tzv. Stabilní privátní , RFC 7217). Vždy existuje možnost použít službu pro automatické přidělování adres IPv6 serverem, podobnou té, která existuje pro IPv4, s DHCPv6.
Multicast , která inzeruje balíček ke skupině, která je součástí původních specifikací IPv6. Tato funkce také existuje v IPv4, kde byla přidána RFC 988 v roce 1986.
Již neexistuje vysílací adresa IPv6, nahrazuje se adresou vícesměrového vysílání specifickou pro požadovanou aplikaci. Například adresa ff02 :: 101 se používá ke kontaktu serverů NTP na odkazu. To umožňuje hostitelům filtrovat pakety určené pro protokoly nebo aplikace, které nepoužívají, aniž by bylo nutné zkoumat obsah paketu.
Na úrovni ethernetu je řada předpon OUI vyhrazena pro adresy vícesměrového vysílání IPv6 (33: 33: xx). MAC adresa skupiny vícesměrového vysílání bude sestávat z těchto 16 bitů následovaných posledních 32 bitů adresy vícesměrového vysílání IPv6. Například adresa ff02 :: 3: 2 bude odpovídat MAC adrese 33: 33: 00: 03: 00: 02. Ačkoli mnoho skupin vícesměrového vysílání sdílí stejnou adresu MAC, již to umožňuje efektivní filtrování na úrovni síťového adaptéru.
Ačkoli je podpora vícesměrového vysílání na úrovni odkazu pro IPv6 povinná, směrování paketů vícesměrového vysílání nad rámec segmentu vyžaduje použití směrovacích protokolů, jako je PIM , podle uvážení poskytovatele internetových služeb.
Protokol Multicast Listener Discovery umožňuje identifikovat aktivní skupiny v segmentu, jako je IGMP pro IPv4.
Mezi nejjednodušší ethernetové přepínače léčit multicastové rámce tím, že vysílá je jako vysílacích rámců . Toto chování je vylepšeno MLD snooping, který omezuje vysílání pouze na hostitele projevující zájem o skupinu, jako je IGMP Snooping pro IPv4.
Zatímco v IPv4 je obtížné rezervovat globální adresy vícesměrového vysílání, RFC 3306 přidruží blok adres vícesměrového vysílání / 96 pro každou směrovatelnou předponu na internetu, tj. Každá organizace má automaticky 4 miliardy dolarů. 'Veřejné adresy vícesměrového vysílání. RFC 3956 také zjednodušuje realizaci bodů setkání pro multicast propojení.
Struktura adres vícesměrového vysílání založená na prefixu unicast může mít tedy podobu jednoho z následujících příkladů:
V systému názvů domén jsou názvy hostitelů přidruženy k adresám IPv6 pomocí záznamu AAAA.
www.ipv6.ripe.net. IN AAAA 2001:610:240:22::c100:68bZpětný záznam se provádí pod ip6.arpa obrácením adresy zapsané v kanonické podobě ( RFC 3596): nejdříve je zakódován nejméně významný nibble:
b.8.6.0.0.0.1.c.0.0.0.0.0.0.0.0.2.2.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa. IN PTR www.ipv6.ripe.net.První verze standardu plánovala použít příponu ip6 .int .
Mechanismus použitý ke konstrukci názvu reverzní domény je podobný mechanismu použitému v IPv4, s tím rozdílem, že tečky se používají mezi každým kouskem ( RFC 3596) bitů (nebo kouskem 4 bitů), což prodlužuje doménu.
Složitější bitové štítky ( RFC 2673), DNAME a A6 ( RFC 2874), které překonávají omezení delegování na hranici okusování , jsou považovány za experimentální a jejich podpora je vzácná ( RFC 3363, záznam neobvyklého A6 byl zařazen na „historický“ stav podle RFC 6563 v roce 2012).
Zpětné rozlišení lze použít v systémech řízení přístupu i v diagnostických nástrojích, jako je traceroute .
V IPv6 se nedoporučuje používat překlad adres, aby se zachovala transparentnost sítě ( RFC 5902), jeho použití již není nutné pro ukládání adres.
Protokol IPv6 poskytuje mechanismy pro zachování stejné adresy IPv6 pro stroj, který lze připojit k různým sítím, a přitom se co nejvíce vyhnout trojúhelníkovému směrování.
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. Přechodem je poskytnout hostitelům IPv4 duální zásobník , tedy adresy IPv6 i IPv4.
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 překryvné sítě , může být na újmu výkonu.
Statické tunelyK dispozici je několik služeb typu „ tunelový broker “, které obvykle vyžadují registraci. Můžeme citovat SixXS 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é tunelyJe 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 .
NAT-PT kombinuje překlad síťových adres a server DNS pro umožnění komunikace mezi systémy IPv4 a systémy IPv6. Je definován v RFC 2766, ale kvůli problémům byl RFC 4966 zamítnut .
Multihoming je pro síť mít více poskytovatelů tranzitních za účelem zvýšení spolehlivosti přístupu k internetu. V IPv4 se toho obvykle dosahuje vlastním číslem AS , rozsahem IP adres poskytovatele nezávislého (PI) a použitím BGP k dynamické výměně tras s každým z poskytovatelů.
Tento způsob provádění multihomingu spotřebovává čísla AS a zvyšuje velikost směrovací tabulky Internetu kvůli předponám PI, které nelze agregovat.
Standardizace multihomingu v protokolu IPv6 byla zpožděna, přičemž jednou z počátečních ambicí architektury IPv6 bylo používat pouze adresy typu Provider Aggregatable (PA) ke zmenšení velikosti směrovací tabulky Internetu. S ohledem na to bylo multihoming dosaženo přidělením tolika PA adres, kolik je poskytovatelů, mechanismy IPv6, jako je automatické přidělování a omezená životnost adres usnadňující změny adres spojené se změnami dodavatelů. Regionální internetové registry proto donedávna nedistribuovaly blok PI pro IPv6.
V roce 2009 RIR, stejně jako RIPE NCC , změnily svou politiku tím, že souhlasily s přidělením bloků PI společnostem, které se chtějí připojit k více poskytovatelům, minimální velikost bloku PI je / 48, zatímco velikost bloku je PA / 32. To umožňuje provádět multihoming stejným způsobem jako v IPv4.
Další možné přístupy jsou založeny na oddělení identifikátoru a lokátoru ( oddělení identifikátoru / lokátoru ):
Toto je výzkumné téma pracovní skupiny Routing Research pracovní skupiny pro internetový výzkum (en) .
V první fázi poskytovatelé internetových služeb používají tunely, které zapouzdřují pakety IPv6 v paketech IPv4 (přes 6v4 nebo GRE), k procházení skupin směrovačů , které nepodporují IPv6. Pokud je to možné, výměny probíhají nativně s IPv4 a IPv6, které koexistují na stejných odkazech. Pokud jsou směrovače aktualizovány tak, aby podporovaly protokol IPv6, není nutné mít samostatnou infrastrukturu pro protokol IPv6, protože směrovače zpracovávají přenosy IPv4 i IPv6.
Od té doby Červenec 2004, ICANN přijímá integrovat jmenné servery s adresami IPv6 ( Spojovací záznamy ) v kořenové zóně. První domény nejvyšší úrovně, které mají server DNS IPv6, jsou .kr a .jp , brzy následuje .fr .
v Února 2008„ICANN přidal adresy IPv6 k šesti ze třinácti kořenových serverů DNS a„ i “bylo přidáno v roce 2010. Na druhou stranu v roce 2010 mělo 228 z 283 domén nejvyšší úrovně alespoň jeden server s adresou IPv6. Registrátoři by však měli aktualizovat svůj software, aby podporovali delegování na servery IPv6 a jakékoli záznamy lepidla AAAA .
Hlavní jmenné servery, jako je BINDv 9, podporují záznamy AAAA i přenos požadavků přes IPv6.
Velikost paketů DNS v UDP je omezena na 512 bajtů ( RFC 1035), což může způsobit problémy v případě, že je odpověď obzvláště velká. Standard poté stanoví, že se používá připojení TCP, ale některé brány firewall blokují port TCP 53 a toto připojení spotřebovává více prostředků než v UDP. Tento případ nastává zejména u seznamu jmenných serverů v kořenové zóně. EDNS 0 ( RFC je 2671) rozšíření umožňuje použití větší velikosti paketu, její podpora je doporučena pro IPv6 a DNSSEC.
Směrovací protokoly jako BGP ( RFC 2545), OSPFv 3 ( RFC 5340), IS-IS ( RFC 5308) a MPLS ( RFC 4798) byly aktualizovány pro IPv6.
Protokoly TCP a UDP fungují jako IPv4. Pseudo hlavička použitá pro výpočet řídicího kódu je však upravena a zahrnuje zdrojovou a cílovou adresu IPv6. Použití kontrolního kódu je také povinné pro UDP. Byly provedeny drobné změny v podpoře jumbo paketů ( RFC 2675).
Protokoly linkové vrstvy typu IEEE 802 jsou vhodné pro přenos IPv6. Na úrovni ethernetu je například hodnota typového pole přiřazeného IPv6 0x86DD ( RFC 2464).
V sítích NBMA (en), jako je X.25 nebo Frame Relay , jsou plánovány úpravy, které umožní provoz Neighbor Discovery .
Konsorcium CableLabs (v) zveřejnilo specifikace týkající se kabelových modemů IPv6 v DOCSISv 3.0srpna 2006. V DOCSIS verze 2.0 není žádná podpora IPv6. Takzvaná verze „DOCSIS 2.0 + IPv6“ však existuje a vyžaduje pouze aktualizaci firmwaru.
Pro technologie xDSL definuje RFC 2472 zapouzdření IPv6 přes PPP. ARM musí také podporovat IPv6.
Obecně platí, že zařízení, která pracují na linkové vrstvě , jako jsou ethernetové přepínače , nepotřebují aktualizaci pro podporu IPv6, s výjimkou možného vzdáleného ovládání a správy a optimalizace vysílání multicast s MLD snooping .
Přístupové systémy obecně musí být přezkoumány pro IPv6, zejména pro nástroje pro přidělování adres a databáze pro registraci adres.
Od počátku XXI -tého století, všechny hlavní operační systémy ( GNU / Linux , Mac OS X , Microsoft Windows , BSD , Solaris , HP-UX , atd.) Byly aktualizovány tak, aby podpora IPv6, a to je také případ další vestavěné systémy, jako jsou Symbian , QNX , Android , Windows Mobile nebo Wind River .
Windows Vista podporuje protokol IPv6 ve výchozí konfiguraci, zpřístupňuje nastavení protokolu IPv6 v grafickém uživatelském rozhraní ve stejné rovině jako nastavení protokolu IPv4 a používá nový duální zásobník TCP / IP místo nezávislého zásobníku pro protokol IPv6. Tato podpora je základem pro HomeGroup a DirectAccess ve Windows 7 .
Na routeru úrovni , Cisco nabízí podporu IPv6 již od roku 2001 s IOS 12.2, je to také v případě novějších verzí softwaru ze strany velkých výrobců, jako Juniper Networks , Alcatel-Lucent nebo Redback Networks .
Některé CPE jsou však stále nekompatibilní s IPv6, což vyžaduje konfiguraci tunelů.
Aplikace připojené k síti musí být upraveny tak, aby byly kompatibilní s IPv6. Rozsah aktualizace zdrojového kódu se liší podle toho, jak aplikace adresy používají. Může to být jednoduchá náhrada, ale také složitější úpravy, pokud je adresa uložena v databázi nebo je použita v řízení přístupu.
Pokud není možné aplikaci rychle aktualizovat, přechodové techniky umožňují aplikacím IPv4 komunikovat s klienty IPv6:
Mnoho aplikací již bylo přeneseno. To platí zejména pro webové prohlížeče, jako je Internet Explorer (od verze 7, částečně pro verzi 6), Mozilla Firefox (1.0), Opera (7.20b), Safari a Google Chrome , Mozilla Thunderbird mail klient (1.0), webový server Apache (1.3.27 / 2.0.43), poštovní server Exim (4.20) atd.
Renater začal experimentovat s IPv6 v roce 1996 se sítí G6bone, francouzským protějškem globální sítě 6bone, která začala ve stejném roce. Tato testovací síť používala hlavně tunely. Pilotní služba sítě Renater 2 IPv6 nabízí nativní protokol IPv6 přes připojení ATM v roce 2002.
poskytovatel internetu | Datum nasazení | Délka přidělené předpony | MTU | Poznámky |
---|---|---|---|---|
Nerim | Březen 2003 | / 48 | 1 500 v PPPoA, 1 492 v PPPoE | |
Volný, uvolnit | prosince 2007 | / 61 | 1480 v nevázaném ADSL , není k dispozici v nevázaném | 6. místo v ADSL |
FDN | Listopadu 2008 | / 48 | 1 492 v PPPoE | |
SFR | konec roku 2011 (beta v červen 2011)
konec roku 2013 (FTTH) |
/ 64 | ? | L2TP tunel |
Čitatelné | počátkem roku 2012 | ? | ? | DOCSIS 3.0 |
OVH | polovina roku 2012 | / 56 | 1 500 v IPoE (oddělené), 1 492 v PPPoE | delegování předpony ( RFC 3633) protokolem DHCPv6 |
oranžový | Testy Wanadoo v roce 2005; nabízena jako přizpůsobená nabídka od roku 2010 na firemním trhu pod značkou Orange Business Services , od té doby interní testyčervence 2014, Nasazení IPv6 pro širokou veřejnost začalo počátkem roku 2016 pro zákazníky s optickými vlákny a VDSL. | / 56 | 1 500 | Livebox Play je inzerován jako kompatibilní s IPv4 a IPv6. |
Bouygues Telecom | plánováno na oddělené ADSL v roce 2017, FTTH v roce 2018 | / 60 | 1 500 | Delegování předvoleb IPv6 na Bboxu v roce 2018 |
Zeop | 22. července 2014 | / 56 | 1 500 | První operátor IPv6 na Réunionu |
Quantic Telecom | 2013 | / 48 | ? | ? |
K-Net | 2012 | / 56 | 1 500 | |
Orne THD | 2019 | / 56 | 1 500 | První operátor, který má pro všechny zákazníky povoleno 100% IPv6 |
Podle výroční zprávy ARCEP za rok 2019 přidělili čtyři hlavní francouzští operátoři (Bouygues Telecom, Free, Orange, SFR) na konci roku 2004 přibližně 94% až 99% adres IPv4, které vlastní. června 2019.
Zdroje: Arcep |
Zdroje: Arcep |
Ve Švýcarsku kromě univerzálního síťového operátora Switch nasadilo několik alternativních operátorů IPv6 pro své rezidenční zákazníky, jakmile je protokol standardizován, jedním z nejdůležitějších je Init7.
Úřadující operátor, Swisscom , provedl experimenty s nasazením v letech 2003 a 2004 jako součást švýcarské pracovní skupiny IPv6, jejímž byl vůdcem, ale pouze IPv6 ve výrobě udržovala mezinárodní síť společnosti (IP-Plus). V roce 2011 zahájil Swisscom pilotní projekt otevřený všem svým zákazníkům pro nasazení rezidenční IPv6 prostřednictvím 6. technologie , přičemž každý zákazník měl pro svou osobní potřebu / 60.
Ostatní významní švýcarští operátoři, jmenovitě Sunrise, Cablecom a Orange, zatím v roce oficiálně neoznámili žádné plány července 2011, avšak France Telecom v říjnu 2009 oznámila, že pro své nasazení použije jako pilotní zemi Švýcarsko.
V roce 2000 umožnil program 6INIT propojení evropských národních výzkumných a vzdělávacích sítí (NREN) pomocí PVC IPv6 přes ATM prostřednictvím evropské výzkumné sítě TEN 155 .
V roce 2003 síť GÉANT , která nahradila TEN 155, používala duální stack (IPv4 + IPv6). Osmnáct NREN je nativně připojeno v IPv6.
Evropská komise si stanovila za cíl přijmout do konce roku 2008 závazky od 100 hlavních provozovatelů webových stránek v Evropské unii a v roce Květen 2009.
V roce 2010 se RIPE NCC (Europe) je oblast, která oznamuje největší počet IPv6 prefixů.
Projekt IPv6 Ripeness of RIPE má sledovat zavedení IPv6 v Evropě udělením hvězd místním internetovým registrům, jakmile budou dosaženy některé indikátory nasazení. Hvězdy se udělují za každé z následujících kritérií:
v Leden 2013, 57% LIR získalo blok adres IPv6 a 19% dosáhlo nejvyšší úrovně čtyř hvězdiček.
V roce 1996 testovací síť 6bone umožnila experimentovat s technologií IPv6 ( RFC 2471). Tato síť byla postavena na tunelech a trasy byly vyměňovány protokolem BGP4 + . Účastníci dostali v bloku 3ffe :: / 16 předponu / 24, / 28 nebo / 32. Síť byla zrušena v roce 2006 ( RFC 3701) ve prospěch nativních připojení.
Dnes mnoho webových serverů přijímá připojení přes IPv6. Google je například přístupný v IPv6 zBřezen 2008, to platí také pro YouTube a Facebook od roku 2010.
Existují také servery IPv6 nabízející běžné služby, jako jsou FTP , SSH , SMTP , IMAP nebo IRC .
V roce 2009 začalo několik globálních operátorů zavádět IPv6.
V Japonsku , NTT prodává různé IPv6 nabídky služeb a také prodává Flet je telefon .
Podle nařízení o veřejných zakázkách je podpora protokolu IPv6 povinná, zejména ve státech Evropské unie a ve Spojených státech .
Ve Spojených státech začala společnost Comcast v roce 2010 testovat různé technologie kolem protokolu IPv6 ve své produkční síti v očekávání definitivního nasazení a vyčerpání adres IPv4 . IPv6 používá také ministerstvo obrany Spojených států amerických.
Čínská lidová republika se na IPv6 dívá se zájmem. Jeho cílem je zahájit komerční používání protokolu IPv6 od roku 2013 a širší používání a propojení do roku 2015. Čínské adresy IPv6 představují pouze 0,29% globálních adres IPv6, v roce 2011 Zatímco Čína je na globálním třetím místě.
IPv6 je někdy vyžadován jako jediný prostředek propojení s mobilními mobilními terminály v Asii ; rychle tomu tak bude i v Evropě, kdy bude muset být stará řešení propojení založená na protokolech GSM nahrazena řešeními IP. Kromě toho, jak se mobilní použití vyvíjí směrem k trvalému připojení IP, bude velmi obtížné oslovit velmi velký počet mobilních terminálů ( smartphonů ) s adresováním IPv4 (dokonce s NAT).
Zpráva OECD zveřejněná v roce 2006dubna 2010naznačuje, že úroveň přijetí protokolu IPv6 je stále nízká, přičemž 0,25 až 1% uživatelů používá protokol IPv6. Nativní přenos IPv6 představuje 0,3% provozu AMS-IX . Na konci roku 2009 bylo viditelných 1 851 čísel AS IPv6, přičemž počet se za dva roky zdvojnásobil.
v prosince 2010, Google odhaduje, že počet uživatelů IPv6 její internetové vyhledávací služby by byl kolem 0,25%.
Případ WikipedieTýmy Wikipedie připravují tento technický aspekt od roku 2008, po pokusu v roce 2006. Byla vytvořena kontrolní stránka, která sleduje jeho pokrok.
Po účasti nadace na zkušebním dni roku 2011. Wikipedia umožňuje svým uživatelům plně využívat své služby pomocí protokolu IPv6 v den spuštění.
Světový den IPv6The 8. června 2011Internet Society (ISOC) hostil Světový den IPv6, kde prodejci a lokalit byli vyzváni, aby vyzkoušet tuto technologii ve velkém měřítku. Této akce se zúčastnily společnosti Google, Facebook, Yahoo!, Akamai a Limelight Networks. Google odhaduje, že tento test neovlivní 99,95% uživatelů. Statistiky předložené společností Yahoo ukazují, že bylo ovlivněno 0,022% uživatelů jejich stránek, zatímco 0,229% používalo protokol IPv6.
Legislativní vývojVe Francii zákon o digitální republice stanoví povinnou kompatibilitu produktů IPv6 prodávaných z EU1 st 01. 2018.
Někteří, jako Randy Bush, kritizovali způsob, jakým byla zpracována fáze přechodu na IPv6, což naznačuje, že obtíže a náklady na přechod byly minimalizovány, že adresy IPv6 jsou distribuovány příliš velkoryse, že úroveň současného provozu není dovolte nám tvrdit, že směrovače jsou schopny dosáhnout stejného výkonu jako u protokolu IPv4, že adaptace protokolu je neúplná (zejména SNMP a firewally) a že očekávané výhody (pokud jde o eliminaci NAT a agregaci směrovací tabulky internetu) byly nadhodnoceny.
Na druhou stranu mohou některé operační systémy, které mají duální zásobník, ale nemají funkční připojení IPv6, způsobit neobvyklé zpoždění při přístupu k serverům, které mají jak adresu IPv6, tak adresu IPv6. Adresa IPv4, přičemž adresa IPv6 se používá jako priorita než se po určité době uchýlíte k adrese IPv4.
V roce 2011 vedla politika partnerského vztahu určitých poskytovatelů přístupu k rozdělení IPv6 internetu. Uživatelé Hurricane Electric (AS 6939) nemohou například komunikovat s uživateli Cogent (AS 174) nebo Level 3 (AS 3356). Tento problém příležitostně ovlivňuje také IPv4 Internet.
Brzdy při nasazeníPřekážky při zavádění protokolu IPv6 jsou mimo jiné tyto:
Pokud jde o vývoj podpory IPv6 mezi poskytovateli obsahu a služeb, problém se někdy srovnává s problémem slepice a vejce:
Podle studie zveřejněné v října 2009, dodavatelé označují jako hlavní překážky následující:
Hlavní faktory rozvoje jsou:
Pokud jde o problémy, s nimiž se setkávají poskytovatelé internetových služeb, kteří nasadili protokol IPv6:
Obecně tržní produkty určené pro širokou veřejnost nemají možnost aktualizace.
V roce 2014 podpora protokolu IPv6 ještě není kritériem volby pro konečného spotřebitele. Pokud hlavní aplikace již nebude přístupná v protokolu IPv4, bude nepochybně přezkoumána důležitost tohoto kritéria. Společnosti jsou však tomuto problému pozornější a vyhýbají se investicím do vybavení, které by mohlo být nekompatibilní s IPv6.
Zákazníci s pouze jednou adresou IPv6 by se mohli objevit kolem roku 2014, problém připojení k internetovým serverům, které mají pouze jednu adresu IPv4, tedy v praxi nastane u internetových zákazníků, kteří nemají adresu IPv4. Dual stack (adresy IPv4 a IPV6). Technický problém představuje také přístup k serverům IPv6 z klientů IPv4.
Problémy jsou tedy již Viditelné týkající se zejména mobilního přístupu k internetu , který často přiděluje pouze nesměrovatelné soukromé adresy IPv4, ale připojený k proxy serverům HTTP poskytovaným provozovatelem přístupové sítě, s někdy neuspokojivým výkonem a problémy s omezením komunikační protokoly podporované tímto typem tunelů, ale také stabilita dočasných relací. Jiná řešení využívající dynamický NAT mají další problém související s hladomorem portů dostupných ve směrovačích NAT sdílených několika klienty IPv4 pro optimální použití se stále interaktivnějšími aplikacemi aktuálního webu, které vyžadují mnoho portů pro každého uživatele; další řešení založená na překladu protokolu v tunelu (6to4 nebo Teredo) také představují podobné problémy s výkonem a náklady na implementaci, které by pouze nativní nasazení IPv6 mohlo vyřešit lepším kompromisem mezi výkonem, náklady na implementaci a provozními náklady: protože již velmi časté problémy existují na mobilním přístupu 3G a zákazníci těchto sítí je pozorují i při velmi mírném použití (když jsou náklady na přístup již vysoké), přechod na další úroveň sítí 4G + ( například LTE ) nemůže být ekonomicky životaschopný bez přechodu na nativní směrování IPv6 , bez tunelu nebo adaptačního proxy, kdykoli je to možné (mnoho aplikací a webů bude muset být upraveno tak, aby byly přímo přístupné v IPv6, aniž by tyto úpravy vyžadovaly, pokud si chtějí zachovat přijatelný výkon pro své klienty bez nativního přístupu IPv4).
Některá zařízení by sice potřebovala pouze aktualizaci firmwaru pro IPv6, ale není jisté, že jejich výrobci investují do této cesty, až se prodej produktů IPv6 Ready ukáže jako výhodnější.