[要約] RFC 8215は、ローカルで使用されるIPv4/IPv6翻訳プレフィックスに関するガイドラインです。その目的は、IPv4とIPv6の間の通信を容易にするために、ローカルネットワークでの翻訳プレフィックスの使用方法を提供することです。

Internet Engineering Task Force (IETF)                       T. Anderson
Request for Comments: 8215                                Redpill Linpro
Category: Standards Track                                    August 2017
ISSN: 2070-1721

Local-Use IPv4/IPv6 Translation Prefix

ローカル使用IPv4 / IPv6変換プレフィックス

Abstract

概要

This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms.

このドキュメントでは、IPv4 / IPv6変換メカニズムを有効にするドメイン内でローカルに使用するために、IPv6プレフィックス64：ff9b：1 :: / 48を予約しています。

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 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、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/rfc8215.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8215で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright（c）2017 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Why 64:ff9b:1::/48? . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Prefix Length . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  Prefix Value  . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Deployment Considerations . . . . . . . . . . . . . . . . . .   4
   6.  Checksum Neutrality . . . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7
1. Introduction
1. はじめに

This document reserves 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. This facilitates the coexistence of multiple IPv4/IPv6 translation mechanisms in the same network without requiring the use of a Network-Specific Prefix assigned from the operator's allocated global unicast address space.

このドキュメントでは、IPv4 / IPv6変換メカニズムを有効にするドメイン内でのローカル使用のために64：ff9b：1 :: / 48を予約しています。これにより、オペレーターに割り当てられたグローバルユニキャストアドレススペースから割り当てられたネットワーク固有のプレフィックスを使用せずに、同じネットワークで複数のIPv4 / IPv6変換メカニズムを共存させることができます。

2. Terminology
2. 用語

This document uses the following terms:

このドキュメントでは、次の用語を使用します。

Network-Specific Prefix (NSP) A globally unique prefix assigned by a network operator for use with an IPv4/IPv6 translation mechanism [RFC6052].

ネットワーク固有のプレフィックス（NSP）IPv4 / IPv6変換メカニズム[RFC6052]で使用するためにネットワークオペレーターによって割り当てられたグローバルに一意のプレフィックス。

Well-Known Prefix (WKP) The prefix 64:ff9b::/96, which is reserved for use with the [RFC6052] IPv4/IPv6 address translation algorithms.

既知のプレフィックス（WKP）プレフィックス64：ff9b :: /96。[RFC6052] IPv4 / IPv6アドレス変換アルゴリズムで使用するために予約されています。

3. Problem Statement
3. 問題文

Since the WKP 64:ff9b::/96 was reserved by [RFC6052], several new IPv4/IPv6 translation mechanisms have been defined by the IETF, such as those defined in [RFC6146] and [RFC7915]. These mechanisms target various different use cases. An operator might therefore wish to make use of several of them simultaneously.

WKP 64：ff9b :: / 96は[RFC6052]によって予約されていたため、[RFC6146]や[RFC7915]で定義されているものなど、IETFによっていくつかの新しいIPv4 / IPv6変換メカニズムが定義されています。これらのメカニズムは、さまざまな異なるユースケースを対象としています。したがって、オペレーターはそれらのいくつかを同時に使用したいと思うかもしれません。

The WKP is reserved specifically for use with the algorithms specified in [RFC6052]. More recent RFCs describe IPv4/IPv6 translation mechanisms that use different algorithms. An operator deploying such mechanisms cannot make use of the WKP in a legitimate fashion.

WKPは、特に[RFC6052]で指定されたアルゴリズムで使用するために予約されています。最近のRFCでは、さまざまなアルゴリズムを使用するIPv4 / IPv6変換メカニズムについて説明しています。このようなメカニズムを展開するオペレーターは、正当な方法でWKPを利用することはできません。

Also, because the WKP is a /96, an operator preferring to use the WKP over an NSP can do so for only one of their IPv4/IPv6 translation mechanisms. All others must necessarily use an NSP.

また、WKPは/ 96であるため、NSPよりもWKPを使用することを好むオペレーターは、IPv4 / IPv6変換メカニズムの1つに対してのみ使用できます。他のすべては必ずNSPを使用する必要があります。

Section 3.1 of [RFC6052] imposes certain restrictions on the use of the WKP, such as forbidding its use in combination with private IPv4 addresses [RFC1918]. These restrictions might conflict with the operator's desired use of an IPv4/IPv6 translation mechanism.

[RFC6052]のセクション3.1では、プライベートIPv4アドレス[RFC1918]と組み合わせて使用​​することを禁止するなど、WKPの使用に特定の制限を課しています。これらの制限は、オペレーターが希望するIPv4 / IPv6変換メカニズムの使用と競合する可能性があります。

In summary, there is a need for a local-use prefix that facilitates the coexistence of multiple IPv4/IPv6 translation mechanisms in a single network domain, as well as the deployment of translation mechanisms that do not use the [RFC6052] algorithms or adhere to its usage restrictions.

要約すると、単一のネットワークドメインでの複数のIPv4 / IPv6変換メカニズムの共存を容易にするローカル使用プレフィックス、および[RFC6052]アルゴリズムを使用しない、または準拠しない変換メカニズムの展開が必要です。その使用制限。

4. Why 64:ff9b:1::/48?
4. なぜ64：ff9b：1 :: / 48なのですか？
4.1. Prefix Length
4.1. プレフィックス長

One of the primary goals of this document is to facilitate multiple simultaneous deployments of IPv4/IPv6 translation mechanisms in a single network. The first criterion is therefore that the prefix length chosen must be shorter than the prefix length used by any individual translation mechanism.

このドキュメントの主な目的の1つは、単一のネットワークでIPv4 / IPv6変換メカニズムの複数の同時展開を容易にすることです。したがって、最初の基準は、選択されたプレフィックス長が、個々の変換メカニズムで使用されるプレフィックス長よりも短くなければならないということです。

The second criterion is that the prefix length chosen is a multiple of 16. This ensures the prefix ends on a colon boundary when representing it in text, easing operator interaction with it.

2番目の基準は、選択された接頭辞の長さが16の倍数であることです。これにより、接頭辞がテキストで表されるときにコロンの境界で終了し、オペレーターとの対話が容易になります。

The [RFC6052] algorithms specifies IPv4/IPv6 translation prefixes as short as /32. In order to facilitate multiple instances of translation mechanisms using /32s, while at the same time aligning on a 16-bit boundary, it would be necessary to reserve a /16. Doing so, however, was considered as too wasteful by the IPv6 Operations Working Group.

[RFC6052]アルゴリズムは、IPv4 / IPv6変換プレフィックスを/ 32と指定しています。 / 32を使用する変換メカニズムの複数のインスタンスを容易にするために、同時に16ビットの境界に合わせて、/ 16を予約する必要があります。ただし、そうすることは、IPv6運用作業部会によって無駄が多すぎると見なされました。

The shortest translation prefix that was reported to the IPv6 Operations Working Group as being deployed in a live network was /64. The longest 16-bit-aligned prefix length that can accommodate multiple instances of /64 is /48. The prefix length of /48 was therefore chosen, as it satisfies both the criteria above, while at the same time avoids wasting too much of the IPv6 address space.

ライブネットワークに展開されているとIPv6 Operations Working Groupに報告された最短の変換プレフィックスは/ 64でした。 / 64の複数のインスタンスに対応できる最長の16ビット境界の接頭辞長は/ 48です。したがって、プレフィックス長/ 48が選択されました。これは、上記の両方の基準を満たしていると同時に、IPv6アドレス空間の無駄遣いを避けているためです。

4.2. Prefix Value
4.2. プレフィックス値

It is desirable to minimise the amount of additional "pollution" in the unallocated IPv6 address space caused by the reservation made by this document. Ensuring the reserved prefix is adjacent to the 64:ff9b::/96 WKP already reserved by [RFC6052] accomplishes this.

このドキュメントによって行われた予約によって引き起こされる未割り当てのIPv6アドレス空間での追加の「汚染」の量を最小限に抑えることが望ましいです。 [RFC6052]によって予約済みの64：ff9b :: / 96 WKPに予約済みの接頭辞が隣接していることを確認すると、これが実現します。

Given the previous decision to use a prefix length of /48, this leaves two options: 64:ff9a:ffff::/48 and 64:ff9b:1::/48.

プレフィックス長として/ 48を使用するという以前の決定を踏まえると、64：ff9a：ffff :: / 48および64：ff9b：1 :: / 48という2つのオプションが残ります。

64:ff9a:ffff::/48 has the benefit that it is completely adjacent to the [RFC6052] WKP. That is, 64:ff9a:ffff::/48 and 64:ff9b::/96 combine to form an uninterrupted range of IPv6 addresses starting with 64:ff9a:ffff:: and ending with 64:ff9b::ffff:ffff.

64：ff9a：ffff :: / 48は、[RFC6052] WKPに完全に隣接しているという利点があります。つまり、64：ff9a：ffff :: / 48と64：ff9b :: / 96を組み合わせて、64：ff9a：ffff ::で始まり64：ff9b :: ffff：ffffで終わる、中断されないIPv6アドレスの範囲を形成します。

64:ff9b:1::/48 is, on the other hand, not completely adjacent to 64:ff9b::/96. The range starting with 64:ff9b::1:0:0 and ending with 64:ff9b:0:ffff:ffff:ffff:ffff:ffff would remain unallocated.

一方、64：ff9b：1 :: / 48は、64：ff9b :: / 96に完全に隣接していません。 64：ff9b :: 1：0：0で始まり、64：ff9b：0：ffff：ffff：ffff：ffff：ffffで終わる範囲は、未割り当てのままになります。

This particular drawback is, however, balanced by the fact that the smallest possible aggregate prefix that covers both the [RFC6052] WKP and 64:ff9a:ffff::/48 is much larger than the smallest possible aggregate prefix that covers both the [RFC6052] WKP and 64:ff9b:1::/48. These aggregate prefixes are 64:ff9a::/31 and 64:ff9b::/47, respectively. IPv6 address space is allocated using prefixes rather than address ranges, so it could be argued that 64:ff9b:1::/48 is the option that would cause special-use prefixes reserved for IPv4/IPv6 translation to "pollute" the minimum possible amount of unallocated IPv6 address space.

ただし、この特定の欠点は、[RFC6052] WKPと64：ff9a：ffff :: / 48の両方をカバーする可能な最小の集約プレフィックスが、[RFC6052]の両方をカバーする可能な最小の集約プレフィックスよりもはるかに大きいという事実によってバランスが取れています。 ] WKPおよび64：ff9b：1 :: / 48。これらの集約プレフィックスは、それぞれ64：ff9a :: / 31および64：ff9b :: / 47です。 IPv6アドレススペースは、アドレス範囲ではなくプレフィックスを使用して割り当てられるため、64：ff9b：1 :: / 48は、IPv4 / IPv6変換用に予約された特殊用途のプレフィックスを可能な限り最小限に「汚染」させるオプションであると主張できます。未割り当てのIPv6アドレス空間の量。

Finally, 64:ff9b:1::/48 also has the advantage that its textual representation is shorter than 64:ff9a:ffff::/48. While this might seem insignificant, the preference human network operators have for addresses that are simple to type should not be underestimated.

最後に、64：ff9b：1 :: / 48には、テキスト表現が64：ff9a：ffff :: / 48よりも短いという利点もあります。これは重要ではないように思えるかもしれませんが、入力が簡単なアドレスに対するヒューマンネットワークオペレーターの設定を過小評価しないでください。

After weighing the above pros and cons, 64:ff9b:1::/48 was chosen.

上記の長所と短所を比較検討した結果、64：ff9b：1 :: / 48が選択されました。

5. Deployment Considerations
5. 導入に関する考慮事項

64:ff9b:1::/48 is intended as a technology-agnostic and generic reservation. A network operator may freely use it in combination with any kind of IPv4/IPv6 translation mechanism deployed within their network.

64：ff9b：1 :: / 48は、技術にとらわれない一般的な予約を目的としています。ネットワークオペレーターは、ネットワーク内に展開されているあらゆる種類のIPv4 / IPv6変換メカニズムと組み合わせて自由に使用できます。

By default, IPv6 nodes and applications must not treat IPv6 addresses within 64:ff9b:1::/48 differently from other globally scoped IPv6 addresses. In particular, they must not make any assumptions regarding the syntax or properties of those addresses (e.g., the existence and location of embedded IPv4 addresses) or the type of associated translation mechanism (e.g., whether it is stateful or stateless).

デフォルトでは、IPv6ノードとアプリケーションは、64：ff9b：1 :: / 48内のIPv6アドレスを他のグローバルスコープのIPv6アドレスと異なる方法で処理してはなりません。特に、これらのアドレスの構文やプロパティ（たとえば、埋め込まれたIPv4アドレスの存在と場所）、または関連する変換メカニズムのタイプ（たとえば、ステートフルかステートレスか）を想定してはなりません。

64:ff9b:1::/48 or any more-specific prefix may only be used in inter-domain routing if done in accordance with the rules described in Section 3.2 of [RFC6052].

64：ff9b：1 :: / 48またはより具体的なプレフィックスは、[RFC6052]のセクション3.2で説明されているルールに従って行われた場合にのみ、ドメイン間ルーティングで使用できます。

Note that 64:ff9b:1::/48 (or any more-specific prefix) is distinct from the WKP 64:ff9b::/96. Therefore, the restrictions on the use of the WKP described in Section 3.1 of [RFC6052] do not apply to the use of 64:ff9b:1::/48.

64：ff9b：1 :: / 48（またはより具体的なプレフィックス）は、WKP 64：ff9b :: / 96とは異なることに注意してください。したがって、[RFC6052]のセクション3.1で説明されているWKPの使用に関する制限は、64：ff9b：1 :: / 48の使用には適用されません。

Operators tempted to use the covering aggregate prefix 64:ff9b::/47 to refer to all special-use prefixes currently reserved for IPv4/IPv6 translation should be warned that this aggregate includes a range of unallocated addresses (see Section 4.2) that the IETF could potentially reserve in the future for entirely different purposes.

カバーする集約プレフィックス64：ff9b :: / 47を使用してIPv4 / IPv6変換用に現在予約されているすべての特殊用途のプレフィックスを参照しようとするオペレーターは、この集約にIETFが割り当てる未割り当てアドレスの範囲（セクション4.2を参照）が含まれていることを警告する必要があります将来的にはまったく異なる目的のために予約する可能性があります。

6. Checksum Neutrality
6. チェックサム中立性

Use of 64:ff9b:1::/48 does not in itself guarantee checksum neutrality, as many of the IPv4/IPv6 translation algorithms it can be used with are fundamentally incompatible with checksum-neutral address translations.

64：ff9b：1 :: / 48を使用しても、それを使用できるIPv4 / IPv6変換アルゴリズムの多くはチェックサムニュートラルアドレス変換と基本的に互換性がないため、チェックサムの中立性は保証されません。

Section 4.1 of [RFC6052] contains further discussion about IPv4/IPv6 translation and checksum neutrality.

[RFC6052]のセクション4.1には、IPv4 / IPv6変換とチェックサムの中立性に関する詳細な説明が含まれています。

The Stateless IP/ICMP Translation algorithm [RFC7915] is one well-known algorithm that can operate in a checksum-neutral manner, when using the [RFC6052] algorithms for all of its address translations. However, in order to attain checksum neutrality, it is imperative that the translation prefix be chosen carefully. Specifically, in order for a 96-bit [RFC6052] prefix to be checksum neutral, all the six 16-bit words in the prefix must add up to a multiple of 0xffff.

ステートレスIP / ICMP変換アルゴリズム[RFC7915]は、そのすべてのアドレス変換に[RFC6052]アルゴリズムを使用する場合に、チェックサムニュートラルな方法で動作できるよく知られたアルゴリズムの1つです。ただし、チェックサムの中立性を実現するには、変換接頭辞を慎重に選択することが不可欠です。具体的には、96ビット[RFC6052]プレフィックスがチェックサムニュートラルになるためには、プレフィックスの6つの16ビットワードすべてを合計して、0xffffの倍数にする必要があります。

The following non-exhaustive list contains examples of translation prefixes that are checksum neutral when used with the [RFC7915] and [RFC6052] algorithms:

次の完全ではないリストに、[RFC7915]および[RFC6052]アルゴリズムで使用した場合にチェックサムニュートラルな変換プレフィックスの例が含まれています。 

   o  64:ff9b:1:fffe::/96
        
   o  64:ff9b:1:fffd:1::/96
        
   o  64:ff9b:1:fffc:2::/96
        
   o  64:ff9b:1:abcd:0:5431::/96
7. IANA Considerations
7. IANAに関する考慮事項

The IANA has added the following entry to the "IANA IPv6 Special-Purpose Address Registry":

IANAは、「IANA IPv6特別目的アドレスレジストリ」に次のエントリを追加しました。 

              +----------------------+---------------------+
              | Attribute            | Value               |
              +----------------------+---------------------+
              | Address Block        | 64:ff9b:1::/48      |
              | Name                 | IPv4-IPv6 Translat. |
              | RFC                  | RFC 8215            |
              | Allocation Date      | 2017-06             |
              | Termination Date     | N/A                 |
              | Source               | True                |
              | Destination          | True                |
              | Forwardable          | True                |
              | Globally Reachable   | False               |
              | Reserved-by-Protocol | False               |
              +----------------------+---------------------+

The IANA has also added the following footnote to the 0000::/8 entry of the "Internet Protocol Version 6 Address Space" registry:

IANAは、「インターネットプロトコルバージョン6アドレススペース」レジストリの0000 :: / 8エントリに次の脚注も追加しました。

64:ff9b:1::/48 reserved for Local-Use IPv4/IPv6 Translation [RFC8215].

64：ff9b：1 :: / 48は、ローカル使用のIPv4 / IPv6変換[RFC8215]用に予約されています。

8. Security Considerations
8. セキュリティに関する考慮事項

The reservation of 64:ff9b:1::/48 is not known to cause any new security considerations beyond those documented in Section 5 of [RFC6052].

64：ff9b：1 :: / 48を予約しても、[RFC6052]のセクション5に記載されているものを超える新しいセキュリティ上の考慮事項が発生することはありません。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <https://www.rfc-editor.org/info/rfc6052>.

[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、DOI 10.17487 / RFC6052、2010年10月、< https://www.rfc-editor.org/info/rfc6052>。

9.2. Informative References
9.2. 参考引用

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.

[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<https://www.rfc-editor.org/info/rfc1918>。

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.

[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスおよびプロトコル変換」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https： //www.rfc-editor.org/info/rfc6146>。

[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, <https://www.rfc-editor.org/info/rfc7915>.

[RFC7915] Bao、C.、Li、X.、Baker、F.、Anderson、T。、およびF. Gont、「IP / ICMP変換アルゴリズム」、RFC 7915、DOI 10.17487 / RFC7915、2016年6月、<https： //www.rfc-editor.org/info/rfc7915>。

Acknowledgements

謝辞

The author would like to thank Fred Baker, Mohamed Boucadair, Brian E. Carpenter, Pier Carlo Chiodi, Joe Clarke, David Farmer, Suresh Krishnan, Warren Kumari, Holger Metschulat, Federico Santandrea, and David Schinazi for contributing to the creation of this document.

このドキュメントの作成に貢献してくれたFred Baker、Mohamed Boucadair、Brian E. Carpenter、Pier Carlo Chiodi、Joe Clarke、David Farmer、Suresh Krishnan、Warren Kumari、Holger Metschulat、Federico Santandrea、David Schinaziに感謝します。 。

Author's Address

著者のアドレス

Tore Anderson Redpill Linpro Vitaminveien 1A 0485 Oslo Norway

Tore Anderson Redpill Linpro Vitaminveien 1A 0485 Oslo Norway 

   Phone: +47 959 31 212
   Email: tore@redpill-linpro.com
   URI:   http://www.redpill-linpro.com