[要約] RFC 6139は、グローバルエンタープライズ再帰（RANGER）シナリオにおけるネットワークのルーティングとアドレッシングに関するものです。このRFCの目的は、RANGERシナリオにおけるネットワークの設計と運用に関するガイドラインを提供することです。
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
グローバルエンタープライズ再帰（レンジャー）シナリオを備えたネットワークでのルーティングとアドレス指定
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.
「グローバルエンタープライズ再帰（レンジャー）を備えたネットワークでのルーティングとアドレス指定」（RFC 5720）は、スケーラブルなルーティングとアドレス指定のためのアーキテクチャのフレームワークを提供します。スケーラビリティ、プロバイダーの独立性、モビリティ、マルチホーム、交通工学、セキュリティのための漸進的に展開可能なアプローチを提供します。このドキュメントでは、アーキテクチャの機能を紹介するための一連のユースケースについて説明します。さらに、レンジャーアーキテクチャが、元々インターネットの持続的な成長を目的としていたネットワークの原則をどのように回復するかを示しています。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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
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]展開。Global Enterprise Recursion（Ranger）[RFC5720]を使用したネットワークでのルーティングとアドレス指定は、他の2つのアプローチを促進する「マップとカプセル化」アプローチのアーキテクチャ要素について説明します。このドキュメントでは、レンジャーの運用シナリオについて説明します。
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".
レンジャーは、スケーラブルなルーティングとアドレス指定のためのアーキテクチャフレームワークを提供します。次世代インターネットのスケーラビリティ、プロバイダーの独立性、モビリティ、マルチホーム、セキュリティを提供します。レンジャーアーキテクチャの原則は新しいものではありません。彼らは、道路グループの審議[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].
これらの建築原則が最初に開発されて以来、インターネットは非常に成長しており、その進化によりこれらの能力の必要性が高まっています。インターネットは、先進国全体のビジネス、政府、および個々のユーザーにとって重要なリソースとなっています。レンジャーはこれらの歴史的な建築原則を進め、シングルトンルーターの粒度からインターネット全体に至るまでのネットワーク要素のコレクションを表すことができるユビキタスなエンタープライズネットワーク構造を作成します。このエンタープライズネットワーク構造は、トンネルエンドポイントを構成するボーダールーターを使用して、潜在的に再帰的にネストされたネットワークを接続します。各エンタープライズネットワークは、グローバルに一意のエンドポイントインターフェイス識別子（EID）でアドレス指定されたエッジネットワークとデバイスを接続する仮想オーバーレイネットワークをサポートし、完全に独立した内部ルーティングロケーター（RLOC）アドレススペースを使用できます。レンジャーのバーチャルオーバーレイは、従来の管理および組織の境界を超越することができます。したがって、このオーバーレイネットワークは、最も純粋な形で、インターネット全体に及び、[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 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.
レンジャーアーキテクチャは、サイト内自動トンネルアドレス指定プロトコル（ISATAP）[RFC5214] [RFC5579]から早期観測を引き出しましたが、現在は仮想エンタープライズトラバーサル（VET）[RFC5558]、サブネットワークのカプセル化および適応層（シール）[RFC5320]を使用しています。IPSEC [RFC4301]を含むその他のメカニズムは、機能的な構成要素をブロックします。このドキュメントでは、ユースケースについて説明し、レンジャーメカニズムがどのように適用されるかを示しています。補完的なメカニズム（DNS、DHCP、NATなど）が含まれており、さまざまなピースがどのように連携できるかを示します。「IPv6エンタープライズネットワークシナリオ」[RFC4057]および「IPv6エンタープライズネットワーク分析-IPレイヤー3フォーカス」[RFC4852]で導入された概念を拡張し、エンタープライズネットワークモデルが幅広いシナリオに一般化する方法を示しています。これらのユースケースは、例を提供し、批判やコメントを招き、レンジャーアーキテクチャを使用して次世代インターネットを作成する可能性を調査するために含まれています。レンジャー、獣医、シール、およびISATAPに精通していることが想定されています。
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).
インターネットトポロジ階層インターネットプロトコル（IP）は、ネットワーク化された要素の集約の増加で構成されるトポロジ階層をネイティブにサポートしています。デバイスのネットワークインターフェイスはサブネットワークにグループ化され、サブネットワークはより大きな集約にグループ化されます。サブネットワークは、オプションでエリアにグループ化でき、エリアは自律システム（AS）にグループ化できます。または、サブネットワークをASに直接グループ化できます。IPトポロジー階層の基礎はASです。これは、ルーティング、アドレス指定、サービスの質、セキュリティ、および管理など、ネットワーク展開の管理境界を決定します。ドメイン内ルーティングは自律システム内で発生し、ドメイン間ルーティングは自律システムを「ネットワークのネットワーク」（インターネット）にリンクします。
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パブリックアドレススペースは、グローバルインターネットの巨大な「エンタープライズネットワーク」と見なすことができます。
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）です。Commons内のエンタープライズインタールーティング領域は、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スペースや組織グループを持つパーティションも含まれている場合があります。したがって、エンタープライズネットワークは「1つの大きな幸せな家族」である必要はありませんが、代わりに、競合する関心を持っている可能性のある多様な組織（グローバルインターネットのデフォルトフリーゾーン内のケースなど）の協力的な相互接続のコモンズを提供します。
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トポロジー階層レベルにエンタープライズネットワークが存在する場合があります。レンジャーアーキテクチャの原則は、ある程度の協力的なアクティブ管理を備えたあらゆるネットワークエンティティに適用されます。したがって、この定義は、ホームネットワーク、小さなオフィスネットワーク、多種多様なモバイルアドホックネットワーク（マネ）、さらにはグローバルなインターネット自体にまで拡張されます。
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.
このドキュメントの残りの部分を通して、「エンタープライズ」という用語は、エンタープライズまたはサイトのいずれかを指します。つまり、レンジャーの原則は、あらゆるサイズまたは形状の企業やサイトに等しく適用されます。再帰的な分解の最低レベルでは、シングルトンエンタープライズボーダールーターは、それ自体が企業と見なすことができます。
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 architectural equivalent of the functional term "EBR" defined in [RFC5558], and is synonymous with the term "xTR" used in other contexts (e.g., [LISP]).
エンタープライズボーダールーター（EBR）オーバーレイネットワークのトンネルエンドポイントとしても構成されているエンタープライズネットワークの端にあるノード。EBRSは、直接接続されたネットワークをオーバーレイネットワークに接続し、コモンズを横断するIP-in-IPトンネルを介して他のEBRに接続します。この定義は、[RFC5558]で定義されている機能用語「EBR」に相当するアーキテクチャの同等物として意図されており、他のコンテキスト（[LISP]など）で使用される「XTR」という用語と同義です。
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]).
Enterprise Border Gateway（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 Virtual Enterprise Traversal（VET）[RFC5558];6OVOR4およびISATAPの機能的なスーパーセットを提供する機能的仕様と運用プラクティス。ユニキャストとマルチキャストの両方のトンネリングに加えて、VETはアドレス/プレフィックスのオートコンチュレーションと、IPSEC、シール、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適応をリンクするための機能的仕様。シールは、効果的なイングレスフィルタリングをサポートし、多様な特性を持つリンクを介して構成されたサブネットワークに適応します。
Within the RANGER architectural context, the SEAL "subnetwork" and RANGER "enterprise" should be considered as identical abstractions.
レンジャーアーキテクチャのコンテキスト内では、シール「サブネットワーク」とレンジャー「エンタープライズ」は、同一の抽象化と見なされるべきです。
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.
Customer Premises Equipment（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-to-IPV4 NATが展開されます。
The RANGER [RFC5720] architecture seeks to fulfill the objectives set forth in [RFC1955]:
レンジャー[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 現在のインターネットアドレス構造を使用します
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 Enterprise Networkは、共通（ビジネス、社会、政治など）の目標を共有する協力的なネットワーク化された集団です。エンタープライズネットワークの構成はシンプルまたは複雑であり、あらゆるIPトポロジー階層レベルで動作できます。レンジャーはカプセル化に焦点を当てていますが、ネイティブと翻訳されたルーティングとアドレス指定の両方と互換性があります。
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が介在するコモンズ全体で分散ネットワークの作成をサポートしていることを示しています。
.--------------. .--------------. .-------------.
/ \_ _/ \_ _/ \
\ Enterprise A / \ Commons / \ Enterprise B /
\_ _ _ _ _ _ _ / \_ _ _ _ _ _ _ / \_ _ _ _ _ _ _/
Domains
Network / IPvx IPvy IPvz
Protocol \ IPv6 IPv4 IPv6
IP Security secured unsecured secured
Mgmt Domain Entity A ISP Entity 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アドレス
Figure 1. RANGER Links Distributed Enterprise Networks
図1.レンジャーリンク分散エンタープライズネットワーク
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].
レンジャーの概念は再帰的に適用できます。それらは、IPトポロジー階層内の任意のレベルで実装して、従来のエリア、またはサブネットワークの境界、またはサブネットワークの境界を拡張するエンタープライズの組織構造を作成することができます。この構造は、トンネルエンドポイントを構成するボーダールーターを使用して、従来の管理境界と組織の境界を超える仮想オーバーレイネットワークで、潜在的に再帰的にネストされたエンタープライズネットワーク間の通信を可能にします。したがって、最も純粋な形では、このオーバーレイネットワークはインターネット全体に及び、エンドツーエンドの透明性を復元する可能性があります[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.
レンジャーアーキテクチャは、仮想エンタープライズトラバーサル[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はレンジャーの再帰の制限要因であり、特定の文脈では、シングルトン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
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 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.
EBRSは、ネットワークとエンドシステムを、インターフェイスタイプのレパートリーを介して1つ以上のエンタープライズネットワークに接続します。エンタープライズインターフェイスは、コモンズに付着します。Provider-Edgeインターフェイスは、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.
獣医インターフェイスは、レンジャーの再帰とIP-in-IPカプセル化をサポートします。VETインターフェイスは、IPトポロジー階層内で水平または垂直に再帰を可能にするために、プロバイダーエッジ、エンタープライズ内、またはエンタープライズエッジインターフェイスを介して構成されています。VETインターフェイスは、すべて同じエンタープライズネットワークに接続するいくつかの基礎となるインターフェイスで構成できます。これにより、いくつかの利点を提供できるリンク層マルチプレックス機能が作成されます（[RFC1122]、セクション3.3.4を参照）。重要な利点の1つは、再装飾を必要とせずに、同じエンタープライズネットワークに接続された複数のリンク間のフェールオーバー間の継続的な動作です。
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は、コモンズ全体の仮想オーバーレイネットワークを介して通信する2つのエンタープライズネットワーク（それぞれが独自の内部アドレス指定およびルーティングシステムを備えた）を示しています。仮想オーバーレイは、地理的遠隔性、プロトコルの非互換性、またはその両方で区切られたエンタープライズネットワークをリンクするトンネリングによって現れます。左のエンタープライズネットワーク内の侵入EBR（IERB）は、カプセル化されたパケットをコモンズを越えて右のエンタープライズネットワーク内の出口EBR（EBR）に転送しようとしています。
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.
この図は、EBRがインターフェイスにルーティングロケーター（RLOC）アドレスをCommonsのインテリアIPルーティングとアドレススペースに割り当て、宛先ホストはエンタープライズエッジインターフェイスにエンドポイントインターフェイス識別子（EID）を割り当てることを示しています。IERBは、マッピングシステムを使用して、宛先EIDアドレスへのパス上のEBRのRLOCを発見します。IPトポロジー階層の特定のレベルで動作する各再帰的にネストされたエンタープライズネットワークインスタンス内で、個別のマッピングシステムが維持されます。Rangerは、マッピングシステムを使用して、Commons全体の仮想オーバーレイを介してピアエンタープライズネットワークに参加します。
Mapping System RLOC EID
. (BGP, DNS, etc.) . .
.---.------. .----------. . .------.---.
/ . \ / \ . / . \
/ (O) iEBR------/--------------\------eEBR * \
\ / \ Commons / \ /
\_ _ _ _ _ _ / \_ _ _ _ _ _ / \_ _ _ _ _ _/
Enterprise Network A Enterprise Network B
エンタープライズネットワークエンタープライズネットワーク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アドレスおよび/またはプレフィックスの両方を構成する必要があります。Autoconfigurationは、VETで指定されているように、再帰階層の次の高層層に接続するエンタープライズボーダーゲートウェイ（EBGS）と調整されています。DHCP [RFC2131] [RFC3315]およびStateless Address Autoconfiguration（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は、Link-Local Multicast Name Resolution（LLMNR）[RFC4795]などのグローバルDNSおよび/またはエンタープライズローカルネームサービスを使用して、ボーダールーター発見のメカニズムを指定します。
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.
マッピングシステムは、限られたマッピングエージェントのセット間で同期される分散データベースです。データベースの同期は、さまざまなプロトコルの代替案によって実現できます。最も一般的に使用される代替品は、Border Gateway Protocol（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.
EBRSは、EBGへのマッピングがない初期パケットを転送します。EBGは順番にパケットを最終目的地に向けて転送し、リダイレクトを返して、必要に応じてより良い次のホップをEBRに通知します。次に、EBRは、転送情報ベース（FIB）の設定に使用できるマッピング応答を受け取ります。次に、コモンズを越えてEBRのリモートRLOCアドレスに送信するために、外側のIPヘッダーに転送された各パケットをカプセル化します。ebrは順番にパケットを脱カプセル化し、それらを宛先Eidアドレスに転送します。コモンズ内のルーティング情報ベース（RIB）は、EidsではなくRLOCに関する状態を維持する必要があります。同期されたEIDからRLOCへのマッピング状態は、コモンズ内の状態の変化をリンクするため、振動の対象ではありません。レンジャーは、エンタープライズ内のRLOCアドレス指定範囲とは異なる適切に大きなEIDアドレス指定範囲を選択することにより、スケーラブルなアドレス指定をサポートします。
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 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.
インターネットの成長は、長年にわたって認識されてきたルーティングとアドレス指定に課題をもたらしました[Radir-Probstate]。IPv4 [RFC0791]アドレススペースは制限されており、地域のインターネットレジストリ（RIR）割り当ては、86％の「非常に痛みを伴う」ホスト密度（HD）比（つまり、192M割り当てられたアドレス）[RFC3194]を通過しています。その結果、IPv4アドレスプールの消耗は、今後2年以内に[IPv4pool]、[Huston-end]に予測されます。IPv6は、はるかに大きな住所スペースで住所の不足を解決することを約束しますが、移行はコストがかかり、以下で説明するBGPの問題を悪化させる可能性があります。より豊富な相互接続、マルチホームの増加（特にプロバイダーに依存しない（PI）アドレス）、およびルーティングのより細かい制御を介して交通工学をサポートしたいという欲求は、デフォルトのフリーゾーンでの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は、レンジャーアーキテクチャがインターネットで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
| \____________________________/ |
\ /
\_______________________________/
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]の予備的な推奨事項を調査しています。レンジャーは、この分類法の中でコア/エッジ分離アーキテクチャを提示し、コアからエッジネットワークへの適用性を一意に示しており、再帰的なエンタープライズのエンタープライズフレームワークを介してエッジネットワークに至ります。レンジャーは、「APT：A Practical Transit Mapping Service」[APT]、「仮想集約によるFIB抑制」[Grow-Va]、Locator/ID分離プロトコルなど、ルーティングスケーリングの問題に対処することを目的とした多くのスキームとさらに互換性があります。lisp） "[lisp]、その他。
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]を変更せずに複数のプロバイダーと調整する機能を頻繁に必要とします。レンジャーは、スケーラビリティ、プロバイダーの独立性、モビリティ、マルチホーム、セキュリティを完全にサポートして、対処計画とエンタープライズ間ルーティングを調整する方法を提供します。
_.--------------------._
_.---'' -.
,--'' ,---. `---.
,-' 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 ------------------>
Figure 5. Enterprise Networks within the Internet Commons
図5.インターネットコモンズ内のエンタープライズネットワーク
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は、エンタープライズネットワークE1を介してEMを介して、エンタープライズボーダールーター（EBRS）X1からX9を介してグローバルIPv4インターネットに接続されています。これらの同じ境界ノードは、それぞれのエンタープライズネットワーク内のノードにデフォルトのルーティングサービスを提供するエンタープライズボーダーゲートウェイ（EBG）としても機能します。グローバルインターネットは、さまざまなエンタープライズネットワークが協力しているが潜在的に競合するエンティティとして接続するコモンズを形成します。各エンタープライズネットワーク内には、そのエンタープライズネットワークのRLOCスペースから取得したアドレスを使用し、両方が（グローバルスコープ）EIDアドレスと非カプセル化IPを備えたIPパケットをカプセル化するアドレスを使用する多くのホスト、ルーター、ネットワーク（図には示されていません）が任意に存在する場合があります。（Enterprise-Local）RLOCアドレスを備えたパケットを転送できます。
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 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.
各エンタープライズネットワークには、低層ネットワークが含まれる場合があります。たとえば、ネットワークE2のSingleton EBR "W"は、より低い層ネットワーク（E2.1など）に存在し、（その添付デバイスのいずれかとともに）は、それ自体が企業と見なされる場合があります。WをY3とY4をEBGと見なし、X5とX6を共通のプロバイダーネットワーク（この場合はインターネット）に接続するEBGと見なしています。各エンタープライズネットワークには、エッジネットワーク上のノードのアドレス指定に使用される1つ以上のエンドポイントインターフェイス識別子（EID）アドレスプレフィックスがあります。Rangerのマップアンドエンコップアプローチは、EBRルーターインターフェイスに割り当てられたインターネットコモンズのルーティング情報ベース（RIB）からEIDのルーティングロケーター（RLOC）へのマッピングを分離します。インターネットコモンズのBGPは、インターネットコモンズの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への複数の場所と接続を持つ企業を表しています。企業は最近、他の企業と合併して、その内部ネットワークに2つの馬鹿げた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コモンズ全体で通常のパケットとカプセル化されたパケットの両方を提供します。RLOCアドレスにバインドするLEGACY IPv4サービスは、EIDベースのサービスが展開されているにもかかわらず、引き続きサポートされています。レガシーIPクライアントとサーバーが同じRLOCアドレス空間内にある場合、エンタープライズネットワークコモンズ全体のRLOCベースのルーティングを使用して通信するだけです。クライアントとサーバーが同じRLOCアドレス空間内にない場合、それらは何らかの形のネットワークアドレスおよび/またはプロトコル変換を介して通信します（詳細については[RFC5720]、セクション3.3.4を参照）。さまざまなエンタープライズネットワークのEBRSは、EIDのプレフィックスをエンタープライズ固有のマッピングシステムに公開するため、さまざまなエンタープライズネットワークの他のEBRSがマッピングシステムに相談して、EIDプレフィックスを提供する1つ以上の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に送信します。これは、独自のソースアドレスを持つ外側IPパケットのパケットをカプセル化します。次のホップEBRの宛先としてのRLOCアドレス - この場合、x6。X6はパケットを脱カプセル化し、宛先EIDプレフィックスを検索し、X7のRLOCを次のホップとして取得します。X6は、RLOCアドレスX6をソースとして、X7を宛先としてX7を持つパケット内のIPv6パケットをカプセル化します。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).
この例では、レンジャーを使用して可能な多くのスレッドを使用します。他のオプションと詳細については、[RFC5720]および[RFC5558]を参照してください。今日のボーダールーターでプロキシとファイアウォールを使用する多くのエンタープライズネットワークは、その企業の境界線の制御を維持したいと考えており、レンジャーの使用はそのような構成を排除しません（たとえば、セクション4.3を参照）。
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の可能な構成は、各エンタープライズコンポーネントがレンジャーコンポーネントを使用してリンクされた再帰的なお尻であることです。このような構成は、非常に大企業（ボーイングの企業エンタープライズネットワークなど）のネットワークにとって、今日ではますます一般的になっています。これらのネットワークは、グローバルインターネットのデフォルトフリーゾーン（DFZ）内でリブを維持するBGPインスタンスから多くの企業内部のASSと独立したリンクをリンクする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は、インターネットの残りの部分に、従来のIPトポロジー階層であるかのように表示されます。レンジャーは再帰をサポートするため、それぞれがIGPの代わりに内部的にBGPを使用する可能性があるため、それぞれがIGPの代わりに内部でBGPを使用する可能性があるため、再帰的な方法でローカルな内部インターネットで構成されます。展開の特定の要件を達成するために（スケーリング、ユニークな管理、および/または機能的コンパートメント化など）、このエンタープライズ内のエンタープライズフレームワークは、必要に応じて非常に深く拡張できます。
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、およびレンジャー技術の適用から自然に恩恵を受ける複雑な内部構造が含まれます。ただし、他のすべてのエンタープライズネットワークインスタンス（大小の両方）は、レンジャーが提供することもできます。たとえば、小規模およびホームオフィス（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 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を変更したり、より多くの場所に拡張する機能です。カリフォルニアに単一の場所がある小さな会社を考えてみましょう。ISP接続は、ネットワークアドレス翻訳者として機能するルーターと会社のファイアウォールを介して行われます。少数のコンピューター（ "wksta"）のアドレスは、[RFC1918]プライベートアドレススペースから取得されます。
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.
この構成は、サイト内のサービスを外の世界に公開する必要がないため、ソフトウェア開発作業を行っている少数の従業員に適しています。しかし、製品の紹介がアプローチするにつれて、Webの存在が必要になりました。ネットワークマネージャーは、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サーバー、ワークステーション、その他のエンタープライズネットワークサービスをホストするルーターで接続されたいくつかのネットワークセグメントを接続するエンタープライズエッジインターフェイス。獣医インターフェイスは、新しいサービスネットワーク上で構成されており、サーバーにパブリックインターネットからアドレス指定できるようにします。
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は、既存のファイアウォール/NAT機能によってまだ保護されている他の企業資産を公開することなく、パブリックインターネットからアクセスできる「非武装ゾーン（DMZ）」内のサービスを維持しています。
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 | |
| +--------+ |
+------------+
Figure 8. RANGER for Multiple Locations
図8.複数の場所のレンジャー
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または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 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.
レンジャーアーキテクチャは、既存のIPv4エンドシステムとルーター（つまり、デュアルスタックを介して）にアドレス指定するIPv6の追加と、IPv4ネットワークの既存のセットへのIPv6ネットワークの追加を促進します。Ranger（VETとSEALを使用）により、別のプロトコルまたはルーティングシステムをサポートするネットワークインフラストラクチャ全体で1つのプロトコルで発信されたパケットを運ぶことができます。図1は、レンジャーがエッジ（EID）とコア（RLOCコモンズ）テクノロジーのさまざまな組み合わせをサポートする方法を示しています。
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":
レンジャーアーキテクチャは、EBRSが接続した連結エンタープライズネットワークの任意に長いパスを越えてエンドツーエンドの通信をサポートしています。IPv6がエンドポイントインターフェイス識別子（EID）スペースとして使用される場合、各EBRは、拡張されたIPv6アドレススペースのため、制限をスケーリングすることなく、IPv6 EIDプレフィックスのグローバルに一意のセットをプロビジョニングできます。たとえば、図9は、「H」と「H」の間のパスが「VET4」から「VET1」からラベル付けされたVETインターフェイスに及ぶ介在するエンタープライズネットワークの介在セットで区切られた「H」と「J」のペアを示しています。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 . . . . . "
" . . . . . . . "
" "
" " " " " " " " " " " " " " "" " " " " " " "
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は、IPv4 < - > IPv6翻訳がネットワークベース[bevave-v6v4]および/またはエンドシステムスタックベース（例えば[RFC2767]）プロトコル翻訳システムを介してサポートされると予想しています。図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___|
\_______________/ \___________/
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パケットは、NAT-PT-同等のプロセスによってIPv6パケットに変換されるEnterprise Border Router（EBR）によって受信されます。次に、EBRはパケットをIPv4にカプセル化し、レンジャー対応インターネットを介してサイト2に送信します。サイト2のEBRによって受信および脱カプセル化されています。EBRは、NAT-PT-同等の翻訳を使用して、結果のIPv6パケットを変換します。エンドシステムBのIPv4アプリケーションにサイト2 IPv4のみのネットワーク全体で配信されるIPv4パケット
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は、デュアルスタックエンドシステム内のBIS翻訳プロセスを使用した単純化されたアプローチを示しています（[RFC2767]）。この場合、デュアルスタックエンドシステムのIPv4アプリケーションは、IPv4ペイロードを形成し、エンドシステムプロトコルスタック自体内のIPv6パケットに変換されます。その後、IPv6パケットをカプセル化してインターネット上で送信して脱カプセル化し、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.
IPプロトコルの翻訳以外の他の問題は、IPv4-IPv6遷移中に発生する可能性があります。[RFC4038]は、IPv4のみのプロトコルスタックで実行されているIPv4/IPv6対応アプリケーション、両方のIPバージョンのアドレスを含むDNS応答、および複数のアプリケーションバージョンをサポートすることの難しさなどの問題を指摘しています。また、アプリケーションを優先ソリューションとしてデュアルサポートに変換することもアドバイスしています。これらの問題は、このドキュメントの範囲外です。
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）アドレスのプレフィックスを使用できる必要があります。Voiceなどの一部のアプリケーションには、セッションのサバイバビリティとも呼ばれる迅速またはシームレスな接続ハンドオフが必要です。インターネットルーティングをモビリティによって不当に混乱させるべきではないため、モバイルノードやエッジネットワークの動きは、特に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).
レンジャーエンタープライズネットワークがインターネット上でオーバーレイされると、モバイルノードまたはモバイルルーター（任意に複雑なエッジネットワークまたはエンタープライズネットワークを接続する）は、到達可能なままで過剰なルーティングチャーンを作成することなく、異なる添付ポイント間を移動できます。商用航空会社のシナリオでは、モバイルルーターを備えた航空機は、オンボードネットワークを再処理することなく、地上局のアタッチメントポイント（異なる大陸にある可能性がある）の間を移動します。図12は、4つの異なるアクセスポイント間を通過する航空機を示しています。2つは、航空通信サービスプロバイダー（ACSP）1の一部であり、1つはACSP2に、最後はAir Navigation Service Provider（ANSP）です。この例のACSP1とACSP2は異なる大陸にある可能性があるため、従来のモバイルIPホームエージェントスキーム[RFC3775] [RFC5944]は、1つのACSPまたは他のACSPに対して非常に非効率的なパスをもたらします。Aero Enterprise Networkは、両方の大陸に及ぶオーバーレイであり、複数のエントリポイントと出口ポイントを提供することで効率的なパスを可能にします（1つの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 --> +------+
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 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.
平面がACSP1エンタープライズネットワーク内にある地上ステーション間を移動する場合、ACSP1以外でルーティングやマッピングの変更を行う必要はありません。さらに、リンク層の多重化（上記のセクション3で述べたように）が使用されている場合、VETインターフェイスネットワークレイヤーは動きを認識していません。アクセスのポイントがACSP2に移動すると、Aero Enterprise Networkの外で変更は行われません。航空機が同じ親エンタープライズネットワークの地上ステーション間を移動すると（図12の航空機からACSP1への2つの異なるリンクで示されているように）、航空機は新しいポイントでPIプレフィックスを発表し、古いものから引き出します。ワールドワイドインターネットは変更を見ていません。マッピングシステムチャーンはACSP1に限定されます。なぜなら、プレフィックスをParent Aero Enterprise Network内で発表または撤回する必要はないためです。つまり、チャーンは再帰的な階層のより低い層に分離されます。これは、以前は接続によってフィールドされた非推奨モビリティソリューションとは対照的です。これにより、破壊的なBGPの変更がインターネットルーティングシステムに変化し、モバイルオンボードネットワークをサポートしていました。
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）の自動構成が必要です。最初の対応者がチーム間のコミュニケーションと調整のためのネットワーキングが必要な場合、レンジャーは各チームまたは代理店が[RFC558]に記載されている自動構成を迅速に立ち上がって、アドレス/プレフィックスオートコンフェッショナルを調整し、チームや代理店に必要なボーダールーターを発見することを可能にします。相互接続。
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は、ネットワークインフラストラクチャのないシーンに到着する警察ユニットが、インターネットに到達するために1つ以上のセルラー、802.16、または衛星リンクを備えた車両に取り付けられた802.11ホットスポットを使用してワイヤレスネットワークを作成する方法を示しています。この例では、カリフォルニアハイウェイパトロールは、インターネットとVET1サービングネットワークL1への衛星リンクを備えたインシデント管理センターを設定しています。ロサンゼルス郡保安官チームは、フィールド本部にネットワークL1.1を設定し、アルタデナ警察はモバイルユニットでL1.2ネットワークを作成します。R2は、それぞれネットワークL1.2とL1.1を接続するボーダールーターX3およびX4のEBGとして機能するルーターです。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では、個々のPIアドレスプレフィックスがL1.2およびL1.1からL1からL1を発表し、R2は衛星ISPに宣伝されます。R1は、WIMAXプロバイダーからPAプレフィックスを受け取り、プレフィックスの一部をX1およびX2に委任します。R2はR1でIGPを実行し、PIプレフィックスを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 |
+--+---+
Figure 13. First-Responder MANET
図13.ファーストレスポンダーマネ
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）を作成し、そのルーティングおよびアドレス指定要素はレンジャーの概念によってきれいにサポートされています。
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は、レンジャーが別のエンタープライズネットワーク、AおよびB内にある2つのエンタープライズボーダールーター（EBR）のエンタープライズインターフェイス（ネットワーク）インターフェイスの作成をサポートしていることを示しています。IPトポロジー階層のレベルでは、このVETインターフェイスはIP-in-IPカプセル化を使用します。これは、一般的なCOMSECアプローチ（IPSEC- [RFC4301]）に対応します。この同じレンジャーの概念が、IPトポロジー階層のサブネットワークレベルで動作するエンタープライズネットワークに適用される場合、これは古い形式のcomSec（リンクレイヤー暗号化）に対応します。同じレンジャーの概念がシングルトンEBRノード（つまり、IPトポロジ階層のインターフェイスレベル）であるエンタープライズネットワークに適用される場合、これは3番目の軍事COMSECの代替（リンク暗号化）に対応します。
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.
前の段落は、IPトポロジー階層構造の関係に関してCOMSECアプローチを説明するレンジャーアーキテクチャの柔軟性を示しています。レンジャーアーキテクチャのパワーは、図3の各エンティティ自体が、IPトポロジー階層の特定のレベルで動作する単純または複雑なネットワーク構造である可能性があることを認識すると明らかになります。（複雑な構造は、レンジャーの再帰によって拡張されたアーキテクチャを指します。）たとえば、図のコモンズ自体は、インターフェイス、サブネットワーク、自律システム、またはインターネットである可能性があります。エンタープライズネットワークAとBは、単一のエンドシステム、サブネットワーク、自律システム、またはインターネットである可能性があります。
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.
戦術的なミリタリーマネは、従来のネットワークとは多くの点で異なります。最も明白なのは、戦術的な展開と自己形成ネットワークの属性の高いモビリティ自体です。ネットワーク化された各戦術エンティティは無線/ルーターをサポートしているため、軍のマネット内のルーターの数は、従来の民間ネットワークよりも数桁（密度が高い）になる可能性があります。これは、少量の展開でさえ、非マネット展開と比較した場合、比較的大きなルーター集団を持っていることを意味します。ルーター集団が大きくなると、プロトコルスケーラビリティの問題に対する感度が向上します。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 Recursionにより、ルートの集約を自然に促進するマネが、組織構造を並列化し、複雑な手動構成を必要としない単純な「プラグアンドプレイ」階層的配置を介してスケーリングすることができます。たとえば、MANETの自律システムは、自律システム自体であるエンタープライズネットワークで物理的に構成されることにより、レンジャーの再帰の恩恵を受ける可能性があります。この関係は、異なるレベルの抽象化で共通のミッション割り当てを持つエンティティ間のルート集約を作成するために、必要に応じて垂直に再帰的に拡張される可能性があります。MANETルーティングは積極的な研究トピックであるため、これらの構造が民間のIPトポロジー階層ピアと同様のルーティングプロトコルを使用する場合と使用しない場合があることを認識することが役立ちます。たとえば、高度にモバイル環境内のBGPの動作のため、ASSのリンクに使用される外部ゲートウェイプロトコル（EGP）はBGPである場合とそうでない場合があり、BGPの場合、異常なタイマー設定がある場合があります。ただし、IGPとEGPがどのように使用されても、レンジャーコンストラクトは、ルートスケーリングを有効にするために、共通のミッション割り当てを共有するエンティティ間のルート集約を増やすことができます。
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.
戦術的な軍事マネは、しばしば定常インフラストラクチャと通信する要件を持っています。モビリティをエンタープライズネットワークにローカリングすることにより、特定のモビリティに優しいプロトコルをローカライズし、それらの集約結果を安定したネットワークでサポートするプロトコルを使用して固定ネットワークに提示します。これにより、定常インフラストラクチャに報告されたルーティングおよびアドレス指定システムに対するモビリティの影響も軽減されます。モビリティ誘発ルートの変動（たとえば、ルーティングフラップ）は引き続き発生する可能性がありますが、レンジャーコンストラクトを使用してIPトポロジー階層の下層にそれらをローカライズすると、その影響を減衰させる可能性があります。たとえば、図3のエンタープライズネットワークAはミリタリーマネであり、エンタープライズネットワークBは静止した軍事団体になる可能性があります。特定のIPトポロジー階層レベルでのエンタープライズネットワークAおよびBインターフェイスを思い出してください。ただし、レンジャーメカニズムによって物理的に拡張される可能性があります。たとえば、エンタープライズネットワークAは、自律システムであるかのようにエンタープライズネットワークBにインターフェイスする物理的にネットワークインターネットであるMANETエンタープライズです。これにより、エンタープライズネットワークBは、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.
戦術的な軍事ネットワークのもう1つの重要な特徴は、無線ネットワークが伝達するデータとは異なる分類レベルで動作するため、戦術的な軍事ネットワークには、同等のサイズの静止軍事展開よりも数桁のCOMSECデバイスがあることです。COMSECデバイスは、モバイル戦争対策エンティティの数の関数です）。これにより、オーバーレイCOMSECネットワーク関係自体に重要なスケーラビリティの問題が発生する可能性があります。COMSECスケーリングの問題は、いくつかの次元で明らかになります。ただし、ルーティングの集約とスケーリングを改善するために、レンジャーの再帰が垂直方向に使用されたように、IPトポロジーエンタープライズのエンタープライズ構造を作成したように、レンジャーの再帰により、ピアエンタープライズ間のルート最適化トランザクションの承認が可能になることを認識することが重要です。ネットワークオーバーレイシステムのCOMSECの集約とスケーリングを改善するために、同じIPトポロジー階層レベル内）。VETのレンジャー使用は、サブネットワークのカプセル化および適応層（SEAL）と組み合わさって、トンネルを介した堅牢なパケット識別と最大送信ユニット（MTU）リンク適応サービスを提供します。これらの機能は、MTUの制限によって引き起こされるソースアドレススプーフィングとブラックホールの両方から保護します。
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).
ネットワークプロバイダーは、上記のプロトコルの移行とネットワークタイプをサポートする方法を持っている必要があり、それでも信頼性があり、財政的に健全なままです。レンジャーアーキテクチャは、一般的なインターネットサービスプロバイダー（ISP）、セルラーオペレーターネットワーク、および航空通信ネットワーク（ATN）などの専門ネットワークをサポートする方法を提供します。
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-RTRS]の接続のためのコモンズを提供します。これは、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ルーターのRLOCとしてプライベートIPv4アドレスの割り当て（つまり、パブリックではなく）を割り当てる義務があります。これにより、「ネストされたNAT」シナリオが生まれ、Nat Traversalによってもたらされる全体的な脆性性を高めることができます。
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）[Incing-CGN]を展開でき、CPEからインターネットへのパスで2番目のレベルの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 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.
「IPv6をISPネットワークに導入するためのシナリオと分析」[RFC4029]は、ISPバックボーンネットワークと顧客接続の移行の両方の検討について説明しています。ただし、このドキュメントでは、ルーター間トンネルのユースケースを考慮しています。したがって、ISATAPメカニズム（ホストツールーターまたはホストからホストへのトンネルのみをサポートする）は、候補技術として言及されていません。アーリーポイントソリューション（例：トンネルセットアッププロトコル（TSP）[RFC5572]、単純なIPv6-in-IPV4トンネル確立手順（STEP）[STEP]など）が推奨されました。この文書は、レンジャー、獣医、シールもこれらのネットワークで適切な解決策になることを示唆しています。
[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）コンテキストを使用して、オペレータネットワークを介してトンネルを確立し、Gateway General Packet Radio Service（GPRS）サポートノード（GGSN）に確立します。レンジャーは3GPP遷移で使用できます。UEがIPv6を使用し、PDPコンテキストがIPv4プロバイダーネットワーク全体で確立されると、UEはEBRとして自らを設定し、VETトンネリングを介してGGSN（レンジャー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はセルラープロバイダーネットワークへの最初のホップルーター/ブリッジであり、ラップトップコンピューターはレンジャーモデルのEBRとして構成できます。繰り返しますが、GGSNまたはGGSNを介して到達可能なGGSNまたはデバイスは、レンジャーEBGとして機能する可能性があります。
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内には、ATN内の自律システムまたはインターネットとして内部で編成されている多くの航空通信サービスプロバイダー（ACSP）および航空ナビゲーションサービスプロバイダー（ANSP）ネットワークがあります。それ自体が、地域、組織、または機能的なコンパートメントとして編成された低層のエンタープライズネットワークにさらに内部的に細分化される可能性があります。ATN内のACSPとANSPは、民間航空サービスのための飛行の安全性の共通の目的を共有するが、エンタープライズネットワークは、コンポーネントが明確なお尻であることを必要とする競合するビジネス、社会、または政治的利益を持っている可能性があることに注意することが重要です。
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.
したがって、レンジャーの原則は、非常に多様なローカルポリシーの区別を可能にしながら、共同の目標をサポートしています。このように、お互いを信頼していないエンティティは、共通の目標を達成するために共同インフラストラクチャを作成できます。
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.
このような運用協会は、米国国防総省のグローバル情報グリッド（ギグ）を含む多くの将来の展開を特徴付けます。特に、すべてのエンタープライズネットワークのルーティングとアドレス指定の取り決めには、特定のレベル、スケーリングの問題、セキュリティポリシーの違い、自由市場の力、組織の違い、政治的違い、またはその他の要因で相互の協力的な管理が必要ですが、内部競争が生じる場合があります。そうでなければ共通の目標を共有するエンティティの中で。これには、その協会内の異なるエンタープライズネットワークが、独自の機能的なインターネット関係内にリンクされている明確なロバに分離する必要があります。
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を参照）、安全で効率的な空の旅を提供するために協力する多くの政府および民間企業にサービスを提供します。レンジャーでこれらのニーズを満たす可能性のある方法の1つは、図14に示すように、インターネット上のIP-in-IPトンネルを使用してオーバーレイを作成することです。Aeroオーバーレイはエンタープライズネットワークを形成し、ACSPからの内部パケットとANSPエッジネットワークを形成します。EBR上の獣医インターフェイス間の移動インターネットを横切る通過は、1つのホップのみとして表示されます。
_...--------------------------------------..._
/ \
( 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は、ACSPとANSP EBRSが中間EBRでの検索や再カプセル化をさらにマッピングすることなくトラフィックをルーティングできる調整されたグローバルスコープRLOCアドレススペースを使用して、エッジネットワークの完全なルーティング情報を交換することを選択する場合があります。共通の親として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は、OSIネットワークをIPv4（またはIPv6）インターネットを介して橋渡しするか、OSIネットワーク全体でIPv4またはIPv6ネットワークをブリッジすることができます。共通エンタープライズネットワークにIPインターフェイスを持つEBRのペア（インターネット、Aeroネットワーク、または他の親または子エンタープライズネットワークなど）は、ISOネットワークサービスアクセスポイントを検索することにより、添付のOSIエッジネットワーク間の通信をサポートできます（NSAP）RLOCマッピングのIPアドレスの代わりに[IS8348]アドレス。したがって、OSI Connectionless Network Protocol（CLNP）[IS8473]パケットは、インターネットプロトコルエンタープライズネットワークを介した送信用のIPv4（またはIPv6）ヘッダー内でカプセル化できます。一部のOSIネットワークは、[RFC4548]にアドレス指定するIPv6に移行する場合がありますが、アプリケーションはRFC 2126 [RFC2126]を使用してTCP/IPを超えてOSI上層を運ぶことで適応します。別のアプローチは、サブネットワークの収束を使用して、インターネットプロトコルネットワーク[RFC1070]を介したOSIネットワークプロトコルデータユニットをトンネルに使用することです。
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 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.
図15は、IPv4 Aeroオーバーレイを介して接続されたACSPとANSPを示しています。ホストHは、ACSPエンタープライズネットワーク内のEBR Fのエンタープライズエッジネットワークインターフェイスを介して接続されたACSPへのワイヤレスリンクを持つ航空機のオンボードシステムを表します。HはIPv6エッジネットワークに存在し、そのEIDはACSP IPv6プレフィックスから取得されます。Hは、ANSPエンタープライズネットワークのサーバーSにクエリを送信する必要があります。hはGでDNSクエリをサーバーに送信することから始め、その見返りにサーバーSのEidを受信し、Source Eid（H）と宛先Eid（S）を使用してIPv6パケットを作成し、デフォルトのルーターに転送します。F. Fは、EID（S）から適切なRLOCへのマッピングについてGを参照します。この場合、EBR FはIPv6アウターパケットのIPv6パケットをカプセル化し、パケットをデフォルトのEBG A.に転送します。Aはパケットを脱カプセル化し、EBR BのDNSサーバーをクエリすることにより宛先EID（S）を検索します。EBR EのRLOCを使用したマッピングA Aは、ソースRLOC（A）と宛先RLOC（E）を備えたIPv4外側パケットのIPv6内側パケットをカプセル化します。パケットは、エアロオーバーレイでEBRS CおよびDを介して転送され、Eが脱カプセル化されているEに達するまで転送されます。EはEID/RLOCマッピングのキャッシュを相談し、SのEBRがNであることがわかります。Sソース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] /
\...__________________________...
Figure 15. Packet Forwarding for Aeronautical Networks
図15.航空ネットワークのパケット転送
"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]は、GATEWAYを介してISPネットワークに接続されたIPv6対応ルーターとENDシステムをサポートするための4つのケースを考慮します。
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ボックスを使用してサービスプロバイダーに接続する顧客ネットワークの広範な慣行によって代表されます。レンジャーはこのシナリオに直接対処していません。ただし、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のみのルーターとエンドシステムが含まれている場合、レンジャーカプセル化メカニズムが適用されます。
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ルーターになります。その場合、ゲートウェイはレンジャーEBRになる可能性があり、シナリオはセクション4.3で説明したSOHOネットワークユースケースと同じになります。特に、従来のホームネットワークIPv4 NATボックスがIPv6ルーティングもサポートするように更新されると、NATボックスはレンジャーEBRになります。
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で説明されています。これらには、アプリケーショントラフィックへのマッピングシステムの効果、マッピングシステムを保護する必要性、MTUエフェクト、およびレガシーインターネットネットワークがレンジャーを使用している人に接続する能力が含まれます。
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インターネットの将来の成長を綿密に調査していません。たとえば、数百万人の顧客を同時にサポートする現在の主要なインターネットサービス（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 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.
これらの要件では、インターネットルーティングのスケーリングに悪影響を与えることなく、RangerとIPv6およびIPv4ネイティブインターネットルーティングシステムの両方と互換性のあるオーバーレイネットワークソリューションが必要です。ソリューションは、[RFC5720]のセクション3.7で説明したマッピングとカプセル化の懸念を回避する必要があります。たとえば、初期パケットに容認できない遅延を伝えることなく、一般的に最短のパスルーティングを提供する必要があります。このソリューションは、システムを終了するために変更を必要とせずに、ルートの最適化を活用できるモバイルエンドユーザーネットワークにモビリティ管理機能をさらに提供する必要があります。最後に、ソリューションは、エンドユーザーネットワークが交通工学とフォールトトレランスをサポートして、複数のISPからインターネットアクセスサービスを同時に取得できるようにするビジネスモデルに基づいている必要があります。
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アドレス空間からRLOCSとしてアドレス指定され、巨大なエンタープライズネットワークと見なすことができます。ただし、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.
レンジャーは、ネットワーク（またはエンタープライズ - エンテルプライズ）フレームワークの真のネットワークを有効にします。これは、ここで文書化されている幅広い展開シナリオにも当てはまります。また、任意の深さに再帰的にネストされる可能性のあるネットワークのネットワークでも当てはまります。したがって、レンジャーは、相互に互換性がある場合と互換性がある場合とそうでない場合があるポイントソリューションの混合袋ではなく、すべての再帰層に一貫して適用される統一アーキテクチャをもたらします。IPv6およびIPv4ネイティブインターネットルーティングシステムとの共存をサポートするオーバーレイネットワークソリューションと組み合わせると、統一された将来のインターネットアーキテクチャが可能です。
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]で対処されています。レンジャーアーキテクチャ自体はセキュリティに関する考慮事項に対処していませんが、機能的な仕様の構造フレームワークを提案しています。トンネリングに関するセキュリティの懸念と、レンジャーアーキテクチャと互換性のある推奨事項は、[トンネル-SEC]にあります。特定のユースケースのセキュリティ上の考慮事項について説明します。
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.
この作品は、実際のインターネット展開から多くのピアによって「学んだ教訓」とカプセル化プロトコルの開発の経験から「学んだ教訓」で補われたインターネットの元のアーキテクチャの原則に触発されました。編集者は、彼らが多くの人によって開始された作業を促進していることを認めています。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 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。、「グローバルエンタープライズリクルシオン（レンジャー）を備えたネットワークでのルーティングとアドレス指定」、RFC 5720、2010年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：A Practical Transit Mapping Service」、2007年11月の作業。
[BEHAVE-v6v4] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", Work in Progress, August 2010.
[beave-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.
[Bell-Lapadula] Bell、D。およびL. Lapadula、「安全なコンピューターシステム：数学的基礎とモデル」、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 Customer Edge Routersの基本要件」、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、「Virtual AggregationによるFIB抑制」、2010年8月の作業。
[HUSTON-END] Huston, G., "The End of the (IPv4) World is Nigher!", July 2007.
[Huston-end] Huston、G。、「（IPv4）世界の終わりはNigher！」、2007年7月。
[IEN48] Cerf, V., "The Catenet Model for Internetworking", July 1978.
[IEN48] Cerf、V。、「インターネットワークのカテネットモデル」、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]国際標準化機関、国際電気技術委員会、「Connectionless-Mode Network Service：Protocol Specificationを提供するためのプロトコル」、1998。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, March 2009.
[lisp] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator/ID Separation Protocol（LISP）」、2009年3月、Work in Progress。
[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審議」、RFC 1380、1992年11月。
[RFC1753] Chiappa, N., "IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture", RFC 1753, December 1994.
[RFC1753] Chiappa、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、「Private Internetsのアドレス割り当て」、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のインターネットルーティングとアドレス指定（capp）の新しいスキーム」、RFC 1955、1996年6月。
[RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top of TCP (ITOT)", RFC 2126, March 1997.
[RFC2126] Pouffary、Y。およびA. Young、「TCPの上にあるISO輸送サービス（ITOT）」、RFC 2126、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年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、「Bump-in-the-Stack」テクニック（BIS）を使用したデュアルスタックホスト、RFC 2767、2000年2月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]カーペンター、B。、「インターネット透明性」、RFC 2775、2000年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 3194、2001年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のダイナミックホスト構成プロトコル」、RFC 3315、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 3775、2004年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 4029、2005年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 Enterprise Networkシナリオ」、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 4192、2005年9月。
[RFC4215] Wiljakka, J., Ed., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[RFC4215] Wiljakka、J.、ed。、「第3世代パートナーシッププロジェクト（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。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年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 4380、2006年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、「Link-Local Multicast Name Resolution（LLMNR）」、RFC 4795、2007年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 4852、2007年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 Stateless Address Autoconfiguration」、RFC 4862、2007年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 5214、2008年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。、「Virtual Enterprise Traversal（VET）」、RFC 5558、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、「Tunnel Setup Protocol（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、「Nemumberingまだ仕事が必要」、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 5944、2010年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.
[Step] Savola、P。、「Simple IPv6-in-IPV4トンネル設立手順（STEP）」、2004年1月の作業。
[TUNNEL-SEC] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns With IP Tunneling", Work in Progress, October 2010.
[トンネルセック]クリシュナン、S。、ターラー、D。、およびJ.ホーグランド、「IPトンネリングに関するセキュリティ上の懸念」、2010年10月の進行中。
Authors' Addresses
著者のアドレス
Steven W. Russert (editor) 1078 Ridge Crest Dr. Wenatchee, WA 98801 USA
スティーブン・W・ラッサート（編集者）1078リッジクレスト博士ウェナチー、ワシントン州98801 USA
EMail: russerts@hotmail.com
Eric W. Fleischman (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
エリック・W・フライシュマン（編集者）ボーイング・リサーチ・テクノロジーP.O.ボックス3707 MC 7L-49シアトル、ワシントン州98124 USA
EMail: eric.fleischman@boeing.com
Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
フレッドL.テンプリン（編集者）ボーイングリサーチ＆テクノロジーP.O.ボックス3707 MC 7L-49シアトル、ワシントン州98124 USA
EMail: fltemplin@acm.org