idnits 2.17.1 draft-ietf-softwire-map-dhcp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2013) is 3839 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 615, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-option-guidelines' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-homenet-arch' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-unified-cpe' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'I-D.mdt-softwire-map-deployment' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'RFC6335' is defined on line 682, 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-13 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-06 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-01 == 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-07 == 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: April 18, 2014 Cisco Systems 6 W. Dec 7 Cisco 8 C.X. Bao 9 Tsinghua University 10 L. Yeh 11 Freelancer Technologies 12 X. Deng 13 October 15, 2013 15 DHCPv6 Options for configuration of Softwire Address and Port Mapped 16 Clients 17 draft-ietf-softwire-map-dhcp-05 19 Abstract 21 This document specifies DHCPv6 options, termed Softwire46 options, 22 for the provisioning of Softwire46 Customer Edge (CE) devices. 23 Softwire46 is a collective term used to refer to architectures based 24 on the notion of IPv4 Address+Port (A+P) for providing IPv4 25 connectivity across an IPv6 network. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 18, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Softwire 46 approaches discussed . . . . . . . . . . . . . . . 3 63 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Softwire 46 Overview . . . . . . . . . . . . . . . . . . . . . 3 65 5. Common Softwire 46 DHCPv6 Options . . . . . . . . . . . . . . 4 66 5.1. S46 Rule Option . . . . . . . . . . . . . . . . . . . . . 5 67 5.2. S46 BR Option . . . . . . . . . . . . . . . . . . . . . . 6 68 5.3. S46 DMR Option . . . . . . . . . . . . . . . . . . . . . . 7 69 5.4. S46 IPv4 Address Option . . . . . . . . . . . . . . . . . 7 70 5.5. S46 Port Parameters Option . . . . . . . . . . . . . . . . 8 71 6. Softwire 46 Container DHCPv6 Options . . . . . . . . . . . . . 9 72 6.1. Softwire46 MAP-E Container Option . . . . . . . . . . . . 9 73 6.2. Softwire46 MAP-T Container Option . . . . . . . . . . . . 10 74 6.3. Softwire46 LightWeight 46 Container Option . . . . . . . . 10 75 7. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 11 76 8. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 11 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 12.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 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 [I-D.ietf- 94 softwire-map]. The MAP solution consists of one or more MAP Border 95 Relay (BR) routers, responsible for stateless forwarding between a 96 MAP IPv6 domain and an IPv4 network, and one or more MAP Customer 97 Edge (CE) routers, responsible for forwarding between a user's 98 private IPv4 network and the MAP IPv6 network domain. Collectively 99 the MAP CE and BR form a domain when configured with common service 100 parameters. This characteristic is common to all of the Softwire46 101 proposals. 103 To function in such a domain, a CE requires to be provisioned with 104 the appropriate A+P service parameters for that domain. This 105 consists primarily of the IPv4 address the CE should use and the 106 transport layer port-range(s). Furthermore the IPv6 transport mode 107 (e.g. encapsulation or translation) needs to be specified. 109 This memo specifies a set of DHCPv6 [RFC3315] options to provision 110 Softwire46 information to CE routers. Configuration of the BR is out 111 of scope of this document. 113 2. Softwire 46 approaches discussed 115 ***To be removed*** 117 The approach laid out in this document was taken after consideration 118 of a couple of alternatives. The first alternative was to have 119 everything in the single option. However, given that in practice 120 some CPEs might not implement all of the mechanism, this means the 121 single option would not work. The CPE would have to come up with the 122 mechanism to signal its capabilities to DHCPv6 server. Thus, the 123 conclusion was made that each mechanism requires its own option, 124 containing the per-mechanism configuration. The container design was 125 selected because the configuration elements are similar between the 126 mechanisms and having the smaller building blocks within them should 127 help to reuse the code, for the CPEs that implement multiple 128 mechanisms. After the multi-container approach was taken, the choice 129 was to keep everything in the single document or split into several 130 documents - one per mechanism. 132 3. Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 4. Softwire 46 Overview 140 This document describes a set of common DHCPv6 options for MAP-E [I-D 141 .ietf-softwire-map], MAP-T [I-D.ietf-softwire-map-t] and Lightweight 142 4over6 [I-D.ietf-softwire-lw4over6] mechanisms. 144 MAP-E, MAP-T and Lightweight 4over6 are essentially providing the 145 same functionality: IPv4 service to a CE router over an IPv6 only 146 access network. MAP-E and MAP-T may embed parts of the IPv4 address 147 in IPv6 prefixes, thereby supporting many clients with a fixed set of 148 mapping rules and mesh mode (direct CE to CE communication). MAP-E 149 and MAP-T CEs may also be provisioned in hub and spoke mode, and in 150 1:1 mode (no embedded address bits). The difference between MAP-E 151 and MAP-T is that they use different means to connect to the IPv6 152 domain. MAP-E uses RFC2473 [RFC2473] IPv4 over IPv6 tunnelling, 153 while MAP-T uses NAT64 [RFC6145] based translation. Lightweight 154 4over6 is a strict subset of MAP-E in hub and spoke mode with zero 155 embedded address bits. Lightweight 4over6 is restricted to 156 supporting only a full IPv4 address or shared IPv4 address, 157 provisioning an IPv4 prefix is not supported. 159 To support more than one mechanism at a time and to allow for a 160 possibility of transition between them, the Option Request Option 161 DHCPv6 [RFC3315] function is used. Each mechanism has a 162 corresponding container option. A DHCPv6 client can request a 163 particular mechanism by including the option code for a particular 164 container option in its ORO option. The provisioning parameters for 165 that mechanism are expressed by embedding the common format options 166 within the respective container. 168 This approach implies that the all the provisioning options MUST 169 appear only within the container options. The client MUST NOT 170 request any of the provisioning options directly within an ORO. 171 Likewise, the server MUST NOT send the provisioning options directly 172 within DHCPv6 message, without encapsulating them in the 173 corresponding container options. 175 The document is organized with the common sub-options described 176 first, and then the three container options. Some of the sub-options 177 are mandatory in some of the containers and some are optional, or not 178 permitted at all. 180 5. Common Softwire 46 DHCPv6 Options 182 The DHCPv6 protocol is used for Softwire46 CE provisioning following 183 regular DHCPv6 notions, with the CE assuming the role of a DHCPv6 184 client, and the DHCPv6 server providing options following typical 185 DHCPv6 server side policies. The format and usage of the options is 186 defined in the following sub-sections. 188 Each CE needs to be provisioned with enough information to calculate 189 its IPv4 address, IPv4 prefix or shared IPv4 address. MAP-E and 190 MAP-T uses the OPTION_S46_RULE, while for Lightweight 4over6, the 191 OPTION_S46_IPV4ADDRESS option is used. A CE that needs to 192 communicate outside of the A+P domain, also needs the address or 193 prefix of the BR. MAP-E and Lightweight 4over6 use the OPTION_S46_BR 194 option to communicate the IPv6 address of the BR. MAP-T forms an 195 IPv6 destination address by embedding an IPv4 destination address 196 into the BR's IPv6 prefix conveyed via the OPTION_S46_DMR option. 197 Optionally all mechanisms can include the OPTION_S46_PORTPARAMS to 198 specify parameters and port sets for the port range algorithm. 200 5.1. S46 Rule Option 202 Figure 1 shows the format of the S46 Rule option used for conveying 203 the BMR and FMR. 205 A server MAY send more than one S46 Rule Option in a container, if it 206 is configured to do so. Clients MUST NOT send a S46 Rule Option. 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | OPTION_S46_RULE | option-length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | flags | ea-len | prefix4-len | ipv4-prefix | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | (continued) | prefix6-len | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | ipv6-prefix | 218 | (variable length) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | 221 . S46_RULE-options . 222 . . 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 1: S46 Rule Option 227 o option-code: OPTION_S46_RULE (TBD1) 228 o option-length: length of the option, excluding option-code and 229 option-length fields, including length of all encapsulated 230 options, expressed in bytes. 231 o flags: 8 bits long field carrying flags applicable to the rule. 232 The meaning of specific bits is explained in Figure 2. 233 o ea-len: 8 bits long field that specifies the Embedded-Address (EA) 234 bit length. Values allowed range from 0 to 48. 235 o prefix4-len: 8 bits long field expressing the prefix length of the 236 IPv4 prefix specified in the rule-ipv4-prefix field. Valid values 237 0 to 32. 238 o ipv4-prefix: a fixed length 32 bit field that specifies the IPv4 239 prefix for the S46 rule. Zero-padded. 241 o prefix6-len: 8 bits long field expressing the prefix length of the 242 IPv6 prefix specified in the rule-ipv6-prefix field. 243 o ipv6-prefix: a variable length field that specifies the IPv6 244 domain prefix for the S46 rule. The field is padded with follow 245 up zero bits up to the nearest octet boundary when prefix6-len is 246 not divisible by 8. 247 o S46_RULE-options: a variable field that may contain zero or more 248 options that specify additional parameters for this S46 rule, e.g. 249 a Port Parameter Option. 251 The Format of the S46 Rule Flags field is: 253 0 1 2 3 4 5 6 7 254 +-+-+-+-+-+-+-+-+ 255 |Reserved |F| 256 +-+-+-+-+-+-+-+-+ 258 Figure 2: S46 Rule Flags 260 o Reserved: 7-bits reserved for future use as flags. 261 o F-Flag: 1 bit field that specifies whether the rule is to be used 262 for forwarding (FMR). If set, this rule is used as a FMR, if not 263 set this rule is only a BMR. Note: BMR rules can be also FMR 264 rules by setting the F flag. BMR rules are determined by a match 265 of the Rule-IPv6-prefix against the CPE's prefix(es). 267 It is expected that in a typical mesh deployment scenarios, there 268 will be a single BMR, which could also be designated as an FMR using 269 the F-Flag. 271 5.2. S46 BR Option 273 S46 BR Option is used to convey the IPv6 address of the Border Relay. 274 Figure Figure 4 shows the format of the BR option. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | OPTION_S46_BR | option-length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | br-ipv6-address | 282 | | 283 | | 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 3: S46 DMR Option 289 o option-code: OPTION_S46_BR (TBD2) 290 o option-length: 16 291 o br-ipv6-address: a fixed length field of 16 octets that specifies 292 the IPv6 address for the S46 BR. 294 BR redundancy can be implemented by using an anycast address for the 295 BR IPv6 address. Multiple BR options MAY be included in the 296 container; this document does not further explore the use of multiple 297 BR IPv6 addresses. 299 5.3. S46 DMR Option 301 S46 DMR Option is used to convey values for Default Mapping Rule. 302 Figure Figure 4 shows the format of the MAP Rule option used for 303 conveying a DMR. 305 0 1 2 3 306 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | OPTION_S46_DMR | option-length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 |dmr-prefix6-len| dmr-ipv6-prefix | 311 +-+-+-+-+-+-+-+-+ (variable length) | 312 . . 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 4: S46 DMR Option 317 o option-code: OPTION_S46_DMR (TBD3) 318 o option-length: 1 + length of dmr-ipv6-prefix specified in bytes. 319 o dmr-prefix6-len: 8 bits long field expressing the bit mask length 320 of the IPv6 prefix specified in the dmr-ipv6-prefix field. 321 o dmr-ipv6-prefix: a variable length field that specifies the IPv6 322 prefix or address for the S46 BR. This field is padded with 323 follow up zeros to the nearest octet boundary when dmr-prefix6-len 324 is not divisible by 8. 326 5.4. S46 IPv4 Address Option 328 The IPv4 address Option MAY be used to specify the full or shared 329 IPv4 address of the CE. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | OPTION_S46_IPV4ADDRESS | option-length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | ipv4-address | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 . S46_IPV4ADDRESS-options . 340 . . 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 5: S46 IPv4 address Option 345 o option-code: OPTION_S46_IPV4ADDRESS (TBD4) 346 o option-length: 4 347 o ipv4-address: A fixed field of 4 octets specifying an IPv4 348 address. 349 o S46_IPV4ADDRESS-options: a variable field that may contain zero or 350 more options that specify additional parameters e.g. a Port 351 Parameter Option. 353 5.5. S46 Port Parameters Option 355 The Port Parameters Option specifies optional Rule Port Parameters 356 that MAY be provided as part of the Mapping Rule for CEs using the 357 MAP algorithm. 359 See [I-D.ietf-softwire-map], Section 5.1 for detailed description of 360 MAP algorithm that explains meaning of all parameters. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | OPTION_S46_PORTPARAMS | option-length | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | offset | PSID-len | PSID | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Figure 6: S46 Port Parameters Option 372 o option-code: OPTION_S46_PORTPARAMS (TBD5) 373 o option-length: 4 374 o offset: (PSID offset) 8 bits long field that specifies the numeric 375 value for the S46 algorithm's excluded port range/offset bits 376 (A-bits), as per section 5.1.1 in [I-D.ietf-softwire-map]. 377 Allowed values are between 0 and 16, with the default value being 378 6. 379 o PSID-len: Bit length value of the number of significant bits in 380 the PSID field. (also known as 'k'). When set to 0, the PSID 381 field is to be ignored. After the first 'a' bits, there are k 382 bits in the port number representing valid of PSID. Subsequently, 383 the address sharing ratio would be 2^k. 384 o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value 385 algorithmically identifies a set of ports assigned to a CE. The 386 first k-bits on the left of this 2-octets field is the PSID value. 387 The remaining (16-k) bits on the right are padding zeros. 389 When receiving the Port Parameters option with an explicit PSID, the 390 client MUST use this explicit PSID in configuring its MAP interface. 391 If the conveyed IPv4 address is not 32 bit-long. The formula for 392 this check is "prefix4-len + ea-len = 32" and serves to ensure that 393 the explicit PSID is only applied to configurations with a completely 394 formed IPv4 address. 396 The OPTION_S46_PORTPARAMS option MUST be encapsulated in a 397 OPTION_S46_RULE option or an OPTION_S46_IPV4ADDRESS option. It MUST 398 NOT appear directly within a container option. 400 6. Softwire 46 Container DHCPv6 Options 402 +------------------------+-------+-------+--------------------+ 403 | Option | MAP-E | MAP-T | Lightweight 4over6 | 404 +------------------------+-------+-------+--------------------+ 405 | OPTION_S46_RULE | M | M | - | 406 | OPTION_S46_BR | M | - | M | 407 | OPTION_S46_PORTPARAMS | O | O | O | 408 | OPTION_S46_DMR | - | M | - | 409 | OPTION_S46_IPV4ADDRESS | - | - | M | 410 +------------------------+-------+-------+--------------------+ 412 M - Mandatory, O - Optional, - - Not Applicable 414 Table 1: Option to Container Mappings 416 6.1. Softwire46 MAP-E Container Option 418 This MAP-E Container Option specifies the container used to group all 419 rules and optional port parameters for a specified domain. 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | OPTION_S46_CONT_MAPE | option-length | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 . encapsulated-options (variable length) . 428 . . 429 +---------------------------------------------------------------+ 431 Figure 7: MAP-E Container Option 433 o option-code: OPTION_S46_CONT_MAPE (TBD6) 434 o option-length: Length of encapsulated options 435 o encapsulated-options: options associated with this Softwire46 436 MAP-E domain. 438 The encapsulated options field encapsulates those options that are 439 specific to this MAP Option. Currently there are two options 440 specified for the OPTION_S46_CONT_MAPE option, OPTION_S46_RULE and 441 OPTION_S46_BR. There MUST be at least one OPTION_S46_RULE option and 442 at least one OPTION_S46_BR. 444 Other options suitable for a domain may be defined in the future. A 445 DHCP message MAY include multiple S46 MAPE Container Options 446 (representing multiple domains). 448 6.2. Softwire46 MAP-T Container Option 450 This MAP-T Container Option specifies the container used to group all 451 rules and optional port parameters for a specified domain. 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | OPTION_S46_CONT_MAPT | option-length | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | | 459 . encapsulated-options (variable length) . 460 . . 461 +---------------------------------------------------------------+ 463 Figure 8: MAP-E Container Option 465 o option-code: OPTION_S46_CONT_MAPT (TBD7) 466 o option-length: Length of encapsulated options 467 o encapsulated-options: options associated with this Softwire46 468 MAP-T domain. 470 The encapsulated options field encapsulates those options that are 471 specific to this MAP Option. Currently there are two options 472 specified for the OPTION_S46_CONT_MAPT option, OPTION_S46_RULE and 473 OPTION_S46_DMR options. There MUST be at least one OPTION_S46_RULE 474 option and exactly one OPTION_S46_DMR. 476 6.3. Softwire46 LightWeight 46 Container Option 478 This LW46 Container Option specifies the container used to group all 479 rules and optional port parameters for a specified domain. 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | OPTION_S46_CONT_LW | option-length | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 + encapsulated-options (variable length) . 488 . . 489 +---------------------------------------------------------------+ 491 Figure 9: LW46 Container Option 493 o option-code: OPTION_S46_CONT_LW (TBD8) 494 o option-length: Length of encapsulated options 495 o encapsulated-options: options associated with this Softwire46 496 domain. 498 The encapsulated options field encapsulates those options that are 499 specific to this Lightweight 4over6 Option. Currently there are two 500 options specified for the OPTION_S46_CONT_LW option, 501 OPTION_S46_IPV4ADDRESS and OPTION_S46_BR. There MUST be exactly one 502 OPTION_S46_IPV4ADDRESS option and at least one OPTION_S46_BR. 504 7. DHCPv6 Server Behavior 506 RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and 507 server negotiate configuration values using the ORO. As a 508 convenience to the reader, we mention here that a server will by 509 default not reply with a Softwire 46 Container Option if the client 510 has not explicitly enumerated it in its Option Request Option. 512 A CE router may support several or all of the mechanisms mentioned 513 here. In the case where a client requests multiple mechanisms in its 514 ORO option, the server SHOULD reply with all the corresponding 515 Softwire 46 Container options, enumerated in the Option Request 516 Option, it is configured for. 518 8. DHCPv6 Client Behavior 520 A S46 CE acting as DHCPv6 client will request S46 configuration to be 521 assigned by the DHCPv6 server located in the IPv6 network. Such a 522 client SHOULD include the S46 Container option(s) that it is 523 interested in, in its ORO in SOLICIT, REQUEST, RENEW, REBIND and 524 INFORMATION-REQUEST messages. 526 When processing received S46 container options the following 527 behaviour is expected: 529 o A client MUST support processing multiple received OPTION_S46_RULE 530 options in a container OPTION_S46_CONT_MAPE or 531 OPTION_S46_CONT_MAPT option 532 o A client receiving an unsupported S46 option, or an invalid 533 parameter value SHOULD discard that S46 Container option and log 534 the event. 536 The behavior of a client supporting multiple Softwire 46 mechanisms, 537 is out of scope of this document. See: [I-D.ietf-softwire-unified- 538 cpe] for how to prioritise and handle multiple simulatanous 539 mechanisms in use. 541 DISCUSS: There are many ways of delivering IPv4 to a CE router. 542 Native IPv4 with global addressing, native IPv4 with private 543 addressing, DS-lite, 464XLAT, 4rd, MAP-E, MAP-T, Lightweight 4over6. 544 Should a CPE prefer a single option (per interface), should it 545 configure multiple, and handle a smooth transition between them? 546 [I-D.townsley-troan-ipv6-ce-transitioning] proposes one of the 547 approaches to handle this scenario by having an implicit order. 548 Other approaches are possible and should be discussed, however, this 549 is out of scope for this particular document. 551 Note that system implementing CE functionality may have multiple 552 network interfaces, and these interfaces may be configured 553 differently; some may be connected to networks that call for MAP, and 554 some may be connected to networks that are using normal dual stack or 555 other means. The CE system should approach this specification on an 556 interface-by-interface basis. For example, if the CE system is MAP 557 capable and is attached to multiple networks that provide the MAP 558 Mapping Rule Option, then the CE system MUST configure a MAP service 559 (i.e. a translation or encapsulation) for each interface separately 560 as each MAP provides IPv4 connectivity for each distinct interface. 561 Means to bind a MAP configuration to a given interface in a multiple 562 interfaces device are out of scope of this document. 564 9. Security Considerations 566 Implementation of this document does not present any new security 567 issues, but as with all DHCPv6-derived configuration state, it is 568 completely possible that the configuration is being delivered by a 569 third party (Man In The Middle). As such, there is no basis to trust 570 that the access over the MAP can be trusted, and it should not 571 therefore bypass any security mechanisms such as IP firewalls. 573 Readers concerned with security of MAP provisioning over DHCPv6 are 574 encouraged to read [I-D.ietf-dhc-secure-dhcpv6]. 576 Section XX of [I-D.ietf-softwire-map] discusses security issues of 577 the MAP mechanism. 579 Section 23 of [RFC3315] discusses DHCPv6-related security issues. 581 10. IANA Considerations 583 IANA is kindly requested to allocate the following DHCPv6 option 584 codes: TBD1 for OPTION_S46_RULE, TBD2 for OPTION_S4_BR, TBD3 for 585 OPTION_S46_DMR, TBD4 for OPTION_S46_IPV4ADDRESS, TBD5 for 586 OPTION_S46_PORTPARAMS, and TBD6 for OPTION_S46_CONT_MAPE, TBD7 for 587 OPTION_S46_CONT_MAPT and TBD8 for OPTION_S46_CONT_LW All values 588 should be added to the DHCPv6 option code space defined in Section 589 24.3 of [RFC3315]. 591 11. Acknowledgements 592 This document was created as a product of a MAP design team. 593 Following people were members of that team: Congxiao Bao, Mohamed 594 Boucadair, Gang Chen, Maoke Chen, Wojciech Dec, Xiaohong Deng, Jouni 595 Korhonen, Xing Li, Satoru Matsushima, Tomasz Mrugalski, Tetsuya 596 Murakami, Jacni Qin, Necj Scoberne, Qiong Sun, Tina Tsou, Dan Wing, 597 Leaf Yeh and Jan Zorz. 599 Former MAP design team members are: Remi Despres. 601 Authors would like to thank Bernie Volz for his insightful comments 602 and suggestions. 604 12. References 606 12.1. Normative References 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, March 1997. 611 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 612 and M. Carney, "Dynamic Host Configuration Protocol for 613 IPv6 (DHCPv6)", RFC 3315, July 2003. 615 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 616 Host Configuration Protocol (DHCP) version 6", RFC 3633, 617 December 2003. 619 12.2. Informative References 621 [I-D.ietf-dhc-option-guidelines] 622 Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 623 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 624 draft-ietf-dhc-option-guidelines-13 (work in progress), 625 July 2013. 627 [I-D.ietf-dhc-secure-dhcpv6] 628 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", draft- 629 ietf-dhc-secure-dhcpv6-07 (work in progress), September 630 2012. 632 [I-D.ietf-homenet-arch] 633 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 634 "Home Networking Architecture for IPv6", draft-ietf- 635 homenet-arch-06 (work in progress), October 2012. 637 [I-D.ietf-softwire-lw4over6] 638 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 639 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 640 Architecture", draft-ietf-softwire-lw4over6-01 (work in 641 progress), July 2013. 643 [I-D.ietf-softwire-map-t] 644 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 645 T. Murakami, "Mapping of Address and Port using 646 Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work 647 in progress), September 2013. 649 [I-D.ietf-softwire-map] 650 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 651 Murakami, T., and T. Taylor, "Mapping of Address and Port 652 with Encapsulation (MAP)", draft-ietf-softwire-map-07 653 (work in progress), May 2013. 655 [I-D.ietf-softwire-unified-cpe] 656 Boucadair, M., Farrer, I., Perreault, S., and S. 657 Sivakumar, "Unified IPv4-in-IPv6 Softwire CPE", draft- 658 ietf-softwire-unified-cpe-01 (work in progress), May 2013. 660 [I-D.mdt-softwire-map-deployment] 661 Sun, Q., Chen, M., Chen, G., Sun, C., Tsou, T., and S. 662 Perreault, "Mapping of Address and Port (MAP) - Deployment 663 Considerations", draft-mdt-softwire-map-deployment-02 664 (work in progress), June 2012. 666 [I-D.townsley-troan-ipv6-ce-transitioning] 667 Townsley, M. and O. Troan, "Basic Requirements for 668 Customer Edge Routers - multihoming and transition", 669 draft-townsley-troan-ipv6-ce-transitioning-02 (work in 670 progress), December 2011. 672 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 673 IPv6 Specification", RFC 2473, December 1998. 675 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 676 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 677 May 2008. 679 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 680 Algorithm", RFC 6145, April 2011. 682 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 683 Cheshire, "Internet Assigned Numbers Authority (IANA) 684 Procedures for the Management of the Service Name and 685 Transport Protocol Port Number Registry", BCP 165, RFC 686 6335, August 2011. 688 Authors' Addresses 689 Tomasz Mrugalski 690 Internet Systems Consortium, Inc. 691 950 Charter Street 692 Redwood City, CA 94063 693 USA 695 Phone: +1 650 423 1345 696 Email: tomasz.mrugalski@gmail.com 697 URI: http://www.isc.org/ 699 Ole Troan (editor) 700 Cisco Systems 701 Philip Pedersens vei 1 702 Lysaker 1366 703 Norway 705 Email: ot@cisco.com 707 Wojciech Dec 708 Cisco Systems, Inc. 709 The Netherlands 711 Email: wdec@cisco.com 712 URI: http://cisco.com 714 Congxiao Bao 715 CERNET Center/Tsinghua University 716 Room 225, Main Building, Tsinghua University 717 Beijing 100084 718 CN 720 Phone: +86 10-62785983 721 Email: congxiao@cernet.edu.cn 723 Leaf Y. Yeh 724 Freelancer Technologies 725 Shenzhen, Guangdong 726 P. R. China 728 Email: leaf.yeh.sdo@gmail.com 730 Xiaohong Deng 731 6 Cordelia St. 732 South Brisbane QLD 4101 733 Australia 735 Phone: +61 3858 3128 736 Email: dxhbupt@gmail.com