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

Versions: 00 01 02

Network Working Group                                       Qiong Sun
Internet Draft                                           Chongfeng Xie
Intended status: Informational                           China Telecom
Expires: April 24, 2011                                       Xing Li
                                                          CongXiao Bao
                                     CERNET Center/Tsinghua University
                                                            Ming Feng
                                                         China Telecom
                                                         March 6, 2011


      Considerations for Stateless Translation (IVI/dIVI) in Large SP
                                 Network
                      draft-sunq-v6ops-ivi-sp-02.txt


Abstract

   With the approaching exhaustion of IPv4 address space, large-scale
   SPs are now faced with the only real option to deploy IPv6 in a
   timely manner. In order to achieve smooth transition to IPv6,
   migration tools should be introduced for different deployment models.
   Among different IPv6 transition mechanisms, dIVI is a prefix-specific
   and stateless address mapping method which can directly translate
   IPv4 packet to IPv6 packet. This document describes the challenges
   and requirements for large SP to deploy IPv6 in operational network,
   the experimental results of dIVI in our laboratory and the
   considerations for dIVI deployment in large SP operational 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




Sun                  Expires September 24 2011               [Page 1]


Internet-Draft   Considerations for Stateless Translation    March 2011


   This Internet-Draft will expire on September 6,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 ............................................... 3
   3. Problem Statement ........................................... 3
   4. Laboratory experiment........................................ 5
      4.1. Experiment environment.................................. 6
      4.2. Experiment configuration................................ 7
      4.3. Experiment results...................................... 7
   5. dIVI Deployment Scenario..................................... 9
      5.1. Network Architecture for Large SP Network............... 9
      5.2. dIVI Deployment Scenario in Operational Network.........11
   6. Considerations for dIVI deployment.......................... 12
      6.1. Addressing ............................................ 12
      6.2. Routing ............................................... 13
      6.3. DNS ................................................... 13
      6.4. AAA and User Management................................ 13
      6.5. Network management..................................... 14
      6.6. dIVI CPE Requirements and Configuration ................14
      6.7. dIVI Xlate Placement in Large SP Network ...............14
      6.8. ALG consideration ......................................15
   7. Security Considerations..................................... 15
   8. IANA Considerations ........................................ 15
   9. References ................................................. 15
      9.1. Normative References................................... 15
   10. Acknowledgments ........................................... 16





Sun                  Expires September 6, 2011               [Page 2]


Internet-Draft   Considerations for Stateless Translation    March 2011


1.  Introduction

   The dramatic growth of the Internet is accelerating the exhaustion of
   available IPv4 addressing pool. It is widely accepted that IPv6 is
   the only real option on the table for the continued 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 achieve smooth transition to IPv6, migration tools should
   be introduced for different deployment models, among which dIVI is a
   stateless translation mechanism with good scalability. This document
   describes the challenges and requirements for large SPs in IPv6
   transition period. Then, we introduce dIVI experimental results in
   our laboratory. And finally, the considerations for designing and
   deploying dIVI in operational network are discussed in terms of
   addressing and routing, DNS deployment requirement, AAA support and
   user management, network management, CPE requirement and Xlate
   placement.

2. Terminologies

   This document uses the terminologies defined in [I-D.ietf-behave-
   v6v4-framework], [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-
   address-format], [I-D.ietf-behave-v6v4-xlate-stateful], and [I-D.xli-
   behave-ivi].

   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. Problem Statement

   It is well known that the pool of public IPv4 addressing is nearing
   its exhaustion. The '/8' IANA blocks for Regional Internet Registries
   (RIRs) are projected to 'run-out' towards the end of 2011. Credible
   estimates based on past behavior suggest that the RIRs will exhaust
   their remaining address space by early 2012, apart from the
   development of a market in IPv4 address space. Thus, it will become
   much more difficult to get available public IPv4 addresses. In the
   same time, a lot of emerging applications, e.g. Apple's iPad,
   Motion's BlackBerry, etc. will quickly deplete the available
   addresses. This has led to a hightened awareness among the providers
   to consider introducing IPv6 to keep the Internet operational.

   It has been widely accepted that the end goal of IPv6 transition is
   to achieve an end-to-end IPv6-only network, and IPv4 can eventually


Sun                  Expires September 6, 2011               [Page 3]


Internet-Draft   Considerations for Stateless Translation    March 2011


   be turned off. However, since it will have impact on almost the
   entire world, it will take a considerable period of time to reach the
   ultimate goal. As a result, IPv4 and IPv6 need to coexist during the
   whole transition period. In this document, we mainly focus on IPv6
   migration issues from large ISP's point of view. In order to
   facilitate smooth IPv6 migration, some factors need to be taken into
   consideration especially for large SPs. There are ten major
   requirements:

   1. It should deploy in an incremental fashion and the overall
      transition process should be stable and operational.

   2. It should largely reduce IPv4 public address consumption.

   3. It should accelerate the deployment of IPv6, rather than just
      prolonging the lifecycle of IPv4 by introducing multiple layers of
      NAT.

   4. There should be no perceived degradation of customer experience.
      As a result, IPv6 transition mechanisms should provide IPv4
      service continuity.

   5. It should achieve scalability, simplicity and high availability,
      especially for large-scale SPs.

   6. It should have user management and network management ability.

   7. It should support user authentication, authorization and
      accounting as an essential part of operational network.

   8. Most ISPs need some kind of mechanisms to trace the origin of
      traffic in their networks. This should also be available for IPv6
      traffic.

   9. It should have good throughput performance and massive concurrent
      session support.

   10.It should maintain the deployment concepts and business models
      which have been proven and used with existing revenue generating
      IPv4 services.

   All existing IPv6 transition mechanisms can be widely divided into
   three categories: dual-stack solution, translation-based solution and
   tunnel-based solution. In this document, we mainly concentrate on
   stateless translation mechanism: dIVI. The original stateless
   IPv4/IPv6 translation (stateless 1:1 IVI) is scalable, [I-D.ietf-
   behave-v6v4-framework], [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-


Sun                  Expires September 6, 2011               [Page 4]


Internet-Draft   Considerations for Stateless Translation    March 2011


   behave-address-format],[I-D.xli-behave-ivi]. But it cannot use the
   IPv4 addresses effectively. The stateless dIVI[I-D.xli-behave-divi]
   is a double translation mechanism which includes a 1:N stateless
   translator and a 1:1 Hgw translator. The 1:N stateless translator is
   implemented in the border between the IPv6 network and the IPv4
   Internet. It translates the packets between IPv4 and IPv6 with the
   1:N stateless address mapping. The 1:1 Hgw translator is implemented
   between an IPv6 network and user's end system. It translates the
   packets between IPv4 and IPv6 with 1:1 stateless address mapping. In
   addition, the home gateway translator maps random source port numbers
   to restricted port number based on the extended IPv4-translatable
   address format and keeps the mapping table in database for the port
   number mapping of the retuning packets and all the packets in the
   same session.

   dIVI support bidirectional communication initiated from IPv4 and IPv6.
   It can be deployed in an IPv6-only access network, in which
   operational and maintenance cost can be reduced. It has very good
   scalability and can largely reduce IPv4 address consumption.

   In this document, we firstly demonstrate the laboratory experimental
   results of dIVI in section 4. We can see that dIVI can support most
   of the current IPv4 applications in IPv6-only access network, while
   largely reducing IPv4 address consumption. And then dIVI deployment
   model and considerations in large operational network are proposed in
   section 5 and section 6 respectively. Some important factors need to
   be taken into account when introducing dIVI. Since most challenges in
   dIVI have no big difference compared to an IPv6-only environment, we
   strongly recommend that related network elements should take the
   corresponding modifications in order to guarantee the IPv6 transition
   process to be operational and manageable.

4. Laboratory experiment

   We have tested dIVI using the prototype in our laboratory. The major
   objective listed in the following is to verify the functionality and
   performance of dIVI:

   O Verify how to deploy dIVI in practical network.

   O Verify what applications can be used in dIVI.

   O Verify what Operating Systems can be supported in dIVI.

   O Verify the effect of user experience with limited ports.

   O Verify the performance of dIVI.


Sun                  Expires September 6, 2011               [Page 5]


Internet-Draft   Considerations for Stateless Translation    March 2011


    4.1. Experiment environment

   We have tested dIVI in our laboratory. The network topology is
   depicted in Figure 1.

    +-----+  +-----+
    |Host1+--+Hgw1 +------+                              ------
    +-----+  +-----+      |                          ////      \\\\
                        /-+--\      +----------+   //              \\
                      //      \\    |          |  |                  |
    +-----+  +-----+ |  IPv6    |   | IVI Xlate|  |  IPv4 Internet   |
    |Host2+--+Hgw2 +-+ Network  +---|          +--+                  |
    +-----+  +-----+  \\      //    |          |   \\              //
                        |---+/      +----------+     \\\\      ////
                        |   |                            ------
    +-----+  +-----+    |   |
    |Host3+--+Hgw3 +----+   |
    +-----+  +-----+        |                            ------
                            |                        ////      \\\\\
                            |                      |/                |
                            +----------------------+  IPv6 Internet  |
                                                   |                 |
                                                   |\               /
                                                     \\\\      /////
                                                          ------

                    Figure 1 dIVI topology in the test

   There are three key components in the test:

   o The Hosts are dual-stack customers, who could run IPv4 application,
      IPv6 application or dual stack application.

   o The Home Gateways (Hgw) are dIVI translator in user side. It
      translates the packets between IPv4 and IPv6 with 1:1 stateless
      address mapping, and maps random source port numbers to restricted
      port number.

   o The Xlate translates the packets between IPv4 and IPv6 with the
      1:N stateless address mapping.

   The network between Hgw and Xlate is IPv6-only, and the network
   behind Hgw is dual-stack. Thus, the hosts behind Hgw can communicate
   with both IPv4 Internet and IPv6 Internet.





Sun                  Expires September 6, 2011               [Page 6]


Internet-Draft   Considerations for Stateless Translation    March 2011


    4.2. Experiment configuration

   For address configuration, each host will use two IPv6 addresses: one
   is IVI6 address which is synthesized in Hgw with the IVI4 address and
   port-related information, and the other is non-IVI IPv6 address which
   is used for native IPv6 communication. We should notice that only
   non-IVI IPv6 address needs be allocated to end users. Besides, each
   user will get an IVI4 address from Hgw.

   For routing configuration, both IVI address and non-IVI address need
   to be imported into the IPv6-only network.

   For port configuration, since there are 65536 TCP/UDP ports for each
   IP address, and in fact one can use hundreds only for normal
   applications, so one IPv4 address can be shared by multiple customers.
   In our experiment, we selected ratio to be 128. That is to say, one
   IPv4 address is shared by 128 users, and there are 512 available
   ports per user.

   For DNS configuration, there is no need to have additional DNS64 for
   dIVI. Only an IPv6 DNS server with A/AAAA records is needed and the
   DNS address is manually configured in Hgw. Besides, Hgw has
   implemented DNS Proxy and it will convert an IPv4 DNS
   request/response to IPv6 DNS request/response.

   For ALG configuration, there is no need to deploy specific ALG for
   IPv4 applications in dIVI.

    4.3. Experiment results

   In our laboratory, 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.








Sun                  Expires September 6, 2011               [Page 7]


Internet-Draft   Considerations for Stateless Translation    March 2011


   The experimental results are listed as follows:

   |----------------------|-------------------------------------------|
   | Type                 | Experiment Result                         |
   |----------------------|-------------------------------------------|
   | Application test     | dIVI hosts can support web, email, im, ftp|
   |                      | , telnet, SSH, video, Video Camera, P2P,  |
   |                      | online game, voip, and so on.             |
   |----------------------|-------------------------------------------|
   | Operating System test| dIVI can widely support Win7, VISTA,      |
   |                      | windows XP.                               |
   |----------------------|-------------------------------------------|
   |                      | The performance test for dIVI Xlate 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 2 dIVI test result



   From the experiment, we can have the following conclusions:

   1. dIVI can have good scalability. Xlate does not need to maintain
      any session state, and only limited session states have to been
      maintained in Hgw for its customer.

   2. dIVI can be deployed in an incremental way. The most complicated
      part of dIVI is addressing and routing. The configuration for DNS
      and ALG is very simple.

   3. dIVI can support a majority of current IPv4 applications.

   4. dIVI can support a variety of Operating Systems.

   5. With the ratio of 128 (512 maximum concurrent sessions), there is
      no perceived degradation of customer experience.



   However, in the current status of equipment, e.g. BRAS, end system,
   etc., the support for IPv6-only function has not been fully
   accomplished. Therefore, there are still some limitations which would
   be improved in the next version of dIVI development when deploying
   dIVI prototype in practical operational network:


Sun                  Expires September 6, 2011               [Page 8]


Internet-Draft   Considerations for Stateless Translation    March 2011


   1. Address assignment process have not been integrated with existing
      address allocation system.

   2. Currently, IVI routing entries are configured manually.

   3. Hgw has not integrated PPPoE functionality with dIVI functionality.

   4. AAA system has not supported IVI-related (or IPv6-only) functions.

   With regard to the listed IPv6 transition requirements in section 3,
   most of them can be satisfied by dIVI, except for the requirement of
   network management and user management. These two points should be
   paid special attention for large SPs, which will be further discussed
   in section 6.

5. dIVI Deployment Scenario

   In order to investigate the ways to deploy dIVI in operational
   network, we firstly briefly discuss network architecture for large SP
   network. Then dIVI deployment model is introduced.



    5.1. Network Architecture for Large SP Network

   In large SPs, the generic network topology can be divided into four
   main parts (as depicted in Figure3): the Customer Premises Network
   (CPN), the Access Network (AN), the Metro Area Network (MAN), and the
   Backbone Network.



      -----             ------
    //     \\         //      \\         ------              ----------
    /       \        /         \\      //      \\         //  CPN
   |         +------+           +----+           \       /   ----------
   |         |      |   Metro   +BRAS|            |-----|--- End System
   | Backbone|Core  |   Area    |/SR |   Access   |     |    ----------
   | Network |Route |  Network  +----+   Network  | CPE |    ----------
   |         |      |           |AAA |            |-----|--- End System
   |         +------+           +----+           /       \   ----------
    \        /       \         /      \\       //         \\
     \\    //         \\      //         ------              ----------
       ----             ------

             Figure 3 Network Architecture for Large SP Network



Sun                  Expires September 6, 2011               [Page 9]


Internet-Draft   Considerations for Stateless Translation    March 2011




   1. CPN is the part of the network by a customer when connecting to an
      ISP's network which includes the CPE and the last hop link.

   2. In Access Network, a very wide variety of access technologies can
      be used, including ADSL, Ethernet, PON, ATM, WIFI, etc.

   3. MAN is the aggregated network for customers in one single metro,
      with the vast range of size. In most metro networks, BRAS is
      connected to Core Router directly, while for a small portion of
      large metro networks, BRAS is connected to Core Routers via
      aggregated routers.

   4. Backbone network is to offer transit service between MANs and
      other ISPs.

   There are typically two network models for fixed broadband access
   service: one is to access using PPPoE/PPPoA authentication method
   while the other is to use IPoE. The first one is usually applied to
   Residential network and SOHO networks. Subscribers in CPNs can access
   broadband network by PPP dial-up authentication. BRAS is the key
   network element which takes full responsibility of IP address
   assignment, user authentication, traffic aggregation, PPP session
   termination, etc. Then IP traffic is forwarded to Core Routers
   through Metro Area Network, and finally transited to external
   Internet via Backbone network.

   The second network scenario is usually applied to large enterprise
   networks. Subscribers in CPNs can access broadband network by IPoE
   authentication. IP address is normally assigned by DHCP server, or
   static configuration.

















Sun                  Expires September 6, 2011              [Page 10]


Internet-Draft   Considerations for Stateless Translation    March 2011


    5.2. dIVI Deployment Scenario in Operational Network

   The deployment model of dIVI in operational network is depicted in
   Figure4.

       ----             -----
     //    \\         //     \\         ---------              --------
    /        \       /         \      //         \\         //  CPN
   |         +-----+            +----+             \       /   --------
   |         |     |   Metro    |BRAS|              |-----|--End System
   | Backbone|Core |   Area     |/SR |   Access     |     |    --------
   | Network |Route|  Network   +----+   Network    | CPE |    --------
   |         |     |            |AAA |              |-----|--End System
   |         +-----+            +----+             /    |  \   --------
    \        /       \          /      \\         //    |   \\
     \\    //         \\      //         --------       |     ---------
       ----            ----|--                          |
                           |                            |
    -----------------|     |      |----------------|    |    |---------|
                      \    |     /                  \   |   /          |
                       \---|--- /                    \--|--/           |
        IPv6/IPv4      |  dIVI  |       IPv6-only    | Hgw | IPv6/IPv4 |
         Internet      |  Xlate |        Network     |(CPE)|  Network  |
                   / ------- \                   / ----- \          |
                     /           \                 /         \         |
    ----------------|             |----------------|          |--------|
              Figure 4 dIVI Deployment in Operational Network


   In stateless dIVI, the network between Hgw and Xlate is an IPv6-only
   network, in which the operational and maintenance cost can be greatly
   reduced. The access network behind Hgw can either be IPv4-only or
   dual-stack. Thus, IPv4-only system and dual-stack system can
   communication with IPv4 Internet using shared IPv4 address by dIVI
   and the dual-stack system can also communicate with IPv6 Internet
   directly.

   In operational network, Hgw can usually be integrated with CPE, while
   Xlate can be in someplace of MAN or Backbone Network. Subscribers can
   get IPv6 address from BRAS/SR after user authentication stage. Then,
   IVI-related route should be imported into the IPv6-only network
   between Xlate and Hgw. The detailed considerations for dIVI
   deployment will be discussed in section 6.






Sun                  Expires September 6, 2011              [Page 11]


Internet-Draft   Considerations for Stateless Translation    March 2011


6. Considerations for dIVI deployment

   This section describes the considerations for dIVI deployment in
   large operational network.

   The major differences between dIVI deployment in laboratory and
   operational network lie in:

   1. Operational network is a commercial network with strict user
      management requirement, while in laboratory it is simple and
      straightforward.

   2. Operational network has different kinds of network equipments, e.g.
      BRAS/SR, CPE, Radius, etc. It would be more difficult to take
      modifications on all of these equipments.

   3. Operational network has a large number of customers. Thus, it
      would be impossible to take manual configuration for all customers.

   In this section, we try to outline considerations for dIVI deployment
   on large SP network. Some of the features are not specific to dIVI,
   but rather to a general requirement on all IPv6 transition techniques.

    6.1. Addressing

   In dIVI, there is no need to allocate IVI6 address explicitly to end
   users. Thus, the process of IPv6 address assignment can be integrated
   with existing IPv6 address allocation process. Only CPE will need to
   get IVI4 address, reallocate it to end user, do port-mapping and
   traffic translation with port-related information. Here are some
   basic considerations in dIVI addressing:

   o Determine IVI6 prefix for each Xlate. Operators should use its own
      prefix as an IVI6 prefix, i.e. pref=2001:db8:a4a6::/48, in order
      to perform stateless translation. Address allocation process in
      BRAS/SR should be consistent with Xlate.

   o Determine the embedded IVI4 address and port multx ratio.
      Operators should estimate the scale of subscribers in a certain
      region, evaluate the number of remaining IPv4 address, and analyze
      the number of concurrent ports. It is a tradeoff between multx
      ratio and concurrent port numbers. The bigger the multx ratio is,
      the more an IPv4 address can be shared by multiple subscribers and
      the less concurrent port number can be used per subscriber. From
      the above test in our laboratory, we choose multx ratio to be 128
      and it is enough for current usage.



Sun                  Expires September 6, 2011              [Page 12]


Internet-Draft   Considerations for Stateless Translation    March 2011


   o Determine the ways to distribute the configuration profile
      including IVI4 address and port multx ratio to Hgw automatically,
      either by extended DHCP option, or other protocols.

    6.2. Routing

   In dIVI, IVI4(i) and IVI6(i) will be aggregated to ISP's IPv4 address
   and ISP's IPv6 address. They will not affect the global IPv4 and IPv6
   routing tables

   In dIVI deployment model, Hgws are normally configured with a default
   route that points to the BRAS/SR.  The routers between BRAS/SR and
   Xlate run IPv6 dynamic routing protocols (IGP or BGP), and routers in
   the upper level of Xlate run IPv4 dynamic routing protocols.
   Therefore, the aggregated IVI6 routing directing to the upper routers
   will be learned/inserted by in IPv6-only domain. And the IVI6 route
   directing to Hgws should also be configured in BRAS/SR.

    6.3. DNS

   In dIVI, there is no DNS64/DNS46 needed anymore. An IPv6 DNS server
   is needed to process IPv6 DNS request/response, and the address of
   IPv6 DNS server should be passed to Hgw.

   Since there is no IPv4 DNS server in IPv6-only network, it is
   recommended that Hgw should implement IPv4-to-IPv6 DNS Proxy to
   convert an IPv4 DNS request/response to IPv6 DNS request/response
   accordingly.

    6.4. AAA and User Management

   User authentication can be used to control who can have the dIVI
   connectivity service. This is not always required when a customer of
   IPv4 service automatically can have access to the dIVI service.
   However, it is highly recommended that IPv6-only customers should be
   authenticated separately. It is good for security, trouble shooting,
   user accounting, etc. There are some major points that AAA systems
   need to be taken into consideration:

   o User authentication function needs to be extended to support the
      identification of IPv6-only subscriber, with additional dIVI-
      related profile for subscribers, e.g. IVI6 address, IVI4 address,
      non-IVI address, etc.

   o User accounting and management function needs to be extended to
      identify dIVI user (or IPv6-only user) separately.



Sun                  Expires September 6, 2011              [Page 13]


Internet-Draft   Considerations for Stateless Translation    March 2011


   In summary, the major challenge of dIVI for the AAA and User
   Management is no big difference compared to an IPv6-only environment.

    6.5. Network management

   There are two issues to manage dIVI in operational network:

   o Manage IPv6-only network. Operators should be able to manage IPv6-
      only network, including IPv6 MIB modules, Netflow Records, log
      information, etc.

   o Manage the translation process. There are some exceptions that the
      MIB modules need to add dIVI related features, e.g. dIVI device
      management, dIVI traffic monitoring, etc.

    6.6. dIVI CPE Requirements and Configuration

   In dIVI, CPE is an important network element. It should perform DHCP
   server, integrated user authentication function, traffic translation
   and port mapping, DNS proxy, etc. The major operations in dIVI CPE
   include:

   o Address assignment: dIVI CPE should support IVI4 address
      assignment by DHCP process to end users. It should also support
      IPv6 address assignment, either by stateful DHCP or stateless
      auto-configuration.

   o Integrated user authentication function: dIVI CPE should integrate
      with existing user authentication function, e.g. PPPoE/PPPoA, etc.

   o DNS: CPE should enable RFC 5006, well-known addresses, and DHCPv6
      in order to maximize the likelihood of dIVI Hgw being able to use
      DNS without manual configuration. Besides, dIVI CPE should also
      support IPv4-to-IPv6 DNS proxy.

    6.7. dIVI Xlate Placement in Large SP Network

   Normally, dIVI Xlate can be deployed in "centralized model" and
   "distributed model".

   In "centralized model", dIVI Xlate could be deployed in the place of
   Core Router, or even in the entrance of ICP. Since dIVI is a
   stateless method with better scalability than stateful ones, it can
   handle numerous concurrent sessions.

   In "distributed model", dIVI Xlate is usually be integrated with
   BRAS/SR. So each Xlate should be configured with its own IVI6 prefix


Sun                  Expires September 6, 2011              [Page 14]


Internet-Draft   Considerations for Stateless Translation    March 2011


   and is responsible for translating the traffic of its own region. The
   number of subscribers is normally limited, so does the number of IVI
   routing entries. However, the network infrastructure should still be
   upgraded to dual-stack support in MAN and backbone network, and so
   the decreased operational cost is rather limited. Besides, since the
   newly emerging customers might be distributed in the whole Metro area,
   we have to deploy Xlate on all BRAS/SRs. This will cost a lot in the
   initial phase of IPv6 transition period.

   In summary, we strongly recommend adopting "centralized model" for
   dIVI. It is a cost-effective way and easy to manage.

    6.8. ALG consideration

   dIVI does not require ALG, this is a very important feature in the
   initial development phase of IPv6.

7. Security Considerations

   There are no security considerations in this document.

8. IANA Considerations

   This memo adds no new IANA considerations.

   Note to RFC Editor: This section will have served its purpose if it
   correctly tells IANA that no new assignments or registries are
   required, or if those assignments or registries are created during
   the RFC publication process.  From the author's perspective, it may
   therefore be removed upon publication as an RFC at the RFC Editor's
   discretion.
9. References

    9.1. Normative References

   [I-D.ietf-behave-address-format] C., Bao, Huitema, C., Bagnulo, M.,
             Boucadair, M., and X.Li, "IPv6 Addressing of IPv4/IPv6
             Translators", draft-ietf-behave-address-format-10 (work in
             progress), August 2009.

   [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and
             I. Beijnum, "DNS64: DNS extensions for Network Address
             Translation from IPv6 Clients to IPv4 Servers", draft-ietf-
             behave-dns64-11 (work in progress),October 2009.





Sun                  Expires September 6, 2011              [Page 15]


Internet-Draft   Considerations for Stateless Translation    March 2011


   [I-D.ietf-behave-v6v4-framework] Baker, F., Li, X., Bao, C., and K.
             Yin, "Framework for IPv4/IPv6 Translation", draft-ietf-
             behave-v6v4-framework-10 (work in progress), October 2009.

   [I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP
             Translation Algorithm", draft-ietf-behave-v6v4-xlate-23
             (work in progress), October 2009.

   [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., I.
             Beijnum, "IP/ICMP Translation Algorithm", draft-ietf-
             behave-v6v4-xlate-12 (work in progress), October 2009.

   [I-D.xli-behave-divi] Li,X., Bao, C., and Zhang, H., "Address-sharing
             stateless double IVI", draft-xli-behave-divi-01, April 29,
             2010.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

10. Acknowledgments

      The authors would like to thank to Fred Baker for his continuous
   suggestion around this topic over the years. Thanks to Qian Wang, Jie
   Hu and Fan Shi for useful feedback.
























Sun                  Expires September 6, 2011              [Page 16]


Internet-Draft   Considerations for Stateless Translation    March 2011


Authors' Addresses

   Qiong SUN
   China Telecom Beijing Research Institute
   Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035
   China

   Phone: <86 10 58552636>
   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

   Xing Li
    CERNET Center/Tsinghua University
   Room 225, Main Building, Tsinghua University

   Phone: <86 10 62785983>
   Email: xing@cernet.edu.cn

   Congxiao Bao
   CERNET Center/Tsinghua University
   Room 225, Main Building, Tsinghua University

   Phone: <86 10 62785983>
   Email: congxiao@cernet.edu.cn >

   Ming Feng
   China Telecom
   No.31, Jinrong Ave,Xicheng District,100032

   Phone: <86 10 58501428>
   Email: fengm@chinatelecom.com.cn










Sun                  Expires September 6, 2011              [Page 17]


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