draft-ietf-dhc-pd-exclude-04.txt   rfc6603.txt 
Dynamic Host Configuration (DHC) J. Korhonen, Ed. Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks Request for Comments: 6603 Nokia Siemens Networks
Updates: 3633 (if approved) T. Savolainen Updates: 3633 T. Savolainen
Intended status: Standards Track Nokia Category: Standards Track Nokia
Expires: June 22, 2012 S. Krishnan ISSN: 2070-1721 S. Krishnan
Ericsson Ericsson
O. Troan O. Troan
Cisco Systems, Inc Cisco Systems, Inc
December 20, 2011 May 2012
Prefix Exclude Option for DHCPv6-based Prefix Delegation Prefix Exclude Option for DHCPv6-based Prefix Delegation
draft-ietf-dhc-pd-exclude-04.txt
Abstract Abstract
This specification defines an optional mechanism to allow exclusion This specification defines an optional mechanism to allow exclusion
of one specific prefix from a delegated prefix set when using DHCPv6- of one specific prefix from a delegated prefix set when using
based prefix delegation. The new mechanism updates RFC 3633. DHCPv6-based prefix delegation. The new mechanism updates RFC 3633.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 22, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6603.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3 2. Requirements and Terminology ....................................2
3. Problem Background . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Background ..............................................3
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Solution ........................................................3
4.1. Prefix Delegation with Excluded Prefixes . . . . . . . . . 4 4.1. Prefix Delegation with Excluded Prefixes ...................3
4.2. Prefix Exclude Option . . . . . . . . . . . . . . . . . . . 4 4.2. Prefix Exclude Option ......................................4
5. Delegating Router Solicitation . . . . . . . . . . . . . . . . 6 5. Delegating Router Solicitation ..................................6
5.1. Requesting Router . . . . . . . . . . . . . . . . . . . . . 6 5.1. Requesting Router ..........................................6
5.2. Delegating Router . . . . . . . . . . . . . . . . . . . . . 7 5.2. Delegating Router ..........................................6
6. Requesting Router Initiated Prefix Delegation . . . . . . . . . 7 6. Requesting Router Initiated Prefix Delegation ...................7
6.1. Requesting Router . . . . . . . . . . . . . . . . . . . . . 7 6.1. Requesting Router ..........................................7
6.2. Delegating Router . . . . . . . . . . . . . . . . . . . . . 8 6.2. Delegating Router ..........................................8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations .........................................8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations .............................................8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements ................................................8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References .....................................................9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References ......................................9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References ....................................9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
This specification defines an optional mechanism and the related This specification defines an optional mechanism and the related
DHCPv6 option to allow exclusion of one specific prefix from a DHCPv6 option to allow exclusion of one specific prefix from a
delegated prefix set when using DHCPv6-based prefix delegation. delegated prefix set when using DHCPv6-based prefix delegation.
The prefix exclusion mechanism is targeted to deployments where The prefix exclusion mechanism is targeted at deployments where
DHCPv6-based prefix delegation is used but a single aggregated route/ DHCPv6-based prefix delegation is used, but a single aggregated
prefix has to represent one customer, instead of using one prefix for route/prefix has to represent one customer, instead of using one
the link between the delegating router and the requesting router and prefix for the link between the delegating router and the requesting
another prefix for the customer network. The mechanism defined in router and another prefix for the customer network. The mechanism
this specification allows a delegating router to use a prefix out of defined in this specification allows a delegating router to use a
the delegated prefix set on the link through which it exchanges prefix out of the delegated prefix set on the link through which it
DHCPv6 messages with the requesting router, and is intended for use exchanges DHCPv6 messages with the requesting router, and is intended
in networks where each requesting router is on its own layer 2 for use in networks where each requesting router is on its own
domain. layer-2 domain.
2. Requirements and Terminology 2. Requirements and Terminology
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. Problem Background 3. Problem Background
DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit
limitation described in Section 12.1 of [RFC3633] that a prefix limitation described in Section 12.1 of [RFC3633] that a prefix
delegated to a requesting router cannot be used by the delegating delegated to a requesting router cannot be used by the delegating
router. This restriction implies that the delegating router will router. This restriction implies that the delegating router will
have two (non aggregatable) routes towards a customer, one for the have two (non-aggregatable) routes towards a customer: one for the
link between the requesting router and the delegating router, and one link between the requesting router and the delegating router, and one
for the customer site behind the requesting router. for the customer site behind the requesting router.
There are architectures and link models, where a host (e.g. a mobile 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) router, also acting as a requesting router) always has a single (/64)
prefix configured on its uplink interface and the delegating router prefix configured on its uplink interface and the delegating router
is also requesting router's first hop router. Furthermore, it may be is also the requesting router's first-hop router. Furthermore, it
required that the prefix configured on the uplink interface has to be may be required that the prefix configured on the uplink interface
aggregatable with the delegated prefixes. This introduces a problem has to be aggregatable with the delegated prefixes. This introduces
in how to use DHCPv6-PD together with stateless [RFC4862] or stateful a problem in how to use DHCPv6-PD together with stateless [RFC4862]
[RFC3315] address autoconfiguration on a link, where the /64 or stateful [RFC3315] address autoconfiguration on a link where the
advertised on the link is also part of the prefix delegated (e.g /56) /64 advertised is also part of the prefix delegated (e.g., /56) to
to the requesting router. the requesting router.
4. Solution 4. Solution
4.1. Prefix Delegation with Excluded Prefixes 4.1. Prefix Delegation with Excluded Prefixes
This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE
(TBD1), that is used to exclude exactly one prefix from a delegated (67), that is used to exclude exactly one prefix from a delegated
prefix. The OPTION_PD_EXCLUDE is included in the OPTION_IAPREFIX prefix. The OPTION_PD_EXCLUDE is included in the OPTION_IAPREFIX
IAprefix-options field. There can be at most one OPTION_PD_EXCLUDE IAprefix-options field. There can be at most one OPTION_PD_EXCLUDE
option in one OPTION_IAPREFIX option. The OPTION_PD_EXCLUDE option option in one OPTION_IAPREFIX option. The OPTION_PD_EXCLUDE option
allows prefix delegation where a requesting router is delegated a allows prefix delegation where a requesting router is delegated a
prefix (e.g. /56) and the delegating router uses one prefix (e.g. 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 /64) on the link through which it exchanges DHCPv6 messages with the
requesting router with a prefix out of the same delegated prefix set. requesting router with a prefix out of the same delegated prefix set.
A requesting router includes an OPTION_ORO option with the A requesting router includes an OPTION_ORO option with the
OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, or Rebind OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, or Rebind
message to inform the delegating router about the support for the message to inform the delegating router about the support for the
prefix delegation functionality defined in this specification. A prefix delegation functionality defined in this specification. A
delegating router may include the OPTION_PD_EXCLUDE option code in an delegating router may include the OPTION_PD_EXCLUDE option code in an
OPTION_ORO option in a Reconfigure message for indicating that the OPTION_ORO option in a Reconfigure message to indicate that the
requesting router should request OPTION_PD_EXCLUDE from the requesting router should request OPTION_PD_EXCLUDE from the
delegating router. delegating router.
The delegating router includes the prefix in the OPTION_PD_EXCLUDE The delegating router includes the prefix in the OPTION_PD_EXCLUDE
option that is excluded from the delegated prefix set. The option that is excluded from the delegated prefix set. The
requesting router MUST NOT assign the excluded prefix to any of its requesting router MUST NOT assign the excluded prefix to any of its
downstream interfaces. downstream interfaces.
4.2. Prefix Exclude Option 4.2. Prefix Exclude Option
0 1 2 3 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 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 | | OPTION_PD_EXCLUDE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix-len | IPv6 subnet ID (1 to 16 octets) ~ | prefix-len | IPv6 subnet ID (1 to 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix Exclude Option Prefix Exclude Option
o option-code: OPTION_PD_EXCLUDE (TBD1). o option-code: OPTION_PD_EXCLUDE (67).
o option-len: 1 + length of IPv6 subnet ID in octets. A valid o option-len: 1 + length of IPv6 subnet ID in octets. A valid
option-len is between 2 and 17. option-len is between 2 and 17.
o prefix-len: The length of the excluded prefix in bits. The o prefix-len: The length of the excluded prefix in bits. The
prefix-len MUST be between 'OPTION_IAPREFIX prefix-length'+1 and prefix-len MUST be between 'OPTION_IAPREFIX prefix-length'+1 and
128. 128.
o IPv6 subnet ID: A variable length IPv6 subnet ID up to 128 bits. o IPv6 subnet ID: A variable-length IPv6 subnet ID up to 128 bits.
The IPv6 subnet ID contains prefix-len minus 'OPTION_IAPREFIX prefix- The IPv6 subnet ID contains prefix-len minus 'OPTION_IAPREFIX prefix-
length' bits extracted from the excluded prefix starting from the bit length' bits extracted from the excluded prefix starting from the bit
position 'OPTION_IAPREFIX prefix-length'. The extracted subnet ID position 'OPTION_IAPREFIX prefix-length'. The extracted subnet ID
MUST be left shifted to start from a full octet boundary, i.e. left MUST be left-shifted to start from a full octet boundary, i.e., left-
shift of 'OPTION_IAPREFIX prefix-length' mod 8 bits. The subnet ID shift of 'OPTION_IAPREFIX prefix-length' mod 8 bits. The subnet ID
MUST be zero padded to the next full octet boundary. MUST be zero-padded to the next full octet boundary.
The encoding of the IPv6 subnet ID can be expressed in a C-like The encoding of the IPv6 subnet ID can be expressed in a C-like
pseudo code as shown below: pseudocode as shown below:
uint128_t p1; // the delegated IPv6 prefix uint128_t p1; // the delegated IPv6 prefix
uint128_t p2; // the excluded IPv6 prefix uint128_t p2; // the excluded IPv6 prefix
uint16_t a; // the OPTION_IAPREFIX prefix-length uint16_t a; // the OPTION_IAPREFIX prefix-length
uint8_t b; // the excluded IPv6 prefix length uint8_t b; // the excluded IPv6 prefix length
uint8_t s; uint8_t s;
// sanity checks // sanity checks
s = 128-a; // size of non-prefix bits s = 128-a; // size of non-prefix bits
assert(b>a); // b must be at least a+1 assert(b>a); // b must be at least a+1
assert(p1>>s == p2>>s); // p1 and p2 must share a common assert(p1>>s == p2>>s); // p1 and p2 must share a common
// prefix of 'a' bits // prefix of 'a' bits
// calculate the option content // calculate the option content
uint16_t c = b-a-1; // the IPv6_subnet_ID_length-1 in bits uint16_t c = b-a-1; // the IPv6_subnet_ID_length-1 in bits
uint16_t d = (c/8)+1; // the IPv6_subnet_ID_length in octets uint16_t d = (c/8)+1; // the IPv6_subnet_ID_length in octets
uint128_t p = p2<<a; // p is the IPv6 subnet ID that has the uint128_t p = p2<<a; // p is the IPv6 subnet ID that has the
// common p1 prefix left shifted out to // common p1 prefix left-shifted out to
// a full octet boundary (trailing bits // a full octet boundary (trailing bits
// are zeroed) // are zeroed)
// populate the option // populate the option
uint8_t* id = &OPTION_PD_EXCLUDE.IPv6_subnet_ID; uint8_t* id = &OPTION_PD_EXCLUDE.IPv6_subnet_ID;
OPTION_PD_EXCLUDE.option_len = d+1; OPTION_PD_EXCLUDE.option_len = d+1;
OPTION_PD_EXCLUDE.prefix_len = b; OPTION_PD_EXCLUDE.prefix_len = b;
while (d-- > 0) { while (d-- > 0) {
*id++ = p>>120; *id++ = p>>120;
p <<= 8; p <<= 8;
} }
The OPTION_PD_EXCLUDE option MUST only be included in the The OPTION_PD_EXCLUDE option MUST only be included in the
OPTION_IAPREFIX IAprefix-options [RFC3633] field. OPTION_IAPREFIX IAprefix-options [RFC3633] field.
Any prefix excluded from the delegated prefix MUST be contained in Any prefix excluded from the delegated prefix MUST be contained in
OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX. OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX.
The prefix included in the OPTION_PD_EXCLUDE option share the same The prefix included in the OPTION_PD_EXCLUDE option shares the same
preferred-lifetime and valid-lifetime as the delegated prefix in the preferred-lifetime and valid-lifetime as the delegated prefix in the
encapsulating OPTION_IAPREFIX option. encapsulating OPTION_IAPREFIX option.
The prefix in the OPTION_PD_EXCLUDE option MUST be part of the The prefix in the OPTION_PD_EXCLUDE option MUST be part of the
delegated prefix in the OPTION_IAPREFIX. For example, the requesting delegated prefix in the OPTION_IAPREFIX. For example, the requesting
router has earlier been assigned a 2001:db8:dead:beef::/64 prefix by router has earlier been assigned a 2001:db8:dead:beef::/64 prefix by
the delegating router, and the delegated prefix in the the delegating router, and the delegated prefix in the
OPTION_IAPREFIX is 2001:db8:dead:bee0::/59. In this case, 2001:db8: OPTION_IAPREFIX is 2001:db8:dead:bee0::/59. In this case, 2001:db8:
dead:beef::/64 is a valid prefix to be used in the OPTION_PD_EXCLUDE dead:beef::/64 is a valid prefix to be used in the OPTION_PD_EXCLUDE
option. The OPTION_PD_EXCLUDE option would be encoded as follows: option. The OPTION_PD_EXCLUDE option would be encoded as follows:
0 1 2 3 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 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 | 2 | | OPTION_PD_EXCLUDE | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 |0|1|1|1|1|0|0|0| | 64 |0|1|1|1|1|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^ ^
| | | |
| +- 3 zero padded bits follow | +- 3 zero-padded bits follow
| |
+- using C syntax: 0xef << (59 % 8) +- using C syntax: 0xef << (59 % 8)
Note: 59 mod 8 = 3 Note: 59 mod 8 = 3
5. Delegating Router Solicitation 5. Delegating Router Solicitation
The requesting router locates and selects a delegating router in the The requesting router locates and selects a delegating router in the
same way as described in Section 11 [RFC3633]. This specification same way as described in Section 11 [RFC3633]. This specification
only describes the additional steps required by the use of only describes the additional steps required by the use of the
OPTION_PD_EXCLUDE option. OPTION_PD_EXCLUDE option.
5.1. Requesting Router 5.1. Requesting Router
If the requesting router implements the solution described in If the requesting router implements the solution described in Section
Section 4.1 then the requesting router SHOULD include the 4.1, then the requesting router SHOULD include the OPTION_PD_EXCLUDE
OPTION_PD_EXCLUDE option code in the OPTION_ORO option in Solicit option code in the OPTION_ORO option in Solicit messages.
messages.
Once receiving Advertise message, the requesting router uses the Once receiving Advertise message(s), the requesting router uses the
prefix(es) received in OPTION_PD_EXCLUDE in addition to the prefix(es) received in OPTION_PD_EXCLUDE, in addition to the
advertised prefixes to choose the delegating router. Requesting advertised prefixes, to choose the delegating router. The requesting
router MUST proceed to Prefix Delegation procedure described in router MUST proceed to the Prefix Delegation procedure described in
Section 6.1. If Advertise message did not include OPTION_PD_EXCLUDE Section 6.1. If the Advertise message did not include the
option, then the requesting router MUST fall back to normal [RFC3633] OPTION_PD_EXCLUDE option, then the requesting router MUST fall back
Section 11.1 behavior. to normal behavior, as described in Section 11.1 of [RFC3633].
5.2. Delegating Router 5.2. Delegating Router
If the OPTION_ORO option in the Solicit message includes the If the OPTION_ORO option in the Solicit message includes the
OPTION_PD_EXCLUDE option code, then the delegating router knows that OPTION_PD_EXCLUDE option code, then the delegating router knows that
the requesting router supports the solution defined in this the requesting router supports the solution defined in this
specification. If the Solicit message also contains an IA_PD option, specification. If the Solicit message also contains an IA_PD option,
the delegating router can delegate to the requesting router a prefix the delegating router can delegate to the requesting router a prefix
which includes the prefix already assigned to the requesting router's that includes the prefix already assigned to the requesting router's
uplink interface. The delegating router includes the prefix uplink interface. The delegating router includes the prefix
originally or to be assigned to the requesting router in the originally, or to be, assigned to the requesting router in the
OPTION_PD_EXCLUDE option within the OPTION_IAPREFIX IAprefix-option OPTION_PD_EXCLUDE option within the OPTION_IAPREFIX IAprefix-option
in the Advertise message. in the Advertise message.
If the OPTION_ORO option in the Solicit message does not include the If the OPTION_ORO option in the Solicit message does not include the
OPTION_PD_EXCLUDE option code, then the delegating router MUST fall OPTION_PD_EXCLUDE option code, then the delegating router MUST fall
back to normal [RFC3633] Section 11.2 behavior. back to normal behavior, as described in Section 11.2 of [RFC3633].
If the OPTION_ORO option in the Solicit message includes the If the OPTION_ORO option in the Solicit message includes the
OPTION_PD_EXCLUDE option code but the delegating router does not OPTION_PD_EXCLUDE option code but the delegating router does not
support the solution described in this specification, then the support the solution described in this specification, then the
delegating router acts as specified in [RFC3633]. The requesting delegating router acts as specified in [RFC3633].
router MUST in this case also fall back to normal [RFC3633] behavior.
6. Requesting Router Initiated Prefix Delegation 6. Requesting Router-Initiated Prefix Delegation
The procedures described in the following sections are aligned with The procedures described in the following sections are aligned with
Section 12 of [RFC3633]. In this specification we only describe the Section 12 of [RFC3633]. In this specification, we only describe the
additional steps required by the use of OPTION_PD_EXCLUDE option. additional steps required by the use of the OPTION_PD_EXCLUDE option.
6.1. Requesting Router 6.1. Requesting Router
The requesting router behavior regarding the use of the The requesting router behavior regarding the use of the
OPTION_PD_EXCLUDE option is more or less identical to step described OPTION_PD_EXCLUDE option is mostly identical to the steps described
in Section 5.1. The only difference really is different used DHCPv6 in Section 5.1, with the difference being the use of a DHCPv6 Request
messages. The requesting router SHOULD include the OPTION_PD_EXCLUDE instead of an Solicit message. The requesting router SHOULD include
option code in the OPTION_ORO option in DHCPv6 messages as described the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6
in Section 22.7 of [RFC3315]. messages as described in Section 22.7 of [RFC3315]. The requesting
router SHOULD include the OPTION_PD_EXCLUDE option code in the
OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of
[RFC3315].
The requesting router uses a Release message to return the delegated The requesting router uses a Release message to return the delegated
prefix(es) to a delegating router. The prefix(es) to be released prefix(es) to a delegating router. The prefix(es) to be released
MUST be included in the IA_PDs along with the excluded prefix MUST be included in the IA_PDs along with the excluded prefix
included in the OPTION_PD_EXCLUDE option. The requesting router MUST included in the OPTION_PD_EXCLUDE option. The requesting router MUST
NOT use the OPTION_PD_EXCLUDE option to introduce additional excluded NOT use the OPTION_PD_EXCLUDE option to introduce an additional
prefix in the Release message that it originally got a valid binding excluded prefix in the Release message for which it originally got a
for. valid binding.
The requesting router must create sink routes for the delegated The requesting router must create sink routes for the delegated
prefixes minus the excluded prefixes. This may be done by creating prefixes, minus the excluded prefixes. This may be done by creating
sink routes for delegated prefixes and more specific routes for the sink routes for delegated prefixes and more specific routes for the
excluded prefixes. excluded prefixes.
6.2. Delegating Router 6.2. Delegating Router
The delegating router behavior regarding the use of the The delegating router behavior regarding the use of the
OPTION_PD_EXCLUDE option is more or less identical to step described OPTION_PD_EXCLUDE option is more or less identical to the step
in Section 5.2. The only difference really is DHCPv6 messages used described in Section 5.2. The only difference is the DHCPv6 messages
to carry the OPTION_PD_EXCLUDE option. used to carry the OPTION_PD_EXCLUDE option.
The delegating router may mark any prefix(es) in IA_PD Prefix options The delegating router may mark any prefix(es) in the IA_PD Prefix
in a Release message from a requesting router as 'available' options in a Release message from a requesting router as 'available',
excluding the prefix included in the OPTION_PD_EXCLUDE options. If excluding the prefix included in the OPTION_PD_EXCLUDE options. If
the Release message contains 'new' excluded prefix in any the Release message contains a 'new' excluded prefix in any
OPTION_PD_EXCLUDE option, the delegating router MUST send a Reply OPTION_PD_EXCLUDE option, the delegating router MUST send a Reply
message with Status Code set to NoBinding for that IA_PD option. message with the Status Code set to NoBinding for that IA_PD option.
7. Security Considerations 7. Security Considerations
Security considerations in DHCPv6 are described in Section 23 of Security considerations for DHCPv6 are described in Section 23 of
[RFC3315], and for DHCPv6 Prefix Delegation in Section 12 of [RFC3315]. For DHCPv6 Prefix Delegation, they are described in
[RFC3633]. Section 15 of [RFC3633]. In particular, RFC 3633 provides
recommendations for protection against prefix delegation attacks.
This specification does not add any new security considerations
beyond those provided by RFC 3633.
8. IANA Considerations 8. IANA Considerations
A new DHCPv6 Option Code is reserved from DHCPv6 registry for DHCP A new DHCPv6 Option Code has been reserved from the "Dynamic Host
Option Codes. Configuration Protocol for IPv6 (DHCPv6)" registry for DHCP Option
Codes.
OPTION_PD_EXCLUDE is set to TBD1 OPTION_PD_EXCLUDE (67)
9. Acknowledgements 9. Acknowledgements
Authors would like to thank Ralph Droms, Frank Brockners, Ted Lemon, The authors would like to thank Ralph Droms, Frank Brockners, Ted
Julien Laganier, Fredrik Garneij, Sri Gundavelli, Mikael Abrahamsson, Lemon, Julien Laganier, Fredrik Garneij, Sri Gundavelli, Mikael
Behcet Sarikaya, Jyrki Soini, Deng Hui, Stephen Jacob, Hemant Singh, Abrahamsson, Behcet Sarikaya, Jyrki Soini, Deng Hui, Stephen Jacob,
Gaurav Halwasia, Lorenzo Colitti and Tomasz Mrugalski for their Hemant Singh, Gaurav Halwasia, Lorenzo Colitti, and Tomasz Mrugalski
valuable comments and discussions. for their valuable comments and discussions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
10.2. Informative References 10.2. Informative References
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
FI-02600 Espoo FI-02600 Espoo
Finland Finland
Email: jouni.nospam@gmail.com EMail: jouni.nospam@gmail.com
Teemu Savolainen Teemu Savolainen
Nokia Nokia
Hermiankatu 12 D Hermiankatu 12 D
FI-33720 Tampere FI-33720 Tampere
Finland Finland
Email: teemu.savolainen@nokia.com EMail: teemu.savolainen@nokia.com
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Email: suresh.krishnan@ericsson.com EMail: suresh.krishnan@ericsson.com
Ole Troan Ole Troan
Cisco Systems, Inc Cisco Systems, Inc
Oslo Oslo
Norway Norway
Email: ot@cisco.com EMail: ot@cisco.com
 End of changes. 50 change blocks. 
125 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/