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]