idnits 2.17.1 draft-mdt-softwire-map-dhcp-option-03.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 (July 4, 2012) is 4307 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: 'RFC3633' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'I-D.boucadair-dhcpv6-shared-address-option' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tsvwg-iana-ports' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'I-D.mrugalski-dhc-dhcpv6-4rd' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'I-D.murakami-softwire-4rd' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 623, 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-03 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 11 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: January 5, 2013 Cisco 6 C. Bao 7 Tsinghua University 8 W. Dec 9 Cisco 10 July 4, 2012 12 DHCPv6 Options for Mapping of Address and Port 13 draft-mdt-softwire-map-dhcp-option-03 15 Abstract 17 This document specifies DHCPv6 options for the provisioning of 18 Mapping of Address and Port (MAP) Customer Edge (CE) devices, based 19 on the MAP paramaters defined in [I-D.ietf-softwire-map]. 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 January 5, 2013. 38 Copyright Notice 40 Copyright (c) 2012 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. MAP Information . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. DHCPv6 MAP Options Format . . . . . . . . . . . . . . . . . . 4 59 4.1. MAP Option . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. MAP Rule Option . . . . . . . . . . . . . . . . . . . . . 6 61 4.3. MAP DMR Option . . . . . . . . . . . . . . . . . . . . . . 8 62 4.4. MAP Port Parameters Option . . . . . . . . . . . . . . . . 8 63 5. MAP Options Examples . . . . . . . . . . . . . . . . . . . . . 9 64 5.1. BMR Option Example . . . . . . . . . . . . . . . . . . . . 9 65 5.2. FMR Option Example . . . . . . . . . . . . . . . . . . . . 10 66 5.3. DMR Option Example . . . . . . . . . . . . . . . . . . . . 10 67 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 10 68 7. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 10 69 8. Usage of flags and paramaters . . . . . . . . . . . . . . . . 11 70 9. Deployment considerations . . . . . . . . . . . . . . . . . . 12 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 Mapping of Address and Port (MAP) defined in [I-D.ietf-softwire-map] 82 is a mechanism for providing IPv4 connectivity service to end users 83 over a service provider's IPv6 network, allowing for shared or 84 dedicated IPv4 addressing. It consists of a set of one or more MAP 85 Border Relay (BR) routers, responsible for stateless forwarding, and 86 one or more MAP Customer Edge (CE) routers, that collectively form a 87 MAP Domain when configured with common MAP rule-sets. In a 88 residential broadband deployment the CE is sometimes referred to as a 89 Residential Gateway (RG) or Customer Premises Equipment (CPE). 91 A typical MAP CE will serve its end-user with one WAN side interface 92 connected to an operator domain providing a MAP service. To function 93 in the MAP domain, the CE requires to be provisioned with the 94 appropiate MAP service paramaters for that domain. Particularly in 95 larger networks it is not feasible to configure such parameters 96 manually, which forms the requirement for a dynamic MAP provisioning 97 mechanism that is defined in this document based on the existing 98 DHCPv6 [RFC3315] protocol. The configuration of the MAP BR is 99 outside of scope of this document. 101 This document specifies the DHCPv6 options that allow MAP CE 102 provisioning, based on the definitions of parameters provided in 103 [I-D.ietf-softwire-map], and is applicable to both MAP-E and MAP-T 104 transport variants. The definition of DHCPv6 options for MAP CE 105 provisioning does not preclude the definition of other dynamic 106 methods for configuring MAP devices, or supplementing such 107 configuration, nor is the use of DHCPv6 provisioning mandatory for 108 MAP operation. 110 Since specification of MAP architecture is still expected to evolve, 111 DHCPv6 options may have to evolve too to fit the revised MAP 112 specification. 114 Described proposal is not a dynamic port allocation mechanism. 116 Readers interested in deployment considerations are encouraged to 117 read [I-D.mdt-softwire-map-deployment]. 119 2. Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 3. MAP Information 127 The following presents the information parameters that are used to 128 configure a MAP CE: 130 o A Default Mapping Rule (DMR). This rule governs the default 131 forwarding/mapping behaviour of the MAP CE, ie it informs the CE 132 of the BR router's address or prefix that is typically used as a 133 default. The DMR is a mandatory parameter for a MAP CE. 134 o A Basic Mapping Rule (BMR). This rule governs the MAP 135 configuration of the CE, including that of completing the CE's MAP 136 IPv6 address, as well as deriving the CEs IPv4 parameters. Key 137 parameters of a BMR include: i) The IPv4 Prefix - Used to derive 138 the CE's IPv4 address; ii) The Embedded Address bit length - Used 139 to derive how many, if any, of the CE's IPv6 address is mapped to 140 the IPv4 address. iii) The IPv6 prefix - used to determine the 141 CE's IPv6 MAP domain prefix that is to form the base for the CE's 142 MAP address. The BMR is an optional rule for a MAP CE. 143 o A Forward Mapping Rule (FMR). This rule governs the MAP CE-CE 144 forwarding behaviour for IPv4 destinations covered by the rule. 145 The FMR is effectively a special type of an BMR, given that it 146 shares exactly the same configuration parameters, except that 147 these parameters are only applied for setting up forwarding. Its 148 presence enables a given CE to communicate directly in "mesh mode" 149 with other CEs. The FMR is an optional rule, and the absence of 150 such a rule indicates that the CE is to simply use its default 151 mapping rule for all destinations. 152 o Transport mode; encapsulation (MAP-E) or translation (MAP-T) modes 153 to be used for the MAP CE Domain. 154 o Additional parameters. The MAP specification allows great 155 flexibility in the level of automation a CE uses to derive its 156 IPv4 address and port-sharing (PSID), ranging from full derivation 157 of these parameters from the CE's IPv6 prefix, to full 158 parametrization of MAP configuration independent of the CE's IPv6 159 prefix. Optional parameters such as the PSID allow this 160 flexibility. 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 is only one option defined that may appear 279 in rule sub-options field, eg the OPTION_MAP_PORTPARAMS, defined 280 in section Section 4.4. 282 The value of the EA-len and prefix4-len SHOULD be equal to or greater 283 than 32. 285 The Format of the MAP Rule Flags field is: 287 0 1 2 3 4 5 6 7 288 +-+-+-+-+-+-+-+-+ 289 |Reserved |F| 290 +-+-+-+-+-+-+-+-+ 292 Figure 4: MAP Rule Flags 294 o Reserved: 7-bits reserved for future use as flags. 295 o F-Flag: 1 bit field that specifies whether the rule is to be used 296 for forwarding (FMR). 0x0 = This rule is NOT used as an FMR. 0x1 = 297 This rule is also an FMR. 298 o Note: BMR rules can be also FMR rules by setting the F flag. BMR 299 rules are determined by a match of the Rule-IPv6-prefix against 300 the CPE's prefix(es). 302 It is expected that in a typical MAP deployment scenarios, there will 303 be a single DMR and a single BMR, which could also be designated as 304 an FMR using the F-Flag. 306 4.3. MAP DMR Option 308 Figure X shows the format of the MAP Rule option used for conveying 309 the DMR. 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | OPTION_MAP_DMR | option-length | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |dmr-prefix6-len| dmr-ipv6-prefix | 317 +-+-+-+-+-+-+-+-+ (variable length) | 318 . . 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 . sub-options (variable length) . 322 . . 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Figure 5: MAP DMR Option 327 o option-code: OPTION_MAP_DMR (TBD3) 328 o option-length: 1 + length of dmr-ipv6-prefix + sub-options in 329 bytes 330 o dmr-prefix6-len: T8 bits long field expressing the bit mask length 331 of the IPv6 prefix specified in the dmr-ipv6-prefix field. 332 o dmr-ipv6-prefix: a variable length field that specifies the IPv6 333 prefix or address for the MAP BR. This field is padded with zeros 334 up to the nearest octet boundary when prefix4-len is not divisible 335 by 8. 336 o sub options: options associatied to this MAP DMR option. 338 4.4. MAP Port Parameters Option 340 Port Parameters Option specifies optional Rule Port Parameters that 341 MAY be provided as part of the Mapping Rule. It MAY appear as sub- 342 option in OPTION_MAP_RULE option. It MUST NOT appear directly in a 343 message. 345 See [I-D.ietf-softwire-map], Section 5.1 for detailed description of 346 Port mapping algorithm. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | OPTION_MAP_PORTPARAMS | option-length | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | rsv |offset | rsv | PSID-len| PSID | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Figure 6: MAP Port Parameters Option 358 o option-code: OPTION_MAP_PORTPARAMS (TBD4) 359 o option-length: 4 360 o rsvd: This 4-bits long field is currently not used and MUST be set 361 to 0 by server. Its value MUST be ignored by clients. 362 o offset: (PSID offset) 4 bits long field that specifies the numeric 363 value for the MAP algorithm's excluded port range/offset bits 364 (A-bits), as per section 5.1.1 in [I-D.ietf-softwire-map]. 365 Default must be set to 4. 366 o PSID-len: Bit length value of the number of significant bits in 367 the PSID field. (also known as 'k'). When set to 0, the PSID 368 field is to be ignored. After the first 'a' bits, there are k 369 bits in the port number representing valid of PSID. Subsequently, 370 the address sharing ratio would be 2 ^k. 371 o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value 372 algorithmically identifies a set of ports assigned to a CE. The 373 first k-bits on the left of this 2-octets field is the PSID value. 374 The remaining (16-k) bits on the right are padding zeros. 376 When receiveing the Port Parameters option with an explicit PSID, the 377 client MUST use this explicit PSID in configuring its MAP interface. 379 5. MAP Options Examples 381 DHCPv6 server provisioning a single MAP Rule to a CE (DHCPv6 client) 382 will convey the following MAP options in its messages: 384 5.1. BMR Option Example 386 TODO: Reflect example in section 5.2 of MAP draft 388 Figure 7: BMR Option Example 390 5.2. FMR Option Example 392 TODO: Reflect example in section 5.3 of MAP draft 394 Figure 8: FMR Option Example 396 5.3. DMR Option Example 398 TODO: Reflect example in section 5.4 of MAP draft 400 Figure 9: DMR Option Examples 402 6. DHCPv6 Server Behavior 404 RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and 405 server negotiate configuration values using the ORO. As a 406 convenience to the reader, we mention here that a server will by 407 default not reply with a MAP Rule Option if the client has not 408 explicitly enumerated it on its Option Request Option. 410 A Server following this specification MUST allow the configuration of 411 one or more MAP Rule Options, and SHOULD send such options grouped 412 under a single MAP_OPTION. 414 Server MUST transmit all configured instances of the Mapping Rule 415 Options with all sub-options, if client requested it using 416 OPTION_MAP_RULE in its Option Request Option (ORO). Server MUST 417 transmit MAP Flags Option if client requested OPTION_MAP in its ORO. 419 The server MUST be capable of following per client assignment rules 420 when assigning MAP options. 422 7. DHCPv6 Client Behavior 424 A MAP CE acting as DHCPv6 client will request MAP configuration to be 425 assigned by the DHCPv6 server located in the ISP network. A client 426 supporting MAP functionality SHOULD request OPTION_MAP, 427 OPTION_MAP_RULE and OPTION_MAP_DMR options in its ORO in SOLICIT, 428 REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages. 430 When processing received MAP options the following behaviour is 431 expected: 433 o A client MUST support processing multiple received OPTION_MAP_RULE 434 options in a OPTION_MAP option 435 o A client receiving an unsupported MAP option, or an unrecognized 436 parameter value SHOULD discard the entire OPTION_MAP. 437 o Only one OPTION_MAP_DMR is allowed per OPTION_MAP option. 439 The client MUST be capable of applying the received MAP option 440 parameters for the configuration of the local MAP instance. 442 Note that system implementing MAP CE functionality may have multiple 443 network interfaces, and these interfaces may be configured 444 differently; some may be connected to networks that call for MAP, and 445 some may be connected to networks that are using normal dual stack or 446 other means. The MAP CE system should approach this specification on 447 an interface-by-interface basis. For example, if the CE system is 448 attached to multiple networks that provide the MAP Mapping Rule 449 Option, then the CE system MUST configure a MAP connection (i.e. a 450 translation or encapsulation) for each interface separately as each 451 MAP provides IPv4 connectivity for each distinct interface. Means to 452 bind a MAP configuration to a given interface in a multiple 453 interfaces device are out of scope of this document. 455 8. Usage of flags and paramaters 457 The defined MAP options contain a number of flags and parameters that 458 are intended to provide full flexibility in the configuration of a 459 MAP CE. Some usage examples are: 461 o A MAP CE receiving an OPTION_MAP option with the T flag set to 1 462 will assume a MAP-E (encapsulation) mode of operation for the 463 domain and all associated rules. Conversely, when the received 464 option has the T flag set to 0, the CE will assume a MAP-T 465 (stateless NAT46 translation) mode of operation. 466 o The presence of a OPTION_MAP_RULE option, along with IPv4 prefix 467 parameters, indicates to the MAP CE that NAPT44 mode of operation 468 is expected, following the address mapping rules defined in 469 [I-D.ietf-softwire-map]. Conversely, the absence of an 470 OPTION_MAP_RULE option indicates that NAT44 mode is not required, 471 and that the MAP CE is to plainly encapsulate (MAP-E mode) or 472 statelessly translate using NAT64 (MAP-T mode) any IPv4 traffic 473 sent following the DMR. 474 o The MAP domain ipv6-prefix in the BMR should correspond to a 475 service prefix assigned to the CPE by the operator, with the 476 latter being assigned using regular IPv6 means, eg DHCP PD or 477 SLAAC. This parameter allows the CPE to select the prefix for MAP 478 operation. 480 o The EA_LEN parameter, along with the length of the IPv4 prefix in 481 the BMR option, allows the MAP CE to determine whether address 482 sharing is in effect, and what is the address sharing ratio. Eg: 483 A prefix4-len of 16 bits, and EA-len of 18 combines to a 32 bit 484 IPv4 address with a sharing ratio of 4. 485 o The use of the F(orward) flag in the BMR allows a CE to apply a 486 received BMR as an FMR, thereby enabling mesh-mode for the domain 487 covered by the BMR rule. 488 o In the absence of a BMR, the presence of the mandatory DMR 489 indicates to the CPE the address or prefix of a BR, and makes the 490 MAP CE fully compatible with DS-Lite and stateful or stateless 491 NAT64 core nodes. Eg a MAP CE configured in MAP-E mode, with just 492 a DMR and a BR IPv6 address equivalent to that of the AFTR, 493 effectively acts as a DS-Lite B4 element. For more discussion 494 about MAP deployment considerations, see 495 [I-D.mdt-softwire-map-deployment]. 497 9. Deployment considerations 499 Usage of PSID Option should be avoided if possible and PSID embedded 500 in the delegated prefix should be used instead. This allows MAP 501 deployment to not introduce any additional state in DHCP server. 502 PSID Option must be assigned on a per CE basis, thus requiring more 503 complicated server configuration. 505 In a typical environment, there will be only one MAP domain, so 506 server will provide only a single instance of MAP option that acts a 507 container for MAP Rule Options and other options that are specific to 508 that MAP domain. 510 In case of multiple provisioning domains, as defined in 511 [I-D.ietf-homenet-arch], one server may be required to provide 512 information about more than one MAP domain. In such case, server 513 will provide two or more instances of MAP Options, each with its own 514 set of sub-option that define MAP rules for each specific MAP domain. 515 Details of mulitple provisioning domains are discussed in Section 4.1 516 of [I-D.mdt-softwire-map-deployment]. 518 10. IANA Considerations 520 IANA is kindly requested to allocate DHCPv6 option codes for TBD1 for 521 OPTION_MAP, TBD2 for OPTION_MAP_RULE, TBD3 for OPTION_MAP_DMR, and 522 TBD4 for OPTION_MAP_Port. All values should be added to the DHCPv6 523 option code space defined in Section 24.3 of [RFC3315]. 525 11. Security Considerations 527 Implementation of this document does not present any new security 528 issues, but as with all DHCPv6-derived configuration state, it is 529 completely possible that the configuration is being delivered by a 530 third party (Man In The Middle). As such, there is no basis to trust 531 that the access over the MAP can be trusted, and it should not 532 therefore bypass any security mechanisms such as IP firewalls. 534 Readers concerned with security of MAP provisioning over DHCPv6 are 535 encouraged to familiarize with [I-D.ietf-dhc-secure-dhcpv6]. 537 Section XX of [I-D.ietf-softwire-map] discusses security issues of 538 the MAP mechanism. 540 Section 23 of [RFC3315] discusses DHCPv6-related security issues. 542 12. Acknowledgements 544 This document was created as a product of a MAP design team. 545 Following people were members of that team: Congxiao Bao, Mohamed 546 Boucadair, Gang Chen, Maoke Chen, Wojciech Dec, Xiaohong Deng, Jouni 547 Korhonen, Xing Li, Satoru Matsushima, Tomasz Mrugalski, Tetsuya 548 Murakami, Jacni Qin, Necj Scoberne, Qiong Sun, Tina Tsou, Dan Wing, 549 Leaf Yeh and Jan Zorz. 551 Former MAP design team members are: Remi Despres. 553 13. References 555 13.1. Normative References 557 [I-D.ietf-softwire-map] 558 Troan, O., Dec, W., Li, X., Bao, C., Zhai, Y., Matsushima, 559 S., and T. Murakami, "Mapping of Address and Port (MAP)", 560 draft-ietf-softwire-map-01 (work in progress), June 2012. 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, March 1997. 565 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 566 and M. Carney, "Dynamic Host Configuration Protocol for 567 IPv6 (DHCPv6)", RFC 3315, July 2003. 569 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 570 Host Configuration Protocol (DHCP) version 6", RFC 3633, 571 December 2003. 573 13.2. Informative References 575 [I-D.boucadair-dhcpv6-shared-address-option] 576 Boucadair, M., Levis, P., Grimault, J., Savolainen, T., 577 and G. Bajko, "Dynamic Host Configuration Protocol 578 (DHCPv6) Options for Shared IP Addresses Solutions", 579 draft-boucadair-dhcpv6-shared-address-option-01 (work in 580 progress), December 2009. 582 [I-D.ietf-dhc-option-guidelines] 583 Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 584 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 585 draft-ietf-dhc-option-guidelines-08 (work in progress), 586 June 2012. 588 [I-D.ietf-dhc-secure-dhcpv6] 589 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 590 draft-ietf-dhc-secure-dhcpv6-06 (work in progress), 591 March 2012. 593 [I-D.ietf-homenet-arch] 594 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 595 "Home Networking Architecture for IPv6", 596 draft-ietf-homenet-arch-03 (work in progress), June 2012. 598 [I-D.ietf-tsvwg-iana-ports] 599 Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 600 Cheshire, "Internet Assigned Numbers Authority (IANA) 601 Procedures for the Management of the Service Name and 602 Transport Protocol Port Number Registry", 603 draft-ietf-tsvwg-iana-ports-10 (work in progress), 604 February 2011. 606 [I-D.mdt-softwire-map-deployment] 607 Sun, Q., Chen, M., Chen, G., Sun, C., Tsou, T., and S. 608 Perreault, "Mapping of Address and Port (MAP) - Deployment 609 Considerations", draft-mdt-softwire-map-deployment-02 610 (work in progress), June 2012. 612 [I-D.mrugalski-dhc-dhcpv6-4rd] 613 Mrugalski, T., "DHCPv6 Options for IPv4 Residual 614 Deployment (4rd)", draft-mrugalski-dhc-dhcpv6-4rd-00 (work 615 in progress), July 2011. 617 [I-D.murakami-softwire-4rd] 618 Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual 619 Deployment on IPv6 infrastructure - protocol 620 specification", draft-murakami-softwire-4rd-01 (work in 621 progress), September 2011. 623 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 624 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 625 May 2008. 627 Authors' Addresses 629 Tomasz Mrugalski 630 Internet Systems Consortium, Inc. 631 950 Charter Street 632 Redwood City, CA 94063 633 USA 635 Phone: +1 650 423 1345 636 Email: tomasz.mrugalski@gmail.com 637 URI: http://www.isc.org/ 639 Ole Troan 640 Cisco Systems, Inc. 641 Telemarksvingen 20 642 Oslo N-0655 643 Norway 645 Email: ot@cisco.com 646 URI: http://cisco.com 648 Congxiao Bao 649 CERNET Center/Tsinghua University 650 Room 225, Main Building, Tsinghua University 651 Beijing 100084 652 CN 654 Phone: +86 10-62785983 655 Email: congxiao@cernet.edu.cn 656 Wojciech Dec 657 Cisco Systems, Inc. 658 The Netherlands 660 Phone: 661 Fax: 662 Email: wdec@cisco.com 663 URI: