Dynamic Host Configuration (DHC) J. Korhonen
Internet-Draft Nokia Siemens Networks
Updates: 3633 (if approved) T. Savolainen
Intended status: Standards Track Nokia
Expires: March 6, 2011 September 2, 2010
Prefix Exclude Option for DHCPv6-based Prefix Delegation
draft-korhonen-dhc-pd-exclude-01.txt
Abstract
This specification defines an optional mechanism to allow exclusion
of one specific prefix from a delegated prefix set when using DHCPv6-
based prefix delegation.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 6, 2011.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Korhonen & Savolainen Expires March 6, 2011 [Page 1]
Internet-Draft PD Exclude Option September 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3
3. Prefix Delegation with Excluded Prefixes . . . . . . . . . . . 3
3.1. Problem Background . . . . . . . . . . . . . . . . . . . . 3
3.2. Available Workarounds . . . . . . . . . . . . . . . . . . . 4
3.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . 5
4. Prefix Exclude Option . . . . . . . . . . . . . . . . . . . . . 5
5. Delegating Router Solicitation . . . . . . . . . . . . . . . . 6
5.1. Requesting Router . . . . . . . . . . . . . . . . . . . . . 6
5.2. Delegating Router . . . . . . . . . . . . . . . . . . . . . 7
6. Requesting Router Initiated Prefix Delegation . . . . . . . . . 8
6.1. Requesting Router . . . . . . . . . . . . . . . . . . . . . 8
6.2. Delegating Router . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Korhonen & Savolainen Expires March 6, 2011 [Page 2]
Internet-Draft PD Exclude Option September 2010
1. Introduction
This specification defines an optional mechanism and the related
DHCPv6 option to allow exclusion of one specific prefix from a
delegated prefix set when using DHCPv6-based prefix delegation.
The prefix exclusion mechanism is targeted to deployments where
DHCPv6-based prefix delegation is used but a single aggregatable
route/refix has to represents one customer, instead of using one
prefix for the link and another prefix for the customer network. The
mechanism defined in this specification allows requesting router to
use a prefix out of delegated prefix set on its link through which it
exchanges DHCPv6 messages with the delegating router.
2. Requirements and Terminology
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 [RFC2119].
3. Prefix Delegation with Excluded Prefixes
3.1. Problem Background
DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit
limitation described in Section 12.1 of [RFC3633] that a prefix
delegated to a requesting router cannot be used by the delegating
router. This restriction implies that the delegating router will
have two (non aggregatable) routes towards a customer, one for the
link between the requesting router and the delegating router and one
for the customer site behind the requesting router. This approach
works well with the unnumbered router model (i.e. routers on the link
have no globally scoped prefixes). Also the same approach applies to
the case where the prefix assigned to the requesting router link
through which it received DHCP messages does not in any way need to
be associated to the delegated prefixes.
There are architectures and link models, where a host (e.g. a mobile
router, also acting as a requesting router) always has a single (/64)
prefix configured on its uplink interface and the delegating router
is also requesting router's first hop router. Furthermore, it may be
required that the prefix configured on the uplink interface has to be
aggregatable with the delegated prefixes. This introduces a problem
how to use DHCPv6-PD together with stateless [RFC4862] or stateful
[RFC3315] address autoconfiguration on a link, where the /64
advertised on the link is also part of the prefix delegated (e.g /56)
Korhonen & Savolainen Expires March 6, 2011 [Page 3]
Internet-Draft PD Exclude Option September 2010
to the requesting router.
3.2. Available Workarounds
The problem described in Section 3.1 can be solved in a multiple of
ways. We list a number of possible solutions below that all allow a
natural aggregation of the /64 prefix used on the link and the
delegated prefix. Some of them are possible without modifications to
[RFC3633] protocol but require new functionality in the delegating
router or have other constraints.
1. Delegating and requesting router agree that a specific prefix
from a delegated prefix set can be configured and used on the
link where both delegating and requesting router are attached to.
Both delegating and requesting router have to understand new
enhanced DHCPv6-PD functionality and/or DHCPv6 options to achieve
the desired outcome. This solution is described in Section 3.3.
2. A delegating router delegates only half of the prefix that was
reserved for the requesting router. A /64 of the other half is
used for (point-to-point) link where the delegating and
requesting router are attached to. The other half of the
reserved prefix get delegated to the requesting router. This
solution has an obvious issue of "wasting" prefixes. One can
argue that IPv6 has no issue of address shortage but solutions
promoting greedy use of IPv6 prefixes should not advocated. This
solution is one possible fallback mechanism when the solution
described in Section 3.3 is not available in the requesting
router.
3. A delegating router delegates a prefix that was reserved for the
requesting router in a sets of longer prefixes. For example, if
the reserved prefix is a /56 then it can be delegated as a set of
/57, /58, /59, /60, /61, /62, /63 and one /64. The last
remaining /64 is the prefix assigned to the uplink of the
requesting router. The size of the DHCPv6 message may quickly
become an issue when the delegating any reasonable sized prefix.
This solution is one possible fallback mechanism when the
solution described in Section 3.3 is not available in the
requesting router. However, it is possible that legacy
requesting router implementations cannot handle multiple
delegated prefixes and therefore the solution 2) is probably a
safer choice for a fallback mechanism.
4. A requesting router requests a single /64 for each of its
downstream interfaces and a delegating router aggregates these
/64 prefixes into a larger allocation. The size of the DHCPv6
message may quickly become an issue when the delegating any
Korhonen & Savolainen Expires March 6, 2011 [Page 4]
Internet-Draft PD Exclude Option September 2010
reasonable sized prefix. This solution is one possible fallback
mechanism when the solution described in Section 3.3 is not
available in the delegating router. However, it is not granted
that legacy requesting router implementations can handle multiple
delegated prefixes and therefore the solution 2) is probably a
safer choice for a fallback mechanism.
3.3. Proposed Solution
This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE
(TBD1), that is used to exclude exactly one prefix from a delegated
prefix defined in the OPTION_IAPREFIX. The OPTION_PD_EXCLUDE MUST
only be included in the OPTION_IAPREFIX IAprefix-options field.
There can be zero or one OPTION_PD_EXCLUDE option in one
OPTION_IAPREFIX option. The OPTION_PD_EXCLUDE option allows prefix
delegation where a requesting router is delegated a prefix (e.g. /56)
and the delegating router uses one prefix (e.g. /64) on the link
through which it exchanges DHCPv6 messages with the requesting router
with a prefix out of the same delegated prefix set.
A requesting router SHOULD include an OPTION_ORO option with the
OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, Rebind,
Confirm or Information-request message to inform the delegating
router about the support for the prefix delegation functionality
defined in this specification. A delegating router MAY include an
OPTION_ORO option in a Reconfigure option to indicate which options
the requesting router should request from the delegating router.
The delegating router MAY include the unspecified address '::' in the
OPTION_PD_EXCLUDE as an indication that the option was understood but
there is no reason to exclude any prefix from the delegated prefix
set. Otherwise, the delegating router includes the prefix in the
OPTION_PD_EXCLUDE option that is excluded from the delegated prefix
set. The requesting router MUST NOT assign the excluded prefix to
any of its downstream interfaces.
4. Prefix Exclude Option
0 1 2 3
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_PD_EXCLUDE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix-len | IPv6-prefix (0 to 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Korhonen & Savolainen Expires March 6, 2011 [Page 5]
Internet-Draft PD Exclude Option September 2010
Prefix Exclude Option
o option-code: OPTION_PD_EXCLUDE (TBD1).
o option-len: 1 + length of prefix in octets. Valid option-lens are
between 1 and 17.
o prefix-len: The length of the excluded prefix in bits. Valid
prefix-lens are between 0 and 128. Prefix length of 0 means the
unspecified address '::'.
o IPv6-prefix: A variable length IPv6 prefix up to 128 bits. The
prefix MUST be zero padded to the next full octet boundary.
Trailing zero octets of the prefix SHOULD NOT be encoded into the
prefix field. The unspecified address MUST NOT be encoded at all.
The OPTION_PD_EXCLUDE option MUST only be included in the
OPTION_IAPREFIX IAprefix-options [RFC3633] field. The
OPTION_PD_EXCLUDE option MUST be located before the possible Status
Code option in the IAprefix-options field.
Any prefix excluded from the delegated prefix MUST be contained in
OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX.
The prefix included in the OPTION_PD_EXCLUDE option share the same
preferred-lifetime and valid-lifetime as the delegated prefix in the
'parent' OPTION_IAPREFIX option.
The prefix in the OPTION_PD_EXCLUDE option MUST be part of the
delegated prefix in the OPTION_IAPREFIX. For example, if the
requesting router has earlier been assigned a 2001:db8:dead:beef::/64
prefix by the delegating router, and the delegated prefix in the
OPTION_IAPREFIX is 2001:db8:dead:be00::/56, then the prefix in the
OPTION_PD_EXCLUDE option MUST be 2001:db8:dead:beef::/64.
5. Delegating Router Solicitation
The requesting router locates and selects a delegating router in the
same way as described in Section 11 [RFC3633]. This specification
only describes the additional steps required by the use of
OPTION_PD_EXCLUDE option.
5.1. Requesting Router
The requesting router may have an address configured on its uplink
interface of other scope than link-local and in this case the problem
described in Section 3.1 applies. If the requesting router implement
Korhonen & Savolainen Expires March 6, 2011 [Page 6]
Internet-Draft PD Exclude Option September 2010
the solution described in Section 3.3 then the requesting router MUST
include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option in
the Solicit message.
If the requesting router does not implement the solution described in
this specification (see Section 3.3, it might still be possible for
the requesting router to utilize the workaround 4) described in
Section 3.2 through configuration. In this case the delegating
router may still be able to delegate aggregated prefixes to the
requesting router.
Once receiving Advertisement message, the requesting router uses the
prefix(es) received in OPTION_PD_EXCLUDE in addition to the
advertised prefixes to choose the delegating router to respond to.
If Advertisement message did not include OPTION_PD_EXCLUDE option or
the prefix in the OPTION_PD_EXCLUDE option contains an unspecified
address '::', then the requesting router MUST fall back to normal
[RFC3633] behavior.
Editor's Note: is there actually deployment case when multiple
delegating routers would respond?
5.2. Delegating Router
If the OPTION_ORO option in the Solicit message includes the
OPTION_PD_EXCLUDE option code, then the delegating router knows that
the requesting router supports the solution defined in this
specification. If the Solicit message also contains an IA_PD option,
the delegating router can delegate to the requesting router a prefix
which includes the prefix already assigned to the requesting router's
uplink interface. The delegating router includes the prefix
originally or to be assigned to the requesting router in the
OPTION_PD_EXCLUDE option within the OPTION_IAPREFIX IAprefix-option
in the Advertise message.
If the OPTION_ORO option in the Solicit message does not include the
OPTION_PD_EXCLUDE option code, then the delegating router MUST fall
back to normal [RFC3633] behavior. However, the delegating router
could still delegate prefixes to the requesting router using
workarounds 2), 3) or 4) described in Section 3.2.
If the OPTION_ORO option in the Solicit message includes the
OPTION_PD_EXCLUDE option code but the delegating router does not
support the solution described in this specification, them the
delegating router acts as specified in [RFC3633]. The requesting
router MUST in this case also fall back to normal [RFC3633] behavior.
Korhonen & Savolainen Expires March 6, 2011 [Page 7]
Internet-Draft PD Exclude Option September 2010
6. Requesting Router Initiated Prefix Delegation
The procedures described in the following sections are aligned with
Section 12 of [RFC3633]. In this specification we only describe the
additional steps required by the use of OPTION_PD_EXCLUDE option.
6.1. Requesting Router
The requesting router behavior regarding the use of the
OPTION_PD_EXCLUDE option is more or less identical to step described
in Section 5.1. The only difference really is different used DHCPv6
messages.
The requesting router uses a Release message to return the delegated
prefix(es) to a delegating router. The prefix(es) to be released
MUST be included in the IA_PDs along with the excluded prefix
included in the OPTION_PD_EXCLUDE option. The requesting router MUST
NOT use the OPTION_PD_EXCLUDE option to introduce additional excluded
prefix in the Release message that it originally got a valid binding
for.
The requesting router must create sink routes for the delegated
prefixes minus the excluded prefixes. This may be done by creating
sink routes for delegated prefixes and more specific routes for the
excluded prefixes.
6.2. Delegating Router
The delegating router behavior regarding the use of the
OPTION_PD_EXCLUDE option is more or less identical to step described
in Section 5.2. The only difference really is DHCPv6 messages used
to carry the OPTION_PD_EXCLUDE option.
The delegating router may mark any prefix(es) in IA_PD Prefix options
in a Release message from a requesting router as 'available'
excluding the prefix included in the OPTION_PD_EXCLUDE options. If
the Release message contains 'new' excluded prefix in any
OPTION_PD_EXCLUDE option, the delegating router MUST send a Reply
message with Status Code set to NoBinding for that IA_PD option.
7. Security Considerations
Security considerations in DHCPv6 are described in Section 23 of
[RFC3315], and for DHCPv6 Prefix Delegation in Section 12 of
[RFC3633].
A malicious requesting router may unnecessarily fragment the
Korhonen & Savolainen Expires March 6, 2011 [Page 8]
Internet-Draft PD Exclude Option September 2010
delegating router prefix pools and cause additional load on the
delegating router by defining excluded prefix(es). The excluded
prefix(es) may cause the delegating router to react to neighbor
discovery messages other than just ignoring them.
8. IANA Considerations
A new DHCPv6 Option Code is reserved from DHCPv6 registry for DHCP
Option Codes.
OPTION_PD_EXCLUDE is set to TBD1
9. Acknowledgements
Authors would like to thank Ralph Droms, Frank Brockners, Ted Lemon,
Julien Laganier, Suresh Krishnan, Fredrik Garneij, Sri Gundavelli,
Mikael Abrahamsson and Deng Hui for their valuable comments and
discussions. Authors thank Ole Troan for his detailed review and
suggestions to improve the text.
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.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
10.2. Informative References
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
Korhonen & Savolainen Expires March 6, 2011 [Page 9]
Internet-Draft PD Exclude Option September 2010
Authors' Addresses
Jouni Korhonen
Nokia Siemens Networks
Linnoitustie 6
FI-02600 Espoo
Finland
Email: jouni.nospam@gmail.com
Teemu Savolainen
Nokia
Hermiankatu 12 D
FI-33720 Tampere
Finland
Email: teemu.savolainen@nokia.com
Korhonen & Savolainen Expires March 6, 2011 [Page 10]