RFC 8585: Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service
- J. Palet Martinez,
- H. M.-H. Liu,
- M. Kawashima
Informational
Internet Engineering Task Force (IETF) J. Palet Martinez
Request for Comments: 8585 The IPv6 Company
Category: Informational H. M.-H. Liu
ISSN: 2070-1721 D-Link Systems, Inc.
M. Kawashima
NEC Platforms, Ltd.
May 2019
Requirements for IPv6 Customer Edge Routers
to Support IPv4-as-a-Service
Abstract
This document specifies the IPv4 service continuity requirements for
IPv6 Customer Edge (CE) routers that are provided either by the
service provider or by vendors who sell through the retail market.
Specifically, this document extends the basic requirements for IPv6
CE routers as described in RFC 7084 to allow the provisioning of IPv6
transition services for the support of IPv4-as-a-Service (IPv4aaS) by
means of new transition mechanisms. The document only covers
IPv4aaS, i.e., transition technologies for delivering IPv4 in
IPv6-only access networks. IPv4aaS is necessary because there aren't
sufficient IPv4 addresses available for every possible customer/
device. However, devices or applications in the customer Local Area
Networks (LANs) may be IPv4-only or IPv6-only and still need to
communicate with IPv4-only services on the Internet.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8585.
Palet Martinez, et al. Informational [Page 1]
RFC 8585 Requirements for IPv6 CE to Support IPv4aaS May 2019 Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. LAN-Side Configuration . . . . . . . . . . . . . . . . . 5 3.2. Transition Technologies Support for IPv4 Service Continuity (IPv4-as-a-Service) . . . . . . . . . . . . . 5 3.2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 8 3.2.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 9 3.2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 10 4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 11 5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Comparison to RFC 7084 . . . . . . . . . . . . . . . . . . . 12 7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . 17 Appendix B. End-User Network Architecture . . . . . . . . . . . 18 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Palet Martinez, et al. Informational [Page 2]
RFC 8585 Requirements for IPv6 CE to Support IPv4aaS May 2019 1. Introduction This document defines IPv4 service continuity features over an IPv6-only network for residential or small office routers (referred to as "IPv6 Transition CE Routers") in order to establish an industry baseline for transition features to be implemented on such routers. These routers rely upon requirements for IPv6 CE routers defined in [RFC7084]. The scope of this document is to ensure IPv4 service continuity support for devices in the LAN side. This ensures that remote IPv4-only services continue to be accessible, for both IPv4-only and IPv6-only applications and devices, located in the LAN side behind an IPv6 Transition CE Router connected to an IPv6-only access network. These ISP access networks are typically referred to as Wide Area Networks (WANs), even if they may be metropolitan or regional in some cases. Figure 1 presents a simplified view of this architecture. +------------+ +------------+ \ | IPv4-only | | IPv4/IPv6 | \ | Remote | | Remote | | | Host | | Host | | Internet +--------+---+ +---+--------+ | | | / | | / +-+-----------+-+ \ | Service | \ | Provider | \ | Router | | Service +-------+-------+ | Provider | IPv6-only | Network | Customer / | Internet Connection / | / +------+--------+ \ | IPv6 | \ | Transition CE | \ | Router | | +---+-------+---+ | LAN A | | LAN B | End-User -+----------------+- -+-----+-------------+- | Network(s) | | | | +---+------+ +----+-----+ +-----+----+ | | IPv6-only| | IPv4-only| |IPv4/IPv6 | / | Host | | Host | | Host | / +----------+ +----------+ +----------+ / Figure 1: Simplified Typical IPv6-Only Access Network Palet Martinez, et al. Informational [Page 3]
RFC 8585 Requirements for IPv6 CE to Support IPv4aaS May 2019 This document covers a set of IP transition techniques required when ISPs have, or want to have, an IPv6-only access network. This is a common situation when sufficient IPv4 addresses are no longer available for every possible customer and device, which causes IPv4 addresses to become prohibitively expensive. This, in turn, may result in service providers provisioning IPv6-only WAN access. At the same time, they need to ensure that both IPv4-only and IPv6-only devices and applications in the customer networks can still reach IPv4-only devices and applications on the Internet. This document specifies the IPv4 service continuity mechanisms to be supported by an IPv6 Transition CE Router and relevant provisioning or configuration information differences from [RFC7084]. This document is not a recommendation for service providers to use any specific transition mechanism. Automatic provisioning of more complex topology than a single router with multiple LAN interfaces may be handled by means of the Home Networking Control Protocol (HNCP) [RFC7788], which is out of the scope of this document. Since it is impossible to know prior to sale which transition mechanism a device will need over its lifetime, an IPv6 Transition CE Router intended for the retail market MUST support all the IPv4aaS transition mechanisms listed in this document. Service providers that specify feature sets for the IPv6 Transition CE Router may define a different set of features from those included in this document, for example, features that support only some of the transition mechanisms enumerated in this document. Appendices A and B contain a complete description of the usage scenarios and end-user network architecture, respectively. These appendices, along with [RFC7084], will facilitate a clearer understanding of this document. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Palet Martinez, et al. Informational [Page 4]
RFC 8585 Requirements for IPv6 CE to Support IPv4aaS May 2019 2. Terminology This document uses the same terms as in [RFC7084], with minor clarifications. "IPv4aaS" stands for "IPv4-as-a-Service", meaning transition technologies for delivering IPv4 in IPv6-only connectivity. The term "IPv6 transition Customer Edge Router with IPv4aaS" (shortened as "IPv6 Transition CE Router") is defined as an IPv6 Customer Edge Router that provides features for the delivery of IPv4 services over an IPv6-only WAN network, including IPv6-IPv4 communications. The term "WAN Interface" as used in this document is defined as an IPv6 Transition CE Router attachment to an IPv6-only link used to provide connectivity to a service provider network, including link Internet-layer (or higher layers) tunnels, such as IPv4-in-IPv6 tunnels. 3. Requirements The IPv6 Transition CE Router MUST comply with [RFC7084] ("Basic Requirements for IPv6 Customer Edge Routers"). This document adds new requirements, as described in the following subsections. 3.1. LAN-Side Configuration A new LAN requirement is added, which is, in fact, common in regular IPv6 Transition CE Routers, and is required by most of the transition mechanisms: L-1: The IPv6 Transition CE Router MUST implement a DNS proxy as described in [RFC5625] ("DNS Proxy Implementation Guidelines"). 3.2. Transition Technologies Support for IPv4 Service Continuity (IPv4- as-a-Service) The main target of this document is the support of IPv6-only WAN access. To enable legacy IPv4 functionality, this document also includes the support of IPv4-only devices and applications in the customer LANs, as well as IPv4-only services on the Internet. Thus, both IPv4-only and IPv6-only devices in the customer-side LANs of the IPv6 Transition CE Router are able to reach the IPv4-only services. Palet Martinez, et al. Informational [Page 5]
RFC 8585 Requirements for IPv6 CE to Support IPv4aaS May 2019 Note that this document only configures IPv4aaS in the IPv6 Transition CE Router itself; it does not forward such information to devices attached to the LANs. Thus, the WAN configuration and availability of native IPv4 or IPv4aaS are transparent for the devices attached to the LANs. This document takes no position on simultaneous operation of one or several transition mechanisms and/or native IPv4. In order to seamlessly provide IPv4 service continuity in the customer LANs and allow automated IPv6 transition mechanism provisioning, the following general transition requirements are defined. General transition requirements: TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46 priority options described in [RFC8026] ("Unified IPv4-in- IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism"). TRANS-2: The IPv6 Transition CE Router MUST have a GUI and either a CLI or API (or both) to manually enable/disable each of the supported transition mechanisms. TRANS-3: If an IPv6 Transition CE Router supports more than one LAN subnet, the IPv6 Transition CE Router MUST allow appropriate subnetting and configuration of the address space among several interfaces. In some transition mechanisms, this may require differentiating mappings/ translations on a per-interface basis. In order to allow the service provider to disable all the transition mechanisms and/or choose the most convenient one, the IPv6 Transition CE Router MUST follow the following configuration steps: CONFIG-1: Request the relevant configuration options for each supported transition mechanisms, which MUST remain disabled at this step. CONFIG-2: Following the steps in Section 1.4 of [RFC8026], MUST check for a valid match in OPTION_S46_PRIORITY, which allows enabling/disabling a transition mechanism. CONFIG-3: Keep disabled all the transition mechanisms if no match is found between the priority list and the candidate list, unless a NAT64 [RFC6146] prefix has been configured, in which case, 464XLAT [RFC6877] MUST be enabled. Palet Martinez, et al. Informational [Page 6]
RFC 8585 Requirements for IPv6 CE to Support IPv4aaS May 2019 Because 464XLAT has no DHCPv6 configuration options, it can't currently be included in the OPTION_S46_PRIORITY. In the future, an update of [RFC8026] or a NAT64 DHCPv6 configuration option may enable it. Meanwhile, if an operator provides 464XLAT, it needs to ensure that OPTION_S46_PRIORITY is not sent for any other transition mechanism to the relevant customers. The following subsections describe the requirements for supporting each one of the transition mechanisms. An IPv6 Transition CE Router intended for the retail market MUST support all of them. 3.2.1. 464XLAT 464XLAT [RFC6877] is a technique to provide IPv4 service over an IPv6-only access network without encapsulation. This architecture assumes a Stateful NAT64 [RFC6146] function deployed at the service provider or a third-party network. The IPv6 Transition CE Router MUST support customer-side translator (CLAT) functionality [RFC6877] if intended for the retail market. If 464XLAT is supported, it MUST be implemented according to [RFC6877]. The following IPv6 Transition CE Router requirements also apply. 464XLAT requirements: 464XLAT-1: Unless a dedicated /64 prefix has been acquired, either by using DHCPv6-PD (Dynamic Host Configuration Protocol for IPv6 Prefix Delegation) or by alternative means, the IPv6 Transition CE Router MUST perform IPv4 Network Address Translation (NAT) on IPv4 traffic translated using the CLAT. 464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF [RFC6970] ("Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)"). 464XLAT-3: If the Port Control Protocol (PCP) [RFC6887] is implemented, the IPv6 Transition CE Router MUST also implement [RFC7291] ("DHCP Options for the Port Control Protocol (PCP)"). Following [RFC6887], if no PCP server is configured, the IPv6 Transition CE Router MAY verify if the default gateway or the NAT64 is the PCP server. The IPv6 Transition CE Router MUST use plain IPv6 mode (i.e., not IPv4-in-IPv6 encapsulation) to send PCP requests to the server. Palet Martinez, et al. Informational [Page 7]
RFC 8585 Requirements for IPv6 CE to Support IPv4aaS May 2019 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") in order to discover the provider-side translator (PLAT) translation IPv4 and IPv6 prefix(es)/suffix(es). 464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST follow [RFC7225] ("Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)") in order to learn the PLAT-side translation IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream PCP-controlled NAT64 device. 464XLAT-6: If the network provides several choices for the discovery/learning of the NAT64 prefix, the priority to use one or the other MUST follow this order: 1) [RFC7225] and 2) [RFC7050]. The NAT64 prefix could be discovered by means of the method defined in [RFC7050] only if the service provider uses DNS64 [RFC6147]. It may be the case that the service provider does not use or does not trust DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behind the CE) can be modified by the customer. In that case, the service provider may opt to configure the NAT64 prefix by means of the option defined in [RFC7225]. This can also be used if the service provider uses DNS64 [RFC6147]. 3.2.2. Dual-Stack Lite (DS-Lite) DS-Lite [RFC6333] enables continued support for IPv4 services. DS-Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected that DS-Lite traffic is forwarded over the IPv6 Transition CE Router's native IPv6 WAN interface and not encapsulated in another tunnel. The IPv6 Transition CE Router MUST implement DS-Lite B4 functionality [RFC6333] if intended for the retail market. If DS-Lite is supported, it MUST be implemented according to [RFC6333]. The following IPv6 Transition CE Router requirements also apply. Palet Martinez, et al. Informational [Page 8]
RFC 8585 Requirements for IPv6 CE to Support IPv4aaS May 2019 DS-Lite requirements: DSLITE-1: The IPv6 Transition CE Router MUST support configuration of DS-Lite via the DS-Lite DHCPv6 option [RFC6334] ("Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite"). The IPv6 Transition CE Router MAY use other mechanisms to configure DS-Lite parameters. Such mechanisms are outside the scope of this document. DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF [RFC6970]. DSLITE-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE Router SHOULD implement [RFC7291]. If PCP [RFC6887] is implemented and a PCP server is not configured, the IPv6 Transition CE Router MUST assume, by default, that the Address Family Transition Router (AFTR, commonly called "CGN" - Carrier-Grade NAT) is the PCP server. The IPv6 Transition CE Router MUST use plain IPv6 mode (i.e., not IPv4-in-IPv6 encapsulation) to send PCP requests to the server. The term "default" above is to be interpreted as pertaining to a configuration as applied by a vendor prior to the administrator changing it for its initial activation. DSLITE-4: The IPv6 Transition CE Router MUST NOT perform IPv4 Network Address Translation (NAT) on IPv4 traffic encapsulated using DS-Lite [RFC6333]. 3.2.3. Lightweight 4over6 (lw4o6) lw4o6 [RFC7596] specifies an extension to DS-Lite that moves the NAPT function from the DS-Lite tunnel concentrator to the tunnel client located in the IPv6 Transition CE Router, removing the requirement for an AFTR (CGN) function in the tunnel concentrator and reducing the amount of centralized state. The IPv6 Transition CE Router MUST implement lwB4 functionality [RFC7596] if intended for the retail market. If DS-Lite is implemented, lw4o6 SHOULD be implemented as well. If lw4o6 is supported, it MUST be implemented according to [