idnits 2.17.1 draft-korhonen-dhc-pd-exclude-02.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3633, but the abstract doesn't seem to mention this, which it should. 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 (September 14, 2010) is 4966 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 (==), 3 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: March 18, 2011 S. Krishnan 7 Ericsson 8 O. Troan 9 Cisco Systems, Inc 10 September 14, 2010 12 Prefix Exclude Option for DHCPv6-based Prefix Delegation 13 draft-korhonen-dhc-pd-exclude-02.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. 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 March 18, 2011. 38 Copyright Notice 40 Copyright (c) 2010 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. Prefix Delegation with Excluded Prefixes . . . . . . . . . . . 3 58 3.1. Problem Background . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . 4 60 4. Prefix Exclude Option . . . . . . . . . . . . . . . . . . . . . 4 61 5. Delegating Router Solicitation . . . . . . . . . . . . . . . . 6 62 5.1. Requesting Router . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. Delegating Router . . . . . . . . . . . . . . . . . . . . . 6 64 6. Requesting Router Initiated Prefix Delegation . . . . . . . . . 7 65 6.1. Requesting Router . . . . . . . . . . . . . . . . . . . . . 7 66 6.2. Delegating Router . . . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 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 aggregatable 83 route/prefix has to represents one customer, instead of using one 84 prefix for the link between the delegating router and the requesting 85 router and another prefix for the customer network. The mechanism 86 defined in this specification allows a delegating router to use a 87 prefix out of the delegated prefix set on the link through which it 88 exchanges DHCPv6 messages with the requesting router. 90 2. Requirements and Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Prefix Delegation with Excluded Prefixes 98 3.1. 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. This approach 107 works well with the unnumbered router model (i.e. routers on the link 108 have no globally scoped prefixes). Also the same approach applies to 109 the case where the prefix assigned to the requesting router link 110 through which it received DHCP messages does not in any way need to 111 be associated to the delegated prefixes. 113 There are architectures and link models, where a host (e.g. a mobile 114 router, also acting as a requesting router) always has a single (/64) 115 prefix configured on its uplink interface and the delegating router 116 is also requesting router's first hop router. Furthermore, it may be 117 required that the prefix configured on the uplink interface has to be 118 aggregatable with the delegated prefixes. This introduces a problem 119 in how to use DHCPv6-PD together with stateless [RFC4862] or stateful 120 [RFC3315] address autoconfiguration on a link, where the /64 121 advertised on the link is also part of the prefix delegated (e.g /56) 122 to the requesting router. 124 3.2. Proposed Solution 126 This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE 127 (TBD1), that is used to exclude exactly one prefix from a delegated 128 prefix. The OPTION_PD_EXCLUDE MUST only be included in the 129 OPTION_IAPREFIX IAprefix-options field. There can be at most one 130 OPTION_PD_EXCLUDE option in one OPTION_IAPREFIX option. The 131 OPTION_PD_EXCLUDE option allows prefix delegation where a requesting 132 router is delegated a prefix (e.g. /56) and the delegating router 133 uses one prefix (e.g. /64) on the link through which it exchanges 134 DHCPv6 messages with the requesting router with a prefix out of the 135 same delegated prefix set. 137 A requesting router SHOULD include an OPTION_ORO option with the 138 OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, Rebind or 139 Confirm message to inform the delegating router about the support for 140 the prefix delegation functionality defined in this specification. A 141 delegating router MAY include the OPTION_PD_EXCLUDE option code in an 142 OPTION_ORO option in a Reconfigure message for indicating that the 143 requesting router should request OPTION_PD_EXCLUDE from the 144 delegating router. 146 The delegating router includes the prefix in the OPTION_PD_EXCLUDE 147 option that is excluded from the delegated prefix set. The 148 requesting router MUST NOT assign the excluded prefix to any of its 149 downstream interfaces. 151 4. Prefix Exclude Option 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | OPTION_PD_EXCLUDE | option-len | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | prefix-len | IPv6 subnet ID (1 to 16 octets) ~ 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Prefix Exclude Option 163 o option-code: OPTION_PD_EXCLUDE (TBD1). 165 o option-len: 1 + length of IPv6 subnet ID in octets. A valid 166 option-len is between 2 and 17. 168 o prefix-len: The length of the excluded prefix in bits. The 169 prefix-len MUST be between 'OPTION_IAPREFIX prefix-length'+1 and 170 128. 172 o IPv6 subnet ID: A variable length IPv6 subnet ID up to 128 bits. 173 The subnet ID contains prefix-len minus 'OPTION_IAPREFIX prefix- 174 length' bits extracted from the excluded prefix starting from the 175 bit position 'OPTION_IAPREFIX prefix-length'. The extracted 176 subnet ID MUST be left shifted to start from a full octet 177 boundary, i.e. left shift of 'OPTION_IAPREFIX prefix-length' mod 7 178 bits. The subnet ID MUST be zero padded to the next full octet 179 boundary. 181 The OPTION_PD_EXCLUDE option MUST only be included in the 182 OPTION_IAPREFIX IAprefix-options [RFC3633] field. The 183 OPTION_PD_EXCLUDE option MUST be located before the possible Status 184 Code option in the IAprefix-options field. 186 Any prefix excluded from the delegated prefix MUST be contained in 187 OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX. 189 The prefix included in the OPTION_PD_EXCLUDE option share the same 190 preferred-lifetime and valid-lifetime as the delegated prefix in the 191 encapsulating OPTION_IAPREFIX option. 193 The prefix in the OPTION_PD_EXCLUDE option MUST be part of the 194 delegated prefix in the OPTION_IAPREFIX. For example, the requesting 195 router has earlier been assigned a 2001:db8:dead:beef::/64 prefix by 196 the delegating router, and the delegated prefix in the 197 OPTION_IAPREFIX is 2001:db8:dead:bee0::/59. In this case, 2001:db8: 198 dead:beef::/64 is a valid prefix to be used in the OPTION_PD_EXCLUDE 199 option. The OPTION_PD_EXCLUDE option would be encoded as follows: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | OPTION_PD_EXCLUDE | 2 | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | 64 |0|1|1|1|1|0|0|0| 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 ^ ^ 209 | | 210 | +- 3 zero padded bits follow 211 | 212 +- using C syntax: (0xef & 0x1f) << 3 214 5. Delegating Router Solicitation 216 The requesting router locates and selects a delegating router in the 217 same way as described in Section 11 [RFC3633]. This specification 218 only describes the additional steps required by the use of 219 OPTION_PD_EXCLUDE option. 221 5.1. Requesting Router 223 If the requesting router implement the solution described in 224 Section 3.2 then the requesting router MUST include the 225 OPTION_PD_EXCLUDE option code in the OPTION_ORO option in the Solicit 226 message. 228 Once receiving Advertise message, the requesting router uses the 229 prefix(es) received in OPTION_PD_EXCLUDE in addition to the 230 advertised prefixes to choose the delegating router to respond to. 231 If Advertise message did not include OPTION_PD_EXCLUDE option, then 232 the requesting router MUST fall back to normal [RFC3633] behavior. 234 Editor's Note: is there actually deployment case when multiple 235 delegating routers would respond? 237 5.2. Delegating Router 239 If the OPTION_ORO option in the Solicit message includes the 240 OPTION_PD_EXCLUDE option code, then the delegating router knows that 241 the requesting router supports the solution defined in this 242 specification. If the Solicit message also contains an IA_PD option, 243 the delegating router can delegate to the requesting router a prefix 244 which includes the prefix already assigned to the requesting router's 245 uplink interface. The delegating router includes the prefix 246 originally or to be assigned to the requesting router in the 247 OPTION_PD_EXCLUDE option within the OPTION_IAPREFIX IAprefix-option 248 in the Advertise message. 250 If the OPTION_ORO option in the Solicit message does not include the 251 OPTION_PD_EXCLUDE option code, then the delegating router MUST fall 252 back to normal [RFC3633] behavior. 254 If the OPTION_ORO option in the Solicit message includes the 255 OPTION_PD_EXCLUDE option code but the delegating router does not 256 support the solution described in this specification, them the 257 delegating router acts as specified in [RFC3633]. The requesting 258 router MUST in this case also fall back to normal [RFC3633] behavior. 260 6. Requesting Router Initiated Prefix Delegation 262 The procedures described in the following sections are aligned with 263 Section 12 of [RFC3633]. In this specification we only describe the 264 additional steps required by the use of OPTION_PD_EXCLUDE option. 266 6.1. Requesting Router 268 The requesting router behavior regarding the use of the 269 OPTION_PD_EXCLUDE option is more or less identical to step described 270 in Section 5.1. The only difference really is different used DHCPv6 271 messages. 273 The requesting router uses a Release message to return the delegated 274 prefix(es) to a delegating router. The prefix(es) to be released 275 MUST be included in the IA_PDs along with the excluded prefix 276 included in the OPTION_PD_EXCLUDE option. The requesting router MUST 277 NOT use the OPTION_PD_EXCLUDE option to introduce additional excluded 278 prefix in the Release message that it originally got a valid binding 279 for. 281 The requesting router must create sink routes for the delegated 282 prefixes minus the excluded prefixes. This may be done by creating 283 sink routes for delegated prefixes and more specific routes for the 284 excluded prefixes. 286 6.2. Delegating Router 288 The delegating router behavior regarding the use of the 289 OPTION_PD_EXCLUDE option is more or less identical to step described 290 in Section 5.2. The only difference really is DHCPv6 messages used 291 to carry the OPTION_PD_EXCLUDE option. 293 The delegating router may mark any prefix(es) in IA_PD Prefix options 294 in a Release message from a requesting router as 'available' 295 excluding the prefix included in the OPTION_PD_EXCLUDE options. If 296 the Release message contains 'new' excluded prefix in any 297 OPTION_PD_EXCLUDE option, the delegating router MUST send a Reply 298 message with Status Code set to NoBinding for that IA_PD option. 300 7. Security Considerations 302 Security considerations in DHCPv6 are described in Section 23 of 303 [RFC3315], and for DHCPv6 Prefix Delegation in Section 12 of 304 [RFC3633]. 306 8. IANA Considerations 308 A new DHCPv6 Option Code is reserved from DHCPv6 registry for DHCP 309 Option Codes. 311 OPTION_PD_EXCLUDE is set to TBD1 313 9. Acknowledgements 315 Authors would like to thank Ralph Droms, Frank Brockners, Ted Lemon, 316 Julien Laganier, Fredrik Garneij, Sri Gundavelli, Mikael Abrahamsson 317 and Deng Hui for their valuable comments and discussions. 319 10. References 321 10.1. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 327 and M. Carney, "Dynamic Host Configuration Protocol for 328 IPv6 (DHCPv6)", RFC 3315, July 2003. 330 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 331 Host Configuration Protocol (DHCP) version 6", RFC 3633, 332 December 2003. 334 10.2. Informative References 336 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 337 Address Autoconfiguration", RFC 4862, September 2007. 339 Authors' Addresses 341 Jouni Korhonen (editor) 342 Nokia Siemens Networks 343 Linnoitustie 6 344 FI-02600 Espoo 345 Finland 347 Email: jouni.nospam@gmail.com 348 Teemu Savolainen 349 Nokia 350 Hermiankatu 12 D 351 FI-33720 Tampere 352 Finland 354 Email: teemu.savolainen@nokia.com 356 Suresh Krishnan 357 Ericsson 358 8400 Decarie Blvd. 359 Town of Mount Royal, QC 360 Canada 362 Email: suresh.krishnan@ericsson.com 364 Ole Troan 365 Cisco Systems, Inc 366 Veversmauet 8 367 N-5017 BERGEN 368 Norway 370 Email: ot@cisco.com