Internet Engineering Task Force (IETF) X. Li
Request for Comments: 6791 C. Bao
Updates: 6145 CERNET Center/Tsinghua University
Category: Standards Track D. Wing
ISSN: 2070-1721 R. Vaithianathan
Cisco
G. Huston
APNIC
November 2012
Internet Engineering Task Force (IETF) X. Li
Request for Comments: 6791 C. Bao
Updates: 6145 CERNET Center/Tsinghua University
Category: Standards Track D. Wing
ISSN: 2070-1721 R. Vaithianathan
Cisco
G. Huston
APNIC
November 2012
Stateless Source Address Mapping for ICMPv6 Packets
ICMPv6数据包的无状态源地址映射
Abstract
摘要
A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases.
无状态IPv4/IPv6转换器可以接收包含非IPv4可翻译地址的ICMPv6数据包作为源。这些数据包应作为ICMP数据包通过转换器传递到IPv4目标。本文档介绍了在ICMPv6头中进行源地址转换以处理此类情况的建议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc6791.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6791.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement and Considerations . . . . . . . . . . . . . 3
3.1. Considerations . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Recommendations . . . . . . . . . . . . . . . . . . . . . . 3
4. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement and Considerations . . . . . . . . . . . . . 3
3.1. Considerations . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Recommendations . . . . . . . . . . . . . . . . . . . . . . 3
4. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
Section 5.3 of "IP/ICMP Translation Algorithm" [RFC6145] states that "the IPv6 addresses in the IPv6 header may not be IPv4-translatable addresses and there will be no corresponding IPv4 addresses representing this IPv6 address. In this case, the translator can do stateful translation. A mechanism by which the translator can instead do stateless translation of this address is left for future work." This document, "Stateless Source Address Mapping for ICMPv6 Packets", provides recommendations for this case.
“IP/ICMP转换算法”[RFC6145]第5.3节规定：“IPv6标头中的IPv6地址可能不是IPv4可翻译地址，并且不会有代表此IPv6地址的相应IPv4地址。在这种情况下，译者可以进行有状态翻译。翻译器可以通过一种机制对该地址进行无状态转换，这将留待以后的工作。”本文档“ICMPv6数据包的无状态源地址映射”为这种情况提供了建议。
For the purposes of this document, the term "IPv4-translatable IPv6 address" is as defined in Section 2.2 of [RFC6052].
在本文件中，“IPv4可翻译IPv6地址”一词的定义见[RFC6052]第2.2节。
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
本文件中出现的关键词必须、不得、要求、应、不应、应、不应、建议、可能和可选时，应按照[RFC2119]中的说明进行解释。
When a stateless IPv4/IPv6 translator receives an ICMPv6 message [RFC4443] (for example, "Packet Too Big") sourced from a non-IPv4- translatable IPv6 address and bound for an IPv4-translatable IPv6 address, the translator needs to pick a source address with which to generate an ICMP message. For the reasons discussed below, this choice is problematic.
当无状态IPv4/IPv6转换器收到来自非IPv4可翻译IPv6地址并绑定到IPv4可翻译IPv6地址的ICMPv6消息[RFC4443]（例如，“数据包太大”）时，转换器需要选择用于生成ICMP消息的源地址。出于下面讨论的原因，这种选择是有问题的。
The source address used SHOULD NOT cause the ICMP packet to be discarded. It SHOULD NOT be drawn from [RFC1918] or [RFC6598] address space, because that address space is likely to be subject to unicast Reverse Path Forwarding (uRPF) [RFC3704] filtering.
使用的源地址不应导致ICMP数据包被丢弃。它不应从[RFC1918]或[RFC6598]地址空间中提取，因为该地址空间可能受到单播反向路径转发（uRPF）[RFC3704]过滤的影响。
IPv4/IPv6 translation is intended for use in contexts where IPv4 addresses may not be readily available. Therefore, it is not considered appropriate to assign IPv4-translatable IPv6 addresses for all internal points in the IPv6 network that may originate ICMPv6 messages.
IPv4/IPv6转换旨在用于IPv4地址可能不可用的上下文中。因此，为IPv6网络中可能发起ICMPv6消息的所有内部点分配IPv4可翻译IPv6地址被认为是不合适的。
Another consideration for source selection is that it should be possible for the IPv4 recipients of the ICMP message to be able to distinguish between different IPv6 network origination of ICMPv6 messages (for example, to support a traceroute diagnostic utility that provides some limited network-level visibility across the IPv4/ IPv6 translator). This consideration implies that an IPv4/IPv6 translator needs to have a pool of IPv4 addresses for mapping the source address of ICMPv6 packets generated from different origins, or to include the IPv6 source address information for mapping the source address by others means. Currently, the TRACEROUTE and MTR [MTR] are the only consumers of translated ICMPv6 messages that care about the ICMPv6 source address.
源选择的另一个考虑因素是，ICMP消息的IPv4收件人应该能够区分ICMPv6消息的不同IPv6网络源（例如，支持跟踪路由诊断实用程序，该实用程序在IPv4/IPv6转换器中提供一些有限的网络级可视性）。这一考虑意味着IPv4/IPv6转换器需要有一个IPv4地址池，用于映射从不同来源生成的ICMPv6数据包的源地址，或者包括IPv6源地址信息，以便通过其他方式映射源地址。目前，TRACEROUTE和MTR[MTR]是唯一关心ICMPv6源地址的已翻译ICMPv6消息的使用者。
The recommended approach to source selection is to use a single (or small pool of) public IPv4 address as the source address of the translated ICMP message and leverage the ICMP extension [RFC5837] to include the IPv6 address as an Interface IP Address Sub-Object.
源选择的推荐方法是使用单个（或一小部分）公共IPv4地址作为翻译后的ICMP消息的源地址，并利用ICMP扩展[RFC5837]将IPv6地址包含为接口IP地址子对象。
In the case of either a single public IPv4 address (the IPv4 interface address or loopback address of the translator) or a pool of public IPv4 addresses, the translator SHOULD implement the ICMP extension defined by [RFC5837]. The ICMP message SHOULD include the Interface IP Address Sub-Object and specify the source IPv6 addresses of the original ICMPv6. When an enhanced traceroute application is used, it can derive the real IPv6 source addresses that generated the ICMPv6 messages. Therefore, it would be able improve on visibility towards the origin rather than simply blackholing at or beyond the translator. In the future, a new ICMP extension whose presence indicates that the packet has been translated and that the source address belongs to the translator, not the originating node, can also be considered.
对于单个公共IPv4地址（转换器的IPv4接口地址或环回地址）或公共IPv4地址池，转换器应实现[RFC5837]定义的ICMP扩展。ICMP消息应包括接口IP地址子对象，并指定原始ICMPv6的源IPv6地址。当使用增强型跟踪路由应用程序时，它可以派生生成ICMPv6消息的真实IPv6源地址。因此，它将能够提高对原文的可见性，而不是简单地在译者处或译者之外进行暗访。将来，还可以考虑一个新的ICMP扩展，它的存在表明数据包已被翻译，并且源地址属于转换器，而不是原始节点。
If a pool of public IPv4 addresses is configured on the translator, it is RECOMMENDED to randomly select the IPv4 source address from the pool. Random selection reduces the probability that two ICMP messages elicited by the same TRACEROUTE might specify the same source address and, therefore, erroneously present the appearance of a routing loop.
如果在转换器上配置了公共IPv4地址池，建议从池中随机选择IPv4源地址。随机选择降低了由同一跟踪路由引发的两条ICMP消息可能指定相同源地址的概率，从而错误地呈现路由循环的外观。
[RFC5837] extensions and an enhanced traceroute application, if used, will reveal the IPv6 source addresses that generated the original ICMPv6 messages.
[RFC5837]扩展和增强的跟踪路由应用程序（如果使用）将显示生成原始ICMPv6消息的IPv6源地址。
This document recommends the generation of IPv4 ICMP messages from IPv6 ICMP messages. These messages would otherwise have been discarded. New considerations are not expected to result from this change. As with a number of ICMP messages, a spoofed source address may result in replies arriving at hosts that did not expect them using the facility of the translator.
本文档建议从IPv6 ICMP消息生成IPv4 ICMP消息。否则这些消息将被丢弃。预计这一变化不会产生新的考虑因素。与许多ICMP消息一样，伪造的源地址可能会导致回复到达主机，而主机不希望使用翻译器的功能收到回复。
The authors would like to acknowledge the following contributors of this document: Kevin Yin, Chris Metz, Neeraj Gupta, and Joel Jaeggli. The authors would also like to thank Ronald Bonica, Ray Hunter, George Wes, Yu Guanghui, Sowmini Varadhan, David Farmer, Fred Baker, Leo Vegoda, Joel Jaeggli, Henrik Levkowetz, Randy Bush, and Warren Kumari for their comments and suggestions.
作者要感谢本文件的以下贡献者：Kevin Yin、Chris Metz、Neeraj Gupta和Joel Jaeggli。作者还要感谢罗纳德·博尼卡、雷·亨特、乔治·韦斯、余光辉、索米尼·瓦拉丹、大卫·法默、弗雷德·贝克、利奥·维戈达、乔尔·贾格利、亨里克·列夫科维茨、兰迪·布什和沃伦·库马里的评论和建议。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010.
[RFC5837]Atlas，A.，Ed.，Bonica，R.，Ed.，Pignataro，C.，Ed.，Shen，N.，和JR.Rivers，“为接口和下一跳识别扩展ICMP”，RFC 5837，2010年4月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
[RFC6598]Weil，J.，Kuarsingh，V.，Donley，C.，Liljenstolpe，C.，和M.Azinger，“IANA为共享地址空间保留IPv4前缀”，BCP 153，RFC 6598，2012年4月。
[MTR] "BitWizard B.V. - The Linux Experts", <http://www.bitwizard.nl/mtr/>.
[MTR]“BitWizard B.V.-Linux专家”<http://www.bitwizard.nl/mtr/>.
Authors' Addresses
作者地址
Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China
中国北京清华大学兴利赛特中心/清华大学主楼225室，邮编100084
Phone: +86 10-62785983
EMail: xing@cernet.edu.cn
Phone: +86 10-62785983
EMail: xing@cernet.edu.cn
Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China
中国北京清华大学主楼225室/聪晓宝CERNET中心北京100084
Phone: +86 10-62785983
EMail: congxiao@cernet.edu.cn
Phone: +86 10-62785983
EMail: congxiao@cernet.edu.cn
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 United States
Dan Wing Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Ramji Vaithianathan Cisco Systems, Inc. A 5-2, BGL 12-4, SEZ Unit, Cessna Business Park, Varthur Hobli Sarjapur Outer Ring Road Bangalore Karnataka 560 103 India
Ramji Vaithianathan Cisco Systems，Inc.印度卡纳塔克邦班加罗尔外环路塞斯纳商业园经济特区5-2，BGL 12-4，邮编560 103
Phone: +91 80 4426 0895
EMail: rvaithia@cisco.com
Phone: +91 80 4426 0895
EMail: rvaithia@cisco.com
Geoff Huston APNIC
杰夫·休斯顿呼吸暂停
EMail: gih@apnic.net
EMail: gih@apnic.net