draft-ietf-behave-v4v6-bih-00.txt   draft-ietf-behave-v4v6-bih-01.txt 
Behave WG B. Huang Behave WG B. Huang
Internet-Draft H. Deng Internet-Draft H. Deng
Obsoletes: 3338, 2767 China Mobile Obsoletes: 3338, 2767 China Mobile
(if approved) T. Savolainen (if approved) T. Savolainen
Intended status: Standards Track Nokia Intended status: Standards Track Nokia
Expires: April 14, 2011 October 11, 2010 Expires: April 22, 2011 October 19, 2010
Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
draft-ietf-behave-v4v6-bih-00 draft-ietf-behave-v4v6-bih-01
Abstract Abstract
This document describes the "Bump-In-the-Host" (BIH), a host based This document describes the "Bump-In-the-Host" (BIH), a host based
protocol translation mechanism that allows a subset of applications IPv4 to IPv6 protocol translation mechanism that allows a subset of
supporting only one IP address family to communicate with peers that applications supporting only IPv4 to communicate with peers that are
are reachable or supporting only the other address family. reachable only with IPv6. A host may be connected to IPv6-only or
dual-stack access network. Essentially BIH makes the IPv4
This specification addresses scenarios where a host is provided dual applications think they talk to IPv4 peers and hence hides the
stack or IPv6 only network connectivity. In the dual stack network existence of IPv6 from those applications.
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. The
BIH makes the IPv4 applications think they talk to IPv4 peers and
hence hides the IPv6 from those applications.
Acknowledgement of previous work Acknowledgement of previous work
This document is an update to and directly derivative from Kazuaki This document is an update to and directly derivative from Kazuaki
TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI [RFC2767] and TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI [RFC2767] and
from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and
Erik Nordmark's [RFC3338], which similarly provides a dual stack host Erik Nordmark's [RFC3338], which similarly provides a dual stack host
means to communicate with other IPv6 host using existing IPv4 means to communicate with other IPv6 host using existing IPv4
appliations. This document combines and updates both [RFC2767] and appliations. This document combines and updates both [RFC2767] and
[RFC3338]. [RFC3338].
skipping to change at page 2, line 22 skipping to change at page 2, line 17
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2011. This Internet-Draft will expire on April 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Components of the Bump-in-the-Host . . . . . . . . . . . . . . 6 2. Components of the Bump-in-the-Host . . . . . . . . . . . . . . 6
2.1. Function Mapper . . . . . . . . . . . . . . . . . . . . . 7 2.1. Function Mapper . . . . . . . . . . . . . . . . . . . . . 7
2.2. Translator . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Translator . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Extension Name Resolver . . . . . . . . . . . . . . . . . 8 2.3. Extension Name Resolver . . . . . . . . . . . . . . . . . 8
2.3.1. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 9 2.3.1. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 9
2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 9
3. Behavior and network Examples . . . . . . . . . . . . . . . . 12 3. Behavior and network Examples . . . . . . . . . . . . . . . . 11
4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 16 4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 15
4.2. ICMP Message Handling . . . . . . . . . . . . . . . . . . 16 4.2. ICMP Message Handling . . . . . . . . . . . . . . . . . . 15
4.3. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 16 4.3. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 15
4.4. Internally Assigned IPv4 Addresses . . . . . . . . . . . . 16 4.4. Multi-interface . . . . . . . . . . . . . . . . . . . . . 16
5. Considerations due ALG requirements . . . . . . . . . . . . . 18 4.5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4.6. DNS cache . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 5. Considerations due ALG requirements . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Implementation option for the ENR . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Implementation option for the ENR . . . . . . . . . . 21
Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
While IPv6 support is being widely introduced throughout the While IPv6 support is being widely introduced throughout the
Internet, classes of applications are going to remain IPv4-only. Internet, classes of applications are going to remain IPv4-only.
This document describes a Bump-in-the-Host (BIH), successor and This document describes a Bump-in-the-Host (BIH), successor and
combination of Bump-in-the-Stack (BIS) [RFC2767] and Bump-in-the-API combination of Bump-in-the-Stack (BIS) [RFC2767] and Bump-in-the-API
(BIA) [RFC3338] technologies, which enables accommodation of (BIA) [RFC3338] technologies, which enables accommodation of
significant set of the legacy IPv4-only applications in the IPv6- significant set of the legacy IPv4-only applications in the IPv6-
world. world.
Bump-In-the-Host is not a general purpose translation solution. The Bump-In-the-Host is not recommended to be used in double translation
class of IPv4-only applications the described host-based NAT46 scenarios if the server is dual-stack enabled. The class of IPv4-
protocol translation solution provides Internet connectivity over only applications the described host-based protocol translation
IPv6-only network access includes those applications that use DNS for solution provides Internet connectivity over IPv6-only network access
IP address resolution and that do not embed IP address literals in includes those applications that use DNS for IP address resolution
protocol payloads. This includes essentially all DNS using legacy and that do not embed IP address literals in protocol payloads. This
client-server model applications, which are agnostic on IP address includes essentially all DNS using legacy client-server model
family used by the destination, but not other classes of applications, which are agnostic on IP address family used by the
applications. The transition towards IPv6-only Internet is made destination, but not other classes of applications. The transition
easier by decreasing number of key applications that must be updated towards IPv6-only Internet is made easier by decreasing number of key
to IPv6. applications that must be updated to IPv6.
BIH technique includes two major implementation options: inserts a BIH technique includes two major implementation options: a protocol
protocol translator between the IPv4 and the IPv6 stacks of a host or translator between the IPv4 and the IPv6 stacks of a host or between
between the socket API module and the TCP/IP module. Essentially, the socket API module and the TCP/IP module. Essentially, IPv4 is
IPv4 is translated into IPv6 at the socket API level or at the IP translated into IPv6 at the socket API level or at the IP level.
level.
When the BIH is implemented at the socket API layer, and IPv4 When the BIH is implemented at the socket API layer, and IPv4
applications communicate with IPv6 peers, the API translator applications communicate with IPv6 peers, the API translator
intercepts the socket API functions from IPv4 applications and intercepts the socket API functions from IPv4 applications and
invokes the IPv6 socket API functions to communicate with the IPv6 invokes the IPv6 socket API functions to communicate with the IPv6
hosts, and vice versa. hosts, and vice versa.
When the BIH is implemented at the networking layer, the IPv4 packets When the BIH is implemented at the networking layer, the IPv4 packets
are intercepted and converted to IPv6 using the IP conversion are intercepted and converted to IPv6 using the IP conversion
mechanism defined in SIIT [I-D.ietf-behave-v6v4-xlate]. The mechanism defined in SIIT [I-D.ietf-behave-v6v4-xlate]. The
translation has the same benefits and drawbacks as SIIT. translation has the same benefits and drawbacks as SIIT.
In order to support communication between IPv4 applications and the In order to support communication between IPv4 applications and the
target IPv6 hosts, pooled IPv4 addresses will be assigned through the target IPv6 peers, pooled IPv4 addresses as defined in section 4.3
extension name resolver. will be assigned through the extension name resolver.
The BIH can be used whenever an IPv4-only application needs to The BIH can be used whenever an IPv4-only application needs to
communicate with an IPv6 peer, independently of the address families communicate with a peer reachable only with IPv6, independently of
supported by the access network. Hence the access network can be the address families supported by the access network. Hence the
IPv6-only or dual-stack capable. access network can be IPv6-only or dual-stack capable.
In the case BIH enabled host has a possibility to choose between
IPv4-only path or path including IPv4 to IPv6 protocol translation,
the host MUST select IPv4-only path. However, lacking IPv4-only path
and on request BIH will attempt protocol translation also in the case
a destination has IPv4 addresses in addition to IPv6.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] . document are to be interpreted as described in [RFC2119] .
This document uses terms defined in [RFC2460] , [RFC2893] , [RFC2767] This document uses terms defined in [RFC2460] , [RFC2893] , [RFC2767]
and [RFC3338]. and [RFC3338].
2. Components of the Bump-in-the-Host 2. Components of the Bump-in-the-Host
skipping to change at page 7, line 13 skipping to change at page 7, line 13
in-the-Stack". in-the-Stack".
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| +-------------------------------------------------------+ | | +-------------------------------------------------------+ |
| | IPv4 applications | | | | IPv4 applications | |
| +-------------------------------------------------------+ | | +-------------------------------------------------------+ |
| +-------------------------------------------------------+ | | +-------------------------------------------------------+ |
| | TCP/IPv4 | | | | TCP/IPv4 | |
| | +---------------------------------------------------+ | | | +---------------------------------------------------+ |
| | | +-----------+ +---------+ +---------------+ | | | | +-----------+ +---------+ +---------------+ |
| | | | extension | | address | | translator | | | | | | Extension | | Address | | Translator | |
| | | | name | | mapper | +---------------+ | | | | | Name | | Mapper | +---------------+ |
| | | | resolver | | | +---------------+ | | | | | Resolver | | | +---------------+ |
| | | | | | | | IPv6 | | | | | | | | | | IPv6 | |
| +---+ +-----------+ +---------+ +---------------+ | | +---+ +-----------+ +---------+ +---------------+ |
| +-------------------------------------------------------+ | | +-------------------------------------------------------+ |
| | Network card drivers | | | | Network card drivers | |
| +-------------------------------------------------------+ | | +-------------------------------------------------------+ |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| Network cards | | Network cards |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
skipping to change at page 8, line 18 skipping to change at page 8, line 18
conversion mechanism defined in SIIT [I-D.ietf-behave-v6v4-xlate]. conversion mechanism defined in SIIT [I-D.ietf-behave-v6v4-xlate].
When receiving IPv4 packets from IPv4 applications, translator When receiving IPv4 packets from IPv4 applications, translator
converts IPv4 packet headers into IPv6 packet headers, then, if converts IPv4 packet headers into IPv6 packet headers, then, if
required, fragments the IPv6 packets (because header length of IPv6 required, fragments the IPv6 packets (because header length of IPv6
is typically 20 bytes larger than that of IPv4), and sends them to is typically 20 bytes larger than that of IPv4), and sends them to
IPv6 networks. When receiving IPv6 packets from the IPv6 networks, IPv6 networks. When receiving IPv6 packets from the IPv6 networks,
translator works symmetrically to the previous case, except that translator works symmetrically to the previous case, except that
there is no need to fragment the packets. there is no need to fragment the packets.
The translator module has to adjust transport protocol checksums when
translating between IPv4 and IPv6. In the IPv6 to IPv4 direction the
translator also has to calculate IPv4 header checksum.
2.3. Extension Name Resolver 2.3. Extension Name Resolver
Extension Name Resolver returns a proper answer in response to the Extension Name Resolver returns a proper answer in response to the
IPv4 or IPv6 application's name resolution request. IPv4 application's name resolution request.
In the case of socket API implementation option, when an IPv4 In the case of socket API implementation option, when an IPv4
application in an IPv6 only network tries to do forward lookup to application in an IPv6 only network tries to do forward lookup to
resolve names via the resolver library (e.g. gethostbyname()), BIH resolve names via the resolver library (e.g. gethostbyname()), BIH
intercept the function call and instead calls the IPv6 equivalent intercept the function call and instead calls the IPv6 equivalent
functions (e.g. getnameinfo()) that will resolve both A and AAAA functions (e.g. getnameinfo()) that will resolve both A and AAAA
records. records.
If only AAAA record is available for the name queried, ENR requests If only AAAA record is available for the name queried, ENR requests
the address mapper to assign an IPv4 address corresponding to the the address mapper to assign a local IPv4 address corresponding to
IPv6 address, creates an A record for the assigned IPv4 address, and the IPv6 address, creates an A record for the assigned IPv4 address,
returns the A record to the IPv4 application. and returns the A record to the IPv4 application.
If both A and AAAA record are available in the IPv6 only network, ENR If both A and AAAA record are available in the IPv6 only network, ENR
does not require address mapper to assign IPv4 address, but instead does not require address mapper to assign IPv4 address, but instead
asks address mapper to store relationship between the A and AAAA asks address mapper to store relationship between the A and AAAA
records, and then directly passes the received A record to the IPv4 records, and then directly passes the received A record to the IPv4
application. application. Note: this is a scenario where a host should use
encapsulation instead to avoid protocol translation taking place at a
host.
If only an A record is available it will be passed unmodified to the
application so that the application learns a record exists for the
destination. However, the application will not be able to use the
address for communications if the host is in IPv6-only access
network. If the application tries to send data to such an IPv4
address destination unreachable/host unreachable error will be
returned, which allows application to behave accordingly.
Application | Network | ENR behaviour Application | Network | ENR behaviour
query | response | query | response |
------------+----------+--------------------- ------------+----------+---------------------
A | A | <return A record> A | A | <return A record>
A | AAAA | <synthesize A record> A | AAAA | <synthesize A record>
A | A/AAAA | <return A record> A | A/AAAA | <return A record>
Figure 3: ENR behaviour illustration Figure 3: ENR behaviour illustration
NOTE: An implementation option is to have ENR support in host's NOTE: An implementation option is to have ENR support in host's
(stub) DNS resolver itself as described in [DNS64], in which case (stub) DNS resolver itself as described in [DNS64], in which case
record synthesis is not needed and advanced functions such as DNSSEC record synthesis is not needed and advanced functions such as DNSSEC
are possible. If the ENR is implemented at the network layer, same are possible. If the ENR is implemented at the network layer, same
limitations arise as when DNS record synthesis is done on the limitations arise as when DNS record synthesis is done on the
network. A host also has an option to implement recursive DNS server network. A host also has an option to implement recursive DNS server
function. function.
2.3.1. Reverse DNS lookup 2.3.1. Reverse DNS lookup
When an application initiates a reverse DNS query for a PTR record, When an application initiates a reverse DNS query for a PTR record
to find a name for an IP address, the ENR MUST check whether the (in-addr.arpa), to find a name for an IP address, the ENR MUST check
queried IP address can be found in the cache of the Address Mapper whether the queried IP address can be found in the Address Mapper's
and is a local IP address. If an entry is found and queried address mapping table and is a local IP address. If an entry is found and
is locally generated, the ENR must initiate corresponding reverse DNS the queried address is locally generated, the ENR must initiate
query for the real IP address. corresponding reverse DNS query for the real IPv6 address (ip6.arpa).
In the case application requested reverse lookup for an address not
part of the local IPv4 address pool, e.g. a global address, the
request shall be forwarded unmodified to the network.
For example, when application initiates reverse DNS query for a For example, when an application initiates reverse DNS query for a
synthesized locally valid IPv4 address, the ENR needs to intercept synthesized locally valid IPv4 address, the ENR needs to intercept
that query. The ENR shall perform reverse query procedure for the that query. The ENR will ask the address mapper for the IPv6 address
destination's IPv6 address and return the name received as response that corresponds to the IPv4 address. The ENR shall perform reverse
to IPv6 reverse query to application that initiated the IPv4 query. lookup procedure for the destination's IPv6 address and return the
name received as a response to the application that initiated the
IPv4 query.
2.4. Address Mapper 2.4. Address Mapper
Address mapper ("the mapper" later on), maintains an IPv4 address Address mapper ("the mapper" later on), maintains a local IPv4
pool in the case of dual stack network and IPv6 only network. The address pool in the case of dual stack network and IPv6 only network.
pool consists of private IPv4 addresses as per [RFC1918]. Also, The pool consists of private IPv4 addresses as per section 4.3.
mapper maintains a table consisting of pairs of these locally Also, mapper maintains a table consisting of pairs of locally
selected IPv4 addresses and destinationss' IPv6 addresses. selected IPv4 addresses and destinationss' IPv6 addresses.
When the extension name resolver, translator, or the function mapper When the extension name resolver, translator, or the function mapper
requests mapper to assign an IPv4 address corresponding to an IPv6 requests mapper to assign an IPv4 address corresponding to an IPv6
address, mapper selects and returns an IPv4 address out of the pool, address, mapper selects and returns an IPv4 address out of the local
and registers a new entry into the table dynamically. The pool, and registers a new entry into the table. The registration
registration occurs in the following 3 cases: occurs in the following 3 cases:
(1) When the extension name resolver gets only an 'AAAA' record for (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 the target host name in the dual stack or IPv6 only network and there
is not a mapping entry for the IPv6 address. is no existing mapping entry for the IPv6 address. A local IPv4
address will be returned to application and mapping for local IPv4
address to real IPv6 address is created.
(2) When the extension name resolver gets both an 'A' record and an (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 'AAAA' record for the target host name in the IPv6 only network and
there is not a mapping entry for the IPv6 address. But ENR does not there is no existing apping entry for the IPv6 address. In this case
need an IPv4 address out of the pool, just to register both IPv4 and local IPv4 address does not need to be selected, but mapping entry
IPv6 addresses from 'A' and 'AAAA' records into a new entry into the has to be created between IPv4 and IPv6 addresses from 'A' and 'AAAA'
table. records. The IPv4 address will be returned to an application. Note:
this is a scenario where IPv4 communications, native or encapsulated,
(3) When the function mapper gets a socket API function call from the are preferred over translation.
data received and there is not a mapping entry for the IPv6 source
address.
When the resolver, translator, 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
possible 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| < out of scope >
(5) local IPv4 |IPv6 or DS | v6 | local IPv4 -> real IPv6
(6) local IPv6 |IPv4 or DS | v4 | < out of scope >
(7) real IPv4 |IPv6 | v4 | < out of scope >
(8) real IPv6 |IPv4 | v6 | < out of scope >
Figure 4: 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) The scenario where the resolver gets both 'A' and 'AAAA' replies
for application's 'AAAA' query on IPv4-only access is out of scope.
(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) The scenario where the resolver gets only an 'A' record for the
target host name for application's 'AAAA' request on IPv4 only or DS
access network is out of scope.
(7) The scenario where the resolver gets only an 'A' record for the (3) When the function mapper gets a socket API function call
target host name for application's 'A' request on IPv6 only access triggered by received IPv6 packet and there is no existing mapping
network is out of scope. entry for the IPv6 source address (Editor's note: can this ever
happen in case of client-server nature of BIH?).
(8) The scenario where the resolver gets only an 'AAAA' record for Other possible combinations are outside of BIH and BIH is not
the target host name for application's 'AAAA' request on IPv4 only involved in those.
access network is out of scope.
NOTE: There is only one exception. When initializing the table, NOTE: There is one exception. When initializing the table the mapper
mapper registers a pair of its own IPv4 address and IPv6 address into registers a pair of its own IPv4 address and IPv6 address into the
the table statically. table.
3. Behavior and network Examples 3. Behavior and network Examples
Figure 5 illustrates the very basic network scenario. An IPv4-only Figure 4 illustrates the very basic network scenario. An IPv4-only
application is running on a host attached to IPv6-only Internet and application is running on a host attached to IPv6-only Internet and
is talking to IPv6 enabled server. A communication is made possible is talking to IPv6 enabled server. A communication is made possible
by bump in the host. by bump in the host.
It is worth noting that while the IPv6 server may additionally have
IPv4 addresses, those are unreachable for the host not having any
direct IPv4 connectivity, and hence can be considered irrelevant.
+----+ +-------------+ +----+ +-------------+
| H1 |----------- IPv6 Internet -------- | IPv6 server | | H1 |----------- IPv6 Internet -------- | IPv6 server |
+----+ +-------------+ +----+ +-------------+
v4 only v4 only
application application
Figure 5: Network Scenario #1 Figure 4: Network Scenario #1
Figure 6 illustrates a possible network scenario where an IPv4-only Figure 5 illustrates a possible network scenario where an IPv4-only
application is running on a host attached to a dual-stack network, application is running on a host attached to a dual-stack network,
but the destination server is running on a private site that is but the destination server is running on a private site that is
numbered with public IPv6 addresses and private IPv4 addresses numbered with public IPv6 addresses and private IPv4 addresses
without port forwarding setup on NAT44. The only means to contact to without port forwarding setup on NAT44. The only means to contact to
server is to use IPv6. server is to use IPv6.
+----------------------+ +------------------------------+ +----------------------+ +------------------------------+
| Dual Stack Internet | | IPv4 Private site (Net 10) | | Dual Stack Internet | | IPv4 Private site (Net 10) |
| | | | | | | |
| | | +----------+ | | | | +----------+ |
skipping to change at page 12, line 42 skipping to change at page 11, line 46
| +----+ +---------+ | | | | +----+ +---------+ | | |
| | H1 |-------- | NAT44 |-------------| Server | | | | H1 |-------- | NAT44 |-------------| Server | |
| +----+ +---------+ | | | | +----+ +---------+ | | |
| v4 only | | +----------+ | | v4 only | | +----------+ |
| application | | Dual Stack | | application | | Dual Stack |
| | | etc. 10.1.1.1 | | | | etc. 10.1.1.1 |
| | | AAAA:2009::1 | | | | AAAA:2009::1 |
| | | | | | | |
+----------------------+ +------------------------------+ +----------------------+ +------------------------------+
Figure 6: Network Scenario #2 Figure 5: Network Scenario #2
Illustrations of host behavior in both implementation options are Illustrations of host behavior in both implementation options are
given here. Figure 7 illustrates the setup where BIH is implemented given here. Figure 6 illustrates the setup where BIH is implemented
as a bump in the API, and figure 8 illustrates the setup where BIH is as a bump in the API, and figure 7 illustrates the setup where BIH is
implemented as a bump in the stack. implemented as a bump in the stack.
"dual stack" "host6" "dual stack" "host6"
IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name
appli- API | ENR Address Function| (v6/v4) Server appli- API | ENR Address Function| (v6/v4) Server
cation | Mapper Mapper | cation | Mapper Mapper |
| | | | | | | | | | | | | | | |
<<Resolve an IPv4 address for "host6".>> | | | <<Resolve an IPv4 address for "host6".>> | | |
| | | | | | | | | | | | | | | |
|--------|------->| Query of 'A' records for host6. | | |--------|------->| Query of 'A' records for host6. | |
skipping to change at page 14, line 11 skipping to change at page 13, line 15
| | | | | | | | | | | | | |
| | | |<+++++++| Request IPv4 addresses| | | | |<+++++++| Request IPv4 addresses|
| | | | | corresponding to the | | | | | | corresponding to the |
| | | | | IPv6 addresses. | | | | | | IPv6 addresses. |
| | | | | | | | | | | | | |
| | | |+++++++>| Reply with the IPv4 addresses. | | | |+++++++>| Reply with the IPv4 addresses.
| | | | | | | | | | | | | |
|<=======|========|========|========| An IPv4 Socket function call. |<=======|========|========|========| An IPv4 Socket function call.
| | | | | | | | | | | | | |
Figure 7: Example of BIH as API addition Figure 6: Example of BIH as API addition
"dual stack" "host6" "dual stack" "host6"
IPv4 TCP/ ENR address translator IPv6 IPv4 TCP/ ENR address translator IPv6
appli- IPv4 mapper appli- IPv4 mapper
cation cation
| | | | | | | | | | | | | |
<<Resolve an IPv4 address for "host6".>> | | <<Resolve an IPv4 address for "host6".>> | |
| | | | | | | | | | | | | |
|------|------>| Query of 'A' records for "host6". | Name |------|------>| Query of 'A' records for "host6". | Name
| | | | | | | Server | | | | | | | Server
skipping to change at page 15, line 20 skipping to change at page 14, line 24
| | | | <<Reply an IPv6 packet to | | | | <<Reply an IPv6 packet to
| | | | "dual stack".>> | | | | | "dual stack".>> |
| | | | | | | | | | | | | |
| | |An IPv6 packet. |<==========|=========| | | |An IPv6 packet. |<==========|=========|
| | | | | | | | | | | | | |
| | | | |<<Translate IPv6 into IPv4.>> | | | | |<<Translate IPv6 into IPv4.>>
| | | | | | | | | | | | | |
|<=====|=======|=========|=======| An IPv4 packet. | |<=====|=======|=========|=======| An IPv4 packet. |
| | | | | | | | | | | | | |
Figure 8: Example of BIH at network layer Figure 7: Example of BIH at network layer
4. Considerations 4. Considerations
4.1. Socket API Conversion 4.1. Socket API Conversion
IPv4 socket API functions are translated into semantically as same IPv4 socket API functions are translated into semantically as same
IPv6 socket API functions as possible and vice versa. See Appendix B IPv6 socket API functions as possible and vice versa. See Appendix B
for the API list intercepted by BIH. However, IPv4 socket API for the API list intercepted by BIH. However, IPv4 socket API
functions are not fully compatible with IPv6 since the IPv6 has new functions are not fully compatible with IPv6 since the IPv6 has new
advanced features. advanced features.
skipping to change at page 16, line 40 skipping to change at page 15, line 40
spaces may be exhausted. As a result, it will be impossible for IPv4 spaces may be exhausted. As a result, it will be impossible for IPv4
applications to communicate with IPv6 nodes. It requires smart applications to communicate with IPv6 nodes. It requires smart
management techniques for address pool. For example, it is desirable management techniques for address pool. For example, it is desirable
for the mapper to free the oldest entry and reuse the IPv4 address or for the mapper to free the oldest entry and reuse the IPv4 address or
IPv6 address for creating a new entry. In case of a per-node address IPv6 address for creating a new entry. In case of a per-node address
mapping table, it MAY cause a larger risk of running out of address. mapping table, it MAY cause a larger risk of running out of address.
The RFC1918 address space was chosen because generally legacy The RFC1918 address space was chosen because generally legacy
applications understand that as a private address space. A new applications understand that as a private address space. A new
dedicated address space would run a risk of not being understood by dedicated address space would run a risk of not being understood by
applications as private. The RFC1918 addresses have a risk of applications as private. 127/8 or 169.254/16 are rejected due
conflicting with other interfaces. The conflicts can be mitigated by possible assumptions applications may make when seeing those.
using least commonly used network number of the RFC1918 address space
(TO BE SELECTED) and, if possible, cease using BIH on IPv6-interface
after an IPv4-enabled interface is activated.
4.4. Internally Assigned IPv4 Addresses The RFC1918 addresses have a risk of conflicting with other
interfaces. The conflicts can be mitigated by using least commonly
used network number of the RFC1918 address space. Addresses from
172.16/12 prefix are thought to be less likely to conflict than
addresses from 10/8 or 192.168/16 spaces, hence the used IPv4
addresses are following (Editor's comment: this is first and almost
random proposals):
The IPv4 addresses, which are internally assigned to IPv6 target Source addresses: 172.21.112.0/30. Source address have to be
hosts out of the pool, are the private IPv4 addresses. IPv4 allocated because applications use getsockname() calls and as in the
addresses, which are internally assigned to IPv6 target hosts out of BIS mode an IP address of the IPv4 interface has to be shown. More
the spool, never flow out from the host, and so do not negatively than one address is allocated to allow implementation flexibility,
affect other hosts. e.g. for cases where a host has multiple IPv6 interfaces. The source
addresses are from different subnet than destination addresses to
ensure applications do not do on-link assumptions and do enable NAT
traversal functions.
The internally assigned IPv4 address, which applications see as the Primary destination addresses: 172.21.80.0/20. Address mapper will
source address, MUST be from different subnet than the IPv4 addresses select destination addresses primarily out of this pool.
used by the address synthesis function. This approach ensures legacy
applications realize they are not on the same link with their Secondary destination addresses: 10.170.160.0/20. Address mapper
destination node and if needed, will trigger NAT traversal procedures will select destination addresses out of this pool if the node has
such as keep-alive message sending. dual-stack connection conflicting with primary destination addresses.
4.4. Multi-interface
In the case of dual-stack destinations BIH must do protocol
translation from IPv4 to IPv6 only when the host does not have any
IPv4 interfaces, native or tunneled, available for use.
It is possible that an IPv4 interface is activated during BIH
operation, for example if a node moves to a coverage area of IPv4
enabled network. In such an event BIH must stop initiating protocol
translation sessions for new connections and BIH may disconnect
active sessions. The choice of disconnection is left for
implementatations and it may depend on whether IPv4 address conflict
situation occurs between addresses used by BIH and addresses used by
new IPv4 interface.
4.5. Multicast
Protocol translation for multicast is not supported.
4.6. DNS cache
When BIH module shuts down, e.g. due IPv4 interface becoming
available, BIH must flush node's DNS cache of possible locally
generated entries.
5. Considerations due ALG requirements 5. Considerations due ALG requirements
No ALG functionality is specified herein as ALG design is generally No ALG functionality is specified herein as ALG design is generally
not encouraged for host based translation and as BIH is intended for not encouraged for host based translation and as BIH is intended for
applications not including IP addresses in protocol payloads. applications not including IP addresses in protocol payloads.
6. Security Considerations 6. Security Considerations
The security consideration of BIH mostly relies on that of The security consideration of BIH mostly relies on that of
skipping to change at page 20, line 13 skipping to change at page 19, line 13
techniques as NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] does. techniques as NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] does.
7. Acknowledgments 7. Acknowledgments
The author thanks the discussion from Gang Chen, Dapeng Liu, Bo Zhou, 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 Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of
this document. this document.
The efforts of Suresh Krishnan, Mohamed Boucadair, Yiu L. Lee, James The efforts of Suresh Krishnan, Mohamed Boucadair, Yiu L. Lee, James
Woodyatt, Lorenzo Colitti, Qibo Niu, Pierrick Seite, Dean Cheng, Woodyatt, Lorenzo Colitti, Qibo Niu, Pierrick Seite, Dean Cheng,
Christian Vogt, Jan M. Melen, in reviewing this document are Christian Vogt, Jan M. Melen, and Ed Jankiewizh in reviewing this
gratefully acknowledged. document are gratefully acknowledged.
Advice from Dan Wing, Dave Thaler and Magnus Westerlund are greatly Advice from Dan Wing, Dave Thaler and Magnus Westerlund are greatly
appreciated appreciated
The authors of RFC2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO, The authors of RFC2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO,
Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO. Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO.
The authors of RFC3338 acknowledged implementation contributions by The authors of RFC3338 acknowledged implementation contributions by
Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation
(www.i2soft.net). (www.i2soft.net).
The authors of Bump-in-the-Wire (draft-ietf-biw-00.txt, October
2006), P. Moster, L. Chin, and D. Green, are acknowledged. Few ideas
and clarifications from BIW have been adapted to this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in
progress), September 2010. progress), September 2010.
[I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate-stateful]
skipping to change at page 24, line 21 skipping to change at page 23, line 21
IPv4 new IPv6 IPv4 new IPv6
------------------------------------------------ ------------------------------------------------
AF_INET AF_INET6 AF_INET AF_INET6
sockaddr_in sockaddr_in6 sockaddr_in sockaddr_in6
gethostbyname() getaddrinfo() gethostbyname() getaddrinfo()
gethostbyaddr() getnameinfo() gethostbyaddr() getnameinfo()
inet_ntoa()/inet_addr() inet_pton()/inet_ntop() inet_ntoa()/inet_addr() inet_pton()/inet_ntop()
INADDR_ANY in6addr_any INADDR_ANY in6addr_any
Figure 9 Figure 8
BIH MAY intercept inet_ntoa() and inet_addr() and use the address BIH MAY intercept inet_ntoa() and inet_addr() and use the address
mapper for those. Doing that enables BIH to support literal IP mapper for those. Doing that enables BIH to support literal IP
addresses. addresses.
The gethostbyname() call return a list of addresses. When the name The gethostbyname() call return a list of addresses. When the name
resolver function invokes getaddrinfo() and getaddrinfo() returns resolver function invokes getaddrinfo() and getaddrinfo() returns
multiple IP addresses, whether IPv4 or IPv6, they SHOULD all be multiple IP addresses, whether IPv4 or IPv6, they SHOULD all be
represented in the addresses returned by gethostbyname(). Thus if represented in the addresses returned by gethostbyname(). Thus if
getaddrinfo() returns multiple IPv6 addresses, this implies that getaddrinfo() returns multiple IPv6 addresses, this implies that
 End of changes. 39 change blocks. 
169 lines changed or deleted 181 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/