IPv4和IPv6頭部

IP是TCP/IP協議族中的核心協議。所有TCP、UDP、ICMP和IGMP 數據都通過IP數據報傳輸。IP提供了一種盡力而為、無連接的數據報交付服務。

IP頭部字段

IPv4 頭部通常為 20 字節（無選項時），而 IPv6 頭部固定為 40 字節。IPv6 不支持傳統的頭部“選項”，但支持擴展頭部。

所有二進制整數在網絡中采用 高位優先（網絡字節序），即先傳輸高位字節。

字段	IPv4 中的表現	IPv6 中的表現
版本	4	6
頭部長度	可變，最小20字節，最大60字節	固定40字節
服務類型	DS/ECN	DS/ECN
總長度	包含頭部與數據長度	Payload Length（不含頭部）
標識與分片	支持分片	通過擴展頭部處理
TTL	每跳遞減	同功能，字段名為 Hop Limit
協議/下一個頭部	Protocol 字段	Next Header 字段
校驗和	頭部校驗和	無
源/目的地址	32 位	128 位

版本字段（Version）

• 占 4 位。
• 指示 IP 數據報的協議版本。
  • IPv4 的值為 4
  • IPv6 的值為 6
• IPv4 與 IPv6 除了這個字段位置相同外，其它頭部結構完全不同，不能直接互通。
• 同時支持 IPv4 與 IPv6 的主機稱為“雙棧主機”。

Internet 頭部長度（IHL）

• 占 4 位。
• 表示 IPv4 頭部長度，以 32 位字為單位。
• 最小值為 5（即 20 字節），最大值為 15（即 60 字節）。
• IPv4 可通過選項擴展頭部長度；IPv6 頭部固定為 40 字節，擴展使用擴展頭部完成。

服務類型字段（ToS）/ 通信類型字段（Traffic Class）

• 原為服務類型字段（ToS），后由多份 RFC（如 RFC 2474, RFC 3168, RFC 3260）重新定義。
• 現在該 8 位字段分為：
  • 前6位：DS 字段（Differentiated Services Field）
  • 后2位：ECN 字段（Explicit Congestion Notification）
• 支持服務質量 (QoS) 和網絡擁塞控制。
• 該字段在 IPv4 和 IPv6 中都存在，作用一致。

總長度字段（Total Length）

• 占 16 位。
• 指定整個 IPv4 數據報的長度（頭部 + 數據），單位為字節。
• 最大值為 65535 字節。
• IPv6 采用 Payload Length 字段表示負載長度，不包括頭部長度。

有些鏈路層協議（如以太網）不提供精確的負載大小信息，因此 IP 必須顯式提供總長度。實際中很少發送超過 MTU 的 IP 報文，若超過，需要分片。

標識字段（Identification）

• 占 16 位。
• 主要用于分片場景。
• 每個由主機發出的數據報通常會自增標識號，以便分片后可正確重組。

標志（Flags）與分片偏移量（Fragment Offset）

• 三位標志位，用于控制分片行為。
• 13 位分片偏移量，指示該分片在原始數據報中的位置。

生存時間字段（TTL）

• 占 8 位。
• 表示該數據報最多可經過多少個路由器。
• 每經過一個路由器，TTL 減 1，減至 0 時數據報將被丟棄。
• 防止數據報在網絡中無限循環。

協議字段（Protocol）

• 占 8 位。
• 指示封裝在 IP 數據報內的協議類型。
• 常見值：
  • 6：TCP
  • 17：UDP
  • 1：ICMP
  • 4：IPv4-in-IPv4 封裝
• IPv6 中該字段對應為“下一頭部字段（Next Header）”。

頭部校驗和（Header Checksum）

• 占 16 位。
• 僅覆蓋 IPv4 頭部本身，不包括數據部分。
• 每次 TTL 變化或頭部變更都需重新計算。
• IPv6 移除了該字段，理由：
  • 上層協議都有自己的校驗機制（如 TCP/UDP 校驗和）
  • 減少中間節點處理負擔，提高效率
  • 實際錯誤率已因物理層質量提高而大大降低

源 IP 地址 與 目的 IP 地址

• IPv4 地址為 32 位，IPv6 為 128 位。
• 通常標識一個網絡接口（主機的網絡卡）。
• IPv4 的地址空間約為 2^32 ≈ 42 億 個地址，已遠遠不能滿足全球需求。
• IPv6 地址空間為 2^128 ≈ 3.4 × 10^38 個地址，幾乎無限。

校驗和

Internet校驗和 是一種用于檢測數據報在傳輸過程中是否發生錯誤的機制。當發現一個頭部出錯（計算的校驗和不為0）時，IPv4實現將丟棄接收到的數據報。但是，不會生成差錯信息。更高層以某種方式檢測丟失的數據報，并在必要時重新傳輸。

計算過程：

1. 校驗和字段先置為 0。
2. 將整個 IP 頭部視為一個由多個 16位（2字節）單元組成的序列。
3. 將這些 16 位值使用 二進制反碼加法 相加（詳見下文）。
4. 將最終結果取 反碼（按位取反），存入校驗和字段中。

反碼加法（ones’ complement addition）：當兩個 16 位整數相加產生進位時，該進位會“循環”加回結果的最低位。

DS字段和ECN

• 區分服務字段（DS，Differentiated Services Field）：前 6 位
• 顯式擁塞通知字段（ECN，Explicit Congestion Notification）：后 2 位

DS 字段（Differentiated Services，6 位）

DS 字段由 RFC 2474 定義，用于提供一種可擴展的方式，以實現不同類型的數據服務，支持流量分類與服務質量（QoS）控制等功能。

DS 字段的實際名稱是 DSCP（Differentiated Services Code Point），它是 6 位的編碼字段。

常見的 DSCP 值包括：

• 000000：表示默認（Best Effort）服務，也就是標準默認傳輸方式，不提供任何特殊服務。
• 101110：表示加速轉發（Expedited Forwarding, EF），通常用于對延遲敏感的流量，如 VoIP，提供更快的轉發路徑。
• 001010、010010 等：這些是保證轉發（Assured Forwarding, AF）類的編碼，用于對數據流進行分類調度，以實現可靠性保證。

這些值通常由邊緣路由器設置，并作為數據報文通過網絡傳播時的分類依據，影響隊列調度和帶寬分配等行為。

ECN 字段（Explicit Congestion Notification，2 位）

ECN 字段由 RFC 3168 定義，它允許網絡中的路由器在發生擁塞時通過標記，而不是直接丟棄數據包，向通信雙方顯式通知網絡擁塞情況。

啟用 ECN 功能的前提是：發送方、接收方以及路徑中的路由器都必須支持 ECN。

ECN 字段包含兩位，其取值含義如下：

• 00：表示該數據報 不使用 ECN 功能，即傳統的基于丟包的擁塞控制。
• 01：表示 ECN 能力啟用，ECT(1)（ECN-Capable Transport, 1），由發送方設置。
• 10：表示 ECN 能力啟用，ECT(0)（ECN-Capable Transport, 0），也是由發送方設置。
• 11：表示遇到擁塞（Congestion Encountered, CE），由中間路由器設置。

ECN 的使用過程如下：

1. 發送方在發送數據報時，將 ECN 字段設置為 10（ECT(0)）或 01（ECT(1)），表示它支持 ECN。
2. 如果數據報在中間某個支持 ECN 的路由器處遇到擁塞，路由器會將 ECN 字段的值更改為 11（CE），而不是丟棄該數據報。
3. 接收方檢測到數據報的 ECN 字段為 CE 后，會在 TCP ACK 報文中將此信息反饋給發送方。
4. 發送方根據擁塞通知反饋，降低其發送速率或采取其他擁塞控制策略，以避免網絡進一步惡化。

IP選項

IPv4 支持在其頭部中添加一系列“選項”，這些選項最初由 [RFC 791] 定義。設計這些選項的初衷是在一個較小、可信任的網絡中支持調試、控制、安全等特殊功能。然而，隨著互聯網規模的不斷擴大以及安全問題的暴露，IP 選項在現代網絡中使用越來越少，很多也已被廢棄或僅用于實驗用途。

IPv6 不再在主頭部中攜帶選項，而是引入了**擴展頭部（Extension Headers）**的概念。所有可選信息都被組織為獨立的頭部，緊隨主頭部之后。這種設計更靈活，也便于路由器跳過不關心的頭部類型。

IPv6擴展頭部

IPv6 基本頭部固定為 40 字節，不包含任何可選字段。所有附加功能（如路由選擇、分片、認證、安全、選項等）都通過一個或多個擴展頭部來實現。

擴展頭部僅在需要時才添加，從而避免了每個數據包都必須處理冗余信息。

IPv6 數據包的頭部結構是鏈式結構，從基本頭部開始，每個頭部通過一個字段指向下一個頭部類型。

IPv6選項

IPv6 的擴展頭部中可以攜帶“選項”，這些選項通常用于控制、診斷、安全或特定的協議擴展功能。IPv6 選項主要出現在 Hop-by-Hop 頭部 或 Destination Options 頭部 中，每個選項都由以下字段組成：

• Option Type（1 字節）：標識選項類型。
• Opt Data Len（1 字節）：選項數據長度。
• Option Data：具體的數據內容。

填充1（Pad1）與填充N（PadN）

用于確保選項頭的對齊（通常按 8 字節對齊）或填充末尾空余字節。

• Pad1：1 字節的填充選項，僅包含一個字節的 Option Type，值為 0x00，不帶長度字段。
• PadN：多字節填充，用于填充任意長度，Option Type 為 0x01，后跟一個 Opt Data Len 字段和 N 字節的填充值（一般為0）。

這兩個選項在格式對齊或調試階段非常常見，不承載實際數據。

IPv6 超大有效載荷（Jumbo Payload）

定義在 [RFC 2675] 中，用于支持超過 65,535 字節的數據報。

• 使用一個名為 Jumbo Payload 的選項，其 Option Type 為 0xC2。
• 該選項包含一個 4 字節字段，指定實際的數據長度（最大可達 4,294,967,295 字節）。
• 僅當基本 IPv6 頭部的 Payload Length 字段為 0 時，才使用該選項。
• 此選項只能出現在 Hop-by-Hop 頭部 中。

該機制通常用于高性能網絡環境，且必須由通信雙方和中間設備共同支持。

隧道封裝限制（Tunnel Encapsulation Limit）

定義在 [RFC 2473] 中，用于控制一個 IPv6 數據包最多可以被封裝的次數。

• Option Type：0x04
• Option Data：1 字節，表示還允許封裝的剩余次數。
• 每當一個 IPv6 隧道對數據包封裝一次，該值減 1；若為 0，則不再封裝并丟棄分組。

該選項幫助避免隧道嵌套造成的死循環和性能下降問題。

路由器警告（Router Alert）

定義在 [RFC 2711] 中，用于告知中間路由器：該數據包需要特殊處理（如 RSVP 或 IGMP）。

• Option Type：0x05
• Option Data：2 字節的值，表示警告類型：
  • 0 表示需要對 IGMP 進行處理
  • 1 表示 RSVP
  • 2 表示 AN

該選項只能出現在 Hop-by-Hop 頭部中，是極少數必須由路由器處理的 IPv6 選項之一。

快速啟動（Quick-Start）

定義在 [RFC 4782] 中，是一個實驗性機制，用于讓主機在連接建立初期快速發送更多數據。

• 使用 Quick-Start 選項攜帶請求碼，請求更高的初始發送速率。
• 路由器在支持的前提下，根據自身情況返回批準速率。
• 可提升 TCP 連接建立時的效率，尤其在高帶寬鏈路中更明顯。

由于復雜性和安全性問題，該機制目前使用較少，仍處于試驗階段。

CALIPSO（通用標簽）

定義在 [RFC 5570] 中，用于為 IPv6 數據包打上安全標簽。

• 全稱為 Common Architecture Label IPv6 Security Option
• 適用于多級安全環境，尤其是軍事或政府網絡。
• 攜帶安全類別、安全策略等元信息，便于路由器或終端進行訪問控制。

該選項需結合特定的安全策略體系（如 Bell-LaPadula）才能發揮作用。

家鄉地址（Home Address）

定義在移動 IPv6（[RFC 6275]）中，用于在數據報中標識移動主機的原始地址。

• 移動節點將其當前的“臨時地址”作為 IPv6 源地址，并通過該選項攜帶其“家鄉地址”。
• 通信對端可據此識別真正身份，便于透明通信與安全控制。
• 常出現在 Destination Options 頭部 中，僅由通信對端處理。

該機制是移動 IPv6 實現移動性支持的核心組成部分。

分片頭部

IPv6 中的分片機制與 IPv4 有顯著區別：不再由中間路由器進行分片，而是完全交由源節點處理。這種設計簡化了中間路由器的實現，提升了網絡轉發效率，同時也提高了對網絡路徑中 MTU 限制的依賴。

• 不可分片部分：包括 IPv6 基本頭部及所有必須由中間節點處理的擴展頭部（如逐跳選項頭部）。
• 可分片部分：包含其余部分，例如目的地選項頭部、上層協議頭（如 TCP/UDP）以及數據負載。

1. 原始數據報分為多個分片，每個分片都攜帶一份完整的“不可分片部分”和一個獨立的分片頭部。
2. IPv6 頭部中的 Payload Length 字段也會在每個分片中被調整，反映當前分片的實際長度（包括分片頭和數據）。
3. 所有分片的 Identification 字段值相同，表明它們屬于同一原始數據報。
4. 所有分片的偏移值需為 8 字節對齊，所以分片大小（不含頭部）一般為 8 的倍數。
5. 最后一個分片的 M 位為 0，其余為 1。

IP轉發

從概念上講，IP 轉發機制非常簡單：

• 如果目的地址是本地網絡中的主機（如同一以太網或點到點鏈路），則直接發送；
• 否則，發送到一個默認網關（默認路由器），由其進行進一步的轉發；
• 若無路由信息可用，則數據報將被丟棄，有時會返回一個 ICMP 錯誤消息。

轉發表

IP 通過**查閱轉發表（或稱路由表）**來決定數據報的轉發路徑。雖然 IP 協議標準沒有強制指定轉發表的格式，但它一般包含以下關鍵信息：

字段	含義
目的地（Destination）	IPv4（32位）或 IPv6（128位）地址。可以是單個主機、子網或默認（0.0.0.0/0）路由
掩碼（Mask）	與數據報目的地址按位與后進行匹配。用于區分網絡前綴
下一跳（Next Hop）	表示下一跳的 IP 地址，數據報將被發送到此地址
接口（Interface）	用于發送數據報的物理或邏輯接口，如 eth0、wlan0、ppp0 等

IP轉發行為

當一臺主機或路由器中的 IP 層需要向下一跳發送一個數據報時，它會根據數據報的目的 IP 地址，在轉發表中查找最匹配的下一跳信息。該過程基于 最長前綴匹配（Longest Prefix Match, LPM） 算法進行。

1. 掩碼匹配

   遍歷轉發表中的每條記錄 e?，判斷其是否與目標地址 D 匹配：(D & m?) == d?

• m?：轉發表第 i 條目的掩碼字段；
• d?：轉發表第 i 條目的目的地字段；
• &：按位與操作。

2. 選擇最佳匹配

在所有滿足匹配條件的條目中，選擇掩碼中 1 的數量最多 的條目（即前綴最長的匹配項）。

例如，兩個匹配項的前綴分別為 /24 和 /16，則 /24 更優。

3. 獲取下一跳地址

從最佳匹配項中提取下一跳字段 n，作為數據報轉發的目標地址。

如果沒有任何條目匹配目標地址：

• 主機上：返回“主機不可達”錯誤給源應用；
• 路由器上：發送 ICMP“目的不可達”消息給源主機。

在某些情況下，多個條目可能具有相同的最長前綴長度（例如多個默認路由），此時標準協議沒有規定具體行為：

• 通常操作系統實現：

• 選擇第一條匹配項；

• 負載均衡（如 ECMP）；

• 基于路徑性能（如帶寬、延遲等）；

例子

IP 數據報的交付方式主要分為兩類：

• 直接交付：源主機和目的主機在同一網絡內；
• 間接交付：需要通過一個或多個路由器轉發。

直接交付

在直接交付中，源主機和目的主機處于 同一個網絡（如同一子網或廣播域），數據報可以直接送達。

示例環境：

• 主機 S（Windows XP）：IP 地址 10.0.0.100，MAC 地址為 MAC_S
• 主機 D（Linux）：IP 地址 10.0.0.9，MAC 地址為 MAC_D
• 它們通過一個交換機連接，處于相同的子網 10.0.0.0/25

主機 S 的轉發表如下：

目的地	掩碼	下一跳（網關）	接口
0.0.0.0	0.0.0.0	10.0.0.1	10.0.0.100
10.0.0.0	255.255.255.128	10.0.0.100	10.0.0.100

• 對于目的地址 10.0.0.9，兩個條目都匹配，但 /25 掩碼更長，因此選擇第二條。
• 網關字段與本機 IP 相同（10.0.0.100），意味著數據報將被 直接交付。

交付過程：

1. 如果不知道 D 的 MAC 地址，使用 ARP 請求獲取；
2. 數據報被封裝進以太網幀；
3. 幀的目的地址是 D 的 MAC 地址；
4. 數據通過交換機轉發，交付給主機 D。

間接交付

在間接交付中，源主機和目的主機處于不同網絡之間，必須通過路由器轉發。

示例環境：

• 源主機 S：IP 地址 10.0.0.100，默認網關為 10.0.0.1（R1 的 a 接口）
• 目標主機：ftp.uu.net，IP 地址 192.48.96.9
• 需要經過多個路由器轉發（例如 R1 → R2 → R3 → R4）

主機 S 的處理步驟：

1. 查找轉發表；
2. 找不到特定匹配條目，匹配到默認路由；
3. 默認路由指定下一跳為 10.0.0.1（R1）；
4. 使用 ARP 獲取 R1 的 MAC 地址；
5. 構造以太網幀，幀的目的地址是 R1 的 MAC；
6. 交付數據報給 R1。

注意：在間接交付中，IP 層目的地址始終不變，但低層幀的目的地址是“下一跳”的地址，而不是最終目的主機地址。

IPv6 中的對應處理

• IPv6 使用 鄰居請求消息（Neighbor Solicitation） 來解析下一跳的 MAC 地址；
• 引入 鏈路本地地址（fe80::/10） 與 全球地址 區分使用；
• 對于鏈路本地地址，可能需要用戶指定使用哪個接口；
• 轉發表邏輯基本相同，只是地址長度更長，協議細節略有不同。

移動IP

移動IP基于一臺主機擁有一個“家鄉”網絡，但可以不時地訪問其他網絡的想法。當主機離開家鄉時，它保持平時在家鄉使用的IP地址，但采用一些特殊的路由和轉發手段，使主機可以在這個網絡中與其他系統通信，就好像它仍連接在自己的家鄉網絡中那樣。該方案依賴于一種特殊類型的路由器，它被稱為“家鄉代理”，用于為移動節點提供路由。

基本模型：雙向隧道

移動IP允許一臺主機在改變網絡位置的同時保持其IP地址不變，從而維持上層協議（如TCP）連接的連續性。這種能力對于移動設備（如筆記本電腦、手機等）尤其重要。

在移動IP中，移動節點（MN）擁有一個在家鄉網絡上的家鄉地址（HoA）。當它連接到另一個網絡（稱為外地網絡）時，它會獲取一個新的IP地址，稱為轉交地址（CoA）。

移動IP的核心機制是家鄉代理（HA），這是一種特殊類型的路由器，部署在MN的家鄉網絡中。當CN（通信節點）向MN發送數據時，數據首先到達HA，然后由HA通過隧道機制將數據轉發給MN當前的CoA。

這種機制被稱為雙向隧道，原因如下：

• 從CN到MN：CN → HA → MN（隧道轉發）
• 從MN到CN：MN → HA → CN（隧道轉發）

MN綁定：MN的HoA與其當前CoA之間的映射關系，稱為綁定。HA負責維護這個綁定，并確保CN發來的數據被正確轉發。

路由優化

雙向隧道雖然簡單，但存在效率問題，特別是MN與CN物理距離較近，但都需通過遠距離的HA轉發時，路徑明顯繞遠。為了解決這個問題，MIPv6引入了路由優化（RO）。

1. 綁定更新（BU, Binding Update）
   MN向CN發送一個包含自己HoA和當前CoA的消息，稱為綁定更新請求。CN收到并驗證后，建立綁定關系。

2. 返回路由程序（RRP, Return Routability Procedure）
   為確保MN身份的真實性（防止偽造綁定），引入了RRP機制。其基本過程如下：

   • MN向CN發送兩個探測請求：一個從HoA出發（通過HA中轉），另一個從CoA直接發送。
   • CN收到兩個探測請求后，分別回復兩個探測應答。
   • MN接收到兩個應答后，生成綁定更新請求，并發送給CN。
   • CN通過比對兩個應答，確認HoA和CoA屬于同一個實體，從而建立信任并更新綁定緩存。

3. 數據傳輸階段
   一旦綁定建立成功，CN后續的數據報就可以直接發送給MN的CoA，不再需要經過HA中轉，從而實現了更高效的傳輸路徑。

IPv6要求IPsec支持，但在RO中，MN與CN之間通常不使用IPsec，因為不可靠或配置復雜。

RRP雖然沒有IPsec強大，但更簡單，且足夠滿足大多數移動通信場景的安全需求。

IP數據包的主機處理

雖然路由器在轉發數據報時通常不需要關心數據報的源地址或目的地址選擇，但對主機來說，選擇正確的源地址、判斷接收哪些目的地址以及如何在多接口環境中進行處理，是IP協議棧中的核心任務。

此外，當主機收到發往自身的IP數據報時，是否接受它，也取決于系統采用的主機模式。

主機模式

主機模式定義了在多接口設備上，主機是否接收那些發送到未直連接口地址的IP數據報。這一處理方式由 [RFC 1122] 規范，并分為兩種模式：

強主機模式（Strong Host Model）

在強主機模式下，主機只接受發送到該數據包到達接口上配置的IP地址的數據包。也就是說，目的地址必須與數據包所到達接口的本地地址匹配，系統才處理該數據報。

• 優點：安全性高，避免接口混淆或IP欺騙攻擊。
• 缺點：在多宿主（multi-homed）場景中可能丟棄有效數據包。

弱主機模式（Weak Host Model）

在弱主機模式下，主機接收所有目的地址匹配任意接口地址的數據報，無論這些數據包通過哪個接口接收。

• 優點：靈活，適用于負載均衡、多路徑傳輸、多宿主主機等場景。
• 缺點：可能被攻擊者利用進行IP地址欺騙攻擊。

示例說明

假設主機 A 配置有兩個接口：

• 接口 eth0：IP 地址為 203.0.113.1
• 接口 eth1：IP 地址為 192.0.2.1

主機 B 向 192.0.2.1 發送一個數據報，通過其 Internet 路由（而不是本地連接）發送。

• 如果主機 A 采用強主機模式，由于數據包沒有從 eth1 接收，即使目標地址為 192.0.2.1，也會被丟棄。
• 如果主機 A 采用弱主機模式，則會正常接收并處理這個數據包。

地址選擇

當一臺主機發送 IP 數據報時，需要為其選擇合適的 源地址 和 目的地址。這通常由地址選擇程序根據策略規則自動完成。

隨著 IPv6 的推廣、一個接口可綁定多個地址，以及雙棧主機的出現，地址選擇變得復雜，錯誤的選擇可能導致非對稱路由、分組丟棄等問題。

為此，RFC 3484 制定了地址選擇規則，并使用策略表控制選擇過程。

地址選擇核心思想

• 每臺主機維護一個策略表（最長匹配前綴查找表），根據地址的前綴、標簽和優先級決定使用哪對源/目的地址。
• 源地址選擇算法會為一個目的地址選擇最合適的本地地址。
• 目的地址選擇算法會為一個本地源地址選擇最合適的目的地址。

源地址選擇算法

給定目的地址 D，從本地地址集合中選擇一個最合適的源地址 A，按以下規則依次比較：

1. 優先選擇與目的地址相同的地址
2. 優先選擇范圍更接近目的地址的地址
3. 避免使用過期地址
4. 優先選擇家鄉地址而非轉交地址
5. 優先選擇與目的接口一致的地址
6. 優先標簽匹配的地址
7. 優先非臨時地址
8. 優先前綴匹配更長的地址

目的地址選擇算法

從多個可用的目的地址中為某個源地址選擇最佳目的地址：

1. 避免不可用的目的地（不可達或無源地址可用）
2. 優先與源地址作用范圍匹配的地址
3. 避免使用源地址為過期地址的目的地址
4. 優先選擇配對源地址是家鄉地址的目的地址
5. 優先標簽匹配的目的地址
6. 優先更高優先級的目的地址
7. 優先不經封裝傳輸的目的地址
8. 優先較小作用范圍的地址
9. 優先前綴匹配更長的地址對