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）「グローバルエンタープライズ再帰（レンジャー）とネットワークにおけるルーティングおよびアドレス指定は、」スケーラブルなルーティングおよびアドレス指定のためのアーキテクチャフレームワークを提供します。それは、スケーラビリティ、プロバイダ独立性、モビリティ、マルチホーミング、トラフィックエンジニアリング、およびセキュリティのため、増分展開可能なアプローチを提供します。この文書では、アーキテクチャの機能を紹介するために、ユースケースのシリーズを記述しています。さらに、RANGERアーキテクチャは、もともとインターネットの持続的な成長のために意図され、ネットワーク内のネットワークの原則を復元する方法を示しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6139.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6139で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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]の展開を。グローバルエンタープライズ再帰（レンジャー）[RFC5720]を有するネットワークにおけるルーティングおよびアドレス指定は、他の二つのアプローチを容易にする「地図とカプセル化」アプローチの建築要素を記述する。この文書では、RANGER動作シナリオについて説明します。
RANGER provides an architectural framework for scalable routing and addressing. It provides for scalability, provider independence, mobility, multihoming, and security for the next-generation Internet. The RANGER architectural principles are not new. They can be traced to the deliberations of the ROAD group [RFC1380], and also to still earlier works including NIMROD [RFC1753] and the Catenet model for internetworking [CATENET] [IEN48] [RFC2775]. [RFC1955] captures the high-level architectural aspects of the ROAD group deliberations in a "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG".
レンジャーは、スケーラブルなルーティングおよびアドレス指定のためのアーキテクチャフレームワークを提供します。これは、次世代インターネットのためのスケーラビリティ、プロバイダ独立性、モビリティ、マルチホーミング、セキュリティのために用意されています。 RANGER建築原則は新しいものではありません。彼らはROADグループ[RFC1380]の審議にさかのぼることができ、また、まだ以前のNIMROD [RFC1753]と[CATENET] [IEN48] [RFC2775]をインターネットワーキングのためのCATENETモデルを含む動作しますし。 [RFC1955]は、「IPNGのためのインターネットルーティングおよびアドレッシング（ENCAPS）のための新しいスキーム」のROADグループの審議の高レベルのアーキテクチャの側面をキャプチャします。
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）アドレス空間を使用することができます。 RANGER仮想オーバーレイは、伝統的な管理と組織の境界を超越することができます。その純粋な形で、このオーバレイネットワークは、従って、インターネット全体に及ぶと[RFC2775]で想定されるエンドツーエンドの透過性を回復し得ます。
The RANGER architecture drew early observations from the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] [RFC5579] but now uses Virtual Enterprise Traversal (VET) [RFC5558], the Subnetwork
RANGERアーキテクチャは、プロトコル（ISATAP）[RFC5214] [RFC5579]をアドレス指定、サイト内の自動トンネルからの早期観測を描きましたが、現在は仮想エンタープライズトラバーサル（VET）[RFC5558]、サブネットワークを使用しています
Encapsulation and Adaptation Layer (SEAL) [RFC5320], and other mechanisms including IPsec [RFC4301] as its functional building blocks. This document describes use cases and shows how the RANGER mechanisms apply. Complementary mechanisms (e.g., DNS, DHCP, NAT, etc.) are included to show how the various pieces can work together. It expands on the concepts introduced in "IPv6 Enterprise Network Scenarios" [RFC4057] and "IPv6 Enterprise Network Analysis - IP Layer 3 Focus" [RFC4852], and shows how the enterprise network model generalizes to a broad range of scenarios. These use cases are included to provide examples, invite criticism and comment, and explore the potential for creating the next-generation Internet using the RANGER architecture. Familiarity with RANGER, VET, SEAL, and ISATAP are assumed.
カプセル及びアダプテーションレイヤ（SEAL）[RFC5320]、およびその機能的ビルディングブロックとしてのIPsec [RFC4301]などの他の機構。この文書では、ユースケースを説明し、RANGERメカニズムがどのように適用されるかを示しています。相補的機構（例えば、DNSは、DHCP、NAT、等）は、様々な部分が一緒に働くことができる方法を示すために含まれます。これは、「IPv6のエンタープライズネットワークシナリオ」[RFC4057]および「IPv6のエンタープライズネットワーク解析 - IPレイヤ3つのフォーカス」で導入された概念を拡張[RFC4852]、および企業ネットワークモデルはシナリオの幅広いに一般化する方法を示しています。これらのユースケースは、例を提供して批判してコメントを招待し、RANGERアーキテクチャを用いた次世代のインターネットを作成するための可能性を探るために含まれています。 RANGER、VET、SEAL、および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のパブリックアドレス空間今日は、巨大な「エンタープライズネットワーク」として、グローバルなインターネットのためのRLOC空間として考えることができます。
Endpoint Interface iDentifier (EID) an address assigned to an edge network interface of an end system. Note that EID space is global in scope, and must be separate and distinct from any RLOC space.
エンドポイントインターフェイス識別子（EID）エンドシステムのエッジネットワークインタフェースに割り当てられたアドレス。 EID空間スコープのグローバルであり、任意RLOC空間から分離した別個でなければならないことに留意されたいです。
commons an enterprise-interior routing region that provides a subnetwork for cooperative peering between the border routers of diverse organizations that may have competing interests. An example of a commons is the Default-Free Zone (DFZ) of the global Internet. The enterprise-interior routing region within the commons uses an addressing plan taken from RLOC space.
コモンズ競合する利益を有していてもよく、多様な組織の境界ルータ間の協調的ピアリングのためのサブネットワークを提供し、企業内部ルーティング地域。コモンズの例は、グローバルなインターネットのデフォルトフリーゾーン（DFZ）です。コモンズ内の企業内部ルーティング領域はRLOC空間から取られたアドレス計画を使用します。
enterprise network the same as defined in [RFC4852], where the enterprise network deploys a unified RLOC space addressing plan within the commons, but may also contain partitions with disjoint RLOC spaces and/or organizational groupings that can be considered as enterprises unto themselves. An enterprise network therefore need not be "one big happy family", but instead provides a commons for the cooperative interconnection of diverse organizations that may have competing interests (e.g., such as the case within the global Internet Default-Free Zone).
企業ネットワークは、コモン内計画をアドレッシング統一RLOC空間を展開するだけでなく、それ自体かれ企業とみなすことができる互いに素RLOCスペースおよび/または組織のグループでパーティションを含んでいてもよい[RFC4852]で定義されている企業ネットワーク同じ。企業ネットワークは、したがって、「一つの大きな幸せな家族」である必要はなく、代わりに競合する利害を有していてもよく、多様な組織（例えば、グローバルなインターネットデフォルトフリーゾーン内ケースなど）の協力の相互接続のためのコモンズを提供します。
Historically, enterprise networks are associated with large corporations or academic campuses. However, in RANGER an enterprise network may exist at any IP Topology Hierarchy level. The RANGER architectural principles apply to any networked entity that has some degree of cooperative active management. This definition therefore extends to home networks, small office networks, a wide variety of Mobile Ad hoc Networks (MANETs), and even to the global Internet itself.
歴史的には、企業ネットワークは、大企業や学術キャンパスに関連しています。しかし、RANGERに企業ネットワークは、任意のIPトポロジの階層レベルで存在してもよいです。 RANGER建築の原則は、協同組合積極的な管理をある程度持っている任意のネットワークエンティティに適用されます。この定義は、したがって、ホームネットワーク、小規模オフィスネットワーク、アドホックネットワーク（MANET）の多種多様な、とさえ世界的なインターネット自体にも及びます。
site a logical and/or physical grouping of interfaces within an enterprise network commons, where the topology of the site is a proper subset of the topology of the enterprise network. A site may contain many interior sites, which may themselves contain many interior sites in a recursive fashion.
サイトサイトのトポロジーは、企業ネットワークのトポロジーの適切なサブセットである企業ネットワーク内のコモンインターフェースの論理的及び/又は物理的なグループ化。サイト自体は、再帰的な方法で多くの内部部位を含む可能性がある、多くの内部部位を含有してもよいです。
Throughout the remainder of this document, the term "enterprise" refers to either enterprise or site; i.e., the RANGER principles apply equally to enterprises and sites of any size or shape. At the lowest level of recursive decomposition, a singleton Enterprise Border Router can be considered as an enterprise unto itself.
この文書の残りの部分全体を通して、用語「企業」とは、企業またはサイトのいずれかを指します。即ち、レンジャー原理は、企業や任意のサイズまたは形状の部位に等しく適用されます。再帰的な分解の最下位レベルでは、シングルトンエンタープライズ境界ルータは、それ自体が企業として考えることができます。
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は、オーバーレイネットワークへの直接接続されたネットワークを接続し、他のEBRsにコモン間でIP内IPトンネリングを経由して他のネットワークに接続します。この定義は、[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]).
企業ボーダーゲートウェイ（EBG）もプロバイダーネットワークおよび/またはグローバルインターネットに企業ネットワークに接続するEBR。 EBGsは、一般的に、オーバーレイのデフォルトルータとして構成されており、コモンズ内の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）[RFC5214]、[RFC5579]をアドレッシングISATAPイントラサイト自動トンネル。ユニキャストのみの企業ネットワークを介して自動トンネリングのための機能仕様と運用実践。
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仮想エンタープライズトラバーサル（VET）[RFC5558]。機能仕様と6over4はISATAPとの機能的なスーパーセットを提供し運用方法。ユニキャストとマルチキャストトンネリングの両方に加えて、VETは、アドレス/プレフィックスの自動設定などなどのIPsec、SEAL、UDP、などの追加のカプセル化をサポートしています
SEAL Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320]; a functional specification for robust packet identification and link MTU adaptation over tunnels. SEAL supports effective ingress filtering and adapts to subnetworks configured over links with diverse characteristics.
SEALサブネットワークカプセル化及びアダプテーションレイヤ（SEAL）[RFC5320]。トンネルを介し堅牢なパケット識別とリンクMTUの適応のための機能仕様。シールは、効果的なイングレスフィルタリングをサポートし、多様な特性を持つリンク上で構成されたサブネットワークに適応します。
Within the RANGER architectural context, the SEAL "subnetwork" and RANGER "enterprise" should be considered as identical abstractions.
RANGER建築コンテキスト内で、SEAL「サブネットワーク」とRANGER「企業」は、同一の抽象化と考えるべきです。
Provider-Independent (PI) prefix an EID prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) that is routable within a limited scope and may also appear in enterprise network mapping tables. PI prefixes that can appear in mapping tables are typically delegated to a BR by a registry, but are not aggregated by a provider network.
プロバイダ非依存（PI）EIDプレフィックスをプレフィックス（例えば、2001：DB8 :: / 48、192.0.2 / 24など）限られた範囲内でルーティング可能であり、また企業ネットワーク・マッピング・テーブルに表示されてもよいです。マッピングテーブルに表示できるPIプレフィックスは、通常はレジストリによってBRに委任されているが、プロバイダーネットワークによって集約されていません。
Provider-Aggregated (PA) prefix an EID prefix that is either derived from a PI prefix or delegated directly to a provider network by a registry. Although not widely discussed, it bears specific mention that a prefix taken from a delegating router's PI space becomes a PA prefix from the perspective of the requesting router.
プロバイダ凝集（PA）は、いずれかのPIプレフィックス由来またはレジストリで、プロバイダのネットワークに直接委任されたEIDプレフィクスを付けます。広く議論されていないが、それが委任するルータのPI空間から撮影したプレフィックスが要求ルータの観点からPAの接頭辞になるという具体的な言及を負いません。
Customer Premises Equipment (CPE) Router a residential or small office router that provides IPv4 and/or IPv6 support. The user or the service provider may manage the router.
顧客宅内機器（CPE）ルータのIPv4および/またはIPv6サポートを提供し、住宅や小規模オフィスのルータ。ユーザーまたはサービスプロバイダは、ルータを管理することができます。
Carrier-Grade NAT (CGN) a special (usually high capacity) IPv4-to-IPv4 NAT deployed within the service provider network that serves multiple subnets.
キャリアグレードNAT（CGN）特別な（通常、高容量）のIPv4対IPv4のNATは、複数のサブネットに役立つサービスプロバイダネットワーク内に展開。
The RANGER [RFC5720] architecture seeks to fulfill the objectives set forth in [RFC1955]:
RANGER [RFC5720]アーキテクチャは、[RFC1955]に記載された目標を達成しよう：
o No Changes to Hosts
ホストへの変更なしO
o No Changes to Most Routers
ほとんどのルータへの変更なしO
o No New Routing Protocols
O新たなルーティングプロトコル
o No New Internet Protocols
O新たなインターネットプロトコル
o No Translation of Addresses in Packets
パケット内のアドレスのない翻訳O
o Reduce the Routing Table Size in All Routers
Oすべてのルータでルーティングテーブルのサイズを小さく
o Use the Current Internet Address Structure
O現在のインターネットのアドレス構造を使用します
The RANGER enterprise network is a cooperative networked collective sharing a common (business, social, political, etc.) goal. An enterprise network can be simple or complex in composition and can operate at any IP Topology Hierarchy level. Although RANGER focuses on encapsulation, it is also compatible with both native and translated routing and addressing.
RANGERの企業ネットワークでは、ネットワークの協力、集団の共有、共通の（ビジネス、社会的、政治的、など）のゴールです。企業ネットワークは、組成物中の単純または複雑であることができ、任意のIPトポロジの階層レベルで動作することができます。 RANGERカプセル化に焦点を当てているが、それはまた、天然および翻訳ルーティング及びアドレッシングの両方と互換性があります。
RANGER enables a protocol and/or addressing system to be connected in a virtual overlay across an untrusted transit network, or "commons". While it does not show all possible uses, Figure 1 illustrates that RANGER supports the creation of a distributed network across an intervening commons, which could implement a dissimilar IP version, routing protocol, or addressing system.
レンジャーは、仮想信頼できないトランジットネットワーク上オーバーレイ、または「コモン」に接続するプロトコルおよび/またはアドレス方式を可能にします。それはすべての可能な使用法を示していないが、図1は、RANGERは、異なるIPバージョン、ルーティングプロトコル、または対処するシステムを実装することができ介在コモンズ、全体で分散ネットワークの作成をサポートしていることを示しています。
.--------------. .--------------. .-------------.
/ \_ _/ \_ _/ \
\ Enterprise A / \ Commons / \ Enterprise B /
\_ _ _ _ _ _ _ / \_ _ _ _ _ _ _ / \_ _ _ _ _ _ _/
Domains
Network / IPvx IPvy IPvz Protocol \ IPv6 IPv4 IPv6
ネットワーク/ IPvx IPvy IPvzプロトコル\ IPv6のIPv4からIPv6
IP Security secured unsecured secured
IPセキュリティを確保し、無担保確保しました
Mgmt Domain Entity A ISP Entity B
MGMTドメインエンティティA ISPエンティティB
/ | Public Addresses Private Addresses Public Addresses Addressing |Private Addresses Public Addresses Private Addresses | PA Addresses PI Addresses PA Addresses \ PI Addresses PA Addresses PI Addresses
/ |パブリックアドレスプライベートアドレスパブリックアドレスアドレッシング|プライベートアドレスの公開は、プライベートアドレスをアドレス| PAはPAが\ PIは、PAはPIアドレスをアドレスアドレスアドレスPIアドレスのアドレス
Figure 1. RANGER Links Distributed Enterprise Networks
図1. RANGERリンクは、企業ネットワークを分散します
The RANGER concepts can be applied recursively. They can be implemented at any level within the IP Topology Hierarchy to create an enterprise-within-enterprise organizational structure extending traditional AS, area, or subnetwork boundaries. This structure uses border routers that configure tunnel endpoints to enable communications between potentially recursively nested enterprise networks in a virtual overlay network that transcends traditional administrative and organizational boundaries. In its purest form, this overlay network could therefore span the entire Internet and restore end-to-end transparency [RFC2775].
RANGERの概念を再帰的に適用することができます。彼らは伝統的なAS、エリア、またはサブネットワークの境界を拡張し、企業内・企業の組織構造を作成するために、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]機能仕様されているようRANGERアーキテクチャは、前のカプセル化システムから現在のベストプラクティスの洞察を適用します。結果は、ユニキャストおよびマルチキャストルーティングおよびアドレス指定システムの両方をサポートする任意の複雑な、スケーラブルな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は、それ自体が企業ネットワークと見なすことができます。従来のネットワークインフラストラクチャは、単に任意のネットワークエンティティへの他の修飾を有するEBRsを添加した複雑な構造をサポートするように拡張することができます。
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つまたは複数の企業ネットワークへのネットワークとエンドシステムを接続します。エンタープライズ内部インターフェイスは、コモンズに接続します。プロバイダエッジインターフェイスは、IPトポロジの階層アップ従来のルーティング関係をサポートし、エンタープライズエッジインターフェイスは、IPトポロジの階層ダウン伝統的な関係をサポートします。内部の仮想インターフェイスは、典型的には、ループバックインターフェースやVMwareのようなホストにホストインターフェイスです。
VET interfaces support RANGER recursion and IP-in-IP encapsulation. VET interfaces are configured over provider-edge, enterprise-interior, or enterprise-edge interfaces to allow recursion horizontally or vertically within the IP Topology Hierarchy. A VET interface may be configured over several underlying interfaces that all connect to the same enterprise network. This creates a link-layer multiplexing capability that can provide several advantages (see [RFC1122], Section 3.3.4). One important advantage is continuous operation across failovers between multiple links attached to the same enterprise network, without any need for readdressing.
VETインタフェースはRANGER再帰とIP-in-IPカプセル化をサポートしています。 VETインタフェースはIPトポロジの階層内の水平方向または垂直方向に再帰を可能にするために、プロバイダエッジ、企業内部、またはエンタープライズエッジインターフェイス上に構成されています。 VETインタフェースはすべて同じ企業ネットワークに接続するいくつかの根本的なインターフェイス上に構成されてもよいです。これはいくつかの利点を提供することができるリンク層の多重化機能を作成する（[RFC1122]セクション3.3.4を参照）。 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（iEBR）は右企業ネットワーク内の出口EBR（eEBR）にコモン横切ってカプセル化されたパケットを転送しようとするものです。
The figure shows that the eEBR assigns a Routing Locator (RLOC) address on its interface to the commons' interior IP routing and address space, while the destination host assigns an Endpoint Interface iDentifier (EID) on its enterprise-edge interface. The iEBR uses a mapping system to discover the RLOC of an eEBR on the path to the destination EID address. A distinct mapping system is maintained within each recursively nested enterprise network instance operating at a specific level of the IP Topology Hierarchy. RANGER uses the mapping system to join peer enterprise networks via a virtual overlay across a commons.
図は、宛先ホストがその企業エッジインターフェイス上のエンドポイント・インタフェース識別子（EID）を割り当てながらeEBRは、コモンズの内部IPルーティングおよびアドレス空間へのそのインタフェース上のルーティングロケータ（RLOC）アドレスを割り当てていることを示しています。 iEBR宛先EIDアドレスへの経路上eEBRのRLOCを発見するマッピングシステムを使用します。別個のマッピング・システムは、IPトポロジの階層の特定のレベルで動作し、各再帰的にネストされた企業ネットワーク・インスタンス内に維持されます。レンジャーコモンズ横切る仮想オーバーレイを介してピア企業ネットワークに参加するマッピングシステムを使用します。
Mapping System RLOC EID
. (BGP, DNS, etc.) . .
.---.------. .----------. . .------.---.
/ . \ / \ . / . \
/ (O) iEBR------/--------------\------eEBR * \
\ / \ Commons / \ /
\_ _ _ _ _ _ / \_ _ _ _ _ _ / \_ _ _ _ _ _/
Enterprise Network A Enterprise Network B
エンタープライズネットワークA企業ネットワークB
Figure 3. The RANGER Model
図3. RANGERモデル
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.
EBRsはRLOCとEIDアドレスおよび/またはプレフィックスの両方を設定する必要があります。自動設定は、VETに指定されているように、再帰的な階層で次に高い層に接続するエンタープライズボーダーゲートウェイ（EBGs）と調整されます。 DHCP [RFC2131]、[RFC3315]とステートレスアドレス自動設定（SLAAC）[RFC4862]などの標準的なメカニズムは、この目的のために使用されます。
Similarly, EBRs require a means to discover other EBRs and EBGs that can be used as enterprise network exit points. VET specifies mechanisms for border router discovery using the global DNS and/or enterprise-local name services such as Link-Local Multicast Name Resolution (LLMNR) [RFC4795].
同様に、EBRsは、企業ネットワーク出口ポイントとして使用することができる他のEBRsとEBGsを発見するための手段を必要とします。 VETは、リンクローカルマルチキャスト名前解決（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.
マッピング・システムは、マッピングエージェントの限られたセット間で同期される分散データベースです。データベースの同期は、多くの異なるプロトコルの代替手段によって達成することができます。最も一般的に使用される選択肢は、いずれかのボーダーゲートウェイプロトコル（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）を移入するために使用できるマッピング応答を受信します。その後eEBRのリモートRLOCアドレスにコモン横切って伝送するための外側IPヘッダ内の各転送パケットをカプセル化します。順番にeEBRは、パケットをデカプセル化し、宛先EIDアドレスに転送します。コモンズ内のルーティング情報ベース（RIB）が唯一のRLOCとないのEIDに関する状態を維持する必要があります。同期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-PROB-STATE]のために認識されているルーティングおよびアドレッシングで課題を作成しました。 IPv4の[RFC0791]アドレス空間は限られており、地域インターネットレジストリ（RIR）割り当ては、86％の「非常に痛い」ホスト密度（HD）比閾値（すなわち、192Mがアドレスを割り当てられる）[RFC3194]を通過します。結果として、IPv4アドレスプールの枯渇は、[IPv4POOL]、[HUSTON-END]次の2年以内に予測されます。 IPv6は、はるかに大きなアドレス空間にアドレス不足を解決することを約束しますが、移行はコストがかかり、下記のBGPの問題を悪化させる可能性があります。豊かな相互接続、（特にプロバイダに依存しない（PI）アドレスを持つ）増加マルチホーミング、およびルーティングのより細かい制御を経由してトラフィックエンジニアリングをサポートしたいという願望は、デフォルト・フリーゾーン、または「DFZでBGPルーティングテーブルの超線形成長につながっています」インターネットの。この成長は、現在のインターネットルーティングフレームワーク内で長期のために持続不可能ですルータの能力と技術コストの増加圧力をかけています。
RANGER allows the coordinated reuse of addresses from enterprise to enterprise by making RLOC address spaces independent of one another. Figure 4 shows how the RANGER architecture allows the use of separate address spaces for RLOC and EID addressing in the Internet. This yields more endpoint address space, especially with the use of IPv6, and also reduces the load on BGP in the Internet routing core. Note that Figure 4 could represent variants of RFC 4057 scenarios 1 and 2.
RANGERは、互いに独立しRLOCアドレス空間を作ることによって、企業への企業からのアドレスの協調再利用することができます。図4は、レンジャーアーキテクチャはインターネットにアドレッシング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のいずれかから取り出すことができます。 （ネットワークアドレス変換（NAT）の使用を禁止する）EIDアドレスは、グローバルに一意な場合であっても、ルーティング可能な唯一のより限定された範囲内（例えば、自分自身のエッジネットワークで）。
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]、「仮想集約とFIBの抑制」[-VAをGROW]、「ロケータ/ ID分離プロトコル（：レンジャー「実践トランジットマッピングサービスAPT」を含む、ルーティングスケーリング問題に対処することを意図方式の数とさらに互換性があります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]を必要としている企業ネットワーク。 RANGERは、スケーラビリティ、プロバイダ独立性、モビリティ、マルチホーミング、セキュリティを完全にサポートして、対処する計画と企業間のルーティングを調整する方法を提供します。
_.--------------------._
_.---'' -.
,--'' ,---. `---.
,-' X5 X6 .---.. `-.
,\' ,.X1-.. / \ ,' `. `.
,\' ,' `. .' E2 '. X8 Em \ `.
/ / \ | ,--. | / _,.._ \ \
/ / E1 \ | Y3 `. | | / Y7 | \
; | ___ | | ` W Y4 |... | `Y6 ,' | :
| | ,-' `. X2 | `--' | | `'' | |
: | | V Y2 | \ _ / | | ;
\ | `-Y1,,' | \ .' Y5 / \ ,-Y8'`- / /
\ \ / \ \_' / X9 `. ,'/ /
`. \ X3 `.__,,' `._ Y9'',' ,'
` `._ _,' ___.......X7_ `---' ,'
` `---' ,-' `-. -'
`---. `. E3 Z _' _.--'
`-----. \---.......---' _.---''
`----------------''
<------------------- 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は、EMを介してE1エンタープライズ境界ルータを介してグローバルIPv4インターネット（EBRs）X9を介してX1に接続された企業ネットワークを示しています。これらの同じ境界ノードはまた、それぞれの企業ネットワーク内のノードのデフォルトのルーティングサービスを提供エンタープライズボーダーゲートウェイ（EBGs）として機能します。グローバルなインターネットは、さまざまな企業ネットワークは、まだ潜在的に競合するエンティティを協力して接続する渡っコモンズを形成しています。各企業ネットワーク内でその企業のネットワークのRLOC空間から採取アドレス及び（グローバルスコープ）EIDアドレスとカプセル化されていないIPでカプセル化の両方の上にIPパケットを使用して任意の数のホスト、ルータ、ネットワーク（図示せず）があってもよいです（エンタープライズ・ローカル）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
各企業ネットワークは、下位層のネットワークを包含してもよいです。例えば、ネットワークE2におけるシングルトンEBR「W」は、それ自体が企業として考えることができる（その取り付けられたデバイスのいずれかと一緒に）低階層ネットワーク（E2.1を言う）に存在し、そして。 Wは、順番に（この場合は、インターネットには）一般的なプロバイダネットワークに接続EBGsとしてX5とX6を参照してくださいEBGs、とY3及びY4を見ています。各企業ネットワークは、エッジネットワーク上のノードをアドレス指定するために使用される1つ以上のエンドポイント・インタフェース識別子（EID）アドレスプレフィックスを有します。 RANGERのマップ・アンド・ENCAPSアプローチは、EBRルータインターフェイスに割り当てられているインターネット・コモンズでルーティング情報ベース（RIB）からルーティングロケータ（のRLOC）へのEIDのマッピングを分離します。だけでなく
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.
インターネットコモンズでBGPはインターネットのみコモンズでのRLOCに関する状態を維持する必要がある、それはEBRsへの唯一のルートが必要なので、維持するために少数のユニークなルートを持っています。トラフィックエンジニアリングは、したがって、マッピング・データベースを経由して収容することができます。
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.
EBRsが一緒に企業ネットワークを接続するために配備されているとして、企業ネットワーク内の通常のルータは通常通り機能し、既存のインターネットインフラストラクチャおよびネットワークの独自のRLOCコモンズ渡って普通とカプセル化されたパケットの両方を提供し続けています。 RLOCアドレスにバインドレガシーのIPv4サービスは、EIDベースのサービスが展開されたとしても、サポートされ続けています。レガシーIPクライアントとサーバーが同じRLOCアドレス空間内にある場合、それらは単に企業ネットワークコモンズ全体にRLOCベースのルーティングを使用して通信します。クライアントとサーバが同じRLOCアドレス空間内にない場合は、（詳細はセクション3.3.4を[RFC5720]を参照）、ネットワークアドレスおよび/またはプロトコル変換のいくつかのフォームを介して通信します。様々な企業のネットワークから他のEBRsはEIDプレフィクスを果たす一つ以上EBRsのRLOCアドレスを受信するためのマッピングシステムに相談することができるように様々な企業ネットワークからEBRsは、企業固有のマッピングシステムへのEIDプレフィクスを公開します。
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はそれ自身のソースアドレスと外部IPパケットにパケットをカプセル化EBRのY4にパケットを送信しますそして宛先としてネクストホップEBRのRLOCアドレス - この場合、X6。 X6は、パケットのカプセル化を解除し、ネクストホップとしてX7のRLOCを取得し、先のEIDプレフィクスを検索します。 X6は、宛先としてソースおよびX7としてRLOCアドレスX6とパケットに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).
この例では、RANGERを使用可能であることは多くのうち1つのスレッドを使用します。他のオプションや詳細については、[RFC5720]と[RFC5558]を参照してください。 （例えば、4.3節を参照）は、本日、その境界ルータでプロキシやファイアウォールを使用する多くの企業ネットワークは、企業の枠を超える、そのコントロールを維持することを望むだろう、とRANGERの使用は、このような構成を排除するものではありません。
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）内のRIBを維持BGPインスタンスから、多くの企業内部のASとの独立を結ぶ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).
このような企業体は、真のグローバルインターネットにつながる別のデフォルトルートとはいえ、内部的にそれ自体がインターネットです。それは伝統的なIPトポロジ階層としてであるかのように企業ネットワークE2は、したがって、インターネットの残りの部分に表示されます。 RANGERは再帰をサポートしているため、そのようなネットワーク内のASそれぞれは、それ自体が内部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、および天然にレンジャー技術の適用から利益を得る複雑な内部構造を含みます。しかし、（大と小の両方の）他の全ての企業ネットワークのインスタンスもRANGERによってサービス提供され得ます。例えば、小規模およびホームオフィス（SOHO）ネットワークは、単一のネットワークセグメント上のほんの数のコンピュータを含んでもよく、またはセキュリティアイランド、内部ルータやスイッチなどで大規模な構成に延びていてもよいです
An important concern of the small enterprise network is the ability to grow the network, change ISPs, or expand to more locations without readdressing the existing network. Consider a small company that has 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プレゼンスは、製品導入のアプローチとして必要とされます。ネットワーク管理者は、（図7に示されるように）既存のNAT /ファイアウォールプラットフォーム上で共存関数として、または別個のプラットフォーム上でEBRを展開します。
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に接続されたプロバイダエッジインターフェースを有しています。既存のワークステーション。ワークステーションを接続する既存のエンタープライズ・エッジ・インターフェース;ホストウェブサーバ、ワークステーション、およびその他のエンタープライズネットワークサービスルータによって接続された複数のネットワークセグメントを接続し、エンタープライズエッジインターフェイス。 VETインタフェースは、サーバは、パブリックインターネットから取り組むことができるように、新たなサービス・ネットワークを介して設定されています。
ISP
|
+------|-----+
| <|--
| VET2 < |
| <|---
| |
| | Server Server
| VET1 <|--------|-----------|-------
| |
| +--------+ | Wksta Wksta
| |Firewall| |_____________|____________|
| | NAT | |
| +--------+ |
+------------+
Figure 7. RANGER Serving the Small Company
中小企業にサービスを提供図7. RANGER
In this new configuration, the EBR maintains the services within a "demilitarized zone (DMZ)" that is accessible from the public Internet without exposing other corporate assets that are still protected by the preexisting firewall/NAT functions.
この新しい構成では、EBRは「非武装地帯（DMZ）」内のサービスを維持するには、まだ既存のファイアウォール/ NAT機能により保護されている他の企業の資産を公開することなく、公共のインターネットからアクセス可能です。
Shortly afterward, an infusion of venture capital allows acceleration of the product development and marketing work by adding programmers in Tokyo and sales offices in New York and London. These new branches connect via Virtual Private Network (VPN) links across the Internet, and a new VET interface (VET2) is configured over these links to form a new sub-enterprise:
その後まもなく、ベンチャーキャピタルの注入は、ニューヨーク、ロンドン、東京でプログラマや営業所を追加することで、製品開発とマーケティングの仕事を加速することができます。これらの新しい支店は、インターネット経由の仮想プライベートネットワーク（VPN）リンクを介して接続し、新しいVETインタフェース（VET2）は、新しいサブ企業を形成するために、これらのリンクの上に構成されています。
ISP
|
+------|-----+
| <|------------London
| VET2 < |
| <|--------------------New York
| |
| | Server Server
| VET1 <|--------|-----------|-------
| |
| +--------+ | Wksta Wksta
| |Firewall| |_____________|____________|
| | NAT | |
| +--------+ |
+------------+
Figure 8. RANGER for Multiple Locations
複数の場所については、図8 RANGER
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の両方のための長期的なサポートに対応する必要があります。 IPv6は、スタックデュアルスタック上のIPv4アプリケーション、およびIPv6デュアルスタックの両方の上のIPv6またはIPv4 / IPv6対応のアプリケーション上の遷移のための要件は、IPv4プロトコルスタック、IPv4アプリケーション上で動作するIPv4アプリケーションのためのサポートを含みます。カプセル化と翻訳の両方がありそうなアプリケーション、企業、プロバイダはグローバルコーディネートまたは「フラグの日」せずに、すべての中間状態を含め、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
レンジャーアーキテクチャは、既存のIPv4エンドシステムと（デュアルスタックを介して、すなわち、）ルータにIPv6アドレスの添加ならびにIPv4ネットワークの既存のセットにIPv6ネットワークの付加を容易にします。 （VETシール付き）レンジャーは、他のプロトコル又はルーティングシステムをサポートするネットワークインフラストラクチャ全体のプロトコルで発信パケットを伝送することができます。図1に示します
RANGER supports various combinations of edge (EID) and core (RLOC commons) technologies, going beyond IP version differences to include mixed security, management, and addressing as well.
RANGERは、混合セキュリティ、管理、および同様のアドレッシングを含めるようにIPのバージョンの違いを超えて行く、様々なエッジの組み合わせ（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」および「J」、「vet4」から「vet1」標識されたVETインタフェースによって張ら企業ネットワークの介在組によって分離され、ここで、「H」と "との間の経路、エンドシステムの対を示していますJは、 "V-> Y1-> X2-> X7-> Z」EBRパスを横切ります"：
+------+
| 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
IPv6を使用して図9 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）アドレス空間として使用され、IPv4が隣接EBRsの各対の間の経路上にホップ多くがあった場合も同様です。
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.
レンジャーは、さらに[RFC4472]からIPv6のプロトコル変換、[RFC4038]で説明したIPv4 / IPv6への移行のアプリケーション層の側面、及びDNSの問題を含む支持機構を組み込むための互換性のあるフレームワークを提供します。 < - > IPv6変換ネットワークベース[BEHAVE-v6v4]および/またはエンドシステムスタックベース（例えば、[RFC2767]）プロトコル変換システムを介してサポートされるIPv4アプリケーションが使用中のままインスタンスについて、RANGERは、IPv4がその期待します。プロトコル変換（NAT-PT）VETルータに換算翻訳、及び図11は、「バンプ・イン・スタック」エンドシステムにおける（BIS）換算翻訳（[RFC2767]）を示す - 図10は、NATを示しています。これらの例は、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パケットに変換しエンタープライズ境界ルータ（EBR）によって受信されます。 EBRは、EBRがバックに結果のIPv6パケットを変換するNAT-PT-同等の翻訳を使用したIPv4へのパケットをカプセル化し、サイト2のために彼らはEBRによって受信され、カプセル化が解除されているサイト2にRANGER対応のインターネットを介してそれらを送信しますエンドシステム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]）を示します。この場合、デュアルスタックエンドシステムA上のIPv4アプリケーションは、エンド・システムのプロトコルスタック自体内のIPv6パケットに変換されたIPv4ペイロードを形成します。 IPv6パケットは、次にによってカプセル化と消費のためにIPv4パケットを得、デカプセル化及びエンドシステムB上のBIS-同等のプロセスが翻訳を逆転のIPv4アプリケーションBをホストデュアルスタックエンドシステムに送信されるようにインターネットを介して送信することができます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 / IPv6対応IPv4専用プロトコルスタック、両方の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.
ユビキタス無線アクセスは、ほぼどこにでもネットワークインフラストラクチャへの接続を可能にします。車も人が彼らと動き回るネットワークをホストすることができます。例えば、民間航空機ネットワークは、航空機と地上局との接続点は、別の大陸から移動することができるノマディックネットワーク、ローカル・モビリティ、およびグローバルモビリティのための要件を含みます。モバイルネットワークは、プロバイダ集約（PA）アドレスプレフィクスと同様プロバイダ非依存（PI）を使用できるようにする必要があります。また、セッションの存続として知られている - 音声などの一部のアプリケーションでは、急速またはシームレス接続ハンドオフを必要とします。インターネットルーティングは、過度の移動度によって破壊されてはならないので、モバイルノード又はエッジネットワークの移動は特に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).
レンジャー企業ネットワークは、インターネット上にオーバーレイされたときに到達可能と過剰なルーティングチャーンを作成せずに維持しながら、モバイルノードまたは（エッジ・ネットワークまたは企業ネットワーク任意の複合を接続する）モバイルルータは、アタッチメントの異なる点の間で移動することができます。民間航空会社のシナリオでは、モバイルルータとの航空機は、そのオンボードネットワークの再アドレス指定することなく、添付の地上局点（つまり、異なる大陸にあってもよい）との間で移動します。航空通信サービスプロバイダ（ACSP）1、ACSP2内の1つの一部である2つの、エアナビゲーションサービスプロバイダ（ANSP）に直接最後：図12は、4つの異なるアクセスポイント間遷移航空機を示しています。この例ではACSP1とACSP2は異なる大陸にあるかもしれないので、従来のモバイルIPホームエージェントスキーム[RFC3775] [RFC5944]は1個のACSPまたは他のために非常に非効率的なパスになります。エアロ企業ネットワークは、両方の大陸にまたがり、複数のエントリーポイントと終了ポイントを提供することにより、効率的な経路を可能にするオーバーレイ（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へのアクセス移動の点は、変更はエアロ企業ネットワーク外で行われていない場合。 （図12のACSP1に航空機から二つの異なるリンクによって示されるように）航空機が同じ親企業ネットワークの地上局との間で移動するとき、航空機は、アタッチメントの新しい点でそのPIプレフィックスを発表し、古いからそれらを撤回します。世界中のインターネットは何の変化も見ない、とプレフィックスは親エアロ企業ネットワーク内に発表または撤回する必要はないので、マッピング・システムの解約は、ACSP1に限られています。すなわち、チャーンを再帰的階層の階層を下げるために単離されます。これは、以前に破壊的なBGPは、モバイルオンボードのネットワークをサポートするために、インターネットルーティングシステムに変更を伝播Connexionは、によって擁立非推奨のモビリティソリューションと対比することができます。
Many emerging network scenarios require autoconfiguration of Mobile Ad hoc Networks (MANETs). Where first responders need networking for communications and coordination between teams, RANGER allows each team or agency to quickly stand up a network and then use the autoconfiguration described in [RFC5558] to coordinate address/prefix autoconfiguration and discover border routers needed for teams and agencies to interconnect.
多くの新興ネットワークシナリオは、モバイルアドホックネットワーク（MANET）の自動設定が必要です。第一応答者がチーム間のコミュニケーションと調整のためのネットワーキング必要な場合は、RANGERは、各チームや機関が迅速にネットワークを立ち上がった後、アドレス/プレフィックスの自動設定を調整し、チームや機関にするために必要な境界ルータを発見するために、[RFC5558]で説明自動設定を使用することができます相互接続。
For example, Figure 13 shows how police units arriving on a scene with no network infrastructure can create a wireless network using vehicle-mounted 802.11 hotspots with one or more cellular, 802.16, or satellite links in order to reach the Internet. In this example, the California Highway Patrol sets up an incident management center with a satellite link to the Internet and vet1 serving network L1. The Los Angeles County Sheriff team sets up network L1.1 at their field headquarters, and the Altadena police force creates the L1.2 network with their mobile units. R2 is the router that serves as an EBG for border routers X3 and X4, which connect networks L1.2 and L1.1, respectively. X3 serves vet3, and X4 serves vet2.
例えば、図13は、無ネットワークインフラストラクチャと現場に到着警察ユニットがインターネットに到達するために、1つまたはセルラ以上、802.16、又は衛星リンクを持つ802.11ホットスポットを車両は、搭載使用して無線ネットワークを作成する方法を示しています。この例では、カリフォルニアハイウェイパトロールは、インターネットへの衛星リンクと、ネットワークL1をサービングvet1インシデント管理センターを設定します。ロサンゼルス郡保安官のチームは、その分野の本社でネットワーク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.1と炎レスポンスチームエンタープライズネットワークF1.2を設定すると、企業ネットワークのF1を作成します。 R1及びR2は、互いを発見し、手動設定により、インターネット上のピアEBRsなります。ネットワークL1には、個々のPIアドレスのプレフィックスは、L1にL1.2及びL1.1から発表され、そしてR2は、衛星ISPにそれらをアドバタイズします。 R1は、X1、X2に接頭辞のそのWiMAXの提供者と代表者の部分からPAプレフィックスを受け取ります。 R2もR1にPIプレフィックスをアドバタイズし、そこPAプレフィックスを学び、R1とIGPを実行します。
+------+
| 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まず、レスポンダMANET
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.
軍事ネットワークは民間のネットワークからの多くの点で異なって明確に定義されたポリシー要件を反映しています。軍の情報セキュリティ要件は、情報は、特定の分類にラベル付けされているにつながります。ベル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はこの概念はサブネットワーク上に動作する企業ネットワークに適用する場合RANGERが企業内部（ネットワーク）別個の企業ネットワーク内に位置する2つのエンタープライズ境界ルータ（EBR）のインターフェース、AとBとの間のVETインターフェイスの作成をサポートしていることを示していますIPトポロジの階層のレベルは、このVETインタフェースは、IP-in-IPカプセル化を使用します。これは、人気のCOMSECアプローチ（ - [RFC4301]のIPsec）に対応します。この同じRANGERの概念はIPトポロジ階層のサブネットワークレベルで動作するエンタープライズネットワークに適用されると、これはCOMSECの古い形式（リンク層暗号化）に対応しています。同じレンジャー概念はシングルトンEBRノードである企業ネットワークに適用した場合（すなわち、IP階層トポロジの界面準位）が、これは第三の軍事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のアプローチを説明するRANGERアーキテクチャの柔軟性を示しています。一つは、図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.
戦術的な軍事アドホックネットワークにおける最も明白な戦術の展開とアドホックネットワークにおける自身の自己形成ネットワーク属性の高移動度であること、多くの点で従来のネットワークとは異なります。各ネットワーク・戦術的なエンティティがラジオ/ルータをサポートしているため、軍事アドホックネットワークにおけるルータ内の数字は、伝統的な民間のネットワークより（密度の高い）より多数桁違いすることができます。これは、非MANETの展開と比較しても、小規模の導入が比較的大きいルータ集団を有することを意味します。大きなルータ集団は、直接プロトコルの拡張性の問題へのより高い感度を作成します。 IPプロトコルが効果的に減衰させると緩和技術が採用されている場合でも、スケーリングルータを制約断続を知らせるために、好ましくない反応するので、ルータのスケーラビリティの問題はさらに悪化します。信号の間欠自体は、モビリティの特性とローカルデプロイメント環境の無線信号伝搬属性である（例えば、等地形、群葉、建物、天候、距離、などの問題）。戦争の戦いはまた、天然さらに信号断続の確率を高め、無線信号の伝搬を減らし、その多くのより多くの防御地形の中に配置するために、戦争の戦闘機を奨励しています。
RANGER recursion enables MANETs that naturally encourage route aggregation and scaling through simple "plug and play" hierarchical arrangements that parallel organizational structures and do not entail complex manual configurations. For example, a MANET autonomous system may benefit from RANGER recursion by being physically comprised of enterprise networks that are autonomous systems themselves. This relationship can be recursively extended vertically as deep as required in order to create route aggregation between entities having common mission assignments at differing levels of abstraction. Since MANET routing is an active research topic, it is helpful to realize that these structures may or may not use routing protocols similar to their civilian IP Topology Hierarchy peers. For example, because of the behavior of BGP within highly mobile environments, the Exterior Gateway Protocol (EGP) used to link ASs may or may not be BGP and, if it is BGP, it may have unusual timer settings. However, whatever IGP and EGP is used, RANGER constructs can increase route aggregation between entities sharing common mission assignments to enable route scaling.
RANGERの再帰は当然ルート集約を奨励し、シンプルを通じてスケーリング「プラグアンドプレイ」の階層アレンジメントパラレル組織構造を、複雑な手動設定を必要としませんアドホックネットワークにおけるを可能にします。例えば、MANET自律システムは、物理的に自律システム自体である企業ネットワークからなることによりレンジャー再帰から利益を得ることができます。この関係は、再帰的に縦に抽象化の異なるレベルでの共通の使命割り当てを持つエンティティ間のルート集約を作成するために必要な限り深く拡張することができます。 MANETのルーティングは、アクティブな研究テーマであるので、これらの構造はまたはその民間のIPトポロジ階層のピアと類似のルーティングプロトコルを使用しない場合があることを実現するために有用です。例えば、あるため非常にモバイル環境内のBGPの動作のため、エクステリアゲートウェイプロトコル（EGP）は、BGPであれば、それは珍しいタイマー設定を有していてもよく、またはBGPをしてもしなくてもよいのASをリンクするために使用して。しかし、使用されているものIGPとEGP、RANGER構築物は、ルートのスケーリングを可能にするために、共通の使命の割り当てを共有するエンティティ間のルート集約を増やすことができます。
Tactical military MANETs often have requirements to communicate with stationary infrastructures. By localizing mobility into an enterprise network, the specific mobility-friendly protocols can then be localized and their aggregation results presented to the stationary network using a protocol supported by the stable network. This also reduces the impact of mobility upon routing and addressing systems as reported to the stationary infrastructure. Mobility-induced route fluctuations (e.g., routing flaps) can still occur, but their impact can be dampened if RANGER constructs are used to localize them in lower tiers of the IP Topology Hierarchy. For example, enterprise network A in Figure 3 can be a military MANET, and enterprise network B may be a stationary military entity. Recall that enterprise networks A and B interface at a specific IP Topology Hierarchy level, but they may be physically extended by RANGER mechanisms. For example, enterprise network A can be a MANET enterprise that is physically a network-of-networks Internet that interfaces to enterprise network B as if it were an autonomous system. This gives enterprise network B a more stable and aggregated view of the enterprise network A Internet than would be the case if it were directly aware of A's various sub-enterprise components.
戦術的な軍事アドホックネットワークにおけるは、多くの場合、固定インフラストラクチャと通信するための要件があります。企業ネットワークへの移動性をローカライズすることにより、特定のモビリティ向けプロトコルは、次に局在化することができ、その集計結果は、安定したネットワークによってサポートされるプロトコルを使用して、固定ネットワークに提示します。これはまた、固定インフラストラクチャに報告されたようにシステムのルーティングおよびアドレス指定時移動度の影響を低減します。モビリティ誘発性経路の変動（例えば、ルーティングフラップ）が依然として起こり得るが、レンジャー構築物は、IPトポロジ階層の下位階層でそれらを局在化するために使用される場合、その影響を減衰させることができます。例えば、図3の企業ネットワークAは、軍事MANETすることができ、企業ネットワークBは、固定軍事エンティティであってもよいです。特定のIPトポロジの階層レベルでその企業のネットワークA及びBのインタフェースを呼び出し、それらは物理的にレンジャー機構によって拡張することができます。たとえば、企業ネットワークAは、物理的に、それは自律システムであるかのように企業ネットワークBにインターフェースネットワーク・オブ・ネットワーク、インターネットであるMANET企業であってもよいです。これは、Aの様々なサブエンタープライズコンポーネントの直接知っていた場合よりも、企業ネットワーク、インターネットのより安定した集約ビューB企業ネットワークを与えます。
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.
戦術的な軍事ネットワークのもう一つの重要な特徴は、ラジオネットワークは、彼らが伝えるデータとは異なる分類レベルで動作するので、戦術的な軍事ネットワークは、同サイズの静止軍の展開（すなわち、数が何よりも大きさよりCOMSECのデバイスのいくつかの注文を持っている、ということですCOMSECデバイスは、モバイル戦争戦闘エンティティの数）の関数です。これは、オーバーレイCOMSECネットワーク関係の中に自分自身を大きなスケーラビリティの問題を作成することができます。 COMSECスケーリングの問題は、いくつかの次元で明らかにされています。 （レンジャー再帰がルーティング凝集およびスケーリングを改善するために、IPトポロジ企業内、企業構造を作成するために垂直に使用されたのと同様ことは、認識することが重要であるので、レンジャー再帰ピア企業との間の経路最適化トランザクションの承認を可能に同じIPトポロジの階層レベル内で）ネットワーク・オーバーレイ・システムのCOMSEC凝集およびスケーリングを向上させることができます。 VETのレンジャー使用はまた、トンネル上堅牢パケット識別及び最大伝送単位（MTU）リンク適応サービスを提供するサブネットワークのカプセル化及びアダプテーションレイヤ（SEAL）と結合します。これらの機能は、送信元アドレスのスプーフィングや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を」シナリオ、を生じさせます。
To address this brittleness, the ISP can deploy "Carrier-Grade NATs" (CGNs) [INCR-CGN] that provide a second level of RLOC address translation on the path from the CPE to the Internet. When the CGNs are also configured as EBGs, CPE routers can discover them as default routers for reaching EID-based services using the EBG discovery mechanisms specified in VET.
この脆弱性を対処するために、ISPは、「キャリアグレードのNAT」（CGNを）を展開することができる[INCR-CGN]インターネットへのCPEからの経路上のRLOCアドレス変換の第二レベルを提供します。 CGNをもEBGsとして設定されている場合、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.
「ISPのネットワークにIPv6を導入するためのシナリオと分析」[RFC4029]はISPバックボーンネットワークと顧客の両方の接続の移行に関する考慮事項について説明。しかし、この文書では、ルータ間のトンネルのユースケースを考慮しています。したがって、（唯一のホストとルータまたはホスト間のトンネリングをサポートしている）ISATAP機構は候補技術として言及されていません。初期のポイントソリューション（例えば、トンネルセットアッププロトコル（TSP）[RFC5572]、シンプルIPv6の型のIPv4トンネル確立手順（ステップ）[STEP]、など）が推奨しました。この文書では、RANGER、VETを提案し、シールはまた、これらのネットワークでは、適切なソリューションになります。
[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）は、ゲートウェイ汎用パケット無線サービス（GPRS）サポートノード（GGSN）へのオペレータネットワークを介してトンネルを確立するために、パケットデータプロトコル（PDP）コンテキストを使用しています。レンジャーは、3GPPの遷移で使用することができます。 UEは、IPv6を使用し、PDPコンテキストがIPv4のプロバイダのネットワークを介して確立されたとき、UEは、EBRとしてそれ自体を構成し、VETトンネルを通じて（RANGER EBGなど）GGSNと接触することができます。
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またはデバイスは、レンジャー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の中で、多くの航空通信サービスプロバイダー（ACSP）とエアナビゲーションサービスプロバイダ（ANSP）図5にこれらのエンティティのそれぞれを示すように、内部、すなわちATN内の自律システムやインターネットで、のいずれかとして編成されたネットワークがあるかもしれません自身はさらに、内部、地域組織、または機能室として組織下の階層の企業ネットワークに細分することができます。 ATN内ACSPsとANSPsは安全飛行民間航空サービスのための共通の目的を共有する一方で、それがあることに注意してください、企業ネットワークは、コンポーネントが別個のASであることを必要とし、競合する事業、社会的、または政治的な利害関係を有することができます。
The RANGER principles therefore support collaborative objectives while allowing very diverse local policy distinctions. In this manner, entities that do not trust each other can create collaborative infrastructures to achieve common goals.
非常に多様なローカルポリシーの区別を可能にしながらRANGERの原則は、そのための共同の目標をサポートしています。このようにして、お互いを信頼しないエンティティが共通の目標を達成するための共同のインフラストラクチャを作成することができます。
Operational associations like this will characterize many future deployments, including the US Department of Defense's Global Information Grid (GIG). In particular, although the routing and addressing arrangements of all enterprise networks require a mutual level of cooperative active management at a certain level, scaling issues, security policy differences, free market forces, organizational differences, political distinctions, or other factors may create internal competition among entities that otherwise share common goals. This will require different enterprise networks within that association to be separated into distinct ASs that are linked within their own functional Internet relationship.
このような運用団体は国防のグローバル情報グリッド（GIG）の米国部門を含め、多くの将来の展開を特徴付けます。全ての企業ネットワークのルーティングおよびアドレッシング配置が一定のレベルで協力アクティブな管理の相互のレベルを必要とするが、特に、スケーリングの問題、安全保障政策の違い、自由市場の力、組織の違い、政治的な区別、またはその他の要因には、内部の競争を作成することができそれ以外の場合は、共通の目標を共有エンティティ間。これは、独自の機能のインターネット関係の中にリンクされている別個のASに分離するために、そのアソシエーション内の異なる企業のネットワークを必要とするであろう。
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項を参照）モビリティをサポートしている必要があり、それは多くの場合、お互いに競争しながら、安全かつ効率的な空の旅を提供するために協力し、多くの政府や民間団体を提供しています。図14に示されているエアロオーバーレイは、企業ネットワークを形成するようにレンジャーと、これらのニーズを満たす1つの可能な方法は、インターネットを介してIPインIPトンネルを使用してオーバーレイを作成することになるようにACSPとANSPエッジネットワークから内部パケットそのEBRsのVETインタフェース間の移動は、唯一のホップとしてインターネットを介して自分の通過を参照してください。
_...--------------------------------------..._
/ \
( IPv4 Internet )
-...________________________________________...-
| / | \ |
| / | \ |
_...--------------------------------------..._
/ \
( Aero Overlay )
-...________________________________________...-
. . . . . .
. . . . . .
_...-------.._ _...-------.._ _...-------.._
/ \ / \ / \
( ACSP1 ) ( ANSP ) ( ACSP2 )
-...________...- -...________...- -...________...-
Figure 14. Aeronautical Overlay
図14航空オーバーレイ
Each Aeronautical Communications Service Provider (ACSP), and Aeronautical Navigation Service Provider (ANSP) constitute an enterprise network recursively nested below the aero overlay. Relationships between the various enterprise networks can vary from slight to tight integration. In the example, the ACSP and ANSP might choose to exchange full routing information for their edge networks using a coordinated global-scope RLOC address space across which ACSP and ANSP EBRs can route traffic without further mapping lookups or re-encapsulation at intermediate EBRs. Other enterprise networks that have the aero network as a common parent may not have any knowledge of each other's interior routing but will merely forward packets on a default route up to the aero overlay.
各航空通信サービスプロバイダ（ACSP）、および航空ナビゲーションサービスプロバイダ（ANSP）が再帰的にエアロオーバーレイの下にネストされた企業ネットワークを構成しています。様々な企業ネットワーク間の関係は若干の緊密な統合に異なる場合があります。一例では、ACSPとANSP協調グローバルスコープRLOCアドレス空間を使用して、エッジネットワークのための完全なルーティング情報を交換することを選択するかもしれないACSPと横切るANSP EBRsルーティングできるトラフィック中間EBRsでさらにマッピングルックアップまたは再カプセル化せず。共通の親としてのエアロネットワークを持っている他の企業ネットワークは、互いの内部ルーティングのいずれかの知識を持っていないかもしれませんが、エアロオーバーレイまでのデフォルトルートになります単にパケットを転送。
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へ移行すると予測されています。レンジャーは、IPv4（またはIPv6）を横切って一緒にOSIネットワークをブリッジインターネット、またはOSIネットワークを介してIPv4またはIPv6ネットワークをブリッジすることができます。 （ISOネットワーク・サービス・アクセス・ポイントを検索して、それらの取り付けられたOSIエッジネットワーク間の通信をサポートすることができる（インターネット、エアロネットワーク、または別の親または子の企業ネットワークであるかどうか）は、共通の企業ネットワーク上のIPインタフェースを持つEBRsの対RLOCマッピングのNSAP）アドレス[IS8348] IPアドレスの代わりに。 OSIコネクションレスネットワークプロトコル（CLNP）は[IS8473]パケットは、従って、インターネットプロトコル企業ネットワーク上の伝送のためのIPv4（またはIPv6）ヘッダ内にカプセル化することができます。いくつかのOSIネットワークは、アプリケーションが通常の方法でレンジャー企業横切っとの間で行わ得られたIPパケットと、TCP / IP上OSI上層を運ぶためにRFC 2126 [RFC2126]を使用して適合されている間、[RFC4548]をアドレッシングIPv6へ移行することができます。別のアプローチは、インターネットプロトコルネットワークを介してトンネルOSIネットワーク・プロトコル・データ・ユニットに[RFC1070]をサブネットワーク収束を使用することです。
Figure 15 depicts an ACSP and ANSP connected via an IPv4 aero overlay. Host H represents a system onboard an aircraft that has a wireless link to the ACSP, connected via an enterprise-edge network interface on EBR F within the ACSP enterprise network. H resides on an IPv6 edge network, and its EID is taken from the ACSP IPv6 prefix. H needs to send a query to server S in the ANSP enterprise network. H starts by sending a DNS query to the server at G, and in return it receives the EID of server S. H then creates an IPv6 packet with source EID(H) and destination EID(S) and forwards it to its default router, F. F consults G for a mapping from EID(S) to the appropriate RLOC. In this case, EBR F encapsulates the IPv6 packet in an IPv6 outer packet and forwards the packet to its default EBG, A. A decapsulates the packet and looks up the destination EID(S) by querying the DNS server at EBR B. B returns a mapping with the RLOC of EBR E. A encapsulates the IPv6 inner packet in an IPv4 outer packet with source RLOC(A) and destination RLOC(E). The packet is 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エアロオーバーレイを介して接続されACSPとANSPを示します。ホストHはACSPエンタープライズネットワーク内のEBR F上のエンタープライズエッジネットワークインターフェースを介して接続されたACSPへの無線リンクを有する航空機のオンボードシステムを表します。 Hは、IPv6エッジネットワーク上に存在し、そのEIDはACSP IPv6プレフィックスから取られます。 HはANSPの企業ネットワーク内のサーバSにクエリを送信する必要があります。 、HはGでサーバにDNSクエリを送信することによって開始し、リターンでは、S Hは、次いで、ソースEID（H）と宛先EID（S）とIPv6パケットを作成し、そのデフォルトルータに転送サーバのEIDを受信しますF. Fは、適切なRLOCにEID（S）からマッピングのGを参照します。この場合には、EBR FがIPv6外部パケットにIPv6パケットをカプセル化し、そのデフォルトEBGにパケットを転送する、A. Aはパケットをデカプセル化し、EBR B. BリターンでDNSサーバーを照会することによって、宛先EID（S）を検索しEBR E. AのRLOCとマッピングは、ソースRLOC（A）と宛先RLOC（E）とのIPv4外部パケット内のIPv6内部パケットをカプセル化します。それをデカプセル化されたEに達するまで、パケットはエアロオーバーレイにEBRs C及びDを介して転送されます。 Eは、EID / RLOCマッピングのキャッシュを調べ、SのためのEBRがN EがソースRLOC（E）と宛先RLOC（N）とIPv6パケットにパケットをカプセル化していることを発見します。パケットがNに達したときに、それがカプセル化が解除され、インナーIPv6パケットは、サーバ、Sにエッジネットワーク上で転送されます
_...--------------------------------------..._
/ (B) (D) \
( Aero Overlay (IPv4) )
-...________________________________________...-
. . .
(A) (C) .
. . .
_...------------------------.._ (E)
/ \ .
/ (F) \ .
( [H] ACSP (IPv6) ) .
\ (G) / .
\...__________________________... .
.
_...------------------------.._
/ \
/ (M) (N) \
( ANSP (IPv6) )
\ [S] /
\...__________________________...
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]は、ゲートウェイを介してISPネットワークに接続されたIPv6対応ルータとエンドシステムのサポートのための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ボックスを使用して、顧客のネットワークの広範な実践に代表されます。 RANGERは、直接、このシナリオには対応していません。しかし、Teredoのメカニズム[RFC4380]は多くの場合、十分な解決策を提供することができます。
Case d is a scenario that has not yet seen widespread adoption. In this scenario, the customer network could be configured as IPv6 only, and the deployment could be considered as an IPv6-only extension to a RANGER enterprise-edge network. End systems in this scenario would still require support for legacy IPv4-only applications, and if the customer network contained IPv4-only routers and end systems the RANGER encapsulation mechanisms would still apply.
ケースDは、まだ広く採用さを見ていないシナリオです。このシナリオでは、顧客のネットワークはIPv6のみのように構成することができ、および展開はレンジャーエンタープライズエッジネットワークにIPv6のみの拡張と考えることができます。このシナリオでは、エンド・システムは、依然として、従来のIPv4のみのアプリケーションのサポートを必要とする、と顧客ネットワークはルータとエンドシステムIPv4のみが含まれている場合RANGERカプセル化メカニズムは、まだ適用されます。
Cases b and c correspond to the scenario of the customer gateway to the ISP becoming an IPv6 router. In that case, the gateway could become a RANGER EBR, and the scenario becomes the same as the SOHO network use cases discussed in Section 4.3. In particular, when traditional home network IPv4 NAT boxes are updated to also support IPv6 routing, the NAT box becomes a RANGER EBR.
ケースBとIPv6ルータになってISPに顧客ゲートウェイのシナリオに対応するCをその場合、ゲートウェイは、RANGER EBRなる可能性、およびシナリオは、セクション4.3で説明したSOHOネットワークユースケースと同じになります。具体的には、伝統的なホームネットワークのIPv4 NATボックスはまた、IPv6ルーティングをサポートするように更新されている場合、NATボックスはRANGERの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.
RANGERに関連するマッピングおよびカプセル化の懸念は、[RFC5720]のセクション3.7で議論されてきました。これらは、アプリケーショントラフィックへのマッピングシステムの効果を含む、マッピングシステム、MTUの影響、およびレガシーインターネット網の能力を確保する必要が使用するものRANGERに接続します。
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.
この文書で説明するシナリオが密接に独立RANGERオーバーレイネットワーク内の任意の成長のネイティブIPv6とIPv4インターネットの将来の成長を検討していません。例えば、同時に数百万の顧客をサポートし、現在の日の主要なインターネットサービス（例えば、グーグル、ヤフー、イーベイ、アマゾンは、）ネイティブインターネットルーティングによっておよびアドレッシングではなく、オーバーレイネットワークで最高の提供され続ける可能性が高いです動的なマッピング状態の調整が必要にアレンジ。しかし、同時に、より多くの小さなエンドユーザのネットワークプロバイダに依存しないが、複数の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.
インターネットは、今日はインターネット内のノードはのRLOCとしてパブリックIPv4アドレス空間から対処して、巨大な企業ネットワークとみなすことができます。起因したIPv4の32ビットアドレッシングの制約のために、しかし、継続的な拡大は、IPv6が広く普及を見るためにまだ有しているトランスレータ（NATのを）アドレスはIPv4ネットワークの広範囲の展開を介して発生しています。
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モデルにおいて、例えば、想定されるネットワーク・オブ・ネットワークモデルの縮重発現をもたらしました。実際、これらのNAT変換ドメインは、彼らがエンドシステムの任意の大規模ネットワークのためにプロキシすることができるにもかかわらず、グローバルなインターネット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]で扱われています。 RANGERアーキテクチャ自体はセキュリティ上の考慮事項に対応していませんが、それはやる機能仕様のためのアーキテクチャフレームワークを提案しています。トンネリングとセキュリティ上の懸念は、レンジャーアーキテクチャと互換性のある推奨事項と共に、[TUNNEL-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]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC5720] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010.
[RFC5720]テンプリン、F.、 "ルーティングとグローバル企業再帰（RANGER）とのネットワークにおけるアドレス指定"、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]ジェン、D.、マイゼル、M.、マッシー、D.、王、L.、張、B.、およびL.チャン、 "APT：実践トランジットマッピングサービス"、進歩、2007年11月に作業。
[BEHAVE-v6v4] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", Work in Progress, August 2010.
[BEHAVE-v6v4]ベーカー、F.はLi、X.、バオ、C.、およびK.陰陽 "のIPv4 / IPv6変換のためのフレームワーク" が進歩、2010年8月ワーク。
[BELL-LaPADULA] Bell, D. and L. LaPadula, "Secure Computer Systems: Mathematical Foundations and Model", October 1974.
、1974年10月：[BELL-LaPADULA]ベル、D.およびL. LaPadulaは、 "数学基礎とモデルのコンピュータシステムをセキュア"。
[CATENET] Pouzin, L., "A Proposal for Interconnecting Packet Switching Networks", May 1974.
[CATENET]プザン、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]シン、H.、Beebee、W.、Donley、C.、スターク、B.、およびO. Troan、エド。、 "IPv6のカスタマーエッジルータのための基本要件"、進歩、2010年12月に作業。
[GROW-VA] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "FIB Suppression with Virtual Aggregation", Work in Progress, August 2010.
[GROW-VA]フランシス、P.、徐、X.、Ballani、H.、ジェン、D.、Raszuk、R.、およびL.チャン、 "仮想集約を用いたFIBの抑制"、進歩、2010年8月での作業。
[HUSTON-END] Huston, G., "The End of the (IPv4) World is Nigher!", July 2007.
[HUSTON-END]ヒューストン、G.は、 "（IPv4）の世界の終わりはNigherです！"、2007年7月。
[IEN48] Cerf, V., "The Catenet Model for Internetworking", July 1978.
[IEN48]サーフ、V.、 "インターネットワーキングのためのCATENETモデル"、1978年7月。
[INCR-CGN] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Work in Progress, March 2009.
[INCR-CGN]江、S.、郭、D.、およびB.大工、 "インクリメンタルキャリアグレードNAT（CGN）IPv6移行について"、進歩、2009年3月での作業。
[IPv4POOL] Hain, T., "The IPv4 Address Pool Projection", April 2009.
[IPv4POOL]ハイン、T.、 "IPv4のアドレスプールのプロジェクション"、2009年4月。
[IS8348] International Organization for Standardization, International Electrotechnical Commission, "Open Systems Interconnection -- Network service definition", 2002.
[IS8348]国際標準化機構、国際電気、「開放型システム間相互接続 - ネットワークサービス定義」、2002年。
[IS8473] International Organization for Standardization, International Electrotechnical Commission, "Protocol for providing the connectionless-mode network service: Protocol specification", 1998.
[IS8473]国際標準化機構、国際電気、「接続モード・ネットワーク・サービスを提供するためのプロトコル：プロトコル仕様」、1998年。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, March 2009.
[LISP]ファリナッチ、D.、フラー、V.、マイヤー、D.、およびD.ルイス、 "ロケータ/ ID分離プロトコル（LISP）"、進歩、2009年3月に作業。
[RADIR-PROB-STATE] Narten, T., "On the Scalability of Internet Routing", Work in Progress, February 2010.
"インターネットルーティングのスケーラビリティについて" [RADIR-PROB-STATE] Narten氏、T.、進歩、2010年2月での作業。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a subnetwork for experimentation with the OSI network layer", RFC 1070, February 1989.
[RFC1070] Hagens、R.、ホール、N.、およびM.ローズ、 "OSIネットワーク層での実験のためのサブネットワークとしてのインターネットの利用"、RFC 1070、1989年2月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992.
[RFC1380]グロス、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.、RFC 1753、1994年12月 "ニムロッドルーティングとアドレッシングアーキテクチャのIPngの技術的要件"。
[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.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
"IPNGのためのインターネットルーティングのための新しいスキームとアドレッシング（ENCAPS）" [RFC1955] HindenとR.、RFC 1955、1996年6月。
[RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top of TCP (ITOT)", RFC 2126, March 1997.
"TCPの上にISOトランスポートサービス（ITOT）" [RFC2126] Pouffary、Y.およびA.ヤング、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]カーペンター、B.及びC.チョン、 "明示的なトンネルなしでの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]土屋、K.、樋口、H.、およびY. Atarashi、バンプ・イン・スタック "技術（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]デュラン、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.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、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.のファンデルポール、 "非管理ネットワークの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]リンド、M.、Ksinant、V.、公園、S.、ボドー、A.、およびP. Savola、 "ISPネットワークにIPv6を導入するためのシナリオと分析"、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]シン、M-K。、編、香港、Y-G。、萩野、J.、Savola、P.、およびE.カストロ、 "IPv6移行のアプリケーション側面"、RFC 4038、2005年3月。
[RFC4057] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4057]バウンド、J.、エド。、 "IPv6のエンタープライズネットワークシナリオ"、RFC 4057、2005年6月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]ベイカー、F.、リア、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.、エド。、RFC 4215、2005年10月、 "第三世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6移行に関する分析"。
[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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、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：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、RFC 4380、2006年2月。
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006.
[RFC4472]デュラン、A.、Ihren、J.、およびP. Savola、RFC 4472 "IPv6のDNSで運用考慮事項と課題"、2006年4月。
[RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code Point (ICP) Assignments for NSAP Addresses", RFC 4548, May 2006.
[RFC4548]グレー、E.、Rutemiller、J.、およびG.ツバメ、 "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.、ターラー、D.、およびL. Esibov、 "リンクローカルマルチキャスト名前解決（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]バウンド、J.、Pouffary、Y.、Klynsma、S.、chownコマンド、T.、およびD.グリーン、 "IPv6のエンタープライズネットワーク解析 - IPレイヤ3つのフォーカス"、RFC 4852、2007年4月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]テンプリン、F.、グリーソン、T.、およびD.ターラーは、 "イントラサイト自動トンネルは、プロトコル（ISATAP）をアドレス指定"、RFC 5214、2008年3月。
[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010.
[RFC5320]テンプリン、F.、エド。、 "サブネットワークのカプセル化とアダプテーション層（SEAL）"、RFC 5320、2010年2月。
[RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[RFC5558]テンプリン、F.、エド。、 "仮想エンタープライズトラバーサル（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]ブランシェ、M.およびF.親、RFC 5572、2010年2月 "トンネル設定プロトコル（TSP）とのIPv6トンネルブローカ"。
[RFC5579] Templin, F., Ed., "Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces", RFC 5579, February 2010.
[RFC5579]テンプリン、F.編、 "イントラサイト自動トンネル上のIPv4パケットの送信アドレス指定プロトコル（ISATAP）インタフェース"、RFC 5579、2010年2月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887]大工、B.、アトキンソン、R.、およびH.フリンクは、RFC 5887、2010年5月、 "リナンバリングはまだ作業が必要"。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]パーキンス、C.、エド。、 "IPv4のIPモビリティのサポート、改訂"、RFC 5944、2010年11月。
[RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", RFC 6115, February 2011.
[RFC6115]李、T.、エド。、 "ルーティング・アーキテクチャのための勧告"、RFC 6115、2011年2月。
[STEP] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", Work in Progress, January 2004.
[STEP] Savola、P.、 "シンプルIPv6のインのIPv4トンネルの確立手順（STEP）"、進歩、2004年1月での作業。
[TUNNEL-SEC] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns With IP Tunneling", Work in Progress, October 2010.
[TUNNEL-SEC]クリシュナン、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
メールアドレス：russerts@hotmail.com
Eric W. Fleischman (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
エリック・W. Fleischman（エディタ）ボーイング・リサーチ＆テクノロジー私書箱ボックス3707 MC 7L-49シアトル、WA 98124 USA
EMail: eric.fleischman@boeing.com
メールアドレス：eric.fleischman@boeing.com
Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
フレッド・L.テンプリン（エディタ）ボーイング・リサーチ＆テクノロジー私書箱ボックス3707 MC 7L-49シアトル、WA 98124 USA
EMail: fltemplin@acm.org
メールアドレス：fltemplin@acm.org