正文共：13333 字 3 图，预估阅读时间：9 分钟
RFC3927：Dynamic Configuration of IPv4 Link-Local Addresses，May 2005本文档为互联网社区指定了一个互联网标准跟踪协议，并要求讨论和提出改进建议。请参阅当前版本的“互联网官方协议标准”（STD 1），了解该协议的标准化状态和状态。这份备忘录的分发是无限的。
版权所有（C）互联网协会（2005）。
要参与广域IP网络，主机需要为其接口配置IP地址，可以由用户手动配置，也可以从网络上的源（如动态主机配置协议（Dynamic Host Configuration Protocol，DHCP）服务器）自动配置。不幸的是，这样的地址配置信息可能并不总是可用的。因此，即使没有可用的地址配置，主机也能够依赖于IP网络功能的有用子集是有益的。本文档描述了主机如何自动配置具有169.254/16前缀内IPv4地址的接口，该地址对与连接到同一物理（或逻辑）链路的其他设备的通信有效。
IPv4链路本地地址不适合与未直接连接到同一物理（或逻辑）链路的设备通信，并且仅在稳定、可路由的地址不可用的情况下使用（例如在自组织或隔离网络上）。本文档不建议在同一接口上同时配置IPv4链路本地地址和可路由地址。
随着互联网协议的日益普及，能够使用熟悉的IP工具（如FTP）不仅用于全球通信，而且用于本地通信，变得越来越有价值。例如，两个拥有支持IEEE 802.11无线局域网（802.11）的笔记本电脑的人可能会见面并希望交换文件。希望这些人能够使用IP应用软件，而不必手动配置静态IP地址或设置DHCP服务器[RFC2131]（DHCP：动态主机配置协议详解）。
本文档描述了一种方法，通过该方法，主机可以自动配置具有169.254/16前缀的IPv4地址的接口，该地址对该接口上的链路本地通信有效。这在没有其他配置机制可用的环境中尤其有价值。为此，IPv4前缀169.254/16已在IANA注册。IPv6链路本地地址的分配在“IPv6无状态地址自动配置”[RFC2462]中进行了描述（IPv6 的无状态动态主机配置协议 (DHCP) 服务）。
使用IPv4链路本地地址的链路本地通信仅适用于与连接到同一物理（或逻辑）链路的其他设备的通信。使用IPv4链路本地地址的链路本地通信不适合与未直接连接到同一物理（或逻辑）链路的设备进行通信。
Microsoft Windows 98（及更高版本）和Mac OS 8.5（及更高版本）已经支持此功能。本文档规范了使用，规定了主机和路由器如何处理IPv4链路本地地址的规则。特别是，它描述了路由器在接收源地址或目标地址中具有IPv4链路本地地址的数据包时的行为。关于主机，它讨论了声明和保护地址、在同一接口上维护链路本地和可路由的IPv4地址以及多归属问题。
本文档中的关键字“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“可能”和“可选”应按照“RFC中使用的关键字”[RFC2119]中的描述进行解释。
本文档描述了链路本地寻址，用于单个链路上两台主机之间的IPv4通信。在以下情况下，一组主机被视为“在同一链路上”：
*当该组中的任何主机A使用单播、组播或广播向该组中任何其他主机B发送数据包时，整个链路层数据包有效载荷将原封不动地到达，并且
*来自该组主机的任何主机通过该链路发送的广播都可以被该组中的其他所有主机接收
链路层*报文头*可以修改，例如在令牌环源路由[802.5]中，但不能修改链路层*有效载荷*。特别是，如果转发数据包的任何设备修改了IP报文头或IP有效载荷的任何部分，则该数据包不再被视为在同一链路上。这意味着数据包可能会通过中继器、网桥、集线器或交换机等设备，但就本文而言，仍被视为在同一链路上，而不是通过递减TTL或以其他方式修改IP报文头的IP路由器等设备。
本文档使用术语“可路由地址”来指代可以通过路由器转发的169.254/16前缀之外的所有有效单播IPv4地址。这包括所有全局IP地址和私有地址，如Net 10/8[RFC1918]（私有互联网的地址分配），但不包括环回地址，如127.0.0.1。
无论本文档在描述IPv4链路本地地址的使用时使用“主机”一词，当路由器是包含IPv4链路本地源地址或目的地址的数据包的源或预期目的地时，该文本同样适用于路由器。
本文档在ARP数据包的上下文中使用“发送方IP地址”或“目标IP地址”一词时，分别指ARP规范[RFC826]（ARP：以太网地址解析协议）中标识为“ar$spa”（发送方协议地址）和“ar$tpa”（目标协议地址）的ARP数据包字段。对于本文档中描述的ARP的使用，每个字段都始终包含一个IP地址。
在本文档中，术语“ARP探测”用于指代在本地链路上广播的ARP请求数据包，其具有全零的“发送方IP地址”。“发送方硬件地址”必须包含发送数据包的接口的硬件地址。“目标硬件地址”字段被忽略，应设置为全零。“目标IP地址”字段必须设置为正在探测的地址。
在本文档中，术语“ARP通告”用于指代在本地链路上广播的ARP请求数据包，与上述ARP探测相同，除了发送方和目标IP地址字段都包含要通告的IP地址。
常量以大写字母引入。第9节给出了它们的值。
本规范适用于所有IEEE 802局域网（Local Area Networks，LAN）[802]，包括以太网[802.3]、令牌环[802.5]和IEEE 802.11无线局域网[802.1]，以及以至少1 Mbps的数据速率运行、往返延迟不超过1秒并支持ARP[RFC826]（ARP：以太网地址解析协议）的其他链路层技术。无论本文档在何处使用术语“IEEE 802”，该文本同样适用于这些网络技术中的任何一种。
支持ARP但以低于1 Mbps的速率或高于1秒的延迟运行的链路层技术可能需要为以下参数指定不同的值：
（a） ARP探测的数量和间隔，请参阅第2.2.1节中定义的PROBE_NUM、PROBE_MIN、PROBE_MAX
（b） ARP通告的数量和间隔，请参阅第2.4节中定义的ANNOUNCE_NUM和ANNOUNCI_interval
（c） 可以尝试地址声明的最大速率，请参阅第2.2.1节中定义的rate_LIMITINTERVAL和MAX_CONFLICTS
（d） 冲突ARP之间的时间间隔，低于该时间间隔，主机必须重新配置，而不是试图保护其地址，请参阅第2.5节中定义的DEFENDINTERVAL
不支持ARP的链路层技术可能能够使用其他技术来确定特定IP地址当前是否正在使用中。然而，将索赔和辩护机制应用于此类网络不在本文的范围内。
本规范旨在用于小型自组网，即仅包含少数主机的单个链路。尽管原则上有65024个IPv4链路本地地址可用，但试图在单个链路上使用所有这些地址将导致地址冲突的可能性很高，需要主机花费大量时间来找到可用地址。
在单个链路上拥有1300多台主机的网络运营商可能希望考虑将该单个链路划分为两个或多个子网。连接到已经有1300个主机的链路的主机随机选择IPv4链路本地地址，在第一次尝试时有98%的机会选择未使用的IPv4链路本地地址。主机在两次尝试中有99.96%的机会选择未使用的IPv4链路本地地址。它必须尝试十次以上的概率约为10/17。
IPv4链路本地地址及其动态配置对使用它们的应用程序具有深远的影响。第6节对此进行了讨论。许多应用程序从根本上假设通信对等体的地址是可路由的、相对不变的和唯一的。这些假设不再适用于IPv4链路本地地址，或链路本地和可路由IPv4地址的混合。
因此，虽然许多应用程序可以使用IPv4链路本地地址或链路本地和可路由IPv4地址的混合正常工作，但其他应用程序可能只有在修改后才能正常工作，或者将表现出减少或部分功能。
在某些情况下，修改应用程序以在这种条件下运行可能是不可行的。
因此，IPv4链路本地地址仅应在稳定、可路由的地址不可用的情况下使用（例如在自组织或隔离网络上），或者在理解和接受这些限制及其对应用程序的影响的受控情况下使用。本文档不建议在同一接口上同时配置IPv4链路本地地址和可路由地址。
在离线通信中使用IPv4链路本地地址可能会导致应用程序故障。如果在与不在链路上的主机通信时嵌入了IPv4链路本地地址，则这可能发生在包含嵌入式地址的任何应用程序中。嵌入地址的应用程序示例包括IPsec、Kerberos 4/5、FTP、RSVP、SMTP、SIP、X-Windows/Xterm/Telnet、Real Audio、H.323和SNMP[RFC3027]。
为防止在离线通信中使用IPv4链路本地地址，建议采取以下预防措施：
a.不得在DNS中配置IPv4链路本地地址。从IPv4地址到主机名的映射通常是通过对格式为“x.x.x.x.in-addr.arpa”的名称发出DNS查询来完成的。当用于仅在本地链路上具有意义的链路本地地址时，将此类DNS查询发送到本地链路之外是不合适的。DNS客户端不得对任何属于“254.169.in-addr.arpa.”域的名称发送DNS查询。
DNS递归名称服务器从非兼容客户端接收对“254.169.in-addr.arpa.”域内名称的查询，默认情况下必须返回RCODE 3，权威地断言域名系统中不存在此类名称。
b.只要可用，就应在应用程序中使用可全局解析为可路由地址的名称。仅在本地链路上可解析的名称（例如通过使用链路本地组播名称解析（Link Local Multicast Name Resolution）[LLMNR]等协议）不得在离线通信中使用。只能在本地链路上解析的IPv4地址和名称不应转发到本地链路之外。仅当链路本地地址用作源地址和/或目标地址时，才应发送IPv4链路本地地址。这一强烈建议应防止有限范围的地址和名称脱离其适用的上下文。
c.如果可解析为全局可路由地址的名称不可用，但全局可路由的地址可用，则应使用它们而不是IPv4链路本地地址。
IPv4链路本地地址自动配置的实现必须预期地址冲突，并且必须准备好在检测到冲突时自动选择新地址来优雅地处理它们，如第2节所述。检测和处理地址冲突的要求适用于主机使用169.254/16 IPv4链路本地地址的整个期间，而不仅仅是在初始接口配置期间。例如，如第4节所述，如果两个先前独立的网络连接在一起，则主机完成启动后可能会发生地址冲突。
请注意，169.254/16前缀中的地址不应手动配置或由DHCP服务器配置。手动或DHCP配置可能会导致主机使用169.254/16前缀中的地址，而不遵循与此前缀中地址相关的重复检测和自动配置的特殊规则。虽然DHCP规范[RFC2131]指示DHCP客户端应使用ARP探测新接收的地址，但这不是强制性的。同样，虽然DHCP规范建议DHCP服务器在分配地址之前应使用ICMP回显请求探测地址，但这也不是强制性的，即使服务器这样做，IPv4链路本地地址也是不可路由的，因此未直接连接到链路的DHCP服务器无法检测该链路上的主机是否已经在使用所需的IPv4链路本地位址。
希望配置自己的本地地址（使用手动配置、DHCP服务器或本文档中未描述的任何其他机制）的管理员应使用现有的私有地址前缀[RFC1918]之一，而不是169.254/16前缀。
其他注意事项适用于支持多个活动接口的主机，其中一个或多个接口支持IPv4链路本地地址配置。第3节讨论了这些考虑因素。
有时，具有配置的链路本地地址的设备需要与具有在同一物理链路上配置的可路由地址的设备通信，反之亦然。第2.6节中的规则允许这种通信。
例如，这允许仅具有可路由地址的笔记本电脑使用其全球可路由地址与全球网络服务器通信，同时在仅具有IPv4链路本地地址的本地打印机上打印这些网页。
将多个不同范围的地址分配给一个接口，而没有足够的方法来确定在什么情况下应该使用每个地址，这会导致应用程序的复杂性和用户的困惑。在链路上具有地址的主机可以与该链路上的所有其他设备通信，无论这些设备是使用链路本地地址还是可路由地址。出于这些原因，主机不应在同一接口上同时配置可操作的可路由地址和IPv4链路本地地址。术语“可操作地址”用于表示在当前网络环境中有效通信的地址（见下文）。当接口上有可操作的可路由地址时，主机不应在该接口上分配IPv4链路本地地址。但是，在使用可路由地址和IPv4链路本地地址之间的转换（双向）期间，根据以下规则，两者都可能同时使用：
a.在接口上分配IPv4链路本地地址仅基于接口的状态，并且独立于任何其他协议，如DHCP。主机不得改变其行为和使用其他协议，如DHCP，因为主机已为接口分配了IPv4链路本地地址。
b.如果主机发现以前配置有IPv4链路本地地址的接口现在有一个可操作的可路由地址可用，则主机在发起新通信时必须使用该可路由地址，并且必须停止通过其他人已知的任何机制通告IPv4链路本地地址的可用性。主机应继续使用IPv4链路本地地址进行已在进行的通信，并可能继续接受发往IPv4链路本地的新通信。可操作的可路由地址在接口上可用的方式包括：
*手动配置
*通过DHCP分配地址
*主机漫游到先前分配的地址可操作的网络
c.如果主机发现接口不再有可用的可操作路由地址，则主机可以识别可用的IPv4链路本地地址（如第2节所述），并将该地址分配给接口。可操作的可路由地址可能在接口上不再可用的方式包括：
*通过手动配置从接口中删除地址
*通过DHCP分配的地址的租约到期
*将主机漫游到地址不再可操作的新网络。
系统对地址是否“可操作”的确定并不明确，系统上下文中的许多变化（例如路由器变化）可能会影响地址的可操作性。特别是，主机从一个网络漫游到另一个网络可能会（但不确定）改变配置地址的可操作性，但检测到这种移动并不总是微不足道的。
“IPv4中网络连接检测（Detection of Network Attachment，DNA）”[DNAv4]进一步讨论了地址分配和可操作性确定。
以下部分解释了IPv4链路本地地址选择算法、如何保护IPv4链路本地位址，以及如何传递具有IPv4链路本地住址的IPv4封包。
已经实现链路本地IPv4地址自动配置的Windows和Mac OS主机与本节中介绍的规则兼容。然而，如果发现任何互操作性问题，本文档而不是任何先前的实现定义了标准。
当主机希望配置IPv4链路本地地址时，它会使用在169.254.1.0到169.254.254.255（含）范围内均匀分布的伪随机数生成器来选择地址。
为此，IPv4前缀169.254/16已在IANA注册。169.254/16前缀中的前256个和后256个地址保留供将来使用，不得由使用此动态配置机制的主机选择。
必须选择伪随机数生成算法，以便不同的主机不会生成相同的数字序列。如果主机可以访问每个主机不同的持久信息，例如其IEEE 802 MAC地址，则应使用从该信息导出的值为伪随机数生成器播种。这意味着，即使不使用任何其他持久存储，主机每次启动时通常也会选择相同的IPv4链路本地地址，这便于调试和其他操作原因。使用实时时钟或在每个主机中相同（或可能相同）的任何其他信息为伪随机数生成器播种不适合此目的，因为一组同时通电的主机可能会生成相同的序列，从而导致一系列无休止的冲突，因为主机在完全相同的伪随机序列中以锁定的方式移动，在它们探测的每个地址上都发生冲突。
配备持久存储的主机可以为每个接口记录他们选择的IPv4地址。在启动时，具有先前记录的地址的主机在探测时应将该地址作为第一个候选地址。这增加了地址的稳定性。例如，如果一组主机在晚上断电，那么当它们在第二天早上通电时，它们都将继续使用相同的地址，而不是选择不同的地址，并且可能不得不解决出现的冲突。
在选择了一个IPv4链路本地地址后，主机必须在开始使用之前测试该地址是否已被使用。当网络接口从非活动状态转换为活动状态时，主机不知道该链路上当前可能正在使用哪些IPv4链路本地地址，因为在声明冲突地址时，连接点可能已经改变，或者网络接口可能已经处于非活动状态。
如果主机立即开始使用已被其他主机使用的IPv4链路本地地址，这将对其他主机造成干扰。由于主机可能已经改变了其连接点，因此可以在新网络上获得可路由的地址，因此不能假设IPv4链路本地地址是首选。
在使用IPv4链路本地地址（例如，将其用作IPv4数据包中的源地址，或用作ARP数据包包括中的发送方IPv4地址）之前，主机必须执行以下所述的探测测试，以获得更好的信心，即使用IPv4链路本地地址不会造成中断。
涉及接口激活的事件示例包括：
*重启/启动
*从睡眠中唤醒（如果网络接口在睡眠期间处于非活动状态）
*打开以前不活动的网络接口
*IEEE 802硬件链路状态变化（适用于所应用的介质类型和安全机制）表示接口已处于活动状态。
*与无线基站或自组织网络的关联。
当然，主机不得定期执行此检查。这将浪费网络带宽，并且由于主机能够被动发现冲突，因此没有必要，如第2.5节所述。
在支持ARP的链路层（如IEEE 802）上，使用ARP探测进行冲突检测。在不支持ARP的链路层技术上，可以使用其他技术来确定特定的IPv4地址当前是否正在使用中。然而，将索赔和辩护机制应用于此类网络不在本文的范围内。
主机通过广播所需地址的ARP请求来探测地址是否已在使用中。客户端必须用发送数据包的接口的硬件地址填写ARP请求的“发送方硬件地址”字段。“发送方IP地址”字段必须设置为全零，以避免在地址已被另一台主机使用的情况下污染同一链路上其他主机的ARP缓存。“目标硬件地址”字段被忽略，应设置为全零。“目标IP地址”字段必须设置为正在探测的地址。以这种方式构造的具有全零“发送方IP地址”的ARP请求称为“ARP探测”。
当准备开始探测时，主机应等待在0到PROBE_WAIT秒范围内均匀选择的随机时间间隔，然后应发送PROBE_NUM探测数据包，每个探测数据包的间隔是随机的，PROBE_MIN到PROBE_MAX秒。如果在此期间，从探测过程开始到发送最后一个探测数据包后的ANNOUNCE_WAIT秒，主机在执行探测的接口上接收到任何ARP数据包（请求*或*回复），其中数据包的“发送方IP地址”是被探测的地址，则主机必须将此地址视为正在被其他主机使用，并且必须选择一个新的伪随机地址并重复该过程。此外，如果在此期间主机收到任何ARP探测，其中数据包的“目标IP地址”是被探测的地址，而数据包的“发送方硬件地址”不是主机试图配置的接口的硬件地址，则主机必须同样将其视为地址冲突，并如上所述选择一个新地址。如果两个（或多个）主机试图同时配置相同的IPv4链路本地地址，则可能会出现这种情况。
主机应维护一个计数器，记录其在尝试获取地址的过程中经历的地址冲突数量，如果冲突数量超过MAX_CONFLICTS，则主机必须将探测新地址的速率限制为每个RATE_LIMIT_INTERVAL不超过一个新地址。这是为了防止在病理性故障情况下发生灾难性的ARP风暴，例如一个响应所有ARP探测的流氓主机，导致合法主机进入无限循环，试图选择一个可用的地址。
如果在最后一个ARP探测传输后的几秒钟内，没有收到冲突的ARP回复或ARP探测，则主机已成功声明所需的IPv4链路本地地址。
可能会出现比本文件要求的延迟更短的网络技术。可以生成后续的IETF出版物，为这些技术上的PROBE_WAIT、PROBE_NUM、PROBE_MIN和PROBE_MAX的不同值提供指导。
在探测确定要使用的唯一地址后，主机必须通过广播ANNOUNCE_NUM个ARP通告来通告其声称的地址，间隔ANNOUNCI_INTERVAL秒。ARP通告与上述ARP探测相同，除了现在发送方和目标IP地址都设置为主机新选择的IPv4地址。这些ARP通告的目的是确保链路上的其他主机没有之前可能使用相同地址的其他主机留下的过时ARP缓存条目。
地址冲突检测不仅限于主机发送ARP探测时的地址选择阶段。地址冲突检测是一个持续的过程，只要主机使用IPv4链路本地地址，该过程就有效。在任何时候，如果主机在接口上收到ARP数据包（请求*或*回复），其中“发送方IP地址”是主机为该接口配置的IP地址，但“发送方硬件地址”与该接口的硬件地址不匹配，则这是一个冲突的ARP数据包，表明地址冲突。
主机必须按照以下（a）或（b）中的描述对冲突的ARP数据包做出响应：
（a） 在接收到冲突的ARP数据包后，主机可以选择如上所述立即配置新的IPv4链路本地地址，或
（b） 如果主机当前有活动的TCP连接或其他原因更喜欢保持相同的IPv4地址，并且在最后的DEFEND_INTERVAL秒内没有看到任何其他冲突的ARP数据包，那么它可能会选择通过记录接收冲突ARP数据包的时间来尝试保护其地址，然后广播一个ARP通告，给出自己的IP和硬件地址作为ARP的发送方地址。完成此操作后，主机可以继续正常使用该地址，而无需任何进一步的特殊操作。但是，如果这不是主机看到的第一个冲突的ARP数据包，并且为之前的冲突ARP数据包记录的时间是最近的，在DEFEND_INTERVAL秒内，则主机必须立即停止使用此地址并如上所述配置新的IPv4链路本地地址。这是必要的，以确保两台主机不会陷入无休止的循环，两台主机都试图保护同一个地址。
主机必须按照上述（a）或（b）中的描述对冲突的ARP数据包做出响应。主机不得忽略冲突的ARP数据包。
强制地址重新配置可能会造成中断，导致TCP连接中断。然而，预计这种中断将很少见，如果发生无意的地址重复，那么无论地址是如何分配的，通信中断都是不可避免的。在同一网络上使用相同IP地址的两个不同主机不可能可靠运行。
在因冲突而放弃地址之前，主机应主动尝试使用该地址重置任何现有连接。这减轻了地址重新配置带来的一些安全威胁，如第5节所述。
一旦检测到冲突，立即配置新地址是尽快恢复有用通信的最佳方法。上述广播单个ARP通告以保护地址的机制在一定程度上缓解了这个问题，因为它有助于提高两个冲突主机中的一个能够保留其地址的机会。
所有包含链路本地“发送方IP地址”的ARP数据包（*回复*以及请求）必须使用链路层广播而不是链路层单播发送。这有助于及时检测重复地址。第4节给出了一个例子，说明这有什么帮助。
实现此规范的主机需要遵守其他规则，无论它是否具有配置有IPv4链路本地地址的接口。
由于主机上的每个接口除了通过其他方式（例如手动或通过DHCP服务器）配置的零个或多个其他地址外，还可能具有IPv4链路本地地址，因此主机在发送数据包或启动TCP连接时可能必须选择使用哪个源地址。
如果同一接口上同时有IPv4链路本地和可路由地址，则应首选可路由地址作为新通信的源地址，但从IPv4链路本地地址发送或发送到该地址的数据包仍按预期传递。IPv4链路本地地址可以继续用作通信中的源地址，因为切换到首选地址会导致通信失败，因为上层协议的要求（例如，现有的TCP连接）。有关更多详细信息，请参阅第1.7节。
无论目标是否为IPv4链路本地地址，多宿主主机都需要选择一个出站接口。该过程的细节超出了本规范的范围。选择接口后，多宿主主机应发送涉及本文档中指定的IPv4链路本地地址的数据包，就像所选接口是主机的唯一接口一样。有关多宿主主机的进一步讨论，请参阅第3节。
无论使用哪种接口，如果目标地址在169.254/16前缀中（不包括地址169.254.255.255，这是链路本地前缀的广播地址），则发送方必须对目标地址进行ARP，然后将其数据包直接发送到同一物理链路上的目标。无论接口是配置了Link-Local还是可路由的IPv4地址，都必须这样做。
在许多网络栈中，实现此功能可能就像添加一个路由表条目一样简单，该条目指示169.254/16可以在本地链路上直接访问。这种方法不适用于路由器或多宿主主机。有关多宿主主机的更多讨论，请参阅第3节。
主机不得将带有IPv4链路本地目标地址的数据包发送到任何路由器进行转发。
如果目标地址是169.254/16前缀之外的单播地址，那么主机应该使用适当的可路由IPv4源地址（如果可以的话）。如果出于任何原因，主机选择发送带有IPv4链路本地源地址的数据包（例如，所选接口上没有可用的可路由地址），则它必须对目标地址进行ARP，然后将带有IPv4链路局部源地址和可路由目标IPv4地址的数据包包括在内，直接发送到同一物理链路上的目的地。主机不得将数据包发送到任何路由器进行转发。
对于只有一个接口和一个链路本地IPv4地址的设备，这一要求可以解释为“ARP for everything”。
在许多网络堆栈中，实现这种“ARP for everything”行为可能很简单，比如不配置主IP路由器，将主IP路由器地址配置为0.0.0.0，或者将主IP路由地址设置为与主机自己的链路本地IPv4地址相同。有关多宿主主机中的建议行为，请参阅第3节。
对于从IPv4链路本地地址发送的应用程序，一个合理的默认设置是显式地将IPv4 TTL设置为1。这并不适用于所有情况，因为某些应用程序可能需要将IPv4 TTL设置为其他值。
源地址和/或目的地址在169.254/16前缀中的IPv4数据包不得发送到任何路由器进行转发，接收此类数据包的任何网络设备不得转发，无论IPv4报文头中的TTL如何。同样，路由器或其他主机不得不加选择地应答169.254/16前缀地址的所有ARP请求。路由器当然可以根据本文档中描述的声明和防御协议，对一个或多个IPv4链路本地地址的ARP请求进行应答，这些地址是路由器合法声明为自己使用的。
此限制也适用于组播数据包。具有链路本地源地址的IPv4数据包不得转发到本地链路之外，即使它们有组播目标地址。
非转发规则意味着主机可以假设所有169.254/16目标地址都是“在链路上”并且可以直接访问。169.254/16地址前缀不得为子网。本规范利用基于ARP的地址冲突检测，该检测通过在本地子网上广播来实现。由于此类广播不会转发，如果允许子网划分，那么地址冲突可能不会被发现。
这并不意味着禁止Link-Local设备在本地链路之外进行任何通信。实现链路本地和传统可路由IPv4地址的IP主机仍然可以像今天一样不受限制地使用其可路由地址。
类似的考虑也适用于IP层以上的网络层。
例如，网页（包括自动生成的网页）的设计者不应包含带有嵌入式IPv4链路本地地址的链接，如果这些页面可以从地址有效的本地链路之外的主机上查看。
由于IPv4链路本地地址可能随时更改并且范围有限，因此IPv4链路本地位址不得存储在DNS中。
限制IPv4链路本地地址在本地链路外泄漏的另一个原因是隐私问题。如果IPv4链路本地地址是从MAC地址的哈希中导出的，一些人认为它们可能间接地与个人相关联，从而用于跟踪该个人的活动。在本地链路中，数据包中的硬件地址都是可以直接观察到的，因此只要IPv4链路本地地址不离开本地链路，它们就不会向入侵者提供比直接观察硬件地址更多的信息。
如附录A所述，IPv4链路本地的早期实现修改了DHCP状态机。现场经验表明，这些修改降低了DHCP服务的可靠性。
同时实现IPv4链路本地和DHCPv4客户端的设备不应更改DHCPv4客户端行为以适应IPv4链路本地配置。特别是IPv4链路本地地址的配置，无论DHCP服务器当前是否正在响应，都不足以取消配置有效的DHCP租约，阻止DHCP客户端尝试获取新的IP地址，更改DHCP超时或以任何其他方式更改DHCP状态机的行为。
有关此问题的进一步讨论，请参阅“IPv4中网络连接（DNA）的检测”[DNAv4]。
这里概述的注意事项也适用于主机具有多个IP地址的情况，无论它是否具有多个物理接口。多个接口的其他示例包括不同的逻辑端点（隧道、虚拟专用网络等）和同一物理介质上的多个逻辑网络。这通常被称为“多宿主”。
具有多个活动接口并选择在其中一个或多个接口上实现IPv4链路本地地址动态配置的主机将面临各种问题。本节列出了这些问题，但仅指出了如何解决这些问题。在撰写本文时，还没有一种灵丹妙药可以普遍解决所有情况下的这些问题。在系统上实现本文档中指定的协议之前，实现者必须考虑这些问题，该系统可能具有多个活动接口，作为能够多宿主的TCP/IP栈的一部分。
主机可以同时连接到多个网络。如果每个网络都使用一个地址空间，那就太好了，但事实并非如此。在一个网络中使用的地址，无论是NAT后面的网络还是使用IPv4链路本地地址的链路，都不能在另一个网络上使用，并且具有相同的效果。
如果地址不暴露给应用程序也会很好，但它们确实暴露了。对于特定的传输协议，大多数使用TCP/IP的等待消息的软件在特定的端口号从任何接口接收消息。应用程序通常只知道（并关心）它们已收到消息。应用程序知道应用程序将回复的发件人的地址。
第一个作用域地址问题是源地址选择。多宿主主机具有多个地址。发送到特定目的地时，应使用哪个地址作为源地址？这个问题通常通过参考路由表来回答，该表表示在哪个接口（使用哪个地址）上发送，以及如何发送（应该转发到路由器还是直接发送）。作用域地址使选择变得复杂，因为目标所在的地址范围可能不明确。这张表可能无法给出一个好的答案。这个问题与第3.2节中讨论的下一跳选择有关。
第二个作用域地址问题是由作用域参数泄漏到其作用域之外引起的。第7节对此进行了讨论。
这些问题是可以克服的。一种方法是向应用程序公开作用域信息，以便它们始终知道对等体处于什么作用域。这样，就可以选择正确的接口，并在转发地址和其他作用域参数方面遵循安全的过程。还有其他可能的方法。这些方法都没有针对IPv4进行标准化，也没有在本文档中指定。一个好的API设计可以缓解这些问题，方法是将地址范围暴露给“范围地址感知”应用程序，或者巧妙地封装范围信息和逻辑，使应用程序在不知道地址范围的情况下做正确的事情。
实施者可以承诺解决这些问题，但不能简单地忽视它们。有了足够的经验，希望能够出现规范，解释如何克服范围寻址多宿主问题。
这是IPv4链路本地目标地址在多个接口上可访问的核心问题。当主机需要向链路发送数据时，它应该做什么？本地目标L和L可以在多个链路上使用ARP来解决？
即使在给定时刻只能在一个链路上解析链路本地地址，也不能保证它将来会保持明确。其他接口上的其他主机也可能声明地址L。
一种可能性是，只有在应用程序明确表示从哪个接口发送的情况下，才支持这一点。
这个问题没有标准或明显的解决方案。为IPv4协议套件编写的现有应用软件在很大程度上无法处理地址歧义。这并不妨碍实施者找到解决方案，编写能够使用它的应用程序，并提供一个可以在多个接口上支持IPv4链路本地地址动态配置的主机。然而，这种解决方案几乎肯定不适用于现有软件，对更高层是透明的。
鉴于IP堆栈必须具有与需要发送到链路本地目标地址的数据包相关联的出站接口，因此必须进行接口选择。出站接口不能从数据包的报文头参数（如源地址或目的地址）中导出（例如，通过使用转发表查找）。因此，出站接口关联必须通过其他方式明确完成。规范中没有规定这些方法。
本规范注意从使用IPv4链路本地地址过渡到可路由地址（见第1.5节）。其目的是允许具有单个接口的主机首先支持链路本地配置，然后优雅地过渡到使用可路由地址。由于过渡到使用可路由地址的主机可能暂时有多个地址处于活动状态，因此第3.1节中描述的范围地址问题将适用。当主机获取可路由地址时，它不需要保留其链路本地地址，以便与链路上仅使用链路本地地址的其他设备进行通信：任何符合本规范的主机都知道，无论源地址如何，必须通过直接转发到目的地而不是通过路由器到达IPv4链路本地目的地；该主机不需要具有链路本地源地址才能发送到链路本地目的地址。
具有IPv4链路本地地址的主机可以向没有IPv4链路本地位址的目的地发送。如果主机不是多宿主，则过程简单明了：使用ARP并直接转发到链路上的目标是默认路由。然而，如果主机是多宿主的，路由策略会更复杂，特别是如果其中一个接口配置了可路由地址，并且默认路由（合理地）指向可通过该接口访问的路由器。以下示例说明了这个问题，并提供了一个通用的解决方案。
在上图中，HOST1连接到链路1和链路2。接口i1配置了可路由地址，而i2是IPv4链路本地地址。HOST1通过i1将其默认路由设置为ROUTER的地址。HOST1将路由到169.254/16到i2的目的地，直接发送到目的地。
HOST2具有分配给i3的已配置（非链路本地）IPv4地址。
使用名称解析或服务发现协议，HOST1可以发现HOST2的地址。由于HOST2的地址不在169.254/16中，HOST1的路由策略将通过i1向HOST2发送数据报到ROUTER。除非从ROUTER到HOST2有路由，否则从HOST1发送到HOST2的数据报将无法到达它。
这个问题的一个解决方案是，主机尝试在本地（使用ARP）访问任何收到无法访问的ICMP错误消息（ICMP消息代码0、1、6或7[RFC792]（Internet控制消息协议ICMP报文详解））的主机。主机以循环方式尝试所有附加链路。这已经成功地在一些IPv6主机上实现，以完全规避这个问题。就本例而言，HOST1在无法通过路由器到达HOST2时，将尝试通过i2转发到HOST2并成功。
也可以使用第3.2节中描述的技术或此处未讨论的其他方法来克服这个问题。本规范不提供标准解决方案，也不排除实施者支持多宿主配置，前提是他们解决了本节中主机上支持的应用程序的问题。
如果多宿主主机可以在同一链路上支持多个接口，并且所有接口都支持IPv4链路本地自动配置，则必须小心。如果这些接口试图分配相同的地址，它们将保护主机免受自身攻击，从而导致声明算法失败。这个问题最简单的解决方案是在每个配置了IPv4链路本地地址的接口上独立运行算法。
特别是，ARP数据包似乎声称有一个分配给特定接口的地址，只有当它们在该接口上被接收到并且它们的硬件地址是其他接口的地址时，才表示存在冲突。
如果一个主机在同一链路上有两个接口，那么在这些接口上进行声明和防御必须确保它们最终具有不同的地址，就像它们在不同的主机上一样。请注意，主机在同一链路上使用两个接口的某些方式可能是出乎意料和不明显的，例如当主机具有以太网和802.11无线时，但这两个链路（甚至可能在主机用户不知情的情况下）桥接在一起。
不相交网络链路上的主机可以配置相同的IPv4链路本地地址。如果这些单独的网络链路后来被连接或桥接在一起，那么可能有两个主机现在位于同一链路上，试图使用相同的地址。当任一主机尝试与网络上的任何其他主机通信时，它将在某个时候广播ARP数据包，这将使相关主机能够检测到存在地址冲突。
当检测到这些地址冲突时，随后的强制重新配置可能会中断，导致TCP连接中断。然而，预计这种中断将很少见。当网络上的主机处于活动状态时，加入网络应该相对不常见。此外，65024个地址可供IPv4链路本地使用，因此即使两个小型网络连接在一起，任何给定主机发生冲突的可能性也很小。
当加入两个大型网络（定义为每个网段有大量主机的网络）时，发生冲突的可能性更大。在这种网络中，连接之前分离的段可能会导致一个或多个主机需要更改其IPv4链路本地地址，从而导致TCP连接丢失。在分离和重新连接频繁的情况下，如远程桥接网络，这可能会造成破坏。但是，除非连接段上的主机数量非常大，否则连接和后续地址冲突解决产生的流量将很小。
通过广播而不是单播发送具有IPv4链路本地发送方地址的ARP回复，可以确保这些冲突一旦成为潜在问题就可以被检测到，但不会更早。例如，如果连接了两个不相交的网络链路，其中主机A和B都配置了相同的链路本地地址X，则它们可以保持这种状态，直到A、B或其他主机尝试发起通信。如果其他主机C现在向地址X发送ARP请求，而主机A和B都用传统的单播ARP回复进行回复，那么主机C可能会感到困惑，但A和B仍然不会知道有问题，因为他们都看不到对方的数据包。通过广播发送这些回复允许A和B看到彼此冲突的ARP数据包并相应地做出响应。
请注意，为了更快地检测到这些冲突而定期发送无偿的ARP是不必要的，会浪费网络带宽，实际上可能是有害的。例如，如果网络链路只是短暂地连接，并在启动涉及A或B的任何新通信之前再次分离，那么临时冲突将是良性的，不需要强制重新配置。在这种情况下，触发不必要的强制重新配置没有任何用处。主机不应定期发送免费的ARP。
使用IPv4链路本地地址可能会使网络主机面临新的攻击。特别是，以前没有IP地址且没有运行IP堆栈的主机不易受到基于IP的攻击。通过配置工作地址，主机现在可能容易受到基于IP的攻击。
ARP协议[RFC826]（ARP：以太网地址解析协议）是不安全的。恶意主机可能会在网络上发送欺诈性ARP数据包，干扰其他主机的正常运行。例如，主机很容易回答所有ARP请求，并给出自己的硬件地址，从而声称对网络上每个地址的所有权。
注意：某些类型的本地链路，如无线局域网，不提供物理安全。由于这些链路的存在，实施者认为当设备仅在本地链路上通信时，可以免除正常的安全预防措施，这是非常不明智的。如果不实施适当的安全措施，用户可能会面临相当大的风险。
实施IPv4链路本地配置的主机存在选择性重新配置和中断的额外漏洞。链路上的攻击者可能会发出ARP数据包，这将导致主机通过切换到新地址来断开所有连接。攻击者可以强制实施IPv4链路本地配置的主机选择某些地址，或阻止其完成地址选择。这与前一段所述的欺骗性ARP构成的威胁截然不同。
实现和用户还应注意，根据第2.5节的要求，放弃地址并重新配置的节点允许另一个节点轻松成功地劫持现有的TCP连接。
建议实施者注意，互联网协议架构要求每个联网设备或主机都必须实施足够的安全措施，以保护设备或主机可以访问的资源，包括网络本身，免受已知或可信的威胁。尽管使用IPv4链路本地地址可以减少设备面临的威胁数量，但支持互联网协议的设备的实施者不得假设客户的本地网络没有安全风险。
虽然可能存在特定类型的设备或特定环境，网络提供的安全性足以保护设备可访问的资源，但笼统地说，对于使用IPv4链路本地地址作为唯一访问方式的设备，提供安全性的要求降低了，这将是误导性的。
在所有情况下，无论是否使用IPv4链路本地地址，支持互联网协议的设备的实施者都有必要分析特定主机或设备可能受到的已知和可信的威胁，并在可行的情况下提供安全机制，以改善或降低与此类威胁相关的风险。
使用IPv4链路本地自动配置地址给应用程序的编写者带来了额外的挑战，并可能导致现有的应用程序软件失败。
IPv4链路应用程序使用的本地地址可能会随时间而变化。遇到地址更改的某些应用程序软件将失败。例如，现有的客户端TCP连接将被中止，必须重新发现地址更改的服务器，被阻止的读写将退出并出现错误情况，等等。
生产将用于支持IPv4链路本地地址配置的IP实现的应用软件的供应商应检测并应对地址更改事件。生产支持IPv4链路本地地址配置的IPv4实现的供应商应该向应用程序公开地址更改事件。
IPv4链路本地地址不得通过应用程序协议（例如在URL中）转发到不在同一链路上的目的地。第2.9节和第3节对此进行了进一步讨论。
转发地址信息的现有分布式应用软件可能会失败。例如，FTP[RFC959]（FTP：文件传输协议）（不使用被动模式时）传输客户端的IP地址。假设客户端在只有链路本地地址时启动并获取其IPv4配置。稍后，主机获得一个全局IP地址，客户端联系本地链路外的FTP服务器。如果FTP客户端在FTP“端口”命令中传输其旧的Link-Local地址而不是新的全局IP地址，则FTP服务器将无法打开回客户端的数据连接，FTP操作将失败。
在支持多个接口上的IPv4链路本地地址配置的多宿主主机上运行的应用程序软件可能会失败。
这是因为应用程序软件假定IPv4地址是明确的，它只能指向一个主机。IPv4链路本地地址仅在单个链路上是唯一的。连接到多个链路的主机很容易遇到同一地址出现在多个接口上的情况，或者先出现在一个接口上，然后出现在另一个接口中；在任何情况下都与多个主机相关联。大多数现有软件都没有为这种模糊性做好准备。未来，可以开发应用程序编程接口来防止这个问题。第3节讨论了这个问题。
路由器不得转发具有IPv4链路本地源或目标地址的数据包，无论路由器的默认路由配置或从动态路由协议获得的路由如何。
接收具有IPv4链路本地源或目标地址的数据包的路由器不得转发该数据包。这可以防止将数据包转发回其来源的网段或任何其他网段。
IANA已为本文档中描述的用途分配了前缀169.254/16。此范围内的第一个和最后256个地址（169.254.0.x和169.254.255.x）由标准行动分配，如“IANA编写指南”（BCP 26）[RFC2434]中所定义。本文档不要求其他IANA服务。
本协议中使用了以下定时常数；它们不是用户可配置的。
PROBE_WAIT：1秒（初始随机延迟）
PROBE_NUM：3（探测数据包的数量）
PROBE_MIN：1秒（重复探测前的最小延迟）
PROBE_MAX：2秒（重复探测前的最大延迟）
ANNOUNCE_WAIT：2秒（通告前延迟）
ANNOUNCE_NUM：2（通告数据包数量）
ANNOUNCE_INTERVAL：2秒（通告数据包之间的时间）
MAX_CONFLICTS：10（速率限制前的最大冲突数）
RATE_LIMIT_INTERVAL：60秒（连续尝试之间的延迟）
DEFEND_INTERVAL：10秒（防御ARP之间的最小间隔）
[] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.[] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.[] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.[802.3] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 1996.[802.5] ISO/IEC 8802-5 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 5: Token ring access method and physical layer specifications, (also ANSI/IEEE Std 802.5-1998), 1998.[802.11] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1999, 1999.[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.[DNAv4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", Work in Progress, July 2004.[LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast Name Resolution (LLMNR)", Work in Progress, June 2004.
Mac OS在伪随机的基础上选择IP地址。所选地址将保存在持久存储中，以便在可能的情况下重新启动后继续使用。
Mac OS发送9个DHCPDISCOVER数据包，数据包之间的间隔为2秒。如果这些请求中没有收到任何响应（18秒），它将自动配置。
在发现所选地址正在使用时，Mac OS将选择一个新的随机地址并重试，重试频率限制为每两秒不超过一次。
自动配置的Mac OS系统每五分钟检查一次DHCP服务器的存在。如果找到DHCP服务器，但Mac OS未能成功获得新租约，它将保留现有的自动配置IP地址。如果Mac OS成功获得新租约，它会毫无预警地断开所有现有连接。这可能会导致用户丢失正在进行的会话。一旦获得新的租约，Mac OS将不会使用自动配置的IP地址分配进一步的连接。
如果默认网关存在，Mac OS系统不会将寻址到Link-Local地址的数据包发送到默认网关；这些地址总是在本地段上解析。
默认情况下，Mac OS系统发送TTL为255的所有传出单播数据包。如果所有组播和广播数据包的源地址在169.254/16前缀中，则它们也会以255的TTL发送。
Mac OS在硬件（和驱动程序软件）支持的情况下实现了介质感知。一旦检测到网络连接，就会在接口上发送DHCPDISCOVER。这意味着一旦连接恢复，系统将立即从自动配置模式转换出来。
Mac OS X在伪随机的基础上选择IP地址。所选地址保存在内存中，以便在系统单次启动期间的后续自动配置尝试中可以重复使用。
链路本地地址的自动配置取决于DHCP过程的结果。DHCP发送两个数据包，超时时间为1秒和2秒。如果没有收到响应（三秒），它将开始自动配置。DHCP继续并行发送数据包，总时间为60秒。
在自动配置开始时，它生成10个唯一的随机IP地址，并依次探测每个地址2秒。在找到未使用的地址或地址列表已用尽后，它停止探测。
如果DHCP不成功，它会等待五分钟再重新启动。DHCP成功后，自动配置的链路本地地址将被放弃。但是，Link-Local子网仍处于配置状态。
在任何给定时刻，仅在单个接口上尝试自动配置。
Mac OS X确保具有最高优先级的连接接口与Link-Local子网相关联。如果存在默认网关，则发往链路本地地址的数据包永远不会发送到默认网关。链路本地地址始终在本地段上解析。
Mac OS X在硬件和驱动程序支持的情况下实现介质感知。当网络介质指示已连接时，自动配置过程再次开始，并尝试重新使用之前分配的Link-Local地址。当网络介质指示已断开连接时，系统会等待四秒钟，然后再取消配置链路本地地址和子网。如果在此之前恢复了连接，则自动配置过程将再次开始。如果在此之前未恢复连接，系统将选择另一个接口进行自动配置。
默认情况下，Mac OS X发送TTL为255的所有传出单播数据包。如果所有组播和广播数据包的源地址在169.254/16前缀中，则它们也会以255的TTL发送。
Windows 98/98SE系统在伪随机的基础上选择其IPv4链路本地地址。地址选择算法基于计算接口MAC地址的哈希值，因此大量主机在选择169.254/16地址空间内的地址时应遵循均匀概率分布。从接口的MAC地址导出初始IPv4链路本地地址还可以确保系统重新启动时将获得相同的自动配置地址，除非检测到冲突。
当处于INIT状态时，Windows 98/98SE DHCP客户端总共发送4个DHCPDISCOVER，数据包间间隔为6秒。当所有4个数据包（24秒）后都没有收到响应时，它将自动配置一个地址。
Windows 98/98SE系统的自动配置重试计数为10。在尝试了10个自动配置的IPv4地址并发现全部被占用后，主机将在没有IPv4地址的情况下启动。
自动配置的Windows 98/98SE系统每五分钟检查一次DHCP服务器的存在。如果找到DHCP服务器，但Windows 98未能成功获得新的租约，它将保留现有的自动配置的IPv4链路本地地址。如果Windows 98/98SE成功获得新租约，它将毫无警告地删除所有现有连接。这可能会导致用户丢失正在进行的会话。一旦获得新的租约，Windows 98/98SE将不会使用自动配置的IPv4链路本地地址分配更多连接。
如果存在默认网关，则具有IPv4链路本地地址的Windows 98/98SE系统不会将寻址到IPv4链路本地位置的数据包发送到默认网关；这些地址总是在本地段上解析。
默认情况下，Windows 98/98SE系统发送TTL为128的所有传出单播数据包。TTL配置是通过将REG_DWORD类型的Windows注册表项HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\Parameters\DefaultTTL设置为适当的值来执行的。但是，此默认TTL将应用于所有数据包。虽然此功能可用于将默认TTL设置为255，但它不能用于将IPv4链路本地数据包的默认TTL设为1，同时允许其他数据包以大于1的TTL发送。
Windows 98/98SE系统不实现介质感知。这意味着网络连接问题（如电缆松动）可能会阻止系统联系DHCP服务器，从而导致其自动配置。当连接问题得到解决时（例如重新连接电缆时），情况不会立即自行纠正。由于系统不会检测到重新连接，因此它将保持自动配置模式，直到尝试访问DHCP服务器。
默认情况下，Windows 98SE Internet连接共享（Internet Connection Sharing，ICS）（NAT实现）附带的DHCP服务器从192.168/16专用地址空间中分配。
但是，可以通过注册表项更改分配前缀，并且不会进行任何检查来防止分配超出IPv4链路本地前缀。当配置为这样做时，Windows 98SE ICS将重写来自IPv4链路本地前缀的数据包，并将其转发到本地链路之外。Windows 98SE ICS不会自动路由IPv4链路本地前缀，因此通过DHCP获取地址的主机无法与仅自动配置的设备通信。
默认情况下，其他家庭网关会在IPv4链路本地前缀之外分配地址。Windows 98/98SE系统在与非链路本地主机通信时，可以使用169.254/16 IPv4链路本地地址作为源地址。Windows 98/98SE不支持路由器请求/通告。Windows 98/98SE系统在自动配置模式下不会自动发现默认网关。
Windows XP、Windows 2000和Windows ME系统的自动配置行为与Windows 98/98SE相同，但以下方面除外：
Media Sense（介质感知）
Router Discovery（路由器发现）
Silent RIP（静默RIP）
Windows XP、2000和ME实现了介质感知。一旦检测到网络连接，就会在接口上发送DHCPREQUEST或DHCPDISCOVER。这意味着一旦连接恢复，系统将立即从自动配置模式转换出来。
Windows XP、2000和ME也支持路由器发现，尽管默认情况下它是关闭的。Windows XP和2000也支持RIP侦听器。这意味着他们可能会在自动配置模式下无意中发现默认网关。
Windows XP/2000/ME上的ICS在地址分配和链路本地前缀的NAT方面与Windows 98SE的行为相同。
版权所有（C）互联网协会（2005）。
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
本文件和其中包含的信息是按“原样”提供的，贡献者、他/她代表或赞助的组织（如有）、互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于使用本文件中的信息不会侵犯任何权利或对适销性或特定用途适用性的任何暗示保证。
IETF对可能声称与本文档所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不持任何立场；它也不代表它已经做出了任何独立的努力来确定任何此类权利。有关RFC文档中权限程序的信息，请参阅BCP 78和BCP 79。
向IETF秘书处披露的知识产权副本以及提供许可证的任何保证，或本规范的实施者或用户试图获得使用此类专有权利的一般许可或许可的结果，可以从IETF在线知识产权存储库获得，网址为http://www.ietf.org/ipr.
IETF邀请任何利益相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施本标准所需技术的其他专有权利。请将信息发送至IETFietf-ipr@ietf.org.
RFC编辑器功能的资金目前由互联网协会提供。
长按二维码
关注我们吧
