idnits 2.17.1 draft-ietf-softwire-map-dhcp-06.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 (November 19, 2013) is 3810 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 593, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-option-guidelines' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-homenet-arch' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'I-D.mdt-softwire-map-deployment' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'I-D.townsley-troan-ipv6-ce-transitioning' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC6335' is defined on line 663, 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-14 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-11 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-03 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-map-t-04 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-08 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-unified-cpe-01 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 3 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, Ed. 5 Expires: May 23, 2014 Cisco Systems 6 W. Dec 7 Cisco 8 C. Bao 9 Tsinghua University 10 L. Yeh 11 Freelancer Technologies 12 X. Deng 14 November 19, 2013 16 DHCPv6 Options for configuration of Softwire Address and Port Mapped 17 Clients 18 draft-ietf-softwire-map-dhcp-06 20 Abstract 22 This document specifies DHCPv6 options, termed Softwire46 options, 23 for the provisioning of Softwire46 Customer Edge (CE) devices. 24 Softwire46 is a collective term used to refer to architectures based 25 on the notion of IPv4 Address+Port (A+P) for providing IPv4 26 connectivity across an IPv6 network. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 23, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Softwire 46 Overview . . . . . . . . . . . . . . . . . . . . 3 65 4. Common Softwire 46 DHCPv6 Options . . . . . . . . . . . . . . 4 66 4.1. S46 Rule Option . . . . . . . . . . . . . . . . . . . . . 4 67 4.2. S46 BR Option . . . . . . . . . . . . . . . . . . . . . . 6 68 4.3. S46 DMR Option . . . . . . . . . . . . . . . . . . . . . 7 69 4.4. S46 IPv4 Address Option . . . . . . . . . . . . . . . . . 7 70 4.5. S46 Port Parameters Option . . . . . . . . . . . . . . . 8 71 5. Softwire 46 Container DHCPv6 Options . . . . . . . . . . . . 9 72 5.1. Softwire46 MAP-E Container Option . . . . . . . . . . . . 9 73 5.2. Softwire46 MAP-T Container Option . . . . . . . . . . . . 10 74 5.3. Softwire46 LightWeight 46 Container Option . . . . . . . 10 75 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 11 76 7. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 11 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 11.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 A number of architectural solution proposals discussed in the IETF 88 Softwires Working Group use Address and Port (A+P) as their 89 technology base in providing IPv4 connectivity service to end users 90 using CE devices across a service provider's IPv6 network, while 91 allowing for shared or dedicated IPv4 addressing of the CEs. 93 An example is Mapping of Address and Port (MAP) defined in 94 [I-D.ietf-softwire-map]. The MAP solution consists of one or more 95 MAP Border Relay (BR) routers, responsible for stateless forwarding 96 between a MAP IPv6 domain and an IPv4 network, and one or more MAP 97 Customer Edge (CE) routers, responsible for forwarding between a 98 user's private IPv4 network and the MAP IPv6 network domain. 99 Collectively the MAP CE and BR form a domain when configured with 100 common service parameters. This characteristic is common to all of 101 the Softwire46 proposals. 103 To function in such a domain, a CE needs to be provisioned with the 104 appropriate A+P service parameters for that domain. These consist 105 primarily of the CE's IPv4 address and transport layer port-range(s). 106 Furthermore, the IPv6 transport mode (i.e. encapsulation or 107 translation) needs to be specified. Provisioning of other IPv4 108 configuration information not derived directly from the A+P service 109 parameters is not covered in this document. It is expected that 110 provisioning of other IPv4 configuration will continue to use DHCPv4 111 [RFC2131]. 113 This memo specifies a set of DHCPv6 [RFC3315] options to provision 114 Softwire46 information to CE routers. Configuration of the BR is out 115 of scope of this document. 117 2. Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 3. Softwire 46 Overview 125 This document describes a set of common DHCPv6 options for MAP-E 126 [I-D.ietf-softwire-map], MAP-T [I-D.ietf-softwire-map-t] and 127 Lightweight 4over6 [I-D.ietf-softwire-lw4over6] mechanisms. 129 MAP-E, MAP-T and Lightweight 4over6 are essentially providing the 130 same functionality: IPv4 service to a CE router over an IPv6 only 131 access network. MAP-E and MAP-T may embed parts of the IPv4 address 132 in IPv6 prefixes, thereby supporting many clients with a fixed set of 133 mapping rules and mesh mode (direct CE to CE communication). MAP-E 134 and MAP-T CEs may also be provisioned in hub and spoke mode, and in 135 1:1 mode (no embedded address bits). The difference between MAP-E 136 and MAP-T is that they use different means to connect to the IPv6 137 domain. MAP-E uses RFC2473 [RFC2473] IPv4 over IPv6 tunnelling, 138 while MAP-T uses NAT64 [RFC6145] based translation. Lightweight 139 4over6 is a hub and spoke IPv4 over IPv6 tunnel mechanism, with 140 complete independence of IPv4 and IPv6 addressing (zero embedded 141 address bits). 143 The DHCP options described here tie the provisioning parameters, and 144 hence the IPv4 service itself, to the End-user IPv6 prefix lifetime. 145 The validity of the softwire IPv4 address, prefix or shared IPv4 146 address, port set and any authorisation and accounting are tied to 147 the lifetime of its associated End-user IPv6 prefix. 149 To support more than one mechanism at a time and to allow for a 150 possibility of transition between them, the Option Request Option 151 DHCPv6 [RFC3315] function is used. Each mechanism has a 152 corresponding container option. A DHCPv6 client can request a 153 particular mechanism by including the option code for a particular 154 container option in its ORO option. The provisioning parameters for 155 that mechanism are expressed by embedding the common format options 156 within the respective container. 158 This approach implies that the all the provisioning options MUST 159 appear only within the container options. The client MUST NOT 160 request any of the provisioning options directly within an ORO. 161 Likewise, the server MUST NOT send the provisioning options directly 162 within DHCPv6 message, without encapsulating them in the 163 corresponding container options. 165 The document is organized with the common sub-options described 166 first, and then the three container options. Some of the sub-options 167 are mandatory in some of the containers and some are optional, or not 168 permitted at all. 170 4. Common Softwire 46 DHCPv6 Options 172 The DHCPv6 protocol is used for Softwire46 CE provisioning following 173 regular DHCPv6 notions, with the CE assuming the role of a DHCPv6 174 client, and the DHCPv6 server providing options following typical 175 DHCPv6 server side policies. The format and usage of the options is 176 defined in the following sub-sections. 178 Each CE needs to be provisioned with enough information to calculate 179 its IPv4 address, IPv4 prefix or shared IPv4 address. MAP-E and 180 MAP-T uses the OPTION_S46_RULE, while for Lightweight 4over6, the 181 OPTION_S46_IPV4ADDRESS option is used. A CE that needs to 182 communicate outside of the A+P domain, also needs the address or 183 prefix of the BR. MAP-E and Lightweight 4over6 use the OPTION_S46_BR 184 option to communicate the IPv6 address of the BR. MAP-T forms an 185 IPv6 destination address by embedding an IPv4 destination address 186 into the BR's IPv6 prefix conveyed via the OPTION_S46_DMR option. 187 Optionally all mechanisms can include the OPTION_S46_PORTPARAMS to 188 specify parameters and port sets for the port range algorithm. 190 4.1. S46 Rule Option 192 Figure 1 shows the format of the S46 Rule option used for conveying 193 the BMR and FMR. 195 A server MAY send more than one S46 Rule Option in a container, if it 196 is configured to do so. Clients MUST NOT send a S46 Rule Option. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | OPTION_S46_RULE | option-length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | flags | ea-len | prefix4-len | ipv4-prefix | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | (continued) | prefix6-len | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | ipv6-prefix | 208 | (variable length) | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | | 211 . S46_RULE-options . 212 . . 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 1: S46 Rule Option 217 o option-code: OPTION_S46_RULE (TBD1) 218 o option-length: length of the option, excluding option-code and 219 option-length fields, including length of all encapsulated 220 options, expressed in bytes. 221 o flags: 8 bits long field carrying flags applicable to the rule. 222 The meaning of specific bits is explained in Figure 2. 223 o ea-len: 8 bits long field that specifies the Embedded-Address (EA) 224 bit length. Values allowed range from 0 to 48. 225 o prefix4-len: 8 bits long field expressing the prefix length of the 226 IPv4 prefix specified in the rule-ipv4-prefix field. Valid values 227 0 to 32. 228 o ipv4-prefix: a fixed length 32 bit field that specifies the IPv4 229 prefix for the S46 rule. Zero-padded. 230 o prefix6-len: 8 bits long field expressing the prefix length of the 231 IPv6 prefix specified in the rule-ipv6-prefix field. 232 o ipv6-prefix: a variable length field that specifies the IPv6 233 domain prefix for the S46 rule. The field is padded with follow 234 up zero bits up to the nearest octet boundary when prefix6-len is 235 not divisible by 8. 236 o S46_RULE-options: a variable field that may contain zero or more 237 options that specify additional parameters for this S46 rule, e.g. 238 a Port Parameter Option. 240 The Format of the S46 Rule Flags field is: 242 0 1 2 3 4 5 6 7 243 +-+-+-+-+-+-+-+-+ 244 |Reserved |F| 245 +-+-+-+-+-+-+-+-+ 247 Figure 2: S46 Rule Flags 249 o Reserved: 7-bits reserved for future use as flags. 250 o F-Flag: 1 bit field that specifies whether the rule is to be used 251 for forwarding (FMR). If set, this rule is used as a FMR, if not 252 set this rule is only a BMR. Note: BMR rules can be also FMR 253 rules by setting the F flag. BMR rules are determined by a match 254 of the Rule-IPv6-prefix against the CPE's prefix(es). 256 It is expected that in a typical mesh deployment scenarios, there 257 will be a single BMR, which could also be designated as an FMR using 258 the F-Flag. 260 4.2. S46 BR Option 262 S46 BR Option is used to convey the IPv6 address of the Border Relay. 263 Figure Figure 4 shows the format of the BR option. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | OPTION_S46_BR | option-length | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | br-ipv6-address | 271 | | 272 | | 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 3: S46 DMR Option 278 o option-code: OPTION_S46_BR (TBD2) 279 o option-length: 16 280 o br-ipv6-address: a fixed length field of 16 octets that specifies 281 the IPv6 address for the S46 BR. 283 BR redundancy can be implemented by using an anycast address for the 284 BR IPv6 address. Multiple BR options MAY be included in the 285 container; this document does not further explore the use of multiple 286 BR IPv6 addresses. 288 4.3. S46 DMR Option 290 S46 DMR Option is used to convey values for Default Mapping Rule. 291 Figure Figure 4 shows the format of the MAP Rule option used for 292 conveying a DMR. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | OPTION_S46_DMR | option-length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |dmr-prefix6-len| dmr-ipv6-prefix | 300 +-+-+-+-+-+-+-+-+ (variable length) | 301 . . 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 4: S46 DMR Option 306 o option-code: OPTION_S46_DMR (TBD3) 307 o option-length: 1 + length of dmr-ipv6-prefix specified in bytes. 308 o dmr-prefix6-len: 8 bits long field expressing the bit mask length 309 of the IPv6 prefix specified in the dmr-ipv6-prefix field. 310 o dmr-ipv6-prefix: a variable length field that specifies the IPv6 311 prefix or address for the S46 BR. This field is padded with 312 follow up zeros to the nearest octet boundary when dmr-prefix6-len 313 is not divisible by 8. 315 4.4. S46 IPv4 Address Option 317 The IPv4 address Option MAY be used to specify the full or shared 318 IPv4 address of the CE. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | OPTION_S46_IPV4ADDRESS | option-length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | ipv4-address | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 . S46_IPV4ADDRESS-options . 329 . . 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 5: S46 IPv4 address Option 334 o option-code: OPTION_S46_IPV4ADDRESS (TBD4) 335 o option-length: 4 336 o ipv4-address: A fixed field of 4 octets specifying an IPv4 337 address. 338 o S46_IPV4ADDRESS-options: a variable field that may contain zero or 339 more options that specify additional parameters e.g. a Port 340 Parameter Option. 342 4.5. S46 Port Parameters Option 344 The Port Parameters Option specifies optional Rule Port Parameters 345 that MAY be provided as part of the Mapping Rule for CEs using the 346 MAP algorithm. 348 See [I-D.ietf-softwire-map], Section 5.1 for detailed description of 349 MAP algorithm that explains meaning of all parameters. 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | OPTION_S46_PORTPARAMS | option-length | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | offset | PSID-len | PSID | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Figure 6: S46 Port Parameters Option 361 o option-code: OPTION_S46_PORTPARAMS (TBD5) 362 o option-length: 4 363 o offset: (PSID offset) 8 bits long field that specifies the numeric 364 value for the S46 algorithm's excluded port range/offset bits 365 (A-bits), as per section 5.1.1 in [I-D.ietf-softwire-map]. 366 Allowed values are between 0 and 16, with the default value being 367 6. 368 o PSID-len: Bit length value of the number of significant bits in 369 the PSID field. (also known as 'k'). When set to 0, the PSID 370 field is to be ignored. After the first 'a' bits, there are k 371 bits in the port number representing valid of PSID. Subsequently, 372 the address sharing ratio would be 2^k. 373 o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value 374 algorithmically identifies a set of ports assigned to a CE. The 375 first k-bits on the left of this 2-octets field is the PSID value. 376 The remaining (16-k) bits on the right are padding zeros. 378 When receiving the Port Parameters option with an explicit PSID, the 379 client MUST use this explicit PSID in configuring its MAP interface. 380 If the conveyed IPv4 address is not 32 bit-long. The formula for 381 this check is "prefix4-len + ea-len = 32" and serves to ensure that 382 the explicit PSID is only applied to configurations with a completely 383 formed IPv4 address. 385 The OPTION_S46_PORTPARAMS option MUST be encapsulated in a 386 OPTION_S46_RULE option or an OPTION_S46_IPV4ADDRESS option. It MUST 387 NOT appear directly within a container option. 389 5. Softwire 46 Container DHCPv6 Options 391 +------------------------+-------+-------+--------------------+ 392 | Option | MAP-E | MAP-T | Lightweight 4over6 | 393 +------------------------+-------+-------+--------------------+ 394 | OPTION_S46_RULE | M | M | - | 395 | OPTION_S46_BR | M | - | M | 396 | OPTION_S46_PORTPARAMS | O | O | O | 397 | OPTION_S46_DMR | - | M | - | 398 | OPTION_S46_IPV4ADDRESS | - | - | O | 399 +------------------------+-------+-------+--------------------+ 401 M - Mandatory, O - Optional, - - Not Applicable 403 Table 1: Option to Container Mappings 405 5.1. Softwire46 MAP-E Container Option 407 This MAP-E Container Option specifies the container used to group all 408 rules and optional port parameters for a specified domain. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | OPTION_S46_CONT_MAPE | option-length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | 416 . encapsulated-options (variable length) . 417 . . 418 +---------------------------------------------------------------+ 420 Figure 7: MAP-E Container Option 422 o option-code: OPTION_S46_CONT_MAPE (TBD6) 423 o option-length: Length of encapsulated options 424 o encapsulated-options: options associated with this Softwire46 425 MAP-E domain. 427 The encapsulated options field encapsulates those options that are 428 specific to this MAP Option. Currently there are two options 429 specified for the OPTION_S46_CONT_MAPE option, OPTION_S46_RULE and 430 OPTION_S46_BR. There MUST be at least one OPTION_S46_RULE option and 431 at least one OPTION_S46_BR. 433 Other options suitable for a domain may be defined in the future. A 434 DHCP message MAY include multiple S46 MAPE Container Options 435 (representing multiple domains). 437 5.2. Softwire46 MAP-T Container Option 439 This MAP-T Container Option specifies the container used to group all 440 rules and optional port parameters for a specified domain. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | OPTION_S46_CONT_MAPT | option-length | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | | 448 . encapsulated-options (variable length) . 449 . . 450 +---------------------------------------------------------------+ 452 Figure 8: MAP-E Container Option 454 o option-code: OPTION_S46_CONT_MAPT (TBD7) 455 o option-length: Length of encapsulated options 456 o encapsulated-options: options associated with this Softwire46 457 MAP-T domain. 459 The encapsulated options field encapsulates those options that are 460 specific to this MAP Option. Currently there are two options 461 specified for the OPTION_S46_CONT_MAPT option, OPTION_S46_RULE and 462 OPTION_S46_DMR options. There MUST be at least one OPTION_S46_RULE 463 option and exactly one OPTION_S46_DMR. 465 5.3. Softwire46 LightWeight 46 Container Option 467 This LW46 Container Option specifies the container used to group all 468 rules and optional port parameters for a specified domain. 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | OPTION_S46_CONT_LW | option-length | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | | 476 + encapsulated-options (variable length) . 477 . . 479 +---------------------------------------------------------------+ 481 Figure 9: LW46 Container Option 483 o option-code: OPTION_S46_CONT_LW (TBD8) 484 o option-length: Length of encapsulated options 485 o encapsulated-options: options associated with this Softwire46 486 domain. 488 The encapsulated options field encapsulates those options that are 489 specific to this Lightweight 4over6 Option. Currently there are two 490 options specified for the OPTION_S46_CONT_LW option, 491 OPTION_S46_IPV4ADDRESS and OPTION_S46_BR. There MUST be at most one 492 OPTION_S46_IPV4ADDRESS option and at least one OPTION_S46_BR option. 494 6. DHCPv6 Server Behavior 496 RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and 497 server negotiate configuration values using the ORO. As a 498 convenience to the reader, we mention here that a server will by 499 default not reply with a Softwire 46 Container Option if the client 500 has not explicitly enumerated it in its Option Request Option. 502 A CE router may support several or all of the mechanisms mentioned 503 here. In the case where a client requests multiple mechanisms in its 504 ORO option, the server SHOULD reply with all the corresponding 505 Softwire 46 Container options, enumerated in the Option Request 506 Option, it is configured for. 508 7. DHCPv6 Client Behavior 510 A S46 CE acting as DHCPv6 client will request S46 configuration to be 511 assigned by the DHCPv6 server located in the IPv6 network. Such a 512 client SHOULD include the S46 Container option(s) that it is 513 interested in, in its ORO in SOLICIT, REQUEST, RENEW, REBIND and 514 INFORMATION-REQUEST messages. 516 When processing received S46 container options the following 517 behaviour is expected: 519 o A client MUST support processing multiple received OPTION_S46_RULE 520 options in a container OPTION_S46_CONT_MAPE or 521 OPTION_S46_CONT_MAPT option 522 o A client receiving an unsupported S46 option, or an invalid 523 parameter value SHOULD discard that S46 Container option and log 524 the event. 526 The behavior of a client supporting multiple Softwire 46 mechanisms, 527 is out of scope of this document. See: 528 [I-D.ietf-softwire-unified-cpe] for how to prioritise and handle 529 multiple simulatanous mechanisms in use. 531 Note that system implementing CE functionality may have multiple 532 network interfaces, and these interfaces may be configured 533 differently; some may be connected to networks that call for MAP, and 534 some may be connected to networks that are using normal dual stack or 535 other means. The CE system should approach this specification on an 536 interface-by-interface basis. For example, if the CE system is MAP 537 capable and is attached to multiple networks that provide the MAP 538 Mapping Rule Option, then the CE system MUST configure a MAP service 539 (i.e. a translation or encapsulation) for each interface separately 540 as each MAP provides IPv4 connectivity for each distinct interface. 541 Means to bind a MAP configuration to a given interface in a multiple 542 interfaces device are out of scope of this document. 544 8. Security Considerations 546 Implementation of this document does not present any new security 547 issues, but as with all DHCPv6-derived configuration state, it is 548 completely possible that the configuration is being delivered by a 549 third party (Man In The Middle). As such, there is no basis to trust 550 that the access over the MAP can be trusted, and it should not 551 therefore bypass any security mechanisms such as IP firewalls. 553 Readers concerned with security of MAP provisioning over DHCPv6 are 554 encouraged to read [I-D.ietf-dhc-secure-dhcpv6]. 556 Section 11 of [I-D.ietf-softwire-map] discusses security issues of 557 the MAP mechanism. 559 Section 23 of [RFC3315] discusses DHCPv6-related security issues. 561 9. IANA Considerations 563 IANA is kindly requested to allocate the following DHCPv6 option 564 codes: TBD1 for OPTION_S46_RULE, TBD2 for OPTION_S4_BR, TBD3 for 565 OPTION_S46_DMR, TBD4 for OPTION_S46_IPV4ADDRESS, TBD5 for 566 OPTION_S46_PORTPARAMS, and TBD6 for OPTION_S46_CONT_MAPE, TBD7 for 567 OPTION_S46_CONT_MAPT and TBD8 for OPTION_S46_CONT_LW All values 568 should be added to the DHCPv6 option code space defined in 569 Section 24.3 of [RFC3315]. 571 10. Acknowledgements 572 This document was created as a product of a MAP design team. 573 Following people were members of that team: Congxiao Bao, Mohamed 574 Boucadair, Gang Chen, Maoke Chen, Wojciech Dec, Xiaohong Deng, Jouni 575 Korhonen, Xing Li, Satoru Matsushima, Tomasz Mrugalski, Tetsuya 576 Murakami, Jacni Qin, Necj Scoberne, Qiong Sun, Tina Tsou, Dan Wing, 577 Leaf Yeh and Jan Zorz. 579 Authors would like to thank Bernie Volz for his insightful comments 580 and suggestions. 582 11. References 584 11.1. Normative References 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, March 1997. 589 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 590 and M. Carney, "Dynamic Host Configuration Protocol for 591 IPv6 (DHCPv6)", RFC 3315, July 2003. 593 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 594 Host Configuration Protocol (DHCP) version 6", RFC 3633, 595 December 2003. 597 11.2. Informative References 599 [I-D.ietf-dhc-option-guidelines] 600 Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 601 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 602 draft-ietf-dhc-option-guidelines-14 (work in progress), 603 September 2013. 605 [I-D.ietf-dhc-secure-dhcpv6] 606 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", draft- 607 ietf-dhc-secure-dhcpv6-07 (work in progress), September 608 2012. 610 [I-D.ietf-homenet-arch] 611 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 612 "IPv6 Home Networking Architecture Principles", draft- 613 ietf-homenet-arch-11 (work in progress), October 2013. 615 [I-D.ietf-softwire-lw4over6] 616 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 617 I. Farrer, "Lightweight 4over6: An Extension to the DS- 618 Lite Architecture", draft-ietf-softwire-lw4over6-03 (work 619 in progress), November 2013. 621 [I-D.ietf-softwire-map-t] 622 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 623 T. Murakami, "Mapping of Address and Port using 624 Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work 625 in progress), September 2013. 627 [I-D.ietf-softwire-map] 628 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 629 Murakami, T., and T. Taylor, "Mapping of Address and Port 630 with Encapsulation (MAP)", draft-ietf-softwire-map-08 631 (work in progress), August 2013. 633 [I-D.ietf-softwire-unified-cpe] 634 Boucadair, M., Farrer, I., Perreault, S., and S. 635 Sivakumar, "Unified IPv4-in-IPv6 Softwire CPE", draft- 636 ietf-softwire-unified-cpe-01 (work in progress), May 2013. 638 [I-D.mdt-softwire-map-deployment] 639 Sun, Q., Chen, M., Chen, G., Sun, C., Tsou, T., and S. 640 Perreault, "Mapping of Address and Port (MAP) - Deployment 641 Considerations", draft-mdt-softwire-map-deployment-02 642 (work in progress), June 2012. 644 [I-D.townsley-troan-ipv6-ce-transitioning] 645 Townsley, M. and O. Troan, "Basic Requirements for 646 Customer Edge Routers - multihoming and transition", 647 draft-townsley-troan-ipv6-ce-transitioning-02 (work in 648 progress), December 2011. 650 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 651 2131, March 1997. 653 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 654 IPv6 Specification", RFC 2473, December 1998. 656 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 657 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 658 May 2008. 660 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 661 Algorithm", RFC 6145, April 2011. 663 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 664 Cheshire, "Internet Assigned Numbers Authority (IANA) 665 Procedures for the Management of the Service Name and 666 Transport Protocol Port Number Registry", BCP 165, RFC 667 6335, August 2011. 669 Authors' Addresses 671 Tomasz Mrugalski 672 Internet Systems Consortium, Inc. 673 950 Charter Street 674 Redwood City, CA 94063 675 USA 677 Phone: +1 650 423 1345 678 Email: tomasz.mrugalski@gmail.com 679 URI: http://www.isc.org/ 681 Ole Troan (editor) 682 Cisco Systems 683 Philip Pedersens vei 1 684 Lysaker 1366 685 Norway 687 Email: ot@cisco.com 689 Wojciech Dec 690 Cisco Systems, Inc. 691 The Netherlands 693 Email: wdec@cisco.com 694 URI: http://cisco.com 696 Congxiao Bao 697 CERNET Center/Tsinghua University 698 Room 225, Main Building, Tsinghua University 699 Beijing 100084 700 CN 702 Phone: +86 10-62785983 703 Email: congxiao@cernet.edu.cn 705 Leaf Y. Yeh 706 Freelancer Technologies 707 Shenzhen, Guangdong 708 P. R. China 710 Email: leaf.yeh.sdo@gmail.com 711 Xiaohong Deng 712 6 Cordelia St. 713 South Brisbane QLD 4101 714 Australia 716 Phone: +61 3858 3128 717 Email: dxhbupt@gmail.com