Independent Submission F. Templin
Request for Comments: 5720 Boeing Phantom Works
Category: Informational February 2010
ISSN: 2070-1721
Independent Submission F. Templin
Request for Comments: 5720 Boeing Phantom Works
Category: Informational February 2010
ISSN: 2070-1721
Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)
具有全局企业递归（RANGER）的网络中的路由和寻址
Abstract
摘要
RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence.
RANGER是一个架构框架，用于在具有全局企业递归的网络中进行可伸缩的路由和寻址。在此上下文中，“企业网络”一词扩展到各种各样的用例和部署场景，其中“企业”可以小到一个小型办公室、家庭办公室（SOHO）网络、动态的移动自组织网络、复杂的多组织公司，或大到全球互联网本身。这样的网络需要一个架构解决方案来协调路由和寻址计划，并考虑可伸缩性、提供商独立性、移动性、多址和安全性。这些注意事项对于现有部署尤其适用，但相同的原则甚至适用于干净的方法。RANGER体系结构解决了这些需求，并为IPv6/IPv4共存提供了一个全面的框架。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc5720.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5720.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. The RANGER Architecture .........................................7
3.1. Routing and Addressing .....................................7
3.2. The Enterprise-within-Enterprise Framework .................9
3.3. Virtual Enterprise Traversal (VET) ........................12
3.3.1. RANGER Organizational Principles ...................12
3.3.2. RANGER End-to-End Addressing Example ...............14
3.3.3. Dynamic Routing and On-Demand Mapping ..............14
3.3.4. Support for Legacy RLOC-Based Services .............16
3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL) ......18
3.5. Mobility Management .......................................18
3.6. Multihoming ...............................................20
3.7. Implications for the Internet .............................20
4. Related Initiatives ............................................21
5. Security Considerations ........................................22
6. Acknowledgements ...............................................23
7. References .....................................................23
7.1. Normative References ......................................23
7.2. Informative References ....................................24
1. Introduction ....................................................3
2. Terminology .....................................................4
3. The RANGER Architecture .........................................7
3.1. Routing and Addressing .....................................7
3.2. The Enterprise-within-Enterprise Framework .................9
3.3. Virtual Enterprise Traversal (VET) ........................12
3.3.1. RANGER Organizational Principles ...................12
3.3.2. RANGER End-to-End Addressing Example ...............14
3.3.3. Dynamic Routing and On-Demand Mapping ..............14
3.3.4. Support for Legacy RLOC-Based Services .............16
3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL) ......18
3.5. Mobility Management .......................................18
3.6. Multihoming ...............................................20
3.7. Implications for the Internet .............................20
4. Related Initiatives ............................................21
5. Security Considerations ........................................22
6. Acknowledgements ...............................................23
7. References .....................................................23
7.1. Normative References ......................................23
7.2. Informative References ....................................24
RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a SOHO network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and also provides a comprehensive framework for IPv6/ IPv4 coexistence [COEXIST].
RANGER是一个架构框架，用于在具有全局企业递归的网络中进行可伸缩的路由和寻址。在此上下文中，“企业网络”一词扩展到各种各样的用例和部署场景，其中“企业”可以小到SOHO网络，动态到移动自组织网络，复杂到多组织公司，或大到全球互联网本身。这样的网络需要一个架构解决方案来协调路由和寻址计划，并考虑可伸缩性、提供商独立性、移动性、多址和安全性。这些注意事项对于现有部署尤其适用，但相同的原则甚至适用于干净的方法。RANGER体系结构解决了这些需求，并为IPv6/IPv4共存[共存]提供了一个全面的框架。
RANGER provides a unifying architecture for enterprises that contain one or more distinct interior IP routing and addressing domains (or "Routing LOCator (RLOC) space"), with each distinct RLOC space containing one or more organizational groupings. Each RLOC space may coordinate their own internal addressing plans independently of one another, such that limited-scope addresses (e.g., [RFC1918] private-use IPv4 addresses) may be reused with impunity to provide unlimited scaling through spatial reuse. Each RLOC space therefore appears as an enterprise unto itself, where organizational partitioning of the enterprise into one or more "sub-enterprises" (or "sites") is also possible and beneficial in many scenarios. Without an architected approach, routing and addressing within such a framework would be fragmented due to address/prefix reuse between disjoint enterprises. With RANGER, however, multiple enterprises can be linked together to provide a multi-hop transit for nodes attached to enterprise edge networks that use Endpoint Interface iDentifier (EID) addresses taken from an IP addressing range that is distinct from any RLOC space.
RANGER为包含一个或多个不同内部IP路由和寻址域（或“路由定位器（RLOC）空间”）的企业提供了统一的体系结构，每个不同的RLOC空间包含一个或多个组织分组。每个RLOC空间可以相互独立地协调它们自己的内部寻址计划，这样有限范围的地址（例如，[RFC1918]专用IPv4地址）可以不受惩罚地重用，从而通过空间重用提供无限的扩展。因此，每个RLOC空间本身看起来是一个企业，在许多情况下，将企业组织划分为一个或多个“子企业”（或“站点”）也是可能的，也是有益的。如果没有体系结构的方法，由于地址/前缀在不相交的企业之间重用，这种框架内的路由和寻址将变得支离破碎。但是，使用RANGER，可以将多个企业链接在一起，为连接到企业边缘网络的节点提供多跳传输，这些网络使用端点接口标识符（EID）地址，这些地址取自不同于任何RLOC空间的IP寻址范围。
RANGER is recursive in that multiple enterprises can be joined together in a nested "enterprise-within-enterprise" fashion, where each enterprise also connects edge networks with nodes that configure addresses taken from EID space to support edge/core separation. In this way, the same RANGER principles that apply in lower levels of recursion can extend upwards to parent enterprises and ultimately to the core of the global Internet itself. Furthermore, it is also worth considering whether today's global Internet represents a limiting condition for recursion -- in particular, whether other internets could be manifested as "parallel universes" and joined together at still higher levels of recursion.
RANGER是递归的，因为多个企业可以以嵌套的“企业内企业”方式连接在一起，其中每个企业还将边缘网络与配置从EID空间获取的地址以支持边缘/核心分离的节点连接起来。通过这种方式，同样适用于较低递归级别的RANGER原则可以向上扩展到母公司，并最终扩展到全球互联网本身的核心。此外，还值得考虑的是，今天的全球互联网是否代表了递归的一个限制条件——特别是，其他互联网是否可以表现为“并行宇宙”，并以更高的递归级别连接在一起。
The RANGER architecture is manifested through composite technologies, including Virtual Enterprise Traversal (VET) [VET], the Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL], and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]. Other mechanisms such as IPsec [RFC4301] are also in scope for use within certain scenarios.
RANGER架构通过复合技术表现出来，包括虚拟企业遍历（VET）[VET]、子网封装和适配层（SEAL）[SEAL]和站点内自动隧道寻址协议（ISATAP）[RFC5214]。其他机制，如IPsec[RFC4301]也可在某些场景中使用。
Noting that combinations with still other technologies are also possible, the issues addressed either in full or in part by RANGER include:
注意到与其他技术的结合也是可能的，RANGER全部或部分解决的问题包括：
o scalable routing and addressing
o 可扩展路由和寻址
o provider-independent addressing and its relation to provider-aggregated addressing
o 提供程序独立寻址及其与提供程序聚合寻址的关系
o site mobility and multihoming
o 站点移动性和多址
o address and prefix autoconfiguration
o 地址和前缀自动配置
o border router discovery
o 边界路由器发现
o router/host-to-router/host tunneling
o 路由器/主机到路由器/主机隧道
o neighbor discovery over tunnels
o 隧道上的邻居发现
o MTU determination for tunnels
o 隧道MTU的确定
o IPv6/IPv4 coexistence and transition
o IPv6/IPv4共存与转换
Note that while this document primarily uses the illustrative example of IPv6 [RFC2460] as a virtual overlay over IPv4 [RFC0791] networks, it is important to note that the same architectural principles apply to any combination of IPvX virtual overlays over IPvY networks.
请注意，虽然本文档主要使用IPv6[RFC2460]的示例作为IPv4[RFC0791]网络上的虚拟覆盖，但需要注意的是，相同的体系结构原则适用于IPvY网络上的IPvX虚拟覆盖的任何组合。
Routing Locator (RLOC) an IPv4 or IPv6 address assigned to an interface in an enterprise-interior routing region. Note that private-use IP addresses are local to each enterprise; hence, the same private-use addresses may appear within disjoint enterprises.
路由定位器（RLOC）：分配给企业内部路由区域中接口的IPv4或IPv6地址。请注意，专用IP地址是每个企业的本地地址；因此，相同的专用地址可能出现在不相交的企业中。
Endpoint Interface iDentifier (EID) an IPv4 or IPv6 address assigned to an edge network interface of an end system. Note that EID space must be separate and distinct from any RLOC space.
端点接口标识符（EID）：分配给终端系统边缘网络接口的IPv4或IPv6地址。请注意，EID空间必须与任何RLOC空间分开且不同。
commons an enterprise-interior routing region that provides a subnetwork for cooperative peering between the border routers of diverse organizations that may have competing interests. A prime example of a commons is the Default-Free Zone (DFZ) of the global Internet. The enterprise-interior routing region within the commons uses an addressing plan taken from RLOC space.
commons一个企业内部路由区域，为可能有竞争利益的不同组织的边界路由器之间的协作对等提供子网。公共空间的一个主要例子是全球互联网的默认自由区（DFZ）。公共空间内的企业内部路由区域使用取自RLOC空间的寻址计划。
enterprise the same as defined in [RFC4852], where the enterprise deploys a unified RLOC space addressing plan within the commons but may also contain partitions with disjoint RLOC spaces and/or organizational groupings that can be considered as enterprises unto themselves. An enterprise therefore need not be "one big happy family", but instead provides a commons for the cooperative interconnection of diverse organizations that may have competing interests (e.g., such as the case within the global Internet DFZ).
企业与[RFC4852]中定义的相同，其中企业在公共空间内部署统一的RLOC空间寻址计划，但也可能包含具有不相交的RLOC空间和/或组织分组的分区，这些分区可以被视为企业本身。因此，企业不必是“一个幸福的大家庭”，而是为可能有竞争利益的不同组织之间的合作互联提供一个共同点（例如，全球互联网DFZ内的情况）。
Enterprise networks are typically associated with large corporations or academic campuses; however, the RANGER architectural principles apply to any network that has some degree of cooperative active management. This definition therefore extends to home networks, small office networks, ISP networks, a wide variety of Mobile Ad Hoc Networks (MANETs), and even to the global Internet itself.
企业网络通常与大公司或学术校园相关联；然而，RANGER体系结构原则适用于任何具有某种程度的协同主动管理的网络。因此，这一定义扩展到家庭网络、小型办公网络、ISP网络、各种移动自组织网络（MANET），甚至全球互联网本身。
site a logical and/or physical grouping of interfaces within an enterprise commons, where the topology of the site is a proper subset of the topology of the enterprise. A site may contain many interior sites, which may themselves contain many interior sites in a recursive fashion.
站点：企业公共空间内接口的逻辑和/或物理分组，其中站点的拓扑是企业拓扑的适当子集。一个站点可能包含许多内部站点，这些站点本身可能以递归方式包含许多内部站点。
Throughout the remainder of this document, the term "enterprise" refers to either enterprise or site, i.e., the RANGER principles apply equally to enterprises and sites of any size or shape. At the lowest level of recursive decomposition, a singleton Enterprise Border Router can be considered as an enterprise unto itself.
在本文件其余部分，术语“企业”指企业或场所，即RANGER原则同样适用于任何规模或形状的企业和场所。在递归分解的最低级别，单例企业边界路由器可以被视为企业本身。
Enterprise Border Router (EBR) a router at the edge of an enterprise that is also configured as a tunnel endpoint in an overlay network. EBRs connect their directly attached networks to the overlay network, and connect to other networks via IP-in-IP tunneling across the commons to other EBRs. This definition is intended as an architectural equivalent of the functional term "EBR" defined in [VET].
企业边界路由器（EBR）位于企业边缘的路由器，也被配置为覆盖网络中的隧道端点。EBR将其直接连接的网络连接到覆盖网络，并通过IP-in-IP隧道通过公共空间连接到其他EBR，从而连接到其他网络。该定义旨在作为[VET]中定义的功能术语“EBR”的架构等效物。
Enterprise Border Gateway (EBG) an EBR that also connects the enterprise to provider networks and/or to the global Internet. EBGs are typically configured as default routers in the overlay and provide forwarding services for accessing IP networks not reachable via an EBR within the commons. This definition is intended as an architectural equivalent of the functional term "EBG" defined in [VET], and is synonymous with the term "default mapper" used in other contexts (e.g., [JEN]).
企业边界网关（EBG）一种EBR，它还将企业连接到提供商网络和/或全球互联网。EBG通常配置为覆盖中的默认路由器，并提供转发服务，用于访问公共空间中无法通过EBR访问的IP网络。该定义旨在作为[VET]中定义的功能术语“EBG”的架构等效物，并与其他上下文（例如[JEN]）中使用的术语“默认映射器”同义。
Ingress Tunnel Endpoint (ITE) a host or router interface that encapsulates inner IP packets within an outer IP header for transmission over an enterprise-interior routing region to the RLOC address of an Egress Tunnel Endpoint (ETE).
入口隧道端点（ITE）主机或路由器接口，将内部IP数据包封装在外部IP报头内，以便通过企业内部路由区域传输到出口隧道端点（ETE）的RLOC地址。
Egress Tunnel Endpoint (ETE) a host or router interface that receives encapsulated packets sent to its RLOC address, decapsulates the inner IP packets, then delivers them to the EID address of the final destination.
出口隧道端点（ETE）主机或路由器接口，接收发送到其RLOC地址的封装数据包，解除内部IP数据包的封装，然后将其发送到最终目的地的EID地址。
overlay network a virtual network manifested by routing and addressing over virtual links formed through automatic tunneling. An overlay network may span many underlying enterprises.
覆盖网络通过自动隧道形成的虚拟链路上的路由和寻址显示的虚拟网络。覆盖网络可能跨越许多底层企业。
Provider-Independent (PI) prefix an IPv6 or IPv4 EID prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) that is routable within a limited scope and may also appear in enterprise mapping tables. PI prefixes that can appear in mapping tables are typically delegated to a Border Router (BR) by a registry but are not aggregated by a provider network. Local-use IPv6 and IPv4 prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of a PI prefix, but these typically do not appear in mapping tables.
独立于提供商（PI）前缀IPv6或IPv4 EID前缀（例如，2001:DB8:：/48、192.0.2/24等），可在有限范围内路由，也可能出现在企业映射表中。可以出现在映射表中的PI前缀通常由注册表委托给边界路由器（BR），但不由提供者网络聚合。本地使用IPv6和IPv4前缀（例如FD00:：/8、192.168/16等）是PI前缀的另一个示例，但它们通常不会出现在映射表中。
Provider-Aggregated (PA) prefix an IPv6 or IPv4 EID prefix that is either derived from a PI prefix or delegated directly to a provider network by a registry. Although not widely discussed, it bears specific mention that a prefix taken from a delegating router's PI space becomes a PA prefix from the perspective of the requesting router.
提供程序聚合（PA）前缀IPv6或IPv4 EID前缀，从PI前缀派生或由注册表直接委托给提供程序网络。虽然没有广泛讨论，但它特别提到，从请求路由器的角度来看，从委托路由器的PI空间获取的前缀成为PA前缀。
Additionally, RANGER provides an informative consideration of functional specifications and operational practices outlined in other documents. These documents include:
此外，RANGER还提供了对其他文件中概述的功能规范和操作实践的详细考虑。这些文件包括：
6over4 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels [RFC2529]; functional specifications and operational practices for automatic tunneling of unicast/multicast IPv6 packets over multicast-capable IPv4 enterprises.
6IPv4域上的IPv6 over4传输，无显式隧道[RFC2529]；支持多播的IPv4企业上单播/多播IPv6数据包自动隧道的功能规范和操作规程。
ISATAP Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]; functional specifications and operational practices for automatic tunneling of unicast IPv6 packets over unicast-only IPv4 enterprises.
ISATAP站点内自动隧道寻址协议（ISATAP）[RFC5214]；仅单播IPv4企业上单播IPv6数据包自动隧道的功能规范和操作规程。
VET Virtual Enterprise Traversal (VET) [VET]; functional specifications and operational practices for automatic tunneling of both unicast and multicast IP packets with provisions for address/prefix autoconfiguration, provider-independent addressing, mobility, multihoming, and security. VET is descended from both 6over4 and ISATAP and is also known as "ISATAP version 2 (ISATAPv2)".
虚拟企业遍历（VET）[VET]；单播和多播IP数据包自动隧道的功能规范和操作规程，包括地址/前缀自动配置、独立于提供商的寻址、移动性、多址和安全性。VET是6over4和ISATAP的后代，也称为“ISATAP版本2（ISATAPv2）”。
SEAL Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL]; an encapsulation sublayer that provides an extended IP Identification field and mechanisms for link MTU adaptation over tunnels.
密封子网封装和适配层（SEAL）[SEAL]；封装子层，提供扩展的IP标识字段和隧道上链路MTU适配机制。
The RANGER architecture enables scalable routing and addressing in networks with global enterprise recursion while sustaining support for legacy networks and services. Key to this approach is a framework that accommodates interconnection of diverse organizations across a commons that have a mutual spirit of cooperation but also have the potential for competing interests. The following sections outline the RANGER architecture within the context of anticipated use cases:
RANGER体系结构支持在具有全局企业递归的网络中进行可扩展的路由和寻址，同时支持遗留网络和服务。这种方法的关键是一个框架，该框架能够容纳跨公共领域的不同组织之间的互连，这些组织具有相互合作的精神，但也具有竞争利益的潜力。以下各节概述了预期用例上下文中的RANGER架构：
The Internet today is facing "growing pains", with indications that core Routing Information Base (RIB) scaling may not be sustainable over the long term and that the remaining space for IPv4 address allocations may be depleted in the near future. Therefore, there is an emerging need for scalable routing and addressing solutions. It must further be noted that the same solutions selected to address global Internet routing and addressing scaling can apply equally for large enterprises -- or for any enterprise that would benefit from a separation of core and edge addressing domains.
今天的互联网正面临“成长之痛”，有迹象表明核心路由信息库（RIB）的扩展可能无法长期持续，IPv4地址分配的剩余空间可能在不久的将来耗尽。因此，对可扩展的路由和寻址解决方案的需求正在出现。必须进一步指出的是，为解决全球互联网路由和寻址扩展问题而选择的相同解决方案同样适用于大型企业——或任何将从核心和边缘寻址域分离中获益的企业。
RANGER supports scalable routing through an approach that parallels the "New Scheme for Internet Routing and Addressing" described in [RFC1955]. This approach is also commonly known as "map-and-encaps". In this approach, an Ingress Tunnel Endpoint (ITE) that must forward an IP packet first consults a mapping system to discover a mapping for the destination Endpoint Interface iDentifier (EID) to a Routing LOCator (RLOC) assigned to an Egress Tunnel Endpoint (ETE). The mapping system is typically maintained as a per-enterprise distributed database that is synchronized among a limited set of mapping agents. Distributed database management alternatives include a routing protocol instance maintained by Enterprise Border Gateways (EBGs), a DNS reverse zone distributed among a restricted set of caching servers, etc. Mapping entries are inserted into the mapping system through administrative configuration, automated prefix registrations, etc.
RANGER通过一种与[RFC1955]中描述的“互联网路由和寻址新方案”类似的方法支持可伸缩路由。这种方法通常也被称为“映射和封装”。在该方法中，必须转发IP分组的入口隧道端点（ITE）首先咨询映射系统，以发现目标端点接口标识符（EID）到分配给出口隧道端点（ETE）的路由定位器（RLOC）的映射。映射系统通常作为每个企业的分布式数据库进行维护，该数据库在一组有限的映射代理之间进行同步。分布式数据库管理备选方案包括由企业边界网关（EBG）维护的路由协议实例、分布在一组受限缓存服务器之间的DNS反向区域等。映射条目通过管理配置、自动前缀注册等插入映射系统。
RANGER allows for an ITE to either consult the mapping system itself (while delaying or dropping initial IP packets) or forward initial packets to an EBG acting as a "default mapper". In either case, the ITE receives a mapping reply that it can use to populate its Forwarding Information Base (FIB). The choice of mapping approaches must be considered with respect to the individual enterprise network scenario, e.g., forwarding to an EBG may be more appropriate in some scenarios while ITE self-discovery may be more appropriate in others. Use of other mapping mechanisms is also possible according to the specific enterprise scenario.
RANGER允许ITE咨询映射系统本身（同时延迟或丢弃初始IP数据包），或将初始数据包转发给充当“默认映射器”的EBG。在任何一种情况下，ITE都会收到一个映射回复，可以使用该回复填充其转发信息库（FIB）。必须针对单个企业网络场景考虑映射方法的选择，例如，在某些场景中，转发到EBG可能更合适，而在其他场景中，ITE自我发现可能更合适。根据特定的企业场景，也可以使用其他映射机制。
After discovering the mapping, the ITE encapsulates inner IP packets in an outer IP header for transmission across the commons to the RLOC address of an ETE. The ETE in turn decapsulates the packets and forwards them over the next hop toward the EID address of the final destination. Therefore, the Routing Information Base (RIB) within the commons only needs to maintain state regarding RLOCs and not EIDs, while the synchronized EID-to-RLOC mapping state is maintained by a smaller number of nodes and is not subject to oscillations due to link state changes within the commons. Finally, EIDs are routable only within a limited scope within edge networks (which may be as small as node-local scope in the limiting case).
在发现映射后，ITE将内部IP数据包封装在外部IP报头中，以便通过公共空间传输到ETE的RLOC地址。ETE依次解除数据包的封装，并在下一跳中将其转发到最终目的地的EID地址。因此，公共空间内的路由信息库（RIB）只需要维护关于RLOC而不是EID的状态，而同步EID到RLOC的映射状态由较少数量的节点维护，并且不会由于公共空间内的链路状态变化而受到振荡。最后，EID只能在边缘网络的有限范围内进行路由（在有限的情况下，可能与节点本地范围一样小）。
RANGER supports scalable addressing by selecting a suitably large EID addressing range that is distinct and kept separate from any enterprise-interior RLOC addressing ranges. It should therefore come as no surprise that taking EID space from the IPv6 addressing architecture should lead to a viable, scalable addressing alternative, while taking EID space from the (already exhausted) IPv4 addressing architecture may not.
RANGER通过选择一个适当大的EID寻址范围来支持可伸缩寻址，该范围与任何企业内部RLOC寻址范围不同并保持独立。因此，毫不奇怪，从IPv6寻址体系结构中获取EID空间将导致一种可行的、可扩展的寻址替代方案，而从（已经耗尽的）IPv4寻址体系结构中获取EID空间可能不会。
Enterprise networks traditionally distribute routing information via Interior Gateway Protocols (IGPs) such as Open Shortest Path First (OSPF), while large enterprises may even use an Exterior Gateway Protocol (EGP) internally in place of an IGP. Thus, it is becoming increasingly commonplace for large enterprises to use the Border Gateway Protocol (BGP) internally and independently from the BGP instance that maintains the RIB within the global Internet DFZ.
传统上，企业网络通过内部网关协议（IGP）分发路由信息，如开放最短路径优先（OSPF），而大型企业甚至可以在内部使用外部网关协议（EGP）代替IGP。因此，大型企业在内部使用边界网关协议（BGP）变得越来越普遍，并独立于在全球互联网DFZ内维护RIB的BGP实例。
As such, large enterprises may run an internal instance of BGP across many internal Autonomous Systems (ASs). Such a large enterprise can therefore appear as an internet unto itself, albeit with default routes leading to the true global Internet. Additionally, each internal AS within such an enterprise may itself run BGP internally in place of an IGP, and can therefore also appear as an independent, lower-tier enterprise unto itself. This enterprise-within-enterprise framework can be extended in a recursive fashion as broadly and as deeply as desired to achieve scaling factors as well as organizational and/or functional compartmentalization, e.g., as shown in Figure 1.
因此，大型企业可以跨许多内部自治系统（ASs）运行BGP的内部实例。因此，这样一个大型企业可以作为一个互联网出现在自己的面前，尽管默认的路由通向真正的全球互联网。此外，这样一个企业内部的每一个内部组织本身都可以在内部运行BGP来代替IGP，因此也可以作为一个独立的、较低级别的企业出现。企业框架中的企业可以以递归的方式进行扩展，扩展的范围和深度可以达到所需的比例因子以及组织和/或功能划分，如图1所示。
,---------------.
,-' Global `-. <--------+
( IPv6/IPv4 ) ,----|-----.
`-. Internet ,-' ( Enterprises)
`+--+..+--+ ...+--+ ( E2 thru EN )
_.-|R1|--|R2+----|Rn|-._ `.---------/
_.---'' +--+ +--+ ...+--+ -.
,--'' ,---. `---.
,-' X5 X6 .---.. `-.
,' ,.X1-.. / \ ,' `. `.
,' ,' `. .' E1.2 '. X8 E1.m \ `.
/ / \ | ,--. | / _,.._ \ \
/ / E1.1 \ | Y3 `. | | / Y7 | \
; | ___ | | ` W Y4 |... | `Y6 ,' | :
| | ,-' `. X2 | `--' | | `'' | |
: | | V Y2 | \ _ / | | ;
\ | `-Y1,,' | \ .' Y5 / \ ,-Y8'`- / /
\ \ / \ \_' / X9 `. ,'/ /
`. \ X3 `.__,,' `._ Y9'',' ,'
` `._ _,' ___.......X7_ `---' ,'
` `---' ,-' `-. -'
`---. `. E1.3 Z _' _.--'
`-----. \---.......---' _.---''
`----------------''
,---------------.
,-' Global `-. <--------+
( IPv6/IPv4 ) ,----|-----.
`-. Internet ,-' ( Enterprises)
`+--+..+--+ ...+--+ ( E2 thru EN )
_.-|R1|--|R2+----|Rn|-._ `.---------/
_.---'' +--+ +--+ ...+--+ -.
,--'' ,---. `---.
,-' X5 X6 .---.. `-.
,' ,.X1-.. / \ ,' `. `.
,' ,' `. .' E1.2 '. X8 E1.m \ `.
/ / \ | ,--. | / _,.._ \ \
/ / E1.1 \ | Y3 `. | | / Y7 | \
; | ___ | | ` W Y4 |... | `Y6 ,' | :
| | ,-' `. X2 | `--' | | `'' | |
: | | V Y2 | \ _ / | | ;
\ | `-Y1,,' | \ .' Y5 / \ ,-Y8'`- / /
\ \ / \ \_' / X9 `. ,'/ /
`. \ X3 `.__,,' `._ Y9'',' ,'
` `._ _,' ___.......X7_ `---' ,'
` `---' ,-' `-. -'
`---. `. E1.3 Z _' _.--'
`-----. \---.......---' _.---''
`----------------''
<---------------- Enterprise E1 ---------------->
<---------------- Enterprise E1 ---------------->
Figure 1: Enterprise-within-Enterprise Framework
图1：企业框架内的企业
Figure 1 depicts an enterprise 'E1' connected to the global IPv6/IPv4 Internet via routers 'R1' through 'Rn' and additional enterprises 'E2' through 'EN' that also connect to the global Internet. Within the 'E1' commons, there may be arbitrarily many hosts, routers, and networks (not shown in the diagram) that use addresses taken from RLOC space and over which both encapsulated and unencapsulated IP packets can be forwarded. There may also be many lower-tier enterprises, 'E1.1' through 'E1.m' (shown in the diagram), that interconnect within the 'E1' commons via Enterprise Border Routers (EBRs), depicted as 'X1' through 'X9' (where 'X1' through 'X9' see 'R1' through 'Rn' as EBGs). Within each 'E1.*' enterprise, there may also be arbitrarily many lower-tier enterprises that interconnect within the 'E1.*' commons via EBRs, depicted as 'Y1' through 'Y9' in the diagram (where 'Y1' through 'Y9' see 'X1' through 'X9' as EBGs). This recursive decomposition can be nested as deeply as desired and ultimately terminates at singleton nodes such as those depicted as 'V', 'W', and 'Z' in the diagram.
图1描述了通过路由器“R1”到“Rn”连接到全球IPv6/IPv4互联网的企业“E1”，以及通过同样连接到全球互联网的其他企业“E2”到“EN”。在“E1”公用区内，可能有任意多个主机、路由器和网络（图中未显示），它们使用从RLOC空间获取的地址，通过这些地址可以转发封装和未封装的IP数据包。也可能有许多低层企业，“E1.1”到“E1.m”（如图所示），它们通过企业边界路由器（EBR）在“E1”公用区内互连，被描述为“X1”到“X9”（其中“X1”到“X9”参见“R1”到“Rn”作为EBG）。在每个“E1.*”企业中，也可能有任意多个较低层的企业通过EBR在“E1.*”公共区内互连，在图中被描述为“Y1”到“Y9”（其中“Y1”到“Y9”参见“X1”到“X9”作为EBG）。这种递归分解可以根据需要进行深度嵌套，并最终终止于单例节点，如图中描述为“V”、“W”和“Z”的节点。
It is important to note that nodes such as 'V', 'W', and 'Z' may be simple hosts or they may be EBRs that attach arbitrarily complex edge networks with addresses taken from EID space. Such edge networks could be as simple as a home network behind a residential gateway or as complex as a major corporate/academic campus, a large service provider network, etc.
需要注意的是，“V”、“W”和“Z”等节点可能是简单主机，也可能是连接任意复杂边缘网络的EBR，地址取自EID空间。这种边缘网络可以像住宅网关后面的家庭网络一样简单，也可以像大型企业/学术校园、大型服务提供商网络等一样复杂。
Again, this enterprise-within-enterprise framework can be recursively nested as broadly and deeply as desired. From the highest level of the recursion, consider now that the global Internet itself can be viewed as an "enterprise" that interconnects lower-tier enterprises E1 through EN such that all RANGER architectural principles apply equally within that context. Furthermore, the RANGER architecture recognizes that the global Internet need not represent a limiting condition for recursion, but rather allows that other internets could be manifested as "parallel universes" and joined together at still higher levels of recursion.
同样，企业框架中的这个企业可以根据需要递归地进行广泛和深入的嵌套。从递归的最高级别，现在考虑全球互联网本身可以被看作是一个“企业”，互连低层企业E1到EN，使得所有游侠架构原则在该上下文中同样适用。此外，RANGER体系结构认识到，全球互联网不需要代表递归的限制条件，而是允许其他互联网可以表现为“并行宇宙”，并以更高的递归级别连接在一起。
As a specific case in point, the future global Aeronautical Telecommunications Network (ATN), under consideration within the civil aviation industry [BAUER], will take the form of a large enterprise network that appears as an internet unto itself, i.e., exactly as depicted for 'E1' in Figure 1. Within the ATN, there will be many Air Communications Service Provider (ACSP) and Air Navigation Service Provider (ANSP) networks organized as autonomous systems internal to the ATN, i.e., exactly as depicted for 'E1.*' in the diagram. The ACSP/ANSP network EBGs will participate in a BGP instance internal to the ATN, and may themselves run independent BGP instances internally that are further sub-divided into lower-tier enterprises organized as regional, organizational, functional, etc. compartments. It is important to note that, while ACSPs/ANSPs within the ATN will share a common objective of safety-of-flight for civil aviation services, there may be competing business/social/political interests between them, such that the ATN is not necessarily "one big happy family". Therefore, the model parallels that of the global Internet itself.
作为一个具体的例子，民航业[BAUER]正在考虑的未来全球航空电信网络（ATN）将采用大型企业网络的形式，该网络本身就是一个互联网，即，与图1中“E1”的描述完全相同。在ATN内，将有许多空中通信服务提供商（ACSP）和空中导航服务提供商（ANSP）网络组织为ATN内部的自治系统，即，完全如图中“E1.*”所示。ACSP/ANSP网络EBG将参与ATN内部的BGP实例，并且自身可以在内部运行独立的BGP实例，这些实例进一步细分为区域、组织、功能等划分的较低层企业。值得注意的是，虽然ATN内的ACSP/ANSP将共享民航服务飞行安全的共同目标，但它们之间可能存在竞争性的商业/社会/政治利益，因此ATN不一定是“一个幸福的大家庭”。因此，该模型与全球互联网本身的模型相似。
Such an operational framework may indeed be the case for many next-generation enterprises. In particular, although the routing and addressing arrangements of all enterprises will require a mutual level of cooperative active management at a certain level, free market forces, business objectives, political alliances, etc. may drive internal competition.
对于许多下一代企业来说，这种运营框架可能确实是如此。特别是，尽管所有企业的路线和地址安排都需要在一定程度上进行相互合作的积极管理，但自由市场力量、商业目标、政治联盟等可能会推动内部竞争。
Within the enterprise-within-enterprise framework outlined in Section 3.2, the RANGER architecture is based on overlay networks manifested through Virtual Enterprise Traversal (VET) ([VET], [RFC5214]). The VET approach uses automatic IP-in-IP tunneling in which ITEs encapsulate EID-based inner IP packets within RLOC-based, outer IP headers for transmission across the commons to ETEs.
在第3.2节概述的企业内企业框架内，RANGER体系结构基于通过虚拟企业遍历（VET）（[VET]，[RFC5214]）表现的覆盖网络。VET方法使用自动IP-in-IP隧道，其中ITE将基于EID的内部IP数据包封装在基于RLOC的外部IP报头中，以便通过公用网络传输到ETE。
For each enterprise they connect to, EBRs that use VET configure a Non-Broadcast, Multiple Access (NBMA) interface known as a "VET interface" that sees all other EBRs within the enterprise as potential single-hop neighbors from the perspective of the inner IP protocol. This means that, for many enterprise scenarios, standard neighbor discovery mechanisms (e.g., router advertisements, redirects, etc.) can be used between EBR pairs. This gives rise to a data-driven model in which neighbor relationships are formed based on traffic demand in the data plane, which in many cases can relax the requirement for dynamic routing exchanges across the overlay in the control plane.
对于他们连接到的每个企业，使用VET的EBR配置一个称为“VET接口”的非广播多址（NBMA）接口，该接口从内部IP协议的角度将企业内的所有其他EBR视为潜在的单跳邻居。这意味着，对于许多企业场景，EBR对之间可以使用标准邻居发现机制（例如，路由器广告、重定向等）。这就产生了一种数据驱动模型，在该模型中，邻居关系是根据数据平面中的流量需求形成的，在许多情况下，这可以缓解控制平面中覆盖层之间动态路由交换的需求。
When multiple VET interfaces are linked together, end-to-end traversal is seen as multiple VET hops from the perspective of the inner IP protocol. In that case, transition between VET interfaces entails a "re-encapsulation" approach in which a packet that exits VET interface 'i' is decapsulated then re-encapsulated before it is forwarded into VET interface 'i+1'. For example, if an end-to-end path between two EID-based peers crosses N distinct VET interfaces, a traceroute would show N inner IP forwarding hops corresponding to the portions of the path that traverse the VET interfaces.
当多个VET接口链接在一起时，从内部IP协议的角度来看，端到端遍历被视为多个VET跳。在这种情况下，VET接口之间的转换需要一种“重新封装”方法，在这种方法中，退出VET接口“i”的数据包被解封，然后在转发到VET接口“i+1”之前重新封装。例如，如果两个基于EID的对等点之间的端到端路径跨越N个不同的VET接口，则跟踪路由将显示N个内部IP转发跳，对应于穿过VET接口的路径部分。
VET and its related works specify necessary mechanisms and operational practices to manifest the RANGER architecture. The use of VET in conjunction with SEAL (see Section 3.4) is essential in certain deployments to avoid issues related to source address spoofing and black holing due to path Maximum Transmission Unit (MTU) limitations. (The use of VET in conjunction with IPsec [RFC4301] may also be necessary in some enterprise network scenarios.) The following sections discuss operational considerations and use cases within the VET approach.
VET及其相关工作规定了展示RANGER架构所需的机制和操作实践。在某些部署中，必须将VET与SEAL（见第3.4节）结合使用，以避免由于路径最大传输单元（MTU）限制而导致的源地址欺骗和黑洞问题。（在某些企业网络场景中，可能还需要将VET与IPsec[RFC4301]结合使用。）以下各节讨论了VET方法中的操作注意事项和用例。
Figure 2 below depicts a vertical slice (albeit represented horizontally) from the enterprise-within-enterprise framework shown in Figure 1:
下面的图2描述了图1所示的企业框架内企业的垂直切片（尽管是水平表示的）：
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) ----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +--- + v +----+ v +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ t +----+ +-----+-------+
" . | 1 . . 2 . . 3 . " |
" . H . . . . . " |
" . . . . . . . . . . . . . . " +--+---+
" <E1.1.1> <E1.1> <E1> " | IPv4 |
" 10/8 10/8 10/8 " |Server|
" " " " " " " " " " " " " " "" " " " " " " " | S2 |
<-- Enterprise E1 --> +------+
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) ----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +--- + v +----+ v +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ t +----+ +-----+-------+
" . | 1 . . 2 . . 3 . " |
" . H . . . . . " |
" . . . . . . . . . . . . . . " +--+---+
" <E1.1.1> <E1.1> <E1> " | IPv4 |
" 10/8 10/8 10/8 " |Server|
" " " " " " " " " " " " " " "" " " " " " " " | S2 |
<-- Enterprise E1 --> +------+
Figure 2: Virtual Enterprise Traversal
图2：虚拟企业遍历
Within this vertical slice, each enterprise within the 'E1' recursive hierarchy is spanned by VET interfaces, represented as 'vet1' through 'vet3'. Each VET interface within this framework is a Non-Broadcast, Multiple Access (NBMA) interface that connects all EBRs within the same enterprise. Each enterprise within the 'E1' hierarchy may comprise a smaller topological region within a larger RLOC space, or they may configure an independent RLOC space from a common (but spatially reused) limited-scope prefix, e.g., depicted as multiple disjoint instances of '10/8' in the diagram.
在这个垂直切片中，“E1”递归层次结构中的每个企业都有VET接口，表示为“vet1”到“vet3”。该框架内的每个VET接口都是一个非广播多址（NBMA）接口，用于连接同一企业内的所有EBR。“E1”层次结构中的每个企业可以包括较大RLOC空间中的较小拓扑区域，或者它们可以从公共（但在空间上重用）有限范围前缀配置独立的RLOC空间，例如，图中描述为“10/8”的多个不相交实例。
In the RANGER approach, EBRs within lower-tier enterprises coordinate their EID prefixes with EBGs that connect to an upper-tier enterprise. EID prefixes could be either provider-independent (PI) prefixes owned by the EBR or provider-aggregated (PA) prefixes delegated by the EBG. In either case, EID prefixes must be coordinated with the enterprise routing/mapping systems.
在RANGER方法中，下层企业中的EBR将其EID前缀与连接到上层企业的EBG进行协调。EID前缀可以是EBR拥有的独立于提供程序（PI）前缀，也可以是EBG委托的提供程序聚合（PA）前缀。无论哪种情况，EID前缀都必须与企业路由/映射系统协调。
When PA EID prefixes are used, the EBR for each 'E1*' enterprise receives an EID prefix delegation from a delegating EBG in a parent enterprise. In this example, when 'R2' is a delegating router for the prefix '2001:DB8::/40', it may delegate '2001:DB8::/48' to 'X2', which in turn delegates '2001:DB8::/52' to 'Y1', which in turn delegates '2001:DB8::/56' to 'V'. The preferred mechanism for this recursive PA prefix sub-delegation is DHCP Prefix Delegation [RFC3633], which also arranges for publication of the prefixes in the enterprise routing system.
当使用PA EID前缀时，每个“E1*”企业的EBR从母企业中的委派EBG接收EID前缀委派。在本例中，当“R2”是前缀“2001:DB8:：/40”的委托路由器时，它可能会将“2001:DB8:：/48”委托给“X2”，而“X2”又将“2001:DB8:：/52”委托给“Y1”，而“Y1”又将“2001:DB8:：/56”委托给“V”。此递归PA前缀子委托的首选机制是DHCP前缀委托[RFC3633]，它还安排在企业路由系统中发布前缀。
When PI EID prefixes are used, individual EBRs (e.g., 'V') register their PI prefixes (e.g., '2001:DB1:10::/56') by sending Router Advertisement (RA) messages to EBGs within the enterprise to assert prefix ownership. When stronger authentication is necessary, the EBRs can digitally sign the messages using the mechanisms specified for SEcure Neighbor Discovery (SEND) [RFC3971]. EBGs that receive the RAs (e.g., 'Y1') first verify the sender's credentials, then register the prefixes in the enterprise mapping system. Next, they forward a proxied version of the RA to EBGs within their parent enterprises (e.g., 'X2'). This proxying process continues up the recursive hierarchy until a default-free commons is reached. (In this case, the proxying process ends at 'R2'). After the initial registration, the EBR that owns the PI prefixes must periodically send additional RAs to update prefix expiration timers.
当使用PI EID前缀时，单个EBR（例如，“V”）通过向企业内的EBG发送路由器广告（RA）消息以声明前缀所有权来注册其PI前缀（例如，“2001:DB1:10:：/56”）。当需要更强的身份验证时，EBR可以使用为安全邻居发现（SEND）指定的机制对消息进行数字签名[RFC3971]。接收RAs（例如，“Y1”）的EBG首先验证发送方的凭据，然后在企业映射系统中注册前缀。接下来，他们将RA的代理版本转发给其母企业内的EBG（例如，“X2”）。这个代理过程继续向上递归层次结构，直到达到默认的空闲公共空间。（在本例中，代理过程在“R2”处结束）。初始注册后，拥有PI前缀的EBR必须定期发送额外的RAs以更新前缀过期计时器。
In Figure 2, an IPv6 host 'H' that is deeply nested within Enterprise 'E1' connects to IPv6 server 'S1', located somewhere on the IPv6 Internet. 'H' is attached to a shared link with IPv6/IPv4 dual-stack router 'V', which advertises the IPv6 prefixes '2001:DB8:0:0::/64' and '2001:DB8:10:0::/64'. 'H' uses standard IPv6 neighbor discovery mechanisms to discover 'V' as a default IPv6 router that can forward its packets off the local link, and configures addresses from both of the advertised prefixes. 'V' in turn sees node 'Y1' as an EBG that is reachable via VET interface 'vet1' and that can forward packets toward IPv6 server 'S1'. Similarly, node 'Y1' is an EBR on the enterprise spanned by 'vet2' that sees 'X2' as an EBG, and node 'X2' is an EBR on 'vet3' that sees 'R2' as an EBG. Ultimately, 'R2' is an EBR that connects 'E1' to the global Internet.
在图2中，深入嵌套在企业“E1”中的IPv6主机“H”连接到位于IPv6 Internet上某处的IPv6服务器“S1”“H”与IPv6/IPv4双栈路由器“V”连接到共享链路，该路由器播发IPv6前缀“2001:DB8:0:0:：/64”和“2001:DB8:10:0:：/64”“H”使用标准IPv6邻居发现机制发现“V”作为默认IPv6路由器，该路由器可以从本地链路转发其数据包，并配置来自两个播发前缀的地址。”V'反过来将节点“Y1”视为可通过VET接口“vet1”访问的EBG，并可将数据包转发到IPv6服务器“S1”。类似地，节点“Y1”是由“vet2”跨越的企业上的EBR，它将“X2”视为EBG，节点“X2”是“vet3”上的EBR，它将“R2”视为EBG。最终，“R2”是将“E1”连接到全球互联网的EBR。
In the example shown in Figure 2, 'V', 'Y1', 'X2', and 'R2' configure separate VET interfaces for each enterprise they connect to in order to discover routes through a dynamic routing protocol and/or mapping database lookups. After tunnels 'vet1' through 'vet3' are established, the EBRs connected to a VET interface can run a dynamic routing protocol such as OSPVFv3 [RFC5340] and exchange topology information over the VET interface using the NBMA interface model. In this way, each EBR can discover other EBRs on the link via routing protocol control message exchanges.
在图2所示的示例中，“V”、“Y1”、“X2”和“R2”为它们连接到的每个企业配置单独的VET接口，以便通过动态路由协议和/或映射数据库查找发现路由。建立隧道“vet1”到“vet3”后，连接到VET接口的EBR可以运行动态路由协议，如OSPVV3[RFC5340]，并使用NBMA接口模型在VET接口上交换拓扑信息。这样，每个EBR可以通过路由协议控制消息交换发现链路上的其他EBR。
In a second example, Figure 3 depicts an instance of on-demand discovery of more specific routes in which an IPv6 end system 'H' connects to a peer end system 'J', located in a different organizational entity within 'E1':
在第二个示例中，图3描述了一个按需发现更多特定路由的实例，其中IPv6终端系统“H”连接到位于“E1”内不同组织实体中的对等终端系统“J”：
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) ----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +----+ v +----+ +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ +----+ +-----+-------+
" . | 1 . . 2 . . . " |
" . H . . . . v . " |
" . . . . . . . . . . . e . " +--+---+
" . t . " | IPv4 |
" . . . . . . , . 3 . " |Server|
" . +----+ v +----+ . " | S2 |
" . | Z += e =+ X7 += . " +------+
" . +-+--+ t +----+ . "
" . | 4 . . . "
" . J . . . . . "
" . . . . . . . "
" 2001:DB8:20::/56 (PI) --------> "
" " " " " " " " " " " " " " "" " " " " " " "
<-- Enterprise E1 -->
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) ----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +----+ v +----+ +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ +----+ +-----+-------+
" . | 1 . . 2 . . . " |
" . H . . . . v . " |
" . . . . . . . . . . . e . " +--+---+
" . t . " | IPv4 |
" . . . . . . , . 3 . " |Server|
" . +----+ v +----+ . " | S2 |
" . | Z += e =+ X7 += . " +------+
" . +-+--+ t +----+ . "
" . | 4 . . . "
" . J . . . . . "
" . . . . . . . "
" 2001:DB8:20::/56 (PI) --------> "
" " " " " " " " " " " " " " "" " " " " " " "
<-- Enterprise E1 -->
Figure 3: On-Demand Discovery
图3：按需发现
In this example, tunnel interfaces 'vet1' through 'vet4' as well as IPv6 PI prefix registrations have been established through VET enterprise autoconfiguration procedures. When IPv6 end system 'H' with IPv6 address '2001:DB8:10::1' sends packets to a peer end system 'J' with IPv6 address '2001:DB8:20::1', the packets will be conveyed through 'V', 'Y1', and finally to 'X2' via default routes. Then, unless 'X2' has an IPv6 FIB entry matching 'J', it must discover that 'J' can be reached using a more direct route via 'X7' as the next-hop across the 'E1' commons.
在本例中，通过VET企业自动配置程序建立了隧道接口“vet1”到“vet4”以及IPv6 PI前缀注册。当IPv6地址为“2001:DB8:10:：1”的IPv6端系统“H”向IPv6地址为“2001:DB8:20:：1”的对等端系统“J”发送数据包时，数据包将通过“V”、“Y1”传输，最后通过默认路由传输到“X2”。然后，除非“X2”有一个与“J”匹配的IPv6 FIB条目，否则它必须发现可以使用更直接的路由通过“X7”到达“J”，作为“E1”共用空间的下一个跃点。
In particular, when 'X2' receives a packet on the 'vet2' interface with inner destination address 'J', it can perform an on-demand mapping lookup by consulting the enterprise mapping service, e.g., by consulting the DNS reverse zone. Alternatively, 'X2' can send the packet to a default router (e.g., 'R2'), which in turn can forward the packet to 'X7' and return an ICMPv6 redirect message. When 'X2' receives the redirect, it can send an RA message to 'X7' to prove that it is authorized to produce packets with a prefix that matches source address 'J'. 'X2' can then forward subsequent packets directly to 'X7' without involving 'R2'.
特别是，当“X2”在“vet2”接口上接收到具有内部目标地址“J”的数据包时，它可以通过咨询企业映射服务（例如，通过咨询DNS反向区域）来执行按需映射查找。或者，“X2”可以将数据包发送到默认路由器（例如，“R2”），而默认路由器又可以将数据包转发到“X7”并返回ICMPv6重定向消息。当“X2”接收到重定向时，它可以向“X7”发送RA消息，以证明它有权生成前缀与源地址“J”匹配的数据包X2'然后可以将后续数据包直接转发到'X7'，而不涉及'R2'。
In some enterprise scenarios, dynamic routing and on-demand mapping can be combined as complementary functions. In other scenarios, it may be preferable to use either dynamic routing only or on-demand mapping only.
在某些企业场景中，动态路由和按需映射可以组合为补充功能。在其他场景中，最好只使用动态路由或只使用按需映射。
Legacy hosts, routers, and networks that were already present in pre-RANGER deployments and have already numbered their interfaces with RLOC addresses must see continued support for RLOC-based services for the long term, even as EID-based services are rolled out in new deployments. For example, a legacy IPv4-only node behind an IPv4 Network Address Translator (NAT) must still be able to reach legacy IPv4-only Internet services (e.g., "http://example.com") long after the RANGER architecture and EID-based services are widely deployed.
即使在新部署中推出了基于EID的服务，但在RANGER部署前已经存在并已使用RLOC地址对其接口进行编号的旧式主机、路由器和网络仍必须长期支持基于RLOC的服务。例如，IPv4网络地址转换器（NAT）后面的传统仅IPv4节点必须仍然能够访问传统仅IPv4的Internet服务（例如“http://example.com）很久以前，RANGER体系结构和基于EID的服务被广泛部署。
Returning to the example diagrams, while virtual enterprise traversal across 'E1' provides a fully connected routing and addressing capability for EID-based services, legacy nodes will still require access to RLOC-based services within connected or disjoint RLOC spaces for an extended (and possibly indefinite) period. For example, Figure 4 below depicts the applicable RLOC-based IPv4 service-access scenarios for the RANGER architecture when VET interfaces are used to link recursively nested enterprises together:
返回到示例图，虽然跨“E1”的虚拟企业遍历为基于EID的服务提供了完全连接的路由和寻址功能，但传统节点仍将需要在连接或不连接的RLOC空间内访问基于RLOC的服务，时间延长（可能不确定）。例如，下面的图4描述了RANGER体系结构中使用VET接口将递归嵌套的企业链接在一起时适用的基于RLOC的IPv4服务访问场景：
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) -----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +--- + v +----+ v +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ t +----+ +-----+-------+
" . | 1 . . 2 . . 3 . " |
" . K L . . . . M . " |
" . . . . . . . . . . . . . . " +--+---+
" <E1.1.1> <E1.1> <E1> " | IPv4 |
" " |Server|
" " " " " " " " " " " " " " "" " " " " " " " | S2 |
<-- Enterprise E1 --> +------+
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) -----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +--- + v +----+ v +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ t +----+ +-----+-------+
" . | 1 . . 2 . . 3 . " |
" . K L . . . . M . " |
" . . . . . . . . . . . . . . " +--+---+
" <E1.1.1> <E1.1> <E1> " | IPv4 |
" " |Server|
" " " " " " " " " " " " " " "" " " " " " " " | S2 |
<-- Enterprise E1 --> +------+
Figure 4: Support for Legacy RLOC-Based Services
图4：对传统的基于RLOC的服务的支持
In a first instance, a legacy RLOC-based IPv4 client 'K' within enterprise 'E1.1.1' can access RLOC-based IPv4 service 'L' within the same enterprise as normal and without the need for any encapsulation.
在第一个实例中，企业“E1.1.1”中基于RLOC的旧式IPv4客户端“K”可以像正常情况一样访问同一企业中基于RLOC的IPv4服务“L”，而无需任何封装。
Instead, 'K' discovers a "mapping" for 'L' through a simple lookup within the 'E1.1.1' enterprise-local name service, and conveys packets to 'L' through unencapsulated RLOC-based IPv4 routing and addressing within the 'E1.1.1' commons. In many instances, this may indeed be the preferred service-access model, even when EID-based IPv6 services are widely deployed due to factors such as inability to replace legacy IPv4 applications, IPv6 header overhead avoidance, etc.
相反，“K”通过在“E1.1.1”企业本地名称服务中的简单查找来发现“L”的“映射”，并通过“E1.1.1”公用空间中基于RLOC的未封装IPv4路由和寻址将数据包传送到“L”。在许多情况下，这可能确实是首选的服务访问模型，即使在基于EID的IPv6服务由于无法替换旧式IPv4应用程序、避免IPv6报头开销等因素而广泛部署时也是如此。
In a second instance, RLOC-based IPv4 client 'K' can access RLOC-based IPv4 server 'S2' on the legacy global IPv4 Internet in a number of ways, based on the way the recursively nested 'E1.*' enterprises are provisioned:
在第二个实例中，基于RLOC的IPv4客户端“K”可以通过多种方式访问旧式全局IPv4 Internet上基于RLOC的IPv4服务器“S2”，具体方式取决于递归嵌套的“E1.*”企业的配置方式：
o if all of the recursively nested 'E1.*' enterprises are configured within the same IPv4 RLOC space, normal IPv4 forwarding will convey unencapsulated IPv4 packets from 'K' toward 'R2', which then acts as an IPv4 Network Address Translator (NAT) and/or an ordinary IPv4 Enterprise Border Router.
o 如果在相同的IPv4 RLOC空间中配置了所有递归嵌套的“E1.*”企业，则正常的IPv4转发将把未封装的IPv4数据包从“K”传送到“R2”，然后“R2”充当IPv4网络地址转换器（NAT）和/或普通IPv4企业边界路由器。
o if the recursively nested 'E1.*' enterprises are configured within disjoint RLOC spaces, all EBGs 'Y1', 'X2', and 'R2' can be configured to provide an IPv4 NAT capability (i.e., a recursive nesting of NATs within NATs). However, this approach places multiple instances of stateful NAT devices on the path, which can lead to an overall degree of brittleness and intolerance to routing changes. Instead, 'R2' can act as a "Carrier-Grade NAT (CGN)", and 'V' can convey packets from 'K' to the CGN using IPv4-in-IPv6-in-IPv4 tunneling. The CGN can then decapsulate the inner, RLOC-based IPv4 packets and translate the IPv4 source addresses into global IPv4 source addresses before sending the packets on to 'S2'.
o 如果在不相交的RLOC空间中配置递归嵌套的“E1.*”企业，则可以将所有EBG“Y1”、“X2”和“R2”配置为提供IPv4 NAT功能（即NAT中NAT的递归嵌套）。但是，这种方法会在路径上放置多个有状态NAT设备实例，这会导致路由更改的整体脆弱性和不容忍性。相反，“R2”可以充当“载波级NAT（CGN）”，而“V”可以使用IPv4-in-IPv6-in-IPv4隧道将数据包从“K”传送到CGN。然后，CGN可以解除内部基于RLOC的IPv4数据包的封装，并在将数据包发送到“S2”之前将IPv4源地址转换为全局IPv4源地址。
o 'K' could be configured as an EID-based, IPv6-capable node and use standard IPv6 routing to reach an IPv6/IPv4 translator located at an EBR for the enterprise in which 'S2' resides. The translator would then use IPv6-to-IPv4 translation before sending packets onwards toward 'S2'. These and other alternatives are discussed in [WING].
o “K”可以配置为基于EID、支持IPv6的节点，并使用标准IPv6路由到达位于“S2”所在企业的EBR处的IPv6/IPv4转换器。然后，转换器将使用IPv6到IPv4的转换，然后再向“S2”发送数据包。这些和其他备选方案在[WING]中讨论。
In a final instance, RLOC-based IPv4 client 'K' can access an RLOC-based IPv4 server 'M' in a different enterprise within E1 as long as both enterprises are configured over the same IPv4 RLOC space. If the enterprises are configured over disjoint IPv4 RLOC spaces, however, 'K' would still be able to access 'M' by using EID-based IPv6 services, by using EID-based IPv4 services if an EID-based IPv4 overlay were deployed, or by using some form of RLOC-based IPv4 NAT traversal. 'K' could also access server 'M' if both 'V' and 'X2'
在最后一个实例中，基于RLOC的IPv4客户端“K”可以访问E1中不同企业中基于RLOC的IPv4服务器“M”，只要这两个企业在相同的IPv4 RLOC空间上进行配置。但是，如果企业是在不相交的IPv4 RLOC空间上配置的，则“K”仍然能够通过使用基于EID的IPv6服务、如果部署了基于EID的IPv4覆盖，则使用基于EID的IPv4服务或通过使用某种形式的基于RLOC的IPv4 NAT遍历来访问“M”如果'V'和'X2'同时存在，K'也可以访问服务器'M'
implemented an IPv6/IPv4 protocol translation capability. Finally, 'K' and/or 'M' could implement a bump-in-the-wire or bump-in-the-api IPv6/IPv4 protocol translation capability.
实现了IPv6/IPv4协议转换功能。最后，“K”和/或“M”可以在线路中实现通气，或者在api IPv6/IPv4协议转换功能中实现通气。
Tunnel endpoints that depend on ICMP feedback from routers within the enterprise commons may be susceptible to undetected black holes due to ICMP filtering gateways and/or off-path ICMP spoofing attacks from a node pretending to be a router. Furthermore, rogue nodes within enterprises that do not correctly implement ingress filtering can send spoofed packets of any kind, e.g., for the purpose of mounting denial-of-service and/or traffic amplification attacks targeting underprivileged links.
由于ICMP过滤网关和/或来自假装为路由器的节点的非路径ICMP欺骗攻击，依赖于企业公用区内路由器的ICMP反馈的隧道端点可能容易受到未检测到的黑洞的影响。此外，企业内未正确实施入口过滤的流氓节点可发送任何类型的伪造数据包，例如，用于针对弱势链路发起拒绝服务和/或流量放大攻击。
The Subnetwork Encapsulation and Adaptation Layer (SEAL) provisions each encapsulated packet with a monotonically incrementing, extended Identification field (i.e., the 32-bit SEAL_ID) that tunnel endpoints can use as a nonce to detect off-path spoofing. Moreover, tunnel endpoints that use SEAL can continue to operate correctly even if some/many ICMPs are lost. Finally, tunnel endpoints that use SEAL can adapt to subnetworks containing links with diverse MTUs properties.
子网络封装和适配层（SEAL）为每个封装的分组提供单调递增的扩展标识字段（即32位SEAL_ID），隧道端点可以将其用作检测路径外欺骗的nonce。此外，即使某些/多个ICMP丢失，使用SEAL的隧道端点也可以继续正常运行。最后，使用SEAL的隧道端点可以适应包含具有不同MTU属性的链路的子网络。
Enterprise mobility use cases must be considered along several different vectors:
企业移动性用例必须考虑几个不同的向量：
o nomadic enterprises and end systems may be satisfied to incur address renumbering events as they move between new enterprise network attachment points.
o 游牧企业和终端系统在新的企业网络连接点之间移动时，可能会产生地址重新编号事件。
o mobile enterprises with PI prefixes may be satisfied by dynamic updates to the mapping system as long as they do not impart unacceptable churn.
o 具有PI前缀的移动企业可以通过映射系统的动态更新来满足需求，只要它们不会带来不可接受的搅动。
o mobile enterprises and end systems with PA addresses/prefixes may require additional supporting mechanisms that can accommodate address/prefix renumbering.
o 具有PA地址/前缀的移动企业和终端系统可能需要额外的支持机制，以适应地址/前缀重新编号。
Nomadic enterprise mobility is already satisfied by currently deployed technologies. For example, transporting a laptop computer from a wireless-access hot spot to a home network LAN would allow the nomadic device to re-establish connectivity at the expense of address renumbering. Such renumbering may be acceptable, especially for
目前部署的技术已经满足了游牧式企业移动性的要求。例如，将笔记本电脑从无线接入热点传输到家庭网络LAN将允许游牧设备重新建立连接，而代价是地址重新编号。这种重新编号可能是可以接受的，特别是对于
devices that do not require session persistence across mobility events and do not configure servers with addresses published in the global DNS.
不需要跨移动事件进行会话持久性且不使用全局DNS中发布的地址配置服务器的设备。
Mobile enterprises with PI prefixes that use VET and SEAL can move between parent enterprise attachment points as long as they withdraw the prefixes from the mapping systems of departed enterprises and inject them into the mapping systems of new enterprises. When moving between the lower recursive tiers of a common parent enterprise, such a localized event mobility may result in no changes to the parent enterprise's mapping system. Hence, the organizational structure of a carefully arranged enterprise-within-enterprise framework may be able to dampen mobility-related churn. For enterprises that require in-the-network confidentiality, IKEv2 Mobility and Multihoming (MOBIKE) [RFC4555] may also be useful within this context.
使用VET和SEAL的PI前缀的移动企业可以在母企业连接点之间移动，只要它们从已离职企业的映射系统中提取前缀并将其注入新企业的映射系统中。在公共父企业的较低递归层之间移动时，这种本地化的事件移动可能不会对父企业的映射系统造成任何更改。因此，在企业框架内精心安排的企业的组织结构可能能够抑制与移动性相关的流失。对于需要网络机密性的企业，IKEv2移动和多址（MOBIKE）[RFC4555]在这种情况下也可能有用。
Mobile enterprises and end systems that move quickly between disparate parent enterprise attachment points should not use PI prefixes if withdrawing and announcing the prefixes would impart unacceptable mapping/routing churn and packet loss. They should instead use PA addresses/prefixes that can be coordinated via a rendezvous service. Mobility management mechanisms such as Mobile IPv6 [RFC3775] and the Host Identity Protocol (HIP) [RFC4423] can be used to maintain a stable identifier for fast moving devices even as they move quickly between visited enterprise attachment points.
移动企业和终端系统在不同的父企业连接点之间快速移动时，如果撤回和宣布前缀将导致不可接受的映射/路由混乱和数据包丢失，则不应使用PI前缀。他们应该使用PA地址/前缀，这些地址/前缀可以通过集合服务进行协调。移动管理机制，如移动IPv6[RFC3775]和主机标识协议（HIP）[RFC4423]可用于维护快速移动设备的稳定标识符，即使它们在访问的企业连接点之间快速移动。
As a use case in point, consider an aircraft with a mobile router moving between ground station points of attachment. If the ground stations are located within the same enterprise, or within lower-tier sites of the same parent enterprise, it should suffice for the aircraft to announce its PI prefixes at its new point of attachment and withdraw them from the old. This would avoid excessive mapping system churn, since the prefixes need not be announced/withdrawn within the parent enterprise, i.e., the churn is isolated to lower layers of the recursive hierarchy. Note also that such movement would not entail an aircraft-wide readdressing event.
作为一个用例，考虑一个带有移动路由器的飞行器在地面站连接点之间移动。如果地面站位于同一企业内，或位于同一母企业的较低层站点内，则飞机应足以在其新连接点宣布其PI前缀，并将其从旧连接点撤回。这将避免过度的映射系统搅动，因为前缀不需要在母企业内宣布/撤销，即搅动被隔离到递归层次结构的较低层。还应注意，此类移动不会导致全飞机重新换装事件。
As a second example, consider a wireless handset moving between service coverage areas maintained by independent providers with peering arrangements. Since the coverage range of terrestrial cellular wireless technologies is limited, mobility events may occur on a much more aggressive timescale than some other examples. In this case, the handset may expect to incur a readdressing event for its access interface at least, and may be obliged to arrange for a rendezvous service linkage.
作为第二个例子，考虑在独立的提供商通过对等安排维护的服务覆盖区域之间移动的无线手持机。由于地面蜂窝无线技术的覆盖范围是有限的，因此移动事件可能发生在比其他一些示例更具攻击性的时间尺度上。在这种情况下，手持机可能期望至少为其接入接口引起重新穿戴事件，并且可能被迫安排集合服务链接。
It should specifically be noted that the contingency of mobility management solutions is not necessarily mutually exclusive and must be considered in relation to specific use cases. The RANGER architecture is therefore naturally inclusive in this regard. In particular, RANGER could benefit from mechanisms that could support rapid dynamic updates of PI prefix mappings without causing excessive churn.
应该特别注意的是，机动性管理解决方案的偶然性不一定是相互排斥的，必须结合具体的用例来考虑。因此，RANGER架构在这方面自然具有包容性。特别是，RANGER可以从支持PI前缀映射的快速动态更新的机制中获益，而不会造成过度搅动。
As with mobility management, multihoming use cases must be considered along multiple vectors. Within an enterprise, EBRs can discover multiple EBGs and use them in a fault-tolerant and load-balancing fashion as long as they register their PI prefixes with each such EBG, as described in Section 3.3.1. These registrations are created through the transmission of Router Advertisement messages that percolate up through the recursive enterprise-within-enterprise hierarchy.
与移动性管理一样，必须沿多个向量考虑多归属用例。在企业内，EBR可以发现多个EBG，并以容错和负载平衡的方式使用它们，只要它们向每个EBG注册PI前缀，如第3.3.1节所述。这些注册是通过路由器广告消息的传输创建的，这些消息通过企业层次结构中的递归企业进行渗透。
As a first case in point, consider the enterprise network of a major corporation that obtains services from a number of ISPs. The corporation should be able to register its PI prefixes with all of its ISPs, and use any of the ISPs for its Internet access services.
作为第一个例子，考虑一个从多个ISP获得服务的大公司的企业网络。该公司应能够在其所有ISP上注册其PI前缀，并将任何ISP用于其互联网接入服务。
As a second use case, consider an aircraft with a diverse set of wireless links (e.g., VHF, 802.16, directional, SATCOM, etc.). The aircraft should be able to select and utilize the most appropriate link(s) based on the phase of flight and to change seamlessly between links as necessary. Other examples include a nomadic laptop with both 802.11 and Ethernet links, a wireless handset with both CDMA wireless and 802.11, etc.
作为第二种使用情况，考虑具有不同的无线链路集的飞行器（例如，VHF、802.16、定向、SATCOM等）。飞机应能够根据飞行阶段选择和利用最合适的链路，并根据需要在链路之间无缝切换。其他示例包括同时具有802.11和以太网链路的游牧笔记本电脑、同时具有CDMA无线和802.11的无线手持设备等。
As with mobility management, the contingency of solutions is not necessarily mutually exclusive and can combine to suit use cases within the scope of the RANGER architecture.
与移动性管理一样，解决方案的偶然性不一定是相互排斥的，可以结合起来以适应RANGER架构范围内的用例。
Selection of mapping alternatives may have significant implications for applications, server selection, route determination, security, etc. In particular, applications that expect all packets (including initial ones) to experience similar delays may be adversely affected by a scheme that imposes non-negligible delays when initial packets are queued while a look-aside mapping table is consulted. Still other applications may experience significant startup delays when its initial packets are dropped during a mapping lookup event. These
映射备选方案的选择可能会对应用程序、服务器选择、路由确定、安全性等产生重大影响。特别是，需要所有数据包（包括初始数据包）的应用程序若要经历类似的延迟，则可能会受到一种方案的不利影响，该方案在查询旁侧映射表时，在初始数据包排队时施加不可忽略的延迟。还有一些应用程序在映射查找事件期间丢弃其初始数据包时可能会经历严重的启动延迟。这些
factors would seem to favor a scheme that is able to forward initial packets along a path with sub-optimal delay while a mapping lookup is performed in parallel, e.g., such as when a "default mapper" is used.
在并行执行映射查找时，例如当使用“默认映射器”时，这些因素似乎有利于能够沿具有次优延迟的路径转发初始分组的方案。
Generally speaking, proactive mapping-maintenance mechanisms may have scaling issues with the amount of updates they generate, while reactive mechanisms may involve effects to the delay of initial packets before the cached state is updated. Also to be considered are attacks against the mapping mechanism, which may result in denial of service of the mapping cache.
一般来说，主动映射维护机制可能会因其生成的更新量而存在缩放问题，而被动机制可能会影响缓存状态更新之前初始数据包的延迟。还应考虑针对映射机制的攻击，这可能导致映射缓存的拒绝服务。
Encapsulation of packets in automatically created tunnels involves a number of issues as well. There are obvious interactions between encapsulation overhead and the effective tunnel MTU, which can be addressed by SEAL and (when necessary) careful operational link arrangements. Moreover, it is important to minimize the impact to the global routing table without at the same time impacting the ability of legacy Internet networks to connect to those employing RANGER. As long as other nodes in the Internet need to connect to networks implementing RANGER, EID routes need to appear both in the mapping system and the global BGP routing tables. This can be accommodated by keeping the number of prefixes aggregated by RANGER to the bare minimum through efficient aggregation (e.g., one or a few [PREF]::/4 IPv6 prefixes instead of millions of [PREF]::/32 prefixes).
在自动创建的隧道中封装数据包也涉及许多问题。封装开销和有效隧道MTU之间存在明显的相互作用，这可以通过密封和（必要时）仔细的操作链路安排来解决。此外，重要的是尽量减少对全局路由表的影响，同时不影响传统Internet网络连接到使用RANGER的网络的能力。只要Internet上的其他节点需要连接到实现RANGER的网络，EID路由就需要同时出现在映射系统和全局BGP路由表中。这可以通过有效聚合（例如，一个或几个[PREF]：：/4个IPv6前缀，而不是数百万个[PREF]：：/32前缀）将RANGER聚合的前缀数量保持在最低限度来实现。
The origins of the RANGER architectural principles can be traced to the "Catenet model for internetworking" ([CATENET], [IEN48], [RFC2775]) beginning as early as the mid-1970's. Subsequently, deliberations of the ROAD group [RFC1380] and related efforts such as NIMROD [RFC1753] provided a sustained evolution of the concepts. [RFC1955], "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", captures the high-level architectural aspects of the ROAD group deliberations.
RANGER体系结构原则的起源可以追溯到早在20世纪70年代中期就开始的“互联网的Catenet模型”（[Catenet]、[IEN48]、[RFC2775]）。随后，道路小组[RFC1380]的讨论和NIMROD[RFC1753]等相关工作提供了概念的持续演变。[RFC1955]，“IPNG的互联网路由和寻址（ENCAPS）新方案”，抓住了道路小组讨论的高层架构方面。
These foundational works significantly influenced more recent developments, including the X-Bone initiative [XBONE], which explored virtual topologies manifested through tunneling. Various tunneling approaches including IP-in-IP ([RFC2003], [RFC4213]), 6over4 [RFC2529], and ISATAP [RFC5214] have evolved from the mid-1990's until the present day and are used in common, operational practice. Tunnel-mode IPsec [RFC4301] is also commonly used for separation of security domains within enterprises.
这些基础性工作极大地影响了最近的发展，包括X-Bone倡议[XBONE]，该倡议探索了通过隧道实现的虚拟拓扑。各种隧道方法，包括IP-in-IP（[RFC2003]、[RFC4213]）、6over4[RFC2529]和ISATAP[RFC5214]从20世纪90年代中期一直发展到今天，并在常见的操作实践中使用。隧道模式IPsec[RFC4301]也常用于企业内安全域的分离。
Currently, initiatives with similar properties to RANGER are under development within the IRTF Routing Research Group (RRG) and within IETF working groups such as LISP, SOFTWIRE, V6OPS, and others. Numerous proposals have been offered within the RRG, including the Locator-Identifier Split Protocol (LISP) [LISP], Six-One [VOGT], ILNP [ILNP], Internet vastly improved plumbing (Ivip) [WHITTLE], A Practical Transit-Mapping Service (APT) [JEN], and Virtual Aggregation [VA]. Still other similar initiatives almost certainly exist.
目前，IRTF路由研究组（RRG）和IETF工作组（如LISP、SOFTWIRE、V6OPS等）正在开发与RANGER具有类似特性的计划。RRG内部提出了许多建议，包括定位器标识符拆分协议（LISP）[LISP]、六一[VOGT]、ILNP[ILNP]、互联网极大改进管道（Ivip）[WHITTLE]、实用交通地图服务（APT）[JEN]和虚拟聚合[VA]。还有其他类似的举措几乎肯定存在。
While RANGER shares many properties with these earlier works, it uniquely provides a top-to-bottom articulation of how the various pieces fit together within a recursively nested "enterprise-within-enterprise" (or "network-of-networks") framework. In this way, it bears striking resemblance to the network-of-networks model envisioned by CATENET. RANGER further provides a detailed consideration of challenging issues such as autoconfiguration, provider-independent addressing, border router discovery, tunnel MTU, multihoming, etc. that many other approaches have either overlooked or left for future work. A detailed analysis of RANGER applicability in various use case scenarios is provided in "RANGER Scenarios (RANGERS)" [RUSSERT].
虽然RANGER与这些早期作品共享许多属性，但它独特地提供了一种自上而下的表达方式，说明了在递归嵌套的“企业内部企业”（或“网络网络”）框架中，各个部分是如何组合在一起的。通过这种方式，它与CATENET设想的网络中的网络模型有着惊人的相似性。RANGER进一步详细考虑了一些具有挑战性的问题，如自动配置、独立于提供商的寻址、边界路由器发现、隧道MTU、多主定位等，而许多其他方法要么忽略了这些问题，要么留给了未来的工作。“RANGER scenarios（RANGERS）”[RUSSERT]中详细分析了RANGER在各种用例场景中的适用性。
Communications between endpoints within different sites inside an enterprise are carried across a commons that joins organizational entities with a mutual spirit of cooperation, but between which there may be competing business/sociological/political interests. As a result, mechanisms that rely on feedback from routers on the path may become brittle or susceptible to spoofing attacks. This is due to the fact that IP packets can be lost due to congestion or packet-filtering gateways and that the source addresses of IP packets can be forged. Moreover, IP packets in general can be generated by anonymous attackers, e.g., from a rogue node within a third-party enterprise that has malicious intent toward a victim.
企业内不同站点内的端点之间的通信通过公共空间进行，该公共空间以相互合作的精神连接组织实体，但在这些公共空间之间可能存在相互竞争的商业/社会/政治利益。因此，依赖路径上路由器反馈的机制可能变得脆弱或容易受到欺骗攻击。这是因为IP数据包可能由于拥塞或数据包过滤网关而丢失，并且IP数据包的源地址可能被伪造。此外，匿名攻击者通常可以生成IP数据包，例如，来自第三方企业内恶意攻击受害者的恶意节点。
Path MTU Discovery is an example of a mechanism that relies on ICMP feedback from routers on the path and, as such, is susceptible to these issues. For IPv4, a common workaround is to disable Path MTU Discovery and let fragmentation occur in the network if necessary. For IPv6, lack of fragmentation support in the network precludes this option such that the mitigation typically recommended is to discard ICMP messages that contain insufficient information and/or to operate with the minimum IPv6 path MTU. This example extends also to other mechanisms that either rely on or are enhanced by feedback from network devices; however, attack vectors based on non-ICMP messages are also subject for concern.
路径MTU发现是依赖于路径上路由器的ICMP反馈的机制的一个示例，因此容易受到这些问题的影响。对于IPv4，一个常见的解决方法是禁用路径MTU发现，并在必要时在网络中发生碎片。对于IPv6，由于网络中缺少碎片支持，因此无法使用此选项，因此通常建议的缓解措施是丢弃包含不充分信息的ICMP消息和/或使用最小IPv6路径MTU运行。该示例还扩展到依赖于网络设备的反馈或由网络设备的反馈增强的其他机制；然而，基于非ICMP消息的攻击向量也值得关注。
The RANGER architecture supports effective mitigations for attacks such as distributed denial-of-service, traffic amplification, etc. In particular, when VET and SEAL are used, EBGs can use the 32-bit identification encoded in the SEAL header as well as ingress filtering to determine if a message has come from a topologically correct enterprise located across the commons. This allows enterprises to employ effective mitigations at their borders without the requirement for mutual cooperation from other enterprises. When source address spoofing by on-path attackers located within the commons is also subject for concern, additional securing mechanisms such as tunnel-mode IPsec between enterprise EBGs can also be used.
RANGER体系结构支持有效缓解攻击，如分布式拒绝服务、流量放大等。特别是在使用VET和SEAL时，EBGs可以使用SEAL报头中编码的32位标识以及入口过滤来确定消息是否来自位于公用区的拓扑正确的企业。这使得企业能够在其边界采取有效的缓解措施，而无需其他企业的相互合作。当位于公用区内的路径上攻击者的源地址欺骗也受到关注时，还可以使用其他安全机制，如企业EBG之间的隧道模式IPsec。
EBRs can obtain PI prefixes through arrangements with a prefix delegation authority. Thereafter, the EBR can announce and/or withdraw the prefixes within an enterprise by sending IPv6 Router Advertisements (RAs). In environments where additional authenticating mechanisms are necessary, the EBR can sign its RAs using SEcure Neighbor Discovery (SEND) [RFC3971].
EBR可以通过与前缀授权机构的安排获得PI前缀。此后，EBR可以通过发送IPv6路由器广告（RAs）在企业内宣布和/或收回前缀。在需要额外身份验证机制的环境中，EBR可以使用安全邻居发现（SEND）[RFC3971]对其RAs进行签名。
While the RANGER architecture does not in itself address security considerations, it proposes an architectural framework for functional specifications that do. Security concerns with tunneling, along with recommendations that are compatible with the RANGER architecture, are found in [HOAGLAND].
虽然RANGER体系结构本身并没有解决安全问题，但它为功能规范提出了一个体系结构框架。关于隧道的安全问题，以及与RANGER架构兼容的建议，请参见[HOAGLAND]。
This work was inspired through the encouragement of the Boeing DC&NT network technology team and through the communications of the IESG.
这项工作的灵感来自波音DC&NT网络技术团队的鼓励和IESG的沟通。
Many individuals have contributed to the architectural principles that form the basis for RANGER over the course of many years. The following individuals have given specific feedback on the RANGER document itself: Jari Arkko, Brian Carpenter, Eric Fleischman, Joel Halpern, Thomas Henderson, Steven Russert, Dallas Thomas, Robin Whittle.
多年来，许多人对构成RANGER基础的建筑原则做出了贡献。以下个人对游骑兵文件本身给出了具体反馈：贾里·阿尔科、布赖恩·卡彭特、埃里克·弗莱斯曼、乔尔·哈尔伯恩、托马斯·亨德森、史蒂文·拉塞特、达拉斯·托马斯、罗宾·惠特尔。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[CATENET] Pouzin, L., "A Proposal for Interconnecting Packet Switching Networks", Proceedings of EUROCOMP, Bronel University, p. 1023-1036, May 1974.
[CATENET]Pouzin，L.，“互连分组交换网络的提案”，欧洲公司学报，布朗尔大学，第页。1974年5月1023-1036日。
[COEXIST] Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios", Work in Progress, July 2009.
[共存]Arkko，J.和M.Townsley，“IPv4耗尽和IPv4-IPv6共存场景”，正在进行的工作，2009年7月。
[BAUER] Bauer, C. and S. Ayaz, "ATN Topology Considerations for Aeronautical NEMO RO", Work in Progress, September 2009.
[BAUER]BAUER，C.和S.Ayaz，“航空NEMO RO的ATN拓扑考虑”，正在进行的工作，2009年9月。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, September 2009.
[LISP]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，正在进行的工作，2009年9月。
[HOAGLAND] Hoagland, J., Krishnan, S., and D. Thaler, "Security Concerns With IP Tunneling", Work in Progress, October 2008.
[HOAGLAND]HOAGLAND，J.，Krishnan，S.，和D.Thaler，“IP隧道的安全问题”，正在进行的工作，2008年10月。
[JEN] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and L. Zhang, "APT: A Practical Transit Mapping Service", Work in Progress, November 2007.
[JEN]JEN，D.，Meisel，M.，Massey，D.，Wang，L.，Zhang，B.，和L.Zhang，“APT：一种实用的交通测绘服务”，正在进行的工作，2007年11月。
[RUSSERT] Russert, S., Fleischman, E., and F. Templin, "RANGER Scenarios", Work in Progress, September 2009.
[RUSSERT]RUSSERT，S.，Fleischman，E.，和F.Templin，“游骑兵场景”，正在进行的工作，2009年9月。
[SEAL] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010.
[SEAL]Templin，F.，Ed.“子网络封装和适配层（SEAL）”，RFC 5320，2010年2月。
[VET] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[VET]Templin，F.，Ed.，“虚拟企业遍历（VET）”，RFC 5558，2010年2月。
[WING] Wing, D., Ward, D., and A. Durand, "A Comparison of Proposals to Replace NAT-PT", Work in Progress, September 2008.
[WING]WING，D.，Ward，D.，和A.Durand，“替代NAT-PT方案的比较”，正在进行的工作，2008年9月。
[IEN48] Cerf, V., "The Catenet Model for Internetworking", July 1978.
[IEN48]Cerf，V.，“互联网的Catenet模型”，1978年7月。
[ILNP] Atkinson, R., "ILNP Concept of Operations", Work in Progress, December 2008.
[ILNP]阿特金森，R.，“ILNP作战概念”，在建工程，2008年12月。
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992.
[RFC1380]Gross，P.和P.Almquist，“IESG关于路由和寻址的讨论”，RFC1380，1992年11月。
[RFC1753] Chiappa, N., "IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture", RFC 1753, December 1994.
[RFC1753]Chiapa，N.，“Nimrod路由和寻址体系结构的IPng技术要求”，RFC 1753，1994年12月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC1955]Hinden，R.，“IPNG的互联网路由和寻址新方案（ENCAPS）”，RFC 19551996年6月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529]Carpenter，B.和C.Jung，“在没有明确隧道的IPv4域上传输IPv6”，RFC 2529，1999年3月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]Carpenter，B.，“互联网透明度”，RFC 27752000年2月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC 4423，2006年5月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC4555，2006年6月。
[RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. Green, "IPv6 Enterprise Network Analysis - IP Layer 3 Focus", RFC 4852, April 2007.
[RFC4852]Bound，J.，Pouffary，Y.，Klynsma，S.，Chown，T.，和D.Green，“IPv6企业网络分析-IP层3焦点”，RFC 48522007年4月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[VA] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "FIB Suppression with Virtual Aggregation", Work in Progress, October 2009.
[VA]Francis，P.，Xu，X.，Ballani，H.，Jen，D.，Raszuk，R.，和L.Zhang，“FIB抑制与虚拟聚集”，正在进行的工作，2009年10月。
[VOGT] Vogt, C., "Six/One: A Solution for Routing and Addressing in IPv6", Work in Progress, October 2009.
[VOGT]VOGT，C.，“六/一：IPv6路由和寻址解决方案”，进展中的工作，2009年10月。
[WHITTLE] Whittle, R., "Ivip (Internet Vastly Improved Plumbing) Architecture", Work in Progress, August 2008.
[WHITTLE]WHITTLE，R.，“Ivip（互联网极大改进的管道）架构”，正在进行的工作，2008年8月。
[XBONE] Touch, J., "The X-Bone", March 1997,
http://www.isi.edu/touch/pubs/ngi97/x-bone-ngi97.pdf
[XBONE] Touch, J., "The X-Bone", March 1997,
http://www.isi.edu/touch/pubs/ngi97/x-bone-ngi97.pdf
Author's Address
作者地址
Fred L. Templin Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
Fred L.Templin波音幻影工厂美国华盛顿州西雅图3707 MC 7L-49邮政信箱98124
EMail: fltemplin@acm.org
EMail: fltemplin@acm.org