專業提供企業網絡專線 、MPLS VPN、SD-WAN、IPLC、IPLC、海外IDC、云專線等技術方案。
咨詢熱線:400-028-9798

IPLC

IPv6協議規范

發布時間:2021-07-20 15:01:39來源:未知作者:大V閱讀:

[導讀]: Internet Protocol, Version 6 (IPv6) Specification 梗概 本文檔規定了 Internet 協議的第 6 版(IPv6),它廢棄了 RFC 2460。 本備忘錄的狀態 這是一個 Internet 標準跟蹤文檔。 本文檔是 Internet 工程任務組...
Internet Protocol, Version 6 (IPv6) Specification

梗概

本文檔規定了 Internet 協議的第 6 版(IPv6),它廢棄了 RFC 2460。

本備忘錄的狀態

這是一個 Internet 標準跟蹤文檔。

本文檔是 Internet 工程任務組 (IETF) 的產品。它代表了 IETF 社區的共識。它已接受公眾審查,并已被互聯網工程指導組 (IESG) 批準出版。有關 Internet 標準的更多信息,請參見 RFC 7841 的第 2 節。

有關本文檔的當前狀態、任何勘誤以及如何提供反饋的信息,請訪問 http://www.rfc-editor.org/info/rfc8200。

版權聲明

版權所有 (c) 2017 IETF Trust 和確定為文檔作者的人員。版權所有。

本文檔受 BCP 78 和 IETF 信托與 IETF 文檔相關的法律規定 (http://trustee.ietf.org/license-info) 的約束,該規定在本文檔發布之日生效。請仔細閱讀這些文件,因為它們描述了您對本文件的權利和限制。從本文檔中提取的代碼組件必須包含 Trust Legal Provisions 第 4.e 節中所述的簡化 BSD 許可文本,并且不提供如簡化 BSD 許可中所述的保證。

本文檔可能包含來自于 2008 年 11 月 10 日之前發布或公開提供的 IETF 文檔或 IETF 貢獻的材料。控制本材料某些版權的人可能未授予 IETF 信托允許修改此類材料的權利在 IETF 標準流程之外。如果沒有從控制此類材料版權的人那里獲得足夠的許可,則不得在 IETF 標準流程之外修改本文檔,并且不得在 IETF 標準流程之外創建其衍生作品,除非將其格式化為作為 RFC 發布或將其翻譯成英語以外的語言。

1、簡介

IP 版本 6 (IPv6) 是互聯網協議 (Internet Protocol,IP) 的新版本,設計為 IP 版本 4 (IPv4) [RFC791] 的后繼版本。從 IPv4 到 IPv6 的變化主要分為以下幾類:

** 擴展尋址能力

IPv6 將 IP 地址大小從 32 位增加到 128 位,以支持更多級別的尋址層次結構、更多數量的可尋址節點以及更簡單的地址自動配置。通過向多播地址添加“范圍”字段來提高多播路由的可擴展性。并且定義了一種稱為“任播地址”的新型地址;它用于向一組節點中的任何一個發送數據包。

** 報文頭格式簡化

一些 IPv4 報文頭字段已被刪除或成為可選字段,以降低數據包處理的常見情況處理成本并限制 IPv6 報文頭的帶寬成本。

** 改進了對擴展和選項的支持

IP 報文頭選項編碼方式的變化允許更高效的轉發、對選項長度的更寬松的限制,以及在未來引入新選項的更大靈活性。

** 流標簽能力

添加了一項新功能,可以對發送方請求在網絡中作為單個流處理的數據包序列進行標記。

** 身份驗證和隱私功能

為 IPv6 指定了支持身份驗證、數據完整性和(可選)數據機密性的擴展。

本文檔規定了基本 IPv6 報文頭和最初定義的 IPv6 擴展頭和選項。它還討論了數據包大小問題、流標簽和流量類別的語義以及 IPv6 對上層協議的影響。IPv6 地址的格式和語義在 [RFC4291] 中單獨指定。[RFC4443] 中規定了所有 IPv6 實現都需要包含的 ICMP 的 IPv6 版本。

IPv6 的數據傳輸順序與 [RFC791] 的附錄 B 中定義的 IPv4 相同。

注意:由于本文檔已廢棄 [RFC2460],因此本文檔中引用的任何包含指向 RFC 2460 的指針的文檔都應被解釋為引用本文檔。

2. 術語

node:節點,實現 IPv6 的設備。

router:路由器,轉發非自身為目的址的 IPv6 數據包的節點。(請參閱下面的注釋。)

host:主機,任何不是路由器的節點。(請參閱下面的注釋。)

upper layer:上層,在 IPv6 網絡層之上的協議層。比如傳輸協議(例如 TCP 和 UDP)、控制協議(例如 ICMP)、路由協議(例如 OSPF)以及通過 IPv6 “隧道化”(即封裝在)IPv6 中的 Internet 層或較低層協議,例如 Internetwork Packet Exchange (IPX) )、AppleTalk 或 IPv6 本身。

link:鏈路,節點可以在鏈路層(即 IPv6 正下方的層)進行通信的通信設施或介質。例如以太網(簡單或橋接);PPP 鏈接;X.25、幀中繼或 ATM 網絡;和互聯網層或更高層的“隧道”,例如通過 IPv4 或 IPv6 本身的隧道。

neighbors:鄰居,連接到同一鏈路的節點。

interface:接口,節點和鏈路的連接點。

address:地址,一個接口或一組接口的 IPv6 層標識符。

packet:包/報文,一個 IPv6 報文頭和有效載荷。

link MTU:鏈路MTU,可以通過鏈路傳送的最大傳輸單元,即以八位字節為單位的最大數據包大小。

path MTU:路徑MTU,源節點和目的節點之間路徑中所有鏈路的最小鏈路 MTU。

注意:具有多個接口的設備可以配置為轉發來自其某些接口集(少于全部)的非自身目標數據包,并丟棄來自其他接口的非自身目標數據包。當從前一個(轉發)接口接收來自鄰居的數據包并與鄰居交互時,此類設備必須遵守路由器的協議要求。當從后者(非轉發)接口接收數據包并與鄰居交互時,它必須遵守主機的協議要求。

3、 IPv6 頭格式

IPv6協議規范

Version:版本, 4 位 Internet 協議版本號 = 6。

Traffic Class:流量類別, 8 位流量類別字段。見第 7 節。

Flow Label:流標簽, 20 位流標簽。見第 6 節。

Payload Length:有效載荷長度, 16 位無符號整數。IPv6 有效負載的長度,即此 IPv6 報文頭后面的數據包的其余部分,以八位字節為單位。(請注意,存在的任何擴展報文頭(請參閱第 4 節)都被視為有效載荷的一部分,即包含在長度計數中。)

Next Header:下一個報文頭, 8 位選擇器。標識緊跟在 IPv6 報文頭之后的報文頭類型。使用與 IPv4 協議字段 [IANA-PN] 相同的值。

Hop Limit:跳數限制, 8 位無符號整數。每個轉發數據包的節點減 1。轉發時,如果接收時 Hop Limit 為零或遞減為零,則丟棄該數據包。作為數據包目的的節點不應丟棄 Hop Limit 為零的數據包;它應該正常處理數據包。

Source Address:源地址,數據包始發者的 128 位地址。參見 [RFC4291]。

Destination Address:目標地址,數據包預期接收者的 128 位地址(如果存在路由報文頭,則可能不是最終接收者)。參見 [RFC4291] 和第 4.4 節。

4、 IPv6 擴展頭

在 IPv6 中,可選的互聯網層信息被編碼在單獨的報文頭中,這些報文頭可以放置在數據包中的 IPv6 報文頭和上層報文頭之間。有少量這樣的擴展報文頭,每個報文頭由不同的下一個報文頭值標識。

擴展報文頭從 IANA IP 協議編號 [IANA-PN] 編號,與 IPv4 和 IPv6 使用的值相同。當處理數據包中的 Next Header 值序列時,第一個不是擴展頭 [IANA-EH] 表示數據包中的下一項是相應的上層頭。如果沒有上層報文頭,則使用特殊的“無下一個報文頭”值。

如這些示例中所示,IPv6 數據包可以攜帶零個、一個或多個擴展報文頭,每個擴展報文頭由前一個報文頭的下一個報文頭字段標識:

IPv6協議規范

擴展報文頭(Hop-by-Hop Options 報文頭除外)不會被任何沿著數據包傳遞路徑的節點處理、插入或刪除,直到數據包到達該節點(或節點集的每個節點,在多播情況下)在 IPv6 報文頭的目標地址字段中標識。

Hop-by-Hop Options 報文頭不會被插入或刪除,但可以被沿數據包傳遞路徑的任何節點檢查或處理,直到數據包到達節點(或節點組中的每個節點,在多播的情況下)在 IPv6 報文頭的目標地址字段中標識。Hop-by-Hop Options 報文頭(如果存在)必須緊跟在 IPv6 報文頭之后。它的存在由 IPv6 報文頭的下一個報文頭字段中的值零指示。

注意:雖然 [RFC2460] 要求所有節點都必須檢查和處理 Hop-by-Hop Options 報文頭,但現在預計,如果明確配置為這樣做,沿數據包傳送路徑的節點僅檢查和處理 Hop-by-Hop Options 報文頭。

在目的節點,對 IPv6 報文頭的 Next Header 字段的正常解復用調用模塊來處理第一個擴展報文頭,如果沒有擴展報文頭,則調用上層報文頭。每個擴展頭的內容和語義決定是否繼續下一個頭。因此,擴展頭必須嚴格按照它們在數據包中出現的順序進行處理;例如,接收方不得掃描數據包以尋找特定類型的擴展報文頭并在處理所有前面的報文頭之前處理該報文頭。

如果作為處理報文頭的結果,目標節點需要繼續處理下一個報文頭,但節點無法識別當前報文頭中的 Next Header 值,則它應該丟棄該數據包并向目標節點發送 ICMP 參數問題消息。數據包的來源,ICMP 代碼值為 1(“遇到無法識別的下一個報文頭類型”),ICMP 指針字段包含原始數據包中無法識別的值的偏移量。如果節點在除 IPv6 報文頭之外的任何報文頭中遇到 Next Header 值為零,則應采取相同的操作。

每個擴展報文頭是 8 個八位字節長的整數倍,以便為后續報文頭保留 8 個八位字節對齊。每個擴展報文頭內的多八位字節字段在它們的自然邊界上對齊,即寬度為 n 個八位字節的字段放置在從報文頭開始的 n 個八位字節的整數倍處,對于 n = 1、2、4 或 8。

IPv6 的完整實現包括以下擴展頭的實現:

Hop-by-Hop Options,逐跳選項

Fragment,分段

Destination Options,目的選項

Routing,路由

Authentication,驗證

Encapsulating Security Payload,封裝安全載荷

本文件規定了前四種;最后兩個分別在 [RFC4302] 和 [RFC4303] 中指定。可以在 [IANA-EH] 找到當前的 IPv6 擴展頭列表。

4.1、 擴展頭順序

當在同一個數據包中使用多個擴展頭時,建議這些頭按以下順序出現:

IPv6 header,IPv6 報文頭

Hop-by-Hop Options header,逐跳選項報文頭

Destination Options header,目標選項報文頭(注 1)

Routing header,路由頭

Fragment header,片段頭

Authentication header,驗證報文頭(注 2)

Encapsulating Security Payload header,封裝安全載荷頭(注 2)

Destination Options header,目的選項報文頭(注 3)

Upper-Layer header,上層報文頭

注 1:用于由出現在 IPv6 目標地址字段中的第一個目標以及路由報文頭中列出的后續目標處理的選項。

注 2:[RFC4303] 中給出了關于認證和封裝安全有效載荷頭的相對順序的附加建議。

注 3:對于僅由數據包的最終目的處理的選項。

每個擴展報文頭最多應該出現一次,除了 Destination Options 報文頭,它最多應該出現兩次(一次在路由報文頭之前,一次在上層報文頭之前)。

如果上層報文頭是另一個 IPv6 報文頭(在 IPv6 被隧道傳輸或封裝在 IPv6 中的情況下),它可能跟隨著它自己的擴展報文頭,它們分別受相同的排序建議的約束。

如果定義了其他擴展報文頭,則必須指定它們相對于上面列出的報文頭的排序約束。

IPv6 節點必須接受并嘗試以任何順序處理擴展報文頭,并且在同一個數據包中出現任意次數,但 Hop-by-Hop Options 報文頭除外,它被限制為僅出現在 IPv6 報文頭之后。盡管如此,強烈建議 IPv6 數據包的來源遵循上述推薦順序,直到并且除非后續規范修改該推薦。

4.2、 選項

本文檔中指定的兩個當前定義的擴展報文頭——Hop-by-Hop Options 報文頭和 Destination Options 報文頭——攜帶可變數量的“選項”,這些“選項”是以下編碼的類型-長度-值 (TLV)格式:

IPv6協議規范

Option Type 選項類型的 8 位標識符。

Opt Data Len 8 位無符號整數。此選項的選項數據字段的長度,以八位字節為單位。

選項數據可變長度字段。特定于選項類型的數據。

報文頭中的選項序列必須嚴格按照它們在報文頭中出現的順序進行處理;例如,接收方不得掃描報文頭以尋找特定類型的選項并在處理所有前面的選項之前處理該選項。

選項類型標識符在內部進行編碼,以便它們的最高 2 位指定在處理 IPv6 節點不識別選項類型時必須采取的操作:

00 - 跳過此選項并繼續處理報文頭。

01 - 丟棄數據包。

10 - 丟棄數據包,無論數據包的目標地址是否是多播地址,都向數據包的源地址發送 ICMP 參數問題,代碼 2,消息,指向無法識別的選項類型。

11 - 丟棄數據包,并且僅當數據包的目標地址不是多播地址時,才向數據包的源地址發送 ICMP 參數問題,代碼 2,消息,指向無法識別的選項類型。

選項類型的第三高位指定該選項的選項數據是否可以在到達數據包最終目的的途中改變。當數據包中存在身份驗證報文頭時,對于其數據可能在途中更改的任何選項,在計算或驗證數據包的身份驗證值時,其整個選項數據字段必須被視為零值八位字節。

0 - 選項數據在途中不會改變

1 - 選項數據可能會在途中發生變化

上述三個高階位將被視為選項類型的一部分,而不是獨立于選項類型。也就是說,特定選項由完整的 8 位選項類型標識,而不僅僅是選項類型的低 5 位。

相同的選項類型編號空間用于 Hop-by-Hop Options 報文頭和 Destination Options 報文頭。但是,特定選項的規范可能會將其使用限制為僅這兩個報文頭之一。

個別選項可能有特定的對齊要求,以確保選項數據字段內的多字節值落在自然邊界上。選項的對齊要求使用符號 xn+y 指定,這意味著選項類型必須出現在從頭開始的 x 個八位字節加上 y 個八位字節的整數倍處。例如:

2n 表示從頭開始的任何 2 個八位字節的偏移量。

8n+2 表示從頭開始的任何 8 個八位字節的偏移量,加上 2 個八位字節。

有兩個填充選項在必要時用于對齊后續選項并將包含的報文頭填充到長度為 8 個八位字節的倍數。所有 IPv6 實現都必須識別這些填充選項:

Pad1 選項(對齊要求:無)

IPv6協議規范

注意!Pad1 選項的格式是一種特殊情況——它沒有長度和值字段。

Pad1 選項用于將 1 個八位字節的填充插入報文頭的選項區域。如果需要多個八位字節的填充,則應使用接下來描述的 PadN 選項,而不是多個 Pad1 選項。

PadN 選項(對齊要求:無)

IPv6協議規范

PadN 選項用于將兩個或多個八位字節的填充插入到報文頭的選項區域中。對于填充的 N 個八位字節,Opt Data Len 字段包含值 N-2,而 Option Data 由 N-2 個零值八位字節組成。

附錄 A 包含設計新選項的格式指南。

4.3、 逐跳選項報文頭

Hop-by-Hop Options 報文頭用于攜帶可選信息,這些信息可以由沿數據包傳遞路徑的每個節點進行檢查和處理。Hop-by-Hop Options 報文頭由 IPv6 報文頭中的 Next Header 值 0 標識,并具有以下格式:

IPv6協議規范

下一個報文頭:8 位選擇器。標識緊跟在 Hop-by-Hop Options 報文頭之后的報文頭類型。使用與 IPv4 協議字段 [IANA-PN] 相同的值。

HDR Ext Len:8 位無符號整數。Hop-by-Hop Options 報文頭的長度,以 8 個八位字節為單位,不包括前 8 個八位字節。

選項:可變長度字段,其長度使得完整的逐跳選項報文頭是 8 個八位字節長的整數倍。包含一個或多個 TLV 編碼選項,如第 4.2 節所述。

本文檔中定義的唯一逐跳選項是第 4.2 節中指定的 Pad1 和 PadN 選項。

4.4、 路由頭

路由報文頭被 IPv6 源用來列出一個或多個在到達數據包目的的途中要“訪問”的中間節點。此功能與 IPv4 的松散源和記錄路由選項非常相似。Routing 報文頭由緊接在前一個報文頭中的 Next Header 值 43 標識,并具有以下格式:

IPv6協議規范

下一個報文頭:8 位選擇器。標識緊跟在 Routing 報文頭之后的報文頭類型。使用與 IPv4 協議字段 [IANA-PN] 相同的值。

HDR Ext Len:8 位無符號整數。路由報文頭的長度,以 8 個八位字節為單位,不包括前 8 個八位字節。

路由類型:特定路由報文頭變體的 8 位標識符。

Segments Left:8 位無符號整數。剩余路由分段的數量,即在到達最終目的之前仍要訪問的明確列出的中間節點的數量。

type-specific data:可變長度字段,格式由路由類型確定,長度使得完整的路由報文頭是 8 個八位字節長的整數倍。

如果在處理接收到的數據包時,節點遇到具有無法識別的路由類型值的路由報文頭,則節點所需的行為取決于 Segments Left 字段的值,如下所示:

如果 Segments Left 為零,則節點必須忽略路由頭并繼續處理數據包中的下一個頭,其類型由路由頭中的下一個頭字段標識。

如果 Segments Left 不為零,則節點必須丟棄數據包并向數據包的源地址發送 ICMP 參數問題代碼 0 消息,指向無法識別的路由類型。

如果中間節點在處理接收到的數據包的路由頭后,確定將數據包轉發到鏈路 MTU 小于數據包大小的鏈路上,則該節點必須丟棄該數據包并發送 ICMP 數據包大消息到數據包的源地址。

當前定義的 IPv6 路由頭及其狀態可以在 [IANA-RH] 中找到。IPv6 路由頭的分配指南可以在 [RFC5871] 中找到。

4.5、 片段頭

IPv6 源使用 Fragment 報文頭發送大于到達其目的的路徑 MTU 的數據包。(注意:與 IPv4 不同,IPv6 中的分段僅由源節點執行,而不是由沿數據包傳送路徑的路由器執行——參見第 5 節。)片段頭由緊接在前一個頭中的 Next Header 值 44 標識,并且具有以下格式:

IPv6協議規范

下一個報文頭:8 位選擇器。標識原始數據包的 Fragmentable Part 的初始頭類型(定義如下)。使用與 IPv4 協議字段 [IANA-PN] 相同的值。

Reserved:8 位保留字段。傳輸初始化為零;接收時被忽略。

片段偏移量:13 位無符號整數。此報文頭后面的數據相對于原始數據包的可分段部分的開頭的偏移量(以 8 個八位字節為單位)。

Res:2 位保留字段。傳輸初始化為零;接待時被忽略。

M: 1 = 更多片段;0 = 最后一個片段。

Identification:32 位。請參閱下面的說明。

為了發送一個太大而無法容納到其目的的路徑的 MTU 的數據包,源節點可以將數據包分成多個片段并將每個片段作為單獨的數據包發送,以便在接收器處重新組裝。

對于每個要分段的數據包,源節點都會生成一個標識值。標識必須不同于最近發送的任何其他具有相同源地址和目標地址的分段數據包*。如果存在路由報文頭,則關注的目標地址是最終目標的地址。

*“最近”是指在數據包的最大可能生命周期內,包括從源到目的的傳輸時間以及等待與同一數據包的其他片段重新組裝所花費的時間。然而,不要求源節點知道最大數據包壽命。相反,假設可以通過實施導致低標識重用頻率的算法來滿足要求。[RFC7739] 中描述了可以滿足此要求的算法示例。

初始的、大的、未分段的數據包被稱為“原始數據包”,它被認為由三部分組成,如圖所示:

原始數據包:

IPv6協議規范

Per-Fragment 報文頭必須包含 IPv6 報文頭加上必須由到達目的的節點處理的任何擴展報文頭,即所有報文頭直到并包括路由報文頭(如果存在),否則為 Hop-by-Hop Options報文頭(如果存在),否則沒有擴展報文頭。

擴展報文頭是未包含在數據包的 Per-Fragment 報文報文頭分中的所有其他擴展報文頭。為此,封裝安全有效載荷 (ESP) 不被視為擴展報文頭。Upper-Layer 頭是第一個不是 IPv6 擴展頭的上層頭。上層報文頭的示例包括 TCP、UDP、IPv4、IPv6、ICMPv6 和 ESP。

Fragmentable Part 由上層報文頭之后或任何包含 Next Header 值為 No Next Header 的報文頭(即初始 IPv6 報文頭或擴展報文頭)之后的數據包的其余部分組成。

原始數據包的 Fragmentable 部分被分成多個片段。必須選擇片段的長度,使得生成的片段數據包適合到數據包目的的路徑的 MTU。每個完整的片段,可能除了最后一個(“最右邊的”)片段,都是 8 個八位字節長的整數倍。

片段在單獨的“片段數據包”中傳輸,如圖所示:

原始數據包:

IPv6協議規范

分段數據包:

IPv6協議規范

第一個分段包由以下部分組成:

(1) 原始報文的 Per-Fragment 頭,原始 IPv6 報文頭的 Payload Length 更改為僅包含該分段報文的長度(不包括 IPv6 報文頭本身的長度),以及該報文的 Next Header 字段Per-Fragment 報文頭的最后一個報文頭更改為 44。

(2) 一個片段頭,包含:

Next Header 值,用于標識原始數據包的 Per-Fragment 報文頭之后的第一個報文頭。

包含片段偏移量的片段偏移量,以 8 個八位字節為單位,相對于原始數據包的可分段部分的開頭。第一個(“最左邊”)片段的片段偏移量為 0。

M 標志值為 1,因為這是第一個片段。

標識值由原始數據包生成。

(3) 擴展報文頭,如果有的話,和上層報文頭。這些報文頭必須在第一個片段中。注意:這將通過上層報文頭的報文頭大小限制為到數據包目的的路徑的 MTU。

(4) 第一個片段。

隨后的分段數據包由以下部分組成:

(1) 原始報文的 Per-Fragment 頭,原始 IPv6 報文頭的 Payload Length 更改為僅包含該分段報文的長度(不包括 IPv6 報文頭本身的長度),以及該報文的 Next Header 字段Per-Fragment 報文頭的最后一個報文頭更改為 44。

(2) 一個片段頭,包含:

Next Header 值,用于標識原始數據包的 Per-Fragment 報文頭之后的第一個報文頭。

包含片段偏移量的片段偏移量,以 8 個八位字節為單位,相對于原始數據包的可分段部分的開頭。

如果片段是最后一個(“最右邊”),則 M 標志值為 0,否則 M 標志值為 1。

標識值由原始數據包生成。

(3) 片段本身。

不得創建與從原始數據包創建的任何其他片段重疊的片段。

在目的,分段數據包被重新組合成其原始的、未分段的形式,如圖所示:

重新組裝的原始數據包:

IPv6協議規范

以下規則管理重組:

原始數據包僅由具有相同源地址、目標地址和片段標識的片段數據包重組而成。

重組后的數據包的 Per-Fragment 報文頭由所有報文頭組成,但不包括第一個片段數據包(即 Fragment Offset 為零的數據包)的 Fragment 報文頭,有以下兩個變化:

Per-Fragment 頭的最后一個頭的 Next Header 字段是從第一個片段的 Fragment 頭的 Next Header 字段中獲取的。

重組數據包的有效載荷長度是根據 Per-Fragment 頭的長度和最后一個片段的長度和偏移量計算的。例如,計算重組原始數據包的有效載荷長度的公式為:

PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last

公式中:

PL.orig = 重組數據包的有效載荷長度字段。

PL.first = 第一個片段數據包的有效載荷長度字段。

FL.first = 第一個片段數據包的片段頭之后的片段長度。

FO.last = 最后一個分段包的分段頭的分段偏移字段。

FL.last = 最后一個片段包的片段頭之后的片段長度。

重組包的可分段部分由每個分段包中的分段頭后面的分段構成。每個片段的長度是通過從數據包的 Payload Length 中減去 IPv6 報文頭和片段本身之間的報文頭長度來計算的;它在 Fragmentable Part 中的相對位置是根據它的 Fragment Offset 值計算的。

Fragment 報文頭不存在于最終重組的數據包中。

如果分段是一個完整的數據報(即,Fragment Offset 字段和 M 標志都為零),那么它不需要任何進一步的重組,應該作為一個完全重組的數據包來處理(即更新 Next Header,調整 Payload長度、刪除 Fragment 報文頭等)。與此數據包匹配的任何其他片段(即,相同的 IPv6 源地址、IPv6 目標地址和片段標識)應獨立處理。

重組分段數據包時可能會出現以下錯誤情況:

** 如果在接收到該數據包的第一個到達片段后 60 秒內收到的片段不足以完成數據包的重組,則必須放棄該數據包的重組,并且必須丟棄該數據包已接收的所有片段.如果接收到第一個片段(即片段偏移為零的片段),則應向該片段的源發送 ICMP Time Exceeded -- Fragment Reassembly Time Exceeded 消息。

** 如果從片段數據包的 Payload Length 字段導出的片段長度不是 8 個八位字節的倍數,并且該片段的 M 標志為 1,則必須丟棄該片段,并且 ICMP 參數問題,代碼 0 , 消息應該發送到分段的源,指向分段數據包的 Payload Length 字段。

** 如果片段的長度和偏移量使得從該片段重組的數據包的有效載荷長度將超過 65,535 個八位字節,則必須丟棄該片段,并且應將 ICMP 參數問題,代碼 0,消息發送到源分段的,指向分段包的Fragment Offset字段。

** 如果第一個片段不包括通過上層報文頭的所有報文頭,則應丟棄該片段,并將 ICMP 參數問題,代碼 3,消息發送到片段的源,并將指針字段設置為零。

** 如果正在重組的任何片段與為同一數據包重組的任何其他片段重疊,則必須放棄該數據包的重組,并且必須丟棄該數據包已收到的所有片段,并且不應有 ICMP 錯誤消息發送。

需要注意的是,片段在網絡中可能會被復制。代替將這些完全重復的片段視為重疊片段,實現可以選擇檢測這種情況并丟棄完全重復的片段,同時保留屬于同一數據包的其他片段。

以下情況預計不會頻繁發生,但如果發生,則不會被視為錯誤:

同一個原始數據包的不同分段的Fragment 頭之前的頭的數量和內容可能不同。在每個片段包中的片段包頭之前,無論出現什么包頭,都會在包到達時進行處理,然后再將片段排隊以進行重組。只有 Offset zero fragment 數據包中的那些頭被保留在重新組裝的數據包中。

同一原始報文的不同分段的分段頭中的下一個頭值可能不同。只有來自 Offset zero fragment 數據包的值用于重組。

IPv6 報文頭中的其他字段也可能因重新組裝的片段而異。如果使用來自偏移零片段的值的基本機制不夠充分,則使用這些字段的規范可能會提供附加說明。例如,[RFC3168] 的第 5.3 節描述了如何組合來自不同片段的顯式擁塞通知 (Explicit Congestion Notification,ECN) 位以導出重組數據包的 ECN 位。

4.6、 目的選項報文頭

Destination Options 報文頭用于攜帶僅需要由數據包的目標節點檢查的可選信息。Destination Options 報文頭由緊接在前一個報文頭中的 Next Header 值 60 標識,并具有以下格式:

IPv6協議規范

下一個報文頭:8 位選擇器。標識緊跟在 Destination Options 報文頭之后的報文頭類型。使用與 IPv4 協議字段 [IANA-PN] 相同的值。

HDR Ext Len:8 位無符號整數。Destination Options 報文頭的長度,以 8 個八位字節為單位,不包括前 8 個八位字節。

選項:可變長度字段,其長度使得完整的目標選項報文頭是 8 個八位字節長的整數倍。包含一個或多個 TLV 編碼選項,如第 4.2 節所述。

本文檔中定義的唯一目標選項是第 4.2 節中指定的 Pad1 和 PadN 選項。

請注意,有兩種可能的方式在 IPv6 數據包中對可選目標信息進行編碼:作為目標選項報文頭中的選項或作為單獨的擴展報文頭。Fragment 報文頭和 Authentication 報文頭是后一種方法的示例。可以使用哪種方法取決于不理解可選信息的目標節點需要什么操作:

** 如果目標節點想要丟棄數據包,并且僅當數據包的目標地址不是多播地址時,才向數據包的源地址發送 ICMP Unrecognized Type 消息,則該信息可以編碼為單獨的報文頭或作為 Destination Options 報文頭中的一個選項,其 Option Type 的最高 2 位值為 11。選擇可能取決于以下因素:哪個占用更少的八位字節,或者哪個產生更好的對齊或更有效的解析。

** 如果需要任何其他操作,則必須將信息編碼為 Destination Options 報文頭中的選項,其選項類型的最高 2 位值為 00、01 或 10,指定所需的操作(參見第 4.2 節) )。

4.7、 沒有下一個報文頭

IPv6 報文頭或任何擴展報文頭的 Next Header 字段中的值 59 表示該報文頭后面沒有任何內容。如果 IPv6 報文頭的 Payload Length 字段指示在其 Next Header 字段包含 59 的報文頭末尾之后存在八位字節,則如果轉發數據包,則必須忽略這些八位字節并保持不變地傳遞。

4.8、 定義新的擴展頭和選項

不建議定義新的 IPv6 擴展報文頭,除非沒有現有的 IPv6 擴展報文頭可通過為該 IPv6 擴展報文頭指定新選項來使用。指定新 IPv6 擴展頭的提案必須包括詳細的技術解釋,說明為什么現有 IPv6 擴展頭不能用于所需的新功能。有關其他背景信息,請參閱 [RFC6564]。

注意:不能定義需要逐跳行為的新擴展報文頭,因為如本文檔第 4 節中所指定,具有逐跳行為的唯一擴展報文頭是逐跳選項報文頭。

不推薦使用新的逐跳選項,因為節點可能被配置為忽略逐跳選項報文頭,丟棄包含逐跳選項報文頭的數據包,或分配包含逐跳選項報文頭的數據包到緩慢的處理路徑。考慮定義新的逐跳選項的設計人員需要了解這種可能的行為。為什么在標準化之前需要任何新的逐跳選項,必須有一個非常明確的理由。

建議使用 Destination Options 頭代替定義新的擴展頭來攜帶只能由數據包的目的節點檢查的可選信息,因為它們提供更好的處理和向后兼容性。

如果定義了新的擴展頭,它們需要使用以下格式:

IPv6協議規范

下一個報文頭:8 位選擇器。標識緊跟在擴展報文頭之后的報文頭類型。使用與 IPv4 協議字段 [IANA-PN] 相同的值。

HDR Ext Len:8 位無符號整數。Destination Options 報文頭的長度,以 8 個八位字節為單位,不包括前 8 個八位字節。

報文頭特定數據:可變長度字段。特定于擴展報文頭的字段。

5、 數據包大小問題

IPv6 要求 Internet 中的每個鏈接的 MTU 為 1280 八位字節或更大。這稱為 IPv6 最小鏈路 MTU。在任何不能一次性傳送 1280 個八位字節數據包的鏈路上,必須在 IPv6 之下的一層提供特定于鏈路的分段和重組。

具有可配置 MTU 的鏈路(例如,PPP 鏈路 [RFC1661])必須配置為具有至少 1280 個八位字節的 MTU;建議將它們配置為 1500 個八位字節或更大的 MTU,以適應可能的封裝(即隧道)而不會導致 IPv6 層分段。

從節點直接連接到的每條鏈路,該節點必須能夠接受與該鏈路的 MTU 一樣大的數據包。

強烈建議 IPv6 節點實現路徑 MTU 發現 [RFC8201],以便發現和利用大于 1280 八位字節的路徑 MTU。然而,最小的 IPv6 實現(例如,在引導 ROM 中)可能會簡單地將自身限制為發送不超過 1280 個八位字節的數據包,并省略路徑 MTU 發現的實現。

為了發送大于路徑 MTU 的數據包,節點可以使用 IPv6 Fragment 報文頭在源處對數據包進行分段,并在目的重新組裝。但是,在任何能夠調整其數據包以適應測量的路徑 MTU(即低至 1280 個八位字節)的應用程序中,不鼓勵使用此類分段。

一個節點必須能夠接受一個分段的數據包,在重組后,該數據包大到 1500 個八位字節。一個節點被允許接受重組為超過 1500 個八位字節的分段數據包。依賴 IPv6 分段發送大于路徑 MTU 的數據包的上層協議或應用程序不應發送大于 1500 個八位字節的數據包,除非它保證目的能夠重新組裝更大尺寸的數據包。

6、 流標簽

源使用 IPv6 報文頭中的 20 位流標簽字段來標記要在網絡中作為單個流處理的數據包序列。

IPv6 流標簽的當前定義可以在 [RFC6437] 中找到。

7、 流量類別

IPv6 報文頭中的 8 位流量類別字段被網絡用于流量管理。接收到的數據包或片段中的流量類別位的值可能與數據包源發送的值不同。

[RFC2474] 和 [RFC3168] 中規定了當前使用的流量類別字段用于區分服務和顯式擁塞通知。

8、 上層協議問題

IPv6協議規范

8.1、 上層校驗和

任何在其校驗和計算中包含來自 IP 報文頭的地址的傳輸或其他上層協議都必須修改以在 IPv6 上使用,以包含 128 位 IPv6 地址而不是 32 位 IPv4 地址。特別是,下圖顯示了 IPv6 的 TCP 和 UDP“偽報文頭”:

** 如果 IPv6 數據包包含路由報文頭,則偽報文頭中使用的目標地址是最終目的的目標地址。在始發節點,該地址將位于路由報文頭的最后一個元素中;在接收方,該地址將位于 IPv6 報文頭的目標地址字段中。

** 偽報文頭中的下一個報文頭值標識

上層協議(例如,TCP 為 6,UDP 為 17)。如果 IPv6 頭和上層頭之間存在擴展頭,它將與 IPv6 頭中的 Next Header 值不同。

** 偽頭中的 Upper-Layer Packet Length 是上層頭和數據(例如 TCP 頭加 TCP 數據)的長度。一些上層協議攜帶自己的長度信息(例如UDP頭中的長度字段);對于此類協議,這是偽報文頭中使用的長度。其他協議(如 TCP)不攜帶自己的長度信息,在這種情況下,偽頭中使用的長度是來自 IPv6 頭的有效載荷長度減去 IPv6 頭和上層之間存在的任何擴展頭的長度-層報文頭。

** 與 IPv4 不同,當 UDP 數據包由 IPv6 節點發起時,默認行為是 UDP 校驗和不是可選的。也就是說,無論何時發起 UDP 數據包,IPv6 節點都必須對數據包和偽報文頭計算 UDP 校驗和,如果計算結果為零,則必須將其更改為十六進制 FFFF 以放置在 UDP 報文頭中. IPv6 接收器必須丟棄包含零校驗和的 UDP 數據包,并應記錄錯誤。

** 作為默認行為的一個例外,使用 UDP 作為隧道封裝的協議可能會為發送和/或接收的特定端口(或端口集)啟用零校驗和模式。任何實現零校驗和模式的節點都必須遵循“使用具有零校驗和的 IPv6 UDP 數據報的適用性聲明”[RFC6936] 中指定的要求。

ICMP [RFC4443] 的 IPv6 版本在其校驗和計算中包含上述偽頭;這是對 ICMP 的 IPv4 版本的更改,它的校驗和中不包含偽報文頭。更改的原因是為了保護 ICMP 免受其所依賴的 IPv6 報文頭的那些字段的錯誤傳遞或損壞,與 IPv4 不同,這些字段未包含在 Internet 層校驗和中。ICMP 偽頭中的 Next Header 字段包含值 58,它標識 ICMP 的 IPv6 版本。

8.2、 最大數據包生命周期

與 IPv4 不同,IPv6 節點不需要強制執行最大數據包生命周期。這就是 IPv4 的“生存時間”字段在 IPv6 中更名為“跳數限制”的原因。實際上,很少有(如果有的話)IPv4 實現符合限制數據包生命周期的要求,因此這在實踐中并沒有改變。任何依賴互聯網層(無論是 IPv4 還是 IPv6)來限制數據包生命周期的上層協議都應該升級以提供自己的機制來檢測和丟棄過時的數據包。

8.3、 最大上層有效載荷大小

在計算可用于上層數據的最大有效載荷大小時,上層協議必須考慮 IPv6 報文頭相對于 IPv4 報文頭的更大尺寸。例如,在 IPv4 中,TCP 的最大分段大小 (MSS) 選項計算為最大數據包大小(默認值或通過路徑 MTU 發現學習的值)減去 40 個八位字節(20 個八位字節用于最小長度的 IPv4 報文頭和 20 個八位字節)對于最小長度的 TCP 報文頭)。在 IPv6 上使用 TCP 時,MSS 必須計算為最大數據包大小減去 60 個八位字節,因為最小長度的 IPv6 報文頭(即沒有擴展報文頭的 IPv6 報文頭)比最小長度的 IPv4 報文頭長 20 個八位字節。

8.4、 響應攜帶路由頭的數據包

當上層協議發送一個或多個數據包以響應包含路由報文頭的接收數據包時,響應數據包不得包含通過“反轉”接收到的路由報文頭而自動導出的路由報文頭,除非完整性已驗證接收的源地址和路由報文頭的真實性(例如,通過在接收的數據包中使用身份驗證報文頭)。換句話說,僅允許以下類型的數據包響應接收到的帶有路由頭的數據包:

** 不攜帶路由頭的響應數據包。

** 帶有路由報文頭的響應數據包,不是通過反轉接收到的數據包的路由報文頭(例如,由本地配置提供的路由報文頭)導出的。

** 帶有路由頭的響應包是通過反轉接收到的包的路由頭導出的,當且僅當來自接收包的源地址和路由頭的完整性和真實性已經被響應者驗證。

9、 IANA 考慮

許多 IANA 注冊機構都引用了 RFC 2460。這些包括:

** Internet 協議版本 6 (IPv6) 參數 [IANA-6P]

** 分配的互聯網協議編號 [IANA-PN]

** ONC RPC 網絡標識符 (netids) [IANA-NI]

** 網絡層協議標識符 (NLPID) [IANA-NL]

** 協議注冊機構 [IANA-PR]

IANA 已更新這些引用以指向本文檔。

10、 安全考慮

從數據包的基本格式和傳輸的角度來看,IPv6 具有類似于 IPv4 的安全特性。這些安全問題包括:

** 竊聽,其中路徑上的元素可以觀察每個 IPv6 數據報的整個數據包(包括內容和元數據)。

** 重放,攻擊者從線路上記錄一系列數據包,并將它們回放給最初接收它們的一方。

** 數據包插入,攻擊者偽造具有某些選定屬性集的數據包并將其注入網絡。

** 數據包刪除,攻擊者從網絡中刪除數據包。

** 數據包修改,攻擊者從線路中移除數據包,對其進行修改,然后將其重新注入網絡。

** 中間人 (Man-in-the-middle,MITM) 攻擊,攻擊者破壞通信流,以偽裝成發送者到接收者和接收者到發送者。

** 拒絕服務 (Denial-of-service,DoS) 攻擊,攻擊者向目標發送大量合法流量以壓制它。

通過使用“Internet 協議安全架構”[RFC4301],可以保護 IPv6 數據包免受竊聽、重放、數據包插入、數據包修改和 MITM 攻擊。此外,還可以使用傳輸層安全 (TLS) 或安全外殼 (SSH) 等上層協議來保護運行在 IPv6 之上的應用層流量。

沒有任何機制可以防止 DoS 攻擊。防御這些類型的攻擊超出了本規范的范圍。

IPv6 地址明顯大于 IPv4 地址,這使得在 Internet 上甚至在單個網絡鏈接(例如局域網)上掃描地址空間變得更加困難。有關更多信息,請參閱 [RFC7707]。

由于減少了地址轉換技術的使用,因此與 IPv4 相比,節點的 IPv6 地址有望在 Internet 上更加明顯。這會產生一些額外的隱私問題,例如更容易區分端點。有關更多信息,請參閱 [RFC7721]。

IPv6 擴展頭架構的設計,在增加了很多靈活性的同時,也帶來了新的安全挑戰。如下所述,與 Fragment 擴展報文頭相關的問題已得到解決,但很明顯,對于未來設計的任何新擴展報文頭,都需要徹底檢查安全隱患,這需要包括新擴展報文頭如何與現有的擴展頭。有關更多信息,請參閱 [RFC7045]。

此版本的 IPv6 規范解決了在 IPv6 規范的先前版本 [RFC2460] 中發現的許多安全問題。這些包括:

** 修改了文本以處理整個數據報的片段的情況(即片段偏移字段和 M 標志都為零)。如果收到,則應將它們作為重新組裝的數據包進行處理。任何其他匹配的片段都應該獨立處理。片段創建過程被修改為不創建整個數據報片段(片段偏移字段和 M 標志為零)。有關更多信息,請參閱 [RFC6946] 和 [RFC8021]。

** 刪除了第 5 節中要求在報告下一跳 MTU 的 ICMP 數據包太大消息小于 1280 時在傳出數據包中包含 Fragment 報文頭的段落。有關更多信息,請參閱 [RFC6946]。

** 更改文本以要求 IPv6 節點不得創建重疊片段。此外,在重組 IPv6 數據報時,如果確定其組成片段中的一個或多個是重疊片段,則必須靜默丟棄整個數據報(以及任何組成片段)。包括在收到重疊片段時不應發送 ICMP 錯誤消息的說明。有關更多信息,請參閱 [RFC5722]。

** 修改了正文,要求通過第一個上層報文頭的所有報文頭都在第一個片段中。有關更多信息,請參閱 [RFC7112]。

** 合并了 [RFC5095] 和 [RFC5871] 的更新,刪除了路由頭類型 0 (RH0) 的描述,路由頭的分配指南在 RFC 5871 中指定,并從所需的擴展頭列表中刪除了 RH0 。

與 IPv6 其他部分相關的安全問題,包括尋址、ICMPv6、路徑 MTU 發現等,在適當的規范中進行了討論。

11、 參考文獻

11.1、 規范參考

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981,.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998,.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001,.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006,.

[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006,.

[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011,.

11.2、 參考資料

[Err2541] RFC Errata, Erratum ID 2541, RFC 2460.

[Err4279] RFC Errata, Erratum ID 4279, RFC 2460.

[Err4657] RFC Errata, Erratum ID 4657, RFC 2460.

[Err4662] RFC Errata, Erratum ID 4662, RFC 2460.

[IANA-6P] IANA, "Internet Protocol Version 6 (IPv6) Parameters",.

[IANA-EH] IANA, "IPv6 Extension Header Types",.

[IANA-NI] IANA, "ONC RPC Network Identifiers (netids)",.

[IANA-NL] IANA, "Network Layer Protocol Identifiers (NLPIDs) of Interest",.

[IANA-PN] IANA, "Protocol Numbers",.

[IANA-PR] IANA, "Protocol Registries",.

[IANA-RH] IANA, "Routing Types",.

[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998,.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005,.

[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005,.

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005,.

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007,.

[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009,.

[RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871, May 2010,.

[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, DOI 10.17487/RFC6564, April 2012,.

[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013,.

[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 6946, DOI 10.17487/RFC6946, May 2013,.

[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013,.

[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/RFC7112, January 2014,.

[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,.

[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016,.

[RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016,.

[RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6 Atomic Fragments Considered Harmful", RFC 8021, DOI 10.17487/RFC8021, January 2017,.

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017,.

附錄 A、 選項格式指南

本附錄就如何在設計要在 Hop-by-Hop Options 報文頭或 Destination Options 報文頭中使用的新選項時如何布置字段提供一些建議,如第 4.2 節所述。這些準則基于以下假設:

** 一個理想的特性是選項的選項數據區域內的任何多八位字節字段都在它們的自然邊界上對齊,即寬度為 n 個八位字節的字段應放置在從躍點開始的 n 個八位字節的整數倍處-by-Hop 或 Destination Options 報文頭,對于 n = 1、2、4 或 8。

** 另一個可取的特性是 Hop-by-Hop 或 Destination Options 報文頭占用盡可能少的空間,前提是報文頭是 8 個八位字節長的整數倍。

** 可以假設,當任一帶有選項的報文頭存在時,它們攜帶的選項數量非常少,通常只有一個。

這些假設建議使用以下方法來布置選項的字段:將字段從最小到最大排序,沒有內部填充,然后根據最大字段的對齊要求(最多8 個八位字節的最大對齊)。以下示例說明了此方法:

示例 1

如果選項 X 需要兩個數據字段,其中一個長度為 8 個八位字節,一個長度為 4 個八位字節,則其布局如下:

IPv6協議規范

它的對齊要求是 8n+2,以確保 8 個八位字節字段從封閉報文頭開始處的 8 倍偏移處開始。包含此選項的完整 Hop-by-Hop 或 Destination Options 報文頭如下所示:

IPv6協議規范

示例 2

如果選項 Y 需要三個數據字段,其中一個長度為 4 個八位字節,一個長度為 2 個八位字節,一個長度為 1 個八位字節,則其布局如下:

IPv6協議規范

它的對齊要求是 4n+3,以確保 4 個八位字節字段從封閉報文頭的開始位置以 4 的倍數偏移開始。包含此選項的完整 Hop-by-Hop 或 Destination Options 報文頭如下所示:

IPv6協議規范

示例 3

包含示例 1 和示例 2 中的選項 X 和 Y 的逐跳或目標選項報文頭將具有以下兩種格式之一,具體取決于哪個選項首先出現:

IPv6協議規范

附錄 B、 和 RFC 2460 相比的更改

本備忘錄對 RFC 2460 有以下更改。

** 從摘要中刪除了下一代 IP。

** 在第 1 節中添加了數據傳輸順序與 RFC 791 中定義的 IPv4 相同的文本。

** 澄清了第 3 節中關于遞減跳躍限制的文本。

** 闡明擴展報文頭(Hop-by-Hop Options 報文頭除外)不會被沿數據包傳送路徑的任何節點處理、插入或刪除。

** 將 Hop-by-Hop Options 報文頭的要求更改為“可以”,并添加了一條注釋以指示關于 Hop-by-Hop Options 報文頭的預期內容。

** 在第 4 節中添加了一段以闡明擴展報文頭如何編號以及哪些是上層報文頭。

** 在第 4 節末尾添加了對“IPv6 擴展報文頭類型”IANA 注冊表的引用。

** 合并了來自 RFC 5095 和 5871 的更新,以刪除 RH0 的描述,路由報文頭的分配指南在 RFC 5871 中指定,并從所需的擴展報文頭列表中刪除了 RH0。

** 根據 RFC 5722、6946、7112 和 8021 的更新修訂了關于 IPv6 分段的第 4.5 節。這包括:

- 修改了文本以處理整個數據報的片段的情況(即片段偏移字段和 M 標志都為零)。如果收到,則應將它們作為重新組裝的數據包進行處理。任何其他匹配的片段都應該獨立處理。修改后的片段創建過程被修改為不創建整個數據報片段(片段偏移字段和 M 標志為零)。

- 更改文本以要求 IPv6 節點不得創建重疊片段。此外,在重組 IPv6 數據報時,如果確定其組成片段的一個或多個是重疊片段,則必須靜默丟棄整個數據報(以及任何組成片段)。包括在收到重疊片段時不應發送 ICMP 錯誤消息的說明。

- 修改了文本,要求通過第一個 Upper-Layer 報文頭的所有報文頭都在第一個片段中。這更改了描述數據包如何分段和重組的文本,并添加了一個新的錯誤案例。

- 在處理完全重復的片段的片段報文頭過程中添加了文本。

- 更新了 Fragmentation 報文頭文本以更正身份驗證報文頭 (AH) 的包含并注明無下一個報文頭情況。

- 將 Fragment 報文報文頭分中的術語從“Unfragmentable Headers”更改為“Per-Fragment headers”。

- 刪除了第 5 節中的段落,如果 ICMP 數據包太大消息報告下一跳 MTU 小于 1280,則要求在傳出數據包中包含片段報文頭。

- 更改文本以闡明 MTU 限制和 8 字節限制,并在第一個片段中注明對報文頭的限制。

** 在第 4.5 節中,添加了說明,指出 IPv6 報文頭中的某些字段也可能因重新組裝的片段而異,并且其他規范可能會提供有關如何重新組裝它們的附加說明。例如,參見 [RFC3168] 的第 5.3 節。

** 合并了來自 RFC 6564 的更新以添加新的第 4.8 節,該節描述了定義新擴展報文頭和選項的建議。

** 向第 5 節添加文本以定義“IPv6 最小鏈路 MTU”。

** 簡化了第 6 節中關于流標簽的文本并刪除了附錄 A(“流標簽字段的語義和用法”);相反,指向 [RFC6437] 中的 IPv6 流標簽字段和 [RFC2474] 和 [RFC3168] 中的流量類別字段的當前規范。

** 在第 8 節中合并了 RFC 6935(“隧道數據包的 IPv6 和 UDP 校驗和”)所做的更新。為處理具有隧道零校驗和的 UDP 數據包的默認行為添加了一個例外。

** 在第 9 節“IANA 注意事項”中添加了說明,以將 RFC 2460 的引用更改為本文檔。

** 修訂并擴展了第 10 節“安全注意事項”。

** 在致謝部分添加了一個段落,感謝更新文檔的作者。

** 更新了對當前版本的引用,并分配了對規范性和信息性的引用。

** 進行了更改以解決 RFC 2460 上的勘誤表。這些是:

勘誤 ID 2541 [Err2541]:此勘誤指出,當流標簽的長度從 RFC 1883 中的 24 位更改為 20 位時,RFC 2460 未更新 RFC 2205。此問題已在定義流標簽的 RFC 6437 中解決.此規范現在引用 RFC 6437。無需更改。

勘誤 ID 4279 [Err4279]:此勘誤指出規范不處理轉發節點接收具有零跳數限制的數據包的情況。這在本規范的第 3 節中得到了修復。

勘誤 ID 4657 [Err4657]:此勘誤建議文本,擴展報文頭絕不能由除數據包源之外的任何節點插入。這已在第 4 節“IPv6 擴展報文頭”中解決。

勘誤表 ID 4662 [Err4662]:該勘誤表建議的文本是,除了一個例外,擴展報文頭不會被沿數據包傳遞路徑的任何節點檢查、處理、修改、插入或刪除。這已在第 4 節“IPv6 擴展報文頭”中解決。

勘誤 ID 2843:此勘誤標記為“已拒絕”。沒有進行任何更改。

以上就是IPv6協議規范的介紹,Vecloud為客戶提供豐富的IPV6網絡專線解決方案,主要國家包含日本、韓國、倫敦、法蘭克福、洛杉磯、圣何塞、華盛頓、印度、迪拜、南非等均可隨時提供網絡專線和IP傳輸服務。

免責聲明:部分文章信息來源于網絡以及網友投稿,本網站只負責對文章進行整理、排版、編輯,是出于傳遞 更多信息之目的,并不意味著贊同其觀點或證實其內容的真實性,如本站文章和轉稿涉及版權等問題,請作者在及時聯系我們本站,我們會盡快處理。

標題:IPv6協議規范

TAG標簽: IPV6

地址:http://www.indiamait.com/hangyedongtai/314.html