網際協定版本 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 的部署。

位址格式

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

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

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

常規分類

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

分配

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

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

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

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

特殊用途的位址

專用網路

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

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

虛擬私人網路絡

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

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

鏈路本地位址

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

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

環回位址（Loopback Address）

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

以 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

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

位址解析

網際網路上的主機通常被指定，但 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 首部和資料部分

首部

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）選項不被推薦使用，因其可能帶來安全問題。許多路由器會拒絕帶有這些選項的封包。

資料

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

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

參見 IP 協定號列表以獲得完整列表。



分片和組裝

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

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

分片

當裝置收到 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。

重組

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


* DF 標誌為 0；

* 分片偏移量欄位不為 0。

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

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



輔助協定

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

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



參見


* 分類網路

* 無類別域間路由

* 網際網路號碼分配局

* 已分配的 / 8 IPv4 位址塊列表

* 區域網際網路註冊管理機構

* 各國 IPv4 位元址分配列表



參考文獻



外部連結


* RFC 791 — Internet Protocol（英文）

* RFC 3344 — IPv4 Mobility（英文）

* IANA — 網際網路位址分配局官方網站（英文）

* IP Header Breakdown, including specific options（頁面存檔備份，存於網際網路檔案館）（英文）

* IPv6 vs. carrier-grade NAT/squeezing more out of IPv4（英文）

* IPv4 特殊用途位址（頁面存檔備份，存於網際網路檔案館） （英文）

位址耗盡：


* RIPE report on address consumption as of October 2003

* Official current state of IPv4 /8 allocations, as maintained by IANA

* Dynamically generated graphs of IPv4 address consumption with predictions of exhaustion dates — Geoff Huston（頁面存檔備份，存於網際網路檔案館）

* IP addressing in China and the myth of address shortage

* Countdown of remaining IPv4 available addresses（頁面存檔備份，存於網際網路檔案館） (estimated)