[要約] RFC 8539は、DHCPv6を使用してDHCPv4を介したソフトワイヤプロビジョニングを実現するための仕様です。目的は、IPv6ネットワーク上でIPv4サービスを提供するための効果的な方法を提供することです。
Internet Engineering Task Force (IETF) I. Farrer
Request for Comments: 8539 Deutsche Telekom AG
Updates: 7598 Q. Sun
Category: Standards Track Y. Cui
ISSN: 2070-1721 L. Sun
Tsinghua University
March 2019
Softwire Provisioning Using DHCPv4 over DHCPv6
DHCPv6 over DHCPv4を使用したSoftwireプロビジョニング
Abstract
概要
DHCPv4 over DHCPv6 (RFC 7341) is a mechanism for dynamically configuring IPv4 for use as an over-the-top service in an IPv6-only network. Softwires are an example of such a service. For DHCPv4 over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios (e.g., RFC 7596 or RFC 7597), the operator needs to know the IPv6 address that the client will use as the source of an IPv4-in-IPv6 softwire tunnel. This address, in conjunction with the client's IPv4 address, and (in some deployments) the Port Set ID are used to create a binding table entry in the operator's softwire tunnel concentrator. This memo defines a DHCPv6 option to convey IPv6 parameters for establishing the softwire tunnel and a DHCPv4 option (to be used only with DHCP 4o6) to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It is designed to work in conjunction with the IPv4 address allocation process.
DHCPv4 over DHCPv6（RFC 7341）は、IPv6のみのネットワークでオーバーザトップサービスとして使用するIPv4を動的に構成するためのメカニズムです。ソフトワイヤーはそのようなサービスの一例です。 DHCPv4 over DHCPv6（DHCP 4o6）が一部のIPv4-over-IPv6ソフトワイヤーメカニズムおよび展開シナリオ（たとえば、RFC 7596またはRFC 7597）で機能するためには、オペレーターはクライアントがクライアントのソースとして使用するIPv6アドレスを知っている必要があります。 IPv4-in-IPv6ソフトワイヤートンネル。このアドレスは、クライアントのIPv4アドレスと組み合わせて（一部の展開では）、ポートセットIDを使用して、オペレーターのソフトワイヤートンネルコンセントレーターにバインディングテーブルエントリを作成します。このメモは、ソフトワイヤートンネルを確立するためのIPv6パラメーターを伝達するDHCPv6オプションと、DHCP 4o6クライアントとサーバーの間でソーストンネルIPv6アドレスを通信するDHCPv4オプション（DHCP 4o6でのみ使用）を定義します。 IPv4アドレス割り当てプロセスと連動するように設計されています。
"DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients" (RFC 7598) describes a deterministic DHCPv6-based mechanism for provisioning softwires. This document updates RFC 7598, allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6 client's Option Request Option (ORO) request and to appear directly within subsequent messages sent by the DHCPv6 server.
「Softwireアドレスおよびポートマップクライアントの構成のためのDHCPv6オプション」（RFC 7598）では、ソフトワイヤーをプロビジョニングするための確定的なDHCPv6ベースのメカニズムについて説明しています。このドキュメントはRFC 7598を更新し、OPTION_S46_BR（90）をDHCPv6クライアントのオプション要求オプション（ORO）要求で列挙し、DHCPv6サーバーが送信する後続のメッセージ内に直接表示できるようにします。
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 https://www.rfc-editor.org/info/rfc8539.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8539で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Updating RFC 7598 to Permit the Reuse of
OPTION_S46_BR (90) . . . . . . . . . . . . . . . . . . . 5
5. DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . . 6
6. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. DHCPv6 Softwire Source Binding Prefix Hint Option . . . . 7
6.2. DHCP 4o6 Softwire Source Address Option . . . . . . . . . 8
7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Client Initialization . . . . . . . . . . . . . . . . . . 9
7.2. Renewing or Rebinding the IPv4 Address Lease and
Softwire Source Address . . . . . . . . . . . . . . . . . 10
7.2.1. Changing the Bound IPv6 Softwire Source Address . . . 10
7.3. Releasing the IPv4 Address Lease and Softwire
Source Address . . . . . . . . . . . . . . . . . . . . . 11
7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . . . . 11
7.5. Client and Server Softwire Source Address Mismatch . . . 11
7.6. Use with Dynamic, Shared IPv4 Addresses . . . . . . . . . 12
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Changing the Bound IPv6 Source Address . . . . . . . . . 12
8.2. Handling Conflicts between Clients' Bound IPv6 Source
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1. Client Privacy Considerations . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Deterministic IPv4-over-IPv6 transition technologies require that elements be preconfigured with binding rules for routing traffic to clients. This places a constraint on the choice of address used as the client's softwire source address: it must use a predetermined prefix, which is usually configured on the home gateway device. [RFC7598] describes a DHCPv6-based mechanism for provisioning such deterministic softwires.
確定的IPv4-over-IPv6移行テクノロジーでは、トラフィックをクライアントにルーティングするためのバインディングルールを使用して要素を事前に構成する必要があります。これは、クライアントのソフトワイヤー送信元アドレスとして使用されるアドレスの選択に制約を課します。これは、事前に定義されたプレフィックスを使用する必要があります。これは通常、ホームゲートウェイデバイスで構成されます。 [RFC7598]は、このような確定的なソフトワイヤーをプロビジョニングするためのDHCPv6ベースのメカニズムについて説明しています。
A dynamic provisioning model, such as using DHCPv4 over DHCPv6 (DHCP 4o6) [RFC7341], allows much more flexibility in the location of the IPv4-over-IPv6 softwire source address. In this model, the IPv6 address is dynamically communicated back to the service provider, allowing the corresponding softwire configuration to be created in the border relay (BR).
DHCPv4 over DHCPv6（DHCP 4o6）[RFC7341]を使用するなどの動的プロビジョニングモデルでは、IPv4-over-IPv6ソフトワイヤー送信元アドレスの場所の柔軟性が大幅に向上します。このモデルでは、IPv6アドレスがサービスプロバイダーに動的に通信されるため、対応するソフトワイヤー構成を境界リレー（BR）で作成できます。
The DHCP 4o6 client and softwire client could be run on end devices attached to a network segment using any routable IPv6 prefix allocated to an end user, located anywhere within an arbitrary home network topology. Dynamic allocation also helps to optimize IPv4 resource usage, because only clients that are actively renewing their IPv4 lease hold on to the address.
DHCP 4o6クライアントおよびソフトワイヤークライアントは、任意のホームネットワークトポロジ内の任意の場所にあるエンドユーザーに割り当てられたルーティング可能なIPv6プレフィックスを使用して、ネットワークセグメントに接続されたエンドデバイスで実行できます。動的割り当ては、IPv4リースをアクティブに更新しているクライアントのみがアドレスを保持するため、IPv4リソースの使用を最適化するのにも役立ちます。
This document describes a mechanism for dynamically provisioning softwires created using DHCP 4o6, including provisioning the client with the address of the softwire BR and informing the service provider of a client's binding between the dynamically allocated IPv4 address and Port Set ID and the IPv6 address that the softwire initiator will use for accessing IPv4-over-IPv6 services.
このドキュメントでは、DHCP 4o6を使用して作成されたソフトワイヤーを動的にプロビジョニングするメカニズムについて説明します。これには、ソフトワイヤーBRのアドレスをクライアントにプロビジョニングし、動的に割り当てられたIPv4アドレスとポートセットIDとIPv6アドレスの間のクライアントのバインディングをサービスプロバイダーに通知します。ソフトワイヤイニシエータは、IPv4-over-IPv6サービスへのアクセスに使用します。
The mechanism operates alongside the DHCP 4o6 message flows to communicate the binding information over the IPv6-only network. The DHCP 4o6 server provides a single point in the network that holds the current client binding information. The service provider can then use this binding information to provision other functional elements, such as the BR(s).
このメカニズムは、DHCP 4o6メッセージフローと連携して動作し、IPv6のみのネットワークを介してバインディング情報を伝達します。 DHCP 4o6サーバーは、現在のクライアントバインディング情報を保持するネットワーク内の単一のポイントを提供します。サービスプロバイダーは、このバインディング情報を使用して、BRなどの他の機能要素をプロビジョニングできます。
The mechanism described in this document is only suitable for use for provisioning softwire clients via DHCP 4o6. The options described here are only applicable within the DHCP 4o6 message-exchange process. Current softwire technologies suitable for extending to incorporate DHCP 4o6 with dynamic IPv4 address leasing include [RFC7597] and [RFC7596].
このドキュメントで説明されているメカニズムは、DHCP 4o6を介してソフトワイヤークライアントをプロビジョニングする場合にのみ適しています。ここで説明するオプションは、DHCP 4o6メッセージ交換プロセス内でのみ適用されます。 DHCP 4o6と動的IPv4アドレスリースを組み込むために拡張するのに適した現在のソフトワイヤー技術には、[RFC7597]と[RFC7596]があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
In order to provision a softwire, both IPv6 and IPv4 configurations need to be passed to the client. To map this to the DHCP 4o6 configuration process, the IPv6 configuration is carried in DHCPv6 options [RFC8415], carried inside the DHCPv6 message DHCPV4-RESPONSE (21) sent by the server. OPTION_S46_BR (90) is used to provision the remote IPv6 address for the softwire BR (see Section 4.1). OPTION_S46_BIND_IPV6_PREFIX (137) is optionally sent by the DHCP 4o6 server to indicate to the client a preferred IPv6 prefix for binding the received IPv4 configuration and sourcing tunnel traffic. This may be necessary if there are multiple IPv6 prefixes in use in the customer network (e.g., Unique Local Addresses (ULAs)) or if the specific IPv4-over-IPv6 transition mechanism requires the use of a particular prefix for any reason.
ソフトワイヤーをプロビジョニングするには、IPv6とIPv4の両方の構成をクライアントに渡す必要があります。これをDHCP 4o6構成プロセスにマップするために、IPv6構成はDHCPv6オプション[RFC8415]で伝達され、サーバーによって送信されたDHCPv6メッセージDHCPV4-RESPONSE（21）内で伝達されます。 OPTION_S46_BR（90）は、ソフトワイヤーBRのリモートIPv6アドレスをプロビジョニングするために使用されます（セクション4.1を参照）。 OPTION_S46_BIND_IPV6_PREFIX（137）はオプションでDHCP 4o6サーバーから送信され、受信したIPv4構成をバインドしてトンネルトラフィックを送信するための優先IPv6プレフィックスをクライアントに示します。これは、お客様のネットワークで複数のIPv6プレフィックスが使用されている場合（たとえば、一意のローカルアドレス（ULA））、または特定のIPv4-over-IPv6移行メカニズムが何らかの理由で特定のプレフィックスの使用を必要とする場合に必要になることがあります。
IPv4 configuration is carried in DHCPv4 messages [RFC2131] (inside the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism described in [RFC7341].
IPv4設定は、[RFC7341]で説明されているメカニズムを使用して、DHCPv4メッセージ[RFC2131]（DHCP 4o6オプションOPTION_DHCPV4_MSG（87）内）で伝達されます。
In order for the client to communicate the softwire source address, a new DHCPv4 option OPTION_DHCP4O6_S46_SADDR (109) is defined in this document. This is included in DHCPREQUEST messages sent by the client and is stored by the server for the lifetime of the IPv4 address lease.
クライアントがソフトワイヤー送信元アドレスを通信するために、新しいDHCPv4オプションOPTION_DHCP4O6_S46_SADDR（109）がこのドキュメントで定義されています。これは、クライアントによって送信されるDHCPREQUESTメッセージに含まれ、IPv4アドレスリースの有効期間中、サーバーによって格納されます。
Section 4.2 of [RFC7598] defines option OPTION_S46_BR (90) for communicating remote softwire BR IPv6 address(es) to a client, but it mandates that the option can only be used when encapsulated within one of the softwire container options: OPTION_S46_CONT_MAPE (94) or OPTION_S46_CONT_LW (96). From Section 3 of [RFC7598]:
[RFC7598]のセクション4.2は、リモートソフトワイヤーBR IPv6アドレスをクライアントに通信するためのオプションOPTION_S46_BR（90）を定義していますが、オプションは、ソフトワイヤーコンテナーオプションの1つにカプセル化されている場合にのみ使用できることを義務付けています：OPTION_S46_CONT_MAPE（94）またはOPTION_S46_CONT_LW（96）。 [RFC7598]のセクション3から：
Softwire46 DHCPv6 clients that receive provisioning options that are not encapsulated in container options MUST silently ignore these options.
コンテナーオプションにカプセル化されていないプロビジョニングオプションを受信するSoftwire46 DHCPv6クライアントは、これらのオプションを暗黙的に無視する必要があります。
This document updates [RFC7598], removing this restriction for OPTION_S46_BR (90), allowing it to be enumerated in the client's ORO request and appear directly within subsequent messages sent by the DHCPv6 server.
このドキュメントは[RFC7598]を更新し、OPTION_S46_BR（90）のこの制限を削除して、クライアントのORO要求で列挙され、DHCPv6サーバーによって送信される後続のメッセージ内に直接表示されるようにします。
Figure 1 shows the relevant extensions to the successful DHCP 4o6 IPv4 allocation client/server message flow for the softwire source address function. The full process, including error handling, is described in Section 7.
図1は、ソフトワイヤー送信元アドレス機能で成功したDHCP 4o6 IPv4割り当てクライアント/サーバーメッセージフローの関連拡張を示しています。エラー処理を含む完全なプロセスについては、セクション7で説明します。
In each step, the DHCPv6 portion of the message and any relevant option is shown above the arrow. The DHCP 4o6 content of the message and its relevant options are below the arrow. All the DHCPv4 messages are encapsulated in DHCPV4-QUERY (20) or DHCPV4-RESPONSE (21) messages. Where relevant, the necessary options and their contents are shown.
各ステップで、メッセージのDHCPv6部分と関連オプションが矢印の上に表示されます。メッセージのDHCP 4o6コンテンツとその関連オプションは、矢印の下にあります。すべてのDHCPv4メッセージは、DHCPV4-QUERY（20）またはDHCPV4-RESPONSE（21）メッセージにカプセル化されます。必要に応じて、必要なオプションとその内容が表示されます。
DHCP 4o6 DHCP 4o6
Client Server
| |
| DHCPv6 - DHCPV4-QUERY message containing |
| OPTION_ORO (6) listing (90, 137) |
Step 1 |----------------------------------------------------->|
| DHCPv4 - DHCPDISCOVER message |
| |
| |
| DHCPv6 - DHCPV4-RESPONSE message containing |
| OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(137) |
| (bind-ipv6-prefix with service provider's |
| preferred prefix) |
Step 2 |<-----------------------------------------------------|
| DHCPv4 - DHCPOFFER message |
| containing an available IPv4 address |
| |
| DHCPv6 - DHCPV4-QUERY message |
Step 3 |----------------------------------------------------->|
| DHCPv4 - DHCPREQUEST message containing the |
| requested IPv4 address and OPTION_DHCP4O6_S46_SADDR |
| (softwire-ipv6-src-address with client's bound |
| IPv6 softwire source address) |
| |
| |
| DHCPv6 - DHCPV4-RESPONSE message |
Step 4 |<-----------------------------------------------------|
| DHCPv4 - DHCPACK message containing |
| the leased IPv4 address and OPTION_DHCP4O6_S46_SADDR |
| (softwire-ipv6-src-address with client's bound |
| IPv6 softwire source address) |
| |
Figure 1: IPv6/IPv4 Binding Message Flow
図1：IPv6 / IPv4バインディングメッセージフロー
Step 1 The client constructs a DHCPv6 "DHCPV4-QUERY (20)" message. This message contains two options: DHCPv6 OPTION_ORO (6) and OPTION_DHCPV4_MSG (87). OPTION_ORO lists "90" (OPTION_S46_BR) and "137" (OPTION_S46_BIND_IPV6_PREFIX). OPTION_DHCPV4_MSG contains a DHCPv4 DHCPDISCOVER message.
ステップ1クライアントはDHCPv6 "DHCPV4-QUERY（20）"メッセージを作成します。このメッセージには、DHCPv6 OPTION_ORO（6）およびOPTION_DHCPV4_MSG（87）の2つのオプションが含まれています。 OPTION_OROは "90"（OPTION_S46_BR）および "137"（OPTION_S46_BIND_IPV6_PREFIX）をリストします。 OPTION_DHCPV4_MSGには、DHCPv4 DHCPDISCOVERメッセージが含まれています。
Step 2 The server responds with a DHCPv6 "DHCPV4-RESPONSE (21)" message. This message contains an OPTION_S46_BR (90) containing the IPv6 address of the BR for the client's softwire configuration. The message may also optionally contain OPTION_S46_BIND_IPV6_PREFIX (137). OPTION_DHCPV4_MSG contains a DHCPv4 DHCPOFFER message. The DHCPv4 message contains an available IPv4 address.
ステップ2サーバーはDHCPv6 "DHCPV4-RESPONSE（21）"メッセージで応答します。このメッセージには、クライアントのソフトワイヤー構成のBRのIPv6アドレスを含むOPTION_S46_BR（90）が含まれています。メッセージには、オプションでOPTION_S46_BIND_IPV6_PREFIX（137）を含めることもできます。 OPTION_DHCPV4_MSGには、DHCPv4 DHCPOFFERメッセージが含まれています。 DHCPv4メッセージには、使用可能なIPv4アドレスが含まれています。
Step 3 The client sends a DHCPv6 "DHCPV4-QUERY (20)" message containing a DHCPv4 DHCPREQUEST message with the requested IPv4 address and OPTION_DHCP4O6_S46_SADDR (109) with the IPv6 address that the client will use as its softwire source address.
ステップ3クライアントは、要求されたIPv4アドレスを含むDHCPv4 DHCPREQUESTメッセージと、クライアントがそのソフトワイヤソースアドレスとして使用するIPv6アドレスを含むOPTION_DHCP4O6_S46_SADDR（109）を含むDHCPv6 "DHCPV4-QUERY（20）"メッセージを送信します。
Step 4 The server sends a DHCPv6 "DHCPV4-RESPONSE (21)" message. OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message with the allocated IPv4 address. OPTION_DHCP4O6_S46_SADDR with the client's bound softwire source address is included.
ステップ4サーバーはDHCPv6 "DHCPV4-RESPONSE（21）"メッセージを送信します。 OPTION_DHCPV4_MSGには、IPv4アドレスが割り当てられたDHCPv4 DHCPACKメッセージが含まれています。 OPTION_DHCP4O6_S46_SADDRには、クライアントのバインドされたソフトワイヤー送信元アドレスが含まれています。
The format of the DHCPv6 source binding prefix hint option is as follows:
DHCPv6ソースバインディングプレフィックスヒントオプションの形式は次のとおりです。
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_BIND_IPV6_PREFIX | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|bindprefix6-len| |
+-+-+-+-+-+-+-+-+ bind-ipv6-prefix .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of OPTION_S46_BIND_IPV6_PREFIX
図2：OPTION_S46_BIND_IPV6_PREFIXのフォーマット
o option-code: OPTION_S46_BIND_IPV6_PREFIX (137)
o オプションコード：OPTION_S46_BIND_IPV6_PREFIX（137）
o option-length: 1 + length of bind-ipv6-prefix, specified in bytes.
o option-length：1 + bind-ipv6-prefixの長さ（バイト単位で指定）。
o bindprefix6-len: 8-bit field expressing the bit mask length of the IPv6 prefix specified in bind-ipv6-prefix. Valid values are 0 to 128.
o bindprefix6-len：bind-ipv6-prefixで指定されたIPv6プレフィックスのビットマスク長を表す8ビットのフィールド。有効な値は0〜128です。
o bind-ipv6-prefix: The IPv6 prefix indicating the preferred prefix for the client to bind the received IPv4 configuration to. The length is (bindprefix6-len + 7) / 8. The field is padded on the right with zero bits up to the next octet boundary when bind-ipv6-prefix is not evenly divisible by 8. These padding bits are ignored by the receiver (see Section 7.4).
o bind-ipv6-prefix：受信したIPv4構成をバインドするクライアントの優先プレフィックスを示すIPv6プレフィックス。長さは（bindprefix6-len + 7）/ 8です。bind-ipv6-prefixが8で割り切れない場合、フィールドの右側には次のオクテット境界までゼロビットが埋め込まれます。これらのパディングビットはレシーバーによって無視されます（セクション7.4を参照）。
OPTION_S46_BIND_IPV6_PREFIX is a singleton. Servers MUST NOT send more than one instance of the OPTION_S46_BIND_IPV6_PREFIX option.
OPTION_S46_BIND_IPV6_PREFIXはシングルトンです。サーバーは、OPTION_S46_BIND_IPV6_PREFIXオプションの複数のインスタンスを送信してはなりません（MUST NOT）。
The format of the DHCPv4 over DHCPv6 softwire source address option is as follows:
DHCPv4 over DHCPv6ソフトワイヤ送信元アドレスオプションの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| option-code | option-length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ softwire-ipv6-src-address +
. (128 bits) .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: Format of OPTION_DHCP4O6_S46_SADDR
図3：OPTION_DHCP4O6_S46_SADDRのフォーマット
o option-code: OPTION_DHCP4O6_S46_SADDR (109)
o オプションコード：OPTION_DHCP4O6_S46_SADDR（109）
o option-length: 16.
o オプションの長さ：16。
o softwire-ipv6-src-address: 16 bytes long; the IPv6 address that is associated (either being requested for binding or currently bound) with the client's IPv4 configuration.
o softwire-ipv6-src-address：16バイト長。クライアントのIPv4構成に関連付けられている（バインドが要求されているか、現在バインドされている）IPv6アドレス。
Note: The function of OPTION_DHCP4O6_S46_SADDR may seem similar to the DHCPv4 message's "chaddr" field or the Client Identifier (61) option in that it provides a unique lower-layer address that the server can use for identifying the client. However, as both of these are required to remain constant throughout the address lease lifetime, they cannot be used with the mechanism described in this document. This is because the client may only be able to construct the IPv6 address to use as the source address after it has received the first DHCPV4-RESPONSE message from the server containing OPTION_S46_BIND_IPV6_PREFIX.
注：OPTION_DHCP4O6_S46_SADDRの機能は、サーバーがクライアントの識別に使用できる一意の下位層アドレスを提供するという点で、DHCPv4メッセージの「chaddr」フィールドまたはクライアント識別子（61）オプションに似ているように見える場合があります。ただし、これらは両方ともアドレスリースのライフタイムを通じて一定である必要があるため、このドキュメントで説明されているメカニズムでは使用できません。これは、クライアントが、OPTION_S46_BIND_IPV6_PREFIXを含むサーバーから最初のDHCPV4-RESPONSEメッセージを受信した後でのみ、ソースアドレスとして使用するIPv6アドレスを構築できる可能性があるためです。
A client requiring dynamic softwire configuration first enables DHCP 4o6 configuration using the method described in Section 5 of [RFC7341]. If OPTION_DHCP4_O_DHCP6_SERVER is received in the corresponding REPLY message, the client MAY continue with the configuration process described below.
動的なソフトワイヤー構成を必要とするクライアントは、最初に[RFC7341]のセクション5で説明されている方法を使用してDHCP 4o6構成を有効にします。 OPTION_DHCP4_O_DHCP6_SERVERが対応するREPLYメッセージで受信された場合、クライアントは、以下で説明する構成プロセスを続行できます（MAY）。
Before the dynamic softwire configuration process can commence, the client MUST be configured with a suitable IPv6 prefix to be used as the local softwire endpoint. This could be obtained using DHCPv6, Router Advertisement (RA) / Prefix Information Option (PIO), or another mechanism.
ダイナミックソフトワイヤー構成プロセスを開始する前に、ローカルソフトワイヤーエンドポイントとして使用する適切なIPv6プレフィックスを使用してクライアントを構成する必要があります。これは、DHCPv6、ルーターアドバタイズ（RA）/プレフィックス情報オプション（PIO）、または別のメカニズムを使用して取得できます。
When constructing the initial DHCP 4o6 DHCPDISCOVER message, the client includes a DHCPv6 OPTION_ORO (6) within the options field of the DHCP-QUERY message. OPTION_ORO contains the option codes for OPTION_S46_BR (90) and OPTION_S46_BIND_IPV6_PREFIX (137).
最初のDHCP 4o6 DHCPDISCOVERメッセージを作成するとき、クライアントはDHCP-QUERYメッセージのオプションフィールド内にDHCPv6 OPTION_ORO（6）を含めます。 OPTION_OROには、OPTION_S46_BR（90）およびOPTION_S46_BIND_IPV6_PREFIX（137）のオプションコードが含まれています。
On receipt of the DHCP 4o6 server's reply (a DHCPV4-RESPONSE containing a DHCPOFFER message), the client checks the contents of the DHCPv4-RESPONSE for the presence of a valid OPTION_S46_BR option. If this option is not present, or does not contain at least one valid IPv6 address for a BR, then the client MUST discard the message, as without the address of the BR the client cannot configure the softwire and so has no interface to request IPv4 configuration for.
DHCP 4o6サーバーの応答（DHCPOFFERメッセージを含むDHCPV4-RESPONSE）を受信すると、クライアントはDHCPv4-RESPONSEの内容をチェックして、有効なOPTION_S46_BRオプションが存在するかどうかを確認します。このオプションが存在しない場合、またはBRの有効なIPv6アドレスが1つも含まれていない場合、クライアントはメッセージを破棄する必要があります。BRのアドレスがないと、クライアントはソフトワイヤーを構成できず、IPv4を要求するインターフェイスがないためです。構成。
The DHCPV4-RESPONSE message may also include OPTION_S46_BIND_IPV6_PREFIX, which is used by the operator to indicate a preferred prefix that the client should bind IPv4 configuration to. If received, the client first checks the option according to Section 7.4. If valid, the client uses this prefix as the "IPv6 binding prefix" and follows to the process described in Section 5.1 of [RFC7596] in order to select an active IPv6 prefix to construct the softwire. If no match is found, or the client doesn't receive OPTION_S46_BIND_IPV6_PREFIX, the client MAY select any valid IPv6 prefix (of a suitable scope) to use as the tunnel source.
DHCPV4-RESPONSEメッセージには、OPTION_S46_BIND_IPV6_PREFIXも含まれる場合があります。これは、クライアントがIPv4構成をバインドする必要のある優先プレフィックスを示すためにオペレーターによって使用されます。受け取った場合、クライアントは最初にセクション7.4に従ってオプションをチェックします。有効な場合、クライアントはこのプレフィックスを「IPv6バインディングプレフィックス」として使用し、[RFC7596]のセクション5.1で説明されているプロセスに従って、アクティブなIPv6プレフィックスを選択してソフトワイヤーを構築します。一致が見つからない場合、またはクライアントがOPTION_S46_BIND_IPV6_PREFIXを受信しない場合、クライアントは（適切なスコープの）有効なIPv6プレフィックスを選択してトンネルソースとして使用できます（MAY）。
Once the client has selected a suitable prefix, it MAY either use an existing IPv6 address that is already configured on an interface or create a new address specifically for use as the softwire source address (e.g., using an Interface Identifier constructed as per Section 6 of [RFC7597]). If a new address is being created, the client MUST complete configuration of the new address, performing duplicate address detection (if required) before proceeding.
クライアントが適切なプレフィックスを選択すると、インターフェースに既に構成されている既存のIPv6アドレスを使用するか、ソフトワイヤーの送信元アドレスとして使用するための新しいアドレスを作成することができます（たとえば、 [RFC7597]）。新しいアドレスが作成されている場合、クライアントは新しいアドレスの構成を完了し、続行する前に（必要な場合）重複アドレス検出を実行する必要があります。
The client then constructs a DHCPV4-QUERY message containing a DHCPv4 DHCPREQUEST message. OPTION_DHCP4O6_S46_SADDR is included in the options field of the DHCPREQUEST message with the IPv6 address of its softwire source address in the softwire-ipv6-src-address field.
次に、クライアントはDHCPv4 DHCPREQUESTメッセージを含むDHCPV4-QUERYメッセージを作成します。 OPTION_DHCP4O6_S46_SADDRは、DHCPREQUESTメッセージのオプションフィールドに含まれ、softwire-ipv6-src-addressフィールドにそのソフトワイヤー送信元アドレスのIPv6アドレスが含まれます。
When the client receives a DHCPv4 DHCPACK message from the server, it checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its active softwire source address. If they match, the allocation process has concluded. If there is a discrepancy, then the process described in Section 7.5 is followed.
クライアントはサーバーからDHCPv4 DHCPACKメッセージを受信すると、OPTION_DHCP4O6_S46_SADDRのIPv6アドレスをアクティブなソフトワイヤー送信元アドレスと照合します。それらが一致する場合、割り当てプロセスは終了しています。不一致がある場合は、セクション7.5で説明されているプロセスに従います。
If the client receives a DHCPv4 DHCPNAK message from the server, then the configuration process has been unsuccessful. The client then restarts the process from Step 1 of Figure 1.
クライアントがサーバーからDHCPv4 DHCPNAKメッセージを受信した場合、構成プロセスは失敗しています。その後、クライアントは図1のステップ1からプロセスを再開します。
7.2. Renewing or Rebinding the IPv4 Address Lease and Softwire Source Address
7.2. IPv4アドレスリースとSoftwire送信元アドレスの更新または再バインド
Whenever the client attempts to extend the lease time of the IPv4 address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its softwire source address in the softwire-ipv6-src-address field MUST be included in the DHCPREQUEST message.
クライアントがIPv4アドレスのリース時間を延長しようとするときはいつでも、softwire-ipv6-src-addressフィールドにソフトワイヤー送信元アドレスのIPv6アドレスを含むOPTION_DHCP4O6_S46_SADDRがDHCPREQUESTメッセージに含まれている必要があります。
Across the lifetime of the leased IPv4 address, it is possible that the client's IPv6 address will change, e.g., if there is an IPv6 renumbering event.
リースされたIPv4アドレスの有効期間全体で、たとえばIPv6再番号付けイベントが発生した場合など、クライアントのIPv6アドレスが変更される可能性があります。
In this situation, the client MUST inform the server of the new address. This is done by sending a DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address.
この状況では、クライアントはサーバーに新しいアドレスを通知する必要があります。これは、OPTION_DHCP4O6_S46_SADDRを含むDHCPREQUESTメッセージを新しいIPv6送信元アドレスと共に送信することによって行われます。
When the client receives a DHCPv4 DHCPACK message from the server, it checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its active softwire source address. If they match, the allocation process has concluded. If there is a discrepancy, then the process described in Section 7.5 is followed.
クライアントはサーバーからDHCPv4 DHCPACKメッセージを受信すると、OPTION_DHCP4O6_S46_SADDRのIPv6アドレスをアクティブなソフトワイヤー送信元アドレスと照合します。それらが一致する場合、割り当てプロセスは終了しています。不一致がある場合は、セクション7.5で説明されているプロセスに従います。
If the client receives a DHCPv4 DHCPNAK message in response from the server, then the change of the bound IPv6 softwire source address has been unsuccessful. In this case, the client MUST stop using the new IPv6 source address. The client then restarts the process from Step 1 of Figure 1.
クライアントがサーバーからの応答としてDHCPv4 DHCPNAKメッセージを受信した場合、バインドされたIPv6ソフトワイヤー送信元アドレスの変更は失敗しています。この場合、クライアントは新しいIPv6送信元アドレスの使用を停止する必要があります。その後、クライアントは図1のステップ1からプロセスを再開します。
When the client no longer requires the IPv4 resource, it sends a DHCPv4 DHCPRELEASE message to the server. As the options field is unused in this message type, OPTION_DHCP4O6_S46_SADDR is not included.
クライアントがIPv4リソースを必要としなくなると、クライアントはDHCPv4 DHCPRELEASEメッセージをサーバーに送信します。このメッセージタイプではオプションフィールドが使用されていないため、OPTION_DHCP4O6_S46_SADDRは含まれていません。
On receipt of the OPTION_S46_BIND_IPV6_PREFIX option, the client makes the following validation checks:
OPTION_S46_BIND_IPV6_PREFIXオプションを受信すると、クライアントは次の検証チェックを行います。
o The received bindprefix6-len value is not larger than 128.
o 受信したbindprefix6-len値は128以下です。
o The number of bytes received in the bind-ipv6-prefix field is consistent with the received bindprefix6-len value (calculated as described in Section 6.1).
o bind-ipv6-prefixフィールドで受信したバイト数は、受信したbindprefix6-len値（6.1節で説明されているように計算）と一致しています。
If either check fails, the receiver discards the invalid option and proceeds to attempt configuration as if the option had not been received.
いずれかのチェックが失敗した場合、受信者は無効なオプションを破棄し、オプションが受信されなかったかのように構成を試みます。
The receiver MUST only use bits from the bind-ipv6-prefix field up to the value specified in the bindprefix6-len when performing the longest prefix match. bind-ipv6-prefix bits beyond this value MUST be ignored.
受信者は、最長のプレフィックス照合を実行するときに、bind-ipv6-prefixフィールドからbindprefix6-lenで指定された値までのビットのみを使用する必要があります。この値を超えるbind-ipv6-prefixビットは無視する必要があります。
If the client receives a DHCPACK message with an OPTION_DHCP4O6_S46_SADDR containing an IPv6 address that differs from its active softwire source address, the client SHOULD wait for a randomized time interval and then resend the DHCPREQUEST message with the correct softwire source address. Section 4.1 of [RFC2131] describes the retransmission backoff interval process.
クライアントが、アクティブなソフトワイヤー送信元アドレスとは異なるIPv6アドレスを含むOPTION_DHCP4O6_S46_SADDRを含むDHCPACKメッセージを受信した場合、クライアントはランダムな時間間隔を待ってから、正しいソフトワイヤー送信元アドレスでDHCPREQUESTメッセージを再送信する必要があります。 [RFC2131]のセクション4.1は、再送信バックオフ間隔プロセスについて説明しています。
The default minimum time for the client to attempt retransmission is 60 seconds. If, after this time has expired, the client has not received a DHCPACK message with the correct bound IPv6 address, client MAY send a DHCPRELEASE message and restart the process described in Section 7. The retry interval should be configurable and aligned with any server policy defining the minimum time interval for client address updates as described in Section 8.1.
クライアントが再送信を試行するデフォルトの最小時間は60秒です。この時間が経過した後、クライアントが正しいバインドされたIPv6アドレスを含むDHCPACKメッセージを受信しなかった場合、クライアントはDHCPRELEASEメッセージを送信し、セクション7で説明されているプロセスを再開することができます（MAY）。セクション8.1で説明されているクライアントアドレス更新の最小時間間隔の定義。
[RFC7618] describes a mechanism for using DHCPv4 to distribute dynamic, shared IPv4 addresses to clients. The mechanism described in this document is compatible with IPv4 address sharing and can be enabled by following the process described in Section 6 of [RFC7618].
[RFC7618]は、DHCPv4を使用して動的な共有IPv4アドレスをクライアントに配布するメカニズムについて説明しています。このドキュメントで説明されているメカニズムはIPv4アドレス共有と互換性があり、[RFC7618]のセクション6で説明されているプロセスに従って有効にすることができます。
Beyond the normal DHCP 4o6 functionality defined in [RFC7341], the server MUST also store the IPv6 softwire source address of the client in the leasing address database, alongside the IPv4 address and client identifier.
[RFC7341]で定義されている通常のDHCP 4o6機能に加えて、サーバーはクライアントのIPv6ソフトワイヤー送信元アドレスをリースアドレスデータベースにIPv4アドレスとクライアント識別子と共に保存する必要があります（MUST）。
An OPTION_DHCP4O6_S46_SADDR containing the bound softwire source address MUST be sent in every DHCPACK message sent by the server.
バインドされたソフトワイヤー送信元アドレスを含むOPTION_DHCP4O6_S46_SADDRは、サーバーによって送信されるすべてのDHCPACKメッセージで送信される必要があります。
The binding entry between the client's IPv6 softwire source address and the leased IPv4 address is valid as long as the IPv4 lease remains valid.
クライアントのIPv6ソフトワイヤー送信元アドレスとリースされたIPv4アドレスの間のバインディングエントリは、IPv4リースが有効である限り有効です。
In the event that the server receives a DHCPREQUEST message for an active IPv4 lease containing an OPTION_DHCP4O6_S46_SADDR with an IPv6 address that differs from the address that is currently stored, the server updates the stored softwire source address with the new address supplied by the client and sends a DHCPACK message containing the updated softwire source address in OPTION_DHCP4O6_S46_SADDR.
サーバーが、現在格納されているアドレスとは異なるIPv6アドレスを持つOPTION_DHCP4O6_S46_SADDRを含むアクティブなIPv4リースのDHCPREQUESTメッセージを受信した場合、サーバーは、クライアントによって提供された新しいアドレスで格納されたソフトワイヤー送信元アドレスを更新し、送信しますOPTION_DHCP4O6_S46_SADDRの更新されたソフトワイヤー送信元アドレスを含むDHCPACKメッセージ。
The server MAY implement a policy enforcing a minimum time interval between a client updating its softwire source IPv6 address. If a client attempts to update the softwire source IPv6 address before the minimum time has expired, the server can either silently drop the client's message or send back a DHCPACK message containing the existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. If implemented, the default minimum client source address update interval is 60 seconds.
サーバーは、ソフトワイヤー送信元IPv6アドレスを更新するクライアント間の最小時間間隔を強制するポリシーを実装してもよい（MAY）。最小時間が経過する前にクライアントがソフトワイヤー送信元IPv6アドレスを更新しようとすると、サーバーはクライアントのメッセージを通知なしでドロップするか、OPTION_DHCP4O6_S46_SADDRに既存のIPv6アドレスバインディングを含むDHCPACKメッセージを返信します。実装されている場合、デフォルトの最小クライアント送信元アドレス更新間隔は60秒です。
In order for traffic to be forwarded correctly, each customer edge's (CE's) softwire IPv6 source address must be unique. To ensure this, on receipt of every client DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR, the DHCP 4o6 server MUST check the received IPv6 address against all existing CE source addresses stored for active client IPv4 leases. If there is a match for any active lease other than the lease belonging to the client sending the DHCPREQUEST, then the client's IPv6 source address MUST NOT be stored or updated.
トラフィックを正しく転送するには、各カスタマーエッジ（CE）のソフトワイヤーIPv6送信元アドレスが一意である必要があります。これを確実にするために、OPTION_DHCP4O6_S46_SADDRを含むすべてのクライアントDHCPREQUESTメッセージを受信すると、DHCP 4o6サーバーは、アクティブなクライアントIPv4リース用に保存されているすべての既存のCEソースアドレスに対して受信したIPv6アドレスをチェックする必要があります。 DHCPREQUESTを送信するクライアントに属するリース以外のアクティブなリースと一致する場合、クライアントのIPv6送信元アドレスを保存または更新してはなりません（MUST NOT）。
Depending on where the client and server are in the address leasing lifecycle, the DHCP 4o6 server then takes the following action:
クライアントとサーバーがアドレスリースライフサイクルのどこにあるかに応じて、DHCP 4o6サーバーは次のアクションを実行します。
o If the DHCP 4o6 does not have a current, active IPv4 address lease for the client, then the DHCP address allocation process has not been successful. The server returns a DHCPNAK message to the client.
o DHCP 4o6にクライアントの現在のアクティブなIPv4アドレスリースがない場合、DHCPアドレス割り当てプロセスは成功していません。サーバーはDHCPNAKメッセージをクライアントに返します。
o If the DHCP 4o6 does have a current, active IPv4 address lease, then the source address update process (see Section 8.1) has not been successful. The DHCP 4o6 server can either silently drop the client's message or return a DHCPACK message containing the existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR.
o DHCP 4o6に現在アクティブなIPv4アドレスリースがある場合、送信元アドレスの更新プロセス（セクション8.1を参照）は成功していません。 DHCP 4o6サーバーは、クライアントのメッセージを通知なしでドロップするか、OPTION_DHCP4O6_S46_SADDRに既存のIPv6アドレスバインディングを含むDHCPACKメッセージを返すことができます。
Security considerations that are applicable to [RFC7341] are also applicable here.
[RFC7341]に適用されるセキュリティの考慮事項は、ここにも適用されます。
A rogue client could attempt to use the mechanism described in Section 7.2.1 to redirect IPv4 traffic intended for another client to itself. This would be performed by sending a DHCPREQUEST message for another client's active IPv4 lease containing the attacker's softwire IPv6 address in OPTION_DHCP4O6_S46_SADDR.
不正クライアントは、セクション7.2.1で説明されているメカニズムを使用して、別のクライアント向けのIPv4トラフィックを自身にリダイレクトしようとする可能性があります。これは、OPTION_DHCP4O6_S46_SADDRに攻撃者のソフトワイヤーIPv6アドレスを含む別のクライアントのアクティブなIPv4リースのDHCPREQUESTメッセージを送信することで実行されます。
For such an attack to be effective, the attacker would need to know both the client identifier and the active IPv4 address lease currently in use by another client. This could be attempted in three ways:
このような攻撃を効果的にするには、攻撃者はクライアント識別子と、別のクライアントが現在使用しているアクティブなIPv4アドレスリースの両方を知っている必要があります。これは3つの方法で試行できます。
1. One customer learning the active IPv4 address lease and client identifier of another customer via snooping the DHCP4o6 message flow between the client and server. The mechanism described in this document is intended for use in a typical ISP network topology with a dedicated Layer 2 access network per client, meaning that snooping of another client's traffic is not possible. If the access network is a shared medium, then provisioning softwire clients using dynamic DHCP4o6 as described here is NOT RECOMMENDED.
1. ある顧客は、クライアントとサーバー間のDHCP4o6メッセージフローをスヌーピングして、別の顧客のアクティブなIPv4アドレスリースとクライアント識別子を学習します。このドキュメントで説明するメカニズムは、クライアントごとに専用のレイヤ2アクセスネットワークを備えた一般的なISPネットワークトポロジで使用することを目的としています。つまり、別のクライアントのトラフィックのスヌーピングは不可能です。アクセスネットワークが共有メディアの場合、ここで説明する動的DHCP4o6を使用したソフトワイヤークライアントのプロビジョニングは推奨されません。
2. Learning the active IPv4 address lease and client identifier via snooping the DHCP4o6 message flow between the client and server in the aggregation or core ISP network. In this case, the attacker requires a level of access to the ISP's infrastructure that means they can already intercept or interfere with traffic flows to the client.
2. 集約またはコアISPネットワーク内のクライアントとサーバー間のDHCP4o6メッセージフローをスヌーピングすることにより、アクティブなIPv4アドレスリースとクライアント識別子を学習します。この場合、攻撃者はISPのインフラストラクチャへのある程度のアクセスを必要とします。つまり、クライアントへのトラフィックフローをすでに傍受または妨害している可能性があります。
3. An attacker attempting to brute-force guess the IPv4 lease address and client identifier tuple. The risk of this can be reduced by using a client identifier format that is not easily guessable, e.g., by using a random-based client identifier (see Section 3.5 of [RFC7844]).
3. 総当たり攻撃を試みる攻撃者は、IPv4リースアドレスとクライアント識別子タプルを推測します。これのリスクは、ランダムベースのクライアント識別子を使用するなど、簡単に推測できないクライアント識別子形式を使用することで軽減できます（[RFC7844]のセクション3.5を参照）。
An attacker could attempt to redirect existing flows to a client unable to process the traffic. This type of attack can be prevented by implementing network ingress filtering [BCP38] in conjunction with the BR source address validation processes described in [RFC7596] Section 5.2 and [RFC7597] Section 8.1.
攻撃者は、トラフィックを処理できないクライアントに既存のフローをリダイレクトしようとする可能性があります。このタイプの攻撃は、[RFC7596]セクション5.2と[RFC7597]セクション8.1で説明されているBR送信元アドレス検証プロセスと組み合わせてネットワーク入力フィルタリング[BCP38]を実装することで防止できます。
A client may attempt to overload the server by sending multiple source address update messages (see Section 7.2.1) in a short time frame. This risk can be reduced by implementing a server policy enforcing a minimum time interval between client address changes, as described in Section 8.1.
クライアントは、短時間で複数の送信元アドレス更新メッセージ（セクション7.2.1を参照）を送信することにより、サーバーに過負荷をかけようとする場合があります。セクション8.1で説明されているように、クライアントアドレスの変更間の最小時間間隔を強制するサーバーポリシーを実装することにより、このリスクを軽減できます。
[RFC7844] describes anonymity profiles for DHCP clients. These considerations and recommendations are also applicable to clients implementing the mechanism described in this document. As DHCP 4o6 only uses DHCPv6 as a stateless transport for DHCPv4 messages, the "Anonymity Profile for DHCPv4" described in Section 3 is most relevant here.
[RFC7844]は、DHCPクライアントの匿名プロファイルについて説明しています。これらの考慮事項と推奨事項は、このドキュメントで説明されているメカニズムを実装するクライアントにも適用できます。 DHCP 4o6はDHCPv4メッセージのステートレストランスポートとしてDHCPv6のみを使用するため、セクション3で説明されている「DHCPv4の匿名プロファイル」がここで最も重要です。
In addition to the considerations given in [RFC7844], the mechanism that the client uses for constructing the interface identifier for its IPv6 softwire source address (see Section 7.1) could result in the device being trackable across different networks and sessions, e.g., if the client's softwire Interface Identifier (IID) is immutable.
[RFC7844]に記載されている考慮事項に加えて、クライアントがIPv6ソフトワイヤー送信元アドレスのインターフェース識別子を構築するために使用するメカニズム（セクション7.1を参照）は、デバイスが異なるネットワークやセッションにわたって追跡可能になる場合があります。クライアントのソフトワイヤーインターフェイス識別子（IID）は不変です。
This can be mitigated by constructing the softwire source IPv6 address as per Section 6 of [RFC7597]. Here, the address's IID contains only the allocated IPv4 address (and port set identifier if [RFC7618] is being used). This means no additional client information is exposed to the DHCP 4o6 server; it also means that the IID will change as the leased IPv4 address changes (e.g., between sessions when Section 3.5 of [RFC7844] is implemented).
これは、[RFC7597]のセクション6に従ってソフトワイヤー送信元IPv6アドレスを作成することで軽減できます。ここで、アドレスのIIDには、割り当てられたIPv4アドレス（および[RFC7618]が使用されている場合はポートセット識別子）のみが含まれています。これは、追加のクライアント情報がDHCP 4o6サーバーに公開されないことを意味します。また、リースされたIPv4アドレスが変更されると（たとえば、[RFC7844]のセクション3.5が実装されているセッション間で）、IIDが変更されることも意味します。
IANA has assigned the OPTION_S46_BIND_IPV6_PREFIX (137) option code from the DHCPv6 "Option Codes" registry maintained at <http://www.iana.org/assignments/dhcpv6-parameters> as follows:
IANAは、<http://www.iana.org/assignments/dhcpv6-parameters>で管理されているDHCPv6 "Option Codes"レジストリから、OPTION_S46_BIND_IPV6_PREFIX（137）オプションコードを次のように割り当てました。
Value: 137 Description: OPTION_S46_BIND_IPV6_PREFIX Client ORO: Yes Singleton Option: Yes Reference: RFC 8539
値：137説明：OPTION_S46_BIND_IPV6_PREFIXクライアントORO：はいシングルトンオプション：はいリファレンス：RFC 8539
IANA has assigned the OPTION_DHCP4O6_S46_SADDR (109) option code from the "BOOTP Vendor Extensions and DHCP Options" registry maintained at <http://www.iana.org/assignments/bootp-dhcp-parameters> as follows:
IANAは、<http://www.iana.org/assignments/bootp-dhcp-parameters>で管理されている "BOOTP Vendor Extensions and DHCP Options"レジストリから、OPTION_DHCP4O6_S46_SADDR（109）オプションコードを次のように割り当てました。
Tag: 109 Name: OPTION_DHCP4O6_S46_SADDR Data Length: 16 Meaning: DHCPv4 over DHCPv6 Softwire Source Address Option Reference: RFC 8539
タグ：109名前：OPTION_DHCP4O6_S46_SADDRデータ長：16意味：DHCPv6 over DHCPv6 Softwire送信元アドレスオプションリファレンス：RFC 8539
IANA has updated the entry for DHCPv6 OPTION_S46_BR (90) in the "Option Codes" registry maintained at <https://www.iana.org/assignments/dhcpv6-parameters> as follows:
IANAは、<https://www.iana.org/assignments/dhcpv6-parameters>で管理されている「オプションコード」レジストリのDHCPv6 OPTION_S46_BR（90）のエントリを次のように更新しました。
Old Entry:
古いエントリ：
Value: 90 Description: OPTION_S46_BR Client ORO: No Singleton Option: No Reference: [RFC7598]
値：90説明：OPTION_S46_BRクライアントORO：シングルトンオプションなし：リファレンスなし：[RFC7598]
New Entry:
新規エントリー：
Value: 90 Description: OPTION_S46_BR Client ORO: Yes Singleton Option: No Reference: [RFC7598], [RFC8539]
値：90説明：OPTION_S46_BRクライアントORO：はいシングルトンオプション：いいえ参照：[RFC7598]、[RFC8539]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https://www.rfc-editor.org/info/rfc2131>。
[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, <https://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、<https://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, <https://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月、<https://www.rfc-editor.org/info/rfc7598>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Siodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T。、およびT. Winters、「IPv6の動的ホスト構成プロトコル（DHCPv6）」、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https://www.rfc-editor.org/info/rfc8415>。
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000, <https://www.rfc-editor.org/info/bcp38>.
[BCP38]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを利用するサービス拒否攻撃の打破」、BCP 38、RFC 2827、2000年5月、<https：//www.rfc-editor。 org / info / bcp38>。
[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, <https://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月、<https://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, <https://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月、<https://www.rfc-editor.org/info/rfc7597>。
[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", RFC 7618, DOI 10.17487/RFC7618, August 2015, <https://www.rfc-editor.org/info/rfc7618>.
[RFC7618] Cui、Y.、Sun、Q.、Farrer、I.、Lee、Y.、Sun、Q。、およびM. Boucadair、「共有IPv4アドレスの動的割り当て」、RFC 7618、DOI 10.17487 / RFC7618、 2015年8月、<https://www.rfc-editor.org/info/rfc7618>。
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.
[RFC7844] Huitema、C.、Mrugalski、T。、およびS. Krishnan、「DHCPクライアントの匿名プロファイル」、RFC 7844、DOI 10.17487 / RFC7844、2016年5月、<https://www.rfc-editor.org/ info / rfc7844>。
Acknowledgements
謝辞
The authors would like to thank Ted Lemon, Lishan Li, Tatuya Jinmei, Jonas Gorski, and Razvan Becheriu for their contributions and comments.
著者は、Ted Lemon、Lishan Li、Tatuya Jinmei、Jonas Gorski、Razvan Becheriuの貢献とコメントに感謝します。
Authors' Addresses
著者のアドレス
Ian Farrer Deutsche Telekom AG Landgrabenweg 151 Bonn, NRW 53227 Germany
Ian Farrer Deutsche Telekom AG Landgrabenweg 151 Bonn、NRW 53227 Germany
Email: ian.farrer@telekom.de
Qi Sun Tsinghua University Beijing 100084 China
Q i sun ts inghua大学北京100084中国
Phone: +86-10-6278-5822
Email: sunqi.ietf@gmail.com
Yong Cui Tsinghua University Beijing 100084 China
Yong Cu ITS inghuauniversity北京100084中国
Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn
Linhui Sun Tsinghua University Beijing 100084 China
リンは大学北京100084中国に日光浴をします
Phone: +86-10-6278-5822
Email: lh.sunlinh@gmail.com