Network Working Group M. Boucadair, Ed.
Internet-Draft P. Levis
Intended status: Standards Track J-L. Grimault
Expires: November 19, 2009 France Telecom
T. Savolainen
G. Bajko
Nokia
May 18, 2009
Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP
Addresses Solutions
draft-boucadair-dhcpv6-shared-address-option-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 19, 2009.
Copyright Notice
Boucadair, et al. Expires November 19, 2009 [Page 1]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This memo defines Dynamic Host Configuration Protocol version 6
(DHCPv6) Options to be used in the context of shared IP address
solutions. In some deployment scenarios, DHCP (IPv4) cannot be used
to configure customer devices because only IPv6 capabilities are
deployed (e.g. DS-lite context or IPv6 Port Range). Therefore,
DHCPv6 may be used to convey IPv4-related configuration information
such as Port Range and/or Port Extended IPv4 addresses. This
document defines also a DHCPv6 Option aiming to convey the IPv6
prefix to be used to build IPv4-inferred IPv6 addresses required in
the context of stateless IPv4-in-IPv6 encapsulation.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Boucadair, et al. Expires November 19, 2009 [Page 2]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv4 Address Option . . . . . . . . . . . . . . . . . . . . . 5
3. Port Extended IPv4 Address DHCPv6 Option . . . . . . . . . . . 6
3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Port Range Sub-Option . . . . . . . . . . . . . . . . . . 7
3.3. Delegated Random Port Range Sub-Option . . . . . . . . . . 8
4. IPv4-inferred IPv6 address Format Option . . . . . . . . . . . 9
5. Supported IPv4-inferred IPv6 Address Formats Option . . . . . 12
6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Port Mask Example . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Boucadair, et al. Expires November 19, 2009 [Page 3]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
1. Introduction
Within the context of IPv4 address depletion, several solutions have
been submitted to the IETF to propose viable alternatives to double
NAT [I-D.nishitani-cgn]. Examples of these solutions are
[I-D.ietf-softwire-dual-stack-lite] and
[I-D.boucadair-behave-ipv6-portrange]. These solutions propose to
share a given global IPv4 address between several customers. These
solutions differ in the way they behave and particularly on the
location of the NAT function. In
[I-D.boucadair-behave-ipv6-portrange] the NAT function stays at the
CPE level and none lies in the network whilst in
[I-D.ietf-softwire-dual-stack-lite] the NAT function is located in
the network -in the DS-lite node- while the NAT in the CPE can be
deactivated. Nevertheless, [I-D.ietf-softwire-dual-stack-lite]
supports the Extended Port IP address logic mainly for the
enforcement of port forwarding service for instance. Therefore,
dedicated means such as [I-D.bajko-pripaddrassign] are required for
the provisioning of pertinent information to constrain the source
port number. [I-D.bajko-pripaddrassign] specifications may be used
when IPv4-enabled DHCP servers are deployed and corresponding DHCP
clients enabled in customer devices, such as the CPE.
Furthermore, both [I-D.ietf-softwire-dual-stack-lite] and
[I-D.boucadair-behave-ipv6-portrange] assume that only IPv6 transfer
capabilities are activated on the link connecting the customer's
device to the access network. IPv4-in-IPv6 tunneling capabilities
can be put in place to allow DHCP exchanges and therefore
[I-D.bajko-pripaddrassign] can be used to provision the customer
device. Nevertheless, in environments where no IPv4-enabled DHCP
servers are maintained or no tunneling means are deployed to reach
DHCP servers, alternative means to provision the customer's device
are required. This memo is an effort to meet this requirement.
Note that [I-D.dhankins-softwire-tunnel-option] can be used to
provide the customer device with the IPv6 address of a DS-lite CGN or
a PRR (Port Range Router) node.
Concretely, this document defines the following new DHCPv6 Options
[RFC3315]:
1. IPv4 address: This option is used to convey a "full" IPv4
address.
2. Port Extended IPv4 Address: This option carries an IPv4 address
to be used in conjunction with an allocated Port Range. In case
of Port Range allocation, several customers are assigned with the
same IPv4 Address. This option defines the allowed port values
Boucadair, et al. Expires November 19, 2009 [Page 4]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
to be used as source port number. This option is completely
independent of the IPv4 address Option above.
3. IPv4-inferred IPv6 address Format: This option is used to provide
the device with the prefix to be used to build an IPv4-inferred
IPv6 address, as for example defined in
[I-D.boucadair-behave-ipv6-portrange], Section 4 "IPv6-IPv4
Address Mapping Formalism".
4. Supported IPv4-inferred IPv6 address Formats: This option allows
a DHCPv6 client to indicate the type of IPv4-inferred IPv6
address format(s) it can handle.
2. IPv4 Address Option
This DHCPv6 Option carries an IPv4 address. The DHCPv6 Option has
the format shown in Figure 1 :
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IPV4_A | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (IPv4 Address) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv4 Address DHCPv6 Option
- option-code: OPTION_IPV4_A (To be assigned by IANA)
- option-length: 12.
- preferred-lifetime: The preferred lifetime for the IPv4 address
in the option, expressed in units of seconds.
- valid-lifetime: The valid lifetime for the IPv4 address in the
option, expressed in units of seconds.
Boucadair, et al. Expires November 19, 2009 [Page 5]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
3. Port Extended IPv4 Address DHCPv6 Option
3.1. Option Format
The Port Extended IPv4 address DHCPv6 Option is used to specify a
shared IPv4 address together with one range of ports (contiguous or
not).
The format of the Port Extended IPv4 address Option is provided in
Figure 2.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PORT_EXTENDED_A | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-option-code | sub-option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-option-content |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Port Extended IPv4 Address DHCPv6 Option
- option-code: OPTION_PORT_EXTENDED_A (To be assigned by IANA)
- option-length: the length of enclosed sub-option(s) + 4.
- sub-option code: specifies the code of the included sub-options.
Two sub-codes are defined in this document: SUB_OPTION_PORT_MASK
and SUB_OPTION_DELG_RAND.
- sub-option-len: length of the sub-option.
Boucadair, et al. Expires November 19, 2009 [Page 6]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
- sub-option-content: content of the sub-option
- preferred-lifetime: The preferred lifetime for the Port Extended
IPv4 address in the option, expressed in units of seconds.
- valid-lifetime: The valid lifetime for the Port Extended IPv4
address in the option, expressed in units of seconds.
3.2. Port Range Sub-Option
Figure 3 provides an overview of the Port Range sub-option.
This sub-option is used to notify a remote peer about an IPv4 address
to be used in conjunction with an allocated Port Range. The Port
Range is allocated on the form of a Port Mask to be applied when
selecting a port value as a source port. The Port Range Sub Option
is used to infer a set of allowed port values. A Port Mask defines a
set of ports that all have in common a subset of pre-positioned bits.
This set of ports is also called Port Range.
A Port Mask is composed of a Port Range Value and a Port Range Mask.
o The Port Range Value indicates the value of the significant bits
of the Port Mask. The Port Range Value is encoded as follows:
* The significant bits may take a value of 0 or 1.
* All the other bits (non significant ones) are set to 0.
o The Port Range Mask indicates, by the bit(s) set to 1, the
position of the significant bits of the Port Range Value.
This DHCPv6 Sub Option provides a way to negotiate the port range to
be allocated to the peer.
Boucadair, et al. Expires November 19, 2009 [Page 7]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB_OPTION_PORT_MASK | sub-option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Extended IP Address (IPv4 Address) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Range Value | Port Range Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Port Range Sub Option
- sub-option-code: SUB_OPTION_PORT_MASK (To be assigned by IANA)
- sub-option-len: 8.
- Port Extended IP Address: specifies the shared IPv4 address
- Port Range Value (PRV) (16 bits): PRV indicates the value of the
significant bits of the Port Mask.
- Port Range Mask (PRM) (16 bits): The Port Range Mask indicates,
by the bit(s) set to 1, the position of the significant bits of
the Port Range Value.
An example of Port Range Mask is provided in Appendix A.
3.3. Delegated Random Port Range Sub-Option
Figure 4 provides an overview of the delegated random Port Range:
Boucadair, et al. Expires November 19, 2009 [Page 8]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB_OPTION_DELG_RAND | sub-option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Extended IP Address (IPv4 Address) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| starting point | number of delegated ports |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key K (128 bits) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Delegated Random Port Option
- sub-option-code: SUB_OPTION_DELG_RAND (To be assigned by IANA)
- sub-option-len: 28.
- Port Extended IP Address: specifies the shared IPv4 address
- Function: A 32 bit field whose value is associated with
predefined encryption functions. For more information about this
function, refer to [I-D.bajko-pripaddrassign].
- starting point: A 16 bit value used as an input to the specified
function.
- Number of delegated ports: A 16bit value specifying the number
of ports delegated to the client for use as source port values.
- Key K: A 128 bit key used as input to the predefined function
for delegated port calculation.
4. IPv4-inferred IPv6 address Format Option
[I-D.boucadair-behave-ipv6-portrange] defines a Port Range solution
which assumes IPv6-only network for the delivery of both IPv4 and
IPv6 connectivity services. The solution is based on IPv4-in-IPv6
encapsulation for the transport of IPv4 datagrams inside an IPv6-only
network. For these reasons, an IPv6 prefix is required to build
destination IPv4-inferred IPv6 addresses of IPv4-in-IPv6 encapsulated
datagrams issued by a port-restricted device.
Boucadair, et al. Expires November 19, 2009 [Page 9]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
Figure 5 provides an example of a structure of an IPv4-inferred IPv6
address where "WKIPv6" is a well-known IPv6 prefix:
+----------------------------------------------------------------------...+
| WKIPv6 |Dest. IPv4 |Dest. | 0:0:0:0 |
| |address |port | |
+----------------------------------------------------------------------...+
Figure 5: Example of IPv4-inferred IPv6 Address
The IPv4-inferred IPv6 address format used by a device depends on
several parameters such as the ability of the device to use a port
number or not when building an IPv4-inferred IPv6 address. Hence
there is a need to identify several formats. This need is covered by
the IPv4-inferred IPv6 address Format Option.
The IPv4-inferred IPv6 address Format Option is structured as shown
in Figure 6.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INFER_V4V6 | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| format-type | IPv6 Prefix length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| IPv6 Prefix (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPv4-inferred IPv6 addresses Format Option
- option-code: OPTION_INFER_V4V6 (To be assigned by IANA)
- option-length: Variable.
- format-type: Indicates the format type of the IPv4-inferred IPv6
address. The values so far defined are the following ones:
Boucadair, et al. Expires November 19, 2009 [Page 10]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
- "1": When the format-type value is set to 1, the destination
addresses of IPv4-in-IPv6 datagrams issued by the device have
the following structure:
+-----------------------------------------------------------------------------+
| IPv6 Prefix (128 bits) |
| |
+-----------------------------------------------------------------------------+
Figure 7: Format Type (1)
As a matter of fact, the IPv6 Prefix (128 bits long) is an IPv6
address here. The IPv4-in-IPv6 encapsulation scheme is the
simple IPv4-in-IPv6 encapsulation.
- "2": When the format-type value is equal to 2, the
destination IPv6 addresses of IPv4-in-IPv6 datagrams issued by
the device follow the following structure. This format type is
defined in [I-D.boucadair-behave-ipv6-portrange].
+------------------------------------------------------------------------------+
|IPv6 Prefix (32 bits)| Dest. IPv4 | 0::0 |
| | address (32 bits)| |
+------------------------------------------------------------------------------+
Figure 8: Format Type (2)
The IPv4-in-IPv6 encapsulation scheme is the simple IPv4-in-
IPv6 encapsulation.
- "3": When the format-type value is set to 3,
a. if the IPv4 packet to be sent encapsulated bears a protocol
with port information (case of TCP and UDP, for example),
the destination IPv6 address of the IPv4-in-IPv6 datagram
transmitted by the device follows the following structure :
+------------------------------------------------------------------------------+
|IPv6 Prefix (32 bits)| Dest. IPv4 |Dest. Port| 0::0 |
| | address (32 bits)|(16 bits) | |
+------------------------------------------------------------------------------+
Figure 9: Format Type (3)
Boucadair, et al. Expires November 19, 2009 [Page 11]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
b. if the IPv4 datagram to be encapsulated bears a protocol
without port number (e.g. ICMP), the destination IPv6
address of the IPv4-in-IPv6 datagram issued by the device
SHOULD be sent to another IPv6 destination address than the
destination address depicted in Figure 9. For example,
such packet without port number MAY be transmitted to a DS-
lite CGN node. Another alternative is to send such packet
following the Format Type (2) even if Format Type (3) has
been mandated by the DHCPv6 server to the client, but this
behavior is NOT RECOMMENDED.
The IPv4-in-IPv6 encapsulation scheme is the simple IPv4-in-
IPv6 encapsulation.
- Other format-type values can be defined later. The format-
type values from the value 32768 are not reserved. They can be
used in a ISP scope to encode a proprietary format-type.
- IPv6 Prefix: Encloses the IPv6 prefix to be used to build IPv4-
inferred IPv6 addresses. When format-type 1 is used, this prefix
is an IPv6 address.
- preferred-lifetime: The preferred lifetime for the IPv6 Prefix
in the option, expressed in units of seconds.
- valid-lifetime: The valid lifetime for the IPv6 Prefix in the
option, expressed in units of seconds.
5. Supported IPv4-inferred IPv6 Address Formats Option
A client MAY indicate the format-type values it can support (related
to IPv4- inferred IPv6 address Formats Option) by including the
Supported IPv4-inferred IPv6 address Formats Option in a DHCPv6
Solicit, Request, Renew, Rebind, Confirm or Information-request
message.
The order in the list MAY indicate preference in format-types, the
first value being the preferred one.
The Supported IPv4-inferred IPv6 address Format Option is structured
as shown in Figure 10.
Boucadair, et al. Expires November 19, 2009 [Page 12]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SUPPORT_INFER_V4V6 | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| format-type-1 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | format-type-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Supported IPv4-inferred IPv6 Address Formats Option
- option-code: OPTION_SUPPORT_INFER_V4V6 (To be assigned by IANA)
- option-length: permits to numerate the supported format-type
values.
option-length = 2 * number of format-type values. In case of an
odd number of format-type values, a padding of two "x00" octets is
to be placed in the ending 16 bits.
- format-type-i: the values of the format-type supported by the
client.
6. Behaviour
A client MAY request IPv4 Address and/or Port Extended IPv4 Address
and/or IPv4-inferred IPv6 address Format Option(s) by including the
corresponding Option codes into an Option Request Option (as per
[RFC3315]). This latter being itself included into a Solicit,
Request, Renew, Rebind, Confirm or Information-request message.
Doing so, the client can inform the server about options the client
wishes to receive.
The client MAY include IPv4 Address and/or Port Extended IPv4 Address
and/or IPv4-inferred IPv6 address Format in Solicit, Request, Renew,
Rebind, Confirm or Information request message as hints to the server
about parameter values the client would like to be returned. In such
case, the Option Request Option MUST be sent in the message and
includes the corresponding Option codes. If the client sends the
IPv4-inferred IPv6 address Formats as a hint to the server, the value
of the format-type in the Option is the value of the format-type
preferred by the client.
A client MAY indicate the format-type values it can support (related
to IPv4-inferred IPv6 address Format Option) by including the
Supported IPv4-inferred IPv6 address Formats Option in a Solicit,
Request, Renew, Rebind, Confirm or Information-request message. If
Boucadair, et al. Expires November 19, 2009 [Page 13]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
in the same message the client has also included the IPv4-inferred
IPv6 address Format Option as a hint to the server, then the format-
type values listed in the Supported IPv4-inferred IPv6 address
Formats Option has to be taken by the server as complementary
information. In that case, for consistency reasons, the first
format-type value indicated in the Supported IPv4-inferred IPv6
address Formats Option MUST be the same value (i.e. the preferred
one) as the one in the IPv4-inferred IPv6 address Format Option.
If a client receives the IPv4 Address Option in conjunction with an
IPv4-inferred IPv6 address Format Option, all IPv4 datagrams MUST be
encapsulated in IPv6 according to the features indicated in this
latter Option, meaning that the destination IPv6 addresses MUST be
IPv4-inferred addresses as specified in the Option.
If a client receives the Port Extended IPv4 Address Option, the
client MUST constrain the source port number of included Port
Extended IPv4 Address to be within the provisioned Port Range. If a
client receives the IPv4 Address Port Extended IPv4 Address Option in
conjunction with the IPv4-inferred IPv6 address Format Option, all
IPv4 datagrams MUST be encapsulated in IPv6 according to the features
indicated in this latter Option, meaning that the destination IPv6
addresses MUST be IPv4-inferred address as specified in the Option.
If a client receives a Port Extended IPv4 Address Option but no Port
Range Sub-Option included, it MUST use the conveyed IPv4 address as
non restricted one. If in addition, it has received an IPv4-inferred
IPv6 address Format Option, all IPv4 datagrams MUST be encapsulated
in IPv6 according to the features indicated in this latter Option,
meaning that the destination IPv6 addresses MUST be IPv4-inferred
addresses as specified in the Option.
If a client receives a Port Extended IPv4 Address Option with the
Port Range Sub-Option enclosed but with the IPv4 address set to
"0.0.0.0", the client MUST constrain all IPv4 communications to be
within the allocated Port Range. In such case, the IPv4 address the
client will use is allocated by other means than by DHCPv6 Port
Extended IPv4 Address Option (e.g. through DHCP (IPv4), IPv4 address
derived from an IPv6 address, ... ). It is NOT RECOMMENDED that the
client or the server use the IPv4 Address Option in conjunction with
a Port Extended IPv4 Address option with Port Range Sub-Option
present and IPv4 address set to "0.0.0.0", because the use of the
Port Extended IPv4 Address Option with a correct IPv4 address is more
efficient.
When a peer issues a request enclosing one or more options (defined
in this document), if the server does not support this (ese)
option(s), the DHCPv6 server ignores the corresponding option.
Boucadair, et al. Expires November 19, 2009 [Page 14]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
7. IANA Considerations
This document requests IANA to assign numbers for these DHCPv6
options:
- OPTION_IPV4_A
- OPTION_PORT_EXTENDED_A
- OPTION_INFER_V4V6
- OPTION_SUPPORT_INFER_V4V6
And the following sub-options:
- SUB_OPTION_PORT_MASK
- SUB_OPTION_DELG_RAND
8. Security Considerations
All security considerations described in [RFC3315] apply for this
specification.
9. Acknowledgements
The authors would like to thank Christian JACQUENET for his review.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
10.2. Informative References
[I-D.bajko-pripaddrassign]
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
Boucadair, et al. Expires November 19, 2009 [Page 15]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
"Port Restricted IP Address Assignment",
draft-bajko-pripaddrassign-01 (work in progress),
March 2009.
[I-D.boucadair-behave-ipv6-portrange]
Boucadair, M., Levis, P., Grimault, J., Villefranque, A.,
and M. Kassi-Lahlou, "Flexible IPv6 Migration Scenarios in
the Context of IPv4 Address Shortage",
draft-boucadair-behave-ipv6-portrange-01 (work in
progress), March 2009.
[I-D.dhankins-softwire-tunnel-option]
Hankins, D., "Dynamic Host Configuration Protocol Option
for Dual-Stack Lite",
draft-dhankins-softwire-tunnel-option-03 (work in
progress), March 2009.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
"Dual-stack lite broadband deployments post IPv4
exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work
in progress), March 2009.
[I-D.nishitani-cgn]
Nishitani, T., Miyakawa, S., Nakagawa, A., and H. Ashida,
"Common Functions of Large Scale NAT (LSN)",
draft-nishitani-cgn-01 (work in progress), November 2008.
Appendix A. Port Mask Example
The following figure (Figure 11) provides an example of the resulting
Port Range when:
- Port Range Mask is set to 0001010000000000 (5120) and
- Port Range Value is set to 0000010000000000 (1024).
Ports belonging to this port range must have the 4th bit (resp. the
sixth one), from the left, set to 0 (resp. 1). Only these ports will
be used by the peer when enforcing the configuration conveyed by
DHCPv6.
Boucadair, et al. Expires November 19, 2009 [Page 16]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Mask
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| | (two significant bits)
v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x 0 x 1 x x x x x x x x x x| Usable ports (x may take a value of 0 or 1).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Example of Port Range Mask and Port Range Value
Authors' Addresses
Mohamed Boucadair (editor)
France Telecom
3, Av Francois Chateaux
Rennes 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Pierre Levis
France Telecom
Email: pierre.levis@orange-ftgroup.com
Jean-Luc Grimault
France Telecom
Email: jeanluc.grimault@orange-ftgroup.com
Boucadair, et al. Expires November 19, 2009 [Page 17]
Internet-Draft Shared IP addresses DHCPv6 Options May 2009
Teemu Savolainen
Nokia
Email: teemu.savolainen@nokia.com
Gabor Bajko
Nokia
Email: Gabor.Bajko@nokia.com
Boucadair, et al. Expires November 19, 2009 [Page 18]