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

Versions: (RFC 3338) 00 01 02

Behave                                                          B. Huang
Internet-Draft                                                   H. Deng
Obsoletes: 3338 (if approved)                               China Mobile
Intended status: Experimental                              T. Savolainen
Expires: September 8, 2010                                         Nokia
                                                           March 7, 2010


             Dual Stack Hosts Using "Bump-in-the-API" (BIA)
                    draft-huang-behave-rfc3338bis-02

Abstract

   This document describes the "Bump-In-the-API" (BIA) host based
   protocol translation mechanism that allows applications supporting
   only one IP address family to communicate with peers that are
   reachable or supporting only the other address family.

   This specification addresses scenarios where a host is provided dual
   stack or IPv6 only network connectivity.  In the dual stack network
   case, single address family applications in the host sometime will
   communicate directly with other hosts using the different address
   family.  In the case of IPv6 only network or IPv6 only destination,
   IPv4-originated communications have to be translated into IPv6.
   Technically, the BIA-enabled host resolves both A and AAAA addresses
   of the destination and behaves according to received responses.

   Acknowledgement of previous work

   This document is an update to and directly derivative from Seungyun
   Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and Erik Nordmark's
   [RFC3338], which similarly provides a dual stack host means to
   communicate with other IPv6 host using existing IPv4 appliations.The
   original document was a product of the NGTRANS working group.

   The changes in this document reflect four components

      1.  Supporting IPv6 only network connections

      2.  IPv4 address pool use private address

      3.  Extending ENR and address mapper to operate differently

      4.  Adding an alternative way to implement the ENR

   The goal of this mechanism is the same as that of the Bump-in-the-
   stack mechanism, but this mechanism provides the translation method
   between the IPv4 APIs and IPv6 APIs.  Thus, the goal is simply



Huang, et al.           Expires September 8, 2010               [Page 1]


Internet-Draft                     BIA                        March 2010


   achieved without IP header translation.

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

   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.












Huang, et al.           Expires September 8, 2010               [Page 2]


Internet-Draft                     BIA                        March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Dual Stack Host Architecture Using BIA . . . . . . . . . . . .  6
     2.1.  Function Mapper  . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Extension Name Resolver  . . . . . . . . . . . . . . . . .  7
     2.3.  Address Mapper . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Behavior Examples  . . . . . . . . . . . . . . . . . . . . . . 10
     3.1.  dual stack network and IPv6 only peer  . . . . . . . . . . 10
     3.2.  IPv6 only network and dual-stack peer  . . . . . . . . . . 10
   4.  Considerations . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  IPv4 Address Pool and Mapping Table  . . . . . . . . . . . 11
     4.2.  Internally Assigned IPv4 or IPv6 Addresses . . . . . . . . 11
   5.  ALG related  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Implementation of ENR . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
































Huang, et al.           Expires September 8, 2010               [Page 3]


Internet-Draft                     BIA                        March 2010


1.  Introduction

   [RFC3338] stated that there are few applications for IPv6 [RFC2460]
   as compared with IPv4 in which a great number of applications are
   available.  In order to advance the transition smoothly, it is highly
   desirable to make the availability of IPv6 applications increase to
   the same level as IPv4.  Unfortunately, however, this is expected to
   take a long time.

   BIA [RFC3338] proposed a mechanism of dual stack hosts using the
   technique called "Bump-in-the-API" in the IP security area.  The
   technique inserts an API translator between the socket API module and
   the TCP/IP module in the dual stack hosts, so that it translates the
   IPv4 socket API function into IPv6 socket API function and vice
   versa.

   BIS [RFC2767] specifies a host translation mechanism using a
   technique called "Bump-in-the-Stack".  It translates IPv4 into IPv6,
   and vice versa using the IP conversion mechanism defined in SIIT
   [RFC2765].  BIS allows hosts to communicate with other IPv6 hosts
   using existing IPv4 applications.  However, this approach is to use a
   translator which is inserted between the TCP/IP module and network
   card driver, so that it has the same limitations as the SIIT based IP
   header translation methods.  In addition, its implementation is
   dependent upon the network interface driver.

   When IPv4 applications on the dual stack communicate with other IPv6
   hosts, the API translator detects the socket API functions from IPv4
   applications and invokes the IPv6 socket API functions to communicate
   with the IPv6 hosts, and vice versa.  In order to support
   communication between IPv4 applications and the target IPv6 hosts,
   pooled IPv4 addresses will be assigned through the extension name
   resolver in the API translator.  But the those IPv4 addresses never
   flow out from them.

   The network scenario specified in [RFC3338] is a dual stack network.
   where IPv4 communication can be transported independently of IPv6.
   However, if the network provides only IPv6 transport, applications's
   IPv4 packets have to be translated into IPv6.

   This specification assumes that host knows it is connected with a
   dual stack network or IPv6-only network.  The host learns that from
   layer 2 or from results of layer 3 IP address configuration
   mechanisms.

   If the network which host is connecting with is IPv6 only network,
   then host's IPv6 application will behave reguarly, and it's IPv4
   application's packets have to be translated into IPv6 in order to



Huang, et al.           Expires September 8, 2010               [Page 4]


Internet-Draft                     BIA                        March 2010


   communicate with IPv6 applications.

   If the network which host is connecting with is dual stack network,
   then host will behave as what [RFC3338] originally described.

   The scenario where destination peer is not reachable with the address
   family a host is provisioned with is not covered by this document, as
   that requires network based protocol translation solution.  However,
   the BIA technology can complement network based protocol translation
   .

   Moreover, since the translation is automatically carried out with the
   help of DNS protocol, most applications do not need to know whether
   target hosts are IPv6 or IPv4 ones.  That is, this allows hosts to
   communicate with other IPv6 hosts using existing IPv4 applications ;
   thus it seems as if peers are always dual stack hosts with
   applications for both IPv4 and IPv6.

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

   This document uses terms defined in [RFC2460] , [RFC2893] , [RFC2767]
   and [RFC3338].



























Huang, et al.           Expires September 8, 2010               [Page 5]


Internet-Draft                     BIA                        March 2010


2.  Dual Stack Host Architecture Using BIA

   Figure 1 shows the architecture of the host in which BIA is
   installed.


                  +----------------------------------------------+
                  | +------------------------------------------+ |
                  | |                                          | |
                  | |            IPv4 applications             | |
                  | |                                          | |
                  | +------------------------------------------+ |
                  | +------------------------------------------+ |
                  | |           Socket API (IPv4, IPv6)        | |
                  | +------------------------------------------+ |
                  | +-[ API translator]------------------------+ |
                  | | +-----------+ +---------+ +------------+ | |
                  | | | Ext. Name | | Address | | Function   | | |
                  | | | Resolver  | | Mapper  | | Mapper     | | |
                  | | +-----------+ +---------+ +------------+ | |
                  | +------------------------------------------+ |
                  | +--------------------+ +-------------------+ |
                  | |                    | |                   | |
                  | |    TCP(UDP)/IPv4   | |   TCP(UDP)/IPv6   | |
                  | |                    | |                   | |
                  | +--------------------+ +-------------------+ |
                  +----------------------------------------------+

          Figure 1: Architecture of the dual stack host using BIA

   Dual stack hosts defined in RFC2893 [RFC2893] need applications,
   TCP/IP modules and addresses for both IPv4 and IPv6.  The proposed
   hosts in this document have an API translator to communicate with
   other IPv6 hosts using existing IPv4 applications.  The API
   translator consists of 3 modules, an extension name resolver, an
   address mapper and a function mapper.

2.1.  Function Mapper

   It translates an IPv4 socket API function into an IPv6 socket API
   function, and vice versa.

   When detecting the IPv4 socket API functions from IPv4 applications,
   it intercepts the function call and invokes new IPv6 socket API
   functions which correspond to the IPv4 socket API functions.  Those
   IPv6 API functions are used to communicate with the target IPv6
   hosts.  When detecting the IPv6 socket API functions from the data
   received from the IPv6 hosts, it works symmetrically in relation to



Huang, et al.           Expires September 8, 2010               [Page 6]


Internet-Draft                     BIA                        March 2010


   the previous case.

2.2.  Extension Name Resolver

   It returns a proper answer in response to the IPv4 or IPv6
   application's request.

   When an IPv4 application in an IPv6 only network tries to resolve
   names via the resolver library (e.g. gethostbyname()), BIA intercept
   the function call and instead call the IPv6 equivalent functions
   (e.g. getnameinfo()) that will resolve both A and AAAA records.

   If only AAAA record is available, it requests the address mapper to
   assign an IPv4 address corresponding to the IPv6 address, then
   creates the A record for the assigned IPv4 address, and returns the A
   record to the IPv4 application.

   If both A and AAAA record are available in the IPv6 only network, it
   doesn't requests the address mapper but directly send this A record
   and AAAA record to address mapper to store this relationship, then
   directly pass this A record to the IPv4 application.

2.3.  Address Mapper

   It internally maintains a table of the pairs of an IPv4 address and
   an IPv6 address.  The IPv4 addresses are assigned from an IPv4
   address pool.  The pool can consists of private IPv4 addresses.

   When the extension name resolver or the function mapper requests it
   to assign an IPv4 address corresponding to an IPv6 address, it
   selects and returns an IPv4 address out of the pool, and registers a
   new entry into the table dynamically.  The registration occurs in the
   following 3 cases:

   (1) When the extension name resolver gets only an 'AAAA' record for
   the target host name in the dual stack or IPv6 only network and there
   is not a mapping entry for the IPv6 address.

   (2) When the extension name resolver gets both an 'A' record and an
   'AAAA' record for the target host name in the IPv6 only network and
   there is not a mapping entry for the IPv6 address.  But it doesn't
   need an IPv4 address out of the pool, just registers both IPv4 and
   IPv6 address from 'A' and 'AAAA' records into a new entry into the
   table.

   (3) When the function mapper gets a socket API function call from the
   data received and there is not a mapping entry for the IPv6 source
   address.



Huang, et al.           Expires September 8, 2010               [Page 7]


Internet-Draft                     BIA                        March 2010


   When the resolver or the function mapper requests mapper to assign an
   IPv4 address corresponding to an IPv6 address, mapper, if required,
   selects and returns an IPv4 address out of the pool, and registers a
   new entry into the table dynamically.  The following table describes
   how mappings are created into the table in each scenario :

          Mapping table | Access    | Peer   | Created
          entry for     |link type  | support| address mapping
       -------------------+-------------+-------------------------------
       (1) real IPv4    |IPv4 or DS | v4     | < no mapping needed >
       (2) real IPv6    |IPv6 or DS | v6     | < no mapping needed >
       (3) real IPv4    |IPv6       | v4 & v6| real IPv4 -> real IPv6
       (4) real IPv6    |IPv4       | v4 & v6| real IPv6 -> real IPv4
       (5) local IPv4   |IPv6 or DS | v6     | local IPv4 -> real IPv6
       (6) local IPv6   |IPv4 or DS | v4     | local IPv6 -> real IPv4
       (7) real IPv4    |IPv6       | v4     | out of scope
       (8) real IPv6    |IPv4       | v6     | out of scope

           Figure 2: Address Mapper's mapping table illustration

   Below are examples for all eight scenarios:

   (1) When the resolver gets an 'A' reply for application's 'A' query
   on access network supporting IPv4, there is no need to create mapping
   (or just stub mapping real IPv4 -> real IPv4).

   (2) When the resolver gets an 'AAAA' reply for application's 'AAAA'
   query on access network supporting IPv6, there is no need to create
   mapping (or just stub mapping real IPv6 -> real IPv6).

   (3) When the resolver gets both 'A' and 'AAAA' replies for
   application's 'A' query on IPv6-only access, there shall be mapping
   for real IPv4 to real IPv6.

   (4) When the resolver gets both 'A' and 'AAAA' replies for
   application's 'AAAA' query on IPv4-only access, there shall be
   mapping for real IPv6 to real IPv4.

   (5) When the resolver gets only an 'AAAA' record for the target host
   name for application's 'A' request on IPv6 only or DS access network,
   a local IPv4 address will be given to application and mapping for
   local IPv4 address to real IPv6 address is created.

   (6) When the resolver gets only an 'A' record for the target host
   name for application's 'AAAA' request on IPv4 only or DS access
   network, a local IPv6 address will be given to application and
   mapping for local IPv6 address to real IPv4 address is created.




Huang, et al.           Expires September 8, 2010               [Page 8]


Internet-Draft                     BIA                        March 2010


   (7) When the resolver gets only an 'A' record for the target host
   name for application's 'A' request on IPv6 only access network, a
   double translation would be required and thus is out of the scope of
   this document.

   (8) When the resolver gets only an 'AAAA' record for the target host
   name for application's 'AAAA' request on IPv4 only access network, a
   double translation would be required and thus is out of the scope of
   this document.

   NOTE: There is only one exception.  When initializing the table,
   mapper registers a pair of its own IPv4 address and IPv6 address into
   the table statically.

   NOTE: This is the same as that of the Address Mapper in [RFC2767].




































Huang, et al.           Expires September 8, 2010               [Page 9]


Internet-Draft                     BIA                        March 2010


3.  Behavior Examples

   The mechanism of BIA could be used in two type of network
   environments, the first is dual stack network and IPv6 only peer, the
   second is IPv6 only network and dual stack peer.  ENR will behave
   according to different network environment.

3.1.  dual stack network and IPv6 only peer

   There are several reasons to not upgrade IPv4 applications to support
   IPv6 such as charging, codec, lack of knowledge et al, and this is
   out of scope of this document.  Section 4 of [RFC3338] already has
   stated in detail how this work, there are no need to modify anything
   here.

3.2.  IPv6 only network and dual-stack peer

   When a dual stack server locates in the IPv6 only network, and not
   yet updated IPv4 applicaiton need to visit this server.  This is the
   network scenario of IPv6 only and dual stack peer.  There is the need
   to replace "host6" with "host46" in figure 2 of section 4 of
   [RFC3338] because the peer host is dual stack.

   If only 'AAAA' records is resolved, so the ENR need to request the
   address mapper to allocate any IPv4 addresses from its pool, it's the
   same as the section 4 of [RFC3338].

   If both the 'A' and 'AAAA' records are resolved, then there will be a
   little difference with section 4 of [RFC3338], the ENR does not need
   to request one IPv4 address from address mapper which is
   corresponding to the IPv6 address. on the contrarary, ENR will store
   the mapping between received destination's IPv4 and IPv6 addresses
   which are from 'A' and 'AAAA' records.  After that, the ENR will
   return 'A' record to the application as is.

















Huang, et al.           Expires September 8, 2010              [Page 10]


Internet-Draft                     BIA                        March 2010


4.  Considerations

   Other considerations in [RFC3338] are still the same, here only
   clarify the section of IPv4 Address Pool and Mapping Table and
   Internally Assigned IPv4 or IPv6 Addresses to support private IPv4
   address.

4.1.  IPv4 Address Pool and Mapping Table

   The address pool consists of the private IPv4 addresses.  This pool
   can be implemented at different granularity in the node e.g., a
   single pool per node, or at some finer granularity such as per user
   or per process.  However, if a number of IPv4 applications
   communicate with IPv6 hosts or IPv6 applications communicate with
   IPv4 hosts, the available address spaces will be exhausted.  As a
   result, it will be impossible for IPv4 applications to communicate
   with IPv6 nodes.  It requires smart management techniques for address
   pool.  For example, it is desirable for the mapper to free the oldest
   entry and reuse the IPv4 address or IPv6 address for creating a new
   entry.  This issues is the same as [BIS].  In case of a per-node
   address mapping table, it MAY cause a larger risk of running out of
   address.

4.2.  Internally Assigned IPv4 or IPv6 Addresses

   The IPv4 addresses, which are internally assigned to IPv6 target
   hosts out of the pool, are the private IPv4 addresses.  IPv4
   addresses, which are internally assigned to IPv6 target hosts out of
   the spool, never flow out from the host, and so do not negatively
   affect other hosts.





















Huang, et al.           Expires September 8, 2010              [Page 11]


Internet-Draft                     BIA                        March 2010


5.  ALG related

   BIA host should only perform a minimum of ALG to avoid complicated
   ALG design for various kind of appliation such as FTP, RTSP et al.
   ALG design is not encouraged for host based translation.  It is out
   of scope of this document.













































Huang, et al.           Expires September 8, 2010              [Page 12]


Internet-Draft                     BIA                        March 2010


6.  Security Considerations

   This is the same as the [RFC3338], newly added function doesn't bring
   new threat to the host based translation.















































Huang, et al.           Expires September 8, 2010              [Page 13]


Internet-Draft                     BIA                        March 2010


7.  Acknowledgments

   The author thanks the discussion from Gang Chen, Dapeng Liu, Bo Zhou,
   Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of
   this document.

   The efforts of Suresh Krishnan, Mohamed Boucadair, Yiu L. Lee, James
   Woodyatt, Lorenzo Colitti, Qibo Niu, Pierrick Seite, Dean Cheng,
   Christian Vogt, Jan M. Melen in reviewing this document are
   gratefully acknowledged.

   Advice from Dan Wing, Dave Thaler and Magnus Westerlund are greatly
   appreciated






































Huang, et al.           Expires September 8, 2010              [Page 14]


Internet-Draft                     BIA                        March 2010


8.  Normative References

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

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

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

   [RFC2767]  Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack
              Hosts using the "Bump-In-the-Stack" Technique (BIS)",
              RFC 2767, February 2000.

   [RFC2893]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
              IPv6 Hosts and Routers", RFC 2893, August 2000.

   [RFC3338]  Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A.
              Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)",
              RFC 3338, October 2002.






















Huang, et al.           Expires September 8, 2010              [Page 15]


Internet-Draft                     BIA                        March 2010


Appendix A.  Implementation of ENR

   It's not necessarily implment the ENR in the kernel level, but just
   implement it as the user space by set the default DNS server to
   127.0.0.1, then IPv4 application could always send DNS query to the
   localhost, then ENR will send both A and AAAA query to the actual DNS
   server.  So ENR will keep the real DNS server address.












































Huang, et al.           Expires September 8, 2010              [Page 16]


Internet-Draft                     BIA                        March 2010


Authors' Addresses

   Bill Huang
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: bill.huang@chinamobile.com


   Hui Deng
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: denghui02@gmail.com


   Teemu Savolainen
   Nokia
   Hermiankatu 12 D
   FI-33720 TAMPERE
   Finland

   Email: teemu.savolainen@nokia.com






















Huang, et al.           Expires September 8, 2010              [Page 17]


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