[要約] RFC 6791は、ICMPv6パケットのための状態を持たないソースアドレスマッピングに関する仕様です。その目的は、ICMPv6パケットの送信元アドレスをマッピングするための手法を提供することです。
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パケットを受信する場合があります。これらのパケットは、IPv4宛先に向けられたICMPパケットとしてトランスレータを通過する必要があります。このドキュメントでは、このような場合に対処するためのICMPv6ヘッダーでの送信元アドレス変換の推奨事項を示します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]（たとえば、「Packet Too Big」）を受信すると、トランスレータは、 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パケットを破棄するべきではありません（SHOULD NOT）。 [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アドレスをすぐに使用できない場合のコンテキストでの使用を目的としています。したがって、ICMPv6メッセージを発信する可能性があるIPv6ネットワークのすべての内部ポイントに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ネットワーク発信を区別できるようにする必要があることです（たとえば、一部のネットワークレベルの可視性を提供するtraceroute診断ユーティリティをサポートするため） IPv4 / IPv6トランスレータ全体で）。この考慮事項は、IPv4 / IPv6トランスレーターが、異なる発信元から生成されたICMPv6パケットの送信元アドレスをマッピングするためのIPv4アドレスのプールを持つか、他の方法で送信元アドレスをマッピングするための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.
ソースを選択するための推奨されるアプローチは、変換されたICMPメッセージのソースアドレスとして単一（または小さなプール）のパブリックIPv4アドレスを使用し、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拡張を実装する必要があります（SHOULD）。 ICMPメッセージには、インターフェイスIPアドレスサブオブジェクトを含めて、元のICMPv6のソースIPv6アドレスを指定する必要があります（SHOULD）。拡張tracerouteアプリケーションを使用すると、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送信元アドレスをランダムに選択することをお勧めします。ランダムな選択により、同じTRACEROUTEによって引き出された2つのICMPメッセージが同じ送信元アドレスを指定する可能性が低くなるため、ルーティングループのように誤って表示される可能性があります。
[RFC5837] extensions and an enhanced traceroute application, if used, will reveal the IPv6 source addresses that generated the original ICMPv6 messages.
[RFC5837]拡張機能と拡張tracerouteアプリケーションを使用すると、元の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]ベイカー、F。、およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、2004年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、編、「インターネットプロトコルバージョン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.、and JR。 Rivers、「Interface and Next-Hop Identificationのための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 6052、2010年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 6145、2011年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-Reserved IPv4 Prefix for Shared Address Space」、BCP 153、RFC 6598、2012年4月。
[MTR] "BitWizard B.V. - The Linux Experts", <http://www.bitwizard.nl/mtr/>.
[MTR]「BitWizard B.V.-The Linux Experts」、<http://www.bitwizard.nl/mtr/>。
Authors' Addresses
著者のアドレス
Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China
Xing Li CERNETセンター/清華大学本館225号室北京100084中国清華大学
Phone: +86 10-62785983
EMail: xing@cernet.edu.cn
Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China
Congxiao Bao CERNETセンター/清華大学本館北京100084中国本館225号室
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 West Tasman Drive San Jose、CA 95134アメリカ合衆国
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. A 5-2、BGL 12-4、SEZ Unit、Cessna Business Park、Varthur Hobli Sarjapur Outer Ring Road Bangalore Karnataka 560103 India
Phone: +91 80 4426 0895
EMail: rvaithia@cisco.com
Geoff Huston APNIC
ジェフ・ヒューストンAPNIC
EMail: gih@apnic.net