Transition Requirements for IPv6
Customer Edge Routers to support IPv4 as a ServiceThe IPv6 CompanyMolino de la Navata, 75La Navata - GalapagarMadrid28420Spainjordi.palet@theipv6company.comhttp://www.theipv6company.com/D-Link Systems, Inc.17595 Mount Herrmann St.Fountain ValleyCalifornia92708UShans.liu@dlinkcorp.comhttp://www.dlink.com/IPv6 Operations (v6ops)IPv6 transition CE requirements for IPv4aaSThis document specifies the transition requirements for an IPv6 Customer Edge (CE)
router, either provided by the service provider or thru the retail market.Specifically, this document extends the "Basic Requirements for
IPv6 Customer Edge Routers" ()
in order to allow the provisioning of IPv6 transition services for the
support of IPv4 as a Service (IPv4aaS) by means of new transition mechanisms,
which where not available at the time was published.
The document only covers transition technologies for delivering IPv4 in
IPv6-only access networks, commonly called IPv4 "as-a-service" (IPv4aaS),
as required in a world where IPv4 addresses are no longer available, so hosts
in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring
to communicate with IPv4-only services at the Internet, are still able to do so.This document defines basic IPv6 transition features for a residential or
small-office router, referred to as an "IPv6 Transition CE router with IPv4aaS
support", in order to establish an industry baseline for transition features
to be implemented on such a router.These routers are based on "Basic Requirements for
IPv6 Customer Edge Routers" (), so the scope of
this documents is to ensure the IPv4 "service continuity" support,
in the LAN side and the access to IPv4-only Internet services from
an IPv6-only access WAN even from IPv6-only applications
or devices in the LAN side.This document covers the IP transition technologies required when ISPs have
already an IPv6-only access network, which is becoming a common situation
in a world where IPv4 addresses are no longer available, so the service providers
need to provision IPv6-only WAN access, while at the same time ensuring that
both IPv4-only and IPv6-only devices or applications in the customer LANs,
can still reach IPv4-only devices or applications in Internet,
which still don't have IPv6 support.This document specifies the transition mechanisms to be supported by an IPv6
transition CE router, and relevant provisioning or configuration information
differences from .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 HNCP (), which is out of the scope of this
document.The CE vendors need to consider that the situation of lack of IPv4
addresses and the IPv6 deployment, is a global issue, so the CEs fulfilling
the requirements of this document aren't only those provided by the
service providers to the customers, but also the customers may need
to replace existing ones by themselves thru the retail market.
Take careful note: Unlike other IETF documents, the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
described in RFC 2119. 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 (preferable
in RFC or stable form) 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
access networks.
This document uses the same terminology as in ,
with two minor clarifications.The term "IPv6 transition Customer Edge Router with IPv4aaS"
(shortened as "IPv6 transition CE") is defined
as an "IPv6 Customer Edge Router" that provides transition support to allow
IPv4-IPv6 coexistence either beyond the WAN, in the LAN or both.The "WAN Interface" term used across this document, means that can also support
link technologies based in Internet-layer (or higher-layers) "tunnels", such as
IPv4-in-IPv6 tunnels.The situation before described, where there is ongoing IPv6 deployment
and lack of IPv4 addresses, is not happening at the same pace at every country,
and even within every country, every ISP. For different technical, financial,
commercial/marketing and socio-economical reasons, each network is transitioning
at their own pace, and nobody has a magic crystal ball, to make a guess.Different studies also show that this is a changing situation, because in a
single country, may be not all operators provide IPv6 support, and customer churn
implies that the same customers at some point may have IPv6 service and may not
have it, if changing ISP, and viceversa.So it is clear that, to cover all those evolving situations, it is required an
IPv6 transition CE which, at least from the perspective of the transition support,
can keep accommodating to those changes, as it may be or not provided by the
service provider. Even may be a point when, having one working seamlessly among
different operators means lower cost for changing them, and so, increase and
facilitate competition.Moreover, because some services will remain as IPv4-only for an undetermined
time and some service providers may also delay their IPv6 support, again for
an undetermined period of time, there is an uncertainty about how much time
there will be a percentage of IPv4 traffic between end-users and end-services,
that definitively needs to be "serviced", so there will be a need to provide
CEs with support "IPv4 as a Service" for some time.This document is consequently, based on those premises, in order to
ensure the continued transition from networks that today may provide
access with dual-stack or IPv6-in-IPv4, as described in ,
and as an "extension" to it, evolving to an IPv6-only access with
IPv4-as-a-Service.Considering that situation and different possible usage cases, the
IPv6 Transition CE router described in this document is expected to be
used typically, in any of the following scenarios:Residential/household users. Common usage is any kind of Internet access
(web, email, streaming, online gaming, etc.).Residential with Small Office/Home Office (SOHO). Same usage as for the
first scenario.Small Office/Home Office (SOHO). Same usage as for the first scenario.Small and Medium Enterprise (SME). Same usage as for the first scenario.Residential/household with advanced requirements. Same basic usage
as for the first scenario, however there may be requirements for exporting
services to the WAN (IP cameras, web, DNS, email, VPN, etc.).Small and Medium Enterprise (SME) with advanced requirements. Same
basic usage as for the first scenario, however there may be requirements for
exporting services to the WAN (IP cameras, web, DNS, email, VPN, etc.).The above list is not intended to be comprehensive of all the possible usage
scenarios, just the main ones. In fact, combinations of the above usages are also
possible, for example a residential with SOHO and advanced requirements, as well
as situations where the same CE is used at different times in different scenarios
or even different services providers that may use a different transition
mechanism.The mechanisms for exporting IPv6 services are commonly "naturally" available
in any IPv6 router, as when using GUA, unless they are blocked by firewall rules,
which may require some manual configuration by means of a GUI and/or CLI.However, in the case of IPv4, because the usage of private addresses and NAT, it
typically requires some degree of manual configuration such as setting up a DMZ,
virtual servers, or port/protocol forwarding. In general, CE routers already
provide GUI and/or CLI to manually configure them, or the possibility to setup the
CE in bridge mode, so another CE behind it, takes care of that. It is out of the
scope of this document the definition of any requirements for that.The main difference for an IPv6 Transition CE router to support one or several
of the above indicated scenarios, is related to the packet processing capabilities,
performance, even other details such as the number of WAN/LAN interfaces,
their maximum speed, memory for keeping tables or tracking connections, etc.
So, it is out of the scope of this document to classify them.For example, an SME may have just 10 employees (micro-SME), which commonly will
be considered same as a SOHO, but a small SME can have up to 50 employees, or 250
for a medium one. Depending on the IPv6 Transition CE router capabilities or
even how it is being configured (for instance, using SLAAC or DHCPv6), it may
support even a higher number of employees if the traffic in the LANs is low,
or switched by another device(s), or the WAN bandwidth requirements are low, etc.
The actual bandwidth capabilities of access with technologies such as FTTH, cable
and even 3GPP/LTE, allows the support of such usages, and indeed, is a very
common situation that access networks and the IPv6 Transition CE provided
by the service provider are the same for SMEs and residential users.There is also no difference in terms of who actually provides the
IPv6 Transition CE router. In most of the cases is the service provider,
and in fact is responsible, typically, of provisioning/managing at least the
WAN side. However, commonly the user has access to configure the LAN interfaces,
firewall, DMZ, and many other aspects. In fact, in many cases, the user must
supply, or at least can replace the IPv6 Transition CE router, which makes even
more relevant that all the IPv6 Transition CE routers, support the same
requirements defined in this document, despite if they are provided
directly by the service provider or acquired thru the retail market.The IPv6 Transition CE router described in this document is not intended
for usage in other scenarios such as bigger Enterprises, Data Centers,
Content Providers, etc. So, even if the documented requirements meet
their needs, may have additional requirements, which are out of the scope
of this document.According to the descriptions in the precedent sections, an end-user
network will likely support both IPv4 and IPv6. It is
not expected that an end user will change their existing network
topology with the introduction of IPv6. There are some differences in
how IPv6 works and is provisioned; these differences have implications
for the network architecture.A typical IPv4 end-user network consists of a "plug and play" router with
NAT functionality and a single link behind it, connected to the service
provider network.From the perspective of an "IPv4 user" behind an IPv6 transition Customer
Edge Router with IPv4aaS, this doesn't change.However, while a typical IPv4 NAT deployment by default blocks all incoming
connections and may allow opening of ports using a Universal
Plug and Play Internet Gateway Device (UPnP IGD) or some other firewall control protocol, in the
case of an IPv6-only access, the latest may not be feasible depending on
specific transition mechanism details. PCP (Port Control Protocol,
) may be an alternative solution, as well.Another consequence of using IPv4 private address space in the end-user
network is that it provides stable addressing; that is, it never changes
even when you change service providers, and the addresses are always
there even when the WAN interface is down or the customer edge router
has not yet been provisioned. In the case of an IPv6-only access,
there is no change on that if the transition mechanism keeps running
the NAT interface towards the LAN side.Many existing routers support dynamic routing (which learns routes
from other routers), and advanced end-users can build arbitrary, complex
networks using manual configuration of address prefixes combined with a
dynamic routing protocol. Once again, this is true for both, IPv4 and IPv6.In general, 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 is not providing
transit to other external networks. However HNCP ()
allows support for automatic provisioning of downstream routers.
Figure 1 illustrates the model topology for the end-user network.This architecture describes the:Basic capabilities of an IPv6 Transition CE routerProvisioning of the WAN interface connecting to the service
providerProvisioning of the LAN interfacesThe IPv6 Transition CE router may be manually configured in an arbitrary
topology with a dynamic routing protocol or using HNCP
(). Automatic provisioning and configuration
is described for a single IPv6 Transition CE router only.The IPv6 Transition CE router must comply with all the requirements stated
in .A new general requirement is added:G-6 The IPv6-only CE router MUST comply with .A new LAN requirement is:L-15 The IPv6 CE router SHOULD implement a DNS proxy as described
in .The main target of this document is the support of IPv6-only WAN
access, and while needed, the support of IPv4-only devices
and applications in the customers LANs, in one side of the picture.
In the other side, some remote services may stay IPv4-only, so
a solution is also required for both the IPv4-only and the IPv6-only
devices inside the CE are able to reach the IPv4-only services.
Consequently, transition technologies to resolve both sides of the
picture are considered.In order to seamlessly provide the IPv4 Service Continuity in Customer LANs,
allowing an automated IPv6 transition mechanism provisioning, a new general
transition requirement is added.General transition requirement: The IPv6 Transition CE router MUST support the DHCPv6 S46 priority
option described in if more than one S46
mechanisms is supported.The following sections describe the requirements for supporting additional
transition mechanisms not included in .464XLAT is a technique
to provide IPv4 access service to IPv6-only edge networks
without encapsulation.The IPv6 Transition CE router SHOULD support CLAT functionality.
If 464XLAT is supported, it MUST be implemented according to
. The following CE Requirements also apply:464XLAT requirements: The IPv6 Transition CE router MUST verify if the WAN link supports
native IPv4, and if that's not available, MUST enable the CLAT (in order
to automatically configure ), unless there is
a match with a valid OPTION_S46_PRIORITY (following section 1.4
of ), which will allow configuring any
of the other transition mechanisms.The IPv6 Transition CE router MUST perform IPv4 Network Address
Translation (NAT) on IPv4 traffic translated using the CLAT, unless
a dedicated /64 prefix has been acquired using DHCPv6-PD
.The IPv6 Transition CE router MUST implement
in order to discover the PLAT-side translation IPv4 and IPv6
prefix(es)/suffix(es). In environments with PCP support, the
IPv6 Transition CE SHOULD follow
to learn the PLAT-side translation IPv4 and IPv6 prefix(es)/suffix(es)
used by an upstream PCP-controlled NAT64 device.Lw4o6 specifies an extension to DS-Lite,
which 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 a CGN function in the tunnel concentrator and reducing
the amount of centralized state.The IPv6 Transition CE router SHOULD implement lw4o6 functionality.
If DS-Lite is implemented, lw4o6 MUST be supported as well. If lw4o6
is supported, it MUST be implemented according to .
This document takes no position on simultaneous operation of lw4o6
and native IPv4. The following IPv6 Transition CE router
Requirements also apply:Lw4o6 requirements: The IPv6 Transition CE router MUST support configuration of
lw4o6 via the lw4o6 DHCPv6 options .
The IPv6 Transition CE router MAY use other mechanisms to configure
lw4o6 parameters. Such mechanisms are outside the scope
of this document.The IPv6 Transition CE router MUST support the DHCPv4-over-DHCPv6
(DHCP 4o6) transport described in .The IPv6 Transition CE router MAY support Dynamic Allocation of
Shared IPv4 Addresses as described in .MAP-E is a mechanism for transporting IPv4
packets across an IPv6 network using IP encapsulation, including a generic
mechanism for mapping between IPv6 addresses and IPv4 addresses as well as
transport-layer ports.The IPv6 Transition CE router SHOULD support MAP-E functionality.
If MAP-E is supported, it MUST be implemented according to
. The following CE Requirements also apply:MAP-E requirements: The IPv6 Transition CE router MUST support configuration of MAP-E
via the MAP-E DHCPv6 options .
The IPv6 Transition CE router MAY use other mechanisms to configure
MAP-E parameters. Such mechanisms are outside the scope
of this document.MAP-T is a mechanism similar to MAP-E,
differing from it in that MAP-T uses IPv4-IPv6 translation, rather than
encapsulation, as the form of IPv6 domain transport.The IPv6 Transition CE router SHOULD support MAP-T functionality.
If MAP-T is supported, it MUST be implemented according to
. The following IPv6 Transition CE Requirements
also apply:MAP-T requirements: The CE router MUST support configuration of MAP-T via the MAP-T
DHCPv6 options . The IPv6 Transition CE router
MAY use other mechanisms to configure MAP-T parameters. Such mechanisms
are outside the scope of this document.Actual deployments support IPv4 multicast for services such as
IPTV. In the transition phase it is expected that multicast services
will still be provided using IPv4 to the customer LANs.In order to support the delivery of IPv4 multicast services to IPv4
clients over an IPv6 multicast network, the IPv6 Transition CE router SHOULD support
and .One of the apparent main issues for vendors to include new functionalities,
such as 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 (OpenWRT/LEDE, Linux, others), that adding the support for
the new transitions mechanisms, requires around 10-12 Kbytes (because most
of the code base is shared among several transition mechanisms already
supported by ), as a single data plane
is common to all them, which typically means about 0,15% of the
existing code size in popular CEs already in the market.It is also clear that the new requirements don't have extra cost in terms of
RAM memory, neither other hardware requirements such as more powerful CPUs.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 the new transition mechanisms, and even several vendors already
have implementations and provide it to ISPs, so the development cost is negligent,
and only integration and testing cost may become a minor issue.The IPv6 Transition CE router must comply with the Security Considerations
as stated in .Thanks to James Woodyatt, Mohamed Boucadair, Masanobu Kawashima,
Mikael Abrahamsson, Barbara Stark, Ole Troan and Brian Carpenter for their review
and comments in previous versions of this document.InternetGatewayDevice:2 Device Template Version 1.01