[要約] RFC 5720は、グローバルエンタープライズ再帰（RANGER）ネットワークにおけるルーティングとアドレッシングに関するものです。その目的は、大規模なネットワーク環境での効果的なルーティングとアドレッシングの実現です。
Independent Submission F. Templin
Request for Comments: 5720 Boeing Phantom Works
Category: Informational February 2010
ISSN: 2070-1721
Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)
グローバルエンタープライズの再帰を備えたネットワークでのルーティングとアドレス指定（レンジャー）
Abstract
概要
RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence.
レンジャーは、グローバルエンタープライズの再帰を備えたネットワークでのスケーラブルなルーティングとアドレス指定のためのアーキテクチャのフレームワークです。このコンテキスト内の「エンタープライズネットワーク」という用語は、さまざまなユースケースと展開シナリオにまで拡張されます。「エンタープライズ」は、モバイルアドホックネットワークのようにダイナミックな小さなオフィス、ホームオフィス（SOHO）ネットワークと同じくらい小さいことができます。、マルチオーガニゼーション企業と同じように複雑であり、グローバルインターネット自体と同じ大きさです。このようなネットワークには、スケーラビリティ、プロバイダーに独立、モビリティ、マルチホーム、セキュリティのための宿泊施設とルーティングおよび対処計画の調整のためのアーキテクチャされたソリューションが必要です。これらの考慮事項は、既存の展開に特に当てはまりますが、クリーンスレートアプローチにも同じ原則が適用されます。レンジャーアーキテクチャはこれらの要件に対処し、IPv6/IPv4共存の包括的なフレームワークを提供します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5720.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5720で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. The RANGER Architecture .........................................7
3.1. Routing and Addressing .....................................7
3.2. The Enterprise-within-Enterprise Framework .................9
3.3. Virtual Enterprise Traversal (VET) ........................12
3.3.1. RANGER Organizational Principles ...................12
3.3.2. RANGER End-to-End Addressing Example ...............14
3.3.3. Dynamic Routing and On-Demand Mapping ..............14
3.3.4. Support for Legacy RLOC-Based Services .............16
3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL) ......18
3.5. Mobility Management .......................................18
3.6. Multihoming ...............................................20
3.7. Implications for the Internet .............................20
4. Related Initiatives ............................................21
5. Security Considerations ........................................22
6. Acknowledgements ...............................................23
7. References .....................................................23
7.1. Normative References ......................................23
7.2. Informative References ....................................24
RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a SOHO network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and also provides a comprehensive framework for IPv6/ IPv4 coexistence [COEXIST].
レンジャーは、グローバルエンタープライズの再帰を備えたネットワークでのスケーラブルなルーティングとアドレス指定のためのアーキテクチャのフレームワークです。このコンテキスト内の「エンタープライズネットワーク」という用語は、さまざまなユースケースと展開シナリオにまで拡張されます。「エンタープライズ」はソーホーネットワークと同じくらい小さく、モバイルアドホックネットワークと同じくらいダイナミックで、マルチと同じくらい複雑になります。Organizational Corporation、またはグローバルなインターネット自体と同じ大きさ。このようなネットワークには、スケーラビリティ、プロバイダーに独立、モビリティ、マルチホーム、セキュリティのための宿泊施設とルーティングおよび対処計画の調整のためのアーキテクチャされたソリューションが必要です。これらの考慮事項は、既存の展開に特に当てはまりますが、クリーンスレートアプローチにも同じ原則が適用されます。レンジャーアーキテクチャはこれらの要件に対処し、IPv6/ IPv4共存[共存]の包括的なフレームワークも提供します。
RANGER provides a unifying architecture for enterprises that contain one or more distinct interior IP routing and addressing domains (or "Routing LOCator (RLOC) space"), with each distinct RLOC space containing one or more organizational groupings. Each RLOC space may coordinate their own internal addressing plans independently of one another, such that limited-scope addresses (e.g., [RFC1918] private-use IPv4 addresses) may be reused with impunity to provide unlimited scaling through spatial reuse. Each RLOC space therefore appears as an enterprise unto itself, where organizational partitioning of the enterprise into one or more "sub-enterprises" (or "sites") is also possible and beneficial in many scenarios. Without an architected approach, routing and addressing within such a framework would be fragmented due to address/prefix reuse between disjoint enterprises. With RANGER, however, multiple enterprises can be linked together to provide a multi-hop transit for nodes attached to enterprise edge networks that use Endpoint Interface iDentifier (EID) addresses taken from an IP addressing range that is distinct from any RLOC space.
レンジャーは、1つ以上の異なるインテリアIPルーティングとアドレス指定ドメイン（または「ルーティングロケーター（RLOC）スペース」）を含む企業に統一アーキテクチャを提供し、それぞれの異なるRLOCスペースに1つ以上の組織グループを含む。各RLOCスペースは、互いに独立して独自の内部アドレス指定計画を調整することができます。そのため、限られたスコープアドレス（[RFC1918]プライベート使用IPv4アドレスなど）は、空間的再利用を通じて無制限のスケーリングを提供するために免責で再利用できます。したがって、各RLOCスペースは、企業を1つまたは複数の「サブエンタープリス」（または「サイト」）に組織的な分割することも可能であり、多くのシナリオで有益であるエンタープライズ自体として表示されます。アーキテクチャされたアプローチがなければ、そのようなフレームワーク内でのルーティングとアドレス指定は、馬鹿げた企業間のアドレス/プレフィックスの再利用のために断片化されます。ただし、Rangerを使用すると、複数のエンタープライズをリンクして、RLOCスペースとは異なるIPアドレス範囲から取得したエンドポイントインターフェイス識別子（EID）アドレスを使用するエンタープライズエッジネットワークに接続されたノードのマルチホップトランジットを提供できます。
RANGER is recursive in that multiple enterprises can be joined together in a nested "enterprise-within-enterprise" fashion, where each enterprise also connects edge networks with nodes that configure addresses taken from EID space to support edge/core separation. In this way, the same RANGER principles that apply in lower levels of recursion can extend upwards to parent enterprises and ultimately to the core of the global Internet itself. Furthermore, it is also worth considering whether today's global Internet represents a limiting condition for recursion -- in particular, whether other internets could be manifested as "parallel universes" and joined together at still higher levels of recursion.
レンジャーは、複数の企業をネストされた「エンタープライズウィチンエンタープライズ」ファッションで結合できるという点で再帰的です。各エンタープライズは、エッジスペースから取られたアドレスを構成するエッジ/コア分離をサポートするエッジネットワークをノードと接続します。このようにして、再帰のレベルで適用される同じレンジャーの原則は、親企業に、そして最終的にはグローバルなインターネット自体の中核にまで及ぶことができます。さらに、今日のグローバルなインターネットが再帰の制限条件を表しているかどうか、特に他のインターネットが「平行宇宙」として現れ、さらに高いレベルの再帰で一緒に結合できるかどうかを考慮する価値があります。
The RANGER architecture is manifested through composite technologies, including Virtual Enterprise Traversal (VET) [VET], the Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL], and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]. Other mechanisms such as IPsec [RFC4301] are also in scope for use within certain scenarios.
レンジャーアーキテクチャは、仮想エンタープライズトラバーサル（VET）[VET]、サブネットワークのカプセル化および適応層（シール）[シール]、および地位の自動トンネルアドレス指定プロトコル（ISATAP）[RFC5214]を含む複合技術を通じて現れます。IPSEC [RFC4301]などの他のメカニズムは、特定のシナリオ内で使用する範囲にあります。
Noting that combinations with still other technologies are also possible, the issues addressed either in full or in part by RANGER include:
まだ他のテクノロジーとの組み合わせも可能であることに注意して、レンジャーが完全にまたは部分的に対処する問題は次のとおりです。
o scalable routing and addressing
o スケーラブルなルーティングとアドレス指定
o provider-independent addressing and its relation to provider-aggregated addressing
o プロバイダーに依存しないアドレス指定と、プロバイダーと組み合わせたアドレス指定との関係
o site mobility and multihoming
o サイトのモビリティとマルチホミング
o address and prefix autoconfiguration
o アドレスとプレフィックスAutoconfiguration
o border router discovery
o ボーダールーターの発見
o router/host-to-router/host tunneling
o ルーター/ホストからルーター/ホストトンネル
o neighbor discovery over tunnels
o トンネルを介した隣人の発見
o MTU determination for tunnels
o トンネルのMTU決定
o IPv6/IPv4 coexistence and transition
o IPv6/IPv4の共存と遷移
Note that while this document primarily uses the illustrative example of IPv6 [RFC2460] as a virtual overlay over IPv4 [RFC0791] networks, it is important to note that the same architectural principles apply to any combination of IPvX virtual overlays over IPvY networks.
このドキュメントは、主にIPv6 [RFC2460]の実例をIPv4 [RFC0791]ネットワークの仮想オーバーレイとして使用していますが、同じアーキテクチャの原理がIPVYネットワーク上のIPVX仮想オーバーレイの任意の組み合わせに適用されることに注意することが重要であることに注意してください。
Routing Locator (RLOC) an IPv4 or IPv6 address assigned to an interface in an enterprise-interior routing region. Note that private-use IP addresses are local to each enterprise; hence, the same private-use addresses may appear within disjoint enterprises.
ルーティングロケーター（RLOC）エンタープライズ内ルーティング領域のインターフェイスに割り当てられたIPv4またはIPv6アドレス。プライベート使用IPアドレスは各企業にとってローカルであることに注意してください。したがって、同じ個人用のアドレスがdisjoint Enterprises内に表示される場合があります。
Endpoint Interface iDentifier (EID) an IPv4 or IPv6 address assigned to an edge network interface of an end system. Note that EID space must be separate and distinct from any RLOC space.
エンドポイントインターフェイス識別子（EID）エンドシステムのエッジネットワークインターフェイスに割り当てられたIPv4またはIPv6アドレス。EIDスペースは、RLOCスペースとは別に異なる必要があることに注意してください。
commons an enterprise-interior routing region that provides a subnetwork for cooperative peering between the border routers of diverse organizations that may have competing interests. A prime example of a commons is the Default-Free Zone (DFZ) of the global Internet. The enterprise-interior routing region within the commons uses an addressing plan taken from RLOC space.
Commons競合する関心を持っている可能性のある多様な組織の国境ルーター間の協力的な覗き見のためのサブネットワークを提供する企業間ルーティング地域。コモンズの代表的な例は、グローバルインターネットのデフォルトフリーゾーン（DFZ）です。Commons内のエンタープライズインタールーティング領域は、RLOCスペースから取得したアドレス指定計画を使用しています。
enterprise the same as defined in [RFC4852], where the enterprise deploys a unified RLOC space addressing plan within the commons but may also contain partitions with disjoint RLOC spaces and/or organizational groupings that can be considered as enterprises unto themselves. An enterprise therefore need not be "one big happy family", but instead provides a commons for the cooperative interconnection of diverse organizations that may have competing interests (e.g., such as the case within the global Internet DFZ).
エンタープライズは[RFC4852]で定義されているのと同じです。ここでは、エンタープライズはコモンズ内で統一されたRLOCスペースアドレス指定計画を展開していますが、それ自体が企業と見なすことができる分離RLOCスペースおよび/または組織グループを持つパーティションも含まれている場合があります。したがって、企業は「1つの大きな幸せな家族」である必要はありませんが、代わりに、競合する関心を持っている可能性のある多様な組織（グローバルインターネットDFZの場合など）の協力的な相互接続のコモンズを提供します。
Enterprise networks are typically associated with large corporations or academic campuses; however, the RANGER architectural principles apply to any network that has some degree of cooperative active management. This definition therefore extends to home networks, small office networks, ISP networks, a wide variety of Mobile Ad Hoc Networks (MANETs), and even to the global Internet itself.
エンタープライズネットワークは通常、大企業または学術キャンパスに関連付けられています。ただし、レンジャーアーキテクチャの原則は、ある程度の協力的なアクティブ管理を備えたあらゆるネットワークに適用されます。したがって、この定義は、ホームネットワーク、小さなオフィスネットワーク、ISPネットワーク、多種多様なモバイルアドホックネットワーク（MANET）、さらにはグローバルなインターネット自体にまで拡張されます。
site a logical and/or physical grouping of interfaces within an enterprise commons, where the topology of the site is a proper subset of the topology of the enterprise. A site may contain many interior sites, which may themselves contain many interior sites in a recursive fashion.
サイトサイトのトポロジーがエンタープライズのトポロジーの適切なサブセットであるエンタープライズコモンズ内のインターフェイスの論理的および/または物理的なグループ化。サイトには多くのインテリアサイトが含まれている場合があります。これには、それ自体が再帰的な方法で多くのインテリアサイトが含まれている場合があります。
Throughout the remainder of this document, the term "enterprise" refers to either enterprise or site, i.e., the RANGER principles apply equally to enterprises and sites of any size or shape. At the lowest level of recursive decomposition, a singleton Enterprise Border Router can be considered as an enterprise unto itself.
このドキュメントの残りの部分を通して、「エンタープライズ」という用語は、エンタープライズまたはサイトのいずれかを指します。つまり、レンジャーの原則は、あらゆるサイズまたは形状の企業やサイトに等しく適用されます。再帰的な分解の最低レベルでは、シングルトンエンタープライズボーダールーターは、それ自体が企業と見なすことができます。
Enterprise Border Router (EBR) a router at the edge of an enterprise that is also configured as a tunnel endpoint in an overlay network. EBRs connect their directly attached networks to the overlay network, and connect to other networks via IP-in-IP tunneling across the commons to other EBRs. This definition is intended as an architectural equivalent of the functional term "EBR" defined in [VET].
エンタープライズボーダールーター（EBR）オーバーレイネットワークのトンネルエンドポイントとしても構成されているエンタープライズのエッジにあるルーター。EBRSは、直接接続されたネットワークをオーバーレイネットワークに接続し、コモンズを横断するIP-in-IPトンネルを介して他のEBRに接続します。この定義は、[VET]で定義されている機能的用語「EBR」に相当する建築物として意図されています。
Enterprise Border Gateway (EBG) an EBR that also connects the enterprise to provider networks and/or to the global Internet. EBGs are typically configured as default routers in the overlay and provide forwarding services for accessing IP networks not reachable via an EBR within the commons. This definition is intended as an architectural equivalent of the functional term "EBG" defined in [VET], and is synonymous with the term "default mapper" used in other contexts (e.g., [JEN]).
Enterprise Border Gateway（EBG）エンタープライズをプロバイダーネットワークおよび/またはグローバルインターネットに接続するEBR。EBGは通常、オーバーレイ内のデフォルトのルーターとして構成され、コモンズ内のEBRを介して到達できないIPネットワークにアクセスするための転送サービスを提供します。この定義は、[VET]で定義された機能的な用語「EBG」に相当するアーキテクチャの同等物として意図されており、他のコンテキスト（[Jen]など）で使用される「デフォルトマッパー」という用語と同義です。
Ingress Tunnel Endpoint (ITE) a host or router interface that encapsulates inner IP packets within an outer IP header for transmission over an enterprise-interior routing region to the RLOC address of an Egress Tunnel Endpoint (ETE).
Ingress Tunnel Endpoint（ITE）エンタープライズ内部ルーティング領域を介して送信するための外部IPヘッダー内の内部IPパケットをカプセル化するホストまたはルーターインターフェイス。
Egress Tunnel Endpoint (ETE) a host or router interface that receives encapsulated packets sent to its RLOC address, decapsulates the inner IP packets, then delivers them to the EID address of the final destination.
出力トンネルエンドポイント（ETE）RLOCアドレスに送信されたカプセル化されたパケットを受信するホストまたはルーターインターフェイスは、内側のIPパケットを脱カプセル化し、最終宛先のEIDアドレスに配信します。
overlay network a virtual network manifested by routing and addressing over virtual links formed through automatic tunneling. An overlay network may span many underlying enterprises.
オーバーレイネットワーク自動トンネリングを通じて形成された仮想リンクをルーティングおよびアドレス指定することによって明らかにされた仮想ネットワーク。オーバーレイネットワークは、多くの基礎となる企業にまたがる可能性があります。
Provider-Independent (PI) prefix an IPv6 or IPv4 EID prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) that is routable within a limited scope and may also appear in enterprise mapping tables. PI prefixes that can appear in mapping tables are typically delegated to a Border Router (BR) by a registry but are not aggregated by a provider network. Local-use IPv6 and IPv4 prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of a PI prefix, but these typically do not appear in mapping tables.
Provider-Aggregated (PA) prefix an IPv6 or IPv4 EID prefix that is either derived from a PI prefix or delegated directly to a provider network by a registry. Although not widely discussed, it bears specific mention that a prefix taken from a delegating router's PI space becomes a PA prefix from the perspective of the requesting router.
PROVIDER-AGGREGTED（PA）プレフィックスIPv6またはIPv4 EIDプレフィックスは、PIプレフィックスから派生するか、レジストリによってプロバイダーネットワークに直接委任されます。広く議論されていませんが、委任するルーターのPIスペースから取られた接頭辞は、要求するルーターの観点からPAプレフィックスになることを特に言及しています。
Additionally, RANGER provides an informative consideration of functional specifications and operational practices outlined in other documents. These documents include: 6over4 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels [RFC2529]; functional specifications and operational practices for automatic tunneling of unicast/multicast IPv6 packets over multicast-capable IPv4 enterprises.
さらに、Rangerは、他の文書で概説されている機能的仕様と運用慣行について有益な考慮事項を提供します。これらのドキュメントには、次のものが含まれます。明示的なトンネルのないIPv4ドメインを介したIPv6の6OVOR4伝送[RFC2529]。マルチキャスト対応のIPv4エンタープライズを介したユニキャスト/マルチキャストIPv6パケットの自動トンネリングのための機能仕様と運用プラクティス。
ISATAP Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]; functional specifications and operational practices for automatic tunneling of unicast IPv6 packets over unicast-only IPv4 enterprises.
ISATAP内部自動トンネルアドレス指定プロトコル（ISATAP）[RFC5214];ユニキャストのみのIPv4エンタープライズを介したユニキャストIPv6パケットの自動トンネリングのための機能仕様と運用プラクティス。
VET Virtual Enterprise Traversal (VET) [VET]; functional specifications and operational practices for automatic tunneling of both unicast and multicast IP packets with provisions for address/prefix autoconfiguration, provider-independent addressing, mobility, multihoming, and security. VET is descended from both 6over4 and ISATAP and is also known as "ISATAP version 2 (ISATAPv2)".
VET Virtual Enterprise Traversal（VET）[VET];ユニキャストとマルチキャストの両方のIPパケットの自動トンネリングのための機能仕様と運用慣行アドレス/プレフィックスオートコンチュレーション、プロバイダーに依存しないアドレス指定、モビリティ、マルチホミング、セキュリティの規定。獣医は6OVER4とISATAPの両方から派生しており、「ISATAPバージョン2（ISATAPV2）」としても知られています。
SEAL Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL]; an encapsulation sublayer that provides an extended IP Identification field and mechanisms for link MTU adaptation over tunnels.
シールサブネットワークのカプセル化および適応層（シール）[シール];トンネルを介したリンクMTU適応のための拡張IP識別フィールドとメカニズムを提供するカプセル化サブレーヤー。
The RANGER architecture enables scalable routing and addressing in networks with global enterprise recursion while sustaining support for legacy networks and services. Key to this approach is a framework that accommodates interconnection of diverse organizations across a commons that have a mutual spirit of cooperation but also have the potential for competing interests. The following sections outline the RANGER architecture within the context of anticipated use cases:
レンジャーアーキテクチャにより、レガシーネットワークとサービスのサポートを維持しながら、グローバルエンタープライズの再帰を備えたネットワークでのスケーラブルなルーティングとアドレス指定を可能にします。このアプローチの鍵は、協力の相互精神を持っているが、競合する利益の可能性を持つコモンズ全体の多様な組織の相互接続に対応するフレームワークです。次のセクションでは、予想されるユースケースのコンテキスト内でレンジャーアーキテクチャの概要を説明します。
The Internet today is facing "growing pains", with indications that core Routing Information Base (RIB) scaling may not be sustainable over the long term and that the remaining space for IPv4 address allocations may be depleted in the near future. Therefore, there is an emerging need for scalable routing and addressing solutions. It must further be noted that the same solutions selected to address global Internet routing and addressing scaling can apply equally for large enterprises -- or for any enterprise that would benefit from a separation of core and edge addressing domains.
今日のインターネットは「成長する痛み」に直面しており、コアルーティング情報ベース（RIB）スケーリングは長期的には持続可能ではなく、IPv4アドレスの割り当ての残りのスペースが近い将来に枯渇する可能性があることを示しています。したがって、スケーラブルなルーティングとアドレス指定ソリューションが新たに必要とされています。さらに、グローバルなインターネットルーティングとアドレス指定スケーリングに対処するために選択されたのと同じソリューションが、大企業、またはコアとエッジアドレス指定のドメインの分離から利益を得る企業に等しく適用できることに注意する必要があります。
RANGER supports scalable routing through an approach that parallels the "New Scheme for Internet Routing and Addressing" described in [RFC1955]. This approach is also commonly known as "map-and-encaps". In this approach, an Ingress Tunnel Endpoint (ITE) that must forward an IP packet first consults a mapping system to discover a mapping for the destination Endpoint Interface iDentifier (EID) to a Routing LOCator (RLOC) assigned to an Egress Tunnel Endpoint (ETE). The mapping system is typically maintained as a per-enterprise distributed database that is synchronized among a limited set of mapping agents. Distributed database management alternatives include a routing protocol instance maintained by Enterprise Border Gateways (EBGs), a DNS reverse zone distributed among a restricted set of caching servers, etc. Mapping entries are inserted into the mapping system through administrative configuration, automated prefix registrations, etc.
Rangerは、[RFC1955]に記載されている「インターネットルーティングとアドレス指定の新しいスキーム」に匹敵するアプローチを介したスケーラブルなルーティングをサポートしています。このアプローチは、一般に「マップアンドエンコップ」としても知られています。このアプローチでは、IPパケットを転送する必要があるイングレストンネルエンドポイント（ITE）が最初にマッピングシステムを参照して、宛先エンドポイントインターフェイス識別子（EID）のマッピングを発見して、出力トンネルエンドポイント（ETEに割り当てられたルーティングロケーター（RLOC）に）。マッピングシステムは通常、限られたマッピングエージェントのセット間で同期されるエンテルプライズ分散データベースとして維持されます。分散データベース管理の代替案には、エンタープライズボーダーゲートウェイ（EBG）が管理するルーティングプロトコルインスタンス、キャッシュサーバーの制限付きセット間に配布されるDNSリバースゾーンなどが含まれます。。
RANGER allows for an ITE to either consult the mapping system itself (while delaying or dropping initial IP packets) or forward initial packets to an EBG acting as a "default mapper". In either case, the ITE receives a mapping reply that it can use to populate its Forwarding Information Base (FIB). The choice of mapping approaches must be considered with respect to the individual enterprise network scenario, e.g., forwarding to an EBG may be more appropriate in some scenarios while ITE self-discovery may be more appropriate in others. Use of other mapping mechanisms is also possible according to the specific enterprise scenario.
Rangerでは、ITEがマッピングシステム自体（初期IPパケットの遅延またはドロップ）を参照するか、初期パケットを「デフォルトマッパー」として機能するEBGに相談することができます。どちらの場合でも、ITEは、転送情報ベース（FIB）を入力するために使用できるマッピング応答を受け取ります。マッピングアプローチの選択は、個々のエンタープライズネットワークシナリオに関して考慮する必要があります。たとえば、EBGへの転送がいくつかのシナリオでより適切な場合がありますが、ITEの自己発見は他のシナリオでより適切かもしれません。特定のエンタープライズシナリオに従って、他のマッピングメカニズムの使用も可能です。
After discovering the mapping, the ITE encapsulates inner IP packets in an outer IP header for transmission across the commons to the RLOC address of an ETE. The ETE in turn decapsulates the packets and forwards them over the next hop toward the EID address of the final destination. Therefore, the Routing Information Base (RIB) within the commons only needs to maintain state regarding RLOCs and not EIDs, while the synchronized EID-to-RLOC mapping state is maintained by a smaller number of nodes and is not subject to oscillations due to link state changes within the commons. Finally, EIDs are routable only within a limited scope within edge networks (which may be as small as node-local scope in the limiting case).
マッピングを発見した後、ITEは、Commonsを介してETEのRLOCアドレスに送信するために、外側のIPヘッダーに内部IPパケットをカプセル化します。ETEは、順番にパケットを脱カプセル化し、次のホップに最終目的地のEIDアドレスに向かって転送します。したがって、コモンズ内のルーティング情報ベース（RIB）は、EIDではなくRLOCに関して状態を維持する必要がありますが、同期されたEIDからRLOCへのマッピング状態は、少ない数のノードによって維持され、リンクによる振動の対象ではありませんコモンズ内の状態の変化。最後に、Eidsは、Edgeネットワーク内の限られたスコープ内でのみルーティング可能です（制限ケースのノードローカルスコープと同じくらい小さい場合があります）。
RANGER supports scalable addressing by selecting a suitably large EID addressing range that is distinct and kept separate from any enterprise-interior RLOC addressing ranges. It should therefore come as no surprise that taking EID space from the IPv6 addressing architecture should lead to a viable, scalable addressing alternative, while taking EID space from the (already exhausted) IPv4 addressing architecture may not.
Rangerは、明確な適切に大きなEIDアドレス指定範囲を選択し、エンタープライズ内のRLOCアドレス指定範囲とは別に保持されるスケーラブルアドレス指定をサポートします。したがって、IPv6アドレス指定アーキテクチャからEidスペースをとることは、（すでに疲れ果てた）IPv4アドレス指定アーキテクチャからEidスペースをとる一方で、実行可能でスケーラブルなアドレス指定の代替につながるはずであることは驚くことではありません。
Enterprise networks traditionally distribute routing information via Interior Gateway Protocols (IGPs) such as Open Shortest Path First (OSPF), while large enterprises may even use an Exterior Gateway Protocol (EGP) internally in place of an IGP. Thus, it is becoming increasingly commonplace for large enterprises to use the Border Gateway Protocol (BGP) internally and independently from the BGP instance that maintains the RIB within the global Internet DFZ.
エンタープライズネットワークは、従来、Open Shortest Path First（OSPF）などのインテリアゲートウェイプロトコル（IGP）を介してルーティング情報を配布していますが、大規模な企業はIGPの代わりに外部ゲートウェイプロトコル（EGP）を内部で使用することさえあります。したがって、大企業が、グローバルなインターネットDFZ内のリブを維持するBGPインスタンスから内部的および独立してボーダーゲートウェイプロトコル（BGP）を使用することがますます一般的になりつつあります。
As such, large enterprises may run an internal instance of BGP across many internal Autonomous Systems (ASs). Such a large enterprise can therefore appear as an internet unto itself, albeit with default routes leading to the true global Internet. Additionally, each internal AS within such an enterprise may itself run BGP internally in place of an IGP, and can therefore also appear as an independent, lower-tier enterprise unto itself. This enterprise-within-enterprise framework can be extended in a recursive fashion as broadly and as deeply as desired to achieve scaling factors as well as organizational and/or functional compartmentalization, e.g., as shown in Figure 1.
そのため、大企業は、多くの内部自律システム（ASS）でBGPの内部インスタンスを実行する場合があります。したがって、このような大企業は、真のグローバルなインターネットにつながるデフォルトのルートはありますが、それ自体にインターネットとして表示される可能性があります。さらに、そのような企業内の各内部は、IGPの代わりに内部的にBGPを実行する可能性があるため、独立した低層企業としても現れることがあります。このエンタープライズ付きのエンタープライズフレームワークは、図1に示すように、スケーリング要因や組織的および/または機能的なコンパートメント化を達成するために、広くかつ必要な限り深く拡張できます。
,---------------.
,-' Global `-. <--------+
( IPv6/IPv4 ) ,----|-----.
`-. Internet ,-' ( Enterprises)
`+--+..+--+ ...+--+ ( E2 thru EN )
_.-|R1|--|R2+----|Rn|-._ `.---------/
_.---'' +--+ +--+ ...+--+ -.
,--'' ,---. `---.
,-' X5 X6 .---.. `-.
,' ,.X1-.. / \ ,' `. `.
,' ,' `. .' E1.2 '. X8 E1.m \ `.
/ / \ | ,--. | / _,.._ \ \
/ / E1.1 \ | Y3 `. | | / Y7 | \
; | ___ | | ` W Y4 |... | `Y6 ,' | :
| | ,-' `. X2 | `--' | | `'' | |
: | | V Y2 | \ _ / | | ;
\ | `-Y1,,' | \ .' Y5 / \ ,-Y8'`- / /
\ \ / \ \_' / X9 `. ,'/ /
`. \ X3 `.__,,' `._ Y9'',' ,'
` `._ _,' ___.......X7_ `---' ,'
` `---' ,-' `-. -'
`---. `. E1.3 Z _' _.--'
`-----. \---.......---' _.---''
`----------------''
<---------------- Enterprise E1 ---------------->
Figure 1: Enterprise-within-Enterprise Framework
図1：エンタープライズ - エンテルプライズフレームワーク
Figure 1 depicts an enterprise 'E1' connected to the global IPv6/IPv4 Internet via routers 'R1' through 'Rn' and additional enterprises 'E2' through 'EN' that also connect to the global Internet. Within the 'E1' commons, there may be arbitrarily many hosts, routers, and networks (not shown in the diagram) that use addresses taken from RLOC space and over which both encapsulated and unencapsulated IP packets can be forwarded. There may also be many lower-tier enterprises, 'E1.1' through 'E1.m' (shown in the diagram), that interconnect within the 'E1' commons via Enterprise Border Routers (EBRs), depicted as 'X1' through 'X9' (where 'X1' through 'X9' see 'R1' through 'Rn' as EBGs). Within each 'E1.*' enterprise, there may also be arbitrarily many lower-tier enterprises that interconnect within the 'E1.*' commons via EBRs, depicted as 'Y1' through 'Y9' in the diagram (where 'Y1' through 'Y9' see 'X1' through 'X9' as EBGs). This recursive decomposition can be nested as deeply as desired and ultimately terminates at singleton nodes such as those depicted as 'V', 'W', and 'Z' in the diagram.
図1は、グローバルインターネットに接続する「RN」を介して「RN」を介して「RN」を介して「RN」を介して「R1」を介して「R1」を介して「R1」を介してグローバルIPv6/IPv4インターネットに接続されているエンタープライズ「E1」を示しています。「E1」コモンズ内には、RLOCスペースから取得したアドレスを使用し、カプセル化されていないIPパケットと非カプセル化されていないIPパケットを転送できる多くのホスト、ルーター、ネットワーク（図には示されていません）が任意に任意に存在している場合があります。また、エンタープライズボーダールーター（EBRS）を介して「E1」コモンズ内の相互接続を「E1.M」から「E1.M」から「E1.1」から「E1.1」から「E1.M」から「EBRS）を介して多くの低層企業がある場合があります。'x9'（ここで、 'x9'を介して 'x9'を介してebgsとして 'r1'を参照してください）。各 'e1。*'エンタープライズ内には、ebrsを介した「e1。*'commons内に相互接続する多くの低い低層企業があります。'y9'は、ebgsとして「x9」を介して「x1」を参照してください）。この再帰的な分解は、望ましいように深くネストすることができ、最終的には図の「V」、「W」、「Z」として描かれたものなどのシングルトンノードで終了します。
It is important to note that nodes such as 'V', 'W', and 'Z' may be simple hosts or they may be EBRs that attach arbitrarily complex edge networks with addresses taken from EID space. Such edge networks could be as simple as a home network behind a residential gateway or as complex as a major corporate/academic campus, a large service provider network, etc.
「V」、「W」、「Z」などのノードが単純なホストである場合がある場合、またはEIDスペースから取得したアドレスを任意に複雑なエッジネットワークを付けるEBRである場合があることに注意することが重要です。このようなエッジネットワークは、住宅のゲートウェイの背後にあるホームネットワークのように、または主要な企業/アカデミックキャンパス、大規模なサービスプロバイダーネットワークなどと同じくらい簡単です。
Again, this enterprise-within-enterprise framework can be recursively nested as broadly and deeply as desired. From the highest level of the recursion, consider now that the global Internet itself can be viewed as an "enterprise" that interconnects lower-tier enterprises E1 through EN such that all RANGER architectural principles apply equally within that context. Furthermore, the RANGER architecture recognizes that the global Internet need not represent a limiting condition for recursion, but rather allows that other internets could be manifested as "parallel universes" and joined together at still higher levels of recursion.
繰り返しになりますが、このエンタープライズ付きのエンタープライズフレームワークは、望ましいとおりに広く深く深くネストされる可能性があります。再帰の最高レベルから、グローバルなインターネット自体は、すべてのレンジャーアーキテクチャの原則がそのコンテキスト内で等しく適用されるように、より低層のエンタープライズE1を介してENを相互接続する「エンタープライズ」と見なすことができることを考慮してください。さらに、レンジャーアーキテクチャは、グローバルなインターネットが再帰の制限条件を表す必要はないことを認識していますが、他のインターネットを「平行宇宙」として明らかにし、さらに高いレベルの再帰で結合することができることを認識しています。
As a specific case in point, the future global Aeronautical Telecommunications Network (ATN), under consideration within the civil aviation industry [BAUER], will take the form of a large enterprise network that appears as an internet unto itself, i.e., exactly as depicted for 'E1' in Figure 1. Within the ATN, there will be many Air Communications Service Provider (ACSP) and Air Navigation Service Provider (ANSP) networks organized as autonomous systems internal to the ATN, i.e., exactly as depicted for 'E1.*' in the diagram. The ACSP/ANSP network EBGs will participate in a BGP instance internal to the ATN, and may themselves run independent BGP instances internally that are further sub-divided into lower-tier enterprises organized as regional, organizational, functional, etc. compartments. It is important to note that, while ACSPs/ANSPs within the ATN will share a common objective of safety-of-flight for civil aviation services, there may be competing business/social/political interests between them, such that the ATN is not necessarily "one big happy family". Therefore, the model parallels that of the global Internet itself.
特定のケースとして、将来のグローバルな航空通信ネットワーク（ATN）は、民間航空産業[Bauer]内で検討中で、インターネット自体、つまり描かれたとおりに表示される大規模なエンタープライズネットワークの形を取ります。図1の「E1」の場合、ATN内には、ATNの内部の自律システムとして編成された多くの航空通信サービスプロバイダー（ACSP）および航空ナビゲーションサービスプロバイダー（ANSP）ネットワークがあります。*'図の中。ACSP/ANSPネットワークEBGSは、ATNの内部BGPインスタンスに参加し、それ自体が地域、組織、機能などとして組織化された低層企業にさらに下位に分割される独立したBGPインスタンスを内部的に実行する可能性があります。ATN内のACSPS/ANSPは、民間航空サービスの飛行の安全性の共通の目的を共有するが、それらの間に競合するビジネス/社会/政治的利益があるため、ATNは必ずしも必ずしもそうではないことに注意することが重要です。「1つの大きな幸せな家族」。したがって、モデルはグローバルなインターネット自体のモデルと類似しています。
Such an operational framework may indeed be the case for many next-generation enterprises. In particular, although the routing and addressing arrangements of all enterprises will require a mutual level of cooperative active management at a certain level, free market forces, business objectives, political alliances, etc. may drive internal competition.
このような運用フレームワークは、実際に多くの次世代企業に当てはまる可能性があります。特に、すべての企業のルーティングとアドレス指定の取り決めは、特定のレベル、自由市場の力、ビジネス目標、政治的同盟などで相互レベルの協力的な積極的な管理を必要とします。
Within the enterprise-within-enterprise framework outlined in Section 3.2, the RANGER architecture is based on overlay networks manifested through Virtual Enterprise Traversal (VET) ([VET], [RFC5214]). The VET approach uses automatic IP-in-IP tunneling in which ITEs encapsulate EID-based inner IP packets within RLOC-based, outer IP headers for transmission across the commons to ETEs.
セクション3.2で概説されているエンタープライズエンタープライズフレームワーク内では、レンジャーアーキテクチャは、仮想エンタープライズトラバーサル（VET）（[VET]、[RFC5214]）を通じて顕在化されたオーバーレイネットワークに基づいています。VETアプローチは、ITEがコモンズからETEへの送信用のRLOCベースの外部IPヘッダー内のEIDベースの内側IPパケットをカプセル化する自動IP-in-IPトンネルを使用します。
For each enterprise they connect to, EBRs that use VET configure a Non-Broadcast, Multiple Access (NBMA) interface known as a "VET interface" that sees all other EBRs within the enterprise as potential single-hop neighbors from the perspective of the inner IP protocol. This means that, for many enterprise scenarios, standard neighbor discovery mechanisms (e.g., router advertisements, redirects, etc.) can be used between EBR pairs. This gives rise to a data-driven model in which neighbor relationships are formed based on traffic demand in the data plane, which in many cases can relax the requirement for dynamic routing exchanges across the overlay in the control plane.
彼らが接続する各エンタープライズについて、獣医を使用するEBRは、内部の視点からの潜在的なシングルホップ隣人としてエンタープライズ内の他のすべてのEBRを見ている「獣医インターフェイス」として知られる非放送、複数アクセス（NBMA）インターフェイスを構成しますIPプロトコル。これは、多くのエンタープライズシナリオで、EBRペア間で標準的な近隣発見メカニズム（例：ルーター広告、リダイレクトなど）を使用できることを意味します。これにより、データ駆動型のモデルが生じます。このモデルでは、データプレーンの交通需要に基づいて隣接関係が形成され、多くの場合、コントロールプレーンのオーバーレイ全体の動的ルーティング交換の要件を緩和できます。
When multiple VET interfaces are linked together, end-to-end traversal is seen as multiple VET hops from the perspective of the inner IP protocol. In that case, transition between VET interfaces entails a "re-encapsulation" approach in which a packet that exits VET interface 'i' is decapsulated then re-encapsulated before it is forwarded into VET interface 'i+1'. For example, if an end-to-end path between two EID-based peers crosses N distinct VET interfaces, a traceroute would show N inner IP forwarding hops corresponding to the portions of the path that traverse the VET interfaces.
複数のVETインターフェイスがリンクされている場合、エンドツーエンドのトラバーサルは、内部IPプロトコルの観点から複数のVETホップと見なされます。その場合、VETインターフェイス間の遷移には、VETインターフェイス「I」を終了するパケットが脱カプセル化され、VETインターフェイス「I 1」に転送される前に再エンコールされます。たとえば、2つのEIDベースのピア間のエンドツーエンドパスが異なる獣医インターフェイスを通過する場合、トレーサーは獣医界面を横断するパスの部分に対応する内部IP転送ホップを示します。
VET and its related works specify necessary mechanisms and operational practices to manifest the RANGER architecture. The use of VET in conjunction with SEAL (see Section 3.4) is essential in certain deployments to avoid issues related to source address spoofing and black holing due to path Maximum Transmission Unit (MTU) limitations. (The use of VET in conjunction with IPsec [RFC4301] may also be necessary in some enterprise network scenarios.) The following sections discuss operational considerations and use cases within the VET approach.
獣医とその関連作品は、レンジャーアーキテクチャを明らかにするために必要なメカニズムと運用慣行を指定します。SEAL（セクション3.4を参照）と連携したVETの使用は、パス最大伝送ユニット（MTU）の制限に関連するソースアドレスのスプーフィングとブラックホリングに関連する問題を回避するために、特定の展開に不可欠です。（一部のエンタープライズネットワークシナリオでは、IPSEC [RFC4301]と連携したVETの使用も必要になる場合があります。）以下のセクションでは、VETアプローチ内の運用上の考慮事項とユースケースについて説明します。
Figure 2 below depicts a vertical slice (albeit represented horizontally) from the enterprise-within-enterprise framework shown in Figure 1:
以下の図2は、図1に示すエンタープライズ内のフレームワークからの垂直スライス（水平に表されますが）を示しています。
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) ----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +--- + v +----+ v +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ t +----+ +-----+-------+
" . | 1 . . 2 . . 3 . " |
" . H . . . . . " |
" . . . . . . . . . . . . . . " +--+---+
" <E1.1.1> <E1.1> <E1> " | IPv4 |
" 10/8 10/8 10/8 " |Server|
" " " " " " " " " " " " " " "" " " " " " " " | S2 |
<-- Enterprise E1 --> +------+
Figure 2: Virtual Enterprise Traversal
図2：仮想エンタープライズトラバーサル
Within this vertical slice, each enterprise within the 'E1' recursive hierarchy is spanned by VET interfaces, represented as 'vet1' through 'vet3'. Each VET interface within this framework is a Non-Broadcast, Multiple Access (NBMA) interface that connects all EBRs within the same enterprise. Each enterprise within the 'E1' hierarchy may comprise a smaller topological region within a larger RLOC space, or they may configure an independent RLOC space from a common (but spatially reused) limited-scope prefix, e.g., depicted as multiple disjoint instances of '10/8' in the diagram.
この垂直スライス内では、「E1」再帰階層内の各企業は、「VET3」を介して「VET1」として表されるVETインターフェイスによって範囲されています。このフレームワーク内の各獣医インターフェイスは、同じ企業内のすべてのEBRを接続する非放送、複数アクセス（NBMA）インターフェイスです。「E1」階層内の各企業は、より大きなRLOC空間内のより小さなトポロジー領域を構成する場合があります。または、一般的な（ただし、空間的に再利用された）限定スコーププレフィックスから独立したRLOC空間を構成する場合があります。ダイアグラムの10/8 '。
In the RANGER approach, EBRs within lower-tier enterprises coordinate their EID prefixes with EBGs that connect to an upper-tier enterprise. EID prefixes could be either provider-independent (PI) prefixes owned by the EBR or provider-aggregated (PA) prefixes delegated by the EBG. In either case, EID prefixes must be coordinated with the enterprise routing/mapping systems.
レンジャーアプローチでは、より下層エンタープライズ内のEBRSは、EIDプレフィックスを上層企業に接続するEBGと調整します。EIDプレフィックスは、EBRが所有するプロバイダーに依存しない（PI）プレフィックスまたはProvider-Aggregated（PA）プレフィックスがEBGによって委任されます。どちらの場合でも、EIDプレフィックスはエンタープライズルーティング/マッピングシステムと調整する必要があります。
When PA EID prefixes are used, the EBR for each 'E1*' enterprise receives an EID prefix delegation from a delegating EBG in a parent enterprise. In this example, when 'R2' is a delegating router for the prefix '2001:DB8::/40', it may delegate '2001:DB8::/48' to 'X2', which in turn delegates '2001:DB8::/52' to 'Y1', which in turn delegates '2001:DB8::/56' to 'V'. The preferred mechanism for this recursive PA prefix sub-delegation is DHCP Prefix Delegation [RFC3633], which also arranges for publication of the prefixes in the enterprise routing system.
PA EIDプレフィックスを使用すると、各「E1*」エンタープライズのEBRは、親エンタープライズのEBGを委任するEIDプレフィックス委任を受信します。この例では、「R2」がプレフィックスの委任ルーター '2001：db8 ::/40'である場合、2001年：db8 ::/48 'から' x2 'に委任することができます。::/52 'to' y1 '。この再帰的なPAプレフィックスサブディレージゼーションの好ましいメカニズムは、DHCPプレフィックス委任[RFC3633]であり、エンタープライズルーティングシステムでのプレフィックスの公開も配置されています。
When PI EID prefixes are used, individual EBRs (e.g., 'V') register their PI prefixes (e.g., '2001:DB1:10::/56') by sending Router Advertisement (RA) messages to EBGs within the enterprise to assert prefix ownership. When stronger authentication is necessary, the EBRs can digitally sign the messages using the mechanisms specified for SEcure Neighbor Discovery (SEND) [RFC3971]. EBGs that receive the RAs (e.g., 'Y1') first verify the sender's credentials, then register the prefixes in the enterprise mapping system. Next, they forward a proxied version of the RA to EBGs within their parent enterprises (e.g., 'X2'). This proxying process continues up the recursive hierarchy until a default-free commons is reached. (In this case, the proxying process ends at 'R2'). After the initial registration, the EBR that owns the PI prefixes must periodically send additional RAs to update prefix expiration timers.
PI EIDプレフィックスを使用すると、個々のEBR（ 'v'）がPIプレフィックス（例： '2001：db1：10 ::/56'）をエンタープライズ内のEBGに送信することにより、PIプレフィックス（ '2001：DB1：10 ::/56'）を登録して、主張しています。プレフィックスの所有権。より強力な認証が必要な場合、EBRSは、安全な隣接発見（送信）[RFC3971]のために指定されたメカニズムを使用してメッセージにデジタル的に署名できます。RAS（「Y1」など）を受け取るEBGは、最初に送信者の資格情報を検証し、次にエンタープライズマッピングシステムにプレフィックスを登録します。次に、RAのプロキシバージョンを親エンタープライズ内のEBGに転送します（例： 'x2'）。このプロキシプロセスは、デフォルトのないコモンズに到達するまで、再帰的な階層を継続します。（この場合、プロキシプロセスは「R2」で終了します）。最初の登録後、PIプレフィックスを所有するEBRは、定期的に追加のRAを送信してプレフィックスの有効期限タイマーを更新する必要があります。
In Figure 2, an IPv6 host 'H' that is deeply nested within Enterprise 'E1' connects to IPv6 server 'S1', located somewhere on the IPv6 Internet. 'H' is attached to a shared link with IPv6/IPv4 dual-stack router 'V', which advertises the IPv6 prefixes '2001:DB8:0:0::/64' and '2001:DB8:10:0::/64'. 'H' uses standard IPv6 neighbor discovery mechanisms to discover 'V' as a default IPv6 router that can forward its packets off the local link, and configures addresses from both of the advertised prefixes. 'V' in turn sees node 'Y1' as an EBG that is reachable via VET interface 'vet1' and that can forward packets toward IPv6 server 'S1'. Similarly, node 'Y1' is an EBR on the enterprise spanned by 'vet2' that sees 'X2' as an EBG, and node 'X2' is an EBR on 'vet3' that sees 'R2' as an EBG. Ultimately, 'R2' is an EBR that connects 'E1' to the global Internet.
図2では、IPv6インターネットのどこかにあるEnterprise 'E1'に深くネストされているIPv6ホスト「H」がIPv6サーバー「S1」に接続しています。「H」は、IPv6/Dual-Stack Router 'V'との共有リンクに接続されています。これは、IPv6プレフィックス '2001：DB8：0：0：0 ::/64'および '2001：DB8：10：0 ::を宣伝しています。/64 '。'H'は、標準のIPv6ネイバーディスカバリーメカニズムを使用して、「V」をデフォルトのIPv6ルーターとして発見し、ローカルリンクからパケットを転送し、広告されたプレフィックスの両方からアドレスを構成します。「V」は、Node 'Y1'をVETインターフェイス「VET1」を介して到達可能であり、IPv6サーバー「S1」にパケットを転送できるEBGと見なしています。同様に、Node 'Y1'は、「Vet2」がEBGと見なす「Vet2」に及ぶエンタープライズのEBRであり、Node 'X2'は「VET3」のEBRで「R2」をEBGと見なしています。最終的に、「R2」は「E1」をグローバルインターネットに接続するEBRです。
In the example shown in Figure 2, 'V', 'Y1', 'X2', and 'R2' configure separate VET interfaces for each enterprise they connect to in order to discover routes through a dynamic routing protocol and/or mapping database lookups. After tunnels 'vet1' through 'vet3' are established, the EBRs connected to a VET interface can run a dynamic routing protocol such as OSPVFv3 [RFC5340] and exchange topology information over the VET interface using the NBMA interface model. In this way, each EBR can discover other EBRs on the link via routing protocol control message exchanges.
図2に示す例では、「V」、「Y1」、「X2」、および「R2」は、ダイナミックルーティングプロトコルおよび/またはマッピングデータベースの検索を介してルートを発見するために、各エンタープライズに個別の獣医インターフェイスを構成します。。「VET3」を介してトンネル「VET1」が確立された後、VETインターフェイスに接続されたEBRSは、NBMAインターフェイスモデルを使用してVETインターフェイスを介したOSPVFV3 [RFC5340]などの動的ルーティングプロトコルを実行できます。このようにして、各EBRは、ルーティングプロトコル制御メッセージ交換を介してリンク上の他のEBRを発見できます。
In a second example, Figure 3 depicts an instance of on-demand discovery of more specific routes in which an IPv6 end system 'H' connects to a peer end system 'J', located in a different organizational entity within 'E1':
2番目の例では、図3は、IPv6エンドシステム「H」が「E1」内の異なる組織エンティティにあるピアエンドシステム「J」に接続するより具体的なルートのオンデマンド発見のインスタンスを示しています。
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) ----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +----+ v +----+ +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ +----+ +-----+-------+
" . | 1 . . 2 . . . " |
" . H . . . . v . " |
" . . . . . . . . . . . e . " +--+---+
" . t . " | IPv4 |
" . . . . . . , . 3 . " |Server|
" . +----+ v +----+ . " | S2 |
" . | Z += e =+ X7 += . " +------+
" . +-+--+ t +----+ . "
" . | 4 . . . "
" . J . . . . . "
" . . . . . . . "
" 2001:DB8:20::/56 (PI) --------> "
" " " " " " " " " " " " " " "" " " " " " " "
<-- Enterprise E1 -->
Figure 3: On-Demand Discovery
図3：オンデマンド発見
In this example, tunnel interfaces 'vet1' through 'vet4' as well as IPv6 PI prefix registrations have been established through VET enterprise autoconfiguration procedures. When IPv6 end system 'H' with IPv6 address '2001:DB8:10::1' sends packets to a peer end system 'J' with IPv6 address '2001:DB8:20::1', the packets will be conveyed through 'V', 'Y1', and finally to 'X2' via default routes. Then, unless 'X2' has an IPv6 FIB entry matching 'J', it must discover that 'J' can be reached using a more direct route via 'X7' as the next-hop across the 'E1' commons.
この例では、「VET4」を介したトンネルインターフェイス「VET1」とIPv6 PIプレフィックス登録は、VET Enterprise Autoconfiguration手順を通じて確立されています。IPv6のh 'をIPv6アドレスで終了する場合' 2001：db8：10 :: 1 'Packetsをピアエンドシステムに送信しますIPv6アドレス' 2001：db8：20 :: 1 '、パケットは通知されます「V」、「Y1」、そして最後にデフォルトルートを介して「x2」になります。次に、「X2」にIPv6 FIBエントリ「J」が一致する場合を除き、「E1」コモンズの次のホップとして「X7」を介してより直接的なルートを使用して「J」に到達できることを発見する必要があります。
In particular, when 'X2' receives a packet on the 'vet2' interface with inner destination address 'J', it can perform an on-demand mapping lookup by consulting the enterprise mapping service, e.g., by consulting the DNS reverse zone. Alternatively, 'X2' can send the packet to a default router (e.g., 'R2'), which in turn can forward the packet to 'X7' and return an ICMPv6 redirect message. When 'X2' receives the redirect, it can send an RA message to 'X7' to prove that it is authorized to produce packets with a prefix that matches source address 'J'. 'X2' can then forward subsequent packets directly to 'X7' without involving 'R2'.
特に、「X2」がインナー宛先アドレス「J」を使用した「VET2」インターフェイスのパケットを受信すると、Enterprise Mapping Service、たとえばDNSリバースゾーンに相談することにより、オンデマンドマッピングルックアップを実行できます。または、 'x2'はパケットをデフォルトのルーター（ 'R2'など）に送信し、パケットを「x7」に転送し、ICMPV6リダイレクトメッセージを返すことができます。「x2」がリダイレクトを受信すると、raメッセージを「x7」に送信して、ソースアドレス「J」に一致するプレフィックスを備えたパケットを生成することが許可されていることを証明できます。「X2」は、「R2」を含むことなく、後続のパケットを「X7」に直接転送できます。
In some enterprise scenarios, dynamic routing and on-demand mapping can be combined as complementary functions. In other scenarios, it may be preferable to use either dynamic routing only or on-demand mapping only.
一部のエンタープライズシナリオでは、動的ルーティングとオンデマンドマッピングを補完的な関数として組み合わせることができます。他のシナリオでは、動的ルーティングのみまたはオンデマンドマッピングのみを使用することが望ましい場合があります。
Legacy hosts, routers, and networks that were already present in pre-RANGER deployments and have already numbered their interfaces with RLOC addresses must see continued support for RLOC-based services for the long term, even as EID-based services are rolled out in new deployments. For example, a legacy IPv4-only node behind an IPv4 Network Address Translator (NAT) must still be able to reach legacy IPv4-only Internet services (e.g., "http://example.com") long after the RANGER architecture and EID-based services are widely deployed.
レガシーのホスト、ルーター、およびレンジャーの展開にすでに存在しており、すでにRLOCアドレスでインターフェイスを番号付けしているネットワークは、EIDベースのサービスが新しいサービスで展開されていても、長期的にRLOCベースのサービスの継続的なサポートを見る必要があります展開。たとえば、IPv4ネットワークアドレス翻訳者（NAT）の背後にあるレガシーIPv4のみのノードは、レンジャーアーキテクチャとEidの長い間、Legacy IPv4のみのインターネットサービスに到達できる必要があります（ "http://example.com"） - ベースのサービスは広く展開されています。
Returning to the example diagrams, while virtual enterprise traversal across 'E1' provides a fully connected routing and addressing capability for EID-based services, legacy nodes will still require access to RLOC-based services within connected or disjoint RLOC spaces for an extended (and possibly indefinite) period. For example, Figure 4 below depicts the applicable RLOC-based IPv4 service-access scenarios for the RANGER architecture when VET interfaces are used to link recursively nested enterprises together:
図の例に戻ると、「E1」を横切る仮想エンタープライズトラバーサルは、EIDベースのサービスの完全に接続されたルーティングとアドレス指定機能を提供しますが、レガシーノードは、拡張された（および拡張された接続または分離RLOCスペース内のRLOCベースのサービスへのアクセスが必要です（およびおそらく不定）期間。たとえば、以下の図4は、レンジャーアーキテクチャの該当するRLOCベースのIPv4サービスアクセスシナリオを示しています。
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) -----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +--- + v +----+ v +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ t +----+ +-----+-------+
" . | 1 . . 2 . . 3 . " |
" . K L . . . . M . " |
" . . . . . . . . . . . . . . " +--+---+
" <E1.1.1> <E1.1> <E1> " | IPv4 |
" " |Server|
" " " " " " " " " " " " " " "" " " " " " " " | S2 |
<-- Enterprise E1 --> +------+
Figure 4: Support for Legacy RLOC-Based Services
図4：レガシーRLOCベースのサービスのサポート
In a first instance, a legacy RLOC-based IPv4 client 'K' within enterprise 'E1.1.1' can access RLOC-based IPv4 service 'L' within the same enterprise as normal and without the need for any encapsulation.
最初の例では、レガシーRLOCベースのIPv4クライアント「K」は、エンタープライズ '内のe1.1.1'内で、通常と同じエンタープライズ内で、カプセル化を必要とせずにRLOCベースのIPv4サービス「L」にアクセスできます。
Instead, 'K' discovers a "mapping" for 'L' through a simple lookup within the 'E1.1.1' enterprise-local name service, and conveys packets to 'L' through unencapsulated RLOC-based IPv4 routing and addressing within the 'E1.1.1' commons. In many instances, this may indeed be the preferred service-access model, even when EID-based IPv6 services are widely deployed due to factors such as inability to replace legacy IPv4 applications, IPv6 header overhead avoidance, etc.
代わりに、「K」は、「E1.1.1」エンタープライズ - ローカルネームサービス内の単純な検索を通じて「L」の「マッピング」を発見し、カプセル化されていないRLOCベースのIPv4ルーティングとアドレス指定を介して「L」にパケットを伝えます。E1.1.1 'コモンズ。多くの場合、これは、LEGACY IPv4アプリケーション、IPv6ヘッダーのオーバーヘッド回避などを交換できないなどの要因のために、EIDベースのIPv6サービスが広く展開されている場合でも、実際に優先サービスアクセスモデルである可能性があります。
In a second instance, RLOC-based IPv4 client 'K' can access RLOC-based IPv4 server 'S2' on the legacy global IPv4 Internet in a number of ways, based on the way the recursively nested 'E1.*' enterprises are provisioned:
第2の例では、RLOCベースのIPv4クライアント 'K'は、再帰的にネストされた 'e1。：
o if all of the recursively nested 'E1.*' enterprises are configured within the same IPv4 RLOC space, normal IPv4 forwarding will convey unencapsulated IPv4 packets from 'K' toward 'R2', which then acts as an IPv4 Network Address Translator (NAT) and/or an ordinary IPv4 Enterprise Border Router.
o 再帰的にネストされたすべての 'e1。*'エンタープライズが同じIPv4 RLOCスペース内で構成されている場合、通常のIPv4転送は、カプセル化されていないIPv4パケットを「K」から「R2」に向けて伝えます。および/または通常のIPv4エンタープライズボーダールーター。
o if the recursively nested 'E1.*' enterprises are configured within disjoint RLOC spaces, all EBGs 'Y1', 'X2', and 'R2' can be configured to provide an IPv4 NAT capability (i.e., a recursive nesting of NATs within NATs). However, this approach places multiple instances of stateful NAT devices on the path, which can lead to an overall degree of brittleness and intolerance to routing changes. Instead, 'R2' can act as a "Carrier-Grade NAT (CGN)", and 'V' can convey packets from 'K' to the CGN using IPv4-in-IPv6-in-IPv4 tunneling. The CGN can then decapsulate the inner, RLOC-based IPv4 packets and translate the IPv4 source addresses into global IPv4 source addresses before sending the packets on to 'S2'.
o 再帰的にネストされた 'e1。*'エンタープライズが馬鹿げたRLOCスペース内で構成されている場合、すべてのEBGS 'y1'、 'x2'、および 'r2'を設定することができます。）。ただし、このアプローチは、パス上にステートフルNATデバイスの複数のインスタンスを配置するため、ルーティングの変更に対する全体的な程度の脆弱性と不寛容につながる可能性があります。代わりに、「R2」は「キャリアグレードNAT（CGN）」として機能し、「V」はIPv4-in-IPV6-in-IPV4トンネリングを使用して「K」からCGNにパケットを伝えることができます。CGNは、内側のRLOCベースのIPv4パケットを脱カプセル化し、IPv4ソースアドレスをグローバルIPv4ソースアドレスに変換してから、パケットを「S2」に送信します。
o 'K' could be configured as an EID-based, IPv6-capable node and use standard IPv6 routing to reach an IPv6/IPv4 translator located at an EBR for the enterprise in which 'S2' resides. The translator would then use IPv6-to-IPv4 translation before sending packets onwards toward 'S2'. These and other alternatives are discussed in [WING].
o 「K」はEIDベースのIPv6対応ノードとして構成し、標準のIPv6ルーティングを使用して、「S2」が存在するエンタープライズのEBRにあるIPv6/IPv4翻訳者に到達することができます。翻訳者は、「S2」に向かってパケットを送信する前に、IPv6からIPV4の翻訳を使用します。これらおよびその他の選択肢については、[Wing]で説明されています。
In a final instance, RLOC-based IPv4 client 'K' can access an RLOC-based IPv4 server 'M' in a different enterprise within E1 as long as both enterprises are configured over the same IPv4 RLOC space. If the enterprises are configured over disjoint IPv4 RLOC spaces, however, 'K' would still be able to access 'M' by using EID-based IPv6 services, by using EID-based IPv4 services if an EID-based IPv4 overlay were deployed, or by using some form of RLOC-based IPv4 NAT traversal. 'K' could also access server 'M' if both 'V' and 'X2' implemented an IPv6/IPv4 protocol translation capability. Finally, 'K' and/or 'M' could implement a bump-in-the-wire or bump-in-the-api IPv6/IPv4 protocol translation capability.
最後の例では、RLOCベースのIPv4クライアント「K」は、両方の企業が同じIPv4 RLOCスペースで構成されている限り、E1内の別のエンタープライズでRLOCベースのIPv4サーバー「M」にアクセスできます。ただし、エンタープライズがIPv4 RLOCスペースで構成されている場合、EIDベースのIPv4サービスを使用して、EIDベースのIPv4サービスを使用して、EIDベースのIPv4サービスを使用して「K」にアクセスできるようになります。または、何らかの形のRLOCベースのIPv4 NATトラバーサルを使用します。「k」は、「V」と「x2」の両方がIPv6/IPv4プロトコル変換機能を実装した場合、サーバー「M」にアクセスすることもできます。最後に、「K」および/または「M」は、ワイヤーまたはAPIのIPv6/IPv4プロトコルの翻訳機能を実装できます。
Tunnel endpoints that depend on ICMP feedback from routers within the enterprise commons may be susceptible to undetected black holes due to ICMP filtering gateways and/or off-path ICMP spoofing attacks from a node pretending to be a router. Furthermore, rogue nodes within enterprises that do not correctly implement ingress filtering can send spoofed packets of any kind, e.g., for the purpose of mounting denial-of-service and/or traffic amplification attacks targeting underprivileged links.
エンタープライズコモンズ内のルーターからのICMPフィードバックに依存するトンネルエンドポイントは、ICMPフィルタリングゲートウェイおよび/またはルーターのふりをするノードからのオフパスICMPスプーフィング攻撃により、検出されないブラックホールの影響を受けやすい場合があります。さらに、イングレスフィルタリングを正しく実装していない企業内の不正なノードは、たとえば、サービスの拒否および/または恵まれないリンクをターゲットにしたトラフィック増幅攻撃を取り付ける目的で、あらゆる種類のスプーフィングされたパケットを送信する可能性があります。
The Subnetwork Encapsulation and Adaptation Layer (SEAL) provisions each encapsulated packet with a monotonically incrementing, extended Identification field (i.e., the 32-bit SEAL_ID) that tunnel endpoints can use as a nonce to detect off-path spoofing. Moreover, tunnel endpoints that use SEAL can continue to operate correctly even if some/many ICMPs are lost. Finally, tunnel endpoints that use SEAL can adapt to subnetworks containing links with diverse MTUs properties.
サブネットワークのカプセル化および適応レイヤー（シール）は、トンネルエンドポイントが非CEとして使用してパスオフポーフィングを検出できる単調な拡張識別フィールド（つまり、32ビットシール_ID）を単調に増加させる拡張識別フィールド（つまり、32ビットSEAL_ID）を提供します。さらに、シールを使用するトンネルエンドポイントは、一部/多くのICMPが失われたとしても、引き続き正しく動作します。最後に、シールを使用するトンネルエンドポイントは、多様なMTUプロパティを含むリンクを含むサブネットワークに適応できます。
Enterprise mobility use cases must be considered along several different vectors:
エンタープライズモビリティユースケースは、いくつかの異なるベクトルに沿って考慮する必要があります。
o nomadic enterprises and end systems may be satisfied to incur address renumbering events as they move between new enterprise network attachment points.
o Nomadic EnterprisesとEnd Systemsは、新しいエンタープライズネットワークの添付ポイント間を移動する際に、住所の住所イベントを発生させるために満たされる場合があります。
o mobile enterprises with PI prefixes may be satisfied by dynamic updates to the mapping system as long as they do not impart unacceptable churn.
o PIプレフィックスを備えたモバイルエンタープライズは、マッピングシステムへの動的な更新により、容認できない解約を行わない限り、満たされる場合があります。
o mobile enterprises and end systems with PA addresses/prefixes may require additional supporting mechanisms that can accommodate address/prefix renumbering.
o PAアドレス/プレフィックスを備えたモバイルエンタープライズとエンドシステムには、アドレス/プレフィックスの変更に対応できる追加のサポートメカニズムが必要になる場合があります。
Nomadic enterprise mobility is already satisfied by currently deployed technologies. For example, transporting a laptop computer from a wireless-access hot spot to a home network LAN would allow the nomadic device to re-establish connectivity at the expense of address renumbering. Such renumbering may be acceptable, especially for devices that do not require session persistence across mobility events and do not configure servers with addresses published in the global DNS.
Nomadic Enterprise Mobilityは、現在展開されているテクノロジーによってすでに満たされています。たとえば、ワイヤレスアクセスホットスポットからホームネットワークLANにラップトップコンピューターを輸送すると、Nomadicデバイスは住所の犠牲を払って接続を再確立することができます。このような変更は、特にモビリティイベント間のセッションの持続性を必要とせず、グローバルDNSで公開されているアドレスを持つサーバーを構成しないデバイスでは受け入れられる場合があります。
Mobile enterprises with PI prefixes that use VET and SEAL can move between parent enterprise attachment points as long as they withdraw the prefixes from the mapping systems of departed enterprises and inject them into the mapping systems of new enterprises. When moving between the lower recursive tiers of a common parent enterprise, such a localized event mobility may result in no changes to the parent enterprise's mapping system. Hence, the organizational structure of a carefully arranged enterprise-within-enterprise framework may be able to dampen mobility-related churn. For enterprises that require in-the-network confidentiality, IKEv2 Mobility and Multihoming (MOBIKE) [RFC4555] may also be useful within this context.
VETとシールを使用するPIプレフィックスを備えたモバイルエンタープライズは、出発した企業のマッピングシステムからプレフィックスを引き出し、それらを新しい企業のマッピングシステムに注入する限り、親エンタープライズアタッチメントポイント間を移動できます。一般的な親エンタープライズの下位再帰層を移動する場合、このようなローカライズされたイベントモビリティは、親エンタープライズのマッピングシステムに変更が生じない場合があります。したがって、慎重に配置されたエンタープライズとエンテルプライズフレームワークの組織構造は、モビリティ関連の解約を弱めることができる可能性があります。ネットワーク内の機密性を必要とする企業の場合、IKEV2モビリティとマルチホミング（Mobike）[RFC4555]もこのコンテキスト内で役立つ場合があります。
Mobile enterprises and end systems that move quickly between disparate parent enterprise attachment points should not use PI prefixes if withdrawing and announcing the prefixes would impart unacceptable mapping/routing churn and packet loss. They should instead use PA addresses/prefixes that can be coordinated via a rendezvous service. Mobility management mechanisms such as Mobile IPv6 [RFC3775] and the Host Identity Protocol (HIP) [RFC4423] can be used to maintain a stable identifier for fast moving devices even as they move quickly between visited enterprise attachment points.
プレフィックスを撤回してアナウンスすると、容認できないマッピング/ルーティングチャーンとパケット損失が与えられる場合、異なる親エンタープライズ添付ファイル間を迅速に移動するモバイルエンタープライズとエンドシステムは、PIプレフィックスを使用しないでください。代わりに、ランデブーサービスを介して調整できるPAアドレス/プレフィックスを使用する必要があります。モバイルIPv6 [RFC3775]やホストアイデンティティプロトコル（HIP）[RFC4423]などのモビリティ管理メカニズムを使用して、訪問したエンタープライズアタッチメントポイント間を迅速に移動しても、高速移動デバイスの安定した識別子を維持できます。
As a use case in point, consider an aircraft with a mobile router moving between ground station points of attachment. If the ground stations are located within the same enterprise, or within lower-tier sites of the same parent enterprise, it should suffice for the aircraft to announce its PI prefixes at its new point of attachment and withdraw them from the old. This would avoid excessive mapping system churn, since the prefixes need not be announced/withdrawn within the parent enterprise, i.e., the churn is isolated to lower layers of the recursive hierarchy. Note also that such movement would not entail an aircraft-wide readdressing event.
適切なユースケースとして、アタッチメントの地点間を移動するモバイルルーターを移動する航空機を検討してください。地上局が同じエンタープライズ内または同じ親エンタープライズの低層サイト内にある場合、航空機が新しい添付ファイルでPIプレフィックスを発表し、古いものから引き出すことは十分である必要があります。これにより、プレフィックスを親エンタープライズ内で発表/撤回する必要がないため、過度のマッピングシステムチャーンが回避されます。つまり、チャーンは再帰階層の層を下げるために分離されます。また、そのような動きは、航空機全体の再抑制イベントを伴うものではないことに注意してください。
As a second example, consider a wireless handset moving between service coverage areas maintained by independent providers with peering arrangements. Since the coverage range of terrestrial cellular wireless technologies is limited, mobility events may occur on a much more aggressive timescale than some other examples. In this case, the handset may expect to incur a readdressing event for its access interface at least, and may be obliged to arrange for a rendezvous service linkage.
2番目の例として、独立したプロバイダーが皮をむいた取り決めで維持しているサービスカバレッジエリア間を移動するワイヤレスハンドセットを検討してください。陸生セルラーワイヤレステクノロジーのカバレッジ範囲は限られているため、モビリティイベントは他の例よりもはるかに積極的なタイムスケールで発生する可能性があります。この場合、携帯電話は、少なくともアクセスインターフェイスのために再生イベントを発生させることを期待する場合があり、ランデブーサービスリンクを手配する義務がある場合があります。
It should specifically be noted that the contingency of mobility management solutions is not necessarily mutually exclusive and must be considered in relation to specific use cases. The RANGER architecture is therefore naturally inclusive in this regard. In particular, RANGER could benefit from mechanisms that could support rapid dynamic updates of PI prefix mappings without causing excessive churn.
モビリティ管理ソリューションの偶発性は必ずしも相互に排他的ではなく、特定のユースケースに関連して考慮する必要があることに特に注意する必要があります。したがって、レンジャーアーキテクチャは、この点で自然に包括的です。特に、レンジャーは、過度のチャーンを引き起こすことなく、PIプレフィックスマッピングの迅速な動的更新をサポートできるメカニズムの恩恵を受ける可能性があります。
As with mobility management, multihoming use cases must be considered along multiple vectors. Within an enterprise, EBRs can discover multiple EBGs and use them in a fault-tolerant and load-balancing fashion as long as they register their PI prefixes with each such EBG, as described in Section 3.3.1. These registrations are created through the transmission of Router Advertisement messages that percolate up through the recursive enterprise-within-enterprise hierarchy.
モビリティ管理と同様に、複数のベクトルに沿ってマルチホームのユースケースを考慮する必要があります。企業内で、EBRSは複数のEBGを発見し、セクション3.3.1で説明されているように、そのようなEBGそれぞれにPIプレフィックスを登録する限り、断層耐性で負荷バランスをとる方法で使用できます。これらの登録は、再帰的なエンタープライズの階層を介して浸透するルーター広告メッセージの送信を通じて作成されます。
As a first case in point, consider the enterprise network of a major corporation that obtains services from a number of ISPs. The corporation should be able to register its PI prefixes with all of its ISPs, and use any of the ISPs for its Internet access services.
一例として、多くのISPからサービスを取得する主要企業のエンタープライズネットワークを検討してください。企業は、すべてのISPにPIプレフィックスを登録し、ISPをインターネットアクセスサービスに使用できるはずです。
As a second use case, consider an aircraft with a diverse set of wireless links (e.g., VHF, 802.16, directional, SATCOM, etc.). The aircraft should be able to select and utilize the most appropriate link(s) based on the phase of flight and to change seamlessly between links as necessary. Other examples include a nomadic laptop with both 802.11 and Ethernet links, a wireless handset with both CDMA wireless and 802.11, etc.
2番目のユースケースとして、ワイヤレスリンクの多様なセット（VHF、802.16、Directional、SATCOMなど）を備えた航空機を検討してください。航空機は、飛行の段階に基づいて最も適切なリンクを選択して利用できる必要があり、必要に応じてリンク間でシームレスに変更することができます。その他の例には、802.11リンクとイーサネットリンクの両方を備えた遊牧ラップトップ、CDMAワイヤレスと802.11などのワイヤレスハンドセットなどがあります。
As with mobility management, the contingency of solutions is not necessarily mutually exclusive and can combine to suit use cases within the scope of the RANGER architecture.
モビリティ管理と同様に、ソリューションの偶発性は必ずしも相互に排他的ではなく、レンジャーアーキテクチャの範囲内でのユースケースに合わせて組み合わせることができます。
Selection of mapping alternatives may have significant implications for applications, server selection, route determination, security, etc. In particular, applications that expect all packets (including initial ones) to experience similar delays may be adversely affected by a scheme that imposes non-negligible delays when initial packets are queued while a look-aside mapping table is consulted. Still other applications may experience significant startup delays when its initial packets are dropped during a mapping lookup event. These factors would seem to favor a scheme that is able to forward initial packets along a path with sub-optimal delay while a mapping lookup is performed in parallel, e.g., such as when a "default mapper" is used.
マッピングの代替品の選択は、アプリケーション、サーバーの選択、ルート決定、セキュリティなどに大きな意味を持つ可能性があります。特に、すべてのパケット（初期のパケットを含む）が同様の遅延を経験することを期待するアプリケーションは、無視できないスキームによって悪影響を受ける可能性があります。Look-Asideマッピングテーブルが相談されている間に、初期パケットがキューにキューになったときの遅延。さらに他のアプリケーションは、マッピングルックアップイベント中に最初のパケットがドロップされると、重要なスタートアップ遅延が発生する場合があります。これらの要因は、「デフォルトマッパー」が使用される場合など、マッピングルックアップが並行して実行され、最適な遅延のあるパスに沿って初期パケットを転送できるスキームを支持するように思われます。
Generally speaking, proactive mapping-maintenance mechanisms may have scaling issues with the amount of updates they generate, while reactive mechanisms may involve effects to the delay of initial packets before the cached state is updated. Also to be considered are attacks against the mapping mechanism, which may result in denial of service of the mapping cache.
一般的に言えば、プロアクティブなマッピングメンテナンスメカニズムには、生成する更新の量に関するスケーリングの問題がある場合がありますが、反応的なメカニズムには、キャッシュ状態が更新される前に初期パケットの遅延への影響が含まれる場合があります。また、マッピングメカニズムに対する攻撃も考慮されます。これにより、マッピングキャッシュのサービスが拒否される可能性があります。
Encapsulation of packets in automatically created tunnels involves a number of issues as well. There are obvious interactions between encapsulation overhead and the effective tunnel MTU, which can be addressed by SEAL and (when necessary) careful operational link arrangements. Moreover, it is important to minimize the impact to the global routing table without at the same time impacting the ability of legacy Internet networks to connect to those employing RANGER. As long as other nodes in the Internet need to connect to networks implementing RANGER, EID routes need to appear both in the mapping system and the global BGP routing tables. This can be accommodated by keeping the number of prefixes aggregated by RANGER to the bare minimum through efficient aggregation (e.g., one or a few [PREF]::/4 IPv6 prefixes instead of millions of [PREF]::/32 prefixes).
自動的に作成されたトンネルでのパケットのカプセル化には、多くの問題も含まれます。カプセル化オーバーヘッドと効果的なトンネルMTUとの間には明らかな相互作用があります。これは、シールと（必要に応じて）慎重な運用リンクの配置によって対処できます。さらに、レガシーインターネットネットワークがレンジャーを雇用している人に接続する能力に影響を与えることなく、グローバルルーティングテーブルへの影響を最小限に抑えることが重要です。インターネット内の他のノードがレンジャーを実装するネットワークに接続する必要がある限り、EIDルートはマッピングシステムとグローバルBGPルーティングテーブルの両方に表示する必要があります。これは、効率的な集約を通じてレンジャーによって最小限に集計された接頭辞の数を保持することで対応できます（たとえば、数百万の[pref] ::/32プレフィックスではなく、1つまたはいくつかの[pref] ::/4 ipv6プレフィックス）。
The origins of the RANGER architectural principles can be traced to the "Catenet model for internetworking" ([CATENET], [IEN48], [RFC2775]) beginning as early as the mid-1970's. Subsequently, deliberations of the ROAD group [RFC1380] and related efforts such as NIMROD [RFC1753] provided a sustained evolution of the concepts. [RFC1955], "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", captures the high-level architectural aspects of the ROAD group deliberations.
レンジャーアーキテクチャの原則の起源は、1970年代半ばに早くから始まる「インターネットワークのカテネットモデル」（[Catenet]、[IEN48]、[RFC2775]）にまでさかのぼることができます。その後、道路グループ[RFC1380]の審議およびNimrod [RFC1753]などの関連する努力は、概念の持続的な進化を提供しました。[RFC1955]、「IPNGのインターネットルーティングとアドレス指定（capp）の新しいスキーム」は、ロードグループの審議の高レベルのアーキテクチャの側面を捉えています。
These foundational works significantly influenced more recent developments, including the X-Bone initiative [XBONE], which explored virtual topologies manifested through tunneling. Various tunneling approaches including IP-in-IP ([RFC2003], [RFC4213]), 6over4 [RFC2529], and ISATAP [RFC5214] have evolved from the mid-1990's until the present day and are used in common, operational practice. Tunnel-mode IPsec [RFC4301] is also commonly used for separation of security domains within enterprises.
これらの基礎作品は、トンネリングを通じて現れた仮想トポロジーを調査したX-Bone Initiative [Xbone]を含む、より最近の開発に大きな影響を与えました。IP-in-IP（[RFC2003]、[RFC4213]）、6OVOR4 [RFC2529]、およびISATAP [RFC5214]を含むさまざまなトンネルアプローチは、1990年代半ばから現在まで進化し、共通して使用されています。トンネルモードIPSEC [RFC4301]は、企業内のセキュリティドメインの分離にも一般的に使用されています。
Currently, initiatives with similar properties to RANGER are under development within the IRTF Routing Research Group (RRG) and within IETF working groups such as LISP, SOFTWIRE, V6OPS, and others. Numerous proposals have been offered within the RRG, including the Locator-Identifier Split Protocol (LISP) [LISP], Six-One [VOGT], ILNP [ILNP], Internet vastly improved plumbing (Ivip) [WHITTLE], A Practical Transit-Mapping Service (APT) [JEN], and Virtual Aggregation [VA]. Still other similar initiatives almost certainly exist.
現在、Rangerと同様の特性を持つイニシアチブは、IRTFルーティングリサーチグループ（RRG）およびLISP、Softwire、V6OPSなどのIETFワーキンググループ内で開発中です。ロケーター - アイデンティファイアスプリットプロトコル（LISP）[LISP]、6対[VOGT]、ILNP [ILNP]、インターネットが大幅に改善された配管（IVIP）、実用的なトランジット - を含む、RRG内で多数の提案が提供されています。マッピングサービス（APT）[JEN]、および仮想集約[VA]。さらに他の同様のイニシアチブはほぼ確実に存在します。
While RANGER shares many properties with these earlier works, it uniquely provides a top-to-bottom articulation of how the various pieces fit together within a recursively nested "enterprise-within-enterprise" (or "network-of-networks") framework. In this way, it bears striking resemblance to the network-of-networks model envisioned by CATENET. RANGER further provides a detailed consideration of challenging issues such as autoconfiguration, provider-independent addressing, border router discovery, tunnel MTU, multihoming, etc. that many other approaches have either overlooked or left for future work. A detailed analysis of RANGER applicability in various use case scenarios is provided in "RANGER Scenarios (RANGERS)" [RUSSERT].
レンジャーはこれらの以前の作品と多くのプロパティを共有していますが、さまざまな作品が再帰的にネストされた「エンタープライズ - エンタープライズ」（または「ネットワークオブネットワーク」）フレームワーク内にどのように適合するかについての最高の表現をユニークに提供します。このようにして、Catenetが想定したネットワークオブネットワークモデルに顕著に類似しています。レンジャーはさらに、オートコンフィギュレーション、プロバイダーに依存しないアドレス指定、ボーダールーターの発見、トンネルMTU、マルチホミングなどの挑戦的な問題の詳細な検討を提供します。さまざまなユースケースシナリオでのレンジャーの適用性の詳細な分析は、「レンジャーシナリオ（レンジャー）」[Russert]で提供されています。
Communications between endpoints within different sites inside an enterprise are carried across a commons that joins organizational entities with a mutual spirit of cooperation, but between which there may be competing business/sociological/political interests. As a result, mechanisms that rely on feedback from routers on the path may become brittle or susceptible to spoofing attacks. This is due to the fact that IP packets can be lost due to congestion or packet-filtering gateways and that the source addresses of IP packets can be forged. Moreover, IP packets in general can be generated by anonymous attackers, e.g., from a rogue node within a third-party enterprise that has malicious intent toward a victim.
エンタープライズ内の異なるサイト内のエンドポイント間のコミュニケーションは、相互の協力精神を持つ組織エンティティに加わるコモンズ全体に運ばれますが、その間に競合するビジネス/社会学的/政治的利益があるかもしれません。その結果、パス上のルーターからのフィードバックに依存するメカニズムは、攻撃をスプーフィングしたり、影響を受けたりする可能性があります。これは、うっ血またはパケットフィルタリングゲートウェイのためにIPパケットが失われる可能性があり、IPパケットのソースアドレスを偽造できるという事実によるものです。さらに、一般に、IPパケットは、匿名の攻撃者によって、たとえば、被害者に対して悪意を持っているサードパーティ企業内の不正なノードから生成することができます。
Path MTU Discovery is an example of a mechanism that relies on ICMP feedback from routers on the path and, as such, is susceptible to these issues. For IPv4, a common workaround is to disable Path MTU Discovery and let fragmentation occur in the network if necessary. For IPv6, lack of fragmentation support in the network precludes this option such that the mitigation typically recommended is to discard ICMP messages that contain insufficient information and/or to operate with the minimum IPv6 path MTU. This example extends also to other mechanisms that either rely on or are enhanced by feedback from network devices; however, attack vectors based on non-ICMP messages are also subject for concern.
The RANGER architecture supports effective mitigations for attacks such as distributed denial-of-service, traffic amplification, etc. In particular, when VET and SEAL are used, EBGs can use the 32-bit identification encoded in the SEAL header as well as ingress filtering to determine if a message has come from a topologically correct enterprise located across the commons. This allows enterprises to employ effective mitigations at their borders without the requirement for mutual cooperation from other enterprises. When source address spoofing by on-path attackers located within the commons is also subject for concern, additional securing mechanisms such as tunnel-mode IPsec between enterprise EBGs can also be used.
EBRs can obtain PI prefixes through arrangements with a prefix delegation authority. Thereafter, the EBR can announce and/or withdraw the prefixes within an enterprise by sending IPv6 Router Advertisements (RAs). In environments where additional authenticating mechanisms are necessary, the EBR can sign its RAs using SEcure Neighbor Discovery (SEND) [RFC3971].
EBRSは、プレフィックス委任当局との配置を通じてPIプレフィックスを取得できます。その後、EBRは、IPv6ルーター広告（RAS）を送信することにより、エンタープライズ内のプレフィックスを発表および/または撤回できます。追加の認証メカニズムが必要な環境では、EBRは安全な近隣発見（送信）[RFC3971]を使用してRASに署名できます。
While the RANGER architecture does not in itself address security considerations, it proposes an architectural framework for functional specifications that do. Security concerns with tunneling, along with recommendations that are compatible with the RANGER architecture, are found in [HOAGLAND].
レンジャーアーキテクチャはそれ自体がセキュリティの考慮事項に対処していませんが、機能的な仕様のためのアーキテクチャのフレームワークを提案しています。トンネリングに関するセキュリティの懸念と、レンジャーアーキテクチャと互換性のある推奨事項は、[Hoagland]にあります。
This work was inspired through the encouragement of the Boeing DC&NT network technology team and through the communications of the IESG.
この作業は、ボーイングDC＆NTネットワークテクノロジーチームの励ましとIESGの通信を通じてインスピレーションを受けました。
Many individuals have contributed to the architectural principles that form the basis for RANGER over the course of many years. The following individuals have given specific feedback on the RANGER document itself: Jari Arkko, Brian Carpenter, Eric Fleischman, Joel Halpern, Thomas Henderson, Steven Russert, Dallas Thomas, Robin Whittle.
多くの個人が、長年にわたってレンジャーの基礎を形成する建築原則に貢献してきました。次の個人は、レンジャーの文書自体について具体的なフィードバックを提供しています：Jari Arkko、Brian Carpenter、Eric Fleischman、Joel Halpern、Thomas Henderson、Steven Russert、Dallas Thomas、Robin Whittle。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[CATENET] Pouzin, L., "A Proposal for Interconnecting Packet Switching Networks", Proceedings of EUROCOMP, Bronel University, p. 1023-1036, May 1974.
[Catenet] Pouzin、L。、「パケットスイッチングネットワークを相互接続する提案」、Eurocompの議事録、Bronel University、p。1023-1036、1974年5月。
[COEXIST] Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios", Work in Progress, July 2009.
[共存] Arkko、J。およびM. Townsley、「IPv4ランアウトおよびIPv4-IPV6共存シナリオ」、2009年7月の作業。
[BAUER] Bauer, C. and S. Ayaz, "ATN Topology Considerations for Aeronautical NEMO RO", Work in Progress, September 2009.
[Bauer] Bauer、C。およびS. Ayaz、「Aeronautical nemo roのATNトポロジに関する考慮事項」、2009年9月、進行中の作業。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, September 2009.
[lisp] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator/ID Separation Protocol（LISP）」、2009年9月、作業進行中。
[HOAGLAND] Hoagland, J., Krishnan, S., and D. Thaler, "Security Concerns With IP Tunneling", Work in Progress, October 2008.
[Hoagland] Hoagland、J.、Krishnan、S。、およびD. Thaler、「IPトンネリングに関するセキュリティ上の懸念」、2008年10月の作業。
[JEN] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and L. Zhang, "APT: A Practical Transit Mapping Service", Work in Progress, November 2007.
[Jen] Jen、D.、Meisel、M.、Massey、D.、Wang、L.、Zhang、B。、およびL. Zhang、「Apt：A Practical Transit Mapping Service」、Work in Progress、2007年11月。
[RUSSERT] Russert, S., Fleischman, E., and F. Templin, "RANGER Scenarios", Work in Progress, September 2009.
[Russert] Russert、S.、Fleischman、E。、およびF. Templin、「レンジャーシナリオ」、2009年9月、進行中の作業。
[SEAL] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010.
[SEAL] Templin、F.、ed。、「サブネットワークのカプセル化と適応層（SEAL）」、RFC 5320、2010年2月。
[VET] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[Vet] Templin、F.、ed。、「Virtual Enterprise Traversal（VET）」、RFC 5558、2010年2月。
[WING] Wing, D., Ward, D., and A. Durand, "A Comparison of Proposals to Replace NAT-PT", Work in Progress, September 2008.
[Wing] Wing、D.、Ward、D。、およびA. Durand、「Nat-PTを置き換える提案の比較」、2008年9月、進行中の作業。
[IEN48] Cerf, V., "The Catenet Model for Internetworking", July 1978.
[IEN48] Cerf、V。、「インターネットワークのカテネットモデル」、1978年7月。
[ILNP] Atkinson, R., "ILNP Concept of Operations", Work in Progress, December 2008.
[ILNP] Atkinson、R。、「ILNP Operationsの概念」、2008年12月、進行中の作業。
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992.
[RFC1380] Gross、P。およびP. Almquist、「ルーティングとアドレス指定に関するIESG審議」、RFC 1380、1992年11月。
[RFC1753] Chiappa, N., "IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture", RFC 1753, December 1994.
[RFC1753] Chiappa、N。、「Nimrodルーティングとアドレス指定アーキテクチャのIPNG技術要件」、RFC 1753、1994年12月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC1955] Hinden、R。、「IPNGのインターネットルーティングとアドレス指定（capp）の新しいスキーム」、RFC 1955、1996年6月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529] Carpenter、B。およびC. Jung、「明示的なトンネルなしのIPv4ドメイン上のIPv6の伝達」、RFC 2529、1999年3月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]カーペンター、B。、「インターネット透明性」、RFC 2775、2000年2月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「ホストアイデンティティプロトコル（HIP）アーキテクチャ」、RFC 4423、2006年5月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P。、「IKEV2モビリティおよびマルチホームプロトコル（MOBIKE）」、RFC 4555、2006年6月。
[RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. Green, "IPv6 Enterprise Network Analysis - IP Layer 3 Focus", RFC 4852, April 2007.
[RFC4852] Bound、J.、Pouffary、Y.、Klynsma、S.、Chown、T。、およびD. Green、「IPv6エンタープライズネットワーク分析-IPレイヤー3フォーカス」、RFC 4852、2007年4月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（ISATAP）」、RFC 5214、2008年3月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[VA] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "FIB Suppression with Virtual Aggregation", Work in Progress, October 2009.
[VA] Francis、P.、Xu、X.、Ballani、H.、Jen、D.、Raszuk、R。、およびL. Zhang、「Virtual AggregationによるFIB抑制」、2009年10月の作業。
[VOGT] Vogt, C., "Six/One: A Solution for Routing and Addressing in IPv6", Work in Progress, October 2009.
[Vogt] Vogt、C。、「Six/One：IPv6でのルーティングとアドレス指定のためのソリューション」、2009年10月、進行中の作業。
[WHITTLE] Whittle, R., "Ivip (Internet Vastly Improved Plumbing) Architecture", Work in Progress, August 2008.
[Whittle] Whittle、R。、「IVIP（インターネットが大幅に改善された配管）アーキテクチャ」、2008年8月の作業。
[XBONE] Touch, J., "The X-Bone", March 1997, http://www.isi.edu/touch/pubs/ngi97/x-bone-ngi97.pdf
[Xbone] Touch、J。、「X-Bone」、1997年3月、http：//www.isi.edu/touch/pubs/ngi97/x-bone-ngi97.pdf
Author's Address
著者の連絡先
Fred L. Templin Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
フレッド・L・テンプリン・ボーイング・ファントム・ワークスP.O.ボックス3707 MC 7L-49シアトル、ワシントン州98124 USA
EMail: fltemplin@acm.org