[要約] RFC 6179は、インターネットルーティングオーバーレイネットワーク（IRON）に関するものであり、その目的は、インターネットのスケーラビリティとセキュリティを向上させるために、オーバーレイネットワークを使用してルーティングを行うことです。
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................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]の集約は、各ルーターの転送情報ベースに必要なエントリの数を減らすために仮想プレフィックス（VPS）を備えたルーティングオーバーレイを導入するグローバルなルーティング提案です）およびルーティング情報ベース（リブ）。グローバルエンタープライズ再帰（Ranger）[RFC5720]を使用したネットワークでのルーティングとアドレス指定は、非常に広範なユースケースシナリオ[RFC6139]に適用できるエンタープライズネットワークの再帰的配置を調べます。Ironは、レンジャーの非放送、複数アクセス（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から概念を借りて、インターネットからの概念をさらに借用し、配管（IVIP）[IVIP-ARCH]建築提案と、関連する翻訳トンネルルーター（TTR）モビリティエクステンション[TTRMOB]とともに大幅に改善されました。実際、TTRモデルは、このドキュメントで議論されている鉄のモビリティアーキテクチャの設計に大きな影響を与えました。鉄に適応したネットワークアドレス翻訳者（NAT）トラバーサル技術は、施設のレガシー機器（サンプル）の提案[サンプル]の単純なアドレスマッピングに触発されました。
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.
鉄は、現在のBGP [RFC4271]ルーティングシステムを変更せずにスケーラブルなアドレス指定をサポートします。鉄は、インターネットプロトコル標準[RFC0791] [RFC2460]を観察します。IPパケット内でカプセル化できる他のネットワーク層プロトコル（例：OSI/CLNP（Connectionless Network Protocol）[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.
鉄は、エンドユーザーネットワーク（EUN）プレフィックス（EPS）が顧客サイトに委任される仮想プレフィックス（VPS）を所有および管理する仮想プレフィックス企業（VPC）によって管理される仮想オーバーレイネットワークを含むグローバルルーティングシステムです。この鉄は、マルチホーム、モビリティ管理、および交通工学に対する顧客の需要の高まりに動機付けられ、安定したアドレス指定を使用して、[RFC4192] [RFC5887]のネットワークへの依存を最小限に抑えます。鉄は、既存のIPv4およびIPv6グローバルインターネットルーティングシステムを、外側のIPv4またはIPv6ヘッダー内の内部ネットワークプロトコルパケットのトンネルの仮想NBMAリンクとして使用します（セクション3を参照）。鉄には、少数の新しいBGPコアルーターとサポートサーバーの展開、および顧客Eunsの鉄を受けたルーター/サーバーの展開が必要です。ホストの変更はなく、ほとんどのルーターの変更は必要ありません。
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.
注：このドキュメントは、インターネット調査タスクフォース（IRTF）ドキュメントストリーム手順[RFC5743]に準拠して提供されています。IETF製品ではなく、標準でもありません。このドキュメントの見解は、IRTFルーティングリサーチグループ（RRG）が物議を醸すと考えられていましたが、RGは文書をまだ公開すべきであるというコンセンサスに達しました。このドキュメントは、RRG内および公開前に選択された専門家のレビュー担当者を通じてレビュー期間を受けます。次のセクションでは、鉄の建築の詳細について説明します。
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など）から派生した、より具体的な内側ネットワーク層プレフィックス。（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.
インターネットルーティングオーバーレイネットワーク（鉄）：一般的なインターネットワークで構成されたすべてのVPCオーバーレイネットワークのユニオンを含む複合仮想オーバーレイネットワーク。鉄は、ロケーターアドレスを使用する外側ヘッダー内の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 Client Router/Host（ "Client"）：NBMAトンネル仮想インターフェイスを介して顧客のeunと関連する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サービングルーター（ "Server"）：顧客クライアントが所有するEPSに転送およびマッピングサービスを提供するVPCのオーバーレイネットワークルーター。
IRON Relay Router ("Relay"): a VPC's overlay network router that acts as a relay between the IRON and the native Internet.
Iron Relay Router（ "Relay"）：鉄とネイティブインターネットの間のリレーとして機能するVPCのオーバーレイネットワークルーター。
IRON Agent (IA): generically refers to any of an IRON Client/Server/Relay.
鉄エージェント（IA）：鉄のクライアント/サーバー/リレーのいずれかを一般的に指します。
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）：顧客Eunを基礎となるインターネットワークに接続するサービスプロバイダー。言い換えれば、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プレフィックスから撮影したロケーターはグローバルベースでルーティングできますが、プライベートIPプレフィックスから取得したロケーターは、ネットワークアドレス変換（NAT）を介して公開されます。
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.
サブネットワークのカプセル化および適応レイヤー（シール）：拡張パケット識別と、決定論的なネットワーク層フィードバックを確保するためのコントロールメッセージプロトコルを提供するカプセル化サブレイヤー。
Virtual Enterprise Traversal (VET): a method for discovering border routers and forming dynamic tunnel-neighbor relationships over enterprise networks (or sites) with varying properties.
Virtual Enterprise Traversal（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）：仮想プレフィックス会社（VPC）が所有および管理する所有および管理されているプレフィックスブロック（例：IPv4 /16、IPv6 /20、OSIネットワークサービスアクセスプロトコル（NSAP）プレフィックスなど）。
Virtual Prefix Company (VPC): a company that owns and manages a set of VPs from which it delegates EPs to EUNs.
Virtual Prefix Company（VPC）：EPSをEunsに委任するVPSのセットを所有および管理する会社。
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オーバーレイネットワーク基礎となるインターネットワーク（グローバルインターネットなど）で構成された仮想オーバーレイネットワークを介して、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.
インターネットルーティングオーバーレイネットワーク（Iron）は、一般的なインターネットワークで構成された仮想オーバーレイネットワークのシステムです。このドキュメントで提示された原則は、パブリックグローバルインターネットのコンテキスト内で議論されていますが、自律的なインターネットワークにも適用することもできます。したがって、このドキュメントの残りの部分は、特定の区別を行う必要がある場合を除き、「インターネット」と「インターネットワーク」という用語を同じ意味で指します。
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.
鉄は、インターネットルーティングに使用されるカプセル化ヘッダー内のエンドツーエンド通信セッションのパケットを自動的にトンネルする鉄のエージェント（IAS）で構成されています。IASは、サブネットワークのカプセル化および適応層（SEAL）[Intarea-Seal]と組み合わせて、仮想エンタープライズトラバーサル（VET）[INTAREA-VET]仮想NBMAリンクモデルを使用して、図に示すように外側のヘッダー内の内側のネットワーク層パケットをカプセル化します。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を使用して、シールコントロールメッセージプロトコル（SCMP）を使用して、ルートリダイレクト、パス最大伝送ユニット（PMTU）制限の表示、宛先のない到達可能性などの制御メッセージを決定的に交換および認証します。IASは、NBMA仮想リンクの近隣のように表示されます。、および形成双方向および/または単方向トンネルneighborの関係。
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.
鉄は、一般的な基礎となるインターネットで構成され、仮想プレフィックス企業（VPCS）が所有および管理するすべての仮想オーバーレイネットワークの結合です。このような仮想オーバーレイネットワークは、高度に集約された仮想プレフィックス（VP）を提供するために、インターネット全体に分散されたIASのセットで構成されています。VPCSは、VPSからサブプレフィックスを委任し、エンドユーザーネットワークプレフィックス（EPS）として顧客にリースします。次に、顧客はEPSを顧客Edge IASに割り当て、エンドユーザーネットワーク（Euns）を鉄に接続します。
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.
鉄は、エンドシステムまたはインターネット内のほとんどのルーターに変更を必要としません。代わりに、鉄は、新しいプラットフォームとして、または既存のプラットフォームの変更として展開されるIAで構成されています。IASは、既存のインターネットルーティングシステムを乱すことなく徐々に展開され、鉄をナビゲートするためのウェイポイント（または「ケアン」）として機能する場合があります。IASの機能的役割については、次のセクションで説明します。
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：ユーンを鉄に接続する鉄クライアントルーター
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.
鉄をサービングするルーター（または、単純に「サーバー」）は、顧客クライアントルーターが所有するEPSに転送およびマッピングサービスを提供するVPCのオーバーレイネットワークルーターです。典型的な展開では、VPCは、クライアントが近くにあるものを発見できるように、グローバルに分散した方法で多くのサーバーを鉄の周りに展開します（例：図3に示すように）。
+--------+ +--------+
| 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：鉄のサービングルーターグローバルディストリビューションの例
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.
各サーバーは、各クライアントの顧客との双方向トンネル隣人の関係を形成するトンネルエンドポイントルーターとして機能します。また、次のセクションで説明したように、各サーバーはまた、鉄からパケットをネイティブインターネットに転送できるリレーのセットに関連付けられています。
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.
鉄リレールーター（または、単純に「リレー」）は、鉄とネイティブインターネットの間のリレーとして機能する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は、会社のVPSをIPv4およびIPv6グローバルインターネットBGPルーティングシステムに宣伝する1つ以上のリレーを構成します。各リレーは、VPCのオーバーレイネットワークサーバーのすべてに関連付けられています。たとえば、イーサネットケーブルなどの直接的な相互接続を介して、鉄の上のトンネルを介して関連しています。リレーの役割（およびオーバーレイネットワークサーバーとの関係）は図に示されています。4。
.-.
,-( _)-.
.-(_ (_ )-.
(_ Internet )
`-(______)-' | +--------+
| |--| Server |
+----+---+ | +--------+
| Relay |----| +--------+
+--------+ |--| Server |
_|| | +--------+
(:::)-. (Ethernet)
.-(::::::::)
+--------+ .-(::::::::::::)-. +--------+
| Server |=(:::: The IRON ::::)=| Server |
+--------+ `-(::::::::::::)-' +--------+
`-(::::::)-'
|| (Tunnels)
+--------+
| Server |
+--------+
Figure 4: IRON Relay Router Connecting IRON to Native Internet
図4：鉄をネイティブインターネットに接続する鉄リレールーター
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オーバーレイネットワークが展開されると、キルトの別のパッチになります。したがって、鉄は複数の個々のパッチで構成される複合オーバーレイネットワークであり、各パッチは他のパッチとは独立してアクティビティを調整します（各パッチのサーバーが鉄のすべての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.
鉄の各VPCオーバーレイネットワークは、クライアントの顧客にサービスを提供するリレーとサーバーのセットを維持しています。適切な顧客サービスレベルを確保するために、VPCはトラフィックスケーリング分析を実施し、インターネット全体でグローバルにオーバーレイネットワークに十分なリレーとサーバーを配布する必要があります。図5は、鉄仮想オーバーレイネットワークのリレー、サーバー、およびクライアントの論理的配置を示しています。
.-.
,-( _)-.
.-(_ (_ )-.
(__ 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インターネットに直接接続します。また、VPC Overlay NetworkのIPv4 VPSをIPv4 BGPルーティングシステムに宣伝し、Overlay NetworkのIPv6 VPSをIPv6 BGPルーティングシステムに宣伝します。したがって、リレーは、インターネット内のエンドシステムから送信された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オーバーレイネットワークは、リレーとの関連を介して、クライアントとEunを鉄とIPv6およびIPv4インターネットに関連付けるサーバーのセットも管理します。したがって、鉄サーバーは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からクライアントのマッピングをキャッシュするクライアントの作業セットを維持します。また、各サーバーは、動的ルーティングプロトコルを介して、VPCオーバーレイネットワークの各リレーに作業セットのEPSのリストを伝播します（例：EPからサーバーマッピングのみを運ぶオーバーレイネットワーク内部BGPインスタンスまた、外部BGPルーティングシステムと相互作用しません）。したがって、各サーバーは現在の作業セットのEPSを追跡する必要がありますが、各リレーは、VPCオーバーレイネットワーク内のすべてのEPSのリーチ性情報を表す完全な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から基本的なインターネット接続を取得するクライアントを確立し、サーバーに接続してユーンを鉄に接続します。各eunは、クライアントが互いに調整している限り、1つまたは複数のクライアントを介して鉄に接続できます。たとえば、Eunパーティションを緩和します。リレーやサーバーとは異なり、クライアントはNATの1つまたは複数の層の背後にあるプライベートアドレスを使用できます。各クライアントは、最初に、Anycast Discovery Process（以下で説明）を通じて近くのサーバーのリストを発見します。次に、これらの近くのサーバーのいずれかを選択し、初期交換と定期的なkeepAlivesを使用して、サーバーとの双方向トンネル隣人の関係を形成します。
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.
クライアントがサーバーを選択すると、サーバーにトンネリングすることにより、初期のアウトバウンドパケットをEunsから転送し、最終目的地にサービスを提供する鉄内の最も近いリレーに転送します。その後、クライアントは、最終的な目的地のウンにサービスを提供するサーバーを通るより直接的なルートを通知するリダイレクトメッセージを受信します。
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.
鉄は、基礎となるインターネットワークでネイティブにルーティングできないネットワーク層アドレスファミリのVPSをサポートするためにも使用できます（たとえば、パブリックインターネット、IPv4のみのインターネットワーク、IPv6のみのインターネットワークなどのIPv6を介してIPv6を介してIPv6を介してOSI/CLNP。）。他の住所ファミリに基づいたインターネットワークを介した1つの住所ファミリの鉄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.
鉄の初期化には、VPCオーバーレイネットワークおよび顧客Euns内のIASのスタートアップアクションが必要です。次のサブセクションでは、これらのスタートアップ手順について説明します。
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オーバーレイネットワーク内の各リレーには、同じオーバーレイネットワークに属するすべてのサーバーのロケーターと同様に機能するVPSのリストが提供されます。リレーには、外部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.
起動時に、リレーは、BGPルーターと同じように、IPv4およびIPv6インターネットのピアとのBGPルーティング交換に従事します。次に、EPからサーバーマッピングを発見する目的で、オーバーレイネットワーク内のすべてのサーバー（たとえば、双方向トンネルを介したTCP接続を介して、内部BGP（IBGP）ルートリフレクターなどを介して）に接続します。リレーに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 VPSをIPv6 BGPルーティングシステムに宣伝し、IPv4 VPSをIPv4 BGPルーティングシステムに宣伝します。リレーはさらに、IPv4/24コンパニオンプレフィックス（例：192.0.2.0/24）をIPv4ルーティングシステムとIPv6 ::/64コンパニオンプレフィックス（例：2001：db8 ::/64）にIPv6ルーティングシステムに宣伝します（例：/64これらは、VPから取得したサブプレフィックスである可能性があることに注意してください。リレーは、IPv4コンパニオンプレフィックス（例：192.0.2.1）にホスト番号 '1'を構成し、IPv6コンパニオンプレフィックス（例：2001：db8 :: 0）にインターフェイス識別子 '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オーバーレイネットワーク内の各サーバーは、オーバーレイネットワークのVPSを集約するすべてのリレーのロケーターでプロビジョニングされます。ルートの最適化をサポートするには、EPAおよび非EPAアドレスを識別できるように、サーバーに鉄内のすべてのVPのリスト（つまり、独自のオーバーレイネットワークのVPSだけでなく）をプロビジョニングする必要があります。（したがって、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からサーバーマッピングを報告する目的で、オーバーレイネットワーク内のすべてのリレー（たとえば、IBGPルートリフレクターなどを介して、IBGPルートリフレクターなどを介して）内のすべてのリレーに接続する必要があります。その後、サーバーは、双方向のトンネル隣人関係を確立する一環として、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.
最初の運用使用の前に、各クライアントは、VPCから1つ以上のEPSとVPCオーバーレイネットワークに関連付けられたコンパニオンプレフィックスを取得する必要があります（セクション5.1を参照）。また、クライアントは、VPCから証明書とパブリック/プライベートキーペアを取得する必要があります。これは、後でEPSの所有権を証明するために使用できるものです。これは、各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オーバーレイネットワークサブネットルーターのAnycastアドレスにSCMPルーター勧誘（SRS）メッセージを送信して、最も近いリレーを発見します。リレーは、1つ以上の近くのサーバーのロケーターアドレスをリストする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.
クライアントが1つのサーバーと1つのサーバーのみを選択することが不可欠であることに注意してください。これは、VPCオーバーレイネットワークマッピングシステムが、サーバー自体と運命を共有する任意の時点で、任意の時点で1つのアクティブなEPからサーバーへのマッピングのみを持つことができるようにするためです。このサーバーが失敗した場合、クライアントは、新しいEP-Serverマッピングで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で詳述されている鉄の初期化に続いて、IASはパケットの受信および転送の定常状態のプロセスに従事します。すべてのIASは、VET [Intarea-Vet]とシール[Intarea-Seal]のメカニズムを使用して鉄の上にカプセル化されたパケットを転送しますが、リレー（および場合によってはサーバー）は、ネイティブIPv6およびIPv4インターネットとの間でパケットをさらに転送します。IASはまた、SCMPを使用して、リダイレクトメッセージの送信と受信プロセス、エラーメッセージなどを含む他のIAと調整します（ただし、IAは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パスのセットを表すために、単一のトンネルneighbor識別子（つまり、「非CE」）が使用されることを意味します。したがって、Nonceは、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メッセージを受信すると、カプセル化されたパケットインエラーのNonCEフィールドをチェックして、メッセージがサーバーのトンネルneighbor状態に対応していることを確認し、ノンセが一致する場合にメッセージを受け入れます。（ただし、パケットインエラーの外側のソースと宛先アドレスは、サーバーおよび/またはリレーアドレスの書き換えの可能性があるため、元のパケットのアドレスとは異なる場合があることに注意してください。）
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を送信することにより、クライアントからSRSSに応答します。サーバーがクライアントトンネルの隣人の1つからシールカプセル化されたパケットを受信すると、内側の宛先アドレスを調べます。内側の宛先アドレスがEPAではない場合、サーバーはパケットを脱カプセル化し、フィルタリングの侵入により損失なくそうすることができれば、インターネットにカプセル化されずに転送します。それ以外の場合、サーバーはパケットを再カプセルします（つまり、外側のヘッダーを削除し、同じアドレスファミリの新しい外側ヘッダーに置き換えます）。次に、再エンコールされたパケットをリレーに転送します。リレーは、それを脱カプセル化してインターネットに転送します。
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の場合、サーバーは外部ソースアドレスを独自のロケーターアドレスのいずれかに書き換え、外側の宛先アドレスを内側の宛先アドレスに関連付けられたコンパニオンプレフィックスから取得したサブネットルーターのAnycastアドレスに書き換えます（外側のIPプロトコルと同じアドレスファミリのコンパニオンプレフィックスが使用されている場合）。次に、サーバーは、デフォルトまたはより特定のルートを介して、改訂されたカプセル化されたパケットをインターネットに転送し、宛先VPCオーバーレイネットワーク内の最も近いリレーに向けられます。パケットを送信した後、サーバーは宛先VPCオーバーレイネットワーク内のリレー/サーバーからSCMPエラーまたはリダイレクトメッセージを受信します。その場合、サーバーは、メッセージのNONCEが元の内側パケットを送信したクライアントと一致し、NONCEが一致しない場合にメッセージを破棄することを確認します。それ以外の場合、サーバーは、クライアントのトンネルneighbor状態に関連付けられたソースアドレス、宛先アドレス、および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と一致する場合、 'a'は新しい外側ヘッダーでパケットを再カプセルし、それを転送しますクライアント（ '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.
各リレーがVPSを同期した後（セクション5.1を参照）、会社のVPSおよびコンパニオンプレフィックスの完全なセットをIPv4およびIPv6インターネットBGPルーティングシステムに宣伝します。これらのプレフィックスは、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.
リレーがVPSの1つで覆われたEPAに運命づけられたインターネットからパケットを受信すると、通常のIPルーターとして動作します。特に、リレーはFIBを探して、宛先アドレスをカバーするEPにサービスを提供するサーバーのロケーターを発見します。その後、リレーは、外側のソースアドレスとして独自のロケーターを使用してパケットをカプセル化し、サーバーのロケーターを外側の宛先アドレスとしてカプセル化し、パケットをサーバーに転送します。
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.
リレーがインターネットからサブネットルーターのANYCASTアドレスのいずれかに向けられたパケットを受信すると、シールがカプセル化されていない場合、パケットを破棄します。パケットが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.
パケットが通常のシールパケット（つまり、内側のパケットをカプセル化するもの）である場合、リレーは同じアドレスファミリのSCMPリダイレクトメッセージを送信します。リダイレクトされたターゲットとして。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アドレスしたウン内に配置される場合の通信をサポートします。両方のホストが鉄のウン内にいる場合、パスから不要なサーバーとリレーを排除するルートリダイレクトが可能です。ただし、1つのホストのみが鉄のウン内にいる場合、ルートの最適化は使用できません。次のセクションでは、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.
両方のホストが鉄のウン内にいる場合、シナリオを一方向的な方法で、つまり、ソースホストから宛先ホストまでの前方方向にのみパケットフローをトレースすることで、シナリオを考慮するだけで十分です。逆方向は個別に考慮し、前方向と同じ考慮事項を負担します。
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内のソースホストによって生成されるフローの初期パケットは、ソースホストのサーバーと宛先ホストのリレーの両方を通過する必要がありますが、ルート最適化はこれらの要素を排除できます。フロー内の後続のパケットのパスから。図6は、2つの鉄のウン内のホストAからホストBへの初期パケットのフローを示しています（同じシナリオは、2つのEUNが同じVPCオーバーレイネットワーク内にあるか、異なるオーバーレイネットワーク内にあるかどうかを適用します）。
________________________________________
.-( .-. )-.
.-( ,-( _)-. )-.
.-( +========+(_ (_ +=====+ )-.
.( || (_|| 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は、Eun A内のeun A内のルーティングに接続されたネットワークインターフェイスを介してホストBに向けられた送信パケットをクライアント（a）にeunのデフォルトルーターとして誘導し、獣医とシールを使用します。外側のソースアドレスとしてロケーターアドレスを使用して外側のヘッダーにそれらをカプセル化し、サーバー（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）からカプセル化されたパケットを受信し、外側のソースアドレスを独自のロケーターアドレスのいずれかに書き換え、内側の宛先アドレスに関連付けられている適切なアドレスファミリのサブネットルーターAnycastアドレスに外側の宛先アドレスを書き換えます。サーバー（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）からカプセル化されたパケットをインターセプトし、そのFIBをチェックして、次のホップとしてサーバー（b）を使用して内側の宛先アドレスBをカバーするエントリを発見します。リレー（b）は、scmpをサーバー（a）（*）にリダイレクトし、カプセル化されたパケットの外側の宛先アドレスをサーバー（b）のロケーターアドレスに書き換え、これらの改訂されたパケットをサーバー（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）と宛先アドレスBをカバーするエントリを発見するために、そのFIBを確認します。サーバー（b）は、クライアント用のトンネルneighbor状態に関連付けられたソースアドレス、宛先アドレス、およびノンセパラメーターを使用する新しい外側ヘッダーのパケットを再カプセル化します（b）。サーバー（b）は、これらの再エンコープ化されたパケットをインターネットに転送し、ルーティングによりクライアント（b）に向けられます。クライアント（b）は、パケットを脱カプセル化し、内側のパケットをEun Bを介して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）は、リレー（b）リストサーバー（b）から1つ以上のSCMPリダイレクトメッセージを受信し、次のホップをより良いものとして受信することに注意してください。サーバー（a）は、リダイレクトをクライアント（a）に転送します。クライアント（a）は、一方向のトンネルneighbor状態を確立し、その後、カプセル化されたパケットをサーバー（b）のロケーターアドレス（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.
1人のホストが鉄のウン内にあり、もう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は、鉄eunのホストAから流れるパケットの鉄の参照動作シナリオを示しています。
_________________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | 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：鉄のホストAから非アイロンホスト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は、鉄eun Aに接続されたネットワークインターフェイスを介してホストBに向けた送信パケットBをEun A内でクライアント（a）にeunのデフォルトルーターとして誘導し、獣医を使用してシールを使用します。外側のソースアドレスとしてロケーターアドレスと、サーバーのロケーターアドレス（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）。これにより、単に脱カプセル化して、カプセル化されていないパケットをインターネットに転送します。パケットがインターネットにリリースされると、ルーティングは最終的な宛先Bに向けられます（サーバー（a）とリレー（a）は、図8に統一ゲートウェイの2つの半分として描かれていることに注意してください。その場合、「」「サーバー（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.
このシナリオには、常に鉄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は、鉄のウンである鉄のウンをホストするためにホストBから流れるパケットの鉄参照動作シナリオを示しています。
_______________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | 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：非アイアンホスト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は、非アイロン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）は、FIBをチェックして、次のホップとしてクライアント（a）と宛先アドレスAをカバーするエントリを発見します。サーバー（a）次に、（Re）クライアント用のトンネルneighbor状態に関連付けられたソースアドレス、宛先アドレス、およびノンセパラメーターを使用する外側ヘッダーのパケットをカプセル化します（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.
このシナリオには、常に鉄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.
鉄のサーバーとリレーは固定インフラストラクチャと見なすことができますが、クライアントは異なるネットワークポイントの間を移動したり、複数のISPに接続したり、トラフィックフローを明示的に管理する必要があります。次のセクションでは、鉄クライアントルーターのモビリティ、マルチホーム、トラフィックエンジニアリングの考慮事項について説明します。
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で説明されているAnycastディスカバリー手順を再発行して、サーバーの候補セットが変更されたかどうかを発見します。クライアントの現在のサーバーが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 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.
新しいサーバーに移動するために、クライアントは最初にセクション5.3で説明されているように、新しいサーバーでEP登録プロセスに従事します。次に、クライアントは、新しいサーバーに新しいサーバーのロケーターアドレスを提供することで移動したことを通知します。繰り返しますが、VPC固有の信頼できるトランザクションを介して。以前のサーバーは、生涯の期限が切れたときに古い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自体がEPSを使用するために不合理な原価計算構造を適用している場合、顧客は別のVPCを求めることを強いられ、再度変更シナリオに立ち向かう必要があります。したがって、回避を変更するための鉄のアプローチは、倫理的ビジネス慣行を実施し、合理的な料金を提供する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アドレス指定を使用する非アイロンEUNを使用したグローバルなパブリックIPv4ルーティングおよびアドレス指定システムで構成されています。後者のEunsクラスは、ネットワークアドレス翻訳者（NAT）を介してパブリックインターネットに接続します。クライアントがNATの後ろにある場合、パブリックアドレスを持つクライアントと同じ手順を使用してサーバーを選択します。唯一の要件は、クライアントがSEALカプセル化を構成して、NATトラバーサル、つまりUDPをサポートするトランスポートプロトコルを使用する必要があることです。
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.
鉄は、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.
鉄のサーバーとリレーは、クライアントにプロキシングするインターネットグループ管理プロトコル（IGMP） /マルチキャストリスナーディスカバリー（MLD）を提供するために、トポロジカルに配置されています[RFC4605]。鉄に関するさらなるマルチキャストの考慮事項（たとえば、マルチキャストルーティングプロトコル、トラフィックスケーリングなどとの相互作用など）については、別のドキュメントで説明します。
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によって割り当てられた通常の非EPAアドレスから、または別のクライアントに割り当てられたEPから取得した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（a）内でアドレスEPA（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：ネストされたウンの例
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.
ホストZへの送信パケットのホストの2つのケースとホスト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).
ホストAは、ソースアドレスEPA（a）と宛先アドレスzを使用したパケットを最初にeun（a）に転送します。Eun（a）内のルーティングは、パケットをクライアント（a）に向け、外側のソースアドレスとしてEPA（b）を使用して外側のヘッダーにカプセル化し、外側の宛先アドレスとしてサーバー（a）にカプセル化し、その後、カプセル化されたパケットを転送します。Eun（b）に。Eun（b）内のルーティングは、パケットをクライアント（b）に向け、外側のソースアドレスとしてEPA（c）を使用して外側のヘッダーにカプセル化し、外側の宛先アドレスとしてサーバー（b）をカプセル化し、2回のカプセル化されたパケットを転送しますEun（c）に。Eun（c）内のルーティングは、パケットをクライアント（c）に向けます。これは、ISP（d）を外側のソースアドレスとして、サーバー（c）を外側の宛先アドレスとして外側のヘッダーにカプセル化します。クライアント（c）は、このトリプルカプセル化されたパケットをISP（d）ネットワークに送信し、インターネットにサーバーにルーティングされます（c）。
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）がトリプルカプセル化されたパケットを受信すると、カプセル化の外側の層を削除し、結果の2回カプセル化されたパケットをインターネットにサーバーに転送します（b）。次に、サーバー（b）はカプセル化の外側の層を削除し、結果のかつて除去されるパケットをインターネットに転送します（a）。次に、サーバー（a）は、内側アドレス「z」のアドレスタイプをチェックします。zが非EPAアドレスの場合、サーバー（a）は単にパケットを脱カプセル化し、インターネットに転送します。それ以外の場合、サーバー（a）は、1回限定されたパケットの外側のソースと宛先アドレスを書き換え、リレー（z）に転送します。リレー（z）は、パケットの外側の宛先アドレスをサーバー（z）のロケーターに書き換え、パケットを転送し、リダイレクトをサーバー（a）に送信します（リダイレクトをクライアント（a）に転送します）。サーバー（z）はパケットを再カプセル化し、それをクライアント（z）に転送します。クライアント（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）は、EPA（b）を使用してパケットを外側の宛先アドレスとしてカプセル化し、パケットをインターネットに転送します。インターネットルーティングは、この回転したパケットをサーバー（b）に伝えます。これには、クライアント（b）がEPA（b）に向かう次のホップとしてリスト（b）をリストするマッピングがあります。サーバー（b）は、EPA（c）を使用してパケットを外側の宛先アドレスとしてカプセル化し、パケットをインターネットに転送します。その後、インターネットルーティングは、この2回の抑制されたパケットをサーバー（c）に伝えます。これには、クライアント（c）がEPA（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）に到着すると、カプセル化の外層をストリップし、2回カプセル化されたパケットをEPA（c）に転送します。これはクライアントのロケーターアドレスです（b）。クライアント（b）が2回カプセル化されたパケットを受信すると、カプセル化の外層をストリップし、クライアント（a）のロケーターアドレスであるEPA（b）に1回カプセル化されたパケットを転送します。クライアント（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.
鉄のアーキテクチャは、純粋な動的ルーティングシステムによって得られる最短パスルーティングと、純粋なマッピングシステムによって得られるルーティングスケーリング抑制の両方から利益を得るハイブリッドルーティング/マッピングシステムを想定しています。したがって、鉄は、純粋なルーティングと純粋なマッピングシステムだけでは満足できないというとらえどころのない「スイートスポット」をターゲットにしています。
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.
鉄システムでは、バランスの取れた仮想オーバーレイネットワークを維持するために、インターネットおよび/またはプロバイダーネットワーク全体に新しいルーター/サーバーを展開する必要があります。これらのルーター/サーバーは、既存のインターネットインフラストラクチャを中断することなく徐々に展開でき、顧客に許容可能なサービスレベルを適切に提供することができます。
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 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 Virtual Overlayネットワークは、ネイティブインターネット内の既存および新興サービスとシームレスに動作します。特に、Iron Virtual Overlay Networksがサービスを提供する顧客は、非アイロンサービスプロバイダーがサービスする顧客が享受しているのと同じサービスを受け取ります。ネイティブインターネット内に既に展開されているインターネットサービスは、鉄の仮想オーバーレイネットワークの顧客に対応するために変更を加える必要もありません。
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に対応するリンクを構成する場合があります。鉄システムは、パケットのサイズが基礎となるパスよりわずかに大きくなる可能性のある追加のパケットあたりのオーバーヘッドを課しますが、鉄ルーターは、パスMTUアンダーランのすべてのインスタンスを自然に検出および調整する方法を備えています。場合によっては、これらの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).
最後に、そしておそらく最も重要なこととして、鉄システムは、エンドユーザーデバイスとネットワークが自由に動き回ることを可能にし、ルーティングシステムで最小限の振動を与え、一般的に最短パスルートを維持できるようにする、組み込みのモビリティ管理とマルチホーム機能を提供します。このモビリティ管理は、鉄の顧客/プロバイダー関係の性質そのものを通じて提供されるため、補助メカニズムは必要ありません。モビリティ管理とマルチホーム機能は、IPv6 Neighbor Discovery（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]で説明しています。鉄に固有のその他のスケーリングの考慮事項については、付録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]の概念に基づいて構築されているため、関連するイニシアチブのセットを継承します。インターネット研究タスクフォース（IRTF）ルーティングリサーチグループ（RRG）は、ルーティングアーキテクチャの推奨[RFC6115]について鉄を言及しています。
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 Server Constructは、この作業で説明されているCRの概念に似ています。ただし、顧客がサーバーと調整する方法は異なり、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トラバーサルテクニックを提案しています。鉄に適応したNATトラバーサル技術は、施設のレガシー機器（サンプル）の提案[サンプル]の単純なアドレスマッピングに触発されました。
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]で説明されています。鉄にも適用される追加の考慮事項は、レンジャー[RFC5720] [RFC6139]、VET [Intarea-Vet]、Seal [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).
鉄システムは、さらに、鉄のクライアントをサーバーとサーバーにリレーに相互認証することに依存しています。これは、最初の認証交換と、それに続くトンネル隣人のノンセスを使用して達成されます。これは、パスオフパス攻撃の検出に使用できます。すべてのインターネット通信に関しては、鉄システムは、整合性のあるリレーにも依存し、虚偽の広告を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オーバーレイネットワークには、オーバーレイ内のすべてのリレーとサーバーがクライアント<->サーバーバインディングの一貫したビューを持つように、インテリアルーティングシステムの整合性を保証する手段が必要です。最後に、鉄のリレーとサーバーに対するサービス拒否（DOS）攻撃は、スプーフィングされたソースアドレスを持つパケットが高いデータレートに到達すると発生する可能性があります。ただし、この問題は、今日のパブリックインターネットのBorder Routerの場合と同じです。
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メーリングリストに表示されます。ロビン・ホイットルとスティーブ・ラッサートは、鉄に強く影響を与えたTTRモビリティアーキテクチャを共同執筆しました。エリック・フライシュマンは、トポロジカルに近いサーバーを発見するために、Anycastを活用する機会を指摘しました。トーマス・ヘンダーソンは、スケーリング特性の定量分析を推奨しました。
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.
次の個人は、Jari Arkko、Mohamed Boucadair、Stewart Bryant、John Buford、Ralph Droms、Wesley Eddy、Adrian Farrel、Dae Young Kim、およびRobin Whittleを提供しました。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[BGPMON] net, B., "BGPmon.net - Monitoring Your Prefixes, http://bgpmon.net/stat.php", June 2010.
[BGPMON] Net、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.
[進化] Zhang、B.、Zhang、L。、およびL. Wang、「グローバルルーティングスケーラビリティに向けた進化」、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] Francis、P.、Xu、X.、Ballani、H.、Jen、D.、Raszuk、R。、およびL. Zhang、「Virtual AggregationによるFIB抑制」、2011年2月の作業。
[INTAREA-SEAL] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Work in Progress, February 2011.
[Intarea-Seal] Templin、F.、ed。、「サブネットワークのカプセル化と適応層（SEAL）」、2011年2月の作業。
[INTAREA-VET] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", Work in Progress, January 2011.
[Intarea-Vet] Templin、F.、ed。、「Virtual Enterprise Traversal（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.、Hall、N。、およびM. Rose、「OSIネットワークレイヤーの実験のためのサブネットワークとしてのインターネットの使用」、RFC 1070、1989年2月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526] Johnson、D。およびS. Deering、「予約済みのIPv6サブネットAnycastアドレス」、RFC 2526、1999年3月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068] Huitema、C。、「6to4リレールーターのAnycast Prefix」、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] Baker、F.、Lear、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.、Li、T。、およびS. Hares、「A Border Gateway Protocol 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] Gray、E.、Rutemiller、J。、およびG. Swallow、「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] Fenner、B.、He、H.、Haberman、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] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（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] Eddy、W.、Ivancic、W.、およびT. Davis、「航空および宇宙探査モバイルネットワークでの運用上の使用のためのネットワークモビリティルート最適化要件」、RFC 5522、2009年10月。
[RFC5720] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010.
[RFC5720] Templin、F。、「グローバルエンタープライズリクルシオン（レンジャー）を備えたネットワークでのルーティングとアドレス指定」、RFC 5720、2010年2月。
[RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, December 2009.
[RFC5743] Falk、A。、「インターネット研究タスクフォース（IRTF）ドキュメントストリームの定義」、RFC 5743、2009年12月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887] Carpenter、B.、Atkinson、R。、およびH. Flinck、「Nemumberingまだ仕事が必要」、RFC 5887、2010年5月。
[RFC6115] Li, T., "Recommendation for a Routing Architecture", RFC 6115, February 2011.
[RFC6115] Li、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] Russert、S.、Fleischman、E。、およびF. Templin、「グローバルエンタープライズ再帰（Ranger）シナリオを備えたネットワークでのルーティングとアドレス指定」、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.、Calderon、M。、およびI. Soto、「Cressportent Routerベースのルート最適化（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.
[サンプル] Carpenter、B。およびS. Jiang、「IPv6のレガシーNat Traversal：施設レガシー機器（サンプル）の単純なアドレスマッピング」、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。and S. Russert、「インターネットのルーティングスケーリング問題に対するコアエッジ分離ソリューションのためのTTRモビリティ拡張、http：//www.firstpr.com/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] Krishnan、S.、Thaler、D。、およびJ. Hoagland、「IPトンネリングに関するセキュリティ上の懸念」、2010年10月の作業。
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.
鉄のアーキテクチャは、基礎となるインターネットワークのアドレスファミリと一致するVPSのEPAアドレスを使用して、パケットの一般的に最短パスルーティングを提供することにより、ルーティングシステムを活用します。しかし、VPSが基礎となるインターネットワーク内でルーティングできないアドレスファミリである場合（たとえば、OSI/NSAP [RFC4548] VPがIPv4インターネット内で使用される場合）、グローバルマッピングデータベースを使用するには、サーバーがVPSにマップされるようにするために必要です。インターネットワーク内でルーティング可能なアドレスファミリから取られたコンパニオンプレフィックス。たとえば、IPv6 VP（例：2001：db8 ::/32）は、コンパニオンIPv4プレフィックス（例：192.0.2.0/24）とペアにすることができ、カプセル化されたIPv6パケットをIPv4----インターネットワークに転送できます。
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.
したがって、鉄のすべてのVPは、鉄のすべてのVPのVPからコンパニオンへのプレフィックスマッピングを維持するグローバルに分散したマスターVPデータベース（MVPD）で表現する必要があります。MVPDは、インターネットが割り当てられた数字当局（IANA）と同じ方法で、グローバルに管理された割り当てられた番号当局によって維持されています（IANA）は、現在、すべてのトップレベルのIPv4およびIPv6代表団のマスターリストを維持しています。データベースは、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を読み取ることにより、鉄のVPSの完全なセットを発見します。サーバーは、近くのサーバーから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にパケットを転送できます。したがって、コンパニオンプレフィックスはAnycastプレフィックスとして機能します。
Possible encapsulations in this model include IPv6-in-IPv4, IPv4-in-IPv6, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc.
このモデルの可能なカプセルには、IPv6-in-IPV4、IPv4-in-IPV6、OSI/CLNP-in-IPV6、OSI/CLNP-in-IPV4などが含まれます。
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.
鉄の建築のスケーリングの側面は、実際の展開における適用性に強い影響を及ぼします。スケーリングは、多数の顧客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に委任されるグローバルインターネットルーティングシステムに1つ以上のVPを宣伝します。したがって、各VPが多くのEPをカバーすると、ルーティングスケーリングが最小化されます。たとえば、IPv6プレフィックス2001：db8 ::/32には、eunへの割り当てのための2^24 ::/56 EPプレフィックスが含まれています。したがって、鉄は2^32 ::/56 EPSを収容でき、ドメイン間ルーティングコアに宣伝されているのは2^8 ::/32 VPSだけです。（携帯電話ネットワーク内の個々の携帯電話に割り当てられた /64がさらに長いEPプレフィックスを使用した場合、かなりの数のEUNを1つのVPでのみ表現できます。）各VPには、関連するAnyCastコンパニオンプレフィックスもあります。したがって、VPごとにグローバルルーティングシステムに宣伝されているAnycastプレフィックスが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と非アイロンインターネットの間に転送されるすべてのトラフィックパケットを処理する必要があります。この後者のクラスのトラフィックに対するスケーリングの懸念は、大規模なエンタープライズネットワークをインターネットに接続するASBRルーターの場合と違いはありません。サーバーのトラフィックスケーリングに関しては、各サーバーはVPCオーバーレイネットワークの顧客Eunsのセットをサービスします。サーバーは、すべてのトラフィックパケットをeunsに向けてサービスを提供していますが、EUNSから開始され、EPAに運命づけられたフローの初期パケットのみにサービスを提供しています。したがって、EPAアドレストラフィックのトラフィックスケーリングは非対称的な考慮事項であり、各サーバーが提供するEUNの数に比例します。
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オーバーレイネットワーク内のすべてのサーバーのリストと、各サーバーがサービスを提供するすべての顧客EunのFIBエントリを維持しています。したがって、この状態は、VPCオーバーレイネットワークのEunの数によって支配されています。したがって、VPCオーバーレイネットワーク計画中には、すべてのEunの州情報に対応するためのリレーのサイジングが必要です。サーバーの州の要件に関しては、各サーバーは、サービスを提供する各顧客Eunのトンネル隣人状態を維持していますが、VPCオーバーレイネットワークのすべてのEunの状態を維持する必要はありません。最後に、リレーもサーバーも、アウトバウンドトラフィックの最終的な目的地のために状態を維持する必要はありません。
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.テンプリン（編集者）ボーイングリサーチ＆テクノロジーP.O.ボックス3707 MC 7L-49シアトル、ワシントン州98124 USA
EMail: fltemplin@acm.org