本章將說明
IPv6 標頭架構，並與 IPv4 標頭做比較。並將討論 IPv6 新出現的 Extension
標頭。
瞭解通訊協定標頭架構與伴隨的資訊型態，是處理通訊協定的首要基本功。對此瞭解有助
於確認通訊協定最佳組態方式與選項用途。在問題修復時，亦有助於確認可能的問題來源
與爭議。
IPv6 封包標頭架構規格定義於 RFC 2460。標頭擁有固定長度 40 位元組。針對 Source 與
Destination 位址兩個欄位分別使用 16 位元組（128 位元），因此通用標頭訊息僅 8 位元
組。
Base IPv6 標頭因此比 IPv4 標頭更簡單精實，可做更有效率的處理，我們將會看到，
它擴充了通訊協定滿足未來需求更具彈性。
通用標頭架構
IPv6 移除五個來自 IPv4 的標頭：
z
z
Header Length
z
z
Identification
z
z
Flags
z
z
Fragment Offset
z
z
Header Checksum
IPv6 通訊協定架構
第三章
50
第三章
Header Length 移除是由於固定標頭長度之後已不再需要。IPv4 最小標頭長度為 20 位
元組，但若添加選項，則以
4 位元組為單位增加，擴充到 60 位元組。因此，對 IPv4 而
言，標頭總長相關資訊非常重要。在
IPv6 下，選項定義於 Extension 標頭（本章稍後將
提及）。
Identification、Flags 與 Fragment Offset 欄，皆用於分段 IPv4 標頭裡的封包。當大型封包
必須在僅支援較小封包的網路上傳送時就會產生
Fragmentation。這種狀況下，IPv4 路由
器會將封包切割成較小片段，再轉送多個封包。目的地主機會收集這些封包再重組。若只
遺失一個封包或一個封包有誤，整個傳輸過程式重來，會很沒效率。
IPv6 下，主機透過
RFC 1981 裡定義的 Path MTU Discovery 處理程序，得知 Path Maximum Transmission Unit
（
MTU）大小。IPv4 裡的 Don't Fragment Bit（DF Bit）就是用於 Path MTU Discovery。
若路由器因封包大小無法轉送封包，又因為設定了
DF Bit 而不能分段，會回傳 ICMP 的
「
Packet Too Big」訊息給來源端點。若傳送 IPv6 的主機要分段封包，它會使用 Extension
標頭來做。
IPv6 路由器會依循不分段封包的路徑，就像在 IPv4 裡那樣。因此路由器一定
會回傳「
Packet Too Big」訊息給來源端點。這就是IPv6 標頭移除 Identification、Flags 與
Fragment Offset 欄位，由來源主機視需求決定是否插入 Extension 標頭的理由。稍後本章
會解釋
Extension 標頭。
第四章解說 Path MTU Discovery。
移除
Header Checksum 欄是為了改善處理速度。若路由器不必檢查與更新 checksum，就能
更快處理。
IPv4 開發之際，在媒體存取層作 checksum 還不普遍，因此 checksum 欄出現
在
IPv4 標頭很合理。而今，未偵測到錯誤與錯誤路由封包的風險非常小。傳輸層（UDP
與
TCP）下還是有 checksum 欄。使用 IPv4，UDP checksum 為選擇性，使用 IPv6，UDP
checksum 為強制性。由於 IP 屬於
盡力傳送
（
best-effort delivery）通訊協定，確保完整性
是上層通訊協定的責任。
Traffic Class 欄取代 IPv4 的「Type of Service」欄。IPv6 有不同的機制處理偏好。IPv4
裡的
Protocol Type 欄更名為 Next Header 欄，而 Time-to-Live（TTL）欄則更名為 Hop
Limit。Flow Label 欄為加入的欄位。
IPv6 通訊協定架構
51
IPv6 標頭欄位
熟悉
IPv6 標頭欄位，可更瞭解 IPv6 運作方式。
圖
3-1 提供了 IPv6 標頭概述。這些欄位於下列清單有詳盡探討。
圖
3-1 IPv6 標頭欄位
圖
3-1 顯示了即便標頭總共 40 位元組，為預設 IPv4 標頭的兩倍，但其實很有效率，因為
大部份標頭已由兩組
16 位元組的 IPv6 位址填滿。剩下只有 8 位元組給其餘標頭資訊。
Version（4
位元
）
此
4 位元欄位內容為通訊協定版本。在 IPv6 下，數字為 6。版本編號 5 不能用，因為
已被指派給實驗性資料流通訊協定（
RFC 1819）。
Traffic class（1
位元組
）
此欄位置換
IPv4 的 Type of Service 欄。幫助即時資料處理，與需要特殊處理的其他
資料，而傳送節點與轉送的路由器可以利用它確認與辯識
IPv6 封包裡各種類別與優
先權。
RFC 2474「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6
Headers」說明如何利用 IPv6 的 Traffic Class 欄。RFC 2474 用 DS Field 這個字指 IPv4
標頭的
Type of Service 欄，以及 IPv6 標頭的 Traffic Class 欄。
通訊協定版本
用來辯認
IPv6 封包中不同的優先權。
更多資訊請參考
RFC 2474。
IPv6 標頭後所攜帶的資料長度。
用來為路由上的封包依序貼上標籤，
使處理更有效率。
Extension 標頭包含的通訊協定數字或值。
請參閱表
3-1。
中繼器（
hops）數量值。
每經過一個路由都會將之減
1。
52
第三章
參考第五章可瞭解 Traffic Class 欄使用的更多資訊。
Flow label（20
位元
）
此欄位識別為促進即時流量封包處理而必須一視同仁的封包。傳送主機可以一組選項為
封包依序貼上標籤。路由器對資料流保持追蹤，且能夠更有效率處理屬於相同資料流的
封包，因為無須重新處理每個封包標頭。資料流標籤與來源端位址可以當成資料流唯一
識別。不支援
Flow Label 欄位功能的節點，轉送封包時需傳送未經更動的欄位，接收封
包時則忽略該欄位。所有屬於相同資料流的封包必須擁有相同
Source 與 Destination IP
位址。
使用 Flow Label 欄屬實驗性質，撰文此時仍處於 IETF 討論狀態。參考第五章
可瞭解更多資訊。
Payload length（2
位元組
）
此欄定義
負載
（
payload）── 例如 IPv6 標頭後所攜帶的資料長度。IPv6 計算方式與
IPv4 不同。IPv4 的 Length 欄包含 IPv4 標頭長度，但 IPv6 的 Payload Length 欄僅接續
IPv6 標頭後的資料。Extension 標頭被視為負載的一部份，因此會計算進去。
事實上
2 位元組的 Payload Length 欄將最大封包負載大小限制在 64 KB。IPv6 有
Jumbogram Option，在必要時可支援更大封包。Jumbogram Option 攜於 Hop-by-Hop
Option 標頭（將於本章稍候探討）內。Jumbograms 只有在 IPv6 節點附加至連結 MTU
大於
64 KB 連結時才會派上用場，它們定義於 RFC 2675。
Next Header（1
位元組
）
IPv4 下，此欄位稱之為 Protocol Type 欄，但 IPv6 將之更名，反映 IP 封包新的組織方
式。若下一個標頭為
UDP 或 TCP，此欄內容為與 IPv4 相同通訊協定編號，例如 TCP
的通訊協定編號
6，或 UDP 的 7。但若在 IPv6 使用 Extension 標頭，此欄內容則為下一
個
Extension 標頭型態。Extension 標頭定位在 IP 標頭與 TCP 或 UDP 標頭之間。表 3-1
列出了
Next Header 欄可能值。IPv6 相關新標頭以粗體顯示。
IPv6 通訊協定架構
53
表
3-1 Next Header 欄位值
值
說明
0
IPv4 標頭：保留未使用
IPv6 標頭：Hop-by-Hop Option 標頭之後
1
Internet Control Message Protocol（ICMPv4）—IPv4 支援
2
Internet Group Management Protocol（IGMPv4）—IPv4 支援
4
IPv4
5
Stream Protocol（RFC 1819）
6
TCP
8
Exterior Gateway Protocol（EGP）
9
IGP
──
任一私有內部閘道器（用於
Cisco IGRP）
17
UDP
41
IPv6
43
路由標頭
44
分段標頭
45
域間路由通訊協定（
Interdomain Routing Protocol；IDRP）
46
資源預留通訊協定（
Resource Reservation Protocol；RSVP）
47
一般路由封裝（
General Routing Encapsulation；GRE）
50
Encapsulating Security Payload 標頭
51
身份認證標頭
58
ICMPv6
59
IPv6 的 No Next Header
60
Destination Options 標頭
88
EIGRP
89
OSPF
103
PIM
108
IP負載壓縮通訊協定（IP Payload Compression Protocol）
115
Layer 2 Tunneling Protocol（L2TP）
132
Stream Control Transmission Protocol（SCTP）
135
Mobility Header（Mobile IPv6）
54
第三章
值
說明
140
Shim6（RFC 5533）
143–252
未指派
253, 254
用於實驗與測試性質（
RFC 3692）
255
保留
標頭型態編號源自通訊協定型態編號相同範圍數字，因而不致混淆。
[54]
在
http://www.iana.org/assignments/protocol-numbers 可找到現行清單。
Hop limit（1
位元組
）
此欄與
IPv4 的 TTL 欄類似。最初，IPv4 TTL 欄內含秒數，指出封包被丟棄前在網路裡
停留了多久時間。事實上，
IPv4 路由器每跳一個點就減去此值。此欄在 IPv6 裡更名為
Hop Limit 反映這樣的處理。此欄位裡的值表示中繼器（hops）數量。每個轉送節點都
會將此數字減
1。若路由器接收 Hop Limit 為 1 的封包，會被減成 0，丟棄封包，然後
回傳
ICMPv6 訊息「Hop Limit exceeded in transit」給傳送者。
Source address（16
位元組
）
此欄內容為封包發起者
IP 位址。
Destination address（16
位元組
）
此欄內容為封包預期接收者
IP 位址。可以是最終目的地，或在出現 Routing 標頭時，可
為下一個中繼路由器位址。
圖
3-2 顯示了追蹤檔 IPv6 標頭。
IPv6 通訊協定架構
55
圖
3-2 追蹤檔的 IPv6 標頭
此追蹤檔顯示所有探討的標頭欄位，說明它們在追蹤檔裡的呈現方式。
Version 欄為 6
指
IPv6。Traffic Class（Priority）與 Flow Label 欄在此封包裡未使用，設為 0。Payload
Length 為 40，且 Next Header 值設為 58 指 ICMPv6。Hop Limit 設為 128 且 Source 與
Destination 位址內含我的 IPv6 節點 link-local 位址。細節資訊視窗第一行顯示
Ethertype
0x86DD
。此值指出這是
IPv6 封包。若為 IPv4 封包，值為
0x0800
。此欄位可用於設定分析
器過濾所有原生
IPv6 封包。
分析器工具程式可以以不同方式解碼。若使用其他分析器版本或型態，解碼看
起來就會稍有不同。差異不在封包，而是封包在分析器介面裡的呈現方式。
Extension 標頭
IPv4 標頭可以為了 Security Options、Source Routing 或 Time stamping 這類特殊選項，從
最小值
20 位元組擴充到最大值 60 位元組。此功能極少使用，因為會導致效能衝擊。例
如，
IPv4 硬體轉送實作就必須傳遞涵蓋選項的封包給主要處理器（軟體處理）。
簡化封包標頭，可以加快處理程序。
IPv6 提供新的方式處理選項，充份改善處理程序：
它以所謂
Extension
標頭
的方式處理額外選項。
Extension 標頭只在選項需要時才插入封
包。大部份情況下，只有最終目的地要處理
Extension 標頭，中間裝置不用。
56
第三章
時下
IPv6 規格文件定義六個 Extension 標頭，所有 IPv6 節點皆須支援：
z
z
Hop-by-Hop Options 標頭
z
z
Routing 標頭
z
z
Fragment 標頭
z
z
Destination Options 標頭
z
z
Authentication 標頭
z
z
Encapsulating Security Payload 標頭
IPv6 封包裡可以有 0 個、1 個甚至 1 個以上的 Extension 標頭。Extension 標頭位於 IPv6
標頭與上層通訊協定標頭之間。每個
Extension 標頭僅由 IPv6 標頭 Destination 位址裡認
定的節點檢查與處理。若
Destination address 欄裡的位址為多點傳送位址，則 Extension 標
頭由屬於該多點傳送群組的所有節點檢查與處理。
Extension 標頭必須由出現在封包標頭
裡的確切順序處理。
只有目的地節點處理
Extension 標頭的規則有個例外。若 Extension 標頭為 Hop-by-Hop
Options 標頭，則其攜帶的資訊必須由封包路徑沿線所有節點檢查與處理。如有 Hop-by-
Hop Options 標頭，必須緊接於 IPv6 標頭後。會以 IPv6 標頭 Next Header 欄值為 0 的方式
表示（見本章先前表
3-1）。
前四個 Extension 標頭說明於 RFC 2460。Authentication 說明於 RFC 4302，
而
Encapsulating Security Payload 標頭則在 RFC 4303 裡。Extension 標頭的
未來更新將於
RFC 6564 定義。
這種架構對未來必須開發額外
Extension 標頭來說非常彈性。可定義新 Extension 標頭使
用之，無須變更
IPv6 標頭。定義 Mobile IPv6（RFC 6275）的 Mobility 標頭就是不錯的例
子，這將於第八章探討。
圖
3-3 說明了 Extension 標頭使用方式。
IPv6 通訊協定架構
57
圖
3-3 Extension 標頭的使用
每個
Extension 標頭長度為八位元組倍數，因此接續標頭一定是對齊的。若節點被要求
處理下一個標頭，但無法辯識
Next Header 欄裡的值，就必須拋棄封包並回傳 ICMPv6
Parameter Problem 訊息給封包來源。
ICMPv6 訊息詳細內容，請參考第四章。
若在單一封包中使用一個以上的
Extension 標頭，應使用下列標頭順序（RFC 2460）：
1. IPv6 標頭
2. Hop-by-Hop Options 標頭
3. Destination Options 標頭（由 IPv6 Destination 位址欄裡出現的第一個目的地處理的
選項，加上列於
Routing 標頭裡接續的目的地）
4. Routing 標頭
5. Fragment 標頭
6. Authentication 標頭
7. Encapsulating Security Payload 標頭
8. Destination Options 標頭（只有封包最後目的地要處理的選項）
9. Upper-Layer 標頭
58
第三章
RFC 2460 留下詮釋的空間。雖然這是建議順序，但 IPv6 節點一定會試圖以各種順序處
理
Extension 標頭。不過還是強烈建議 IPv6 封包來源使用建議的順序，除非有新規格文件
修訂。
在
IPv4 裡封裝 IPv6 時，Upper-Layer 標頭可以是另一個 IPv6 標頭，且可包含必須依循相
同規則的
Extension 標頭。
Hop-by-Hop Options 標頭
Hop-by-Hop Options 標頭攜有必須由封包沿途路徑所有節點檢查的選擇性資訊。它必須緊
接在
IPv6 標頭後，並以 Next Header 值為 0 的方式表示。舉例來說，Router Alert（RFC
2711）使用 Hop-by-Hop Options 指出像 Resource Reservation Protocol（RSVP）這類通訊
協定、
Multicast Listener Discovery（MLD）訊息，或 Jumbogram Option。使用 IPv4，路
由器決定是否需要確認資料流的唯一方式是：在整個資料流裡至少局部解析上層資料。這
種處理方式會嚴重拖慢路由處理過程。使用
IPv6，缺乏 Hop-byHop Options 標頭時，路由
器知道它不需要處理路由器專用資訊，並能立刻將封包路由至最後目的地。如有
Hop-by-
Hop Options 標頭，路由器只需要確認這個標頭，不必進一步查探進入封包。
Hop-by-Hop Options 標頭格式如圖 3-4 所示。
圖
3-4 Hop-by-Hop Options 標頭格式
以下列出各欄說明：
Next Header（1
位元組
）
Next Header 欄確認接在 Hop-by-Hop Options 標頭後的標頭型態。Next Header 欄使用表
3-1 所列的值，本章稍早已做說明。
選項型態
選項資料長度
接續標頭識別符型態。
參考表
3-1。
含括一或多個選項
以八位元組為單位的
Hop-by-Hop 選項標頭長度，
不包括第一組八位元組。
IPv6 通訊協定架構
59
Extension Header Length（1
位元組
）
此欄以八位元組為單位確認
Hop-by-Hop Options 標頭長度。長度計算不包括第一個八位
元組。所以若標頭比八位元組還短，此欄內容值為
0。
Options（
變量
）
可為一或多個選項。選項長度可變動，由
Header Extension Length 欄決定。
Option Type 欄為 Options 欄第一個位元組，內容為處理的節點無法識別此選項時，如何處
理選項的資訊。前兩個位元指定採取動作：
z
z
00：跳過並繼續處理。
z
z
01：丟棄封包。
z
z
10：丟棄封包並傳送 ICMP Parameter Problem, Code 2 訊息至封包 Source 位址，點出
不認識此選項型態。
z
z
11：僅在目的地非多點傳送位址時丟棄封包，並傳送 ICMP Parameter Problem, Code
2 訊息至封包 Source 位址。
Options Type 欄第三位元指出在路由中選項資訊可改變（值 1），或不可改變（值 0）。
選項型態
Jumbogram
Hop-by-Hop Option Type 支援 IPv6 Jumbograms 傳送。IPv6 Payload Length 欄支援最大封
包
65,535 位元組。Jumbo Payload Option（RFC 2675）允許傳送更大封包。
IPv6 標頭帶有 Jumbo Payload 選項的封包裡，Payload Length 欄位設定為 0。Next Header
欄內容為值
0，表示 Hop-by-Hop Options 標頭。Option Type 值為 194 表示 Jumbo Payload
選項。
Jumbo Payload Length 欄有 32 位元，因此支援介於 65,536 與 4,294,967,295 位元組
的封包傳輸。
RFC 2675 還定義在需要支援 Jumbograms 傳送的主機中必須實作的 UDP 與
TCP 擴充。Jumbograms 路徑上所有裝置都必須支援此選項。
選項路由器警示
此
Option Type 指示路由器，該封包內含重要訊息轉送封包時必須處理。此選項現在大多
供
MLD（Multicast Listener Discovery）與 RSVP（Resource Reservation Protocol）使用。
它定義於
RFC 2711，而該 RFC 已由 RFC 6398 更新。
60
第三章
RSVP 控制內含必須由沿途路由器詮釋或更新的資訊。這些控制封包使用 Hop-by-Hop
Options 標頭，因而僅路由器處理封包，正規資料封包沒有這類 Extension 標頭，因此會立
即轉送路由器無須做進一步檢查。
Option Type 欄前三個位元設定為 0。不認得這個選項的路由器會忽略並轉送封包。第一個
位元組剩下的五個位元中，選項型態
5 已定義。Option Data Length 欄內容為值 2，表示接
下來欄位值為兩個位元組長度（參考圖
3-4）。
此 Router Alert 值清單可於 http://www.iana.org/assignments/ipv6-routeralert-
values 找到。
圖
3-5 顯示了追蹤檔裡的 Hop-by-Hop Options 標頭。
圖
3-5 追蹤檔裡的 Hop-by-Hop Options 標頭
螢幕截圖顯示了封包編號
10 的詳細內容。這是 MLDv2 Multicast Listener Report
Message。如前面所述，這些多點傳送註冊訊息必有 Hop-by-Hop Options 標頭（Next
Header 值 0），因為這是路由器無須轉送的封包，但它必須處理內容資訊。你會發現 Hop
Limit 設為 1 指出這是 MDL 訊息；Destination 位址
ff02::16
指 MLDv2 路由器多點傳
送位址；
Hop-by-Hop Options 標頭內容值 58 指 ICMPv6 下一個標頭欄位；Length 欄與
Router Alert 選項型態 5 的 value 欄為 0 指 MLD。
IPv6 通訊協定架構
61
路由標頭
Routing
標頭
提供一或多個封包路徑到其目的地間應拜訪的中間節點清單。在
IPv4 世界，
稱之為
Loose Source Route 選項。Routing 標頭可由前一個標頭裡的 Next Header 值設為 43
辯識。圖
3-6 顯示了 Routing 標頭格式。
圖
3-6 Routing 標頭格式
以下列出各欄位說明：
Next Header（1
位元組
）
Next Header 欄確認 Routing 標頭之後的標頭型態。使用與 IPv4 Protocol Type 欄位裡的
相同值（見本章先前表
3-1）。
Extension Header Length（1
位元組
）
此欄識別以八位元組為單位的
Routing 標頭長度。長度計算不包含第一組八位元。
Routing Type（1
位元組
）
此欄確認
Routing 標頭型態。RFC 2460 陳述的 Routing Type 0 基於安全性理由已被 RFC
5095 推翻。Mobile IPv6 規格文件定義 Routing Type 2（此規格文件於第八章探討）。撰
文此時有部份草案仍在處理中，它們定義名為
Segment Routing 標頭的新片段路由結構
與新路由標頭型態。本章最後
draft 處可以找到這些草案。這些規格文件能否能出現，
在你讀到這裡時就會知道。
Segments Left（1
位元組
）
此欄確認封包抵達其最終目的地前，還有多少節點要拜訪。
接續標頭的識別符長度。
參考表
3-1。
路由標頭識別符型態。
視路由型態而定。
以八位元組為單位的路由標頭長度，
不包括第一組八位元組。
直至最終目的地的表列節點數。
62
第三章
Type-Specific Data（
變動長度
）
此欄長度端視
Routing Type 而定。完整標頭必為八位元倍數。
若處理
Routing 標頭的節點無法確認 Routing Type 值，將視 Segments Left 欄內容採取
行動。若
Segments Left 欄未涵蓋任何需拜訪節點，節點必須忽略 Routing 標頭接著處理
封包下一個標頭，這是由
Next Header 欄位值決定。若 Segments Left 欄非零，節點必須
丟棄封包並傳送
ICMP Parameter Problem, Code 0 訊息給封包 Source 位址，指出不認識
的
Routing Type。若轉送節點因下一個連結 MTU 太小無法處理封包，會丟棄封包並傳送
ICMP Packet Too Big 訊息回傳予封包來源。
圖
3-7 顯示了追蹤檔裡的 Type 2 Routing 標頭。
圖
3-7 追蹤檔裡的 Routing 標頭 Type 2
為表示
Type 2 Routing 標頭必須採取 Mobile IPv6 追蹤，此規格文件定義這類 Routing 標頭
型態。
IPv6 標頭裡的 Next Header 欄以顯示值 43 表示 Routing 標頭。Routing 標頭涵蓋本
段稍前探討的欄位。路由標頭中
Next Header 值為 135 時指出它是 Mobility 標頭。Header
Length 內容為兩個八位元組，會被添加為總長 16 位元組的長度（一個位址）。Segments
Left 欄內容為值 1，因為 Options 欄裡為一筆位址紀錄。最後，Options 欄會列出帶有本地
位址的
Home Address 選項。
參考第八章可以找到在 Mobility 上使用 Routing 標頭的方式。
IPv6 通訊協定架構
63
關於新
Routing 標頭選項的例子，可以參考 RFC 6554「An IPv6 Routing Header for Source
Routes with the Routing Protocol for Low-Power and Lossy Networks（RPL）」。在 Low-
power and Lossy Networks（LLNs）下，路由器記憶體多半相當有限，僅允許少量預設路
由且沒有其他目的地。這份
RFC 定義 Source Routing Header（SRH），嚴格限定 RPL 路
由器間使用。
Fragment Header
要傳送封包至
IPv6 目的地的 IPv6 主機，使用 Path MTU 探索可確認為到達目的地的路徑
上最大封包大小。若被傳送的封包大於支援的
MTU，則來源主機會分段處理封包。不同
於
IPv4 的是，使用 IPv6 時路徑沿途的路由器不會分段封包。分段動作只發生在傳送封包
的來源主機。目的地主機進行重新組裝。
Fragment 標頭可由前一個標頭的 Next Header 值
為
44 確認。Fragment 標頭格式顯示如圖 3-8。
圖
3-8 Fragment 標頭格式
以下列出各欄位說明：
Next Header（1
位元組
）
Next Header 欄確認接在 Fragment 標頭後的標頭型態。使用與 IPv4 Protocol Type 欄相同
值。（見表
3-1）
Reserved（1
位元組
）
未使用，設為
0。
接續標頭識別符型態。
參考表
3-1。
起始原始封包相關封包資料以八位元組
為單位的
offset。
來源節點為辨識所有屬於原始封包的封包
所產生的識別符。
值
1 = 更多分段。值 0 = 最後分段。
未使用；設為零。
未使用；設為零。
64
第三章
Fragment Offset（13
位元
）
此封包相對於原始封包起始資料的八位元組單位資料偏移量。
Reserved（2
位元
）
未使用，設為
0。
M-Flag（1
位元
）
值
1 指出有更多分段，值 0 則指最後分段。
Identification（4
位元組
）
來源主機為確認所有封包屬於原始封包所產生，此欄通常以計數器的方式實作，每個由
來源主機分段的封包必需加一。
Fragment 標頭未如 IPv4 含括 Don't Fragment 欄。不需要，因為 IPv6 下的路
由器不再需要分段。只有來源主機可以分段封包。
初始未分段封包稱之為
原始封包
。未分段部份由
IPv6 標頭加上抵達目的地路徑沿途節
點必須處理的所有
Extension 標頭（例如 Hop-by-Hop Options 標頭）組成。原始封包可分
段部份則為只需最終目的地處理的
Extension 標頭，加上 Upper-Layer 標頭與所有資料組
成。圖
3-9（RFC 2460）說明了分段處理程序。
圖
3-9 IPv6 分段
原始封包不可分段的部份會顯示於每個分段，接在
Fragmentation 標頭後再接上可分段資
料。原始封包
IPv6 標頭必須稍作修改。Length 欄會影響分段長度（除了 IPv6 標頭外）而
非原始封包長度。
IPv6 通訊協定架構
65
目的地節點收集所有分段再重新組合。所有分段必須擁有相同
Source 與 Destination 位
址，以及相同識別值以利重組。若有分段未於第一個分段抵達後
60 秒內到達目的地，
目的地會拋棄所有封包。若目的地已接收第一個分段（
Offset = 0），會回傳 ICMPv6
Fragment Reassembly Time Exceeded 訊息至來源處。
圖
3-10 顯示了 Fragment 標頭。
圖
3-10 追蹤檔裡的 Fragment 標頭
整組分段由兩個封包組成，第一個顯示如圖
3-10。IPv6 標頭中，Payload Length 欄位值
為
1,456，這是分段標頭與該分段長度，不是整個原始封包長度。Next Header 欄指定為
值
44，指的是 Fragment 標頭。此欄接著 Hop Limit 欄與 Source 與 Destination IP 位址。
Fragment 標頭裡第一個欄位為 Next Header 欄。由於這是 ping 的動作，所以內容值 58 指
ICMPv6。並且因為這是分段組第一個封包，Offset 欄值為 0 且 M-Flag 設為 1，意即不會
再有分段。
Identification 設為 1 且必須與屬於此分段組所有封包一致。圖 3-11 說明分段組
裡的第二個封包。
圖
3-11 分段組最後一個封包
66
第三章
此分段組裡第二與最後封包擁有
0x00b5
的 Offset 值，轉換十進制標記為 181，為第一個
分段長度。
M-Flag 設為 1，指出它是最末封包，告知接收的主機該重組分段了。兩個封包
裡的
Identification 欄皆設為 1。
RFC 2460 規格文件允許重疊分段，產生安全性疑慮。RFC 5722「Handling of Overlapping
IPv6 Fragments」說明安全性議題，更新 RFC 2460 並禁止重疊分段。RFC 6980 說明何
以
IPv6 分段會因去除安全性機制有效性像是 RA Guard 而變成安全問題，並禁止於傳統
Neighbor Discovery 訊息使用 IPv6 Fragmentation。
請參考第四章 Neighbor Discovery 說明，與第六章對 RA Guard 與 Fragment
標頭安全性實作的探討。
Destination Options Header
Destination Options 標頭負載只有目的地節點（IPv6 標頭裡 Destination 位址）需確認的選
擇性資訊。值為
60 的 Next Header 確認此型態標頭。如前面所述，Destination Options 標
頭可於
IPv6 封包出現兩次。當它插在 Routing 標頭前時，內容為 Routing 標頭所列路由器
需處理的訊息。當它插入上層通訊協定標頭前，內容為封包最後目的地使用的資訊。圖
3-12 顯示了 Destination Options 標頭格式。
圖
3-12 Destination Options 標頭格式
如你所見，這個格式與
Hop-by-Hop Options 標頭格式類似。以下列出各欄位說明：
於
Option Data Length 欄裡
指定的資料長度
選項型態
選項資料長度
IPv6 通訊協定架構
67
Next Header（1
位元組
）
Next Header 欄確認 Destination Options 標頭後的標頭型態。使用表 3-1 所列相同值，
如本章稍前所示。
Extension Header Length（1
位元組
）
此欄以八位元組為單位確認
Destination Options 標頭長度。長度計算不含括第一個八位
元組。
Options（
可變長度
）
選項可能一或多個。選項長度可以變動，且由
Header Extension Length 欄位決定。
Options 欄使用方式與 Hop-by-Hop Options 標頭相似，這點本章稍早已探討過。Destination
Options 標頭使用範例為 Mobile IPv6。可於第八章找到 Mobile IPv6 詳細說明。另一個已
定義的
Destination Option Header 選項為 RFC 2473 裡的 Tunnel Encapsulation Limit Option
「
Generic Packet Tunneling in IPv6 Specification」，用於限制封包進一步封裝的次數。
可於 http://www.iana.org/assignments/ipv6parameters/ 找到 Routing 與
Destination Options 標頭已定義選項的最新清單。
圖
3-13 顯示了追蹤檔裡的 Destination Options 標頭。
圖
3-13 追蹤檔裡的 Destination Options 標頭
68
第三章
為了說明
Destination Options 標頭，我們再次參考 Mobile IPv6 追蹤。這是 Binding Update
訊息。在
IP 標頭 Next Header 欄裡使用值為 60 的 Destination Options 標頭。Destination
Options 標頭 Next Header 欄位值為 135 表示 Mobile IPv6 訊息，並含括 Home Address 選
項與行動節點內部位址。
參考第八章，找出 Mobility 使用 Destination Options 標頭的方式。
新
Extension 標頭格式
除
Hop-by-Hop 與 Routing 標頭外，Extension 標頭通常只由封包最終目的地處理。實作
上，封包路徑上的裝置，像是路由器與防火牆，都有能力解析流經的封包或線速（
wire
speed）下忽略 Extension 標頭的能力。為因應真實世界實作與最佳化 Extension 標頭處理
及
Extension 標頭調查，有了 RFC 6564「A Uniform Format for IPv6 Extension Headers」定
義的新
Extension 標頭格式。圖 3-14 說明了此新格式。
圖
3-14 新 Extension 標頭格式
以下列出各欄位說明：
Next Header（1
位元組
）
Next Header 欄確認 Extension 標頭後標頭型態。使用表 3-1 相同值，如本章稍前所示。
Extension Header Length（1 位元組）
此欄以八位元為單位確認
Extension 標頭長度。長度計算不含括第一組八位元。
Options（
變動大小
）
選項長度可以變動且由
Header Extension Length 欄決定。
接續標頭識別符型態。
參考表
3-1。
指定給擴充標頭的欄位。
以八位元組為單位的擴充標頭長度，
不包括第一個八位元組。
IPv6 通訊協定架構
69
本章說明的基本
Extension 標頭格式不會改變。但若未來定義新的 Extension 標頭，就必須
依循該格式。這代表處理
Extension 標頭的所有裝置，像是防火牆，不但都必須能適切處
理基本
Extension 標頭，還要能處理使用新格式的新 Extension 標頭。
RFC 6564 定義部份規則與摘要如下：
z
z
可能的話，不應該定義新
Extension 標頭，而該使用 Destination Options 標頭新選
項。只有在不得已的情況下才定義
Extension 標頭。
z
z
不必為逐跳（
hop-by-hop）行為模式產生新標頭，且針對現有 Hop-by-Hop Options
標頭的新選項，只應於有限環境下產生。
Extension 標頭處理與標頭鏈長度
RFC 2460 裡基礎規格文件表示 Extension 標頭僅由終點站端點處理（帶有 Hop-by-Hop
Options 標頭例外）。這種架構的目的可導入新 Extension 標頭，且只有終點站端點必須更
新。這樣處理可使封包路徑沿途轉送端點透明化。實作上已顯示這麼做不一定可行。有些
路由器與各種中介裝置像是防火牆、負載平衡與封包歸類
── 亦稱為中介軟體，可能會
檢查
IPv6 基礎標頭外 IP 標頭其他部份。極常見的是，若它們不認識 Extension 標頭，可
能直接丟掉封包，導致連結性失敗。再者
Hop-by-Hop Extension 標頭通常若非高速路由器
掌控，就是於漫長路徑處理。
RFC 7045「Transmission and Processing of Extension Headers」探討了這些議題。雖然根據
這份基礎規格文件，終點站端點應丟棄不認識的
Extension 標頭，但封包路徑上的轉送裝
置不應該這麼做。另一方面，這些轉送裝置可能會丟棄它們還不認識的新定義
Extension
標頭封包。
RFC 表示這些裝置上的政策應能獨立組態。預設組態應允許所有標準的
Extension 標頭。就防火牆而言，RFC 特別要求內含標準 Extension 標頭的封包只有在內
部組態政策之下才能丟棄。以
Hop-by-Hop Extension 標頭而言，規定所有轉送裝置都應處
理，但實作者必須警覺，這通常會遇上漫長路徑。
另一個問題是：沒有單獨地點可找到所有
Extension 標頭，而數字可能會如新規格文件出
現規律成長。因此對廠商而言，很難確認在其環境下必須支援哪個
Extension 標頭。該
RFC 因而定義在 IANA（Internet Assigned Numbers Authority）IPv6 Parameters 裡必須有新
段落列出所有
IPv6 Extension 標頭型態。
70
第三章
新 IANA 針對「IPv6 Extension header」註冊段落可於 http://bit.ly/1na7H1Q
第
153 頁找到。
關於標頭鏈（包括
IPv6 標頭、所有 Extension 標頭，以及上層通訊協定標頭），以下必
須注意：在
IPv4 我們已修正上層對所有 IPv4 封包中 IPv4 選項的限制。在 IPv6 基礎規格
文件中並未限制封包裡
Extension 標頭數量。因此當封包分段後，標頭鍊可能生成多個分
段。這麼做會有問題，尤其在防火牆無法將規則套用至分段的時候，因為它們所需要的資
訊在第一個分段裡會找不到。
RFC 7112「Implications of Oversized IPv6 Header Chains」敘
述此問題並更新
RFC 2460，例如分段後資料流的第一個分段必須含括完整 IPv6 標頭鍊。
在熟悉了
IPv6 標頭與 Extension 標頭後，下一個章節將介紹 ICMPv6 的進階功能，提供給
讀者
ICMPv4 裡沒聽過的管理功能。
參考文件
以下為本章內容提及的重要
RFC 清單。有時會納入額外相關主題 RFC，以利進一步做自
我學習。
RFCs
z
z
RFC 791,“Internet Protocol,”1981
z
z
RFC 1812,“Requirements for IP Version 4 Routers,”1995
z
z
RFC 1819,“Internet Stream Protocol Version 2,”1995
z
z
RFC 1981,“Path MTU Discovery for IP version 6,”1996
z
z
RFC 2460,“Internet Protocol, Version 6（IPv6）Specification,”1998
z
z
RFC 2473,“Generic Packet Tunneling in IPv6 Specification,”1998
z
z
RFC 2474,“Definition of the Differentiated Services Field（DS Field）,”1998
z
z
RFC 2475,“An Architecture for Differentiated Services,”1998
z
z
RFC 2507,“IP Header Compression,”1999
z
z
RFC 2675,“IPv6 Jumbograms,”1999
IPv6 通訊協定架構
71
z
z
RFC 2711,“IPv6 Router Alert Option,”1999
z
z
RFC 3168,“The Addition of Explicit Congestion Notification（ECN）to IP,”2001
z
z
RFC 3175,“Aggregation of RSVP for IPv4 and IPv6 Reservations,”2001
z
z
RFC 3514,“The Security Flag in the IPv4 Header,”April 1, 2003
z
z
RFC 4301,“Security Architecture for the Internet Protocol,”2005
z
z
RFC 4302,“IP Authentication Header,”2005
z
z
RFC 4303,“IP Encapsulating Security Payload（ESP）,”2005
z
z
RFC 4305,“Cryptographic Algorithm Implementation Requirements for Encap sulating
Security Payload（ESP）and Authentication Header（AH）,”2005
z
z
RFC 4727,“Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP
Headers,”2006
z
z
RFC 5095,“Deprecation of Type 0 Routing Headers in IPv6,”2007
z
z
RFC 5350,“IANA Considerations for the IPv4 and IPv6 Router Alert Options,”2008
z
z
RFC 5722,“Handling of Overlapping IPv6 Fragments,”2009
z
z
RFC 5871,“IANA Allocation Guidelines for the IPv6 Routing Header,”2010
z
z
RFC 6105,“IPv6 Router Advertisement Guard,”2011
z
z
RFC 6275,“Mobility Support in IPv6,”2011
z
z
RFC 6398,“IP Router Alert Considerations and Usage,”2011
z
z
RFC 6434,“IPv6 Node Requirements,”2011
z
z
RFC 6437,“IPv6 Flow Label Specification,”2011
z
z
RFC 6553,“The Routing Protocol for Low-Power and Lossy Networks（RPL）Op tion
for Carrying RPL Information in Data-Plane Datagrams,”2012
z
z
RFC 6554,“An IPv6 Routing Header for Source Routes with the Routing Protocol for
Low-Power and Lossy Networks（RPL）,”2012
z
z
RFC 6564,“A Uniform Format for IPv6 Extension Headers,”2012
z
z
RFC 6621,“Simplified Multicast Forwarding,”2012
z
z
RFC 6946,“Processing of IPv6‘Atomic’Fragments,”2013
z
z
RFC 6980,“Security Implications of IPv6 Fragmentation with IPv6 Neighbor Dis
covery,”2013
72
第三章
z
z
RFC 7045,“Transmission and Processing of IPv6 Extension Headers,”2014
z
z
RFC 7112,“Implications of Oversized IPv6 Header Chains,”2014
z
z
RFC 7113,“Implementation Advice for IPv6 Router Advertisement Guard（RA
Guard）,”2014
z
z
RFC 7136,“Significance of IPv6 Interface Identifiers,”2014
草案
你可以在
http://www.ietf.org/ID.html 找到 Draft，最新版本草案可參考 https://datatracker.
ietf.org/public/pidtracker.cgi。無需版本編號，只要輸入草案名稱就會出現最新版本。若草
案未顯示，有可能已刪除。若被公佈為
RFC，則會顯示 RFC 編號。http://tools.ietf.org/wg
相當方便。更多標準化處理程序、
RFC 與草案資訊，可於附錄 A 找到。
以下是我針對本章列出的草案清單，再加上一些本章主題相關的有趣草案提供給讀者：
“
Segment Routing Architecture＂
draft-filsfils-spring-segment-routing-02
“
Segment Routing Use Cases＂
draft-filsfils-spring-segment-routing-use-cases-00
“
IPv6 Segment Routing Header（SRH）＂
draft-previdi-6man-segment-routing-header-00