draft-ietf-dhc-dynamic-shared-v4allocation-03.txt   draft-ietf-dhc-dynamic-shared-v4allocation-04.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: August 2, 2015 I. Farrer Expires: August 20, 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
January 29, 2015 February 16, 2015
Dynamic Allocation of Shared IPv4 Addresses Dynamic Allocation of Shared IPv4 Addresses
draft-ietf-dhc-dynamic-shared-v4allocation-03 draft-ietf-dhc-dynamic-shared-v4allocation-04
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 August 2, 2015. This Internet-Draft will expire on August 20, 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 4, line 10 skipping to change at page 4, line 10
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 dynamic allocation process for 'full'
IPv4 addresses described in [RFC2131]. The essential difference is IPv4 addresses described in [RFC2131]. The essential difference is
that the DHCP 4o6 Server MAY allocate the same IPv4 address to more that the DHCP 4o6 Server MAY allocate the same IPv4 address to more
than one DHCP 4o6 client simultaneously, providing that each shared than one DHCP 4o6 client simultaneously, providing that each shared
address allocation also includes a range of layer 4 source ports address allocation also includes a range of layer 4 source ports
unique to that address (i.e., the combined tuple of IPv4 address and unique to that address (i.e., the combined tuple of IPv4 address and
Port Set ID MUST be unique for each active lease). Port Set ID MUST 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 information. The below), which is a DHCPv4 option containing PSID (Port Set ID)
client includes this option within the Parameter Request List option information. The client includes this option within the Parameter
[RFC2132] in its DHCPv4 DHCPDISCOVER and DHCPREQUEST messages, Request List option [RFC2132] in its DHCPv4 DHCPDISCOVER and
indicating its support for shared, dynamic address leasing to the DHCPREQUEST messages, indicating its support for shared, dynamic
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
option, the server can dynamically allocate PSIDs to clients and option, the server can dynamically allocate PSIDs to clients and
maintain shared IPv4 address leases. The server then manages unique maintain shared IPv4 address leases. The server then manages unique
client leases based the IPv4 address and PSID tuple, instead of using client leases based the IPv4 address and PSID tuple, instead of using
only the IPv4 address. only the IPv4 address.
In the event that a dynamic, shared addressing capable client In the event that a dynamic, shared addressing capable client
receives more than one DHCP 4o6 offer, with one of the offers does receives more than one DHCP 4o6 offer, where a received offer does
not containing OPTION_V4_PORTPARAMS (i.e. is an offer for a full IPv4 not contain OPTION_V4_PORTPARAMS (i.e.,j is an offer for a full IPv4
address), then the client SHOULD prefer the full IPv4 offer over the address), then the client SHOULD prefer the full IPv4 offer over the
shared IPv4 address offer(s), unless specifically configured shared IPv4 address offer(s), unless specifically configured
otherwise. otherwise.
5. Client-Server Interaction 5. Client-Server Interaction
The following DHCPv4 message flow is transported within the The following DHCPv4 message flow is transported within the
DHCPv4-query and DHCPv4-response messages as in DHCPv4 over DHCPv6 DHCPv4-query and DHCPv4-response messages as in DHCPv4 over DHCPv6
[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. OPTION_V4_PORTPARAMS.
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 support shared IPv4 addresses respond with a DHCPOFFER message as
containing an IPv4 address in the 'yiaddr' field. The response usual with the shared IPv4 address in the 'yiaddr' field and MUST
MUST also include the OPTION_V4_PORTPARAMS option containing an add an OPTION_V4_PORTPARAMS option containing an available
available restricted port set. If the received restricted port set. If the DHCPDISCOVER included an
OPTION_V4_PORTPARAMS contains a non-zero PSID-Len field, the DHCP OPTION_V4_PORTPARAMS option containing a non-zero PSID-Len field,
4o6 Server MAY allocate a port set of the requested size to the the DHCP 4o6 Server MAY allocate a port set of the requested size
client (depending on policy). The DHCPOFFER message is then to the client (depending on policy). The DHCPOFFER message is
included in the DHCPv4-response message and sent to the client. then encapsulated 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
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 selected DHCP server's server identifier and the 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 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
used by both the server and the client to identify a lease in any used by both the server and the client to identify a lease in any
DHCP message. The server responds with a DHCPACK message DHCP message. The server MUST respond with a DHCPACK message
containing the configuration parameters for the requesting containing OPTION_V4_PORTPARAMS for the requesting client.
client.
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 an in-use probe 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 leased network
identifier, the leased network address and OPTION_V4_PORTPARAMS address and OPTION_V4_PORTPARAMS (with the allocated PSID) to
(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 followedon condition that the client's source of [RFC2131] MUST be followed on the condition that the client's
IPv6 address for DHCP 4o6 does not change. The client MUST include source IPv6 address for DHCP 4o6 does not change. Note, this
the OPTION_V4_PORTPARAMS with the requested port set information in corresponds to INIT-REBOOT state defiend in [RFC2131]. The client
the message flow, which starts with a DHCPREQUEST message. If the MUST include the OPTION_V4_PORTPARAMS with the requested port set
client's DHCP 4o6 IPv6 source address is changed for any reason, the information in the message flow, which starts with a DHCPREQUEST
client MUST re-initiate the DHCP 4o6 shared-address provisioning message. If the client's DHCP 4o6 IPv6 source address is changed for
process by sending a DHCPDISCOVER message. any reason, the client MUST re-initiate the DHCP 4o6 shared-address
provisioning process by sending a DHCPDISCOVER message.
6. Client Behavior 6. Client Behavior
A DHCP 4o6 client applying for a shared IPv4 address MUST include the A DHCP 4o6 client discovering for a shared IPv4 address MUST include
OPTION_V4_PORTPARAMS option code in the Parameter Request List the OPTION_V4_PORTPARAMS option code in the Parameter Request List
option. The client retrieves a port set using the values contained option. If a client has been successfully allocated and IPv4 address
in OPTION_V4_PORTPARAMS. If a client has been successfully allocated and PSID previously, the client MAY include in the DHCPDISCOVER
and IPv4 address and PSID previously, the client MAY include in the message the 'requested IP address' option along with an
DHCPDISCOVER message the 'requested IP address' option along with an
OPTION_V4_PORTPARAMS to request that a specific IPv4 address and PSID OPTION_V4_PORTPARAMS to request that a specific IPv4 address and PSID
be re-assigned. Alternatively, the client MAY omit the 'requested IP be re-assigned. Alternatively, the client MAY omit the 'requested IP
address' option, but include an OPTION_V4_PORTPARAMS with a non-zero 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 value in only the PSID-Len field, as a hint to the server for the
preferred size of the port set. 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. address sharing.
skipping to change at page 6, line 33 skipping to change at page 6, line 33
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 all traffic destined to The client MUST apply the following rules for all traffic destined to
or originating from the shared IPv4 address: or originating from the shared IPv4 address:
o The client MUST use only port-aware protocols (e.g TCP, UDP, DCCP o The client MUST use only port-aware protocols (e.g., TCP, UDP,
etc.) or ICMP implementing [RFC5508]. DCCP etc.) or ICMP implementing [RFC5508].
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 out of The mechanism by which a client implements the above rules is out of
skipping to change at page 8, line 4 skipping to change at page 8, line 4
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 the server MUST assign the address and port set process. Therefore the server MUST assign the address and port set
in the same DHCP message. in the same DHCP message.
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 MUST implement a mechanism available to lease to clients, the server MUST implement a mechanism
to reserve some port ranges (e.g. 'well-known-ports' 0-1023) from to reserve some port ranges (e.g., 'well-known-ports' 0-1023) from
allocation to clients. The reservation policy SHOULD be allocation to clients. The reservation policy SHOULD be
configurable. configurable.
7.1. Leasing Shared and Non-Shared IPv4 Addresses from a Single DHCP 7.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_V4_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
skipping to change at page 9, line 12 skipping to change at page 9, line 12
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 the value of PSID. Subsequently, the the port number representing the value 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 client.
first k-bits on the left of this 2-octets field is the PSID value. The first k-bits on the left of this 2-octets field is the PSID
The remaining (16-k) bits on the right are padding zeros. value. The remaining (16-k) bits on the right are padding zeros.
[I-D.ietf-softwire-map] Section 5.1 provides a full description of [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 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).
9. Security Considerations 9. Security Considerations
The security considerations in [RFC2131] and [RFC7341] are to be The security considerations in [RFC2131] and [RFC7341] are to be
considered. Additional considerations are elaborated in the considered. Additional considerations are elaborated in the
following sub-sections. following sub-sections.
9.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.
9.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 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
of TCP against Blind In-Window Attacks, use IPv6). of 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].
 End of changes. 20 change blocks. 
55 lines changed or deleted 55 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/