柚子快報激活碼778899分享:網(wǎng)絡網(wǎng)絡層之(2)ARP協(xié)議
柚子快報激活碼778899分享:網(wǎng)絡網(wǎng)絡層之(2)ARP協(xié)議
網(wǎng)絡網(wǎng)絡層之(2)ARP協(xié)議
Author:Once Day Date: 2024年4月1日
漫漫長路,有人對你笑過嘛…
全系列文檔可參考專欄:通信網(wǎng)絡技術_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)絡網(wǎng)絡層之(2)ARP協(xié)議1.概述1.1 介紹1.2 常見實現(xiàn)1.3 相關RFC文檔
2.ARP幀格式2.2 免費ARP2.3 ARP代理2.4 ARP欺騙和攻擊
3. RARP協(xié)議3.1 介紹3.2 分組格式3.3 RARP服務器
1.概述
1.1 介紹
地址解析協(xié)議,即ARP(Address Resolution Protocol),是根據(jù)IP地址獲取物理地址的一個TCP/IP協(xié)議,負責將IP地址映射為物理地址.
通常所說的以太網(wǎng)的網(wǎng)卡是不識別IP地址的,而是通過識別MAC地址來判斷該幀是否是給本機的。因此就需要提供一個機制根據(jù)目的主機的IP翻譯出它的MAC地址。
注意:像點對點鏈路(如PPP協(xié)議)是不需要MAC,也就不需要地址解析協(xié)議。
歷史上還有一個RARP協(xié)議 ,即逆地址解析協(xié)議,根據(jù)MAC解析出IP地址,現(xiàn)在已有DHCP協(xié)議代替。
主要的關注的幾點如下:
每臺主機都一個高速緩存ARP cache,里面有本局域網(wǎng)上各主機和路由的IP地址到硬件地址的映射表。 如果在高速緩存里找不到對應IP,則發(fā)送ARP請求。 ARP是本地局域網(wǎng)廣播分組,包含本機IP、MAC以及目的IP。 接收者從該請求報文中提取出源主機的IP地址和物理地址的綁定,更新自己的ARP緩沖 。 對應IP的接收者發(fā)回ARP應答報文給請求者,包含IP和MAC,是單播分組。 高速緩存有一段生存時間,失效后將重新發(fā)送ARP請求。
ARP僅用于IPv4,IPv6使用鄰居發(fā)現(xiàn)協(xié)議,被合并進了ICMPv6協(xié)議。
ARP在正常情況下,僅適用于廣播網(wǎng)絡,在非廣播網(wǎng)絡上,需要復雜的映射協(xié)議支持才行。
1.2 常見實現(xiàn)
主機發(fā)送信息時將包含目標IP地址的ARP請求廣播到局域網(wǎng)絡上的所有主機,并接收返回消息,以此確定目標的物理地址;收到返回消息后將該IP地址和物理地址存入本機ARP緩存中并保留一定時間,下次請求時直接查詢ARP緩存以節(jié)約資源。地址解析協(xié)議是建立在網(wǎng)絡中各個主機互相信任的基礎上的,局域網(wǎng)絡上的主機可以自主發(fā)送ARP應答消息,其他主機收到應答報文時不會檢測該報文的真實性就會將其記入本機ARP緩存;
網(wǎng)絡設備一般都有一個ARP緩存(ARP Cache),ARP緩存用來存放IP地址和MAC地址的關聯(lián)信息。在發(fā)送數(shù)據(jù)前,設備會先查找ARP緩存表。如果緩存表中存在對方設備的MAC地址,則直接采用該MAC地址來封裝幀,然后將幀發(fā)送出去。
如果緩存表中不存在相應的信息,則通過發(fā)送ARP request報文來獲得它。學習到的IP地址和MAC地址的映射關系會被放入ARP緩存表中存放一段時間。
在有效期內(nèi),設備可以直接從這個表中查找目的MAC地址來進行數(shù)據(jù)封裝,而無需進行ARP查詢。過了這段有效期,ARP表現(xiàn)會被自動刪除。如果目標設備位于其他網(wǎng)絡則源設備會在ARP緩存表中查找網(wǎng)關的MAC地址,然后將數(shù)據(jù)發(fā)送給網(wǎng)關,網(wǎng)關再把數(shù)據(jù)轉(zhuǎn)發(fā)給目的設備。
ARP表項又分為動態(tài)ARP表項和靜態(tài)ARP表項。
動態(tài)ARP表項由ARP協(xié)議通過ARP報文自動生成和維護,可以被老化,可以被新的ARP報文更新,可以被靜態(tài)ARP表項覆蓋。靜態(tài)ARP表項通過手工配置和維護,不會被老化,不會被動態(tài)ARP表項覆蓋。直到重新啟動計算機為止。配置靜態(tài)ARP表項可以增加通信的安全性。靜態(tài)ARP表項可以限制和指定IP地址的設備通信時只使用指定的MAC地址,此時攻擊報文無法修改此表項的IP地址和MAC地址的映射關系,從而保護了本設備和指定設備間的正常通信。
Unix系統(tǒng)一般使用冒號分割MAC地址,而IEEE標準和其他操作系統(tǒng)傾向于使用短桿分割,如下:
Unix風格 --> 00:11:22:33:44:55
IEEE風格 --> 00-11-22-33-44-55
RFC1122文檔建議最大發(fā)送頻率是每秒一次,不同IP層協(xié)議的值不一樣,比如ICMP和UDP,通常為5秒,TCP協(xié)議為10秒。
1.3 相關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)絡層協(xié)議地址(如IP地址)動態(tài)轉(zhuǎn)換為鏈路層地址(如以太網(wǎng)的MAC地址),以便在以太網(wǎng)硬件上進行數(shù)據(jù)傳輸。
(2) RFC 903: A Reverse Address Resolution Protocol (rfc-editor.org)
RFC 903描述了一種協(xié)議,允許網(wǎng)絡主機在只知道其硬件地址(如物理網(wǎng)絡地址)的情況下,動態(tài)發(fā)現(xiàn)其協(xié)議地址(如IP地址),特別適用于無盤工作站等設備在啟動時獲取其網(wǎng)絡協(xié)議地址。
(3) RFC 1027: Using ARP to implement transparent subnet gateways (rfc-editor.org)
RFC 1027詳細描述了如何使用以太網(wǎng)地址解析協(xié)議(ARP)來實現(xiàn)透明子網(wǎng)網(wǎng)關,允許連接的子網(wǎng)上的主機在不知情的情況下進行通信,主要采用了“代理ARP”技術。
(4) RFC 1122: Requirements for Internet Hosts - Communication Layers (rfc-editor.org)
RFC 1122是一份重要的文檔,它詳細定義了互聯(lián)網(wǎng)主機在通信協(xié)議層的要求,特別是鏈路層、IP層和傳輸層。這份文檔與其配套文檔RFC 1123一起,為互聯(lián)網(wǎng)主機軟件的實現(xiàn)提供了全面的指導和要求。
(5) RFC 2332: NBMA Next Hop Resolution Protocol (NHRP) (rfc-editor.org)
RFC 2332定義了NHRP協(xié)議的標準實現(xiàn),該協(xié)議用于在NBMA網(wǎng)絡中進行有效的下一跳解析,以支持多協(xié)議互聯(lián)網(wǎng)層通信。
(6) RFC 5227: IPv4 Address Conflict Detection (rfc-editor.org)
RFC 5227定義了IPv4地址沖突檢測機制,通過發(fā)送ARP探測和通告數(shù)據(jù)包來預防和識別同一網(wǎng)絡上的兩個主機使用相同IP地址的情況,并提供了解決沖突的指導。
(7) RFC 5494: IANA Allocation Guidelines for the Address Resolution Protocol (ARP) (rfc-editor.org)
RFC 5494定義了用于地址解析協(xié)議(ARP)的IANA分配指南,包括硬件地址空間、協(xié)議地址空間和操作碼的分配規(guī)則,并為實驗目的預留了一些數(shù)值。
2.ARP幀格式
目的地址、源地址、長度/類型等字段是以太網(wǎng)頭部,這部分和其他以太網(wǎng)幀保持一致??蓞⒖家韵挛臋n:
網(wǎng)絡之以太網(wǎng)_ Once_day的博客-CSDN博客
下面看一個實際的ARP包(使用WireShark軟件抓包):
可以看到,對于request請求,目的MAC地址是ff:ff:ff:ff:ff:ff,表示廣播地址,在同一廣播域的所有以太網(wǎng)口都可以接收這些幀。對于ARP請求和應答,長度/類型字段值必須為0x0806。
數(shù)據(jù)部分存儲的就是ARP請求或者應答消息了:
硬件類型:即硬件地址的類型,可參考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é)議可以進一步降低請求頻率。
2.2 免費ARP
免費 ARP(Gratuitous ARP)包是一種特殊的ARP請求,一臺主機發(fā)送ARP請求以獲取自己的地址。
免費ARP報文與普通ARP請求報文的區(qū)別在于報文中的目標IP地址。普通ARP報文中的目標IP地址是其他主機的IP地址;而免費ARP的請求報文中,目標IP地址是自己的IP地址。
有兩個作用:
確定是否有其他主機配置了相同的IPv4地址。更新其他主機上的ARP緩存。
在RFC中描述了一種**IPv4地址沖突檢測(ACD)**機制,可用來檢測IPv4地址沖突情況。
ACD定義了兩種ARP分組:
ARP探測分組,是一個ARP請求,其中發(fā)送方協(xié)議地址被設置為0,目的協(xié)議地址為候選IPv4地址。ARP通告分組,發(fā)送方協(xié)議地址和目的地址都為候選IPv4地址。
2.3 ARP代理
當局域網(wǎng)內(nèi)部主機發(fā)起跨網(wǎng)段的ARP請求時,出口路由器/網(wǎng)關設備將自身MAC地址回復該請求時,這個過程稱為代理ARP,也被稱為混雜ARP(Promiscuous ARP)。
如上圖所示,PC1和PC2位于兩個網(wǎng)段,PC1發(fā)送ARP請求PC2的硬件地址,此時Router回復該ARP請求,并且將MAC地址填為自身地址,然后將PC1發(fā)給PC2的數(shù)據(jù)包再轉(zhuǎn)發(fā)給PC2。
PC1和PC2看起來互相隱身,可以屏蔽復雜網(wǎng)絡拓撲。
2.4 ARP欺騙和攻擊
ARP的解析是依賴于主機內(nèi)部的高速緩存,如果惡意主機發(fā)送ARP應答或者免費ARP等,那么就會返回一個錯誤的MAC地址,從而導致數(shù)據(jù)報文發(fā)送到錯誤主機上。
黑客向?qū)Ψ接嬎銠C不斷發(fā)送有欺詐性質(zhì)的ARP數(shù)據(jù)包,數(shù)據(jù)包內(nèi)包含有與當前設備重復的Mac地址,使對方在回應報文時,由于簡單的地址重復錯誤而導致不能進行正常的網(wǎng)絡通信,或者如果不及時處理,便會造成網(wǎng)絡通道阻塞、網(wǎng)絡設備的承載過重、網(wǎng)絡的通訊質(zhì)量不佳等情況。
3. RARP協(xié)議
3.1 介紹
在計算機網(wǎng)絡的世界里,RARP(Reverse Address Resolution Protocol,反向地址解析協(xié)議)曾是一個重要的網(wǎng)絡協(xié)議,它的主要作用是允許物理機在局域網(wǎng)內(nèi)的網(wǎng)絡活動開始時,通過其物理地址(MAC地址)來查詢網(wǎng)絡地址(比如IPv4地址)。這個過程有點像在一個大型的公司樓里尋找某個人的辦公室,知道這個人的名字(物理地址),但是需要查找他的辦公室號碼(網(wǎng)絡地址)。
RARP的工作機制比較簡單:當一個網(wǎng)絡設備(通常是無盤系統(tǒng))啟動時,它知道自己的物理地址,但不知道自己的IP地址。它會在局域網(wǎng)內(nèi)廣播一個RARP請求,請求中包含它的物理地址。網(wǎng)絡中的RARP服務器收到請求后,會查找相應的表項,找到與物理地址對應的IP地址,并將這個信息發(fā)送回請求的設備。這樣,設備就獲得了自己的IP地址,可以進一步與網(wǎng)絡中的其他設備進行通信。
然而,隨著技術的發(fā)展,RARP協(xié)議逐漸被一個更加強大的協(xié)議取代了,這個協(xié)議就是DHCP(Dynamic Host Configuration Protocol,動態(tài)主機配置協(xié)議)。DHCP不僅可以提供IP地址,還能配置子網(wǎng)掩碼、默認網(wǎng)關、DNS服務器地址等信息,使得網(wǎng)絡設備的配置更加自動化和智能化。
盡管RARP現(xiàn)在已經(jīng)不太常用了,但它在歷史上的作用不容忽視。它是網(wǎng)絡啟動和自動配置過程中的一個關鍵步驟,是那個網(wǎng)絡技術發(fā)展初期的一個重要創(chuàng)新。在一些特定的舊系統(tǒng)或者遺留設備中,可能還會遇到RARP協(xié)議的身影,但在現(xiàn)代網(wǎng)絡架構中,它已經(jīng)基本被更先進的技術所替代。在網(wǎng)絡協(xié)議的長河中,RARP像是一塊墊腳石,幫助我們跨向了自動化網(wǎng)絡配置的新紀元。
3.2 分組格式
RARP分組的格式與ARP分組基本一致。它們之間主要的差別是RARP請求或應答的幀類型代碼為0x8035,而且RARP請求的操作代碼為3,應答操作代碼為4。
和ARP一樣,RARP請求以廣播方式傳送,而RARP應答一般是單播(unicast)傳送的。
3.3 RARP服務器
在過去,RARP服務器通常是網(wǎng)絡中的一臺計算機,它會運行RARP服務軟件。這臺服務器負責響應來自客戶端的RARP請求,并為它們提供所需的網(wǎng)絡地址信息。RARP服務器內(nèi)部維護一個表格,這個表格將每個物理地址(MAC地址)映射到一個IP地址。當服務器接收到一個廣播的RARP請求時,它會查詢這個表,找到與請求中的物理地址對應的IP地址,然后將這個信息封裝在RARP響應中返回給請求者。
通常,這個映射表是由網(wǎng)絡管理員手動維護的。在網(wǎng)絡規(guī)模較小,設備較少時,這種方法是可行的。但隨著網(wǎng)絡規(guī)模的增大,手動維護映射表變得越來越不現(xiàn)實,這也是RARP的一個局限性。這種方式要求網(wǎng)絡管理員對網(wǎng)絡中的每個設備都有詳細的記錄,并且每當有設備變動時,都需要更新映射表,這對于管理者來說是一項繁重的工作。
另外,RARP的一個局限性是它只能提供IP地址,而不能像DHCP那樣提供其他網(wǎng)絡配置信息,如子網(wǎng)掩碼、默認網(wǎng)關和DNS服務器地址等。這意味著網(wǎng)絡中的設備需要通過其他方式來獲取這些額外的配置信息,這降低了網(wǎng)絡配置的自動化程度。
還有,RARP協(xié)議本身不具備跨越不同網(wǎng)絡的能力,這意味著每個局域網(wǎng)都需要單獨的RARP服務器。在大規(guī)模網(wǎng)絡中,這會導致大量的資源投入和管理復雜性。
和ARP協(xié)議不同,RARP無法集成到內(nèi)核中(需要讀取磁盤文件,通常都由用戶空間實現(xiàn)),但ARP通常可以作為TCP/IP棧的一個組成部分。當每個網(wǎng)絡有多個RARP服務器時,受限于廣播報文形式,會存在多個回復應答,增加以太網(wǎng)發(fā)生沖突的概率。
柚子快報激活碼778899分享:網(wǎng)絡網(wǎng)絡層之(2)ARP協(xié)議
相關鏈接
本文內(nèi)容根據(jù)網(wǎng)絡資料整理,出于傳遞更多信息之目的,不代表金鑰匙跨境贊同其觀點和立場。
轉(zhuǎn)載請注明,如有侵權,聯(lián)系刪除。