[要約] RFC 6306は、階層的なIPv4フレームワークを定義し、IPv4アドレスの効率的な割り当てと管理を目指しています。このRFCの目的は、アドレス空間の効率的な利用と、アドレスの階層化によるネットワークのスケーラビリティの向上です。
Internet Research Task Force (IRTF) P. Frejborg
Request for Comments: 6306 July 2011
Category: Experimental
ISSN: 2070-1721
Hierarchical IPv4 Framework
階層IPv4フレームワーク
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.
このドキュメントでは、現在のIPv4アドレススペースを2つの新しいアドレスカテゴリに分割する方法のフレームワークについて説明します。グローバルに一意のコアアドレススペース（エリアロケーター、ALOC）と、地域的にあるエッジアドレススペース（エンドポイントロケーター、ELOC）個性的。将来、ELOCスペースは、プライベートネットワークまたはサービスプロバイダードメインでのみ重要になります。したがって、32x32ビットアドレス指定スキームと階層的なルーティングアーキテクチャが達成されます。階層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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................4
2. 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）は、2006年10月18〜19日にアムステルダムでルーティングとアドレス指定ワークショップを開催しました。ワークショップの結果は[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.
このドキュメントの著者は、IPアドレススペースが2つのグループに分離されることが提案されているため、LISPアプローチが非常に興味深いことを発見しました：デフォルトのフリーゾーン（DFZと呼ばれるインターネットのグローバルルーティングテーブルに存在するルーティングロケーター（RLOC））、およびエンドポイント識別子（EIDS）。これらは、インターネットに接続されたエッジネットワークにのみ存在します。
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の間に設置されたボーダールーターでキャッシュソリューションを必要とする新しいマッピングシステムも導入します。DFZでは、Border Router間にトンネリング（オーバーレイ）スキームが適用されるため、DFZではEIDプレフィックスは必要ありません。著者にとって、これは複雑なアーキテクチャのように思われます。これは、同様の過去のアーキテクチャから学んだ教訓を適用することで改善できるようです。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フレームワークの提案は、MPLSからアイデアを借用してピアツーピアアーキテクチャを開発することにより、LISPからのエッジおよびコアIPアドレス指定グループをオーバーレイソリューションを作成することなく使用できるかどうかの問題から生じました。つまり、トンネリングの代わりに、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.
パケットを組み立てる方法に関して2つのアーキテクチャオプションが存在し、DFZでRBR機能を適用できるようにします。パケットは、イングレスネットワークノード（LISPまたはMPLと同様）またはエンドポイント自体で組み立てられました。エンドポイントでシムヘッダーを使用してパケットを組み立てる際の主な欠点は、エンドポイントのスタックをアップグレードする必要があることです。ただし、重要な利点は、例えばLISPで説明したように、MTU発見のパスの問題が存在しないことです。さらに、キャッシュスケーラビリティの問題は、キャッシュをエンドポイントに押し込むことにより、可能な限り最大限に緩和されます。
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アドレスが許可されています。RBR機能を適用し、現在のIPv4ヘッダーをシムヘッダーで拡張し、エンドポイントで新しいヘッダーを組み立てることにより、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ビットアドレススキームを64ビットに拡張できると判断されました。グローバルにユニークなコアロケーター用に予約されている32ビットと、地元のユニークなエッジロケーター用に予約されている32ビットです。
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フレームワークは、HIPV4として省略されており、これはホストIDプロトコル（HIP）[RFC4423]の略語に近いものであることに注意してください。したがって、読者は、2つの異なるアーキテクチャを表す2つの略語（HIPV4とHIP）の使用に注意を払う必要があります。
Use of the hIPv4 abbreviation has caused much confusion, but it was chosen for two reasons:
HIPV4の略語の使用は多くの混乱を引き起こしましたが、2つの理由で選択されました。
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.
したがって、著者は、領域間にアドレスブロック依存関係があるため、現在の方法は集約アドレス指定スキームとして最もよく説明されると結論付けています。アドレスをエッジとコアロケータースペース（正式な階層）に分割すると、新しい次元が開きます。エッジロケータースペースは、前述の3種類の領域の集約アドレススキームとして展開できます。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）レルムと呼ばれる4番目のレベルが可能になります。
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.
o IPv4-フレームワークはまだ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]。HIPV4フレームワークが調査研究から標準RFCに開発された場合、両方のアーキテクチャが既存の展開されたアーキテクチャとの後方互換性、階層的なアーキテクチャとの後方互換性を共有するため、階層的なIPv4フレームワーク名を拡張インターネットプロトコル、EIPに置き換えることをお勧めします。アドレス指定など、HIPV4の略語は股関節と混同することができます。
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].
キーワードは、[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によってサービスプロバイダーに割り当てられます。ALOCはGLBから割り当てられているため、グローバルにユニークです。
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ブロックは地理的領域でのみユニークです。一意性の最終政策は、RIRSによって定義されます。長期的なルーティングアーキテクチャでは、ELOCブロックはRIRによって割り当てられなくなりました。それは地元のアロックの領域でのみユニークです。
ALOC realm:
アロックレルム：
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.
インターネット内の領域は、少なくとも1つの付着されたレルムボーダールーター（RBR）です。また、ALOCをALOCレルムに割り当てる必要があります。ALOCレルムのルーティング情報ベース（RIB）は、ローカルELOCプレフィックスとグローバルALOCプレフィックスの両方を保持しています。ALOCレルムは、ALOCプレフィックスのみを他のALOCレルムと交換します。
Realm Border Router (RBR):
Realm Border Router（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はロケーターヘッダーの転送インジケーターフィールドを使用できます。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.
地域のインターネットレジストリによって割り当てられた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によるエンドツーエンドの接続性を破るいくつかの障害を作成しました。インターネット。
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.
インターネットの現在のアドレス指定スキームを他のグローバルアドレス指定またはロケーションスキームと比較すると、他のスキームが構造でいくつかのレベルを使用していることに気付きます。たとえば、郵便制度は、道路住所、都市、および国を使用して目的地を見つけます。地理的サイトを見つけるために、地図作成システムで経度と緯度を使用します。もう1つのグローバルネットワークである公共のスイッチング電話ネットワーク（PSTN）は、階層的なシグナリングアーキテクチャを有効にした3レベルの番号付けスキームに基づいて構築されています。現在のIPv4アドレス指定スキームを単一レベルから2レベルのアドレス指定構造に拡大することにより、[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、トンネリング、ロケーターの書き換えなどの追加のメカニズムをサポートする必要があります。不一致を克服するための識別子の助け。その結果、エンドポイントの情報が失われるか、非表示になります。2レベルのアドレス指定スキームを使用すると、これらの追加のメカニズムを削除し、コア/エッジロケーターを使用して新しいルーティングと転送のディレクティブを作成できます。
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フレームワークの2レベルのアドレス指定スキームを理解する便利な方法は、国コード、国家目的地コード、および加入者番号を使用する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).
IPv4ヘッダーとトランスポートプロトコルヘッダーの間に、ALOCおよびELOC要素をシムヘッダー（MPLSおよび[Rbridge]アーキテクチャと同様）として挿入することにより、HIPV4ヘッダーが作成されます。ネットワークの観点から見ると、HIPV4ヘッダーはIPv4ヘッダーのように「見た目と感じ」であり、EIPおよび[Nimrod]の初期の定義で概説されている目標のいくつかを満たします。結果は、現在の転送面をアップグレードする必要がないということですが、コントロールプレーン（例：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）内の領域、またはインターネット内のASESのグループにまたがる領域の位置機能を提供します。エリアには、たとえば、エリアのいくつかの入り口/出口ポイント間の負荷分散などの交通工学目的のために、いくつかの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（またはASESのグループ）内の領域にALOCプレフィックスが割り当てられている場合、その領域にはALOC領域になる可能性があります。ALOCレルムを確立するには、ALOCプレフィックスだけでなく、より多くの要素が必要です。1つまたは複数のレルムボーダールーター（RBR）を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のプレフィックスで構成され、2番目は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を持つことで、ネットワークに潜在的な単一の障害点が作成されることが予想されます。したがって、いくつかのRBRがALOCレルムにインストールされ、RBRSはALOCプレフィックスをロケーターとして使用し、ルーターはALOCプレフィックスをローカルALOC領域内のanycastロケーターとして発表します。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は、マルチキャストソースディスカバリープロトコル（MSDP）[RFC3618]およびプロトコル独立マルチキャスト（PIM）[RFC4601]機能を使用して、Anycast Rendezvous Pointの役割を担いますが、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で説明するように、IPv4アドレスのより地域のアドレス割り当てポリシーを展開できます。ELOCプレフィックスは、ローカルおよびリモート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プレフィックスのみを運ぶだけで十分です。
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.
IPヘッダーの宛先アドレスフィールドの値がリモートALOCプレフィックスであるため、HIPV4パケットがリモートアロックレルムに到着すると、最も近いRBRに転送されます。RBRがHIPV4ヘッダーを交換した場合、IPヘッダーの宛先アドレスフィールドの値はリモートELOCです。したがって、HIPV4パケットは、リモートアロックレルムの最終目的地に転送されます。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.
アドレス指定構造はもはや一次元ではなく、第2レベルの階層が追加されたことを理解しているため、インターネット上のリモートELOC（エンドポイント）とリモートアロックレルムを見つける問題を解決し、どこで組み立てるかを決定することが重要です。HIPV4パケットのヘッダー。階層IPv4フレームワークは、ALOC情報をエンドポイントに配布できるように、新しいレコードタイプをサポートする必要があるドメイン名システムに依存しています。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領域内で使用されるアプリケーション（例：Enterpriseのプライベートネットワーク）は、中間でも長期的なルーティングアーキテクチャでもアップグレードする必要はないことに注意してください。クラシック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スペースはグローバルにユニークではなくなります。代わりに、地域の割り当てポリシーを実装できます。詳細については、付録Aを参照してください。現在のルーティングアーキテクチャから中間ルーティングアーキテクチャへの移行については、付録Dで説明します。
Legend: *attachment point in the ALOC realm UER=Unique ELOC region EP=Endpoint
凡例： *アロックレルムのアタッチメントポイント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.
このセクションでは、2つのHIPV4エンドポイント間のHIPV4セッションの例を示します。イニシエーターと異なるALOCレルムに存在するレスポンダーです。
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スタックがトランスポート用のパケットを組み立てている場合、HIPV4スタックは、DNS応答で受信したALOC情報に基づいて、クラシックIPv4またはHIPV4ヘッダーが使用されるかどうかを決定するものとします。イニシエーターのローカルALOCプレフィックスがレスポンダーのALOCプレフィックスに等しい場合、イニシエーターとレスポンダーの両方がローカルALOC領域に存在するため、ルーティング目的でHIPV4ヘッダーを使用する必要はありません。パケットはローカルアロックレルムを終了しないため、パケットは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.
ALOCレルム内の2つのエンドポイント間のセッションでは、ルーティングの目的ではなく、マルチパス対応トランスポートプロトコルのvaliant耐荷分散[VLB]を使用するため（セクション11.1を参照）、または識別子/ロケーターの分割スキーム（セクション7を参照）。VLBを使用すると、イニシエーターはロケーターヘッダーをパケットに追加し、VLBビットを01または11に設定し、VLBがサブフローを要求されることをレスポンダーおよび中間ルーターに示します。これはイントラアロックレルムセッションであるため、ロケーターヘッダーに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.
識別子/ロケータースプリットスキームがセッション（イントラアロックまたはインターアロック）に適用されている場合、イニシエーターはiビットを1に設定し、ロケーターヘッダー長フィールドを使用する必要があります。識別子/ロケータースプリットスキーム情報は、ロケーターヘッダーの長さフィールドの後にロケーターヘッダーに挿入されます。
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スタックは、ローカルアロックとリモートアロックが一致していないため、セッションに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.
e. ロケーターヘッダーのプロトコルフィールドに輸送プロトコル値を設定し、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.
g. ロケーターヘッダーのFIビットを00に設定します。
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.
h. 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パケットは、リモートアロックレルムの最も近い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. IPヘッダーのソースアドレスを、ロケーターヘッダーのALOCプレフィックスに置き換えます。
d. Replace the destination address in the IP header with the ELOC prefix of the locator header.
d. IPヘッダーの宛先アドレスを、ロケーターヘッダーのELOCプレフィックスに置き換えます。
e. Replace the ALOC prefix in the locator header with the destination address of the IP header.
e. ロケーターヘッダーのALOCプレフィックスをIPヘッダーの宛先アドレスに置き換えます。
f. Replace the ELOC prefix in the locator header with the source address of the IP header.
f. ロケーターヘッダーのELOCプレフィックスをIPヘッダーのソースアドレスに置き換えます。
g. Set the S-field to 1.
g. Sフィールドを1に設定します。
h. Decrease the Time to Live (TTL) value by one.
h. ライブ（TTL）値を1つずつ短縮します。
i. Calculate IP, locator, and transport protocol header checksums. The transport header calculation does not include the locator header fields.
i. 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レルム内にルーティングされます。
5. The responder receives the hIPv4 packet.
5. レスポンダーはHIPV4パケットを受け取ります。
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. Responderの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.
Responderのアプリケーションはイニシエーターに応答し、戻ってくるパケットはほぼ同じ手順を実行します。これは、イニシエーターがセッションを開始したときのようにステップ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レルムの転送面がアップグレードされると確立されます。トランジット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レルムがアップグレードされると、エンタープライズまたはサービスプロバイダーは32ビットのELOCアドレススペースを完全に使用して、アドレススペースの制約を削除し、過剰な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のスワップサービスは、現在のIPv4フレームワークからHIPv4フレームワークへのスムーズな遷移を提供するために、フレームワークに追加されました。現在の転送面の主要なアップグレードは、スワップサービスの導入により回避されます。将来的には、アロック領域に「現状のまま」のままにすることができます。また、ルーターが自然なライフサイクルプロセスでアップグレードされると、アロックレルムの端に向かってスワップサービスをプッシュすることができます。
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で定義されているタスクに反して、ロケーターヘッダーとこのプレフィックスをFIBと比較します。Next-HopエントリがRBR対応の場合、パケットはELOCプレフィックスに従って転送されます。Next-Hopが古典的な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プレフィックスに従って、上流のANYCASTまたはUNICAST ALOC RBRにパケットがルーティングされます。ローカルALOC出口ルーティングは、ローカルALOC FIBに対して適用されます。リモートELOCアプローチルーティングは、リモートアロックレルムの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.
IPおよびトランスポートプロトコルヘッダーはそのままのままであることに注意してください（RBRはルーターであるため、TTL値を除く）。ロケーターヘッダーの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
凡例： *アロックレルムのアタッチメントポイントuer =一意のエロック領域ep =エンドポイントarbr = anycast rbr urbr = unicast 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レルムでアップグレードされると削除できます。ソースのALOCRBRはFIビットを11に設定し、逆パス転送（RPF）チェックがLocator Headerの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).
長期的な進化は、32x32ビットのロケータースペースを提供します。ALOCプレフィックスは、サービスプロバイダーにのみ割り当てられます。ELOCプレフィックスは、ローカルアロックの領域でのみ重要です。エンタープライズは、プライベートネットワークに32ビットのロケータースペースを使用できます（ALOCプレフィックスは添付のISPからレンタルされます）。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.
このセクションでは、2つのHIPV4エンドポイント間のHIPV4セッションの例を示します。ALOC領域のイニシエーターが、HIPV4フレームワークをサポートするために転送面がアップグレードされ、古典的なIPv4転送面を持つリモートALOC領域に居住する応答者。
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.
ローカルアロックレルムの転送面がアップグレードされた場合、エンドポイントにそれについて通知する必要があります。つまり、DHCPへの拡張が必要であるか、エンドポイントが手動で構成されており、ローカルALOCレルムが完全に準拠していることを通知します。
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スタックは、ローカルアロックとリモートアロックが一致していないため、セッションにHIPV4ヘッダーを使用する必要があることに気付きます。イニシエーターのHIPV4スタックは、以下を除き、セクション5.2、ステップ1で説明されているようにパケットを組み立てる必要があります。
g. Set the FI-bits of the locator header to 01.
g. ロケーターヘッダーのFIビットを01に設定します。
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プレフィックスに従ってローカルSLOCレルムを介してルーティングされます。ローカル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. ロケーターヘッダーのFIビットを00に設定します。
d. Decrease the TTL value by one.
d. TTL値を1つ減らします。
e. Calculate IP and locator header checksums.
e. 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.
4. HIPV4パケットは、セクション5.2、手順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. Responderのアプリケーションはイニシエーターに応答し、戻るパケットは次のことを除いて、セクション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ヘッダーの宛先アドレスフィールドの値がローカルALOCプレフィックスと一致し、FIビットが00に設定されていることに気付いた場合、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. ロケーターヘッダーのFIビットを10に設定します。
d. Decrease the TTL value by one.
d. TTL値を1つ減らします。
e. Calculate IP and locator header checksums.
e. 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. Responderの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]に記載されています。もう1つの重要な影響ソースは、「将来のインターネットアーキテクチャは、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).
したがって、識別子要素をHIPV4フレームワークに追加して、将来のアプリケーションのパスを提供して、基礎となるネットワークレイヤーアドレス指定スキーム（ローカルおよびリモートIPアドレスタプル）への現在の依存関係を削除できるようにする必要があります。
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].
ただし、Sigcomm2008のMobiarchワークショップの[ID/loc_split]プレゼンテーションで説明されているように、識別子/ロケーターの分割を適用するさまざまな方法があります。したがって、HIPV4フレームワークは、単一の識別子/ロケータースプリットソリューションを提案または定義しません。分割は、たとえば、マルチパス輸送プロトコルまたは股関節などの識別子/ロケーターデータベーススキームによって達成できます。プレースホルダーがロケーターヘッダーに追加されているため、識別子/ロケーターの分割スキームを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の主な目標の1つは、現在の実装との逆方向の互換性を提供することです。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.
MPTCP自体は、股関節と同様に識別子/ロケーターデータベーススキームを提供しません。代わりに、MPTCPは、2つのエンドポイント間の1つのセッションでサブフローを管理およびバンドルするためのトークンを提案しています。トークンは、セッション識別子の特性を持つと見なすことができ、アプリケーション層の一般的なCookieメカニズムを提供し、アプリケーション層と輸送層の間にセッション層を作成します。したがって、セッション識別子の使用は、サイトとエンドポイントのモビリティシナリオの両方で、モビリティを改善するメカニズムを提供します。
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フレームワークに追加するのはなぜですか？股関節、識別子/ロケーターネットワークプロトコル[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.
ただし、識別子/ロケーターデータベーススキームとDNSセキュリティ（DNSSEC）[RFC4033]を組み合わせることは興味深いものです。今日、セキュリティゾーンは、セキュリティルールセットのロケータープレフィックスを使用してスコープされています。代わりに、完全に適格なドメイン名（FQDN）をルールセットで使用でき、ロケーターのプレフィックスの変更はファイアウォールのセキュリティルールセットに依存しなくなります。もう1つの興味深い側面は、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は、いくつかの自律システム（ASE）にまたがる可能性のあるインターネット内の領域を説明しています。ALOCがエリアを説明するとき、それは今後Anycast 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は、2つのALOCレルム間の特定のノードを記述するためにも使用できます。たとえば、プライベートとISP ALOCレルムの間にインストールされたノード、または2つのプライベートALOCレルムの間にインストールされます。このユースケースでは、ALOCは、プライベートネットワークがインターネットに接続されている添付ファイルのポイントを説明しています。このアロックタイプは、以降、ユニキャストALOCと呼ばれます。
The main difference between anycast and unicast ALOC types is:
AnycastとUnicast ALOCタイプの主な違いは、次のとおりです。
o In an anycast ALOC scenario, ELOC routing information is shared between the attached ALOC realms.
o Anycast ALOCシナリオでは、ELOCルーティング情報が添付のALOCレルム間で共有されます。
o In a unicast ALOC scenario, no ELOC routing information is shared between the attached ALOC realms.
o ユニキャストALOCシナリオでは、接続されたALOCレルム間でELOCルーティング情報は共有されていません。
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スペースは、DFZに設置されているグローバルに一意のALOCスペース（別名GLB）と、プライベートネットワーク内で使用されるプライベートALOCスペースの2つのタイプに分割されています。プライベートアロックは、[RFC1918]で定義されているのと同じロケータースペースを使用します。プライベート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 各ネットワークインターフェイスの1つのELOCプレフィックス。
o One private ALOC prefix due to
o 1つのプライベートアロックプレフィックスが原因です
- The enterprise has recently been merged with another enterprise and overlapping ELOC spaces exist.
- エンタープライズは最近、別の企業と統合されており、ELOCスペースが重複しています。
o Several private ALOC prefixes due to
o いくつかのプライベートアロックプレフィックスが原因です
- 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.
o 1つまたは複数のグローバルALOCプレフィックス。これらのALOCは、エンタープライズネットワークがインターネットにどのように添付されているかを説明しています。
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プレフィックスが返されると、イニシエーターはALOCプレフィックスを独自のローカルALOCプレフィックス（DHCPを介して提供するか、手動で構成）と比較します。
o If the remote ALOC prefix is from the private ALOC space, the initiator will use the given private ALOC prefix for the session.
o リモートALOCプレフィックスがプライベートアロックスペースからのものである場合、イニシエーターはセッションに指定されたプライベート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.
プライベートALOC機能を使用するネットワークを設計するために2つのユースケースが存在します。リモートエンドポイントは遠く離れており、高速長距離接続を活用しており、セッションのパフォーマンスを改善するには、マルチパス輸送プロトコルを使用する必要があります。
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.
もう1つのユースケースは、リモートエンドポイントが最近マージされたネットワークに存在する場合、プライベートELOC [RFC1918]スペースが変更されていない場合に重なります。イニシエーターとレスポンダーの間のネットワークでは、1つまたは複数のユニキャストALOCソリューションが必要です。ELOCプレフィックスが重複しない長距離セッションの場合、AnycastまたはUnicast ALOCソリューションを展開できます。
A third use case follows; again the initiator compares returned ALOC prefixes from DNS with its own local ALOC prefixes:
3番目のユースケースが続きます。繰り返しますが、イニシエーターは、DNSから返されたALOCプレフィックスを独自のローカル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.
o リモートALOCプレフィックスがグローバルALOCスペースからであり、リモートALOCが指定されたグローバルALOCプレフィックスと一致しない場合、イニシエーターはセッションに指定されたグローバル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領域のイニシエーターの出力パケットは、ロケーターヘッダーのALOCプレフィックスに基づいて明示的なパス（MPLS LSP、L2TPV3トンネルなど）にルーティングされたIPヘッダーのプロトコル値によって識別できます。ローカル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は、VPN接続とインターネット上（中間ルーティングアーキテクチャ）を介してマルチパスセッションを持つ2つのエンドポイントを持つ概念図を示しています。
Legend: *attachment point in the ALOC realm UER=Unique ELOC region EP=Endpoint aRBR=anycast RBR uRBR=unicast RBR BR=Border Router
凡例： *アロックレルムのアタッチメントポイントuer =一意のエロック領域ep =エンドポイントarbr = anycast rbr urbr = unicast rbr br = borderルーター
|-------------------------------------------------------------|
| 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.
最初のサブフローは、urbr3とurbr4を介してイニシエーター（EP1）から（両方ともプライベートユニキャストALOCプレフィックスを使用して）レスポンダー（EP2）に確立されます。通常のユニキャスト転送が適用されます。URBR3とURBR4のALOCプレフィックスは、ローカルアロックレルムとリモートALOCレルムの両方のルーティングテーブルにインストールされています。2番目のサブフローは、インターネット、つまりBR1-> BR2からEP2への介して確立されます。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.
ELOCプレフィックスは、ローカルおよびリモートのALOCレルムが異なるELOC領域に存在し、プライベートユニキャストALOCプレフィックスによって分離されているため、重複する可能性があることに注意してください。
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.
4番目のユースケースは、[split-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.
5番目のユースケースは、住宅ユーザー向けです。住宅ユーザーは、ISPのサービスオファーとネットワーク設計に応じて、1つまたは複数のALOCプレフィックスを使用できます。ISPがマルチパス輸送プロトコルとローカルALOC出口ルーティングの高度なサポートを提供することを好む場合、住宅ユーザーにはいくつかのALOCプレフィックスが提供されます。住宅ユーザーに提供されるALOCはGLBスペースから取得され、Anycast 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アーキテクチャは、新しい拡張機能をサポートする必要があります。タイプのリソースレコードは、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フレームワークが完全に実装されると、DFZのBGPピア間でALOCプレフィックスのみが発表されます。
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つまたは複数のRBRが付着する必要があります。ALOCプレフィックスは、RBRのAnycast IPアドレスとして構成されています。Anycast 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アドレスをソケットから、およびIPヘッダーの宛先アドレスとしてリモートALOCプレフィックスを備えた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がHIPV4をサポートするためにアップグレードされるエンドポイントを提供するために新しいリソースレコード（RR）タイプが必要であることは明らかです。将来のRRタイプは、[RFC3597]および[RFC5395]で説明されているガイドラインに従って、次の特性を備えていなければなりません。
o Associated with the appropriate Fully Qualified Domain Name (FQDN), inserted in the NAME field.
o 名前フィールドに挿入された、適切な完全資格のドメイン名（FQDN）に関連付けられています。
o Assigned a new integer (QTYPE) in the TYPE field, to be assigned by IANA.
o IANAによって割り当てられるように、タイプフィールドに新しい整数（QTYPE）を割り当てました。
o The CLASS field is set to IN.
o クラスフィールドはに設定されています。
o The RDATA field is of an unknown type as defined in [RFC3597] and shall have the following format:
o RDATAフィールドは、[RFC3597]で定義されている未知のタイプで、次の形式を使用するものとします。
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：ALOCRRの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を利用するものとします。また、ALOCRRが返されたときにA RRがその目的に使用されるため、新しいELOC RRを定義する必要はありません。
Figure 5 shows how the locator header is added to the current IPv4 header, creating a hIPv4 header.
図5は、ロケーターヘッダーが現在のIPv4ヘッダーに追加され、HIPV4ヘッダーの作成方法を示しています。
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.
フラグフィールドは、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 REALM BIT、A-BIT：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に設定します。RBRは、IPヘッダーのソースアドレスと宛先アドレスをロケーターヘッダーのALOCおよびELOCプレフィックスと交換すると、このビットを1に設定します。
Forwarding Indicator, FI-bits: 2 bits
転送指標、FIビット：2ビット
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）フィールドの目的は、将来の転送面がメカニズムを提供して、どの転送情報ベース（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出口ルーティングモード。イニシエーターは、FIビットを01に設定し、ロケーターヘッダーのALOCプレフィックスを使用して、ローカルALOCプレフィックスの所有者であるRBRにパケットを転送します。RBRはFIビットを00に変更するものとします。
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ヘッダーの宛先アドレスフィールドの値に従ってパケットを転送するものとします。DFZルーターは、宛先アドレスがローカルALOCプレフィックスと一致しない限り、IPヘッダーの宛先アドレスフィールドの値に基づいてパケットを転送するものとします。この状況が発生すると、パケットがリモートアロックレルムに入り、リモートRBRはFIビットを10に変更します。
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アプローチルーティングモード。リモートアロック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：アロック間RPFチェックモード。ローカルALOC RBRはFIビットを11に変更し、共有ツリーの次のインターアロックルーターは、ロケーターヘッダーのALOCプレフィックスに対してRPFチェックを適用するものとします。
Valiant Load-Balancing, VLB-bits: 2 bits (optional, subject for further research)
Valiant Load-Balancing、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：次のサブフロー。勇敢な負荷分散を適用する必要があります
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ビットをゼロに設定する必要があります。Valiant Load-Balancing-Capableノードは、値がゼロに設定されている場合、セッションに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によってサービスプロバイダーに割り当てられます。ALOCはGLBから割り当てられているため、グローバルにユニークです。
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ブロックは地理的領域でのみユニークです。一意性の最終政策は、RIRSによって定義されます。長期的なルーティングアーキテクチャでは、ELOCブロックはRIRによって割り当てられなくなりました。それは地元のアロックの領域でのみユニークです。
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.
2つのALOCレルムに存在する同じローカルELOCプレフィックスを持つ2つのイニシエーターが、3番目の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情報の助けを借りて1つの一意のセッションのみを受け入れる必要があります。「同一のセッションの状況」がある場合、つまり、両方のイニシエーターが5タプル<プロトコル、ローカルIPアドレス、ローカルポート、リモートIPアドレス、リモートポート>で同じ値を使用します。続行するセッション。次のセッションは禁止されており、イニシエーターは「同一のセッションの状況」に関する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ビットと定義されているトークンを導入しています。トークンは、セッションの一意性を特定して検証するための将来のアプリケーションに6番目のタプルを提供します。したがって、「同一のセッションの状況」を持つ確率はさらに減少します。識別子/ロケーターデータベーススキームを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パケットに追加すると、そのサイズが増加しますが、パケットはエンドポイントで組み立てられているため、ネットワーク内の現在のPATH 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 生のソケットに基づくアプリケーション - 生のソケットは、ペイロードのみを受け取る他のソケットとは対照的に、完全なヘッダーを含むパケットを受信します。
o Applications needed to enable the hIPv4 framework, such as DNS and DHCP databases, which must be extended to support ALOC prefixes.
o ALOCプレフィックスをサポートするために拡張する必要があるDNSやDHCPデータベースなど、HIPV4フレームワークを有効にするために必要なアプリケーションが必要です。
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:
o IPアドレスをペイロードに挿入するアプリケーション、または新しいセッションをセットアップするためにIPアドレスを使用して、ある種の識別または紹介として。このカテゴリに属するアプリケーションは、拡張機能が組み込まれるまで他のALOCレルムにセッションを設定することはできません。ローカルALOCの領域内では、現在のIPv4スキームがまだ有効であるため、制限はありません。次のアプリケーションが特定されています。
- SIP: IP addresses are inserted in the SDP offers/answers, XML body, Contact, Via, maddr, Route, Record-Route SIP headers.
- SIP：IPアドレスは、SDPオファー/回答、XMLボディ、連絡先、via、maddr、ルート、レコードルートSIPヘッダーに挿入されます。
- 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.
o FQDNで機能するアプリケーションですが、Ping、Traceroute、Telnetなど、代わりに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フレームワークは保持されます。HIPV4ヘッダーをサポートするために、ALOCレルム間で使用されるIP対応アプリケーションをアップグレードする必要があります。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レルムで、IPヘッダーのソースアドレスフィールドの値を、インターアロックマルチキャストストリームのローカルALOCプレフィックスに置き換える必要があります。これは、ローカルRBRがMSDPおよびPIM機能を備えたAnycast Rendezvousポイントとしても機能する場合に達成できます。これらの機能により、RBRはマルチキャスト対応RBR（MRBR）になります。ソースはMRBRとソースツリーでレジスタを登録し、ソースとMRBRの間に確立されます。インターアロックレルムレシーバーがマルチキャストグループを購読する場合、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. IPヘッダーのソースアドレスをローカルALOCプレフィックスに置き換えます。
d. Set the S-field to 1.
d. Sフィールドを1に設定します。
e. Decrease the TTL value by one.
e. TTL値を1つ減らします。
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.
g. パケットを共有マルチキャストツリーに転送します。
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アドレスを設定します。
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.
e. ロケーターヘッダーのa-、i-、s-、vlb-、およびlフィールドに目的のパラメーターを設定します。
f. Set the FI-bits of the locator header to 00.
f. ロケーターヘッダーのFIビットを00に設定します。
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.
g. 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レルムへの荷重バランスは、領域でのRBRの配置によって影響を受ける可能性があります。RBRは、最短パススキームを提供します。また、RIRポリシーが許可されている場合、サービスプロバイダーはいくつかのALOCを割り当てることができます。したがって、ALOCプレフィックスの助けを借りて、トラフィックエンジニアリングとフィルタリングを実行できます。たとえば、DFZに完全に分布していない1つの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出口ルーティングを適用するには、サイトのイニシエーターとボーダールーターの間にいくつかの新しいネットワークノードが必要です。
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.
マルチパストランスポートプロトコルとともに、サブフローは特定のアタッチメントポイント、つまり、プライベートローカル/リモートアロックレルム（マルチホームサイト）とインターネットの間にあるボーダールーターを介してルーティングできます。マルチホーミングはマルチパスになります。詳細については、付録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.
マルチパス対応輸送プロトコルを使用すると、Valiant Load-Balancing [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.
RBR機能がValiant Load-Balancing Enabled Backboneノード（以下VRBRと呼ばれる）に展開され、バックボーンノードが論理的なメッシュ化された接続を介して相互接続されている場合、サブフローにValiant Load-Balancingを適用できます。サブフローにロケーターヘッダーのVLBフィールドに適切なビットが設定されている場合、ファーストイングレスVRBRはサブフローのVLBスイッチングを行います。つまり、vlbビットが01または11に設定されている場合、vlbのパケットのVLBスイッチングを行うことが許可されています。L-bitが0に設定され、VRBRのローカルALOCプレフィックスがAloc-Field'sと一致しますプレフィックス。ロケーターヘッダーにALOCおよびELOCフィールドがないが、他のフィールドの値が上記のように設定されている場合、VRBRはサブフローにも同様にVLBスイッチングを適用する必要があります。マルチパス対応セッション。
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レルムでのみ切り替えられ、サブフローはさまざまなパスでインターネット全体でルーティングされる可能性があります。すべてのALOCレルムでVLBスイッチングが適用される場合、これはサブフローに多すぎるレイテンシを追加する可能性が最も高くなります。最初の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リブの成長の背後にある重要な調査結果の1つです。[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.
マルチホミングを展開する理由の1つは、上流のISPが交換されたときにローカルインフラストラクチャの変更を避けることです。したがって、今日、Pi-Addressブロックはエンタープライズに展開されています。中間ルーティングアーキテクチャでは、エンタープライズには、内部ルーティングに使用される地域のPI ELOCブロック（詳細については、付録Aを参照）が割り当てられます。アップストリームISPは、エンタープライズのネットワークがインターネットにどのように接続されているかを説明するALOCプレフィックスを提供します。エンタープライズが別のISPに切り替えることを希望する場合、ALOCプレフィックスはインターネット接続にのみ使用されるため、ローカルネットワークの接続性の中断なしに、以前のISPのALOCプレフィックスから新しいISPのALOCプレフィックスまで、エンドポイントのALOCプレフィックスのみを変更します - - エンドポイントでいくつかのアロックを同時に使用できます。したがって、あるISPから別の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ビットと定義されています。トークンは、セッションの一意性を識別および検証するための6番目のタプルを提供します。この6番目のタプル - トークン - は、基礎となる層であるIPレイヤーに依存しません。セッションはトークンの助けを借りて識別されるため、アプリケーションはロケーターパラメーターがいつ変更されるかを認識しません。マルチホームのシナリオでは、アプリケーションは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.
セキュリティの問題が発生します：トークンは、たとえば中間の攻撃など、セッション中にキャプチャできます。これらの攻撃は、たとえば[TCPCRYPT]を適用することで軽減できます。アプリケーションが中間攻撃に対する完全な保護が必要な場合、ユーザーはセッションにTransport Layer Security Protocol（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はモバイルエンドポイントにローミング機能を提供します。ただし、一部のユースケースでは、固定エンドポイントはセッションをモバイルレスポンダーに初期化する必要があります。したがって、モバイルIP（MIP）[RFC5944]には、HIPV4拡張機能を組み込む必要があります。MIPは、モバイルエンドポイントにランデブーサービスを提供します。
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.
また、多くのアプリケーションは、ユーザーにRendezvousサービスを提供しています。たとえば、SIP、ピアツーピア、インスタントメッセージングサービスを提供しています。一般的なランデブーサービスソリューションは、識別子/ロケーターデータベーススキーム（股関節、ILNP、またはNBSなど）によって提供できます。必要に応じて、ユーザー（実際にアプリケーション）は、拡張MIP、アプリケーション固有のランデブーサービス、一般的なランデブーサービス、またはそれらの組み合わせなど、これらのランデブーサービススキームのいずれかを利用できます。
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フレームワークでは、現在のIPv4スタック、インフラストラクチャシステム、およびIPアドレス情報を使用するいくつかのアプリケーションへの拡張機能が必要ですが、インターネット内の現在の転送面はそのまま残っていますが、新しい転送要素（RBR）が作成するには、アロックレルム。
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.
IPv4スタック、インフラストラクチャシステム、およびIPアドレス情報を使用するアプリケーションへの拡張は、現在の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:
一次元アドレス指定構造は、階層的アドレス指定スキームとルーティングアーキテクチャに追加された4番目の階層に置き換えるのはいつですか？著者は、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.
HIPV4フレームワークが成功しない最大のリスクと理由は、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 Endpointのスタックをアップグレードし、例えば、重要なシステムまたは複雑なシステムでは、間違いなく時間がかかります。したがって、そのようなシステムの前にミドルボックスをインストールする方が便利です。HIPV4フレームワークには、遷移をスピードアップするためのミドルボックスソリューションが必要であることは明らかです。CESアーキテクチャとHIPV4フレームワークを組み合わせることで、そのような中間ボックスが生成される場合があります。詳細については、付録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ステータスを実現するには、付録Dを参照してください。他の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レルムを介してルーティングする必要があります。安全なドメイン間ルーティング（SIDR）ワーキンググループを使用して、ALOCプレフィックスをハイジャックから保護できるかどうかを判断する研究を行う必要があります。
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.
特定のELOCプレフィックスをハイジャックできないことにより、分散型拒否（DDOS）攻撃を緩和するときにいくつかの意味があります。この含意は、特に長期的なルーティングアーキテクチャで発生します。たとえば、多裕福な企業がISPにユニキャストALOC RBRと接続されている場合です。
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つの方法は、攻撃の犠牲者が「移転」されるように、より具体的な接頭辞（通常はホストプレフィックス）をルーティングテーブルに注入することです。陥没穴は、偽のトラフィックを有効なトラフィックから分離するか、攻撃を分析する場合があります。長期的なルーティングアーキテクチャの課題は、ISPのルーティングテーブルにELOCプレフィックスをインストールできない場合に、マルチホームエンタープライズの特定の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領域でのファイアウォール（または同様のノード）が攻撃を発見します。エンタープライズのセキュリティスタッフは、攻撃によって引き起こされる受信トラフィックの量がすぐに接続またはその他のリソースを飽和させることを認識しています。したがって、スタッフは、攻撃の上流ISPに、また被害者のALOCプレフィックスXとELOCプレフィックスYについて通知します。
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ルールを適用します。NATルールは、IPヘッダーの宛先アドレスがXとロケーターヘッダーのELOCプレフィックスがYと一致する場合、パケットのIPヘッダーの宛先アドレスをzに置き換えます。また、サービスIDはロケーターヘッダーに挿入されます。サービス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によって識別されます。偽のトラフィックは陥没穴で破棄されます。有効なトラフィックの場合、IPヘッダーZの宛先アドレスの値はXに置き換えられます。分析されたパケットのサービスIDを使用することにより、エンタープライズはサービス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レルムにまたがる攻撃には、新しい方法が必要です。1つの例を上記で説明します。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 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.
HIPV4フレームワークはCatch-22の状況を作成しないため、HIPV4への移行は企業にとって魅力的かもしれません。たとえば、プライベートネットワーク内でのみ使用されるアプリケーションはいつIPv4からIPv6に移植されるべきですか？また、アプリケーションをIPv6に移植するためのビジネスの正当化は何ですか？別の問題は、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.
ただし、Enterpriseが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用に同様のスキームを展開できます。つまり、64x64ビットロケータースペースを作成できます。しかし、次のような、この文書が書かれた時点でいくつかの利点が失われていたでしょう。
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].
o ALOCおよびELOCプレフィックスを含むロケーターヘッダーは、96ビットに対して160ビットが大きかったでしょう。識別子（EUI-64）は常に存在していました。これは、[RFC4941]および[Mobility_＆_privacy]で説明されているように、プライバシー問題の見解に応じて、長所または短所と見なすことができます。
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] Wang、Z。、「EIP：The Extended Internet Protocol」、RFC 1385、1992年11月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F.、ed。、「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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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] Fenner、B.、Handley、M.、Holbrook、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.、Gan、D.、Tappan、D.、およびC. Pignataro、「マルチパートメッセージをサポートするためにICMPを拡張」、RFC 4884、2007年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944] Perkins、C.、ed。、「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] Jen、D.、Meisel、M.、Yan、H。Massey、D.、Wang、L.、Zhang、B.、Zhang、L。、「新しいインターネットルーティングアーキテクチャに向けて：エッジを分離するための議論Transit Core "、2008、http：//conferences.sigcomm.org/ hotnets/2008/Papers/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.、Braun、M.B.、Brim、S.、Eggert、L.、Vogt、C.、Zhang、L。、「Perspectives Workshop：将来のインターネットでの命名とアドレス指定」、2009年、http：//www.dagstuhl.de/ de/programm/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] Thaler、D。、「なぜ私たちはとにかくID/ロケーターを分割したいのですか？」、2008、http：//conferences.sigcomm/2008/workshops/mobiarch/slides/thaler.pdf。
[ILNP] Atkinson, R., "ILNP Concept of Operations", Work in Progress, February 2011.
[ILNP] Atkinson、R。、「ILNP Operations of Operations」、Work in Progress、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.、Chuang、J。、「Valiant Load-Balancing Networksの最適性と相互接続」、2007年、http：//people.ischool.berkeley.edu/~chuang/ pubs/vlb-infocom07。PDF。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol", Work in Progress, June 2011.
[lisp] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator/ID Separation Protocol」、2011年6月の作業。
[Mobility_&_Privacy] Brim, S., Linsner. M., McLaughlin, B., and K. Wierenga, "Mobility and Privacy", Work in Progress, March 2011.
[モビリティ_＆_プライバシー] Brim、S.、Linsner。M.、McLaughlin、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.、Xu、M.、Ming、Z。、およびC. Vogt、「名前ベースのSockets Architecture」、2010年9月に進行中の作業。
[Nimrod] Chiappa, N., "A New IP Routing and Addressing Architecture", 1991, http://ana-3.lcs.mit.edu/ ~jnc/nimrod/overview.txt.
[Nimrod] Chiappa、N。、「新しいIPルーティングとアドレス指定アーキテクチャ」、1991、http：//ana-3.lcs.mit.edu/〜jnc/nimrod/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] Godfrey、P.G.、Shenker、S.、Stoica、I。、「Pathlet Routing」、2008、http：//conferences.sigcomm.org/hotnets/2008/ Papers/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] Delong、O。、「IPv4アプリケーションをデュアルスタックに移植する、例を挙げて」、2010年、http：//www.apricot.net/apricot2010/program/tutorials/ porting-ipv4-apps.html。
[RBridge] Perlman, R., "RBridges, Transparent Routing", 2004, http://www.ieee-infocom.org/2004/Papers/26_1.PDF.
[Rbridge] Perlman、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] Kim、C.、Caesar、M.、Gerber、A.、Rexford、J。、「Revisiting Route Caching：The World Be Flat」、2009、http：//www.springerlink.com/content/80w13260665vv2222013333/。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597] Gustafsson、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] Fenner、B.、ed。、およびD. Meyer、ed。、「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] Moskowitz、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. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、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] Meyer、D.、ed。、Zhang、L.、ed。、およびK. Fall、ed。、「ルーティングとアドレス指定に関するIABワークショップからの報告」、RFC 4984、2007年9月。
[RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", RFC 5395, November 2008.
[RFC5395] EastLake 3rd、D。、「ドメイン名システム（DNS）IANAの考慮事項」、RFC 5395、2008年11月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「双方向転送検出（BFD）」、RFC 5880、2010年6月。
[RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", RFC 6115, February 2011.
[RFC6115] Li、T.、ed。、「ルーティングアーキテクチャの推奨」、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] Ford、A.、Raiciu、C.、Handley、M.、Barre、S.、およびJ. Iyengar、「MultiPath TCP開発のための建築ガイドライン」、RFC 6182、2011年3月。
[RFC6227] Li, T., Ed., "Design Goals for Scalable Internet Routing", RFC 6227, May 2011.
[RFC6227] Li、T.、ed。、「スケーラブルなインターネットルーティングの設計目標」、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.
[足場] Freedman、M.J.、Arye、M.、Gopalan、P.、Steven Y. Ko、S.Y.、Nordstrom、E.、Rexford、J.、Shue、D。：//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.
[split-dns]バインド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.、Hamburg、M.、Handley、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] Zhang-Shen、R.、McKeown、N。、「Valiant Load-Balancingを備えた予測可能なインターネットバックボーンの設計」、2004年、http：//conferences.sigcomm.org/hotnets/ 2004/hotnets-iii％20proceed/Zhang-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フレームワークのアーキテクチャに影響を与えたアイデア、提案、議論を提供してきました。以下の人は、アルファベット順に貴重なレビュー情報を提供しています：Aki Anttila、Mohamed Boucadair、Antti Jarvenpaa、Dae Young Kim、Mark Lewis、Wes Toman、およびRobin Whittle。
Also, during the IRSG and IESG review process, Rajeev Koodli, Wesley Eddy, Jari Arkko, and Adrian Farrel provided valuable review input.
また、IRSGおよびIESGレビュープロセスでは、Rajeev Koodli、Wesley Eddy、Jari Arkko、およびAdrian Farrelが貴重なレビュー入力を提供しました。
Lastly, a special thanks to Alfred Schwab from the Poughkeepsie ITSO for his editorial assistance.
最後に、彼の編集支援をしてくれたPouchkeepsie ItsoのAlfred Schwabに特別な感謝です。
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アドレスブロックの再利用を可能にすることを確認する方法を検討します。最終的なポリシーを定義するのは、地域のインターネットレジストリ（RIRS）です。
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.
大企業には、国境ルーティングとして実装するリソースがあります。ほとんどの大企業は、すでにマルチホーミングソリューションを実装しています。中小企業（中小企業）は、国境ルーティングとして実装するリソースを持たない場合があります。または、実装は中小企業に不必要なコストを導入します。また、すべての企業に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レルム、つまりRBRソリューションを実装し、ボーダールーティングとして実装することを余儀なくされることなく、RIRからPI ELOCブロックを予約できるはずです。PI ELOCブロックはグローバルにユニークではなくなっているため、中小企業は、アクティブであるか、インターネットに添付ポイントがある地域の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.
エンタープライズがインターネットサービスプロバイダーを交換する場合、ELOCスキームを変更する必要はありません。エンドポイントのローカルALOCプレフィックスのみが変更されます。エンタープライズの内部トラフィックは、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.
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:
インターアロックレルムセッションを確立する転送面とすべてのホストが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スペースは、これ以降、ローカルアロックの領域でのみ重要です。
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スペースを拡張して、AnycastおよびUnicast ALOCの割り当てに対して32ビットすべて（RFC 1918で定義されているブロックを除く）を使用できます。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.
o ISPとエンタープライズはELOCルーティング情報を共有する必要がなくなったため、グローバルAnycast ALOCソリューションはグローバルユニキャストALOCソリューションに置き換えることができます。また、GLBには、すべての企業向けにグローバルユニキャストALOCプレフィックス（ES）を予約するのに十分なスペースがあります。
o Residential users will still use global anycast ALOC solutions, and if they change service providers, their locators need to be replaced.
o 住宅ユーザーは引き続きグローバルなAnycast 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.
その結果、32x32ビットのロケータースペースが達成されます。企業がISPを別のISPに置き換えると、ALOCプレフィックス（ES）のみがエンドポイントとインフラストラクチャノードで置き換えられます。ALOCプレフィックスの変更は、たとえばDHCPやIGPへの拡張により自動化できます。
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を参照）が完全に完了すると、ALOCレルムを作成したISPのrib骨に次のエントリがあります。
o The PA ELOC blocks of directly attached customers (residential and enterprises)
o 直接添付された顧客（住宅および企業）のPA ELOCブロック
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
o 他のサービスプロバイダーから受け取ったグローバルにユニークなALOCプレフィックス
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のrib骨のサイズの成長に最大の影響を与えているため、A /20 IPv4プレフィックスをA /32 ALOCプレフィックスに置き換えても、DFZのrib骨のサイズは小さくなりません。
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.
この種のALOC割り当てポリシーを実装すると、マルチホミングがDFZのrib骨サイズを増やさないため、DFZのrib骨サイズが大幅に削減されます。しかし、このポリシーは、ルーティング情報を圧縮することでネットワークでの可視性を失うため、回復力の動作にある程度影響を与えます。今日のマルチホーミングソリューションでは、ネットワークは常にリモートエンドポイントがどこに存在するかを常に知っています。リンクまたはネットワークの障害の場合、バックアップパスが計算され、代替パスが見つかり、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が与えられています。アップストリームサービスプロバイダーは、エンタープライズのALOC情報を提供します。10.1.1.1および10.2.2.2。リモートエンドポイントがインストールされ、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はマルチホームです。ALOCは現在のIPスタックのAPIでは使用できませんが、両方のELOCはAPIのローカルおよびリモートIPアドレスと見なされるため、アプリケーションはIPアドレス172.16.1.1と192.168.1.1の間で通信します。ALOCプレフィックスが含まれている場合、セッションは10.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を所有するサービスプロバイダーとの間のリンクがダウンします。イニシエーター（BR-I3）のボーダールーターは、サービスプロバイダーとELOC情報の間でALOC情報のみが交換されるため、ALOCの領域内にとどまるために圧縮されるため、状況を認識しません。しかし、BR-R1はリンクの障害に気付くでしょう。BR-R1は、このセッションのロケーターヘッダーのALOCフィールドを10.1.1.1から10.2.2.2に書き換え、BR-R2を介して2番目のサービスプロバイダーにパケットを送信できます。イニシエーター10.3.3.3：172.16.1.1とレスポンダー10.2.2.2:192.168.1.1のセッションは、IPスタックAPIのレガシー5タプルが変更されないため、そのままのままです。レスポンダーの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宛先の到達不可能なメッセージを受け取る可能性があります（セキュリティ機能によってブロックされていない場合）。。または、エンドポイントは、セッションの特定のタイムアウトの後、他のアロックに切り替えようとする場合があります。すべてのセッション移行ケースでは、レガシー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]を使用して、セッションのハイジャックをさらに軽減できます。アプリケーションが中間の攻撃に対する完全な保護を必要とする場合、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でのリブエントリの低い成長を提供します。
o When static routing is used between the enterprise and the ISP:
o エンタープライズと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または隣接するISPS ribでBGPチャーンを引き起こすことはできません。
o When dynamic routing is used between the enterprise and the ISP:
o エンタープライズと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のBGPチャーンを引き起こす可能性がありますが、DFZでは発生しません。
o The cost of the border router should be less than in today's multi-homing solution.
o ボーダールーターのコストは、今日のマルチホミングソリューションよりも少ないはずです。
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.
o モビリティ - ワイヤレスアクセスネットワークを上回るアプリケーションの需要が増加すると推定されています。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 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.
o IPv4からIPv6（現在定義されているアーキテクチャ）への移行により、DFZ全体でRIBとFIBが増加します。[RFC4984]で説明されているように、転送面の新しいアップグレードが必要かどうかは不明です。おそらくアップグレードが必要です。IPv4とIPv6を同時に展開する結果は、ルーターがリブとFIBのより大きなメモリを持つ必要があることです。すべてのグローバルに一意のプレフィックスは、DFZに参加しているルーターにインストールされています。エンタープライズはDFZのすべてのルーターに1つまたは複数の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.
o 別の問題：IPv4からIPv6（現在定義されているアーキテクチャ）への移行が発生した場合、[RFC4984]で説明されているように、DFZのルーターをより高価なルーターにアップグレードする必要がある可能性が高いです。インターネットユーザーの大きな浸透がすでに存在している世界の裕福な地域では、サービスプロバイダーは、サブスクライバーにアップグレードのコストをより簡単に渡すことができます。「裕福な/高い浸透」比では、サブスクライバーがインターネットを放棄するため、コストはそれほど成長しません。しかし、通常、加入者の浸透度が低い世界の裕福でない地域では、アップグレードのコストをそれほど簡単に受け入れることはできません。「裕福で低い浸透度の低い」比率は、コストの劇的な増加を課す可能性があります。加入者に渡す必要があります。したがって、インターネットに接続する余裕があるサブスクライバーは少なくなりました。世界の裕福でない地域のグローバル企業と企業にとって、このシナリオは潜在的な顧客が少なくなり、企業の遊牧民がインターネットに接続できない状況がある可能性があります。これも公平ではありません。すべての人間は、インターネット体験を楽しむことができる公正なチャンスを持つべきであり、世界の裕福な部分はこれを考慮すべきです。多くの企業は、企業の社会的責任プログラムに取り組んでいます。
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.
技術的および経済的な議論だけではありません。たとえば、インターネットの進化の現在の予測とは対照的に、インターネットがより環境に優しく、より手頃な価格になることなど、一般大衆が関心を持ち、懸念している他の議論は見つかります。
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フレームワークにはエンドポイントのスタックの変更が必要なため、現在のIPv4アーキテクチャが中間HIPV4ルーティングアーキテクチャに移行するまでには時間がかかります。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-Addressエントリを最小限に抑え、エンドポイントの現在のスタックを保存することです。しかし、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アーキテクチャは、DFZのrib骨にインストールされているものとローカルネットワークにインストールされている2つの新しいカテゴリに、アドレススペースを2つの新しいカテゴリに分割するため、CESアーキテクチャとHIPV4フレームワークの間にある程度の類似点があります。実際、IPおよびロケーターヘッダースワップ機能の発明は[LISP]に触発されました。
In order to describe how these two architectures might be integrated, some terminology definitions are needed:
これらの2つのアーキテクチャがどのように統合されるかを説明するために、いくつかの用語の定義が必要です。
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
o ロケーターヘッダーのALOCフィールドにポリシーベースのルーティングを適用できること
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.
CESノードには、MPTCP拡張が含まれていません。これは、CACHED HIPV4エントリのMPTCPサブフローを信号と維持するにはCESノードに多大な負担をかける可能性が高いためです。
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-Addressesを使用しますが、中型/中小企業はPi-またはPAアドレス空間のいずれかを使用します。
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-Addressエントリを削減することを目的としています。したがって、MapとEncapsulateの出力機能は、コンテンツサイトの前にインストールされます。MapとEncapsulateの出力機能を含むノードには、マップとカプセルのイングレス機能も含まれている可能性があります。また、ルーターであるため、ノードはHIPV4スタックをサポートし、ロケーターヘッダーのALOCフィールドを使用してCESノードになるためにポリシーベースのルーティングを適用できるだけです。
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.
LCPにCESアーキテクチャを採用するよう説得するために、キャッシュおよびマッピングルックアップ遅延リスクを軽減するメカニズムを提供する必要があります。1つの方法は、CESアーキテクチャをエッジにプッシュすることです。新しい機能を追加するエッジに近いほど、ITスケーリングが向上します。つまり、エンドポイントスタックがアップグレードされた場合、キャッシュメカニズムはエンドポイント自体によって維持されます。CESソリューションがエンドポイントに統合されている場合、CESアーキテクチャのアドレス指定スキームがHIPV4のアドレス指定スキームに置き換えられる場合、マッピングメカニズムを削除できます。このアプローチにより、LCPSはサイトの前に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）がグローバルに一意ではなくなってはならないことを提案しています。移行が完了すると、より地域の割り当てを展開できます。しかし、これは、HIPV4フレームワークをサポートするためにすべてのエンドポイント（他のALOCレルムへのセッションを確立している）が移行した後にのみ可能です。ここで、CESアーキテクチャはIPv4アドレスの再利用をスピードアップできます。つまり、IPv4アドレスブロックがELOCブロックになると、他のRIR領域で再利用できます。インターネット内のすべてのエンドポイントを最初にアップグレードする必要はありません。
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アーキテクチャは、DFZからPi-Addressesを除去することを目的としており、コンテンツサイトを多かれ少なかれCESソリューションのロールアウトの主要なターゲットにします。大規模なコンテンツサイトでは、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-AddressエントリはDFZから削除されました。おそらく、HIPV4スタックをサポートするために消費者サイトのいくつかのエンドポイントがアップグレードされている可能性があります。特に、LCPSのサービスレベルに影響を与えたキャッシュやマッピング遅延に問題がある場合。次に、問題は、コンテンツサイトのアップグレードを追跡する方法です。コンテンツサイトまたはコンテンツエンドポイントが移行されている場合、DNSレコードには、各AレコードのCESノードエントリまたはALOCエントリが必要です。コンテンツサイトでのCESソリューションの侵入（DNSのCES-Node/ALOCレコードが続く）が十分に高い場合、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アドレスの枯渇は、サービスプロバイダーのネットワークでより多くのNATを引き起こします（ネットワークがより複雑になるため、運用支出が増加します）またはISPは顧客にIPv6に移行するように強制する必要があります。しかし、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からのALOCプレフィックスのみを備えた、より独立したルーティングドメイン（ALOCレルム）と、直接添付の顧客からのELOCプレフィックスを備えています。他の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.
レガシーエンドポイントがリモートエンドポイントのDNSエントリ（HIPV4アップグレードエンドポイント）を解決すると、DNS応答でALOCレコードを受信します。レガシーエンドポイントは、ALOCレコードを無視します。A-Recordのみがセッションを確立するために使用されます。次に、レガシーエンドポイントがセッションを初期化し、パケットがマップとカプセルのイングレスノードに送信されます。これは、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ヘッダースキームが使用され、A /32エントリがキャッシュに作成されます。A /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. Locator Headerを作成し、IPヘッダーの宛先アドレスフィールドの値をロケーターヘッダーのELOCフィールドにコピーします。
c. Replace the destination address in the IP header with the ALOC prefix given in the cache.
c. IPヘッダーの宛先アドレスを、キャッシュに与えられたALOCプレフィックスに置き換えます。
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.
e. 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.
g. ロケーターヘッダーのFIビットを00に設定します。
h. Decrease the TTL value by one.
h. TTL値を1つ減らします。
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.
i. 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. コンシューマ/コンテンツサイトの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ノードレコードのいずれかを受信します。要求するHIPV4エンドポイントの観点から、新しいレコードプレフィックスがインターネット内のRBRノードまたはCESノードを見つけるために使用されるかどうかは本当に問題ではありません。CESノードは、リモートレガシーエンドポイント。したがって、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. IPヘッダーの宛先アドレスを、ロケーターヘッダーのELOCプレフィックスに置き換えます。
e. Remove the locator header.
e. ロケーターヘッダーを取り外します。
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. パケットを返すためのキャッシュエントリ（すでに存在しない限り）を作成します。A /32エントリが必要です。キャッシュエントリの使用を最適化するために、CESノードは、リモートサイトのすべてのエンドポイントがアップグレードされているかどうかをCESマッピングノードに尋ねる場合があります。アップグレードした場合、キャッシュで短いプレフィックスを使用できます。
g. Decrease the TTL value by one.
g. TTL値を1つ減らします。
h. Calculate IP and transport protocol header checksums.
h. IPおよびトランスポートプロトコルヘッダーチェックサムを計算します。
i. Forward the packet according to the destination address of the IP header.
i. 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.
3. 消費者サイトに地域的にユニークなELOCを備えた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.
このユースケースでは、ISPSのマップとカプセルのノードでいくつかのメカニズムが発明され、実装されない限り、セッションは失敗します。古典的な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. コンシューマ/コンテンツサイトのHIPV4対応エンドポイントは、HIPV4対応エンドポイントを備えたコンテンツサイトへのセッションを確立します。
See Section 5.2.
セクション5.2を参照してください。
Author's Address
著者の連絡先
Patrick Frejborg EMail: pfrejborg@gmail.com
Patrick Frejborgメール：pfrejborg@gmail.com