Internet Research Task Force (IRTF) T. Li, Ed.
Request for Comments: 6115 Cisco Systems
Category: Informational February 2011
ISSN: 2070-1721
Internet Research Task Force (IRTF) T. Li, Ed.
Request for Comments: 6115 Cisco Systems
Category: Informational February 2011
ISSN: 2070-1721
Recommendation for a Routing Architecture
路由体系结构的建议
Abstract
摘要
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group.
人们普遍认为，Internet路由和寻址体系结构在可扩展性、多宿主和域间流量工程方面面临挑战。作为IETF未来方向的建议，本文件提出了有助于互联网未来可扩展性的解决方案。为此，本文件调查了在本次活动中提出供讨论的许多提案，以及随后的一些分析和主席的架构建议。本文件是路由研究组的产品。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Routing Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网研究工作组（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/rfc6115.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6115.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Background to This Document . . . . . . . . . . . . . . . 5
1.2. Areas of Group Consensus . . . . . . . . . . . . . . . . . 6
1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
2. Locator/ID Separation Protocol (LISP) . . . . . . . . . . . . 8
2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. References . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Routing Architecture for the Next Generation Internet
(RANGI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4. References . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Internet Vastly Improved Plumbing (Ivip) . . . . . . . . . . . 16
4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 16
4.1.2. Extensions . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2.1. TTR Mobility . . . . . . . . . . . . . . . . . . . 17
4.1.2.2. Modified Header Forwarding . . . . . . . . . . . . 18
4.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.5. References . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Hierarchical IPv4 Framework (hIPv4) . . . . . . . . . . . . . 21
5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Background to This Document . . . . . . . . . . . . . . . 5
1.2. Areas of Group Consensus . . . . . . . . . . . . . . . . . 6
1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
2. Locator/ID Separation Protocol (LISP) . . . . . . . . . . . . 8
2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. References . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Routing Architecture for the Next Generation Internet
(RANGI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4. References . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Internet Vastly Improved Plumbing (Ivip) . . . . . . . . . . . 16
4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 16
4.1.2. Extensions . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2.1. TTR Mobility . . . . . . . . . . . . . . . . . . . 17
4.1.2.2. Modified Header Forwarding . . . . . . . . . . . . 18
4.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.5. References . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Hierarchical IPv4 Framework (hIPv4) . . . . . . . . . . . . . 21
5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.3. Costs and Issues . . . . . . . . . . . . . . . . . . . 23
5.1.4. References . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Name Overlay (NOL) Service for Scalable Internet Routing . . . 25
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.4. References . . . . . . . . . . . . . . . . . . . . . . 27
6.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Compact Routing in a Locator Identifier Mapping System (CRM) . 29
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1.4. References . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Layered Mapping System (LMS) . . . . . . . . . . . . . . . . . 32
8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 32
8.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1.4. References . . . . . . . . . . . . . . . . . . . . . . 33
8.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 34
9. Two-Phased Mapping . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1.1. Considerations . . . . . . . . . . . . . . . . . . . . 34
9.1.2. Basics of a Two-Phased Mapping . . . . . . . . . . . . 35
9.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 36
9.1.5. References . . . . . . . . . . . . . . . . . . . . . . 36
9.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Global Locator, Local Locator, and Identifier Split
(GLI-Split) . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 36
10.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1.4. References . . . . . . . . . . . . . . . . . . . . . . 38
10.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.3. Costs and Issues . . . . . . . . . . . . . . . . . . . 23
5.1.4. References . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Name Overlay (NOL) Service for Scalable Internet Routing . . . 25
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.4. References . . . . . . . . . . . . . . . . . . . . . . 27
6.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Compact Routing in a Locator Identifier Mapping System (CRM) . 29
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1.4. References . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Layered Mapping System (LMS) . . . . . . . . . . . . . . . . . 32
8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 32
8.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1.4. References . . . . . . . . . . . . . . . . . . . . . . 33
8.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 34
9. Two-Phased Mapping . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1.1. Considerations . . . . . . . . . . . . . . . . . . . . 34
9.1.2. Basics of a Two-Phased Mapping . . . . . . . . . . . . 35
9.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 36
9.1.5. References . . . . . . . . . . . . . . . . . . . . . . 36
9.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Global Locator, Local Locator, and Identifier Split
(GLI-Split) . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 36
10.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1.4. References . . . . . . . . . . . . . . . . . . . . . . 38
10.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 39
11. Tunneled Inter-Domain Routing (TIDR) . . . . . . . . . . . . . 40
11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1.4. References . . . . . . . . . . . . . . . . . . . . . . 41
11.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 42
12. Identifier-Locator Network Protocol (ILNP) . . . . . . . . . . 42
12.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 42
12.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 42
12.1.2. Benefits . . . . . . . . . . . . . . . . . . . . . . . 43
12.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1.4. References . . . . . . . . . . . . . . . . . . . . . . 45
12.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 45
12.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 46
13. Enhanced Efficiency of Mapping Distribution Protocols in
Map-and-Encap Schemes (EEMDP) . . . . . . . . . . . . . . . . 48
13.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 48
13.1.2. Management of Mapping Distribution of Subprefixes
Spread across Multiple ETRs . . . . . . . . . . . . . 48
13.1.3. Management of Mapping Distribution for Scenarios
with Hierarchy of ETRs and Multihoming . . . . . . . . 49
13.1.4. References . . . . . . . . . . . . . . . . . . . . . . 50
13.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 51
14. Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1.1. Need for Evolution . . . . . . . . . . . . . . . . . . 52
14.1.2. Relation to Other RRG Proposals . . . . . . . . . . . 53
14.1.3. Aggregation with Increasing Scopes . . . . . . . . . . 53
14.1.4. References . . . . . . . . . . . . . . . . . . . . . . 55
14.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 55
14.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 56
15. Name-Based Sockets . . . . . . . . . . . . . . . . . . . . . . 56
15.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 56
15.1.1. References . . . . . . . . . . . . . . . . . . . . . . 58
15.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.2.1. Deployment . . . . . . . . . . . . . . . . . . . . . . 59
15.2.2. Edge-networks . . . . . . . . . . . . . . . . . . . . 59
15.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 59
16. Routing and Addressing in Networks with Global Enterprise
Recursion (IRON-RANGER) . . . . . . . . . . . . . . . . . . . 59
16.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 59
16.1.1. Gains . . . . . . . . . . . . . . . . . . . . . . . . 60
16.1.2. Costs . . . . . . . . . . . . . . . . . . . . . . . . 61
16.1.3. References . . . . . . . . . . . . . . . . . . . . . . 61
11. Tunneled Inter-Domain Routing (TIDR) . . . . . . . . . . . . . 40
11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1.4. References . . . . . . . . . . . . . . . . . . . . . . 41
11.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 42
12. Identifier-Locator Network Protocol (ILNP) . . . . . . . . . . 42
12.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 42
12.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 42
12.1.2. Benefits . . . . . . . . . . . . . . . . . . . . . . . 43
12.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1.4. References . . . . . . . . . . . . . . . . . . . . . . 45
12.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 45
12.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 46
13. Enhanced Efficiency of Mapping Distribution Protocols in
Map-and-Encap Schemes (EEMDP) . . . . . . . . . . . . . . . . 48
13.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 48
13.1.2. Management of Mapping Distribution of Subprefixes
Spread across Multiple ETRs . . . . . . . . . . . . . 48
13.1.3. Management of Mapping Distribution for Scenarios
with Hierarchy of ETRs and Multihoming . . . . . . . . 49
13.1.4. References . . . . . . . . . . . . . . . . . . . . . . 50
13.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 51
14. Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1.1. Need for Evolution . . . . . . . . . . . . . . . . . . 52
14.1.2. Relation to Other RRG Proposals . . . . . . . . . . . 53
14.1.3. Aggregation with Increasing Scopes . . . . . . . . . . 53
14.1.4. References . . . . . . . . . . . . . . . . . . . . . . 55
14.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 55
14.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 56
15. Name-Based Sockets . . . . . . . . . . . . . . . . . . . . . . 56
15.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 56
15.1.1. References . . . . . . . . . . . . . . . . . . . . . . 58
15.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.2.1. Deployment . . . . . . . . . . . . . . . . . . . . . . 59
15.2.2. Edge-networks . . . . . . . . . . . . . . . . . . . . 59
15.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 59
16. Routing and Addressing in Networks with Global Enterprise
Recursion (IRON-RANGER) . . . . . . . . . . . . . . . . . . . 59
16.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 59
16.1.1. Gains . . . . . . . . . . . . . . . . . . . . . . . . 60
16.1.2. Costs . . . . . . . . . . . . . . . . . . . . . . . . 61
16.1.3. References . . . . . . . . . . . . . . . . . . . . . . 61
16.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 61
16.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 62
17. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 63
17.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 64
17.2. Recommendation to the IETF . . . . . . . . . . . . . . . . 65
17.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 65
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66
19. Security Considerations . . . . . . . . . . . . . . . . . . . 66
20. Informative References . . . . . . . . . . . . . . . . . . . . 66
16.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 61
16.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 62
17. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 63
17.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 64
17.2. Recommendation to the IETF . . . . . . . . . . . . . . . . 65
17.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 65
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66
19. Security Considerations . . . . . . . . . . . . . . . . . . . 66
20. Informative References . . . . . . . . . . . . . . . . . . . . 66
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. The problem being addressed has been documented in [Scalability_PS], and the design goals that we have discussed can be found in [RRG_Design_Goals].
人们普遍认为，Internet路由和寻址体系结构在可扩展性、多宿主和域间流量工程方面面临挑战。正在解决的问题已记录在[Scalability_PS]中，我们讨论的设计目标可在[RRG_design_goals]中找到。
This document surveys many of the proposals that were brought forward for discussion in this activity. For some of the proposals, this document also includes additional analysis showing some of the concerns with specific proposals, and how some of those concerns may be addressed. Readers are cautioned not to draw any conclusions about the degree of interest or endorsement by the Routing Research Group (RRG) from the presence of any proposals in this document, or the amount of analysis devoted to specific proposals.
本文件调查了在本次活动中提出供讨论的许多提案。对于一些提案，本文件还包括额外的分析，显示了与具体提案有关的一些问题，以及如何解决这些问题。提醒读者不要从本文件中的任何提案或专门针对具体提案的分析量中得出任何关于路由研究组（RRG）的兴趣或认可程度的结论。
The RRG was chartered to research and recommend a new routing architecture for the Internet. The goal was to explore many alternatives and build consensus around a single proposal. The only constraint on the group's process was that the process be open and the group set forth with the usual discussion of proposals and trying to build consensus around them. There were no explicit contingencies in the group's process for the eventuality that the group did not reach consensus.
RRG被授权研究和推荐一种新的互联网路由架构。目标是探索多种备选方案，并围绕一项提案达成共识。对工作组进程的唯一限制是，进程必须公开，工作组以通常的方式讨论提案，并试图围绕提案达成共识。在本集团的过程中，没有明确的或有事项导致本集团未能达成共识。
The group met at every IETF meeting from March 2007 to March 2010 and discussed many proposals, both in person and via its mailing list. Unfortunately, the group did not reach consensus. Rather than lose the contributions and progress that had been made, the chairs (Lixia Zhang and Tony Li) elected to collect the proposals of the group and some of the debate concerning the proposals and make a recommendation from those proposals. Thus, the recommendation reflects the opinions of the chairs and not necessarily the consensus of the group.
该小组在2007年3月至2010年3月的每一次IETF会议上都举行了会议，并亲自或通过邮件列表讨论了许多提案。不幸的是，该小组没有达成共识。主席（张丽霞和李东尼）没有失去已经取得的贡献和进展，而是选择收集工作组的提案和一些关于提案的辩论，并从这些提案中提出建议。因此，该建议反映了主席的意见，而不一定反映了工作组的共识。
The group was able to reach consensus on a number of items that are
该小组得以就一些有待解决的问题达成共识
included below. The proposals included here were collected in an open call amongst the group. Once the proposals were collected, the group was solicited to submit critiques of each proposal. The group was asked to self-organize to produce a single critique for each proposal. In cases where there were several critiques submitted, the editor selected one. The proponents of each proposal then were given the opportunity to write a rebuttal of the critique. Finally, the group again had the opportunity to write a counterpoint of the rebuttal. No counterpoints were submitted. For pragmatic reasons, each submission was severely constrained in length.
包括在下面。此处包含的建议是在小组之间的公开电话中收集的。收集提案后，要求小组对每一提案提出评论。该小组被要求自行组织，对每一项提案提出一个评论。在提交了多篇评论的情况下，编辑选择了一篇。然后，每项提案的支持者都有机会对批评进行反驳。最后，该小组再次有机会写下反驳的对位。没有提出反对意见。出于务实的原因，每次提交的文件在长度上都受到严格限制。
All of the proposals were given the opportunity to progress their documents to RFC status; however, not all of them have chosen to pursue this path. As a result, some of the references in this document may become inaccessible. This is unfortunately unavoidable.
所有提案都有机会将其文件升级为RFC状态；然而，并非所有国家都选择走这条道路。因此，本文件中的某些参考可能无法访问。不幸的是，这是不可避免的。
The group did reach consensus that the overall document should be published. The document has been reviewed by many of the active members of the Research Group.
工作组确实达成了一致意见，即应公布整个文件。该文件已由研究小组的许多活跃成员审查。
The group was also able to reach broad and clear consensus on some terminology and several important technical points. For the sake of posterity, these are recorded here:
专家组还就一些术语和几个重要的技术要点达成了广泛和明确的共识。为了子孙后代，这里记录了以下内容：
1. A "node" is either a host or a router.
1. “节点”是主机或路由器。
2. A "router" is any device that forwards packets at the network layer (e.g., IPv4, IPv6) of the Internet architecture.
2. “路由器”是指在互联网体系结构的网络层（如IPv4、IPv6）转发数据包的任何设备。
3. A "host" is a device that can send/receive packets to/from the network, but does not forward packets.
3. “主机”是可以向网络发送/接收数据包，但不转发数据包的设备。
4. A "bridge" is a device that forwards packets at the link layer (e.g., Ethernet) of the Internet architecture. An Ethernet switch or Ethernet hub are examples of bridges.
4. “网桥”是在互联网体系结构的链路层（例如以太网）转发数据包的设备。以太网交换机或以太网集线器就是网桥的例子。
5. An "address" is an object that combines aspects of identity with topological location. IPv4 and IPv6 addresses are current examples.
5. “地址”是一个结合了身份和拓扑位置的对象。IPv4和IPv6地址是当前的示例。
6. A "locator" is a structured topology-dependent name that is not used for node identification and is not a path. Two related meanings are current, depending on the class of things being named:
6. “定位器”是一个结构化拓扑相关名称，不用于节点标识，也不是路径。两个相关的含义是当前的，取决于被命名的事物的类别：
1. The topology-dependent name of a node's interface.
1. 节点接口的拓扑相关名称。
2. The topology-dependent name of a single subnetwork OR topology-dependent name of a group of related subnetworks that share a single aggregate. An IP routing prefix is a current example of the latter.
2. 单个子网络的拓扑相关名称或共享单个聚合的一组相关子网络的拓扑相关名称。IP路由前缀是后者的当前示例。
7. An "identifier" is a topology-independent name for a logical node. Depending upon instantiation, a "logical node" might be a single physical device, a cluster of devices acting as a single node, or a single virtual partition of a single physical device. An OSI End System Identifier (ESID) is an example of an identifier. A Fully Qualified Domain Name (FQDN) that precisely names one logical node is another example. (Note well that not all FQDNs meet this definition.)
7. “标识符”是逻辑节点的与拓扑无关的名称。根据实例化的不同，“逻辑节点”可能是单个物理设备、充当单个节点的设备集群或单个物理设备的单个虚拟分区。OSI终端系统标识符（ESID）是标识符的一个示例。另一个例子是精确命名一个逻辑节点的完全限定域名（FQDN）。（请注意，并非所有FQDN都符合此定义。）
8. Various other names (i.e., other than addresses, locators, or identifiers), each of which has the sole purpose of identifying a component of a logical system or physical device, might exist at various protocol layers in the Internet architecture.
8. 各种其他名称（即，地址、定位器或标识符除外）可能存在于因特网体系结构中的各种协议层上，每个名称的唯一目的是识别逻辑系统或物理设备的组件。
9. The Research Group has rough consensus that separating identity from location is desirable and technically feasible. However, the Research Group does NOT have consensus on the best engineering approach to such an identity/location split.
9. 研究小组大致一致认为，将身份与地点分开是可取的，而且在技术上是可行的。然而，研究小组并没有就这种身份/位置划分的最佳工程方法达成共识。
10. The Research Group has consensus that the Internet needs to support multihoming in a manner that scales well and does not have prohibitive costs.
10. 该研究小组一致认为，互联网需要以一种可扩展且成本不高的方式支持多宿。
11. Any IETF solution to Internet scaling has to not only support multihoming, but address the real-world constraints of the end customers (large and small).
11. 任何互联网扩展的IETF解决方案不仅必须支持多主，还必须解决终端客户（大客户和小客户）的现实约束。
This section lists some of the most common abbreviations used in the remainder of this document.
本节列出了本文件其余部分中使用的一些最常见的缩写。
DFZ Default-Free Zone
默认自由区
EID Endpoint IDentifier or Endpoint Interface iDentifier: The precise definition varies depending on the proposal.
EID端点标识符或端点接口标识符：精确定义因方案而异。
ETR Egress Tunnel Router: In a system that tunnels traffic across the existing infrastructure by encapsulating it, the device close to the actual ultimate destination that decapsulates the traffic before forwarding it to the ultimate destination.
ETR出口隧道路由器：在通过封装跨现有基础设施传输流量的系统中，靠近实际最终目的地的设备，该设备在将流量转发到最终目的地之前对其进行去封装。
FIB Forwarding Information Base: The forwarding table, used in the
FIB转发信息库：转发表，用于
data plane of routers to select the next hop for each packet.
路由器的数据平面，用于为每个数据包选择下一跳。
ITR Ingress Tunnel Router: In a system that tunnels traffic across the existing infrastructure by encapsulating it, the device close to the actual original source that encapsulates the traffic before using the tunnel to send it to the appropriate ETR.
ITR入口隧道路由器：在通过封装跨现有基础设施传输流量的系统中，靠近实际原始源的设备，在使用隧道将流量发送到适当的ETR之前封装流量。
PA Provider-Aggregatable: Address space that can be aggregated as part of a service provider's routing advertisements.
PA Provider Aggregatable：可以作为服务提供商路由公告的一部分进行聚合的地址空间。
PI Provider-Independent: Address space assigned by an Internet registry independent of any service provider.
PI Provider Independent：由独立于任何服务提供商的Internet注册表分配的地址空间。
PMTUD Path Maximum Transmission Unit Discovery: The process or mechanism that determines the largest packet that can be sent between a given source and destination without being either i) fragmented (IPv4 only), or ii) discarded (if not fragmentable) because it is too large to be sent down one link in the path from the source to the destination.
PMTUD Path最大传输单元发现：一种过程或机制，用于确定在给定源和目标之间可以发送的最大数据包，而不会被i）分段（仅IPv4），或ii）丢弃（如果不可分段），因为数据包太大，无法在从源到目标的路径中沿一条链路发送。
RIB Routing Information Base. The routing table, used in the control plane of routers to exchange routing information and construct the FIB.
RIB路由信息库。路由表，用于路由器的控制平面，用于交换路由信息和构造FIB。
RIR Regional Internet Registry.
RIR区域互联网注册处。
RLOC Routing LOCator: The precise definition varies depending on the proposal.
RLOC路由定位器：精确定义因方案而异。
xTR Tunnel Router: In some systems, the term used to describe a device which can function as both an ITR and an ETR.
xTR隧道路由器：在某些系统中，用于描述既可作为ITR又可作为ETR的设备的术语。
Implements a locator/identifier separation mechanism using encapsulation between routers at the "edge" of the Internet. Such a separation allows topological aggregation of the routable addresses (locators) while providing stable and portable numbering of end systems (identifiers).
使用Internet“边缘”路由器之间的封装实现定位器/标识符分离机制。这种分离允许路由地址（定位器）的拓扑聚合，同时提供稳定和可移植的终端系统（标识符）编号。
o topological aggregation of locator space (RLOCs) used for routing, which greatly reduces both the overall size and the "churn rate" of the information needed to operate the Internet global routing system
o 用于路由的定位空间拓扑聚合（RLOCs），大大减少了运行Internet全局路由系统所需信息的总体大小和“流失率”
o separate identifier space (EIDs) for end systems, effectively allowing "PI for all" (no renumbering cost for connectivity changes) without adding state to the global routing system
o 为终端系统提供单独的标识符空间（EID），有效地允许“PI为所有”（连接更改无需重新编号成本），而无需向全局路由系统添加状态
o improved traffic engineering capabilities that explicitly do not add state to the global routing system and whose deployment will allow active removal of the more-specific state that is currently used
o 改进的流量工程功能，明确不向全局路由系统添加状态，其部署将允许主动删除当前使用的更具体的状态
o no changes required to end systems
o 无需更改即可结束系统
o no changes to Internet "core" routers
o 互联网“核心”路由器无变化
o minimal and straightforward changes to "edge" routers
o 对“边缘”路由器进行最小且直接的更改
o day-one advantages for early adopters
o 早期采用者的第一天优势
o defined router-to-router protocol
o 定义的路由器到路由器协议
o defined database mapping system
o 定义数据库映射系统
o defined deployment plan
o 定义的部署计划
o defined interoperability/interworking mechanisms
o 定义的互操作性/互通机制
o defined scalable end-host mobility mechanisms
o 定义的可扩展终端主机移动机制
o prototype implementation already exists and is undergoing testing
o 原型实现已经存在，正在进行测试
o production implementations in progress
o 正在进行的生产实施
o mapping system infrastructure (map servers, map resolvers, Alternative Logical Topology (ALT) routers). This is considered a new potential business opportunity.
o 映射系统基础架构（映射服务器、映射解析器、可选逻辑拓扑（ALT）路由器）。这被认为是一个新的潜在商机。
o interworking infrastructure (proxy ITRs). This is considered a new potential business opportunity.
o 互通基础设施（代理ITRs）。这被认为是一个新的潜在商机。
o overhead for determining/maintaining locator/path liveness. This is a common issue for all identifier/locator separation proposals.
o 确定/维护定位器/路径活跃度的开销。这是所有标识符/定位器分离方案的常见问题。
[LISP] [LISP+ALT] [LISP-MS] [LISP-Interworking] [LISP-MN] [LIG] [LOC_ID_Implications]
[LISP][LISP+ALT][LISP-MS][LISP互通][LISP-MN][LIG][LOC\U ID\U含义]
LISP+ALT distributes mapping information to ITRs via (optional, local, potentially caching) Map Resolvers and with globally distributed query servers: ETRs and optional Map Servers (MSes).
LISP+ALT通过（可选的、本地的、可能缓存的）映射解析器以及全局分布的查询服务器（ETR和可选的映射服务器（MSE））将映射信息分发到ITRs。
A fundamental problem with any global query server network is that the frequently long paths and greater risk of packet loss may cause ITRs to drop or significantly delay the initial packets of many new sessions. ITRs drop the packet(s) they have no mapping for. After the mapping arrives, the ITR waits for a re-sent packet and will tunnel that packet correctly. These "initial-packet delays" reduce performance and so create a major barrier to voluntary adoption on a wide enough basis to solve the routing scaling problem.
任何全局查询服务器网络的一个基本问题是，频繁的长路径和较大的数据包丢失风险可能会导致ITR丢弃或显著延迟许多新会话的初始数据包。ITR丢弃它们没有映射的数据包。映射到达后，ITR等待重新发送的数据包，并将正确地对该数据包进行隧道传输。这些“初始数据包延迟”降低了性能，因此在足够广泛的基础上为自愿采用以解决路由扩展问题造成了主要障碍。
ALT's delays are compounded by its structure being "aggressively aggregated", without regard to the geographic location of the routers. Tunnels between ALT routers will often span intercontinental distances and traverse many Internet routers.
ALT的延迟因其结构“积极聚合”而变得更加复杂，不考虑路由器的地理位置。ALT路由器之间的隧道通常跨越洲际距离，并穿越许多互联网路由器。
The many levels to which a query typically ascends in the ALT hierarchy before descending towards its destination will often involve excessively long geographic paths and so worsen initial-packet delays.
查询通常在向目的地下降之前在ALT层次结构中上升到多个级别，这通常会涉及过长的地理路径，从而恶化初始数据包延迟。
No solution has been proposed for these problems or for the contradiction between the need for high aggregation while making the ALT structure robust against single points of failure.
对于这些问题或使ALT结构对单点故障具有鲁棒性的同时需要高聚合度之间的矛盾，尚未提出解决方案。
LISP's ITRs' multihoming service restoration depends on their determining the reachability of end-user networks via two or more ETRs. Large numbers of ITRs doing this is inefficient and may overburden ETRs.
LISP的ITRs的多主服务恢复取决于其通过两个或多个ETR确定最终用户网络的可达性。大量ITR这样做效率低下，可能会使ETR负担过重。
Testing reachability of the ETRs is complex and costly -- and insufficient. ITRs cannot test network reachability via each ETR, since the ITRs do not have the address of a device in each ETR's network. So, ETRs must report network unreachability to ITRs.
测试ETRs的可达性既复杂又昂贵——而且还不够。ITRs无法通过每个ETR测试网络可达性，因为ITRs没有每个ETR网络中的设备地址。因此，ETRs必须向ITRs报告网络不可达性。
LISP involves complex communication between ITRs and ETRs, with UDP and 64-bit LISP headers in all traffic packets.
LISP涉及ITRs和ETRs之间的复杂通信，所有流量数据包中都包含UDP和64位LISP头。
The advantage of LISP+ALT is that its ability to handle billions of EIDs is not constrained by the need to transmit or store the mapping to any one location. Such numbers, beyond a few tens of millions of EIDs, will only result if the system is used for mobility. Yet the concerns just mentioned about ALT's structure arise from the millions of ETRs that would be needed just for non-mobile networks.
LISP+ALT的优点是，它处理数十亿EID的能力不受将映射传输或存储到任何一个位置的需要的限制。只有当系统用于移动性时，这些数字才会超过几千万个EID。然而，刚才提到的关于ALT结构的担忧来自于非移动网络所需的数百万ETR。
In LISP's mobility approach, each Mobile Node (MN) needs an RLOC address to be its own ETR, meaning the MN cannot be behind a NAT. Mapping changes must be sent instantly to all relevant ITRs every time the MN gets a new address -- LISP cannot achieve this.
在LISP的移动性方法中，每个移动节点（MN）都需要一个RLOC地址作为其自己的ETR，这意味着MN不能位于NAT后面。每次MN获得新地址时，映射更改必须立即发送到所有相关的ITR——LISP无法实现这一点。
In order to enforce ISP filtering of incoming packets by source address, LISP ITRs would have to implement the same filtering on each decapsulated packet. This may be prohibitively expensive.
为了按源地址对传入数据包实施ISP过滤，LISP ITRs必须对每个解封数据包实施相同的过滤。这可能会非常昂贵。
LISP monolithically integrates multihoming failure detection and restoration decision-making processes into the Core-Edge Separation (CES) scheme itself. End-user networks must rely on the necessarily limited capabilities that are built into every ITR.
LISP将多归宿故障检测和恢复决策过程集成到核心边缘分离（CES）方案中。最终用户网络必须依赖于每个ITR内置的有限功能。
LISP+ALT may be able to solve the routing scaling problem, but alternative approaches would be superior because they eliminate the initial-packet delay problem and give end-user networks real-time control over ITR tunneling.
LISP+ALT可能能够解决路由扩展问题，但替代方法更为优越，因为它们消除了初始数据包延迟问题，并为最终用户网络提供了对ITR隧道的实时控制。
Initial-packet loss/delays turn out not to be a deep issue. Mechanisms for interoperation with the legacy part of the network are needed in any viably deployable design, and LISP has such mechanisms. If needed, initial packets can be sent via those legacy mechanisms until the ITR has a mapping. (Field experience has shown that the caches on those interoperation devices are guaranteed to be populated, as 'crackers' doing address-space sweeps periodically send packets to every available mapping.)
最初的数据包丢失/延迟并不是一个严重的问题。在任何可部署的设计中，都需要与网络的遗留部分进行互操作的机制，而LISP有这样的机制。如果需要，可以通过这些遗留机制发送初始数据包，直到ITR具有映射。（现场经验表明，这些互操作设备上的缓存保证会被填充，因为进行地址空间扫描的“破解者”会定期向每个可用映射发送数据包。）
On ALT issues, it is not at all mandatory that ALT be the mapping system used in the long term. LISP has a standardized mapping system interface, in part to allow reasonably smooth deployment of whatever new mapping system(s) experience might show are required. At least one other mapping system (LISP-TREE) [LISP-TREE], which avoids ALT's problems (such as query load concentration at high-level nodes), has already been laid out and extensively simulated. Exactly what mixture of mapping system(s) is optimal is not really answerable
在ALT问题上，ALT作为长期使用的映射系统完全不是强制性的。LISP有一个标准化的映射系统接口，部分是为了允许合理地顺利部署可能需要的任何新映射系统。至少有一个其他映射系统（LISP-TREE）[LISP-TREE]，它避免了ALT的问题（例如高级节点上的查询负载集中），已经部署并进行了广泛的模拟。确切地说，什么样的映射系统是最优的并不是真正的答案
without more extensive experience, but LISP is designed to allow evolutionary changes to other mapping system(s).
没有更广泛的经验，但LISP旨在允许对其他映射系统进行进化更改。
As far as ETR reachability goes, a potential problem to which there is a solution with an adequate level of efficiency, complexity, and robustness is not really a problem. LISP has a number of overlapping mechanisms that it is believed will provide adequate reachability detection (along the three axes above), and in field testing to date, they have behaved as expected.
就ETR可达性而言，一个具有足够的效率、复杂性和鲁棒性的解决方案的潜在问题并不是真正的问题。LISP有许多重叠机制，据信这些机制将提供足够的可达性检测（沿上述三个轴），并且在迄今为止的现场测试中，它们的表现与预期一致。
Operation of LISP devices behind a NAT has already been demonstrated. A number of mechanisms to update correspondent nodes when a mapping is updated have been designed (some are already in use).
NAT后面的LISP设备的操作已经过演示。已经设计了许多机制来在映射更新时更新对应节点（一些机制已经在使用中）。
Similar to Host Identity Protocol (HIP) [RFC4423], RANGI introduces a host identifier layer between the network layer and the transport layer, and the transport-layer associations (i.e., TCP connections) are no longer bound to IP addresses, but to host identifiers. The major difference from HIP is that the host identifier in RANGI is a 128-bit hierarchical and cryptographic identifier that has organizational structure. As a result, the corresponding ID->locator mapping system for such identifiers has a reasonable business model and clear trust boundaries. In addition, RANGI uses IPv4-embedded IPv6 addresses as locators. The Locator Domain Identifier (LD ID) (i.e., the leftmost 96 bits) of this locator is a provider-assigned /96 IPv6 prefix, while the last four octets of this locator are a local IPv4 address (either public or private). This special locator could be used to realize 6over4 automatic tunneling (borrowing ideas from the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]), which will reduce the deployment cost of this new routing architecture. Within RANGI, the mappings from FQDN to host identifiers are stored in the DNS system, while the mappings from host identifiers to locators are stored in a distributed ID/locator mapping system (e.g., a hierarchical Distributed Hash Table (DHT) system, or a reverse DNS system).
与主机标识协议（HIP）[RFC4423]类似，RANGI在网络层和传输层之间引入了主机标识符层，传输层关联（即TCP连接）不再绑定到IP地址，而是绑定到主机标识符。与HIP的主要区别在于RANGI中的主机标识符是一个具有组织结构的128位分层加密标识符。因此，针对此类标识符的相应ID->locator映射系统具有合理的业务模型和清晰的信任边界。此外，RANGI使用IPv4嵌入式IPv6地址作为定位器。此定位器的定位器域标识符（LD ID）（即最左边的96位）是提供商分配的/96 IPv6前缀，而此定位器的最后四个八位字节是本地IPv4地址（公共或专用）。这种特殊的定位器可用于实现6over4自动隧道（借鉴站点内自动隧道寻址协议（ISATAP）[RFC5214]的思想），这将降低这种新路由架构的部署成本。在RANGI中，从FQDN到主机标识符的映射存储在DNS系统中，而从主机标识符到定位器的映射存储在分布式ID/定位器映射系统中（例如，分层分布式哈希表（DHT）系统或反向DNS系统）。
RANGI achieves almost all of the goals set forth by RRG as follows:
RANGI几乎实现了RRG设定的所有目标，如下所示：
1. Routing Scalability: Scalability is achieved by decoupling identifiers from locators.
1. 路由可伸缩性：可伸缩性是通过将标识符与定位器分离来实现的。
2. Traffic Engineering: Hosts located in a multihomed site can suggest the upstream ISP for outbound and inbound traffic, while the first-hop Locator Domain Border Router (LDBR; i.e., site border router) has the final decision on the upstream ISP selection.
2. 流量工程：位于多宿站点的主机可以向上游ISP建议出站和入站流量，而第一跳定位域边界路由器（LDBR；即站点边界路由器）对上游ISP选择具有最终决定权。
3. Mobility and Multihoming: Sessions will not be interrupted due to locator change in cases of mobility or multihoming.
3. 移动性和多宿：在移动性或多宿情况下，会话不会因定位器更改而中断。
4. Simplified Renumbering: When changing providers, the local IPv4 addresses of the site do not need to change. Hence, the internal routers within the site don't need renumbering.
4. 简化的重新编号：更改提供程序时，不需要更改站点的本地IPv4地址。因此，站点内的内部路由器不需要重新编号。
5. Decoupling Location and Identifier: Obvious.
5. 解耦位置和标识符：显而易见。
6. Routing Stability: Since the locators are topologically aggregatable and the internal topology within the LD will not be disclosed outside, routing stability could be improved greatly.
6. 路由稳定性：由于定位器在拓扑上是可聚合的，并且LD内的内部拓扑不会对外公开，因此路由稳定性可以大大提高。
7. Routing Security: RANGI reuses the current routing system and does not introduce any new security risks into the routing system.
7. 路由安全：RANGI重用当前的路由系统，不会给路由系统带来任何新的安全风险。
8. Incremental Deployability: RANGI allows an easy transition from IPv4 networks to IPv6 networks. In addition, RANGI proxy allows RANGI-aware hosts to communicate to legacy IPv4 or IPv6 hosts, and vice versa.
8. 增量部署：RANGI允许从IPv4网络轻松过渡到IPv6网络。此外，RANGI代理允许RANGI感知主机与传统IPv4或IPv6主机通信，反之亦然。
1. A host change is required.
1. 需要更改主机。
2. The first-hop LDBR change is required to support site-controlled traffic-engineering capability.
2. 第一跳LDBR变更需要支持现场控制的交通工程能力。
3. The ID->locator mapping system is a new infrastructure to be deployed.
3. ID->locator映射系统是要部署的新基础设施。
4. RANGI proxy needs to be deployed for communication between RANGI-aware hosts and legacy hosts.
4. 需要部署RANGI代理，以便在支持RANGI的主机和遗留主机之间进行通信。
[RFC3007] [RFC4423] [RANGI] [RANGI-PROXY] [RANGI-SLIDES]
[RFC3007][RFC4423][RANGI][RANGI-PROXY][RANGI-SLIDES]
RANGI is an ID/locator split protocol that, like HIP, places a cryptographically signed ID between the network layer (IPv6) and transport. Unlike the HIP ID, the RANGI ID has a hierarchical structure that allows it to support ID->locator lookups. This hierarchical structure addresses two weaknesses of the flat HIP ID: the difficulty of doing the ID->locator lookup, and the administrative scalability of doing firewall filtering on flat IDs. The usage of this hierarchy is overloaded: it serves to make the ID unique, to drive the lookup process, and possibly other things like firewall filtering. More thought is needed as to what constitutes these levels with respect to these various roles.
RANGI是一种ID/定位器拆分协议，与HIP一样，它在网络层（IPv6）和传输层之间放置加密签名的ID。与HIP ID不同，RANGI ID具有层次结构，允许它支持ID->locator查找。这种层次结构解决了扁平HIP ID的两个弱点：执行ID->locator查找的困难，以及在扁平ID上执行防火墙过滤的管理可伸缩性。这种层次结构的使用是超负荷的：它用于使ID唯一、驱动查找过程，以及可能的防火墙过滤等其他功能。关于这些不同的角色，这些层次的构成需要更多的思考。
The RANGI document [RANGI] suggests FQDN->ID lookup through DNS, and separately an ID->locator lookup that may be DNS or may be something else (a hierarchy of DHTs). It would be more efficient if the FQDN lookup produces both ID and locators (as does the Identifier-Locator Network Protocol (ILNP)). Probably DNS alone is sufficient for the ID->locator lookup since individual DNS servers can hold very large numbers of mappings.
RANGI文档[RANGI]建议通过DNS进行FQDN->ID查找，并单独进行ID->locator查找，该查找可能是DNS，也可能是其他内容（DHT的层次结构）。如果FQDN查找同时生成ID和定位器（标识符定位器网络协议（ILNP））会更有效。可能仅DNS就足以进行ID->locator查找，因为单个DNS服务器可以保存大量映射。
RANGI provides strong sender identification, but at the cost of computing crypto. Many hosts (public web servers) may prefer to forgo the crypto at the expense of losing some functionality (receiver mobility or dynamic multihoming load balancing). While RANGI doesn't require that the receiver validate the sender, it may be good to have a mechanism whereby the receiver can signal to the sender that it is not validating, so that the sender can avoid locator changes.
RANGI提供了强大的发送者身份识别，但代价是计算密码。许多主机（公共web服务器）可能宁愿放弃加密，代价是失去一些功能（接收器移动性或动态多主负载平衡）。虽然RANGI不要求接收方验证发送方，但最好有一种机制，使接收方可以向发送方发出信号，表明其未进行验证，这样发送方就可以避免更改定位器。
Architecturally, there are many advantages to putting the mapping function at the end host (versus at the edge). This simplifies the problems of neighbor aliveness and delayed first packet, and avoids stateful middleboxes. Unfortunately, the early-adopter incentive for host upgrade may not be adequate (HIP's lack of uptake being an example).
在体系结构上，将映射功能放在终端主机（而不是边缘主机）有许多优点。这简化了邻居有效性和延迟第一个数据包的问题，并避免了有状态的中间盒。不幸的是，早期采用者对主机升级的激励可能不够充分（HIP缺乏理解就是一个例子）。
RANGI does not have an explicit solution for the mobility race condition (there is no mention of a home-agent-like device). However, host-to-host notification combined with fallback on the ID->locators lookup (assuming adequate dynamic update of the lookup system) may be good enough for the vast majority of mobility situations.
RANGI没有针对移动性竞争条件的明确解决方案（没有提到类似home agent的设备）。但是，主机到主机通知与ID->locators查找的回退（假设查找系统有足够的动态更新）相结合，对于绝大多数移动性情况可能已经足够好了。
RANGI uses proxies to deal with both legacy IPv6 and IPv4 sites. RANGI proxies have no mechanisms to deal with the edge-to-edge aliveness problem. The edge-to-edge proxy approach dirties up an otherwise clean end-to-end model.
RANGI使用代理处理传统IPv6和IPv4站点。RANGI代理没有处理边到边有效性问题的机制。边到边代理方法会弄脏原本干净的端到端模型。
RANGI exploits existing IPv6 transition technologies (ISATAP and softwire). These transition technologies are in any event being pursued outside of RRG and do not need to be specified in RANGI drafts per se. RANGI only needs to address how it interoperates with IPv4 and legacy IPv6, which it appears to do adequately well through proxies.
RANGI利用现有的IPv6过渡技术（ISATAP和softwire）。这些过渡技术在任何情况下都是在RRG之外进行的，不需要在RANGI草案本身中指定。RANGI只需要解决它如何与IPv4和旧式IPv6进行互操作的问题，它似乎通过代理做得很好。
The reason why the ID->locator lookup is separated from the FQDN->ID lookup is: 1) not all applications are tied to FQDNs, and 2) it seems unnecessary to require all devices to possess a FQDN of their own. Basically, RANGI uses DNS to realize the ID->locator mapping system. If there are too many entries to be maintained by the authoritative servers of a given Administrative Domain (AD), Distributed Hash Table (DHT) technology can be used to make these authoritative servers scale better, e.g., the mappings maintained by a given AD will be distributed among a group of authoritative servers in a DHT fashion. As a result, the robustness feature of DHT is inherited naturally into the ID->locator mapping system. Meanwhile, there is no trust issue since each AD authority runs its own DHT ring, which maintains only the mappings for those identifiers that are administrated by that AD authority.
ID->locator查找与FQDN->ID查找分开的原因是：1）并非所有应用程序都绑定到FQDN，2）似乎没有必要要求所有设备都拥有自己的FQDN。基本上，RANGI使用DNS来实现ID->locator映射系统。如果给定管理域（AD）的权威服务器要维护的条目太多，则可以使用分布式哈希表（DHT）技术使这些权威服务器更好地扩展，例如，给定AD维护的映射将以DHT方式分布在一组权威服务器之间。因此，DHT的健壮性特性自然地继承到ID->locator映射系统中。同时，不存在信任问题，因为每个广告机构都运行自己的DHT环，DHT环只维护由该广告机构管理的那些标识符的映射。
For host mobility, if communicating entities are RANGI nodes, the mobile node will notify the correspondent node of its new locator once its locator changes due to a mobility or re-homing event. Meanwhile, it should also update its locator information in the ID->locator mapping system in a timely fashion by using the Secure DNS Dynamic Update mechanism defined in [RFC3007]. In case of simultaneous mobility, at least one of the nodes has to resort to the ID->locator mapping system for resolving the correspondent node's new locator so as to continue their communication. If the correspondent node is a legacy host, Transit Proxies, which fulfill a similar function as the home agents in Mobile IP, will relay the packets between the communicating parties.
对于主机移动性，如果通信实体是RANGI节点，则一旦其定位器由于移动性或重新归宿事件而改变，移动节点将通知对应节点其新定位器。同时，还应使用[RFC3007]中定义的安全DNS动态更新机制，及时更新ID->locator mapping系统中的定位信息。在同时移动的情况下，至少一个节点必须求助于ID->locator映射系统来解析对应节点的新定位器，以便继续它们的通信。如果对应节点是传统主机，则传输代理将在通信方之间中继数据包，传输代理履行与移动IP中的归属代理类似的功能。
RANGI uses proxies (e.g., Site Proxy and Transit Proxy) to deal with both legacy IPv6 and IPv4 sites. Since proxies function as RANGI hosts, they can handle Locator Update Notification messages sent from remote RANGI hosts (or even from remote RANGI proxies) correctly. Hence, there is no edge-to-edge aliveness problem. Details will be specified in a later version of RANGI-PROXY.
RANGI使用代理（例如站点代理和传输代理）处理传统IPv6和IPv4站点。由于代理作为RANGI主机运行，它们可以正确处理从远程RANGI主机（甚至从远程RANGI代理）发送的定位器更新通知消息。因此，不存在边到边的有效性问题。详细信息将在RANGI-PROXY的更高版本中指定。
The intention behind RANGI using IPv4-embedded IPv6 addresses as locators is to reduce the total deployment cost of this new Internet architecture and to avoid renumbering the site's internal routers when such a site changes ISPs.
RANGI使用IPv4嵌入式IPv6地址作为定位器的目的是降低这种新互联网体系结构的总体部署成本，并避免在此类站点更改ISP时重新编号站点的内部路由器。
Ivip (pronounced eye-vip, est. 2007-06-15) is a Core-Edge Separation scheme for IPv4 and IPv6. It provides multihoming, portability of address space, and inbound traffic engineering for end-user networks of all sizes and types, including those of corporations, SOHO (Small Office, Home Office), and mobile devices.
Ivip（发音为EyeVIP，est.2007-06-15）是IPv4和IPv6的核心边缘分离方案。它为各种规模和类型的最终用户网络（包括公司、SOHO（小型办公室、家庭办公室）和移动设备网络）提供多归属、地址空间的可移植性和入站流量工程。
Ivip meets all the constraints imposed by the need for widespread voluntary adoption [Ivip_Constraints].
Ivip满足了广泛自愿采用的需求所施加的所有约束[Ivip_约束]。
Ivip's global fast-push mapping distribution network is structured like a cross-linked multicast tree. This pushes all mapping changes to full-database query servers (QSDs) within ISPs and end-user networks that have ITRs. Each mapping change is sent to all QSDs within a few seconds. (Note: "QSD" is from Query Server with full Database.)
Ivip的全球快速推送映射分发网络的结构类似于一个交叉链接的多播树。这会将所有映射更改推送到ISP和具有ITR的最终用户网络中的完整数据库查询服务器（QSD）。每次映射更改都会在几秒钟内发送到所有QSD。（注意：“QSD”来自具有完整数据库的查询服务器。）
ITRs gain mapping information from these local QSDs within a few tens of milliseconds. QSDs notify ITRs of changed mappings with similarly low latency. ITRs tunnel all traffic packets to the correct ETR without significant delay.
ITR在几十毫秒内从这些本地QSD获得映射信息。QSD以类似的低延迟通知ITR已更改的映射。ITRs通过隧道将所有流量数据包传输到正确的ETR，无明显延迟。
Ivip's mapping consists of a single ETR address for each range of mapped address space. Ivip ITRs do not need to test reachability to ETRs because the mapping is changed in real-time to that of the desired ETR.
Ivip映射由每个映射地址空间范围的单个ETR地址组成。Ivip ITR不需要测试ETR的可达性，因为映射会实时更改为所需ETR的映射。
End-user networks control the mapping, typically by contracting a specialized company to monitor the reachability of their ETRs, and change the mapping to achieve multihoming and/or traffic engineering (TE). So, the mechanisms that control ITR tunneling are controlled by the end-user networks in real-time and are completely separate from the Core-Edge Separation scheme itself.
最终用户网络控制映射，通常通过与专业公司签订合同来监控其ETR的可达性，并更改映射以实现多主和/或流量工程（TE）。因此，控制ITR隧道的机制由最终用户网络实时控制，并且与核心-边缘分离方案本身完全分离。
ITRs can be implemented in dedicated servers or hardware-based routers. The ITR function can also be integrated into sending hosts. ETRs are relatively simple and only communicate with ITRs rarely -- for Path MTU management with longer packets.
ITRs可以在专用服务器或基于硬件的路由器中实现。ITR功能也可以集成到发送主机中。ETR相对简单，并且很少与ITR通信——用于较长数据包的路径MTU管理。
Ivip-mapped ranges of end-user address space need not be subnets. They can be of any length, in units of IPv4 addresses or IPv6 /64s.
最终用户地址空间的Ivip映射范围不需要是子网。它们可以是任何长度，以IPv4地址或IPv6/64为单位。
Compared to conventional unscalable BGP techniques, and to the use of Core-Edge Separation architectures with non-real-time mapping systems, end-user networks will be able to achieve more flexible and responsive inbound TE. If inbound traffic is split into several streams, each to addresses in different mapped ranges, then real-time mapping changes can be used to steer the streams between multiple ETRs at multiple ISPs.
与传统的不可扩展BGP技术相比，以及与非实时映射系统一起使用核心边缘分离体系结构相比，最终用户网络将能够实现更灵活和响应更快的入站TE。如果入站流量被分成多个流，每个流指向不同映射范围内的地址，则可以使用实时映射更改在多个ISP的多个ETR之间引导流。
Default ITRs in the DFZ (DITRs; similar to LISP's Proxy Tunnel Routers) tunnel packets sent by hosts in networks that lack ITRs. So multihoming, portability, and TE benefits apply to all traffic.
DFZ（DITR；类似于LISP的代理隧道路由器）隧道数据包中的默认ITR，由缺少ITR的网络中的主机发送。因此，多主、便携性和TE优势适用于所有流量。
ITRs request mappings either directly from a local QSD or via one or more layers of caching query servers (QSCs), which in turn request it from a local QSD. QSCs are optional but generally desirable since they reduce the query load on QSDs. (Note: "QSC" is from Query Server with Cache.)
ITRs直接从本地QSD请求映射，或通过一层或多层缓存查询服务器（QSC）请求映射，后者反过来从本地QSD请求映射。QSC是可选的，但通常是可取的，因为它们减少了QSD上的查询负载。（注意：“QSC”来自带有缓存的查询服务器。）
ETRs may be in ISP or end-user networks. IP-in-IP encapsulation is used, so there is no UDP or any other header. PMTUD (Path MTU Discovery) management with minimal complexity and overhead will handle the problems caused by encapsulation, and adapt smoothly to jumbo frame paths becoming available in the DFZ. The outer header's source address is that of the sending host -- this enables existing ISP Border Router (BR) filtering of source addresses to be extended to encapsulated traffic packets by the simple mechanism of the ETR dropping packets whose inner and outer source address do not match.
ETR可能位于ISP或最终用户网络中。使用IP-in-IP封装，因此没有UDP或任何其他标头。PMTUD（Path MTU Discovery，路径MTU发现）管理以最小的复杂性和开销将处理封装引起的问题，并平滑地适应DFZ中可用的巨型帧路径。外部报头的源地址是发送主机的源地址——通过ETR丢弃内部和外部源地址不匹配的数据包的简单机制，可以将现有ISP边界路由器（BR）对源地址的过滤扩展到封装的流量数据包。
The Translating Tunnel Router (TTR) approach to mobility [Ivip_Mobility] is applicable to all Core-Edge Separation techniques and provides scalable IPv4 and IPv6 mobility in which the MN keeps its own mapped IP address(es) no matter how or where it is physically connected, including behind one or more layers of NAT.
移动性转换隧道路由器（TTR）方法[Ivip_mobility]适用于所有核心边缘分离技术，并提供可扩展的IPv4和IPv6移动性，其中MN保持其自己的映射IP地址，无论其物理连接方式或位置如何，包括在一个或多个NAT层后面。
Path lengths are typically optimal or close to optimal, and the MN communicates normally with all other non-mobile hosts (no stack or application changes), and of course other MNs. Mapping changes are only needed when the MN uses a new TTR, which would typically occur if the MN moved more than 1000 km. Mapping changes are not required when the MN changes its physical address(es).
路径长度通常是最优的或接近最优的，并且MN与所有其他非移动主机（没有堆栈或应用程序更改）以及其他MN正常通信。只有当MN使用新的TTR时才需要更改映射，如果MN移动超过1000 km，通常会发生这种情况。当MN更改其物理地址时，不需要更改映射。
Separate schemes for IPv4 and IPv6 enable tunneling from ITR to ETR without encapsulation. This will remove the encapsulation overhead and PMTUD problems. Both approaches involve modifying all routers between the ITR and ETR to accept a modified form of the IP header. These schemes require new FIB/RIB functionality in DFZ and some other routers but do not alter the BGP functions of DFZ routers.
IPv4和IPv6的单独方案支持从ITR到ETR的隧道传输，而无需封装。这将消除封装开销和PMTUD问题。这两种方法都涉及修改ITR和ETR之间的所有路由器，以接受修改后的IP报头形式。这些方案要求DFZ和其他一些路由器具有新的FIB/RIB功能，但不会改变DFZ路由器的BGP功能。
o Amenable to widespread voluntary adoption due to no need for host changes, complete support for packets sent from non-upgraded networks and no significant degradation in performance.
o 由于不需要更改主机，完全支持从未升级的网络发送的数据包，并且性能没有显著下降，因此易于广泛自愿采用。
o Modular separation of the control of ITR tunneling behavior from the ITRs and the Core-Edge Separation scheme itself: end-user networks control mapping in any way they like, in real-time.
o ITR隧道行为控制与ITR和核心边缘分离方案本身的模块化分离：终端用户网络以他们喜欢的任何方式实时控制映射。
o A small fee per mapping change deters frivolous changes and helps pay for pushing the mapping data to all QSDs. End-user networks that make frequent mapping changes for inbound TE should find these fees attractive considering how it improves their ability to utilize the bandwidth of multiple ISP links.
o 每次映射更改只需支付少量费用，就可以阻止琐碎的更改，并帮助支付将映射数据推送到所有QSD的费用。考虑到这些费用如何提高其利用多个ISP链路带宽的能力，对入站TE进行频繁映射更改的最终用户网络应该会发现这些费用很有吸引力。
o End-user networks will typically pay the cost of Open ITR in the DFZ (OITRD) forwarding to their networks. This provides a business model for OITRD deployment and avoids unfair distribution of costs.
o 最终用户网络通常将支付DFZ中开放ITR（OITRD）转发到其网络的费用。这为OITRD部署提供了一个商业模式，并避免了不公平的成本分配。
o Existing source address filtering arrangements at BRs of ISPs and end-user networks are prohibitively expensive to implement directly in ETRs, but with the outer header's source address being the same as the sending host's address, Ivip ETRs inexpensively enforce BR filtering on decapsulated packets.
o ISP和最终用户网络的BRs处的现有源地址过滤安排直接在ETR中实施成本过高，但由于外部报头的源地址与发送主机的地址相同，Ivip ETR以低廉的成本在未封装的数据包上实施BR过滤。
QSDs receive all mapping changes and store a complete copy of the mapping database. However, a worst-case scenario is 10 billion IPv6 mappings, each of 32 bytes, which fits on a consumer hard drive today and should fit in server DRAM by the time such adoption is reached.
QSD接收所有映射更改并存储映射数据库的完整副本。然而，最坏的情况是100亿个IPv6映射，每个映射有32字节，现在可以安装在消费者硬盘上，到采用这种映射时应该可以安装在服务器DRAM中。
The maximum number of non-mobile networks requiring multihoming, etc., is likely to be ~10 million, so most of the 10 billion mappings would be for mobile devices. However, TTR mobility does not involve frequent mapping changes since most MNs only rarely move more than 1000 km.
需要多宿等功能的非移动网络的最大数量可能为1000万个，因此100亿个映射中的大部分将用于移动设备。然而，TTR移动性不涉及频繁的映射更改，因为大多数MN很少移动超过1000公里。
[Ivip_EAF] [Ivip_PMTUD] [Ivip_PLF] [Ivip_Constraints] [Ivip_Mobility] [Ivip_DRTM] [Ivip_Glossary]
[Ivip_EAF][Ivip_PMTUD][Ivip_PLF][Ivip_约束][Ivip_移动性][Ivip_DRTM][Ivip_词汇表]
Looked at from the thousand-foot level, Ivip shares the basic design approaches with LISP and a number of other map-and-encap designs based on the Core-Edge Separation. However, the details differ substantially. Ivip's design makes a bold assumption that, with technology advances, one could afford to maintain a real-time distributed global mapping database for all networks and hosts. Ivip proposes that multiple parties collaborate to build a mapping distribution system that pushes all mapping information and updates to local, full-database query servers located in all ISPs within a few seconds. The system has no single point of failure and uses end-to-end authentication.
从千英尺的高度来看，Ivip与LISP以及许多其他基于核心边缘分离的地图和包裹设计共享基本设计方法。然而，细节却大不相同。Ivip的设计大胆地假设，随着技术的进步，人们可以为所有网络和主机维护一个实时分布式全局映射数据库。Ivip建议多方合作构建一个映射分发系统，在几秒钟内将所有映射信息和更新推送到位于所有ISP中的本地完整数据库查询服务器。系统没有单点故障，使用端到端身份验证。
A "real time, globally synchronized mapping database" is a critical assumption in Ivip. Using that as a foundation, Ivip design avoids several challenging design issues that others have studied extensively, that include
“实时、全局同步的映射数据库”是Ivip中的一个关键假设。以此为基础，IVIP设计避免了其他一些已经广泛研究的具有挑战性的设计问题，包括
1. special considerations of mobility support that add additional complexity to the overall system;
1. 移动支持的特殊考虑，增加了整个系统的复杂性；
2. prompt detection of ETR failures and notification to all relevant ITRs, which turns out to be a rather difficult problem; and
2. 及时检测ETR故障并通知所有相关ITR，这是一个相当困难的问题；和
3. development of a partial-mapping lookup sub-system. Ivip assumes the existence of local query servers with a full database with the latest mapping information changes.
3. 部分映射查找子系统的开发。Ivip假设存在本地查询服务器，该服务器具有一个包含最新映射信息更改的完整数据库。
To be considered as a viable solution to the Internet routing scalability problem, Ivip faces two fundamental questions. First, whether a global-scale system can achieve real-time synchronized operations as assumed by Ivip is an entirely open question. Past experiences suggest otherwise.
Ivip被认为是解决Internet路由可伸缩性问题的可行方案，它面临两个基本问题。首先，一个全球规模的系统能否实现Ivip假设的实时同步操作是一个完全开放的问题。过去的经验表明情况并非如此。
The second question concerns incremental rollout. Ivip represents an ambitious approach, with real-time mapping and local full-database query servers -- which many people regard as impossible. Developing and implementing Ivip may take a fair amount of resources, yet there is an open question regarding how to quantify the gains by first movers -- both those who will provide the Ivip infrastructure and
第二个问题涉及增量推出。Ivip代表了一种雄心勃勃的方法，具有实时映射和本地完整数据库查询服务器——许多人认为这是不可能的。开发和实施Ivip可能需要相当数量的资源，但如何量化先行者（包括提供Ivip基础设施的人和
those that will use it. Significant global routing table reduction only happens when a large enough number of parties have adopted Ivip. The same question arises for most other proposals as well.
那些将使用它的人。只有当足够多的参与方采用Ivip时，才会出现显著的全局路由表缩减。大多数其他提案也出现了同样的问题。
One belief is that Ivip's more ambitious mapping system makes a good design tradeoff for the greater benefits for end-user networks and for those that develop the infrastructure. Another belief is that this ambitious design is not viable.
一种观点认为，Ivip更雄心勃勃的映射系统为最终用户网络和开发基础设施的网络带来更大的好处，在设计上做出了很好的权衡。另一个信念是这种雄心勃勃的设计是不可行的。
Since the Summary and Critique were written, Ivip's mapping system has been significantly redesigned: DRTM - Distributed Real Time Mapping [Ivip_DRTM].
自从总结和评论被撰写之后，Ivip的绘图系统已经被显著地重新设计：DRTM-分布式实时绘图[Ivip_DRTM]。
DRTM makes it easier for ISPs to install their own ITRs. It also facilitates Mapped Address Block (MAB) operating companies -- which need not be ISPs -- leasing Scalable Provider-Independent (SPI) address space to end-user networks with almost no ISP involvement. ISPs need not install ITRs or ETRs. For an ISP to support its customers using SPI space, they need only allow the forwarding of outgoing packets whose source addresses are from SPI space. End-user networks can implement their own ETRs on their existing PA address(es) -- and MAB operating companies make all the initial investments.
DRTM使ISP更容易安装自己的ITR。它还方便了映射地址块（MAB）运营公司（不必是ISP）将可扩展的独立提供商（SPI）地址空间租赁给终端用户网络，而几乎没有ISP的参与。ISP不需要安装ITRs或ETRs。为了让ISP支持其客户使用SPI空间，他们只需要允许转发源地址来自SPI空间的传出数据包。最终用户网络可以在其现有PA地址上实施自己的ETR——MAB运营公司进行所有初始投资。
Once SPI adoption becomes widespread, ISPs will be motivated to install their own ITRs to locally tunnel packets that are sent from customer networks and that must be tunneled to SPI-using customers of the same ISP -- rather than letting these packets exit the ISP's network and return in tunnels to ETRs in the network.
一旦SPI被广泛采用，ISP将被激励安装自己的ITR到从客户网络发送的本地隧道数据包中，这些数据包必须使用同一ISP的客户通过隧道传输到SPI，而不是让这些数据包退出ISP的网络并通过隧道返回网络中的ETR。
There is no need for full-database query servers in ISPs or for any device that stores the full mapping information for all Mapped Address Blocks (MABs). ISPs that want ITRs will install two or more Map Resolver (MR) servers. These are caching query servers which query multiple (typically nearby) query servers that are full-database for the subset of MABs they serve. These "nearby" query servers will be at DITR sites, which will be run by, or for, MAB operating companies who lease MAB space to large numbers of end-user networks. These DITR-site servers will usually be close enough to the MRs to generate replies with sufficiently low delay and risk of packet loss for ITRs to buffer initial packets for a few tens of milliseconds while the mapping arrives.
ISP中不需要完整的数据库查询服务器，也不需要存储所有映射地址块（MAB）的完整映射信息的任何设备。需要ITRs的ISP将安装两个或多个地图解析器（MR）服务器。这些是缓存查询服务器，用于查询多个（通常在附近）查询服务器，这些服务器是它们所服务的MAB子集的完整数据库。这些“附近”的查询服务器将位于DITR站点，由向大量最终用户网络租赁MAB空间的MAB运营公司或为其运营。这些DITR站点服务器通常离MRs足够近，以便生成具有足够低延迟和数据包丢失风险的回复，以便ITR在映射到达时将初始数据包缓冲几十毫秒。
DRTM will scale to billions of micronets, tens of thousands of MABs, and potentially hundreds of MAB operating companies, without single points of failure or central coordination.
DRTM将扩展到数十亿微米，数万个MAB，以及可能的数百个MAB运营公司，无需单点故障或集中协调。
The critique implies a threshold of adoption is required before significant routing scaling benefits occur. This is untrue of any Core-Edge Separation proposal, including LISP and Ivip. Both can achieve scalable routing benefits in direct proportion to their level of adoption by providing portability, multihoming, and inbound TE to large numbers of end-user networks.
批评意味着，在出现显著的路由扩展效益之前，需要有一个采用门槛。这不符合任何核心边缘分离方案，包括LISP和Ivip。通过向大量终端用户网络提供可移植性、多宿和入站TE，两者都可以实现与采用程度成正比的可扩展路由优势。
Core-Edge Elimination (CEE) architectures require all Internet communications to change to IPv6 with a new locator/identifier separation naming model. This would impose burdens of extra management effort, packets, and session establishment delays on all hosts -- which is a particularly unacceptable burden on battery-operated mobile hosts that rely on wireless links.
核心边缘消除（CEE）体系结构要求所有互联网通信使用新的定位器/标识符分离命名模型更改为IPv6。这将给所有主机带来额外的管理工作、数据包和会话建立延迟的负担——这对于依赖无线链路的电池供电移动主机来说是一个特别不可接受的负担。
Core-Edge Separation architectures retain the current, efficient, naming model, require no changes to hosts, and support both IPv4 and IPv6. Ivip is the most promising architecture for future development because its scalable, distributed, real-time mapping system best supports TTR mobility, enables ITRs to be simpler, and gives real-time control of ITR tunneling to the end-user network or to organizations they appoint to control the mapping of their micronets.
核心边缘分离体系结构保留了当前高效的命名模型，不需要更改主机，并且支持IPv4和IPv6。Ivip是未来发展中最有希望的体系结构，因为其可扩展、分布式、实时映射系统最好地支持TTR移动性，使ITR更简单，并将ITR隧道的实时控制提供给最终用户网络或他们指定的组织，以控制其微网的映射。
The Hierarchical IPv4 Framework (hIPv4) adds scalability to the routing architecture by introducing additional hierarchy in the IPv4 address space. The IPv4 addressing scheme is divided into two parts, the Area Locator (ALOC) address space, which is globally unique, and the Endpoint Locator (ELOC) address space, which is only regionally unique. The ALOC and ELOC prefixes are added as a shim header between the IP header and transport protocol header; the shim header is identified with a new protocol number in the IP header. Instead of creating a tunneling (i.e., overlay) solution, a new routing element is needed in the service provider's routing domain (called ALOC realm) -- a Locator Swap Router. The current IPv4 forwarding plane remains intact, and no new routing protocols, mapping systems, or caching solutions are required. The control plane of the ALOC realm routers needs some modification in order for ICMP to be compatible with the hIPv4 framework. When an area (one or several autonomous systems (ASes)) of an ISP has transformed into an ALOC realm, only ALOC prefixes are exchanged with other ALOC realms. Directly attached ELOC prefixes are only inserted to the RIB of the local ALOC realm; ELOC prefixes are not distributed to the DFZ. Multihoming can be achieved in two ways, either the enterprise
分层IPv4框架（hIPv4）通过在IPv4地址空间中引入额外的层次结构，为路由体系结构增加了可伸缩性。IPv4寻址方案分为两部分：全局唯一的区域定位器（ALOC）地址空间和仅在区域上唯一的端点定位器（ELOC）地址空间。ALOC和ELOC前缀被添加为IP报头和传输协议报头之间的垫片报头；垫片头在IP头中用一个新的协议号标识。与创建隧道（即覆盖）解决方案不同，服务提供商的路由域（称为ALOC领域）中需要一个新的路由元素——定位器交换路由器。当前IPv4转发平面保持不变，不需要新的路由协议、映射系统或缓存解决方案。ALOC领域路由器的控制平面需要一些修改，以便ICMP与hIPv4框架兼容。当ISP的一个区域（一个或多个自治系统（ASes））转换为ALOC领域时，只有ALOC前缀与其他ALOC领域交换。直接附加的ELOC前缀仅插入到本地ALOC域的肋骨上；ELOC前缀不会分发到DFZ。多归属可以通过两种方式实现，一种是企业
requests an ALOC prefix from the RIR (this is not recommended) or the enterprise receives the ALOC prefixes from their upstream ISPs. ELOC prefixes are PI addresses and remain intact when an upstream ISP is changed; only the ALOC prefix is replaced. When the RIB of the DFZ is compressed (containing only ALOC prefixes), ingress routers will no longer know the availability of the destination prefix; thus, the endpoints must take more responsibility for their sessions. This can be achieved by using multipath enabled transport protocols, such as SCTP [RFC4960] and Multipath TCP (MPTCP) [MPTCP_Arch], at the endpoints. The multipath transport protocols also provide a session identifier, i.e., verification tag or token; thus, the location and identifier split is carried out -- site mobility, endpoint mobility, and mobile site mobility are achieved. DNS needs to be upgraded: in order to resolve the location of an endpoint, the endpoint must have one ELOC value (current A-record) and at least one ALOC value in DNS (in multihoming solutions there will be several ALOC values for an endpoint).
从RIR请求ALOC前缀（不建议这样做），或者企业从其上游ISP接收ALOC前缀。ELOC前缀是PI地址，在上游ISP发生变化时保持不变；仅替换ALOC前缀。当DFZ的RIB被压缩时（仅包含ALOC前缀），入口路由器将不再知道目的前缀的可用性；因此，端点必须对其会话承担更多的责任。这可以通过在端点使用支持多路径的传输协议来实现，如SCTP[RFC4960]和多路径TCP（MPTCP）[MPTCP_Arch]。多路径传输协议还提供会话标识符，即验证标签或令牌；因此，进行了位置和标识符拆分——实现了站点移动性、端点移动性和移动站点移动性。DNS需要升级：为了解析端点的位置，端点必须在DNS中有一个ELOC值（当前A记录）和至少一个ALOC值（在多宿主解决方案中，端点将有多个ALOC值）。
1. Improved routing scalability: Adding additional hierarchy to the address space enables more hierarchy in the routing architecture. Early adapters of an ALOC realm will no longer carry the current RIB of the DFZ -- only ELOC prefixes of their directly attached networks and ALOC prefixes from other service providers that have migrated are installed in the ALOC realm's RIB.
1. 改进的路由可伸缩性：向地址空间添加额外的层次结构可以在路由体系结构中实现更多层次结构。ALOC领域的早期适配器将不再携带DFZ的当前RIB——只有其直接连接网络的ELOC前缀和已迁移的其他服务提供商的ALOC前缀安装在ALOC领域的RIB中。
2. Scalable support for traffic engineering: Multipath enabled transport protocols are recommended to achieve dynamic load-balancing of a session. Support for Valiant Load-balancing (VLB) [Valiant] schemes has been added to the framework; more research work is required around VLB switching.
2. 对流量工程的可扩展支持：建议使用支持多路径的传输协议来实现会话的动态负载平衡。框架中增加了对Valiant负载平衡（VLB）[Valiant]方案的支持；围绕VLB交换需要更多的研究工作。
3. Scalable support for multihoming: Only attachment points of a multihomed site are advertised (using the ALOC prefix) in the DFZ. DNS will inform the requester on how many attachment points the destination endpoint has. It is the initiating endpoint's choice/responsibility to choose which attachment point is used for the session; endpoints using multipath-enabled transport protocols can make use of several attachment points for a session.
3. 对多宿主的可扩展支持：在DFZ中只公布多宿主站点的连接点（使用ALOC前缀）。DNS将通知请求者目标端点有多少个连接点。发起端点的选择/责任是选择会话使用的连接点；使用支持多路径传输协议的端点可以为会话使用多个连接点。
4. Simplified Renumbering: When changing provider, the local ELOC prefixes remains intact; only the ALOC prefix is changed at the endpoints. The ALOC prefix is not used for routing or forwarding decisions in the local network.
4. 简化重新编号：更改提供程序时，本地ELOC前缀保持不变；在端点处仅更改ALOC前缀。ALOC前缀不用于本地网络中的路由或转发决策。
5. Decoupling Location and Identifier: The verification tag (SCTP) and token (MPTCP) can be considered to have the characteristics of a session identifier, and thus a session layer is created between the transport and application layers in the TCP/IP model.
5. 解耦位置和标识符：验证标记（SCTP）和令牌（MPTCP）可以被视为具有会话标识符的特征，因此在TCP/IP模型的传输层和应用层之间创建了会话层。
6. Routing quality: The hIPv4 framework introduces no tunneling or caching mechanisms. Only a swap of the content in the IPv4 header and locator header at the destination ALOC realm is required; thus, current routing and forwarding algorithms are preserved as such. Valiant Load-balancing might be used as a new forwarding mechanism.
6. 路由质量：hIPv4框架不引入隧道或缓存机制。只需要在目标ALOC领域交换IPv4标头和定位器标头中的内容；因此，当前的路由和转发算法被保留下来。Valiant负载平衡可以用作一种新的转发机制。
7. Routing Security: Similar as with today's DFZ, except that ELOC prefixes cannot be hijacked (by injecting a longest match prefix) outside an ALOC realm.
7. 路由安全性：与今天的DFZ类似，只是ELOC前缀不能在ALOC领域之外被劫持（通过注入最长的匹配前缀）。
8. Deployability: The hIPv4 framework is an evolution of the current IPv4 framework and is backwards compatible with the current IPv4 framework. Sessions in a local network and inside an ALOC realm might in the future still use the current IPv4 framework.
8. 可部署性：hIPv4框架是当前IPv4框架的演变，与当前IPv4框架向后兼容。本地网络和ALOC领域内的会话将来可能仍然使用当前的IPv4框架。
1. Upgrade of the stack at an endpoint that is establishing sessions outside the local ALOC realm.
1. 升级在本地ALOC领域之外建立会话的端点处的堆栈。
2. In a multihoming solution, the border routers should be able to apply policy-based routing upon the ALOC value in the locator header.
2. 在多宿主解决方案中，边界路由器应能够根据定位器报头中的ALOC值应用基于策略的路由。
3. New IP allocation policies must be set by the RIRs.
3. RIRs必须设置新的IP分配策略。
4. There is a short timeframe before the expected depletion of the IPv4 address space occurs.
4. 在IPv4地址空间出现预期耗尽之前，有一段很短的时间。
5. Will enterprises give up their current globally unique IPv4 address block allocation they have gained?
5. 企业是否会放弃目前获得的全球唯一IPv4地址块分配？
6. Coordination with MPTCP is highly desirable.
6. 与邮电部协调是非常可取的。
[hIPv4] [Valiant]
[hIPv4][Valiant]
hIPv4 is an innovative approach to expanding the IPv4 addressing system in order to resolve the scalable routing problem. This critique does not attempt a full assessment of hIPv4's architecture and mechanisms. The only question addressed here is whether hIPv4 should be chosen for IETF development in preference to, or together with, the only two proposals which appear to be practical solutions for IPv4: Ivip and LISP.
hIPv4是扩展IPv4寻址系统以解决可扩展路由问题的一种创新方法。本评论并不试图对hIPv4的架构和机制进行全面评估。这里讨论的唯一问题是，是否应选择hIPv4作为IETF开发的首选方案，或者与仅有的两个似乎是IPv4实用解决方案的方案（Ivip和LISP）一起使用。
Ivip and LISP appear to have a major advantage over hIPv4 in terms of support for packets sent from non-upgraded hosts/networks. Ivip's DITRs (Default ITRs in the DFZ) and LISP's PTRs (Proxy Tunnel Routers) both accept packets sent by any non-upgraded host/network and tunnel them to the correct ETR -- thus providing the full benefits of portability, multihoming, and inbound TE for these packets as well as those sent by hosts in networks with ITRs. hIPv4 appears to have no such mechanism, so these benefits are only available for communications between two upgraded hosts in upgraded networks.
就支持从未升级的主机/网络发送的数据包而言，Ivip和LISP似乎比hIPv4具有主要优势。Ivip的DITR（DFZ中的默认ITR）和LISP的PTR（代理隧道路由器）都接受任何未升级的主机/网络发送的数据包，并通过隧道将它们传输到正确的ETR——从而为这些数据包以及由具有ITR的网络中的主机发送的数据包提供了可移植性、多宿主和入站TE的全部好处。hIPv4似乎没有这样的机制，因此这些好处仅适用于升级网络中两个升级主机之间的通信。
This means that significant benefits for adopters -- the ability to rely on the new system to provide the portability, multihoming, and inbound TE benefits for all, or almost all, their communications -- will only arise after all, or almost all, networks upgrade their networks, hosts, and addressing arrangements. hIPv4's relationship between adoption levels and benefits to any adopter therefore are far less favorable to widespread adoption than those of Core-Edge Separation (CES) architectures such as Ivip and LISP.
这意味着，只有在所有或几乎所有网络升级其网络、主机和寻址安排后，采用者才能获得显著的好处，即依靠新系统为所有或几乎所有通信提供便携性、多主和入站TE好处。因此，与Ivip和LISP等核心边缘分离（CES）体系结构相比，hIPv4的采用水平与任何采用者的利益之间的关系对广泛采用的有利程度要低得多。
This results in hIPv4 also being at a disadvantage regarding the achievement of significant routing scaling benefits, which likewise will only result once adoption is close to ubiquitous. Ivip and LISP can provide routing scaling benefits in direct proportion to their level of adoption, since all adopters gain full benefits for all their communications, in a highly scalable manner.
这导致hIPv4在实现显著的路由扩展优势方面也处于劣势，这同样只会在采用接近普遍时才会产生。Ivip和LISP可以提供与其采用程度成正比的路由扩展好处，因为所有采用者都可以以高度可扩展的方式获得其所有通信的全部好处。
hIPv4 requires stack upgrades, which are not required by any CES architecture. Furthermore, a large number of existing IPv4 application protocols convey IP addresses between hosts in a manner that will not work with hIPv4: "There are several applications that are inserting IP address information in the payload of a packet. Some applications use the IP address information to create new sessions or for identification purposes. This section is trying to list the applications that need to be enhanced; however, this is by no means a comprehensive list" [hIPv4].
hIPv4需要堆栈升级，这是任何CES体系结构都不需要的。此外，大量现有的IPv4应用程序协议以一种不适用于hIPv4的方式在主机之间传输IP地址：“有几个应用程序正在数据包的有效负载中插入IP地址信息。某些应用程序使用IP地址信息创建新会话或用于识别目的。本节试图列出需要增强的应用程序；然而，这绝不是一份全面的清单“[hIPv4]。
If even a few widely used applications would need to be rewritten to operate successfully with hIPv4, then this would be such a disincentive to adoption to rule out hIPv4 ever being adopted widely enough to solve the routing scaling problem, especially since CES architectures fully support all existing protocols, without the need for altering host stacks.
如果即使是一些广泛使用的应用程序也需要重写才能成功使用hIPv4，那么这将阻碍采用hIPv4，从而排除hIPv4被广泛采用以解决路由扩展问题，特别是因为CES体系结构完全支持所有现有协议，无需更改主机堆栈。
It appears that hIPv4 involves major practical difficulties, which mean that in its current form it is not suitable for IETF development.
hIPv4似乎涉及重大的实际困难，这意味着它目前的形式不适合IETF的开发。
No rebuttal was submitted for this proposal.
没有人对这项提议提出反驳。
The basic idea is to add a name overlay (NOL) onto the existing TCP/IP stack.
基本思想是在现有TCP/IP堆栈上添加名称覆盖（NOL）。
Its functions include:
其职能包括：
1. Managing host name configuration, registration, and authentication;
1. 管理主机名配置、注册和身份验证；
2. Initiating and managing transport connection channels (i.e., TCP/IP connections) by name;
2. 按名称启动和管理传输连接通道（即TCP/IP连接）；
3. Keeping application data transport continuity for mobility.
3. 保持应用程序数据传输的连续性以实现移动性。
At the edge network, we introduce a new type of gateway, a Name Transfer Relay (NTR), which blocks the PI addresses of edge networks into upstream transit networks. NTRs perform address and/or port translation between blocked PI addresses and globally routable addresses, which seem like today's widely used NAT / Network Address Port Translation (NAPT) devices. Both legacy and NOL applications behind a NTR can access the outside as usual. To access the hosts behind a NTR from outside, we need to use NOL to traverse the NTR by name and initiate connections to the hosts behind it.
在边缘网络中，我们引入了一种新型的网关，名称传输中继（NTR），它将边缘网络的PI地址阻塞到上游传输网络中。NTR在阻塞的PI地址和全局可路由地址之间执行地址和/或端口转换，这似乎是当今广泛使用的NAT/网络地址端口转换（NAPT）设备。NTR后面的传统和NOL应用程序都可以像往常一样访问外部。要从外部访问NTR后面的主机，我们需要使用NOL按名称遍历NTR，并启动到NTR后面主机的连接。
Different from proposed host-based ID/locator split solutions, such as HIP, Shim6, and name-oriented stack, NOL doesn't need to change the existing TCP/IP stack, sockets, or their packet formats. NOL can coexist with the legacy infrastructure, and the Core-Edge Separation solutions (e.g., APT, LISP, Six/One, Ivip, etc.).
与建议的基于主机的ID/locator拆分解决方案（如HIP、Shim6和面向名称的堆栈）不同，NOL不需要更改现有的TCP/IP堆栈、套接字或其数据包格式。NOL可以与传统基础设施和核心边缘分离解决方案（如APT、LISP、六/一、Ivip等）共存。
1. Reduce routing table size: Prevent edge network PI address from leaking into the transit network by deploying gateway NTRs.
1. 减少路由表大小：通过部署网关NTR防止边缘网络PI地址泄漏到传输网络中。
2. Traffic Engineering: For legacy and NOL application sessions, the incoming traffic can be directed to a specific NTR by DNS. In addition, for NOL applications, initial sessions can be redirected from one NTR to other appropriate NTRs. These mechanisms provide some support for traffic engineering.
2. 流量工程：对于传统和NOL应用程序会话，传入的流量可以通过DNS定向到特定的NTR。此外，对于NOL应用程序，初始会话可以从一个NTR重定向到其他适当的NTR。这些机制为流量工程提供了一些支持。
3. Multihoming: When a PI addressed network connects to the Internet by multihoming with several providers, it can deploy NTRs to prevent the PI addresses from leaking into provider networks.
3. 多宿：当一个PI寻址网络通过多个提供商的多宿连接到Internet时，它可以部署NTR以防止PI地址泄漏到提供商网络中。
4. Transparency: NTRs can be allocated PA addresses from the upstream providers and store them in NTRs' address pool. By DNS query or NOL session, any session that wants to access the hosts behind the NTR can be delegated to a specific PA address in the NTR address pool.
4. 透明度：NTR可以从上游提供商处分配PA地址，并将其存储在NTR的地址池中。通过DNS查询或NOL会话，任何想要访问NTR后面主机的会话都可以委托给NTR地址池中的特定PA地址。
5. Mobility: The NOL layer manages the traditional TCP/IP transport connections, and provides application data transport continuity by checkpointing the transport connection at sequence number boundaries.
5. 移动性：NOL层管理传统的TCP/IP传输连接，并通过在序列号边界检查传输连接来提供应用程序数据传输连续性。
6. No need to change TCP/IP stack, sockets, or DNS system.
6. 无需更改TCP/IP堆栈、套接字或DNS系统。
7. No need for extra mapping system.
7. 不需要额外的映射系统。
8. NTR can be deployed unilaterally, just like NATs.
8. NTR可以像NAT一样单方面部署。
9. NOL applications can communicate with legacy applications.
9. NOL应用程序可以与遗留应用程序通信。
10. NOL can be compatible with existing solutions, such as APT, LISP, Ivip, etc.
10. NOL可以与现有解决方案兼容，如APT、LISP、Ivip等。
11. End-user-controlled multipath indirect routing based on distributed NTRs. This will give benefits to the performance-aware applications, such as video streaming, applications on MSN.com, etc.
11. 最终用户控制的基于分布式NTR的多径间接路由。这将为性能感知应用程序带来好处，如视频流、MSN.com上的应用程序等。
1. Legacy applications have trouble with initiating access to the servers behind NTR. Such trouble can be resolved by deploying the NOL proxy for legacy hosts, or delegating globally routable PA addresses in the NTR address pool for these servers, or deploying a proxy server outside the NTR.
1. 遗留应用程序在启动对NTR后面的服务器的访问时遇到问题。通过为遗留主机部署NOL代理，或在这些服务器的NTR地址池中委派全局可路由PA地址，或在NTR之外部署代理服务器，可以解决此类问题。
2. NOL may increase the number of entries in DNS, but it is not drastic because it only increases the number of DNS records at domain granularity not the number of hosts. The name used in NOL, for example, is similar to an email address hostname@example.net. The needed DNS entries and query are just for "example.net", and the NTR knows the "hostnames". Not only will the number of DNS records be increased, but the dynamics of DNS might be agitated as well. However, the scalability and performance of DNS are guaranteed by its naming hierarchy and caching mechanisms.
2. NOL可能会增加DNS中的条目数，但这并不严重，因为它只会增加域粒度上的DNS记录数，而不会增加主机数。例如，NOL中使用的名称类似于电子邮件地址hostname@example.net. 所需的DNS条目和查询仅针对“example.net”，NTR知道“主机名”。不仅DNS记录的数量会增加，而且DNS的动态也可能会受到影响。然而，DNS的可伸缩性和性能是由其命名层次结构和缓存机制保证的。
3. Address translating/rewriting costs on NTRs.
3. 解决NTR上的翻译/重写成本。
No references were submitted.
没有提交任何参考资料。
1. Applications on hosts need to be rebuilt based on a name overlay library to be NOL-enabled. The legacy software that is not maintained will not be able to benefit from NOL in the Core-Edge Elimination situation. In the Core-Edge Separation scheme, a new gateway NTR is deployed to prevent edge-specific PI prefixes from leaking into the transit core. NOL doesn't impede the legacy endpoints behind the NTR from accessing the outside Internet, but the legacy endpoints cannot access or will have difficultly accessing the endpoints behind a NTR without the help of NOL.
1. 主机上的应用程序需要基于要启用NOL的名称覆盖库重建。在核心边缘消除情况下，未维护的遗留软件将无法从NOL中获益。在核心-边缘分离方案中，部署了一个新的网关NTR，以防止特定于边缘的PI前缀泄漏到传输核心中。NOL不会阻止NTR后面的传统端点访问外部Internet，但如果没有NOL的帮助，传统端点无法访问或将很难访问NTR后面的端点。
2. In the case of Core-Edge Elimination, the end site will be assigned multiple PA address spaces, which leads to renumbering troubles when switching to other upstream providers. Upgrading endpoints to support NOL doesn't give any benefits to edge networks. Endpoints have little incentive to use NOL in a Core-Edge Elimination scenario, and the same is true with other host-based ID/locator split proposals. Whether they are IPv4 or IPv6 networks, edge networks prefer PI address space to PA address space.
2. 在核心边缘消除的情况下，终端站点将被分配多个PA地址空间，这导致在切换到其他上游提供商时出现重新编号问题。升级端点以支持NOL不会给边缘网络带来任何好处。端点在核心边缘消除方案中使用NOL的动机很小，其他基于主机的ID/定位器拆分方案也是如此。无论是IPv4还是IPv6网络，边缘网络都更喜欢PI地址空间而不是PA地址空间。
3. In the Core-Edge Separation scenario, the additional gateway NTR is to prevent the specific prefixes from the edge networks, just like a NAT or the ITR/ETR of LISP. A NTR gateway can be seen as an extension of NAT (Network Address Translation). Although NATs are deployed widely, upgrading them to support NOL extension or deploying additional new gateway NTRs at the edge networks is on a voluntary basis and has few economic incentives.
3. 在核心边缘分离场景中，额外的网关NTR用于防止来自边缘网络的特定前缀，就像NAT或LISP的ITR/ETR一样。NTR网关可以看作是NAT（网络地址转换）的扩展。虽然NAT被广泛部署，但升级NAT以支持NOL扩展或在边缘网络上部署额外的新网关NTR是自愿的，并且没有多少经济激励。
4. The stateful or stateless translation for each packet traversing a NTR will require the cost of the CPU and memory of NTRs, and increase forwarding delay. Thus, it is not appropriate to deploy NTRs at the high-level transit networks where aggregated traffic may cause congestion at the NTRs.
4. 通过NTR的每个数据包的有状态或无状态转换将需要NTR的CPU和内存成本，并增加转发延迟。因此，在高级别公交网络上部署NTR是不合适的，因为聚集的交通量可能会导致NTR的拥塞。
5. In the Core-Edge Separation scenario, the requirement for multihoming and inter-domain traffic engineering will make end sites accessible via multiple different NTRs. For reliability, all of the associations between multiple NTRs and the end site name will be kept in DNS, which may increase the load on DNS.
5. 在核心边缘分离场景中，多主和域间流量工程的要求将使终端站点可以通过多个不同的NTR访问。为了可靠性，多个NTR和终端站点名称之间的所有关联将保留在DNS中，这可能会增加DNS上的负载。
6. To support mobility, it is necessary for DNS to update the corresponding name-NTR mapping records when an end system moves from behind one NTR to another NTR. The NOL-enabled end relies on the NOL layer to preserve the continuity of the transport layer, since the underlying TCP/UDP transport session would be broken when the IP address changed.
6. 为了支持移动性，当终端系统从一个NTR后面移动到另一个NTR时，DNS有必要更新相应的名称NTR映射记录。启用NOL的端依赖NOL层来保持传输层的连续性，因为当IP地址更改时，底层TCP/UDP传输会话将中断。
NOL resembles neither CEE nor CES as a solution. By supporting application-level sessions through the name overlay layer, NOL can support some solutions in the CEE style. However, NOL is in general closer to CES solutions, i.e., preventing PI prefixes of edge networks from entering into the upstream transit networks. This is done by the NTR, like the ITRs/ETRs in CES solutions, but NOL has no need to define the clear boundary between core and edge networks. NOL is designed to try to provide end users or networks a service that facilitates the adoption of multihoming, multipath routing, and traffic engineering by the indirect routing through NTRs, and that, in the mean time, doesn't accelerate or decelerate the growth of global routing table size.
NOL既不像CEE，也不像CES。通过名称覆盖层支持应用程序级会话，NOL可以支持CEE风格的一些解决方案。然而，NOL通常更接近CES解决方案，即防止边缘网络的PI前缀进入上游公交网络。这是由NTR完成的，就像CES解决方案中的ITRs/ETRs一样，但NOL不需要定义核心网络和边缘网络之间的清晰边界。NOL旨在通过NTR的间接路由，为最终用户或网络提供一种服务，以促进多归属、多路径路由和流量工程的采用，同时不会加速或减缓全局路由表大小的增长。
Some problems are described in the NOL critique. In the original NOL proposal document, the DNS query for a host that is behind a NTR will induce the return of the actual IP addresses of the host and the address of the NTR. This arrangement might cause some difficulties for legacy applications due to the non-standard response from DNS. To resolve this problem, we instead have the NOL service use a new
NOL评论中描述了一些问题。在原始NOL提案文档中，对NTR后面的主机的DNS查询将返回主机的实际IP地址和NTR的地址。由于DNS的非标准响应，这种安排可能会给遗留应用程序带来一些困难。为了解决这个问题，我们让NOL服务使用新的
namespace, and have DNS not return NTR IP addresses for the legacy hosts. The names used for NOL are formatted like email addresses, such as "des@example.net". The mapping between "example.net" and the IP address of the corresponding NTR will be registered in DNS. The NOL layer will understand the meaning of the name "des@example.net" , and it will send a query to DNS only for "example.net". DNS will then return IP addresses of the corresponding NTRs. Legacy applications will still use the traditional FQDN name, and DNS will return the actual IP address of the host. However, if the host is behind a NTR, the legacy applications may be unable to access the host.
命名空间，并且DNS不返回旧主机的NTR IP地址。NOL使用的名称格式类似于电子邮件地址，例如“des@example.net". “example.net”与相应NTR的IP地址之间的映射将在DNS中注册。NOL层将理解名称的含义”des@example.net，它将只向DNS发送“example.net”的查询。然后，DNS将返回相应NTR的IP地址。遗留应用程序仍将使用传统的FQDN名称，DNS将返回主机的实际IP地址。但是，如果主机位于NTR后面，则遗留应用程序可能无法访问主机。
The stateless address translation or stateful address and port translation may cause a scaling problem with the number of table entries NTR must maintain, and legacy applications cannot initiate sessions with hosts inside the NOL-adopting End User Network (EUN). However, these problems may not be a big barrier for the deployment of NOL or other similar approaches. Many NAT-like boxes, proxy, and firewall devices are widely used at the ingress/egress points of enterprise networks, campus networks, or other stub EUNs. The hosts running as servers can be deployed outside NTRs or can be assigned PA addresses in an NTR-adopting EUN.
无状态地址转换或有状态地址和端口转换可能会导致NTR必须维护的表条目数量的缩放问题，并且遗留应用程序无法启动与最终用户网络（EUN）内主机的会话。然而，这些问题可能不是部署NOL或其他类似方法的一大障碍。许多类似NAT的盒子、代理和防火墙设备广泛用于企业网络、校园网络或其他网络的入口/出口点。作为服务器运行的主机可以部署在NTR外部，也可以在采用EUN的NTR中分配PA地址。
This proposal (referred to here as "CRM") is to build a highly scalable locator identity mapping system using compact routing principles. This provides the means for dynamic topology adaption to facilitate efficient aggregation [CRM]. Map servers are assigned as cluster heads or landmarks based on their capability to aggregate EID announcements.
该提案（此处称为“CRM”）旨在使用紧凑的路由原则构建一个高度可扩展的定位器身份映射系统。这提供了动态拓扑自适应的方法，以促进高效聚合[CRM]。地图服务器根据其聚合EID公告的能力被指定为集群头或地标。
o Minimizes the routing table sizes at the system level (i.e., map servers). Provides clear upper bounds for routing stretch that define the packet delivery delay of the map request / first packet.
o 最小化系统级（即地图服务器）的路由表大小。为定义map请求/第一个数据包的数据包传递延迟的路由延伸提供明确的上限。
o Organizes the mapping system based on the EID numbering space, minimizes the administrative overhead of managing the EID space. No need for administratively planned hierarchical address allocation as the system will find convergence into a set of EID allocations.
o 根据EID编号空间组织映射系统，将管理EID空间的管理开销降至最低。不需要管理性计划的分层地址分配，因为系统将收敛到一组EID分配中。
o Availability and robustness of the overall routing system (including xTRs and map servers) are improved because of the potential to use multiple map servers and direct routes without the involvement of map servers.
o 由于可以在不涉及地图服务器的情况下使用多个地图服务器和直接路由，因此提高了整个路由系统（包括XTR和地图服务器）的可用性和健壮性。
The scalability gains will materialize only in large deployments. If the stretch is bounded to those of compact routing (worst-case stretch less or equal to 3, on average, 1+epsilon), then each xTR needs to have memory/cache for the mappings of its cluster.
可扩展性的提高只会在大型部署中实现。如果拉伸限制在紧凑路由的范围内（最坏情况下拉伸小于或等于3，平均为1+ε），那么每个xTR都需要为其集群的映射提供内存/缓存。
[CRM]
[客户关系管理]
The CRM proposal is not a complete proposal and therefore cannot be considered for further development by the IETF as a scalable routing solution.
CRM提案不是一个完整的提案，因此IETF不能将其作为可扩展路由解决方案进行进一步开发。
While Compact Routing principles may be able to improve a mapping overlay structure such as LISP+ALT, there are several objections to this approach.
虽然紧凑路由原则可能能够改进映射覆盖结构，如LISP+ALT，但这种方法存在一些反对意见。
Firstly, a CRM-modified ALT structure would still be a global query server system. No matter how ALT's path lengths and delays are optimized, there is a problem with a querier -- which could be anywhere in the world -- relying on mapping information from one or ideally two or more authoritative query servers, which could also be anywhere in the world. The delays and risks of packet loss that are inherent in such a system constitute a fundamental problem. This is especially true when multiple, potentially long, traffic streams are received by ITRs and forwarded over the CRM networks for delivery to the destination network. ITRs must use the CRM infrastructure while they are awaiting a map reply. The traffic forwarded on the CRM infrastructure functions as map requests and can present a scalability and performance issue to the infrastructure.
首先，CRM修改的ALT结构仍然是一个全局查询服务器系统。无论ALT的路径长度和延迟如何优化，查询器（可能在世界任何地方）都存在一个问题，它依赖于来自一个或两个或多个权威查询服务器（也可能在世界任何地方）的映射信息。这种系统固有的延迟和数据包丢失风险构成了一个基本问题。当ITR接收到多个可能很长的流量流并通过CRM网络转发到目标网络时，情况尤其如此。ITR在等待map回复时必须使用CRM基础设施。CRM基础架构上转发的流量作为映射请求发挥作用，可能会给基础架构带来可伸缩性和性能问题。
Secondly, the alterations contemplated in this proposal involve the roles of particular nodes in the network being dynamically assigned as part of the network's self-organizing nature.
第二，本提案中考虑的变更涉及将网络中的特定节点的角色动态分配为网络自组织性质的一部分。
The discussion of clustering in the middle of page 4 of [CRM] also indicates that particular nodes are responsible for registering EIDs from typically far-distant ETRs, all of which are handling closely related EIDs that this node can aggregate. Since MSes are apparently
在[CRM]的第4页中间的聚类讨论还表明，特定的节点负责从通常远距离的ETRs注册EID，所有这些都处理与该节点可以聚集的密切相关的EID。因为中小企业显然是
nodes within the compact routing system, and the process of an MS deciding whether to accept EID registrations is determined as part of the self-organizing properties of the system, there are concerns about how EID registration can be performed securely, when no particular physical node is responsible for it.
紧凑型路由系统中的节点，以及MS决定是否接受EID注册的过程被确定为系统自组织属性的一部分，在没有特定物理节点负责EID注册的情况下，存在EID注册如何安全执行的问题。
Thirdly, there are concerns about individually owned nodes performing work for other organizations. Such problems of trust and of responsibilities and costs being placed on those who do not directly benefit already exist in the inter-domain routing system and are a challenge for any scalable routing solution.
第三，人们担心个人所有的节点为其他组织执行工作。域间路由系统中已经存在这样的信任问题、责任问题和成本问题，这些问题都是由那些没有直接受益的人承担的，对于任何可扩展的路由解决方案来说都是一个挑战。
There are simpler solutions to the mapping problem than having an elaborate network of routers. If a global-scale query system is still preferred, then it would be better to have ITRs use local MRs, each of which is dynamically configured to know the IP address of the million or so authoritative Map Server (MS) query servers -- or two million or so assuming they exist in pairs for redundancy.
对于映射问题，有比拥有复杂的路由器网络更简单的解决方案。如果仍然首选全局规模的查询系统，那么最好让ITR使用本地MRs，每个MRs都被动态配置为知道大约一百万个权威地图服务器（MS）查询服务器的IP地址——或者假设它们成对存在以备冗余。
It appears that the inherently greater delays and risks of packet loss of global query server systems make them unsuitable mapping solutions for Core-Edge Elimination or Core-Edge Separation architectures. The solution to these problems appears to involve a greater number of widely distributed authoritative query servers, one or more of which will therefore be close enough to each querier that delays and risk of packet loss are reduced to acceptable levels. Such a structure would be suitable for map requests, but perhaps not for handling traffic packets to be delivered to the destination networks.
看来，全局查询服务器系统固有的更大延迟和数据包丢失风险使其不适合用于核心边缘消除或核心边缘分离架构的映射解决方案。这些问题的解决方案似乎涉及大量分布广泛的权威查询服务器，因此其中一个或多个服务器将与每个查询者足够接近，从而将延迟和数据包丢失风险降低到可接受的水平。这种结构适用于map请求，但可能不适用于处理要传送到目的地网络的业务分组。
CRM is most easily understood as an alteration to the routing structure of the LISP+ALT mapping overlay system, by altering or adding to the network's BGP control plane.
CRM最容易理解为通过改变或添加到网络的BGP控制平面来改变LISP+ALT映射覆盖系统的路由结构。
CRM's aims include the delivery of initial traffic packets to their destination networks where they also function as map requests. These packet streams may be long and numerous in the fractions of a second to perhaps several seconds that may elapse before the ITR receives the map reply.
CRM的目标包括将初始流量数据包传送到目的地网络，在那里它们也可以作为map请求。在ITR接收到map应答之前，这些分组流可以在一秒到几秒的分数内是长的和多的。
Compact Routing principles are used to optimize the path length taken by these query or traffic packets through a significantly modified version of the ALT (or similar) network, while also generally reducing typical or maximum paths taken by the query packets.
紧凑路由原则用于通过大幅修改的ALT（或类似）网络优化这些查询或流量数据包采用的路径长度，同时通常也减少查询数据包采用的典型或最大路径。
An overlay network is a diversion from the shortest path. However, CMR limits this diversion and provides an upper bound. Landmark routers/servers could deliver more than just the first traffic packet, subject to their CPU capabilities and their network connectivity bandwidths.
重叠网络是从最短路径的转移。然而，CMR限制了这种转移，并提供了一个上限。Landmark路由器/服务器根据其CPU能力和网络连接带宽，可以提供不仅仅是第一个流量数据包。
The trust between the landmarks (mapping servers) can be built based on the current BGP relationships. Registration to the landmark nodes needs to be authenticated mutually between the MS and the system that is registering. This part is not documented in the proposal text.
可以基于当前BGP关系建立地标（映射服务器）之间的信任。对landmark节点的注册需要在MS和正在注册的系统之间相互验证。本部分未记录在标书文本中。
The layered mapping system proposal builds a hierarchical mapping system to support scalability, analyzes the design constraints, presents an explicit system structure, designs a two-cache mechanism on ingress tunneling router (ITR) to gain low request delay, and facilitates data validation. Tunneling and mapping are done at the core, and no change is needed on edge networks. The mapping system is run by interest groups independent of any ISP, which conforms to an economical model and can be voluntarily adopted by various networks. Mapping systems can also be constructed stepwise, especially in the IPv6 scenario.
分层映射系统方案构建了一个支持可伸缩性的分层映射系统，分析了设计约束，给出了一个明确的系统结构，在入口隧道路由器（ITR）上设计了一个双缓存机制以获得较低的请求延迟，并促进了数据验证。隧道和映射在核心完成，边缘网络无需更改。测绘系统由独立于任何ISP的利益集团运行，符合经济模式，可由各种网络自愿采用。映射系统也可以逐步构建，特别是在IPv6场景中。
1. Scalability
1. 可伸缩性
A. Distributed storage of mapping data avoids central storage of massive amounts of data and restricts updates within local areas.
A.地图数据的分布式存储避免了大量数据的集中存储，并限制了本地区域内的更新。
B. The cache mechanism in an ITR reasonably reduces the request loads on the mapping system.
B.ITR中的缓存机制合理地减少了映射系统上的请求负载。
2. Deployability
2. 可部署性
A. No change on edge systems, only tunneling in core routers, and new devices in core networks.
A.边缘系统没有变化，只有核心路由器中的隧道，以及核心网络中的新设备。
B. The mapping system can be constructed stepwise: a mapping node needn't be constructed if none of its responsible ELOCs is allocated. This makes sense especially for IPv6.
B.映射系统可以逐步构建：如果没有分配其负责的ELOC，则无需构建映射节点。这对于IPv6尤其有意义。
C. Conforms to a viable economic model: the mapping system operators can profit from their services; core routers and edge networks are willing to join the circle either to avoid router upgrades or realize traffic engineering. Benefits from joining are independent of the scheme's implementation scale.
C.符合可行的经济模式：测绘系统运营商可以从其服务中获利；核心路由器和边缘网络愿意加入这个圈子，要么避免路由器升级，要么实现流量工程。加入该计划的好处与该计划的实施规模无关。
3. Low request delay: The low number of layers in the mapping structure and the two-stage cache help achieve low request delay.
3. 低请求延迟：映射结构中的低层数和两级缓存有助于实现低请求延迟。
4. Data consistency: The two-stage cache enables an ITR to update data in the map cache conveniently.
4. 数据一致性：两级缓存使ITR能够方便地更新地图缓存中的数据。
5. Traffic engineering support: Edge networks inform the mapping system of their prioritized mappings with all upstream routers, thus giving the edge networks control over their ingress flows.
5. 流量工程支持：边缘网络通知映射系统其与所有上游路由器的优先映射，从而使边缘网络控制其入口流。
1. Deployment of LMS needs to be further discussed.
1. LMS的部署需要进一步讨论。
2. The structure of the mapping system needs to be refined according to practical circumstances.
2. 测绘系统的结构需要根据实际情况加以改进。
[LMS_Summary] [LMS]
[LMS_摘要][LMS]
LMS is a mapping mechanism based on Core-Edge Separation. In fact, any proposal that needs a global mapping system with keys with similar properties to that of an "edge address" in a Core-Edge Separation scenario can use such a mechanism. This means that those keys are globally unique (by authorization or just statistically), at the disposal of edge users, and may have several satisfied mappings (with possibly different weights). A proposal to address routing scalability that needs mapping but doesn't specify the mapping mechanism can use LMS to strengthen its infrastructure.
LMS是一种基于核边缘分离的映射机制。事实上，任何需要具有与核心-边缘分离场景中的“边缘地址”具有类似属性的密钥的全局映射系统的方案都可以使用这种机制。这意味着这些密钥是全局唯一的（通过授权或统计），由边缘用户处理，并且可能具有多个满意的映射（可能具有不同的权重）。解决需要映射但未指定映射机制的路由可伸缩性的建议可以使用LMS来加强其基础设施。
The key idea of LMS is similar to that of LISP+ALT: that the mapping system should be hierarchically organized to gain scalability for storage and updates and to achieve quick indexing for lookups. However, LMS advocates an ISP-independent mapping system, and ETRs are not the authorities of mapping data. ETRs or edge-sites report their mapping data to related mapping servers.
LMS的关键思想类似于LISP+ALT：映射系统应该分层组织，以获得存储和更新的可伸缩性，并实现查找的快速索引。然而，LMS提倡独立于ISP的制图系统，ETR不是制图数据的权威机构。ETR或边缘站点向相关映射服务器报告其映射数据。
LMS assumes that mapping servers can be incrementally deployed in that a server may not be constructed if none of its administered edge addresses are allocated, and that mapping servers can charge for their services, which provides the economic incentive for their existence. How this brand-new system can be constructed is still not clear. Explicit layering is only an ideal state, and the proposal analyzes the layering limits and feasibility, rather than provide a practical way for deployment.
LMS假设映射服务器可以增量部署，因为如果没有分配其管理的边缘地址，则可能无法构建服务器，并且映射服务器可以对其服务收费，这为其存在提供了经济激励。如何构建这一全新体系尚不清楚。显式分层只是一种理想状态，建议分析分层的限制和可行性，而不是提供一种实用的部署方式。
The drawbacks of LMS's feasibility analysis also include that it 1) is based on current PC power and may not represent future circumstances (especially for IPv6), and 2) does not consider the variability of address utilization. Some IP address spaces may be effectively allocated and used while some may not, causing some mapping servers to be overloaded while others are poorly utilized. More thoughts are needed as to the flexibility of the layer design.
LMS的可行性分析的缺点还包括IT 1基于当前PC功率，并且可能不代表未来的情况（特别是对于IPv6），并且2）不考虑地址利用的可变性。一些IP地址空间可能被有效分配和使用，而一些可能没有，这会导致一些映射服务器过载，而另一些映射服务器利用率很低。关于图层设计的灵活性，需要更多的思考。
LMS doesn't fit well for mobility. It does not solve the problem when hosts move faster than the mapping updates and propagation between relative mapping servers. On the other hand, mobile hosts' moving across ASes and changing their attachment points (core addresses) is less frequent than hosts' moving within an AS.
LMS不适合移动。当主机的移动速度超过映射更新和相对映射服务器之间的传播速度时，它无法解决问题。另一方面，移动主机在AS间移动并更改其连接点（核心地址）的频率低于主机在AS内移动的频率。
Separation needs two planes: Core-Edge Separation (which is to gain routing table scalability) and identity/location separation (which is to achieve mobility). The Global Locator, Local Locator, and Identifier (GLI) scheme does a good clarification of this, and in that case, LMS can be used to provide identity-to-core address mapping. Of course, other schemes may be competent, and LMS can be incorporated with them if the scheme has global keys and needs to map them to other namespaces.
分离需要两个平面：核心-边缘分离（用于获得路由表的可伸缩性）和身份/位置分离（用于实现移动性）。全局定位器、本地定位器和标识符（GLI）方案很好地说明了这一点，在这种情况下，LMS可用于提供身份到核心地址的映射。当然，其他方案也可以胜任，如果方案具有全局密钥并且需要将其映射到其他名称空间，则可以将LMS与之合并。
No rebuttal was submitted for this proposal.
没有人对这项提议提出反驳。
1. A mapping from prefixes to ETRs is an M:M mapping. Any change of a (prefix, ETR) pair should be updated in a timely manner, which can be a heavy burden to any mapping system if the relation changes frequently.
1. 从前缀到ETRs的映射是M:M映射。（前缀，ETR）对的任何更改都应及时更新，如果关系频繁更改，这可能会给任何映射系统带来沉重负担。
2. A prefix<->ETR mapping system cannot be deployed efficiently if it is overwhelmed by worldwide dynamics. Therefore, the mapping itself is not scalable with this direct mapping scheme.
2. 如果一个prefix<->ETR映射系统被全球动态所压倒，它将无法有效部署。因此，这种直接映射方案无法扩展映射本身。
1. Introduce an AS number in the middle of the mapping, the phase I mapping is prefix<->AS#, phase II mapping is AS#<->ETRs. This creates a M:1:M mapping model.
1. 在映射的中间引入一个As数，相位I映射是前缀<>作为α，第二映射为α<-> ETRs。这将创建一个M:1:M映射模型。
2. It is fair to assume that all ASes know their local prefixes (in the IGP) better than other ASes and that it is most likely that local prefixes can be aggregated when they can be mapped to the AS number, which will reduce the number of mapping entries. Also, ASes also know clearly their ETRs on the border between core and edge. So, all mapping information can be collected locally.
2. 可以公平地假设，所有ASE（在IGP中）都比其他ASE更了解其本地前缀，并且当本地前缀可以映射到AS编号时，很可能可以聚合本地前缀，这将减少映射条目的数量。此外，ASE还清楚地知道其核心和边缘边界上的ETR。因此，所有映射信息都可以在本地收集。
3. A registry system will take care of the phase I mapping information. Each AS should have a registration agent to notify the registry of the local range of IP address space. This system can be organized as a hierarchical infrastructure like DNS, or alternatively, as a centralized registry like "whois" in each RIR. Phase II mapping information can be distributed between xTRs as a BGP extension.
3. 注册系统将负责第一阶段的映射信息。每个AS都应该有一个注册代理来通知注册表IP地址空间的本地范围。该系统可以组织为DNS之类的分层基础设施，或者也可以组织为每个RIR中的“whois”之类的集中式注册表。阶段II映射信息可以作为BGP扩展在XTR之间分发。
4. The basic forwarding procedure is that the ITR first gets the destination AS number from the phase I mapper (or from cache) when the packet is entering the "core". Then, it will extract the closest ETR for the destination AS number. This is local, since phase II mapping information has been "pushed" to the ITR through BGP updates. Finally, the ITR tunnels the packet to the corresponding ETR.
4. 基本转发过程是，当数据包进入“核心”时，ITR首先从第一阶段映射器（或缓存）获取目的地AS编号。然后，它将提取目标最近的ETR作为编号。这是本地的，因为第二阶段映射信息已通过BGP更新“推送”到ITR。最后，ITR通过隧道将数据包传输到相应的ETR。
1. Any prefix reconfiguration (aggregation/deaggregation) within an AS will not be reflected in the mapping system.
1. AS中的任何前缀重新配置（聚合/反聚合）都不会反映在映射系统中。
2. Local prefixes can be aggregated with a high degree of efficiency.
2. 可以高效地聚合本地前缀。
3. Both phase I and phase II mappings can be stable.
3. 第一阶段和第二阶段的映射都是稳定的。
4. A stable mapping system will reduce the update overhead introduced by topology changes and/or routing policy dynamics.
4. 稳定的映射系统将减少拓扑更改和/或路由策略动态带来的更新开销。
1. The two-phased mapping scheme introduces an AS number between the mapping prefixes and ETRs.
1. 两阶段映射方案在映射前缀和ETR之间引入AS编号。
2. The decoupling of direct mapping makes highly dynamic updates stable; therefore, it can be more scalable than any direct mapping designs.
2. 直接映射的解耦使动态更新高度稳定；因此，它可以比任何直接映射设计更具可伸缩性。
3. The two-phased mapping scheme is adaptable to any proposals based on the core/edge split.
3. 两阶段映射方案适用于基于核心/边缘分割的任何方案。
No references were submitted.
没有提交任何参考资料。
This is a simple idea on how to scale mapping. However, this design is too incomplete to be considered a serious input to RRG. Take the following two issues as example:
这是一个关于如何缩放贴图的简单想法。然而，该设计太不完整，不能被视为RRG的重要投入。以以下两个问题为例：
First, in this two-phase scheme, an AS is essentially the unit of destinations (i.e., sending ITRs find out destination AS D, then send data to one of D's ETRs). This does not offer much choice for traffic engineering.
首先，在这个两阶段方案中，AS本质上是目的地的单位（即，发送ITR找出目的地为D，然后将数据发送到D的一个ETR）。这并不能为交通工程提供太多选择。
Second, there is no consideration whatsoever on failure detection and handling.
第二，对故障检测和处理没有任何考虑。
No rebuttal was submitted for this proposal.
没有人对这项提议提出反驳。
GLI-Split implements a separation between global routing (in the global Internet outside edge networks) and local routing (inside edge networks) using global and local locators (GLs and LLs). In addition, a separate static identifier (ID) is used to identify communication endpoints (e.g., nodes or services) independently of any routing information. Locators and IDs are encoded in IPv6 addresses to enable backwards-compatibility with the IPv6 Internet. The higher-order bits store either a GL or a LL, while the lower-
GLI Split使用全局和本地定位器（GLs和LLs）在全局路由（在全局Internet外部边缘网络中）和本地路由（在边缘网络内部）之间实现分离。此外，单独的静态标识符（ID）用于独立于任何路由信息来识别通信端点（例如，节点或服务）。定位器和ID以IPv6地址编码，以实现与IPv6 Internet的向后兼容性。高阶位存储GL或LL，而低阶位存储GL或LL-
order bits contain the ID. A local mapping system maps IDs to LLs, and a global mapping system maps IDs to GLs. The full GLI-mode requires nodes with upgraded networking stacks and special GLI-gateways. The GLI-gateways perform stateless locator rewriting in IPv6 addresses with the help of the local and global mapping system. Non-upgraded IPv6 nodes can also be accommodated in GLI-domains since an enhanced DHCP service and GLI-gateways compensate for their missing GLI-functionality. This is an important feature for incremental deployability.
订单位包含ID。本地映射系统将ID映射到LLs，全局映射系统将ID映射到GLs。全GLI模式需要具有升级网络堆栈和特殊GLI网关的节点。GLI网关在本地和全局映射系统的帮助下，在IPv6地址中执行无状态定位器重写。由于增强的DHCP服务和GLI网关弥补了它们缺少的GLI功能，所以非升级的IPv6节点也可以容纳在GLI域中。这是增量部署能力的一个重要特性。
The benefits of GLI-Split are:
GLI拆分的好处是：
o Hierarchical aggregation of routing information in the global Internet through separation of edge and core routing
o 通过边缘和核心路由分离实现全球互联网路由信息的分层聚合
o Provider changes not visible to nodes inside GLI-domains (renumbering not needed)
o 提供程序更改对GLI域内的节点不可见（不需要重新编号）
o Rearrangement of subnetworks within edge networks not visible to the outside world (better support of large edge networks)
o 在外部世界看不到的边缘网络内重新排列子网络（更好地支持大型边缘网络）
o Transport connections survive both types of changes
o 传输连接在这两种类型的更改中都能生存
o Multihoming
o 多归宿
o Improved traffic engineering for incoming and outgoing traffic
o 改进了传入和传出流量的流量工程
o Multipath routing and load balancing for hosts
o 主机的多路径路由和负载平衡
o Improved resilience
o 提高弹性
o Improved mobility support without home agents and triangle routing
o 改进的移动性支持，无需家庭代理和三角路由
o Interworking with the classic Internet
o 与经典互联网互通
* without triangle routing over proxy routers
* 无三角路由的代理路由器
* without stateful NAT
* 无状态NAT
These benefits are available for upgraded GLI-nodes, but non-upgraded nodes in GLI-domains partially benefit from these advanced features, too. This offers multiple incentives for early adopters, and they have the option to migrate their nodes gradually from non-GLI-stacks to GLI-stacks.
这些好处可用于升级的GLI节点，但GLI域中未升级的节点也部分受益于这些高级功能。这为早期采用者提供了多种激励，他们可以选择将节点从非GLI堆栈逐渐迁移到GLI堆栈。
o Local and global mapping system
o 本地和全球制图系统
o Modified DHCP or similar mechanism
o 修改的DHCP或类似机制
o GLI-gateways with stateless locator rewriting in IPv6 addresses
o IPv6地址中具有无状态定位器重写的GLI网关
o Upgraded stacks (only for full GLI-mode)
o 升级的堆栈（仅适用于全GLI模式）
[GLI]
[GLI]
GLI-Split makes a clear distinction between two separation planes: the separation between identifier and locator (which is to meet end-users' needs including mobility) and the separation between local and global locator (which makes the global routing table scalable). The distinction is needed since ISPs and hosts have different requirements, with both needing to make the changes inside and outside GLI-domains invisible to their opposites.
GLI Split明确区分了两个分离平面：标识符和定位器之间的分离（这是为了满足终端用户的需求，包括移动性）和本地定位器和全局定位器之间的分离（这使得全局路由表具有可伸缩性）。之所以需要区分，是因为ISP和主机有不同的需求，两者都需要使GLI域内外的变化对其对立面不可见。
A main drawback of GLI-Split is that it puts a burden on hosts. Before routing a packet received from upper layers, network stacks in hosts first need to resolve the DNS name to an IP address; if the IP address is GLI-formed, it may look up the map from the identifier extracted from the IP address to the local locator. If the communication is between different GLI-domains, hosts may further look up the mapping from the identifier to the global locator. Having the local mapping system forward requests to the global mapping system for hosts is just an option. Though host lookup may ease the burden of intermediate nodes, which would otherwise to perform the mapping lookup, the three lookups by hosts in the worst case may lead to large delays unless a very efficient mapping mechanism is devised. The work may also become impractical for low-powered hosts. On one hand, GLI-Split can provide backward compatibility where classic and upgraded IPv6 hosts can communicate. This is its big virtue. On the other hand, the need to upgrade may work against hosts' enthusiasm to change. This is offset against the benefits they would gain.
GLI拆分的一个主要缺点是它会给主机带来负担。在路由从上层接收的数据包之前，主机中的网络堆栈首先需要将DNS名称解析为IP地址；如果IP地址是GLI形成的，它可以查找从IP地址提取的标识符到本地定位器的映射。如果通信在不同的GLI域之间，则主机可以进一步查找从标识符到全局定位器的映射。让本地映射系统将请求转发到主机的全局映射系统只是一种选择。尽管主机查找可以减轻中间节点的负担，否则将无法执行映射查找，但主机在最坏情况下的三次查找可能会导致较大的延迟，除非设计出非常有效的映射机制。对于低功耗主机，这项工作也可能变得不切实际。一方面，GLI Split可以提供向后兼容性，经典的和升级的IPv6主机可以进行通信。这是它最大的优点。另一方面，升级的需要可能不利于东道主改变的热情。这抵消了他们将获得的好处。
GLI-Split provides additional features to improve TE and to improve resilience, e.g., exerting multipath routing. However, the cost is that more burdens are placed on hosts, e.g., they may need more lookup actions and route selections. However, these kinds of tradeoffs between costs and gains exist in most proposals.
GLI Split提供了其他功能，以改善TE和提高恢复能力，例如使用多路径路由。但是，成本是主机承担了更多的负担，例如，它们可能需要更多的查找操作和路由选择。然而，在大多数提案中都存在成本和收益之间的这种权衡。
One improvement of GLI-Split is its support for mobility by updating DNS data as GLI-hosts move across GLI-domains. Through this, the GLI-corresponding-node can query DNS to get a valid global locator of the GLI-mobile-node and need not query the global mapping system (unless it wants to do multipath routing), giving more incentives for nodes to become GLI-enabled. The merits of GLI-Split, including simplified-mobility-handover provision, compensate for the costs of this improvement.
GLI Split的一个改进是通过在GLI主机跨GLI域移动时更新DNS数据来支持移动性。通过这种方式，GLI对应节点可以查询DNS以获得GLI移动节点的有效全局定位器，并且不需要查询全局映射系统（除非它想要进行多路径路由），从而为节点启用GLI提供更多激励。GLI拆分的优点，包括简化的移动性切换规定，弥补了这一改进的成本。
GLI-Split claims to use rewriting instead of tunneling for conversions between local and global locators when packets span GLI-domains. The major advantage is that this kind of rewriting needs no extra state, since local and global locators need not map to each other. Many other rewriting mechanisms instead need to maintain extra state. It also avoids the MTU problem faced by the tunneling methods. However, GLI-Split achieves this only by compressing the namespace size of each attribute (identifier and local/global locator). GLI-Split encodes two namespaces (identifier and local/ global locator) into an IPv6 address (each has a size of 2^64 or less), while map-and-encap proposals assume that identifier and locator each occupy a 128-bit space.
GLI Split声称，当数据包跨越GLI域时，本地和全局定位器之间的转换使用重写而不是隧道。主要优点是这种重写不需要额外的状态，因为本地和全局定位器不需要相互映射。许多其他重写机制需要维护额外的状态。它还避免了隧道方法面临的MTU问题。但是，GLI Split仅通过压缩每个属性（标识符和本地/全局定位器）的名称空间大小来实现这一点。GLI Split将两个名称空间（标识符和本地/全局定位器）编码为一个IPv6地址（每个地址的大小为2^64或更小），而map和encap方案假定标识符和定位器各自占用128位空间。
The arguments in the GLI-Split critique are correct. There are only two points that should be clarified here. First, it is not a drawback that hosts perform the mapping lookups. Second, the critique proposed an improvement to the mobility mechanism, which is of a general nature and not specific to GLI-Split.
GLI分裂评论中的论点是正确的。这里只有两点需要澄清。首先，主机执行映射查找并不是一个缺点。第二，批评提出了对流动机制的改进，这是一种一般性的机制，而不是特定于GLI拆分。
1. The additional burden on the hosts is actually a benefit, compared to having the same burden on the gateways. If the gateway would perform the lookups and packets addressed to uncached EIDs arrive, a lookup in the mapping system must be initiated. Until the mapping reply returns, packets must be either dropped, cached, or sent over the mapping system to the destination. All these options are not optimal and have their drawbacks. To avoid these problems in GLI-Split, the hosts perform the lookup. The short additional delay is not a big issue in the hosts because it happens before the first packets are sent. So, no packets are lost or have to be cached. GLI-Split could also easily be adapted to special GLI-hosts (e.g., low-power sensor nodes) that do not have to do any lookup and simply let the gateway do all the work. This functionality is included anyway for backward compatibility with regular IPv6 hosts inside the GLI-domain.
1. 与网关上的负担相同相比，主机上的额外负担实际上是一个好处。如果网关将执行查找，并且发往未缓存EID的数据包到达，则必须启动映射系统中的查找。在映射应答返回之前，必须丢弃、缓存数据包，或者通过映射系统将数据包发送到目标。所有这些选择都不是最优的，都有其缺点。为了避免GLI拆分中出现这些问题，主机将执行查找。短的额外延迟在主机中不是一个大问题，因为它发生在发送第一个数据包之前。因此，不会丢失或缓存任何数据包。GLI Split还可以很容易地适用于特殊的GLI主机（例如，低功耗传感器节点），这些主机不必进行任何查找，只需让网关完成所有工作。为了与GLI域内的常规IPv6主机向后兼容，仍然包含此功能。
2. The critique proposes a DNS-based mobility mechanism as an improvement to GLI-Split. However, this improvement is an alternative mobility approach that can be applied to any routing architecture (including GLI-Split) and also raises some concerns, e.g., the update speed of DNS. Therefore, we prefer to keep this issue out of the discussion.
2. 该评论提出了一种基于DNS的移动机制，作为对GLI拆分的改进。然而，这种改进是一种可选的移动性方法，可应用于任何路由体系结构（包括GLI拆分），并且也引起了一些关注，例如DNS的更新速度。因此，我们宁愿不讨论这个问题。
Provides a method for locator/identifier separation using tunnels between routers on the edge of the Internet transit infrastructure. It enriches the BGP protocol for distributing the identifier-to-locator mapping. Using new BGP attributes, "identifier prefixes" are assigned inter-domain routing locators so that they will not be installed in the RIB and will be moved to a new table called the Tunnel Information Base (TIB). Afterwards, when routing a packet to an "identifier prefix", first the TIB will be searched to perform tunneling, and secondly the RIB will be searched for actual routing. After the edge router performs tunneling, all routers in the middle will route this packet until the packet reaches the router at the tail-end of the tunnel.
提供一种使用互联网传输基础设施边缘路由器之间的隧道分离定位器/标识符的方法。它丰富了用于分发标识符到定位器映射的BGP协议。使用新的BGP属性，为“标识符前缀”分配域间路由定位器，以便它们不会安装在RIB中，并将移动到称为隧道信息库（TIB）的新表中。之后，当将数据包路由到“标识符前缀”时，首先搜索TIB以执行隧道，然后搜索RIB以进行实际路由。在边缘路由器执行隧道之后，中间的所有路由器将路由该分组，直到数据包到达隧道尾端的路由器为止。
o Smooth deployment
o 顺利部署
o Size reduction of the global RIB
o 整体肋骨的缩小
o Deterministic customer traffic engineering for incoming traffic
o 针对传入流量的确定性客户流量工程
o Numerous forwarding decisions for a particular address prefix
o 针对特定地址前缀的大量转发决策
o Stops AS number space depletion
o 当数字空间耗尽时停止
o Improved BGP convergence
o 改进的BGP收敛性
o Protection of the inter-domain routing infrastructure
o 域间路由基础设施的保护
o Easy separation of control traffic and transit traffic
o 控制交通和过境交通容易分离
o Different layer-2 protocol IDs for transit and non-transit traffic
o 传输和非传输流量的不同第2层协议ID
o Multihoming resilience
o 多归宿弹性
o New address families and tunneling techniques
o 新地址族与隧道技术
o Support for IPv4 or IPv6, and migration to IPv6
o 支持IPv4或IPv6，并迁移到IPv6
o Scalability, stability, and reliability
o 可扩展性、稳定性和可靠性
o Faster inter-domain routing
o 更快的域间路由
o Routers on the edge of the inter-domain infrastructure will need to be upgraded to hold the mapping database (i.e., the TIB).
o 域间基础设施边缘上的路由器需要升级以保存映射数据库（即TIB）。
o "Mapping updates" will need to be treated differently from usual BGP "routing updates".
o “映射更新”需要与通常的BGP“路由更新”区别对待。
[TIDR] [TIDR_identifiers] [TIDR_and_LISP] [TIDR_AS_forwarding]
[TIDR][TIDR_标识符][TIDR_和_LISP][TIDR_AS_转发]
TIDR is a Core-Edge Separation architecture from late 2006 that distributes its mapping information via BGP messages that are passed between DFZ routers.
TIDR是2006年末的一种核心边缘分离架构，它通过在DFZ路由器之间传递的BGP消息来分发其映射信息。
This means that TIDR cannot solve the most important goal of scalable routing -- to accommodate much larger numbers of end-user network prefixes (millions or billions) without each such prefix directly burdening every DFZ router. Messages advertising routes for TIDR-managed prefixes may be handled with lower priority, but this would only marginally reduce the workload for each DFZ router compared to handling an advertisement of a conventional PI prefix.
这意味着TIDR无法解决可伸缩路由的最重要目标——容纳更多的最终用户网络前缀（数百万或数十亿），而每个前缀都不会直接加重每个DFZ路由器的负担。TIDR管理的前缀的消息广告路由可以以较低的优先级处理，但与处理传统PI前缀的广告相比，这只会略微减少每个DFZ路由器的工作量。
Therefore, TIDR cannot be considered for RRG recommendation as a solution to the routing scaling problem.
因此，不能将TIDR作为RRG建议的路由扩展问题的解决方案。
For a TIDR-using network to receive packets sent from any host, every BR of all ISPs must be upgraded to have the new ITR-like functionality. Furthermore, all DFZ routers would need to be altered so they accepted and correctly propagated the routes for end-user network address space, with the new LOCATOR attribute, which contains the ETR address and a REMOTE-PREFERENCE value. Firstly, if they received two such advertisements with different LOCATORs, they would advertise a single route to this prefix containing both. Secondly, for end-user address space (for IPv4) to be more finely divided, the DFZ routers must propagate LOCATOR-containing advertisements for prefixes longer than /24.
对于使用网络接收任何主机发送的数据包的TIDR，所有ISP的每个BR都必须升级，以具有新的类似ITR的功能。此外，需要更改所有DFZ路由器，以便它们接受并正确传播最终用户网络地址空间的路由，并使用新的定位器属性，该属性包含ETR地址和远程首选项值。首先，如果他们收到两个具有不同定位器的此类广告，他们将向包含这两个定位器的前缀发布一条路由。其次，为了更精细地划分最终用户地址空间（对于IPv4），DFZ路由器必须传播包含前缀大于/24的广告的定位器。
TIDR's ITR-like routers store the full mapping database -- so there would be no delay in obtaining mapping, and therefore no significant delay in tunneling traffic packets.
TIDR的类ITR路由器存储完整的映射数据库——因此在获取映射时不会有延迟，因此在隧道传输数据包时也不会有显著延迟。
[TIDR] is written as if traffic packets are classified by reference to the RIB, but routers use the FIB for this purpose, and "FIB" does not appear in [TIDR].
[TIDR]的编写方式与参考RIB对流量数据包进行分类一样，但路由器为此使用FIB，并且[TIDR]中没有出现“FIB”。
TIDR does not specify a tunneling technique, leaving this to be chosen by the ETR-like function of BRs and specified as part of a second kind of new BGP route advertised by that ETR-like BR. There is no provision for solving the PMTUD problems inherent in encapsulation-based tunneling.
TIDR未指定隧道技术，这将由BRs的ETR类功能选择，并指定为该ETR类BR宣传的第二种新BGP路由的一部分。没有解决基于封装的隧道中固有的PMTUD问题的规定。
ITR functions must be performed by already busy routers of ISPs, rather than being distributed to other routers or to sending hosts. There is no practical support for mobility. The mapping in each end-user route advertisement includes a REMOTE-PREFERENCE for each ETR-like BR, but this is used by the ITR-like functions of BRs to always select the LOCATOR with the highest value. As currently described, TIDR does not provide inbound load-splitting TE.
ITR功能必须由ISP已经繁忙的路由器执行，而不是分配给其他路由器或发送主机。没有对流动性的实际支持。每个终端用户路线广告中的映射包括每个ETR类BR的远程首选项，但BRs的ITR类功能使用此选项始终选择具有最高值的定位器。如目前所述，TIDR不提供入站负载拆分TE。
Multihoming service restoration is achieved initially by the ETR-like function of the BR at the ISP (whose link to the end-user network has just failed). It looks up the mapping to find the next preferred ETR-like BR's address. The first ETR-like router tunnels the packets to the second ETR-like router in the other ISP. However, if the failure was caused by the first ISP itself being unreachable, then connectivity would not be restored until a revised mapping (with higher REMOTE-PREFERENCE) from the reachable ETR-like BR of the second ISP propagated across the DFZ to all ITR-like routers, or the withdrawn advertisement for the first one reaches the ITR-like router.
多主服务恢复最初是通过ISP（其与最终用户网络的链接刚刚失败）上BR的ETR功能实现的。它查找映射以查找下一个首选ETR，如BR的地址。第一个ETR类路由器通过隧道将数据包传输到另一个ISP中的第二个ETR类路由器。但是，如果故障是由第一个ISP本身无法访问引起的，则在第二个ISP的可访问ETR-like BR的修改映射（具有更高的远程首选项）通过DFZ传播到所有ITR-like路由器之前，连接不会恢复，或者第一条被撤回的广告到达类似ITR的路由器。
No rebuttal was submitted for this proposal.
没有人对这项提议提出反驳。
o Provides crisp separation of Identifiers from Locators.
o 提供标识符与定位器的清晰分离。
o Identifiers name nodes, not interfaces.
o 标识符命名节点，而不是接口。
o Locators name subnetworks, rather than interfaces, so they are equivalent to an IP routing prefix.
o 定位器命名子网，而不是接口，因此它们相当于IP路由前缀。
o Identifiers are never used for network-layer routing, whilst Locators are never used for Node Identity.
o 标识符从不用于网络层路由，而定位器从不用于节点标识。
o Transport-layer sessions (e.g., TCP session state) use only Identifiers, never Locators, meaning that changes in location have no adverse impact on an IP session.
o 传输层会话（例如，TCP会话状态）仅使用标识符，从不使用定位器，这意味着位置的更改不会对IP会话产生不利影响。
o The underlying protocol mechanisms support fully scalable site multihoming, node multihoming, site mobility, and node mobility.
o 底层协议机制支持完全可扩展的站点多宿主、节点多宿主、站点移动性和节点移动性。
o ILNP enables topological aggregation of location information while providing stable and topology-independent identities for nodes.
o ILNP支持位置信息的拓扑聚合，同时为节点提供稳定和拓扑无关的身份。
o In turn, this topological aggregation reduces both the routing prefix "churn" rate and the overall size of the Internet's global routing table, by eliminating the value and need for more-specific routing state currently carried throughout the global (default-free) zone of the routing system.
o 反过来，这种拓扑聚合减少了路由前缀“搅动”率和Internet全局路由表的总体大小，因为它消除了路由系统全局（无默认）区域中当前承载的更具体路由状态的值和需要。
o ILNP enables improved traffic engineering capabilities without adding any state to the global routing system. TE capabilities include both provider-driven TE and also end-site-controlled TE.
o ILNP能够在不向全局路由系统添加任何状态的情况下提高流量工程能力。TE功能包括提供商驱动的TE和终端站点控制的TE。
o ILNP's mobility approach:
o ILNP的移动性方法：
* eliminates the need for special-purpose routers (e.g., home agent and/or foreign agent now required by Mobile IP and NEMO).
* 消除了对专用路由器的需求（例如，移动IP和NEMO现在需要的归属代理和/或外部代理）。
* eliminates "triangle routing" in all cases.
* 在所有情况下消除“三角形布线”。
* supports both "make before break" and "break before make" layer-3 handoffs.
* 支持“先接通后断开”和“先断开后接通”第3层切换。
o ILNP improves resilience and network availability while reducing the global routing state (as compared with the currently deployed Internet).
o ILNP提高了恢复能力和网络可用性，同时降低了全局路由状态（与当前部署的Internet相比）。
o ILNP is incrementally deployable:
o ILNP可增量部署：
* No changes are required to existing IPv6 (or IPv4) routers.
* 无需更改现有IPv6（或IPv4）路由器。
* Upgraded nodes gain benefits immediately ("day one"); those benefits gain in value as more nodes are upgraded (this follows Metcalfe's Law).
* 升级后的节点立即受益（“第一天”）；这些好处随着更多节点的升级而增值（这遵循梅特卡夫定律）。
* The incremental deployment approach is documented.
* 增量部署方法已记录在案。
o ILNP is backwards compatible:
o ILNP向后兼容：
* ILNPv6 is fully backwards compatible with IPv6 (ILNPv4 is fully backwards compatible with IPv4).
* ILNPv6与IPv6完全向后兼容（ILNPv4与IPv4完全向后兼容）。
* Reuses existing known-to-scale DNS mechanisms to provide identifier/locator mapping.
* 重用现有已知的可扩展DNS机制，以提供标识符/定位器映射。
* Existing DNS security mechanisms are reused without change.
* 现有的DNS安全机制可以在不作更改的情况下重用。
* Existing IP Security mechanisms are reused with one minor change (IPsec Security Associations replace the current use of IP addresses with the use of Identifier values). NB: IPsec is also backwards compatible.
* 现有的IP安全机制只做了一个小改动就可以重用（IPsec安全关联将当前使用的IP地址替换为使用的标识符值）。注意：IPsec也是向后兼容的。
* The backwards compatibility approach is documented.
* 记录了向后兼容性方法。
o No new or additional overhead is required to determine or to maintain locator/path liveness.
o 确定或保持定位器/路径活跃度不需要新的或额外的开销。
o ILNP does not require locator rewriting (NAT); ILNP permits and tolerates NAT, should that be desirable in some deployment(s).
o ILNP不需要定位器重写（NAT）；如果在某些部署中需要NAT，ILNP允许并容忍NAT。
o Changes to upstream network providers do not require node or subnetwork renumbering within end-sites.
o 对上游网络提供商的更改不需要在终端站点内对节点或子网络重新编号。
o ILNP is compatible with and can facilitate the transition from current single-path TCP to multipath TCP.
o ILNP与当前的单路径TCP兼容，并且能够促进从当前的单路径TCP到多路径TCP的转换。
o ILNP can be implemented such that existing applications (e.g., applications using the BSD Sockets API) do NOT need any changes or modifications to use ILNP.
o ILNP的实现可以使现有应用程序（例如，使用BSD套接字API的应用程序）不需要任何更改或修改即可使用ILNP。
o End systems need to be enhanced incrementally to support ILNP in addition to IPv6 (or IPv4 or both).
o 除了IPv6（或IPv4或两者兼而有之）之外，终端系统还需要逐步增强以支持ILNP。
o DNS servers supporting upgraded end systems also should be upgraded to support new DNS resource records for ILNP. (The DNS protocol and DNS security do not need any changes.)
o 支持升级的终端系统的DNS服务器也应该升级，以支持ILNP的新DNS资源记录。（DNS协议和DNS安全性不需要任何更改。）
[ILNP_Site] [MobiArch1] [MobiArch2] [MILCOM1] [MILCOM2] [DNSnBIND]
[Referral_Obj] [ILNP_Intro] [ILNP_Nonce] [ILNP_DNS] [ILNP_ICMP]
[JSAC_Arch] [RFC4033] [RFC4034] [RFC4035] [RFC5534] [RFC5902]
[ILNP_Site] [MobiArch1] [MobiArch2] [MILCOM1] [MILCOM2] [DNSnBIND]
[Referral_Obj] [ILNP_Intro] [ILNP_Nonce] [ILNP_DNS] [ILNP_ICMP]
[JSAC_Arch] [RFC4033] [RFC4034] [RFC4035] [RFC5534] [RFC5902]
The primary issue for ILNP is how the deployment incentives and benefits line up with the RRG goal of reducing the rate of growth of entries and churn in the core routing table. If a site is currently using PI space, it can only stop advertising that space when the entire site is ILNP capable. This needs (at least) clear elucidation of the incentives for ILNP which are not related to routing scaling, in order for there to be a path for this to address the RRG needs. Similarly, the incentives for upgrading hosts need to align with the value for those hosts.
ILNP的主要问题是，部署激励和好处如何与RRG的目标一致，即降低核心路由表中条目和客户流失的增长率。如果一个站点当前正在使用PI空间，它只能在整个站点支持ILNP时停止该空间的广告。这需要（至少）明确说明与路由扩展无关的ILNP激励措施，以便找到解决RRG需求的途径。类似地，升级主机的动机需要与这些主机的价值保持一致。
A closely related question is whether this mechanism actually addresses the sites need for PI addresses. Assuming ILNP is deployed, the site does achieve flexible, resilient, communication using all of its Internet connections. While the proposal addresses the host updates when the host learns of provider changes, there are other aspects of provider change that are not addressed. This includes renumbering routers, subnets, and certain servers. (It is presumed that most servers, once the entire site has moved to ILNP, will not be concerned if their locator changes. However, some servers must have known locators, such as the DNS server.) The issues described in [RFC5887] will be ameliorated, but not resolved. To be able to adopt this proposal, and have sites use it, we need to address these issues. When a site changes points of attachment, only a small amount of DNS provisioning should be required. The LP resource record type is apparently intended to help with this. It is also likely that the use of dynamic DNS will help this.
一个密切相关的问题是，这种机制是否真正解决了站点对PI地址的需求。假设部署了ILNP，该站点确实可以使用其所有的Internet连接实现灵活、有弹性的通信。当主机得知提供商变更时，提案会解决主机更新问题，但提供商变更的其他方面尚未解决。这包括对路由器、子网和某些服务器重新编号。（假设大多数服务器在整个站点移动到ILNP后，如果其定位器发生变化，则不会担心。但是，某些服务器必须具有已知的定位器，例如DNS服务器。）[RFC5887]中描述的问题将得到改善，但未得到解决。为了能够采纳这一提案，并让网站使用它，我们需要解决这些问题。当站点更改连接点时，只需要少量的DNS配置。LP资源记录类型显然是为了帮助实现这一点。使用动态DNS也可能有助于实现这一点。
The ILNP mechanism is described as being suitable for use in conjunction with mobility. This raises the question of race conditions. To the degree that mobility concerns are valid at this time, it is worth asking how communication can be established if a node is sufficiently mobile that it is moving faster than the DNS update and DNS fetch cycle can effectively propagate changes.
ILNP机制被描述为适合与机动性结合使用。这就提出了种族条件的问题。就移动性问题在此时有效的程度而言，值得一问的是，如果节点具有足够的移动性，其移动速度比DNS更新快，并且DNS提取周期可以有效地传播更改，那么如何建立通信。
This proposal does presume that all communication using this mechanism is tied to DNS names. While it is true that most communication does start from a DNS name, it is not the case that all exchanges have this property. Some communication initiation and referral can be done with an explicit identifier/locator pair. This does appear to require some extensions to the existing mechanism (for
此建议假定所有使用此机制的通信都与DNS名称关联。虽然大多数通信确实是从DNS名称开始的，但并非所有交换都具有此属性。可以使用显式标识符/定位器对进行一些通信初始化和引用。这似乎需要对现有机制进行一些扩展（例如
both sides to add locators). In general, some additional clarity on the assumptions regarding DNS, particularly for low-end devices, would seem appropriate.
两侧添加定位器）。一般来说，关于DNS的假设（特别是对于低端设备）的一些额外澄清似乎是合适的。
One issue that this proposal shares with many others is the question of how to determine which locator pairs (local and remote) are actually functional. This is an issue both for initial communications establishment and for robustly maintaining communication. It is likely that a combination of monitoring of traffic (in the host, where this is tractable), coupled with other active measures, can address this. ICMP is clearly insufficient.
本提案与其他许多提案一样的一个问题是如何确定哪些定位器对（本地和远程）实际起作用。这对于初始通信建立和稳健地维护通信都是一个问题。很可能通过对通信量的监控（在主机中，这是可处理的），再加上其他主动措施，可以解决这一问题。ICMP显然是不够的。
ILNP eliminates the perceived need for PI addressing and encourages increased DFZ aggregation. Many enterprise users view DFZ scaling issues as too abstruse, so ILNP creates more user-visible incentives to upgrade deployed systems.
ILNP消除了对PI寻址的感知需求，并鼓励增加DFZ聚合。许多企业用户认为DFZ扩展问题过于深奥，因此ILNP为升级已部署系统创造了更多用户可见的激励。
ILNP mobility eliminates Duplicate Address Detection (DAD), reducing the layer-3 handoff time significantly when compared to IETF standard Mobile IP, as shown in [MobiArch1] and [MobiArch2]. ICMP location updates separately reduce the layer-3 handoff latency.
ILNP移动性消除了重复地址检测（DAD），与IETF标准移动IP相比，显著缩短了第三层切换时间，如[MobiArch1]和[MobiArch2]所示。ICMP位置更新可单独减少第3层切换延迟。
Also, ILNP enables both host multihoming and site multihoming. Current BGP approaches cannot support host multihoming. Host multihoming is valuable in reducing the site's set of externally visible nodes.
此外，ILNP还支持主机多宿主和站点多宿主。当前的BGP方法无法支持主机多宿主。主机多宿主在减少站点的外部可见节点集方面很有价值。
Improved mobility support is very important. This is shown by the research literature and also appears in discussions with vendors of mobile devices (smartphones, MP3 players). Several operating system vendors push "updates" with major networking software changes in maintenance releases today. Security concerns mean most hosts receive vendor updates more quickly these days.
提高机动性支持非常重要。研究文献表明了这一点，与移动设备（智能手机、MP3播放器）供应商的讨论也显示了这一点。一些操作系统供应商在今天的维护版本中推出了重大网络软件更改的“更新”。安全问题意味着现在大多数主机接收供应商更新的速度更快。
ILNP enables a site to hide exterior connectivity changes from interior nodes, using various approaches. One approach deploys unique local address (ULA) prefixes within the site, and has the site border router(s) rewrite the Locator values. The usual NAT issues don't arise because the Locator value is not used above the network-layer. [MILCOM1] [MILCOM2]
ILNP允许站点使用各种方法从内部节点隐藏外部连接更改。一种方法是在站点内部署唯一本地地址（ULA）前缀，并让站点边界路由器重写定位器值。通常不会出现NAT问题，因为定位器值未在网络层上使用。[MILCOM1][MILCOM2]
[RFC5902] makes clear that many users desire IPv6 NAT, with site interior obfuscation as a major driver. This makes global-scope PI addressing much less desirable for end sites than formerly.
[RFC5902]清楚地表明，许多用户希望使用IPv6 NAT，站点内部混淆是主要驱动因素。这使得全球范围PI寻址对终端站点的要求比以前低得多。
ILNP-capable nodes can talk existing IP with legacy IP-only nodes, with no loss of current IP capability. So, ILNP-capable nodes will never be worse off.
支持ILNP的节点可以在不丢失当前IP功能的情况下，与传统的纯IP节点通信。因此，支持ILNP的节点将永远不会变得更糟。
Secure Dynamic DNS Update is standard and widely supported in deployed hosts and DNS servers. [DNSnBIND] says many sites have deployed this technology without realizing it (e.g., by enabling both the DHCP server and Active Directory of the MS-Windows Server).
安全动态DNS更新是标准的，在部署的主机和DNS服务器中得到广泛支持。[DNSnBIND]表示，许多站点在没有意识到的情况下部署了这项技术（例如，通过启用DHCP服务器和MS Windows服务器的Active Directory）。
If a node is as mobile as the critique says, then existing IETF Mobile IP standards also will fail. They also use location updates (e.g., MN -> home agent, MN -> foreign agent).
如果一个节点像评论所说的那样移动，那么现有的IETF移动IP标准也将失败。他们还使用位置更新（例如，MN->home agent，MN->foreign agent）。
ILNP also enables new approaches to security that eliminate dependence upon location-dependent Access Control Lists (ACLs) without packet authentication. Instead, security appliances track flows using Identifier values and validate the identifier/locator relationship cryptographically [RFC4033] [RFC4034] [RFC4035] or non-cryptographically by reading the nonce [ILNP_Nonce].
ILNP还支持新的安全方法，消除对位置相关访问控制列表（ACL）的依赖，而无需数据包身份验证。相反，安全设备使用标识符值跟踪流，并通过加密方式[RFC4033][RFC4034][RFC4035]或通过读取nonce[ILNP_nonce]以非加密方式验证标识符/定位器关系。
The DNS LP record has a more detailed explanation now. LP records enable a site to change its upstream connectivity by changing the L resource records of a single FQDN covering the whole site, thereby providing scalability.
DNS LP记录现在有更详细的解释。LP记录允许站点通过更改覆盖整个站点的单个FQDN的L资源记录来更改其上游连接，从而提供可伸缩性。
DNS-based server load balancing works well with ILNP by using DNS SRV records. DNS SRV records are not new, are widely available in DNS clients and servers, and are widely used today in the IPv4 Internet for server load balancing.
通过使用DNS SRV记录，基于DNS的服务器负载平衡与ILNP配合良好。DNS SRV记录并非新记录，在DNS客户端和服务器中广泛可用，目前在IPv4 Internet中广泛用于服务器负载平衡。
Recent ILNP documents discuss referrals in more detail. A node with a binary referral can find the FQDN using DNS PTR records, which can be authenticated [RFC4033] [RFC4034] [RFC4035]. Approaches such as [Referral_Obj] improve user experience and user capability, so are likely to self-deploy.
最近的ILNP文件更详细地讨论了转介。具有二进制引用的节点可以使用DNS PTR记录查找FQDN，该记录可以通过身份验证[RFC4033][RFC4034][RFC4035]。[Referral_Obj]等方法可以改善用户体验和用户能力，因此可能会自行部署。
Selection from multiple Locators is identical to an IPv4 system selecting from multiple A records for its correspondent. Deployed IP nodes can track reachability via existing host mechanisms or by using the SHIM6 method. [RFC5534]
从多个定位器中进行选择与IPv4系统从多个A记录中为其对应者进行选择相同。部署的IP节点可以通过现有主机机制或使用SHIM6方法跟踪可达性。[RFC5534]
13. Enhanced Efficiency of Mapping Distribution Protocols in Map-and-Encap Schemes (EEMDP)
13. Map和Encap方案（EEMDP）中映射分发协议的增强效率
We present some architectural principles pertaining to the mapping distribution protocols, especially applicable to the map-and-encap (e.g., LISP) type of protocols. These principles enhance the efficiency of the map-and-encap protocols in terms of (1) better utilization of resources (e.g., processing and memory) at Ingress Tunnel Routers (ITRs) and mapping servers, and consequently, (2) reduction of response time (e.g., first-packet delay). We consider how Egress Tunnel Routers (ETRs) can perform aggregation of endpoint ID (EID) address space belonging to their downstream delivery networks, in spite of migration/re-homing of some subprefixes to other ETRs. This aggregation may be useful for reducing the processing load and memory consumption associated with map messages, especially at some resource-constrained ITRs and subsystems of the mapping distribution system. We also consider another architectural concept where the ETRs are organized in a hierarchical manner for the potential benefit of aggregation of their EID address spaces. The two key architectural ideas are discussed in some more detail below. A more complete description can be found in [EEMDP_Considerations] and [EEMDP_Presentation].
我们提出了一些与映射分发协议相关的体系结构原则，尤其适用于map和encap（例如LISP）类型的协议。这些原则在以下方面提高了map和encap协议的效率：（1）在入口隧道路由器（ITR）和映射服务器上更好地利用资源（例如，处理和内存），并因此，（2）减少响应时间（例如，第一包延迟）。我们考虑出口隧道路由器（ETRS）可以执行属于其下游传送网络的端点ID（EID）地址空间的聚合，尽管某些子前缀迁移到其他ETRs。此聚合可用于减少与映射消息相关联的处理负载和内存消耗，尤其是在映射分发系统的某些资源受限的itr和子系统中。我们还考虑了另一种体系结构概念，其中ETRS以分层方式组织，以获得它们的EID地址空间聚集的潜在益处。下面将更详细地讨论这两个关键的体系结构思想。更完整的描述可在[EEMDP_注意事项]和[EEMDP_演示文稿]中找到。
It will be helpful to refer to Figures 1, 2, and 3 in [EEMDP_Considerations] for some of the discussions that follow here below.
参考[EEMDP_注意事项]中的图1、图2和图3将有助于下文的一些讨论。
13.1.2. Management of Mapping Distribution of Subprefixes Spread across Multiple ETRs
13.1.2. 管理分布在多个ETR中的子引用的映射分布
To assist in this discussion, we start with the high level architecture of a map-and-encap approach (it would be helpful to see Figure 1 in [EEMDP_Considerations]). In this architecture, we have the usual ITRs, ETRs, delivery networks, etc. In addition, we have the ID-Locator Mapping (ILM) servers, which are repositories for complete mapping information, while the ILM-Regional (ILM-R) servers can contain partial and/or regionally relevant mapping information.
为了帮助进行讨论，我们从map和encap方法的高级体系结构开始（请参见[EEMDP_注意事项]中的图1）。在这种体系结构中，我们有常用的ITR、ETR、交付网络等。此外，我们还有ID定位器映射（ILM）服务器，它们是完整映射信息的存储库，而ILM区域（ILM-R）服务器可以包含部分和/或区域相关映射信息。
While a large endpoint address space contained in a prefix may be mostly associated with the delivery networks served by one ETR, some fragments (subprefixes) of that address space may be located elsewhere at other ETRs. Let a/20 denote a prefix that is conceptually viewed as composed of 16 subnets of /24 size that are denoted as a1/24, a2/24, ..., a16/24. For example, a/20 is mostly at
虽然前缀中包含的大型端点地址空间可能主要与一个ETR服务的传送网络相关联，但该地址空间的一些片段（子前缀）可能位于其他ETR的其他位置。让a/20表示一个前缀，该前缀在概念上被视为由16个大小为/24的子网组成，这些子网被表示为a1/24、a2/24、…、a16/24。例如，a/20主要是在
ETR1, while only two of its subprefixes a8/24 and a15/24 are elsewhere at ETR3 and ETR2, respectively (see Figure 2 [EEMDP_Considerations]). From the point of view of efficiency of the mapping distribution protocol, it may be beneficial for ETR1 to announce a map for the entire space a/20 (rather than fragment it into a multitude of more-specific prefixes), and provide the necessary exceptions in the map information. Thus, the map message could be in the form of Map:(a/20, ETR1; Exceptions: a8/24, a15/24). In addition, ETR2 and ETR3 announce the maps for a15/24 and a8/24, respectively, and so the ILMs know where the exception EID addresses are located. Now consider a host associated with ITR1 initiating a packet destined for an address a7(1), which is in a7/24 that is not in the exception portion of a/20. Now a question arises as to which of the following approaches would be the best choice:
ETR1，而其子引用a8/24和a15/24中只有两个子引用分别位于ETR3和ETR2的其他位置（见图2[EEMDP_注意事项]）。从映射分发协议效率的角度来看，ETR1宣布整个空间a/20的映射（而不是将其分割为多个更具体的前缀）并在映射信息中提供必要的异常可能是有益的。因此，map消息可以是map的形式：（a/20，ETR1；例外：a8/24，a15/24）。此外，ETR2和ETR3分别宣布a15/24和a8/24的映射，因此ILM知道异常EID地址的位置。现在考虑与ITR1相关联的主机，该分组起始于地址A7（1）的分组，该地址位于A7／24中，而不是在A/20的异常部分。现在出现了以下哪种方法是最佳选择的问题：
1. ILM-R provides the complete mapping information for a/20 to ITR1 including all maps for relevant exception subprefixes.
1. ILM-R提供a/20到ITR1的完整映射信息，包括相关异常子引用的所有映射。
2. ILM-R provides only the directly relevant map to ITR1, which in this case is (a/20, ETR1).
2. ILM-R仅提供与ITR1直接相关的映射，在本例中为（a/20，ETR1）。
In the first approach, the advantage is that ITR1 would have the complete mapping for a/20 (including exception subnets), and it would not have to generate queries for subsequent first packets that are destined to any address in a/20, including a8/24 and a15/24. However, the disadvantage is that if there is a significant number of exception subprefixes, then the very first packet destined for a/20 will experience a long delay, and also the processors at ITR1 and ILM-R can experience overload. In addition, the memory usage at ITR1 can be very inefficient. The advantage of the second approach above is that the ILM-R does not overload resources at ITR1, neither in terms of processing or memory usage, but it needs an enhanced map response in of the form Map:(a/20, ETR1, MS=1), where the MS (More Specific) indicator is set to 1 to indicate to ITR1 that not all subnets in a/20 map to ETR1. The key idea is that aggregation is beneficial, and subnet exceptions must be handled with additional messages or indicators in the maps.
在第一种方法中，优点是ITR1将具有a/20（包括异常子网）的完整映射，并且它不必为发送到a/20中任何地址（包括a8/24和a15/24）的后续第一个数据包生成查询。然而，缺点是，如果存在大量异常子引用，则发送到a/20的第一个数据包将经历较长的延迟，并且ITR1和ILM-R处的处理器也会经历过载。此外，ITR1的内存使用效率可能非常低。上述第二种方法的优点是，ILM-R不会使ITR1的资源过载，无论是在处理还是内存使用方面，但它需要一个增强的map响应，其形式为map:（a/20，ETR1，MS=1），其中MS（更具体的）指示符设置为1，以向ITR1指示并非a/20中的所有子网都映射到ETR1。关键思想是聚合是有益的，子网异常必须通过映射中的附加消息或指示器来处理。
13.1.3. Management of Mapping Distribution for Scenarios with Hierarchy of ETRs and Multihoming
13.1.3. 具有ETR和多主系统层次结构的场景的映射分布管理
Now we highlight another architectural concept related to mapping management (please refer to Figure 3 in [EEMDP_Considerations]). Here we consider the possibility that ETRs may be organized in a hierarchical manner. For instance, ETR7 is higher in the hierarchy relative to ETR1, ETR2, and ETR3, and like-wise ETR8 is higher relative to ETR4, ETR5, and ETR6. For instance, ETRs 1 through 3 can relegate the locator role to ETR7 for their EID address space. In
现在，我们重点介绍与映射管理相关的另一个体系结构概念（请参阅[EEMDP_注意事项]中的图3）。在这里，我们考虑的可能性，ETRS可以组织在一个分层的方式。例如，ETR7在层次结构中相对于ETR1、ETR2和ETR3更高，而与wise ETR8类似，ETR8相对于ETR4、ETR5和ETR6更高。例如，ETRs 1到3可以将其EID地址空间的定位器角色降级为ETR7。在里面
essence, they can allow ETR7 to act as the locator for the delivery networks in their purview. ETR7 keeps a local mapping table for mapping the appropriate EID address space to specific ETRs that are hierarchically associated with it in the level below. In this situation, ETR7 can perform EID address space aggregation across ETRs 1 through 3 and can also include its own immediate EID address space for the purpose of that aggregation. The many details related to this approach and special circumstances involving multihoming of subnets are discussed in detail in [EEMDP_Considerations]. The hierarchical organization of ETRs and delivery networks should help in the future growth and scalability of ETRs and mapping distribution networks. This is essentially recursive map-and-encap, and some of the mapping distribution and management functionality will remain local to topologically neighboring delivery networks that are hierarchically underneath ETRs.
本质上，他们可以允许ETR7充当其权限内交付网络的定位器。ETR7保留一个本地映射表，用于将适当的EID地址空间映射到特定的ETR，这些ETR在下面的级别中按层次结构与其关联。在这种情况下，ETR7可以在ETR 1到3之间执行EID地址空间聚合，并且还可以包含自己的即时EID地址空间以进行聚合。与此方法相关的许多细节以及涉及子网多宿的特殊情况在[EEMDP_注意事项]中进行了详细讨论。ETR和配送网络的分层组织应有助于ETR和地图配送网络的未来增长和可扩展性。这本质上是递归映射和encap，一些映射分发和管理功能将保持在ETR下面的拓扑相邻交付网络的本地。
[EEMDP_Considerations] [EEMDP_Presentation] [FIBAggregatability]
[EEMDP_注意事项][EEMDP_演示文稿][可聚合性]
The scheme described in [EEMDP_Considerations] represents one approach to mapping overhead reduction, and it is a general idea that is applicable to any proposal that includes prefix or EID aggregation. A somewhat similar idea is also used in Level-3 aggregation in the FIB aggregation proposal [FIBAggregatability]. There can be cases where deaggregation of EID prefixes occur in such a way that the bulk of an EID prefix P would be attached to one locator (say, ETR1) while a few subprefixes under P would be attached to other locators elsewhere (say, ETR2, ETR3, etc.). Ideally, such cases should not happen; however, in reality it can happen as the RIR's address allocations are imperfect. In addition, as new IP address allocations become harder to get, an IPv4 prefix owner might split previously unused subprefixes of that prefix and allocate them to remote sites (homed to other ETRs). Assuming these situations could arise in practice, the nature of the solution would be that the response from the mapping server for the coarser site would include information about the more specifics. The solution as presented seems correct.
[EEMDP_注意事项]中描述的方案代表了映射开销减少的一种方法，它是适用于包括前缀或EID聚合的任何方案的一般思想。FIB聚合提案[FIB可聚合性]中的3级聚合也使用了类似的想法。可能存在这样的情况，即EID前缀的解聚集以这样的方式发生：EID前缀P的大部分将连接到一个定位器（例如ETR1），而P下的一些子前缀将连接到其他定位器（例如ETR2、ETR3等）。理想情况下，此类情况不应发生；然而，在现实中，由于RIR的地址分配不完善，这种情况可能发生。此外，随着新的IP地址分配变得越来越难，IPv4前缀所有者可能会分割该前缀以前未使用的子前缀，并将其分配到远程站点（驻留到其他ETR）。假设在实践中可能出现这些情况，解决方案的本质是映射服务器对较粗糙站点的响应将包含有关更详细的信息。所提出的解决办法似乎是正确的。
The proposal mentions that in Approach 1, the ID-Locator Mapping (ILM) system provides the complete mapping information for an aggregate EID prefix to a querying ITR, including all the maps for the relevant exception subprefixes. The sheer number of such more-specifics can be worrisome, for example, in LISP. What if a company's mobile-node EIDs came out of their corporate EID prefix? Approach 2 is far better but still there may be too many entries for
该提案提到，在方法1中，ID定位器映射（ILM）系统提供了聚合EID前缀到查询ITR的完整映射信息，包括相关异常子引用的所有映射。例如，在LISP中，这样更多细节的数量可能令人担忧。如果公司的移动节点EID来自其公司EID前缀，该怎么办？方法2要好得多，但仍然可能有太多的条目供选择
a regional ILM to store. In Approach 2, the ILM communicates that there are more specifics but does not communicate their mask-length. A suggested improvement would be that rather than saying that there are more specifics, indicate what their mask-lengths are. There can be multiple mask lengths. This number should be pretty small for IPv4 but can be large for IPv6.
要存储的区域ILM。在方法2中，ILM告知有更多细节，但不告知其掩码长度。一个建议的改进是，与其说有更多细节，不如指出它们的遮罩长度。可以有多个遮罩长度。这个数字对于IPv4应该很小，但对于IPv6可能很大。
Later in the proposal, a different problem is addressed, involving a hierarchy of ETRs and how aggregation of EID prefixes from lower-level ETRs can be performed at a higher-level ETR. The various scenarios here are well illustrated and described. This seems like a good idea, and a solution like LISP can support this as specified. As any optimization scheme would inevitably add some complexity; the proposed scheme for enhancing mapping efficiency comes with some of its own overhead. The gain depends on the details of specific EID blocks, i.e., how frequently the situations (such as an ETR that has a bigger EID block with a few holes) arise.
在本提案的后面，将讨论一个不同的问题，涉及ETR的层次结构，以及如何在更高级别的ETR上聚合来自较低级别ETR的EID前缀。这里的各种场景都得到了很好的说明和描述。这似乎是一个好主意，像LISP这样的解决方案可以按照规定支持这一点。因为任何优化方案都不可避免地会增加一些复杂性；为提高映射效率而提出的方案本身也有一些开销。增益取决于特定EID块的细节，即情况出现的频率（例如具有较大EID块且带有几个孔的ETR）。
There are two main points in the critique that are addressed here: (1) The gain depends on the details of specific EID blocks, i.e., how frequently the situations arise such as an ETR having a bigger EID block with a few holes, and (2) Approach 2 is lacking an added feature of conveying just the mask-length of the more specifics that exist as part of the current map response.
这里讨论的评论中有两个要点：（1）增益取决于特定EID块的细节，即出现这种情况的频率，例如ETR有一个更大的EID块和几个孔，以及（2）方法2缺少一个额外的功能，即只传递作为当前map响应一部分存在的更多细节的掩码长度。
Regarding comment (1) above, there are multiple possibilities
regarding how situations can arise, resulting in allocations having
holes in them. An example of one of these possibilities is as
follows. Org-A has historically received multiple /20s, /22s, and
/24s over the course of time that are adjacent to each other. At the
present time, these prefixes would all aggregate to a /16 but for the
fact that just a few of the underlying /24s have been allocated
elsewhere historically to other organizations by an RIR or ISPs. An
example of a second possibility is that Org-A has an allocation of a
/16. It has suballocated a /22 to one of its subsidiaries, and
subsequently sold the subsidiary to another Org-B. For ease of
keeping the /22 subnet up and running without service disruption, the
/22 subprefix is allowed to be transferred in the acquisition
process. Now the /22 subprefix originates from a different AS and is
serviced by a different ETR (as compared to the parent \16 prefix).
We are in the process of performing an analysis of RIR allocation
data and are aware of other studies (notably at UCLA) that are also
performing similar analysis to quantify the frequency of occurrence
of the holes. We feel that the problem that has been addressed is a
realistic one, and the proposed scheme would help reduce the
overheads associated with the mapping distribution system.
Regarding comment (1) above, there are multiple possibilities
regarding how situations can arise, resulting in allocations having
holes in them. An example of one of these possibilities is as
follows. Org-A has historically received multiple /20s, /22s, and
/24s over the course of time that are adjacent to each other. At the
present time, these prefixes would all aggregate to a /16 but for the
fact that just a few of the underlying /24s have been allocated
elsewhere historically to other organizations by an RIR or ISPs. An
example of a second possibility is that Org-A has an allocation of a
/16. It has suballocated a /22 to one of its subsidiaries, and
subsequently sold the subsidiary to another Org-B. For ease of
keeping the /22 subnet up and running without service disruption, the
/22 subprefix is allowed to be transferred in the acquisition
process. Now the /22 subprefix originates from a different AS and is
serviced by a different ETR (as compared to the parent \16 prefix).
We are in the process of performing an analysis of RIR allocation
data and are aware of other studies (notably at UCLA) that are also
performing similar analysis to quantify the frequency of occurrence
of the holes. We feel that the problem that has been addressed is a
realistic one, and the proposed scheme would help reduce the
overheads associated with the mapping distribution system.
Regarding comment (2) above, the suggested modification to Approach 2 would be definitely beneficial. In fact, we feel that it would be fairly straightforward to dynamically use Approach 1 or Approach 2 (with the suggested modification), depending on whether there are only a few (e.g., <=5) or many (e.g., >5) more specifics, respectively. The suggested modification of notifying the mask-length of the more specifics in the map response is indeed very helpful because then the ITR would not have to resend a map-query for EID addresses that match the EID address in the previous query up to at least mask-length bit positions. There can be a two-bit field in the map response that would be interpreted as follows.
关于上述评论（2），建议对方法2进行修改肯定是有益的。事实上，我们认为动态地使用方法1或方法2（带有建议的修改）是相当简单的，这取决于是否分别有少数（例如<=5）或许多（例如>5）更多的细节。建议的修改是通知掩码长度映射响应中的更多细节，这确实非常有用，因为这样ITR就不必重新发送映射查询，以查找与前一查询中的EID地址匹配的EID地址，至少达到掩码长度位位置。map响应中可能有一个两位字段，其解释如下。
(a) value 00: there are no more specifics
(a) 值00：没有更多细节
(b) value 01: there are more specifics and their exact information follows in additional map-responses
(b) 值01：在其他地图响应中有更多细节及其确切信息
(c) value 10: there are more-specifics and the mask-length of the next more-specific is indicated in the current map-response.
(c) 值10：有更多细节，下一个更具体的掩码长度在当前映射响应中指示。
An additional field will be included that will be used to specify the mask-length of the next more-specific in the case of value 10 (case (c) above).
将包括一个附加字段，用于在值为10的情况下（上述情况（c））指定下一个更具体的掩码长度。
As the Internet continues its rapid growth, router memory size and CPU cycle requirements are outpacing feasible hardware upgrade schedules. We propose to solve this problem by applying aggregation with increasing scopes to gradually evolve the routing system towards a scalable structure. At each evolutionary step, our solution is able to interoperate with the existing system and provide immediate benefits to adopters to enable deployment. This document summarizes the need for an evolutionary design, the relationship between our proposal and other revolutionary proposals, and the steps of aggregation with increasing scopes. Our detailed proposal can be found in [Evolution].
随着互联网的持续快速增长，路由器内存大小和CPU周期要求超过了可行的硬件升级计划。我们建议通过应用范围不断扩大的聚合来解决这个问题，从而使路由系统逐渐向可伸缩结构发展。在每一个演进步骤中，我们的解决方案都能够与现有系统进行互操作，并为采用者提供即时的好处，从而实现部署。本文件总结了渐进式设计的必要性、我们的提案与其他革命性提案之间的关系，以及随着范围的扩大而聚合的步骤。我们的详细建议可在[进化]中找到。
Multiple different views exist regarding the routing scalability problem. Networks differ vastly in goals, behavior, and resources, giving each a different view of the severity and imminence of the scalability problem. Therefore, we believe that, for any solution to be adopted, it will start with one or a few early adopters and may not ever reach the entire Internet. The evolutionary approach
关于路由可伸缩性问题，存在多种不同的观点。网络在目标、行为和资源上有着巨大的差异，每个网络对可伸缩性问题的严重性和紧迫性有着不同的看法。因此，我们相信，对于任何要采用的解决方案，它将从一个或几个早期采用者开始，并且可能永远不会到达整个互联网。进化方法
recognizes that changes to the Internet can only be a gradual process with multiple stages. At each stage, adopters are driven by and rewarded with solving an immediate problem. Each solution must be deployable by individual networks who deem it necessary at a time they deem it necessary, without requiring coordination from other networks, and the solution has to bring immediate relief to a single first-mover.
认识到互联网的变化只能是一个多阶段的渐进过程。在每个阶段，采用者都会受到解决眼前问题的驱动并获得奖励。每个解决方案必须可由认为有必要的各个网络在其认为有必要的时候部署，而不需要其他网络的协调，并且该解决方案必须立即缓解单个先行者的压力。
Most proposals take a revolutionary approach that expects the entire Internet to eventually move to some new design whose main benefits would not materialize until the vast majority of the system has been upgraded; their incremental deployment plan simply ensures interoperation between upgraded and legacy parts of the system. In contrast, the evolutionary approach depicts a system where changes may happen here and there as needed, but there is no dependency on the system as a whole making a change. Whoever takes a step forward gains the benefit by solving his own problem, without depending on others to take actions. Thus, deployability includes not only interoperability, but also the alignment of costs and gains.
大多数提案都采取了革命性的方法，期望整个互联网最终转向某种新的设计，其主要好处在绝大多数系统升级之前不会实现；他们的增量部署计划只是确保系统升级部分和遗留部分之间的互操作。相比之下，进化方法描述了一个系统，在这个系统中，可能会根据需要在这里或那里发生变化，但不依赖于整个系统进行变化。谁向前迈出一步，谁就可以通过解决自己的问题而获益，而不必依赖他人采取行动。因此，可部署性不仅包括互操作性，还包括成本和收益的一致性。
The main differences between our approach and more revolutionary map-and-encap proposals are: (a) we do not start with a pre-defined boundary between edge and core; and (b) each step brings immediate benefits to individual first-movers. Note that our proposal neither interferes nor prevents any revolutionary host-based solutions such as ILNP from being rolled out. However, host-based solutions do not bring useful impact until a large portion of hosts have been upgraded. Thus, even if a host-based solution is rolled out in the long run, an evolutionary solution is still needed for the near term.
我们的方法与更具革命性的map和encap方案之间的主要区别在于：（a）我们不从边缘和核心之间的预定义边界开始；（b）每一步都会为个人的先行者带来即时利益。请注意，我们的建议既不会干扰也不会阻止任何革命性的基于主机的解决方案（如ILNP）的推出。但是，在大部分主机升级之前，基于主机的解决方案不会带来有用的影响。因此，即使从长远来看推出了基于主机的解决方案，短期内仍需要一个渐进的解决方案。
Aggregating many routing entries to a fewer number is a basic approach to improving routing scalability. Aggregation can take different forms and be done within different scopes. In our design, the aggregation scope starts from a single router, then expands to a single network and neighbor networks. The order of the following steps is not fixed but is merely a suggestion; it is under each individual network's discretion which steps they choose to take based on their evaluation of the severity of the problems and the affordability of the solutions.
将多个路由条目聚合为较少的数目是提高路由可伸缩性的基本方法。聚合可以采用不同的形式，并且可以在不同的范围内完成。在我们的设计中，聚合范围从单个路由器开始，然后扩展到单个网络和邻居网络。以下步骤的顺序不是固定的，只是一个建议；根据对问题严重性和解决方案可承受性的评估，每个网络可自行决定采取哪些步骤。
1. FIB Aggregation (FA) in a single router. A router algorithmically aggregates its FIB entries without changing its RIB or its routing announcements. No coordination among routers
1. 单个路由器中的FIB聚合（FA）。路由器通过算法聚合其FIB条目，而不改变其RIB或其路由公告。路由器之间没有协调
is needed, nor any change to existing protocols. This brings scalability relief to individual routers with only a software upgrade.
也不需要对现有协议进行任何更改。这只需软件升级就可以减轻单个路由器的可伸缩性。
2. Enabling 'best external' on Provider Edge routers (PEs), Autonomous System Border Routers (ASBRs), and Route Reflectors (RRs), and turning on next-hop-self on RRs. For hierarchical networks, the RRs in each Point of Presence (PoP) can serve as a default gateway for nodes in the PoP, thus allowing the non-RR nodes in each PoP to maintain smaller routing tables that only include paths that egress that PoP. This is known as 'topology-based mode' Virtual Aggregation, and can be done with existing hardware and configuration changes only. Please see [Evolution_Grow_Presentation] for details.
2. 启用“最佳外部”提供商边缘路由器（PEs）、自治系统边界路由器（ASBR）和路由反射器（RRs），并启用下一跳自开RRs。对于分层网络，每个存在点（PoP）中的RR可以用作PoP中节点的默认网关，从而允许每个PoP中的非RR节点维护较小的路由表，该路由表仅包括从该PoP出去的路径。这称为“基于拓扑的模式”虚拟聚合，只能通过现有硬件和配置更改来完成。有关详细信息，请参见[Evolution\u Grow\u Presentation]。
3. Virtual Aggregation (VA) in a single network. Within an AS, some fraction of existing routers are designated as Aggregation Point Routers (APRs). These routers are either individually or collectively maintain the full FIB table. Other routers may suppress entries from their FIBs, instead forwarding packets to APRs, which will then tunnel the packets to the correct egress routers. VA can be viewed as an intra-domain map-and-encap system to provide the operators with a control mechanism for the FIB size in their routers.
3. 单个网络中的虚拟聚合（VA）。在AS中，一些现有路由器被指定为聚合点路由器（APR）。这些路由器单独或共同维护完整的FIB表。其他路由器可能会抑制来自其FIB的条目，而不是将数据包转发到APR，后者随后将数据包隧道到正确的出口路由器。VA可以被视为一个域内映射和encap系统，为运营商的路由器中的FIB大小提供控制机制。
4. VA across neighbor networks. When adjacent networks have VA deployed, they can go one step further by piggybacking egress router information on existing BGP announcements, so that packets can be tunneled directly to a neighbor network's egress router. This improves packet delivery performance by performing the encapsulation/decapsulation only once across these neighbor networks, as well as reducing the stretch of the path.
4. VA跨邻居网络。当相邻网络部署了VA时，它们可以更进一步，在现有BGP公告上搭载出口路由器信息，以便数据包可以直接通过隧道传输到相邻网络的出口路由器。这通过在这些相邻网络上只执行一次封装/解封装以及减少路径的拉伸来提高数据包交付性能。
5. Reducing RIB Size by separating the control plane from the data plane. Although a router's FIB can be reduced by FA or VA, it usually still needs to maintain the full RIB to produce complete routing announcements to its neighbors. To reduce the RIB size, a network can set up special boxes, which we call controllers, to take over the External BGP (eBGP) sessions from border routers. The controllers receive eBGP announcements, make routing decisions, and then inform other routers in the same network of how to forward packets, while the regular routers just focus on the job of forwarding packets. The controllers, not being part of the data path, can be scaled using commodity hardware.
5. 通过将控制平面与数据平面分离来减小加强筋尺寸。虽然路由器的FIB可以通过FA或VA来减少，但它通常仍然需要保持完整的RIB以向其邻居生成完整的路由公告。为了减少肋骨的尺寸，网络可以设置特殊的盒子，我们称之为控制器，从边界路由器接管外部BGP（eBGP）会话。控制器接收eBGP通知，做出路由决定，然后通知同一网络中的其他路由器如何转发数据包，而常规路由器只关注转发数据包的工作。控制器不是数据路径的一部分，可以使用商品硬件进行缩放。
6. Insulating forwarding routers from routing churn. For routers with a smaller RIB, the rate of routing churn is naturally reduced. Further reduction can be achieved by not announcing
6. 将转发路由器与路由搅动隔离。对于RIB较小的路由器，路由搅动率自然会降低。通过不宣布，可以实现进一步的减排
failures of customer prefixes into the core, but handling these failures in a data-driven fashion, e.g., a link failure to an edge network is not reported unless and until there are data packets that are heading towards the failed link.
客户前缀进入核心的故障，但以数据驱动的方式处理这些故障，例如，除非有数据包朝向故障链路，否则不会报告到边缘网络的链路故障。
[Evolution] [Evolution_Grow_Presentation]
[进化][进化成长演示]
All of the RRG proposals that scale the routing architecture share one fundamental approach, route aggregation, in different forms, e.g., LISP removes "edge prefixes" using encapsulation at ITRs, and ILNP achieves the goal by locator rewrite. In this evolutionary path proposal, each stage of the evolution applies aggregation with increasing scopes to solve a specific scalability problem, and eventually the path leads towards global routing scalability. For example, it uses FIB aggregation at the single router level, virtual aggregation at the network level, and then between neighboring networks at the inter-domain level.
所有扩展路由体系结构的RRG方案都以不同的形式共享一种基本方法，即路由聚合，例如，LISP在ITRs使用封装移除“边缘前缀”，ILNP通过定位器重写实现这一目标。在这个进化路径方案中，进化的每个阶段都应用范围不断扩大的聚合来解决特定的可伸缩性问题，最终该路径将通向全局路由可伸缩性。例如，它在单路由器级别使用FIB聚合，在网络级别使用虚拟聚合，然后在域间级别在相邻网络之间使用虚拟聚合。
Compared to other proposals, this proposal has the lowest hurdle to deployment, because it does not require that all networks move to use a global mapping system or upgrade all hosts, and it is designed for each individual network to get immediate benefits after its own deployment.
与其他方案相比，此方案的部署难度最低，因为它不要求所有网络都使用全局映射系统或升级所有主机，而且它是为每个单独的网络设计的，以便在其自身部署后立即获得好处。
Criticisms of this proposal fall into two types. The first type concerns several potential issues in the technical design as listed below:
对这项建议的批评分为两类。第一类涉及技术设计中的几个潜在问题，如下所示：
1. FIB aggregation, at level-3 and level-4, may introduce extra routable space. Concerns have been raised about the potential routing loops resulting from forwarding otherwise non-routable packets, and the potential impact on Reverse Path Forwarding (RPF) checking. These concerns can be addressed by choosing a lower level of aggregation and by adding null routes to minimize the extra space, at the cost of reduced aggregation gain.
1. 3级和4级的FIB聚合可能会引入额外的可路由空间。人们对转发不可路由的数据包可能导致的路由循环以及对反向路径转发（RPF）检查的潜在影响表示担忧。这些问题可以通过选择较低级别的聚合和添加空路由来解决，以减少聚合增益为代价，最小化额外空间。
2. Virtual Aggregation changes the traffic paths in an ISP network, thereby introducing stretch. Changing the traffic path may also impact the reverse path checking practice used to filter out packets from spoofed sources. More analysis is need to identify the potential side-effects of VA and to address these issues.
2. 虚拟聚合会改变ISP网络中的流量路径，从而引入拉伸。更改流量路径还可能影响反向路径检查实践，该实践用于从欺骗源中过滤出数据包。需要进行更多的分析，以确定VA的潜在副作用，并解决这些问题。
3. The current Virtual Aggregation description is difficult to understand, due to its multiple options for encapsulation and popular prefix configurations, which makes the mechanism look overly complicated. More thought is needed to simplify the design and description.
3. 当前的虚拟聚合描述很难理解，因为它有多种封装选项和流行的前缀配置，这使得机制看起来过于复杂。需要更多的思考来简化设计和描述。
4. FIB Aggregation and Virtual Aggregation may require additional operational cost. There may be new design trade-offs that the operators need to understand in order to select the best option for their networks. More analysis is needed to identify and quantify all potential operational costs.
4. FIB聚合和虚拟聚合可能需要额外的运营成本。运营商可能需要了解新的设计权衡，以便为其网络选择最佳选项。需要更多的分析来确定和量化所有潜在的运营成本。
5. In contrast to a number of other proposals, this solution does not provide mobility support. It remains an open question as to whether the routing system should handle mobility.
5. 与许多其他提案不同，该解决方案不提供移动支持。路由系统是否应该处理移动性仍然是一个悬而未决的问题。
The second criticism is whether deploying quick fixes like FIB aggregation would alleviate scalability problems in the short term and reduce the incentives for deploying a new architecture; and whether an evolutionary approach would end up with adding more and more patches to the old architecture, and not lead to a fundamentally new architecture as the proposal had expected. Though this solution may get rolled out more easily and quickly, a new architecture, if/ once deployed, could solve more problems with cleaner solutions.
第二个批评是，部署FIB聚合之类的快速修复是否会在短期内缓解可伸缩性问题，并降低部署新体系结构的动机；以及进化方法最终是否会在旧体系结构上添加越来越多的补丁，而不会像提案所预期的那样产生一个全新的体系结构。尽管此解决方案可能会更容易、更快速地推出，但一个新的体系结构（如果/一旦部署）可以用更干净的解决方案解决更多问题。
No rebuttal was submitted for this proposal.
没有人对这项提议提出反驳。
Name-based sockets are an evolution of the existing address-based sockets, enabling applications to initiate and receive communication sessions based on the use of domain names in lieu of IP addresses. Name-based sockets move the existing indirection from domain names to IP addresses from its current position in applications down to the IP layer. As a result, applications communicate exclusively based on domain names, while the discovery, selection, and potentially in-session re-selection of IP addresses is centrally performed by the IP stack itself.
基于名称的套接字是现有基于地址的套接字的演变，使应用程序能够在使用域名代替IP地址的基础上启动和接收通信会话。基于名称的套接字将现有的间接寻址从域名移动到IP地址，从其在应用程序中的当前位置向下移动到IP层。因此，应用程序只能基于域名进行通信，而IP地址的发现、选择以及会话中可能的重新选择则由IP堆栈本身集中执行。
Name-based sockets help mitigate the Internet routing scalability problem by separating naming and addressing more consistently than what is possible with the existing address-based sockets. This supports IP address aggregation because it simplifies the use of IP
与现有的基于地址的套接字相比，基于名称的套接字可以更一致地分离命名和寻址，从而有助于缓解Internet路由可伸缩性问题。这支持IP地址聚合，因为它简化了IP地址的使用
addresses with high topological significance, as well as the dynamic replacement of IP addresses during network-topological and host-attachment changes.
具有高度拓扑意义的地址，以及在网络拓扑和主机连接更改期间动态替换IP地址。
A particularly positive effect of name-based sockets on Internet routing scalability is the new incentives for edge network operators to use provider-assigned IP addresses, which are more aggregatable than the typically preferred provider-independent IP addresses. Even though provider-independent IP addresses are harder to get and more expensive than provider-assigned IP addresses, many operators desire provider-independent addresses due to the high indirect cost of provider-assigned IP addresses. This indirect cost is comprised of both difficulties in multihoming, and tedious and largely manual renumbering upon provider changes.
基于名称的套接字对Internet路由可伸缩性的一个特别积极的影响是，边缘网络运营商使用提供商分配的IP地址的新激励，这些IP地址比通常首选的独立于提供商的IP地址更易于聚合。尽管与提供商分配的IP地址相比，独立于提供商的IP地址更难获得且成本更高，但由于提供商分配的IP地址的间接成本较高，许多运营商希望获得独立于提供商的IP地址。这种间接成本既包括多宿主的困难，也包括提供者更改时繁琐且主要是手动的重新编号。
Name-based sockets reduce the indirect cost of provider-assigned IP addresses in three ways, and hence make the use of provider-assigned IP addresses more acceptable: (1) They enable fine-grained and responsive multihoming. (2) They simplify renumbering by offering an easy means to replace IP addresses in referrals with domain names. This helps avoiding updates to application and operating system configurations, scripts, and databases during renumbering. (3) They facilitate low-cost solutions that eliminate renumbering altogether. One such low-cost solution is IP address translation, which in combination with name-based sockets loses its adverse impact on applications.
基于名称的套接字通过三种方式降低了提供者分配的IP地址的间接成本，从而使提供者分配的IP地址的使用更容易接受：（1）它们支持细粒度和响应性的多宿主。（2） 他们提供了一种简单的方法，用域名替换推荐中的IP地址，从而简化了重新编号。这有助于避免在重新编号期间更新应用程序和操作系统配置、脚本和数据库。（3） 它们促进了完全消除重新编号的低成本解决方案。其中一种低成本的解决方案是IP地址转换，它与基于名称的套接字相结合，将失去对应用程序的不利影响。
The prerequisite for a positive effect of name-based sockets on Internet routing scalability is their adoption in operating systems and applications. Operating systems should be augmented to offer name-based sockets as a new alternative to the existing address-based sockets, and applications should use name-based sockets for their communications. Neither an instantaneous, nor an eventually complete transition to name-based sockets is required, yet the positive effect on Internet routing scalability will grow with the extent of this transition.
基于名称的套接字对Internet路由可伸缩性产生积极影响的先决条件是在操作系统和应用程序中采用它们。应扩充操作系统，以提供基于名称的套接字，作为现有基于地址的套接字的新替代方案，应用程序应使用基于名称的套接字进行通信。不需要立即过渡到基于名称的套接字，也不需要最终完全过渡到基于名称的套接字，但是这种过渡的程度会增加对Internet路由可伸缩性的积极影响。
Name-based sockets were hence designed with a focus on deployment incentives, comprising both immediate deployment benefits as well as low deployment costs. Name-based sockets provide a benefit to application developers because the alleviation of applications from IP address management responsibilities simplifies and expedites application development. This benefit is immediate owing to the backwards compatibility of name-based sockets with legacy applications and legacy peers. The appeal to application developers, in turn, is an immediate benefit for operating system vendors who adopt name-based sockets.
因此，基于名称的套接字设计的重点是部署激励，包括即时部署好处和低部署成本。基于名称的套接字为应用程序开发人员带来了好处，因为减轻了应用程序的IP地址管理责任，简化并加快了应用程序开发。由于基于名称的套接字与旧式应用程序和旧式对等机的向后兼容性，这一好处立竿见影。反过来，对应用程序开发人员的吸引力对于采用基于名称的套接字的操作系统供应商来说是一个立竿见影的好处。
Name-based sockets furthermore minimize deployment costs: Alternative techniques to separate naming and addressing provide applications with "surrogate IP addresses" that dynamically map onto regular IP addresses. A surrogate IP address is indistinguishable from a regular IP address for applications, but does not have the topological significance of a regular IP address. Mobile IP and the Host Identity Protocol are examples of such separation techniques. Mobile IP uses "home IP addresses" as surrogate IP addresses with reduced topological significance. The Host Identity Protocol uses "host identifiers" as surrogate IP addresses without topological significance. A disadvantage of surrogate IP addresses is their incurred cost in terms of extra administrative overhead and, for some techniques, extra infrastructure. Since surrogate IP addresses must be resolvable to the corresponding regular IP addresses, they must be provisioned in the DNS or similar infrastructure. Mobile IP uses a new infrastructure of home agents for this purpose, while the Host Identity Protocol populates DNS servers with host identities. Name-based sockets avoid this cost because they function without surrogate IP addresses, and hence without the provisioning and infrastructure requirements that accompany surrogate addresses.
基于名称的套接字进一步降低了部署成本：分离命名和寻址的替代技术为应用程序提供了动态映射到常规IP地址的“代理IP地址”。对于应用程序，代理IP地址与常规IP地址无法区分，但不具有常规IP地址的拓扑意义。移动IP和主机身份协议是此类分离技术的示例。移动IP使用“家庭IP地址”作为代理IP地址，拓扑重要性降低。主机标识协议使用“主机标识符”作为代理IP地址，没有拓扑意义。代理IP地址的一个缺点是，它们会产生额外的管理开销，对于某些技术，还会产生额外的基础设施。由于代理IP地址必须可解析为相应的常规IP地址，因此必须在DNS或类似基础结构中提供代理IP地址。移动IP为此目的使用新的家庭代理基础设施，而主机标识协议使用主机标识填充DNS服务器。基于名称的套接字避免了这一成本，因为它们在没有代理IP地址的情况下工作，因此没有伴随代理地址的资源调配和基础结构要求。
Certainly, some edge networks will continue to use provider-independent addresses despite name-based sockets, perhaps simply due to inertia. But name-based sockets will help reduce the number of those networks, and thus have a positive impact on Internet routing scalability.
当然，一些边缘网络将继续使用独立于提供商的地址，尽管使用基于名称的套接字，这可能仅仅是由于惯性。但基于名称的套接字将有助于减少这些网络的数量，从而对Internet路由可伸缩性产生积极影响。
A more comprehensive description of name-based sockets can be found in [Name_Based_Sockets].
有关基于名称的套接字的更全面的描述，请参见[基于名称的套接字]。
[Name_Based_Sockets]
[基于名称的\u套接字]
Name-based sockets contribution to the routing scalability problem is to decrease the reliance on PI addresses, allowing a greater use of PA addresses, and thus a less fragmented routing table. It provides end hosts with an API which makes the applications address-agnostic. The name abstraction allows the hosts to use any type of locator, independent of format or provider. This increases the motivation and usability of PA addresses. Some applications, in particular bootstrapping applications, may still require hard coded IP addresses, and as such will still motivate the use of PI addresses.
基于名称的套接字对路由可伸缩性问题的贡献是减少对PI地址的依赖，允许更多地使用PA地址，从而减少路由表的碎片。它为终端主机提供了一个API，使应用程序地址不可知。名称抽象允许主机使用任何类型的定位器，与格式或提供者无关。这增加了PA地址的动机和可用性。一些应用程序，特别是引导应用程序，可能仍然需要硬编码的IP地址，因此仍然会鼓励使用PI地址。
The main incentives and drivers are geared towards the transition of applications to the name-based sockets. Adoption by applications will be driven by benefits in terms of reduced application development cost. Legacy applications are expected to migrate to the new API at a slower pace, as the name-based sockets are backwards compatible, this can happen in a per-host fashion. Also, not all applications can be ported to a FQDN dependent infrastructure, e.g., DNS functions. This hurdle is manageable, and may not be a definite obstacle for the transition of a whole domain, but it needs to be taken into account when striving for mobility/multihoming of an entire site. The transition of functions on individual hosts may be trivial, either through upgrades/changes to the OS or as linked libraries. This can still happen incrementally and independently, as compatibility is not affected by the use of name-based sockets.
主要的激励和驱动因素是面向应用程序向基于名称的套接字的过渡。应用程序的采用将受到降低应用程序开发成本的好处的推动。传统应用程序预计将以较慢的速度迁移到新API，因为基于名称的套接字是向后兼容的，这可能以每主机的方式发生。此外，并非所有应用程序都可以移植到依赖FQDN的基础结构，例如DNS功能。这一障碍是可管理的，可能不是整个领域过渡的明确障碍，但在努力实现整个站点的移动性/多归属性时，需要考虑到这一障碍。通过升级/更改操作系统或作为链接库，单个主机上的功能转换可能很简单。由于兼容性不受基于名称的套接字使用的影响，因此这种情况仍然可以以增量方式独立发生。
Name-based sockets rely on the transition of individual applications and are backwards compatible, so they do not require bilateral upgrades. This allows each host to migrate its applications independently. Name-based sockets may make an individual client agnostic to the networking medium, be it PA/PI IP-addresses or in a the future an entirely different networking medium. However, an entire edge-network, with internal and external services will not be able to make a complete transition in the near future. Hence, even if a substantial fraction of the hosts in an edge-network use name-based sockets, PI addresses may still be required by the edge-network. In short, new services may be implemented using name-based sockets, old services may be ported. Name-based sockets provide an increased motivation to move to PA-addresses as actual provider independence relies less and less on PI-addressing.
基于名称的套接字依赖于单个应用程序的转换，并且向后兼容，因此它们不需要双边升级。这允许每个主机独立迁移其应用程序。基于名称的套接字可能使单个客户端对网络介质不可知，无论是PA/PI IP地址还是将来完全不同的网络介质。但是，拥有内部和外部服务的整个边缘网络在不久的将来将无法完成过渡。因此，即使边缘网络中相当一部分主机使用基于名称的套接字，边缘网络可能仍然需要PI地址。简而言之，新服务可以使用基于名称的套接字实现，旧服务可以移植。由于实际的提供者独立性越来越不依赖于PI寻址，因此基于名称的套接字提供了更大的动机来移动到PA地址。
No rebuttal was submitted for this proposal.
没有人对这项提议提出反驳。
16. Routing and Addressing in Networks with Global Enterprise Recursion (IRON-RANGER)
16. 具有全局企业递归的网络中的路由和寻址（IRON-RANGER）
RANGER is a locator/identifier separation approach that uses IP-in-IP encapsulation to connect edge networks across transit networks such as the global Internet. End systems use endpoint interface identifier (EID) addresses that may be routable within edge networks but do not appear in transit network routing tables. EID to Routing
RANGER是一种定位器/标识符分离方法，它使用IP-in-IP封装来连接跨传输网络（如全球互联网）的边缘网络。终端系统使用端点接口标识符（EID）地址，这些地址可以在边缘网络内路由，但不会出现在传输网络路由表中。EID到路由
Locator (RLOC) address bindings are instead maintained in mapping tables and also cached in default router FIBs (i.e., very much the same as for the global DNS and its associated caching resolvers). RANGER enterprise networks are organized in a recursive hierarchy with default mappers connecting lower layers to the next higher layer in the hierarchy. Default mappers forward initial packets and push mapping information to lower-tier routers and end systems through secure redirection.
定位器（RLOC）地址绑定在映射表中维护，也缓存在默认路由器FIB中（即，与全局DNS及其关联的缓存解析程序非常相似）。RANGER enterprise网络以递归层次结构组织，默认映射器将较低层连接到层次结构中的下一个较高层。默认映射器通过安全重定向转发初始数据包并将映射信息推送到较低层路由器和终端系统。
RANGER is an architectural framework derived from the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).
RANGER是从站点内自动隧道寻址协议（ISATAP）派生的体系结构框架。
o provides a scalable routing system alternative in instances where dynamic routing protocols are impractical
o 在动态路由协议不可行的情况下，提供可扩展的路由系统替代方案
o naturally supports a recursively-nested "network-of-networks" (or, "enterprise-within-enterprise") hierarchy
o 自然支持递归嵌套的“网络网络”（或“企业内部企业”）层次结构
o uses asymmetric security mechanisms (i.e., secure neighbor discovery) to secure router discovery and the redirection mechanism
o 使用非对称安全机制（即安全邻居发现）来保护路由器发现和重定向机制
o can quickly detect path failures and pick alternate routes
o 可以快速检测路径故障并选择备用路由
o naturally supports provider-independent addressing
o 自然支持独立于提供者的寻址
o support for site multihoming and traffic engineering
o 支持站点多主和流量工程
o ingress filtering for multihomed sites
o 多宿主站点的入口过滤
o mobility-agile through explicit cache invalidation (much more reactive than dynamic DNS)
o 通过显式缓存失效实现灵活的移动性（比动态DNS反应性强得多）
o supports neighbor discovery and neighbor unreachability detection over tunnels
o 支持隧道上的邻居发现和邻居不可达性检测
o no changes to end systems
o 终端系统无变化
o no changes to most routers
o 大多数路由器没有变化
o supports IPv6 transition
o 支持IPv6转换
o compatible with true identity/locator split mechanisms such as HIP (i.e., packets contain a HIP Host Identity Tag (HIT) as an end system identifier, IPv6 address as endpoint interface identifier (EID) in the inner IP header and IPv4 address as Routing LOCator (RLOC) in the outer IP header)
o 与真正的标识/定位器拆分机制（如HIP）兼容（即，数据包包含HIP主机标识标签（HIT）作为终端系统标识符，IPv6地址作为内部IP报头中的端点接口标识符（EID），IPv4地址作为外部IP报头中的路由定位器（RLOC））
o prototype code available
o 原型代码可用
o new code needed in enterprise border routers
o 企业边界路由器需要新代码
o locator/path liveness detection using RFC 4861 neighbor unreachability detection (i.e., extra control messages, but data-driven) [RFC4861]
o 使用RFC 4861邻居不可达性检测的定位器/路径活跃度检测（即，额外控制消息，但数据驱动）[RFC4861]
[IRON] [RANGER_Scen] [VET] [SEAL] [RFC5201] [RFC5214] [RFC5720]
[铁制][护林员西][兽医][印章][RFC5201][RFC5214][RFC5720]
The RANGER architectural framework is intended to be applicable for a Core-Edge Separation (CES) architecture for scalable routing, using either IPv4 or IPv6 -- or using both in an integrated system which may carry one protocol over the other.
RANGER体系结构框架旨在适用于可扩展路由的核心边缘分离（CES）体系结构，使用IPv4或IPv6，或者在一个集成系统中同时使用这两种协议，该集成系统可能承载一种协议而不是另一种协议。
However, despite [IRON] being readied for publication as an experimental RFC, the framework falls well short of the level of detail required to envisage how it could be used to implement a practical scalable routing solution. For instance, the document contains no specification for a mapping protocol, or how the mapping lookup system would work on a global scale.
然而，尽管[IRON]已经准备好作为实验性RFC发布，但该框架还远远没有达到设想如何使用它来实现实用的可伸缩路由解决方案所需的详细程度。例如，该文档不包含映射协议的规范，也不包含映射查找系统在全局范围内的工作方式。
There is no provision for RANGER's ITR-like routers being able to probe the reachability of end-user networks via multiple ETR-like routers -- nor for any other approach to multihoming service restoration.
没有规定RANGER的类ITR路由器能够通过多个类ETR路由器探测最终用户网络的可达性，也没有规定任何其他多主服务恢复方法。
Nor is there any provision for inbound TE or support of mobile devices which frequently change their point of attachment.
也没有任何关于入站TE或支持经常更改其连接点的移动设备的规定。
Therefore, in its current form, RANGER cannot be contemplated as a superior scalable routing solution to some other proposals which are specified in sufficient detail and which appear to be feasible.
因此，在其目前的形式下，RANGER不能被认为是比其他一些方案更好的可伸缩路由解决方案，这些方案已经详细说明，并且似乎是可行的。
RANGER uses its own tunneling and PMTUD management protocol: SEAL. Adoption of SEAL in its current form would prevent the proper utilization of jumbo frame paths in the DFZ, which will become the norm in the future. SEAL uses "Packet Too Big" [RFC4443] and "Fragmentation Needed" [RFC0792] messages to the sending host only to fix a preset maximum packet length. To avoid the need for the SEAL layer to fragment packets of this length, this MTU value (for the input of the tunnel) needs to be set significantly below 1500 bytes, assuming the typically ~1500 byte MTU values for paths across the DFZ today. In order to avoid this excessive fragmentation, this value could only be raised to a ~9k byte value at some time in the future where essentially all paths between ITRs and ETRs were jumbo frame capable.
RANGER使用自己的隧道和PMTUD管理协议：SEAL。采用当前形式的SEAL将阻止在DFZ中正确使用巨型帧路径，这将成为未来的标准。SEAL使用“数据包太大”[RFC4443]和“需要碎片”[RFC0792]消息发送给发送主机，仅用于固定预设的最大数据包长度。为了避免密封层需要对该长度的数据包进行分段，需要将该MTU值（用于隧道的输入）设置为大大低于1500字节，假设目前跨DFZ的路径的MTU值通常为~1500字节。为了避免这种过度碎片化，该值只能在将来某个时候提高到~9k字节的值，因为ITR和ETR之间的所有路径基本上都支持巨型帧。
The Internet Routing Overlay Network (IRON) [IRON] is a scalable Internet routing architecture that builds on the RANGER recursive enterprise network hierarchy [RFC5720]. IRON bonds together participating RANGER networks using VET [VET] and SEAL [SEAL] to enable secure and scalable routing through automatic tunneling within the Internet core. The IRON-RANGER automatic tunneling abstraction views the entire global Internet DFZ as a virtual Non-Broadcast Multi-Access (NBMA) link similar to ISATAP [RFC5214].
Internet路由覆盖网络（IRON）[IRON]是一种基于RANGER递归企业网络层次结构[RFC5720]的可扩展Internet路由体系结构。IRON使用VET[VET]和SEAL[SEAL]将参与的RANGER网络连接在一起，通过互联网核心内的自动隧道实现安全和可扩展的路由。IRON-RANGER自动隧道抽象将整个全球互联网DFZ视为一个虚拟的非广播多址（NBMA）链路，类似于ISATAP[RFC5214]。
IRON-RANGER is an example of a Core-Edge Separation (CES) system. Instead of a classical mapping database, however, IRON-RANGER uses a hybrid combination of a proactive dynamic routing protocol for distributing highly aggregated Virtual Prefixes (VPs) and an on-demand data driven protocol for distributing more-specific Provider-Independent (PI) prefixes derived from the VPs.
IRON-RANGER是核心边缘分离（CES）系统的一个示例。但是，IRON-RANGER没有使用经典的映射数据库，而是使用了主动动态路由协议（用于分发高度聚合的虚拟前缀（VP））和按需数据驱动协议（用于分发从VPs派生的更特定的独立于提供商（PI）的前缀）的混合组合。
The IRON-RANGER hierarchy consists of recursively-nested RANGER enterprise networks joined together by IRON routers that participate in a global BGP instance. The IRON BGP instance is maintained separately from the current Internet BGP Routing LOCator (RLOC) address space (i.e., the set of all public IPv4 prefixes in the Internet). Instead, the IRON BGP instance maintains VPs taken from Endpoint Interface iDentifier (EID) address space, e.g., the IPv6 global unicast address space. To accommodate scaling, only O(10k) -- O(100k) VPs are allocated e.g., using /20 or shorter IPv6 prefixes.
IRON-RANGER层次结构由递归嵌套的RANGER企业网络组成，这些网络由参与全局BGP实例的IRON路由器连接在一起。IRON BGP实例与当前Internet BGP路由定位器（RLOC）地址空间（即Internet中所有公共IPv4前缀的集合）分开维护。相反，IRON BGP实例维护从端点接口标识符（EID）地址空间获取的VP，例如IPv6全局单播地址空间。为了适应扩展，仅分配O（10k）--O（100k）VP，例如使用/20或更短的IPv6前缀。
IRON routers lease portions of their VPs as Provider-Independent (PI) prefixes for customer equipment (CEs), thereby creating a sustainable business model. CEs that lease PI prefixes propagate address mapping(s) throughout their attached RANGER networks and up to VP-owning IRON router(s) through periodic transmission of "bubbles" with authentication and PI prefix information. Routers in RANGER networks
IRON路由器将其VP的一部分作为独立于提供商（PI）的前缀出租给客户设备（CE），从而创建了一个可持续的商业模式。租用PI前缀的CE通过定期传输带有身份验证和PI前缀信息的“气泡”，将地址映射传播到其连接的RANGER网络，并传播到拥有VP的IRON路由器。RANGER网络中的路由器
and IRON routers that receive and forward the bubbles securely install PI prefixes in their FIBs, but do not inject them into the RIB. IRON routers therefore keep track of only their customer base via the FIB entries and keep track of only the Internet-wide VP database in the RIB.
接收和转发气泡的铁路由器在其FIB中安全地安装PI前缀，但不将其注入肋骨。因此，IRON路由器仅通过FIB条目跟踪其客户群，并仅跟踪RIB中的互联网范围VP数据库。
IRON routers propagate more-specific prefixes using secure redirection to update router FIBs. Prefix redirection is driven by the data plane and does not affect the control plane. Redirected prefixes are not injected into the RIB, but rather are maintained as FIB soft state that is purged after expiration or route failure. Neighbor unreachability detection is used to detect failure.
IRON路由器使用安全重定向来传播更特定的前缀，以更新路由器FIB。前缀重定向由数据平面驱动，不影响控制平面。重定向的前缀不会被注入到RIB中，而是保持为FIB软状态，在到期或路由失败后被清除。邻居不可达性检测用于检测故障。
Secure prefix registrations and redirections are accommodated through the mechanisms of SEAL. Tunnel endpoints using SEAL synchronize sequence numbers, and can therefore discard any packets they receive that are outside of the current sequence number window. Hence, off-path attacks are defeated. These synchronized tunnel endpoints can therefore exchange prefixes with signed certificates that prove prefix ownership in such a way that DoS vectors that attack crypto calculation overhead are eliminated due to the prevention of off-path attacks.
安全前缀注册和重定向通过SEAL机制实现。使用SEAL的隧道端点会同步序列号，因此可以丢弃当前序列号窗口之外的任何数据包。因此，非路径攻击被击败。因此，这些同步隧道端点可以与签名证书交换前缀，签名证书证明前缀所有权，从而消除攻击加密计算开销的DoS向量，从而防止非路径攻击。
CEs can move from old RANGER networks and re-inject their PI prefixes into new RANGER networks. This would be accommodated by IRON-RANGER as a site multihoming event while host mobility and true locator-ID separation is accommodated via HIP [RFC5201].
CEs可以从旧的RANGER网络迁移，并将其PI前缀重新注入新的RANGER网络。这将由IRON-RANGER作为站点多主事件进行调节，而主机移动性和真正的定位器ID分离则通过HIP进行调节[RFC5201]。
As can be seen from the extensive list of proposals above, the group explored a number of possible solutions. Unfortunately, the group did not reach rough consensus on a single best approach. Accordingly, the recommendation has been left to the co-chairs. The remainder of this section describes the rationale and decision of the co-chairs.
从上述广泛的提案清单可以看出，工作组探讨了一些可能的解决办法。不幸的是，该小组没有就单一的最佳办法达成大致共识。因此，该建议已留给联合主席处理。本节其余部分介绍了联合主席的基本原理和决定。
As a reminder, the goal of the research group was to develop a recommendation for an approach to a routing and addressing architecture for the Internet. The primary goal of the architecture is to provide improved scalability for the routing subsystem. Specifically, this implies that we should be able to continue to grow the routing subsystem to meet the needs of the Internet without requiring drastic and continuous increases in the amount of state or processing requirements for routers.
作为提醒，研究小组的目标是为互联网路由和寻址体系结构的方法提出建议。该体系结构的主要目标是为路由子系统提供改进的可伸缩性。具体地说，这意味着我们应该能够继续发展路由子系统，以满足互联网的需求，而不需要对路由器的状态量或处理需求进行急剧和持续的增加。
There is a general concern that the cost and structure of the routing and addressing architecture as we know it today may become prohibitively expensive with continued growth, with repercussions to the health of the Internet. As such, there is an urgent need to examine and evaluate potential scalability enhancements.
人们普遍担心，随着互联网的持续增长，我们今天所知道的路由和寻址体系结构的成本和结构可能会变得非常昂贵，从而影响互联网的健康。因此，迫切需要检查和评估潜在的可伸缩性增强。
For the long term future of the Internet, it has become apparent that IPv6 is going to play a significant role. It has taken more than a decade, but IPv6 is starting to see some non-trivial amount of deployment. This is in part due to the depletion of IPv4 addresses. It therefore seems apparent that the new architecture must be applicable to IPv6. It may or may not be applicable to IPv4, but not addressing the IPv6 portion of the network would simply lead to recreating the routing scalability problem in the IPv6 domain, because the two share a common routing architecture.
从互联网的长远发展来看，IPv6显然将发挥重要作用。这已经花了十多年的时间，但IPv6开始看到一些不平凡的部署量。部分原因是IPv4地址耗尽。因此，新体系结构显然必须适用于IPv6。它可能适用于IPv4，也可能不适用于IPv4，但不解决网络的IPv6部分只会导致在IPv6域中重新产生路由可伸缩性问题，因为两者共享一个共同的路由体系结构。
Whatever change we make, we should expect that this is a very long-lived change. The routing architecture of the entire Internet is a loosely coordinated, complex, expensive subsystem, and permanent, pervasive changes to it will require difficult choices during deployment and integration. These cannot be undertaken lightly.
无论我们做出什么样的改变，我们都应该期待这是一个非常长久的改变。整个互联网的路由架构是一个松散协调、复杂、昂贵的子系统，对其进行永久性、普遍性的更改将需要在部署和集成期间做出艰难的选择。这些都不能掉以轻心。
By extension, if we are going to the trouble, pain, and expense of making major architectural changes, it follows that we want to make the best changes possible. We should regard any such changes as permanent and we should therefore aim for long term solutions that place the network in the best possible position for ongoing growth. These changes should be cleanly integrated, first-class citizens within the architecture. That is to say that any new elements that are integrated into the architecture should be fundamental primitives, on par with the other existing legacy primitives in the architecture, that interact naturally and logically when in combination with other elements of the architecture.
从广义上讲，如果我们要为进行重大架构更改而付出麻烦、痛苦和费用，那么我们希望尽可能地进行最佳更改。我们应将任何此类变化视为永久性的，因此，我们应着眼于长期解决方案，将网络置于持续增长的最佳位置。这些变化应该干净地集成在体系结构中，成为一流的公民。也就是说，集成到体系结构中的任何新元素应该是基本的原语，与体系结构中的其他现有遗留基元一致，当与体系结构的其他元素相结合时，它们自然地和逻辑地相互作用。
Over the history of the Internet, we have been very good about creating temporary, ad-hoc changes, both to the routing architecture and other aspects of the network layer. However, many of these band-aid solutions have come with a significant overhead in terms of long-term maintenance and architectural complexity. This is to be avoided and short-term improvements should eventually be replaced by long-term, permanent solutions.
在互联网的发展史上，我们一直非常善于对路由架构和网络层的其他方面进行临时的、即席的更改。然而，许多这些带助解决方案在长期维护和体系结构复杂性方面具有显著的开销。这是要避免的，短期的改进最终应该被长期的、永久的解决方案所取代。
In the particular instance of the routing and addressing architecture today, we feel that the situation requires that we pursue both short-term improvements and long-term solutions. These are not incompatible because we truly intend for the short-term improvements
在今天的路由和寻址体系结构的特定实例中，我们认为这种情况要求我们同时追求短期改进和长期解决方案。这些并不是不相容的，因为我们确实打算在短期内进行改进
to be completely localized and temporary. The short-term improvements are necessary to give us the time necessary to develop, test, and deploy the long-term solution. As the long-term solution is rolled out and gains traction, the short-term improvements should be of less benefit and can subsequently be withdrawn.
完全本地化和临时化。短期的改进是必要的，以便给我们开发、测试和部署长期解决方案所需的时间。随着长期解决方案的推出和吸引力的增强，短期改进的好处应该会减少，并且可以随后撤销。
The group explored a number of proposed solutions but did not reach consensus on a single best approach. Therefore, in fulfillment of the routing research group's charter, the co-chairs recommend that the IETF pursue work in the following areas:
工作组探讨了若干拟议的解决办法，但没有就单一的最佳办法达成共识。因此，为了履行路由研究小组的章程，联合主席建议IETF在以下领域开展工作：
Evolution [Evolution]
进化[进化]
Identifier-Locator Network Protocol (ILNP) [ILNP_Site]
标识符定位器网络协议（ILNP）[ILNP_站点]
Renumbering [RFC5887]
重新编号[RFC5887]
We selected Evolution because it is a short-term improvement. It can be applied on a per-domain basis, under local administration and has immediate effect. While there is some complexity involved, we feel that this option is constructive for service providers who find the additional complexity to be less painful than upgrading hardware. This improvement can be deployed by domains that feel it necessary, for as long as they feel it is necessary. If this deployment lasts longer than expected, then the implications of that decision are wholly local to the domain.
我们选择进化是因为它是一种短期的改进。它可以在本地管理下按域应用，并立即生效。虽然这涉及到一些复杂性，但我们认为，对于发现额外复杂性比升级硬件痛苦更小的服务提供商来说，此选项是有建设性的。只要域认为有必要，就可以部署这种改进。如果此部署持续的时间比预期的长，那么该决策的影响对域来说完全是局部的。
We recommended ILNP because we find it to be a clean solution for the architecture. It separates location from identity in a clear, straightforward way that is consistent with the remainder of the Internet architecture and makes both first-class citizens. Unlike the many map-and-encap proposals, there are no complications due to tunneling, indirection, or semantics that shift over the lifetime of a packet's delivery.
我们推荐ILNP，因为我们发现它是架构的干净解决方案。它以一种清晰、直截了当的方式将位置与身份区分开来，与互联网架构的其余部分保持一致，并使两者都成为一流公民。与许多map和encap方案不同，在数据包传递的整个生命周期内，不会因隧道、间接或语义的变化而出现复杂情况。
We recommend further work on automating renumbering because even with ILNP, the ability of a domain to change its locators at minimal cost is fundamentally necessary. No routing architecture will be able to scale without some form of abstraction, and domains that change their point of attachment must fundamentally be prepared to change their locators in line with this abstraction. We recognize that [RFC5887] is not a solution so much as a problem statement, and we are simply recommending that the IETF create effective and convenient mechanisms for site renumbering.
我们建议进一步自动化重新编号，因为即使使用ILNP，域以最低成本更改其定位器的能力也是必不可少的。没有某种形式的抽象，任何路由体系结构都无法进行扩展，而改变其连接点的域必须从根本上准备好根据这种抽象改变其定位器。我们认识到，[RFC5887]与其说是一个问题陈述，不如说是一个解决方案，我们只是建议IETF为站点重新编号创建有效和方便的机制。
This document presents a small portion of the overall work product of the Routing Research Group, who have developed all of these architectural approaches and many specific proposals within this solution space.
本文档介绍了路由研究小组整体工作成果的一小部分，该小组在此解决方案空间内开发了所有这些体系结构方法和许多具体建议。
Space precludes a full treatment of security considerations for all proposals summarized herein. [RFC3552] However, it was a requirement of the research group to provide security that is at least as strong as the existing Internet routing and addressing architecture. Each technical proposal has slightly different security considerations, the details of which are in many of the references cited.
由于篇幅有限，无法对本文概述的所有提案的安全考虑进行全面处理。[RFC3552]然而，研究小组要求提供至少与现有互联网路由和寻址架构一样强大的安全性。每项技术方案都有略微不同的安全注意事项，其详细信息见所引用的许多参考文献。
[CRM] Flinck, H., "Compact routing in locator identifier mapping system", <http://www.tschofenig.priv.at/rrg/ CR_mapping_system_0.1.pdf>.
[CRM]Flinck，H.，“定位器标识符映射系统中的紧凑路由”<http://www.tschofenig.priv.at/rrg/ CR\U映射\U系统\U 0.1.pdf>。
[DNSnBIND] Liu, C. and P. Albitz, "DNS & BIND", 2006, 5th Edition, O'Reilly & Associates, Sebastopol, CA, USA. ISBN 0-596-10057-4.
[DNSnBIND]Liu，C.和P.Albitz，“DNS和BIND”，2006年，第5版，O'Reilly&Associates，塞巴斯托波尔，加利福尼亚州，美国。ISBN 0-596-10057-4。
[EEMDP_Considerations] Sriram, K., Kim, Y., and D. Montgomery, "Enhanced Efficiency of Mapping Distribution Protocols in Scalable Routing and Addressing Architectures", Proceedings of the ICCCN, Zurich, Switzerland, August 2010, <http://www.antd.nist.gov/~ksriram/EEMDP_ICCCN2010.pdf>.
[EEMDP_考量]Sriram，K.，Kim，Y.，和D.Montgomery，“可扩展路由和寻址体系结构中映射分发协议的增强效率”，ICCCN会议记录，瑞士苏黎世，2010年8月<http://www.antd.nist.gov/~ksriram/EEMDP_ICCCN2010.pdf>。
[EEMDP_Presentation] Sriram, K., Gleichmann, P., Kim, Y., and D. Montgomery, "Enhanced Efficiency of Mapping Distribution Protocols in Scalable Routing and Addressing Architectures", Presented at the LISP WG meeting, IETF 78, July 2010. Originally presented at the RRG meeting at IETF 72, <http://www.ietf.org/proceedings/78/slides/lisp-6.pdf>.
[EEMDP_演示文稿]Sriram，K.，Gleichmann，P.，Kim，Y.，和D.Montgomery，“可扩展路由和寻址体系结构中映射分发协议的增强效率”，在2010年7月IETF 78的LISP工作组会议上介绍。最初在IETF 72的RRG会议上提出<http://www.ietf.org/proceedings/78/slides/lisp-6.pdf>.
[Evolution] Zhang, B. and L. Zhang, "Evolution Towards Global Routing Scalability", Work in Progress, October 2009.
[Evolution]Zhang，B.和L.Zhang，“朝向全球路由可扩展性的进化”，正在进行的工作，2009年10月。
[Evolution_Grow_Presentation] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "Virtual Aggregation (VA)", November 2009, <http://www.ietf.org/proceedings/76/slides/grow-5.pdf>.
[Evolution_Grow_Presentation]Francis，P.，Xu，X.，Ballani，H.，Jen，D.，Raszuk，R.，和L.Zhang，“虚拟聚合（VA）”，2009年11月<http://www.ietf.org/proceedings/76/slides/grow-5.pdf>.
[FIBAggregatability] Zhang, B., Wang, L., Zhao, X., Liu, Y., and L. Zhang, "An Evaluation Study of Router FIB Aggregatability", November 2009, <http://www.ietf.org/proceedings/76/slides/grow-2.pdf>.
[FIB可聚合性]Zhang，B.，Wang，L.，Zhao，X.，Liu，Y.，和L.Zhang，“路由器FIB可聚合性评估研究”，2009年11月<http://www.ietf.org/proceedings/76/slides/grow-2.pdf>.
[GLI] Menth, M., Hartmann, M., and D. Klein, "Global Locator, Local Locator, and Identifier Split (GLI-Split)", April 2010, <http://www3.informatik.uni-wuerzburg.de/TR/tr470.pdf>.
[GLI]Minth，M.，Hartmann，M.和D.Klein，“全局定位器，局部定位器和标识符拆分（GLI拆分）”，2010年4月<http://www3.informatik.uni-wuerzburg.de/TR/tr470.pdf>.
[ILNP_DNS] Atkinson, R. and S. Rose, "DNS Resource Records for ILNP", Work in Progress, February 2011.
[ILNP_DNS]Atkinson，R.和S.Rose，“ILNP的DNS资源记录”，正在进行的工作，2011年2月。
[ILNP_ICMP] Atkinson, R., "ICMP Locator Update message", Work in Progress, February 2011.
[ILNP_ICMP]阿特金森，R.，“ICMP定位器更新消息”，正在进行的工作，2011年2月。
[ILNP_Intro] Atkinson, R., "ILNP Concept of Operations", Work in Progress, February 2011.
[ILNP_简介]阿特金森，R.，“ILNP作战概念”，在建工程，2011年2月。
[ILNP_Nonce] Atkinson, R., "ILNP Nonce Destination Option", Work in Progress, February 2011.
[ILNP_Nonce]阿特金森，R.，“ILNP Nonce目的地选项”，正在进行的工作，2011年2月。
[ILNP_Site] Atkinson, R., Bhatti, S., Hailes, S., Rehunathan, D., and M. Lad, "ILNP - Identifier-Locator Network Protocol", updated 06 January 2011, <http://ilnp.cs.st-andrews.ac.uk>.
[ILNP_站点]Atkinson，R.，Bhatti，S.，Hailes，S.，Rehunahan，D.，和M.Lad，“ILNP-标识符定位器网络协议”，2011年1月6日更新<http://ilnp.cs.st-andrews.ac.uk>.
[IRON] Templin, F., "The Internet Routing Overlay Network (IRON)", Work in Progress, January 2011.
[IRON]Templin，F.，“互联网路由覆盖网络（IRON）”，正在进行的工作，2011年1月。
[Ivip_Constraints] Whittle, R., "List of constraints on a successful scalable routing solution which result from the need for widespread voluntary adoption", April 2009, <http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/>.
[Ivip_约束]Whittle，R.，“因需要广泛自愿采用而导致的成功可扩展路由解决方案的约束列表”，2009年4月<http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/>.
[Ivip_DRTM] Whittle, R., "DRTM - Distributed Real Time Mapping for Ivip and LISP", Work in Progress, March 2010.
[Ivip_DRTM]Whittle，R.，“DRTM-Ivip和LISP的分布式实时映射”，正在进行的工作，2010年3月。
[Ivip_EAF] Whittle, R., "Ivip4 ETR Address Forwarding", Work in Progress, January 2010.
[Ivip_EAF]Whittle，R.，“Ivip4 ETR地址转发”，正在进行的工作，2010年1月。
[Ivip_Glossary] Whittle, R., "Glossary of some Ivip and scalable routing terms", Work in Progress, March 2010.
[Ivip_术语表]Whittle，R.，“一些Ivip和可伸缩路由术语表”，正在进行的工作，2010年3月。
[Ivip_Mobility] Whittle, R., "TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem", August 2008, <http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf>.
[Ivip_Mobility]Whittle，R.，“互联网路由扩展问题核心边缘分离解决方案的TTR移动扩展”，2008年8月<http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf>.
[Ivip_PLF] Whittle, R., "Prefix Label Forwarding (PLF) - Modified Header Forwarding for IPv6", <http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/>.
[Ivip_PLF]Whittle，R.，“前缀标签转发（PLF）-IPv6的修改头转发”<http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/>.
[Ivip_PMTUD] Whittle, R., "IPTM - Ivip's approach to solving the problems with encapsulation overhead, MTU, fragmentation and Path MTU Discovery", January 2010, <http://www.firstpr.com.au/ip/ivip/pmtud-frag/>.
[Ivip_PMTUD]Whittle，R.，“IPTM-Ivip解决封装开销、MTU、碎片和路径MTU发现问题的方法”，2010年1月<http://www.firstpr.com.au/ip/ivip/pmtud-frag/>.
[JSAC_Arch] Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the Internet Architecture Through Naming", IEEE Journal on Selected Areas in Communication (JSAC) 28(8), October 2010.
[JSAC_Arch]Atkinson，R.，Bhatti，S.和S.Hailes，“通过命名发展互联网架构”，IEEE通信选定领域杂志（JSAC）28（8），2010年10月。
[LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", Work in Progress, February 2010.
[LIG]Farinaci，D.和D.Meyer，“LISP Internet Groper（LIG）”，正在进行的工作，2010年2月。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, October 2010.
[LISP]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，正在进行的工作，2010年10月。
[LISP+ALT] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP+ALT)", Work in Progress, October 2010.
[LISP+ALT]Fuller，V.，Farinaci，D.，Meyer，D.，和D.Lewis，“LISP替代拓扑（LISP+ALT）”，正在进行的工作，2010年10月。
[LISP-Interworking] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", Work in Progress, August 2010.
[LISP互通]Lewis，D.，Meyer，D.，Farinaci，D.，和V.Fuller，“将LISP与IPv4和IPv6互通”，正在进行的工作，2010年8月。
[LISP-MN] Meyer, D., Lewis, D., and D. Farinacci, "LISP Mobile Node", Work in Progress, October 2010.
[LISP-MN]Meyer，D.，Lewis，D.，和D.Farinaci，“LISP移动节点”，正在进行的工作，2010年10月。
[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server", Work in Progress, October 2010.
[LISP-MS]Fuller，V.和D.Farinaci，“LISP地图服务器”，正在进行的工作，2010年10月。
[LISP-TREE] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System", IEEE Journal on Selected Areas in Communications, Volume 28, Issue 8, October 2010, <http ://ieeexplore.ieee.org/stamp/ stamp.jsp?tp=&arnumber=5586446>.
[LISP-TREE]Jakab，L.，Cabellos Aparicio，A.，Coras，F.，Saucez，D.，和O.Bonaventure，“LISP-TREE：支持LISP映射系统的DNS层次结构”，IEEE通信领域选定领域杂志，第28卷，第8期，2010年10月，<http://ieeexplore.IEEE.org/stamp/stamp.jsp？tp=&arnumber=5586446>。
[LMS] Letong, S., Xia, Y., ZhiLiang, W., and W. Jianping, "A Layered Mapping System For Scalable Routing", <http:// docs.google.com/ fileview?id=0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktN mFkYzBhNWJhMWEy&hl=en>.
[LMS]乐通，S.，夏，Y.，智良，W.，和W.建平，“可伸缩路由的分层映射系统”，<http://docs.google.com/fileview？id=0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktN mFkYzBhNWJhMWEy&hl=en>。
[LMS_Summary] Sun, C., "A Layered Mapping System (Summary)", <http:// docs.google.com/ Doc?docid=0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&hl=en>.
[LMS_Summary]Sun，C.，“分层映射系统（摘要）”，<http://docs.google.com/Doc？docid=0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&hl=en>。
[LOC_ID_Implications] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", Work in Progress, January 2009.
[LOC_ID_Implications]Meyer，D.和D.Lewis，“定位器/ID分离的架构影响”，正在进行的工作，2009年1月。
[MILCOM1] Atkinson, R. and S. Bhatti, "Site-Controlled Secure Multi-homing and Traffic Engineering for IP", IEEE Military Communications Conference (MILCOM) 28, Boston, MA, USA, October 2009.
[MILCOM1]Atkinson，R.和S.Bhatti，“IP的现场控制安全多主和流量工程”，IEEE军事通信会议（MILCOM）28，美国马萨诸塞州波士顿，2009年10月。
[MILCOM2] Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised Resilience, Multi-homing and Mobility Capability for IP", IEEE Military Communications Conference (MILCOM) 27, San Diego, CA, USA, November 2008.
[MILCOM2]Atkinson，R.，Bhatti，S.，和S.Hailes，“IP的协调弹性、多址和移动能力”，IEEE军事通信会议（MILCOM）27，加利福尼亚州圣地亚哥，美国，2008年11月。
[MPTCP_Arch] Ford, A., Raiciu, C., Barre, S., Iyengar, J., and B. Ford, "Architectural Guidelines for Multipath TCP Development", Work in Progress, February 2010.
[MPTCP_Arch]Ford，A.，Raiciu，C.，Barre，S.，Iyengar，J.，和B.Ford，“多路径TCP开发的架构指南”，正在进行的工作，2010年2月。
[MobiArch1] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an Integrated Service through the Use of Naming", ACM International Workshop on Mobility in the Evolving Internet (MobiArch) 2, Kyoto, Japan, August 2007.
[MobiArch1]Atkinson，R.，Bhatti，S.，和S.Hailes，“通过使用命名将移动性作为一项综合服务”，ACM国际研讨会，关于互联网发展中的移动性（MobiArch）2，日本京都，2007年8月。
[MobiArch2] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through Naming: Impact on DNS", ACM International Workshop on Mobility in the Evolving Internet (MobiArch) 3, Seattle, USA, August 2008.
[MobiArch2]Atkinson，R.，Bhatti，S.和S.Hailes，“通过命名实现的移动性：对DNS的影响”，ACM国际研讨会，关于互联网发展中的移动性（MobiArch）3，美国西雅图，2008年8月。
[Name_Based_Sockets] Vogt, C., "Simplifying Internet Applications Development With A Name-Based Sockets Interface", December 2009, <http ://christianvogt.mailup.net/pub/ vogt-2009-name-based-sockets.pdf>.
[Name_-Based_-Sockets]Vogt，C.，“使用基于姓名的Sockets接口简化互联网应用程序开发”，2009年12月，<http://christianvogt.mailup.net/pub/Vogt-2009-Name-Based-Sockets.pdf>。
[RANGER_Scen] Russert, S., Fleischman, E., and F. Templin, "RANGER Scenarios", Work in Progress, July 2010.
[RANGER_Scen]Russert，S.，Fleischman，E.，和F.Templin，“RANGER场景”，正在进行的工作，2010年7月。
[RANGI] Xu, X., "Routing Architecture for the Next Generation Internet (RANGI)", Work in Progress, August 2010.
[RANGI]Xu，X.“下一代互联网的路由架构（RANGI）”，正在进行的工作，2010年8月。
[RANGI-PROXY] Xu, X., "Transition Mechanisms for Routing Architecture for the Next Generation Internet (RANGI)", Work in Progress, July 2009.
[RANGI-PROXY]Xu，X.“下一代互联网路由架构的过渡机制（RANGI）”，正在进行的工作，2009年7月。
[RANGI-SLIDES] Xu, X., "Routing Architecture for the Next-Generation Internet (RANGI)", <http://www.ietf.org/proceedings/76/ slides/RRG-1/RRG-1.htm>.
[RANGI-SLIDES]Xu，X.，“下一代互联网的路由架构（RANGI）”<http://www.ietf.org/proceedings/76/ 幻灯片/RRG-1/RRG-1.htm>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[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月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[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月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009.
[RFC5534]Arkko，J.和I.van Beijnum，“IPv6多宿的故障检测和定位器对探测协议”，RFC 55342009年6月。
[RFC5720] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010.
[RFC5720]Templin，F.“具有全局企业递归（RANGER）的网络中的路由和寻址”，RFC 5720，2010年2月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887]Carpenter，B.，Atkinson，R.，和H.Flinck，“重新编号仍然需要工作”，RFC 5887，2010年5月。
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC5902]Thaler，D.，Zhang，L.，和G.Lebovitz，“IAB对IPv6网络地址转换的思考”，RFC 59022010年7月。
[RRG_Design_Goals] Li, T., "Design Goals for Scalable Internet Routing", Work in Progress, January 2011.
[RRG_Design_Goals]Li，T.，“可扩展互联网路由的设计目标”，进展中的工作，2011年1月。
[Referral_Obj] Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and K. Moore, "A Generic Referral Object for Internet Entities", Work in Progress, October 2009.
[Referral_Obj]Carpenter，B.，Boucadair，M.，Halpern，J.，Jiang，S.，和K.Moore，“互联网实体的通用参考对象”，正在进行的工作，2009年10月。
[SEAL] Templin, F., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Work in Progress, January 2011.
[SEAL]Templin，F.，“子网络封装和适配层（SEAL）”，正在进行的工作，2011年1月。
[Scalability_PS] Narten, T., "On the Scalability of Internet Routing", Work in Progress, February 2010.
[Scalability_PS]Narten，T.，“互联网路由的可伸缩性”，正在进行的工作，2010年2月。
[TIDR] Adan, J., "Tunneled Inter-domain Routing (TIDR)", Work in Progress, December 2006.
[TIDR]Adan，J.，“隧道式域间路由（TIDR）”，正在进行的工作，2006年12月。
[TIDR_AS_forwarding] Adan, J., "yetAnotherProposal: AS-number forwarding", March 2008, <http://www.ops.ietf.org/lists/rrg/2008/msg00716.html>.
[TIDR_AS_forwarding]Adan，J.，“yetAnotherProposal:AS number forwarding”，2008年3月<http://www.ops.ietf.org/lists/rrg/2008/msg00716.html>.
[TIDR_and_LISP] Adan, J., "LISP etc architecture", December 2007, <http://www.ops.ietf.org/lists/rrg/2007/msg00902.html>.
[TIDR_and_LISP]Adan，J.，“LISP等体系结构”，2007年12月<http://www.ops.ietf.org/lists/rrg/2007/msg00902.html>.
[TIDR_identifiers] Adan, J., "TIDR using the IDENTIFIERS attribute", April 2007, <http://www.ietf.org/mail-archive/web/ram/ current/msg01308.html>.
[TIDR_标识符]Adan，J.，“TIDR使用标识符属性”，2007年4月<http://www.ietf.org/mail-archive/web/ram/ 当前/msg01308.html>。
[VET] Templin, F., "Virtual Enterprise Traversal (VET)", Work in Progress, January 2011.
[VET]Templin，F.，“虚拟企业遍历（VET）”，正在进行的工作，2011年1月。
[Valiant] Zhang-Shen, R. and N. McKeown, "Designing a Predictable Internet Backbone Network", November 2004, <http:// conferences.sigcomm.org/hotnets/2004/ HotNets-III%20Proceedings/zhang-shen.pdf>.
[Valiant]张申，R.和N.McKeown，“设计可预测的互联网骨干网络”，2004年11月，<http://conferences.sigcomm.org/hotnets/2004/hotnets III%20Proceedings/Zhang Shen.pdf>。
[hIPv4] Frejborg, P., "Hierarchical IPv4 Framework", Work in Progress, October 2010.
[hIPv4]Frejborg，P.，“分层IPv4框架”，正在进行的工作，2010年10月。
Author's Address
作者地址
Tony Li (editor) Cisco Systems 170 West Tasman Dr. San Jose, CA 95134 USA
Tony Li（编辑）思科系统170 West Tasman美国加利福尼亚州圣何塞博士95134
Phone: +1 408 853 9317
EMail: tony.li@tony.li
Phone: +1 408 853 9317
EMail: tony.li@tony.li