跳转到内容

IPv6

本页使用了标题或全文手工转换
维基百科，自由的百科全书

这是本页的一个历史版本，由Ntoukk（留言 | 贡献）在2012年10月23日 (二) 03:25编辑。这可能和当前版本存在着巨大的差异。

網際網路协议套組
應用層
傳輸層
網路層
連結層

IPv6（Internet Protocol version 6，網際網路通訊協定第6版）是被指定为IPv4继任者的下一代網際網路协议版本，網際網路中最先出现的应用到现在依然占有优势。这是个用于封包交换互联网络的網路层协议。驱使重新设计網際網路协议的主要原因是，90年代初有人擔心10年內IPv4位址空間就會不敷用。IPv6在1998年12月被網際網路工程任務小組（Internet Engineering Task Force，简称IETF）通过公布互联网标准规范（RFC 2460）的方式定义出台。

IPv6具有比IPv4大得多的地址空间。这是因为IPv6使用了128位元的地址，而IPv4只用32位元。因此新增的地址空间支持2128（約3.4 ×1038）个位址。这一扩展提供了灵活的地址分配以及路由转发，并消除了对網路地址转换（NAT）的依赖。NAT是目前减缓IPv4地址耗尽最有效的方式，因此获得了广泛的部署。就以地球人口70億人計算，每人平均可分得約4.86 x 1028（486117667*1020）個IPv6位址。

背景与目标

促使IPv6形成的主要原因是网络空间的匮乏。從1990年開始，網際網路工程任務小組（Internet Engineering Task Force，簡稱IETF）開始規劃IPv4的下一代協定，除要解決即將遇到的IP位址短缺問題外，還要發展更多的擴充功能，為此IETF小組創建IPng，以讓後續工作順利進行。1994年，各IPng領域的代表們於多倫多舉辦的IETF會議中正式提議IPv6發展計劃，該提議直到同年的11月17日才被認可，並於1998年8月10日成為IETF的草案標準。

IPv6的计划是建立未来網際網路扩充的基础，其目标是取代IPv4，预计在2025年以前IPv4仍会被支持，以便给新协议的修正留下足够的时间。

虽然IPv6在1994年就已被IETF指定作为IPv4的下一代標準，然而在世界范围内使用IPv6部署的公众网 [2] 与IPv4相比还非常的少 [3] 。

IPv6能解決的核心問題與互聯網目前所面臨的關鍵問題之間出現了明顯的偏差，難以給互聯網的發展帶來革命性的影響。與IPv4的各種地址復用解決方案相比，IPv6能夠降低複雜性和成本，然而目前卻只有製造商較能夠感受到這個優勢，用戶和運營商無法直接感受到，導致產業鏈缺乏推動IPv6的動力。 [4]

IPv6编址

从IPv4到IPv6最显著的变化就是网络地址的长度。RFC 2373和RFC 2374定义的IPv6地址，就像下面章节所描述的，有128位长；IPv6地址的表达形式一般采用32个十六进制数。

IPv6中可能的地址有2128 ≈ 3.4×1038个。也可以考虑为1632个，因为32位地址每位可以取16个不同的值（参考组合数学）。

在很多场合，IPv6地址由两个逻辑部分组成：一个64位的网络前缀和一个64位的主机地址，主机地址通常根据物理地址自动生成，叫做EUI-64（或者64-位扩展唯一标识）

IPv6格式

参见：IPv6地址

IPv6二進位制下為128位元長度，以16位元為一組，每組以冒號":"隔開，可以分為8組，每組以4位元十六進制方式表示。例如： 

2001:0db8:85a3:08d3:1319:8a2e:0370:7344

是一個合法的IPv6位址。

同時IPv6在某些條件下可以省略，以下是省略規則

  • 規則1：每項數字前導的0可以省略，省略後前導數字仍是0則繼續，例如下組IPv6是等價的。
2001:0DB8:02de:0000:0000:0000:0000:0e13
2001:DB8:2de:0000:0000:0000:0000:e13
2001:DB8:2de:000:000:000:000:e13
2001:DB8:2de:00:00:00:00:e13
2001:DB8:2de:0:0:0:0:e13
  • 規則2：可以用雙冒號"::"表示一組0或多組連續的0，例如

如果四組數字都是零，可以被省略。例如下組IPv6是等價的。 

2001:DB8:2de:0:0:0:0:e13
2001:DB8:2de::e13

再舉一個例子，遵照以上省略規則，下面這組IPv6都是等價的 

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:57ab

不過請注意有的情形下省略是非法的，例如這個IPv6是非法的。 

2001::25de::cade

因為它有可能是下種情形之一，造成無法推斷。 

2001:0000:0000:0000:0000:25de:0000:cade
2001:0000:0000:0000:25de:0000:0000:cade
2001:0000:0000:25de:0000:0000:0000:cade
2001:0000:25de:0000:0000:0000:0000:cade

如果這個位址實際上是IPv4的位址，後32位元可以用10進制數表示；因此： 

::ffff:192.168.89.9等價於::ffff:c0a8:5909，但不等價於::192.168.89.9和::c0a8:5909。
::ffff:1.2.3.4格式叫做IPv4映射位址。而::1.2.3.4格式叫做IPv4一致位址，目前已被取消。

IPv4位址可以很容易的轉化為IPv6格式。舉例來說，如果IPv4的一個位址為135.75.43.52（十六進位為0x874B2B34），它可以被轉化為0000:0000:0000:0000:0000:ffff:874B:2B34或者::ffff:874B:2B34。同時，還可以使用混合符號（IPv4-compatible address），則位址可以為::ffff:135.75.43.52。

IPv6位址的分類

IPv6位址可分為三種：[1]

  • 單播（unicast）位址
單播位址標示一個網路介面。协议會把送往位址的封包投送給其介面。IPv6的單播位址可以有一個代表特殊位址名字的範疇，如link-local位址和唯一區域位址（ULA，unique local address）。單播地址包括可聚類的全球單播地址、鏈路本地地址等。
  • 任播（anycast）位址
任播地址也稱泛播地址，任播位址用於指定給一群介面，通常這些介面屬於不同的節點。若封包被送到一個任播位址時，則會被轉送到成員中的其中之一。通常會根據路由協定，選擇"最近"的成員。任播位址通常無法輕易分別：它們擁有和正常單播位址一樣的結構，只是會在路由協定中將多個節點加入網路中。任播地址從單播地址中分配。
  • 多播（multicast）位址
多播地址也稱組播地址。多播位址也被指定到一群不同的介面，送到多播位址的封包會被傳送到所有的位址。多播位址由皆為一的位元組起始，亦即：它們的前置為FF00::/8。其第二個位元組的最後四個位元用以標明"範疇"。
一般有node-local(0x1)、link-local(0x2)、site-local(0x5)、organization-local(0x8)和global(0xE)。多播位址中的最低112位元會組成多播群組識別碼，不過因為傳統方法是從MAC位址產生，故只有群組識別碼中的最低32位元有使用。定義過的群組識別碼有用於所有節點的多播位址0x1和用於所有路由器的0x2。
另一個多播群組的位址為"solicited-node多播位址"，是由前置FF02::1:FF00:0/104和剩餘的群組識別碼（最低24位元）所組成。這些位址允許經由鄰居發現協議（NDP，Neighbor Discovery Protocol）來解譯連結層位址，因而不用干擾到在區網內的所有節點。

特殊位址

IANA維護官方的 [5]。全域的單播位址的指定可在RIR's或 中找到 （英文）GRH DFP pages。

IPv6中有些位址是有特殊含义的：

未指定位址
  • ::/128－ 所有位元皆為零的位址稱作未指定位址。這個位址不可指定給某個網路介面，並且只有在主機尚未知道其來源IP時，才會用於軟體中。路由器不可轉送包含未指定位址的封包。
Link local位址
  • ::1/128－ 是一種單播繞回位址。如果一個應用程式將封包送到此位址，IPv6堆疊會轉送這些封包繞回到同樣的虛擬介面（相當於IPv4中的127.0.0.1）。
  • fe80::/10－ 這些link-local位址指明，這些位址只在區域連線中是合法的，這有點類似於IPv4中的169.254.0.0/16。
唯一區域位域
  • fc00::/7－唯一區域位址（ULA，unique local address）只可在一群網站中遶送。這定義在RFC 4193中，是用來取代site-local位域。這位址包含一個40位元的偽隨機數，以減少當網站合併或封包誤傳到網路時碰撞的風險。這些位址除了只能用於區域外，還具備全域性的範疇，這點違反了唯一區域位域所取代的site-local位址的定義。
多播位址
  • ff00::/8－這個前置表明定義在"IP Version 6 Addressing Architecture"（RFC 4291）中的多播位址[2][失效連結]。其中，有些位址已用於指定特殊協議，如ff0X::101將到達所有區域的NTP伺服器（RFC 2375）。
Solicited-node多播位址
  • ff02::1:FFXX:XXXX－XX:XXXX為相對應的單播或任播位址中的三個最低的位元組。
IPv4轉譯位址
ORCHID
  • 2001:10::/28－ORCHID (Overlay Routable Cryptographic Hash Identifiers) (RFC 4843)。這些是不可遶送的IPv6位址，用於加密雜湊識別。
文件
  • 2001:db8::/32－ 這前置用於文件（RFC 3849）。這些位址應用於IPV6位址的範例中，或描述網路架構。
遭捨棄或刪除的用法
  • ::/96－ 這個前置曾用於IPv4相容位址，現已刪除。
  • fec0::/10－ 這個site-local前置指明這位址只在組織內合法。它已在2004年九月的RFC3879中捨棄，並且新系統不應該支援這類型的位址。

IPv6封包

IPv6封包的架構說明。

IPv6封包由两个主要部分组成：头部和负载。

包头是包的前40字节并且包含有源和目的地址，协议版本，通信类别（8位元，包优先级），流标记（20位元，QoS服务质量控制），负载长度（16位），下一个头部（用于向后兼容性），和跳段数限制（8位元，生存时间，相当于IPv4中的TTL）。后面是负载，至少1280字节长，或者在可变MTU（最大传输单元）大小环境中这个值为1500字节。负载在标准模式下最大可为65535字节，或者在扩展包头的"jumbo payload"选项进行设置。

IPv6曾有两个有着细微差别的版本；在RFC 1883中定义的原始版本（现在废弃）和RFC 2460中描述的现在提议的标准版本。两者主要在通信类别这个选项上有所不同，它的位数由4位变为了8位。其他的区别都是微不足道的。

分段（Fragmentation）只在IPv6的主机中被处理。在IPv6中，可选项都被从标准头部中移出并在协议字段中指定，类似于IPv4的协议字段功能。

IPv6和域名系统

IPv6地址在域名系统中为执行正向解析表示为AAAA记录（所谓4A记录，类似的IPv4表示为A记录A records）；反向解析在ip6.arpa（原先ip6.int）下进行，在这里地址空间为半字节16进制数字格式。这种模式在RFC 3596给与了定义。

AAAA模式是IPv6结构设计时的两种提议之一。另外一种正向解析为A6记录并且有一些其他的创新像二进制串标签和DNAME记录等。RFC 2874和它的一些引用中定义了这种模式。

AAAA模式只是IPv6域名系统的简单概括，A6模式使域名系统中检查更全面，也因此更复杂：

  • A6记录允许一个IPv6地址在分散于多个记录中，或许在不同的区域；举例来说，这就在原则上允许网络的快速重编号。
  • 使用域名系统记录委派地址被DNAME记录（类似于现有的CNAME，不过是重命名整棵树）所取代。
  • 一种新的叫做比特标签的类型被引入，主要用于反向解析。

2002年8月的RFC 3363中对AAAA模式给与了有效的标准化（在RFC 3364有着对于两种模式优缺点的更深入的讨论）。

IPv6部署与应用

2004年7月的ICANN声称網際網路的根域名服务器已经经过改进同时支持IPv6和IPv4 [6] 。

缺点：

  • 需要在整个網際網路和它所连接到的设备上建立对IPv6的支持
  • 从IPv4访问时的转换过程中，在网关路由器（IPv6<-->IPv4）还是需要一个IPv4地址和一些NAT（=共享的IP地址），增加了它的复杂性，还意味着IPv6许诺的巨大的空间地址不能够立刻被有效的使用。
  • 遗留的结构问题，例如在对IPv6 multihoming支持上一致性的匮乏。

工作：

部署進度：

  • 目前全球通過IPv6第二階段認證的產品共644項，以國別論，美國位居首共264種產品通過階段認證，次為日本計143項，台灣居第三，共115項完成階段認證，中國大陸居四，共68件產品通過階段認證[3]。

网络层安全

Internet Protocol Security (IPsec) 原本是为IPv6开发，但是是在IPv4中第一次大量部署。最初，IPsec是IPv6协议组中不可少的一部分，[4] 但现在已经是可选的一部分。[5]

轉換機制

主条目：IPv6转换机制

在IPv6完全取代IPv4前，需要一些轉換機制[6][失效連結]使得只支援IPv6的主機可以連絡IPv4服務，並且允許孤立的IPv6主機及網路可以藉由IPv4設施連絡IPv6網際網路。

在IPv6主機和路由器與IPv4系統共存的時期時，RFC2893 和 RFC2185 定義了轉換機制。這些技術，有時一起稱作簡單網際網路轉換（SIT，Simple Internet Transition）。[7] 包含：

  • 運作於主機和路由器之間的雙堆疊IP實作
  • 將IPv4嵌入IPv6位址
  • IPv6立於IPv4之上的隧道機制
  • IPv4/IPv6报头轉換

雙堆疊

將IPv6視為一種IPv4的延伸，以共享程式碼的方式去實作網路堆疊，其可以同時支援IPv4和IPv6，如此是相對較為容易的。如此的實作稱為雙堆疊，並且，一個實作雙堆疊的主機稱為雙堆疊主機。這步驟描述於RFC 4213。

目前大部分IPv6的實現使用雙堆疊。一些早期實驗性實作使用獨立的IPv4和IPv6堆疊。

穿隧

為了連通IPv6網際網路，一個孤立主機或網路需要使用現存IPv4的基礎設施來攜帶IPv6封包。這可由將IPv6封包裝入IPv4封包的穿隧協議來完成，實際上就是將IPv4當成IPv6的連結層。

IP協議號碼的41號用來標示將IPv6資料訊框直接裝入IPv4封包。IPv6亦能將入UDP封包，如為了跨過一些會阻擋協議41交通的路由器或NAT設備。其它流行的封裝機制則有AYIYA和GRE。

自動穿隧

自動穿隧指路由設施自動決定隧道端點的技術。RFC 3056建議使用6to4穿隧技術來自動穿隧，其會使用41協議來封裝。[8] 隧道端點是由遠端知名的IPv4任播位址所決定，並在本地端嵌入IPv4位址資訊到IPv6中。現今6to4是廣泛佈署的。

Teredo是使用UDP封裝的穿隧技術，據稱可跨越多個NAT設備。 [9] Teredo並非廣泛用於佈署的，但一個實驗性版本的Teredo已安裝於Windows XP SP2 IPv6堆疊中。IPv6，包含6to4穿隧和Teredo穿隧，在Windows Vista中預設是啟動的。[10] 許多Unix系統只支援原生的6to4，但Teredo可由如Miredoo的第三方軟體來提供。

ISATAP[11] 藉由將IPv4位址對應到IPv6的link-local位址，從而將IPv4網路視為一種虛擬的IPv6區域連線。不像6to4和Teredo是站點間的穿隧機制，ISATAP是一種站點內機制，意味著它是用來設計提供在一個組織內節點之間的IPv6連接性。

組態穿隧 (6in4)

在組態穿隧中，如6in4穿隧，隧道端點是要明確組態過的，可以是藉由管理員手動或作業系統的組態機制，或者藉由如tunnel broker等的自動服務。[12] 組態穿隧通常比自動穿隧更容易去除錯，故建議用於大型且良好管理的網路。

組態穿隧在IPv4隧道上，使用網際協議中號碼的41號。

用於只支援IPv6主機的代理和轉譯

在區域網際網路註冊管理機構耗盡所有可使用的IPv4位址後，非常有可能新加入網際網路的主機只具有IPv6連接能力。對這些須要向後相容以能存取IPv4資源的客戶端，須要佈署合適的轉換機制。

一種轉換技術是使用雙堆疊的應用層代理，如網頁代理伺服器。

一些對於應用程式無法得知但在其低層使用類NAT轉換技術也曾被提出。但因為一般應用層協議所要求的能力其應用太廣，其中大部分都被認定在實際上太不可靠，並且被認為應刪除。

主要的IPv6公告

  • 在2003年，日本經濟新聞（在2003年被CNET亚洲机构引用）报告中说日本、中国和韩国声称已经决定要在网络技术中寻求领先，将部分参与IPv6的开发并在2005年开始全面采用IPv6。
  • ICANN在2004年7月20日发表声明，称DNS根服务器已经建立了对应日本（.jp）和韩国（.kr）的顶级域名服务器的AAAA记录，序列号为2004072000。对应法国的（.fr）IPv6记录会再晚一点时间加入。这就开放了IPv6的运作。
  • 2011年互联网协会将6月8日定为世界IPv6日。包括Google、Facebook和雅虎在内的参与者将在当天对他们的主要服务启用IPv6，以推进互联网工业加速部署全面IPv6支持[13]。

参看

相关的IETF工作组

  • 6bone：IPv6 Backbone
  • ipng：IP Next Generation（concluded）
  • ipv6：IP Version 6
  • ipv6mib：IPv6 MIB（concluded）
  • multi6：Site Multihoming in IPv6
  • v6ops：IPv6 Operations

參考資料

  1. ^ RFC 2373 - IP Version 6 Addressing Architecture
  2. ^ [1][失效連結]
  3. ^ 上千菁英來台 打造網路新標準 鍾榮峰/台北/中央社 2011/11/14 18:32
  4. ^ RFC 4301, IPv6 Node Requirements", J. Loughney (April 2006)
  5. ^ RFC 6434, "IPv6 Node Requirements", E. Jankiewicz, J. Loughney, T. Narten (December 2011)
  6. ^ IPv6 Transition Mechanism / Tunneling Comparison[失效連結]
  7. ^ Rodriguez, Adolfo; John Gatrell; John Karas; Roland Peschke. Internet transition - Migrating from IPv4 to IPv6. TCP/IP Tutorial and Technical Overview. IBM. 2001-08-06 [2008-08-15]. These techniques are sometimes collectively termed Simple Internet Transition (SIT). 
  8. ^ RFC 3056: Connection of IPv6 Domains via IPv4 Clouds
  9. ^ RFC 4380: Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
  10. ^ The Windows Vista Developer Story: Application Compatibility Cookbook
  11. ^ RFC 4214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
  12. ^ RFC 3053: IPv6 Tunnel Broker
  13. ^ Internet Society - World IPv6 Day. Internet Society. [2011-06-07]. 
  • RFC 2460 - Internet Protocol, Version 6 - 現在版本
  • RFC 1883 - Internet Protocol, Version 6 - 舊版本
  • RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) - 現在版本 取代 RFC 4214

外部链接

Template:Link FA

检索自“https://zh.wikipedia.org/zhwiki/w/index.php?title=IPv6&oldid=23407765”