IPv6是網際網路協議第四版（IPv4）的更新版；最初它在IETF的
IPng選取過程中勝出時稱為網際網路下一代網際協議（IPng），IPv6是被正式廣泛使用的第二版網際網路協議。

現有標準IPv4只支持大概40億（2³²）個網路地址，而IPv6支持2¹²⁸（約3.4
×10³⁸）個，這等價於在地球上每平方英寸有4.3×10²⁰地址（6.7×10¹⁷地址／mm²）。（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 2373 和RFC
2374定義的IPv6地址，就像下面章節所描述的，有128位長；IPv6地址的表達形式一般採用32個十六進位數。

IPv6中可能的地址有2¹²⁸ ≈
3.4×10³⁸個。也可以想象為16³²個因為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

等於

2001B8: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 轉譯位址

• ::ffff:0:0/96 － 用於IPv4映射位址（參見以下的
  Transition mechanisms）。
  
• 2001::/32 － 用於 Teredo
  tunneling 。
  
• 2002::/16 － 用於 6to4 。
  

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[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 系統共存的時期時，RFC2893 和 RFC2185 定義了轉換機制。這些技術，有時一起稱作簡單網際網路轉換（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 設備。其它流行的封裝機制則有AYIYA和GRE。

[編輯]
自動穿隧

自動穿隧指路由設施自動決定隧道端點的技術。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的運作。
  

[編輯]
參看

• OSI模型
  
• IPv4
  
• IP

[編輯]
相關的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 - 舊版本

[編輯]
外部連結

• The IPv6
  Portal...... All the IPv6 News
  
• linuxreviews.org:Why you want IPv6
  
• http://www.iana.org/assignments/ipv6-address-space
  
• CNET Asia Staff.（2003）. Report: Japan, China, S. Korea developing
  next Net. Retrieved January 14, 2003.
  
• http://www.moonv6.org/