draft-ietf-dhc-dynamic-shared-v4allocation-00.txt   draft-ietf-dhc-dynamic-shared-v4allocation-01.txt 
DHC WG Y. Cui DHC WG Y. Cui
Internet-Draft Q. Sun Internet-Draft Q. Sun
Intended status: Standards Track Tsinghua University Intended status: Standards Track Tsinghua University
Expires: October 6, 2014 I. Farrer Expires: January 2, 2015 I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
Y. Lee Y. Lee
Comcast Comcast
Q. Sun Q. Sun
China Telecom China Telecom
M. Boucadair M. Boucadair
France Telecom France Telecom
April 4, 2014 July 1, 2014
Dynamic Allocation of Shared IPv4 Addresses Dynamic Allocation of Shared IPv4 Addresses
draft-ietf-dhc-dynamic-shared-v4allocation-00 draft-ietf-dhc-dynamic-shared-v4allocation-01
Abstract Abstract
This memo describes the 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 to clients using DHCPv4. Address sharing allows a single IPv4
address to be allocated to multiple, active clients simultaneously, address to be allocated to multiple, active clients simultaneously,
each client being differentiated by a unique set of transport source each client being differentiated by a unique set of transport source
port numbers. The necessary changes to existing DHCPv4 client and port numbers. The necessary changes to existing DHCPv4 client and
server behavior are described and a new DHCPv4 option for server behavior are described and a new DHCPv4 option for
provisioning clients with shared IPv4 addresses is included. provisioning clients with shared IPv4 addresses is included.
Due to the nature of IP addresses sharing, some limitations to their Due to the nature of IP addresses sharing, some limitations to their
applicability are necessary. This memo describes these limitations applicability are necessary. This memo describes these limitations
and recommends suitable architectures and technologies where address and recommends suitable architectures and technologies where address
sharing may be utilized. sharing may be utilized.
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 RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 6, 2014. This Internet-Draft will expire on January 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Functional Overview . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Client-Server Interaction . . . . . . . . . . . . . . . . . . 4 4. Functional Overview . . . . . . . . . . . . . . . . . . . . . 3
5. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 5. Client-Server Interaction . . . . . . . . . . . . . . . . . . 4
5.1. Leasing Shared and Non-Shared IPv4 Addresses from a 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Leasing Shared and Non-Shared IPv4 Addresses from a
Single DHCP 4o6 Server . . . . . . . . . . . . . . . . . 6 Single DHCP 4o6 Server . . . . . . . . . . . . . . . . . 6
6. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Restrictions to Client Usage of a Shared IPv4 Address . . 7 7.1. Restrictions to Client Usage of a Shared IPv4 Address . . 7
7. DHCPv4 Port Parameters Option . . . . . . . . . . . . . . . . 7 8. DHCPv4 Port Parameters Option . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 9 9.1. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 9
8.2. Port Randomization . . . . . . . . . . . . . . . . . . . 9 9.2. Port Randomization . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The shortage of available public IPv4 addresses means that it is not The shortage of available public IPv4 addresses means that it is not
always possible for operators to allocate a full IPv4 address to always possible for operators to allocate a full IPv4 address to
every connected device. This problem is particularly acute whilst an every connected device. This problem is particularly acute whilst an
operator is migrating from their existing, native IPv4 network to a operator is migrating from their existing, native IPv4 network to a
native IPv6 network with IPv4 provided as an overlay service. During native IPv6 network with IPv4 provided as an overlay service. During
this phase, public IPv4 addresses are needed to provide for both this phase, public IPv4 addresses are needed to provide for both
existing and transition networks. existing and transition networks.
Two main types of solutions have emerged to address the problem (see Two main types of solutions have emerged to address the problem (see
Appendix A of [RFC6269]): Appendix A of [RFC6269]):
1. Deploying Carrier Grade Network devices (CGNs, [RFC6888]). 1. Deploying Carrier Grade Network Address Translation devices
(CGNAT, [RFC6888]).
2. Distributing the same public IPv4 address to multiple clients 2. Distributing the same public IPv4 address to multiple clients
using non-overlapping layer 4 port sets. differentiated by non-overlapping layer 4 port sets.
This memo focuses on the second category of solutions. This memo focuses on the second category of solutions.
[I-D.ietf-dhc-dhcpv4-over-dhcpv6] introduces a "DHCP 4o6 Server", [I-D.ietf-dhc-dhcpv4-over-dhcpv6] introduces a "DHCP 4o6 Server",
which is capable of servicing both DHCPv6 [RFC3315] and DHCPv4-over- which offers dynamic leasing for IPv4 addresses to clients as in
DHCPv6 requests, and offers dynamic leasing for IPv4 addresses to DHCPv4 [RFC2131] but transported within a DHCPv6 message flow. This
clients as in DHCPv4 [RFC2131]. This memo specifies a new DHCPv4 memo specifies a new DHCPv4 option: OPTION_V4_PORTPARAMS, and
option, called OPTION_V4_PORTPARAMS, and describes how it can be used describes how it can be used for the dynamic leasing of shared IPv4
to achieve dynamic leasing for shared IPv4 addresses. addresses.
This extension is only suitable for specific architectures based on This extension is only suitable for specific architectures based on
the Address plus Port model (A+P) [RFC6346]. the Address plus Port model (A+P) [RFC6346].
Although DHCPv4 over DHCPv6 is used as the underlying DHCPv4 Although DHCPv4 over DHCPv6 is used as the underlying DHCPv4
transport mechanism throughout this document, OPTION_V4_PORTPARAMS as transport mechanism throughout this document, OPTION_V4_PORTPARAMS as
a DHCPv4 option may also be used in other solutions such as DHCPv4 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 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. OPTION_V4_PORTPARAMS in these cases is out of scope of this document.
2. Functional Overview 2. Requirements Language
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
lease).
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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
to identify clients which support shared, dynamic address leasing. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
With this option, the server can dynamically maintain shared IPv4 document are to be interpreted as described in RFC 2119 [RFC2119].
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 3. Terminology
This document makes use of the following terms: This document makes use of the following terms:
Shared IPv4 address: An IPv4 address with a restricted layer 4 port Shared IPv4 address: An IPv4 address with a restricted layer 4 port
set. Connections sourced from the shared address set. Connections sourced from the shared
must use source ports within the assigned port address MUST use source ports within the
set. assigned port set.
Port Set ID (PSID): Identifier for a range of ports assigned to a Port Set ID (PSID): Identifier for a range of ports assigned to a
DHCP client. DHCP client.
4. Client-Server Interaction 4. Functional Overview
Using DHCPv4 over DHCPv6, the following DHCPv4 message flow is Functionally, the dynamic allocation of shared IPv4 addresses by the
transported within the DHCPv4-query and DHCPv4-response messages (the DHCP 4o6 Server is similar to dynamic allocation process for 'full'
DHCPv6 messages used for carrying DHCPv4 messages). 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 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 request, indicating its support for shared
IPv4 addressing to the DHCP 4o6 server.
OPTION_V4_PORTPARAMS is also implemented by the server to identify
clients which support shared, dynamic address leasing. With this
option, the server can dynamically allocate PSID to the client and
maintain shared IPv4 address leases. The server then manages unique
client leases based on both the IPv4 address and PSID tuple, instead
of using only the IPv4 address.
5. Client-Server Interaction
The following DHCPv4 message flow is transported within the
DHCPv4-query and DHCPv4-response messages as in DHCPv4 over DHCPv6
[I-D.ietf-dhc-dhcpv4-over-dhcpv6].
1. When the client constructs its DHCPv4 DHCPDISCOVER message to be 1. When the client constructs its DHCPv4 DHCPDISCOVER message to be
transported within the DHCPv4-query message, the DHCPDISCOVER transported within the DHCPv4-query message, the DHCPDISCOVER
message MUST include the following options: A client identifier message MUST include the client identifier option (constructed as
(constructed as per [RFC4361] and OPTION_V4_PORTPARAMS (described per [RFC4361] and the Parameter Request List (PRL) option with
below). The client MAY insert a non-zero value in the PSID-Len the code of OPTION_V4_PORTPARAMS. The client MAY insert an
field within OPTION_V4_PORTPARAMS to indicate the preferred size OPTION_V4_PORTPARAMS with a non-zero value in the PSID-Len field
of the restricted port set to the DHCP 4o6 Server. to indicate a preferred size for the restricted port set to the
2. Each DHCP 4o6 Server that receives the DHCPDISCOVER message DHCP 4o6 Server.
within the DHCPv4-query message and supports shared IPv4 2. DHCP 4o6 Servers that receive the DHCPDISCOVER message and
addresses responds with a DHCPOFFER message containing an support shared IPv4 addresses responds with a DHCPOFFER message
available IPv4 address in the 'yiaddr' field. The response MUST containing an IPv4 address in the 'yiaddr' field. The response
also include OPTION_V4_PORTPARAMS containing a restricted port MUST also include the OPTION_V4_PORTPARAMS option containing an
set. If the received OPTION_V4_PORTPARAMS field contains a non- available restricted port set. If the received
zero PSID-Len field, the DHCP 4o6 Server MAY allocate a port set OPTION_V4_PORTPARAMS field contains a non-zero PSID-Len field,
of the requested size to the client (depending on policy). The the DHCP 4o6 Server MAY allocate a port set of the requested size
DHCPOFFER message is included in the DHCPv4-response message and to the client (depending on policy). The DHCPOFFER message is
sent to the client. included in the DHCPv4-response message and sent to the client.
3. The client evaluates all received DHCPOFFER messages and selects 3. The client evaluates all received DHCPOFFER messages and selects
one (e.g. based on the configuration parameters received, such as one (e.g. based on the configuration parameters received, such as
the size of the offered port set). The client then sends a the size of the offered port set). The client then sends a
DHCPREQUEST encapsulated in the DHCPv4-query message, containing DHCPREQUEST encapsulated in the DHCPv4-query message, containing
the selected DHCP server's server identifier and the the selected DHCP server's server identifier and the
corresponding OPTION_V4_PORTPARAMS received in the DHCPOFFER corresponding OPTION_V4_PORTPARAMS received in the DHCPOFFER
message. message.
4. The server identified in the DHCPREQUEST message (via the siaddr 4. The server identified in the DHCPREQUEST message creates a
field) creates a binding for the client. The binding includes binding for the client. The binding includes the client
the client identifier, the IPv4 address and the PSID. These identifier, the IPv4 address and the PSID. These parameters are
parameters are used by both the server and the client to identify used by both the server and the client to identify a lease in any
a lease in any DHCP messages. The server responds with a DHCPACK DHCP messages. The server responds with a DHCPACK message
message containing the configuration parameters for the containing the configuration parameters for the requesting
requesting client. Optionally, the server MAY also store the client.
IPv6 address that the client has bound the received IPv4
parameters to.
5. On receipt of the DHCPACK message with the configuration 5. On receipt of the DHCPACK message with the configuration
parameters, the client MUST NOT perform a final check on the parameters, the client MUST NOT perform a final check on the
address, such as ARPing for a duplicate allocated address. address, such as ARPing for a duplicate allocated address.
6. If the client chooses to relinquish its lease by sending a 6. If the client chooses to relinquish its lease by sending a
DHCPRELEASE message, the client MUST include the original client DHCPRELEASE message, the client MUST include the original client
identifier, the leased network address and the allocated identifier, the leased network address and the
restricted port set in OPTION_V4_PORTPARAMS. OPTION_V4_PORTPARAMS containing the allocated port set to
identify the lease to be released.
In the case that the client has stored the previously allocated In the case that the client has stored the previously allocated
address and restricted port set, the process described in section 3.2 address and restricted port set, the process described in section 3.2
of [RFC2131] must be followed to reuse the previously allocated of [RFC2131] MUST be followed. The OPTION_V4_PORTPARAMS MUST be
shared IPv4 address. OPTION_V4_PORTPARAMS MUST be included in the included in the message flow, with the client's requested port set
message flow, with the client's requested port set being included in information being included in the DHCPDISCOVER message.
the DHCPDISCOVER message.
5. Server Behavior 6. Server Behavior
The DHCP 4o6 Server MUST NOT reply with the OPTION_V4_PORTPARAMS The DHCP 4o6 Server MUST NOT reply with the OPTION_V4_PORTPARAMS
until the client has explicitly listed the option code in the until the client has explicitly listed the option code in the
Parameter Request List (Option 55) [RFC2132]. Parameter Request List (Option 55) [RFC2132].
The DHCP 4o6 Server SHOULD reply with OPTION_V4_PORTPARAMS if the The DHCP 4o6 Server SHOULD reply with OPTION_V4_PORTPARAMS if the
client includes the OPTION_V4_PORTPARAMS in its Parameter Request client includes the OPTION_V4_PORTPARAMS in its Parameter Request
List. In order to achieve the dynamic management the shared IPv4 List. In order to achieve the dynamic management of shared IPv4
address, the server MUST run an address and port-set pool that addresses, the server MUST run an address and port-set pool that
provides the same function as the address pool in a regular DHCP provides the same function as the address pool in a regular DHCP
server. The server MUST use the combination of address and PSID as 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 the key for maintaining the state of a lease, and for searching for
an available lease for assignment. The leasing database MUST include an available lease for assignment. The leasing database MUST include
the IPv4 address, PSID and client identifier of the requesting the IPv4 address, PSID and client identifier of the requesting
client. client.
When a server receives a DHCPDISCOVER message with When a server receives a DHCPDISCOVER message with
OPTION_V4_PORTPARAMS in the Parameter Request List, the server OPTION_V4_PORTPARAMS in the Parameter Request List option, the server
determines an IPv4 address with a port-set for the requesting client. determines an IPv4 address with a PSID for the requesting client. If
The logic for selection is similar to that in Section 4.3.1 of an IPv4 address with a PSID is available, the server SHOULD follow
[RFC2131]. the logic below to select which specific address and PSID to
provision to the client. The logic is similar to that in
Section 4.3.1 of [RFC2131].
When the server receives a DHCPREQUEST message with o The client's current address with the PSID as recorded in the
OPTION_V4_PORTPARAMS, the server MUST determine the client's state client's current lease binding, ELSE
according to related parameters (Section 4.3.2 of [RFC2131]) and the o The client's previous address with PSID as recorded in the
value of OPTION_V4_PORTPARAMS. client's (expired or released) binding, if that address with the
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 in the OPTION_V4_PORTPARAMS, if the requested 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 Upon receipt of a DHCPRELEASE message with OPTION_V4_PORTPARAMS, the
server searches for the lease using the address in the 'ciaddr' field server searches for the lease using the address in the 'ciaddr' field
and the PSID information in the OPTION_V4_PORTPARAMS, and marks the and the PSID information in the OPTION_V4_PORTPARAMS, and marks the
lease as unallocated. lease as unallocated.
The port-set assignment MUST be coupled with the address assignment The port-set assignment MUST be coupled with the address assignment
process. Therefore server MUST assign the address and port set in process. Therefore server MUST assign the address and port set in
the same DHCP messages. The lease information for the address is the same DHCP messages. Lease information for the address is also
applicable to the port-set as well. applicable to the port-set.
When defining the pools of IPv4 addresses and PSIDs which are When defining the pools of IPv4 addresses and PSIDs which are
available to lease to clients, the server SHOULD implement a available to lease to clients, the server MUST implement a mechanism
mechanism to reserve some port ranges (e.g. 'well-known-ports' to reserve some port ranges (e.g. 'well-known-ports' 0-1023) from
0-1023) from allocation to clients. allocation to clients. The reservation policy SHOULD be
configurable.
5.1. Leasing Shared and Non-Shared IPv4 Addresses from a Single DHCP 6.1. Leasing Shared and Non-Shared IPv4 Addresses from a Single DHCP
4o6 Server 4o6 Server
A single DHCP 4o6 server may serve clients that do not support 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 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 allocation of shared addresses differ from the rules for full IPv4
address assignment, the DHCP 4o6 server MUST implement a mechanism to address assignment, the DHCP 4o6 server MUST implement a mechanism to
ensure that clients which do not support OPTION_PORTPARAMS do not ensure that clients not supporting OPTION_V4_PORTPARAMS do not
receive shared addresses. For example, two separate IPv4 addressing receive shared addresses. For example, two separate IPv4 addressing
pools could be used, one of which allocates IPv4 addresses and PSIDs pools could be used, one of which allocates IPv4 addresses and PSIDs
only to clients that have requested them. only to clients that have requested them.
If the server is only configured one address pool for shared address If the server is only configured with address pools for shared
allocation, it MUST discard requests that do not contain address allocation, it MUST discard requests that do not contain
OPTION_V4_PORTPARAMS in the Parameter Request List option. OPTION_V4_PORTPARAMS in the Parameter Request List option.
6. Client Behavior 7. Client Behavior
The DHCP 4o6 client applying for a shared IPv4 address MUST include The DHCP 4o6 client applying for a shared IPv4 address MUST include
the OPTION_V4_PORTPARAMS code in the Parameter Request List (Option the OPTION_V4_PORTPARAMS code in the Parameter Request List option.
55). The client retrieves a port set using the value contained in The client retrieves a port set using the values contained in
OPTION_V4_PORTPARAMS. OPTION_V4_PORTPARAMS. The client MAY use a non-zero value for the
PSID-len field within OPTION_PORTPARMAS in the DHCPDISCOVER message,
for requesting a specific size of port set.
The client MAY use a non-zero value for the PSID-len field within A client that requests OPTION_V4_PORTPARAMS, but receives DHCPOFFER
OPTION_PORTPARMAS in the DHCPDISCOVER message. This is used to and DHCPACK messages without OPTION_V4_PORTPARAMS SHOULD proceed as
request a specific size of port-set (i.e., the number of source ports defined in [I-D.ietf-dhc-dhcpv4-over-dhcpv6] and configure a full
that it will be allocated). IPv4 address with no address sharing.
The client MUST NOT probe a newly received IPv4 address (e.g., with When receiving a DHCPACK message containing OPTION_V4_PORTPARAMS, the
client MUST use the receivd 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. ARP) to see if it is in use by another host.
When the client renews or releases the DHCP lease, it MUST put the When the client renews or releases its DHCP lease, it MUST put the
values of offset, PSID length and PSID into the OPTION_V4_PORTPARAMS, values of offset, PSID length and PSID into OPTION_V4_PORTPARAMS, and
and send to the server within corresponding DHCPv4 messages that are send it to the server within corresponding DHCPv4 messages that are
conveyed through DHCPv4-query message. conveyed through DHCPv4-query message.
6.1. Restrictions to Client Usage of a Shared IPv4 Address 7.1. Restrictions to Client Usage of a Shared IPv4 Address
As a single IPv4 address is being shared between a number of As a single IPv4 address is being shared between a number of
different clients, the allocated shared address is only suitable for different clients, the allocated shared address is only suitable for
certain uses. The client MUST implement a function to ensure that certain uses. The client MUST implement a function to ensure that
only the allocated layer 4 ports of the shared IPv4 address are used only the allocated layer 4 ports of the shared IPv4 address are used
for sourcing new connections, or accepting inbound connections. for sourcing new connections, or accepting inbound connections.
The client MUST apply the following rules for any traffic to or from The client MUST apply the following rules for any traffic to or from
the shared IPv4 address: the shared IPv4 address:
skipping to change at page 7, line 40 skipping to change at page 8, line 5
used. used.
o All connections originating from the shared IPv4 address MUST use o All connections originating from the shared IPv4 address MUST use
a source port taken from the allocated restricted port set. a source port taken from the allocated restricted port set.
o The client MUST NOT accept inbound connections on ports outside of o The client MUST NOT accept inbound connections on ports outside of
the allocated restricted port set. the allocated restricted port set.
In order to prevent addressing conflicts which could arise from the In order to prevent addressing conflicts which could arise from the
allocation of the same IPv4 address, the client MUST NOT configure allocation of the same IPv4 address, the client MUST NOT configure
the received restricted IPv4 address on-link. the received restricted IPv4 address on-link.
The mechanism by which a client implements the above rules is outside The mechanism by which a client implements the above rules is out of
of the scope of this document. the scope of this document.
In the event that the DHCPv4 over DHCPv6 configuration mechanism In the event that the DHCPv4 over DHCPv6 configuration mechanism
fails for any reason, the client MUST NOT configure an IPv4 link- fails for any reason, the client MUST NOT configure an IPv4 link-
local address [RFC3927](taken from the 169.254.0.0/16 range). local address [RFC3927](taken from the 169.254.0.0/16 range).
7. DHCPv4 Port Parameters Option 8. DHCPv4 Port Parameters Option
The Port Parameters Option for DHCPv4 is specified to convey the The Port Parameters Option for DHCPv4 is specified to convey the
restricted set of layer 4 source ports that are necessary to restricted set of layer 4 source ports that are necessary to
dynamically allocate a shared address. The option uses the same dynamically allocate a shared address. The option uses the same
fields as the Port Parameters Option described in Section 4.5 of fields as the S46 Port Parameters Option described in Section 4.5 of
[I-D.ietf-softwire-map-dhcp], implemented as a DHCPv4 option. This [I-D.ietf-softwire-map-dhcp], implemented as a DHCPv4 option. This
is to maintain compatibility with existing port set implementations. is to maintain compatibility with existing port set implementations.
The format of OPTION_V4_PORTPARAMS is shown in Figure 1. The format of OPTION_V4_PORTPARAMS is shown in Figure 1.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| option-code | Length | | option-code | option-len |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| offset | PSID-Len | | offset | PSID-len |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PSID | | PSID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 1: DHCPv4 Port Parameters Option Figure 1: DHCPv4 Port Parameters Option
o option-code: OPTION_V4_PORTPARAMS (TBA) o option-code: OPTION_V4_PORTPARAMS (TBA)
o option-length: 4 o option-len: 4
o offset: (PSID offset) 8 bits long field that specifies the numeric o offset: (PSID offset) 8 bits long field that specifies the numeric
value for the excluded port range/offset bits (A-bits), as per value for the excluded port range/offset bits (A-bits), as per
section 5.1 of [I-D.ietf-softwire-map]. Allowed values are 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 between 0 and 15, with the default value being 6 for MAP based
implementations. This parameter is unused by a Lightweight 4over6 implementations. This parameter is unused by a Lightweight 4over6
client and should be set to 0. client and should be set to 0.
o PSID-Len: Bit length value of the number of significant bits in 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 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 is to be ignored. After the first 'a' bits, there are k bits in
the port number representing valid of PSID. Subsequently, the the port number representing valid of PSID. Subsequently, the
address sharing ratio would be 2^k. address sharing ratio would be 2^k.
o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value
algorithmically identifies a set of ports assigned to a CE. The 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. 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. The remaining (16-k) bits on the right are padding zeros.
[I-D.ietf-softwire-map] Section 5.1 provides a full description of [I-D.ietf-softwire-map] Section 5.1 provides a full description of
how the PSID is interpreted by the client. how the PSID is interpreted by the client.
In order to exclude the system ports ([RFC6335]) or ports saved by In order to exclude the system ports ([RFC6335]) or ports saved by
ISPs, the former port-sets that contain well-known ports SHOULD NOT ISPs, the former port-sets that contain well-known ports SHOULD NOT
be assigned. be assigned.
When receiving the Port Parameters option with an explicit PSID, the 9. Security Considerations
client MUST use this explicit PSID in configuring its DHCPv4 over
DHCPv6 interface.
8. Security Considerations
The security considerations in [RFC2131] and The security considerations in [RFC2131] and
[I-D.ietf-dhc-dhcpv4-over-dhcpv6] are to be considered. Additional [I-D.ietf-dhc-dhcpv4-over-dhcpv6] are to be considered. Additional
considerations are elaborated in the following sub-sections. considerations are elaborated in the following sub-sections.
8.1. Denial-of-Service 9.1. Denial-of-Service
The solution is vulnerable to DoS attacks when used on a shared The solution is vulnerable to DoS attacks when used on a shared
medium or when access network authentication is not a prerequisite to medium or when access network authentication is not a prerequisite to
IP address assignment. The solution SHOULD only be used on point-to- IP address assignment. The solution SHOULD only be used on point-to-
point links, tunnels, and/or in environments where authentication at point links, tunnels, and/or in environments where authentication at
the link layer is performed before IP address assignment. It is not the link layer is performed before IP address assignment. It is not
suitable for network access over shared mediums. suitable for network access over shared mediums.
8.2. Port Randomization 9.2. Port Randomization
Preserving port randomization [RFC6056] may be more or less difficult Preserving port randomization [RFC6056] may be more or less difficult
depending on the address sharing ratio (i.e., the size of the port 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 space assigned to a CPE). The host can only randomize the ports
inside a fixed port range [RFC6269]. inside a fixed port range [RFC6269].
More discussion to improve the robustness of TCP against Blind In- More discussion to improve the robustness of TCP against Blind In-
Window Attacks can be found at [RFC5961]. Other means than the Window Attacks can be found at [RFC5961]. Other means than the
(IPv4) source port randomization to provide protection against (IPv4) source port randomization to provide protection against
attacks should be used (e.g., use [I-D.vixie-dnsext-dns0x20] to attacks should be used (e.g., use [I-D.vixie-dnsext-dns0x20] to
protect against DNS attacks, [RFC5961] to improve the robustness of protect against DNS attacks, [RFC5961] to improve the robustness of
TCP against Blind In-Window Attacks, use IPv6). TCP against Blind In-Window Attacks, use IPv6).
A proposal to preserve the entropy when selecting port is discussed A proposal to preserve the entropy when selecting port is discussed
in [I-D.bajko-pripaddrassign]. in [I-D.bajko-pripaddrassign].
9. IANA Considerations 10. IANA Considerations
IANA is requested to assign the following new DHCPv4 Option Code in IANA is requested to assign the following new DHCPv4 Option Code in
the registry maintained in http://www.iana.org/assignments/bootp- the registry maintained in http://www.iana.org/assignments/bootp-
dhcp-parameters/: dhcp-parameters/:
Option Name Value Data Meaning Option Name Value Data Meaning
length length
-------------------- ----- ------ ----------------------------------- -------------------- ----- ------ -----------------------------------
OPTION_V4_PORTPARAMS TBA 4 This option is used to configure a OPTION_V4_PORTPARAMS TBA 4 This option is used to configure a
set of ports bound to a shared IPv4 set of ports bound to a shared IPv4
address. address.
10. Acknowledgements 11. Acknowledgements
This document is merged from [I-D.sun-dhc-port-set-option] and This document is merged from [I-D.sun-dhc-port-set-option] and
[I-D.farrer-dhc-shared-address-lease]. [I-D.farrer-dhc-shared-address-lease].
The authors would like to thank Peng Wu, Gabor Bajko, Teemu The authors would like to thank Peng Wu, Gabor Bajko, Teemu
Savolainen, Ted Lemon, Tina Tsou, Pierre Levis, Cong Liu for Marcin Savolainen, Ted Lemon, Tina Tsou, Pierre Levis, Cong Liu and Marcin
Siodelski, for their contribution to this work. Siodelski, for their contributions to this work.
11. References 12. References
11.1. Normative References 12.1. Normative References
[I-D.ietf-dhc-dhcpv4-over-dhcpv6] [I-D.ietf-dhc-dhcpv4-over-dhcpv6]
Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
dhcpv4-over-dhcpv6-06 (work in progress), February 2014. dhcpv4-over-dhcpv6-09 (work in progress), June 2014.
[I-D.ietf-softwire-map] [I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-10 with Encapsulation (MAP)", draft-ietf-softwire-map-10
(work in progress), January 2014. (work in progress), January 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 11, line 5 skipping to change at page 11, line 13
2010. 2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, January Protocol Port Randomization", BCP 156, RFC 6056, January
2011. 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269, June Roberts, "Issues with IP Address Sharing", RFC 6269, June
2011. 2011.
11.2. Informative References 12.2. Informative References
[I-D.bajko-pripaddrassign] [I-D.bajko-pripaddrassign]
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
"Port Restricted IP Address Assignment", draft-bajko- "Port Restricted IP Address Assignment", draft-bajko-
pripaddrassign-04 (work in progress), April 2012. pripaddrassign-04 (work in progress), April 2012.
[I-D.farrer-dhc-shared-address-lease] [I-D.farrer-dhc-shared-address-lease]
Farrer, I., "Dynamic Allocation of Shared IPv4 Addresses Farrer, I., "Dynamic Allocation of Shared IPv4 Addresses
using DHCPv4 over DHCPv6", draft-farrer-dhc-shared- using DHCPv4 over DHCPv6", draft-farrer-dhc-shared-
address-lease-00 (work in progress), June 2013. address-lease-00 (work in progress), June 2013.
[I-D.ietf-dhc-dhcpv4-over-ipv6] [I-D.ietf-dhc-dhcpv4-over-ipv6]
Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4 Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4
over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-08 over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-09
(work in progress), October 2013. (work in progress), April 2014.
[I-D.ietf-softwire-lw4over6] [I-D.ietf-softwire-lw4over6]
Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
I. Farrer, "Lightweight 4over6: An Extension to the DS- I. Farrer, "Lightweight 4over6: An Extension to the DS-
Lite Architecture", draft-ietf-softwire-lw4over6-08 (work Lite Architecture", draft-ietf-softwire-lw4over6-10 (work
in progress), March 2014. in progress), June 2014.
[I-D.ietf-softwire-map-dhcp] [I-D.ietf-softwire-map-dhcp]
Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng, W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng,
"DHCPv6 Options for configuration of Softwire Address and "DHCPv6 Options for configuration of Softwire Address and
Port Mapped Clients", draft-ietf-softwire-map-dhcp-07 Port Mapped Clients", draft-ietf-softwire-map-dhcp-07
(work in progress), March 2014. (work in progress), March 2014.
[I-D.sun-dhc-port-set-option] [I-D.sun-dhc-port-set-option]
Qiong, Q., Lee, Y., Sun, Q., Bajko, G., and M. Boucadair, Qiong, Q., Lee, Y., Sun, Q., Bajko, G., and M. Boucadair,
skipping to change at page 12, line 27 skipping to change at page 12, line 35
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common Requirements for Carrier-Grade NATs and H. Ashida, "Common Requirements for Carrier-Grade NATs
(CGNs)", BCP 127, RFC 6888, April 2013. (CGNs)", BCP 127, RFC 6888, April 2013.
Authors' Addresses Authors' Addresses
Yong Cui Yong Cui
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R. China
Phone: +86-10-6260-3059 Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn Email: yong@csnet1.cs.tsinghua.edu.cn
Qi Sun Qi Sun
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R. China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: sunqi@csnet1.cs.tsinghua.edu.cn Email: sunqi@csnet1.cs.tsinghua.edu.cn
Ian Farrer Ian Farrer
Deutsche Telekom AG Deutsche Telekom AG
CTO-ATI, Landgrabenweg 151 CTO-ATI, Landgrabenweg 151
Bonn, NRW 53227 Bonn, NRW 53227
Germany Germany
Email: ian.farrer@telekom.de Email: ian.farrer@telekom.de
Yiu L. Lee Yiu L. Lee
Comcast Comcast
One Comcast Center One Comcast Center
Philadelphia PA 19103 Philadelphia PA 19103
USA USA
Email: yiu_lee@cable.comcast.com Email: yiu_lee@cable.comcast.com
Qiong Sun Qiong Sun
China Telecom China Telecom
skipping to change at page 13, line 16 skipping to change at page 13, line 24
One Comcast Center One Comcast Center
Philadelphia PA 19103 Philadelphia PA 19103
USA USA
Email: yiu_lee@cable.comcast.com Email: yiu_lee@cable.comcast.com
Qiong Sun Qiong Sun
China Telecom China Telecom
Room 708, No.118, Xizhimennei Street Room 708, No.118, Xizhimennei Street
Beijing 100035 Beijing 100035
P.R.China P.R. China
Phone: +86-10-58552936 Phone: +86-10-58552936
Email: sunqiong@ctbri.com.cn Email: sunqiong@ctbri.com.cn
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
2330 Central Expressway 2330 Central Expressway
Rennes 35000 Rennes 35000
France France
 End of changes. 59 change blocks. 
163 lines changed or deleted 172 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/