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 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/rfc5720.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5720で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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].
レンジャーは、スケーラブルなルーティングおよびグローバル企業再帰有するネットワークに対処するためのアーキテクチャフレームワークです。この文脈内の用語「エンタープライズネットワーク」は、マルチのような複雑なように、アドホックネットワークなどの動的として、「企業」は、SOHOネットワーク限り小さくすることができるユースケースと展開シナリオ、多種多様に及びます組織の法人、またはグローバルインターネット自体と同じ大きさ。このようなネットワークは、スケーラビリティ、プロバイダ独立性、モビリティ、マルチホーミング、およびセキュリティのための宿泊施設で計画をルーティングおよびアドレッシングの調整のために体系化ソリューションが必要になります。これらの考慮事項は、既存の展開に特に当てはまるが、同じ原理がさえクリーンスレートアプローチのために適用されます。レンジャーアーキテクチャは、これらの要件に対処し、またのIPv6 / IPv4の共存[COEXIST]のための包括的なフレームワークを提供します。
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.
レンジャーは、一つ以上の組織グループを含む各個別のRLOC空間と、一つ以上の異なる内部IPルーティングおよびアドレス指定ドメイン（又は「ルーティングロケータ（RLOC）空間」）を含む企業の統合アーキテクチャを提供します。各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.
RANGERは、複数の企業に再帰的である各企業は、エッジ/コアの分離をサポートするために、EID空間から取られたアドレスを設定するノードとエッジネットワークを接続するネストされた「企業内・企業」様式で一緒に結合することができます。このように、再帰のより低いレベルに適用されるのと同じレンジャー原理は、グローバルインターネット自体のコアに最終的に親企業に上向きに延びることができ。具体的には、他のインターネットは「並行宇宙」として現れると再帰のさらに高いレベルで接合することができるかどうか - さらに、今日のグローバルなインターネットは、再帰のための制限条件を表しているかどうかも検討する価値があります。
The RANGER architecture is manifested through composite technologies, including Virtual Enterprise Traversal (VET) [VET], the Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL], and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]. Other mechanisms such as IPsec [RFC4301] are also in scope for use within certain scenarios.
RANGERアーキテクチャは、仮想エンタープライズトラバーサル（VET）[VET]、サブネットワークのカプセル化とアダプテーション層（SEAL）[SEAL]、およびプロトコル（ISATAP）をアドレス指定、サイト内の自動トンネル[RFC5214]を含む複合技術によって明示されます。このようにIPsec [RFC4301]などの他のメカニズムは、特定のシナリオ内で使用する範囲でもあります。
Noting that combinations with still other technologies are also possible, the issues addressed either in full or in part by RANGER include:
：まだ他の技術との組み合わせも可能であることに留意し、問題が含まRANGERで全額または一部のいずれかで対処しました
o scalable routing and addressing
Oスケーラブルなルーティングおよびアドレッシング
o provider-independent addressing and its relation to provider-aggregated addressing
Oプロバイダに依存しないアドレス指定およびプロバイダ凝集アドレッシングとの関係
o site mobility and multihoming
Oサイトのモビリティとマルチホーミング
o address and prefix autoconfiguration
Oアドレスとプレフィックスの自動設定
o border router discovery
O境界ルータの発見
o router/host-to-router/host tunneling
Oルータ/ホスト・ツー・ルータ/ホストトンネリング
o neighbor discovery over tunnels
トンネルを介しO近隣探索
o MTU determination for tunnels
トンネルのO MTU決定
o IPv6/IPv4 coexistence and transition
OのIPv6 / IPv4の共存と移行
Note that while this document primarily uses the illustrative example of IPv6 [RFC2460] as a virtual overlay over IPv4 [RFC0791] networks, it is important to note that the same architectural principles apply to any combination of IPvX virtual overlays over IPvY networks.
この文書は主にIPv4の[RFC0791]ネットワーク上の仮想オーバーレイとしてのIPv6 [RFC2460]の例示的な例を用いているが、同じアーキテクチャ原理がIPvYネットワーク上IPvX仮想オーバーレイの任意の組み合わせに適用されることに注意することが重要であることに留意されたいです。
Routing Locator (RLOC) an IPv4 or IPv6 address assigned to an interface in an enterprise-interior routing region. Note that private-use IP addresses are local to each enterprise; hence, the same private-use addresses may appear within disjoint enterprises.
ルーティングロケータ（RLOC）企業内部ルーティング領域内のインタフェースに割り当てられたIPv4またはIPv6アドレス。私的使用のIPアドレスが各企業に対してローカルであることに注意してください。したがって、同じプライベート使用アドレスがばらばらの企業の中に表示されることがあります。
Endpoint Interface iDentifier (EID) an IPv4 or IPv6 address assigned to an edge network interface of an end system. Note that EID space must be separate and distinct from any RLOC space.
エンドポイントインターフェイス識別子（EID）エンドシステムのエッジネットワークインタフェースに割り当てられたIPv4またはIPv6アドレス。 EIDスペースが任意のRLOC空間から独立した別個でなければならないことに注意してください。
commons an enterprise-interior routing region that provides a subnetwork for cooperative peering between the border routers of diverse organizations that may have competing interests. A prime example of a commons is the Default-Free Zone (DFZ) of the global Internet. The enterprise-interior routing region within the commons uses an addressing plan taken from RLOC space.
コモンズ競合する利益を有していてもよく、多様な組織の境界ルータ間の協調的ピアリングのためのサブネットワークを提供し、企業内部ルーティング地域。コモンズの典型的な例は、グローバルなインターネットのデフォルトフリーゾーン（DFZ）です。コモンズ内の企業内部ルーティング領域はRLOC空間から取られたアドレス計画を使用します。
enterprise the same as defined in [RFC4852], where the enterprise deploys a unified RLOC space addressing plan within the commons but may also contain partitions with disjoint RLOC spaces and/or organizational groupings that can be considered as enterprises unto themselves. An enterprise therefore need not be "one big happy family", but instead provides a commons for the cooperative interconnection of diverse organizations that may have competing interests (e.g., such as the case within the global Internet DFZ).
企業企業はコモンズ内計画をアドレッシング統一RLOC空間を展開だけでなく、自身かれ企業とみなすことができる互いに素RLOCスペースおよび/または組織のグループとのパーティションを含んでいてもよい[RFC4852]で定義と同じ。企業は、したがって、「一つの大きな幸せな家族」である必要はなく、代わりに競合する利害を有していてもよく、多様な組織（例えば、グローバルなインターネットDFZ内ケースなど）の協力の相互接続のためのコモンズを提供します。
Enterprise networks are typically associated with large corporations or academic campuses; however, the RANGER architectural principles apply to any network that has some degree of cooperative active management. This definition therefore extends to home networks, small office networks, ISP networks, a wide variety of Mobile Ad Hoc Networks (MANETs), and even to the global Internet itself.
エンタープライズネットワークは、典型的には、大企業や学術キャンパスに関連しています。しかし、RANGER建築の原則は、協同組合積極的な管理をある程度持っている任意のネットワークに適用されます。この定義は、それゆえ、さらにはグローバルなインターネット自体にホームネットワーク、小規模オフィスネットワーク、ISPのネットワーク、アドホックネットワーク（MANET）の多種多様に及びます。
site a logical and/or physical grouping of interfaces within an enterprise commons, where the topology of the site is a proper subset of the topology of the enterprise. A site may contain many interior sites, which may themselves contain many interior sites in a recursive fashion.
サイトサイトのトポロジーは、企業のトポロジーの適切なサブセットであるエンタープライズ・コモンズ内インターフェイスの論理的及び/又は物理的なグループ化。サイト自体は、再帰的な方法で多くの内部部位を含む可能性がある、多くの内部部位を含有してもよいです。
Throughout the remainder of this document, the term "enterprise" refers to either enterprise or site, i.e., the RANGER principles apply equally to enterprises and sites of any size or shape. At the lowest level of recursive decomposition, a singleton Enterprise Border Router can be considered as an enterprise unto itself.
この文書の残りの部分全体を通して、用語「企業」とは、企業またはサイトのいずれかを指す、すなわち、レンジャー原理は、企業や任意のサイズまたは形状の部位に等しく適用されます。再帰的な分解の最下位レベルでは、シングルトンエンタープライズ境界ルータは、それ自体が企業として考えることができます。
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は、オーバーレイネットワークへの直接接続されたネットワークを接続し、他のEBRsにコモン間でIP内IPトンネリングを経由して他のネットワークに接続します。この定義は、[VET]で定義された機能的用語「EBR」の建築等価物として意図されています。
Enterprise Border Gateway (EBG) an EBR that also connects the enterprise to provider networks and/or to the global Internet. EBGs are typically configured as default routers in the overlay and provide forwarding services for accessing IP networks not reachable via an EBR within the commons. This definition is intended as an architectural equivalent of the functional term "EBG" defined in [VET], and is synonymous with the term "default mapper" used in other contexts (e.g., [JEN]).
企業ボーダーゲートウェイ（EBG）もプロバイダーネットワークおよび/またはグローバルインターネットに企業を接続EBR。 EBGsは、一般的に、オーバーレイのデフォルトルータとして設定し、コモンズ内のEBRを経由して到達できないIPネットワークにアクセスするための転送サービスを提供しています。この定義は機能的な用語[VET]で定義された「EBG」の建築等価物として意図され、そして他の文脈で使用される用語「デフォルトマッピング」（例えば、[JEN]）と同義です。
Ingress Tunnel Endpoint (ITE) a host or router interface that encapsulates inner IP packets within an outer IP header for transmission over an enterprise-interior routing region to the RLOC address of an Egress Tunnel Endpoint (ETE).
入力トンネルエンドポイント（ITE）出口トンネルエンドポイント（ETE）のRLOCアドレスに企業内部ルーティング領域を介して送信するための外側の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アドレスに送信されたカプセル化パケットを受信したホストまたはルータインターフェイスが、最終目的地のEIDアドレスに配信し、次に、内側IPパケットをデカプセル化します。
overlay network a virtual network manifested by routing and addressing over virtual links formed through automatic tunneling. An overlay network may span many underlying enterprises.
オーバーレイ・ネットワークのルーティングおよび自動トンネリングを介して形成された仮想リンクを介してアドレス指定することによって明らかに仮想ネットワーク。オーバーレイネットワークは、多くの基礎となる企業をまたがることがあります。
Provider-Independent (PI) prefix an IPv6 or IPv4 EID prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) that is routable within a limited scope and may also appear in enterprise mapping tables. PI prefixes that can appear in mapping tables are typically delegated to a Border Router (BR) by a registry but are not aggregated by a provider network. Local-use IPv6 and IPv4 prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of a PI prefix, but these typically do not appear in mapping tables.
プロバイダ非依存（PI）は、IPv6またはIPv4 EIDプレフィクスを接頭語（例えば、2001：等DB8 :: / 48、192.0.2 / 24）限られた範囲内でルーティング可能であり、また、企業のマッピングテーブルに表示されてもよいです。マッピングテーブルに表示できるPIプレフィックスは、通常はレジストリによって境界ルータ（BR）に委譲されますが、プロバイダのネットワークによって集約されていません。局所使用のIPv6およびIPv4のプレフィックス（例えば、FD00 :: / 8、192.168 / 16等）PIプレフィックスの別の例であるが、これらは、典型的には、マッピングテーブルに表示されません。
Provider-Aggregated (PA) prefix an IPv6 or IPv4 EID prefix that is either derived from a PI prefix or delegated directly to a provider network by a registry. Although not widely discussed, it bears specific mention that a prefix taken from a delegating router's PI space becomes a PA prefix from the perspective of the requesting router.
プロバイダ凝集（PA）は、PIのプレフィックスに由来するか、またはレジストリで、プロバイダのネットワークに直接委譲されるかのIPv6またはIPv4 EIDプレフィクスを付けます。広く議論されていないが、それが委任するルータのPI空間から撮影したプレフィックスが要求ルータの観点からPAの接頭辞になるという具体的な言及を負いません。
Additionally, RANGER provides an informative consideration of functional specifications and operational practices outlined in other documents. These documents include:
さらに、RANGERは、機能仕様及びその他の書類に概説業務慣行の有益な配慮を提供します。これらの文書は、次のとおりです。
6over4 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels [RFC2529]; functional specifications and operational practices for automatic tunneling of unicast/multicast IPv6 packets over multicast-capable IPv4 enterprises.
明示的なトンネル[RFC2529]無しのIPv4ドメイン上のIPv6の6over4はトランスミッション。マルチキャスト対応の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）[RFC5214]をアドレッシングISATAPサイト内の自動トンネル。ユニキャストIPv4のみ企業上のユニキャストIPv6パケットの自動トンネリングのための機能仕様と運用方法。
VET Virtual Enterprise Traversal (VET) [VET]; functional specifications and operational practices for automatic tunneling of both unicast and multicast IP packets with provisions for address/prefix autoconfiguration, provider-independent addressing, mobility, multihoming, and security. VET is descended from both 6over4 and ISATAP and is also known as "ISATAP version 2 (ISATAPv2)".
VET仮想エンタープライズトラバーサル（VET）[VET]。アドレス/プレフィックスの自動設定のための規定にユニキャストとマルチキャストの両方のIPパケットの自動トンネリング、プロバイダに依存しないアドレス指定を、モビリティ、マルチホーミング、およびセキュリティのための機能仕様と運用実践。 VETは、6over4はISATAPとの両方から下降され、また、「ISATAPバージョン2（ISATAPv2）」として知られています。
SEAL Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL]; an encapsulation sublayer that provides an extended IP Identification field and mechanisms for link MTU adaptation over tunnels.
SEALサブネットワークカプセル化及びアダプテーションレイヤ（SEAL）[SEAL]。拡張IP識別フィールドと、トンネル上のリンクMTUの適応のためのメカニズムを提供するカプセル化サブレイヤ。
The RANGER architecture enables scalable routing and addressing in networks with global enterprise recursion while sustaining support for legacy networks and services. Key to this approach is a framework that accommodates interconnection of diverse organizations across a commons that have a mutual spirit of cooperation but also have the potential for competing interests. The following sections outline the RANGER architecture within the context of anticipated use cases:
RANGERアーキテクチャは、スケーラブルなルーティングを可能にし、従来のネットワークとサービスのサポートを維持しながら、グローバル企業の再帰とネットワークで取り組みます。このアプローチの鍵は、協力の相互の精神を持っているだけでなく、競合する利益の可能性を持っていコモンズ渡って多様な組織の相互接続を収納するフレームワークです。次のセクションでは、予想されるユースケースのコンテキスト内RANGERアーキテクチャの概要を説明。
The Internet today is facing "growing pains", with indications that core Routing Information Base (RIB) scaling may not be sustainable over the long term and that the remaining space for IPv4 address allocations may be depleted in the near future. Therefore, there is an emerging need for scalable routing and addressing solutions. It must further be noted that the same solutions selected to address global Internet routing and addressing scaling can apply equally for large enterprises -- or for any enterprise that would benefit from a separation of core and edge addressing domains.
インターネット今日は、コアルーティング情報ベース（RIB）スケーリングが長期的に持続可能であるとIPv4アドレス割り当ての残りのスペースは、近い将来に枯渇することができるものではないことを指摘して、「成長の痛み」を、直面しています。したがって、スケーラブルなルーティングおよびアドレッシングソリューションのための新たなニーズがあります。またはドメインをアドレッシングコアおよびエッジの分離から利益を得る任意の企業のために - さらに、グローバルインターネットルーティングに対処するために選択したのと同じ溶液及びアドレッシングスケーリングは大企業にも同様に適用することができることに留意しなければなりません。
RANGER supports scalable routing through an approach that parallels the "New Scheme for Internet Routing and Addressing" described in [RFC1955]. This approach is also commonly known as "map-and-encaps". In this approach, an Ingress Tunnel Endpoint (ITE) that must forward an IP packet first consults a mapping system to discover a mapping for the destination Endpoint Interface iDentifier (EID) to a Routing LOCator (RLOC) assigned to an Egress Tunnel Endpoint (ETE). The mapping system is typically maintained as a per-enterprise distributed database that is synchronized among a limited set of mapping agents. Distributed database management alternatives include a routing protocol instance maintained by Enterprise Border Gateways (EBGs), a DNS reverse zone distributed among a restricted set of caching servers, etc. Mapping entries are inserted into the mapping system through administrative configuration, automated prefix registrations, etc.
RANGERは、[RFC1955]で説明した「新しいインターネットルーティングのためのスキームとアドレス指定を」平行アプローチを通じてスケーラブルなルーティングをサポートしています。このアプローチは、一般に「マップ・アンド・ENCAPS」として知られています。このアプローチでは、IPパケットを転送しなければならない入力トンネルエンドポイント（ITE）は、第一（ETEを退出トンネルエンドポイントに割り当てられたルーティングロケータ（RLOC）に宛先エンドポイント・インタフェース識別子（EID）のマッピングを発見するためのマッピングシステムを参照します）。マッピング・システムは、典型的には、マッピングエージェントの限られたセット間で同期されるごと企業分散データベースとして維持されます。分散データベース管理の選択肢は等、マッピング・エントリが管理構成を介してマッピング・システムに挿入される等、自動プレフィックス登録をエンタープライズボーダーゲートウェイ（EBGs）、キャッシングサーバの制限されたセットの中に分散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は、マッピングシステム自体を参照してください（最初のIPパケットを遅延または滴下しながら）、または「デフォルト・マッパー」として機能するEBGに初期パケットを転送のいずれかにITEすることができます。いずれの場合においても、ITEは、その転送情報ベース（FIB）を移入するために使用できるマッピング応答を受信します。マッピング手法の選択は、個々の企業のネットワークシナリオに関して考慮しなければならないITE自己発見は、他でより適切であり得るが、例えば、EBGへの転送は、いくつかのシナリオで、より適切であるかもしれません。他のマッピング機構を使用することは、特定の企業のシナリオに従っても可能です。
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はETEのRLOCアドレスにコモン横切って伝送するための外側IPヘッダに内側IPパケットをカプセル化します。順番にETEは、パケットのカプセル化を解除し、最終目的地のEIDアドレスに向けて次のホップの上にそれらを転送します。したがって、ルーティング情報ベース（RIB）コモンズ内のみ同期EID対RLOCマッピング状態は、ノードの小さな数で維持され、リンクによる振動を受けないでいる間、のRLOCとしないのEIDに関する状態を維持する必要がありますコモンズ内の状態が変化します。最後に、のEIDのみ（限定場合にノードローカルスコープのように小さくてもよい）エッジネットワーク内の限られた範囲内でルーティング可能です。
RANGER supports scalable addressing by selecting a suitably large EID addressing range that is distinct and kept separate from any enterprise-interior RLOC addressing ranges. It should therefore come as no surprise that taking EID space from the IPv6 addressing architecture should lead to a viable, scalable addressing alternative, while taking EID space from the (already exhausted) IPv4 addressing architecture may not.
レンジャーは別個であり、任意の企業内部RLOCアドレッシング範囲別に保持好適大EIDアドレッシング範囲を選択することによって対処スケーラブルサポート。したがって、ないかもしれません（すでに疲れ）のIPv4アドレス体系からEIDスペースを取りながら、IPv6のアドレス体系からEIDスペースを取ることは、実行可能な、拡張性のある対処する代替につながるべきであることは驚くことではありません。
Enterprise networks traditionally distribute routing information via Interior Gateway Protocols (IGPs) such as Open Shortest Path First (OSPF), while large enterprises may even use an Exterior Gateway Protocol (EGP) internally in place of an IGP. Thus, it is becoming increasingly commonplace for large enterprises to use the Border Gateway Protocol (BGP) internally and independently from the BGP instance that maintains the RIB within the global Internet DFZ.
大企業でも内部IGPの代わりに、外部ゲートウェイプロトコル（EGP）を使用するかもしれないが、企業のネットワークは、伝統的に、このようなオープンショーテストパスファースト（OSPF）などの内部ゲートウェイプロトコル（のIGP）を経由してルーティング情報を配布します。大企業は、グローバルインターネットDFZ内RIBを維持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.
このように、大企業は、多くの内部自律システム間（お尻）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は、企業を示す「E1」、グローバルインターネットに接続する「EN」を介して「Rnの」および追加の企業のE2 'を介してルータR1「」を介してグローバルIPv6 / IPv4インターネットに接続されています。 「E1」コモンズ内に、任意の数のホスト、ルータ、およびRLOC空間から、両方のカプセル化及び非カプセル化IPパケットを転送することができる引き継いアドレスを使用するネットワーク（図示せず）があってもよいです。また、多くの下位層の企業は、「X1」を通るように示されている（図に示す）「E1.m」、エンタープライズ境界ルータを介して、「E1」コモンズ内のその相互接続（EBRs）、スルー「E1.1」が存在してもよいです'X9'（ 'X9' を介して 'X1' はEBGsとして 'Rnを' を介して 'R1' を参照）。各「E1。*」企業内で、また、その内配線任意の多くの下位層の企業が存在してもよい「E1。*」図（「Y1」を介して「Y9」から「Y1」として示さEBRs介しコモンズ、 '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空間から取られたアドレスを持つ任意の複雑なエッジネットワークを取り付けるEBRsであってもよいことに留意することが重要です。このようなエッジネットワークは、レジデンシャルゲートウェイの背後にあるか、などの主要企業/学術キャンパス、大規模なサービスプロバイダのネットワーク、のような複雑なホームネットワークのような単純なものでした
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.
再び、この企業内のエンタープライズフレームワークは、再帰として広く深く所望のように入れ子にすることができます。再帰の最高レベルから、グローバルインターネット自体が全てRANGER建築原理はそのコンテキスト内でも同様に適用するようにENを介して下部層の企業E1を相互接続する「企業」とみなすことができることを今考えます。また、レンジャーアーキテクチャは、グローバルインターネットは再帰のために制約条件を表すのではなく、他のインターネットは「平行宇宙」として現れると再帰のより高いレベルで一緒に結合することができることを可能にする必要はないことを認識する。
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]の下で、示されているとおりに、すなわち、それ自体がインターネットのように見える大規模な企業ネットワークの形をとるだろうATNの中で、図1の「E1」のため、「E1用に示されているとおりに、多くの航空通信サービスプロバイダー（ACSP）とエアナビゲーションサービスプロバイダATNへの内部自律システムとして組織化（ANSP）ネットワーク、すなわちがあるでしょう。 *」ダイアグラムインチACSP / ANSPネットワークEBGsはATN内部BGPインスタンスに参加する、そしてそれ自体がさらにあり、その内部に独立したBGPインスタンスを実行することができるサブ分割領域、組織、機能、等区画として編成下部層の企業に。 ATN内ACSPs / ANSPsは、それらの間のビジネス/政治/社会的な利害が競合することができる、安全の飛行民間航空サービスのための共通の目的を共有する一方、ATNは必ずしもならないように、それを注意することが重要です「一つの大きな幸せな家族」。したがって、モデルは、グローバルなインターネット自体のそれに匹敵します。
Such an operational framework may indeed be the case for many next-generation enterprises. In particular, although the routing and addressing arrangements of all enterprises will require a mutual level of cooperative active management at a certain level, free market forces, business objectives, political alliances, etc. may drive internal competition.
そのような動作フレームワークは、実際、多くの次世代企業の場合であってもよいです。すべての企業のルーティングおよびアドレッシング配置が一定のレベルで協力アクティブな管理の相互のレベルが必要になりますが、特に、自由市場の力、ビジネス目標、政党連合などは、内部の競争を駆動することができます。
Within the enterprise-within-enterprise framework outlined in Section 3.2, the RANGER architecture is based on overlay networks manifested through Virtual Enterprise Traversal (VET) ([VET], [RFC5214]). The VET approach uses automatic IP-in-IP tunneling in which ITEs encapsulate EID-based inner IP packets within RLOC-based, outer IP headers for transmission across the commons to ETEs.
セクション3.2に概説エンタープライズ内のエンタープライズフレームワーク内で、レンジャーアーキテクチャは、仮想エンタープライズトラバーサル（VET）（[VET]、[RFC5214]）を介して現れるオーバーレイネットワークに基づいています。 VETアプローチはITESはETESにコモン横切って伝送するためのRLOCベース、外側IPヘッダ内のEIDベースの内側IPパケットをカプセル化した自動IPイン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.
彼らはに接続各企業のために、VETを使用EBRsは、内部の観点から潜在的なシングルホップ隣人として、企業内の他のすべてのEBRsを見る「VETインタフェース」として知られる非放送、多重アクセス（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「+ 1」に転送される前に、VETインタフェース「i」は、次いでデカプセル化さを出るパケットは、再カプセル化する「再カプセル化」アプローチを伴います。例えば2 EIDベースのピアとの間のエンドツーエンドパスがN別個VETインタフェースを横切る場合、トレースルートを示すであろうNインナーIP転送はVETインターフェースを横切るパスの部分に対応するホップ。
VET and its related works specify necessary mechanisms and operational practices to manifest the RANGER architecture. The use of VET in conjunction with SEAL (see Section 3.4) is essential in certain deployments to avoid issues related to source address spoofing and black holing due to path Maximum Transmission Unit (MTU) limitations. (The use of VET in conjunction with IPsec [RFC4301] may also be necessary in some enterprise network scenarios.) The following sections discuss operational considerations and use cases within the VET approach.
VETとその関連作品はRANGERアーキテクチャをマニフェストに必要なメカニズムと運用実務を指定します。 SEALと一緒にVETの使用は（3.4節を参照）により、パス最大転送単位（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:
図1に示されている企業内のエンタープライズ・フレームワークから（水平に表されるが）図2は、以下の垂直スライスを示します。
+------+
| 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のインターフェースによって張られます。このフレームワーク内の各VETインタフェースは、同じ企業内のすべてのEBRsを接続非放送、多重アクセス（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は、上部層の企業に接続EBGsとそのEIDプレフィクスを調整します。 EIDプレフィクスは、EBRまたはプロバイダ凝集EBGによって委任（PA）プレフィックスが所有者に依存しない（PI）プレフィックスのいずれかとすることができます。いずれの場合においても、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' と、順番に委譲する「2001：DB8 :: Y1から '/ 52' '、ひいては代議員の '2001：DB8 :: V '' に' / 56。この再帰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.
主張する企業内EBGsに、ルータ広告（RA）メッセージを送信することにより、PIのEIDプレフィックスを使用する場合には、個々のEBRs（例えば、 'V'）は、そのPIの接頭辞（例えば、 '10 :: / 56：DB1 2001'）に登録しますプレフィックスの所有権。強力な認証が必要な場合、EBRsは、デジタルセキュア近隣探索（SEND）[RFC3971]に指定されたメカニズムを使用してメッセージに署名することができます。 RAを受信EBGs（例えば、「Y1」）は、まず、送信側の証明書を検証するエンタープライズ・マッピング・システムにおけるプレフィックスを登録します。次に、彼らは、親企業内EBGs（例えば、「X2」）にRAのプロキシバージョンを転送します。デフォルトフリーコモンズに到達するまで、このプロキシプロセスは、再帰的な階層をアップし続けています。 （この場合には、プロキシ処理は、「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では、深くエンタープライズ「E1」内にネストされたIPv6ホスト「H」は、IPv6インターネット上のどこかに位置するのIPv6サーバー「S1」に接続されています。 '0：：：DB8 2001 0 :: / 64' 'H' がIPv6プレフィックスを通知したIPv6 / IPv4デュアルスタックルータ 'V' と共有リンクに接続されており、「2001：DB8：10：0 :: / 64' 。 「H」は、ローカルリンク外のパケットを転送することができ、デフォルトのIPv6ルータとして「V」を発見するために、標準のIPv6近隣探索メカニズムを使用し、アドバタイズされるプレフィクスの両方からのアドレスを設定します。今度は「V」はVETインタフェースを介して到達可能であるEBG「vet1」とノード「Y1」を見て、それは、IPv6サーバー「S1」に向かってパケットを転送することができます。同様に、ノード「Y1」はEBGとして「X2」を見「vet2」、およびノード「X2」が及ぶ企業にEBRはEBGとして「R2」を見「vet3」にEBRです。最終的に、「R2」は、グローバルインターネットに「E1」を接続するEBRです。
In the example shown in Figure 2, 'V', 'Y1', 'X2', and 'R2' configure separate VET interfaces for each enterprise they connect to in order to discover routes through a dynamic routing protocol and/or mapping database lookups. After tunnels 'vet1' through 'vet3' are established, the EBRs connected to a VET interface can run a dynamic routing protocol such as OSPVFv3 [RFC5340] and exchange topology information over the VET interface using the NBMA interface model. In this way, each EBR can discover other EBRs on the link via routing protocol control message exchanges.
図2に示す例では、「V」、「Y1」、「X2」、及び「R2」はダイナミックルーティングプロトコルおよび/またはマッピングデータベース検索を介して経路を発見するために、それらが接続各企業のための別個のVETインターフェイスを設定します。 「vet3」を介してトンネル「vet1」が確立された後、VETインターフェースに接続EBRsは、OSPVFv3 [RFC5340]とNBMAインタフェースモデルを使用して、VETインタフェースを介して交換トポロジ情報などの動的ルーティングプロトコルを実行することができます。このように、各EBRは、ルーティングプロトコル制御メッセージ交換を介して、リンク上の他のEBRsを発見することができます。
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.
この例では、トンネルインターフェイス 'vet1「vet4」を介して、ならびにIPv6のPIプレフィックス登録はVET企業の自動設定手順を介して確立されています。 IPv6のエンドシステムのIPv6アドレスを「H」とき「2001：DB8：10 :: 1」「：DB8：2001 20 :: 1」ピアエンドシステムのIPv6アドレスを持つ「J」にパケットを送信し、パケットが通って搬送されますデフォルトルートを経由して、最終的に「X2」から「V」、「Y1」。 「X2」はIPv6のFIBエントリマッチング「J」を有している場合を除き、その後、それは「J」が「E1」コモンズ横切って次のホップとして「X7」を介してより直接的な経路を用いて到達できることを発見しなければなりません。
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」インターフェイス上でパケットを受信した場合、特に、それがDNS逆ゾーンを調べることによって、例えば、エンタープライズ・マッピング・サービスを参照することにより、オンデマンドマッピングのルックアップを行うことができます。あるいは、「X2」は今度は「X7」にパケットを転送し、ICMPv6のメッセージをリダイレクト返すことができ、デフォルトのルータ（例えば、「R2」）にパケットを送信することができます。 「X2」は、リダイレクトを受信すると、送信元アドレス「J」を一致する接頭辞でパケットを生成するために許可されていることを証明するために「X7」にRAメッセージを送信することができます。 「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.
前RANGER展開で既に存在していたと、既にRLOCアドレスとそのインタフェースの番号が付けられているレガシーホスト、ルータ、およびネットワークは、EIDベースのサービスは、新しいで展開されたとしても、長期的にRLOCベースのサービスのための継続的なサポートを見なければなりません展開。例えば、IPv4のネットワークアドレス変換（NAT）の背後にあるレガシーIPv4のみのノードには、まだ長いRANGERアーキテクチャとEID後レガシー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は、以下VETインタフェースが再帰的にネストされた企業を一緒にリンクするために使用されているレンジャーアーキテクチャに適用RLOCベースのIPv4サービスアクセスシナリオを描いています。
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) -----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +--- + v +----+ v +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ t +----+ +-----+-------+
" . | 1 . . 2 . . 3 . " |
" . K L . . . . M . " |
" . . . . . . . . . . . . . . " +--+---+
" <E1.1.1> <E1.1> <E1> " | IPv4 |
" " |Server|
" " " " " " " " " " " " " " "" " " " " " " " | S2 |
<-- Enterprise E1 --> +------+
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' コモンズ。多くの場合、これは確かにEIDベースのIPv6サービスが広く起因等のレガシーIPv4アプリケーションを交換することができない、IPv6ヘッダのオーバーヘッド回避、などの要因にデプロイされた場合であっても、好適なサービス・アクセス・モデルであってもよいです
In a second instance, RLOC-based IPv4 client 'K' can access RLOC-based IPv4 server 'S2' on the legacy global IPv4 Internet in a number of ways, based on the way the recursively nested 'E1.*' enterprises are provisioned:
第二の例では、RLOCベースのIPv4クライアント「K」の方法を再帰的にネストに基づいて、いくつかの方法でグローバルなIPv4インターネットレガシーにRLOCベースのIPv4サーバS2「」にアクセスすることができます「E1。*」企業がプロビジョニングされています：
o if all of the recursively nested 'E1.*' enterprises are configured within the same IPv4 RLOC space, normal IPv4 forwarding will convey unencapsulated IPv4 packets from 'K' toward 'R2', which then acts as an IPv4 Network Address Translator (NAT) and/or an ordinary IPv4 Enterprise Border Router.
O再帰的にネストされたすべての「E1。*」企業が同一のIPv4 RLOC空間内に構成され、通常のIPv4転送は（NATをその後のIPv4ネットワークアドレストランスレータとして働く「R2」に向かって「K」からカプセル化されていないIPv4パケットを伝達する場合）、および/または通常の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'.
「X2」、再帰的にネストされた「E1。*」企業がばらばらRLOC空間内に構成されている場合、全てEBGs「Y1」O、及び「R2」はIPv4のNAT機能内のNATの（すなわち、再帰的な入れ子を提供するように構成することができますNATを）。しかし、このアプローチは、ルーティングの変更に脆性と不寛容の全体的な程度につながることができますパス上のステートフルNATデバイスの複数のインスタンスを配置します。その代わりに、「R2」はIPv4にインのIPv6インのIPv4トンネリングを使用CGNに「K」からのパケットを伝達することができる「キャリアグレードNAT（CGN）」、及び「V」として作用することができます。 CGNは、次いで、内側、RLOCベースIPv4パケットをデカプセル化し、「S2」上にパケットを送信する前に、グローバルIPv4ソースアドレスにIPv4ソースアドレスを変換することができます。
o 'K' could be configured as an EID-based, IPv6-capable node and use standard IPv6 routing to reach an IPv6/IPv4 translator located at an EBR for the enterprise in which 'S2' resides. The translator would then use IPv6-to-IPv4 translation before sending packets onwards toward 'S2'. These and other alternatives are discussed in [WING].
O「K」がEIDベース、IPv6対応のノードとして構成され、「S2」存在する企業のためにEBR位置のIPv6 / IPv4トランスレータに到達するために、標準的なIPv6ルーティングを使用することができます。翻訳者は、その後、「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空間上に構成されている場合、しかし、「K」は、依然として、EIDベースのIPv4オーバーレイが展開された場合EIDベースのIPv4サービスを使用することによって、EIDベースのIPv6サービスを使用して、「M」にアクセスすることができるであろうまたはRLOCベースのIPv4 NATトラバーサルのいくつかのフォームを使用します。 「V」と「X2」の両方がIPv6 / IPv4のプロトコル変換機能を実装した場合に「K」は「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.
サブネットワークのカプセル化及びアダプテーションレイヤ（SEAL）規定そのトンネルエンドポイントは、オフパスなりすましを検出するためのナンスとして使用できる単調にインクリメント、拡張識別フィールド（すなわち、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ノマディック企業とエンドシステムは、新しい企業ネットワークアタッチメントポイント間を移動するように、アドレスリナンバリングイベントが発生するように満たすことができます。
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.
ノマディックエンタープライズモビリティは、すでに現在展開技術によって満たされています。例えば、ホームネットワークLANへの無線アクセスのホットスポットからのラップトップコンピュータを輸送することは遊牧民のデバイスがアドレスリナンバリングを犠牲にして接続を再確立することができるようになります。このようなリナンバリングは特にモビリティイベント全体セッションの永続性を必要とせず、グローバル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.
特に、移動性管理ソリューションの不測の事態が必ずしも相互に排他的ではなく、具体的な使用例に関連して考慮されなければならないことに留意すべきです。 RANGERアーキテクチャは、したがって、この点で自然に包括的です。特に、RANGERは、過度の解約を生じさせることなく、PIプレフィックスマッピングの急速な動的更新をサポートできるメカニズムから利益を得ることができます。
As with mobility management, multihoming use cases must be considered along multiple vectors. Within an enterprise, EBRs can discover multiple EBGs and use them in a fault-tolerant and load-balancing fashion as long as they register their PI prefixes with each such EBG, as described in Section 3.3.1. These registrations are created through the transmission of Router Advertisement messages that percolate up through the recursive enterprise-within-enterprise hierarchy.
モビリティ管理と同様に、マルチホーミングのユースケースは、複数のベクトルに沿って考えなければなりません。企業内では、EBRsは、複数のEBGsを発見することができ、彼らはそれぞれ、このようなEBGとのPIプレフィックスを登録すると、セクション3.3.1で説明したように、限り、フォールトトレラントとロードバランシングの方法でそれらを使用しています。これらの登録は、再帰的な企業内・企業階層をアップ浸透ルータアドバタイズメントメッセージの送信を介して作成されます。
As a first case in point, consider the enterprise network of a major corporation that obtains services from a number of ISPs. The corporation should be able to register its PI prefixes with all of its ISPs, and use any of the ISPs for its Internet access services.
ポイントの最初のケースとして、ISPの数からサービスを取得し、大企業の企業ネットワークを考えます。企業はそのISPのすべてとそのPIプレフィックスを登録し、そのインターネット接続サービスのためのISPのいずれかを使用することができるはずです。
As a second use case, consider an aircraft with a diverse set of wireless links (e.g., VHF, 802.16, directional, SATCOM, etc.). The aircraft should be able to select and utilize the most appropriate link(s) based on the phase of flight and to change seamlessly between links as necessary. Other examples include a nomadic laptop with both 802.11 and Ethernet links, a wireless handset with both CDMA wireless and 802.11, etc.
第二のユースケースとして、無線リンク（例えば、VHF、802.16、指向、SATCOM、等）の多様なセットを有する航空機を考えます。航空機は選択と飛行の位相に基づいて、最も適切なリンク（複数可）を活用し、必要に応じてリンクの間をシームレスに変更することができるはずです。他の例としては、など、両方の802.11とイーサネットのリンクを持つ遊牧民のラップトップ、CDMAの無線と802.11の両方を持つ無線ハンドセットを含み、
As with mobility management, the contingency of solutions is not necessarily mutually exclusive and can combine to suit use cases within the scope of the RANGER architecture.
モビリティ管理と同様に、ソリューションの不測の事態は、必ずしも相互に排他的ではなく、RANGERアーキテクチャの範囲内でのユースケースに合わせて組み合わせることができます。
Selection of mapping alternatives may have significant implications for applications, server selection, route determination, security, etc. In particular, applications that expect all packets (including initial ones) to experience similar delays may be adversely affected by a scheme that imposes non-negligible delays when initial packets are queued while a look-aside mapping table is consulted. Still other applications may experience significant startup delays when its initial packets are dropped during a mapping lookup event. These factors would seem to favor a scheme that is able to forward initial packets along a path with sub-optimal delay while a mapping lookup is performed in parallel, e.g., such as when a "default mapper" is used.
マッピングの選択肢の選択は（初期のものを含む）すべてのパケットが同様の遅延が発生することを期待するアプリケーションに悪影響を無視できない課しスキームによって影響を受ける可能性があり、特になど、アプリケーション、サーバ選択、ルート決定、セキュリティのために重要な意味を持っていることルックアサイドマッピングテーブルが参照されている間、最初のパケットがキューイングされている遅延。その最初のパケットがマッピング検索イベント中にドロップされたとき、さらに他のアプリケーションは、重要なスタートアップの遅延が発生することがあります。これらの要因は、マッピングルックアップが、そのような「デフォルトマッピング」が使用される場合として、例えば、並列に行われている間、最適遅延を有する経路に沿って最初のパケットを転送することができる方式を好むように思われます。
Generally speaking, proactive mapping-maintenance mechanisms may have scaling issues with the amount of updates they generate, while reactive mechanisms may involve effects to the delay of initial packets before the cached state is updated. Also to be considered are attacks against the mapping mechanism, which may result in denial of service of the mapping cache.
キャッシュされた状態が更新される前に、反応のメカニズムは、最初のパケットの遅延に影響を伴うことながら、一般的に言って、積極的なマッピング・メンテナンス・メカニズムは、彼らが発生するアップデートの量の問題をスケーリングした可能性があります。また、考慮すべきマッピングキャッシュのサービス拒否が発生する可能性がある、マッピングメカニズムに対する攻撃です。
Encapsulation of packets in automatically created tunnels involves a number of issues as well. There are obvious interactions between encapsulation overhead and the effective tunnel MTU, which can be addressed by SEAL and (when necessary) careful operational link arrangements. Moreover, it is important to minimize the impact to the global routing table without at the same time impacting the ability of legacy Internet networks to connect to those employing RANGER. As long as other nodes in the Internet need to connect to networks implementing RANGER, EID routes need to appear both in the mapping system and the global BGP routing tables. This can be accommodated by keeping the number of prefixes aggregated by RANGER to the bare minimum through efficient aggregation (e.g., one or a few [PREF]::/4 IPv6 prefixes instead of millions of [PREF]::/32 prefixes).
自動的に作成されたトンネル内のパケットのカプセル化は、同様に多くの問題を含んでいます。カプセル化オーバーヘッドとシールと（必要なとき）することによって対処することができる効果的なトンネルMTU、慎重な運用リンクの手配間の明確な相互作用があります。また、同時にRANGERを用いるものに接続する従来のインターネットネットワークの能力に影響を与えることなく、グローバルルーティングテーブルへの影響を最小限に抑えることが重要です。限り、インターネット内の他のノードは、RANGERを実装するネットワークに接続する必要があるように、EID経路がマッピングシステムとグローバルBGPルーティングテーブルの両方を表示する必要があります。これは、（代わりに[PREF] :: / 32プレフィックスの数百万の、例えば、一つまたは[PREF]いくつか:: / 4 IPv6プレフィックス）効率的な凝集を介して最低限にRANGERによって集約プレフィクスの数を維持することによって対応することができます。
The origins of the RANGER architectural principles can be traced to the "Catenet model for internetworking" ([CATENET], [IEN48], [RFC2775]) beginning as early as the mid-1970's. Subsequently, deliberations of the ROAD group [RFC1380] and related efforts such as NIMROD [RFC1753] provided a sustained evolution of the concepts. [RFC1955], "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", captures the high-level architectural aspects of the ROAD group deliberations.
RANGER建築の原則の起源は、早ければ1970年代半ばとして始まる（[CATENET]、[IEN48]、[RFC2775]）を「インターネットワーキングのためCATENETモデル」に遡ることができます。続いて、そのようなNIMROD [RFC1753]としてROAD基[RFC1380]および関連する努力の審議は、概念の持続的な発展をもたらしました。 [RFC1955]は、「新しいインターネットルーティングのためのスキームとIPNGについて（ENCAPS）のアドレッシングは」ROADグループの審議の高レベルのアーキテクチャの側面をキャプチャします。
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-骨イニシアチブ[XBONE]、など、より多くの最近の進展を、影響を受けました。様々なトンネリングが（[RFC2003]、[RFC4213]）、6over4は[RFC2529]で-IP IP-、および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]、シックス・ワン[VOGT]、ILNP [ILNP]、インターネット大幅に改善された配管（Ivip）[削る]、実用Transit-含め、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によって想定されるネットワーク・オブ・ネットワークモデルに印象的な似ています。 RANGERは、さらに、他の多くのアプローチはどちらか見落としや将来の仕事のために残されているなどの自動設定、プロバイダに依存しないアドレス指定を、境界ルータの発見、トンネルMTU、マルチホーミング、など困難な問題の詳細な検討を提供します。様々なユースケースシナリオでレンジャー適用性の詳細な分析は、「レンジャーシナリオ（レンジャーズ）」[ラサート]で提供されます。
Communications between endpoints within different sites inside an enterprise are carried across a commons that joins organizational entities with a mutual spirit of cooperation, but between which there may be competing business/sociological/political interests. As a result, mechanisms that rely on feedback from routers on the path may become brittle or susceptible to spoofing attacks. This is due to the fact that IP packets can be lost due to congestion or packet-filtering gateways and that the source addresses of IP packets can be forged. Moreover, IP packets in general can be generated by anonymous attackers, e.g., from a rogue node within a third-party enterprise that has malicious intent toward a victim.
企業内の異なるサイト内のエンドポイント間の通信は、協力の相互の精神と組織エンティティを結合コモンズ渡って行われているが、それらの間に競合するビジネス/社会学/政治的利益があるかもしれません。結果として、経路上のルータからのフィードバックに依存しているメカニズムは、スプーフィング攻撃に脆い又は感受性となることができます。これは、IPパケットが輻輳やパケットフィルタリングゲートウェイにし、IPパケットの送信元アドレスは偽造できることに失われる可能性があるという事実によるものです。また、一般にIPパケットが犠牲者に向けて悪意を持っているサードパーティ企業内不正なノードから、例えば、匿名の攻撃者によって生成することができます。
Path MTU Discovery is an example of a mechanism that relies on ICMP feedback from routers on the path and, as such, is susceptible to these issues. For IPv4, a common workaround is to disable Path MTU Discovery and let fragmentation occur in the network if necessary. For IPv6, lack of fragmentation support in the network precludes this option such that the mitigation typically recommended is to discard ICMP messages that contain insufficient information and/or to operate with the minimum IPv6 path MTU. This example extends also to other mechanisms that either rely on or are enhanced by feedback from network devices; however, attack vectors based on non-ICMP messages are also subject for concern.
パスMTU探索のような、経路上のルータからICMPのフィードバックに依存する機構の一例であり、これらの問題の影響を受けやすいです。 IPv4の場合、一般的な回避策は、パスMTUディスカバリを無効にし、必要に応じて断片化はネットワーク内で発生させることです。 IPv6の場合、ネットワーク内の断片化サポートの欠如は、典型的には推奨緩和が不十分な情報を含むICMPメッセージを破棄し、および/または最小のIPv6パスMTUで動作するように、このオプションを排除します。この例では、いずれかに依存して、またはネットワークデバイスからのフィードバックにより増強される他の機構にも延びています。しかし、非ICMPメッセージに基づいて攻撃ベクトルも懸念の対象となっています。
The RANGER architecture supports effective mitigations for attacks such as distributed denial-of-service, traffic amplification, etc. In particular, when VET and SEAL are used, EBGs can use the 32-bit identification encoded in the SEAL header as well as ingress filtering to determine if a message has come from a topologically correct enterprise located across the commons. This allows enterprises to employ effective mitigations at their borders without the requirement for mutual cooperation from other enterprises. When source address spoofing by on-path attackers located within the commons is also subject for concern, additional securing mechanisms such as tunnel-mode IPsec between enterprise EBGs can also be used.
VETシールが使用される場合レンジャーアーキテクチャは、特にこのような分散サービス拒否、トラフィック増幅、等の攻撃のための効果的な緩和策をサポートし、EBGsは、32ビットシールヘッダに符号化された識別と同様にイングレスフィルタリングを使用することができメッセージは、コモン向かいトポロジー的に正しい企業から来たかどうかを決定します。これは、企業が他の企業からの相互協力を必要とせずに、その境界で効果的な緩和策を採用することができます。コモンズ内に位置するオン・パス攻撃者によって送信元アドレススプーフィングも懸念の対象である場合、そのような企業EBGs間のトンネル・モードのIPsecなどの追加の固定機構を使用することもできます。
EBRs can obtain PI prefixes through arrangements with a prefix delegation authority. Thereafter, the EBR can announce and/or withdraw the prefixes within an enterprise by sending IPv6 Router Advertisements (RAs). In environments where additional authenticating mechanisms are necessary, the EBR can sign its RAs using SEcure Neighbor Discovery (SEND) [RFC3971].
EBRsはプレフィックス委任権限を持つ契約を通じてPIプレフィックスを取得することができます。その後、EBRは、アナウンス及び/またはIPv6ルータ広告（RAS）を送信することにより、企業内のプレフィクスを撤回することができます。追加の認証メカニズムが必要である環境では、EBRは、セキュア近隣探索（SEND）[RFC3971]を使用してのRAに署名することができます。
While the RANGER architecture does not in itself address security considerations, it proposes an architectural framework for functional specifications that do. Security concerns with tunneling, along with recommendations that are compatible with the RANGER architecture, are found in [HOAGLAND].
RANGERアーキテクチャ自体はセキュリティ上の考慮事項に対応していませんが、それはやる機能仕様のためのアーキテクチャフレームワークを提案しています。トンネリングとセキュリティ上の懸念は、RANGERアーキテクチャと互換性のある勧告に沿って、[ホーグランド]に記載されています。
This work was inspired through the encouragement of the Boeing DC&NT network technology team and through the communications of the IESG.
この作品は、ボーイングDC＆NTネットワーク技術チームの激励を通って、IESGのコミュニケーションを通じて触発されました。
Many individuals have contributed to the architectural principles that form the basis for RANGER over the course of many years. The following individuals have given specific feedback on the RANGER document itself: Jari Arkko, Brian Carpenter, Eric Fleischman, Joel Halpern, Thomas Henderson, Steven Russert, Dallas Thomas, Robin Whittle.
多くの個人は、長年にわたってRANGERのための基礎を形成する建築原則に貢献してきました。ヤリArkko、ブライアン・カーペンター、エリックFleischman、ジョエル・ハルパーン、トーマス・ヘンダーソン、スティーブン・ラサート、ダラス・トーマス、ロビンWhittleさん：以下の個人はRANGERドキュメント自体に固有のフィードバックを与えています。
[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月。
[CATENET] Pouzin, L., "A Proposal for Interconnecting Packet Switching Networks", Proceedings of EUROCOMP, Bronel University, p. 1023-1036, May 1974.
[CATENET]プザン、L.、 "パケット交換ネットワークを相互接続するための提案"、EUROCOMP、Bronel大学、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.
[COEXIST] 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]バウアー、C.およびS. Ayaz、 "航空NEMO ROのためのATNトポロジの考慮事項"、進歩、2009年9月での作業。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, September 2009.
[LISP]ファリナッチ、D.、フラー、V.、マイヤー、D.、およびD.ルイス、 "ロケータ/ ID分離プロトコル（LISP）"、進歩、2009年9月に作業。
[HOAGLAND] Hoagland, J., Krishnan, S., and D. Thaler, "Security Concerns With IP Tunneling", Work in Progress, October 2008.
[ホーグランド]ホーグランド、J.、クリシュナン、S.、およびD.ターラー、 "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]ジェン、D.、マイゼル、M.、マッシー、D.、王、L.、張、B.、およびL.チャン、 "APT：実践トランジットマッピングサービス" 進歩、2007年11月で、作業。
[RUSSERT] Russert, S., Fleischman, E., and F. Templin, "RANGER Scenarios", Work in Progress, September 2009.
[ラサート]ラサート、S.、Fleischman、E.、およびF.テンプリン、 "RANGERのシナリオ"、進歩、2009年9月での作業。
[SEAL] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010.
[SEAL]テンプリン、F.、エド。、 "サブネットワークのカプセル化とアダプテーション層（SEAL）"、RFC 5320、2010年2月。
[VET] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[VET]テンプリン、F.、エド。、 "仮想エンタープライズトラバーサル（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]ウィング、D.、ウォード、D.、およびA.デュラン、進歩、2008年9月の作品 "NAT-PTを交換する提案の比較"。
[IEN48] Cerf, V., "The Catenet Model for Internetworking", July 1978.
[IEN48]サーフ、V.、 "インターネットワーキングのためのCATENETモデル"、1978年7月。
[ILNP] Atkinson, R., "ILNP Concept of Operations", Work in Progress, December 2008.
[ILNP]アトキンソン、R.、 "オペレーションのILNPコンセプト"、進歩、2008年12月に作業。
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992.
[RFC1380]グロス、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月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、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]カーペンター、B.及びC.チョン、 "明示的なトンネルなしでの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、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[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月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、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]バウンド、J.、Pouffary、Y.、Klynsma、S.、chownコマンド、T.、およびD.グリーン、 "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]テンプリン、F.、グリーソン、T.、およびD.ターラーは、 "イントラサイト自動トンネルは、プロトコル（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.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、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]フランシス、P.、徐、X.、Ballani、H.、ジェン、D.、Raszuk、R.、およびL.チャン、 "仮想集約を用いたFIBの抑制"、進歩、2009年10月に作業。
[VOGT] Vogt, C., "Six/One: A Solution for Routing and Addressing in IPv6", Work in Progress, October 2009.
[VOGT]フォークト、C.、 "/ワン6：IPv6におけるルーティングと対処するためのソリューション"、進歩、2009年10月に作業。
[WHITTLE] Whittle, R., "Ivip (Internet Vastly Improved Plumbing) Architecture", Work in Progress, August 2008.
[削る] 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】タッチ、J.、 "X-ボーン"、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.テンプリンファントムワークス私書箱ボックス3707 MC 7L-49シアトル、WA 98124 USA
EMail: fltemplin@acm.org
メールアドレス：fltemplin@acm.org