idnits 2.17.1 draft-ietf-dhc-pd-exclude-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3633, updated by this document, for RFC5378 checks: 2002-10-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 20, 2011) is 4482 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration (DHC) J. Korhonen, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Updates: 3633 (if approved) T. Savolainen 5 Intended status: Standards Track Nokia 6 Expires: June 22, 2012 S. Krishnan 7 Ericsson 8 O. Troan 9 Cisco Systems, Inc 10 December 20, 2011 12 Prefix Exclude Option for DHCPv6-based Prefix Delegation 13 draft-ietf-dhc-pd-exclude-04.txt 15 Abstract 17 This specification defines an optional mechanism to allow exclusion 18 of one specific prefix from a delegated prefix set when using DHCPv6- 19 based prefix delegation. The new mechanism updates RFC 3633. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 22, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3 57 3. Problem Background . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Prefix Delegation with Excluded Prefixes . . . . . . . . . 4 60 4.2. Prefix Exclude Option . . . . . . . . . . . . . . . . . . . 4 61 5. Delegating Router Solicitation . . . . . . . . . . . . . . . . 6 62 5.1. Requesting Router . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. Delegating Router . . . . . . . . . . . . . . . . . . . . . 7 64 6. Requesting Router Initiated Prefix Delegation . . . . . . . . . 7 65 6.1. Requesting Router . . . . . . . . . . . . . . . . . . . . . 7 66 6.2. Delegating Router . . . . . . . . . . . . . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 This specification defines an optional mechanism and the related 78 DHCPv6 option to allow exclusion of one specific prefix from a 79 delegated prefix set when using DHCPv6-based prefix delegation. 81 The prefix exclusion mechanism is targeted to deployments where 82 DHCPv6-based prefix delegation is used but a single aggregated route/ 83 prefix has to represent one customer, instead of using one prefix for 84 the link between the delegating router and the requesting router and 85 another prefix for the customer network. The mechanism defined in 86 this specification allows a delegating router to use a prefix out of 87 the delegated prefix set on the link through which it exchanges 88 DHCPv6 messages with the requesting router, and is intended for use 89 in networks where each requesting router is on its own layer 2 90 domain. 92 2. Requirements and Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Problem Background 100 DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit 101 limitation described in Section 12.1 of [RFC3633] that a prefix 102 delegated to a requesting router cannot be used by the delegating 103 router. This restriction implies that the delegating router will 104 have two (non aggregatable) routes towards a customer, one for the 105 link between the requesting router and the delegating router, and one 106 for the customer site behind the requesting router. 108 There are architectures and link models, where a host (e.g. a mobile 109 router, also acting as a requesting router) always has a single (/64) 110 prefix configured on its uplink interface and the delegating router 111 is also requesting router's first hop router. Furthermore, it may be 112 required that the prefix configured on the uplink interface has to be 113 aggregatable with the delegated prefixes. This introduces a problem 114 in how to use DHCPv6-PD together with stateless [RFC4862] or stateful 115 [RFC3315] address autoconfiguration on a link, where the /64 116 advertised on the link is also part of the prefix delegated (e.g /56) 117 to the requesting router. 119 4. Solution 121 4.1. Prefix Delegation with Excluded Prefixes 123 This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE 124 (TBD1), that is used to exclude exactly one prefix from a delegated 125 prefix. The OPTION_PD_EXCLUDE is included in the OPTION_IAPREFIX 126 IAprefix-options field. There can be at most one OPTION_PD_EXCLUDE 127 option in one OPTION_IAPREFIX option. The OPTION_PD_EXCLUDE option 128 allows prefix delegation where a requesting router is delegated a 129 prefix (e.g. /56) and the delegating router uses one prefix (e.g. 130 /64) on the link through which it exchanges DHCPv6 messages with the 131 requesting router with a prefix out of the same delegated prefix set. 133 A requesting router includes an OPTION_ORO option with the 134 OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, or Rebind 135 message to inform the delegating router about the support for the 136 prefix delegation functionality defined in this specification. A 137 delegating router may include the OPTION_PD_EXCLUDE option code in an 138 OPTION_ORO option in a Reconfigure message for indicating that the 139 requesting router should request OPTION_PD_EXCLUDE from the 140 delegating router. 142 The delegating router includes the prefix in the OPTION_PD_EXCLUDE 143 option that is excluded from the delegated prefix set. The 144 requesting router MUST NOT assign the excluded prefix to any of its 145 downstream interfaces. 147 4.2. Prefix Exclude Option 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | OPTION_PD_EXCLUDE | option-len | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | prefix-len | IPv6 subnet ID (1 to 16 octets) ~ 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Prefix Exclude Option 159 o option-code: OPTION_PD_EXCLUDE (TBD1). 161 o option-len: 1 + length of IPv6 subnet ID in octets. A valid 162 option-len is between 2 and 17. 164 o prefix-len: The length of the excluded prefix in bits. The 165 prefix-len MUST be between 'OPTION_IAPREFIX prefix-length'+1 and 166 128. 168 o IPv6 subnet ID: A variable length IPv6 subnet ID up to 128 bits. 170 The IPv6 subnet ID contains prefix-len minus 'OPTION_IAPREFIX prefix- 171 length' bits extracted from the excluded prefix starting from the bit 172 position 'OPTION_IAPREFIX prefix-length'. The extracted subnet ID 173 MUST be left shifted to start from a full octet boundary, i.e. left 174 shift of 'OPTION_IAPREFIX prefix-length' mod 8 bits. The subnet ID 175 MUST be zero padded to the next full octet boundary. 177 The encoding of the IPv6 subnet ID can be expressed in a C-like 178 pseudo code as shown below: 180 uint128_t p1; // the delegated IPv6 prefix 181 uint128_t p2; // the excluded IPv6 prefix 182 uint16_t a; // the OPTION_IAPREFIX prefix-length 183 uint8_t b; // the excluded IPv6 prefix length 184 uint8_t s; 186 // sanity checks 188 s = 128-a; // size of non-prefix bits 189 assert(b>a); // b must be at least a+1 190 assert(p1>>s == p2>>s); // p1 and p2 must share a common 191 // prefix of 'a' bits 193 // calculate the option content 195 uint16_t c = b-a-1; // the IPv6_subnet_ID_length-1 in bits 196 uint16_t d = (c/8)+1; // the IPv6_subnet_ID_length in octets 197 uint128_t p = p2< 0) { 209 *id++ = p>>120; 210 p <<= 8; 211 } 213 The OPTION_PD_EXCLUDE option MUST only be included in the 214 OPTION_IAPREFIX IAprefix-options [RFC3633] field. 216 Any prefix excluded from the delegated prefix MUST be contained in 217 OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX. 219 The prefix included in the OPTION_PD_EXCLUDE option share the same 220 preferred-lifetime and valid-lifetime as the delegated prefix in the 221 encapsulating OPTION_IAPREFIX option. 223 The prefix in the OPTION_PD_EXCLUDE option MUST be part of the 224 delegated prefix in the OPTION_IAPREFIX. For example, the requesting 225 router has earlier been assigned a 2001:db8:dead:beef::/64 prefix by 226 the delegating router, and the delegated prefix in the 227 OPTION_IAPREFIX is 2001:db8:dead:bee0::/59. In this case, 2001:db8: 228 dead:beef::/64 is a valid prefix to be used in the OPTION_PD_EXCLUDE 229 option. The OPTION_PD_EXCLUDE option would be encoded as follows: 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | OPTION_PD_EXCLUDE | 2 | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | 64 |0|1|1|1|1|0|0|0| 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 ^ ^ 239 | | 240 | +- 3 zero padded bits follow 241 | 242 +- using C syntax: 0xef << (59 % 8) 243 Note: 59 mod 8 = 3 245 5. Delegating Router Solicitation 247 The requesting router locates and selects a delegating router in the 248 same way as described in Section 11 [RFC3633]. This specification 249 only describes the additional steps required by the use of 250 OPTION_PD_EXCLUDE option. 252 5.1. Requesting Router 254 If the requesting router implements the solution described in 255 Section 4.1 then the requesting router SHOULD include the 256 OPTION_PD_EXCLUDE option code in the OPTION_ORO option in Solicit 257 messages. 259 Once receiving Advertise message, the requesting router uses the 260 prefix(es) received in OPTION_PD_EXCLUDE in addition to the 261 advertised prefixes to choose the delegating router. Requesting 262 router MUST proceed to Prefix Delegation procedure described in 263 Section 6.1. If Advertise message did not include OPTION_PD_EXCLUDE 264 option, then the requesting router MUST fall back to normal [RFC3633] 265 Section 11.1 behavior. 267 5.2. Delegating Router 269 If the OPTION_ORO option in the Solicit message includes the 270 OPTION_PD_EXCLUDE option code, then the delegating router knows that 271 the requesting router supports the solution defined in this 272 specification. If the Solicit message also contains an IA_PD option, 273 the delegating router can delegate to the requesting router a prefix 274 which includes the prefix already assigned to the requesting router's 275 uplink interface. The delegating router includes the prefix 276 originally or to be assigned to the requesting router in the 277 OPTION_PD_EXCLUDE option within the OPTION_IAPREFIX IAprefix-option 278 in the Advertise message. 280 If the OPTION_ORO option in the Solicit message does not include the 281 OPTION_PD_EXCLUDE option code, then the delegating router MUST fall 282 back to normal [RFC3633] Section 11.2 behavior. 284 If the OPTION_ORO option in the Solicit message includes the 285 OPTION_PD_EXCLUDE option code but the delegating router does not 286 support the solution described in this specification, then the 287 delegating router acts as specified in [RFC3633]. The requesting 288 router MUST in this case also fall back to normal [RFC3633] behavior. 290 6. Requesting Router Initiated Prefix Delegation 292 The procedures described in the following sections are aligned with 293 Section 12 of [RFC3633]. In this specification we only describe the 294 additional steps required by the use of OPTION_PD_EXCLUDE option. 296 6.1. Requesting Router 298 The requesting router behavior regarding the use of the 299 OPTION_PD_EXCLUDE option is more or less identical to step described 300 in Section 5.1. The only difference really is different used DHCPv6 301 messages. The requesting router SHOULD include the OPTION_PD_EXCLUDE 302 option code in the OPTION_ORO option in DHCPv6 messages as described 303 in Section 22.7 of [RFC3315]. 305 The requesting router uses a Release message to return the delegated 306 prefix(es) to a delegating router. The prefix(es) to be released 307 MUST be included in the IA_PDs along with the excluded prefix 308 included in the OPTION_PD_EXCLUDE option. The requesting router MUST 309 NOT use the OPTION_PD_EXCLUDE option to introduce additional excluded 310 prefix in the Release message that it originally got a valid binding 311 for. 313 The requesting router must create sink routes for the delegated 314 prefixes minus the excluded prefixes. This may be done by creating 315 sink routes for delegated prefixes and more specific routes for the 316 excluded prefixes. 318 6.2. Delegating Router 320 The delegating router behavior regarding the use of the 321 OPTION_PD_EXCLUDE option is more or less identical to step described 322 in Section 5.2. The only difference really is DHCPv6 messages used 323 to carry the OPTION_PD_EXCLUDE option. 325 The delegating router may mark any prefix(es) in IA_PD Prefix options 326 in a Release message from a requesting router as 'available' 327 excluding the prefix included in the OPTION_PD_EXCLUDE options. If 328 the Release message contains 'new' excluded prefix in any 329 OPTION_PD_EXCLUDE option, the delegating router MUST send a Reply 330 message with Status Code set to NoBinding for that IA_PD option. 332 7. Security Considerations 334 Security considerations in DHCPv6 are described in Section 23 of 335 [RFC3315], and for DHCPv6 Prefix Delegation in Section 12 of 336 [RFC3633]. 338 8. IANA Considerations 340 A new DHCPv6 Option Code is reserved from DHCPv6 registry for DHCP 341 Option Codes. 343 OPTION_PD_EXCLUDE is set to TBD1 345 9. Acknowledgements 347 Authors would like to thank Ralph Droms, Frank Brockners, Ted Lemon, 348 Julien Laganier, Fredrik Garneij, Sri Gundavelli, Mikael Abrahamsson, 349 Behcet Sarikaya, Jyrki Soini, Deng Hui, Stephen Jacob, Hemant Singh, 350 Gaurav Halwasia, Lorenzo Colitti and Tomasz Mrugalski for their 351 valuable comments and discussions. 353 10. References 355 10.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 361 and M. Carney, "Dynamic Host Configuration Protocol for 362 IPv6 (DHCPv6)", RFC 3315, July 2003. 364 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 365 Host Configuration Protocol (DHCP) version 6", RFC 3633, 366 December 2003. 368 10.2. Informative References 370 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 371 Address Autoconfiguration", RFC 4862, September 2007. 373 Authors' Addresses 375 Jouni Korhonen (editor) 376 Nokia Siemens Networks 377 Linnoitustie 6 378 FI-02600 Espoo 379 Finland 381 Email: jouni.nospam@gmail.com 383 Teemu Savolainen 384 Nokia 385 Hermiankatu 12 D 386 FI-33720 Tampere 387 Finland 389 Email: teemu.savolainen@nokia.com 390 Suresh Krishnan 391 Ericsson 392 8400 Decarie Blvd. 393 Town of Mount Royal, QC 394 Canada 396 Email: suresh.krishnan@ericsson.com 398 Ole Troan 399 Cisco Systems, Inc 400 Oslo 401 Norway 403 Email: ot@cisco.com