Internet Research Task Force (IRTF) P. Frejborg
Request for Comments: 6306 July 2011
Category: Experimental
ISSN: 2070-1721
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地址空间划分为两个新地址类别的框架：全局唯一的核心地址空间（区域定位器，ALOC）和区域唯一的边缘地址空间（端点定位器，ELOC）。在未来，ELOC空间仅在专用网络或服务提供商领域中具有重要意义。因此，实现了32x32位寻址方案和分层路由结构。分层IPv4框架与当前IPv4 Internet向后兼容。
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）路由研究组一名或多名成员的个人意见。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6306.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6306.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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.
本文档的作者发现LISP方法非常有趣，因为IP地址空间被建议分为两组：路由定位器（RLOC），它们存在于称为默认自由区（DFZ）的Internet全局路由表中，以及端点标识符（EID），仅存在于连接到Internet的边缘网络中。
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中不需要EID前缀，因为边界路由器之间应用了隧道（覆盖）方案。在作者看来，这似乎是一个复杂的体系结构，可以通过应用从类似的过去体系结构中吸取的经验教训加以改进——在90年代，覆盖体系结构很常见，部署在帧中继和ATM技术之上。基于缓存的路由架构也被尝试过，例如Ipsilon的IP交换。这些体系结构在很大程度上被MPLS[RFC3031]所取代，原因有几个——其中之一是覆盖和缓存解决方案在历史上一直存在可伸缩性问题。自90年代以来，科技确实在不断发展。覆盖和缓存解决方案的可伸缩性问题可能与现代硬件和新方法不太相关；请参阅[重新访问路由缓存]
Nevertheless, the author has some doubt whether overlay and caching will scale well, based upon lessons learned from past overlay and caching architectures. The hierarchical IPv4 framework proposal arose from the question of whether the edge and core IP addressing groupings from LISP could be used without creating an overlay solution by borrowing ideas from MPLS to develop a peer-to-peer architecture. That is, instead of tunneling, why not swap IP addresses (hereafter called locators) on a node in the DFZ? By introducing a shim header to the IPv4 header and Realm Border Router (RBR) functionality on the network, the edge locators are no longer needed in the routing table of DFZ.
然而，根据从过去的覆盖和缓存体系结构中吸取的经验教训，作者对覆盖和缓存是否能够很好地扩展表示怀疑。分层IPv4框架提案的提出源于这样一个问题：是否可以使用LISP中的边缘和核心IP寻址分组，而无需通过借鉴MPLS的思想来开发对等体系结构来创建覆盖解决方案。也就是说，为什么不在DFZ中的节点上交换IP地址（以下称为定位器），而不是隧道呢？通过在网络上的IPv4报头和领域边界路由器（RBR）功能中引入垫片报头，DFZ的路由表中不再需要边缘定位器。
Two architectural options existed regarding how to assemble the packet so that RBR functionality can be applied in the DFZ: the packet was assembled by either an ingress network node (similar to LISP or MPLS) or at the endpoint itself. The major drawback in assembling the packet with a shim header at the endpoint is that the endpoint's stack must be upgraded; however, a significant advantage is that the Path MTU Discovery issue, as discussed in, e.g., LISP, would not exist. In addition, the caching scalability issue is mitigated to the greatest extent possible by pushing caching to the endpoint.
关于如何组装数据包以便在DFZ中应用RBR功能，存在两种体系结构选项：数据包由入口网络节点（类似于LISP或MPLS）或端点本身组装。在端点处使用垫片头组装数据包的主要缺点是必须升级端点的堆栈；然而，一个显著的优点是，如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网络中，允许重叠IP地址，因为转发平面正在利用来自MPLS垫片头的标签信息。通过应用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位寻址方案与当前部署的Internet寻址方案向后兼容。
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，与主机标识协议（HIP）的缩写相近[RFC4423]。因此，读者需要注意两个缩写词的使用——hIPv4和HIP，它们代表两种不同的体系结构。
Use of the hIPv4 abbreviation has caused much confusion, but it was chosen for two reasons:
使用hIPv4缩写引起了很多混乱，但选择它有两个原因：
o Hierarchical - to emphasize that a hierarchical addressing scheme is developed. A formalized hierarchy is achieved in the routing architecture. Some literature describes today's Internet as already using hierarchical addressing. The author believes that this claim is not valid -- today's Internet uses one flat address space.
o 分层-强调开发了分层寻址方案。在路由体系结构中实现了形式化的层次结构。一些文献描述今天的互联网已经使用分层寻址。作者认为这种说法是无效的——今天的互联网使用一个平面地址空间。
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）。当前平面地址空间在区域之间的边界路由器处汇总或聚合，以抑制路由表的大小。为了对前缀进行汇总或聚合，地址空间必须在各个区域上保持连续。
Thus, the author concludes that the current method is best described as an aggregating addressing scheme since there are address block dependencies between the areas. Dividing addresses into edge and core locator spaces (a formalized hierarchy) opens up a new dimension -- the edge locator space can still be deployed as an aggregating address scheme on the three types of areas mentioned earlier. In hIPv4, the core locators are combined with edge locators, independent from each other -- the two locator space allocation policies are separated and no dependencies exist between the two addressing schemes in the long-term architecture.
因此，作者得出结论，当前方法最好描述为聚合寻址方案，因为区域之间存在地址块依赖关系。将地址划分为边缘和核心定位器空间（一种形式化的层次结构）打开了一个新的维度——边缘定位器空间仍然可以作为聚合地址方案部署在前面提到的三种类型的区域上。在hIPv4中，核心定位器与边缘定位器相结合，彼此独立——两个定位器空间分配策略是分开的，在长期体系结构中，两个寻址方案之间不存在依赖关系。
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.
实现了一种新的分层寻址方案：描述端点如何连接到本地网络以及端点如何连接到Internet的两级寻址方案。寻址方案中的这一变化将在路由体系结构中启用第四级，称为区域定位器（ALOC）域。
o IPv4 - to emphasize that the framework is still based upon the IPv4 addressing scheme, and is only an evolution from the currently deployed addressing scheme of the Internet.
o IPv4—强调该框架仍然基于IPv4寻址方案，只是从当前部署的Internet寻址方案的演变。
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的缩写可能与HIP混淆。
This document is an individual contribution to the IRTF Routing Research Group (RRG); discussions between those on the mailing list of the group have influenced the framework. The views in this document are considered controversial by the IRTF Routing Research Group (RRG), but the group reached a consensus that the document should still be published. Since consensus was not achieved at RGG regarding which proposal should be preferred -- as stated in
本文件是对IRTF路由研究组（RRG）的个人贡献；工作组邮寄名单上的人之间的讨论影响了该框架。IRTF路由研究小组（RRG）认为本文件中的观点存在争议，但该小组达成共识，认为该文件仍应出版。由于RGG未就应优先考虑哪项提案达成共识，如
[RFC6115]: "The group explored a number of proposed solutions but did not reach consensus on a single best approach" -- thus, all proposals produced within RRG can be considered controversial.
[RFC6115]：“该小组探讨了许多提议的解决方案，但没有就单一的最佳方法达成共识”——因此，RRG内部提出的所有提议都可能被视为有争议的。
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].
本文件中的关键词必须、不得、要求、应、不应、应、不应、建议、可和可选应按照[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.
分配用于在Internet中定位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块仅在地理区域中是唯一的。唯一性的最终政策应由RIR确定。在长期路由架构中，ELOC块不再由RIR分配；它仅在本地ALOC领域中是独一无二的。
ALOC realm:
ALOC领域：
An area in the Internet with at least one attached Realm Border Router (RBR). Also, an ALOC must be assigned to the ALOC realm. The Routing Information Base (RIB) of an ALOC realm holds both local ELOC prefixes and global ALOC prefixes. An ALOC realm exchanges only ALOC prefixes with other ALOC realms.
互联网上至少有一个连接域边界路由器（RBR）的区域。此外，必须将ALOC分配给ALOC领域。ALOC领域的路由信息库（RIB）包含本地ELOC前缀和全局ALOC前缀。ALOC领域仅与其他ALOC领域交换ALOC前缀。
Realm Border Router (RBR):
领域边界路由器（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.
由区域Internet注册表直接分配给用户组织的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.
由区域Internet注册表分配给Internet服务提供商的IPv4地址块，该地址块可聚合为单个路由播发。
Site mobility:
现场流动性：
A site wishing to change its attachment point to the Internet without changing its IP address block.
希望在不更改其IP地址块的情况下更改其Internet连接点的站点。
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.
Internet当前的IP寻址（IPv4）和未来的寻址（IPv6）方案本质上是一维的。这种限制——一维寻址方案——造成了一些障碍，例如，由于NAT中断了端到端的连接，限制了流控制传输协议（SCTP）[RFC4960]的部署，等等，从而阻碍了互联网的进一步发展。
If we compare the Internet's current addressing schemes to other global addressing or location schemes, we notice that the other schemes use several levels in their structures. For example, the postal system uses street address, city, and country to locate a destination. To locate a geographical site, we use longitude and latitude in the cartography system. The other global network, the Public Switched Telephone Network (PSTN), has been built upon a three-level numbering scheme that has enabled a hierarchical
如果我们将Internet当前的寻址方案与其他全局寻址或位置方案进行比较，我们会注意到其他方案在其结构中使用了多个级别。例如，邮政系统使用街道地址、城市和国家来定位目的地。为了定位地理位置，我们在制图系统中使用经度和纬度。另一个全球网络是公共交换电话网（PSTN），它是建立在一个三级编号方案的基础上的，该方案实现了分级管理
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.
信令架构。通过将当前的IPv4寻址方案从单级扩展到两级寻址结构，可以解决[RFC4984]中讨论的大多数问题。此外，分层寻址方案更能描述我们现在所处的互联网。
Looking back, it seems that the architecture of the Internet changed quite radically from the intended architecture with the introduction of [RFC1918], which divides the hosts into three categories and the address space into two categories: globally unique and private address spaces. This idea allowed for further growth of the Internet and extended the life of the IPv4 address space, and it ended up becoming much more successful than expected. RFC 1918 didn't solve the multi-homing requirements for endpoints providing services for Internet users, that is, multi-homed sites with globally unique IP addresses at endpoints to be accessed from the Internet.
回顾过去，随着[RFC1918]的引入，互联网的体系结构似乎与预期的体系结构发生了根本性的变化。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.
RFC1918已经证明，借助于分类地址空间，即全球唯一和私有地址空间，互联网的扩展性更好。RRG提案表明，通过引入核心和边缘定位器，互联网将能够进一步扩展。那么，为什么不更改寻址方案（IPv4和IPv6寻址方案，尽管本文档仅关注IPv4），以更好地反映当前和未来的Internet路由体系结构？如果我们继续使用平面寻址方案，并将其与核心（全局）和边缘（专用）定位器（地址）类别相结合，则路由体系结构将必须支持附加机制，例如NAT、隧道或定位器重写，并借助标识符来克服失配。结果将导致端点的信息丢失或隐藏。使用两级寻址方案，可以删除这些附加机制，并使用核心/边缘定位器创建新的路由和转发指令。
A convenient way to understand the two-level addressing scheme of the hIPv4 framework is to compare it to the PSTN numbering scheme (E.164), which uses country codes, national destination codes, and subscriber numbers. The Area Locator (ALOC) prefix in the hIPv4 addressing scheme can be considered similar to the country code in PSTN; i.e., the ALOC prefix locates an area in the Internet called an ALOC realm. The Endpoint Locator (ELOC) prefixes in hIPv4 can be
理解hIPv4框架的两级寻址方案的一个方便方法是将其与PSTN编号方案（E.164）进行比较，后者使用国家代码、国家目的地代码和用户号码。hIPv4寻址方案中的区域定位器（ALOC）前缀可被视为类似于PSTN中的国家代码；i、 例如，ALOC前缀定位互联网上一个称为ALOC领域的区域。hIPv4中的端点定位器（ELOC）前缀可以是
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.
与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.
中间路由架构向后兼容当前部署的Internet；也就是说，转发平面保持不变，但控制平面需要升级以支持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）内某个区域的定位功能，或Internet中跨越一组ASE的区域的定位功能。一个区域可以分配多个ALOC前缀，例如，用于流量工程目的，例如在该区域的多个入口/出口点之间进行负载平衡。ALOC前缀用于Internet上的路由和转发目的，因此ALOC前缀必须是全局唯一的，并从IPv4地址块分配。这个全局唯一的IPv4地址块称为全局定位块（GLB）。
When an area within an AS (or a group of ASes) is assigned an ALOC prefix, the area has the potential to become an ALOC realm. In order to establish an ALOC realm, more elements, more than just the ALOC prefix, are needed. One or multiple Realm Border Routers (RBRs) must be attached to the ALOC realm. An RBR element is a node capable of swapping the prefixes of the IP header and the new shim header, called the locator header. The swap service is described in detail in Section 5.2, step 3.
当AS（或一组AS）中的某个区域被分配了ALOC前缀时，该区域有可能成为ALOC领域。为了建立ALOC领域，需要更多的元素，而不仅仅是ALOC前缀。一个或多个领域边界路由器（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可能是一个服务器，它有两个连接到路由器的接口，第一个接口配置了ALOC前缀，第二个接口配置了任何IPv4前缀。RBR不使用动态路由协议，因此不需要转发信息库（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功能可以集成到路由器的转发平面中。预计一个RBR将无法处理为ALOC领域指定的所有传入流量，而拥有一个RBR也将在网络中造成潜在的单点故障。因此，多个RBR可能安装在ALOC领域中，RBR应使用ALOC前缀作为其定位器，路由器将ALOC前缀宣布为本地ALOC领域内的选播定位器。ALOC前缀通过BGP机制在整个DFZ中播发。RBR在网络中的位置将影响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]功能的选播集合点，但交换报头既不需要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
ALOC领域尚未完全构建。我们现在可以在Internet上定位ALOC领域，但要定位连接到ALOC领域的端点，需要一个新元素：端点定位器（EndpointLocator，ELOC）。如前一节所述，可以认为ELOC前缀与PSTN中的用户号码相似。ELOC不是新元素，而是对端点上配置的当前IPv4地址的重新定义。之所以使用术语重新定义，是因为当hIPv4框架完全实现时，IPv4地址的全局唯一性不再有效。更具区域性的讲话
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.
可以部署IPv4地址的分配策略，如附录A所述。ELOC前缀将仅用于本地和远程ALOC领域内的路由和转发目的，而不用于中间ALOC领域。
When an initiator is establishing a session to a responder residing outside the local ALOC realm, the value in the destination address field of the IP header of an outgoing packet is no longer the remote destination address (ELOC prefix); instead, the remote ALOC prefix is installed in the destination address field of the IP header. Because the value in the destination address field of the IP header is carrying an ALOC prefix, the intermediate ALOC realms do not need to install the ELOC prefixes of other ALOC realms in their routing tables. It is sufficient for the intermediate ALOC realms to carry only the ALOC prefixes.
当发起方正在建立与驻留在本地ALOC领域之外的响应方的会话时，传出分组的IP报头的目的地地址字段中的值不再是远程目的地地址（ELOC前缀）；相反，远程ALOC前缀安装在IP报头的目标地址字段中。由于IP报头的destination address字段中的值带有ALOC前缀，因此中间ALOC领域不需要在其路由表中安装其他ALOC领域的ELOC前缀。中间ALOC域只携带ALOC前缀就足够了。
The outcome is that the routing tables at each ALOC realm will be reduced when the hIPV4 framework is fully implemented. The ALOC prefixes are still globally unique and must be installed in the DFZ. Thus, the service provider cannot control the growth of the ALOC prefixes, but she/he can control the amount of local ELOC prefixes in her/his local ALOC realm.
结果是，当hIPV4框架完全实现时，每个ALOC领域的路由表都将减少。ALOC前缀仍然是全局唯一的，必须安装在DFZ中。因此，服务提供商无法控制ALOC前缀的增长，但她/他可以控制她/他的本地ALOC领域中本地ELOC前缀的数量。
When the hIPv4 packet arrives at the remote ALOC realm, it is forwarded to the nearest RBR, since the value in the destination address field of the IP header is the remote ALOC prefix. When the RBR has swapped the hIPv4 header, the value in the destination address field of the IP header is the remote ELOC; thus, the hIPv4 packet will be forwarded to the final destination at the remote ALOC realm. An endpoint using an ELOC prefix can be attached simultaneously to two different ALOC realms without the requirement to deploy a classical multi-homing solution; for details, see Section 12 and Appendix B.
当hIPv4数据包到达远程ALOC领域时，它被转发到最近的RBR，因为IP报头的destination address字段中的值是远程ALOC前缀。当RBR交换hIPv4报头时，IP报头的目的地址字段中的值为远程ELOC；因此，hIPv4数据包将被转发到远程ALOC领域的最终目的地。使用ELOC前缀的端点可以同时连接到两个不同的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.
认识到寻址结构不再是一维的，并且添加了第二级层次结构，因此解决在Internet上定位远程ELOC（端点）和远程ALOC领域的问题以及确定在何处组装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.
更好的解决方案是在端点处扩展当前IPv4堆栈，以便在端点的堆栈处合并ALOC和ELOC元素；但是，必须保持向后兼容性。当hIPv4框架完全实现时，大多数应用程序不会意识到扩展，而其他IP意识应用程序，如移动IP、SIP、IPsec AH等（见第10.3节）将受到影响，并且不能在其ALOC领域之外使用，除非升级。原因是IP感知应用程序依赖于底层网络寻址结构，例如，识别端点。
Note that the applications used inside the local ALOC realm (e.g., enterprise's private network) do not need to be upgraded -- neither in the intermediate nor in the long-term routing architecture. The classical IPv4 framework is preserved in that only IP-aware applications used between ALOC realms need to be upgraded to support the hIPv4 header.
请注意，本地ALOC领域（例如，企业的专用网络）中使用的应用程序不需要升级——无论是在中间还是在长期路由架构中。经典的IPv4框架被保留下来，因为只有ALOC领域之间使用的IP感知应用程序需要升级以支持hIPv4报头。
Figure 1 shows a conceptual overview of the intermediate routing architecture. When this architecture is in place, the ELOC space is no longer globally unique. Instead, a regional allocation policy can be implemented. For further details, see Appendix A. The transition from the current routing architecture to the intermediate routing architecture is discussed in Appendix D.
图1显示了中间路由体系结构的概念概述。当此体系结构就位时，ELOC空间不再是全局唯一的。相反，可以实施区域分配政策。有关更多详细信息，请参见附录A。附录D讨论了从当前路由体系结构到中间路由体系结构的过渡。
Legend: *attachment point in the ALOC realm UER=Unique ELOC region EP=Endpoint
图例：*ALOC领域中的连接点UER=唯一ELOC区域EP=端点
|-------------------------------------------------------------|
| UER1 | | UER2 |
|-------------------------------------------------------------|
| Enterprise1 | ISP1 | ISP | ISP2 | Enterprise2 |
| ALOC Realm | ALOC Realm | Tier1 | ALOC Realm | ALOC Realm |
| | | | | |
| *EP | *RBR | | *RBR | *EP |
| ELOC1 | ALOC1 | | ALOC2 | ELOC4 |
| | | | | |
| | *EP | | *EP | |
| | ELOC2 | | ELOC3 | |
| | | | | |
|-------------|xxxxxxxxxxxxxx DFZ xxxxxxxxxxxxxx| ------------|
| RIB | RIB | RIB | RIB | RIB |
| | | | | |
| ALOC1 | ALOC1 | ALOC1 | ALOC2 | ALOC2 |
| ELOC1 | ALOC2 | ALOC2 | ALOC1 | ELOC4 |
| | ELOC2 | | ELOC3 | |
| | ELOC1 | | ELOC4 | |
| | | | | |
|-------------------------------------------------------------|
|-------------------------------------------------------------|
| 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.
本节提供了两个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前缀，则无需出于路由目的使用hIPv4头，因为发起方和响应方都位于本地ALOC域中。数据包根据IP报头中的前缀进行路由，因为数据包不会退出本地ALOC领域。当本地ALOC前缀与远程ALOC前缀不匹配时，必须组装hIPv4头，因为数据包需要路由到远程ALOC域。
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领域内两个端点之间的会话可能会使用定位器头——不是为了路由目的，而是为了利用Valiant负载平衡[VLB]实现支持多路径的传输协议（参见第11.1节）或利用标识符/定位器拆分方案（参见第7节）。当使用VLB时，发起方将定位器报头添加到分组中，并通过将VLB位设置为01或11，向响应方和中间路由器指示请求VLB用于子流。因为这是一个ALOC域内会话，所以不需要向定位器头添加ALOC和ELOC字段，因此定位器头的大小将为4字节。
If an identifier/locator split scheme is applied for the session (intra-ALOC or inter-ALOC), the initiator must set the I-bit to 1 and make use of the Locator Header Length field. Identifier/locator split scheme information is inserted into the locator header after the Locator Header Length field.
如果为会话（ALOC内或ALOC间）应用了标识符/定位器拆分方案，则发起方必须将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堆栈注意到本地和远程ALOC不匹配，因此必须为会话使用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. hIPv4数据包根据IP报头的目标地址字段中的值在整个互联网上路由。
3. The hIPv4 packet will reach the closest RBR of the remote ALOC realm. When the RBR notices that the value in the destination address of the IP header matches the local ALOC prefix, the RBR must:
3. hIPv4数据包将到达远程ALOC领域最近的RBR。当RBR注意到IP报头的目标地址中的值与本地ALOC前缀匹配时，RBR必须：
a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
a. 验证接收到的数据包是否使用IP报头协议字段中的hIPv4协议值。
b. Verify IP, locator, and transport protocol header checksums. The transport protocol header verification does not include the locator header fields.
b. 验证IP、定位器和传输协议标头校验和。传输协议标头验证不包括定位器标头字段。
c. Replace the source address in the IP header with the ALOC prefix of the locator header.
c. 用定位器标头的ALOC前缀替换IP标头中的源地址。
d. Replace the destination address in the IP header with the ELOC prefix of the locator header.
d. 用定位器标头的ELOC前缀替换IP标头中的目标地址。
e. Replace the ALOC prefix in the locator header with the destination address of the IP header.
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）值减少一。
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报头的destination address字段中的新值在远程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. 响应程序的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. 定位器头的ELOC前缀作为远程IP地址。
The responder's application will respond to the initiator and the returning packet will take almost the same steps, which are steps 1 to 6, as when the initiator started the session. In step 1, the responder does not need to do a DNS lookup since all information is provided by the packet.
响应程序的应用程序将响应发起程序，返回的数据包将采取与发起程序启动会话时几乎相同的步骤，即步骤1到6。在步骤1中，响应者不需要进行DNS查找，因为所有信息都由数据包提供。
The long-term routing architecture is established once the forwarding planes of private ALOC realms or service providers ALOC realms containing subscribers are upgraded. The forwarding planes of transit DFZ routers do not need to be upgraded. Why then would private network or service provider administrators upgrade their infrastructure? There are two incentives:
一旦包含用户的私有ALOC领域或服务提供商ALOC领域的转发平面升级，则建立长期路由架构。transit DFZ路由器的转发平面不需要升级。那么，为什么专用网络或服务提供商管理员要升级其基础设施？有两种激励措施：
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框架的平稳过渡；通过引入交换服务，避免了当前转发平面的重大升级。将来，如果愿意，交换服务可以在ALOC领域保持“原样”，或者当路由器在其自然生命周期过程中升级时，交换服务可以推向ALOC领域的边缘。
Once an upgrade of a router is required because of, for example, increased demand for bandwidth, the modified forwarding plane might concurrently support IPv4 and hIPv4 forwarding -- and the swap service can be pushed towards the edge and in the future removed at the ALOC realm. This is accomplished by adding an extension to the current routing protocols, both IGP and BGP. When an RBR receives a hIPv4 packet where the value of the destination address field in the IP header matches the local ALOC prefix, the RBR will -- contrary to the tasks defined in Section 5.2, step 3 -- look up the ELOC field in the locator header and compare this prefix against the FIB. If the next-hop entry is RBR-capable, the packet will be forwarded according to the ELOC prefix. If the next-hop is a classical IPv4 router, the RBR must apply the tasks defined in Section 5.2, step 3 and, once completed, forward the packet according to the new value in the destination address field of the IP header.
例如，由于带宽需求增加而需要升级路由器时，修改后的转发平面可能同时支持IPv4和hIPv4转发，交换服务可以推向边缘，将来在ALOC领域中删除。这是通过向当前路由协议（IGP和BGP）添加扩展来实现的。当RBR接收到IP报头中目标地址字段的值与本地ALOC前缀匹配的hIPv4数据包时，RBR将——与第5.2节步骤3中定义的任务相反——查找定位器报头中的ELOC字段，并将该前缀与FIB进行比较。如果下一跳条目支持RBR，则将根据ELOC前缀转发数据包。如果下一个跃点是典型的IPv4路由器，RBR必须应用第5.2节步骤3中定义的任务，完成后，根据IP报头的目标地址字段中的新值转发数据包。
When all endpoints (that need to establish sessions outside the local ALOC realm) and infrastructure nodes in an ALOC realm are hIPv4- capable, there is no need to apply swap service for unicast sessions. Forwarding decisions can be based on information in the IP and locator headers. In the local ALOC realm, packets are routed to their upstream anycast or unicast ALOC RBR according to the ALOC prefix in the locator header; local ALOC exit routing is applied against the local ALOC FIB. Remote ELOC approach routing is applied against the ELOC FIB in the remote ALOC realm.
当ALOC领域中的所有端点（需要在本地ALOC领域之外建立会话）和基础结构节点都支持hIPv4时，就不需要为单播会话应用交换服务。转发决策可以基于IP和定位器头中的信息。在本地ALOC领域中，根据定位器报头中的ALOC前缀将分组路由到其上游选播或单播ALOC RBR；本地ALOC出口路由针对本地ALOC FIB应用。远程ELOC方法路由是针对远程ALOC领域中的ELOC FIB应用的。
Note that IP and transport protocol headers will remain intact (except for TTL values, since the RBR is a router); only FI and LH checksum values in the locator header will alternate in local ALOC exit routing mode and remote ELOC approach routing mode.
注意，IP和传输协议头将保持不变（TTL值除外，因为RBR是路由器）；在本地ALOC出口路由模式和远程ELOC进近路由模式下，只有定位器标头中的FI和LH校验和值会交替。
Figure 2 shows a conceptual overview of the long-term hIPv4 routing architecture.
图2显示了长期hIPv4路由体系结构的概念概述。
Legend: *attachment point in the ALOC realm UER=Unique ELOC region EP=Endpoint aRBR=anycast RBR uRBR=unicast RBR
图例：*ALOC领域中的连接点UER=唯一ELOC区域EP=端点aRBR=选播RBR uRBR=单播RBR
|-------------------------------------------------------------|
| UER1 | UER2 | | UER3 | UER4 |
|-------------------------------------------------------------|
| Enterprise1 | ISP1 | ISP | ISP2 | Enterprise2 |
| ALOC Realm | ALOC Realm | Tier1 | ALOC Realm | ALOC Realm |
| | | | | |
| *EP | *aRBR | | *aRBR | *EP |
| ELOC1 | ALOC1.1 | | ALOC2.1 | ELOC4 |
| | | | | |
| *uRBR | | uRBR* |
| |ALOC1.2 | | ALOC2.2| |
| | | | | |
| | *EP | | *EP | |
| | ELOC2 | | ELOC3 | |
| | | | | |
|-------------|xxxxxxxxxxxxxx DFZ xxxxxxxxxxxxxx|-------------|
| RIB | RIB | RIB | RIB | RIB |
| | | | | |
| ALOC1.2 | ALOC1.1 | ALOC1 | ALOC2.1 | ALOC2.2 |
| ELOC1 | ALOC1.2 | ALOC2 | ALOC2.2 | ELOC4 |
| | ALOC2 | | ALOC1 | |
| | ELOC2 | | ELOC3 | |
| | | | | |
|-------------------------------------------------------------|
|-------------------------------------------------------------|
| UER1 | UER2 | | UER3 | UER4 |
|-------------------------------------------------------------|
| Enterprise1 | ISP1 | ISP | ISP2 | Enterprise2 |
| ALOC Realm | ALOC Realm | Tier1 | ALOC Realm | ALOC Realm |
| | | | | |
| *EP | *aRBR | | *aRBR | *EP |
| ELOC1 | ALOC1.1 | | ALOC2.1 | ELOC4 |
| | | | | |
| *uRBR | | uRBR* |
| |ALOC1.2 | | ALOC2.2| |
| | | | | |
| | *EP | | *EP | |
| | ELOC2 | | ELOC3 | |
| | | | | |
|-------------|xxxxxxxxxxxxxx DFZ xxxxxxxxxxxxxx|-------------|
| RIB | RIB | RIB | RIB | RIB |
| | | | | |
| ALOC1.2 | ALOC1.1 | ALOC1 | ALOC2.1 | ALOC2.2 |
| ELOC1 | ALOC1.2 | ALOC2 | ALOC2.2 | ELOC4 |
| | ALOC2 | | ALOC1 | |
| | ELOC2 | | ELOC3 | |
| | | | | |
|-------------------------------------------------------------|
Figure 2: Long-term routing architecture of hIPv4
图2:hIPv4的长期路由架构
Also, the swap service for multicast can be removed when the forwarding planes are upgraded in all consequent ALOC realms. The source's ALOC RBR sets the FI-bits to 11, and a Reverse Path Forwarding (RPF) check is hereafter applied against the ALOC prefix in the locator header. Here, IP and transport protocol headers will not alternate.
此外，当在所有后续ALOC领域中升级转发平面时，可以删除多播的交换服务。源的ALOC RBR将FI位设置为11，并且随后针对定位器报头中的ALOC前缀应用反向路径转发（RPF）检查。在这里，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
长期发展将提供32x32位定位器空间。ALOC前缀仅分配给服务提供商；ELOC前缀仅在本地ALOC领域有效。企业可以为其专用网络使用32位定位器空间（ALOC前缀为
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).
从连接的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.
本节提供了两个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.
本地ALOC领域的转发平面升级后，必须通知端点；也就是说，需要对DHCP进行扩展，或者手动配置端点以通知本地ALOC领域完全符合hIPv4。
How a hIPV4 session is established follows:
hIPV4会话的建立方式如下：
1. The initiator queries the DNS server. The hIPv4 stack notices that the local and remote ALOCs do not match and therefore must use the hIPv4 header for the session. The hIPv4 stack of the initiator must assemble the packet as described in Section 5.2, step 1, except for the following:
1. 启动器查询DNS服务器。hIPv4堆栈注意到本地和远程ALOC不匹配，因此必须为会话使用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. 根据定位器报头的ALOC前缀，hIPv4分组在本地ALOC域中路由；采用本地ALOC出口路由。
3. The hIPv4 packet will reach the closest RBR of the local ALOC realm. When the RBR notices that the packet's ALOC prefix of the locator header matches the local ALOC prefix and the FI-bits are set to 01, the RBR must:
3. hIPv4数据包将到达本地ALOC领域最近的RBR。当RBR注意到定位器报头的数据包的ALOC前缀与本地ALOC前缀匹配并且FI位设置为01时，RBR必须：
a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
a. 验证接收到的数据包是否使用IP报头协议字段中的hIPv4协议值。
b. Verify the IP and locator header checksums.
b. 验证IP和定位器标头校验和。
c. Set the FI-bits of the locator header to 00.
c. 将定位器标题的FI位设置为00。
d. Decrease the TTL value by one.
d. 将TTL值减小一。
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. 如第5.2节步骤2至6所述，将hIPv4数据包路由至响应程序。采用DFZ路由。
5. The responder's application responds to the initiator and the returning packet takes almost the same steps as described in Section 5.2 except for:
5. 响应方的应用程序响应发起方，返回的数据包采取与第5.2节所述几乎相同的步骤，除了：
6. The hIPv4 packet will reach the closest RBR of the initiator's ALOC realm. When the RBR notices that the value in the destination address field of the IP header matches the local ALOC prefix and the FI-bits are set to 00, the RBR must:
6. hIPv4数据包将到达发起方ALOC领域最近的RBR。当RBR注意到IP报头的destination address字段中的值与本地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值减小一。
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. 响应程序的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. 定位器标头的ELOC前缀作为本地IP地址。
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]中说明了将位置与标识分离的设计指南和基本原理。另一个重要的影响来源是[Dagstuhl]研讨会的报告和演示，该报告和演示宣称“未来的互联网体系结构必须将IP地址作为名称、定位器和转发指令的功能解耦，以促进互联网的增长和新的网络拓扑动态”。
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].
然而，应用标识符/定位器拆分有多种方法，如Sigcomm 2008年MobiArch研讨会的[ID/loc_split]演示中所述。因此，hIPv4框架不会提出或定义单一标识符/定位器拆分解决方案；可以通过例如多路径传输协议或标识符/定位器数据库方案（例如HIP）来实现分割。定位器标题中添加了占位符，因此标识符/定位器拆分方案可以集成到hIPv4框架中。但标识符/定位器分离方案可能会造成隐私不便，如[Mobility_uu&u privacy]中所述。
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框架启用标识符/定位器拆分的最有趣的候选协议。从hIPv4的角度来看，MPTCP特别有趣；MPTCP的主要目标之一是提供与当前实现的向后兼容性：hIPv4具有相同的目标。
MPTCP itself does not provide an identifier/locator database scheme as HIP does. Instead, MPTCP is proposing a token -- with local meaning -- to manage and bundle subflows under one session between two endpoints. The token can be considered to have the characteristics of a session identifier, providing a generic cookie mechanism for the application layer and creating a session layer between the application and transport layers. Thus, the use of a session identifier will provide a mechanism to improve mobility, both in site and endpoint mobility scenarios.
MPTCP本身不像HIP那样提供标识符/定位器数据库方案。相反，MPTCP提出了一个具有本地含义的令牌，用于在两个端点之间的一个会话下管理和捆绑子流。令牌可以被认为具有会话标识符的特征，为应用层提供通用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
既然会话标识符提高了站点和端点的移动性，路由可伸缩性通过引入分层寻址方案而得到改善，那么为什么还要在hIPv4框架中添加标识符/定位器数据库方案呢？引入标识符/定位器数据库
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.
如HIP、标识符/定位器网络协议[ILNP]和基于名称的套接字[NBS]中所述，该方案可能会缓解或消除防火墙上用于确定安全区域范围的定位器重新编号依赖项，但这种方法将从根本上改变当前部署的安全体系结构。
However, combining an identifier/locator database scheme with DNS Security (DNSSEC) [RFC4033] is interesting. Today, security zones are scoped by using locator prefixes in the security rule sets. Instead, a Fully Qualified Domain Name (FQDN) could be used in the rule sets and the renumbering of locator prefixes would no longer depend upon the security rule sets in firewalls. Another interesting aspect is that an FQDN is and needs to be globally unique. The ALOC prefix must be globally unique, but ELOC prefixes are only regionally unique and in the long-term only locally unique. Nevertheless, combining identifier/locator database schemes with security architectures and DNSSEC needs further study.
然而，将标识符/定位器数据库方案与DNS安全性（DNSSEC）[RFC4033]相结合是有趣的。如今，安全区域的范围是通过在安全规则集中使用定位器前缀来确定的。相反，可以在规则集中使用完全限定域名（FQDN），定位器前缀的重新编号将不再依赖于防火墙中的安全规则集。另一个有趣的方面是FQDN是并且需要是全局唯一的。ALOC前缀必须是全局唯一的，但ELOC前缀仅在区域上唯一，长期而言仅在局部唯一。然而，将标识符/定位器数据库方案与安全体系结构和DNSSEC相结合需要进一步研究。
In order to provide multi-homing and mobility capabilities for single path transport protocols such as TCP and UDP, an identifier/locator database scheme is needed. This scheme can also be used to create a bidirectional NAT traversal solution with a locator translation map consisting of private locator prefixes and public identifiers at the border router.
为了为单路径传输协议（如TCP和UDP）提供多归属和移动能力，需要一个标识符/定位器数据库方案。该方案还可用于创建双向NAT穿越解决方案，该解决方案在边界路由器处具有由私有定位器前缀和公共标识符组成的定位器转换映射。
The hIPv4 routing architecture provides only location information for the endpoints; that is, the ELOC describes how the endpoint is attached to the local network, and the ALOC prefixes describe how the endpoint is attached to the Internet. Identifier/locator split schemes are decoupled from the routing architecture -- the application layer may or may not make use of an identifier/locator split scheme.
hIPv4路由体系结构仅提供端点的位置信息；也就是说，ELOC描述端点如何连接到本地网络，ALOC前缀描述端点如何连接到Internet。标识符/定位器拆分方案与路由体系结构分离——应用层可以使用标识符/定位器拆分方案，也可以不使用标识符/定位器拆分方案。
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描述了As。当ALOC描述一个区域时，它在下文中称为选播ALOC。
The ALOC can also be used to describe a specific node between two ALOC realms, e.g., a node installed between a private and an ISP ALOC realm, or between two private ALOC realms. In this use case the ALOC describes an attachment point, e.g., where a private network is attached to the Internet. This ALOC type is hereafter called a unicast ALOC.
ALOC还可用于描述两个ALOC领域之间的特定节点，例如，安装在私有和ISP ALOC领域之间的节点，或安装在两个私有ALOC领域之间的节点。在这个用例中，ALOC描述了一个连接点，例如，专用网络连接到互联网的地方。这种ALOC类型在下文中称为单播ALOC。
The main difference between anycast and unicast ALOC types is:
选播和单播ALOC类型之间的主要区别是：
o In an anycast ALOC scenario, ELOC routing information is shared between the attached ALOC realms.
o 在选播ALOC场景中，ELOC路由信息在连接的ALOC领域之间共享。
o In a unicast ALOC scenario, no ELOC routing information is shared between the attached ALOC realms.
o 在单播ALOC场景中，连接的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空间。专用ALOC使用[RFC1918]中定义的相同定位器空间；专用ALOC在专用网络中必须是唯一的，并且不能与专用ELOC前缀重叠。只允许ISP申请全局ALOC前缀。有关进一步讨论，请参见附录A。ISP应尽可能聚合全局ALOC前缀，以减少DFZ中路由表的大小。
When a user logs on to the enterprise's network, the endpoint will receive the following locator prefixes via provisioning means (e.g., DHCP or manually configured):
当用户登录到企业网络时，端点将通过设置方式（例如，DHCP或手动配置）接收以下定位器前缀：
o One ELOC prefix for each network interface.
o 每个网络接口一个ELOC前缀。
o One private ALOC prefix due to
o 一个私有ALOC前缀由于
- 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 一个或多个全局ALOC前缀。这些ALOC描述了企业网络如何连接到Internet。
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
当用户建立到远程端点的会话时，DNS通常用于解析远程定位器前缀。DNS将返回远程端点的ELOC和ALOC前缀。如果没有返回ALOC前缀，则会向远程主机启动经典IPv4会话
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).
终点。返回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空间，则发起方将为会话使用给定的专用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功能的网络。远程端点距离较远，利用高速长距离连接，为了提高会话性能，应使用多路径传输协议。
The other use case is when the remote endpoint resides in a network that recently has been merged and private ELOC [RFC1918] spaces overlap if no renumbering is applied. One or several unicast ALOC solutions are needed in the network between the initiator and responder. For long-distance sessions with no overlapping ELOC prefixes, anycast or unicast ALOC solutions can be deployed.
另一个用例是远程端点位于最近已合并的网络中，如果未应用重新编号，则私有ELOC[RFC1918]空间重叠。在发起方和响应方之间的网络中需要一个或多个单播ALOC解决方案。对于没有重叠ELOC前缀的远程会话，可以部署任意广播或单播ALOC解决方案。
A third use case follows; again the initiator compares returned ALOC prefixes from DNS with its own local ALOC prefixes:
第三个用例如下；发起方再次将从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前缀指示远程网络如何连接到Internet。当使用多路径传输协议时，子流可以通过单独的边界路由器路由到远程端点——如果本地和远程站点都是多址的，则可以在本地和远程站点上路由。本地ALOC领域中的启动器的出口分组可以通过IP报头中的协议值来识别，并基于定位器报头中的ALOC前缀路由到显式路径（例如，MPLS LSP、L2TPv3隧道等）。可以设计本地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连接和Internet（在中间路由体系结构中）具有多路径会话。
Legend: *attachment point in the ALOC realm UER=Unique ELOC region EP=Endpoint aRBR=anycast RBR uRBR=unicast RBR BR=Border Router
图例：*ALOC领域中的连接点UER=唯一ELOC区域EP=端点aRBR=任意广播RBR uRBR=单播RBR BR=边界路由器
|-------------------------------------------------------------|
| UER1 | | UER2 |
|-----------------------------------------------|-------------|
| Enterprise1 | | Enterprise2 |
| ALOC Realm | | ALOC Realm |
| |---------------------------------| |
| | VPN | |
| | ALOC Realm | |
| *uRBR3 uRBR4* |
| |ALOC3 ALOC4| |
| |xxxxxxxxxxxX VPN RIB xxxxxxxxxxxx| |
| | | |
| | ALOC3 & ALOC4 | |
| |---------------------------------| |
| *EP1 | | *EP2 |
| ELOC1 |---------------------------------| ELOC2 |
| | ISP1 | ISP | ISP2 | |
| | ALOC Realm | Tier1 | ALOC Realm | |
| | | | | |
| BR1* *aRBR | | *aRBR *BR2 |
| | ALOC1 | | ALOC2 | |
| | | | | |
|-------------|xxxxxxxxxxxxxx DFZ xxxxxxxxxxxxxx|-------------|
| RIB | RIB | RIB | RIB | RIB |
| | | | | |
| ALOC1 | ALOC1 | ALOC1 | ALOC2 | ALOC2 |
| ALOC3 | ALOC2 | ALOC2 | ALOC1 | ALOC4 |
| ALOC4 | ELOC1 | | ELOC2 | ALOC3 |
| ELOC1 | | | | ELOC2 |
| | | | | |
|-------------------------------------------------------------|
|-------------------------------------------------------------|
| 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和Internet的多路径
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.
第一子流从发起方（EP1）经由uRBR3和uRBR4（两者都使用专用单播ALOC前缀）建立到响应方（EP2）。采用普通单播转发；uRBR3和uRBR4的ALOC前缀安装在本地和远程ALOC领域的路由表中。第二个子流通过互联网建立，即通过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.
第四个用例是利用私有和全局ALOC功能，以与[Split DNS]解决方案的设计和实施保持一致。
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.
第五个用例是针对住宅用户的。住宅用户可以使用一个或多个ALOC前缀，具体取决于ISP的服务提供和网络设计。如果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分配一个或多个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的肋中。当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领域必须有一个或多个RBR连接到它。ALOC前缀配置为RBR上的选播IP地址。选播IP地址安装到适当的路由协议，以便分发到DFZ。
6. The IPv4 socket API at endpoints must be extended to support local and remote ALOC prefixes. The modified IPv4 socket API must be backwards compatible with the current IPv4 socket API. The outgoing hIPv4 packet must be assembled by the hIPv4 stack with
6. 端点处的IPv4套接字API必须扩展以支持本地和远程ALOC前缀。修改后的IPv4套接字API必须与当前IPv4套接字API向后兼容。传出hIPv4数据包必须由hIPv4堆栈使用
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.
套接字中的本地IP地址作为源地址，远程ALOC前缀作为IP头中的目标地址。本地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充当Internet的“电话簿”，很明显，DNS需要一种新的资源记录（RR）类型来服务升级为支持hIPv4的端点。未来的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 在类型字段中分配一个新的整数（QTYPE），由IANA分配。
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 Preference子字段：一个16位整数，指定与FQDN相关联的其他RR的首选项。较低的值优先于较高的值。
o ALOC subfield: A 32-bit integer that specifies the Area Locator of the associated FQDN.
o ALOC子字段：指定关联FQDN的区域定位器的32位整数。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Preference |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| ALOC |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Preference |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| ALOC |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 4: RDATA format of the ALOC RR
图4:ALOC RR的RDATA格式
Only endpoints that have been upgraded to support hIPv4 shall make use of the new ALOC RR. Also, there is no need to define a new ELOC RR because the A RR is used for that purpose when the ALOC RR is returned.
只有升级为支持hIPv4的端点才能使用新的ALOC RR。此外，不需要定义新的ELOC RR，因为在返回ALOC RR时，a 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
国际人道主义法：4位
The Internet Header Length field is identical to that of RFC 791.
Internet标头长度字段与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领域位，A位：1位
When the initiator and responder reside in different ALOC realms, the A-bit is set to 1 and the Area and Endpoint Locator fields must be used in the locator header. The size of the locator header is 12 bytes. When the A-bit is set to 0, the initiator and responder reside within the same ALOC realm. The Area and Endpoint Locator shall not be used in the locator header. The size of the locator header is 4 bytes.
当启动器和响应程序位于不同的ALOC域时，A位设置为1，并且必须在定位器头中使用区域和端点定位器字段。定位器标头的大小为12字节。当A位设置为0时，启动器和响应程序位于同一个ALOC域中。区域和端点定位器不得用于定位器标题中。定位器标头的大小为4字节。
Identifier Bit, I-bit: 1 bit
标识符位，I位：1位
The identifier bit is set to 1 if the endpoint is using an identifier/locator split scheme within the locator header. The identifier/locator split scheme must indicate by how much the size of the locator header is increased. The Locator Header Length field is also added to the locator header.
如果端点在定位器头中使用标识符/定位器拆分方案，则标识符位设置为1。标识符/定位器拆分方案必须指明定位器标头的大小增加了多少。定位器标头长度字段也添加到定位器标头。
Swap Bit, S-bit: 1 bit
交换位，S位：1位
The initiator sets the swap bit to 0 in the hIPv4 packet. An RBR will set this bit to 1 when it is swapping the source and destination addresses of the IP header with the ALOC and ELOC prefixes of the locator header.
启动器将hIPv4数据包中的交换位设置为0。当RBR将IP报头的源地址和目标地址与定位器报头的ALOC和ELOC前缀交换时，RBR将该位设置为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）应用于ALOC域间会话。新的转发平面将删除单播和多播会话的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前缀用于将数据包转发给RBR，RBR是本地ALOC前缀的所有者。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路由器应根据IP报头的目的地址字段中的值转发数据包，除非目的地址与本地ALOC前缀匹配。当这种情况发生时，数据包进入远程ALOC领域，远程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进近路由模式。远程ALOC RBR和后续路由器应基于定位器报头中的ELOC前缀转发数据包。
11: Inter-ALOC RPF check mode. The local ALOC RBR changes the FI-bits to 11 and the following inter-ALOC routers on the shared tree shall apply the RPF check against the ALOC prefix in the locator header.
11：ALOC间RPF检查模式。本地ALOC RBR将FI位更改为11，共享树上的以下ALOC路由器应针对定位器报头中的ALOC前缀应用RPF检查。
Valiant Load-Balancing, VLB-bits: 2 bits (optional, subject for further research)
Valiant负载平衡，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:
Valiant负载平衡字段的目的是为支持多路径的传输协议提供一种机制，以请求网络中子流的显式路径，子流是两个端点之间会话的组成部分。子流路径请求可设置如下：
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：第一亚流。可以应用最短路径或Valiant负载平衡。
11: Next subflow(s). Valiant Load-Balancing should be applied
11：下一个子流。应采用Valiant负载平衡
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节点可以为会话应用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.
区域定位器是分配用于在Internet中定位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块仅在地理区域中是唯一的。唯一性的最终政策应由RIR确定。在长期路由架构中，ELOC块不再由RIR分配；它仅在本地ALOC领域中是独一无二的。
Locator Header Length (optional): 16 bits
定位器标头长度（可选）：16位
The Locator Header Length is the total length of the locator header. Locator Header Length is applied when the identifier bit is set to 1. Identifier/locator split scheme parameters are inserted into the locator header after this field.
定位器标头长度是定位器标头的总长度。当标识符位设置为1时，将应用定位器标头长度。标识符/定位器拆分方案参数插入到此字段后的定位器标题中。
Padding (optional): variable
填充（可选）：变量
The locator header padding is used to ensure that the locator header ends on a 32-bit boundary. The padding is zero.
定位器标头填充用于确保定位器标头在32位边界上结束。填充为零。
Because an ELOC prefix is only significant within the local ALOC realm, there is a slight possibility that a session between two endpoints residing in separate ALOC realms might use the same local and remote ELOC prefixes. But the session is still unique because the two processes communicating over the transport protocol form a logical session that is uniquely identifiable by the 5-tuple involved, by the combination of <protocol, local IP address, local port, remote IP address, remote port>.
由于ELOC前缀仅在本地ALOC领域内有效，因此驻留在单独ALOC领域中的两个端点之间的会话可能会使用相同的本地和远程ELOC前缀。但是会话仍然是唯一的，因为通过传输协议进行通信的两个进程形成了一个逻辑会话，该逻辑会话由所涉及的5元组通过<protocol，local IP address，local port，remote IP address，remote port>的组合唯一标识。
The session might no longer be unique when two initiators with the same local ELOC prefix residing in two separate ALOC realms are accessing a responder located in a third ALOC realm. In this scenario, the possibility exists that the initiators will use the same local port value. This situation will cause an "identical session situation" for the application layer.
当驻留在两个单独的ALOC域中具有相同本地ELOC前缀的两个启动器正在访问位于第三个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
为了克服这种情况，hIPv4堆栈必须在ALOC信息的帮助下只接受一个唯一的会话。如果存在“相同的会话情况”，即两个启动器在5元组<协议，本地IP地址，本地端口，远程IP地址，远程端口>中使用相同的值，hIPv4堆栈应只允许第一个
established session to continue. The following sessions must be prohibited and the initiator is informed by ICMP notification about the "identical session situation".
已确定会议将继续举行。必须禁止以下会话，并且ICMP通知发起者“相同会话情况”。
MPTCP introduces a token that is locally significant and currently defined as 32 bits long. The token will provide a sixth tuple for future applications to identify and verify the uniqueness of a session. Thus, the probability to have an "identical session situation" is further reduced. By adding an identifier/locator database scheme to the hIPv4 framework, the "identical session situation" is completely removed.
MPTCP引入了一个本地有效且当前定义为32位长的令牌。令牌将为未来的应用程序提供第六个元组，以识别和验证会话的唯一性。因此，具有“相同会话情况”的概率进一步降低。通过向hIPv4框架中添加标识符/定位器数据库方案，完全消除了“相同的会话情况”。
Adding the locator header to an IPv4 packet in order to create a hIPv4 packet will increase the size of it, but since the packet is assembled at the endpoint it will not add complications of the current Path MTU Discovery (PMTUD) mechanism in the network. The intermediate network between two endpoints will not see any difference in the size of packets; IPv4 and hIPv4 packet sizes are the same from the network point of view.
将定位器头添加到IPv4数据包以创建hIPv4数据包将增加其大小，但由于数据包在端点处组装，因此不会增加网络中当前路径MTU发现（PMTUD）机制的复杂性。两个端点之间的中间网络将看不到数据包大小的任何差异；从网络的角度来看，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地址信息以用作推荐。本节尝试列出需要增强的应用程序；然而，这并不是一份全面的清单。这些申请可分为五大类：
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 启用hIPv4框架所需的应用程序，如DNS和DHCP数据库，必须对其进行扩展以支持ALOC前缀。
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:ResourceReservationProtocol（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运行的应用程序，但许多应用程序使用IP地址，如ping、traceroute、telnet等。CLI语法需要升级，以便通过扩展套接字API支持ALOC和ELOC信息。
At first glance, it seems that a lot of applications need to be re-engineered and ported, but the situation is not all that bad. The applications used inside the local ALOC realm (e.g., an enterprise's private network) do not need to be upgraded, neither in the intermediate nor in the long-term architecture. The classical IPv4 framework is preserved. Only IP-aware applications used between ALOC realms need to be upgraded to support the hIPv4 header. IPv6 has the definitions in place of the applications mentioned above, but the migration of applications from IPv4 to IPv6 can impose some capital expenditures for enterprises, especially if the applications are customized or homegrown; see [Porting_IPv4].
乍一看，许多应用程序似乎需要重新设计和移植，但情况并不那么糟糕。本地ALOC领域内使用的应用程序（例如，企业的专用网络）不需要升级，无论是在中间架构还是在长期架构中。保留了经典的IPv4框架。只有ALOC领域之间使用的IP感知应用程序需要升级以支持hIPv4标头。IPv6具有取代上述应用程序的定义，但将应用程序从IPv4迁移到IPv6可能会给企业带来一些资本支出，特别是如果应用程序是定制的或自主开发的；请参阅[移植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间多播流的本地ALOC前缀。如果本地RBR还充当具有MSDP和PIM功能的选播集合点，则可以实现这一点。通过这些功能，RBR成为支持多播的RBR（mRBR）。源在mRBR上注册，并在源和mRBR之间建立源树。当ALOC域间接收器订阅多播组时，mRBR必须按以下方式交换hIPv4报头：
a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
a. 验证接收到的数据包是否使用IP报头协议字段中的hIPv4协议值。
b. Verify IP, locator, and transport protocol header checksums.
b. 验证IP、定位器和传输协议标头校验和。
c. Replace the source address in the IP header with the local ALOC prefix.
c. 用本地ALOC前缀替换IP头中的源地址。
d. Set the S-field to 1.
d. 将S字段设置为1。
e. Decrease the TTL value by one.
e. 将TTL值减小一。
f. Calculate IP, locator, and transport protocol header checksums. Transport protocol header calculations do not include the locator header fields.
f. 计算IP、定位器和传输协议标头校验和。传输协议标头计算不包括定位器标头字段。
g. Forward the packet to the shared multicast tree.
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头的destination address（目标地址）字段中设置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到接收器的下游路由器将使用IP报头中的源地址（mRBR之后的源ALOC前缀）进行RPF验证。为了让接收器创建实时传输控制协议（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前缀的帮助下完成。例如，敏感流量可以聚合在一个ALOC前缀下，该前缀未完全分布到DFZ中。
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领域（远程站点）的入口负载平衡受站点使用的Internet连接点数量以及连接点在站点上的位置的影响。为了应用本地ALOC出口路由，例如从多宿站点，在发起方和站点的边界路由器之间需要一些新的网络节点。
In the intermediate routing architecture this is achieved by using overlay architectures such as MPLS LSP, L2TPv3 tunnels, etc. The new network node(s) shall be able to identify hIPv4 packets, based on the protocol field in the IP header, and switch the packets to explicit paths based on the ALOC prefix in the locator header. In the long-term routing architecture the overlay solution is replaced with a new forwarding plane; see Section 6.2.
在中间路由架构中，这是通过使用覆盖架构（如MPLS LSP、L2TPv3隧道等）实现的。新网络节点应能够基于IP报头中的协议字段识别hIPv4数据包，并基于定位器报头中的ALOC前缀将数据包切换到显式路径。在长期路由架构中，覆盖解决方案被替换为新的转发平面；见第6.2节。
Together with a multipath transport protocol, the subflows can be routed via specific attachment points, that is, border routers sitting between the private local/remote ALOC realms (multi-homed sites) and the Internet. Multi-homing becomes multi-pathing. For details, see Appendix B.
与多路径传输协议一起，子流可以通过特定的连接点进行路由，即位于私有本地/远程ALOC领域（多主站点）和Internet之间的边界路由器。多归宿变成了多路径。详情见附录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负载平衡[VLB]的主干网新设计方法开辟了可能性。如果两个站点通过单个上行链路连接到Internet，并且端点使用支持多路径的传输协议，并且仅使用一个接口/ELOC前缀连接到网络，则两个子流很可能在整个Internet上采用最短路径。也就是说，两个子流都是在相同的链路上建立的，当链路上出现拥塞或链路故障时，两个子流可能同时丢弃数据包。因此，多路径的好处就失去了。
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负载平衡的主干节点（以下称为vRBR）上，并且主干节点通过逻辑全网状连接互连，则Valiant负载平衡可应用于子流。当子流在定位器报头的VLB字段中设置了适当的位时，第一个入口vRBR应对子流进行VLB切换。也就是说，如果VLB位设置为01或11，L位设置为0，并且vRBR的本地ALOC前缀与ALOC字段的前缀匹配，则允许入口vRBR对子流的分组进行VLB切换。如果定位器标头中没有ALOC和ELOC字段，但其他字段的值如上所述设置，则vRBR也应为子流应用VLB切换——因为它是属于启用多路径会话的ALOC域内子流。
With this combination of parameters in the locator header, the subflow is VLB switched only at the first ALOC realm and the subflows might be routed throughout the Internet on different paths. If VLB switching is applied at every ALOC realm, this would most likely add too much latency for the subflows. The VLB switching at the first ALOC realm will not separate the subflows on the first and last mile links (site with a single uplink). If the subflows on the first and last mile link need to be routed on separate links, the endpoints should be deployed in a multi-homed environment. Studies on how Valiant Load-Balancing is influencing traffic patterns between interconnected VLB [iVLB] backbone networks have been done. Nevertheless, more studies are needed regarding Valiant Load-Balancing scenarios.
通过定位器报头中的参数组合，子流仅在第一个ALOC领域进行VLB切换，并且子流可能在不同路径上通过互联网路由。如果VLB切换应用于每个ALOC领域，则极有可能为子流增加太多延迟。第一个ALOC领域的VLB切换不会分离第一英里和最后一英里链路（具有单个上行链路的站点）上的子流。如果第一英里和最后一英里链路上的子流需要在单独的链路上路由，则应在多宿环境中部署端点。关于Valiant负载平衡如何影响互连VLB[iVLB]骨干网络之间的流量模式的研究已经完成。然而，关于Valiant负载平衡场景还需要更多的研究。
This section considers two types of mobility solutions: site mobility and endpoint mobility.
本节讨论两种类型的移动性解决方案：站点移动性和端点移动性。
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肋骨生长背后的关键发现之一；参见[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
部署多宿主的原因之一是避免在替换上游ISP时对本地基础设施重新编号。因此，今天，PI地址块被部署在企业中。在中间路由体系结构中，为企业分配一个用于内部路由的区域PI ELOC块（有关详细信息，请参阅附录a）。上游ISP提供一个ALOC前缀
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.
描述企业网络如何连接到Internet。如果企业希望切换到另一个ISP，它只会将端点处的ALOC前缀从以前ISP的ALOC前缀更改为新ISP的ALOC前缀，而不会中断本地网络中的连接，因为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为Internet连接提供其ALOC前缀。附录B详细讨论了多归宿。
Endpoint mobility:
端点移动性：
As said earlier, MPTCP is the most interesting identifier/locator split scheme to solve endpoint mobility scenarios. MPTCP introduces a token, which is locally significant and currently defined as 32 bits long. The token will provide a sixth tuple to identify and verify the uniqueness of a session. This sixth tuple -- the token -- does not depend upon the underlying layer, the IP layer. The session is identified with the help of the token and thus the application is not aware when the locator parameters are changed, e.g., during a roaming situation, but it is required that the application is not making use of ELOC/ALOC information. In multi-homed scenarios, the application can make use of ELOC information, which will not change if the endpoint is fixed to the location.
如前所述，MPTCP是解决端点移动场景的最有趣的标识符/定位器拆分方案。MPTCP引入了一个令牌，该令牌具有本地意义，目前定义为32位长。令牌将提供第六个元组来识别和验证会话的唯一性。第六个元组——令牌——不依赖于底层IP层。借助令牌识别会话，因此应用程序不知道定位器参数何时改变，例如在漫游情况期间，但是要求应用程序不使用ELOC/ALOC信息。在多宿主场景中，应用程序可以使用ELOC信息，如果端点固定到该位置，则不会更改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]来缓解这些攻击。如果应用程序需要针对中间人攻击提供全面保护，则用户应为会话应用传输层安全协议（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.
此外，许多应用程序为其用户提供会合服务，例如SIP、点对点、即时消息服务。通用会合服务解决方案可由标识符/定位器数据库方案提供，例如HIP、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地址信息的应用程序，但Internet中的当前转发平面保持不变，只是创建ALOC域需要一个新的转发元素（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:
什么时候一维寻址结构将被分层寻址方案和添加到路由架构中的第四层取代？作者认为有两个可能的转折点：
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
hIPv4框架无法成功的最大风险和原因是，在IPv4地址空间出现预期耗尽之前，时间非常短——实际上，第一个RIR已经用完了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.
在本文件的IESG审查过程中（2011年4月）发表的讲话。此外，企业是否会放弃对其获得的当前IPv4地址块的全局分配，因为IPv4地址块已成为具有经济价值的资产。
The transition requires the upgrade of endpoint's stack, and this is a drawback compared to the [CES] architectures proposed in [RFC6115]. A transition to an architecture that requires the upgrade of endpoint's stack is considerably slower than an architecture that requires only upgrade of some network nodes. But the transition might not be as slow or challenging at it first seems since hIPv4 is an evolution of the current deployed Internet.
该转换需要对端点的堆栈进行升级，与[RFC6115]中提出的[CES]体系结构相比，这是一个缺点。向需要升级端点堆栈的体系结构的转换要比只需要升级某些网络节点的体系结构慢得多。但这种转变可能并不像最初看起来的那样缓慢或具有挑战性，因为hIPv4是当前部署的互联网的一种演变。
o Not all endpoints need to be upgraded; the endpoints that do not establish sessions to other ALOC realms can continue to make use of the classical IPv4 framework. Also, legacy applications that are used only inside a local ALOC realm do not need to be ported to another framework. For further details, see Appendix C.
o 并非所有端点都需要升级；不建立到其他ALOC领域的会话的端点可以继续使用经典的IPv4框架。此外，仅在本地ALOC领域内使用的遗留应用程序不需要移植到另一个框架。有关更多详细信息，请参见附录C。
o Upgrading endpoint's stack, e.g., at critical or complicated systems, will definitely take time; thus, it would be more convenient to install a middlebox in front of such systems. It is obvious that the hIPv4 framework needs a middlebox solution to speed up the transition; combining CES architectures with the hIPv4 framework might produce such a middlebox. For further details, see Appendix D.
o 升级端点的堆栈（例如，在关键或复杂的系统上）肯定需要时间；因此，在这些系统前面安装一个中间箱会更方便。很明显，hIPv4框架需要一个中间箱解决方案来加快过渡；将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块从全局唯一分配状态释放到区域唯一分配状态之前，并不需要升级Internet中的所有端点。也就是说，为了在中间路由架构中实现本地网络中使用的前缀的ELOC状态，请参见附录D。希望在长期路由架构中实现其ELOC块的本地唯一状态的ALOC域不需要等待其他ALOC域同时进入同一级别。其他ALOC领域已经达到中间路由架构状态就足够了。有关更多详细信息，请参见第6节。
Because the hIPv4 framework does not introduce other network mechanisms than a new type of border router to the currently deployed routing architecture, the best current practices for securing ISP networks are still valid. Since the DFZ will no longer contain ELOC prefixes, there are some benefits and complications regarding security that need to be taken into account.
由于hIPv4框架除了在当前部署的路由体系结构中引入新型边界路由器外，没有引入其他网络机制，因此目前保护ISP网络的最佳实践仍然有效。由于DFZ将不再包含ELOC前缀，因此需要考虑安全方面的一些好处和复杂性。
The hijacking of a single ELOC prefix by longest match from another ALOC realm is no longer possible because the prefixes are separated by a locator, the ALOC. To carry out a hijack of a certain ELOC prefix, the whole ALOC realm must be routed via a bogus ALOC realm. Studies should be done with the Secure Inter-Domain Routing (SIDR) working group to determine whether the ALOC prefixes can be protected from hijacking.
通过另一个ALOC领域的最长匹配劫持单个ELOC前缀已不再可能，因为前缀由定位器ALOC分隔。要劫持某个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）攻击时会产生一些影响。这种影响尤其出现在长期路由架构中，例如，当多宿企业通过单播ALOC RBR连接到ISP时。
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攻击的一种方法是向路由表中注入更具体的前缀（通常为主机前缀），以便“重新定位”攻击的受害者，即在受害者前面创建一个陷穴。天坑可能会将虚假流量与有效流量分开，或分析攻击。长期路由体系结构中的挑战是，当无法在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:
通过借鉴以服务为中心的网络体系结构[SCAFFOLD]的思想，可以创建一个陷穴服务。如何设计分布式天坑服务的示例如下：
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
b. ISP保留用于天坑服务的资源。这些资源使用ALOC前缀Z；这些资源使用服务ID和受害者的X和Y前缀进行编程。ISP将服务ID通知受害者的安全人员。ISP在其RBR和/或支持hIPv4的路由器上应用NAT规则。当IP报头的目标地址与X和定位器报头的ELOC前缀匹配时，NAT规则将数据包的IP报头中的目标地址替换为Z
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.
匹配Y。此外，服务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内部攻击。对于跨越多个ALOC领域的攻击，需要新的方法；上面描述了一个示例。期望启用RBR和hIPv4的路由器能够应用NAT规则并将服务ID插入转发平面中的选定分组。
This document offers a high-level overview of the hierarchical IPv4 framework that could be built in parallel with the current Internet by implementing extensions at several architectures. Implementation of the hIPv4 framework will not require a major service window break in the Internet or at the private networks of enterprises. Basically, the hIPv4 framework is an evolution of the current IPv4 framework.
本文档提供了分层IPv4框架的高级概述，该框架可以通过在多个体系结构上实现扩展与当前Internet并行构建。hIPv4框架的实施不需要在互联网或企业专用网络上出现重大服务窗口中断。基本上，hIPv4框架是当前IPv4框架的演变。
The transition to hIPv4 might be attractive for enterprises since the hIPv4 framework does not create a catch-22 situation, e.g., when should an application used only inside the private network be ported from IPv4 to IPv6? Also, what is the business justification for porting the application to IPv6? Another matter is that when an
向hIPv4的过渡可能对企业具有吸引力，因为hIPv4框架不会造成第二十二条军规的情况，例如，何时应将仅在专用网络内使用的应用程序从IPv4移植到IPv6？另外，将应用程序移植到IPv6的业务理由是什么？另一件事是当
IPv4/v6 dual-stack solution is used it could impose operational expenditures, especially with rule sets at firewalls -- both in front of servers and at clients.
如果使用IPv4/v6双栈解决方案，可能会增加运营开支，特别是在防火墙上的规则集上——无论是在服务器前面还是在客户端。
If an enterprise chooses to deploy hIPv4, however, the legacy applications do not need to be ported because hIPv4 is backwards compatible with the classical IPv4 framework. This means lower costs for the enterprise, and an additional bonus is the new stack's capabilities to better serve mobility use cases.
但是，如果企业选择部署hIPv4，则不需要移植遗留应用程序，因为hIPv4与经典IPv4框架向后兼容。这意味着企业的成本更低，另外一个额外的好处是新堆栈能够更好地服务于移动性用例。
But the enterprise must take the decision soon and act promptly, because the IPv4 address depletion is a reality in the very near future. If the decision is delayed, IPv6 will arrive, and then, sooner or later, the legacy applications will need to be ported.
但企业必须尽快做出决定并迅速采取行动，因为IPv4地址耗尽将在不久的将来成为现实。如果决定延迟，IPv6将到达，然后，早晚都需要移植遗留应用程序。
However, though this document has focused only on IPv4, a similar scheme can be deployed for IPv6 in the future, that is, creating a 64x64 bit locator space. But some benefits would have been lost at the time this document was written, such as:
然而，尽管本文档仅关注IPv4，但将来可以为IPv6部署类似的方案，即创建64x64位定位器空间。但在编写本文档时，某些好处可能已经丧失，例如：
o Backwards compatibility with the current Internet and therefore no smooth migration plan is gained.
o 与当前Internet向后兼容，因此无法获得平滑的迁移计划。
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前缀）会更大，分别为160位和96位。标识符（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）和以服务为中心的网络架构（如SCAFFOLD）的补充。最终用户和企业对互联网上的路由问题不感兴趣；相反，应在三个学科上应用整体观点，重点关注新的服务机会，并将其传达给最终用户和企业。然后，可能会接受并执行到新路由架构的转换请求。然而，要实现这三个学科的整体框架，还需要做更多的工作。
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992.
[RFC1385]Wang，Z.，“EIP：扩展互联网协议”，RFC1385，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，“私人互联网地址分配”，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，“多协议标签交换体系结构”，RFC 30312001年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 46012006年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，“传输层安全（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 59442010年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.，“走向一种新的互联网路由架构：将边缘与传输核心分离的论点”，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.，“展望研讨会：未来互联网中的命名和寻址”，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.org/sigcomm/2008/workshops/ mobiarch/slides/thaler.pdf。
[ILNP] Atkinson, R., "ILNP Concept of Operations", Work in Progress, February 2011.
[ILNP]阿特金森，R.，“ILNP作战概念”，在建工程，2011年2月。
[iVLB] Babaioff, M., Chuang, J., "On the Optimality and Interconnection of Valiant Load-Balancing Networks", 2007, http://people.ischool.berkeley.edu/~chuang/ pubs/VLB-infocom07.pdf.
[iVLB]Babaioff，M.，Chuang，J.，“关于Valiant负载平衡网络的最优性和互连”，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]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议”，正在进行的工作，2011年6月。
[Mobility_&_Privacy] Brim, S., Linsner. M., McLaughlin, B., and K. Wierenga, "Mobility and Privacy", Work in Progress, March 2011.
[移动和隐私]布里姆，S.，林斯纳。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，“基于名称的套接字架构”，正在进行的工作，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/ 文件/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/.
[重游路线缓存]Kim，C.，Caesar，M.，Gerber，A.，Rexford，J.，“重游路线缓存：世界应该是平的”，2009年，http://www.springerlink.com/content/80w13260665v2013/.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，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.，“多播源发现协议（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中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年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 53952008年11月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年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]福特，A.，雷丘，C.，汉德利，M.，巴尔，S.，和J.艾扬格，“多路径TCP开发的架构指南”，RFC6182，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/ 路由搜索组。
[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.
[SCAFFOLD]Freedman，M.J.，Arye，M.，Gopalan，P.，Steven Y.Ko，S.Y.，Nordstrom，E.，Rexford，J.，Shue，D.“以服务为中心的脚手架网络”，2010年9月http://www.cs.princeton.edu/research/techreps/TR-885-10.
[Split-DNS] BIND 9 Administrator Reference Manual, http://www.bind9.net/manual/bind/9.3.1/ Bv9ARM.ch04.html#AEN767.
[拆分DNS]绑定9管理员参考手册，http://www.bind9.net/manual/bind/9.3.1/ Bv9ARM.ch04.html#AEN767。
[tcpcrypt] Bittau, A., Hamburg, M., Handley, M., Mazi`eres, D., Boneh, D., "The case for ubiquitous transport-level encryption", 2010, http://tcpcrypt.org/tcpcrypt.pdf.
[tcpcrypt]Bittau，A.，汉堡，M.，汉德利，M.，马齐埃雷斯，D.，博内，D.，“无处不在的传输级加密的案例”，2010年，http://tcpcrypt.org/tcpcrypt.pdf.
[VLB] Zhang-Shen, R., McKeown, N., "Designing a Predictable Internet Backbone with Valiant Load-Balancing", 2004, http://conferences.sigcomm.org/hotnets/ 2004/HotNets-III%20Proceedings/zhang-shen.pdf.
[VLB]张申，R.，McKeown，N.，“设计具有Valiant负载平衡的可预测互联网主干网”，2004年，http://conferences.sigcomm.org/hotnets/ 2004/HotNets III%20Proceedings/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.
最后，Poughkeepsie 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地址块。最终政策由区域互联网注册中心（RIR）确定。
When the intermediate routing architecture (see Figure 1) is fully implemented, every ALOC realm could have a full IPv4 address space, except the GLB, from which to allocate ELOC blocks. There are some implications, however. In order for an enterprise to achieve site mobility, that is, to change service provider without changing its ELOC scheme, the enterprise should implement an autonomous system (AS) solution with an ALOC prefix at the attachment point to the service provider.
当中间路由架构（见图1）完全实现时，每个ALOC领域都可以有一个完整的IPv4地址空间，GLB除外，从中分配ELOC块。然而，也有一些影响。为了使企业实现站点移动性，即在不改变其ELOC方案的情况下改变服务提供商，企业应实施在服务提供商的连接点具有ALOC前缀的自治系统（AS）解决方案。
Larger enterprises have the resources to implement AS border routing. Most large enterprises have already implemented multi-homing solutions. Small and midsize enterprises (SMEs) may not have the resources to implement AS border routing, or the implementation introduces unnecessary costs for the SME. Also, if every enterprise needs to have an allocated ALOC prefix, this will have an impact on the RIB at the DFZ -- the RIB will be populated with a huge number of non-aggregatable ALOC prefixes.
大型企业有资源实现边界路由。大多数大型企业已经实施了多主机解决方案。中小型企业（SME）可能没有资源实施边界路由，或者实施会给SME带来不必要的成本。此外，如果每个企业都需要分配ALOC前缀，这将对DFZ的RIB产生影响——RIB将填充大量不可聚合的ALOC前缀。
It is clear that a compromise is needed. An SME site usually deploys a single uplink to the Internet and should be able to reserve a PI ELOC block from the RIR without being forced to create an ALOC realm, that is, implement an RBR solution and AS border routing. Since the PI ELOC block is no longer globally unique, an SME can only reserve the PI ELOC block for the region where it is active or has its attachment point to the Internet. The attachment point rarely changes to another country; therefore, it is sufficient that the PI ELOC block is regionally unique.
很明显，需要妥协。SME站点通常部署到互联网的单个上行链路，并且应该能够从RIR预留一个PI ELOC块，而不必被迫创建ALOC领域，即实施RBR解决方案并作为边界路由。由于PI ELOC块不再是全球唯一的，因此SME只能为其活动或其连接点连接到Internet的区域保留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.
当企业更换其Internet服务提供商时，它不必更改其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.
企业合并和收购可能会导致ELOC冲突，因为PI 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解决方案来分离它们——如果所有受影响的端点都支持hIPv4框架。
Finally, residential users will receive only PA locators. When a residential user changes a service provider, she/he has to replace the locators. Since a PA ELOC block is no longer globally unique, every Internet service provider can use the PA ELOC blocks at their ALOC realms; the PA locators become kind of private locators for the service providers.
最后，住宅用户将只接收PA定位器。当住宅用户更换服务提供商时，她/他必须更换定位器。由于PA ELOC块不再是全球唯一的，因此每个互联网服务提供商都可以在其ALOC领域使用PA ELOC块；PA定位器成为服务提供商的一种私有定位器。
If the forwarding planes and all hosts that establish inter-ALOC realm sessions are upgraded to support the hIPv4 framework, that is, the long-term routing architecture (see Figure 2) is implemented, several interesting possibilities occur:
如果将建立ALOC域间会话的转发平面和所有主机升级为支持hIPv4框架，即实现长期路由体系结构（见图2），则会出现几种有趣的可能性：
o The regional allocation policy for PI ELOC spaces can be removed, and the enterprise can make use of the whole IPv4 address space that is globally unique today. The ELOC space is hereafter only significant at a local ALOC realm.
o 可以删除PI ELOC空间的区域分配策略，企业可以利用当前全球唯一的整个IPv4地址空间。此后，ELOC空间仅在局部ALOC领域具有重要意义。
o In case of mergers or acquisitions of enterprises, the private unicast ALOC solution can be used to separate overlapping ELOC spaces.
o 在企业合并或收购的情况下，私有单播ALOC解决方案可用于分离重叠的ELOC空间。
o The GLB space can be expanded to make use of all 32 bits (except for the blocks defined in RFC 1918) for anycast and unicast ALOC allocations; only ISPs are allowed to apply for GLB prefixes.
o GLB空间可以扩展以利用所有32位（RFC1918中定义的块除外）进行任意广播和单播ALOC分配；仅允许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路由信息，因此可以用全局单播ALOC解决方案取代全局选播ALOC解决方案。此外，GLB中有足够的空间为每个企业保留全局单播ALOC前缀。
o Residential users will still use global anycast ALOC solutions, and if they change service providers, their locators need to be replaced.
o 住宅用户仍将使用global 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前缀。例如，可以通过DHCP和IGP扩展自动对ALOC前缀进行重新编号。
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 直连客户（住宅和企业）的私人住宅区
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中肋骨尺寸的增长产生了最大的影响——因此，将a/20 IPv4前缀替换为a/32 ALOC前缀不会减少DFZ中肋骨的尺寸。
Most likely, the only way to prevent this from happening is to impose a yearly cost for the allocation of an ALOC prefix, except if you are a service provider that is providing access and/or transit traffic for your customers. And it is reasonable to impose a cost for allocating an ALOC prefix for the non-service providers, because when an enterprise uses an ALOC prefix, it is reserving a FIB entry throughout the DFZ; the ALOC FIB entry needs to have power, space, hardware, and cooling on all the routers in the DFZ.
最有可能的是，防止这种情况发生的唯一方法是每年为ALOC前缀的分配收取费用，除非您是为您的客户提供访问和/或中转流量的服务提供商。为非服务提供商分配ALOC前缀施加成本是合理的，因为当企业使用ALOC前缀时，它在整个DFZ中保留FIB条目；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
实施这种ALOC分配策略将很好地减少DFZ中的肋骨尺寸，因为多归巢将不再增加DFZ中的肋骨尺寸。但此策略将对恢复能力行为产生一定影响，因为通过压缩路由信息，我们将在网络中失去可见性。在当今的多宿主解决方案中，网络总是知道远程端点所在的位置。在链路或网络故障的情况下，计算备份路径并找到替代路径，DFZ中的所有路由器都知道拓扑结构的变化。此功能已卸载端点的工作负载；他们只需要找到最近的入口路由器，网络就会提供服务
the packets to the egress router, regardless (almost) of what failures happen in the network. And with the growth of multi-homed prefixes, the routers in the DFZ have been forced to carry greater workloads, perhaps close to their limits -- the workload between the network and endpoints is not in balance. The conclusion is that the endpoints should take more responsibility for their sessions by offloading the workload in the network. How? Let us walk through an example.
将数据包发送到出口路由器，而不管（几乎）网络中发生了什么故障。随着多宿前缀的增长，DFZ中的路由器被迫承载更大的工作负载，可能接近其极限——网络和端点之间的工作负载不平衡。结论是，端点应该通过减轻网络中的工作负载来承担更多的会话责任。怎样让我们看一个例子。
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.
远程企业已通过静态路由或向上游服务提供商宣布的BGP获得ELOC块192.168.1.0/24。上游服务提供商为企业提供ALOC信息10.1.1.1和10.2.2.2。已安装远程端点，并给出ELOC 192.168.1.1——ELOC是一个定位器，用于定义远程端点连接到远程网络的位置。远程端点被分配了ALOC 10.1.1.1和10.2.2.2——ALOC是一个定位器，用于定义远程网络到Internet的连接点。
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的启动器（本地端点）通过使用ALOC 10.3.3.3与ELOC 192.168.1.1和ALOC 10.1.1处的响应者（远程端点）建立会话。也就是说，网络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.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）的边界路由器不会意识到这种情况，因为只有ALOC信息在服务提供商之间交换，并且ELOC信息被压缩以留在ALOC领域内。但是BR-R1会注意到链路故障；BR-R1可以将该会话的定位器标头中的ALOC字段从10.1.1.1重写为10.2.2.2，并通过BR-R2将数据包发送给第二个服务提供商。启动器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.
如果BR-I3和提供ALOC 10.3.3.3的ISP之间的网络链路出现故障，BR-I3可以重写定位器报头中的ALOC前缀，并通过BR-I4路由数据包，会话将保持正常。如果网络中的某个地方出现故障，边界路由器可能会收到ICMP目的地不可访问消息（如果没有被某些安全功能阻止），并因此尝试通过替换hIPv4报头中的ALOC前缀将会话切换到其他ISP。或者，在会话中的某个超时之后，端点可能会尝试自己切换到其他ALOC。在所有会话转换情况下，遗留的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.
如果边界路由器或其中一个端点在未与远程端点协商的情况下更改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或相邻ISP的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 并非所有端点都需要升级，只有那些直接连接到Internet的端点，例如便携式笔记本电脑、智能移动电话、代理和DMZ/前端端点。但最关键的端点，即企业保存其最关键业务应用程序的后端端点，不需要升级。这些端点根本不应该从Internet访问，而应该仅从专用网络访问。这一功能可以通过hIPv4框架实现，因为它与当前的IPv4协议栈向后兼容。因此，对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
o 从IPv4到IPv6（当前定义的体系结构）的迁移将增加整个DFZ的RIB和FIB。是否需要对[RFC4984]中讨论的转发平面进行新的升级尚不清楚。很可能需要升级。这个
outcome of deploying IPv4 and IPv6 concurrently is that the routers need to have larger memories for the RIB and FIB -- every globally unique prefix is installed in the routers that are participating in the DFZ. Since the enterprise reserves one or several RIB/FIB entries on every router in the DFZ, it is increasing the power consumption of the Internet, thus increasing the carbon footprint. And many enterprises are committed to green programs. If hIPv4 is deployed, the power consumption of the Internet will not grow as much as in an IPv4 to IPv6 transition scenario.
同时部署IPv4和IPv6的结果是，路由器需要为RIB和FIB拥有更大的内存——每个全局唯一前缀都安装在参与DFZ的路由器中。由于企业在DFZ中的每个路由器上保留一个或多个RIB/FIB条目，因此增加了互联网的功耗，从而增加了碳足迹。许多企业都致力于绿色计划。如果部署了hIPv4，Internet的功耗增长将不会像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（当前定义的体系结构）的迁移，DFZ中的路由器很可能需要升级到更昂贵的路由器，如[RFC4984]中所述。在世界富裕地区，互联网用户已经大量渗透，服务提供商可以更轻松地将升级成本转嫁给用户。在“富有/高渗透率”的情况下，成本不会增长太多，以至于用户会放弃互联网。但在世界上较不富裕的地区，用户普及率通常较低，升级成本无法轻易接受——“较不富裕/较低普及率”可能会大幅增加需要转嫁给用户的成本。因此，能够连接到互联网的用户越来越少。对于全球企业和世界较不富裕地区的企业而言，这种情况可能意味着潜在客户减少，并且可能出现企业游牧民族无法连接到互联网的情况。这也不公平,；每个人都应该有一个公平的机会享受互联网体验——世界上富裕的部分应该考虑到这一权利。许多企业致力于企业社会责任计划。
Not only technical and economical arguments can be found. Other arguments that the general public is interested in and concerned about can be found, for example, that the Internet becomes greener and more affordable for everyone, in contrast with the current forecast of the evolution of the Internet.
不仅可以找到技术和经济方面的论据。公众感兴趣和关注的其他论点可以找到，例如，与当前对互联网发展的预测相比，互联网变得更加绿色，每个人都能负担得起。
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
因为hIPv4框架需要更改端点的堆栈，所以在将当前IPv4体系结构迁移到中间hIPv4路由体系结构之前需要一些时间。如果hIPv4代理解决方案可以在
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.
在传统的IPv4端点中，早期采用者开始向hIPv4框架迁移的门槛将不那么值得怀疑，迁移阶段也很可能更短。
Therefore, it should be investigated whether the hIPv4 framework can be integrated with Core-Edge Separation [CES] architectures. In CES architectures the endpoints do not need to be modified. The design goal of a CES solution is to minimize the PI-address entries in the DFZ and to preserve the current stack at the endpoints. But a CES solution requires a new mapping system and also introduces a caching mechanism in the map-and-encapsulate network nodes. Much debate about scalability of a mapping system and the caching mechanism has been going on at the [RRG] list. At the present time it is unclear how well both solutions will scale; research work on both topics is still in progress.
因此，应该研究hIPv4框架是否可以与核心边缘分离[CES]架构集成。在CES体系结构中，端点不需要修改。CES解决方案的设计目标是最小化DFZ中的PI地址项，并在端点保留当前堆栈。但是CES解决方案需要一个新的映射系统，还需要在映射中引入缓存机制并封装网络节点。关于映射系统的可伸缩性和缓存机制的许多争论一直在[RRG]列表中进行。目前尚不清楚这两种解决方案的扩展性如何；关于这两个主题的研究工作仍在进行中。
Since the CES architectures divide the address spaces into two new categories, one that is installed in the RIB of the DFZ and one that is installed in the local networks, there are to some degree similarities between CES architectures and the hIPv4 framework. Actually, the invention of the IP and locator header swap functionality was inspired by [LISP].
由于CES体系结构将地址空间分为两个新类别，一个安装在DFZ的RIB中，另一个安装在本地网络中，因此CES体系结构与hIPv4框架之间存在一定程度的相似性。实际上，IP和定位器头交换功能的发明是受[LISP]启发的。
In order to describe how these two architectures might be integrated, some terminology definitions are needed:
为了描述这两种体系结构如何集成，需要一些术语定义：
CES-node:
CES节点：
A network node installed in front of a local network that must have the following characteristics:
安装在本地网络前面的网络节点必须具有以下特征：
o Map-and-encapsulate ingress functionality
o 映射和封装入口功能
o Map-and-encapsulate egress functionality
o 映射和封装出口功能
o Incorporate the hIPv4 stack
o 合并hIPv4堆栈
o Routing functionality, [RFC1812]
o 路由功能，[RFC1812]
o Being able to apply policy-based routing on the ALOC field in the locator header
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扩展，因为它很可能会给CES节点带来太多负担，无法为缓存的hIPv4条目发送信号并维护MPTCP子流。
Consumer site:
消费者网站：
A site that is not publishing any services towards the Internet, that is, there are no entries in DNS for this site. It is used by local endpoints to establish outbound connectivity -- endpoints are initiating sessions from the site towards content sites. Usually such sites are found at small enterprises and residences. PA-addresses are usually assigned to them.
未向Internet发布任何服务的站点，即此站点的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.
向Internet发布服务的站点，通常有DNS条目。本地端点使用这样的站点来建立入站和出站连接。大型企业使用PI地址，而中小型企业使用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地址条目。因此，映射和封装出口功能将安装在内容站点的前面。包含map和封装出口功能的节点很可能也将包含map和封装入口功能；它也是一个路由器，因此节点只需要支持hIPv4堆栈，并且能够使用locator标头的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体系结构，它应该提供一种机制来减轻缓存和映射查找延迟风险。一种方法是将CES架构推向边缘——您添加的新功能越靠近边缘，它的可扩展性就越好。也就是说，如果端点堆栈升级，缓存机制将由端点本身维护。当CES解决方案在端点处集成时，如果用hIPv4的寻址方案替换CES体系结构的寻址方案，则可以删除映射机制。通过这种方法，LCP可以在其站点前面安装CES节点。此外，内容站点上的某些端点可能会使用hIPv4堆栈进行升级。
If the LCP faces issues with the caching or mapping mechanisms, the provider can ask its clients to upgrade their endpoint's stack to ensure a proper service level. At the same time, the LCP promotes the migration from the current routing architecture to a new routing architecture, not for the sake of the routing architecture but instead to ensure a proper service level -- you can say that a business model will promote the migration of a new routing architecture.
如果LCP面临缓存或映射机制的问题，提供者可以要求其客户端升级其端点的堆栈，以确保适当的服务级别。同时，LCP促进了从当前路由体系结构到新路由体系结构的迁移，不是为了路由体系结构，而是为了确保适当的服务级别——可以说，业务模型将促进新路由体系结构的迁移。
The hIPv4 framework proposes that the IPv4 addresses (ELOC) should no longer be globally unique; once the transition is completed, a more regional allocation can be deployed. But this is only possible once all endpoints (that are establishing sessions to other ALOC realms) have migrated to support the hIPv4 framework. Here the CES architecture can speed up the re-usage of IPv4 addresses; that is, once an IPv4 address block has become an ELOC block it can be re-used in the other RIR regions, without the requirement that all endpoints in the Internet must first be upgraded.
hIPv4框架建议IPv4地址（ELOC）不再是全局唯一的；一旦过渡完成，就可以部署更多的区域拨款。但是，只有当所有端点（正在建立到其他ALOC领域的会话）都迁移到支持hIPv4框架时，这才可能实现。在这里，CES体系结构可以加快IPv4地址的重复使用；也就是说，一旦IPv4地址块成为ELOC块，它就可以在其他RIR区域中重新使用，而无需首先升级Internet中的所有端点。
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地址，使内容站点或多或少成为推出CES解决方案的主要目标。在大型内容站点上，最有可能安装CES节点。升级大型内容站点上的所有端点（向Internet提供服务）需要时间，而且内容站点上的端点可能仅在其正常生命周期过程中升级。但是，如果内容站点的大小很小，管理员要么安装CES节点，要么升级端点的堆栈——这一决定受可用性、可靠性和经济可行性的影响。
Once the content sites have been upgraded, the PI-address entries have been removed from the DFZ. Most likely also some endpoints at the consumer sites have been upgraded to support the hIPv4 stack -- especially if there have been issues with the caches or mapping delays that have influenced the service levels at the LCPs. Then, the issue is how to keep track of the upgrade of the content sites -- have they been migrated or not? If the content sites or content endpoints have been migrated, the DNS records should have either a CES-node entry or ALOC entry for each A-record. When the penetration of CES solutions at content sites (followed up by CES-node/ALOC records in DNS) is high enough, the ISP can start to promote the hIPv4 stack upgrade at the consumer sites.
内容站点升级后，PI地址条目将从DFZ中删除。最有可能的情况是，消费者站点的某些端点已升级以支持hIPv4堆栈，特别是在缓存或映射延迟出现问题影响LCP的服务级别时。然后，问题是如何跟踪内容站点的升级——它们是否已迁移？如果内容站点或内容端点已迁移，则DNS记录应具有每个a记录的CES节点条目或ALOC条目。当CES解决方案在内容站点的普及率足够高（随后是DNS中的CES节点/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
一旦PA地址块被迁移，它就可以从全局分配释放到区域分配。为什么ISP会推动其客户部署hIPv4堆栈？由于商业模式的原因，在当前的市场环境下，成本会更高
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.
建筑学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将拥有一个更独立的路由域（ALOC领域），只有来自其他ISP的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解决方案很有吸引力。它将消除即将到来的IPv4地址耗尽限制，而不强制消费者切换到IPv6，因此内容提供商可以继续增长（接触更多消费者）。
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也可能会发现这种解决方案很有吸引力，因为从长远来看，它可以减少资本和运营支出。内容提供商和互联网服务提供商都为互联网提供了基础。如果两者都采用这种体系结构，消费者就必须采用。这两个提供商都可能找到业务模型来“引导”消费者走向新的路由体系结构。
Then, how will this affect the consumer and content sites? Residential users will need to upgrade their endpoints. But it doesn't really matter which IP version they use. It is the availability and affordability of the Internet that matters most.
那么，这将如何影响消费者和内容网站？住宅用户将需要升级其端点。但他们使用哪个IP版本并不重要。最重要的是互联网的可用性和可承受性。
Enterprises will be affected a little bit more. The edge devices at the enterprises' local networks need to be upgraded -- edge nodes such as AS border routers, middleboxes, DNS, DHCP, and public nodes -- but by installing a CES-node in front of them, the upgrade process is postponed and the legacy nodes can be upgraded during their normal lifecycle process. The internal infrastructure is preserved, internal applications can still use IPv4, and all investment in IPv4 skills is preserved.
企业会受到更大的影响。企业本地网络上的边缘设备需要升级——边缘节点，如边界路由器、中间盒、DNS、DHCP和公共节点——但通过在它们前面安装CES节点，升级过程将推迟，遗留节点可以在其正常生命周期过程中升级。内部基础设施得到保留，内部应用程序仍然可以使用IPv4，对IPv4技能的所有投资也得到保留。
Walkthrough of use cases:
用例演练：
1. A legacy endpoint at a content site establishes a session to a content site with a hIPv4 upgraded endpoint.
1. 内容站点上的旧端点使用hIPv4升级的端点建立到内容站点的会话。
When the legacy endpoint resolves the DNS entry for the remote endpoint (a hIPv4 upgraded endpoint), it receives an ALOC record in the DNS response. The legacy endpoint ignores the ALOC record. Only the A-record is used to establish the session. Next, the legacy endpoint initializes the session and a packet is sent towards the map-and-encapsulate ingress node, which needs to do a lookup at the CES mapping system (the assumption here is that no cache entry exists for the remote endpoint). The mapping system returns either a CES-node prefix or an ALOC prefix for the lookup -- since the requested remote endpoint has been upgraded, the mapping system returns an ALOC prefix.
当传统端点解析远程端点（hIPv4升级的端点）的DNS条目时，它将在DNS响应中接收ALOC记录。旧端点忽略ALOC记录。只有A记录用于建立会话。接下来，遗留端点初始化会话，并向map发送一个数据包并封装入口节点，该节点需要在CES映射系统上进行查找（这里的假设是远程端点不存在缓存条目）。映射系统为查找返回CES节点前缀或ALOC前缀——由于请求的远程端点已升级，映射系统将返回ALOC前缀。
The CES-node will not use the CES encapsulation scheme for this session. Instead, the hIPv4 header scheme will be used and a /32 entry will be created in the cache. A /32 entry must be created; it is possible that not all endpoints at the remote site are upgraded to support the hIPv4 framework. The /32 cache entry can be replaced with a shorter prefix in the cache if all endpoints are upgraded at the remote site. To indicate this situation, a subfield should be added for the ALOC record in the mapping system.
CES节点不会为此会话使用CES封装方案。相反，将使用hIPv4标头方案，并在缓存中创建/32条目。必须创建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. 创建定位器头并将IP头的目标地址字段中的值复制到定位器头的ELOC字段。
c. Replace the destination address in the IP header with the ALOC prefix given in the cache.
c. 用缓存中给定的ALOC前缀替换IP头中的目标地址。
d. Insert the local CES-node prefix in the ALOC field of the locator header.
d. 在定位器头的ALOC字段中插入本地CES节点前缀。
e. Copy the transport protocol value of the IP header to the protocol field of the locator header and set the hIPv4 protocol value in the protocol field of the IP header.
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值减小一。
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端点的角度来看，新记录前缀是否用于定位Internet中的RBR节点或CES节点并不重要——CES节点将充当远程遗留端点前面的hIPv4代理。因此，hIPv4端点组装hIPv4数据包以初始化会话，当数据包到达CES节点时，它必须执行以下操作：
a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
a. 验证接收到的数据包是否使用IP报头协议字段中的hIPv4协议值。
b. Verify IP, locator, and transport protocol header checksums. Transport protocol header verification does not include the locator header fields.
b. 验证IP、定位器和传输协议标头校验和。传输协议头验证不包括定位器头字段。
c. Replace the protocol field value of the IP header with the protocol field value of the locator header.
c. 用定位器标头的协议字段值替换IP标头的协议字段值。
d. Replace the destination address in the IP header with the ELOC prefix of the locator header.
d. 用定位器标头的ELOC前缀替换IP标头中的目标地址。
e. Remove the locator header.
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值减小一。
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.
在这个用例中，会话将失败，除非在ISP的映射和封装节点上发明并实现某种机制。会话将在ALOC领域内工作，因为经典的IPv4框架仍然有效。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架构（architecture）文档中描述。
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