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
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客户端和服务器行为的必要更改，并包括一个新的DHCPv4选项，用于为客户端提供共享IPv4地址。
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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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]):
为解决该问题，出现了两种主要的解决方案（见[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. 将相同的公共IPv4地址分发给多个客户端，这些客户端由非重叠的第4层端口集区分。
This memo focuses on the second category of solutions.
本备忘录重点介绍第二类解决方案。
[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服务器”，它为客户端提供IPv4地址的动态租赁，如DHCPv4[RFC2131]中所述，但在DHCPv6消息流中传输。此备忘录指定了一个新的DHCPv4选项--optionv4u 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传输机制，但如果需要，选项_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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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客户端实现选项_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.
选项\u V4\u PORTPARAMS也由服务器实现，以标识支持共享、动态地址租赁的客户端。使用此选项，服务器可以向客户端动态分配PSID，并维护共享IPv4地址租约。然后，服务器基于IPv4地址和PSID元组管理唯一的客户端租用，而不是仅使用IPv4地址。
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提供，而接收到的提供不包含选项_V4_PORTPARAMS（即，它是完整IPv4地址的提供），则客户端应首选完整IPv4提供而不是共享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查询和DHCPv4响应消息中传输，如DHCPv4 over DHCPv6[RFC7341]中所述。
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]构造）和参数请求列表选项以及代码选项_V4_PORTPARAMS。客户端可以在相关字段中插入带有首选值的选项\u V4\u PORTPARAMS，作为对DHCP 4o6服务器的建议。
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地址响应DHCPOFFERE消息，并且它们必须添加包含可用受限端口集的选项\u V4\u PORTPARAMS选项。如果DHCPDISCOVER包含包含非零PSID len字段的选项\u V4\u PORTPARAMS选项，则DHCP 4o6服务器可能会将请求大小的端口集分配给客户端（取决于策略）。然后，DHCPOFFER消息被封装在DHCPv4响应消息中，并发送到客户端。
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消息并选择一条（例如，基于接收到的配置参数，例如提供的端口集的大小）。然后，客户端发送封装在DHCPv4查询消息中的DHCPREQUEST，该消息包含在DHCPOFFER消息中接收到的相应选项\u V4\u PORTPARAMS。
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消息中的租约。服务器必须响应一条DHCPACK消息，其中包含请求客户端的选项\u V4\u PORTPARAMS。
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消息时，客户端不得对地址执行正在使用的探测，例如对重复分配的地址执行ARP。
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消息选择放弃其租约，则客户端必须包括租用的网络地址和选项_V4_PORTPARAMS（带有分配的PSID），以标识要释放的租约。
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]中定义的初始重新启动状态。客户端必须在消息流中包含带有请求的端口集信息的选项\u V4\u PORTPARAMS，该消息流以DHCPREQUEST消息开始。如果客户端的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客户端必须在参数请求列表选项中包含选项_V4_PORTPARAMS选项代码。如果客户机之前已成功分配IPv4地址和PSID，则客户机的DHCPDISCOVER消息可能包括请求的IP地址选项以及用于请求重新分配特定IPv4地址和PSID的选项\u V4\u PORTPARAMS。或者，客户端可以省略请求的IP地址选项，但仅在PSID len字段中包含一个非零值的选项\u V4\u 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.
当接收到包含选项_V4_PORTPARAMS的DHCPACK消息时，客户端必须使用收到的显式PSID来配置发出DHCP 4o6请求的接口。
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）以查看它是否正在被其他主机使用。
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租约时，它必须在选项_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地址或源自共享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 客户端不得在已分配的受限端口集之外的端口上接受入站连接。
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操作。
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范围）。
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].
除非客户端已在参数请求列表（选项55）[RFC2132]中明确列出选项代码，否则DHCP 4o6服务器不得使用选项_V4_PORTPARAMS进行回复。
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.
如果客户端在其参数请求列表中包含选项\u V4\u PORTPARAMS，则DHCP 4o6服务器应使用选项\u V4\u PORTPARAMS进行回复。为了实现共享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].
当服务器接收到参数请求列表选项中带有选项_V4_PORTPARAMS的DHCPDISCOVER消息时，服务器将为请求客户端确定带有PSID的IPv4地址。如果具有PSID的IPv4地址可用，则服务器应按照以下逻辑选择要向客户端提供的特定地址和PSID。该逻辑类似于[RFC2131]第4.3.1节中所述的逻辑。
o The client's current address with the PSID, as recorded in the client's current lease binding, ELSE
o 客户当前租约绑定中记录的客户当前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池中，并且尚未分配，则为
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地址选项中请求的地址以及选项_V4_PORTPARAMS中请求的PSID参数（如果该地址和PSID对有效且尚未分配），否则
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.
收到带有选项_V4_PORTPARAMS的DHCPRELEASE消息后，服务器使用ciaddr字段中的地址和选项_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的客户端以及支持OPTION_V4_PORTPARAMS的客户端提供服务。由于共享地址分配的规则与完整IPv4地址分配的规则不同，DHCP 4o6服务器必须实现一种机制，以确保不支持OPTION_V4_PORTPARAMS的客户端不接收共享地址。例如，可以使用两个独立的IPv4寻址池，其中一个只将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.
如果服务器仅配置了用于共享地址分配的地址池，则必须放弃参数请求列表选项中不包含选项\u V4\u 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).
可以指示配置了非共享地址池的服务器接受接收到的请求，这些请求包含参数请求列表选项中的选项_V4_PORTPARAMS（即，忽略选项_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.
选项_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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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 选项代码：选项4\u端口参数（159）
o option-len: 4
o 选项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 偏移量：PSID偏移量。根据[RFC7597]第5.1节，指定排除的端口范围/偏移位（“a”位）的数值的8位字段。允许的值介于0和15之间，对于基于地图的实现，默认值为6。轻量级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”位之后，端口号中有k位表示PSID的值。随后，地址共享比率将为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消息流（通过在选项_DHCP4_O_DHCP6_服务器选项[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攻击，从而耗尽其他客户端的可用地址和端口集。这可以通过在每个适用的客户站点上实施DHCP 4o6地址分配策略来缓解，该策略限制来自该客户站点的请求的客户端的同时活动IPv4租约的数量。
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匿名性]的未来版本中讨论关于这一权衡的指导。
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]).
保留端口随机化[RFC6056]可能更加困难，因为主机只能随机化固定端口范围内的端口（请参阅[RFC6269]第13.4节）。
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在维护的注册表中分配了以下新的DHCPv4选项代码：<http://www.iana.org/assignments/bootp-dhcp-parameters/>:
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.
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.，“动态主机配置协议”，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]Lemon，T.和B.Sommerfeld，“动态主机配置协议第四版（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，“运输协议端口随机化建议”，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）传输”，RFC 7341，DOI 10.17487/RFC73412014年8月<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，“轻量级4over6：双栈精简架构的扩展”，RFC 7596，DOI 10.17487/RFC75962015年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.，和T.Taylor，Ed.，“地址和端口的封装映射（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匿名]Huitema，C.，Mrugalski，T.，和S.Krishnan，“DHCP客户的匿名配置文件”，正在进行的工作，草稿-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端口集选项]Sun，Q.，Lee，Y.，Sun，Q.，Bajko，G.，和M.Boucadair，“用于端口集分配的动态主机配置协议（DHCP）选项”，正在进行的工作，草稿-Sun-dhc-Port-Set-Option-022013年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.“在DHCPv6上使用DHCPv4动态分配共享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]福特，M.，Ed.，Boucadair，M.，Durand，A.，Levis，P.，和P.Roberts，“IP地址共享问题”，RFC 6269，DOI 10.17487/RFC62692011年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]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（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]Bush，R.，Ed.，“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.，和H.Ashida，“载体级NAT（CGN）的通用要求”，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，“用于配置软线地址和端口映射客户端的DHCPv6选项”，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端口集Opt]和[DHCPv4\u 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.
作者要感谢吴鹏、加博·巴伊科、蒂姆·萨沃莱宁、特德·莱蒙、蒂娜·邹、皮埃尔·列维斯、刘聪、马辛·西奥德尔斯基和克里斯蒂安·惠特马的贡献。
Many thanks to Brian Haberman for the review.
非常感谢Brian Haberman的评论。
Authors' Addresses
作者地址
Yong Cui Tsinghua University Beijing 100084 China
清华大学崔勇中国北京100084
Phone: +86-10-62603059
Email: yong@csnet1.cs.tsinghua.edu.cn
Phone: +86-10-62603059
Email: yong@csnet1.cs.tsinghua.edu.cn
Qi Sun Tsinghua University Beijing 100084 China
齐孙清华大学北京100084
Phone: +86-10-62785822
Email: sunqi.ietf@gmail.com
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，德国新南威尔士州波恩市兰德格拉本韦151号，邮编53227
Email: ian.farrer@telekom.de
Email: ian.farrer@telekom.de
Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 United States
Yiu L.Lee Comcast美国宾夕法尼亚州费城Comcast中心1号，邮编：19103
Email: yiu_lee@cable.comcast.com
Email: yiu_lee@cable.comcast.com
Qiong Sun China Telecom Room 708, No.118, Xizhimennei Street Beijing 100035 China
中国北京西直门内大街118号琼阳中国电信708室，邮编100035
Phone: +86-10-58552936
Email: sunqiong@ctbri.com.cn
Phone: +86-10-58552936
Email: sunqiong@ctbri.com.cn
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
Email: mohamed.boucadair@orange.com
Email: mohamed.boucadair@orange.com