draft-ietf-dhc-dynamic-shared-v4allocation-07.txt   draft-ietf-dhc-dynamic-shared-v4allocation-08.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: November 14, 2015 I. Farrer Expires: November 29, 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
May 13, 2015 May 28, 2015
Dynamic Allocation of Shared IPv4 Addresses Dynamic Allocation of Shared IPv4 Addresses
draft-ietf-dhc-dynamic-shared-v4allocation-07 draft-ietf-dhc-dynamic-shared-v4allocation-08
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 November 14, 2015. This Internet-Draft will expire on November 29, 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 3, line 30 skipping to change at page 3, line 30
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
The solution allows multiple hosts to be simultaneously allocated the The solution allows multiple hosts to be simultaneously allocated the
same IP address. As the IP address is no longer a unique identifier same IP address. As the IP address is no longer a unique identifier
for a host, this extension is only suitable for specific for a host, this extension is only suitable for specific
architectures based on the Address plus Port model (A+P) [RFC6346] architectures based on the Address plus Port model (A+P) [RFC6346].
such as [I-D.ietf-softwire-lw4over6] and certain configurations of Specifically, this document presents a solution that applies to
[I-D.ietf-softwire-map]. [I-D.ietf-softwire-lw4over6] and certain configurations of
[I-D.ietf-softwire-map] (e.g., EA-bit length set to 0).
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 media, including Ethernet, WLAN, cable,
etc..
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
4. Terminology 4. Terminology
This document makes use of the following terms: This document makes use of the following terms:
skipping to change at page 8, line 5 skipping to change at page 8, line 8
o The address requested in the 'Requested IP Address' option along o The address requested in the 'Requested IP Address' option along
with the PSID parameters requested in the OPTION_V4_PORTPARAMS, if with the PSID parameters requested in the OPTION_V4_PORTPARAMS, if
that pair of address and PSID is valid and not already allocated, that pair of address and PSID is valid and not already allocated,
ELSE ELSE
o A new address with a PSID allocated from the server's pool of o A new address with a PSID allocated from the server's pool of
available addresses and PSIDs. 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 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 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., 0-1023) from allocation to to reserve some port ranges (e.g., 0-1023) from allocation to
clients. The reservation policy SHOULD be configurable. clients. The reservation policy SHOULD be configurable.
skipping to change at page 10, line 12 skipping to change at page 10, line 12
unicast DHCP 4o6 message flows (enabled by supplying DHCP 4o6 server unicast DHCP 4o6 message flows (enabled by supplying DHCP 4o6 server
unicast addresses within the OPTION_DHCP4_O_DHCP6_SERVER option). unicast addresses within the OPTION_DHCP4_O_DHCP6_SERVER option).
A malicious user could attempt a DoS attack by requesting a large A malicious user could attempt a DoS attack by requesting a large
number ofIPv4 address (or fractional address) and port sets number ofIPv4 address (or fractional address) and port sets
allocations, exhausting the available addresses and port sets for allocations, exhausting the available addresses and port sets for
other clients. This can be mitigated through DHCP 4o6 address other clients. This can be mitigated through DHCP 4o6 address
allocation policy, limiting the number of simultaneously active IPv4 allocation policy, limiting the number of simultaneously active IPv4
leases for clients whose request originate from each customer site. leases for clients whose request originate from each customer site.
Additional security considerations are discussed in Section 11 of
[I-D.ietf-softwire-map] and Section 9 of
[I-D.ietf-softwire-lw4over6].
10.1. Port Randomization 10.1. Port Randomization
Preserving port randomization [RFC6056] may be more or less difficult Preserving port randomization [RFC6056] may be more difficult because
depending on the address sharing ratio (i.e., the size of the port the host can only randomize the ports inside a fixed port range (see
space assigned to a client). The host can only randomize the ports Section 13.4 of [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
in [I-D.bajko-pripaddrassign].
11. IANA Considerations 11. 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
skipping to change at page 11, line 48 skipping to change at page 11, line 48
[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.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC
7341, August 2014. 7341, August 2014.
13.2. Informative References 13.2. Informative References
[I-D.bajko-pripaddrassign]
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
"Port Restricted IP Address Assignment", draft-bajko-
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-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., Yeh, L., and X. Deng, "DHCPv6 Options for W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
configuration of Softwire Address and Port Mapped configuration of Softwire Address and Port Mapped
Clients", draft-ietf-softwire-map-dhcp-12 (work in Clients", draft-ietf-softwire-map-dhcp-12 (work in
 End of changes. 11 change blocks. 
21 lines changed or deleted 19 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/