draft-ietf-behave-v4v6-bih-06.txt   draft-ietf-behave-v4v6-bih-07.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: February 11, 2012 August 10, 2011 Expires: June 9, 2012 December 7, 2011
Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
draft-ietf-behave-v4v6-bih-06 draft-ietf-behave-v4v6-bih-07
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 a 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
on which applications are running may be connected to IPv6-only or on which applications are running may be connected to IPv6-only or
dual-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
synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC synthesis of IPv4 addresses. This document obsoletes RFC 2767 and
3338. RFC 3338.
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 February 11, 2012. This Internet-Draft will expire on June 9, 2012.
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 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acknowledgement of previous work . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 8
2.2. Protocol 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 . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 9 2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 10
2.3.4. DNS cache in network-layer ENR . . . . . . . . . . . . 10 2.3.4. DNS caches and locally generated IPv4 addresses . . . 10
2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 10
3. Behavior and Network Examples . . . . . . . . . . . . . . . . 12 3. Behavior and Network Examples . . . . . . . . . . . . . . . . 12
4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 16 4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 16
4.2. Socket bindings . . . . . . . . . . . . . . . . . . . . . 16 4.2. Socket bindings . . . . . . . . . . . . . . . . . . . . . 16
4.3. ICMP Message Handling . . . . . . . . . . . . . . . . . . 16 4.3. ICMP Message Handling . . . . . . . . . . . . . . . . . . 16
4.4. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 16 4.4. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 16
4.5. Multi-interface . . . . . . . . . . . . . . . . . . . . . 17 4.5. Multi-interface . . . . . . . . . . . . . . . . . . . . . 17
4.6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18 4.6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Considerations due ALG requirements . . . . . . . . . . . . . 19 5. Application-Level Gateway requirements considerations . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7.1. Implications on End-to-End Security . . . . . . . . . . . 21 7.1. Implications on End-to-End Security . . . . . . . . . . . 21
7.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Attacks on BIH . . . . . . . . . . . . . . . . . . . . . . 21 7.3. Attacks on BIH . . . . . . . . . . . . . . . . . . . . . . 21
7.4. DNS considerations . . . . . . . . . . . . . . . . . . . . 22 7.4. DNS considerations . . . . . . . . . . . . . . . . . . . . 22
8. Changes since RFC2767 and RFC3338 . . . . . . . . . . . . . . 23 8. Changes since RFC2767 and RFC3338 . . . . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
skipping to change at page 4, line 12 skipping to change at page 4, line 12
Appendix A. API list intercepted by BIH . . . . . . . . . . . . . 27 Appendix A. API list intercepted by BIH . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document describes Bump-in-the-Host (BIH), a successor and This document describes Bump-in-the-Host (BIH), a successor and
combination of the Bump-in-the-Stack (BIS)[RFC2767] and Bump-in-the- combination of the Bump-in-the-Stack (BIS)[RFC2767] and Bump-in-the-
API (BIA) [RFC3338] technologies, which enable IPv4-only legacy API (BIA) [RFC3338] technologies, which enable IPv4-only legacy
applications to communicate with IPv6-only servers by synthesizing applications to communicate with IPv6-only servers by synthesizing
IPv4 addresses from AAAA records. Section 8 describes the reasons IPv4 addresses from AAAA records. Section 8 describes the reasons
for updating RFC2767 and RFC3338. for making RFC2767 and RFC3338 obsolete.
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 includes legacy client-server applications application-protocol payloads. This includes legacy client-server
using the DNS that are agnostic to the IP address family used by the applications using the DNS that are agnostic to the IP address family
destination and that are able to do NAT traversal. The synthetic used by the destination and that are able to do NAT traversal. The
IPv4 addresses shown to applications are taken from the RFC1918 synthetic IPv4 addresses shown to applications are taken from the
private address pool in order to ensure that 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
NAT64 is NOT RECOMMENDED [RFC6180]. NAT64 is NOT RECOMMENDED [RFC6180].
BIH includes two major implementation options: a protocol translator BIH includes two major implementation alternatives: a protocol
between the IPv4 and the IPv6 stacks of a host, or an API translator translator between the IPv4 and the IPv6 stacks of a host, or an API
between the IPv4 socket API module and the TCP/IP module. translator 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, former of which is the recommended implementation
alternative.
When 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 IPv6 hosts. IPv6 socket API function calls to communicate with IPv6 hosts.
When BIH is implemented at the networking layer the IPv4 packets are When BIH is implemented at the network layer the IPv4 packets are
intercepted and converted to IPv6 using the IP conversion mechanism intercepted and converted to IPv6 using the IP conversion mechanism
defined in Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]. defined in Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145].
The protocol translation has the same benefits and drawbacks as SIIT. The protocol translation has the same benefits and drawbacks as SIIT.
The location of the BIH refers to the location of the protocol The location of the BIH refers to the location of the protocol
translation function. The location of DNS synthesis is orthogonal to translation function. The location of the local IPv4 address and DNS
the location of protocol translation, and may or may not happen at A record synthesis function is orthogonal to the location of the
the same level. protocol translation, and may or may not happen at the same location.
BIH can be used whenever an IPv4-only application needs to 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] . [RFC2119] .
This document uses terms defined in [RFC2460] and [RFC4213]. This document uses terms defined in [RFC2460] and [RFC4213].
1.1. Acknowledgement of previous work 1.1. Acknowledgement of previous work
This document is a direct update to and directly derivative from This document is a direct derivative from Kazuaki TSHUCHIYA,
Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's Bump- Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's Bump-in-the-Stack
in-the-Stack [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain
Kim, Alain Durand, and Erik Nordmark's Bump-in-the-API [RFC3338], Durand, and Erik Nordmark's Bump-in-the-API [RFC3338], which
which similarly provide a dual stack host means to communicate with similarly provides IPv4-only applications on dual-stack hosts the
other IPv6 hosts using existing IPv4 applications. Section 7 covers means to operate over IPv6. Section 8 covers the changes since those
the changes since those documents. documents.
2. Components of the Bump-in-the-Host 2. Components of the Bump-in-the-Host
Figure 1 shows the architecture of a host in which BIH is implemented Figure 1 shows the architecture of a host in which BIH is implemented
as a socket API layer translator, i.e., as a "Bump-in-the-API". as a socket API layer translator, i.e., as a "Bump-in-the-API".
+----------------------------------------------+ +----------------------------------------------+
| +------------------------------------------+ | | +------------------------------------------+ |
| | | | | | | |
| | IPv4 applications | | | | IPv4 applications | |
skipping to change at page 7, line 31 skipping to change at page 7, line 31
| | IPv4 / IPv6 | | | | | | IPv4 / IPv6 | | | |
| +------------------------------------------+ +---------+ | | +------------------------------------------+ +---------+ |
+------------------------------------------------------------+ +------------------------------------------------------------+
Figure 2: Architecture of a dual-stack host using protocol Figure 2: Architecture of a dual-stack host using protocol
translation at the network layer translation at the network layer
Dual stack hosts defined in RFC 4213 [RFC4213] need applications, Dual stack hosts defined in RFC 4213 [RFC4213] 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
allow existing IPv4 applications to communicate with IPv6-only peers. allow legacy IPv4 applications to communicate with IPv6-only peers.
The BIH architecture consists of an Extension Name Resolver, an The BIH architecture consists of an Extension Name Resolver, an
Address Mapper, and depending on implementation either a Function Address Mapper, and depending on implementation either a Function
Mapper or a Protocol Translator. It is worth noting that the Mapper or a Protocol Translator. It is worth noting that the
Extension Name Resolver's placement is orthogonal to the placement of Extension Name Resolver's placement is orthogonal to the placement of
protocol translation. For example, the Extension Name Resolver may protocol translation. For example, the Extension Name Resolver may
reside in the socket API while protocol translation takes place at reside in the socket API while protocol translation takes place at
the networking layer. the network layer.
The choice between the socket API and the network layer architectures
varies case by case. While the socket API architecture alternative
is the recommended one, it may not always be possible to choose.
This may be the case, for example, when the used operating system
does not allow modifications to be done for API implementations, but
does allow addition of virtual network interfaces and related
software modules. On the other hand, sometimes it may not be
possible to introduce protocol translators inside the operating
system, but it may be easy to modify implementations behind the API
provided for applications. The choice of architecture also depends
on who is creating implementation of BIH. For example, an
application framework provider, an operating system provider, and a
device vendor may all choose different approaches due their different
positions.
2.1. Function Mapper 2.1. Function Mapper
The function mapper translates an IPv4 socket API function into an The function mapper translates an IPv4 socket API function into an
IPv6 socket API function. IPv6 socket API function.
When detecting IPv4 socket API function calls from IPv4 applications, When detecting IPv4 socket API function calls from IPv4 applications,
the function mapper MUST intercept the function calls and invoke IPv6 the function mapper MUST intercept the function calls and invoke IPv6
socket API functions that correspond to the IPv4 socket API socket API functions that correspond to the IPv4 socket API
functions. functions.
skipping to change at page 8, line 13 skipping to change at page 8, line 28
local synthesis and the address mapping table does not have an entry local synthesis and the address mapping table does not have an entry
mathching the address. mathching the address.
See Appendix A for an informational list of functions that would be See Appendix A for an informational list of functions that would be
appropriate to intercept by the function mapper. appropriate to intercept by the function mapper.
2.2. Protocol translator 2.2. Protocol translator
The protocol translator translates IPv4 into IPv6 and vice versa The protocol translator translates IPv4 into IPv6 and vice versa
using the IP conversion mechanism defined in SIIT [RFC6145]. To using the IP conversion mechanism defined in SIIT [RFC6145]. To
avoid unnecessary fragmentation, the host's IPv4 module should be avoid unnecessary fragmentation, the host's IPv4 module SHOULD be
configured with a small enough MTU (IPv6 link MTU - 20 bytes). configured with a small enough MTU (MTU of the IPv6 enabled link - 20
bytes).
Protocol translation cannot be performed for IPv4 packets sent to the Protocol translation cannot be performed for IPv4 packets sent to the
IPv4 address range used by local synthesis and for which a mapping IPv4 address range used by local synthesis and for which a mapping
table entry does not exist. The implementation SHOULD attempt to table entry does not exist. The implementation SHOULD attempt to
route such packets via IPv4 interfaces instead. route such packets via IPv4 interfaces instead.
2.3. Extension Name Resolver 2.3. Extension Name Resolver
The Extension Name Resolver (ENR) returns an answer in response to The Extension Name Resolver (ENR) returns an answer in response to
the IPv4 application's name resolution request. the IPv4 application's name resolution request.
In the case of the socket API layer implementation option, when an In the case of the socket API layer implementation alternative, when
IPv4 application tries to do a forward lookup to resolve names via an IPv4 application tries to do a forward lookup to resolve names via
the resolver library (e.g., gethostbyname()), BIH intercepts the the resolver library (e.g., gethostbyname()), BIH intercepts the
function call and instead calls the IPv6 equivalent functions (e.g., function call and instead calls the IPv6 equivalent functions (e.g.,
getaddrinfo()) that will resolve both A and AAAA records. This getaddrinfo()) that will resolve both A and AAAA records. This
implementation option is name resolution protocol agnostic, and hence implementation alternative is name resolution protocol agnostic, and
supports techniques such as "hosts-file", NetBIOS, mDNS, and anything hence supports techniques such as "hosts-file", NetBIOS, mDNS, and
else the underlying operating system uses. anything else the underlying operating system uses.
In the case of the network layer implementation option, the ENR In the case of the network layer implementation alternative, the ENR
intercepts the A query and creates an additional AAAA query with intercepts the A query and creates an additional AAAA query with
similar content. The ENR will then collect replies to both A and similar content. The ENR will then collect replies to both A and
AAAA queries and, depending on results, either return an A reply AAAA queries and, depending on results, either return an A reply
unmodified or synthesize a new A reply. The network layer unmodified or synthesize a new A reply. The network layer
implementation option will only be able to catch applications' name implementation alternative will only be able to catch applications'
resolution requests that result in actual DNS queries, hence is more name resolution requests that result in actual DNS queries, hence is
limited when compared to the socket API layer implementation option. more limited when compared to the socket API layer implementation
Hence the socket API layer option is RECOMMENDED. alternative. Hence the socket API layer alternative is RECOMMENDED.
In either implementation option, if there is a real IPv4 address In either implementation alternative, if there is a non-excluded IPv4
available, the ENR SHOULD NOT synthesize IPv4 addresses. By default address available, the ENR MUST NOT synthesize IPv4 addresses.
an ENR implementation MUST NOT synthesize IPv4 addresses when real
IPv4 addresses exist.
If only IPv6 addresses are available for the queried name, the ENR The ENR asks the address mapper to assign a local IPv4 address
asks the address mapper to assign a local IPv4 address corresponding corresponding to each received IPv6 address if the A record query
to each IPv6 address. resulted in negative response, all received IPv4 addresses were
excluded, or the A query timed out. The timeout value is
implementation specific and may be short in order to provide good
user experience.
In the case of the API layer implementation option, the ENR will In the case of the API layer implementation alternative, the ENR will
simply make the API (e.g. gethostbyname) return the synthetic simply make the API (e.g. gethostbyname) return the synthetic
address. In the case of the network-layer implementation option, the address. In the case of the network-layer implementation
ENR synthesizes an A record for the assigned IPv4 address, and alternative, the ENR synthesizes an A record for the assigned IPv4
delivers it up the stack. If the response contains a CNAME or a address, and delivers it up the stack. If the response contains a
DNAME record, then the CNAME or DNAME chain is followed until the CNAME or a DNAME record, then the CNAME or DNAME chain is followed
first terminating A or AAAA record is reached. until the first terminating A or AAAA record is reached.
Application | Network | ENR behavior Application | Network | ENR behavior
query | response | query | response |
---------------+-----------------------+---------------------------- ---------------+-----------------------+----------------------------
IPv4 address(es) | IPv4 address(es) | return real IPv4 address(es) IPv4 address(es) | IPv4 address(es) | return real IPv4 address(es)
IPv4 address(es) | IPv6 address(es) | synthesize IPv4 address(es) IPv4 address(es) | IPv6 address(es) | synthesize IPv4 address(es)
IPv4 address(es) | IPv4/IPv6 address(es) | return real IPv4 address(es) IPv4 address(es) | IPv4/IPv6 address(es) | return real IPv4 address(es)
Figure 3: ENR behavior 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
An ENR implementation SHOULD by default exclude certain IPv4 and IPv6 An ENR implementation SHOULD 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 MAY include addresses such as those that should excluded by default MAY include addresses such as those that should
not appear in the DNS or on the wire (see [RFC6147] section 5.1.4 and not appear in the DNS or on the wire (see [RFC6147] section 5.1.4 and
[RFC5735]). Additional addresses MAY be excluded based on possibly [RFC5735]). Additional addresses MAY be excluded based on possibly
configurable local policies. configurable local policies.
2.3.2. DNSSEC support 2.3.2. DNSSEC support
When the ENR is implemented at the network layer, the A record When the ENR is implemented at the network layer, the A record
synthesis can cause similar issues as are described in [RFC6147] synthesis can cause similar issues as are described in [RFC6147]
section 3. The main resolver of a host running BIH SHOULD NOT section 3. While running BIH, the main resolver of the host SHOULD
perform validation of A records, as it will be impossible to validate NOT perform validation of A records as synthetic A records created by
synthetic A records created by ENR. The ENR may support DNSSEC. ENR would fail in validation. While not running BIH, host's resolver
can use DNSSEC in the same way that any other resolver can. The ENR
MAY support DNSSEC, in which case the (stub) resolver on a host can
be configured to trust validations done by the ENR located at the
network layer. In some cases the host's validating stub resolver can
implement the ENR by itself.
When the ENR is implemented at the socket API level, there are no When the ENR is implemented at the socket API level, there are no
issues with DNSSEC use, as the ENR itself uses socket APIs for DNS issues with DNSSEC use, as the ENR itself uses socket APIs for DNS
resolution. This approach is RECOMMENDED. resolution. This approach is RECOMMENDED.
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 the ENR itself.
2.3.3. Reverse DNS lookup 2.3.3. Reverse DNS lookup
When an application requests a reverse lookup for an IPv4 address, When an application requests a reverse lookup for an IPv4 address,
the ENR MUST check whether the queried IPv4 address can be found in the ENR MUST check whether the queried IPv4 address can be found in
the Address Mapper's mapping table and is a local IPv4 address. If the Address Mapper's mapping table and is a local IPv4 address. If
an entry is found and the queried address is locally generated, the an entry is found and the queried address is locally generated, the
ENR MUST initiate a corresponding reverse lookup for the real IPv6 ENR MUST initiate a corresponding reverse lookup for the real IPv6
address. In the case where the application requested a reverse address. In the case where the application requested a reverse
lookup for an address not part of the local IPv4 address pool, e.g., lookup for an address not part of the local IPv4 address pool, e.g.,
a global address, the request MUST be passed on unmodified. a global address, the request MUST be passed on unmodified.
For example, when an application requests a reverse lookup for a For example, when an application requests a reverse lookup 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 asks 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 a that corresponds to the IPv4 address. The ENR shall perform a
reverse lookup procedure for the destination's IPv6 address and reverse lookup procedure for the destination's IPv6 address and
return the name received as a response to the application that return the name received as a response to the application that
initiated the IPv4 query. initiated the IPv4 query.
2.3.4. DNS cache in network-layer ENR 2.3.4. DNS caches and locally generated IPv4 addresses
When BIH shuts down, e.g., due to an IPv4 interface becoming When BIH shuts down or address mapping table entries are cleared for
available, BIH MUST flush the node's DNS cache of possible locally any reason, DNS cache entries for locally generated IPv4 addresses
generated entries. This cache may be in the network-layer ENR MUST be flushed. There may be a DNS cache in the network-layer ENR
itself, but also possibly host's caching stub resolver. itself, but also at the host's stub resolver.
2.4. Address Mapper 2.4. Address Mapper
The 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 per section 4.3. Also, the consists of private IPv4 addresses per section 4.4. 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 three cases:
(1) When the extension name resolver gets only IPv6 addresses for the (1) When the extension name resolver gets only IPv6 addresses for the
target host name and there is no existing mapping entry for the IPv6 target host name and there is no existing mapping entry for the IPv6
addresses. One or more local IPv4 addresses will be returned to the addresses. One or more local IPv4 addresses will be returned to the
application and mappings for local IPv4 addresses to real IPv6 application and mappings for local IPv4 addresses to real IPv6
addresses are created. addresses are created.
(2) When the extension name resolver gets both IPv4 and IPv6 (2) When the extension name resolver gets both IPv4 and IPv6
addresses, but the IPv4 addresses contain only excluded IPv4 addresses, but the IPv4 addresses contain only excluded IPv4
addresses (e.g., 127.0.0.1). The behavior will follow case (1). addresses (e.g., 127.0.0.1). The behavior will follow case (1).
(3) When the function mapper gets a socket API function call (3) When the function mapper is triggered by a received IPv6 packet
triggered by a received IPv6 packet and there is no existing mapping and there is no existing mapping entry for the IPv6 source address
entry for the IPv6 source address (for example, the client sent a UDP (for example, the client sent a UDP request to an anycast address but
request to an anycast address but a response was received from a a response was received from a unicast address).
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.
3. Behavior and Network Examples 3. Behavior and Network Examples
Figure 4 illustrates a 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 the IPv6-only Internet application is running on a host attached to the IPv6-only Internet
and is talking to an IPv6-only server. Communication is made and is talking to an IPv6-only server. Communication is made
possible by Bump-In-the-Host. possible by Bump-In-the-Host.
skipping to change at page 12, line 44 skipping to change at page 12, line 44
| +----+ | +-----------+ | | | | +----+ | +-----------+ | | |
| v4 only +-|IPv6 Router|-----------+ | | | v4 only +-|IPv6 Router|-----------+ | |
| application +-----------+ +----------+ | | application +-----------+ +----------+ |
| | | Dual Stack | | | | Dual Stack |
| | | 10.1.1.1 | | | | 10.1.1.1 |
| | | 2001:DB8::1 | | | | 2001:DB8::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 alternatives
given here. Figure 6 illustrates a setup where BIH (including the are given here. Figure 6 illustrates a setup where BIH (including
ENR) is implemented at the sockets API layer, and Figure 7 the ENR) is implemented at the sockets API layer, and Figure 7
illustrates a setup where BIH (including the ENR) is implemented at illustrates a setup where BIH (including the ENR) is implemented at
the network layer. the network layer.
"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 IPv4 addresses for "host6".>> | | | <<Resolve IPv4 addresses for "host6".>> | | |
| | | | | | | | | | | | | | | |
skipping to change at page 13, line 34 skipping to change at page 13, line 34
| | | | | | | | | | | | | |
| | | |<<Assign one IPv4 address.>> | | | | |<<Assign one IPv4 address.>> |
| | | | | | | | | | | | | |
| | |<+++++++| Reply with the IPv4 address. | | | |<+++++++| Reply with the IPv4 address. |
| | | | | | | | | | | | | |
|<-------|<-------| Reply with the IPv4 address | |<-------|<-------| Reply with the IPv4 address |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
<<Call IPv4 Socket API function >> | | | <<Call IPv4 Socket API function >> | | |
| | | | | | | | | | | | | |
|=======>|=========================>|An IPv4 Socket API function call |=======>|=========================>|An IPv4 Socket API action
| | | | | | | | | | | | | |
| | | |<+++++++| 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 action |=======================>|
| | | | | | | | | | | | | |
| | | | |<<IPv6 data received | | | | | |<<IPv6 data received |
| | | | | from network.>> | | | | | | from network.>> |
| | | | | | | | | | | | | |
| An IPv6 Socket API function call.|<=======================| | An IPv6 Socket API action |<=======================|
| | | | | | | | | | | | | |
| | | | |<<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 API action
| | | | | | | | | | | | | |
Figure 6: Example of BIH as API addition Figure 6: Example of BIH as API addition
"dual stack" "host6" "dual stack" "host6"
IPv4 stub TCP/ ENR address translator IPv6 IPv4 stub TCP/ ENR address translator IPv6
app res. IPv4 mapper app res. IPv4 mapper
| | | | | | | | | | | | | | | |
<<Resolve an IPv4 address for "host6".>> | | <<Resolve an IPv4 address for "host6".>> | |
|-->| | | | | | | |-->| | | | | | |
skipping to change at page 15, line 12 skipping to change at page 15, line 12
| | | | | | 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 with an IPv6 packet to.>> | | | | | <<Reply with an IPv6 packet.>>
| | | | | | | | | | | | | | | |
| | | |An IPv6 packet. |<==========|<========| | | | |An IPv6 packet. |<==========|<========|
| | | | | | | | | | | | | | | |
| | | | | |<<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.
skipping to change at page 16, line 27 skipping to change at page 16, line 27
BIH SHOULD select a source address for a socket from the recommended BIH SHOULD select a source address for a socket from the recommended
source address pool if a socket used for communications has not been source address pool if a socket used for communications has not been
explicitly bound to any IPv4 address. explicitly bound to any IPv4 address.
The binding of an explicitly bound socket MUST NOT be changed by the The binding of an explicitly bound socket MUST NOT be changed by the
BIH. BIH.
4.3. ICMP Message Handling 4.3. ICMP Message Handling
When an application needs ICMP messages values (e.g., Type, Code, ICMPv4 and ICMPv6 messages MUST be translated as defined by SIIT
etc.) sent from the network layer, ICMPv4 message values MAY be [RFC6145]. In the network layer implementation alternative, protocol
translated into ICMPv6 message values based on SIIT [RFC6145], and translator MUST translate ICMPv6 packets to ICMPv4 and vice versa,
vice versa. and in the socket API implementation alternative, the socket API MUST
handle conversions in similar fashion.
4.4. IPv4 Address Pool and Mapping Table 4.4. 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 granularities [RFC1918]. This pool can be implemented at different granularities
in the node, e.g., a single pool per node, or at some finer in the node, e.g., a single pool per node, or at some finer
granularity such as per-user or per-process. In the case of a large granularity such as per-user or per-process. In the case of a large
number of IPv4 applications communicating with a large number of IPv6 number of IPv4 applications communicating with a large number of IPv6
servers, the available address space may be exhausted if the servers, the available address space may be exhausted if the
granularity is not fine enough. This should be a rare event and granularity is not fine enough. This should be a rare event and
chances will decrease as IPv6 support increases. The applications chances will decrease as IPv6 support increases. The applications
may use IPv4 addresses they learn for a much longer period than DNS may use IPv4 addresses they learn for a much longer period than DNS
time-to-live indicates. Therefore, the mapping table entries should time-to-live indicates. Therefore, the mapping table entries should
be kept active for a long period of time. For example, a web browser be kept active for a long period of time. For example, a web browser
may initiate one DNS query and then create multiple TCP sessions over may initiate one DNS query and then create multiple TCP sessions over
time to the address it learns. When address mapping table clean-up time to the address it learns. When address mapping table clean-up
is required the BIH may utilize techniques used by network address is required, the BIH may utilize techniques used by network address
translators, such as described in [RFC2663], [RFC5382], and translators, such as described in [RFC2663], [RFC5382], and
[RFC5508]. [RFC5508].
The RFC1918 address space was chosen because generally legacy The RFC1918 address space was chosen because generally legacy
applications understand it 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 and 169.254/16 are rejected due to 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 used by the BIH have a risk of conflicting with The RFC1918 addresses used by the BIH have a risk of conflicting with
skipping to change at page 19, line 5 skipping to change at page 19, line 5
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
implementations and it may depend on whether IPv4 address conflict implementations and it may depend on whether IPv4 address conflict
occurs between addresses used by BIH and addresses used by the new occurs between addresses used by BIH and addresses used by the new
IPv4 interface. IPv4 interface.
4.6. Multicast 4.6. Multicast
Protocol translation for multicast is not supported. Protocol translation for multicast is not supported.
5. Considerations due ALG requirements 5. Application-Level Gateway requirements considerations
No ALG functionality is specified herein as ALG design is generally No Application-Level Gateway (ALG) functionality is specified herein
not encouraged for host-based translation and as BIH is intended for as ALG design is generally not encouraged for host-based translation
applications that do not include IP addresses in protocol payloads. and as BIH is intended for applications that do not include IP
addresses in protocol payloads.
6. IANA Considerations 6. IANA Considerations
There are no actions for IANA. There are no actions for IANA.
7. Security Considerations 7. Security Considerations
The security considerations of BIH follows closely, but not The security considerations of BIH follows closely, but not
completely, those of NAT64 [RFC6146] and DNS64 [RFC6147]. The completely, those of NAT64 [RFC6146] and DNS64 [RFC6147]. The
following sections are copied from RFC6146 and RFC6147 and modified following sections are copied from RFC6146 and RFC6147 and modified
skipping to change at page 21, line 46 skipping to change at page 21, line 46
configuration in the filtering portions of the BIH, not by the configuration in the filtering portions of the BIH, not by the
address mapping behavior. address mapping behavior.
7.3. Attacks on BIH 7.3. Attacks on BIH
The BIH implementation itself is a potential victim of different The BIH implementation itself is a potential victim of different
types of attacks. In particular, the BIH can be a victim of DoS types of attacks. In particular, the BIH can be a victim of DoS
attacks. The BIH implementation has a limited number of resources attacks. The BIH implementation has a limited number of resources
that can be consumed by attackers creating a DoS attack. The BIH has that can be consumed by attackers creating a DoS attack. The BIH has
a limited number of IPv4 addresses that it uses to create the a limited number of IPv4 addresses that it uses to create the
bindings. Even though the BIH performs address and port translation, bindings. Even though the BIH performs address translation, it is
it is possible for an attacker to consume the synthetic IPv4 address possible for an attacker to consume the synthetic IPv4 address pool
pool by triggering a host to issue DNS queries for names that cause by triggering a host to issue DNS queries for names that cause ENR to
ENR to synthesise A records. DoS attacks can also affect other synthesise A records. DoS attacks can also affect other limited
limited resources available in the host running BIH such as memory or resources available in the host running BIH such as memory or link
link capacity. For instance, it is possible for an attacker to capacity. For instance, it is possible for an attacker to launch a
launch a DoS attack on the memory of the BIH running device by DoS attack on the memory of the BIH running device by sending
sending fragments that the BIH will store for a given period. If the fragments that the BIH will store for a given period. If the number
number of fragments is high enough, the memory of the host could be of fragments is large enough, the memory of the host could be
exhausted. BIN implementations MUST implement proper protection exhausted. BIH implementations MUST implement proper protection
against such attacks, for instance, allocating a limited amount of against such attacks, for instance, allocating a limited amount of
memory for fragmented packet storage. memory for fragmented packet storage.
Another consideration related to BIH resource depletion refers to the Another consideration related to BIH resource depletion refers to the
preservation of binding state. Attackers may try to keep a binding preservation of binding state. Attackers may try to keep a binding
state alive forever by sending periodic packets that refresh the state alive forever by sending periodic packets that refresh the
state. In order to allow the BIH to defend against such attacks, the state. In order to allow the BIH to defend against such attacks, the
BIH implementation MAY choose not to extend the session entry BIH implementation MAY choose not to extend the session entry
lifetime for a specific entry upon the reception of packets for that lifetime for a specific entry upon the reception of packets for that
entry through the external interface. entry through the external interface. However, such an action would
not allow one-way communication sessions to stay alive.
7.4. DNS considerations 7.4. DNS considerations
BIH operates in combination with the DNS, and is therefore subject to BIH operates in combination with the DNS, and is therefore subject to
whatever security considerations are appropriate to the DNS mode in whatever security considerations are appropriate to the DNS mode in
which the BIH is operating (i.e., authoritative, recursive, or stub- which the BIH is operating (i.e. recursive or stub-resolver mode).
resolver mode).
BIH has the potential to interfere with the functioning of DNSSEC, BIH has the potential to interfere with the functioning of DNSSEC,
because BIH modifies DNS answers, and DNSSEC is designed to detect because BIH modifies DNS answers, and DNSSEC is designed to detect
such modifications and to treat modified answers as bogus. such modifications and to treat modified answers as bogus.
8. Changes since RFC2767 and RFC3338 8. Changes since RFC2767 and RFC3338
This document combines and obsoletes both [RFC2767] and [RFC3338]. This document combines and obsoletes both [RFC2767] and [RFC3338].
The changes in this document mainly reflect the following components: The changes in this document mainly reflect the following components:
skipping to change at page 24, line 12 skipping to change at page 24, line 12
6. Supporting reverse (PTR) queries 6. Supporting reverse (PTR) queries
9. Acknowledgments 9. Acknowledgments
The authors thank the discussion from Gang Chen, Dapeng Liu, Bo Zhou, The authors thank 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 Mohamed Boucadair, Dean Cheng, Lorenzo Colitti, Paco The efforts of Mohamed Boucadair, Dean Cheng, Lorenzo Colitti, Paco
Cortes, Marnix Goossens, Ala Hamarsheh, Ed Jankiewizh, Suresh Cortes, Ralph Droms, Stephen Farrell, Fernando Gont, Marnix Goossens,
Wassim Haddad, Ala Hamarsheh, Dave Harrington, Ed Jankiewizh, Suresh
Krishnan, Julien Laganier, Yiu L. Lee, Jan M. Melen, Qibo Niu, Krishnan, Julien Laganier, Yiu L. Lee, Jan M. Melen, Qibo Niu,
Pierrick Seite, Christian Vogt, Magnus Westerlund, Dan Wing, Dave Pierrick Seite, Christian Vogt, Magnus Westerlund, Dan Wing, and
Harrington, and James Woodyatt in reviewing this document are James Woodyatt in reviewing this document are gratefully
gratefully acknowledged. acknowledged.
Special acknowledgements go to Dave Thaler for his extensive review Special acknowledgements go to Dave Thaler for his extensive review
and support. 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).
skipping to change at page 27, line 7 skipping to change at page 27, line 7
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010. BCP 153, RFC 5735, January 2010.
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment", RFC 6180, Transition Mechanisms during IPv6 Deployment", RFC 6180,
May 2011. May 2011.
Appendix A. API list intercepted by BIH Appendix A. API list intercepted by BIH
The following informational list includes API functions that would be The following informational list includes some of the API functions
appropriate to intercept by BIH module when implemented at socket that would be appropriate to intercept by BIH module when implemented
layer. Please note that this list may not be fully exhaustive. at the socket API layer. Please note that this list is not fully
exhaustive, as the function names and services that are available on
different APIs vary significantly.
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()
skipping to change at page 27, line 49 skipping to change at page 27, line 51
gethostbyname() gethostbyname()
getaddrinfo() getaddrinfo()
The functions that are related to socket options are: The functions that are related to socket options are:
getsocketopt() getsocketopt()
setsocketopt() setsocketopt()
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 [RFC3493], 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. However, IPv4 address literals can only be used after a addresses. However, IPv4 address literals can only be used after a
mapping entry between the IPv4 address and corresponding IPv6 address mapping entry between the IPv4 address and corresponding IPv6 address
has been created. has been created.
The gethostbyname() and getaddrinfo() calls return a list of The gethostbyname() and getaddrinfo() calls return a list of
addresses. When the name resolver function invokes getaddrinfo() and addresses. When the name resolver function invokes getaddrinfo() and
getaddrinfo() returns multiple IP addresses, whether IPv4 or IPv6, getaddrinfo() returns multiple IP addresses, whether IPv4 or IPv6,
they SHOULD all be represented in the addresses returned by they should all be represented in the addresses returned by
gethostbyname(). Thus if getaddrinfo() returns multiple IPv6 gethostbyname(). Thus if getaddrinfo() returns multiple IPv6
addresses, this implies that multiple address mappings will be addresses, this implies that multiple address mappings will be
created; one for each IPv6 address. 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,
 End of changes. 52 change blocks. 
119 lines changed or deleted 142 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/