doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc7618.txt b/doc/rfc/rfc7618.txt
new file mode 100644
index 0000000..89e0300
--- /dev/null
+++ b/doc/rfc/rfc7618.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+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
+
+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.
+
+   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.
+
+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.
+
+   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.
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 1]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 2]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+1.  Introduction
+
+   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.
+
+   Two main types of solutions have emerged to address the problem (see
+   Appendix A of [RFC6269]):
+
+   1.  Deploying Carrier-Grade Network Address Translation devices
+       (CGNs) [RFC6888].
+
+   2.  Distributing the same public IPv4 address to multiple clients
+       differentiated by non-overlapping Layer 4 port sets.
+
+   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.
+
+   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.
+
+2.  Applicability Statement
+
+   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).
+
+   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).
+
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 3]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+3.  Requirements Language
+
+   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].
+
+4.  Terminology
+
+   This document uses the following terms:
+
+   Shared IPv4 address:  An IPv4 address with a restricted Layer 4
+                         port set.
+
+   Port Set ID (PSID):   Identifier for a range of ports assigned to a
+                         DHCP client.
+
+5.  Functional Overview
+
+   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).
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 4]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+6.  Client-Server Interaction
+
+   The following DHCPv4 message flow is transported within the
+   DHCPv4-query and DHCPv4-response messages as described in 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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 5]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+   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.
+
+7.  Client Behavior
+
+   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.
+
+   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).
+
+   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.
+
+   The client MUST NOT probe a newly received IPv4 address (e.g., using
+   ARP) to see if it is in use by another host.
+
+   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.
+
+   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.
+
+
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 6]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+7.1.  Restrictions to Client Usage of a Shared IPv4 Address
+
+   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.
+
+   The client MUST apply the following rules for all traffic destined
+   to, or originating from, the shared IPv4 address:
+
+   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  All connections originating from the shared IPv4 address MUST use
+      a source port taken from the allocated restricted port set.
+
+   o  The client MUST NOT accept inbound connections on ports outside of
+      the allocated restricted port set.
+
+   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.
+
+   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).
+
+8.  Server Behavior
+
+   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].
+
+   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.
+
+
+
+Cui, et al.                  Standards Track                    [Page 7]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+   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].
+
+   o  The client's current address with the PSID, as recorded in the
+      client's current lease binding, ELSE
+
+   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  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  A new address with a PSID allocated from the server's pool of
+      available addresses and PSIDs.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 8]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+8.1.  Leasing Shared and Non-Shared IPv4 Addresses from a Single
+      DHCP 4o6 Server
+
+   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.
+
+   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.
+
+   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).
+
+9.  DHCPv4 Port Parameters Option
+
+   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.
+
+   The format of OPTION_V4_PORTPARAMS is shown in Figure 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
+
+   o  option-code: OPTION_V4_PORTPARAMS (159)
+
+   o  option-len: 4
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 9]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+   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-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: 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.
+
+   Section 5.1 of [RFC7597] provides a full description of how the PSID
+   is interpreted by the client.
+
+   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).
+
+10.  Security Considerations
+
+   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]).
+
+   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.
+
+   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
+
+
+
+Cui, et al.                  Standards Track                   [Page 10]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+   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].
+
+   Additional security considerations are discussed in Section 10 of
+   [RFC7597] and Section 9 of [RFC7596].
+
+10.1.  Port Randomization
+
+   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]).
+
+   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).
+
+11.  IANA Considerations
+
+   IANA has assigned the following new DHCPv4 Option Code in the
+   registry maintained at
+   <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.
+
+12.  References
+
+12.1.  Normative References
+
+   [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>.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, DOI 10.17487/RFC2131, March 1997,
+              <http://www.rfc-editor.org/info/rfc2131>.
+
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 11]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+12.2.  Informative References
+
+   [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-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.
+
+
+
+Cui, et al.                  Standards Track                   [Page 12]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+   [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.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 13]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+Acknowledgements
+
+   This document is the result of merging [DHCP-Port-Set-Opt] and
+   [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.
+
+   Many thanks to Brian Haberman for the review.
+
+Authors' Addresses
+
+   Yong Cui
+   Tsinghua University
+   Beijing  100084
+   China
+
+   Phone: +86-10-62603059
+   Email: yong@csnet1.cs.tsinghua.edu.cn
+
+
+   Qi Sun
+   Tsinghua University
+   Beijing  100084
+   China
+
+   Phone: +86-10-62785822
+   Email: sunqi.ietf@gmail.com
+
+
+   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
+
+   Email: yiu_lee@cable.comcast.com
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 14]
+
+RFC 7618             Dynamic Shared IPv4 Allocation          August 2015
+
+
+   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
+
+   Email: mohamed.boucadair@orange.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 15]
+