本文將闡述IPv6 報(bào)頭的結(jié)構(gòu)并將其與IPv4 報(bào)頭相比較。此外還將討論Extension（擴(kuò)展）報(bào)頭，這是IPv6 所新加的內(nèi)容。

在RFC 2460 中定義了IPv6 數(shù)據(jù)包的報(bào)頭結(jié)構(gòu)。該報(bào)頭固定為40 字節(jié)長。源和目的地址各占16 字節(jié)（128 位），因此，只有8 字節(jié)是用于普通報(bào)頭信息的。

普通報(bào)頭結(jié)構(gòu)

在IPv6 中，IPv4 報(bào)頭中的下面五個(gè)字段被去除了：

● Header Length（報(bào)頭長度）

● Identification（標(biāo)識(shí)）

● Flags（標(biāo)志）

● Fragment Offset（段偏移量）

● Header Checksum（報(bào)頭校驗(yàn)和）

除去Header Length（報(bào)頭長度）字段是因?yàn)閷?duì)于固定長度的報(bào)頭，它是不起作用的。在IPv4 中，報(bào)頭最短長度為20 字節(jié)，但是如果添加一些選項(xiàng)，則會(huì)以4字節(jié)長度遞增，最長可達(dá)60 字節(jié)。因此，對(duì)于IPv4 來說，報(bào)頭的總長度信息是很重要的。在IPv6 中，選項(xiàng)由擴(kuò)展報(bào)頭定義（將在本章后面部分作介紹）。

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

去除Header Checksum（報(bào)頭校驗(yàn)和）字段是為了提高處理速度。如果路由器無需檢驗(yàn)并更新校驗(yàn)和，則處理會(huì)變得更快。校驗(yàn)和的計(jì)算也是在介質(zhì)訪問層完成的，這樣未檢測(cè)到的錯(cuò)誤和錯(cuò)誤路由的數(shù)據(jù)包所引起的風(fēng)險(xiǎn)最小。傳輸層（UDP和TCP）中有一個(gè)校驗(yàn)和字段。IP 是一種“盡力而為”的傳輸協(xié)議，保證數(shù)據(jù)完整性的責(zé)任屬于其上層協(xié)議。

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

IPv6 報(bào)頭中的字段

對(duì)IPv6 報(bào)頭中各個(gè)字段越熟悉，你對(duì)IPv6 的工作方式越理解。

圖2-1 是IPv6 報(bào)頭的概述。將在下面的段落中詳細(xì)討論各個(gè)字段。

圖2-1 說明，即使IPv6 報(bào)頭的總長度是默認(rèn)的IPv4 報(bào)頭的兩倍長，達(dá)到了40 字節(jié)，但它實(shí)際上是被簡(jiǎn)化了的，因?yàn)閳?bào)頭的絕大部分被兩個(gè)16 字節(jié)的IPv6 地址占據(jù)。這樣，只剩8 個(gè)字節(jié)可供其他報(bào)頭信息使用。

Version（版本，4 位）這是一個(gè)4 位長的字段，其中包含了協(xié)議的版本。在IPv6 中，該數(shù)目為6。不能使用版本號(hào)5，因?yàn)? 早已被分配給一個(gè)實(shí)驗(yàn)性的流協(xié)議（ST2，RFC 1819）。

Traffic Class（流量類別，1 字節(jié)）該字段代替了IPv4 中的Type of Service 字段，它有助于處理實(shí)時(shí)數(shù)據(jù)以及任何需要特別處理的數(shù)據(jù)。發(fā)送節(jié)點(diǎn)和轉(zhuǎn)發(fā)路由器可以使用該字段來識(shí)別和分辨IPv6數(shù)據(jù)包的類別和優(yōu)先級(jí)。

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

Flow Label（流標(biāo)簽，20 位）

該字段區(qū)分需要相同處理的數(shù)據(jù)包，以此來促進(jìn)實(shí)時(shí)性流量的處理。發(fā)送主機(jī)能夠用一組選項(xiàng)標(biāo)記數(shù)據(jù)包的順序。路由器跟蹤數(shù)據(jù)流并更有效地處理屬于相同數(shù)據(jù)流的數(shù)據(jù)包，因?yàn)樗麄儫o須重新處理每個(gè)數(shù)據(jù)包的報(bào)頭。數(shù)據(jù)流由流標(biāo)簽和源節(jié)點(diǎn)的地址惟一標(biāo)識(shí)。不支持Flow Label字段功能的節(jié)點(diǎn)需要在轉(zhuǎn)發(fā)數(shù)據(jù)包時(shí)不加改變地傳遞該字段，并在接收數(shù)據(jù)包時(shí)忽略該字段。屬于同一數(shù)據(jù)流的所有數(shù)據(jù)包必須具有相同的源IP 地址和目的IP 地址。

Payload Length（有效載荷長度，2 字節(jié)）

該字段指定了有效載荷，也就是在IP 報(bào)頭后攜帶的數(shù)據(jù)長度。IPv6 中的計(jì)算與IPv4 不同。IPv4 中的Length 字段包括IPv4 報(bào)頭的長度，而IPv6 中的PayloadLength（有效載荷長度）字段僅包含IPv6 報(bào)頭后的數(shù)據(jù)。擴(kuò)展報(bào)頭被認(rèn)為是有效載荷的一部分，因此被包括在計(jì)算之內(nèi)。

由于Payload Length（有效載荷長度）字段只有2 個(gè)字節(jié)，因此數(shù)據(jù)包的有效載荷最大為64KB。IPv6 有一個(gè)Jumbogram Extension 報(bào)頭，如果有需要，它可以支持更大的數(shù)據(jù)包。只有當(dāng)I P v 6 節(jié)點(diǎn)連接到MTU 大于6 4 K B 的鏈路時(shí)，Jumbogram 才起作用。RFC 2675 中詳細(xì)說明了Jumbogram。

Next Header（下一報(bào)頭，1 字節(jié)）

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

注意：報(bào)頭類型和協(xié)議類型數(shù)字的范圍是相同的，因此不應(yīng)有沖突。

Hop Limit（跳數(shù)限制，1 字節(jié)）

該字段和IPv4 的TTL 字段類似。TTL 字段包含一個(gè)秒數(shù)，指示數(shù)據(jù)包在銷毀之前在網(wǎng)絡(luò)中逗留的時(shí)間。絕大多數(shù)路由器只是簡(jiǎn)單地在數(shù)據(jù)包經(jīng)過每一跳時(shí)將該值減1。該字段在IPv6 中被重命名為Hop Limit?，F(xiàn)在用字段中的值標(biāo)識(shí)跳數(shù)，而不是秒數(shù)。每個(gè)轉(zhuǎn)發(fā)節(jié)點(diǎn)對(duì)此數(shù)目減1。

Source Address（源地址，16 字節(jié)）

該字段包含數(shù)據(jù)包發(fā)送者的IP 地址。

Destination Address（目的地址，16 字節(jié)）

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

圖2-2 為跟蹤文件中的IPv6 報(bào)頭。

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

擴(kuò)展報(bào)頭

IPv4 報(bào)頭的長度可以從最小的20 字節(jié)擴(kuò)展為60 字節(jié)，以便指定選項(xiàng)，如安全選項(xiàng)（Security Option）、源路由（Source Routing）或時(shí)間戳（Timestamping）。這項(xiàng)功能很少使用，因?yàn)闀?huì)降低性能。例如，IPv4 硬件轉(zhuǎn)發(fā)實(shí)現(xiàn)必須把包含選項(xiàng)的數(shù)據(jù)包傳遞給主處理程序（軟件處理）。

數(shù)據(jù)包的報(bào)頭越簡(jiǎn)單，處理過程就越快。IPv6 采用一種新方法來處理選項(xiàng)，顯著地改善了處理速度。它在附加的擴(kuò)展報(bào)頭中對(duì)這些選項(xiàng)進(jìn)行處理。

當(dāng)前的IPv6 規(guī)范（RFC 2460）定義了六個(gè)擴(kuò)展報(bào)頭：

● Hop-by-Hop Options 報(bào)頭

● Routing 報(bào)頭

● Fragment 報(bào)頭

● Destination Options 報(bào)頭

● Authentication 報(bào)頭

● Encrypted Security Payload 報(bào)頭

在IPv6 報(bào)頭和上層協(xié)議報(bào)頭之間可以有一個(gè)或多個(gè)擴(kuò)展報(bào)頭，也可以沒有。每個(gè)擴(kuò)展報(bào)頭由前面報(bào)頭的Next Header 字段標(biāo)識(shí)。擴(kuò)展報(bào)頭只被IPv6 報(bào)頭的Destination Address字段所標(biāo)識(shí)的節(jié)點(diǎn)進(jìn)行檢查或處理。如果Destination Address字段中的地址是多播地址，則擴(kuò)展報(bào)頭可被屬于該多播組的所有節(jié)點(diǎn)檢查或處理。擴(kuò)展報(bào)頭必須嚴(yán)格按照在數(shù)據(jù)包報(bào)頭中出現(xiàn)的順序進(jìn)行處理。

上面所述的規(guī)則有個(gè)例外：只有目的節(jié)點(diǎn)才會(huì)處理擴(kuò)展報(bào)頭。如果擴(kuò)展報(bào)頭是Hop-by-Hop Options報(bào)頭，則其承載的信息必須被數(shù)據(jù)包經(jīng)過路徑上的每個(gè)節(jié)點(diǎn)檢查和處理。如果有Hop-by-Hop Options 報(bào)頭，則必須緊接在IPv6 報(bào)頭之后。IPv6 報(bào)頭的Next Header 字段中用0 來表示Hop-by-Hop Options 報(bào)頭（參見本章前面的表2-1）。

注意： 前四個(gè)擴(kuò)展報(bào)頭在RFC 2460 文檔中描述。Authentication 報(bào)頭在RFC 2402 中描述， Encrypted Security Payload 報(bào)頭在RFC 2406 中描述。

圖2-3 演示了擴(kuò)展報(bào)頭的使用方式。

每個(gè)擴(kuò)展報(bào)頭的字節(jié)長為8 的整數(shù)倍。因此，后面的報(bào)頭總是可以對(duì)齊。如果節(jié)點(diǎn)需要處理Next Header 字段，但不能識(shí)別該字段的值，那么就需要丟棄該數(shù)據(jù)包，并向數(shù)據(jù)包的發(fā)送源返回一條“ICMPv6 Parameter Problem”消息。第四章將詳細(xì)介紹ICMPv6 消息的有關(guān)細(xì)節(jié)。

如果在單個(gè)數(shù)據(jù)包中使用了多個(gè)擴(kuò)展報(bào)頭，則應(yīng)該使用如下的報(bào)頭順序（RFC 2460）：

1. IPv6 報(bào)頭

2. Hop-by-Hop Options 報(bào)頭

3. Destination Options報(bào)頭（用于由IPv6 目的地址字段中第一個(gè)出現(xiàn)的目的地

址以及隨后在Routing 報(bào)頭中列舉的目的地址進(jìn)行處理的選項(xiàng)）。

4. Routing 報(bào)頭

5. Fragment 報(bào)頭

6. Authentication 報(bào)頭

7. Encapsulating Security Payload 報(bào)頭

8. Destination Options 報(bào)頭（用于只由數(shù)據(jù)包最終目的地址進(jìn)行處理的選項(xiàng)）。

9. Upper-Layer 報(bào)頭

若IPv6 被封裝在IPv4 中，則Upper-Layer 報(bào)頭可以是另一個(gè)IPv6 報(bào)頭，并且可以包含符合相同規(guī)則的擴(kuò)展報(bào)頭。

Hop-by-Hop Options 報(bào)頭

Hop-by-Hop Options擴(kuò)展報(bào)頭攜帶著必須由數(shù)據(jù)包經(jīng)過路徑上的每個(gè)節(jié)點(diǎn)進(jìn)行檢查的可選信息。它必須緊跟在IPv6 報(bào)頭后，并由Next Header 值0 表示。例如，Router Alert（RFC 2711）把Hop-by-Hop Options 報(bào)頭應(yīng)用于資源預(yù)留協(xié)議（Resource Reservation Protocol，RSVP）或多播偵聽者發(fā)現(xiàn)（Multicast ListenerDiscovery，MLD）消息。在IPv4 中，路由器判斷是否需要檢查數(shù)據(jù)報(bào)的惟一方法是解析所有數(shù)據(jù)報(bào)中的上層數(shù)據(jù)，至少是部分解析。這極大地降低了路由處理速度。在IPv6 中，如果沒有Hop-by-Hop Options 擴(kuò)展報(bào)頭，則路由器知道無須處理路由器相關(guān)的信息，因此可以立即把數(shù)據(jù)包路由到最終目的地。若存在Hopby-Hop Options 擴(kuò)展報(bào)頭，則路由器只需檢查報(bào)頭，而無須深入查看數(shù)據(jù)包。

Hop-by-Hop Options 報(bào)頭的格式如圖2-4 所示。

下面對(duì)每個(gè)字段進(jìn)行解釋：

Next Header（下一報(bào)頭，1 字節(jié)）

Next Header 字段標(biāo)識(shí)了跟在Hop-by-Hop Options 報(bào)頭之后的報(bào)頭的類型。

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

Header Extension Length（報(bào)頭擴(kuò)展長度，1 字節(jié)）

該字段標(biāo)識(shí)Hop-by-Hop Options 報(bào)頭的長度，以8 字節(jié)為單位。長度的計(jì)算不包括第一個(gè)8 字節(jié)。

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

Option Type（選項(xiàng)類型）字段是Options 字段的第一個(gè)字節(jié)，包含了在執(zhí)行處理的節(jié)點(diǎn)不能識(shí)別該選項(xiàng)時(shí)如何處理選項(xiàng)的信息。該值的前兩位值指定了要執(zhí)行的操作。

● 值00：跳過并繼續(xù)處理。

● 值01：丟棄數(shù)據(jù)包。

● 值10：丟棄數(shù)據(jù)包并向數(shù)據(jù)包的源地址發(fā)送“ICMP Parameter Problem,Code 2”消息，指出不能識(shí)別的選項(xiàng)類型。

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

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

Routing 報(bào)頭

Routing報(bào)頭用來給出一個(gè)或多個(gè)數(shù)據(jù)包在到達(dá)目的地的路徑上應(yīng)該經(jīng)過的中間節(jié)點(diǎn)。在IPv4 中，這叫做Loose Source 和Record Route 選項(xiàng)。Routing 報(bào)頭由其前一個(gè)報(bào)頭的Next Header 值43 標(biāo)識(shí)。圖2-5 說明了Routing 報(bào)頭的格式。

下面對(duì)每個(gè)字段進(jìn)行解釋：

Next Header（下一報(bào)頭，1 字節(jié)）

Next Header 字段標(biāo)識(shí)了Routing 報(bào)頭后的報(bào)頭的類型。它使用與IPv4 協(xié)議類型字段相同的值（參見本章前面的表2-1）。

Header Extension Length（報(bào)頭擴(kuò)展長度，1 字節(jié)）

該字段標(biāo)識(shí)了Routing 報(bào)頭的長度，以8 字節(jié)為單位。長度計(jì)算不包括第一個(gè)8 字節(jié)。

Routing Type（路由類型，1 字節(jié)）

該字段標(biāo)識(shí)了Routing 報(bào)頭的類型。RFC 2460 說明了Routing Type 0。

Segments Left（剩余段，1 字節(jié)）

該字段標(biāo)識(shí)了在數(shù)據(jù)包到達(dá)最終目的地之前還需經(jīng)過多少節(jié)點(diǎn)。

Type-Specific Data（類型相關(guān)數(shù)據(jù)，長度不定）

該字段長取決于路由類型。該長度總是保證完整的報(bào)頭為8 字節(jié)的倍數(shù)。

如果處理Routing 報(bào)頭的節(jié)點(diǎn)不能識(shí)別Routing Type 值，則采取的措施取決于Segments Left 字段的內(nèi)容。如果Segments Left 字段不包含任何要經(jīng)過的節(jié)點(diǎn)，則節(jié)點(diǎn)必須忽略Routing報(bào)頭并處理數(shù)據(jù)包中的下一個(gè)報(bào)頭，這由Next Header字段的值決定。如果Segments Left 字段不為0，則節(jié)點(diǎn)必須丟棄數(shù)據(jù)包并向數(shù)據(jù)包的源地址發(fā)送“ICMP Parameter Problem, Code 0”消息，指出未識(shí)別出的路由類型。如果轉(zhuǎn)發(fā)節(jié)點(diǎn)因?yàn)橄乱绘溄拥腗TU 太小而不能處理數(shù)據(jù)包，它將丟棄數(shù)據(jù)包并向數(shù)據(jù)包的發(fā)送源發(fā)送“ICMP Packet Too Big”消息。

RFC 2460 中惟一描述的Routing Type 是Type Zero Routing 報(bào)頭。處理Routing報(bào)頭的第一個(gè)節(jié)點(diǎn)由IPv6 報(bào)頭中的Destination address 字段指定。該節(jié)點(diǎn)對(duì)Segments Left 字段減1，并把IPv6 報(bào)頭的Routing 報(bào)頭內(nèi)的下一個(gè)地址字段插入到IPv6 的Destination address 字段。然后數(shù)據(jù)包被轉(zhuǎn)發(fā)到下一跳，按前面描述的方法處理Routing報(bào)頭，直到到達(dá)最終目的地。最終目的地是Routing Header Data字段的最后一個(gè)地址。例如，Mobile IPv6 使用Routing 報(bào)頭。任何向移動(dòng)節(jié)點(diǎn)發(fā)送數(shù)據(jù)包的節(jié)點(diǎn)都將把數(shù)據(jù)包發(fā)送到該移動(dòng)節(jié)點(diǎn)的轉(zhuǎn)交地址（care-of-address）。

它包括Routing 報(bào)頭，其中包含一條該移動(dòng)節(jié)點(diǎn)的家庭地址。移動(dòng)節(jié)點(diǎn)把IPv6 報(bào)頭中的目的地址和Routing 報(bào)頭中的條目進(jìn)行交換，然后用家庭地址作為源地址進(jìn)行應(yīng)答，就如同它接收到了本地網(wǎng)絡(luò)的數(shù)據(jù)包一樣。要更深入討論Mobile IPv6并了解相關(guān)術(shù)語的定義，請(qǐng)參考第七章。圖2-6 為跟蹤文件中的Routing 報(bào)頭。

IPv6 報(bào)頭中的Next Header 字段值為43 則表示是Routing 報(bào)頭。Source address和Destination address 的前綴為“2002:”，這意味著6to4 站點(diǎn)。Routing 報(bào)頭包含本節(jié)先前討論的字段。Next Header 為ICMPv6，值58。Header Length 是兩個(gè)8 字節(jié)長的單元，即共16 字節(jié)長。Segments Left 字段值為1，因?yàn)樵贠ptions 字段中有一個(gè)地址條目。最后，Options 字段列舉要經(jīng)過的地址。在本例中，只有一個(gè)地址條目。如果在此列舉了一些主機(jī)，則每個(gè)轉(zhuǎn)發(fā)節(jié)點(diǎn)（也就是IPv6 報(bào)頭中的目的IP 地址）要從該主機(jī)列表中取出下一個(gè)條目，用作IPv6 報(bào)頭中的新的目的IP 地址，對(duì)Segments Left 字段減1，并轉(zhuǎn)發(fā)數(shù)據(jù)包。重復(fù)此過程，直到到達(dá)列表中的最后一臺(tái)主機(jī)。RFC 2460 中演示了一個(gè)例子。

某源節(jié)點(diǎn)S 使用Routing 報(bào)頭通過中間節(jié)點(diǎn)I1、I2 和I3，將一個(gè)數(shù)據(jù)包發(fā)送到目的節(jié)點(diǎn)D。Routing 報(bào)頭的變化如表2-2 所示。

Fragment 報(bào)頭

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

下面描述各個(gè)字段：

Next Header（下一報(bào)頭，1 字節(jié)）

Next Header字段標(biāo)識(shí)了緊跟在Fragment報(bào)頭后的報(bào)頭的類型。它與IPv4 協(xié)議類型字段的值相同（參見表2-1）。

Reserved（保留，1 字節(jié)）

未使用，設(shè)為0。

Fragment Offset（段偏移量，13 位）

數(shù)據(jù)包中的數(shù)據(jù)相對(duì)于原始數(shù)據(jù)包中數(shù)據(jù)的開始的偏移量，以8 字節(jié)為單位。

Reserved（保留，2 位）

未使用，設(shè)為0。

M-Flag（M- 標(biāo)志，1 位）

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

Identification（標(biāo)識(shí)，4 字節(jié)）由源主機(jī)生成，用于識(shí)別屬于原始數(shù)據(jù)包的所有數(shù)據(jù)包。該字段通常由計(jì)數(shù)器實(shí)現(xiàn)，每當(dāng)有一個(gè)需要源主機(jī)進(jìn)行分段的數(shù)據(jù)包，計(jì)數(shù)器就加1。

初始的未分段數(shù)據(jù)包稱為原始數(shù)據(jù)包，其中有個(gè)不可分段的部分，包含了IPv6 報(bào)頭，以及任何必須由通往目的地的路徑上的節(jié)點(diǎn)進(jìn)行處理的擴(kuò)展報(bào)頭（如Hopby-Hop Options 報(bào)頭）。原始數(shù)據(jù)包中的可分段部分包括任何只能由最終目的主機(jī)處理的擴(kuò)展報(bào)頭，以及Upper-Layer 報(bào)頭和任何數(shù)據(jù)。圖2-8（RFC 2460）演示了分段過程。

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

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

圖2-9 展示了一個(gè)Fragment 報(bào)頭。

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

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

Destination Options 報(bào)頭

Destination Options 報(bào)頭攜帶著只由目的節(jié)點(diǎn)檢查的可選信息。標(biāo)識(shí)此類報(bào)頭的Next Header 值為60。圖2-11 展示了Destination Options 報(bào)頭的格式。

下面對(duì)每個(gè)字段進(jìn)行解釋:

Next Header（下一報(bào)頭，1 字節(jié)）

Next Header 字段標(biāo)識(shí)了緊跟在Destination Options 報(bào)頭后的報(bào)頭類型。它使用本章前面表2-1 列出的值。

Header Extension Length（報(bào)頭擴(kuò)展長度，1 字節(jié)）該字段以8 字節(jié)為單位標(biāo)識(shí)了Destination Options 報(bào)頭的長度。前8 個(gè)字節(jié)的長度不計(jì)算在內(nèi)。

Options（選項(xiàng)，長度不定）

可以有一個(gè)或多個(gè)選項(xiàng)。該選項(xiàng)的長度是不定的，由Header Extension Length 字段決定。

Options 字段的使用方式與Hop-by-Hop Options 報(bào)頭的使用方式相同。使用了Destination Options 報(bào)頭的一個(gè)例子就是Mobile IPv6。和外部網(wǎng)絡(luò)相連接的移動(dòng)IPv6 節(jié)點(diǎn)發(fā)送數(shù)據(jù)包時(shí)，把轉(zhuǎn)交地址作為源地址，把本地網(wǎng)絡(luò)地址作為本地地址目的選項(xiàng)。根據(jù)當(dāng)前的Mobile IPv6 草案，正確處理Destination Option 中本地地址的能力是所有IPv6 節(jié)點(diǎn)都需要的。