Behave B. Huang
Internet-Draft H. Deng
Obsoletes: 2767 (if approved) China Mobile
Intended status: Experimental T. Savolainen
Expires: September 8, 2010 Nokia
March 7, 2010
Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)
draft-huang-behave-rfc2767bis-02
Abstract
This document describes the "Bump-In-the-Stack" (BIS) 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. Furthermore,
this technology avoids need for unnecessary double protocol
translation in the case where destination is dual-stack enabled.
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 will communicate
directly with other hosts reachable with the different address
family. In the case of IPv6 only network or IPv6 only destination,
IPv4-originated communications have to be be translated into IPv6.
In the scenario of single address family access network, but dual-
stack destination, network based translation is always avoided.
Technically, the BIS-enabled host resolves both IPv4 and IPv6
addresses of the destination and behaves according to received
responses.
Acknowledgement of previous work
This document is an update to and directly derivative from Kazuaki
TSUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's [RFC2767],
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 three components
1. Supporting IPv6 only network connections
2. Extending ENR and address mapper to operate differently
3. Adding an alternative way to implement the ENR
Huang, et al. Expires September 8, 2010 [Page 1]
Internet-Draft Dual Stack Hosts using BIS March 2010
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 Dual Stack Hosts using BIS March 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Components . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Translator . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Extension Name Resolver (ENR) . . . . . . . . . . . . . . 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. Applicability and Limitations . . . . . . . . . . . . . . . . 12
5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 12
6. ALG related . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Implementation of ENR . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Huang, et al. Expires September 8, 2010 [Page 3]
Internet-Draft Dual Stack Hosts using BIS March 2010
1. Introduction
BIS [RFC2767]stated that there are few applications for IPv6 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. Meanwhile, there are scenarios where a dual stack
host is connected to IPv6-only network but it is running IPv4-only
applications, or a host is running IPv6- only applications while
connected to IPv4-only network.
BIS proposed a mechanism of dual stack hosts using the technique
called "Bump-in-the-Stack" in the IP security area. The technique
inserts modules, which snoop data flowing between a TCP/IPv4 module
and network card driver modules and translate IPv4 into IPv6 and vice
versa, into the hosts, and makes them self-translators. When they
communicate with the other IPv6 hosts, pooled IPv4 addresses are
assigned to the IPv6 hosts internally, but the IPv4 addresses never
flow out from them.
The network scenario specified in RFC2767 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. The opposite happens
when the network is IPv4-only and application is IPv6-only capable.
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
communicate with IPv6 peers.
If the network which host is connecting with is dual stack network,
then host will behave as what RFC 2767 originally described.
However, even in the dual stack access network case it can be that
the destination peer is only reachable via single address family. In
case there is a conflict between the address family supported by an
application and the peer, BIS is needed.
Since the translation is automatically carried out with the help of
DNS protocol, most applications do not need to know whether the
target hosts are IPv6 or IPv4 ones. That is, this allows hosts to
communicate with other IPv6 hosts using existing IPv4 applications
Huang, et al. Expires September 8, 2010 [Page 4]
Internet-Draft Dual Stack Hosts using BIS March 2010
and other IPv4 hosts using existing IPv6 applications; thus it seems
as if peers are always dual stack hosts with applications for both
IPv4 and IPv6.
This document uses terms defined in [RFC2460] , [RFC2893] , [RFC2767]
and [RFC3338].
Huang, et al. Expires September 8, 2010 [Page 5]
Internet-Draft Dual Stack Hosts using BIS March 2010
2. Components
Dual stack hosts need applications, TCP/IP modules and addresses for
both IPv4 and IPv6. The proposed hosts in this memo have 3 newly
defined modules: a translator, an extension name resolver (ENR) and
an address mapper. These hosts communicate with other IPv6 hosts
using IPv4 application.
Figure 1 illustrates the structure of the host in which new modules
are installed.
+-------------------------------------------------------------+
| +-------------------------------------------------------+ |
| | IPv4 applications | |
| +-------------------------------------------------------+ |
| +-------------------------------------------------------+ |
| | TCP/IPv4 | |
| | +---------------------------------------------------+ |
| | | +-----------+ +---------+ +---------------+ |
| | | | extension | | address | | translator | |
| | | | name | | mapper | +---------------+ |
| | | | resolver | | | +---------------+ |
| | | | | | | | IPv6 | |
| +---+ +-----------+ +---------+ +---------------+ |
| +-------------------------------------------------------+ |
| | Network card drivers | |
| +-------------------------------------------------------+ |
+-------------------------------------------------------------+
+-------------------------------------------------------------+
| Network cards |
+-------------------------------------------------------------+
Figure 1: Structure of the proposed dual stack host
2.1. Translator
It translates IPv4 into IPv6 and vice versa using the IP conversion
mechanism defined in SIIT [RFC2765].
When receiving IPv4 packets from IPv4 applications, translator
converts IPv4 packet headers into IPv6 packet headers, then, if
required, fragments the IPv6 packets (because header length of IPv6
is typically 20 bytes larger than that of IPv4), and sends them to
IPv6 networks. When receiving IPv6 packets from the IPv6 networks,
translator works symmetrically to the previous case, except that
there is no need to fragment the packets.
Huang, et al. Expires September 8, 2010 [Page 6]
Internet-Draft Dual Stack Hosts using BIS March 2010
2.2. Extension Name Resolver (ENR)
ENR returns always a "proper" answer in response to the IPv4
application's name resolution requests. In the case network does not
return the IP address family application requested, the ENR will
requests the address mapper to assign a local IP address
corresponding to received IP address, and then synthesize 'A' record
for the assigned IP address. E.g. in case of AAAA response is
received while application asked for A, the address mapper will
select a local IPv4 address, and ENR will synthesize 'A' record based
on it.
The application typically sends a query to a name server to resolve
'A' records for the target host name. ENR snoops the query, then, if
required, creates another query to ensure both 'A' and 'AAAA' records
are requested for the host name, and sends the queries to the DNS
server.
The following table illustrates ENR behaviour. The address
application receives, and whether synthesis happens, is independent
of the address families a host is actually provisioned with.
Application | Network | ENR behaviour
query | response |
------------+----------+---------------------
A | A | <return A record>
A | AAAA | <synthesize A record>
A | A/AAAA | <return A record>
Figure 2: ENR behaviour illustration
NOTE: This action is similar to that of the DNS64 in the network
side, here it happens on the host.
NOTE: An implementation option is to have ENR support in host's
(stub) DNS resolver itself as described in [DNS64], in which case
record synthesis is not needed and advanced functions such as DNSSEC
are possible. If the ENR is implemented in BIS-module, same
limitations arise as when DNS record synthesis is done on network.
Anyway, it depends on the host to implement recursive DNS server by
itself.
2.3. Address mapper
Address mapper ("the mapper" later on ), maintains an IPv4 address
pool in the case of dual stack network and IPv6 only network. The
pool can consists of private IPv4 addresses. Also, mapper maintains
a table consisting of pairs of these locally selected IPv4 addresses
Huang, et al. Expires September 8, 2010 [Page 7]
Internet-Draft Dual Stack Hosts using BIS March 2010
and a destinations's IPv6 addresses.
When the extension name resolver or the translator 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 translator gets a socket API function call from the data
received and there is not a mapping entry for the IPv6 source
address.
When the resolver or the translator 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 3: 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).
Huang, et al. Expires September 8, 2010 [Page 8]
Internet-Draft Dual Stack Hosts using BIS March 2010
(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.
(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.
Huang, et al. Expires September 8, 2010 [Page 9]
Internet-Draft Dual Stack Hosts using BIS March 2010
3. Behavior Examples
The mechanism of BIS 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 3 of [RFC2767] 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 3 of
[RFC2767] 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 3 of [RFC2767].
If both the 'A' and 'AAAA' records are resolved, then there will be a
little difference with section 3 of [RFC2767], 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 Dual Stack Hosts using BIS March 2010
4. Considerations
This section considers some issues of the proposed dual stack hosts.
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 Dual Stack Hosts using BIS March 2010
5. Applicability and Limitations
This section considers applicability and limitations of the proposed
dual stack hosts.
5.1. Applicability
The mechanism can be useful for people in the initial stages of IPv6
transition when significant percentage of applications are not yet
modified into IPv6 realm. BIS can also help users who cannot upgrade
their important legacy applications for any reason, such as due to
lacking of maintenance support. The reason is that BIS allows hosts
to communicate with IPv6 hosts using existing IPv4 applications, and
that people can get connectivity for both IPv4 and IPv6 even if they
do not have IPv6 applications.
Furthermore, as protocol translation is supported also from IPv6 to
IPv4, application developers can focus on implementing only IPv6
support.
5.2. Limitations
BIS allows hosts to communicate with IPv6 enabled hosts using
existing IPv4 applications, but this can not be applied to IPv4
applications which use special IPv4 options since it is impossible to
translate IPv4 options into IPv6. Similarly it is impossible to
translate any IPv6 option headers into IPv4, except for fragment
headers and routing headers. So IPv6 inbound communication having
the option headers may be rejected. But this kind of usage is not
the majority of today's IP traffic.
Huang, et al. Expires September 8, 2010 [Page 12]
Internet-Draft Dual Stack Hosts using BIS March 2010
6. ALG related
BIS host should only perform a minimum of ALG, especially for Host to
Host Direct scenario to avoid complicated ALG design for various kind
of appliation. ALG design is not encouraged for host based
translation. It is out of scope of this document, and it will be
handled in other document.
Huang, et al. Expires September 8, 2010 [Page 13]
Internet-Draft Dual Stack Hosts using BIS March 2010
7. 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 14]
Internet-Draft Dual Stack Hosts using BIS March 2010
8. 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 15]
Internet-Draft Dual Stack Hosts using BIS March 2010
9. 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 16]
Internet-Draft Dual Stack Hosts using BIS 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 17]
Internet-Draft Dual Stack Hosts using BIS 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 18]