Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Errata ExistInternet Engineering Task Force (IETF) J. Korhonen, Ed.Request for Comments: 6603 Nokia Siemens NetworksUpdates:3633 T. SavolainenCategory: Standards Track NokiaISSN: 2070-1721 S. Krishnan Ericsson O. Troan Cisco Systems, Inc May 2012Prefix Exclude Option for DHCPv6-based Prefix DelegationAbstract 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 updatesRFC 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 inSection 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttp://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 toBCP 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, et al. Standards Track [Page 1]
RFC 6603 PD Exclude Option May 2012Table of Contents1. Introduction ....................................................22. Requirements and Terminology ....................................23. Problem Background ..............................................34. Solution ........................................................34.1. Prefix Delegation with Excluded Prefixes ...................34.2. Prefix Exclude Option ......................................45. Delegating Router Solicitation ..................................65.1. Requesting Router ..........................................65.2. Delegating Router ..........................................66. Requesting Router Initiated Prefix Delegation ...................76.1. Requesting Router ..........................................76.2. Delegating Router ..........................................87. Security Considerations .........................................88. IANA Considerations .............................................89. Acknowledgements ................................................810. References .....................................................910.1. Normative References ......................................910.2. Informative References ....................................91. 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].Korhonen, et al. Standards Track [Page 2]
RFC 6603 PD Exclude Option May 20123. Problem Background DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit limitation described inSection 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. Solution4.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.Korhonen, et al. Standards Track [Page 3]
RFC 6603 PD Exclude Option May 2012 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.Korhonen, et al. Standards Track [Page 4]
RFC 6603 PD Exclude Option May 2012 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 requestingKorhonen, et al. Standards Track [Page 5]
RFC 6603 PD Exclude Option May 2012 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 = 35. Delegating Router Solicitation The requesting router locates and selects a delegating router in the same way as described inSection 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 inSection4.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 inSection 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 inSection 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 prefixKorhonen, et al. Standards Track [Page 6]
RFC 6603 PD Exclude Option May 2012 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 inSection 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 withSection 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 inSection 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 inSection 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 inSection 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.Korhonen, et al. Standards Track [Page 7]
RFC 6603 PD Exclude Option May 20126.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 inSection 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 inSection 23 of [RFC3315]. For DHCPv6 Prefix Delegation, they are described inSection 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 byRFC 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.Korhonen, et al. Standards Track [Page 8]
RFC 6603 PD Exclude Option May 201210. References10.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.Korhonen, et al. Standards Track [Page 9]
RFC 6603 PD Exclude Option May 2012Authors' 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.comKorhonen, et al. Standards Track [Page 10]
[8]ページ先頭