draft-ietf-behave-v4v6-bih-01.txt   draft-ietf-behave-v4v6-bih-02.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 22, 2011 October 19, 2010 Expires: July 27, 2011 January 23, 2011
Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
draft-ietf-behave-v4v6-bih-01 draft-ietf-behave-v4v6-bih-02
Abstract Abstract
This document describes the "Bump-In-the-Host" (BIH), a host based Bump-In-the-Host (BIH) is a host based IPv4 to IPv6 protocol
IPv4 to IPv6 protocol translation mechanism that allows a subset of translation mechanism that allows class of IPv4-only applications
applications supporting only IPv4 to communicate with peers that are that work through NATs to communicate with IPv6-only peers. The host
reachable only with IPv6. A host may be connected to IPv6-only or applications are running on may be connected to IPv6-only or dual-
dual-stack access network. Essentially BIH makes the IPv4 stack access networks. BIH hides IPv6 and makes the IPv4-only
applications think they talk to IPv4 peers and hence hides the applications think they are talking with IPv4 peers by local
existence of IPv6 from those applications. synthetization of A records.
Acknowledgement of previous work
This document is an update to and directly derivative from Kazuaki
TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI [RFC2767] and
from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and
Erik Nordmark's [RFC3338], which similarly provides a dual stack host
means to communicate with other IPv6 host using existing IPv4
appliations. This document combines and updates both [RFC2767] and
[RFC3338].
The changes in this document reflect five components
1. Supporting IPv6 only network connections
2. IPv4 address pool use private address instead of the
unassigned IPv4 addresses (0.0.0.1 - 0.0.0.255)
3. Extending ENR and address mapper to operate differently
4. Adding an alternative way to implement the ENR
5. Going for standards track instead of experimental/
informational
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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
skipping to change at page 2, line 17 skipping to change at page 1, line 38
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 22, 2011. This Internet-Draft will expire on July 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acknowledgement of previous work . . . . . . . . . . . . . 5
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. Special exclusion sets for A and AAAA records . . . . 9
2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2. DNSSEC support . . . . . . . . . . . . . . . . . . . . 9
2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 9
2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 10
3. Behavior and network Examples . . . . . . . . . . . . . . . . 11 3. Behavior and network Examples . . . . . . . . . . . . . . . . 11
4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 15 4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 15
4.2. ICMP Message Handling . . . . . . . . . . . . . . . . . . 15 4.2. ICMP Message Handling . . . . . . . . . . . . . . . . . . 15
4.3. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 15 4.3. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 15
4.4. Multi-interface . . . . . . . . . . . . . . . . . . . . . 16 4.4. Multi-interface . . . . . . . . . . . . . . . . . . . . . 16
4.5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 16 4.5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6. DNS cache . . . . . . . . . . . . . . . . . . . . . . . . 16 4.6. DNS cache . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Considerations due ALG requirements . . . . . . . . . . . . . 17 5. Considerations due ALG requirements . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Implementation option for the ENR . . . . . . . . . . 21 Appendix A. Implementation option for the ENR . . . . . . . . . . 21
Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 22 Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
While IPv6 support is being widely introduced throughout the
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 IPv4-only legacy
significant set of the legacy IPv4-only applications in the IPv6- applications to communicate with IPv6-only servers by synthesizing A
world. records from AAAA records.
Bump-In-the-Host is not recommended to be used in double translation The supported class of applications includes those that use DNS for
scenarios if the server is dual-stack enabled. The class of IPv4- IP address resolution and that do not embed IP address literals in
only applications the described host-based protocol translation protocol payloads. This essentially includes legacy client-server
solution provides Internet connectivity over IPv6-only network access applications using the DNS that are agnostic to the IP address family
includes those applications that use DNS for IP address resolution used by the destination and that are able to do NAT traversal. The
and that do not embed IP address literals in protocol payloads. This synthetic IPv4 addresses shown to applications are taken from RFC1918
includes essentially all DNS using legacy client-server model private address pool in order to ensure possible NAT traversal
applications, which are agnostic on IP address family used by the techniques will be initiated.
destination, but not other classes of applications. The transition
towards IPv6-only Internet is made easier by decreasing number of key IETF recommends using dual-stack or tunneling based solutions for
applications that must be updated to IPv6. IPv6 transition and specifically recommends against deployments
utilizing double protocol translation. Use of BIH together with a
network-side IP translation is NOT RECOMMENDED as a competing
technology for tunneling based transition solutions.
BIH technique includes two major implementation options: a protocol BIH technique includes two major implementation options: a protocol
translator between the IPv4 and the IPv6 stacks of a host or between translator between the IPv4 and the IPv6 stacks of a host or API
the socket API module and the TCP/IP module. Essentially, IPv4 is translator between the IPv4 socket API module and the TCP/IP module.
translated into IPv6 at the socket API level or at the IP level. Essentially, IPv4 is translated into IPv6 at the socket API layer or
at the IP layer.
When the BIH is implemented at the socket API layer, and IPv4 When the BIH is implemented at the socket API layer the translator
applications communicate with IPv6 peers, the API translator intercepts IPv4 socket API function calls and invokes corresponding
intercepts the socket API functions from IPv4 applications and IPv6 socket API function calls to communicate with the IPv6 hosts.
invokes the IPv6 socket API functions to communicate with the IPv6
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 protocol
translation has the same benefits and drawbacks as SIIT. layer translation has the same benefits and drawbacks as SIIT.
In order to support communication between IPv4 applications and the
target IPv6 peers, pooled IPv4 addresses as defined in section 4.3
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 a peer reachable only with IPv6, independently of communicate with an IPv6-only server, independently of the address
the address families supported by the access network. Hence the families supported by the access network. Hence the access network
access network can be IPv6-only or dual-stack capable. 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].
1.1. Acknowledgement of previous work
This document is direct update to and directly derivative from
Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI
[RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain
Durand, and Erik Nordmark's [RFC3338], which similarly provides a
dual stack host means to communicate with other IPv6 host using
existing IPv4 appliations.
This document combines and updates both [RFC2767] and [RFC3338]
The changes in this document mainly reflect following components
1. Supporting IPv6 only network connections
2. IPv4 address pool use private address instead of the
unassigned IPv4 addresses (0.0.0.1 - 0.0.0.255)
3. Extending ENR and address mapper to operate differently
4. Adding an alternative way to implement the ENR
5. Going for standards track instead of experimental/
informational
6. Supporting reverse (PTR) queries
2. Components of the Bump-in-the-Host 2. Components of the Bump-in-the-Host
Figure 1 shows the architecture of the host in which BIH is Figure 1 shows the architecture of the host in which BIH is
implemented as socket API layer translator, i.e. as the original implemented as socket API layer translator, i.e. as the original
"Bump-in-the-API". "Bump-in-the-API".
+----------------------------------------------+ +----------------------------------------------+
| +------------------------------------------+ | | +------------------------------------------+ |
| | | | | | | |
| | IPv4 applications | | | | IPv4 applications | |
skipping to change at page 7, line 32 skipping to change at page 7, line 32
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| Network cards | | Network cards |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
Figure 2: Architecture of the dual-stack host using BIH at network Figure 2: Architecture of the dual-stack host using BIH at network
layer layer
Dual stack hosts defined in RFC2893 [RFC2893] need applications, Dual stack hosts defined in RFC2893 [RFC2893] need applications,
TCP/IP modules and addresses for both IPv4 and IPv6. The proposed TCP/IP modules and addresses for both IPv4 and IPv6. The proposed
hosts in this document have an API or network layer translator to hosts in this document have an API or network layer translator to
communicate with other IPv6 hosts using existing IPv4 applications. communicate with IPv6-only peers using existing IPv4 applications.
The BIH translator consists of an extension name resolver, an address The BIH translator consists of an Extension Name Resolver, an Address
mapper, and depending on implementation either a function mapper or a Mapper, and depending on implementation either a Function Mapper or a
protocol translator. Protocol Translator.
2.1. Function Mapper 2.1. Function Mapper
Function mapper translates an IPv4 socket API function into an IPv6 Function mapper translates an IPv4 socket API function into an IPv6
socket API function, and vice versa. socket API function, and vice versa.
When detecting IPv4 socket API function calls from IPv4 applications, When detecting IPv4 socket API function calls from IPv4 applications,
function mapper intercepts the function calls and invokes new IPv6 function mapper intercepts the function calls and invokes IPv6 socket
socket API functions which correspond to the IPv4 socket API API functions which correspond to the IPv4 socket API functions. The
functions. Those IPv6 API functions are used to communicate with the IPv6 API functions are used to communicate with the target IPv6
target IPv6 peers. When detecting IPv6 socket API function calls peers. When detecting IPv6 socket API function calls triggered by
triggered by the data received from the IPv6 peers, function mapper the data received from the IPv6 peers, function mapper works
works symmetrically in relation to the previous case. symmetrically in relation to the previous case.
See Appendix B for list of functions that may be intercepted by the
function mapper.
2.2. Translator 2.2. Translator
Translator translates IPv4 into IPv6 and vice versa using the IP Translator translates IPv4 into IPv6 and vice versa using the IP
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
skipping to change at page 8, line 27 skipping to change at page 8, line 27
The translator module has to adjust transport protocol checksums when The translator module has to adjust transport protocol checksums when
translating between IPv4 and IPv6. In the IPv6 to IPv4 direction the translating between IPv4 and IPv6. In the IPv6 to IPv4 direction the
translator also has to calculate IPv4 header checksum. 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 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 layer implementation option, when an IPv4
application in an IPv6 only network tries to do forward lookup to application tries to do forward lookup to resolve names via the
resolve names via the resolver library (e.g. gethostbyname()), BIH resolver library (e.g. gethostbyname()), BIH intercept the function
intercept the function call and instead calls the IPv6 equivalent call and instead calls the IPv6 equivalent functions (e.g.
functions (e.g. getnameinfo()) that will resolve both A and AAAA getnameinfo()) that will resolve both A and AAAA records.
records.
If only AAAA record is available for the name queried, ENR requests In the case of stack layer implementation option the ENR intercepts
the address mapper to assign a local IPv4 address corresponding to the A query and creates additional AAAA query with essentially the
the IPv6 address, creates an A record for the assigned IPv4 address, same content. The ENR will then collect replies to both A and AAAA
and returns the A record to the IPv4 application. queries and depending on results either returns A reply unmodified or
drops the real A reply and synthesizes a new A reply.
If both A and AAAA record are available in the IPv6 only network, ENR In either implementation options, if only non-excluded AAAA records
does not require address mapper to assign IPv4 address, but instead are available for the queried name, ENR requests the address mapper
asks address mapper to store relationship between the A and AAAA to assign a local IPv4 address corresponding to the IPv6 address(es).
records, and then directly passes the received A record to the IPv4 In the case of API layer implementation option the ENR will simply
application. Note: this is a scenario where a host should use make API (e.g. gethostbyname) to return the synthetic address. In
encapsulation instead to avoid protocol translation taking place at a the case of network layer implementation option ENR synthesizes an A
host. record for the assigned IPv4 address, and returns the A record to the
IPv4 application.
If only an A record is available it will be passed unmodified to the If there is real, non-excluded, A record available, ENR SHOULD NOT
application so that the application learns a record exists for the synthetize IPv4 addresses to be given to the application. By default
destination. However, the application will not be able to use the ENR implementation MUST NOT synthesize IPv4 addresses when real A
address for communications if the host is in IPv6-only access records exist.
network. If the application tries to send data to such an IPv4
address destination unreachable/host unreachable error will be If the response contains a CNAME or a DNAME record, then the CNAME or
returned, which allows application to behave accordingly. DNAME chains is followed until the first terminating A or AAAA record
is reached.
Application | Network | ENR behaviour Application | Network | ENR behaviour
query | response | query | response |
------------+----------+--------------------- ------------+----------+------------------------
A | A | <return A record> A | A | <return real A record>
A | AAAA | <synthesize A record> A | AAAA | <synthesize A record>
A | A/AAAA | <return A record> A | A/AAAA | <return real A record>
Figure 3: ENR behaviour illustration Figure 3: ENR behaviour illustration
NOTE: An implementation option is to have ENR support in host's 2.3.1. Special exclusion sets for A and AAAA records
(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 at the network layer, same
limitations arise as when DNS record synthesis is done on the
network. A host also has an option to implement recursive DNS server
function.
2.3.1. Reverse DNS lookup ENR implementation MAY by default exclude certain IPv4 and IPv6
addresses seen on received A and AAAA records. The addresses to be
excluded by default SHOULD include martian addresses such as those
that should not appear in the DNS or on the wire. Additional
addresses MAY be excluded based on possibly configurable local
policies.
2.3.2. DNSSEC support
The A record synthesis done by ENR in the network layer model can
cause problems for DNSSEC validation possibly done by the host's
resolver, as the synthetic responses cannot be succesfully validated.
DNSSEC can be supported by configuring the (stub) resolver on a host
to trust validations done by the local ENR or alternatively the
validating resolver can implement ENR on itself and only SIIT takes
place at network layer.
When ENR is implemented at the socket API level there is no problems
with DNSSEC, as the ENR itself uses socket APIs.
2.3.3. 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
(in-addr.arpa), to find a name for an IP address, the ENR MUST check (in-addr.arpa), to find a name for an IP address, the ENR MUST check
whether the queried IP address can be found in the Address Mapper's whether the queried IP address can be found in the Address Mapper's
mapping table and is a local IP address. If an entry is found and mapping table and is a local IP address. If an entry is found and
the queried address is locally generated, the ENR must initiate the queried address is locally generated, the ENR must initiate
corresponding reverse DNS query for the real IPv6 address (ip6.arpa). corresponding reverse DNS query for the real IPv6 address (ip6.arpa).
In the case application requested reverse lookup for an address not In the case application requested reverse lookup for an address not
part of the local IPv4 address pool, e.g. a global address, the part of the local IPv4 address pool, e.g. a global address, the
request shall be forwarded unmodified to the network. request shall be forwarded unmodified to the network.
skipping to change at page 9, line 45 skipping to change at page 10, line 13
For example, when an 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 will ask the address mapper for the IPv6 address that query. The ENR will ask the address mapper for the IPv6 address
that corresponds to the IPv4 address. The ENR shall perform reverse that corresponds to the IPv4 address. The ENR shall perform reverse
lookup procedure for the destination's IPv6 address and return the lookup procedure for the destination's IPv6 address and return the
name received as a response to the application that initiated the name received as a response to the application that initiated the
IPv4 query. IPv4 query.
2.4. Address Mapper 2.4. Address Mapper
Address mapper ("the mapper" later on), maintains a local IPv4 Address mapper maintains a local IPv4 address pool. The pool
address pool in the case of dual stack network and IPv6 only network. consists of private IPv4 addresses as per section 4.3. Also, the
The pool consists of private IPv4 addresses as per section 4.3. address mapper maintains a table consisting of pairs of locally
Also, mapper maintains a table consisting of pairs of locally selected IPv4 addresses and destinations' 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 the address mapper to assign an IPv4 address corresponding
address, mapper selects and returns an IPv4 address out of the local to an IPv6 address, the address mapper selects and returns an IPv4
pool, and registers a new entry into the table. The registration address out of the local pool, and registers a new entry into the
occurs in the following 3 cases: table. The registration 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
the target host name in the dual stack or IPv6 only network and there target host name in the dual stack or IPv6 only network and there is
is no existing mapping entry for the IPv6 address. A local IPv4 no existing mapping entry for the IPv6 address. A local IPv4 address
address will be returned to application and mapping for local IPv4 will be returned to application and mapping for local IPv4 address to
address to real IPv6 address is created. 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, but the A record contains only excluded IPv4 addresses.
there is no existing apping entry for the IPv6 address. In this case Behavior will follow the case (1).
local IPv4 address does not need to be selected, but mapping entry
has to be created between IPv4 and IPv6 addresses from 'A' and 'AAAA'
records. The IPv4 address will be returned to an application. Note:
this is a scenario where IPv4 communications, native or encapsulated,
are preferred over translation.
(3) When the function mapper gets a socket API function call (3) When the function mapper gets a socket API function call
triggered by received IPv6 packet and there is no existing mapping triggered by received IPv6 packet and there is no existing mapping
entry for the IPv6 source address (Editor's note: can this ever entry for the IPv6 source address (Editor's note: can this ever
happen in case of client-server nature of BIH?). happen in case of client-server nature of BIH?).
Other possible combinations are outside of BIH and BIH is not Other possible combinations are outside of BIH and BIH is not
involved in those. involved in those.
NOTE: There is one exception. When initializing the table the mapper NOTE: There is one exception. When initializing the table the mapper
registers a pair of its own IPv4 address and IPv6 address into the registers a pair of its own IPv4 address and IPv6 address into the
table. table.
3. Behavior and network Examples 3. Behavior and network Examples
Figure 4 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-only server. A communication is made possible by
by bump in the host. 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 4: Network Scenario #1 Figure 4: Network Scenario #1
Figure 5 illustrates a possible network scenario where an IPv4-only Figure 5 illustrates a possible network scenario where an IPv4-only
skipping to change at page 15, line 13 skipping to change at page 15, line 13
Figure 7: 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, but IPv4-only application are unlikely to need
them.
4.2. ICMP Message Handling 4.2. ICMP Message Handling
When an application needs ICMP messages values (e.g., Type, Code, When an application needs ICMP messages values (e.g., Type, Code,
etc.) sent from a network layer, ICMPv4 message values MAY be etc.) sent from a network layer, ICMPv4 message values MAY be
translated into ICMPv6 message values based on SIIT translated into ICMPv6 message values based on SIIT
[I-D.ietf-behave-v6v4-xlate], and vice versa. It can be implemented [I-D.ietf-behave-v6v4-xlate], and vice versa.
using raw socket.
4.3. IPv4 Address Pool and Mapping Table 4.3. IPv4 Address Pool and Mapping Table
The address pool consists of the private IPv4 addresses as per The address pool consists of the private IPv4 addresses as per
[RFC1918]. This pool can be implemented at different granularity in [RFC1918]. This pool can be implemented at different granularity in
the node e.g., a single pool per node, or at some finer granularity 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 such as per user or per process. In he case of large number of IPv4
applications communicate with IPv6 hosts, the available address applications would communicate with large number of IPv6 servers, the
spaces may be exhausted. As a result, it will be impossible for IPv4 available address spaces may be exhausted. This should be quite rare
applications to communicate with IPv6 nodes. It requires smart event and changes will decrease as IPv6 support increases. The
management techniques for address pool. For example, it is desirable possible problem can also mitigated with smart management techniques
for the mapper to free the oldest entry and reuse the IPv4 address or of the address pool. For example, entries with longest inactivity
IPv6 address for creating a new entry. In case of a per-node address time can be cleared and IPv4 addresess reused for creating new
mapping table, it MAY cause a larger risk of running out of address. entries.
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. 127/8 or 169.254/16 are rejected due applications as private. 127/8 or 169.254/16 are rejected due
possible assumptions applications may make when seeing those. possible assumptions applications may make when seeing those.
The RFC1918 addresses have a risk of conflicting with other The RFC1918 addresses have a risk of conflicting with other
interfaces. The conflicts can be mitigated by using least commonly interfaces. The conflicts can be mitigated by using least commonly
used network number of the RFC1918 address space. Addresses from used network number of the RFC1918 address space. Addresses from
172.16/12 prefix are thought to be less likely to conflict than 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 from 10/8 or 192.168/16 spaces, hence the used IPv4
addresses are following (Editor's comment: this is first and almost addresses are following (Editor's comment: this is first proposal,
random proposals): educated better quesses are welcome):
Source addresses: 172.21.112.0/30. Source address have to be Source addresses: 172.21.112.0/30. Source address have to be
allocated because applications use getsockname() calls and as in the allocated because applications use getsockname() calls and as in the
BIS mode an IP address of the IPv4 interface has to be shown. More BIS mode an IP address of the IPv4 interface has to be shown (e.g. by
than one address is allocated to allow implementation flexibility, 'ifconfig'). More than one address is allocated to allow
e.g. for cases where a host has multiple IPv6 interfaces. The source implementation flexibility, e.g. for cases where a host has multiple
addresses are from different subnet than destination addresses to IPv6 interfaces. The source addresses are from different subnet than
ensure applications do not do on-link assumptions and do enable NAT destination addresses to ensure applications would not do on-link
traversal functions. assumptions and would enable NAT traversal functions.
Primary destination addresses: 172.21.80.0/20. Address mapper will Primary destination addresses: 172.21.80.0/20. Address mapper will
select destination addresses primarily out of this pool. select destination addresses primarily out of this pool.
Secondary destination addresses: 10.170.160.0/20. Address mapper Secondary destination addresses: 10.170.160.0/20. Address mapper
will select destination addresses out of this pool if the node has will select destination addresses out of this pool if the node has
dual-stack connection conflicting with primary destination addresses. dual-stack connection conflicting with primary destination addresses.
4.4. Multi-interface 4.4. Multi-interface
In the case of dual-stack destinations BIH must do protocol In the case of dual-stack destinations BIH must do protocol
translation from IPv4 to IPv6 only when the host does not have any translation from IPv4 to IPv6 only when the host does not have any
IPv4 interfaces, native or tunneled, available for use. IPv4 interfaces, native or tunneled, available for use.
It is possible that an IPv4 interface is activated during BIH It is possible that an IPv4 interface is activated during BIH
operation, for example if a node moves to a coverage area of IPv4 operation, for example if a node moves to a coverage area of IPv4
enabled network. In such an event BIH must stop initiating protocol enabled network. In such an event BIH MUST stop initiating protocol
translation sessions for new connections and BIH may disconnect translation sessions for new connections and BIH MAY disconnect
active sessions. The choice of disconnection is left for active sessions. The choice of disconnection is left for
implementatations and it may depend on whether IPv4 address conflict implementatations and it may depend on whether IPv4 address conflict
situation occurs between addresses used by BIH and addresses used by situation occurs between addresses used by BIH and addresses used by
new IPv4 interface. new IPv4 interface.
4.5. Multicast 4.5. Multicast
Protocol translation for multicast is not supported. Protocol translation for multicast is not supported.
4.6. DNS cache 4.6. DNS cache
skipping to change at page 18, line 13 skipping to change at page 18, line 13
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
[I-D.ietf-behave-v6v4-xlate-stateful]. [I-D.ietf-behave-v6v4-xlate-stateful].
In the socket layer implementation approach the differences are due In the socket layer implementation approach the differences are due
to the address translation occurring at the API and not in the to the address translation occurring at the API and not in the
network layer. That is, since the mechanism uses the API translator network layer. That is, since the mechanism uses the API translator
at the socket API level, hosts can utilize the security of the at the socket API layer, hosts can utilize the security of the
network layer (e.g., IPSec) when they communicate with IPv6 hosts network layer (e.g., IPSec) when they communicate with IPv6 hosts
using IPv4 applications via the mechanism. As well, there is no need using IPv4 applications via the mechanism. As well, there is no need
for DNS ALG as in NAT-PT, so there is no interference with DNSSEC for DNS ALG as in NAT-PT, so there is no interference with DNSSEC
either. either.
In the network layer implementation approach hosts cannot utilize the In the network layer implementation approach hosts cannot utilize the
security above network layer when they communicate with IPv6 hosts security above network layer when they communicate with IPv6 hosts
using IPv4 applications via BIH and encrypt embedded IP addresses, or using IPv4 applications via BIH and encrypt embedded IP addresses, or
when the protocol data is encrypted using IP addresses as keys. In when the protocol data is encrypted using IP addresses as keys. In
these cases it is impossible for the mechanism to translate the IPv4 these cases it is impossible for the mechanism to translate the IPv4
skipping to change at page 19, 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, and Ed Jankiewizh in reviewing this Christian Vogt, Jan M. Melen, Ed Jankiewizh, Marnix Goossens, Ala
document are gratefully acknowledged. Hamarsheh, and Julien Laganier in reviewing this 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).
 End of changes. 40 change blocks. 
175 lines changed or deleted 182 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/