Internet Protocol, Version 6 (IPv6) Specification
本文檔規(guī)定了 Internet 協(xié)議的第 6 版(IPv6)，它廢棄了 RFC 2460。
這是一個 Internet 標(biāo)準(zhǔn)跟蹤文檔。
本文檔是 Internet 工程任務(wù)組 (IETF) 的產(chǎn)品。它代表了 IETF 社區(qū)的共識。它已接受公眾審查，并已被互聯(lián)網(wǎng)工程指導(dǎo)組 (IESG) 批準(zhǔn)出版。有關(guān) Internet 標(biāo)準(zhǔn)的更多信息，請參見 RFC 7841 的第 2 節(jié)。
有關(guān)本文檔的當(dāng)前狀態(tài)、任何勘誤以及如何提供反饋的信息，請訪問 http://www.rfc-editor.org/info/rfc8200。
版權(quán)所有 (c) 2017 IETF Trust 和確定為文檔作者的人員。版權(quán)所有。
本文檔受 BCP 78 和 IETF 信托與 IETF 文檔相關(guān)的法律規(guī)定 (http://trustee.ietf.org/license-info) 的約束，該規(guī)定在本文檔發(fā)布之日生效。請仔細(xì)閱讀這些文件，因為它們描述了您對本文件的權(quán)利和限制。從本文檔中提取的代碼組件必須包含 Trust Legal Provisions 第 4.e 節(jié)中所述的簡化 BSD 許可文本，并且不提供如簡化 BSD 許可中所述的保證。
本文檔可能包含來自于 2008 年 11 月 10 日之前發(fā)布或公開提供的 IETF 文檔或 IETF 貢獻(xiàn)的材料。控制本材料某些版權(quán)的人可能未授予 IETF 信托允許修改此類材料的權(quán)利在 IETF 標(biāo)準(zhǔn)流程之外。如果沒有從控制此類材料版權(quán)的人那里獲得足夠的許可，則不得在 IETF 標(biāo)準(zhǔn)流程之外修改本文檔，并且不得在 IETF 標(biāo)準(zhǔn)流程之外創(chuàng)建其衍生作品，除非將其格式化為作為 RFC 發(fā)布或?qū)⑵浞g成英語以外的語言。
IP 版本 6 (IPv6) 是互聯(lián)網(wǎng)協(xié)議 (Internet Protocol，IP) 的新版本，設(shè)計為 IP 版本 4 (IPv4) [RFC791] 的后繼版本。從 IPv4 到 IPv6 的變化主要分為以下幾類：
** 擴(kuò)展尋址能力
IPv6 將 IP 地址大小從 32 位增加到 128 位，以支持更多級別的尋址層次結(jié)構(gòu)、更多數(shù)量的可尋址節(jié)點(diǎn)以及更簡單的地址自動配置。通過向多播地址添加“范圍”字段來提高多播路由的可擴(kuò)展性。并且定義了一種稱為“任播地址”的新型地址；它用于向一組節(jié)點(diǎn)中的任何一個發(fā)送數(shù)據(jù)包。
** 報文頭格式簡化
一些 IPv4 報文頭字段已被刪除或成為可選字段，以降低數(shù)據(jù)包處理的常見情況處理成本并限制 IPv6 報文頭的帶寬成本。
** 改進(jìn)了對擴(kuò)展和選項的支持
IP 報文頭選項編碼方式的變化允許更高效的轉(zhuǎn)發(fā)、對選項長度的更寬松的限制，以及在未來引入新選項的更大靈活性。
** 流標(biāo)簽?zāi)芰?/p>
添加了一項新功能，可以對發(fā)送方請求在網(wǎng)絡(luò)中作為單個流處理的數(shù)據(jù)包序列進(jìn)行標(biāo)記。
** 身份驗證和隱私功能
為 IPv6 指定了支持身份驗證、數(shù)據(jù)完整性和（可選）數(shù)據(jù)機(jī)密性的擴(kuò)展。
本文檔規(guī)定了基本 IPv6 報文頭和最初定義的 IPv6 擴(kuò)展頭和選項。它還討論了數(shù)據(jù)包大小問題、流標(biāo)簽和流量類別的語義以及 IPv6 對上層協(xié)議的影響。IPv6 地址的格式和語義在 [RFC4291] 中單獨(dú)指定。[RFC4443] 中規(guī)定了所有 IPv6 實(shí)現(xiàn)都需要包含的 ICMP 的 IPv6 版本。
IPv6 的數(shù)據(jù)傳輸順序與 [RFC791] 的附錄 B 中定義的 IPv4 相同。
注意：由于本文檔已廢棄 [RFC2460]，因此本文檔中引用的任何包含指向 RFC 2460 的指針的文檔都應(yīng)被解釋為引用本文檔。
node：節(jié)點(diǎn)，實(shí)現(xiàn) IPv6 的設(shè)備。
router：路由器，轉(zhuǎn)發(fā)非自身為目的址的 IPv6 數(shù)據(jù)包的節(jié)點(diǎn)。（請參閱下面的注釋。）
host：主機(jī)，任何不是路由器的節(jié)點(diǎn)。（請參閱下面的注釋。）
upper layer：上層，在 IPv6 網(wǎng)絡(luò)層之上的協(xié)議層。比如傳輸協(xié)議（例如 TCP 和 UDP）、控制協(xié)議（例如 ICMP）、路由協(xié)議（例如 OSPF）以及通過 IPv6 “隧道化”（即封裝在）IPv6 中的 Internet 層或較低層協(xié)議，例如 Internetwork Packet Exchange (IPX) )、AppleTalk 或 IPv6 本身。
link：鏈路，節(jié)點(diǎn)可以在鏈路層（即 IPv6 正下方的層）進(jìn)行通信的通信設(shè)施或介質(zhì)。例如以太網(wǎng)（簡單或橋接）；PPP 鏈接；X.25、幀中繼或 ATM 網(wǎng)絡(luò)；和互聯(lián)網(wǎng)層或更高層的“隧道”，例如通過 IPv4 或 IPv6 本身的隧道。
neighbors：鄰居，連接到同一鏈路的節(jié)點(diǎn)。
interface：接口，節(jié)點(diǎn)和鏈路的連接點(diǎn)。
address：地址，一個接口或一組接口的 IPv6 層標(biāo)識符。
packet：包/報文，一個 IPv6 報文頭和有效載荷。
link MTU：鏈路MTU，可以通過鏈路傳送的最大傳輸單元，即以八位字節(jié)為單位的最大數(shù)據(jù)包大小。
path MTU：路徑MTU，源節(jié)點(diǎn)和目的節(jié)點(diǎn)之間路徑中所有鏈路的最小鏈路 MTU。
注意：具有多個接口的設(shè)備可以配置為轉(zhuǎn)發(fā)來自其某些接口集（少于全部）的非自身目標(biāo)數(shù)據(jù)包，并丟棄來自其他接口的非自身目標(biāo)數(shù)據(jù)包。當(dāng)從前一個（轉(zhuǎn)發(fā)）接口接收來自鄰居的數(shù)據(jù)包并與鄰居交互時，此類設(shè)備必須遵守路由器的協(xié)議要求。當(dāng)從后者（非轉(zhuǎn)發(fā)）接口接收數(shù)據(jù)包并與鄰居交互時，它必須遵守主機(jī)的協(xié)議要求。
Version：版本， 4 位 Internet 協(xié)議版本號 = 6。
Traffic Class：流量類別， 8 位流量類別字段。見第 7 節(jié)。
Flow Label：流標(biāo)簽， 20 位流標(biāo)簽。見第 6 節(jié)。
Payload Length：有效載荷長度， 16 位無符號整數(shù)。IPv6 有效負(fù)載的長度，即此 IPv6 報文頭后面的數(shù)據(jù)包的其余部分，以八位字節(jié)為單位。（請注意，存在的任何擴(kuò)展報文頭（請參閱第 4 節(jié)）都被視為有效載荷的一部分，即包含在長度計數(shù)中。）
Next Header：下一個報文頭， 8 位選擇器。標(biāo)識緊跟在 IPv6 報文頭之后的報文頭類型。使用與 IPv4 協(xié)議字段 [IANA-PN] 相同的值。
Hop Limit：跳數(shù)限制， 8 位無符號整數(shù)。每個轉(zhuǎn)發(fā)數(shù)據(jù)包的節(jié)點(diǎn)減 1。轉(zhuǎn)發(fā)時，如果接收時 Hop Limit 為零或遞減為零，則丟棄該數(shù)據(jù)包。作為數(shù)據(jù)包目的的節(jié)點(diǎn)不應(yīng)丟棄 Hop Limit 為零的數(shù)據(jù)包；它應(yīng)該正常處理數(shù)據(jù)包。
Source Address：源地址，數(shù)據(jù)包始發(fā)者的 128 位地址。參見 [RFC4291]。
Destination Address：目標(biāo)地址，數(shù)據(jù)包預(yù)期接收者的 128 位地址（如果存在路由報文頭，則可能不是最終接收者）。參見 [RFC4291] 和第 4.4 節(jié)。
在 IPv6 中，可選的互聯(lián)網(wǎng)層信息被編碼在單獨(dú)的報文頭中，這些報文頭可以放置在數(shù)據(jù)包中的 IPv6 報文頭和上層報文頭之間。有少量這樣的擴(kuò)展報文頭，每個報文頭由不同的下一個報文頭值標(biāo)識。
擴(kuò)展報文頭從 IANA IP 協(xié)議編號 [IANA-PN] 編號，與 IPv4 和 IPv6 使用的值相同。當(dāng)處理數(shù)據(jù)包中的 Next Header 值序列時，第一個不是擴(kuò)展頭 [IANA-EH] 表示數(shù)據(jù)包中的下一項是相應(yīng)的上層頭。如果沒有上層報文頭，則使用特殊的“無下一個報文頭”值。
如這些示例中所示，IPv6 數(shù)據(jù)包可以攜帶零個、一個或多個擴(kuò)展報文頭，每個擴(kuò)展報文頭由前一個報文頭的下一個報文頭字段標(biāo)識：
擴(kuò)展報文頭（Hop-by-Hop Options 報文頭除外）不會被任何沿著數(shù)據(jù)包傳遞路徑的節(jié)點(diǎn)處理、插入或刪除，直到數(shù)據(jù)包到達(dá)該節(jié)點(diǎn)（或節(jié)點(diǎn)集的每個節(jié)點(diǎn)，在多播情況下）在 IPv6 報文頭的目標(biāo)地址字段中標(biāo)識。
Hop-by-Hop Options 報文頭不會被插入或刪除，但可以被沿數(shù)據(jù)包傳遞路徑的任何節(jié)點(diǎn)檢查或處理，直到數(shù)據(jù)包到達(dá)節(jié)點(diǎn)（或節(jié)點(diǎn)組中的每個節(jié)點(diǎn)，在多播的情況下）在 IPv6 報文頭的目標(biāo)地址字段中標(biāo)識。Hop-by-Hop Options 報文頭（如果存在）必須緊跟在 IPv6 報文頭之后。它的存在由 IPv6 報文頭的下一個報文頭字段中的值零指示。
注意：雖然 [RFC2460] 要求所有節(jié)點(diǎn)都必須檢查和處理 Hop-by-Hop Options 報文頭，但現(xiàn)在預(yù)計，如果明確配置為這樣做，沿數(shù)據(jù)包傳送路徑的節(jié)點(diǎn)僅檢查和處理 Hop-by-Hop Options 報文頭。
在目的節(jié)點(diǎn)，對 IPv6 報文頭的 Next Header 字段的正常解復(fù)用調(diào)用模塊來處理第一個擴(kuò)展報文頭，如果沒有擴(kuò)展報文頭，則調(diào)用上層報文頭。每個擴(kuò)展頭的內(nèi)容和語義決定是否繼續(xù)下一個頭。因此，擴(kuò)展頭必須嚴(yán)格按照它們在數(shù)據(jù)包中出現(xiàn)的順序進(jìn)行處理；例如，接收方不得掃描數(shù)據(jù)包以尋找特定類型的擴(kuò)展報文頭并在處理所有前面的報文頭之前處理該報文頭。
如果作為處理報文頭的結(jié)果，目標(biāo)節(jié)點(diǎn)需要繼續(xù)處理下一個報文頭，但節(jié)點(diǎn)無法識別當(dāng)前報文頭中的 Next Header 值，則它應(yīng)該丟棄該數(shù)據(jù)包并向目標(biāo)節(jié)點(diǎn)發(fā)送 ICMP 參數(shù)問題消息。數(shù)據(jù)包的來源，ICMP 代碼值為 1（“遇到無法識別的下一個報文頭類型”），ICMP 指針字段包含原始數(shù)據(jù)包中無法識別的值的偏移量。如果節(jié)點(diǎn)在除 IPv6 報文頭之外的任何報文頭中遇到 Next Header 值為零，則應(yīng)采取相同的操作。
每個擴(kuò)展報文頭是 8 個八位字節(jié)長的整數(shù)倍，以便為后續(xù)報文頭保留 8 個八位字節(jié)對齊。每個擴(kuò)展報文頭內(nèi)的多八位字節(jié)字段在它們的自然邊界上對齊，即寬度為 n 個八位字節(jié)的字段放置在從報文頭開始的 n 個八位字節(jié)的整數(shù)倍處，對于 n = 1、2、4 或 8。
IPv6 的完整實(shí)現(xiàn)包括以下擴(kuò)展頭的實(shí)現(xiàn)：
Hop-by-Hop Options，逐跳選項
Fragment，分段
Destination Options，目的選項
Routing，路由
Authentication，驗證
Encapsulating Security Payload，封裝安全載荷
本文件規(guī)定了前四種；最后兩個分別在 [RFC4302] 和 [RFC4303] 中指定。可以在 [IANA-EH] 找到當(dāng)前的 IPv6 擴(kuò)展頭列表。
當(dāng)在同一個數(shù)據(jù)包中使用多個擴(kuò)展頭時，建議這些頭按以下順序出現(xiàn)：
IPv6 header，IPv6 報文頭
Hop-by-Hop Options header，逐跳選項報文頭
Destination Options header，目標(biāo)選項報文頭（注 1）
Routing header，路由頭
Fragment header，片段頭
Authentication header，驗證報文頭（注 2）
Encapsulating Security Payload header，封裝安全載荷頭（注 2）
Destination Options header，目的選項報文頭（注 3）
Upper-Layer header，上層報文頭
注 1：用于由出現(xiàn)在 IPv6 目標(biāo)地址字段中的第一個目標(biāo)以及路由報文頭中列出的后續(xù)目標(biāo)處理的選項。
注 2：[RFC4303] 中給出了關(guān)于認(rèn)證和封裝安全有效載荷頭的相對順序的附加建議。
注 3：對于僅由數(shù)據(jù)包的最終目的處理的選項。
每個擴(kuò)展報文頭最多應(yīng)該出現(xiàn)一次，除了 Destination Options 報文頭，它最多應(yīng)該出現(xiàn)兩次（一次在路由報文頭之前，一次在上層報文頭之前）。
如果上層報文頭是另一個 IPv6 報文頭（在 IPv6 被隧道傳輸或封裝在 IPv6 中的情況下），它可能跟隨著它自己的擴(kuò)展報文頭，它們分別受相同的排序建議的約束。
如果定義了其他擴(kuò)展報文頭，則必須指定它們相對于上面列出的報文頭的排序約束。
IPv6 節(jié)點(diǎn)必須接受并嘗試以任何順序處理擴(kuò)展報文頭，并且在同一個數(shù)據(jù)包中出現(xiàn)任意次數(shù)，但 Hop-by-Hop Options 報文頭除外，它被限制為僅出現(xiàn)在 IPv6 報文頭之后。盡管如此，強(qiáng)烈建議 IPv6 數(shù)據(jù)包的來源遵循上述推薦順序，直到并且除非后續(xù)規(guī)范修改該推薦。
本文檔中指定的兩個當(dāng)前定義的擴(kuò)展報文頭——Hop-by-Hop Options 報文頭和 Destination Options 報文頭——攜帶可變數(shù)量的“選項”，這些“選項”是以下編碼的類型-長度-值 (TLV)格式：
Option Type 選項類型的 8 位標(biāo)識符。
Opt Data Len 8 位無符號整數(shù)。此選項的選項數(shù)據(jù)字段的長度，以八位字節(jié)為單位。
選項數(shù)據(jù)可變長度字段。特定于選項類型的數(shù)據(jù)。
報文頭中的選項序列必須嚴(yán)格按照它們在報文頭中出現(xiàn)的順序進(jìn)行處理；例如，接收方不得掃描報文頭以尋找特定類型的選項并在處理所有前面的選項之前處理該選項。
選項類型標(biāo)識符在內(nèi)部進(jìn)行編碼，以便它們的最高 2 位指定在處理 IPv6 節(jié)點(diǎn)不識別選項類型時必須采取的操作：
00 - 跳過此選項并繼續(xù)處理報文頭。
01 - 丟棄數(shù)據(jù)包。
10 - 丟棄數(shù)據(jù)包，無論數(shù)據(jù)包的目標(biāo)地址是否是多播地址，都向數(shù)據(jù)包的源地址發(fā)送 ICMP 參數(shù)問題，代碼 2，消息，指向無法識別的選項類型。
11 - 丟棄數(shù)據(jù)包，并且僅當(dāng)數(shù)據(jù)包的目標(biāo)地址不是多播地址時，才向數(shù)據(jù)包的源地址發(fā)送 ICMP 參數(shù)問題，代碼 2，消息，指向無法識別的選項類型。
選項類型的第三高位指定該選項的選項數(shù)據(jù)是否可以在到達(dá)數(shù)據(jù)包最終目的的途中改變。當(dāng)數(shù)據(jù)包中存在身份驗證報文頭時，對于其數(shù)據(jù)可能在途中更改的任何選項，在計算或驗證數(shù)據(jù)包的身份驗證值時，其整個選項數(shù)據(jù)字段必須被視為零值八位字節(jié)。
0 - 選項數(shù)據(jù)在途中不會改變
1 - 選項數(shù)據(jù)可能會在途中發(fā)生變化
上述三個高階位將被視為選項類型的一部分，而不是獨(dú)立于選項類型。也就是說，特定選項由完整的 8 位選項類型標(biāo)識，而不僅僅是選項類型的低 5 位。
相同的選項類型編號空間用于 Hop-by-Hop Options 報文頭和 Destination Options 報文頭。但是，特定選項的規(guī)范可能會將其使用限制為僅這兩個報文頭之一。
個別選項可能有特定的對齊要求，以確保選項數(shù)據(jù)字段內(nèi)的多字節(jié)值落在自然邊界上。選項的對齊要求使用符號 xn+y 指定，這意味著選項類型必須出現(xiàn)在從頭開始的 x 個八位字節(jié)加上 y 個八位字節(jié)的整數(shù)倍處。例如：
2n 表示從頭開始的任何 2 個八位字節(jié)的偏移量。
8n+2 表示從頭開始的任何 8 個八位字節(jié)的偏移量，加上 2 個八位字節(jié)。
有兩個填充選項在必要時用于對齊后續(xù)選項并將包含的報文頭填充到長度為 8 個八位字節(jié)的倍數(shù)。所有 IPv6 實(shí)現(xiàn)都必須識別這些填充選項：
注意！Pad1 選項的格式是一種特殊情況——它沒有長度和值字段。
Pad1 選項用于將 1 個八位字節(jié)的填充插入報文頭的選項區(qū)域。如果需要多個八位字節(jié)的填充，則應(yīng)使用接下來描述的 PadN 選項，而不是多個 Pad1 選項。
PadN 選項用于將兩個或多個八位字節(jié)的填充插入到報文頭的選項區(qū)域中。對于填充的 N 個八位字節(jié)，Opt Data Len 字段包含值 N-2，而 Option Data 由 N-2 個零值八位字節(jié)組成。
附錄 A 包含設(shè)計新選項的格式指南。
Hop-by-Hop Options 報文頭用于攜帶可選信息，這些信息可以由沿數(shù)據(jù)包傳遞路徑的每個節(jié)點(diǎn)進(jìn)行檢查和處理。Hop-by-Hop Options 報文頭由 IPv6 報文頭中的 Next Header 值 0 標(biāo)識，并具有以下格式：
下一個報文頭：8 位選擇器。標(biāo)識緊跟在 Hop-by-Hop Options 報文頭之后的報文頭類型。使用與 IPv4 協(xié)議字段 [IANA-PN] 相同的值。
HDR Ext Len：8 位無符號整數(shù)。Hop-by-Hop Options 報文頭的長度，以 8 個八位字節(jié)為單位，不包括前 8 個八位字節(jié)。
選項：可變長度字段，其長度使得完整的逐跳選項報文頭是 8 個八位字節(jié)長的整數(shù)倍。包含一個或多個 TLV 編碼選項，如第 4.2 節(jié)所述。
本文檔中定義的唯一逐跳選項是第 4.2 節(jié)中指定的 Pad1 和 PadN 選項。
路由報文頭被 IPv6 源用來列出一個或多個在到達(dá)數(shù)據(jù)包目的的途中要“訪問”的中間節(jié)點(diǎn)。此功能與 IPv4 的松散源和記錄路由選項非常相似。Routing 報文頭由緊接在前一個報文頭中的 Next Header 值 43 標(biāo)識，并具有以下格式：
下一個報文頭：8 位選擇器。標(biāo)識緊跟在 Routing 報文頭之后的報文頭類型。使用與 IPv4 協(xié)議字段 [IANA-PN] 相同的值。
HDR Ext Len：8 位無符號整數(shù)。路由報文頭的長度，以 8 個八位字節(jié)為單位，不包括前 8 個八位字節(jié)。
路由類型：特定路由報文頭變體的 8 位標(biāo)識符。
Segments Left：8 位無符號整數(shù)。剩余路由分段的數(shù)量，即在到達(dá)最終目的之前仍要訪問的明確列出的中間節(jié)點(diǎn)的數(shù)量。
type-specific data：可變長度字段，格式由路由類型確定，長度使得完整的路由報文頭是 8 個八位字節(jié)長的整數(shù)倍。
如果在處理接收到的數(shù)據(jù)包時，節(jié)點(diǎn)遇到具有無法識別的路由類型值的路由報文頭，則節(jié)點(diǎn)所需的行為取決于 Segments Left 字段的值，如下所示：
如果 Segments Left 為零，則節(jié)點(diǎn)必須忽略路由頭并繼續(xù)處理數(shù)據(jù)包中的下一個頭，其類型由路由頭中的下一個頭字段標(biāo)識。
如果 Segments Left 不為零，則節(jié)點(diǎn)必須丟棄數(shù)據(jù)包并向數(shù)據(jù)包的源地址發(fā)送 ICMP 參數(shù)問題代碼 0 消息，指向無法識別的路由類型。
如果中間節(jié)點(diǎn)在處理接收到的數(shù)據(jù)包的路由頭后，確定將數(shù)據(jù)包轉(zhuǎn)發(fā)到鏈路 MTU 小于數(shù)據(jù)包大小的鏈路上，則該節(jié)點(diǎn)必須丟棄該數(shù)據(jù)包并發(fā)送 ICMP 數(shù)據(jù)包大消息到數(shù)據(jù)包的源地址。
當(dāng)前定義的 IPv6 路由頭及其狀態(tài)可以在 [IANA-RH] 中找到。IPv6 路由頭的分配指南可以在 [RFC5871] 中找到。
IPv6 源使用 Fragment 報文頭發(fā)送大于到達(dá)其目的的路徑 MTU 的數(shù)據(jù)包。（注意：與 IPv4 不同，IPv6 中的分段僅由源節(jié)點(diǎn)執(zhí)行，而不是由沿數(shù)據(jù)包傳送路徑的路由器執(zhí)行——參見第 5 節(jié)。）片段頭由緊接在前一個頭中的 Next Header 值 44 標(biāo)識，并且具有以下格式：
下一個報文頭：8 位選擇器。標(biāo)識原始數(shù)據(jù)包的 Fragmentable Part 的初始頭類型（定義如下）。使用與 IPv4 協(xié)議字段 [IANA-PN] 相同的值。
Reserved：8 位保留字段。傳輸初始化為零；接收時被忽略。
片段偏移量：13 位無符號整數(shù)。此報文頭后面的數(shù)據(jù)相對于原始數(shù)據(jù)包的可分段部分的開頭的偏移量（以 8 個八位字節(jié)為單位）。
Res：2 位保留字段。傳輸初始化為零；接待時被忽略。
M：1 = 更多片段；0 = 最后一個片段。
Identification:32 位。請參閱下面的說明。
為了發(fā)送一個太大而無法容納到其目的的路徑的 MTU 的數(shù)據(jù)包，源節(jié)點(diǎn)可以將數(shù)據(jù)包分成多個片段并將每個片段作為單獨(dú)的數(shù)據(jù)包發(fā)送，以便在接收器處重新組裝。
對于每個要分段的數(shù)據(jù)包，源節(jié)點(diǎn)都會生成一個標(biāo)識值。標(biāo)識必須不同于最近發(fā)送的任何其他具有相同源地址和目標(biāo)地址的分段數(shù)據(jù)包*。如果存在路由報文頭，則關(guān)注的目標(biāo)地址是最終目標(biāo)的地址。
*“最近”是指在數(shù)據(jù)包的最大可能生命周期內(nèi)，包括從源到目的的傳輸時間以及等待與同一數(shù)據(jù)包的其他片段重新組裝所花費(fèi)的時間。然而，不要求源節(jié)點(diǎn)知道最大數(shù)據(jù)包壽命。相反，假設(shè)可以通過實(shí)施導(dǎo)致低標(biāo)識重用頻率的算法來滿足要求。[RFC7739] 中描述了可以滿足此要求的算法示例。
初始的、大的、未分段的數(shù)據(jù)包被稱為“原始數(shù)據(jù)包”，它被認(rèn)為由三部分組成，如圖所示：
原始數(shù)據(jù)包：
Per-Fragment 報文頭必須包含 IPv6 報文頭加上必須由到達(dá)目的的節(jié)點(diǎn)處理的任何擴(kuò)展報文頭，即所有報文頭直到并包括路由報文頭（如果存在），否則為 Hop-by-Hop Options報文頭（如果存在），否則沒有擴(kuò)展報文頭。
擴(kuò)展報文頭是未包含在數(shù)據(jù)包的 Per-Fragment 報文報文頭分中的所有其他擴(kuò)展報文頭。為此，封裝安全有效載荷 (ESP) 不被視為擴(kuò)展報文頭。Upper-Layer 頭是第一個不是 IPv6 擴(kuò)展頭的上層頭。上層報文頭的示例包括 TCP、UDP、IPv4、IPv6、ICMPv6 和 ESP。
Fragmentable Part 由上層報文頭之后或任何包含 Next Header 值為 No Next Header 的報文頭（即初始 IPv6 報文頭或擴(kuò)展報文頭）之后的數(shù)據(jù)包的其余部分組成。
原始數(shù)據(jù)包的 Fragmentable 部分被分成多個片段。必須選擇片段的長度，使得生成的片段數(shù)據(jù)包適合到數(shù)據(jù)包目的的路徑的 MTU。每個完整的片段，可能除了最后一個（“最右邊的”）片段，都是 8 個八位字節(jié)長的整數(shù)倍。
片段在單獨(dú)的“片段數(shù)據(jù)包”中傳輸，如圖所示：
原始數(shù)據(jù)包：
分段數(shù)據(jù)包：
第一個分段包由以下部分組成：
(1) 原始報文的 Per-Fragment 頭，原始 IPv6 報文頭的 Payload Length 更改為僅包含該分段報文的長度（不包括 IPv6 報文頭本身的長度），以及該報文的 Next Header 字段Per-Fragment 報文頭的最后一個報文頭更改為 44。
(2) 一個片段頭，包含：
Next Header 值，用于標(biāo)識原始數(shù)據(jù)包的 Per-Fragment 報文頭之后的第一個報文頭。
包含片段偏移量的片段偏移量，以 8 個八位字節(jié)為單位，相對于原始數(shù)據(jù)包的可分段部分的開頭。第一個（“最左邊”）片段的片段偏移量為 0。
M 標(biāo)志值為 1，因為這是第一個片段。
標(biāo)識值由原始數(shù)據(jù)包生成。
(3) 擴(kuò)展報文頭，如果有的話，和上層報文頭。這些報文頭必須在第一個片段中。注意：這將通過上層報文頭的報文頭大小限制為到數(shù)據(jù)包目的的路徑的 MTU。
(4) 第一個片段。
隨后的分段數(shù)據(jù)包由以下部分組成：
(1) 原始報文的 Per-Fragment 頭，原始 IPv6 報文頭的 Payload Length 更改為僅包含該分段報文的長度（不包括 IPv6 報文頭本身的長度），以及該報文的 Next Header 字段Per-Fragment 報文頭的最后一個報文頭更改為 44。
(2) 一個片段頭，包含：
Next Header 值，用于標(biāo)識原始數(shù)據(jù)包的 Per-Fragment 報文頭之后的第一個報文頭。
包含片段偏移量的片段偏移量，以 8 個八位字節(jié)為單位，相對于原始數(shù)據(jù)包的可分段部分的開頭。
如果片段是最后一個（“最右邊”），則 M 標(biāo)志值為 0，否則 M 標(biāo)志值為 1。
標(biāo)識值由原始數(shù)據(jù)包生成。
(3) 片段本身。
不得創(chuàng)建與從原始數(shù)據(jù)包創(chuàng)建的任何其他片段重疊的片段。
在目的，分段數(shù)據(jù)包被重新組合成其原始的、未分段的形式，如圖所示：
重新組裝的原始數(shù)據(jù)包：
以下規(guī)則管理重組：
原始數(shù)據(jù)包僅由具有相同源地址、目標(biāo)地址和片段標(biāo)識的片段數(shù)據(jù)包重組而成。
重組后的數(shù)據(jù)包的 Per-Fragment 報文頭由所有報文頭組成，但不包括第一個片段數(shù)據(jù)包（即 Fragment Offset 為零的數(shù)據(jù)包）的 Fragment 報文頭，有以下兩個變化：
Per-Fragment 頭的最后一個頭的 Next Header 字段是從第一個片段的 Fragment 頭的 Next Header 字段中獲取的。
重組數(shù)據(jù)包的有效載荷長度是根據(jù) Per-Fragment 頭的長度和最后一個片段的長度和偏移量計算的。例如，計算重組原始數(shù)據(jù)包的有效載荷長度的公式為：
PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last
公式中：
PL.orig = 重組數(shù)據(jù)包的有效載荷長度字段。
PL.first = 第一個片段數(shù)據(jù)包的有效載荷長度字段。
FL.first = 第一個片段數(shù)據(jù)包的片段頭之后的片段長度。
FO.last = 最后一個分段包的分段頭的分段偏移字段。
FL.last = 最后一個片段包的片段頭之后的片段長度。
重組包的可分段部分由每個分段包中的分段頭后面的分段構(gòu)成。每個片段的長度是通過從數(shù)據(jù)包的 Payload Length 中減去 IPv6 報文頭和片段本身之間的報文頭長度來計算的；它在 Fragmentable Part 中的相對位置是根據(jù)它的 Fragment Offset 值計算的。
Fragment 報文頭不存在于最終重組的數(shù)據(jù)包中。
如果分段是一個完整的數(shù)據(jù)報（即，F(xiàn)ragment Offset 字段和 M 標(biāo)志都為零），那么它不需要任何進(jìn)一步的重組，應(yīng)該作為一個完全重組的數(shù)據(jù)包來處理（即更新 Next Header，調(diào)整 Payload長度、刪除 Fragment 報文頭等）。與此數(shù)據(jù)包匹配的任何其他片段（即，相同的 IPv6 源地址、IPv6 目標(biāo)地址和片段標(biāo)識）應(yīng)獨(dú)立處理。
重組分段數(shù)據(jù)包時可能會出現(xiàn)以下錯誤情況：
** 如果在接收到該數(shù)據(jù)包的第一個到達(dá)片段后 60 秒內(nèi)收到的片段不足以完成數(shù)據(jù)包的重組，則必須放棄該數(shù)據(jù)包的重組，并且必須丟棄該數(shù)據(jù)包已接收的所有片段.如果接收到第一個片段（即片段偏移為零的片段），則應(yīng)向該片段的源發(fā)送 ICMP Time Exceeded -- Fragment Reassembly Time Exceeded 消息。
** 如果從片段數(shù)據(jù)包的 Payload Length 字段導(dǎo)出的片段長度不是 8 個八位字節(jié)的倍數(shù)，并且該片段的 M 標(biāo)志為 1，則必須丟棄該片段，并且 ICMP 參數(shù)問題，代碼 0 , 消息應(yīng)該發(fā)送到分段的源，指向分段數(shù)據(jù)包的 Payload Length 字段。
** 如果片段的長度和偏移量使得從該片段重組的數(shù)據(jù)包的有效載荷長度將超過 65,535 個八位字節(jié)，則必須丟棄該片段，并且應(yīng)將 ICMP 參數(shù)問題，代碼 0，消息發(fā)送到源分段的，指向分段包的Fragment Offset字段。
** 如果第一個片段不包括通過上層報文頭的所有報文頭，則應(yīng)丟棄該片段，并將 ICMP 參數(shù)問題，代碼 3，消息發(fā)送到片段的源，并將指針字段設(shè)置為零。
** 如果正在重組的任何片段與為同一數(shù)據(jù)包重組的任何其他片段重疊，則必須放棄該數(shù)據(jù)包的重組，并且必須丟棄該數(shù)據(jù)包已收到的所有片段，并且不應(yīng)有 ICMP 錯誤消息發(fā)送。
需要注意的是，片段在網(wǎng)絡(luò)中可能會被復(fù)制。代替將這些完全重復(fù)的片段視為重疊片段，實(shí)現(xiàn)可以選擇檢測這種情況并丟棄完全重復(fù)的片段，同時保留屬于同一數(shù)據(jù)包的其他片段。
以下情況預(yù)計不會頻繁發(fā)生，但如果發(fā)生，則不會被視為錯誤：
同一個原始數(shù)據(jù)包的不同分段的Fragment 頭之前的頭的數(shù)量和內(nèi)容可能不同。在每個片段包中的片段包頭之前，無論出現(xiàn)什么包頭，都會在包到達(dá)時進(jìn)行處理，然后再將片段排隊以進(jìn)行重組。只有 Offset zero fragment 數(shù)據(jù)包中的那些頭被保留在重新組裝的數(shù)據(jù)包中。
同一原始報文的不同分段的分段頭中的下一個頭值可能不同。只有來自 Offset zero fragment 數(shù)據(jù)包的值用于重組。
IPv6 報文頭中的其他字段也可能因重新組裝的片段而異。如果使用來自偏移零片段的值的基本機(jī)制不夠充分，則使用這些字段的規(guī)范可能會提供附加說明。例如，[RFC3168] 的第 5.3 節(jié)描述了如何組合來自不同片段的顯式擁塞通知 (Explicit Congestion Notification，ECN) 位以導(dǎo)出重組數(shù)據(jù)包的 ECN 位。
Destination Options 報文頭用于攜帶僅需要由數(shù)據(jù)包的目標(biāo)節(jié)點(diǎn)檢查的可選信息。Destination Options 報文頭由緊接在前一個報文頭中的 Next Header 值 60 標(biāo)識，并具有以下格式：
下一個報文頭：8 位選擇器。標(biāo)識緊跟在 Destination Options 報文頭之后的報文頭類型。使用與 IPv4 協(xié)議字段 [IANA-PN] 相同的值。
HDR Ext Len：8 位無符號整數(shù)。Destination Options 報文頭的長度，以 8 個八位字節(jié)為單位，不包括前 8 個八位字節(jié)。
選項：可變長度字段，其長度使得完整的目標(biāo)選項報文頭是 8 個八位字節(jié)長的整數(shù)倍。包含一個或多個 TLV 編碼選項，如第 4.2 節(jié)所述。
本文檔中定義的唯一目標(biāo)選項是第 4.2 節(jié)中指定的 Pad1 和 PadN 選項。
請注意，有兩種可能的方式在 IPv6 數(shù)據(jù)包中對可選目標(biāo)信息進(jìn)行編碼：作為目標(biāo)選項報文頭中的選項或作為單獨(dú)的擴(kuò)展報文頭。Fragment 報文頭和 Authentication 報文頭是后一種方法的示例。可以使用哪種方法取決于不理解可選信息的目標(biāo)節(jié)點(diǎn)需要什么操作：
** 如果目標(biāo)節(jié)點(diǎn)想要丟棄數(shù)據(jù)包，并且僅當(dāng)數(shù)據(jù)包的目標(biāo)地址不是多播地址時，才向數(shù)據(jù)包的源地址發(fā)送 ICMP Unrecognized Type 消息，則該信息可以編碼為單獨(dú)的報文頭或作為 Destination Options 報文頭中的一個選項，其 Option Type 的最高 2 位值為 11。選擇可能取決于以下因素：哪個占用更少的八位字節(jié)，或者哪個產(chǎn)生更好的對齊或更有效的解析。
** 如果需要任何其他操作，則必須將信息編碼為 Destination Options 報文頭中的選項，其選項類型的最高 2 位值為 00、01 或 10，指定所需的操作（參見第 4.2 節(jié)） ）。
IPv6 報文頭或任何擴(kuò)展報文頭的 Next Header 字段中的值 59 表示該報文頭后面沒有任何內(nèi)容。如果 IPv6 報文頭的 Payload Length 字段指示在其 Next Header 字段包含 59 的報文頭末尾之后存在八位字節(jié)，則如果轉(zhuǎn)發(fā)數(shù)據(jù)包，則必須忽略這些八位字節(jié)并保持不變地傳遞。
不建議定義新的 IPv6 擴(kuò)展報文頭，除非沒有現(xiàn)有的 IPv6 擴(kuò)展報文頭可通過為該 IPv6 擴(kuò)展報文頭指定新選項來使用。指定新 IPv6 擴(kuò)展頭的提案必須包括詳細(xì)的技術(shù)解釋，說明為什么現(xiàn)有 IPv6 擴(kuò)展頭不能用于所需的新功能。有關(guān)其他背景信息，請參閱 [RFC6564]。
注意：不能定義需要逐跳行為的新擴(kuò)展報文頭，因為如本文檔第 4 節(jié)中所指定，具有逐跳行為的唯一擴(kuò)展報文頭是逐跳選項報文頭。
不推薦使用新的逐跳選項，因為節(jié)點(diǎn)可能被配置為忽略逐跳選項報文頭，丟棄包含逐跳選項報文頭的數(shù)據(jù)包，或分配包含逐跳選項報文頭的數(shù)據(jù)包到緩慢的處理路徑。考慮定義新的逐跳選項的設(shè)計人員需要了解這種可能的行為。為什么在標(biāo)準(zhǔn)化之前需要任何新的逐跳選項，必須有一個非常明確的理由。
建議使用 Destination Options 頭代替定義新的擴(kuò)展頭來攜帶只能由數(shù)據(jù)包的目的節(jié)點(diǎn)檢查的可選信息，因為它們提供更好的處理和向后兼容性。
如果定義了新的擴(kuò)展頭，它們需要使用以下格式：
下一個報文頭：8 位選擇器。標(biāo)識緊跟在擴(kuò)展報文頭之后的報文頭類型。使用與 IPv4 協(xié)議字段 [IANA-PN] 相同的值。
HDR Ext Len：8 位無符號整數(shù)。Destination Options 報文頭的長度，以 8 個八位字節(jié)為單位，不包括前 8 個八位字節(jié)。
報文頭特定數(shù)據(jù)：可變長度字段。特定于擴(kuò)展報文頭的字段。
IPv6 要求 Internet 中的每個鏈接的 MTU 為 1280 八位字節(jié)或更大。這稱為 IPv6 最小鏈路 MTU。在任何不能一次性傳送 1280 個八位字節(jié)數(shù)據(jù)包的鏈路上，必須在 IPv6 之下的一層提供特定于鏈路的分段和重組。
具有可配置 MTU 的鏈路（例如，PPP 鏈路 [RFC1661]）必須配置為具有至少 1280 個八位字節(jié)的 MTU；建議將它們配置為 1500 個八位字節(jié)或更大的 MTU，以適應(yīng)可能的封裝（即隧道）而不會導(dǎo)致 IPv6 層分段。
從節(jié)點(diǎn)直接連接到的每條鏈路，該節(jié)點(diǎn)必須能夠接受與該鏈路的 MTU 一樣大的數(shù)據(jù)包。
強(qiáng)烈建議 IPv6 節(jié)點(diǎn)實(shí)現(xiàn)路徑 MTU 發(fā)現(xiàn) [RFC8201]，以便發(fā)現(xiàn)和利用大于 1280 八位字節(jié)的路徑 MTU。然而，最小的 IPv6 實(shí)現(xiàn)（例如，在引導(dǎo) ROM 中）可能會簡單地將自身限制為發(fā)送不超過 1280 個八位字節(jié)的數(shù)據(jù)包，并省略路徑 MTU 發(fā)現(xiàn)的實(shí)現(xiàn)。
為了發(fā)送大于路徑 MTU 的數(shù)據(jù)包，節(jié)點(diǎn)可以使用 IPv6 Fragment 報文頭在源處對數(shù)據(jù)包進(jìn)行分段，并在目的重新組裝。但是，在任何能夠調(diào)整其數(shù)據(jù)包以適應(yīng)測量的路徑 MTU（即低至 1280 個八位字節(jié)）的應(yīng)用程序中，不鼓勵使用此類分段。
一個節(jié)點(diǎn)必須能夠接受一個分段的數(shù)據(jù)包，在重組后，該數(shù)據(jù)包大到 1500 個八位字節(jié)。一個節(jié)點(diǎn)被允許接受重組為超過 1500 個八位字節(jié)的分段數(shù)據(jù)包。依賴 IPv6 分段發(fā)送大于路徑 MTU 的數(shù)據(jù)包的上層協(xié)議或應(yīng)用程序不應(yīng)發(fā)送大于 1500 個八位字節(jié)的數(shù)據(jù)包，除非它保證目的能夠重新組裝更大尺寸的數(shù)據(jù)包。
源使用 IPv6 報文頭中的 20 位流標(biāo)簽字段來標(biāo)記要在網(wǎng)絡(luò)中作為單個流處理的數(shù)據(jù)包序列。
IPv6 流標(biāo)簽的當(dāng)前定義可以在 [RFC6437] 中找到。
IPv6 報文頭中的 8 位流量類別字段被網(wǎng)絡(luò)用于流量管理。接收到的數(shù)據(jù)包或片段中的流量類別位的值可能與數(shù)據(jù)包源發(fā)送的值不同。
[RFC2474] 和 [RFC3168] 中規(guī)定了當(dāng)前使用的流量類別字段用于區(qū)分服務(wù)和顯式擁塞通知。
任何在其校驗和計算中包含來自 IP 報文頭的地址的傳輸或其他上層協(xié)議都必須修改以在 IPv6 上使用，以包含 128 位 IPv6 地址而不是 32 位 IPv4 地址。特別是，下圖顯示了 IPv6 的 TCP 和 UDP“偽報文頭”：
** 如果 IPv6 數(shù)據(jù)包包含路由報文頭，則偽報文頭中使用的目標(biāo)地址是最終目的的目標(biāo)地址。在始發(fā)節(jié)點(diǎn)，該地址將位于路由報文頭的最后一個元素中；在接收方，該地址將位于 IPv6 報文頭的目標(biāo)地址字段中。
** 偽報文頭中的下一個報文頭值標(biāo)識
上層協(xié)議（例如，TCP 為 6，UDP 為 17）。如果 IPv6 頭和上層頭之間存在擴(kuò)展頭，它將與 IPv6 頭中的 Next Header 值不同。
** 偽頭中的 Upper-Layer Packet Length 是上層頭和數(shù)據(jù)（例如 TCP 頭加 TCP 數(shù)據(jù)）的長度。一些上層協(xié)議攜帶自己的長度信息（例如UDP頭中的長度字段）；對于此類協(xié)議，這是偽報文頭中使用的長度。其他協(xié)議（如 TCP）不攜帶自己的長度信息，在這種情況下，偽頭中使用的長度是來自 IPv6 頭的有效載荷長度減去 IPv6 頭和上層之間存在的任何擴(kuò)展頭的長度-層報文頭。
** 與 IPv4 不同，當(dāng) UDP 數(shù)據(jù)包由 IPv6 節(jié)點(diǎn)發(fā)起時，默認(rèn)行為是 UDP 校驗和不是可選的。也就是說，無論何時發(fā)起 UDP 數(shù)據(jù)包，IPv6 節(jié)點(diǎn)都必須對數(shù)據(jù)包和偽報文頭計算 UDP 校驗和，如果計算結(jié)果為零，則必須將其更改為十六進(jìn)制 FFFF 以放置在 UDP 報文頭中. IPv6 接收器必須丟棄包含零校驗和的 UDP 數(shù)據(jù)包，并應(yīng)記錄錯誤。
** 作為默認(rèn)行為的一個例外，使用 UDP 作為隧道封裝的協(xié)議可能會為發(fā)送和/或接收的特定端口（或端口集）啟用零校驗和模式。任何實(shí)現(xiàn)零校驗和模式的節(jié)點(diǎn)都必須遵循“使用具有零校驗和的 IPv6 UDP 數(shù)據(jù)報的適用性聲明”[RFC6936] 中指定的要求。
ICMP [RFC4443] 的 IPv6 版本在其校驗和計算中包含上述偽頭；這是對 ICMP 的 IPv4 版本的更改，它的校驗和中不包含偽報文頭。更改的原因是為了保護(hù) ICMP 免受其所依賴的 IPv6 報文頭的那些字段的錯誤傳遞或損壞，與 IPv4 不同，這些字段未包含在 Internet 層校驗和中。ICMP 偽頭中的 Next Header 字段包含值 58，它標(biāo)識 ICMP 的 IPv6 版本。
與 IPv4 不同，IPv6 節(jié)點(diǎn)不需要強(qiáng)制執(zhí)行最大數(shù)據(jù)包生命周期。這就是 IPv4 的“生存時間”字段在 IPv6 中更名為“跳數(shù)限制”的原因。實(shí)際上，很少有（如果有的話）IPv4 實(shí)現(xiàn)符合限制數(shù)據(jù)包生命周期的要求，因此這在實(shí)踐中并沒有改變。任何依賴互聯(lián)網(wǎng)層（無論是 IPv4 還是 IPv6）來限制數(shù)據(jù)包生命周期的上層協(xié)議都應(yīng)該升級以提供自己的機(jī)制來檢測和丟棄過時的數(shù)據(jù)包。
在計算可用于上層數(shù)據(jù)的最大有效載荷大小時，上層協(xié)議必須考慮 IPv6 報文頭相對于 IPv4 報文頭的更大尺寸。例如，在 IPv4 中，TCP 的最大分段大小 (MSS) 選項計算為最大數(shù)據(jù)包大小（默認(rèn)值或通過路徑 MTU 發(fā)現(xiàn)學(xué)習(xí)的值）減去 40 個八位字節(jié)（20 個八位字節(jié)用于最小長度的 IPv4 報文頭和 20 個八位字節(jié)）對于最小長度的 TCP 報文頭）。在 IPv6 上使用 TCP 時，MSS 必須計算為最大數(shù)據(jù)包大小減去 60 個八位字節(jié)，因為最小長度的 IPv6 報文頭（即沒有擴(kuò)展報文頭的 IPv6 報文頭）比最小長度的 IPv4 報文頭長 20 個八位字節(jié)。
當(dāng)上層協(xié)議發(fā)送一個或多個數(shù)據(jù)包以響應(yīng)包含路由報文頭的接收數(shù)據(jù)包時，響應(yīng)數(shù)據(jù)包不得包含通過“反轉(zhuǎn)”接收到的路由報文頭而自動導(dǎo)出的路由報文頭，除非完整性已驗證接收的源地址和路由報文頭的真實(shí)性（例如，通過在接收的數(shù)據(jù)包中使用身份驗證報文頭）。換句話說，僅允許以下類型的數(shù)據(jù)包響應(yīng)接收到的帶有路由頭的數(shù)據(jù)包：
** 不攜帶路由頭的響應(yīng)數(shù)據(jù)包。
** 帶有路由報文頭的響應(yīng)數(shù)據(jù)包，不是通過反轉(zhuǎn)接收到的數(shù)據(jù)包的路由報文頭（例如，由本地配置提供的路由報文頭）導(dǎo)出的。
** 帶有路由頭的響應(yīng)包是通過反轉(zhuǎn)接收到的包的路由頭導(dǎo)出的，當(dāng)且僅當(dāng)來自接收包的源地址和路由頭的完整性和真實(shí)性已經(jīng)被響應(yīng)者驗證。
許多 IANA 注冊機(jī)構(gòu)都引用了 RFC 2460。這些包括：
** Internet 協(xié)議版本 6 (IPv6) 參數(shù) [IANA-6P]
** 分配的互聯(lián)網(wǎng)協(xié)議編號 [IANA-PN]
** ONC RPC 網(wǎng)絡(luò)標(biāo)識符 (netids) [IANA-NI]
** 網(wǎng)絡(luò)層協(xié)議標(biāo)識符 (NLPID) [IANA-NL]
** 協(xié)議注冊機(jī)構(gòu) [IANA-PR]
IANA 已更新這些引用以指向本文檔。
從數(shù)據(jù)包的基本格式和傳輸?shù)慕嵌葋砜矗琁Pv6 具有類似于 IPv4 的安全特性。這些安全問題包括：
** 竊聽，其中路徑上的元素可以觀察每個 IPv6 數(shù)據(jù)報的整個數(shù)據(jù)包（包括內(nèi)容和元數(shù)據(jù)）。
** 重放，攻擊者從線路上記錄一系列數(shù)據(jù)包，并將它們回放給最初接收它們的一方。
** 數(shù)據(jù)包插入，攻擊者偽造具有某些選定屬性集的數(shù)據(jù)包并將其注入網(wǎng)絡(luò)。
** 數(shù)據(jù)包刪除，攻擊者從網(wǎng)絡(luò)中刪除數(shù)據(jù)包。
** 數(shù)據(jù)包修改，攻擊者從線路中移除數(shù)據(jù)包，對其進(jìn)行修改，然后將其重新注入網(wǎng)絡(luò)。
** 中間人 (Man-in-the-middle，MITM) 攻擊，攻擊者破壞通信流，以偽裝成發(fā)送者到接收者和接收者到發(fā)送者。
** 拒絕服務(wù) (Denial-of-service，DoS) 攻擊，攻擊者向目標(biāo)發(fā)送大量合法流量以壓制它。
通過使用“Internet 協(xié)議安全架構(gòu)”[RFC4301]，可以保護(hù) IPv6 數(shù)據(jù)包免受竊聽、重放、數(shù)據(jù)包插入、數(shù)據(jù)包修改和 MITM 攻擊。此外，還可以使用傳輸層安全 (TLS) 或安全外殼 (SSH) 等上層協(xié)議來保護(hù)運(yùn)行在 IPv6 之上的應(yīng)用層流量。
沒有任何機(jī)制可以防止 DoS 攻擊。防御這些類型的攻擊超出了本規(guī)范的范圍。
IPv6 地址明顯大于 IPv4 地址，這使得在 Internet 上甚至在單個網(wǎng)絡(luò)鏈接（例如局域網(wǎng)）上掃描地址空間變得更加困難。有關(guān)更多信息，請參閱 [RFC7707]。
由于減少了地址轉(zhuǎn)換技術(shù)的使用，因此與 IPv4 相比，節(jié)點(diǎn)的 IPv6 地址有望在 Internet 上更加明顯。這會產(chǎn)生一些額外的隱私問題，例如更容易區(qū)分端點(diǎn)。有關(guān)更多信息，請參閱 [RFC7721]。
IPv6 擴(kuò)展頭架構(gòu)的設(shè)計，在增加了很多靈活性的同時，也帶來了新的安全挑戰(zhàn)。如下所述，與 Fragment 擴(kuò)展報文頭相關(guān)的問題已得到解決，但很明顯，對于未來設(shè)計的任何新擴(kuò)展報文頭，都需要徹底檢查安全隱患，這需要包括新擴(kuò)展報文頭如何與現(xiàn)有的擴(kuò)展頭。有關(guān)更多信息，請參閱 [RFC7045]。
此版本的 IPv6 規(guī)范解決了在 IPv6 規(guī)范的先前版本 [RFC2460] 中發(fā)現(xiàn)的許多安全問題。這些包括：
** 修改了文本以處理整個數(shù)據(jù)報的片段的情況（即片段偏移字段和 M 標(biāo)志都為零）。如果收到，則應(yīng)將它們作為重新組裝的數(shù)據(jù)包進(jìn)行處理。任何其他匹配的片段都應(yīng)該獨(dú)立處理。片段創(chuàng)建過程被修改為不創(chuàng)建整個數(shù)據(jù)報片段（片段偏移字段和 M 標(biāo)志為零）。有關(guān)更多信息，請參閱 [RFC6946] 和 [RFC8021]。
** 刪除了第 5 節(jié)中要求在報告下一跳 MTU 的 ICMP 數(shù)據(jù)包太大消息小于 1280 時在傳出數(shù)據(jù)包中包含 Fragment 報文頭的段落。有關(guān)更多信息，請參閱 [RFC6946]。
** 更改文本以要求 IPv6 節(jié)點(diǎn)不得創(chuàng)建重疊片段。此外，在重組 IPv6 數(shù)據(jù)報時，如果確定其組成片段中的一個或多個是重疊片段，則必須靜默丟棄整個數(shù)據(jù)報（以及任何組成片段）。包括在收到重疊片段時不應(yīng)發(fā)送 ICMP 錯誤消息的說明。有關(guān)更多信息，請參閱 [RFC5722]。
** 修改了正文，要求通過第一個上層報文頭的所有報文頭都在第一個片段中。有關(guān)更多信息，請參閱 [RFC7112]。
** 合并了 [RFC5095] 和 [RFC5871] 的更新，刪除了路由頭類型 0 (RH0) 的描述，路由頭的分配指南在 RFC 5871 中指定，并從所需的擴(kuò)展頭列表中刪除了 RH0 。
與 IPv6 其他部分相關(guān)的安全問題，包括尋址、ICMPv6、路徑 MTU 發(fā)現(xiàn)等，在適當(dāng)?shù)囊?guī)范中進(jìn)行了討論。
[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,
[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,
本附錄就如何在設(shè)計要在 Hop-by-Hop Options 報文頭或 Destination Options 報文頭中使用的新選項時如何布置字段提供一些建議，如第 4.2 節(jié)所述。這些準(zhǔn)則基于以下假設(shè)：
** 一個理想的特性是選項的選項數(shù)據(jù)區(qū)域內(nèi)的任何多八位字節(jié)字段都在它們的自然邊界上對齊，即寬度為 n 個八位字節(jié)的字段應(yīng)放置在從躍點(diǎn)開始的 n 個八位字節(jié)的整數(shù)倍處-by-Hop 或 Destination Options 報文頭，對于 n = 1、2、4 或 8。
** 另一個可取的特性是 Hop-by-Hop 或 Destination Options 報文頭占用盡可能少的空間，前提是報文頭是 8 個八位字節(jié)長的整數(shù)倍。
** 可以假設(shè)，當(dāng)任一帶有選項的報文頭存在時，它們攜帶的選項數(shù)量非常少，通常只有一個。
這些假設(shè)建議使用以下方法來布置選項的字段：將字段從最小到最大排序，沒有內(nèi)部填充，然后根據(jù)最大字段的對齊要求（最多8 個八位字節(jié)的最大對齊）。以下示例說明了此方法：
如果選項 X 需要兩個數(shù)據(jù)字段，其中一個長度為 8 個八位字節(jié)，一個長度為 4 個八位字節(jié)，則其布局如下：
它的對齊要求是 8n+2，以確保 8 個八位字節(jié)字段從封閉報文頭開始處的 8 倍偏移處開始。包含此選項的完整 Hop-by-Hop 或 Destination Options 報文頭如下所示：
如果選項 Y 需要三個數(shù)據(jù)字段，其中一個長度為 4 個八位字節(jié)，一個長度為 2 個八位字節(jié)，一個長度為 1 個八位字節(jié)，則其布局如下：
它的對齊要求是 4n+3，以確保 4 個八位字節(jié)字段從封閉報文頭的開始位置以 4 的倍數(shù)偏移開始。包含此選項的完整 Hop-by-Hop 或 Destination Options 報文頭如下所示：
包含示例 1 和示例 2 中的選項 X 和 Y 的逐跳或目標(biāo)選項報文頭將具有以下兩種格式之一，具體取決于哪個選項首先出現(xiàn)：
本備忘錄對 RFC 2460 有以下更改。
** 從摘要中刪除了下一代 IP。
** 在第 1 節(jié)中添加了數(shù)據(jù)傳輸順序與 RFC 791 中定義的 IPv4 相同的文本。
** 澄清了第 3 節(jié)中關(guān)于遞減跳躍限制的文本。
** 闡明擴(kuò)展報文頭（Hop-by-Hop Options 報文頭除外）不會被沿數(shù)據(jù)包傳送路徑的任何節(jié)點(diǎn)處理、插入或刪除。
** 將 Hop-by-Hop Options 報文頭的要求更改為“可以”，并添加了一條注釋以指示關(guān)于 Hop-by-Hop Options 報文頭的預(yù)期內(nèi)容。
** 在第 4 節(jié)中添加了一段以闡明擴(kuò)展報文頭如何編號以及哪些是上層報文頭。
** 在第 4 節(jié)末尾添加了對“IPv6 擴(kuò)展報文頭類型”IANA 注冊表的引用。
** 合并了來自 RFC 5095 和 5871 的更新，以刪除 RH0 的描述，路由報文頭的分配指南在 RFC 5871 中指定，并從所需的擴(kuò)展報文頭列表中刪除了 RH0。
** 根據(jù) RFC 5722、6946、7112 和 8021 的更新修訂了關(guān)于 IPv6 分段的第 4.5 節(jié)。這包括：
- 修改了文本以處理整個數(shù)據(jù)報的片段的情況（即片段偏移字段和 M 標(biāo)志都為零）。如果收到，則應(yīng)將它們作為重新組裝的數(shù)據(jù)包進(jìn)行處理。任何其他匹配的片段都應(yīng)該獨(dú)立處理。修改后的片段創(chuàng)建過程被修改為不創(chuàng)建整個數(shù)據(jù)報片段（片段偏移字段和 M 標(biāo)志為零）。
- 更改文本以要求 IPv6 節(jié)點(diǎn)不得創(chuàng)建重疊片段。此外，在重組 IPv6 數(shù)據(jù)報時，如果確定其組成片段的一個或多個是重疊片段，則必須靜默丟棄整個數(shù)據(jù)報（以及任何組成片段）。包括在收到重疊片段時不應(yīng)發(fā)送 ICMP 錯誤消息的說明。
- 修改了文本，要求通過第一個 Upper-Layer 報文頭的所有報文頭都在第一個片段中。這更改了描述數(shù)據(jù)包如何分段和重組的文本，并添加了一個新的錯誤案例。
- 在處理完全重復(fù)的片段的片段報文頭過程中添加了文本。
- 更新了 Fragmentation 報文頭文本以更正身份驗證報文頭 (AH) 的包含并注明無下一個報文頭情況。
- 將 Fragment 報文報文頭分中的術(shù)語從“Unfragmentable Headers”更改為“Per-Fragment headers”。
- 刪除了第 5 節(jié)中的段落，如果 ICMP 數(shù)據(jù)包太大消息報告下一跳 MTU 小于 1280，則要求在傳出數(shù)據(jù)包中包含片段報文頭。
- 更改文本以闡明 MTU 限制和 8 字節(jié)限制，并在第一個片段中注明對報文頭的限制。
** 在第 4.5 節(jié)中，添加了說明，指出 IPv6 報文頭中的某些字段也可能因重新組裝的片段而異，并且其他規(guī)范可能會提供有關(guān)如何重新組裝它們的附加說明。例如，參見 [RFC3168] 的第 5.3 節(jié)。
** 合并了來自 RFC 6564 的更新以添加新的第 4.8 節(jié)，該節(jié)描述了定義新擴(kuò)展報文頭和選項的建議。
** 向第 5 節(jié)添加文本以定義“IPv6 最小鏈路 MTU”。
** 簡化了第 6 節(jié)中關(guān)于流標(biāo)簽的文本并刪除了附錄 A（“流標(biāo)簽字段的語義和用法”）；相反，指向 [RFC6437] 中的 IPv6 流標(biāo)簽字段和 [RFC2474] 和 [RFC3168] 中的流量類別字段的當(dāng)前規(guī)范。
** 在第 8 節(jié)中合并了 RFC 6935（“隧道數(shù)據(jù)包的 IPv6 和 UDP 校驗和”）所做的更新。為處理具有隧道零校驗和的 UDP 數(shù)據(jù)包的默認(rèn)行為添加了一個例外。
** 在第 9 節(jié)“IANA 注意事項”中添加了說明，以將 RFC 2460 的引用更改為本文檔。
** 修訂并擴(kuò)展了第 10 節(jié)“安全注意事項”。
** 在致謝部分添加了一個段落，感謝更新文檔的作者。
** 更新了對當(dāng)前版本的引用，并分配了對規(guī)范性和信息性的引用。
** 進(jìn)行了更改以解決 RFC 2460 上的勘誤表。這些是：
勘誤 ID 2541 [Err2541]：此勘誤指出，當(dāng)流標(biāo)簽的長度從 RFC 1883 中的 24 位更改為 20 位時，RFC 2460 未更新 RFC 2205。此問題已在定義流標(biāo)簽的 RFC 6437 中解決.此規(guī)范現(xiàn)在引用 RFC 6437。無需更改。
勘誤 ID 4279 [Err4279]：此勘誤指出規(guī)范不處理轉(zhuǎn)發(fā)節(jié)點(diǎn)接收具有零跳數(shù)限制的數(shù)據(jù)包的情況。這在本規(guī)范的第 3 節(jié)中得到了修復(fù)。
勘誤 ID 4657 [Err4657]：此勘誤建議文本，擴(kuò)展報文頭絕不能由除數(shù)據(jù)包源之外的任何節(jié)點(diǎn)插入。這已在第 4 節(jié)“IPv6 擴(kuò)展報文頭”中解決。
勘誤表 ID 4662 [Err4662]：該勘誤表建議的文本是，除了一個例外，擴(kuò)展報文頭不會被沿數(shù)據(jù)包傳遞路徑的任何節(jié)點(diǎn)檢查、處理、修改、插入或刪除。這已在第 4 節(jié)“IPv6 擴(kuò)展報文頭”中解決。
勘誤 ID 2843：此勘誤標(biāo)記為“已拒絕”。沒有進(jìn)行任何更改。
