draft-ietf-dhc-dynamic-shared-v4allocation-04.txt   draft-ietf-dhc-dynamic-shared-v4allocation-05.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 20, 2015 I. Farrer Expires: August 21, 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
February 16, 2015 February 17, 2015
Dynamic Allocation of Shared IPv4 Addresses Dynamic Allocation of Shared IPv4 Addresses
draft-ietf-dhc-dynamic-shared-v4allocation-04 draft-ietf-dhc-dynamic-shared-v4allocation-05
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 20, 2015. This Internet-Draft will expire on August 21, 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 25 skipping to change at page 4, line 25
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, where a received offer does receives more than one DHCP 4o6 offer, where a received offer does
not contain OPTION_V4_PORTPARAMS (i.e.,j is an offer for a full IPv4 not contain OPTION_V4_PORTPARAMS (i.e., 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
OPTION_V4_PORTPARAMS. the code of OPTION_V4_PORTPARAMS. The client MAY insert an
OPTION_V4_PORTPARAMS with preferred values in related fields as a
suggestion to the DHCP 4o6 Server.
2. DHCP 4o6 Servers that receive the DHCPDISCOVER message and 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 as
usual with the shared IPv4 address in the 'yiaddr' field and MUST usual with the shared IPv4 address in the 'yiaddr' field and MUST
add an OPTION_V4_PORTPARAMS option containing an available add an OPTION_V4_PORTPARAMS option containing an available
restricted port set. If the DHCPDISCOVER included an restricted port set. If the DHCPDISCOVER included an
OPTION_V4_PORTPARAMS option containing a non-zero PSID-Len field, OPTION_V4_PORTPARAMS option containing a non-zero PSID-Len field,
the DHCP 4o6 Server MAY allocate a port set of the requested size the DHCP 4o6 Server MAY allocate a port set of the requested size
to the client (depending on policy). The DHCPOFFER message is to the client (depending on policy). The DHCPOFFER message is
then encapsulated in the DHCPv4-response message and sent to the then encapsulated in the DHCPv4-response message and sent to the
client. client.
skipping to change at page 5, line 29 skipping to change at page 5, line 30
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 defiend in [RFC2131]. The client corresponds to INIT-REBOOT state defined in [RFC2131]. The client
MUST include the OPTION_V4_PORTPARAMS with the requested port set MUST include the OPTION_V4_PORTPARAMS with the requested port set
information in the message flow, which starts with a DHCPREQUEST 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.
6. Client Behavior 6. Client Behavior
A DHCP 4o6 client discovering for a shared IPv4 address MUST include A DHCP 4o6 client discovering for a shared IPv4 address MUST include
the OPTION_V4_PORTPARAMS option code in the Parameter Request List the OPTION_V4_PORTPARAMS option code in the Parameter Request List
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., 0-1023) from allocation to
allocation to clients. The reservation policy SHOULD be 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
ensure that clients not supporting OPTION_V4_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
skipping to change at page 10, line 11 skipping to change at page 10, line 8
(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].
10. 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.
11. 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 and Marcin Savolainen, Ted Lemon, Tina Tsou, Pierre Levis, Cong Liu, and Marcin
Siodelski, for their contributions to this work. Siodelski for their contributions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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-13 (work Lite Architecture", draft-ietf-softwire-lw4over6-13 (work
in progress), November 2014. in progress), November 2014.
skipping to change at page 13, line 23 skipping to change at page 13, line 23
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
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
 End of changes. 11 change blocks. 
14 lines changed or deleted 14 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/