Independent Submission B. Carpenter
Request for Comments: 8136 Univ. of Auckland
Category: Informational R. Hinden
ISSN: 2070-1721 Check Point Software
1 April 2017
Independent Submission B. Carpenter
Request for Comments: 8136 Univ. of Auckland
Category: Informational R. Hinden
ISSN: 2070-1721 Check Point Software
1 April 2017
Additional Transition Functionality for IPv6
IPv6的附加转换功能
Abstract
摘要
This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.
本文档提出了一种附加机制，旨在促进从IPv4到IPv6的过渡，并提高后者的安全性和隐私性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第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/rfc8136.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8136.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Required Function of All IPv4 Nodes . . . . . . . . . . . . . 2
3. Security Flag for IPv6 Packets . . . . . . . . . . . . . . . 3
4. Advanced Solution . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Privacy Extension . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Required Function of All IPv4 Nodes . . . . . . . . . . . . . 2
3. Security Flag for IPv6 Packets . . . . . . . . . . . . . . . 3
4. Advanced Solution . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Privacy Extension . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
In a recent statement [IABv6], the Internet Architecture Board deemed that the Internet Engineering Task Force is expected to "stop requiring IPv4 compatibility in new or extended protocols" and that future work will "optimize for and depend on IPv6". In the interest of promoting these goals, this memo makes an important change to IPv4 node requirements [RFC1122] and adds a missing security feature to IPv6 [RFC2460].
在最近的一份声明[IABv6]中，互联网体系结构委员会认为互联网工程任务组将“停止要求新协议或扩展协议中的IPv4兼容性”，未来的工作将“优化并依赖IPv6”。为了促进这些目标，本备忘录对IPv4节点要求[RFC1122]进行了重要更改，并在IPv6[RFC2460]中添加了缺失的安全功能。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are not to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”不应按照[RFC2119]中的描述进行解释。
To ensure that all routers, firewalls, load balancers, and other forms of middleboxes can readily identify IPv4 packets and deal with them appropriately (selective dropping, switching to the slow path through a router, sending them to the longest path first, etc.), all IPv4 nodes MUST set the security flag defined by [RFC3514] to 1. This should be sufficient to ensure that implementers of dual stack applications prefer IPv6 when given the choice, and that the Happy Eyeballs algorithm [RFC6555] will usually favour the IPv6 path.
为确保所有路由器、防火墙、负载平衡器和其他形式的中间盒都能轻松识别IPv4数据包并对其进行适当处理（选择性丢弃、通过路由器切换到慢路径、首先将其发送到最长路径等），所有IPv4节点必须将[RFC3514]定义的安全标志设置为1。这应该足以确保双栈应用程序的实现者在有选择的情况下更喜欢IPv6，并且快乐眼球算法[RFC6555]通常会支持IPv6路径。
The above requirement will somewhat nullify the practical effect of the IPv4 security flag for benign traffic, but this disadvantage can readily be overcome by adding an equivalent flag for IPv6; in fact, this is highly desirable to maintain feature equivalence between IPv4 and IPv6. Fortunately, this can easily be achieved since IPv6 supplies so many bits. The solution defined here is that the Security Flag bit for an IPv6 packet is simply the parity of the source address of the packet. In other words, if the source address contains an odd number of 1s, the flag is True; otherwise, it's False. All other considerations for the flag are exactly as described in [RFC3514].
上述要求将在一定程度上抵消IPv4安全标志对良性流量的实际影响，但通过为IPv6添加等效标志，可以轻松克服这一缺点；事实上，这对于保持IPv4和IPv6之间的功能等效是非常可取的。幸运的是，这很容易实现，因为IPv6提供了如此多的位。这里定义的解决方案是，IPv6数据包的安全标志位只是数据包源地址的奇偶校验。换句话说，如果源地址包含奇数个1，则标志为真；否则，这是错误的。该标志的所有其他注意事项完全如[RFC3514]中所述。
For an interface whose IPv6 address is set by Stateless Address Autoconfiguration [RFC4862], it is the host itself that determines the state of its security flag, by choosing an appropriate Interface Identifier value. Fortunately this is now possible and compatible with [RFC7136], [RFC7217], [RFC7421], and [RFC7721].
对于其IPv6地址由无状态地址自动配置[RFC4862]设置的接口，主机本身通过选择适当的接口标识符值来确定其安全标志的状态。幸运的是，这现在是可能的，并且与[RFC7136]、[RFC7217]、[RFC7421]和[RFC7721]兼容。
For an interface whose IPv6 address is set by DHCPv6 [RFC3315] or manually, the network administrator is free to choose an Interface Identifier that provides the desired security flag that is also compatible with [RFC7721].
对于其IPv6地址由DHCPv6[RFC3315]或手动设置的接口，网络管理员可以自由选择提供所需安全标志的接口标识符，该标志也与[RFC7721]兼容。
An exception case is a link with a 127-bit prefix [RFC6164]. Since there is only one bit available as an Interface Identifier, one end or the other will inevitably have its security flag set, and the other won't. In this case, the node at one end will simply interpret the other end's security flag to mean the opposite of what it says, and vice versa.
例外情况是带有127位前缀[RFC6164]的链路。由于只有一位可用作接口标识符，因此一端或另一端将不可避免地设置其安全标志，而另一端则不会。在这种情况下，一端的节点将简单地将另一端的安全标志解释为与它所说的相反的意思，反之亦然。
Since RFC 6164 is designed for links between routers, in the case where different ISPs are at each end of the link, it is normal operational practice for one ISP to consider the other ISP to be evil.
由于RFC 6164是设计用于路由器之间的链路，在不同的ISP在链路的每一端的情况下，对于一个ISP来说，考虑其他ISP是邪恶的是正常的操作实践。
In the event that the previous solution proves too simple to deploy in practice, a more advanced solution is also defined. It uses a new IPv6 hop-by-hop User Security Flag Option (UFO).
如果以前的解决方案过于简单，无法在实践中部署，则还将定义更高级的解决方案。它使用新的IPv6逐跳用户安全标志选项（UFO）。
The UFO is a hop-by-hop option that can be included in any IPv6 packet. Multiple UFOs MUST NOT be present in the packet. The UFO has no alignment requirement. Its format is as follows:
UFO是一个逐跳选项，可以包含在任何IPv6数据包中。包中不得存在多个UFO。UFO没有对准要求。其格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UserSecFlag |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UserSecFlag |
+-+-+-+-+-+-+-+-+
User Security Flag Option Layout
用户安全标志选项布局
Option Type
选项类型
8-bit identifier of the type of option. The option identifier for the User Security Flag Option (0x7g) has not been allocated by the IANA.
选项类型的8位标识符。IANA尚未分配用户安全标志选项（0x7g）的选项标识符。
Option Length
选项长度
8-bit unsigned integer. The length of the option (excluding the Option Type and Option Length fields). The value MUST be 1.
8位无符号整数。选项的长度（不包括选项类型和选项长度字段）。该值必须为1。
UserSecFlag
用户安全标志
8-bit unsigned integer. Bit 0 has the functionality defined in [RFC3514]. The other bits are reserved and MUST be zero or one.
8位无符号整数。位0具有[RFC3514]中定义的功能。其他位是保留的，必须为零或一。
The mechanism can be extended to add a privacy flag. With the mechanism of Section 3, the privacy flag could be encoded by using quaternary parity (CRC-2) to obtain an extra bit. However, this would waste considerable amounts of address space and SHOULD NOT be done. With the UFO mechanism, bit 1 of UserSecFlag is defined as the privacy flag. If set, it means that the packet contains private information and MUST NOT be inspected en route. All firewalls, monitoring devices, and government agencies MUST respect this rule. This option is expected to be much more computationally efficient
该机制可以扩展为添加隐私标志。根据第3节的机制，可以使用四元奇偶校验（CRC-2）对隐私标志进行编码，以获得额外的位。但是，这将浪费大量的地址空间，因此不应这样做。在UFO机制中，UserSecFlag的第1位被定义为隐私标志。如果设置，则意味着数据包包含私有信息，并且不能在途中进行检查。所有防火墙、监控设备和政府机构都必须遵守此规则。预计该选项的计算效率要高得多
than conventional privacy techniques like IPsec and Transport Layer Security (TLS) as no encryption or key management is required to achieve the desired privacy.
与IPsec和传输层安全（TLS）等传统隐私技术相比，无需加密或密钥管理即可实现所需的隐私。
The security considerations of [RFC3514] now apply to IPv6. However, with the security flag being set for all IPv4 packets, there is a risk that all IPv4 traffic will now be treated as a very distributed denial-of-service attack.
[RFC3514]的安全注意事项现在适用于IPv6。但是，由于为所有IPv4数据包设置了安全标志，所有IPv4流量现在都有可能被视为非常分散的拒绝服务攻击。
Given the recent experience with very large scale DDoS attacks from Internet of Things (IoT) devices like IP Cameras, phishing attacks, malware, etc., that occur on the IPv4 Internet, it is a safe assumption that all IPv4 packets are evil.
鉴于最近在IPv4互联网上发生的物联网（IoT）设备（如IP摄像头、网络钓鱼攻击、恶意软件等）的大规模DDoS攻击的经验，可以安全地假设所有IPv4数据包都是邪恶的。
Since the mechanism described in Section 3 is compatible with [RFC7721], address privacy is not impacted. Also, with that mechanism, exactly half the IPv6 address space will indicate that the security flag is set, so we can assert that the IPv6 Internet is only half evil.
由于第3节中描述的机制与[RFC7721]兼容，因此地址隐私不受影响。此外，通过这种机制，IPv6地址空间的一半将表示设置了安全标志，因此我们可以断言IPv6 Internet只是一半邪恶。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<http://www.rfc-editor.org/info/rfc1122>.
[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>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[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>.
[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>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，DOI 10.17487/RFC65552012年4月<http://www.rfc-editor.org/info/rfc6555>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7136]Carpenter，B.和S.Jiang，“IPv6接口标识符的重要性”，RFC 7136，DOI 10.17487/RFC7136，2014年2月<http://www.rfc-editor.org/info/rfc7136>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217]Gont，F.“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”，RFC 7217，DOI 10.17487/RFC72172014年4月<http://www.rfc-editor.org/info/rfc7217>.
[IABv6] IAB, "IAB Statement on IPv6", November 2016, <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>.
[IABv6]IAB，“IAB关于IPv6的声明”，2016年11月<https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>.
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, DOI 10.17487/RFC3514, April 2003, <http://www.rfc-editor.org/info/rfc3514>.
[RFC3514]Bellovin，S.，“IPv4报头中的安全标志”，RFC 3514，DOI 10.17487/RFC3514，2003年4月<http://www.rfc-editor.org/info/rfc3514>.
[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>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <http://www.rfc-editor.org/info/rfc7721>.
[RFC7721]Cooper，A.，Gont，F.，和D.Thaler，“IPv6地址生成机制的安全和隐私考虑”，RFC 7721，DOI 10.17487/RFC7721，2016年3月<http://www.rfc-editor.org/info/rfc7721>.
Authors' Addresses
作者地址
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
Email: brian.e.carpenter@gmail.com
Email: brian.e.carpenter@gmail.com
Robert M. Hinden Check Point Software 959 Skyway Road San Carlos CA 94070 United States of America
美国加利福尼亚州圣卡洛斯市Skyway路959号Robert M.Hinden检查点软件94070
Email: bob.hinden@gmail.com
Email: bob.hinden@gmail.com