IPv6

網際協議第6版（Internet Protocol version 6，縮寫：IPv6）是網際協議的最新版本，用作網際網路的協議。用它來取代IPv4主要是為了解決IPv4地址枯竭問題，同時它也在其他方面對於IPv4有許多改進。

IPv6於1998推出，設計目的是取代IPv4，然而長期以來IPv4在網際網路流量中仍佔據主要地位，IPv6的使用增長緩慢。

2026年3月28日，通過IPv6使用Google服務的使用者百分率首次達到50%。同期，Cloudflare的統計數字顯示，網際網路的整體用量有40%來自IPv6。

## 背景與目標

現今的網際網路發展蓬勃，截至2018年1月，全球上網人數已達40.21億，IPv4僅能提供約42.9億個IP位置。雖然目前的網路地址轉換及無類別域間路由等技術可延緩網路位置匱乏之現象，但為求解決根本問題，從1990年開始，網際網路工程工作小組開始規劃IPv4的下一代協定，除要解決即將遇到的IP位址短缺問題外，還要發展更多的擴充功能，為此IETF小組創建IPng，以讓後續工作順利進行。1994年，各IPng領域的代表們於多倫多舉辦的IETF會議中，正式提議IPv6發展計劃，該提議直到同年的11月17日才被認可，並於1996年8月10日成為IETF的草案標準，最終IPv6在1998年12月由網際網路工程工作小組以網際網路標準規範（RFC 2460，在2017年7月被RFC 8200替代）的方式正式公佈。

IPv6的計劃是建立未來網際網路擴充的基礎，其目標是取代IPv4，雖然IPv6在1994年就已被IETF指定作為IPv4的下一代標準，由於早期的路由器、防火牆、企業的企業資源計劃系統及相關應用程式皆須改寫，所以在世界範圍內使用IPv6部署的公眾網與IPv4相比還非常的少，技術上仍以雙架構並存居多。預計在2025年以前IPv4仍會被支持，以便給新協議的修正留下足夠的時間。

## 與IPv4比較

在Internet上，數據以分組的形式傳輸。IPv6定義了一種新的分組格式，目的是為了最小化路由器處理的訊息標頭。由於IPv4訊息和IPv6訊息標頭有很大不同，因此這兩種協議無法互操作。但是在大多數情況下，IPv6僅僅是對IPv4的一種保守擴展。除了嵌入了網際網路地址的那些應用協議（如FTP和NTPv3，新地址格式可能會與當前協議的語法衝突）以外，大多數傳輸層和應用層協議幾乎不怎麼需要修改就可以在IPv6上運行。

### 無狀態地址自動配置（SLAAC）

當連接到IPv6網路上時，IPv6主機可以使用鄰居發現協議對自身進行自動配置。當第一次連接到網路上時，主機發送一個鏈路本地路由器請求（solicitation）多播請求來獲取配置參數。路由器使用包含Internet層配置參數的路由器宣告（advertisement）報文進行回應。

在不適合使用IPv6無狀態地址自動配置的場景下，網路可以使用有狀態配置（DHCPv6）或者使用靜態方法手動配置。

## IPv6編碼

IPv6具有比IPv4大得多的編碼地址空間。IPv6採用128位元的地址，而IPv4使用的是32位元。理論上，新增的地址空間支持2128（約3.4×1038）個位址。不過，可分配的公共地址數目遠少於理論值，因為網際網路服務提供者最多只能指定IPv6地址中的64位網路前綴，而非像IPv4一樣分配完整長度的IP位址。

根據RFC 4291，IPv6地址按最高有效位（字首）分為以下類別：

地址類別｜二進制字首｜IPv6表示法

未指定｜0...0｜::/128

迴環｜0...01｜::1/128

多播｜11111111｜FF00::/8

鏈路本地｜1111111010｜FE80::/10

全域單播｜(其餘所有)｜(其餘所有)

任播地址與單播地址共用相同的地址空間。若同一IP位址分配到多台主機，則變成任播地址。

全域單播地址（Global Unicast Address）相當於IPv4的公共地址。由於IPv6的全球單播地址採用固定的64位網路前綴及64位主機地址，所以每個子網可連接的設備數量為264（43億×43億）個，在實際應用中相當於無限大。主機地址通常根據48位的MAC地址自動生成，稱為64位擴展唯一標識（Extended Unique Identifier-64），簡稱EUI-64。

長度｜3｜45 (長度可變)｜16 (長度可變)｜64

欄位｜首碼 (固定為001)｜全球路由前綴｜子網ID｜介面ID / 主機地址

截止2026年，網際網路工程任務組只分配了`001`作為全球單播地址的首碼，佔IPv6地址空間8。IANA保留了約85%地址供未來使用。

以十六進制表達示時，IP位址的最高有效位必定為2或3。

- 2000:: (0010...)
- 3000:: (0011...)

2001年9月，網際網路工程任務組網路架構委員會建議在一般情況下為家庭使用者及企業使用者提供`/48`網路，預留16位元供企業內部建立子網。每間企業最多可建立65536個子網。扣除3位首碼後，可分發的全球路由前綴有45位元長度，約為35萬億個。不過，統一為所有使用者預留16位子網ID的建議一直備受爭議，家庭使用者及中小企業顯然不需要6萬多個子網。

2011年3月，網際網路工程任務組發佈新指引，建議網際網路服務提供者為家庭使用者預留的子網ID可減少到8位元長度，以節省8位IP位址空間。部分ISP只為使用者預留4位子網ID，甚至不預留子網段。若ISP指派64位元全球路由前綴，使用者可使用NAT66分割子網。

## IPv6格式

IPv6二進位制下為128位元長度，以16位元為一組，每組以冒號「:」隔開，可以分為8組，每組以4位十六進制方式表示。例如：`2001:0db8:86a3:08d3:1319:8a2e:0370:7344` 是一個合法的IPv6位址。類似於IPv4的點分十進位，同樣也存在點分十六進位的寫法，將8組16位十六進位地址的冒號去除後，每位以點號「.」分組，例如：`2001:0db8:85a3:08d3:1319:8a2e:0370:7344`則記為`2.0.0.1.0.d.b.8.8.5.a.3.0.8.d.3.1.3.1.9.8.a.2.e.0.3.7.0.7.3.4.4`，其倒序寫法用於ip6.arpa子域名記錄IPv6地址與域名的映射。

同時IPv6在某些條件下可以省略：

- 每項數字前導的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
- 可以用雙冒號「::」表示一組0或多組連續的0，但只能出現一次：
- 如果四組數字都是零，可以被省略。遵照以上省略規則，下面這兩組IPv6都是相等的。
- 2001:db8:2de:0:0:0:0:e13
- 2001:db8:2de::e13
- 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: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位元可以用IPv4的點分十進位方式表示；因此::ffff:192.168.89.9 相等於::ffff:c0a8:5909。這種地址格式叫做IPv4映射位址。

由於同一非全局地址可能在同一範圍的多個區域中使用（例如，在兩條獨立的物理鏈路中使用鏈路本地地址 fe80::1），而且一個節點可能連接到同一範圍的不同區域的接口（例如，一個路由器通常有多個接口連接到不同的鏈路）。IPv6新增了區域ID（Zone ID）加以區分，或稱作用域ID（Scope ID）。作用域ID僅用於本地連結，使用百分號追加在地址後面。其內容特定於作業系統，例如Windows使用數字 fe80::2%3，Linux使用網卡名字 fe80::2%eth0。在URI中使用時，百分號需要進行編碼，例如 fe80::a%en1 應顯示為 http://fe80::a%25en1。

### IPv6位址的分類

IPv6位址可分為三種：

單播（unicast）位址：單播位址標示一個網路介面。協議會把送往位址的封包送往給其介面。IPv6的單播位址可以有一個代表特殊位址名字的範疇，如鏈路本地位址（link local address）和唯一區域位址（ULA，unique local address）。單播地址包括可聚類的全球單播地址(地址範圍為16進位：2000~3fff 開頭)、鏈路本地地址(地址為fe80開頭)等。

任播（anycast）位址：任播像是Unicast（單點傳播）與Broadcast（多點廣播）的綜合。單點廣播在來源和目的地間直接進行通訊；多點廣播存在於單一來源和多個目的地進行通訊。

而Anycast則在以上兩者之間，它像多點廣播（Broadcast）一樣，會有一組接收節點的位址列表，但指定為Anycast的封包，只會傳送給距離最近或傳送成本最低（根據路由表來判斷）的其中一個接收位址，當該接收位址收到封包並進行回應，且加入後續的傳輸。該接收列表的其他節點，會知道某個節點位址已經回應了，它們就不再加入後續的傳輸作業。

以目前的應用為例，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位址空間列表。全域的單播位址的分配可在各個區域網際網路註冊管理機構或 GRH DFP 頁面找到。

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

未指定位址

- ::/128－所有位元皆為零的位址稱作未指定位址。這個位址不可指定給某個網路介面，並且只有在主機尚未知道其來源IP時，才會用於軟體中。路由器不可轉送包含未指定位址的封包。

鏈路本地位址

- ::1/128－是一種單播繞回位址。如果一個應用程式將封包送到此位址，IPv6堆疊會轉送這些封包繞回到同樣的虛擬介面（相當於IPv4中的127.0.0.1/8）。
- fe80::/10－這些鏈路本地位址指明，這些位址只在區域連線中是合法的，這有點類似於IPv4中的169.254.0.0/16。

唯一區域地址

- fc00::/7－唯一區域位址（ULA，unique local address）只可用於本地通訊，類似於IPv4的專用網絡位址10.0.0.0/8、172.16.0.0/12和192.168.0.0/16。這定義在RFC 4193中，是用來取代站點本地位域。這位址包含一個40位元的偽隨機數，以減少當網站合併或封包誤傳到網路時碰撞的風險。這些位址除了只能用於區域外，還具備全域性的範疇，這點違反了唯一區域位域所取代的站點本地位址的定義。

多播位址

- ff00::/8－這個前置表明定義在"IP Version 6 Addressing Architecture"（RFC 4291）中的多播位址。其中，有些位址已用於指定特殊協議，如ff0X::101對應所有區域的NTP伺服器（RFC 2375）。

請求節點多播位址（Solicited-node multicast address）

- ff02::1:FFXX:XXXX－XX:XXXX為相對應的單播或任播位址中的三個最低的位元組。

IPv4轉譯位址

- ::ffff:x.x.x.x/96－用於IPv4映射位址。（參見以下的轉換機制）。
- 2001::/32－用於Teredo隧道。
- 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－這個站點本地前置指明這位址只在組織內合法。它已在2004年9月的RFC3879中捨棄，並且新系統不應該支援這類型的位址。

## IPv6封包

IPv6封包由兩個主要部分組成：頭部和負載。

包頭是包的前320比特，並且包含有源和目的地址，協議版本，通信類別（8位元，包優先級），流標記（20位元，QoS服務質量控制），分組長度（16位），下一個頭部（用於入棧解碼，類似IPv4中的協議號），和跳段數限制（8位元，生存時間，相當於IPv4中的TTL）。後面是負載。MTU至少1280位元組長，在常見的乙太網環境中為1500位元組。負載在標準模式下最大可為65535位元組，如果擴展報頭設置了「jumbo payload」選項，則長度值被置為0。

IPv6曾有兩個有著細微差別的版本；在 RFC 1883 中定義的原始版本（現在廢棄）和 RFC 2460 中描述的現在提議的標準版本。兩者主要在「通信類別」這個選項上有所不同，它的位數由4位變為了8位。其他的區別都是微不足道的。

由於分片（Fragmentation）只在IPv6的主機中處理，而IPv6也要求實現「MTU路徑發現」來避免數據包需要被中間設備分片，所以IPv4頭涉及分片的欄位從IPv6基本頭移出至專用的分片擴展報頭中。

在IPv6中，可選項都被從標準頭部中移出並在協議欄位中指定，類似於IPv4的協議欄位功能。

## IPv6和域名系統

IPv6地址在域名系統中為執行正向解析表示為AAAA記錄（所謂4A記錄，類似地，IPv4表示為A記錄（A record））；反向解析在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。

缺點：

- 需要在整個網際網路和它所連接到的設備上建立對IPv6的支持
- 從IPv4訪問時的轉換過程中，在網關路由器（IPv6IPv4）還是需要一個IPv4地址和一些NAT（=共享的IP位址），增加了它的複雜性，還意味著IPv6許諾的巨大的空間地址不能夠立刻被有效的使用。
- 遺留的結構問題，例如在對IPv6 multihoming支持上一致性的匱乏。

工作：

- 6bone
- ICMPv6
- IPv6 multihoming

部署進度：

- 截至2011年，全球通過IPv6第二階段認證的產品共644項，美國位居首共264種產品通過階段認證，次為日本計143項，台灣居第三，共115項完成階段認證，中國大陸居四，共68件產品通過階段認證。

### 網路層安全

網際網路安全協議（Internet Protocol Security，即IPsec）原本為IPv6開發，但是在IPv4中已經大量部署。IPsec最初是IPv6協議的強制要求，但後來改為可選項。

## 轉換機制

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

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

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

許多轉換機制使用隧道來把IPv6交通包封在IPv4網路中。這個解決方案並不完美，可能會增加延時以及引起路徑最大傳輸單元發現（Path MTU Discovery）的問題，它並不總能運行，因為過時的網路設備可能不支持IPv6。有線電視基礎上的Internet訪問就是一個例子。在現代的有線電視網路中，光纖同軸混合網（HFC）的核心（比如大型核心路由器）是有可能支持IPv6的。然而，其他網路設備（比如一個線纜數據機終端系統（CMTS）)以及使用者設備（如線纜數據機）會需要軟體更新或硬體更新來支持IPv6。這意味著線纜網路運營商必須調整適應隧道直至主幹設備支持內部雙堆疊。

### 雙堆疊

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

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

### 隧道

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

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

#### 自動隧道

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

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

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

#### 組態隧道（6in4）

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

組態隧道在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記錄會再晚一點時間加入。
- 2011年網際網路協會將6月8日定為世界IPv6日。包括Google、Facebook和雅虎在內的參與者將在當天對他們的主要服務啟用IPv6，以推進網際網路工業加速部署全面IPv6支持。
- 2017年11月26日，中共中央辦公廳、國務院辦公廳印發《推進網際網路協議第六版（IPv6）規模部署行動計劃》，要求各地各部門貫徹落實。其中主要目標包括：到2018年末，IPv6活躍用戶數達2億，網際網路使用者中占比不低於20%；到2020年末，IPv6活躍用戶數超過5億，網際網路使用者中占比超過50%，新增網路地址不再使用私有IPv4地址；到2025年末，中國IPv6網路規模、使用者規模、流量規模位居世界第一，網路、應用、終端全面支持IPv6。
- 根據科技資訊網站cnBeta.com，截至2021年4月8日，中國總共獲得IPv6地址塊數量為59,039個/32（即是每段32位元的IPv6地址數目），目前排名第二的美國擁有57,785個/32。

## 相關的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

## 參考資料

- RFC 2460 - Internet Protocol, Version 6 - 現在版本
- RFC 1883 - Internet Protocol, Version 6 - 舊版本
- RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) - 現在版本取代RFC 4214