本文將闡述IPv6 報頭的結構并將其與IPv4 報頭相比較。此外還將討論Extension（擴展）報頭，這是IPv6 所新加的內容。

在RFC 2460 中定義了IPv6 數據包的報頭結構。該報頭固定為40 字節長。源和目的地址各占16 字節（128 位），因此，只有8 字節是用于普通報頭信息的。

普通報頭結構

在IPv6 中，IPv4 報頭中的下面五個字段被去除了：

● Header Length（報頭長度）

● Identification（標識）

● Flags（標志）

● Fragment Offset（段偏移量）

● Header Checksum（報頭校驗和）

除去Header Length（報頭長度）字段是因為對于固定長度的報頭，它是不起作用的。在IPv4 中，報頭最短長度為20 字節，但是如果添加一些選項，則會以4字節長度遞增，最長可達60 字節。因此，對于IPv4 來說，報頭的總長度信息是很重要的。在IPv6 中，選項由擴展報頭定義（將在本章后面部分作介紹）。

Identification（標識）字段、Flags（標志）字段和Fragment Offset（段偏移量）字段處理IPv4報頭中的數據包分段。如果要在只支持小數據包的網絡中發送大數據包，就需要進行分段。在這種情況下，IPv4路由器把數據包分割成更小的片段，并轉發多個數據包。目的主機收集數據包并進行重新組合。即便只有一個數據包丟失或出錯，都需要重新進行傳輸，因此效率很低。在IPv6 中，主機通過一個叫做路徑MTU 發現（Path MTU Discovery）的過程來了解路徑最大傳輸單元（Maximum Transmission Unit，MTU）的大小。如果IPv6 的發送主機想要對數據包進行分段，就需要使用擴展報頭來實現。數據包傳輸路徑上的IPv6路由器不像在IPv4 中那樣進行數據分段。因此，在IPv6 中去除了Identification、Flags 和Fragment Offset字段并將會按需插入一個擴展報頭。擴展報頭將在本章后面進行介紹。

去除Header Checksum（報頭校驗和）字段是為了提高處理速度。如果路由器無需檢驗并更新校驗和，則處理會變得更快。校驗和的計算也是在介質訪問層完成的，這樣未檢測到的錯誤和錯誤路由的數據包所引起的風險最小。傳輸層（UDP和TCP）中有一個校驗和字段。IP 是一種“盡力而為”的傳輸協議，保證數據完整性的責任屬于其上層協議。

Type of Service（服務類型）字段由Traffic Class（流量類別）字段代替。IPv6處理參數的機制與IPv4 不同。請參考第六章來了解更多的信息。Protocol Type（協議類型）和Time-to-Live（TTL，生存期）字段被重新命名，且稍稍做了些修改。IPv6 報頭中還添加了一個Flow Label（流標簽）字段。

IPv6 報頭中的字段

對IPv6 報頭中各個字段越熟悉，你對IPv6 的工作方式越理解。

圖2-1 是IPv6 報頭的概述。將在下面的段落中詳細討論各個字段。

圖2-1 說明，即使IPv6 報頭的總長度是默認的IPv4 報頭的兩倍長，達到了40 字節，但它實際上是被簡化了的，因為報頭的絕大部分被兩個16 字節的IPv6 地址占據。這樣，只剩8 個字節可供其他報頭信息使用。

Version（版本，4 位）這是一個4 位長的字段，其中包含了協議的版本。在IPv6 中，該數目為6。不能使用版本號5，因為5 早已被分配給一個實驗性的流協議（ST2，RFC 1819）。

Traffic Class（流量類別，1 字節）該字段代替了IPv4 中的Type of Service 字段，它有助于處理實時數據以及任何需要特別處理的數據。發送節點和轉發路由器可以使用該字段來識別和分辨IPv6數據包的類別和優先級。

RFC 2474“Definition of the Differentiated Services Field (DS Field) in the IPv4and IPv6 Headers”（IPv4 和IPv6 報頭中差分服務（DS）字段的定義）文檔中解釋了如何使用IPv6 中的Traffic Class 字段。RFC 2474 使用術語DS 來指代IPv4報頭的Type of Service 字段和IPv6 報頭中的Traffic Class 字段。

Flow Label（流標簽，20 位）

該字段區分需要相同處理的數據包，以此來促進實時性流量的處理。發送主機能夠用一組選項標記數據包的順序。路由器跟蹤數據流并更有效地處理屬于相同數據流的數據包，因為他們無須重新處理每個數據包的報頭。數據流由流標簽和源節點的地址惟一標識。不支持Flow Label字段功能的節點需要在轉發數據包時不加改變地傳遞該字段，并在接收數據包時忽略該字段。屬于同一數據流的所有數據包必須具有相同的源IP 地址和目的IP 地址。

Payload Length（有效載荷長度，2 字節）

該字段指定了有效載荷，也就是在IP 報頭后攜帶的數據長度。IPv6 中的計算與IPv4 不同。IPv4 中的Length 字段包括IPv4 報頭的長度，而IPv6 中的PayloadLength（有效載荷長度）字段僅包含IPv6 報頭后的數據。擴展報頭被認為是有效載荷的一部分，因此被包括在計算之內。

由于Payload Length（有效載荷長度）字段只有2 個字節，因此數據包的有效載荷最大為64KB。IPv6 有一個Jumbogram Extension 報頭，如果有需要，它可以支持更大的數據包。只有當I P v 6 節點連接到MTU 大于6 4 K B 的鏈路時，Jumbogram 才起作用。RFC 2675 中詳細說明了Jumbogram。

Next Header（下一報頭，1 字節）

在IPv4 中，該字段為Protocol Type（協議類型）字段。在IPv6 中則被重新命名，以反映出重新組織的IP數據包。如果下一個報頭是UDP或TCP，該字段將和IPv4中包含的協議號相同，例如，TCP 的協議號為6；UDP 為17。但是，如果使用了IPv6 擴展報頭，該字段就包含了下一擴展報頭的類型，它位于IP 報頭和TCP 或UDP 報頭之間。表2-1 列舉了Next Header 字段中可能的值：

注意：報頭類型和協議類型數字的范圍是相同的，因此不應有沖突。

Hop Limit（跳數限制，1 字節）

該字段和IPv4 的TTL 字段類似。TTL 字段包含一個秒數，指示數據包在銷毀之前在網絡中逗留的時間。絕大多數路由器只是簡單地在數據包經過每一跳時將該值減1。該字段在IPv6 中被重命名為Hop Limit。現在用字段中的值標識跳數，而不是秒數。每個轉發節點對此數目減1。

Source Address（源地址，16 字節）

該字段包含數據包發送者的IP 地址。

Destination Address（目的地址，16 字節）

該字段包含數據包目的接收者的IP地址。對于IPv4，該字段總是包含數據包的最終目的地的地址。對于IPv6，如果提供了Routing（路由）報頭，則該字段包含的未必是最終地址。

圖2-2 為跟蹤文件中的IPv6 報頭。

跟蹤文件顯示了前面討論過的所有報頭字段，及其在跟蹤文件中的表示方式。其中，Version 字段值為IPv6 相應地設為6。該數據包沒有使用Priority 字段和Flow Label 字段，因此都被設為0。Payload Length 字段設為40，而Next Header 字段的值被設為58，以表示ICMPv6。Hop Limit 設為128，Source address 和Destination address 包含了我的IPv6 節點的鏈路本地地址。

擴展報頭

IPv4 報頭的長度可以從最小的20 字節擴展為60 字節，以便指定選項，如安全選項（Security Option）、源路由（Source Routing）或時間戳（Timestamping）。這項功能很少使用，因為會降低性能。例如，IPv4 硬件轉發實現必須把包含選項的數據包傳遞給主處理程序（軟件處理）。

數據包的報頭越簡單，處理過程就越快。IPv6 采用一種新方法來處理選項，顯著地改善了處理速度。它在附加的擴展報頭中對這些選項進行處理。

當前的IPv6 規范（RFC 2460）定義了六個擴展報頭：

● Hop-by-Hop Options 報頭

● Routing 報頭

● Fragment 報頭

● Destination Options 報頭

● Authentication 報頭

● Encrypted Security Payload 報頭

在IPv6 報頭和上層協議報頭之間可以有一個或多個擴展報頭，也可以沒有。每個擴展報頭由前面報頭的Next Header 字段標識。擴展報頭只被IPv6 報頭的Destination Address字段所標識的節點進行檢查或處理。如果Destination Address字段中的地址是多播地址，則擴展報頭可被屬于該多播組的所有節點檢查或處理。擴展報頭必須嚴格按照在數據包報頭中出現的順序進行處理。

上面所述的規則有個例外：只有目的節點才會處理擴展報頭。如果擴展報頭是Hop-by-Hop Options報頭，則其承載的信息必須被數據包經過路徑上的每個節點檢查和處理。如果有Hop-by-Hop Options 報頭，則必須緊接在IPv6 報頭之后。IPv6 報頭的Next Header 字段中用0 來表示Hop-by-Hop Options 報頭（參見本章前面的表2-1）。

注意： 前四個擴展報頭在RFC 2460 文檔中描述。Authentication 報頭在RFC 2402 中描述， Encrypted Security Payload 報頭在RFC 2406 中描述。

圖2-3 演示了擴展報頭的使用方式。

每個擴展報頭的字節長為8 的整數倍。因此，后面的報頭總是可以對齊。如果節點需要處理Next Header 字段，但不能識別該字段的值，那么就需要丟棄該數據包，并向數據包的發送源返回一條“ICMPv6 Parameter Problem”消息。第四章將詳細介紹ICMPv6 消息的有關細節。

如果在單個數據包中使用了多個擴展報頭，則應該使用如下的報頭順序（RFC 2460）：

1. IPv6 報頭

2. Hop-by-Hop Options 報頭

3. Destination Options報頭（用于由IPv6 目的地址字段中第一個出現的目的地

址以及隨后在Routing 報頭中列舉的目的地址進行處理的選項）。

4. Routing 報頭

5. Fragment 報頭

6. Authentication 報頭

7. Encapsulating Security Payload 報頭

8. Destination Options 報頭（用于只由數據包最終目的地址進行處理的選項）。

9. Upper-Layer 報頭

若IPv6 被封裝在IPv4 中，則Upper-Layer 報頭可以是另一個IPv6 報頭，并且可以包含符合相同規則的擴展報頭。

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 ListenerDiscovery，MLD）消息。在IPv4 中，路由器判斷是否需要檢查數據報的惟一方法是解析所有數據報中的上層數據，至少是部分解析。這極大地降低了路由處理速度。在IPv6 中，如果沒有Hop-by-Hop Options 擴展報頭，則路由器知道無須處理路由器相關的信息，因此可以立即把數據包路由到最終目的地。若存在Hopby-Hop Options 擴展報頭，則路由器只需檢查報頭，而無須深入查看數據包。

Hop-by-Hop Options 報頭的格式如圖2-4 所示。

下面對每個字段進行解釋：

Next Header（下一報頭，1 字節）

Next Header 字段標識了跟在Hop-by-Hop Options 報頭之后的報頭的類型。

Next Header 字段使用表2-1（在本章前面部分）中所列舉的值。

Header Extension Length（報頭擴展長度，1 字節）

該字段標識Hop-by-Hop Options 報頭的長度，以8 字節為單位。長度的計算不包括第一個8 字節。

Options（選項，長度不定）這可能是一個或多個選項。該選項的長度是不定的，由Header Extension Length 字段決定。

Option Type（選項類型）字段是Options 字段的第一個字節，包含了在執行處理的節點不能識別該選項時如何處理選項的信息。該值的前兩位值指定了要執行的操作。

● 值00：跳過并繼續處理。

● 值01：丟棄數據包。

● 值10：丟棄數據包并向數據包的源地址發送“ICMP Parameter Problem,Code 2”消息，指出不能識別的選項類型。

● 值11：丟棄數據包，并且在目的不是多播地址時向數據包的源地址發送“ICMP Parameter Problem, Code 2”消息。

選項類型字段的第三位指定選項信息是否能夠在傳送途中改變（值01）或不改變（值00）。

Routing 報頭

Routing報頭用來給出一個或多個數據包在到達目的地的路徑上應該經過的中間節點。在IPv4 中，這叫做Loose Source 和Record Route 選項。Routing 報頭由其前一個報頭的Next Header 值43 標識。圖2-5 說明了Routing 報頭的格式。

下面對每個字段進行解釋：

Next Header（下一報頭，1 字節）

Next Header 字段標識了Routing 報頭后的報頭的類型。它使用與IPv4 協議類型字段相同的值（參見本章前面的表2-1）。

Header Extension Length（報頭擴展長度，1 字節）

該字段標識了Routing 報頭的長度，以8 字節為單位。長度計算不包括第一個8 字節。

Routing Type（路由類型，1 字節）

該字段標識了Routing 報頭的類型。RFC 2460 說明了Routing Type 0。

Segments Left（剩余段，1 字節）

該字段標識了在數據包到達最終目的地之前還需經過多少節點。

Type-Specific Data（類型相關數據，長度不定）

該字段長取決于路由類型。該長度總是保證完整的報頭為8 字節的倍數。

如果處理Routing 報頭的節點不能識別Routing Type 值，則采取的措施取決于Segments Left 字段的內容。如果Segments Left 字段不包含任何要經過的節點，則節點必須忽略Routing報頭并處理數據包中的下一個報頭，這由Next Header字段的值決定。如果Segments Left 字段不為0，則節點必須丟棄數據包并向數據包的源地址發送“ICMP Parameter Problem, Code 0”消息，指出未識別出的路由類型。如果轉發節點因為下一鏈接的MTU 太小而不能處理數據包，它將丟棄數據包并向數據包的發送源發送“ICMP Packet Too Big”消息。

RFC 2460 中惟一描述的Routing Type 是Type Zero Routing 報頭。處理Routing報頭的第一個節點由IPv6 報頭中的Destination address 字段指定。該節點對Segments Left 字段減1，并把IPv6 報頭的Routing 報頭內的下一個地址字段插入到IPv6 的Destination address 字段。然后數據包被轉發到下一跳，按前面描述的方法處理Routing報頭，直到到達最終目的地。最終目的地是Routing Header Data字段的最后一個地址。例如，Mobile IPv6 使用Routing 報頭。任何向移動節點發送數據包的節點都將把數據包發送到該移動節點的轉交地址（care-of-address）。

它包括Routing 報頭，其中包含一條該移動節點的家庭地址。移動節點把IPv6 報頭中的目的地址和Routing 報頭中的條目進行交換，然后用家庭地址作為源地址進行應答，就如同它接收到了本地網絡的數據包一樣。要更深入討論Mobile IPv6并了解相關術語的定義，請參考第七章。圖2-6 為跟蹤文件中的Routing 報頭。

IPv6 報頭中的Next Header 字段值為43 則表示是Routing 報頭。Source address和Destination address 的前綴為“2002:”，這意味著6to4 站點。Routing 報頭包含本節先前討論的字段。Next Header 為ICMPv6，值58。Header Length 是兩個8 字節長的單元，即共16 字節長。Segments Left 字段值為1，因為在Options 字段中有一個地址條目。最后，Options 字段列舉要經過的地址。在本例中，只有一個地址條目。如果在此列舉了一些主機，則每個轉發節點（也就是IPv6 報頭中的目的IP 地址）要從該主機列表中取出下一個條目，用作IPv6 報頭中的新的目的IP 地址，對Segments Left 字段減1，并轉發數據包。重復此過程，直到到達列表中的最后一臺主機。RFC 2460 中演示了一個例子。

某源節點S 使用Routing 報頭通過中間節點I1、I2 和I3，將一個數據包發送到目的節點D。Routing 報頭的變化如表2-2 所示。

Fragment 報頭

要把數據包發送到IPv6目的地的IPv6主機使用路徑MTU發現來判斷在通往目的地的路徑上能使用的最大數據包大小。如果要發送的數據包大于所支持的MTU，源主機將對數據包進行分段處理。與IPv4不同，IPv6中的數據包不會由傳輸路徑上的路由器分段。分段只會在發送數據包的源主機上進行。目的主機則進行重新組裝。Fragment 報頭由前一報頭的Next Header 標識為值44。Fragment 報頭的格式如圖2-7 所示。

下面描述各個字段：

Next Header（下一報頭，1 字節）

Next Header字段標識了緊跟在Fragment報頭后的報頭的類型。它與IPv4 協議類型字段的值相同（參見表2-1）。

Reserved（保留，1 字節）

未使用，設為0。

Fragment Offset（段偏移量，13 位）

數據包中的數據相對于原始數據包中數據的開始的偏移量，以8 字節為單位。

Reserved（保留，2 位）

未使用，設為0。

M-Flag（M- 標志，1 位）

值為1 表示還有更多分段；值為0 表示最后一個分段。

Identification（標識，4 字節）由源主機生成，用于識別屬于原始數據包的所有數據包。該字段通常由計數器實現，每當有一個需要源主機進行分段的數據包，計數器就加1。

初始的未分段數據包稱為原始數據包，其中有個不可分段的部分，包含了IPv6 報頭，以及任何必須由通往目的地的路徑上的節點進行處理的擴展報頭（如Hopby-Hop Options 報頭）。原始數據包中的可分段部分包括任何只能由最終目的主機處理的擴展報頭，以及Upper-Layer 報頭和任何數據。圖2-8（RFC 2460）演示了分段過程。

每個分段中都有原始數據包的不可分段部分，后面緊跟著Fragment報頭，然后是可分段數據。原始數據包的IPv6 報頭必須稍做修改。長度字段表示分段的長度（不包括IPv6 報頭），而不是原始數據包的長度。

目的節點收集所有分段并進行重新組合。這些分段必須有相同的源地址和目的地址以及相同的標識值，才能進行組合。如果在第一個分段到達60 秒后，分段沒有全部到達目的地，目的主機將丟棄所有數據包。如果目的方接收到了第一個分段（偏移為0），它將向源地址返回一條“ICMPv6 Fragment Reassembly TimeExceeded”消息。

圖2-9 展示了一個Fragment 報頭。

我們通過發起一個從Marvin主機向Ford主機（分別是Windows 2000系統和Linux系統）的特大ping（譯注1）命令來創建此Fragment 報頭。整個分段集包括兩個數據包第一個如圖2-9 所示。在IPv6 報頭中，Payload Length 字段值為1456，即Fragment報頭和一個分段的長度，而不是整個原始數據包的長度。Next Header字段指定為值44，即Fragment 報頭的值。該字段后緊跟著Hop Limit 字段和源IP 地址和目的IP 地址。Fragment 報頭中的第一個字段是Next Header 字段。因為運行的是ping 命令，因此其中包含了值58（意味著ICMPv6）。并且，由于這是分段集當中的第一個數據包，因此偏移字段中的值為0；而M-Flag 則設為1，表示還有其他分段。Identification 字段設為1，且必須和屬于此分段集的所有數據包相同。圖2-10 展示了分段集當中的第二個數據包。

該分段集的第二個也是最后一個數據包的偏移值為0x05A8（十進制值為1448），即第一個分段的長度。M-Flag 被設為0，表示這是最后的數據包，并通知接收主機進行分段的重組合。這兩個數據包中的Identification 字段都設為1。

Destination Options 報頭

Destination Options 報頭攜帶著只由目的節點檢查的可選信息。標識此類報頭的Next Header 值為60。圖2-11 展示了Destination Options 報頭的格式。

下面對每個字段進行解釋:

Next Header（下一報頭，1 字節）

Next Header 字段標識了緊跟在Destination Options 報頭后的報頭類型。它使用本章前面表2-1 列出的值。

Header Extension Length（報頭擴展長度，1 字節）該字段以8 字節為單位標識了Destination Options 報頭的長度。前8 個字節的長度不計算在內。

Options（選項，長度不定）

可以有一個或多個選項。該選項的長度是不定的，由Header Extension Length 字段決定。

Options 字段的使用方式與Hop-by-Hop Options 報頭的使用方式相同。使用了Destination Options 報頭的一個例子就是Mobile IPv6。和外部網絡相連接的移動IPv6 節點發送數據包時，把轉交地址作為源地址，把本地網絡地址作為本地地址目的選項。根據當前的Mobile IPv6 草案，正確處理Destination Option 中本地地址的能力是所有IPv6 節點都需要的。