Internet Research Task Force (IRTF) P. Frejborg
Request for Comments: 6306 July 2011
Category: Experimental
ISSN: 2070-1721
Hierarchical IPv4 Framework
Abstract
抽象
This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOCs) that is globally unique, and an edge address space (Endpoint Locators, ELOCs) that is regionally unique. In the future, the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet.
グローバルに一意であるコア・アドレス空間（エリアロケータ、ALOCs）、及び地域であるエッジアドレス空間（エンドポイントロケータ、ELOCs）：このドキュメントは、現在のIPv4アドレス空間は、2つの新しいアドレスのカテゴリに分けることができる方法のためのフレームワークを記述しユニーク。将来的には、ELOCスペースは、プライベートネットワーク内またはサービスプロバイダのドメインで重要になります。したがって、32×32ビットアドレッシング方式と階層的なルーティングアーキテクチャが達成されます。階層IPv4のフレームワークは、現在のIPv4インターネットとの下位互換性があります。
This document also discusses a method for decoupling the location and identifier functions -- future applications can make use of the separation. The framework requires extensions to the existing Domain Name System (DNS), the existing IPv4 stack of the endpoints, middleboxes, and routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers.
将来のアプリケーションは、分離を利用することができる - この文書はまた、位置及び識別子の機能を分離するための方法を論じています。フレームワークは、既存のドメインネームシステム（DNS）、インターネット内のエンドポイント、ミドルボックス、およびルータの既存のIPv4スタックへの拡張を必要とします。フレームワークは、エンドポイント、DNS、ミドルボックス、およびルータのためにインクリメンタルに実装することができます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the 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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。この文書はインターネット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/rfc6306.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6306で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................4
2. Requirements Notation ...........................................7
3. Definitions of Terms ............................................7
4. Hierarchical Addressing .........................................9
5. Intermediate Routing Architecture ..............................11
5.1. Overview ..................................................11
5.2. Life of a hIPv4 Session ...................................15
6. Long-Term Routing Architecture .................................18
6.1. Overview ..................................................19
6.2. Exit, DFZ, and Approach Routing ...........................21
7. Decoupling Location and Identification .........................23
8. ALOC Use Cases .................................................24
9. Mandatory Extensions ...........................................28
9.1. Overview ..................................................28
9.2. DNS Extensions ............................................29
9.3. Extensions to the IPv4 Header .............................30
10. Consequences ..................................................34
10.1. Overlapping Local and Remote ELOC Prefixes/Ports .........34
10.2. Large Encapsulated Packets ...............................35
10.3. Affected Applications ....................................35
10.4. ICMP .....................................................37
10.5. Multicast ................................................37
11. Traffic Engineering Considerations ............................38
11.1. Valiant Load-Balancing ...................................39
12. Mobility Considerations .......................................40
13. Transition Considerations .....................................42
14. Security Considerations .......................................43
15. Conclusions ...................................................45
16. References ....................................................47
16.1. Normative References .....................................47
16.2. Informative References ...................................47
17. Acknowlegments ................................................50
Appendix A. Short Term and Future IPv4 Address Allocation Policy ..51
Appendix B. Multi-Homing becomes Multi-Pathing ....................53
Appendix C. Incentives and Transition Arguments ...................57
Appendix D. Integration with CES Architectures ....................58
A Locator/Identifier Separation Protocol [LISP] presentation from a breakout session at an expo held in January, 2008, triggered a research study; findings from the study are described in this document. Further studies revealed that the routing community at IETF is concerned about the scalability of the routing and addressing system of the future Internet. The Internet Architecture Board (IAB) held a Routing and Addressing workshop on October 18-19, 2006, in Amsterdam. The outcome from the workshop is documented in [RFC4984]. Also, the IRTF had established a Routing Research Group [RRG] in 2007 and created some design guidelines; see [RFC6227].
2008年1月に開催された博覧会でのブレイクアウトセッションからロケータ/識別子分離プロトコル[LISP]プレゼンテーションでは、調査研究を引き起こしました。本研究で得られた知見は、このドキュメントで説明されています。さらなる研究は、IETFでのルーティングコミュニティは、ルーティングのスケーラビリティと将来のインターネットのアドレッシングシステムを懸念していることを明らかにしました。インターネットアーキテクチャ委員会（IAB）はアムステルダムで、10月18-19日、2006ルーティングとアドレッシングのワークショップを開催しました。ワークショップからの結果は、[RFC4984]に記載されています。また、IRTFは、2007年にルーティング研究グループ[RRG]を設立し、いくつかの設計ガイドラインを作成していました。 [RFC6227]を参照してください。
The author of this document found the LISP approach very interesting because the IP address space is proposed to be separated into two groups: Routing Locators (RLOCs), which are present in the global routing table of the Internet called the Default-Free Zone (DFZ), and Endpoint Identifiers (EIDs), which are only present in edge networks attached to the Internet.
デフォルト・フリーゾーン（DFZと呼ばれるルーティングロケータ（のRLOC）、インターネットのグローバルルーティングテーブルに存在している：この文書の著者は、二つのグループにIPアドレス空間を分離することが提案されているため、非常に興味深いLISPのアプローチを発見しました）、インターネットに接続エッジネットワークにのみ存在し、エンドポイント識別子（のEID）。
The proposed LISP architecture reduces the routing information in the DFZ, but it also introduces a new mapping system that would require a caching solution at the border routers installed between the edge networks and DFZ. EID prefixes are not needed in the DFZ since a tunneling (overlay) scheme is applied between the border routers. To the author, this seems to be a complex architecture that could be improved by applying lessons learned from similar past architectures -- in the '90s, overlay architectures were common, deployed on top of Frame Relay and ATM technologies. Cache-based routing architectures have also been tried, for example, Ipsilon's IP Switching. These architectures have largely been replaced by MPLS [RFC3031] for several reasons -- one being that overlay and caching solutions have historically suffered from scalability issues. Technology has certainly evolved since the '90s. The scalability issues of overlay and caching solutions may prove to be less relevant for modern hardware and new methods; see [Revisiting_Route_Caching]
提案されたLISPアーキテクチャはDFZにルーティング情報を減少させるが、それはまた、エッジネットワークとDFZ間に設置境界ルータでのキャッシング・ソリューションを必要とする新たなマッピングシステムを導入します。トンネリング（オーバーレイ）方式は境界ルータとの間に印加されるので、EIDプレフィクスはDFZに必要とされません。著者に、これは類似した過去のアーキテクチャから学んだ教訓適用することによって改善することができ、複雑なアーキテクチャのようです - 90年代で、オーバーレイ・アーキテクチャは、フレームリレーやATM技術の上に展開され、一般的でした。キャッシュベースのルーティングアーキテクチャはまた、例えば、IpsilonのIPスイッチングを試されています。これらのアーキテクチャは、主に、いくつかの理由のためにMPLS [RFC3031]に置き換えられている - 1は、そのオーバーレイとキャッシングソリューションは、歴史的に拡張性の問題に悩まされてきています。技術は確かに90年代以来、進化してきました。オーバーレイとキャッシングソリューションのスケーラビリティの問題は、最近のハードウェアおよび新しい方法のためにあまり関係になるかもしれません。 [Revisiting_Route_Caching]を参照してください
Nevertheless, the author has some doubt whether overlay and caching will scale well, based upon lessons learned from past overlay and caching architectures. The hierarchical IPv4 framework proposal arose from the question of whether the edge and core IP addressing groupings from LISP could be used without creating an overlay solution by borrowing ideas from MPLS to develop a peer-to-peer architecture. That is, instead of tunneling, why not swap IP addresses (hereafter called locators) on a node in the DFZ? By introducing a shim header to the IPv4 header and Realm Border Router (RBR) functionality on the network, the edge locators are no longer needed in the routing table of DFZ.
それにもかかわらず、著者は、オーバーレイやキャッシングが過去オーバーレイとキャッシングアーキテクチャから学んだ教訓に基づいて、うまくスケールするかどうかを、いくつかの疑問を持っています。階層のIPv4フレームワークの提案は、LISPからグループをアドレッシングエッジおよびコアIPは、ピア・ツー・ピア・アーキテクチャを開発するためにMPLSからアイデアを借りてオーバーレイ・ソリューションを作成することなく使用することができるかどうかの問題から生じました。その代わりに、トンネルの、ある、なぜDFZ内のノード上（以下、ロケータと呼ばれる）IPアドレスを交換しませんか？ネットワーク上のIPv4ヘッダと領域境界ルータ（RBR）機能にシムヘッダを導入することにより、エッジロケータはもはやDFZのルーティングテーブルに必要とされません。
Two architectural options existed regarding how to assemble the packet so that RBR functionality can be applied in the DFZ: the packet was assembled by either an ingress network node (similar to LISP or MPLS) or at the endpoint itself. The major drawback in assembling the packet with a shim header at the endpoint is that the endpoint's stack must be upgraded; however, a significant advantage is that the Path MTU Discovery issue, as discussed in, e.g., LISP, would not exist. In addition, the caching scalability issue is mitigated to the greatest extent possible by pushing caching to the endpoint.
パケットが（LISP又はMPLSと同様の）入口ネットワーク・ノードのいずれかによって、またはエンドポイント自体で組み立てた：二つのアーキテクチャオプションがRBR機能がDFZに適用することができるように、パケットをアセンブルする方法について存在します。エンドポイントでシムヘッダでパケットを組み立てる際の主な欠点は、エンドポイントのスタックをアップグレードしなければならないということです。しかし、重要な利点はで説明したようにパスMTUディスカバリの問題は、例えば、LISP、存在しないだろうということです。また、キャッシングのスケーラビリティの問題は、エンドポイントにキャッシュを押すことによって、最大限に軽減されます。
This approach also opened up the possibility of extending the current IP address scheme with a new dimension. In an MPLS network, overlapping IP addresses are allowed since the forwarding plane is leveraging label information from the MPLS shim header. By applying RBR functionality, extending the current IPv4 header with a shim header and assembling the new header at endpoints, an IP network can also carry packets with overlapping edge locators, although the core locators must still be globally unique. The location of an endpoint is also no longer described by a single address space; it is described by a combination of an edge locator and a core locator, or a set of core locators.
このアプローチはまた、新たな次元で、現在のIPアドレス体系を拡張する可能性を開きました。転送プレーンは、MPLSシムヘッダからラベル情報を活用しているので、MPLSネットワークでは、重複するIPアドレスが許可されています。コアロケータはまだグローバルに一意でなければならないがシムヘッダと現在のIPv4ヘッダを拡張し、エンドポイントに新しいヘッダを組み立て、RBR機能を適用することにより、IPネットワークはまた、重複するエッジロケータを持つパケットを運ぶことができます。エンドポイントの位置も、もはや単一のアドレス空間によって記載されていません。これは、エッジロケータとコアロケータ、またはコアロケータのセットの組み合わせによって記述されます。
Later on, it was determined that the current 32-bit address scheme can be extended to 64 bits -- 32 bits reserved for globally unique core locators and 32 bits reserved for locally unique edge locators.
グローバルに一意のコアロケータのために予約さ32ビットであり、局所的に一意のエッジロケータのために予約32ビット - 後に、それが現在の32ビットのアドレス方式が64ビットに拡張することができることが判明しました。
The new 64-bit addressing scheme is backwards compatible with the currently deployed Internet addressing scheme.
新しい64ビットアドレッシング方式は、現在展開され、インターネットのアドレス指定方式との後方互換性があります。
By making the architectural decisions described above, the foundation for the hierarchical IPv4 framework was laid out.
上記のアーキテクチャの決定を行うことにより、階層的なIPv4のフレームワークの基盤がレイアウトされました。
Note that the hierarchical IPv4 framework is abbreviated as hIPv4, which is close to the abbreviation of Host Identity Protocol (HIP) [RFC4423]. Thus, the reader needs to pay attention to the use of the two abbreviations -- hIPv4 and HIP, which represent two different architectures.
階層IPv4のフレームワークはホストアイデンティティプロトコル（HIP）[RFC4423]の略語に近接していhIPv4、と略記されることに注意してください。 hIPv4とHIP、二つの異なるアーキテクチャを表現する - このように、読者は、二つの略語の使用に注意を払う必要があります。
Use of the hIPv4 abbreviation has caused much confusion, but it was chosen for two reasons:
hIPv4略語の使用は多くの混乱を引き起こしたが、それは二つの理由のために選択しました。
o Hierarchical - to emphasize that a hierarchical addressing scheme is developed. A formalized hierarchy is achieved in the routing architecture. Some literature describes today's Internet as already using hierarchical addressing. The author believes that this claim is not valid -- today's Internet uses one flat address space.
O階層 - 階層的なアドレス方式が開発されていることを強調すること。定式化階層は、ルーティングアーキテクチャで達成されます。いくつかの文献は、既にアドレッシング階層を使用して、今日のインターネットを記述する。著者はこの主張が有効でないと考えている - 今日のインターネットは1つのフラットなアドレス空間を使用しています。
It is true that we have hierarchical routing in place. A routing architecture can consist of at least three types of areas: stub area, backbone area, and autonomous system (AS). The current flat address space is summarized or aggregated at border routers between the areas to suppress the size of a routing table. In order to carry out summaries or aggregates of prefixes, the address space must be continuous over the areas.
私たちが代わりに階層ルーティングを持っていることは事実です。スタブエリア、バックボーンエリア、自律システム（AS）：ルーティングアーキテクチャは、領域の少なくとも3つのタイプからなることができます。現在のフラットアドレス空間は、ルーティングテーブルのサイズを抑えるために領域間の境界ルータで要約または集約されます。接頭辞の概要や集計を行うために、アドレス空間は、領域にわたって連続でなければなりません。
Thus, the author concludes that the current method is best described as an aggregating addressing scheme since there are address block dependencies between the areas. Dividing addresses into edge and core locator spaces (a formalized hierarchy) opens up a new dimension -- the edge locator space can still be deployed as an aggregating address scheme on the three types of areas mentioned earlier. In hIPv4, the core locators are combined with edge locators, independent from each other -- the two locator space allocation policies are separated and no dependencies exist between the two addressing schemes in the long-term architecture.
したがって、著者は現在の方法は、最高のエリア間のアドレスブロックの依存関係があるのでアドレッシング方式凝集として記載されていると結論します。エッジおよびコアロケータスペース（正式階層）内にアドレスを分割すると、新たな次元を開き - エッジロケータ空間は依然として前述した領域の三種類に集約アドレススキームとして展開することができます。 hIPv4において、コアロケータは、互いに独立して、エッジロケータと組み合わされる - 2つのロケータ領域割当てポリシーを分離し、依存関係は、長期アーキテクチャにおける2つのアドレス指定方式の間に存在していません。
A new hierarchical addressing scheme is achieved: a two-level addressing scheme describing how the endpoint is attached to the local network and also how the endpoint is attached to the Internet. This change in the addressing scheme will enable a fourth level, called the Area Locator (ALOC) realm, at the routing architecture.
新しい階層アドレッシングスキームが達成される2つのレベルのアドレス指定スキームは、エンドポイントがエンドポイントがインターネットに接続されている方法も、ローカルネットワークに接続され、どのように記述します。アドレッシングスキームにおけるこの変化は、ルーティングアーキテクチャの領域ロケータ（ALOC）領域と呼ばれる第四のレベルを、可能にするであろう。
o IPv4 - to emphasize that the framework is still based upon the IPv4 addressing scheme, and is only an evolution from the currently deployed addressing scheme of the Internet.
IPv4のO - フレームワークは、まだIPv4のアドレス指定方式に基づいて、およびインターネットの現在展開アドレス方式からのみの進化であることを強調すること。
While performing this research study, the author reviewed a previous hierarchical addressing and routing architecture that had been proposed in the past, the Extended Internet Protocol (EIP) [RFC1385]. Should the hIPv4 framework ever be developed from a research study to a standard RFC, it is recommended that the hierarchical IPv4 framework name be replaced with Extended Internet Protocol, EIP, since both architectures share similarities, e.g., backwards compatibility with existing deployed architecture, hierarchical addressing, etc., and the hIPv4 abbreviation can be mixed up with HIP.
この調査研究を行いながら、著者は、拡張インターネットプロトコル（EIP）[RFC1385]を過去に提案されていた以前の階層的なアドレッシングとルーティングのアーキテクチャを検討しました。これまでの標準RFCへの調査研究から開発されhIPv4フレームワークは、階層のIPv4フレームワーク名は例えば、展開、既存のアーキテクチャとの下位互換性、階層、両方のアーキテクチャを共有する類似するので、拡張インターネットプロトコル、EIPに置き換えることが推奨されるべきですなど、アドレッシング、およびhIPv4の略語は、HIPと混同することができます。
This document is an individual contribution to the IRTF Routing Research Group (RRG); discussions between those on the mailing list of the group have influenced the framework. The views in this document are considered controversial by the IRTF Routing Research Group (RRG), but the group reached a consensus that the document should still be published. Since consensus was not achieved at RGG regarding which proposal should be preferred -- as stated in
この文書では、IRTFのルーティング研究グループ（RRG）への個々の貢献です。グループのメーリングリストで、それらの間の議論は、フレームワークに影響を与えました。この文書に記載されているビューはIRTFのルーティング研究グループ（RRG）で物議考えられますが、グループは文書がまだ公表されるべきであると合意に達しています。に記載されているよう - コンセンサスが好ましいすべき提案に関するRGGで達成されなかったので
[RFC6115]: "The group explored a number of proposed solutions but did not reach consensus on a single best approach" -- thus, all proposals produced within RRG can be considered controversial.
[RFC6115]：「グループが提案されたソリューションの数を調査したが、単一の最良のアプローチについて合意に達しなかった」 - このように、RRG以内に生産されるすべての提案が物議を考えることができます。
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].
キーワードは、必要は、、、、、MAY、推奨、及びこの文書のOPTIONALすべきでないないものSHALL NOT MUST MUSTは[RFC2119]に記載されているように解釈されるべきです。
This document makes use of the following terms:
このドキュメントでは、次の用語を使用します：
Regional Internet Registry (RIR):
地域インターネットレジストリ（RIR）：
This is an organization overseeing the allocation and registration of Internet number resources within a particular region of the world. Resources include IP addresses (both IPv4 and IPv6) and autonomous system numbers.
これは、世界の特定の領域内でのインターネット番号リソースの割り当てと登録を監督する組織です。リソースは、IPアドレス（IPv4とIPv6の両方）と自律システム番号が含まれます。
Locator:
ロケータ：
A name for a point of attachment within the topology at a given layer. Objects that change their point(s) of attachment will need to change their associated locator(s).
所定の層におけるトポロジ内の結合点の名前。アタッチメントのそのポイントを変更するオブジェクトは、それに関連するロケータ（複数可）を変更する必要があります。
Global Locator Block (GLB):
グローバルロケータブロック（GLB）：
An IPv4 address block that is globally unique.
グローバルに一意であるIPv4アドレスブロック。
Area Locator (ALOC):
エリアロケータ（ALOC）：
An IPv4 address (/32) assigned to locate an ALOC realm in the Internet. The ALOC is assigned by an RIR to a service provider. The ALOC is globally unique because it is allocated from the GLB.
インターネットにALOC領域を見つけるために割り当てられたIPv4アドレス（/ 32）。 ALOCは、サービスプロバイダへのRIRによって割り当てられます。それはGLBから割り当てられているので、ALOCは、グローバルに一意です。
Endpoint Locator (ELOC):
エンドポイントロケータ（ELOC）：
An IPv4 address assigned to locate an endpoint in a local network. The ELOC block is assigned by an RIR to a service provider or to an enterprise. In the intermediate routing architecture, the ELOC block is only unique in a geographical region. The final policy of uniqueness shall be defined by the RIRs. In the long-term routing architecture, the ELOC block is no longer assigned by an RIR; it is only unique in the local ALOC realm.
ローカルネットワーク内のエンドポイントを検索するために割り当てられたIPv4アドレス。 ELOCブロックは、サービスプロバイダまたは企業にRIRによって割り当てられます。中間ルーティングアーキテクチャでは、ELOCブロックは、地理的領域でのみ一意です。一意の最終方針はのRIRで定義されなければなりません。長期ルーティングアーキテクチャでは、ELOCブロックはもはやRIRによって割り当てられていません。それは地元のALOC分野で唯一のユニークです。
ALOC realm:
ALOC分野：
An area in the Internet with at least one attached Realm Border Router (RBR). Also, an ALOC must be assigned to the ALOC realm. The Routing Information Base (RIB) of an ALOC realm holds both local ELOC prefixes and global ALOC prefixes. An ALOC realm exchanges only ALOC prefixes with other ALOC realms.
少なくとも一つの取り付けられたレルムボーダルータ（RBR）とインターネット内の領域。また、ALOCがALOCレルムに割り当てる必要があります。 ALOCレルムのルーティング情報ベース（RIB）は、ローカルELOCプレフィックスとグローバルALOCプレフィックスの両方を保持しています。 ALOCレルム交換他ALOCレルムでのみALOCプレフィックス。
Realm Border Router (RBR):
ボーダーレルムPouara（RBR）。
A router or node that is able to identify and process the hIPv4 header. In the intermediate routing architecture, the RBR shall be able to produce a service, that is, to swap the prefixes in the IP header and locator header, and then forward the packet according to the value in the destination address field of the IP header. In the long-term routing architecture, the RBR is not required to produce the swap service. Instead, the RBR can make use of the Forwarding Indicator field in the locator header. Once the FI-bits are processed, the RBR forwards the packet according to the value in the destination address of the IP header or according to the value in the ELOC field of the locator header. The RBR must have the ALOC assigned as its locator.
hIPv4ヘッダを識別し、処理することができるルータまたはノード。中間ルーティングアーキテクチャでは、RBRは、IPヘッダとロケータヘッダにプレフィックスを交換するサービスを、すなわち、生成し、IPヘッダの宛先アドレスフィールドの値に応じてパケットを転送することができなければなりません。長期ルーティングアーキテクチャでは、RBRは、スワップサービスを生成するために必要とされません。その代わり、RBRはロケータヘッダ内の転送Indicatorフィールドを利用することができます。 FIビットが処理されると、RBRは、IPヘッダの宛先アドレスの値に応じて、またはロケータヘッダのELOCフィールドの値に応じてパケットを転送します。 RBRは、そのロケータとして割り当てられたALOCを持っている必要があります。
Locator Header:
ロケータヘッダー：
A 4-byte or 12-byte field, inserted between the IP header and transport protocol header. If an identifier/locator split scheme is used, the size of the locator header is further expanded.
IPヘッダとトランスポート・プロトコル・ヘッダとの間に挿入された4バイトまたは12バイトのフィールド。識別子/ロケータ分割スキームが使用される場合、ロケータヘッダのサイズがさらに拡大されます。
Identifier:
識別：
The name of an object at a given layer. Identifiers have no topological sensitivity and do not have to change, even if the object changes its point(s) of attachment within the network topology.
所定の層におけるオブジェクトの名前。識別子にはトポロジカル感度を持っていないと、オブジェクトは、ネットワークトポロジ内の接続ポイント（複数可）を変更しても、変更する必要はありません。
Identifier/locator split scheme:
識別子/ロケータ分離スキーム：
Separate identifiers used by applications from locators that are used for routing. The exchange of identifiers can occur discreetly between endpoints that have established a session, or the identifier/locator split can be mapped at a public database.
ルーティングに使用されているロケータからのアプリケーションで使用される個別の識別子。識別子の交換は、セッションを確立している、または識別子/ロケータ分割が公共のデータベースにマッピングすることができるエンドポイント間で慎重に発生する可能性があります。
Session:
セッション：
An interactive information exchange between endpoints that is established at a certain time and torn down at a later time.
特定の時間に確立され、後の時点で切断されたエンドポイントとの間の対話型情報交換。
Provider Independent Address Space (PI addresses/prefixes):
プロバイダ独立アドレス空間（PIアドレス/プレフィックス）：
An IPv4 address block that is assigned by a Regional Internet Registry directly to a user organization.
ユーザ組織に直接地域インターネットレジストリによって割り当てられたIPv4アドレスブロック。
Provider Aggregatable Address Space (PA addresses/prefixes):
プロバイダ集約アドレス空間（PAアドレス/プレフィックス）：
An IPv4 address block assigned by a Regional Internet Registry to an Internet Service Provider that can be aggregated into a single route advertisement.
1つのルートの広告に集約することができ、インターネットサービスプロバイダへの地域インターネットレジストリによって割り当てられたIPv4アドレスブロック。
Site mobility:
サイトのモビリティ：
A site wishing to change its attachment point to the Internet without changing its IP address block.
そのIPアドレスブロックを変更することなく、インターネットへの接続点を変更したいサイト。
Endpoint mobility:
エンドポイントの移動性：
An endpoint moves relatively rapidly between different networks, changing its IP layer network attachment point.
エンドポイントは、そのIP層ネットワーク接続ポイントを変更する、異なるネットワーク間で比較的急速に移動します。
Subflow:
サブフロー：
A flow of packets operating over an individual path, the flow forming part of a larger transport protocol connection.
個々の経路上で動作するパケットの流れ、より大きなトランスポートプロトコル接続の一部を形成する流れ。
The current IP addressing (IPv4) and the future addressing (IPv6) schemes of the Internet are unidimensional by their nature. This limitation -- the unidimensional addressing scheme -- has created some roadblocks, for example, breaking end-to-end connectivity due to NAT, limited deployment of Stream Control Transmission Protocol (SCTP) [RFC4960], etc., for further growth of the Internet.
現在のIPアドレス指定の（IPv4）と将来のアドレッシング（IPv6）のインターネットのスキームは、その性質上一次元です。この制限 - 一次元アドレス指定方式 - いくつかの障害物を作成したが、例えば、のさらなる成長のために、原因NATなどのストリーム制御伝送プロトコル（SCTP）[RFC4960]の限られた展開にエンドツーエンド接続を壊しますインターネット。
If we compare the Internet's current addressing schemes to other global addressing or location schemes, we notice that the other schemes use several levels in their structures. For example, the postal system uses street address, city, and country to locate a destination. To locate a geographical site, we use longitude and latitude in the cartography system. The other global network, the Public Switched Telephone Network (PSTN), has been built upon a three-level numbering scheme that has enabled a hierarchical signaling architecture. By expanding the current IPv4 addressing scheme from a single level to a two-level addressing structure, most of the issues discussed in [RFC4984] can be solved. Also, a hierarchical addressing scheme would better describe the Internet we have in place today.
私たちは他のグローバルアドレッシングや場所のスキームへのインターネットの現在のアドレス指定方式を比較すると、我々は他のスキームは、その構造中にいくつかのレベルを使用することに注意してください。例えば、郵便システムは、目的地を検索し、住所、市、国を使用しています。地理的な場所を見つけるには、我々は、地図作成システムの経度と緯度を使用しています。公衆交換電話網（PSTN）、他のグローバルネットワークは、階層シグナリングアーキテクチャを可能にした3レベルの番号付けスキームに基づいて構築されています。二レベルのアドレッシング構造の単一レベルから現在のIPv4アドレス方式を拡張することによって、[RFC4984]で説明した問題のほとんどを解決することができます。また、階層的なアドレス方式は、より良い私たちは、今日の場所に持ってインターネットを記述します。
Looking back, it seems that the architecture of the Internet changed quite radically from the intended architecture with the introduction of [RFC1918], which divides the hosts into three categories and the address space into two categories: globally unique and private address spaces. This idea allowed for further growth of the Internet and extended the life of the IPv4 address space, and it ended up becoming much more successful than expected. RFC 1918 didn't solve the multi-homing requirements for endpoints providing services for Internet users, that is, multi-homed sites with globally unique IP addresses at endpoints to be accessed from the Internet.
グローバルに一意とプライベートアドレス空間：振り返ってみると、インターネットのアーキテクチャは二つのカテゴリーに三つのカテゴリーにホストを分割[RFC1918]の導入、およびアドレス空間を意図したアーキテクチャから、かなり劇的に変化しているようです。このアイデアは、インターネットのさらなる成長のために許可されると、IPv4アドレス空間の寿命を延長し、それははるかに成功した予想以上になってしまいました。 RFC 1918は、エンドポイントは、つまり、エンドポイントでグローバルに一意なIPアドレスを持つマルチホームのサイトはインターネットからアクセスするインターネットユーザーにサービスを提供するためのマルチホーミング要件を解決しませんでした。
Multi-homing has imposed some challenges for the routing architecture that [RRG] is addressing in [RFC6115]. Almost all proposals in the report suggest a core and edge locator separation or elimination to create a scalable routing architecture. The core locator space can be viewed to be similar to the globally unique address space, and the edge locator space similar to the private address space in RFC 1918.
マルチホーミングは、[RRG]は[RFC6115]でアドレス指定されたルーティングアーキテクチャのいくつかの課題を課しています。レポート内のほとんどすべての提案は、スケーラブルなルーティングアーキテクチャを作成するために、コアとエッジロケータ分離または除去を示唆しています。コアロケータスペースは、グローバルに一意なアドレス空間、およびRFC 1918でのプライベートアドレス空間に類似エッジロケータスペースと類似していると見ることができます。
RFC 1918 has already demonstrated that Internet scales better with the help of categorized address spaces, that is, globally unique and private address spaces. The RRG proposals suggest that the Internet will be able to scale even further by introducing core and edge locators. Why not then change the addressing scheme (both IPv4 and IPv6 addressing schemes, though this document is only focusing on IPv4) to better reflect the current and forthcoming Internet routing architecture? If we continue to use a flat addressing scheme, and combine it with core (global) and edge (private) locator (address) categories, the routing architecture will have to support additional mechanisms, such as NAT, tunneling, or locator rewriting with the help of an identifier to overcome the mismatch. The result will be that information is lost or hidden for the endpoints. With a two-level addressing scheme, these additional mechanisms can be removed and core/edge locators can be used to create new routing and forwarding directives.
RFC 1918は、すでにインターネットは、より良い分類アドレス空間の助けを借りて、スケール、それは、グローバルに一意とプライベートアドレス空間であることを示しました。 RRG提案は、インターネット、コア及びエッジロケータを導入することによってさらに拡張することができるであろうことを示唆しています。 （この文書はIPv4のみに焦点を当てているが、IPv4とIPv6の両方のアドレッシング方式）なぜ、より良い現在および今後のインターネットルーティングアーキテクチャを反映するためにアドレス指定方式を変更しませんか？私たちは、フラットアドレッシング方式を使用し、コア（グローバル）とエッジ（プライベート）ロケータ（アドレス）カテゴリとそれを組み合わせるし続ける場合は、ルーティングアーキテクチャは、と書き換え、そのようなNAT、トンネリング、またはロケータなどの追加のメカニズムをサポートする必要があります不一致を克服するための識別子の助け。その結果、情報は、エンドポイントのために失われたり、隠されていることになります。二レベルのアドレッシング方式で、これらの追加の機構を除去することができ、コア/エッジロケータは新しいルーティングおよび転送指示を作成するために使用することができます。
A convenient way to understand the two-level addressing scheme of the hIPv4 framework is to compare it to the PSTN numbering scheme (E.164), which uses country codes, national destination codes, and subscriber numbers. The Area Locator (ALOC) prefix in the hIPv4 addressing scheme can be considered similar to the country code in PSTN; i.e., the ALOC prefix locates an area in the Internet called an ALOC realm. The Endpoint Locator (ELOC) prefixes in hIPv4 can be compared to the subscriber numbers in PSTN -- the ELOC is regionally unique (in the future, locally unique) at the attached ALOC realm. The ELOC can also be attached simultaneously to several ALOC realms.
hIPv4フレームワークの二レベルのアドレッシングスキームを理解する便利な方法は、国コード、国宛先コード、および加入者番号を使用してPSTN番号付けスキーム（E.164）、それを比較することです。 hIPv4アドレッシングスキーム領域ロケータ（ALOC）接頭辞は、PSTNにおける国コードと同様とみなすことができます。すなわち、ALOCプレフィックスは、インターネットでの面積がALOCレルムを呼ば検索します。 hIPv4エンドポイントロケータ（ELOC）プレフィックスはPSTN内の加入者番号と比較することができる - ELOC、添付ALOCレルムに（局所的に一意の、将来の）地域固有のものです。 ELOCはまた、いくつかのALOC、レルムに同時に接続することができます。
By inserting the ALOC and ELOC elements as a shim header (similar to the MPLS and [RBridge] architectures) between the IPv4 header and the transport protocol header, a hIPv4 header is created. From the network point of view, the hIPv4 header "looks and feels like" an IPv4 header, thus fulfilling some of the goals as outlined in EIP and in the early definition of [Nimrod]. The outcome is that the current forwarding plane does not need to be upgraded, though some minor changes are needed in the control plane (e.g., ICMP extensions).
ALOCとIPv4ヘッダとトランスポート・プロトコル・ヘッダとの間の（MPLSおよび[RBridge]アーキテクチャに類似）シムヘッダとしてELOC要素を挿入することにより、hIPv4ヘッダが作成されます。ネットワークの観点からは、hIPv4ヘッダが「見て、のように感じている」EIP及び[ニムロデ]の初期定義に概説されるようにこのような目標のいくつかを満たす、IPv4ヘッダ。結果は、いくつかのマイナーな変更がコントロールプレーン（例えば、ICMPの拡張）で必要とされているものの、現在の転送プレーンは、アップグレードする必要がないことです。
The intermediate routing architecture is backwards compatible with the currently deployed Internet; that is, the forwarding plane remains intact except that the control plane needs to be upgraded to support ICMP extensions. The endpoint's stack needs to be upgraded, and middleboxes need to be upgraded or replaced. In order to speed up the transition phase, middleboxes might be installed in front of endpoints so that their stack upgrade can be postponed; for further details, see Appendix D.
中間ルーティングアーキテクチャは、現在展開され、インターネットとの後方互換性があります。つまり、フォワーディングプレーンは、制御プレーンは、ICMPの拡張をサポートするようにアップグレードする必要があることを除いてそのまま残ります。エンドポイントのスタックは、アップグレードする必要があり、ミドルボックスは、アップグレードまたは交換する必要があります。そのスタックのアップグレードを延期することができるように移行期をスピードアップするためには、ミドルボックスは、エンドポイントの前に設置されることがあります。詳細は、付録Dを参照してください。
As mentioned in previous sections, the role of an Area Locator (ALOC) prefix is similar to a country code in PSTN; the ALOC prefix provides a location functionality of an area within an autonomous system (AS), or an area spanning over a group of ASes, in the Internet. An area can have several ALOC prefixes assigned, e.g., for traffic engineering purposes such as load balancing among several ingress/egress points at the area. The ALOC prefix is used for routing and forwarding purposes on the Internet, and so the ALOC prefix must be globally unique and is allocated from an IPv4 address block. This globally unique IPv4 address block is called the Global Locator Block (GLB).
前のセクションで述べたように、エリアロケータ（ALOC）接頭辞の役割は、PSTNにおける国コードに類似しています。 ALOCプレフィックスはインターネットで、自律システム（AS）内の領域の位置の機能、またはのASのグループの上にまたがる領域を提供します。面積は、このような領域では、いくつかの入口/出口ポイント間でのロードバランシングなどのトラフィックエンジニアリングの目的のために、例えば、割り当てられたいくつかのALOCプレフィックスを持つことができます。 ALOCプレフィックスは、インターネット上でルーティングおよび転送の目的のために使用され、従ってALOCプレフィックスはグローバルに一意でなければならず、IPv4アドレスブロックから割り当てられます。このグローバルにユニークなIPv4アドレスブロックは、グローバルロケータブロック（GLB）と呼ばれています。
When an area within an AS (or a group of ASes) is assigned an ALOC prefix, the area has the potential to become an ALOC realm. In order to establish an ALOC realm, more elements, more than just the ALOC prefix, are needed. One or multiple Realm Border Routers (RBRs) must be attached to the ALOC realm. An RBR element is a node capable of swapping the prefixes of the IP header and the new shim header, called the locator header. The swap service is described in detail in Section 5.2, step 3.
AS（又はのASのグループ）内の領域は、ALOCプレフィックスを割り当てられている場合、領域はALOC領域になる可能性を秘めています。 ALOCレルムを確立するために、より多くの要素が、ちょうどALOCプレフィックスよりも、必要とされています。一つまたは複数のレルム境界ルータ（RBRS）がALOCレルムに接続する必要があります。 RBR要素がロケータヘッダーと呼ばれるIPヘッダと新しいシムヘッダのプレフィックスを交換することが可能なノードです。交換サービスは、セクション5.2、ステップ3に詳細に記載されています。
Today's routers do not support this RBR functionality. Therefore, the new functionality will most likely be developed on an external device attached to a router belonging to the ALOC realm. The external RBR might be a server with two interfaces attached to a router, the first interface configured with the prefix of the ALOC and the second with any IPv4 prefix. The RBRs do not make use of dynamic routing protocols, so neither a Forwarding Information Base (FIB) nor a cache is needed -- the RBR performs a service, swapping headers.
今日のルータは、このRBRの機能をサポートしていません。そのため、新機能は、最も可能性の高いALOCレルムに属するルータに接続された外部デバイス上で開発されます。外部RBRは、ルータに取り付けられた2つのインターフェース、ALOCのプレフィックスと任意のIPv4プレフィックスを有する第で構成された第一のインタフェースを備えたサーバであるかもしれません。 RBRSは、ダイナミックルーティングプロトコルを使用しませんので、どちらも転送情報ベース（FIB）にもキャッシュが必要ありません - RBRは、ヘッダーを交換、サービスを実行します。
The swap service is applied on a per-packet basis, and the information needed to carry out the swap is included in the locator header of the hIPv4 packet. Thus, a standalone device with sufficient computing and I/O resources to handle the incoming traffic can take the role as an RBR. Later on, the RBR functionality might be integrated into the forwarding plane of a router. It is expected that one RBR will not be able to handle all the incoming traffic designated for an ALOC realm and that having a single RBR would also create a potential single point of failure in the network. Therefore, several RBRs might be installed in the ALOC realm and the RBRs shall use the ALOC prefix as their locator, and the routers announce the ALOC prefix as an anycast locator within the local ALOC realm. The ALOC prefix is advertised throughout the DFZ by BGP mechanisms. The placement of the RBRs in the network will influence the ingress traffic to the ALOC realm.
スワップサービスはパケット単位で適用され、スワップを行うために必要な情報がhIPv4パケットのロケータヘッダに含まれています。したがって、着信トラフィックを処理するのに十分なコンピューティングおよびI / Oリソースを備えたスタンドアロンデバイスは、RBRとしての役割を取ることができます。その後、RBR機能は、ルータのフォワーディングプレーンに統合される可能性があります。 1つRBRがALOCレルムに対しても、ネットワーク内のシングルポイント障害が発生を作成し、単一のRBRを持つことを指定されたすべての着信トラフィックを処理することはできないと予想されます。そのため、いくつかのRBRSはALOC領域にインストールされるかもしれないとRBRSは、そのロケータとしてALOC接頭辞を使用しなければならない、とルータがローカルALOCレルム内エニーキャストロケータとしてALOCプレフィックスを発表します。 ALOCプレフィックスは、BGPメカニズムによってDFZを通じてアドバタイズされます。ネットワーク内RBRSの配置は、ALOCレルムに入力トラフィックに影響を与えます。
Since the forwarding paradigm of multicast packets is quite different from forwarding unicast packets, the multicast functionality will have an impact on the RBR. Because the multicast RBR (mRBR) functionality is not available on today's routers, an external device is needed -- later on the functionality might be integrated into the routers. The mRBR shall take the role of an anycast Rendezvous Point with the Multicast Source Discovery Protocol (MSDP) [RFC3618] and Protocol Independent Multicast (PIM) [RFC4601] capabilities, but to swap headers neither a FIB nor a cache is required. As with the RBR, the multicast hIPv4 packets are carrying all needed information in their headers in order to apply the swap service; for details, see Section 10.5.
マルチキャストパケットの転送パラダイムは、ユニキャストパケットを転送するとは全く異なるため、マルチキャスト機能がRBRに影響を与えることになります。マルチキャストRBR（mRBR）機能は、今日のルータでは利用できませんので、外部デバイスが必要とされている - 後で機能には、ルータに統合される可能性があります。 mRBRには、Multicast Source Discovery Protocol（MSDP）[RFC3618]およびプロトコル独立マルチキャスト（PIM）[RFC4601]機能を備えたエニーキャストランデブーポイントの役割をとらなければならないが、FIBやキャッシュのいずれも必要とされるヘッダを交換します。 RBRと同様に、マルチキャストhIPv4パケットが交換サービスを適用するために、それらのヘッダ内のすべての必要な情報を運んでいます。詳細については、項10.5を参照してください。
The ALOC realm is not yet fully constructed. We can now locate the ALOC realm on the Internet, but to locate the endpoints attached to the ALOC realm, a new element is needed: the Endpoint Locator (ELOC). As mentioned in the previous section, the ELOC prefixes can be considered similar to the subscriber numbers in PSTN. The ELOC is not a new element but a redefinition of the current IPv4 address configured at an endpoint. The term redefinition is applied because when the hIPv4 framework is fully implemented, the global uniqueness of the IPv4 addresses is no longer valid. A more regional address allocation policy of IPv4 addresses can be deployed, as discussed in Appendix A. The ELOC prefix will only be used for routing and forwarding purposes inside the local and remote ALOC realms, and it is not used in the intermediate ALOC realms.
ALOCレルムは、まだ完全に構築されていません。私たちは今、インターネット上のALOCレルムを見つけることができますが、ALOCレルムに取り付けたエンドポイントを見つけるために、新しい要素が必要とされている：エンドポイントロケータ（ELOC）。前節で述べたように、ELOCプレフィックスは、PSTN内の加入者番号と同様と考えることができます。 ELOCは、新しい要素が、エンドポイントで構成された現在のIPv4アドレスの再定義はありません。 hIPv4の枠組みが完全に実装されている場合、IPv4アドレスのグローバル一意性が有効でなくなっているので、長期的な再定義が適用されません。付録A.ザELOCプレフィックスで説明したようにIPv4アドレスの複数の地域アドレス割り当てポリシーは、展開することができ、ローカルおよびリモートのALOCレルム内部ルーティングおよび転送の目的のために使用され、それは中間ALOCレルムで使用されていません。
When an initiator is establishing a session to a responder residing outside the local ALOC realm, the value in the destination address field of the IP header of an outgoing packet is no longer the remote destination address (ELOC prefix); instead, the remote ALOC prefix is installed in the destination address field of the IP header. Because the value in the destination address field of the IP header is carrying an ALOC prefix, the intermediate ALOC realms do not need to install the ELOC prefixes of other ALOC realms in their routing tables. It is sufficient for the intermediate ALOC realms to carry only the ALOC prefixes.
イニシエータは、ローカルALOC領域外に存在するレスポンダにセッションを確立された場合、発信パケットのIPヘッダの宛先アドレスフィールドの値は、もはやリモート宛先アドレス（ELOCプレフィックス）ではありません。代わりに、遠隔ALOCプレフィックスは、IPヘッダの宛先アドレスフィールドに設置されています。 IPヘッダの宛先アドレスフィールドの値がALOCプレフィックスを搬送されているので、中間ALOCレルムは、そのルーティングテーブル内の他のALOCレルムのELOCプレフィックスをインストールする必要はありません。中間ALOCレルムのみALOCプレフィックスを運ぶことは十分です。
The outcome is that the routing tables at each ALOC realm will be reduced when the hIPV4 framework is fully implemented. The ALOC prefixes are still globally unique and must be installed in the DFZ. Thus, the service provider cannot control the growth of the ALOC prefixes, but she/he can control the amount of local ELOC prefixes in her/his local ALOC realm.
結果はhIPV4フレームワークを完全に実装されたときに各ALOC領域におけるルーティングテーブルが減少することです。 ALOCプレフィクスがまだグローバルにユニークであり、DFZにインストールする必要があります。このように、サービスプロバイダは、ALOCプレフィックスの成長を制御することはできませんが、彼女は/彼は彼女/彼の地元ALOC分野で地元ELOCプレフィックスの量を制御することができます。
When the hIPv4 packet arrives at the remote ALOC realm, it is forwarded to the nearest RBR, since the value in the destination address field of the IP header is the remote ALOC prefix. When the RBR has swapped the hIPv4 header, the value in the destination address field of the IP header is the remote ELOC; thus, the hIPv4 packet will be forwarded to the final destination at the remote ALOC realm. An endpoint using an ELOC prefix can be attached simultaneously to two different ALOC realms without the requirement to deploy a classical multi-homing solution; for details, see Section 12 and Appendix B.
hIPv4パケットがリモートALOC領域に到着するIPヘッダの宛先アドレスフィールドの値がリモートALOCプレフィックスであるので、それは、最も近いRBRに転送されます。 RBRはhIPv4ヘッダをスワップしたとき、IPヘッダの宛先アドレスフィールドの値は、リモートELOCあります。従って、hIPv4パケットは、リモートALOC分野における最終的な宛先に転送されます。 ELOCプレフィックスを使用してエンドポイントは、古典的なマルチホーミングソリューションを展開する必要なく、2つの異なるALOCレルムに同時に結合することができます。詳細については、12章および付録Bを参照してください。
Understanding that the addressing structure is no longer unidimensional and that a second level of hierarchy has been added, it is important to solve the problems of locating the remote ELOC (endpoint) and remote ALOC realm on the Internet, as well as determining where to assemble the header of the hIPv4 packet. The hierarchical IPv4 framework relies upon the Domain Name System needs to support a new record type so that the ALOC information can be distributed to the endpoints. To construct the header of the hIPv4 packet, either the endpoint or an intermediate node (e.g., a proxy) should be used. A proxy solution is likely to prove suboptimal due to a complication induced by the proxy's need to listen to DNS messages, and a cache solution has scalability issues.
アドレッシング構造は、階層の第二のレベルが追加されたことはもはや一次元とされないことを理解し、どこ組み立てるために、インターネット上のリモートELOC（エンドポイント）とリモートALOC領域を配置、ならびに決定の問題を解決することが重要ですhIPv4パケットのヘッダ。ドメインネームシステムは、ALOC情報をエンドポイントに配布できるように、新しいレコードタイプをサポートする必要がある時に、階層のIPv4フレームワークは依存しています。 hIPv4パケットのヘッダを構築するために、エンドポイントまたは中間ノード（例えば、プロキシ）のいずれかが使用されるべきです。プロキシソリューションが原因DNSメッセージを聞くためのプロキシの必要性によって誘発される合併症に次善の証明する可能性がある、とキャッシュソリューションは、拡張性の問題があります。
A better solution is to extend the current IPv4 stack at the endpoints so that the ALOC and ELOC elements are incorporated at the endpoint's stack; however, backwards compatibility must be preserved. Most applications will not be aware of the extensions while other IP-aware applications, such as Mobile IP, SIP, IPsec AH and so on (see Section 10.3) will suffer and cannot be used outside their ALOC realm when the hIPv4 framework is fully implemented, unless they are upgraded. The reason is that the IP-aware applications depend upon the underlying network addressing structure, e.g., to identify an endpoint.
よりよい解決策は、ALOC及びELOC要素はエンドポイントのスタックに組み込まれているように、エンドポイントに現在のIPv4スタックを拡張することです。ただし、下位互換性は維持されなければなりません。ほとんどのアプリケーションは、このようなように、モバイルIP、SIP、IPsecのAHおよびなどの他のIP対応アプリケーションは、（項10.3を参照）を被るながら拡張を認識しませんし、hIPv4の枠組みが完全に実装されたときにそのALOC領域外で使用することはできません、それらがアップグレードされていない限り。その理由は、IP対応のアプリケーションがエンドポイントを識別するために、例えば、基礎となるネットワークアドレッシング構造に依存することです。
Note that the applications used inside the local ALOC realm (e.g., enterprise's private network) do not need to be upgraded -- neither in the intermediate nor in the long-term routing architecture. The classical IPv4 framework is preserved in that only IP-aware applications used between ALOC realms need to be upgraded to support the hIPv4 header.
中間でも長期的なルーティングアーキテクチャでもない - ローカルALOC分野（例えば、企業のプライベートネットワーク）の内部で使用するアプリケーションをアップグレードする必要はないことに注意してください。古典的なIPv4のフレームワークはALOCレルム間使用されている唯一のIP対応のアプリケーションに保存されhIPv4ヘッダをサポートするようにアップグレードする必要があります。
Figure 1 shows a conceptual overview of the intermediate routing architecture. When this architecture is in place, the ELOC space is no longer globally unique. Instead, a regional allocation policy can be implemented. For further details, see Appendix A. The transition from the current routing architecture to the intermediate routing architecture is discussed in Appendix D.
図1は、中間ルーティング・アーキテクチャの概念の概要を示します。このアーキテクチャは、所定の位置にあるときは、ELOCスペースはもはやグローバルに一意ではありません。代わりに、地域の割り当てポリシーを実現することができます。詳細については、現在のルーティングアーキテクチャから中間ルーティングアーキテクチャへの移行は、付録Dに記載されている付録Aを参照してください
Legend: *attachment point in the ALOC realm UER=Unique ELOC region EP=Endpoint
凡例：ALOCレルムUER =ユニークELOC地域EP =エンドポイントにおける*取り付け点
|-------------------------------------------------------------|
| UER1 | | UER2 |
|-------------------------------------------------------------|
| Enterprise1 | ISP1 | ISP | ISP2 | Enterprise2 |
| ALOC Realm | ALOC Realm | Tier1 | ALOC Realm | ALOC Realm |
| | | | | |
| *EP | *RBR | | *RBR | *EP |
| ELOC1 | ALOC1 | | ALOC2 | ELOC4 |
| | | | | |
| | *EP | | *EP | |
| | ELOC2 | | ELOC3 | |
| | | | | |
|-------------|xxxxxxxxxxxxxx DFZ xxxxxxxxxxxxxx| ------------|
| RIB | RIB | RIB | RIB | RIB |
| | | | | |
| ALOC1 | ALOC1 | ALOC1 | ALOC2 | ALOC2 |
| ELOC1 | ALOC2 | ALOC2 | ALOC1 | ELOC4 |
| | ELOC2 | | ELOC3 | |
| | ELOC1 | | ELOC4 | |
| | | | | |
|-------------------------------------------------------------|
Figure 1: Intermediate routing architecture of hIPv4
図1：hIPv4の中間ルーティングアーキテクチャ
This section provides an example of a hIPv4 session between two hIPv4 endpoints: an initiator and a responder residing in different ALOC realms.
イニシエータと異なるALOCレルムに存在する応答：このセクションでは、2つのhIPv4エンドポイント間hIPv4セッションの例を提供します。
When the hIPv4 stack is assembling the packet for transport, the hIPv4 stack shall decide if a classical IPv4 or a hIPv4 header is used based on the ALOC information received by a DNS reply. If the initiator's local ALOC prefix equals the responder's ALOC prefix, there is no need to use the hIPv4 header for routing purposes, because both the initiator and responder reside in the local ALOC realm. The packet is routed according to the prefixes in the IP header since the packet will not exit the local ALOC realm. When the local ALOC prefix does not match the remote ALOC prefix, a hIPv4 header must be assembled because the packet needs to be routed to a remote ALOC realm.
hIPv4スタックはトランスポートのためにパケットをアセンブルしたとき、古典IPv4またはhIPv4ヘッダがDNS応答によって受信ALOC情報に基づいて使用される場合、hIPv4スタックが決定しなければなりません。イニシエータのローカルALOCプレフィックスはレスポンダのALOCプレフィックスに等しい場合、イニシエータとレスポンダの双方がローカルALOC領域内に存在するので、ルーティングの目的のためにhIPv4ヘッダーを使用する必要はありません。パケットがローカルALOC領域を出ないので、パケットは、IPヘッダ内のプレフィクスに従ってルーティングされます。ローカルALOCプレフィクスがリモートALOCプレフィックスに一致しない場合は、パケットがリモートALOCレルムにルーティングする必要があるので、hIPv4ヘッダを組み立てなければなりません。
A session between two endpoints inside an ALOC realm might use the locator header -- not for routing purposes, but to make use of Valiant Load-Balancing [VLB] for multipath-enabled transport protocols (see Section 11.1) or to make use of an identifier/locator split scheme (see Section 7). When making use of VLB, the initiator adds the locator header to the packet and by setting the VLB-bits to 01 or 11, indicating to the responder and intermediate routers that VLB is requested for the subflow. Because this is an intra-ALOC realm session, there is no need to add ALOC and ELOC fields to the locator header, and thus the size of the locator header will be 4 bytes.
ない目的をルーティングするために、しかし、マルチパス対応のトランスポートプロトコルのヴァリアントロードバランシング[VLB]を利用すること（セクション11.1を参照）またはANを利用する - ALOCレルム内の2つのエンドポイント間のセッションは、ロケータ・ヘッダを使用するかもしれません識別子/ロケータ分離スキーム（セクション7を参照）。 VLBを利用する場合、イニシエータは、パケットおよびVLBは、サブフローのために要求される応答と中間ルータに示し、01または11にVLBビットを設定することにより、ロケータヘッダを付加します。これは、イントラALOCレルムセッションであるため、ロケータヘッダにALOCとELOCフィールドを追加するので、ロケータヘッダのサイズは4つのバイトであろう必要はありません。
If an identifier/locator split scheme is applied for the session (intra-ALOC or inter-ALOC), the initiator must set the I-bit to 1 and make use of the Locator Header Length field. Identifier/locator split scheme information is inserted into the locator header after the Locator Header Length field.
識別子/ロケータ分割スキームがセッション（イントラALOCまたはインターALOC）に適用される場合、開始剤は、1へのIビットを設定し、ロケータヘッダ長フィールドを利用しなければなりません。識別子/ロケータスプリット方式情報は、ロケータヘッダ長フィールドの後ロケータ・ヘッダに挿入されます。
How a hIPv4 session is established follows:
どのようにhIPv4セッションが確立され、次のとおりです。
1. The initiator queries the DNS server. The hIPv4 stack notices that the local and remote ALOCs do not match and therefore must use the hIPv4 header for the session. The hIPv4 stack of the initiator must assemble the packet by the following method:
1.イニシエータは、DNSサーバーを照会します。 hIPv4スタックは、ローカルおよびリモートALOCsが一致しないため、セッションのためhIPv4ヘッダーを使用しなければならないことに気付きます。イニシエータのhIPv4スタックは、次のような方法でパケットを組み立てる必要があります。
a. Set the local IP address from the API in the source address field of the IP header.
A。 IPヘッダの送信元アドレスフィールド内のAPIからローカルIPアドレスを設定します。
b. Set the remote IP address from the API in the ELOC field of the locator header.
B。ロケータヘッダーのELOC分野におけるAPIからのリモートIPアドレスを設定します。
c. Set the local ALOC prefix in the ALOC field of the locator header.
C。ロケータヘッダーのALOCフィールドにローカルALOCプレフィックスを設定します。
d. Set the remote ALOC prefix in the destination address field of the IP header.
D。 IPヘッダの宛先アドレスフィールドにリモートALOCプレフィックスを設定します。
e. Set the transport protocol value in the protocol field of the locator header and set the hIPv4 protocol value in the protocol field of the IP header.
電子。ロケータヘッダのプロトコルフィールドにトランスポートプロトコル値を設定し、IPヘッダのプロトコルフィールドにhIPv4プロトコル値を設定します。
f. Set the desired parameters in the A-, I-, S-, VLB-, and L-fields of the locator header.
F。 A-、I-、S-、VLB-、及びロケータヘッダのLフィールドにおける所望のパラメータを設定します。
g. Set the FI-bits of the locator header to 00.
グラム。 00ロケータヘッダのFIビットを設定します。
h. Calculate IP, locator, and transport protocol header checksums. The transport protocol header calculation does not include the locator header fields. When completed, the packet is transmitted.
時間。 IP、ロケータ、およびトランスポート・プロトコル・ヘッダのチェックサムを計算します。トランスポートプロトコルヘッダ計算は、ロケータ・ヘッダ・フィールドを含んでいません。完了すると、パケットが送信されます。
2. The hIPv4 packet is routed throughout the Internet based on the value in the destination address field of the IP header.
2. IPv4パケットは、IPヘッダの宛先アドレスフィールドの値に基づいて、インターネットを介してルーティングされます。
3. The hIPv4 packet will reach the closest RBR of the remote ALOC realm. When the RBR notices that the value in the destination address of the IP header matches the local ALOC prefix, the RBR must:
3. hIPv4パケットは、リモートALOC分野の最も近いRBRに到達します。 RBRは、IPヘッダの宛先アドレスの値がローカルALOCプレフィックスと一致していることに気づくとき、RBR必要があります：
a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
A。受信したパケットがIPヘッダのプロトコルフィールドにhIPv4プロトコル値を使用していることを確認します。
b. Verify IP, locator, and transport protocol header checksums. The transport protocol header verification does not include the locator header fields.
B。 IP、ロケータ、およびトランスポート・プロトコル・ヘッダのチェックサムを検証します。トランスポート・プロトコル・ヘッダの検証はロケータヘッダフィールドを含んでいません。
c. Replace the source address in the IP header with the ALOC prefix of the locator header.
C。ロケータヘッダのALOCプレフィックスとIPヘッダ内の送信元アドレスを置き換えます。
d. Replace the destination address in the IP header with the ELOC prefix of the locator header.
D。ロケータヘッダのELOCプレフィックスとIPヘッダ内の宛先アドレスを置き換えます。
e. Replace the ALOC prefix in the locator header with the destination address of the IP header.
電子。 IPヘッダの宛先アドレスを持つロケータヘッダ内ALOCプレフィックスを置き換えます。
f. Replace the ELOC prefix in the locator header with the source address of the IP header.
F。 IPヘッダの送信元アドレスとロケータヘッダ内ELOCプレフィックスを置き換えます。
g. Set the S-field to 1.
グラム。 S-フィールドを1に設定してください。
h. Decrease the Time to Live (TTL) value by one.
時間。 1で（TTL）値を生存時間を減らします。
i. Calculate IP, locator, and transport protocol header checksums. The transport header calculation does not include the locator header fields.
私。 IP、ロケータ、およびトランスポート・プロトコル・ヘッダのチェックサムを計算します。トランスポートヘッダ計算は、ロケータ・ヘッダ・フィールドを含んでいません。
j. Forward the packet according to the value in the destination address field of the IP header.
J。 IPヘッダの宛先アドレスフィールドの値に応じてパケットを転送します。
4. The swapped hIPv4 packet is now routed inside the remote ALOC realm based on the new value in the destination address field of the IP header to the final destination.
4.スワップhIPv4パケットは、現在最終的な宛先へのIPヘッダの宛先アドレスフィールドに新しい値に基づいて遠隔ALOCレルム内部ルーティングされます。
a. The hIPv4 stack must verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
A。 hIPv4スタックは、受信したパケットがIPヘッダのプロトコルフィールドにhIPv4プロトコル値を使用していることを確認しなければなりません。
b. Verify IP, locator, and transport protocol header checksums. The transport protocol header verification does not include the locator header fields.
B。 IP、ロケータ、およびトランスポート・プロトコル・ヘッダのチェックサムを検証します。トランスポート・プロトコル・ヘッダの検証はロケータヘッダフィールドを含んでいません。
6. The hIPv4 stack of the responder must present the following to the extended IPv4 socket API:
6.レスポンダのhIPv4スタックは、拡張IPv4ソケットのAPIに以下を提示する必要があります。
a. The source address of the IP header as the remote ALOC prefix.
A。リモートALOCプレフィックスとしてIPヘッダの送信元アドレス。
b. The destination address of the IP header as the local IP address.
B。ローカルIPアドレスとしてIPヘッダの宛先アドレス。
c. Verify that the received ALOC prefix of the locator header equals the local ALOC prefix.
C。ロケータヘッダの受信ALOCプレフィックスがローカルALOCプレフィックスに等しいことを確認します。
d. The ELOC prefix of the locator header as the remote IP address.
D。リモートIPアドレスとしてロケータヘッダのELOCプレフィックス。
The responder's application will respond to the initiator and the returning packet will take almost the same steps, which are steps 1 to 6, as when the initiator started the session. In step 1, the responder does not need to do a DNS lookup since all information is provided by the packet.
応答者のアプリケーションは、イニシエータに応答し、イニシエータがセッションを開始したときのように戻ったパケットは1〜6ステップで、ほぼ同じ手順を、かかります。ステップ1では、応答者は、すべての情報は、パケットによって提供されているのでDNSルックアップを行う必要はありません。
The long-term routing architecture is established once the forwarding planes of private ALOC realms or service providers ALOC realms containing subscribers are upgraded. The forwarding planes of transit DFZ routers do not need to be upgraded. Why then would private network or service provider administrators upgrade their infrastructure? There are two incentives:
長期的なルーティングアーキテクチャは、加入者を含むALOC、レルムがアップグレードされているプライベートALOCレルムまたはサービスプロバイダーのフォワーディングプレーン一度確立されています。トランジットDFZルータのフォワーディングプレーンをアップグレードする必要はありません。なぜ、プライベートネットワークまたはサービスプロバイダーの管理者は、インフラストラクチャをアップグレードするのでしょうか？ 2つのインセンティブがあります。
o The overlay local ALOC exit routing topology (as discussed in Section 11) can be replaced by a peer-to-peer local ALOC exit routing topology, which is simpler to operate, thus decreasing operational expenditures.
OオーバーレイローカルALOC出口ルーティングトポロジが（セクション11で説明したように）、したがって運用コストを減少させる、操作が簡単で、ピア・ツー・ピアローカルALOC出口ルーティングトポロジー、置き換えることができます。
o Locator freedom: Once the local ALOC realm is upgraded, the enterprise or service provider can use the full 32-bit ELOC address space to remove address space constraints and to design a well-aggregated routing topology with an overdimensioned ELOC allocation policy.
Oロケータ自由：ローカルALOCレルムがアップグレードされると、企業またはサービスプロバイダは、アドレス空間の制約を除去し、過大ELOC割り当てポリシーに十分に集約ルーティングトポロジを設計するために完全な32ビットELOCアドレス空間を使用することができます。
When an enterprise or service provider upgrades the forwarding plane in their ALOC realm, the previous PI or PA address space allocation is released back to the RIR to be used for ALOC allocations in the GLB.
企業やサービスプロバイダが彼らのALOC分野におけるフォワーディングプレーンをアップグレードする場合、以前のPIやPAアドレス空間の割り当てはバックRIRにリリースされGLBでALOCの割り当てに使用します。
The swap service at the RBR was added to the framework in order to provide a smooth transition from the current IPv4 framework to the hIPv4 framework; a major upgrade of the current forwarding plane is avoided by the introduction of the swap service. In the future, the swap service can be left "as is" in the ALOC realm, if preferred, or the swap service can be pushed towards the edge of the ALOC realm when routers are upgraded in their natural lifecycle process.
RBRでスワップサービスはhIPv4フレームワークに現在のIPv4フレームワークからのスムーズな移行を提供するために、フレームワークに加えました。現在のフォワーディングプレーンのメジャーアップグレードは、スワップサービスの導入によって回避されます。将来的には、スワップ・サービスは、好ましい場合、ALOCレルムに「そのまま」のままにすることができ、又はルータは、その天然のライフサイクルプロセスでアップグレードされるとき、スワップサービスはALOC領域の縁部に向かって押し込むことができます。
Once an upgrade of a router is required because of, for example, increased demand for bandwidth, the modified forwarding plane might concurrently support IPv4 and hIPv4 forwarding -- and the swap service can be pushed towards the edge and in the future removed at the ALOC realm. This is accomplished by adding an extension to the current routing protocols, both IGP and BGP. When an RBR receives a hIPv4 packet where the value of the destination address field in the IP header matches the local ALOC prefix, the RBR will -- contrary to the tasks defined in Section 5.2, step 3 -- look up the ELOC field in the locator header and compare this prefix against the FIB. If the next-hop entry is RBR-capable, the packet will be forwarded according to the ELOC prefix. If the next-hop is a classical IPv4 router, the RBR must apply the tasks defined in Section 5.2, step 3 and, once completed, forward the packet according to the new value in the destination address field of the IP header.
ルータのアップグレードがあるため帯域幅のために、例えば、需要増加の要求されると、改変転送プレーンは、同時にIPv4およびhIPv4転送をサポートするかもしれない - と交換サービスは、エッジに向かって及びALOCで除去し、将来的に押し込むことができます分野。これは、現在のルーティングプロトコル、IGPとBGPの両方に拡張を追加することによって達成されます。 RBRは、IPヘッダの宛先アドレスフィールドの値がローカルALOCプレフィックスと一致hIPv4パケットを受信すると、RBR意志 - セクション5.2で定義されているタスク、ステップ3に反し - でELOCフィールドをルックアップロケータヘッダとFIBに対して、この接頭辞を比較します。ネクストホップエントリはRBR-対応している場合、パケットはELOCプレフィックスに応じて転送されます。次のホップは古典的なIPv4ルータである場合は、RBRは、セクション5.2で定義されているタスクを適用するステップ3と、一度完了しなければならない、IPヘッダの宛先アドレスフィールドに新しい値に応じてパケットを転送します。
When all endpoints (that need to establish sessions outside the local ALOC realm) and infrastructure nodes in an ALOC realm are hIPv4- capable, there is no need to apply swap service for unicast sessions. Forwarding decisions can be based on information in the IP and locator headers. In the local ALOC realm, packets are routed to their upstream anycast or unicast ALOC RBR according to the ALOC prefix in the locator header; local ALOC exit routing is applied against the local ALOC FIB. Remote ELOC approach routing is applied against the ELOC FIB in the remote ALOC realm.
ALOCレルム内のすべてのエンドポイント（ローカルALOCレルム外セッションを確立することが必要）とインフラストラクチャ・ノードはhIPv4-可能である場合、ユニキャストセッションのためにスワップサービスを適用する必要はありません。転送の決定は、IPおよびロケータヘッダーの情報に基づいて行うことができます。ローカルALOC分野では、パケットがロケータヘッダ内ALOCプレフィックスに応じてその上流エニーキャスト、またはユニキャストALOCのRBRにルーティングされます。ローカルALOC出口ルーティングはローカルALOC FIBに対して適用されます。リモートELOCアプローチルーティングは、リモートALOC分野でELOC FIBに対して適用されます。
Note that IP and transport protocol headers will remain intact (except for TTL values, since the RBR is a router); only FI and LH checksum values in the locator header will alternate in local ALOC exit routing mode and remote ELOC approach routing mode.
（RBRがルータであるため、TTL値を除く）IPトランスポートプロトコルヘッダは無傷のままであろうことに留意されたいです。ロケータヘッダ内のみFI及びLHチェックサム値は、ローカルALOC出口ルーティングモードと遠隔ELOCアプローチルーティングモードに切り替わります。
Figure 2 shows a conceptual overview of the long-term hIPv4 routing architecture.
図2は、長期hIPv4ルーティングアーキテクチャの概念の概要を示します。
Legend: *attachment point in the ALOC realm UER=Unique ELOC region EP=Endpoint aRBR=anycast RBR uRBR=unicast RBR
凡例：* ALOC分野UER =ユニークELOC地域の取り付け点EP =エンドポイントaRBR =エニーキャストRBR uRBR =ユニキャストRBR
|-------------------------------------------------------------|
| UER1 | UER2 | | UER3 | UER4 |
|-------------------------------------------------------------|
| Enterprise1 | ISP1 | ISP | ISP2 | Enterprise2 |
| ALOC Realm | ALOC Realm | Tier1 | ALOC Realm | ALOC Realm |
| | | | | |
| *EP | *aRBR | | *aRBR | *EP |
| ELOC1 | ALOC1.1 | | ALOC2.1 | ELOC4 |
| | | | | |
| *uRBR | | uRBR* |
| |ALOC1.2 | | ALOC2.2| |
| | | | | |
| | *EP | | *EP | |
| | ELOC2 | | ELOC3 | |
| | | | | |
|-------------|xxxxxxxxxxxxxx DFZ xxxxxxxxxxxxxx|-------------|
| RIB | RIB | RIB | RIB | RIB |
| | | | | |
| ALOC1.2 | ALOC1.1 | ALOC1 | ALOC2.1 | ALOC2.2 |
| ELOC1 | ALOC1.2 | ALOC2 | ALOC2.2 | ELOC4 |
| | ALOC2 | | ALOC1 | |
| | ELOC2 | | ELOC3 | |
| | | | | |
|-------------------------------------------------------------|
Figure 2: Long-term routing architecture of hIPv4
図2：hIPv4の長期ルーティングアーキテクチャ
Also, the swap service for multicast can be removed when the forwarding planes are upgraded in all consequent ALOC realms. The source's ALOC RBR sets the FI-bits to 11, and a Reverse Path Forwarding (RPF) check is hereafter applied against the ALOC prefix in the locator header. Here, IP and transport protocol headers will not alternate.
転送プレーンは全て結果としてALOCレルムにアップグレードされる場合にも、マルチキャストのためのスワップ・サービスを除去することができます。ソースのALOC RBR 11にFI-ビットを設定し、リバースパス転送（RPF）チェックは以下ロケータヘッダ内ALOCプレフィックスに対して適用されます。ここでは、IPおよびトランスポートプロトコルヘッダは、代替ではないでしょう。
A long-term evolution will provide a 32x32 bit locator space. The ALOC prefixes are allocated only to service providers; ELOC prefixes are only significant at a local ALOC realm. An enterprise can use a 32-bit locator space for its private network (the ALOC prefix is rented from the attached ISP), and an ISP can use a 32-bit ELOC space to provide Internet connectivity services for its directly attached customers (residential and enterprise).
長期的な進化は、32×32ビットのロケータ空間を提供します。 ALOCプレフィックスが唯一のサービスプロバイダに割り当てられています。 ELOCプレフィックスはローカルALOC分野でのみ重要です。住宅（企業は（ALOCプレフィックスが添付ISPから借りている）そのプライベートネットワークのための32ビットのロケータスペースを使用することができ、およびISPは、その直接接続された顧客向けインターネット接続サービスを提供するために、32ビットELOCスペースを使用することができますし、企業）。
This section provides an example of a hIPv4 session between two hIPv4 endpoints: an initiator in an ALOC realm where the forwarding plane has been upgraded to support the hIPv4 framework, and a responder residing in a remote ALOC realm with the classical IPv4 forwarding plane.
転送プレーンをhIPv4フレームワークをサポートするようにアップグレードされたALOC分野で開始し、古典的なIPv4の転送プレーンと遠隔ALOC分野に存在する応答：このセクションでは、2つのhIPv4エンドポイント間hIPv4セッションの例を提供します。
When the forwarding plane at the local ALOC realm has been upgraded, the endpoints must be informed about it; that is, extensions to DHCP are needed or the endpoints are manually configured to be notified that the local ALOC realm is fully hIPv4 compliant.
ローカルALOC分野でのフォワーディングプレーンがアップグレードされた場合には、エンドポイントがそれを知らされなければなりません。つまり、DHCPへの拡張が必要とされているか、エンドポイントを手動でローカルALOCレルムが完全にhIPv4準拠していることが通知されるように構成されています。
How a hIPV4 session is established follows:
どのようにhIPV4セッションが確立され、次のとおりです。
1. The initiator queries the DNS server. The hIPv4 stack notices that the local and remote ALOCs do not match and therefore must use the hIPv4 header for the session. The hIPv4 stack of the initiator must assemble the packet as described in Section 5.2, step 1, except for the following:
1.イニシエータは、DNSサーバーを照会します。 hIPv4スタックは、ローカルおよびリモートALOCsが一致しないため、セッションのためhIPv4ヘッダーを使用しなければならないことに気付きます。セクション5.2、工程1に記載されているように、開始剤のhIPv4スタックは、以下を除いて、パケットを組み立てる必要があります。
g. Set the FI-bits of the locator header to 01.
グラム。 01にロケータヘッダのFIビットを設定します。
2. The hIPv4 packet is routed throughout the local ALOC realm according to the ALOC prefix of the locator header; local ALOC exit routing is applied.
2. IPv4パケットは、ロケータ・ヘッダのALOCプレフィックスに従ってローカルALOCレルムを介してルーティングされます。ローカルALOC出口ルーティングが適用されます。
3. The hIPv4 packet will reach the closest RBR of the local ALOC realm. When the RBR notices that the packet's ALOC prefix of the locator header matches the local ALOC prefix and the FI-bits are set to 01, the RBR must:
3. hIPv4パケットはローカルALOC分野の最も近いRBRに到達します。 RBRロケータヘッダのパケットのALOCプレフィックスがローカルALOCプレフィックスと一致し、FI-ビットが01に設定されていることに気付く場合、RBRを行う必要があります。
a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
A。受信したパケットがIPヘッダのプロトコルフィールドにhIPv4プロトコル値を使用していることを確認します。
b. Verify the IP and locator header checksums.
B。 IPロケータヘッダチェックサムを検証します。
c. Set the FI-bits of the locator header to 00.
C。 00ロケータヘッダのFIビットを設定します。
d. Decrease the TTL value by one.
D。 1によるTTL値を減らします。
e. Calculate IP and locator header checksums.
電子。 IPロケータヘッダチェックサムを計算します。
f. Forward the packet according to the value in the destination address field of the IP header.
F。 IPヘッダの宛先アドレスフィールドの値に応じてパケットを転送します。
4. The hIPv4 packet is routed to the responder as described in Section 5.2, steps 2 to 6. DFZ routing is applied.
セクション5.2で説明したように4 hIPv4パケットをレスポンダにルーティングされ、2〜6 DFZルーティングが適用されるステップ。
5. The responder's application responds to the initiator and the returning packet takes almost the same steps as described in Section 5.2 except for:
5.応答者のアプリケーションは、イニシエータに応答し、を除いて、セクション5.2で説明したように戻ったパケットは、ほぼ同じ手順を実行します。
6. The hIPv4 packet will reach the closest RBR of the initiator's ALOC realm. When the RBR notices that the value in the destination address field of the IP header matches the local ALOC prefix and the FI-bits are set to 00, the RBR must:
6. hIPv4パケットは、イニシエータのALOCレルムの最も近いRBRに到達します。 RBRは、IPヘッダの宛先アドレスフィールドの値が00に設定されているローカルALOCプレフィックスとFIビットと一致していることに気付く場合、RBRしなければなりません。
a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
A。受信したパケットがIPヘッダのプロトコルフィールドにhIPv4プロトコル値を使用していることを確認します。
b. Verify the IP and locator header checksums.
B。 IPロケータヘッダチェックサムを検証します。
c. Set the FI-bits of the locator header to 10.
C。 10にロケータヘッダのFIビットを設定します。
d. Decrease the TTL value by one.
D。 1によるTTL値を減らします。
e. Calculate IP and locator header checksums.
電子。 IPロケータヘッダチェックサムを計算します。
f. Forward the packet according to the ELOC prefix of the locator header.
F。ロケータヘッダのELOCプレフィックスに応じてパケットを転送します。
7. The hIPv4 packet is routed throughout the initiator's ALOC realm according to the ELOC prefix of the locator header. Remote ELOC approach routing is applied.
7. hIPv4パケットは、ロケータ・ヘッダのELOCプレフィックスに係るイニシエータのALOCレルムを通してルーティングされます。リモートELOCアプローチルーティングが適用されます。
8. The hIPv4 stack of the responder must present the following to the extended IPv4 socket API:
8応答のhIPv4スタックは、拡張IPv4ソケットAPIに次のように提示しなければなりません。
a. The source address of the IP header as the remote IP address.
A。リモートIPアドレスとしてIPヘッダの送信元アドレス。
b. The destination address of the IP header as the local ALOC prefix.
B。ローカルALOCプレフィックスとしてIPヘッダの宛先アドレス。
c. The ALOC prefix of the locator header as the remote ALOC prefix.
C。リモートALOCプレフィックスとしてロケータヘッダのALOCプレフィックス。
d. The ELOC prefix of the locator header as the local IP address.
D。ローカルIPアドレスとロケータヘッダのELOCプレフィックス。
The design guidelines and rationale behind decoupling the location from identification are stated in [RFC6227]. Another important influence source is the report and presentations from the [Dagstuhl] workshop that declared "a future Internet architecture must hence decouple the functions of IP addresses as names, locators, and forwarding directives in order to facilitate the growth and new network-topological dynamisms of the Internet".
識別情報から場所をデカップリングの後ろに設計ガイドラインと理論的根拠は、[RFC6227]に記載されています。もう一つの重要な影響源は、将来のインターネットアーキテクチャは、したがって成長と新しいネットワーク・トポロジカルdynamismsを容易にするために名前、ロケータ、および転送ディレクティブとしてIPアドレスの機能を分離しなければならない」と宣言[Dagstuhl]ワークショップからの報告やプレゼンテーションですインターネットの」。
Therefore, identifier elements need to be added to the hIPv4 framework to provide a path for future applications to be able to remove the current dependency on the underlying network layer addressing scheme (local and remote IP address tuple).
したがって、識別子要素は、将来のアプリケーションは、基礎となるネットワーク層アドレス指定方式（ローカルおよびリモートのIPアドレスタプル）に電流依存性を除去することができるようにするための経路を提供するhIPv4フレームワークに追加する必要があります。
However, there are various ways to apply an identifier/locator split, as discussed in an [ID/loc_Split] presentation from the MobiArch workshop at Sigcomm 2008. Thus, the hIPv4 framework will not propose or define a single identifier/locator split solution; a split can be achieved by, for example, a multipath transport protocol or by an identifier/locator database scheme such as HIP. A placeholder has been added to the locator header so identifier/locator split schemes can be integrated into the hIPv4 framework. But identifier/locator split schemes may cause privacy inconveniences, as discussed in [Mobility_&_Privacy].
したがって、hIPv4フレームワークは単一の識別子/ロケータ分離溶液を提案し、または定義しないであろうSIGCOMM 2008でMobiArchワークショップから[ID / loc_Split]プレゼンテーションで説明されているようしかし、識別子/ロケータ分離を適用する様々な方法があります。分割は、例えば、マルチパストランスポートプロトコルまたは識別子/ロケータデータベース方式では、HIPのように、によって達成することができます。識別子/ロケータ分割スキームはhIPv4フレームワークに統合することができるように、プレースホルダは、ロケータヘッダに追加されています。 [モビリティ_＆_プライバシー]で説明したようにしかし、識別子/ロケータ分離スキームは、プライバシーの不具合を引き起こす可能性があります。
Multipath transport protocols, such as SCTP and the currently under development Multipath TCP (MPTCP) [RFC6182], are the most interesting candidates to enable an identifier/locator split for the hIPv4 framework. MPTCP is especially interesting from hIPv4's point of view; one of the main goals of MPTCP is to provide backwards compatibility with current implementations: hIPv4 shares the same goal.
そのようなSCTP現在開発中のマルチTCP（MPTCP）[RFC6182]としてマルチパストランスポートプロトコルは、hIPv4フレームワークの識別子/ロケータ分離を可能にするための最も興味深い候補です。 MPTCPは、ビューのhIPv4の観点から特に興味深いものです。 MPTCPの主な目標の一つは、現在の実装との下位互換性を提供することです：hIPv4は同じ目標を共有しています。
MPTCP itself does not provide an identifier/locator database scheme as HIP does. Instead, MPTCP is proposing a token -- with local meaning -- to manage and bundle subflows under one session between two endpoints. The token can be considered to have the characteristics of a session identifier, providing a generic cookie mechanism for the application layer and creating a session layer between the application and transport layers. Thus, the use of a session identifier will provide a mechanism to improve mobility, both in site and endpoint mobility scenarios.
HIPが行うようMPTCP自体は、識別子/ロケータのデータベース・スキームを提供しません。その代わり、MPTCPは、トークンを提案している - 地元の意味で - 2つのエンドポイント間に1つのセッションでのサブフローを管理し、バンドルします。トークンは、アプリケーション層のための一般的なクッキーのメカニズムを提供し、アプリケーションとトランスポート層の間のセッション層を作成、セッション識別子の特性を有すると考えることができます。このように、セッション識別子を使用することは、両方のサイトとエンドポイントモビリティのシナリオでは、移動度を向上するためのメカニズムを提供します。
Since the session identifier improves site and endpoint mobility, routing scalability is improved by introducing a hierarchical addressing scheme, why then add an identifier/locator database scheme to the hIPv4 framework? Introducing an identifier/locator database scheme, as described in HIP, Identifier/Locator Network Protocol [ILNP] and Name-Based Sockets [NBS], might ease or remove the locator renumbering dependencies at firewalls that are used to scope security zones, but this approach would fundamentally change the currently deployed security architecture.
セッション識別子は、サイトとエンドポイントの移動度を向上させることができるので、ルーティングのスケーラビリティは、次にhIPv4フレームワークに識別子/ロケータのデータベース・スキームを追加する理由を、階層アドレッシングスキームを導入することによって改善されますか？ HIPに記載されているように、識別子/ロケータのデータベース・スキームを導入すること、識別子/ロケータネットワークプロトコル[ILNP]と名前ベースのソケット[NBS]、緩和又は除去スコープセキュリティゾーンに使用されるファイアウォールに依存関係をリナンバリングロケータを、このかもしれませんアプローチは基本的に現在展開セキュリティアーキテクチャを変更します。
However, combining an identifier/locator database scheme with DNS Security (DNSSEC) [RFC4033] is interesting. Today, security zones are scoped by using locator prefixes in the security rule sets. Instead, a Fully Qualified Domain Name (FQDN) could be used in the rule sets and the renumbering of locator prefixes would no longer depend upon the security rule sets in firewalls. Another interesting aspect is that an FQDN is and needs to be globally unique. The ALOC prefix must be globally unique, but ELOC prefixes are only regionally unique and in the long-term only locally unique. Nevertheless, combining identifier/locator database schemes with security architectures and DNSSEC needs further study.
しかしながら、[RFC4033] DNSセキュリティ（DNSSEC）と識別子/ロケータデータベース方式を組み合わせることは興味深いです。今日では、セキュリティゾーンは、セキュリティルールセットにロケータ接頭辞を使用することによってスコープされています。代わりに、完全修飾ドメイン名（FQDN）は、ルール・セットで使用することができ、ロケータプレフィックスの再番号付けは、もはやファイアウォールのセキュリティルールセットに依存しないだろう。もう一つの興味深い側面は、FQDNであり、グローバルに一意である必要があります。 ALOCプレフィックスは、グローバルに一意である必要がありますが、ELOCプレフィックスは地域ローカルでのみユニークユニークかつ長期的です。それにもかかわらず、セキュリティアーキテクチャと識別子/ロケータデータベーススキームを組み合わせ、DNSSECは、さらなる研究が必要です。
In order to provide multi-homing and mobility capabilities for single path transport protocols such as TCP and UDP, an identifier/locator database scheme is needed. This scheme can also be used to create a bidirectional NAT traversal solution with a locator translation map consisting of private locator prefixes and public identifiers at the border router.
このようなTCPやUDPなどの単一パストランスポートプロトコルのマルチホーミングおよびモビリティ機能を提供するために、識別子/ロケータのデータベース・スキームが必要とされます。この方式は、境界ルータでプライベートロケータプレフィックスと公開識別子からなるロケータ変換マップとの双方向NATトラバーサルソリューションを作成するために使用することができます。
The hIPv4 routing architecture provides only location information for the endpoints; that is, the ELOC describes how the endpoint is attached to the local network, and the ALOC prefixes describe how the endpoint is attached to the Internet. Identifier/locator split schemes are decoupled from the routing architecture -- the application layer may or may not make use of an identifier/locator split scheme.
hIPv4ルーティングアーキテクチャは、エンドポイントのための唯一の位置情報を提供します。つまり、ELOCは、エンドポイントは、ローカルネットワークに接続されている方法について説明し、及びALOCプレフィックスは、エンドポイントがインターネットに接続されている方法について説明します。識別子/ロケータ分割スキームは、ルーティングアーキテクチャから分離された - アプリケーション層または識別子/ロケータ分割方式を利用してもしなくてもよいです。
Several ALOC use cases are explored in this section. As mentioned in Section 5.1, ALOC describes an area in the Internet that can span several autonomous systems (ASes), or if the area is equal to an AS you can say that the ALOC describes an AS. When the ALOC describes an area, it is hereafter called an anycast ALOC.
いくつかのALOCユースケースは、このセクションで検討されています。 5.1節で述べたように、ALOCは、複数の自律システム（ASの）をまたがることができ、インターネットにエリアを説明し、または面積が等しい場合は、ALOCがASを記述することを言うことができますように。 ALOCエリアを記述する場合は、以下のエニーキャストALOCと呼ばれています。
The ALOC can also be used to describe a specific node between two ALOC realms, e.g., a node installed between a private and an ISP ALOC realm, or between two private ALOC realms. In this use case the ALOC describes an attachment point, e.g., where a private network is attached to the Internet. This ALOC type is hereafter called a unicast ALOC.
ALOCはまた、例えば、プライベートおよびISP ALOCレルム間、または2つのプライベートALOCレルム間に設置ノード2つのALOCレルム間の特定のノードを記述するために使用することができます。このユースケースにALOCは、プライベートネットワークがインターネットに接続されたアタッチメントポイント、例えばを、記載されています。このALOCタイプは以下のユニキャストALOCと呼ばれています。
The main difference between anycast and unicast ALOC types is:
エニーキャストとユニキャストALOC種類の主な違いは次のとおりです。
o In an anycast ALOC scenario, ELOC routing information is shared between the attached ALOC realms.
OエニーキャストALOCのシナリオでは、ELOCルーティング情報を添付ALOCレルム間で共有されます。
o In a unicast ALOC scenario, no ELOC routing information is shared between the attached ALOC realms.
OユニキャストALOCシナリオでは、ELOCルーティング情報は、添付ALOCレルム間で共有されていません。
Unicast ALOC functionalities should not be deployed between private and ISP ALOC realms in the intermediate routing architecture -- it would require too many locators from the GLB space. Instead, unicast ALOC functionality will be used to separate private ALOC realms.
ユニキャストALOCの機能は、中間ルーティングアーキテクチャでプライベートとISP ALOCレルムの間で展開されるべきではない - それはGLB空間からあまりにも多くのロケータを必要とします。代わりに、ユニキャストALOC機能はプライベートALOCレルムを分離するために使用されます。
ALOC space is divided into two types, a globally unique ALOC space (a.k.a. GLB) that is installed in DFZ, and a private ALOC space that is used inside private networks. Private ALOCs use the same locator space as defined in [RFC1918]; a private ALOC must be unique inside the private network and not overlap private ELOC prefixes. Only ISPs should be allowed to apply for global ALOC prefixes. For further discussion, see Appendix A. The ISP should aggregate global ALOC prefixes as much as possible in order to reduce the size of the routing table in DFZ.
ALOCスペースが2種類、DFZにインストールされているグローバルに一意なALOCスペース（別称、GLB）、およびプライベートネットワーク内で使用されているプライベートALOCスペースに分かれています。 [RFC1918]で定義されているプライベートALOCsは同じロケータスペースを使用します。プライベートALOCは、プライベートネットワーク内で一意で、プライベートELOC接頭辞を重複しないようにします。唯一のISPはグローバルALOCプレフィックスの申請を許可する必要があります。さらなる議論については、付録A.ザ・ISPがDFZにルーティングテーブルのサイズを小さくするために、できるだけ多くのグローバルALOCプレフィックスを集約する必要があります参照してください。
When a user logs on to the enterprise's network, the endpoint will receive the following locator prefixes via provisioning means (e.g., DHCP or manually configured):
企業のネットワークの上の際にユーザがログインすると、エンドポイントは、手段をプロビジョニングを介して（例えば、DHCPまたは手動で設定）を以下のロケータプレフィックスを受信します。
o One ELOC prefix for each network interface.
O各ネットワークインタフェースの一つELOCプレフィックス。
o One private ALOC prefix due to
O 1つのプライベート・ALOC接頭辞が原因
- The enterprise has recently been merged with another enterprise and overlapping ELOC spaces exist.
- 企業は最近、別の企業と合併されていて、重複ELOCスペースが存在します。
o Several private ALOC prefixes due to
によるOいくつかの民間ALOCプレフィックス
- The enterprise network spans high-speed long-distance connections. It is well-known that TCP cannot sustain high throughput for extended periods of time. Higher throughput might be achieved by using multiple paths concurrently.
- 企業ネットワークは、高速長距離接続にわたります。これは、TCPが長期間にわたって高いスループットを維持することができないことはよく知られています。より高いスループットは、同時に複数のパスを使用することによって達成されるかもしれません。
o One or several global ALOC prefixes. These ALOCs describe how the enterprise network is attached to the Internet.
一つまたは複数のグローバルALOCプレフィックスO。これらのALOCsは、企業ネットワークがインターネットに接続されている方法について説明します。
As the user establishes a session to a remote endpoint, DNS is usually used to resolve remote locator prefixes. DNS will return ELOC and ALOC prefixes of the remote endpoint. If no ALOC prefixes are returned, a classical IPv4 session is initiated to the remote endpoint. When ALOC prefixes are returned, the initiator compares the ALOC prefixes with its own local ALOC prefixes (that are provided via DHCP or manually configured).
ユーザーがリモートエンドポイントへのセッションを確立したよう、DNSは通常、リモートロケータ接頭辞を解決するために使用されます。 DNSは、リモートエンドポイントのELOCとALOC接頭辞を返します。何ALOC接頭辞が返されない場合は、古典IPv4のセッションがリモートエンドポイントに開始されます。 ALOCプレフィックスが返された場合、イニシエータは、（DHCP経由で提供または手動で設定されている）自身のローカルALOCプレフィックスとALOCプレフィックスを比較します。
o If the remote ALOC prefix is from the private ALOC space, the initiator will use the given private ALOC prefix for the session.
リモートALOCプレフィクスがプライベートALOC宇宙からのものである場合、O、イニシエータは、セッションのために与えられたプライベートALOCプレフィックスを使用します。
Two use cases exist to design a network to use private ALOC functionality. The remote endpoint is far away, leveraging high-speed long-distance connections, and in order to improve performance for the session a multipath transport protocol should be used.
2つの使用例は、プライベートALOC機能を使用するネットワークを設計するために存在します。リモートエンドポイントは、マルチパストランスポートプロトコルが使用されるべきセッションの性能を向上させるために高速長距離接続を活用し、そして、遠く離れています。
The other use case is when the remote endpoint resides in a network that recently has been merged and private ELOC [RFC1918] spaces overlap if no renumbering is applied. One or several unicast ALOC solutions are needed in the network between the initiator and responder. For long-distance sessions with no overlapping ELOC prefixes, anycast or unicast ALOC solutions can be deployed.
リモートエンドポイントが最近マージされないリナンバリングが適用されない場合、プライベートELOC [RFC1918]スペースが重複されたネットワーク内に存在するときに、他のユースケースです。 1つまたはいくつかのユニキャストALOC溶液は、イニシエータとレスポンダとの間のネットワークで必要とされます。無重複ELOCプレフィックス、エニーキャスト、またはユニキャストALOC溶液と長距離セッションのために展開することができます。
A third use case follows; again the initiator compares returned ALOC prefixes from DNS with its own local ALOC prefixes:
第三のユースケースは、以下;再び、イニシエータは、独自のローカルALOCプレフィックスとDNSから返さALOCプレフィックスを比較します。
o If the remote ALOC prefix is from the global ALOC space and the remote ALOC doesn't match the given global ALOC prefix, the initiator will use the given global ALOC prefix for the session.
リモートALOCプレフィクスがグローバルALOCスペースからのものであり、リモートALOCが与えられたグローバルALOCプレフィックスと一致しない場合は、O、イニシエータは、セッションのために与えられたグローバルALOCプレフィックスを使用します。
In this use case the remote endpoint resides outside the enterprise's private network, and the global remote ALOC prefixes indicate how the remote network is attached to the Internet. When a multipath transport protocol is used, the subflows can be routed via separate border routers to the remote endpoint -- both at the local and remote sites, if both are multi-homed. The initiator's egress packets in the local ALOC realm can be identified by the protocol value in the IP header, routed to an explicit path (e.g., MPLS LSP, L2TPv3 tunnel, etc.) based on the ALOC prefix in the locator header. A local ALOC overlay exit routing scheme can be designed. In the long-term routing architecture the overlay, the tunnel mechanism, can be removed; see Section 6.2.
このユースケースでは、リモートエンドポイントは、企業のプライベートネットワークの外部に存在し、グローバルな遠隔ALOCプレフィックスは、リモートネットワークがインターネットに接続されているかを示しています。マルチトランスポートプロトコルが使用されるとき、サブフローは、リモートエンドポイントに別個の境界ルータを介してルーティングすることができる - ローカルとリモートの両方のサイトで、両方がマルチホームである場合。ローカルALOC分野におけるイニシエータの出力パケットは、明示的なパスにルーティングされたIPヘッダのプロトコル値によって識別することができる（例えば、MPLS LSP、L2TPv3のトンネルなど）ロケータヘッダ内ALOCプレフィックスに基づきます。ローカルALOCオーバーレイ出口ルーティング・スキームを設計することができます。長期ルーティングアーキテクチャでオーバーレイ、トンネル機構は、除去することができます。 6.2節を参照してください。
Figure 3 shows a conceptual diagram with two endpoints having a multipath session over a VPN connection and over the Internet (in the intermediate routing architecture).
図3は、2つのエンドポイントは、（中間ルーティングアーキテクチャの）VPN接続を介して、インターネット上のマルチパスセッションを有する概念図を示します。
Legend: *attachment point in the ALOC realm UER=Unique ELOC region EP=Endpoint aRBR=anycast RBR uRBR=unicast RBR BR=Border Router
凡例：* ALOC分野UER =ユニークELOC地域の取り付け点EP =エンドポイントaRBR =エニーキャストRBR uRBR =ユニキャストRBR BR =境界ルータ
|-------------------------------------------------------------|
| UER1 | | UER2 |
|-----------------------------------------------|-------------|
| Enterprise1 | | Enterprise2 |
| ALOC Realm | | ALOC Realm |
| |---------------------------------| |
| | VPN | |
| | ALOC Realm | |
| *uRBR3 uRBR4* |
| |ALOC3 ALOC4| |
| |xxxxxxxxxxxX VPN RIB xxxxxxxxxxxx| |
| | | |
| | ALOC3 & ALOC4 | |
| |---------------------------------| |
| *EP1 | | *EP2 |
| ELOC1 |---------------------------------| ELOC2 |
| | ISP1 | ISP | ISP2 | |
| | ALOC Realm | Tier1 | ALOC Realm | |
| | | | | |
| BR1* *aRBR | | *aRBR *BR2 |
| | ALOC1 | | ALOC2 | |
| | | | | |
|-------------|xxxxxxxxxxxxxx DFZ xxxxxxxxxxxxxx|-------------|
| RIB | RIB | RIB | RIB | RIB |
| | | | | |
| ALOC1 | ALOC1 | ALOC1 | ALOC2 | ALOC2 |
| ALOC3 | ALOC2 | ALOC2 | ALOC1 | ALOC4 |
| ALOC4 | ELOC1 | | ELOC2 | ALOC3 |
| ELOC1 | | | | ELOC2 |
| | | | | |
|-------------------------------------------------------------|
Figure 3: Multi-pathing via VPN and the Internet
図3：VPNとインターネットを経由してマルチパス
The first subflow is established from the initiator (EP1) via uRBR3 and uRBR4 (both use a private unicast ALOC prefix) to the responder (EP2). Normal unicast forwarding is applied; ALOC prefixes of uRBR3 and uRBR4 are installed in the routing tables of both the local and remote ALOC realms. A second subflow is established via the Internet, that is, via BR1->BR2 to EP2. 0/0 exit routing is used to enter the Internet at both ALOC realms.
最初のサブフローは、レスポンダ（EP2）に（プライベートユニキャストALOCプレフィックスを使用両方）uRBR3およびuRBR4を介してイニシエータ（EP1）から確立されます。通常のユニキャスト転送が適用されます。 uRBR3およびuRBR4のALOCプレフィックスは、ローカルとリモートの両方のALOCレルムのルーティングテーブルにインストールされています。二サブフローはEP2にBR1-> BR2を経由して、つまり、インターネットを介して確立されます。 0/0の出口ルーティングは、ALOCレルムの両方でインターネットを入力するために使用されます。
Note that ELOC prefixes can overlap since the local and remote ALOC realms reside in different ELOC regions and are separated by private unicast ALOC prefixes.
ローカルおよびリモートALOCレルムが異なるELOC領域に存在し、プライベートユニキャストALOCプレフィクスによって分離されているのでELOCプレフィックスが重複することができることに留意されたいです。
The fourth use case is to leverage the private and global ALOC functionalities to be aligned with the design and implementation of [Split-DNS] solutions.
第四ユースケースは、[スプリットDNS]ソリューションの設計と実装を整列させるためのプライベートとグローバルALOC機能を活用することです。
The fifth use case is for residential users. A residential user may use one or several ALOC prefixes, depending upon the service offer and network design of the ISP. If the ISP prefers to offer advanced support for multipath transport protocols and local ALOC exit routing, the residential user is provided with several ALOC prefixes. The ALOC provided for residential users is taken from the GLB space and anycast ALOC functionality is applied.
第五ユースケースは、住宅のユーザー向けです。住宅の使用者は、ISPのサービス提供とネットワーク設計に応じて、一つまたは複数のALOC接頭辞を使用することができます。 ISPは、マルチパストランスポートプロトコルやローカルALOC出口ルーティングのための高度なサポートを提供することを好む場合は、住宅のユーザーは、いくつかのALOCプレフィックスを備えています。 ALOCは、住宅のユーザに提供GLB空間から取られ、エニーキャストALOC機能が適用されます。
To implement the hierarchical IPv4 framework, some basic rules are needed:
階層的なIPv4のフレームワークを実装するには、いくつかの基本的なルールが必要とされています。
1. The DNS architecture must support a new extension; an A type Resource Record should be able to associate ALOC prefixes.
1. DNSアーキテクチャは、新しい拡張機能をサポートしている必要があります。 Aタイプのリソースレコードは、ALOCプレフィックスを関連付けることができるはずです。
2. An endpoint upgraded to support hIPv4 shall have information about the local ALOC prefixes; the local ALOC prefixes can be configured manually or provided via provisioning means such as DHCP.
2. hIPv4をサポートするようにアップグレードエンドポイントは、ローカルALOCプレフィックスについての情報を持たなければなりません。ローカルALOCプレフィックスを手動で設定またはDHCPなどの手段をプロビジョニングを介して提供することができます。
3. A globally unique IPv4 address block shall be reserved; this block is called the Global Locator Block (GLB). A service provider can have one or several ALOC prefixes allocated from the GLB.
3.グローバルにユニークなIPv4アドレスブロックを予約しなければなりません。このブロックは、グローバルロケータブロック（GLB）と呼ばれています。サービスプロバイダは、GLBから割り当てられた1つのまたは複数のALOCプレフィックスを持つことができます。
4. ALOC prefixes are announced via current BGP to adjacent peers. They are installed in the RIB of the DFZ. When the hIPV4 framework is fully implemented, only ALOC prefixes are announced between the BGP peers in the DFZ.
4. ALOC接頭辞は、隣接ピアに現行のBGPを経由して発表しています。彼らはDFZのRIBにインストールされています。 hIPV4の枠組みが完全に実装されている場合は、唯一のALOCプレフィックスはDFZでBGPピア間に発表されています。
5. An ALOC realm must have one or several RBRs attached to it. The ALOC prefix is configured as an anycast IP address on the RBR. The anycast IP address is installed to appropriate routing protocols in order to be distributed to the DFZ.
5. ALOCレルムは1またはそれに接続されているいくつかのRBRSを持っている必要があります。 ALOC接頭辞はRBRのエニーキャストIPアドレスとして設定されています。エニーキャストIPアドレスがDFZに配布するために、ルーティングプロトコルを適切に設置されます。
6. The IPv4 socket API at endpoints must be extended to support local and remote ALOC prefixes. The modified IPv4 socket API must be backwards compatible with the current IPv4 socket API. The outgoing hIPv4 packet must be assembled by the hIPv4 stack with the local IP address from the socket as the source address and the remote ALOC prefix as the destination address in the IP header. The local ALOC prefix is inserted in the ALOC field of the locator header. The remote IP address from the socket API is inserted in the ELOC field of the locator header.
6.エンドポイントでのIPv4ソケットAPIは、ローカルおよびリモートALOC接頭辞をサポートするように拡張されなければなりません。変更されたIPv4ソケットAPIは、現在のIPv4ソケットAPIとの下位互換性がなければなりません。発信hIPv4パケットは、送信元アドレスとIPヘッダ内の宛先アドレスとしてリモートALOCプレフィックスとしてソケットからローカルIPアドレスをスタックhIPv4によって組み立てられなければなりません。ローカルALOCプレフィックスは、ロケータヘッダのALOCフィールドに挿入されます。ソケットAPIからリモートIPアドレスは、ロケータヘッダのELOCフィールドに挿入されます。
Since the hierarchical IPv4 framework introduces an extended addressing scheme and because DNS serves as the "phone book" for the Internet, it is obvious that DNS needs a new Resource Record (RR) type to serve endpoints that are upgraded to support hIPv4. Future RR types must follow the guidelines described in [RFC3597] and [RFC5395] with the following characteristics:
階層的なIPv4のフレームワークは、拡張アドレス指定方式を導入し、DNSはインターネットのための「電話帳」として機能するので、DNSが新しいリソースレコード（RR）がhIPv4をサポートするようにアップグレードされているエンドポイントを提供するために入力する必要のあることは明らかであるので。将来のRRタイプは、次の特性を持つ[RFC3597]で説明するガイドラインと[RFC5395]をに従う必要があります。
o Associated with the appropriate Fully Qualified Domain Name (FQDN), inserted in the NAME field.
O NAMEフィールドに挿入された適切な完全修飾ドメイン名（FQDN）、関連付けられました。
o Assigned a new integer (QTYPE) in the TYPE field, to be assigned by IANA.
O IANAによって割り当てられる、TYPEフィールドに新しい整数（QTYPE）を割り当てます。
o The CLASS field is set to IN.
O CLASSフィールドがINに設定されています。
o The RDATA field is of an unknown type as defined in [RFC3597] and shall have the following format:
[RFC3597]で定義され、次の形式を有するものとしてO RDATAフィールドは、未知のタイプのものです。
o Preference subfield: A 16-bit integer that specifies the preference given to this RR among others associated with a FQDN. Lower values are preferred over higher values.
O嗜好サブフィールド：FQDNに関連付けられ、とりわけこのRRに付与された優先度を指定する16ビット整数。低い値は高い値より優先されます。
o ALOC subfield: A 32-bit integer that specifies the Area Locator of the associated FQDN.
O ALOCサブフィールド：関連するFQDNのエリアロケータを指定する32ビット整数。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Preference |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| ALOC |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 4: RDATA format of the ALOC RR
図4：ALOC RRのRDATAフォーマット
Only endpoints that have been upgraded to support hIPv4 shall make use of the new ALOC RR. Also, there is no need to define a new ELOC RR because the A RR is used for that purpose when the ALOC RR is returned.
のみhIPv4をサポートするようにアップグレードされているエンドポイントが新しいALOC RRの使用をしなければなりません。また、ALOC RRが返されたときにA RRは、その目的のために使用されているため、新しいELOCのRRを定義する必要はありません。
Figure 5 shows how the locator header is added to the current IPv4 header, creating a hIPv4 header.
図5は、ロケータヘッダがhIPv4ヘッダを作成、現在のIPv4ヘッダに付加する方法を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|I|S| FI|VLB|L| Protocol | LH Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area Locator (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Locator (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LH Length (optional) | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: hIPv4 header
図5：hIPv4ヘッダ
Version: 4 bits
バージョン：4ビット
The Version field is identical to that of RFC 791.
バージョンフィールドは、RFC 791のものと同じです。
IHL: 4 bits
IHL：4ビット
The Internet Header Length field is identical to that of RFC 791.
インターネットヘッダ長フィールドは、RFC 791のものと同じです。
Type of Service: 8 bits
サービスの種類：8ビット
The Type of Service is identical to that of RFC 791.
サービスの種類は、RFC 791のものと同じです。
Total Length: 16 bits
全長：16ビット
The Total Length field is identical to that of RFC 791.
全長フィールドは、RFC 791のものと同じです。
Identification: 16 bits
識別：16ビット
The Identification field is identical to that of RFC 791.
識別フィールドは、RFC 791のものと同じです。
Flags: 3 bits
フラグ：3ビット
The Flags field is identical to that of RFC 791.
Flagsフィールドは、RFC 791のものと同じです。
Fragment Offset: 13 bits
フラグメントオフセット：13ビット
The Fragment Offset field is identical to that of RFC 791.
フラグメントオフセットフィールドは、RFC 791のものと同じです。
Time to Live: 8 bits
生存時間：8ビット
The Time to Live field is identical to that of RFC 791.
フィールドの生存時間は、RFC 791のものと同じです。
Protocol: 8 bits
プロトコル：8ビット
A new protocol number must be assigned for hIPv4.
新しいプロトコル番号はhIPv4のために割り当てる必要があります。
Header Checksum: 16 bits
ヘッダチェックサム：16ビット
The Header Checksum field is identical to that of RFC 791.
ヘッダチェックサムフィールドは、RFC 791のものと同じです。
Source Address: 32 bits
ソースアドレス：32ビット
The Source Address field is identical to that of RFC 791.
ソースアドレスフィールドは、RFC 791のものと同じです。
Destination Address: 32 bits
宛先アドレス：32ビット
The Destination Address field is identical to that of RFC 791.
宛先アドレスフィールドは、RFC 791のものと同じです。
Options and Padding: Variable length
オプションとパディング：可変長
The Options and Padding fields are identical to that of RFC 791.
オプションとパディングフィールドは、RFC 791のそれと同じです。
ALOC Realm Bit, A-bit: 1 bit
ALOCレルムビット、Aビット：1ビット
When the initiator and responder reside in different ALOC realms, the A-bit is set to 1 and the Area and Endpoint Locator fields must be used in the locator header. The size of the locator header is 12 bytes. When the A-bit is set to 0, the initiator and responder reside within the same ALOC realm. The Area and Endpoint Locator shall not be used in the locator header. The size of the locator header is 4 bytes.
イニシエータとレスポンダは異なるALOCレルムに存在する場合、Aビットが1にセットされ、エリアとエンドポイントロケータフィールドは、ロケータ・ヘッダに使用されなければなりません。ロケータヘッダのサイズは12バイトです。 Aビットが0に設定されている場合、イニシエータとレスポンダは同じALOC領域内に存在します。エリアとエンドポイントロケータはロケータヘッダーで使用してはなりません。ロケータヘッダのサイズは4バイトです。
Identifier Bit, I-bit: 1 bit
識別子ビット、Iビット：1ビット
The identifier bit is set to 1 if the endpoint is using an identifier/locator split scheme within the locator header. The identifier/locator split scheme must indicate by how much the size of the locator header is increased. The Locator Header Length field is also added to the locator header.
エンドポイントがロケータヘッダ内の識別子/ロケータ分割方式を使用している場合、識別子ビットが1に設定されています。識別子/ロケータ分割スキームは、ロケータヘッダのサイズが増加するどの程度によって示さなければなりません。ロケータヘッダ長フィールドは、ロケータ・ヘッダに付加されます。
Swap Bit, S-bit: 1 bit
スワップビット、Sビット：1ビット
The initiator sets the swap bit to 0 in the hIPv4 packet. An RBR will set this bit to 1 when it is swapping the source and destination addresses of the IP header with the ALOC and ELOC prefixes of the locator header.
イニシエータはhIPv4パケットにスワップビットに0をセットします。それはロケータヘッダのALOCとELOCプレフィックスとIPヘッダの送信元アドレスと宛先アドレスを交換したときRBRは、このビットを1にセットします。
Forwarding Indicator, FI-bits: 2 bits
2ビット：インジケータ、FIビットを転送します
The purpose of the Forwarding Indicator (FI) field is to provide a mechanism for a future forwarding plane to identify which Forwarding Information Base (FIB) should be used for inter-ALOC realm sessions. The new forwarding plane will remove the swap functionality of IP and locator header values for both unicast and multicast sessions. The outcome is that the IP and transport protocol headers will remain intact and only FI and LH checksum values in the locator header will alternate. The following values are defined:
転送インジケータ（FI）フィールドの目的は、インターALOCレルムセッションのために使用すべき転送情報ベース（FIB）を識別するための将来の転送プレーンのための機構を提供することです。新しい転送プレーンは、IPユニキャストとマルチキャストセッションの両方のロケータヘッダ値のスワップ機能を削除します。結果は、IPトランスポートプロトコルヘッダは無傷のままであろうとロケータヘッダ内FI及びLHチェックサム値のみが代替されることです。次の値が定義されています。
01: Local ALOC exit routing mode. The initiator shall set the FI-bits to 01 and the ALOC prefix in the locator header is used to forward the packets to the RBR that is the owner of the local ALOC prefix. The RBR shall change the FI-bits to 00.
01：ローカルALOC退出ルーティングモード。イニシエータ01にFI-ビットを設定しなければならないとロケータヘッダ内ALOCプレフィックスはローカルALOCプレフィックスの所有者であるRBRにパケットを転送するために使用されます。 RBR 00にFI-ビットを変更しなければなりません。
00: DFZ routing mode. The local ALOC RBR shall forward the packets according to the value in the destination address field of the IP header. The DFZ routers shall forward the packets based on the value in the destination address field of the IP header unless the destination address matches the local ALOC prefix. When this situation occurs, the packet enters the remote ALOC realm and the remote RBR shall change the FI-bits to 10.
00：DFZルーティングモード。ローカルALOC RBRは、IPヘッダの宛先アドレスフィールドの値に応じてパケットを転送しなければなりません。宛先アドレスがローカルALOCプレフィックスと一致しない限りDFZルータは、IPヘッダの宛先アドレスフィールドの値に基づいてパケットを転送しなければなりません。このような状況が発生すると、パケットは、リモートALOC領域に入り、遠隔RBR 10にFI-ビットを変更しなければなりません。
10: Remote ELOC approach routing mode. The remote ALOC RBR and following routers shall forward the packets based on the ELOC prefix in the locator header.
10：リモートELOCアプローチルーティングモード。リモートALOC RBRと次のルータはロケータヘッダ内ELOCプレフィックスに基づいてパケットを転送しなければなりません。
11: Inter-ALOC RPF check mode. The local ALOC RBR changes the FI-bits to 11 and the following inter-ALOC routers on the shared tree shall apply the RPF check against the ALOC prefix in the locator header.
11：インターALOC RPFチェックモード。ローカルALOC RBR 11にFI-ビットを変更し、共有ツリー上の次のインターALOCルータはロケータヘッダ内ALOCプレフィックスに対してRPFチェックを適用しなければなりません。
Valiant Load-Balancing, VLB-bits: 2 bits (optional, subject for further research)
勇敢なロードバランシング、VLBビット：2ビット（オプション、さらなる研究のために被験体）
The purpose of the Valiant Load-Balancing field is to provide a mechanism for multipath-enabled transport protocols to request explicit paths in the network for subflows, which are component parts of a session between two endpoints. The subflow path request can be set as follows:
ヴァリアントロードバランシングフィールドの目的は、マルチパス対応のトランスポート・プロトコルは、2つのエンドポイント間のセッションの構成部品であるサブフローのためのネットワーク内の明示的なパスを要求するための機構を提供することです。次のようにサブフローパス要求を設定することができます。
00: Latency-sensitive application. Only one single subflow (multipath not applied), the shortest path through the network is requested.
00：遅延の影響を受けやすいアプリケーション。単一サブフロー（マルチパスが適用されていない）だけ、ネットワークを通じて最短パスが要求されます。
01: First subflow. The shortest path or Valiant Load-Balancing might be applied.
01：まず、サブフロー。最短経路やヴァリアントロードバランシングが適用される可能性があります。
11: Next subflow(s). Valiant Load-Balancing should be applied
11：次のサブフロー（S）。ヴァリアントロードバランシングが適用されるべきです
Load-Balanced, L-bit: 1 bit (optional, subject for further research)
負荷分散、Lビット：1ビット（、任意の更なる研究のために被験体）
The initiator must set the L-bit to zero. A Valiant Load-Balancing-capable node can apply VLB switching for the session if the value is set to zero; if the value is set to 1, VLB switching is not allowed. When VLB switching is applied for the session, the node applying the VLB algorithm must set the value to 1.
イニシエータはゼロにLビットを設定しなければなりません。ヴァリアントロードバランシング対応ノードは、値がゼロに設定されている場合、セッションのためにVLBスイッチングを適用することができます。値が1に設定されている場合、VLBの切り替えが許可されていません。 VLB切り替えがセッションに適用される場合、VLBアルゴリズムを適用するノードは、値を1に設定しなければなりません。
Protocol: 8 bits
プロトコル：8ビット
The Protocol field is identical to that of RFC 791.
プロトコルフィールドは、RFC 791のものと同じです。
Locator Header Checksum: 16 bits
ロケータヘッダチェックサム：16ビット
A checksum is calculated for the locator header only. The checksum is computed at the initiator, recomputed at the RBR, and verified at the responder. The checksum algorithm is identical to that of RFC 791.
チェックサムのみロケータヘッダに対して計算されます。チェックサムは、イニシエータで算出RBRで再計算、およびレスポンダで検証されます。チェックサムアルゴリズムは、RFC 791のものと同じです。
Area Locator (optional): 32 bits
領域ロケータ（オプション）：32ビット
The Area Locator is an IPv4 address assigned to locate an ALOC realm in the Internet. The ALOC is assigned by an RIR to a service provider. The ALOC is globally unique because it is allocated from the GLB.
エリアロケータは、インターネットでALOCレルムを見つけるために割り当てられたIPv4アドレスです。 ALOCは、サービスプロバイダへのRIRによって割り当てられます。それはGLBから割り当てられているので、ALOCは、グローバルに一意です。
Endpoint Locator (optional): 32 bits
エンドポイントロケータ（オプション）：32ビット
The Endpoint Locator is an IPv4 address assigned to locate an endpoint in a local network. The ELOC block is assigned by an RIR to a service provider or to an enterprise. In the intermediate routing architecture the ELOC block is only unique in a geographical region. The final policy of uniqueness shall be defined by the RIRs. In the long-term routing architecture the ELOC block is no longer assigned by an RIR; it is only unique in the local ALOC realm.
エンドポイントロケータは、ローカルネットワーク内のエンドポイントを検索するために割り当てられたIPv4アドレスです。 ELOCブロックは、サービスプロバイダまたは企業にRIRによって割り当てられます。中間ルーティングアーキテクチャでELOCブロックは、地理的領域でのみ一意です。一意の最終方針はのRIRで定義されなければなりません。長期ルーティングアーキテクチャでELOCブロックは、もはやRIRによって割り当てられていません。それは地元のALOC分野で唯一のユニークです。
Locator Header Length (optional): 16 bits
ロケータヘッダ長（オプション）：16ビット
The Locator Header Length is the total length of the locator header. Locator Header Length is applied when the identifier bit is set to 1. Identifier/locator split scheme parameters are inserted into the locator header after this field.
ロケータヘッダ長は、ロケータヘッダの全長です。識別子ビットが1の識別子に設定されている場合、ロケータヘッダ長が適用される/ロケータ分割方式パラメータは、このフィールドの後にロケータ・ヘッダに挿入されます。
Padding (optional): variable
パディング（オプション）：変数
The locator header padding is used to ensure that the locator header ends on a 32-bit boundary. The padding is zero.
ロケータヘッダパディングはロケータヘッダが32ビット境界で終了することを保証するために使用されます。パディングはゼロです。
Because an ELOC prefix is only significant within the local ALOC realm, there is a slight possibility that a session between two endpoints residing in separate ALOC realms might use the same local and remote ELOC prefixes. But the session is still unique because the two processes communicating over the transport protocol form a logical session that is uniquely identifiable by the 5-tuple involved, by the combination of <protocol, local IP address, local port, remote IP address, remote port>.
ELOCプレフィックスがローカルALOCレルム内のみ重要であるため、別のALOCのレルムに存在する2つのエンドポイント間のセッションが同じローカルおよびリモートELOC接頭辞を使用するかもしれないというわずかな可能性があります。トランスポート・プロトコルを介して通信する2つのプロセスが<プロトコル、ローカルIPアドレス、ローカルポート、リモートIPアドレス、リモートポートの組み合わせによって、関与する5タプルによって一意に識別された論理セッションを形成するので、しかし、セッションがまだ一意です>。
The session might no longer be unique when two initiators with the same local ELOC prefix residing in two separate ALOC realms are accessing a responder located in a third ALOC realm. In this scenario, the possibility exists that the initiators will use the same local port value. This situation will cause an "identical session situation" for the application layer.
二つの別々のALOCのレルムに存在する同じローカルELOC接頭辞を持つ2つのイニシエータが第三ALOC領域に位置レスポンダをアクセスしているときに、セッションはもはや一意でないかもしれません。このシナリオでは、可能性は、開始剤は、同じローカル・ポートの値を使用すること存在します。この状況は、アプリケーション層のための「同一セッションの状況」が発生します。
To overcome this scenario, the hIPv4 stack must accept only one unique session with the help of the ALOC information. If there is an "identical session situation", i.e., both initiators use the same values in the 5-tuple <protocol, local IP address, local port, remote IP address, remote port>, the hIPv4 stack shall allow only the first established session to continue. The following sessions must be prohibited and the initiator is informed by ICMP notification about the "identical session situation".
このシナリオを克服するために、hIPv4スタックは、ALOC情報の助けを借りて、一つだけのユニークなセッションを受け入れなければなりません。 「同一セッション状況」、つまりがある場合は、両方の開始剤は、5タプルで同じ値<プロトコル、ローカルIPアドレス、ローカルポート、リモートIPアドレス、リモートポート>を使用し、hIPv4スタックは最初が確立できるようにするものセッションは続行します。次のセッションでは禁止されなければならないと、イニシエータは「同一セッション状況」についてICMP通知により通知されます。
MPTCP introduces a token that is locally significant and currently defined as 32 bits long. The token will provide a sixth tuple for future applications to identify and verify the uniqueness of a session. Thus, the probability to have an "identical session situation" is further reduced. By adding an identifier/locator database scheme to the hIPv4 framework, the "identical session situation" is completely removed.
MPTCPは、局所的に有意な、現在32ビット長として定義されているトークンを導入します。トークンは、セッションの一意性を識別し、検証するための将来のアプリケーションのための第六の組を提供します。このように、「同一セッションの状況を」持っている確率はさらに減少します。 hIPv4フレームワークの識別子/ロケータのデータベース・スキームを追加することによって、「同一セッションの状況は、」完全に除去されます。
Adding the locator header to an IPv4 packet in order to create a hIPv4 packet will increase the size of it, but since the packet is assembled at the endpoint it will not add complications of the current Path MTU Discovery (PMTUD) mechanism in the network. The intermediate network between two endpoints will not see any difference in the size of packets; IPv4 and hIPv4 packet sizes are the same from the network point of view.
hIPv4パケットを作成するためにIPv4パケットにロケータ・ヘッダを追加することの大きさを増加させるが、パケットがエンドポイントで組み立てられるので、ネットワークの現在のパスMTU探索（PMTUD）機構の複雑さを追加しないであろう。 2つのエンドポイント間の中間ネットワークは、パケットのサイズの違いは表示されません。 IPv4とhIPv4パケットサイズは、ネットワークの観点から、同一です。
There are several applications that insert IP address information to the payload of a packet. Some applications use the IP address information to create new sessions or for identification purposes. Some applications collect IP address information to be used as referrals. This section tries to list the applications that need to be enhanced; however, this is by no means a comprehensive list. The applications can be divided into five main categories:
パケットのペイロードにIPアドレス情報を挿入し、いくつかのアプリケーションがあります。一部のアプリケーションでは、新しいセッションや識別目的のために作成するために、IPアドレス情報を使用しています。一部のアプリケーションでは、紹介として使用するIPアドレス情報を収集します。このセクションでは、強化する必要があるアプリケーションの一覧を表示しようとします。しかし、これは決して包括的なリストです。アプリケーションは、5つの主要なカテゴリに分けることができます。
o Applications based on raw sockets - a raw socket receives packets containing the complete header, in contrast to the other sockets that only receive the payload.
生のソケットに基づくOアプリケーション - rawソケットは、ペイロードを受信し、他のソケットとは対照的に、完全なヘッダを含むパケットを受信します。
o Applications needed to enable the hIPv4 framework, such as DNS and DHCP databases, which must be extended to support ALOC prefixes.
ALOC接頭辞をサポートするように拡張されている必要があり、そのようなDNSやDHCPデータベースなどhIPv4フレームワークを有効にするために必要なOアプリケーション、。
o Applications that insert IP addresses into the payload or use the IP address for setting up new sessions or for some kind of identification or as referrals. An application belonging to this category cannot set up sessions to other ALOC realms until extensions have been incorporated. Within the local ALOC realm there are no restrictions since the current IPv4 scheme is still valid. The following applications have been identified:
ペイロードにIPアドレスを挿入したり、新しいセッションを設定するためのまたは識別のいくつかの種類のためか、紹介としてIPアドレスを使用するOアプリケーション。拡張機能が組み込まれているまで、このカテゴリに属するアプリケーションは、他のALOCのレルムにセッションを設定することはできません。現在のIPv4方式がまだ有効であるため、ローカルALOCレルム内で制限はありません。次のアプリケーションが確認されています。
- SIP: IP addresses are inserted in the SDP offers/answers, XML body, Contact, Via, maddr, Route, Record-Route SIP headers.
- SIP：IPアドレスが提供/回答は、XML本体、連絡先、経由、MADDR、ルート、録音・ルートSIPヘッダSDPに挿入されています。
- Mobile IP: the mobile node uses several IP addresses during the registration process.
- モバイルIP：モバイルノードは登録プロセス中に複数のIPアドレスを使用しています。
- IPsec AH: designed to detect alterations at the IP packet header.
- IPsecのAH：IPパケットのヘッダに変化を検出するように設計。
- RSVP: Resource Reservation Protocol (RSVP) messages are sent hop-by-hop between RSVP-capable routers to construct an explicit path.
- RSVP：リソース予約プロトコル（RSVP）メッセージは、明示的なパスを構築するために、ホップバイホップRSVP対応ルータとの間に送られます。
- ICMP: notifications need to be able to incorporate ALOC information and assemble the hIPv4 header in order to be routed back to the source.
- ICMP：通知はALOC情報を組み込み、バックソースにルーティングするためにhIPv4ヘッダを組み立てることができるようにする必要があります。
- Source Specific Multicast: the receiver must specify the source address.
- ソース固有マルチキャスト：受信機は、送信元アドレスを指定する必要があります。
- IGMPv3: a source-list is included in the IGMP reports.
- （注）IGMPv3：IGMPレポートでは、ソース・リストが含まれています。
o Applications related to security, such as firewalls, must be enhanced to support ALOC prefixes.
ファイアウォールなどのセキュリティに関連するOアプリケーションは、ALOC接頭辞をサポートするように拡張されなければなりません。
o Applications that will function with FQDN, but many use IP addresses instead, such as ping, traceroute, telnet, and so on. The CLI syntax needs to be upgraded to support ALOC and ELOC information via the extended socket API.
こうしたそうでping、tracerouteのは、telnet、およびなどのFQDNで機能しますOアプリケーションが、代わりに多く使用IPアドレス、。 CLIの構文は、拡張ソケットAPIを経由してALOCとELOC情報をサポートするようにアップグレードする必要があります。
At first glance, it seems that a lot of applications need to be re-engineered and ported, but the situation is not all that bad. The applications used inside the local ALOC realm (e.g., an enterprise's private network) do not need to be upgraded, neither in the intermediate nor in the long-term architecture. The classical IPv4 framework is preserved. Only IP-aware applications used between ALOC realms need to be upgraded to support the hIPv4 header. IPv6 has the definitions in place of the applications mentioned above, but the migration of applications from IPv4 to IPv6 can impose some capital expenditures for enterprises, especially if the applications are customized or homegrown; see [Porting_IPv4].
一見すると、アプリケーションの多くは再設計および移植する必要があることようだが、状況はすべてが悪いわけではありません。ローカルALOC分野（例えば、企業のプライベートネットワーク）の内部で使用されるアプリケーションは、中間でも長期的なアーキテクチャでもない、アップグレードする必要はありません。古典のIPv4枠組みは維持されます。 ALOCレルムの間で使用されるIP対応のアプリケーションのみがhIPv4ヘッダをサポートするようにアップグレードする必要があります。 IPv6は、上述したアプリケーションの代わりの定義を有するが、IPv4からIPv6へのアプリケーションの移行はアプリケーションをカスタマイズまたは自社開発している場合は特に、企業のためにいくつかの資本支出を課すことができます。 [Porting_IPv4]を参照してください。
As stated earlier, hIPv4 does not require to port applications used inside a private network. The conclusion is that, whatever next generation architecture is deployed, some applications will suffer, either during the transition period or when being re-engineered in order to be compatible with the new architecture.
先に述べたように、hIPv4は、プライベートネットワーク内で使用されるポートのアプリケーションに必要としません。結論は、次世代アーキテクチャが展開されているもの、いくつかのアプリケーションは、移行期間中に、またはときに新しいアーキテクチャと互換性を持つようにするために再設計されているいずれか、被る、ということです。
As long as the ICMP request is executed inside the local ALOC realm, the normal IPv4 ICMP mechanism can be used. As soon as the ICMP request exits the local ALOC realm, the locator header shall be used in the notifications. Therefore, extensions to the ICMP shall be implemented. These shall be compatible with [RFC4884] and support ALOC and ELOC information.
限り、ICMP要求がローカルALOCレルム内で実行されるように、通常のIPv4 ICMP機構を使用することができます。すぐにICMP要求がローカルALOCレルムを出るときに、ロケータヘッダーは、通知に使用しなければなりません。したがって、ICMPの拡張機能が実装されなければなりません。これらは、[RFC4884]と互換性があるとALOCとELOC情報をサポートしなければなりません。
Since local ELOC prefixes are only installed in the routing table of the local ALOC realm, there is a constraint with Reverse Path Forwarding (RPF) that is used to ensure loop-free forwarding of multicast packets. The source address of a multicast group (S,G) is used against the RPF check. The address of the source can no longer be used as a RPF checkpoint outside the local ALOC realm.
ローカルELOCプレフィックスのみローカルALOCレルムのルーティングテーブルにインストールされているので、マルチキャストパケットのループフリー転送を確実にするために使用されるリバースパス転送（RPF）との制約があります。マルチキャストグループ（S、G）の送信元アドレスは、RPFチェックに対して使用されます。送信元のアドレスは、もはやローカルALOC分野外のRPFチェックポイントとして使用することはできません。
To enable RPF globally for an (S,G), the multicast-enabled RBR (mRBR) must at the source's ALOC realm replace the value of the source address field in the IP header with the local ALOC prefix for inter-ALOC multicast streams. This can be achieved if the local RBR acts also as an anycast Rendezvous Point with MSDP and PIM capabilities. With these functionalities the RBR becomes a multicast-enabled RBR (mRBR). The source registers at the mRBR and a source tree is established between the source and the mRBR. When an inter-ALOC realm receiver subscribes to the multicast group, the mRBR has to swap the hIPv4 header in the following way:
（S、G）のためのグローバルRPFを有効にするには、マルチキャスト対応RBR（mRBR）は、ソースのALOC領域で相互ALOCマルチキャストストリームのローカルALOCプレフィックスとIPヘッダのソースアドレスフィールドの値を交換しなければなりません。ローカルRBRは、MSDPとPIM機能を備えたエニーキャストランデブーポイントとしても機能する場合、これが実現することができます。これらの機能によってRBRは、マルチキャスト対応RBR（mRBR）となります。ソースmRBRに登録し、ソースツリーは、ソースとmRBRとの間に確立されます。インターALOCレルムレシーバがマルチキャストグループに加入するとき、mRBRは、次のようにhIPv4ヘッダをスワップしなければなりません。
a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
A。受信したパケットがIPヘッダのプロトコルフィールドにhIPv4プロトコル値を使用していることを確認します。
b. Verify IP, locator, and transport protocol header checksums.
B。 IP、ロケータ、およびトランスポート・プロトコル・ヘッダのチェックサムを検証します。
c. Replace the source address in the IP header with the local ALOC prefix.
C。ローカルALOCの接頭辞でIPヘッダ内の送信元アドレスを交換してください。
d. Set the S-field to 1.
D。 S-フィールドを1に設定してください。
e. Decrease the TTL value by one.
電子。 1によるTTL値を減らします。
f. Calculate IP, locator, and transport protocol header checksums. Transport protocol header calculations do not include the locator header fields.
F。 IP、ロケータ、およびトランスポート・プロトコル・ヘッダのチェックサムを計算します。トランスポートプロトコルヘッダの計算は、ロケータヘッダフィールドが含まれていません。
g. Forward the packet to the shared multicast tree.
グラム。共有マルチキャストツリーにパケットを転送します。
In order for the mRBR to function as described above, the source must assemble the multicast hIPv4 packet in the following way:
上記のようにmRBRが機能するためには、ソースは次のようにマルチキャストhIPv4パケットを組み立てる必要があります。
a. Set the local IP address (S) from the API in the source address field of the IP header and in the ELOC field of the locator header.
A。 IPヘッダのソースアドレスフィールド内のロケータヘッダのELOC分野におけるAPIからローカルIPアドレス（S）を設定します。
b. Set the multicast address (G) from the API in the destination address field of the IP header.
B。 IPヘッダの宛先アドレスフィールドにAPIからマルチキャストアドレス（G）を設定します。
c. Set the local ALOC prefix in the ALOC field of the locator header.
C。ロケータヘッダーのALOCフィールドにローカルALOCプレフィックスを設定します。
d. Set the transport protocol value in the protocol field of the locator header and the hIPv4 protocol value in the protocol field of the IP header.
D。ロケータヘッダとIPヘッダのプロトコルフィールドにhIPv4プロトコル値のプロトコルフィールドにトランスポートプロトコル値を設定します。
e. Set the desired parameters in the A-, I-, S-, VLB-, and L-fields of the locator header.
電子。 A-、I-、S-、VLB-、及びロケータヘッダのLフィールドにおける所望のパラメータを設定します。
f. Set the FI-bits of the locator header to 00.
F。 00ロケータヘッダのFIビットを設定します。
g. Calculate IP, locator, and transport protocol header checksums. Transport protocol header calculations do not include the locator header fields. When completed, the packet is transmitted.
グラム。 IP、ロケータ、およびトランスポート・プロトコル・ヘッダのチェックサムを計算します。トランスポートプロトコルヘッダの計算は、ロケータヘッダフィールドが含まれていません。完了すると、パケットが送信されます。
The downstream routers from the mRBR towards the receiver will use the source address (which is the source's ALOC prefix after the mRBR) in the IP header for RPF verification. In order for the receiver to create Real-time Transport Control Protocol (RTCP) receiver reports, all information is provided in the hIPv4 header of the packet.
受信機に向かってmRBRから下流のルータは、RPF検証のためのIPヘッダ内の（mRBR後のソースのALOCプレフィクスである）送信元アドレスを使用します。リアルタイムトランスポート制御プロトコル（RTCP）受信機レポートを作成するための受信機のためのために、すべての情報は、パケットのhIPv4ヘッダに設けられています。
Because Source Specific Multicast (SSM) and IGMPv3 use IP addresses in the payload, both protocols need to be modified to support the hIPv4 framework.
ソース固有マルチキャスト（SSM）およびIGMPv3は、ペイロードにIPアドレスを使用しているため、両方のプロトコルはhIPv4フレームワークをサポートするように変更する必要があります。
When the intermediate phase of the hIPv4 framework is fully implemented, ingress load balancing to an ALOC realm can be influenced by the placement of RBRs at the realm; an RBR provides a shortest path scheme. Also, if RIR policies allow, a service provider can have several ALOCs assigned. Hence, traffic engineering and filtering can be done with the help of ALOC prefixes. For example, sensitive traffic can be aggregated under one ALOC prefix that is not fully distributed into the DFZ.
hIPv4フレームワークの中間相が完全に実装されている場合、ALOCレルムにバランス入力荷重がレルムでRBRSの配置によって影響され得ます。 RBRは、最短パス方式を提供します。 RIRのポリシーが許可する場合にも、サービスプロバイダは、割り当てられたいくつかのALOCsを持つことができます。したがって、トラフィックエンジニアリングおよびフィルタリングがALOCプレフィックスの助けを借りて行うことができます。例えば、敏感なトラフィックは、完全DFZに分配されないものALOCプレフィックスの下に集約することができます。
If needed, an ALOC traffic engineering solution between ALOC realms might be developed, to create explicit paths that can be engineered via specific ALOC prefixes. For example, develop a mechanism similar to the one described in [Pathlet_Routing]. Further studies are needed; first it should be evaluated whether there is demand for such a solution.
必要であれば、ALOCレルム間ALOCトラフィックエンジニアリング・ソリューションには、特定のALOCプレフィックスを経由して設計することができる、明示的なパスを作成するために、開発されるかもしれません。例えば、[Pathlet_Routing]に記載のものと同様の機構を開発します。さらなる研究が必要とされています。最初のそのようなソリューションの需要があるかどうかを評価すべきです。
Ingress load balancing to a private remote ALOC realm (remote site) is influenced by how many attachment points to the Internet the site uses and where the attachment points are placed at the site. In order to apply local ALOC exit routing, e.g., from a multi-homed site, some new network nodes are needed between the initiator and the border routers of the site.
プライベートリモートALOC分野（リモートサイト）に均衡イングレス負荷がどのように多くの添付ファイルのポイント、インターネットにサイトを使用して、どこで付着点がサイトに配置されている影響を受けています。ローカルALOC出口ルーティングを適用するために、例えば、マルチホームサイトから、いくつかの新しいネットワーク・ノードは、イニシエータとサイトの境界ルータとの間で必要とされています。
In the intermediate routing architecture this is achieved by using overlay architectures such as MPLS LSP, L2TPv3 tunnels, etc. The new network node(s) shall be able to identify hIPv4 packets, based on the protocol field in the IP header, and switch the packets to explicit paths based on the ALOC prefix in the locator header. In the long-term routing architecture the overlay solution is replaced with a new forwarding plane; see Section 6.2.
中間ルーティングアーキテクチャでは、これは等MPLS LSP、L2TPv3のトンネル、新たなネットワーク・ノード（単数または複数）のIPヘッダのプロトコルフィールドに基づいて、hIPv4パケットを識別し、切り替えることができなければならないようなオーバーレイ・アーキテクチャを使用することによって達成されますロケータヘッダ内ALOCプレフィックスに基づいて明示的なパスへのパケット。長期ルーティングアーキテクチャでオーバーレイ溶液は新しい転送プレーンで置換されています。 6.2節を参照してください。
Together with a multipath transport protocol, the subflows can be routed via specific attachment points, that is, border routers sitting between the private local/remote ALOC realms (multi-homed sites) and the Internet. Multi-homing becomes multi-pathing. For details, see Appendix B.
一緒にマルチパストランスポートプロトコルで、サブフローは、特定のアタッチメントポイントを経由してルーティングすることができ、それは、民間のリモート/ローカルALOCレルム（マルチホームのサイト）とインターネットの間に座って境界ルータです。マルチホーミングは、マルチパスになります。詳細については、付録Bを参照してください。
The use of multipath-enabled transport protocols opens up the possibility to develop a new design methodology of backbone networks, based on Valiant Load-Balancing [VLB]. If two sites that are connected with a single uplink to the Internet, and the endpoints are using multipath-enabled transport protocols and are attached to the network with only one interface/ELOC-prefix, both subflows will most likely take the shortest path throughout the Internet. That is, both subflows are established over the same links and when there is congestion on a link or a failure of a link, both subflows might simultaneously drop packets. Thus, the benefit of multi-pathing is lost.
マルチパス対応のトランスポートプロトコルの使用はヴァリアントロードバランシング[VLB]に基づいて、バックボーンネットワークの新しい設計手法を開発する可能性を開きます。 2つのインターネットへの単一のアップリンクに接続されているサイト、およびエンドポイントは、マルチパス対応のトランスポートプロトコルを使用していて、1つのインターフェイスだけ/ ELOC-prefixでネットワークに接続されている場合、両方のサブフローは、最も可能性の高い全体に最短経路を取りますインターネット。これは、両方のサブフローは、同じリンク上に確立され、リンクまたはリンクの障害に輻輳がある場合には、両方のサブフローが同時にパケットをドロップする可能性があります。このように、マルチパスの利点が失われます。
The "subflows-over-same-links" scenario can be avoided if the subflows are traffic engineered to traverse the Internet on different paths, but this is difficult to achieve by using classical traffic engineering, such as IGP tuning or MPLS-based traffic engineering. By adding a mechanism to the locator header, the "subflows-over-same-links" scenario might be avoided.
サブフローは、トラフィックが異なるパスでインターネットを横断するために設計され、これは、このようなIGPのチューニングやMPLSベースのトラフィックエンジニアリングなど、古典トラフィックエンジニアリングを使用することによって達成することが困難である場合、「サブフローオーバー同じリンク」のシナリオを回避することができます。ロケータヘッダに機構を追加することによって、「サブフローオーバー同じリンク」のシナリオを回避するかもしれません。
If the RBR functionality is deployed on a Valiant Load-Balancing enabled backbone node -- hereafter called vRBR -- and the backbone nodes are interconnected via logical full meshed connections, Valiant Load-Balancing can be applied for the subflows. When a subflow has the appropriate bits set in the VLB-field of the locator header, the first ingress vRBR shall do VLB switching of the subflow. That is, the ingress vRBR is allowed to do VLB switching of the subflow's packets if the VLB-bits are set to 01 or 11, the L-bit is set to 0, and the local ALOC prefix of the vRBR matches the ALOC-field's prefix. If there are no ALOC and ELOC fields in the locator header, but the other fields' values are set as described above, the vRBR should apply VLB switching as well for the subflow -- because it is an intra-ALOC realm subflow belonging to a multipath-enabled session.
以下vRBR呼ばれる - - RBR機能がヴァリアントロードバランシング有効バックボーンノードにデプロイされている場合は、バックボーン・ノードの論理完全噛合接続を介して相互に接続され、ヴァリアントロードバランシングは、サブフローに適用することができます。サブフローは、ロケータヘッダのVLBフィールドに設定された適切なビットを有する場合、第1の入口vRBRは、サブフローのVLB切り替えを行うものとします。 VLBビットが01または11に設定されている場合には、入口vRBRがサブフローのパケットのVLB切り替えを行うことが許可されている、Lビットは0に設定され、vRBRのローカルALOCプレフィックスはALOCフィールドのと一致しています接頭辞。そこロケータヘッダにはALOCとELOCフィールドはありませんが、上記のように他のフィールドの値が設定され、vRBRはサブフローのために同様にスイッチングVLBを適用する必要がある場合 - それが属するイントラALOCレルムサブフローであるためマルチパス対応のセッション。
With this combination of parameters in the locator header, the subflow is VLB switched only at the first ALOC realm and the subflows might be routed throughout the Internet on different paths. If VLB switching is applied at every ALOC realm, this would most likely add too much latency for the subflows. The VLB switching at the first ALOC realm will not separate the subflows on the first and last mile links (site with a single uplink). If the subflows on the first and last mile link need to be routed on separate links, the endpoints should be deployed in a multi-homed environment. Studies on how Valiant Load-Balancing is influencing traffic patterns between interconnected VLB [iVLB] backbone networks have been done. Nevertheless, more studies are needed regarding Valiant Load-Balancing scenarios.
ロケータ・ヘッダ内のパラメータの組み合わせと、サブフローはVLBは、第ALOC領域でのみ切り替えられ、サブフローは異なる経路にインターネットを通してルーティングされるかもしれません。 VLBの切り替えは、すべてのALOC分野で適用されている場合は、これが最も可能性が高いサブフローのためにあまりにも多くの遅延を追加します。最初ALOC領域でのVLBの切り替えは、最初と最後のマイルへのリンク（単一のアップリンクを持つサイト）にサブフローを分離しません。最初と最後のマイルリンク上のサブフローが個別のリンクにルーティングする必要がある場合は、エンドポイントはマルチホーム環境に展開する必要があります。ヴァリアントロードバランシングが相互接続VLB [iVLB]バックボーンネットワーク間のトラフィックパターンに影響を与えているかについての研究が行われています。それにも関わらず、多くの研究がヴァリアントロードバランシングのシナリオに関して必要とされています。
This section considers two types of mobility solutions: site mobility and endpoint mobility.
サイトのモビリティとエンドポイントの移動性：このセクションでは、モビリティソリューションの2種類を検討します。
Site mobility:
サイトのモビリティ：
Today, classical multi-homing is the most common solution for enterprises that wish to achieve site mobility. Multi-homing is one of the key findings behind the growth of the DFZ RIB; see [RFC4984], Sections 2.1 and 3.1.2. The hIPv4 framework can provide a solution for enterprises to have site mobility without the requirement of implementing a classical multi-homed solution.
今日では、古典マルチホーミングは、サイトのモビリティを実現したい企業のための最も一般的なソリューションです。マルチホーミングはDFZ RIBの成長の背後にある主要な調査結果の一つです。 [RFC4984]を参照してください、セクション2.1および3.1.2。企業は、古典的なマルチホームのソリューションを実装する必要なく、サイトの移動性を持っているためhIPv4フレームワークは、ソリューションを提供することができます。
One of the reasons to deploy multi-homing is to avoid renumbering of the local infrastructure when an upstream ISP is replaced. Thus, today, PI-address blocks are deployed at enterprises. In the intermediate routing architecture, an enterprise is allocated a regional PI ELOC block (for details, see Appendix A) that is used for internal routing. The upstream ISP provides an ALOC prefix that describes how the enterprise's network is connected to the Internet. If the enterprise wishes to switch to another ISP, it only changes the ALOC prefix at endpoints, from the previous ISP's ALOC prefix to the new ISP's ALOC prefix, without connectivity interruptions in the local network since the ALOC prefix is only used for Internet connectivity -- several ALOCs can be used simultaneously at the endpoints; thus, a smooth migration from one ISP to another is possible. In the long-term routing architecture, when the forwarding plane is upgraded, the regional PI ELOC block is returned to the RIR and the enterprise can use a full 32-bit ELOC space to design the internal routing topology.
マルチホーミングを展開する理由の一つは、上流のISPが交換されたときに、ローカルインフラのリナンバリングを回避することです。このように、今日は、PIアドレスブロックは、企業で導入されています。中間ルーティングアーキテクチャでは、企業は、内部ルーティングのために使用される（詳細については、付録Aを参照）地域のPI ELOCブロックが割り当てられます。上流のISPは、企業のネットワークがインターネットに接続されている方法について説明しALOCプレフィックスを提供します。企業が別のISPに切り替えることを望む場合ALOCプレフィックスが唯一のインターネット接続に使用されているので、それだけで、ローカルネットワーク内の接続の中断せずに、以前のISPのALOCプレフィックスから新しいISPのALOCのプレフィックスに、エンドポイントでALOCプレフィックスを変更します - - いくつかのALOCsは、エンドポイントで同時に使用することができます。従って、別のISPからのスムーズな移行が可能です。転送プレーンがアップグレードされたとき、長期ルーティングアーキテクチャでは、地域のPI ELOCブロックがRIRに戻され、企業は、内部ルーティングトポロジを設計するために完全な32ビットELOC空間を使用することができます。
An enterprise can easily become multi-homed or switch ISPs. The local ELOC block is used for internal routing and upstream ISPs provide their ALOC prefixes for Internet connectivity. Multi-homing is discussed in detail in Appendix B.
企業は容易にマルチホームになるかのISPを切り替えることができます。ローカルELOCブロックは、内部ルーティングのために使用され、上流のISPがインターネット接続のために彼らのALOCプレフィックスを提供します。マルチホーミングは、付録Bで詳しく説明されています
Endpoint mobility:
エンドポイントの移動性：
As said earlier, MPTCP is the most interesting identifier/locator split scheme to solve endpoint mobility scenarios. MPTCP introduces a token, which is locally significant and currently defined as 32 bits long. The token will provide a sixth tuple to identify and verify the uniqueness of a session. This sixth tuple -- the token -- does not depend upon the underlying layer, the IP layer. The session is identified with the help of the token and thus the application is not aware when the locator parameters are changed, e.g., during a roaming situation, but it is required that the application is not making use of ELOC/ALOC information. In multi-homed scenarios, the application can make use of ELOC information, which will not change if the endpoint is fixed to the location.
先に述べたように、MPTCPは、エンドポイントのモビリティのシナリオを解決するための最も興味深いの識別子/ロケータ分離方式があります。 MPTCPは、局所的に有意な、現在32ビット長として定義されているトークンを導入します。トークンは、セッションの一意性を識別し、検証するための第六のタプルを提供します。この第六組 - トークンが - 、下地層、IP層に依存しません。セッションは、トークンの助けを借りて識別されるため、アプリケーションは、ロケータパラメータは、ローミング状況の間に、例えば、変更されたときに認識していないが、アプリケーションがELOC / ALOC情報を利用していないことが必要です。マルチホームシナリオでは、アプリケーションは、エンドポイントが位置に固定されている場合は変更されないELOC情報を利用することができます。
Security issues arise: the token can be captured during the session by, for example, a man-in-the-middle attack. These attacks can be mitigated by applying [tcpcrypt], for example. If the application requires full protection against man-in-the-middle attacks, the user should apply the Transport Layer Security Protocol (TLS) [RFC5246] for the session.
セキュリティの問題が発生：トークンは、man-in-the-middle攻撃、例えば、によってセッション中に取得することができます。これらの攻撃は、たとえば、[tcpcrypt]を適用することによって緩和することができます。アプリケーションは、man-in-the-middle攻撃に対する完全な保護を必要とする場合、ユーザーはセッションのためのトランスポート層セキュリティプロトコル（TLS）[RFC5246]を適用する必要があります。
The most common endpoint mobility use case today is that the responder resides in the fixed network and the initiator is mobile. Thus, MPTCP will provide roaming capabilities for the mobile endpoint, if both endpoints are making use of the MPTCP extension. However, in some use cases, the fixed endpoint needs to initialize a session to a mobile responder. Therefore, Mobile IP (MIP) [RFC5944] should incorporate the hIPv4 extension -- MIP provides a rendezvous service for the mobile endpoints.
最も一般的なエンドポイントモビリティユースケース今日は、レスポンダは、固定ネットワーク内に存在し、イニシエータがモバイルであるということです。両方のエンドポイントがMPTCP拡張を利用している場合はこのように、MPTCPは、モバイルエンドポイントのローミング機能を提供します。しかし、いくつかのユースケースでは、固定エンドポイントは、モバイルレスポンダにセッションを初期化する必要があります。 MIPは、モバイルエンドポイントのランデブーサービスを提供する - したがって、モバイルIP（MIP）[RFC5944]はhIPv4拡張を組み込むべきです。
Also, many applications provide rendezvous services for their users, e.g., SIP, peer-to-peer, Instant Messaging services. A generic rendezvous service solution can be provided by an identifier/locator database scheme, e.g., HIP, ILNP, or NBS. If desired, the user (actually the application) can make use of one of these rendezvous service schemes, such as extended MIP, some application-specific rendezvous services, or a generic rendezvous service -- or some combination of them.
また、多くのアプリケーションは、SIP、ピア・ツー・ピア、インスタントメッセージングサービス、例えば、そのユーザのためのランデブーサービスを提供します。汎用ランデブー・サービス・ソリューションは、識別子/ロケータデータベース方式、例えば、HIP、ILNP、またはNBSによって提供することができます。またはそれらの組み合わせ - 必要に応じて、ユーザー（実際にアプリケーション）は、このような拡張MIP、いくつかのアプリケーション固有のランデブーサービス、または一般的なランデブーサービスとしてこれらのランデブーサービススキームの1つの使用をすることができます。
The hIPv4 framework will not define which identifier/locator split solution should be used for endpoint mobility. The hIPv4 framework is focusing on routing scalability and supports several identifier/locator split solutions that can be exploited to develop new services, with the focus on endpoint mobility.
hIPv4フレームワークは、エンドポイントの移動のために使用されるべき識別子/ロケータ分離溶液定義しないであろう。 hIPv4フレームワークは、エンドポイントの移動性に焦点を当てて、スケーラビリティをルーティングに焦点を当て、新たなサービスを開発するために利用することができますいくつかの識別子/ロケータ分離ソリューションをサポートしています。
The hIPv4 framework is not introducing any new protocols that would be mandatory for the transition from IPv4 to hIPv4; instead, extensions are added to existing protocols. The hIPv4 framework requires extensions to the current IPv4 stack, to infrastructure systems, and to some applications that use IP address information, but the current forwarding plane in the Internet remains intact, except that a new forwarding element (the RBR) is required to create an ALOC realm.
hIPv4フレームワークは、IPv4からhIPv4への移行のために必須であろう任意の新しいプロトコルを導入していません。代わりに、拡張は既存のプロトコルに追加されます。 hIPv4フレームワークは、インフラシステム、およびIPアドレス情報を使用するいくつかのアプリケーションには、現在のIPv4スタックへの拡張が必要ですが、インターネットで現在のフォワーディングプレーンはそのまま残り、新しい転送要素（RBR）を作成するために必要であることを除き、 ALOC分野。
Extensions to the IPv4 stack, to infrastructure systems, and to applications that make use of IP address information can be deployed in parallel with the current IPv4 framework. Genuine hIPv4 sessions can be established between endpoints even though the current unidimensional addressing structure is still present.
IPアドレス情報を利用するIPv4スタックに、インフラシステム、およびアプリケーションへの拡張は、現在のIPv4フレームワークと並行して展開することができます。本物のhIPv4セッションは、現在の一次元のアドレス指定構造がまだ存在するにもかかわらず、エンドポイント間で確立することができます。
When will the unidimensional addressing structure be replaced by a hierarchical addressing scheme and a fourth hierarchy added to the routing architecture? The author thinks there are two possible tipping points:
場合一次元アドレッシング構造は、階層アドレッシングスキームにより置換第四階層ルーティングアーキテクチャに追加されるのだろうか？著者は、2つの可能な転換点があると考えて：
o When the RIB of DFZ is getting close to the capabilities of current forwarding planes. Who will pay for the upgrade? Or will the service provider only accept ALOC prefixes from other service providers and avoid capital expenditures?
O DFZのRIBは、現在の転送プレーンの能力に近づいているとき。アップグレードのために誰が支払うのでしょうか？またはサービスプロバイダは他のサービスプロバイダからALOCプレフィックスを受け入れ、資本支出を避けることができますか？
o When the depletion of IPv4 addresses is causing enough problems for service providers and enterprises.
O IPv4アドレスの枯渇は、サービスプロバイダーや企業のための十分な問題を引き起こしているとき。
The biggest risk and reason why the hIPv4 framework will not succeed is the very short time frame until the expected depletion of the IPv4 address space occurs -- actually the first RIR has run out of IPv4 addresses during the IESG review process of this document (April 2011). Also, will enterprises give up their global allocation of the current IPv4 address block they have gained, as an IPv4 address block has become an asset with an economical value.
IPv4アドレス空間の予想枯渇が発生するまでhIPv4フレームワークが成功しない理由の最大のリスクとその理由は、非常に短い時間枠である - 実際に最初のRIRは、この文書（4月のIESGレビュープロセスの間に、IPv4アドレスの不足しています2011）。 IPv4アドレスブロックは、経済的価値を持つ資産となっているとしても、企業は、彼らが得た現在のIPv4アドレスブロックの彼らの世界的な配分を放棄します。
The transition requires the upgrade of endpoint's stack, and this is a drawback compared to the [CES] architectures proposed in [RFC6115]. A transition to an architecture that requires the upgrade of endpoint's stack is considerably slower than an architecture that requires only upgrade of some network nodes. But the transition might not be as slow or challenging at it first seems since hIPv4 is an evolution of the current deployed Internet.
トランジションは、エンドポイントのスタックのアップグレードを必要とし、これは[RFC6115]で提案されている[CES]のアーキテクチャに比べて欠点です。エンドポイントのスタックのアップグレードを必要とするアーキテクチャへの移行は、いくつかのネットワークノードのアップグレードのみを必要とするアーキテクチャよりもかなり遅いです。しかし、移行はhIPv4は、現在展開され、インターネットの進化であるので、それは最初に思えるのように遅いか、挑戦的ではないかもしれません。
o Not all endpoints need to be upgraded; the endpoints that do not establish sessions to other ALOC realms can continue to make use of the classical IPv4 framework. Also, legacy applications that are used only inside a local ALOC realm do not need to be ported to another framework. For further details, see Appendix C.
Oすべてのエンドポイントをアップグレードする必要があるわけではありません。他のALOCレルムにセッションを確立していないエンドポイントは、古典的なIPv4のフレームワークを利用するために続けることができます。また、地元のALOC領域内でのみ使用されているレガシーアプリケーションは、別のフレームワークに移植する必要はありません。詳細については、付録Cを参照してください。
o Upgrading endpoint's stack, e.g., at critical or complicated systems, will definitely take time; thus, it would be more convenient to install a middlebox in front of such systems. It is obvious that the hIPv4 framework needs a middlebox solution to speed up the transition; combining CES architectures with the hIPv4 framework might produce such a middlebox. For further details, see Appendix D.
エンドポイントのスタックをアップグレードO、例えば、重要または複雑なシステムでは、間違いなく時間がかかります。したがって、このようなシステムの前にミドルをインストールする方が便利だろう。 hIPv4フレームワークは、遷移を高速化するミドル溶液が必要であることは明らかです。 hIPv4フレームワークとCESアーキテクチャを組み合わせることは、このようなミドルが生じる可能性があります。詳細については、付録Dを参照してください。
o The framework is incrementally deployable. Not all endpoints in the Internet need to be upgraded before the first IPv4 block can be released from a globally unique allocation status to a regionally unique allocation status. That is, to achieve ELOC status for the prefixes used in a local network in the intermediate routing architecture, see Appendix D. An ALOC realm that wishes to achieve local unique status for its ELOC block in the long-term routing architecture does not need to wait for other ALOC realms to proceed to the same level simultaneously. It is sufficient that the other ALOC realms have achieved the intermediate routing architecture status. For further details, see Section 6.
Oフレームワークは、増分展開可能です。ないインターネット内のすべてのエンドポイントは、最初のIPv4ブロックが地域独特の割り当て状況にグローバルに一意の割り当て状態から解放される前にアップグレードする必要があります。これは、中間ルーティングアーキテクチャのローカルネットワークで使用されるプレフィックスのELOCの状態を達成するために、ある、する必要はありません長期的なルーティングアーキテクチャにおけるそのELOCブロックのために地元のユニークな地位を達成したい付録D.アンALOCレルムを参照してください同時に同じレベルに進むために、他のALOCレルムのを待ちます。他のALOCレルムは、中間ルーティングアーキテクチャ状態を達成していることで十分です。詳細については、第6章を参照してください。
Because the hIPv4 framework does not introduce other network mechanisms than a new type of border router to the currently deployed routing architecture, the best current practices for securing ISP networks are still valid. Since the DFZ will no longer contain ELOC prefixes, there are some benefits and complications regarding security that need to be taken into account.
hIPv4フレームワークは、現在展開ルーティングアーキテクチャの境界ルータの新しいタイプ以外のネットワークの仕組みを導入していないため、ISPネットワークを保護するための最良の現在のプラクティスはまだ有効です。 DFZは、もはやELOCプレフィックスを含まないので、考慮に入れる必要があるセキュリティに関するいくつかの利点と合併症があります。
The hijacking of a single ELOC prefix by longest match from another ALOC realm is no longer possible because the prefixes are separated by a locator, the ALOC. To carry out a hijack of a certain ELOC prefix, the whole ALOC realm must be routed via a bogus ALOC realm. Studies should be done with the Secure Inter-Domain Routing (SIDR) working group to determine whether the ALOC prefixes can be protected from hijacking.
接頭辞がロケータ、ALOCで区切られているので、他のALOC分野から最長一致することにより、単一のELOCプレフィックスのハイジャックは、もはや不可能です。特定のELOCプレフィックスのハイジャックを実行するために、全体ALOCレルムは偽のALOC領域を経由してルーティングする必要があります。研究は、ALOCプレフィックスがハイジャックから保護することができるかどうかを判断するためにセキュアなドメイン間ルーティング（SIDR）ワーキンググループで行われるべきです。
By not being able to hijack a certain ELOC prefix, there are some implications when mitigating distributed denial-of-service (DDoS) attacks. This implication occurs especially in the long-term routing architecture, e.g., when a multi-homed enterprise is connected with unicast ALOC RBRs to the ISPs.
分散型サービス拒否（DDoS）攻撃を軽減する際に、特定のELOCプレフィックスをハイジャックすることができないことで、いくつかの意味があります。マルチホーム企業がISPにユニキャストALOC RBRSと接続されている場合、この意味は、例えば、特に長期のルーティングアーキテクチャで起こります。
One method used today to mitigate DDoS attacks is to inject a more specific prefix (typically host prefix) to the routing table so that the victim of the attack is "relocated", i.e., a sinkhole is created in front of the victim. The sinkhole may separate bogus traffic from valid traffic or analyze the attack. The challenge in the long-term routing architecture is how to reroute a specific ELOC prefix of the multi-homed enterprise when the ELOC prefix cannot be installed in the ISP's routing table.
DDoS攻撃を軽減するために、今日使用される1つの方法は、攻撃の犠牲者は、すなわち、陥没穴は、被害者の前に作成され、「移転」されるように、ルーティングテーブルに（通常は接頭辞をホスティング）、より具体的な接頭辞を注入することです。陥没穴は、有効なトラフィックから偽のトラフィックを分離したり、攻撃を分析することができます。長期的なルーティングアーキテクチャの課題は、ELOCプレフィックスはISPのルーティングテーブルにインストールすることができないときマルチホーム企業の具体的なELOCプレフィックスを再ルーティングする方法です。
Creating a sinkhole for all traffic designated to an ALOC realm might be challenging and expensive, depending on the size of the multi-homed enterprise. To have the sinkhole at the enterprise's ALOC realm may saturate the connections between the enterprise and ISPs, thus this approach is not a real option.
ALOCレルムに指定されたすべてのトラフィックのための陥没穴を作成すると、マルチホーム企業の大きさに応じて、挑戦し、高価になるかもしれません。企業のALOC分野での陥没穴は、企業やISP間の接続を飽和さも持っているために、このように、このアプローチは現実的な選択肢ではありません。
By borrowing ideas from a service-centric networking architecture [SCAFFOLD], a sinkhole service can be created. An example of how a distributed sinkhole service can be designed follows:
サービス中心のネットワークアーキテクチャ[足場]からアイデアを借りて、陥没穴のサービスを作成することができます。分散型シンクホールサービスを設計することができる方法の例を以下に示します。
a. A firewall (or similar node) at the victim's ALOC realm discovers an attack. The security staff at the enterprise realizes that the amount of the incoming traffic caused by the attack is soon saturating the connections or other resources. Thus, the staff informs the upstream ISPs of the attack, also about the victim's ALOC prefix X and ELOC prefix Y.
A。被害者のALOCレルムでのファイアウォール（または類似ノード）が攻撃を検出します。企業のセキュリティ担当者は、攻撃によって引き起こされる着信トラフィックの量はすぐに接続またはその他のリソースが飽和していることを実現しています。このように、スタッフも、被害者のALOCプレフィックスXとELOCプレフィックスY.については、攻撃の上流のISPに通知します
b. The ISP reserves the resources for the sinkhole service. These resources make use of ALOC prefix Z; the resources are programmed with a service ID and the victim's X and Y prefixes. The ISP informs the victim's security staff of the service ID. The ISP applies a NAT rule on their RBRs and/or hIPv4-enabled routers. The NAT rule replaces the destination address in the IP header of packets with Z when the destination address of the IP header matches X and the ELOC prefix of the locator header matches Y. Also, the service ID is inserted to the locator header; the service ID acts as a referral for the sinkhole. It is possible that the sinkhole serves several victims; thus, a referral is needed. PMTUD issues must be taken into account.
B。 ISPは、シンクホールサービスのためのリソースを予約します。これらのリソースは、ALOCプレフィックスZを利用します。リソースは、サービスIDと被害者のXとYの接頭辞を使ってプログラムされています。 ISPは、サービスIDの被害者のセキュリティスタッフを通知します。 ISPは、彼らのRBRSおよび/またはhIPv4対応ルータ上のNATルールを適用します。 IPヘッダの宛先アドレスがXと一致し、ロケータヘッダのELOCプレフィックスは、サービスIDがロケータヘッダに挿入され、また、Y.と一致する場合、NATルールは、Zと、パケットのIPヘッダ内の宛先アドレスを置き換えます。サービスIDは、陥没穴のための紹介として機能します。陥没穴は、いくつかの犠牲者を果たすことは可能です。このように、紹介が必要とされています。 PMTUDの問題を考慮する必要があります。
c. The victim's inbound traffic is now routed at the RBRs and/or hIPv4-enabled routers to the sinkhole(s); the traffic is identified by the service ID. Bogus traffic is discarded at the sinkhole, for valid traffic the value of the destination address in the IP header Z is replaced with X. By using a service ID in the analyzed packets, the enterprise is informed that the packets containing service ID are valid traffic and allowed to be forwarded to the victim. It might be possible that not all upstream ISPs are redirecting traffic to the distributed sinkholes. Thus, traffic that does not contain the agreed service ID might be bogus. Also, by inserting a service ID to the valid packets, overlay solutions between the routers, sinkholes, and victim can be avoided. In case the valid packet with a service ID traverses another RBR or hIPv4-enabled router containing the same NAT rule, that packet is not rerouted to the sinkhole. The enterprise shall ensure that the victim does not use the service ID in its replies -- if the attacker becomes aware of the service ID, the sinkhole is disarmed.
C。被害者のインバウンドトラフィックが今シンクホール（複数可）にRBRSおよび/またはhIPv4対応ルータでルーティングされます。トラフィックは、サービスIDによって識別されます。偽のトラフィックを解析し、パケット内のサービスIDを使用することにより、有効なトラフィックのためにIPヘッダZの宛先アドレスの値がXで置換され、陥没穴に廃棄され、企業は、サービスIDを含むパケットが有効なトラフィックであることを通知されますそして被害者に転送することができました。ない、すべての上流のISPが分散陥没穴にトラフィックをリダイレクトしている可能性があります。このように、合意されたサービスIDが含まれていないトラフィックは、偽のかもしれません。また、有効なパケットにサービスIDを挿入することにより、ルータ、陥没穴、と被害者の間のオーバーレイソリューションを回避することができます。場合は、サービスIDを持つ有効なパケットは、パケットがシンクホールに再ルーティングされていないことと同じNATルールを含む別のRBRまたはhIPv4対応ルータを通過します。シンクホールが解除され、攻撃者がサービスIDに気付いた場合 - 企業は、被害者がその応答でサービスIDを使用していないことを保証しなければなりません。
Today, traffic is sent to sinkholes by injecting host routes into the routing table. This method can still be used inside an ALOC realm for intra-ALOC attacks. For attacks spanning over several ALOC realms new methods are needed; one example is described above. It is desirable that the RBR and hIPv4-enabled routers are capable of applying NAT rules and inserting service ID to selected packets in the forwarding plane.
今日では、トラフィックをルーティングテーブルにホストルートを注入することにより、陥没穴に送信されます。この方法では、まだ、イントラALOC攻撃にALOC領域内で使用することができます。いくつかのALOCの上にまたがる攻撃するための新しい方法が必要とされているレルム。一例は、上述されています。 RBRとhIPv4対応ルータは、NATルールを適用し、転送プレーン内の選択されたパケットにサービスIDを挿入することが可能であることが望ましいです。
This document offers a high-level overview of the hierarchical IPv4 framework that could be built in parallel with the current Internet by implementing extensions at several architectures. Implementation of the hIPv4 framework will not require a major service window break in the Internet or at the private networks of enterprises. Basically, the hIPv4 framework is an evolution of the current IPv4 framework.
このドキュメントは、いくつかのアーキテクチャでの拡張機能を実装することによって、現在のインターネットと並行して構築することができ、階層のIPv4フレームワークの高レベルの概要を提供しています。 hIPv4フレームワークの実装は、インターネットや企業のプライベートネットワークの主要なサービスウィンドウの休憩を必要としません。基本的には、hIPv4フレームワークは、現在のIPv4フレームワークの進化です。
The transition to hIPv4 might be attractive for enterprises since the hIPv4 framework does not create a catch-22 situation, e.g., when should an application used only inside the private network be ported from IPv4 to IPv6? Also, what is the business justification for porting the application to IPv6? Another matter is that when an
hIPv4フレームワークは、IPv4からIPv6への移植され、例えば、アプリケーションがプライベートネットワーク内でのみ使用しなければならないキャッチ22状況を、作成しないためhIPv4への移行は企業にとって魅力的であるかもしれませんか？また、IPv6へのアプリケーションを移植のためのビジネス上の正当な理由は何ですか？もう一つの問題は、ときということです
IPv4/v6 dual-stack solution is used it could impose operational expenditures, especially with rule sets at firewalls -- both in front of servers and at clients.
サーバーの前にとクライアントの両方で - IPv4の/ v6のデュアルスタック・ソリューションは、それが特にファイアウォールのルールセットで、運用コストを課す可能性が使用されています。
If an enterprise chooses to deploy hIPv4, however, the legacy applications do not need to be ported because hIPv4 is backwards compatible with the classical IPv4 framework. This means lower costs for the enterprise, and an additional bonus is the new stack's capabilities to better serve mobility use cases.
企業がhIPv4を展開することを選択した場合hIPv4は、古典的なIPv4のフレームワークとの後方互換性があるため、しかし、レガシーアプリケーションを移植する必要はありません。これは、企業のための低コストを意味し、追加のボーナスは新しいスタックの機能は、より良いモビリティユースケースを提供することです。
But the enterprise must take the decision soon and act promptly, because the IPv4 address depletion is a reality in the very near future. If the decision is delayed, IPv6 will arrive, and then, sooner or later, the legacy applications will need to be ported.
しかし、企業はすぐに決断を下すと、IPv4アドレスの枯渇は非常に近い将来に現実であるので、速やかに行動しなければなりません。決定が遅れている場合は、IPv6が到着し、その後、遅かれ早かれ、レガシーアプリケーションを移植する必要があります。
However, though this document has focused only on IPv4, a similar scheme can be deployed for IPv6 in the future, that is, creating a 64x64 bit locator space. But some benefits would have been lost at the time this document was written, such as:
しかし、この文書は、IPv4のみに焦点を当てているが、同様のスキームは、将来的にIPv6のために展開することができ、それは、64×64ビットロケータスペースを作成し、です。しかし、いくつかの利点は、この文書が書かれた時点で、このようなとして失われていたであろう。
o Backwards compatibility with the current Internet and therefore no smooth migration plan is gained.
O後方現在のインターネットとの互換性あり、したがってスムーズな移行計画が得られません。
o The locator header, including ALOC and ELOC prefixes, would have been larger, 160 bits versus 96 bits. And the identifier (EUI-64) would always have been present, which can be considered as pros or cons, depending upon one's view of the privacy issue, as discussed in [RFC4941] and in [Mobility_& _Privacy].
ALOCとELOCプレフィックスを含むロケータヘッダ、O、96ビット対160ビットを大きくされているだろう。 [RFC4941]にし、[Mobility_＆_Privacy]で説明したように識別子（EUI-64）は、常に、プライバシーの問題の一つのビューに応じて、長所や短所として考えることができる、存在していたでしょう。
If an enterprise prefers hIPv4 (e.g., due to gaining additional IPv4 addresses and smooth migration capabilities), there is an unintentional side effect (from the enterprise's point of view) on the routing architecture of the Internet; multi-homing becomes multi-pathing, and an opportunity opens up for the service providers to create an Internet routing architecture that holds less prefixes and generates less BGP updates in DFZ than the current Internet.
企業がhIPv4を好む場合（例えば、による追加IPv4アドレスと滑らかな移行機能を得るために）、インターネットのルーティングアーキテクチャ上の（ビューの企業の観点から）意図しない副作用があります。マルチホーミングは、マルチパスになり、機会が少ないプレフィックスを保持し、現在のインターネットよりもDFZで少ないBGPアップデートを生成し、インターネットルーティングアーキテクチャを作成するために、サービスプロバイダのために開きます。
The hIPv4 framework is providing a new hierarchy in the routing subsystem and is complementary work to multipath-enabled transport protocols (such as MPTCP and SCTP) and service-centric networking architectures (such as SCAFFOLD). End users and enterprises are not interested in routing issues in the Internet; instead, a holistic view should be applied on the three disciplines with a focus on new service opportunities and communicated to the end users and enterprises. Then perhaps the transition request to a new routing architecture will be accepted and carried out. However, more work is needed to accomplish a holistic framework of the three disciplines.
hIPv4フレームワークは、ルーティングサブシステムに新たな階層を提供し、そして（例えば足場として）サービス中心のネットワークアーキテクチャ（例えばMPTCP及びSCTPなど）マルチパス対応のトランスポートプロトコルに相補的な作業です。エンドユーザーや企業がインターネットでルーティングの問題に興味を持っていません。代わりに、全体像は、新しいサービスの機会に焦点を当てた3つの規律に適用され、エンドユーザーや企業に通知しなければなりません。おそらく新しいルーティングアーキテクチャへの遷移要求が受け入れられ、実施されます。しかし、より多くの作業が3つの分野の全体的な枠組みを達成するために必要とされます。
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992.
[RFC1385]王、Z.、 "EIP：拡張インターネット・プロトコル"、RFC 1385、1992年11月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、エド。、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[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月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[RFC4884] Bonica、R.、ガン、D.、タッパン、D.、およびC. Pignataro、RFC 4884、2007年4月 "拡張ICMPは、マルチパートメッセージをサポートするために"。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]パーキンス、C.、エド。、 "IPv4のIPモビリティのサポート、改訂"、RFC 5944、2010年11月。
[CES] Jen, D., Meisel, M., Yan, H. Massey, D., Wang, L., Zhang, B., Zhang, L., "Towards A New Internet Routing Architecture: Arguments for Separating Edges from Transit Core", 2008, http://conferences.sigcomm.org/ hotnets/2008/papers/18.pdf.
【CES】ジェン、D.、マイゼル、M.、ヤン、H.マッシー、D.、王、L.、チャン、B.、チャン、L.、「新しいインターネットルーティングアーキテクチャに向けて：から分離エッジの引数トランジットコア」、2008年、http://conferences.sigcomm.org/ hotnets / 2008 /論文/ 18.pdf。
[Dagstuhl] Arkko, J., Braun, M.B., Brim, S., Eggert, L., Vogt, C., Zhang, L., "Perspectives Workshop: Naming and Addressing in a Future Internet", 2009, http://www.dagstuhl.de/ de/programm/kalender/semhp/?semnr=09102.
【Dagstuhl] Arkko、J.、ブラウン、MB、つば、S.、Eggertの、L.、フォークト、C.、チャン、L.、 "視点ワークショップ：次世代のインターネットで命名とアドレス指定" 2009は、http：/ /www.dagstuhl.de/ド/プログラムの開発/ Kalenderの/ semhp /？semnr = 09102。
[ID/loc_Split] Thaler, D., "Why do we really want an ID/locator split anyway?", 2008, http://conferences.sigcomm.org/sigcomm/2008/workshops/ mobiarch/slides/thaler.pdf.
[ID / loc_Split]ターラー、D.、 "なぜ、私たちは本当にID /ロケータは、とにかく分割したいのか？"、2008年、http://conferences.sigcomm.org/sigcomm/2008/workshops/ mobiarch /スライド/ thaler.pdf 。
[ILNP] Atkinson, R., "ILNP Concept of Operations", Work in Progress, February 2011.
[ILNP]アトキンソン、R.、 "オペレーションのILNPコンセプト"、進歩、2011年2月での作業。
[iVLB] Babaioff, M., Chuang, J., "On the Optimality and Interconnection of Valiant Load-Balancing Networks", 2007, http://people.ischool.berkeley.edu/~chuang/ pubs/VLB-infocom07.pdf.
【iVLB] Babaioff、M.、荘、 "最適オンとヴァリアント負荷分散ネットワークの相互接続" J.、2007、http://people.ischool.berkeley.edu/~chuang/パブ/ VLB-infocom07。 PDF。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol", Work in Progress, June 2011.
[LISP]ファリナッチ、D.、フラー、V.、マイヤー、D.、およびD.ルイス、 "ロケータ/ ID分離プロトコル"、進歩、2011年6月での作業。
[Mobility_&_Privacy] Brim, S., Linsner. M., McLaughlin, B., and K. Wierenga, "Mobility and Privacy", Work in Progress, March 2011.
[モビリティ_＆_プライバシー]つば、S.、Linsner。 M.、マクラフリン、B.、およびK. Wierenga、 "モビリティとプライバシー"、進歩、2011年3月に作業。
[NBS] Ubillos, J., Xu, M., Ming, Z., and C. Vogt, "Name-Based Sockets Architecture", Work in Progress, September 2010.
【NBS] Ubillos、J.、徐、M.、明、Z.、およびC.フォークト、 "名前ベースのソケット・アーキテクチャ"、進歩2010年9月に働いています。
[Nimrod] Chiappa, N., "A New IP Routing and Addressing Architecture", 1991, http://ana-3.lcs.mit.edu/ ~jnc/nimrod/overview.txt.
[ニムロッド] Chiappa、N.、 "新しいIPルーティングおよびアドレス指定アーキテクチャ"、1991年、http://ana-3.lcs.mit.edu/〜JNC /ニムロッド/ overview.txt。
[Pathlet_Routing] Godfrey, P.G., Shenker, S., Stoica, I., "Pathlet Routing", 2008, http://conferences.sigcomm.org/hotnets/2008/ papers/17.pdf.
【Pathlet_Routing]ゴッド、P。G.、Shenker、S.、ストイカ、I.、 "Pathletルーティング"、2008年http://conferences.sigcomm.org/hotnets/2008/紙/ 17.pdf。
[Porting_IPv4] DeLong, O., "Porting IPv4 applications to dual stack, with examples", 2010, http://www.apricot.net/apricot2010/program/tutorials/ porting-ipv4-apps.html.
【Porting_IPv4]デロング、O.、 "例とデュアルスタックへの移植IPv4アプリケーション、" 2010年、http://www.apricot.net/apricot2010/program/tutorials/は移植-IPv4にapps.html。
[RBridge] Perlman, R., "RBridges, Transparent Routing", 2004, http://www.ieee-infocom.org/2004/Papers/26_1.PDF.
[RBridge]パールマン、R.、 "RBridges、透明ルーティング"、2004年、http://www.ieee-infocom.org/2004/Papers/26_1.PDF。
[Revisiting_Route_Caching] Kim, C., Caesar, M., Gerber, A., Rexford, J., "Revisiting Route Caching: The World Should Be Flat", 2009, http://www.springerlink.com/content/80w13260665v2013/.
[Revisiting_Route_Caching]キム、C.、シーザー、M.、ガーバー、A.、Rexfordの、J.、 "ルートキャッシュを再考：世界は平らにしてください"、2009年、http://www.springerlink.com/content/80w13260665v2013 /。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]グスタフソン、A.、 "未知のDNSリソースレコード（RR）の取扱いタイプ"、RFC 3597、2003年9月。
[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]フェナー、B.、エド。、およびD.マイヤー、エド。、 "は、Multicast Source Discovery Protocol（MSDP）"、RFC 3618、2003年10月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten氏、T.、Draves、R.、およびS.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984]マイヤー、D.、エド。、チャン、L.、エド。、およびK.秋、エド。、 "ルーティングとアドレッシングのIABワークショップからの報告書"、RFC 4984、2007年9月。
[RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", RFC 5395, November 2008.
[RFC5395]イーストレーク第3、D.、 "ドメインネームシステム（DNS）IANAの考慮事項"、RFC 5395、2008年11月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]カッツ、D.およびD.区、 "双方向フォワーディング検出（BFD）"、RFC 5880、2010年6月。
[RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", RFC 6115, February 2011.
[RFC6115]李、T.、エド。、 "ルーティング・アーキテクチャのための勧告"、RFC 6115、2011年2月。
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011.
[RFC6182]フォード、A.、Raiciu、C.、ハンドレー、M.、バール、S.、およびJ.アイアンガー、 "マルチパスTCP開発のための建築ガイドライン"、RFC 6182、2011年3月。
[RFC6227] Li, T., Ed., "Design Goals for Scalable Internet Routing", RFC 6227, May 2011.
[RFC6227]李、T.、エド。、 "スケーラブルなインターネットルーティングの設計目標"、RFC 6227、2011年5月。
[RRG] RRG, "IRTF Routing Research Group Home Page", http://tools.ietf.org/group/irtf/trac/wiki/ RoutingResearchGroup.
[RRG] RRG、 "IRTFのルーティング研究グループのホームページ"、http://tools.ietf.org/group/irtf/trac/wiki/ RoutingResearchGroup。
[SCAFFOLD] Freedman, M.J., Arye, M., Gopalan, P., Steven Y. Ko, S.Y., Nordstrom, E., Rexford, J., Shue, D. "Service-Centric Networking with SCAFFOLD", September 2010 http://www.cs.princeton.edu/research/techreps/TR-885-10.
【足場】フリードマン、MJ、Arye、M.、ゴパラン、P.、スティーブンY.コ、SY、ノードストローム、E.、Rexfordの、J.、シュー、D. "足場とサービス中心ネットワーク" 2010年9月HTTP ：//www.cs.princeton.edu/research/techreps/TR-885-10。
[Split-DNS] BIND 9 Administrator Reference Manual, http://www.bind9.net/manual/bind/9.3.1/ Bv9ARM.ch04.html#AEN767.
[スプリットDNS] BIND 9管理者リファレンスマニュアル、http://www.bind9.net/manual/bind/9.3.1/ Bv9ARM.ch04.html＃AEN767。
[tcpcrypt] Bittau, A., Hamburg, M., Handley, M., Mazi`eres, D., Boneh, D., "The case for ubiquitous transport-level encryption", 2010, http://tcpcrypt.org/tcpcrypt.pdf.
【tcpcrypt] Bittau、A.、ハンブルク、M.、ハンドレー、M.、Mazi`eres、D.、Boneh、D.、 "ユビキタストランスポートレベルの暗号化のためのケース" 2010年、http://tcpcrypt.org /tcpcrypt.pdf。
[VLB] Zhang-Shen, R., McKeown, N., "Designing a Predictable Internet Backbone with Valiant Load-Balancing", 2004, http://conferences.sigcomm.org/hotnets/ 2004/HotNets-III%20Proceedings/zhang-shen.pdf.
【VLB]チャン・シェン、R.、McKeownの、N.、2004年 "ヴァリアントロードバランシングで予測可能なインターネットバックボーンの設計"、http://conferences.sigcomm.org/hotnets/ 2004 / HotNets-III％20Proceedings /張-shen.pdf。
The active participants at the Routing Research Group [RRG] mailing list are acknowledged. They have provided ideas, proposals, and discussions that have influenced the architecture of the hIPv4 framework. The following persons, in alphabetical order, have provided valuable review input: Aki Anttila, Mohamed Boucadair, Antti Jarvenpaa, Dae Young Kim, Mark Lewis, Wes Toman, and Robin Whittle.
ルーティング研究グループ[RRG]メーリングリストでのアクティブな参加者が認めています。彼らはアイデア、提案、およびhIPv4フレームワークのアーキテクチャに影響を与えた議論を提供してきました。安芸Anttila、モハメドBoucadair、アンティヤルヴェンパー、府ヤング・キム、マーク・ルイス、ウェス・トマン、そしてロビンWhittleさん：次の人は、アルファベット順に、貴重なレビュー入力を提供しています。
Also, during the IRSG and IESG review process, Rajeev Koodli, Wesley Eddy, Jari Arkko, and Adrian Farrel provided valuable review input.
また、IRSGとIESGのレビュープロセスの間に、ラジーブKoodli、ウェズリーエディ、ヤリArkko、およびエードリアンファレルは、貴重なレビュー入力を提供します。
Lastly, a special thanks to Alfred Schwab from the Poughkeepsie ITSO for his editorial assistance.
最後に、彼の編集支援のためポキプシーITSOからアルフレッド・シュワブへの特別な感謝。
Appendix A. Short-Term and Future IPv4 Address Allocation Policy
付録A.短期と今後のIPv4アドレス割り当て方針
In this section, we study how the hIPv4 framework could influence the IPv4 address allocation policies to ensure that the new framework will enable some reusage of IPv4 address blocks. It is the Regional Internet Registries (RIRs) that shall define the final policies.
このセクションでは、我々はhIPv4フレームワークは新しいフレームワークは、IPv4アドレスブロックの一部の再使用を可能にすることを保証するために、IPv4アドレスの割り当てポリシーに影響を与える可能性がどのように勉強しています。それは、最終的な方針を定めるものとする地域インターネットレジストリ（RIRが）です。
When the intermediate routing architecture (see Figure 1) is fully implemented, every ALOC realm could have a full IPv4 address space, except the GLB, from which to allocate ELOC blocks. There are some implications, however. In order for an enterprise to achieve site mobility, that is, to change service provider without changing its ELOC scheme, the enterprise should implement an autonomous system (AS) solution with an ALOC prefix at the attachment point to the service provider.
場合、中間ルーティング・アーキテクチャ（図1参照）が完全に実装され、すべてのALOCレルムはELOCブロックを割り当てるそこからGLB、を除いて、完全なIPv4アドレス空間を有することができます。いくつかの意味合いは、しかし、があります。つまり、そのELOC方式を変更することなく、サービスプロバイダを変更するには、サイトのモビリティを実現する企業向けのために、企業はサービスプロバイダーへの取り付け点でALOCプレフィックスと自律システム（AS）ソリューションを実装する必要があります。
Larger enterprises have the resources to implement AS border routing. Most large enterprises have already implemented multi-homing solutions. Small and midsize enterprises (SMEs) may not have the resources to implement AS border routing, or the implementation introduces unnecessary costs for the SME. Also, if every enterprise needs to have an allocated ALOC prefix, this will have an impact on the RIB at the DFZ -- the RIB will be populated with a huge number of non-aggregatable ALOC prefixes.
大企業は、国境のルーティングなどを実装するためのリソースを持っています。ほとんどの大企業はすでに、マルチホーミングソリューションを実装しています。中小企業（SME）は、国境ルーティングなどを実装するためのリソースを持っていない可能性があり、または実装はSMEのための不要なコストを導入しています。すべての企業が割り当てられALOCプレフィックスを有する必要がある場合も、これはDFZでRIBに影響を与える - RIBは、非集約ALOCプレフィクスの膨大な数が移入されます。
It is clear that a compromise is needed. An SME site usually deploys a single uplink to the Internet and should be able to reserve a PI ELOC block from the RIR without being forced to create an ALOC realm, that is, implement an RBR solution and AS border routing. Since the PI ELOC block is no longer globally unique, an SME can only reserve the PI ELOC block for the region where it is active or has its attachment point to the Internet. The attachment point rarely changes to another country; therefore, it is sufficient that the PI ELOC block is regionally unique.
妥協が必要であることは明らかです。 SMEサイトでは、通常、インターネットへの単一のアップリンクを配備し、ALOCレルムを作成することを余儀なくされることなく、RIRからPIのELOCブロックを確保することができるはずです、つまり、RBRのソリューションを実装し、国境ルーティングAS。 PIのELOCブロックはもはやグローバルに一意ではありませんので、SMEは、それがアクティブであるか、インターネットへの接続点を持っている地域のPI ELOCブロックを予約することができます。取付点はほとんど別の国に変化しません。したがって、PIのELOCブロックは地域固有のものであることは十分です。
When the enterprise replaces its Internet service provider, it does not have to change its ELOC scheme -- only the local ALOC prefix at the endpoints is changed. The internal traffic at an enterprise does not make use of the ALOC prefix. The internal routing uses only the ELOC prefixes, and thus the internal routing and addressing architectures are preserved.
エンドポイントでの唯一のローカルALOCプレフィックス変更された - 企業がそのインターネットサービスプロバイダを置き換えると、そのELOCスキームを変更する必要はありません。企業の内部トラフィックは、ALOCプレフィックスを使用しません。内部ルーティングのみELOCプレフィックスを使用し、従って、内部ルーティングおよびアドレス指定アーキテクチャが保存されます。
Mergers and acquisitions of enterprises can cause ELOC conflicts, because the PI ELOC block is hereafter only regionally unique. If an enterprise in region A acquires an enterprise in region B, there is a slight chance that both enterprises have overlapping ELOC prefixes.
PIのELOCブロックは以下のみ地域独特であるため、企業の合併や買収は、ELOC競合を引き起こす可能性があります。領域A内の企業は、領域Bの企業を取得した場合、両方の企業が重複ELOCプレフィックスを有することわずかな可能性があります。
If overlapping of ELOC prefixes occurs, the private unicast ALOC solution can be implemented to separate them -- if all affected endpoints support the hIPv4 framework.
影響を受けるすべてのエンドポイントがhIPv4フレームワークをサポートしている場合 - ELOCプレフィックスの重複が発生した場合は、民間のユニキャストALOCソリューションは、それらを分離するために実装することができます。
Finally, residential users will receive only PA locators. When a residential user changes a service provider, she/he has to replace the locators. Since a PA ELOC block is no longer globally unique, every Internet service provider can use the PA ELOC blocks at their ALOC realms; the PA locators become kind of private locators for the service providers.
最後に、住宅のユーザーのみがPAロケータを受け取ることになります。住宅のユーザーは、サービスプロバイダを変更した場合、彼女/彼はロケータを交換する必要があります。 PA ELOCブロックは、もはやグローバルに一意ではありませんので、すべてのインターネット・サービス・プロバイダは、彼らのALOCレルムでPA ELOCブロックを使用することができます。 PAロケータは、サービスプロバイダのためのプライベートロケータのようなものになります。
If the forwarding planes and all hosts that establish inter-ALOC realm sessions are upgraded to support the hIPv4 framework, that is, the long-term routing architecture (see Figure 2) is implemented, several interesting possibilities occur:
インターALOCレルムセッションを確立し、転送プレーンとすべてのホストがhIPv4フレームワークをサポートするようにアップグレードされている場合、つまり、長期のルーティングアーキテクチャが実装されている（図2参照）、いくつかの興味深い可能性が生じます。
o The regional allocation policy for PI ELOC spaces can be removed, and the enterprise can make use of the whole IPv4 address space that is globally unique today. The ELOC space is hereafter only significant at a local ALOC realm.
O PIのELOCスペースの地域の割り当てポリシーを除去することができ、企業は今日、グローバルに一意である全体のIPv4アドレス空間を利用することができます。 ELOCスペースは、以下のローカルALOC分野で唯一重要です。
o In case of mergers or acquisitions of enterprises, the private unicast ALOC solution can be used to separate overlapping ELOC spaces.
O企業の合併または買収の場合には、プライベートユニキャストALOC溶液ELOCスペースを重複分離するために使用することができます。
o The GLB space can be expanded to make use of all 32 bits (except for the blocks defined in RFC 1918) for anycast and unicast ALOC allocations; only ISPs are allowed to apply for GLB prefixes.
O GLB空間は、エニーキャストとユニキャストALOC割り当ての（RFC 1918で定義されたブロックを除く）のすべての32ビットを利用するように拡張することができます。唯一のISPは、GLBプレフィックスの申請が許可されています。
o The global anycast ALOC solution can be replaced with the global unicast ALOC solution since the ISP and enterprise no longer need to share ELOC routing information. Also, there is enough space in the GLB to reserve global unicast ALOC prefix(es) for every enterprise.
ISPおよび企業がもはやルーティング情報ELOCを共有する必要があるためoをグローバルエニーキャストALOC溶液がグローバルユニキャストALOC溶液と交換することができません。また、すべての企業のためのグローバルユニキャストALOC接頭語（es）を予約するGLBに十分なスペースがあります。
o Residential users will still use global anycast ALOC solutions, and if they change service providers, their locators need to be replaced.
O住居ユーザーはグローバルエニーキャストALOCソリューションを使用すると、彼らはサービスプロバイダを変更した場合、そのロケータを交換する必要があります。
The result is that a 32x32 bit locator space is achieved. When an enterprise replaces an ISP with another ISP, only the ALOC prefix(es) is replaced at endpoints and infrastructure nodes. Renumbering of ALOC prefixes can be automated by, for example, DHCP and extensions to IGP.
結果は、32×32ビットのロケータスペースが達成されることです。企業が別のISPとISPを置換するとき、唯一ALOCプレフィックス（ES）は、エンドポイントおよびインフラストラクチャノードに置き換えられます。 ALOCプレフィックスのリナンバリングは、例えば、DHCPおよびIGPの拡張機能によって自動化することができます。
Appendix B. Multi-Homing becomes Multi-Pathing
付録B.マルチホーミングは、マルチパスになり
When the transition to the intermediate routing architecture (see Figure 1) is fully completed, the RIB of an ISP that has created an ALOC realm will have the following entries:
中間ルーティングアーキテクチャへの移行が完全に完了した（図1を参照）場合、作成したISPのRIBはALOCレルムは次のエントリを有することになります。
o The PA ELOC blocks of directly attached customers (residential and enterprises)
直接接続された顧客（住宅および企業）のPA ELOCブロックO
o The PI ELOC blocks of directly attached customers (e.g., enterprises)
O直接接続され、顧客のPI ELOCブロック（例えば、企業）
o The globally unique ALOC prefixes, received from other service providers
グローバルに一意ALOCプレフィックスO、他のサービスプロバイダから受け取りました
The ISP will not carry any PA or PI ELOC blocks from other service providers in its routing table. In order to do routing and forwarding of packets between ISPs, only ALOC information of other ISPs is needed.
ISPは、そのルーティングテーブル内の他のサービスプロバイダから任意のPAまたはPI ELOCブロックを運ぶことはありません。 ISP間のパケットのルーティングおよび転送を行うために、他のISPの唯一ALOC情報が必要です。
Then, the question is how to keep the growth of ALOC reasonable? If the enterprise is using PI addresses, has an AS number, and is implementing BGP, why not apply for an ALOC prefix?
その後、質問は合理的なALOCの成長を維持する方法ですか？企業は、PIアドレスを使用している場合は、AS番号を持っており、BGPは、なぜALOC接頭辞には適用されませ実施していますか？
Classical multi-homing is causing the biggest impact on the growth of the size of the RIB in the DFZ -- so replacing a /20 IPv4 prefix with a /32 ALOC prefix will not reduce the size of the RIB in the DFZ.
そうDFZリブのサイズを縮小しないであろう/ 32 ALOC接頭辞/ 20のIPv4プレフィックスを置き換える - 古典的なマルチホーミングはDFZリブの大きさの成長に最も大きな影響を引き起こしています。
Most likely, the only way to prevent this from happening is to impose a yearly cost for the allocation of an ALOC prefix, except if you are a service provider that is providing access and/or transit traffic for your customers. And it is reasonable to impose a cost for allocating an ALOC prefix for the non-service providers, because when an enterprise uses an ALOC prefix, it is reserving a FIB entry throughout the DFZ; the ALOC FIB entry needs to have power, space, hardware, and cooling on all the routers in the DFZ.
ほとんどの場合、これを防ぐための唯一の方法は、あなたの顧客のためのアクセスおよび/または通過トラフィックを提供しているサービスプロバイダであれば除き、ALOCプレフィックスの割り当てのための年間コストを課すことです。企業がALOCの接頭辞を使用する場合、それはDFZを通じてFIBエントリを確保しているため、非サービスプロバイダ向けALOCプレフィックスを割り当てるためのコストを課すことは合理的です。 ALOC FIBエントリはDFZ内のすべてのルータに電源、スペース、ハードウェア、および冷却を持っている必要があります。
Implementing this kind of ALOC allocating policy will reduce the RIB size in the DFZ quite well, because multi-homing will no longer increase the RIB size of the DFZ. But this policy will have some impact on the resilience behavior because by compressing routing information we will lose visibility in the network. In today's multi-homing solutions the network always knows where the remote endpoint resides. In case of a link or network failure, a backup path is calculated and an alternative path is found, and all routers in the DFZ are aware of the change in the topology. This functionality has off-loaded the workload of the endpoints; they only need to find the closest ingress router and the network will deliver the packets to the egress router, regardless (almost) of what failures happen in the network. And with the growth of multi-homed prefixes, the routers in the DFZ have been forced to carry greater workloads, perhaps close to their limits -- the workload between the network and endpoints is not in balance. The conclusion is that the endpoints should take more responsibility for their sessions by offloading the workload in the network. How? Let us walk through an example.
マルチホーミングは、もはやDFZのRIBのサイズが大きくなりますので、非常によくDFZでRIBサイズを小さくしませんALOC割り当てポリシーのこの種を実装します。ルーティング情報を圧縮することにより、我々は、ネットワークの可視性を失うことになるので、しかし、この政策は、反発行動に何らかの影響を持つことになります。リモートエンドポイントがどこにあるか、今日のマルチホーミングソリューションでは、ネットワークは常に知っています。リンクまたはネットワーク障害が発生した場合に、バックアップパスを算出し、代替経路が発見され、そしてDFZのすべてのルータは、トポロジの変化を認識しています。この機能は、エンドポイントのワークロード、オフロードされています。彼らは唯一の最も近い入口ルータを見つける必要があるとのネットワークは（ほとんど）何の障害はネットワークで起こるかかわらず、出口ルータにパケットを配信します。そして、マルチホームプレフィックスの成長とともに、DFZのルータは、その限界におそらく近い、より大きなワークロードを実行することを余儀なくされている - ネットワークとエンドポイント間のワークロードバランスではありません。結論は、エンドポイントがネットワークに負荷をオフロードすることによって、そのセッションのためのより多くの責任を取るべきであるということです。どうやって？私たちは例を見てみましょう。
A remote enterprise has been given an ELOC block 192.168.1.0/24, either via static routing or BGP announced to the upstream service providers. The upstream service providers provide the ALOC information for the enterprise, 10.1.1.1 and 10.2.2.2. A remote endpoint has been installed and given ELOC 192.168.1.1 -- the ELOC is a locator defining where the remote endpoint is attached to the remote network. The remote endpoint has been assigned ALOCs 10.1.1.1 and 10.2.2.2 -- an ALOC is a locator defining the attachment point of the remote network to the Internet.
遠隔企業はELOCブロック192.168.1.0/24を与え、静的ルーティング、またはBGPを介して上流のサービスプロバイダに発表されています。上流のサービスプロバイダは、企業、10.1.1.1および10.2.2.2のためのALOC情報を提供します。リモートエンドポイントがインストールされELOC 192.168.1.1与えられている - ELOCは、リモートエンドポイントがリモートネットワークに接続されているロケータ定義です。リモートエンドポイントはALOCs 10.1.1.1及び10.2.2.2が割り当てられている - ALOCは、インターネットへのリモートネットワークの接続ポイントを定義するロケータです。
The initiator (local endpoint) that has ELOC 172.16.1.1 and ALOC prefixes 10.3.3.3 and 10.4.4.4 has established a session by using ALOC 10.3.3.3 to the responder (remote endpoint) at ELOC 192.168.1.1 and ALOC 10.1.1.1. That is, both networks 192.168.10/24 and 172.16.1.0/24 are multi-homed. ALOCs are not available in the current IP stack's API, but both ELOCs are seen as the local and remote IP addresses in the API, so the application will communicate between IP addresses 172.16.1.1 and 192.168.1.1. If ALOC prefixes are included, the session is established between 10.3.3.3:172.16.1.1 and 10.1.1.1:192.168.1.1.
ELOC 172.16.1.1とALOCプレフィクス10.3.3.3及び10.4.4.4を持つ開始剤（ローカルエンドポイント）はELOC 192.168.1.1とALOC 10.1.1.1に応答（リモートエンドポイント）にALOC 10.3.3.3を使用してセッションを確立しました。つまり、両方のネットワーク192.168.10 / 24および172.16.1.0/24がマルチホームである、です。 ALOCsは、現在のIPスタックのAPIで利用できませんが、両方ELOCsはAPIでローカルとリモートのIPアドレスと見られているので、IPの間で通信するアプリケーションは、172.16.1.1および192.168.1.1に対処します。 ALOC接頭辞が含まれている場合、セッションは10.3.3.3:172.16.1.1と10.1.1.1:192.168.1.1の間で確立されています。
Next, a network failure occurs and the link between the responder border router (BR-R1) and service provider that owns ALOC 10.1.1.1 goes down. The border router of the initiator (BR-I3) will not be aware of the situation, because only ALOC information is exchanged between service providers and ELOC information is compressed to stay within ALOC realms. But BR-R1 will notice the link failure; BR-R1 could rewrite the ALOC field in the locator header for this session from 10.1.1.1 to 10.2.2.2 and send the packets to the second service provider via BR-R2. The session between the initiator 10.3.3.3:172.16.1.1 and the responder 10.2.2.2:192.168.1.1 remains intact because the legacy 5-tuple at the IP stack API does not change. Only the ALOC prefix of the responder has changed and this information is not shown to the application. An assumption here is that the hIPv4 stack does accept changes of ALOC prefixes on the fly (more about this later).
次に、ネットワーク障害が発生し、応答者の境界ルータ（BR-R1）及びALOC 10.1.1.1を所有しているサービスプロバイダとの間のリンクがダウンします。唯一ALOC情報は、サービスプロバイダとELOC情報がALOCレルム内に収まるように圧縮されている間で交換されるため、開始剤（BR-I3）の境界ルータは、状況を認識しません。しかし、BR-R1は、リンク障害に気づくでしょう。 BR-R1は、10.1.1.1から10.2.2.2に、このセッションのためのロケータヘッダ内ALOCフィールドを書き換えるとBR-R2を介して第2のサービスプロバイダにパケットを送ることができます。 IPスタックAPIのレガシー5タプルが変更されないため、イニシエータ10.3.3.3:172.16.1.1と応答10.2.2.2:192.168.1.1間のセッションはそのまま残ります。唯一の応答者のALOCプレフィックスが変更されており、この情報は、アプリケーションに表示されていません。ここでの仮定はhIPv4スタックが（この後の詳細については）その場でALOCプレフィックスの変更を受け入れないということです。
If the network link between the BR-I3 and ISP providing ALOC 10.3.3.3 fails, BR-I3 could rewrite the ALOC prefix in the locator header and route the packets via BR-I4 and the session would stay up. If there is a failure somewhere in the network, the border routers might receive an ICMP destination unreachable message (if not blocked by some security functionality) and thus try to switch the session over to the other ISP by replacing the ALOC prefixes in the hIPv4 header. Or the endpoints might try themselves to switch to the other ALOCs after a certain time-out in the session. In all session transition cases the legacy 5-tuple remains intact.
ALOC 10.3.3.3を提供するBR-I3とISP間のネットワークリンクに障害が発生した場合、BR-I3は、ロケータヘッダとルートにALOCプレフィックスを書き換えることができBR-I4とセッションを経由してパケットが起きてしまいます。どこかに、ネットワーク内の障害が発生した場合、境界ルータは、（いくつかのセキュリティ機能によってブロックされていない場合）、ICMP宛先到達不能メッセージを受信し、従ってhIPv4ヘッダにALOCプレフィックスを置き換えることにより、他のISPへのセッションを切り替えることを試みるかもしれません。またはエンドポイントは、セッション中に一定のタイムアウト後に他のALOCsに切り替えるために自分自身を試してみてください。すべてのセッションの遷移例ではレガシー5タプルはそのまま残ります。
If border routers or one of the endpoints changes the ALOC prefix without a negotiation with the remote endpoint, security issues arise. Can the endpoints trust the remote endpoint when ALOC prefixes are changed on the fly -- is it still the same remote endpoint or has the session been hijacked by a bogus endpoint? The obvious answer is that an identification mechanism is needed to ensure that after a change in the path or a change of the attachment point of the endpoint, the endpoints are still the same. An identifier needs to be exchanged during the transition of the session.
境界ルータまたはエンドポイントの1つは、リモートエンドポイントとの交渉なしにALOC接頭辞を変更した場合、セキュリティ上の問題が生じます。 ALOC接頭辞をその場で変更された場合、エンドポイントは、リモートエンドポイントを信頼することができます - それはまだ同じリモートエンドポイントであるか、セッションが偽のエンドポイントによってハイジャックされましたか？明白な答えは、識別機構は経路における変化またはエンドポイントのアタッチメントポイントの変更後に、エンドポイントは依然として同じであることを確認するために必要とされることです。識別子は、セッションの移行中に交換する必要があります。
Identifier/locator split schemes have been discussed on the [RRG] mailing list, for example, multipath-enabled transport protocols and identifier database schemes. Both types of identifiers can be used to protect the session from being hijacked. A session identifier will provide a low-level security mechanism, offering some protection against hijacking of the session and also provide mobility. SCTP uses the verification tag to identify the association; MPTCP incorporates a token functionality for the same purpose -- both can be considered to fulfill the characteristics of a session identifier. [tcpcrypt] can be used to further mitigate session hijacking. If the application requires full protection against man-in-the-middle attacks, TLS should be applied for the session. Both transport protocols are also multipath-capable. Implementing multipath-capable transport protocols in a multi-homed environment will provide new capabilities, such as:
識別子/ロケータ分割スキームは[RRG]メーリングリスト、例えば、マルチパス対応のトランスポート・プロトコル識別子データベース・スキームに議論されています。識別子の両方のタイプがハイジャックされてからセッションを保護するために使用することができます。セッション識別子は、セッションのハイジャックに対するある程度の保護を提供し、低レベルのセキュリティメカニズムを提供し、また、モビリティを提供します。 SCTPアソシエーションを識別するために、検証タグを使用します。 MPTCPは、同じ目的のためにトークンの機能が組み込まれて - の両方がセッション識別子の特性を満たすために考えることができます。 【tcpcrypt】さらに、セッションハイジャックを緩和するために使用することができます。アプリケーションは、man-in-the-middle攻撃に対する完全な保護を必要とする場合は、TLSセッションのために適用されるべきです。どちらのトランスポートプロトコルはまた、マルチパス対応しています。マルチホーム環境でマルチパス対応のトランスポートプロトコルを実装するような新機能を提供します：
o Concurrent and separate exit/entry paths via different attachment points at multi-homed sites.
マルチホーム部位で異なるアタッチメントポイントを介しO同時および別々の出口/入口経路。
o True dynamic load-balancing, in which the endpoints do not participate in any routing protocols or do not update rendezvous solutions due to network link or node failures.
O真の動的な負荷分散は、その内のエンドポイントは、任意のルーティングプロトコルに参加しないか、ネットワークのリンクまたはノードの障害へのランデブーソリューションを更新しません。
o Only a single Network Interface Card (NIC) on the endpoints is required.
Oのみのエンドポイント上の単一のネットワーク・インターフェース・カード（NIC）が必要です。
o In case of a border router or ISP failure, the multipath transport protocol will provide resilience.
OボーダールータまたはISPの障害の場合には、マルチトランスポート・プロトコルは、弾力性を提供するであろう。
By adding more intelligence at the endpoints, such as multipath-enabled transport protocols, the workload of the network is offloaded and can take less responsibility for providing visibility of destination prefixes on the Internet; for example, prefix compression in the DFZ can be applied and only the attachment points of a local network need to be announced in the DFZ. And the IP address space no longer needs to be globally unique; it is sufficient that only a part is globally unique, with the rest being only regionally unique (in the long-term routing architecture, locally unique) as discussed in Appendix A.
こうしたマルチパス対応のトランスポートプロトコルとして、エンドポイント、でより多くのインテリジェンスを追加することにより、ネットワークの負荷をオフロードして、インターネット上の宛先プレフィックスの可視性を提供するためのより少ない責任を取ることができます。例えば、DFZでプレフィックス圧縮を適用することができ、ローカルネットワークの唯一の接続点はDFZに発表する必要があります。そして、IPアドレス空間は、もはやグローバルに一意である必要がありません。残りは付録Aで説明したように（長期ルーティング・アーキテクチャにおいて、ローカルで一意）のみ地域ユニークであると、一部のみがグローバルに一意であることで十分です
The outcome is that the current multi-homing solution can migrate towards a multi-pathing environment that will have the following characteristics:
結果は現在のマルチホーミングソリューションは、次のような特徴を持っていますマルチパス環境に向かって移動できることです。
o An AS number is not mandatory for enterprises.
O AS番号は、企業にとって必須ではありません。
o BGP is not mandatory at the enterprise's border routers; static routing with Bidirectional Forwarding Detection (BFD) [RFC5880] is an option.
O BGPは、企業の境界ルータでは必須ではありません。双方向フォワーディング検出（BFD）[RFC5880]の静的ルーティングはオプションです。
o Allocation of global ALOC prefixes for the enterprise should not be allowed; instead, upstream ISPs provide the global ALOC prefixes for the enterprise.
O企業のグローバルALOCプレフィックスの割り当ては許されるべきではありません。代わりに、上流のISPは、企業のグローバルALOCプレフィックスを提供しています。
o MPTCP provides dynamic load-balancing without using routing protocols; several paths can be used simultaneously and thus resilience is achieved.
O MPTCPは、ルーティングプロトコルを使用することなく、動的負荷分散を提供します。いくつかの経路を同時に使用することができ、したがって、反発性が達成されます。
o Provides low growth of RIB entries at the DFZ.
oはDFZでRIBエントリーの低成長を提供します。
o When static routing is used between the enterprise and the ISP:
静的ルーティングは、企業とISPとの間で使用される場合○：
- The RIB size at the enterprise's border routers does not depend upon the size of the RIB in the DFZ or in adjacent ISPs.
- 企業の境界ルータのRIBサイズはDFZ内または隣接のISPでRIBの大きさに依存しません。
- The enterprise's border router cannot cause BGP churn in the DFZ or in the adjacent ISPs' RIB.
- 企業の境界ルータはDFZ中または隣接するISPのRIBにBGPチャーンを引き起こすことはできません。
o When dynamic routing is used between the enterprise and the ISP:
動的ルーティングは、企業とISPとの間で使用される場合○：
- The RIB size at the enterprise's border routers depends upon the size of the RIB in the DFZ and adjacent ISPs.
- 企業の境界ルータのRIBサイズはDFZと隣接のISPでRIBの大きさに依存します。
- The enterprise's border router can cause BGP churn for the adjacent ISPs, but not in the DFZ.
- 企業の境界ルータは、隣接するISPのためではなく、DFZにBGPチャーンを引き起こす可能性があります。
o The cost of the border router should be less than in today's multi-homing solution.
O境界ルータのコストは、今日のマルチホーミングソリューションに比べて小さくする必要があります。
Appendix C. Incentives and Transition Arguments
付録C.インセンティブとトランジションの引数
The media has announced the meltdown of the Internet and the depletion of IPv4 addresses several times, but the potential chaos has been postponed and the general public has lost interest in these announcements. Perhaps it could be worthwhile to find other valuable arguments that the general public could be interested in, such as:
メディアは、インターネットのメルトダウンを発表したとIPv4の枯渇は、数回に対処しますが、潜在的な混乱が延期されたと一般市民は、これらの発表に興味を失ってしまいました。おそらく次のような一般市民がに興味がある可能性があり、他の貴重な議論を、見つけるために価値があるかもしれません。
o Not all endpoints need to be upgraded, only those that are directly attached to the Internet, such as portable laptops, smart mobile phones, proxies, and DMZ/frontend endpoints. But the most critical endpoints, the backend endpoints where enterprises keep their most critical business applications, do not need to be upgraded. These endpoints should not be reached at all from the Internet, only from the private network. And this functionality can be achieved with the hIPv4 framework, since it is backwards compatible with the current IPv4 stack. Therefore, investments in legacy applications used inside an ALOC realm are preserved.
Oすべてのエンドポイントは、アップグレードするためにこのようなポータブルラップトップ、スマートフォン、携帯電話、プロキシ、DMZ /フロントエンドのエンドポイントとして、インターネットに直接接続されているもののみを、必要としません。しかし、最も重要なエンドポイントは、企業が彼らの最も重要なビジネス・アプリケーションを維持するバックエンドのエンドポイントは、アップグレードする必要はありません。これらのエンドポイントは、プライベートネットワークから、インターネットからのすべてで到達すべきではありません。それは、現在のIPv4スタックと下位互換性があるので、この機能は、hIPv4フレームワークを用いて達成することができます。したがって、ALOC領域の内部で使用されるレガシーアプリケーションへの投資は保持されます。
o Mobility - it is estimated that the demand for applications that perform well over the wireless access network will increase. Introduction of MPTCP and identifier/locator split schemes opens up new possibilities to create new solutions and applications that are optimized for mobility. The hIPv4 framework requires an upgrade of the endpoint's stack; if possible, the hIPv4 stack should also contain MPTCP and identifier/locator split scheme features. Applications designed for mobility could bring competitive benefits.
モビリティ○ - 無線アクセスネットワーク上でも実行するアプリケーションの需要が増加すると推定されています。 MPTCP識別子/ロケータ分離スキームの導入は、新しいソリューションとモビリティのために最適化されたアプリケーションを作成するための新しい可能性を開きます。 hIPv4フレームワークは、エンドポイントのスタックのアップグレードが必要です。可能であれば、hIPv4スタックがMPTCPと識別子/ロケータ分離スキームの機能をも含まれている必要があります。モビリティのために設計されたアプリケーションは、競争力の恩恵をもたらす可能性があります。
o The intermediate routers in the network do not need to be upgraded immediately; the current forwarding plane can still be used. The benefit is that the current network equipment can be preserved at the service providers, enterprises, and residences (except middleboxes). This means that the carbon footprint is a lot lower compared to other solutions. Many enterprises do have green programs and many residential users are concerned with the global warming issue.
ネットワークにおける中間ルータoをすぐにアップグレードする必要はありません。現在のフォワーディングプレーンは、まだ使用することができます。利点は、現在のネットワーク機器は、サービスプロバイダ、企業、及び（中間装置を除く）住宅で保存することができることです。これは、カーボンフットプリントは、他のソリューションに比べてはるかに低くなることを意味します。多くの企業は、緑のプログラムを持っているし、多くの住宅のユーザーは、地球温暖化問題に関係しています。
o The migration from IPv4 to IPv6 (currently defined architecture) will increase the RIB and FIB throughout DFZ. Whether it will require a new upgrade of the forwarding plane as discussed in [RFC4984] is unclear. Most likely an upgrade is needed. The
（現在定義されているアーキテクチャ）IPv4からIPv6への移行O DFZ全体RIBとFIBを増加させるであろう。 [RFC4984]で説明したように、それはフォワーディングプレーンの新しいアップグレードが必要になるかどうかは不明です。ほとんどのアップグレードが必要とされています。ザ・
outcome of deploying IPv4 and IPv6 concurrently is that the routers need to have larger memories for the RIB and FIB -- every globally unique prefix is installed in the routers that are participating in the DFZ. Since the enterprise reserves one or several RIB/FIB entries on every router in the DFZ, it is increasing the power consumption of the Internet, thus increasing the carbon footprint. And many enterprises are committed to green programs. If hIPv4 is deployed, the power consumption of the Internet will not grow as much as in an IPv4 to IPv6 transition scenario.
すべてのグローバルにユニークな接頭辞がDFZに参加しているルータに搭載されている - 同時にIPv4およびIPv6の展開の結果は、ルータがRIBおよびFIBのためのより大きなメモリを持っている必要があるということです。企業の埋蔵1またはDFZ内のすべてのルータ上のいくつかのRIB / FIBエントリので、それはこのように、二酸化炭素排出量を増やし、インターネットの消費電力を増加しています。そして、多くの企業がグリーンプログラムにコミットしています。 hIPv4が展開されている場合は、インターネットの消費電力は、IPv4からIPv6への移行シナリオで同じくらいに成長しません。
o Another issue: if the migration from IPv4 to IPv6 (currently defined architecture) occurs, the routers in the DFZ most likely need to be upgraded to more expensive routers, as discussed in [RFC4984]. In the wealthy part of the world, where a large penetration of Internet users is already present, the service providers can pass the costs of the upgrade along to their subscribers more easily. With a "wealthy/high penetration" ratio the cost will not grow so much that the subscribers would abandon the Internet. But in the less wealthy part of the world, where there is usually a lower penetration of subscribers, the cost of the upgrade cannot be accepted so easily -- a "less wealthy/low penetration" ratio could impose a dramatic increase of the cost that needs to be passed along to the subscribers. And thus fewer subscribers could afford to get connected to the Internet. For the global enterprises and the enterprises in the less wealthy part of the world, this scenario could mean less potential customers and there could be situations when the nomads of the enterprises can't get connected to the Internet. This is also not fair; every human being should have a fair chance to be able to enjoy the Internet experience -- and the wealthy part of the world should take this right into consideration. Many enterprises are committed to Corporate Social Responsibility programs.
もう一つの問題○：IPv4からIPv6への移行（現在定義されているアーキテクチャ）が発生した場合、DFZのルータは、最も可能性が高い[RFC4984]で説明したように、より高価なルータにアップグレードする必要があります。インターネットユーザーの大規模な普及が既に存在している世界の裕福な部分では、サービスプロバイダは、より簡単に自分の加入者に沿ってアップグレードのコストを渡すことができます。 「裕福/高浸透」比のコストは、加入者がインターネットを放棄することをあまり成長しないだろう。しかし、通常、加入者の低浸透があり、世界のあまり裕福な一部で、アップグレードのコストはそう簡単に受け入れることができない - 「レス裕福/低浸透」の比率は、コストの劇的な増加を課すことができること加入者に渡される必要があります。したがって、少数の加入者は、インターネットに接続して取得する余裕がありました。グローバル企業と世界のあまり裕福な一部の企業では、このシナリオは、以下の潜在的な顧客を意味するかもしれませんし、企業の遊牧民は、インターネットに接続して取得することができないときの状況があるかもしれません。また、これは公平ではありません。すべての人間は、インターネット体験を楽しむことができるようにする公平な機会を持つべきである - そして世界の裕福な部分を考慮にこの権利を取る必要があります。多くの企業は、企業の社会的責任プログラムにコミットしています。
Not only technical and economical arguments can be found. Other arguments that the general public is interested in and concerned about can be found, for example, that the Internet becomes greener and more affordable for everyone, in contrast with the current forecast of the evolution of the Internet.
唯一の技術的・経済的な引数を見つけることができません。一般の人が興味を持ってと懸念していることを他の引数は、インターネットは、インターネットの進化の現在の予測とは対照的に、環境に優しいと皆のためのより手頃な価格になっていること、例えば、見つけることができます。
Appendix D. Integration with CES Architectures
CESアーキテクチャと付録D.統合
Because the hIPv4 framework requires changes to the endpoint's stack, it will take some time before the migration of the current IPv4 architecture to the intermediate hIPv4 routing architecture is fully completed. If a hIPv4 proxy solution could be used in front of classical IPv4 endpoints, the threshold for early adopters to start to migrate towards the hIPv4 framework would be less questionable and the migration phase would also most likely be much shorter.
hIPv4フレームワークは、エンドポイントのスタックへの変更を必要とするため、中間hIPv4のルーティングアーキテクチャに現在のIPv4アーキテクチャの移行が完全に完了する前に、それはいくつかの時間がかかります。 hIPv4プロキシソリューションは、古典的なIPv4のエンドポイントの前に使用することができれば、hIPv4の枠組みに向けて移動を開始する早期導入のためのしきい値は、あまり疑問になり、移行相はまた、最も可能性の高いはるかに短くなります。
Therefore, it should be investigated whether the hIPv4 framework can be integrated with Core-Edge Separation [CES] architectures. In CES architectures the endpoints do not need to be modified. The design goal of a CES solution is to minimize the PI-address entries in the DFZ and to preserve the current stack at the endpoints. But a CES solution requires a new mapping system and also introduces a caching mechanism in the map-and-encapsulate network nodes. Much debate about scalability of a mapping system and the caching mechanism has been going on at the [RRG] list. At the present time it is unclear how well both solutions will scale; research work on both topics is still in progress.
したがって、hIPv4フレームワークはコア・エッジ分離[CES]アーキテクチャに統合することができるかどうかを検討すべきです。 CESのアーキテクチャでは、エンドポイントを変更する必要はありません。 CESソリューションの設計目標は、DFZにおけるPI-アドレスエントリを最小限にし、エンドポイントで現在のスタックを維持することです。しかし、CESのソリューションは、新しいマッピングシステムを必要とし、また、地図と-カプセル化するネットワーク・ノードでキャッシュメカニズムが導入されました。マッピングシステムの拡張性とキャッシュメカニズムについて多くの議論が[RRG]リストで続いています。現時点では、両方のソリューションを拡張する方法も不明です。両方のトピックに関する研究作業はまだ進行中です。
Since the CES architectures divide the address spaces into two new categories, one that is installed in the RIB of the DFZ and one that is installed in the local networks, there are to some degree similarities between CES architectures and the hIPv4 framework. Actually, the invention of the IP and locator header swap functionality was inspired by [LISP].
CESアーキテクチャは、2つの新しいカテゴリ、ローカルネットワークにインストールされDFZ一つのRIBにインストールされたものにアドレス空間を分割するので、CESアーキテクチャとhIPv4フレームワークとの間のある程度の類似性が存在します。実際には、IP及びロケータヘッダスワップ機能の発明は、[LISP]に触発されました。
In order to describe how these two architectures might be integrated, some terminology definitions are needed:
これらの二つのアーキテクチャが統合されるかもしれない方法を説明するために、いくつかの用語の定義が必要です。
CES-node:
CES-ノード：
A network node installed in front of a local network that must have the following characteristics:
以下の特性を有していなければならないローカルネットワークの前にインストールされたネットワーク・ノード。
o Map-and-encapsulate ingress functionality
Oマップ-とカプセル化の進入機能
o Map-and-encapsulate egress functionality
Oマップ-とカプセル化出力機能を
o Incorporate the hIPv4 stack
O hIPv4スタックを組み込みます
o Routing functionality, [RFC1812]
Oルーティング機能、[RFC1812]
o Being able to apply policy-based routing on the ALOC field in the locator header
ロケータヘッダーにALOCフィールドにポリシーベースのルーティングを適用することができることO
The CES-node does not include the MPTCP extension because it would most likely put too much of a burden on the CES-node to signal and maintain MPTCP subflows for the cached hIPv4 entries.
それが最も可能性の高いキャッシュされたhIPv4エントリのMPTCPのサブフローを通知し、維持するために、CES-ノード上の負担のあまりを置くので、CES-ノードはMPTCP拡張子が含まれていません。
Consumer site:
消費者のサイト：
A site that is not publishing any services towards the Internet, that is, there are no entries in DNS for this site. It is used by local endpoints to establish outbound connectivity -- endpoints are initiating sessions from the site towards content sites. Usually such sites are found at small enterprises and residences. PA-addresses are usually assigned to them.
インターネットに向けてあらゆるサービスを公開されていないサイトは、つまり、このサイトのDNSエントリがありません。アウトバウンド接続を確立するために、ローカルエンドポイントで使用されている - エンドポイントは、コンテンツサイトに対するサイトからセッションを開始しています。通常、このようなサイトは、中小企業や住宅で発見されています。 PA-アドレスは、通常、それらに割り当てられています。
Content site:
コンテンツサイト：
A site that is publishing services towards the Internet, and which usually does have DNS entries. Such a site is used by local endpoints to establish both inbound and outbound connectivity. Large enterprises use PI-addresses, while midsize/small enterprises use either PI- or PA-address space.
インターネットに向けてサービスを公開しているサイト、およびその通常のDNSエントリを持っています。このようなサイトは、インバウンドとアウトバウンドの両方の接続を確立するために、ローカルエンドポイントで使用されています。中堅/中小企業は、PI-またはPA-アドレス空間のいずれかを使用しながら、大企業は、PI-アドレスを使用します。
The CES architectures aim to reduce the PI-address entries in the DFZ. Therefore, map-and-encapsulate egress functionality will be installed in front of the content sites. It is likely that the node containing map-and-encapsulate egress functionality will also contain map-and-encapsulate ingress functionality; it is also a router, so the node just needs to support the hIPv4 stack and be able to apply policy-based routing using the ALOC field of the locator header to become a CES-node.
CESのアーキテクチャはDFZにPI-アドレスエントリを削減することを目指しています。そのため、地図とカプセル化の出力機能は、コンテンツサイトの前に設置されます。地図とカプセル化の出力機能を含むノードは、マップ-とカプセル化の進入の機能が含まれている可能性があります。またルータであるので、ノードは単にhIPv4スタックをサポートし、CES-ノードになるためにロケータヘッダのALOCフィールドを使用して、ポリシーベースのルーティングを適用することができる必要があります。
It is possible that the large content providers (LCPs) are not willing to install map-and-encapsulate functionality in front of their sites. If the caching mechanism is not fully reliable or if the mapping lookup delay does have an impact on their clients' user experience, then most likely the LCPs will not adopt the CES architecture.
大規模なコンテンツプロバイダ（のLCP）は自分のサイトの前にマップし、カプセル化機能をインストールすることを望んでいない可能性があります。キャッシュメカニズムは完全には信頼性がないか、またはマッピング検索遅延は、その後、彼らのクライアントのユーザーエクスペリエンスに影響を持っている場合は、最も可能性の高いLCPは、CESのアーキテクチャを採用しません。
In order to convince a LCP to adopt the CES architecture, it should provide a mechanism to mitigate the caching and mapping lookup delay risks. One method is to push the CES architectures to the edge -- the closer to the edge you add new functionality, the better it will scale. That is, if the endpoint stack is upgraded, the caching mechanism is maintained by the endpoint itself. The mapping mechanism can be removed if the CES architecture's addressing scheme is replaced with the addressing scheme of hIPv4 when the CES solution is integrated at the endpoints. With this approach, the LCPs might install a CES-node in front of their sites. Also, some endpoints at the content site might be upgraded with the hIPv4 stack.
CESのアーキテクチャを採用するLCPを説得するためには、キャッシングおよびマッピング検索遅延のリスクを軽減するためのメカニズムを提供する必要があります。エッジに近い新しい機能を追加し、より良い、それはスケールします - 一つの方法は、エッジにCESアーキテクチャをプッシュすることです。エンドポイント・スタックがアップグレードされている場合には、キャッシング・メカニズムは、エンドポイント自体によって維持されます。 CESのアーキテクチャのアドレス指定方式は、CES溶液をエンドポイントに統合されてhIPv4のアドレス指定方式に置き換えられた場合にマッピングメカニズムを除去することができます。このアプローチでは、LCPは、自分のサイトの前にCES-ノードをインストールすることがあります。また、コンテンツサイトでのいくつかのエンドポイントはhIPv4スタックでアップグレードされる可能性があります。
If the LCP faces issues with the caching or mapping mechanisms, the provider can ask its clients to upgrade their endpoint's stack to ensure a proper service level. At the same time, the LCP promotes the migration from the current routing architecture to a new routing architecture, not for the sake of the routing architecture but instead to ensure a proper service level -- you can say that a business model will promote the migration of a new routing architecture.
LCPは、キャッシュやマッピングのメカニズムの問題に直面している場合、プロバイダは、適切なサービスレベルを確保するために彼らのエンドポイントのスタックをアップグレードするには、そのクライアントに依頼することができます。同時に、LCPはないルーティングアーキテクチャのために、新しいルーティングアーキテクチャに現在のルーティングアーキテクチャからの移行を促進する代わりに、適切なサービスレベルを確保するために - あなたはビジネスモデルが移行を促進すると言うことができます新しいルーティングアーキテクチャの。
The hIPv4 framework proposes that the IPv4 addresses (ELOC) should no longer be globally unique; once the transition is completed, a more regional allocation can be deployed. But this is only possible once all endpoints (that are establishing sessions to other ALOC realms) have migrated to support the hIPv4 framework. Here the CES architecture can speed up the re-usage of IPv4 addresses; that is, once an IPv4 address block has become an ELOC block it can be re-used in the other RIR regions, without the requirement that all endpoints in the Internet must first be upgraded.
hIPv4フレームワークは、IPv4アドレス（ELOC）は、もはやグローバルに一意であるべきではないことを提案しています。移行が完了すると、より多くの地域の割り当てを展開することができます。しかし、これは（他のALOCのレルムにセッションを確立している）一度すべてのエンドポイントがhIPv4フレームワークをサポートするために、移行した場合のみ可能です。ここではCESアーキテクチャは、IPv4アドレスの再使用をスピードアップすることができます。つまり、一度IPv4アドレスブロックは、インターネット内のすべてのエンドポイントが最初にアップグレードされなければならない必要とせず、それは他のRIRの領域に再使用することができるELOCブロックとなっています。
As stated earlier, the CES architecture aims to remove PI-addresses from the DFZ, making the content sites more or less the primary target for the roll-out of a CES solution. At large content sites a CES-node most likely will be installed. To upgrade all endpoints (that are providing services towards the Internet) at a large content site will take time, and it might be that the endpoints at the content site are upgraded only within their normal lifecycle process. But if the size of the content site is small, the administrator either installs a CES-node or upgrades the endpoint's stack -- a decision influenced by availability, reliability, and economic feasibility.
先に述べたように、CESのアーキテクチャは、CESソリューションのロールアウトのための主なターゲットコンテンツサイトより以下にすること、DFZからPI-アドレスを削除することを目指しています。大規模なコンテンツサイトではCES-ノードは、最も可能性の高いインストールされます。時間がかかります大型コンテンツサイト（インターネットに向けてサービスを提供している）すべてのエンドポイントをアップグレードするには、それがコンテンツサイトでのエンドポイントが唯一の彼らの通常のライフサイクルプロセス内でアップグレードされていることかもしれません。コンテンツサイトのサイズが小さい場合でも、管理者はCES-ノードをインストールするのいずれかまたはエンドポイントのスタックをアップグレード - 可用性、信頼性、および経済性の影響を受けて決定を。
Once the content sites have been upgraded, the PI-address entries have been removed from the DFZ. Most likely also some endpoints at the consumer sites have been upgraded to support the hIPv4 stack -- especially if there have been issues with the caches or mapping delays that have influenced the service levels at the LCPs. Then, the issue is how to keep track of the upgrade of the content sites -- have they been migrated or not? If the content sites or content endpoints have been migrated, the DNS records should have either a CES-node entry or ALOC entry for each A-record. When the penetration of CES solutions at content sites (followed up by CES-node/ALOC records in DNS) is high enough, the ISP can start to promote the hIPv4 stack upgrade at the consumer sites.
コンテンツサイトは、アップグレードされた後は、PIアドレスのエントリがDFZから削除されました。ほとんどの場合、消費者のサイトでいくつかのエンドポイントがhIPv4スタックをサポートするようにアップグレードされている - のLCPでサービスレベルに影響を与えたキャッシュまたはマッピング遅延の問題があった場合は特に。その後、問題がコンテンツサイトのアップグレードを追跡する方法である - 彼らは移行かいないされていますか？コンテンツサイトやコンテンツのエンドポイントが移行されている場合は、DNSレコードはCES-ノードのエントリまたは各AレコードのためのALOCエントリのいずれかが必要です。コンテンツサイト（DNSでのCES-ノード/ ALOC記録によってフォローアップ）でのCESソリューションの浸透が十分に高い場合、ISPはhIPv4スタックが消費者のサイトでアップグレードを促進するために開始することができます。
Once a PA-address block has been migrated it can be released from global allocation to a regional allocation. Why would an ISP then push its customers to deploy hIPv4 stacks? Because of the business model -- it will be more expensive to stay in the current architecture. The depletion of IPv4 addresses will either cause more NAT at the service provider's network (operational expenditures will increase because the network will become more complex) or the ISP should force its customers to migrate to IPv6. But the ISP could lose customers to other ISPs that are offering IPv4 services.
PA-アドレスブロックが移行されたら、それは地域の割り当てにグローバル割り当てから解除することができます。なぜ、ISPは、hIPv4スタックを展開する顧客をプッシュするのでしょうか？そのためビジネスモデルの - 現在のアーキテクチャに滞在するより高価になるだろう。 IPv4アドレスの枯渇は、サービスプロバイダのネットワーク（ネットワークがより複雑になりますので、運用コストが増加します）、またはISPがIPv6に移行する顧客を強制すべきではより多くのNATが発生しますか。しかし、ISPは、IPv4サービスを提供している他のISPに顧客を失う可能性があります。
When PA-addresses have been migrated to the hIPv4 framework, the ISP will have a more independent routing domain (ALOC realm) with only ALOC prefixes from other ISPs and ELOC prefixes from directly attached customers. BGP churn from other ISPs is no longer received, the amount of alternative paths is reduced, and the ISP can better control the growth of the RIB at their ALOC realm. The operational and capital expenditures should be lower than in the current routing architecture.
PA-アドレスはhIPv4の枠組みに移行された場合は、ISPは、直接接続、顧客から他のISPとELOCプレフィックスからのみALOCプレフィックスを持つ複数の独立したルーティングドメイン（ALOC領域）を有するであろう。他のISPからBGPチャーンがもはや受信され、代替パスの量が低減されていない、およびISPがより自分ALOCレルムでRIBの成長を制御することができます。業務及び資本的支出には、現在のルーティングアーキテクチャにおけるより低くなければなりません。
To summarize, the content providers might find the CES+hIPv4 solution attractive. It will remove the forthcoming IPv4 address depletion constraints without forcing the consumers to switch to IPv6, and thus the content providers can continue to grow (reach more consumers).
要約すると、コンテンツプロバイダは、CES + hIPv4ソリューションは魅力的かもしれません。これは、IPv6に切り替えるには、消費者を強制することなく、今後のIPv4アドレスの枯渇の制約を削除しますので、コンテンツプロバイダは、（より多くの消費者に届く）成長を続けることができます。
The ISP might also find this solution attractive because it should reduce the capital and operational expenditures in the long term. Both the content providers and the ISPs are providing the foundation of the Internet. If both adopt this architecture, the consumers have to adopt. Both providers might find business models to "guide" the consumers towards the new routing architecture.
それは長期的には資本支出と運用コストを削減する必要があるため、ISPはまた、このソリューションは魅力的かもしれません。コンテンツプロバイダやISPの両方が、インターネットの基盤を提供しています。両方このアーキテクチャを採用した場合、消費者が採用しなければなりません。どちらのプロバイダは、新たなルーティングアーキテクチャに向けて消費者を「導く」ためにビジネスモデルを見つけるかもしれません。
Then, how will this affect the consumer and content sites? Residential users will need to upgrade their endpoints. But it doesn't really matter which IP version they use. It is the availability and affordability of the Internet that matters most.
次に、どのようにこれは、消費者とコンテンツサイトに影響を与えるのだろうか？住宅のユーザーは、自分のエンドポイントをアップグレードする必要があります。しかし、本当に彼らが使用しているIPバージョンは関係ありません。これは、最も重要なインターネットの可用性と手頃な価格です。
Enterprises will be affected a little bit more. The edge devices at the enterprises' local networks need to be upgraded -- edge nodes such as AS border routers, middleboxes, DNS, DHCP, and public nodes -- but by installing a CES-node in front of them, the upgrade process is postponed and the legacy nodes can be upgraded during their normal lifecycle process. The internal infrastructure is preserved, internal applications can still use IPv4, and all investment in IPv4 skills is preserved.
企業はもう少し影響を受けることになります。そのような境界ルータ、中間装置、DNS、DHCP、およびパブリックノードとして、エッジノード - - 企業のローカルネットワークにおけるエッジデバイスは、アップグレードする必要があるが、それらの前にCESノードをインストールすることで、アップグレードプロセスであります延期とレガシー・ノードは通常のライフサイクルプロセスの間にアップグレードすることができます。内部インフラストラクチャは保存され、内部のアプリケーションは、まだIPv4のを使用することができ、およびIPv4のスキルのすべての投資は保持されます。
Walkthrough of use cases:
使用例チュートリアル：
1. A legacy endpoint at a content site establishes a session to a content site with a hIPv4 upgraded endpoint.
1.コンテンツサイトでのレガシーエンドポイントはhIPv4アップグレードエンドポイントとコンテンツサイトへのセッションを確立します。
When the legacy endpoint resolves the DNS entry for the remote endpoint (a hIPv4 upgraded endpoint), it receives an ALOC record in the DNS response. The legacy endpoint ignores the ALOC record. Only the A-record is used to establish the session. Next, the legacy endpoint initializes the session and a packet is sent towards the map-and-encapsulate ingress node, which needs to do a lookup at the CES mapping system (the assumption here is that no cache entry exists for the remote endpoint). The mapping system returns either a CES-node prefix or an ALOC prefix for the lookup -- since the requested remote endpoint has been upgraded, the mapping system returns an ALOC prefix.
レガシーエンドポイントがリモートエンドポイント（hIPv4アップグレードされたエンドポイント）のDNSエントリを解決するときは、DNS応答でALOCレコードを受け取ります。レガシーエンドポイントは、ALOCレコードを無視します。唯一のAレコードは、セッションを確立するために使用されます。次に、従来のエンドポイントがセッションを初期化し、パケットがCESマッピングシステムで検索を行う必要があるマップとカプセル化の入口ノードに向けて送信される（ここでの仮定には、キャッシュエントリがリモートエンドポイントのために存在していないということです）。マッピングシステムは、CES-ノードのプレフィックスや検索のためのALOCプレフィックスのいずれかを返します - 要求されたリモートエンドポイントがアップグレードされているため、マッピングシステムは、ALOC接頭辞を返します。
The CES-node will not use the CES encapsulation scheme for this session. Instead, the hIPv4 header scheme will be used and a /32 entry will be created in the cache. A /32 entry must be created; it is possible that not all endpoints at the remote site are upgraded to support the hIPv4 framework. The /32 cache entry can be replaced with a shorter prefix in the cache if all endpoints are upgraded at the remote site. To indicate this situation, a subfield should be added for the ALOC record in the mapping system.
CES-ノードは、このセッションのためのCESカプセル化スキームを使用しません。代わりに、hIPv4ヘッダスキームが使用され、/ 32エントリがキャッシュ内に作成されます。 / 32のエントリを作成する必要があります。リモートサイトのすべてのエンドポイントがhIPv4フレームワークをサポートするようにアップグレードされていない可能性があります。すべてのエンドポイントは、リモートサイトでアップグレードされた場合/ 32キャッシュエントリがキャッシュ内に短いプレフィックスに置き換えることができます。このような状況を示すために、サブフィールドは、マッピングシステムにおけるALOCレコードを追加する必要があります。
The CES-node must execute the following steps for the egress packets:
CES-ノードは、出力パケットのために、次の手順を実行する必要があります。
a. Verify IP and transport header checksums.
A。 IPトランスポートヘッダのチェックサムを検証します。
b. Create the locator header and copy the value in the destination address field of the IP header to the ELOC field of the locator header.
B。ロケータヘッダを作成し、ロケータヘッダのELOCフィールドにIPヘッダの宛先アドレスフィールドに値をコピーします。
c. Replace the destination address in the IP header with the ALOC prefix given in the cache.
C。キャッシュ内の所与ALOCプレフィックスとIPヘッダ内の宛先アドレスを置き換えます。
d. Insert the local CES-node prefix in the ALOC field of the locator header.
D。ロケータヘッダーのALOC分野におけるローカルCES-ノードの接頭辞を挿入します。
e. Copy the transport protocol value of the IP header to the protocol field of the locator header and set the hIPv4 protocol value in the protocol field of the IP header.
電子。ロケータヘッダのプロトコルフィールドにIPヘッダのトランスポートプロトコルの値をコピーして、IPヘッダのプロトコルフィールドにhIPv4プロトコル値を設定します。
f. Set the desired parameters in the A-, I-, S-, VLB-, and L-fields of the locator header.
F。 A-、I-、S-、VLB-、及びロケータヘッダのLフィールドにおける所望のパラメータを設定します。
g. Set the FI-bits of the locator header to 00.
グラム。 00ロケータヘッダのFIビットを設定します。
h. Decrease the TTL value by one.
時間。 1によるTTL値を減らします。
i. Calculate IP, locator, and transport protocol header checksums. Transport protocol header calculations do not include the locator header fields. When completed, the packet is transmitted.
私。 IP、ロケータ、およびトランスポート・プロトコル・ヘッダのチェックサムを計算します。トランスポートプロトコルヘッダの計算は、ロケータヘッダフィールドが含まれていません。完了すると、パケットが送信されます。
j. Because the size of the packet might exceed MTU due to the insertion of the locator header, and if MTU is exceeded, the CES-node should inform the source endpoint of the situation with an ICMP message, and the CES-node should apply fragmentation of the hIPv4 packet.
J。パケットのサイズが原因ロケータヘッダの挿入にMTUを超える可能性があるため、及びMTUを超えた場合、CES-ノードはICMPメッセージと状況のソースエンドポイントに通知しなければならない、とCES-ノードは、断片化を適用すべきですhIPv4パケット。
2. A hIPv4-upgraded endpoint at a consumer/content site establishes a session to a content site with a CES-node in front of a legacy endpoint.
消費者/コンテンツサイトで2 A hIPv4-アップグレードエンドポイントは、レガシーエンドポイントの前のCES-ノードとコンテンツサイトへのセッションを確立します。
The hIPv4 upgraded endpoint receives, in the DNS response, either an ALOC record or a CES-node record for the resolved destination. From the requesting hIPv4 endpoint's point of view, it really doesn't matter if the new record prefix is used to locate RBR-nodes or CES-nodes in the Internet -- the CES-node will act as a hIPv4 proxy in front of the remote legacy endpoint. Thus the hIPv4 endpoint assembles a hIPv4 packet to initialize the session, and when the packet arrives at the CES-node it must execute the following:
hIPv4アップグレードエンドポイントは、DNS応答で、ALOCレコードまたは解決先のためのCES-ノードレコードのいずれかを受け取ります。 CES-ノードが目の前にhIPv4プロキシとして動作します - 新しいレコードのプレフィックスがインターネットにRBR-ノードまたはCES-ノードの位置を特定するために使用されている場合、ビューの要求hIPv4エンドポイントの観点から、それは本当に問題ではありません。リモートレガシーエンドポイント。したがってhIPv4エンドポイントは、セッションを初期化するためにhIPv4パケットを組み立て、パケットはCES-ノードに到着したときには、次のコマンドを実行する必要があります。
a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
A。受信したパケットがIPヘッダのプロトコルフィールドにhIPv4プロトコル値を使用していることを確認します。
b. Verify IP, locator, and transport protocol header checksums. Transport protocol header verification does not include the locator header fields.
B。 IP、ロケータ、およびトランスポート・プロトコル・ヘッダのチェックサムを検証します。トランスポートプロトコルヘッダの検証は、ロケータ・ヘッダ・フィールドを含んでいません。
c. Replace the protocol field value of the IP header with the protocol field value of the locator header.
C。ロケータヘッダのプロトコルフィールド値を有するIPヘッダのプロトコルフィールド値を置き換えます。
d. Replace the destination address in the IP header with the ELOC prefix of the locator header.
D。ロケータヘッダのELOCプレフィックスとIPヘッダ内の宛先アドレスを置き換えます。
e. Remove the locator header.
電子。ロケータヘッダを削除します。
f. Create a cache entry (unless an entry already exists) for returning packets. A /32 entry is required. To optimize the usage of cache entries, the CES-node might ask the CES mapping node whether all endpoints at the remote site are upgraded or not. If upgraded, a shorter prefix can be used in the cache.
F。パケットを返すために（エントリがすでに存在していない限り）キャッシュエントリを作成します。 / 32エントリが必要です。キャッシュエントリの使用を最適化するために、CES-ノードは、リモートサイトのすべてのエンドポイントがアップグレードされているかどうかCESマッピングノードを頼むかもしれません。アップグレードした場合、短いプレフィックスは、キャッシュに使用することができます。
g. Decrease the TTL value by one.
グラム。 1によるTTL値を減らします。
h. Calculate IP and transport protocol header checksums.
時間。 IPトランスポートプロトコルヘッダのチェックサムを計算します。
i. Forward the packet according to the destination address of the IP header.
私。 IPヘッダの宛先アドレスに応じてパケットを転送します。
3. A hIPv4-enabled endpoint with a regionally unique ELOC at a consumer site establishes a session to a consumer site with a legacy endpoint.
消費者向けサイトで地域独自のELOC 3. A hIPv4対応のエンドポイントは、レガシーエンドポイントと消費者のサイトへのセッションを確立します。
In this use case, the sessions will fail unless some mechanism is invented and implemented at the ISPs' map-and-encapsulate nodes. The sessions will work inside an ALOC realm since the classical IPv4 framework is still valid. Sessions between ALOC realms will fail. Some applications establish sessions between consumer sites. The most common are gaming and peer-to-peer applications. These communities have historically been in the forefront of adopting new technologies. It is expected that they either develop workarounds to solve this issue or simply ask their members to upgrade their stacks.
いくつかのメカニズムが発明とISPの地図とカプセル化ノードで実行されていない限り、このユースケースでは、セッションは失敗します。古典のIPv4フレームワークがまだ有効であるため、セッションはALOC領域内で動作します。 ALOCレルムの間のセッションは失敗します。一部のアプリケーションでは、消費者のサイト間のセッションを確立します。最も一般的なのは、ゲームやピア・ツー・ピア・アプリケーションです。これらのコミュニティは、歴史的に新しい技術の採用の最前線にされています。彼らはどちらか、この問題を解決するための回避策を開発したり、単純に自分のスタックをアップグレードするために、そのメンバーを尋ねることが期待されます。
4. A legacy endpoint at a consumer/content site establishes a session to a content site with a CES-node in front of a legacy endpoint.
4.消費者/コンテンツサイトのレガシーエンドポイントは、レガシーエンドポイントの前のCES-ノードとコンテンツサイトとのセッションを確立します。
Assumed to be described in CES architecture documents.
CESアーキテクチャ文書に記載することを想定。
5. A hIPv4-enabled endpoint at a consumer/content site establishes a session to a content site with a hIPv4-enabled endpoint.
消費者/コンテンツサイトで5 A hIPv4対応のエンドポイントはhIPv4対応のエンドポイントとコンテンツサイトへのセッションを確立します。
See Section 5.2.
5.2節を参照してください。
Author's Address
著者のアドレス
Patrick Frejborg EMail: pfrejborg@gmail.com
パトリックFrejborg Eメール：pfrejborg@gmail.com