draft-ietf-dhc-dynamic-shared-v4allocation-05.txt   draft-ietf-dhc-dynamic-shared-v4allocation-06.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 21, 2015 I. Farrer Expires: October 17, 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 17, 2015 April 15, 2015
Dynamic Allocation of Shared IPv4 Addresses Dynamic Allocation of Shared IPv4 Addresses
draft-ietf-dhc-dynamic-shared-v4allocation-05 draft-ietf-dhc-dynamic-shared-v4allocation-06
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 21, 2015. This Internet-Draft will expire on October 17, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
4. Functional Overview . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Client-Server Interaction . . . . . . . . . . . . . . . . . . 4 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 4
6. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 6. Client-Server Interaction . . . . . . . . . . . . . . . . . . 4
6.1. Restrictions to Client Usage of a Shared IPv4 Address . . 6 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Restrictions to Client Usage of a Shared IPv4 Address . . 6
7.1. Leasing Shared and Non-Shared IPv4 Addresses from a 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Leasing Shared and Non-Shared IPv4 Addresses from a
Single DHCP 4o6 Server . . . . . . . . . . . . . . . . . 8 Single DHCP 4o6 Server . . . . . . . . . . . . . . . . . 8
8. DHCPv4 Port Parameters Option . . . . . . . . . . . . . . . . 8 9. DHCPv4 Port Parameters Option . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 9 10.1. Denial-of-Service . . . . . . . . . . . . . . . . . . . 10
9.2. Port Randomization . . . . . . . . . . . . . . . . . . . 9 10.2. Port Randomization . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.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
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
skipping to change at page 3, line 25 skipping to change at page 3, line 25
[RFC7341] introduces a "DHCP 4o6 Server", which offers dynamic [RFC7341] introduces a "DHCP 4o6 Server", which offers dynamic
leasing for IPv4 addresses to clients as in DHCPv4 [RFC2131] but leasing for IPv4 addresses to clients as in DHCPv4 [RFC2131] but
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
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] such as the Address plus Port model (A+P) [RFC6346] such as
[I-D.ietf-softwire-lw4over6] and certain configurations of [I-D.ietf-softwire-lw4over6] and certain configurations of
[I-D.ietf-softwire-map]. [I-D.ietf-softwire-map].
2. Requirements Language The solution should only be used on point-to-point links, tunnels,
and/or in environments where authentication at the link layer is
performed before IP address assignment. It is not suitable for
network access over shared mediums.
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].
3. Terminology 4. 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 set.
address MUST use source ports within the
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. 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 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 can 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 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 30 skipping to change at page 4, line 37
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., 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 6. 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. The client MAY insert an the code of OPTION_V4_PORTPARAMS. The client MAY insert an
skipping to change at page 5, line 37 skipping to change at page 5, line 42
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 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 7. 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
option. If a client has been successfully allocated and IPv4 address option. If a client has been successfully allocated an IPv4 address
and PSID previously, the client MAY include in the DHCPDISCOVER and PSID previously, the client MAY include in the DHCPDISCOVER
message the 'requested IP address' option along with an 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 (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.
The client MUST NOT probe a newly received IPv4 address (e.g., using 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 its 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 OPTION_V4_PORTPARAMS, and values of offset, PSID length and PSID into OPTION_V4_PORTPARAMS, and
send it 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.
In the event that the client's DHCP 4o6 IPv6 source address is In the event that the client's DHCP 4o6 IPv6 source address is
changed for any reason, the client MUST re-initiate the DHCP 4o6 changed for any reason, the client MUST re-initiate the DHCP 4o6
shared-address provisioning process by sending a DHCPDISCOVER shared-address provisioning process by sending a DHCPDISCOVER
message. 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 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, o The client MUST use only port-aware protocols (e.g., TCP, UDP,
DCCP 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 use the
the received restricted IPv4 address on-link. received restricted IPv4 address to perform ARP operations.
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
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. Server Behavior 8. Server Behavior
The DHCP 4o6 Server MUST NOT reply with OPTION_V4_PORTPARAMS unless The DHCP 4o6 Server MUST NOT reply with OPTION_V4_PORTPARAMS unless
the client has explicitly listed the option code in the Parameter the client has explicitly listed the option code in the Parameter
Request List (Option 55) [RFC2132]. 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 OPTION_V4_PORTPARAMS in its Parameter Request List. client includes OPTION_V4_PORTPARAMS in its Parameter Request List.
In order to achieve the dynamic management of shared IPv4 addresses, In order to achieve the dynamic management of shared IPv4 addresses,
the server MUST implement an address and port-set pool that provides the server is required to implement an address and port-set pool that
the same function as the address pool in a regular DHCP server. The provides the same function as the address pool in a regular DHCP
server MUST use the combination of address and PSID as the key for server. Also, the server uses the combination of address and PSID as
maintaining the state of a lease, and for searching for an available the key for maintaining the state of a lease, and for searching for
lease for assignment. The leasing database MUST include the IPv4 an available lease for assignment. The leasing database is required
address, PSID and client identifier of the requesting client. to include the IPv4 address, PSID and client identifier of the
requesting 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 option, the server OPTION_V4_PORTPARAMS in the Parameter Request List option, the server
determines an IPv4 address with a PSID for the requesting client. If determines an IPv4 address with a PSID for the requesting client. If
an IPv4 address with a PSID is available, the server SHOULD follow an IPv4 address with a PSID is available, the server SHOULD follow
the logic below to select which specific address and PSID to the logic below to select which specific address and PSID to
provision to the client. The logic is similar to that in provision to the client. The logic is similar to that in
Section 4.3.1 of [RFC2131]. Section 4.3.1 of [RFC2131].
o The client's current address with the PSID as recorded in the o The client's current address with the PSID as recorded in the
skipping to change at page 8, line 7 skipping to change at page 8, line 16
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.
7.1. Leasing Shared and Non-Shared IPv4 Addresses from a Single DHCP 8.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
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 with address pools for shared If the server is only configured with address pools for shared
address 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.
8. DHCPv4 Port Parameters Option A server configured with non-shared address pools can be instructed
to honor received requests that contain OPTION_V4_PORTPARAMS in the
Parameter Request List option (that is ignore OPTION_V4_PORTPARAMS
and serve the requesting clients with non-shared IPv4 addresses).
The DHCPv4 Port Parameters Option uses the same fields as the S46 9. DHCPv4 Port Parameters Option
Port Parameters Option described in Section 4.5 of
[I-D.ietf-softwire-map-dhcp], implemented as a DHCPv4 option. This The meaning of 'offset', 'PSID-len', and 'PSID' fields of the DHCPv4
is to maintain compatibility with existing port set implementations. Port Parameters Option is identical to that of 'offset', 'PSID-len',
and 'PSID' fields of the S46 Port Parameters Option (Section 4.5 of
[I-D.ietf-softwire-map-dhcp]). The use of the same encoding in both
options is meant to ensure 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 | option-len | | option-code | option-len |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| offset | PSID-len | | offset | PSID-len |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
skipping to change at page 9, line 23 skipping to change at page 9, line 43
value. 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 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).
9. Security Considerations 10. 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 10.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. Refer to Section 2 for the target use cases.
point links, tunnels, and/or in environments where authentication at
the link layer is performed before IP address assignment. It is not
suitable for network access over shared mediums.
9.2. Port Randomization 10.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 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
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 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
set of ports bound to a shared IPv4 set of ports bound to a shared IPv4
address. address.
11. Acknowledgements 12. 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. Siodelski for their contributions.
12. References Many thanks to Brian Haberman for the review.
12.1. Normative References 13. References
13.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.
[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-12 with Encapsulation (MAP)", draft-ietf-softwire-map-13
(work in progress), November 2014. (work in progress), March 2015.
[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.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
skipping to change at page 11, line 21 skipping to change at page 11, line 46
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.
[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.
12.2. Informative References 13.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-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-11 (work in Clients", draft-ietf-softwire-map-dhcp-12 (work in
progress), November 2014. progress), March 2015.
[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,
"Dynamic Host Configuration Protocol (DHCP) Option for "Dynamic Host Configuration Protocol (DHCP) Option for
Port Set Assignment", draft-sun-dhc-port-set-option-02 Port Set Assignment", draft-sun-dhc-port-set-option-02
(work in progress), October 2013. (work in progress), October 2013.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005. 2005.
 End of changes. 35 change blocks. 
65 lines changed or deleted 78 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/