Internet Research Task Force (IRTF) F. Templin, Ed.
Request for Comments: 6179 Boeing Research & Technology
Category: Experimental March 2011
ISSN: 2070-1721
The Internet Routing Overlay Network (IRON)
Abstract
抽象
Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of the IRTF Routing Research Group.
インターネットは、需要の増加に伴うエスカレート成長をサポートし続けなければならないので、現在のルーティング・アーキテクチャと運用慣行が更新されなければならないことは明らかです。この文書は、インターネットルーティングオーバレイネットワークシステムを終了するには何も変更し、既存のルーティングシステムに変更を加える必要はありませんしながら、持続的な成長をサポートしています（IRON）を提案しています。 IRONは、さらにルーティングのスケーリング、移動性管理、マルチホーミング、トラフィックエンジニアリングとNATトラバーサルを含む他の重要な問題に対処します。ビジネス上の考慮事項が広く採用のための重要な決定要因であるが、それらはこの文書の範囲外です。この文書では、IRTFのルーティング研究グループの製品です。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Internet Research Task Force (IRTF) Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットリサーチタスクフォースのインターネットResearch Task Force（IRTF）研究グループ（IRTF）の1つまたは複数のメンバーの個々の意見（複数可）を表しています。 IRSGによって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 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/rfc6179.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6179で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................5
3. The Internet Routing Overlay Network ............................7
3.1. IRON Client ................................................9
3.2. IRON Serving Router .......................................10
3.3. IRON Relay Router .........................................10
4. IRON Organizational Principles .................................11
5. IRON Initialization ............................................13
5.1. IRON Relay Router Initialization ..........................13
5.2. IRON Serving Router Initialization ........................14
5.3. IRON Client Initialization ................................15
6. IRON Operation .................................................15
6.1. IRON Client Operation .....................................16
6.2. IRON Serving Router Operation .............................17
6.3. IRON Relay Router Operation ...............................18
6.4. IRON Reference Operating Scenarios ........................18
6.4.1. Both Hosts within IRON EUNs ........................19
6.4.2. Mixed IRON and Non-IRON Hosts ......................21
6.5. Mobility, Multihoming, and Traffic Engineering
Considerations ............................................24
6.5.1. Mobility Management ................................24
6.5.2. Multihoming ........................................25
6.5.3. Inbound Traffic Engineering ........................25
6.5.4. Outbound Traffic Engineering .......................25
6.6. Renumbering Considerations ................................25
6.7. NAT Traversal Considerations ..............................26
6.8. Multicast Considerations ..................................26
6.9. Nested EUN Considerations .................................26
6.9.1. Host A Sends Packets to Host Z .....................28
6.9.2. Host Z Sends Packets to Host A .....................28
7. Implications for the Internet ..................................29
8. Additional Considerations ......................................30
9. Related Initiatives ............................................30
10. Security Considerations .......................................31
11. Acknowledgements ..............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................32
Appendix A. IRON VPs over Internetworks with Different
Address Families ......................................35
Appendix B. Scaling Considerations ................................36
Growth in the number of entries instantiated in the Internet routing system has led to concerns regarding unsustainable routing scaling [RADIR]. Operational practices such as the increased use of multihoming with Provider-Independent (PI) addressing are resulting in more and more fine-grained prefixes being injected into the routing system from more and more end user networks. Furthermore, depletion of the public IPv4 address space has raised concerns for both increased address space fragmentation (leading to yet further routing table entries) and an impending address space run-out scenario. At the same time, the IPv6 routing system is beginning to see growth [BGPMON] which must be managed in order to avoid the same routing scaling issues the IPv4 Internet now faces. Since the Internet must continue to scale to accommodate increasing demand, it is clear that new routing methodologies and operational practices are needed.
インターネットルーティングシステムでインスタンスのエントリ数の成長は[RADIR]スケーリング持続不可能なルーティングに関する懸念につながっています。アドレッシングそのようなプロバイダ非依存（PI）でマルチホーミングの使用の増加のような運用方法は、より多くのエンド・ユーザ・ネットワークからルーティングシステムに注入されるより多くのきめ細かいプレフィックスをもたらすれます。さらに、パブリックIPv4アドレス空間の枯渇は、（さらに別のルーティングテーブルのエントリにつながる）の両方の増加アドレス空間の断片化及び切迫アドレス空間ランアウトシナリオの懸念を提起しています。同時に、IPv6ルーティングシステムは、IPv4インターネットが今直面している同じルーティングスケーリングの問題を回避するために管理されなければならない成長[BGPMON]を参照してくださいし始めています。インターネットは、需要の増加に対応するために拡張し続けなければならないので、新しいルーティング手法や運用方法が必要であることは明らかです。
Several related works have investigated routing scaling issues. Virtual Aggregation (VA) [GROW-VA] and Aggregation in Increasing Scopes (AIS) [EVOLUTION] are global routing proposals that introduce routing overlays with Virtual Prefixes (VPs) to reduce the number of entries required in each router's Forwarding Information Base (FIB) and Routing Information Base (RIB). Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) [RFC5720] examines recursive arrangements of enterprise networks that can apply to a very broad set of use-case scenarios [RFC6139]. IRON specifically adopts the RANGER Non-Broadcast, Multiple Access (NBMA) tunnel virtual-interface model, and uses Virtual Enterprise Traversal (VET) [INTAREA-VET] and the Subnetwork Adaptation and Encapsulation Layer (SEAL) [INTAREA-SEAL] as its functional building blocks.
いくつかの関連作品は、ルーティングのスケーリングの問題を検討しました。仮想集約（VA）[GROW-VA]と集計をスコープ（AIS）を増やすには、[EVOLUTION]は、各ルータの転送情報ベース（FIBに必要なエントリの数を減らすために、仮想プレフィックス（VPS）とルーティングオーバーレイを導入し、グローバルルーティング提案されています）およびルーティング情報ベース（RIB）。グローバルエンタープライズ再帰（レンジャー）[RFC5720]を有するネットワークにおけるルーティング及びアドレッシングはユース・ケース・シナリオ[RFC6139]の非常に広いセットに適用することができる企業ネットワークの再帰的配列を調べます。鉄は、具体的にRANGER非放送、多重アクセス（NBMA）トンネル仮想インタフェースモデルを採用し、そのように仮想エンタープライズトラバーサル（VET）INTAREA-VET]およびサブネットワーク適応およびカプセル化レイヤ（SEAL）INTAREA-SEAL]を使用します機能的なビルディングブロック。
This document proposes an Internet Routing Overlay Network (IRON) with goals of supporting sustainable growth while requiring no changes to the existing routing system. IRON borrows concepts from VA and AIS, and further borrows concepts from the Internet Vastly Improved Plumbing (Ivip) [IVIP-ARCH] architecture proposal along with its associated Translating Tunnel Router (TTR) mobility extensions [TTRMOB]. Indeed, the TTR model to a great degree inspired the IRON mobility architecture design discussed in this document. The Network Address Translator (NAT) traversal techniques adapted for IRON were inspired by the Simple Address Mapping for Premises Legacy Equipment (SAMPLE) proposal [SAMPLE].
この文書では、既存のルーティングシステムへの変更を必要としないながら、持続的な成長を支えるの目標とインターネットルーティングオーバーレイネットワーク（IRON）を提案しています。鉄はVAとAISから概念を借り、さらに大きくそれに関連する翻訳トンネルルータ（TTR）モビリティ拡張[TTRMOB]とともに配管（Ivip）IVIP-ARCH]アーキテクチャの提案を改善インターネットから概念を借り。確かに、かなりの程度までTTRモデルは、このドキュメントで説明IRONモビリティアーキテクチャの設計に影響を与えました。 IRONに適合し、ネットワークアドレス変換（NAT）トラバーサル技術は構内レガシー機器用のシンプルなアドレスマッピング（SAMPLE）の提案[SAMPLE]に触発されました。
IRON supports scalable addressing without changing the current BGP [RFC4271] routing system. IRON observes the Internet Protocol standards [RFC0791][RFC2460]. Other network-layer protocols that can be encapsulated within IP packets (e.g., OSI/CLNP (Connectionless Network Protocol) [RFC1070], etc.) are also within scope.
IRONは、現在のBGP [RFC4271]ルーティングシステムを変更せずに対処するスケーラブルなサポートしています。 IRONは、インターネットプロトコル規格[RFC0791] [RFC2460]を観察します。 IPパケット内にカプセル化することができる他のネットワーク層プロトコル（例えば、OSI / CLNP（コネクションレスネットワークプロトコル）[RFC1070]など）が範囲内です。
The IRON is a global routing system comprising virtual overlay networks managed by Virtual Prefix Companies (VPCs) that own and manage Virtual Prefixes (VPs) from which End User Network (EUN) prefixes (EPs) are delegated to customer sites. The IRON is motivated by a growing customer demand for multihoming, mobility management, and traffic engineering while using stable addressing to minimize dependence on network renumbering [RFC4192][RFC5887]. The IRON uses the existing IPv4 and IPv6 global Internet routing systems as virtual NBMA links for tunneling inner network protocol packets within outer IPv4 or IPv6 headers (see Section 3). The IRON requires deployment of a small number of new BGP core routers and supporting servers, as well as IRON-aware routers/servers in customer EUNs. No modifications to hosts, and no modifications to most routers, are required.
IRONは、エンドユーザーのネットワーク（EUN）プレフィックス（EPS）は、顧客のサイトに委任されているから、仮想プレフィックス（VPS）を所有し、管理する仮想プレフィックス会社（VPCの）が管理する仮想オーバーレイネットワークを備えたグローバルルーティングシステムです。 [RFC4192] [RFC5887]をリナンバリングネットワークへの依存を最小限に抑えるために取り組む安定を使用している間IRONはマルチホーミング、モビリティ管理、およびトラフィックエンジニアリングのために成長している顧客の需要によって動機付けられています。鉄は、外側IPv4またはIPv6ヘッダー（セクション3を参照）内の内部ネットワーク・プロトコル・パケットをトンネリングするための仮想NBMAリンクなど既存のIPv4およびIPv6グローバルインターネットルーティングシステムを使用します。 IRONは新しいBGPのコアルータとサポートするサーバの数が少ないの展開だけでなく、顧客EUNsでIRON対応のルータ/サーバが必要です。ホストへの改造、そしてほとんどのルータへの変更なしには、必要ありません。
Note: This document is offered in compliance with Internet Research Task Force (IRTF) document stream procedures [RFC5743]; it is not an IETF product and is not a standard. The views in this document were considered controversial by the IRTF Routing Research Group (RRG), but the RG reached a consensus that the document should still be published. The document will undergo a period of review within the RRG and through selected expert reviewers prior to publication. The following sections discuss details of the IRON architecture.
注意：この文書はインターネットResearch Task Force（IRTF）ドキュメントストリーム手順[RFC5743]に準拠して提供されています。それは、IETFの製品ではなく、標準ではありません。この文書に記載されているビューはIRTFのルーティング研究グループ（RRG）で物議考えられるが、RGは、文書はまだ公表されなければならない合意に達しました。文書は、出版前にRRG内および選択された専門家の査読を通じて審査の期間を受けることになります。次のセクションでは、IRONアーキテクチャの詳細を議論します。
This document makes use of the following terms:
このドキュメントでは、次の用語を使用します：
End User Network (EUN): an edge network that connects an organization's devices (e.g., computers, routers, printers, etc.) to the Internet.
エンドユーザーのネットワーク（EUN）：インターネットへの組織のデバイス（例えば、コンピュータ、ルータ、プリンタなど）を接続エッジネットワーク。
End User Network Prefix (EP): a more specific inner network-layer prefix derived from a Virtual Prefix (VP) (e.g., an IPv4 /28, an IPv6 /56, etc.) and delegated to an EUN by a Virtual Prefix Company (VPC).
エンドユーザネットワークプレフィックス（EP）：仮想プレフィックス（VP）に由来する、より具体的な内部ネットワーク層接頭辞（例えば、などのIPv4 / 28、IPv6の/ 56、）および仮想プレフィックス当社がEUNに委任（VPC）。
End User Network Prefix Address (EPA): a network-layer address belonging to an EP and assigned to the interface of an end system in an EUN.
エンドユーザのネットワークプレフィックスアドレス（EPA）：ネットワーク層アドレスがEPに所属し、EUNにおけるエンドシステムのインタフェースに割り当てられました。
Forwarding Information Base (FIB): a data structure containing network prefixes to next-hop mappings; usually maintained in a router's fast-path processing lookup tables.
転送情報ベース（FIB）：ネクストホップへのマッピングネットワークプレフィックスを含むデータ構造。通常、ルータのファストパス処理ルックアップテーブルで維持しました。
Internet Routing Overlay Network (IRON): a composite virtual overlay network that comprises the union of all VPC overlay networks configured over a common Internetwork. The IRON supports routing through encapsulation of inner packets with EPA addresses within outer headers that use locator addresses.
インターネットルーティングオーバーレイネットワーク（IRON）：一般的なインターネットワーク上で構成されているすべてのVPCのオーバーレイネットワークの組合を備えた複合仮想オーバーレイネットワーク。 IRONは、ロケータアドレスを使用し、外側のヘッダー内EPAアドレスと内部パケットのカプセル化を経由サポート。
IRON Client Router/Host ("Client"): a customer's router or host that logically connects the customer's EUNs and their associated EPs to the IRON via an NBMA tunnel virtual interface.
IRONクライアントルータ/ホスト（「クライアント」）：論理NBMAトンネルの仮想インターフェースを介してIRONに、顧客のEUNsとその関連のEPを接続している顧客のルータまたはホスト。
IRON Serving Router ("Server"): a VPC's overlay network router that provides forwarding and mapping services for the EPs owned by customer Clients.
IRONサービングルーター（「サーバー」）：顧客クライアントが所有しているのEPの転送およびマッピングサービスを提供してVPCのオーバーレイネットワークルータ。
IRON Relay Router ("Relay"): a VPC's overlay network router that acts as a relay between the IRON and the native Internet.
IRONリレールーター（「リレー」）：VPCのオーバレイネットワークルータIRONとネイティブインターネットとの間の中継として機能します。
IRON Agent (IA): generically refers to any of an IRON Client/Server/Relay.
IRONエージェント（IA）は：一般的にIRONクライアント/サーバ/リレーのいずれかを指します。
Internet Service Provider (ISP): a service provider that connects customer EUNs to the underlying Internetwork. In other words, an ISP is responsible for providing basic Internet connectivity for customer EUNs.
インターネットサービスプロバイダ（ISP）：基本的なインターネットワークに顧客EUNsを接続するサービスプロバイダー。言い換えれば、ISPは、顧客EUNsのための基本的なインターネット接続を提供する責任があります。
Locator an IP address assigned to the interface of a router or end system within a public or private network. Locators taken from public IP prefixes are routable on a global basis, while locators taken from private IP prefixes are made public via Network Address Translation (NAT).
パブリックまたはプライベートネットワーク内のルータまたはエンド・システムのインタフェースに割り当てられたIPアドレスをロケータ。プライベートIPプレフィックスから取られたロケータは、ネットワークアドレス変換（NAT）を介して公開されている間、パブリックIPプレフィックスから取られたロケータは、グローバルにルーティング可能です。
Routing and Addressing in Networks with Global Enterprise Recursion (RANGER): an architectural examination of virtual overlay networks applied to enterprise network scenarios, with implications for a wider variety of use cases.
ルーティングとグローバル企業再帰（RANGER）とネットワークにおけるアドレッシング：仮想オーバーレイネットワークのアーキテクチャの検討は、ユースケースの広いさまざまな意味合いで、企業ネットワークのシナリオに適用されます。
Subnetwork Encapsulation and Adaptation Layer (SEAL): an encapsulation sublayer that provides extended packet identification and a Control Message Protocol to ensure deterministic network-layer feedback.
サブネットワークのカプセル化及びアダプテーションレイヤ（SEAL）：確定的ネットワーク層フィードバックを確保するために、拡張パケット識別及び制御メッセージプロトコルを提供するカプセル化サブレイヤ。
Virtual Enterprise Traversal (VET): a method for discovering border routers and forming dynamic tunnel-neighbor relationships over enterprise networks (or sites) with varying properties.
仮想エンタープライズトラバーサル（VET）：境界ルータを発見すると変化する特性を有する企業ネットワーク（またはサイト）上に動的トンネルネイバー関係を形成するための方法。
Virtual Prefix (VP): a prefix block (e.g., an IPv4 /16, an IPv6 /20, an OSI Network Service Access Protocol (NSAP) prefix, etc.) that is owned and managed by a Virtual Prefix Company (VPC).
仮想プレフィックス（VP）：接頭ブロック（例えば、IPv4の/ 16、IPv6の/ 20、OSIネットワークサービスアクセスプロトコル（NSAP）の接頭辞など）を所有し、仮想プレフィックスカンパニー（VPC）によって管理されています。
Virtual Prefix Company (VPC): a company that owns and manages a set of VPs from which it delegates EPs to EUNs.
仮想プレフィックスカンパニー（VPC）：それデリゲートがEUNsに、EPS、そこからのVPのセットを所有し、管理する会社。
VPC Overlay Network a specialized set of routers deployed by a VPC to service customer EUNs through a virtual overlay network configured over an underlying Internetwork (e.g., the global Internet).
VPCオーバーレイネットワーク基盤となるインターネットワーク（例えば、グローバルインターネット）上に構成された仮想オーバレイネットワークを介して顧客EUNsにサービスを提供するVPCによって展開ルータの特殊なセット。
The Internet Routing Overlay Network (IRON) is a system of virtual overlay networks configured over a common Internetwork. While the principles presented in this document are discussed within the context of the public global Internet, they can also be applied to any autonomous Internetwork. The rest of this document therefore refers to the terms "Internet" and "Internetwork" interchangeably except in cases where specific distinctions must be made.
インターネットルーティングオーバレイネットワーク（鉄）、共通インターネットワーク上に設定された仮想オーバーレイネットワークのシステムです。この文書の原則は公共のグローバルなインターネットの文脈の中で議論されているが、それらはまた、任意の自律インターネットワークにも適用することができます。このドキュメントの残りの部分は、したがって、用語「インターネット」と同義的に特定の区別がなされなければならない場合を除いて、「インターネットワーク」を指します。
The IRON consists of IRON Agents (IAs) that automatically tunnel the packets of end-to-end communication sessions within encapsulating headers used for Internet routing. IAs use the Virtual Enterprise Traversal (VET) [INTAREA-VET] virtual NBMA link model in conjunction with the Subnetwork Encapsulation and Adaptation Layer (SEAL) [INTAREA-SEAL] to encapsulate inner network-layer packets within outer headers, as shown in Figure 1.
IRONは、インターネットルーティングに使用されるヘッダをカプセル化内のエンド・ツー・エンドの通信セッションのIRONエージェント（IAS）は、自動的にトンネルパケットから成ります。 IASは、図に示すように、外側のヘッダ内に内部ネットワーク層パケットをカプセル化するためにサブネットワークのカプセル化及びアダプテーションレイヤ（SEAL）と組み合わせて仮想エンタープライズトラバーサル（VET）INTAREA-VET]仮想NBMAリンクモデル[INTAREA-SEAL]を使用します1。
+-------------------------+
| Outer headers with |
~ locator addresses ~
| (IPv4 or IPv6) |
+-------------------------+
| SEAL Header |
+-------------------------+ +-------------------------+
| Inner Packet Header | --> | Inner Packet Header |
~ with EP addresses ~ --> ~ with EP addresses ~
| (IPv4, IPv6, OSI, etc.) | --> | (IPv4, IPv6, OSI, etc.) |
+-------------------------+ +-------------------------+
| | --> | |
~ Inner Packet Body ~ --> ~ Inner Packet Body ~
| | --> | |
+-------------------------+ +-------------------------+
Inner packet before Outer packet after encapsulation encapsulation
カプセルのカプセル化後の外部パケットの前に内部パケット
Figure 1: Encapsulation of Inner Packets within Outer IP Headers
図1：外部IPヘッダ内のインナーパケットのカプセル化
VET specifies the automatic tunneling mechanisms used for encapsulation, while SEAL specifies the format and usage of the SEAL header as well as a set of control messages. Most notably, IAs use the SEAL Control Message Protocol (SCMP) to deterministically exchange and authenticate control messages such as route redirections, indications of Path Maximum Transmission Unit (PMTU) limitations, destination unreachables, etc. IAs appear as neighbors on an NBMA virtual link, and form bidirectional and/or unidirectional tunnel-neighbor relationships.
シールはフォーマットおよび使用方法シールヘッダのと同様に、制御メッセージのセットを指定しながら、VETは、カプセル化のために使用される自動トンネリングメカニズムを指定します。最も顕著なのは、IASは決定論などのルートリダイレクト、パス最大伝送単位（PMTU）の制限の兆候、送信先到達不能、などの制御メッセージを交換し、認証するためにSEAL制御メッセージプロトコル（SCMP）を使用するIASはNBMA仮想リンク上の隣人として表示されます、双方向及び/又は一方向トンネルネイバー関係を形成します。
The IRON is the union of all virtual overlay networks that are configured over a common underlying Internet and are owned and managed by Virtual Prefix Companies (VPCs). Each such virtual overlay network comprises a set of IAs distributed throughout the Internet to serve highly aggregated Virtual Prefixes (VPs). VPCs delegate sub-prefixes from their VPs, which they lease to customers as End User Network Prefixes (EPs). In turn, the customers assign the EPs to their customer edge IAs, which connect their End User Networks (EUNs) to the IRON.
IRONは、共通の基盤となるインターネット上で構成され、所有され、仮想プレフィックス会社（VPCの）によって管理されているすべての仮想オーバーレイネットワークの労働組合です。このような各仮想オーバレイネットワークは、高度に凝集仮想プレフィックス（VPS）を提供するためにインターネット全体に分散発行機関のセットを含みます。彼らはエンドユーザのネットワークプレフィックス（EPS）として顧客にリース自分のVP、からVPCのデリゲートサブプレフィックス。ターンでは、顧客はIRONへのエンドユーザーのネットワーク（EUNs）を接続し、顧客エッジ発行機関へのEPを割り当てます。
VPCs may have no affiliation with the ISP networks from which customers obtain their basic Internet connectivity. Therefore, a customer could procure its summary network services either through a common broker or through separate entities. In that case, the VPC can open for business and begin serving its customers immediately without the need to coordinate its activities with ISPs or other VPCs. Further details on business considerations are out of scope for this document.
VPCのは、顧客が彼らの基本的なインターネット接続を取得し、そこからISPのネットワークとは提携を持っていないかもしれません。そのため、顧客は、一般的なブローカーを介して、または個別のエンティティのいずれかを介してその概要ネットワーク・サービスを調達することができます。その場合には、VPCはビジネスのために開いて、ISPや他のVPCとその活動を調整する必要がなく、すぐにその顧客にサービスを提供開始することができます。ビジネス上の考慮事項の詳細は、このドキュメントの範囲外です。
The IRON requires no changes to end systems or to most routers in the Internet. Instead, the IRON comprises IAs that are deployed either as new platforms or as modifications to existing platforms. IAs may be deployed incrementally without disturbing the existing Internet routing system and act as waypoints (or "cairns") for navigating the IRON. The functional roles for IAs are described in the following sections.
IRONは、システムを終了するか、インターネットでほとんどのルータにするために変更する必要はありません。その代わり、IRONは、新しいプラットフォームとして、あるいは既存のプラットフォームへの変更のいずれかとして展開されているIASを備えています。 IASはIRONをナビゲートするためのウェイポイント（または「ケアンズ」）などの既存のインターネットルーティングシステム及び作用を妨害することなく増分的に展開することができます。発行機関のための機能的役割は、以下のセクションに記載されています。
An IRON client (or, simply, "Client") is a customer's router or host
that logically connects the customer's EUNs and their associated EPs
to the IRON via tunnels, as shown in Figure 2. Client routers obtain
EPs from VPCs and use them to number subnets and interfaces within
their EUNs. A Client can be deployed on the same physical platform
that also connects the customer's EUNs to its ISPs, but it may also
be a separate router or even a standalone server system located
within the EUN. (This model applies even if the EUN connects to the
ISP via a Network Address Translator (NAT) -- see Section 6.7).
Finally, a Client may also be a simple end system that connects a
singleton EPA and exhibits the outward appearance of a host.
.-.
,-( _)-.
+--------+ .-(_ (_ )-.
| Client |--(_ ISP )
+---+----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN ) e `-(______)-
`-(______)-' l ___
| s => (:::)-.
+----+---+ .-(::::::::)
| Host | .-(::::::::::::)-.
+--------+ (:::: The IRON ::::)
`-(::::::::::::)-'
`-(::::::)-'
Figure 2: IRON Client Router Connecting EUN to the IRON
図2：IRONクライアントルータはIRONへのEUNの接続します
An IRON serving router (or, simply, "Server") is a VPC's overlay network router that provides forwarding and mapping services for the EPs owned by customer Client routers. In typical deployments, a VPC will deploy many Servers around the IRON in a globally distributed fashion (e.g., as depicted in Figure 3) so that Clients can discover those that are nearby.
IRON提供するルータ（または、単に、「サーバ」）は、お客様のクライアントルータによって所有のEPの転送およびマッピングサービスを提供してVPCのオーバーレイネットワークルータです。クライアントは、近くにあるものを発見することができるように、典型的な展開では、VPC（例えば、図3に示されるように）、グローバルに分散方式でIRONの周りに多くのサーバを展開します。
+--------+ +--------+
| Boston | | Tokyo |
| Server | | Server |
+--+-----+ ++-------+
+--------+ \ /
| Seattle| \ ___ /
| Server | \ (:::)-. +--------+
+------+-+ .-(::::::::)------+ Paris |
\.-(::::::::::::)-. | Server |
(:::: The IRON ::::) +--------+
`-(::::::::::::)-'
+--------+ / `-(::::::)-' \ +--------+
| Moscow + | \--- + Sydney |
| Server | +----+---+ | Server |
+--------+ | Cairo | +--------+
| Server |
+--------+
Figure 3: IRON Serving Router Global Distribution Example
図3：IRONサービングルータのグローバル・ディストリビューション例
Each Server acts as a tunnel-endpoint router that forms a bidirectional tunnel-neighbor relationship with each of its Client customers. Each Server also associates with a set of Relays that can forward packets from the IRON out to the native Internet and vice versa, as discussed in the next section.
各サーバは、そのクライアントの顧客のそれぞれとの間で双方向トンネル隣接関係を形成し、トンネルのエンドポイントルータとして動作します。各サーバは、また、次のセクションで説明したように、ネイティブインターネット及びその逆に出IRONからパケットを転送することができるリレーのセットに関連付けます。
An IRON Relay Router (or, simply, "Relay") is a VPC's overlay network router that acts as a relay between the IRON and the native Internet. Therefore, it also serves as an Autonomous System Border Router (ASBR) that is owned and managed by the VPC.
IRONリレールーター（または、単に、「リレー」）は、鉄とネイティブインターネットとの間の中継として機能しVPCのオーバーレイネットワークルータです。したがって、それはまた、VPCによって所有され、管理されている自律システム境界ルータ（ASBR）として機能します。
Each VPC configures one or more Relays that advertise the company's VPs into the IPv4 and IPv6 global Internet BGP routing systems. Each Relay associates with all of the VPC's overlay network Servers, e.g., via tunnels over the IRON, via a direct interconnect such as an Ethernet cable, etc. The Relay role (as well as its relationship with overlay network Servers) is depicted in Figure 4.
各VPCは、IPv4とIPv6のグローバルなインターネットBGPルーティングシステムに、同社の仮想プロセッサを宣伝一つ以上のリレーを設定します。このようなイーサネットケーブルなどの直接相互接続を介して、IRON上のトンネルを介してVPCのオーバレイネットワークのすべてのサーバー、例えば、等リレー役割（ならびにオーバーレイネットワークサーバとの関係）を有する各中継会合は、図に示されています4。
.-.
,-( _)-.
.-(_ (_ )-.
(_ Internet )
`-(______)-' | +--------+
| |--| Server |
+----+---+ | +--------+
| Relay |----| +--------+
+--------+ |--| Server |
_|| | +--------+
(:::)-. (Ethernet)
.-(::::::::)
+--------+ .-(::::::::::::)-. +--------+
| Server |=(:::: The IRON ::::)=| Server |
+--------+ `-(::::::::::::)-' +--------+
`-(::::::)-'
|| (Tunnels)
+--------+
| Server |
+--------+
Figure 4: IRON Relay Router Connecting IRON to Native Internet
図4：IRONリレールーターは、ネイティブのインターネットへの接続IRON
The IRON consists of the union of all VPC overlay networks configured over a common Internetwork (e.g., the public Internet). Each such overlay network represents a distinct "patch" on the Internet "quilt", where the patches are stitched together by tunnels over the links, routers, bridges, etc. that connect the underlying Internetwork. When a new VPC overlay network is deployed, it becomes yet another patch on the quilt. The IRON is therefore a composite overlay network consisting of multiple individual patches, where each patch coordinates its activities independently of all others (with the exception that the Servers of each patch must be aware of all VPs in the IRON). In order to ensure mutual cooperation between all VPC overlay networks, sufficient address space portions of the inner network-layer protocol (e.g., IPv4, IPv6, etc.) should be set aside and designated as VP space.
鉄は、共通のインターネットワーク（例えば、公衆インターネット）上に設定されているすべてのVPCオーバレイネットワークの組合から成ります。各そのようなオーバーレイネットワークは、パッチは、基礎となるインターネットワークを接続するリンク、ルータ、ブリッジ、等にわたってトンネルによって縫合されるインターネット「キルト」、上の異なる「パッチ」を表します。新しいVPCのオーバーレイネットワークが展開されると、それはキルトにさらに別のパッチになります。 IRONしたがって、各パッチは、独立して（各パッチのサーバは鉄中のすべてのVPを認識しなければならないことを除いて）他のすべての活動を調整する複数の個々のパッチからなる複合オーバーレイ・ネットワークです。全てVPCオーバレイネットワーク間の相互協力を確保するために、内部ネットワーク層プロトコル（例えば、IPv4の、IPv6の、など）の十分なアドレス空間部が確保されるべきであり、VPスペースとして指定します。
Each VPC overlay network in the IRON maintains a set of Relays and Servers that provide services to their Client customers. In order to ensure adequate customer service levels, the VPC should conduct a traffic scaling analysis and distribute sufficient Relays and Servers for the overlay network globally throughout the Internet. Figure 5 depicts the logical arrangement of Relays, Servers, and Clients in an IRON virtual overlay network.
IRON内の各VPCのオーバーレイネットワークは、彼らのクライアントの顧客にサービスを提供リレーおよびサーバーのセットを保持しています。十分な顧客サービスレベルを確保するためには、VPCはトラフィックスケーリング分析を行う必要がありますし、インターネットを通じて世界的にオーバーレイネットワークのための十分なリレーおよびサーバーを配布します。図5は、IRON仮想オーバレイネットワークにおけるリレー、サーバ、およびクライアントの論理的な配置を示します。
.-.
,-( _)-.
.-(_ (_ )-.
(__ Internet _)
`-(______)-'
<------------ Relays ------------>
________________________
(::::::::::::::::::::::::)-.
.-(:::::::::::::::::::::::::::::)
.-(:::::::::::::::::::::::::::::::::)-.
(::::::::::: The IRON :::::::::::::::)
`-(:::::::::::::::::::::::::::::::::)-'
`-(::::::::::::::::::::::::::::)-'
<------------ Servers ------------>
.-. .-. .-.
,-( _)-. ,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-.
(__ ISP A _) (__ ISP B _) ... (__ ISP x _)
`-(______)-' `-(______)-' `-(______)-'
<----------- NATs ------------>
<----------- Clients and EUNs ----------->
Figure 5: Virtual Overlay Network Organization
図5：仮想オーバーレイネットワーク組織
Each Relay in the VPC overlay network connects the overlay directly to the underlying IPv4 and IPv6 Internets. It also advertises the VPC overlay network's IPv4 VPs into the IPv4 BGP routing system and advertises the overlay network's IPv6 VPs into the IPv6 BGP routing system. Relays will therefore receive packets with EPA destination addresses sent by end systems in the Internet and direct them toward EPA-addressed end systems connected to the VPC overlay network.
VPCオーバーレイネットワーク内の各リレーは、基礎となるIPv4とIPv6インターネットの直接オーバーレイを接続しています。また、IPv4のBGPルーティングシステムにVPCオーバレイネットワークのIPv4のVPをアドバタイズおよびIPv6 BGPルーティングシステムに、オーバーレイネットワークのIPv6のVPをアドバタイズします。リレーは、したがって、インターネットでエンドシステムによって送信されたEPAの宛先アドレスを持つパケットを受信して、VPCのオーバーレイネットワークに接続されているEPA-対処エンドシステムに向かってそれらを指示します。
Each VPC overlay network also manages a set of Servers that connect their Clients and associated EUNs to the IRON and to the IPv6 and IPv4 Internets via their associations with Relays. IRON Servers therefore need not be BGP routers themselves; they can be simple commodity hardware platforms. Moreover, the Server and Relay functions can be deployed together on the same physical platform as a unified gateway, or they may be deployed on separate platforms (e.g., for load balancing purposes).
各VPCのオーバーレイネットワークはまた、リレーで自分の団体を経由してIRONにし、IPv6とIPv4インターネットのに彼らのクライアントとの関連EUNsを接続するサーバーのセットを管理します。 IRONサーバーは、したがって、自分自身のBGPルータである必要はありません。彼らは、単純なコモディティ・ハードウェア・プラットフォームすることができます。また、サーバおよびリレー機能は、統合ゲートウェイと同じ物理プラットフォーム上に一緒に展開することができ、またはそれらは別々のプラットフォーム（例えば、負荷バランシングのために）上に配備されてもよいです。
Each Server maintains a working set of Clients for which it caches EP-to-Client mappings in its Forwarding Information Base (FIB). Each Server also, in turn, propagates the list of EPs in its working set to each of the Relays in the VPC overlay network via a dynamic routing protocol (e.g., an overlay network internal BGP instance that carries only the EP-to-Server mappings and does not interact with the external BGP routing system). Therefore, each Server only needs to track the EPs for its current working set of Clients, while each Relay will maintain a full EP-to-Server mapping table that represents reachability information for all EPs in the VPC overlay network.
各サーバーは、その転送情報ベース（FIB）にEPからクライアントへのマッピングをキャッシュするクライアントのワーキングセットを保持しています。各サーバは、順番に、動的ルーティングプロトコル（例えば、唯一EPからサーバーへのマッピングを搬送するオーバーレイネットワーク内部BGPインスタンスを介してVPCオーバレイネットワーク内のリレーのそれぞれに設定され、その作業中のEPのリストを伝播しますそして、）外部BGPルーティングシステムと相互作用しません。そのため、各サーバは、各リレーは、VPCオーバーレイネットワーク内のすべてのEPの到達可能性情報を表しフルEPからサーバへのマッピングテーブルを維持する一方で、クライアントの現在の作業セットのためのEPを追跡する必要があります。
Customers establish Clients that obtain their basic Internet connectivity from ISPs and connect to Servers to attach their EUNs to the IRON. Each EUN can connect to the IRON via one or multiple Clients as long as the Clients coordinate with one another, e.g., to mitigate EUN partitions. Unlike Relays and Servers, Clients may use private addresses behind one or several layers of NATs. Each Client initially discovers a list of nearby Servers through an anycast discovery process (described below). It then selects one of these nearby Servers and forms a bidirectional tunnel-neighbor relationship with the server through an initial exchange followed by periodic keepalives.
お客様は、ISPのから彼らの基本的なインターネット接続を取得し、IRONへのEUNsを添付するサーバーに接続するクライアントを確立します。各EUNであればクライアントはEUNパーティションを軽減するために、例えば、互いに座標など、1つまたは複数のクライアントを介して、IRONに接続することができます。リレーおよびサーバーとは異なり、クライアントがNATのの一つまたは複数の層の後ろにプライベートアドレスを使用することができます。各クライアントは、最初はエニーキャストディスカバリプロセス（後述）を介して近くのサーバのリストを発見します。これは、これらの近くのサーバの1つを選択し、周期的なキープアライブ続く初期の交換を介してサーバとの双方向トンネルネイバー関係を形成します。
After the Client selects a Server, it forwards initial outbound packets from its EUNs by tunneling them to the Server, which, in turn, forwards them to the nearest Relay within the IRON that serves the final destination. The Client will subsequently receive redirect messages informing it of a more direct route through a Server that serves the final destination EUN.
クライアントがサーバを選択した後、それは順番に、最終的な目的地を提供していIRON内の最も近いリレーに転送し、サーバー、それらをトンネリングすることによって、そのEUNsから最初のアウトバウンドパケットを転送します。クライアントは、その後、最終的な宛先EUNを提供していサーバを介してより直接的な経路を通知するリダイレクトメッセージを受信します。
The IRON can also be used to support VPs of network-layer address families that cannot be routed natively in the underlying Internetwork (e.g., OSI/CLNP over the public Internet, IPv6 over IPv4-only Internetworks, IPv4 over IPv6-only Internetworks, etc.). Further details for the support of IRON VPs of one address family over Internetworks based on other address families are discussed in Appendix A.
IRONはまた、などIPv6のみのインターネットワーク、オーバーIPv4のみインターネットワーク、IPv4の上のIPv6、公共のインターネット上で基礎となるインターネットワーク（例えば、OSI / CLNPでネイティブにルーティングすることはできませんネットワーク層のアドレスファミリの仮想プロセッサをサポートするために使用することができます。）。他のアドレスファミリに基づいてインターネットワーク上の1つのアドレスファミリーのIRONのVPをサポートするための更なる詳細は、付録Aで説明されています
IRON initialization entails the startup actions of IAs within the VPC overlay network and customer EUNs. The following sub-sections discuss these startup procedures.
IRONの初期化は、VPCオーバーレイネットワークと顧客EUNs内のIAの起動アクションを伴います。以下のサブセクションでは、これらの起動手順について説明します。
Before its first operational use, each Relay in a VPC overlay network is provisioned with the list of VPs that it will serve as well as the locators for all Servers that belong to the same overlay network. The Relay is also provisioned with external BGP interconnections -- the same as for any BGP router.
その第一の演算に使用する前に、VPCのオーバーレイネットワーク内の各リレーは、それが機能するのVPだけでなく、同じオーバーレイネットワークに属しているすべてのサーバのロケータのリストがプロビジョニングされています。リレーは、外部BGPの相互接続がプロビジョニングされている - すべてのBGPルータの場合と同じ。
Upon startup, the Relay engages in BGP routing exchanges with its peers in the IPv4 and IPv6 Internets the same as for any BGP router. It then connects to all of the Servers in the overlay network (e.g., via a TCP connection over a bidirectional tunnel, via an Internal BGP (IBGP) route reflector, etc.) for the purpose of discovering EP-to-Server mappings. After the Relay has fully populated its EP-to-Server mapping information database, it is said to be "synchronized" with regard to its VPs.
起動時に、リレーは、IPv4とIPv6インターネットの任意のBGPルータと同様に、そのピアとBGPルーティング交換に係合します。その後、EPからサーバーへのマッピングを発見するために（内部BGP（IBGP）ルートリフレクタ等を介して双方向トンネル上のTCP接続を介して、例えば、）オーバレイネットワーク内のすべてのサーバに接続されています。リレーは完全にそのEPからサーバへのマッピング情報データベースを埋めた後、そのVPをに関して「同期」されると言われています。
After this initial synchronization procedure, the Relay then advertises the overlay network's VPs externally. In particular, the Relay advertises the IPv6 VPs into the IPv6 BGP routing system and advertises the IPv4 VPs into the IPv4 BGP routing system. The Relay additionally advertises an IPv4 /24 companion prefix (e.g., 192.0.2.0/24) into the IPv4 routing system and an IPv6 ::/64 companion prefix (e.g., 2001:DB8::/64) into the IPv6 routing system (note that these may also be sub-prefixes taken from a VP). The Relay then configures the host number '1' in the IPv4 companion prefix (e.g., as 192.0.2.1) and the interface identifier '0' in the IPv6 companion prefix (e.g., as 2001:DB8::0), and it assigns the resulting addresses as subnet-router anycast addresses [RFC3068][RFC2526] for the VPC overlay network. (See Appendix A for more information on the discovery and use of companion prefixes.) The Relay then engages in ordinary packet-forwarding operations.
この初期同期手順の後、リレーは、外部からオーバーレイネットワークのVPのをアドバタイズします。具体的には、リレーは、IPv6 BGPルーティングシステムへのIPv6のVPをアドバタイズし、IPv4 BGPルーティングシステムへのIPv4のVPをアドバタイズ。 （IPv6ルーティングシステムにリレーはさらに、IPv4ルーティングシステムおよびIPv6 :: / 64コンパニオンプレフィックス（DB8 :: / 64例えば、2001）にはIPv4 / 24コンパニオン接頭辞（例えば、192.0.2.0/24）をアドバタイズこれらはまた、VPから取られたサブプレフィックス）であってもよいことに注意してください。リレーは、次に（192.0.2.1として例えば、）のIPv4コンパニオン・プレフィックス内のホスト数「1」とインターフェース識別子「0」のIPv6コンパニオンプレフィックスに設定する（例えば、2001のように：DB8を:: 0）、それが割り当てVPCオーバーレイネットワークのサブネットのルータエニーキャストアドレスとして得られたアドレス[RFC3068]、[RFC2526]。 （コンパニオンプレフィックスの発見および使用の詳細については、付録Aを参照してください。）リレーは、その後、通常のパケット転送作業に従事しています。
Before its first operational use, each Server in a VPC overlay network is provisioned with the locators for all Relays that aggregate the overlay network's VPs. In order to support route optimization, the Server must also be provisioned with the list of all VPs in the IRON (i.e., not just the VPs of its own overlay network) so that it can discern EPA and non-EPA addresses. (Therefore, the Server could be greatly simplified if the list of VPs could be covered within a small number of very short prefixes, e.g., one or a few IPv6 ::/20's). The Server must also discover the VP companion prefix relationships discussed in Section 5.1, e.g., via a global database such as discussed in Appendix A.
その第一の演算に使用する前に、VPCオーバーレイネットワーク内の各サーバは、オーバーレイネットワークのVPのを集約すべてのリレーのためのロケータがプロビジョニングされています。それはEPAと非EPAアドレスを識別できるように、ルートの最適化をサポートするために、サーバーは、（独自のオーバーレイネットワークのすなわち、だけではなく、VPS）IRON内のすべてのVPのリストをプロビジョニングする必要があります。 （VPSのリストが非常に短いプレフィックスの少数、例えば、1つまたはIPv6 :: / 20代数内で被覆することができればそのため、サーバは大幅に簡略化することができます）。サーバーは、付録Aで説明したようにグローバル・データベースを経由して、例えば、5.1節で述べたVPコンパニオン接頭辞関係をも検出する必要があります
Upon startup, each Server must connect to all of the Relays within its overlay network (e.g., via a TCP connection, via an IBGP route reflector, etc.) for the purpose of reporting its EP-to-Server mappings. The Server then actively listens for Client customers that register their EP prefixes as part of establishing a bidirectional tunnel-neighbor relationship. When a new Client registers its EP prefixes, the Server announces the new EP additions to all Relays; when an existing Client unregisters its EP prefixes, the Server withdraws its announcements.
起動時に、各サーバは、そのEPからサーバーへのマッピングを報告する目的のためにそのオーバーレイネットワーク（例えば、TCP接続を介して、IBGPルートリフレクタを介して、など）内のリレーのすべてに接続しなければなりません。 Serverは、積極的に双方向トンネル・ネイバー関係を確立する一環として、彼らのEPプレフィックスを登録し、クライアントの顧客を待ち受けます。新しいクライアントはそのEPプレフィックスを登録すると、サーバーはすべてのリレーに新しいEPの追加を発表しました。既存のクライアントはそのEPプレフィックスの登録を解除する場合、サーバーはその発表を撤回します。
Before its first operational use, each Client must obtain one or more EPs from its VPC as well as the companion prefixes associated with the VPC overlay network (see Section 5.1). The Client must also obtain a certificate and a public/private key pair from the VPC that it can later use to prove ownership of its EPs. This implies that each VPC must run its own public key infrastructure to be used only for the purpose of verifying its customers' claimed right to use an EP. Hence, the VPC need not coordinate its public key infrastructure with any other organization.
その第一の演算に使用する前に、各クライアントは、1つまたは複数のそのVPCからのEPだけでなく、VPCオーバーレイネットワークに関連付けられたコンパニオンプレフィックスを取得する必要があります（5.1節を参照してください）。クライアントはまた、後でそののEPの所有権を証明するために使用することができVPCから証明書と公開鍵/秘密鍵のペアを取得する必要があります。これは、各VPCだけEPを使用するには、顧客のクレーム権利を検証する目的で使用されるように自身の公開鍵インフラストラクチャを実行しなければならないことを意味します。したがって、VPCは他の組織とその公開鍵インフラストラクチャを調整する必要はありません。
Upon startup, the Client sends an SCMP Router Solicitation (SRS) message to the VPC overlay network subnet-router anycast address to discover the nearest Relay. The Relay will return an SCMP Router Advertisement (SRA) message that lists the locator addresses of one or more nearby Servers. (This list is analogous to the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Potential Router List (PRL) [RFC5214].)
起動時に、クライアントは最も近いリレーを発見するためにVPCオーバーレイネットワークサブネットルータエニーキャストアドレスにSCMPルータ要請（SRS）メッセージを送信します。リレーは、一つ以上の近くのサーバーのロケータアドレスをリストSCMPルータアドバタイズメント（SRA）のメッセージを返します。 （このリストは、サイト内の自動トンネルは、プロトコル（ISATAP）潜在的なルータリスト（PRL）[RFC5214]をアドレッシングに似ています。）
After the Client receives an SRA message from the nearby Relay listing the locator addresses of nearby Servers, it initiates a short transaction with one of the Servers carried by a reliable transport protocol such as TCP in order to establish a bidirectional tunnel-neighbor relationship. The protocol details of the transaction are specific to the VPC, and hence out of scope for this document.
クライアントは、近くのサーバーのロケータアドレスをリスト近くのリレーからSRAメッセージを受信した後、それは双方向のトンネル隣接関係を確立するために、TCPのような信頼性の高いトランスポートプロトコルによって運ばサーバの1つで短いトランザクションを開始します。トランザクションのプロトコルの詳細は、この文書のために、ひいては範囲外VPCに特異的です。
Note that it is essential that the Client select one and only one Server. This is to allow the VPC overlay network mapping system to have one and only one active EP-to-Server mapping at any point in time, which shares fate with the Server itself. If this Server fails, the Client can select a new one that will automatically update the VPC overlay network mapping system with a new EP-to-Server mapping.
クライアントが、唯一のサーバーを選択することが不可欠であることに注意してください。これは、VPCオーバーレイネットワークマッピングシステムは、1およびServer自体で運命を共有し、任意の時点、1つだけのアクティブEP-サーバーへのマッピングを持つことができるようにすることです。このサーバに障害が発生した場合、クライアントは自動的に新しいEPからサーバへのマッピングにVPCオーバレイネットワークマッピングシステムを更新する新しいものを選択することができます。
Following the IRON initialization detailed in Section 5, IAs engage in the steady-state process of receiving and forwarding packets. All IAs forward encapsulated packets over the IRON using the mechanisms of VET [INTAREA-VET] and SEAL [INTAREA-SEAL], while Relays (and in some cases Servers) additionally forward packets to and from the native IPv6 and IPv4 Internets. IAs also use SCMP to coordinate with other IAs, including the process of sending and receiving redirect messages, error messages, etc. (Note however that an IA must not send an SCMP message in response to an SCMP error message.) Each IA operates as specified in the following sub-sections.
セクション5に詳述IRONの初期化に続いて、IASは、パケットを受信および転送の定常状態プロセスに従事する。一方、リレー（場合によってサーバーに）すべてのIASは、前方さらにフォワードパケットがおよびネイティブIPv6とIPv4インターネットのから、[INTAREA-SEAL] [INTAREA-VET] VETのメカニズムを使用して、IRONを介してパケットをカプセル化及びシール。 IASはまた、（IAは、SCMPのエラーメッセージに応答して、SCMPメッセージを送信してはならないことに注意してください。）等を送信およびリダイレクトメッセージを受信する処理を含む他の発行機関、エラーメッセージ、で調整するSCMPを使用する各IAが動作するように以下のサブセクションで指定されました。
After selecting its Server as specified in Section 5.3, the Client should register each of its ISP connections with the Server for multihoming purposes. To do so, it sends periodic beacons (e.g., SRS messages) to its Server via each of its ISPs to establish additional tunnel-neighbor state. This implies that a single tunnel-neighbor identifier (i.e., a "nonce") is used to represent the set of all ISP paths between the Client and the Server. Therefore, the nonce names this "bundle" of ISP paths.
5.3節で指定されたように、そのサーバーを選択した後、クライアントは、マルチホーミングの目的のためにサーバーとのISP接続のそれぞれを登録する必要があります。そのためには、追加のトンネル隣人状態を確立するために、そのISPのそれぞれを経由してそのサーバーに定期的にビーコン（例えば、SRSのメッセージ）を送信します。これは、単一のトンネル隣接識別子（すなわち、「ナンス」）は、クライアントとサーバー間のすべてのISP経路のセットを表すために使用されることを意味します。 ISPの経路のため、ナンス名この「バンドル」。
If the Client ceases to receive acknowledgements from its Server via a specific ISP connection, it marks the Server as unreachable from that address and therefore over that ISP connection. (The Client should also inform its Server of this outage via one of its working ISP connections.) If the Client ceases to receive acknowledgements from its Server via multiple ISP connections, it marks the Server as unusable and quickly attempts to register with a new Server. The act of registering with a new Server will automatically purge the stale mapping state associated with the old Server, since dynamic routing will propagate the new client/server relationship to the VPC overlay network Relay Routers.
クライアントは、特定のISP接続を介してそのサーバーからの確認応答を受信しなくなった場合は、そのアドレスから到達不能として、したがって、そのISP接続経由でサーバをマーク。 （クライアントはまた、その作業ISP接続のうちの1つを介して、この停電のそのサーバーに通知する必要があります。）クライアントが複数のISP接続を介してそのサーバーからの確認応答を受信しなくなった場合は、それが使用できないようにサーバーをマークし、すぐに新しいサーバーに登録しよう。ダイナミックルーティングがVPCオーバーレイネットワークリレールータへの新しいクライアント/サーバ関係を伝播するので、自動的に、古いサーバーに関連付けられた古いマッピング状態をパージする新しいサーバーを登録する行為。
When an end system in an EUN sends a flow of packets to a correspondent, the packets are forwarded through the EUN via normal routing until they reach the Client, which then tunnels the initial packets to its Server as the next hop. In particular, the Client encapsulates each packet in an outer header with its locator as the source address and the locator of its Server as the destination address. Note that after sending the initial packets of a flow, the Client may receive important SCMP messages, such as indications of PMTU limitations, redirects that point to a better next hop, etc.
EUNにおけるエンドシステムが対応するパケットのフローを送信するとき、彼らはその後、次ホップとして、そのサーバーへの初期パケットをトンネルクライアントに達するまで、パケットは通常のルーティングを介してEUNを通じて転送されます。具体的には、クライアントは、そのソースアドレスとしてロケータ及び宛先アドレスとしてのサーバのロケータと外部ヘッダ中の各パケットをカプセル化します。フローの最初のパケットを送信した後、クライアントは、PMTUの制限の指標として重要SCMPメッセージを受信してもよいことに留意されたい、より良い次ホップなどにその点をリダイレクト
The Client uses the mechanisms specified in VET and SEAL to encapsulate each forwarded packet. The Client further uses the SCMP protocol to coordinate with Servers, including accepting redirects and other SCMP messages. When the Client receives an SCMP message, it checks the nonce field of the encapsulated packet-in-error to verify that the message corresponds to the tunnel-neighbor state for its Server and accepts the message if the nonce matches. (Note however that the outer source and destination addresses of the packet-in-error may be different than those in the original packet due to possible Server and/or Relay address rewritings.)
クライアントは、各転送されたパケットをカプセル化するVETとシールで指定されたメカニズムを使用しています。クライアントは、さらに受け入れリダイレクトと他のSCMPメッセージを含むサーバと調整するSCMPプロトコルを使用します。クライアントはSCMPメッセージを受信すると、メッセージは、そのサーバ用のトンネル隣接状態に対応し、ノンスが一致する場合、メッセージを受け付けることを確認するために、カプセル化されたパケットにおけるエラーのノンスフィールドをチェックします。 （パケット・イン・エラーの外送信元アドレスと宛先アドレスが原因の可能なサーバ及び/又は中継アドレス書き換えに元のパケットのものと異なってもよいことに注意してください。）
After the Server is initialized, it responds to SRSs from Clients by sending SRAs. When the Server receives a SEAL-encapsulated packet from one of its Client tunnel neighbors, it examines the inner destination address. If the inner destination address is not an EPA, the Server decapsulates the packet and forwards it unencapsulated into the Internet if it is able to do so without loss due to ingress filtering. Otherwise, the Server re-encapsulates the packet (i.e., it removes the outer header and replaces it with a new outer header of the same address family) and sets the outer destination address to the locator address of a Relay within its VPC overlay network. It then forwards the re-encapsulated packet to the Relay, which will, in turn, decapsulate it and forward it into the Internet.
サーバーが初期化された後、それはのSRAを送信することで、クライアントからのSRSに応答します。サーバは、そのクライアントトンネルネイバーのいずれかからシールカプセル化されたパケットを受信すると、内部宛先アドレスを調べます。内部宛先アドレスがEPAでない場合、サーバは、原因イングレスフィルタリングを失うことなく、そうすることができれば、それはインターネットにカプセル化されていないパケットや転送のカプセル化を解除します。そうでない場合、サーバはパケットを再カプセル化する（すなわち、それは外側のヘッダを除去し、同じアドレスファミリーの新たな外部ヘッダに置き換える）、そのVPC用オーバレイネットワーク内の中継のロケータアドレスに外側の宛先アドレスを設定します。その後、今度は、それをデカプセル化し、インターネットにそれを転送するリレーに再カプセル化されたパケットを転送します。
If the inner destination address is an EPA, however, the Server rewrites the outer source address to one of its own locator addresses and rewrites the outer destination address to the subnet-router anycast address taken from the companion prefix associated with the inner destination address (where the companion prefix of the same address family as the outer IP protocol is used). The Server then forwards the revised encapsulated packet into the Internet via a default or more specific route, where it will be directed to the closest Relay within the destination VPC overlay network. After sending the packet, the Server may then receive an SCMP error or redirect message from a Relay/Server within the destination VPC overlay network. In that case, the Server verifies that the nonce in the message matches the Client that sent the original inner packet and discards the message if the nonce does not match. Otherwise, the Server re-encapsulates the SCMP message in a new outer header that uses the source address, destination address, and nonce parameters associated with the Client's tunnel-neighbor state; it then forwards the message to the Client. This arrangement is necessary to allow SCMP messages to flow through any NATs on the path.
内部宛先アドレスがEPAである場合、ただし、サーバーは、（独自のロケータアドレスの1つに、外側のソースアドレスを書き換えると内側宛先アドレスに関連付けられたコンパニオン・プレフィックスから採取したサブネット・ルータのエニーキャストアドレスに外側の宛先アドレスを書き換えます外側のIPプロトコルと同じアドレスファミリのコンパニオン接頭辞が使用されている場合）。サーバーは、それが先VPCオーバーレイネットワーク内で最も近いリレーに送られますデフォルト以上の特定のルートを経由してインターネットに改訂されたカプセル化されたパケットを転送します。パケットを送信した後、サーバは、次に、SCMPエラーを受け取ることができるか、宛先VPC用オーバレイネットワーク内のリレー/サーバからのメッセージをリダイレクトします。その場合、サーバは、メッセージ内のnonceが元の内部パケットを送信したクライアントに一致し、ノンスが一致しない場合、メッセージを廃棄することを検証します。そうでなければ、サーバ送信元アドレス、宛先アドレス、およびクライアントのトンネル隣接状態に関連付けられたノンスのパラメータを使用して新しい外部ヘッダ中のSCMPメッセージは、再カプセル化します。それは、その後、クライアントにメッセージを転送します。この構成は、SCMPメッセージは、経路上の任意のNATを通って流れることができるようにする必要があります。
When a Server ('A') receives a SEAL-encapsulated packet from a Relay or from the Internet, if the inner destination address matches an EP in its FIB, 'A' re-encapsulates the packet in a new outer header and forwards it to a Client ('B'), which, in turn, decapsulates the packet and forwards it to the correct end system in the EUN. However, if 'B' has left notice with 'A' that it has moved to a new Server ('C'), 'A' will instead forward the packet to 'C' and also send an SCMP redirect message back to the source of the packet. In this way, 'B' can leave behind forwarding information when changing between Servers 'A' and 'C' (e.g., due to mobility events) without exposing packets to loss.
サーバー（「A」）はリレーから又はインターネットからシールカプセル化されたパケットを受信したときに、内側宛先アドレスがそのFIBにEPと一致する場合、 '新しい外部ヘッダでパケットを再カプセル化し、それを転送します次に、パケットをデカプセル化し、EUNにおける正しいエンドシステムに転送し、クライアント（「B」）へ。しかし、「B」は、それが新しいサーバー（「C」）に移動したことを「A」との通知を残している場合、「」の代わりに「C」にパケットを転送し、また、SCMPバックソースにメッセージをリダイレクト送りますパケットの。このように、「B」が損失パケットをさらすことなく、サーバ「A」と「C」（例えば、モビリティに起因する事象）の間で変化するときに情報を転送するの背後に残すことができます。
After each Relay has synchronized its VPs (see Section 5.1) it advertises the full set of the company's VPs and companion prefixes into the IPv4 and IPv6 Internet BGP routing systems. These prefixes will be represented as ordinary routing information in the BGP, and any packets originating from the IPv4 or IPv6 Internet destined to an address covered by one of the prefixes will be forwarded to one of the VPC overlay network's Relays.
各リレーは、そのVPのを同期した後、それはIPv4とIPv6インターネットBGPルーティングシステムに、同社の仮想プロセッサとコンパニオンプレフィックスのフルセットをアドバタイズ（5.1節を参照してください）。これらのプレフィックスは、BGPにおける通常のルーティング情報として表現され、プレフィックスのいずれかによって覆わアドレス宛てのIPv4またはIPv6インターネットに由来する任意のパケットは、VPCオーバレイネットワークのリレーのいずれかに転送されます。
When a Relay receives a packet from the Internet destined to an EPA covered by one of its VPs, it behaves as an ordinary IP router. In particular, the Relay looks in its FIB to discover a locator of the Server that serves the EP covering the destination address. The Relay then simply encapsulates the packet with its own locator as the outer source address and the locator of the Server as the outer destination address and forwards the packet to the Server.
リレーは、その仮想プロセッサの一つでカバーEPA宛のインターネットからのパケットを受信すると、通常のIPルータとして動作します。特に、リレーは、宛先アドレスをカバーEPを提供していますサーバーのロケータを発見するためにそのFIBに見えます。リレーは、単にそれ自身の外側のソースアドレスとしてロケータと外側宛先アドレスとしてサーバのロケータでパケットをカプセル化し、サーバにパケットを転送します。
When a Relay receives a packet from the Internet destined to one of its subnet-router anycast addresses, it discards the packet if it is not SEAL encapsulated. If the packet is an SCMP SRS message, the Relay instead sends an SRA message back to the source listing the locator addresses of nearby Servers then discards the message. The Relay otherwise discards all other SCMP messages.
リレーは、そのサブネットルータエニーキャストアドレスの1つに宛てインターネットからのパケットを受信すると、それがカプセル化されたシールされていない場合、そのパケットを破棄します。パケットがSCMP SRSメッセージがある場合は、リレーではなく、メッセージを破棄バック近くのサーバーのロケータアドレスをソースリストにSRAメッセージを送信します。リレーは、そうでない場合は、他のすべてのSCMPメッセージを破棄します。
If the packet is an ordinary SEAL packet (i.e., one that encapsulates an inner packet), the Relay sends an SCMP redirect message of the same address family back to the source with the locator of the Server that serves the EPA destination in the inner packet as the redirected target. The source and destination addresses of the SCMP redirect message use the outer destination and source addresses of the original packet, respectively. After sending the redirect message, the Relay then rewrites the outer destination address of the SEAL-encapsulated packet to the locator of the Server and forwards the revised packet to the Server. Note that in this arrangement, any errors that occur on the path between the Relay and the Server will be delivered to the original source but with a different destination address due to this Relay address rewriting.
パケットは通常SEALパケット（インナパケットをカプセル化すなわち1）である場合、リレーはSCMPは、内部パケットでEPA先を提供していますサーバーのロケータバックソースに同じアドレスファミリーのリダイレクトメッセージを送信します。リダイレクト対象として。 SCMPの送信元および宛先アドレスは、メッセージが、それぞれ、元のパケットの外側の宛先および送信元アドレスを使用してリダイレクトします。リダイレクトメッセージを送信した後、リレーは、次にサーバーのロケータにシールカプセル化されたパケットの外側の宛先アドレスを書き換えてサーバに改訂されたパケットを転送します。この構成では、リレーとサーバとの間の経路上に発生したエラーが原因書き換えこのリレー・アドレスに元のソースではなく、異なる宛先アドレスに配信されることに留意されたいです。
The IRON supports communications when one or both hosts are located within EP-addressed EUNs, regardless of whether the EPs are provisioned by the same VPC or by different VPCs. When both hosts are within IRON EUNs, route redirections that eliminate unnecessary Servers and Relays from the path are possible. When only one host is within an IRON EUN, however, route optimization cannot be used. The following sections discuss the two scenarios.
一方または両方のホストにかかわらずEPSは同じVPCによって、または異なるのVPCによってプロビジョニングされているかどうかの、EP-対処EUNs内に位置するとき鉄が通信をサポートします。両方のホストがIRON EUNs内にある場合、パスから不要なサーバーとリレーを排除するルートリダイレクションが可能です。 1つのホストのみがIRON EUN内であれば、しかし、ルート最適化を使用することはできません。次のセクションでは、2つのシナリオについて説明します。
When both hosts are within IRON EUNs, it is sufficient to consider the scenario in a unidirectional fashion, i.e., by tracing packet flows only in the forward direction from source host to destination host. The reverse direction can be considered separately and incurs the same considerations as for the forward direction.
両方のホストがIRON EUNs内にある場合、それは一方向様式でのシナリオを検討するのに十分である、すなわち、パケットをトレースすることによってのみ、宛先ホストに送信元ホストから順方向に流れます。逆方向を別々に考慮し、順方向と同じ考察を招くことができます。
In this scenario, the initial packets of a flow produced by a source host within an EUN connected to the IRON by a Client must flow through both the Server of the source host and a Relay of the destination host, but route optimization can eliminate these elements from the path for subsequent packets in the flow. Figure 6 shows the flow of initial packets from host A to host B within two IRON EUNs (the same scenario applies whether the two EUNs are within the same VPC overlay network or different overlay networks).
このシナリオでは、EUN内のソースホストによって生成される流れの最初のパケットがクライアントによってIRONに接続されたソースホストのサーバと宛先ホストのリレーの両方を通って流れなければならないが、ルート最適化は、これらの要素を排除することができますフロー内の後続パケット用のパスから。図6は、2つのIRON EUNs（二EUNsが同じVPCオーバーレイネットワークまたは異なるオーバレイネットワーク内にあるかどうか、同じシナリオが適用される）内のBをホストするホストAからの最初のパケットの流れを示しています。
________________________________________
.-( .-. )-.
.-( ,-( _)-. )-.
.-( +========+(_ (_ +=====+ )-.
.( || (_|| Internet ||_) || ).
.( || ||-(______)-|| vv ).
.( +--------++--+ || || +------------+ ).
( +==>| Server(A) | vv || | Server(B) |====+ )
( // +---------|\-+ +--++----++--+ +------------+ \\ )
( // .-. | \ | Relay(B) | .-. \\ )
( //,-( _)-. | \ +-v----------+ ,-( _)-\\ )
( .||_ (_ )-. | \____| .-(_ (_ ||. )
( _|| ISP A .) | (__ ISP B ||_))
( ||-(______)-' | (redirect) `-(______)|| )
( || | | | vv )
( +-----+-----+ | +-----+-----+ )
| Client(A) | <--+ | Client(B) |
+-----+-----+ The IRON +-----+-----+
| ( (Overlaid on the Native Internet) ) |
.-. .-( .-) .-.
,-( _)-. .-(________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ IRON EUN B )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 6: Initial Packet Flow before Redirects
図6：リダイレクト前の初期のパケットフロー
With reference to Figure 6, host A sends packets destined to host B via its network interface connected to EUN A. Routing within EUN A will direct the packets to Client(A) as a default router for the EUN, which then uses VET and SEAL to encapsulate them in outer headers with its locator address as the outer source address and the locator address of Server(A) as the outer destination address. Client(A) then simply forwards the encapsulated packets into its ISP network connection that provided its locator. The ISP will forward the encapsulated packets into the Internet without filtering since the (outer) source address is topologically correct. Once the packets have been forwarded into the Internet, routing will direct them to Server(A).
図6を参照すると、ホストAは、その後、VETシールを使用EUN、デフォルトルータとしてクライアント（A）にパケットを指示するEUN A内EUN A.ルーティングに接続されたネットワークインターフェースを介してホストBに宛てのパケットを送信します外側の宛先アドレスとして、外側のソースアドレス及びサーバ（A）のロケータアドレスとしてそのロケータアドレスとアウターヘッダでそれらを封入します。クライアント（A）は、単にそのロケータを提供し、そのISPネットワーク接続にカプセル化されたパケットを転送します。 （外側の）送信元アドレスがトポロジー的に正しいので、ISPは、フィルタリングなしでインターネットにカプセル化されたパケットを転送します。パケットがインターネットに転送された後は、ルーティングがサーバ（A）にそれらを指示します。
Server(A) receives the encapsulated packets from Client(A) then rewrites the outer source address to one of its own locator addresses and rewrites the outer destination address to the subnet-router anycast address of the appropriate address family associated with the inner destination address. Server(A) then forwards the revised encapsulated packets into the Internet, where routing will direct them to Relay(B), which services the VPC overlay network associated with host B.
サーバ（A）は、クライアント（A）は、独自のロケータアドレスの1つに外側のソースアドレスが書き換えからカプセル化されたパケットを受信し、内部宛先アドレスに関連付けられた適切なアドレスファミリーのサブネットルータエニーキャストアドレスに外側宛先アドレスを書き換えます。サーバ（A）をホストBに関連付けられたVPCオーバレイネットワークサービスルーティングは、それらが（B）は、中継するように指示するインターネット、に改訂されたカプセル化されたパケットを転送します
Relay(B) will intercept the encapsulated packets from Server(A) then check its FIB to discover an entry that covers inner destination address B with Server(B) as the next hop. Relay(B) then returns SCMP redirect messages to Server(A) (*), rewrites the outer destination address of the encapsulated packets to the locator address of Server(B), and forwards these revised packets to Server(B).
リレー（B）は（A）を次のホップとしてサーバ（B）と内部宛先アドレスBをカバーするエントリを発見するために、そのFIBをチェックサーバからカプセル化されたパケットを傍受します。リレー（B）を、SCMPは、サーバ（A）（*）にメッセージをリダイレクト返すサーバ（B）のロケータアドレスにカプセル化されたパケットの外側の宛先アドレスを書き換え、およびサーバ（B）に、これらの改訂パケットを転送します。
Server(B) will receive the encapsulated packets from Relay(B) then check its FIB to discover an entry that covers destination address B with Client(B) as the next hop. Server(B) then re-encapsulates the packets in a new outer header that uses the source address, destination address, and nonce parameters associated with the tunnel-neighbor state for Client(B). Server(B) then forwards these re-encapsulated packets into the Internet, where routing will direct them to Client(B). Client(B) will, in turn, decapsulate the packets and forward the inner packets to host B via EUN B.
サーバ（B）は、ネクストホップとしてクライアントと宛先アドレスB（B）を覆うエントリを発見するために、そのFIBをチェックし、その後リレー（B）からのカプセル化されたパケットを受信します。サーバ（B）は、ソースアドレス、宛先アドレス、およびクライアント（B）のためのトンネルの隣接状態に関連付けられたノンスのパラメータを使用して新しい外部ヘッダ内のパケットを再カプセル化します。サーバー（B）は、ルーティングは、クライアント（B）にそれらを指示する場所を、インターネットにこれらの再カプセル化されたパケットを転送します。クライアント（B）は、今度は、パケットをデカプセル化し、EUN Bを介してBをホストする内部パケットを転送します
(*) Note that after the initial flow of packets, Server(A) will have received one or more SCMP redirect messages from Relay(B) listing Server(B) as a better next hop. Server(A) will, in turn, forward the redirects to Client(A), which will establish unidirectional tunnel-neighbor state and thereafter forward its encapsulated packets directly to the locator address of Server(B) without involving either Server(A) or Relay(B), as shown in Figure 7.
（*）パケットの最初の流れの後に、サーバ（A）が一つ以上のSCMPより良いネクストホップとしてサーバ（B）のリストリレーからメッセージ（B）をリダイレクトを受信したことに注意してください。サーバ（A）、今度は、クライアントへの（A）にリダイレクトを転送する、サーバ（A）のいずれかを伴うことなく、サーバ（B）のロケータアドレスに直接フォワードその後、そのカプセル化されたパケットを一方向トンネルネイバー状態を確立しますまたは図7に示すように、リレー（B）。
________________________________________
.-( .-. )-.
.-( ,-( _)-. )-.
.-( +=============> .-(_ (_ )-.======+ )-.
.( // (__ Internet _) || ).
.( // `-(______)-' vv ).
.( // +------------+ ).
( // | Server(B) |====+ )
( // +------------+ \\ )
( // .-. .-. \\ )
( //,-( _)-. ,-( _)-\\ )
( .||_ (_ )-. .-(_ (_ ||. )
( _|| ISP A .) (__ ISP B ||_))
( ||-(______)-' `-(______)|| )
( || | | vv )
( +-----+-----+ The IRON +-----+-----+ )
| Client(A) | (Overlaid on the native Internet) | Client(B) |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-( .-) .-.
,-( _)-. .-(________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ IRON EUN B )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 7: Sustained Packet Flow after Redirects
図7：リダイレクトした後、パケットフローを持続
When one host is within an IRON EUN and the other is in a non-IRON EUN (i.e., one that connects to the native Internet instead of the IRON), the IA elements involved depend on the packet-flow directions. The cases are described in the following sub-sections.
一つのホストは、IRON EUN内にあり、他方が非IRON EUN（代わりIRONのネイティブインターネットに接続され、すなわち、1）であるとき、関係IA要素は、パケットフローの方向に依存します。場合によっては、以下のサブセクションで説明されています。
Figure 8 depicts the IRON reference operating scenario for packets flowing from host A in an IRON EUN to host B in a non-IRON EUN.
図8は、非IRON EUNにBをホストするIRON EUNのホストAから流れるパケットのIRON基準動作シナリオを示します。
_________________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | Relay(A) |--------------+ )-.
.( +------------+ \ ).
.( +=======>| Server(A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // The IRON ) \ )
( // .-. ) \ .-. )
( //,-( _)-. ) \ ,-( _)-. )
( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. )
( _|| ISP A ) ) (_ | ISP B ))
( ||-(______)-' ) |-(______)-' )
( || | )-. v | )
( +-----+ ----+ )-. +-----+-----+ )
| Client(A) |)-. | Router B |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-(____________________________________)-. .-.
,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_non-IRON EUN B)
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 8: From IRON Host A to Non-IRON Host B
図8：IRONホストAからの非IRONホストBへ
In this scenario, host A sends packets destined to host B via its network interface connected to IRON EUN A. Routing within EUN A will direct the packets to Client(A) as a default router for the EUN, which then uses VET and SEAL to encapsulate them in outer headers with its locator address as the outer source address and the locator address of Server(A) as the outer destination address. The ISP will pass the packets without filtering since the (outer) source address is topologically correct. Once the packets have been released into the native Internet, routing will direct them to Server(A).
このシナリオでは、ホストAは、その後にVETシールを使用EUN、デフォルトルータとしてクライアント（A）にパケットを指示するEUN A内IRON EUN A.ルーティングに接続されたネットワークインターフェースを介してホストBに宛てのパケットを送信します外側の宛先アドレスとして、外側のソースアドレスおよびサーバのロケータアドレス（A）としてのロケータアドレスと外側のヘッダーにそれらをカプセル化します。 （外側の）送信元アドレスがトポロジー的に正しいので、ISPは、フィルタリングなしでパケットを通過します。パケットがネイティブインターネット中に放出されると、ルーティングがサーバ（A）にそれらを指示します。
Server(A) receives the encapsulated packets from Client(A) then re-encapsulates and forwards them to Relay(A), which simply decapsulates them and forwards the unencapsulated packets into the Internet. Once the packets are released into the Internet, routing will direct them to the final destination B. (Note that Server(A) and Relay(A) are depicted in Figure 8 as two halves of a unified gateway. In that case, the "forwarding" between Server(A) and Relay(A) is a zero-instruction imaginary operation within the gateway.)
サーバ（A）は、再カプセル化クライアント（A）からカプセル化されたパケットを受信し、（A）のリレーに転送し、単にそれらをデカプセル化し、インターネットにカプセル化されていないパケットを転送します。パケットはインターネット中に放出されると、ルーティングは、サーバ（A）及びリレー（A）に注意してください（最終目的地Bにそれらを指示する統一されたゲートウェイの両半分として図8に示されている。その場合に、 "サーバ（A）及びリレー（A）との間に」転送するゲートウェイ内ゼロ命令仮想動作です。）
This scenario always involves a Server and Relay owned by the VPC that provides service to IRON EUN A. Therefore, it imparts a cost that would need to be borne by either the VPC or its customers.
このシナリオは、常にそのためIRON EUN Aにサービスを提供してVPCが所有するサーバおよびリレーは、それはVPCまたはその顧客のいずれかが負担する必要があるであろうコストを与える必要。
Figure 9 depicts the IRON reference operating scenario for packets flowing from host B in an Non-IRON EUN to host A in an IRON EUN.
図9は、IRON EUNにAをホストする非鉄EUN、ホストBから流れるパケットのIRON基準動作シナリオを示します。
_______________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | Relay(A) |<-------------+ )-.
.( +------------+ \ ).
.( +========| Server(A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // The IRON ) \ )
( // .-. ) \ .-. )
( //,-( _)-. ) \ ,-( _)-. )
( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. )
( _|| ISP A ) ) (_ | ISP B ))
( ||-(______)-' ) |-(______)-' )
( vv | )-. | | )
( +-----+ ----+ )-. +-----+-----+ )
| Client(A) |)-. | Router B |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-(____________________________________)-. .-.
,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_non-IRON EUN B)
`-(______)-' `-(_______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 9: From Non-IRON Host B to IRON Host A
図9：非IRONホストBからの鉄のホストAへ
In this scenario, host B sends packets destined to host A via its network interface connected to non-IRON EUN B. Routing will direct the packets to Relay(A), which then forwards them to Server(A) using encapsulation if necessary.
このシナリオでは、ホストBが非IRON EUN B.経路に接続されたネットワークインタフェースを介してホスト宛てのパケットを送信し、その後、必要に応じてカプセル化を使用して、サーバ（A）に転送した、（A）のリレーにパケットを指示します。
Server(A) will then check its FIB to discover an entry that covers destination address A with Client(A) as the next hop. Server(A) then (re-)encapsulates the packets in an outer header that uses the source address, destination address, and nonce parameters associated with the tunnel-neighbor state for Client(A). Next, Server(A) forwards these (re-)encapsulated packets into the Internet, where routing will direct them to Client(A). Client(A) will, in turn, decapsulate the packets and forward the inner packets to host A via its network interface connected to IRON EUN A.
サーバ（A）は、次のホップなどのクライアント（A）と宛先アドレスAをカバーエントリを発見するためにそのFIBをチェックします。サーバ（A）を（再）送信元アドレス、宛先アドレス、およびクライアント（A）のためのトンネルの隣接状態に関連付けられたノンスパラメータを使用する外部ヘッダ内のパケットをカプセル化します。次に、サーバ（A）は、ルーティングは、クライアント（A）にそれらを指示する、インターネット、にこれらの（再）カプセル化されたパケットを転送します。クライアント（A）は、今度は、IRON EUN Aに接続されたネットワークインタフェースを介してホストにパケットをデカプセル化し、内部パケットを転送します
This scenario always involves a Server and Relay owned by the VPC that provides service to IRON EUN A. Therefore, it imparts a cost that would need to be borne by either the VPC or its customers.
このシナリオは、常にそのためIRON EUN Aにサービスを提供してVPCが所有するサーバおよびリレーは、それはVPCまたはその顧客のいずれかが負担する必要があるであろうコストを与える必要。
While IRON Servers and Relays can be considered as fixed infrastructure, Clients may need to move between different network points of attachment, connect to multiple ISPs, or explicitly manage their traffic flows. The following sections discuss mobility, multihoming, and traffic engineering considerations for IRON client routers.
IRONサーバおよびリレーは、固定インフラとして考えることができますが、クライアントは、添付ファイルの異なるネットワークポイント間を移動する必要が複数のISPに接続し、または明示的にトラフィックフローを管理することができます。次のセクションでは、IRONクライアントルータ用のモビリティ、マルチホーミング、およびトラフィックエンジニアリングの考慮事項について説明します。
When a Client changes its network point of attachment (e.g., due to a mobility event), it configures one or more new locators. If the Client has not moved far away from its previous network point of attachment, it simply informs its Server of any locator additions or deletions. This operation is performance sensitive and should be conducted immediately to avoid packet loss.
クライアント（モビリティイベントに起因例えば、）アタッチメントのそのネットワーク・ポイントを変更すると、それは1つ以上の新しいロケータを構成します。クライアントが遠く添付ファイルの以前のネットワークポイントから移動していない場合、それは単に任意のロケータ追加または削除のそのサーバーに通知します。この操作は、パフォーマンスに敏感であり、パケット損失を避けるために、すぐに実施されるべきです。
If the Client has moved far away from its previous network point of attachment, however, it re-issues the anycast discovery procedure described in Section 6.1 to discover whether its candidate set of Servers has changed. If the Client's current Server is also included in the new list received from the VPC, this provides indication that the Client has not moved far enough to warrant changing to a new Server. Otherwise, the Client may wish to move to a new Server in order to reduce routing stretch. This operation is not performance critical, and therefore can be conducted over a matter of seconds/ minutes instead of milliseconds/microseconds.
クライアントは、遠く離れた添付ファイルの以前のネットワーク点から移動した場合は、しかし、それは再発行する6.1節で説明したエニーキャスト発見手順をサーバーのその候補セットが変更されたかどうかを発見します。クライアントの現在のサーバーも、新しいリストに含まれている場合はVPCから受信し、これにより、クライアントは新しいサーバーへの変更を正当とするために十分移動していないという指示を提供します。そうでない場合、クライアントはルーティングのストレッチを減らすために、新しいサーバーに移動することもできます。この操作は、パフォーマンスクリティカルではないので、代わりにミリ秒/マイクロ秒/数分にわたって実施することができます。
To move to a new Server, the Client first engages in the EP registration process with the new Server, as described in Section 5.3. The Client then informs its former Server that it has moved by
5.3節で説明したように、新しいサーバーに移動するには、クライアントはまず、新しいサーバーでEPの登録プロセスに取り組んでいます。クライアントは、それが移動したかつてのサーバーに通知します
providing it with the locator address of the new Server; again, via a VPC-specific reliable transaction. The former Server will then garbage-collect the stale FIB entries when their lifetime expires.
新しいサーバーのロケータアドレスでそれを提供します。再び、VPC固有の信頼性の高い取引を介しました。彼らの寿命が満了したとき、元Serverは、古いFIBエントリをガベージコレクトされます。
This will allow the former Server to redirect existing correspondents to the new Server so that no packets are lost.
これには、パケットが失われないように、旧サーバーを新しいサーバーに既存の特派をリダイレクトすることができます。
A Client may register multiple locators with its Server. It can assign metrics with its registrations to inform the Server of preferred locators, and it can select outgoing locators according to its local preferences. Therefore, multihoming is naturally supported.
クライアントは、そのサーバーで複数のロケータを登録することができます。これは、好適なロケータのサーバーに通知するために、その登録してメトリックを割り当てることができ、そしてそれはその地域の好みに応じて、発信ロケータを選択することができます。したがって、マルチホーミングは自然にサポートされています。
A Client can dynamically adjust the priorities of its prefix registrations with its Server in order to influence inbound traffic flows. It can also change between Servers when multiple Servers are available, but should strive for stability in its Server selection in order to limit VPC network routing churn.
クライアントが動的にインバウンドトラフィックフローに影響を与えるために、そのサーバーとのプレフィックス登録の優先順位を調整することができます。これは、複数のサーバーが用意されていたときにも、サーバー間で変更することができますが、VPCネットワークルーティング解約を制限するために、そのサーバーの選択での安定性のために努力すべきです。
A Client can select outgoing locators, e.g., based on current Quality-of-Service (QoS) considerations such as minimizing one-way delay or one-way delay variance.
クライアントは、一方向遅延又は片道遅延変動を最小化する現在のサービス品質（QoS）の考慮に基づいて、例えば、発信ロケータを選択することができます。
As new link-layer technologies and/or service models emerge, customers will be motivated to select their service providers through healthy competition between ISPs. If a customer's EUN addresses are tied to a specific ISP, however, the customer may be forced to undergo a painstaking EUN renumbering process if it wishes to change to a different ISP [RFC4192][RFC5887].
新しいリンク層技術および/またはサービスモデルが登場したよう、顧客がISP間の健全な競争を通じて、サービスプロバイダを選択するように動機づけされます。顧客のEUNアドレスが特定のISPに関連付けられている場合、それは別のISP [RFC4192] [RFC5887]に変更したい場合は、しかし、顧客は骨の折れるEUNのリナンバリングプロセスを受けることを余儀なくされることがあります。
When a customer obtains EP prefixes from a VPC, it can change between ISPs seamlessly and without need to renumber. If the VPC itself applies unreasonable costing structures for use of the EPs, however, the customer may be compelled to seek a different VPC and would again be required to confront a renumbering scenario. The IRON approach to renumbering avoidance therefore depends on VPCs conducting ethical business practices and offering reasonable rates.
お客様がVPCからEPプレフィックスを取得すると、それがシームレスかつリナンバリングしなくても、ISPの間で変更することができます。 VPC自体はのEPを使用するための不当なコスト構造を適用する場合は、しかし、顧客が別のVPCを模索せざるを得ないとすることができ、再びリナンバリングのシナリオに直面するために必要とされるであろう。リナンバリング回避へIRONアプローチは、したがって、倫理的なビジネス慣行を実施し、リーズナブルな料金を提供するのVPCに依存しています。
The Internet today consists of a global public IPv4 routing and addressing system with non-IRON EUNs that use either public or private IPv4 addressing. The latter class of EUNs connect to the public Internet via Network Address Translators (NATs). When a Client is located behind a NAT, it selects Servers using the same procedures as for Clients with public addresses, e.g., it can send SRS messages to Servers in order to get SRA messages in return. The only requirement is that the Client must configure its SEAL encapsulation to use a transport protocol that supports NAT traversal, namely UDP.
インターネット今日は、アドレッシング、パブリックまたはプライベートのいずれかのIPv4を使用する非鉄EUNsを持つグローバルパブリックIPv4ルーティングおよびアドレス指定システムで構成されています。 EUNsの後者のクラスは、翻訳者（NATのを）アドレス、ネットワークを介して公衆インターネットに接続します。クライアントがNATの背後に配置されている場合は、パブリックアドレスを持つクライアントの場合と同じ手順を使用してサーバを選択し、例えば、それは見返りにSRAメッセージを取得するために、サーバーにSRSメッセージを送ることができます。唯一の要件は、クライアントがNATトラバーサル、すなわちUDPをサポートするトランスポートプロトコルを使用するようにそのSEALカプセル化を設定しなければならないということです。
Since the Server maintains state about its Client customers, it can discover locator information for each Client by examining the UDP port number and IP address in the outer headers of the Client's encapsulated packets. When there is a NAT in the path, the UDP port number and IP address in each encapsulated packet will correspond to state in the NAT box and might not correspond to the actual values assigned to the Client. The Server can then encapsulate packets destined to hosts in the Client's EUN within outer headers that use this IP address and UDP port number. The NAT box will receive the packets, translate the values in the outer headers, then forward the packets to the Client. In this sense, the Server's "locator" for the Client consists of the concatenation of the IP address and UDP port number.
サーバーはそのクライアントの顧客についての状態を維持するので、それはクライアントのカプセル化されたパケットの外側ヘッダにUDPポート番号とIPアドレスを調べることによって、各クライアントのロケータ情報を発見することができます。 NATがパスに存在する場合、各カプセル化されたパケットにUDPポート番号とIPアドレスがNATボックス状態に対応し、クライアントに割り当てられた実際の値に対応しないかもしれません。サーバーは、このIPアドレスとUDPポート番号を使用し、外側のヘッダー内のクライアントのEUNのホスト宛てのパケットをカプセル化することができます。 NATボックスは、パケットを受信し、外側のヘッダーの値を変換し、クライアントにパケットを転送します。この意味では、クライアント用のサーバーの「ロケータは、」IPアドレスとUDPポート番号の連結で構成されています。
IRON does not introduce any new issues to complications raised for NAT traversal or for applications embedding address referrals in their payload.
IRONは、NATトラバーサルのためか、彼らのペイロードにアドレスの参照を埋め込むアプリケーション用に飼育合併症への新たな問題を導入しません。
IRON Servers and Relays are topologically positioned to provide Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) proxying for their Clients [RFC4605]. Further multicast considerations for IRON (e.g., interactions with multicast routing protocols, traffic scaling, etc.) will be discussed in a separate document.
IRONサーバおよびリレーは、位相幾何学[RFC4605]彼らのクライアントのためのインターネットグループ管理プロトコル（IGMP）/マルチキャストリスナ発見（MLD）プロキシを提供するように配置されています。 IRONための更なるマルチキャスト考慮事項（例えば、マルチキャストルーティングプロトコル、トラフィックスケーリング、等との相互作用）は、別の文書に説明します。
Each Client configures a locator that may be taken from an ordinary non-EPA address assigned by an ISP or from an EPA address taken from an EP assigned to another Client. In that case, the Client is said to be "nested" within the EUN of another Client, and recursive nestings of multiple layers of encapsulations may be necessary.
各クライアントは、ISPまたは別のクライアントに割り当てられたEPから取られたEPAアドレスから割り当てられた通常の非EPAアドレスから取得することができるロケータを構成します。その場合、クライアントは他のクライアントのEUN内に「ネスト」されると言われ、そしてカプセル化の複数の層の再帰的ネスティングが必要であってもよいです。
For example, in the network scenario depicted in Figure 10, Client(A) configures a locator EPA(B) taken from the EP assigned to EUN(B). Client(B) in turn configures a locator EPA(C) taken from the EP assigned to EUN(C). Finally, Client(C) configures a locator ISP(D) taken from a non-EPA address delegated by an ordinary ISP(D). Using this example, the "nested-IRON" case must be examined in which a host A, which configures the address EPA(A) within EUN(A), exchanges packets with host Z located elsewhere in the Internet.
例えば、図10に示されているネットワークのシナリオでは、クライアント（A）は、EUN（B）に割り当てられたEPから取らロケータEPA（B）を構成します。次にクライアント（B）は、EUN（C）に割り当てられたEPから取らロケータEPA（C）を構成します。最後に、クライアント（C）は、通常のISP（D）によって委任非EPAアドレスから取られたロケータISP（D）を構成します。この例を使用して、「ネストされた鉄」の場合は、EUN内のアドレスEPA（A）（A）を構成するホストAは、インターネットの他の場所に位置するホストZとパケットを交換する検討されなければなりません。
.-.
ISP(D) ,-( _)-.
+-----------+ .-(_ (_ )-.
| Client(C) |--(_ ISP(D) )
+-----+-----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN(C) ) e `-(______)-'
`-(______)-' l ___
| EPA(C) s => (:::)-.
+-----+-----+ .-(::::::::)
| Client(B) | .-(::::::::::::)-. +-----------+
+-----+-----+ (:::: The IRON ::::) | Relay(Z) |
| `-(::::::::::::)-' +-----------+
.-. `-(::::::)-' +-----------+
,-( _)-. | Server(Z) |
.-(_ (_ )-. +-----------+ +-----------+
(_ EUN(B) ) | Server(C) | +-----------+
`-(______)-' +-----------+ | Client(Z) |
| EPA(B) +-----------+ +-----------+
+-----+-----+ | Server(B) | +--------+
| Client(A) | +-----------+ | Host Z |
+-----------+ +-----------+ +--------+
| | Server(A) |
.-. +-----------+
,-( _)-. EPA(A)
.-(_ (_ )-. +--------+
(_ EUN(A) )---| Host A |
`-(______)-' +--------+
Figure 10: Nested EUN Example
図10：ネストEUN例
The two cases of host A sending packets to host Z, and host Z sending packets to host A, must be considered separately, as described below.
ホストA送信パケットの2つのケースがZをホストするために、以下に説明するように、ホストにパケットを送信ホストZは、別々に考慮しなければなりません。
Host A first forwards a packet with source address EPA(A) and destination address Z into EUN(A). Routing within EUN(A) will direct the packet to Client(A), which encapsulates it in an outer header with EPA(B) as the outer source address and Server(A) as the outer destination address then forwards the once-encapsulated packet into EUN(B). Routing within EUN(B) will direct the packet to Client(B), which encapsulates it in an outer header with EPA(C) as the outer source address and Server(B) as the outer destination address then forwards the twice-encapsulated packet into EUN(C). Routing within EUN(C) will direct the packet to Client(C), which encapsulates it in an outer header with ISP(D) as the outer source address and Server(C) as the outer destination address. Client(C) then sends this triple-encapsulated packet into the ISP(D) network, where it will be routed into the Internet to Server(C).
EUN（A）への最初の送信元アドレスEPA（A）と転送パケットおよび宛先アドレスZをホストします。外側の宛先アドレスが一旦カプセル化パケットを転送するようにEUN（A）内のルーティングは、外側のソースアドレス及びサーバ（A）としてEPAとアウターヘッダの中にカプセル化するクライアント（A）、（B）にパケットを指示しますEUNに（B）。 EUN（B）内のルーティングは、外側宛先アドレスとしてEPAとアウターヘッダの中にカプセル化し（B）、外側のソースアドレスおよびサーバとして（C）（B）が2回カプセル化パケットを転送するクライアントにパケットを指示しますEUN（C）へ。 EUN（C）内のルーティングは、外側宛先アドレスとして、外側のソースアドレスとサーバー（C）としてISP（D）とアウターヘッダの中にカプセル化し、クライアントにパケット（C）を、指示します。クライアント（C）は、それがサーバー（C）にインターネットにルーティングされるISP（D）ネットワーク、にこの三重カプセル化パケットを送信します。
When Server(C) receives the triple-encapsulated packet, it removes the outer layer of encapsulation and forwards the resulting twice-encapsulated packet into the Internet to Server(B). Next, Server(B) removes the outer layer of encapsulation and forwards the resulting once-encapsulated packet into the Internet to Server(A). Next, Server(A) checks the address type of the inner address 'Z'. If Z is a non-EPA address, Server(A) simply decapsulates the packet and forwards it into the Internet. Otherwise, Server(A) rewrites the outer source and destination addresses of the once-encapsulated packet and forwards it to Relay(Z). Relay(Z), in turn, rewrites the outer destination address of the packet to the locator for Server(Z), then forwards the packet and sends a redirect to Server(A) (which forwards the redirect to Client(A)). Server(Z) then re-encapsulates the packet and forwards it to Client(Z), which decapsulates it and forwards the inner packet to host Z. Subsequent packets from Client(A) will then use Server(Z) as the next hop toward host Z, which eliminates Server(A) and Relay(Z) from the path.
サーバー（C）は三重カプセル化されたパケットを受信すると、カプセルの外側の層を除去し、サーバ（B）に、インターネットに、得られた二回カプセル化パケットを転送します。次に、サーバ（B）は、カプセルの外側の層を除去し、サーバ（A）にインターネットに得一度カプセル化パケットを転送します。次に、サーバ（A）はインナーアドレス「Z」のアドレスタイプを確認します。 Zは非EPAアドレスがある場合は、サーバ（A）は、単にパケットをデカプセル化し、インターネットにそれを転送します。そうでなければ、サーバ（A）が一度カプセル化パケットの外側の送信元アドレスと宛先アドレスを書き換え、（Z）リレーに転送します。リレー（Z）は、今度は、そのパケットを転送し、（クライアントへのリダイレクト（A）を転送する）サーバ（A）へのリダイレクトを送信し、サーバー（Z）のロケータへのパケットの外側の宛先アドレスを書き換えます。サーバ（Z）、パケットを再カプセル化し、その後に向かって次のホップとしてサーバ（Z）を使用することをデカプセル化し、クライアント（A）からZ.後続パケットをホストする内部パケットを転送クライアント（Z）に転送しますパスからサーバ（A）及びリレー（Z）を排除Zを、ホスト。
Whether or not host Z configures an EPA address, its packets destined to host A will eventually reach Server(A). Server(A) will have a mapping that lists Client(A) as the next hop toward EPA(A). Server(A) will then encapsulate the packet with EPA(B) as the outer destination address and forward the packet into the Internet. Internet routing will convey this once-encapsulated packet to Server(B), which will have a mapping that lists Client(B) as the next hop toward EPA(B). Server(B) will then encapsulate the packet with EPA(C) as the outer destination address and forward the packet into the Internet. Internet routing will then convey this twice-encapsulated packet to Server(C), which will have a mapping that lists Client(C) as the next hop toward EPA(C). Server(C) will then encapsulate the packet with ISP(D) as the outer destination address and forward the packet into the Internet. Internet routing will then convey this triple-encapsulated packet to Client(C).
Zは、EPAアドレスを設定するホストかどうかにかかわらず、そのパケットは最終的にサーバ（A）に達するAをホストする運命。サーバ（A）は、EPA（A）の方へのネクストホップとしてクライアント（A）を示していますマッピングを持つことになります。サーバ（A）を外側の宛先アドレスとしてEPA（B）を用いてパケットをカプセル化し、インターネットへパケットを転送します。インターネットルーティングは、EPA（B）に向かって次のホップとしてクライアント（B）をリストのマッピングを持っている、サーバ（B）に、この一度カプセル化パケットを伝達します。サーバ（B）は、次いで、外側宛先アドレスとしてEPA（C）を用いてパケットをカプセル化し、インターネットへパケットを転送します。インターネットルーティングは、EPA（C）に向けてのネクストホップとしてクライアント（C）を示していますマッピングを持っているであろう、サーバー（C）に、この二度カプセル化されたパケットを伝えます。サーバ（C）は、次いで、外側宛先アドレスとしてISP（D）を用いてパケットをカプセル化し、インターネットへパケットを転送します。インターネットルーティングは、クライアント（C）に、このトリプルカプセル化されたパケットを伝えます。
When the triple-encapsulated packet arrives at Client(C), it strips the outer layer of encapsulation and forwards the twice-encapsulated packet to EPA(C), which is the locator address of Client(B). When Client(B) receives the twice-encapsulated packet, it strips the outer layer of encapsulation and forwards the once-encapsulated packet to EPA(B), which is the locator address of Client(A). When Client(A) receives the once-encapsulated packet, it strips the outer layer of encapsulation and forwards the unencapsulated packet to EPA(A), which is the host address of host A.
三重カプセル化パケットはクライアント（C）に到着すると、それはカプセルの外側の層を取り除き、クライアント（B）のロケータアドレスであるEPA（C）に二回カプセル化パケットを転送します。クライアント（B）は二回カプセル化されたパケットを受信すると、カプセルの外側の層を取り除き、クライアント（A）のロケータアドレスであるEPA（B）に一度カプセル化パケットを転送します。クライアント（A）が一度カプセル化されたパケットを受信すると、カプセルの外側の層を取り除き、ホストAのホストアドレスであるEPA（A）にカプセル化されていないパケットを転送します
The IRON architecture envisions a hybrid routing/mapping system that benefits from both the shortest-path routing afforded by pure dynamic routing systems and the routing-scaling suppression afforded by pure mapping systems. Therefore, IRON targets the elusive "sweet spot" that pure routing and pure mapping systems alone cannot satisfy.
IRONアーキテクチャは純粋な動的ルーティングシステム及び純マッピングシステムによって与えられるルーティングスケーリング抑制によって与えられる最短パスルーティングの両方から利益を得るハイブリッドルーティング/マッピングシステムを想定しています。したがって、IRONは満たすことができないだけではとらえどころのない「スイートスポット」という純粋なルーティングと純粋なマッピングシステムを対象としています。
The IRON system requires a deployment of new routers/servers throughout the Internet and/or provider networks to maintain well-balanced virtual overlay networks. These routers/servers can be deployed incrementally without disruption to existing Internet infrastructure and appropriately managed to provide acceptable service levels to customers.
IRONシステムは、バランスのとれた仮想オーバーレイネットワークを維持するために、インターネットおよび/またはプロバイダのネットワークを通じて新しいルータ/サーバの展開が必要です。これらのルータ/サーバは、既存のインターネットインフラストラクチャに中断することなくインクリメンタルに展開し、適切に顧客に許容可能なサービスレベルを提供するために管理することができます。
End-to-end traffic that traverses an IRON virtual overlay network may experience delay variance between the initial packets and subsequent packets of a flow. This is due to the IRON system allowing a longer path stretch for initial packets followed by timely route optimizations to utilize better next hop routers/servers for subsequent packets.
IRON仮想オーバーレイネットワークを通過するエンドツーエンドのトラフィックは、最初のパケットとフローの後続のパケット間の遅延変動が発生することがあります。これは、より良い、後続のパケットのネクストホップルータ/サーバを利用するためにタイムリーなルートの最適化に続いて、最初のパケットのための長いパスのストレッチを可能IRONシステムによるものです。
IRON virtual overlay networks also work seamlessly with existing and emerging services within the native Internet. In particular, customers serviced by IRON virtual overlay networks will receive the same service enjoyed by customers serviced by non-IRON service providers. Internet services already deployed within the native Internet also need not make any changes to accommodate IRON virtual overlay network customers.
IRON仮想オーバーレイネットワークもネイティブインターネット内の既存および新興のサービスとシームレスに連携します。特に、IRON仮想オーバーレイネットワークによってサービスの顧客は、非IRONサービスプロバイダによるサービスをお客様に楽しんで同じサービスを受信します。すでにネイティブインターネット内に配備インターネットサービスもIRON仮想オーバーレイネットワークの顧客に対応するために変更を加える必要はありません。
The IRON system operates between routers within provider networks and end user networks. Within these networks, the underlying paths traversed by the virtual overlay networks may comprise links that accommodate varying MTUs. While the IRON system imposes an additional per-packet overhead that may cause the size of packets to become slightly larger than the underlying path can accommodate, IRON routers have a method for naturally detecting and tuning out all instances of path MTU underruns. In some cases, these MTU underruns may need to be reported back to the original hosts; however, the system will also allow for MTUs much larger than those typically available in current Internet paths to be discovered and utilized as more links with larger MTUs are deployed.
鉄系は、プロバイダネットワークとエンドユーザのネットワーク内のルータとの間で動作します。これらのネットワーク内で、仮想オーバーレイネットワークによって横切ら基礎となるパスがのMTUを変える適応リンクを含んでいてもよいです。鉄系は、パケットのサイズが基礎のパスよりも若干大きくなることがあり、追加のパケットごとのオーバヘッドが収容できる課しながら、IRONルータは自然に検出し、パスMTUのアンダーランのすべてのインスタンスを調整するための方法を有しています。いくつかの場合において、これらのMTUアンダーランは、元のホストに報告する必要があるかもしれません。しかし、システムはまた、発見し、より大きなMTUで複数のリンクが展開されるように利用される現在のインターネット経路で一般的に利用可能なものよりはるかに大きいのMTUを可能にします。
Finally, and perhaps most importantly, the IRON system provides an in-built mobility management and multihoming capability that allows end user devices and networks to move about freely while both imparting minimal oscillations in the routing system and maintaining generally shortest-path routes. This mobility management is afforded through the very nature of the IRON customer/provider relationship, and therefore requires no adjunct mechanisms. The mobility management and multihoming capabilities are further supported by forward-path reachability detection that provides "hints of forward progress" in the same spirit as for IPv6 Neighbor Discovery (ND).
最後に、おそらく最も重要なのは、鉄系が提供する内蔵のモビリティ管理との両方がルーティングシステムに最小限の振動を付与すると、一般に最短パス経路を維持しながら、エンドユーザデバイスとネットワークが約自由に移動することを可能にするマルチホーム機能。このモビリティ管理はIRON顧客/プロバイダ関係の性質によって与えられるので、何の補助メカニズムを必要としません。モビリティ管理及びマルチホーミング機能は、さらに、IPv6近隣探索（ND）と同じ趣旨で、「前進のヒント」を提供往路到達可能性検出によって支持されています。
Considerations for the scalability of Internet Routing due to multihoming, traffic engineering, and provider-independent addressing are discussed in [RADIR]. Other scaling considerations specific to IRON are discussed in Appendix B.
マルチホーミング、トラフィックエンジニアリング、およびプロバイダに依存しない対処するインターネットルーティングのスケーラビリティに関する考慮事項は、[RADIR]で議論されています。 IRONに固有の他のスケーリングの考慮事項は、付録Bで説明されています
Route optimization considerations for mobile networks are found in [RFC5522].
モバイルネットワークの経路最適化に関する注意事項は、[RFC5522]に記載されています。
IRON builds upon the concepts of the RANGER architecture [RFC5720] [RFC6139], and therefore inherits the same set of related initiatives. The Internet Research Task Force (IRTF) Routing Research Group (RRG) mentions IRON in its recommendation for a routing architecture [RFC6115].
鉄レンジャーアーキテクチャ[RFC5720]、[RFC6139]の概念に基づいて構築、従って関連イニシアチブの同じセットを継承します。インターネットResearch Task Force（IRTF）のルーティング研究グループ（RRG）は、ルーティングアーキテクチャ[RFC6115]のためにその勧告にIRONに言及しています。
Virtual Aggregation (VA) [GROW-VA] and Aggregation in Increasing Scopes (AIS) [EVOLUTION] provide the basis for the Virtual Prefix concepts.
仮想アグリゲーション（VA）GROW-VA]および凝集をスコープ（AIS）を増加させる[EVOLUTION]仮想プレフィックスの概念の基礎を提供します。
Internet Vastly Improved Plumbing (Ivip) [IVIP-ARCH] has contributed valuable insights, including the use of real-time mapping. The use of Servers as mobility anchor points is directly influenced by Ivip's associated TTR mobility extensions [TTRMOB].
インターネット大幅に改善配管（Ivip）[IVIP-ARCH]はリアルタイムマッピングの使用を含む貴重な洞察力を、貢献してきました。モビリティアンカーポイントとしてサーバーを使用することは、直接Ivipの関連するTTRモビリティ拡張[TTRMOB]の影響を受けています。
[RO-CR] discusses a route optimization approach using a Correspondent Router (CR) model. The IRON Server construct is similar to the CR concept described in this work; however, the manner in which customer EUNs coordinate with Servers is different and based on the redirection model associated with NBMA links.
[RO-CR]はコレスポンデントルータ（CR）モデルを使用して、経路最適化アプローチについて説明します。 IRONサーバー構築物は、この作品で説明CRの概念に似ています。しかし、顧客EUNs、サーバと連携する方法は異なるとNBMAリンクに関連付けられたリダイレクションモデルに基づいています。
Numerous publications have proposed NAT traversal techniques. The NAT traversal techniques adapted for IRON were inspired by the Simple Address Mapping for Premises Legacy Equipment (SAMPLE) proposal [SAMPLE].
多数の刊行物は、NATトラバーサル技術を提案しています。 IRONに適合NATトラバーサル技法は、宅内レガシー機器のための簡単なアドレスマッピング（SAMPLE）案[SAMPLE]に触発されました。
Security considerations that apply to tunneling in general are discussed in [V6OPS-TUN-SEC]. Additional considerations that apply also to IRON are discussed in RANGER [RFC5720] [RFC6139], VET [INTAREA-VET] and SEAL [INTAREA-SEAL].
一般的に、トンネルに適用されるセキュリティ上の考慮事項は、[V6OPS-TUN-SEC]で議論されています。 IRONにも適用される追加の考慮事項は、RANGER [RFC5720] [RFC6139]、VET [INTAREA-VET]とシール[INTAREA-SEAL]で議論されています。
The IRON system further depends on mutual authentication of IRON Clients to Servers and Servers to Relays. This is accomplished through initial authentication exchanges followed by tunnel-neighbor nonces that can be used to detect off-path attacks. As for all Internet communications, the IRON system also depends on Relays acting with integrity and not injecting false advertisements into the BGP (e.g., to mount traffic siphoning attacks).
IRONシステムは、リレーにサーバーとサーバーにIRONクライアントの相互認証に依存します。これは、オフ・パス攻撃を検出するために使用することができるトンネル隣接ノンス続く最初の認証交換を介して達成されます。すべてのインターネット通信用として、IRONシステムは、リレー誠実に行動し、BGP（例えば、攻撃を吸い上げるトラフィックをマウントする）に虚偽の広告を注入していないに依存します。
Each VPC overlay network requires a means for assuring the integrity of the interior routing system so that all Relays and Servers in the overlay have a consistent view of Client<->Server bindings. Finally, Denial-of-Service (DoS) attacks on IRON Relays and Servers can occur when packets with spoofed source addresses arrive at high data rates. However, this issue is no different than for any border router in the public Internet today.
< - >サーバーのバインディング各VPCのオーバーレイネットワークは、オーバーレイ内のすべてのリレーおよびサーバーは、クライアントの一貫したビューを持つように内部ルーティングシステムの完全性を保証するための手段が必要となります。偽装された送信元アドレスを持つパケットは、高いデータレートに到達したときに最後に、IRONリレーおよびサーバー上のサービス拒否（DoS）攻撃が発生する可能性があります。しかし、この問題は、公衆インターネットであらゆる境界ルータ今日よりも違いはありません。
The ideas behind this work have benefited greatly from discussions with colleagues; some of which appear on the RRG and other IRTF/IETF mailing lists. Robin Whittle and Steve Russert co-authored the TTR mobility architecture, which strongly influenced IRON. Eric Fleischman pointed out the opportunity to leverage anycast for discovering topologically close Servers. Thomas Henderson recommended a quantitative analysis of scaling properties.
この作品の背後にある考え方は、同僚との議論から大きな恩恵を受けています。そのうちのいくつかは、RRGおよびその他のIRTF / IETFメーリングリストに表示されます。ロビン・ホイットルとスティーブラサートは強くIRONに影響を与えたTTRモビリティアーキテクチャを、共著。エリックFleischmanは、位相幾何学的に近いサーバを発見するためのエニーキャストを活用する機会を指摘しました。トーマス・ヘンダーソンは、プロパティをスケーリングの定量分析をお勧めします。
The following individuals provided essential review input: Jari Arkko, Mohamed Boucadair, Stewart Bryant, John Buford, Ralph Droms, Wesley Eddy, Adrian Farrel, Dae Young Kim, and Robin Whittle.
ヤリArkko、モハメドBoucadair、スチュワートブライアント、ジョン・ビュフォード、ラルフDroms、ウェズリーエディ、エードリアンファレル、府ヤング・キム、そしてロビンWhittleさん：以下の個人が必須レビュー入力を提供します。
[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月。
[BGPMON] net, B., "BGPmon.net - Monitoring Your Prefixes, http://bgpmon.net/stat.php", June 2010.
[BGPMON]ネット、B.、 "BGPmon.net - あなたの接頭辞を監視、http://bgpmon.net/stat.php"、2010年6月。
[EVOLUTION] Zhang, B., Zhang, L., and L. Wang, "Evolution Towards Global Routing Scalability", Work in Progress, October 2009.
[EVOLUTION]チャン、B.、チャン、L.、およびL.王、 "グローバルルーティングスケーラビリティに向けて進化"、進歩、2009年10月に作業。
[GROW-VA] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "FIB Suppression with Virtual Aggregation", Work in Progress, February 2011.
[GROW-VA]フランシス、P.、徐、X.、Ballani、H.、ジェン、D.、Raszuk、R.、およびL.チャン、 "仮想集約を用いたFIBの抑制"、進歩、2011年2月での作業。
[INTAREA-SEAL] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Work in Progress, February 2011.
[INTAREA-SEAL]テンプリン、F.、エド。、 "サブネットワークのカプセル化とアダプテーション層（SEAL）"、進歩、2011年2月での作業。
[INTAREA-VET] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", Work in Progress, January 2011.
[INTAREA-VET]テンプリン、F.、エド。、 "仮想エンタープライズトラバーサル（VET）"、進歩、2011年1月での作業。
[IVIP-ARCH] Whittle, R., "Ivip (Internet Vastly Improved Plumbing) Architecture", Work in Progress, March 2010.
[IVIP-ARCH] Whittleさん、R.、 "Ivip（インターネット大幅に改善配管）アーキテクチャ"、進歩、2010年3月での作業。
[RADIR] Narten, T., "On the Scalability of Internet Routing", Work in Progress, February 2010.
"インターネットルーティングのスケーラビリティについて" [RADIR] Narten氏、T.、進歩、2010年2月での作業。
[RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a subnetwork for experimentation with the OSI network layer", RFC 1070, February 1989.
[RFC1070] Hagens、R.、ホール、N.、およびM.ローズ、 "OSIネットワーク層での実験のためのサブネットワークとしてのインターネットの利用"、RFC 1070、1989年2月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]ジョンソン、D.とS.デアリング、 "予約済みのIPv6サブネットエニーキャストアドレス"、RFC 2526、1999年3月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]のHuitema、C.、 "6to4のリレールーターのエニーキャストプレフィックス"、RFC 3068、2001年6月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]ベイカー、F.、リア、E.、およびR. Droms、 "国旗の日なしでIPv6ネットワークを再番号付けのための手順"、RFC 4192、2005年9月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code Point (ICP) Assignments for NSAP Addresses", RFC 4548, May 2006.
[RFC4548]グレー、E.、Rutemiller、J.、およびG.ツバメ、 "NSAPアドレスのためのインターネットコードポイント（ICP）の割り当て"、RFC 4548、2006年5月。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4605]フェナー、B.、彼、H.、ハーバーマン、B.、およびH. Sandick、 "インターネットグループ管理プロトコル（IGMP）/マルチキャストリスナ発見（MLD）ベースマルチキャスト転送（" IGMP / MLDプロキシ」） 」、RFC 4605、2006年8月。
[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月。
[RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", RFC 5522, October 2009.
[RFC5522]エディ、W.、Ivancic、W.、およびT.デービス、「航空宇宙探査モバイルネットワークでの操作上の使用のためのネットワークモビリティ経路最適化の要件」、RFC 5522、2009年10月。
[RFC5720] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010.
[RFC5720]テンプリン、F.、 "ルーティングとグローバル企業再帰（RANGER）とのネットワークにおけるアドレス指定"、RFC 5720、2010年2月。
[RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, December 2009.
[RFC5743]、RFC 5743、2009年12月フォーク、A.、 "インターネットResearch Task Force（IRTF）文書ストリームの定義"。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887]大工、B.、アトキンソン、R.、およびH.フリンクは、RFC 5887、2010年5月、 "リナンバリングはまだ作業が必要"。
[RFC6115] Li, T., "Recommendation for a Routing Architecture", RFC 6115, February 2011.
[RFC6115]李、T.、 "ルーティング・アーキテクチャのための勧告"、RFC 6115、2011年2月。
[RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios", RFC 6139, February 2011.
[RFC6139]ラサート、S.、Fleischman、E.、およびF.テンプリン、 "ルーティングとグローバルエンタープライズ再帰（レンジャー）とネットワークにおけるアドレッシングシナリオ"、RFC 6139、2011年2月。
[RO-CR] Bernardos, C., Calderon, M., and I. Soto, "Correspondent Router based Route Optimisation for NEMO (CRON)", Work in Progress, July 2008.
[RO-CR] Bernardos、C.、カルデロン、M.、およびI.ソト、 "NEMO（CRON）のためのコレスポンデントルータベースのルート最適化"、進歩、2008年7月に働いています。
[SAMPLE] Carpenter, B. and S. Jiang, "Legacy NAT Traversal for IPv6: Simple Address Mapping for Premises Legacy Equipment (SAMPLE)", Work in Progress, June 2010.
[SAMPLE]大工、B.とS.江、「IPv6のレガシーNATトラバーサル：構内レガシー機器（SAMPLE）のためのシンプルなアドレスマッピング」、進歩、2010年6月での作業。
[TTRMOB] Whittle, R. and S. Russert, "TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem, http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf", August 2008.
[TTRMOB] Whittleさん、R.とS.ラサート、「インターネットのルーティングのスケーリング問題にコアエッジ分離ソリューションのTTRモビリティの拡張、http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf 」、2008年8月。
[V6OPS-TUN-SEC] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns With IP Tunneling", Work in Progress, October 2010.
[V6OPS-TUN-SEC]クリシュナン、S.、ターラー、D.、およびJ.ホーグランド、 "IPトンネリングとセキュリティの懸念"、進歩、2010年10月の作業。
Appendix A. IRON VPs over Internetworks with Different Address Families
付録A. IRON VPの異なるアドレスファミリとインターネットワークオーバー
The IRON architecture leverages the routing system by providing generally shortest-path routing for packets with EPA addresses from VPs that match the address family of the underlying Internetwork. When the VPs are of an address family that is not routable within the underlying Internetwork, however, (e.g., when OSI/NSAP [RFC4548] VPs are used within an IPv4 Internetwork) a global mapping database is required to allow Servers to map VPs to companion prefixes taken from address families that are routable within the Internetwork. For example, an IPv6 VP (e.g., 2001:DB8::/32) could be paired with a companion IPv4 prefix (e.g., 192.0.2.0/24) so that encapsulated IPv6 packets can be forwarded over IPv4-only Internetworks.
IRONアーキテクチャは基礎となるインターネットワークのアドレスファミリーが一致のVPからEPAアドレスを持つパケットのルーティング一般最短パスを提供することにより、ルーティングシステムを活用します。グローバルマッピングデータベースは、サーバがへのVPをマッピングできるようにするために必要とされるのVPは、基礎となるインターネットワーク内でルーティングできないアドレスファミリである場合には、しかしながら、（例えば、OSI / NSAP [RFC4548]のVPは、IPv4のインターネットワーク内で使用される場合）インターネットワーク内でルーティング可能なアドレスファミリから取られたコンパニオンプレフィックス。例えば、IPv6のVP（例えば、2001：DB8 :: / 32）は、カプセル化されたIPv6パケットはIPv4のみインターネットワークを介して転送することができるようにコンパニオンIPv4プレフィクス（例えば、192.0.2.0/24）と対にすることができます。
Every VP in the IRON must therefore be represented in a globally distributed Master VP database (MVPd) that maintains VP-to-companion prefix mappings for all VPs in the IRON. The MVPd is maintained by a globally managed assigned numbers authority in the same manner as the Internet Assigned Numbers Authority (IANA) currently maintains the master list of all top-level IPv4 and IPv6 delegations. The database can be replicated across multiple servers for load balancing, much in the same way that FTP mirror sites are used to manage software distributions.
IRONのすべてのVPは、そのためIRON内のすべてのVPのためのVP・ツー・コンパニオンのプレフィックスのマッピングを維持してグローバルに分散マスターVPデータベース（MVPd）で表現されなければなりません。インターネット割り当て番号機関（IANA）は、現在、すべてのトップレベルのIPv4およびIPv6の委任のマスターリストを維持するようMVPdは同様にグローバルに管理割り当て番号機関によって維持されます。データベースには、多くのFTPミラーサイトは、ソフトウェアの配布を管理するために使用されているのと同じように、負荷分散のために複数のサーバーに複製することができます。
Upon startup, each Server discovers the full set of VPs for the IRON by reading the MVPd. The Server reads the MVPd from a nearby server and periodically checks the server for deltas since the database was last read. After reading the MVPd, the Server has a full list of VP-to-companion prefix mappings.
起動時に、各サーバーはMVPdを読み取ることによって、IRON用のVPフルセットを発見します。サーバーは、近くのサーバーからMVPdを読み取り、データベースが前回の読み込み後、定期的にデルタのためにサーバーをチェックします。 MVPdを読んだ後、サーバーはVP・ツー・コンパニオンプレフィックスマッピングの完全なリストを持っています。
The Server can then forward packets toward EPAs covered by a VP by encapsulating them in an outer header of the VP's companion prefix address family and using any address taken from the companion prefix as the outer destination address. The companion prefix therefore serves as an anycast prefix.
サーバーは、VPのコンパニオンプレフィックスアドレスファミリの外側のヘッダーでそれらをカプセル化し、外側の宛先アドレスとしてコンパニオンプレフィックスから取られた任意のアドレスを使用してVPによってカバーされたEPAに向けて、その後パケットを転送することができます。コンパニオン・プレフィックスは、従って、エニーキャストプレフィックスとして機能します。
Possible encapsulations in this model include IPv6-in-IPv4, IPv4-in-IPv6, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc.
このモデルにおける可能なカプセル化は、IPv6インのIPv4、IPv4のインのIPv6、OSI / CLNPインIPv6の、OSI / CLNPインのIPv4、等が挙げられます
Appendix B. Scaling Considerations
注意事項スケーリング付録B.
Scaling aspects of the IRON architecture have strong implications for its applicability in practical deployments. Scaling must be considered along multiple vectors, including Interdomain core routing scaling, scaling to accommodate large numbers of customer EUNs, traffic scaling, state requirements, etc.
IRONアーキテクチャのスケーリング側面は、実用的な展開での適用のための強力な意味合いを持っています。スケーリングは、顧客のEUNs、交通スケーリング、状態の要件などの多数に対応するために、スケーリング、ドメイン間のコアルーティングのスケーリングを含む複数のベクター、一緒に考えなければなりません
In terms of routing scaling, each VPC will advertise one or more VPs into the global Internet routing system from which EPs are delegated to customer EUNs. Routing scaling will therefore be minimized when each VP covers many EPs. For example, the IPv6 prefix 2001:DB8::/32 contains 2^24 ::/56 EP prefixes for assignment to EUNs; therefore, the IRON could accommodate 2^32 ::/56 EPs with only 2^8 ::/32 VPs advertised in the interdomain routing core. (When even longer EP prefixes are used, e.g., /64s assigned to individual handsets in a cellular provider network, considerable numbers of EUNs can be represented within only a single VP.) Each VP also has an associated anycast companion prefix; hence, there will be one anycast prefix advertised into the global routing system for each VP.
ルーティングスケーリングに関しては、各VPCをEPSは、顧客のEUNsに委任されているから、グローバルなインターネットルーティングシステムへの一の以上のVPをアドバタイズします。各VPは、多くのEPをカバーしていたときに、ルーティングのスケーリングは、したがって、最小化されます。例えば、IPv6プレフィックス2001：DB8 :: / 32はEUNsへの割り当てのために2 ^ 24 :: / 56 EPプレフィックスを含み、したがって、鉄はドメイン間ルーティングコアでアドバタイズのみ2 ^ 8 :: / 32のVPとの2 ^ 32 :: / 56のEPを収容できます。 （さらに長いEPプレフィックスを使用する場合、例えば、/セルラプロバイダネットワーク内の個々のハンドセットに割り当て64Sは、EUNsのかなりの数は、単一のVP内に表すことができる。）各VPは、関連エニーキャストコンパニオン・プレフィックスを有します。したがって、各VPのグローバルルーティングシステムにアドバタイズ1つのエニーキャストプレフィックスが存在するであろう。
In terms of traffic scaling for Relays, each Relay represents an ASBR of a "shell" enterprise network that simply directs arriving traffic packets with EPA destination addresses towards Servers that service customer EUNs. Moreover, the Relay sheds traffic destined to EPAs through redirection, which removes it from the path for the vast majority of traffic packets. On the other hand, each Relay must handle all traffic packets forwarded between its customer EUNs and the non-IRON Internet. The scaling concerns for this latter class of traffic are no different than for ASBR routers that connect large enterprise networks to the Internet. In terms of traffic scaling for Servers, each Server services a set of the VPC overlay network's customer EUNs. The Server services all traffic packets destined to its EUNs but only services the initial packets of flows initiated from the EUNs and destined to EPAs. Therefore, traffic scaling for EPA-addressed traffic is an asymmetric consideration and is proportional to the number of EUNs each Server serves.
リレーのトラフィックスケーリングの点で、各リレーは、単にサービス顧客EUNsサーバに向けEPAの宛先アドレスを持つトラフィックパケット到着指示する「シェル」企業ネットワークのASBRを表します。また、リレートラフィックパケットの大多数のパスから削除リダイレクションを介してのEPA宛てのトラフィックは、小屋。一方、各リレーは、その顧客EUNsと非IRONインターネットとの間で転送されるすべてのトラフィックパケットを処理する必要があります。トラフィックのこの後者のクラスのためのスケーリングの懸念は、インターネットへの大規模な企業ネットワークに接続するASBRルータ用よりも違いはありません。サーバのトラフィックスケーリングの面では、各サーバーは、VPCのオーバーレイネットワークの顧客EUNsのセットにサービスを提供します。 ServerサービスのすべてのトラフィックパケットがそのEUNs宛だけEUNsから開始されたフローの最初のパケットをサービスとのEPAに向かいます。したがって、EPAアドレス指定トラフィックのトラフィックスケーリングは、非対称考慮され、各サーバがサービスを提供EUNsの数に比例します。
In terms of state requirements for Relays, each Relay maintains a list of all Servers in the VPC overlay network as well as FIB entries for all customer EUNs that each Server serves. This state is therefore dominated by the number of EUNs in the VPC overlay network. Sizing the Relay to accommodate state information for all EUNs is therefore required during VPC overlay network planning. In terms of state requirements for Servers, each Server maintains tunnel-neighbor state for each of the customer EUNs it serves, but it need not keep state for all EUNs in the VPC overlay network. Finally, neither Relays nor Servers need keep state for final destinations of outbound traffic.
リレーの状態要件に関しては、各リレーは、VPCオーバーレイネットワーク内のすべてのサーバのリストだけでなく、各サーバーがサービスを提供するすべての顧客EUNsのためのFIBエントリを維持します。この状態は、したがって、VPCオーバレイネットワーク内EUNsの数によって支配されます。すべてEUNsの状態情報に対応するためにリレーをサイジングのでVPCオーバーレイネットワーク計画時に必要とされます。サーバーの状態要件の面では、各サーバーは、それがサービスを提供する顧客EUNsごとにトンネル隣人の状態を維持しますが、VPCのオーバーレイネットワーク内のすべてのEUNsの状態を維持する必要はありません。最後に、リレーでもサーバーでもないが、アウトバウンドトラフィックの最終目的地の状態を保つ必要があります。
Clients source and sink all traffic packets originating from or destined to the customer EUN. Therefore, traffic scaling considerations for Clients are the same as for any site border router. Clients also retain state for the Servers for final destinations of outbound traffic flows. This can be managed as soft state, since stale entries purged from the cache will be refreshed when new traffic packets are sent.
クライアントのソースとは、すべてのトラフィックパケットがから発信や顧客のEUN宛て沈みます。そのため、クライアントのトラフィックスケーリングの考慮事項は、任意のサイトの境界ルータと同じです。また、クライアントは、アウトバウンドトラフィックフローの最終目的地のためのサーバの状態を維持します。新しいトラフィックパケットが送信されるときにキャッシュからパージ古いエントリが更新されますので、これは、柔らかい状態として管理することができます。
Author's Address
著者のアドレス
Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
フレッド・L.テンプリン（エディタ）ボーイング・リサーチ＆テクノロジー私書箱ボックス3707 MC 7L-49シアトル、WA 98124 USA
EMail: fltemplin@acm.org
メールアドレス：fltemplin@acm.org