idnits 2.17.1 draft-ietf-softwire-unified-cpe-03.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 (January 13, 2016) is 3026 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: July 16, 2016 Deutsche Telekom 6 January 13, 2016 8 Unified IPv4-in-IPv6 Softwire CPE 9 draft-ietf-softwire-unified-cpe-03 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 describes a specification 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 July 16, 2016. 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. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. S46 Priority Option . . . . . . . . . . . . . . . . . . . 4 66 1.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 5 67 1.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6 68 1.5. S46 Mechanisms and their Identifying Option Codes . . . . 6 69 2. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 5.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 IPv4 service continuity is one of the major technical challenges 80 which must be considered during IPv6 migration. Over the past few 81 years, a number of different approaches have been developed to assist 82 with this problem (e.g., [RFC6333], [RFC7596], or [RFC7597]). These 83 approaches, referred to as 'S46 mechanisms' in this document, exist 84 in order to meet the particular deployment, scaling, addressing and 85 other requirements of different service provider's networks. 87 A common feature shared between all of the differing modes is the 88 integration of softwire tunnel end-point functionality into the CPE 89 router. Due to this inherent data plane similarity, a single CPE may 90 be capable of supporting several different approaches. Users may 91 also wish to configure a specific mode of operation. 93 A service provider's network may also have more than one S46 94 mechanism enabled in order to support a diverse CPE population with 95 differing client functionality, such as during a migration between 96 mechanisms, or where services require specific supporting softwire 97 architectures. 99 For softwire based services to be successfully established, it is 100 essential that the customer end-node, the service provider end-node 101 and provisioning systems are able to indicate their capabilities and 102 preferred mode of operation. 104 A number of DHCPv6 options for the provisioning of softwires have 105 been standardized: 107 RFC6334 Defines DHCPv6 option 64 for configuring Basic Bridging 108 BroadBand (B4, [RFC6333]) elements with the IPv6 address of 109 the Address Family Transition Router (AFTR, [RFC6333]). 110 RFC7341 Defines DHCPv6 option 88 for configuring the address of a 111 DHCPv4 over DHCPv6 server, which can then be used by a 112 softwire client for obtaining further configuration. 113 RFC7598 Defines DHCPv6 options 94, 95 and 96 for provisioning Mapping 114 of Address and Port with Encapsulation (MAP-E, [RFC7597]), 115 Mapping of Address and Port using Translation (MAP-T, 116 [RFC7599]), and Lightweight 4over6 [RFC7596] respectively. 118 This document describes a DHCPv6 based prioritisation method whereby 119 a CPE which supports several S46 mechanisms and receives 120 configuration for more than one can prioritise which mechanism to 121 use. The method requires no server side logic to be implemented and 122 only uses a simple S46 mechanism prioritization to be implemented in 123 the CPE. 125 The prioritisation method as described here does not provide 126 redundancy between S46 mechanisms for the client. I.e. If the 127 highest priority S46 mechanism which has been provisioned to the 128 client is not available for any reason, the means for identifying 129 this and falling back to the S46 mechanism with the next highest 130 priority is not in the scope of this document. 132 1.1. Rationale 134 The following rationale has been adopted for this document: 136 (1) Simplify solution migration paths: Define unified CPE behavior, 137 allowing for smooth migration between the different s46 138 mechanisms. 139 (2) Deterministic CPE co-existence behavior: Specify the behavior 140 when several S46 mechanisms co-exist in the CPE. 142 (3) Deterministic service provider co-existence behavior: Specify 143 the behavior when several modes co-exist in the service 144 providers network. 145 (4) Re-usability: Maximize the re-use of existing functional blocks 146 including tunnel end-points, port restricted NAPT44, forwarding 147 behavior, etc. 148 (5) Solution agnostic: Adopt neutral terminology and avoid (as far 149 as possible) overloading the document with solution-specific 150 terms. 151 (6) Flexibility: Allow operators to compile CPE software only for 152 the mode(s) necessary for their chosen deployment context(s). 153 (7) Simplicity: Provide a model that allows operators to only 154 implement the specific mode(s) that they require without the 155 additional complexity of unneeded modes. 157 1.2. S46 Priority Option 159 The S46 Priority Option is used to convey a priority order of IPv4 160 service continuity mechanisms. Figure 1 shows the format of the S46 161 Priority Option. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | OPTION_V6_S46_PRIORITY | option-length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | s46-option-code | s46-option-code | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | ... | s46-option-code | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 1: S46 Priority Option 175 o option-code: OPTION_V6_S46_PRIORITY (TBD) 176 o option-length: variable-length 177 o s46-option-code: 16-bits long IANA registered option code of the 178 DHCPv6 option which is used to identify the softwire mechanism. 179 S46 mechanism are prioritized in the appearance order in the S46 180 Priority Option. 182 Each defined s46_option_code MUST NOT appear more than once within 183 the list of S46 option codes. The option MUST contain at least one 184 s46-option-code. 186 1.3. Client Behavior 188 Clients MAY request option OPTION_V6_S46_PRIORITY, as defined in 189 [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. 190 As a convenience to the reader, we mention here that the client 191 includes requested option codes in the Option Request Option. 193 Upon receipt of a DHCPv6 Offer message from the server containing 194 OPTION_V6_S46_PRIORITY the client performs the following steps: 196 1. Check the contents of the DHCPv6 message for options containing 197 valid S46 mechanism configuration. A candidate list of possible 198 S46 mechanisms is created from these option codes. 199 2. Check the contents of OPTION_V6_S46_PRIORITY for the DHCPv6 200 option codes contained in the included s46-option-code fields. 201 From this, an S46 mechanism priority list is created, ordered 202 from highest to lowest following the appearance order. 203 3. Sequentially check the priority list against the candidate list 204 until a match is found. 205 4. When a match is found, the client SHOULD configure the resulting 206 S46 mechanism. Configuration for other S46 mechanisms MUST be 207 discarded. 209 In the event that no match is found between the priority list and the 210 candidate list, the client MAY proceed with configuring one or more 211 of the provisioned S46 softwire mechanism(s). In this case, which 212 mechanism(s) are chosen by the client is implementation-specific and 213 not defined here. 215 In the event that the client receives OPTION_V6_S46_PRIORITY with the 216 following errors, it MUST be discarded: 218 o No s46-option-code field is included. 219 o Multiple s46-option-code fields with the same value are included. 221 If an invalid OPTION_V6_S46_PRIORITY option is received, the client 222 MAY proceed with configuring the provisioned S46 mechanisms as if 223 OPTION_V6_S46_PRIORITY had not been received. 225 In the event that a client receives an OPTION_V6_S46_PRIORITY option 226 containing a value in s46-option-code representing an S46 mechanism 227 which the client has not implemented, this is not considered an 228 error. 230 1.4. Server Behavior 232 Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in 233 regards to option assignment. As a convenience to the reader, we 234 mention here that the server will send option foo only if configured 235 with specific values for foo and if the client requested it. 237 Option OPTION_V6_S46_PRIORITY is a singleton. Servers MUST NOT send 238 more than one instance of the OPTION_V6_S46_PRIORITY option. 240 1.5. S46 Mechanisms and their Identifying Option Codes 242 The following table shows the currently defined option codes and the 243 S46 mechanisms which they represent. This list is complete at the 244 time of writing, but should not be considered definitive as new S46 245 mechanisms may be defined in the future. 247 +-------------+--------------------+-----------+ 248 | Option Code | S46 Mechanism | Reference | 249 +-------------+--------------------+-----------+ 250 | 64 | DS-Lite | [RFC6334] | 251 | 88 | DHCPv6 over DHCPv6 | [RFC7341] | 252 | 94 | MAP-E | [RFC7598] | 253 | 95 | MAP-T | [RFC7598] | 254 | 96 | Lightweight 4over6 | [RFC7598] | 255 +-------------+--------------------+-----------+ 257 Table 1: DHCPv6 Option to S46 Mechanism Mappings 259 2. Security Considerations 261 Security considerations discussed in [RFC6334] and [RFC7598] apply 262 for this document. 264 Misbehaving intermediate nodes may alter the content of the S46 265 Priority Option. This may lead to setting a different IPv4 service 266 continuity mechanism than the one initially preferred by the network 267 side. 269 3. IANA Considerations 271 IANA is kindly requested to allocate the following DHCPv6 option 272 code: 274 TBD for OPTION_V6_S46_PRIORITY 276 All values should be added to the DHCPv6 option code space defined in 277 Section 24.3 of [RFC3315]. 279 4. Acknowledgements 281 Many thanks to O. Troan, S. Barth. A. Yourtchenko, B. Volz T. 282 Mrugalski for their input and suggestions. 284 5. References 286 5.1. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, 291 . 293 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 294 C., and M. Carney, "Dynamic Host Configuration Protocol 295 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 296 2003, . 298 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 299 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 300 RFC 6334, DOI 10.17487/RFC6334, August 2011, 301 . 303 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 304 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 305 RFC 7341, DOI 10.17487/RFC7341, August 2014, 306 . 308 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 309 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 310 Configuration of Softwire Address and Port-Mapped 311 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 312 . 314 5.2. Informative References 316 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 317 Stack Lite Broadband Deployments Following IPv4 318 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 319 . 321 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 322 Farrer, "Lightweight 4over6: An Extension to the Dual- 323 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 324 July 2015, . 326 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 327 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 328 Port with Encapsulation (MAP-E)", RFC 7597, 329 DOI 10.17487/RFC7597, July 2015, 330 . 332 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 333 and T. Murakami, "Mapping of Address and Port using 334 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 335 2015, . 337 Authors' Addresses 339 Mohamed Boucadair 340 Orange 341 Rennes 342 France 344 Email: mohamed.boucadair@orange.com 346 Ian Farrer 347 Deutsche Telekom 348 Germany 350 Email: ian.farrer@telekom.de