draft-ietf-dhc-dynamic-shared-v4allocation-06.txt   draft-ietf-dhc-dynamic-shared-v4allocation-07.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 17, 2015 I. Farrer Expires: November 14, 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 15, 2015 May 13, 2015
Dynamic Allocation of Shared IPv4 Addresses Dynamic Allocation of Shared IPv4 Addresses
draft-ietf-dhc-dynamic-shared-v4allocation-06 draft-ietf-dhc-dynamic-shared-v4allocation-07
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 layer each client being differentiated by a unique set of transport layer
source port numbers. The necessary changes to existing DHCPv4 client source port numbers. The necessary changes to existing DHCPv4 client
and server behavior are described and a new DHCPv4 option for and 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.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 17, 2015. This Internet-Draft will expire on November 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 4 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 4
6. Client-Server Interaction . . . . . . . . . . . . . . . . . . 4 6. Client-Server Interaction . . . . . . . . . . . . . . . . . . 4
7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Restrictions to Client Usage of a Shared IPv4 Address . . 6 7.1. Restrictions to Client Usage of a Shared IPv4 Address . . 6
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Leasing Shared and Non-Shared IPv4 Addresses from a 8.1. Leasing Shared and Non-Shared IPv4 Addresses from a
Single DHCP 4o6 Server . . . . . . . . . . . . . . . . . 8 Single DHCP 4o6 Server . . . . . . . . . . . . . . . . . 8
9. DHCPv4 Port Parameters Option . . . . . . . . . . . . . . . . 8 9. DHCPv4 Port Parameters Option . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10.1. Denial-of-Service . . . . . . . . . . . . . . . . . . . 10 10.1. Port Randomization . . . . . . . . . . . . . . . . . . . 10
10.2. Port Randomization . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 11 13.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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
transported within a DHCPv6 message flow. This memo specifies a new transported within a DHCPv6 message flow. This memo specifies a new
DHCPv4 option: OPTION_V4_PORTPARAMS, and describes how it can be used DHCPv4 option: OPTION_V4_PORTPARAMS, and describes how it can be used
for the dynamic leasing of shared IPv4 addresses. for the dynamic leasing of shared IPv4 addresses.
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, if required. a DHCPv4 option may also be used in other solutions, if required.
2. Applicability Statement 2. Applicability Statement
This extension is only suitable for specific architectures based on The solution allows multiple hosts to be simultaneously allocated the
the Address plus Port model (A+P) [RFC6346] such as same IP address. As the IP address is no longer a unique identifier
[I-D.ietf-softwire-lw4over6] and certain configurations of for a host, this extension is only suitable for specific
architectures based on the Address plus Port model (A+P) [RFC6346]
such as [I-D.ietf-softwire-lw4over6] and certain configurations of
[I-D.ietf-softwire-map]. [I-D.ietf-softwire-map].
The solution should only be used on point-to-point links, tunnels, The solution should only be used on point-to-point links, tunnels,
and/or in environments where authentication at the link layer is and/or in environments where authentication at the link layer is
performed before IP address assignment. It is not suitable for performed before IP address assignment. It is not suitable for
network access over shared mediums. network access over shared mediums.
3. Requirements Language 3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 8 skipping to change at page 4, line 8
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. 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.
5. Functional Overview 5. Functional Overview
Functionally, the dynamic allocation of shared IPv4 addresses by the Functionally, the dynamic allocation of shared IPv4 addresses by the
DHCP 4o6 Server is similar to dynamic allocation process for 'full' DHCP 4o6 Server is similar to the dynamic allocation process for
IPv4 addresses described in [RFC2131]. The essential difference is 'full' IPv4 addresses described in [RFC2131]. The essential
that the DHCP 4o6 Server can allocate the same IPv4 address to more difference is that the DHCP 4o6 Server can allocate the same IPv4
than one DHCP 4o6 client simultaneously, providing that each shared address to more than one DHCP 4o6 client simultaneously, providing
address allocation also includes a range of layer 4 source ports that each shared address allocation also includes a range of layer 4
unique to that address (i.e., the combined tuple of IPv4 address and source ports unique to that address (i.e., the combined tuple of IPv4
Port Set ID is to be unique for each active lease). address and Port Set ID is to be unique for each active lease).
The DHCP 4o6 client implements OPTION_V4_PORTPARAMS (described The DHCP 4o6 client implements OPTION_V4_PORTPARAMS (described
below), which is a DHCPv4 option containing PSID (Port Set ID) below), which is a DHCPv4 option containing PSID (Port Set ID)
information. The client includes this option within the Parameter information. The client includes this option within the Parameter
Request List option [RFC2132] in its DHCPv4 DHCPDISCOVER and Request List option [RFC2132] in its DHCPv4 DHCPDISCOVER and
DHCPREQUEST messages, indicating its support for shared, dynamic DHCPREQUEST messages, indicating its support for shared, dynamic
address leasing to the DHCP 4o6 server. address leasing to the DHCP 4o6 server.
OPTION_V4_PORTPARAMS is also implemented by the server to identify OPTION_V4_PORTPARAMS is also implemented by the server to identify
clients that support shared, dynamic address leasing. With this clients that support shared, dynamic address leasing. With this
skipping to change at page 4, line 51 skipping to change at page 4, line 51
[RFC7341]. [RFC7341].
1. When the client constructs the DHCPv4 DHCPDISCOVER message to be 1. When the client constructs the 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 client identifier option (constructed as message MUST include the client identifier option (constructed as
per [RFC4361]) and the Parameter Request List (PRL) option with per [RFC4361]) and the Parameter Request List (PRL) option with
the code of OPTION_V4_PORTPARAMS. The client MAY insert an the code of OPTION_V4_PORTPARAMS. The client MAY insert an
OPTION_V4_PORTPARAMS with preferred values in related fields as a OPTION_V4_PORTPARAMS with preferred values in related fields as a
suggestion to the DHCP 4o6 Server. suggestion to the DHCP 4o6 Server.
2. DHCP 4o6 Servers that receive the DHCPDISCOVER message and 2. DHCP 4o6 Servers that receive the DHCPDISCOVER message and
support shared IPv4 addresses respond with a DHCPOFFER message as support shared IPv4 addresses respond with a DHCPOFFER message
usual with the shared IPv4 address in the 'yiaddr' field and MUST with the shared IPv4 address in the 'yiaddr' field and MUST add
add an OPTION_V4_PORTPARAMS option containing an available an OPTION_V4_PORTPARAMS option containing an available restricted
restricted port set. If the DHCPDISCOVER included an port set. If the DHCPDISCOVER included an OPTION_V4_PORTPARAMS
OPTION_V4_PORTPARAMS option containing a non-zero PSID-Len field, option containing a non-zero PSID-Len field, the DHCP 4o6 Server
the DHCP 4o6 Server MAY allocate a port set of the requested size MAY allocate a port set of the requested size to the client
to the client (depending on policy). The DHCPOFFER message is (depending on policy). The DHCPOFFER message is then
then encapsulated in the DHCPv4-response message and sent to the encapsulated in the DHCPv4-response message and sent to the
client. 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 one (e.g., based on the configuration parameters received, such
as the size of the offered port set). The client then sends a as 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 corresponding OPTION_V4_PORTPARAMS received in the DHCPOFFER the corresponding OPTION_V4_PORTPARAMS received in the DHCPOFFER
message. message.
4. The server identified in the DHCPREQUEST message creates a 4. The server identified in the DHCPREQUEST message creates a
binding for the client. The binding includes the client binding for the client. The binding includes the client
identifier, the IPv4 address and the PSID. These parameters are identifier, the IPv4 address and the PSID. These parameters are
skipping to change at page 5, line 35 skipping to change at page 5, line 35
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 leased network DHCPRELEASE message, the client MUST include the leased network
address and OPTION_V4_PORTPARAMS (with the allocated PSID) to address and OPTION_V4_PORTPARAMS (with the allocated PSID) to
identify the lease to be released. 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 logic described in Section 3.2 address and restricted port set, the logic described in Section 3.2
of [RFC2131] MUST be followed on the condition that the client's of [RFC2131] MUST be followed on the condition that the client's
source IPv6 address for DHCP 4o6 does not change. Note, this source IPv6 address for DHCP 4o6 does not change. Note, this
corresponds to INIT-REBOOT state defined in [RFC2131]. The client corresponds to the INIT-REBOOT state defined in [RFC2131]. The
MUST include the OPTION_V4_PORTPARAMS with the requested port set client MUST include the OPTION_V4_PORTPARAMS with the requested port
information in the message flow, which starts with a DHCPREQUEST set information in the message flow, which starts with a DHCPREQUEST
message. If the client's DHCP 4o6 IPv6 source address is changed for 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 any reason, the client MUST re-initiate the DHCP 4o6 shared-address
provisioning process by sending a DHCPDISCOVER message. provisioning process by sending a DHCPDISCOVER message.
7. Client Behavior 7. Client Behavior
A DHCP 4o6 client discovering for a shared IPv4 address MUST include A DHCP 4o6 client sending a DHCPDISCOVER message for a shared IPv4
the OPTION_V4_PORTPARAMS option code in the Parameter Request List address MUST include the OPTION_V4_PORTPARAMS option code in the
option. If a client has been successfully allocated an IPv4 address Parameter Request List option. If a client has been successfully
and PSID previously, the client MAY include in the DHCPDISCOVER allocated an IPv4 address and PSID previously, the client's
message the 'requested IP address' option along with an DHCPDISCOVER message MAY include the 'requested IP address' option
OPTION_V4_PORTPARAMS to request that a specific IPv4 address and PSID along with an OPTION_V4_PORTPARAMS to request that a specific IPv4
be re-assigned. Alternatively, the client MAY omit the 'requested IP address and PSID be re-assigned. Alternatively, the client MAY omit
address' option, but include an OPTION_V4_PORTPARAMS with a non-zero the 'requested IP address' option, but include an
value in only the PSID-Len field, as a hint to the server for the OPTION_V4_PORTPARAMS with a non-zero value in only the PSID-Len
preferred size of the port set. 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 A client that requests OPTION_V4_PORTPARAMS, but receives DHCPOFFER
and DHCPACK messages without OPTION_V4_PORTPARAMS SHOULD proceed as and DHCPACK messages without OPTION_V4_PORTPARAMS SHOULD proceed as
defined in [RFC7341] and configure a full IPv4 address with no defined in [RFC7341] and configure a full IPv4 address with no
address sharing (see Section 8.1 for the server's behavior). address sharing (see Section 8.1 for the server's behavior).
When receiving a DHCPACK message containing OPTION_V4_PORTPARAMS, the When receiving a DHCPACK message containing OPTION_V4_PORTPARAMS, the
client MUST use the received explicit PSID for configuring the client MUST use the received explicit PSID for configuring the
interface for which the DHCP 4o6 request was made. interface for which the DHCP 4o6 request was made.
skipping to change at page 9, line 45 skipping to change at page 9, line 45
[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 reserved by 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 ISPs, the former port-sets that contain well-known ports MUST NOT be
assigned unless the operator has explicitly configured otherwise assigned unless the operator has explicitly configured otherwise
(e.g., by allocating a full IPv4 address). (e.g., by allocating a full IPv4 address).
10. Security Considerations 10. Security Considerations
The security considerations in [RFC2131] and [RFC7341] are to be The security considerations described in [RFC2131] and [RFC7341] are
considered. Additional considerations are elaborated in the also potentially applicable to this solution. Unauthorised DHCP 4o6
following sub-sections. servers in the network could be used to stage an amplification attack
or to supply invalid configuration leading to service disruption.
10.1. Denial-of-Service The risks of these types of attacks can be reduced through the use of
unicast DHCP 4o6 message flows (enabled by supplying DHCP 4o6 server
unicast addresses within the OPTION_DHCP4_O_DHCP6_SERVER option).
The solution is vulnerable to DoS attacks when used on a shared A malicious user could attempt a DoS attack by requesting a large
medium or when access network authentication is not a prerequisite to number ofIPv4 address (or fractional address) and port sets
IP address assignment. Refer to Section 2 for the target use cases. allocations, exhausting the available addresses and port sets for
other clients. This can be mitigated through DHCP 4o6 address
allocation policy, limiting the number of simultaneously active IPv4
leases for clients whose request originate from each customer site.
10.2. Port Randomization 10.1. 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 client). The host can only randomize the ports space assigned to a client). 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 [RFC5961] to improve the robustness attacks should be used (e.g., use [RFC5961] to improve the robustness
 End of changes. 13 change blocks. 
46 lines changed or deleted 53 lines changed or added

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