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