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