Internet Engineering Task Force (IETF) M. Behringer
Request for Comments: 7404 E. Vyncke
Category: Informational Cisco
ISSN: 2070-1721 November 2014
Internet Engineering Task Force (IETF) M. Behringer
Request for Comments: 7404 E. Vyncke
Category: Informational Cisco
ISSN: 2070-1721 November 2014
Using Only Link-Local Addressing inside an IPv6 Network
在IPv6网络中仅使用链路本地寻址
Abstract
摘要
In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.
在IPv6网络中，路由器之间的基础设施链路上只能使用链路本地地址。本文讨论了这种方法的优点和缺点，以促进给定网络的决策过程。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7404.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7404.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Using Link-Local Addressing on Infrastructure Links . . . . . 2
2.1. The Approach . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Internet Exchange Points . . . . . . . . . . . . . . . . 6
2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. Informative References . . . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Using Link-Local Addressing on Infrastructure Links . . . . . 2
2.1. The Approach . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Internet Exchange Points . . . . . . . . . . . . . . . . 6
2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. Informative References . . . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
An infrastructure link between a set of routers typically does not require global or unique local addresses [RFC4193]. Using only link-local addressing on such links has a number of advantages; for example, routing tables do not need to carry link addressing and can therefore be significantly smaller. This helps to decrease failover times in certain routing convergence events. An interface of a router is also not reachable beyond the link boundaries, therefore reducing the attack surface.
一组路由器之间的基础设施链路通常不需要全局或唯一的本地地址[RFC4193]。在这样的链接上只使用链接本地寻址有很多优点；例如，路由表不需要携带链接地址，因此可以大大减小。这有助于减少某些路由聚合事件中的故障切换时间。路由器的接口在链路边界之外也无法到达，因此减少了攻击面。
This document discusses the advantages and caveats of this approach.
本文件讨论了这种方法的优点和注意事项。
Note that some traditional techniques used to operate a network, such as pinging interfaces or seeing interface information in a traceroute, do not work with this approach. Details are discussed below.
请注意，一些用于操作网络的传统技术，例如ping接口或在traceroute中查看接口信息，不适用于这种方法。详情如下。
During WG and IETF last call, the technical correctness of the document was reviewed; however, debate exists as to whether to recommend this technique. The deployment of this technique is appropriate where it is found to be necessary.
在工作组和IETF最后一次通话期间，审查了文件的技术正确性；然而，关于是否推荐这种技术存在争议。在必要的情况下，这种技术的部署是适当的。
This document discusses the approach of using only link-local addresses (LLAs) on all router interfaces on infrastructure links. Routers don't typically need to receive packets from hosts or nodes outside the network. For a network operator, there may be reasons to use addresses that are greater than link-local scope on infrastructure interfaces for certain operational tasks, such as pings to an interface or traceroutes across the network. This document discusses such cases and proposes alternative procedures.
本文档讨论了在基础设施链路上的所有路由器接口上仅使用链路本地地址（LLA）的方法。路由器通常不需要从网络外的主机或节点接收数据包。对于网络运营商来说，可能有理由在某些操作任务中使用大于基础设施接口上链路本地作用域的地址，例如到接口的ping或网络上的跟踪路由。本文件讨论了此类情况，并提出了替代程序。
In this approach, neither globally routed IPv6 addresses nor unique local addresses are configured on infrastructure links. In the absence of specific global or unique local address definitions, the default behavior of routers is to use link-local addresses, notably for routing protocols.
在这种方法中，基础设施链路上既不配置全局路由IPv6地址，也不配置唯一的本地地址。在没有特定全局或唯一本地地址定义的情况下，路由器的默认行为是使用链路本地地址，尤其是路由协议。
The sending of ICMPv6 [RFC4443] error messages ("packet-too-big", "time-exceeded", etc.) is required for routers. Therefore, another interface must be configured with an IPv6 address that has a greater scope than link-local. This address will usually be a loopback interface with a global scope address belonging to the operator and part of an announced prefix (with a suitable prefix length) to avoid being dropped by other routers implementing ingress filtering [RFC3704]. This is implementation dependent. For the remainder of this document, we will refer to this interface as a "loopback interface".
路由器需要发送ICMPv6[RFC4443]错误消息（“数据包太大”、“超出时间”等）。因此，另一个接口必须配置一个IPv6地址，该地址的作用域大于本地链路。该地址通常是一个环回接口，具有属于运营商的全局作用域地址和已公布前缀的一部分（具有合适的前缀长度），以避免被实施入口过滤的其他路由器丢弃[RFC3704]。这取决于实现。在本文档的其余部分中，我们将此接口称为“环回接口”。
[RFC6724] recommends that IPv6 addresses that are greater than link-local scope be used as the source IPv6 address for all generated ICMPv6 messages sent to a non-link-local address, with the exception of ICMPv6 redirect messages (as defined in Section 4.5 of [RFC4861]).
[RFC6724]建议将大于链路本地作用域的IPv6地址用作发送到非链路本地地址的所有生成的ICMPv6消息的源IPv6地址，但ICMPv6重定向消息除外（如[RFC4861]第4.5节所定义）。
The effect on specific traffic types is as follows:
对特定交通类型的影响如下：
o Most control plane protocols (such as BGP [RFC4271], IS-IS [IS-IS], OSPFv3 [RFC5340], Routing Information Protocol Next Generation (RIPng) [RFC2080], and PIM [RFC4609]) work by default or can be configured to work with link-local addresses. Exceptions are explained in the caveats section (Section 2.3).
o 大多数控制平面协议（如BGP[RFC4271]、IS-IS[IS-IS]、OSPFv3[RFC5340]、下一代路由信息协议（RIPng）[RFC2080]和PIM[RFC4609]）默认工作，或者可以配置为与链路本地地址一起工作。例外情况在“注意事项”一节（第2.3节）中解释。
o Management plane traffic (such as Secure SHell (SSH) Protocol [RFC4251], Telnet [RFC0495], Simple Network Management Protocol (SNMP) [RFC1157], and ICMPv6 Echo Request [RFC4443]) can use the address of the router loopback interface as the destination address. Router management can also be done over out-of-band channels.
o 管理平面通信（如安全外壳（SSH）协议[RFC4251]、Telnet[RFC0495]、简单网络管理协议（SNMP）[RFC1157]和ICMPv6回显请求[RFC4443]）可以使用路由器环回接口的地址作为目标地址。路由器管理也可以通过带外通道完成。
o ICMP error messages are usually sourced from a loopback interface with a scope that is greater than link-local. Section 4.5 of [RFC4861] explains one exception: ICMP redirect messages can also be sourced from a link-local address.
o ICMP错误消息通常来自范围大于本地链路的环回接口。[RFC4861]第4.5节解释了一个例外情况：ICMP重定向消息也可以来自链路本地地址。
o Data plane traffic is forwarded independently of the link address type.
o 数据平面流量的转发独立于链路地址类型。
o Neighbor discovery (neighbor solicitation and neighbor advertisement) is done by using link-local unicast and multicast addresses. Therefore, neighbor discovery is not affected.
o 邻居发现（邻居请求和邻居广告）是通过使用链路本地单播和多播地址来完成的。因此，邻居发现不受影响。
Thus, we conclude that it is possible to construct a working network in this way.
因此，我们得出结论，以这种方式构建工作网络是可能的。
The following list of advantages is in no particular order.
下面列出的优点没有特别的顺序。
Smaller routing tables: Since the routing protocol only needs to carry one global address (the loopback interface) per router, it is smaller than the traditional approach where every infrastructure link address is carried in the routing protocol. This reduces memory consumption and increases the convergence speed in some routing failover cases. Because the Forwarding Information Base to be downloaded to line cards is smaller, and there are fewer prefixes in the Routing Information Base, the routing algorithm is accelerated. Note that smaller routing tables can also be achieved by putting interfaces in passive mode for the Interior Gateway Protocol (IGP).
较小的路由表：由于路由协议只需要为每个路由器携带一个全局地址（环回接口），因此它比在路由协议中携带每个基础设施链路地址的传统方法要小。在某些路由故障切换情况下，这会减少内存消耗并提高收敛速度。由于下载到线路卡的转发信息库较小，且路由信息库中的前缀较少，因此路由算法得到了加速。请注意，对于内部网关协议（IGP），将接口置于被动模式也可以实现较小的路由表。
Simpler address management: Only loopback interface addresses need to be considered in an addressing plan. This also allows for easier renumbering.
更简单的地址管理：在寻址计划中只需要考虑环回接口地址。这还允许更容易地重新编号。
Lower configuration complexity: Link-local addresses require no specific configuration, thereby lowering the complexity and size of router configurations. This also reduces the likelihood of configuration mistakes.
更低的配置复杂性：链路本地地址不需要特定的配置，从而降低路由器配置的复杂性和大小。这也降低了配置错误的可能性。
Simpler DNS: Less routable address space in use also means less reverse and forward mapping DNS resource records to maintain. Of course, if the operator selects not to enter any global interface addresses in the DNS anyway, then this is less of an advantage.
更简单的DNS：使用更少的可路由地址空间也意味着需要维护的反向和正向映射DNS资源记录更少。当然，如果运营商选择不在DNS中输入任何全局接口地址，那么这就不是什么优势。
Reduced attack surface: Every routable address on a router constitutes a potential attack point; a remote attacker can send traffic to that address, for example, a TCP SYN flood (see [RFC4987]). If a network only uses the addresses of the router loopback interface(s), only those addresses need to be protected from outside the network. This may ease protection measures, such as Infrastructure Access Control Lists (iACL). Without using link-local addresses, it is still possible to achieve the simple iACL if the network addressing scheme is set up such that all link and loopback interfaces have addresses that are greater than link-local and are aggregatable, and if the infrastructure access list covers that entire aggregated space. See also [RFC6752] for further discussion
减少攻击面：路由器上的每个可路由地址构成潜在攻击点；远程攻击者可以向该地址发送流量，例如TCP SYN洪水（请参阅[RFC4987]）。如果网络仅使用路由器环回接口的地址，则只有这些地址需要从网络外部进行保护。这可能会简化保护措施，如基础设施访问控制列表（iACL）。在不使用链路本地地址的情况下，如果将网络寻址方案设置为所有链路和环回接口的地址都大于链路本地地址且可聚合，并且基础设施访问列表覆盖整个聚合空间，则仍然可以实现简单的iACL。进一步讨论请参见[RFC6752]
on this topic. [RFC6860] describes another approach to hide addressing on infrastructure links for OSPFv2 and OSPFv3 by modifying the existing protocols. This document does not modify any protocol and applies only to IPv6.
关于这个话题。[RFC6860]描述了另一种通过修改现有协议来隐藏OSPFv2和OSPFv3的基础设施链路寻址的方法。本文档不修改任何协议，仅适用于IPv6。
The caveats listed in this section are in no particular order.
本节中列出的注意事项没有特定顺序。
Interface ping: If an interface doesn't have a routable address, it can only be pinged from a node on the same link. Therefore, it is not possible to ping a specific link interface remotely. A possible workaround is to ping the loopback address of a router instead. In most cases today, it is not possible to see which link the packet was received on; however, [RFC5837] suggests including the interface identifier of the interface a packet was received on in the ICMPv6 response. It must be noted that there are few implementations of this ICMPv6 extension. With this approach, it would be possible to ping a router on the addresses of loopback interfaces, yet see which interface the packet was received on. To check liveliness of a specific interface, it may be necessary to use other methods, such as connecting to the router via SSH and checking locally or using SNMP.
接口ping：如果接口没有可路由地址，则只能从同一链路上的节点ping。因此，无法远程ping特定的链路接口。一个可能的解决方法是ping路由器的环回地址。在今天的大多数情况下，不可能看到数据包是在哪个链路上接收的；但是，[RFC5837]建议在ICMPv6响应中包含接收数据包的接口的接口标识符。必须注意的是，此ICMPv6扩展的实现很少。通过这种方法，可以在环回接口的地址上ping路由器，同时查看在哪个接口上接收数据包。要检查特定接口的活跃性，可能需要使用其他方法，例如通过SSH连接到路由器并在本地检查或使用SNMP。
Traceroute: Similar to the ping case, a reply to a traceroute packet would come from the address of a loopback interface, and current implementations do not display the specific interface the packets came in on. Again, [RFC5837] provides a solution. As in the ping case above, it is not possible to traceroute to a particular interface if it only has a link-local address. Conversely, this approach may make network topology discovery from outside the network simpler: instead of responding with multiple different interface IP addresses, which have to be correlated by the outsider, a router will always respond with the same loopback address. If reverse DNS mapping is used, the mapping is trivial in either case.
Traceroute：与ping情况类似，对Traceroute数据包的回复将来自环回接口的地址，并且当前的实现不显示数据包进入的特定接口。[RFC5837]再次提供了一个解决方案。与上面的ping情况一样，如果某个接口只有一个链接本地地址，则不可能跟踪路由到该接口。相反，这种方法可能会使从网络外部发现网络拓扑变得更简单：路由器不会使用多个不同的接口IP地址（必须由外部人员关联）进行响应，而是始终使用相同的环回地址进行响应。如果使用反向DNS映射，则无论哪种情况，映射都是微不足道的。
Hardware dependency: LLAs have usually been based on 64-bit Extended Unique Identifiers (EUI-64); hence, they change when the Message Authentication Code (MAC) address is changed. This could pose a problem in a case where the routing neighbor must be configured explicitly (e.g., BGP) and a line card needs to be physically replaced, hence changing the EUI-64 LLA and breaking the routing neighborship. LLAs can be statically configured, such as fe80::1 and fe80::2, which can be used to configure any required static routing neighborship. However, this static LLA configuration may be more complex to operate than statically configured addresses that are greater than link-local scope. This is because LLAs are inherently ambiguous. For a multi-link node, such as a router, to deal with the
硬件依赖性：LLA通常基于64位扩展唯一标识符（EUI-64）；因此，当消息身份验证码（MAC）地址更改时，它们也会更改。在必须明确配置路由邻居（例如BGP）并且需要物理更换线路卡的情况下，这可能会造成问题，从而更改EUI-64 LLA并中断路由邻居关系。LLA可以静态配置，例如fe80:：1和fe80:：2，它们可以用于配置任何所需的静态路由邻居。然而，这种静态LLA配置可能比大于链路本地作用域的静态配置地址更复杂。这是因为LLA本质上是不明确的。对于多链路节点，如路由器，要处理
ambiguity, the link zone index must also be considered explicitly, e.g., using the extended textual notation described in [RFC4007], as in this example, 'BGP neighbor fe80::1%eth0 is down'.
不明确，还必须明确考虑链路区域索引，例如，使用[RFC4007]中描述的扩展文本表示法，如本例中的“BGP邻居fe80:：1%eth0关闭”。
Network Management System (NMS) toolkits: If there is any NMS tool that makes use of an interface IP address of a router to carry out any of its NMS functions, then it would no longer work if the interface does not have a routable address. A possible workaround for such tools is to use the routable address of the router loopback interface instead. Most vendor implementations allow the specification of loopback interface addresses for SYSLOG, IPFIX, and SNMP. The Link Layer Discovery Protocol (LLDP) (IEEE 802.1AB-2009) runs directly over Ethernet and does not require any IPv6 address, so dynamic network discovery is not hindered by using only LLA when using LLDP. But, network discovery based on Neighbor Discovery Protocol (NDP) cache content will only display the link-local addresses and not the addresses of the loopback interfaces; therefore, network discovery should rather be based on the Route Information Base to detect adjacent nodes.
网络管理系统（NMS）工具包：如果有任何NMS工具利用路由器的接口IP地址来执行其任何NMS功能，那么如果接口没有可路由地址，则该工具将不再工作。此类工具的一个可能的解决方法是使用路由器环回接口的可路由地址。大多数供应商实现都允许为SYSLOG、IPFIX和SNMP指定环回接口地址。链路层发现协议（LLDP）（IEEE 802.1AB-2009）直接在以太网上运行，不需要任何IPv6地址，因此在使用LLDP时仅使用LLA不会妨碍动态网络发现。但是，基于邻居发现协议（NDP）缓存内容的网络发现只显示链路本地地址，而不显示环回接口的地址；因此，网络发现应该基于路由信息库来检测相邻节点。
MPLS and RSVP-Traffic Engineering (RSVP-TE) [RFC3209] allow the establishment of an MPLS Label Switched Path (LSP) on a path that is explicitly identified by a strict sequence of IP prefixes or addresses (each pertaining to an interface or a router on the path). This is commonly used for Fast Reroute (FRR). However, if an interface uses only a link-local address, then such LSPs cannot be established. At the time of writing this document, there is no workaround for this case; therefore, where RSVP-TE is being used, the approach described in this document does not work.
MPLS和RSVP流量工程（RSVP-TE）[RFC3209]允许在路径上建立MPLS标签交换路径（LSP），该路径由严格的IP前缀或地址序列明确标识（每个前缀或地址都与路径上的接口或路由器有关）。这通常用于快速重路由（FRR）。但是，如果接口仅使用链路本地地址，则无法建立此类LSP。在编写本文件时，本案例没有解决办法；因此，在使用RSVP-TE的情况下，本文件中描述的方法不起作用。
Internet Exchange Points (IXPs) have a special importance in the global Internet because they connect a high number of networks in a single location and because a significant part of Internet traffic passes through at least one IXP. An IXP requires, therefore, a very high level of security. The address space used on an IXP is generally known, as it is registered in the global Internet Route Registry, or it is easily discoverable through traceroute. The IXP prefix is especially critical because practically all addresses on this prefix are critical systems in the Internet.
互联网交换点（IXP）在全球互联网中具有特殊的重要性，因为它们在一个位置连接大量网络，并且互联网流量的很大一部分通过至少一个IXP。因此，IXP需要非常高级别的安全性。IXP上使用的地址空间通常是已知的，因为它在全局Internet路由注册表中注册，或者很容易通过跟踪路由发现。IXP前缀尤其重要，因为实际上这个前缀上的所有地址都是Internet上的关键系统。
Apart from general device security guidelines, there are basically two additional ways to raise security (see also [BGP-OPSEC]):
除了一般设备安全指南外，基本上还有两种提高安全性的方法（另请参见[BGP-OPSEC]）：
1. Not to announce the prefix in question, and
1. 不公布有问题的前缀，以及
2. To drop all traffic from remote locations destined to the IXP prefixes.
2. 删除从远程位置发送到IXP前缀的所有流量。
Not announcing the prefix of the IXP would frequently result in traceroute and similar packets (required for Path MTU Discovery (PMTUD)) being dropped due to unicast Reverse Path Forwarding (uRPF) checks. Given that PMTUD is critical, this is generally not acceptable. Dropping all external traffic to the IXP prefix is hard to implement because if only one service provider connected to an IXP does not filter correctly, then all IXP routers are reachable from at least that service provider network.
由于单播反向路径转发（uRPF）检查，不宣布IXP的前缀通常会导致跟踪器路由和类似数据包（路径MTU发现（PMTUD）所需）被丢弃。鉴于PMTUD至关重要，这通常是不可接受的。将所有外部流量丢弃到IXP前缀是很难实现的，因为如果只有一个连接到IXP的服务提供商没有正确过滤，那么至少可以从该服务提供商网络访问所有IXP路由器。
As the prefix used in the IXP is usually longer than a /48, it is frequently dropped by route filters on the Internet having the same net effect as not announcing the prefix.
由于IXP中使用的前缀通常比a/48长，它经常被互联网上的路由过滤器丢弃，具有与不公布前缀相同的净效果。
Using link-local addresses on the IXP may help in this scenario. In this case, the generated ICMPv6 packets would be generated from loopback interfaces or from any other interface with a globally routable address without any configuration. However, in this case, each service provider would use their own address space, making a generic attack against all devices on the IXP harder. All of an IXP's loopback interface addresses can be discovered by a potential attacker with a simple traceroute; a generic attack is, therefore, still possible, but it would require more work.
在IXP上使用链接本地地址在这种情况下可能会有所帮助。在这种情况下，生成的ICMPv6数据包将从环回接口或具有全局可路由地址的任何其他接口生成，无需任何配置。但是，在这种情况下，每个服务提供商都会使用自己的地址空间，这使得针对IXP上所有设备的一般攻击更加困难。所有IXP的环回接口地址都可以被潜在攻击者通过简单的跟踪路由发现；因此，通用攻击仍然是可能的，但需要更多的工作。
In some cases, service providers carry the IXP addresses in their IGP for certain forms of traffic engineering across multiple exit points. Link-local addresses cannot be used for this purpose; in this case, the service provider would have to employ other methods of traffic engineering.
在某些情况下，服务提供商在其IGP中携带IXP地址，用于跨多个出口点的特定形式的流量工程。链路本地地址不能用于此目的；在这种情况下，服务提供商将不得不采用其他交通工程方法。
If an Internet Exchange Point is using a global prefix registered for this purpose, a traceroute will indicate whether the trace crosses an IXP rather than a private interconnect. If link-local addressing is used instead, a traceroute will not provide this distinction.
如果Internet交换点使用为此目的注册的全局前缀，则跟踪路由将指示跟踪是否跨越IXP而不是专用互连。如果改为使用链路本地寻址，跟踪路由将不会提供这种区别。
Exclusively using link-local addressing on infrastructure links has a number of advantages and disadvantages, both of which are described in detail in this document. A network operator can use this document to evaluate whether or not using link-local addressing on
在基础设施链路上专门使用链路本地寻址有许多优点和缺点，本文将详细介绍这两个优点和缺点。网络运营商可以使用此文档评估是否在网络上使用链路本地寻址
infrastructure links is a good idea in the context of his/her network. This document makes no particular recommendation either in favor or against.
在他/她的网络环境中，基础设施链接是一个好主意。本文件未提出赞成或反对的特别建议。
Using only LLAs on infrastructure links reduces the attack surface of a router. Loopback interfaces with routed addresses are still reachable and must be secured, but infrastructure links can only be attacked from the local link. This simplifies security of control and management planes. The approach does not impact the security of the data plane. The link-local-only approach does not address control plane [RFC6192] attacks generated by data plane packets (such as hop-limit expiration or packets containing a hop-by-hop extension header).
在基础设施链路上仅使用LLA可以减少路由器的攻击面。具有路由地址的环回接口仍然可以访问，并且必须加以保护，但基础设施链接只能从本地链接受到攻击。这简化了控制和管理平面的安全性。该方法不会影响数据平面的安全性。仅链路本地方法不解决由数据平面数据包（例如跳限制过期或包含逐跳扩展头的数据包）生成的控制平面[RFC6192]攻击。
For additional security considerations, as previously stated, see also [RFC5837] and [BGP-OPSEC].
如前所述，有关其他安全注意事项，请参见[RFC5837]和[BGP-OPSEC]。
[BGP-OPSEC] Durand, J., Pepelnjak, I., and G. Doering, "BGP operations and security", Work in Progress, draft-ietf-opsec-bgp-security-05, August 2014.
[BGP-OPSEC]Durand，J.，Pepelnjak，I.，和G.Doering，“BGP运营和安全”，在建工程，草案-ietf-OPSEC-BGP-security-052014年8月。
[IS-IS] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO Standard 10589, 2002.
[IS-IS]国际标准化组织，“与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，ISO标准10589，2002年。
[RFC0495] McKenzie, A., "Telnet Protocol specifications", RFC 495, May 1973, <http://www.rfc-editor.org/info/rfc0495>.
[RFC0495]McKenzie，A.，“Telnet协议规范”，RFC 495，1973年5月<http://www.rfc-editor.org/info/rfc0495>.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990, <http://www.rfc-editor.org/info/rfc1157>.
[RFC1157]Case，J.，Fedor，M.，Schoffstall，M.，和J.Davin，“简单网络管理协议（SNMP）”，STD 15，RFC 1157，1990年5月<http://www.rfc-editor.org/info/rfc1157>.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997, <http://www.rfc-editor.org/info/rfc2080>.
[RFC2080]Malkin，G.和R.Minnear，“IPv6的RIPng”，RFC20801997年1月<http://www.rfc-editor.org/info/rfc2080>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月<http://www.rfc-editor.org/info/rfc3704>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005, <http://www.rfc-editor.org/info/rfc4007>.
[RFC4007]Deering，S.，Haberman，B.，Jinmei，T.，Nordmark，E.，和B.Zill，“IPv6作用域地址体系结构”，RFC 4007，2005年3月<http://www.rfc-editor.org/info/rfc4007>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月<http://www.rfc-editor.org/info/rfc4193>.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[RFC4251]Ylonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 42512006年1月<http://www.rfc-editor.org/info/rfc4251>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月<http://www.rfc-editor.org/info/rfc4271>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月<http://www.rfc-editor.org/info/rfc4443>.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, October 2006, <http://www.rfc-editor.org/info/rfc4609>.
[RFC4609]Savola，P.，Lehtonen，R.，和D.Meyer，“协议独立多播-稀疏模式（PIM-SM）多播路由安全问题和增强”，RFC 4609，2006年10月<http://www.rfc-editor.org/info/rfc4609>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月<http://rfc-editor.org/info/rfc4861>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007, <http://www.rfc-editor.org/info/rfc4987>.
[RFC4987]Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，2007年8月<http://www.rfc-editor.org/info/rfc4987>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月<http://www.rfc-editor.org/info/rfc5340>.
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010, <http://www.rfc-editor.org/info/rfc5837>.
[RFC5837]Atlas，A.，Bonica，R.，Pignataro，C.，Shen，N.，和JR.Rivers，“为接口和下一跳识别扩展ICMP”，RFC 5837，2010年4月<http://www.rfc-editor.org/info/rfc5837>.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011, <http://www.rfc-editor.org/info/rfc6192>.
[RFC6192]Dugal，D.，Pignataro，C.，和R.Dunn，“保护路由器控制平面”，RFC 61922011年3月<http://www.rfc-editor.org/info/rfc6192>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月<http://www.rfc-editor.org/info/rfc6724>.
[RFC6752] Kirkham, A., "Issues with Private IP Addressing in the Internet", RFC 6752, September 2012, <http://www.rfc-editor.org/info/rfc6752>.
[RFC6752]Kirkham，A.“互联网中的私有IP地址问题”，RFC 67522012年9月<http://www.rfc-editor.org/info/rfc6752>.
[RFC6860] Yang, Y., Retana, A., and A. Roy, "Hiding Transit-Only Networks in OSPF", RFC 6860, January 2013, <http://www.rfc-editor.org/info/rfc6860>.
[RFC6860]Yang，Y.，Retana，A.和A.Roy，“在OSPF中隐藏公交专用网络”，RFC 68602013年1月<http://www.rfc-editor.org/info/rfc6860>.
Acknowledgments
致谢
The authors would like to thank Salman Asadullah, Brian Carpenter, Bill Cerveny, Benoit Claise, Rama Darbha, Simon Eng, Wes George, Fernando Gont, Jen Linkova, Harald Michl, Janos Mohacsi, Ivan Pepelnjak, Alvaro Retana, Jinmei Tatuya, and Peter Yee for their useful comments about this work.
作者要感谢萨尔曼·阿萨杜拉、布赖恩·卡彭特、比尔·塞维尼、贝诺特·克莱斯、拉玛·达尔巴、西蒙·恩格、韦斯·乔治、费尔南多·冈特、詹·林科娃、哈拉尔德·米克尔、亚诺斯·莫哈西、伊万·佩佩尔尼亚克、阿尔瓦罗·雷塔纳、金美·塔图亚和彼得·耶因对这部作品的有益评论。
Authors' Addresses
作者地址
Michael Behringer Cisco Building D, 45 Allee des Ormes Mougins 06250 France
Michael Behringer Cisco D栋，45 Allee des Ormes Mougins法国06250
EMail: mbehring@cisco.com
EMail: mbehring@cisco.com
Eric Vyncke Cisco De Kleetlaan, 6A Diegem 1831 Belgium
Eric Vyncke Cisco De Kleetlaan，6A Diegem 1831比利时
EMail: evyncke@cisco.com
EMail: evyncke@cisco.com