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