Skip to main content

Dynamic Allocation of Shared IPv4 Addresses

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7618.
Authors Yong Cui , Qiong Sun , Ian Farrer , Yiu Lee , Qi Sun , Mohamed Boucadair
Last updated 2014-04-04
Replaces draft-csf-dhc-dynamic-shared-v4allocation
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7618 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
DHC WG                                                            Y. Cui
Internet-Draft                                                    Q. Sun
Intended status: Standards Track                     Tsinghua University
Expires: October 6, 2014                                       I. Farrer
                                                     Deutsche Telekom AG
                                                                  Y. Lee
                                                                  Q. Sun
                                                           China Telecom
                                                            M. Boucadair
                                                          France Telecom
                                                           April 4, 2014

              Dynamic Allocation of Shared IPv4 Addresses


   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,
   each client being differentiated by a unique set of transport 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 addresses sharing, some limitations to their
   applicability are necessary.  This memo describes these limitations
   and recommends suitable architectures and technologies where address
   sharing may be utilized.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

Cui, et al.              Expires October 6, 2014                [Page 1]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 6, 2014.

Copyright Notice

   Copyright (c) 2014 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
   ( 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.  Functional Overview . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Client-Server Interaction . . . . . . . . . . . . . . . . . .   4
   5.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Leasing Shared and Non-Shared IPv4 Addresses from a
           Single DHCP 4o6 Server  . . . . . . . . . . . . . . . . .   6
   6.  Client Behavior . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Restrictions to Client Usage of a Shared IPv4 Address . .   7
   7.  DHCPv4 Port Parameters Option . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     8.1.  Denial-of-Service . . . . . . . . . . . . . . . . . . . .   9
     8.2.  Port Randomization  . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

Cui, et al.              Expires October 6, 2014                [Page 2]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

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 whilst 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 devices (CGNs, [RFC6888]).
   2.  Distributing the same public IPv4 address to multiple clients
       using non-overlapping layer 4 port sets.

   This memo focuses on the second category of solutions.

   [I-D.ietf-dhc-dhcpv4-over-dhcpv6] introduces a "DHCP 4o6 Server",
   which is capable of servicing both DHCPv6 [RFC3315] and DHCPv4-over-
   DHCPv6 requests, and offers dynamic leasing for IPv4 addresses to
   clients as in DHCPv4 [RFC2131].  This memo specifies a new DHCPv4
   option, called OPTION_V4_PORTPARAMS, and describes how it can be used
   to achieve dynamic leasing for shared IPv4 addresses.

   This extension is only suitable for specific architectures based on
   the Address plus Port model (A+P) [RFC6346].

   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 such as DHCPv4
   over IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6].  The usage of
   OPTION_V4_PORTPARAMS in these cases is out of scope of this document.

2.  Functional Overview

   Functionally, the dynamic allocation of shared IPv4 addresses by the
   DHCP 4o6 Server is similar to the DHCPv4 server dynamic allocation
   process for 'full' IPv4 addresses described in [RFC2131].  The
   essential difference is that the DHCP 4o6 Server MAY 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 MUST be unique for each active

Cui, et al.              Expires October 6, 2014                [Page 3]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

   The DHCP 4o6 client inlcudes OPTION_V4_PORTPARAMS (described below)
   within the Parameter Request List option [RFC2132] in the
   DHCPDISCOVER message to indicate to the DHCP 4o6 server that it
   supports shared IPv4 addressing.  OPTION_V4_PORTPARAMS is also used
   by the server to convey the allocated PSID to the client.

   OPTION_V4_PORTPARAMS is also implemented by the server to enable it
   to identify clients which support shared, dynamic address leasing.
   With this option, the server can dynamically maintain shared IPv4
   address leases.  The server must also manage unique client leases
   based on both the IPv4 address and PSID tuple, instead of using only
   the IPv4 address.

3.  Terminology

   This document makes use of the following terms:

   Shared IPv4 address:  An IPv4 address with a restricted layer 4 port
                       set.  Connections sourced from the shared address
                       must use source ports within the assigned port
   Port Set ID (PSID): Identifier for a range of ports assigned to a
                       DHCP client.

4.  Client-Server Interaction

   Using DHCPv4 over DHCPv6, the following DHCPv4 message flow is
   transported within the DHCPv4-query and DHCPv4-response messages (the
   DHCPv6 messages used for carrying DHCPv4 messages).

   1.  When the client constructs its DHCPv4 DHCPDISCOVER message to be
       transported within the DHCPv4-query message, the DHCPDISCOVER
       message MUST include the following options: A client identifier
       (constructed as per [RFC4361] and OPTION_V4_PORTPARAMS (described
       below).  The client MAY insert a non-zero value in the PSID-Len
       field within OPTION_V4_PORTPARAMS to indicate the preferred size
       of the restricted port set to the DHCP 4o6 Server.
   2.  Each DHCP 4o6 Server that receives the DHCPDISCOVER message
       within the DHCPv4-query message and supports shared IPv4
       addresses responds with a DHCPOFFER message containing an
       available IPv4 address in the 'yiaddr' field.  The response MUST
       also include OPTION_V4_PORTPARAMS containing a restricted port
       set.  If the received OPTION_V4_PORTPARAMS field contains 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 included in the DHCPv4-response message and
       sent to the client.

Cui, et al.              Expires October 6, 2014                [Page 4]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

   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 selected DHCP server's server identifier and the
       corresponding OPTION_V4_PORTPARAMS received in the DHCPOFFER
   4.  The server identified in the DHCPREQUEST message (via the siaddr
       field) 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 messages.  The server responds with a DHCPACK
       message containing the configuration parameters for the
       requesting client.  Optionally, the server MAY also store the
       IPv6 address that the client has bound the received IPv4
       parameters to.
   5.  On receipt of the DHCPACK message with the configuration
       parameters, the client MUST NOT perform a final check 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 original client
       identifier, the leased network address and the allocated
       restricted port set in OPTION_V4_PORTPARAMS.

   In the case that the client has stored the previously allocated
   address and restricted port set, the process described in section 3.2
   of [RFC2131] must be followed to reuse the previously allocated
   shared IPv4 address.  OPTION_V4_PORTPARAMS MUST be included in the
   message flow, with the client's requested port set being included in
   the DHCPDISCOVER message.

5.  Server Behavior

   The DHCP 4o6 Server MUST NOT reply with the OPTION_V4_PORTPARAMS
   until 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 the OPTION_V4_PORTPARAMS in its Parameter Request
   List.  In order to achieve the dynamic management the shared IPv4
   address, the server MUST run an address and port-set pool that
   provides the same function as the address pool in a regular DHCP
   server.  The server MUST use 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 MUST include
   the IPv4 address, PSID and client identifier of the requesting

Cui, et al.              Expires October 6, 2014                [Page 5]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

   When a server receives a DHCPDISCOVER message with
   OPTION_V4_PORTPARAMS in the Parameter Request List, the server
   determines an IPv4 address with a port-set for the requesting client.
   The logic for selection is similar to that in Section 4.3.1 of

   When the server receives a DHCPREQUEST message with
   OPTION_V4_PORTPARAMS, the server MUST determine the client's state
   according to related parameters (Section 4.3.2 of [RFC2131]) and the

   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.

   The port-set assignment MUST be coupled with the address assignment
   process.  Therefore server MUST assign the address and port set in
   the same DHCP messages.  The lease information for the address is
   applicable to the port-set as well.

   When defining the pools of IPv4 addresses and PSIDs which are
   available to lease to clients, the server SHOULD implement a
   mechanism to reserve some port ranges (e.g. 'well-known-ports'
   0-1023) from allocation to clients.

5.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_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 which do not support OPTION_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 one address pool for shared address
   allocation, it MUST discard requests that do not contain
   OPTION_V4_PORTPARAMS in the Parameter Request List option.

6.  Client Behavior

   The DHCP 4o6 client applying for a shared IPv4 address MUST include
   the OPTION_V4_PORTPARAMS code in the Parameter Request List (Option
   55).  The client retrieves a port set using the value contained in

Cui, et al.              Expires October 6, 2014                [Page 6]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

   The client MAY use a non-zero value for the PSID-len field within
   OPTION_PORTPARMAS in the DHCPDISCOVER message.  This is used to
   request a specific size of port-set (i.e., the number of source ports
   that it will be allocated).

   The client MUST NOT probe a newly received IPv4 address (e.g., with
   ARP) to see if it is in use by another host.

   When the client renews or releases the DHCP lease, it MUST put the
   values of offset, PSID length and PSID into the OPTION_V4_PORTPARAMS,
   and send to the server within corresponding DHCPv4 messages that are
   conveyed through DHCPv4-query message.

6.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 any traffic to or from
   the shared IPv4 address:

   o  Only port-aware protocols or ICMP implementing [RFC5508] MUST be
   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 which could arise from the
   allocation of the same IPv4 address, the client MUST NOT configure
   the received restricted IPv4 address on-link.

   The mechanism by which a client implements the above rules is outside
   of the scope of 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 range).

7.  DHCPv4 Port Parameters Option

   The Port Parameters Option for DHCPv4 is specified to convey the
   restricted set of layer 4 source ports that are necessary to
   dynamically allocate a shared address.  The option uses the same
   fields as the Port Parameters Option described in Section 4.5 of

Cui, et al.              Expires October 6, 2014                [Page 7]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

   [I-D.ietf-softwire-map-dhcp], implemented as a DHCPv4 option.  This
   is to maintain 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      |        Length         |
                |         offset        |       PSID-Len        |
                |                     PSID                      |

                  Figure 1: DHCPv4 Port Parameters Option

   o  option-code: OPTION_V4_PORTPARAMS (TBA)
   o  option-length: 4
   o  offset: (PSID offset) 8 bits long field that specifies the numeric
      value for the excluded port range/offset bits (A-bits), as per
      section 5.1 of [I-D.ietf-softwire-map].  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 valid 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 CE.  The
      first k-bits on the left of this 2-octets field is the PSID value.
      The remaining (16-k) bits on the right are padding zeros.

   [I-D.ietf-softwire-map] Section 5.1 provides a full description of
   how the PSID is interpreted by the client.

   In order to exclude the system ports ([RFC6335]) or ports saved by
   ISPs, the former port-sets that contain well-known ports SHOULD NOT
   be assigned.

   When receiving the Port Parameters option with an explicit PSID, the
   client MUST use this explicit PSID in configuring its DHCPv4 over
   DHCPv6 interface.

Cui, et al.              Expires October 6, 2014                [Page 8]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

8.  Security Considerations

   The security considerations in [RFC2131] and
   [I-D.ietf-dhc-dhcpv4-over-dhcpv6] are to be considered.  Additional
   considerations are elaborated in the following sub-sections.

8.1.  Denial-of-Service

   The solution is vulnerable to DoS attacks when used on a shared
   medium or when access network authentication is not a prerequisite to
   IP address assignment.  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 mediums.

8.2.  Port Randomization

   Preserving port randomization [RFC6056] may be more or less difficult
   depending on the address sharing ratio (i.e., the size of the port
   space assigned to a CPE).  The host can only randomize the ports
   inside a fixed port range [RFC6269].

   More discussion to improve the robustness of TCP against Blind In-
   Window Attacks can be found at [RFC5961].  Other means than the
   (IPv4) source port randomization to provide protection against
   attacks should be used (e.g., use [I-D.vixie-dnsext-dns0x20] to
   protect against DNS attacks, [RFC5961] to improve the robustness of
   TCP against Blind In-Window Attacks, use IPv6).

   A proposal to preserve the entropy when selecting port is discussed
   in [I-D.bajko-pripaddrassign].

9.  IANA Considerations

   IANA is requested to assign the following new DHCPv4 Option Code in
   the registry maintained in

            Option Name Value Data   Meaning
   -------------------- ----- ------ -----------------------------------
   OPTION_V4_PORTPARAMS TBA   4      This option is used to configure a
                                     set of ports bound to a shared IPv4

Cui, et al.              Expires October 6, 2014                [Page 9]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

10.  Acknowledgements

   This document is merged from [I-D.sun-dhc-port-set-option] and

   The authors would like to thank Peng Wu, Gabor Bajko, Teemu
   Savolainen, Ted Lemon, Tina Tsou, Pierre Levis, Cong Liu for Marcin
   Siodelski, for their contribution to this work.

11.  References

11.1.  Normative References

              Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
              Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
              dhcpv4-over-dhcpv6-06 (work in progress), February 2014.

              Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, "Mapping of Address and Port
              with Encapsulation (MAP)", draft-ietf-softwire-map-10
              (work in progress), January 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC4361]  Lemon, T. and B. Sommerfeld, "Node-specific Client
              Identifiers for Dynamic Host Configuration Protocol
              Version Four (DHCPv4)", RFC 4361, February 2006.

   [RFC5961]  Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
              Robustness to Blind In-Window Attacks", RFC 5961, August

   [RFC6056]  Larsen, M. and F. Gont, "Recommendations for Transport-
              Protocol Port Randomization", BCP 156, RFC 6056, January

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269, June

Cui, et al.              Expires October 6, 2014               [Page 10]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

11.2.  Informative References

              Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
              "Port Restricted IP Address Assignment", draft-bajko-
              pripaddrassign-04 (work in progress), April 2012.

              Farrer, I., "Dynamic Allocation of Shared IPv4 Addresses
              using DHCPv4 over DHCPv6", draft-farrer-dhc-shared-
              address-lease-00 (work in progress), June 2013.

              Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4
              over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-08
              (work in progress), October 2013.

              Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
              I. Farrer, "Lightweight 4over6: An Extension to the DS-
              Lite Architecture", draft-ietf-softwire-lw4over6-08 (work
              in progress), March 2014.

              Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
              W., Bao, C.,, l., and X. Deng,
              "DHCPv6 Options for configuration of Softwire Address and
              Port Mapped Clients", draft-ietf-softwire-map-dhcp-07
              (work in progress), March 2014.

              Qiong, Q., Lee, Y., Sun, Q., Bajko, G., and M. Boucadair,
              "Dynamic Host Configuration Protocol (DHCP) Option for
              Port Set Assignment", draft-sun-dhc-port-set-option-02
              (work in progress), October 2013.

              Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to
              Improve Transaction Identity", draft-vixie-dnsext-
              dns0x20-00 (work in progress), March 2008.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927, May

Cui, et al.              Expires October 6, 2014               [Page 11]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

   [RFC5508]  Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
              Behavioral Requirements for ICMP", BCP 148, RFC 5508,
              April 2009.

   [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, August 2011.

   [RFC6346]  Bush, R., "The Address plus Port (A+P) Approach to the
              IPv4 Address Shortage", RFC 6346, August 2011.

   [RFC6888]  Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common Requirements for Carrier-Grade NATs
              (CGNs)", BCP 127, RFC 6888, April 2013.

Authors' Addresses

   Yong Cui
   Tsinghua University
   Beijing  100084

   Phone: +86-10-6260-3059

   Qi Sun
   Tsinghua University
   Beijing  100084

   Phone: +86-10-6278-5822

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


Cui, et al.              Expires October 6, 2014               [Page 12]
Internet-Draft       Dynamic Shared IPv4 Allocation           April 2014

   Yiu L. Lee
   One Comcast Center
   Philadelphia  PA 19103


   Qiong Sun
   China Telecom
   Room 708, No.118, Xizhimennei Street
   Beijing  100035

   Phone: +86-10-58552936

   Mohamed Boucadair
   France Telecom
   2330 Central Expressway
   Rennes  35000


Cui, et al.              Expires October 6, 2014               [Page 13]