[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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


   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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

    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

   6to4 table: binding table in LAFT-CGW for IPv6 sources with IPv4

   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

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-

   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   |
                       +-----+-----+      +---------------------------+
        |            |src address:|
                             |            |src port:       9201       |
                             |            +---------------------------+
                   |         |         |
                   |    Home Gateway   |
                   ||     LAFT-CGW    ||
                   |       |NAT|       |
                   |       +-+-+       |
                   +--------|||--------+  +---------------------------+
             2001:c68:0:1::1|||           |src addr6:  2001:c68:0:1::1|
     |||           |src addr4:  |
      IPv4-in-IPv6 Tunnel->>|||           |src port:   2001           |
                            |||           +---------------------------+
                   /        |||        \
                  |   ISP core network  |
                   \        |||        /
                     -------|||-------    +---------------------------+
                            |||           |src addr4:  |
             2001:c68:0:2::1|||           |src port:   2001           |
     |||           +---------------------------+
                   |     LAFT-NGW      |
                   |         |         |

Sun                  Expires September 15, 2011               [Page 8]

Internet-Draft   Lightweight address family transition    March 2011

                   /         |         \
                  |       Internet      |
                   \         |         /
                       | 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|
     |||           |src addr4:  |
      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:  |
             2001:c68:0:2::1|||           |src port:   2002           |
     |||           +---------------------------+
                   |     LAFT-NGW      |
                   |         |         |
                   /         |         \
                  |       Internet      |
                   \         |         /
                       | 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,

  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

  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

    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

  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,

  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

    (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

    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

    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

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

   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

   Phone: <86 10 58552116>
   Email: xiechf@ctbri.com.cn

Sun                  Expires September 15, 2011              [Page 19]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/