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]