draft-ietf-v6ops-transition-ipv4aas-13.txt   draft-ietf-v6ops-transition-ipv4aas-14.txt 
IPv6 Operations (v6ops) J. Palet Martinez IPv6 Operations (v6ops) J. Palet Martinez
Internet-Draft The IPv6 Company Internet-Draft The IPv6 Company
Intended status: Informational H. M.-H. Liu Intended status: Informational H. M.-H. Liu
Expires: July 14, 2019 D-Link Systems, Inc. Expires: July 18, 2019 D-Link Systems, Inc.
M. Kawashima M. Kawashima
NEC Platforms, Ltd. NEC Platforms, Ltd.
January 10, 2019 January 14, 2019
Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity
as-a-Service as-a-Service
draft-ietf-v6ops-transition-ipv4aas-13 draft-ietf-v6ops-transition-ipv4aas-14
Abstract Abstract
This document specifies the IPv4 service continuity requirements for This document specifies the IPv4 service continuity requirements for
an IPv6 Customer Edge (CE) router, either provided by the service an IPv6 Customer Edge (CE) router, either provided by the service
provider or by vendors who sell through the retail market. provider or by vendors who sell through the retail market.
Specifically, this document extends the "Basic Requirements for IPv6 Specifically, this document extends the "Basic Requirements for IPv6
Customer Edge Routers" (RFC7084) in order to allow the provisioning Customer Edge Routers" (RFC7084) in order to allow the provisioning
of IPv6 transition services for the support of "IPv4 as-a-Service" of IPv6 transition services for the support of "IPv4 as-a-Service"
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 14, 2019. This Internet-Draft will expire on July 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language - Special Note . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. LAN-Side Configuration . . . . . . . . . . . . . . . . . 6 3.1. LAN-Side Configuration . . . . . . . . . . . . . . . . . 6
3.2. Transition Technologies Support for IPv4 Service 3.2. Transition Technologies Support for IPv4 Service
Continuity (IPv4 as-a-Service - IPv4aaS) . . . . . 6 Continuity (IPv4 as-a-Service - IPv4aaS) . . . . . 6
3.2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 9 3.2.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 8
3.2.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 10 3.2.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 9
3.2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 11
4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 11 4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 11
5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 12 5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Comparison to RFC7084 . . . . . . . . . . . . . . . . . . . . 12 6. Comparison to RFC7084 . . . . . . . . . . . . . . . . . . . . 12
7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. Annex A: Usage Scenarios . . . . . . . . . . . . . . . . . . 14 11. Annex A: Usage Scenarios . . . . . . . . . . . . . . . . . . 14
12. Annex B: End-User Network Architecture . . . . . . . . . . . 15 12. Annex B: End-User Network Architecture . . . . . . . . . . . 15
13. ANNEX C: Changes from -00 . . . . . . . . . . . . . . . . . . 18 13. ANNEX C: Changes from -00 . . . . . . . . . . . . . . . . . . 18
14. ANNEX D: Changes from -01 . . . . . . . . . . . . . . . . . . 18 14. ANNEX D: Changes from -01 . . . . . . . . . . . . . . . . . . 18
15. ANNEX E: Changes from -02 . . . . . . . . . . . . . . . . . . 18 15. ANNEX E: Changes from -02 . . . . . . . . . . . . . . . . . . 18
16. ANNEX F: Changes from -03 . . . . . . . . . . . . . . . . . . 19 16. ANNEX F: Changes from -03 . . . . . . . . . . . . . . . . . . 19
17. ANNEX G: Changes from -04 . . . . . . . . . . . . . . . . . . 19 17. ANNEX G: Changes from -04 . . . . . . . . . . . . . . . . . . 19
18. ANNEX H: Changes from -05 . . . . . . . . . . . . . . . . . . 19 18. ANNEX H: Changes from -05 . . . . . . . . . . . . . . . . . . 19
19. ANNEX I: Changes from -06 . . . . . . . . . . . . . . . . . . 19 19. ANNEX I: Changes from -06 . . . . . . . . . . . . . . . . . . 19
20. ANNEX J: Changes from -07 . . . . . . . . . . . . . . . . . . 19 20. ANNEX J: Changes from -07 . . . . . . . . . . . . . . . . . . 19
21. ANNEX K: Changes from -08, -09 and -10 . . . . . . . . . . . 20 21. ANNEX K: Changes from -08, -09 and -10 . . . . . . . . . . . 20
22. ANNEX L: Changes from -11 and -12 . . . . . . . . . . . . . . 20 22. ANNEX L: Changes from -11, -12 and -13 . . . . . . . . . . . 20
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
23.1. Normative References . . . . . . . . . . . . . . . . . . 20 23.1. Normative References . . . . . . . . . . . . . . . . . . 20
23.2. Informative References . . . . . . . . . . . . . . . . . 23 23.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document defines IPv4 service continuity features over an This document defines IPv4 service continuity features over an
IPv6-only network, for a residential or small-office router, referred IPv6-only network, for a residential or small-office router, referred
to as an "IPv6 Transition CE Router", in order to establish an to as an "IPv6 Transition CE Router", in order to establish an
industry baseline for transition features to be implemented on such a industry baseline for transition features to be implemented on such a
router. router.
These routers rely upon "Basic Requirements for IPv6 Customer Edge These routers rely upon "Basic Requirements for IPv6 Customer Edge
Routers" [RFC7084]. The scope of this document is to ensure the IPv4 Routers" [RFC7084]. The scope of this document is to ensure the IPv4
"service continuity" support, for devices in the LAN side. This "service continuity" support, for devices in the LAN side. This
ensures that remote IPv4-only services continue to be accessible, ensures that remote IPv4-only services continue to be accessible,
from an IPv6-only Internet Service Provider access network (typically from an IPv6-only Internet Service Provider (ISP) access network from
referred as WAN - Wide Area Network, even if in some cases it may be both, IPv4-only and IPv6-only applications and devices in the LAN
metropolitan, regional, etc.), from both, IPv4-only and IPv6-only side. These ISP access networks are typically referred to as Wide
applications or devices in the LAN side. Area Networks (WANs), even if in some cases they may be metropolitan
or regional. Figure 1 presents a simplified view of this
architecture.
+------------+ +------------+ \ +------------+ +------------+ \
| IPv4-only | | IPv4/IPv6 | \ | IPv4-only | | IPv4/IPv6 | \
| Remote | | Remote | | | Remote | | Remote | |
| Host | | Host | | Internet | Host | | Host | | Internet
+--------+---+ +---+--------+ | +--------+---+ +---+--------+ |
| | / | | /
| | / | | /
+-+-----------+-+ \ +-+-----------+-+ \
| Service | \ | Service | \
skipping to change at page 4, line 37 skipping to change at page 4, line 37
-+----------------+- -+-----+-------------+- | Network(s) -+----------------+- -+-----+-------------+- | Network(s)
| | | | | | | |
+---+------+ +----+-----+ +-----+----+ | +---+------+ +----+-----+ +-----+----+ |
| IPv6-only| | IPv4-only| |IPv4/IPv6 | / | IPv6-only| | IPv4-only| |IPv4/IPv6 | /
| Host | | Host | | Host | / | Host | | Host | | Host | /
+----------+ +----------+ +----------+ / +----------+ +----------+ +----------+ /
Figure 1: Simplified Typical IPv6-only Access Network Figure 1: Simplified Typical IPv6-only Access Network
This document covers a set of IP transition techniques required when This document covers a set of IP transition techniques required when
ISPs (Internet Service Providers) have, or want to have, an IPv6-only ISPs have, or want to have, an IPv6-only access network. This is a
access network. This is a common situation when sufficient IPv4 common situation when sufficient IPv4 addresses are no longer
addresses are no longer available for every possible customer and available for every possible customer and device, causing IPv4
device, causing IPv4 addresses to become prohibitively expensive. addresses to become prohibitively expensive. This, in turn, may
This, in turn, may result in service providers provisioning IPv6-only result in service providers provisioning IPv6-only WAN access. At
WAN access. At the same time, they need to ensure that both the same time, they need to ensure that both IPv4-only and IPv6-only
IPv4-only and IPv6-only devices or applications in the customer devices and applications in the customer networks can still reach
networks can still reach IPv4-only devices and applications in the IPv4-only devices and applications in the Internet.
Internet.
This document specifies the IPv4 service continuity mechanisms to be This document specifies the IPv4 service continuity mechanisms to be
supported by an IPv6 Transition CE Router, and relevant provisioning supported by an IPv6 Transition CE Router, and relevant provisioning
or configuration information differences from [RFC7084]. or configuration information differences from [RFC7084].
This document is not a recommendation for service providers to use This document is not a recommendation for service providers to use
any specific transition mechanism. any specific transition mechanism.
Automatic provisioning of more complex topology than a single router Automatic provisioning of more complex topology than a single router
with multiple LAN interfaces may be handled by means of HNCP with multiple LAN interfaces may be handled by means of HNCP
[RFC7788] (Home Networking Control Protocol), which is out of the [RFC7788] (Home Networking Control Protocol), which is out of the
scope of this document. scope of this document.
Since it is impossible to know prior to sale which transition Since it is impossible to know prior to sale which transition
mechanism a device will need over its lifetime, an IPv6 Transition CE mechanism a device will need over its lifetime, an IPv6 Transition CE
Router intended for the retail market MUST support all the IPv4aaS Router intended for the retail market MUST support all the IPv4aaS
transition mechanisms supported by this document. Service providers transition mechanisms listed in this document. Service providers who
who specify feature sets for the IPv6 Transition CE Router, may specify feature sets for the IPv6 Transition CE Router, may define a
define a different set of features than those included in this different set of features than those included in this document, for
document, for example supporting only some of the transition example supporting only some of the transition mechanisms enumerated
mechanisms enumerated in this document. in this document.
A complete description of "Usage Scenarios" and "End-User Network A complete description of "Usage Scenarios" and "End-User Network
Architecture" is provided in Annexes A and B, respectively, which Architecture" is provided in Annexes A and B, respectively, which
together with [RFC7084], will facilitate the reader to have a clearer together with [RFC7084], will facilitate the reader to have a clearer
understanding of this document. understanding of this document.
1.1. Requirements Language - Special Note 1.1. Requirements Language
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document, are not used as described in [RFC2119]. When these words
aren't capitalized, they have their normal English meaning, as per
[RFC8174]. This document uses these keywords not strictly for the
purpose of interoperability, but rather for the purpose of
establishing industry-common baseline functionality. As such, the
document points to several other specifications to provide additional
guidance to implementers regarding any protocol implementation
required to produce a successful IPv6 Transition CE Router that
interoperates successfully with a particular subset of currently
deploying and planned common IPv6-only access networks.
Additionally, the keyword "DEFAULT" is to be interpreted in this The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
document as pertaining to a configuration as applied by a vendor, "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
prior to the administrator changing it for its initial activation. "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology 2. Terminology
This document uses the same terms as in [RFC7084], with minor This document uses the same terms as in [RFC7084], with minor
clarifications. clarifications.
"IPv4aaS" stands for "IPv4 as-a-Service", meaning transition "IPv4aaS" stands for "IPv4 as-a-Service", meaning transition
technologies for delivering IPv4 in IPv6-only connectivity. technologies for delivering IPv4 in IPv6-only connectivity.
The term "IPv6 transition Customer Edge Router with IPv4aaS" The term "IPv6 transition Customer Edge Router with IPv4aaS"
skipping to change at page 6, line 48 skipping to change at page 6, line 40
Note that this document is only configuring the IPv4aaS in the IPv6 Note that this document is only configuring the IPv4aaS in the IPv6
Transition CE Router itself, and not forwarding such information to Transition CE Router itself, and not forwarding such information to
devices attached to the LANs, so the WAN configuration, availability devices attached to the LANs, so the WAN configuration, availability
of native IPv4 or IPv4aaS, is transparent for them. of native IPv4 or IPv4aaS, is transparent for them.
This document takes no position on simultaneous operation of one or This document takes no position on simultaneous operation of one or
several transition mechanisms and/or native IPv4. several transition mechanisms and/or native IPv4.
In order to seamlessly provide IPv4 service continuity in the In order to seamlessly provide IPv4 service continuity in the
customer LANs, and allow an automated IPv6 transition mechanism customer LANs, and allow automated IPv6 transition mechanism
provisioning, the following general transition requirements are provisioning, the following general transition requirements are
defined. defined.
General transition requirements: General transition requirements:
TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46 TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46
priority options described in [RFC8026] (Unified IPv4-in- priority options described in [RFC8026] (Unified IPv4-in-
IPv6 Softwire Customer Premises Equipment (CPE): A IPv6 Softwire Customer Premises Equipment (CPE): A
DHCPv6-Based Prioritization Mechanism). DHCPv6-Based Prioritization Mechanism).
TRANS-2: The IPv6 Transition CE Router MUST have a GUI, CLI and/or TRANS-2: The IPv6 Transition CE Router MUST have a GUI and either a
API option to manually enable/disable each of the supported CLI or API (or both) to manually enable/disable each of the
transition mechanisms. supported transition mechanisms.
TRANS-3: If an IPv6 Transition CE Router supports more than one LAN TRANS-3: If an IPv6 Transition CE Router supports more than one LAN
subnet, the IPv6 Transition CE Router MUST allow subnet, the IPv6 Transition CE Router MUST allow
appropriate subnetting and configuring the address space appropriate subnetting and configuration of the address
(which may depend on each transition mechanism) among the space among the several interfaces. In some transition
several interfaces. In some transition mechanisms, this mechanisms, this may require differentiating mappings/
may require differentiating mappings/translations per translations on a per-interface basis.
interfaces.
In order to allow the service provider to disable all the transition In order to allow the service provider to disable all the transition
mechanisms and/or choose the most convenient one, the IPv6 Transition mechanisms and/or choose the most convenient one, the IPv6 Transition
CE Router MUST follow the following configuration steps: CE Router MUST follow the following configuration steps:
CONFIG-1: Request the relevant configuration options for each CONFIG-1: Request the relevant configuration options for each
supported transition mechanisms, which MUST remain supported transition mechanisms, which MUST remain
disabled at this step. disabled at this step.
CONFIG-2: Following Section 1.4 of [RFC8026], MUST check for a valid CONFIG-2: Following Section 1.4 of [RFC8026], MUST check for a valid
skipping to change at page 8, line 9 skipping to change at page 7, line 47
Protocol Translation from IPv6 Clients to IPv4 Servers) function Protocol Translation from IPv6 Clients to IPv4 Servers) function
deployed at the service provider or a third-party network. deployed at the service provider or a third-party network.
The IPv6 Transition CE Router MUST support CLAT functionality The IPv6 Transition CE Router MUST support CLAT functionality
[RFC6877] if intended for the retail market. If 464XLAT is [RFC6877] if intended for the retail market. If 464XLAT is
supported, it MUST be implemented according to [RFC6877]. The supported, it MUST be implemented according to [RFC6877]. The
following IPv6 Transition CE Router requirements also apply: following IPv6 Transition CE Router requirements also apply:
464XLAT requirements: 464XLAT requirements:
464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Network 464XLAT-1: Unless a dedicated /64 prefix has been acquired, either
Address Translation (NAT) on IPv4 traffic translated using DHCPv6-PD [RFC8415] (IPv6 Prefix Options for
using the CLAT, unless a dedicated /64 prefix has been DHCPv6) or by alternative means, the IPv6 Transition CE
acquired, either using DHCPv6-PD [RFC8415] (IPv6 Prefix Router MUST perform IPv4 Network Address Translation
Options for DHCPv6) or by alternative means. (NAT) on IPv4 traffic translated using the CLAT.
464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF 464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF
[RFC6970] (UPnP Internet Gateway Device - Port Control [RFC6970] (UPnP Internet Gateway Device - Port Control
Protocol Interworking Function). Protocol Interworking Function).
464XLAT-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE 464XLAT-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE
Router MUST also implement [RFC7291] (DHCP Options for Router MUST also implement [RFC7291] (DHCP Options for
the PCP). Following [RFC6887], if no PCP server is the PCP). Following [RFC6887], if no PCP server is
configured, the IPv6 Transition CE Router MAY verify if configured, the IPv6 Transition CE Router MAY verify if
the default gateway, or the NAT64 is the PCP server. the default gateway, or the NAT64 is the PCP server. The
Plain IPv6 mode (i.e., no IPv4-in-IPv6 encapsulation is IPv6 Transition CE Router MUST use plain IPv6 mode (i.e.,
used) MUST be used to send PCP requests to the server. no IPv4-in-IPv6 encapsulation is used) to send PCP
requests to the server.
464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050]
(Discovery of the IPv6 Prefix Used for IPv6 Address (Discovery of the IPv6 Prefix Used for IPv6 Address
Synthesis) in order to discover the PLAT-side translation Synthesis) in order to discover the PLAT-side translation
IPv4 and IPv6 prefix(es)/suffix(es). IPv4 and IPv6 prefix(es)/suffix(es).
464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST 464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST
follow [RFC7225] (Discovering NAT64 IPv6 Prefixes Using follow [RFC7225] (Discovering NAT64 IPv6 Prefixes Using
the PCP), in order to learn the PLAT-side translation the PCP), in order to learn the PLAT-side translation
IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream
PCP-controlled NAT64 device. PCP-controlled NAT64 device.
464XLAT-6: [RFC8115] MUST be implemented and a DHCPv6 Option 464XLAT-6: The priority for the NAT64 prefix, in case the network
"OPTION_V6_PREFIX64" [RFC8115], with zeroed ASM_mPrefix64
and SSM_mPrefix64, MUST also be considered as a valid
NAT64 prefix (uPrefix64).
464XLAT-7: The priority for the NAT64 prefix, in case the network
provides several choices, MUST be: 1) [RFC7225], 2) provides several choices, MUST be: 1) [RFC7225], 2)
[RFC8115], and 3) [RFC7050]. [RFC7050].
464XLAT-8: If a DHCPv6 Option "OPTION_V6_PREFIX64" [RFC8115], with 464XLAT-7: If one or more NAT64 prefixes are learnt by means of
zeroed ASM_mPrefix64 and SSM_mPrefix64 provides a NAT64 either [RFC7225] or [RFC7050], then 464XLAT MUST be
prefix, or one or more NAT64 prefixes are learnt by means
of either [RFC7050] or [RFC7225], then 464XLAT MUST be
included in the candidate list of possible S46 mechanism included in the candidate list of possible S46 mechanism
(Section 1.4.1 of [RFC8026]). (Section 1.4.1 of [RFC8026]).
The NAT64 prefix could be discovered by means of [RFC7050] only in The NAT64 prefix could be discovered by means of [RFC7050] only in
the case the service provider uses DNS64 [RFC6147]. If DNS64 the case the service provider uses DNS64 [RFC6147]. It may be the
[RFC6147] is not used, or not trusted, as the DNS configuration at case that the service provider does not use or does not trust DNS64
the CE (or hosts behind the CE) may be modified by the customer, then [RFC6147] because the DNS configuration at the CE (or hosts behind
the service provider may opt to configure the NAT64 prefix either by the CE) can be modified by the customer. In that case, the service
means of [RFC7225] or [RFC8115], which also can be used if the provider may opt to configure the NAT64 prefix by means of [RFC7225].
service provider uses DNS64 [RFC6147]. This can also be used if the service provider uses DNS64 [RFC6147].
3.2.2. Dual-Stack Lite (DS-Lite) 3.2.2. Dual-Stack Lite (DS-Lite)
Dual-Stack Lite [RFC6333] enables continued support for IPv4 Dual-Stack Lite [RFC6333] enables continued support for IPv4
services. Dual-Stack Lite enables a broadband service provider to services. Dual-Stack Lite enables a broadband service provider to
share IPv4 addresses among customers by combining two well-known share IPv4 addresses among customers by combining two well-known
technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation
(NAT). It is expected that DS-Lite traffic is forwarded over the (NAT). It is expected that DS-Lite traffic is forwarded over the
IPv6 Transition CE Router's native IPv6 WAN interface, and not IPv6 Transition CE Router's native IPv6 WAN interface, and not
encapsulated in another tunnel. encapsulated in another tunnel.
skipping to change at page 9, line 46 skipping to change at page 9, line 29
document. document.
DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF
[RFC6970] (UPnP Internet Gateway Device - Port Control [RFC6970] (UPnP Internet Gateway Device - Port Control
Protocol Interworking Function). Protocol Interworking Function).
DSLITE-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE DSLITE-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE
Router SHOULD implement [RFC7291] (DHCP Options for the Router SHOULD implement [RFC7291] (DHCP Options for the
PCP). If PCP [RFC6887] is implemented and a PCP server is PCP). If PCP [RFC6887] is implemented and a PCP server is
not configured, the IPv6 Transition CE Router MUST assume, not configured, the IPv6 Transition CE Router MUST assume,
by DEFAULT, that the AFTR is the PCP server. Plain IPv6 by default, that the AFTR is the PCP server. The IPv6
mode (i.e., no IPv4-in-IPv6 encapsulation is used) MUST be Transition CE Router MUST use plain IPv6 mode (i.e., no
used to send PCP requests to the server. IPv4-in-IPv6 encapsulation is used) 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 DSLITE-4: The IPv6 Transition CE Router MUST NOT perform IPv4
Network Address Translation (NAT) on IPv4 traffic Network Address Translation (NAT) on IPv4 traffic
encapsulated using DS-Lite [RFC6333]. encapsulated using DS-Lite [RFC6333].
3.2.3. Lightweight 4over6 (lw4o6) 3.2.3. Lightweight 4over6 (lw4o6)
lw4o6 [RFC7596] specifies an extension to DS-Lite which moves the lw4o6 [RFC7596] specifies an extension to DS-Lite which moves the
NAPT function from the DS-Lite tunnel concentrator to the tunnel NAPT function from the DS-Lite tunnel concentrator to the tunnel
client located in the IPv6 Transition CE Router, removing the client located in the IPv6 Transition CE Router, removing the
skipping to change at page 12, line 39 skipping to change at page 12, line 26
This document doesn't include support for 6rd [RFC5969], because it This document doesn't include support for 6rd [RFC5969], because it
is an IPv6-in-IPv4 tunneling. is an IPv6-in-IPv4 tunneling.
Regarding DS-LITE [RFC6333], this document includes slightly Regarding DS-LITE [RFC6333], this document includes slightly
different requirements, related to the support of PCP [RFC6887], IGD- different requirements, related to the support of PCP [RFC6887], IGD-
PCP IWF [RFC6970] and the prioritization of the transition PCP IWF [RFC6970] and the prioritization of the transition
mechanisms, including dual-stack. mechanisms, including dual-stack.
7. Code Considerations 7. Code Considerations
One of the apparent main issues for vendors to include new At the time of this writing, one of the apparent main issues for
functionalities, such as support for new transition mechanisms, is vendors to include new functionalities, such as support for new
the lack of space in the flash (or equivalent) memory. However, it transition mechanisms, is the lack of space in the flash (or
has been confirmed from existing open source implementations equivalent) memory. However, it has been confirmed from existing
(OpenWRT/LEDE, Linux, VPP, others), that adding the support for the open source implementations (OpenWRT/LEDE, Linux, VPP, others), that
new transitions mechanisms, requires around 10-12 Kbytes, because adding the support for the new transitions mechanisms, requires
most of the code base is shared among several transition mechanisms, around 10-12 Kbytes, because most of the code base is shared among
which are already supported by [RFC7084]. A single data plane is several transition mechanisms, which are already supported by
common to all them, which typically means, in popular CEs already in [RFC7084]. A single data plane is common to all them, which
the market [OpenWRT], about 0,15% of the existing code size. 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.
In general, the new requirements don't have extra cost in terms of In general, the new requirements don't have extra cost in terms of
RAM memory, nor other hardware requirements such as more powerful RAM memory, nor other hardware requirements such as more powerful
CPUs, if compared to the cost of NAT44 code, so existing hardware CPUs, if compared to the cost of NAT44 code, so existing hardware
should support all them with minimal impact. should be able to support all them with minimal impact.
The other issue seems to be the cost of developing the code for those The other issue seems to be the cost of developing the code for those
new functionalities. However, at the time of writing this document, new functionalities. However, at the time of writing this document,
it has been confirmed that there are several open source versions of it has been confirmed that there are several open source versions of
the required code for supporting all the new transition mechanisms, the required code for supporting all the new transition mechanisms,
and several vendors already have implementations and provide it to and several vendors already have implementations and provide it to
ISPs, so the development cost is negligible, and only integration and ISPs, so the development cost is negligible, and only integration and
testing cost may become an issue. testing cost may become an issue.
Finally, in some cases, operators supporting several transition Finally, in some cases, operators supporting several transition
mechanisms may need to consider training costs for staff in all those mechanisms may need to consider training costs for staff in all the
techniques for their operation and management, even if this is not techniques for their operation and management, even if this is not
directly caused by supporting this document, but because the business directly caused by supporting this document, but because the business
decisions behind that. decisions behind that.
8. Security Considerations 8. Security Considerations
The IPv6 Transition CE Router must comply with the Security The IPv6 Transition CE Router must comply with the Security
Considerations as stated in [RFC7084], as well as those stated by Considerations as stated in [RFC7084], as well as those stated by
each transition mechanism implemented by the IPv6 Transition CE each transition mechanism implemented by the IPv6 Transition CE
Router. Router.
skipping to change at page 14, line 13 skipping to change at page 13, line 52
Table 1: DHCPv6 Option Code for 464XLAT Table 1: DHCPv6 Option Code for 464XLAT
10. Acknowledgements 10. Acknowledgements
Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian
Carpenter, Ian Farrer, Lee Howard, Richard Patterson, Barbara Stark, Carpenter, Ian Farrer, Lee Howard, Richard Patterson, Barbara Stark,
Ole Troan, James Woodyatt, Lorenzo Colitti and Alejandro D'Egidio, Ole Troan, James Woodyatt, Lorenzo Colitti and Alejandro D'Egidio,
for their review and comments in this and/or previous versions of for their review and comments in this and/or previous versions of
this document, as well as to the Last Call reviewers by the Ops-dir this document, as well as to the Last Call reviewers by the Ops-dir
(Dan Romascanu), Sec-dir (Christian Huitema), Rtg-dir (Daniele (Dan Romascanu), Sec-dir (Christian Huitema), Rtg-dir (Daniele
Ceccarelli), Tsv-art (Martin Stiemerling) and Gen-art (Matthew Ceccarelli), Tsv-art (Martin Stiemerling), Gen-art (Matthew Miller)
Miller). and IESG (Alissa Cooper, Benjamin Kaduk, Suresh Krishnan, Ben
Campbell, Spencer Dawkins, Mirja Kuhlewind, and Adam Roach).
11. Annex A: Usage Scenarios 11. Annex A: Usage Scenarios
The situation previously described, where there is ongoing IPv6 The situation previously described, where there is ongoing IPv6
deployment and lack of IPv4 addresses, is not happening at the same deployment and lack of IPv4 addresses, is not happening at the same
pace in every country, and even within every country, every ISP. For pace in every country, and even within every country, for every ISP.
different technical, financial, commercial/marketing and socio- For different technical, financial, commercial/marketing and socio-
economic reasons, each network is transitioning at their own pace; economic reasons, each network is transitioning at their own pace;
the global transition timings cannot be estimated. the global transition timings cannot be reliably estimated.
Different studies (for example [IPv6Survey]) also show that the IPv6 Different studies (for example [IPv6Survey]) also show that the IPv6
deployment is a changing situation. In a single country, not all deployment is a changing situation. In a single country, not all
operators will necessarily provide IPv6 support. Consumers may also operators will necessarily provide IPv6 support. Consumers may also
switch ISPs, and use the same IPv6 Transition CE Router with either switch ISPs, and use the same IPv6 Transition CE Router with either
an ISP that provides IPv4-only or an ISP that provides IPv6 with an ISP that provides IPv4-only or an ISP that provides IPv6 with
IPv4aaS. IPv4aaS.
So, to cover all those evolving situations, an IPv6 Transition CE So, to cover all those evolving situations, an IPv6 Transition CE
Router is required, at least from the perspective of the transition Router is required, at least from the perspective of the transition
skipping to change at page 15, line 7 skipping to change at page 14, line 47
IPv6-only access with IPv4-as-a-Service. IPv6-only access with IPv4-as-a-Service.
Considering that situation and different possible usage cases, the Considering that situation and different possible usage cases, the
IPv6 Transition CE Router described in this document is expected to IPv6 Transition CE Router described in this document is expected to
be used typically, in residential/household, Small Office/Home Office be used typically, in residential/household, Small Office/Home Office
(SOHO) and Small/Medium Enterprise (SME). Common usage is any kind (SOHO) and Small/Medium Enterprise (SME). Common usage is any kind
of Internet access (web, email, streaming, online gaming, etc.) and of Internet access (web, email, streaming, online gaming, etc.) and
even more advanced requirements including inbound connections (IP even more advanced requirements including inbound connections (IP
cameras, web, DNS, email, VPN, etc.). cameras, web, DNS, email, VPN, etc.).
The above is not intended to be comprehensive list of all the The above is not intended to be a comprehensive list of all the
possible usage cases, just an overall view. In fact, combinations of possible usage cases, just an overall view. In fact, combinations of
the above usages are also possible, as well as situations where the the above usages are also possible, as well as situations where the
same CE is used at different times in different scenarios or even same CE is used at different times in different scenarios or even
different services providers that may use a different transition different with services providers that may use a different transition
mechanism. mechanism.
The mechanisms for allowing inbound connections are "naturally" The mechanisms for allowing inbound connections are "naturally"
available in any IPv6 router, when using GUA (IPv6 Global Unicast available in any IPv6 router when using GUA (IPv6 Global Unicast
Addresses), unless they are blocked by firewall rules, which may Addresses), unless they are blocked by firewall rules, which may
require some manual configuration by means of a GUI, CLI and/or API. require some manual configuration.
However, in the case of IPv4aaS, because the usage of private However, in the case of IPv4aaS, because the usage of private
addresses and NAT and even depending on the specific transition addresses and NAT and even depending on the specific transition
mechanism, inbound connections typically require some degree of more mechanism, inbound connections typically require some degree of more
complex manual configuration such as setting up a DMZ, virtual complex manual configuration such as setting up a DMZ, virtual
servers, or port/protocol forwarding. In general, IPv4 CE Routers servers, or port/protocol forwarding. In general, IPv4 CE Routers
already provide a GUI and/or a CLI to manually configure them, or the already provide a GUI, CLI or API to manually configure them, or the
possibility to setup the CE in bridge mode, so another CE behind it possibility to setup the CE in bridge mode, so another CE behind it
takes care of that. The requirements for that support are out of the takes care of that. The requirements for that support are out of the
scope of this document. scope of this document.
It is not relevant who provides the IPv6 Transition CE Router. In It is not relevant who provides the IPv6 Transition CE Router. In
most of the cases is the service provider, and in fact is most of the cases it is the service provider, and in fact they are
responsible, typically, of provisioning/managing at least the WAN responsible, typically, of provisioning/managing at least the WAN
side. Commonly, the user has access to configure the LAN interfaces, side. Commonly, the user has access to configure the LAN interfaces,
firewall, DMZ, and many other features. However, in many cases, the firewall, DMZ, and many other features. However, in many cases, the
user must supply or may replace the IPv6 Transition CE Router. This user must supply or may replace the IPv6 Transition CE Router. This
underscores the importance of the IPv6 Transition CE Routers underscores the importance of the IPv6 Transition CE Routers
supporting the same requirements defined in this document. fulfilling the same requirements defined in this document.
The IPv6 Transition CE Router described in this document is not The IPv6 Transition CE Router described in this document is not
intended for usage in other scenarios such as large Enterprises, Data intended for usage in other scenarios such as large Enterprises, Data
Centers, Content Providers, etc. So even if the documented Centers, Content Providers, etc. So even if the documented
requirements meet their needs, they may have additional requirements, requirements meet their needs, they may have additional requirements,
which are out of the scope of this document. which are out of the scope of this document.
12. Annex B: End-User Network Architecture 12. Annex B: End-User Network Architecture
According to the descriptions in the preceding sections, an end-user According to the descriptions in the preceding sections, an end-user
skipping to change at page 16, line 33 skipping to change at page 16, line 26
addresses are always usable even when the WAN interface is down or addresses are always usable even when the WAN interface is down or
the customer edge router has not yet been provisioned. In the case the customer edge router has not yet been provisioned. In the case
of an IPv6-only access, private IPv4 addresses are also available if of an IPv6-only access, private IPv4 addresses are also available if
the IPv4aaS transition mechanism keeps running the NAT interface the IPv4aaS transition mechanism keeps running the NAT interface
towards the LAN side when the WAN interface is down. towards the LAN side when the WAN interface is down.
More advanced routers support dynamic routing (which learns routes More advanced routers support dynamic routing (which learns routes
from other routers), and advanced end-users can build arbitrary, from other routers), and advanced end-users can build arbitrary,
complex networks using manual configuration of address prefixes complex networks using manual configuration of address prefixes
combined with a dynamic routing protocol. Once again, this is true combined with a dynamic routing protocol. Once again, this is true
for both, IPv4 and IPv6. for both IPv4 and IPv6.
In general, the end-user network architecture for IPv6 should provide In general, the end-user network architecture for IPv6 should provide
equivalent or better capabilities and functionality than the current equivalent or better capabilities and functionality than the current
IPv4 architecture. IPv4 architecture.
The end-user network is a stub network, in the sense that is not The end-user network is a stub network, in the sense that is not
providing transit to other external networks. However, HNCP providing transit to other external networks. However, HNCP
[RFC7788] allows support for automatic provisioning of downstream [RFC7788] allows support for automatic provisioning of downstream
routers. Figure 1 illustrates the model topology for the end-user routers. Figure 2 illustrates the model topology for the end-user
network. network.
+---------------+ \ +---------------+ \
| Service | \ | Service | \
| Provider | \ | Provider | \
| Router | | Service | Router | | Service
+-------+-------+ | Provider +-------+-------+ | Provider
| IPv6-only | Network | IPv6-only | Network
| Customer / | Customer /
| Internet Connection / | Internet Connection /
skipping to change at page 20, line 11 skipping to change at page 20, line 11
Section to be removed by RFC Editor. Significant updates are: Section to be removed by RFC Editor. Significant updates are:
1. Added text to UPnP section. 1. Added text to UPnP section.
21. ANNEX K: Changes from -08, -09 and -10 21. ANNEX K: Changes from -08, -09 and -10
Section to be removed by RFC Editor. Significant updates are: Section to be removed by RFC Editor. Significant updates are:
1. Editorial edits. 1. Editorial edits.
22. ANNEX L: Changes from -11 and -12 22. ANNEX L: Changes from -11, -12 and -13
Section to be removed by RFC Editor. Significant updates are: Section to be removed by RFC Editor. Significant updates are:
1. Changes related to suggestions by Ops-dir, Sec-dir, Rtg-dir, Tsv- 1. Changes related to suggestions by Ops-dir, Sec-dir, Rtg-dir, Tsv-
art and Gen-art, as well as comments from IESG review. art and Gen-art, as well as comments from IESG review.
23. References 23. References
23.1. Normative References 23.1. Normative References
 End of changes. 40 change blocks. 
109 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/