IPv6

维基百科,自由的百科全书

跳转到: 导航, 搜索
網路協議
應用層
DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTP ·RTSP · SDP · SOAP · GTP · STUN · NTP · SSDP · 更多
传输层
TCP · UDP · TLS · DCCP · SCTP · RSVP · PPTP · 更多
网络层
IP (IPv4 · IPv6) ·

ICMP · ICMPv6 · IGMP · RIP ·

OSPF · BGP · IS-IS · IPsec · 更多
数据链路层
802.11 · 802.16 · Wi-Fi · WiMAX · ARP · RARP · ATM · DTM · 令牌环 · 以太网 · FDDI · 帧中继 · GPRS · EVDO · HSPA · HDLC · PPP · L2TP · ISDN · 更多
物理层
以太网物理层 · 调制解调器 · PLC · SONET/SDH · G.709 · 光导纤维 · 同轴电缆 · 双绞线 · 更多
本模板: 查看  討論  編輯  歷史

IPv6是互联网协议第四版(IPv4)的更新版;最初它在IETF的 IPng选取过程中胜出时称为互联网下一代网际协议(IPng),IPv6是被正式广泛使用的第二版互联网协议。

现有标准IPv4只支持大概40亿(232)个网络地址,而IPv6支持2128(約3.4 ×1038)个,这等价于在地球上每平方英寸有4.3×1020地址(6.7×1017地址/mm2)。(IPv5不是IPv4的继承,而是实验性的面向流的数据流协议,用来对声音,图像等提供支持。)

目录

[编辑] 背景与目标

促使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部署的公众网[1]与IPv4相比还非常的少[2]

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

[编辑] IPv6 编址

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

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

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

[编辑] IPv6位址表示

IPv6位址為128位元長度,但通常寫做8組每組四個十六進制的形式。例如:

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

是一個合法的IPv6位址。

如果四個數字都是零,可以被省略。例如:

2001:0db8:85a3:0000:1319:8a2e:0370:7344

等同於

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

遵從這些規則,如果因為省略而出現了兩個以上的冒號的話,可以壓縮為一個,但這種零壓縮在位址中只能出現一次。因此:

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

都是合法的地址,並且他們是等價的。但

2001::25de::cade

是非法的。(因為這樣會使得搞不清楚每個壓縮中有幾個全零的分組)

同時前導的零可以省略,因此:

2001:0DB8:02de::0e13

等於

2001:DB8:2de::e13

如果這個位址實際上是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:0000:874B:2B34或者::874B:2B34。同時,還可以使用混合符號(IPv4-compatible address),則位址可以為::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 維護官方的(英文)IPv6 位址空間列表。全域的單播位址的指定可在 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年七月的ICANN声称互联网的根域名服务器已经经过改进同时支持IPv6和IPv4[4]

缺点:

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

工作:

  • 6bone
  • ICMPv6
  • IPv6 multihoming

[编辑] 轉換機制

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

在 IPv6 主機和路由器與 IPv4 系統共存的時期時,RFC2893RFC2185 定義了轉換機制。這些技術,有時一起稱作簡單網際網路轉換(SIT,Simple Internet Transition)。[4] 包含:

  • 運作於主機和路由器之間的雙堆疊 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 設備。其它流行的封裝機制則有AYIYAGRE

[编辑] 自動穿隧

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

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

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

[编辑] 組態穿隧 (6in4)

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

組態穿隧在 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的运作。

[编辑] 参看

[编辑] 相关的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. ^ (英文) IPv6 多播位址
  3. ^ IPv6 Transition Mechanism / Tunneling Comparison
  4. ^ Rodriguez, Adolfo,John Gatrell; John Karas; Roland Peschke(2001年8月6日).Internet transition - Migrating from IPv4 to IPv6.TCP/IP Tutorial and Technical Overview.IBM.於2008年8月15日查閱.原文:“These techniques are sometimes collectively termed Simple Internet Transition (SIT).”
  5. ^ RFC 3056: Connection of IPv6 Domains via IPv4 Clouds
  6. ^ RFC 4380: Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
  7. ^ The Windows Vista Developer Story: Application Compatibility Cookbook
  8. ^ RFC 4214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
  9. ^ RFC 3053: IPv6 Tunnel Broker
  • RFC 2460 - Internet Protocol, Version 6 - 現在版本
  • RFC 1883 - Internet Protocol, Version 6 - 舊版本

[编辑] 外部链接

个人工具