idnits 2.17.1 draft-mrugalski-dhc-dhcpv6-4rd-00.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 abstract seems to contain references ([I-D.despres-intarea-4rd]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2011) is 4679 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) == Outdated reference: A later version (-17) exists of draft-ietf-dhc-option-guidelines-06 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC T. Mrugalski 3 Internet-Draft ISC 4 Intended status: Standards Track July 02, 2011 5 Expires: January 3, 2012 7 DHCPv6 Options for IPv4 Residual Deployment (4rd) 8 draft-mrugalski-dhc-dhcpv6-4rd-00 10 Abstract 12 This document specifies DHCPv6 options which are meant to be used by 13 4rd Customer Edge (CE) to obtain necessary parameters to configure 14 their 4rd automatic tunnels. The 4rd architecture is defined in 15 [I-D.despres-intarea-4rd]. Since specification of 4rd is still 16 expected to evolve, DHCPv6 options may have to evolve too to fit the 17 revised 4rd specification. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 3, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. DHCPv6 Options Format . . . . . . . . . . . . . . . . . . . . 3 56 3.1. 4rd Options Cardinality . . . . . . . . . . . . . . . . . 4 57 3.2. 4rd Mapping Rule Option . . . . . . . . . . . . . . . . . 4 58 3.3. CE IPv6 Prefix Option . . . . . . . . . . . . . . . . . . 5 59 3.4. CE IPv6 Prefix Length Option . . . . . . . . . . . . . . . 6 60 3.5. Domain 4rd Prefix Option . . . . . . . . . . . . . . . . . 6 61 3.6. Domain IPv6 Suffix Option . . . . . . . . . . . . . . . . 7 62 3.7. BR Anycast Option . . . . . . . . . . . . . . . . . . . . 8 63 4. 4rd Options Example . . . . . . . . . . . . . . . . . . . . . 8 64 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 8 65 6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Requirements Language 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 80 2. Introduction 82 IPv4 Residual Deployment across IPv6-Service networks (4rd) 83 [I-D.despres-intarea-4rd] is an automatic tunneling mechanism for 84 providing IPv4 connectivity service to end users over a service 85 provider's IPv6 network. To operate properly, 4rd Customer Edge (CE) 86 requires one or more mapping rules configured. One mapping rule 87 constists of the following parameters: Length of CE IPv6 Prefix, 88 Domain IPv6 Prefix, Domain 4rd Prefix, and optionally Domain IPv6 89 suffix. Also, Anycast BR IPv6 address must be configured for proper 90 operation. This document defines several DHCPv6 options that allow 91 delivery of required information to configure CE. Definitions of 92 enumerated parameters are provided in [I-D.despres-intarea-4rd]. 93 Since specification of 4rd is still expected to evolve, DHCPv6 94 options may have to evolve too to fit the revised 4rd specification. 96 3. DHCPv6 Options Format 98 To configure CE equipment remotely, DHCPv6 should be used. Several 99 new options are defined for that purpose. Their format and usage is 100 defined in the following sections. 102 Discussion: Proposed layout assumes that several simple options are 103 used. Such approach simplifies implementation as it is much easier 104 for implementors to reuse existing code handling such options. This 105 design choice comes at a cost, however. Clients must perform checks 106 if provided set of options is complete. Alternatively, it would be 107 possible to define one complex option that contains all mandatory 108 parameters. Nevertheless, since postfix parameter is optional, it 109 would still require sub-options (or conditional formatting that is 110 strongly not recommended [I-D.ietf-dhc-option-guidelines]). 112 Discussion: It has also been proposed that since 3 mandatory 113 parameters - Domain IPv6 Prefix, Length of the CE IPv6 Prefix (note: 114 these are different prefixes), and Domain 4rd prefix - are always 115 present, they may be grouped together. 117 3.1. 4rd Options Cardinality 119 To properly configure 4rd infrastructure, following parameters are 120 required: 122 Exactly one Anycast BR IPv6 Address. 124 One or more 4rd mapping rules. Each 4rd mapping rule consists of 125 exactly one 4rd CE prefix, exactly one CE IPv6 prefix length, and 126 exactly one 4rd prefix. Each mapping rule may contain zero or one 127 Domain IPv6 Suffix. 129 3.2. 4rd Mapping Rule Option 131 The 4rd Mapping Rule Option does not convey any information on its 132 own, but rather is used to group options that represent parameteres 133 of a single mapping rule. 4rd architecture allows more than one 134 mapping rules, therefore the 4rd Mapping Rule Option MAY appear more 135 than once in a DHCPv6 message. 137 The format of the 4rd Mapping Rule Option is shown in Figure 1. 139 0 1 2 3 140 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 141 +-------------------------------+-------------------------------+ 142 | OPTION_4RD_RULE (TBD) | option-len | 143 +-------------------------------+-------------------------------+ 144 | | 145 | sub-options | 146 | | 147 +---------------------------------------------------------------+ 149 option-code: OPTION_4RD_RULE (TBD) 151 option-len: Length of all sub-options. 153 sub-options: options defining Mapping Rule parameters 155 Figure 1: 4rd Mapping Rule Option 157 The 4rd Mapping Rule Option consists of option-code and option-len 158 fields (as all DHCPv6 options do), and a variable length sub-options 159 field that contains rule parameters. 161 The 4rd Mapping Rule Option SHOULD NOT appear in any other than the 162 following DHCPv6 messages: Solicit, Advertise, Request, Renew, 163 Rebind, Information-Request and Reply. The 4rd Rule Option may 164 appear more than once in each message. 166 Each 4rd Mapping Rule Option MUST contain exactly one 4rd CE Prefix 167 Option, exactly one CE IPv6 Prefix Length Option, exactly one 4rd 168 Prefix Option and zero or one Domain IPv6 Suffix Option. Option that 169 does not meet this criteria is invalid and MUST be ignored. 171 4rd Mapping Rule Option may contain additional options. 173 Discussion: Defined format does not allow referencing rules, i.e. if 174 there are several rules, there is no rule 1, rule 2 etc. DHCPv6 175 protocol does not allow leveraging order in which options appear in 176 the message. If rule indentification is useful, a small ID field may 177 be added to the 4rd Mapping Rule Option. 179 3.3. CE IPv6 Prefix Option 181 CE IPv6 Prefix Option conveys information about domain IPv6 prefix 182 that is going to be used by requesting client (CE). 184 The format of the CE IPv6 Prefix Option is defined in Figure 2. 186 0 1 2 3 187 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 188 +-------------------------------+-------------------------------+ 189 | OPTION_4RD_PREFIX6 | option-len | 190 +-------------------------------+-------------------------------+ 191 | | 192 | domain-ipv6-prefix | 193 | | 194 | | 195 +---------------------------------------------------------------+ 197 option-code: OPTION_4RD_PREFIX6 (TBD) 199 option-len: Length of Domain IPv6 Prefix in octets (16) 201 domain-ipv6-prefix: 4rd Domain IPv6 Prefix 203 Figure 2: CE IPv6 Prefix Option 205 The CE IPv6 Prefix Option consists of option-code and option-len 206 fields (as all DHCPv6 options do), and 16 octets long Domain IPv6 207 Prefix field. 209 The CE IPv6 Prefix Option MUST NOT appear in DHCPv6 message directly. 210 It MUST NOT appear in any option other than 4rd Mapping Rule Option. 212 3.4. CE IPv6 Prefix Length Option 214 The CE IPv6 Prefix Length Option defines length of the prefix 215 assigned to specific CE. It is expected to be used together with CE 216 IPv6 Prefix Option, defined in Section Section 3.3. 218 The format of the CE Prefix Length Option is shown in Figure 3. 220 0 1 2 3 221 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 222 +-------------------------------+-------------------------------+ 223 | OPTION_4RD_PREFIX6_LEN | option-len | 224 +-------------------------------+-------------------------------+ 225 | prefix len | 226 +---------------+ 228 option-code: OPTION_4RD_PREFIX6_LEN: (TBD) 230 option-len: Length of the prefix-len field in octets (1) 232 prefix-len: Length of Domain IPv6 Prefix 234 Figure 3: CE IPv6 Prefix Length Option 236 The CE IPv6 Prefix Length Option consists of option-code and option- 237 len fields (as all DHCPv6 options do), and 1 octet long Domain IPv6 238 Prefix Length field that specifies length in bits (0-64). 240 The CE IPv6 Prefix Length Option MUST NOT appear in DHCPv6 message 241 directly. It MUST NOT appear in any option other than 4rd Mapping 242 Rule Option. 244 3.5. Domain 4rd Prefix Option 246 The Domain 4rd Prefix Option contains IPv4 address. Depending on its 247 length it is IPv4 prefix, an IPv4 address, or a shared IPv4 address 248 followed by Port-set ID. 250 The format of the Domain 4rd Prefix Option is shown in Figure 251 Figure 4. 253 0 1 2 3 254 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 255 +-------------------------------+-------------------------------+ 256 | OPTION_4RD_PREFIX4 | option-len | 257 +-------------------------------+-------------------------------+ 258 | domain-4rd-prefix | 259 +-------------------------------+-------------------------------+ 260 | 4rd-prefix-len| 261 +---------------+ 262 OPTION_4RD_PREFIX: (TBD) 264 option-len: 7 266 domain-4rd-prefix: Domain 4rd Prefix (an IPv4 address) 268 4rd-prefix-len: Length of Domain IPv6 Prefix (in bits) 270 Figure 4: Domain 4rd Prefix Option 272 The Domain 4rd Prefix Option consists of option-code and option-len 273 fields (as all DHCPv6 options do), four octets long domain-4rd-prefix 274 field that contains IPv4 address and one octect long 4rd-prefix-len. 276 Depending on 4rd-prefix-len value, actual 4rd Prefix may be range of 277 IPv4 addresses (part of domain-4rd-prefix), a single IPv4 address 278 (specified by domain-4rd-prefix) or IPv4 address+port range 279 (specified by domain-4rd-prefix and Port-set ID). Port-Set ID is 280 derived from CE Index, as explained in see Section 4.3.3 in 281 [I-D.despres-intarea-4rd]. 283 3.6. Domain IPv6 Suffix Option 285 TODO: I don't understand what this suffix is. 286 [I-D.despres-intarea-4rd] is unclear. My understanding is that 287 suffix are bits that are appended to Domain IPv6 Prefix + CE Index 288 and they together form CE IPv6 Prefix. It is only used when Domain 289 IPv6 Prefix and CE Index are short enough. On the other hand, slide 290 4 of http://tools.ietf.org/agenda/80/slides/dhc-6.pdf suggests that 291 suffix defines something that is appended after CE IPv6 Prefix. 293 Discussion: Wouldn't it be better to just use Domain IPv6 Prefix as a 294 template with CE Index inserted at appropriate offset? This would 295 make configuration simpler (one less option) and also validation of 296 received option would be much more straightforward. 298 3.7. BR Anycast Option 300 The BR Anycast Option specifies an IPv6 anycast address that should 301 be used to reach nearest Border Relay. 303 The format of the BR Anycast Option is shown in Figure 5. 305 0 1 2 3 306 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 307 +-------------------------------+-------------------------------+ 308 | OPTION_4RD_BR | option-len | 309 +-------------------------------+-------------------------------+ 310 | | 311 | br-anycast-addr | 312 | | 313 | | 314 +---------------------------------------------------------------+ 316 option-code: OPTION_4RD_BR (TBD) 318 option-len: Length of BR IPv6 Anycast Prefix (16) 320 br-anycast-addr: Border Relay IPv6 Anycast Address 322 Figure 5: BR IPv6 Address Option 324 The BR IPv6 Address Option consists of option-code and option-len 325 fields (as all DHCPv6 options do), and a 16 octets long br-anycast- 326 addr field that specifies Border Relay IPv6 Anycast address. 328 The BR Anycast Option SHOULD NOT appear in any other than the 329 following DHCPv6 messages: Solicit, Advertise, Request, Renew, 330 Rebind, Information-Request and Reply. 332 The BR Anycast Option MAY appear zero or one time in a single 333 message. 335 4. 4rd Options Example 337 TODO: Provide an example here. Possibly reuse example from Remi's 338 presentation from IETF80. 340 5. DHCPv6 Server Behavior 342 Server conformant to this specification MUST allow configuration of 343 one or more Mapping Rule Options. 345 Server MUST transmist all configured instances of the Mapping Rule 346 Options with all sub-options, if client requested it using 347 OPTION_4RD_RULE in ORO. 349 RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and 350 server negotiate configuration values using the Option Request Option 351 (OPTION_ORO). As a convenience to the reader, we mention here that a 352 server will not reply with a 4rd Mapping Rule Option if the client 353 has not explicitly enumerated it on its Option Request Option. 355 6. DHCPv6 Client Behavior 357 Although other use cases are allowed, in typical use case CE will act 358 as DHCPv6 client and will request 4rd configuration to be assigned by 359 the DHCPv6 server located in the ISP network. A client that supports 360 4rd CE functionality and conforms to this specfication MUST include 361 OPTION_4RD_RULE in its ORO. 363 Client SHOULD request 4rd options in SOLICIT, REQUEST, RENEW, REBIND 364 and INFORMATION-REQUEST messages. 366 If the client receives OPTION_4RD_RULE option, it must verify the 367 option contents, as described in Section 3.2. In case of failved 368 verification, client MUST discard invalid option and continue 369 processing any following options, including other instances of 4rd 370 options. 372 If client receives more than one OPTION_4RD_RULE, it MUST use all 373 received instances. It MUST NOT use only the first one, while 374 discarding remaining ones. 376 Note that system implementing 4rd CE functionality may have multiple 377 network interfaces, and these interfaces may be configured 378 differently; some may be connected to networks that call for 4rd, and 379 some may be connected to networks that are using normal dual stack or 380 other means. The 4rd CE system should approach this specification on 381 an interface-by-interface basis. For example, if the CE system is 382 attached to multiple networks that provide the 4rd Mapping Rule 383 Option, then the CE system MUST configure a 4rd tunnel for each 384 interface separately as each 4rd provides IPv4 connectivity for each 385 distinct interface. Means to bind a 4rd configuration to a given 386 interface in a multiple interfaces device are out of scope of this 387 document. 389 7. Security Considerations 391 Implementation of this document does not present any new security 392 issues, but as with all DHCPv6-derived configuration state, it is 393 completely possible that the configuration is being delivered by a 394 third party (Man In The Middle). As such, there is no basis to trust 395 that the access the 4rd can be trusted, and it should not therefore 396 bypass any security mechanisms such as IP firewalls. 398 Section 23 of [RFC3315] discusses DHCPv6-related security issues. 400 Section 6 of [I-D.despres-intarea-4rd] discusses 4rd related security 401 issues. 403 8. IANA Considerations 405 IANA is requested to allocate DHCPv6 option codes referencing this 406 document, delineating OPTION_4RD_RULE, OPTION_4RD_PREFIX6, 407 OPTION_4RD_PREFIX6_LEN, OPTION_4RD_PREFIX and OPTION_4RD_BR option 408 names. 410 9. Acknowledgements 412 This document would not have been possible without support from Remi 413 Despres, Satoru Matsushima, Ole Troan and Tetsuya Murakami. 415 10. References 417 10.1. Normative References 419 [I-D.despres-intarea-4rd] 420 Despres, R., Matsushima, S., Murakami, T., and O. Troan, 421 "IPv4 Residual Deployment across IPv6-Service networks 422 (4rd) ISP-NAT's made optional", 423 draft-despres-intarea-4rd-01 (work in progress), 424 March 2011. 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 430 and M. Carney, "Dynamic Host Configuration Protocol for 431 IPv6 (DHCPv6)", RFC 3315, July 2003. 433 10.2. Informative References 435 [I-D.ietf-dhc-option-guidelines] 436 Hankins, D., "Guidelines for Creating New DHCP Options", 437 draft-ietf-dhc-option-guidelines-06 (work in progress), 438 March 2010. 440 Author's Address 442 Tomasz Mrugalski 443 Internet Systems Consortium, Inc. 444 950 Charter Street 445 Redwood City, CA 94063 446 USA 448 Phone: +1 650 423 1345 449 Email: tomasz.mrugalski@gmail.com