Internet Engineering Task Force A. Durand, Ed.
Internet-Draft Comcast
Intended status: Standards Track July 11, 2009
Expires: January 12, 2010
Dual-stack lite broadband deployments post IPv4 exhaustion
draft-ietf-softwire-dual-stack-lite-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The common thinking for more than 10 years has been that the
transition to IPv6 will be based on the dual stack model and that
most things would be converted this way before we ran out of IPv4.
Durand Expires January 12, 2010 [Page 1]
Internet-Draft Dual-stack lite July 2009
It has not happened. The IANA free pool of IPv4 addresses will be
depleted soon, well before any significant IPv6 deployment will have
occurred.
This document revisits the dual-stack model and introduces the dual-
stack lite technology aimed at better aligning the costs and benefits
of deploying IPv6. Dual-stack lite will provide the necessary bridge
between the two protocols, offering an evolution path of the Internet
post IANA IPv4 depletion.
Dual-Stack lite enable a brodband service provider to share IPv4
addresses among customers by combining two well-known technologies:
IP in IP (IPv4/IPv6) and NAT.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. IPv4 exhaustion coming sooner than expected . . . . . . . 4
2. The two long tails . . . . . . . . . . . . . . . . . . . . . . 5
2.1. The long tail of IPv4-only devices in the home . . . . . . 5
2.2. The long tail of content and services available on the
Internet . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Additional impact on new broadband deployment . . . . . . 5
2.4. Burden on service providers . . . . . . . . . . . . . . . 6
2.5. Dual-prong strategy for broadband . . . . . . . . . . . . 6
3. Expectations for dual-stack lite deployment . . . . . . . . . 6
3.1. Expectations for home gateway based scenarios . . . . . . 6
3.2. Expectations for devices directly connected to the
broadband service provider network . . . . . . . . . . . . 7
3.3. Expectations for IP-enabled wireless devices scenario . . 7
3.4. Application expectations . . . . . . . . . . . . . . . . . 7
3.5. Service provider network expectations . . . . . . . . . . 8
4. Dual-stack lite . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Domain of application . . . . . . . . . . . . . . . . . . 8
4.2. Dual-stack lite interface . . . . . . . . . . . . . . . . 9
4.3. Dual-stack lite device . . . . . . . . . . . . . . . . . . 9
4.4. Dual-stack lite home router . . . . . . . . . . . . . . . 9
4.5. Dual-stack lite router . . . . . . . . . . . . . . . . . . 10
4.6. Discovery of the dual-stack lite carrier-grade NAT
device . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7. Dual-stack lite carrier-grade NAT . . . . . . . . . . . . 11
5. Example architectures . . . . . . . . . . . . . . . . . . . . 11
5.1. Router-based architecture . . . . . . . . . . . . . . . . 11
5.1.1. Example message flow . . . . . . . . . . . . . . . . . 14
5.1.2. Translation details . . . . . . . . . . . . . . . . . 18
Durand Expires January 12, 2010 [Page 2]
Internet-Draft Dual-stack lite July 2009
5.2. Host based architecture . . . . . . . . . . . . . . . . . 19
5.2.1. Example message flow . . . . . . . . . . . . . . . . . 22
5.2.2. Translation details . . . . . . . . . . . . . . . . . 26
6. Encapsulations . . . . . . . . . . . . . . . . . . . . . . . . 26
7. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 27
8. Carrier-grade NAT considerations . . . . . . . . . . . . . . . 27
9. Port allocation . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Static port reservation . . . . . . . . . . . . . . . . . 28
9.2. Dynamic port reservation . . . . . . . . . . . . . . . . . 29
9.2.1. UPnP . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.2.2. NAT-PMP . . . . . . . . . . . . . . . . . . . . . . . 29
9.2.3. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Other carrier-grade NAT considerations . . . . . . . . . . . . 30
10.1. ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Multicast considerations . . . . . . . . . . . . . . . . . 32
11.2. 3rd party carrier-grade NAT . . . . . . . . . . . . . . . 32
11.3. Interface initialization . . . . . . . . . . . . . . . . . 32
12. Comparison with an architecture with multiple-layers of NAT . 32
13. Comparison with NAT-PT (or its potential replacements) . . . . 33
14. Comparison with DSTM . . . . . . . . . . . . . . . . . . . . . 34
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
17. Security Considerations . . . . . . . . . . . . . . . . . . . 35
18. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 36
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
19.1. Normative references . . . . . . . . . . . . . . . . . . . 37
19.2. Informative references . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
Durand Expires January 12, 2010 [Page 3]
Internet-Draft Dual-stack lite July 2009
1. Introduction
This document presents views on IP deployments after the exhaustion
of IPv4 addresses and some of the necessary technologies to achieve
it. The views expressed are the authors' personal opinions and in no
way imply that Comcast plans to deploy or that Cisco will implement
the technologies described here.
1.1. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology
This document makes a distinction between a dual-stack capable and a
dual-stack provisioned device. The former is a device that has code
that implements both IPv4 and IPv6, from the network layer to the
applications. The later is a similar device that has been
provisioned with both an IPv4 and an IPv6 address on its
interface(s). This document will also further refine this notion by
distinguishing between interfaces provisioned directly by the service
provider from those provisioned by the customer.
1.3. IPv4 exhaustion coming sooner than expected
Global public IPv4 addresses coming from the IANA free pool are
running out faster than many predicted a few years ago. The current
model shows that exhaustion could happen as early as 2010 or 2011.
See http://ipv4.potaroo.net for more details. Those projection are
based on the assumption that tomorrow is going to be very similar to
today, i.e., looking at recent address consumption figures is a good
indicator of future consumption patterns. This of course, does not
take into account any new large scale deployment of IP technology or
any human reaction when facing an upcoming shortage.
The prediction of the exact date of exhaustion of the IANA free pool
is outside the scope of this document, however one conclusion must be
drawn from that study: there will be in the near future a point where
new global public IPv4 addresses will not be available in large
enough quantity thus any new broadband deployment may have to
consider the option of not provisioning any (global) IPv4 addresses
to the WAN facing interface of edge devices. However, the classic
IPv6 deployment model known as "dual stack provisioning" can be a non
starter in such environments.
Durand Expires January 12, 2010 [Page 4]
Internet-Draft Dual-stack lite July 2009
2. The two long tails
The dual-stack lite technology is intended for maintaining
connectivity to legacy IPv4 devices and networks after the exhaustion
of the IPv4 address space while service provider networks make a
transition to IPv6-only deployments. This section describes some of
the specific legacy scenarios addressed by dual-stack lite.
2.1. The long tail of IPv4-only devices in the home
Broadband home customers have a mix and match of IP enabled devices.
The most recent operating systems (e.g., Windows Vista, Mac OS X and
various versions of Linux) can operate in an IPv6-only environment;
however most of the legacy devices can't. Windows XP, for example,
cannot process DNS requests over IPv6 transport. More, having an
operating system that support IPv6 does npot garantee that all the
application will support IPv6. Many are still only supporting IPv4.
Consumer electronic devices (non traditional PCs) are now more and
more conected to home networks. Large TVs with a MOCA or ethernet
connection, point-and-shoot camera with a Wifi interface to push
pictures on the Web, and many others are now comom and most have been
reported to only support IPv4. Those devices are generally not
upgradables to support IPv6. Expecting broadband customers to
massively upgrade their software (and in most cases the corresponding
hardware) to deploy IPv6 is a very tall order.
2.2. The long tail of content and services available on the Internet
IPv6 deployment has taken a very long time to take off, so the
current situation is that almost none of the content and services
available on the Internet are accessible over IPv6. This situation
will probably change in the future, but for now, one has to make the
assumption that most of the traffic generated by (and to) broadband
customers will be sent to (and originated by) IPv4 nodes. Even when
the majority of the most popular content will be accessible via IPv6,
there will still be a need to access the long tail of content only
reachable with IPv4.
2.3. Additional impact on new broadband deployment
Even when considering new, green field, broadband deployments, such
as always-on 4G, service providers have to face the same situation as
described above, that is, content and services available on the
Internet are, today, generally accessible only over IPv4 and not
IPv6. This makes adoption of IPv6 for green field deployment
difficult. Solutions like NAT-PT, now deprecated, do not provide, as
of today, a satisfying and scalable answer.
Durand Expires January 12, 2010 [Page 5]
Internet-Draft Dual-stack lite July 2009
2.4. Burden on service providers
As a conclusion, broadband service providers may be faced with the
situation where they have IPv4 customers who need to communicate with
IPv4 servers on the Internet but may not have any IPv4 addresses left
to assign to those customers. A service providers may also be in a
situation where it wants to deploy IPv6 in its core network, avoiding
the use of scarce IPv4 addresses. However, without some form of
backward compatibility with IPv4, the cost and the benefits of
deploying IPv6 are not aligned, making incremental IPv6 deployment
very difficult.
2.5. Dual-prong strategy for broadband
Facing the reality of the upcoming completion of the IPv4 address
space on pne side and the two long IPv4 tails on the other side,
broadband providers can implement a dual-prong strategy when they
will face a shortage of IPv4 addresses. First prong is to deploy
IPv6 natively. Second is to use a transition bridge to offer an IPv4
service without relying on a unique IPv4 adress per customer. That
means haring IPv4 addresses among customers and implementing some
form of NAT inside the provider network. This documment proposes a
scalable way of doing so by combining two well-known technologies, IP
in IP (IPv4/IPv6) tunneling and NAT.
3. Expectations for dual-stack lite deployment
3.1. Expectations for home gateway based scenarios
This section mainly address home style networks characterized by the
presence of a home gateway.
Legacy, unmodified, IPv4-only devices inside the home network are
expected to keep using [RFC1918] address space, a-la 192.168.0.0/16
and should be able to access the IPv4 Internet in a similar way they
do it today through a home gateway IPv4 NAT.
Unmodified IPv6 capable devices are expected to be able to reach
directly the IPv6 Internet, without going through any translation.
It is expected that most IPv6 capable devices will also be IPv4
capable and will simply be configured with an IPv4 RFC1918 style
address within the home network and access the IPv4 Internet the same
way as the legacy IPv4-only devices within the home.
IPv6-only devices that do not include code for an IPv4 stack are
outside of the scope of this document.
Durand Expires January 12, 2010 [Page 6]
Internet-Draft Dual-stack lite July 2009
It is expected that the home gateway is either software upgradable,
replaceable or provided by the service provider as part of a new
contract. Outside of early IPv6 deployments done prior to IPv4
exhaustion using some form of tunnel, this is pretty much a
requirement to deploy any IPv6 service to the home. It is expected
that this home gateway will be a dual stack capable device that would
only be provisioned with IPv6 on its WAN side. IPv4 and IPv6 are
expected to be locally provisioned on any LAN interfaces of such
devices. IPv4 addresses on such interfaces are expected to be
RFC1918. The key point here is that the service provider will not
provision any IPv4 addresses for those home gateway devices.
3.2. Expectations for devices directly connected to the broadband
service provider network
Under this deployment model, devices directly connected to the
broadband service provider network without the presence of a home
gateway will have to be dual stack capable devices. The service
provider facing interface(s) of such device will only be provisioned
with IPv6. IPv4 may or may not be provisioned locally on other
interfaces of such devices. Similarly to the above section, the key
point here is that the service provider will not provision any IPv4
addresses for those directly connected devices.
It is expected that directly connected devices will implement code to
support the dual-stack lite functionality. The minimum support
required is an IPv4-in-IPv6 tunnel [RFC2473].
IPv4-only devices and IPv6-only devices are specifically left out of
scope for this document. It is expected that most modern device
directly connected to the service provider network would not have
memory constraints to implement both stack.
3.3. Expectations for IP-enabled wireless devices scenario
Simialr to host devices directly connected to the broadband servie
provider network, the wireless device will have dual-stack
implemented. When the wireless device requests IP connectivity from
the service provider, the service provider will only provision an
IPv6 address to the WAN facing interface of the wireless device. No
IPv4 (public or RFC1918) address will be given to the device. When
the wireless device accesses IPv4 services, it will be implemented
the dual-stack lite functionality described in section 4.
3.4. Application expectations
Most applications that today work transparently through an IPv4 home
gateway NAT should keep working the same way. However, it is not
Durand Expires January 12, 2010 [Page 7]
Internet-Draft Dual-stack lite July 2009
expected that applications that requires specific port assignment or
specific port mapping from the NAT box will keep working. Details
and recommendations for application behavior are outside the scope of
this document and should be discussed in the behave working group.
3.5. Service provider network expectations
The dual-stack lite deployment model is based on the notion that IPv4
addresses will be shared by several customers. This implies that the
NAT functionality will move from the home gateway to a device hosted
within the service provider network. It is important to observe that
this functionality does not have to be performed deep in the core of
the network and that it might be better implemented close to the
aggregation point of customer traffic.
4. Dual-stack lite
The core ideas behind dual-stack lite are:
o Move from a deployment model where a globally unique IPv4 address
is provisioned per customer and shared among several devices
within that customer premise to a deployment model where that
globally unique IPv4 address is shared among many customers
o Provide transport of IPv4 traffic to customers over a core network
that uses only IPv6
Instead of relying on a cascade of NATs or NAT-PT, the dual-stack
lite model is built on IPv4-in-IPv6 tunnels to cross the network to
reach a carrier-grade IPv4-IPv4 NAT. As such, it simplifies the
management of the service provider network by using only IPv6 and
provides the customer the benefit of having only one layer of NAT.
The additional benefit of this model is to gradually introduce IPv6
in the Internet by making it virtually backward compatible with IPv4.
Details about IPv6 tunneling can be found on [RFC2473], where the
next header is simply 4, for IPv4, as explained in [RFC2460] and in
[RFC1700].
4.1. Domain of application
The dual-stack lite deployment model has been designed with broadband
networks in mind. It is certainly applicable to other domains
although the authors do not make any specific claim of suitability.
Durand Expires January 12, 2010 [Page 8]
Internet-Draft Dual-stack lite July 2009
4.2. Dual-stack lite interface
A dual-stack lite interface on a dual-stack capable device is modeled
as a point to point IPv4-in-IPv6 tunnel. Its configuration requires
that the device is provisioned with IPv6 but does not require it to
be provisioned with a global IPv4 by the service provider.
Any locally unique IPv4 address can be configured on the subscriber
network end of the dual-stack lite tunnel. In the case of dual-stack
lite in which the tunnel endpoint is in a host Section 5.2, it is
recommended that dual-stack lite implementations use any address
a.b.c.d in the well known range e.f.g.h/p (to be defined by IANA) but
the first one (all-zero address in the reserved subnet) as the IPv4
host side of the tunnel and the last one of the same range as the
address of the IPv4 default gateway, with a netmask to cover a /p
network.
o Note 1: on a multi-home node, several dual-stack like interfaces
could end-up being configured. Each of those interfaces should be
configured with a different IPv4 address taken out of the reserved
range.
o Note 2: because of this static configuration using well known
values, there is no need to run a DHCPv4 client on a dual-stack
lite interface.
The service provider network end point of a dual-stack lite interface
is the IPv6 address of a dual-stack lite carrier-grade NAT within the
service provider network.
4.3. Dual-stack lite device
A dual-stack lite device is a dual-stack capable device implementing
a dual-stack lite interface. In the absence of better routing
information, a dual-stack lite device will configure a static IPv4
default route over the dual-stack lite interface.
4.4. Dual-stack lite home router
A dual-stack lite home router is a dual-stack capable home router
implementing a dual-stack lite interface layered on top of its WAN
interface. In the absence of better routing information, a dual-
stack lite home router will configure a static IPv4 default route
over the dual-stack lite interface. The dual-stack lite home router
can use any IPv4 address a.b.c.d out of the e.f.g.h/p prefix (TBD by
IANA) to source its own IPv4 packets, embedded into the IPv6 tunnel.
If the dual-stack lite home router need to configure a router
pointing to an IPv4 default router, it can use the last address in
Durand Expires January 12, 2010 [Page 9]
Internet-Draft Dual-stack lite July 2009
the e.f.g.h/p (TBD by IANA) range for that purpose, with a netmask to
cover a /p (TBD by IANA) network.
For normal IPv4 packets, a dual-stack lite home router MUST NOT
perform any IPv4 address translation. From egress traffic, the home
router passes packets from the LAN interface to the dual-stack lite
interface for IPv6 encapsulation. For ingress traffic, the home
router receives packets from the dual-stack lite interface,
decapsulates the IPv6 header, and routes the packets to the target
based on the destination address in the IPv4 header. Either case,
the dual-stack lite home router will not perform address translation.
For IPv4 packets fallen into the A+P address space, the A+P enabled
home router MUST perform the A+P mechanism described in
[I-D.ymbk-aplusp]. For egress traffic, the home router references
the A+P table using the source IPv4 address and transport port
number, and passes the packets from the LAN interface to the dual-
stack lite interface for IPv6 encapsulation. For ingress traffic,
the home router receives packets from the dual-stack lite interface,
decapsulates the IPv6 header, finds the targeted host using the A+P
table, and routes the packets accordingly to the host. The A+P
enabled home router handles the A+P table. The dual-stack lite
carrier-grade NAT simply forwards the packets to the IPv4-in-IPv6
tunnel.
Besides, the dual-stack lite router must account the tunnel overhead
which reduces the effective MTU size. As such, the router may
perform IPv6 fragmentation. More details can be found in
Section 10.2.
4.5. Dual-stack lite router
The concept of a dual-stack lite home router can be extended to any
IPv4 router serving as a gateway between a leaf IP domain and the
rest of the Internet.
4.6. Discovery of the dual-stack lite carrier-grade NAT device
The IPv6 address of a dual-stack lite carrier-grade NAT device can be
configured on a dual-stack lite interface using a variety of methods,
ranging from an out-of-band mechanism, manual configuration, a to-be-
defined DHCPv6 option [I-D.dhankins-softwire-tunnel-option] or a to-
be-defined IPv6 router advertisement. It is expected that over time
some or all the above methods, as well as others, will be defined.
The requirements and specifications of such methods are out of scope
for this document.
Durand Expires January 12, 2010 [Page 10]
Internet-Draft Dual-stack lite July 2009
4.7. Dual-stack lite carrier-grade NAT
A dual-stack lite carrier grade NAT is a special IPv4 to IPv4 NAT
deployed within the service provider network. It is reachable by
customers via a series of point to point IPv4-in-IPv6 tunnels.
A dual-stack lite carrier-grade NAT uses a combination of the IPv6
source address of the tunnel and the inner IPv4 source address to
establish and maintain the IPv4 NAT mapping table.
A dual-stack lite carrier-grade NAT does not have to perform any
IPv6-IPv6, IPv6-IPv4 or IPv4-IPv6 NAT.
A dual-stack lite carrier-grade NAT can use the last IPv4 address of
the range e.f.g.h/p (TBD by IANA) in the IPv4 ICMP packets it will
originate toward a dual-stack lite client to enable meaningful ping
and traceroute results.
A dual-stack lite carrier-grade NAT forwards packets without NAT for
those fallen in the A+P address space.
5. Example architectures
The underlying technology behind dual-stack lite is the combination
of two well-known technologies: NAT and tunneling. This combination
can be best described using the terminology developed in the softwire
working group as Softwire NAT, or SNAT.
Two architectures can be deployed for dual-stack lite. One is
targeting the legacy installed base of IPv4 only hosts (and dual-
stack capable hosts) sitting behind a gateway. The second is
targeting dual-stack capable hosts initiating the tunnel themselves.
5.1. Router-based architecture
This architecture is targeted at residential broadband deployments
but can be adapted easily to other types of deployment where the
installed base of IPv4-only device is important.
Consider a scenario where a Dual-Stack lite home gateway is
provisioned only with IPv6 in the WAN port, no IPv4. The home
gateway acts as an IPv4 DCHP server for the LAN network (wireline and
wireless) handing out RFC1918 addresses. In addition, the home
gateway may support IPv6 Auto-Configuration and/or DHCPv6 server for
the LAN network. When an IPv4-only device connects to the home
gateway, the gateway will hand it out a RFC1918 address. When a
dual-stack capable device connects to the home gateway, the gateway
Durand Expires January 12, 2010 [Page 11]
Internet-Draft Dual-stack lite July 2009
will hand out a RFC1918 address and a global IPv6 address to the
device. Besides, the home gateway will create an IPv4-in-IPv6
softwire tunnel [RFC5571]to a Carrier-Grade NAT. The Carrier-Grade
NAT will reside in the service provider network.
When the device accesses IPv6 service, it will send the IPv6 datagram
to the home gateway natively. The home gateway will route the
traffic upstream to the default gateway.
When the device accesses IPv4 service, it will source the IPv4
datagram with the RFC1918 address and send the IPv4 datagram to the
home gateway. The home gateway will encapsulate the IPv4 datagram
inside the IPv4-over-IPv6 softwire tunnel and forward the IPv6
datagram to the Carrier-Grade NAT. This contrasts what the home
gateways normally do today which will NAT the RFC1918 address to the
public IPv4 address and route the datagram upstream. When the
Carrier-Grade NAT receives the IPv6 datagram, it will de-capsulate
the IPv6 header and perform an IPv4-to-IPv4 NAT on the source
address.
As illustrated in Figure 1, this dual-stack lite deployment model
consists of three components: the dual-stack lite home router, the
dual-stack lite carrier-grade NAT and a softwire between the softwire
initiator (SI) [RFC5571] in the dual-stack lite home router and the
softwire concentrator (SC) [RFC5571] in the dual-stack lite carrier-
grade NAT. The dual-stack lite carrier-grade NAT performs IPv4-IPv4
NAT translations to multiplex multiple subscribers through a single
global IPv4 address. Overlapping address spaces used by subscribers
are disambiguated through the identification of tunnel endpoints.
Durand Expires January 12, 2010 [Page 12]
Internet-Draft Dual-stack lite July 2009
+-----------+
| Host |
+-----+-----+
|10.0.0.1
|
|
|10.0.0.2
+---------|---------+
| | |
|dual-stack lite home router
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
|||2001:0:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:0:0:2::1
+--------|||--------+
|dual-stack lite carrier-grade NAT
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|129.0.0.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 1: SNAT gateway-based architecture
Durand Expires January 12, 2010 [Page 13]
Internet-Draft Dual-stack lite July 2009
Notes:
o The dual-stack lite home router is not required to be on the same
link as the host
o The dual-stack lite home router could be replaced by a dual-stack
lite router in the service provider network
The resulting solution accepts an IPv4 datagram that is translated
into an IPv4-in-IPv6 softwire datagram for transmission across the
softwire. At the corresponding endpoint, the IPv4 datagram is
decapsulated, and the translated IPv4 address is inserted based on a
translation from the softwire.
5.1.1. Example message flow
In the example shown in Figure 2, the translation tables in the dual-
stack lite carrier-grade NAT is configured to forward between IP/TCP
(10.0.0.1/10000) and IP/TCP (129.0.0.1/5000). That is, a datagram
received by the dual-stack lite home router from the host at address
10.0.0.1, using TCP DST port 10000 will be translated a datagram with
IP SRC address 129.0.0.1 and TCP SRC port 5000 in the Internet.
Durand Expires January 12, 2010 [Page 14]
Internet-Draft Dual-stack lite July 2009
+-----------+
| Host |
+-----+-----+
| |10.0.0.1
IPv4 datagram 1 | |
| |
v |10.0.0.2
+---------|---------+
| | |
|dual-stack lite home router
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
| |||2001:0:0:1::1
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:0:0:2::1
+------|-|||--------+
|dual-stack lite carrier-grade NAT
| v ||| |
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |129.0.0.1
IPv4 datagram 3 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
Durand Expires January 12, 2010 [Page 15]
Internet-Draft Dual-stack lite July 2009
Figure 2: Outbound Datagram
+-----------------+--------------+---------------+
| Datagram | Header field | Contents |
+-----------------+--------------+---------------+
| IPv4 datagram 1 | IPv4 Dst | 128.0.0.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:2::1 |
| | IPv6 Src | 2001:0:0:1::1 |
| | IPv4 Dst | 128.0.0.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 128.0.0.1 |
| | IPv4 Src | 129.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 5000 |
+-----------------+--------------+---------------+
Datagram header contents
When datagram 1 is received by the dual-stack lite home router, the
SI function encapsulates the datagram in datagram 2 and forwards it
to the dual-stack lite carrier-grade NAT over the softwire.
When it receives datagram 2, the SC in the dual-stack lite carrier-
grade NAT hands the IPv4 datagram to the NAT, which determines from
its translation table that the datagram received on Softwire_1 with
TCP SRC port 10000 should be translated to datagram 3 with IP SRC
address 129.0.0.1 and TCP SRC port 5000.
Figure 3 shows an inbound message received at the dual-stack lite
carrier-grade NAT. When the NAT function in the dual-stack lite
carrier-grade NAT receives datagram 1, it looks up the IP/TCP DST in
its translation table. In the example in Figure 3, the NAT
translates the TCP DST port to 10000, sets the IP DST address to
10.0.0.1 and hands the datagram to the SC for transmission over
Softwire_1. The SI in the dual-stack lite home router decapsulates
IPv4 datagram from the inbound softwire datagram, and forwards it to
the host.
Durand Expires January 12, 2010 [Page 16]
Internet-Draft Dual-stack lite July 2009
+-----------+
| Host |
+-----+-----+
^ |10.0.0.1
IPv4 datagram 3 | |
| |
| |10.0.0.2
+---------|---------+
| +-+-+ |
|dual-stack lite home router
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
^ |||2001:0:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:0:0:2::1
+------|-|||--------+
|dual-stack lite carrier-grade NAT
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |129.0.0.1
IPv4 datagram 1 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 3: Inbound Datagram
Durand Expires January 12, 2010 [Page 17]
Internet-Draft Dual-stack lite July 2009
+-----------------+--------------+---------------+
| Datagram | Header field | Contents |
+-----------------+--------------+---------------+
| IPv4 datagram 1 | IPv4 Dst | 129.0.0.1 |
| | IPv4 Src | 128.0.0.1 |
| | TCP Dst | 5000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:1::1 |
| | IPv6 Src | 2001:0:0:2::1 |
| | IPv4 Dst | 10.0.0.1 |
| | IP Src | 128.0.0.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 10.0.0.1 |
| | IPv4 Src | 128.0.0.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
+-----------------+--------------+---------------+
Datagram header contents
5.1.2. Translation details
The dual-stack lite carrier-grade NAT has a NAT that translates
between softwire/port pairs and IPv4-address/port pairs. The same
translation is applied to IPv4 datagrams received on the device's
external interface and from the softwire endpoint in the device.
In Figure 2, the translator network interface in the dual-stack lite
carrier-grade NAT is on the Internet, and the softwire interface
connects to the dual-stack lite home router. The dual-stack lite
carrier-grade NAT translator is configured as follows:
Network interface: Translate IPv4 destination address and TCP
destination port to the softwire identifier and TCP destination
port
Softwire interface: Translate softwire identifier and TCP source
port to IPv4 source address and TCP source port
Here is how the translation in Figure 3 works:
o Datagram 1 is received on the dual-stack lite carrier-grade NAT
translator network interface. The translator looks up the IPv4-
address/port pair in its translator table, rewrites the IPv4
destination address to 10.0.0.1 and the TCP source port to 10000,
Durand Expires January 12, 2010 [Page 18]
Internet-Draft Dual-stack lite July 2009
and hands the datagram to the SE to be forwarded over the
softwire.
o The IPv4 datagram is received on the dual-stack lite home router
SI. The SI function extracts the IPv4 datagram and the dual-stack
lite home router forwards datagram 3 to the host.
+----------------------------------+--------------------+
| Softwire-Id/IPv4/Port | IPv4/Port |
+----------------------------------+--------------------+
| 2001:0:0:1::1/10.0.0.1/TCP 10000 | 129.0.0.1/TCP 5000 |
+----------------------------------+--------------------+
Dual-Stack lite carrier-grade NAT translation table
The Softwire-Id is the IPv6 address assigned to the Dual-Stack lite
home gateway. Hosts behind the same Dual-Stack lite home router have
the same Softwire-Id. The source IPv4 is the RFC1918 addressed
assigned by the Dual-Stack home router which is unique to each host
behind the home gateway. The Dual-Stack lite carrier-grade NAT would
receive packets sourced from different IPv4 addresses in the same
softwire tunnel. The carrier-grade NAT combines the Softwire-Id and
IPv4 address/Port [Softwire-Id, IPv4+Port] to uniquely identify the
host behind the same Dual-Stack lite home router.
5.2. Host based architecture
This architecture is targeted at new, large scale deployments of
dual-stack capable devices implementing a dual-stack lite interface.
Consider a scenario where a Dual-Stack lite host device is directly
connected to the service provider network. The host device is dual-
stack capable but only provisioned an IPv6 global address. Besides,
the host device will pre-configure a well-known IPv4 non-routable
address (see IANA section). This well-known IPv4 non-routable
address is similar to the 127.0.0.1 loopback address. Every host
device implemented Dual-Stack lite will pre-configure the same
address. This address will be used to source the IPv4 datagram when
the device accesses IPv4 services. Besides, the host device will
create an IPv4-over-IPv6 softwire tunnel to a Carrier Grade NAT. The
Carrier Grade NAT will reside in the service provider network.
When the device accesses IPv6 service, the device will send the IPv6
datagram natively to the default gateway.
When the device accesses IPv4 service, it will source the IPv4
datagram with the well-known non-routable IPv4 address. Then, the
host device will encapsulate the IPv4 datagram inside the IPv4-over-
Durand Expires January 12, 2010 [Page 19]
Internet-Draft Dual-stack lite July 2009
IPv6 softwire tunnel and send the IPv6 datagram to the Carrier-Grade
NAT. When the Carrier-Grade NAT receives the IPv6 datagram, it will
de-capsulate the IPv6 header and perform IPv4-to-IPv4 NAT on the
source address.
This scenario works on both wireline and wireless networks. A
typical wireless device will connect directly to the service provider
without home gateway in between.
As illustrated in Figure 4, this dual-stack lite deployment model
consists of three components: the dual-stack lite host, the dual-
stack lite carrier-grade NAT and a softwire between the softwire
initiator (SI) in the host and the softwire concentrator (SC) in the
dual-stack lite carrier-grade NAT. The dual-stack lite host is
assumed to have IPv6 service and can exchange IPv6 traffic with the
dual-stack lite carrier-grade NAT.
The dual-stack lite carrier-grade NAT performs IPv4-IPv4 NAT
translations to multiplex multiple subscribers through a single
global IPv4 address. Overlapping IPv4 address spaces used by the
dual-stack lite hosts are disambiguated through the identification of
tunnel endpoints.
In this situation, the dual-stack lite host configures the IPv4
address a.b.c.d out of the well-known range e.f.g.h/p (TBD by IANA)
on it dual-stack lite interface acting as the SI. It also configure
the last IPv4 address of the reserved range as the address of its
default gateway, with a netmask to cover a /p (TBD by IANA) network.
Durand Expires January 12, 2010 [Page 20]
Internet-Draft Dual-stack lite July 2009
+-------------------+
| |
|Host a.b.c.d |
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
|||2001:0:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:0:0:2::1
+--------|||--------+
|dual-stack lite carrier-grade NAT
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|129.0.0.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 4: SNAT host-based architecture
The resulting solution accepts an IPv4 datagram that is translated
into an IPv4-in-IPv6 softwire datagram for transmission across the
softwire. At the corresponding endpoint, the IPv4 datagram is
decapsulated, and the translated IPv4 address is inserted based on a
translation from the softwire.
Durand Expires January 12, 2010 [Page 21]
Internet-Draft Dual-stack lite July 2009
5.2.1. Example message flow
In the example shown in Figure 5, the translation tables in the dual-
stack lite carrier-grade NAT is configured to forward between IP/TCP
(a.b.c.d/10000) and IP/TCP (129.0.0.1/5000). That is, a datagram
received from the host at address a.b.c.d, using TCP DST port 10000
will be translated a datagram with IP SRC address 129.0.0.1 and TCP
SRC port 5000 in the Internet.
Durand Expires January 12, 2010 [Page 22]
Internet-Draft Dual-stack lite July 2009
+-------------------+
| |
|Host a.b.c.d |
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
| |||2001:0:0:1::1
IPv6 datagram 1| |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:0:0:2::1
+------|-|||--------+
|dual-stack lite carrier-grade NAT
| v ||| |
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |129.0.0.1
IPv4 datagram 2 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 5: Outbound Datagram
Durand Expires January 12, 2010 [Page 23]
Internet-Draft Dual-stack lite July 2009
+-----------------+--------------+---------------+
| Datagram | Header field | Contents |
+-----------------+--------------+---------------+
| IPv6 Datagram 1 | IPv6 Dst | 2001:0:0:2::1 |
| | IPv6 Src | 2001:0:0:1::1 |
| | IPv4 Dst | 128.0.0.1 |
| | IPv4 Src | a.b.c.d |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 2 | IPv4 Dst | 128.0.0.1 |
| | IPv4 Src | 129.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 5000 |
+-----------------+--------------+---------------+
Datagram header contents
When sending an IPv4 packet, the dual-stack lite host encapsulates it
in datagram 1 and forwards it to the dual-stack lite carrier-grade
NAT over the softwire.
When it receives datagram 1, the SC in the dual-stack lite carrier-
grade NAT hands the IPv4 datagram to the NAT, which determines from
its translation table that the datagram received on Softwire_1 with
TCP SRC port 10000 should be translated to datagram 3 with IP SRC
address 129.0.0.1 and TCP SRC port 5000.
Figure 6 shows an inbound message received at the dual-stack lite
carrier-grade NAT. When the NAT function in the dual-stack lite
carrier-grade NAT receives datagram 1, it looks up the IP/TCP DST in
its translation table. In the example in Figure 3, the NAT
translates the TCP DST port to 10000, sets the IP DST address to
a.b.c.d and hands the datagram to the SC for transmission over
Softwire_1. The SI in the dual-stack lite home router decapsulates
IPv4 datagram from the inbound softwire datagram, and forwards it to
the host.
Durand Expires January 12, 2010 [Page 24]
Internet-Draft Dual-stack lite July 2009
+-------------------+
| |
|Host a.b.c.d |
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
^ |||2001:0:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:0:0:2::1
+------|-|||--------+
|dual-stack lite carrier-grade NAT
| | ||| |
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |129.0.0.1
IPv4 datagram 1 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 6: Inbound Datagram
Durand Expires January 12, 2010 [Page 25]
Internet-Draft Dual-stack lite July 2009
+-----------------+--------------+---------------+
| Datagram | Header field | Contents |
+-----------------+--------------+---------------+
| IPv4 datagram 1 | IPv4 Dst | 129.0.0.1 |
| | IPv4 Src | 128.0.0.1 |
| | TCP Dst | 5000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:1::1 |
| | IPv6 Src | 2001:0:0:2::1 |
| | IPv4 Dst | a.b.c.d |
| | IP Src | 128.0.0.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
+-----------------+--------------+---------------+
Datagram header contents
5.2.2. Translation details
The translations happening in the dual-stack lite carrier-grade NAT
are the same as in the previous examples. The well known IPv4
address a.b.c.d out of the e.f.g.h/p (TBD by IANA) range used by all
the hosts are disambiguated by the IPv6 source address of the
softwire.
+---------------------------------+--------------------+
| Softwire-Id/IPv4/Port | IPv4/Port |
+---------------------------------+--------------------+
| 2001:0:0:1::1/a.b.c.d/TCP 10000 | 129.0.0.1/TCP 5000 |
+---------------------------------+--------------------+
Dual-Stack lite carrier-grade NAT translation table
The Softwire-Id is the IPv6 address assigned to the Dual-Stack host.
Each host has an unique Softwire-Id. The source IPv4 address is one
of the well-known IPv4 address (TBD by INAN). The carrier-grade NAT
could receive packets from different hosts sourced from the same IPv4
well-known address from different softwire tunnels. Similar to the
SNAT gateway architecture, the Dual-Stack lite carrier grade NAT
combines the Softwire-Id and IPv4 address/Port [Softwire-Id, IPv4+
Port] to uniquely identify the individual host.
6. Encapsulations
In its simplest deployment model, dual-stack lite only requires IPv4
in IPv6 encapsulation. In more complex scenario where a site gateway
Durand Expires January 12, 2010 [Page 26]
Internet-Draft Dual-stack lite July 2009
would play the role of the softwire initiator, more complex
encapsulation might be desired. Thus dual-stack lite hosts, dual-
stack lite home gateway and dual-stack lite NAT devices MUST at
minimum implement IPv4 in IPv6 encapsulation. On top of that, dual-
stack lite NAT devices MAY also support other encapsulation, like
L2TPv2/v3, GRE, MPLS,... If they do, they SHOULD support L2TPv2 as
defined in the IETF softwire hub & spoke framework.
7. DNS considerations
A dual-satck lite home gateway is only provision on the WAN interface
with IPv6. As such, all configuration information have to be passed
by the broadband service provider over IPv6. This means that the
home gateway will typically use DHCPv6 [RFC3315] to learn the address
of the DNS recursive server as in [RFC3646]. However, DHCPv6 only
defines an option to pass an IPv6 address of a DNS resolver, not an
IPv4 address. IPv6 node inside the home network may very well use
this IPv6 address to reach the DNS resolver, but IPv4 nodes can't.
They need to be configured with an IPv4 address of a recursive DNS
server.
The recommended way to solve this issue is to configure the home
gateway to act as a DNS proxy, advertizing itself internally with
DHCPv4 as an IPv4 DNS resolver and forwarding the DNS request over
IPv6 to the IPv6 DNS resolver address it has received over DHCPv6.
If the home gateway is also acting as a DHCPv6 server for internal
host and is implementing the DHCPv6 DNS option, it can either also
act as a DNS proxy or simply pass through the IPv6 address of the
service provider DNS recursive server. While implementing a DNS
proxy, the home gateway should follow recommendations in
[I-D.ietf-dnsext-dnsproxy].
8. Carrier-grade NAT considerations
A dual-stack lite carrier-grade NAT SHOULD implement behavior
conforming to the best current practice, currently documented in
[RFC4787], [I-D.ietf-behave-tcp] and [I-D.ietf-behave-nat-icmp].
Other requirements for carrier-grade NATs can be found in
[I-D.nishitani-cgn].
9. Port allocation
Because IPv4 addresses will be shared among customers and potentially
a large address space reduction factor may be applied, in average,
only a limited number N of TCP or UDP port numbers will be available
Durand Expires January 12, 2010 [Page 27]
Internet-Draft Dual-stack lite July 2009
per customer. This means that applications opening a very large
number of TCP ports may have a harder time to work. For example, it
has been reported that a very well know web site was using AJAX
techniques and was opening up to 69 TCP ports per web page. If we
make the hypothesis of an address space reduction of a factor 100
(one IPv4 address per 100 customers), and 65k ports per IPv4
addresses available, that makes a total of N=650 ports available
simultaneously to be shared among the various devices behind the
dual-stack lite tunnel end-point.
There is an important operational difference if those N ports are
pre-allocated in a cookie-cutter fashion versus allocated on demand
by incoming connections. This is a difference between an average of
N ports and a maximum of N ports. Several service providers have
reported an average number of connections per customer in the single
digit. At the opposite end, thousands or tens of thousands of ports
could be use in a peak by any single customer browsing a number of
AJAX/Web 2.0 sites. With that average number of connections per
customers in mind, having an address space reduction of a factor 100
or more is realistic.
Application expecting incoming connections, such a peer-to-peer ones,
have become popular. Those applications use a very limited number of
ports, usually a single one. Making sure those applications keep
working in a dual-stack lite environment is important. Similarly,
there is a growing list of applications that require some king of ALG
to work through a NAT. Service provider carrier-grade NATs should
not to be in the way of the deployment of such applications. As
such, there is a legitimate need to leave certain ports under the
control of the end user. This argue for an hybrid environment, where
most ports are dynamically managed by the carrier-grade NAT in a
shared pool and a limited number are dedicated per users and
controlled by them.
More considerations on sharing IPv4 addresses can be found in
[I-D.ford-shared-addressing-issues].
9.1. Static port reservation
A service provider can reserve a static number of ports per user.
Note: those could be TCP and/or UDP ports. The simplest way to allow
users to control the associated NAT bindings is to offer a web
interface (for example as part of the service provider portal) where,
once authenticated, a user can configure each dedicated external IPv4
address/port binding on the carrier-grade NAT in one of the following
way:
Durand Expires January 12, 2010 [Page 28]
Internet-Draft Dual-stack lite July 2009
o either direct the carrier-grade NAT to forward incoming traffic on
this address/port to the dual-stack lite home gateway, and let
this device deal with it. This required support for A+P
[I-D.ymbk-aplusp] semantic on the home gateway.
o or direct the carrier-grade NAT to rewrite the destination address
in those incoming packets to a private IPv4 address within the
home network. For obvious security reasons, redirection to global
IPv4 address should not be authorized. Note: this behavior is
very similar to the port forwarding function found in most home
gateways.
The exact number of ports reserved per user is left at the discretion
of the service provider.
9.2. Dynamic port reservation
9.2.1. UPnP
One could be tempted to have the home gateway relaying UPnP messages
over the tunnel to the carrier-grade NAT. Unfortunately, this would
not work. Some applications insist on running on a well-known port
number (or port range) using UPnP to request the NAT to reserve that
port. Those ports may or may not be available; they could be used by
another customer. Using UPnP, a NAT box does not have any way to
redirect such applications to use another port, the only option is to
deny the request. Those applications typically then cycle through a
small range of ports (typically 10 or so) until they abort. The
likelihood of those ports being all already in use by other users is
very high. As such, UPnP cannot be supported as-is in a dual-stack
lite environment.
oNote: the UPnP forum has been reported to address this issue in an
upcoming version of the IGD profile.
9.2.2. NAT-PMP
NAT-PMP [I-D.cheshire-nat-pmp] offers a better semantic, by enabling
the NAT to redirect the application to use another unallocated port.
A Dual-stack lite home gateway could proxy the NAT-PMP messages to
the carrier-grade NAT through the tunnel.
9.2.3. DHCPv6
If more ports need to be reserved outside of that static dedicated
range, a DHCPv6 option such as
[I-D.bajko-v6ops-port-restricted-ipaddr-assign] may also be an
interesting approach. This may be limited to the A+P semantic
Durand Expires January 12, 2010 [Page 29]
Internet-Draft Dual-stack lite July 2009
mentioned above, as there might not be a way to explicitly control
the port forwarding semantic. Also, there are concerns that this
would lead to a cooky cutter distribution of ports per customers,
dramatically reducing the ratio of customer per IPv4 address.
10. Other carrier-grade NAT considerations
10.1. ALG
The carrier-grade NAT should only perform a minimum number of ALG for
the classic applications such as FTP, RTSP/RTP, IPsec and PPTP VPN
pass-through and enable the users to use their own ALG on statically
or dynamically reserved port instead.
In particular, the carrier-grade NAT SHOULD NOT perform any ALG on
the ports reserved either statically or dynamically for a user.
10.2. MTU
Using an encapsulation (IP-in-IP or L2TP) to carry IPv4 traffic over
IPv6 will reduce the effective MTU of the datagram. Unfortunately,
path MTU discovery [RFC1191] is not a reliable method to deal with
this problem. For IPv4-in-IPv6 softwire [RFC2473], we suggest to
increase the MTU size to the link-MTU + 40 bytes to all the links
between the Dual-Stack lite Tunnel Entry-Point and Tunnel Exit-Point
[RFC2473]. The extra 40 bytes can accommodate both the IPv6
encapsulation header and the IPv4 datagram without fragmenting the
IPv6 packet. If the link MTU cannot be increased, the Tunnel Entry-
Point and Tunnel Exit-Point MUST fragment and reassemble the over-
sized datagram after IPv6 encapsulation. When the Tunnel Entry-Point
forwards a packet larger than the MTU after encapsulation, it MUST
fragment the over-sized IPv6 packet into two IPv6 packets.
Fragmentation happens because the resulted IPv6 packet after
encapsulation is larger than MTU. Thus, fragmentation MUST happen
after the encapsulation on the IPv6 packet. When the Tunnel Exit-
Point receives the fragmented IPv6 packets, it MUST reassemble and
decapsulate the packets. Detailed procedure has been specified in
[RFC2473] Section 7.2.
There is a performance trade-off for this approach. Fragmentation at
the Tunnel Entry-Point is a light-weighted operation. In contrast,
reassembly at the Tunnel Exit-Point can be expensive. When the
Tunnel Exit-Point receives the first fragmented packet, it must wait
for the second fragmented packet to arrive in order to reassemble the
two fragmented IPv6 packets for decapsulation. This requires the
Tunnel Exit-Point to buffer and keep track of fragmented packets.
Consider that the carrier-grade NAT is the Tunnel Exit-Point for many
Durand Expires January 12, 2010 [Page 30]
Internet-Draft Dual-stack lite July 2009
tunnels. If many clients simultaneously source large number of
fragmented packets to the carrier-grade NAT, this will demand the
carrier-grade NAT to buffer and consume enormous resources to keep
track of the flows. This reassembly process will significantly
impact the carrier-grade NAT performance. However, this impact only
happens when many clients simultaneously source large IPv4 packets.
Since we believe that majority of the clients will receive large IPv4
packets (such as watching video streams) instead of sourcing large
IPv4 packets (such as sourcing video streams), so reassembly is only
a fraction of the overall carrier-grade NAT's workload.
Fragmentation/Reassembly could be expensive. We suggest a method to
optimize TCP sessions to reduce the need to fragment and reassemble
TCP packets. When the carrier-grade NAT receive the first TCP SYN
packet which is used to initiate a TCP session, the carrier-grade NAT
rewrites the MSS option in the TCP header to a lower value. When the
carrier-grade NAT receives the returned TCP SYN-ACK for that session,
it will also rewrite the MSS option to a lower value. In the case of
using simple IPv4-in-IPv6, the suggested maximum MSS value is MTU
substracts (IPv6 header + TCP header + IPv4 header). For example: If
the MTU is 1500, the MSS value would be re-written to 1500 - 40 - 20
- 20 = 1420. This optimization tries to assure that the TCP client
and server generate packets smaller than the MTU size after
encapsulation. Hence, fragmentation and reassembly can be avoided
throughout the life-time of this TCP session.
TCP Authentication Option (TCP-AO) [I-D.ietf-tcpm-tcp-auth-opt] is
specified to protect against replays for TCP sessions. In TCP-AO,
when the TCP option flag sets to 0, all TCP options are included in
the MAC calculation. Modifying MSS option by carrier-grade NAT will
alter the Message Authentication Codes (MAC) calculation. Thus, the
TCP-AO originator will consider this is a Man-in-the-Middle attack
and fails the TCP-AO check. When the TCP option flag sets to 1,
TCP-AO will exclude all TCP options in the MAC calculation.
Modifying MSS option will not alter the MAC calculation. Thus,
TCP-AO originator will pass the TCP-AO check. The default TCP-AO
behavior is to set TCP option flag to 0, so using TCP-AO in default
mode with this optimization will cause TCP-AO check to fail. For
those consider to use MSS optimization, we recommend to set the TCP
option flag to 1 when using TCP-AO. TCP-AO is specified to replace
TCP MD5 Signature Option (TCP-MD5) [RFC2385]. TCP-MD5 will continue
to work because TCP-MD5 applies the MD5 algorithm on the TCP header,
excluding options, and assuming a checksum of zero.
11. Future work
The items described bellow could be included in a future version of
Durand Expires January 12, 2010 [Page 31]
Internet-Draft Dual-stack lite July 2009
this document or be the object of a separate document.
11.1. Multicast considerations
This document only describes unicast IPv4 as IPv4 Multicast is not
widely deployed in broadband networks. Some multicast IPv4
considerations might to be discussed as well in a future revision of
this document.
11.2. 3rd party carrier-grade NAT
The dual-stack lite architecture can be easily extended to support
3rd party carrier-grade NATs. The dual-stack lite interface just
need to be pointed to the IPv6 address of that 3rd party carrier-
grade NAT instead of the IPv6 address of the service provider
carrier-grade NAT. Implementation of dual-stack lite should enable
users to override the mechanism used for automatic discovery of the
carrier grade NAT and, for example, manually enter the DNS name of
the selected carrier-grade NAT.
11.3. Interface initialization
The initialization sequence of each interface of a dual-stack lite
node need to be analyzed and heuristics need to be defined to
determined if each interface operates in IPv4 mode, IPv6 mode, dual-
stack mode or dual-stack lite mode. The absence/presence of the
DHCPv6 option discussed above in requests/responses could be a
trigger to decide in which mode to operate.
12. Comparison with an architecture with multiple-layers of NAT
An alternative architecture could consist on layering multiple levels
of IPv4-IPv4 NAT toward the edges of the service provider network.
Such architecture has a key advantage: it would work with any
existing IPv4 home gateway. However, it would have a number of
drawbacks:
o Each NAT device in the path will have its own application level
gateways, increasing the odds of failure or miss-configuration.
o The larger private IPv4 address space available today is Net
10.0.0.0/8. It can in theory accommodate for about 16 million
addresses, in practice, with an 80% allocation efficiency, it can
address about 13 million devices. This may not be enough for
existing and future large scale deployments, thus multiple
overlapping copies of Net 10 might have to be used simultaneously.
This in itself create more complexity:
Durand Expires January 12, 2010 [Page 32]
Internet-Draft Dual-stack lite July 2009
* If multiple copies of Net 10 are in use, network
troubleshooting gets more difficult. One first need to figure
out in which Net 10 realm the customer is before sending a ping
to a home gateway to test it. This means that provisioning
systems need to be modified to include this information.
* Multiple overlapping copies of Net 10 often intersect in some
places with routers and firewalls. The configuration of such
devices need to carefully take into accounts the overlapping
address space. Debugging problems created by miss-
configuration can be time consuming.
o Both legacy customers with global IPv4 addresses and new customers
with private IPv4 addresses may be connected to the same
aggregation router. That router will have to make the decision to
send packets directly to the Internet or via a translator based on
the source address of those packets, which is known as source-
based routing. Although not impossible to implement, this adds
complexity to the management of the network.
None of the issues described above are show stoppers, but put
together, they seriously increase the complexity of the management of
the network.
13. Comparison with NAT-PT (or its potential replacements)
NAT-PT [RFC2766] deals with the translation from IPv6 to IPv4 and
vice versa. As such, it would not help solving the problem of
offering IPv4 service to legacy IPv4 hosts. NAT-PT is targeted at
green field IPv6 deployments, allowing them to access services and
content on the IPv4 Internet. In that sense, NAT-PT could be in
competition with dual-stack lite for green field deployment of new
devices directly connected to the broadband service provider network.
In this situation, NAT-PT has the advantage of enabling to remove
entirely the IPv4 stack on edge devices. This may be critical on
sensor type devices with a very small memory footprint. However, it
is unclear if such devices really need to have access to the whole
global IPv4 Internet in the first place or if they only need to
communicate with servers that can be made IPv6 enable.
In the more general case, dual-stack lite has several advantages over
NAT-PT:
o Dual-stack lite does not require any hack to the DNS. In other
words, there is no need to synthesize fake AAAA records to
represent IPv4 addresses. This make DNSsec works more reliably.
Durand Expires January 12, 2010 [Page 33]
Internet-Draft Dual-stack lite July 2009
o Because of the DNS ALG hack, NAT-PT places restriction on the
topology, in most cases requiring that all exiting traffic go
through a single point of contention. Because there is no DNS ALG
with dual-stack lite and because each dual-stack lite device can
be directed independently to a different dual-stack lite NAT, the
dual-stack lite architecture can scale better.
o ALG sometimes need to manipulate literal IP address in the payload
of packets. In the case of an IPv4-IPv4 NAT, this is a simple 32
bit field replacement. In the case of IPv6-IPv4 (or IPv4-IPv6)
NAT, a 128 bit field need to be substituted by a 32 bit field (or
vice versa). This makes NAT-PT ALG more complex than dual-stack
lite NAT ALG.
For more detail on NAT-PT related issues, see [RFC4966].
14. Comparison with DSTM
DSTM [I-D.bound-dstm-exp] was addressing IPv6 backward compatibility
with IPv4 by providing a temporary IPv4 address to dual-stack nodes.
Connectivity was also provided by the way of IPv4-in-IPv6 tunnels.
However, DSTM was relying on nodes acquiring and releasing IPv4
addresses on a need to have basis. It is the authors' opinion that
such mechanism may not provide the necessary savings in address space
for large scale broadband deployments.
15. Acknowledgements
The authors would like to acknowledge the role of Mark Townsley for
his input on the overall architecture of this technology by pointing
this work in the direction of [I-D.droms-softwires-snat]. Note that
this document results from a merging of [I-D.durand-dual-stack-lite]
and [I-D.droms-softwires-snat].Also to be acknowledged are the many
discussions with a number of people including Shin Miyakawa,
Katsuyasu Toyama, Akihide Hiura, Takashi Uematsu, Tetsutaro Hara,
Yasunori Matsubayashi, Ichiro Mizukoshi. The author would also like
to thank David Ward, Jari Arkko, Thomas Narten and Geoff Huston for
their constructive feedbacks. A special thank you goes to Dave
Thaler for his review and comments.
16. IANA Considerations
This draft request IANA to allocate a well know IPv4 e.f.g.h/29
network prefix. That range is used to number the dual-stack lite
interfaces. Reserving a /29 allows for 6 possible interfaces on a
Durand Expires January 12, 2010 [Page 34]
Internet-Draft Dual-stack lite July 2009
multi-home node. The last IPv4 address of this range is reserved as
the IPv4 address of the default router for such dual-stack lite
hosts.
17. Security Considerations
Security issues associated with NAT have long been documented. See
[RFC2663] and [RFC2993].
However, moving the NAT functionality from the home gateway to the
core of the service provider network and sharing IPv4 addresses among
customers create additional requirements when logging data for abuse
usage. With any architecture where an IPv4 address does not uniquely
represent an end host, IPv4 addresses and a timestamps are no longer
sufficient to identify a particular broadband customer. Additional
information such as transport protocol information will be required
for that purpose. For example, we suggest to log the transport port
number for TCP and UDP connections.
The carrier-grade NAT performs translation functions for interior
IPv4 hosts at RFC 1918 addresses or at the IANA reserved address
range (TBA by IANA). If the interior host is properly using the
authorized IPv4 address with the authorized transport protocol port
range such as A+P semantic for the tunnel, the carrier-grade NAT can
simply forward without translation to permit the authorized address
and port range to function properly. All packets with unauthorized
interior IPv4 addresses or with authorized interior IPv4 address but
unauthorized port range MUST NOT be forwarded by the carrier-grade
NAT. This prevents rogue devices from launching denial of service
attacks using unauthorized public IPv4 addresses in the IPv4 source
header field or unauthorized transport port range in the IPv4
transport header field. For example, rogue devices could bombard a
public web server by launching TCP SYN ACK attack. The victim will
receive TCP SYN from random IPv4 source addresses at a rapid rate and
deny TCP services to legitimate users.
Similarly, some attack mitigation techniques put an IPv4 address in a
"penalty box" for a period of time if an abnormal behavior is
observed. Such techniques may need to be revisited as they would
impact more than just one user (presumably the offender) at a time.
With IPv4 addresses shared by multiple users, ports become a critical
resource. As such, some mechanisms need to be put in place by a
carrier-grade NAT to limit port usage, either by rate-limiting new
connections or putting a hard limit on the maximum number of port
usable by single user. If this number is high enough, it should not
interfere with normal usage and still provide reasonable protection
Durand Expires January 12, 2010 [Page 35]
Internet-Draft Dual-stack lite July 2009
of the shared pool.
More considerations on sharing IPv4 addresses can be found in
"I-D.ford-shared-addressing-issues".
If some form of IPv6 ingress filtering is deployed in the broadband
network and dual-stack lite service is restricted to those customers,
then tunnels terminating at the carrier-grade NAT and coming from
registered customer IPv6 addresses cannot be spoofed. Thus a simple
access control list on the tunnel transport source address is all
what is required to accept traffic on the southbound interface of a
carrier-grade NAT.
18. Author's Address
This document is the result of the work of the following authors:
Alain Durand
Comcast
1, Comcast center
Philadelphia, PA 19103
USA
Email: alain_durand@cable.comcast.com
Ralph Droms
Cisco
1414 Massachusetts Avenue
Boxborough, MA 01714
USA
Phone: +1 978.936.1674
Email: rdroms@cisco.com
Brian Haberman
Johns Hopkins University Applied Physics Lab
11100 Johns Hopkins Road
Laurel, MD 20723-6099
USA
Phone: +1 443 778 1319
Email: brian@innovationslab.net
Durand Expires January 12, 2010 [Page 36]
Internet-Draft Dual-stack lite July 2009
James Woodyatt
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Email: jhw@apple.com
Yiu Lee
Comcast
1, Comcast center
Philadelphia, PA 19103
USA
Email: yiu_lee@cable.comcast.com
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington 98110
USA
Phone: +1 206 780 0431 x1
Email: randy@psg.com
19. References
19.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
19.2. Informative references
[I-D.bajko-v6ops-port-restricted-ipaddr-assign]
Bajko, G. and T. Savolainen, "Port Restricted IP Address
Assignment",
draft-bajko-v6ops-port-restricted-ipaddr-assign-02 (work
in progress), November 2008.
[I-D.bound-dstm-exp]
Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism
(DSTM)", draft-bound-dstm-exp-04 (work in progress),
October 2005.
[I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008.
Durand Expires January 12, 2010 [Page 37]
Internet-Draft Dual-stack lite July 2009
[I-D.despres-sam]
Despres, R., "Stateless Address Mapping (SAM) Avoiding
NATs and restoring the end-to-end model in IPv6",
draft-despres-sam-02 (work in progress), March 2009.
[I-D.dhankins-softwire-tunnel-option]
Hankins, D., "Dynamic Host Configuration Protocol Option
for Dual-Stack Lite",
draft-dhankins-softwire-tunnel-option-03 (work in
progress), March 2009.
[I-D.droms-softwires-snat]
Droms, R. and B. Haberman, "Softwires Network Address
Translation (SNAT)", draft-droms-softwires-snat-01 (work
in progress), July 2008.
[I-D.durand-dual-stack-lite]
Durand, A., "Dual-stack lite broadband deployments post
IPv4 exhaustion", draft-durand-dual-stack-lite-00 (work in
progress), July 2008.
[I-D.ford-shared-addressing-issues]
Durand, A., Ford, M., and P. Roberts, "Issues with ISP
Responses to IPv4 Address Exhaustion",
draft-ford-shared-addressing-issues-00 (work in progress),
March 2009.
[I-D.ietf-behave-nat-icmp]
Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP protocol",
draft-ietf-behave-nat-icmp-12 (work in progress),
January 2009.
[I-D.ietf-behave-tcp]
Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP",
draft-ietf-behave-tcp-08 (work in progress),
September 2008.
[I-D.ietf-dnsext-dnsproxy]
Bellis, R., "DNS Proxy Implementation Guidelines",
draft-ietf-dnsext-dnsproxy-06 (work in progress),
July 2009.
[I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05
(work in progress), July 2009.
Durand Expires January 12, 2010 [Page 38]
Internet-Draft Dual-stack lite July 2009
[I-D.nishitani-cgn]
Nishitani, T., Miyakawa, S., Nakagawa, A., and H. Ashida,
"Common Functions of Large Scale NAT (LSN)",
draft-nishitani-cgn-02 (work in progress), June 2009.
[I-D.ymbk-aplusp]
Bush, R., Maennel, O., Zorz, J., Bellovin, S., and L.
Cittadini, "The A+P Approach to the IPv4 Address
Shortage", draft-ymbk-aplusp-03 (work in progress),
March 2009.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
Durand Expires January 12, 2010 [Page 39]
Internet-Draft Dual-stack lite July 2009
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
[RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B.,
Toutain, L., and J. Tremblay, "Softwire Hub and Spoke
Deployment Framework with Layer Two Tunneling Protocol
Version 2 (L2TPv2)", RFC 5571, June 2009.
[UPnP-IGD]
UPnP Forum, "Universal Plug and Play Internet Gateway
Device Standardized Gateway Device Protocol",
September 2006,
<http://www.upnp.org/standardizeddcps/igd.asp>.
Author's Address
Alain Durand (editor)
Comcast
1, Comcast center
Philadelphia, PA 19103
USA
Email: alain_durand@cable.comcast.com
Durand Expires January 12, 2010 [Page 40]
