鏈路本地地址
鏈路本地地址(英語:Link-local address),又稱連結本地位址、本地鏈路位址,是計算機網絡中一類特殊的地址,它僅供於在網段,或廣播域中的主機相互通信使用。這類主機通常不需要外部互聯網服務,僅有主機間相互通訊的需求。
地址分配
編輯對於使用互聯網協議 (IP)的網絡,經常使用無狀態地址自動配置。在IPv4中通常只用於分配在網絡接口沒有外部的、有狀態的IP地址情況下,如動態主機配置協議 (DHCP),或當其他的配置方法無效時。 在IPv6[1]中鏈路本地地址是強制性的。
網絡中的應用層程序進程相互通訊時一般假設其地址是穩定的、可路由的、唯一的地址,但在由於鏈路本地地址的隨機分配性質,可能會對應用層的進程帶來麻煩。儘管一些應用層程序可以同時兼容鏈路本地地址和一般可路由地址,但是不建議在接口上同時配置這兩種地址[2]。由於鏈路本地地址一般隨機自動分配,所以在整個通訊期間必須持續監測和處理衝突。
使用該類地址重要的守則之一是,禁止手動分配或者由DHCP服務器進行分配,儘管在一個小型網絡中可以人為保證地址的不重複性,但是手動分配的地址無法遵守自動配置檢測和處理的相關規則,在DHCP環境下對地址要求使用ARP或者ICMP Echo請求來確定地址的可用性,但這並不是強制性的。所以在需要配置鏈路本地地址的環境中應該讓主機自動配置該類地址。如果希望手動分配或者使用DHCP服務則應該使用在RFC1918 (頁面存檔備份,存於網際網路檔案館)中定義的私有地址。
IPv4
編輯地址選擇
編輯在RFC 3927中,互聯網工程任務組保留了地址塊169.254.0.0/16。 從169.254.1.0到169.254.254.255的地址可以用於鏈路本地地址的分配。 第一塊256個地址(169.254.0.0/24)和最後一塊256地址(169.254.255.0/24)保留待將來使用,不會被分配給主機[3]。網絡主機在可用的地址範圍內(169.254.1.0 - 169.254.254.255)隨機選擇一個地址,並使用地址解析協議(ARP)確定該地址未被使用。 如果收到ARP回復,表示IP地址已經被使用,將重新隨機選擇IP地址並重複該過程直到選定的IP可用。
隨機選擇實際上是使用偽隨機發生器來生成不同的結果[2],所以必須選擇不同的種子來生成,如MAC地址這種唯一值。而且由於MAC地址存儲在網卡中且是固定的,所以用隨機數產生的本地鏈路地址也基本是固定的,這種特性使得地址出現衝突的可能性降低,並且帶來方便性。
在具有永久存儲設備的主機中,每個接口鏈路本地地址可能被存儲,在下次啟動時這些地址應該被優先考慮[2]。
當主機用ARP確認地址可使用後,還要向網絡廣播ARP通告向其他主機說明自己的地址,目的是為了確保鏈路上的其他主機不會有其他以前可能使用過相同地址的主機遺留的ARP緩存條目。
地址衝突檢測
編輯當網絡中的主機收到一個ARP並且查詢的IP地址與接口相同但硬件地址不同時便視為衝突,主機必須選擇以下兩種處理方式之一:
- 重新配置新IP。
- 回復發送單播ARP給發送方,使用自己的IP和硬件地址,保持自己的IP。
主機必須對出現衝突的ARP進行相應處理。在第二種處理方式中,如果不是第一次出現衝突並且在DEFEND_INTERVAL時間內則需要立即放棄衝突的IP重新選擇其他地址[2]。
當在接口上配置了全局可路由地址或專用地址,新地址的使用一般應該優先於鏈路本地地址,但主機之間仍然可以通過鏈路本地地址進行通信。
地址使用和轉發規則
編輯在主機的同一個接口中允許擁有多個IP地址,在已經配置過本地鏈路地址的接口上同樣允許存在可路由地址,並且這兩個地址都可用於通訊。可路由地址優先於本地鏈路地址。
在主機使用本地鏈路地址時,必須用ARP確定目的主機的鏈路段,這有時被稱為「ARP一切」。
路由器等設備是禁止轉發此類地址(目的地址)的數據包的。使用鏈路本地地址的數據包的TTL值一般被設置為1,但在某些情況下可能是其他值。
由於鏈路本地地址被禁止轉發到其他網段,以此類地址為目的地址的數據包將只會在本地網段或廣播域傳播,所以在這類的地址中是禁止劃分子網的。但當主機同時擁有鏈路本地地址和可路由地址時,可以使用可路由地址來與外界主機通訊。
IPv6
編輯在IPv6下,地址塊fe80::/10被保留作鏈路本地地址。
參見
編輯參考文獻
編輯- ^ Hinden, R.; Deering, S., RFC 4291: IP Version 6 Addressing Architecture, Fremont, CA: IETF, February 2006 [2017-12-11], (原始內容存檔於2017-12-15).
- ^ 2.0 2.1 2.2 2.3 RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses, S. Cheshire, B. Aboba, E. Guttman, The Internet Society (May 2005)
- ^ RFC 3927 section 2.1