Network Working Group Qiong Sun
Internet Draft Chongfeng Xie
Intended status: Standards Track China Telecom
Expires: April 24, 2011 March 15, 2011
LAFT6: Lightweight address family transition for IPv6
draft-sun-v6ops-laft6-01.txt
Abstract
With the approaching exhaustion of IPv4 address space, large-scale
ISPs are now facing the option to deploy IPv6 in a timely manner.
However, most existing IPv6 transition solutions have tradeoff
between scalability and efficiency. This draft proposes a lightweight
address family transition mechanism named LAFT6. It only needs to
maintain per-subscriber state entries in core network and there is no
specific address format requirement for users' IPv6 address. It is a
lightweight solution in terms of state-management, addressing and
routing. The experimental results have shown that LAFT6 is scalable
and can be rapidly deployed in commercial ISP network.
Status of this Memo
This Internet-Draft is submitted 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 September 15,2011.
Sun Expires September 24 2011 [Page 1]
Internet-Draft Lightweight address family transition March 2011
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in
the Simplified BSD License.
Table of Contents
1. Introduction ................................................ 3
2. Terminologies ............................................... 4
3. LAFT6 Overview .............................................. 5
3.1. Features of LAFT6....................................... 5
3.2. Deployment scenario..................................... 6
3.3. LAFT6 solution overview................................. 7
3.4. LAFT6 workflow ......................................... 7
4. LAFT-CGW element ........................................... 10
4.1. Initialization ........................................ 10
4.2. Extended Binding Table................................. 11
4.3. Packet Translation..................................... 11
4.4. Encapsulation/De-encapsulation......................... 12
4.5. Fragmentation and Reassembly........................... 12
4.6. LAFT-NGW discovery..................................... 12
4.7. DNS ................................................... 13
5. LAFT-NGW element ........................................... 13
5.1. Port-range Binding Table............................... 13
5.2. Encapsulation ......................................... 13
5.3. Fragmentation and Reassembly........................... 13
5.4. DNS ................................................... 14
6. Deployment Considerations for Broadband Provider............ 14
6.1. Addressing and Routing................................. 14
6.2. DNS ................................................... 14
6.3. AAA and User Management................................ 14
6.4. Placement in Large SP Network.......................... 15
6.5. ALG consideration...................................... 15
7. Security Considerations..................................... 15
8. IANA Considerations ........................................ 15
9. Appendix A: Experimental Result............................. 15
Sun Expires September 15, 2011 [Page 2]
Internet-Draft Lightweight address family transition March 2011
9.1. Experiment environment................................. 16
9.2. Experiment configuration............................... 16
9.3. Experiment results..................................... 17
9.4. Conclusions ........................................... 17
10. References ................................................ 18
11. Acknowledgments ........................................... 19
1. Introduction
Global IPv4 address exhaustion is becoming reality. The dramatic
growth of the Internet is accelerating the consumption of available IPv4
addresses, which makes the address shortage problem even worse. It is
widely accepted that IPv6 is the only answer to solve the address
shortage problem and sustain the long-term growth of the Internet.
However, IPv6 deployment is a huge systematic project and a lot of
challenges will arise especially in large SP operational network.
In order to facilitate smooth migration to IPv6-based Internet, many
factors need to be taken into consideration, e.g. rapid deployment,
scalability, backward compatibility, legal traceability and IPv6
encouragement. Thereinto, high scalability and efficiency are two
factors which cannot be easily accomplished in the same time.
Currently, most existing IPv6 transition mechanisms can be wildly
divided into stateful and stateless solutions. Stateful ones, e.g. DS-
Lite[I-D.ietf-softwire-dual-stack-lite], NAT64 [I-D.ietf-behave-v6v4-
xlate-stateful], etc., need to keep per-session state in CGN. This will
result in severe scalability problem especially for large-scale ISP
networks. Moreover, the dynamic feature of session-based states will
also bring a great burden on load balancing with state synchronization
and legal traceability.
While for stateless solutions, it has strict IPv6 address-format
restriction in order to achieve algorithm-based translation. It is very
scalable, simple and straightforward; however, it would also have impact
on existing address allocation systems, CPE prefix delegation models and
routing systems. Since these IPv6 addresses with embedded port index are
not continuous anymore, existing DHCPv6 server have to introduce
additional function to deal with port-range allocation, either by
specifying individual IPv6 address for each end subscriber manually in
DHCPv6 pool configuration, or taking modifications for automatic
configuration. And then, CPE should re-allocate IPv6 address to end-user
based on PD prefix, and announce individual IPv6 routing entry to access
Sun Expires September 15, 2011 [Page 3]
Internet-Draft Lightweight address family transition March 2011
routers. These functionalities have not been fully supported by existing
systems.
Therefore, existing solutions do not have a good tradeoff between
stateful and stateless ones.
For large scale operators, it is of vital importance to achieve high
scalability and simplicity in core network. It is one of the key
principles in the overall development of Internet and it would also be
very important in the future. Although it is inevitable to multiplex
IPv4 address with port range in IPv4/IPv6 coexistence period when the
common problems discussed in [I-D.ietf-intarea-shared-addressing-issues]
could not be totally avoided, a lightweight state-management solution is
still encouraged. It could simplify the packet processing procedure,
state synchronization and traffic logging, etc., compared to session-
based stateful solution.
Furthermore, it is also very important for network operators to
adopt flexible addressing. A solution with no specific addressing
requirement can make use of existing IPv6 addressing and routing model
as much as possible. As a result, it can be rapidly deployed in
operational network when facing pressing IPv4 address shortage problem.
Network operators could further define more flexible addressing plans
according to different service requirement.
In this document, we propose a scalable lightweight solution named
LAFT6. It only needs to maintain per-subscriber state entries in core
network and there is no specific address format requirement for each
IPv6 address.
2. Terminologies
LAFT-CGW LAFT Customer-side Gateway
LAFT-NGW LAFT Network-side Gateway
Addr4-user IPv4 address for end node
Addr4-CGW-pub Multiplex Public IPv4 address for LAFT-CGW
Addr6-user IPv6 address for end node
Addr6-CGW IPv6 address for LAFT-CGW
Addr6-NGW IPv6 address for LAFT-CGW
Port-range-CGW Port range of LAFT-CGW
Sun Expires September 15, 2011 [Page 4]
Internet-Draft Lightweight address family transition March 2011
Pref64 Prefix for translation
4to4 table: binding table in LAFT-CGW for IPv4 sources with IPv4
receivers
6to4 table: binding table in LAFT-CGW for IPv6 sources with IPv4
receivers
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
3. LAFT6 Overview
3.1. Features of LAFT6
Instead of relying on a large carrier-grade session-based NAT, LAFT6
solution is built on IPv4-in-IPv6 tunnels to reach a lightweight
subscriber-based NAT in the carrier side. Two major features of LAFT6
are lightweight state management and addressing.
For lightweight state management, LAFT6-NGW only needs to maintain
the mapping pair between IPv4 address (denoted by Addr4-CGW-pub),
available port range (denoted by Port-range-CGW) with IPv6
address( denoted by Addr6-CGW)for each subscriber. It would be stable
during one login process for each subscriber. Thus, it could
dramatically reduce the size of state database compared to session-based
solutions, e.g. DS-Lite, NAT444, NAT64, etc. There are numbers of
benefits to this feature:
o The state management in Carrier-grade NAT is largely simplified,
including searching, inserting and deleting process, not only due
to the fact that the size of state database has been reduced to a
great extend, but also the number of dimension for each state has
been decreased from 5-dimensional session-based tuple to 3-
dimensional subscriber-based tuple (IPv6 address, IPv4 address and
port range). Therefore, it can easily support larger amount of
subscribers when deployed in the same placement than session-based
solutions.
Sun Expires September 15, 2011 [Page 5]
Internet-Draft Lightweight address family transition March 2011
o It can simplify the complexity in traffic logging system. It only
needs to record IPv4 address, available port range, IPv6 address
and time stamp for each subscriber. While for session-based
solution, logging system needs to record the 6-dimensional tuple
including IPv4 source address, IPv4 destination address, source
port, destination port, protocol and timestamp, other than
solutions taking into account the advice given in [I-D.behave-
natx4-log-reduction].
o State synchronization and HA (High Availability) is easier to
achieve since the binding state for a specific subscriber is more
stable during the whole login process.
For lightweight addressing, LAFT6 has no additional requirements on
IPv6 address format. In this way, the addressing and routing of the
service provider access network is simplified by leveraging existing
IPv6 addressing and routing system. And more flexible addressing for
different services and applications can be achieved conveniently. As a
result, LAFT6 can be deployed rapidly in operational network.
3.2. Deployment scenario
The LAFT6 function is implemented in a customer side gateway (LAFT-CGW)
and a carried grade gateway (LAFT-NGW) (as depicted in Figure1).
+------+
// \\ ------------
/ \ / \
+------+ + +----------+ |
| IPv4 +-----+ | | LAFT-NGW | IPv4 Internet |
| node | | | +----------+ |
+------+ | +----------+ IPv6-only | \ /
+--+ LAFT-CGW | network | ------------
| | HGW | |
| +----------+ | ------------
+------+ | | | / \
| IPv6 | | | +----------+ |
| node |-----+ | | CR | IPv6 Internet |
+------+ + +----------+ |
\ / \ /
\\ // ------------
+------+
Figure 1 LAFT6 deployment scenario
It is mainly designed for end nodes with a customer gateway in
broadband access network. For example, in the future home network, it
would be common that there are IPv4-only computers, dual-stack computers,
Sun Expires September 15, 2011 [Page 6]
Internet-Draft Lightweight address family transition March 2011
IPv6-only sensors located behind the same home gateway. Therefore, LAFT-
CGW is designed to accommodate different scenarios gracefully and it is
up to LAFT-CGW to determine which scenario it would like to support,
while LAFT-NGW is simple and it can deal with different scenarios in the
same way.
LAFT6 can be applied to both scenarios where IPv4 sources
communicate IPv4 receivers (denoted as 4to4) and IPv6 sources
communicate with IPv4 receivers (denoted as 6to4). It can also support
IPv6 sources communicating with IPv6 receivers in a native way without
further treatment.
In home Local Area network, which is characterized by the presence
of a home gateway, or CPE, provisioned only with IPv6 by the service
provider, a LAFT CPE is an IPv6-aware device with a LAFT-CGW Interface
implemented in the WAN interface. LAFT-NGW element is implemented in a
device which has (at least) two interfaces, an IPv4 interface connected
to the IPv4 network, and an IPv6 interface connected to the IPv6 network.
It is usually deployed in core network.
3.3. LAFT6 solution overview
In the initial phase, the end user and LAFT-CGW(e.g. located in Home
gateway) would get their individual IPv6 address (denoted as Addr6-user
and Addr6-CGW) through traditional PPPoE, IPoE, etc. Besides, the end
user would also get its private IPv4 address (denoted as Addr4-user)
which is determined by LAFT-CGW only. After that, LAFT-CGW would be
allocated a port range (denoted as Port-range-CGW), a public address
(denoted as Addr4-CGW-pub) via PCP protocol [I-D.tsou-pcp-natcoord], and
notify LAFT-NGW with its own IPv6 address (Addr6-CGW). LAFT-NGW would
keep 3-tuple, which includes Addr4-CGW-pub, Port-range-CGW and Addr6-CGW.
In LAFT6, LAFT-CGW can deal with session-based packet translation
like traditional NAT, except that it would change the randomly generated
source port to a valid port number within the range of Port-range-CGW.
At the same time, it will deal with different scenarios accordingly.
While in LAFT-NGW, on the other hand, it only needs to do packet
encapsulation/ de-encapsulation according to the address mapping table
in LAFT-NGW for different scenarios. Although it is a little complicated
in LAFT-CGW, there will be not many new functionalities to implement
since customer-side NAT is a quite common function for most current CPEs.
3.4. LAFT6 workflow
For upstream packets originated from IPv4 sources and destined for a
receiver located in the IPv4 network, LAFT-CGW will firstly change the
randomly generated source port to a valid port selected from Port-range-
Sun Expires September 15, 2011 [Page 7]
Internet-Draft Lightweight address family transition March 2011
CGW, then change the private IPv4 address to its Addr4-CGW-pub and
encapsulate in IPv6 packet directed to LAFT-NGW. The corresponding
mapping table with IPv4 addresses and port number will be maintained in
LAFT-CGW. The LAFT-NGW will only need to de-encapsulate the packet and
forward them as IPv4 packets through the IPv4 network to the IPv4
receiver. There is no packet translation in LAFT-NGW anymore. For
downstream IPv4 packet, LAFT-NGW will extract the IPv4 destination
address and destination port from the incoming packet, lookup the
mapping table, determine the corresponding IPv6 address and then
tunneled to LAFT-CGW. LAFT-CGW will also de-encapsulate the packet,
lookup the mapping table for each packet, determine the original port
number and private IPv4 address, and translate the packet back again.
The workflow of 4to4 communication is depicted in the following
Figure 2.
+-----------+ Packet Workflow Example
| Host |
+-----+-----+ +---------------------------+
192.168.0.2 | |src address: 192.168.0.2|
| |src port: 9201 |
| +---------------------------+
192.168.0.1 |
+---------|---------+
| | |
| Home Gateway |
|+--------+--------+|
|| LAFT-CGW ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+--------|||--------+ +---------------------------+
2001:c68:0:1::1||| |src addr6: 2001:c68:0:1::1|
210.25.112.69||| |src addr4: 210.25.112.69 |
IPv4-in-IPv6 Tunnel->>||| |src port: 2001 |
||| +---------------------------+
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||------- +---------------------------+
||| |src addr4: 210.25.112.69 |
2001:c68:0:2::1||| |src port: 2001 |
210.25.112.69||| +---------------------------+
+--------|||--------+
| LAFT-NGW |
| | |
Sun Expires September 15, 2011 [Page 8]
Internet-Draft Lightweight address family transition March 2011
+---------|---------+
210.25.112.69|
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 2 Workflow of 4to4 communication
For packets generated from IPv6 sources for a receiver located in
the IPv4 network, the LAFT-CGW will not only need to change the random
source port to a valid port in the Port-range-CGW,and change the IPv6
address to Addr4-CGW-pub, but also translate the IPv6 packet to an IPv4
packet. Then, the traversed IPv4 packet with Addr4-CGW-pub will also be
encapsulated in IPv6 packet and then tunneled to LAFT-NGW. In this IPv6
header, the source address is Addr6-CGW, rather than Addr6-user in the
original IPv6 packet generated by IPv6 source. LAFT-NGW will take the
same procedure as in the 4to4 scenario.
The workflow of 6to4 communication is depicted in the following
Figure 3.
+-----------+ Packet Workflow Example
| Host |
+-----+-----+
2001:c68:0:3::2||| +---------------------------+
||| |src addr6: 2001:c68:0:3::2 |
||| |src port: 9103 |
2001:c68:0:3::1||| +---------------------------+
+---------|---------+
| | |
| Home Gateway |
|+--------+--------+|
|| LAFT-CGW ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+--------|||--------+ +---------------------------+
2001:c68:0:1::1||| |src addr6: 2001:c68:0:1::1|
210.25.112.69||| |src addr4: 210.25.112.69 |
IPv4-in-IPv6 Tunnel->>||| |src port: 2002 |
Sun Expires September 15, 2011 [Page 9]
Internet-Draft Lightweight address family transition March 2011
||| +---------------------------+
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||------- +---------------------------+
||| |src addr4: 210.25.112.69 |
2001:c68:0:2::1||| |src port: 2002 |
210.25.112.69||| +---------------------------+
+--------|||--------+
| LAFT-NGW |
| | |
+---------|---------+
210.25.112.69|
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 3 Workflow of 6to4 communication
4. LAFT-CGW element
The LAFT-CGW element is a function implemented on CPE. LAFT-CGW need
to perform initialization, build extended binding table, do packet
translation, encapsulation, fragmentation and reassembly, and DNS proxy,
etc.
4.1. Initialization
In the initialization phase, each LAFT-CGW device will get its own
IPv6 address by existing user authentication process, and it will also
get Addr4-CGW-pub and Port-range-CGW by extended protocols [].
Furthermore, it would allocate private IPv4 address to IPv4 or dual-
stack end-users.
<We will add additional port range considerations in the next version>.
Sun Expires September 15, 2011 [Page 10]
Internet-Draft Lightweight address family transition March 2011
4.2. Extended Binding Table
There are two kinds of binding tables in LAFT-CGW element: one is
4to4 scenario (denoted as 4to4 table) and the other is 6to4 scenario
(denoted as 6to4 table).
There are conceptual dynamic data structures to construct the 4to4
and 6to4 binding table, with TCP, UDP and ICMP respectively. In case of
TCP and UCP, each state entry specifies a mapping between the IP address
and port number:
(X',x) <--> (T,y)
where X' is Addr4-user in 4to4 mapping table and is Addr6-user in 6to4
table, T is the Addr4-CGW-address for both 4to4 table and 6to4 table, x
is the original random port created by upper-layer application for LAFT-
CGW and y is the translated port in Port-range-CGW. A given IPv6 or IPv4
transport address can appear in at most one entry in a binding table
since TCP and UDP have separate binding tables because TCP and UDP have
different port number space.
In the case of the ICMP Query, each ICMP Query binding entry
specifies a mapping between an (IP address, ICMP Identifier) pair.
(X',i1) <--> (T,i2)
where X' and T are the same as in the above table, i1 and i2 are an ICMP
Identifiers in 4to4 case and are an ICMPv6 Identifiers in 6to4 case. A
given (IPv6 or IPv4 address, ICMPv6 or ICMPv4 Identifier) pair can
appear in at most one entry in the ICMP Query.
Each upstream packet will construct a binding entry in case there is
no existing binding entry in the extended binding table. It will
determine the traversed port number for each packet. For downstream
packet, LAFT-CGW knows how to re-construct IPv4/IPv6 packet when the
packets comes back from by doing a reverse look-up in the extended IPv4
NAT binding table.
4.3. Packet Translation
In LAFT-CGW, packet translation includes network-layer header
translation and transport-layer header translation.
o Network-layer header translation
Sun Expires September 15, 2011 [Page 11]
Internet-Draft Lightweight address family transition March 2011
For both IPv4 and IPv6 packet, it will change the end user address
to Addr4-CGW. For IPv6 packet, it MUST be performed according to SIIT
[RFC2765] except the source addresses in the header.
o Transport-layer header translation
In LAFT-CGW, source port should be changed to the conversed port
according to extended binding table. Since the TCP and UDP headers
[RFC0793] [RFC0768] consist of check sums which include the IP header,
the recalculation and updating of the transport-layer headers MUST be
performed.
4.4. Encapsulation/De-encapsulation
The tunnel is a multi-point to point IPv4-in-IPv6 tunnel ending on a
service provider LAFT-NGW. The upstream IPv4 packet will be encapsulated
in IPv6 header and tunneled to LAFT-NGW. In the same way, the downstream
IPv6 tunneled packet will be de-encapsulated in LAFT-CGW.
4.5. Fragmentation and Reassembly
Fragmentation and Reassembly is the most time-consuming task for
LAFT-CGW. Thus, it is better to deal with this problem, either by
increasing the MTU size of all the links between the LAFT-CGW element
and the LAFT-NGW elements or by limiting the size of packet generated by
end users.
However, as not all service providers will be able to control the
links or the packet size, the LAFT-CGW element MUST perform
fragmentation and reassembly if the outgoing link MTU cannot accommodate
the packet IPv6 transmission due to the addition of the extra IPv6
header.
Fragmentation MUST happen after the encapsulation on the IPv6 packet.
Reassembly MUST happen before the de-capsulation of the IPv6 header. The
IETF standard for Fragmentation and MTU Handling is defined in [I-
D.ietf-behave-v6v4-xlate], which contains updated technical
specifications.
4.6. LAFT-NGW discovery
In order to configure the IPv4-in-IPv6 tunnel, the LAFT-CGW element
needs the IPv6 address of the LAFT-NGW element. In order to guarantee
interoperability, a LAFT-CGW element SHOULD implement the DHCPv6 option
defined in [I-D.ietf-softwire-ds-lite-tunnel-option].
Sun Expires September 15, 2011 [Page 12]
Internet-Draft Lightweight address family transition March 2011
4.7. DNS
A LAFT-CGW element is only configured from the service provider with
IPv6 address, so it can only learn the address of a DNS recursive server
through DHCPv6 (or other similar method over IPv6). As DHCPv6 only
defines an option to get the IPv6 address of such a DNS recursive server,
the LAFT-CGW element cannot easily discover the IPv4 address of such a
recursive DNS server, and as such will have to perform all DNS
resolution over IPv6. As a result, the LAFT-CGW element SHOULD implement
a DNS proxy, following the recommendations of [RFC5625].
When LAFT6 is applied to 6to4 scenario, it should also perform DNS64
[I-D.ietf-behave-dns64] in case there is no DNS64 server located in the
local network. It should be configured with a Pref64 to synthesize IPv6
address. For AAAA request, the DNS64 will query the AAAA response. If
there is no response for a certain period, it will reconstruct an A
request and synthesize an AAAA response.
5. LAFT-NGW element
An LAFT-NGW element is the combination of an IPv4-in-IPv6 tunnel
end-point. LAFT-NGW element is a light-weight end-point which only needs
to do port-range management, encapsulation, fragmentation and reassembly,
etc.
5.1. Port-range Binding Table
In LAFT-NGW, there is one Port-range Binding tale for TCP, UDP and
ICMP. Each state entry specifies a mapping between the IP address, port
range:
(X') <--> (T,pr)
where X' is the IPv6 address of LAFT-CGW (Addr6-CGW), T is the user's
Addr4-CGW, and pr is Port-range-CGW for each user. pr can be continuous,
discrete or partial random. This binding table can be used for both 4to4
and 6to4 scenarios.
5.2. Encapsulation
The tunnel is a point-to-multipoint IPv4-in-IPv6 tunnel ending at
the LAFT-CGW elements.
5.3. Fragmentation and Reassembly
Fragmentation and Reassembly will be performed if the underlying
link MTU cannot accommodate packet transmission due to addition of the
Sun Expires September 15, 2011 [Page 13]
Internet-Draft Lightweight address family transition March 2011
extra IPv6 header of the tunnel. Fragmentation MUST happen after the
encapsulation on the IPv6 packet. Reassembly MUST happen before the de-
capsulation of the IPv6 header.
Methods to avoid fragmentation, such as rewriting the TCP MSS option
or using technologies such as Subnetwork Encapsulation and Adaptation
Layer defined in [I-D.templin-seal] are out of scope for this document.
5.4. DNS
As noted previously, LAFT6 node implementing a LAFT-CGW element will
perform DNS resolution over IPv6. As such, very few, if any, DNS packets
will flow through the LAFT-NGW element.
6. Deployment Considerations for Broadband Provider
6.1. Addressing and Routing
In LAFT6, there is no additional addressing and routing requirements.
Thus, the process of IPv6 address assignment and routing entry
establishment can be integrated with existing IPv6 address allocation
process, e.g. using PPPoE or IPoE, etc.
6.2. DNS
In LAFT6, since there is no IPv4 DNS server in IPv6-only network, it
is recommended that LAFT-CGW should implement IPv4-to-IPv6 DNS Proxy to
convert an IPv4 DNS request/response to IPv6 DNS request/response
accordingly.
When applied to scenarios for IPv6 sources communicating with IPv6
receivers, DNS64 should be deployed. In case there is no DNS64 deployed
in IPv6 operational network, it is recommended that DNS64 should be
integrated into LAFT-CGW.
6.3. AAA and User Management
User authentication can be used to control who can have the LAFT6
connectivity service. In the initial phase of deployment, the maximum
number of port number for subscribers can be configured uniformly in
LAFT-NGW. But it is still recommended that AAA would define the maximum
number of port number for different subscribers to offer better security
and differentiated service.
Sun Expires September 15, 2011 [Page 14]
Internet-Draft Lightweight address family transition March 2011
6.4. Placement in Large SP Network
Normally, LAFT-NGW can be deployed in "centralized model" and
"distributed model".
In "centralized model", LAFT-NGW could be deployed in the place of
Core Router. Since LAFT-NGW has good scalability and it can handle
numerous concurrent sessions, we strongly recommend adopting
"centralized model" for LAFT6 as it is a cost-effective way and easy to
manage.
In "distributed model", LAFT-NGW is usually be integrated with
BRAS/SR. Since the newly emerging customers might be distributed in the
whole Metro area, we have to deploy LAFT-NGW on all BRAS/SRs. This will
cost a lot in the initial phase of IPv6 transition period.
6.5. ALG consideration
Currently, LAFT6 can support most of existing applications, such as
HTTP, SSH and Telnet. However, some applications are designed such that
IP addresses are used to identify application-layer entities (e.g. FTP).
In these cases, application layer gateway (ALG) is unavoidable, and it
can be integrated into the LAFT-CGW.
Since there is no address and port mapping in LAFT-NGW, there is no
ALG needed anymore in carrier side network.
7. Security Considerations
There are no security considerations in this document.
8. IANA Considerations
This memo adds no new IANA considerations.
9. Appendix A: Experimental Result
We have tested LAFT6 using the prototype in our operational network
of HuNan province, China. The major objective listed in the following is
to verify the functionality and performance of LAFT6:
O Verify how to deploy LAFT6 in practical network.
O Verify what applications can be used in LAFT6.
O Verify the effect of user experience with limited ports.
Sun Expires September 15, 2011 [Page 15]
Internet-Draft Lightweight address family transition March 2011
O Verify the performance of LAFT6.
9.1. Experiment environment
The network topology for this experiment is depicted in Figure 4.
+-----+ +-----+
|Host1+--+ CGW +----+ --------
+-----+ +-----+ | /// \\\
| /------\ // \\
| // \\ +-----+ | |
+-----+ +-----+ +-+--+ | IPv6 | | | | IPv4 Internet |
|Host2+--+ CGW +--+BRAS+--| Network |---| NGW +--+ |
+-----+ +-----+ +-+--+ \\ // | | \\ //
| \---+--/ +-----+ \\\ ///
| | ---------
+-----+ +-----+ | |
|Host3+--+ CGW +----+ |
+-----+ +-----+ | ------
| // \\
| / \
+-------------------+IPv6 Internet +
| |
\ /
\\ //
-------
Figure 4 LAFT6 topology in the test
There are three key components in the test:
o The Hosts are dual-stack or IPv6-only customers, who could run
IPv4 application, IPv6 application or dual stack application.
o The Home Gateways (Hgw) are LAFT-CGW in user side. It would do
packet translation, encapsulation, fragmentation and reassembly,
and DNS proxy, etc.
o The LAFT-NGW encapsulate/de-encapsulate the packet according to
the mapping table in LAFT-NGW.
9.2. Experiment configuration
For address configuration, each host will get it IPv6 address
through PPPoE process. And there is no explicit routing configuration
needed.
Sun Expires September 15, 2011 [Page 16]
Internet-Draft Lightweight address family transition March 2011
For port configuration, we allocate each user with 2000 maximum
available ports in LAFT-NGW. We have not implement AAA system with
additional port-number notification.
For DNS configuration, since LAFT-CGW has implemented DNS64 itself,
there is no DNS64 needed anymore in our operational network.
9.3. Experiment results
In our trial, we mainly have taken the following tests:
o Application test: The applications we have tested include web,
email, Instant Message, ftp, telnet, SSH, video, Video Camera, P2P,
online game, Voip, VPN and so on.
o Operating System test: The OS we have tested includes Win7, VISTA,
windows XP.
o Performance test: We have measured the parameters of concurrent
session number, throughput performance.
The experimental results are listed as follows:
|----------------------|-------------------------------------------|
| Type | Experiment Result |
|----------------------|-------------------------------------------|
| Application test | LAFT hosts can support web, email, im, ftp|
| | , telnet, SSH, video, Video Camera, P2P, |
| | online game, voip, and so on. |
|----------------------|-------------------------------------------|
| Operating System test| LAFT can widely support Win7, VISTA, |
| | windows XP. |
|----------------------|-------------------------------------------|
| | The performance test for LAFT-NGW is |
| | carried out on a normal PC. |
| Performance test | Due to limitation of the PC hardware, the |
| | overall throughput is not quite good. |
| | However, it can still support more than |
| | one hundred million concurrent sessions |
|----------------------|-------------------------------------------|
Figure 5 LAFT6 test result
9.4. Conclusions
From the experiment, we can have the following conclusions:
Sun Expires September 15, 2011 [Page 17]
Internet-Draft Lightweight address family transition March 2011
o LAFT6 has good scalability. LAFT-NGW is a lightweight solution
which only maintains per-subscriber state information. As a result,
it can easily support a large amount of concurrent subscribers.
o LAFT6 can be deployed rapidly. There is no modification to
existing addressing and routing system in our operational network.
And it is simple to achieve traffic tracing and logging.
o LAFT6 can support a majority of current IPv4 applications and it
can support a variety of Operating Systems.
10. References
[I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt,
J., and Y. Lee, "Dual-Stack Lite Broadband Deployments
Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-
lite-06 (work in progress), August 2010
[I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and
I. Beijnum, "Stateful NAT64: Network Address and Protocol
Translation from IPv6 Clients to IPv4 Servers", draft-ietf-
behave-v6v4-xlate-stateful-12 (work in progress), July 2010.
[I-D.ietf-intarea-shared-addressing-issues] M. Ford, Ed., M.
Boucadair, A. Durand, P. Levis, P. Roberts, "Issues with IP
Address Sharing", draft-ietf-intarea-shared-addressing-
issues-04 (work in progress), February 2011.
[I-D.behave-natx4-log-reduction] T. Tsou, W. Li, T. Taylor, "Port
Management To Reduce Logging In Large-Scale NATs", draft-
tsou-behave-natx4-log-reduction-02(work in progress),
September 2010.
[I-D.ietf-softwire-ds-lite-tunnel-option] D. Hankins, T. Mrugalski,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Option for Dual-Stack Lite", draft-ietf-softwire-ds-lite-
tunnel-option-08 (work in progress), January 2011
[RFC5625] R. Bellis, "DNS Proxy Implementation Guidelines", RFC5625,
August 2009.
[I-D.ietf-behave-dns64] Bagnulo, M., "DNS64: DNS extensions for
Network Address Translation from IPv6 Clients to IPv4
Servers", draft-ietf-behave-dns64-10.txt, July 2010.
Sun Expires September 15, 2011 [Page 18]
Internet-Draft Lightweight address family transition March 2011
[I-D.tsou-pcp-natcoord] T.Tsou, C.Zhou, Q.Sun, T.Taylor, "Using PCP
To Coordinate Between the CGN and Home Gateway Via Port
Allocation", draft-tsou-pcp-natcoord-00.txt, March 4, 2011.
11. Acknowledgments
The authors would like to thank to Fred Baker and Tony Hain for his
continuous suggestion around this topic over the years. Thanks to Qian
Wang, Jie Hu and Fan Shi for useful feedback.
Authors' Addresses
Qiong SUN
China Telecom Beijing Research Institute
Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035
China
Phone: <86 10 58552936>
Email: sunqiong@ctbri.com.cn
Chongfeng Xie
China Telecom Beijing Research Institute
Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035
China
Phone: <86 10 58552116>
Email: xiechf@ctbri.com.cn
Sun Expires September 15, 2011 [Page 19]