idnits 2.17.1 draft-ietf-softwire-map-dhcp-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.ietf-softwire-map]), 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 (August 1, 2012) is 4285 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 527, but no explicit reference was found in the text == Unused Reference: 'I-D.mrugalski-dhc-dhcpv6-4rd' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'I-D.murakami-softwire-4rd' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC6335' is defined on line 571, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-01 ** 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-08 == Outdated reference: A later version (-07) exists of draft-ietf-dhc-secure-dhcpv6-06 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-04 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire WG T. Mrugalski 3 Internet-Draft ISC 4 Intended status: Standards Track O. Troan 5 Expires: February 2, 2013 Cisco 6 C. Bao 7 Tsinghua University 8 W. Dec 9 Cisco 10 L. Yeh 11 Huawei 12 August 1, 2012 14 DHCPv6 Options for Mapping of Address and Port 15 draft-ietf-softwire-map-dhcp-00 17 Abstract 19 This document specifies DHCPv6 options for the provisioning of 20 Mapping of Address and Port (MAP) Customer Edge (CE) devices, based 21 on the MAP paramaters defined in [I-D.ietf-softwire-map]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 2, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. MAP Information . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. DHCPv6 MAP Options Format . . . . . . . . . . . . . . . . . . 4 61 4.1. MAP Option . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. MAP Rule Option . . . . . . . . . . . . . . . . . . . . . 6 63 4.3. MAP DMR Option . . . . . . . . . . . . . . . . . . . . . . 8 64 5. MAP Options Examples . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. BMR Option Example . . . . . . . . . . . . . . . . . . . . 8 66 5.2. FMR Option Example . . . . . . . . . . . . . . . . . . . . 9 67 5.3. DMR Option Example . . . . . . . . . . . . . . . . . . . . 9 68 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 9 69 7. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 9 70 8. Usage of flags and paramaters . . . . . . . . . . . . . . . . 10 71 9. Deployment considerations . . . . . . . . . . . . . . . . . . 11 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 77 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 Mapping of Address and Port (MAP) defined in [I-D.ietf-softwire-map] 83 is a mechanism for providing IPv4 connectivity service to end users 84 over a service provider's IPv6 network, allowing for shared or 85 dedicated IPv4 addressing. It consists of a set of one or more MAP 86 Border Relay (BR) routers, responsible for stateless forwarding, and 87 one or more MAP Customer Edge (CE) routers, that collectively form a 88 MAP Domain when configured with common MAP rule-sets. In a 89 residential broadband deployment the CE is sometimes referred to as a 90 Residential Gateway (RG) or Customer Premises Equipment (CPE). 92 A typical MAP CE will serve its end-user with one WAN side interface 93 connected to an operator domain providing a MAP service. To function 94 in the MAP domain, the CE requires to be provisioned with the 95 appropiate MAP service paramaters for that domain. Particularly in 96 larger networks it is not feasible to configure such parameters 97 manually, which forms the requirement for a dynamic MAP provisioning 98 mechanism that is defined in this document based on the existing 99 DHCPv6 [RFC3315] protocol. The configuration of the MAP BR is 100 outside of scope of this document. 102 This document specifies the DHCPv6 options that allow MAP CE 103 provisioning, based on the definitions of parameters provided in 104 [I-D.ietf-softwire-map], and is applicable to both MAP-E and MAP-T 105 transport variants. The definition of DHCPv6 options for MAP CE 106 provisioning does not preclude the definition of other dynamic 107 methods for configuring MAP devices, or supplementing such 108 configuration, nor is the use of DHCPv6 provisioning mandatory for 109 MAP operation. 111 Since specification of MAP architecture is still expected to evolve, 112 DHCPv6 options may have to evolve too to fit the revised MAP 113 specification. 115 Described proposal is not a dynamic port allocation mechanism. 117 Readers interested in deployment considerations are encouraged to 118 read [I-D.mdt-softwire-map-deployment]. 120 2. Conventions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 3. MAP Information 128 The following presents the information parameters that are used to 129 configure a MAP CE: 131 o A Default Mapping Rule (DMR). This rule governs the default 132 forwarding/mapping behaviour of the MAP CE, ie it informs the CE 133 of the BR router's address or prefix that is typically used as a 134 default. The DMR is a mandatory parameter for a MAP CE. 135 o A Basic Mapping Rule (BMR). This rule governs the MAP 136 configuration of the CE, including that of completing the CE's MAP 137 IPv6 address, as well as deriving the CEs IPv4 parameters. Key 138 parameters of a BMR include: i) The IPv4 Prefix - Used to derive 139 the CE's IPv4 address; ii) The Embedded Address bit length - Used 140 to derive how many, if any, of the CE's IPv6 address is mapped to 141 the IPv4 address. iii) The IPv6 prefix - used to determine the 142 CE's IPv6 MAP domain prefix that is to form the base for the CE's 143 MAP address. The BMR is an optional rule for a MAP CE. 144 o A Forward Mapping Rule (FMR). This rule governs the MAP CE-CE 145 forwarding behaviour for IPv4 destinations covered by the rule. 146 The FMR is effectively a special type of an BMR, given that it 147 shares exactly the same configuration parameters, except that 148 these parameters are only applied for setting up forwarding. Its 149 presence enables a given CE to communicate directly in "mesh mode" 150 with other CEs. The FMR is an optional rule, and the absence of 151 such a rule indicates that the CE is to simply use its default 152 mapping rule for all destinations. 153 o Transport mode; encapsulation (MAP-E) or translation (MAP-T) modes 154 to be used for the MAP CE Domain. 155 o Additional parameters. The MAP specification allows great 156 flexibility in the level of automation a CE uses to derive its 157 IPv4 address and port-sharing (PSID), ranging from full derivation 158 of these parameters from the CE's IPv6 prefix, to full 159 parametrization of MAP configuration independent of the CE's IPv6 160 prefix. 162 4. DHCPv6 MAP Options Format 164 The DHCPv6 protocol is used for MAP CE provisioning following regular 165 DHCPv6 notions, with the MAP CE assuming a DHCPv6 client role, and 166 the MAP parameters provided by the DHCPv6 server following server 167 side policies. The format and usage of the MAP options is defined in 168 the following sections. 170 Discussion: As the exact parameters required to configure MAP rules 171 and MAP in general are expected to change, this section is expected 172 to be updated and follow change in the [I-D.ietf-softwire-map]. 174 Discussion: It should be noted that initial concept of 4rd/MAP 175 provisioning was presented in DHC working group meeting. It used one 176 complex option to convey all required parameters. Strong suggestion 177 from DHC WG was to use several simpler options. Options (possibly 178 nested) are preferred over conditional option formatting. See DHCP 179 option guidelines document [I-D.ietf-dhc-option-guidelines]). 181 Server that supports MAP configuration and is configured to provision 182 requesting CE MUST include exactly one OPTION_MAP option in a REPLY 183 message for each MAP domain. It is envisaged that in typical 184 network, there will be only one MAP domain deployed. 186 4.1. MAP Option 188 This MAP Option specifies the container option used to group all 189 rules for a specified MAP domain. 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | OPTION_MAP | option-length | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | flags | . 197 +-+-+-+-+-+-+-+-+ sub-options (variable length) . 198 . . 199 +---------------------------------------------------------------+ 201 Figure 1: MAP Option 203 o option-code: OPTION_MAP (TBD1) 204 o option-length: 1 + Length of the sub-options 205 o flags: This 8-bits long conveys the MAP Option Flags. The meaning 206 of specific bits is explained in Figure 2. 207 o sub-options: options associatied to this MAP option. 209 The sub options field encapsulates those options that are specific to 210 this MAP Option. For example, all of the MAP Rule Options are in the 211 sub-options field. A DHCP message may contain multiple MAP Options. 213 The Format of the MAP Option Flags field is: 215 0 1 2 3 4 5 6 7 216 +-+-+-+-+-+-+-+-+ 217 |Reserved |T| 218 +-+-+-+-+-+-+-+-+ 220 Figure 2: MAP Option Flags 222 o Reserved: 7-bits reserved for future use. 223 o T: 1 bit field that specifies transport mode to use: translation 224 (0) or encapsulation (1). 226 It was suggested to also provision information whether MAP network is 227 working in hub and spoke or mesh mode. That is not necessary, as 228 mesh mode is assumed when there is at least one FMR present. 230 4.2. MAP Rule Option 232 Figure X shows the format of the MAP Rule option used for conveying 233 the BMR and FMR. 235 Server includes one or more MAP Rule Options in MAP Flags option. 237 Server MAY send more than one MAP Rule Option, if it is configured to 238 do so. Clients MUST NOT send MAP Rule Option. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | OPTION_MAP_RULE | option-length | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | prefix6-len | ea-len | prefix4-len | rule-flags | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | rule-ipv4-prefix | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | rule-ipv6-prefix | 250 | (variable length) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 . sub-options (variable length) . 254 . . 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 3: MAP Rule Option 259 o option-code: OPTION_MAP_RULE (TBD2) 260 o option-length: length of the option, excluding option-code and 261 option-length fields, including length of all sub-options. 262 o prefix6-len: 8 bits long field expressing the bit mask length of 263 the IPv6 prefix specified in the rule-ipv6-prefix field. 264 o ea-len: 8-bits long field that specifies the Embedded-Address (EA) 265 bit length. Values allowed range from 0 to 48. 266 o prefix4-len: 8 bits long field expressing the bit mask length of 267 the IPv4 prefix specified in the rule-ipv4-prefix field. 268 o rule-flags: 8 bit long field carrying flags applicable to the 269 rule. The meaning of specific bits is explained in Figure 4. 270 o rule-ipv4-prefix: a 32 bit fixed length field that specifies the 271 IPv4 prefix for the MAP rule. 272 o rule-ipv6-prefix: a variable length field that specifies the IPv6 273 domain prefix for the MAP rule. The field is padded with zeros up 274 to the nearest octet boundary when prefix6-len is not divisible by 275 8. 276 o rule sub-options: a variable field that may contain zero or more 277 options that specify additional parameters for this MAP BMR/FMR 278 rule. Currently there are no such options defined, but they may 279 be defined in the future. 281 The value of the EA-len and prefix4-len SHOULD be equal to or greater 282 than 32. 284 The Format of the MAP Rule Flags field is: 286 0 1 2 3 4 5 6 7 287 +-+-+-+-+-+-+-+-+ 288 |Reserved |F| 289 +-+-+-+-+-+-+-+-+ 291 Figure 4: MAP Rule Flags 293 o Reserved: 7-bits reserved for future use as flags. 294 o F-Flag: 1 bit field that specifies whether the rule is to be used 295 for forwarding (FMR). 0x0 = This rule is NOT used as an FMR. 0x1 = 296 This rule is also an FMR. 297 o Note: BMR rules can be also FMR rules by setting the F flag. BMR 298 rules are determined by a match of the Rule-IPv6-prefix against 299 the CPE's prefix(es). 301 It is expected that in a typical MAP deployment scenarios, there will 302 be a single DMR and a single BMR, which could also be designated as 303 an FMR using the F-Flag. 305 4.3. MAP DMR Option 307 Figure X shows the format of the MAP Rule option used for conveying 308 the DMR. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | OPTION_MAP_DMR | option-length | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |dmr-prefix6-len| dmr-ipv6-prefix | 316 +-+-+-+-+-+-+-+-+ (variable length) | 317 . . 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | | 320 . sub-options (variable length) . 321 . . 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 5: MAP DMR Option 326 o option-code: OPTION_MAP_DMR (TBD3) 327 o option-length: 1 + length of dmr-ipv6-prefix + sub-options in 328 bytes 329 o dmr-prefix6-len: T8 bits long field expressing the bit mask length 330 of the IPv6 prefix specified in the dmr-ipv6-prefix field. 331 o dmr-ipv6-prefix: a variable length field that specifies the IPv6 332 prefix or address for the MAP BR. This field is padded with zeros 333 up to the nearest octet boundary when prefix4-len is not divisible 334 by 8. 335 o sub options: options associatied to this MAP DMR option. 337 5. MAP Options Examples 339 DHCPv6 server provisioning a single MAP Rule to a CE (DHCPv6 client) 340 will convey the following MAP options in its messages: 342 5.1. BMR Option Example 344 TODO: Reflect example in section 5.2 of MAP draft 346 Figure 6: BMR Option Example 348 5.2. FMR Option Example 350 TODO: Reflect example in section 5.3 of MAP draft 352 Figure 7: FMR Option Example 354 5.3. DMR Option Example 356 TODO: Reflect example in section 5.4 of MAP draft 358 Figure 8: DMR Option Examples 360 6. DHCPv6 Server Behavior 362 RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and 363 server negotiate configuration values using the ORO. As a 364 convenience to the reader, we mention here that a server will by 365 default not reply with a MAP Rule Option if the client has not 366 explicitly enumerated it on its Option Request Option. 368 A Server following this specification MUST allow the configuration of 369 one or more MAP Rule Options, and SHOULD send such options grouped 370 under a single MAP_OPTION. 372 Server MUST transmit all configured instances of the Mapping Rule 373 Options with all sub-options, if client requested it using 374 OPTION_MAP_RULE in its Option Request Option (ORO). Server MUST 375 transmit MAP Flags Option if client requested OPTION_MAP in its ORO. 377 The server MUST be capable of following per client assignment rules 378 when assigning MAP options. 380 7. DHCPv6 Client Behavior 382 A MAP CE acting as DHCPv6 client will request MAP configuration to be 383 assigned by the DHCPv6 server located in the ISP network. A client 384 supporting MAP functionality SHOULD request OPTION_MAP, 385 OPTION_MAP_RULE and OPTION_MAP_DMR options in its ORO in SOLICIT, 386 REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages. 388 When processing received MAP options the following behaviour is 389 expected: 391 o A client MUST support processing multiple received OPTION_MAP_RULE 392 options in a OPTION_MAP option 393 o A client receiving an unsupported MAP option, or an unrecognized 394 parameter value SHOULD discard the entire OPTION_MAP. 395 o Only one OPTION_MAP_DMR is allowed per OPTION_MAP option. 397 The client MUST be capable of applying the received MAP option 398 parameters for the configuration of the local MAP instance. 400 Note that system implementing MAP CE functionality may have multiple 401 network interfaces, and these interfaces may be configured 402 differently; some may be connected to networks that call for MAP, and 403 some may be connected to networks that are using normal dual stack or 404 other means. The MAP CE system should approach this specification on 405 an interface-by-interface basis. For example, if the CE system is 406 attached to multiple networks that provide the MAP Mapping Rule 407 Option, then the CE system MUST configure a MAP connection (i.e. a 408 translation or encapsulation) for each interface separately as each 409 MAP provides IPv4 connectivity for each distinct interface. Means to 410 bind a MAP configuration to a given interface in a multiple 411 interfaces device are out of scope of this document. 413 8. Usage of flags and paramaters 415 The defined MAP options contain a number of flags and parameters that 416 are intended to provide full flexibility in the configuration of a 417 MAP CE. Some usage examples are: 419 o A MAP CE receiving an OPTION_MAP option with the T flag set to 1 420 will assume a MAP-E (encapsulation) mode of operation for the 421 domain and all associated rules. Conversely, when the received 422 option has the T flag set to 0, the CE will assume a MAP-T 423 (stateless NAT46 translation) mode of operation. 424 o The presence of a OPTION_MAP_RULE option, along with IPv4 prefix 425 parameters, indicates to the MAP CE that NAPT44 mode of operation 426 is expected, following the address mapping rules defined in 427 [I-D.ietf-softwire-map]. Conversely, the absence of an 428 OPTION_MAP_RULE option indicates that NAT44 mode is not required, 429 and that the MAP CE is to plainly encapsulate (MAP-E mode) or 430 statelessly translate using NAT64 (MAP-T mode) any IPv4 traffic 431 sent following the DMR. 432 o The MAP domain ipv6-prefix in the BMR should correspond to a 433 service prefix assigned to the CPE by the operator, with the 434 latter being assigned using regular IPv6 means, e.g. DHCP PD 435 [RFC3633] or SLAAC. This parameter allows the CPE to select the 436 prefix for MAP operation. 438 o The EA_LEN parameter, along with the length of the IPv4 prefix in 439 the BMR option, allows the MAP CE to determine whether address 440 sharing is in effect, and what is the address sharing ratio. Eg: 441 A prefix4-len of 16 bits, and EA-len of 18 combines to a 32 bit 442 IPv4 address with a sharing ratio of 4. 443 o The use of the F(orward) flag in the BMR allows a CE to apply a 444 received BMR as an FMR, thereby enabling mesh-mode for the domain 445 covered by the BMR rule. 446 o In the absence of a BMR, the presence of the mandatory DMR 447 indicates to the CPE the address or prefix of a BR, and makes the 448 MAP CE fully compatible with DS-Lite and stateful or stateless 449 NAT64 core nodes. Eg a MAP CE configured in MAP-E mode, with just 450 a DMR and a BR IPv6 address equivalent to that of the AFTR, 451 effectively acts as a DS-Lite B4 element. For more discussion 452 about MAP deployment considerations, see 453 [I-D.mdt-softwire-map-deployment]. 455 9. Deployment considerations 457 In a typical environment, there will be only one MAP domain, so 458 server will provide only a single instance of MAP option that acts a 459 container for MAP Rule Options and other options that are specific to 460 that MAP domain. 462 In case of multiple provisioning domains, as defined in 463 [I-D.ietf-homenet-arch], one server may be required to provide 464 information about more than one MAP domain. In such case, server 465 will provide two or more instances of MAP Options, each with its own 466 set of sub-option that define MAP rules for each specific MAP domain. 467 Details of mulitple provisioning domains are discussed in Section 4.1 468 of [I-D.mdt-softwire-map-deployment]. 470 10. IANA Considerations 472 IANA is kindly requested to allocate DHCPv6 option codes for TBD1 for 473 OPTION_MAP, TBD2 for OPTION_MAP_RULE, and TBD3 for OPTION_MAP_DMR. 474 All values should be added to the DHCPv6 option code space defined in 475 Section 24.3 of [RFC3315]. 477 11. Security Considerations 479 Implementation of this document does not present any new security 480 issues, but as with all DHCPv6-derived configuration state, it is 481 completely possible that the configuration is being delivered by a 482 third party (Man In The Middle). As such, there is no basis to trust 483 that the access over the MAP can be trusted, and it should not 484 therefore bypass any security mechanisms such as IP firewalls. 486 Readers concerned with security of MAP provisioning over DHCPv6 are 487 encouraged to familiarize with [I-D.ietf-dhc-secure-dhcpv6]. 489 Section XX of [I-D.ietf-softwire-map] discusses security issues of 490 the MAP mechanism. 492 Section 23 of [RFC3315] discusses DHCPv6-related security issues. 494 12. Acknowledgements 496 This document was created as a product of a MAP design team. 497 Following people were members of that team: Congxiao Bao, Mohamed 498 Boucadair, Gang Chen, Maoke Chen, Wojciech Dec, Xiaohong Deng, Jouni 499 Korhonen, Xing Li, Satoru Matsushima, Tomasz Mrugalski, Tetsuya 500 Murakami, Jacni Qin, Necj Scoberne, Qiong Sun, Tina Tsou, Dan Wing, 501 Leaf Yeh and Jan Zorz. 503 Former MAP design team members are: Remi Despres. 505 13. References 507 13.1. Normative References 509 [I-D.ietf-softwire-map] 510 Troan, O., Dec, W., Li, X., Bao, C., Zhai, Y., Matsushima, 511 S., and T. Murakami, "Mapping of Address and Port (MAP)", 512 draft-ietf-softwire-map-01 (work in progress), June 2012. 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 518 and M. Carney, "Dynamic Host Configuration Protocol for 519 IPv6 (DHCPv6)", RFC 3315, July 2003. 521 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 522 Host Configuration Protocol (DHCP) version 6", RFC 3633, 523 December 2003. 525 13.2. Informative References 527 [I-D.boucadair-dhcpv6-shared-address-option] 528 Boucadair, M., Levis, P., Grimault, J., Savolainen, T., 529 and G. Bajko, "Dynamic Host Configuration Protocol 530 (DHCPv6) Options for Shared IP Addresses Solutions", 531 draft-boucadair-dhcpv6-shared-address-option-01 (work in 532 progress), December 2009. 534 [I-D.ietf-dhc-option-guidelines] 535 Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 536 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 537 draft-ietf-dhc-option-guidelines-08 (work in progress), 538 June 2012. 540 [I-D.ietf-dhc-secure-dhcpv6] 541 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 542 draft-ietf-dhc-secure-dhcpv6-06 (work in progress), 543 March 2012. 545 [I-D.ietf-homenet-arch] 546 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 547 "Home Networking Architecture for IPv6", 548 draft-ietf-homenet-arch-04 (work in progress), July 2012. 550 [I-D.mdt-softwire-map-deployment] 551 Sun, Q., Chen, M., Chen, G., Sun, C., Tsou, T., and S. 552 Perreault, "Mapping of Address and Port (MAP) - Deployment 553 Considerations", draft-mdt-softwire-map-deployment-02 554 (work in progress), June 2012. 556 [I-D.mrugalski-dhc-dhcpv6-4rd] 557 Mrugalski, T., "DHCPv6 Options for IPv4 Residual 558 Deployment (4rd)", draft-mrugalski-dhc-dhcpv6-4rd-00 (work 559 in progress), July 2011. 561 [I-D.murakami-softwire-4rd] 562 Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual 563 Deployment on IPv6 infrastructure - protocol 564 specification", draft-murakami-softwire-4rd-01 (work in 565 progress), September 2011. 567 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 568 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 569 May 2008. 571 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 572 Cheshire, "Internet Assigned Numbers Authority (IANA) 573 Procedures for the Management of the Service Name and 574 Transport Protocol Port Number Registry", BCP 165, 575 RFC 6335, August 2011. 577 Authors' Addresses 579 Tomasz Mrugalski 580 Internet Systems Consortium, Inc. 581 950 Charter Street 582 Redwood City, CA 94063 583 USA 585 Phone: +1 650 423 1345 586 Email: tomasz.mrugalski@gmail.com 587 URI: http://www.isc.org/ 589 Ole Troan 590 Cisco Systems, Inc. 591 Telemarksvingen 20 592 Oslo N-0655 593 Norway 595 Email: ot@cisco.com 596 URI: http://cisco.com 598 Congxiao Bao 599 CERNET Center/Tsinghua University 600 Room 225, Main Building, Tsinghua University 601 Beijing 100084 602 CN 604 Phone: +86 10-62785983 605 Email: congxiao@cernet.edu.cn 607 Wojciech Dec 608 Cisco Systems, Inc. 609 The Netherlands 611 Phone: 612 Fax: 613 Email: wdec@cisco.com 614 URI: 616 Leaf Y. Yeh 617 Huawei Technologies 618 Shenzhen, 619 P. R. China 621 Phone: 622 Fax: 623 Email: leaf.y.yeh@huawei.com 624 URI: