Independent Submission                                   S. Russert, Ed.
Request for Comments: 6139                                  Unaffiliated
Category: Informational                               E. Fleischman, Ed.
ISSN: 2070-1721                                          F. Templin, Ed.
                                            Boeing Research & Technology
                                                           February 2011
        
Independent Submission                                   S. Russert, Ed.
Request for Comments: 6139                                  Unaffiliated
Category: Informational                               E. Fleischman, Ed.
ISSN: 2070-1721                                          F. Templin, Ed.
                                            Boeing Research & Technology
                                                           February 2011
        

Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios

具有全局企业递归(RANGER)方案的网络中的路由和寻址

Abstract

摘要

"Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)" (RFC 5720) provides an architectural framework for scalable routing and addressing. It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering, and security. This document describes a series of use cases in order to showcase the architectural capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet.

“具有全局企业递归(RANGER)的网络中的路由和寻址”(RFC 5720)为可扩展的路由和寻址提供了体系结构框架。它为可伸缩性、提供商独立性、移动性、多主、流量工程和安全性提供了一种可增量部署的方法。本文档描述了一系列用例,以展示体系结构功能。它进一步展示了RANGER体系结构如何按照最初用于互联网持续增长的网络原则恢复网络。

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/rfc6139.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc6139.

Copyright Notice

版权公告

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2011 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. Approach ........................................................7
   4. Scenarios ......................................................11
      4.1. Global Concerns ...........................................11
           4.1.1. Scaling the Global Inter-Domain Routing Core .......11
           4.1.2. Supporting Large Corporate Enterprise Networks .....13
      4.2. Autonomous System Concerns ................................16
      4.3. Small Enterprise Concerns .................................16
      4.4. IPv4/IPv6 Transition and Coexistence ......................18
      4.5. Mobility and MANET ........................................21
           4.5.1. Global Mobility Management .........................21
           4.5.2. First-Responder Mobile Ad Hoc Networks (MANETs) ....23
           4.5.3. Tactical Military MANETs ...........................24
      4.6. Provider Concerns .........................................27
           4.6.1. ISP Networks .......................................27
           4.6.2. Cellular Operator Networks .........................28
           4.6.3. Aeronautical Telecommunications Network (ATN) ......28
           4.6.4. Unmanaged Networks .................................31
   5. Mapping and Encapsulation Concerns .............................32
   6. Problem Statement and Call for Solutions .......................32
   7. Summary ........................................................33
   8. Security Considerations ........................................33
   9. Acknowledgements ...............................................34
   10. References ....................................................34
      10.1. Normative References .....................................34
      10.2. Informative References ...................................34
        
   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. Approach ........................................................7
   4. Scenarios ......................................................11
      4.1. Global Concerns ...........................................11
           4.1.1. Scaling the Global Inter-Domain Routing Core .......11
           4.1.2. Supporting Large Corporate Enterprise Networks .....13
      4.2. Autonomous System Concerns ................................16
      4.3. Small Enterprise Concerns .................................16
      4.4. IPv4/IPv6 Transition and Coexistence ......................18
      4.5. Mobility and MANET ........................................21
           4.5.1. Global Mobility Management .........................21
           4.5.2. First-Responder Mobile Ad Hoc Networks (MANETs) ....23
           4.5.3. Tactical Military MANETs ...........................24
      4.6. Provider Concerns .........................................27
           4.6.1. ISP Networks .......................................27
           4.6.2. Cellular Operator Networks .........................28
           4.6.3. Aeronautical Telecommunications Network (ATN) ......28
           4.6.4. Unmanaged Networks .................................31
   5. Mapping and Encapsulation Concerns .............................32
   6. Problem Statement and Call for Solutions .......................32
   7. Summary ........................................................33
   8. Security Considerations ........................................33
   9. Acknowledgements ...............................................34
   10. References ....................................................34
      10.1. Normative References .....................................34
      10.2. Informative References ...................................34
        
1. Introduction
1. 介绍

The Internet is continually required to support more users, more internetwork connections, and increasing complexity due to diverse policy requirements. This growth and change strains the infrastructure and demands new solutions. Some of the complementary approaches to transform Internet technology are being pursued concurrently within the IETF: translation (including Network Address Translation (NAT)), tunneling (map and encapsulate), and native IPv6 [RFC2460] deployment. Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) [RFC5720] describes the architectural elements of a "map and encapsulate" approach that also facilitates the other two approaches. This document discusses RANGER operational scenarios.

由于不同的政策要求,互联网不断被要求支持更多的用户、更多的互联网连接以及日益增加的复杂性。这种增长和变化给基础架构带来了压力,需要新的解决方案。IETF中同时采用了一些转换互联网技术的补充方法:转换(包括网络地址转换(NAT))、隧道(映射和封装)和本机IPv6[RFC2460]部署。具有全局企业递归(RANGER)的网络中的路由和寻址[RFC5720]描述了“映射和封装”方法的体系结构元素,该方法也促进了其他两种方法。本文档讨论了RANGER的操作场景。

RANGER provides an architectural framework for scalable routing and addressing. It provides for scalability, provider independence, mobility, multihoming, and security for the next-generation Internet. The RANGER architectural principles are not new. They can be traced to the deliberations of the ROAD group [RFC1380], and also to still earlier works including NIMROD [RFC1753] and the Catenet model for internetworking [CATENET] [IEN48] [RFC2775]. [RFC1955] captures the high-level architectural aspects of the ROAD group deliberations in a "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG".

RANGER为可扩展的路由和寻址提供了体系结构框架。它为下一代互联网提供了可扩展性、提供商独立性、移动性、多主和安全性。RANGER的架构原则并不新鲜。它们可以追溯到道路小组[RFC1380]的讨论,也可以追溯到早期的工作,包括NIMROD[RFC1753]和用于互联的Catenet模型[Catenet][IEN48][RFC2775]。[RFC1955]在“IPNG的互联网路由和寻址(ENCAPS)新方案”中捕捉了道路小组讨论的高层架构方面。

The Internet has grown tremendously since these architectural principles were first developed, and that evolution increases the need for these capabilities. The Internet has become a critical resource for business, for government, and for individual users throughout the developed world. RANGER carries forward these historic architectural principles, creating a ubiquitous enterprise network structure that can represent collections of network elements ranging from the granularity of a singleton router all the way up to an entire Internet. This enterprise network structure uses border routers that configure tunnel endpoints to connect potentially recursively nested networks. Each enterprise network may use completely independent internal Routing Locator (RLOC) address spaces, supporting a virtual overlay network connecting edge networks and devices that are addressed with globally unique Endpoint Interface iDentifiers (EIDs). The RANGER virtual overlay can transcend traditional administrative and organizational boundaries. In its purest form, this overlay network could therefore span the entire Internet and restore the end-to-end transparency envisioned in [RFC2775].

自从这些体系结构原则被首次开发以来,互联网得到了巨大的发展,而这种发展增加了对这些功能的需求。互联网已经成为发达国家商业、政府和个人用户的重要资源。RANGER继承了这些历史性的架构原则,创建了一个无处不在的企业网络结构,它可以代表从单一路由器的粒度到整个互联网的网络元素集合。此企业网络结构使用边界路由器,这些路由器配置隧道端点以连接可能递归嵌套的网络。每个企业网络可以使用完全独立的内部路由定位器(RLOC)地址空间,支持虚拟覆盖网络,连接使用全局唯一端点接口标识符(EID)寻址的边缘网络和设备。RANGER虚拟覆盖可以超越传统的管理和组织边界。因此,以最纯粹的形式,这种覆盖网络可以覆盖整个互联网,并恢复[RFC2775]中设想的端到端透明度。

The RANGER architecture drew early observations from the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] [RFC5579] but now uses Virtual Enterprise Traversal (VET) [RFC5558], the Subnetwork

RANGER体系结构从站点内自动隧道寻址协议(ISATAP)[RFC5214][RFC5579]中获得了早期观察结果,但现在使用虚拟企业遍历(VET)[RFC5558],即子网

Encapsulation and Adaptation Layer (SEAL) [RFC5320], and other mechanisms including IPsec [RFC4301] as its functional building blocks. This document describes use cases and shows how the RANGER mechanisms apply. Complementary mechanisms (e.g., DNS, DHCP, NAT, etc.) are included to show how the various pieces can work together. It expands on the concepts introduced in "IPv6 Enterprise Network Scenarios" [RFC4057] and "IPv6 Enterprise Network Analysis - IP Layer 3 Focus" [RFC4852], and shows how the enterprise network model generalizes to a broad range of scenarios. These use cases are included to provide examples, invite criticism and comment, and explore the potential for creating the next-generation Internet using the RANGER architecture. Familiarity with RANGER, VET, SEAL, and ISATAP are assumed.

封装和适配层(SEAL)[RFC5320]和其他机制,包括IPsec[RFC4301]作为其功能构建块。本文档描述了用例,并展示了RANGER机制是如何应用的。补充机制(如DNS、DHCP、NAT等)包括在内,以显示各个部分如何协同工作。它扩展了“IPv6企业网络场景”[RFC4057]和“IPv6企业网络分析-IP层3焦点”[RFC4852]中引入的概念,并展示了企业网络模型如何推广到广泛的场景。包括这些用例是为了提供示例、邀请批评和评论,并探索使用RANGER架构创建下一代互联网的潜力。假设熟悉护林员、兽医、海豹突击队和ISATAP。

2. Terminology
2. 术语

Internet Topology Hierarchy The Internet Protocol (IP) natively supports a topology hierarchy comprised of increasing aggregations of networked elements. Network interfaces of devices are grouped into subnetworks, and subnetworks are grouped into larger aggregations. Subnetworks can be optionally grouped into areas and the areas grouped into an autonomous system (AS). Alternatively, subnetworks can be directly grouped into an AS. The foundation of the IP Topology Hierarchy is the AS, which determines the administrative boundaries of a network deployment including its routing, addressing, quality of service, security, and management. Intra-domain routing occurs within an autonomous system, and inter-domain routing links autonomous systems into a "network of networks" (Internet).

Internet拓扑结构Internet协议(IP)本机支持由不断增加的网络元素聚合组成的拓扑结构。设备的网络接口分为子网,子网分为更大的聚合。子网可以选择性地分组到区域中,区域可以分组到自治系统(AS)中。或者,子网络可以直接分组为AS。IP拓扑层次结构的基础是AS,它决定网络部署的管理边界,包括路由、寻址、服务质量、安全性和管理。域内路由发生在自治系统内,域间路由将自治系统链接到“网络网络”(Internet)中。

Routing Locator (RLOC) an address assigned to an interface in an enterprise-interior routing region. Note that RLOC space is local to each enterprise network.

路由定位器(RLOC):分配给企业内部路由区域中接口的地址。请注意,RLOC空间是每个企业网络的本地空间。

The IPv4 public address space currently in use today can be considered as the RLOC space for the global Internet as a giant "enterprise network".

目前使用的IPv4公共地址空间可以被视为全球互联网的RLOC空间,作为一个巨大的“企业网络”。

Endpoint Interface iDentifier (EID) an address assigned to an edge network interface of an end system. Note that EID space is global in scope, and must be separate and distinct from any RLOC space.

端点接口标识符(EID):分配给终端系统边缘网络接口的地址。请注意,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. An 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 network the same as defined in [RFC4852], where the enterprise network 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 network 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 Default-Free Zone).

企业网络与[RFC4852]中定义的相同,其中企业网络在公共空间内部署统一的RLOC空间寻址计划,但也可能包含具有不相交的RLOC空间和/或组织分组的分区,这些分区可以被视为企业本身。因此,企业网络不一定是“一个幸福的大家庭”,而是为可能有竞争利益的不同组织的合作互联提供了一个共同点(例如,全球互联网无违约区内的情况)。

Historically, enterprise networks are associated with large corporations or academic campuses. However, in RANGER an enterprise network may exist at any IP Topology Hierarchy level. The RANGER architectural principles apply to any networked entity that has some degree of cooperative active management. This definition therefore extends to home networks, small office networks, a wide variety of Mobile Ad hoc Networks (MANETs), and even to the global Internet itself.

从历史上看,企业网络与大公司或学术校园有关。但是,在RANGER中,企业网络可能存在于任何IP拓扑层次结构级别。RANGER体系结构原则适用于任何具有某种程度的协同主动管理的网络实体。因此,这一定义扩展到家庭网络、小型办公室网络、各种移动自组织网络(MANET),甚至全球互联网本身。

site a logical and/or physical grouping of interfaces within an enterprise network commons, where the topology of the site is a proper subset of the topology of the enterprise network. 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.

在本文件其余部分,术语“企业”指企业或现场;i、 例如,RANGER原则同样适用于任何规模或形状的企业和场所。在递归分解的最低级别,单例企业边界路由器可以被视为企业本身。

Enterprise Border Router (EBR) a node at the edge of an enterprise network 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

企业边界路由器(EBR)位于企业网络边缘的节点,也被配置为覆盖网络中的隧道端点。EBR将其直接连接的网络连接到覆盖网络,并通过IP-in-IP隧道通过公共空间连接到其他EBR,从而连接到其他网络。这一定义旨在作为一种解释

architectural equivalent of the functional term "EBR" defined in [RFC5558], and is synonymous with the term "xTR" used in other contexts (e.g., [LISP]).

[RFC5558]中定义的功能术语“EBR”的体系结构等效物,与其他上下文中使用的术语“xTR”同义(如[LISP])。

Enterprise Border Gateway (EBG) an EBR that also connects the enterprise network 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 [RFC5558], and is synonymous with the term "default mapper" used in other contexts (e.g., [APT]).

企业边界网关(EBG)一种EBR,它还将企业网络连接到提供商网络和/或全球互联网。EBG通常配置为覆盖中的默认路由器,并提供转发服务,用于访问公共空间中无法通过EBR访问的IP网络。该定义旨在作为[RFC5558]中定义的功能术语“EBG”的架构等效物,并与其他上下文(例如[APT])中使用的术语“默认映射器”同义。

overlay network a virtual network manifested by routing and addressing over virtual links formed through automatic tunneling. An overlay network may span many underlying enterprise networks.

覆盖网络通过自动隧道形成的虚拟链路上的路由和寻址显示的虚拟网络。覆盖网络可以跨越许多底层企业网络。

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 enterprise networks.

6over4“在IPv4域上传输IPv6而无显式隧道”[RFC2529];通过支持多播的IPv4企业网络自动隧道单播/多播IPv6数据包的功能规范和操作规程。

ISATAP Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] [RFC5579]; functional specifications and operational practices for automatic tunneling over unicast-only enterprise networks.

ISATAP站点内自动隧道寻址协议(ISATAP)[RFC5214][RFC5579];仅单播企业网络上自动隧道的功能规范和操作规程。

VET Virtual Enterprise Traversal (VET) [RFC5558]; functional specifications and operational practices that provide a functional superset of 6over4 and ISATAP. In addition to both unicast and multicast tunneling, VET also supports address/prefix autoconfiguration as well as additional encapsulations such as IPsec, SEAL, UDP, etc.

虚拟企业遍历(VET)[RFC5558];提供6over4和ISATAP功能超集的功能规范和操作规程。除了单播和多播隧道外,VET还支持地址/前缀自动配置以及其他封装,如IPsec、SEAL、UDP等。

SEAL Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320]; a functional specification for robust packet identification and link MTU adaptation over tunnels. SEAL supports effective ingress filtering and adapts to subnetworks configured over links with diverse characteristics.

密封子网封装和适配层(密封)[RFC5320];隧道上鲁棒数据包识别和链路MTU自适应的功能规范。SEAL支持有效的入口过滤,并适应在具有不同特征的链路上配置的子网。

Within the RANGER architectural context, the SEAL "subnetwork" and RANGER "enterprise" should be considered as identical abstractions.

在RANGER架构上下文中,SEAL“子网络”和RANGER“企业”应被视为相同的抽象。

Provider-Independent (PI) prefix an 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 network mapping tables. PI prefixes that can appear in mapping tables are typically delegated to a BR by a registry, but are not aggregated by a provider network.

独立于提供商(PI)前缀EID前缀(例如,2001:DB8::/48、192.0.2/24等),可在有限范围内路由,也可能出现在企业网络映射表中。可以出现在映射表中的PI前缀通常由注册表委托给BR,但不会由提供程序网络聚合。

Provider-Aggregated (PA) prefix an 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)前缀源于PI前缀或由注册表直接委托给提供者网络的EID前缀。虽然没有广泛讨论,但它特别提到,从请求路由器的角度来看,从委托路由器的PI空间获取的前缀成为PA前缀。

Customer Premises Equipment (CPE) Router a residential or small office router that provides IPv4 and/or IPv6 support. The user or the service provider may manage the router.

客户场所设备(CPE)路由器提供IPv4和/或IPv6支持的住宅或小型办公室路由器。用户或服务提供商可以管理路由器。

Carrier-Grade NAT (CGN) a special (usually high capacity) IPv4-to-IPv4 NAT deployed within the service provider network that serves multiple subnets.

运营商级NAT(CGN):部署在服务提供商网络内的一种特殊(通常为高容量)IPv4到IPv4 NAT,为多个子网提供服务。

3. Approach
3. 方法

The RANGER [RFC5720] architecture seeks to fulfill the objectives set forth in [RFC1955]:

RANGER[RFC5720]体系结构旨在实现[RFC1955]中规定的目标:

o No Changes to Hosts

o 不更改主机

o No Changes to Most Routers

o 大多数路由器没有变化

o No New Routing Protocols

o 没有新的路由协议

o No New Internet Protocols

o 没有新的互联网协议

o No Translation of Addresses in Packets

o 数据包中的地址没有翻译

o Reduce the Routing Table Size in All Routers

o 减少所有路由器中的路由表大小

o Use the Current Internet Address Structure

o 使用当前的Internet地址结构

The RANGER enterprise network is a cooperative networked collective sharing a common (business, social, political, etc.) goal. An enterprise network can be simple or complex in composition and can operate at any IP Topology Hierarchy level. Although RANGER focuses on encapsulation, it is also compatible with both native and translated routing and addressing.

RANGER企业网络是一个共享共同(商业、社会、政治等)目标的合作网络化集体。企业网络的组成可以是简单的,也可以是复杂的,并且可以在任何IP拓扑层次结构级别上运行。尽管RANGER专注于封装,但它也与本机和转换的路由和寻址兼容。

RANGER enables a protocol and/or addressing system to be connected in a virtual overlay across an untrusted transit network, or "commons". While it does not show all possible uses, Figure 1 illustrates that RANGER supports the creation of a distributed network across an intervening commons, which could implement a dissimilar IP version, routing protocol, or addressing system.

RANGER使协议和/或寻址系统能够跨不受信任的传输网络或“公共空间”以虚拟覆盖方式连接。虽然它没有显示所有可能的用途,但图1说明了RANGER支持跨介入公共空间创建分布式网络,这可能实现不同的IP版本、路由协议或寻址系统。

              .--------------.     .--------------.     .-------------.
             /                \_ _/                \_ _/               \
             \ Enterprise A   /   \    Commons     /   \  Enterprise B /
              \_ _ _ _ _ _ _ /     \_ _ _ _ _ _ _ /     \_ _ _ _ _ _ _/
    Domains
        
              .--------------.     .--------------.     .-------------.
             /                \_ _/                \_ _/               \
             \ Enterprise A   /   \    Commons     /   \  Enterprise B /
              \_ _ _ _ _ _ _ /     \_ _ _ _ _ _ _ /     \_ _ _ _ _ _ _/
    Domains
        

Network / IPvx IPvy IPvz Protocol \ IPv6 IPv4 IPv6

网络/IPvx IPvy IPvz协议\IPv6

IP Security secured unsecured secured

IP安全有保障无保障

Mgmt Domain Entity A ISP Entity B

管理域实体A ISP实体B

/ | Public Addresses Private Addresses Public Addresses Addressing |Private Addresses Public Addresses Private Addresses | PA Addresses PI Addresses PA Addresses \ PI Addresses PA Addresses PI Addresses

/|公共地址私人地址公共地址寻址|私人地址公共地址私人地址| PA地址PI地址PA地址\PI地址PA地址PI地址PI地址

Figure 1. RANGER Links Distributed Enterprise Networks

图1。RANGER链接分布式企业网络

The RANGER concepts can be applied recursively. They can be implemented at any level within the IP Topology Hierarchy to create an enterprise-within-enterprise organizational structure extending traditional AS, area, or subnetwork boundaries. This structure uses border routers that configure tunnel endpoints to enable communications between potentially recursively nested enterprise networks in a virtual overlay network that transcends traditional administrative and organizational boundaries. In its purest form, this overlay network could therefore span the entire Internet and restore end-to-end transparency [RFC2775].

RANGER概念可以递归应用。它们可以在IP拓扑层次结构中的任何级别实现,以在企业组织结构中创建企业,扩展传统的AS、区域或子网络边界。此结构使用边界路由器,这些路由器配置隧道端点,以支持虚拟覆盖网络中潜在的递归嵌套企业网络之间的通信,该虚拟覆盖网络超越了传统的管理和组织边界。以其最纯粹的形式,这种覆盖网络可以跨越整个互联网,恢复端到端的透明度[RFC2775]。

The RANGER architecture applies the best current practice insights from previous encapsulation systems as they are currently articulated within the Virtual Enterprise Traversal [RFC5558], and Subnetwork Encapsulation and Adaptation Layer [RFC5320] functional specifications. The result is an architecture and protocol system that can be used to create arbitrarily complex, scalable IP deployments that support both unicast and multicast routing and addressing systems.

RANGER体系结构应用了以前封装系统的最佳实践见解,因为它们目前在虚拟企业遍历[RFC5558]和子网封装和适配层[RFC5320]功能规范中进行了阐述。其结果是一个体系结构和协议系统,可用于创建支持单播和多播路由和寻址系统的任意复杂、可扩展的IP部署。

RANGER supports scalable routing through a recursively nested enterprise-within-enterprise network capability. The fundamental building block is the Enterprise Border Router (EBR) (see Figure 2). The EBR is the limiting factor for RANGER recursion, and in certain contexts a singleton EBR can be viewed as an enterprise network unto itself. Traditional network infrastructures can be extended to support complex structures solely with the addition of EBRs with no other modification to any networked entity.

RANGER支持通过企业网络中递归嵌套的企业进行可伸缩路由。基本构建块是企业边界路由器(EBR)(见图2)。EBR是RANGER递归的限制因素,在某些情况下,单例EBR可以被视为自身的企业网络。传统的网络基础设施可以通过添加EBR扩展到支持复杂结构,而无需对任何网络实体进行其他修改。

An EBR can be a commercial off-the-shelf router, a tactical military radio, an aircraft mobile router, etc., but it can also be an end system (e.g., a laptop computer, a soldiers' handheld device, etc.) with an embedded gateway function [RFC1122].

EBR可以是商用现货路由器、战术军用无线电、飞机移动路由器等,但也可以是具有嵌入式网关功能的终端系统(如笔记本电脑、士兵手持设备等)[RFC1122]。

                         Provider-Edge Interfaces
                                  x   x        x
                                  |   |        |
             +--------------------+---+--------+----------+    E
             |                    |   |        |          |    n
             |    I               |   |  ....  |          |    t
             |    n           +---+---+--------+---+      |    e
             |    t           |   +--------+      /|      |    r
             |    e  I   x----+   |  Host  |   I /*+------+--< p  I
             |    r  n        |   |Function|   n|**|      |    r  n
             |    n  t        |   +--------+   t|**|      |    i  t
             |    a  e   x----+              V e|**+------+--< s  e
             |    l  r      . |              E r|**|  .   |    e  r
             |       f      . |              T f|**|  .   |       f
             |    V  a      . |   +--------+   a|**|  .   |    I  a
             |    i  c      . |   | Router |   c|**|  .   |    n  c
             |    r  e   x----+   |Function|   e \*+------+--< t  e
             |    t  s        |   +--------+      \|      |    e  s
             |    u           +---+---+--------+---+      |    r
             |    a               |   |  ....  |          |    i
             |    l               |   |        |          |    o
             +--------------------+---+--------+----------+    r
                                  |   |        |
                                  x   x        x
                        Enterprise-Edge Interfaces
        
                         Provider-Edge Interfaces
                                  x   x        x
                                  |   |        |
             +--------------------+---+--------+----------+    E
             |                    |   |        |          |    n
             |    I               |   |  ....  |          |    t
             |    n           +---+---+--------+---+      |    e
             |    t           |   +--------+      /|      |    r
             |    e  I   x----+   |  Host  |   I /*+------+--< p  I
             |    r  n        |   |Function|   n|**|      |    r  n
             |    n  t        |   +--------+   t|**|      |    i  t
             |    a  e   x----+              V e|**+------+--< s  e
             |    l  r      . |              E r|**|  .   |    e  r
             |       f      . |              T f|**|  .   |       f
             |    V  a      . |   +--------+   a|**|  .   |    I  a
             |    i  c      . |   | Router |   c|**|  .   |    n  c
             |    r  e   x----+   |Function|   e \*+------+--< t  e
             |    t  s        |   +--------+      \|      |    e  s
             |    u           +---+---+--------+---+      |    r
             |    a               |   |  ....  |          |    i
             |    l               |   |        |          |    o
             +--------------------+---+--------+----------+    r
                                  |   |        |
                                  x   x        x
                        Enterprise-Edge Interfaces
        

Figure 2. Enterprise Border Router (EBR)

图2。企业边界路由器(EBR)

EBRs connect networks and end systems to one or more enterprise networks via a repertoire of interface types. Enterprise-interior interfaces attach to a commons. Provider-edge interfaces support

EBR通过一系列接口类型将网络和终端系统连接到一个或多个企业网络。企业内部接口连接到公共空间。提供程序边缘接口支持

traditional routing relationships up the IP Topology Hierarchy, and enterprise-edge interfaces support traditional relationships down the IP Topology Hierarchy. Internal virtual interfaces are typically loopback interfaces or VMware-like host-in-host interfaces.

传统的路由关系沿着IP拓扑层次结构向上,而企业边缘接口支持沿着IP拓扑层次结构向下的传统关系。内部虚拟接口通常是环回接口或类似VMware的主机中主机接口。

VET interfaces support RANGER recursion and IP-in-IP encapsulation. VET interfaces are configured over provider-edge, enterprise-interior, or enterprise-edge interfaces to allow recursion horizontally or vertically within the IP Topology Hierarchy. A VET interface may be configured over several underlying interfaces that all connect to the same enterprise network. This creates a link-layer multiplexing capability that can provide several advantages (see [RFC1122], Section 3.3.4). One important advantage is continuous operation across failovers between multiple links attached to the same enterprise network, without any need for readdressing.

VET接口支持RANGER递归和IP-in-IP封装。VET接口通过提供程序边缘、企业内部或企业边缘接口进行配置,以允许在IP拓扑层次结构中水平或垂直递归。一个VET接口可以配置在多个底层接口上,这些接口都连接到同一个企业网络。这创造了一种链路层多路复用能力,可提供多种优势(见[RFC1122],第3.3.4节)。一个重要的优势是连接到同一企业网络的多个链路之间的故障切换可以连续运行,而无需重新安装。

Figure 3 shows two enterprise networks (each with their own internal addressing and routing systems) that communicate over a virtual overlay network across a commons. The virtual overlay is manifested by tunneling, which links enterprise networks separated by geographical remoteness, protocol incompatibility, or both. An ingress EBR (iEBR) within the left enterprise network seeks to forward encapsulated packets across the commons to the egress EBR (eEBR) within the right enterprise network.

图3显示了两个企业网络(每个企业网络都有自己的内部寻址和路由系统),它们通过一个虚拟覆盖网络跨公共空间进行通信。虚拟覆盖通过隧道实现,隧道将企业网络连接起来,这些企业网络因地理位置偏远、协议不兼容或两者兼而有之而分开。左侧企业网络中的入口EBR(iEBR)寻求将封装的数据包通过公共空间转发到右侧企业网络中的出口EBR(eEBR)。

The figure shows that the eEBR assigns a Routing Locator (RLOC) address on its interface to the commons' interior IP routing and address space, while the destination host assigns an Endpoint Interface iDentifier (EID) on its enterprise-edge interface. The iEBR uses a mapping system to discover the RLOC of an eEBR on the path to the destination EID address. A distinct mapping system is maintained within each recursively nested enterprise network instance operating at a specific level of the IP Topology Hierarchy. RANGER uses the mapping system to join peer enterprise networks via a virtual overlay across a commons.

该图显示,eEBR在其接口上将路由定位器(RLOC)地址分配给commons的内部IP路由和地址空间,而目标主机在其企业边缘接口上分配端点接口标识符(EID)。iEBR使用映射系统在到目标EID地址的路径上发现eEBR的RLOC。在每个递归嵌套的企业网络实例中维护一个不同的映射系统,该实例在IP拓扑层次结构的特定级别上运行。RANGER使用映射系统通过公共空间上的虚拟覆盖连接对等企业网络。

               Mapping System                   RLOC       EID
               . (BGP, DNS, etc.)                 .         .
         .---.------.          .----------.       .  .------.---.
        /  .         \        /            \      . /       .    \
       /  (O)      iEBR------/--------------\------eEBR     *     \
       \              /      \   Commons    /       \             /
        \_ _ _ _ _ _ /        \_ _ _ _ _ _ /         \_ _ _ _ _ _/
        
               Mapping System                   RLOC       EID
               . (BGP, DNS, etc.)                 .         .
         .---.------.          .----------.       .  .------.---.
        /  .         \        /            \      . /       .    \
       /  (O)      iEBR------/--------------\------eEBR     *     \
       \              /      \   Commons    /       \             /
        \_ _ _ _ _ _ /        \_ _ _ _ _ _ /         \_ _ _ _ _ _/
        

Enterprise Network A Enterprise Network B

企业网络A企业网络B

Figure 3. The RANGER Model

图3。游骑兵模型

EBRs must configure both RLOC and EID addresses and/or prefixes. Autoconfiguration is coordinated with Enterprise Border Gateways (EBGs) that connect to the next-higher layer in the recursive hierarchy, as specified in VET. Standard mechanisms including DHCP [RFC2131] [RFC3315] and Stateless Address Autoconfiguration (SLAAC) [RFC4862] are used for this purpose.

EBR必须配置RLOC和EID地址和/或前缀。自动配置与企业边界网关(EBG)协调,后者连接到递归层次结构中的下一个更高层,如VET中所指定。标准机制包括DHCP[RFC2131][RFC3315]和无状态地址自动配置(SLAAC)[RFC4862]用于此目的。

Similarly, EBRs require a means to discover other EBRs and EBGs that can be used as enterprise network exit points. VET specifies mechanisms for border router discovery using the global DNS and/or enterprise-local name services such as Link-Local Multicast Name Resolution (LLMNR) [RFC4795].

类似地,EBR需要一种方法来发现可用作企业网络出口点的其他EBR和EBG。VET指定使用全局DNS和/或企业本地名称服务(如链路本地多播名称解析(LLMNR)[RFC4795]的边界路由器发现机制。

The mapping system is a distributed database that is synchronized among a limited set of mapping agents. Database synchronization can be achieved by many different protocol alternatives. The most commonly used alternatives are either the Border Gateway Protocol (BGP) [RFC4271] or the Domain Name System (DNS) [RFC1035]. Mapping-system databases can be populated by many different mechanisms including administrative configuration and automated prefix registrations.

映射系统是一个分布式数据库,在一组有限的映射代理之间进行同步。数据库同步可以通过许多不同的协议替代方案来实现。最常用的替代方案是边界网关协议(BGP)[RFC4271]或域名系统(DNS)[RFC1035]。映射系统数据库可以由许多不同的机制填充,包括管理配置和自动前缀注册。

EBRs forward initial packets for which they have no mapping to an EBG. The EBG in turn forwards the packet toward the final destination and returns a redirect to inform the EBR of a better next hop if necessary. The EBR then receives a mapping reply that it can use to populate its Forwarding Information Base (FIB). It then encapsulates each forwarded packet in an outer IP header for transmission across the commons to the remote RLOC address of an eEBR. The eEBR in turn decapsulates the packets and forwards them to the destination EID address. The Routing Information Base (RIB) within the commons only needs to maintain state regarding RLOCs and not EIDs. The synchronized EID-to-RLOC mapping state is not subject to oscillations due to link state changes within the commons. RANGER supports scalable addressing by selecting a suitably large EID addressing range that is distinct from any enterprise-interior RLOC addressing ranges.

EBR转发没有映射到EBG的初始数据包。EBG依次将数据包转发到最终目的地,并返回重定向,以便在必要时通知EBR更好的下一跳。然后,EBR接收一个映射应答,它可以使用该应答填充其转发信息库(FIB)。然后,它将每个转发的数据包封装在一个外部IP报头中,以便通过公共空间传输到eEBR的远程RLOC地址。eEBR依次解除数据包的封装并将其转发到目标EID地址。commons中的路由信息库(RIB)只需要维护关于RLOC而不是EID的状态。同步EID到RLOC的映射状态不会因公用区内的链路状态更改而发生振荡。RANGER通过选择与任何企业内部RLOC寻址范围不同的适当大EID寻址范围来支持可伸缩寻址。

4. Scenarios
4. 情节
4.1. Global Concerns
4.1. 全球关切
4.1.1. Scaling the Global Inter-Domain Routing Core
4.1.1. 扩展全局域间路由核心

Growth in the Internet has created challenges in routing and addressing that have been recognized for many years [RADIR-PROB-STATE]. IPv4 [RFC0791] address space is limited, and Regional Internet Registry (RIR) allocation is passing the "very

互联网的发展给路由和寻址带来了挑战,这一点多年来一直为人们所认识[RADIR-PROB-STATE]。IPv4[RFC0791]地址空间有限,区域Internet注册表(RIR)分配正在通过“非常重要的”阶段

painful" Host Density (HD) ratio threshold of 86% (that is, 192M allocated addresses) [RFC3194]. As a result, exhaustion of the IPv4 address pool is predicted within the next two years [IPv4POOL], [HUSTON-END]. IPv6 promises to resolve the address shortage with a much larger address space, but transition is costly and could exacerbate BGP problems described below. Richer interconnection, increased multihoming (especially with provider-independent (PI) addresses), and a desire to support traffic engineering via finer control of routing has led to super-linear growth of BGP routing tables in the Default-Free Zone, or "DFZ", of the Internet. This growth is placing increasing pressures on router capacities and technology costs that are unsustainable for the longer term within the current Internet routing framework.

痛苦的“主机密度(HD)比率阈值为86%(即分配了192M个地址)[RFC3194]。因此,预计IPv4地址池将在未来两年内耗尽[IPv4POOL],[HUSTON-END].IPv6承诺用更大的地址空间解决地址短缺问题,但转换成本高昂,并可能加剧下文所述的BGP问题。更丰富的互连,更多的多宿(特别是使用独立于提供商(PI)的地址),并希望通过更精细的路由控制来支持流量工程,这导致了默认自由区或“DFZ”中BGP路由表的超线性增长“,在互联网上。这种增长给路由器的容量和技术成本带来了越来越大的压力,而在当前的互联网路由框架内,这些都是不可持续的。

RANGER allows the coordinated reuse of addresses from enterprise to enterprise by making RLOC address spaces independent of one another. Figure 4 shows how the RANGER architecture allows the use of separate address spaces for RLOC and EID addressing in the Internet. This yields more endpoint address space, especially with the use of IPv6, and also reduces the load on BGP in the Internet routing core. Note that Figure 4 could represent variants of RFC 4057 scenarios 1 and 2.

RANGER通过使RLOC地址空间彼此独立,允许在企业之间协调地重用地址。图4显示了RANGER体系结构如何允许在Internet中为RLOC和EID寻址使用单独的地址空间。这会产生更多的端点地址空间,特别是在使用IPv6的情况下,还可以减少互联网路由核心中BGP的负载。注意,图4可以表示RFC 4057场景1和场景2的变体。

      EID                          RLOC                       EID
       PA                         Spaces                       PI
   Allocation                                             Registration
                    .-------------------------------.          ^
                   /           Internet Commons      \         |
                   |  .---------------------------.   |        |
  2001:DB8::/40    | /         Enterprise A        \  | 2001:DB8:10::/56
        |          |/              10.1/16          \ |        ^
        |          ||  .-------------------------.   ||        |
        V          || /         Enterprise A.1    \  ||        |
  2001:DB8::/48    || |            10.1/16        |  || 2001:DB8:11::/56
                   ||  \_________________________/  / |
                   | \                             /  |
                   |   ---------------------------    |
                   |                                  |
                   |  .---------------------------.   |
                   | /         Enterprise B        \  |
 2001:DB8:100::/40 | |            10.1/16           | | 2001:DB8:12::/56
                   |  \____________________________/  |
                    \                                 /
                     \_______________________________/
        
      EID                          RLOC                       EID
       PA                         Spaces                       PI
   Allocation                                             Registration
                    .-------------------------------.          ^
                   /           Internet Commons      \         |
                   |  .---------------------------.   |        |
  2001:DB8::/40    | /         Enterprise A        \  | 2001:DB8:10::/56
        |          |/              10.1/16          \ |        ^
        |          ||  .-------------------------.   ||        |
        V          || /         Enterprise A.1    \  ||        |
  2001:DB8::/48    || |            10.1/16        |  || 2001:DB8:11::/56
                   ||  \_________________________/  / |
                   | \                             /  |
                   |   ---------------------------    |
                   |                                  |
                   |  .---------------------------.   |
                   | /         Enterprise B        \  |
 2001:DB8:100::/40 | |            10.1/16           | | 2001:DB8:12::/56
                   |  \____________________________/  |
                    \                                 /
                     \_______________________________/
        

Figure 4. Enterprise Networks and the Internet

图4。企业网络和因特网

RLOC address spaces are entirely independent of one another, as they are used only within an enterprise network (recall that an enterprise network can exist at any level of the IP Topology Hierarchy). Such an arrangement allows each RLOC space to maintain an independent routing system and thereby avoid the inherent scaling issues if a single monolithic routing system were used for all.

RLOC地址空间彼此完全独立,因为它们仅在企业网络中使用(请记住,企业网络可以存在于IP拓扑层次结构的任何级别)。这样的安排允许每个RLOC空间维护独立的路由系统,因此,如果所有系统都使用单个单片路由系统,则避免了固有的缩放问题。

EID address space can be provider-aggregated (PA) or PI, and taken from either IPv4 or IPv6. EID addresses (barring the use of Network Address Translation (NAT)) are globally unique, even when routable only within a more limited scope (e.g., in their own edge networks).

EID地址空间可以是提供程序聚合(PA)或PI,并且可以从IPv4或IPv6获取。EID地址(除非使用网络地址转换(NAT))是全局唯一的,即使只能在更有限的范围内(例如,在其自己的边缘网络中)进行路由。

The IRTF routing research group is investigating a Preliminary Recommendation for a routing architecture [RFC6115] that provides a taxonomy for routing scaling solutions for the global Internet inter-domain routing core. RANGER presents a core/edge separation architecture within this taxonomy that uniquely shows applicability from the core all the way out to edge networks via its recursive enterprise-within-enterprise framework. RANGER is further compatible with a number of schemes intending to address routing scaling issues, including "APT: A Practical Transit Mapping Service" [APT], "FIB Suppression with Virtual Aggregation" [GROW-VA], "Locator/ID Separation Protocol (LISP)" [LISP], and others.

IRTF路由研究小组正在研究一种路由架构[RFC6115]的初步建议,该架构为全球互联网域间路由核心的路由扩展解决方案提供了分类。RANGER在此分类法中提出了一个核心/边缘分离体系结构,该体系结构独特地显示了从核心到边缘网络的适用性,通过其企业框架中的递归企业。RANGER还与许多旨在解决路由缩放问题的方案兼容,包括“APT:一种实用的公交映射服务”[APT]、“具有虚拟聚合的FIB抑制”[GROW-VA]、“定位器/ID分离协议(LISP)”[LISP]等。

4.1.2. Supporting Large Corporate Enterprise Networks
4.1.2. 支持大型企业网络

Each enterprise network operator must be able to manage its internal networks and use the Internet infrastructure to achieve its performance and reliability goals. Enterprise networks that are multihomed or have mobile components frequently require provider-independent addressing and the ability to coordinate with multiple providers without renumbering "flag days" [RFC4192] [RFC5887]. RANGER provides a way to coordinate addressing plans and inter-enterprise routing, with full support for scalability, provider independence, mobility, multihoming, and security.

每个企业网络运营商必须能够管理其内部网络,并使用互联网基础设施来实现其性能和可靠性目标。多址或具有移动组件的企业网络通常需要独立于提供商的寻址,并且能够在不重新编号“卖旗日”的情况下与多个提供商协调[RFC4192][RFC5887]。RANGER提供了一种协调寻址计划和企业间路由的方法,完全支持可扩展性、提供商独立性、移动性、多宿主和安全性。

                             _.--------------------._
                      _.---''                         -.
                 ,--''           ,---.                 `---.
              ,-'              X5     X6            .---..  `-.
            ,\'  ,.X1-..       /         \        ,'       `.  `.
          ,\'  ,'       `.    .'  E2     '.     X8    Em     \   `.
         /   /           \   |   ,--.    |     / _,.._        \    \
        /   /   E1        \  | Y3    `.  |    | /     Y7      |     \
       ;   |    ___        | |  ` W  Y4  |... | `Y6  ,'       |      :
       |   | ,-'   `.     X2 |   `--'    |    |   `''         |      |
       :   | |  V  Y2      | \    _      /    |               |      ;
        \  | `-Y1,,'       |  \ .' Y5   /      \    ,-Y8'`-  /      /
         \  \             /    \ \_'   /       X9   `.    ,'/      /
          `. \          X3      `.__,,'          `._  Y9'','     ,'
            ` `._     _,'      ___.......X7_        `---'      ,'
              `  `---'      ,-'             `-.              -'
                 `---.      `.    E3     Z   _'        _.--'
                      `-----. \---.......---'   _.---''
                             `----------------''
        
                             _.--------------------._
                      _.---''                         -.
                 ,--''           ,---.                 `---.
              ,-'              X5     X6            .---..  `-.
            ,\'  ,.X1-..       /         \        ,'       `.  `.
          ,\'  ,'       `.    .'  E2     '.     X8    Em     \   `.
         /   /           \   |   ,--.    |     / _,.._        \    \
        /   /   E1        \  | Y3    `.  |    | /     Y7      |     \
       ;   |    ___        | |  ` W  Y4  |... | `Y6  ,'       |      :
       |   | ,-'   `.     X2 |   `--'    |    |   `''         |      |
       :   | |  V  Y2      | \    _      /    |               |      ;
        \  | `-Y1,,'       |  \ .' Y5   /      \    ,-Y8'`-  /      /
         \  \             /    \ \_'   /       X9   `.    ,'/      /
          `. \          X3      `.__,,'          `._  Y9'','     ,'
            ` `._     _,'      ___.......X7_        `---'      ,'
              `  `---'      ,-'             `-.              -'
                 `---.      `.    E3     Z   _'        _.--'
                      `-----. \---.......---'   _.---''
                             `----------------''
        
       <------------------- Global IPv4 Internet ------------------>
        
       <------------------- Global IPv4 Internet ------------------>
        

Figure 5. Enterprise Networks within the Internet Commons

图5。Internet公共空间中的企业网络

Figure 5 depicts enterprise networks E1 through Em connected to the global IPv4 Internet via Enterprise Border Routers (EBRs) X1 through X9. These same border nodes also act as Enterprise Border Gateways (EBGs) that provide default routing services for nodes within their respective enterprise networks. The global Internet forms a commons across which the various enterprise networks connect as cooperating yet potentially competing entities. Within each enterprise network there may be arbitrarily many hosts, routers, and networks (not shown in the diagram) that use addresses taken from that enterprise network's RLOC space and over which both encapsulated IP packets with (global-scoped) EID addresses and unencapsulated IP packets with (enterprise-local) RLOC addresses can be forwarded.

图5描述了通过企业边界路由器(EBR)X1到X9连接到全球IPv4互联网的企业网络E1到Em。这些边界节点还充当企业边界网关(EBG),为各自企业网络中的节点提供默认路由服务。全球互联网形成了一个公共空间,各种企业网络通过这个公共空间进行连接,成为合作但潜在竞争的实体。在每个企业网络中,可能有任意多个主机、路由器和网络(图中未显示),它们使用从该企业网络的RLOC空间获取的地址,并且可以通过这些地址转发具有(全局范围)EID地址的封装IP包和具有(企业本地)RLOC地址的未封装IP包。

Each enterprise network may encompass lower-tier networks; for instance, the singleton EBR "W" in network E2 resides in a lower-tier network (say E2.1), and (along with any of its attached devices) may be considered as an enterprise unto itself. W sees Y3 and Y4 as EBGs, which in turn see X5 and X6 as EBGs that connect to a common provider network (in this case, the Internet). Each enterprise network has one or more Endpoint Interface iDentifier (EID) address prefixes used for addressing nodes on edge networks. RANGER's map-and-encaps approach separates the mapping of EIDs to Routing Locators (RLOCs) from the Routing Information Base (RIB) in the Internet commons that are assigned to EBR router interfaces. Not only does

每个企业网络可以包括较低层的网络;例如,网络E2中的单例EBR“W”驻留在较低层网络(例如E2.1)中,并且(连同其任何连接的设备)可以被视为自身的企业。W将Y3和Y4视为EBG,而X5和X6则视为连接到公共提供商网络(在本例中为互联网)的EBG。每个企业网络都有一个或多个端点接口标识符(EID)地址前缀,用于寻址边缘网络上的节点。RANGER的map and encaps方法将EID到路由定位器(RLOC)的映射与分配给EBR路由器接口的Internet公用区中的路由信息库(RIB)分离。不仅如此

BGP in the Internet commons only need to maintain state regarding RLOCs in the Internet commons, it has fewer unique routes to maintain because only routes to EBRs are needed; traffic engineering can therefore be accommodated via the mapping database.

Internet commons中的BGP只需要维护Internet commons中RLOC的状态,因为只需要到EBR的路由,所以需要维护的唯一路由较少;因此,可以通过映射数据库来适应交通工程。

In Figure 5, enterprise network E2 represents a corporation that has multiple locations and connections to multiple ISPs. The corporation has recently merged with another corporation so that its internal network has two disjoint RLOC address spaces, but neither of the formerly separate entities can bear the burden of address renumbering. Enterprise network E2 can use a suitably large IPv4 and/or IPv6 EID addressing range (that is distinct from any enterprise-interior RLOC addressing range) to support end systems on enterprise-edge networks with no disruption to preexisting address numbering.

在图5中,企业网络E2表示一个拥有多个位置并连接到多个ISP的公司。该公司最近与另一家公司合并,因此其内部网络有两个不相交的RLOC地址空间,但以前独立的实体都无法承担地址重新编号的负担。企业网络E2可以使用适当大的IPv4和/或IPv6 EID寻址范围(不同于任何企业内部RLOC寻址范围)来支持企业边缘网络上的终端系统,而不会中断先前存在的地址编号。

As EBRs are deployed to connect enterprise networks together, ordinary routers within the enterprise network continue to function as normal and deliver both ordinary and encapsulated packets across the existing Internet infrastructure and the network's own RLOC commons. Legacy IPv4 services that bind to RLOC addresses continue to be supported even as EID-based services are rolled out. Where a legacy IP client and server are within the same RLOC address space, they simply communicate by using RLOC-based routing across the enterprise network commons. If the client and server are not within the same RLOC address space, they communicate through some form of network address and/or protocol translation (see [RFC5720], Section 3.3.4 for details). EBRs from the various enterprise networks publish their EID prefixes to an enterprise-specific mapping system, so that other EBRs from the various enterprise networks can consult the mapping system to receive the RLOC address of one or more EBRs that serve the EID prefix.

随着EBR被部署用于将企业网络连接在一起,企业网络中的普通路由器将继续正常工作,并在现有互联网基础设施和网络自身的RLOC公用空间中传递普通和封装的数据包。即使推出了基于EID的服务,绑定到RLOC地址的旧式IPv4服务仍然受到支持。如果传统IP客户机和服务器位于同一RLOC地址空间内,则它们只需通过跨企业网络公用区使用基于RLOC的路由进行通信。如果客户端和服务器不在同一RLOC地址空间内,则它们通过某种形式的网络地址和/或协议转换进行通信(有关详细信息,请参见[RFC5720],第3.3.4节)。来自各种企业网络的EBR将其EID前缀发布到特定于企业的映射系统,以便来自各种企业网络的其他EBR可以咨询映射系统以接收服务于EID前缀的一个或多个EBR的RLOC地址。

As an example, when an end system connected to W in E2.1 has a packet to send to node Z in enterprise network E3, W sends the packet to EBR Y4, which encapsulates the packet in an outer IP packet with its own source address and the RLOC address of the next-hop EBR as the destination -- in this case, X6. X6 decapsulates the packet and looks up the destination EID prefix, obtaining the RLOC of X7 as next-hop. X6 then encapsulates the IPv6 packet in a packet with RLOC address X6 as the source and X7 as the destination. X7 decapsulates the packet on receipt and forwards it via its enterprise-edge interface to node Z.

例如,当E2.1中连接到W的终端系统有一个数据包要发送到企业网络E3中的节点Z时,W将该数据包发送到EBR Y4,EBR Y4将该数据包封装在一个外部IP数据包中,其自身的源地址和下一跳EBR的RLOC地址作为目的地——在本例中为X6。X6解除数据包的封装并查找目标EID前缀,获得X7的RLOC作为下一跳。X6然后将IPv6数据包封装在一个数据包中,RLOC地址X6作为源,X7作为目标。X7在收到数据包时解除其封装,并通过其企业边缘接口将其转发到节点Z。

This example uses one thread out of many that are possible using RANGER; see [RFC5720] and [RFC5558] for other options and details. Many enterprise networks that use proxies and firewalls at their border routers today will wish to maintain that control over their enterprise borders, and the use of RANGER does not preclude such configurations (for example, see Section 4.3).

这个例子使用了许多可能使用RANGER的线程中的一个;有关其他选项和详细信息,请参见[RFC5720]和[RFC5558]。如今,在边界路由器上使用代理和防火墙的许多企业网络都希望保持对其企业边界的控制,而RANGER的使用并不排除此类配置(例如,参见第4.3节)。

4.2. Autonomous System Concerns
4.2. 自治系统关注点

An enterprise network such as E2 in Figure 5 above can represent an AS within the IP Topology Hierarchy. A possible configuration for enterprise network E2 is for each of its enterprise components to also be recursive ASs linked together using the RANGER constructs. Such a configuration is increasingly commonplace today for the networks of very large corporations (e.g., Boeing's corporate enterprise network). These networks support an internal instance of the BGP linking many corporate-internal ASs and independent from the BGP instance that maintains the RIB within the global Internet Default-Free Zone (DFZ). Such configurations are often motivated by scaling or administrative requirements.

像上面图5中的E2这样的企业网络可以表示IP拓扑层次结构中的as。企业网络E2的一种可能的配置是使用RANGER构造将其每个企业组件连接在一起。如今,这种配置在大型公司的网络(例如波音公司的企业网络)中越来越常见。这些网络支持BGP的一个内部实例,该实例链接许多公司内部ASs,并独立于在全球互联网无默认区(DFZ)内维护RIB的BGP实例。这种配置通常是由扩展或管理需求驱动的。

Such a corporate entity is internally an Internet unto itself, albeit with separate default routes leading to the true global Internet. The enterprise network E2 therefore appears to the rest of the Internet as if it were a traditional IP Topology Hierarchy AS. Since RANGER supports recursion, each AS within such a network may itself use BGP internally in place of an IGP, and can therefore also internally be composed of a locally internal Internet in a recursive fashion. This enterprise-within-enterprise framework can recursively be extended as broadly and as deeply as required in order to achieve the specific requirements of the deployment (e.g., scaling, unique administration, and/or functional compartmentalization).

这样一个公司实体在内部是一个互联网,尽管有单独的默认路径通向真正的全球互联网。因此,企业网络E2在Internet的其余部分看来似乎是一个传统的IP拓扑层次结构。由于RANGER支持递归,这样的网络中的每个AS本身可以在内部使用BGP代替IGP,因此也可以在内部以递归方式由本地内部互联网组成。企业框架中的企业可以根据需要递归地进行广泛和深入的扩展,以实现部署的特定需求(例如,扩展、独特的管理和/或功能划分)。

4.3. Small Enterprise Concerns
4.3. 小型企业关注的问题

Global enterprise networks operating at the autonomous system level of the IP Topology Hierarchy include multiple geographical regions, multiple ISPs, and complex internal structures that naturally benefit from the application of RANGER techniques. However, all other enterprise network instances (both large and small) can also be served by RANGER. For example, Small and Home Office (SOHO) networks may comprise only a few computers on a single network segment or may extend to larger configurations with security islands, internal routers and switches, etc.

在IP拓扑层次结构的自治系统级别上运行的全球企业网络包括多个地理区域、多个ISP和复杂的内部结构,这些结构自然受益于RANGER技术的应用。但是,所有其他企业网络实例(无论大小)也可以由RANGER提供服务。例如,小型和家庭办公室(SOHO)网络可能仅包括单个网段上的几台计算机,或者可能扩展到具有安全岛、内部路由器和交换机等的大型配置。

An important concern of the small enterprise network is the ability to grow the network, change ISPs, or expand to more locations without readdressing the existing network. Consider a small company that has

小型企业网络的一个重要问题是,在不重新修饰现有网络的情况下,能够扩展网络、更改ISP或扩展到更多位置。考虑一个小公司

a single location in California. The ISP connection is via a router that acts as a Network Address Translator and firewall for the company. Addresses of the few computers ("Wksta") are taken from the [RFC1918] private address space.

加州的一个单一地点。ISP通过路由器连接,路由器充当公司的网络地址转换器和防火墙。少数计算机(“Wksta”)的地址取自[RFC1918]专用地址空间。

                            ISP
                      -------|-----            Wksta        Wksta
                      |  Firewall  |_____________|____________|
                      |    NAT     |
                      -------------
        
                            ISP
                      -------|-----            Wksta        Wksta
                      |  Firewall  |_____________|____________|
                      |    NAT     |
                      -------------
        

Figure 6. Simple SOHO Network

图6。简单SOHO网络

This configuration has been adequate for the few employees performing software development work, since there is no need to expose services within the site to the outside world. But now a web presence is required as product introduction approaches. The network manager deploys an EBR either as a co-resident function on the existing NAT/ firewall platform (as depicted in Figure 7) or on a separate platform.

这种配置对于执行软件开发工作的少数员工来说已经足够了,因为不需要将站点内的服务公开给外部世界。但现在,随着产品介绍的临近,需要一个网络存在。network manager将EBR部署为现有NAT/防火墙平台(如图7所示)或单独平台上的共同驻留功能。

The EBR has a provider-edge interface connected to the ISP; the preexisting workstations; the preexisting enterprise-edge interfaces connecting the workstations; and enterprise-edge interfaces connecting several network segments connected by routers that host web servers, workstations, and other enterprise network services. A VET interface is configured over the new service network to allow the servers to be addressed from the public Internet.

EBR具有连接到ISP的提供商边缘接口;现有的工作站;连接工作站的现有企业边缘接口;以及企业边缘接口,用于连接由承载web服务器、工作站和其他企业网络服务的路由器连接的多个网段。在新的服务网络上配置了一个VET接口,以允许从公共互联网对服务器进行寻址。

                       ISP
                       |
                +------|-----+
                |           <|--
                |     VET2 < |
                |           <|---
                |            |
                |            |      Server     Server
                |      VET1 <|--------|-----------|-------
                |            |
                | +--------+ |           Wksta        Wksta
                | |Firewall| |_____________|____________|
                | |   NAT  | |
                | +--------+ |
                +------------+
        
                       ISP
                       |
                +------|-----+
                |           <|--
                |     VET2 < |
                |           <|---
                |            |
                |            |      Server     Server
                |      VET1 <|--------|-----------|-------
                |            |
                | +--------+ |           Wksta        Wksta
                | |Firewall| |_____________|____________|
                | |   NAT  | |
                | +--------+ |
                +------------+
        

Figure 7. RANGER Serving the Small Company

图7。为小公司服务的护林员

In this new configuration, the EBR maintains the services within a "demilitarized zone (DMZ)" that is accessible from the public Internet without exposing other corporate assets that are still protected by the preexisting firewall/NAT functions.

在这种新配置中,EBR在“非军事区(DMZ)”内维护服务,该区域可从公共互联网访问,而不暴露其他仍受现有防火墙/NAT功能保护的公司资产。

Shortly afterward, an infusion of venture capital allows acceleration of the product development and marketing work by adding programmers in Tokyo and sales offices in New York and London. These new branches connect via Virtual Private Network (VPN) links across the Internet, and a new VET interface (VET2) is configured over these links to form a new sub-enterprise:

不久之后,通过在东京增加程序员以及在纽约和伦敦增加销售办事处,风险资本的注入加速了产品开发和营销工作。这些新分支机构通过互联网上的虚拟专用网络(VPN)链接进行连接,并在这些链接上配置新的VET接口(VET2),以形成新的子企业:

                       ISP
                        |
                 +------|-----+
                 |           <|------------London
                 |     VET2 < |
                 |           <|--------------------New York
                 |            |
                 |            |      Server     Server
                 |     VET1  <|--------|-----------|-------
                 |            |
                 | +--------+ |          Wksta        Wksta
                 | |Firewall| |_____________|____________|
                 | |   NAT  | |
                 | +--------+ |
                 +------------+
        
                       ISP
                        |
                 +------|-----+
                 |           <|------------London
                 |     VET2 < |
                 |           <|--------------------New York
                 |            |
                 |            |      Server     Server
                 |     VET1  <|--------|-----------|-------
                 |            |
                 | +--------+ |          Wksta        Wksta
                 | |Firewall| |_____________|____________|
                 | |   NAT  | |
                 | +--------+ |
                 +------------+
        

Figure 8. RANGER for Multiple Locations

图8。多个地点的护林员

4.4. IPv4/IPv6 Transition and Coexistence
4.4. IPv4/IPv6转换与共存

End systems and networks need to accommodate long-term support for both IPv4 and IPv6. Requirements for transition include support for IPv4 applications running over IPv4 protocol stacks, IPv4 applications over IPv6 stacks, IPv4 applications over dual stacks, and IPv6 or IPv4/IPv6-capable applications over both IPv6 and dual stacks. Both encapsulation and translation will likely be needed to allow applications, enterprises, and providers to incorporate IPv6, including all intermediate states, without global coordination or a "flag day".

终端系统和网络需要长期支持IPv4和IPv6。过渡要求包括支持通过IPv4协议栈运行的IPv4应用程序、通过IPv6栈运行的IPv4应用程序、通过双栈运行的IPv4应用程序以及通过IPv6和双栈运行的IPv6或支持IPv4/IPv6的应用程序。可能需要封装和翻译来允许应用程序、企业和提供商在没有全球协调或“国旗日”的情况下合并IPv6,包括所有中间状态。

The RANGER architecture facilitates the addition of IPv6 addressing to existing IPv4 end systems and routers (i.e., via dual stack) as well as the addition of IPv6 networks to the existing set of IPv4 networks. RANGER (with VET and SEAL) makes it possible to carry packets originated in one protocol across a network infrastructure supporting another protocol or routing system. Figure 1 shows how

RANGER体系结构有助于将IPv6寻址添加到现有IPv4终端系统和路由器(即,通过双堆栈),以及将IPv6网络添加到现有IPv4网络集。RANGER(带有VET和SEAL)使得在支持另一个协议或路由系统的网络基础设施上传输源自一个协议的数据包成为可能。图1显示了如何

RANGER supports various combinations of edge (EID) and core (RLOC commons) technologies, going beyond IP version differences to include mixed security, management, and addressing as well.

RANGER支持边缘(EID)和核心(RLOC commons)技术的各种组合,超越了IP版本差异,还包括混合安全性、管理和寻址。

The RANGER architecture supports end-to-end communications across arbitrarily long paths of concatenated enterprise networks connected by EBRs. When IPv6 is used as Endpoint Interface iDentifier (EID) space, each EBR can provision a globally unique set of IPv6 EID prefixes without scaling limitations, due to the expanded IPv6 address space. For example, Figure 9 shows a pair of end systems, "H" and "J", separated by an intervening set of enterprise networks spanned by VET interfaces labeled "vet1" through "vet4", where the path between "H" and "J" traverses the EBR path "V->Y1->X2->X7->Z":

RANGER体系结构支持跨由EBR连接的连接企业网络的任意长路径进行端到端通信。当IPv6用作端点接口标识符(EID)空间时,由于扩展了IPv6地址空间,每个EBR可以提供一组全局唯一的IPv6 EID前缀,而不受缩放限制。例如,图9显示了一对终端系统“H”和“J”,由一组由标记为“vet1”到“vet4”的VET接口跨越的企业网络隔开,其中“H”和“J”之间的路径穿过EBR路径“V->Y1->X2->X7->Z”:

                                                            +------+
                                                            | IPv6 |
                                                            |Server|
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "                                               "      +--+---+
   "     . . . . . . .       . . . .      . . . .     "        |
   "   .               .    .       .    .       .    "        |
   "   .  +----+   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         .      . . . .     "
    "                 . . . . . . .                   "
      "                                              "
        " " " " " " " " " " " " " " "" " " " " " " "
        
                                                            +------+
                                                            | IPv6 |
                                                            |Server|
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "                                               "      +--+---+
   "     . . . . . . .       . . . .      . . . .     "        |
   "   .               .    .       .    .       .    "        |
   "   .  +----+   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         .      . . . .     "
    "                 . . . . . . .                   "
      "                                              "
        " " " " " " " " " " " " " " "" " " " " " " "
        

Figure 9. EBR Waypoint Navigation Using IPv6

图9。使用IPv6的EBR航路点导航

When each EBR in the path is assigned a unique set of IPv6 EID prefixes (and registers these prefixes in the appropriate routing/ mapping tables), IPv6 can be used for navigation purposes with each EBR in the path seen as a waypoint for navigation. This is true even if IPv4 is used as the enterprise-local Routing Locator (RLOC) address space and there were many IPv4 hops on the path between each pair of neighboring EBRs.

当为路径中的每个EBR分配一组唯一的IPv6 EID前缀(并将这些前缀注册到相应的路由/映射表中)时,IPv6可用于导航目的,路径中的每个EBR被视为导航的航路点。即使IPv4用作企业本地路由定位器(RLOC)地址空间,并且在每对相邻EBR之间的路径上有许多IPv4跃点,这也是正确的。

RANGER further provides a compatible framework for incorporating supporting mechanisms including protocol translation, application-layer aspects of IPv4/IPv6 transition discussed in [RFC4038], and DNS issues for IPv6 from [RFC4472]. For instances where IPv4 applications remain in use, RANGER expects that IPv4<->IPv6 translation will be supported via network-based [BEHAVE-v6v4] and/or end system stack-based (e.g., [RFC2767]) protocol translation systems. Figure 10 shows the NAT - Protocol Translation (NAT-PT)-equivalent translation in the VET router, and Figure 11 shows the "Bump-In-the-Stack" (BIS)-equivalent translation in end systems ([RFC2767]). These examples address scenarios not mentioned in RFC 4852.

RANGER还提供了一个兼容的框架,用于合并支持机制,包括协议转换、[RFC4038]中讨论的IPv4/IPv6转换的应用层方面,以及[RFC4472]中针对IPv6的DNS问题。对于IPv4应用程序仍在使用的情况,RANGER希望通过基于网络的[BEHAVE-v6v4]和/或基于终端系统堆栈(例如[RFC2767])的协议转换系统支持IPv4<->IPv6转换。图10显示了VET路由器中的NAT-协议转换(NAT-PT)-等效转换,图11显示了终端系统中的“堆栈中的凹凸”(BIS)-等效转换([RFC2767])。这些示例涉及RFC 4852中未提及的场景。

              IPv4 App A                               IPv4 App B
            _____________                            _____________
           |_TCP or UDP__|                          |_TCP or UDP__|
           |____IPv4_____|                          |____IPv4_____|
            ______|______                           _______|_____
           /             \                         /             \
           |  IPv4-Only   |                        |  IPv4-Only   |
           |   Site 1     |                        |   Site 2     |
           \_____________/                         \_____________/
            ______|______                            ______|_______
           |____IPv4_____|       _____________      |____IPv4_____|
           |NAT-PT-equiv_|      /             \     |NAT-PT-equiv_|
           |_TCP or UDP__|      |   Internet   |    |_TCP or UDP__|
           |____IPv6_____|      |   (RANGER)   |    |____IPv6_____|
           |__VET/SEAL___|      \_____________/     |__VET/SEAL___|
                  \_______________/         \___________/
        
              IPv4 App A                               IPv4 App B
            _____________                            _____________
           |_TCP or UDP__|                          |_TCP or UDP__|
           |____IPv4_____|                          |____IPv4_____|
            ______|______                           _______|_____
           /             \                         /             \
           |  IPv4-Only   |                        |  IPv4-Only   |
           |   Site 1     |                        |   Site 2     |
           \_____________/                         \_____________/
            ______|______                            ______|_______
           |____IPv4_____|       _____________      |____IPv4_____|
           |NAT-PT-equiv_|      /             \     |NAT-PT-equiv_|
           |_TCP or UDP__|      |   Internet   |    |_TCP or UDP__|
           |____IPv6_____|      |   (RANGER)   |    |____IPv6_____|
           |__VET/SEAL___|      \_____________/     |__VET/SEAL___|
                  \_______________/         \___________/
        

Figure 10. Translation in Routers

图10。路由器中的翻译

In Figure 10, an IPv4 application on end system A operates normally, and the end system sends IPv4 packets on the IPv4-only site network. The IPv4 packets are received by an Enterprise Border Router (EBR) that translates them into IPv6 packets by a NAT-PT-equivalent process. The EBR then encapsulates the packets into IPv4 and sends them across the RANGER-enabled Internet to Site 2 where they are received and decapsulated by an EBR for Site 2. The EBR uses NAT-PT-equivalent translation to translate the resulting IPv6 packet back to an IPv4 packet that is delivered across the Site 2 IPv4-only network to an IPv4 application on end system B.

在图10中,终端系统A上的IPv4应用程序正常运行,并且终端系统在仅IPv4的站点网络上发送IPv4数据包。IPv4数据包由企业边界路由器(EBR)接收,EBR通过NAT-PT等效过程将其转换为IPv6数据包。然后,EBR将数据包封装到IPv4中,并通过启用RANGER的Internet将数据包发送到站点2,在站点2上,EBR接收数据包并对其解除封装。EBR使用NAT PT等效转换将生成的IPv6数据包转换回IPv4数据包,该数据包通过站点2纯IPv4网络传送到终端系统B上的IPv4应用程序。

           IPv4 App A                               IPv4 App B
         _____________        _____________       _____________
        |_TCP or UDP__|      /             \     |_TCP or UDP__|
        |____BIS______|      |   Internet   |    |____BIS______|
        |____IPv6_____|      |   (RANGER)   |    |____IPv6_____|
        |__VET/SEAL___|      \_____________/     |__VET/SEAL___|
               \_______________/         \___________/
        
           IPv4 App A                               IPv4 App B
         _____________        _____________       _____________
        |_TCP or UDP__|      /             \     |_TCP or UDP__|
        |____BIS______|      |   Internet   |    |____BIS______|
        |____IPv6_____|      |   (RANGER)   |    |____IPv6_____|
        |__VET/SEAL___|      \_____________/     |__VET/SEAL___|
               \_______________/         \___________/
        

Figure 11. BIS-Style Translation in Dual-Stack End Systems

图11。双栈端系统中的BIS风格翻译

Figure 11 shows the simplified approach using a BIS translation process within dual-stack end systems ([RFC2767]). In this case, the IPv4 application on dual-stack end system A forms an IPv4 payload, which is then transformed into an IPv6 packet within the end system protocol stack itself. The IPv6 packet can then be encapsulated and sent across the Internet to be decapsulated and sent to the dual-stack end system hosting IPv4 application B. The BIS-equivalent process on end system B reverses the translation, yielding an IPv4 packet for consumption by the IPv4-only application.

图11显示了在双栈端系统([RFC2767])中使用BIS转换过程的简化方法。在这种情况下,双栈终端系统A上的IPv4应用程序形成IPv4有效负载,然后将其转换为终端系统协议栈本身内的IPv6数据包。然后,可以封装IPv6数据包,并通过Internet发送,以解封装并发送到承载IPv4应用程序B的双堆栈终端系统。终端系统B上的BIS等效过程会反转转换,生成IPv4数据包,供仅IPv4应用程序使用。

Other issues besides IP protocol translation may arise during IPv4-IPv6 transition; [RFC4038] points out issues including IPv4/IPv6-capable applications running on IPv4-only protocol stacks, DNS responses that include addresses of both IP versions, and the difficulty of supporting multiple application versions. It also advises that applications be converted to dual support as a preferred solution. These issues are outside the scope of this document.

IPv4-IPv6过渡期间可能会出现IP协议转换以外的其他问题;[RFC4038]指出了一些问题,包括仅在IPv4协议栈上运行的支持IPv4/IPv6的应用程序、包含两个IP版本地址的DNS响应,以及支持多个应用程序版本的困难。它还建议将应用程序转换为双支持作为首选解决方案。这些问题超出了本文件的范围。

4.5. Mobility and MANET
4.5. 移动和移动自组网
4.5.1. Global Mobility Management
4.5.1. 全球流动管理

Ubiquitous wireless access enables connection to network infrastructure nearly anywhere. Vehicles and even persons can host networks that move around with them. For example, commercial aircraft networks include requirements for nomadic networks, local mobility, and global mobility where the connection point between airplane and ground station can move from one continent to another. Mobile networks need to be able to use provider-independent (PI) as well as provider-aggregated (PA) address prefixes. Some applications such as voice require rapid or seamless connection handoffs -- also known as session survivability. Internet routing should not be unduly disrupted by mobility, so movement of mobile nodes or edge networks should not cause large ripples of routing protocol traffic, especially in the DFZ.

无处不在的无线接入使得几乎任何地方都可以连接到网络基础设施。车辆甚至人都可以承载与他们一起移动的网络。例如,商用飞机网络包括游牧网络、本地机动性和全球机动性的要求,其中飞机和地面站之间的连接点可以从一个大陆移动到另一个大陆。移动网络需要能够使用提供商独立(PI)和提供商聚合(PA)地址前缀。某些应用程序(如语音)需要快速或无缝的连接切换,也称为会话生存能力。互联网路由不应被移动性过度干扰,因此移动节点或边缘网络的移动不应引起路由协议流量的大波动,特别是在DFZ中。

When a RANGER enterprise network is overlaid on the Internet, mobile nodes or mobile routers (that connect arbitrarily complex edge networks or enterprise networks) can move between different points of attachment while remaining reachable and without creating excessive routing churn. In a commercial airline scenario, an aircraft with a mobile router would move between ground station points of attachment (that may be on different continents) without the readdressing of its onboard networks. Figure 12 shows an aircraft transiting between four different access points: two that are part of Air Communications Service Provider (ACSP) 1, one in ACSP2, and the last directly to the Air Navigation Service Provider (ANSP). ACSP1 and ACSP2 in this example might be on different continents, so a traditional Mobile IP Home Agent scheme [RFC3775] [RFC5944] would result in very inefficient paths for one ACSP or the other. The aero enterprise network is an overlay that spans both continents and allows efficient paths by providing multiple entry and exit points (only one, R2, is shown).

当RANGER企业网络覆盖在Internet上时,移动节点或移动路由器(连接任意复杂的边缘网络或企业网络)可以在不同的连接点之间移动,同时保持可访问性,并且不会造成过度的路由混乱。在商业航空公司场景中,带有移动路由器的飞机将在地面站连接点(可能位于不同大陆)之间移动,而无需重新安装其机载网络。图12显示了一架飞机在四个不同的接入点之间过渡:两个是空中通信服务提供商(ACSP)1的一部分,一个在ACSP2中,最后一个直接连接到空中导航服务提供商(ANSP)。本例中的ACSP1和ACSP2可能位于不同的大陆,因此传统的移动IP归属代理方案[RFC3775][RFC5944]将导致一个ACSP或另一个ACSP的路径效率非常低。aero enterprise网络是一个覆盖两大洲的网络,通过提供多个入口和出口点(仅显示一个R2),实现高效路径。

  Aircraft - - - - - - ,.- - - - - -.- - ->
        .             ,  .           .                        +------+
         .           ,    .           .                       | IPv6 |
          .         ,      .           .                      |Server|
         " ." " " ", "" " " ." " "  " " .? " " " " "          |  S1  |
       "    .     ,          .           .            "       +--+---+
     "       .   ,            .           .            "         |
     "     . ...            . . .         . . +----+    "        |
     "   .       .        .      .      .    =+ X3 +    "        |
     "   .   v  +--- +   . v      .     .  v  +----+    ?        |
     "   .   e =+ Y1 +   . e      .     .  e  .       +----+  +--------+
     "   .   t  +----+   . t    +----+  .  t  .      =+-R2-+==+Internet|
     "   .   1   .       . 2   =+ X2 +  .  3  .       +----+  +--------+
     "    .     .         .     +----+   .   .          "        |
     "      . .             . . .         . .           "     +------+
      "    <ACSP1>       <ACSP2>        <ANSP>          "     | IPv4 |
        "                                              "      |Server|
          "                - - vet4 - -               "       |  S2  |
            " " " " " " " " " " " " " "" " " " " " "          |  S2  |
                 <-- Aero Enterprise Network -->              +------+
        
  Aircraft - - - - - - ,.- - - - - -.- - ->
        .             ,  .           .                        +------+
         .           ,    .           .                       | IPv6 |
          .         ,      .           .                      |Server|
         " ." " " ", "" " " ." " "  " " .? " " " " "          |  S1  |
       "    .     ,          .           .            "       +--+---+
     "       .   ,            .           .            "         |
     "     . ...            . . .         . . +----+    "        |
     "   .       .        .      .      .    =+ X3 +    "        |
     "   .   v  +--- +   . v      .     .  v  +----+    ?        |
     "   .   e =+ Y1 +   . e      .     .  e  .       +----+  +--------+
     "   .   t  +----+   . t    +----+  .  t  .      =+-R2-+==+Internet|
     "   .   1   .       . 2   =+ X2 +  .  3  .       +----+  +--------+
     "    .     .         .     +----+   .   .          "        |
     "      . .             . . .         . .           "     +------+
      "    <ACSP1>       <ACSP2>        <ANSP>          "     | IPv4 |
        "                                              "      |Server|
          "                - - vet4 - -               "       |  S2  |
            " " " " " " " " " " " " " "" " " " " " "          |  S2  |
                 <-- Aero Enterprise Network -->              +------+
        

Figure 12. Commercial Airplane Mobility

图12。商用飞机机动性

When the plane moves between ground stations that are located within the ACSP1 enterprise network, no routing or mapping changes need be made outside ACSP1. Moreover, if link-layer multiplexing (as mentioned in Section 3 above) is used, then the VET interface network layer is unaware of the movement. When the point of access moves to ACSP2, no changes are made outside the aero enterprise network. When the aircraft moves between ground stations of the same parent

当飞机在位于ACSP1企业网络内的地面站之间移动时,无需在ACSP1外部进行路由或映射更改。此外,如果使用链路层多路复用(如上文第3节所述),则VET接口网络层不知道该移动。当接入点移动到ACSP2时,不会在aero enterprise网络之外进行任何更改。当飞机在同一父站的地面站之间移动时

enterprise network (as indicated by the two different links from the aircraft to ACSP1 in Figure 12), the aircraft announces its PI prefixes at its new point of attachment and withdraws them from the old. The worldwide Internet sees no change, and mapping-system churn is confined to ACSP1, since the prefixes need not be announced or withdrawn within the parent aero enterprise network; i.e., the churn is isolated to lower tiers of the recursive hierarchy. This can be contrasted with the deprecated mobility solution previously fielded by Connexion, which propagated disruptive BGP changes into the Internet routing system to support mobile onboard networks.

企业网络(如图12中从飞机到ACSP1的两个不同链接所示),飞机在其新的连接点宣布其PI前缀,并从旧的连接点撤回它们。全球互联网看不到任何变化,地图系统搅动仅限于ACSP1,因为前缀不需要在母公司航空企业网络中宣布或撤销;i、 例如,客户流失被隔离到递归层次结构的较低层。这与Connexion之前推出的不推荐的移动解决方案形成对比,后者将破坏性BGP更改传播到互联网路由系统中,以支持移动车载网络。

4.5.2. First-Responder Mobile Ad Hoc Networks (MANETs)
4.5.2. 第一响应者移动自组织网络(MANET)

Many emerging network scenarios require autoconfiguration of Mobile Ad hoc Networks (MANETs). Where first responders need networking for communications and coordination between teams, RANGER allows each team or agency to quickly stand up a network and then use the autoconfiguration described in [RFC5558] to coordinate address/prefix autoconfiguration and discover border routers needed for teams and agencies to interconnect.

许多新兴的网络场景需要自动配置移动自组织网络(MANET)。当第一响应者需要联网以实现团队之间的通信和协调时,RANGER允许每个团队或机构快速建立网络,然后使用[RFC5558]中描述的自动配置来协调地址/前缀自动配置,并发现团队和机构互连所需的边界路由器。

For example, Figure 13 shows how police units arriving on a scene with no network infrastructure can create a wireless network using vehicle-mounted 802.11 hotspots with one or more cellular, 802.16, or satellite links in order to reach the Internet. In this example, the California Highway Patrol sets up an incident management center with a satellite link to the Internet and vet1 serving network L1. The Los Angeles County Sheriff team sets up network L1.1 at their field headquarters, and the Altadena police force creates the L1.2 network with their mobile units. R2 is the router that serves as an EBG for border routers X3 and X4, which connect networks L1.2 and L1.1, respectively. X3 serves vet3, and X4 serves vet2.

例如,图13显示了到达没有网络基础设施的现场的警察部队如何使用车载802.11热点创建无线网络,该热点具有一个或多个蜂窝、802.16或卫星链路,以便接入互联网。在本例中,加利福尼亚州公路巡逻队建立了一个事故管理中心,该中心通过卫星链路连接到互联网和vet1服务网络L1。洛杉矶县警长团队在其战地总部建立了L1.1网络,阿尔塔德纳警察部队用他们的机动部队建立了L1.2网络。R2是用作边界路由器X3和X4的EBG的路由器,分别连接网络L1.2和L1.1。X3为vet3服务,X4为vet2服务。

In like manner, the Angeles National Forest creates enterprise network F1, with the San Gabriel Ranger District setting up enterprise network F1.1 and the Fire Response Team Enterprise Network F1.2. R1 and R2 discover one another and become peer EBRs across the Internet by means of manual configuration. In network L1, individual PI address prefixes are announced from L1.2 and L1.1 to L1, and R2 advertises them to the satellite ISP. R1 receives a PA prefix from its WiMAX provider and delegates parts of the prefix to X1 and X2. R2 also runs an IGP with R1, advertising the PI prefixes to R1 and learning the PA prefixes there.

同样,洛杉矶国家森林局创建了企业网络F1,圣加布里埃尔流浪者区建立了企业网络F1.1和消防队企业网络F1.2。R1和R2通过手动配置相互发现并成为互联网上的对等EBR。在网络L1中,从L1.2和L1.1到L1宣布各个PI地址前缀,R2向卫星ISP播发它们。R1从其WiMAX提供商处接收PA前缀,并将部分前缀委托给X1和X2。R2还使用R1运行IGP,将PI前缀告知R1,并在R1处学习PA前缀。

                                                            +------+
                                                            | IPv6 |
                                                            |Server|
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "      Law Enforcement Enterprise Network       "      +--+---+
    "    2001:DB8:10::/56 (PI)  ---------------->     "        |
   "      . . . . . . . +--- +            . . . .     "        |
   "    .              =+ X3 +===========.       .    "  +-----+-------+
   "   .  +----+   v    +--- +           .   v   +----+  |             +
   "   .  | V  +=  e    .      . .       .   e  =+ R2 +==+             |
   "   .  +-+--+   t    .    .      +----+   t   +----+  |             |
   "   .    |      3   .    . vet2  + X4 +=  1   .    "  |             |
   "    .   H1        .     .       +----+       .    "  |             |
   "      . . . . . .        . . . .      . . . .     "  |             |
    "       <L1.2>           <L1.1>        <L1>       "  |             |
      "      10/8             10/8         10/8      "   |             |
        " " " " " " " " " " " " " " "" " " " " " " "     |   Internet  |
                                                         |             |
       " " " " " " " "" " " " " " " " " " " " " " " "    |             |
     "     USDA Forest Service Enterprise Network    "   |             |
    "         <----------------- 2001:DB8::/40 (PA)  "   |             |
   "      . . . . . . . +--- +            . . . .     "  |             |
   "    .              =+ X1 +===========.       .    "  |             |
   "   .  +----+   v    +--- +           .   v   +----+  |             |
   "   .  | J  +=  e    .      . .       .   e  =+ R1 +==+             |
   "   .  +-+--+   t    .    .      +----+   t   +----+  |             |
   "   .    |      6   .    . vet5  + X2 +=  4   .    "  +-----+-------+
   "    .   H2        .     .       +----+       .    "        |
   "      . . . . . .        . . . .      . . . .     "     +--+---+
    "       <F1.2>           <F1.1>        <F1>       "     | IPv4 |
      "      10/8             10/8         10/8      "      |Server|
        " " " " " " " " " " " " " " "" " " " " " " "        |  S2  |
                                                              +--+---+
        
                                                            +------+
                                                            | IPv6 |
                                                            |Server|
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "      Law Enforcement Enterprise Network       "      +--+---+
    "    2001:DB8:10::/56 (PI)  ---------------->     "        |
   "      . . . . . . . +--- +            . . . .     "        |
   "    .              =+ X3 +===========.       .    "  +-----+-------+
   "   .  +----+   v    +--- +           .   v   +----+  |             +
   "   .  | V  +=  e    .      . .       .   e  =+ R2 +==+             |
   "   .  +-+--+   t    .    .      +----+   t   +----+  |             |
   "   .    |      3   .    . vet2  + X4 +=  1   .    "  |             |
   "    .   H1        .     .       +----+       .    "  |             |
   "      . . . . . .        . . . .      . . . .     "  |             |
    "       <L1.2>           <L1.1>        <L1>       "  |             |
      "      10/8             10/8         10/8      "   |             |
        " " " " " " " " " " " " " " "" " " " " " " "     |   Internet  |
                                                         |             |
       " " " " " " " "" " " " " " " " " " " " " " " "    |             |
     "     USDA Forest Service Enterprise Network    "   |             |
    "         <----------------- 2001:DB8::/40 (PA)  "   |             |
   "      . . . . . . . +--- +            . . . .     "  |             |
   "    .              =+ X1 +===========.       .    "  |             |
   "   .  +----+   v    +--- +           .   v   +----+  |             |
   "   .  | J  +=  e    .      . .       .   e  =+ R1 +==+             |
   "   .  +-+--+   t    .    .      +----+   t   +----+  |             |
   "   .    |      6   .    . vet5  + X2 +=  4   .    "  +-----+-------+
   "    .   H2        .     .       +----+       .    "        |
   "      . . . . . .        . . . .      . . . .     "     +--+---+
    "       <F1.2>           <F1.1>        <F1>       "     | IPv4 |
      "      10/8             10/8         10/8      "      |Server|
        " " " " " " " " " " " " " " "" " " " " " " "        |  S2  |
                                                              +--+---+
        

Figure 13. First-Responder MANET

图13。第一响应移动自组网

4.5.3. Tactical Military MANETs
4.5.3. 战术军事移动自组网

Military networks reflect well-defined policy requirements that differ in many ways from civilian networks. The military's information security requirements result in information being labeled into specific classifications. The Bell-LaPadula model [BELL-LaPADULA] provides a mechanism to extend information security policy into networked environments. This extension creates communications security (COMSEC), whose routing and addressing elements are cleanly supported by RANGER concepts.

军事网络反映了明确的政策要求,在许多方面与民用网络有所不同。军队的信息安全要求导致信息被标记为特定的分类。Bell-LaPadula模型[Bell-LaPadula]提供了一种将信息安全策略扩展到网络环境的机制。该扩展创建了通信安全(COMSEC),其路由和寻址元素由RANGER概念明确支持。

Figure 3 shows that RANGER supports creation of a VET interface between the enterprise-interior (network) interface of two Enterprise Border Routers (EBR) located within separate enterprise networks, A and B. When this concept is applied to enterprise networks operating above the subnetwork level of the IP Topology Hierarchy, then this VET interface uses IP-in-IP encapsulation. This corresponds with a popular COMSEC approach (IPsec -- [RFC4301]). When this same RANGER concept is applied to enterprise networks operating at the subnetwork level of the IP Topology Hierarchy, then this corresponds to an older form of COMSEC (Link Layer Encryption). When the same RANGER concept is applied to enterprise networks being singleton EBR nodes (i.e., the interface level of the IP Topology Hierarchy), then this corresponds to a third military COMSEC alternative (Link Encryption).

图3显示RANGER支持在位于单独企业网络a和B内的两个企业边界路由器(EBR)的企业内部(网络)接口之间创建VET接口。当此概念应用于在IP拓扑层次结构的子网络级别上运行的企业网络时,然后这个VET接口在IP封装中使用IP。这与流行的通信安全方法(IPsec--[RFC4301])相对应。如果将相同的RANGER概念应用于在IP拓扑层次结构的子网级别上运行的企业网络,则这对应于较旧形式的COMSEC(链路层加密)。当相同的RANGER概念应用于作为单一EBR节点的企业网络(即,IP拓扑层次结构的接口级别)时,则这对应于第三种军事通信安全替代方案(链路加密)。

The previous paragraph shows the flexibility of the RANGER architecture to describe COMSEC approaches in terms of IP Topology Hierarchy structured relationships. The power of the RANGER architecture becomes apparent when one recognizes that each of the entities in Figure 3 may themselves be simple or complex network structures operating at any specific level of the IP Topology Hierarchy. (Complex structures refer to architectures that have been extended by RANGER recursion.) For example, the commons in the figure may itself be an interface, a subnetwork, an autonomous system, or an Internet. Enterprise networks A and B can be a single end system, a subnetwork, an autonomous system, or an Internet.

上一段显示了RANGER架构在描述通信安全方法的IP拓扑层次结构关系方面的灵活性。当人们认识到图3中的每个实体本身可能是在IP拓扑层次结构的任何特定级别上运行的简单或复杂的网络结构时,RANGER体系结构的威力变得显而易见。(复杂结构是指通过RANGER递归扩展的体系结构。)例如,图中的公共空间本身可能是接口、子网、自治系统或互联网。企业网络A和B可以是单端系统、子网、自治系统或Internet。

Tactical military MANETs differ from traditional networks in many ways, the most obvious being the high mobility of tactical deployments and self-forming-network attributes of MANETs themselves. Because each networked tactical entity supports a radio/router, the numbers of routers within military MANETs can be orders of magnitude more numerous (denser) than traditional civilian networks. This means that even small deployments have comparatively large router populations when compared to non-MANET deployments. Larger router populations directly create greater sensitivity to protocol scalability issues. Router scalability issues are further exacerbated because IP protocols react unfavorably to signal intermittence, which effectively dampens and constrains router scaling even when mitigation techniques are employed. Signal intermittence itself is a characteristic of mobility and the radio signal propagation attributes of local deployment environments (e.g., such issues as terrain, foliage, buildings, weather, distance, etc.). War fighting also encourages war fighters to locate into more defensible terrain features, many of which naturally reduce radio signal propagation, further increasing the probability of signal intermittence.

战术军事移动自组网在许多方面不同于传统网络,最明显的是战术部署的高移动性和移动自组网自身的自形成网络属性。由于每个联网的战术实体都支持一个无线电/路由器,因此军事移动自组网中的路由器数量可以比传统民用网络多几个数量级(更密集)。这意味着,与非MANET部署相比,即使是小型部署也有相对较大的路由器数量。更大的路由器数量直接导致对协议可伸缩性问题更敏感。路由器可伸缩性问题进一步恶化,因为IP协议对信号间歇做出不利反应,即使采用缓解技术,也会有效抑制和限制路由器的可伸缩性。信号间歇本身是机动性的一个特征,也是本地部署环境的无线电信号传播属性(例如,地形、树叶、建筑物、天气、距离等问题)。战争还鼓励作战人员定位到更具防御能力的地形特征,其中许多自然会减少无线电信号传播,进一步增加信号间歇性的可能性。

RANGER recursion enables MANETs that naturally encourage route aggregation and scaling through simple "plug and play" hierarchical arrangements that parallel organizational structures and do not entail complex manual configurations. For example, a MANET autonomous system may benefit from RANGER recursion by being physically comprised of enterprise networks that are autonomous systems themselves. This relationship can be recursively extended vertically as deep as required in order to create route aggregation between entities having common mission assignments at differing levels of abstraction. Since MANET routing is an active research topic, it is helpful to realize that these structures may or may not use routing protocols similar to their civilian IP Topology Hierarchy peers. For example, because of the behavior of BGP within highly mobile environments, the Exterior Gateway Protocol (EGP) used to link ASs may or may not be BGP and, if it is BGP, it may have unusual timer settings. However, whatever IGP and EGP is used, RANGER constructs can increase route aggregation between entities sharing common mission assignments to enable route scaling.

RANGER递归使MANET能够通过简单的“即插即用”分层安排自然地鼓励路由聚合和扩展,这种分层安排与组织结构并行,不需要复杂的手动配置。例如,MANET自治系统可以通过物理上由自治系统本身的企业网络组成而受益于RANGER递归。这种关系可以递归地垂直扩展到所需的深度,以便在具有不同抽象级别的公共任务分配的实体之间创建路由聚合。由于MANET路由是一个活跃的研究课题,因此有助于认识到这些结构可能使用或可能不使用类似于其民用IP拓扑结构对等点的路由协议。例如,由于BGP在高度移动环境中的行为,用于链接ASs的外部网关协议(EGP)可能是也可能不是BGP,如果是BGP,则可能具有异常的计时器设置。然而,无论使用什么IGP和EGP,RANGER构造都可以增加共享公共任务分配的实体之间的路由聚合,从而实现路由扩展。

Tactical military MANETs often have requirements to communicate with stationary infrastructures. By localizing mobility into an enterprise network, the specific mobility-friendly protocols can then be localized and their aggregation results presented to the stationary network using a protocol supported by the stable network. This also reduces the impact of mobility upon routing and addressing systems as reported to the stationary infrastructure. Mobility-induced route fluctuations (e.g., routing flaps) can still occur, but their impact can be dampened if RANGER constructs are used to localize them in lower tiers of the IP Topology Hierarchy. For example, enterprise network A in Figure 3 can be a military MANET, and enterprise network B may be a stationary military entity. Recall that enterprise networks A and B interface at a specific IP Topology Hierarchy level, but they may be physically extended by RANGER mechanisms. For example, enterprise network A can be a MANET enterprise that is physically a network-of-networks Internet that interfaces to enterprise network B as if it were an autonomous system. This gives enterprise network B a more stable and aggregated view of the enterprise network A Internet than would be the case if it were directly aware of A's various sub-enterprise components.

战术军事移动自组网通常需要与固定的基础设施进行通信。通过将移动性本地化到企业网络中,可以本地化特定的移动性友好协议,并使用稳定网络支持的协议将其聚合结果呈现给固定网络。这也减少了向固定基础设施报告的移动对路由和寻址系统的影响。移动性引起的路由波动(例如,路由襟翼)仍然可能发生,但如果使用RANGER构造将其定位在IP拓扑层次结构的较低层中,则其影响可能会减弱。例如,图3中的企业网络A可以是军事MANET,企业网络B可以是固定的军事实体。回想一下,企业网络A和B在特定的IP拓扑层次结构级别进行接口,但它们可以通过RANGER机制进行物理扩展。例如,企业网络A可以是一个MANET企业,它在物理上是一个与企业网络B连接的互联网网络网络,就像它是一个自治系统一样。这为企业网络B提供了一个更稳定和聚合的企业网络a Internet视图,而不是直接了解a的各种子企业组件的情况。

Another key distinctive feature of tactical military networks is that, because radio networks operate at a different classification level than the data they convey, tactical military networks have several orders of magnitude more COMSEC devices than do equivalently sized stationary military deployments (i.e., the number of COMSEC devices is a function of the number of mobile war-fighting entities). This can create significant scalability issues within the overlay COMSEC network relationships themselves. COMSEC scaling problems are

战术军事网络的另一个关键显著特征是,由于无线电网络的分类级别与其传输的数据不同,战术军事网络的通信安全设备比同等规模的固定军事部署多几个数量级(即,通信安全设备的数量是移动作战实体数量的函数)。这可能会在覆盖通信安全网络关系中产生重大的可扩展性问题。通信安全扩展问题包括

manifested in several dimensions. It is important to recognize, however, that just as RANGER recursion was used vertically to create IP Topology enterprise-within-enterprise structures in order to improve routing aggregation and scaling, so RANGER recursion allows for authorization of route-optimized transactions between peer enterprises (within the same IP Topology Hierarchy level) to improve COMSEC aggregation and scaling of the network overlay system. The RANGER use of VET also combines with the Subnetwork Encapsulation and Adaptation Layer (SEAL) to provide robust packet identification and maximum transmission unit (MTU) link adaptation services over tunnels. These capabilities protect against both source address spoofing and black holes caused by MTU limitations.

表现在几个方面。然而,必须认识到,正如RANGER递归被垂直用于在企业结构内创建IP拓扑企业,以改进路由聚合和扩展,因此RANGER递归允许对对等企业之间的路由优化事务进行授权(在同一IP拓扑层次结构级别内)以改进网络覆盖系统的通信安全聚合和扩展。VET的RANGER使用还与子网络封装和适配层(SEAL)相结合,以提供强健的数据包识别和最大传输单元(MTU)隧道上的链路适配服务。这些功能可防止源地址欺骗和MTU限制造成的黑洞。

4.6. Provider Concerns
4.6. 供应商问题

Network providers must have a way to support the protocol transitions and network types mentioned above and still remain reliable and financially sound. The RANGER architecture provides ways to support general Internet Service Providers (ISPs), cellular operator networks, and specialized networks such as the Aeronautical Telecommunications Network (ATN).

网络提供商必须有办法支持上述协议转换和网络类型,并且仍然保持可靠和财务状况良好。RANGER架构提供了支持通用互联网服务提供商(ISP)、蜂窝运营商网络和航空电信网络(ATN)等专用网络的方法。

4.6.1. ISP Networks
4.6.1. ISP网络

Internet service provider networks provide a commons for the connection of Customer Premises Equipment (CPE) routers [CPE-RTRS] that connect arbitrarily complex customer networks. This is true whether the ISP permits direct customer-to-customer communications, or whether all communications are forwarded through ISP provider-edge equipment.

互联网服务提供商网络为连接任意复杂客户网络的客户场所设备(CPE)路由器[CPE-RTR]提供了公共空间。无论ISP是否允许直接的客户间通信,或者所有通信是否通过ISP提供商边缘设备转发,都是如此。

The ISP commons must potentially support hundreds of thousands of CPE routers (or more); hence the ISP may be obliged to assign private IPv4 address allocations (i.e., instead of public) as RLOCs for CPE routers. This gives rise to a "nested NATs" scenario, which can increase the overall brittleness brought on by NAT traversal.

ISP共用空间必须可能支持数十万个CPE路由器(或更多);因此,ISP可能必须为CPE路由器分配专用IPv4地址分配(即,代替公用地址分配)作为RLOC。这就产生了一个“嵌套NAT”场景,它会增加NAT遍历带来的整体脆性。

To address this brittleness, the ISP can deploy "Carrier-Grade NATs" (CGNs) [INCR-CGN] that provide a second level of RLOC address translation on the path from the CPE to the Internet. When the CGNs are also configured as EBGs, CPE routers can discover them as default routers for reaching EID-based services using the EBG discovery mechanisms specified in VET.

为了解决这种脆弱性,ISP可以部署“载波级NAT”(CGN)[INCR-CGN],在从CPE到Internet的路径上提供第二级RLOC地址转换。当CGN也配置为EBG时,CPE路由器可以使用VET中指定的EBG发现机制将其发现为默认路由器,以达到基于EID的服务。

"Scenarios and Analysis for Introducing IPv6 into ISP Networks" [RFC4029] discusses both ISP backbone network and customer connection transition considerations; however, this document considers router-to-router tunneling use cases. Therefore the ISATAP mechanism (which

“将IPv6引入ISP网络的场景和分析”[RFC4029]讨论了ISP主干网和客户连接转换考虑事项;然而,本文档考虑了路由器到路由器隧道的用例。因此,ISATAP机制

only supports host-to-router or host-to-host tunneling) is not mentioned as a candidate technology. Early point solutions (e.g., the Tunnel Setup Protocol (TSP) [RFC5572], the Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP) [STEP], etc.) were recommended. This document suggests that RANGER, VET, and SEAL would also be suitable solutions in these networks.

仅支持主机到路由器或主机到主机隧道)未作为候选技术提及。建议采用早期点解决方案(例如,隧道设置协议(TSP)[RFC5572],简单的IPv6-in-IPv4隧道建立过程(步骤)[STEP],等等)。本文件表明,护林员、兽医和海豹突击队也是这些网络中的合适解决方案。

4.6.2. Cellular Operator Networks
4.6.2. 蜂窝运营商网络

[RFC4215] provides a (dated) "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks". It envisions an extended period of support for both IPv4 and IPv6 protocols in the operator network. User Equipment (UE) uses the Packet Data Protocol (PDP) context to establish tunnels through the operator network to a Gateway General Packet Radio Service (GPRS) Support Node (GGSN). RANGER could be used in 3GPP transition; when the UE uses IPv6, and the PDP context is established across an IPv4 provider network, the UE can configure itself as an EBR and contact the GGSN (as a RANGER EBG) through VET tunneling.

[RFC4215]提供了一份(注明日期的)“第三代合作伙伴计划(3GPP)网络中IPv6过渡的分析”。它设想在运营商网络中延长对IPv4和IPv6协议的支持期。用户设备(UE)使用分组数据协议(PDP)上下文建立通过运营商网络到网关通用分组无线业务(GPRS)支持节点(GGSN)的隧道。RANGER可用于3GPP转换;当UE使用IPv6,并且通过IPv4提供商网络建立PDP上下文时,UE可以将自己配置为EBR,并通过VET隧道与GGSN(作为RANGER EBG)联系。

Other [RFC4215] scenarios examine IPv4-only UEs, IPv6-only UEs, and various combinations of IPv4 and IPv6 within the operator network. Also to be considered are scenarios in which the UE is configured as a router or bridge that connects an end system such as a laptop computer. In that case, the UE could be the first-hop router/bridge into the cellular provider network, and the laptop computer could be configured as an EBR in the RANGER model. Again, the GGSN or a device reachable through the GGSN could serve as a RANGER EBG.

其他[RFC4215]场景检查运营商网络中仅IPv4的UE、仅IPv6的UE以及IPv4和IPv6的各种组合。还应考虑其中UE被配置为连接诸如膝上型计算机之类的终端系统的路由器或网桥的场景。在这种情况下,UE可以是进入蜂窝提供商网络的第一跳路由器/网桥,并且膝上型计算机可以配置为RANGER模型中的EBR。同样,GGSN或可通过GGSN到达的设备可以用作测距仪EBG。

4.6.3. Aeronautical Telecommunications Network (ATN)
4.6.3. 航空电信网(ATN)

The Aeronautical Telecommunications Network (ATN) is currently based on the OSI and IPv4 protocols and is deployed only in limited areas. The future ATN under consideration within the civil aviation industry will be IPv6-based. The IP variant of ATN is expected to take the form of a worldwide enterprise network that internally comprises an aeronautical-only Internet that has additional external interfaces to the global Internet. Within the ATN, there may be many Air Communications Service Provider (ACSP) and Air Navigation Service Provider (ANSP) networks that are internally organized either as autonomous systems or internets within the ATN, i.e., as depicted in Figure 5. Each of these entities may themselves be further internally subdivided into lower-tier enterprise networks organized as regional, organizational, or functional compartments. It is important to note that while ACSPs and ANSPs within the ATN will share a common objective of safety-of-flight for civil aviation services, enterprise networks may have competing business, social, or political interests that require that components be distinct ASs.

航空电信网络(ATN)目前基于OSI和IPv4协议,仅在有限的地区部署。民航行业正在考虑的未来ATN将基于IPv6。ATN的IP变体预计将采用全球企业网络的形式,该网络内部包含一个仅用于航空的互联网,该互联网具有与全球互联网的额外外部接口。在ATN内,可能存在许多空中通信服务提供商(ACSP)和空中导航服务提供商(ANSP)网络,这些网络在ATN内部组织为自治系统或互联网,如图5所示。这些实体中的每一个都可以在内部进一步细分为较低层次的企业网络,组织为区域、组织或职能部门。值得注意的是,虽然ATN内的ACSP和ANSP将共享民航服务飞行安全的共同目标,但企业网络可能具有竞争性的商业、社会或政治利益,要求组件是不同的ASs。

The RANGER principles therefore support collaborative objectives while allowing very diverse local policy distinctions. In this manner, entities that do not trust each other can create collaborative infrastructures to achieve common goals.

因此,RANGER原则支持合作目标,同时允许非常不同的地方政策区分。通过这种方式,彼此不信任的实体可以创建协作基础设施以实现共同目标。

Operational associations like this will characterize many future deployments, including the US Department of Defense's Global Information Grid (GIG). In particular, although the routing and addressing arrangements of all enterprise networks require a mutual level of cooperative active management at a certain level, scaling issues, security policy differences, free market forces, organizational differences, political distinctions, or other factors may create internal competition among entities that otherwise share common goals. This will require different enterprise networks within that association to be separated into distinct ASs that are linked within their own functional Internet relationship.

类似这样的作战关联将成为许多未来部署的特征,包括美国国防部的全球信息网格(GIG)。特别是,尽管所有企业网络的路由和寻址安排都需要在一定程度上进行相互合作的积极管理,但规模问题、安全政策差异、自由市场力量、组织差异、政治差异、,或其他因素可能会在具有共同目标的实体之间产生内部竞争。这将需要将该关联中的不同企业网络分离为不同的ASs,这些ASs在其自身的功能性Internet关系中链接。

The ATN illustrates transition from OSI protocols to IPv6. It must support mobility (see Section 4.5.1), and it serves many government and private entities that cooperate to provide safe and efficient air travel while often competing with one another. One possible way to meet these needs with RANGER is to create an overlay using IP-in-IP tunneling across the Internet, as illustrated in Figure 14. The aero overlay forms an enterprise network, so that inner packets from ACSP and ANSP edge networks that travel between VET interfaces on EBRs see their passage across the Internet as only one hop.

ATN说明了从OSI协议到IPv6的过渡。它必须支持机动性(见第4.5.1节),并为许多政府和私人实体提供服务,这些实体相互合作,提供安全高效的航空旅行,同时经常相互竞争。使用RANGER满足这些需求的一种可能方法是在Internet上的IP隧道中使用IP创建覆盖,如图14所示。aero overlay形成了一个企业网络,因此来自ACSP和ANSP边缘网络的内部数据包在EBR上的VET接口之间传输时,只需一个跃点即可通过互联网。

               _...--------------------------------------..._
              /                                              \
             (                  IPv4 Internet                 )
              -...________________________________________...-
                    |         /       |       \       |
                    |        /        |        \      |
               _...--------------------------------------..._
              /                                              \
             (                  Aero Overlay                  )
              -...________________________________________...-
               .  .         .          .            .   .
              .   .           .       .             .    .
       _...-------.._       _...-------.._      _...-------.._
      /              \     /              \    /              \
     (      ACSP1     )   (      ANSP      )  (     ACSP2      )
      -...________...-     -...________...-    -...________...-
        
               _...--------------------------------------..._
              /                                              \
             (                  IPv4 Internet                 )
              -...________________________________________...-
                    |         /       |       \       |
                    |        /        |        \      |
               _...--------------------------------------..._
              /                                              \
             (                  Aero Overlay                  )
              -...________________________________________...-
               .  .         .          .            .   .
              .   .           .       .             .    .
       _...-------.._       _...-------.._      _...-------.._
      /              \     /              \    /              \
     (      ACSP1     )   (      ANSP      )  (     ACSP2      )
      -...________...-     -...________...-    -...________...-
        

Figure 14. Aeronautical Overlay

图14。航空覆盖

Each Aeronautical Communications Service Provider (ACSP), and Aeronautical Navigation Service Provider (ANSP) constitute an enterprise network recursively nested below the aero overlay. Relationships between the various enterprise networks can vary from slight to tight integration. In the example, the ACSP and ANSP might choose to exchange full routing information for their edge networks using a coordinated global-scope RLOC address space across which ACSP and ANSP EBRs can route traffic without further mapping lookups or re-encapsulation at intermediate EBRs. Other enterprise networks that have the aero network as a common parent may not have any knowledge of each other's interior routing but will merely forward packets on a default route up to the aero overlay.

每个航空通信服务提供商(ACSP)和航空导航服务提供商(ANSP)构成了一个企业网络,递归地嵌套在航空覆盖之下。各种企业网络之间的关系可以是轻微的集成,也可以是紧密的集成。在该示例中,ACSP和ANSP可能选择使用协调的全局作用域RLOC地址空间为其边缘网络交换完整路由信息,ACSP和ANSP EBR可以通过该地址空间路由流量,而无需在中间EBR处进一步映射查找或重新封装。将aero网络作为公共父级的其他企业网络可能不知道彼此的内部路由,但只会将默认路由上的数据包转发到aero覆盖。

The ATN is currently an OSI network but is projected to transition to IPv6 over time. RANGER can bridge OSI networks together across the IPv4 (or IPv6) Internet, or bridge IPv4 or IPv6 networks across an OSI network. A pair of EBRs that have IP interfaces on a common enterprise network (whether it is the Internet, the aero network, or another parent or child enterprise network) can support communications between their attached OSI edge networks by looking up ISO network service access point (NSAP) addresses [IS8348] instead of IP addresses for RLOC mappings. OSI ConnectionLess Network Protocol (CLNP) [IS8473] packets can therefore be encapsulated within IPv4 (or IPv6) headers for transmission across an Internet Protocol enterprise network. Some OSI networks may transition to IPv6 addressing [RFC4548] while applications are adapted by using RFC 2126 [RFC2126] to carry OSI upper layers over TCP/IP, with the resulting IP packets carried across and between RANGER enterprises in the normal way. Another approach is to use subnetwork convergence to tunnel OSI network protocol data units over Internet Protocol networks [RFC1070].

ATN目前是一个OSI网络,但随着时间的推移,预计将过渡到IPv6。RANGER可以跨IPv4(或IPv6)Internet将OSI网络桥接在一起,或者跨OSI网络桥接IPv4或IPv6网络。在公共企业网络(无论是Internet、aero网络还是另一个父或子企业网络)上具有IP接口的一对EBR可以通过查找ISO网络服务接入点(NSAP)地址[IS8348]而不是RLOC映射的IP地址来支持其连接的OSI边缘网络之间的通信。因此,OSI无连接网络协议(CLNP)[IS8473]数据包可以封装在IPv4(或IPv6)报头中,以便通过Internet协议企业网络进行传输。一些OSI网络可能过渡到IPv6寻址[RFC4548],而应用程序则通过使用RFC 2126[RFC2126]通过TCP/IP承载OSI上层,由此产生的IP数据包以正常方式在RANGER企业之间传输。另一种方法是使用子网聚合在互联网协议网络上隧道OSI网络协议数据单元[RFC1070]。

Figure 15 depicts an ACSP and ANSP connected via an IPv4 aero overlay. Host H represents a system onboard an aircraft that has a wireless link to the ACSP, connected via an enterprise-edge network interface on EBR F within the ACSP enterprise network. H resides on an IPv6 edge network, and its EID is taken from the ACSP IPv6 prefix. H needs to send a query to server S in the ANSP enterprise network. H starts by sending a DNS query to the server at G, and in return it receives the EID of server S. H then creates an IPv6 packet with source EID(H) and destination EID(S) and forwards it to its default router, F. F consults G for a mapping from EID(S) to the appropriate RLOC. In this case, EBR F encapsulates the IPv6 packet in an IPv6 outer packet and forwards the packet to its default EBG, A. A decapsulates the packet and looks up the destination EID(S) by querying the DNS server at EBR B. B returns a mapping with the RLOC of EBR E. A encapsulates the IPv6 inner packet in an IPv4 outer packet with source RLOC(A) and destination RLOC(E). The packet is

图15描述了通过IPv4 aero覆盖连接的ACSP和ANSP。主机H表示飞机上的系统,该系统具有到ACSP的无线链路,通过ACSP企业网络内EBR F上的企业边缘网络接口连接。H位于IPv6边缘网络上,其EID取自ACSP IPv6前缀。H需要向ANSP企业网络中的服务器S发送查询。H首先向G处的服务器发送一个DNS查询,作为回报,它接收服务器S的EID。H然后创建一个带有源EID(H)和目标EID(S)的IPv6数据包,并将其转发到其默认路由器,F.F向G咨询EID到相应RLOC的映射。在这种情况下,EBR F将IPv6数据包封装在IPv6外部数据包中,并将数据包转发到其默认EBG A。A将数据包解封,并通过查询EBR B处的DNS服务器来查找目标EID。B返回与EBR E的RLOC的映射。A将IPv6内部数据包封装在具有源RLOC(A)的IPv4外部数据包中和目的地RLOC(E)。这包是

forwarded via EBRs C and D in the aero overlay until it reaches E, where it is decapsulated. E consults its cache of EID/RLOC mappings and finds that the EBR for S is N. E encapsulates the packet in an IPv6 packet with source RLOC(E) and destination RLOC(N). When the packet reaches N, it is decapsulated, and the inner IPv6 packet is forwarded on the edge network to the server, S.

通过航空覆盖层中的EBRs C和D转发,直到到达E,在E处解除封装。E查阅其EID/RLOC映射的缓存,发现S的EBR为N。E将数据包封装在带有源RLOC(E)和目标RLOC(N)的IPv6数据包中。当数据包到达N时,它被解除封装,内部IPv6数据包在边缘网络上转发到服务器S。

             _...--------------------------------------..._
            /           (B)                   (D)          \
           (                  Aero Overlay (IPv4)           )
            -...________________________________________...-
                 .                  .            .
               (A)                (C)            .
               .                  .              .
      _...------------------------.._           (E)
     /                               \           .
    /      (F)                        \          .
   (     [H]       ACSP (IPv6)         )         .
    \                      (G)        /          .
     \...__________________________...           .
                                                 .
                                      _...------------------------.._
                                     /                               \
                                    /     (M)                (N)      \
                                   (               ANSP (IPv6)         )
                                    \                          [S]    /
                                     \...__________________________...
        
             _...--------------------------------------..._
            /           (B)                   (D)          \
           (                  Aero Overlay (IPv4)           )
            -...________________________________________...-
                 .                  .            .
               (A)                (C)            .
               .                  .              .
      _...------------------------.._           (E)
     /                               \           .
    /      (F)                        \          .
   (     [H]       ACSP (IPv6)         )         .
    \                      (G)        /          .
     \...__________________________...           .
                                                 .
                                      _...------------------------.._
                                     /                               \
                                    /     (M)                (N)      \
                                   (               ANSP (IPv6)         )
                                    \                          [S]    /
                                     \...__________________________...
        

Figure 15. Packet Forwarding for Aeronautical Networks

图15。航空网络中的数据包转发

4.6.4. Unmanaged Networks
4.6.4. 非托管网络

"Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks" [RFC3904] considers four cases for support of IPv6-enabled routers and end systems connected to an ISP network via a gateway:

“非托管网络IPv6过渡机制评估”[RFC3904]考虑了四种情况,以支持通过网关连接到ISP网络的支持IPv6的路由器和终端系统:

a. a gateway that does not provide IPv6 at all;

a. 一个根本不提供IPv6的网关;

b. a dual-stack gateway connected to a dual-stack ISP;

b. 连接到双栈ISP的双栈网关;

c. a dual-stack gateway connected to an IPv4-only ISP; and

c. 连接到仅IPv4 ISP的双栈网关;和

d. a gateway connected to an IPv6-only ISP.

d. 连接到仅限IPv6的ISP的网关。

Case a is typified by the widespread practice of customer networks using IPv4-only NAT boxes to connect to their service providers. RANGER does not address this scenario directly; however, the Teredo mechanism [RFC4380] can provide a sufficient solution in many cases.

案例a的典型特征是客户网络广泛使用仅IPv4的NAT盒连接到其服务提供商。RANGER没有直接解决这个问题;然而,Teredo机制[RFC4380]可以在许多情况下提供足够的解决方案。

Case d is a scenario that has not yet seen widespread adoption. In this scenario, the customer network could be configured as IPv6 only, and the deployment could be considered as an IPv6-only extension to a RANGER enterprise-edge network. End systems in this scenario would still require support for legacy IPv4-only applications, and if the customer network contained IPv4-only routers and end systems the RANGER encapsulation mechanisms would still apply.

案例d是一种尚未被广泛采用的情况。在此场景中,客户网络可以配置为仅限IPv6,部署可以视为RANGER enterprise edge网络的仅限IPv6扩展。此场景中的终端系统仍然需要支持传统的仅IPv4应用程序,如果客户网络包含仅IPv4路由器和终端系统,则RANGER封装机制仍然适用。

Cases b and c correspond to the scenario of the customer gateway to the ISP becoming an IPv6 router. In that case, the gateway could become a RANGER EBR, and the scenario becomes the same as the SOHO network use cases discussed in Section 4.3. In particular, when traditional home network IPv4 NAT boxes are updated to also support IPv6 routing, the NAT box becomes a RANGER EBR.

案例b和c对应于ISP的客户网关成为IPv6路由器的场景。在这种情况下,网关可以成为RANGER EBR,场景与第4.3节中讨论的SOHO网络用例相同。特别是,当传统家庭网络IPv4 NAT盒更新为也支持IPv6路由时,NAT盒将成为RANGER EBR。

5. Mapping and Encapsulation Concerns
5. 映射和封装关注点

Mapping and encapsulation concerns related to RANGER have been discussed in Section 3.7 of [RFC5720]. These include effects of mapping systems to application traffic, the need to secure the mapping system, MTU effects, and the ability of legacy Internet networks to connect to those employing RANGER.

[RFC5720]第3.7节讨论了与RANGER相关的映射和封装问题。这些包括将系统映射到应用程序流量的影响、保护映射系统的需要、MTU影响以及传统Internet网络连接到使用RANGER的网络的能力。

6. Problem Statement and Call for Solutions
6. 问题陈述和寻求解决方案

The scenarios discussed in this document have not closely examined future growth of the native IPv6 and IPv4 Internets independently of any growth in RANGER overlay networking. For example, it is likely that current-day major Internet services that support millions of customers simultaneously (e.g., Google, Yahoo, eBay, Amazon, etc.) will continue to be served best by native Internet routing and addressing rather than by overlay network arrangements that require dynamic mapping state coordination. At the same time, however, more and more small end user networks will wish to use provider-independent addressing for multihoming via multiple ISPs as well as support traffic engineering and mobility management.

本文档中讨论的场景没有仔细研究本机IPv6和IPv4 Internet的未来增长,与RANGER覆盖网络的任何增长无关。例如,当前同时支持数百万客户的主要互联网服务(如Google、Yahoo、eBay、Amazon等)很可能继续通过本机互联网路由和寻址而不是需要动态映射状态协调的覆盖网络安排获得最佳服务。然而,与此同时,越来越多的小型终端用户网络将希望通过多个ISP使用独立于提供商的寻址来实现多宿,并支持流量工程和移动性管理。

These requirements call for an overlay network solution that is compatible with both RANGER and the IPv6 and IPv4 native Internet routing system without adversely affecting Internet routing scaling. The solution must avoid the mapping and encapsulation concerns discussed in Section 3.7 of [RFC5720]; for example, it must provide generally shortest path routing without imparting unacceptable delays for initial packets. The solution must further provide mobility management capabilities for mobile end user networks that can take

这些要求要求提供一种覆盖网络解决方案,该解决方案既与RANGER兼容,又与IPv6和IPv4本机Internet路由系统兼容,且不会对Internet路由扩展产生不利影响。解决方案必须避免[RFC5720]第3.7节中讨论的映射和封装问题;例如,它必须提供一般最短路径路由,而不会对初始数据包造成不可接受的延迟。该解决方案必须进一步为移动终端用户网络提供移动性管理能力,以便

advantage of route optimization while requiring no modifications to end systems. Finally, the solution must be based on a business model that allows end user networks to obtain Internet access services from multiple ISPs simultaneously with support for traffic engineering and fault tolerance.

路线优化的优势,同时不需要修改终端系统。最后,该解决方案必须基于一种商业模式,允许最终用户网络同时从多个ISP获得互联网接入服务,并支持流量工程和容错。

7. Summary
7. 总结

The Internet today can be considered as a giant enterprise network, with nodes in the Internet addressed from the public IPv4 address space as RLOCs. Due to the 32-bit addressing limitations of IPv4, however, continued expansion has occurred through the widespread deployment of IPv4 Network Address Translators (NATs) while IPv6 has yet to see wide adoption.

今天的互联网可以被视为一个巨大的企业网络,互联网中的节点从公共IPv4地址空间作为RLOC寻址。然而,由于IPv4的32位寻址限制,通过广泛部署IPv4网络地址转换器(NAT)实现了持续扩展,而IPv6尚未得到广泛采用。

In many senses, however, this has resulted in a degenerate manifestation of the network-of-networks model originally envisaged, e.g., in the Catenet model. Indeed, these NATed domains have the external appearance of being a simple host within the global Internet RLOC space even though they may be proxying for arbitrarily large networks of end systems. The end result is a loss of transparency in the end-to-end model; it is no longer true that any node in the Internet can directly address any other node.

然而,在许多意义上,这导致了最初设想的网络网络模型的退化表现,例如在Catenet模型中。事实上,这些域在外观上是全球互联网RLOC空间中的一个简单主机,即使它们可能代理任意大型的终端系统网络。最终结果是端到端模型的透明度降低;互联网上的任何节点都不能直接寻址任何其他节点,这已不再是事实。

RANGER enables a true network-within-network (or enterprise-within-enterprise) framework. This is true even across a wide array of deployment scenarios as documented here, and even for networks-within-networks that may be recursively nested to an arbitrary depth. RANGER therefore brings a unifying architecture applied consistently across all layers of recursion, rather than a mixed bag of point solutions that may or may not be mutually compatible. When coupled with an overlay network solution that supports coexistence with the IPv6 and IPv4 native Internet routing systems, a unified future Internet architecture is possible.

RANGER在网络(或企业内企业)框架中实现真正的网络。即使在本文所述的各种部署场景中,甚至对于可能递归嵌套到任意深度的网络中的网络,情况也是如此。因此,RANGER带来了一个统一的架构,该架构在递归的所有层上都得到了一致的应用,而不是一个混合的点解决方案包,这些点解决方案可能相互兼容,也可能互不兼容。当与支持IPv6和IPv4本机Internet路由系统共存的覆盖网络解决方案相结合时,未来统一的Internet体系结构是可能的。

8. Security Considerations
8. 安全考虑

Security considerations are addressed in [RFC5720], [RFC5558], and [RFC5320]. 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 [TUNNEL-SEC]. Security considerations for specific use cases are discussed there.

[RFC5720]、[RFC5558]和[RFC5320]中阐述了安全注意事项。虽然RANGER体系结构本身并没有解决安全问题,但它为功能规范提出了一个体系结构框架。有关隧道的安全问题,以及与RANGER架构兼容的建议,请参见[TUNNEL-SEC]。这里讨论了特定用例的安全注意事项。

9. Acknowledgements
9. 致谢

This work was inspired by the original architectural principles of the Internet supplemented with "lessons learned" by many peers from actual Internet deployments and experience developing encapsulation protocols. The editors acknowledge that they are furthering work initiated by many.

这项工作的灵感来自互联网的原始架构原则,并由许多同行从实际互联网部署和开发封装协议的经验中总结出“经验教训”。编辑们承认,他们正在推进许多人发起的工作。

10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[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月。

[RFC5720] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010.

[RFC5720]Templin,F.“具有全局企业递归(RANGER)的网络中的路由和寻址”,RFC 5720,2010年2月。

10.2. Informative References
10.2. 资料性引用

[APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and L. Zhang, "APT: A Practical Transit Mapping Service", Work in Progress, November 2007.

[APT]Jen,D.,Meisel,M.,Massey,D.,Wang,L.,Zhang,B.,和L.Zhang,“APT:一种实用的交通测绘服务”,正在进行的工作,2007年11月。

[BEHAVE-v6v4] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", Work in Progress, August 2010.

[BEHAVE-v6v4]Baker,F.,Li,X.,Bao,C.,和K.Yin,“IPv4/IPv6转换框架”,正在进行的工作,2010年8月。

[BELL-LaPADULA] Bell, D. and L. LaPadula, "Secure Computer Systems: Mathematical Foundations and Model", October 1974.

[贝尔·拉帕杜拉]贝尔,D.和L.拉帕杜拉,“安全计算机系统:数学基础和模型”,1974年10月。

[CATENET] Pouzin, L., "A Proposal for Interconnecting Packet Switching Networks", May 1974.

[CATENET]Pouzin,L.,“互连分组交换网络的提案”,1974年5月。

[CPE-RTRS] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, Ed., "Basic Requirements for IPv6 Customer Edge Routers", Work in Progress, December 2010.

[CPE-RTRS]Singh,H.,Beebee,W.,Donley,C.,Stark,B.,和O.Troan,Ed.,“IPv6客户边缘路由器的基本要求”,正在进行的工作,2010年12月。

[GROW-VA] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "FIB Suppression with Virtual Aggregation", Work in Progress, August 2010.

[GROW-VA]Francis,P.,Xu,X.,Ballani,H.,Jen,D.,Raszuk,R.,和L.Zhang,“FIB抑制与虚拟聚集”,正在进行的工作,2010年8月。

[HUSTON-END] Huston, G., "The End of the (IPv4) World is Nigher!", July 2007.

[HUSTON-END]HUSTON,G.,“IPv4世界的末日就在眼前!”,2007年7月。

[IEN48] Cerf, V., "The Catenet Model for Internetworking", July 1978.

[IEN48]Cerf,V.,“互联网的Catenet模型”,1978年7月。

[INCR-CGN] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Work in Progress, March 2009.

[INCR-CGN]Jiang,S.,Guo,D.,和B.Carpenter,“IPv6过渡的增量载波级NAT(CGN)”,正在进行的工作,2009年3月。

[IPv4POOL] Hain, T., "The IPv4 Address Pool Projection", April 2009.

[IPv4POOL]Hain,T.,“IPv4地址池投影”,2009年4月。

[IS8348] International Organization for Standardization, International Electrotechnical Commission, "Open Systems Interconnection -- Network service definition", 2002.

[IS8348]国际标准化组织,国际电工委员会,“开放系统互连——网络服务定义”,2002年。

[IS8473] International Organization for Standardization, International Electrotechnical Commission, "Protocol for providing the connectionless-mode network service: Protocol specification", 1998.

[IS8473]国际标准化组织,国际电工委员会,“提供无连接模式网络服务的协议:协议规范”,1998年。

[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, March 2009.

[LISP]Farinaci,D.,Fuller,V.,Meyer,D.,和D.Lewis,“定位器/身份分离协议(LISP)”,正在进行的工作,2009年3月。

[RADIR-PROB-STATE] Narten, T., "On the Scalability of Internet Routing", Work in Progress, February 2010.

[RADIR-PROB-STATE]Narten,T.,“互联网路由的可扩展性”,正在进行的工作,2010年2月。

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1035]Mockapetris,P.,“域名-实现和规范”,STD 13,RFC 1035,1987年11月。

[RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a subnetwork for experimentation with the OSI network layer", RFC 1070, February 1989.

[RFC1070]Hagens,R.,Hall,N.,和M.Rose,“将互联网用作OSI网络层实验的子网”,RFC 1070,1989年2月。

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122]Braden,R.,Ed.“互联网主机的要求-通信层”,STD 3,RFC 1122,1989年10月。

[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月。

[RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top of TCP (ITOT)", RFC 2126, March 1997.

[RFC2126]Poufary,Y.和A.Young,“TCP之上的ISO传输服务(ITOT)”,RFC 2126,1997年3月。

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[RFC2131]Droms,R.,“动态主机配置协议”,RFC21311997年3月。

[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月。

[RFC2767] Tsuchiya, K., Higuchi, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000.

[RFC2767]Tsuchiya,K.,Higuchi,H.,和Y.Atarashi,“使用“堆栈中的凹凸”技术(BIS)的双堆栈主机”,RFC 2767,2000年2月。

[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.

[RFC2775]Carpenter,B.,“互联网透明度”,RFC 27752000年2月。

[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", RFC 3194, November 2001.

[RFC3194]Durand,A.和C.Huitema,“地址分配效率的H密度比——H比率的更新”,RFC 31942001年11月。

[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC3315]Droms,R.,Ed.,Bound,J.,Volz,B.,Lemon,T.,Perkins,C.,和M.Carney,“IPv6的动态主机配置协议(DHCPv6)”,RFC3315,2003年7月。

[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月。

[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004.

[RFC3904]Huitema,C.,Austein,R.,Satapati,S.,和R.van der Pol,“非托管网络IPv6过渡机制的评估”,RFC 3904,2004年9月。

[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.

[RFC4029]Lind,M.,Ksinant,V.,Park,S.,Baudot,A.,和P.Savola,“将IPv6引入ISP网络的场景和分析”,RFC 40292005年3月。

[RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.

[RFC4038]Shin,M-K.,Ed.,Hong,Y-G.,Hagino,J.,Savola,P.,和E.Castro,“IPv6过渡的应用方面”,RFC 4038,2005年3月。

[RFC4057] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.

[RFC4057]Bound,J.,Ed.,“IPv6企业网络场景”,RFC 4057,2005年6月。

[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.

[RFC4192]Baker,F.,Lear,E.,和R.Droms,“在没有国旗日的情况下对IPv6网络重新编号的程序”,RFC 41922005年9月。

[RFC4215] Wiljakka, J., Ed., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.

[RFC4215]Wiljakka,J.,Ed.,“第三代合作伙伴计划(3GPP)网络中IPv6过渡的分析”,RFC 4215,2005年10月。

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4271]Rekhter,Y.,Ed.,Li,T.,Ed.,和S.Hares,Ed.,“边境网关协议4(BGP-4)”,RFC 42712006年1月。

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[RFC4301]Kent,S.和K.Seo,“互联网协议的安全架构”,RFC 43012005年12月。

[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.

[RFC4380]Huitema,C.,“Teredo:通过网络地址转换(NAT)通过UDP传输IPv6”,RFC 43802006年2月。

[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006.

[RFC4472]Durand,A.,Ihren,J.,和P.Savola,“IPv6 DNS的操作注意事项和问题”,RFC 4472,2006年4月。

[RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code Point (ICP) Assignments for NSAP Addresses", RFC 4548, May 2006.

[RFC4548]Gray,E.,Rutemiller,J.和G.Swallow,“NSAP地址的互联网代码点(ICP)分配”,RFC 4548,2006年5月。

[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.

[RFC4795]Aboba,B.,Thaler,D.,和L.Esibov,“链路本地多播名称解析(LLMNR)”,RFC 47952007年1月。

[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月。

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

[RFC4862]Thomson,S.,Narten,T.,和T.Jinmei,“IPv6无状态地址自动配置”,RFC 48622007年9月。

[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月。

[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010.

[RFC5320]Templin,F.,Ed.“子网络封装和适配层(SEAL)”,RFC 5320,2010年2月。

[RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.

[RFC5558]Templin,F.,Ed.,“虚拟企业遍历(VET)”,RFC55558,2010年2月。

[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.

[RFC5572]Blanchet,M.和F.Parent,“具有隧道设置协议(TSP)的IPv6隧道代理”,RFC 5572,2010年2月。

[RFC5579] Templin, F., Ed., "Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces", RFC 5579, February 2010.

[RFC5579]Templin,F.,Ed.“通过站点内自动隧道寻址协议(ISATAP)接口传输IPv4数据包”,RFC 5579,2010年2月。

[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.

[RFC5887]Carpenter,B.,Atkinson,R.,和H.Flinck,“重新编号仍然需要工作”,RFC 5887,2010年5月。

[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.

[RFC5944]Perkins,C.,Ed.,“IPv4的IP移动支持,修订版”,RFC 59442010年11月。

[RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", RFC 6115, February 2011.

[RFC6115]Li,T.,Ed.“路由架构的建议”,RFC 6115,2011年2月。

[STEP] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", Work in Progress, January 2004.

[步骤]Savola,P.,“简单的IPv6-in-IPv4隧道建立过程(步骤)”,正在进行的工作,2004年1月。

[TUNNEL-SEC] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns With IP Tunneling", Work in Progress, October 2010.

[TUNNEL-SEC]Krishnan,S.,Thaler,D.,和J.Hoagland,“IP隧道的安全问题”,正在进行的工作,2010年10月。

Authors' Addresses

作者地址

Steven W. Russert (editor) 1078 Ridge Crest Dr. Wenatchee, WA 98801 USA

Steven W.Russert(编辑)1078 Ridge Crest Wenatchee博士,美国华盛顿州98801

   EMail: russerts@hotmail.com
        
   EMail: russerts@hotmail.com
        

Eric W. Fleischman (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA

Eric W.Fleischman(编辑)美国华盛顿州西雅图波音研究与技术公司邮政信箱3707 MC 7L-49 98124

   EMail: eric.fleischman@boeing.com
        
   EMail: eric.fleischman@boeing.com
        

Fred L. Templin (editor) Boeing Research & Technology 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