Internet DRAFT - draft-hamarsheh-behave-biav2
draft-hamarsheh-behave-biav2
Network working group A. Hamarsheh
Internet-Draft ETRO/Vrije Universiteit Brussel
Intended status: Informational M. Goossens
Expires: July 23, 2011 ETRO/Vrije Universiteit Brussel
January 19, 2011
Hosts with Any Network Connectivity Using "Bump-in-the-API"(BIA)
draft-hamarsheh-behave-biav2-05
Abstract
This document specifies a mechanism for hosts with any network
connectivity (IPv4 only, IPv6 only, or dual IPv4/IPv6
connectivity) to run applications of any capability
(IPv4 only, IPv6 only, or dual IPv4/IPv6) without any
modification to those applications. It is a generalisation
of a previous experimental protocol called "Bump-in-the-API"
(BIA) [RFC3338]. New mechanism of BIA allows a changeover between
the application layer and the IP communication layers from IPv4
to IPv6 and vice versa or IPv6 to IPv4 and vice versa, without
requiring those applications to be converted in addressing
capabilities, effectively shielding the application layer from
IPv4 or IPv6 connectivity. This is considered by the authors to
be one of the essential conditions for the transition to IPv6
in the Internet to be successful.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 23, 2011.
Hamarsheh & Goossens Expires July 23, 2011 [Page 1]
Internet-Draft BIAv2 January 2011
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents:
1. Motivation and Introduction ................................ 5
1.1 Motivation .............................................. 5
1.2 Introduction ............................................ 6
2. Applicability and Related Techniques ....................... 7
2.1 Applicability ........................................... 7
2.2 Related Techniques ...................................... 8
3. Host Configurations Using BIA .............................. 9
3.1 IPv6 Only Host Using BIA ................................ 10
3.2 IPv4 Only Host Using BIA ................................ 10
3.3 Dual Connectivity Host Using BIA ........................ 11
4. BIA Modules ................................................ 12
4.1 Name Resolver ........................................... 12
4.1.1 IPv4 Only Application on The Local Host .............. 12
4.1.2 IPv6 Only Application on The Local Host .............. 13
4.1.3 Reverse DNS Lookup ................................... 14
4.1.4 Originating Without DNS Lookup ....................... 14
4.2 Address Resolver ........................................ 15
4.2.1 Mapping .............................................. 15
4.2.2 Embedding ............................................ 16
4.3 Function Mapper ......................................... 16
Hamarsheh & Goossens Expires July 23, 2011 [Page 2]
Internet-Draft BIAv2 January 2011
5. Behavior Examples ......................................... .17
5.1 IPv4 Only Application, IPv6 Only Connectivity with an
IPv6 Only Peer .......................................... 18
5.1.1 Behavior for IPv4 Only Originator Application on IPv6
Only Host Communicating to IPv6 Only Peer ............ 18
5.1.2 Behavior for IPv4 Only Recipient Application on IPv6
Only Host ............................................ 19
5.2 IPv4 only Application, IPv6 Only Network and Dual
Connectivity Peer ....................................... 21
5.2.1 Behavior for IPv4 Only Originator Application on IPv6
Only Host Communicating with Dual Connectivity Host .. 21
5.2.2 Behavior for IPv4 Only Recipient Application on IPv6
Only Host Communicating with Dual Connectivity Host .. 21
5.3 IPv6 Only Application, IPv4 Only Connectivity with an
IPv4 Only Peer .......................................... 21
5.3.1 Behavior for IPv6 Only Originator Application on IPv4
Only Host Communicating with IPv4 Only Host .......... 21
5.3.2 Behavior for IPv6 Only Recipient Application on IPv4
Only Host Communicating with IPv4 Only Host .......... 23
5.4 IPv6 Only Application, IPv4 Only Network and Dual
Connectivity Peer ....................................... 24
5.4.1 Behavior for IPv6 Only Originator Application on IPv4
Only Host Communicating with Dual Connectivity Host .. 24
5.4.2 Behavior for IPv6 Only Recipient Application on IPv4
Only Host Communicating with Dual Connectivity Host .. 24
5.5 IPv4 Only Application on Dual Connectivity Host
Communicating to IPv6 Only Peer ......................... 24
5.5.1 IPv4 Only Originator Application on Dual Connectivity
Host Communicating to IPv6 Only Peer ................ 24
5.5.2 IPv4 Only Recipient Application on Dual Connectivity
Host Communicating to IPv6 Only Peer ................. 24
5.6 IPv6 Only Application on Dual Connectivity Host
Communicating to IPv4 Only Peer ......................... 24
5.6.1 IPv6 Only Originator Application on Dual Connectivity
Host Communicating to IPv4 Only Peer ................. 24
5.6.2 IPv4 Only Recipient Application on Dual Connectivity
Host Communicating to IPv4 Only Peer ................. 24
6. Considerations ............................................. 25
6.1 Socket API Conversion ................................... 25
6.2 Address Mapping and Embedding ........................... 25
6.3 ICMP Message Handling ................................... 26
6.4 Implementation Issues ................................... 26
7. Limitations ................................................ 26
8. IANA Considerations ........................................ 26
9. Security Considerations .................................... 27
Hamarsheh & Goossens Expires July 23, 2011 [Page 3]
Internet-Draft BIAv2 January 2011
10. References ................................................. 27
10.1 Normative References ................................... 27
10.2 Informative References ................................. 28
Authors Addresses .............................................. 29
Hamarsheh & Goossens Expires July 23, 2011 [Page 4]
Internet-Draft BIAv2 January 2011
1. Motivation And Introduction
1.1 Motivation
It is probably important to give a brief analysis first of one of the
blocking factors withholding the wide-spread introduction of IPv6 in
order to fully understand why the here proposed BIA is considered an
essential component in the unlocking of IPv6.
At the inception of IPv6 it was - rather naively - presumed that all
parties involved with the Internet would be eager to make the
changeover and that the transition would happen spontaneously.
It is now quite generally acknowledged that some human and commercial
factors preventing a spontaneous transition have been largely
underestimated. In the transition to IPv6 there are essentially
two parties involved: network providers and end-users.
The benefits of using IPv6 are almost entirely for the network
providers, while the end-users have only potentially indirect
benefits from better network operation. No drive to make the
changeover should be expected from the majority of end-users,
as they have probably little to gain. The network providers can expect
benefits,but they are obviously dependent on the willingness of their
end-users to make any changeover. The result is some kind of
deadlock: no (commercial) network provider is going to force the
customers to make the changeover against their will. So making the
transition transparent to the end-user is the key in any transition
to IPv6. The average end-users are not really aware about what goes on
in the network layer, and even if they do, they usually could not care
less. It does not matter much to them if their applications are
communicating using IPv4 or IPv6. But, while there is no drive to be
expected from the end-users for any transition to IPv6, the vast
majority would not object to the transition on condition they can go
on using their applications as before.
While the first impression is that applications are not affected
by the changeover on the IP layer from IPv4 to IPv6, this is
unfortunately not true. The applications are using IP addresses,
and hence should be capable of dealing with the longer IPv6 addresses
when having to communicate over IPv6.
Expecting all applications to be modified to be capable of dealing
with the longer IPv6 addresses is rather naive. Apart from the
"standard" Internet applications with rather good support such as
web browsers, email programs, etc. that can be expected to be IPv6
enabled, there are thousands of other applications, some of them are
written by small companies (of which some may be out of business)
and others are even "home-made". For some applications, Internet
communication is only a side-issue, for example for registering
and/or checking for updates, and upgrading to become IPv6 compatible
is probably not a high priority. It is to be expected that a large
Hamarsheh & Goossens Expires July 23, 2011 [Page 5]
Internet-Draft BIAv2 January 2011
proportion of applications will only be modified to be IPv6
compatible when IPv6 usage gets into full swing. And even if the
IPv6 capable new versions of application software are made available,
it is again rather naive to expect all end-users to do the required
updating of all the software on their system.
The end-users MAY be willing to accept a changeover to IPv6, but will
NOT accept that some of their applications will no longer work as
before. From this observation it becomes obvious that it is
absolutely essential that provisions are standard installed and
enabled on any general purpose machine (the vast majority of systems
connected to the Internet) that is provided for IPv6 communication
and potentially has to run IPv4-only applications to continue
communicating as before when communicating using IPv6. While the
demand for mandatory provisions on every general purpose machine
capable of communicating using IPv6 may seem a tall order,
it should be realized that this approach is much more realistic
then expecting all applications to be made IPv6 compatible:
compared to thousands of applications that would need conversion
requiring all application developers to follow suit, the number of
communication stack implementations on general purpose machines is
very small and is made by only a handful of developers.
While somewhat less of an urgent issue, the solution should be
general enough to handle the reverse problem as well: an IPv6 only
application should be able to communicate on a machine with IPv4
only connectivity, or dual IPv4/IPv6 connectivity when communicating
using IPv4 with remote hosts that have IPv4-only connectivity.While
this looks like a move in the wrong direction in the context of
transition towards IPv6, this capability is also important to break
the slowdown of the development of IPv6 compatible applications,
as described in [RFC2460]. Little effort is being invested into
making applications IPv6 capable, as almost no machines currently
have IPv6 connectivity. BIA allows to using these IPv6 capable
applications to run on the IPv4 infrastructure, removing the
practical limitation that IPv6 applications cannot be used at
this time.
Other practical issues are blocking the deployment of IPv6, such as
the lack of IPv6 support in public access networks, the lack of real
auto configuration between IPv4 and IPv6 connectivity,
incompatibility in IPv4/IPv6 connectivity of hosts, etc. Solutions to
these other practical issues are being investigated currently by
the authors.
1.2 Introduction
The original BIA is an experimental function intended at allowing IPv4
only applications on dual stack (dual connectivity) hosts to
Hamarsheh & Goossens Expires July 23, 2011 [Page 6]
Internet-Draft BIAv2 January 2011
communicate over IPv6 with remote IPv6 only applications. It was also
only usable in the specific context described.
The proposed BIA is a generalisation of the original concept, allowing
any mixture of IPv4/IPv6 type capable applications to communicate over
any IPv4/IPv6 connections with any IPv4/IPv6 type capable remote
applications. BIA effectively decouples application IPv4/IPv6
capability from IPv4/IPv6 connectivity, and all allows IPv4/IPv6
incompatibility between two communicating applications.
The concept is quite simple: BIA essentially does internal address
translation where necessary between IPv4 and IPv6 addresses in between
the application and the communication stack; functionally, it can be
compared to an internal NAT [RFC3022] between the communication stack
and the application layer. Conceptually BIA is an adaptation layer
that needs to be inserted between the application layer and the IP
communication stack as an API layer on top of the native API functions,
offering the same API functions as the native ones to the application
layer. In an optimized implementation, it can probably better be
implemented as an internal modification to the API itself.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] .
This document uses terms defined in [RFC2460], [RFC4213], [RFC2767],
[RFC3338], and [I-D.draft-huang-behave-rfc3338bis].
2. Applicability and Related techniques
The term IPv4/IPv6 connectivity will be used, rather than stack, since
it is the connectivity that specifies whether the machine can
communicate using IPv4, IPv6 or both, and not only the implementation
of the IP stacks inside the machine; e.g. a dual stack machine has
both IPv4 and IPv6 stacks implemented, but may have only IPv4 or IPv6
network connectivity due to the type of network it is connected to,
or may have to use IPv6 because the remote has only IPv6 connectivity.
2.1 Applicability
The BIA is a mechanism that should be mandatory installed and enabled
on hosts potentially having to run applications with incompatible
IPv4/IPv6 addressing capability regarding to their IPv4/IPv6 network
connectivity. For example, IPv4 only applications that have to
communicate over IPv6; or IPv6 only applications having to communicate
over IPv4 only connectivity. It allows an IPv4 only application which
is running on the local host to communicate over IPv6 with another
IPv4/IPv6 application on another host without any modification.
Hamarsheh & Goossens Expires July 23, 2011 [Page 7]
Internet-Draft BIAv2 January 2011
It is important to note that the mechanism assumes that the host knows
whether it is connected via dual IPv4/IPv6 connectivity, IPv4 only
connectivity, or IPv6 only connectivity (this is an implementation
issue and will not be discussed here). Table 1 describes the scenarios
of all IPv4/IPv6 capability types of applications running over all
possible types of host connectivities. Only the situations with
incompatibility between application IPv4/IPv6 capability and IPv4/IPv6
connectivity are listed.
Source Host Destination Host
+---------------+-------------------+ +-------------------+
| Appl. Version | Host Connectivity | Network | Host Connectivity |
+---------------+-------------------+ +-------------------+
| IPv4 | IPv6 | <-IPv6-> | IPv6 |
+---------------+-------------------+ +-------------------+
| IPv4 | IPv6 | <-IPv6-> | IPv4/IPv6 |
+---------------+-------------------+ +-------------------+
| IPv6 | IPv4 | <-IPv4-> | IPv4 |
+---------------+-------------------+ +-------------------+
| IPv6 | IPv4 | <-IPv4-> | IPv4/IPv6 |
+---------------+-------------------+ +-------------------+
| IPv4 | IPv4/IPv6 | <-IPv6-> | IPv6 |
+---------------+-------------------+ +-------------------+
| IPv6 | IPv4/IPv6 | <-IPv4-> | IPv4 |
+---------------+-------------------+ +-------------------+
Table 1: List all the scenarios treated by BIA mechanism
2.2 Related Techniques
The original BIA mechanism is customized for dual stack hosts. BIA is
a mechanism that is inserted between the socket API module and the
TCP/IP module. The main purpose of this mechanism is to make the IPv4
applications communicate with applications that can only communicate
using IPv6 (IPv6 only connectivity and/or IPv6 only application)
without any modification on those IPv4 applications. This would be
achieved by translating the IPv4 socket API functions into IPv6 socket
API functions and vice versa.
BIS mechanism [RFC2767] allows host to communicate with other IPv6
hosts using existing IPv4 applications. It is also customized for dual
stack hosts. The technique uses SIIT [RFC2765] to translate the IPv4
traffic into IPv6 traffic and vice versa. However, this mechanism uses
translator which is inserted between the TCP/IP module and the network
card driver. The limitations of this mechanism are similar to the SIIT
limitations concerning the IP header translation methods. Its
implementation is also fully dependent on the network interface driver.
Hamarsheh & Goossens Expires July 23, 2011 [Page 8]
Internet-Draft BIAv2 January 2011
3. Host Configurations using BIA
BIA can be installed on three different host configurations regarding
to IPv4/IPv6
connectivity:
1. IPv4 only host: only IPv4 connectivity.
2. IPv6 only host: only IPv6 connectivity.
3. IPv4/IPv6 host: both IPv4 and IPv6 connectivity.
The connectivity of the local host for communication with a remote host
is actually decided by several factors:
- The implementation of stack(s) in the local (IPv4 only stack, IPv6
only stack, or dual stack).
- The network connectivity of the local host (IPv4 network connectivity
only, IPv6 network connectivity only, both IPv4 and IPv6 network
connectivity).
- The connectivity of the remote machine (IPv4 only connectivity, IPv6
only connectivity, both IPv4 and IPv6 connectivity).
This means that the connectivity of a host, even with dual stack
implementation, is dynamic: it depends on the network connectivity,
which may change (e.g. a laptop that may be regularly connected to
different networks over time) and/or the connectivity of the remote
host.
For example a local host may be limited to IPv6 communication with a
remote host because it only has an IPv6 stack implemented, it may
have a dual stack implementation but only IPv6 network connectivity,
or the remote host may have only IPv6 connectivity.
The connectivity of the host will be combined with three possibilities
of application addressing capability.
- IPv4 only application: only IPv4 addressing capability.
- IPv6 only application: only IPv6 addressing capability.
- IPv4/IPv6 application: both IPv4 and IPv6 addressing capability.
There will be different behavior for BIA depending on the local host
IPv4/IPv6 connectivity as well as the application's IPv4/IPv6
addressing capability.
- IPv4 applications communicating over IPv4 or IPv6 applications
communicating over IPv6 are the native situations and do not need
consideration here; in this case BIA simply has to perform
no action.
Hamarsheh & Goossens Expires July 23, 2011 [Page 9]
Internet-Draft BIAv2 January 2011
- For an IPv4 application that needs to communicate using IPv6,
the IPv4 application's addressing needs to be converted to IPv6
in order to be transmitted to the remote host. The opposite
conversion has to be applied when an IPv6 application needs to
communicate over IPv4.
- For an IPv6 only application on an IPv4/IPv6 host communicating
with an IPv4/IPv6 remote host, the mechanism provides an optional
feature to make this application able to communicate over IPv4 as
well as over IPv6. If this application is trying to communicate
over IPv4, the application's addressing needs to be converted to
IPv4 in order to be transmitted to the remote host.
3.1 IPv6 Only Host Architecture Using BIA
IPv4 applications need IPv4 connectivity for communication. BIA is a
mechanism that enables hosts that have to communicate using IPv6 to
run IPv4 applications. Such hosts MUST have BIA installed and enabled.
Figure 1 shows the architecture of the IPv6 host in which BIA
is installed.
+---------------------------------------------+
| +-------------------+ |
| | IPv4 Applications | |
| +-------------------+ |
| +-[BIA]-----------------------------------+ |
| | +-----------------------+ | |
| | |Socket API (IPv4, IPv6)| | |
| | +-----------------------+ | |
| +-----------------------------------------+ |
| +-------------------+ |
| | IPv6 API | |
| +-------------------+ |
| | | |
| | TCP(UDP)/IPv6 | |
| | | |
| +-------------------+ |
+---------------------------------------------+
Figure 1: the architecture of IPv6 only host
In which BIA is installed.
3.2 IPv4 Only Host Architecture Using BIA
IPv4 only hosts are capable of running IPv4 applications only. BIA
can be installed on such machines to allow these hosts to run IPv6
only applications as well. Figure 2 shows the host architecture of
the IPv4 host in which BIA is installed.
Hamarsheh & Goossens Expires July 23, 2011 [Page 10]
Internet-Draft BIAv2 January 2011
+---------------------------------------------+
| +-------------------+ |
| | IPv6 Applications | |
| +-------------------+ |
| +-[BIA]-----------------------------------+ |
| | +-----------------------+ | |
| | |Socket API (IPv4, IPv6)| | |
| | +-----------------------+ | |
| +-----------------------------------------+ |
| +-------------------+ |
| | IPv4 API | |
| +-------------------+ |
| | | |
| | TCP(UDP)/IPv4 | |
| | | |
| +-------------------+ |
+---------------------------------------------+
Figure 2: the architecture of IPv4 only host
In which BIA is installed.
3.3 Dual Connectivity Host Architecture Using BIA
[RFC4213] suggests that dual stack hosts need applications, dual
TCP/IP modules and addresses for both IPv4 and IPv6. In such hosts,
the BIA will be used only when the received DNS record(s) version is
incompatible with the running of the application's IPv4/IPv6
capability. For example, if a dual connectivity host is running an
IPv4 only application, and this application is going to communicate
with an IPv6 only host, then the name resolver will receive the
'AAAA' record for the destination host so that the current
connectivity will be IPv6, and BIA will translate the IPv4 socket
API functions into IPv6 socket API functions and vice versa.
BIA always will use the API functions that are compatible with the
destination address. Figure 3 shows a dual connectivity host on which
BIA is installed.
Hamarsheh & Goossens Expires July 23, 2011 [Page 11]
Internet-Draft BIAv2 January 2011
+---------------------------------------------+
| +-------------------+ +-------------------+ |
| | IPv4 Applications | | IPv6 Applications | |
| +-------------------+ +-------------------+ |
| +-[BIA]-----------------------------------+ |
| | +-----------------------+ | |
| | |Socket API (IPv4, IPv6)| | |
| | +-----------------------+ | |
| +-----------------------------------------+ |
| +-------------------+ +-------------------+ |
| | IPv4 API | | IPv6 API | |
| +-------------------+ +-------------------+ |
| | | | | |
| | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | |
| | | | | |
| +-------------------+ +-------------------+ |
+---------------------------------------------+
Figure 3: the architecture of dual stack host
In which BIA is installed.
4. BIA Modules
Like BIA, the API translator in BIA consists of three modules, name
resolver, address resolver, and function mapper.
4.1 Name Resolver
In general the name resolver module returns a proper answer in response
to the IPv4 or IPv6 application's DNS resolving request. The name
resolver has different behaviors depending on the running
application's IPv4/IPv6 capability and the IPv4/IPv6 connectivity.
4.1.1 IPv4 only application on the local host:
- IPv4 Only Host:
Since this is the native situation, BIA needs to perform no action.
- IPv6 Only Host
This behavior of the name resolver occurs when an IPv4 application
needs to communicate using IPv6. The application will try to resolve
names via the IPv4 resolver library (e.g. gethostbyname). BIA will
call the IPv6 equivalent function (e.g. getnameinfo) that will
resolve both 'A' and 'AAAA' records. If it got 'AAAA' record(s) only,
it requests the address resolver (see below) to assign internal IPv4
address(es) corresponding to the IPv6 address(es) of the 'AAAA'
record(s), then creates 'A' record(s) for the assigned IPv4
address(es), finally returns the created 'A' record(s) of the
Hamarsheh & Goossens Expires July 23, 2011 [Page 12]
Internet-Draft BIAv2 January 2011
internal address(es) to the IPv4 application. Note that this behavior
is similar to the name resolver behavior in the BIA mechanism, but
there are differences in the way internal addresses are assigned and
managed (see address resolver further).
If both 'A' and 'AAAA' records are received, BIA will discard the 'A'
record(s) as these cannot be used with IPv6, and select only the
'AAAA' record(s).
- IPv4/IPv6 Host:
The application will try to resolve names via the IPv4 resolver library
(e.g. gethostbyname). BIA will call the IPv6 equivalent function (e.g.
getnameinfo) that will resolve both 'A' and 'AAAA' records. If it got
'AAAA' record(s) only, it requests the address resolver (see below) to
assign internal IPv4 address(es) corresponding to the IPv6 address(es)
of the 'AAAA' record(s), then creates 'A' record(s) for the assigned
IPv4 address(es), finally returns the created 'A' record(s) of the
internal address(es) to the IPv4 application. If it got 'A' record(s)
only, the communication will continue as native IPv4 communication,
and BIA has to do no operation. If both 'A' and 'AAAA' records are
returned, the communication can be effected natively using IPv4 using
the 'A' record(s). But as an additional, optional feature, the IPv4
application can also be allowed to communicate over IPv6 with IPv6
peer(s). In that case, it requests the address resolver (see below) to
assign internal IPv4 address(es) corresponding to the IPv6 address(es)
of the 'AAAA' record(s), then creates 'A' record(s) for the assigned
IPv4 address(es), and finally returns both the original 'A' for the
remote AND the created 'A' record(s) of the internal address(es) to
the IPv4 application. This extends the communication capabilities
of the application to cover both IPv4 and IPv6 communication with
the remote(s).
4.1.2 IPv6 Application on the local host:
- IPv6 Only Host:
Since this is the native situation, BIA needs to perform no action.
- IPv4 Only Host:
This situation occurs when an IPv6 application needs to communicate
using IPv4, the application will try to resolve names via the IPv6
resolver library (e.g. getnameinfo). BIA will call the IPv4 equivalent
function (e.g. gethostbyname). If it got 'A' record(s) only, it
requests the address resolver to assign an internal IPv4-embedded
IPv6 address(es) [I-D.draft-ietf-behave-address-format] corresponding
to the IPv4 ddress(es), then creates 'AAAA' record(s) for the
IPv4-embedded IPv6 address(es) and returns these 'AAAA' record(s) to
the IPv6 application.
Hamarsheh & Goossens Expires July 23, 2011 [Page 13]
Internet-Draft BIAv2 January 2011
- IPv4/IPv6 Host:
The application will try to resolve names via the IPv6 resolver library
(e.g. gethostinfo) that will resolve both 'A' and 'AAAA' records. If it
got 'A' record(s) only, the name resolver will request the address
resolver to assign internal IPv4-embedded IPv6 address(es) corresponding
to the IPv4 address(es), then creates 'AAAA' record(s) for the
IPv4-embedded IPv6 address(es) and returns these 'AAAA' record(s) to
the application. If it got 'AAAA' records only, the communication will
continue as native IPv6 communication, and BIA has to do no operation.
If both 'A' and 'AAAA' records are returned, the communication can be
effected natively using IPv6 using the 'AAAA' record(s). But as an
additional, optional feature, the IPv6 application can also be allowed
to communicate over IPv4 with IPv4 peer(s). In that case, it requests
the address resolver to assign internal IPv4-embedded IPv6 address(es),
then creates 'AAAA' record(s), and finally returns both the original
'AAAA' for the remote AND the created 'AAAA' record(s) of the internal
address(es) to the IPv6 application. This extends the communication
capabilities of the application to cover both IPv4 and IPv6
communication with the remote(s).
4.1.3 Reverse DNS lookup
For various reasons, applications may do "pointer" lookups, i.e. the
application passes the IP address and expects the host name in return.
BIA should be able to handle these calls. When address translation
(mapping or embedding) was performed on the host IP address, the
application will call with the internal address generated by BIA.
The DNS call to resolve the name should obviously be made with the
external address that corresponds to the translated address, and the
name returned for the external address needs to be returned to the
application.
4.1.4 Originating without DNS lookup
Some applications bypass the DNS lookup, and use an IP address directly
instead. While often this is bad practice, in some instances this how
the software is being operated. For an IPv4 only application making
such call, if an address mapping was stored for the supplied IPv4
address, that mapping can be used. Otherwise, as no DNS call is made, a
correspondence between IPv4 and IPv6 addresses cannot be made by the
name and address resolvers, and communication using incompatible
application IPv4 capability and IPv6 connectivity is impossible.
But for both for IPv4 and IPv6 applications, as a last resort, a
"dirty trick" can be attempted however. Using the IP address from the
application, a "pointer" DNS lookup can be made. If this succeeds,
a forward DNS lookup can be made on the returned name, which may return
Hamarsheh & Goossens Expires July 23, 2011 [Page 14]
Internet-Draft BIAv2 January 2011
one or more addresses of the other type required to establish the
required IPv4/IPv6 address relationship. If this trick does not
succeed, communication will be impossible, unless native communication
is available (IPv4 over IPv4 connectivity or IPv6 over IPv6
connectivity).
It is recommended that address relationships can be manually entered
in the mapping table for such occurrences. Such address mappings are in
this case external IPv4-to-external IPv6 address mappings, and not
relations between an internal and an external address.
4.2 Address Resolver
The address resolver is only involved with incompatibility between
application IPv4/IPv6 capability and host IPv4/IPv6 connectivity. The
address resolver has different behavior depending on the name resolver
and function mapper requests. Like in the original BIA address mapper,
the address resolver in BIA maintains a table of the pairs of an
internal IPv4 address and an external IPv6 address in an IPv6 only
host. These IPv4 addresses are assigned from an IPv4 address pool for
internal addresses, but the mechanism for the pool is different here,
as explained further.
The key difference between BIA and the BIA mechanism is the ability for
the later to address all kinds of remote host connectivity (i.e. IPv4
only, IPv6 only and dual IPv4/IPv6 connectivity). Different addressing
techniques are used depending on the remote host. The sending host has
to take the decision either to map the destination IPv6 address into an
internal IPv4 address assigned from the IPv4 address pool, or to embed
the IPv4 address into an internal IPv4-embedded IPv6 address. The
Address resolver in BIA can receive two possible address types-normally
after calling the name resolver and querying the DNS- regarding the
remote host(s) for that domain name:
- IPv6 Address: in this case it receives 'AAAA' record(s) and the
address resolver has to map the IPv6 into an internal IPv4
address(es).
- IPv4 address: in this case it receives 'A' record(s) and the address
resolver has to embed the IPv4 address into an internal IPv6
address(es).
4.2.1 Mapping
This technique is used when an IPv4 application needs to communicate
using IPv6. It internally maintains a table of the pairs of IPv4
address(es) and IPv6 address(es). The IPv4 addresses are assigned
from an IPv4 address pool. These addresses should be selected from
a private IPv4 addresses as per [RFC1918] to be used by BIA for
Hamarsheh & Goossens Expires July 23, 2011 [Page 15]
Internet-Draft BIAv2 January 2011
mapping purposes (see further). When the name resolver or the
function mapper requests it to assign an internal IPv4 address
corresponding to an IPv6 address, it selects and returns an IPv4
address out of the pool, and registers a new entry into the table
dynamically. As in the original BIA, the registration occurs in the
following two cases:
1. When the name resolver gets only an 'AAAA' record for the target
host name and there is not a mapping entry for the IPv6 address.
2. When the function mapper gets a socket API function call from the
data received and there is not a mapping entry for the IPv6 source
address. Address mappings are stored. When the address resolver is
called to map an IPv6 external address into an IPv4 internal address,
it will first look up the table to check whether there was a previous
mapping for that address. If one is found, it will reuse and return
that mapping. If not, it will create a new mapping, store that mapping
and return the newly created mapping.
4.2.2 Embedding
Unlike the original BIA, BIA also allows IPv6 only applications to
communicate over IPv4. Therefore a correspondence between external
IPv4 addresses and internal IPv6 addresses need to be established.
The proposed method is "IPv4-in-IPv6" address embedding
[I-D.draft-ietf-behave-address-format]. The address resolver is
configured to use one of the methodologies that are described in
[I-D.draft-ietf-behave-address-format] to create an
IPv4-embedded IPv6 address. The new address consists of: Network
Specific Prefix (NSP) (32 bits), the IPv4 destination address
(32 bits), and finally the suffix (64 bits). Figure 4 demonstrates
the IPv4-embedded IPv6 address structure.
As the real external IPv4 address is embedded into the internal
IPv6 address, no registering is required in this case, as there
is always a unique correspondence.
| 32 bits | 32 bits | 64 bits |
+--------------+--------------+---------------------------+
| NSP | IPv4 Address | Suffix |
+--------------+--------------+---------------------------+
Figure 4: The structure of IPv4-embedded IPv6 address
4.3 Function Mapper
The function mapper has different behavior depending on the host
connectivity. In dual connectivity hosts (IPv4 and IPv6 connectivity)
the function mapper is used to decide which API functions to call in
Hamarsheh & Goossens Expires July 23, 2011 [Page 16]
Internet-Draft BIAv2 January 2011
the current communication. It is important to note that the BIA modules
will be invoked just if there is an incompatibility between the running
application and the connectivity type. In case of IPv6 only or IPv4
only connectivity, the main goal of the function mapper is just like
in original BIA mechanism. It is used when conversion is required
from IPv4 to IPv6 or the other way around between application layer
and communication stack. In that case it translates the API functions
used by the application into the API functions needed for the
communication, and vice versa.
In dual connectivity hosts, deciding which API functions to call
depends on the address type of the remote. The following is the
behavior of the function mapper running on dual connectivity hosts:
1. IPv4 only application communicating over IPv6: in this case it will
call the equivalent IPv6 socket API functions. The application will use
the IPv4 socket API to communicate with other hosts. Since the
application needs to communicate over IPv6, the function mapper
intercepts the IPv4 socket API functions and calls the equivalent IPv6
socket API functions instead.
2. IPv6 only application communicating over IPv4: in this case it will
call the equivalent IPv4 socket API functions. The application will use
the IPv6 socket API to communicate with other hosts. Since the
application needs to communicate over IPv4, the function mapper
intercepts the IPv6 socket API functions and calls the equivalent IPv4
socket API functions instead.
5. Behavior Examples
The following sections will describe the behaviors of the hosts and
applications that are listed in table 1.
In the following sections, the meanings of arrows are as follows:
---> A DNS message for name resolving created by the
Applications and the name resolver in the API translator.
+++> An IPv4 or IPv4-embedded IPv6 address request to and reply
from the address resolver for the name resolver and the
function mapper.
===> Data flow by API functions created by the applications
and the function mapper in the API translator.
Hamarsheh & Goossens Expires July 23, 2011 [Page 17]
Internet-Draft BIAv2 January 2011
5.1 IPv4 Only Application, IPv6 Only Connectivity with an IPv6
Only Peer.
5.1.1 Behavior for IPv4 Only Originator Application on IPv6 Only Host
Communicating to IPv6 Only Peer
When an IPv4 application sends a DNS query to its name server, the name
resolver intercepts the query and then creates a new query to resolve
both 'A' and 'AAAA' records. When only 'AAAA' record(s) is (are)
resolved, the name resolver requests the address resolver to get IPv4
address(es) corresponding to the IPv6 address(es) for each IPv6 address
from the 'AAAA' record. The address resolver first looks up the table
of stored entries to check if the correspondence was made previously.
If yes,the stored mapping is retrieved and passed to the name resolver.
If not, the address resolver creates a new mapping for an internal IPv4
address corresponding to the IPv6 external address, stores the mapping,
and returns the mapping to the name resolver. The name resolver, upon
receiving the internal IPv4 address(es) creates 'A' record(s) for the
assigned IPv4 address(es) and returns these to the application. In
order for the IPv4 application to send IPv4 packets over IPv6, it
calls the IPv4 socket API function. The function mapper detects the API
function call from the application. The IPv6 address is required to
invoke the IPv6 socket API function, thus the function mapper requests
the IPv6 address corresponding for the internal IPv4 address to the
address resolver. The address resolver selects the external destination
IPv6 address corresponding to the internal IPv4 address from the
mapping table and returns it to the function mapper. Using this IPv6
address, the function mapper will invoke the IPv6 socket API function
corresponding to the IPv4 socket API function received from the
application.
When a reply is received, this will come in through the IPv6 socket API,
and the function mapper requests the address resolver for the IPv4
address corresponding to the received IPv6 address. This IPv4 address
will be used to translate the IPv6 socket API function call into the
corresponding IPv4 socket API function call for the IPv4 application.
Figure 5 illustrates the behavior described above.
Hamarsheh & Goossens Expires July 23, 2011 [Page 18]
Internet-Draft BIAv2 January 2011
+-[IPv6 Only Host]-----------------+
| API Translator |
| +--------+ +--------+ +--------+ |
+----+ +---------+ | |Name | |Address | |Function| | +------++---+
|IPv4| | API | | |Resolver| |Resolver| | Mapper | | |IPv6 ||DNS|
|App.| | (V4/V6) | | +----|---+ +----|---+ +----|---+ | |Host || |
+-|--+ +----|----+ +------|----------|----------|-----+ +---|--++-|-+
| Resolve IPv4 for host 6| | | | |
|----------------------->| query 'A' and 'AAAA' for host 6 | |
| | |--------------------------------------->|
| | | | | | |
| | | Reply with 'AAAA' Only | |
| | |<---------------------------------------|
| | | | | | |
| | | Req IPv4 | | | |
| | |+++++++++>| | | |
| | | Rep IPv4 |{Address Mapping} | |
| | |<+++++++++| | | |
| Reply with 'A' record | | | | |
|<-----------------------| | | | |
|An IPv4 API function call | | | |
|=============================================>| | |
| | | |Req IPv6 | | |
| | | |<+++++++++| | |
| | | {Lookup} |Rep IPv6 | | |
| | | |+++++++++>| | |
| | | | IPv6 API function Call|
| | | | |===========>| |
| | | | | | |
| | | | IPv6 API function Call|
| | | | |<===========| |
| | | | Req IPv4 | | |
| | | |<+++++++++| | |
| | | {Lookup} | Rep IPv4 | | |
| | | |+++++++++>| | |
| An IPv4 API function call | | | |
|<=============================================| | |
| | | | | | |
Figure 5: The behavior of the originator communicates with IPv6
Application
5.1.2 Behavior for IPv4 Only Recipient Application on IPv6 Only Host
The IPv6 originator host that started the communication to this host
has resolved the address of this IPv6 host with 'AAAA' record(s)
Hamarsheh & Goossens Expires July 23, 2011 [Page 19]
Internet-Draft BIAv2 January 2011
through its name server, and has sent an IPv6 packet to this IPv6
host. The function mapper requests the internal IPv4 address
corresponding to the originator's IPv6 address. The address resolver
looks up the mapping table to check for an entry. If one is found,
it returns the internal IPv4 address corresponding to the IPv6
address. Then the function mapper invokes the corresponding IPv4
socket API function for the IPv4 application corresponding to the
IPv6 function. If not, the address resolver creates a new mapping
for an internal IPv4 address corresponding to the IPv6 external
address, stores the mapping, and returns the mapping to the function
resolver. The remaining part of the handling is identical to what
was described in 5.1.1. Figure 6 illustrates the behavior described
above.
+-[IPv6 Only Host]-----------------+
| API Translator |
| +--------+ +--------+ +--------+ |
+---------+ | |Name | |Address | |Function| | +---------+
|IPv4 App | | |Resolver| |Resolver| |Mapper | | |IPv6 Only|
| | | +----|---+ +----|---+ +----|---+ | |Host |
+----|----+ +------|----------|----------|-----+ +----|----+
| | | | IPv6 API function call
| | | |<===================|
| | |Req IPv4 | |
| | |<+++++++++| |
| {Address Mapping}|Rep IPv4 | |
| | |+++++++++>| |
|IPv4 API function call | | |
|<===================================| |
|Reply IPv4 data to host 6| | |
|===================================>| |
| | | | |
| | | Req IPv6 | |
| | |<+++++++++| |
| {Address Lookup} | Rep IPv6 | |
| | |+++++++++>| |
| | | | |
| | | |IPv6 API function call
| | | |===================>|
| | | | |
Figure 6: Behavior of receiving data from IPv6 host
Hamarsheh & Goossens Expires July 23, 2011 [Page 20]
Internet-Draft BIAv2 January 2011
5.2 IPv4 Only Application, IPv6 Only Network and Dual Connectivity Peer
5.2.1 Behavior for IPv4 Only Originator Application on IPv6 Only Host
Communicating with Dual Connectivity Host
When an IPv4 application sends a DNS query to its name server, the name
resolver intercepts the query and then creates a new query to resolve
both 'A' and 'AAAA' records. If both 'A' and 'AAAA' records are
resolved, the name resolver will only select the 'AAAA' records and
drop the drop the 'A' record(s) and requests the address resolver to
assign internal IPv4 address(es) corresponding to the IPv6 address(es).
The remaining behavior is exactly like described in 5.1.1.
5.2.2 Behavior for IPv4 Only Recipient Application on IPv6 Only Host
Communicating with Dual Connectivity Host
Exactly the same as in section 5.1.2
5.3 IPv6 Only Application, IPv4 Only Connectivity with an IPv4
Only Peer
5.3.1 Behavior for IPv6 Only Originator Application on IPv4 Only Host
Communicating with IPv4 Only Host
When an IPv6 application sends a DNS query to its name server to
resolve both 'A' and 'AAAA' records, the name resolver intercepts the
query and then creates a new query to resolve only 'A' record(s),
since it is a IPv4 only host. With only 'A' record(s) resolved, the
name resolver requests the address resolver to embed the IPv4
address(es) into IPv6 address(es) using the format described in
section 4.2.2. The name resolver creates 'AAAA' record(s) for the
IPv4 embedded IPv6 address(es) and returns it to the application.
In order for the IPv6 application to send IPv6 packets to IPv4 only
host, it calls the IPv6 socket API function. The function mapper
detects the API function call from the application. The function
mapper requires an IPv4 address to invoke the IPv4 socket API
function, so it requests the corresponding IPv4 address to the
address resolver. The address resolver extracts the destination
IPv4 address from the IPv4-embedded IPv6 address and returns it to
the function mapper. Using this IPv4 address, the function mapper
will invoke the IPv4 socket API function corresponding to the IPv6
socket API function. We notice here the address resolver is not
going to save any new records to the mapping table.
When a reply is received, this will come in through the IPv4 socket
API, and the function mapper requests the address resolver for the
IPv6 address corresponding to the received IPv4 address. This IPv6
address will be used to translate the IPv4 socket API function call
Hamarsheh & Goossens Expires July 23, 2011 [Page 21]
Internet-Draft BIAv2 January 2011
into the corresponding IPv6 socket API function call for the IPv6
application. Figure 7 illustrates the behavior described above.
+-[IPv4 Only Host]-----------------+
| API Translator |
| +--------+ +--------+ +--------+ |
+----+ +---------+ | |Name | |Address | |Function| | +------++---+
|IPv6| | API | | |Resolver| |Resolver| | Mapper | | |IPv4 ||DNS|
|App.| | (V4/V6) | | +----|---+ +----|---+ +----|---+ | |Host || |
+-|--+ +----|----+ +------|----------|----------|-----+ +---|--++-|-+
| Resolve IPv6 for host 4| | | | |
|----------------------->| query 'A' and 'AAAA' for host 4 | |
| | |--------------------------------------->|
| | | | | | |
| | | Reply with 'A' Only | |
| | |<-------------------------------------->|
| | | | | | |
| | | Req IPv6 | | | |
| | |+++++++++>| | | |
| | {Embedding} | Rep IPv6 | | | |
| | |<+++++++++| | | |
|Reply with 'AAAA' record| | | | |
|<-----------------------| | | | |
|An IPv6 API function call | | | |
|=============================================>| | |
| | | |Req IPv4 | | |
| | | |<+++++++++| | |
| | {Extracting}|Rep IPv4 | | |
| | | |+++++++++>| | |
| | | | IPv4 API function Call|
| | | | |===========>| |
| | | | | | |
| | | | IPv4 API function Call|
| | | | |<===========| |
| | | | Req IPv6 | | |
| | | |<+++++++++| | |
| | {Embedding} | Rep IPv6 | | |
| | | |+++++++++>| | |
| An IPv6 API function call | | | |
|<=============================================| | |
Figure 7: The behavior of the originator communicates with IPv4
Application
Hamarsheh & Goossens Expires July 23, 2011 [Page 22]
Internet-Draft BIAv2 January 2011
5.3.2 Behavior for IPv6 Only Recipient Application on IPv4 Only Host
Communicating with IPv4 Only Host
The IPv4 originator host has resolved the address of this IPv4 host
with 'A'records through its name server, and has sent an IPv4 packet
to this IPv4 host. The function mapper requests the IPv6 address to
the address resolver in order to invoke the IPv6 socket API function
to communicate with the IPv6 application. The address resolver embeds
the IPv4 address(es) into IPv6 address(es) using the format described
in section 4.2.2, and returns this address. Then the function mapper
invokes the corresponding IPv6 socket API function for the IPv6
application corresponding to the IPv4 function.
+-[IPv4 Only Host]-----------------+
| API Translator |
| +--------+ +--------+ +--------+ |
+---------+ | |Name | |Address | |Function| | +---------+
|IPv6 App | | |Resolver| |Resolver| |Mapper | | |IPv4 Only|
| | | +----|---+ +----|---+ +----|---+ | |Host |
+----|----+ +------|----------|----------|-----+ +----|----+
| | | | IPv4 API function call
| | | |<===================|
| | |Req IPv6 | |
| | |<+++++++++| |
| {Embedding} |Rep IPv6 | |
| | |+++++++++>| |
|IPv6 API function call | | |
|<===================================| |
|Reply IPv6 data to host 4| | |
|===================================>| |
| | | | |
| | | Req IPv4 | |
| | |<+++++++++| |
| {Extracting} | Rep IPv4 | |
| | |+++++++++>| |
| | | | |
| | | |IPv4 API function call
| | | |===================>|
| | | | |
Figure 8: Behavior of receiving data from IPv4 host
Hamarsheh & Goossens Expires July 23, 2011 [Page 23]
Internet-Draft BIAv2 January 2011
5.4 IPv6 Only Application, IPv4 Only Network and Dual Connectivity Peer
5.4.1 Behavior for IPv6 Only Originator Application on IPv4 Only Host
Communicating with Dual Connectivity Host
When an IPv6 application sends a DNS query to its name server, the name
resolver intercepts the query and then creates a new query to resolve
'A' record(s); no 'AAAA' record(s) are returned, as it is an IPv4 only
host. When 'A' record(s) is/are resolved, the name resolver will
request the address resolver to embed the IPv4 address(es) into IPv6
address(es) using the format that is describes in section 4.2.2.
The remaining processing is as in 5.3.1.
5.4.2 Behavior for IPv6 Only Recipient Application on IPv4 Only Host
Communicating with Dual Connectivity Host
Exactly the same as in section 5.3.2
5.5 IPv4 Only Application on Dual Connectivity Host Communicating to
IPv6 Only Peer
5.5.1 IPv4 Only Originator Application on Dual Connectivity Host
Communicating to IPv6 Only Peer
Exactly the same as in section 5.1.1
5.5.2 IPv4 Only Recipient Application on Dual Connectivity Host
Communicating to IPv6 Only Peer
Exactly the same as in section 5.1.2
5.6 IPv6 Only Application on Dual Connectivity Host Communicating
to IPv4 Only Peer
5.6.1 IPv6 Only Originator Application on Dual Connectivity Host
Communicating to IPv4 Only Peer
Exactly the same as in section 5.3.1
5.6.2 IPv4 Only Recipient Application on Dual Connectivity Host
Communicating to IPv4 Only Peer
Exactly the same as in section 5.3.2
Hamarsheh & Goossens Expires July 23, 2011 [Page 24]
Internet-Draft BIAv2 January 2011
6. Considerations
6.1 Socket API Conversion
This document uses the socket API conversion specified in [RFC3338].
6.2 Address Mapping and Embedding
There are some considerations as to the choice and management of the
internal addresses:
- For a diversity of reasons, several applications store the addresses
of machines they have been communicating with, and check these
addresses on next contact. It is hence important that each mapping
of external IPv6 to internal IPv4 addresses is being stored by BIA,
so as to always use the same internal address for a particular
external address at the next communication. This implies a very wide
IPv4 address range available for mapping. The authors propose a
Class A range, making approximately 16Mega addresses available.
Even that can get exhausted in some cases, so this range should
be supplemented by a round-robin scheme where,in case of exhaustion,
the mappings that remain unused for the longest time can be reused
for new mappings (not the creation time, but the last time that
mapping was actively used is important). It is considered that this
would be sufficient in about all operational situations. As this
mapping list potentially can become very large, the store/retrieval
mechanism implementation should be optimized for speed or it may
introduce unacceptable long delays. This is an implementation issue
however, and will not be dealt with here.
- It is obvious that an IPv4/IPv6 correspondence while be frequently
required in the course of a communication; short time caching seems
essential to avoid having to look up the correspondence again during
the course of a communication.
- A machine having both IPv4 and IPv6 connectivity will be using both
IPv4 and IPv6 addresses. To avoid conflicts, it is essential that the
internal addresses used will never be used as an external address.
Original BIA proposed the use of a limited (256 addresses) range as
a "pool" in an "unassigned" IPv4 address range. The limited size (256)
is much too small for operational purposes, even not considering the
requirement for storing the mappings as described in the previous
paragraph, as a machine may have more than this number of mappings
active concurrently. Taking into account the requirement for storing
the mappings, a very large range of unassigned addresses is required.
Hamarsheh & Goossens Expires July 23, 2011 [Page 25]
Internet-Draft BIAv2 January 2011
6.3 ICMP Message Handling
When an application needs ICMP messages values (e.g., Type, Code,
etc.) sent from a network layer, ICMPv4 message values MAY be
translated into ICMPv6 message values based on SIIT
[I-D.ietf-behave-v6v4-xlate], and vice versa. It can be implemented
using raw socket.
6.4 Implementation Issues
This document uses the implementation issues specified in [RFC3338].
7. Limitations
This mechanism supports unicast communications only. In order to support
multicast functions, some other additional functionalities must be
considered in the function mapper module.
Since the IPv6 socket API has new advanced features, it is difficult to
translate such kinds of IPv6 socket APIs into IPv4 socket APIs. Thus,
IPv6 inbound communication with advanced features may be discarded.
It should be noted that the original BIA assumes the hosts have
compatible network connectivity. The new version of the BIA is
developed to support the heterogeneity between connectivity and
applications only, NOT incompatible network connectivity.
Communication between hosts with incompatible connectivity
(IPv4 only connectivity to IPv6 only connectivity, or the other way
around) cannot be handled by BIA, and other solutions need to be
applied, e.g. protocol translation mechanisms PNAT
[I-D.draft-huang-behave-pnat], NAT64
[I-D.ietf-behave-v6v4-xlate-stateful], or SIIT
[I-D.ietf-behave-v6v4-xlate].
8. IANA Considerations
This document has no IANA actions.
Hamarsheh & Goossens Expires July 23, 2011 [Page 26]
Internet-Draft BIAv2 January 2011
9. Security Considerations
This document uses the security considerations specified in [RFC3338].
10. References
10.1 Normative References
[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.
[RFC2460] Deering, S., and R., Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack
Hosts using the "Bump-In-the-Stack" Technique (BIS)",
RFC 2767, February 2000.
[I-D.draft-huang-behave-rfc3338bis]
Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts
Using "Bump-in-the-API" (BIA)",
draft-huang-behave-rfc3338bis-02 (work in progress),
March 2010.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",BCP 5,
RFC 1918, February 1996.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[I-D.draft-ietf-behave-address-format]
Huitema, C., "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-10 (work in progress),
August 2010.
Hamarsheh & Goossens Expires July 23, 2011 [Page 27]
Internet-Draft BIAv2 January 2011
[I-D.draft-huang-behave-pnat]
Huang, B., and H., Deng, "Prefix NAT: Host based IPv6
translation", draft-huang-behave-pnat-01 (work in
progress), February 2010.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-
stateful-12 (work in progress), July 2010.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in
progress), September 2010.
10.2 Informative References
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003.
Hamarsheh & Goossens Expires July 23, 2011 [Page 28]
Internet-Draft BIAv2 January 2011
Authors' Addresses
Ala Hamarsheh
Electronics and Informatics Department ETRO/Vrije Universiteit Brussel
Pleinlaan 2, 1050 Elsene, Brussels, Belgium
Tel: +32 2 629 2930
Fax: +32 2 629 2883
Email: ala.hamarsheh@vub.ac.be
Prof. Marnix Goossens
Electronics and Informatics Department ETRO/Vrije Universiteit Brussel
Pleinlaan 2, 1050 Elsene, Brussels, Belgium
Tel: +32 2 629 2987
Fax: +32 2 629 2883
Email: marnix.goossens@vub.ac.be
Hamarsheh & Goossens Expires July 23, 2011 [Page 29]
