Behave B. Huang
Internet-Draft H. Deng
Obsoletes: 2767 (if approved) China Mobile
Intended status: Experimental T. Savolainen
Expires: August 21, 2010 Nokia
February 17, 2010
Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)
draft-huang-behave-rfc2767bis-01
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, IPv6 only or IPv4 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. IPv6 communications may have to translated
similarly to IPv4. 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. Supporting IPv4 only network connections
Huang, et al. Expires August 21, 2010 [Page 1]
Internet-Draft Dual Stack Hosts using BIS February 2010
3. Supporting dual stack network connections with 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 August 21, 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 August 21, 2010 [Page 2]
Internet-Draft Dual Stack Hosts using BIS February 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 . . . . . . . . . . . . . . . . . . . . . . 8
3. Action Examples -- dual stack network and IPv6 only peer . . . 10
3.1. Originator behavior . . . . . . . . . . . . . . . . . . . 10
3.2. Recipient behavior . . . . . . . . . . . . . . . . . . . . 12
4. Action Examples -- IPv6 only network and dual-stack peer . . . 15
4.1. Originator behavior . . . . . . . . . . . . . . . . . . . 15
4.2. Recipient behavior . . . . . . . . . . . . . . . . . . . . 17
5. Action Examples -- IPv4 only network and IPv4 only peer . . . 18
5.1. Originator behavior . . . . . . . . . . . . . . . . . . . 18
5.2. Recipient behavior . . . . . . . . . . . . . . . . . . . . 20
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. IP conversion . . . . . . . . . . . . . . . . . . . . . . 23
6.2. IPv4 or IPv6 Address Pool and Mapping Table . . . . . . . 23
6.3. Internally Assigned IPv4 or IPv6 Addresses . . . . . . . . 23
7. Applicability and Limitations . . . . . . . . . . . . . . . . 24
7.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 24
8. ALG related . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. Normative References . . . . . . . . . . . . . . . . . . . . . 28
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Huang, et al. Expires August 21, 2010 [Page 3]
Internet-Draft Dual Stack Hosts using BIS February 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, IPv6-only network or IPv4-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 IPv4 only network,
then host's IPv4 application will behave regularly, and it's IPv6
application's packets have to be translated into IPv4 packets.
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.
Huang, et al. Expires August 21, 2010 [Page 4]
Internet-Draft Dual Stack Hosts using BIS February 2010
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
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 August 21, 2010 [Page 5]
Internet-Draft Dual Stack Hosts using BIS February 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 and IPv4 hosts using IPv6 application.
Figure 1 illustrates the structure of the host in which new modules
are installed.
+----------------------------------------------------------------+
| +---------------------------+ +---------------------------+ |
| | IPv4 applications | | IPv6 applications | |
| +---------------------------+ +---------------------------+ |
| +---------------------------+ +---------------------------+ |
| | TCP/IPv4 | | TCP/IPv6 | |
| | +-----------------------+ +----------------------+ | |
| | | +-----------+ +---------------+ +---------+ | | |
| | | | Extension | | translator | | address | | | |
| | | | Name | +---------------+ | mapper | | | |
| | | | Resolver | +------+ +------+ | | | | |
| | | | | | IPv6 | | IPv4 | | | | | |
| +---+ +-----------+ +------+ +------+ +---------+ +----+ |
| +----------------------------------------------------------+ |
| | 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 in the IPv6 only
network, 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.
When receiving IPv6 packets from IPv6 applications in the IPv4 only
Huang, et al. Expires August 21, 2010 [Page 6]
Internet-Draft Dual Stack Hosts using BIS February 2010
network, translator converts IPv6 packet headers into IPv4 packet
headers, but doesn't do fragmentation as packet size is decreased,
and sends packets to IPv4 networks. When receiving IPv4 packets from
the IPv4 networks, it works symmetrically to the previous case.
(NOTE: for packet received from network, if there is unsolicited IPv4
1500 byte packet coming from the network, which needs to be
translated into IPv6 inside a host, then there is a need to fragment
the packets)
2.2. Extension Name Resolver (ENR)
ENR returns always a "proper" answer in response to the IPv4 and IPv6
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' or
'AAAA' 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', 'AAAA', or both, 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 as is>
A | AAAA | <synthesize A record>
AAAA | AAAA | <return as is>
AAAA | A | <synthesize AAAA 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
Huang, et al. Expires August 21, 2010 [Page 7]
Internet-Draft Dual Stack Hosts using BIS February 2010
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
and a destinations' IPv6 addresses.
In the case of dual-stack networks and IPv4 only networks, mapper
creates locally used IPv6 addresses by concatenation of IPv6 prefix
and destination's IPv4 address. The mapper maintains a table
consisting of pairs of local IPv6 addresseses and destinations' IPv4
addresses.
When the resolver or the translator requests mapper to assign an IPv4
address corresponding to an IPv6 address or assign an IPv6 address
corresponding to an IPv4 address, mapper, if required, selects and
returns an IPv4 address out of the pool, or concatenated IPv6
address, and registers a new entry into the table dynamically. The
following table describes how mappings are created into the table in
each scenario (note that the scenario of destination not supporting
the same address family host is provisioned with, and where network
based translation assistance would be needed, is shown in the table
for the sake of completeness only (7 & 8)):
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 | real IPv4 -> synthetic IPv6
(8) real IPv6 |IPv4 | v6 | real IPv6 -> synthetic IPv4
Figure 3: Address Mapper's mapping table illustration
Below are example for all six 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 August 21, 2010 [Page 8]
Internet-Draft Dual Stack Hosts using BIS February 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 August 21, 2010 [Page 9]
Internet-Draft Dual Stack Hosts using BIS February 2010
3. Action Examples -- dual stack network and IPv6 only peer
This section describes action of the proposed dual stack host called
"dual stack," which communicates with an IPv6 peer called "host6"
using an IPv4 application on dual stack network.
3.1. Originator behavior
This subsection describes the originator behavior of "dual stack."
The communication is triggered by "dual stack."
The application sends a query to its name server to resolve 'A'
records for "host6."
The resolver snoops the query, then creates another query for 'AAAA'
to resolve both 'A' and 'AAAA' records for the host name, and sends
it to the server. In this case, only the 'AAAA' record is resolved,
so the resolver requests the mapper to assign an IPv4 address
corresponding to the IPv6 address.
NOTE: In the case of communication with an IPv4 host, the 'A' record
is resolved and then the resolver returns it to the application as
is. There is no need for the IP conversion as shown later.
The mapper selects an IPv4 address out of the pool and returns it to
the ENR.
The ENR creates the 'A' record for the assigned IPv4 address and
returns it to the application.
NOTE: See subsection 6.3 about the influence on other hosts caused by
an IPv4 address assigned here.
The application sends an IPv4 packet to "host6."
The IPv4 packet reaches the translator. The translator tries to
translate the IPv4 packet into an IPv6 packet but does not know how
to translate the IPv4 destination address and the IPv4 source
address. So the translator requests the mapper to provide mapping
entries for them.
The mapper checks its mapping table and finds entries for each of
them, and then returns the IPv6 destination address and the IPv6
source address to the translator.
NOTE: The mapper will register its own IPv4 address and IPv6 address
into the table beforehand. See subsection 2.3.
Huang, et al. Expires August 21, 2010 [Page 10]
Internet-Draft Dual Stack Hosts using BIS February 2010
The translator translates the IPv4 packet into an IPv6 packet and
then fragments the IPv6 packet if necessary and sends it to an IPv6
network.
The IPv6 packet reaches "host6." Then "host6" sends a new IPv6
packet to "dual stack."
The IPv6 packet reaches the translator in "dual stack."
The translator gets mapping entries for the IPv6 destination address
and the IPv6 source address from the mapper in the same way as
before.
Then the translator translates the IPv6 packet into an IPv4 packet
and tosses it up to the application.
The following diagram illustrates the action described above:
"dual stack" "host6"
IPv4 TCP/ extension address translator IPv6
appli- IPv4 name mapper
cation resolver
| | | | | | |
<<Resolve an IPv4 address for "host6".>> | |
| | | | | | |
|------|------>| Query of 'A' records for "host6". | Name
| | | | | | | Server
| | |---------|-------|-----------|---------|--->|
| | | Query of 'A' records and 'AAAA' for "host6"
| | | | | | | |
| | |<--------|-------|-----------|---------|----|
| | | Reply only with 'AAAA' record. |
| | | | | | |
| | |<<Only 'AAAA' record is resolved.>> |
| | | | | | |
| | |-------->| Request one IPv4 address |
| | | | corresponding to the IPv6 address.
| | | | | | |
| | | |<<Assign one IPv4 address.>> |
| | | | | | |
| | |<--------| Reply with the IPv4 address.
| | | | | | |
| | |<<Create 'A' record for the IPv4 address.>>
| | | | | | |
|<-----|-------| Reply with the 'A' record. | |
| | | | | | |
Figure 4: Action of the originator (1/2)
Huang, et al. Expires August 21, 2010 [Page 11]
Internet-Draft Dual Stack Hosts using BIS February 2010
"dual stack" "host6"
IPv4 TCP/ extension address translator IPv6
appli- IPv4 name mapper
cation resolver
| | | | | | |
<<Send an IPv4 packet to "host6".>>| | |
| | | | | | |
|======|=======|=========|======>| An IPv4 packet. |
| | | | | | |
| | | |<------| Request IPv6 addresses
| | | | | corresponding to the IPv4
| | | | | addresses. |
| | | | | | |
| | | |------>| Reply with the IPv6|
| | | | | addresses. |
| | | | | | |
| | | | |<<Translate IPv4 into IPv6.>>
| | | | | | |
| | |An IPv6 packet. |===========|========>|
| | | | | | |
| | | | <<Reply an IPv6 packet to
| | | | "dual stack".>> |
| | | | | | |
| | |An IPv6 packet. |<==========|=========|
| | | | | | |
| | | | |<<Translate IPv6 into IPv4.>>
| | | | | | |
|<=====|=======|=========|=======| An IPv4 packet. |
| | | | | | |
Figure 5: Action of the originator (2/2)
3.2. Recipient behavior
This subsection describes the recipient behavior of "dual stack."
The communication is triggered by "host6."
"host6" resolves the 'AAAA' record for "dual stack" through its name
server, and then sends an IPv6 packet to the IPv6 address.
The IPv6 packet reaches the translator in "dual stack."
The translator tries to translate the IPv6 packet into an IPv4 packet
but does not know how to translate the IPv6 destination address and
the IPv6 source address. So the translator requests the mapper to
provide mapping entries for them.
The mapper checks its mapping table with each of them and finds a
Huang, et al. Expires August 21, 2010 [Page 12]
Internet-Draft Dual Stack Hosts using BIS February 2010
mapping entry for the IPv6 destination address.
NOTE: The mapper will register its own IPv4 address and IPv6 address
into the table beforehand. See subsection 2.3.
But there is not a mapping entry for the IPv6 source address, so the
mapper selects an IPv4 address out of the pool for it, and then
returns the IPv4 destination address and the IPv4 source address to
the translator.
NOTE: See subsection 6.3 about the influence on other hosts caused by
an IPv4 address assigned here.
The translator translates the IPv6 packet into an IPv4 packet and
tosses it up to the application.
The application sends a new IPv4 packet to "host6."
The following behavior is the same as that described in subsection
3.1.
The following diagram illustrates the action described above:
Huang, et al. Expires August 21, 2010 [Page 13]
Internet-Draft Dual Stack Hosts using BIS February 2010
"dual stack" "host6"
IPv4 TCP/ extension address translator IPv6
appli- IPv4 name mapper
cation resolver
| | | | | | |
<<Receive data from "host6".>> | | |
| | | | | | |
| | |An IPv6 packet. |<==========|=========|
| | | | | | |
| | | |<------| Request IPv4 addresses
| | | | | corresponding to the IPv6
| | | | | addresses. |
| | | | | | |
| | | |------>| Reply with the IPv4|
| | | | | addresses. |
| | | | | | |
| | | | |<<Translate IPv6 into IPv4.>>
| | | | | | |
|<=====|=======|=========|=======| An IPv4 packet. |
| | | | | | |
<<Reply an IPv4 packet to "host6".>> | |
| | | | | | |
|======|=======|=========|======>| An IPv4 packet. |
| | | | | | |
| | | | |<<Translate IPv4 into IPv6.>>
| | | | | | |
| | |An IPv6 packet. |===========|========>|
| | | | | | |
Figure 6: Action of the recipient
Huang, et al. Expires August 21, 2010 [Page 14]
Internet-Draft Dual Stack Hosts using BIS February 2010
4. Action Examples -- IPv6 only network and dual-stack peer
This section describes action of the proposed dual stack host called
"dual stack," which communicates with an dual stack peer called
"host46" using an IPv4 only application while provisioned only with
IPv6 network connectivity.
4.1. Originator behavior
This subsection describes the originator behavior of "dual stack."
The communication is triggered by "dual stack."
The application sends a query to its name server to resolve 'A'
records for "host46."
The resolver snoops the query, then creates another query for 'AAAA'
to resolve both 'A' and 'AAAA' records for the host name, and sends
it to the server. In this case, both the 'A' and 'AAAA' records are
resolved, so the resolver does not need to request the mapper to
allocate any IPv4 addresses from its pool, but only to store mapping
between received destination's IPv4 and IPv6 addresses.
In this case of communication with an dual-stack host, the 'A' record
is also resolved and the resolver can return it to the application as
is.
The application sends an IPv4 packet to "host46."
The IPv4 packet reaches the translator. The translator tries to
translate the IPv4 packet into an IPv6 packet but does not know how
to translate the IPv4 destination address and the IPv4 source
address. So the translator requests the mapper to provide mapping
entries for them.
The mapper checks its mapping table and finds entries for each of
them, and then returns the IPv6 destination address and the IPv6
source address to the translator.
NOTE: The mapper will register its own IPv4 address and IPv6 address
into the table beforehand. See subsection 2.3.
The translator translates the IPv4 packet into an IPv6 packet then
fragments the IPv6 packet if necessary and sends it to an IPv6
network.
The IPv6 packet reaches "host46." Then "host46" sends a new IPv6
packet to "dual stack."
Huang, et al. Expires August 21, 2010 [Page 15]
Internet-Draft Dual Stack Hosts using BIS February 2010
The IPv6 packet reaches the translator in "dual stack."
The translator gets mapping entries for the IPv6 destination address
and the IPv6 source address from the mapper in the same way as
before.
Then the translator translates the IPv6 packet into an IPv4 packet
and tosses it up to the application.
The following diagram illustrates the action described above:
"dual stack" "host46"
IPv4 TCP/ extension address translator IPv6
appli- IPv4 name mapper
cation resolver
| | | | | | |
<<Resolve an IPv4 address for "host46".>> | |
| | | | | | |
|------|----->| Query of 'A' records for "host46". | Name
| | | | | | | Server
| | |---------|-------|-----------|---------|--->|
| | | Query of 'A' records and 'AAAA' for "host46"
| | | | | | | |
| | |<--------|-------|-----------|---------|----|
| | | Reply with 'A' and 'AAAA' records. |
| | | | | | |
| | |<<Both 'AAAA' and 'A' record is resolved.>>
| | | | | | |
| | |-------->|Request mapping of received IPv4 address
| | | |corresponding to the received IPv6 address.
| | | | | | |
|<-----|------| Reply with the 'A' record. | |
| | | | | | |
Figure 7: Action of the originator (1/2)
Huang, et al. Expires August 21, 2010 [Page 16]
Internet-Draft Dual Stack Hosts using BIS February 2010
"dual stack" "host46"
IPv4 TCP/ extension address translator IPv6
appli- IPv4 name mapper
cation resolver
| | | | | | |
<<Send an IPv4 packet to "host46".>>| | |
| | | | | | |
|======|=======|=========|======>| An IPv4 packet. |
| | | | | | |
| | | |<------| Request IPv6 addresses
| | | | | corresponding to the IPv4
| | | | | addresses. |
| | | | | | |
| | | |------>| Reply with the IPv6|
| | | | | addresses. |
| | | | | | |
| | | | |<<Translate IPv4 into IPv6.>>
| | | | | | |
| | |An IPv6 packet. |===========|========>|
| | | | | | |
| | | | <<Reply an IPv6 packet to
| | | | "dual stack".>> |
| | | | | | |
| | |An IPv6 packet. |<==========|=========|
| | | | | | |
| | | | |<<Translate IPv6 into IPv4.>>
| | | | | | |
|<=====|=======|=========|=======| An IPv4 packet. |
| | | | | | |
Figure 8: Action of the originator (2/2)
4.2. Recipient behavior
The recipient behaviour is exactly the same as in 3.2.
Huang, et al. Expires August 21, 2010 [Page 17]
Internet-Draft Dual Stack Hosts using BIS February 2010
5. Action Examples -- IPv4 only network and IPv4 only peer
This section describes action of the proposed dual stack host called
"dual stack," which communicates with an IPv4 peer called "host4"
using an IPv6 application.
5.1. Originator behavior
This subsection describes the originator behavior of "dual stack."
The communication is triggered by "dual stack."
The application sends a query to its name server to resolve 'AAAA'
records for "host4."
The resolver snoops the query, then creates another query for 'A' to
resolve both 'A' and 'AAAA' records for the host name, and sends it
to the server. In this case, only the 'A' record is resolved, so the
resolver requests the mapper to assign an IPv6 address corresponding
to the IPv4 address.
NOTE: In the case of communication with a dual-stack host, the 'AAAA'
record is also resolved and then the resolver returns it to the
application as is. The mapper will create mapping between the IPv4
and IPv6 addresses similarly as in in 4.1.
The mapper concatenates IPv6 WKP with the resolved IPv4 address and
returns it to the resolver.
The resolver creates the 'AAAA' record for the assigned IPv6 address
and returns it to the application.
NOTE: See subsection 6.3 about the influence on other hosts caused by
an IPv6 address assigned here.
The application sends an IPv6 packet to "host4."
The IPv6 packet reaches the translator. The translator tries to
translate the IPv6 packet into an IPv4 packet but does not know how
to translate the IPv6 destination address and the IPv6 source
address. So the translator requests the mapper to provide mapping
entries for them.
The mapper checks its mapping table and finds entries for each of
them, and then returns the IPv4 destination address and the IPv4
source address to the translator.
NOTE: The mapper will register its own IPv4 address and IPv6 address
into the table beforehand. See subsection 2.3.
Huang, et al. Expires August 21, 2010 [Page 18]
Internet-Draft Dual Stack Hosts using BIS February 2010
The translator translates the IPv6 packet into an IPv4 packet and
sends it to an IPv4 network.
The IPv4 packet reaches "host4." Then "host4" sends a new IPv4
packet to "dual stack."
The IPv4 packet reaches the translator in "dual stack."
The translator gets mapping entries for the IPv4 destination address
and the IPv4 source address from the mapper in the same way as
before.
Then the translator translates the IPv4 packet into an IPv6 packet
and tosses it up to the application.
The following diagram illustrates the action described above:
"dual stack" "host4"
IPv6 TCP/ extension address translator IPv4
appli- IPv6 name mapper
cation resolver
| | | | | | |
<<Resolve an IPv6 address for "host4".>> | |
| | | | | | |
|------|------>| Query of 'AAAA' records for "host4". | Name
| | | | | | | Server
| | |---------|-------|-----------|---------|--->|
| | | Query of 'A' records and 'AAAA' for "host4"
| | | | | | | |
| | |<--------|-------|-----------|---------|----|
| | | Reply only with 'A' record. |
| | | | | | |
| | |<<Only 'A' record is resolved.>> |
| | | | | | |
| | |-------->| Request one IPv6 address |
| | | | corresponding to the IPv4 address.
| | | | | | |
| | | |<<Assign one IPv6 address.>> |
| | | | | | |
| | |<--------| Reply with the IPv6 address.
| | | | | | |
| | |<<Create 'AAAA' record for the IPv6 address.>>
| | | | | | |
|<-----|-------|Reply with the 'AAAAA' record| |
| | | | | | |
Figure 9: Action of the originator (1/2)
Huang, et al. Expires August 21, 2010 [Page 19]
Internet-Draft Dual Stack Hosts using BIS February 2010
"dual stack" "host4"
IPv6 TCP/ extension address translator IPv4
appli- IPv6 name mapper
cation resolver
| | | | | | |
<<Send an IPv6 packet to "host4".>>| | |
| | | | | | |
|======|=======|=========|======>| An IPv6 packet. |
| | | | | | |
| | | |<------| Request IPv4 addresses
| | | | | corresponding to the IPv6
| | | | | addresses. |
| | | | | | |
| | | |------>| Reply with the IPv4|
| | | | | addresses. |
| | | | | | |
| | | | |<<Translate IPv6 into IPv4.>>
| | | | | | |
| | |An IPv4 packet. |===========|========>|
| | | | | | |
| | | | <<Reply an IPv4 packet to
| | | | "dual stack".>> |
| | | | | | |
| | |An IPv4 packet. |<==========|=========|
| | | | | | |
| | | | |<<Translate IPv4 into IPv.>>
| | | | | | |
|<=====|=======|=========|=======| An IPv6 packet. |
| | | | | | |
Figure 10: Action of the originator (2/2)
5.2. Recipient behavior
This subsection describes the recipient behavior of "dual stack."
The communication is triggered by "host4."
"host4" resolves the 'A' record for "dual stack" through its name
server, and then sends an IPv4 packet to the IPv4 address.
The IPv4 packet reaches the translator in "dual stack."
The translator tries to translate the IPv4 packet into an IPv6 packet
but does not know how to translate the IPv4 destination address and
the IPv4 source address. So the translator requests the mapper to
provide mapping entries for them.
The mapper checks its mapping table with each of them and finds a
Huang, et al. Expires August 21, 2010 [Page 20]
Internet-Draft Dual Stack Hosts using BIS February 2010
mapping entry for the IPv4 destination address.
NOTE: The mapper will register its own IPv4 address and IPv6 address
into the table beforehand. See subsection 2.3.
But there is not a mapping entry for the IPv4 source address, so the
mapper concatenates IPv6 WKP with the IPv4 source address and then
returns the IPv6 destination address and the IPv6 source address to
the translator.
NOTE: See subsection 6.3 about the influence on other hosts caused by
an IPv6 address assigned here.
The translator translates the IPv4 packet into an IPv6 packet and
tosses it up to the application.
The application sends a new IPv6 packet to "host4."
The following behavior is similar as described in subsection 3.1.
The following diagram illustrates the action described above:
Huang, et al. Expires August 21, 2010 [Page 21]
Internet-Draft Dual Stack Hosts using BIS February 2010
"dual stack" "host4"
IPv6 TCP/ extension address translator IPv4
appli- IPv6 name mapper
cation resolver
| | | | | | |
<<Receive data from "host4".>> | | |
| | | | | | |
| | |An IPv4 packet. |<==========|=========|
| | | | | | |
| | | |<------| Request IPv6 addresses
| | | | | corresponding to the IPv4
| | | | | addresses. |
| | | | | | |
| | | |------>| Reply with the IPv6|
| | | | | addresses. |
| | | | | | |
| | | | |<<Translate IPv4 into IPv6.>>
| | | | | | |
|<=====|=======|=========|=======| An IPv6 packet. |
| | | | | | |
<<Reply an IPv6 packet to "host4".>> | |
| | | | | | |
|======|=======|=========|======>| An IPv6 packet. |
| | | | | | |
| | | | |<<Translate IPv6 into IPv4.>>
| | | | | | |
| | |An IPv4 packet. |===========|========>|
| | | | | | |
Figure 11: Action of the recipient
Huang, et al. Expires August 21, 2010 [Page 22]
Internet-Draft Dual Stack Hosts using BIS February 2010
6. Considerations
This section considers some issues of the proposed dual stack hosts.
6.1. IP conversion
In common with NAT, IP protocol translation has to translate IP
addresses embedded in application layer protocols, such as FTP.
Translation of all such applications is a difficult problem.
6.2. IPv4 or IPv6 Address Pool and Mapping Table
The address pool consists of the unassigned IPv4 addresses or
internal IPv6 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 or IPv6 applications
to communicate with IPv4 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.
6.3. Internally Assigned IPv4 or IPv6 Addresses
The IPv4 addresses, which are internally assigned to IPv6 target
hosts out of the pool, are the unassigned IPv4 addresses (e.g.,
0.0.0.1 ~ 0.255.255.255). There is no potential collision with
another use of the private address space when the IPv4 address flows
out from the host.
The IPv6 addresses, which are internally assigned to IPv4 target
hosts out of the pool, are the special IPv6 addresses (It need IANA's
consideration). There is no potential collision with another use of
thosee address space when the IPv6 address flows out from the host.
Huang, et al. Expires August 21, 2010 [Page 23]
Internet-Draft Dual Stack Hosts using BIS February 2010
7. Applicability and Limitations
This section considers applicability and limitations of the proposed
dual stack hosts.
7.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.
7.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 August 21, 2010 [Page 24]
Internet-Draft Dual Stack Hosts using BIS February 2010
8. ALG related
BIA 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 like [PNAT-ALG].
Huang, et al. Expires August 21, 2010 [Page 25]
Internet-Draft Dual Stack Hosts using BIS February 2010
9. 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.
Huang, et al. Expires August 21, 2010 [Page 26]
Internet-Draft Dual Stack Hosts using BIS February 2010
10. Security Considerations
This section considers security of the proposed dual stack hosts.
The hosts can utilize the security of all layers like ordinary IPv4
communication when they communicate with IPv4 hosts using IPv4
applications via the mechanism. Likewise they can utilize the
security of all layers like ordinary IPv6 communication when they
communicate with IPv6 hosts using IPv6 applications via the complete
IPv6 stack. However, unfortunately, they can not utilize the
security above network layer when they communicate with IPv6 hosts
using IPv4 applications via the mechanism. The reason is that when
the protocol data with which IP addresses are embedded is encrypted,
or when the protocol data is encrypted using IP addresses as keys, it
is impossible for the mechanism to translate the IPv4 data into IPv6
and vice versa. Therefore it is highly desirable to upgrade to the
applications modified into IPv6 for utilizing the security at
communication with IPv6 hosts.
Huang, et al. Expires August 21, 2010 [Page 27]
Internet-Draft Dual Stack Hosts using BIS February 2010
11. Normative References
[ADDRFORMAT]
Huitema, C., "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-00 (work in progress),
Aug 2009.
[DNS64] Bagnulo, M., "DNS64: DNS extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-00 (work in progress), July 2009.
[NAT64] Bagnulo, M., "NAT64: Network Address and Protocol
Translation from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-01 (work in
progress), July. 2009.
[PNAT] Huang, Bill., "Prefix NAT: Host based IPv6 translation",
draft-huang-pnat-host-ipv6-03 (work in progress).
[PNAT-ALG]
Wing, D., "Concerns with IPv4 Applications Accessing IPv6
Servers (NAT46)", draft-wing-behave-v4app-v6server-01
(work in progress), February 2010.
[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 August 21, 2010 [Page 28]
Internet-Draft Dual Stack Hosts using BIS February 2010
Appendix A. Acknowledgements
The authors gratefully acknowledge the many helpful advice from Dan
Wing and Dave Thaler for intiating this work, thanks mailing list
discussion from Mohamed Boucadair, Yiu L. Lee, James Woodyatt,
Lorenzo Colitti, Qibo Niu, Lin Xiao, and Pierrick Seite.
Contributions from Gang Chen, Bo Zhou, Dapeng Liu,Hong Liu, Tao Sun
et al. in the development of this document.
Advice from Dan Wing, Dave Thaler and Magnus Westerlund are greatly
appreciated
Huang, et al. Expires August 21, 2010 [Page 29]
Internet-Draft Dual Stack Hosts using BIS February 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 August 21, 2010 [Page 30]