本頁使用了標題或全文手工轉換

IPv4

維基百科,自由的百科全書
前往: 導覽搜尋

網際網路協定版本4英語Internet Protocol version 4IPv4)是網際網路協定開發過程中的第四個修訂版本,也是此協定第一個被廣泛部署的版本。IPv4與IPv6均是標準化網際網路的核心部分。IPv4依然是使用最廣泛的網際網路協定版本,直到2011年,IPv6仍處在部署的初期。

IPv4在IETF於1981年9月發行的RFC 791中被描述,此RFC替換了於1980年1月發行的RFC 760

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

位址[編輯]

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

這些限制刺激了仍在開發早期的IPv6的部署,這也是唯一的長期解決方案。

位址格式[編輯]

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

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

格式 從點分十進制轉換
點分十進制 192.0.2.235 不適用
點分十六進制[1] 0xC0.0x00.0x02.0xEB 每個位元組被單獨轉換為十六進制
點分八進制[1] 0300.0000.0002.0353 每個位元組被單獨轉換為八進制
十六進制 0xC00002EB 將點分十六進制連在一起
十進制 3221226219 用十進制寫出的32位元整數
八進制 030000001353 用八進制寫出的32位元整數

此外,在點分格式中,每個位元組都可用任意的進制表達。如,192.0x00.0002.235是一種合法(但很不常用)的表示。

分配[編輯]

最初,一個IP位址被分成兩部分:網路識別碼在位址的高位位元組中,主機識別碼在剩下的部分中。這使得建立最多256個網路成為可能,但很快人們發現這樣是不夠的。

為了克服這個限制,在隨後出現的分類網路中,位址的高位位元組被重定義為網路的(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 5735
10.0.0.0/8 專用網路 RFC 1918
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 廣播 RFC 919

專用網路[編輯]

在IPv4所允許的大約四十億位址中,三個位址塊被保留作專用網路。這些位址塊在專用網路之外不可路由,專用網路之內的主機也不能直接與公共網路通訊。但透過網路位址轉換,他們即能做到後者。

下表展示了三個被保留作專用網路的位址塊(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隧道或專用網路。在網路上建立連線專用網路的隧道,在這種功能主機將封裝在網路上可以接受的報文,可以被送達另一端在附加的協定層被去掉,報文也被送達其原定的目的地。 此外封裝過的報文也可能被加密以保證其在網路上傳安全性。

鏈路本地位址[編輯]

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。在這種情況下,儘管可能帶來誤解,但192.168.1.255、192.168.2.255等位址可以被分配給主機。同理,192.168.0.0作為網路識別碼不能被分配,但192.168.1.0、192.168.2.0等都是可以的。

隨著CIDR的到來,廣播位址不一定總是以255結尾。比如,子網路203.0.113.16/28的廣播位址是203.0.113.31。

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

位址解析[編輯]

網際網路上的主機通常被其名字(如zh.wikipedia.org、www.berkeley.edu等)而不是IP位址識別,但IP報文的路由是由IP位址而不是這些名字決定的。這就需要將名字翻譯(解析)成位址。

域名系統(DNS)提供了這樣一個將名字轉換為位址和將位址轉換為名字的系統。與CIDR相像,DNS也有一個層級的結構,使不同的命名空間可被再委託給其它DNS伺服器。

域名系統經常被描述為電話系統中的黃頁:在那裡人們可以把名字和電話號碼對應起來。

位址空間枯竭[編輯]

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

一些市場力量也加快了IPv4位址的耗盡,如:

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

隨著IANA把最後5個位址塊分配給5個RIR,其主位址池在2011年2月3日耗盡。[3] 許多位址分配和消耗的模型都預測第一個耗盡位址的RIR會在2011年的下半年出現。[4]

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

網路位址轉換[編輯]

對位址的快速分配和其造成的位址短缺促成了許多有效應用位址的方法,其中一種就是網路位址轉換(NAT)。NAT裝置將一整個專有網路隱藏在一個公共IP位址「之後」。許多擁有很多用戶的ISP都依賴這一技術。

報文結構[編輯]

一份IP報文包含一個首部和一份資料,

首部[編輯]

IPv4報文的首部包含14個欄位,其中13個是必須的,第14個是可選的(在表中用紅色標出),並貼切地命名為:「選項」。首部中的欄位均以大端序包裝,在以下的圖表和討論中,最高有效位被標記為0,因此例如版本欄位實際上可在第一個位元組的前四高有效位中被找到。

位偏移 0–3 4–7 8–13 14-15 16–18 19–31
0 版本 首部長度 DSCP 顯式擁塞通告 全長
32 識別元 標誌 分片偏移
64 存活時間 協定 首部檢驗和
96 源IP位址
128 目的IP位址
160 選項(如首部長度>5)
160
or
192+
 
資料
 
版本
IP報文首部的第一個欄位是4位元版本欄位。對IPv4來說,這個欄位的值是4。
首部長度(IHL)
第二個欄位是4位元首部長度,說明首部有多少32位元長。由於IPv4首部可能包含數目不定的選項,這個欄位也用來確定資料的偏移量。這個欄位的最小值是5(RFC 791),最大值是15。
DiffServ(DSCP)
最初被定義為服務類型欄位,但被RFC 2474重定義為DiffServ。新的需要即時資料流的技術會應用這個欄位,一個例子是VoIP
顯式擁塞通告(ECN)
RFC 3168中定義,允許在不丟棄報文的同時通知對方網路擁塞的發生。ECN是一種可選的功能,僅當兩端都支援並希望使用,且底層網路支援時才被使用。
全長
這個16位元欄位定義了報文總長,包含首部和資料,單位為位元組。這個欄位的最小值是20(20位元組首部+0位元組資料),最大值是65,535。所有主機都必須支援最小576位元組的報文,但大多數現代主機支援更大的報文。有時候子網路會限制報文的大小,這時報文就必須被分片。
識別元
這個欄位主要被用來唯一地標識一個報文的所有分片。一些實驗性的工作建議將此欄位用於其它目的,例如增加報文跟蹤資訊以協助探測偽造的源位址。[5]
標誌
這個3位欄位用於控制和識別分片,它們是:
  • 位0:保留,必須為0;
  • 位1:禁止分片(DF);
  • 位2:更多分片(MF)。
如果DF標誌被設定但路由要求必須分片報文,此報文會被丟棄。這個標誌可被用於發往沒有能力組裝分片的主機。
當一個報文被分片,除了最後一片外的所有分片都設定MF標誌。不被分片的報文不設定MF標誌:它是它自己的最後一片。
分片偏移
這個13位欄位指明了每個分片相對於原始報文開頭的偏移量,以8位元組作單位。
存活時間(TTL)
這個8位元欄位避免報文在網際網路中永遠存在(例如陷入路由環路)。存活時間以秒為單位,但小於一秒的時間均向上取整到一秒。在現實中,這實際上成了一個跳數計數器:報文經過的每個路由器都將此欄位減一,當此欄位等於0時,報文不再向下一跳傳送並被丟棄。常規地,一份ICMP報文被發回報文傳送端說明其傳送的報文已被丟棄。這也是traceroute的核心原理。
協定
這個欄位定義了該報文資料區使用的協定。IANA維護著一份協定清單(最初由RFC 790定義)。
首部檢驗和
這個16位元檢驗和欄位用於對首部查錯。在每一跳,計算出的首部檢驗和必須與此欄位進行比對,如果不一致,此報文被丟棄。值得注意的是,資料區的錯誤留待上層協定處理——用戶資料報協定傳輸控制協定都有檢驗和欄位。
因為生存時間欄位在每一跳都會發生變化,意味著檢驗和必須被重新計算,RFC 1071這樣定義計算檢驗和的方法:
The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.
源位址
一個IPv4位址由四個位元組共32位元構成,此欄位的值是將每個位元組轉為二進制並拼在一起所得到的32位元值。
例如,10.9.8.7是00001010000010010000100000000111。
這個位址是報文的傳送端。但請注意,因為NAT的存在,這個位址並不總是報文的真實傳送端,因此發往此位址的報文會被送往NAT裝置,並由它被翻譯為真實的位址。
目的位址
與源位址格式相同,但指出報文的接收端。
選項
附加的首部欄位可能跟在目的位址之後,但這並不被經常使用。請注意首部長度欄位必須包括足夠的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封裝 -
89 開放式最短路徑優先 OSPF
132 流控制傳輸協定 SCTP

參見IP協定欄位值清單以獲得完整清單。

分片和組裝[編輯]

網際網路協定是整個網際網路架構的基礎,使得不同的網路間交換流量成為可能。其設計容納了物理條件不同的網路:其獨立於其下的鏈路層傳輸技術。不同的鏈路層經常不僅在傳輸速度上有差異,還在結構和影格尺寸上有不同,這一整個被MTU參數描述。為了實現IP橫越網路的角色,有必要實現一種自動調整傳輸單元大小的機制來適應其下的技術限制。這帶出了IP報文的分片。在IPv4中,這個功能被放置在網路層,並由IPv4路由器完成。

與此不同的是,下一代網際網路協定IPv6不要求路由器執行分片操作,而是將檢測路徑最大傳輸單元大小的任務交給了主機。

分片[編輯]

當一個裝置收到一個IP報文時,它閱讀其目的位址並決定要在哪個裝置上傳送它。裝置有與其關聯的MTU來決定其載荷的最大長度,如報文長度比MTU大,那麼裝置必須進行分片。

裝置將整個報文資料分成數片,每一片的長度都小於等於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)? 分片偏移量
首部 資料
1 2500 1 0
20 2480
2 2040 0 310
20 2020

現在,假設下一跳的MTU掉到1,500位元組,那麼每一個分片都會被再次分成兩片:

# 總長 更多分片(MF)? 分片偏移量
首部 資料
1 1500 1 0
20 1480
2 1020 1 185
20 1000
3 1500 1 310
20 1480
4 560 0 495
20 540

事實上,資料的長度被保留了下來——1480+1000+1480+540=4500,最後一片的偏移量(495)*8(位元組)加上資料——3960+540=4500也正好是資料長度。

值得注意的是,第3和4片是從原始第2片再次分片而來的。當一個裝置必須分片最後一片時,它必須在除分出的最後一片外的其它片上設定更多分片標誌。

組裝[編輯]

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

  • 更多分片標誌被設定;
  • 分片偏移量欄位不為0。

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

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

輔助協定[編輯]

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

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

參見[編輯]

參考文獻[編輯]

外部連結[編輯]

位址耗盡: