IPv4

網際協議版本 4（Internet Protocol version 4，縮寫：IPv4，又稱網際網路通訊協定第四版）是網際協議開發過程中的第四個修訂版本，也是此協議第一個被廣泛部署和使用的版本。其後繼版本為 IPv6，直到 2011 年，IANA IPv4 位址完全用盡時，IPv6 仍處在部署的初期。

IPv4 在 IETF 於 1981 年 9 月釋出的 RFC 791 中被描述，此 RFC 替換了於 1980 年 1 月釋出的 RFC 760。

IPv4 是一種無連線的協議，操作在使用分組交換的鏈路層（如乙太網）上。此協議會盡最大努力交付資料包，意即它不保證任何資料包均能送達目的地，也不保證所有資料包均按照正確的順序無重複地到達。這些方面是由上層的傳輸協議（如傳輸控制協議）處理的。

地址

IPv4 使用 32 位（4 位元組）地址，因此地址空間中只有約四十億（4,294,967,296，232）個地址。不過，一些地址是為特殊用途所保留的，如專用網路（約 1800 萬個地址）和多播地址（約 2.7 億個地址），這減少了可在網際網路上路由的地址數量。隨著地址不斷被分配給終端使用者，IPv4 地址枯竭問題也在隨之產生。基於分類網路、無類別域間路由和網路地址轉換的地址結構重構顯著地減少了地址枯竭的速度。但在 2011 年 2 月 3 日，在最後 5 個地址塊被分配給 5 個區域網際網路註冊管理機構之後，IANA 的主要地址池已經用盡。

這些限制刺激了仍在開發早期的作為目前唯一的長期解決方案的 IPv6 的部署。

1.1 地址格式

IPv4 地址可被寫作任何表示一個 32 位整數值的形式，但為了方便人類閱讀和分析，它通常被寫作點分十進位制的形式，即四個位元組被分開用十進位制寫出，中間用點分隔。

下表展示了幾種不同的格式：

此外，在點分格式中，每個位元組都可用任意的進製表達。如，192.0x00.0002.235 是一種合法（但不常用）的表示。點分格式也支援零省略的寫法，例如 127.1.1 等同於 127.1.0.1。

1.2 常規分類

說明：D 類與 E 類 IPv4 地址不區分網路地址與主機地址

1.3 分配

最初，一個 IP 地址被分成兩部分：網路識別碼在地址的高位位元組中，主機識別碼在剩下的部分中。

為了克服這個限制，在隨後出現的分類網路中，地址的高位位元組被重定義為網路的類 (Class)。這個系統定義了五個類別：A、B、C、D 和 E。A、B 和 C 類有不同的網路類別長度，剩餘的部分被用來識別網路內的主機，這就意味著每個網路類別有著不同的給主機編址的能力。D 類被用於多播地址，E 類被留作將來使用。

1993 年，無類別域間路由（CIDR）正式地取代了分類網路，後者也因此被稱為 “有類別” 的。

CIDR 被設計為可以重新劃分地址空間，因此小的或大的地址塊均可以分配給使用者。CIDR 建立的分層架構由網際網路號碼分配局（IANA）和區域網際網路註冊管理機構（RIR）進行管理，每個 RIR 均維護著一個公共的 WHOIS 資料庫，以此提供 IP 地址分配的詳情。

1.4 特殊用途的地址

1.5 專用網路

在 IPv4 所允許的大約四十億地址中，三個地址塊被保留作專用網路。這些地址塊在專用網路之外不可路由，專用網路之內的主機也不能直接與公共網路通訊。但透過網路地址轉換（NAT），使用這些地址的主機可以像擁有共有地址的主機在網際網路上通訊。

下表展示了三個被保留作專用網路的地址塊（RFC 1918）：

1.5.1 虛擬專用網路

通常情況下，路由器根據資料報文的目的地址決定轉發資料報文的下一跳地址。使用專用網路地址作為目的地址的資料包通常無法被公共路由器正確送達，因為公共路由器沒有相應的路由資訊，即無法得知如何才能轉發到該 IP 地址。因此，這就需要透過一種方法，將指引資料報文轉發的下一跳地址和真正要傳輸的目的地址分離開。於是就使用虛擬專用網，將 IP 報文封裝在其他報文內，以便於透過公網上的公共路由器，達到能處理該封包內層資料的網路裝置上解除封包後，該資料包可以被繼續轉發到目的地址。

將資料報文封裝的過程中，可以將資料報文封裝於 IP 報文中，也可以使用多協議標籤交換協議等，透過其他協議引導資料報文轉發。也可以封裝同時加密資料，以保護資料內容。

1.6 鏈路本地地址

RFC 5735 中將地址塊 169.254.0.0/16 保留為特殊用於鏈路本地地址，這些地址僅在鏈路上有效（如一段本地網路或一個端到端連線）。這些地址與專用網路地址一樣不可路由，也不可作為公共網路上報文的源或目的地址。鏈路本地地址主要被用於地址自動配置：當主機不能從 DHCP 伺服器處獲得 IP 地址時，它會用這種方法生成一個。

當這個地址塊最初被保留時，地址自動配置尚沒有一個標準。為了填補這個空白，微軟建立了一種叫自動專用 IP 定址（APIPA）的實現。因微軟的市場影響力，APIPA 已經被部署到了幾百萬機器上，也因此成為了事實上的工業標準。許多年後，IETF 為此定義了一份正式的標準：RFC 3927，命名為 “IPv4 鏈路本地地址的動態配置”。

1.7 環回地址（Loopback Address）

地址塊 127.0.0.0/8 被保留作環回通訊用。此範圍中的地址絕不應出現在主機之外，傳送至此地址的報文被作為同一虛擬網路裝置上的入站報文（環回），主要用於檢查 TCP/IP 協議棧是否正確執行和本機對本機的連結。

1.8 以 0 或 255 結尾的地址

一個常見的誤解是以 0 或 255 結尾的地址永遠不能分配給主機：這僅在子網路遮罩至少 24 位元長度時（舊的 C 類地址，或 CIDR 中的 / 24 到 / 32）才成立。

在有類別的編址中，只有三種可能的子網路遮罩：A 類：255.0.0.0，B 類：255.255.0.0，C 類：255.255.255.0。如，在子網路 192.168.5.0/255.255.255.0（即 192.168.5.0/24）中，網路識別碼 192.168.5.0 用來表示整個子網路，所以它不能用來標識子網路上的某個特定主機。

廣播地址允許資料包發往子網路上的所有裝置。一般情況下，廣播位址是藉由子網路遮罩的位元反碼並和網路識別碼執行 OR 的位元運算得到，即廣播地址是子網路中的最後一個地址。在上述例子中，廣播地址是 192.168.5.255，所以為了避免歧義，這個地址也不能被分配給主機。在 A、B 和 C 類網路中，廣播地址總是以 255 結尾。

但是，這並不意味著每個以 255 結尾的地址都不能用做主機地址。比如，在 B 類子網 192.168.0.0/255.255.0.0（即 192.168.0.0/16）中，廣播地址是 192.168.255.255（主機位全 1）。在這種情況下，儘管可能帶來誤解，但 192.168.1.255、192.168.2.255 等地址可以被分配給主機。同理，192.168.0.0 作為網路識別碼不能被分配，但 192.168.1.0、192.168.2.0 等都是可以的。

隨著 CIDR 的到來，廣播地址不一定總是以 255 結尾（廣播地址是指主機位都為 1 的地址，255 只是其中一種情況）。比如，子網路 203.0.113.16/28 的廣播地址是 203.0.113.31。過程如下：

網路：203.0.113.16

掩碼：255.255.255.240

掩碼反碼：0.0.0.15

OR 操作：

00010000 | 00001111 = 00011111 =31

一般情況下，子網路的第一個和最後一個地址分別被作為網路識別碼和廣播地址，任何其它地址都可以被分配給其上的主機。

1.9 地址解析

網際網路上的主機通常被指定，但 IP 報文的路由是由 IP 地址而不是這些名字決定的。這就需要將域名翻譯（解析）成地址。

域名系統（DNS）提供了域名轉換為 IP 地址的服務。與 CIDR 相像，DNS 是層級結構。

地址空間枯竭

從 20 世紀 80 年代起，一個很明顯的問題是 IPv4 地址在以比設計時的預計更快的速度耗盡。 這是建立分類網路、無類別域間路由，和最終決定重新設計基於更長地址的網際網路協議（IPv6）的誘因。

一些市場力量也加快了 IPv4 地址的耗盡，如：

網際網路使用者的急速增長；
總是開著的裝置：ADSL 調變解調器、纜線資料機等；
移動裝置：筆記型電腦、PDA、行動電話等。

隨著網際網路的增長，各種各樣的技術隨之產生以應對 IPv4 地址的耗盡，如：

網路地址轉換（NAT）；
專用網路的使用；
動態主機設定協議（DHCP）；
基於名字的虛擬主機；
區域網際網路註冊管理機構對地址分配的控制；
對網際網路初期分配的大地址塊的回收。

隨著 IANA 把最後 5 個地址塊分配給 5 個 RIR，其主地址池在 2011 年 2 月 3 日耗盡。 許多地址分配和消耗的模型都預測第一個耗盡地址的 RIR 會在 2011 年的下半年出現。ARIN 在 2015 年用完可用的供應，APNIC、LACNIC 和 AFIC 根據其社群政策定量供應。

廣泛被接受且已被標準化的解決方案是遷移至 IPv6。IPv6 的地址長度從 IPv4 的 32 位增長到了 128 位，以此提供了更好的路由聚合，也為終端使用者分配最小為 264 個主機地址的地址塊成為可能。遷移過程正在進行，但其完成仍需要相當的時間。

網路地址轉換

對地址的快速分配和其造成的地址短缺促成了許多有效應用地址的方法，其中一種就是網路地址轉換（NAT）。

報文結構

IP 報文包含 IP 首部和資料部分

4.1 首部

IPv4 報文的首部包含 14 個欄位，其中 13 個是必須的，第 14 個是可選的（紅色標出），並命名為：“選項” 欄位。首部中的欄位均以大端序包裝，在以下的圖表和討論中，最高有效位（Most Significant bit）被標記為 0。

 版本（Version）

 版本欄位佔 4bit，通訊雙方使用的版本必須一致。對於 IPv4，欄位的值是 4。

 首部長度（Internet Header Length， IHL）

 佔 4bit，首部長度說明首部有多少 32 位字（4 位元組）。由於 IPv4 首部可能包含數目不定的選項，這個欄位也用來確定資料的偏移量。這個欄位的最小值是 5（二進位制 0101），相當於 5*4=20 位元組（RFC 791），最大十進位制值是 15。

 區分服務（Differentiated Services，DS）

 佔 6bit，最初被定義為服務型別欄位，實際上並未使用，但 1998 年被 IETF 重定義為區分服務 RFC 2474。只有在使用區分服務時，這個欄位才起作用，在一般的情況 下都不使用這個欄位。例如需要即時資料流的技術會應用這個欄位，一個例子是 VoIP。

 顯式擁塞通告（ Explicit Congestion Notification，ECN）

 在 RFC 3168 中定義，允許在不丟棄報文的同時通知對方網路擁塞的發生。ECN 是一種可選的功能，僅當兩端都支援並希望使用，且底層網路支援時才被使用。

 全長（Total Length）

 這個 16 位欄位定義了報文總長，包含首部和資料，單位為位元組。這個欄位的最小值是 20（20 位元組首部 + 0 位元組資料），最大值是 216-1=65,535。IP 規定所有主機都必須支援最小 576 位元組的報文，這是假定上層資料長度 512 位元組，加上最長 IP 首部 60 位元組，加上 4 位元組富裕量，得出 576 位元組，但大多數現代主機支援更大的報文。當下層的資料鏈路協議的最大傳輸單元（MTU）欄位的值小於 IP 報文長度時，報文就必須被分片，詳細見下個標題。

 識別符號（Identification）

 佔 16 位，這個欄位主要被用來唯一地標識一個報文的所有分片，因為分片不一定按序到達，所以在重組時需要知道分片所屬的報文。每產生一個數據報，計數器加 1，並賦值給此欄位。一些實驗性的工作建議將此欄位用於其它目的，例如增加報文跟蹤資訊以協助探測偽造的源地址。

 標誌 （Flags）

 這個 3 位欄位用於控制和識別分片，它們是：

位 0：保留，必須為 0；
位 1：禁止分片（Don’t Fragment，DF），當 DF=0 時才允許分片；
位 2：更多分片（More Fragment，MF），MF=1 代表後面還有分片，MF=0 代表已經是最後一個分片。

 如果 DF 標誌被設定為 1，但路由要求必須分片報文，此報文會被丟棄。這個標誌可被用於發往沒有能力組裝分片的主機。

 當一個報文被分片，除了最後一片外的所有分片都設定 MF 為 1。最後一個片段具有非零片段偏移欄位，將其與未分片資料包區分開，未分片的偏移欄位為 0。

 分片偏移 （Fragment Offset）

 這個 13 位欄位指明瞭每個分片相對於原始報文開頭的偏移量，以 8 位元組作單位。

 存活時間（Time To Live，TTL）

 這個 8 位欄位避免報文在網際網路中永遠存在（例如陷入路由環路）。存活時間以秒為單位，但小於一秒的時間均向上取整到一秒。在現實中，這實際上成了一個跳數計數器：報文經過的每個路由器都將此欄位減 1，當此欄位等於 0 時，報文不再向下一跳傳送並被丟棄，最大值是 255。常規地，一份 ICMP 報文被髮回報文傳送端說明其傳送的報文已被丟棄。這也是 traceroute 的核心原理。

 協議 （Protocol）

 佔 8bit，這個欄位定義了該報文資料區使用的協議。IANA 維護著一份協議列表（最初由 RFC 790 定義），詳細參見 IP 協議號列表。

 首部檢驗和 （Header Checksum）

 這個 16 位檢驗和欄位只對首部查錯，不包括資料部分。在每一跳，路由器都要重新計算出的首部檢驗和並與此欄位進行比對，如果不一致，此報文將會被丟棄。重新計算的必要性是因為每一跳的一些首部欄位（如 TTL、Flag、Offset 等）都有可能發生變化，不檢查資料部分是為了減少工作量。資料區的錯誤留待上層協議處理 —— 使用者資料報協議（UDP）和傳輸控制協議（TCP）都有檢驗和欄位。此處的檢驗計算方法不使用 CRC。

 RFC 1071

 源地址（Source address）

 一個 IPv4 地址由四個位元組共 32 位構成，此欄位的值是將每個位元組轉為二進位制並拼在一起所得到的 32 位值。

 例如，10.9.8.7 是 00001010000010010000100000000111。

 但請注意，因為 NAT 的存在，這個地址並不總是報文的真實發送端，因此發往此地址的報文會被送往 NAT 裝置，並由它被翻譯為真實的地址。

 目的地址（Destination address）

 與源地址格式相同，但指出報文的接收端。

 選項（Options）

 附加的首部欄位可能跟在目的地址之後，但這並不被經常使用，從 1 到 40 個位元組不等。請注意首部長度欄位必須包括足夠的 32 位字來放下所有的選項（包括任何必須的填充以使首部長度能夠被 32 位整除）。當選項列表的結尾不是首部的結尾時，EOL（選項列表結束，0x00）選項被插入列表末尾。下表列出了可能

注：如果首部長度大於 5，那麼選項欄位必然存在並必須被考慮。
注：備份、類和數字經常被一併稱呼為 “型別”。

 寬鬆的源站選路（LSRR）和嚴格的源站選路（SSRR）選項不被推薦使用，因其可能帶來安全問題。許多路由器會拒絕帶有這些選項的報文。

4.2 資料

資料欄位不是首部的一部分，因此並不被包含在首部檢驗和中。資料的格式在協議首部欄位中被指明，並可以是任意的傳輸層協議。

一些常見協議的協議欄位值被列在下面：

分片和組裝

網際網路協議（IP）是整個網際網路架構的基礎，可以支援不同的物理層網路，即 IP 層獨立於鏈路層傳輸技術。不同的鏈路層不僅在傳輸速度上有差異，還在幀結構和大小上有所不同，不同 MTU 引數描述了資料幀的大小。為了實現 IP 資料包能夠使用不同的鏈路層技術，需要將 IP 資料包變成適合鏈路層的資料格式，IP 報文的分片即是 IP 資料包為了滿足鏈路層的資料大小而進行的分割。

在 IPv6 不要求路由器執行分片操作，而是將檢測路徑最大傳輸單元大小的任務交給了主機。

5.1 分片

當裝置收到 IP 報文時，分析其目的地址並決定要在哪個鏈路上傳送它。MTU 決定了資料載荷的最大長度，如 IP 報文長度比 MTU 大，則 IP 資料包必須進行分片。每一片的長度都小於等於 MTU 減去 IP 首部長度。接下來每一片均被放到獨立的 IP 報文中，並進行如下修改：

總長欄位被修改為此分片的長度；
更多分片（MF）標誌被設定，除了最後一片；
分片偏移量欄位被調整為合適的值；
首部檢驗和被重新計算。

例如，對於一個長 20 位元組的首部和一個 MTU 為 1,500 的乙太網，分片偏移量將會是：0、(1480/8)=185、(2960/8)=370、(4440/8)=555、(5920/8)=740、等等。

如果報文經過路徑的 MTU 減小了，那麼分片可能會被再次分片。

比如，一個 4,500 位元組的資料載荷被封裝進了一個沒有選項的 IP 報文（即總長為 4,520 位元組），並在 MTU 為 2,500 位元組的鏈路上傳輸，那麼它會被破成如下兩個分片：

現在，假設下一跳的 MTU 為 1,500 位元組，那麼每一個分片都會被再次分成兩片（由於資料片段只有在目的主機才重新被組成資料報，因此再次分片是針對每個在網路中傳輸的資料幀）：

第 3 和 4 片是從原始第 2 片再次分片而來，所以除了分片後的最後一個分片外 MF 為都為 1。

5.2 重組

當一個接收者發現 IP 報文的下列專案之一為真時：

DF 標誌為 0；
分片偏移量欄位不為 0。

它便知道這個報文已被分片，並隨即將資料、識別符號欄位、分片偏移量和更多分片標誌一起儲存起來。

當接受者收到了更多分片標誌未被設定的分片時，它便知道原始資料載荷的總長。一旦它收齊了所有的分片，它便可以將所有片按照正確的順序（透過分片偏移量）組裝起來，並交給上層協議棧。

輔助協議

網際網路協議定義並激活了網路層，它使用一個邏輯地址系統。IP 地址並不以任何永久的方式繫結到硬體，而且事實上一個網路介面可以有許多 IP 地址。為了正確地交付一份報文，主機和路由器需要其它機制來識別裝置介面和 IP 地址之間的關聯。地址解析協議（ARP）為 IPv4 執行這種 IP 地址到物理地址（MAC 地址）的轉換。

此外，反向操作有時候也是必須的，比如，一臺主機在啟動時需要知道自己的 IP 地址（除非地址已經被管理員預先設定）。目前被用於這一用途的協議有動態主機設定協議（DHCP）、引導協議（BOOTP）和比較不常用的 RARP。