draft-ietf-behave-v4v6-bih-02.txt   draft-ietf-behave-v4v6-bih-03.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: July 27, 2011 January 23, 2011 Expires: September 12, 2011 March 11, 2011
Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
draft-ietf-behave-v4v6-bih-02 draft-ietf-behave-v4v6-bih-03
Abstract Abstract
Bump-In-the-Host (BIH) is a host based IPv4 to IPv6 protocol Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol
translation mechanism that allows class of IPv4-only applications translation mechanism that allows a class of IPv4-only applications
that work through NATs to communicate with IPv6-only peers. The host that work through NATs to communicate with IPv6-only peers. The host
applications are running on may be connected to IPv6-only or dual- on which applications are running may be connected to IPv6-only or
stack access networks. BIH hides IPv6 and makes the IPv4-only dual-stack access networks. BIH hides IPv6 and makes the IPv4-only
applications think they are talking with IPv4 peers by local applications think they are talking with IPv4 peers by local
synthetization of A records. synthesis of IPv4 addresses.
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
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 July 27, 2011. This Internet-Draft will expire on September 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 11 skipping to change at page 3, line 11
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 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. Protocol translator . . . . . . . . . . . . . . . . . . . 8
2.3. Extension Name Resolver . . . . . . . . . . . . . . . . . 8 2.3. Extension Name Resolver . . . . . . . . . . . . . . . . . 8
2.3.1. Special exclusion sets for A and AAAA records . . . . 9 2.3.1. Special exclusion sets for A and AAAA records . . . . 9
2.3.2. DNSSEC support . . . . . . . . . . . . . . . . . . . . 9 2.3.2. DNSSEC support . . . . . . . . . . . . . . . . . . . . 9
2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 9 2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 9
2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 10 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. Changes since RFC2767 and RFC3338 . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Implementation option for the ENR . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 22 Appendix A. Implementation option for the ENR . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document describes a Bump-in-the-Host (BIH), successor and This document describes Bump-in-the-Host (BIH), a successor and
combination of Bump-in-the-Stack (BIS)[RFC2767] and Bump-in-the-API combination of the Bump-in-the-Stack (BIS)[RFC2767] and Bump-in-the-
(BIA) [RFC3338] technologies, which enables IPv4-only legacy API (BIA) [RFC3338] technologies, which enable IPv4-only legacy
applications to communicate with IPv6-only servers by synthesizing A applications to communicate with IPv6-only servers by synthesizing
records from AAAA records. IPv4 addresses from AAAA records.
The supported class of applications includes those that use DNS for The supported class of applications includes those that use DNS for
IP address resolution and that do not embed IP address literals in IP address resolution and that do not embed IP address literals in
protocol payloads. This essentially includes legacy client-server protocol payloads. This essentially includes legacy client-server
applications using the DNS that are agnostic to the IP address family applications using the DNS that are agnostic to the IP address family
used by the destination and that are able to do NAT traversal. The used by the destination and that are able to do NAT traversal. The
synthetic IPv4 addresses shown to applications are taken from RFC1918 synthetic IPv4 addresses shown to applications are taken from the
private address pool in order to ensure possible NAT traversal RFC1918 private address pool in order to ensure that possible NAT
techniques will be initiated. traversal techniques will be initiated.
IETF recommends using dual-stack or tunneling based solutions for IETF recommends using dual-stack or tunneling based solutions for
IPv6 transition and specifically recommends against deployments IPv6 transition and specifically recommends against deployments
utilizing double protocol translation. Use of BIH together with a utilizing double protocol translation. Use of BIH together with a
network-side IP translation is NOT RECOMMENDED as a competing NAT64 is NOT RECOMMENDED as a competing technology for tunneling
technology for tunneling based transition solutions. based transition solutions.
BIH technique includes two major implementation options: a protocol BIH includes two major implementation options: a protocol translator
translator between the IPv4 and the IPv6 stacks of a host or API between the IPv4 and the IPv6 stacks of a host, or an API translator
translator between the IPv4 socket API module and the TCP/IP module. between the IPv4 socket API module and the TCP/IP module.
Essentially, IPv4 is translated into IPv6 at the socket API layer or Essentially, IPv4 is translated into IPv6 at the socket API layer or
at the IP layer. at the IP layer.
When the BIH is implemented at the socket API layer the translator When BIH is implemented at the socket API layer, the translator
intercepts IPv4 socket API function calls and invokes corresponding intercepts IPv4 socket API function calls and invokes corresponding
IPv6 socket API function calls to communicate with the IPv6 hosts. IPv6 socket API function calls to communicate with IPv6 hosts.
When the BIH is implemented at the networking layer the IPv4 packets When BIH is implemented at the networking layer the IPv4 packets are
are intercepted and converted to IPv6 using the IP conversion intercepted and converted to IPv6 using the IP conversion mechanism
mechanism defined in SIIT [I-D.ietf-behave-v6v4-xlate]. The protocol defined in Stateless IP/ICMP Translation Algorithm (SIIT)
layer translation has the same benefits and drawbacks as SIIT. [I-D.ietf-behave-v6v4-xlate]. The protocol translation has the same
benefits and drawbacks as SIIT.
The BIH can be used whenever an IPv4-only application needs to The location of the BIH refers essentially to the location of the
protocol translation function. The location of DNS synthesis is
orthogonal to the location of protocol translation, and may or may
not happen at the same level.
BIH can be used whenever an IPv4-only application needs to
communicate with an IPv6-only server, independently of the address communicate with an IPv6-only server, independently of the address
families supported by the access network. Hence the access network families supported by the access network. Hence the access network
can be IPv6-only or dual-stack capable. can be IPv6-only or dual-stack capable.
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 1.1. Acknowledgement of previous work
This document is direct update to and directly derivative from This document is a direct update to and directly derivative from
Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's Bump-
[RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain in-the-Stack [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin
Durand, and Erik Nordmark's [RFC3338], which similarly provides a Kim, Alain Durand, and Erik Nordmark's Bump-in-the-API [RFC3338],
dual stack host means to communicate with other IPv6 host using which similarly provide a dual stack host means to communicate with
existing IPv4 appliations. other IPv6 hosts using existing IPv4 applications.
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 a host in which BIH is implemented
implemented as socket API layer translator, i.e. as the original as a socket API layer translator, i.e., as a "Bump-in-the-API".
"Bump-in-the-API".
+----------------------------------------------+ +----------------------------------------------+
| +------------------------------------------+ | | +------------------------------------------+ |
| | | | | | | |
| | IPv4 applications | | | | IPv4 applications | |
| | | | | | | |
| +------------------------------------------+ | | +------------------------------------------+ |
| +------------------------------------------+ | | +------------------------------------------+ |
| | Socket API (IPv4, IPv6) | | | | Socket API (IPv4, IPv6) | |
| +------------------------------------------+ | | +------------------------------------------+ |
skipping to change at page 6, line 33 skipping to change at page 6, line 32
| | | Resolver | | Mapper | | Mapper | | | | | | Resolver | | Mapper | | Mapper | | |
| | +-----------+ +---------+ +------------+ | | | | +-----------+ +---------+ +------------+ | |
| +------------------------------------------+ | | +------------------------------------------+ |
| +--------------------+ +-------------------+ | | +--------------------+ +-------------------+ |
| | | | | | | | | | | |
| | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | |
| | | | | | | | | | | |
| +--------------------+ +-------------------+ | | +--------------------+ +-------------------+ |
+----------------------------------------------+ +----------------------------------------------+
Figure 1: Architecture of the dual stack host using BIH at socket Figure 1: Architecture of a dual stack host using protocol
layer translation at socket layer
Figure 2 shows the architecture of the host in which BIH is Figure 2 shows the architecture of a host in which BIH is implemented
implemented as network layer translator, i.e. as the original "Bump- as a network layer translator, i.e., a "Bump-in-the-Stack".
in-the-Stack".
+-------------------------------------------------------------+ +------------------------------------------------------------+
| +-------------------------------------------------------+ | | +------------------------------------------+ |
| | IPv4 applications | | | | IPv4 applications | |
| +-------------------------------------------------------+ | | | Host's main DNS resolver | |
| +-------------------------------------------------------+ | | +------------------------------------------+ |
| | TCP/IPv4 | | | +------------------------------------------+ |
| | +---------------------------------------------------+ | | | TCP/UDP | |
| | | +-----------+ +---------+ +---------------+ | | +------------------------------------------+ |
| | | | Extension | | Address | | Translator | | | +------------------------------------------+ +---------+ |
| | | | Name | | Mapper | +---------------+ | | | IPv4 | | | |
| | | | Resolver | | | +---------------+ | | +------------------------------------------+ | Address | |
| | | | | | | | IPv6 | | | +------------------+ +---------------------+ | Mapper | |
| +---+ +-----------+ +---------+ +---------------+ | | | Protocol | | Extension Name | | | |
| +-------------------------------------------------------+ | | | Translator | | Resolver | | | |
| | Network card drivers | | | +------------------+ +---------------------+ | | |
| +-------------------------------------------------------+ | | +------------------------------------------+ | | |
+-------------------------------------------------------------+ | | IPv4 / IPv6 | | | |
+-------------------------------------------------------------+ | +------------------------------------------+ +---------+ |
| Network cards | +------------------------------------------------------------+
+-------------------------------------------------------------+
Figure 2: Architecture of the dual-stack host using BIH at network Figure 2: Architecture of a dual-stack host using protocol
layer translation at the network layer
Dual stack hosts defined in RFC2893 [RFC2893] need applications, Dual stack hosts defined in RFC 2893 [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 IPv6-only peers using existing IPv4 applications. allow existing IPv4 applications to communicate with IPv6-only peers.
The BIH translator consists of an Extension Name Resolver, an Address The BIH architecture consists of an Extension Name Resolver, an
Mapper, and depending on implementation either a Function Mapper or a Address Mapper, and depending on implementation either a Function
Protocol Translator. Mapper or a Protocol Translator. It is worth noting that Extension
Name Resolver's placement is orthogonal decision to placement of
protocol translation. For example, the Extension Name Resolver may
reside in the socket API while protocol translation takes place at
the networking layer.
2.1. Function Mapper 2.1. Function Mapper
Function mapper translates an IPv4 socket API function into an IPv6 The function mapper translates an IPv4 socket API function into an
socket API function, and vice versa. IPv6 socket API function.
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 IPv6 socket the function mapper intercepts the function calls and invokes IPv6
API functions which correspond to the IPv4 socket API functions. The socket API functions that correspond to the IPv4 socket API
IPv6 API functions are used to communicate with the target IPv6 functions.
peers. When detecting IPv6 socket API function calls triggered by
the data received from the IPv6 peers, function mapper works
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
Translator translates IPv4 into IPv6 and vice versa using the IP See Appendix B for a list of functions that MUST be intercepted by
conversion mechanism defined in SIIT [I-D.ietf-behave-v6v4-xlate]. the function mapper.
When receiving IPv4 packets from IPv4 applications, translator 2.2. Protocol translator
converts IPv4 packet headers into IPv6 packet headers, then, if
required, fragments the IPv6 packets (because header length of IPv6
is typically 20 bytes larger than that of IPv4), and sends them to
IPv6 networks. When receiving IPv6 packets from the IPv6 networks,
translator works symmetrically to the previous case, except that
there is no need to fragment the packets.
The translator module has to adjust transport protocol checksums when The protocol translator translates IPv4 into IPv6 and vice versa
translating between IPv4 and IPv6. In the IPv6 to IPv4 direction the using the IP conversion mechanism defined in SIIT
translator also has to calculate IPv4 header checksum. [I-D.ietf-behave-v6v4-xlate]. To avoid unnecessary fragmentation,
host's IPv4 module should be configured with small enough MTU (IPv6
link MTU - 20 bytes).
2.3. Extension Name Resolver 2.3. Extension Name Resolver
Extension Name Resolver returns a proper answer in response to the The Extension Name Resolver (ENR) returns a proper answer in response
IPv4 application's name resolution request. to the IPv4 application's name resolution request.
In the case of socket API layer implementation option, when an IPv4 In the case of the socket API layer implementation option, when an
application tries to do forward lookup to resolve names via the IPv4 application tries to do a forward lookup to resolve names via
resolver library (e.g. gethostbyname()), BIH intercept the function the resolver library (e.g., gethostbyname()), BIH intercepts the
call and instead calls the IPv6 equivalent functions (e.g. function call and instead calls the IPv6 equivalent functions (e.g.,
getnameinfo()) that will resolve both A and AAAA records. getnameinfo()) that will resolve both A and AAAA records. This
implementation option is name resolution protocol agnostic, and hence
supports techniques such as "hosts-file", NetBIOS, mDNS, and
essentially anything underlying operating system uses.
In the case of stack layer implementation option the ENR intercepts In the case of the network layer implementation option, the ENR
the A query and creates additional AAAA query with essentially the intercepts the A query and creates an additional AAAA query with
same content. The ENR will then collect replies to both A and AAAA essentially the same content. The ENR will then collect replies to
queries and depending on results either returns A reply unmodified or both A and AAAA queries and, depending on results, either return an A
drops the real A reply and synthesizes a new A reply. reply unmodified or synthesize a new A reply. The network layer
implementation option will only be able to catch applications' name
resolution requests that result in actual DNS queries, hence is more
limited when compared to socket API layer implementation option.
In either implementation options, if only non-excluded AAAA records In either implementation option, if only AAAA records are available
are available for the queried name, ENR requests the address mapper for the queried name, the ENR asks the address mapper to assign a
to assign a local IPv4 address corresponding to the IPv6 address(es). local IPv4 address corresponding to each IPv6 address. In the case
In the case of API layer implementation option the ENR will simply of the API layer implementation option, the ENR will simply the make
make API (e.g. gethostbyname) to return the synthetic address. In API (e.g. gethostbyname) return the synthetic address. In the case
the case of network layer implementation option ENR synthesizes an A of the network-layer implementation option, the ENR synthesizes an A
record for the assigned IPv4 address, and returns the A record to the record for the assigned IPv4 address, and delivers it up the stack.
IPv4 application.
If there is real, non-excluded, A record available, ENR SHOULD NOT If there is a real A record available, the ENR SHOULD NOT synthesize
synthetize IPv4 addresses to be given to the application. By default IPv4 addresses. By default an ENR implementation MUST NOT synthesize
ENR implementation MUST NOT synthesize IPv4 addresses when real A IPv4 addresses when real A records exist.
records exist.
If the response contains a CNAME or a DNAME record, then the CNAME or If the response contains a CNAME or a DNAME record, then the CNAME or
DNAME chains is followed until the first terminating A or AAAA record DNAME chain is followed until the first terminating A or AAAA record
is reached. is reached.
Application | Network | ENR behaviour Application | Network | ENR behavior
query | response | query | response |
------------+----------+------------------------ ------------+----------+------------------------
A | A | <return real A record> A | A | <return real A record>
A | AAAA | <synthesize A record> A | AAAA | <synthesize A record>
A | A/AAAA | <return real A record> A | A/AAAA | <return real A record>
Figure 3: ENR behaviour illustration Figure 3: ENR behavior illustration
2.3.1. Special exclusion sets for A and AAAA records 2.3.1. Special exclusion sets for A and AAAA records
ENR implementation MAY by default exclude certain IPv4 and IPv6 An ENR implementation MAY by default exclude certain IPv4 and IPv6
addresses seen on received A and AAAA records. The addresses to be addresses seen on received A and AAAA records. The addresses to be
excluded by default SHOULD include martian addresses such as those excluded by default SHOULD include martian addresses such as those
that should not appear in the DNS or on the wire. Additional that should not appear in the DNS or on the wire. Additional
addresses MAY be excluded based on possibly configurable local addresses MAY be excluded based on possibly configurable local
policies. policies.
2.3.2. DNSSEC support 2.3.2. DNSSEC support
The A record synthesis done by ENR in the network layer model can When the ENR is implemented at the network layer, the A record
cause problems for DNSSEC validation possibly done by the host's synthesis can cause essentially the same issues as are described in
resolver, as the synthetic responses cannot be succesfully validated. [I-D.ietf-behave-dns64] section 3. To avoid unwanted discarding of
DNSSEC can be supported by configuring the (stub) resolver on a host synthetic A records on the host's main resolver, the host's main
to trust validations done by the local ENR or alternatively the resolver MUST send DNS questions with the CD "Checking Disabled" bit
validating resolver can implement ENR on itself and only SIIT takes cleared. The ENR can support DNSSEC as any resolver on a host.
place at network layer.
When ENR is implemented at the socket API level there is no problems When the ENR is implemented at the socket API level, there are no
with DNSSEC, as the ENR itself uses socket APIs. problems with DNSSEC, as the ENR itself uses socket APIs for DNS
resolution.
DNSSEC can also be supported by configuring the (stub) resolver on a
host to trust validations done by the ENR located at network layer or
alternatively the validating resolver can implement ENR on itself.
In order to properly support DNSSEC, the ENR SHOULD be implemented at
the socket API level. If the socket API level implementation is not
possible, DNSSEC support SHOULD be provided by other means.
2.3.3. Reverse DNS lookup 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 to find a name for an IP address, the ENR MUST check whether the
whether the queried IP address can be found in the Address Mapper's queried IP address can be found in the Address Mapper's mapping table
mapping table and is a local IP address. If an entry is found and and is a local IP address. If an entry is found and the queried
the queried address is locally generated, the ENR must initiate address is locally generated, the ENR MUST initiate a corresponding
corresponding reverse DNS query for the real IPv6 address (ip6.arpa). reverse DNS query for the real IPv6 address. In the case application
In the case application requested reverse lookup for an address not requested reverse lookup for an address not part of the local IPv4
part of the local IPv4 address pool, e.g. a global address, the address pool, e.g., a global address, the request MUST be forwarded
request shall be forwarded unmodified to the network. unmodified to the network.
For example, when an application initiates reverse DNS query for a For example, when an application initiates a 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 asks 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 a
lookup procedure for the destination's IPv6 address and return the reverse lookup procedure for the destination's IPv6 address and
name received as a response to the application that initiated the return the name received as a response to the application that
IPv4 query. initiated the IPv4 query.
2.4. Address Mapper 2.4. Address Mapper
Address mapper maintains a local IPv4 address pool. The pool The address mapper maintains a local IPv4 address pool. The pool
consists of private IPv4 addresses as per section 4.3. Also, the consists of private IPv4 addresses as per section 4.3. Also, the
address mapper maintains a table consisting of pairs of locally address mapper maintains a table consisting of pairs of locally
selected IPv4 addresses and destinations' IPv6 addresses. selected IPv4 addresses and destinations' IPv6 addresses.
When the extension name resolver, translator, or the function mapper When the extension name resolver, translator, or the function mapper
requests the address mapper to assign an IPv4 address corresponding requests the address mapper to assign an IPv4 address corresponding
to an IPv6 address, the address mapper selects and returns an IPv4 to an IPv6 address, the address mapper selects and returns an IPv4
address out of the local pool, and registers a new entry into the address out of the local pool, and registers a new entry into the
table. The registration 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 the (1) When the extension name resolver gets only AAAA records for the
target host name in the dual stack or IPv6 only network and there is target host name in the dual stack or IPv6-only network and there is
no existing mapping entry for the IPv6 address. A local IPv4 address no existing mapping entry for the IPv6 addresses. One or more local
will be returned to application and mapping for local IPv4 address to IPv4 addresses will be returned to application and mappings for local
real IPv6 address is created. IPv4 addresses to real IPv6 addresses are created.
(2) When the extension name resolver gets both an A record and an (2) When the extension name resolver gets both A records and AAAA
AAAA record, but the A record contains only excluded IPv4 addresses. records, but the A records contain only excluded IPv4 addresses.
Behavior will follow the case (1). Behavior will follow the case (1).
(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 a 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 (for example, client sent UDP
happen in case of client-server nature of BIH?). request to anycast address but response was received from unicast
address).
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
registers a pair of its own IPv4 address and IPv6 address into the
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 a 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 the IPv6-only Internet
is talking to IPv6-only server. A communication is made possible by and is talking to an IPv6-only server. Communication is made
Bump-In-the-Host. possible by Bump-In-the-Host.
+----+ +-------------+ +----+ +-------------+
| 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
application is running on a host attached to a dual-stack network, application is running on a host attached to a dual-stack network,
but the destination server is running on a private site that is but the destination server is running on a private site that is
numbered with public IPv6 addresses and private IPv4 addresses numbered with public IPv6 addresses and private IPv4 addresses
without port forwarding setup on NAT44. The only means to contact to without port forwarding setup on the NAT44. The only means to
server is to use IPv6. contact the server is to use IPv6.
+----------------------+ +------------------------------+ +----------------------+ +------------------------------+
| Dual Stack Internet | | IPv4 Private site (Net 10) | | Dual Stack Internet | | IPv4 Private site (Net 10) |
| | | | | | | |
| | | +----------+ | | | | +----------+ |
| | | | | | | | | | | |
| +----+ +---------+ | | | | +----+ +---------+ | | |
| | H1 |-------- | NAT44 |-------------| Server | | | | H1 |-------- | NAT44 |-------------| Server | |
| +----+ +---------+ | | | | +----+ +---------+ | | |
| v4 only | | +----------+ | | v4 only | | +----------+ |
| application | | Dual Stack | | application | | Dual Stack |
| | | etc. 10.1.1.1 | | | | 10.1.1.1 |
| | | AAAA:2009::1 | | | | AAAA:2009::1 |
| | | | | | | |
+----------------------+ +------------------------------+ +----------------------+ +------------------------------+
Figure 5: Network Scenario #2 Figure 5: Network Scenario #2
Illustrations of host behavior in both implementation options are Illustrations of host behavior in both implementation options are
given here. Figure 6 illustrates the setup where BIH is implemented given here. Figure 6 illustrates the setup where BIH is implemented
as a bump in the API, and figure 7 illustrates the setup where BIH is as a bump in the API, and figure 7 illustrates the setup where BIH is
implemented as a bump in the stack. implemented as a bump in the stack.
"dual stack" "host6" "dual stack" "host6"
IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name
appli- API | ENR Address Function| (v6/v4) Server appli- API | ENR Address Function| (v6/v4) Server
cation | Mapper Mapper | cation | Mapper Mapper |
| | | | | | | | | | | | | | | |
<<Resolve an IPv4 address for "host6".>> | | | <<Resolve an IPv4 address for "host6".>> | | |
| | | | | | | | | | | | | | | |
|--------|------->| Query of 'A' records for host6. | | |------->|------->| Query of IPv4 address for host6. | |
| | | | | | | | | | | | | | | |
| | |--------|--------|---------|--------------|------>| | | |------------------------------------------------->|
| | | Query of 'A' records and 'AAAA' for host6 | | | | Query of 'A' records and 'AAAA' for host6 |
| | | | | | | | | | | | | | | |
| | |<-------|--------|---------|--------------|-------| | | |<-------------------------------------------------|
| | | Reply with the 'AAAA' record. | | | | | Reply with the 'AAAA' record. | |
| | | | | | | | | | | | | |
| | |<<The 'AAAA' record is resolved.>> | | | |<<The 'AAAA' record is resolved.>> |
| | | | | | | | | | | | | |
| | |+++++++>| Request one IPv4 address | | | |+++++++>| Request one IPv4 address |
| | | | corresponding to the IPv6 address. | | | | corresponding to the IPv6 address.
| | | | | | | | | | | | | |
| | | |<<Assign one IPv4 address.>> | | | | |<<Assign one IPv4 address.>> |
| | | | | | | | | | | | | |
| | |<+++++++| Reply with the IPv4 address. | | | |<+++++++| Reply with the IPv4 address. |
| | | | | | | | | | | | | |
| | |<<Create 'A' record for the IPv4 address.>> |<-------|<-------| Reply with the IPv4 address |
| | | | | | |
|<-------|--------| Reply with the 'A' record.| |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
<<Call IPv4 Socket API function >> | | | <<Call IPv4 Socket API function >> | | |
| | | | | | | | | | | | | |
|========|========|========|=======>|An IPv4 Socket API function Call |=======>|=========================>|An IPv4 Socket API function call
| | | | | | | | | | | | | |
| | | |<+++++++| Request IPv6 addresses| | | | |<+++++++| Request IPv6 addresses|
| | | | | corresponding to the | | | | | | corresponding to the |
| | | | | IPv4 addresses. | | | | | | IPv4 addresses. |
| | | | | | | | | | | | | |
| | | |+++++++>| Reply with the IPv6 addresses. | | | |+++++++>| Reply with the IPv6 addresses.
| | | | | | | | | | | | | |
| | | | |<<Translate IPv4 into IPv6.>> | | | | |<<Translate IPv4 into IPv6.>>
| | | | | | | | | | | | | |
| An IPv6 Socket API function call.|=========|=============>| | An IPv6 Socket API function call.|=======================>|
| | | | | | | | | | | | | |
| | | | |<<Reply an IPv6 data | | | | | |<<IPv6 data received |
| | | | | to dual stack.>> | | | | | | from network.>> |
| | | | | | | | | | | | | |
| An IPv6 Socket API function call.|<========|==============| | An IPv6 Socket API function call.|<=======================|
| | | | | | | | | | | | | |
| | | | |<<Translate IPv6 into IPv4.>> | | | | |<<Translate IPv6 into IPv4.>>
| | | | | | | | | | | | | |
| | | |<+++++++| Request IPv4 addresses| | | | |<+++++++| Request IPv4 addresses|
| | | | | corresponding to the | | | | | | corresponding to the |
| | | | | IPv6 addresses. | | | | | | IPv6 addresses. |
| | | | | | | | | | | | | |
| | | |+++++++>| Reply with the IPv4 addresses. | | | |+++++++>| Reply with the IPv4 addresses.
| | | | | | | | | | | | | |
|<=======|========|========|========| An IPv4 Socket function call. |<=======|<=========================| An IPv4 Socket function call.
| | | | | | | | | | | | | |
Figure 6: Example of BIH as API addition Figure 6: Example of BIH as API addition
"dual stack" "host6" "dual stack" "host6"
IPv4 TCP/ ENR address translator IPv6 IPv4 stub TCP/ ENR address translator IPv6
appli- IPv4 mapper app res. IPv4 mapper
cation | | | | | | | |
| | | | | | | <<Resolve an IPv4 address for "host6".>> | |
<<Resolve an IPv4 address for "host6".>> | | |-->| | | | | | |
| | | | | | | | |----------->| Query of 'A' records for "host6". | Name
|------|------>| Query of 'A' records for "host6". | Name | | | | | | | | Server
| | | | | | | Server | | | |------------------------------------------->|
| | |---------|-------|-----------|---------|--->| | | | | Query of 'A' records and 'AAAA' for "host6"
| | | Query of 'A' records and 'AAAA' for "host6" | | | | | | | | |
| | | | | | | | | | | |<-------------------------------------------|
| | |<--------|-------|-----------|---------|----| | | | | Reply only with 'AAAA' record. |
| | | Reply only with 'AAAA' record. | | | | | | | | |
| | | | | | | | | | |<<Only 'AAAA' record is resolved.>> |
| | |<<Only 'AAAA' record is resolved.>> | | | | | | | | |
| | | | | | | | | | |-------->| Request one IPv4 address |
| | |-------->| Request one IPv4 address | | | | | | corresponding to each IPv6 address.
| | | | corresponding to the IPv6 address. | | | | | | | |
| | | | | | | | | | | |<<Assign IPv4 addresses.>> |
| | | |<<Assign one IPv4 address.>> | | | | | | | | |
| | | | | | | | | | |<--------| Reply with the IPv4 address.
| | |<--------| Reply with the IPv4 address. | | | | | | | |
| | | | | | | | | | |<<Create 'A' record for the IPv4 address.>>
| | |<<Create 'A' record for the IPv4 address.>> | | | | | | | |
| | | | | | | | |<-----------| Reply with the 'A' record. | |
|<-----|-------| Reply with the 'A' record. | | | | | | | | | |
| | | | | | | |<--|<<Reply with the IPv4 address | | |
| | | | | | | | | | | | | | |
<<Send an IPv4 packet to "host6".>>| | | <<Send an IPv4 packet to "host6".>>| | |
| | | | | | | | | | | | | | |
|======|=======|=========|======>| An IPv4 packet. | |=======>|========================>| An IPv4 packet. |
| | | | | | | | | | | | | | |
| | | |<------| Request IPv6 addresses | | | | |<------| Request IPv6 addresses
| | | | | corresponding to the IPv4 | | | | | | corresponding to the IPv4
| | | | | addresses. | | | | | | | addresses. |
| | | | | | | | | | | | | | |
| | | |------>| Reply with the IPv6| | | | | |------>| Reply with the IPv6|
| | | | | addresses. | | | | | | | addresses. |
| | | | | | | | | | | | | | |
| | | | |<<Translate IPv4 into IPv6.>> | | | | | |<<Translate IPv4 into IPv6.>>
| | | | | | | | | | | | | | |
| | |An IPv6 packet. |===========|========>| | | | |An IPv6 packet. |==========>|========>|
| | | | | | | | | | | | | | |
| | | | <<Reply an IPv6 packet to | | | | | <<Reply with an IPv6 packet to.>>
| | | | "dual stack".>> | | | | | | | | |
| | | | | | | | | | |An IPv6 packet. |<==========|<========|
| | |An IPv6 packet. |<==========|=========| | | | | | | | |
| | | | | | | | | | | | |<<Translate IPv6 into IPv4.>>
| | | | |<<Translate IPv6 into IPv4.>> | | | | | | | |
| | | | | | | |<=======|=========================| An IPv4 packet. |
|<=====|=======|=========|=======| An IPv4 packet. | | | | | | | | |
| | | | | | |
Figure 7: Example of BIH at network layer Figure 7: Example of BIH at the 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 IPv6 socket API
IPv6 socket API functions as possible and vice versa. See Appendix B functions that are semantically as identical as possible and vice
for the API list intercepted by BIH. However, IPv4 socket API versa. See Appendix B for the API list intercepted by BIH. However,
functions are not fully compatible with IPv6 since the IPv6 has new IPv4 socket API functions are not fully compatible with IPv6 since
advanced features, but IPv4-only application are unlikely to need IPv4 supports features that are not present in IPv6, such as
them. SO_BROADCAST.
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 the 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. [I-D.ietf-behave-v6v4-xlate], and vice versa.
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 granularities
the node e.g., a single pool per node, or at some finer granularity in the node, e.g., a single pool per node, or at some finer
such as per user or per process. In he case of large number of IPv4 granularity such as per-user or per-process. In the case of a large
applications would communicate with large number of IPv6 servers, the number of IPv4 applications communicating with a large number of IPv6
available address spaces may be exhausted. This should be quite rare servers, the available address space may be exhausted if the
event and changes will decrease as IPv6 support increases. The granularity is not fine enough. This should be a rare event and
possible problem can also mitigated with smart management techniques chances will decrease as IPv6 support increases. The possible
of the address pool. For example, entries with longest inactivity problem can also mitigated with smart management techniques of the
time can be cleared and IPv4 addresess reused for creating new address pool. For example, entries with the longest inactivity time
entries. can be cleared and IPv4 addresses reused for creating new 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 it 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 and 169.254/16 are rejected due to
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 a least commonly
used network number of the RFC1918 address space. Addresses from used portion of the RFC1918 address space. Addresses from 172.16/12
172.16/12 prefix are thought to be less likely to conflict than are thought to be less likely to conflict than addresses from 10/8 or
addresses from 10/8 or 192.168/16 spaces, hence the used IPv4 192.168/16 spaces, hence the RECOMMENDED IPv4 addresses are following
addresses are following (Editor's comment: this is first proposal, (Editor's comment: this is first proposal, educated better guesses
educated better quesses are welcome): are welcome):
Source addresses: 172.21.112.0/30. Source address have to be Source addresses: 172.21.112.0/30. Source addresses have to be
allocated because applications use getsockname() calls and as in the allocated because applications use getsockname() calls and in the BIS
BIS mode an IP address of the IPv4 interface has to be shown (e.g. by mode an IP address of the IPv4 interface has to be shown (e.g., by
'ifconfig'). More than one address is allocated to allow 'ifconfig'). More than one address is allocated to allow
implementation flexibility, e.g. for cases where a host has multiple implementation flexibility, e.g., for cases where a host has multiple
IPv6 interfaces. The source addresses are from different subnet than IPv6 interfaces. The source addresses are from different subnets
destination addresses to ensure applications would not do on-link than destination addresses to that ensure applications would not make
assumptions and would enable NAT traversal functions. on-link assumptions and would instead enable NAT traversal functions.
Primary destination addresses: 172.21.80.0/20. Address mapper will Primary destination addresses: 172.21.80.0/20. The address mapper
select destination addresses primarily out of this pool. will 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. The 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 a
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 NOT do protocol
translation from IPv4 to IPv6 only when the host does not have any translation from IPv4 to IPv6 when the host has any IPv4 interfaces,
IPv4 interfaces, native or tunneled, available for use. 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 an 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 implementations and it may depend on whether IPv4 address conflict
situation occurs between addresses used by BIH and addresses used by occurs between addresses used by BIH and addresses used by the new
new IPv4 interface. 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
When BIH module shuts down, e.g. due IPv4 interface becoming When BIH shuts down, e.g., due to an IPv4 interface becoming
available, BIH must flush node's DNS cache of possible locally available, BIH MUST flush the node's DNS cache of possible locally
generated entries. generated entries. This cache may be in the ENR itself, but also
possibly host's caching stub resolver.
5. Considerations due ALG requirements 5. Considerations due ALG requirements
No ALG functionality is specified herein as ALG design is generally No ALG functionality is specified herein as ALG design is generally
not encouraged for host based translation and as BIH is intended for not encouraged for host-based translation and as BIH is intended for
applications not including IP addresses in protocol payloads. applications that do not include IP addresses in protocol payloads.
6. Security Considerations 6. Security Considerations
The security consideration of BIH mostly relies on that of The security considerations 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 layer, 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 such, 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, IPv4-using IKE will not
security above network layer when they communicate with IPv6 hosts work. This means IPv4-based IPsec/IKE using VPN solutions cannot
using IPv4 applications via BIH and encrypt embedded IP addresses, or work through BIH. However, transport and application layer solutions
when the protocol data is encrypted using IP addresses as keys. In such as TLS or SSL-VPN do work through BIH.
these cases it is impossible for the mechanism to translate the IPv4
data into IPv6 and vice versa. Therefore it is highly desirable to
upgrade to the applications modified into IPv6 for utilizing the
security at communication with IPv6 hosts.
The use of address pooling may open a denial of service attack The use of address pooling may open a denial-of-service attack
vulnerability. So BIH should employ the same sort of protection vulnerability. So BIH should employ the same sort of protection
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. Changes since RFC2767 and RFC3338
This document combines and obsoletes both [RFC2767] and [RFC3338].
The changes in this document mainly reflect the following components:
1. Supporting IPv6-only network connections
2. The IPv4 address pool uses private address instead of reserved
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. Standards track instead of experimental/informational
6. Supporting reverse (PTR) queries
8. 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, Ed Jankiewizh, Marnix Goossens, Ala Christian Vogt, Jan M. Melen, Ed Jankiewizh, Marnix Goossens, Ala
Hamarsheh, and Julien Laganier in reviewing this document are Hamarsheh, Dan Wing, Magnus Westerlun and Julien Laganier in
gratefully acknowledged. reviewing this document are gratefully acknowledged.
Advice from Dan Wing, Dave Thaler and Magnus Westerlund are greatly Special acknowledgements go to Dave Thaler for his extensive review
appreciated and support.
The authors of RFC2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO, The authors of RFC2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO,
Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO. Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO.
The authors of RFC3338 acknowledged implementation contributions by The authors of RFC3338 acknowledged implementation contributions by
Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation
(www.i2soft.net). (www.i2soft.net).
The authors of Bump-in-the-Wire (draft-ietf-biw-00.txt, October The authors of Bump-in-the-Wire (BIW) (draft-ietf-biw-00.txt, October
2006), P. Moster, L. Chin, and D. Green, are acknowledged. Few ideas 2006), P. Moster, L. Chin, and D. Green, are acknowledged. Some
and clarifications from BIW have been adapted to this document. ideas and clarifications from BIW have been adapted to this document.
8. References 9. References
8.1. Normative References 9.1. Normative References
[I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-11 (work in progress),
October 2010.
[I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in
progress), September 2010. progress), September 2010.
[I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", Clients to IPv4 Servers",
skipping to change at page 20, line 42 skipping to change at page 21, line 49
Hosts using the "Bump-In-the-Stack" Technique (BIS)", Hosts using the "Bump-In-the-Stack" Technique (BIS)",
RFC 2767, February 2000. RFC 2767, February 2000.
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000. IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A.
Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)",
RFC 3338, October 2002. RFC 3338, October 2002.
8.2. Informative References 9.2. Informative References
[RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
"Basic Socket Interface Extensions for IPv6", RFC 2553, Stevens, "Basic Socket Interface Extensions for IPv6",
March 1999. RFC 3493, February 2003.
Appendix A. Implementation option for the ENR Appendix A. Implementation option for the ENR
It is not necessary to implement the ENR at the kernel level, but it It is not necessary to implement the ENR at the kernel level, but it
can be implemented instead at the user space by setting the host's can be implemented instead at the user space by setting the host's
default DNS server to point to 127.0.0.1. DNS queries would then default DNS server to point to 127.0.0.1. DNS queries would then
always be sent to the ENR, which furthermore ensures both A and AAAA always be sent to the ENR, which furthermore ensures that both A and
queries are sent to the actual DNS server and A queries are always AAAA queries are sent to the actual DNS server and A queries are
answered and required mappings created. always answered and required mappings created.
Appendix B. API list intercepted by BIH Appendix B. API list intercepted by BIH
The following functions are the API list which SHOULD be intercepted The following functions are the API list which SHOULD be intercepted
by BIH module when implemented at socket layer. by BIH module when implemented at socket layer. Please note that
this list may not be fully exhaustive.
The functions that the application uses to pass addresses into the The functions that the application uses to pass addresses into the
system are: system are:
bind() bind()
connect() connect()
sendmsg() sendmsg()
sendto() sendto()
gethostbyaddr()
getnameinfo()
The functions that return an address from the system to an The functions that return an address from the system to an
application are: application are:
accept() accept()
recvfrom() recvfrom()
recvmsg() recvmsg()
getpeername() getpeername()
getsockname() getsockname()
gethostbyname()
getaddrinfo()
The functions that are related to socket options are: The functions that are related to socket options are:
getsocketopt() getsocketopt()
setsocketopt() setsocketopt()
The functions that are used for conversion of IP addresses embedded
in application layer protocol (e.g., FTP, DNS, etc.) are:
recv()
send()
read()
write()
As well, raw sockets for IPv4 and IPv6 MAY be intercepted. As well, raw sockets for IPv4 and IPv6 MAY be intercepted.
Most of the socket functions require a pointer to the socket address Most of the socket functions require a pointer to the socket address
structure as an argument. Each IPv4 argument is mapped into structure as an argument. Each IPv4 argument is mapped into
corresponding an IPv6 argument, and vice versa. corresponding an IPv6 argument, and vice versa.
According to [RFC2553], the following new IPv6 basic APIs and According to [RFC3493], the following new IPv6 basic APIs and
structures are required. structures are required.
IPv4 new IPv6 IPv4 new IPv6
------------------------------------------------ ------------------------------------------------
AF_INET AF_INET6 AF_INET AF_INET6
sockaddr_in sockaddr_in6 sockaddr_in sockaddr_in6
gethostbyname() getaddrinfo() gethostbyname() getaddrinfo()
gethostbyaddr() getnameinfo() gethostbyaddr() getnameinfo()
inet_ntoa()/inet_addr() inet_pton()/inet_ntop() inet_ntoa()/inet_addr() inet_pton()/inet_ntop()
INADDR_ANY in6addr_any INADDR_ANY in6addr_any
Figure 8 Figure 8
BIH MAY intercept inet_ntoa() and inet_addr() and use the address BIH MAY intercept inet_ntoa() and inet_addr() and use the address
mapper for those. Doing that enables BIH to support literal IP mapper for those. Doing that enables BIH to support literal IP
addresses. addresses.
The gethostbyname() call return a list of addresses. When the name The gethostbyname() and getaddrinfo() calls return a list of
resolver function invokes getaddrinfo() and getaddrinfo() returns addresses. When the name resolver function invokes getaddrinfo() and
multiple IP addresses, whether IPv4 or IPv6, they SHOULD all be getaddrinfo() returns multiple IP addresses, whether IPv4 or IPv6,
represented in the addresses returned by gethostbyname(). Thus if they SHOULD all be represented in the addresses returned by
getaddrinfo() returns multiple IPv6 addresses, this implies that gethostbyname(). Thus if getaddrinfo() returns multiple IPv6
multiple address mappings will be created; one for each IPv6 address. addresses, this implies that multiple address mappings will be
created; one for each IPv6 address.
Authors' Addresses Authors' Addresses
Bill Huang Bill Huang
China Mobile China Mobile
53A,Xibianmennei Ave., 53A,Xibianmennei Ave.,
Xuanwu District, Xuanwu District,
Beijing 100053 Beijing 100053
China China
 End of changes. 97 change blocks. 
359 lines changed or deleted 365 lines changed or added

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