idnits 2.17.1 draft-ietf-softwire-unified-cpe-08.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 (September 30, 2016) is 2762 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire WG M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track I. Farrer 5 Expires: April 3, 2017 Deutsche Telekom 6 September 30, 2016 8 Unified IPv4-in-IPv6 Softwire CPE: A DHCPv6-based Prioritization 9 Mechanism 10 draft-ietf-softwire-unified-cpe-08 12 Abstract 14 In IPv6-only provider networks, transporting IPv4 packets 15 encapsulated in IPv6 is a common solution to the problem of IPv4 16 service continuity. A number of differing functional approaches have 17 been developed for this, each having their own specific 18 characteristics. As these approaches share a similar functional 19 architecture and use the same data plane mechanisms, this memo 20 specifies a DHCPv6 option whereby a single CPE can interwork with all 21 of the standardized and proposed approaches to providing encapsulated 22 IPv4 in IPv6 services by providing a prioritization mechanism. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 3, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.3. DHCPv6 S46 Priority Option . . . . . . . . . . . . . . . 4 68 1.4. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 5 69 1.5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 6 70 2. Operator Deployment Considerations for Deploying Multiple 71 Sotfwire Mechanisms . . . . . . . . . . . . . . . . . . . . . 6 72 2.1. Client Address Planning . . . . . . . . . . . . . . . . . 6 73 2.2. Backwards Compatability with Existing Softwire Clients . 7 74 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. S46 Mechanisms and their Identifying Option Codes . . . . 8 77 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 6.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 IPv4 service continuity is one of the major technical challenges 86 which must be considered during IPv6 migration. Over the past few 87 years, a number of different approaches have been developed to assist 88 with this problem (e.g., [RFC6333], [RFC7596], or [RFC7597]). These 89 approaches, referred to as 'S46 mechanisms' in this document, exist 90 in order to meet the particular deployment, scaling, addressing and 91 other requirements of different service provider's networks. 93 A common feature shared between all of the differing modes is the 94 integration of softwire tunnel end-point functionality into the 95 Customer Premise Equipment (CPE) router. Due to this inherent data 96 plane similarity, a single CPE may be capable of supporting several 97 different approaches. Users may also wish to configure a specific 98 mode of operation. 100 A service provider's network may also have more than one S46 101 mechanism enabled in order to support a diverse CPE population with 102 differing client functionality, such as during a migration between 103 mechanisms, or where services require specific supporting softwire 104 architectures. 106 For softwire based services to be successfully established, it is 107 essential that the customer end-node, the service provider end-node 108 and provisioning systems are able to indicate their capabilities and 109 preferred mode of operation. 111 A number of DHCPv6 options for the provisioning of softwires have 112 been standardized: 114 RFC6334 Defines DHCPv6 option 64 for configuring Basic Bridging 115 BroadBand (B4, [RFC6333]) elements with the IPv6 address of 116 the Address Family Transition Router (AFTR, [RFC6333]). 117 RFC7341 Defines DHCPv6 option 88 for configuring the address of a 118 DHCPv4 over DHCPv6 server, which can then be used by a 119 softwire client for obtaining further configuration. 120 RFC7598 Defines DHCPv6 options 94, 95 and 96 for provisioning Mapping 121 of Address and Port with Encapsulation (MAP-E, [RFC7597]), 122 Mapping of Address and Port using Translation (MAP-T, 123 [RFC7599]), and Lightweight 4over6 [RFC7596] respectively. 125 This document describes a DHCPv6 based prioritization method whereby 126 a CPE which supports several S46 mechanisms and receives 127 configuration for more than one can prioritise which mechanism to 128 use. The method requires no server side logic to be implemented and 129 only uses a simple S46 mechanism prioritization to be implemented in 130 the CPE. 132 The prioritization method as described here does not provide 133 redundancy between S46 mechanisms for the client. I.e. If the 134 highest priority S46 mechanism which has been provisioned to the 135 client is not available for any reason, the means for identifying 136 this and falling back to the S46 mechanism with the next highest 137 priority is not in the scope of this document. 139 1.1. Terminology 141 This document makes use of the following terms: 143 o Address Family Transition Router (AFTR): is the IPv4-in-IPv6 144 tunnel termination point and the NAT44 function deployed in the 145 operator's network [RFC6333]. 146 o Border Relay (BR): a MAP-enabled router managed by the service 147 provider at the edge of a MAP domain. A BR has at least an 148 IPv6-enabled interface and an IPv4 interface connected to the 149 native IPv4 network [RFC7597]. 150 o Customer Premise Equipment (CPE): denotes the equipment at the 151 customer edge that terminates the customer end of an IPv6 152 transitional tunnel. In some documents (e.g., [RFC7597]), this 153 functional entity is called CE (Customer Edge). 155 1.2. Rationale 157 The following rationale has been adopted for this document: 159 (1) Simplify solution migration paths: Define unified CPE behavior, 160 allowing for smooth migration between the different s46 161 mechanisms. 162 (2) Deterministic CPE co-existence behavior: Specify the behavior 163 when several S46 mechanisms co-exist in the CPE. 164 (3) Deterministic service provider co-existence behavior: Specify 165 the behavior when several modes co-exist in the service 166 providers network. 167 (4) Re-usability: Maximize the re-use of existing functional blocks 168 including tunnel end-points, port restricted NAPT44, forwarding 169 behavior, etc. 170 (5) Solution agnostic: Adopt neutral terminology and avoid (as far 171 as possible) overloading the document with solution-specific 172 terms. 173 (6) Flexibility: Allow operators to compile CPE software only for 174 the mode(s) necessary for their chosen deployment context(s). 175 (7) Simplicity: Provide a model that allows operators to only 176 implement the specific mode(s) that they require without the 177 additional complexity of unneeded modes. 179 1.3. DHCPv6 S46 Priority Option 181 The S46 Priority Option is used to convey a priority order of IPv4 182 service continuity mechanisms. Figure 1 shows the format of the S46 183 Priority Option. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | OPTION_S46_PRIORITY | option-length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | s46-option-code | s46-option-code | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | ... | s46-option-code | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 1: S46 Priority Option 197 o option-code: OPTION_S46_PRIORITY (TBD) 198 o option-length: >=2 and a multiple of 2, in octets. 199 o s46-option-code: 16-bits long IANA registered option code of the 200 DHCPv6 option which is used to identify the softwire mechanism. 201 S46 mechanism are prioritized in the appearance order in the S46 202 Priority Option. 204 Codes in OPTION_S46_PRIORITY are processed in order; in the event 205 that a client receives more than one s46-option-code with a 206 particular value, this should be considered as invalid. DHCP servers 207 MAY validate the list of s46-option-code values to detect invalid 208 values and duplicates. The option MUST contain at least one s46- 209 option-code. 211 1.4. DHCPv6 Client Behavior 213 Clients MAY request option OPTION_S46_PRIORITY, as defined in 214 [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. 215 As a convenience to the reader, we mention here that the client 216 includes requested option codes in the Option Request Option. 218 Upon receipt of a DHCPv6 Advertise message from the server containing 219 OPTION_S46_PRIORITY the client performs the following steps: 221 1. Check the contents of the DHCPv6 message for options containing 222 valid S46 mechanism configuration. A candidate list of possible 223 S46 mechanisms is created from these option codes. 224 2. Check the contents of OPTION_S46_PRIORITY for the DHCPv6 option 225 codes contained in the included s46-option-code fields. From 226 this, an S46 mechanism priority list is created, ordered from 227 highest to lowest following the appearance order. 228 3. Sequentially check the priority list against the candidate list 229 until a match is found. 230 4. When a match is found, the client MUST configure the resulting 231 S46 mechanism. 233 In the event that no match is found between the priority list and the 234 candidate list, the client MAY proceed with configuring one or more 235 of the provisioned S46 softwire mechanism(s). In this case, which 236 mechanism(s) are chosen by the client is implementation-specific and 237 not defined here. 239 If an invalid OPTION_S46_PRIORITY option is received, the client MAY 240 proceed with configuring the provisioned S46 mechanisms as if 241 OPTION_S46_PRIORITY had not been received. 243 If an unknown option code is received in OPTION_S46_PRIORITY option, 244 the client MUST skip it and continue processing other listed option 245 codes if they exist. The initial option codes that are allowed to be 246 included in a OPTION_S46_PRIORITY option are listed in Section 4.1. 248 1.5. DHCPv6 Server Behavior 250 Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in 251 regards to option assignment. As a convenience to the reader, we 252 mention here that the server will send a particular option code only 253 if configured with specific values for that option code and if the 254 client requested it. 256 Option OPTION_S46_PRIORITY is a singleton. Servers MUST NOT send 257 more than one instance of the OPTION_S46_PRIORITY option. 259 2. Operator Deployment Considerations for Deploying Multiple Sotfwire 260 Mechanisms 262 The following sub-sections describe some considerations for operators 263 who are planning on implementing multiple softwire mechanisms in 264 their network (e.g., during a migration between mechanisms). 266 2.1. Client Address Planning 268 As an operator's available IPv4 resources are likely to be limited, 269 it may be desirable to use a common range of IPv4 addresses across 270 all of the active Softwire mechanisms. However, this is likely to 271 result in difficulties in routing ingress IPv4 traffic to the correct 272 Border Relay (BR)/AFTR instance which is actively serving a given CE. 273 For example, a client which is configured to use MAP-E may send its 274 traffic to the MAP-E BR, but on the return path, the ingress IP 275 traffic gets routed to a MAP-T BR. The resulting translated packet 276 that gets forwarded to the MAP-E client will be dropped. 278 Therefore, operators are advised to use separate IPv4 pools for each 279 of the different mechanisms to simplify planning and IPv4 routing. 281 For IPv6 planning there is less of a constraint as the BR/AFTR 282 elements for the different mechanisms can contain configuration for 283 overlapping client's IPv6 addresses, providing only one mechanism is 284 actively serving a given client at a time. However, the IPv6 address 285 that is used as the tunnel concentrator's endpoint (BR/AFTR address) 286 needs to be different for each mechanisms to ensure correct 287 operation. 289 2.2. Backwards Compatability with Existing Softwire Clients 291 Deployed clients which can support multiple softwire mechanisms, but 292 do not implement the prioritization mechanism described here may 293 require additional planning. In this scenario, the CPE would request 294 configuration for all of the supported softwire mechanisms in its 295 DHCPv6 Option Request Option (ORO), but would not request 296 OPTION_S46_PRIORITY. By default, the DHCPv6 server will respond with 297 configuration for all of the requested mechanisms which could result 298 in unpredictable and unwanted client configuration. 300 In this scenario, it may be necessary for the operator to implement 301 logic within the DHCPv6 server to identify such clients and only 302 provision them with configuration for a single softwire mechanism. 303 It should be noted that this can lead to complexity and reduced 304 scalability in the DHCPv6 server implementation due to the addition 305 DHCPv6 message processing overhead. 307 3. Security Considerations 309 Security considerations discussed in [RFC6334] and [RFC7598] apply 310 for this document. 312 Misbehaving intermediate nodes may alter the content of the S46 313 Priority Option. This may lead to setting a different IPv4 service 314 continuity mechanism than the one initially preferred by the network 315 side. Also, a misbehaving node may alter the content of the S46 316 Priority Option and other DHCPv6 options (e.g., DHCPv6 Option #64 or 317 #90) so that the traffic is intercepted by an illegitimate node. 318 Those attacks are not unique to the S46 Priority Option but are 319 applicable to any DHCPv6 option that can be altered by a misbehaving 320 intermediate node. 322 4. IANA Considerations 324 IANA is kindly requested to allocate the following DHCPv6 option 325 code: 327 TBD for OPTION_S46_PRIORITY 329 All values should be added to the DHCPv6 option code space defined in 330 Section 24.3 of [RFC3315]. 332 4.1. S46 Mechanisms and their Identifying Option Codes 334 This document requests that IANA create a new registry entitled 335 "Option Codes permitted in the S46 Priority Option". This registry 336 will enumerate the set of DHCPv6 Option Codes that can be included in 337 OPTION_S46_PRIORITY option. Options may be added to this list using 338 the IETF Review process described in Section 4.1 of [RFC5226]. 340 The following table shows the option codes which are currently 341 defined and the S46 mechanisms which they represent. The contents of 342 this table shows the format and the initial values for the new 343 registry. Option codes that have not been requested to be added 344 according to the stated procedure should not be mentioned at all in 345 the table, and should not be listed as "reserved" or "unassigned". 346 The valid range of values for the registry is the range of DHCPv6 347 Option Codes (1-65535). 349 +-------------+--------------------+-----------+ 350 | Option Code | S46 Mechanism | Reference | 351 +-------------+--------------------+-----------+ 352 | 64 | DS-Lite | [RFC6334] | 353 | 88 | DHCPv4 over DHCPv6 | [RFC7341] | 354 | 94 | MAP-E | [RFC7598] | 355 | 95 | MAP-T | [RFC7598] | 356 | 96 | Lightweight 4over6 | [RFC7598] | 357 +-------------+--------------------+-----------+ 359 Table 1: DHCPv6 Option to S46 Mechanism Mappings 361 5. Acknowledgements 363 Many thanks to O. Troan, S. Barth. A. Yourtchenko, B. Volz, T. 364 Mrugalski, J. Scudder, P. Kyzivat, F. Baker, and B. Campbell for 365 their input and suggestions. 367 6. References 369 6.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, 373 DOI 10.17487/RFC2119, March 1997, 374 . 376 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 377 C., and M. Carney, "Dynamic Host Configuration Protocol 378 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 379 2003, . 381 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 382 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 383 RFC 6334, DOI 10.17487/RFC6334, August 2011, 384 . 386 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 387 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 388 RFC 7341, DOI 10.17487/RFC7341, August 2014, 389 . 391 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 392 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 393 Configuration of Softwire Address and Port-Mapped 394 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 395 . 397 6.2. Informative References 399 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 400 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 401 DOI 10.17487/RFC5226, May 2008, 402 . 404 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 405 Stack Lite Broadband Deployments Following IPv4 406 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 407 . 409 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 410 Farrer, "Lightweight 4over6: An Extension to the Dual- 411 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 412 July 2015, . 414 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 415 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 416 Port with Encapsulation (MAP-E)", RFC 7597, 417 DOI 10.17487/RFC7597, July 2015, 418 . 420 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 421 and T. Murakami, "Mapping of Address and Port using 422 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 423 2015, . 425 Authors' Addresses 427 Mohamed Boucadair 428 Orange 429 Rennes 430 France 432 Email: mohamed.boucadair@orange.com 434 Ian Farrer 435 Deutsche Telekom 436 Germany 438 Email: ian.farrer@telekom.de