DHCPv6 PD Exclude: Prefix Exclude Option for DHCPv6-based Prefix Delegation
Lets a DHCPv6 server carve one prefix out of a delegated block, such as the one already used on the link.
Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, <https://www.rfc-editor.org/info/rfc6603>.
@misc{rfc6603,
series = {Request for Comments},
number = 6603,
howpublished = {RFC 6603},
publisher = {RFC Editor},
doi = {10.17487/RFC6603},
url = {https://www.rfc-editor.org/info/rfc6603},
author = {J. Korhonen and T. Savolainen and S. Krishnan and O. Troan},
title = {{Prefix Exclude Option for DHCPv6-based Prefix Delegation}},
pagetotal = 10,
year = 2012,
month = may,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 6603 Nokia Siemens Networks
Updates: 3633 T. Savolainen
Category: Standards Track Nokia
ISSN: 2070-1721 S. Krishnan
Ericsson
O. Troan
Cisco Systems, Inc
May 2012
Prefix Exclude Option for DHCPv6-based Prefix Delegation
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. The new mechanism updates RFC 3633.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
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 (c) 2012 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.
Table of Contents
1. Introduction ....................................................2
2. Requirements and Terminology ....................................2
3. Problem Background ..............................................3
4. Solution ........................................................3
4.1. Prefix Delegation with Excluded Prefixes ...................3
4.2. Prefix Exclude Option ......................................4
5. Delegating Router Solicitation ..................................6
5.1. Requesting Router ..........................................6
5.2. Delegating Router ..........................................6
6. Requesting Router Initiated Prefix Delegation ...................7
6.1. Requesting Router ..........................................7
6.2. Delegating Router ..........................................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
9. Acknowledgements ................................................8
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
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 at deployments where
DHCPv6-based prefix delegation is used, but a single aggregated
route/prefix has to represent one customer, instead of using one
prefix for the link between the delegating router and the requesting
router and another prefix for the customer network. The mechanism
defined in this specification allows a delegating router to use a
prefix out of the delegated prefix set on the link through which it
exchanges DHCPv6 messages with the requesting router, and is intended
for use in networks where each requesting router is on its own
layer-2 domain.
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. 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.
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 the 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 in how to use DHCPv6-PD together with stateless [RFC4862]
or stateful [RFC3315] address autoconfiguration on a link where the
/64 advertised is also part of the prefix delegated (e.g., /56) to
the requesting router.
4. Solution
4.1. Prefix Delegation with Excluded Prefixes
This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE
(67), that is used to exclude exactly one prefix from a delegated
prefix. The OPTION_PD_EXCLUDE is included in the OPTION_IAPREFIX
IAprefix-options field. There can be at most 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 includes an OPTION_ORO option with the
OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, or Rebind
message to inform the delegating router about the support for the
prefix delegation functionality defined in this specification. A
delegating router may include the OPTION_PD_EXCLUDE option code in an
OPTION_ORO option in a Reconfigure message to indicate that the
requesting router should request OPTION_PD_EXCLUDE from the
delegating router.
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.2. 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 subnet ID (1 to 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix Exclude Option
o option-code: OPTION_PD_EXCLUDE (67).
o option-len: 1 + length of IPv6 subnet ID in octets. A valid
option-len is between 2 and 17.
o prefix-len: The length of the excluded prefix in bits. The
prefix-len MUST be between 'OPTION_IAPREFIX prefix-length'+1 and
128.
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-
length' bits extracted from the excluded prefix starting from the bit
position 'OPTION_IAPREFIX prefix-length'. The extracted subnet ID
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
MUST be zero-padded to the next full octet boundary.
The encoding of the IPv6 subnet ID can be expressed in a C-like
pseudocode as shown below:
uint128_t p1; // the delegated IPv6 prefix
uint128_t p2; // the excluded IPv6 prefix
uint16_t a; // the OPTION_IAPREFIX prefix-length
uint8_t b; // the excluded IPv6 prefix length
uint8_t s;
// sanity checks
s = 128-a; // size of non-prefix bits
assert(b>a); // b must be at least a+1
assert(p1>>s == p2>>s); // p1 and p2 must share a common
// prefix of 'a' bits
// calculate the option content
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
uint128_t p = p2<<a; // p is the IPv6 subnet ID that has the
// common p1 prefix left-shifted out to
// a full octet boundary (trailing bits
// are zeroed)
// populate the option
uint8_t* id = &OPTION_PD_EXCLUDE.IPv6_subnet_ID;
OPTION_PD_EXCLUDE.option_len = d+1;
OPTION_PD_EXCLUDE.prefix_len = b;
while (d-- > 0) {
*id++ = p>>120;
p <<= 8;
}
The OPTION_PD_EXCLUDE option MUST only be included in the
OPTION_IAPREFIX IAprefix-options [RFC3633] 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 shares the same
preferred-lifetime and valid-lifetime as the delegated prefix in the
encapsulating OPTION_IAPREFIX option.
The prefix in the OPTION_PD_EXCLUDE option MUST be part of the
delegated prefix in the OPTION_IAPREFIX. For example, 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:bee0::/59. In this case, 2001:db8:
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:
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 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 |0|1|1|1|1|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^
| |
| +- 3 zero-padded bits follow
|
+- using C syntax: 0xef << (59 % 8)
Note: 59 mod 8 = 3
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 the
OPTION_PD_EXCLUDE option.
5.1. Requesting Router
If the requesting router implements the solution described in Section
4.1, then the requesting router SHOULD include the OPTION_PD_EXCLUDE
option code in the OPTION_ORO option in Solicit messages.
Once receiving Advertise message(s), the requesting router uses the
prefix(es) received in OPTION_PD_EXCLUDE, in addition to the
advertised prefixes, to choose the delegating router. The requesting
router MUST proceed to the Prefix Delegation procedure described in
Section 6.1. If the Advertise message did not include the
OPTION_PD_EXCLUDE option, then the requesting router MUST fall back
to normal behavior, as described in Section 11.1 of [RFC3633].
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
that 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 behavior, as described in Section 11.2 of [RFC3633].
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, then the
delegating router acts as specified in [RFC3633].
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 the OPTION_PD_EXCLUDE option.
6.1. Requesting Router
The requesting router behavior regarding the use of the
OPTION_PD_EXCLUDE option is mostly identical to the steps described
in Section 5.1, with the difference being the use of a DHCPv6 Request
instead of an Solicit message. 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 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
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 an additional
excluded prefix in the Release message for which it originally got a
valid binding.
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 the step
described in Section 5.2. The only difference is the DHCPv6 messages
used to carry the OPTION_PD_EXCLUDE option.
The delegating router may mark any prefix(es) in the 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 a 'new' excluded prefix in any
OPTION_PD_EXCLUDE option, the delegating router MUST send a Reply
message with the Status Code set to NoBinding for that IA_PD option.
7. Security Considerations
Security considerations for DHCPv6 are described in Section 23 of
[RFC3315]. For DHCPv6 Prefix Delegation, they are described in
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
A new DHCPv6 Option Code has been reserved from the "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)" registry for DHCP Option
Codes.
OPTION_PD_EXCLUDE (67)
9. Acknowledgements
The authors would like to thank Ralph Droms, Frank Brockners, Ted
Lemon, Julien Laganier, Fredrik Garneij, Sri Gundavelli, Mikael
Abrahamsson, Behcet Sarikaya, Jyrki Soini, Deng Hui, Stephen Jacob,
Hemant Singh, Gaurav Halwasia, Lorenzo Colitti, and Tomasz Mrugalski
for their valuable comments and discussions.
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., Ed., 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.
Authors' Addresses
Jouni Korhonen (editor)
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
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
EMail: suresh.krishnan@ericsson.com
Ole Troan
Cisco Systems, Inc
Oslo
Norway
EMail: ot@cisco.com
ISO Plain Language
On this page
§1What the Option Is For
The RFC defines an optional mechanism and the related DHCPv6 option that allow one specific prefix to be excluded from a delegated prefix set when DHCPv6-based prefix delegation is used.
The mechanism targets deployments where prefix delegation is used but a single aggregated route or prefix has to represent one customer, instead of one prefix for the link between the delegating router and the requesting router and another for the customer network behind it. It lets the delegating router use a prefix out of the delegated prefix set on the link through which it exchanges DHCPv6 messages with the requesting router. It is intended for networks where each requesting router is on its own layer 2 domain.
Some networks want a single route that covers the whole customer, rather than two routes: one for the link between the routers and one for the site behind them. The rule that stops the handing-over router from using any of the delegated block is what forces the second route.
This RFC lets the handing-over router keep one prefix out of the block for its own link, and it is meant for networks where each customer router sits on its own local network segment.
§3The Problem the Rule Causes
DHCPv6 prefix delegation, defined in RFC 3633, has an explicit limitation: a prefix delegated to a requesting router cannot be used by the delegating router. The delegating router therefore ends up with two routes towards a customer that cannot be aggregated, one for the link between the requesting router and the delegating router and one for the customer site behind the requesting router.
There are architectures and link models where a host, for example a mobile router that is also acting as a requesting router, always has a single /64 prefix configured on its uplink interface, and the delegating router is also the requesting router's first-hop router. It may also be required that the prefix configured on the uplink interface has to be aggregatable with the delegated prefixes. That combination creates a problem for DHCPv6 prefix delegation together with stateless (RFC 4862) or stateful (RFC 3315) address autoconfiguration on a link where the /64 that is advertised is also part of the prefix delegated to the requesting router, for example a /56.
The rule exists because the block of addresses is meant to belong entirely to the customer. Because of it, the network carries two routes towards that customer, and the two cannot be combined into one.
The problem appears on mobile and other single-homed routers, which always have one prefix on the link to the provider and take their addresses from the provider's router. There the prefix on the link is often part of the same larger block the provider is about to delegate, and the provider needs the two to be combinable into a single route.
§4.1The Solution: One Excluded Prefix
The RFC defines a new DHCPv6 option, OPTION_PD_EXCLUDE, code 67, used to exclude exactly one prefix from a delegated prefix. It is included in the OPTION_IAPREFIX IAprefix-options field, and there can be at most one such option in one OPTION_IAPREFIX option.
The arrangement it allows is that the requesting router is delegated a prefix, for example a /56, and the delegating router uses one prefix, for example a /64, on the link through which it exchanges DHCPv6 messages with the requesting router, taken from that same delegated set.
A requesting router includes the OPTION_PD_EXCLUDE option code in an OPTION_ORO option in a Solicit, Request, Renew or Rebind message, to tell the delegating router that it supports the mechanism. A delegating router may include the same option code in an OPTION_ORO option in a Reconfigure message to ask the requesting router to request it.
The delegating router then includes in the OPTION_PD_EXCLUDE option the prefix that is excluded from the delegated prefix set, and the requesting router MUST NOT assign the excluded prefix to any of its downstream interfaces.
The new option sits inside the option that carries the delegated block, and it names exactly one prefix to hold back. The block that is delegated can be a /56, while the provider's own link to the customer router keeps a /64 taken from that same /56.
The customer router says in its request that it understands the option, so the provider only uses it with routers that can cope. The rule for the other side is simple: the prefix named in the option must not be used on any of the customer router's own downstream interfaces.
§4.2How the Option Is Encoded
The option has four fields. The option code is OPTION_PD_EXCLUDE, 67. The option-len is 1 plus the length of the IPv6 subnet ID in octets, so a valid value is between 2 and 17. The prefix-len is the length of the excluded prefix in bits, and it MUST be between the OPTION_IAPREFIX prefix-length plus 1 and 128. The IPv6 subnet ID is a variable-length value of up to 128 bits.
The subnet ID carries only the bits that distinguish the excluded prefix from the delegated one: it holds prefix-len minus the OPTION_IAPREFIX prefix-length bits taken from the excluded prefix starting at bit position OPTION_IAPREFIX prefix-length. Those bits are then left-shifted so that they start on a full octet boundary, a shift of OPTION_IAPREFIX prefix-length modulo 8 bits, and the result is zero-padded to the next full octet boundary. The RFC gives the calculation as C-like pseudocode and also as a worked example: a router that was assigned 2001:db8:dead:beef::/64 while the delegated prefix is 2001:db8:dead:bee0::/59 encodes the excluded prefix with a prefix-len of 64 and a single octet of subnet ID, because the two prefixes differ in only a few bits.
Three rules apply to the option's placement and content. It MUST only be included in the OPTION_IAPREFIX IAprefix-options field. Any prefix excluded from the delegated prefix MUST be contained in an OPTION_PD_EXCLUDE option within the corresponding OPTION_IAPREFIX. And the prefix in the option MUST be part of the delegated prefix in the OPTION_IAPREFIX; the excluded prefix also shares the same preferred-lifetime and valid-lifetime as the delegated prefix.
The option is small. It has the usual code and length, then one byte giving the length in bits of the prefix being held back, then the bits that distinguish that prefix from the delegated one. Those bits are packed to the left so that they fill whole bytes, which saves space when the two prefixes are close together.
For example, a provider that delegates 2001:db8:dead:bee0::/59 and keeps 2001:db8:dead:beef::/64 for its own link needs only one byte to say so, because the two prefixes differ in a single bit position that the option can point at.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
OPTION-CODE | OPTION_PD_EXCLUDE | 2 bytes | 67 | The DHCPv6 option code. |
OPTION-LEN | option-len | 2 bytes | 2 | 1 plus the length of the IPv6 subnet ID in octets. |
PREFIX-LEN | prefix-len | 1 byte | 64 | Length of the excluded prefix in bits. |
SUBNET-ID | IPv6 subnet ID | 1 byte | The bits that distinguish the excluded prefix from the delegated one, left-shifted to a full octet boundary and zero-padded. |
uint128_t p1; // the delegated IPv6 prefix
uint128_t p2; // the excluded IPv6 prefix
uint16_t a; // the OPTION_IAPREFIX prefix-length
uint8_t b; // the excluded IPv6 prefix length
uint8_t s;
// sanity checks
s = 128-a; // size of non-prefix bits
assert(b>a); // b must be at least a+1
assert(p1>>s == p2>>s); // p1 and p2 must share a common
// prefix of 'a' bits
// calculate the option content
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
uint128_t p = p2<<a; // p is the IPv6 subnet ID that has the
// common p1 prefix left-shifted out to
// a full octet boundary§5Solicitation and Prefix Delegation
The requesting router finds and selects a delegating router in the same way as described in Section 11 of RFC 3633, and the RFC describes only the extra steps that the option requires.
On the requesting router side, if it implements the mechanism it SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option of Solicit messages. On receiving the Advertise messages, it uses the prefixes received in OPTION_PD_EXCLUDE, in addition to the advertised prefixes, to choose the delegating router, and MUST then proceed with the prefix delegation procedure. If the Advertise message did not include the option, it MUST fall back to the normal behaviour of Section 11.1 of RFC 3633.
On the delegating router side, if the OPTION_ORO option in the Solicit includes the option code, the delegating router knows the requesting router supports the mechanism. If the Solicit also contains an IA_PD option, the delegating router can delegate a prefix that includes the prefix already assigned to the requesting router's uplink interface, and it includes that prefix in the OPTION_PD_EXCLUDE option within the OPTION_IAPREFIX IAprefix-option of the Advertise message. If the OPTION_ORO does not include the option code, the delegating router MUST fall back to the normal behaviour of Section 11.2 of RFC 3633. If the option code is present but the delegating router does not support the mechanism, it acts as specified in RFC 3633.
The same steps apply to a requesting router initiated delegation, using a Request message instead of a Solicit. The requesting router returns the delegated prefixes with a Release message, and the prefixes to be released MUST be included in the IA_PDs along with the excluded prefix from the OPTION_PD_EXCLUDE option. It MUST NOT use the option to introduce an additional excluded prefix in the Release message for which it originally got a valid binding. The requesting router must create sink routes for the delegated prefixes minus the excluded prefixes, which can be done by creating sink routes for the delegated prefixes and more specific routes for the excluded prefixes. On the delegating router side, the prefixes in a Release message may be marked as available, excluding the prefix in the OPTION_PD_EXCLUDE options. If the Release message contains a new excluded prefix in any OPTION_PD_EXCLUDE option, the delegating router MUST send a Reply message with the Status Code set to NoBinding for that IA_PD option.
The exchange is an ordinary DHCPv6 one with one addition. The customer router lists the new option code among the options it asks for, and the provider, if it supports the mechanism, answers with the block of prefixes and names the one prefix it is keeping for the link.
If the provider's answer does not contain the option, the customer router goes back to the ordinary rules. If the customer router asks for an option the provider does not support, the provider simply behaves as before.
When the customer router later hands the prefixes back with a Release message, it must send the excluded prefix along with them, and it must not use the option to hold back a prefix it was never given. If it does, the provider answers with a Reply that says there is no such binding.
- SolicitThe client lists option code 67 among the options it asks for.
- AdvertiseThe server sends the delegated prefix and, inside it, the excluded prefix for its own link.
- RequestThe client asks for the delegated prefix in the ordinary way.
- ReplyThe binding is created, with the excluded prefix named again.
§7Security Considerations
The security considerations for DHCPv6 are described in Section 23 of RFC 3315, and those for DHCPv6 prefix delegation in Section 15 of RFC 3633, which also gives recommendations for protection against prefix delegation attacks. This RFC adds no new security considerations beyond those provided by RFC 3633.
The document adds no new security rules. The rules that already apply to DHCPv6 and to prefix delegation apply here too, including the advice about defending against attacks that abuse prefix delegation.