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位地址長度，地址空間共可提供43億（4,294,967,296）個地址，其中可在網際網路上路由的公共地址約37億個，近6億個IP位址保留作其他用途。

在早期的分類網絡架構中，多播地址（D類）被分配了4位前綴，因此佔用了約2.7億（228）個地址。多播地址的使用率不高，16個`/8`網路前綴中有12個屬於「保留」。

約2.7億個E類地址保留作研究、實驗或未來用途。部分軟體和硬體把E類地址視為不合法，並自動丟棄這些封包。由於存在相容性問題，所以在IP位址枯竭時沒有投入使用。此外，IANA認為各國對IP位址的需求龐大，即使把E類地址改為公共地址，人們依然會迅速耗盡所有IP位址。

另外，一些地址是為特殊用途所保留。在A類、B類和C類網路中，各有一個地址區塊保留作專用網絡，合共有約1789萬個地址。`127.0.0.0/8`保留作Localhost回送測試，`0.0.0.0/8`保留作「本網路」，各佔用1678萬個地址。這都減少了可在網際網路上路由的公共地址數量。

隨著地址不斷被分配給最終使用者，IPv4地址枯竭問題也在隨之產生。基於無類別域間路由和網路地址轉換的地址結構重構顯著地減少了地址枯竭的速度。2011年2月3日，在最後5個地址塊被分配給5個區域網際網路註冊管理機構之後，IANA的主要地址池已經用盡。

由於IPv6並不向下相容IPv4，導致使用率增長緩慢。即使已經耗盡IPv4位址，也未能刺激網際網路服務供應商部署IPv6。ISP更傾向於部署電信級NAT，把一個IPv4公共地址轉換為多個IPv4私人地址，供多個客戶同時使用。使用者的路由器也使用NAT，把ISP的一個私人地址轉換為屬於使用者自己的多個私人地址。整個NAT過程包括三個IPv4地址空間，因此稱為NAT444。

### 地址格式

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

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

格式｜值｜從點分十進位轉換

點分十進位｜192.0.2.235｜不適用

點分十六進位｜0xC0.0x00.0x02.0xEB｜每個字節被單獨轉換為十六進位

點分八進位｜0300.0000.0002.0353｜每個字節被單獨轉換為八進位

十六進位｜0xC00002EB｜將點分十六進位連在一起

十進位｜3221226219｜用十進位寫出的32位整數

八進位｜030000001353｜用八進位寫出的32位整數

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

### 分類網絡

IP位址最初被分成兩部分：網路識別碼在地址的首8位，主機識別碼在剩下的24位。此層級結構限制了網際網路只能由254個網路組成，可擴展性不足。為了克服這個限制，在隨後出現的分類網絡中，地址的高位字節被重定義為網路的類(Class)。這個系統定義了五個類別：A、B、C、D和E。

A、B和C類有不同的網路類別長度，剩餘的部分被用來識別網路內的主機，這就意味著每個網路類別有著不同的給主機編址的能力。D類被用於多播地址，E類被留作將來使用。

前8位地址範圍｜類｜路由形式｜占地址總空間的比例

0-127｜A｜單播｜1/2

128-191｜B｜單播｜1/4

192-223｜C｜單播｜1/8

224-239｜D｜多播｜1/16

240-255｜E｜1/16

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

CIDR採用可變長度的網路前綴，按需要分配不同大小的地址塊給使用者，不再是三款固定長度。CIDR創建的分層架構由網際網路號碼分配局（IANA）和區域網際網路註冊管理機構（RIR）進行管理，每個RIR均維護著一個公共的WHOIS資料庫，以此提供IP位址分配的詳情。

### 特殊用途的地址

CIDR地址塊｜描述｜參考資料

0.0.0.0/8｜本網路（僅作為源地址時合法）｜RFC 6890

10.0.0.0/8｜專用網絡｜RFC 1918

100.64.0.0/10｜電信級NAT｜RFC 6598

127.0.0.0/8｜環回｜RFC 5735

169.254.0.0/16｜鏈路本地｜RFC 3927

172.16.0.0/12｜專用網絡｜RFC 1918

192.0.0.0/24｜保留（IANA）｜RFC 5735

192.0.2.0/24｜TEST-NET-1，文檔和示例｜RFC 5735

192.88.99.0/24｜6to4中繼｜RFC 3068

192.168.0.0/16｜專用網絡｜RFC 1918

198.18.0.0/15｜網路基準測試｜RFC 2544

198.51.100.0/24｜TEST-NET-2，文檔和示例｜RFC 5737

203.0.113.0/24｜TEST-NET-3，文檔和示例｜RFC 5737

224.0.0.0/4｜多播（之前的D類網路）｜RFC 3171

240.0.0.0/4｜保留（之前的E類網路）｜RFC 1700

255.255.255.255/32｜受限廣播｜RFC 919

網路號｜主機號｜是否可以作為源地址｜是否可以作為目的地址｜備註/描述

全為0｜全為0｜允許｜禁止｜表示本網主機

全為0｜Host ID｜允許｜禁止｜表示特定主機

全為1｜全為1｜禁止｜允許｜定向廣播地址

127｜任意合法的值｜允許｜允許｜迂迴地址，用於本地測試

Network ID｜全為1｜禁止｜允許｜直接廣播地址

### 專用網絡

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

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

名字｜地址範圍｜地址數量｜有類別的描述｜最大的CIDR地址塊

24位塊｜10.0.0.0–10.255.255.255｜16,777,216｜一個A類｜10.0.0.0/8

20位塊｜172.16.0.0–172.31.255.255｜1,048,576｜連續的16個B類｜172.16.0.0/12

16位塊｜192.168.0.0–192.168.255.255｜65,536｜連續的256個C類｜192.168.0.0/16

#### 虛擬專用網絡

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

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

### 鏈路本地地址

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

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

### 環回地址

地址塊127.0.0.0/8被保留作環回通信用（Loopback Address）。此範圍中的地址絕不應出現在主機之外，發送至此地址的報文被作為同一虛擬網路設備上的入站報文（環回），主要用於檢查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操作：

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

### 地址解析

網際網路上的主機通常被指定，但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，地址長度從32位增加到128位，其中由ISP分配的網路前綴最長64位元。

在IPv4年代，路由器把ISP分配的IP位址轉換為私人網路（如`192.168.0.0/16`），再分配IP位址給其他設備。IPv6的其中一個設計理念是不使用網路地址轉換（NAT），網路前綴佔64位，後64位元作為主機地址，讓每一台設備都可以有自己的公共地址。

## 網路地址轉換

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

## 報文結構

IP報文包含IP首部和數據部分

### 首部

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

位偏移｜0–3｜4–7｜8–13｜14-15｜16–18｜19–31

0｜版本｜首部長度｜區分服務｜顯式擁塞通知｜全長

32｜標識符｜標誌｜分片偏移

64｜存活時間｜協議｜首部檢驗和

96｜源IP位址

128｜目的IP位址

160｜選項（如首部長度>5）

160或192+｜數據

版本（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）選項被插入列表末尾。下表列出了可能

欄位｜長度（位）｜描述

備份｜1｜當此選項需要被備份到所有分片中時，設為1。

類｜2｜常規的選項類別，0為「控制」，2為「查錯和措施」，1和3保留。

數字｜5｜指明一個選項。

長度｜8｜指明整個選項的長度，對於簡單的選項此欄位可能不存在。

數據｜可變｜選項相關數據，對於簡單的選項此欄位可能不存在。

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

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

### 數據

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

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

協議欄位值｜協議名｜縮寫

1｜網際網路控制消息協議｜ICMP

2｜網際網路組管理協議｜IGMP

6｜傳輸控制協議｜TCP

17｜使用者數據報協議｜UDP

41｜IPv6封裝｜ENCAP

89｜開放式最短路徑優先｜OSPF

132｜流控制傳輸協議｜SCTP

參見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位元組的鏈路上傳輸，那麼它會被破成如下兩個分片：

-｜總長｜更多分片（MF）？｜DF｜分片偏移量

首部｜數據

1｜2500｜0｜0

20｜2480

2｜2040｜0｜310

20｜2020

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

-｜總長｜更多分片（MF）？｜DF｜分片偏移量

首部｜數據

1｜1500｜0｜0

20｜1480

2｜1020｜0｜185

20｜1000

3｜1500｜0｜310

20｜1480

4｜560｜0｜495

20｜540

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

### 重組

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

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

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

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

## 輔助協議

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

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

## 外部連結

- 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)