idnits 2.17.1 draft-ietf-softwire-unified-cpe-01.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 (May 30, 2013) is 3983 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) == Missing Reference: 'RFC6324' is mentioned on line 530, but not defined == Unused Reference: 'I-D.ietf-softwire-stateless-4v6-motivation' is defined on line 598, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-00 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-03 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-07 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-dhcpv6-00 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-public-4over6-09 Summary: 0 errors (**), 0 flaws (~~), 8 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: December 01, 2013 Deutsche Telekom 6 S. Perreault, Ed. 7 Viagenie 8 S. Sivakumar, Ed. 9 Cisco Systems 10 May 30, 2013 12 Unified IPv4-in-IPv6 Softwire CPE 13 draft-ietf-softwire-unified-cpe-01 15 Abstract 17 Transporting IPv4 packets encapsulated in IPv6 is a common solution 18 to the problem of IPv4 service continuity over IPv6-only provider 19 networks. A number of differing functional approaches have been 20 developed for this, each having their own specific characteristics. 21 As these approaches share a similar functional architecture and use 22 the same data plane mechanisms, this memo describes a specification 23 whereby a single CPE can interwork with all of the standardized and 24 proposed approaches to providing encapsulated IPv4 in IPv6 services. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 December 01, 2013. 49 Copyright Notice 51 Copyright (c) 2013 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 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. IPv4 Service Continuity Architectures: A 'Big Picture' 69 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. Functional Elements . . . . . . . . . . . . . . . . . . . 5 71 2.2. Required Provisioning Information . . . . . . . . . . . . 7 72 3. Unified Softwire CPE Behaviour . . . . . . . . . . . . . . . 7 73 3.1. IPv4 Address Functional Requirements . . . . . . . . . . 7 74 3.2. Generic CPE Bootstrapping Logic . . . . . . . . . . . . . 8 75 3.3. Customer Side DHCP Based Provisioning . . . . . . . . . . 9 76 3.4. Forwarding Action by the Customer End-Node . . . . . . . 12 77 4. Future Expansion of the Unified CPE Model . . . . . . . . . . 12 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 8.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 IPv4 service continuity is one of the major technical challenges 89 which must be considered during IPv6 migration. Over the past few 90 years, a number of different approaches have been developed to assist 91 with this problem. These approaches, or modes, exist in order to 92 meet the particular deployment, scaling, addressing and other 93 requirements of different service provider's networks. Section 2 of 94 this document describes these approaches in more detail. 96 A common feature shared between all of the differing modes is the 97 integration of softwire tunnel end-point functionality into the CPE 98 router. Due to this inherent data plane similarity, a single CPE may 99 be capable of supporting several different approaches. Users may 100 also wish to configure a specific mode of operation. 102 A service provider's network may also have more than one mode enabled 103 in order to support diverse CPE client functionality, during 104 migration between modes or where services require specific supporting 105 softwire architectures. 107 For softwire based services to be successfully established, it is 108 essential that the customer end-node, the service provider end-node 109 and provisioning systems are able to indicate their capabilities and 110 preferred mode of operation. 112 This memo describes the logic required by both the CPE tunnel end- 113 node and the service provider's provisioning infrastructure so that 114 softwire services can be provided in mixed-mode environments. 116 1.1. Rationale 118 The following rationale has been adopted for this document: 120 (1) Describe the functionality of each the different solution modes 121 and provide clear distinctions between them 123 (2) Simplify solution migration paths: Define unified CPE behavior, 124 allowing for smooth migration between the different modes 126 (3) Deterministic CPE co-existence behavior: Specify the behavior 127 when several modes co-exist in the CPE 129 (4) Deterministic service provider co-existence behavior: Specify 130 the behavior when several modes co-exist in the service providers 131 network 133 (5) Re-usability: Maximize the re-use of existing functional blocks 134 including tunnel end-points, port restricted NAPT44, forwarding 135 behavior, etc. 137 (6) Solution agnostic: Adopt neutral terminology and avoid (as far 138 as possible) overloading the document with solution-specific terms 140 (7) Flexibility: Allow operators to compile CPE software only for 141 the mode(s) necessary for their chosen deployment context(s) 143 (8) Simplicity: Provide a model that allows operators to only 144 implement the specific mode(s) that they require without the 145 additional complexity of unneeded modes. 147 2. IPv4 Service Continuity Architectures: A 'Big Picture' Overview 149 The solutions which have been proposed within the Softwire WG can be 150 categorized into three main functional approaches, differentiated by 151 the amount and type of state that the service provider needs to 152 maintain within their network: 154 (1) Full stateful approach (DS-Lite, [RFC6333]): Requires per- 155 session state to be maintained in the Service Provider's network. 156 (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) 157 [I-D.ietf-softwire-lw4over6][I-D.ietf-softwire-public-4over6] or 158 MAP 1:1 [I-D.ietf-softwire-map] ): Requires a single per- 159 subscriber state (or a few) to be maintained in the Service 160 Provider's network. 161 (3) Full stateless approach (MAP, [I-D.ietf-softwire-map]): Does not 162 require per-session or per-subscriber state to be maintained in 163 the Service Provider's network. 165 All these approaches share a similar architecture, with a tunnel 166 endpoint located in the CPE and a remote tunnel endpoint. All use 167 IPv6 as the transport protocol for the delivery of an IPv4 168 connectivity service using an IPv4-in-IPv6 encapsulation scheme 169 [RFC2473]. 171 Several cases can be envisaged: 173 1. The CPE is complied to support only one mode: No issue is raised 174 by this case. 175 2. The CPE supports several modes but only one mode is explicitly 176 configured: No issue is raised by this case. 177 3. The CPE supports several modes but no mode is explicitly enabled: 178 the CPE will need additional triggers to decide which mode to 179 activate. 180 4. The CPE supports several modes and several modes are configured: 181 the CPE will need additional triggers to decide which mode to 182 activate. 184 As this document describes a provisioning profile whereby a single 185 CPE could be capable of supporting any, or multiple modes, the 186 customer should not be required to have any knowledge of the 187 capabilities and configuration of their CPE, or of their service 188 provider's network. 190 The service provider, however, may have only a single mode enabled, 191 or may have multiple modes, but with one preferred mode. For this 192 reason, it is necessary to approach the configuration of CPEs from 193 the standpoint of the service provider's network capabilities. 195 2.1. Functional Elements 197 The functional elements for each of the solution modes are listed in 198 Table 1: 200 +---------+---------------+--------------+ 201 | Mode | Customer side | Network side | 202 +---------+---------------+--------------+ 203 | DS-Lite | B4 | AFTR | 204 | Lw4o6 | lwB4 | lwAFTR | 205 | MAP | MAP CE | MAP BR | 206 +---------+---------------+--------------+ 208 Table 1: Functional Elements 210 Table 2 describes each functional element: 212 +----------------+--------------------------------------------------+ 213 | Functional | Description | 214 | Element | | 215 +----------------+--------------------------------------------------+ 216 | B4 | An IPv4-in-IPv6 tunnel endpoint; the B4 creates | 217 | | a tunnel to a pre-configured remote tunnel | 218 | | endpoint. | 219 | AFTR | Provides both an IPv4-in-IPv6 tunnel endpoint | 220 | | and a NAT44 function implemented in the same | 221 | | node. | 222 | lwB4 | A B4 which supports port-restricted IPv4 | 223 | | addresses. An lwB4 MAY also provide a NAT44 | 224 | | function. | 225 | lwAFTR | An IPv4-in-IPv6 tunnel endpoint which maintains | 226 | | per-subscriber address binding. Unlike the AFTR, | 227 | | it MUST NOT perform a NAPT44 function. | 228 | MAP CE | A B4 which supports port-restricted IPv4 | 229 | | addresses. It MAY be co-located with a NAT44. A | 230 | | MAP CE forwards IPv4-in-IPv6 packets using | 231 | | provisioned mapping rules to derive the remote | 232 | | tunnel endpoint. | 233 | MAP BR | An IPv4-in-IPv6 tunnel endpoint. A MAP BR | 234 | | forwards IPv4-in-IPv6 packets following pre- | 235 | | configured mapping rules. | 236 +----------------+--------------------------------------------------+ 238 Table 2: Required Element Functionality 240 Table 3 identifies features required by the customer end-node. 242 +--------------+----------------+-----------------+-----------------+ 243 | Functional | IPv4-in-IPv6 | Port-restricted | Port-restricted | 244 | Element | tunnel | IPv4 | NAT44 | 245 | | endpoint | | | 246 +--------------+----------------+-----------------+-----------------+ 247 | B4 | Yes | N/A | No | 248 | lwB4 | Yes | Yes | Optional | 249 | MAP-E CE | Yes | Yes | Optional | 250 +--------------+----------------+-----------------+-----------------+ 252 Table 3: Supported Features 254 2.2. Required Provisioning Information 256 Table 4 identifies the provisioning information required for each 257 solution mode. 259 +---------+---------------------------------------------+ 260 | Mode | Provisioning Information | 261 +---------+---------------------------------------------+ 262 | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint Address | 263 | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint Address | 264 | | IPv4 Address | 265 | | Port Set | 266 | MAP-E | Mapping Rules | 267 | | MAP Domain Parameters | 268 +---------+---------------------------------------------+ 270 Table 4: Provisioning Information 272 Note: MAP Mapping Rules are translated into the following 273 configuration parameters: Set of remote IPv4-in-IPv6 tunnel endpoint 274 addresses, IPv4 address and port set. 276 Note: Required provisioning information for each mode may also 277 be represented as follows: 278 DS-Lite: - Remote IPv4-in-IPv6 Tunnel Endpoint 279 Lw4o6: - DS-Lite set of provisioning information 280 - IPv4 address 281 - Port set 282 MAP-E: - Lw4o6 set of provisioning information 283 - Forwarding mapping rules 285 3. Unified Softwire CPE Behaviour 287 This section specifies a unified CPE behavior capable of supporting 288 any one, or combination of, the three modes. 290 3.1. IPv4 Address Functional Requirements 292 The following two requirements must be met by the functional 293 elements: 295 Full IPv4 Address Assignment All the aforementioned modes MUST be 296 designed to allow either a full or a shared IPv4 address to be 297 assigned to a customer end-node. DS-Lite and MAP-E fulfil this 298 requirement. With minor changes, the [I-D.ietf-softwire-lw4over6] 299 specification can be updated to assign full IPv4 addresses. 301 Customer End-Node NAT A NAT function within the customer end-node is 302 not required for DS-Lite, while it is optional for both MAP-E and 303 Lw4o6. When NAT is enabled for MAP-E or Lw4o6, the customer end- 304 node NAT MUST be able to restrict the external translated source 305 ports to the set of ports that it has been provisioned with. 307 3.2. Generic CPE Bootstrapping Logic 309 The generic provisioning logic is designed to meet the following 310 requirements: 312 o When several service continuity modes are supported by the same 313 CPE, it MUST be possible to configure a single mode for use. 315 o For each network attachment, the end-node MUST NOT activate more 316 than one mode. 318 o The CPE MAY be configured by a user or via remote device 319 management means (e.g., DHCP, TR-069). 321 o A network which supports one or several modes MUST return valid 322 configuration data enabling requesting devices to unambiguously 323 select a single mode to use for attachment. 325 o A CPE which supports only one mode or it is configured to enable 326 only mode MUST ignore any configuration parameter which is not 327 required for the mode it supports. 329 This section sketches a generic algorithm to be followed by a CPE 330 supporting one or more of the modes listed above. Based on the 331 retrieved information, the CPE will determine which mode to activate. 333 (1) If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE 334 MUST be configured with the required provisioning information 335 listed in Table 4. If all of the required information is not 336 available locally, the CPE MUST use available provisioning means 337 (e.g., DHCP) to retrieve the missing configuration data. 339 (2) If the CPE supports several modes, but no mode is explicitly 340 enabled, the CPE MUST use available provisioning means (e.g., 341 DHCP) to retrieve available configuration parameters and use the 342 availability of individual parameters to ascertain which 343 functional mode to configure: 345 (2.1) If only a Remote IPv4-in-IPv6 Tunnel Endpoint is received, 346 the CPE MUST proceed as follows: 348 (2.1) 349 (2.1.1) IPv4-in-IPv6 tunnel endpoint initialization is 350 defined in [RFC6333]. 351 (2.1.2) Outbound IPv4 packets are forwarded to the next hop 352 as specified in Section 3.4. 354 (2.3) If a Remote IPv4-in-IPv6 Tunnel Endpoint, an IPv4 Address 355 and optionally a Port Set are received, the CPE MUST behave 356 as follows: 358 (2.3) 360 (2.2.1) IPv4-in-IPv6 tunnel endpoint initialization is 361 similar to the B4 [RFC6333]. 362 (2.2.2) When NAPT44 is required (e.g., because the CPE is a 363 router), a NAPT44 module is enabled. 364 (2.2.3) The tunnel endpoint address is selected from the 365 native IPv6 addresses configured on the CPE. No 366 particular considerations are required to be taken 367 into account to generate the Interface Identifier. 368 (2.2.4) When a port set is provisioned, the external source 369 ports MUST be restricted to the provisioned set of 370 ports. 371 (2.2.5) After translation, outbound IPv4 packets are 372 forwarded to the next hop as specified in 373 Section 3.4. 375 (2.6) If Mapping Rule(s) are received, the CPE MUST behave as 376 follows: 378 (2.6) 380 (2.3.1) IPv4-in-IPv6 tunnel endpoint initialization is 381 similar to the B4 [RFC6333]. 382 (2.3.2) The tunnel endpoint is assigned with an IPv6 383 address which includes an IPv4 address. The MAP 384 Interface Identifier is based on the format 385 specified in Section 2.2 of [RFC6052]. 386 (2.3.3) When NAPT44 is required (e.g., because the CPE is a 387 router), a NAPT44 module is enabled. 388 (2.3.4) When a port set is provisioned, the external source 389 port MUST be restricted to the provisioned set of 390 ports. 391 (2.3.5) After translation, outbound IPv4 packets then 392 forwarded to the next hop as specified in 393 Section 3.4. 395 3.3. Customer Side DHCP Based Provisioning 397 [DISCUSSION NOTE: 399 1. This section will be updated to reflect the consensus from DHC 400 WG 402 2. As it is proposed that OPTION_MAP would be used for all new 403 softwire provisioning, should we rename OPTION_MAP to 404 OPTION_SW (incl. the associated sub-options)?] 406 This section describes how the logic is implemented using DHCPv6 to 407 provision the necessary parameters for Unified CPE configuration. 408 Other provisioning mechanisms (e.g. static, PCP etc.) may be used 409 instead of, or in addition to DHCPv6 to provision the CPE. DHCP- 410 based configuration SHOULD be implemented by the customer end-node. 411 The following two DHCPv6 options are used: 413 OPTION_AFTR_NAME [RFC6334] Provides the FQDN for the remote IPv4 414 -in-IPv6 tunnel end-point. 416 OPTION_MAP [I-D.ietf-softwire-map-dhcp] Provides 417 IPv4-related configuration for binding mode and/ 418 or mapping rules for stateless mode (including 419 MAP parameters such as offset, domain prefix, 420 etc.). 422 By default, the customer end-node SHOULD support DHCPv6 MAP options 423 to provision IPv4-related connectivity parameters. If a dynamic port 424 assignment scheme is adopted, [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 425 SHOULD be supported. 427 The following additional sub-options are used to convey the different 428 possible configurations options for Binding Mode (using static or 429 dynamic IPv4 addressing plus additional DHCPv6 options): 431 OPTION_MAP_BIND A sub-option used to convey an IPv4 address (for 432 example, encoded as an IPv4-mapped IPv6 address 433 [RFC4291]). This address is used when binding 434 mode is enabled. The receipt of OPTION_MAP_BIND 435 is an implicit indication to the customer side 436 device to operate in binding, rather than 437 stateless mode. 439 OPTION_MAP_BIND_DYN A sub-option used to indicate to the client that 440 it must use the dynamic DHCPv4 over DHCPv6 441 process described in 442 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 444 The customer end-node uses the DHCP Option Request Option (ORO) to 445 request either one or both of these options depending on which modes 446 it is capable of and configured to support. 448 The DHCP option(s) sent in the response allow the service provider to 449 inform the customer end-node which operating mode to enable. 451 The following table shows the different DHCP options (and sub- 452 options) that the service provider can supply in a response. The 453 CPE's interpretation of the different Binding Options parameters are 454 described below. 456 +---------------------------+------------+------------+-------------+ 457 | DHCP Option | Stateful | Binding | Stateless | 458 | | Mode | Mode | Mode | 459 +---------------------------+------------+------------+-------------+ 460 | OPTION_AFTR_NAME | Yes | Yes | Yes | 461 | Binding Option(s) | No | Yes | No | 462 | OPTION_MAP_RULE | No | No | Yes | 463 | OPTION_MAP_PORTPARAMS | No | Optional | Optional | 464 +---------------------------+------------+------------+-------------+ 466 Table 5: DHCP Option Provisioning Matrix 468 The customer side device MUST interpret the received DHCP 469 configuration parameters according to the logic defined in 470 Section 3.2: 472 o If only OPTION_AFTR_NAME is received, then the device MUST operate 473 in stateful mode 475 o If both OPTION_AFTR_NAME and Binding Option(s) are received then 476 the device MUST operate in binding mode 478 o If one or more OPTION_MAP_RULE options are received, then the 479 customer side device MUST operate in stateless mode 481 o If both OPTION_AFTR_NAME and OPTION_MAP_RULE(s) are received, then 482 the customer side device MUST operate as a MAP CE. 483 OPTION_AFTR_NAME provides the FQDN of the MAP BR. 485 o If OPTION_MAP_PORTPARAMS is received as a sub-option to either 486 OPTION_MAP_BIND or OPTION_MAP_RULE, then NAPT44 MUST be configured 487 using the supplied port-set for external translated source ports. 489 From the service providers side, the following rule MUST be followed: 491 o The DHCP server MUST NOT send both Binding Option(s) and 492 OPTION_MAP_RULE in a single OPTION_MAP response. 494 3.4. Forwarding Action by the Customer End-Node 496 For all modes, the longest prefix match algorithm MUST be enforced to 497 forward outbound IPv4 packets. 499 Specifically, this algorithm will: 501 o Always return the address of the AFTR for the DS-Lite mode. 503 o Always return the address of the lwAFTR for the binding mode. 505 o Return the next hop according to the pre-configured mapping rules 506 for the stateless mode (i.e., MAP-E). 508 4. Future Expansion of the Unified CPE Model 510 The mechanism that is described here can be extended to cater for 511 other IPv4 service continuity approaches, outside of those 512 specifically covered in this document. In order to achieve this, the 513 following rules MUST be applied (in addition to the generic CPE 514 bootstrapping logic described in section 3.2 above): 516 The mechanism in extended by defining a new combination of 517 configuration parameters, unique to that mode of operation so that 518 the CPE can unambiguously determine which service continuity mode to 519 configure. This could be based on a new combination of existing 520 parameters, or on new parameters that are specific to the new 521 continuity mode. 523 It is important to note that it is the presence, or absence of 524 configuration parameters that are used to extend the Unified CPE 525 model, not the value of any individual (or multiple) parameters. 527 5. Security Considerations 529 Except for the less efficient port randomization and routing loops 530 [RFC6324], stateless 4/6 solutions are expected to introduce no more 531 security vulnerabilities than stateful ones. Because of their 532 stateless nature, they may in addition, reduce denial of service 533 opportunities. Security considerations defined in Section 11 of 534 [RFC6333] should be taken into account. 536 6. IANA Considerations 538 This document does not require any action from IANA. 540 7. Acknowledgements 542 Many thanks to T. Tsou, O. Troan, W. Dec, M. Chen, for their 543 review and comments. 545 Special thanks to S. Krishnan for the suggestions and guidance. 547 8. References 549 8.1. Normative References 551 [I-D.ietf-softwire-lw4over6] 552 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 553 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 554 Architecture", draft-ietf-softwire-lw4over6-00 (work in 555 progress), April 2013. 557 [I-D.ietf-softwire-map-dhcp] 558 Mrugalski, T., Troan, O., Dec, W., Bao, C., 559 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 560 for Mapping of Address and Port", draft-ietf-softwire-map- 561 dhcp-03 (work in progress), February 2013. 563 [I-D.ietf-softwire-map] 564 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 565 Murakami, T., and T. Taylor, "Mapping of Address and Port 566 with Encapsulation (MAP)", draft-ietf-softwire-map-07 567 (work in progress), May 2013. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 573 IPv6 Specification", RFC 2473, December 1998. 575 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 576 Architecture", RFC 4291, February 2006. 578 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 579 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 580 October 2010. 582 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 583 Stack Lite Broadband Deployments Following IPv4 584 Exhaustion", RFC 6333, August 2011. 586 8.2. Informative References 588 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 589 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 590 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 591 dhcpv4-over-dhcpv6-00 (work in progress), April 2013. 593 [I-D.ietf-softwire-public-4over6] 594 Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 595 IPv4 over IPv6 Access Network", draft-ietf-softwire- 596 public-4over6-09 (work in progress), May 2013. 598 [I-D.ietf-softwire-stateless-4v6-motivation] 599 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 600 Borges, I., and G. Chen, "Motivations for Carrier-side 601 Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- 602 softwire-stateless-4v6-motivation-05 (work in progress), 603 November 2012. 605 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 606 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 607 RFC 6334, August 2011. 609 Authors' Addresses 611 Mohamed Boucadair 612 France Telecom 613 Rennes 614 France 616 Email: mohamed.boucadair@orange.com 618 Ian Farrer 619 Deutsche Telekom 620 Germany 622 Email: ian.farrer@telekom.de 624 Simon Perreault (editor) 625 Viagenie 626 246 Aberdeen 627 Quebec QC G1R 2E1 628 Canada 630 Email: simon.perreault@viagenie.ca 631 Senthil Sivakumar (editor) 632 Cisco Systems 633 7100-8 Kit Creek Road 634 Research Triangle Park, North Carolina 635 USA 637 Email: ssenthil@cisco.com