GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7618

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7618.txt · Last modified: 2015/08/15 00:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki