Internet Research Task Force (IRTF) T. Li, Ed.
Request for Comments: 6115 Cisco Systems
Category: Informational February 2011
ISSN: 2070-1721
Recommendation for a Routing Architecture
Abstract
抽象
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group.
一般的にインターネットルーティングとアドレス体系は、スケーラビリティ、マルチホーミング、およびドメイン間のトラフィックエンジニアリングにおける課題に直面していることが認識されています。この文書は、IETFのための将来の方向性の提言として、インターネットの将来の拡張性を支援することができソリューションを提示します。この目的を達成するために、この文書では、調査この活動に議論のために前倒しされた提案だけでなく、その後の分析の一部と椅子の建築勧告の多くを。この文書では、ルーティング研究グループの製品です。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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 Routing 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.
この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットResearch Task Force（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/rfc6115.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6115で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Background to This Document . . . . . . . . . . . . . . . 5
1.2. Areas of Group Consensus . . . . . . . . . . . . . . . . . 6
1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
2. Locator/ID Separation Protocol (LISP) . . . . . . . . . . . . 8
2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. References . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Routing Architecture for the Next Generation Internet
(RANGI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4. References . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Internet Vastly Improved Plumbing (Ivip) . . . . . . . . . . . 16
4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 16
4.1.2. Extensions . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2.1. TTR Mobility . . . . . . . . . . . . . . . . . . . 17
4.1.2.2. Modified Header Forwarding . . . . . . . . . . . . 18
4.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.5. References . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Hierarchical IPv4 Framework (hIPv4) . . . . . . . . . . . . . 21
5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.3. Costs and Issues . . . . . . . . . . . . . . . . . . . 23
5.1.4. References . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Name Overlay (NOL) Service for Scalable Internet Routing . . . 25
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.4. References . . . . . . . . . . . . . . . . . . . . . . 27
6.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Compact Routing in a Locator Identifier Mapping System (CRM) . 29
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1.4. References . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Layered Mapping System (LMS) . . . . . . . . . . . . . . . . . 32
8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 32
8.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1.4. References . . . . . . . . . . . . . . . . . . . . . . 33
8.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 34
9. Two-Phased Mapping . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1.1. Considerations . . . . . . . . . . . . . . . . . . . . 34
9.1.2. Basics of a Two-Phased Mapping . . . . . . . . . . . . 35
9.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 36
9.1.5. References . . . . . . . . . . . . . . . . . . . . . . 36
9.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Global Locator, Local Locator, and Identifier Split
(GLI-Split) . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 36
10.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1.4. References . . . . . . . . . . . . . . . . . . . . . . 38
10.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 39
11. Tunneled Inter-Domain Routing (TIDR) . . . . . . . . . . . . . 40
11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1.4. References . . . . . . . . . . . . . . . . . . . . . . 41
11.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 42
12. Identifier-Locator Network Protocol (ILNP) . . . . . . . . . . 42
12.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 42
12.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 42
12.1.2. Benefits . . . . . . . . . . . . . . . . . . . . . . . 43
12.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1.4. References . . . . . . . . . . . . . . . . . . . . . . 45
12.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 45
12.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 46
13. Enhanced Efficiency of Mapping Distribution Protocols in
Map-and-Encap Schemes (EEMDP) . . . . . . . . . . . . . . . . 48
13.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 48
13.1.2. Management of Mapping Distribution of Subprefixes
Spread across Multiple ETRs . . . . . . . . . . . . . 48
13.1.3. Management of Mapping Distribution for Scenarios
with Hierarchy of ETRs and Multihoming . . . . . . . . 49
13.1.4. References . . . . . . . . . . . . . . . . . . . . . . 50
13.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 51
14. Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1.1. Need for Evolution . . . . . . . . . . . . . . . . . . 52
14.1.2. Relation to Other RRG Proposals . . . . . . . . . . . 53
14.1.3. Aggregation with Increasing Scopes . . . . . . . . . . 53
14.1.4. References . . . . . . . . . . . . . . . . . . . . . . 55
14.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 55
14.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 56
15. Name-Based Sockets . . . . . . . . . . . . . . . . . . . . . . 56
15.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 56
15.1.1. References . . . . . . . . . . . . . . . . . . . . . . 58
15.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.2.1. Deployment . . . . . . . . . . . . . . . . . . . . . . 59
15.2.2. Edge-networks . . . . . . . . . . . . . . . . . . . . 59
15.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 59
16. Routing and Addressing in Networks with Global Enterprise
Recursion (IRON-RANGER) . . . . . . . . . . . . . . . . . . . 59
16.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 59
16.1.1. Gains . . . . . . . . . . . . . . . . . . . . . . . . 60
16.1.2. Costs . . . . . . . . . . . . . . . . . . . . . . . . 61
16.1.3. References . . . . . . . . . . . . . . . . . . . . . . 61
16.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 61
16.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 62
17. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 63
17.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 64
17.2. Recommendation to the IETF . . . . . . . . . . . . . . . . 65
17.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 65
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66
19. Security Considerations . . . . . . . . . . . . . . . . . . . 66
20. Informative References . . . . . . . . . . . . . . . . . . . . 66
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. The problem being addressed has been documented in [Scalability_PS], and the design goals that we have discussed can be found in [RRG_Design_Goals].
一般的にインターネットルーティングとアドレス体系は、スケーラビリティ、マルチホーミング、およびドメイン間のトラフィックエンジニアリングにおける課題に直面していることが認識されています。アドレス指定されている問題は、[Scalability_PS]に記載されている、と我々が議論してきた設計目標は、[RRG_Design_Goals]で見つけることができます。
This document surveys many of the proposals that were brought forward for discussion in this activity. For some of the proposals, this document also includes additional analysis showing some of the concerns with specific proposals, and how some of those concerns may be addressed. Readers are cautioned not to draw any conclusions about the degree of interest or endorsement by the Routing Research Group (RRG) from the presence of any proposals in this document, or the amount of analysis devoted to specific proposals.
この文書では、調査この活動での議論のために前倒しされた提案の多くを。提案のいくつかのために、この文書はまた、具体的な提案との懸念のいくつかを示す追加の分析が含まれており、これらの懸念のいくつかは、どのように対処することができます。読者は、この文書に記載されている任意の提案の存在、あるいは具体的な提案に専念分析の量からルーティング研究グループ（RRG）によって、興味や承認の程度についての結論を引き出すことはないと警告しています。
The RRG was chartered to research and recommend a new routing architecture for the Internet. The goal was to explore many alternatives and build consensus around a single proposal. The only constraint on the group's process was that the process be open and the group set forth with the usual discussion of proposals and trying to build consensus around them. There were no explicit contingencies in the group's process for the eventuality that the group did not reach consensus.
RRGは、研究とインターネットのための新しいルーティングアーキテクチャを推薦するチャーターました。目標は、多くの選択肢を模索し、単一案の周りのコンセンサスを構築することでした。グループのプロセス上の唯一の制約は、プロセスが開いているということであったとのグループは提案の通常の議論を記載し、それらの周りのコンセンサスを構築しようとしています。グループが合意に達しなかった不測の事態のためのグループのプロセスには明示的な偶発事象は認められませんでした。
The group met at every IETF meeting from March 2007 to March 2010 and discussed many proposals, both in person and via its mailing list. Unfortunately, the group did not reach consensus. Rather than lose the contributions and progress that had been made, the chairs (Lixia Zhang and Tony Li) elected to collect the proposals of the group and some of the debate concerning the proposals and make a recommendation from those proposals. Thus, the recommendation reflects the opinions of the chairs and not necessarily the consensus of the group.
グループは一人で、そのメーリングリスト経由の両方、2007年3月から2010年3月にすべてのIETFミーティングで会って、多くの提案について議論しました。残念ながら、グループが合意に達しありませんでした。行われていた貢献と進歩を失うのではなく、椅子（Lixiaチャンとトニー・リー）は、グループの提言や提案に関する議論の一部を収集し、それらの提案から勧告を行うことを選択しました。このように、勧告は椅子の意見とは限らないグループの総意を反映しています。
The group was able to reach consensus on a number of items that are included below. The proposals included here were collected in an open call amongst the group. Once the proposals were collected, the group was solicited to submit critiques of each proposal. The group was asked to self-organize to produce a single critique for each proposal. In cases where there were several critiques submitted, the editor selected one. The proponents of each proposal then were given the opportunity to write a rebuttal of the critique. Finally, the group again had the opportunity to write a counterpoint of the rebuttal. No counterpoints were submitted. For pragmatic reasons, each submission was severely constrained in length.
グループは、以下に含まれるアイテムの数に合意に達することができました。ここに含ま提案はグループの中で、オープン呼び出しで収集しました。提案が収集した後は、グループは、各提案の批評を提出して募集されました。グループは、自己組織化、各提案のための単一の批判を生成するために頼まれました。提出され、いくつかの批判があった場合には、編集者は、1を選択しました。各提案の支持者は、批判の反論を書く機会を与えられました。最後に、グループは再び反論の対位法を書く機会を持っていました。何対位法が提出されませんでした。実用的な理由から、各提出が厳しく長さに拘束されました。
All of the proposals were given the opportunity to progress their documents to RFC status; however, not all of them have chosen to pursue this path. As a result, some of the references in this document may become inaccessible. This is unfortunately unavoidable.
提案はすべて、RFCステータスにその文書を進行する機会を与えられました。しかし、それらのすべては、このパスを追求することを選択していません。その結果、この文書の参照の一部にアクセスできなくなる可能性があります。これは残念ながら避けられません。
The group did reach consensus that the overall document should be published. The document has been reviewed by many of the active members of the Research Group.
グループは、総合的な文書が公開されるべきであるとの合意に達しました。文書は、研究グループのアクティブなメンバーの多くが検討されています。
The group was also able to reach broad and clear consensus on some terminology and several important technical points. For the sake of posterity, these are recorded here:
グループはまた、いくつかの用語といくつかの重要な技術的な点について広範かつ明確な合意に達することができました。後世のために、これらは、ここに記録されています。
2. A "router" is any device that forwards packets at the network layer (e.g., IPv4, IPv6) of the Internet architecture.
2. A「ルータ」は、インターネットアーキテクチャのネットワーク層（例えば、IPv4の、IPv6の）にパケットを転送する任意のデバイスです。
3. A "host" is a device that can send/receive packets to/from the network, but does not forward packets.
3. A「ホスト」は送信/ネットワークから/へのパケットを受信できるデバイスですが、パケットを転送しません。
4. A "bridge" is a device that forwards packets at the link layer (e.g., Ethernet) of the Internet architecture. An Ethernet switch or Ethernet hub are examples of bridges.
4.「ブリッジ」は、インターネットアーキテクチャのリンク層（例えば、イーサネット）にパケットを転送する装置です。イーサネット・スイッチまたはイーサネット・ハブは、ブリッジの例です。
5. An "address" is an object that combines aspects of identity with topological location. IPv4 and IPv6 addresses are current examples.
5.アン「アドレス」は、位相的な位置と同一の態様を組み合わせたオブジェクトです。 IPv4アドレスとIPv6アドレスは、現在の例です。
6. A "locator" is a structured topology-dependent name that is not used for node identification and is not a path. Two related meanings are current, depending on the class of things being named:
6. A「ロケータ」は、ノード識別のために使用されていない構造トポロジー依存性名とパスではありません。二つの関連意味が命名されているもののクラスに応じて、現在、次のとおりです。
2. The topology-dependent name of a single subnetwork OR topology-dependent name of a group of related subnetworks that share a single aggregate. An IP routing prefix is a current example of the latter.
単一の集合体を共有する関連するサブネットワークのグループの単一のサブネットワークまたはトポロジ依存名の2トポロジー依存性名。 IPルーティングプレフィックスは、後者の現在の例です。
7. An "identifier" is a topology-independent name for a logical node. Depending upon instantiation, a "logical node" might be a single physical device, a cluster of devices acting as a single node, or a single virtual partition of a single physical device. An OSI End System Identifier (ESID) is an example of an identifier. A Fully Qualified Domain Name (FQDN) that precisely names one logical node is another example. (Note well that not all FQDNs meet this definition.)
【請求項7】「識別子」論理ノードのトポロジに依存しない名前です。インスタンス化に応じて、「論理ノード」は、単一の物理デバイス、単一のノードとして動作するデバイスのクラスタ、または単一の物理デバイスの単一の仮想パーティションのかもしれません。 OSIエンドシステム識別子（ESID）は識別子の一例です。正確名つの論理ノードは、他の例である完全修飾ドメイン名（FQDN）。 （すべてのFQDNが、この定義を満たしていないことにも注意してください。）
8. Various other names (i.e., other than addresses, locators, or identifiers), each of which has the sole purpose of identifying a component of a logical system or physical device, might exist at various protocol layers in the Internet architecture.
論理システムまたは物理的デバイスの構成要素を特定する唯一の目的をそれぞれ有する8様々な他の名前（アドレス、ロケータ、または識別子以外即ち、他）は、インターネットアーキテクチャ内の様々なプロトコル層に存在するかもしれません。
9. The Research Group has rough consensus that separating identity from location is desirable and technically feasible. However, the Research Group does NOT have consensus on the best engineering approach to such an identity/location split.
9.研究グループは、場所から身元を分離することが望ましいと技術的に実現可能であることをラフコンセンサスを持っています。しかし、研究グループは、このようなアイデンティティ/場所スプリットへの最良の工学的アプローチについて合意を持っていません。
10. The Research Group has consensus that the Internet needs to support multihoming in a manner that scales well and does not have prohibitive costs.
10.研究グループは、インターネットをうまくスケールし、法外なコストを持っていない方法でマルチホーミングをサポートする必要があることを合意しています。
11. Any IETF solution to Internet scaling has to not only support multihoming, but address the real-world constraints of the end customers (large and small).
11.インターネットのスケーリングにどれIETFソリューションは、マルチホーミングをサポートしていますが、（大・小）エンドユーザーの実世界の制約に対処するだけでなく、持っています。
This section lists some of the most common abbreviations used in the remainder of this document.
このセクションでは、この文書の残りの部分で使用される最も一般的な略語の一部を示します。
DFZ Default-Free Zone
DFZデフォルトフリーゾーン
EID Endpoint IDentifier or Endpoint Interface iDentifier: The precise definition varies depending on the proposal.
EIDエンドポイント識別子またはエンドポイント・インタフェースの識別子：正確な定義が提案によって異なります。
ETR Egress Tunnel Router: In a system that tunnels traffic across the existing infrastructure by encapsulating it, the device close to the actual ultimate destination that decapsulates the traffic before forwarding it to the ultimate destination.
ETR出口トンネルルータ：それをカプセル化することによって、既存のインフラストラクチャ全体のトラフィックをトンネリングシステムでは、最終的な宛先に転送する前にトラフィックをデカプセル化し、実際の最終的な目的地に近いデバイス。
FIB Forwarding Information Base: The forwarding table, used in the
FIB転送情報ベース：転送テーブルで使用
data plane of routers to select the next hop for each packet.
ルータのデータ・プレーンは、各パケットの次のホップを選択します。
ITR Ingress Tunnel Router: In a system that tunnels traffic across the existing infrastructure by encapsulating it, the device close to the actual original source that encapsulates the traffic before using the tunnel to send it to the appropriate ETR.
ITR入力トンネルルータ：それをカプセル化することによって、既存のインフラストラクチャ全体のトラフィックをトンネリングシステムでは、適切なETRに送信するトンネルを使用する前にトラフィックをカプセル化し、実際の元のソースに近いデバイス。
PA Provider-Aggregatable: Address space that can be aggregated as part of a service provider's routing advertisements.
PAプロバイダ-集約：サービスプロバイダのルーティング広告の一部として集約することができるアドレス空間。
PI Provider-Independent: Address space assigned by an Internet registry independent of any service provider.
PIプロバイダに依存しない：任意のサービスプロバイダの独立したインターネットレジストリによって割り当てられたアドレス空間。
PMTUD Path Maximum Transmission Unit Discovery: The process or mechanism that determines the largest packet that can be sent between a given source and destination without being either i) fragmented (IPv4 only), or ii) discarded (if not fragmentable) because it is too large to be sent down one link in the path from the source to the destination.
PMTUDパス最大伝送単位ディスカバリー：のいずれかi）が断片化することなく、所与のソースと宛先の間で送信できる最大のパケットを決定するプロセスまたは機構（IPv4の場合のみ）、または、ii）廃棄（フラグメント化しない場合）、それはあまりにもあるのでソースから宛先へのパスの1つのリンクをダウン送信される大きいです。
RIB Routing Information Base. The routing table, used in the control plane of routers to exchange routing information and construct the FIB.
RIBルーティング情報ベース。ルータの制御プレーンで使用されるルーティングテーブルは、ルーティング情報を交換し、FIBを構築します。
RIR Regional Internet Registry.
RIR地域インターネットレジストリ。
RLOC Routing LOCator: The precise definition varies depending on the proposal.
RLOCルーティングロケータ：正確な定義が提案によって異なります。
xTR Tunnel Router: In some systems, the term used to describe a device which can function as both an ITR and an ETR.
XTRのトンネルルータ：いくつかのシステムでは、ITRとETR両方として機能することができる装置を説明するために使用される用語。
Implements a locator/identifier separation mechanism using encapsulation between routers at the "edge" of the Internet. Such a separation allows topological aggregation of the routable addresses (locators) while providing stable and portable numbering of end systems (identifiers).
インターネットの「エッジ」にルータとの間のカプセル化を使用してロケータ/識別子分離機構を実装します。エンドシステム（識別子）の安定的かつポータブル番号を提供しながら、このような分離は、ルーティング可能なアドレス（ロケータ）のトポロジ集約を可能にします。
o topological aggregation of locator space (RLOCs) used for routing, which greatly reduces both the overall size and the "churn rate" of the information needed to operate the Internet global routing system
Oロケータ空間のトポロジ集約（のRLOC）が大幅に全体的なサイズおよびインターネットグローバルルーティングシステムを動作させるために必要な情報の「解約率」の両方を低減する、ルーティングのために使用しました
o separate identifier space (EIDs) for end systems, effectively allowing "PI for all" (no renumbering cost for connectivity changes) without adding state to the global routing system
O別識別子空間グローバルルーティングシステムに状態を追加することなく、効果的に「すべてのためのPI」を可能にするエンドシステムのため（のEID）、（接続の変更なしリナンバリングのコスト）
o improved traffic engineering capabilities that explicitly do not add state to the global routing system and whose deployment will allow active removal of the more-specific state that is currently used
O明示的にグローバルルーティングシステムに状態を追加しないトラフィックエンジニアリング機能を改善し、その展開、現在使用されている以上、特定の状態のアクティブな除去を可能にします
o no changes required to end systems
システムを終了するために必要な変更なしO
o no changes to Internet "core" routers
インターネットへの変更なし○「コア」ルーター
o minimal and straightforward changes to "edge" routers
「エッジ」ルータにO最小限と簡単な変更
o day-one advantages for early adopters
早期導入のためのO日-1の利点
o defined router-to-router protocol
O定義されたルータ間のプロトコル
o defined database mapping system
O定義データベースマッピングシステム
o defined deployment plan
O定義された展開計画
o defined interoperability/interworking mechanisms
O定義相互運用/連動機構
o defined scalable end-host mobility mechanisms
O拡張性の高いエンドホストモビリティメカニズムを定義し
o prototype implementation already exists and is undergoing testing
Oプロトタイプ実装は、すでに存在しているとテストを受けています
o production implementations in progress
進行中のOの生産の実装
o mapping system infrastructure (map servers, map resolvers, Alternative Logical Topology (ALT) routers). This is considered a new potential business opportunity.
Oマッピングシステムインフラストラクチャ（マップサーバ、マップリゾルバ、代替論理トポロジ（ALT）ルータ）。これは、新しい潜在的なビジネスチャンスと考えられています。
o interworking infrastructure (proxy ITRs). This is considered a new potential business opportunity.
O（プロキシのITR）インフラストラクチャをインターワーキング。これは、新しい潜在的なビジネスチャンスと考えられています。
o overhead for determining/maintaining locator/path liveness. This is a common issue for all identifier/locator separation proposals.
/決定ロケータ/パスの生存性を維持するためのOオーバーヘッド。これは、すべての識別子/ロケータ分離の提案のための共通の問題です。
[LISP] [LISP+ALT] [LISP-MS] [LISP-Interworking] [LISP-MN] [LIG] [LOC_ID_Implications]
[LISP] [LISP + ALT] [LISP-MS] [LISP-インターワーキング] [LISP-MN] [LIG] [LOC_ID_Implications]
LISP+ALT distributes mapping information to ITRs via (optional, local, potentially caching) Map Resolvers and with globally distributed query servers: ETRs and optional Map Servers (MSes).
ETRSとオプションのマップサーバ（のMS）：LISP + ALTは（、オプションのローカル、潜在的にキャッシュする）地図リゾルバ経由してグローバルに分散クエリ・サーバとのITRへのマッピング情報を配信します。
A fundamental problem with any global query server network is that the frequently long paths and greater risk of packet loss may cause ITRs to drop or significantly delay the initial packets of many new sessions. ITRs drop the packet(s) they have no mapping for. After the mapping arrives, the ITR waits for a re-sent packet and will tunnel that packet correctly. These "initial-packet delays" reduce performance and so create a major barrier to voluntary adoption on a wide enough basis to solve the routing scaling problem.
任意のグローバルクエリ・サーバ・ネットワークの基本的な問題は、頻繁に長いパスおよびパケット損失の大きなリスクは、ITRのがドロップするか、または大幅に多くの新しいセッションの最初のパケットを遅らせる原因となるかもしれないということです。 ITRが、彼らはのためのマッピングを持っていない（S）パケットをドロップします。マッピング到着後、ITRが正しくパケット再送信パケットとれるトンネルを待ちます。これらの「初期パケット遅延は、」パフォーマンスを低下させるので、ルーティングのスケーリングの問題を解決するために十分な幅に基づき自主的な採用への大きな障壁を作成します。
ALT's delays are compounded by its structure being "aggressively aggregated", without regard to the geographic location of the routers. Tunnels between ALT routers will often span intercontinental distances and traverse many Internet routers.
ALTの遅延は、ルータの地理的位置に関係なく、「積極的集約」され、その構造によって配合されています。 ALTルータ間のトンネルは、多くの場合、大陸間の距離をまたがると、多くのインターネットルータを通過します。
The many levels to which a query typically ascends in the ALT hierarchy before descending towards its destination will often involve excessively long geographic paths and so worsen initial-packet delays.
クエリは、典型的には、その宛先に向けて下降する前に、ALT階層に上昇した多くのレベルは、多くの場合、過度に長い地理的経路を含むので、最初のパケットの遅延を悪化させるであろう。
No solution has been proposed for these problems or for the contradiction between the need for high aggregation while making the ALT structure robust against single points of failure.
単一障害点に対するALT構造は堅牢ながら解決策は、これらの問題のために、高集約のための必要性の間の矛盾のために提案されていません。
LISP's ITRs' multihoming service restoration depends on their determining the reachability of end-user networks via two or more ETRs. Large numbers of ITRs doing this is inefficient and may overburden ETRs.
LISPのITRのマルチホーミングサービス復旧は自分が二つ以上のETRSを経由して、エンドユーザのネットワークの到達可能性を決定するに依存します。これを行うのITRの多数は非効率的であるとETRSを表土があります。
Testing reachability of the ETRs is complex and costly -- and insufficient. ITRs cannot test network reachability via each ETR, since the ITRs do not have the address of a device in each ETR's network. So, ETRs must report network unreachability to ITRs.
及び不十分 - ETRSのテストの到達可能性は、複雑で高価です。 ITRは、各ETRのネットワーク内のデバイスのアドレスを持っていないので、このITRは、各ETRを介してネットワークの到達可能性をテストすることはできません。だから、ETRSは、ITRは、ネットワークの到達不可能を報告しなければなりません。
LISP involves complex communication between ITRs and ETRs, with UDP and 64-bit LISP headers in all traffic packets.
LISPは、すべてのトラフィックパケットにUDPおよび64ビットLISPヘッダとのITRとETRS間の複雑な通信を伴います。
The advantage of LISP+ALT is that its ability to handle billions of EIDs is not constrained by the need to transmit or store the mapping to any one location. Such numbers, beyond a few tens of millions of EIDs, will only result if the system is used for mobility. Yet the concerns just mentioned about ALT's structure arise from the millions of ETRs that would be needed just for non-mobile networks.
LISP +のALTの利点のEID十億を処理する能力を送信またはいずれかの場所へのマッピングを格納する必要性によって制約されないことです。システムは移動性のために使用されている場合、このような数字は、何百万人のEIDの数十を超えて、のみとなります。しかし、ちょうどALTの構造について言及した懸念は、単に非モバイルネットワークのために必要とされるであろうETRS数百万から生じます。
In LISP's mobility approach, each Mobile Node (MN) needs an RLOC address to be its own ETR, meaning the MN cannot be behind a NAT. Mapping changes must be sent instantly to all relevant ITRs every time the MN gets a new address -- LISP cannot achieve this.
LISPのモビリティ・アプローチでは、各モバイルノード（MN）は、MNがNATの背後にならないことができることを意味し、独自のETRするRLOCアドレスが必要です。マッピングの変更は、関連するすべてのITRに瞬時にMNが新しいアドレスを取得するたびに送信する必要があります - LISPは、これを達成することはできません。
In order to enforce ISP filtering of incoming packets by source address, LISP ITRs would have to implement the same filtering on each decapsulated packet. This may be prohibitively expensive.
ソース・アドレスによって着信パケットのISPフィルタリングを適用するために、LISPのITRはそれぞれデカプセル化パケットに同じフィルタリングを実装しなければなりません。これは非常に高価かもしれません。
LISP monolithically integrates multihoming failure detection and restoration decision-making processes into the Core-Edge Separation (CES) scheme itself. End-user networks must rely on the necessarily limited capabilities that are built into every ITR.
LISPモノリシックには、コア・エッジ分離（CES）方式自体にマルチホーミング障害の検出と修復意思決定プロセスを統合します。エンドユーザーのネットワークは、すべてのITRに組み込まれている、必ずしも限定された機能に依存しなければなりません。
LISP+ALT may be able to solve the routing scaling problem, but alternative approaches would be superior because they eliminate the initial-packet delay problem and give end-user networks real-time control over ITR tunneling.
LISP + ALTは、ルーティングのスケーリングの問題を解決できるかもしれないが、彼らは、最初のパケット遅延の問題を解消し、エンドユーザーのネットワークにITRトンネルの上にリアルタイム制御を与えるための別のアプローチは優れていることでしょう。
Initial-packet loss/delays turn out not to be a deep issue. Mechanisms for interoperation with the legacy part of the network are needed in any viably deployable design, and LISP has such mechanisms. If needed, initial packets can be sent via those legacy mechanisms until the ITR has a mapping. (Field experience has shown that the caches on those interoperation devices are guaranteed to be populated, as 'crackers' doing address-space sweeps periodically send packets to every available mapping.)
初期パケット損失/遅延が深い問題ではないことが判明します。ネットワークのレガシー部分との相互運用のためのメカニズムは、任意の生存可能に配置可能な設計に必要な、とLISPは、そのようなメカニズムを持っています。必要な場合はITRがマッピングを持ってまで、最初のパケットは、それらの従来の機構を介して送信することができます。 （フィールドでの経験は「クラッカー」やったアドレス空間のスイープを定期的に使用可能なすべてのマッピングにパケットを送信するよう、それらの相互運用デバイス上のキャッシュは、読み込まれることが保証されていることが示されています。）
On ALT issues, it is not at all mandatory that ALT be the mapping system used in the long term. LISP has a standardized mapping system interface, in part to allow reasonably smooth deployment of whatever new mapping system(s) experience might show are required. At least one other mapping system (LISP-TREE) [LISP-TREE], which avoids ALT's problems (such as query load concentration at high-level nodes), has already been laid out and extensively simulated. Exactly what mixture of mapping system(s) is optimal is not really answerable without more extensive experience, but LISP is designed to allow evolutionary changes to other mapping system(s).
ALTの問題で、ALTが長期的に使用されるマッピングシステムであることは全く必須ではありません。 LISPはどんな新しいマッピングシステム（複数可）の経験を合理的にスムーズな展開が必要とされて表示される場合があります許可する部分には、標準化されたマッピングシステムのインタフェースを持っています。 （このような高レベルのノードにクエリ負荷濃度など）ALTの問題を回避する少なくとも一つの他のマッピングシステム（LISP-TREE）LISP-TREE]は、既にレイアウトと広範囲シミュレートされています。まさにマッピングシステム（S）の混合物が最適であることは、より広範な経験のない本当に釈明はありませんが、LISPは、他のマッピングシステム（複数可）への進化の変更を許可するように設計されています。
As far as ETR reachability goes, a potential problem to which there is a solution with an adequate level of efficiency, complexity, and robustness is not really a problem. LISP has a number of overlapping mechanisms that it is believed will provide adequate reachability detection (along the three axes above), and in field testing to date, they have behaved as expected.
限りETRの到達可能性が行くように、潜在的な問題は、十分な効率のレベル、複雑さ、および堅牢性を持つソリューションは、実際には問題ありませんされています。 LISPは、（上記の3つの軸に沿って）十分な到達可能性検出を提供し、これまでのフィールドテストでは、彼らが期待通りに挙動していると考えられている重複機構の数を有しています。
Operation of LISP devices behind a NAT has already been demonstrated. A number of mechanisms to update correspondent nodes when a mapping is updated have been designed (some are already in use).
NATの背後にあるLISPデバイスの動作は、既に実証されています。マッピングが設計されている更新されたときに対応ノードを更新するための機構の数（いくつかは既に使用されています）。
Similar to Host Identity Protocol (HIP) [RFC4423], RANGI introduces a host identifier layer between the network layer and the transport layer, and the transport-layer associations (i.e., TCP connections) are no longer bound to IP addresses, but to host identifiers. The major difference from HIP is that the host identifier in RANGI is a 128-bit hierarchical and cryptographic identifier that has organizational structure. As a result, the corresponding ID->locator mapping system for such identifiers has a reasonable business model and clear trust boundaries. In addition, RANGI uses IPv4-embedded IPv6 addresses as locators. The Locator Domain Identifier (LD ID) (i.e., the leftmost 96 bits) of this locator is a provider-assigned /96 IPv6 prefix, while the last four octets of this locator are a local IPv4 address (either public or private). This special locator could be used to realize 6over4 automatic tunneling (borrowing ideas from the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]), which will reduce the deployment cost of this new routing architecture. Within RANGI, the mappings from FQDN to host identifiers are stored in the DNS system, while the mappings from host identifiers to locators are stored in a distributed ID/locator mapping system (e.g., a hierarchical Distributed Hash Table (DHT) system, or a reverse DNS system).
アイデンティティプロトコル（HIP）[RFC4423]をホストと同様に、ランギは、ネットワーク層とトランスポート層、およびトランスポート層の団体間のホスト識別子層を導入し（すなわち、TCP接続は）もはやIPアドレスにバインドされていないが、ホストします識別子。 HIPからの主な違いは、ランギのホスト識別子が組織構造を有している128ビット階層と暗号識別子であることです。その結果、そのような識別子の対応ID->ロケータマッピングシステムは、合理的なビジネスモデルと明確な信頼境界を持っています。また、ランギは、ロケータとしてのIPv4埋め込みIPv6アドレスを使用します。このロケータの最後の4つのオクテット（パブリックまたはプライベートのいずれか）、ローカルIPv4アドレスであるが、このロケータのロケータドメイン識別子（LDのID）（すなわち、左端の96ビット）は、プロバイダが割り当て/ 96 IPv6プレフィックスです。この特別なロケータは、この新たなルーティングアーキテクチャの導入コストを削減する、（プロトコル（ISATAP）[RFC5214]をアドレス指定、サイト内の自動トンネルからアイデアを借用）6over4は自動トンネリングを実現するために使用することができます。ホスト識別子からロケータへのマッピングは、分散ID /ロケータマッピングシステム（例えば、階層分散ハッシュテーブル（DHT）システム、またはAに格納されている間ランギ内に、識別子をホストするFQDNのマッピングは、DNSシステムに格納されていますリバースDNSシステム）。
RANGI achieves almost all of the goals set forth by RRG as follows:
ランギは、ほぼ次のようにRRGが定めるすべての目標実現します：
1. Routing Scalability: Scalability is achieved by decoupling identifiers from locators.
1.ルーティングスケーラビリティ：スケーラビリティは、ロケータから識別子を切り離すことによって達成されます。
2. Traffic Engineering: Hosts located in a multihomed site can suggest the upstream ISP for outbound and inbound traffic, while the first-hop Locator Domain Border Router (LDBR; i.e., site border router) has the final decision on the upstream ISP selection.
2.トラフィックエンジニアリング：;上流ISPの選択の最終決定を持っているマルチホームのサイトにあるホストは、最初のホップのロケータドメイン境界ルータ（すなわち、サイトの境界ルータLDBR）ながら、アウトバウンドとインバウンドトラフィックのための上流ISPを提案することができます。
3. Mobility and Multihoming: Sessions will not be interrupted due to locator change in cases of mobility or multihoming.
3.モビリティとマルチホーミング：セッションが原因モビリティやマルチホーミングの例でロケータ変化に中断されることはありません。
4. Simplified Renumbering: When changing providers, the local IPv4 addresses of the site do not need to change. Hence, the internal routers within the site don't need renumbering.
4.簡体リナンバリング：プロバイダを変更する場合は、サイトのローカルIPv4アドレスを変更する必要はありません。したがって、サイト内の内部ルータは、再番号付けを必要としません。
6. Routing Stability: Since the locators are topologically aggregatable and the internal topology within the LD will not be disclosed outside, routing stability could be improved greatly.
6.ルーティング安定性：ロケータがトポロジー的に集約され、LDの内部トポロジーが外部に開示されないので、ルーティングの安定性が大幅に向上することができます。
7. Routing Security: RANGI reuses the current routing system and does not introduce any new security risks into the routing system.
7.ルーティングセキュリティ：ランギは、現在のルーティングシステムを再利用し、ルーティングシステムに新たなセキュリティリスクを導入しません。
8. Incremental Deployability: RANGI allows an easy transition from IPv4 networks to IPv6 networks. In addition, RANGI proxy allows RANGI-aware hosts to communicate to legacy IPv4 or IPv6 hosts, and vice versa.
8.増分展開性：ランギは、IPv6ネットワークにIPv4ネットワークから簡単に移行することを可能にします。また、ランギプロキシはランギ対応ホストはレガシーIPv4またはIPv6ホスト、及びその逆に通信することを可能にします。
2. The first-hop LDBR change is required to support site-controlled traffic-engineering capability.
2.最初のホップLDBRの変更は、サイト制御トラフィック・エンジニアリング機能をサポートするために必要です。
3. The ID->locator mapping system is a new infrastructure to be deployed.
3. ID->ロケータマッピングシステムを展開する新しいインフラストラクチャです。
4. RANGI proxy needs to be deployed for communication between RANGI-aware hosts and legacy hosts.
4.ランギプロキシはランギ対応ホストとレガシー・ホストとの間の通信のために配備される必要があります。
[RFC3007] [RFC4423] [RANGI] [RANGI-PROXY] [RANGI-SLIDES]
[RFC3007]、[RFC4423] [天] [ランギプロキシ] [ランギ-Kiriata]
RANGI is an ID/locator split protocol that, like HIP, places a cryptographically signed ID between the network layer (IPv6) and transport. Unlike the HIP ID, the RANGI ID has a hierarchical structure that allows it to support ID->locator lookups. This hierarchical structure addresses two weaknesses of the flat HIP ID: the difficulty of doing the ID->locator lookup, and the administrative scalability of doing firewall filtering on flat IDs. The usage of this hierarchy is overloaded: it serves to make the ID unique, to drive the lookup process, and possibly other things like firewall filtering. More thought is needed as to what constitutes these levels with respect to these various roles.
ランギはHIPのように、ネットワーク層（IPv6）の輸送との間の暗号署名されたIDを配置し、ID /ロケータ分離プロトコルです。 HIPのIDとは異なり、ランギIDは、ID->ロケータ検索をサポートすることを可能にする階層構造を有しています。 ID->ロケータルックアップを実行することの難しさ、およびフラットIDにファイアウォールフィルタリングを行うための管理スケーラビリティ：この階層構造は、フラットHIPのIDの2弱点に対処しています。この階層の利用は、オーバーロードされます。それは、IDを一意にするために、ルックアップ・プロセスを駆動するために、そしておそらく他のもののファイアウォールのフィルタリングのように機能します。より多くの思考は、これらの様々な役割に関して、これらのレベルを構成するものへと必要とされています。
The RANGI document [RANGI] suggests FQDN->ID lookup through DNS, and separately an ID->locator lookup that may be DNS or may be something else (a hierarchy of DHTs). It would be more efficient if the FQDN lookup produces both ID and locators (as does the Identifier-Locator Network Protocol (ILNP)). Probably DNS alone is sufficient for the ID->locator lookup since individual DNS servers can hold very large numbers of mappings.
ランギドキュメント[ランギ]はDNS経由FQDN-> IDの検索を提案し、DNSであるか、または何か他のもの（のDHTの階層構造）であってもよい別途ID->ロケータ検索。 FQDNのルックアップはIDとロケーターの両方を生成する場合、それは、より効率的である（識別子ロケータネットワークプロトコル（ILNP）のように）。おそらく一人でDNS個々のDNSサーバは、マッピングの非常に大きな数字を保持することができるのでID->ロケータのルックアップのために十分です。
RANGI provides strong sender identification, but at the cost of computing crypto. Many hosts (public web servers) may prefer to forgo the crypto at the expense of losing some functionality (receiver mobility or dynamic multihoming load balancing). While RANGI doesn't require that the receiver validate the sender, it may be good to have a mechanism whereby the receiver can signal to the sender that it is not validating, so that the sender can avoid locator changes.
ランギは、強力な送信者識別情報を提供していますが、暗号を計算するコストで。多くのホスト（パブリックWebサーバ）は、一部の機能（受信機の移動性や動的なマルチホーミング負荷分散を）失うことを犠牲にして暗号化を見送ることを好むことがあります。ランギは、受信者が送信者を検証することを必要としないが、受信機が、送信者がロケータの変化を避けることができるように、それは、検証されていないことを送信者に知らせることができる機構を有することが良いかもしれません。
Architecturally, there are many advantages to putting the mapping function at the end host (versus at the edge). This simplifies the problems of neighbor aliveness and delayed first packet, and avoids stateful middleboxes. Unfortunately, the early-adopter incentive for host upgrade may not be adequate (HIP's lack of uptake being an example).
アーキテクチャ、（エッジで対）エンドホストにマッピング関数を置くには多くの利点があります。これは、隣接稼働状態と遅延された第1のパケットの問題を簡素化し、ステートフルミドルボックスを回避することができます。残念ながら、ホストのアップグレードのための早期導入のインセンティブが（取り込みのHIPの不足は、一例である）適切ではないかもしれません。
RANGI does not have an explicit solution for the mobility race condition (there is no mention of a home-agent-like device). However, host-to-host notification combined with fallback on the ID->locators lookup (assuming adequate dynamic update of the lookup system) may be good enough for the vast majority of mobility situations.
ランギは（ホームエージェントのようなデバイスの言及がない）モビリティ競合状態のための明示的な解決策を持っていません。しかし、ホストからホストへ通知ID-にフォールバックと組み合わせ>ロケータルックアップ（検索システムの適切な動的更新を想定）は、モビリティ状況の大半のために十分であってもよいです。
RANGI uses proxies to deal with both legacy IPv6 and IPv4 sites. RANGI proxies have no mechanisms to deal with the edge-to-edge aliveness problem. The edge-to-edge proxy approach dirties up an otherwise clean end-to-end model.
ランギは、両方のレガシーIPv6とIPv4のサイトに対処するためにプロキシを使用しています。ランギプロキシは、エッジ・ツー・エッジ稼働状態の問題に対処するいかなる機構を有していません。エッジ・ツー・エッジプロキシアプローチは、そうでなければ清浄なエンドツーエンドモデルを汚し。
RANGI exploits existing IPv6 transition technologies (ISATAP and softwire). These transition technologies are in any event being pursued outside of RRG and do not need to be specified in RANGI drafts per se. RANGI only needs to address how it interoperates with IPv4 and legacy IPv6, which it appears to do adequately well through proxies.
ランギは、既存のIPv6移行テクノロジ（ISATAPおよびsoftwire）を利用します。これらの移行テクノロジは、RRGの外で追求されて任意のイベントであり、それ自体を立案ランギで指定する必要はありません。ランギは、それはプロキシ経由十分にうまくやって表示され、IPv4とIPv6の遺産、と相互運用する方法に対処する必要があります。
The reason why the ID->locator lookup is separated from the FQDN->ID lookup is: 1) not all applications are tied to FQDNs, and 2) it seems unnecessary to require all devices to possess a FQDN of their own. Basically, RANGI uses DNS to realize the ID->locator mapping system. If there are too many entries to be maintained by the authoritative servers of a given Administrative Domain (AD), Distributed Hash Table (DHT) technology can be used to make these authoritative servers scale better, e.g., the mappings maintained by a given AD will be distributed among a group of authoritative servers in a DHT fashion. As a result, the robustness feature of DHT is inherited naturally into the ID->locator mapping system. Meanwhile, there is no trust issue since each AD authority runs its own DHT ring, which maintains only the mappings for those identifiers that are administrated by that AD authority.
ID->ロケータルックアップがFQDN-> IDの検索から分離されている理由は、1）すべてのアプリケーションがのFQDNに縛られない、そして2）自分自身のFQDNを所有するすべてのデバイスを必要とするために不必要なようです。基本的には、ランギはID->ロケータマッピングシステムを実現するためにDNSを使用しています。与えられた管理ドメイン（AD）の権威サーバによって維持することがあまりにも多くのエントリがある場合は、分散ハッシュテーブル（DHT）技術は、これらの権威サーバは、例えば、より良い与えられたADによって維持マッピングを拡張するために使用することができますDHT方式で権威サーバのグループ間で分散します。結果として、DHTのロバスト性の特徴はID->ロケータマッピングシステムに自然に継承されます。各AD機関はそのAD当局によって管理されているこれらの識別子のための唯一のマッピングを維持し、独自のDHTリングを実行しますので、また、何の信頼の問題はありません。
For host mobility, if communicating entities are RANGI nodes, the mobile node will notify the correspondent node of its new locator once its locator changes due to a mobility or re-homing event. Meanwhile, it should also update its locator information in the ID->locator mapping system in a timely fashion by using the Secure DNS Dynamic Update mechanism defined in [RFC3007]. In case of simultaneous mobility, at least one of the nodes has to resort to the ID->locator mapping system for resolving the correspondent node's new locator so as to continue their communication. If the correspondent node is a legacy host, Transit Proxies, which fulfill a similar function as the home agents in Mobile IP, will relay the packets between the communicating parties.
通信エンティティがランギのノードであれば、ホストモビリティのために、移動ノードは、移動または再ホーミングイベントに、そのロケータの変更後の新しいロケータのコレスポンデントノードに通知します。一方、それはまた、[RFC3007]で定義されたセキュアDNS動的更新メカニズムを使用してタイムリーにID->ロケータマッピングシステムでのロケータ情報を更新すべきです。同時モビリティの場合には、ノードの少なくとも一つは、彼らの通信を継続するように、通信相手ノードの新しいロケータを解決するためのID->ロケータマッピングシステムに頼らなければなりません。コレスポンデントノードは、レガシーホストである場合には、モバイルIPにおけるホームエージェントとして同様の機能を果たすトランジットプロキシは、通信当事者間でパケットを中継します。
RANGI uses proxies (e.g., Site Proxy and Transit Proxy) to deal with both legacy IPv6 and IPv4 sites. Since proxies function as RANGI hosts, they can handle Locator Update Notification messages sent from remote RANGI hosts (or even from remote RANGI proxies) correctly. Hence, there is no edge-to-edge aliveness problem. Details will be specified in a later version of RANGI-PROXY.
ランギは、両方のレガシーIPv6とIPv4のサイトに対処するためのプロキシ（例えば、サイトプロキシとトランジットプロキシ）を使用しています。ランギホストとしてプロキシ機能するので、彼らは（あるいはリモートランギプロキシから）正しくリモートランギホストから送信されたロケータ更新通知メッセージを処理することができます。したがって、全くエッジ・ツー・エッジ稼働状態の問題は存在しません。詳細は、ランギ-PROXYの以降のバージョンで指定されます。
The intention behind RANGI using IPv4-embedded IPv6 addresses as locators is to reduce the total deployment cost of this new Internet architecture and to avoid renumbering the site's internal routers when such a site changes ISPs.
ロケータとしてのIPv4-埋め込まれたIPv6アドレスを使用してランギの背後にある意図は、この新しいインターネットアーキテクチャの総導入コストを削減し、このようなサイトはISPのを変更したときに、サイトの内部ルーターを再番号付けないようにすることです。
Ivip (pronounced eye-vip, est. 2007-06-15) is a Core-Edge Separation scheme for IPv4 and IPv6. It provides multihoming, portability of address space, and inbound traffic engineering for end-user networks of all sizes and types, including those of corporations, SOHO (Small Office, Home Office), and mobile devices.
Ivip（発音目VIP、EST。2007-06-15）は、IPv4およびIPv6のためのコア・エッジ分離方式です。これは、企業、SOHO（スモールオフィス、ホームオフィス）、およびモバイルデバイスのものも含め、すべてのサイズと種類のエンドユーザのネットワークのためのマルチホーミング、アドレス空間の移植性、およびインバウンドトラフィックエンジニアリングを提供します。
Ivip meets all the constraints imposed by the need for widespread voluntary adoption [Ivip_Constraints].
Ivipは[Ivip_Constraints]広範な自主的な採用の必要性によって課されるすべての制約を満たしています。
Ivip's global fast-push mapping distribution network is structured like a cross-linked multicast tree. This pushes all mapping changes to full-database query servers (QSDs) within ISPs and end-user networks that have ITRs. Each mapping change is sent to all QSDs within a few seconds. (Note: "QSD" is from Query Server with full Database.)
Ivipのグローバル高速プッシュマッピング配信ネットワークは、架橋されたマルチキャストツリーのように構成されています。これは、ISPやITRのを持っているエンドユーザーのネットワーク内の全データベースのクエリ・サーバ（QSDs）へのすべてのマッピングの変更をプッシュします。各マッピングの変更は、数秒以内にすべてのQSDsに送信されます。 （注：「QSDは、」完全なデータベースとクエリサーバーからです。）
ITRs gain mapping information from these local QSDs within a few tens of milliseconds. QSDs notify ITRs of changed mappings with similarly low latency. ITRs tunnel all traffic packets to the correct ETR without significant delay.
ITRが数十ミリ秒以内にこれらのローカルQSDsからのマッピング情報を得ることができます。 QSDsは、同様に低遅延で変更されたマッピングのITRを通知します。 ITRのトンネル大幅な遅延なしに正しいETRへのすべてのトラフィックパケット。
Ivip's mapping consists of a single ETR address for each range of mapped address space. Ivip ITRs do not need to test reachability to ETRs because the mapping is changed in real-time to that of the desired ETR.
Ivipのマッピングは、マッピングされたアドレス空間の各範囲のための単一のETRアドレスで構成されています。 Ivip ITRは、マッピングが必要なETRのものにリアルタイムで変化するためETRSに到達可能性をテストする必要はありません。
End-user networks control the mapping, typically by contracting a specialized company to monitor the reachability of their ETRs, and change the mapping to achieve multihoming and/or traffic engineering (TE). So, the mechanisms that control ITR tunneling are controlled by the end-user networks in real-time and are completely separate from the Core-Edge Separation scheme itself.
エンドユーザネットワークは、典型的には、そのETRSの到達可能性を監視し、マルチホーミングおよび/またはトラフィックエンジニアリング（TE）を達成するためにマッピングを変更するには、専門の会社を契約することで、マッピングを制御します。だから、ITRトンネリングを制御するメカニズムは、リアルタイムでエンドユーザネットワークによって制御され、コア・エッジ分離スキーム自体から完全に分離されています。
ITRs can be implemented in dedicated servers or hardware-based routers. The ITR function can also be integrated into sending hosts. ETRs are relatively simple and only communicate with ITRs rarely -- for Path MTU management with longer packets.
ITRが専用サーバーまたはハードウェアベースのルータで実現することができます。 ITR機能も送信ホストに統合することができます。 ETRSは比較的単純であり、唯一のまれのITRとの通信 - 長いパケットでパスMTU管理のため。
Ivip-mapped ranges of end-user address space need not be subnets. They can be of any length, in units of IPv4 addresses or IPv6 /64s.
エンドユーザーのアドレス空間のIvipマッピングされた範囲がサブネットである必要はありません。彼らは、IPv4アドレスまたはIPv6 / 64Sの単位で、任意の長さであってもよいです。
Compared to conventional unscalable BGP techniques, and to the use of Core-Edge Separation architectures with non-real-time mapping systems, end-user networks will be able to achieve more flexible and responsive inbound TE. If inbound traffic is split into several streams, each to addresses in different mapped ranges, then real-time mapping changes can be used to steer the streams between multiple ETRs at multiple ISPs.
従来のスケーラブルBGP技術に比べて、非リアルタイムマッピングシステムとコア・エッジ分離アーキテクチャの使用に、エンドユーザのネットワークがより柔軟で応答性のインバウンドTEを達成することができるようになります。インバウンドトラフィックは、異なるマッピングされた範囲内のアドレスにそれぞれ、複数のストリームに分割されている場合、リアルタイムマッピングの変更は、複数のISPに複数ETRS間のストリームを操縦するために使用することができます。
Default ITRs in the DFZ (DITRs; similar to LISP's Proxy Tunnel Routers) tunnel packets sent by hosts in networks that lack ITRs. So multihoming, portability, and TE benefits apply to all traffic.
ITRを欠き、ネットワーク内のホストによって送信されたトンネルパケット、DFZ（LISPのプロキシトンネルルータと同様DITRs）におけるデフォルトのITR。だから、マルチホーミング、移植性、およびTEの利点は、すべてのトラフィックに適用されます。
ITRs request mappings either directly from a local QSD or via one or more layers of caching query servers (QSCs), which in turn request it from a local QSD. QSCs are optional but generally desirable since they reduce the query load on QSDs. (Note: "QSC" is from Query Server with Cache.)
直接ローカルQSDからか、今度は地元QSDからそれを要求するキャッシュクエリ・サーバ（QSCs）、の一つ以上の層を経由してのいずれかのITR要求のマッピング。彼らはQSDs上のクエリ負荷を軽減するため、QSCsはオプションですが、一般的に望ましいものです。 （注：「QSCは、」キャッシュとクエリサーバーからです。）
ETRs may be in ISP or end-user networks. IP-in-IP encapsulation is used, so there is no UDP or any other header. PMTUD (Path MTU Discovery) management with minimal complexity and overhead will handle the problems caused by encapsulation, and adapt smoothly to jumbo frame paths becoming available in the DFZ. The outer header's source address is that of the sending host -- this enables existing ISP Border Router (BR) filtering of source addresses to be extended to encapsulated traffic packets by the simple mechanism of the ETR dropping packets whose inner and outer source address do not match.
ETRSは、ISPまたはエンドユーザのネットワークであってもよいです。 IPインIPカプセル化が使用されるので、何UDPまたは任意の他のヘッダが存在しません。最小限の複雑さとオーバーヘッドでPMTUD（パスMTUディスカバリ）管理は、カプセル化によって引き起こされる問題に対処し、DFZに利用可能になるジャンボフレーム路に円滑に適応します。外部ヘッダのソース・アドレスは、送信ホストのそれである - これは、内側と外側のソースアドレスないETRドロップパケットの単純な機構によってカプセル化されたトラフィックパケットに拡張するソースアドレスの既存のISPボーダルータ（BR）フィルタリングを可能にします一致。
The Translating Tunnel Router (TTR) approach to mobility [Ivip_Mobility] is applicable to all Core-Edge Separation techniques and provides scalable IPv4 and IPv6 mobility in which the MN keeps its own mapped IP address(es) no matter how or where it is physically connected, including behind one or more layers of NAT.
モビリティ[Ivip_Mobility]への翻訳トンネルルータ（TTR）のアプローチは、すべてのコア・エッジの分離技術に適用可能であり、それが物理的にどこどんなにまたはMNは、独自のマッピングされたIPアドレスを保持するスケーラブルなIPv4とIPv6のモビリティを提供しませんNATの一つ以上の層の後ろに含め、接続されています。
Path lengths are typically optimal or close to optimal, and the MN communicates normally with all other non-mobile hosts (no stack or application changes), and of course other MNs. Mapping changes are only needed when the MN uses a new TTR, which would typically occur if the MN moved more than 1000 km. Mapping changes are not required when the MN changes its physical address(es).
経路長は、典型的には、最適または最適に近いものであり、MNは、他のすべての非モバイルホスト（NOスタックまたはアプリケーションの変更）と、そしてもちろん、他のMNの通常の通信を行います。 MNは、MN以上千キロを移動した場合、通常発生するであろう新しいTTRを、使用する際にマッピングの変更のみが必要とされています。 MNは、その物理アドレスを変更した場合のマッピングの変更は必要ありません。
Separate schemes for IPv4 and IPv6 enable tunneling from ITR to ETR without encapsulation. This will remove the encapsulation overhead and PMTUD problems. Both approaches involve modifying all routers between the ITR and ETR to accept a modified form of the IP header. These schemes require new FIB/RIB functionality in DFZ and some other routers but do not alter the BGP functions of DFZ routers.
IPv4とIPv6のための別のスキームは、カプセル化することなく、ETRにITRからのトンネリングを有効にします。これは、カプセル化オーバーヘッドとPMTUDの問題を削除します。両方のアプローチは、IPヘッダの修正された形式を受け入れるようにITRとETRの間のすべてのルータを変更することを含みます。これらのスキームはDFZといくつかの他のルータで新しいFIB / RIB機能を必要とするが、DFZルータのBGP機能を変更しません。
o Amenable to widespread voluntary adoption due to no need for host changes, complete support for packets sent from non-upgraded networks and no significant degradation in performance.
広範囲の自主的な採用に適しOによるホストの変更、非アップグレードのネットワークから送信されたパケットのための完全なサポートとパフォーマンスに有意な低下が不要に。
o Modular separation of the control of ITR tunneling behavior from the ITRs and the Core-Edge Separation scheme itself: end-user networks control mapping in any way they like, in real-time.
OのITRおよびコア・エッジ分離スキーム自体からITRトンネルの挙動の制御のモジュラー分離：彼らは好きなようで、エンドユーザのネットワーク制御マッピング、リアルタイムインチ
o A small fee per mapping change deters frivolous changes and helps pay for pushing the mapping data to all QSDs. End-user networks that make frequent mapping changes for inbound TE should find these fees attractive considering how it improves their ability to utilize the bandwidth of multiple ISP links.
Oマッピングの変更ごとに小額の手数料は、軽薄な変化を抑止し、すべてのQSDsにマッピングデータをプッシュするために支払うことができます。インバウンドTEのための頻繁なマッピング変更を行い、エンドユーザネットワークは、複数のISPリンクの帯域幅を利用する能力を向上させる方法を検討これらの手数料が魅力を感じるはずです。
o End-user networks will typically pay the cost of Open ITR in the DFZ (OITRD) forwarding to their networks. This provides a business model for OITRD deployment and avoids unfair distribution of costs.
Oエンドユーザネットワークは、典型的には、そのネットワークへのDFZ（OITRD）転送にオープンITRの費用を支払うことになります。これはOITRD展開のためのビジネスモデルを提供し、コストの不公平な分配を避けることができます。
o Existing source address filtering arrangements at BRs of ISPs and end-user networks are prohibitively expensive to implement directly in ETRs, but with the outer header's source address being the same as the sending host's address, Ivip ETRs inexpensively enforce BR filtering on decapsulated packets.
ISPやエンドユーザネットワークののBRにおけるO既存のソースアドレスフィルタリング装置はETRSに直接実装する非常に高価であるが、外部ヘッダのソース・アドレスが送信元ホストのアドレスと同じであると、Ivip ETRS安価デカプセル化パケットにBRフィルタリングを強制します。
QSDs receive all mapping changes and store a complete copy of the mapping database. However, a worst-case scenario is 10 billion IPv6 mappings, each of 32 bytes, which fits on a consumer hard drive today and should fit in server DRAM by the time such adoption is reached.
QSDsは、すべてのマッピング変更を受信し、マッピングデータベースの完全なコピーを格納します。しかし、最悪のシナリオは、100億のIPv6のマッピング、今日の消費者のハードドライブに収まると、このような採用が到達した時点で、サーバのDRAMに適合しなければならない32バイト、のそれぞれです。
The maximum number of non-mobile networks requiring multihoming, etc., is likely to be ~10 million, so most of the 10 billion mappings would be for mobile devices. However, TTR mobility does not involve frequent mapping changes since most MNs only rarely move more than 1000 km.
などマルチホーミングを必要とする非モバイルネットワークの最大数は、〜千万である可能性が高いので、100億のマッピングのほとんどは、モバイルデバイスのためになります。しかし、TTRの移動度はほとんどのMNはまれにしか以上千キロを移動しないため、頻繁なマッピングの変更を必要としません。
[Ivip_EAF] [Ivip_PMTUD] [Ivip_PLF] [Ivip_Constraints] [Ivip_Mobility] [Ivip_DRTM] [Ivip_Glossary]
[Ivip_EAF] [Ivip_PMTUD] [Ivip_PLF] [Ivip_Constraints] [Ivip_Mobility] [Ivip_DRTM] [Ivip_Glossary]
Looked at from the thousand-foot level, Ivip shares the basic design approaches with LISP and a number of other map-and-encap designs based on the Core-Edge Separation. However, the details differ substantially. Ivip's design makes a bold assumption that, with technology advances, one could afford to maintain a real-time distributed global mapping database for all networks and hosts. Ivip proposes that multiple parties collaborate to build a mapping distribution system that pushes all mapping information and updates to local, full-database query servers located in all ISPs within a few seconds. The system has no single point of failure and uses end-to-end authentication.
千フィートのレベルから見て、Ivip株式基本設計は、LISPとコア・エッジ分離に基づいて、他のマップと-ENCAPデザインの数に近づきます。しかし、詳細は大きく異なります。 Ivipのデザインは、技術の進歩で、1は、すべてのネットワークとホストのためのグローバルマッピングデータベース分散リアルタイム性を維持する余裕ができ、大胆な仮定を作ります。 Ivipは、複数の当事者が、数秒以内にすべてのISPにあるローカル、フルデータベースのクエリ・サーバへのすべてのマッピング情報と更新をプッシュマッピング配信システムを構築するために協力することを提案しています。システムは、故障の単一点を持たず、エンド・ツー・エンドの認証を使用します。
A "real time, globally synchronized mapping database" is a critical assumption in Ivip. Using that as a foundation, Ivip design avoids several challenging design issues that others have studied extensively, that include
「リアルタイム、グローバル同期マッピングデータベースは、」Ivipの重要な仮定です。基礎として、Ivipの設計には、他の人が広く研究されているいくつかの挑戦的な設計上の問題を回避することを使用します
1. special considerations of mobility support that add additional complexity to the overall system;
全体的なシステムに追加の複雑さを加えるモビリティサポートの1.特別な考慮事項。
2. prompt detection of ETR failures and notification to all relevant ITRs, which turns out to be a rather difficult problem; and
かなり難しい問題であることが判明し、関連するすべてのITR 2.プロンプトETR障害の検出および通知、。そして
3. development of a partial-mapping lookup sub-system. Ivip assumes the existence of local query servers with a full database with the latest mapping information changes.
パーシャル・マッピング・ルックアップ・サブシステムの3開発。 Ivipは、最新のマッピング情報の変更との完全なデータベースとローカルクエリサーバーの存在を前提としています。
To be considered as a viable solution to the Internet routing scalability problem, Ivip faces two fundamental questions. First, whether a global-scale system can achieve real-time synchronized operations as assumed by Ivip is an entirely open question. Past experiences suggest otherwise.
インターネットルーティングスケーラビリティの問題に対する実行可能な解決策として考えられるために、Ivipは、2つの基本的な疑問に直面しています。まず、Ivipによって仮定として、地球規模のシステムは、リアルタイム同期操作を実現することができるかどうか、完全にオープンな質問です。過去の経験は、それ以外の場合は示唆しています。
The second question concerns incremental rollout. Ivip represents an ambitious approach, with real-time mapping and local full-database query servers -- which many people regard as impossible. Developing and implementing Ivip may take a fair amount of resources, yet there is an open question regarding how to quantify the gains by first movers -- both those who will provide the Ivip infrastructure and those that will use it. Significant global routing table reduction only happens when a large enough number of parties have adopted Ivip. The same question arises for most other proposals as well.
2番目の質問は、増分展開に関するものです。 Ivipは、リアルタイムのマッピングおよびローカルフルデータベースのクエリ・サーバで、野心的なアプローチを表し - 多くの人が不可能と考えています。開発とIvipを実装すると、リソースのかなりの量を取る、まだ最初の発動機によって利益を定量化する方法については未解決の問題があること - の両方Ivipのインフラストラクチャを提供します人々とそれを使用しますもの。関係者の十分な大きさの数がIvipを採用している際に重要なグローバルルーティングテーブルの減少にのみ発生します。同じ質問は、同様に他のほとんどの提案のために生じます。
One belief is that Ivip's more ambitious mapping system makes a good design tradeoff for the greater benefits for end-user networks and for those that develop the infrastructure. Another belief is that this ambitious design is not viable.
一つの信念はIvipのより野心的なマッピングシステムは、エンドユーザのネットワークのためのより大きな利益のために、インフラを開発するもののために良いデザインのトレードオフになるということです。もう一つの信念は、この野心的なデザインが実行可能でないということです。
Since the Summary and Critique were written, Ivip's mapping system has been significantly redesigned: DRTM - Distributed Real Time Mapping [Ivip_DRTM].
要約と批判が書かれていたので、Ivipのマッピングシステムが大幅に再設計されました：DRTM - 分散リアルタイムマッピング[Ivip_DRTM]。
DRTM makes it easier for ISPs to install their own ITRs. It also facilitates Mapped Address Block (MAB) operating companies -- which need not be ISPs -- leasing Scalable Provider-Independent (SPI) address space to end-user networks with almost no ISP involvement. ISPs need not install ITRs or ETRs. For an ISP to support its customers using SPI space, they need only allow the forwarding of outgoing packets whose source addresses are from SPI space. End-user networks can implement their own ETRs on their existing PA address(es) -- and MAB operating companies make all the initial investments.
DRTMは、ISPは、自分のITRのをインストールすることが容易になります。ほとんどのISP関与してネットワークエンドユーザーのためのスケーラブルなプロバイダに依存しない（SPI）のアドレス空間をリース - のISPである必要はない - それはまた、マップされたアドレスブロック（MAB）の事業会社を容易にします。 ISPは、ITRのかETRSをインストールする必要はありません。 ISPは、SPIのスペースを使用して、顧客をサポートするために、彼らは唯一のソースアドレスSPI空間からある発信パケットの転送を許可する必要が。エンドユーザネットワークは、既存のPAアドレス（複数可）に、自分のETRSを実装することができます - とMABの事業会社は、すべての初期投資を行います。
Once SPI adoption becomes widespread, ISPs will be motivated to install their own ITRs to locally tunnel packets that are sent from customer networks and that must be tunneled to SPI-using customers of the same ISP -- rather than letting these packets exit the ISP's network and return in tunnels to ETRs in the network.
むしろ、これらのパケットは、ISPのネットワークを終了させるよりも - SPIの採用が普及したら、ISPが顧客のネットワークから送信され、それが同じISPのSPI-使用している顧客にトンネリングする必要があり、ローカルトンネルパケットに自分自身のITRをインストールするにやる気になりますそして、ネットワーク内のETRSにトンネル内に戻ります。
There is no need for full-database query servers in ISPs or for any device that stores the full mapping information for all Mapped Address Blocks (MABs). ISPs that want ITRs will install two or more Map Resolver (MR) servers. These are caching query servers which query multiple (typically nearby) query servers that are full-database for the subset of MABs they serve. These "nearby" query servers will be at DITR sites, which will be run by, or for, MAB operating companies who lease MAB space to large numbers of end-user networks. These DITR-site servers will usually be close enough to the MRs to generate replies with sufficiently low delay and risk of packet loss for ITRs to buffer initial packets for a few tens of milliseconds while the mapping arrives.
ISPでのフルデータベースのクエリ・サーバまたはすべてのマップされたアドレスブロック（のMAB）の完全なマッピング情報を保存する任意のデバイスのための必要はありません。 ITRのが欲しいのISPは、二つ以上の地図リゾルバ（MR）サーバーをインストールします。これらは、クエリを複数、彼らが奉仕のMABのサブセットのフルデータベースです（通常は近隣）、クエリ・サーバのクエリ・サーバをキャッシュしています。これらの「近く」のクエリ・サーバは、またはエンドユーザーのネットワークの多数にMABスペースをリースMAB事業会社、ためで実行されますDITRサイト、になります。これらのDITRサイトのサーバーは、通常、マッピングが到着している間のITRは、数十ミリ秒の初期パケットをバッファリングするために十分な低遅延やパケットロスのリスクとの回答を生成するのMRに十分に近くなります。
DRTM will scale to billions of micronets, tens of thousands of MABs, and potentially hundreds of MAB operating companies, without single points of failure or central coordination.
DRTMがmicronets数十億に拡大し、潜在的mAbの何千人も、障害または中央コーディネーションの単一ポイントなしMAB事業会社の数百、数十。
The critique implies a threshold of adoption is required before significant routing scaling benefits occur. This is untrue of any Core-Edge Separation proposal, including LISP and Ivip. Both can achieve scalable routing benefits in direct proportion to their level of adoption by providing portability, multihoming, and inbound TE to large numbers of end-user networks.
批判は、重大なルーティングのスケーリングメリットが発生する前に養子縁組のしきい値が必要とされる意味します。これは、LISPとIvipを含む任意のコア - エッジ分離案の真実ではありません。どちらも、エンドユーザーのネットワークの多数への移植、マルチホーミング、およびインバウンドTEを提供することにより、養子縁組のレベルに直接比例してスケーラブルなルーティングの利益を達成することができます。
Core-Edge Elimination (CEE) architectures require all Internet communications to change to IPv6 with a new locator/identifier separation naming model. This would impose burdens of extra management effort, packets, and session establishment delays on all hosts -- which is a particularly unacceptable burden on battery-operated mobile hosts that rely on wireless links.
コアエッジ撤廃（CEE）アーキテクチャは、新たなロケータ/識別子分離の命名モデルとIPv6へ変更するために、すべてのインターネット通信を必要とします。無線リンクに依存しているバッテリ動作のモバイルホスト上で特に許容できない負担となっている - これは、すべてのホスト上の余分な経営努力、パケット、およびセッション確立遅延の負担を課します。
Core-Edge Separation architectures retain the current, efficient, naming model, require no changes to hosts, and support both IPv4 and IPv6. Ivip is the most promising architecture for future development because its scalable, distributed, real-time mapping system best supports TTR mobility, enables ITRs to be simpler, and gives real-time control of ITR tunneling to the end-user network or to organizations they appoint to control the mapping of their micronets.
コアエッジ分離アーキテクチャは、現在、効率的、命名モデルを保持するホストへの変更を必要とせず、IPv4とIPv6の両方をサポートします。そのスケーラブルな分散、リアルタイムマッピングシステムは、最高の、TTRモビリティをサポートするシンプルなことのITRを可能にし、エンドユーザのネットワークまたは組織にITRトンネリングのリアルタイム制御を与えるのでIvipは、将来の発展のために最も有望なアーキテクチャであり、彼らそのmicronetsのマッピングを制御するために任命します。
The Hierarchical IPv4 Framework (hIPv4) adds scalability to the routing architecture by introducing additional hierarchy in the IPv4 address space. The IPv4 addressing scheme is divided into two parts, the Area Locator (ALOC) address space, which is globally unique, and the Endpoint Locator (ELOC) address space, which is only regionally unique. The ALOC and ELOC prefixes are added as a shim header between the IP header and transport protocol header; the shim header is identified with a new protocol number in the IP header. Instead of creating a tunneling (i.e., overlay) solution, a new routing element is needed in the service provider's routing domain (called ALOC realm) -- a Locator Swap Router. The current IPv4 forwarding plane remains intact, and no new routing protocols, mapping systems, or caching solutions are required. The control plane of the ALOC realm routers needs some modification in order for ICMP to be compatible with the hIPv4 framework. When an area (one or several autonomous systems (ASes)) of an ISP has transformed into an ALOC realm, only ALOC prefixes are exchanged with other ALOC realms. Directly attached ELOC prefixes are only inserted to the RIB of the local ALOC realm; ELOC prefixes are not distributed to the DFZ. Multihoming can be achieved in two ways, either the enterprise requests an ALOC prefix from the RIR (this is not recommended) or the enterprise receives the ALOC prefixes from their upstream ISPs. ELOC prefixes are PI addresses and remain intact when an upstream ISP is changed; only the ALOC prefix is replaced. When the RIB of the DFZ is compressed (containing only ALOC prefixes), ingress routers will no longer know the availability of the destination prefix; thus, the endpoints must take more responsibility for their sessions. This can be achieved by using multipath enabled transport protocols, such as SCTP [RFC4960] and Multipath TCP (MPTCP) [MPTCP_Arch], at the endpoints. The multipath transport protocols also provide a session identifier, i.e., verification tag or token; thus, the location and identifier split is carried out -- site mobility, endpoint mobility, and mobile site mobility are achieved. DNS needs to be upgraded: in order to resolve the location of an endpoint, the endpoint must have one ELOC value (current A-record) and at least one ALOC value in DNS (in multihoming solutions there will be several ALOC values for an endpoint).
階層IPv4のフレームワーク（hIPv4）はIPv4アドレス空間に追加の階層を導入することにより、ルーティングアーキテクチャへの拡張性を追加します。 IPv4のアドレス指定スキームは、2つの部分、グローバルに一意であるエリアロケータ（ALOC）アドレス空間、およびのみ地域固有であるエンドポイントロケータ（ELOC）アドレス空間に分割されます。 ALOCとELOCプレフィックスは、IPヘッダとトランスポートプロトコルヘッダとの間のシムヘッダとして付加されています。シムヘッダは、IPヘッダ内の新しいプロトコル番号で識別されます。代わりにトンネルを作成する（すなわち、オーバーレイ）ソリューション、新しいルーティング要素は（ALOC領域と呼ばれる）サービスプロバイダのルーティングドメインで必要とされる - ロケータスワップルータ。現在のIPv4転送プレーンは無傷のままで、そして新しいルーティングプロトコル、マッピングシステム、またはキャッシングソリューションが必要とされません。 ALOCレルムルータの制御プレーンは、ICMPはhIPv4フレームワークと互換性があるようにするためにいくつかの変更を必要とします。 ISPの領域（1つまたはいくつかの自律システム（のAS））がALOC領域に変換した場合、唯一ALOC接頭辞は他のALOCレルムと交換されます。直接結合ELOCプレフィックスは、ローカルALOCレルムのRIBに挿入されています。 ELOC接頭辞はDFZに配布されていません。マルチホーミングは、2つの方法で達成することができ、いずれかの企業は、RIRからALOCプレフィックスを要求する（これは推奨されない）、または企業は、それらの上流のISPからALOCプレフィックスを受信します。 ELOCプレフィックスは、PIアドレスであり、上流のISPが変更されたときにそのまま残ります。のみALOC接頭辞が交換されます。 DFZのRIBは（のみALOCプレフィックスを含む）圧縮されると、侵入ルータは、もはや宛先プレフィクスの利用可能性を知っているんだろう。このように、エンドポイントは、そのセッションのためのより多くの責任を取る必要があります。これは、エンドポイントで、そのようなSCTP [RFC4960]及びマルチTCP（MPTCP）MPTCP_Arch]としてマルチ有効トランスポートプロトコルを使用することによって達成することができます。マルチトランスポートプロトコルは、セッション識別子、即ち、検証タグまたはトークンを提供します。このように、場所や識別子の分割が行われる - サイトモビリティ、エンドポイントのモビリティ、およびモバイルサイトの移動度が達成されます。 DNSをアップグレードする必要があります。エンドポイントの場所を解決するために、エンドポイントが1つのELOC値（現在のAレコード）DNS内の少なくとも1つのALOC値を持っている必要があります（マルチホーミングソリューションで、エンドポイントのためのいくつかのALOC値が存在します）。
1. Improved routing scalability: Adding additional hierarchy to the address space enables more hierarchy in the routing architecture. Early adapters of an ALOC realm will no longer carry the current RIB of the DFZ -- only ELOC prefixes of their directly attached networks and ALOC prefixes from other service providers that have migrated are installed in the ALOC realm's RIB.
1.改善ルーティング・スケーラビリティ：アドレス空間に追加の階層を追加し、ルーティングアーキテクチャにおける複数の階層を可能にします。 ALOC分野の早期アダプタはもはやDFZの現在のRIBを運ぶません - ALOCレルムのRIBにインストールされている移行した他のサービスプロバイダからの直接接続されているネットワークとALOCプレフィックスの唯一ELOCプレフィックス。
2. Scalable support for traffic engineering: Multipath enabled transport protocols are recommended to achieve dynamic load-balancing of a session. Support for Valiant Load-balancing (VLB) [Valiant] schemes has been added to the framework; more research work is required around VLB switching.
トラフィックエンジニアリング2.スケーラブルなサポート：マルチパスは、トランスポートプロトコルを有効には、セッションの動的な負荷分散を実現するために推奨されています。ヴァリアントロードバランシング（VLB）ヴァリアント]スキームのサポートがフレームワークに追加されました。より多くの研究活動は、VLBの切り替えの周りに必要です。
3. Scalable support for multihoming: Only attachment points of a multihomed site are advertised (using the ALOC prefix) in the DFZ. DNS will inform the requester on how many attachment points the destination endpoint has. It is the initiating endpoint's choice/responsibility to choose which attachment point is used for the session; endpoints using multipath-enabled transport protocols can make use of several attachment points for a session.
マルチホーミング3.スケーラブルなサポート：マルチホームサイトの唯一の接続点はDFZ中（ALOCの接頭辞を使用して）宣伝されています。 DNSは、宛先エンドポイントが持っているどのように多くのアタッチメントポイントに依頼者に通知します。セッションのために使用される接続ポイントを選択するには、開始エンドポイントの選択/責任です。マルチパス対応のトランスポートプロトコルを使用して、エンドポイントは、セッションのためのいくつかの付着点を利用することができます。
4. Simplified Renumbering: When changing provider, the local ELOC prefixes remains intact; only the ALOC prefix is changed at the endpoints. The ALOC prefix is not used for routing or forwarding decisions in the local network.
4.簡体リナンバリング：プロバイダを変更する場合は、ローカルELOCプレフィックスがそのまま残ります。のみALOC接頭辞は、エンドポイントで変更されました。 ALOCプレフィックスは、ローカルネットワーク内のルーティングまたは転送を決定するために使用されていません。
5. Decoupling Location and Identifier: The verification tag (SCTP) and token (MPTCP) can be considered to have the characteristics of a session identifier, and thus a session layer is created between the transport and application layers in the TCP/IP model.
前記デカップリング場所識別子：検証タグ（SCTP）とトークン（MPTCP）は、セッション識別子の特性を有すると考えることができるので、セッション層は、TCP / IPモデルにおけるトランスポートおよびアプリケーション層の間に作成されます。
6. Routing quality: The hIPv4 framework introduces no tunneling or caching mechanisms. Only a swap of the content in the IPv4 header and locator header at the destination ALOC realm is required; thus, current routing and forwarding algorithms are preserved as such. Valiant Load-balancing might be used as a new forwarding mechanism.
6.ルーティング品質：hIPv4フレームワークには、トンネリングまたはキャッシング・メカニズムを導入しません。先ALOCレルムでIPv4ヘッダとロケータヘッダのコンテンツの交換が必要とされるのみ。従って、現在のルーティングおよび転送アルゴリズムは、として保存されています。ヴァリアントロードバランシングは、新しい転送メカニズムとして使用される可能性があります。
7. Routing Security: Similar as with today's DFZ, except that ELOC prefixes cannot be hijacked (by injecting a longest match prefix) outside an ALOC realm.
7.ルーティングセキュリティ：今日のDFZと同様の、ELOCプレフィックスがALOC領域外（最長一致プレフィックスを注入することによって）ハイジャックすることができない点が異なります。
8. Deployability: The hIPv4 framework is an evolution of the current IPv4 framework and is backwards compatible with the current IPv4 framework. Sessions in a local network and inside an ALOC realm might in the future still use the current IPv4 framework.
8.展開性：hIPv4フレームワークは、現在のIPv4フレームワークの進化であり、現在のIPv4フレームワークとの下位互換性があります。ローカルネットワーク内及びALOC領域内のセッションが将来的には、まだ現在のIPv4のフレームワークを使用する場合があります。
1. Upgrade of the stack at an endpoint that is establishing sessions outside the local ALOC realm.
ローカルALOC領域外のセッションを確立しているエンドポイントのスタックの1アップグレード。
2. In a multihoming solution, the border routers should be able to apply policy-based routing upon the ALOC value in the locator header.
マルチホーミング溶液2.、境界ルータはロケータヘッダーにALOC値にポリシーベースのルーティングを適用することができなければなりません。
4. There is a short timeframe before the expected depletion of the IPv4 address space occurs.
IPv4アドレス空間の予想枯渇が発生する前に4.短期間があります。
5. Will enterprises give up their current globally unique IPv4 address block allocation they have gained?
5.企業は、彼らが得た彼らの現在のグローバルにユニークなIPv4アドレスブロックの割り当てをあきらめるだろうか？
[hIPv4] [Valiant]
[hIPv4] [ヴァリアント]
hIPv4 is an innovative approach to expanding the IPv4 addressing system in order to resolve the scalable routing problem. This critique does not attempt a full assessment of hIPv4's architecture and mechanisms. The only question addressed here is whether hIPv4 should be chosen for IETF development in preference to, or together with, the only two proposals which appear to be practical solutions for IPv4: Ivip and LISP.
hIPv4は、スケーラブルなルーティングの問題を解決するためにはIPv4アドレス指定のシステムを拡張する革新的なアプローチです。この批判はhIPv4のアーキテクチャとメカニズムの完全な評価をしようとしません。唯一の問題は、ここで扱わhIPv4、または一緒にIPv4のための実用的な解決策のように見える2つのだけの提案、とに優先してIETF開発のために選択されるべきであるかどうかです：IvipとLISP。
Ivip and LISP appear to have a major advantage over hIPv4 in terms of support for packets sent from non-upgraded hosts/networks. Ivip's DITRs (Default ITRs in the DFZ) and LISP's PTRs (Proxy Tunnel Routers) both accept packets sent by any non-upgraded host/network and tunnel them to the correct ETR -- thus providing the full benefits of portability, multihoming, and inbound TE for these packets as well as those sent by hosts in networks with ITRs. hIPv4 appears to have no such mechanism, so these benefits are only available for communications between two upgraded hosts in upgraded networks.
IvipとLISPは、アップグレードされていないホスト/ネットワークから送信されるパケットのサポートの面でhIPv4を超える大きな利点を持っているように見えます。 IvipのDITRs（DFZでデフォルトのITR）とLISPのPTRS（プロキシトンネルルータ）は、任意のアップグレードされていないホスト/ネットワークと正しいETRへのトンネルにそれらを送信したパケットを受け入れるの両方 - これポータビリティ、マルチホーミング、およびインバウンドの完全な利点を提供しますこれらのパケットだけでなく、ITRを持つネットワーク内のホストによって送信されたもののためにTE。 hIPv4にはそのような仕組みを持っていないように思われるので、これらの利点は、アップグレードされたネットワーク内の2つのアップグレードホスト間の通信のためにのみ利用可能です。
This means that significant benefits for adopters -- the ability to rely on the new system to provide the portability, multihoming, and inbound TE benefits for all, or almost all, their communications -- will only arise after all, or almost all, networks upgrade their networks, hosts, and addressing arrangements. hIPv4's relationship between adoption levels and benefits to any adopter therefore are far less favorable to widespread adoption than those of Core-Edge Separation (CES) architectures such as Ivip and LISP.
移植性を提供するために、新しいシステムに依存する機能、マルチホーミング、およびインバウンドTEの利益のためにすべて、またはほとんどすべて、彼らのコミュニケーション - - のみすべての後に発生します、またはほぼすべて、ネットワークこれは採用のための重要な利益があることを意味します彼らのネットワーク、ホスト、およびアドレッシング手配をアップグレードします。任意の採用に採用水準と利益の間hIPv4の関係は、したがって、これまでコア・エッジ分離などIvipやLISPなど（CES）のアーキテクチャのものより広く採用にあまり有利です。
This results in hIPv4 also being at a disadvantage regarding the achievement of significant routing scaling benefits, which likewise will only result once adoption is close to ubiquitous. Ivip and LISP can provide routing scaling benefits in direct proportion to their level of adoption, since all adopters gain full benefits for all their communications, in a highly scalable manner.
これはhIPv4も採用がユビキタスに近い後も同様にのみ発生します重要なルーティングスケーリングメリットの達成に関して不利な立場にあることになります。すべての採用は、すべての通信のための完全な利点を得るため、IvipとLISPは、高度にスケーラブルな方法で、養子縁組のレベルに正比例してルーティングスケールメリットを提供することができます。
hIPv4 requires stack upgrades, which are not required by any CES architecture. Furthermore, a large number of existing IPv4 application protocols convey IP addresses between hosts in a manner that will not work with hIPv4: "There are several applications that are inserting IP address information in the payload of a packet. Some applications use the IP address information to create new sessions or for identification purposes. This section is trying to list the applications that need to be enhanced; however, this is by no means a comprehensive list" [hIPv4].
hIPv4は、任意のCESアーキテクチャによって必要とされていないスタックのアップグレードが必要です。さらに、既存のIPv4アプリケーションプロトコルの多くはhIPv4では動作しませんようにしホスト間でIPアドレスを伝える：「パケットのペイロードにIPアドレス情報を挿入しているいくつかのアプリケーションがありますが、一部のアプリケーションは、IPアドレス情報を使用しています。新しいセッションを作成するか、識別目的のためにこのセクションでは、強化する必要があるアプリケーションの一覧を表示しようとしているとしたが、これは決して包括的なリスト」[hIPv4]を意味することによってではありません。
If even a few widely used applications would need to be rewritten to operate successfully with hIPv4, then this would be such a disincentive to adoption to rule out hIPv4 ever being adopted widely enough to solve the routing scaling problem, especially since CES architectures fully support all existing protocols, without the need for altering host stacks.
さらにいくつかの広く使われているアプリケーションがhIPv4で正常に動作するように書き直すことが必要となる場合、これはCESのアーキテクチャは完全にすべてをサポートし、特に以来、これまでのルーティングのスケーリングの問題を解決するために広く十分に採用されてhIPv4を排除するために採用するなどの阻害要因になりますホストスタックを変更することを必要とせずに既存のプロトコル、。
It appears that hIPv4 involves major practical difficulties, which mean that in its current form it is not suitable for IETF development.
hIPv4は現在の形で、それはIETFの開発に適していないという意味では、主要な実用的な困難を伴うことが表示されます。
No rebuttal was submitted for this proposal.
いかなる反論は、この提案のために提出されませんでした。
The basic idea is to add a name overlay (NOL) onto the existing TCP/IP stack.
基本的な考え方は、既存のTCP / IPスタックに名前オーバーレイ（NOL）を追加することです。
Its functions include:
その機能は次のとおりです。
1. Managing host name configuration, registration, and authentication;
1.ホスト名の設定、登録、認証を管理します。
2. Initiating and managing transport connection channels (i.e., TCP/IP connections) by name;
2.名前によって（すなわち、TCP / IP接続）トランスポート接続チャネルを開始し、管理します。
At the edge network, we introduce a new type of gateway, a Name Transfer Relay (NTR), which blocks the PI addresses of edge networks into upstream transit networks. NTRs perform address and/or port translation between blocked PI addresses and globally routable addresses, which seem like today's widely used NAT / Network Address Port Translation (NAPT) devices. Both legacy and NOL applications behind a NTR can access the outside as usual. To access the hosts behind a NTR from outside, we need to use NOL to traverse the NTR by name and initiate connections to the hosts behind it.
エッジネットワークでは、我々は、ゲートウェイの新しい種類、名前転送リレー（NTR）、上流のトランジットネットワークへのエッジネットワークのブロックPIアドレスを導入します。 NTRSは今日広く使われているNAT /ネットワークアドレスポート変換（NAPT）デバイスのように見えるブロックされたPIアドレスとグローバルにルーティング可能なアドレスの間のアドレスおよび/またはポート変換を行います。 NTRの後ろの両方レガシーとNOLのアプリケーションは、いつものように外部にアクセスすることができます。外部からNTRの背後にあるホストにアクセスするために、我々は名前でNTRを横断するNOLを使用する必要があるとその背後にあるホストへの接続を開始します。
Different from proposed host-based ID/locator split solutions, such as HIP, Shim6, and name-oriented stack, NOL doesn't need to change the existing TCP/IP stack, sockets, or their packet formats. NOL can coexist with the legacy infrastructure, and the Core-Edge Separation solutions (e.g., APT, LISP, Six/One, Ivip, etc.).
このようHIP、SHIM6、名前志向のスタックとして提案されているホストベースのID /ロケータ分離ソリューションと異なり、NOLは、既存のTCP / IPスタック、ソケット、またはそのパケットのフォーマットを変更する必要はありません。 NOLは、レガシーインフラストラクチャと共存、およびコア・エッジ分離溶液（例えば、APT、LISP、シックス/つ、Ivip、等）ことができます。
1. Reduce routing table size: Prevent edge network PI address from leaking into the transit network by deploying gateway NTRs.
1.ルーティングテーブルのサイズを削減：ゲートウェイNTRSを展開することによりトランジットネットワークに漏れるエッジネットワークPIアドレスを防ぎます。
2. Traffic Engineering: For legacy and NOL application sessions, the incoming traffic can be directed to a specific NTR by DNS. In addition, for NOL applications, initial sessions can be redirected from one NTR to other appropriate NTRs. These mechanisms provide some support for traffic engineering.
2.トラフィックエンジニアリングは：レガシーとNOLアプリケーションセッションでは、着信トラフィックは、DNSによって、特定のNTRに向けることができます。また、NOLのアプリケーションのために、最初のセッションは、他の適切なNTRSに1 NTRからリダイレクトすることができます。これらのメカニズムは、トラフィックエンジニアリングのためのいくつかのサポートを提供します。
3. Multihoming: When a PI addressed network connects to the Internet by multihoming with several providers, it can deploy NTRs to prevent the PI addresses from leaking into provider networks.
3.マルチホーミング：PIは、ネットワークが複数のプロバイダとのマルチホーミングでインターネットに接続し、それがプロバイダーネットワークに漏れるPIアドレスを防ぐためにNTRSを展開することができ取り組みます。
4. Transparency: NTRs can be allocated PA addresses from the upstream providers and store them in NTRs' address pool. By DNS query or NOL session, any session that wants to access the hosts behind the NTR can be delegated to a specific PA address in the NTR address pool.
4.透明性：NTRSは、上流プロバイダからPAアドレスを割り当てられ、NTRS'アドレスプールに保存することができます。 DNSクエリまたはNOLのセッションでは、NTRの背後にあるホストにアクセスすることを望んでいるすべてのセッションがNTRアドレスプール内の特定のPAアドレスに委任することができます。
5. Mobility: The NOL layer manages the traditional TCP/IP transport connections, and provides application data transport continuity by checkpointing the transport connection at sequence number boundaries.
5.モビリティ：NOL層は、従来のTCP / IPトランスポート接続を管理し、シーケンス番号の境界でトランスポート接続をチェックポイントすることにより、アプリケーションのデータ転送継続性を提供します。
10. NOL can be compatible with existing solutions, such as APT, LISP, Ivip, etc.
10. NOLは等APT、LISP、Ivip、などの既存のソリューションとの互換性であることができます
11. End-user-controlled multipath indirect routing based on distributed NTRs. This will give benefits to the performance-aware applications, such as video streaming, applications on MSN.com, etc.
分散NTRSに基づいて11エンドユーザ制御のマルチパスルーティング間接。これは、などのビデオ・ストリーミング、MSN.com上のアプリケーション、などのパフォーマンスを意識したアプリケーションに恩恵を与えます
1. Legacy applications have trouble with initiating access to the servers behind NTR. Such trouble can be resolved by deploying the NOL proxy for legacy hosts, or delegating globally routable PA addresses in the NTR address pool for these servers, or deploying a proxy server outside the NTR.
1.レガシーアプリケーションはNTRの背後にあるサーバへのアクセスを開始するとのトラブルを持っています。このようなトラブルは、従来のホストに対してNOLプロキシを展開、またはこれらのサーバー用NTRアドレスプールでグローバルにルーティング可能なPAアドレスを委任、またはNTR外にプロキシサーバーを展開することによって解決することができます。
2. NOL may increase the number of entries in DNS, but it is not drastic because it only increases the number of DNS records at domain granularity not the number of hosts. The name used in NOL, for example, is similar to an email address hostname@example.net. The needed DNS entries and query are just for "example.net", and the NTR knows the "hostnames". Not only will the number of DNS records be increased, but the dynamics of DNS might be agitated as well. However, the scalability and performance of DNS are guaranteed by its naming hierarchy and caching mechanisms.
2. NOLは、DNS内のエントリの数を増加させることができるが、それは唯一のドメイン細分しないホストの数でDNSレコードの数を増加させるので、それは劇的ではありません。 NOLに使用される名前は、例えば、電子メールアドレスhostname@example.netに似ています。必要なDNSエントリおよびクエリは、単に「example.net」としており、NTRは、「ホスト名」を知っています。だけでなく、DNSレコードの数が増加しますが、DNSのダイナミクスは、同様に攪拌することがあります。しかし、DNSのスケーラビリティとパフォーマンスは、その名前階層とキャッシングのメカニズムによって保証されています。
No references were submitted.
いかなる参照が提出されませんでした。
1. Applications on hosts need to be rebuilt based on a name overlay library to be NOL-enabled. The legacy software that is not maintained will not be able to benefit from NOL in the Core-Edge Elimination situation. In the Core-Edge Separation scheme, a new gateway NTR is deployed to prevent edge-specific PI prefixes from leaking into the transit core. NOL doesn't impede the legacy endpoints behind the NTR from accessing the outside Internet, but the legacy endpoints cannot access or will have difficultly accessing the endpoints behind a NTR without the help of NOL.
ホスト上の1.アプリケーションは、NOL-有効であることを名前オーバーレイライブラリに基づいて再構築する必要があります。維持されていないレガシーソフトウェアは、コア・エッジ排除の状況にNOLの恩恵を受けることができなくなります。コアエッジ分離方式では、新たなゲートウェイNTRはトランジットコアに漏れるエッジ固有PIプレフィックスを防止するために配備されます。 NOLは、外部のインターネットにアクセスすることからNTRの後ろのレガシーエンドポイントを妨げないが、従来のエンドポイントはアクセスできないか、困難NOLの助けを借りずにNTRの後ろのエンドポイントにアクセスする必要があります。
2. In the case of Core-Edge Elimination, the end site will be assigned multiple PA address spaces, which leads to renumbering troubles when switching to other upstream providers. Upgrading endpoints to support NOL doesn't give any benefits to edge networks. Endpoints have little incentive to use NOL in a Core-Edge Elimination scenario, and the same is true with other host-based ID/locator split proposals. Whether they are IPv4 or IPv6 networks, edge networks prefer PI address space to PA address space.
2.コア - エッジ排除の場合、エンドサイトは、他の上流のプロバイダに切り替えたときにリナンバリングのトラブルにつながる、複数のPAアドレス空間が割り当てられます。 NOLをサポートするために、エンドポイントをアップグレードすると、エッジネットワークへの恩恵を与えるものではありません。エンドポイントは、コア - エッジ排除シナリオでNOLを使用するためのインセンティブを持っている、と同じことが他のホストベースのID /ロケータ分離の提案と同様です。彼らはIPv4またはIPv6ネットワークであるかどうか、エッジネットワークは、PAアドレス空間にPIアドレス空間を好みます。
3. In the Core-Edge Separation scenario, the additional gateway NTR is to prevent the specific prefixes from the edge networks, just like a NAT or the ITR/ETR of LISP. A NTR gateway can be seen as an extension of NAT (Network Address Translation). Although NATs are deployed widely, upgrading them to support NOL extension or deploying additional new gateway NTRs at the edge networks is on a voluntary basis and has few economic incentives.
コアエッジ分離シナリオ3.、追加のゲートウェイNTRはちょうどLISPのNATまたはITR / ETRように、エッジネットワークから特定のプレフィクスを防止することです。 NTRゲートウェイはNAT（ネットワークアドレス変換）の拡張とみなすことができます。 NATのが広く展開されていますが、NOL拡張をサポートするためにそれらをアップグレードするか、エッジネットワークに追加の新しいゲートウェイNTRSを展開して自主的にあり、いくつかの経済的インセンティブを持っています。
4. The stateful or stateless translation for each packet traversing a NTR will require the cost of the CPU and memory of NTRs, and increase forwarding delay. Thus, it is not appropriate to deploy NTRs at the high-level transit networks where aggregated traffic may cause congestion at the NTRs.
4. NTRを通過する各パケットのステートフルまたはステートレスの翻訳はNTRSのCPUとメモリのコストを必要とし、転送遅延が増加します。したがって、集約トラフィックNTRSで輻輳を引き起こす可能性がハイレベルの中継ネットワークでNTRSを展開することは適切ではありません。
5. In the Core-Edge Separation scenario, the requirement for multihoming and inter-domain traffic engineering will make end sites accessible via multiple different NTRs. For reliability, all of the associations between multiple NTRs and the end site name will be kept in DNS, which may increase the load on DNS.
コア - エッジ分離シナリオでは5、マルチホーミングとドメイン間のトラフィックエンジニアリングのための要件は、複数の異なるNTRSを通じてエンドサイトにアクセスできるようになります。信頼性を高めるため、複数のNTRSとエンドサイト名の間の関連付けのすべてがDNSの負荷を増加させる可能性がある、DNSに保持されます。
6. To support mobility, it is necessary for DNS to update the corresponding name-NTR mapping records when an end system moves from behind one NTR to another NTR. The NOL-enabled end relies on the NOL layer to preserve the continuity of the transport layer, since the underlying TCP/UDP transport session would be broken when the IP address changed.
エンド・システムが別のNTR 1つのNTRの後ろから移動するときDNSは、対応する名前-NTRマッピングレコードを更新するためのモビリティをサポートする6、それが必要です。 IPアドレスが変更されたときに、基礎となるTCP / UDPトランスポートセッションが壊れてしまうので、NOL対応の終わりには、トランスポート層の連続性を維持するためにNOL層に依存しています。
NOL resembles neither CEE nor CES as a solution. By supporting application-level sessions through the name overlay layer, NOL can support some solutions in the CEE style. However, NOL is in general closer to CES solutions, i.e., preventing PI prefixes of edge networks from entering into the upstream transit networks. This is done by the NTR, like the ITRs/ETRs in CES solutions, but NOL has no need to define the clear boundary between core and edge networks. NOL is designed to try to provide end users or networks a service that facilitates the adoption of multihoming, multipath routing, and traffic engineering by the indirect routing through NTRs, and that, in the mean time, doesn't accelerate or decelerate the growth of global routing table size.
NOLは、解決策としてどちらCEEもCESに似ています。名前オーバーレイ層を介してアプリケーションレベルのセッションをサポートすることにより、NOLは、CEEのスタイルでいくつかのソリューションをサポートすることができます。しかし、NOLは、近いCES溶液に、一般的に、すなわち、上流のトランジットネットワークに入るのエッジネットワークのPIプレフィックスを防止します。これは、CESのソリューションでのITR / ETRSのように、NTRによって行われますが、NOLは、コアとエッジネットワークの間に明確な境界を定義する必要がありません。 NOLは、エンドユーザーやネットワークにNTRSを通じて間接的なルーティングによってマルチホーミング、マルチパスルーティング、およびトラフィックエンジニアリングの採用を促進するサービスを提供しようとするように設計され、平均時間では、成長を加速または減速しない、ということですグローバルルーティングテーブルのサイズ。
Some problems are described in the NOL critique. In the original NOL proposal document, the DNS query for a host that is behind a NTR will induce the return of the actual IP addresses of the host and the address of the NTR. This arrangement might cause some difficulties for legacy applications due to the non-standard response from DNS. To resolve this problem, we instead have the NOL service use a new namespace, and have DNS not return NTR IP addresses for the legacy hosts. The names used for NOL are formatted like email addresses, such as "des@example.net". The mapping between "example.net" and the IP address of the corresponding NTR will be registered in DNS. The NOL layer will understand the meaning of the name "des@example.net" , and it will send a query to DNS only for "example.net". DNS will then return IP addresses of the corresponding NTRs. Legacy applications will still use the traditional FQDN name, and DNS will return the actual IP address of the host. However, if the host is behind a NTR, the legacy applications may be unable to access the host.
いくつかの問題は、NOLの批判に記述されています。元NOLの提案書では、NTRの後ろにあるホストのDNSクエリは、ホストの実際のIPアドレスの返却とNTRのアドレスを誘発します。この配置は、DNSからの非標準的な応答のためにレガシーアプリケーションのためのいくつかの困難を引き起こす可能性があります。この問題を解決するために、我々は代わりにNOLサービスは新しい名前空間を使用し、レガシーホスト用NTR IPアドレスを返さないDNSを持っています。 NOLのために使用される名前は、「des@example.net」として、電子メールアドレスのようにフォーマットされています。 「example.net」と対応NTRのIPアドレス間のマッピングは、DNSに登録されます。 NOL層は、名前「des@example.net」の意味を理解し、それが唯一の「example.net」のためにDNSにクエリを送信します。 DNSは、対応するNTRSのIPアドレスを返します。レガシーアプリケーションは、まだ伝統的なFQDN名を使用すると、DNSは、ホストの実際のIPアドレスを返します。ホストがNTRの背後にある場合には、レガシーアプリケーションはホストにアクセスできないことがあります。
The stateless address translation or stateful address and port translation may cause a scaling problem with the number of table entries NTR must maintain, and legacy applications cannot initiate sessions with hosts inside the NOL-adopting End User Network (EUN). However, these problems may not be a big barrier for the deployment of NOL or other similar approaches. Many NAT-like boxes, proxy, and firewall devices are widely used at the ingress/egress points of enterprise networks, campus networks, or other stub EUNs. The hosts running as servers can be deployed outside NTRs or can be assigned PA addresses in an NTR-adopting EUN.
ステートレスアドレス変換またはステートフルアドレスとポート変換はNTRは維持しなければならないテーブルエントリ数とスケーリングの問題を引き起こす可能性があり、およびレガシーアプリケーションは、NOL-採用するエンドユーザーのネットワーク（EUN）内部ホストとのセッションを開始することはできません。しかし、これらの問題は、NOLまたは他の同様のアプローチを展開するための大きな障壁ではないかもしれません。多くのNATのようなボックス、プロキシ、およびファイアウォールデバイスは、広く企業ネットワーク、キャンパスネットワーク、または他のスタブEUNsの入口/出口ポイントで使用されています。サーバとして動作しているホストは、外部のNTRSを展開することができるか、NTR-採用EUNにPAアドレスを割り当てることができます。
This proposal (referred to here as "CRM") is to build a highly scalable locator identity mapping system using compact routing principles. This provides the means for dynamic topology adaption to facilitate efficient aggregation [CRM]. Map servers are assigned as cluster heads or landmarks based on their capability to aggregate EID announcements.
（「CRM」とここで呼ばれる）この提案は、コンパクトなルーティング原理を使用して高度にスケーラブルなロケータIDマッピングシステムを構築することです。これは、効率的な集約[CRM]を容易にするための動的トポロジ適応するための手段を提供します。地図サーバは、EIDの発表を集約する能力に基づいて、クラスタヘッドやランドマークとして割り当てられています。
o Minimizes the routing table sizes at the system level (i.e., map servers). Provides clear upper bounds for routing stretch that define the packet delivery delay of the map request / first packet.
Oは、システムレベル（すなわち、地図サーバ）におけるルーティングテーブルのサイズを最小にします。マップ要求/最初のパケットのパケット配信遅延を定義するストレッチをルーティングするための明確な上限を提供します。
o Organizes the mapping system based on the EID numbering space, minimizes the administrative overhead of managing the EID space. No need for administratively planned hierarchical address allocation as the system will find convergence into a set of EID allocations.
oは、EID番号スペースに基づいてマッピングシステムを整理EIDスペースを管理するための管理オーバーヘッドを最小限に抑えることができます。システムとして管理上、計画階層的なアドレス割り当てのための必要はありませんEID割り当てのセットに収束を見つけません。
o Availability and robustness of the overall routing system (including xTRs and map servers) are improved because of the potential to use multiple map servers and direct routes without the involvement of map servers.
O（xTRs及びマップサーバを含む）全体的なルーティングシステムの可用性と堅牢性があるため、マップサーバの関与なしに、複数のマップ・サーバと直接ルートを使用する可能性を向上させることができます。
The scalability gains will materialize only in large deployments. If the stretch is bounded to those of compact routing (worst-case stretch less or equal to 3, on average, 1+epsilon), then each xTR needs to have memory/cache for the mappings of its cluster.
スケーラビリティの向上は、大規模な展開に実体化されます。ストレッチがコンパクトルーティングのものに制限される場合（3最悪の場合のストレッチ以下、平均して、+イプシロン1）は、各XTRは、そのクラスタのマッピングのためのメモリ/キャッシュを持っている必要があります。
[CRM]
[CRM]
The CRM proposal is not a complete proposal and therefore cannot be considered for further development by the IETF as a scalable routing solution.
CRMの提案は、完全な提案ではないので、スケーラブルなルーティングソリューションとしてIETFによって更なる発展のために考慮することはできません。
While Compact Routing principles may be able to improve a mapping overlay structure such as LISP+ALT, there are several objections to this approach.
コンパクトルーティング原理は、LISP + ALTとしてマッピングオーバーレイ構造を改善することができるかもしれないが、このアプローチにはいくつかの異議があります。
Firstly, a CRM-modified ALT structure would still be a global query server system. No matter how ALT's path lengths and delays are optimized, there is a problem with a querier -- which could be anywhere in the world -- relying on mapping information from one or ideally two or more authoritative query servers, which could also be anywhere in the world. The delays and risks of packet loss that are inherent in such a system constitute a fundamental problem. This is especially true when multiple, potentially long, traffic streams are received by ITRs and forwarded over the CRM networks for delivery to the destination network. ITRs must use the CRM infrastructure while they are awaiting a map reply. The traffic forwarded on the CRM infrastructure functions as map requests and can present a scalability and performance issue to the infrastructure.
まず、CRM-修正ALT構造は、まだグローバルクエリ・サーバ・システムになります。どんなにALTのパスの長さや遅延が最適化されているか、クエリアに問題がある - 世界のどこ可能性 - ものどこにでも可能性が一つまたは理想的に二つ以上の権威のクエリ・サーバからのマッピング情報に頼ります世界。このようなシステムに固有の遅延やパケットロスのリスクは根本的な問題となります。複数の、潜在的に長い、トラフィックストリームは、ITRが受信し、宛先ネットワークへの配信のためのCRMネットワーク上で転送されている場合は特にそうです。彼らは、マップの返信を待っている間のITRは、CRMインフラストラクチャを使用する必要があります。トラフィックは、マップ要求としてCRMインフラストラクチャ機能に転送され、インフラへのスケーラビリティとパフォーマンスの問題を提示することができます。
Secondly, the alterations contemplated in this proposal involve the roles of particular nodes in the network being dynamically assigned as part of the network's self-organizing nature.
第二に、この提案で意図の変更は、ネットワーク内の特定のノードの役割を動的にネットワークの自己組織化自然の一部として割り当てられている伴います。
The discussion of clustering in the middle of page 4 of [CRM] also indicates that particular nodes are responsible for registering EIDs from typically far-distant ETRs, all of which are handling closely related EIDs that this node can aggregate. Since MSes are apparently nodes within the compact routing system, and the process of an MS deciding whether to accept EID registrations is determined as part of the self-organizing properties of the system, there are concerns about how EID registration can be performed securely, when no particular physical node is responsible for it.
[CRM]の4ページの中央にクラスタリングの議論は、特定のノードがこのノードが集約できること密接に関連のEIDを処理しているすべてが、典型的には遠遠くETRSからのEIDを登録する責任があることを示しています。 MSが明らかにされているコンパクトなルーティングシステム内のノード、及びEID登録を受け入れるかどうかを決定するMSのプロセスは、システムの自己組織化特性の一部として決定されるので、EID登録が確実に、ときに実行することができる方法についての懸念があります特に物理ノードは、それを担当していません。
Thirdly, there are concerns about individually owned nodes performing work for other organizations. Such problems of trust and of responsibilities and costs being placed on those who do not directly benefit already exist in the inter-domain routing system and are a challenge for any scalable routing solution.
第三に、他の組織のための作業を行う個人所有のノードについての懸念があります。信頼のと責任とコストのこのような問題は、直接、すでに利益を得ていない人は、ドメイン間ルーティングシステム内に存在し、任意のスケーラブルなルーティングソリューションのために挑戦しているの上に置かれています。
There are simpler solutions to the mapping problem than having an elaborate network of routers. If a global-scale query system is still preferred, then it would be better to have ITRs use local MRs, each of which is dynamically configured to know the IP address of the million or so authoritative Map Server (MS) query servers -- or two million or so assuming they exist in pairs for redundancy.
ルータの精巧なネットワークを持つよりもマッピング問題への単純な解決策があります。地球規模のクエリシステムがまだ好まれている場合、ITRは、動的に百万かそこらの権威マップサーバ（MS）のクエリ・サーバのIPアドレスを知っているように構成されてそれぞれの地元のMRを、使用した方が良いでしょう - または200万かそこら、彼らは、冗長性のためにペアで存在すると仮定。
It appears that the inherently greater delays and risks of packet loss of global query server systems make them unsuitable mapping solutions for Core-Edge Elimination or Core-Edge Separation architectures. The solution to these problems appears to involve a greater number of widely distributed authoritative query servers, one or more of which will therefore be close enough to each querier that delays and risk of packet loss are reduced to acceptable levels. Such a structure would be suitable for map requests, but perhaps not for handling traffic packets to be delivered to the destination networks.
本質的により大きな遅延やグローバルクエリ・サーバ・システムのパケット損失のリスクは、それらコア・エッジ消去又はコア・エッジ分離アーキテクチャに適さないマッピングソリューション作ることが表示されます。これらの問題を解決するには、広く分布している権威のクエリ・サーバ、一つ以上のそのため、遅延やパケットロスのリスクが許容レベルにまで低減されている各クエリアに十分に近くなるのより多くを含むと思われます。このような構造は、マップ要求に適しているであろう、おそらくないトラフィックパケットを処理するためには、宛先ネットワークに配信します。
CRM is most easily understood as an alteration to the routing structure of the LISP+ALT mapping overlay system, by altering or adding to the network's BGP control plane.
CRMは、最も容易に変更すること、またはネットワークのBGP制御プレーンに追加することによって、LISP + ALTマッピングオーバーレイシステムのルーティング構造に変化すると理解されます。
CRM's aims include the delivery of initial traffic packets to their destination networks where they also function as map requests. These packet streams may be long and numerous in the fractions of a second to perhaps several seconds that may elapse before the ITR receives the map reply.
CRMの目的は、彼らはまた、マップ・リクエストとして機能する彼らの宛先ネットワークへの最初のトラフィックパケットの送達を含みます。これらのパケットストリームは、ITRは、マップ応答を受信するまでに経過することがあり、おそらく数秒に2番目の画分に長く、数多くのかもしれません。
Compact Routing principles are used to optimize the path length taken by these query or traffic packets through a significantly modified version of the ALT (or similar) network, while also generally reducing typical or maximum paths taken by the query packets.
コンパクトルーティング原理は、一般にクエリパケットによって撮影された典型的な又は最大パスを削減しながら、ALT（または類似の）ネットワークの大幅修正バージョンを介してこれらのクエリまたはトラフィックパケットによって取られる経路長を最適化するために使用されます。
An overlay network is a diversion from the shortest path. However, CMR limits this diversion and provides an upper bound. Landmark routers/servers could deliver more than just the first traffic packet, subject to their CPU capabilities and their network connectivity bandwidths.
オーバレイネットワークは、最短経路から転換です。しかし、CMRは、この転換を制限し、上限を提供します。ランドマークルータ/サーバは、CPUの能力とそれらのネットワーク接続の帯域幅を受け、ちょうど最初のトラフィックパケット以上のものを提供できます。
The trust between the landmarks (mapping servers) can be built based on the current BGP relationships. Registration to the landmark nodes needs to be authenticated mutually between the MS and the system that is registering. This part is not documented in the proposal text.
ランドマーク（マッピングサーバ）との間に信頼関係が現在のBGP関係に基づいて構築することができます。ランドマークノードへの登録は、MSと登録されているシステムとの間に相互に認証する必要があります。この部分は、提案テキストに記載されていません。
The layered mapping system proposal builds a hierarchical mapping system to support scalability, analyzes the design constraints, presents an explicit system structure, designs a two-cache mechanism on ingress tunneling router (ITR) to gain low request delay, and facilitates data validation. Tunneling and mapping are done at the core, and no change is needed on edge networks. The mapping system is run by interest groups independent of any ISP, which conforms to an economical model and can be voluntarily adopted by various networks. Mapping systems can also be constructed stepwise, especially in the IPv6 scenario.
階層化マッピングシステムの提案は、スケーラビリティをサポートするために、階層的なマッピングシステムを構築する設計上の制約を分析し、明示的なシステム構造を提示し、低要求遅延を得るために、入口のトンネルルータ（ITR）上の2つのキャッシュ・メカニズムを設計し、データ検証を容易にします。トンネリングおよびマッピングは、コアで行われ、そして変化は、エッジネットワーク上で必要とされません。マッピングシステムは、経済的なモデルに準拠しており、自発的に様々なネットワークによって採用することができる任意のISPの独立した利益団体によって運営されています。マッピングシステムは、特にIPv6のシナリオでは、段階的に構築することができます。
A. Distributed storage of mapping data avoids central storage of
massive amounts of data and restricts updates within local
areas.
B. The cache mechanism in an ITR reasonably reduces the request loads on the mapping system.
B.は、ITRのキャッシュ機構は、合理的マッピングシステム上の要求の負荷を低減します。
A. No change on edge systems, only tunneling in core routers,
and new devices in core networks.
B. The mapping system can be constructed stepwise: a mapping node needn't be constructed if none of its responsible ELOCs is allocated. This makes sense especially for IPv6.
B.マッピングシステムを段階的に構築することができる。その責任ELOCsのいずれも割り当てられていない場合、マッピング・ノードを構築する必要はありません。これは、特にIPv6の意味があります。
C. Conforms to a viable economic model: the mapping system operators can profit from their services; core routers and edge networks are willing to join the circle either to avoid router upgrades or realize traffic engineering. Benefits from joining are independent of the scheme's implementation scale.
C.は、実行可能な経済モデルに準拠：マッピングシステムの事業者がサービスから利益を得ることができます。コアルータやエッジネットワークは、ルータのアップグレードを回避またはトラフィックエンジニアリングを実現するためにどちらかのサークルに参加して喜んでいます。入社からの利点は、スキームの実装規模とは無関係です。
3. Low request delay: The low number of layers in the mapping structure and the two-stage cache help achieve low request delay.
3.低要求遅延：マッピング構造における層の数が少ないと二段キャッシュ低い要求遅延を達成するのを助けます。
4. Data consistency: The two-stage cache enables an ITR to update data in the map cache conveniently.
4.データの整合性：二段階キャッシュ便利なマップキャッシュ内のデータを更新するITRを可能にします。
5. Traffic engineering support: Edge networks inform the mapping system of their prioritized mappings with all upstream routers, thus giving the edge networks control over their ingress flows.
5.トラフィックエンジニアリングサポート：エッジネットワークは、このように彼らの入口流れの上にエッジネットワーク制御を与え、すべての上流のルータとその優先順位マッピングのマッピングシステムに通知します。
2. The structure of the mapping system needs to be refined according to practical circumstances.
2.マッピングシステムの構造は、実用的な状況に応じて精製される必要があります。
[LMS_Summary] [LMS]
[LMS_Summary] [LMS]
LMS is a mapping mechanism based on Core-Edge Separation. In fact, any proposal that needs a global mapping system with keys with similar properties to that of an "edge address" in a Core-Edge Separation scenario can use such a mechanism. This means that those keys are globally unique (by authorization or just statistically), at the disposal of edge users, and may have several satisfied mappings (with possibly different weights). A proposal to address routing scalability that needs mapping but doesn't specify the mapping mechanism can use LMS to strengthen its infrastructure.
LMSは、コア - エッジ間隔に基づいてマッピングメカニズムです。実際には、コア・エッジ分離シナリオにおける「エッジアドレス」と同様の特性を有するキーを使用してグローバルマッピングシステムを必要とする任意の提案は、このような機構を使用することができます。これは、エッジユーザの処分で、（承認によって、あるいは単に統計的に）これらのキーは、グローバルに一意であることを意味し、（おそらく異なる重みを持つ）いくつかの満足のマッピングを有することができます。マッピングを必要とするが、マッピングメカニズムを指定しないルーティング拡張性に対処するための提案は、その基盤を強化するためにLMSを使用することができます。
The key idea of LMS is similar to that of LISP+ALT: that the mapping system should be hierarchically organized to gain scalability for storage and updates and to achieve quick indexing for lookups. However, LMS advocates an ISP-independent mapping system, and ETRs are not the authorities of mapping data. ETRs or edge-sites report their mapping data to related mapping servers.
LMSの主要なアイデアは、LISP + Altキーと同様である：マッピングシステムは、階層的に保管し、更新のための拡張性を獲得し、検索のための迅速なインデックスを達成するために組織されるべきであること。しかし、LMSは、ISPに依存しないマッピングシステムを提唱し、ETRSは、マッピングデータの当局ではありません。 ETRSまたはエッジサイトでは、関連するマッピングサーバへのマッピングデータを報告しています。
LMS assumes that mapping servers can be incrementally deployed in that a server may not be constructed if none of its administered edge addresses are allocated, and that mapping servers can charge for their services, which provides the economic incentive for their existence. How this brand-new system can be constructed is still not clear. Explicit layering is only an ideal state, and the proposal analyzes the layering limits and feasibility, rather than provide a practical way for deployment.
LMSは、マッピングサーバは、増分その投与エッジアドレスのいずれも割り当てられていない場合は、サーバーが構築されていない可能性という点で展開することができ、かつそのマッピングサーバは、その存在のための経済的インセンティブを提供し、彼らのサービスのために充電することができていることを前提としています。どのようにこのブランドの新システムを構築することができることはまだ明らかではありません。明示的な階層化は、理想的な状態であり、提案は、展開のための実用的な方法を提供するのではなく、積層限界と可能性を分析します。
The drawbacks of LMS's feasibility analysis also include that it 1) is based on current PC power and may not represent future circumstances (especially for IPv6), and 2) does not consider the variability of address utilization. Some IP address spaces may be effectively allocated and used while some may not, causing some mapping servers to be overloaded while others are poorly utilized. More thoughts are needed as to the flexibility of the layer design.
LMSの実現可能性分析の欠点はまた、1）現在のPCのパワーに基づいており）、特にIPv6用（将来の状況を表していないこと、および2）アドレスの使用率の変動を考慮していないことにあります。一部のIPアドレス空間を効果的に他の人が悪い利用されている間、いくつかのマッピングサーバが過負荷になることを引き起こし、割り当てられ、一部はないかもしれませんが使用することができます。より多くの思考は、層設計の柔軟性として必要とされています。
LMS doesn't fit well for mobility. It does not solve the problem when hosts move faster than the mapping updates and propagation between relative mapping servers. On the other hand, mobile hosts' moving across ASes and changing their attachment points (core addresses) is less frequent than hosts' moving within an AS.
LMSは、モビリティのためによく適合しません。ホストが相対的マッピングサーバ間のマッピングの更新と伝播よりも速く移動するとき、それは問題を解決していません。一方、モバイルホストはのASを横切って移動すると、それらの取り付け点（コアアドレス）を変更するホストはより少ない頻度であるAS内を移動します。
Separation needs two planes: Core-Edge Separation (which is to gain routing table scalability) and identity/location separation (which is to achieve mobility). The Global Locator, Local Locator, and Identifier (GLI) scheme does a good clarification of this, and in that case, LMS can be used to provide identity-to-core address mapping. Of course, other schemes may be competent, and LMS can be incorporated with them if the scheme has global keys and needs to map them to other namespaces.
アイデンティティ/（移動度を達成することである）場所分離（ルーティングテーブルのスケーラビリティを得るためにある）コア・エッジの分離：分離は、二つの平面を必要とします。グローバルロケータ、ローカルロケータと識別子（GLI）方式は、この良い明確化を行い、その場合、LMSは、アイデンティティ・ツー・コアアドレスマッピングを提供するために使用することができます。もちろん、他のスキームが有能であってもよく、スキームはグローバルなキーを持っており、他の名前空間にマップする必要がある場合、LMSは、彼らと一緒に配合することができます。
No rebuttal was submitted for this proposal.
いかなる反論は、この提案のために提出されませんでした。
1. A mapping from prefixes to ETRs is an M:M mapping. Any change of a (prefix, ETR) pair should be updated in a timely manner, which can be a heavy burden to any mapping system if the relation changes frequently.
1. ETRSへのプレフィックスのマッピングはMである：Mマッピング。 （接頭辞、ETR）ペアの変更は関係が頻繁に変更された場合、マッピングシステムに大きな負担することができ、タイムリーに更新する必要があります。
2. A prefix<->ETR mapping system cannot be deployed efficiently if it is overwhelmed by worldwide dynamics. Therefore, the mapping itself is not scalable with this direct mapping scheme.
2.接頭語< - >それは、世界中のダイナミクスに圧倒された場合にETRマッピングシステムを効率的に展開することができません。そのため、マッピング自体は、この直接マッピング方式でスケーラブルではありません。
1. Introduce an AS number in the middle of the mapping, the phase I mapping is prefix<->AS#, phase II mapping is AS#<->ETRs. This creates a M:1:M mapping model.
1マッピングの途中でAS番号の導入、相Iマッピングが接頭辞は< - > < - > ETRS＃ように、位相IIマッピングは＃通りです。 1：MマッピングモデルこれはMを作成します。
2. It is fair to assume that all ASes know their local prefixes (in the IGP) better than other ASes and that it is most likely that local prefixes can be aggregated when they can be mapped to the AS number, which will reduce the number of mapping entries. Also, ASes also know clearly their ETRs on the border between core and edge. So, all mapping information can be collected locally.
2.数を減らすことであろう、全てのASが他のASよりも良い（IGP）で、地元のプレフィックスを知っているし、彼らがAS番号にマッピングすることができたときにローカルプレフィックスを集約することができる可能性が最も高いと仮定することが公正ですマッピングエントリの。また、ASのもはっきりコアとエッジの間の境界上でのETRSを知っています。だから、すべてのマッピング情報をローカルに収集することができます。
3. A registry system will take care of the phase I mapping information. Each AS should have a registration agent to notify the registry of the local range of IP address space. This system can be organized as a hierarchical infrastructure like DNS, or alternatively, as a centralized registry like "whois" in each RIR. Phase II mapping information can be distributed between xTRs as a BGP extension.
3.レジストリのシステムは、私が情報をマッピング相の世話をします。各ASは、IPアドレス空間の局所的な範囲のレジストリを通知するための登録エージェントを持っている必要があります。このシステムは、各RIRの「WHOIS」のような集中型レジストリとして、代わりにDNSなど階層的インフラとして編成することができます。フェーズIIマッピング情報は、BGP拡張としてxTRs間で分散させることができます。
4. The basic forwarding procedure is that the ITR first gets the destination AS number from the phase I mapper (or from cache) when the packet is entering the "core". Then, it will extract the closest ETR for the destination AS number. This is local, since phase II mapping information has been "pushed" to the ITR through BGP updates. Finally, the ITR tunnels the packet to the corresponding ETR.
4.基本的な転送手順は、ITRは、最初のパケットが「コア」を入力したとき、私は（またはキャッシュからの）マッパ相から数AS宛先を取得することです。その後、それはAS番号、宛先のための最も近いETRを抽出します。フェーズIIマッピング情報は、BGPアップデートを通じてITRに「プッシュ」されているので、これは、局所的です。最後に、ITRは、対応するETRにパケットをトンネルします。
1. Any prefix reconfiguration (aggregation/deaggregation) within an AS will not be reflected in the mapping system.
1 AS内の任意のプレフィックスの再構成（凝集/脱凝集）がマッピングシステムに反映されないであろう。
2. Local prefixes can be aggregated with a high degree of efficiency.
2.ローカルプレフィックスが効率良く凝集させることができます。
4. A stable mapping system will reduce the update overhead introduced by topology changes and/or routing policy dynamics.
4.安定したマッピングシステムは、トポロジの変更及び/又はルーティングポリシーダイナミクスによって導入された更新のオーバーヘッドを削減します。
1. The two-phased mapping scheme introduces an AS number between the mapping prefixes and ETRs.
1.二相マッピング方式は、マッピング・プレフィックスとETRS間のAS番号を導入します。
2. The decoupling of direct mapping makes highly dynamic updates stable; therefore, it can be more scalable than any direct mapping designs.
2.直接マッピングの分離は非常に動的な更新を安定させます。したがって、それは任意の直接マッピングの設計よりもスケーラブルであることができます。
3. The two-phased mapping scheme is adaptable to any proposals based on the core/edge split.
3.二相マッピング方式は、コア/エッジ分割に基づく任意の提案に適応可能です。
No references were submitted.
いかなる参照が提出されませんでした。
This is a simple idea on how to scale mapping. However, this design is too incomplete to be considered a serious input to RRG. Take the following two issues as example:
これは、マッピングを拡張する方法についての簡単なアイデアです。しかし、この設計はRRGへの深刻な入力とみなされるにはあまりにも不完全です。例として、次の2つの問題を取ります：
First, in this two-phase scheme, an AS is essentially the unit of destinations (i.e., sending ITRs find out destination AS D, then send data to one of D's ETRs). This does not offer much choice for traffic engineering.
まず、この2段階方式で、AS（すなわち、送信のITRは、次にD'S ETRSのいずれかにデータを送り、D AS先を見つける）は、本質的な目的地の単位です。これは、トラフィックエンジニアリングのための多くの選択肢を提供していません。
Second, there is no consideration whatsoever on failure detection and handling.
第二に、障害検出および取り扱いに関する一切考慮されていません。
No rebuttal was submitted for this proposal.
いかなる反論は、この提案のために提出されませんでした。
GLI-Split implements a separation between global routing (in the global Internet outside edge networks) and local routing (inside edge networks) using global and local locators (GLs and LLs). In addition, a separate static identifier (ID) is used to identify communication endpoints (e.g., nodes or services) independently of any routing information. Locators and IDs are encoded in IPv6 addresses to enable backwards-compatibility with the IPv6 Internet. The higher-order bits store either a GL or a LL, while the lower- order bits contain the ID. A local mapping system maps IDs to LLs, and a global mapping system maps IDs to GLs. The full GLI-mode requires nodes with upgraded networking stacks and special GLI-gateways. The GLI-gateways perform stateless locator rewriting in IPv6 addresses with the help of the local and global mapping system. Non-upgraded IPv6 nodes can also be accommodated in GLI-domains since an enhanced DHCP service and GLI-gateways compensate for their missing GLI-functionality. This is an important feature for incremental deployability.
GLI-分割は、グローバルとローカルロケータ（GLsのとのLL）を用いて（エッジネットワーク外のグローバルインターネットで）グローバルルーティングおよびローカルルーティング（エッジネットワーク内）との間の分離を実現します。また、別の静的識別子（ID）は、通信エンドポイント（例えば、ノードまたはサービス）独立して、任意のルーティング情報を識別するために使用されます。ロケータとIDは、IPv6でエンコードされているIPv6インターネットとの下位互換性を可能にするために対処しています。低級上位ビットはIDを含むながら上位ビットは、GL又はLLのいずれかを格納します。ローカルマッピングシステムは、のLLにIDをマップし、グローバルマッピングシステムはGLsのにIDをマップします。フルGLI-modeは、アップグレードされたネットワーキング・スタックや特別GLI-ゲートウェイを持つノードが必要です。 GLI-ゲートウェイは、ローカルおよびグローバルマッピングシステムの助けを借りて、IPv6アドレスに書き換えステートレスロケータを行います。強化されたDHCPサービスとGLI-ゲートウェイがその欠落しているGLI-機能を補うため、アップグレードされていないIPv6ノードは、GLI-ドメイン内に収納することができます。これは、増分展開性のための重要な機能です。
The benefits of GLI-Split are:
GLI-分割の利点は次のとおりです。
o Hierarchical aggregation of routing information in the global Internet through separation of edge and core routing
エッジの分離およびコアルーティングを介してグローバルインターネットにルーティング情報の階層的集合O
o Provider changes not visible to nodes inside GLI-domains (renumbering not needed)
GLI-ドメイン内のノードには見えないOプロバイダ変更（リナンバリング不要）
o Rearrangement of subnetworks within edge networks not visible to the outside world (better support of large edge networks)
外の世界には見えないエッジネットワーク内のサブネットワークのO転位（大エッジネットワークのより良いサポート）
o Transport connections survive both types of changes
O交通機関の接続は、変化の両方のタイプを乗り切ります
o Multihoming
Oマルチホーミング
o Improved traffic engineering for incoming and outgoing traffic
着信および発信トラフィックのためのOの改善トラフィックエンジニアリング
o Multipath routing and load balancing for hosts
ホストに対して均衡Oマルチパスルーティングおよび負荷
o Improved resilience
Oの改善回復力
o Improved mobility support without home agents and triangle routing
ホームエージェントと三角ルーティングなしOの改善モビリティサポート
o Interworking with the classic Internet
古典的なインターネットとOのインターワーキング
* without triangle routing over proxy routers
*プロキシルータの上に三角形のルーティングなし
* without stateful NAT
*ステートフルNATなし
These benefits are available for upgraded GLI-nodes, but non-upgraded nodes in GLI-domains partially benefit from these advanced features, too. This offers multiple incentives for early adopters, and they have the option to migrate their nodes gradually from non-GLI-stacks to GLI-stacks.
これらの利点は、アップグレードされたGLI-のノードのために利用可能ですが、GLI-ドメインでアップグレードされていないノードは、部分的に、あまりにも、これらの高度な機能の恩恵を受ける。これは、早期導入のために複数のインセンティブを提供しています、そして、彼らはGLI-スタックに非GLI-スタックから徐々に自分のノードを移行するオプションがあります。
o Local and global mapping system
ローカルおよびグローバルマッピングシステムO
o Modified DHCP or similar mechanism
O変更DHCPまたは類似の機構
o GLI-gateways with stateless locator rewriting in IPv6 addresses
OステートレスロケータとGLI-ゲートウェイはIPv6アドレスに書き換え
o Upgraded stacks (only for full GLI-mode)
O（のみフルGLIモード用）スタックをアップグレード
[GLI]
[]
GLI-Split makes a clear distinction between two separation planes: the separation between identifier and locator (which is to meet end-users' needs including mobility) and the separation between local and global locator (which makes the global routing table scalable). The distinction is needed since ISPs and hosts have different requirements, with both needing to make the changes inside and outside GLI-domains invisible to their opposites.
（グローバルルーティングテーブルは、スケーラブルにする）識別子とロケータとの間の分離（モビリティを含む、エンドユーザーのニーズを満たすためである）ローカルおよびグローバルロケータとの間の分離：GLI-分割は、2つの分離面との間に明確な区別を行います。 ISPやホストが異なる要件を持っているので、区別は、両方が彼らの反対には不可視GLI-ドメイン内外の変更を加えることが必要で、必要とされています。
A main drawback of GLI-Split is that it puts a burden on hosts. Before routing a packet received from upper layers, network stacks in hosts first need to resolve the DNS name to an IP address; if the IP address is GLI-formed, it may look up the map from the identifier extracted from the IP address to the local locator. If the communication is between different GLI-domains, hosts may further look up the mapping from the identifier to the global locator. Having the local mapping system forward requests to the global mapping system for hosts is just an option. Though host lookup may ease the burden of intermediate nodes, which would otherwise to perform the mapping lookup, the three lookups by hosts in the worst case may lead to large delays unless a very efficient mapping mechanism is devised. The work may also become impractical for low-powered hosts. On one hand, GLI-Split can provide backward compatibility where classic and upgraded IPv6 hosts can communicate. This is its big virtue. On the other hand, the need to upgrade may work against hosts' enthusiasm to change. This is offset against the benefits they would gain.
GLI-スプリットの主な欠点は、それがホストに負担を置くことです。上位層から受信したパケットをルーティングする前に、ホスト内のネットワークスタックは、最初のIPアドレスにDNS名を解決する必要があります。 IPアドレスはGLI-形成されている場合、それはローカルロケータにIPアドレスから抽出された識別子からマップを見上げることがあります。通信が異なるGLI-ドメインの間にある場合、ホストは、さらにグローバルロケータへの識別子のマッピングをルックアップすることができます。ホストのグローバルマッピングシステムへのローカルマッピングシステム前方の要求を持つことは、単にオプションです。ホストルックアップがそれ以外のマッピングルックアップを実行できるようになり、中間ノードの負荷を軽減することがありますが、非常に効率的なマッピング機構が考案されていない限り、最悪の場合、ホストによる3つのルックアップは大きな遅延につながる可能性があります。仕事はまた、低消費電力のホストのための実用的でなくなることがあります。一方、GLI-分割は、古典的な、アップグレードのIPv6ホストが通信できる後方互換性を提供することができます。これは、その大きな美徳です。一方、アップグレードする必要が変更するホストの熱意に対して動作する可能性があります。これは、彼らが得るだろうメリットと相殺されます。
GLI-Split provides additional features to improve TE and to improve resilience, e.g., exerting multipath routing. However, the cost is that more burdens are placed on hosts, e.g., they may need more lookup actions and route selections. However, these kinds of tradeoffs between costs and gains exist in most proposals.
GLI-分割マルチパスルーティングを発揮する、例えば、TEを改善し、回復力を改善するための追加機能を提供します。しかし、コストがより多くの負担がホスト上に配置されていることである、例えば、彼らはより多くのルックアップアクションとルートの選択が必要な場合があります。しかし、コストと利益の間のトレードオフのこれらの種類は、ほとんどの提案に存在します。
One improvement of GLI-Split is its support for mobility by updating DNS data as GLI-hosts move across GLI-domains. Through this, the GLI-corresponding-node can query DNS to get a valid global locator of the GLI-mobile-node and need not query the global mapping system (unless it wants to do multipath routing), giving more incentives for nodes to become GLI-enabled. The merits of GLI-Split, including simplified-mobility-handover provision, compensate for the costs of this improvement.
GLI-ホストはGLI-ドメイン間で移動するとGLI-スプリットの1つの改良は、DNSデータを更新することにより、モビリティのサポートです。これにより、ノードになるためのより多くのインセンティブを与え、DNSを照会することができますGLI-対応するノードは、GLI-モバイル・ノードの有効なグローバルロケータを取得すると（それがマルチパスルーティングを行うことを望んでいない限り）グローバルマッピングシステムを照会する必要はありませんGLI対応。簡易モビリティ・ハンドオーバの提供など、GLI-分割のメリットは、この改善のコストを補います。
GLI-Split claims to use rewriting instead of tunneling for conversions between local and global locators when packets span GLI-domains. The major advantage is that this kind of rewriting needs no extra state, since local and global locators need not map to each other. Many other rewriting mechanisms instead need to maintain extra state. It also avoids the MTU problem faced by the tunneling methods. However, GLI-Split achieves this only by compressing the namespace size of each attribute (identifier and local/global locator). GLI-Split encodes two namespaces (identifier and local/ global locator) into an IPv6 address (each has a size of 2^64 or less), while map-and-encap proposals assume that identifier and locator each occupy a 128-bit space.
GLI-分割は、パケットがGLI-ドメインにまたがる場合、ローカルおよびグローバルロケータとの間の変換のための書き換えの代わりにトンネリングを使用することを主張します。主な利点は、ローカルおよびグローバルロケータ以来、ニーズに余分な状態を書き換えないこの種のは、お互いにマップする必要がないということです。他の多くの書き換えのメカニズムではなく、余分な状態を維持する必要があります。また、トンネリング方法が直面するMTUの問題を回避できます。しかし、GLI-スプリットは、各属性（識別子およびローカル/グローバルロケータ）の名前空間のサイズを圧縮することによってこれを実現します。マップ・アンド・ENCAP提案がその識別子とロケータは、それぞれ128ビットの空間を占有すると仮定しながら、GLI-分割は、（それぞれが2 ^ 64以下のサイズを有する）のIPv6アドレスに2つの名前空間（識別子及びローカル/グローバルロケータ）をコード。
The arguments in the GLI-Split critique are correct. There are only two points that should be clarified here. First, it is not a drawback that hosts perform the mapping lookups. Second, the critique proposed an improvement to the mobility mechanism, which is of a general nature and not specific to GLI-Split.
GLI-スプリット批判内の引数が正しいです。ここで明確にすべき唯一の2点があります。まず、ホストがマッピングルックアップを実行するという欠点ではありません。第二に、批判は一般的な性質のものであり、GLI-スプリットに固有のものではないモビリティ機構への改善を提案しました。
1. The additional burden on the hosts is actually a benefit, compared to having the same burden on the gateways. If the gateway would perform the lookups and packets addressed to uncached EIDs arrive, a lookup in the mapping system must be initiated. Until the mapping reply returns, packets must be either dropped, cached, or sent over the mapping system to the destination. All these options are not optimal and have their drawbacks. To avoid these problems in GLI-Split, the hosts perform the lookup. The short additional delay is not a big issue in the hosts because it happens before the first packets are sent. So, no packets are lost or have to be cached. GLI-Split could also easily be adapted to special GLI-hosts (e.g., low-power sensor nodes) that do not have to do any lookup and simply let the gateway do all the work. This functionality is included anyway for backward compatibility with regular IPv6 hosts inside the GLI-domain.
1.ホスト上の追加負担はゲートウェイで同じ負荷を有すると比較して、実際に利点です。ゲートウェイが到着キャッシュされていないのEID宛検索し、パケットを実行したい場合は、マッピングシステム内のルックアップを開始する必要があります。マッピング応答を返すまで、パケットは、キャッシュされたドロップしなければならないのいずれか、または宛先へのマッピングシステムを介して送信されます。すべてのこれらのオプションは最適ではなく、その欠点を持っています。 GLI-スプリットでこれらの問題を回避するために、ホストは、ルックアップを実行します。最初のパケットが送信される前に、それが起こるので、短い追加の遅延は、ホストには大きな問題ではありません。だから、何のパケットが失われないか、キャッシュする必要があります。 GLI-分割はまた、簡単に検索を行うと、単にゲートウェイがすべての作業を行うようにする必要はありません特別なGLI-ホスト（例えば、低電力センサノード）に適合させることができます。この機能は、GLI-ドメイン内の通常のIPv6ホストとの下位互換性のためにとにかく含まれています。
2. The critique proposes a DNS-based mobility mechanism as an improvement to GLI-Split. However, this improvement is an alternative mobility approach that can be applied to any routing architecture (including GLI-Split) and also raises some concerns, e.g., the update speed of DNS. Therefore, we prefer to keep this issue out of the discussion.
2.批判はGLI-スプリットの改良として、DNSベースのモビリティ・メカニズムを提案しています。しかし、この改善は、（GLI-スプリットを含む）任意のルーティングアーキテクチャに適用され、また、いくつかの懸念、DNSの例えば、更新速度を上げることができる別のモビリティ・アプローチです。したがって、我々は議論の外に、この問題を維持することを好みます。
Provides a method for locator/identifier separation using tunnels between routers on the edge of the Internet transit infrastructure. It enriches the BGP protocol for distributing the identifier-to-locator mapping. Using new BGP attributes, "identifier prefixes" are assigned inter-domain routing locators so that they will not be installed in the RIB and will be moved to a new table called the Tunnel Information Base (TIB). Afterwards, when routing a packet to an "identifier prefix", first the TIB will be searched to perform tunneling, and secondly the RIB will be searched for actual routing. After the edge router performs tunneling, all routers in the middle will route this packet until the packet reaches the router at the tail-end of the tunnel.
インターネットトランジット・インフラストラクチャのエッジ上のルータ間のトンネルを使用して、ロケータ/識別子分離するための方法を提供します。それは、識別子・ツー・ロケーターのマッピングを配布するためのBGPプロトコルを豊かにします。彼らはRIBにインストールされず、新しいテーブルに移動されますように、新しいBGP属性を使用して、「識別子の接頭辞は、」ドメイン間ルーティングロケータを割り当てられているトンネル情報ベース（TIB）と呼ばれます。 「識別子のプレフィックス」にパケットをルーティングする場合、その後、最初のTIBは、トンネリングを実行するために検索され、及び第二リブは実際のルーティングを探索します。エッジルータは、トンネリングを実行した後、中央の意志経路のすべてのルータのパケットまでこのパケットは、トンネルの末尾のルータに到達します。
o Smooth deployment
Oスムーズな展開
o Size reduction of the global RIB
グローバルRIBのOサイズの削減
o Deterministic customer traffic engineering for incoming traffic
着信トラフィックのO決定的顧客のトラフィックエンジニアリング
o Numerous forwarding decisions for a particular address prefix
特定のアドレスプレフィックスのためのOの多数の転送決定
o Stops AS number space depletion
番号空間の枯渇AS O停止
o Improved BGP convergence
Oの改善BGPコンバージェンス
o Protection of the inter-domain routing infrastructure
ドメイン間ルーティングインフラストラクチャのO保護
o Easy separation of control traffic and transit traffic
制御トラフィックと通過トラフィックのO容易に分離
o Different layer-2 protocol IDs for transit and non-transit traffic
トランジットと非トランジットトラフィックのためのO異なるレイヤ2プロトコルのID
o Multihoming resilience o New address families and tunneling techniques
新しいアドレスファミリおよびトンネリング技術〇〇マルチホーミングの回復力
o Support for IPv4 or IPv6, and migration to IPv6
OのIPv4またはIPv6のサポート、およびIPv6への移行
o Scalability, stability, and reliability
O拡張性、安定性、および信頼性
o Faster inter-domain routing
Oの高速化ドメイン間ルーティング
o Routers on the edge of the inter-domain infrastructure will need to be upgraded to hold the mapping database (i.e., the TIB).
ドメイン間インフラのエッジにOルータはマッピング・データベース（すなわち、TIB）を保持するようにアップグレードする必要があります。
o "Mapping updates" will need to be treated differently from usual BGP "routing updates".
O「マッピングの更新は、」通常のBGP「ルーティングアップデート」から異なる扱いをする必要があります。
[TIDR] [TIDR_identifiers] [TIDR_and_LISP] [TIDR_AS_forwarding]
[TIDR] [TIDR_identifiers] [TIDR_and_LISP] [TIDR_AS_forwarding]
TIDR is a Core-Edge Separation architecture from late 2006 that distributes its mapping information via BGP messages that are passed between DFZ routers.
TIDRはDFZルータ間で渡されるBGPメッセージを経由してそのマッピング情報を配信2006年後半からコア・エッジ分離アーキテクチャです。
This means that TIDR cannot solve the most important goal of scalable routing -- to accommodate much larger numbers of end-user network prefixes (millions or billions) without each such prefix directly burdening every DFZ router. Messages advertising routes for TIDR-managed prefixes may be handled with lower priority, but this would only marginally reduce the workload for each DFZ router compared to handling an advertisement of a conventional PI prefix.
それぞれのそのようなプレフィックスが直接すべてのDFZルータに負担をかけることなく、エンドユーザのネットワークプレフィックス（何百万あるいは数十億）の非常に大きな数字に対応するために - これはTIDRは、スケーラブルなルーティングの最も重要な目標を解決できないことを意味します。 TIDR管理のプレフィックスのルートをアドバタイズメッセージは、優先度の低い処理することができるが、これはわずかに、従来のPIプレフィックスの広告を扱うと比較した各DFZルータの負荷を軽減します。
Therefore, TIDR cannot be considered for RRG recommendation as a solution to the routing scaling problem.
したがって、TIDR、ルーティングスケーリング問題の解決策としてRRG推薦のために考慮することができません。
For a TIDR-using network to receive packets sent from any host, every BR of all ISPs must be upgraded to have the new ITR-like functionality. Furthermore, all DFZ routers would need to be altered so they accepted and correctly propagated the routes for end-user network address space, with the new LOCATOR attribute, which contains the ETR address and a REMOTE-PREFERENCE value. Firstly, if they received two such advertisements with different LOCATORs, they would advertise a single route to this prefix containing both. Secondly, for end-user address space (for IPv4) to be more finely divided, the DFZ routers must propagate LOCATOR-containing advertisements for prefixes longer than /24.
任意のホストから送信されたパケットを受信するTIDR、使用しているネットワークの場合は、すべてのISPのすべてのBRは、新しいITRのような機能を持つようにアップグレードする必要があります。彼らはETRアドレスとREMOTE-プリファレンス値を含む新しいLOCATOR属性で、エンドユーザのネットワークアドレス空間のルートを受け入れ、正しく伝播するようさらに、すべてのDFZルータは変更する必要があります。彼らは異なるロケータを持つ2つのような広告を受け取った場合はまず、彼らは両方を含むこのプレフィックスへの単一のルートをアドバタイズします。第二に、エンドユーザのアドレス（IPv4の）空間より細かく分割するため、DFZルータは/ 24より長いプレフィクスのロケータを含む広告を伝搬しなければなりません。
TIDR's ITR-like routers store the full mapping database -- so there would be no delay in obtaining mapping, and therefore no significant delay in tunneling traffic packets.
TIDRのITRのようなルータは、完全なマッピングデータベースを格納 - ので、トンネリングトラフィックパケット内のマッピングを取得するには遅れ、そのため有意な遅れはないだろう。
[TIDR] is written as if traffic packets are classified by reference to the RIB, but routers use the FIB for this purpose, and "FIB" does not appear in [TIDR].
[TIDR]トラフィックパケットがRIBを参照して分類されているかのように書かれていますが、ルータは[TIDR]に表示されません。この目的のためにFIB、および「FIB」を使用しています。
TIDR does not specify a tunneling technique, leaving this to be chosen by the ETR-like function of BRs and specified as part of a second kind of new BGP route advertised by that ETR-like BR. There is no provision for solving the PMTUD problems inherent in encapsulation-based tunneling.
TIDR本のBRのETR状関数によって選択され、そのETR状BRによってアドバタイズ新しいBGPルートの第二種の一部として指定することを残し、トンネリング技術が指定されていません。カプセル化ベースのトンネルに固有のPMTUDの問題を解決するための規定はありません。
ITR functions must be performed by already busy routers of ISPs, rather than being distributed to other routers or to sending hosts. There is no practical support for mobility. The mapping in each end-user route advertisement includes a REMOTE-PREFERENCE for each ETR-like BR, but this is used by the ITR-like functions of BRs to always select the LOCATOR with the highest value. As currently described, TIDR does not provide inbound load-splitting TE.
ITRの機能はなく、他のルータに分配されるよりも、または送信ホストに、のISP既にビジールータによって実行されなければなりません。モビリティのための実用的なサポートはありません。各エンドユーザの経路広告にマッピングは、各ETR状BRのためのリモート・プリファレンスを含むが、これは常に最高値とのロケータを選択するためのBRのITR状関数によって使用されます。現在説明したように、TIDRは、インバウンド負荷分割TEを提供していません。
Multihoming service restoration is achieved initially by the ETR-like function of the BR at the ISP (whose link to the end-user network has just failed). It looks up the mapping to find the next preferred ETR-like BR's address. The first ETR-like router tunnels the packets to the second ETR-like router in the other ISP. However, if the failure was caused by the first ISP itself being unreachable, then connectivity would not be restored until a revised mapping (with higher REMOTE-PREFERENCE) from the reachable ETR-like BR of the second ISP propagated across the DFZ to all ITR-like routers, or the withdrawn advertisement for the first one reaches the ITR-like router.
マルチホーミングサービス復元が（リンクエンドユーザネットワークへ単に失敗した）ISPにおけるBRのETR状関数によって最初に達成されます。これは、次の優先ETR-ようなBRのアドレスを見つけるために、マッピングを検索します。第ETR状ルータは、他のISPに第ETR状のルータにパケットをトンネルします。故障が最初のISP自体が到達不能であることによって引き起こされた場合は、その後、接続が全てITRにDFZに伝播第ISPの到達ETR状BRから（より高いREMOTE-好みに）改訂マッピングまで復元されません様ルーター、または最初のもののために撤回の広告は、ITRのようなルータに到達しました。
No rebuttal was submitted for this proposal.
いかなる反論は、この提案のために提出されませんでした。
o Provides crisp separation of Identifiers from Locators.
oはロケータからの識別子の鮮明な分離を提供します。
o Identifiers name nodes, not interfaces.
O識別子名ノードではなく、インターフェース。
o Locators name subnetworks, rather than interfaces, so they are equivalent to an IP routing prefix.
Oロケータ名サブネットワークではなく、インターフェイス、ので、IPルーティングプレフィックスに相当します。
o Identifiers are never used for network-layer routing, whilst Locators are never used for Node Identity.
ロケータは、ノードのアイデンティティのために使用されることはありませんしながら、O識別子は、ネットワーク層のルーティングに使用されることはありません。
o Transport-layer sessions (e.g., TCP session state) use only Identifiers, never Locators, meaning that changes in location have no adverse impact on an IP session.
Oトランスポート層セッション（例えば、TCPセッションの状態は）設置場所の変更は、IPセッションに有害な影響を与えないことを意味し、唯一の識別子、決してロケータを使用しています。
o The underlying protocol mechanisms support fully scalable site multihoming, node multihoming, site mobility, and node mobility.
O基本的なプロトコルのメカニズムは完全にスケーラブルなサイトマルチホーミング、ノードマルチホーミング、サイトのモビリティ、およびノードのモビリティをサポートしています。
o ILNP enables topological aggregation of location information while providing stable and topology-independent identities for nodes.
ノードのための安定したトポロジに依存しないIDを提供しながら、O ILNPは、位置情報のトポロジ集約を可能にします。
o In turn, this topological aggregation reduces both the routing prefix "churn" rate and the overall size of the Internet's global routing table, by eliminating the value and need for more-specific routing state currently carried throughout the global (default-free) zone of the routing system.
Oターンでは、このトポロジカル集約は値を排除することで、ルーティング接頭辞「解約」率とインターネットのグローバルルーティングテーブルの全体的なサイズの両方を低減し、現在グローバル（デフォルトフリー）ゾーン全体で実施し、より固有のルーティングの状態のために必要なルーティングシステムの。
o ILNP enables improved traffic engineering capabilities without adding any state to the global routing system. TE capabilities include both provider-driven TE and also end-site-controlled TE.
O ILNPは、グローバルルーティングシステムに任意の状態を追加することなく、改良されたトラフィック・エンジニアリング機能を可能にします。 TE機能は、両方のプロバイダ主導のTEともエンドサイト制御TEが含まれます。
o ILNP's mobility approach:
ILNPのモビリティ・アプローチ○：
* eliminates the need for special-purpose routers (e.g., home agent and/or foreign agent now required by Mobile IP and NEMO).
*（現在はモバイルIPおよびNEMOで必要とされる、例えば、ホームエージェントおよび/または外部エージェント）専用のルーターが不要になります。
* eliminates "triangle routing" in all cases.
*すべてのケースで「トライアングル・ルーティング」を排除します。
* supports both "make before break" and "break before make" layer-3 handoffs.
*「ブレークする前に行う」とレイヤ3ハンドオフ「メイクの前に壊す」の両方をサポートしています。
o ILNP improves resilience and network availability while reducing the global routing state (as compared with the currently deployed Internet).
（現在展開インターネットと比較して）グローバルルーティング状態を低減しつつ、O ILNPは、弾力性とネットワークの可用性を向上させることができます。
o ILNP is incrementally deployable:
O ILNPは、増分展開可能です。
* No changes are required to existing IPv6 (or IPv4) routers.
*変更は、既存のIPv6（またはIPv4）ルーターに必要ありません。
* Upgraded nodes gain benefits immediately ("day one"); those benefits gain in value as more nodes are upgraded (this follows Metcalfe's Law).
*アップグレードしたノードのゲインの利点すぐに（「初日」）;より多くのノードがアップグレードされているとして、これらの利点は（これはメトカーフの法則を次の）値で得ることができます。
* The incremental deployment approach is documented.
*増分の展開アプローチが記載されています。
o ILNP is backwards compatible:
O ILNPは後方互換性があります。
* ILNPv6 is fully backwards compatible with IPv6 (ILNPv4 is fully backwards compatible with IPv4).
* ILNPv6は（ILNPv4が完全にはIPv4との後方互換性がある）は、IPv6と完全に下位互換性があります。
* Reuses existing known-to-scale DNS mechanisms to provide identifier/locator mapping.
*識別子/ロケータマッピングを提供するために、既存の既知のツースケールDNSメカニズムを再利用します。
* Existing DNS security mechanisms are reused without change.
*既存のDNSのセキュリティメカニズムは、変更せずに再利用されます。
* Existing IP Security mechanisms are reused with one minor change (IPsec Security Associations replace the current use of IP addresses with the use of Identifier values). NB: IPsec is also backwards compatible.
*既存のIPセキュリティ・メカニズムは、一つのマイナーな変更（IPsecセキュリティアソシエーションは、識別子の値を使用したIPアドレスの現在の使用を置き換える）で再利用されます。 NB：IPsecはまた、下位互換性があります。
* The backwards compatibility approach is documented.
*後方互換性のアプローチが記載されています。
o No new or additional overhead is required to determine or to maintain locator/path liveness.
O新規または追加のオーバーヘッドを決定するために、またはロケータ/パスの生存性を維持するために必要とされません。
o ILNP does not require locator rewriting (NAT); ILNP permits and tolerates NAT, should that be desirable in some deployment(s).
O ILNPは（NAT）を書き換えロケータを必要としません。 ILNP許可とNATを許容、それはいくつかの展開（S）に望ましいことでなければなりません。
o Changes to upstream network providers do not require node or subnetwork renumbering within end-sites.
Oの変更は、ネットワークプロバイダーがエンドサイト内のノードまたはサブネットワークの再番号付けを必要としない上流へ。
o ILNP is compatible with and can facilitate the transition from current single-path TCP to multipath TCP.
O ILNPはと互換性があり、マルチパスTCPへの電流シングルパスTCPからの移行を容易にすることができます。
o ILNP can be implemented such that existing applications (e.g., applications using the BSD Sockets API) do NOT need any changes or modifications to use ILNP.
O ILNPは、既存のアプリケーション（例えば、BSDソケットAPIを使用するアプリケーション）はILNPを使用する任意の変更または修正を必要としないように実施することができます。
o End systems need to be enhanced incrementally to support ILNP in addition to IPv6 (or IPv4 or both).
Oエンドシステムは、IPv6（あるいはIPv4またはその両方）に加えて、ILNPをサポートするために、インクリメンタルに強化する必要があります。
o DNS servers supporting upgraded end systems also should be upgraded to support new DNS resource records for ILNP. (The DNS protocol and DNS security do not need any changes.)
アップグレードされたエンド・システムをサポートしているOのDNSサーバもILNPのための新しいDNSリソースレコードをサポートするようにアップグレードする必要があります。 （DNSプロトコルとDNSセキュリティは、すべての変更を必要としません。）
[ILNP_Site] [MobiArch1] [MobiArch2] [MILCOM1] [MILCOM2] [DNSnBIND] [Referral_Obj] [ILNP_Intro] [ILNP_Nonce] [ILNP_DNS] [ILNP_ICMP] [JSAC_Arch] [RFC4033] [RFC4034] [RFC4035] [RFC5534] [RFC5902]
[ILNP_Site] [MobiArch1] [MobiArch2] [MILCOM1] [MILCOM2] [DNSnBIND] [Referral_Obj] [ILNP_Intro] [ILNP_Nonce] [ILNP_DNS] [ILNP_ICMP] [JSAC_Arch] [RFC4033]、[RFC4034]、[RFC4035]、[RFC5534]、[RFC5902 ]
The primary issue for ILNP is how the deployment incentives and benefits line up with the RRG goal of reducing the rate of growth of entries and churn in the core routing table. If a site is currently using PI space, it can only stop advertising that space when the entire site is ILNP capable. This needs (at least) clear elucidation of the incentives for ILNP which are not related to routing scaling, in order for there to be a path for this to address the RRG needs. Similarly, the incentives for upgrading hosts need to align with the value for those hosts.
ILNPのための主な問題は、展開のインセンティブとメリットは、コアルーティングテーブル内のエントリの成長と解約率を低減させるRRGの目標と整列する方法です。サイトは現在、PIのスペースを使用している場合は、それだけでサイト全体がILNP可能である場合、そのスペースを宣伝停止することができます。これは、（少なくとも）このRRGニーズに対処するための経路があるようにするためのために、スケーリングをルーティングに関連しないILNPのインセンティブの明確な解明が必要です。同様に、ホストをアップグレードするためのインセンティブは、それらのホストの値と整合する必要があります。
A closely related question is whether this mechanism actually addresses the sites need for PI addresses. Assuming ILNP is deployed, the site does achieve flexible, resilient, communication using all of its Internet connections. While the proposal addresses the host updates when the host learns of provider changes, there are other aspects of provider change that are not addressed. This includes renumbering routers, subnets, and certain servers. (It is presumed that most servers, once the entire site has moved to ILNP, will not be concerned if their locator changes. However, some servers must have known locators, such as the DNS server.) The issues described in [RFC5887] will be ameliorated, but not resolved. To be able to adopt this proposal, and have sites use it, we need to address these issues. When a site changes points of attachment, only a small amount of DNS provisioning should be required. The LP resource record type is apparently intended to help with this. It is also likely that the use of dynamic DNS will help this.
密接に関連の質問は、このメカニズムが実際にサイトがPIアドレスのために必要なアドレスかどうかです。 ILNPが展開されていると仮定すると、サイトがインターネット接続のすべてを使用して、柔軟で弾力性、コミュニケーションを達成ありません。提案は、ホストは、プロバイダの変更を学習したホストのアップデートに対処しながら、対処されていないプロバイダの変更の他の側面があります。これは、リナンバリングルータ、サブネット、および特定のサーバーが含まれます。意志の問題は[RFC5887]で説明した（サイト全体がILNPに移動した後、そのロケータの変化が。しかし、いくつかのサーバは、DNSサーバとしてロケータを、知られている必要があります。場合は、ほとんどのサーバーは、心配されないことが推測されます）改善が、解決しないこと。この提案を採用し、サイトはそれを使用していできるようにするために、我々はこれらの問題に対処する必要があります。サイトには、添付ファイルのポイントを変更すると、DNSプロビジョニングは少量しか必要とされなければなりません。 LPリソースレコードタイプは明らかにこれを支援するためのものです。また、ダイナミックDNSの使用がこれを助ける可能性があります。
The ILNP mechanism is described as being suitable for use in conjunction with mobility. This raises the question of race conditions. To the degree that mobility concerns are valid at this time, it is worth asking how communication can be established if a node is sufficiently mobile that it is moving faster than the DNS update and DNS fetch cycle can effectively propagate changes.
ILNP機構は、モビリティに関連して使用するのに適していると記載されています。これは競合状態の問題を提起します。モビリティの懸念は、この時点で有効であること程度に、それは、ノードは、それがDNSの更新よりも速く動いているとDNSはサイクルが効果的に変更を伝播することができますフェッチすることを十分に携帯であれば通信が確立できるか尋ねる価値があります。
This proposal does presume that all communication using this mechanism is tied to DNS names. While it is true that most communication does start from a DNS name, it is not the case that all exchanges have this property. Some communication initiation and referral can be done with an explicit identifier/locator pair. This does appear to require some extensions to the existing mechanism (for both sides to add locators). In general, some additional clarity on the assumptions regarding DNS, particularly for low-end devices, would seem appropriate.
この提案は、このメカニズムを使用して、すべての通信がDNS名に結びついていることを前提としません。それは、ほとんどの通信は、DNS名から開始しないことは事実ですが、それはすべての交流はこの特性を有する場合ではありません。いくつかの通信開始と紹介は、明示的な識別子/ロケータペアで行うことができます。これは、既存のメカニズム（両側のためにロケータを追加する）にいくつかの拡張機能を必要とするように見えるん。一般的には、特にローエンドのデバイスのために、DNSに関する仮定上のいくつかの追加の透明度は、適切と思われます。
One issue that this proposal shares with many others is the question of how to determine which locator pairs (local and remote) are actually functional. This is an issue both for initial communications establishment and for robustly maintaining communication. It is likely that a combination of monitoring of traffic (in the host, where this is tractable), coupled with other active measures, can address this. ICMP is clearly insufficient.
多くの他の人とこの提案の株式は（ローカルおよびリモート）ロケータペアを決定する方法の問題である1つの問題は、実際に機能しています。これは、初期通信の確立のためと確実に通信を維持するために、両方の問題です。トラフィックのモニタリングの組み合わせは、他のアクティブな措置と相まって、（これは扱いやすいホストに）、これに対処できる可能性があります。 ICMPは明らかに不十分です。
ILNP eliminates the perceived need for PI addressing and encourages increased DFZ aggregation. Many enterprise users view DFZ scaling issues as too abstruse, so ILNP creates more user-visible incentives to upgrade deployed systems.
ILNPアドレッシングPIのための認知必要がなくなり、増加DFZ集約を奨励しています。 ILNPが展開システムをアップグレードするより多くのユーザに見えるのインセンティブを作成しますので、多くの企業ユーザーは、あまりにも難解としてDFZスケーリングの問題を表示します。
ILNP mobility eliminates Duplicate Address Detection (DAD), reducing the layer-3 handoff time significantly when compared to IETF standard Mobile IP, as shown in [MobiArch1] and [MobiArch2]. ICMP location updates separately reduce the layer-3 handoff latency.
ILNP移動度は、[MobiArch2] [MobiArch1]に示すように、IETF標準のモバイルIPと比較した場合に有意にレイヤ3ハンドオフ時間を短縮重複アドレス検出（DAD）を排除します。 ICMP位置更新は別々にレイヤ3ハンドオフ遅延を低減します。
Also, ILNP enables both host multihoming and site multihoming. Current BGP approaches cannot support host multihoming. Host multihoming is valuable in reducing the site's set of externally visible nodes.
また、ILNPはホストマルチホーミングとサイトマルチホーミングの両方を可能にします。現在のBGPのアプローチは、ホストマルチホーミングをサポートすることはできません。ホストマルチホーミングは、外部から見えるノードのサイトのセットを減らすのに貴重です。
Improved mobility support is very important. This is shown by the research literature and also appears in discussions with vendors of mobile devices (smartphones, MP3 players). Several operating system vendors push "updates" with major networking software changes in maintenance releases today. Security concerns mean most hosts receive vendor updates more quickly these days.
改善されたモビリティサポートは非常に重要です。これは、研究文献で示されており、また、モバイルデバイス（スマートフォン、MP3プレーヤー）のベンダーとの協議に表示されます。いくつかのオペレーティングシステムのベンダーはメンテナンスリリースの主要なネットワーキング・ソフトウェアの変更今日で「更新」を押してください。セキュリティ上の懸念は、ほとんどのホストは、これらの日より早くベンダーの更新を受け取る意味します。
ILNP enables a site to hide exterior connectivity changes from interior nodes, using various approaches. One approach deploys unique local address (ULA) prefixes within the site, and has the site border router(s) rewrite the Locator values. The usual NAT issues don't arise because the Locator value is not used above the network-layer. [MILCOM1] [MILCOM2]
ILNPは、様々なアプローチを使用して、内部ノードから外部接続の変更を非表示にするには、サイトを可能にします。一つのアプローチは、サイト内でユニークローカルアドレス（ULA）接頭辞を展開し、サイトの境界ルータ（S）ロケータ値を書き換えています。ロケータ値は、ネットワーク層の上に使用されていないため、通常のNATの問題は発生しません。 [MILCOM1] [MILCOM2]
[RFC5902] makes clear that many users desire IPv6 NAT, with site interior obfuscation as a major driver. This makes global-scope PI addressing much less desirable for end sites than formerly.
[RFC5902]は、多くのユーザーは、主要なドライバーとして、サイト内部の難読化で、IPv6のNATを望んでいることが明らかになります。これはあまり望ましく、以前よりもエンドサイトへのアドレス指定をグローバルスコープのPIになります。
ILNP-capable nodes can talk existing IP with legacy IP-only nodes, with no loss of current IP capability. So, ILNP-capable nodes will never be worse off.
ILNP可能なノードは、現在のIP機能を失うことなく、従来のIP専用ノードと既存のIPを話すことができます。だから、ILNP可能なノードがオフに悪化することはありません。
Secure Dynamic DNS Update is standard and widely supported in deployed hosts and DNS servers. [DNSnBIND] says many sites have deployed this technology without realizing it (e.g., by enabling both the DHCP server and Active Directory of the MS-Windows Server).
セキュリティで保護された動的DNSの更新は、標準および広く採用されているホストとDNSサーバでサポートされています。 [DNSnBIND]多くのサイトが（DHCPサーバとMS-のWindows Server Active Directoryの両方を有効にすることにより、例えば）それを実現することなく、この技術を展開していると言います。
If a node is as mobile as the critique says, then existing IETF Mobile IP standards also will fail. They also use location updates (e.g., MN -> home agent, MN -> foreign agent).
ノードは批判が言うほどの携帯であれば、既存のIETFモバイルIP規格にも失敗します。 （ - >ホームエージェント、MN - >外国人のエージェント、例えば、MN）彼らはまた、位置情報の更新を使用しています。
ILNP also enables new approaches to security that eliminate dependence upon location-dependent Access Control Lists (ACLs) without packet authentication. Instead, security appliances track flows using Identifier values and validate the identifier/locator relationship cryptographically [RFC4033] [RFC4034] [RFC4035] or non-cryptographically by reading the nonce [ILNP_Nonce].
ILNPまたパケット認証なしの位置に依存するアクセス制御リスト（ACL）に依存を解消するセキュリティへの新しいアプローチを可能にします。代わりに、セキュリティ・アプライアンス・トラックは、ナンス[ILNP_Nonce]を読み出すことによって、識別子/ロケータ関係暗号[RFC4033]、[RFC4034]、[RFC4035]、または非暗号を識別子の値を使用して検証して流れます。
The DNS LP record has a more detailed explanation now. LP records enable a site to change its upstream connectivity by changing the L resource records of a single FQDN covering the whole site, thereby providing scalability.
DNS LPレコードは現在、より詳しい説明があります。 LPレコードは、それによって、スケーラビリティを提供し、サイト全体をカバーする単一のFQDNのLリソースレコードを変更することによって、その上流接続を変更するサイトを可能にします。
DNS-based server load balancing works well with ILNP by using DNS SRV records. DNS SRV records are not new, are widely available in DNS clients and servers, and are widely used today in the IPv4 Internet for server load balancing.
DNSベースのサーバーロードバランシングは、DNS SRVレコードを使用してILNPでうまく動作します。 DNS SRVレコードは、新しいものではありませんDNSクライアントとサーバで広く入手可能であり、かつ広くサーバロードバランシングのためにIPv4インターネットで今日使用されています。
Recent ILNP documents discuss referrals in more detail. A node with a binary referral can find the FQDN using DNS PTR records, which can be authenticated [RFC4033] [RFC4034] [RFC4035]. Approaches such as [Referral_Obj] improve user experience and user capability, so are likely to self-deploy.
最近ILNP文書は、より詳細に紹介を議論します。バイナリ紹介有するノードは[RFC4033]、[RFC4034]、[RFC4035]に認証することができるDNS PTRレコードを使用してFQDNを見つけることができます。そのようなユーザーエクスペリエンスとユーザーの能力を向上[Referral_Obj]などのアプローチは、その自己展開するために可能性があります。
Selection from multiple Locators is identical to an IPv4 system selecting from multiple A records for its correspondent. Deployed IP nodes can track reachability via existing host mechanisms or by using the SHIM6 method. [RFC5534]
複数のロケータからの選択は、その対応のための複数のAレコードから選択したIPv4システムと同じです。展開IPノードは、既存のホストのメカニズムを介して、またはSHIM6法を使用して到達可能性を追跡することができます。 [RFC5534]
13. Enhanced Efficiency of Mapping Distribution Protocols in Map-and-Encap Schemes (EEMDP)
地図-と-ENCAPスキームでマッピング配布プロトコルの13効率化（EEMDP）
We present some architectural principles pertaining to the mapping distribution protocols, especially applicable to the map-and-encap (e.g., LISP) type of protocols. These principles enhance the efficiency of the map-and-encap protocols in terms of (1) better utilization of resources (e.g., processing and memory) at Ingress Tunnel Routers (ITRs) and mapping servers, and consequently, (2) reduction of response time (e.g., first-packet delay). We consider how Egress Tunnel Routers (ETRs) can perform aggregation of endpoint ID (EID) address space belonging to their downstream delivery networks, in spite of migration/re-homing of some subprefixes to other ETRs. This aggregation may be useful for reducing the processing load and memory consumption associated with map messages, especially at some resource-constrained ITRs and subsystems of the mapping distribution system. We also consider another architectural concept where the ETRs are organized in a hierarchical manner for the potential benefit of aggregation of their EID address spaces. The two key architectural ideas are discussed in some more detail below. A more complete description can be found in [EEMDP_Considerations] and [EEMDP_Presentation].
我々は、マップ・アンド・エンキャップのプロトコル（例えば、LISP）タイプに特に適用マッピング配信プロトコルに関連するいくつかのアーキテクチャの原則を提示します。これらの原則は、その結果、応答の（2）の減少を入力トンネルルータ（ITRは）およびマッピングサーバでのリソースの（1）良好な利用（例えば、処理およびメモリ）の観点マップと-ENCAPプロトコルの効率を高め、時間（例えば、最初のパケット遅延）。私たちは、出口トンネルルータ（ETRS）は、マイグレーション/再ホーミング他ETRSにはいくつかのサブプレフィクスのにもかかわらず、その下流の配信ネットワークに属するエンドポイントID（EID）のアドレス空間の集約を行うことができる方法を検討します。この凝集は、特に、いくつかのリソースに制約のITRおよびマッピング分配システムのサブシステムで、マップメッセージに関連付けられた処理負荷やメモリ消費量を低減するために有用であり得ます。また、ETRSは、そのEIDのアドレス空間の凝集の潜在的な利益のために階層的に編成されている他の建築コンセプトを考えます。二つの重要な建築のアイデアは、以下のいくつかのより詳細に議論されています。より完全な説明は、[EEMDP_Presentation] [EEMDP_Considerations]に見出すことができます。
It will be helpful to refer to Figures 1, 2, and 3 in [EEMDP_Considerations] for some of the discussions that follow here below.
なお、以下に、ここで以下の説明の一部について[EEMDP_Considerations]で図1、図2、および3を参照すると便利になります。
13.1.2. Management of Mapping Distribution of Subprefixes Spread across Multiple ETRs
13.1.2. 複数のETRSまたがっサブプレフィクスのマッピング配布の管理
To assist in this discussion, we start with the high level architecture of a map-and-encap approach (it would be helpful to see Figure 1 in [EEMDP_Considerations]). In this architecture, we have the usual ITRs, ETRs, delivery networks, etc. In addition, we have the ID-Locator Mapping (ILM) servers, which are repositories for complete mapping information, while the ILM-Regional (ILM-R) servers can contain partial and/or regionally relevant mapping information.
この議論を支援するために、我々は、マップ・アンド・ENCAPアプローチ（[EEMDP_Considerations]で図1を参照することが有用であろう）の高レベルのアーキテクチャで始まります。 ILM-地域（ILM-R）ながら、このアーキテクチャでは、我々はまた、通常のITR、ETRS、配信ネットワーク、等を有していて、我々は、完全なマッピング情報のリポジトリであるID-ロケータマッピング（ILM）サーバを有しますサーバーは、部分的および/または地域の関連するマッピング情報を含めることができます。
While a large endpoint address space contained in a prefix may be mostly associated with the delivery networks served by one ETR, some fragments (subprefixes) of that address space may be located elsewhere at other ETRs. Let a/20 denote a prefix that is conceptually viewed as composed of 16 subnets of /24 size that are denoted as a1/24, a2/24, ..., a16/24. For example, a/20 is mostly at
接頭辞に含まれる大エンドポイントアドレス空間はほとんど1 ETRによってサービス配信ネットワークと関連付けられてもよいが、そのアドレス空間の一部断片（サブプレフィクス）は、他のETRSに他の場所に配置することができます。 / 20 A1 / 24と表記されている/ 24サイズ、A2 / 24、...、A16 / 24の16個のサブネットで構成として概念的に表示される接頭辞を示すものとします。例えば、/ 20で大部分であります
ETR1, while only two of its subprefixes a8/24 and a15/24 are elsewhere at ETR3 and ETR2, respectively (see Figure 2 [EEMDP_Considerations]). From the point of view of efficiency of the mapping distribution protocol, it may be beneficial for ETR1 to announce a map for the entire space a/20 (rather than fragment it into a multitude of more-specific prefixes), and provide the necessary exceptions in the map information. Thus, the map message could be in the form of Map:(a/20, ETR1; Exceptions: a8/24, a15/24). In addition, ETR2 and ETR3 announce the maps for a15/24 and a8/24, respectively, and so the ILMs know where the exception EID addresses are located. Now consider a host associated with ITR1 initiating a packet destined for an address a7(1), which is in a7/24 that is not in the exception portion of a/20. Now a question arises as to which of the following approaches would be the best choice:
ETR1、一方、2つだけのサブプレフィクスのA8 / 24及びA15 / 24は、それぞれ、ETR3とETR2で他の場所である（図2 [EEMDP_Considerations]を参照します）。 ETR1は（というよりも、特定のプレフィックスの多数にそれを断片）の全空間/ 20のマップを発表し、必要な例外を提供するためのマッピング配信プロトコルの効率の観点から、それは有益であり得ます地図情報をインチしたがって、マップメッセージはマップの形であってもよい：（/ 20、ETR1;例外：A8 / 24、A15 / 24）。また、ETR2とETR3はそれぞれ、A15 / 24およびA8 / 24のマップを発表し、例外EIDアドレスが配置されている場所のでILMSは知っています。今ITR1は/ 20を除く部分ではないA7 / 24にあるアドレスA7（1）宛のパケットの開始に関連付けられたホストを考慮する。今の質問は最良の選択となる以下のアプローチのどちらにとして生じます：
1. ILM-R provides the complete mapping information for a/20 to ITR1 including all maps for relevant exception subprefixes.
1 ILM-Rは、関連する例外サブプレフィクスのためのすべてのマップを含むITR1に/ 20のための完全なマッピング情報を提供します。
2. ILM-R provides only the directly relevant map to ITR1, which in this case is (a/20, ETR1).
2. ILM-Rは、この場合でITR1、（/ 20、ETR1）にのみ直接関係マップを提供します。
In the first approach, the advantage is that ITR1 would have the complete mapping for a/20 (including exception subnets), and it would not have to generate queries for subsequent first packets that are destined to any address in a/20, including a8/24 and a15/24. However, the disadvantage is that if there is a significant number of exception subprefixes, then the very first packet destined for a/20 will experience a long delay, and also the processors at ITR1 and ILM-R can experience overload. In addition, the memory usage at ITR1 can be very inefficient. The advantage of the second approach above is that the ILM-R does not overload resources at ITR1, neither in terms of processing or memory usage, but it needs an enhanced map response in of the form Map:(a/20, ETR1, MS=1), where the MS (More Specific) indicator is set to 1 to indicate to ITR1 that not all subnets in a/20 map to ETR1. The key idea is that aggregation is beneficial, and subnet exceptions must be handled with additional messages or indicators in the maps.
第1のアプローチでは、利点はITR1は（例外サブネットを含む）/ 20のための完全なマッピングを有することであり、A8を含む/ 20の任意のアドレスを宛先とするその後の最初のパケットのためのクエリを生成する必要はないであろう/ 24およびA15 / 24。しかし、欠点は、例外サブプレフィクスのかなりの数が存在する場合、次いで/ 20宛の非常に最初のパケットが長い遅延を経験する、またITR1とILM-Rでプロセッサが過負荷を経験することができることです。また、ITR1でのメモリ使用量が非常に非効率的であることができます。 （/ 20、ETR1、MS：上記第二の方法の利点は、ILM-RはITR1で、いずれも処理やメモリ使用量の観点でリソースを過負荷にならないが、それはフォームマップの中の拡張マップ応答を必要とすることです= 1）、MS（より具体的な）インジケータが1に設定されている場合ITR1に示すためにそのないETR1へ/ 20マップ内のすべてのサブネット。キーアイデアは、凝集が有益である、とサブネット例外がマップに追加のメッセージやインジケーターで処理しなければならないということです。
13.1.3. Management of Mapping Distribution for Scenarios with Hierarchy of ETRs and Multihoming
13.1.3. ETRSとマルチホーミングの階層を持つシナリオのマッピングの配布の管理
Now we highlight another architectural concept related to mapping management (please refer to Figure 3 in [EEMDP_Considerations]). Here we consider the possibility that ETRs may be organized in a hierarchical manner. For instance, ETR7 is higher in the hierarchy relative to ETR1, ETR2, and ETR3, and like-wise ETR8 is higher relative to ETR4, ETR5, and ETR6. For instance, ETRs 1 through 3 can relegate the locator role to ETR7 for their EID address space. In essence, they can allow ETR7 to act as the locator for the delivery networks in their purview. ETR7 keeps a local mapping table for mapping the appropriate EID address space to specific ETRs that are hierarchically associated with it in the level below. In this situation, ETR7 can perform EID address space aggregation across ETRs 1 through 3 and can also include its own immediate EID address space for the purpose of that aggregation. The many details related to this approach and special circumstances involving multihoming of subnets are discussed in detail in [EEMDP_Considerations]. The hierarchical organization of ETRs and delivery networks should help in the future growth and scalability of ETRs and mapping distribution networks. This is essentially recursive map-and-encap, and some of the mapping distribution and management functionality will remain local to topologically neighboring delivery networks that are hierarchically underneath ETRs.
今、私たちは（[EEMDP_Considerations]で図3を参照してください）マッピング管理に関連する他の建築コンセプトを強調表示します。ここでは、ETRSは階層的に編成することができる可能性を検討してください。例えば、ETR7はETR1、ETR2、およびETR3に階層相対が高い、などワイズETR8はETR4、ETR5、及びETR6に高い相対的です。例えば、3を通してETRS 1は、そのEIDのアドレス空間のためのETR7へのロケータの役割を格下げすることができます。要するに、彼らはETR7が自分の権限の範囲内配信ネットワークのためのロケータとして機能できるようにすることができます。 ETR7は、階層下のレベルで関連付けられている特定ETRSに適切なEIDアドレス空間をマッピングするためのローカル・マッピングテーブルを保持します。このような状況では、ETR7は3を通じてETRS 1渡っEIDのアドレス空間の集約を行うことができ、また、その凝集の目的のために、独自の即時EIDのアドレス空間を含めることができます。このアプローチとサブネットのマルチホーミングを含む特殊な状況に関連する多くの詳細は[EEMDP_Considerations]に詳細に記載されています。 ETRSと配信ネットワークの階層的な組織はETRSとマッピング配信ネットワークの将来の成長とスケーラビリティに役立つはずです。これは、本質的に再帰的なマップ・アンド・エンキャップであり、マッピング流通及び管理機能の一部はETRS下に階層的である位相的に隣接する配信ネットワークのローカル残ります。
[EEMDP_Considerations] [EEMDP_Presentation] [FIBAggregatability]
[EEMDP_Considerations] [EEMDP_Presentation] [FIBAggregatability]
The scheme described in [EEMDP_Considerations] represents one approach to mapping overhead reduction, and it is a general idea that is applicable to any proposal that includes prefix or EID aggregation. A somewhat similar idea is also used in Level-3 aggregation in the FIB aggregation proposal [FIBAggregatability]. There can be cases where deaggregation of EID prefixes occur in such a way that the bulk of an EID prefix P would be attached to one locator (say, ETR1) while a few subprefixes under P would be attached to other locators elsewhere (say, ETR2, ETR3, etc.). Ideally, such cases should not happen; however, in reality it can happen as the RIR's address allocations are imperfect. In addition, as new IP address allocations become harder to get, an IPv4 prefix owner might split previously unused subprefixes of that prefix and allocate them to remote sites (homed to other ETRs). Assuming these situations could arise in practice, the nature of the solution would be that the response from the mapping server for the coarser site would include information about the more specifics. The solution as presented seems correct.
【EEMDP_Considerations]に記載の方式は、マッピング・オーバーヘッド削減する一つの方法を表し、それはプレフィックスまたはEID集合を含む任意の提案にも適用可能である一般的な考え方です。幾分同様の考えはまた、FIB集約案[FIBAggregatability]でレベル3の凝集に使用されます。 EIDプレフィクスの解凝集はPの下で、いくつかのサブプレフィクスは、他の場所で他のロケータに取り付けられるながらEIDプレフィックスPのバルク一のロケータ（たとえば、ETR1）に取り付けられるような方法（例えば、ETR2で起こる場合があり得ます、ETR3、など）。理想的には、このような場合は発生しません。 RIRのアドレス割り当てが不完全であるようしかし、現実にはそれが起こることができます。新しいIPアドレスの割り当てを得ることが困難になるよう加えて、IPv4のプレフィックスの所有者は、その接頭辞の前に、未使用のサブプレフィクスを分割する可能性があり、リモートサイト（他ETRSにホーミング）に割り当てます。このような状況が実際に発生したと仮定すると、ソリューションの性質が粗いサイトのマッピングサーバからの応答がより詳細に関する情報が含まれることになります。提示された解決策は正しいようです。
The proposal mentions that in Approach 1, the ID-Locator Mapping (ILM) system provides the complete mapping information for an aggregate EID prefix to a querying ITR, including all the maps for the relevant exception subprefixes. The sheer number of such more-specifics can be worrisome, for example, in LISP. What if a company's mobile-node EIDs came out of their corporate EID prefix? Approach 2 is far better but still there may be too many entries for a regional ILM to store. In Approach 2, the ILM communicates that there are more specifics but does not communicate their mask-length. A suggested improvement would be that rather than saying that there are more specifics, indicate what their mask-lengths are. There can be multiple mask lengths. This number should be pretty small for IPv4 but can be large for IPv6.
提案は、アプローチ1において、ID-ロケータマッピング（ILM）システムは、関連する例外サブプレフィクスのためのすべてのマップを含むクエリITRへ集約EIDプレフィクスのための完全なマッピング情報を提供することに言及しています。そのようなより-仕様の膨大な数は、LISP、例えば、気になることができます。どのような企業のモバイル・ノードのEIDは、企業のEIDプレフィックスから出てきた場合は？アプローチ2は、はるかに良いですが、それでも店に地域のILMのためにあまりにも多くのエントリがあるかもしれません。アプローチ2において、ILMが、より具体的であるが、それらのマスクの長さを通信しないことを通信します。提案改善がそれではなく、多くの細目があるということでしょう、そのマスク長が何であるかを示しています。複数のマスク長が存在する場合があります。この番号は、IPv4のためにかなり小さいはずであるが、IPv6に大きくなることがあります。
Later in the proposal, a different problem is addressed, involving a hierarchy of ETRs and how aggregation of EID prefixes from lower-level ETRs can be performed at a higher-level ETR. The various scenarios here are well illustrated and described. This seems like a good idea, and a solution like LISP can support this as specified. As any optimization scheme would inevitably add some complexity; the proposed scheme for enhancing mapping efficiency comes with some of its own overhead. The gain depends on the details of specific EID blocks, i.e., how frequently the situations (such as an ETR that has a bigger EID block with a few holes) arise.
後提案で、別の問題がETRSの階層を含む、アドレス指定され、どのように下位レベルETRSからEIDプレフィクスの集合は、より高いレベルのETRで行うことができます。ここでは様々なシナリオは十分に説明及び記載されています。これは良いアイデアのように思えるし、指定されたLISPのようなソリューションは、これをサポートすることができます。任意の最適化方式は、必然的にいくつかの複雑さを追加したよう。マッピング効率を向上させるための提案方式は、独自のオーバーヘッドの一部が付属しています。利得は、（例えば、いくつかの孔を有する大きなEIDブロックを有するETRような）状況が生じる、すなわち、頻度、特定EIDブロックの詳細に依存します。
There are two main points in the critique that are addressed here: (1) The gain depends on the details of specific EID blocks, i.e., how frequently the situations arise such as an ETR having a bigger EID block with a few holes, and (2) Approach 2 is lacking an added feature of conveying just the mask-length of the more specifics that exist as part of the current map response.
（状況は、このようなETRは、いくつかの穴に大きなEIDブロックを有するように発生頻度、すなわち、（1）の利得は、特定のEIDブロックの詳細に依存する、と：そこに二つの主なポイントは、ここで取り上げている批判しています2）アプローチ2は、現在のマップの応答の一部として存在し、より具体的にだけマスク長を伝える追加機能を欠いています。
Regarding comment (1) above, there are multiple possibilities regarding how situations can arise, resulting in allocations having holes in them. An example of one of these possibilities is as follows. Org-A has historically received multiple /20s, /22s, and /24s over the course of time that are adjacent to each other. At the present time, these prefixes would all aggregate to a /16 but for the fact that just a few of the underlying /24s have been allocated elsewhere historically to other organizations by an RIR or ISPs. An example of a second possibility is that Org-A has an allocation of a /16. It has suballocated a /22 to one of its subsidiaries, and subsequently sold the subsidiary to another Org-B. For ease of keeping the /22 subnet up and running without service disruption, the /22 subprefix is allowed to be transferred in the acquisition process. Now the /22 subprefix originates from a different AS and is serviced by a different ETR (as compared to the parent \16 prefix). We are in the process of performing an analysis of RIR allocation data and are aware of other studies (notably at UCLA) that are also performing similar analysis to quantify the frequency of occurrence of the holes. We feel that the problem that has been addressed is a realistic one, and the proposed scheme would help reduce the overheads associated with the mapping distribution system.
上記のコメント（1）について、それらの穴を有する配分をもたらす状況が生じ得る方法に関する複数の可能性があります。次のようにこれらの可能性のうちの1つの例があります。 ORG-Aは、歴史的に互いに隣接している時間の経過複数/ 20S / 22S、及び/ 24Sを受けました。現時点では、これらのプレフィックスが/ 16までが、基礎となる/ 24Sのほんの一部がRIRやISPが歴史的に他の組織に別の場所に割り当てられているという事実のためにすべての集計だろう。第二の可能性の一例は、ORG-Aは、/ 16の割り当てを有することです。それは、その子会社のいずれかに/ 22 suballocated、その後、別の組織-Bに子会社を売却しました。 / 22サブネットアップを維持し、サービスを中断することなく実行を容易にするために、/ 22サブプレフィクスは、取得プロセスに転送することが許可されています。今/ 22サブプレフィクスが異なるASから発信され、（親\ 16プレフィックスと比較して）異なるETRによってサービスされます。我々は、RIR割当データの解析を行う処理であり、また、穴の発生頻度を定量化するために同様の分析を行っている（特に、UCLAで）他の研究を認識しています。我々は対処された問題は、現実的なものであり、提案方式は、マッピング配信システムに関連するオーバーヘッドを減らすのに役立つだろうと感じています。
Regarding comment (2) above, the suggested modification to Approach 2 would be definitely beneficial. In fact, we feel that it would be fairly straightforward to dynamically use Approach 1 or Approach 2 (with the suggested modification), depending on whether there are only a few (e.g., <=5) or many (e.g., >5) more specifics, respectively. The suggested modification of notifying the mask-length of the more specifics in the map response is indeed very helpful because then the ITR would not have to resend a map-query for EID addresses that match the EID address in the previous query up to at least mask-length bit positions. There can be a two-bit field in the map response that would be interpreted as follows.
コメントについて（2）上記、2に近づく提案の変更は間違いなく有益であろう。実際には、我々はわずか数（例えば、あるかどうかに応じて、動的に（提案修飾を有する）アプローチ1やアプローチ2を使用するためにかなり簡単だろうと感じ<= 5）または多くの（例えば、> 5）より仕様、それぞれ。その後、ITRは、少なくともまで、前のクエリ内のEIDアドレスと一致EIDアドレスのマップクエリーを再送信する必要がないので、マップ応じて、より詳細のマスク長に通知の推奨変更は確かに非常に便利ですマスク長のビット位置。次のように解釈される地図応答の2ビット・フィールドが存在することができます。
(a) value 00: there are no more specifics
（a）は、値00：それ以上の詳細はありません
(b) value 01: there are more specifics and their exact information follows in additional map-responses
（b）は、値01が、より具体的であり、それらの正確な情報は、追加のマップ応答において、以下
(c) value 10: there are more-specifics and the mask-length of the next more-specific is indicated in the current map-response.
（C）値10：以上、具体的かつ現在のマップ応答において示されている次のより固有のマスクの長さがあります。
An additional field will be included that will be used to specify the mask-length of the next more-specific in the case of value 10 (case (c) above).
追加のフィールドが値10（ケース（C）上記）の場合には、次のより固有のマスクの長さを指定するために使用されることが含まれます。
As the Internet continues its rapid growth, router memory size and CPU cycle requirements are outpacing feasible hardware upgrade schedules. We propose to solve this problem by applying aggregation with increasing scopes to gradually evolve the routing system towards a scalable structure. At each evolutionary step, our solution is able to interoperate with the existing system and provide immediate benefits to adopters to enable deployment. This document summarizes the need for an evolutionary design, the relationship between our proposal and other revolutionary proposals, and the steps of aggregation with increasing scopes. Our detailed proposal can be found in [Evolution].
インターネットは急速な成長を続けると、ルータのメモリサイズやCPUサイクル要件は、実現可能なハードウェアのアップグレードのスケジュールを上回っています。私たちは、徐々に拡張性の高い構造に向けてルーティングシステムを進化させスコープの増加に伴って凝集を適用することによって、この問題を解決することを提案します。各進化のステップでは、当社のソリューションは、既存システムとの相互運用と展開を可能にするために採用に直接的なメリットを提供することができます。この文書では、進化的設計の必要性、私たちの提案およびその他の革新的な提案との関係、および増加スコープと凝集の手順をまとめたもの。私たちの詳細な提案は[進化]で見つけることができます。
Multiple different views exist regarding the routing scalability problem. Networks differ vastly in goals, behavior, and resources, giving each a different view of the severity and imminence of the scalability problem. Therefore, we believe that, for any solution to be adopted, it will start with one or a few early adopters and may not ever reach the entire Internet. The evolutionary approach recognizes that changes to the Internet can only be a gradual process with multiple stages. At each stage, adopters are driven by and rewarded with solving an immediate problem. Each solution must be deployable by individual networks who deem it necessary at a time they deem it necessary, without requiring coordination from other networks, and the solution has to bring immediate relief to a single first-mover.
複数の異なるビューは、ルーティングスケーラビリティの問題について存在します。ネットワークはそれぞれにスケーラビリティの問題の深刻さと切迫の別のビューを与え、目標、行動、およびリソースに大幅に異なります。したがって、我々はすべてのソリューションに採用されるように、と信じて、それが1つまたは少数のアーリーアダプターを開始し、これまで、インターネット全体に達していなくてもよいです。進化のアプローチは、インターネットへの変更のみを複数の段階で漸進的なプロセスであることを認識しています。各段階で、採用がによって駆動され、当面の問題を解決するに報わ。各ソリューションは、他のネットワークからの調整を必要とせずに、彼らは必要があると認めるときに必要があると認める個々のネットワークによって展開可能でなければならない、とソリューションは、単一の先発に即時の救済をもたらすことがあります。
Most proposals take a revolutionary approach that expects the entire Internet to eventually move to some new design whose main benefits would not materialize until the vast majority of the system has been upgraded; their incremental deployment plan simply ensures interoperation between upgraded and legacy parts of the system. In contrast, the evolutionary approach depicts a system where changes may happen here and there as needed, but there is no dependency on the system as a whole making a change. Whoever takes a step forward gains the benefit by solving his own problem, without depending on others to take actions. Thus, deployability includes not only interoperability, but also the alignment of costs and gains.
ほとんどの提案は、インターネット全体が最終的にその主な利点システムの大半がアップグレードされるまで、マテリアライズではないでしょういくつかの新しいデザインに移動することを期待革命的なアプローチを取ります。その増分展開計画は、単にシステムのアップグレードとレガシー部品間の相互運用を保証します。これとは対照的に、進化論的なアプローチは、必要に応じて変更があちこちで起こる可能性のあるシステムを示しているが、変更を行うシステム全体としての依存性はありません。誰でも一歩前進を取ることはアクションを実行するために他人に依存することなく、自分自身の問題を解くことによって利益を得ます。このように、展開性は、相互運用性、だけでなく、コストと利益のアライメントだけでなく、。
The main differences between our approach and more revolutionary map-and-encap proposals are: (a) we do not start with a pre-defined boundary between edge and core; and (b) each step brings immediate benefits to individual first-movers. Note that our proposal neither interferes nor prevents any revolutionary host-based solutions such as ILNP from being rolled out. However, host-based solutions do not bring useful impact until a large portion of hosts have been upgraded. Thus, even if a host-based solution is rolled out in the long run, an evolutionary solution is still needed for the near term.
我々のアプローチと、より革新的な地図と-ENCAP提案の主な違いは次のとおりである。（a）当社は、エッジとコアの間で事前に定義された境界で始まりません。および（b）の各ステップは、個々の最初の発動機への直接的なメリットをもたらします。私たちの提案は邪魔しないでも展開されることから、このようなILNPなど任意の革命的なホストベースのソリューションを防ぎどちらことに注意してください。ホストの大部分がアップグレードされるまでただし、ホストベースのソリューションは、有益な影響をもたらすことはありません。このように、ホストベースのソリューションは、長期的にロールアウトされた場合でも、進化的な解決策はまだ短期的に必要です。
Aggregating many routing entries to a fewer number is a basic approach to improving routing scalability. Aggregation can take different forms and be done within different scopes. In our design, the aggregation scope starts from a single router, then expands to a single network and neighbor networks. The order of the following steps is not fixed but is merely a suggestion; it is under each individual network's discretion which steps they choose to take based on their evaluation of the severity of the problems and the affordability of the solutions.
より少ない数に多くのルーティングエントリを集約すると、ルーティングのスケーラビリティを改善する基本的なアプローチです。集計は、異なる形態をとることができ、異なるスコープ内で行われます。私たちのデザインでは、集計範囲は、単一のルータから開始し、その後、単一のネットワークと隣接ネットワークに展開されます。次のステップの順序は固定ではなく、単なる提案でされていません。それは彼らが彼らの問題の深刻度の評価およびソリューションの手頃な価格に基づいて取ることを選択し、手順、個々のネットワークの裁量下にあります。
1. FIB Aggregation (FA) in a single router. A router algorithmically aggregates its FIB entries without changing its RIB or its routing announcements. No coordination among routers is needed, nor any change to existing protocols. This brings scalability relief to individual routers with only a software upgrade.
単一のルータ1. FIB集計（FA）。ルータは、アルゴリズムそのRIBまたはそのルーティングアナウンスを変更することなく、そのFIBエントリを集約します。ルータの間には調整が必要なく、また既存のプロトコルに変更されます。これは、ソフトウェアのアップグレードで、個々のルータにスケーラビリティの救済をもたらします。
2. Enabling 'best external' on Provider Edge routers (PEs), Autonomous System Border Routers (ASBRs), and Route Reflectors (RRs), and turning on next-hop-self on RRs. For hierarchical networks, the RRs in each Point of Presence (PoP) can serve as a default gateway for nodes in the PoP, thus allowing the non-RR nodes in each PoP to maintain smaller routing tables that only include paths that egress that PoP. This is known as 'topology-based mode' Virtual Aggregation, and can be done with existing hardware and configuration changes only. Please see [Evolution_Grow_Presentation] for details.
2.有効にするプロバイダーエッジルータ（PES）、自律システム境界ルータ（ASBRは）、およびルートリフレクタ（RRS）の「最高の外部」とのRRにネクストホップ自己をオンにします。階層型ネットワークの場合、存在する各点（POP）内のRRは、このように各POP内の非RRノードが唯一のPoPことで発信経路を含む小さいルーティングテーブルを維持することができ、POP内のノードのデフォルトゲートウェイとして機能することができます。これは、「トポロジー・ベースモード」の仮想集約として知られており、唯一の既存のハードウェアおよび構成の変更を行うことができます。詳細については、[Evolution_Grow_Presentation]を参照してください。
3. Virtual Aggregation (VA) in a single network. Within an AS, some fraction of existing routers are designated as Aggregation Point Routers (APRs). These routers are either individually or collectively maintain the full FIB table. Other routers may suppress entries from their FIBs, instead forwarding packets to APRs, which will then tunnel the packets to the correct egress routers. VA can be viewed as an intra-domain map-and-encap system to provide the operators with a control mechanism for the FIB size in their routers.
単一のネットワークで3.仮想集約（VA）。 AS内では、既存のルータのいくつかの画分を集約ポイントルータ（のAPR）として指定されています。これらのルータは、個別にまたは総称して、完全なFIBテーブルを維持しています。他のルータは、代わりのAPRにパケットを転送し、それらのFIBからエントリを抑制することができるであろう次いでトンネル正しい出口ルータにパケット。 VAは、そのルータにFIBサイズの制御機構をオペレータに提供するために、ドメイン内のマップ・アンド・ENCAPシステムとみなすことができます。
4. VA across neighbor networks. When adjacent networks have VA deployed, they can go one step further by piggybacking egress router information on existing BGP announcements, so that packets can be tunneled directly to a neighbor network's egress router. This improves packet delivery performance by performing the encapsulation/decapsulation only once across these neighbor networks, as well as reducing the stretch of the path.
隣接ネットワーク全体で4 VA。隣接するネットワークがVA展開している場合は、パケットが隣接ネットワークの出口ルータに直接トンネリングすることができるように、彼らは、既存のBGPアナウンスメントの出口ルータ情報をピギーバックすることにより、さらに一歩行くことができます。これは、これらの隣接ネットワークを横切って一度だけカプセル化/デカプセル化を行うこと、ならびにパスのストレッチを低減することにより、パケット配送のパフォーマンスを向上させることができます。
5. Reducing RIB Size by separating the control plane from the data plane. Although a router's FIB can be reduced by FA or VA, it usually still needs to maintain the full RIB to produce complete routing announcements to its neighbors. To reduce the RIB size, a network can set up special boxes, which we call controllers, to take over the External BGP (eBGP) sessions from border routers. The controllers receive eBGP announcements, make routing decisions, and then inform other routers in the same network of how to forward packets, while the regular routers just focus on the job of forwarding packets. The controllers, not being part of the data path, can be scaled using commodity hardware.
5.データ・プレーンからコントロールプレーンを分離することによりRIBサイズを縮小します。ルータのFIBは、FAまたはVAによって減少させることができるが、通常、まだその隣人への完全なルーティングアナウンスメントを生成するために、完全なRIBを維持する必要があります。 RIBのサイズを小さくするために、ネットワークは、我々は境界ルータから外部BGP（eBGPの）セッションを引き継ぐために、コントローラを呼び出す特別な箱を、設定することができます。コントローラは、通常のルータは単にパケット転送の仕事に焦点を当てながら、パケットを転送する方法の同じネットワーク内の他のルータに通知し、その後、ルーティング決定を行い、かつ、eBGPのアナウンスを受け取ります。コントローラは、データパスの一部ではないが、コモディティ・ハードウェアを使用してスケーリングすることができます。
6. Insulating forwarding routers from routing churn. For routers with a smaller RIB, the rate of routing churn is naturally reduced. Further reduction can be achieved by not announcing failures of customer prefixes into the core, but handling these failures in a data-driven fashion, e.g., a link failure to an edge network is not reported unless and until there are data packets that are heading towards the failed link.
チャーンルーティングから6絶縁転送ルータ。小さなリブをルータに、ルーティング解約率が自然に減少します。さらに低下すると、向かっているデータパケットがある場合を除きとなるまでエッジネットワークへのリンク障害が報告されていない、例えば、コアに顧客プレフィックスの失敗を発表しますが、データ駆動型の方法で、これらの障害を処理していないことによって達成することができます故障したリンク。
[Evolution] [Evolution_Grow_Presentation]
[進化] [Evolution_Grow_Presentation]
All of the RRG proposals that scale the routing architecture share one fundamental approach, route aggregation, in different forms, e.g., LISP removes "edge prefixes" using encapsulation at ITRs, and ILNP achieves the goal by locator rewrite. In this evolutionary path proposal, each stage of the evolution applies aggregation with increasing scopes to solve a specific scalability problem, and eventually the path leads towards global routing scalability. For example, it uses FIB aggregation at the single router level, virtual aggregation at the network level, and then between neighboring networks at the inter-domain level.
ルーティングアーキテクチャを共有する1つの基本的なアプローチをスケーリングRRG提案の全て、ルート集約は、異なる形態で、例えば、LISPは、ITRのでカプセル化を使用して「エッジプレフィックス」を削除し、ILNPロケータ書き換えによって目標を達成します。この進化のパス提案では、進化の各段階は、特定のスケーラビリティの問題を解決するためのスコープの増加に伴って凝集を適用し、最終的にパスがグローバルルーティングスケーラビリティに向けてつながります。例えば、ドメイン間のレベルで隣接ネットワーク間次いで、ネットワークレベルでFIBの単一ルータレベルでの凝集、仮想集合を使用し、。
Compared to other proposals, this proposal has the lowest hurdle to deployment, because it does not require that all networks move to use a global mapping system or upgrade all hosts, and it is designed for each individual network to get immediate benefits after its own deployment.
それは、すべてのネットワークがグローバルマッピングシステムを使用するか、またはすべてのホストをアップグレードするために移動することを必要としないので、他の提案と比較すると、この提案は、展開に最低のハードルがあり、そして独自の展開後すぐに利益を得るために、個々のネットワークのために設計されています。
Criticisms of this proposal fall into two types. The first type concerns several potential issues in the technical design as listed below:
この提案の批判は、2つのタイプに分類されます。以下に示すように、第1のタイプは、技術的な設計では、いくつかの潜在的な問題を懸念します：
1. FIB aggregation, at level-3 and level-4, may introduce extra routable space. Concerns have been raised about the potential routing loops resulting from forwarding otherwise non-routable packets, and the potential impact on Reverse Path Forwarding (RPF) checking. These concerns can be addressed by choosing a lower level of aggregation and by adding null routes to minimize the extra space, at the cost of reduced aggregation gain.
1. FIB凝集は、レベル3とレベル4で、余分なルーティング可能な空間を導入することができます。問題は、そうでなければ、非ルーティング可能なパケットを転送から生じる潜在的なルーティングループ、逆方向パス転送（RPF）に対する潜在的影響確認について提起されています。これらの懸念は、集計の低いレベルを選択することによって、および減少した集約ゲインを犠牲にし、余分なスペースを最小限にするために、ヌルのルートを追加することによって対処することができます。
2. Virtual Aggregation changes the traffic paths in an ISP network, thereby introducing stretch. Changing the traffic path may also impact the reverse path checking practice used to filter out packets from spoofed sources. More analysis is need to identify the potential side-effects of VA and to address these issues.
2.仮想集約ことによりストレッチを導入、ISPネットワーク内のトラフィックの経路を変更します。トラフィックの経路を変更しても、スプーフィングされたソースからのパケットをフィルタリングするために使用される実際の検査逆の経路に影響を与える可能性があります。より多くの分析では、VAの潜在的な副作用を識別し、これらの問題に対処する必要があります。
3. The current Virtual Aggregation description is difficult to understand, due to its multiple options for encapsulation and popular prefix configurations, which makes the mechanism look overly complicated. More thought is needed to simplify the design and description.
3.現在の仮想集約記述が原因のメカニズムは非常に複雑に見えるのカプセル化と人気のプレフィックス設定のための複数のオプションに、理解することは困難です。より多くの思考は、デザインや説明を簡略化するために必要とされます。
4. FIB Aggregation and Virtual Aggregation may require additional operational cost. There may be new design trade-offs that the operators need to understand in order to select the best option for their networks. More analysis is needed to identify and quantify all potential operational costs.
4. FIB集約と仮想集約は、追加の運用コストを必要とするかもしれません。事業者は自社のネットワークに最適なオプションを選択するために理解する必要がある新しいデザインのトレードオフがあるかもしれません。より多くの分析がすべての潜在的な運用コストを識別し、定量化するために必要とされます。
5. In contrast to a number of other proposals, this solution does not provide mobility support. It remains an open question as to whether the routing system should handle mobility.
5.他の提案の数とは対照的に、このソリューションは、モビリティサポートを提供していません。これは、ルーティングシステムは、モビリティを扱うべきかどうかなど、未解決の問題のまま。
The second criticism is whether deploying quick fixes like FIB aggregation would alleviate scalability problems in the short term and reduce the incentives for deploying a new architecture; and whether an evolutionary approach would end up with adding more and more patches to the old architecture, and not lead to a fundamentally new architecture as the proposal had expected. Though this solution may get rolled out more easily and quickly, a new architecture, if/ once deployed, could solve more problems with cleaner solutions.
第二の批判は、FIBの集約などのクイックフィックスを展開すると、短期的にはスケーラビリティの問題を軽減し、新しいアーキテクチャを導入するためのインセンティブを減らすかどうかです。そして進化のアプローチは、古いアーキテクチャに、より多くのパッチを追加することで終わる、と提案が予想していたとして根本的に新しいアーキテクチャにはつながらないでしょうか。 /一度展開されている場合、このソリューションは、より簡単かつ迅速に新しいアーキテクチャを展開れるかもしれませんが、きれいソリューションで多くの問題を解決することができます。
No rebuttal was submitted for this proposal.
いかなる反論は、この提案のために提出されませんでした。
Name-based sockets are an evolution of the existing address-based sockets, enabling applications to initiate and receive communication sessions based on the use of domain names in lieu of IP addresses. Name-based sockets move the existing indirection from domain names to IP addresses from its current position in applications down to the IP layer. As a result, applications communicate exclusively based on domain names, while the discovery, selection, and potentially in-session re-selection of IP addresses is centrally performed by the IP stack itself.
名前ベースのソケットは、IPアドレスの代わりにドメイン名の使用に基づいて、通信セッションを開始し、受信するためのアプリケーションを有効にする、既存のアドレスベースのソケットの進化です。名前ベースのソケットは、IP層までのアプリケーションで現在の位置からIPアドレスへのドメイン名から既存の間接を移動します。 IPアドレスの発見、選択、および潜在的にセッションの再選択が中央IPスタック自体によって行われている間その結果、アプリケーションは、ドメイン名に基づいて排他的に通信します。
Name-based sockets help mitigate the Internet routing scalability problem by separating naming and addressing more consistently than what is possible with the existing address-based sockets. This supports IP address aggregation because it simplifies the use of IP addresses with high topological significance, as well as the dynamic replacement of IP addresses during network-topological and host-attachment changes.
名前ベースのソケットは、ネーミングを分離し、より一貫して、既存のアドレスベースのソケットで可能であるものよりも対処することにより、インターネットルーティングのスケーラビリティの問題を軽減するのに役立ちます。それは高い位相的意義だけでなく、ネットワーク・トポロジカルとホスト・アタッチメントの変更時にIPアドレスを動的に交換してIPアドレスの使用を簡素化するため、これはIPアドレスの集約をサポートしています。
A particularly positive effect of name-based sockets on Internet routing scalability is the new incentives for edge network operators to use provider-assigned IP addresses, which are more aggregatable than the typically preferred provider-independent IP addresses. Even though provider-independent IP addresses are harder to get and more expensive than provider-assigned IP addresses, many operators desire provider-independent addresses due to the high indirect cost of provider-assigned IP addresses. This indirect cost is comprised of both difficulties in multihoming, and tedious and largely manual renumbering upon provider changes.
エッジネットワークオペレータは、典型的には、好適なプロバイダ非依存IPアドレスよりも集約されているプロバイダに割り当てられたIPアドレスを使用するためのインターネット・ルーティング・スケーラビリティ上の名前ベースのソケットの特に正の効果は、新たなインセンティブです。プロバイダに依存しないIPアドレスを取得することが困難とプロバイダーによって割り当てられたIPアドレスよりも高価であるにもかかわらず、多くのオペレータが原因プロバイダーによって割り当てられたIPアドレスの高い間接的なコストのために、プロバイダに依存しないアドレスを望みます。この間接的なコストは、プロバイダの変更時にマルチホーミング、そして退屈で、主にマニュアルリナンバリングの両方の難しさで構成されています。
Name-based sockets reduce the indirect cost of provider-assigned IP addresses in three ways, and hence make the use of provider-assigned IP addresses more acceptable: (1) They enable fine-grained and responsive multihoming. (2) They simplify renumbering by offering an easy means to replace IP addresses in referrals with domain names. This helps avoiding updates to application and operating system configurations, scripts, and databases during renumbering. (3) They facilitate low-cost solutions that eliminate renumbering altogether. One such low-cost solution is IP address translation, which in combination with name-based sockets loses its adverse impact on applications.
名前ベースのソケットは次の3つの方法で、プロバイダによって割り当てられたIPアドレスの間接的なコストを削減し、ひいてはプロバイダーによって割り当てられたIPの使用がより受け入れに対処します：（1）彼らは、きめの細かいおよび応答マルチホーミングを有効にします。 （2）これらは、ドメイン名を持つ紹介してIPアドレスを交換する簡単な手段を提供することによって、リナンバリングを簡素化します。これは、リナンバリングの際に、アプリケーションとオペレーティングシステム構成、スクリプト、およびデータベースへの更新を回避することができます。 （3）それらは、完全リナンバリング排除低コストのソリューションを容易にします。そのような低コストのソリューションは、名前ベースのソケットとの組み合わせでのアプリケーションへの悪影響を失い、IPアドレス変換、です。
The prerequisite for a positive effect of name-based sockets on Internet routing scalability is their adoption in operating systems and applications. Operating systems should be augmented to offer name-based sockets as a new alternative to the existing address-based sockets, and applications should use name-based sockets for their communications. Neither an instantaneous, nor an eventually complete transition to name-based sockets is required, yet the positive effect on Internet routing scalability will grow with the extent of this transition.
インターネットルーティングスケーラビリティに名前ベースのソケットの肯定的な効果のための前提条件は、オペレーティングシステムやアプリケーションでの採用です。オペレーティング・システムは、既存のアドレスベースのソケットに新しい代替として名前ベースのソケットを提供するように拡張されなければならない、とアプリケーションは、その通信に名前ベースのソケットを使用する必要があります。瞬間、また名前ベースのソケットに最終的に完全に移行する必要はありません、まだインターネットルーティング拡張性にプラスの効果は、この移行の程度と成長しますどちらも。
Name-based sockets were hence designed with a focus on deployment incentives, comprising both immediate deployment benefits as well as low deployment costs. Name-based sockets provide a benefit to application developers because the alleviation of applications from IP address management responsibilities simplifies and expedites application development. This benefit is immediate owing to the backwards compatibility of name-based sockets with legacy applications and legacy peers. The appeal to application developers, in turn, is an immediate benefit for operating system vendors who adopt name-based sockets.
名前ベースのソケットは、したがって即時展開のメリットだけでなく、低導入コストの両方を含む、導入のインセンティブを重視して設計されました。 IPアドレスの管理責任からのアプリケーションの軽減を簡素化し、アプリケーション開発を促進するため、名前ベースのソケットは、アプリケーション開発者に利益を提供します。この利点は、レガシーアプリケーションやレガシーピアと名前ベースのソケットの後方互換性のために即時です。アプリケーション開発者へのアピールは、今度は、名前ベースのソケットを採用し、オペレーティング・システム・ベンダにとって直接的な利点です。
Name-based sockets furthermore minimize deployment costs: Alternative techniques to separate naming and addressing provide applications with "surrogate IP addresses" that dynamically map onto regular IP addresses. A surrogate IP address is indistinguishable from a regular IP address for applications, but does not have the topological significance of a regular IP address. Mobile IP and the Host Identity Protocol are examples of such separation techniques. Mobile IP uses "home IP addresses" as surrogate IP addresses with reduced topological significance. The Host Identity Protocol uses "host identifiers" as surrogate IP addresses without topological significance. A disadvantage of surrogate IP addresses is their incurred cost in terms of extra administrative overhead and, for some techniques, extra infrastructure. Since surrogate IP addresses must be resolvable to the corresponding regular IP addresses, they must be provisioned in the DNS or similar infrastructure. Mobile IP uses a new infrastructure of home agents for this purpose, while the Host Identity Protocol populates DNS servers with host identities. Name-based sockets avoid this cost because they function without surrogate IP addresses, and hence without the provisioning and infrastructure requirements that accompany surrogate addresses.
ネーミングおよび動的正規のIPアドレスにマッピング「代理IPアドレス」を持つアプリケーションを提供取り組む分離するために別の技術：名前ベースのソケットは、さらに、展開コストを最小限に抑えることができます。代理IPアドレスは、アプリケーションのための通常のIPアドレスと区別できないが、通常のIPアドレスのトポロジカルな意義を持っていません。モバイルIPとホスト識別プロトコルは、このような分離技術の例です。モバイルIPは減少トポロジカルな意義を持つ代理IPアドレスとして「ホームIPアドレス」を使用しています。ホスト識別プロトコルは、トポロジー的意義のない代理IPアドレスとして「ホスト識別子」を使用しています。代理IPアドレスの欠点は、余分な管理オーバーヘッドと、いくつかの技術のため、余分なインフラの面で彼らの負担費用です。代理IPアドレスは、対応する正規のIPアドレスに解決できなければなりませんので、彼らは、DNSまたは類似のインフラストラクチャにプロビジョニングする必要があります。ホストアイデンティティプロトコルは、ホストのアイデンティティを持つDNSサーバを移入しながら、モバイルIPは、この目的のためにホームエージェントの新しいインフラストラクチャを使用しています。名前ベースのソケットは、彼らが代理IPアドレスがなくても機能するので、このコストを回避し、ひいては代理アドレスを伴うプロビジョニング、インフラ要件なし。
Certainly, some edge networks will continue to use provider-independent addresses despite name-based sockets, perhaps simply due to inertia. But name-based sockets will help reduce the number of those networks, and thus have a positive impact on Internet routing scalability.
確かに、いくつかのエッジネットワークは、おそらく単に慣性によって、名前ベースのソケットにもかかわらず、プロバイダに依存しないアドレスを継続して使用します。しかし、名前ベースのソケットは、これらのネットワークの数を減らすため、インターネットルーティング拡張性にプラスの影響を与えることになります。
A more comprehensive description of name-based sockets can be found in [Name_Based_Sockets].
名前ベースのソケットのより包括的な説明は、[Name_Based_Sockets]に見出すことができます。
[Name_Based_Sockets]
[Name_Based_Sockets]
Name-based sockets contribution to the routing scalability problem is to decrease the reliance on PI addresses, allowing a greater use of PA addresses, and thus a less fragmented routing table. It provides end hosts with an API which makes the applications address-agnostic. The name abstraction allows the hosts to use any type of locator, independent of format or provider. This increases the motivation and usability of PA addresses. Some applications, in particular bootstrapping applications, may still require hard coded IP addresses, and as such will still motivate the use of PI addresses.
ルーティングのスケーラビリティの問題に名前ベースのソケットの寄与は、PIアドレスへの依存を減らすPAアドレスのより大きな利用を可能にし、従ってより少ない断片化されたルーティングテーブルです。これは、アプリケーションのアドレスに依存しない可能APIとエンドホストを提供します。名前の抽象化は、ホストがフォーマットまたはプロバイダから独立し、ロケータの任意の型を使用することを可能にします。これはPAアドレスの動機と使いやすさを向上させます。一部のアプリケーションでは、特定のブートストラップアプリケーションでは、まだハードコード化されたIPアドレスを必要とするかもしれない、そのようにまだPIアドレスの使用を動機となります。
The main incentives and drivers are geared towards the transition of applications to the name-based sockets. Adoption by applications will be driven by benefits in terms of reduced application development cost. Legacy applications are expected to migrate to the new API at a slower pace, as the name-based sockets are backwards compatible, this can happen in a per-host fashion. Also, not all applications can be ported to a FQDN dependent infrastructure, e.g., DNS functions. This hurdle is manageable, and may not be a definite obstacle for the transition of a whole domain, but it needs to be taken into account when striving for mobility/multihoming of an entire site. The transition of functions on individual hosts may be trivial, either through upgrades/changes to the OS or as linked libraries. This can still happen incrementally and independently, as compatibility is not affected by the use of name-based sockets.
メインインセンティブやドライバは、名前ベースのソケットへのアプリケーションの移行に向けています。アプリケーションによる採用が減少し、アプリケーション開発コストの面でメリットによって駆動されます。レガシーアプリケーションは、名前ベースのソケットは後方互換性があるとして、これはホストごとの形で発生する可能性が、遅いペースで新しいAPIに移行することが期待されます。また、全てのアプリケーションがFQDN依存インフラ、例えば、DNS機能に移植することができます。このハードルは管理可能であり、ドメイン全体の移行のための明確な障害ではないかもしれないが、それはサイト全体のモビリティ/マルチホーミングのために努力する際に考慮される必要があります。個々のホスト上の機能の遷移は、OSのアップグレード/変更を介して、またはリンクされたライブラリーとしてのいずれかで、些細であってもよいです。互換性が名前ベースのソケットの使用に影響されないように、これはまだ、漸進的かつ独立して発生する可能性があります。
Name-based sockets rely on the transition of individual applications and are backwards compatible, so they do not require bilateral upgrades. This allows each host to migrate its applications independently. Name-based sockets may make an individual client agnostic to the networking medium, be it PA/PI IP-addresses or in a the future an entirely different networking medium. However, an entire edge-network, with internal and external services will not be able to make a complete transition in the near future. Hence, even if a substantial fraction of the hosts in an edge-network use name-based sockets, PI addresses may still be required by the edge-network. In short, new services may be implemented using name-based sockets, old services may be ported. Name-based sockets provide an increased motivation to move to PA-addresses as actual provider independence relies less and less on PI-addressing.
名前ベースのソケットは、個々のアプリケーションの移行に依存しており、下位互換性があるので、彼らは二国間のアップグレードを必要としません。これは、各ホストは独立してそのアプリケーションを移行することができます。名前ベースのソケットは、ネットワーキング媒体にとらわれない、個々のクライアントを作る、それPA / PI IP-アドレスまたは将来的には全く異なるネットワーク媒体であってもよいです。しかし、内部および外部のサービスと全体のエッジ・ネットワークは、近い将来に完全に移行を行うことはできません。従って、エッジネットワークにおけるホストのかなりの部分は、名前ベースのソケットを使用する場合でも、PIアドレスが依然としてエッジネットワークによって必要とされてもよいです。要するに、新しいサービスは、古いサービスを移植することができる、名前ベースのソケットを使用して実施することができます。名前ベースのソケットは、実際のプロバイダの独立性がPI-アドレッシングに少なく依存しているとして、PA-アドレスに移動するための増加動機を提供しています。
No rebuttal was submitted for this proposal.
いかなる反論は、この提案のために提出されませんでした。
16. Routing and Addressing in Networks with Global Enterprise Recursion (IRON-RANGER)
16.ルーティングとグローバル企業再帰（IRON-RANGER）とネットワークにおけるアドレッシング
RANGER is a locator/identifier separation approach that uses IP-in-IP encapsulation to connect edge networks across transit networks such as the global Internet. End systems use endpoint interface identifier (EID) addresses that may be routable within edge networks but do not appear in transit network routing tables. EID to Routing
レンジャーは、グローバルなインターネットのような中継ネットワークを横切ってエッジ・ネットワークを接続するIP-in-IPカプセル化を使用してロケータ/識別子分離手法です。エンドシステムは、エッジネットワーク内でルーティング可能であってもよいが、トランジットネットワークルーティングテーブルに表示されていないエンドポイント・インタフェース識別子（EID）アドレスを使用します。ルーティングにEID
Locator (RLOC) address bindings are instead maintained in mapping tables and also cached in default router FIBs (i.e., very much the same as for the global DNS and its associated caching resolvers). RANGER enterprise networks are organized in a recursive hierarchy with default mappers connecting lower layers to the next higher layer in the hierarchy. Default mappers forward initial packets and push mapping information to lower-tier routers and end systems through secure redirection.
ロケータ（RLOC）アドレスバインディングではなく、マッピングテーブルに維持され、また、デフォルトルータのFIBにキャッシュされる（すなわち、非常にグローバルDNSおよびその関連するキャッシュリゾルバと同じ）。レンジャー企業ネットワークは、階層内の次の上位層に下層を接続するデフォルトのマッパーと再帰階層に編成されています。前方デフォルトのマッパー初期パケットと安全なリダイレクトを介して下部層のルータとエンドシステムへのマッピング情報をプッシュします。
RANGER is an architectural framework derived from the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).
RANGERは、プロトコル（ISATAP）をアドレス指定、サイト内の自動トンネルの由来アーキテクチャフレームワークです。
o provides a scalable routing system alternative in instances where dynamic routing protocols are impractical
oはダイナミックルーティングプロトコルは実用的でない例において、スケーラブルなルーティングシステムの代替を提供します
o naturally supports a recursively-nested "network-of-networks" (or, "enterprise-within-enterprise") hierarchy
O自然に再帰的にネスト「の-ネットワークのネットワーク」（または、「企業内・企業」）の階層をサポート
o uses asymmetric security mechanisms (i.e., secure neighbor discovery) to secure router discovery and the redirection mechanism
Oは、ルータ発見およびリダイレクション機構を固定するために、非対称のセキュリティ機構（即ち、セキュア近隣探索）を使用し
o can quickly detect path failures and pick alternate routes
Oすばやくパス障害を検出し、代替ルートを選ぶことができます
o naturally supports provider-independent addressing
O自然プロバイダに依存しないアドレス指定をサポートしています
o support for site multihoming and traffic engineering
サイトマルチホーミングとトラフィックエンジニアリングのためのOサポート
o ingress filtering for multihomed sites
マルチホームのサイトのためのOイングレスフィルタリング
o mobility-agile through explicit cache invalidation (much more reactive than dynamic DNS)
（ダイナミックDNSよりもはるかに反応性）明示的なキャッシュの無効化によるOモビリティアジャイル
o supports neighbor discovery and neighbor unreachability detection over tunnels
oはトンネルを介し近隣探索および近隣到達不能検出をサポートしています
o no changes to end systems
エンドシステムへの変更なしO
o no changes to most routers
ほとんどのルータへの変更なしO
o supports IPv6 transition o compatible with true identity/locator split mechanisms such as HIP (i.e., packets contain a HIP Host Identity Tag (HIT) as an end system identifier, IPv6 address as endpoint interface identifier (EID) in the inner IP header and IPv4 address as Routing LOCator (RLOC) in the outer IP header)
oは内側のIPヘッダ内のエンドポイントインターフェイス識別子（EID）のようなHIPなどの真のアイデンティティ/ロケータ分離機構と互換性のO IPv6への移行（すなわち、パケットがエンド・システム識別子としてHIPホストアイデンティティタグ（HIT）を含む、IPv6アドレスをサポートして外側のIPヘッダ内のルーティングロケータ（RLOC）としてIPv4アドレス）
o prototype code available
プロトタイプのコードが利用できるO
o new code needed in enterprise border routers
企業の境界ルータに必要なO新しいコード
o locator/path liveness detection using RFC 4861 neighbor unreachability detection (i.e., extra control messages, but data-driven) [RFC4861]
RFC 4861近隣到達不能検出（即ち、余分な制御メッセージが、データ駆動型）を用いてOロケータ/パスライブネス検出[RFC4861]
[IRON] [RANGER_Scen] [VET] [SEAL] [RFC5201] [RFC5214] [RFC5720]
[IRON] [RANGER_Scen] [VET] [SEAL] [RFC5201]、[RFC5214]、[RFC5720]
The RANGER architectural framework is intended to be applicable for a Core-Edge Separation (CES) architecture for scalable routing, using either IPv4 or IPv6 -- or using both in an integrated system which may carry one protocol over the other.
又は使用して、両方の他の上の1つのプロトコルを搬送することができる統合システムに - RANGERアーキテクチャフレームワークは、IPv4またはIPv6のいずれかを使用して、スケーラブルなルーティングのためのコア・エッジ分離（CES）アーキテクチャに適用可能であることが意図されています。
However, despite [IRON] being readied for publication as an experimental RFC, the framework falls well short of the level of detail required to envisage how it could be used to implement a practical scalable routing solution. For instance, the document contains no specification for a mapping protocol, or how the mapping lookup system would work on a global scale.
しかし、[IRON]は実験RFCとして公表のために準備されているにもかかわらず、フレームワークは、実用的なスケーラブルなルーティングソリューションを実装するために使用することができる方法を想定するために必要な詳細レベルの十分下回ります。例えば、文書は、マッピングプロトコルのための仕様が含まれていない、またはマッピング検索システムは、地球規模でどのように動作しますか。
There is no provision for RANGER's ITR-like routers being able to probe the reachability of end-user networks via multiple ETR-like routers -- nor for any other approach to multihoming service restoration.
マルチホーミングサービス復旧に他のアプローチのために - RANGERのITRのようなルータは、複数のETRのようなルータを経由して、エンドユーザのネットワークの到達可能性を探ることができることについての規定はありません。
Nor is there any provision for inbound TE or support of mobile devices which frequently change their point of attachment.
NORインバウンドTEまたは頻繁に添付ファイルの彼らのポイントを変更するモバイルデバイスをサポートするためのいずれかの条項があります。
Therefore, in its current form, RANGER cannot be contemplated as a superior scalable routing solution to some other proposals which are specified in sufficient detail and which appear to be feasible.
したがって、現在の形で、レンジャー十分詳細に指定され、実行可能であると思われるいくつかの他の提案よりも優れたスケーラブルなルーティングソリューションとして考慮することができません。
RANGER uses its own tunneling and PMTUD management protocol: SEAL. Adoption of SEAL in its current form would prevent the proper utilization of jumbo frame paths in the DFZ, which will become the norm in the future. SEAL uses "Packet Too Big" [RFC4443] and "Fragmentation Needed" [RFC0792] messages to the sending host only to fix a preset maximum packet length. To avoid the need for the SEAL layer to fragment packets of this length, this MTU value (for the input of the tunnel) needs to be set significantly below 1500 bytes, assuming the typically ~1500 byte MTU values for paths across the DFZ today. In order to avoid this excessive fragmentation, this value could only be raised to a ~9k byte value at some time in the future where essentially all paths between ITRs and ETRs were jumbo frame capable.
SEAL：RANGERは、独自のトンネリングおよびPMTUD管理プロトコルを使用しています。現在の形でのシールの採用は、将来的には常識となってますDFZでジャンボフレームのパス、の適切な利用を防止するであろう。 SEALは予め設定された最大パケット長を修正するために、「パケット過大」[RFC4443]と「断片化が必要」、送信ホストに[RFC0792]のメッセージを使用しています。この長さのフラグメントパケットにシール層の必要性を回避するために、（トンネルの入力のための）は、このMTU値はDFZ横切るパス今日のために、典型的には〜1500のバイトのMTU値を仮定して、大幅に1500バイト以下に設定する必要があります。この過度の断片化を避けるために、この値は唯一のITRとETRSの間に本質的にすべてのパスができる、ジャンボフレームだった将来のある時点で〜9Kバイトの値まで上げることができました。
The Internet Routing Overlay Network (IRON) [IRON] is a scalable Internet routing architecture that builds on the RANGER recursive enterprise network hierarchy [RFC5720]. IRON bonds together participating RANGER networks using VET [VET] and SEAL [SEAL] to enable secure and scalable routing through automatic tunneling within the Internet core. The IRON-RANGER automatic tunneling abstraction views the entire global Internet DFZ as a virtual Non-Broadcast Multi-Access (NBMA) link similar to ISATAP [RFC5214].
インターネットルーティングオーバーレイネットワーク（鉄）鉄] RANGER再帰エンタープライズネットワーク階層[RFC5720]に基づいて構築スケーラブルなインターネットルーティングアーキテクチャです。 IRON結合が共にインターネットコア内の自動トンネリングを介して安全かつスケーラブルなルーティングを可能にするために、VET [VET]とシール[SEAL]を用いレンジャーネットワークに参加します。鉄RANGER自動トンネリング抽象仮想非ブロードキャストマルチアクセス（NBMA）として全世界的なインターネットDFZのビューは、[RFC5214]をISATAPと同様リンク。
IRON-RANGER is an example of a Core-Edge Separation (CES) system. Instead of a classical mapping database, however, IRON-RANGER uses a hybrid combination of a proactive dynamic routing protocol for distributing highly aggregated Virtual Prefixes (VPs) and an on-demand data driven protocol for distributing more-specific Provider-Independent (PI) prefixes derived from the VPs.
IRON-RANGERは、Core-エッジ分離（CES）システムの一例です。代わりに、古典的なマッピングデータベースが、鉄RANGERは、より特異的なプロバイダ非依存（PI）を分配するためのプロトコルを駆動高度に凝集した仮想プレフィックス（VPS）およびオンデマンドデータを配信するための積極的な動的ルーティングプロトコルのハイブリッド組み合わせを使用しますVPの由来の接頭辞。
The IRON-RANGER hierarchy consists of recursively-nested RANGER enterprise networks joined together by IRON routers that participate in a global BGP instance. The IRON BGP instance is maintained separately from the current Internet BGP Routing LOCator (RLOC) address space (i.e., the set of all public IPv4 prefixes in the Internet). Instead, the IRON BGP instance maintains VPs taken from Endpoint Interface iDentifier (EID) address space, e.g., the IPv6 global unicast address space. To accommodate scaling, only O(10k) -- O(100k) VPs are allocated e.g., using /20 or shorter IPv6 prefixes.
鉄レンジャー階層を再帰的にネストレンジャー企業ネットワークから成るグローバルBGPインスタンスに参加IRONルータによって一緒に接合されています。 IRON BGPインスタンスは、現在のインターネットBGPルーティングロケータ（RLOC）アドレス空間とは別個に維持される（すなわち、インターネット内のすべてのパブリックIPv4プレフィクスのセット）。代わりに、IRON BGPインスタンスは、例えば、エンドポイントインターフェイス識別子（EID）アドレス空間、IPv6グローバルユニキャストアドレス空間から取られたVPを維持します。スケーリング対応するために、唯一のO（10K） - O（100K）のVPは、/ 20またはより短いIPv6プレフィックスを使用して、例えば、割り当てられています。
IRON routers lease portions of their VPs as Provider-Independent (PI) prefixes for customer equipment (CEs), thereby creating a sustainable business model. CEs that lease PI prefixes propagate address mapping(s) throughout their attached RANGER networks and up to VP-owning IRON router(s) through periodic transmission of "bubbles" with authentication and PI prefix information. Routers in RANGER networks and IRON routers that receive and forward the bubbles securely install PI prefixes in their FIBs, but do not inject them into the RIB. IRON routers therefore keep track of only their customer base via the FIB entries and keep track of only the Internet-wide VP database in the RIB.
IRONルータは、持続可能なビジネスモデルを作成し、顧客の機器のプロバイダに依存しない（PI）のプレフィックス（CES）として彼らのVPの部分をリース。 PIプレフィックスをリースCEはそれらに接続さRANGERネットワーク全体の認証およびPIプレフィックス情報で「泡」の定期的な伝送を通じてIRONルータ（複数可）VP-所有するまでのアドレスマッピング（複数可）を伝播します。気泡を受信して転送するRANGERネットワークとIRONルータのルータはしっかり自分のFIBにPIプレフィックスをインストールしますが、RIBにそれらを注入しないでください。 IRONルータは、そのためのFIBエントリを経由してのみ彼らの顧客ベースを追跡し、RIBにのみ、インターネット全体のVPデータベースを追跡します。
IRON routers propagate more-specific prefixes using secure redirection to update router FIBs. Prefix redirection is driven by the data plane and does not affect the control plane. Redirected prefixes are not injected into the RIB, but rather are maintained as FIB soft state that is purged after expiration or route failure. Neighbor unreachability detection is used to detect failure.
IRONルータは、ルータのFIBを更新するために、安全なリダイレクトを使用して、より固有の接頭辞を伝播します。プレフィックスのリダイレクトは、データプレーンによって駆動され、コントロールプレーンに影響を与えません。リダイレクトされたプレフィックスがRIBに注入されず、むしろ満了またはルートに障害が発生した後にパージされたFIBソフト状態として維持されます。ネイバー到達不能検出は、障害を検出するために使用されます。
Secure prefix registrations and redirections are accommodated through the mechanisms of SEAL. Tunnel endpoints using SEAL synchronize sequence numbers, and can therefore discard any packets they receive that are outside of the current sequence number window. Hence, off-path attacks are defeated. These synchronized tunnel endpoints can therefore exchange prefixes with signed certificates that prove prefix ownership in such a way that DoS vectors that attack crypto calculation overhead are eliminated due to the prevention of off-path attacks.
セキュアプレフィックスの登録とリダイレクトがSEALのメカニズムを介して収容されています。トンネルエンドポイントは、シール同期シーケンス番号を使用し、従って現在のシーケンス番号のウィンドウの外側にあるそれらが受け取るすべてのパケットを破棄することができます。したがって、オフパス攻撃は敗北しています。これら同期トンネルエンドポイントは、したがって、暗号計算オーバーヘッドを攻撃するDoS攻撃ベクトルを伴うオフパス攻撃の防止に排除されるように、プレフィックスの所有権を証明する署名付き証明書とのプレフィックスを交換することができます。
CEs can move from old RANGER networks and re-inject their PI prefixes into new RANGER networks. This would be accommodated by IRON-RANGER as a site multihoming event while host mobility and true locator-ID separation is accommodated via HIP [RFC5201].
CEは古いRANGERネットワークから移動し、新しいRANGERネットワークに彼らのPIプレフィックスを再注入することができます。ホストの移動性と真のロケータ-IDの分離がHIP [RFC5201]を経由して収容されている間、これはサイトマルチホーミングイベントとしてIRON-RANGERが収容されるだろう。
As can be seen from the extensive list of proposals above, the group explored a number of possible solutions. Unfortunately, the group did not reach rough consensus on a single best approach. Accordingly, the recommendation has been left to the co-chairs. The remainder of this section describes the rationale and decision of the co-chairs.
上記提案の広範なリストから分かるように、グループは、可能な解の数を調査しました。残念ながら、グループは、単一の最良のアプローチでラフコンセンサスに達しありませんでした。したがって、勧告は、共同議長に残されています。このセクションの残りの部分は、共同議長の根拠と決定を説明しています。
As a reminder, the goal of the research group was to develop a recommendation for an approach to a routing and addressing architecture for the Internet. The primary goal of the architecture is to provide improved scalability for the routing subsystem. Specifically, this implies that we should be able to continue to grow the routing subsystem to meet the needs of the Internet without requiring drastic and continuous increases in the amount of state or processing requirements for routers.
念のため、研究グループの目標は、インターネットのルーティングおよびアドレッシングアーキテクチャへのアプローチのための勧告を開発することでした。アーキテクチャの主な目的は、ルーティングサブシステムのための改良されたスケーラビリティを提供することです。具体的には、これは我々がルータの状態や処理要件の量の大幅な増加と連続を必要とせずに、インターネットのニーズを満たすために、ルーティングサブシステムを成長させ続けることができなければならないことを意味します。
There is a general concern that the cost and structure of the routing and addressing architecture as we know it today may become prohibitively expensive with continued growth, with repercussions to the health of the Internet. As such, there is an urgent need to examine and evaluate potential scalability enhancements.
コストとルーティングの構造と我々が今日それを知っているようなアーキテクチャへの対応は、インターネットの健康への影響と、継続的な成長と非常に高価になることがあり、一般的な懸念があります。そのため、潜在的なスケーラビリティの強化を検討し、評価するため緊急の必要性があります。
For the long term future of the Internet, it has become apparent that IPv6 is going to play a significant role. It has taken more than a decade, but IPv6 is starting to see some non-trivial amount of deployment. This is in part due to the depletion of IPv4 addresses. It therefore seems apparent that the new architecture must be applicable to IPv6. It may or may not be applicable to IPv4, but not addressing the IPv6 portion of the network would simply lead to recreating the routing scalability problem in the IPv6 domain, because the two share a common routing architecture.
インターネットの長期的な将来のために、それはIPv6が重要な役割を果たしているために起こっていることが明らかになりました。それは十年以上を撮影していますが、IPv6は、展開のいくつかの非自明な量を確認するために始めています。これは、IPv4アドレスの枯渇に起因する部分です。したがって、新しいアーキテクチャは、IPv6への適用でなければならないことが明らかと思われます。それはまたはIPv4に適用可能であってもなくてもよいが、両者が共通のルーティングアーキテクチャを共有するためのネットワークのIPv6の部分に対処しないと、単に、IPv6ドメイン内ルーティングのスケーラビリティの問題を再現につながります。
Whatever change we make, we should expect that this is a very long-lived change. The routing architecture of the entire Internet is a loosely coordinated, complex, expensive subsystem, and permanent, pervasive changes to it will require difficult choices during deployment and integration. These cannot be undertaken lightly.
私たちが作るどのような変化を、私たちは、これは非常に長寿命の変化であることを期待してください。インターネット全体のルーティングアーキテクチャは緩く協調、複雑で、高価なサブシステムであり、それへの恒久的な、普及の変更は、展開と統合時に難しい選択が必要になります。これらは、軽く着手することはできません。
By extension, if we are going to the trouble, pain, and expense of making major architectural changes, it follows that we want to make the best changes possible. We should regard any such changes as permanent and we should therefore aim for long term solutions that place the network in the best possible position for ongoing growth. These changes should be cleanly integrated, first-class citizens within the architecture. That is to say that any new elements that are integrated into the architecture should be fundamental primitives, on par with the other existing legacy primitives in the architecture, that interact naturally and logically when in combination with other elements of the architecture.
我々はトラブル、痛み、および主要なアーキテクチャの変更を行うの費用しようとしている場合は延長することで、我々が最高の変更を可能にしたいということになります。私たちは、永久としてどのような変更を考える必要があり、それゆえ我々は継続的な成長のために可能な限り最高の位置にあるネットワークを置く長期的な解決策を目指すべきです。これらの変更は、きれいアーキテクチャ内で、ファーストクラスの市民を統合する必要があります。これは、アーキテクチャに統合された新しい要素がアーキテクチャの他の要素との組み合わせで自然と論理的に対話するアーキテクチャ内の他の既存のレガシープリミティブと同等の基本的なプリミティブ、あるべきということです。
Over the history of the Internet, we have been very good about creating temporary, ad-hoc changes, both to the routing architecture and other aspects of the network layer. However, many of these band-aid solutions have come with a significant overhead in terms of long-term maintenance and architectural complexity. This is to be avoided and short-term improvements should eventually be replaced by long-term, permanent solutions.
インターネットの歴史にわたって、我々は両方のルーティングアーキテクチャへの一時的な、アドホックの変更、およびネットワーク層の他の側面の作成については非常に良いされています。しかし、これらのバンドエイドソリューションの多くは、長期的なメンテナンスや建築複雑さの点でかなりのオーバーヘッドが付属しています。これは避けなければならないと短期的な改善は、最終的に長期的、恒久的な解決策によって置き換えられるべきです。
In the particular instance of the routing and addressing architecture today, we feel that the situation requires that we pursue both short-term improvements and long-term solutions. These are not incompatible because we truly intend for the short-term improvements to be completely localized and temporary. The short-term improvements are necessary to give us the time necessary to develop, test, and deploy the long-term solution. As the long-term solution is rolled out and gains traction, the short-term improvements should be of less benefit and can subsequently be withdrawn.
ルーティングとアドレス体系の今日の特定のインスタンスでは、我々は状況が、我々は短期的な改善と長期的な解決策の両方を追求することが必要と感じています。短期的な改善は完全にローカライズされた一時的であるために私たちが真に意図するので、これらは互換性がありません。短期的な改善は、私たちに長期的なソリューションを開発、テスト、および展開するために必要な時間を与えるために必要です。長期的なソリューションを展開し、利益を牽引すると、短期的な改善はあまり有益である必要があり、その後、撤回することができます。
The group explored a number of proposed solutions but did not reach consensus on a single best approach. Therefore, in fulfillment of the routing research group's charter, the co-chairs recommend that the IETF pursue work in the following areas:
グループは、提案されたソリューションの数を調査したが、単一の最良のアプローチについて合意に達しありませんでした。そのため、ルーティング研究グループの憲章の履行で、共同議長は、IETFは、以下の分野で仕事を追求することをお勧めします：
Evolution [Evolution]
進化[進化]
Identifier-Locator Network Protocol (ILNP) [ILNP_Site]
識別子ロケータネットワークプロトコル（ILNP）ILNP_Site]
Renumbering [RFC5887]
リナンバリング[RFC5887]
We selected Evolution because it is a short-term improvement. It can be applied on a per-domain basis, under local administration and has immediate effect. While there is some complexity involved, we feel that this option is constructive for service providers who find the additional complexity to be less painful than upgrading hardware. This improvement can be deployed by domains that feel it necessary, for as long as they feel it is necessary. If this deployment lasts longer than expected, then the implications of that decision are wholly local to the domain.
それは短期的な改善されているので、私たちは進化を選択しました。これは、地方行政の下で、ドメインごとに適用され、すぐに効果がありますすることができます。関連するいくつかの複雑さがありますが、私たちは、このオプションは、ハードウェアをアップグレードするよりも少ない痛みを伴うように、追加の複雑さを見つけるサービスプロバイダのための建設的であると感じています。この改善は、限り、彼らはそれが必要であると感じてのために、それが必要な感じのドメインで展開することができます。この展開は予想より長く続く場合は、その判決の意義は、完全ドメインに対してローカルです。
We recommended ILNP because we find it to be a clean solution for the architecture. It separates location from identity in a clear, straightforward way that is consistent with the remainder of the Internet architecture and makes both first-class citizens. Unlike the many map-and-encap proposals, there are no complications due to tunneling, indirection, or semantics that shift over the lifetime of a packet's delivery.
我々はそれが建築のためのクリーンなソリューションであることがわかりましたので、私たちはILNPをお勧めします。これは、インターネットアーキテクチャの残りの部分と一致して、両方の第一級市民になりクリア、簡単な方法で同一の位置を分離します。多くのマップと-ENCAPの提案とは異なり、パケットの配信の寿命にわたってシフトなしトンネリングによる合併症、間接、または意味はありません。
We recommend further work on automating renumbering because even with ILNP, the ability of a domain to change its locators at minimal cost is fundamentally necessary. No routing architecture will be able to scale without some form of abstraction, and domains that change their point of attachment must fundamentally be prepared to change their locators in line with this abstraction. We recognize that [RFC5887] is not a solution so much as a problem statement, and we are simply recommending that the IETF create effective and convenient mechanisms for site renumbering.
私たちもILNPと、最小限のコストでそのロケータを変更するドメインの能力は基本的に必要であるため、リナンバリングを自動化することで、さらに作業をお勧めします。何のルーティングアーキテクチャは、抽象化のいくつかのフォームなしで拡張することができなくなり、アタッチメントのそれらのポイントを変更するドメインは、基本的に、この抽象に沿って自分のロケータを変更するために用意されなければなりません。私たちは、[RFC5887]は、問題文とそんなに解決策ではないことを認識し、我々は単にIETFは、サイトリナンバリングのための効果的で便利なメカニズムを作成することを推奨しています。
This document presents a small portion of the overall work product of the Routing Research Group, who have developed all of these architectural approaches and many specific proposals within this solution space.
この文書では、これらのアーキテクチャのアプローチと、この解空間内の多くの具体的な提案のすべてを開発してきたルーティング研究グループの全体的な成果物の小さな部分を提示します。
Space precludes a full treatment of security considerations for all proposals summarized herein. [RFC3552] However, it was a requirement of the research group to provide security that is at least as strong as the existing Internet routing and addressing architecture. Each technical proposal has slightly different security considerations, the details of which are in many of the references cited.
スペースは、ここにまとめ、すべての提案のためのセキュリティの考慮事項の完全な治療を妨げます。 [RFC3552]はしかし、既存のインターネットルーティングおよびアドレス体系と少なくとも同じくらい強いセキュリティを提供するために、研究グループの要件でした。それぞれの技術的な提案が引用された文献の多くである詳細は、わずかに異なるセキュリティの考慮事項があります。
[CRM] Flinck, H., "Compact routing in locator identifier mapping system", <http://www.tschofenig.priv.at/rrg/ CR_mapping_system_0.1.pdf>.
[CRM]フリンク、H.、 "ロケータ識別子マッピングシステムにおけるコンパクトルーティング"、<http://www.tschofenig.priv.at/rrg/ CR_mapping_system_0.1.pdf>。
[DNSnBIND] Liu, C. and P. Albitz, "DNS & BIND", 2006, 5th Edition, O'Reilly & Associates, Sebastopol, CA, USA. ISBN 0-596-10057-4.
[DNS BIND]劉、C.およびP. Albitz、 "DNSおよびBIND"、2006年、第5版、オライリー＆アソシエーツ、セバストポル、CA、USA。 ISBN 0-596-10057-4。
[EEMDP_Considerations] Sriram, K., Kim, Y., and D. Montgomery, "Enhanced Efficiency of Mapping Distribution Protocols in Scalable Routing and Addressing Architectures", Proceedings of the ICCCN, Zurich, Switzerland, August 2010, <http://www.antd.nist.gov/~ksriram/EEMDP_ICCCN2010.pdf>.
[EEMDP_Considerations]スリラム、K.、キム、Y.、およびD.モンゴメリー、「マッピング配布スケーラブルなルーティングプロトコルでとアドレッシングアーキテクチャの効率化」、ICCCN、チューリッヒ、スイス、2010年8月の議事録、<のhttp：// www.antd.nist.gov/~ksriram/EEMDP_ICCCN2010.pdf>。
[EEMDP_Presentation] Sriram, K., Gleichmann, P., Kim, Y., and D. Montgomery, "Enhanced Efficiency of Mapping Distribution Protocols in Scalable Routing and Addressing Architectures", Presented at the LISP WG meeting, IETF 78, July 2010. Originally presented at the RRG meeting at IETF 72, <http://www.ietf.org/proceedings/78/slides/lisp-6.pdf>.
[EEMDP_Presentation]スリラム、K.、Gleichmann、P.、キム、Y.、およびD.モンゴメリー、LISP WGの会合で発表され、 "マッピング配布スケーラブルなルーティングプロトコルでとアドレッシングアーキテクチャの効率化"、IETF 78、2010年7月。もともとはIETF 72でRRG会議で発表、<http://www.ietf.org/proceedings/78/slides/lisp-6.pdf>。
[Evolution] Zhang, B. and L. Zhang, "Evolution Towards Global Routing Scalability", Work in Progress, October 2009.
[進化]チャン、B.およびL.チャン、「グローバルルーティングスケーラビリティに向けて進化」、進歩、2009年10月に作業。
[Evolution_Grow_Presentation] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "Virtual Aggregation (VA)", November 2009, <http://www.ietf.org/proceedings/76/slides/grow-5.pdf>.
[Evolution_Grow_Presentation]フランシス、P.、徐、X.、Ballani、H.、ジェン、D.、Raszuk、R.、およびL.チャン、 "仮想集約（VA）"、2009年11月、<のhttp：// WWW .ietf.org /手続き/ 76 /スライド/成長-5.pdf>。
[FIBAggregatability] Zhang, B., Wang, L., Zhao, X., Liu, Y., and L. Zhang, "An Evaluation Study of Router FIB Aggregatability", November 2009, <http://www.ietf.org/proceedings/76/slides/grow-2.pdf>.
[FIBAggregatability]チャン、B.、王、L.、趙、X.、劉、Y.、およびL.チャン、 "ルータFIB凝集性の評価調査"、2009年11月、<のhttp：//www.ietf。 ORG /手続き/ 76 /スライド/成長-2.pdf>。
[GLI] Menth, M., Hartmann, M., and D. Klein, "Global Locator, Local Locator, and Identifier Split (GLI-Split)", April 2010, <http://www3.informatik.uni-wuerzburg.de/TR/tr470.pdf>.
[GLI] Menth、M.、ハルトマン、M.、およびD.クライン、 "グローバルロケータ、ローカルロケータと識別子スプリット（GLI-SPLIT）" 2010年4月、<HTTP：//www3.informatik.uni-wuerzburg .DE / TR / tr470.pdf>。
[ILNP_DNS] Atkinson, R. and S. Rose, "DNS Resource Records for ILNP", Work in Progress, February 2011.
[ILNP_DNS]アトキンソン、R.とS.ローズ、 "ILNPのDNSリソースレコード"、進歩、2011年2月での作業。
[ILNP_ICMP] Atkinson, R., "ICMP Locator Update message", Work in Progress, February 2011.
[ILNP_ICMP]アトキンソン、R.、 "ICMPロケータUpdateメッセージ"、進歩、2011年2月での作業。
[ILNP_Intro] Atkinson, R., "ILNP Concept of Operations", Work in Progress, February 2011.
[ILNP_Intro]アトキンソン、R.、 "オペレーションのILNPコンセプト"、進歩、2011年2月での作業。
[ILNP_Nonce] Atkinson, R., "ILNP Nonce Destination Option", Work in Progress, February 2011.
[ILNP_Nonce]アトキンソン、R.、 "ILNPナンス先オプション"、進歩、2011年2月での作業。
[ILNP_Site] Atkinson, R., Bhatti, S., Hailes, S., Rehunathan, D., and M. Lad, "ILNP - Identifier-Locator Network Protocol", updated 06 January 2011, <http://ilnp.cs.st-andrews.ac.uk>.
[ILNP_Site]アトキンソン、R.、Bhattiさん、S.、ヘイルズ、S.、Rehunathan、D.、およびM.ラッド、 - 2011年1月6日の更新 "ILNP識別子ロケータネットワークプロトコル"、、<のhttp：// ilnp。 cs.st-andrews.ac.uk>。
[IRON] Templin, F., "The Internet Routing Overlay Network (IRON)", Work in Progress, January 2011.
[IRON]テンプリン、F.、 "インターネットルーティングオーバーレイネットワーク（IRON）"、進歩、2011年1月での作業。
[Ivip_Constraints] Whittle, R., "List of constraints on a successful scalable routing solution which result from the need for widespread voluntary adoption", April 2009, <http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/>.
[Ivip_Constraints] Whittleさん、R.、「広範な自主的な採用の必要性から生じる成功したスケーラブルなルーティングソリューションの制約のリスト」、2009年4月、<http://www.firstpr.com.au/ip/ivip/RRG -2009 /制約/>。
[Ivip_DRTM] Whittle, R., "DRTM - Distributed Real Time Mapping for Ivip and LISP", Work in Progress, March 2010.
[Ivip_DRTM] Whittleさん、R.、 "DRTM - IvipとLISPのための分散リアルタイムマッピング"、進歩、2010年3月での作業。
[Ivip_EAF] Whittle, R., "Ivip4 ETR Address Forwarding", Work in Progress, January 2010.
[Ivip_EAF] Whittleさん、R.、 "Ivip4 ETRアドレスフォワーディング"、進歩、2010年1月の作業。
[Ivip_Glossary] Whittle, R., "Glossary of some Ivip and scalable routing terms", Work in Progress, March 2010.
[Ivip_Glossary] Whittleさん、R.、 "いくつかのIvipでスケーラブルなルーティング用語集"、進歩、2010年3月での作業。
[Ivip_Mobility] Whittle, R., "TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem", August 2008, <http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf>.
[Ivip_Mobility] Whittleさん、R.、「インターネットのルーティングのスケーリング問題にコアエッジ分離ソリューションのTTRモビリティ機能拡張」2008年8月、<http://www.firstpr.com.au/ip/ivip/TTR-Mobility。 PDF>。
[Ivip_PLF] Whittle, R., "Prefix Label Forwarding (PLF) - Modified Header Forwarding for IPv6", <http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/>.
【Ivip_PLF]削る、R.、 "プレフィックスラベル転送（PLF）は - IPv6のヘッダの転送を改変"、<http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/>。
[Ivip_PMTUD] Whittle, R., "IPTM - Ivip's approach to solving the problems with encapsulation overhead, MTU, fragmentation and Path MTU Discovery", January 2010, <http://www.firstpr.com.au/ip/ivip/pmtud-frag/>.
[Ivip_PMTUD] Whittleさん、R.、 "IPTM - カプセル化のオーバーヘッドの問題を解決するためのIvipのアプローチ、MTU、断片化およびパスMTUディスカバリ"、2010年1月、<http://www.firstpr.com.au/ip/ivip/ PMTUD-FRAG />。
[JSAC_Arch] Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the Internet Architecture Through Naming", IEEE Journal on Selected Areas in Communication (JSAC) 28(8), October 2010.
[JSAC_Arch]アトキンソン、R.、Bhattiさん、S.、およびS.ヘイルズ、コミュニケーションに選択された領域に、IEEEジャーナル "のネーミングを介してインターネットアーキテクチャの進化"（JSAC）28（8）、2010年10月。
[LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", Work in Progress, February 2010.
[LIG]ファリナッチ、D.とD.マイヤー、 "LISPインターネット痴漢（LIG）"、進歩、2010年2月での作業。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, October 2010.
[LISP]ファリナッチ、D.、フラー、V.、マイヤー、D.、およびD.ルイス、 "ロケータ/ ID分離プロトコル（LISP）"、進歩、2010年10月作業。
[LISP+ALT] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP+ALT)", Work in Progress, October 2010.
[LISP + ALT]フラー、V.、ファリナッチ、D.、マイヤー、D.、およびD.ルイス、 "LISP代替トポロジ（LISP + ALT）"、進歩、2010年10月ワーク。
[LISP-Interworking] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", Work in Progress, August 2010.
[LISP-インターワーキング]ルイス、D.、マイヤー、D.、ファリナッチ、D.、およびV.フラー、 "IPv4とIPv6と連動LISP"、進歩、2010年8月ワーク。
[LISP-MN] Meyer, D., Lewis, D., and D. Farinacci, "LISP Mobile Node", Work in Progress, October 2010.
[LISP-MN]マイヤー、D.、ルイス、D.、およびD.ファリナッチ、 "LISPモバイルノード"、進歩、2010年10月の作業。
[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server", Work in Progress, October 2010.
[LISP-MS]フラー、V.およびD.ファリナッチ、 "LISPマップサーバ"、進歩、2010年10月の作業。
[LISP-TREE] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System", IEEE Journal on Selected Areas in Communications, Volume 28, Issue 8, October 2010, <http ://ieeexplore.ieee.org/stamp/ stamp.jsp?tp=&arnumber=5586446>.
[LISP-TREE] Jakab、L.、Cabellos-アパリシオ、A.、Coras、F.、Saucez、D.、およびO.ボナヴェントゥラ、 "LISP-TREE：LISPマッピングシステムをサポートするためのDNS階層"、IEEEジャーナルコミュニケーション、28巻、8号、2010年10月選択された領域に、<HTTP：？//ieeexplore.ieee.org/stamp/ stamp.jsp TP =＆arnumber = 5586446>。
[LMS] Letong, S., Xia, Y., ZhiLiang, W., and W. Jianping, "A Layered Mapping System For Scalable Routing", <http:// docs.google.com/ fileview?id=0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktN mFkYzBhNWJhMWEy&hl=en>.
[LMS] Letong、S.、夏、Y.、ZhiLiang、W.、およびW. Jianping、 "スケーラブルなルーティングのための階層型マッピングシステム"、<HTTP：// docs.google.com/ FILEVIEW ID = 0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktN mFkYzBhNWJhMWEy＆HL = EN>。
[LMS_Summary] Sun, C., "A Layered Mapping System (Summary)", <http:// docs.google.com/ Doc?docid=0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&hl=en>.
[LMS_Summary]日、C.、 "階層化マッピングシステム（概要）"、<のhttp：// docs.google.com/ドクDOCID = 0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi＆HL = EN>。
[LOC_ID_Implications] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", Work in Progress, January 2009.
[LOC_ID_Implications]マイヤー、D.とD.ルイス、 "ロケータ/ ID分離の建築的意味"、進歩、2009年1月の作業。
[MILCOM1] Atkinson, R. and S. Bhatti, "Site-Controlled Secure Multi-homing and Traffic Engineering for IP", IEEE Military Communications Conference (MILCOM) 28, Boston, MA, USA, October 2009.
[MILCOM1]アトキンソン、R.とS. Bhattiさん、 "サイト制御セキュアマルチホーミングおよびIPのためのトラフィック・エンジニアリング"、IEEE軍事通信会議（MILCOM）28、ボストン、MA、USA、2009年10月。
[MILCOM2] Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised Resilience, Multi-homing and Mobility Capability for IP", IEEE Military Communications Conference (MILCOM) 27, San Diego, CA, USA, November 2008.
[MILCOM2]アトキンソン、R.、Bhattiさん、S.、およびS.ヘイルズ、 "調和回復力、IPのためのマルチホーミングおよびモビリティ機能"、IEEE軍事通信会議（MILCOM）27、サンディエゴ、CA、USA、2008年11月。
[MPTCP_Arch] Ford, A., Raiciu, C., Barre, S., Iyengar, J., and B. Ford, "Architectural Guidelines for Multipath TCP Development", Work in Progress, February 2010.
進歩、2010年2月[MPTCP_Arch]フォード、A.、Raiciu、C.、バール、S.、アイアンガー、J.、およびB.フォード、 "マルチパスTCP開発のための建築ガイドライン"、ワーク。
[MobiArch1] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an Integrated Service through the Use of Naming", ACM International Workshop on Mobility in the Evolving Internet (MobiArch) 2, Kyoto, Japan, August 2007.
[MobiArch1]アトキンソン、R.、Bhattiさん、S.、およびS.ヘイルズ、「命名の使用による統合サービスとしてモビリティ」、進化するインターネット（MobiArch）2におけるモビリティのACM国際ワークショップ、京都、日本、8月2007。
[MobiArch2] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through Naming: Impact on DNS", ACM International Workshop on Mobility in the Evolving Internet (MobiArch) 3, Seattle, USA, August 2008.
[MobiArch2]アトキンソン、R.、Bhattiさん、S.、およびS.ヘイルズ、 "命名を通してモビリティ：DNSへの影響" 進化するインターネット（MobiArch）3、シアトル、USA、2008年8月モビリティ上、ACM国際ワークショップを。
[Name_Based_Sockets] Vogt, C., "Simplifying Internet Applications Development With A Name-Based Sockets Interface", December 2009, <http ://christianvogt.mailup.net/pub/ vogt-2009-name-based-sockets.pdf>.
[Name_Based_Sockets]フォークト、C.、2009年12月、 "名前ベースのソケットインタフェースを使用したインターネットアプリケーション開発の簡素化" <のhttp：//christianvogt.mailup.net/pub/フォークト-2009-名前ベース-sockets.pdf> 。
[RANGER_Scen] Russert, S., Fleischman, E., and F. Templin, "RANGER Scenarios", Work in Progress, July 2010.
【RANGER_Scen]ラサート、S.、Fleischman、E.、およびF.テンプリン、 "レンジャーシナリオ"、進歩、2010年7月ワーク。
[RANGI] Xu, X., "Routing Architecture for the Next Generation Internet (RANGI)", Work in Progress, August 2010.
[ランギ]徐、X.、「次世代インターネット（ランギ）のためのルーティングアーキテクチャ」、進歩、2010年8月での作業。
[RANGI-PROXY] Xu, X., "Transition Mechanisms for Routing Architecture for the Next Generation Internet (RANGI)", Work in Progress, July 2009.
[ランギ-PROXY]徐、X.、進歩、2009年7月、「次世代インターネット（ランギ）のためのルーティングアーキテクチャの移行メカニズム」、仕事。
[RANGI-SLIDES] Xu, X., "Routing Architecture for the Next-Generation Internet (RANGI)", <http://www.ietf.org/proceedings/76/ slides/RRG-1/RRG-1.htm>.
[ランギ-SLIDES]徐、X.、 "ルーティングアーキテクチャの次世代インターネット（ランギ）"、<http://www.ietf.org/proceedings/76/スライド/ RRG-1 / RRG-1.htm >。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]モスコウィッツ、R.、Nikander、P.、Jokela、P.、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、RFC 5201、2008年4月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]テンプリン、F.、グリーソン、T.、およびD.ターラーは、 "イントラサイト自動トンネルは、プロトコル（ISATAP）をアドレス指定"、RFC 5214、2008年3月。
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009.
[RFC5534] Arkko、J.およびI.バンBeijnum、 "IPv6のマルチホーミングのための障害の検出とロケータペア探索プロトコル"、RFC 5534、2009年6月。
[RFC5720] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010.
[RFC5720]テンプリン、F.、 "ルーティングとグローバル企業再帰（RANGER）とのネットワークにおけるアドレス指定"、RFC 5720、2010年2月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887]大工、B.、アトキンソン、R.、およびH.フリンクは、RFC 5887、2010年5月、 "リナンバリングはまだ作業が必要"。
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC5902]ターラー、D.、チャン、L.、およびG. Lebovitz、RFC 5902、2010年7月の "IPv6ネットワークアドレス変換のIAB思考"。
[RRG_Design_Goals] Li, T., "Design Goals for Scalable Internet Routing", Work in Progress, January 2011.
[RRG_Design_Goals]李、T.、「スケーラブルなインターネットルーティングの設計目標」、進歩、2011年1月での作業。
[Referral_Obj] Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and K. Moore, "A Generic Referral Object for Internet Entities", Work in Progress, October 2009.
【Referral_Obj]カーペンター、B.、Boucadair、M.、アルペルン、J.、江、S.、およびK.ムーア、 "インターネットエンティティのための一般的な紹介オブジェクト"、進歩、2009年10月に働いています。
[SEAL] Templin, F., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Work in Progress, January 2011.
[SEAL]テンプリン、F.、 "サブネットワークのカプセル化とアダプテーション層（SEAL）"、進歩、2011年1月での作業。
[Scalability_PS] Narten, T., "On the Scalability of Internet Routing", Work in Progress, February 2010.
"インターネットルーティングのスケーラビリティについて" [Scalability_PS] Narten氏、T.、進歩、2010年2月での作業。
[TIDR] Adan, J., "Tunneled Inter-domain Routing (TIDR)", Work in Progress, December 2006.
[TIDR]アダン、J.、 "トンネリングドメイン間ルーティング（TIDR）"、進歩、2006年12月に作業。
[TIDR_AS_forwarding] Adan, J., "yetAnotherProposal: AS-number forwarding", March 2008, <http://www.ops.ietf.org/lists/rrg/2008/msg00716.html>.
[TIDR_AS_forwarding]アダン、J.、 "yetAnotherProposal：AS-番号転送"、2008年3月、<http://www.ops.ietf.org/lists/rrg/2008/msg00716.html>。
[TIDR_and_LISP] Adan, J., "LISP etc architecture", December 2007, <http://www.ops.ietf.org/lists/rrg/2007/msg00902.html>.
[TIDR_and_LISP]アダン、J.、 "LISPなどのアーキテクチャ"、2007年12月、<http://www.ops.ietf.org/lists/rrg/2007/msg00902.html>。
[TIDR_identifiers] Adan, J., "TIDR using the IDENTIFIERS attribute", April 2007, <http://www.ietf.org/mail-archive/web/ram/ current/msg01308.html>.
[TIDR_identifiers]アダン、J.、 "識別子を使用してTIDR属性"、2007年4月、<http://www.ietf.org/mail-archive/web/ram/現在/ msg01308.html>。
[VET] Templin, F., "Virtual Enterprise Traversal (VET)", Work in Progress, January 2011.
[VET]テンプリン、F.、 "仮想エンタープライズトラバーサル（VET）"、進歩、2011年1月での作業。
[Valiant] Zhang-Shen, R. and N. McKeown, "Designing a Predictable Internet Backbone Network", November 2004, <http:// conferences.sigcomm.org/hotnets/2004/ HotNets-III%20Proceedings/zhang-shen.pdf>.
[ヴァリアント]チャン・シェン、R.とN.マッケオン、 "予測可能なインターネットバックボーンネットワークの設計"、2004年11月、<のhttp：// conferences.sigcomm.org/hotnets/2004/ HotNets-III％20Proceedings /チャン・シェン.PDF>。
[hIPv4] Frejborg, P., "Hierarchical IPv4 Framework", Work in Progress, October 2010.
[hIPv4] Frejborg、P.、 "階層IPv4のフレームワーク"、進歩、2010年10月の作業。
Author's Address
著者のアドレス
Tony Li (editor) Cisco Systems 170 West Tasman Dr. San Jose, CA 95134 USA
トニー・リー（編集者）、シスコシステムズ170西タスマン博士サンノゼ、CA 95134 USA
Phone: +1 408 853 9317 EMail: tony.li@tony.li
電話：+1 408 853 9317 Eメール：tony.li@tony.li