RFC 7335 - IPv4 Service Continuity Prefix 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7335
タイトル : RFC 7335 - IPv4サービス継続性プレフィックス
翻訳編集 : 自動生成

[要約] RFC 7335は、IPv4サービスの連続性プレフィックスに関するガイドラインです。その目的は、IPv4アドレスの再利用を促進し、サービスの連続性を確保することです。

Internet Engineering Task Force (IETF)                          C. Byrne
Request for Comments: 7335                                   T-Mobile US
Updates: 6333                                                August 2014
Category: Standards Track
ISSN: 2070-1721

IPv4 Service Continuity Prefix

IPv4サービス継続性プレフィックス

Abstract

概要

Dual-Stack Lite (DS-Lite), defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element. Per this memo, IANA has generalized that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution.

RFC 6333で定義されているデュアルスタックライト（DS-Lite）は、IANAに対して、1920.0.0 / 29をBasic Bridging BroadBand（B4）要素用に予約するように指示します。このメモに従って、IANAは、ルーティングされていないIPv4インターフェースにIPv6移行ソリューションの一部として番号を付ける必要がある他のケースを含めるように予約を一般化しました。

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/rfc7335.

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

著作権表示

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.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  The Case of 464XLAT  . . . . . . . . . . . . . . . . . . . . .  2
   4.  Choosing 192.0.0.0/29  . . . . . . . . . . . . . . . . . . . .  3
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  3
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  3
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  4
   8.  Normative References . . . . . . . . . . . . . . . . . . . . .  4

1. Introduction

1. はじめに

DS-Lite [RFC6333] directs IANA to reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element. This memo generalizes that IANA reservation to include other cases where a non-routed IPv4 interface must be numbered in an IPv6 transition solution. IANA has listed the address block 192.0.0.0/29 reserved for IPv4 Service Continuity Prefix. The result is that 192.0.0.0/29 may be used in any system that requires IPv4 addresses for backward compatibility with IPv4 communications in an IPv6-only network but does not emit IPv4 packets "on the wire".

DS-Lite [RFC6333]は、基本ブリッジングブロードバンド（B4）エレメント用に192.0.0.0/29を予約するようIANAに指示します。このメモは、ルーティングされていないIPv4インターフェースがIPv6移行ソリューションで番号付けされなければならない他のケースを含むようにIANA予約を一般化します。 IANAは、IPv4サービス継続性プレフィックス用に予約されたアドレスブロック192.0.0.0/29をリストしています。その結果、192.0.0.0 / 29は、IPv6のみのネットワークでのIPv4通信との下位互換性のためにIPv4アドレスを必要とするが、「ネットワーク上」でIPv4パケットを送信しないシステムで使用できます。

This generalization does not impact the use of the IPv4 Service Continuity Prefix in a DS-Lite context.

この一般化は、DS-LiteコンテキストでのIPv4サービス継続性プレフィックスの使用に影響を与えません。

2. Conventions

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 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. The Case of 464XLAT

3. 464XLATの場合

464XLAT [RFC6877] describes an architecture for providing IPv4 communication over an IPv6-only access network. One of the methods described in [RFC6877] is for the customer-side translator (CLAT) to be embedded in the host, such as a smartphone or a CPE (Customer Premises Equipment). In such scenarios, the host must have an IPv4 address configured to present to the host network stack and for applications to bind IPv4 sockets.

464XLAT [RFC6877]は、IPv6のみのアクセスネットワーク上でIPv4通信を提供するためのアーキテクチャについて説明しています。 [RFC6877]で説明されている方法の1つは、スマートフォンやCPE（顧客宅内機器）などのホストに顧客側トランスレータ（CLAT）を埋め込むことです。このようなシナリオでは、ホストは、ホストネットワークスタックに提示し、アプリケーションがIPv4ソケットをバインドするように構成されたIPv4アドレスを持っている必要があります。

4. Choosing 192.0.0.0/29

4. 192.0.0.0/29の選択

To avoid conflicts with any other network that may communicate with the CLAT or other IPv6 transition solution, a locally unique IPv4 address must be assigned.

CLATまたは他のIPv6移行ソリューションと通信する可能性がある他のネットワークとの競合を回避するには、ローカルで一意のIPv4アドレスを割り当てる必要があります。

IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333], which is dedicated for DS-Lite. As defined in [RFC6333], this subnet is only present between the B4 and the Address Family Transition Router (AFTR) and never emits packets from this prefix "on the wire". 464XLAT has the same need for a non-routed IPv4 prefix, and this same need may be common for other similar solutions. It is most prudent and effective to generalize 192.0.0.0/29 for the use of supporting IPv4 interfaces in IPv6 transition technologies rather than reserving a prefix for every possible solution.

IANAは、DS-Lite専用の[RFC6333]で192.0.0.0/29の既知の範囲を定義しています。 [RFC6333]で定義されているように、このサブネットはB4とアドレスファミリートランジションルーター（AFTR）の間にのみ存在し、この「プレフィックス」からパケットを送信しません。 464XLATには、ルーティングされないIPv4プレフィックスに対する同じニーズがあり、この同じニーズは他の同様のソリューションにも共通している可能性があります。考えられるすべてのソリューションのプレフィックスを予約するのではなく、IPv6移行テクノロジでIPv4インターフェイスをサポートするために192.0.0.0/29を一般化することが最も賢明で効果的です。

With this memo, 192.0.0.0/29 is now generalized across multiple IPv4 continuity solutions such as 464XLAT and DS-Lite. A host MUST NOT enable two active IPv4 continuity solutions simultaneously in a way that would cause a node to have overlapping 192.0.0.0/29 address space.

このメモにより、192.0.0.0 / 29は、464XLATやDS-Liteなどの複数のIPv4継続性ソリューション全体で一般化されました。ホストは、ノードに192.0.0.0/29アドレス空間の重複を引き起こすような方法で、2つのアクティブなIPv4継続性ソリューションを同時に有効にしてはなりません（MUST NOT）。

5. Security Considerations

5. セキュリティに関する考慮事項

There are no new security considerations beyond what is described [RFC6333] and [RFC6877].

[RFC6333]と[RFC6877]で説明されている以上の新しいセキュリティ上の考慮事項はありません。

6. IANA Considerations

6. IANAに関する考慮事項

IANA has updated the IPv4 Special-Purpose Address Registry available at (http://www.iana.org/assignments/iana-ipv4-special-registry/) as follows:

IANAは、（http://www.iana.org/assignments/iana-ipv4-special-registry/）で入手できるIPv4専用アドレスレジストリを次のように更新しました。

OLD:

古い：

192.0.0.0/29 DS-Lite [RFC6333]

NEW:

新着：

192.0.0.0/29 IPv4 Service Continuity Prefix [RFC7335]

192.0.0.0/29 IPv4サービス継続性プレフィックス[RFC7335]

      +----------------------+-----------------------------------+
      | Attribute            | Value                             |
      +----------------------+-----------------------------------+
      | Address Block        | 192.0.0.0/29                      |
      | Name                 | IPv4 Service Continuity Prefix    |
      | RFC                  | RFC 7335                          |
      | Allocation Date      | June 2011                         |
      | Termination Date     | N/A                               |
      | Source               | True                              |
      | Destination          | True                              |
      | Forwardable          | True                              |
      | Global               | False                             |
      | Reserved-by-Protocol | False                             |
      +----------------------+-----------------------------------+

7. Acknowledgements

7. 謝辞

This document has been substantially improved by specific feedback from Dave Thaler, Fred Baker, Wes George, Lorenzo Colitti, and Mohamed Boucadair.

このドキュメントは、Dave Thaler、Fred Baker、Wes George、Lorenzo Colitti、およびMohamed Boucadairからの具体的なフィードバックによって大幅に改善されています。

8. Normative References

8. 引用文献

[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月。

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.

[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月。

[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013.

[RFC6877] Mawatari、M.、Kawashima、M.、and C. Byrne、 "464XLAT：Combination of Stateful and Stateless Translation"、RFC 6877、April 2013。

Author's Address

著者のアドレス

Cameron Byrne Bellevue, WA USA

かめろんＢｙｒねべっぇゔえ、わうさ

   EMail: Cameron.Byrne@T-Mobile.com