idnits 2.17.1 draft-bfmk-softwire-unified-cpe-02.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 18, 2013) is 4115 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: 'I-D.ietf-softwire-public-4over6' is defined on line 527, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-cui-softwire-b4-translated-ds-lite-09 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-02 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-01 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-public-4over6-04 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire WG M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Standards Track I. Farrer 5 Expires: July 22, 2013 Deutsche Telekom 6 January 18, 2013 8 Unified IPv4-in-IPv6 Softwire CPE 9 draft-bfmk-softwire-unified-cpe-02 11 Abstract 13 Transporting IPv4 packets encapsulated in IPv6 is a common solution 14 to the problem of IPv4 service continuity over IPv6-only provider 15 networks. A number of differing functional approaches have been 16 developed for this, each having their own specific characteristics. 17 As these approaches share a similar functional architecture and use 18 the same data plane mechanisms, this memo describes a specification 19 whereby a single CPE can interwork with all of the standardized and 20 proposed approaches to providing encapsulated IPv4 in IPv6 services. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 22, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. IPv4 Service Continuity Architectures: A 'Big Picture' 65 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Functional Elements . . . . . . . . . . . . . . . . . . . 5 67 2.2. Required Provisoning Information . . . . . . . . . . . . . 6 68 3. Unified Softwire CPE Behaviour . . . . . . . . . . . . . . . . 7 69 3.1. IPv4 Address Functional Requirements . . . . . . . . . . . 7 70 3.2. Generic CPE Bootstrapping Logic . . . . . . . . . . . . . 7 71 3.3. Customer Side DHCP Based Provisioning . . . . . . . . . . 9 72 3.4. Forwarding Action by the Customer End-Node . . . . . . . . 11 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 IPv4 service continuity is one of the major technical challenges 84 which must be considered during IPv6 migration. Over the past few 85 years, a number of different approaches have been developed to assist 86 with this problem. These approaches, or modes, exist in order to 87 meet the particular deployment, scaling, addressing and other 88 requirements of different service provider's networks. Section 2 of 89 this document describes these approaches in more detail. 91 A common feature shared between all of the differing modes is the 92 integration of softwire tunnel end-point functionality into the CPE 93 router. Due to this inherent data plane similarity, a single CPE may 94 be capable of supporting several different approaches. Users may 95 also wish to configure a specific mode of operation. 97 A service provider's network may also have more than one mode enabled 98 in order to support diverse CPE client functionality, during 99 migration between modes or where services require specific supporting 100 softwire architectures. 102 For softwire based services to be successfully established, it is 103 essential that the customer end-node, the service provider end-node 104 and provisioning systems are able to indicate their capabilities and 105 preferred mode of operation. 107 This memo describes the logic required by both the CPE tunnel end- 108 node and the service provider's provisioning infrastructure so that 109 softwire services can be provided in mixed-mode environments. 111 1.1. Rationale 113 The following rationale has been adopted for this document: 115 (1) Describe the functionality of each the different solution modes 116 and provide clear distinctions between them 117 (2) Simplify solution migration paths: Define unified CPE behavior, 118 allowing for smooth migration between the different modes 119 (3) Deterministic CPE co-existence behavior: Specify the behavior 120 when several modes co-exist in the CPE 121 (4) Deterministic service provider co-existence behavior: Specify 122 the behavior when several modes co-exist in the service 123 providers network 124 (5) Re-usability: Maximize the re-use of existing functional blocks 125 including tunnel end-points, port restricted NAPT44, forwarding 126 behavior, etc. 128 (6) Solution agnostic: Adopt neutral terminology and avoid (as far 129 as possible) overloading the document with solution-specific 130 terms 131 (7) Flexibility: Allow operators to compile CPE software only for 132 the mode(s) necessary for their chosen deployment context(s) 133 (8) Simplicity: Provide a model that allows operators to only 134 implement the specific mode(s) that they require without the 135 additional complexity of unneeded modes. 137 2. IPv4 Service Continuity Architectures: A 'Big Picture' Overview 139 The solutions which have been proposed within the Softwire WG can be 140 categorized into three main functional approaches, differentiated by 141 the amount and type of state that the service provider needs to 142 maintain within their network: 143 (1) Full stateful approach (DS-Lite, [RFC6333]): Requires per- 144 session state to be maintained in the Service Provider's 145 network. 146 (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) 147 [I-D.cui-softwire-b4-translated-ds-lite][I-D.ietf-softwire-publi 148 c-4over6] or MAP 1:1 [I-D.ietf-softwire-map] ): Requires a 149 single per-subscriber state (or a few) to be maintained in the 150 Service Provider's network. 151 (3) Full stateless approach (MAP, [I-D.ietf-softwire-map]): Does not 152 require per-session or per-subscriber state to be maintained in 153 the Service Provider's network. 155 All these approaches share a similar architecture, with a tunnel 156 endpoint located in the CPE and a remote tunnel endpoint. All use 157 IPv6 as the transport protocol for the delivery of an IPv4 158 connectivity service using an IPv4-in-IPv6 encapsulation scheme 159 [RFC2473]. 161 Several cases can be envisaged: 162 1. The CPE is complied to support only one mode: No issue is raised 163 by this case. 164 2. The CPE supports several modes but only one mode is explicitly 165 configured: No issue is raised by this case. 166 3. The CPE supports several modes but no mode is explicitly enabled: 167 the CPE will need additional triggers to decide which mode to 168 activate. 169 4. The CPE supports several modes and several modes are configured: 170 the CPE will need additional triggers to decide which mode to 171 activate. 173 As this document describes a provisioning profile whereby a single 174 CPE could be capable of supporting any, or multiple modes, the 175 customer should not be required to have any knowledge of the 176 capabilities and configuration of their CPE, or of their service 177 provider's network. 179 The service provider, however, may have only a single mode enabled, 180 or may have multiple modes, but with one preferred mode. For this 181 reason, it is necessary to approach the configuration of CPEs from 182 the standpoint of the service provider's network capabilities. 184 2.1. Functional Elements 186 The functional elements for each of the solution modes are listed in 187 Table 1: 189 +---------+---------------+--------------+ 190 | Mode | Customer side | Network side | 191 +---------+---------------+--------------+ 192 | DS-Lite | B4 | AFTR | 193 | Lw4o6 | lwB4 | lwAFTR | 194 | MAP | MAP CE | MAP BR | 195 +---------+---------------+--------------+ 197 Table 1: Functional Elements 199 Table 2 describes each functional element: 201 +------------+------------------------------------------------------+ 202 | Functional | Description | 203 | Element | | 204 +------------+------------------------------------------------------+ 205 | B4 | An IPv4-in-IPv6 tunnel endpoint; the B4 creates a | 206 | | tunnel to a pre-configured remote tunnel endpoint. | 207 | AFTR | Provides both an IPv4-in-IPv6 tunnel endpoint and a | 208 | | NAT44 function implemented in the same node. | 209 | lwB4 | A B4 which supports port-restricted IPv4 addresses. | 210 | | An lwB4 MAY also provide a NAT44 function. | 211 | lwAFTR | An IPv4-in-IPv6 tunnel endpoint which maintains | 212 | | per-subscriber address binding. Unlike the AFTR, it | 213 | | MUST NOT perform a NAPT44 function. | 214 | MAP CE | A B4 which supports port-restricted IPv4 addresses. | 215 | | It MAY be co-located with a NAT44. A MAP CE | 216 | | forwards IPv4-in-IPv6 packets using provisioned | 217 | | mapping rules to derive the remote tunnel endpoint. | 218 | MAP BR | An IPv4-in-IPv6 tunnel endpoint. A MAP BR forwards | 219 | | IPv4-in-IPv6 packets following pre-configured | 220 | | mapping rules. | 221 +------------+------------------------------------------------------+ 222 Table 2: Required Element Functionality 224 Table 3 identifies features required by the customer end-node. 226 +--------------+----------------+-----------------+-----------------+ 227 | Functional | IPv4-in-IPv6 | Port-restricted | Port-restricted | 228 | Element | tunnel | IPv4 | NAT44 | 229 | | endpoint | | | 230 +--------------+----------------+-----------------+-----------------+ 231 | B4 | Yes | N/A | No | 232 +--------------+----------------+-----------------+-----------------+ 233 | lwB4 | Yes | Yes | Optional | 234 +--------------+----------------+-----------------+-----------------+ 235 | MAP-E CE | Yes | Yes | Optional | 236 +--------------+----------------+-----------------+-----------------+ 238 Table 3: Supported Features 240 2.2. Required Provisoning Information 242 Table 4 identifies the provisioning information required for each 243 solution mode. 245 +---------+---------------------------------------------+ 246 | Mode | Provisioning Information | 247 +---------+---------------------------------------------+ 248 | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint Address | 249 | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint Address | 250 | | IPv4 Address | 251 | | Port Set | 252 | MAP-E | Mapping Rules | 253 | | MAP Domain Parameters | 254 +---------+---------------------------------------------+ 256 Table 4: Provisioning Information 258 Note: MAP Mapping Rules are translated into the following 259 configuration parameters: Set of remote IPv4-in-IPv6 tunnel endpoint 260 addresses, IPv4 address and port set. 262 Note: Required provisioning information for each mode may also 263 be represented as follows: 264 DS-Lite: - Remote IPv4-in-IPv6 Tunnel Endpoint 265 Lw4o6: - DS-Lite set of provisioning information 266 - IPv4 address 267 - Port set 268 MAP-E: - Lw4o6 set of provisioning information 269 - Forwarding mapping rules 271 3. Unified Softwire CPE Behaviour 273 This section specifies a unified CPE behavior capable of supporting 274 any one, or combination of, the three modes. 276 3.1. IPv4 Address Functional Requirements 278 The following two requirements must be met by the functional 279 elements: 281 Full IPv4 Address Assingment All the aforementioned modes MUST be 282 designed to allow either a full or a shared IPv4 address to be 283 assigned to a customer end-node. DS-Lite and MAP-E fulfill this 284 requirement. With minor changes, the 285 [I-D.cui-softwire-b4-translated-ds-lite] specification can be 286 updated to assign full IPv4 addresses. 288 Customer End-Node NAT A NAT function within the customer end-node is 289 not required for DS-Lite, while it is optional for both MAP-E and 290 Lw4o6. When NAT is enabled for MAP-E or Lw4o6, the customer end- 291 node NAT MUST be able to restrict the external translated source 292 ports to the set of ports that it has been provisioned with. 294 3.2. Generic CPE Bootstrapping Logic 296 The generic provisioning logic is designed to meet the following 297 requirements: 299 o When several service continuity modes are supported by the same 300 CPE, it MUST be possible to configure a single mode for use. 302 o For each network attachment, the end-node MUST NOT activate more 303 than one mode. 305 o The CPE MAY be configured by a user or via remote device 306 management means (e.g., DHCP, TR-069). 308 o A network which supports one or several modes MUST return valid 309 configuration data enabling requesting devices to unambiguously 310 select a single mode to use for attachment. 312 o A CPE which supports only one mode or it is configured to enable 313 only mode MUST ignore any configuration parameter which is not 314 required for the mode it supports. 316 This section sketches a generic algorithm to be followed by a CPE 317 supporting one or more of the modes listed above. Based on the 318 retrieved information, the CPE will determine which mode to activate. 320 (1) If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE 321 MUST be configured with the required provisioning information 322 listed in Table 4. If all of the required information is not 323 available locally, the CPE MUST use available provisioning means 324 (e.g., DHCP) to retrieve the missing configuration data. 326 (2) If the CPE supports several modes, but no mode is explicitly 327 enabled, the CPE MUST use available provisioning means (e.g., 328 DHCP) to retrieve available configuration parameters and use the 329 availability of individual parameters to ascertain which 330 functional mode to configure: 332 (2.1) If only a Remote IPv4-in-IPv6 Tunnel Endpoint is 333 received, the CPE MUST proceed as follows: 334 (2.1.1) IPv4-in-IPv6 tunnel endpoint initialization is 335 defined in [RFC6333]. 336 (2.1.2) Outbound IPv4 packets are forwarded to the next 337 hop as specified in Section 3.4. 339 (2.2) If a Remote IPv4-in-IPv6 Tunnel Endpoint, an IPv4 Address 340 and optionally a Port Set are received, the CPE MUST 341 behave as follows: 342 (2.2.1) IPv4-in-IPv6 tunnel endpoint initialization is 343 similar to the B4 [RFC6333]. 344 (2.2.2) When NAPT44 is required (e.g., because the CPE 345 is a router), a NAPT44 module is enabled. 346 (2.2.3) The tunnel endpoint address is selected from the 347 native IPv6 addresses configured on the CPE. No 348 particular considerations are required to be 349 taken into account to generate the Interface 350 Identifier. 351 (2.2.4) When a port set is provisioned, the external 352 source ports MUST be restricted to the 353 provisioned set of ports. 354 (2.2.5) After translation, outbound IPv4 packets are 355 forwarded to the next hop as specified in 356 Section 3.4. 358 (2.3) If Mapping Rule(s) are received, the CPE MUST behave as 359 follows: 361 (2.3.1) IPv4-in-IPv6 tunnel endpoint initialization is 362 similar to the B4 [RFC6333]. 363 (2.3.2) The tunnel endpoint is assigned with an IPv6 364 address which includes an IPv4 address. The MAP 365 Interface Identifier is based on the format 366 specified in Section 2.2 of [RFC6052]. 367 (2.3.3) When NAPT44 is required (e.g., because the CPE 368 is a router), a NAPT44 module is enabled. 369 (2.3.4) When a port set is provisioned, the external 370 source port MUST be restricted to the 371 provisioned set of ports. 372 (2.3.5) After translation, outbound IPv4 packets then 373 forwarded to the next hop as specified in 374 Section 3.4. 376 3.3. Customer Side DHCP Based Provisioning 378 [DISCUSSION NOTE: 380 1. This section will be updated to reflect the consensus from DHC 381 WG. 383 2. As it is proposed that OPTION_MAP would be used for all new 384 softwire provisioning, should we rename OPTION_MAP to 385 OPTION_SW (incl. the associated sub-options)?] 387 ] 389 DHCP-based configuration SHOULD be implemented by the customer end- 390 node using the following two DHCP options: 392 OPTION_AFTR_NAME [RFC6334] Provides the FQDN for the remote IPv4- 393 in-IPv6 tunnel end-point. 395 OPTION_MAP [I-D.ietf-softwire-map-dhcp] Provides IPv4- 396 related configuration for binding mode and/or 397 mapping rules for stateless mode (including MAP 398 parameters such as offset, domain prefix, etc.). 399 OPTION_MAP_BIND is a sub-option used to convey an 400 IPv4 address (for example, encoded as an IPv4- 401 mapped IPv6 address [RFC4291]). This address is 402 used when binding mode is enabled. The receipt 403 of OPTION_MAP_BIND is an implicit indication to 404 the customer side device to operate in binding, 405 rather than stateless mode. 407 The customer end-node uses the DHCP Option Request Option (ORO) to 408 request either one or both of these options depending on which modes 409 it is capable of and configured to support. 411 The DHCP option(s) sent in the response allow the service provider to 412 inform the customer end-node which operating mode to enable. 414 The following table shows the different DHCP options (and sub- 415 options) that the service provider can supply in a response. 417 +-----------------------+-------------+-------------+---------------+ 418 | DHCP Option | Stateful | Binding | Stateless | 419 | | Mode | Mode | Mode | 420 +-----------------------+-------------+-------------+---------------+ 421 | OPTION_AFTR_NAME | Yes | Yes | Optional | 422 | OPTION_MAP_BIND | No | Yes | No | 423 | OPTION_MAP_RULE | No | No | Yes | 424 | OPTION_MAP_PORTPARAMS | No | Optional | Optional | 425 +-----------------------+-------------+-------------+---------------+ 427 Table 5: DHCP Option Provisioning Matrix 429 The customer side device MUST interpret the received DHCP 430 configuration parameters according to the logic defined in 431 Section 3.2: 433 o If only OPTION_AFTR_NAME is received, then the device MUST operate 434 in stateful mode 436 o If both OPTION_AFTR_NAME and OPTION_MAP_BIND are received then the 437 device MUST operate in binding mode 439 o If one or more OPTION_MAP_RULE options are received, then the 440 customer side device MUST operate in stateless mode 442 o If both OPTION_AFTR_NAME and OPTION_MAP_RULE(s) are received, then 443 the customer side device MUST operate as a MAP CE. 444 OPTION_AFTR_NAME provides the FQDN of the MAP BR. 446 o If OPTION_MAP_PORTPARAMS is received as a sub-option to either 447 OPTION_MAP_BIND or OPTION_MAP_RULE, then NAPT44 MUST be configured 448 using the supplied port-set for external translated source ports. 450 From the service providers side, the following rule MUST be followed: 452 o The DHCP server MUST NOT send both OPTION_MAP_BIND and 453 OPTION_MAP_RULE in a single OPTION_MAP response. 455 3.4. Forwarding Action by the Customer End-Node 457 For all modes, the longest prefix match algorithm MUST be enforced to 458 forward outbound IPv4 packets. 460 Specifically, this algorithm will: 462 o Always return the address of the AFTR for the DS-Lite mode. 464 o Always return the address of the lwAFTR for the binding mode. 466 o Return the next hop according to the pre-configured mapping rules 467 for the stateless mode (i.e., MAP-E). 469 4. Security Considerations 471 Security considerations discussed in Section 7 of 472 [I-D.ietf-softwire-stateless-4v6-motivation] and Section 11 of 473 [RFC6333] should be taken into account. 475 5. IANA Considerations 477 This document does not require any action from IANA. 479 6. Acknowledgements 481 Many thanks to T. Tsou, S. Perrault, S. Sivakumar, O. Troan, W. Dec, 482 M. Chen, for their review and comments. 484 Special thanks to S. Krishnan for the suggestions and guidance. 486 7. References 488 7.1. Normative References 490 [I-D.cui-softwire-b4-translated-ds-lite] 491 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 492 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 493 Architecture", draft-cui-softwire-b4-translated-ds-lite-09 494 (work in progress), October 2012. 496 [I-D.ietf-softwire-map] 497 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., and 498 T. Murakami, "Mapping of Address and Port with 499 Encapsulation (MAP)", draft-ietf-softwire-map-02 (work in 500 progress), September 2012. 502 [I-D.ietf-softwire-map-dhcp] 503 Mrugalski, T., Troan, O., Bao, C., Dec, W., and L. Yeh, 504 "DHCPv6 Options for Mapping of Address and Port", 505 draft-ietf-softwire-map-dhcp-01 (work in progress), 506 August 2012. 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, March 1997. 511 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 512 IPv6 Specification", RFC 2473, December 1998. 514 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 515 Architecture", RFC 4291, February 2006. 517 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 518 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 519 October 2010. 521 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 522 Stack Lite Broadband Deployments Following IPv4 523 Exhaustion", RFC 6333, August 2011. 525 7.2. Informative References 527 [I-D.ietf-softwire-public-4over6] 528 Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 529 IPv4 over IPv6 Access Network", 530 draft-ietf-softwire-public-4over6-04 (work in progress), 531 October 2012. 533 [I-D.ietf-softwire-stateless-4v6-motivation] 534 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 535 Borges, I., and G. Chen, "Motivations for Carrier-side 536 Stateless IPv4 over IPv6 Migration Solutions", 537 draft-ietf-softwire-stateless-4v6-motivation-05 (work in 538 progress), November 2012. 540 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 541 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 542 RFC 6334, August 2011. 544 Authors' Addresses 546 Mohamed Boucadair 547 France Telecom 548 Rennes 549 France 551 Email: mohamed.boucadair@orange.com 553 Ian Farrer 554 Deutsche Telekom 555 Germany 557 Email: ian.farrer@telekom.de