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

Versions: 00 01 02

BEHAVE WG                                                              D. Liu                                                                  D. Liu                                                                  H. Deng
Internet-Draft                                                        H. Deng
Intended status: Standard Track                                  China Mobile
Expires: September 8, 2010                                      March 7, 2010


                          NAT46 considerations
                       draft-liu-behave-nat46-02

Abstract

   The period of IPv4/IPv6 transisation will last for a long time.
   Different phases of IPv4/IPv6 transisation have different scenarioes
   and requirements thus need different solutions.  In the early stage
   of IPv4/IPv6 transisation, sicne the majority of the Internet
   resources locate in the IPv4 Internet, the main communication type of
   the IPv4/IPv6 transition is v6 to v4 which is the IPv6 clients iniate
   communication to the IPv4 servers.  At the later stage of the IPv4/
   IPv6 transisation, the servers may locate in the IPv6 network/
   Internet, in this scenario, there is a need for the legacy IPv4
   client to iniate communication to the IPv6 servers.  This document
   analyses the problems of v4 to v6 communication and discusses a
   solution called PNAT-Lite.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 8, 2010.

Copyright Notice



Liu                     Expires September 8, 2010               [Page 1]


Internet-Draft             NAT46 consideration                March 2010


   Copyright (c) 2010 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 BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  4. DNS46 consideration . . . . . . . . . . . . . . . . . . . .  7
   5.  5. NAT46 GW consideration  . . . . . . . . . . . . . . . . . .  9
   6.  6. ALG consideration . . . . . . . . . . . . . . . . . . . . . 10
   7.  7. NAT46 solution  . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17























Liu                     Expires September 8, 2010               [Page 2]


Internet-Draft             NAT46 consideration                March 2010


1.  Introduction


   +------------------------------------------------------+
   |                                                      |
   |                                                      |
   | +----------------+                 +---------------+ |
   | | IPv4 Network   |                 |IPv6 Internet  | |
   | | +-----------+  |  +-----------+  | +-----------+ | |
   | | |           |--|--|Translation|--|-|           | | |
   | | |IPv4 Client|  |  |   Box     |  | |IPv6 Server| | |
   | | +-----------+  |  +-----------+  | +-----------+ | |
   | |                |                 |               | |
   | +----------------+                 +---------------+ |
   |           |                                |         |
   |          DNS                              DNS        |
   |                                                      |
   |                                                      |
   +------------------------------------------------------+

   Figure 1        NAT46: v4 to v6 communication scenario.

   As figure 1 illustrated, in v4 to v6 communication scenario, the IPv4
   client which locates in the IPv4 network initiates communication to
   the IPv6 server which locates in the IPv6 Internet.

   To enable the v4 to v6 communication, a v4 to v6 translation entity
   need to be involved.  As figure 1 illustrated, a translation box is
   introduced between the IPv4/IPv6 network which performs IPv4/IPv6
   packets translation.  To enable the v4 to v6 communication, it is
   also need to do v6 to v4 address mapping and handle the DNS query and
   response.  As will be discussed in section 4, there are several
   different ways to implement it.

   Although there are different ways for implementation, the basic
   function module of v4 v6 translation should inlclude:

   1) DNS handling:

   Used to handle DNS query and response.  The IPv4 application may send
   type A DNS query to start the communication, but since the server is
   IPv6 server and may have no type A DNS record, there will be no type
   A DNS response returned.  The DNS handling module is then used to
   solve this problem.  It may send both type A and AAAA DNS queries on
   behalf of the IPv4 application and return the proper DNS response to
   the application.

   2) Address mapping



Liu                     Expires September 8, 2010               [Page 3]


Internet-Draft             NAT46 consideration                March 2010


   Address mapping module is used to create and maintain the IPv4 and
   IPv6 address mapping.  Since the IPv4 application can only start
   communication using IPv4 address as destination IP addrss, there is a
   need to use an IPv4 address to represent the IPv6 server's address.
   This mapping normally is created dynamically on demand.  The
   translation box need to use this mapping information for IPv4/IPv6
   packet translation.

   3) v4 v6 translation

   The translation module performs the IPv4 IPv6 packets translation.
   The translation module may need the mapping information to perform
   the translation, so the mapping information and translation module
   need to be synchronized.  The translation may perform based on SIIT
   [RFC2765].




































Liu                     Expires September 8, 2010               [Page 4]


Internet-Draft             NAT46 consideration                March 2010


2.  Conventions used in this document

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














































Liu                     Expires September 8, 2010               [Page 5]


Internet-Draft             NAT46 consideration                March 2010


3.  Terminology

   NAT46 GW: NAT46 gateway, refer to the entity that performs the IPv4/
   IPv6 translation.

   Mapped-IPv4 address: Refers to the dynamically created IPv4 address
   that maps to the server's IPv6 address.  This mapping information
   need to be synchronized with the NAT46 GW.











































Liu                     Expires September 8, 2010               [Page 6]


Internet-Draft             NAT46 consideration                March 2010


4. DNS46 consideration

   The DNS handling and IPv4/IPv6 address mapping function together
   could be recognised as DNS46 ALG.

   There are different approaches to implement DNS46 ALG: in translation
   box, in DNS system, and in host.

   1) Translation box (NAT46 GW) performs DNS46 ALG.

   In this approach, the IPv4 application's type A DNS query message
   will arrive at the NAT46 GW, the NAT46 GW translates it into IPv6
   packet and change type A to AAAA.  If the DNS system returns AAAA
   response, the NAT46 GW will translate the IPv6 DNS response packet
   into IPv4 and create a mapping of the AAAA record and a mapped-IPv4
   address of the server then return to the IPv4 host a A record which
   contains the mapped-IPv4 address.  The IPv4 client will use the
   mapped-IPv4 address as the IPv6 server's IP address to start the
   communication.

   2) DNS46 performs DNS46 ALG.

   In this approach, there will be a DNS46 server in the network and
   performs the DNS46 ALG.  The IPv4 client's type A DNS query will
   arrive at the DNS46 server, the DNS46 server will perform type A
   query, if there is no response, DNS46 will perform type AAAA query.
   If there is a type AAAA DNS response, DNS46 will create a mapping
   between the returned IPv6 address and a dynamically generated IPv4
   address.  Then DNS46 will return the mapped type A DNS response
   message to the IPv4 client.  The DNS46 needs to synchronize this
   mapping information to the NAT46 GW.  The IPv4 client will then use
   this mapped-IPv4 address to initiate the communication.

   3) Host performs DNS46 ALG.

   In this approach, the DNS46 ALG function resides in the host.  The
   IPv4 application in the IPv4 client send type A DNS query.  The DNS46
   ALG function in the host sends both type A and AAAA DNS query, when a
   type AAAA DNS response is received, the DNS46 ALG function in the
   host create a mapping between the IPv6 address of the server and a
   dynamically created mapped-IPv4 address.  If the IPv4/IPv6
   translation function resides in the host, the DNS46 function could
   synchronize the mapping information using internal implementation
   specific mechanism.Otherwise, an external synchronization mechanism
   is needed.

   The three different approaches have their own advantages and
   disadvantages:



Liu                     Expires September 8, 2010               [Page 7]


Internet-Draft             NAT46 consideration                March 2010


   For the approach that performs DNS46 ALG in NAT46 GW, the main
   disadvantage is that it will add complexity to the NAT46 GW.  The
   advantage of this approach is that there is no synchronization
   mechanism needed and no need to change the host and DNS system.  The
   DNS46 approach's main advantage is that it reduces the complexity of
   the NAT46 GW and no change to the host.  The disadvantage of this
   approach is that it needs to introduce new DNS entity (DNS46) and
   need to synchronize the IPv6-IPv4 mapping information between the
   NAT46 GW and DNS46.  The advantage of host based DNS46 ALG approach
   is that it reduces the complexity of the NAT46 GW and no need to
   change of DNS system.  The main disadvantage of this approach is that
   it requires changes to the host.

   There already have some proposals that try to solve the v4 v6
   communication problem: Virtual IPv6 connection[ID-Virual IP] and
   soure IP NAT[ID-Source NAT].  Virtual IPv6 connection is based on the
   DNS system to perform DNS46 function.  Specifically, in virtual IPv6
   connection, the recursive DNS server requests the translation box to
   create the mapping information and then return the created A record
   to the application.  Source IP NAT is also a DNS based solution.  It
   uses flow information to identify the mapping record and thence allow
   each IPv4 address be used in multiple distinct communications.
   NAT-PT is a solution that using the translation box to performs DNS46
   ALG function.  But since NAT-PT's DNS46 ALG has many issues and
   limitations as discussed in RFC4966[RFC4966], the NAT-PT
   specification was abolished.

























Liu                     Expires September 8, 2010               [Page 8]


Internet-Draft             NAT46 consideration                March 2010


5. NAT46 GW consideration

   NAT46 GW performs the translation function between IPv4 and IPv6.
   The NAT46 GW gets the mapping information of the server's IPv6
   address and mapped-IPv4 address by DNS46 ALG function which either
   resides in NAT46 GW, DNS46 or in the host.  The IPv4 packets with the
   mapped-IPv4 address as its destination address will be routed to the
   NAT46 GW.  The NAT46 GW will first query its mapping table to see
   whether there is a mapping entry of this IPv4 address exist.  When a
   mapping entry is found, the NAT46 GW will translate the IPv4
   destination address to its corresponding IPv6 destination address.
   The IPv4 source address could be translated by adding a NAT46 GW
   prefix.






































Liu                     Expires September 8, 2010               [Page 9]


Internet-Draft             NAT46 consideration                March 2010


6. ALG consideration

   When there is an IP address embedded in the payload, it will require
   the NAT46 GW to perform translation of the embedded IP address.
   NAT46 GW should support the most crucial legacy application's ALG.
   It would not require the NAT46 GW to support all the ALGs due to the
   scalability and complexity restriction.












































Liu                     Expires September 8, 2010              [Page 10]


Internet-Draft             NAT46 consideration                March 2010


7. NAT46 solution

   This section discusses a NAT46 solution which implement Extened Name
   Resolver(ENR) and address mapping function in the translation box.
   There is no external synchronization mechanism needed since the
   address mapping and translation function resides in the same box.(as
   illustrated by figure 2)


   +----------------------------------------------------------------+
   |                                                                |
   |                                                                |
   | +----------------+                          +---------------+  |
   | | IPv4 Network   |    Translation box       |IPv6 Internet  |  |
   | | +-----------+  |  +--------------------+  |+------------+ |  |
   | | |           |--|--|+---+ +------------+|  ||            | |  |
   | | |           |     ||ENR| |Addr Mapping||--||IPv6 Server | |  |
   | | |IPv4 Client|  |  |+---+ +------------+|  ||            | |  |
   | | +-----------+  |  +--------------------+  |+------------+ |  |
   | |                |                          |               |  |
   | +----------------+                          +---------------+  |
   |           |                                        |           |
   |          DNS                                      DNS          |
   |                                                                |
   |                                                                |
   +----------------------------------------------------------------+
                   Figure 2        ENR based NAT46 solution

   The ENR module works as follows:

   1)The IPv4 application send type A DNS query.  The IPv4 client may be
   configured to use the Translation box as its DNS server.

   2)The type A DNS query is routed to the ENR module of the translation
   box, the ENR module will then send both type A and AAAA queries to
   the DNS system using its IPv4 interface.

   3)The DNS system may return an A or an AAAA or both A and AAAA record
   according to the server's IP version.

   4)The ENR module decide what DNS response message it will send to the
   IPv4 client based on network connection type towards the IPv6
   Internet and the returned DNS message.  Table 1 illustrated the
   detail operation of ENR:







Liu                     Expires September 8, 2010              [Page 11]


Internet-Draft             NAT46 consideration                March 2010


      +---------+------+--------+-----------+---------+
      | S. App. | Net. |  Peer  | ENR resp. | Fun. Map|
      | Query   | Type |  Type  | to App.   | /Trans. |
      +---------+------+--------+-----------+---------+
      |    A    |   *  |    A   |     A     | no need |
      |    A    |   *  | A/AAAA |     A     | no need |
      |    A    |  v6  |  AAAA  | Mapping A |  v4-v6  |
      |    A    | v4v6 |  AAAA  | Mapping A |  v4-v6  |
      +---------+------+--------+-----------+---------+
           Table 1: ENR function based on network type

   As table 1 illustrated, ENR function could perform intelligent DNS
   handling based on the current connection type.  Here Net.Type is the
   translation box's network connection type towards the IPv6 Internet.

   In the case that v6 to v4 mapping is needed, ENR module requests the
   address mapping module to create a mapped-IPv4 address for the
   server's IPv6 address.  The ENR module will then return an A record
   which contains the mapped-IPv4 address.  The IPv4 client will use
   this mapped-IPv4 address as the destination address of the server to
   start communication.






























Liu                     Expires September 8, 2010              [Page 12]


Internet-Draft             NAT46 consideration                March 2010


8.  Security Considerations

   TBD
















































Liu                     Expires September 8, 2010              [Page 13]


Internet-Draft             NAT46 consideration                March 2010


9.  IANA Considerations

   None
















































Liu                     Expires September 8, 2010              [Page 14]


Internet-Draft             NAT46 consideration                March 2010


10.  Contributors

     Zhen Cao
     China Mobile
     caozhen@chinamobile.com

     Bo Zhou
     China Mobile
     zhouboyj@chinamobile.com

















































Liu                     Expires September 8, 2010              [Page 15]


Internet-Draft             NAT46 consideration                March 2010


11.References

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

   [ID-Virual IP] Christian Vogt,"Virtual IPv6 Connectivity for IPv4-Only
                  Networks", 2009

   [ID-Source NAT] C. Perkins, "Translating IPv4 to IPv6 based on source
                   IPv4 address", 2009

   [RFC2765] Nordmark,E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
             RFC 2765, February 2000.

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













































Liu                     Expires September 8, 2010              [Page 16]


Internet-Draft             NAT46 consideration                March 2010


Author's Address

   Dapeng Liu
   China Mobile
   Unit2, 28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: liudapeng@chinamobile.com


   Hui Deng
   China Mobile
   Unit2, 28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: denghui@chinamobile.com







































Liu                     Expires September 8, 2010              [Page 17]


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