Internet DRAFT - draft-sun-behave-v4tov6

draft-sun-behave-v4tov6





Network Working Group                                             C. Xie
Internet-Draft                                                    Q. Sun
Intended status: Standards Track                                   Q. He
Expires: January 30, 2014                                  China Telecom
                                                                 C. Zhou
                                                     Huawei Technologies
                                                                   X. Li
                                                                  C. Bao
                                                  CERNET Center/Tsinghua
                                                              University
                                                           July 29, 2013


      The Approach for IPv4-only users to access IPv6-only Content
                       draft-sun-behave-v4tov6-01

Abstract

   Current approaches can not solve the scenario that the users from
   IPv4 Internet to access IPv6-only content.  When IPv6 content are
   becoming more and more popular, it is important to ensure that IPv6-
   only content can be reachable from legacy IPv4-only clients via some
   IPv4-only network.  This document proposes two approaches for IPv4-
   only users to access IPv6-only content.  It is designed to cover the
   Scenario 2 in [RFC6144].

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 30, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Xie, et al.             Expires January 30, 2014                [Page 1]

Internet-Draft      IPv4 user to access IPv6 Content           July 2013


   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  The NAT46 translator for IPv4 Internet to access IPv6
       network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Approach 1: DNS-based solution  . . . . . . . . . . . . . . . . 4
   5.  Approach 2: Redirect-based Solution . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9


























Xie, et al.             Expires January 30, 2014                [Page 2]

Internet-Draft      IPv4 user to access IPv6 Content           July 2013


1.  Introduction

   In [RFC6144], Scenario 2 is an important use case.  Not only could
   servers move directly to IPv6 without trudging through a difficult
   transition period, but they could do so without risk of losing
   connectivity with the IPv4-only Internet.

   Existing solutions have not solved this scenario well.  NAT-
   PT[RFC2766]can be used in this scenario, but it requires a tightly
   coupled DNS Application Level Gateway (ALG) in the translator, and
   have been deprecated by the IETF [RFC4966].  The stateless
   translation solution [RFC6219] can work too, but since each IPv6
   server will consume one IPv4 public address, it is not suitable to
   deploy in situation that operators are running out of IPv4 address.
   [RFC6156] can be used for IPv4 client to communicate with IPv6
   client.  But this requires the IPv4 client and IPv6 client to
   implement a TURN client.  Therefore, it is not suitable for
   C-S(Client-Server) and B-S (Browser-Server) mode.

   [I-D.rfvlb-behave-v6-content-for-v4-clients] can work for IPv4-only
   user to access IPv6 content.  But since it uses private IPv4 address
   to mapping the IPv6 server, it can only be used for IPv4 network to
   reach IPv6 network.

   This document is designed for IPv4 Internet to reach IPv6 network.
   There are several requirements in this design:

      1.Considering IPv4 address has been a scarce resource, the amount
      of public IPv4 addresses consumed by the translator should be less
      than that the number of IPv6 servers in the IPv6 network.

      2.  It should not require extra modifications on the server, e.g.
      by using a dynamic port number, implementing TURN client, etc.

   In this document, we propose two approaches for this scenario.  These
   two approaches can make use of existing DNS architecture.  The
   binding table in these two approaches are static.  Therefore, there
   will be no dynamic issue as in NAT-PT or DNS cache syncronization.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Terminology defined in [RFC6144] is used extensively in this
   document.  Besides, this document uses the following terminologies:



Xie, et al.             Expires January 30, 2014                [Page 3]

Internet-Draft      IPv4 user to access IPv6 Content           July 2013


   IPv6-converted addresses: IPv4 addresses used to represent IPv6 nodes
   in an IPv4 Internet.  They have an explicit mapping relationship to
   IPv6 addresses.

   NAT46: a stateful IPv4/IPv6 translation functionality.  It is
   consistent with IP/ICMP translation [RFC6145], and can also support
   IPv6-converted address selection and binding table maintenance.


3.  The NAT46 translator for IPv4 Internet to access IPv6 network

   The NAT46 solution is used for IPv4 clients in IPv4 Internet to reach
   IPv6 servers (depicted in Figure 1).

                 -------                                ------
               //       \\     Address Pool:          //      \\
              /           \   {210.0.0.0/20,         /          \
 23.0.0.1    |             |   213.0.1.0/18...}     |            |   2001:c61::1
+---------+  |  The IPv4   | +-----------------+    |  The IPv6  |  +--------+
|  IPv4   |  |  Internet   | |   Translator    |    |   Network  |  |  IPv6  |
| Client  |--+             +-|     (NAT46)     |----+            +--| Server |
+---------+  |             | +-----------------+    |            |  +--------+
              \           /   Prefix:2001:c68::/96   \          /
               \\       //                            \\      //
                 -------                                ------

       Figure 1: Overall solution for IPv4 Internet to IPv6 network

   In order to achieve the translation initiated from IPv4 side, two
   addresses need to be determined by NAT46 translator.  The first one
   is the IPv6-converted address of the IPv6 server, which is is
   selected from the IPv4 address pool configured in NAT46.  The second
   one is the IPv4-converted address for the IPv4 client, which can be
   synthetized using the stateless approach defined in [RFC6052].

   In our approach, the mapping relationship between IPv6-converted
   address and the IPv6 address for the server is pre-determined in
   advance.  As a result, the A record in the DNS server for a
   particular server is always the same for different IPv4 clients.


4.  Approach 1: DNS-based solution

   This approach is independent of translated protocol.  For
   applications without DNS process can not be solved by this approach.
   In order to support IPv4 address sharing for multiple IPv6 servers,
   one IPv4 address can be shared by multiple servers with different
   service ports.  If there are too many servers with the same service



Xie, et al.             Expires January 30, 2014                [Page 4]

Internet-Draft      IPv4 user to access IPv6 Content           July 2013


   port, the second approach can be used as a complement.

   The overall solution is depicted in Figure 3.

                 -------     +---------------+      ------
               //       \\   | +-----------+ |    //      \\
              /           \  | |   DNS     | |   /          \
+---------+  |  The IPv4   | | +-----------+ |  |  The IPv6  |  +--------+
|  IPv4   |  |  Internet   | |               |  |   Network  |  |  IPv6  |
| Client  |--+             +-|  +--------+   |--+            +--| Server |
+---------+  |             | |  | NAT46  |   |  |            |  +--------+
              \           /  |  +--------+   |   \          /
               \\       //   +---------------+    \\      //
                 -------                            ------

                       Figure 2: DNS-based approach

   It consists of several functionalities:

   1.NAT46: This functionality achieves the translation between IPv4
   packet and IPv6 packet.  It is consistent with [RFC6145].  Besides,
   it maintained the binding table including the IPv6 server address,
   IPv6-converted address for IPv6 server, and the service port
   statically.

   2.DNS: The DNS server is configured with the IPv6-converted address
   as the A record for IPv6 server.

   The workflow of this apporach is as follows:

   +--------+        +--------+       +--------+        +--------+
   | IPv4   |        |   DNS  |       | NAT46  |        |  IPv6  |
   | Client |        |        |       |        |        | Server |
   +--------+        +--------+       +--------+        +--------+
       |                  |                 |               |
       |DNS A record query|                 |               |
       | ipv6.example.com |                 |               |
       |----------------->|                 |               |
       |                  |                 |               |
       | return A record  |                 |               |
       |<-----------------|                 |               |
       |              IPv4 traffic          | Lookup the    |
       |----------------------------------->| Binding Table |
       |                                    | IPv6 Traffic  |
       |                                    |-------------->|
       |        IPv4 traffic(Returned)      |<--------------|
       |<-----------------------------------|               |




Xie, et al.             Expires January 30, 2014                [Page 5]

Internet-Draft      IPv4 user to access IPv6 Content           July 2013


                 Figure 3: Workflow of DNS-based approach

   1.  An IPv4 client initiates a DNS query for A record (e.g.
   ipv6.example.com).

   2.  DNS receives the query.  As it is configured with the IPv6-
   converted address in advance, the A record will be returned to the
   IPv4 client.

   3.  IPv4 client sends IPv4 traffic with the returned IPv6-converted
   address as the destination address.

   4.  When the IPv4 traffic arrives at the NAT46, NAT46 extracts the
   destination address and destination port in the IPv4 traffic.  It
   will lookup the binding table maintained in NAT46 and NAT46
   translates the IPv4 packet to IPv6 packet according to [RFC6145].  No
   port translation will be performed here.

   5.  The return traffic is treated in the same way.


5.  Approach 2: Redirect-based Solution

   This approach is designed for HTTP application.  It will have a high
   address sharing ratio.  In HTTP, since the traffic can be redirected
   to a different service port, it is able to achieve address sharing
   for IPv6 servers by using different ports (denoted as IPv6-converted
   port).  Therefore, one IPv4 address can support up to thousands of
   IPv6 servers in theory.

   The overall solution is depicted in Figure 4.

                 -------     +--------------------+      ------
               //       \\   | +----------------+ |    //      \\
              /           \  | |Redirect Server | |   /          \
+---------+  |  The IPv4   | | +----------------+ |  |  The IPv6  |  +--------+
|  IPv4   |  |  Internet   | |                    |  |   Network  |  |  IPv6  |
| Client  |--+             +-|    +------------+  |--+            +--| Server |
+---------+  |             | |    |   NAT46    |  |  |            |  +--------+
              \           /  |    +------------+  |   \          /
               \\       //   +--------------------+    \\      //
                 -------                                 ------

                     Figure 4: Redirect-based Solution

   It consists of several functionalities:

   1.  NAT46: This functionality is basically the same as the first



Xie, et al.             Expires January 30, 2014                [Page 6]

Internet-Draft      IPv4 user to access IPv6 Content           July 2013


   approach, except for the binding table includes IPv6 server address,
   IPv6 service port, IPv6-converted address and IPv6-converted port.

   2.  Redirect Server: A Redirect server is used to redirect traffic to
   a different IPv6-converted address and IPv6-converted port.  The
   redirect server may either store the binding table, or query for the
   redirected address and port from NAT46.

   The workflow of this apporach is as follows:

+--------+        +--------+        +--------+       +--------+        +--------+
| IPv4   |        |  DNS   |        |Redirect|       | NAT46  |        |  IPv6  |
| Client |        |        |        | Server |       |        |        | Server |
+--------+        +--------+        +--------+       +--------+        +--------+
    |                  |                 |               |                   |
    | DNS A request    |                 |               |                   |
    | ipv6.example.com |                 |               |                   |
    |----------------->|                 |               |                   |
    | A response with  |                 |               |                   |
    | Redirect Ser Addr|                 |               |                   |
    |<-----------------|                 |               |                   |
    | HTTP GET request, with domain name |               |                   |
    |   in HOST field                    |  Request for  |                   |
    |----------------------------------->| IPv4 Dst Addr | Setup mapping     |
    |                                    |-------------->|  table            |
    |return 302 not found, carry IPv4 dst|               |                   |
    |addr in HTTP redirect packet        |               |                   |
    |<-----------------------------------|               |                   |
    |  IPv4 HTTP request with new v4 dst addr            |                   |
    |--------------------------------------------------->| Translate to IPv6 |
    |                                                    |------------------>|
    |                                                    |<------------------|
    |<---------------------------------------------------|                   |


                 Figure 5: Workflow of Proxy-lite Approach

   1.  An IPv4 client initiates a DNS query for A record (e.g.
   ipv6.example.com).

   2.  In DNS server, the address of the redirect server is configured
   as the A record for ipv6.example.com and returns to the IPv4 client.

   3.  The IPv4 client sends HTTP GET request.  The domain name (e.g.
   ipv6.example.com) is carried in HOST field.

   4.  The redirect server interprets the domain name, and sends the
   request to get IPv6-converted address to NAT46 (carrying the address



Xie, et al.             Expires January 30, 2014                [Page 7]

Internet-Draft      IPv4 user to access IPv6 Content           July 2013


   of IPv4 client and the destination port).  The specific protocol for
   the request is now out of scope.

   5.  NAT46 selects IPv6-converted address and IPv6-converted port by
   lookuping the binding table.  It will also keep the destination port
   in the binding table.

   6.  NAT46 returns the IPv6-converted address and IPv6-converted port
   to redirect server and the redirect server in turn returns IPv6-
   converted address in HTTP redirect packet with HTTP error "302 not
   found".

   7.  IPv4 client replaces the destination IPv4 address with the
   returned IPv6-converted address.  The IPv4 traffic is routed to the
   NAT46.

   8. extracts the destination address and destination port in the IPv4
   traffic.  It will lookup the binding table maintained in NAT46 and
   NAT46 translates the IPv4 packet to IPv6 packet according to
   [RFC6145].


6.  IANA Considerations

   No requirement on IANA.


7.  Acknowledgements

   The authors would like to thank Dan Wing, Fred Baker for their review
   and comments.


8.  References

8.1.  Normative References

   [I-D.rfvlb-behave-v6-content-for-v4-clients]
              Rajtar, B., Farrer, I., Ales, V., Li, X., and C. Bao,
              "Framework for accessing IPv6 content for IPv4-only
              clients", draft-rfvlb-behave-v6-content-for-v4-clients-01
              (work in progress), July 2013.

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

   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,



Xie, et al.             Expires January 30, 2014                [Page 8]

Internet-Draft      IPv4 user to access IPv6 Content           July 2013


              February 2000.

   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
              Address Translator - Protocol Translator (NAT-PT) to
              Historic Status", RFC 4966, July 2007.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation", RFC 6144, April 2011.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6156]  Camarillo, G., Novo, O., and S. Perreault, "Traversal
              Using Relays around NAT (TURN) Extension for IPv6",
              RFC 6156, April 2011.

   [RFC6219]  Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
              China Education and Research Network (CERNET) IVI
              Translation Design and Deployment for the IPv4/IPv6
              Coexistence and Transition", RFC 6219, May 2011.

8.2.  Informative References


Authors' Addresses

   Chongfeng Xie
   China Telecom
   P.R.China

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











Xie, et al.             Expires January 30, 2014                [Page 9]

Internet-Draft      IPv4 user to access IPv6 Content           July 2013


   Qiong Sun
   China Telecom
   P.R.China

   Phone: 86 10 58552936
   Email: sunqiong@ctbri.com.cn


   Qi He
   China Telecom
   P.R.China

   Phone: 86 10 58552332
   Email: heqi@ctbri.com.cn


   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Phone:
   Email: cathy.zhou@huawei.com


   Xing Li
   CERNET Center/Tsinghua University
   Room 225, Main Building
   Beijing  100084
   P.R.China

   Phone: +86 10 6278 5983
   Email: xing@cernet.edu.cn


   Congxiao Bao
   CERNET Center/Tsinghua University
   Room 225, Main Building
   Beijing  100084
   P.R.China

   Phone: +86 10 6278 5983
   Email: congxiao@cernet.edu.cn







Xie, et al.             Expires January 30, 2014               [Page 10]