draft-ietf-behave-v4v6-bih-07.txt   draft-ietf-behave-v4v6-bih-08.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: June 9, 2012 December 7, 2011 Expires: June 25, 2012 December 23, 2011
Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
draft-ietf-behave-v4v6-bih-07 draft-ietf-behave-v4v6-bih-08
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 document obsoletes RFC 2767 and synthesis of IPv4 addresses. This document obsoletes RFC 2767 and
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 June 9, 2012. This Internet-Draft will expire on June 25, 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 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acknowledgement of previous work . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. 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 . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . 10 2.3.2. DNSSEC support . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 10 2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 10
2.3.4. DNS caches and locally generated IPv4 addresses . . . 10 2.3.4. DNS caches and synthetic IPv4 addresses . . . . . . . 10
2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 11
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. Application-Level Gateway requirements considerations . . . . 19 5. Application-Level Gateway requirements considerations . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 4, line 45 skipping to change at page 4, line 45
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 network 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 the local IPv4 address and DNS translation function. The location of the IPv4 address and DNS A
A record synthesis function is orthogonal to the location of the record synthesis function is orthogonal to the location of the
protocol translation, and may or may not happen at the same location. 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. Terminology
DNS synthesis
DNS, A record, synthesis is a process where A type of DNS record
is created by Extension Name Resolver to contain synthetic IPv4
address.
Real IPv4 address
An IPv4 address of a remote node a host has learned, for example,
from DNS response to an A query. Real IPv4 address is opposite to
synthetic IPv4 address.
Real IPv6 address
An IPv6 address of a remote node a host has learned, for example,
from DNS response to an AAAA query.
Synthetic IPv4 address
An IPv4 address that has meaning only inside a host and that is
used to provide IPv4 representation of remote node's real IPv6
address.
1.2. Acknowledgement of previous work
This document is a direct derivative from Kazuaki TSHUCHIYA, This document is a direct derivative from Kazuaki TSHUCHIYA,
Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's Bump-in-the-Stack Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's Bump-in-the-Stack
[RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain
Durand, and Erik Nordmark's Bump-in-the-API [RFC3338], which Durand, and Erik Nordmark's Bump-in-the-API [RFC3338], which
similarly provides IPv4-only applications on dual-stack hosts the similarly provides IPv4-only applications on dual-stack hosts the
means to operate over IPv6. Section 8 covers the changes since those means to operate over IPv6. Section 8 covers the changes since those
documents. documents.
2. Components of the Bump-in-the-Host 2. Components of the Bump-in-the-Host
skipping to change at page 9, line 7 skipping to change at page 9, line 7
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 alternative is name resolution protocol agnostic, and implementation alternative is name resolution protocol agnostic, and
hence supports techniques such as "hosts-file", NetBIOS, mDNS, and hence supports techniques such as "hosts-file", NetBIOS, mDNS, and
anything else the underlying operating system uses. anything else the underlying operating system uses.
In the case of the network layer implementation alternative, 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. If no reply for A query is
implementation alternative will only be able to catch applications' received after 300 ms since reception of positive AAAA response, the
name resolution requests that result in actual DNS queries, hence is ENR MAY choose to proceed as if there were only AAAA record available
more limited when compared to the socket API layer implementation for the destination.
alternative. Hence the socket API layer alternative is RECOMMENDED.
In either implementation alternative, if there is a non-excluded IPv4 The network layer implementation alternative will only be able to
address available, the ENR MUST NOT synthesize IPv4 addresses. catch applications' name resolution requests that result in actual
DNS queries, hence is more limited when compared to the socket API
layer implementation alternative. Hence the socket API layer
alternative is RECOMMENDED.
The ENR asks the address mapper to assign a local IPv4 address In either implementation alternative, if DNS A record reply contains
non-excluded real IPv4 addresses the ENR MUST NOT synthesize IPv4
addresses.
The ENR asks the address mapper to assign a synthetic IPv4 address
corresponding to each received IPv6 address if the A record query corresponding to each received IPv6 address if the A record query
resulted in negative response, all received IPv4 addresses were resulted in negative response, all received real IPv4 addresses were
excluded, or the A query timed out. The timeout value is excluded, or the A query timed out. The timeout value is
implementation specific and may be short in order to provide good implementation specific and may be short in order to provide good
user experience. user experience.
In the case of the API layer implementation alternative, 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 IPv4
address. In the case of the network-layer implementation address. In the case of the network-layer implementation
alternative, the ENR synthesizes an A record for the assigned IPv4 alternative, the ENR synthesizes an A record for the assigned
address, and delivers it up the stack. If the response contains a synthetic IPv4 address, and delivers it up the stack. If the
CNAME or a DNAME record, then the CNAME or DNAME chain is followed response contains a CNAME or a DNAME record, then the CNAME or DNAME
until the first terminating A or AAAA record is reached. chain is followed 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 real IPv4 and
addresses seen on received A and AAAA records. The addresses to be IPv6 addresses seen on received A and AAAA records. The addresses to
excluded by default MAY include addresses such as those that should be excluded by default MAY include addresses such as those that
not appear in the DNS or on the wire (see [RFC6147] section 5.1.4 and should not appear in the DNS or on the wire (see [RFC6147] section
[RFC5735]). Additional addresses MAY be excluded based on possibly 5.1.4 and [RFC5735]). Additional addresses MAY be excluded based on
configurable local policies. possibly 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. While running BIH, the main resolver of the host SHOULD section 3. While running BIH, the main resolver of the host SHOULD
NOT perform validation of A records as synthetic A records created by NOT perform validation of A records as synthetic A records created by
ENR would fail in validation. While not running BIH, host's resolver 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 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 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 be configured to trust validations done by the ENR located at the
network layer. In some cases the host's validating stub resolver can network layer. In some cases the host's validating stub resolver can
implement the ENR by itself. 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.
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 (PTR query) for an IPv4
the ENR MUST check whether the queried IPv4 address can be found in address, the ENR MUST check whether the queried IPv4 address can be
the Address Mapper's mapping table and is a local IPv4 address. If found in the Address Mapper's mapping table and is a synthetic IPv4
an entry is found and the queried address is locally generated, the address. If an entry is found and the queried IPv4 address is
ENR MUST initiate a corresponding reverse lookup for the real IPv6 synthetic, the ENR MUST initiate a corresponding reverse lookup for
address. In the case where the application requested a reverse the real IPv6 address. In the case where the application requested a
lookup for an address not part of the local IPv4 address pool, e.g., reverse lookup for an address not part of the synthetic IPv4 address
a global address, the request MUST be passed on unmodified. pool, e.g., 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 synthetic IPv4 address, the ENR needs to intercept that query. The
that query. The ENR asks the address mapper for the IPv6 address ENR asks the address mapper for the real IPv6 address that
that corresponds to the IPv4 address. The ENR shall perform a corresponds to the synthetic 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 caches and locally generated IPv4 addresses 2.3.4. DNS caches and synthetic IPv4 addresses
When BIH shuts down or address mapping table entries are cleared for When BIH shuts down or address mapping table entries are cleared for
any reason, DNS cache entries for locally generated IPv4 addresses any reason, DNS cache entries for synthetic IPv4 addresses MUST be
MUST be flushed. There may be a DNS cache in the network-layer ENR flushed. There may be a DNS cache in the network-layer ENR itself,
itself, but also at the host's stub resolver. 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 an IPv4 address pool that can be used
consists of private IPv4 addresses per section 4.4. Also, the for IPv4 address synthesis. The pool consists of [RFC1918] IPv4
address mapper maintains a table consisting of pairs of locally addresses as per section 4.4. Also, the address mapper maintains a
selected IPv4 addresses and destinations' IPv6 addresses. table consisting of pairs of synthetic IPv4 addresses and
destinations' real 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 a synthetic IPv4 address
to an IPv6 address, the address mapper selects and returns an IPv4 corresponding to an IPv6 address, the address mapper selects and
address out of the local pool, and registers a new entry into the returns an IPv4 address out of the local pool, and registers a new
table. The registration occurs in the following three cases: entry into the 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 synthetic IPv4 addresses will be returned to
application and mappings for local IPv4 addresses to real IPv6 the application and mappings for synthetic IPv4 addresses to real
addresses are created. IPv6 addresses are created.
(2) When the extension name resolver gets both IPv4 and IPv6 (2) When the extension name resolver gets both real IPv4 and IPv6
addresses, but the IPv4 addresses contain only excluded IPv4 addresses, but the real 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 is triggered by a received IPv6 packet (3) When the function mapper is triggered by a received IPv6 packet
and there is no existing mapping entry for the IPv6 source address and there is no existing mapping entry for the IPv6 source address
(for example, the client sent a UDP request to an anycast address but (for example, the client sent a UDP request to an anycast address but
a response was received from a unicast address). a response was received from a 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.
skipping to change at page 12, line 23 skipping to change at page 12, line 23
| 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 not globally reachable IPv4
without port forwarding set up on the NAT44. The only means to addresses, such as [RFC1918] addresses, without port forwarding set
contact the server is to use IPv6. up on the NAT44. The only means to contact the server is to use
IPv6.
+----------------------+ +------------------------------+ +----------------------+ +------------------------------+
| Dual Stack Internet | | IPv4 Private site (Net 10) | | Dual Stack Internet | | IPv4 Private site (Net 10) |
| | | IPv6 routed site | | | | IPv6 routed site |
| +---------+ +----------+ | | +---------+ +----------+ |
| +-| NAT44 |-------------+ | | | +-| NAT44 |-------------+ | |
| +----+ | +---------+ | | | | +----+ | +---------+ | | |
| | H1 |---------+ | | | Server | | | | H1 |---------+ | | | Server | |
| +----+ | +-----------+ | | | | +----+ | +-----------+ | | |
| v4 only +-|IPv6 Router|-----------+ | | | v4 only +-|IPv6 Router|-----------+ | |
skipping to change at page 13, line 5 skipping to change at page 13, line 5
+----------------------+ +------------------------------+ +----------------------+ +------------------------------+
Figure 5: Network Scenario #2 Figure 5: Network Scenario #2
Illustrations of host behavior in both implementation alternatives Illustrations of host behavior in both implementation alternatives
are given here. Figure 6 illustrates a setup where BIH (including are given here. Figure 6 illustrates a setup where BIH (including
the 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".>> | | |
| | | | | | | | | | | | | | | |
|------->|------->| Query IPv4 addresses for host6. | | |------->|------->| Query IPv4 addresses for host6. | |
| | | | | | | | | | | | | | | |
| | |------------------------------------------------->| | | |------------------------------------------------->|
| | | Query 'A' and 'AAAA' records for host6 | | | | Query 'A' and 'AAAA' records 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 synthetic IPv4 address |
| | | | corresponding to the IPv6 address. | | | | corresponding to the IPv6 address.
| | | | | | | | | | | | | |
| | | |<<Assign one IPv4 address.>> | | | | |<<Assign one synthetic IPv4 address.>>
| | | | | | | | | | | | | |
| | |<+++++++| Reply with the IPv4 address. | | | |<+++++++| Reply with the synthetic 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 action |=======>|=========================>|An IPv4 Socket API action
| | | | | | | | | | | | | |
| | | |<+++++++| Request IPv6 addresses| | | | |<+++++++| Request IPv6 addresses|
| | | | | corresponding to the | | | | | | corresponding to the |
| | | | | IPv4 addresses. | | | | | | synthetic IPv4 addresses.
| | | | | | | | | | | | | |
| | | |+++++++>| Reply with the IPv6 addresses. | | | |+++++++>| Reply with the IPv6 addresses.
| | | | | | | | | | | | | |
| | | | |<<Translate IPv4 into IPv6.>> | | | | |<<Translate IPv4 into IPv6.>>
| | | | | | | | | | | | | |
| An IPv6 Socket API action |=======================>| | An IPv6 Socket API action |=======================>|
| | | | | | | | | | | | | |
| | | | |<<IPv6 data received | | | | | |<<IPv6 data received |
| | | | | from network.>> | | | | | | from network.>> |
| | | | | | | | | | | | | |
| An IPv6 Socket API action |<=======================| | An IPv6 Socket API action |<=======================|
| | | | | | | | | | | | | |
| | | | |<<Translate IPv6 into IPv4.>> | | | | |<<Translate IPv6 into IPv4.>>
| | | | | | | | | | | | | |
| | | |<+++++++| Request IPv4 addresses| | | | |<+++++++| Request synthetic 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 API action |<=======|<=========================| 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".>> | |
|-->| | | | | | | |-->| | | | | | |
| |----------->| Query 'A' records for "host6". | Name | |----------->| Query 'A' records for "host6". | Name
| | | | | | | | Server | | | | | | | | Server
| | | |------------------------------------------->| | | | |------------------------------------------->|
| | | | Query 'A' and 'AAAA' records for "host6" | | | | Query 'A' and 'AAAA' records 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 synthetic IPv4 address
| | | | | corresponding to each IPv6 address. | | | | | corresponding to each IPv6 address.
| | | | | | | | | | | | | | | |
| | | | |<<Assign IPv4 addresses.>> | | | | | |<<Assign synthetic IPv4 addresses.>>
| | | | | | | | | | | | | | | |
| | | |<--------| Reply with the IPv4 address. | | | |<--------| Reply with the synthetic 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 | | | |<--|<<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
| | | | | | addresses. | | | | | | | synthetic IPv4 addresses.
| | | | | | | |
| | | | |++++++>| Reply with the IPv6| | | | | | | | |
| | | | | | addresses. | | | | | |++++++>| Reply with the IPv6|
| | | | | | | | | | | | | | addresses. |
| | | | | |<<Translate IPv4 into IPv6.>> | | | | | | | |
| | | | | | | | | | | | | |<<Translate IPv4 into IPv6.>>
| | | |An IPv6 packet. |==========>|========>| | | | | | | | |
| | | | | | | | | | | |An IPv6 packet. |==========>|========>|
| | | | | <<Reply with an IPv6 packet.>> | | | | | | | |
| | | | | | | | | | | | | <<Reply with an IPv6 packet.>>
| | | |An IPv6 packet. |<==========|<========| | | | | | | | |
| | | | | | | | | | | |An IPv6 packet. |<==========|<========|
| | | | | |<<Translate IPv6 into IPv4.>> | | | | | | | |
| | | | | | | | | | | | | |<<Translate IPv6 into IPv4.>>
| | | | |<++++++|Request IPv4 addresses | | | | | | | |
| | | | | |corresponding to the | | | | | |<++++++| Request synthetic IPv4
| | | | | | IPv6 addresses. | | | | | | | addresses corresponding
| | | | | | | | | | | | | | to the IPv6 addresses.
| | | | |++++++>| Reply with the IPv4 addresses. | | | | | | | |
| | | | | | | | | | | | |++++++>| Reply with the IPv4 addresses.
|<=======|=========================| An IPv4 packet. | | | | | | | | |
| | | | | | | | |<=======|=========================| An IPv4 packet. |
| | | | | | | |
Figure 7: Example of BIH at the 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 IPv6 socket API IPv4 socket API functions are translated into IPv6 socket API
functions that are semantically as identical as possible and vice functions that are semantically as identical as possible and vice
versa. See Appendix B for the API list intercepted by BIH. However, versa. See Appendix B for the API list intercepted by BIH. However,
skipping to change at page 16, line 35 skipping to change at page 16, line 35
4.3. ICMP Message Handling 4.3. ICMP Message Handling
ICMPv4 and ICMPv6 messages MUST be translated as defined by SIIT ICMPv4 and ICMPv6 messages MUST be translated as defined by SIIT
[RFC6145]. In the network layer implementation alternative, protocol [RFC6145]. In the network layer implementation alternative, protocol
translator MUST translate ICMPv6 packets to ICMPv4 and vice versa, translator MUST translate ICMPv6 packets to ICMPv4 and vice versa,
and in the socket API implementation alternative, the socket API MUST and in the socket API implementation alternative, the socket API MUST
handle conversions in similar fashion. 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 [RFC1918] private IPv4 addresses.
[RFC1918]. This pool can be implemented at different granularities This pool can be implemented at different granularities in the node,
in the node, e.g., a single pool per node, or at some finer e.g., a single pool per node, or at some finer granularity such as
granularity such as per-user or per-process. In the case of a large per-user or per-process. In the case of a large number of IPv4
number of IPv4 applications communicating with a large number of IPv6 applications communicating with a large number of IPv6 servers, the
servers, the available address space may be exhausted if the available address space may be exhausted if the granularity is not
granularity is not fine enough. This should be a rare event and fine enough. This should be a rare event and chances will decrease
chances will decrease as IPv6 support increases. The applications as IPv6 support increases. The applications may use IPv4 addresses
may use IPv4 addresses they learn for a much longer period than DNS they learn for a much longer period than DNS time-to-live indicates.
time-to-live indicates. Therefore, the mapping table entries should Therefore, the mapping table entries should be kept active for a long
be kept active for a long period of time. For example, a web browser period of time. For example, a web browser may initiate one DNS
may initiate one DNS query and then create multiple TCP sessions over query and then create multiple TCP sessions over time to the address
time to the address it learns. When address mapping table clean-up it learns. When address mapping table clean-up is required, the BIH
is required, the BIH may utilize techniques used by network address may utilize techniques used by network address translators, such as
translators, such as described in [RFC2663], [RFC5382], and 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
addresses used in the host's possible IPv4 interfaces and addresses used in the host's possible IPv4 interfaces and
corresponding local networks. The conflicts can be mitigated, but corresponding local networks. The conflicts can be mitigated, but
not fully avoided, by using less commonly used portions of the not fully avoided, by using less commonly used portions of the
RFC1918 address space. Addresses from 172.16/12 are thought to be RFC1918 address space. Addresses from 172.16/12 are thought to be
less likely to be in conflict than addresses from 10/8 or 192.168/16 less likely to be in conflict than addresses from 10/8 or 192.168/16
spaces. A source address can usually be selected in a non- spaces. A source address can usually be selected in a non-
conflicting manner, but a small possibility exists for synthesized conflicting manner, but a small possibility exists for synthesized
destination addresses being in conflict with real addresses used in destination addresses being in conflict with real addresses used in
local IPv4 networks. attached IPv4 networks.
The RECOMMENDED IPv4 addresses are following: The RECOMMENDED IPv4 addresses are following:
Primary source addresses: 172.21.112.0/20. Source addresses have to Primary source addresses: 172.21.112.0/20. Source addresses have to
be allocated because applications use getsockname() calls and in the be allocated because applications use getsockname() calls and in the
network layer mode an IP address of the IPv4 interface has to be network layer mode an IP address of the IPv4 interface has to be
shown (e.g., by 'ifconfig'). More than one address is allocated to shown (e.g., by 'ifconfig'). More than one address is allocated to
allow implementation flexibility, e.g., for cases where a host has allow implementation flexibility, e.g., for cases where a host has
multiple IPv6 interfaces. The source addresses are from different multiple IPv6 interfaces. The source addresses are from different
subnets than destination addresses to ensure applications would not subnets than destination addresses to ensure applications would not
skipping to change at page 23, line 9 skipping to change at page 23, line 9
which the BIH is operating (i.e. recursive or stub-resolver mode). which the BIH is operating (i.e. recursive or stub-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:
1. Supporting IPv6-only network connections 1. RFC1918 addresses used used for synthesis
2. The IPv4 address pool uses private address instead of reserved The RFC3338 used unassigned IPv4 addresses (e.g., 0.0.0.1 -
IPv4 addresses (0.0.0.1 - 0.0.0.255) 0.0.0.255) for synthetic IPv4 addresses. Those addresses should
not have been used and that may cause problems with applications.
It is preferable to use RFC1918 defined addresses instead, as
described in Section 4.4.
3. Extending ENR and address mapper to operate differently 2. Support for reverse (PTR) DNS queries
4. Adding an alternative way to implement the ENR Neither RFC2767 or RFC3338 included support for reverse (PTR) DNS
queries. This document adds the support at Section 2.3.3.
5. Standards track instead of experimental/informational 3. DNSSEC support
6. Supporting reverse (PTR) queries RFC2767 did not include DNSSEC considerations, which are now
included in Section 2.3.2
4. Architectural recommendation
This document recommends socket API layer implementation option
over network layer translation, i.e. recommends approach
introduced in RFC2767 over the approach of RFC3338.
5. Standards track document
RFC2767 is classified as Informational RFC and RFC3338 as
Experimental RFC. It was discussed and decided in the IETF that
this technology should be on the standards track.
6. Set of other extensions and improvements
Set of lesser extensions, improvements, and clarifications have
been introduced. These include but are not limited to: IPv4 and
IPv6 address exclusion sets at Section 2.3.1, host's DNS cache
considerations, ENR behaviour updates, updated security
considerations, example updates, and deployment scenario updates.
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, Ralph Droms, Stephen Farrell, Fernando Gont, Marnix Goossens, Cortes, Ralph Droms, Stephen Farrell, Fernando Gont, Marnix Goossens,
Wassim Haddad, Ala Hamarsheh, Dave Harrington, Ed Jankiewizh, Suresh Wassim Haddad, Ala Hamarsheh, Dave Harrington, Ed Jankiewizh, Suresh
 End of changes. 34 change blocks. 
199 lines changed or deleted 261 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/