RFC 8585
Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service
RFC 8585: Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service 🎀
okay bestie, the title block is giving organized 💅 It's RFC 8585, titled "Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service." The category is Informational 🌸 with ISSN 2070-1721, dated May 2019. The authors are J. Palet Martinez (The IPv6 Company), H. M.-H. Liu (D-Link Systems, Inc.), and M. Kawashima (NEC Platforms, Ltd.). The header doesn't list anything it obsoletes or updates ✨
Abstract ✨
okay so this doc is all about keeping IPv4 working for people on IPv6-only connections 🌈 It sets the IPv4 service continuity requirements for IPv6 Customer Edge (CE) routers, whether the service provider hands them out or a vendor sells them at retail 🛍️
It builds on the basic requirements in RFC 7084 so these routers can be set up with IPv6 transition services for IPv4-as-a-Service (IPv4aaS) using new transition mechanisms. It only covers IPv4aaS, meaning transition tech for delivering IPv4 over IPv6-only access networks. IPv4aaS is needed because there aren't enough IPv4 addresses for every possible customer and device 😭 But devices and apps on customer Local Area Networks (LANs) might be IPv4-only or IPv6-only and still need to reach IPv4-only services on the Internet 💀
Status of This Memo
this one is not an Internet Standards Track spec. It's published just for info 📚
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for the details 🙈
For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8585 ✨
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) as in effect on the date of publication. Please read these carefully, because 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 they're 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 . . . . . . . . . . . . . . . . . . . . . . . 211. Introduction ✨
This document defines IPv4 service continuity features over an IPv6-only network for home or small office routers (called "IPv6 Transition CE Routers") 🏠 The goal is an industry baseline for transition features on these routers 🦋
These routers lean on the IPv6 CE router requirements in [RFC7084]. The scope is making sure IPv4 service continuity works for devices on the LAN side 💖 That means remote IPv4-only services stay reachable for both IPv4-only and IPv6-only apps and devices sitting behind an IPv6 Transition CE Router connected to an IPv6-only access network. Those ISP access networks are usually called Wide Area Networks (WANs), even when they're metropolitan or regional 🌍 Figure 1 gives a simplified picture:
+------------+ +------------+ \
| 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
This doc covers the set of IP transition techniques needed when ISPs have, or want to have, an IPv6-only access network 🎀 That's common when there aren't enough IPv4 addresses for every customer and device, which makes IPv4 addresses too expensive. So providers may end up provisioning IPv6-only WAN access. Meanwhile, they still need IPv4-only and IPv6-only devices and apps in customer networks to reach IPv4-only devices and apps on the Internet 🧠
This document specifies the IPv4 service continuity mechanisms to be supported by an IPv6 Transition CE Router, plus the provisioning or configuration info that differs from [RFC7084] 🛠️
This document is not a recommendation for service providers to use any specific transition mechanism 🙅♀️
Automatic provisioning of a more complex topology than a single router with multiple LAN interfaces may be handled by the Home Networking Control Protocol (HNCP) [RFC7788]. That's out of scope for this document 🌸
Since it's impossible to know before 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 from the one in this document, for example features that support only some of the transition mechanisms listed here 💅
Appendices A and B contain a full description of the usage scenarios and the end-user network architecture, respectively. These appendices, along with [RFC7084], will help you understand this document better 📖
1.1. Requirements Language 🔑
The BCP 14 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, exactly as shown here 🔥 Anywhere else they're just regular words 🙈
2. Terminology 📚
This doc uses the same terms as [RFC7084], with a few minor clarifications 💖
"IPv4aaS" stands for "IPv4-as-a-Service," meaning transition technologies for delivering IPv4 over IPv6-only connectivity 🦋
"IPv6 transition Customer Edge Router with IPv4aaS" (shortened to "IPv6 Transition CE Router") is an IPv6 Customer Edge Router that provides features for delivering IPv4 services over an IPv6-only WAN network, including IPv6-IPv4 communications ✨
"WAN Interface" means an IPv6 Transition CE Router's attachment to an IPv6-only link used to connect to a service provider network. It includes link Internet-layer (or higher-layer) tunnels, like 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, described in the following subsections 🎀
3.1. LAN-Side Configuration 🏡
A new LAN requirement is added. It's actually common in regular IPv6 Transition CE Routers, and most of the transition mechanisms require it 🫧
- 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) ✨
okay so the main goal here is IPv6-only WAN access 🌸 That's the main character! But legacy IPv4 stuff still matters, so this doc also covers IPv4-only devices and apps in the customer LANs, plus IPv4-only services on the Internet 💅 Which means both IPv4-only and IPv6-only devices on the customer side of the IPv6 Transition CE Router can reach those IPv4-only services. iconic 🦋
ngl this part is subtle: this doc only configures IPv4aaS inside the IPv6 Transition CE Router itself 🧚 It does not pass that info along to the devices on the LANs. So whether the WAN has native IPv4 or IPv4aaS is totally invisible to the LAN devices ✨
This doc takes no position on running one or several transition mechanisms at the same time, or on running them next to native IPv4 🤷♀️
To keep IPv4 service continuity in the customer LANs and let IPv6 transition mechanisms get provisioned automatically 🎀, these 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. 🍓
So the service provider can disable all the transition mechanisms or pick the most convenient one 👑 To make that happen, the IPv6 Transition CE Router MUST follow these configuration steps:
CONFIG-1:Request the relevant configuration options for each supported transition mechanism, 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. (the exception is the whole point, bestie 🌈)
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. Until then, if an operator provides 464XLAT, it needs to make sure 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 transition mechanism. An IPv6 Transition CE Router intended for the retail market MUST support all of them. no skipping, periodt 💅
3.2.1. 464XLAT
464XLAT [RFC6877] is a technique for providing IPv4 service over an IPv6-only access network without encapsulation ✨ This architecture assumes a Stateful NAT64 [RFC6146] function deployed at the service provider or at 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. 🧚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 with the method defined in [RFC7050] only if the service provider uses DNS64 [RFC6147]. The service provider might not use or trust DNS64 [RFC6147], though, because the DNS configuration at the CE (or at hosts behind the CE) can be changed by the customer 🙈 In that case, the service provider may choose to configure the NAT64 prefix with the option defined in [RFC7225]. That option can also be used when the service provider does use DNS64 [RFC6147]. 🌈
3.2.2. Dual-Stack Lite (DS-Lite)
DS-Lite [RFC6333] keeps IPv4 services going 💜 It lets a broadband service provider share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT). DS-Lite traffic is expected to be 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. 🎀
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]. 🚫 this one's a hard no, bestie 💀
3.2.3. Lightweight 4over6 (lw4o6)
lw4o6 [RFC7596] is an extension to DS-Lite that moves the NAPT function from the DS-Lite tunnel concentrator to the tunnel client in the IPv6 Transition CE Router 🍓 That removes the need for an AFTR (CGN) function in the tunnel concentrator and cuts down on centralized state. big brain energy 🧠✨
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 [RFC7596]. The following IPv6 Transition CE Router requirements also apply. 💅
lw4o6 requirements:
LW4O6-1:The IPv6 Transition CE Router MUST support configuration of lw4o6 via the lw4o6 DHCPv6 options [RFC7598] ("DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients"). The IPv6 Transition CE Router MAY use other mechanisms to configure lw4o6 parameters. Such mechanisms are outside the scope of this document. 🌈LW4O6-2:The IPv6 Transition CE Router MUST support the DHCPv4-over-DHCPv6 (DHCP 4o6) transport described in [RFC7341] ("DHCPv4-over-DHCPv6 (DHCP 4o6) Transport"). 🫶LW4O6-3:The IPv6 Transition CE Router MAY support Dynamic Allocation of Shared IPv4 Addresses as described in [RFC7618] ("Dynamic Allocation of Shared IPv4 Addresses"). 🦋
3.2.4. MAP-E
Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597] is a mechanism for carrying IPv4 packets across an IPv6 network using IP encapsulation 🧚 It includes an algorithmic mechanism for mapping between IPv6 and IPv4 addresses. so clean 😭
The IPv6 Transition CE Router MUST support MAP-E CE functionality [RFC7597] if intended for the retail market. If MAP-E is supported, it MUST be implemented according to [RFC7597]. The following IPv6 Transition CE Router requirements also apply. 💖
MAP-E requirements:
MAPE-1:The IPv6 Transition CE Router MUST support configuration of MAP-E via the MAP-E DHCPv6 options [RFC7598]. The IPv6 Transition CE Router MAY use other mechanisms to configure MAP-E parameters. Such mechanisms are outside the scope of this document. ✨MAPE-2:The IPv6 Transition CE Router MAY support Dynamic Allocation of Shared IPv4 Addresses as described in [RFC7618]. 🌸
3.2.5. MAP-T ✨
okay so MAP-T [RFC7599] is basically MAP-E's bestie 👯♀️ they're super similar, but the big difference is that MAP-T uses IPv4-IPv6 translation instead of encapsulation as the form of IPv6 domain transport 🦋
The IPv6 Transition CE Router MUST support MAP-T CE functionality [RFC7599] if intended for the retail market 🛍️ And if MAP-T is supported, it MUST be implemented according to [RFC7599]. The following IPv6 Transition CE Router requirements also apply too 💅
MAP-T requirements:
MAPT-1: The IPv6 Transition CE Router MUST support configuration of MAP-T via the MAP-T DHCPv6 options [RFC7598]. The IPv6 Transition CE Router MAY use other mechanisms to configure MAP-T parameters. Such mechanisms are outside the scope of this document 🙈
MAPT-2: The IPv6 Transition CE Router MAY support Dynamic Allocation of Shared IPv4 Addresses as described in [RFC7618] 🌸
4. IPv4 Multicast Support 📺
existing IPv4 deployments already support IPv4 multicast for stuff like IPTV, and during the transition phase it's expected that multicast services will still be provided using IPv4 to the customer LANs. the vibes are very "old reliable" 🫶
If the IPv6 Transition CE Router supports delivery of IPv4 multicast services, then it MUST support [RFC8114] ("Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network") and [RFC8115] ("DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes") 🎀
5. UPnP Support 🔌
okay this one is giving strict 😤 If the UPnP WANIPConnection:2 service [UPnP-WANIPC][OCF-IGD] is enabled on a CE router, but it cannot be associated with an IPv4 interface established by an IPv4aaS mechanism, or it cannot determine which ports are available, then an AddPortMapping() or AddAnyPortMapping() action MUST be rejected with error code 729 ("ConflictWithOtherMechanisms"). Port availability could be determined through PCP or access to a configured port set (if the IPv4aaS mechanism limits the available ports) 🧚
An AddPortMapping() request for a port that is not available MUST result in "ConflictInMappingEntry" 💀
An AddAnyPortMapping() request for a port that is not available SHOULD result in a successful mapping with an alternative "NewReservedPort" value from within the configured port set range, or as assigned by PCP as per Section 5.6.1 of [RFC6970] ✨
Note that IGD:1 and its WANIPConnection:1 service have been deprecated by OCF (Open Connectivity Foundation) [OCF-IGD]. so yeah, that's old news now 🙅♀️
6. Comparison to RFC 7084 🆚
This document doesn't include support for 6rd [RFC5969] because it is an IPv6-in-IPv4 tunneling. not it, bestie 🙅♀️
Regarding DS-LITE [RFC6333], this document includes slightly different requirements related to the support of PCP [RFC6887], IGD-PCP IWF [RFC6970], and the prioritization of the transition mechanisms, including dual-stack 🌈
7. Code Considerations 💾
At the time of this writing, one of the apparent main issues for vendors when it comes to including new functionalities, like support for new transition mechanisms, is the lack of space in the flash (or equivalent) memory 😭 However, it has been confirmed from existing open-source implementations (e.g., OpenWRT/LEDE, Linux, and VPP) that adding support for the new transition mechanisms requires around 10-12 KBs, because most of the code base is shared among several transition mechanisms that are already supported by [RFC7084]. A single data plane is common to all of them, which typically means, in popular CEs already in the market [OpenWRT], the new required code is only about 0.15% of the total existing code size. the glow-up is tiny ✨
In general, the new requirements don't have extra cost in terms of RAM memory, nor other hardware requirements such as more powerful CPUs, if compared to the cost of NAT44 code. Thus, existing hardware should be able to support all of them with minimal impact 🫧
The other issue seems to be the cost of developing the code for those new functionalities. However, at the time of writing this document, it has been confirmed that there are several open-source versions of the required code for supporting all the new transition mechanisms, and several vendors already have implementations and have provided them to ISPs. Therefore, the development cost is negligible, and only integration and testing cost may become an issue 🧠
Finally, in some cases, operators supporting several transition mechanisms may need to consider training costs for staff in all the techniques for the operation and management of these mechanisms, even if the costs are not directly caused by supporting this document but because of business decisions. the budget conversations are not it 💸
8. Security Considerations 🔐
This is the serious part, bestie, so pay attention 👑 The IPv6 Transition CE Router must comply with the Security Considerations in [RFC7084] as well as those for each transition mechanism implemented by the IPv6 Transition CE Router.
As described in the Security Considerations of [RFC8026] and [RFC8415], there are generic DHCP security issues, which, in the case of this document, mean that malicious nodes may alter the priority of the transition mechanisms. yikes, the chaos 😱
Access network architecture for securing DHCP within the access network is out of scope for this document. Securing DHCP in the LAN is also not in scope. DHCP packets MUST NOT be forwarded between LAN and WAN interfaces of an IPv6 Transition CE Router. do NOT let DHCP cross the streams 🚫🦋
9. IANA Considerations 📋
This document has no IANA actions. nothing to see here, just vibes 🌸
10. References 📚
10.1. Normative References ✨
Okay bestie, here are the normative refs, the ones the spec literally can't function without 📚💖 Every entry is copied exactly, so you can look them all up.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<https://www.rfc-editor.org/info/rfc5625>.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, DOI 10.17487/RFC5969, August 2010,
<https://www.rfc-editor.org/info/rfc5969>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<https://www.rfc-editor.org/info/rfc6333>.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, DOI 10.17487/RFC6334, August 2011,
<https://www.rfc-editor.org/info/rfc6334>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>.
[RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and
Play (UPnP) Internet Gateway Device - Port Control
Protocol Interworking Function (IGD-PCP IWF)", RFC 6970,
DOI 10.17487/RFC6970, July 2013,
<https://www.rfc-editor.org/info/rfc6970>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", RFC 7225,
DOI 10.17487/RFC7225, May 2014,
<https://www.rfc-editor.org/info/rfc7225>.
[RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
the Port Control Protocol (PCP)", RFC 7291,
DOI 10.17487/RFC7291, July 2014,
<https://www.rfc-editor.org/info/rfc7291>.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
RFC 7341, DOI 10.17487/RFC7341, August 2014,
<https://www.rfc-editor.org/info/rfc7341>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <https://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<https://www.rfc-editor.org/info/rfc7597>.
[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
Configuration of Softwire Address and Port-Mapped
Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,
<https://www.rfc-editor.org/info/rfc7598>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <https://www.rfc-editor.org/info/rfc7599>.
[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M.
Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",
RFC 7618, DOI 10.17487/RFC7618, August 2015,
<https://www.rfc-editor.org/info/rfc7618>.
[RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6
Softwire Customer Premises Equipment (CPE): A DHCPv6-Based
Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026,
November 2016, <https://www.rfc-editor.org/info/rfc8026>.
[RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q.
Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients
over an IPv6 Multicast Network", RFC 8114,
DOI 10.17487/RFC8114, March 2017,
<https://www.rfc-editor.org/info/rfc8114>.
[RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6
Option for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017,
<https://www.rfc-editor.org/info/rfc8115>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.10.2. Informative References 🦋
These are the "good to know" refs, like the background reading that makes the main text make more sense 🧠🌸
[IPv6Survey]
Palet Martinez, J., "Best Current Operational Practice for
operators: IPv6 Prefix Assignment for end-customers --
persistent vs non-persistent and what size to choose",
January 2018,
<https://indico.uknof.org.uk/event/41/contribution/5/
material/slides/0.pdf>.
[OCF-IGD] Open Connectivity Foundation, "Internet Gateway Device
(IGD) V 2.0", March 2015,
<https://openconnectivity.org/developer/specifications/
upnp-resources/upnp/internet-gateway-device-igd-v-2-0>.
[OpenWRT] OpenWRT, "Packages", <https://openwrt.org/packages/start>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <https://www.rfc-editor.org/info/rfc7788>.
[UPnP-IGD]
UPnP Forum, "InternetGatewayDevice:2 Device Template
Version 1.01", December 2010, <http://upnp.org/specs/gw/
UPnP-gw-InternetGatewayDevice-v2-Device.pdf>.
[UPnP-WANIPC]
UPnP Forum, "WANIPConnection:2 Service", September 2010,
<http://upnp.org/specs/gw/
UPnP-gw-WANIPConnection-v2-Service.pdf>.Appendix A. Usage Scenarios 🌈
Okay so this is the "real life" part! 🎀 The whole IPv6 rollout is happening at totally different speeds depending on the country, and even between ISPs in the same country. Every network has its own reasons for moving at its own pace (technical, financial, commercial/marketing, and socio-economic stuff, literally all of it 💅). That means nobody can reliably predict when the global transition will be done, so don't trust anyone who promises a date 🙈
Studies like [IPv6Survey] show that IPv6 deployment is a moving target 🦋 Even inside one country, not every operator is going to offer IPv6 support. Consumers can also switch ISPs and keep using the same IPv6 Transition CE Router, whether the new ISP is IPv4-only or offers IPv6 with IPv4aaS. Main character router energy 👑
So, to handle all of those changing situations, an IPv6 Transition CE Router is required, at least when it comes to transition support 🫶
Now, some services and service providers are going to stay IPv4-only for an undetermined amount of time, which means IPv4 service continuity is required too 😭 So yeah, CEs need to keep supporting IPv4aaS indefinitely, no expiry date 💀
Based on all of that, this document makes sure the IPv6 Transition CE Router can keep transitioning from networks that are dual-stack today, or IPv6-in-IPv4 (as described in [RFC7084]), over to networks that give you IPv6-only access with IPv4aaS ✨
Now the use cases. The IPv6 Transition CE Router described here is expected to show up in residential/household setups, small office, home office (SOHO) setups, and small/medium enterprise (SME) setups 🍓 The everyday stuff is any kind of Internet access (web, email, streaming, online gaming, etc.). The more advanced stuff is inbound connections (IP cameras, web, DNS, email, VPN, etc.) 🎮
This list is just a vibe check, not a complete list of every possible use case 🙈 Combos are totally possible, and so is using the same CE at different times for different scenarios, or even with different IPv4aaSes at different service providers. It's giving flexible 💖
Inbound connections are naturally available in any IPv6 router when you're using IPv6 Global Unicast Addresses (GUAs). The only catch is firewall rules, which can block them and may need some manual configuration 🔥
With IPv4aaS, though, it's a different story. Because private IPv4 addresses and NAT are involved, and depending on the specific transition mechanism, inbound connections usually need a bit more complicated manual setup 😩 Think DMZ, virtual servers, or port/protocol forwarding. Most IPv4 CE Routers already come with a GUI, CLI, or API for doing this by hand, or they can be put into bridge mode so a router sitting behind the original CE handles the inbound connections instead 🧚 The requirements for that kind of support are out of the scope of this document, so that's a different chapter bestie 📚
Who provides the IPv6 Transition CE Router doesn't actually matter here 🤷♀️ In most cases, the service provider handles provisioning and management, at least on the WAN side. The user usually gets to configure the LAN interfaces, firewall, DMZ, and a bunch of other features. But plenty of the time, the user has to supply the router themselves, or is allowed to replace it. That's why it's SO important that IPv6 Transition CE Routers actually fulfil the requirements defined in this document 🫶💜
Last but not least, this IPv6 Transition CE Router is not meant for large enterprises, data centers, content providers, and the like 🏢 Even if the documented requirements happen to cover what they need, they may have extra requirements that are out of the scope of this document. Not every party is invited to this slumber party 😌
Appendix B. End-User Network Architecture ✨
okay so an end-user network will likely run both IPv4 and IPv6 (see Section 1 and Appendix A) 💅. end users are not expected to rebuild their whole network topology just because IPv6 showed up 🙈. there are some differences in how IPv6 works and gets provisioned, and those differences do have implications for the network architecture, so we gotta talk about them 🦋.
a typical IPv4 end-user network is a "plug and play" router with NAT functionality and a single link upstream, connected to the service provider network 🎀.
from the point of view of an IPv4 user behind an IPv6 Transition CE Router? literally no change ✨.
but here's the tea 🍵. a typical IPv4 NAT setup blocks all incoming connections by default, though it may let you open ports using a Universal Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD][OCF-IGD] or some other firewall control protocol. with IPv6-only access and IPv4aaS, that might not be doable, depending on the specific transition mechanism details 😭. PCP [RFC6887] could be an alternative solution 🧚.
another perk of using IPv4 private address space in the end-user network is stable addressing. like, it doesn't change even when you switch service providers, and the addresses stay usable even when the WAN interface is down or the customer edge router hasn't been provisioned yet 🌸. with IPv6-only access, private IPv4 addresses are still around too, as long as the IPv4aaS transition mechanism keeps running the NAT interface toward the LAN side when the WAN interface is down 💜.
more advanced routers support dynamic routing (they learn routes from other routers), and advanced end users can build seriously complex networks by manually configuring address prefixes together with a dynamic routing protocol 👑. once again, this is true for both IPv4 and IPv6 ✨.
overall, the end-user network architecture for IPv6 should provide equivalent or better capabilities and functionality than the current IPv4 architecture 🌈.
the end-user network is a stub network, in the sense that it is not providing transit to other external networks. however, HNCP [RFC7788] allows support for automatic provisioning of downstream routers 🍓. Figure 2 shows the model topology for the end-user network 👇.
+---------------+ \
| Service | \
| Provider | \
| Router | | Service
+-------+-------+ | Provider
| IPv6-only | Network
| Customer /
| Internet Connection /
| /
+------+--------+ \
| IPv6 | \
| Transition CE | \
| Router | |
+---+-------+---+ |
Network A | | Network B |
-+----------------+-+- -+---+-------------+- |
| | | | |
+---+------+ | +----+-----+ +-----+----+ |
| IPv6 | | | IPv4 | |IPv4/IPv6 | |
| Host | | | Host | | Host | |
+----------+ | +----------+ +----------+ | End-User
| | Network(s)
+------+--------+ |
| IPv6 | |
| Router | |
+------+--------+ |
Network C | |
-+-------------+--+- |
| | |
+---+------+ +----+-----+ |
| IPv6 | | IPv6 | /
| Host | | Host | /
+----------+ +----------+ /Figure 2: Example of a Typical End-User Network
this architecture describes the:
- Basic capabilities of the IPv6 Transition CE Router
- Provisioning of the WAN interface connecting to the service provider
- Provisioning of the LAN interfaces
the IPv6 Transition CE Router may be manually configured in an arbitrary topology with a dynamic routing protocol or HNCP [RFC7788]. automatic provisioning and configuration are described for a single IPv6 Transition CE Router only 🎯.
Acknowledgements 🫶
thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian Carpenter, Lorenzo Colitti, Alejandro D'Egidio, Ian Farrer, Lee Howard, Richard Patterson, Barbara Stark, Ole Troan, and James Woodyatt for their review and comments in this and/or previous draft versions of this document 💖. thanks also for the Last Call reviews by Dan Romascanu (OPS-DIR); Christian Huitema (SEC-DIR); Daniele Ceccarelli (RTG-DIR); Martin Stiemerling (TSV-ART); Matthew Miller (Gen-ART); and Alissa Cooper, Benjamin Kaduk, Suresh Krishnan, Ben Campbell, Spencer Dawkins, Mirja Kuhlewind, and Adam Roach (all IESG) 👑🌟.
Authors' Addresses 🦋
Jordi Palet Martinez
The IPv6 Company
Molino de la Navata, 75
La Navata - Galapagar, Madrid 28420
Spain
Email: jordi.palet@theipv6company.com
URI: http://www.theipv6company.com/Hans M.-H. Liu
D-Link Systems, Inc.
17595 Mount Herrmann St.
Fountain Valley, California 92708
United States of America
Email: hans.liu@dlinkcorp.com
URI: https://www.dlink.com/Masanobu Kawashima
NEC Platforms, Ltd.
2-3, Kanda-Tsukasamachi
Chiyoda-ku, Tokyo 101-8532
Japan
Email: kawashimam@vx.jp.nec.com
URI: https://www.necplatforms.co.jp/en/📦 where this page comes from
- ietf: rfc8585 2019-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms