[要約] RFC 7618は、共有IPv4アドレスの動的割り当てに関するガイドラインです。その目的は、IPv4アドレスの枯渇を緩和し、効率的なアドレスの共有を可能にすることです。
Internet Engineering Task Force (IETF) Y. Cui
Request for Comments: 7618 Q. Sun
Category: Standards Track Tsinghua University
ISSN: 2070-1721 I. Farrer
Deutsche Telekom AG
Y. Lee
Comcast
Q. Sun
China Telecom
M. Boucadair
France Telecom
August 2015
Dynamic Allocation of Shared IPv4 Addresses
共有IPv4アドレスの動的割り当て
Abstract
概要
This memo describes the dynamic allocation of shared IPv4 addresses to clients using DHCPv4. Address sharing allows a single IPv4 address to be allocated to multiple active clients simultaneously, with each client being differentiated by a unique set of transport-layer source port numbers. The necessary changes to existing DHCPv4 client and server behavior are described, and a new DHCPv4 option for provisioning clients with shared IPv4 addresses is included.
このメモは、DHCPv4を使用するクライアントへの共有IPv4アドレスの動的割り当てについて説明しています。アドレス共有により、単一のIPv4アドレスを複数のアクティブなクライアントに同時に割り当てることができます。各クライアントは、トランスポート層の送信元ポート番号の一意のセットによって区別されます。既存のDHCPv4クライアントとサーバーの動作に必要な変更が説明されており、共有IPv4アドレスでクライアントをプロビジョニングするための新しいDHCPv4オプションが含まれています。
Due to the nature of IP address sharing, some limitations to its applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized.
IPアドレス共有の性質上、その適用性にはいくつかの制限が必要です。このメモは、これらの制限について説明し、アドレス共有を利用できる適切なアーキテクチャとテクノロジーを推奨しています。
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/rfc7618.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7618で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 ....................................................3
2. Applicability Statement .........................................3
3. Requirements Language ...........................................4
4. Terminology .....................................................4
5. Functional Overview .............................................4
6. Client-Server Interaction .......................................5
7. Client Behavior .................................................6
7.1. Restrictions to Client Usage of a Shared IPv4 Address ......7
8. Server Behavior .................................................7
8.1. Leasing Shared and Non-Shared IPv4 Addresses from a
Single DHCP 4o6 Server .....................................9
9. DHCPv4 Port Parameters Option ...................................9
10. Security Considerations .......................................10
10.1. Port Randomization .......................................11
11. IANA Considerations ...........................................11
12. References ....................................................11
12.1. Normative References .....................................11
12.2. Informative References ...................................12
Acknowledgements ..................................................14
Authors' Addresses ................................................14
The shortage of available public IPv4 addresses means that it is not always possible for operators to allocate a full IPv4 address to every connected device. This problem is particularly acute while an operator is migrating from their existing, native IPv4 network to a native IPv6 network with IPv4 provided as an overlay service. During this phase, public IPv4 addresses are needed to provide for both existing and transition networks.
利用可能なパブリックIPv4アドレスの不足は、オペレーターが接続されているすべてのデバイスに完全なIPv4アドレスを割り当てることが常に可能であるとは限らないことを意味します。オペレーターが既存のネイティブIPv4ネットワークから、IPv4をオーバーレイサービスとして提供するネイティブIPv6ネットワークに移行している間、この問題は特に深刻です。このフェーズでは、既存のネットワークと移行ネットワークの両方を提供するためにパブリックIPv4アドレスが必要です。
Two main types of solutions have emerged to address the problem (see Appendix A of [RFC6269]):
この問題に対処するために、主に2つのタイプのソリューションが登場しました（[RFC6269]の付録Aを参照）。
1. Deploying Carrier-Grade Network Address Translation devices (CGNs) [RFC6888].
1. キャリアグレードネットワークアドレス変換デバイス（CGN）[RFC6888]の展開。
2. Distributing the same public IPv4 address to multiple clients differentiated by non-overlapping Layer 4 port sets.
2. 重複しないレイヤ4ポートセットによって区別される複数のクライアントに同じパブリックIPv4アドレスを配布します。
This memo focuses on the second category of solutions.
このメモは、ソリューションの2番目のカテゴリに焦点を当てています。
[RFC7341] introduces a "DHCP 4o6 server", which offers dynamic leasing for IPv4 addresses to clients as described in DHCPv4 [RFC2131], but transported within a DHCPv6 message flow. This memo specifies a new DHCPv4 option -- OPTION_V4_PORTPARAMS -- and describes how it can be used for the dynamic leasing of shared IPv4 addresses.
[RFC7341]は「DHCP 4o6サーバー」を導入します。これは、DHCPv4 [RFC2131]で説明されているように、IPv4アドレスのダイナミックリースをクライアントに提供しますが、DHCPv6メッセージフロー内で転送されます。このメモは、新しいDHCPv4オプション-OPTION_V4_PORTPARAMS-を指定し、共有IPv4アドレスの動的リースにどのように使用できるかを説明します。
Although DHCPv4 over DHCPv6 is used as the underlying DHCPv4 transport mechanism throughout this document, OPTION_V4_PORTPARAMS as a DHCPv4 option may also be used in other solutions, if required.
このドキュメントでは、DHCPv4 over DHCPv6が基になるDHCPv4トランスポートメカニズムとして使用されていますが、必要に応じて、OPTION_V4_PORTPARAMSをDHCPv4オプションとして他のソリューションで使用することもできます。
The solution allows multiple hosts to be simultaneously allocated the same IP address. As the IP address is no longer a unique identifier for a host, this solution is only suitable for specific architectures based on the Address plus Port model (A+P) [RFC6346]. Specifically, this document presents a solution that applies to [RFC7596] and certain configurations of [RFC7597] (e.g., Embedded Address bit (EA-bit) length set to 0).
このソリューションでは、複数のホストに同じIPアドレスを同時に割り当てることができます。 IPアドレスはホストの一意の識別子ではなくなったため、このソリューションは、アドレスプラスポートモデル（A + P）[RFC6346]に基づく特定のアーキテクチャにのみ適しています。具体的には、このドキュメントは、[RFC7596]と[RFC7597]の特定の構成に適用されるソリューションを示しています（たとえば、埋め込みアドレスビット（EAビット）の長さが0に設定されています）。
The solution should only be used on point-to-point links, tunnels, and/or in environments where authentication at the link layer is performed before IP address assignment. It is not suitable for network access over shared media (e.g., Ethernet, WLAN, cable).
このソリューションは、ポイントツーポイントリンク、トンネル、またはIPアドレスの割り当て前にリンクレイヤーで認証が実行される環境でのみ使用する必要があります。共有メディア（イーサネット、WLAN、ケーブルなど）を介したネットワークアクセスには適していません。
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]で説明されているように解釈されます。
This document uses the following terms:
このドキュメントでは、次の用語を使用します。
Shared IPv4 address: An IPv4 address with a restricted Layer 4 port set.
共有IPv4アドレス：制限されたレイヤー4ポートセットを持つIPv4アドレス。
Port Set ID (PSID): Identifier for a range of ports assigned to a DHCP client.
ポートセットID（PSID）：DHCPクライアントに割り当てられたポートの範囲の識別子。
Functionally, the dynamic allocation of shared IPv4 addresses by the DHCP 4o6 server is similar to the dynamic allocation process for "full" IPv4 addresses as described in [RFC2131]. The essential difference is that the DHCP 4o6 server can allocate the same IPv4 address to more than one DHCP 4o6 client simultaneously, providing that each shared-address allocation also includes a range of Layer 4 source ports unique to that address (i.e., the combined tuple of IPv4 address and Port Set ID is to be unique for each active lease).
機能的には、DHCP 4o6サーバーによる共有IPv4アドレスの動的割り当ては、[RFC2131]で説明されている「完全な」IPv4アドレスの動的割り当てプロセスに似ています。本質的な違いは、DHCP 4o6サーバーが同じIPv4アドレスを複数のDHCP 4o6クライアントに同時に割り当てることができることです。ただし、各共有アドレスの割り当てには、そのアドレスに固有のレイヤー4送信元ポートの範囲（つまり、組み合わされたタプル）も含まれます。 IPv4アドレスとポートセットIDは、アクティブなリースごとに一意である必要があります）。
The DHCP 4o6 client implements OPTION_V4_PORTPARAMS (described below), which is a DHCPv4 option containing PSID information. The client includes this option within the Parameter Request List option [RFC2132] in its DHCPv4 DHCPDISCOVER and DHCPREQUEST messages, indicating its support for shared, dynamic address leasing to the DHCP 4o6 server.
DHCP 4o6クライアントは、OPTIONS_V4_PORTPARAMS（以下で説明）を実装します。これは、PSID情報を含むDHCPv4オプションです。クライアントは、DHCPv4 DHCPDISCOVERおよびDHCPREQUESTメッセージのパラメーター要求リストオプション[RFC2132]内にこのオプションを含み、DHCP 4o6サーバーへの共有動的アドレスリースのサポートを示します。
OPTION_V4_PORTPARAMS is also implemented by the server to identify clients that support shared, dynamic address leasing. With this option, the server can dynamically allocate PSIDs to clients and maintain shared IPv4 address leases. The server then manages unique client leases based on the IPv4 address and PSID tuple, instead of using only the IPv4 address.
OPTION_V4_PORTPARAMSもサーバーによって実装され、共有の動的アドレスリースをサポートするクライアントを識別します。このオプションを使用すると、サーバーはクライアントにPSIDを動的に割り当て、共有IPv4アドレスリースを維持できます。サーバーは、IPv4アドレスのみを使用するのではなく、IPv4アドレスとPSIDタプルに基づいて一意のクライアントリースを管理します。
In the event that a client capable of dynamic, shared addressing receives more than one DHCP 4o6 offer, where a received offer does not contain OPTION_V4_PORTPARAMS (i.e., it is an offer for a full IPv4 address), then the client SHOULD prefer the full IPv4 offer over the shared IPv4 address offer(s), unless specifically configured otherwise.
動的な共有アドレス指定が可能なクライアントが複数のDHCP 4o6オファーを受信した場合、受信したオファーにOPTION_V4_PORTPARAMSが含まれていない（つまり、完全なIPv4アドレスのオファーである）場合、クライアントは完全なIPv4を優先する必要があります（SHOULD）特に構成されていない限り、共有IPv4アドレスオファーを介したオファー。
The following DHCPv4 message flow is transported within the DHCPv4-query and DHCPv4-response messages as described in DHCPv4 over DHCPv6 [RFC7341].
次のDHCPv4メッセージフローは、DHCPv4 over DHCPv6 [RFC7341]で説明されているように、DHCPv4-queryおよびDHCPv4-responseメッセージ内で転送されます。
1. When the client constructs the DHCPv4 DHCPDISCOVER message to be transported within the DHCPv4-query message, the DHCPDISCOVER message MUST include the client identifier option (constructed as per [RFC4361]) and the Parameter Request List option with the code OPTION_V4_PORTPARAMS. The client MAY insert an OPTION_V4_PORTPARAMS with preferred values in related fields as a suggestion to the DHCP 4o6 server.
1. クライアントがDHCPv4クエリメッセージ内で転送されるDHCPv4 DHCPDISCOVERメッセージを構築する場合、DHCPDISCOVERメッセージには、クライアント識別子オプション（[RFC4361]に従って構築）およびコードOPTION_V4_PORTPARAMSを含むパラメーター要求リストオプションを含める必要があります。クライアントは、DHCP 4o6サーバーへの提案として、関連フィールドに優先値を含むOPTION_V4_PORTPARAMSを挿入してもよい（MAY）。
2. DHCP 4o6 servers that receive the DHCPDISCOVER message and support shared IPv4 addresses respond with a DHCPOFFER message with the shared IPv4 address in the yiaddr field, and they MUST add an OPTION_V4_PORTPARAMS option containing an available restricted port set. If the DHCPDISCOVER included an OPTION_V4_PORTPARAMS option containing a non-zero PSID-len field, the DHCP 4o6 server MAY allocate a port set of the requested size to the client (depending on policy). The DHCPOFFER message is then encapsulated in the DHCPv4-response message and sent to the client.
2. DHCPDISCOVERメッセージを受信し、共有IPv4アドレスをサポートするDHCP 4o6サーバーは、yiaddrフィールドに共有IPv4アドレスを含むDHCPOFFERメッセージで応答し、利用可能な制限付きポートセットを含むOPTION_V4_PORTPARAMSオプションを追加する必要があります。 DHCPDISCOVERに、ゼロ以外のPSID-lenフィールドを含むOPTION_V4_PORTPARAMSオプションが含まれている場合、DHCP 4o6サーバーは、要求されたサイズのポートセットをクライアントに割り当てることができます（ポリシーによって異なります）。次に、DHCPOFFERメッセージはDHCPv4-responseメッセージにカプセル化され、クライアントに送信されます。
3. The client evaluates all received DHCPOFFER messages and selects one (e.g., based on the configuration parameters received, such as the size of the offered port set). The client then sends a DHCPREQUEST encapsulated in the DHCPv4-query message containing the corresponding OPTION_V4_PORTPARAMS received in the DHCPOFFER message.
3. クライアントは受信したすべてのDHCPOFFERメッセージを評価し、1つを選択します（たとえば、提供されたポートセットのサイズなど、受信した構成パラメーターに基づいて）。次にクライアントは、DHCPOFFERメッセージで受信した対応するOPTION_V4_PORTPARAMSを含むDHCPv4-queryメッセージにカプセル化されたDHCPREQUESTを送信します。
4. The server identified in the DHCPREQUEST message creates a binding for the client. The binding includes the client identifier, the IPv4 address, and the PSID. These parameters are used by both the server and the client to identify a lease in any DHCP message. The server MUST respond with a DHCPACK message containing OPTION_V4_PORTPARAMS for the requesting client.
4. DHCPREQUESTメッセージで識別されたサーバーは、クライアントのバインディングを作成します。バインディングには、クライアント識別子、IPv4アドレス、およびPSIDが含まれます。これらのパラメータは、DHCPメッセージでリースを識別するためにサーバーとクライアントの両方で使用されます。サーバーは、要求しているクライアントのOPTION_V4_PORTPARAMSを含むDHCPACKメッセージで応答する必要があります。
5. On receipt of the DHCPACK message with the configuration parameters, the client MUST NOT perform an in-use probe on the address, such as ARPing for a duplicate allocated address.
5. 構成パラメーターを含むDHCPACKメッセージを受信すると、クライアントは、割り当てられた重複アドレスのARPingなど、アドレスに対して使用中のプローブを実行してはなりません（MUST NOT）。
6. If the client chooses to relinquish its lease by sending a DHCPRELEASE message, the client MUST include the leased network address and OPTION_V4_PORTPARAMS (with the allocated PSID) to identify the lease to be released.
6. クライアントがDHCPRELEASEメッセージを送信してリースを放棄することを選択した場合、クライアントはリースされたネットワークアドレスとOPTION_V4_PORTPARAMS（割り当てられたPSIDを含む）を含めて、解放するリースを識別しなければなりません（MUST）。
In the case where the client has stored the previously allocated address and restricted port set, the logic described in Section 3.2 of [RFC2131] MUST be followed on the condition that the client's source IPv6 address for DHCP 4o6 does not change. Note that this corresponds to the INIT-REBOOT state defined in [RFC2131]. The client MUST include the OPTION_V4_PORTPARAMS with the requested port-set information in the message flow, which starts with a DHCPREQUEST message. If the client's DHCP 4o6 IPv6 source address is changed for any reason, the client MUST re-initiate the DHCP 4o6 shared-address provisioning process by sending a DHCPDISCOVER message.
クライアントが以前に割り当てられたアドレスと制限されたポートセットを保存している場合、[RFC2131]のセクション3.2で説明されているロジックは、DHCP 4o6のクライアントのソースIPv6アドレスが変更されないという条件で従う必要があります。これは、[RFC2131]で定義されているINIT-REBOOT状態に対応することに注意してください。クライアントは、DHCPREQUESTメッセージで始まるメッセージフローに、要求されたポートセット情報を含むOPTION_V4_PORTPARAMSを含める必要があります。クライアントのDHCP 4o6 IPv6送信元アドレスが何らかの理由で変更された場合、クライアントはDHCPDISCOVERメッセージを送信して、DHCP 4o6共有アドレスプロビジョニングプロセスを再開する必要があります。
A DHCP 4o6 client sending a DHCPDISCOVER message for a shared IPv4 address MUST include the OPTION_V4_PORTPARAMS Option Code in the Parameter Request List option. If a client has previously been successfully allocated an IPv4 address and PSID, the client's DHCPDISCOVER message MAY include the Requested IP Address option along with an OPTION_V4_PORTPARAMS to request that a specific IPv4 address and PSID be reassigned. Alternatively, the client MAY omit the Requested IP Address option but include an OPTION_V4_PORTPARAMS with a non-zero value in only the PSID-len field, as a hint to the server for the preferred size of the port set.
共有IPv4アドレスのDHCPDISCOVERメッセージを送信するDHCP 4o6クライアントは、パラメーター要求リストオプションにOPTION_V4_PORTPARAMSオプションコードを含める必要があります。クライアントが以前にIPv4アドレスとPSIDが正常に割り当てられている場合、クライアントのDHCPDISCOVERメッセージには、特定のIPv4アドレスとPSIDの再割り当てを要求するOPTION_V4_PORTPARAMSとともに、要求されたIPアドレスオプションが含まれる場合があります。あるいは、クライアントは、要求されたIPアドレスオプションを省略してもかまいませんが、ポートセットの優先サイズのサーバーへのヒントとして、PSID-lenフィールドのみにゼロ以外の値を持つOPTION_V4_PORTPARAMSを含めます。
A client that requests OPTION_V4_PORTPARAMS but receives DHCPOFFER and DHCPACK messages without OPTION_V4_PORTPARAMS SHOULD proceed as described in Section 9 of [RFC7341] and configure a full IPv4 address with no address sharing (see Section 8.1).
OPTION_V4_PORTPARAMSをリクエストするが、OPTION_V4_PORTPARAMSなしでDHCPOFFERおよびDHCPACKメッセージを受信するクライアントは、[RFC7341]のセクション9の説明に従って処理し、アドレス共有なしで完全なIPv4アドレスを構成する必要があります（セクション8.1を参照）。
When receiving a DHCPACK message containing OPTION_V4_PORTPARAMS, the client MUST use the received explicit PSID for configuring the interface for which the DHCP 4o6 request was made.
OPTION_V4_PORTPARAMSを含むDHCPACKメッセージを受信するとき、クライアントは、DHCP 4o6要求が行われたインターフェイスを構成するために、受信した明示的なPSIDを使用する必要があります。
The client MUST NOT probe a newly received IPv4 address (e.g., using ARP) to see if it is in use by another host.
クライアントは、新しく受信したIPv4アドレスをプローブして（ARPなどを使用して）、別のホストで使用されているかどうかを確認してはなりません（MUST NOT）。
When the client renews or releases its DHCP lease, it MUST include the offset, PSID length, and PSID values in OPTION_V4_PORTPARAMS, and send it to the server within corresponding DHCPv4 messages.
クライアントがDHCPリースを更新または解放するときは、OPTION_V4_PORTPARAMSにオフセット、PSID長、およびPSID値を含め、対応するDHCPv4メッセージ内でサーバーに送信する必要があります。
In the event that the client's DHCP 4o6 IPv6 source address is changed for any reason, the client MUST re-initiate the DHCP 4o6 shared-address provisioning process by sending a DHCPDISCOVER message.
クライアントのDHCP 4o6 IPv6送信元アドレスが何らかの理由で変更された場合、クライアントはDHCPDISCOVERメッセージを送信して、DHCP 4o6共有アドレスプロビジョニングプロセスを再開する必要があります。
As a single IPv4 address is being shared between a number of different clients, the allocated shared address is only suitable for certain uses. The client MUST implement a function to ensure that only the allocated Layer 4 ports of the shared IPv4 address are used for sourcing new connections or accepting inbound connections.
単一のIPv4アドレスが複数の異なるクライアント間で共有されているため、割り当てられた共有アドレスは特定の用途にのみ適しています。クライアントは、共有IPv4アドレスの割り当てられたレイヤー4ポートのみが新しい接続のソースまたはインバウンド接続の受け入れに使用されるようにする関数を実装する必要があります。
The client MUST apply the following rules for all traffic destined to, or originating from, the shared IPv4 address:
クライアントは、共有IPv4アドレスを宛先とするすべてのトラフィックに次のルールを適用する必要があります。
o The client MUST use only port-aware protocols (e.g., TCP, UDP, the Datagram Congestion Control Protocol (DCCP)) and be ICMP compliant with [RFC5508].
o クライアントは、ポート対応プロトコル（TCP、UDP、データグラム輻輳制御プロトコル（DCCP）など）のみを使用し、[RFC5508]に準拠したICMPである必要があります。
o All connections originating from the shared IPv4 address MUST use a source port taken from the allocated restricted port set.
o 共有IPv4アドレスから発生するすべての接続は、割り当てられた制限付きポートセットから取得した送信元ポートを使用する必要があります。
o The client MUST NOT accept inbound connections on ports outside of the allocated restricted port set.
o クライアントは、割り当てられた制限付きポートセット以外のポートでのインバウンド接続を受け入れてはなりません（MUST NOT）。
In order to prevent addressing conflicts that could arise from the allocation of the same IPv4 address, the client MUST NOT use the received restricted IPv4 address to perform ARP operations.
同じIPv4アドレスの割り当てから生じる可能性のあるアドレッシングの競合を防ぐために、クライアントは受信した制限されたIPv4アドレスを使用してARP操作を実行してはなりません（MUST NOT）。
The mechanism by which a client implements the above rules is out of scope for this document.
クライアントが上記のルールを実装するメカニズムは、このドキュメントの範囲外です。
In the event that the DHCPv4-over-DHCPv6 configuration mechanism fails for any reason, the client MUST NOT configure an IPv4 link-local address [RFC3927] (taken from the 169.254.0.0/16 range).
DHCPv4-over-DHCPv6構成メカニズムが何らかの理由で失敗した場合、クライアントはIPv4リンクローカルアドレス[RFC3927]（169.254.0.0/16の範囲から取得）を構成してはなりません（MUST NOT）。
The DHCP 4o6 server MUST NOT reply with OPTION_V4_PORTPARAMS unless the client has explicitly listed the Option Code in the Parameter Request List (Option 55) [RFC2132].
DHCP 4o6サーバーは、クライアントがパラメータ要求リスト（オプション55）[RFC2132]にオプションコードを明示的にリストしていない限り、OPTION_V4_PORTPARAMSで応答してはなりません（MUST NOT）。
The DHCP 4o6 server SHOULD reply with OPTION_V4_PORTPARAMS if the client includes OPTION_V4_PORTPARAMS in its Parameter Request List. In order to achieve dynamic management of shared IPv4 addresses, the server is required to implement an address and port-set pool that provides the same function as the address pool in a regular DHCP server. Also, the server uses the combination of address and PSID as the key for maintaining the state of a lease and for searching for an available lease for assignment. The leasing database is required to include the IPv4 address, PSID, and client identifier of the requesting client.
DHCP 4o6サーバーは、クライアントのパラメーター要求リストにOPTION_V4_PORTPARAMSが含まれている場合、OPTION_V4_PORTPARAMSで応答する必要があります（SHOULD）。共有IPv4アドレスの動的管理を実現するために、サーバーは、通常のDHCPサーバーのアドレスプールと同じ機能を提供するアドレスとポートセットプールを実装する必要があります。また、サーバーはアドレスとPSIDの組み合わせをキーとして使用して、リースの状態を維持し、割り当てに使用できるリースを検索します。リースデータベースには、要求元クライアントのIPv4アドレス、PSID、およびクライアント識別子を含める必要があります。
When a server receives a DHCPDISCOVER message with OPTION_V4_PORTPARAMS in the Parameter Request List option, the server determines an IPv4 address with a PSID for the requesting client. If an IPv4 address with a PSID is available, the server SHOULD follow the logic below to select which specific address and PSID to provision to the client. The logic is similar to that described in Section 4.3.1 of [RFC2131].
サーバーがパラメーター要求リストオプションにOPTION_V4_PORTPARAMSを含むDHCPDISCOVERメッセージを受信すると、サーバーは要求側クライアントのPSIDを使用してIPv4アドレスを決定します。 PSIDを持つIPv4アドレスが利用可能な場合、サーバーは、以下のロジックに従って、クライアントにプロビジョニングする特定のアドレスとPSIDを選択する必要があります（SHOULD）。ロジックは[RFC2131]のセクション4.3.1で説明されているものと同様です。
o The client's current address with the PSID, as recorded in the client's current lease binding, ELSE
o クライアントの現在のリースバインディングELSEに記録されている、クライアントの現在のアドレスとPSID
o The client's previous address with the PSID, as recorded in the client's (expired or released) binding, if that address with PSID is in the server's pool of available addresses and PSIDs, and not already allocated, ELSE
o クライアントの（期限切れまたは解放された）バインディングに記録されている、PSIDを含むクライアントの以前のアドレス（PSIDを含むそのアドレスがサーバーの使用可能なアドレスとPSIDのプールにあり、まだ割り当てられていない場合）ELSE
o The address requested in the Requested IP Address option along with the PSID parameters requested in the OPTION_V4_PORTPARAMS, if that pair of address and PSID is valid and not already allocated, ELSE
o リクエストされたIPアドレスオプションでリクエストされたアドレスと、OPTION_V4_PORTPARAMSでリクエストされたPSIDパラメータ。アドレスとPSIDのペアが有効であり、まだ割り当てられていない場合は、ELSE
o A new address with a PSID allocated from the server's pool of available addresses and PSIDs.
o サーバーの使用可能なアドレスとPSIDのプールから割り当てられたPSIDを持つ新しいアドレス。
Upon receipt of a DHCPRELEASE message with OPTION_V4_PORTPARAMS, the server searches for the lease using the address in the ciaddr field and the PSID information in the OPTION_V4_PORTPARAMS, and marks the lease as unallocated if a record (matching that PSID) is maintained by the server for that client.
サーバーは、OPTION_V4_PORTPARAMSを含むDHCPRELEASEメッセージを受信すると、ciaddrフィールドのアドレスとOPTION_V4_PORTPARAMSのPSID情報を使用してリースを検索し、レコード（そのPSIDと一致）がサーバーによって維持されている場合、そのリースを未割り当てとしてマークしますそのクライアント。
The port-set assignment MUST be coupled with the address assignment process. Therefore, the server MUST assign the address and port set in the same DHCP message.
ポートセットの割り当ては、アドレス割り当てプロセスと組み合わせる必要があります。したがって、サーバーは同じDHCPメッセージで設定されたアドレスとポートを割り当てる必要があります。
When defining the pools of IPv4 addresses and PSIDs that are available to lease to clients, the server MUST implement a mechanism to reserve some port ranges (e.g., 0-1023) from allocation to clients. The reservation policy SHOULD be configurable.
クライアントにリースできるIPv4アドレスとPSIDのプールを定義する場合、サーバーは、クライアントへの割り当てから一部のポート範囲（0〜1023など）を予約するメカニズムを実装する必要があります。予約ポリシーは構成可能である必要があります。
8.1. Leasing Shared and Non-Shared IPv4 Addresses from a Single DHCP 4o6 Server
8.1. 単一のDHCP 4o6サーバーからの共有および非共有IPv4アドレスのリース
A single DHCP 4o6 server may serve clients that do not support OPTION_V4_PORTPARAMS, as well as those that do. As the rules for the allocation of shared addresses differ from the rules for full IPv4 address assignment, the DHCP 4o6 server MUST implement a mechanism to ensure that clients not supporting OPTION_V4_PORTPARAMS do not receive shared addresses. For example, two separate IPv4 addressing pools could be used, one of which allocates IPv4 addresses and PSIDs only to clients that have requested them.
単一のDHCP 4o6サーバーは、OPTION_V4_PORTPARAMSをサポートしていないクライアントだけでなく、サポートしているクライアントにもサービスを提供できます。共有アドレスの割り当てのルールは完全なIPv4アドレス割り当てのルールとは異なるため、DHCP 4o6サーバーは、OPTION_V4_PORTPARAMSをサポートしていないクライアントが共有アドレスを受信しないようにするメカニズムを実装する必要があります。たとえば、2つの個別のIPv4アドレス指定プールを使用できます。そのうちの1つは、IPv4アドレスとPSIDを、それらを要求したクライアントにのみ割り当てます。
If the server is only configured with address pools for shared-address allocation, it MUST discard requests that do not contain OPTION_V4_PORTPARAMS in the Parameter Request List option.
サーバーが共有アドレス割り当て用のアドレスプールのみで構成されている場合、パラメーターリクエストリストオプションにOPTION_V4_PORTPARAMSを含まないリクエストを破棄する必要があります。
A server configured with non-shared address pools can be instructed to honor received requests that contain OPTION_V4_PORTPARAMS in the Parameter Request List option (that is, ignore OPTION_V4_PORTPARAMS and serve the requesting clients with non-shared IPv4 addresses).
非共有アドレスプールで構成されたサーバーは、パラメーター要求リストオプションにOPTION_V4_PORTPARAMSを含む受信した要求を受け入れるように指示できます（つまり、OPTION_V4_PORTPARAMSを無視し、非共有IPv4アドレスで要求クライアントにサービスを提供します）。
The meanings of the offset, PSID-len, and PSID fields of the DHCPv4 Port Parameters option are identical to those of the offset, PSID-len, and PSID fields of the S46 Port Parameters option (Section 4.5 of [RFC7598]). The use of the same encoding in both options is meant to ensure compatibility with existing port-set implementations.
DHCPv4ポートパラメータオプションのオフセット、PSID-len、PSIDフィールドの意味は、S46ポートパラメータオプションのオフセット、PSID-len、PSIDフィールドと同じです（[RFC7598]のセクション4.5）。両方のオプションで同じエンコーディングを使用することは、既存のポートセット実装との互換性を確保することを目的としています。
The format of OPTION_V4_PORTPARAMS is shown in Figure 1.
OPTION_V4_PORTPARAMSのフォーマットを図1に示します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| option-code | option-len |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| offset | PSID-len |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PSID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 1: DHCPv4 Port Parameters Option
図1：DHCPv4ポートパラメータオプション
o option-code: OPTION_V4_PORTPARAMS (159)
o オプションコード：OPTION_HF_PORTPARAMS（159）
o option-len: 4 o offset: PSID offset. 8-bit field that specifies the numeric value for the excluded port range/offset bits ('a' bits), as per Section 5.1 of [RFC7597]. Allowed values are between 0 and 15, with the default value being 6 for MAP-based implementations. This parameter is unused by a Lightweight 4over6 client and should be set to 0.
o option-len：4 o offset：PSIDオフセット。 [RFC7597]のセクション5.1に従って、除外されたポート範囲/オフセットビット（「a」ビット）の数値を指定する8ビットフィールド。許可される値は0〜15で、MAPベースの実装のデフォルト値は6です。このパラメーターは、Lightweight 4over6クライアントでは使用されず、0に設定する必要があります。
o PSID-len: Bit length value of the number of significant bits in the PSID field (also known as 'k'). When set to 0, the PSID field is to be ignored. After the first 'a' bits, there are k bits in the port number representing the value of PSID. Subsequently, the address-sharing ratio would be 2^k.
o PSID-len：PSIDフィールドの有効ビット数のビット長値（「k」とも呼ばれます）。 0に設定すると、PSIDフィールドは無視されます。最初の「a」ビットの後、PSIDの値を表すポート番号にはkビットがあります。その後、アドレス共有比率は2 ^ kになります。
o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value algorithmically identifies a set of ports assigned to a client. The first k bits on the left of this 2-octet field indicate the PSID value. The remaining (16 - k) bits on the right are padding zeros.
o PSID：明示的な16ビット（符号なしワード）PSID値。 PSID値は、クライアントに割り当てられた一連のポートをアルゴリズムによって識別します。この2オクテットフィールドの左側の最初のkビットは、PSID値を示します。右側の残りの（16-k）ビットはパディングゼロです。
Section 5.1 of [RFC7597] provides a full description of how the PSID is interpreted by the client.
[RFC7597]のセクション5.1は、クライアントによるPSIDの解釈方法の詳細を説明しています。
In order to exclude the system ports ([RFC6335]) or ports reserved by ISPs, the former port sets that contain well-known ports MUST NOT be assigned unless the operator has explicitly configured otherwise (e.g., by allocating a full IPv4 address).
システムポート（[RFC6335]）またはISPによって予約されたポートを除外するには、既知のポートを含む以前のポートセットを、オペレーターが明示的に（たとえば、完全なIPv4アドレスを割り当てることによって）構成しない限り、割り当てないでください。
The security considerations described in [RFC2131] and [RFC7341] are also potentially applicable to this solution. Unauthorized DHCP 4o6 servers in the network could be used to stage an amplification attack or to supply an invalid configuration, leading to service disruption. The risks of these types of attacks can be reduced by using unicast DHCP 4o6 message flows (enabled by supplying DHCP 4o6 server unicast addresses within the OPTION_DHCP4_O_DHCP6_SERVER option [RFC7341]).
[RFC2131]および[RFC7341]で説明されているセキュリティの考慮事項も、このソリューションに適用できる可能性があります。ネットワーク内の許可されていないDHCP 4o6サーバーを使用して、増幅攻撃をステージングしたり、無効な構成を提供したりして、サービスを中断させる可能性があります。これらのタイプの攻撃のリスクは、ユニキャストDHCP 4o6メッセージフローを使用することで軽減できます（OPTION_DHCP4_O_DHCP6_SERVERオプション[RFC7341]内でDHCP 4o6サーバーユニキャストアドレスを指定することで有効になります）。
A malicious user could attempt a DoS attack by requesting a large number of IPv4 address (or fractional address) and port-set allocations, exhausting the available addresses and port sets for other clients. This can be mitigated by implementing, on each applicable customer site, a DHCP 4o6 address allocation policy that limits the number of simultaneously active IPv4 leases for clients whose requests originate from that customer site.
悪意のあるユーザーは、大量のIPv4アドレス（またはフラクショナルアドレス）とポートセットの割り当てを要求し、他のクライアントで使用可能なアドレスとポートセットを使い果たすことにより、DoS攻撃を試みる可能性があります。これは、該当する顧客サイトごとに、その顧客サイトから要求が発生するクライアントの同時にアクティブなIPv4リースの数を制限するDHCP 4o6アドレス割り当てポリシーを実装することで軽減できます。
The purpose of the client identifier option is to ensure that the same client retains the same parameters over time. However, this interferes with the client's privacy, as it allows the server to track the client. Clients can manage their level of exposure by controlling the value of the client identifier, thereby trading off stability of parameter allocation for privacy. We expect that guidance on this trade-off will be discussed in a future version of [DHCP-Anonymity].
クライアント識別子オプションの目的は、同じクライアントが長期にわたって同じパラメーターを保持するようにすることです。ただし、サーバーがクライアントを追跡できるようになるため、これはクライアントのプライバシーを妨げます。クライアントは、クライアント識別子の値を制御することにより、公開レベルを管理できます。これにより、パラメータ割り当ての安定性とプライバシーをトレードオフできます。このトレードオフについてのガイダンスは、[DHCP-Anonymity]の将来のバージョンで説明される予定です。
Additional security considerations are discussed in Section 10 of [RFC7597] and Section 9 of [RFC7596].
セキュリティに関するその他の考慮事項については、[RFC7597]のセクション10と[RFC7596]のセクション9で説明しています。
Preserving port randomization [RFC6056] may be more difficult because the host can only randomize the ports inside a fixed port range (see Section 13.4 of [RFC6269]).
ホストはランダムなポート範囲内のポートのみをランダム化できるため（[RFC6269]のセクション13.4を参照）、ポートのランダム化[RFC6056]を維持することはより難しい場合があります。
More discussion regarding improving the robustness of TCP against blind in-window attacks can be found in [RFC5961]. To provide protection against attacks, means other than (IPv4) source port randomization should be used (e.g., use [RFC5961] to improve the robustness of TCP against blind in-window attacks, or use IPv6).
ブラインドウィンドウ内攻撃に対するTCPの堅牢性の向上に関する詳細については、[RFC5961]を参照してください。攻撃に対する保護を提供するには、（IPv4）送信元ポートのランダム化以外の手段を使用する必要があります（たとえば、[RFC5961]を使用して、ブラインドウィンドウ内攻撃に対するTCPの堅牢性を向上させるか、IPv6を使用します）。
IANA has assigned the following new DHCPv4 Option Code in the registry maintained at <http://www.iana.org/assignments/bootp-dhcp-parameters/>:
IANAは、<http://www.iana.org/assignments/bootp-dhcp-parameters/>で管理されているレジストリに、次の新しいDHCPv4オプションコードを割り当てました。
Option Name Tag Data Meaning
Length
-------------------- --- ------ -----------------------------------
OPTION_V4_PORTPARAMS 159 4 This option is used to configure a
set of ports bound to a shared IPv4
address.
[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>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<http://www.rfc-editor.org/info/rfc2131>。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、DOI 10.17487 / RFC2132、1997年3月、<http://www.rfc-editor.org/info/rfc2132>。
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361, February 2006, <http://www.rfc-editor.org/info/rfc4361>.
[RFC4361]レモン、T。およびB.ソマーフェルド、「動的ホスト構成プロトコルバージョン4（DHCPv4）のノード固有のクライアント識別子」、RFC 4361、DOI 10.17487 / RFC4361、2006年2月、<http：//www.rfc- editor.org/info/rfc4361>。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <http://www.rfc-editor.org/info/rfc5961>.
[RFC5961] Ramaiah、A.、Stewart、R。、およびM. Dalal、「ブラインドインウィンドウ攻撃に対するTCPの堅牢性の向上」、RFC 5961、DOI 10.17487 / RFC5961、2010年8月、<http：//www.rfc- editor.org/info/rfc5961>。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.
[RFC6056] Larsen、M。およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、DOI 10.17487 / RFC6056、2011年1月、<http://www.rfc-editor.org/info / rfc6056>。
[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>。
[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>。
[DHCP-Anonymity] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity profile for DHCP clients", Work in Progress, draft-ietf-dhc-anonymity-profile-01, June 2015.
[DHCP-Anonymity] Huitema、C.、Mrugalski、T。、およびS. Krishnan、「DHCPクライアントの匿名性プロファイル」、Work in Progress、draft-ietf-dhc-anonymity-profile-01、2015年6月。
[DHCP-Port-Set-Opt] Sun, Q., Lee, Y., Sun, Q., Bajko, G., and M. Boucadair, "Dynamic Host Configuration Protocol (DHCP) Option for Port Set Assignment", Work in Progress, draft-sun-dhc-port-set-option-02, October 2013.
[DHCP-Port-Set-Opt] Sun、Q.、Lee、Y.、Sun、Q.、Bajko、G。、およびM. Boucadair、「ポートセット割り当て用の動的ホスト構成プロトコル（DHCP）オプション」、作業進行中、draft-sun-dhc-port-set-option-02、2013年10月。
[DHCPv4_v6-Shared-Addr] Farrer, I., "Dynamic Allocation of Shared IPv4 Addresses using DHCPv4 over DHCPv6", Work in Progress, draft-farrer-dhc-shared-address-lease-00, June 2013.
[DHCPv4_v6-Shared-Addr] Farrer、I。、「DHCPv4 over DHCPv6を使用した共有IPv4アドレスの動的割り当て」、作業中、draft-farrer-dhc-shared-address-lease-00、2013年6月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005, <http://www.rfc-editor.org/info/rfc3927>.
[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4リンクローカルアドレスの動的構成」、RFC 3927、DOI 10.17487 / RFC3927、2005年5月、<http：//www.rfc-editor .org / info / rfc3927>。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, DOI 10.17487/RFC5508, April 2009, <http://www.rfc-editor.org/info/rfc5508>.
[RFC5508] Srisuresh、P.、Ford、B.、Sivakumar、S。、およびS. Guha、「ICMPのNAT動作要件」、BCP 148、RFC 5508、DOI 10.17487 / RFC5508、2009年4月、<http：// www.rfc-editor.org/info/rfc5508>。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.
[RFC6269] Ford、M.、Ed。、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「Issues with IP Address Sharing」、RFC 6269、DOI 10.17487 / RFC6269、2011年6月、 <http://www.rfc-editor.org/info/rfc6269>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<http://www.rfc-editor.org/info/rfc6335>。
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/ RFC6346, August 2011, <http://www.rfc-editor.org/info/rfc6346>.
[RFC6346]ブッシュ、R。、編、「IPv4アドレス不足に対するアドレスとポート（A + P）のアプローチ」、RFC 6346、DOI 10.17487 / RFC6346、2011年8月、<http：//www.rfc-editor .org / info / rfc6346>。
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC6888] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A.、and H. Ashida、 "Common Requirements for Carrier-Grade NATs（CGNs）"、BCP 127、RFC 6888、 DOI 10.17487 / RFC6888、2013年4月、<http://www.rfc-editor.org/info/rfc6888>。
[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、「Softwireの構成のためのDHCPv6オプションAddress and Port-Mapped Clients」、RFC 7598、DOI 10.17487 / RFC7598、2015年7月、<http://www.rfc-editor.org/info/rfc7598>。
Acknowledgements
謝辞
This document is the result of merging [DHCP-Port-Set-Opt] and [DHCPv4_v6-Shared-Addr].
このドキュメントは、[DHCP-Port-Set-Opt]と[DHCPv4_v6-Shared-Addr]をマージした結果です。
The authors would like to thank Peng Wu, Gabor Bajko, Teemu Savolainen, Ted Lemon, Tina Tsou, Pierre Levis, Cong Liu, Marcin Siodelski, and Christian Huitema for their contributions.
著者は、Peng Wu、Gabor Bajko、Teemu Savolainen、Ted Lemon、Tina Tsou、Pierre Levis、Cong Liu、Marcin Siodelski、およびChristian Huitemaの貢献に感謝します。
Many thanks to Brian Haberman for the review.
レビューしてくれたBrian Habermanに感謝します。
Authors' Addresses
著者のアドレス
Yong Cui Tsinghua University Beijing 100084 China
Yong Cu ITS inghuauniversity北京100084中国
Phone: +86-10-62603059
Email: yong@csnet1.cs.tsinghua.edu.cn
Qi Sun Tsinghua University Beijing 100084 China
Q i sun ts inghua大学北京100084中国
Phone: +86-10-62785822
Email: sunqi.ietf@gmail.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
Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 United States
Yiu L. Lee Comcast One Comcast Centerフィラデルフィア、PA 19103アメリカ合衆国
Email: yiu_lee@cable.comcast.com Qiong Sun China Telecom Room 708, No.118, Xizhimennei Street Beijing 100035 China
メール：yiu_lee@cable.comcast.com Qiong Sun China Telecom Room 708、No.118、Xizhimennei Street Beijing 100035 China
Phone: +86-10-58552936
Email: sunqiong@ctbri.com.cn
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
Email: mohamed.boucadair@orange.com