鏈路本地地址
鏈路本地地址(英語: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