RFC 8026 - Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8026
タイトル : RFC 8026 - ユニファイドIPv4-in-IPv6 Softwire Customer Premises Equipment（CPE）：DHCPv6ベースの優先順位付けメカニズム
翻訳編集 : 自動生成

[要約] RFC 8026は、IPv4-in-IPv6ソフトワイヤ顧客プレミス装置（CPE）の統一化に関するもので、DHCPv6ベースの優先化メカニズムを提供します。このRFCの目的は、IPv4-in-IPv6ソフトワイヤネットワークにおいて、異なるトラフィッククラスを優先的に処理するための標準的な方法を提供することです。

Internet Engineering Task Force (IETF)                      M. Boucadair
Request for Comments: 8026                                        Orange
Category: Standards Track                                      I. Farrer
ISSN: 2070-1721                                      Deutsche Telekom AG
                                                           November 2016

Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism

ユニファイドIPv4-in-IPv6 Softwire Customer Premises Equipment（CPE）：DHCPv6ベースの優先順位付けメカニズム

Abstract

概要

In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option, whereby a single instance of Customer Premises Equipment (CPE) can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4-in-IPv6 services by providing a prioritization mechanism.

IPv6のみのプロバイダーネットワークでは、IPv6にカプセル化されたIPv4パケットの転送は、IPv4サービスの継続性の問題に対する一般的な解決策です。このためにさまざまな機能的アプローチが開発され、それぞれに固有の特性があります。これらのアプローチは同様の機能アーキテクチャを共有し、同じデータプレーンメカニズムを使用するため、このメモはDHCPv6オプションを指定します。これにより、Customer Premises Equipment（CPE）の単一インスタンスが、カプセル化されたIPv4-inを提供するための標準化され提案されたアプローチのすべてと相互作用できます。 -優先順位付けメカニズムを提供することによる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 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/rfc8026.

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

著作権表示

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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.1.  Requirements Language . . . . . . . . . . . . . . . .   4
     1.2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  DHCPv6 S46 Priority Option  . . . . . . . . . . . . . . .   5
     1.4.  DHCPv6 Client Behavior  . . . . . . . . . . . . . . . . .   6
     1.5.  DHCPv6 Server Behavior  . . . . . . . . . . . . . . . . .   7
   2.  Operator Deployment Considerations for Deploying Multiple
       Softwire Mechanisms . . . . . . . . . . . . . . . . . . . . .   7
     2.1.  Client Address Planning . . . . . . . . . . . . . . . . .   7
     2.2.  Backwards Compatability with Existing Softwire Clients  .   7
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  S46 Mechanisms and Their Identifying Option Codes . . . .   8
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

IPv4 service continuity is one of the major technical challenges that must be considered during IPv6 migration. Over the past few years, a number of different approaches have been developed to assist with this problem (e.g., as described in [RFC6333], [RFC7596], and [RFC7597]). These approaches, referred to as "S46 mechanisms" in this document, exist in order to meet the particular deployment, scaling, addressing, and other requirements of different service providers' networks.

IPv4サービスの継続性は、IPv6の移行中に考慮する必要がある主要な技術的課題の1つです。過去数年にわたって、この問題を支援するために多くの異なるアプローチが開発されてきました（たとえば、[RFC6333]、[RFC7596]、および[RFC7597]で説明されているように）。このドキュメントでは「S46メカニズム」と呼ばれるこれらのアプローチは、さまざまなサービスプロバイダーのネットワークの特定の展開、スケーリング、アドレス指定、およびその他の要件を満たすために存在します。

A common feature shared among all of the differing modes is the integration of softwire tunnel endpoint functionality into the Customer Premises Equipment (CPE) router. Due to this inherent data plane similarity, a single CPE may be capable of supporting several different approaches. Users may also wish to configure a specific mode of operation.

すべての異なるモードで共有される共通の機能は、Softwireトンネルエンドポイント機能を顧客宅内機器（CPE）ルーターに統合することです。この固有のデータプレーンの類似性により、単一のCPEがいくつかの異なるアプローチをサポートできる場合があります。ユーザーは、特定の動作モードを構成することもできます。

A service provider's network may also have more than one S46 mechanism enabled in order to support a diverse CPE population with differing client functionality, such as during a migration between mechanisms or where services require specific supporting softwire architectures.

サービスプロバイダーのネットワークでは、メカニズム間の移行中やサービスが特定のサポートソフトワイヤーアーキテクチャを必要とする場合など、さまざまなクライアント機能を持つ多様なCPE集団をサポートするために、複数のS46メカニズムを有効にすることもできます。

For softwire-based services to be successfully established, it is essential that the customer's end node and the service provider's end node and provisioning systems are able to indicate their capabilities and preferred mode of operation.

ソフトワイヤーベースのサービスが正常に確立されるためには、顧客のエンドノードとサービスプロバイダーのエンドノードおよびプロビジョニングシステムがそれらの機能と優先操作モードを示すことができることが不可欠です。

A number of DHCPv6 options for the provisioning of softwires have been standardized:

ソフトワイヤーのプロビジョニングのためのいくつかのDHCPv6オプションが標準化されました。

RFC 6334 Defines DHCPv6 option 64 for configuring Basic Bridging BroadBand (B4) [RFC6333] elements with the IPv6 address of the Address Family Transition Router (AFTR) [RFC6333].

RFC 6334は、DHCPv6オプション64を定義し、アドレスブリッジ遷移ルーター（AFTR）[RFC6333]のIPv6アドレスで基本ブリッジングブロードバンド（B4）[RFC6333]要素を構成します。

RFC 7341 Defines DHCPv6 option 88 for configuring the address of a DHCPv4-over-DHCPv6 server, which can then be used by a softwire client for obtaining further configuration.

RFC 7341は、DHCPv4-over-DHCPv6サーバーのアドレスを構成するためのDHCPv6オプション88を定義します。このアドレスは、詳細な構成を取得するためにSoftwireクライアントで使用できます。

RFC 7598 Defines DHCPv6 options 94, 95, and 96 for provisioning Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597], Mapping of Address and Port using Translation (MAP-T) [RFC7599], and Lightweight 4over6 [RFC7596] respectively.

RFC 7598は、DHCPv6オプション94、95、96を定義しています。カプセル化されたアドレスとポートのマッピング（MAP-E）[RFC7597]、変換を使用したアドレスとポートのマッピング（MAP-T）[RFC7599]、およびLightweight 4over6 [RFC7596 ]それぞれ。

This document describes a DHCPv6-based prioritization method, whereby a CPE that supports several S46 mechanisms and receives configuration for more than one can prioritize which mechanism to use. The method requires no server-side logic to be implemented and only uses a simple S46 mechanism prioritization to be implemented in the CPE.

このドキュメントでは、DHCPv6ベースの優先順位付け方法について説明します。これにより、複数のS46メカニズムをサポートし、複数の構成を受け取るCPEが、使用するメカニズムに優先順位を付けることができます。この方法では、サーバー側のロジックを実装する必要はなく、単純なS46メカニズムの優先順位付けのみを使用してCPEに実装されます。

The prioritization method as described here does not provide redundancy between S46 mechanisms for the client. That is, if the highest priority S46 mechanism that has been provisioned to the client is not available for any reason, the means for identifying this and falling back to the S46 mechanism with the next highest priority is not in the scope of this document.

ここで説明する優先順位付け方法では、クライアントのS46メカニズム間の冗長性は提供されません。つまり、クライアントにプロビジョニングされた最も優先度の高いS46メカニズムが何らかの理由で利用できない場合、これを識別して次に優先度の高いS46メカニズムにフォールバックする手段は、このドキュメントの範囲外です。

1.1. Terminology

1.1. 用語

This document makes use of the following terms:

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

o Address Family Transition Router (AFTR): The IPv4-in-IPv6 tunnel termination point and the Network Address Translator IPv4/IPv4 (NAT44) function deployed in the operator's network [RFC6333].

o アドレスファミリトランジションルーター（AFTR）：IPv4-in-IPv6トンネルターミネーションポイントおよびオペレーターのネットワークに導入されたネットワークアドレストランスレーターIPv4 / IPv4（NAT44）機能[RFC6333]。

o Border Relay (BR): A MAP-enabled router managed by the service provider at the edge of a MAP domain. A BR has at least an IPv6-enabled interface and an IPv4 interface connected to the native IPv4 network [RFC7597].

o ボーダーリレー（BR）：サービスプロバイダーがMAPドメインのエッジで管理するMAP対応ルーター。 BRには、ネイティブIPv4ネットワーク[RFC7597]に接続された少なくともIPv6対応のインターフェースとIPv4インターフェースがあります。

o Customer Premises Equipment (CPE): Denotes the equipment at the customer edge that terminates the customer end of an IPv6 transitional tunnel. In some documents (e.g., [RFC7597]), this functional entity is called the Customer Edge (CE).

o 顧客宅内機器（CPE）：IPv6トランジショナルトンネルの顧客側を終端する顧客エッジの機器を示します。一部の文書（[RFC7597]など）では、この機能エンティティはカスタマーエッジ（CE）と呼ばれています。

1.1.1. Requirements Language

1.1.1. 要件言語

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]で説明されているように解釈されます。

1.2. Rationale

1.2. 根拠

The following rationale has been adopted for this document:

このドキュメントには次の根拠が採用されています。

(1) Simplified solution migration paths: Define unified CPE behavior, allowing for smooth migration between the different S46 mechanisms.

（1）簡素化されたソリューション移行パス：統一されたCPE動作を定義し、異なるS46メカニズム間のスムーズな移行を可能にします。

(2) Deterministic CPE coexistence behavior: Specify the behavior when several S46 mechanisms coexist in the CPE.

（2）確定的CPE共存動作：複数のS46メカニズムがCPEに共存する場合の動作を指定します。

(3) Deterministic service provider coexistence behavior: Specify the behavior when several modes coexist in the service providers network.

（3）確定的なサービスプロバイダーの共存動作：サービスプロバイダーネットワークで複数のモードが共存する場合の動作を指定します。

(4) Reusability: Maximize the reuse of existing functional blocks including tunnel endpoints, the port-restricted Network Address Port Translator IPv4/IPv4 (NAPT44), forwarding behavior, etc.

（4）再利用性：トンネルエンドポイント、ポート制限のネットワークアドレスポートトランスレーターIPv4 / IPv4（NAPT44）、転送動作などを含む既存の機能ブロックの再利用を最大化します。

(5) Solution agnostic: Adopt neutral terminology and avoid (as far as possible) overloading the document with solution-specific terms.

（5）ソリューションにとらわれない：中立的な用語を採用し、ドキュメントにソリューション固有の用語を詰め込みすぎないようにします（可能な限り）。

(6) Flexibility: Allow operators to compile CPE software only for the mode(s) necessary for their chosen deployment context(s).

（6）柔軟性：オペレーターは、選択したデプロイメントコンテキストに必要なモードに対してのみCPEソフトウェアをコンパイルできます。

(7) Simplicity: Provide a model that allows operators to only implement the specific mode(s) that they require without the additional complexity of unneeded modes.

（7）シンプルさ：オペレーターが必要としない特定のモードのみを実装できるモデルを提供し、不要なモードの複雑さを追加する必要がありません。

1.3. DHCPv6 S46 Priority Option

1.3. DHCPv6 S46優先オプション

The S46 Priority Option is used to convey a priority order of IPv4 service continuity mechanisms. Figure 1 shows the format of the S46 Priority Option.

S46 Priority Optionは、IPv4サービス継続メカニズムの優先順位を伝えるために使用されます。図1は、S46優先オプションのフォーマットを示しています。

      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_S46_PRIORITY      |         option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        s46-option-code        |        s46-option-code        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              ...              |        s46-option-code        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: S46 Priority Option

図1：S46優先度オプション

o option-code: OPTION_S46_PRIORITY (111)

o オプションコード：OPTION_S46_PRIORITY（111）

o option-length: >=2 and a multiple of 2, in octets.

o オプション長：オクテットで> = 2および2の倍数。

o s46-option-code: 16-bit IANA-registered option code of the DHCPv6 option that is used to identify the softwire mechanism. S46 mechanisms are prioritized in the appearance order in the S46 Priority Option.

o s46-option-code：ソフトワイヤーメカニズムの識別に使用されるDHCPv6オプションの16ビットIANA登録オプションコード。 S46メカニズムは、S46優先度オプションの出現順に優先されます。

Codes in OPTION_S46_PRIORITY are processed in order; if a client receives more than one s46-option-code with a particular value, it should consider this case to be invalid. DHCP servers MAY validate the list of s46-option-code values to detect invalid values and duplicates. The option MUST contain at least one s46-option-code.

OPTION_S46_PRIORITYのコードは順番に処理されます。クライアントが特定の値を持つ複数のs46-option-codeを受け取った場合、このケースは無効であると見なす必要があります。 DHCPサーバーは、無効な値と重複を検出するためにs46-option-code値のリストを検証できます（MAY）。オプションには、少なくとも1つのs46-option-codeが含まれている必要があります。

1.4. DHCPv6 Client Behavior

1.4. DHCPv6クライアントの動作

Clients MAY request the OPTION_S46_PRIORITY option, as defined in [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. As a convenience to the reader, we mention here that the client includes requested option codes in the Option Request Option.

[RFC3315]、セクション17.1.1、18.1.1、18.1.3、18.1.4、18.1.5、および22.7で定義されているように、クライアントはOPTION_S46_PRIORITYオプションを要求できます（MAY）。読者の便宜のため、ここではクライアントがオプション要求オプションに要求されたオプションコードを含めることを述べます。

Upon receipt of a DHCPv6 Advertise message from the server containing OPTION_S46_PRIORITY, the client performs the following steps:

OPTION_S46_PRIORITYを含むサーバーからDHCPv6アドバタイズメッセージを受信すると、クライアントは次の手順を実行します。

1. Check the contents of the DHCPv6 message for options containing valid S46 mechanism configuration. A candidate list of possible S46 mechanisms is created from these option codes.

1. DHCPv6メッセージの内容をチェックして、有効なS46メカニズム構成を含むオプションを確認してください。可能なS46メカニズムの候補リストは、これらのオプションコードから作成されます。

2. Check the contents of OPTION_S46_PRIORITY for the DHCPv6 option codes contained in the included s46-option-code fields. From this, an S46 mechanism priority list is created, ordered from highest to lowest following the appearance order.

2. 含まれているs46-option-codeフィールドに含まれているDHCPv6オプションコードのOPTION_S46_PRIORITYの内容を確認します。これにより、S46メカニズムの優先順位リストが作成され、出現順に最も高いものから最も低いものへと並べられます。

3. Sequentially check the priority list against the candidate list until a match is found.

3. 一致が見つかるまで、優先リストと候補リストを順番にチェックします。

4. When a match is found, the client MUST configure the resulting S46 mechanism.

4. 一致が見つかった場合、クライアントは結果のS46メカニズムを構成する必要があります。

In the event that no match is found between the priority list and the candidate list, the client MAY proceed with configuring one or more of the provisioned S46 softwire mechanism(s). In this case, which mechanism(s) are chosen by the client is implementation specific and not defined here.

優先リストと候補リストの間に一致が見つからない場合、クライアントは、プロビジョニングされたS46ソフトワイヤーメカニズムの1つ以上の構成を続行できます（MAY）。この場合、クライアントがどのメカニズムを選択するかは実装固有であり、ここでは定義しません。

If an invalid OPTION_S46_PRIORITY option is received, the client MAY proceed with configuring the provisioned S46 mechanisms as if OPTION_S46_PRIORITY had not been received.

無効なOPTION_S46_PRIORITYオプションが受信された場合、クライアントは、OPTION_S46_PRIORITYが受信されなかったかのように、プロビジョニングされたS46メカニズムの構成を続行できます（MAY）。

If an unknown option code is received in the OPTION_S46_PRIORITY option, the client MUST skip it and continue processing other listed option codes if they exist. The initial option codes that are allowed to be included in an OPTION_S46_PRIORITY option are listed in Section 4.1.

不明なオプションコードがOPTION_S46_PRIORITYオプションで受信された場合、クライアントはそれをスキップし、リストされている他のオプションコードが存在する場合は、それらの処理を続行する必要があります。 OPTION_S46_PRIORITYオプションに含めることが許可されている初期オプションコードは、セクション4.1にリストされています。

1.5. DHCPv6 Server Behavior

1.5. DHCPv6サーバーの動作

Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in regard to option assignment. As a convenience to the reader, we mention here that the server will send a particular option code only if configured with specific values for that option code and if the client requested it.

[RFC3315]のセクション17.2.2および18.2は、オプションの割り当てに関するサーバーの動作を管理します。読者の便宜のために、サーバーが特定のオプションコードを送信するのは、そのオプションコードに特定の値が設定されていて、クライアントが要求した場合のみであることをここで述べます。

Option OPTION_S46_PRIORITY is a singleton. Servers MUST NOT send more than one instance of the OPTION_S46_PRIORITY option.

オプションOPTION_S46_PRIORITYはシングルトンです。サーバーは、OPTION_S46_PRIORITYオプションの複数のインスタンスを送信してはなりません（MUST NOT）。

2. Operator Deployment Considerations for Deploying Multiple Softwire Mechanisms

2. 複数のSoftwireメカニズムを展開するためのオペレーターの展開に関する考慮事項

The following subsections describe some considerations for operators who are planning on implementing multiple softwire mechanisms in their network (e.g., during a migration between mechanisms).

以下のサブセクションでは、ネットワークに複数のソフトワイヤーメカニズムを実装することを計画しているオペレーター（たとえば、メカニズム間の移行中）に関する考慮事項について説明します。

2.1. Client Address Planning

2.1. クライアントアドレス計画

As an operator's available IPv4 resources are likely to be limited, it may be desirable to use a common range of IPv4 addresses across all of the active softwire mechanisms. However, this is likely to result in difficulties in routing ingress IPv4 traffic to the correct Border Relay (BR) / AFTR instance, which is actively serving a given CE. For example, a client that is configured to use MAP-E may send its traffic to the MAP-E BR; however, on the return path, the ingress IP traffic gets routed to a MAP-T BR. The resulting translated packet that gets forwarded to the MAP-E client will be dropped.

オペレーターが利用できるIPv4リソースは限られている可能性が高いため、アクティブなすべてのソフトワイヤーメカニズムでIPv4アドレスの共通の範囲を使用することが望ましい場合があります。ただし、これにより、入力IPv4トラフィックを適切なボーダーリレー（BR）/ AFTRインスタンスにルーティングすることが困難になる可能性があります。たとえば、MAP-Eを使用するように構成されているクライアントは、そのトラフィックをMAP-E BRに送信できます。ただし、リターンパスでは、入力IPトラフィックはMAP-T BRにルーティングされます。 MAP-Eクライアントに転送される結果の変換されたパケットはドロップされます。

Therefore, operators are advised to use separate IPv4 pools for each of the different mechanisms to simplify planning and IPv4 routing.

したがって、オペレーターは、計画とIPv4ルーティングを簡素化するために、異なるメカニズムごとに個別のIPv4プールを使用することをお勧めします。

For IPv6 planning, there is less of a constraint as the BR/AFTR elements for the different mechanisms can contain configuration for overlapping the client's IPv6 addresses, provided that one mechanism is actively serving a given client at a time. However, the IPv6 address that is used as the tunnel concentrator's endpoint (BR/AFTR address) needs to be different for each mechanism to ensure correct operation.

IPv6の計画では、1つのメカニズムが一度に特定のクライアントにアクティブにサービスを提供している場合、異なるメカニズムのBR / AFTR要素にクライアントのIPv6アドレスをオーバーラップする構成を含めることができるため、制約は少なくなります。ただし、トンネルコンセントレータのエンドポイントとして使用されるIPv6アドレス（BR / AFTRアドレス）は、正しい動作を保証するためにメカニズムごとに異なる必要があります。

2.2. Backwards Compatability with Existing Softwire Clients

2.2. 既存のソフトウェアクライアントとの下位互換性

Deployed clients that can support multiple softwire mechanisms, but do not implement the prioritization mechanism described here may require additional planning. In this scenario, the CPE would request configuration for all of the supported softwire mechanisms in its DHCPv6 Option Request Option (ORO), but would not request OPTION_S46_PRIORITY. By default, the DHCPv6 server will respond with configuration for all of the requested mechanisms, which could result in unpredictable and unwanted client configuration.

複数のソフトワイヤーメカニズムをサポートできるが、ここで説明する優先順位付けメカニズムを実装していない展開済みクライアントは、追加の計画が必要になる場合があります。このシナリオでは、CPEはDHCPv6オプション要求オプション（ORO）でサポートされているすべてのソフトワイヤーメカニズムの構成を要求しますが、OPTION_S46_PRIORITYは要求しません。デフォルトでは、DHCPv6サーバーは要求されたすべてのメカニズムの構成で応答するため、予期しない望ましくないクライアント構成になる可能性があります。

In this scenario, it may be necessary for the operator to implement logic within the DHCPv6 server to identify such clients and only provision them with configuration for a single softwire mechanism. It should be noted that this can lead to complexity and reduced scalability in the DHCPv6 server implementation due to the additional DHCPv6 message processing overhead.

このシナリオでは、オペレーターがDHCPv6サーバー内にロジックを実装して、そのようなクライアントを識別し、単一のソフトワイヤーメカニズムの構成のみをプロビジョニングする必要がある場合があります。 DHCPv6メッセージ処理のオーバーヘッドが増えるため、DHCPv6サーバーの実装が複雑になり、スケーラビリティが低下する可能性があることに注意してください。

3. Security Considerations

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

Security considerations discussed in [RFC6334] and [RFC7598] apply for this document.

[RFC6334]および[RFC7598]で説明されているセキュリティの考慮事項がこのドキュメントに適用されます。

Misbehaving intermediate nodes may alter the content of the S46 Priority Option. This may lead to setting a different IPv4 service continuity mechanism than the one initially preferred by the network side. Also, a misbehaving node may alter the content of the S46 Priority Option and other DHCPv6 options (e.g., DHCPv6 Option 64 or 90) so that the traffic is intercepted by an illegitimate node. Those attacks are not unique to the S46 Priority Option but are applicable to any DHCPv6 option that can be altered by a misbehaving intermediate node.

中間ノードの動作を誤ると、S46優先オプションの内容が変更される場合があります。これにより、ネットワーク側で最初に優先されるメカニズムとは異なるIPv4サービス継続メカニズムが設定される可能性があります。また、ノードの動作が正しくない場合、S46 Priority Optionと他のDHCPv6オプション（DHCPv6 Option 64または90など）の内容が変更され、不正なノードによってトラフィックが傍受される可能性があります。これらの攻撃はS46優先度オプションに固有のものではありませんが、不正な中間ノードによって変更される可能性のあるDHCPv6オプションに適用できます。

4. IANA Considerations

4. IANAに関する考慮事項

IANA has allocated the following DHCPv6 option code:

IANAは、次のDHCPv6オプションコードを割り当てています。

111 OPTION_S46_PRIORITY

All values should be added to the DHCPv6 option code space defined in Section 24.3 of [RFC3315].

[RFC3315]のセクション24.3で定義されているDHCPv6オプションコードスペースにすべての値を追加する必要があります。

4.1. S46 Mechanisms and Their Identifying Option Codes

4.1. S46メカニズムとその識別オプションコード

IANA has created a new registry titled "Option Codes permitted in the S46 Priority Option". This registry enumerates the set of DHCPv6 option codes that can be included in the OPTION_S46_PRIORITY option. Options may be added to this list using the IETF Review process described in Section 4.1 of [RFC5226].

IANAは、「S46優先オプションで許可されているオプションコード」というタイトルの新しいレジストリを作成しました。このレジストリは、OPTION_S46_PRIORITYオプションに含めることができるDHCPv6オプションコードのセットを列挙します。 [RFC5226]のセクション4.1で説明されているIETFレビュープロセスを使用して、このリストにオプションを追加できます。

The following table shows the option codes that are currently defined and the S46 mechanisms that they represent. The contents of this table shows the format and the initial values for the new registry. Option codes that have not been requested to be added according to the stated procedure should not be mentioned at all in the table, and they should not be listed as "reserved" or "unassigned". The valid range of values for the registry is the range of DHCPv6 option codes (1-65535).

次の表は、現在定義されているオプションコードとそれらが表すS46メカニズムを示しています。この表の内容は、新しいレジストリの形式と初期値を示しています。記載された手順に従って追加するように要求されていないオプションコードは、表にまったく記載されるべきではなく、「予約済み」または「未割り当て」としてリストされるべきではありません。レジストリの有効な値の範囲は、DHCPv6オプションコードの範囲（1〜65535）です。

             +-------------+--------------------+-----------+
             | Option Code |   S46 Mechanism    | Reference |
             +-------------+--------------------+-----------+
             |      64     |      DS-Lite       | [RFC6334] |
             |      88     | DHCPv4 over DHCPv6 | [RFC7341] |
             |      94     |       MAP-E        | [RFC7598] |
             |      95     |       MAP-T        | [RFC7598] |
             |      96     | Lightweight 4over6 | [RFC7598] |
             +-------------+--------------------+-----------+

Table 1: DHCPv6 Option to S46 Mechanism Mappings

表1：DHCPv6オプションからS46メカニズムへのマッピング

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

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

[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.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。

[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, DOI 10.17487/RFC6334, August 2011, <http://www.rfc-editor.org/info/rfc6334>.

[RFC6334] Hankins、D。およびT. Mrugalski、「Dynamic Host Configuration Protocol for IPv6（DHCPv6）Option for Dual-Stack Lite」、RFC 6334、DOI 10.17487 / RFC6334、2011年8月、<http：//www.rfc- editor.org/info/rfc6334>。

[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, DOI 10.17487/RFC7341, August 2014, <http://www.rfc-editor.org/info/rfc7341>.

[RFC7341] Sun、Q.、Cui、Y.、Siodelski、M.、Krishnan、S.、I。Farrer、「DHCPv4-over-DHCPv6（DHCP 4o6）Transport」、RFC 7341、DOI 10.17487 / RFC7341、8月2014、<http://www.rfc-editor.org/info/rfc7341>。

[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, <http://www.rfc-editor.org/info/rfc7598>.

[RFC7598] Mrugalski、T.、Troan、O.、Farrer、I.、Perreault、S.、Dec、W.、Bao、C.、Yeh、L。、およびX. Deng、「DHCPv6オプションfor Softwireの構成Address and Port-Mapped Clients」、RFC 7598、DOI 10.17487 / RFC7598、2015年7月、<http://www.rfc-editor.org/info/rfc7598>。

5.2. Informative References

5.2. 参考引用

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.

[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、DOI 10.17487 / RFC6333、2011年8月、<http：/ /www.rfc-editor.org/info/rfc6333>。

[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <http://www.rfc-editor.org/info/rfc7596>.

[RFC7596] Cui、Y.、Sun、Q.、Boucadair、M.、Tsou、T.、Lee、Y.、I。Farrer、「Lightweight 4over6：An Extension to the Dual-Stack Lite Architecture」、RFC 7596 、DOI 10.17487 / RFC7596、2015年7月、<http://www.rfc-editor.org/info/rfc7596>。

[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <http://www.rfc-editor.org/info/rfc7597>.

[RFC7597] Troan、O.、Ed。、Dec、W.、Li、X.、Bao、C.、Matsushima、S.、Murakami、T.、and T. Taylor、Ed。、 "Mapping of Address and Portカプセル化あり（MAP-E）」、RFC 7597、DOI 10.17487 / RFC7597、2015年7月、<http://www.rfc-editor.org/info/rfc7597>。

[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, <http://www.rfc-editor.org/info/rfc7599>.

[RFC7599] Li、X.、Bao、C.、Dec、W.、Ed。、Troan、O.、Matsushima S.、T。Murakami、「変換を使用したアドレスとポートのマッピング（MAP-T）」、RFC 7599、DOI 10.17487 / RFC7599、2015年7月、<http://www.rfc-editor.org/info/rfc7599>。

Acknowledgements

謝辞

Many thanks to O. Troan, S. Barth, A. Yourtchenko, B. Volz, T. Mrugalski, J. Scudder, P. Kyzivat, F. Baker, and B. Campbell for their input and suggestions.

O. Troan、S。Barth、A。Yourtchenko、B。Volz、T。Mrugalski、J。Scudder、P。Kyzivat、F。Baker、B。Campbellの各氏の意見や提案に感謝します。

Authors' Addresses

著者のアドレス

Mohamed Boucadair Orange Rennes France

モハメドブーカデールオレンジレンヌフランス

   Email: mohamed.boucadair@orange.com

Ian Farrer Deutsche Telekom AG CTO-ATI, Landgrabenweg 151 Bonn, NRW 53227 Germany

Ian Farrer Deutsche Telekom AG CTO-ATI、Landgrabenweg 151 Bonn、NRW 53227 Germany

   Email: ian.farrer@telekom.de