Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 7608 France Telecom
BCP: 198 A. Petrescu
Category: Best Current Practice CEA, LIST
ISSN: 2070-1721 F. Baker
Cisco Systems
July 2015
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 7608 France Telecom
BCP: 198 A. Petrescu
Category: Best Current Practice CEA, LIST
ISSN: 2070-1721 F. Baker
Cisco Systems
July 2015
IPv6 Prefix Length Recommendation for Forwarding
转发的IPv6前缀长度建议
Abstract
摘要
IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length.
IPv6前缀长度与IPv4一样，是根据无类别域间路由（CIDR）体系结构在IPv6路由和转发过程中传输和使用的参数。IPv6前缀的长度可以是从零到128的任意数字，尽管使用无状态地址自动配置（SLAAC）进行地址分配的子网通常使用/64前缀。因此，路由和转发的硬件和软件实现不应该对前缀长度施加任何规则，而是首先对任何有效长度的前缀实现最长匹配。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc7608.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7608.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Normative References . . . . . . . . . . . . . . . . . . 4
4.2. Informative References . . . . . . . . . . . . . . . . . 4
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Normative References . . . . . . . . . . . . . . . . . . 4
4.2. Informative References . . . . . . . . . . . . . . . . . 4
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
Discussions on the 64-bit boundary in IPv6 addressing ([RFC7421]) revealed a need for a clear recommendation on which bits must be used by forwarding decision-making processes. However, such a recommendation was out of scope for that document.
关于IPv6寻址（[RFC7421]）中64位边界的讨论表明，需要明确建议转发决策过程必须使用哪些位。然而，这一建议超出了该文件的范围。
Although Section 2.5 of [RFC4291] states "IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing" (CIDR, [RFC4632]), there is still a misinterpretation that IPv6 prefixes can be either /127 ([RFC6164]) or any length up to /64. This misinterpretation is mainly induced by the 64-bit boundary in IPv6 addressing.
尽管[RFC4291]第2.5节指出“IPv6单播地址可以使用任意位长度的前缀进行聚合，类似于无类域间路由（CIDR）[RFC4632]）下的IPv4地址，但仍然存在一种误解，即IPv6前缀可以是/127（[RFC6164]），也可以是任何长度不超过/64的前缀。这种误解主要是由IPv6寻址中的64位边界引起的。
As discussed in [RFC7421], "the notion of a /64 boundary in the address was introduced after the initial design of IPv6, following a period when it was expected to be at /80". This evolution of the IPv6 addressing architecture, resulting in [RFC4291], and followed with the addition of /127 prefixes for point-to-point links, clearly demonstrates the intent for future IPv6 developments to have the flexibility to change this part of the architecture when justified.
正如[RFC7421]中所讨论的，“地址中的a/64边界概念是在IPv6的初始设计之后引入的，在一段时间之后，预计它将位于/80”。IPv6寻址体系结构的这一演变导致了[RFC4291]，随后为点到点链路添加了/127前缀，这清楚地表明了未来IPv6开发的意图，即在合理的情况下可以灵活地更改体系结构的这一部分。
It is fundamental not to link routing and forwarding to the IPv6 prefix/address semantics [RFC4291]. This document includes a recommendation in order to support that goal.
基本上，不要将路由和转发链接到IPv6前缀/地址语义[RFC4291]。本文件包括支持该目标的建议。
Forwarding decisions rely on the longest-match-first algorithm, which stipulates that, given a choice between two prefixes in the Forwarding Information Base (FIB) of different length that match the destination address in each bit up to their respective lengths, the longer prefix is used. This document's recommendation (Section 2) is that IPv6 forwarding must follow the longest-match-first rule, regardless of prefix length, unless some overriding policy is configured.
转发决策依赖于最长匹配优先算法，该算法规定，如果在转发信息库（FIB）中的两个不同长度的前缀之间进行选择，并在每个比特中匹配目标地址，直至其各自的长度，则使用较长的前缀。本文档的建议（第2节）是，除非配置了某些覆盖策略，否则IPv6转发必须遵循最长匹配优先规则，而不管前缀长度如何。
This recommendation does not conflict with the 64-bit boundary for some schemes that based on IPv6 stateless address autoconfiguration (SLAAC) [RFC4862], such as [RFC2464]. Indeed, [RFC7421] clarifies this is only a parameter in the SLAAC process, and other longer prefix lengths are in operational use (e.g., either manually configured or based upon DHCPv6 [RFC3315]).
对于一些基于IPv6无状态地址自动配置（SLAAC）[RFC4862]的方案，如[RFC2464]，此建议与64位边界不冲突。实际上，[RFC7421]澄清了这只是SLAAC过程中的一个参数，其他更长的前缀长度正在使用中（例如，手动配置或基于DHCPv6[RFC3315]）。
A historical background of CIDR is documented in [RFC1380] and Section 2 of [RFC4632].
CIDR的历史背景记录在[RFC1380]和[RFC4632]第2节中。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
IPv6 implementations MUST conform to the rules specified in Section 5.1 of [RFC4632].
IPv6实施必须符合[RFC4632]第5.1节中规定的规则。
Decision-making processes for forwarding MUST NOT restrict the length of IPv6 prefixes by design. In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1.
转发决策过程不得通过设计限制IPv6前缀的长度。特别是，转发过程必须设计为以1为增量处理长度不超过/128的前缀。
Policies can be enforced to restrict the length of IP prefixes advertised within a given domain or in a given interconnection link. These policies are deployment specific and/or driven by administrative (interconnection) considerations.
可以强制实施策略以限制在给定域或给定互连链路中公布的IP前缀的长度。这些策略是特定于部署和/或由管理（互连）考虑因素驱动的。
This document does not introduce security issues in addition to what is discussed in [RFC4291].
除[RFC4291]中讨论的内容外，本文档不介绍安全问题。
IPv6 security issues, including operational ones, are discussed in [RFC4942] and [OPSEC-v6].
[RFC4942]和[OPSEC-v6]中讨论了IPv6安全问题，包括操作问题。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <http://www.rfc-editor.org/info/rfc4632>.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，DOI 10.17487/RFC4632，2006年8月<http://www.rfc-editor.org/info/rfc4632>.
[OPSEC-v6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", Work in Progress, draft-ietf-opsec-v6-06, March 2015.
[OPSEC-v6]Chittimaneni，K.，Kaeo，M.，和E.Vyncke，“IPv6网络的运营安全考虑”，正在进行的工作，草案-ietf-OPSEC-v6-062015年3月。
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, DOI 10.17487/RFC1380, November 1992, <http://www.rfc-editor.org/info/rfc1380>.
[RFC1380]Gross，P.和P.Almquist，“IESG关于路由和寻址的讨论”，RFC 1380，DOI 10.17487/RFC1380，1992年11月<http://www.rfc-editor.org/info/rfc1380>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <http://www.rfc-editor.org/info/rfc2464>.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC 2464，DOI 10.17487/RFC2464，1998年12月<http://www.rfc-editor.org/info/rfc2464>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, DOI 10.17487/RFC4942, September 2007, <http://www.rfc-editor.org/info/rfc4942>.
[RFC4942]Davies，E.，Krishnan，S.，和P.Savola，“IPv6过渡/共存安全考虑”，RFC 4942，DOI 10.17487/RFC4942，2007年9月<http://www.rfc-editor.org/info/rfc4942>.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, <http://www.rfc-editor.org/info/rfc6164>.
[RFC6164]Kohno，M.，Nitzan，B.，Bush，R.，Matsuzaki，Y.，Colitti，L.，和T.Narten，“在路由器间链路上使用127位IPv6前缀”，RFC 6164，DOI 10.17487/RFC6164，2011年4月<http://www.rfc-editor.org/info/rfc6164>.
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, <http://www.rfc-editor.org/info/rfc7421>.
[RFC7421]Carpenter，B.，Ed.，Chown，T.，Gont，F.，Jiang，S.，Petrescu，A.，和A.Yourtchenko，“IPv6寻址中64位边界的分析”，RFC 7421，DOI 10.17487/RFC7421，2015年1月<http://www.rfc-editor.org/info/rfc7421>.
Acknowledgements
致谢
Thanks to Eric Vyncke, Christian Jacquenet, Brian Carpenter, Fernando Gont, Tatuya Jinmei, Lorenzo Colitti, Ross Chandler, David Farmer, David Black, and Barry Leiba for their contributions and comments.
感谢Eric Vyncke、Christian Jacquenet、Brian Carpenter、Fernando Gont、Tatuya Jinmei、Lorenzo Coletti、Ross Chandler、David Farmer、David Black和Barry Leiba的贡献和评论。
Special thanks to Randy Bush for his support.
特别感谢兰迪·布什的支持。
Authors' Addresses
作者地址
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
Email: mohamed.boucadair@orange.com
Email: mohamed.boucadair@orange.com
Alexandre Petrescu CEA, LIST CEA Saclay Gif-sur-Yvette, Ile-de-France 91190 France
Alexandre Petrescu CEA，列表CEA Saclay Gif sur Yvette，Ile de France 91190
Phone: +33169089223
Email: alexandre.petrescu@cea.fr
Phone: +33169089223
Email: alexandre.petrescu@cea.fr
Fred Baker Cisco Systems Santa Barbara, California 93117 United States
美国加利福尼亚州圣巴巴拉市弗雷德·贝克思科系统公司，邮编：93117
Email: fred@cisco.com
Email: fred@cisco.com