Loading AI tools
網際協定版本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位元整數值的形式，但為了方便人類閱讀和分析[1]，它通常被寫作點分十進制的形式，即四個位元組被分開用十進制寫出，中間用點分隔。
下表展示了幾種不同的格式：
此外，在點分格式中，每個位元組都可用任意的進制表達。如，192.0x00.0002.235是一種合法（但不常用）的表示。點分格式也支援零省略的寫法，例如127.1..1等同於127.1.0.1。
| 描述 | A類IPv4位址 | B類IPv4位址 | C類IPv4位址 | D類IPv4位址 | E類IPv4位址 |
|---|---|---|---|---|---|
| 網絡標誌位 | 0 | 10 | 110 | 1110 | 1111 |
| IP位址範圍 | 0.0.0.0~127.255.255.255 | 128.0.0.0~191.255.255.255 | 192.0.0.0~223.255.255.255 | 224.0.0.0~239.255.255.255 | 240.0.0.0~255.255.255.255 |
| 可用IP位址範圍 | 1.0.0.1~127.255.255.254 | 128.0.0.1~191.255.255.254 | 192.0.0.1~223.255.255.254 | ||
| 是否可以分配給主機使用 | 是 | 是 | 是 | 否 | 否 |
| 網絡數量（個） | 126 (27-2) | 16384 (214) | 2097152 (221) | --- | --- |
| 每個網絡中可容納主機數（個） | 16777214 (224-2) | 65534 (216-2) | 254 (28-2) | --- | --- |
| 適用範圍 | 大量主機的大型網絡 | 中等規模主機數的網絡 | 小型區域網絡 | 留給Internet體系結構委員會(IAB)使用
多播位址 |
保留，僅作為搜尋、Internet的實驗和開發用 |
| 備註 | 0.0.0.0為特殊位址，表示本網主機 | 255.255.255.255為特殊位址，用於定向廣播 |
說明：D類與E類IPv4位址不區分網絡位址與主機位址
| 網絡號 | 主機號 | 是否可以作為源位址 | 是否可以作為目的位址 | 備註/描述 |
|---|---|---|---|---|
| 全為0 | 全為0 | 允許 | 禁止 | 表示本網主機 |
| 全為0 | Host ID | 允許 | 禁止 | 表示特定主機 |
| 全為1 | 全為1 | 禁止 | 允許 | 定向廣播位址 |
| 127 | 任意合法的值 | 允許 | 允許 | 迂迴位址，用於本地測試 |
| Network ID | 全為1 | 禁止 | 允許 | 直接廣播位址 |
最初，一個IP位址被分成兩部分：網絡識別碼在位址的高位位元組中，主機識別碼在剩下的部分中。
為了克服這個限制，在隨後出現的分類網絡中，位址的高位位元組被重定義為網絡的類(Class)。這個系統定義了五個類別：A、B、C、D和E。A、B和C類有不同的網絡類別長度，剩餘的部分被用來辨識網絡內的主機，這就意味着每個網絡類別有着不同的給主機編址的能力。D類被用於多播位址，E類被留作將來使用。
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 |
在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被保留作環回通訊用。此範圍中的位址絕不應出現在主機之外，傳送至此位址的封包被作為同一虛擬網絡裝置上的入站封包（環回），主要用於檢查TCP/IP協定棧是否正確執行和本機對本機的連結。
一個常見的誤解是以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位址在以比設計時的預計更快的速度耗盡。[4] 這是創建分類網絡、無類別域間路由，和最終決定重新設計基於更長位址的互聯網協定（IPv6）的誘因。
一些市場力量也加快了IPv4位址的耗盡，如：
隨着互聯網的增長，各種各樣的技術隨之產生以應對IPv4位址的耗盡，如：
隨着IANA把最後5個位址塊分配給5個RIR，其主位址池在2011年2月3日耗盡。[5] 許多位址分配和消耗的模型都預測第一個耗盡位址的RIR會在2011年的下半年出現。[6]ARIN在2015年用完可用的供應，APNIC、LACNIC和AFIC根據其社區政策定量供應[7]。
廣泛被接受且已被標準化的解決方案是遷移至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，並賦值給此欄位。一些實驗性的工作建議將此欄位用於其它目的，例如增加封包跟蹤資訊以協助探測偽造的源位址。[8]
- 標誌 （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的核心原理。
- 首部核對和 （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）選項不被推薦使用，因其可能帶來安全問題。許多路由器會拒絕帶有這些選項的封包。
數據欄位不是首部的一部分，因此並不被包含在首部核對和中。數據的格式在協定首部欄位中被指明，並可以是任意的傳輸層協定。
一些常見協定的協定欄位值被列在下面：
參見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。
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
