One document matched: draft-korhonen-dhc-pd-exclude-00.txt
Dynamic Host Configuration (DHC) J. Korhonen
Internet-Draft Nokia Siemens Networks
Updates: 3633 (if approved) T. Savolainen
Intended status: Standards Track Nokia
Expires: January 6, 2011 July 5, 2010
Prefix Exclude Option for DHCPv6-based Prefix Delegation
draft-korhonen-dhc-pd-exclude-00.txt
Abstract
This specification defines an optional mechanism and the related
DHCPv6 option to allow exclusion of one or more specific prefixes
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 January 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 January 6, 2011 [Page 1]
Internet-Draft PD Exclude Option July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Prefix Delegation with Excluded Prefixes . . . . . . . . . . . 3
3.1. Problem Background . . . . . . . . . . . . . . . . . . . . 3
3.2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Prefix Exclude Option . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Korhonen & Savolainen Expires January 6, 2011 [Page 2]
Internet-Draft PD Exclude Option July 2010
1. Introduction
This specification defines an optional mechanism and the related
DHCPv6 option to allow exclusion of one or more specific prefixes
from a delegated prefix set when using DHCPv6-based prefix
delegation.
The prefix excluding mechanism is targeted to deployments where
DHCPv6-based prefix delegation is desired to be used but unnumbered
router model is not available. 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. Furthermore, the specification
allows the delegating router proactively to delegate prefix(es) with
'holes' in the delegated prefix(es).
2. Requirements and Terminology
2.1. Requirements
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].
2.2. Terminology
Addition to the terminology defined in [RFC3315] and [RFC3633] is
also used.
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 the requesting
router MUST NOT assign any delegated prefixes or subnets from the
delegated prefix(es) to the link through which it received the DHCP
message from the delegating router. This approach applies well to
unnumbered router model. 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 need to be in any way associated
to the delegated prefixes. However, in deployments where the prefix
assigned to the requesting router's uplink and the delegated prefixes
have to be tightly correlated, and actually the prefix assigned to
the link to which the router is attached must be from the delegated
prefixes, then the [RFC3633] as such is not enough. This concerns
Korhonen & Savolainen Expires January 6, 2011 [Page 3]
Internet-Draft PD Exclude Option July 2010
especially mobile wireless router deployments, where the link between
the requesting router and the delegating router must always be
assigned a valid prefix.
3.2. Solution
One solution to circumvent the limitations of [RFC3633] is defining a
new DHCPv6 option that allows excluding one or more prefixes from the
delegated prefix set. This specification defines a new option,
OPTION_PD_EXCLUDE (TBD1), that is used to exclude one or more
prefixes from the 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 more OPTION_PD_EXCLUDE
options in one OPTION_IAPREFIX option. Effectively, the
OPTION_PD_EXCLUDE option allows a prefix delegation where a mobile
router in the requesting router role is delegated one prefix (e.g.
/56) and the requesting router configures its link through which it
exchanges DHCPv6 messages with the delegating router using a prefix
out of the delegated prefix set. Alternatively the delegating router
can proactively delegate prefix(es) to the requesting router with
'holes' in the delegated prefix set, for example in cases where the
delegating router would not otherwise be able to satisfy requesting
router's request at all. Both delegating router and requesting
router are aware of these 'certain' prefixes using the
OPTION_PD_EXCLUDE option and act then accordingly.
The requesting router places the OPTION_PD_EXCLUDE option in the
corresponding OPTION_IAPREFIX option to inform the delegating router
about the support or a desire to exclude specific prefix(es) from the
delegated prefix set. If the requesting router knows in advance the
prefix(ex) that must be excluded or must not be part of any delegated
prefix set, such as prefixes used in requesting router's uplink
interface, then those prefixes MUST be included in the
OPTION_PD_EXCLUDE. If the requesting router includes a prefix
configured on its link in the OPTION_PD_EXCLUDE option, the
requesting router MUST have obtained the prefix using some means
(e.g. Stateless Address Autoconfiguration, or DHCPv6) before
requesting the delegating router for prefixes. Otherwise, the
requesting router just includes an undefined address (i.e. '::') as
an indication to the delegating router that it understands a
delegation where some specific prefix(es) MAY be excluded. 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.
The delegating router MAY include the undefined address in the
OPTION_PD_EXCLUDE as an indication that the option was understood but
Korhonen & Savolainen Expires January 6, 2011 [Page 4]
Internet-Draft PD Exclude Option July 2010
there is no reason to exclude any prefix(es) from the delegated
prefix set. Otherwise, the delegating router includes the prefix(es)
in the OPTION_PD_EXCLUDE option that are excluded from the delegated
prefix set and the requesting router MUST NOT assign to its own
subscriber networks.
The absence of the OPTION_PD_EXCLUDE in the OPTION_IAPREFIX option in
either direction (from a requesting router to a delegating router, or
vice versa) implies that the feature defined in this specification is
not supported.
In order to use the mechanism defined in this specification, the
delegating router and the address/prefix management entity assigning
prefixes to the requesting router (e.g. a mobile router) MUST be
tightly synchronized. Otherwise, the delegating router cannot really
delegate prefix(es) that would already contain the prefix(es) the
requesting router included in the OPTION_PD_EXCLUDE option.
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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(s) MUST only be included in the
OPTION_IAPREFIX IAprefix-options [RFC3633] field. The
Korhonen & Savolainen Expires January 6, 2011 [Page 5]
Internet-Draft PD Exclude Option July 2010
OPTION_PD_EXCLUDE option(s) 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(s) within the corresponding
OPTION_IAPREFIX. Therefore, the excluded prefix(es) MUST be part of
the prefix carried in the OPTION_IAPREFIX option, when the
OPTION_PD_EXCLUDE is anything else than the unspecified address '::'.
Prefix(es) included in the OPTION_PD_EXCLUDE option(s) share the same
preferred-lifetime and valid-lifetime as the delegated prefix in the
'parent' OPTION_IAPREFIX option.
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 prefixes in use that it wishes the
delegating router to be aware of; such as the prefix(es) assigned to
the link it uses to send and receive DHCPv6 messages with the
delegating router. In this case the requesting router MUST include
the prefix(es) into the OPTION_PD_EXCLUDE option in the
OPTION_IAPREFIX within the IA_PD option. For example, the requesting
would include the /64 prefix assigned to the link it uses to send and
receive DHCPv6 messages (this applies to the deployment case when
unnumbered router model is not used).
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 undefined
address (i.e. '::'), then the requesting router MUST fall back to
normal [RFC3633] behavior.
5.2. Delegating Router
If the requesting router included the IA_PD Prefix option with the
OPTION_PD_EXCLUDE option (within the OPTION_IAPREFIX IAprefix-
options) in the Solicit message, the delegating router MAY use the
OPTION_PD_EXCLUDE option provided information to assist the selection
of the prefix(es) to be delegated to the requesting router. For
Korhonen & Savolainen Expires January 6, 2011 [Page 6]
Internet-Draft PD Exclude Option July 2010
example, if the OPTION_PD_EXCLUDE option in the Solicit message
contains the prefix 2001:db8:abad:cafe::/64, then the delegating
router could delegate 2001:db8:abad:ca00::/56 (included in the
OPTION_IAPREFIX option) to the requesting router and state that 2001:
db8:abad:cafe::/64 is excluded from the delegated prefix using the
OPTION_PD_EXCLUDE option within the OPTION_IAPREFIX IAprefix-options.
If the prefix in the OPTION_PD_EXCLUDE sent by the requesting router
is not part of the prefix delegating router is delegating, the prefix
in OPTION_PD_EXCLUDE shall be ignored as irrelevant.
If the OPTION_PD_EXCLUDE option contains an undefined address (i.e.
'::') that informs the delegating router that the requesting router
implements the mechanism defined in this specification. In this case
the delegating router MAY choose to delegated prefix(es) with one or
more prefixes excluded from the otherwise continuous prefix set.
If the delegating router knows its address pool for delegation cannot
possibly be in conflict with prefix(es) used in requesting router's
uplink(s), it MAY choose to ignore all OPTION_PD_EXCLUDE options
requesting routers send.
If the delegating router chooses to delegate but not to exclude any
prefix(es) it MUST include the OPTION_PD_EXCLUDE option containing an
undefined address (i.e. '::') in the OPTION_IAPREFIX option within
the IA_PD option.
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 DHCPv6 messages used
to carry the OPTION_PD_EXCLUDE option(s).
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(es)
included in the OPTION_PD_EXCLUDE option. The requesting router MUST
NOT use the OPTION_PD_EXCLUDE option to introduce additional excluded
prefix(es) in the Release message that it originally got a valid
binding for.
Korhonen & Savolainen Expires January 6, 2011 [Page 7]
Internet-Draft PD Exclude Option July 2010
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(s).
The delegating router MAY choose, at any time, to delegate the
requesting router with a prefix with one or more prefixes excluded
from it. For example, the delegating router may delegate 2001:db8:
dead:ba00::/56 prefix to the requesting router but specifically
exclude 2001:db8:dead:bab0::/60 prefix from it. Effectively, the
requesting router gets delegated 240 usable prefixes instead of 256.
The delegating router may mark any prefix(es) in IA_PD Prefix options
in a Release message from a requesting router as 'available'
excluding prefix(es) included in the OPTION_PD_EXCLUDE options(s).
If the Release message contains 'new' excluded prefix(es) 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
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
Korhonen & Savolainen Expires January 6, 2011 [Page 8]
Internet-Draft PD Exclude Option July 2010
9. Acknowledgements
Authors would like to thank Ralph Droms, Ole Troan, Frank Brockners,
Julien Laganier, Suresh Krishnan, Fredrik Garneij, Sri Gundavelli,
and Deng Hui for their valuable comments and discussions.
10. 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.
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 January 6, 2011 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 07:35:52 |