柚子快報激活碼778899分享：網(wǎng)絡(luò)網(wǎng)絡(luò)層之(2)ARP協(xié)議

http://yzkb.51969.com/

網(wǎng)絡(luò)網(wǎng)絡(luò)層之(2)ARP協(xié)議

Author：Once Day Date: 2024年4月1日

漫漫長路，有人對你笑過嘛…

全系列文檔可參考專欄：通信網(wǎng)絡(luò)技術(shù)_Once-Day的博客-CSDN博客。

參考文檔:

《TCP/IP詳解卷一》arp(8) - Linux manual page (man7.org)徹底搞懂系列之：ARP協(xié)議 - 知乎 (zhihu.com)RFC 826: An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware (rfc-editor.org)Linux 命令（199）—— arp 命令 - 騰訊云開發(fā)者社區(qū)-騰訊云 (tencent.com)

文章目錄

網(wǎng)絡(luò)網(wǎng)絡(luò)層之(2)ARP協(xié)議1.概述1.1 介紹1.2 常見實現(xiàn)1.3 相關(guān)RFC文檔

2.ARP幀格式2.2 免費(fèi)ARP2.3 ARP代理2.4 ARP欺騙和攻擊

3. RARP協(xié)議3.1 介紹3.2 分組格式3.3 RARP服務(wù)器

1.概述

1.1 介紹

地址解析協(xié)議，即ARP（Address Resolution Protocol），是根據(jù)IP地址獲取物理地址的一個TCP/IP協(xié)議，負(fù)責(zé)將IP地址映射為物理地址.

通常所說的以太網(wǎng)的網(wǎng)卡是不識別IP地址的，而是通過識別MAC地址來判斷該幀是否是給本機(jī)的。因此就需要提供一個機(jī)制根據(jù)目的主機(jī)的IP翻譯出它的MAC地址。

注意：像點(diǎn)對點(diǎn)鏈路(如PPP協(xié)議)是不需要MAC，也就不需要地址解析協(xié)議。

歷史上還有一個RARP協(xié)議 ，即逆地址解析協(xié)議，根據(jù)MAC解析出IP地址，現(xiàn)在已有DHCP協(xié)議代替。

主要的關(guān)注的幾點(diǎn)如下：

每臺主機(jī)都一個高速緩存ARP cache，里面有本局域網(wǎng)上各主機(jī)和路由的IP地址到硬件地址的映射表。 如果在高速緩存里找不到對應(yīng)IP，則發(fā)送ARP請求。 ARP是本地局域網(wǎng)廣播分組，包含本機(jī)IP、MAC以及目的IP。 接收者從該請求報文中提取出源主機(jī)的IP地址和物理地址的綁定，更新自己的ARP緩沖 。 對應(yīng)IP的接收者發(fā)回ARP應(yīng)答報文給請求者，包含IP和MAC，是單播分組。 高速緩存有一段生存時間，失效后將重新發(fā)送ARP請求。

ARP僅用于IPv4，IPv6使用鄰居發(fā)現(xiàn)協(xié)議，被合并進(jìn)了ICMPv6協(xié)議。

ARP在正常情況下，僅適用于廣播網(wǎng)絡(luò)，在非廣播網(wǎng)絡(luò)上，需要復(fù)雜的映射協(xié)議支持才行。

1.2 常見實現(xiàn)

主機(jī)發(fā)送信息時將包含目標(biāo)IP地址的ARP請求廣播到局域網(wǎng)絡(luò)上的所有主機(jī)，并接收返回消息，以此確定目標(biāo)的物理地址；收到返回消息后將該IP地址和物理地址存入本機(jī)ARP緩存中并保留一定時間，下次請求時直接查詢ARP緩存以節(jié)約資源。地址解析協(xié)議是建立在網(wǎng)絡(luò)中各個主機(jī)互相信任的基礎(chǔ)上的，局域網(wǎng)絡(luò)上的主機(jī)可以自主發(fā)送ARP應(yīng)答消息，其他主機(jī)收到應(yīng)答報文時不會檢測該報文的真實性就會將其記入本機(jī)ARP緩存；

網(wǎng)絡(luò)設(shè)備一般都有一個ARP緩存（ARP Cache），ARP緩存用來存放IP地址和MAC地址的關(guān)聯(lián)信息。在發(fā)送數(shù)據(jù)前，設(shè)備會先查找ARP緩存表。如果緩存表中存在對方設(shè)備的MAC地址，則直接采用該MAC地址來封裝幀，然后將幀發(fā)送出去。

如果緩存表中不存在相應(yīng)的信息，則通過發(fā)送ARP request報文來獲得它。學(xué)習(xí)到的IP地址和MAC地址的映射關(guān)系會被放入ARP緩存表中存放一段時間。

在有效期內(nèi)，設(shè)備可以直接從這個表中查找目的MAC地址來進(jìn)行數(shù)據(jù)封裝，而無需進(jìn)行ARP查詢。過了這段有效期，ARP表現(xiàn)會被自動刪除。如果目標(biāo)設(shè)備位于其他網(wǎng)絡(luò)則源設(shè)備會在ARP緩存表中查找網(wǎng)關(guān)的MAC地址，然后將數(shù)據(jù)發(fā)送給網(wǎng)關(guān)，網(wǎng)關(guān)再把數(shù)據(jù)轉(zhuǎn)發(fā)給目的設(shè)備。

ARP表項又分為動態(tài)ARP表項和靜態(tài)ARP表項。

動態(tài)ARP表項由ARP協(xié)議通過ARP報文自動生成和維護(hù)，可以被老化，可以被新的ARP報文更新，可以被靜態(tài)ARP表項覆蓋。靜態(tài)ARP表項通過手工配置和維護(hù)，不會被老化，不會被動態(tài)ARP表項覆蓋。直到重新啟動計算機(jī)為止。配置靜態(tài)ARP表項可以增加通信的安全性。靜態(tài)ARP表項可以限制和指定IP地址的設(shè)備通信時只使用指定的MAC地址，此時攻擊報文無法修改此表項的IP地址和MAC地址的映射關(guān)系，從而保護(hù)了本設(shè)備和指定設(shè)備間的正常通信。

Unix系統(tǒng)一般使用冒號分割MAC地址，而IEEE標(biāo)準(zhǔn)和其他操作系統(tǒng)傾向于使用短桿分割，如下:

Unix風(fēng)格 --> 00:11:22:33:44:55

IEEE風(fēng)格 --> 00-11-22-33-44-55

RFC1122文檔建議最大發(fā)送頻率是每秒一次，不同IP層協(xié)議的值不一樣，比如ICMP和UDP，通常為5秒，TCP協(xié)議為10秒。

1.3 相關(guān)RFC文檔

(1) RFC 826: An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware (rfc-editor.org)

RFC 826定義了地址解析協(xié)議（ARP），用于將網(wǎng)絡(luò)層協(xié)議地址（如IP地址）動態(tài)轉(zhuǎn)換為鏈路層地址（如以太網(wǎng)的MAC地址），以便在以太網(wǎng)硬件上進(jìn)行數(shù)據(jù)傳輸。

(2) RFC 903: A Reverse Address Resolution Protocol (rfc-editor.org)

RFC 903描述了一種協(xié)議，允許網(wǎng)絡(luò)主機(jī)在只知道其硬件地址（如物理網(wǎng)絡(luò)地址）的情況下，動態(tài)發(fā)現(xiàn)其協(xié)議地址（如IP地址），特別適用于無盤工作站等設(shè)備在啟動時獲取其網(wǎng)絡(luò)協(xié)議地址。

(3) RFC 1027: Using ARP to implement transparent subnet gateways (rfc-editor.org)

RFC 1027詳細(xì)描述了如何使用以太網(wǎng)地址解析協(xié)議（ARP）來實現(xiàn)透明子網(wǎng)網(wǎng)關(guān)，允許連接的子網(wǎng)上的主機(jī)在不知情的情況下進(jìn)行通信，主要采用了“代理ARP”技術(shù)。

(4) RFC 1122: Requirements for Internet Hosts - Communication Layers (rfc-editor.org)

RFC 1122是一份重要的文檔，它詳細(xì)定義了互聯(lián)網(wǎng)主機(jī)在通信協(xié)議層的要求，特別是鏈路層、IP層和傳輸層。這份文檔與其配套文檔RFC 1123一起，為互聯(lián)網(wǎng)主機(jī)軟件的實現(xiàn)提供了全面的指導(dǎo)和要求。

(5) RFC 2332: NBMA Next Hop Resolution Protocol (NHRP) (rfc-editor.org)

RFC 2332定義了NHRP協(xié)議的標(biāo)準(zhǔn)實現(xiàn)，該協(xié)議用于在NBMA網(wǎng)絡(luò)中進(jìn)行有效的下一跳解析，以支持多協(xié)議互聯(lián)網(wǎng)層通信。

(6) RFC 5227: IPv4 Address Conflict Detection (rfc-editor.org)

RFC 5227定義了IPv4地址沖突檢測機(jī)制，通過發(fā)送ARP探測和通告數(shù)據(jù)包來預(yù)防和識別同一網(wǎng)絡(luò)上的兩個主機(jī)使用相同IP地址的情況，并提供了解決沖突的指導(dǎo)。

(7) RFC 5494: IANA Allocation Guidelines for the Address Resolution Protocol (ARP) (rfc-editor.org)

RFC 5494定義了用于地址解析協(xié)議（ARP）的IANA分配指南，包括硬件地址空間、協(xié)議地址空間和操作碼的分配規(guī)則，并為實驗?zāi)康念A(yù)留了一些數(shù)值。

2.ARP幀格式

目的地址、源地址、長度/類型等字段是以太網(wǎng)頭部，這部分和其他以太網(wǎng)幀保持一致。可參考以下文檔：

網(wǎng)絡(luò)之以太網(wǎng)_ Once_day的博客-CSDN博客

下面看一個實際的ARP包(使用WireShark軟件抓包)：

可以看到，對于request請求，目的MAC地址是ff:ff:ff:ff:ff:ff，表示廣播地址，在同一廣播域的所有以太網(wǎng)口都可以接收這些幀。對于ARP請求和應(yīng)答，長度/類型字段值必須為0x0806。

數(shù)據(jù)部分存儲的就是ARP請求或者應(yīng)答消息了：

硬件類型：即硬件地址的類型，可參考Linux內(nèi)核源碼include/uapi/linux/if_arp.h. 協(xié)議類型：指出映射的協(xié)議地址類型，可參考Linux內(nèi)核源碼include/uapi/linux/if_ether.h Line:41 硬件/協(xié)議大?。褐赋鲇布刂泛蛥f(xié)議地址的字節(jié)數(shù)。 操作類型(Opcode)：指出操作的類型，如下： #define ARPOP_REQUEST 1 /* ARP request */

#define ARPOP_REPLY 2 /* ARP reply */

#define ARPOP_RREQUEST 3 /* RARP request */

#define ARPOP_RREPLY 4 /* RARP reply */

#define ARPOP_InREQUEST 8 /* InARP request */

#define ARPOP_InREPLY 9 /* InARP reply */

#define ARPOP_NAK 10 /* (ATM)ARP NAK */

后面緊跟著的就是發(fā)送方/接收方的硬件地址+協(xié)議地址。常見的以太網(wǎng)+IP協(xié)議，ARP包大小為42 Bytes。

ARP請求最大頻率最好不要超過1秒1個，并且根據(jù)不同協(xié)議可以進(jìn)一步降低請求頻率。

2.2 免費(fèi)ARP

免費(fèi) ARP（Gratuitous ARP）包是一種特殊的ARP請求，一臺主機(jī)發(fā)送ARP請求以獲取自己的地址。

免費(fèi)ARP報文與普通ARP請求報文的區(qū)別在于報文中的目標(biāo)IP地址。普通ARP報文中的目標(biāo)IP地址是其他主機(jī)的IP地址；而免費(fèi)ARP的請求報文中，目標(biāo)IP地址是自己的IP地址。

有兩個作用：

確定是否有其他主機(jī)配置了相同的IPv4地址。更新其他主機(jī)上的ARP緩存。

在RFC中描述了一種**IPv4地址沖突檢測(ACD)**機(jī)制，可用來檢測IPv4地址沖突情況。

ACD定義了兩種ARP分組：

ARP探測分組，是一個ARP請求，其中發(fā)送方協(xié)議地址被設(shè)置為0，目的協(xié)議地址為候選IPv4地址。ARP通告分組，發(fā)送方協(xié)議地址和目的地址都為候選IPv4地址。

2.3 ARP代理

當(dāng)局域網(wǎng)內(nèi)部主機(jī)發(fā)起跨網(wǎng)段的ARP請求時，出口路由器/網(wǎng)關(guān)設(shè)備將自身MAC地址回復(fù)該請求時，這個過程稱為代理ARP，也被稱為混雜ARP（Promiscuous ARP）。

如上圖所示，PC1和PC2位于兩個網(wǎng)段，PC1發(fā)送ARP請求PC2的硬件地址，此時Router回復(fù)該ARP請求，并且將MAC地址填為自身地址，然后將PC1發(fā)給PC2的數(shù)據(jù)包再轉(zhuǎn)發(fā)給PC2。

PC1和PC2看起來互相隱身，可以屏蔽復(fù)雜網(wǎng)絡(luò)拓?fù)洹?/p>

2.4 ARP欺騙和攻擊

ARP的解析是依賴于主機(jī)內(nèi)部的高速緩存，如果惡意主機(jī)發(fā)送ARP應(yīng)答或者免費(fèi)ARP等，那么就會返回一個錯誤的MAC地址，從而導(dǎo)致數(shù)據(jù)報文發(fā)送到錯誤主機(jī)上。

黑客向?qū)Ψ接嬎銠C(jī)不斷發(fā)送有欺詐性質(zhì)的ARP數(shù)據(jù)包，數(shù)據(jù)包內(nèi)包含有與當(dāng)前設(shè)備重復(fù)的Mac地址，使對方在回應(yīng)報文時，由于簡單的地址重復(fù)錯誤而導(dǎo)致不能進(jìn)行正常的網(wǎng)絡(luò)通信，或者如果不及時處理，便會造成網(wǎng)絡(luò)通道阻塞、網(wǎng)絡(luò)設(shè)備的承載過重、網(wǎng)絡(luò)的通訊質(zhì)量不佳等情況。

3. RARP協(xié)議

3.1 介紹

在計算機(jī)網(wǎng)絡(luò)的世界里，RARP（Reverse Address Resolution Protocol，反向地址解析協(xié)議）曾是一個重要的網(wǎng)絡(luò)協(xié)議，它的主要作用是允許物理機(jī)在局域網(wǎng)內(nèi)的網(wǎng)絡(luò)活動開始時，通過其物理地址（MAC地址）來查詢網(wǎng)絡(luò)地址（比如IPv4地址）。這個過程有點(diǎn)像在一個大型的公司樓里尋找某個人的辦公室，知道這個人的名字（物理地址），但是需要查找他的辦公室號碼（網(wǎng)絡(luò)地址）。

RARP的工作機(jī)制比較簡單：當(dāng)一個網(wǎng)絡(luò)設(shè)備(通常是無盤系統(tǒng))啟動時，它知道自己的物理地址，但不知道自己的IP地址。它會在局域網(wǎng)內(nèi)廣播一個RARP請求，請求中包含它的物理地址。網(wǎng)絡(luò)中的RARP服務(wù)器收到請求后，會查找相應(yīng)的表項，找到與物理地址對應(yīng)的IP地址，并將這個信息發(fā)送回請求的設(shè)備。這樣，設(shè)備就獲得了自己的IP地址，可以進(jìn)一步與網(wǎng)絡(luò)中的其他設(shè)備進(jìn)行通信。

然而，隨著技術(shù)的發(fā)展，RARP協(xié)議逐漸被一個更加強(qiáng)大的協(xié)議取代了，這個協(xié)議就是DHCP（Dynamic Host Configuration Protocol，動態(tài)主機(jī)配置協(xié)議）。DHCP不僅可以提供IP地址，還能配置子網(wǎng)掩碼、默認(rèn)網(wǎng)關(guān)、DNS服務(wù)器地址等信息，使得網(wǎng)絡(luò)設(shè)備的配置更加自動化和智能化。

盡管RARP現(xiàn)在已經(jīng)不太常用了，但它在歷史上的作用不容忽視。它是網(wǎng)絡(luò)啟動和自動配置過程中的一個關(guān)鍵步驟，是那個網(wǎng)絡(luò)技術(shù)發(fā)展初期的一個重要創(chuàng)新。在一些特定的舊系統(tǒng)或者遺留設(shè)備中，可能還會遇到RARP協(xié)議的身影，但在現(xiàn)代網(wǎng)絡(luò)架構(gòu)中，它已經(jīng)基本被更先進(jìn)的技術(shù)所替代。在網(wǎng)絡(luò)協(xié)議的長河中，RARP像是一塊墊腳石，幫助我們跨向了自動化網(wǎng)絡(luò)配置的新紀(jì)元。

3.2 分組格式

RARP分組的格式與ARP分組基本一致。它們之間主要的差別是RARP請求或應(yīng)答的幀類型代碼為0x8035，而且RARP請求的操作代碼為3，應(yīng)答操作代碼為4。

和ARP一樣，RARP請求以廣播方式傳送，而RARP應(yīng)答一般是單播(unicast)傳送的。

3.3 RARP服務(wù)器

在過去，RARP服務(wù)器通常是網(wǎng)絡(luò)中的一臺計算機(jī)，它會運(yùn)行RARP服務(wù)軟件。這臺服務(wù)器負(fù)責(zé)響應(yīng)來自客戶端的RARP請求，并為它們提供所需的網(wǎng)絡(luò)地址信息。RARP服務(wù)器內(nèi)部維護(hù)一個表格，這個表格將每個物理地址（MAC地址）映射到一個IP地址。當(dāng)服務(wù)器接收到一個廣播的RARP請求時，它會查詢這個表，找到與請求中的物理地址對應(yīng)的IP地址，然后將這個信息封裝在RARP響應(yīng)中返回給請求者。

通常，這個映射表是由網(wǎng)絡(luò)管理員手動維護(hù)的。在網(wǎng)絡(luò)規(guī)模較小，設(shè)備較少時，這種方法是可行的。但隨著網(wǎng)絡(luò)規(guī)模的增大，手動維護(hù)映射表變得越來越不現(xiàn)實，這也是RARP的一個局限性。這種方式要求網(wǎng)絡(luò)管理員對網(wǎng)絡(luò)中的每個設(shè)備都有詳細(xì)的記錄，并且每當(dāng)有設(shè)備變動時，都需要更新映射表，這對于管理者來說是一項繁重的工作。

另外，RARP的一個局限性是它只能提供IP地址，而不能像DHCP那樣提供其他網(wǎng)絡(luò)配置信息，如子網(wǎng)掩碼、默認(rèn)網(wǎng)關(guān)和DNS服務(wù)器地址等。這意味著網(wǎng)絡(luò)中的設(shè)備需要通過其他方式來獲取這些額外的配置信息，這降低了網(wǎng)絡(luò)配置的自動化程度。

還有，RARP協(xié)議本身不具備跨越不同網(wǎng)絡(luò)的能力，這意味著每個局域網(wǎng)都需要單獨(dú)的RARP服務(wù)器。在大規(guī)模網(wǎng)絡(luò)中，這會導(dǎo)致大量的資源投入和管理復(fù)雜性。

和ARP協(xié)議不同，RARP無法集成到內(nèi)核中(需要讀取磁盤文件，通常都由用戶空間實現(xiàn))，但ARP通常可以作為TCP/IP棧的一個組成部分。當(dāng)每個網(wǎng)絡(luò)有多個RARP服務(wù)器時，受限于廣播報文形式，會存在多個回復(fù)應(yīng)答，增加以太網(wǎng)發(fā)生沖突的概率。

柚子快報激活碼778899分享：網(wǎng)絡(luò)網(wǎng)絡(luò)層之(2)ARP協(xié)議

http://yzkb.51969.com/

相關(guān)鏈接