idnits 2.17.1 draft-mdt-softwire-map-dhcp-option-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2011) is 4561 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) == Unused Reference: 'I-D.boucadair-dhcpv6-shared-address-option' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'I-D.mrugalski-dhc-dhcpv6-4rd' is defined on line 401, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-17) exists of draft-ietf-dhc-option-guidelines-07 == Outdated reference: A later version (-07) exists of draft-ietf-dhc-secure-dhcpv6-03 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire WG T. Mrugalski, Ed. 3 Internet-Draft ISC 4 Intended status: Standards Track M. Boucadair 5 Expires: April 26, 2012 France Telecom 6 O. Troan 7 Cisco 8 October 24, 2011 10 DHCPv6 Options for Mapping of Address and Port 11 draft-mdt-softwire-map-dhcp-option-00.txt 13 Abstract 15 Generic mechanism for mapping between an IPv4 prefix, address or 16 parts of thereof, and transport layer between ports and an IPv6 17 prefix or address is specified in [map-design]. This is a companion 18 document that specifies provisioning mechanism of MAP rules. It 19 defines DHCPv6 options which are meant to be used between Customer 20 Edge (CE) devices and DHCPv6 server to obtain necessary parameters to 21 configure MAP rules. Since specification of MAP architecture is 22 still expected to evolve, DHCPv6 options may have to evolve too to 23 fit the revised MAP specification. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 26, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Provisioning mechanism . . . . . . . . . . . . . . . . . . . . 3 62 4. DHCPv6 Options Format . . . . . . . . . . . . . . . . . . . . 4 63 4.1. MAP Options Cardinality . . . . . . . . . . . . . . . . . 4 64 4.2. MAP Flags Option . . . . . . . . . . . . . . . . . . . . . 5 65 4.3. MAP Rule Option . . . . . . . . . . . . . . . . . . . . . 5 66 4.4. MAP Options Example . . . . . . . . . . . . . . . . . . . 6 67 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 7 68 6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 Mapping of Address and Port (MAP) defined in [map-design] is a 82 mechanism for providing IPv4 connectivity service to end users over a 83 service provider's IPv6 network. It defines MAP Border Relay (BR) 84 router that is located that the edge of a MAP domain. MAP Customer 85 Edge (CE) is also defined as a device typically deployed at 86 customers' location. In a residential broadband deployment, this 87 type of device is sometimes referred to as a Residential Gateway (RG) 88 or Customer Premises Equipment (CPE). A MAP CE may also be referred 89 to simply as a "CE" within the context of MAP. 91 A typical MAP CE adopting MAP rules will serve a residential site 92 with one WAN side interface, one or more LAN side interfaces. To 93 operate properly, it requires one or more MAP rules and additional 94 informations. In larger networks it is infeasible to configure such 95 parameters manually. Therefore provisioning mechanism is required. 96 Such mechanism is defined in this document. It leverages existing 97 DHCPv6 [RFC3315] protocol to deliver necessary parameters to CE. 99 This document defines several DHCPv6 options that allow delivery of 100 required information to configure CE. Configuration of the BR is 101 outside of scope of this document. Definitions of used parameters 102 are provided in [map-design]. 104 Since specification of MAP architecture is still expected to evolve, 105 DHCPv6 options may have to evolve too to fit the revised MAP 106 specification. 108 2. Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 3. Provisioning mechanism 116 A typical MAP CE usually acts as a DHCPv6 client and requests options 117 that are being provided by a DHCPv6 server located somewhere in ISP 118 network. It would adopt three kinds of parameters independently: 120 o MAP mapping rules are defined in [map-design], including Rule IPv6 121 prefix/length, Rule IPv4 prefix and BR IPv6 prefix. One MAP CE 122 can receive one or more MAP mapping rules from the DHCPv6 server, 123 the first of which should be the default MAP mapping rule for the 124 initiated CE of its own, followed by other mapping rules within 125 the MAP domain if necessary. 126 o Transport mode indicates encapsulation or translation mode for MAP 127 approach. It should be conducted on interface-by-interface basis 128 o Discussion: Qiong also proposed to add deployment mode here. 129 Jacni Qin recommends against it. Deployment mode is to notify 130 whether CE is in Hub and spoke mode or mesh. In Hub and spoke 131 mode, only the first default MAP mapping rule is needed in the 132 following MAP procedure. While in mesh mode, all MAP mapping 133 rules are included to achieve CE-CE traffic optimization. 135 4. DHCPv6 Options Format 137 DHCPv6 protocol is used for CE provisioning. Several new options are 138 defined for conveying MAP-specific parameters. Their format and 139 usage is defined in the following sections. 141 Discussion: As the exact parameters required to configure MAP rules 142 and MAP in general are expected to change, this section is expected 143 to be updated or even rewritten completely. 145 Discussion: Proposed layout assumes that several simple options are 146 used. Such approach simplifies implementation as it is much easier 147 for implementors to reuse existing code handling such options. This 148 design choice comes at a cost, however. Clients must perform checks 149 if provided set of options is complete. Alternatively, it would be 150 possible to define one complex option that contains all mandatory 151 parameters. 153 Discussion: It should be noted that initial concept of 4rd 154 provisioning was presented in DHC working group meeting. It used one 155 complex option to convey all required parameters. Strong suggestion 156 from DHC WG was to use several simpler options. Options (possibly 157 nested) are preferred over conditional option formatting. See DHCP 158 option guidelines document [I-D.ietf-dhc-option-guidelines]). 160 4.1. MAP Options Cardinality 162 MAP rule is defined in [map-design], Section 4. 164 Discussion: If you want additional parameter added to the 165 OPTION_MAP_RULE option, please update [map-design] first. 167 In each REPLY message, server that supports MAP configuration MUST 168 include exactly one OPTION_MAP_FLAGS option. 170 MAP_FLAGS option MUST include one or more OPTION_MAP_RULE options. 172 For proper operation, additional parameters obtained via other 173 options are necessary. In particular, L parameter is equal to a 174 length of a prefix delegated to CE, conveyed in OPTION_IA_PD and 175 IAPREFIX, as defined in [RFC3633]. 177 4.2. MAP Flags Option 179 . This option specifies MAP flags. Currently the only defined flag 180 is T - transport mode. 0 designates translation and 1 designates 181 encapsulation. 183 Each MAP_FLAGS option MUST contain one or more MAP Rule Options. 185 TODO: Add format here later 187 Figure 1: MAP Flags Option 189 option-code: OPTION_MAP_FLAGS (TBD) 191 4.3. MAP Rule Option 193 This option represents a single MAP Rule. Depending on deployment 194 mode, each CE may require one or more MAP Rules to operate properly. 196 Server includes one or more MAP Rule Options in MAP Flags option. 198 Discussion: Do we need to distinguish or reference rules? (i.e. Is 199 some kind of ID field required?) 201 Server MAY send more than one MAP Rule Option, if it is configured to 202 do so. Clients MUST NOT send MAP Rule Option. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | OPTION_MAP_RULE | option-length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 | rule IPv6 prefix | 211 | | 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | rule IPv4 prefix | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | | 217 | BR prefix (IPv6 prefix) | 218 | | 219 | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | rule-pref6-len| 222 +-+-+-+-+-+-+-+-+ 224 Figure 2: MAP Rule Option 226 o option-code: OPTION_MAP_RULE (TBD) 227 o option-length: 37 in octets 228 o rule-pref6-len: length for the rule IPv6 prefix in bits 229 o rule IPv6 prefix: an IPv6 prefix that appears in a MAP rule. 230 o rule IPv4 prefix: an IPv4 prefix that appears in a MAP rule. 231 o BR prefix: the IPv6 prefix of BR that appears in a MAP rule 233 4.4. MAP Options Example 235 DHCPv6 server provisioning a single MAP Rule to a CE (DHCPv6 client) 236 will convey the following MAP options in its messages: 238 239 240 241 ... 242 243 245 Figure 3: MAP Options Example 247 5. DHCPv6 Server Behavior 249 RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and 250 server negotiate configuration values using the ORO. As a 251 convenience to the reader, we mention here that a server will not 252 reply with a MAP Rule Option if the client has not explicitly 253 enumerated it on its Option Request Option. 255 Server conformant to this specification MUST allow configuration of 256 one or more MAP Rule Options. 258 Server MUST transmist all configured instances of the Mapping Rule 259 Options with all sub-options, if client requested it using 260 OPTION_MAP_RULE in its Option Request Option (ORO). Server MUST 261 transmit MAP Flags Option if client requested OPTION_MAP_FLAGS in its 262 ORO. 264 Rules assignment is a stateless process from the server's 265 perspective. Server does not need to maintain a state of rules 266 provisioned to clients, track lifetimes, expire outdated rules etc. 267 Server SHOULDs assign the same set of rules to all CEs in one MAP 268 Domain, unless there are several classes of CEs defined, e.g. regular 269 and premium users. In such case, each class of CEs is expected to 270 get the same set of rules. Server is not expected to track MAP rules 271 on a per CE basis. Exact assignment of specific rules to a specific 272 CEs is outside of scope of this document. 274 6. DHCPv6 Client Behavior 276 Although other use cases are allowed, in typical use case CE will act 277 as DHCPv6 client and will request MAP configuration to be assigned by 278 the DHCPv6 server located in the ISP network. A client that supports 279 MAP CE functionality and conforms to this specfication MUST include 280 OPTION_MAP_RULE and OPTION_MAP_FLAGS in its ORO. 282 For proper operation, MAP CE client MUST also request IPv6 address 283 (OPTION_IA_NA, defined in [RFC3315]) and prefix delegation 284 (OPTION_IA_PD, defined in [RFC3633]). MAP CE client SHOULD NOT 285 initiate DHCPv4 configuration as all parameters are delivered over 286 DHCPv6. 288 Client SHOULD request OPTION_MAP_RULE and OPTION_MAP_FLAGS options in 289 SOLICIT, REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages. 291 If client receives more than one OPTION_MAP_RULE option, it MUST use 292 all received instances. It MUST NOT use only the first one, while 293 discarding remaining ones. 295 Note that system implementing MAP CE functionality may have multiple 296 network interfaces, and these interfaces may be configured 297 differently; some may be connected to networks that call for MAP, and 298 some may be connected to networks that are using normal dual stack or 299 other means. The MAP CE system should approach this specification on 300 an interface-by-interface basis. For example, if the CE system is 301 attached to multiple networks that provide the MAP Mapping Rule 302 Option, then the CE system MUST configure a MAP connection (i.e. a 303 translation or encapsulation) for each interface separately as each 304 MAP provides IPv4 connectivity for each distinct interface. Means to 305 bind a MAP configuration to a given interface in a multiple 306 interfaces device are out of scope of this document. 308 7. IANA Considerations 310 This specification does not require any IANA actions. 312 8. Security Considerations 314 Implementation of this document does not present any new security 315 issues, but as with all DHCPv6-derived configuration state, it is 316 completely possible that the configuration is being delivered by a 317 third party (Man In The Middle). As such, there is no basis to trust 318 that the access over the MAP can be trusted, and it should not 319 therefore bypass any security mechanisms such as IP firewalls. 321 Readers concerned with security of MAP provisioning over DHCPv6 are 322 encouraged to familiarize with [I-D.ietf-dhc-secure-dhcpv6]. 324 Section XX of [map-design] discusses security issues of the MAP 325 mechanism. 327 Section 23 of [RFC3315] discusses DHCPv6-related security issues. 329 Section 6 of [I-D.murakami-softwire-4rd] discusses 4rd related 330 security issues that are partially applicable to MAP mechanism. 332 9. IANA Considerations 334 IANA is requested to allocate DHCPv6 option codes referencing this 335 document, delineating OPTION_MAP_RULE, OPTION_MAP_BR_PREFIX6, 336 OPTION_MAP_PREFIX6, OPTION_MAP_PREFIX4 and OPTION_MAP_FLAGS option 337 names. 339 10. Contributors 341 The members of the MAP design team are: 342 1. Mohamed Boucadair 343 2. Gang Chen 344 3. Wojciech Dec 345 4. Xiaohong Deng 346 5. Jouni Korhonen 347 6. Xing Li 348 7. Maoke 349 8. Satoru Matsushima 350 9. Tomasz Mrugalski 351 10. Jacni Qin 352 11. Tina Tsou 353 12. Ole Troan 354 13. Dan Wing 355 14. Leaf Yeh 356 15. Jan Zorz 358 11. Acknowledgements 360 Authors would like to thank Xiaohong Deng, Congxiao Bao, Jacni Qin, 361 Qiong Sun for their comments and suggestions. 363 12. References 365 12.1. Normative References 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, March 1997. 370 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 371 and M. Carney, "Dynamic Host Configuration Protocol for 372 IPv6 (DHCPv6)", RFC 3315, July 2003. 374 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 375 Host Configuration Protocol (DHCP) version 6", RFC 3633, 376 December 2003. 378 [map-design] 379 Troan, O., Ed., "Mapping of Address and Port (MAP)", 380 draft-ietf-softwire-mapping-address-and-port 00, 10 2011. 382 12.2. Informative References 384 [I-D.boucadair-dhcpv6-shared-address-option] 385 Boucadair, M., Levis, P., Grimault, J., Savolainen, T., 386 and G. Bajko, "Dynamic Host Configuration Protocol 387 (DHCPv6) Options for Shared IP Addresses Solutions", 388 draft-boucadair-dhcpv6-shared-address-option-01 (work in 389 progress), December 2009. 391 [I-D.ietf-dhc-option-guidelines] 392 Hankins, D., "Guidelines for Creating New DHCP Options", 393 draft-ietf-dhc-option-guidelines-07 (work in progress), 394 October 2011. 396 [I-D.ietf-dhc-secure-dhcpv6] 397 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 398 draft-ietf-dhc-secure-dhcpv6-03 (work in progress), 399 June 2011. 401 [I-D.mrugalski-dhc-dhcpv6-4rd] 402 Mrugalski, T., "DHCPv6 Options for IPv4 Residual 403 Deployment (4rd)", draft-mrugalski-dhc-dhcpv6-4rd-00 (work 404 in progress), July 2011. 406 [I-D.murakami-softwire-4rd] 407 Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual 408 Deployment on IPv6 infrastructure - protocol 409 specification", draft-murakami-softwire-4rd-01 (work in 410 progress), September 2011. 412 Authors' Addresses 414 Tomasz Mrugalski (editor) 415 Internet Systems Consortium, Inc. 416 950 Charter Street 417 Redwood City, CA 94063 418 USA 420 Phone: +1 650 423 1345 421 Email: tomasz.mrugalski@gmail.com 422 Mohamed Boucadair 423 France Telecom 424 Rennes 35000 425 France 427 Email: mohamed.boucadair@gmail.com 429 Ole Troan 430 Cisco Systems, Inc. 431 Telemarksvingen 20 432 Oslo N-0655 433 Norway 435 Email: ot@cisco.com