Loading AI tools
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的部署。
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。
字段 | 長度(位) | 描述 |
---|---|---|
備份 | 1 | 當此選項需要被備份到所有分片中時,設為1。 |
類 | 2 | 常規的選項類別,0為「控制」,2為「查錯和措施」,1和3保留。 |
數字 | 5 | 指明一個選項。 |
長度 | 8 | 指明整個選項的長度,對於簡單的選項此字段可能不存在。 |
數據 | 可變 | 選項相關數據,對於簡單的選項此字段可能不存在。 |
數據字段不是首部的一部分,因此並不被包含在首部檢驗和中。數據的格式在協議首部字段中被指明,並可以是任意的傳輸層協議。
一些常見協議的協議字段值被列在下面:
參見IP協議號列表以獲得完整列表。
互聯網協議(IP)是整個互聯網架構的基礎,可以支持不同的物理層網絡,即IP層獨立於鏈路層傳輸技術。不同的鏈路層不僅在傳輸速度上有差異,還在幀結構和大小上有所不同,不同MTU參數描述了數據幀的大小。為了實現IP數據包能夠使用不同的鏈路層技術,需要將IP數據包變成適合鏈路層的數據格式,IP報文的分片即是IP數據包為了滿足鏈路層的數據大小而進行的分割。
在IPv6不要求路由器執行分片操作,而是將檢測路徑最大傳輸單元大小的任務交給了主機。
當設備收到IP報文時,分析其目的地址並決定要在哪個鏈路上發送它。MTU決定了數據載荷的最大長度,如IP報文長度比MTU大,則IP數據包必須進行分片。每一片的長度都小於等於MTU減去IP首部長度。接下來每一片均被放到獨立的IP報文中,並進行如下修改:
例如,對於一個長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報文的下列項目之一為真時:
它便知道這個報文已被分片,並隨即將數據、標識符字段、分片偏移量和更多分片標誌一起儲存起來。
當接受者收到了更多分片標誌未被設置的分片時,它便知道原始數據載荷的總長。一旦它收齊了所有的分片,它便可以將所有片按照正確的順序(通過分片偏移量)組裝起來,並交給上層協議棧。
互聯網協議定義並激活了網絡層,它使用一個邏輯地址系統。IP地址並不以任何永久的方式綁定到硬件,而且事實上一個網絡接口可以有許多IP地址。為了正確地交付一份報文,主機和路由器需要其它機制來識別設備接口和IP地址之間的關聯。地址解析協議(ARP)為IPv4執行這種IP地址到物理地址(MAC地址)的轉換。
此外,反向操作有時候也是必須的,比如,一台主機在啟動時需要知道自己的IP地址(除非地址已經被管理員預先設置)。目前被用於這一用途的協議有動態主機設置協議(DHCP)、引導協議(BOOTP)和比較不常用的RARP。
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.