idnits 2.17.1 draft-ietf-softwire-map-dhcp-07.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 (March 13, 2014) is 3695 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == 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 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 5 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: September 14, 2014 Cisco 6 I. Farrer 7 Deutsche Telekom AG 8 S. Perreault 9 Viagenie 10 W. Dec 11 Cisco 12 C. Bao 13 Tsinghua University 14 L. Yeh 15 CNNIC 16 X. Deng 17 Yingke Law Firm 18 March 13, 2014 20 DHCPv6 Options for configuration of Softwire Address and Port Mapped 21 Clients 22 draft-ietf-softwire-map-dhcp-07 24 Abstract 26 This document specifies DHCPv6 options, termed Softwire46 options, 27 for the provisioning of Softwire46 Customer Edge (CE) devices. 28 Softwire46 is a collective term used to refer to architectures based 29 on the notion of IPv4 Address+Port (A+P) for providing IPv4 30 connectivity across an IPv6 network. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 14, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Softwire 46 Overview . . . . . . . . . . . . . . . . . . . . 3 69 4. Common Softwire46 DHCPv6 Options . . . . . . . . . . . . . . 4 70 4.1. S46 Rule Option . . . . . . . . . . . . . . . . . . . . . 5 71 4.2. S46 BR Option . . . . . . . . . . . . . . . . . . . . . . 6 72 4.3. S46 DMR Option . . . . . . . . . . . . . . . . . . . . . 7 73 4.4. S46 IPv4/IPv6 Address Binding Option . . . . . . . . . . 7 74 4.5. S46 Port Parameters Option . . . . . . . . . . . . . . . 8 75 5. Softwire 46 Container DHCPv6 Options . . . . . . . . . . . . 9 76 5.1. Softwire46 MAP-E Container Option . . . . . . . . . . . . 9 77 5.2. Softwire46 MAP-T Container Option . . . . . . . . . . . . 10 78 5.3. Softwire46 LightWeight 46 Container Option . . . . . . . 11 79 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 11 80 7. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 12 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 11.2. Informative References . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 A number of architectural solution proposals discussed in the IETF 92 Softwire Working Group use Address and Port (A+P) as their technology 93 base for providing IPv4 connectivity to end users using CE devices 94 across a service provider's IPv6 network, while allowing for shared 95 or dedicated IPv4 addressing of the CEs. 97 An example is Mapping of Address and Port (MAP) defined in 98 [I-D.ietf-softwire-map]. The MAP solution consists of one or more 99 MAP Border Relay (BR) routers, responsible for stateless forwarding 100 between a MAP IPv6 domain and an IPv4 network, and one or more MAP 101 Customer Edge (CE) routers, responsible for forwarding between a 102 user's private IPv4 network and the MAP IPv6 network domain. 103 Collectively, the MAP CE and BR form a domain when configured with 104 common service parameters. This characteristic is common to all of 105 the Softwire46 proposals. 107 To function in such a domain, a CE needs to be provisioned with the 108 appropriate A+P service parameters for that domain. These consist 109 primarily of the CE's IPv4 address and transport layer port-range(s). 110 Furthermore, the IPv6 transport mode (i.e. encapsulation or 111 translation) needs to be specified. Provisioning of other IPv4 112 configuration information not derived directly from the A+P service 113 parameters is not covered in this document. It is expected that 114 provisioning of other IPv4 configuration will continue to use DHCPv4 115 [RFC2131]. 117 This memo specifies a set of DHCPv6 [RFC3315] options to provision 118 Softwire46 information to CE routers. Although the focus is to 119 deliver IPv4 service to an end-user network (such as a residential 120 home network), it can equally be applied to an individual host acting 121 as a CE. Configuration of the BR is out of scope of this document. 123 2. Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 3. Softwire 46 Overview 131 This document describes a set of common DHCPv6 options for 132 configuring the MAP-E [I-D.ietf-softwire-map], MAP-T 133 [I-D.ietf-softwire-map-t] and Lightweight 4over6 134 [I-D.ietf-softwire-lw4over6] mechanisms. 136 MAP-E, MAP-T and Lightweight 4over6 are essentially providing the 137 same functionality: IPv4 service to a CE router over an IPv6 only 138 access network. MAP-E and MAP-T may embed parts of the IPv4 address 139 in IPv6 prefixes, thereby supporting many clients with a fixed set of 140 mapping rules and mesh mode (direct CE to CE communication). MAP-E 141 and MAP-T CEs may also be provisioned in hub and spoke mode, and in 142 1:1 mode (with no embedded address bits). The difference between 143 MAP-E and MAP-T is that they use different means to connect to the 144 IPv6 domain. MAP-E uses RFC2473 [RFC2473] IPv4 over IPv6 tunnelling, 145 while MAP-T uses NAT64 [RFC6145] based translation. Lightweight 146 4over6 is a hub and spoke IPv4 over IPv6 tunneling mechanism, with 147 complete independence of IPv4 and IPv6 addressing (zero embedded 148 address bits). 150 The DHCP options described here tie the provisioning parameters, and 151 hence the IPv4 service itself, to the End-user IPv6 prefix lifetime. 152 The validity of a softwire's IPv4 address, prefix or shared IPv4 153 address, port set and any authorization and accounting are tied to 154 the lifetime of its associated End-user IPv6 prefix. 156 To support more than one mechanism at a time and to allow for a 157 possibility of transition between them, the Option Request Option 158 DHCPv6 [RFC3315] function is used. Each mechanism has a 159 corresponding DHCPv6 container option. A DHCPv6 client can request a 160 particular mechanism by including the option code for a particular 161 container option in its ORO option. The provisioning parameters for 162 that mechanism are expressed by embedding the common format options 163 within the respective container. 165 This approach implies that all of the provisioning options MUST 166 appear only within the container options. The client MUST NOT 167 request any of the provisioning options directly within an ORO. 168 Likewise, the server MUST NOT send the provisioning options directly 169 within a DHCPv6 message, without encapsulation in the corresponding 170 container option. 172 The document is organized with the common sub-options described 173 first, followed by the three container options. Some sub-options are 174 mandatory in some containers, some are optional and some are not 175 permitted at all. 177 4. Common Softwire46 DHCPv6 Options 179 The DHCPv6 protocol is used for Softwire46 CE provisioning following 180 regular DHCPv6 notions, with the CE assuming the role of a DHCPv6 181 client, and the DHCPv6 server providing options following typical 182 DHCPv6 server side policies. The format and usage of the options are 183 defined in the following sub-sections. 185 Each CE needs to be provisioned with enough information to calculate 186 its IPv4 address, IPv4 prefix or shared IPv4 address. MAP-E and 187 MAP-T use the OPTION_S46_RULE, while Lightweight 4over6 uses the 188 OPTION_S46_V4V6BIND option. A CE that needs to communicate outside 189 of the A+P domain also needs the address or prefix of the BR. MAP-E 190 and Lightweight 4over6 use the OPTION_S46_BR option to communicate 191 the IPv6 address of the BR. MAP-T forms an IPv6 destination address 192 by embedding an IPv4 destination address into the BR's IPv6 prefix 193 conveyed via the OPTION_S46_DMR option. Optionally, all mechanisms 194 can include OPTION_S46_PORTPARAMS to specify parameters and port sets 195 for the port range algorithm. 197 4.1. S46 Rule Option 199 Figure 1 shows the format of the S46 Rule option used for conveying 200 the Basic Mapping Rule (BMR) and Forwarding Mapping Rule (FMR). 202 A server MAY send more than one S46 Rule Option in a container, if it 203 is configured to do so. Clients MUST NOT send a S46 Rule Option. 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | OPTION_S46_RULE | option-length | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | flags | ea-len | prefix4-len | ipv4-prefix | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | (continued) | prefix6-len | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | ipv6-prefix | 215 | (variable length) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | | 218 . S46_RULE-options . 219 . . 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 1: S46 Rule Option 224 o option-code: OPTION_S46_RULE (TBD1) 225 o option-length: length of the option, excluding option-code and 226 option-length fields, including length of all encapsulated 227 options, expressed in bytes. 228 o flags: 8 bits long field carrying flags applicable to the rule. 229 The meaning of specific bits are explained in Figure 2. 230 o ea-len: 8 bits long field that specifies the Embedded-Address (EA) 231 bit length. Allowed values range from 0 to 48. 232 o prefix4-len: 8 bits long field expressing the prefix length of the 233 IPv4 prefix specified in the rule-ipv4-prefix field. Valid values 234 0 to 32. 235 o ipv4-prefix: a fixed length 32 bit field that specifies the IPv4 236 prefix for the S46 rule. The bits in the prefix after prefix4-len 237 number of bits are reserved and MUST be initialized to zero by the 238 sender and ignored by the receiver. 239 o prefix6-len: 8 bits long field expressing the length of the IPv6 240 prefix specified in the rule-ipv6-prefix field. 242 o ipv6-prefix: a variable length field that specifies the IPv6 243 domain prefix for the S46 rule. The field is padded with follow 244 up zero bits up to the nearest octet boundary when prefix6-len is 245 not divisible by 8. 246 o S46_RULE-options: a variable field that may contain zero or more 247 options that specify additional parameters for this S46 rule, e.g. 248 a Port Parameter Option. 250 The Format of the S46 Rule Flags field is: 252 0 1 2 3 4 5 6 7 253 +-+-+-+-+-+-+-+-+ 254 |Reserved |F| 255 +-+-+-+-+-+-+-+-+ 257 Figure 2: S46 Rule Flags 259 o Reserved: 7-bits reserved for future use as flags. 260 o F-Flag: 1 bit field that specifies whether the rule is to be used 261 for forwarding (FMR). If set, this rule is used as a FMR, if not 262 set this rule is a BMR. Note: A BMR rule can also be an FMR rule 263 by setting the F flag. The BMR rule is determined by a match of 264 the Rule-IPv6-prefix against the CPE's prefix(es). 266 It is expected that in a typical mesh deployment scenario, there will 267 be a single BMR, which could also be designated as an FMR using the 268 F-Flag. 270 4.2. S46 BR Option 272 The S46 BR Option is used to convey the IPv6 address of the Border 273 Relay. Figure 4 shows the format of the BR option. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | OPTION_S46_BR | option-length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | br-ipv6-address | 281 | | 282 | | 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 3: S46 DMR Option 288 o option-code: OPTION_S46_BR (TBD2) 289 o option-length: 16 290 o br-ipv6-address: a fixed length field of 16 octets that specifies 291 the IPv6 address for the S46 BR. 293 BR redundancy can be implemented by using an anycast address for the 294 BR IPv6 address. Multiple BR options MAY be included in the 295 container; this document does not further explore the use of multiple 296 BR IPv6 addresses. 298 4.3. S46 DMR Option 300 The S46 DMR Option is used to convey values for the Default Mapping 301 Rule (DMR). Figure 4 shows the format of the MAP Rule option used 302 for conveying a DMR. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | OPTION_S46_DMR | option-length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |dmr-prefix6-len| dmr-ipv6-prefix | 310 +-+-+-+-+-+-+-+-+ (variable length) | 311 . . 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Figure 4: S46 DMR Option 316 o option-code: OPTION_S46_DMR (TBD3) 317 o option-length: 1 + length of dmr-ipv6-prefix specified in bytes. 318 o dmr-prefix6-len: 8 bits long field expressing the bit mask length 319 of the IPv6 prefix specified in the dmr-ipv6-prefix field. 320 o dmr-ipv6-prefix: a variable length field specifying the IPv6 321 prefix or address for the S46 BR. This field is right padded with 322 zeros to the nearest octet boundary when dmr-prefix6-len is not 323 divisible by 8. 325 4.4. S46 IPv4/IPv6 Address Binding Option 327 The IPv4 address Option MAY be used to specify the full or shared 328 IPv4 address of the CE. The IPv6 prefix field is used by the CE to 329 identify the correct prefix to use for the tunnel source. 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_V4V6BIND | option-length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | ipv4-address | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 |bindprefix6-len| bind-ipv6-prefix | 339 +-+-+-+-+-+-+-+-+ (variable length) | 340 . . 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | | 343 . S46_V4V6BIND-options . 344 . . 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 5: S46 IPv4/IPv6 Address Binding Option 349 o option-code: OPTION_S46_V4V6BIND (TBD4) 350 o option-length: 4 351 o ipv4-address: A fixed field of 4 octets specifying an IPv4 352 address. 353 o bindprefix6-len: 8 bits long field expressing the bit mask length 354 of the IPv6 prefix specified in the bind-ipv6-prefix field. 355 o bind-ipv6-prefix: a variable length field specifying the IPv6 356 prefix or address for the S46. This field is right padded with 357 zeros to the nearest octet boundary when bindprefix6-len is not 358 divisible by 8. 359 o S46_V4V6BIND-options: a variable field that may contain zero or 360 more options that specify additional parameters e.g. a Port 361 Parameters Option. 363 4.5. S46 Port Parameters Option 365 The Port Parameters Option specifies optional Rule Port Parameters 366 that MAY be provided as part of the Mapping Rule for CEs using the 367 MAP algorithm. 369 See [I-D.ietf-softwire-map], Section 5.1 for a description of MAP 370 algorithm, explaining all of the parameters in detail. 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | OPTION_S46_PORTPARAMS | option-length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | offset | PSID-len | PSID | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 6: S46 Port Parameters Option 382 o option-code: OPTION_S46_PORTPARAMS (TBD5) 383 o option-length: 4 384 o offset: (PSID offset) 8 bits long field that specifies the numeric 385 value for the S46 algorithm's excluded port range/offset bits 386 (A-bits), as per section 5.1.1 of [I-D.ietf-softwire-map]. 387 Allowed values are between 0 and 15, with the default value being 388 6. 389 o PSID-len: Bit length value of the number of significant bits in 390 the PSID field. (also known as 'k'). When set to 0, the PSID 391 field is to be ignored. After the first 'a' bits, there are k 392 bits in the port number representing the value of the Port Set 393 Identifier (PSID). Consequently, the address sharing ratio would 394 be 2^k. 395 o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value 396 algorithmically identifies a set of ports assigned to a CE. The 397 first k bits on the left of this field contain the PSID value. 398 The remaining (16-k) bits on the right are padding zeros. 400 When receiving the Port Parameters option with an explicit PSID, the 401 client MUST use this explicit PSID in configuring its MAP interface. 402 If the conveyed IPv4 address is not 32 bit-long, the option MUST be 403 discarded. The formula for this check is "prefix4-len + ea-len = 32" 404 and serves to ensure that the explicit PSID is only applied to 405 configurations with a completely formed IPv4 address. 407 The OPTION_S46_PORTPARAMS option MUST be encapsulated in a 408 OPTION_S46_RULE option or an OPTION_S46_V4V6BIND option. It MUST NOT 409 appear directly within a container option. 411 5. Softwire 46 Container DHCPv6 Options 413 +-----------------------+-------+-------+--------------------+ 414 | Option | MAP-E | MAP-T | Lightweight 4over6 | 415 +-----------------------+-------+-------+--------------------+ 416 | OPTION_S46_RULE | M | M | N/A | 417 | OPTION_S46_BR | M | N/A | M | 418 | OPTION_S46_PORTPARAMS | O | O | O | 419 | OPTION_S46_DMR | N/A | M | N/A | 420 | OPTION_S46_V4V6BIND | N/A | N/A | O | 421 +-----------------------+-------+-------+--------------------+ 423 M - Mandatory, O - Optional, N/A - Not Applicable 425 Table 1: Option to Container Mappings 427 5.1. Softwire46 MAP-E Container Option 429 The MAP-E Container Option specifies the container used to group all 430 rules and optional port parameters for a specified domain. 432 0 1 2 3 433 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | OPTION_S46_CONT_MAPE | option-length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | 439 . encapsulated-options (variable length) . 440 . . 441 +---------------------------------------------------------------+ 443 Figure 7: MAP-E Container Option 445 o option-code: OPTION_S46_CONT_MAPE (TBD6) 446 o option-length: Length of encapsulated options 447 o encapsulated-options: options associated with this Softwire46 448 MAP-E domain. 450 The encapsulated options field conveys options specific to this MAP 451 Option. Currently there are two options specified for the 452 OPTION_S46_CONT_MAPE option, OPTION_S46_RULE and OPTION_S46_BR. 453 There MUST be at least one OPTION_S46_RULE option and at least one 454 OPTION_S46_BR. 456 Other options applicable to a domain may be defined in the future. A 457 DHCP message MAY include multiple S46 MAPE Container Options 458 (representing multiple domains). 460 5.2. Softwire46 MAP-T Container Option 462 The MAP-T Container Option specifies the container used to group all 463 rules and optional port parameters for a specified domain. 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | OPTION_S46_CONT_MAPT | option-length | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | | 471 . encapsulated-options (variable length) . 472 . . 473 +---------------------------------------------------------------+ 475 Figure 8: MAP-E Container Option 477 o option-code: OPTION_S46_CONT_MAPT (TBD7) 478 o option-length: Length of encapsulated options 479 o encapsulated-options: options associated with this Softwire46 480 MAP-T domain. 482 The encapsulated options field conveys options specific to this MAP 483 Option. Currently there are two options specified for the 484 OPTION_S46_CONT_MAPT option, OPTION_S46_RULE and OPTION_S46_DMR 485 options. There MUST be at least one OPTION_S46_RULE option and 486 exactly one OPTION_S46_DMR. 488 5.3. Softwire46 LightWeight 46 Container Option 490 The LW46 Container Option specifies the container used to group all 491 rules and optional port parameters for a specified domain. 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | OPTION_S46_CONT_LW | option-length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | | 499 + encapsulated-options (variable length) . 500 . . 501 +---------------------------------------------------------------+ 503 Figure 9: LW46 Container Option 505 o option-code: OPTION_S46_CONT_LW (TBD8) 506 o option-length: Length of encapsulated options 507 o encapsulated-options: options associated with this Softwire46 508 domain. 510 The encapsulated options field conveys options specific to this 511 Lightweight 4over6 Option. Currently there are two options specified 512 for the OPTION_S46_CONT_LW option, OPTION_S46_V4V6BIND and 513 OPTION_S46_BR. There MUST be at most one OPTION_S46_V4V6BIND option 514 and at least one OPTION_S46_BR option. 516 6. DHCPv6 Server Behavior 518 [RFC3315] Section 17.2.2 describes how a DHCPv6 client and server 519 negotiate configuration values using the ORO. As a convenience to 520 the reader, we mention here that by default, a server will not reply 521 with a Softwire 46 Container Option if the client has not explicitly 522 enumerated one in its Option Request Option. 524 A CE router may support several (or all) of the mechanisms mentioned 525 here. In the case where a client requests multiple mechanisms in its 526 ORO option, the server SHOULD reply with all the corresponding 527 Softwire 46 Container options, enumerated in the Option Request 528 Option, the the server is configured for. 530 7. DHCPv6 Client Behavior 532 An S46 CE acting as DHCPv6 client will request S46 configuration 533 parameters from the DHCPv6 server located in the IPv6 network. Such 534 a client SHOULD include the S46 Container option(s) that it is 535 configured for in its ORO in SOLICIT, REQUEST, RENEW, REBIND and 536 INFORMATION-REQUEST messages. 538 When processing received S46 container options the following 539 behaviour is expected: 541 o A client MUST support processing multiple received OPTION_S46_RULE 542 options in a container OPTION_S46_CONT_MAPE or 543 OPTION_S46_CONT_MAPT option 544 o A client receiving an unsupported S46 option, or an invalid 545 parameter value SHOULD discard that S46 Container option and log 546 the event. 548 The behavior of a client supporting multiple Softwire 46 mechanisms, 549 is out of scope of this document. [I-D.ietf-softwire-unified-cpe] 550 describes client behaviour for the prioritization and handling of 551 multiple mechanisms simultaneously. 553 Note that system implementing CE functionality may have multiple 554 network interfaces, and these interfaces may be configured 555 differently; some may be connected to networks that call for MAP, and 556 some may be connected to networks that are using normal dual stack or 557 other means. The CE system should approach this specification on an 558 interface-by-interface basis. For example, if the CE system is MAP 559 capable and is attached to multiple networks that provide the MAP 560 Mapping Rule Option, then the CE system MUST configure a MAP service 561 (i.e. a translation or encapsulation) for each interface separately 562 as each MAP provides IPv4 connectivity for each distinct interface. 563 The means to bind a MAP configuration to a given interface in a 564 multiple interfaces device are out of scope of this document. 566 8. Security Considerations 568 Implementation of this document does not present any new security 569 issues, but as with all DHCPv6-derived configuration state, it is 570 possible that configuration is actually being delivered by a third 571 party (Man In The Middle). As such, there is no basis on which 572 access over MAP or lw4o6 can be trusted. Therefore, softwires should 573 not bypass any security mechanisms such as IP firewalls. 575 Readers concerned with security of MAP provisioning over DHCPv6 are 576 encouraged to read [I-D.ietf-dhc-secure-dhcpv6]. 578 Section 11 of [I-D.ietf-softwire-map] discusses security issues of 579 the MAP mechanism. 581 Section 23 of [RFC3315] discusses DHCPv6-related security issues. 583 9. IANA Considerations 585 IANA is kindly requested to allocate the following DHCPv6 option 586 codes: 588 TBD1 for OPTION_S46_RULE 589 TBD2 for OPTION_S4_BR 590 TBD3 for OPTION_S46_DMR 591 TBD4 for OPTION_S46_V4V6BIND 592 TBD5 for OPTION_S46_PORTPARAMS 593 TBD6 for OPTION_S46_CONT_MAPE 594 TBD7 for OPTION_S46_CONT_MAPT 595 TBD8 for OPTION_S46_CONT_LW 597 All values should be added to the DHCPv6 option code space defined in 598 Section 24.3 of [RFC3315]. 600 10. Acknowledgements 602 This document was created as a product of a MAP design team. 603 Following people were members of that team: Congxiao Bao, Mohamed 604 Boucadair, Gang Chen, Maoke Chen, Wojciech Dec, Xiaohong Deng, Jouni 605 Korhonen, Xing Li, Satoru Matsushima, Tomasz Mrugalski, Tetsuya 606 Murakami, Jacni Qin, Necj Scoberne, Qiong Sun, Tina Tsou, Dan Wing, 607 Leaf Yeh and Jan Zorz. 609 The authors would like to thank Bernie Volz and Tom Taylor for their 610 insightful comments and suggestions. 612 11. References 614 11.1. Normative References 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, March 1997. 619 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 620 and M. Carney, "Dynamic Host Configuration Protocol for 621 IPv6 (DHCPv6)", RFC 3315, July 2003. 623 11.2. Informative References 625 [I-D.ietf-dhc-secure-dhcpv6] 626 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", draft- 627 ietf-dhc-secure-dhcpv6-07 (work in progress), September 628 2012. 630 [I-D.ietf-softwire-lw4over6] 631 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 632 I. Farrer, "Lightweight 4over6: An Extension to the DS- 633 Lite Architecture", draft-ietf-softwire-lw4over6-03 (work 634 in progress), November 2013. 636 [I-D.ietf-softwire-map-t] 637 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 638 T. Murakami, "Mapping of Address and Port using 639 Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work 640 in progress), September 2013. 642 [I-D.ietf-softwire-map] 643 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 644 Murakami, T., and T. Taylor, "Mapping of Address and Port 645 with Encapsulation (MAP)", draft-ietf-softwire-map-08 646 (work in progress), August 2013. 648 [I-D.ietf-softwire-unified-cpe] 649 Boucadair, M., Farrer, I., Perreault, S., and S. 650 Sivakumar, "Unified IPv4-in-IPv6 Softwire CPE", draft- 651 ietf-softwire-unified-cpe-01 (work in progress), May 2013. 653 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 654 2131, March 1997. 656 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 657 IPv6 Specification", RFC 2473, December 1998. 659 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 660 Algorithm", RFC 6145, April 2011. 662 Authors' Addresses 664 Tomasz Mrugalski 665 Internet Systems Consortium, Inc. 666 950 Charter Street 667 Redwood City, CA 94063 668 USA 670 Phone: +1 650 423 1345 671 Email: tomasz.mrugalski@gmail.com 672 URI: http://www.isc.org/ 673 Ole Troan 674 Cisco Systems, Inc. 675 Philip Pedersens vei 1 676 Lysaker 1366 677 Norway 679 Email: ot@cisco.com 681 Ian Farrer 682 Deutsche Telekom AG 683 CTO-ATI, Landgrabenweg 151 684 Bonn, NRW 53227 685 Germany 687 Email: ian.farrer@telekom.de 689 Simon Perreault 690 Viagenie 691 246 Aberdeen 692 Quebec, QC G1R 2E1 693 Canada 695 Phone: +1 418 656 9254 696 Email: simon.perreault@viagenie.ca 698 Wojciech Dec 699 Cisco Systems, Inc. 700 The Netherlands 702 Email: wdec@cisco.com 703 URI: http://cisco.com 705 Congxiao Bao 706 CERNET Center/Tsinghua University 707 Room 225, Main Building, Tsinghua University 708 Beijing 100084 709 CN 711 Phone: +86 10-62785983 712 Email: congxiao@cernet.edu.cn 713 Leaf Y. Yeh 714 CNNIC 715 4, South 4th Street, Zhong_Guan_Cun 716 Beijing 100190 717 P. R. China 719 Email: leaf.yeh.sdo@gmail.com 721 Xiaohong Deng 722 Yingke Law Firm 723 6 Floor, C Block, DaCheng International Center Chaoyang District 724 Beijing 100124 725 China 727 Phone: +61 3858 3128 728 Email: dxhbupt@gmail.com