draft-ietf-behave-v4v6-bih-03.txt   draft-ietf-behave-v4v6-bih-04.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: September 12, 2011 March 11, 2011 Expires: October 14, 2011 April 12, 2011
Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
draft-ietf-behave-v4v6-bih-03 draft-ietf-behave-v4v6-bih-04
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. synthesis of IPv4 addresses.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2011. This Internet-Draft will expire on October 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acknowledgement of previous work . . . . . . . . . . . . . 5 1.1. Acknowledgement of previous work . . . . . . . . . . . . . 5
2. Components of the Bump-in-the-Host . . . . . . . . . . . . . . 6 2. Components of the Bump-in-the-Host . . . . . . . . . . . . . . 6
2.1. Function Mapper . . . . . . . . . . . . . . . . . . . . . 7 2.1. Function Mapper . . . . . . . . . . . . . . . . . . . . . 7
2.2. 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 . . . . . . . . . . . . . . . . . . . . 9
2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 9 2.3.3. Reverse DNS lookup . . . . . . . . . . . . . . . . . . 10
2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 10
3. Behavior and network Examples . . . . . . . . . . . . . . . . 11 3. Behavior and network Examples . . . . . . . . . . . . . . . . 12
4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 15 4.1. Socket API Conversion . . . . . . . . . . . . . . . . . . 16
4.2. ICMP Message Handling . . . . . . . . . . . . . . . . . . 15 4.2. Socket bindings . . . . . . . . . . . . . . . . . . . . . 16
4.3. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 15 4.3. ICMP Message Handling . . . . . . . . . . . . . . . . . . 16
4.4. Multi-interface . . . . . . . . . . . . . . . . . . . . . 16 4.4. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 16
4.5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 16 4.5. Multi-interface . . . . . . . . . . . . . . . . . . . . . 17
4.6. DNS cache . . . . . . . . . . . . . . . . . . . . . . . . 16 4.6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Considerations due ALG requirements . . . . . . . . . . . . . 17 4.7. DNS cache . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Considerations due ALG requirements . . . . . . . . . . . . . 19
7. Changes since RFC2767 and RFC3338 . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7. Changes since RFC2767 and RFC3338 . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
Appendix A. Implementation option for the ENR . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 24 Appendix A. Implementation option for the ENR . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. API list intercepted by BIH . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
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. IPv4 addresses from AAAA records.
The supported class of applications includes those that use DNS for The supported class of applications includes those that use DNS for
skipping to change at page 4, line 25 skipping to change at page 4, line 25
protocol payloads. This essentially includes legacy client-server protocol payloads. This essentially includes legacy client-server
applications using the DNS that are agnostic to the IP address family applications using the DNS that are agnostic to the IP address family
used by the destination and that are able to do NAT traversal. The used by the destination and that are able to do NAT traversal. The
synthetic IPv4 addresses shown to applications are taken from the synthetic IPv4 addresses shown to applications are taken from the
RFC1918 private address pool in order to ensure that possible NAT RFC1918 private address pool in order to ensure that possible NAT
traversal 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 as a competing technology for tunneling NAT64 is NOT RECOMMENDED [I-D.arkko-ipv6-transition-guidelines].
based transition solutions.
BIH includes two major implementation options: a protocol translator BIH includes two major implementation options: a protocol translator
between the IPv4 and the IPv6 stacks of a host, or an API translator between the IPv4 and the IPv6 stacks of a host, or an API translator
between the IPv4 socket API module and the TCP/IP module. between the IPv4 socket API module and the TCP/IP module.
Essentially, IPv4 is translated into IPv6 at the socket API layer or Essentially, IPv4 is translated into IPv6 at the socket API layer or
at the IP layer. at the IP layer.
When 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.
skipping to change at page 7, line 50 skipping to change at page 7, line 50
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 intercepts the function calls and invokes IPv6 the function mapper intercepts the function calls and invokes IPv6
socket API functions that correspond to the IPv4 socket API socket API functions that correspond to the IPv4 socket API
functions. functions.
The function mapper MUST NOT perform function mapping when the
application is initiating communications to the address range used by
local synthesis and the address mapping table does not have an entry
mathching the address.
See Appendix B for a list of functions that MUST be intercepted by See Appendix B for a list of functions that MUST be intercepted by
the function mapper. 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 using the IP conversion mechanism defined in SIIT
[I-D.ietf-behave-v6v4-xlate]. To avoid unnecessary fragmentation, [I-D.ietf-behave-v6v4-xlate]. To avoid unnecessary fragmentation,
host's IPv4 module should be configured with small enough MTU (IPv6 host's IPv4 module should be configured with small enough MTU (IPv6
link MTU - 20 bytes). link MTU - 20 bytes).
Protocol translation SHOULD NOT be performend for IPv4 packets sent
to IPv4 address range used by local synthesis and for which mapping
table entry does not exist. The implementation SHOULD attempt to
route such packet via IPv4 interfaces instead.
2.3. Extension Name Resolver 2.3. Extension Name Resolver
The Extension Name Resolver (ENR) returns a proper answer in response The Extension Name Resolver (ENR) returns a proper answer in response
to the IPv4 application's name resolution request. to 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 option, when an
IPv4 application tries to do a forward lookup to resolve names via 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.,
getnameinfo()) that will resolve both A and AAAA records. This getnameinfo()) that will resolve both A and AAAA records. This
skipping to change at page 15, line 16 skipping to change at page 16, line 16
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,
IPv4 socket API functions are not fully compatible with IPv6 since IPv4 socket API functions are not fully compatible with IPv6 since
IPv4 supports features that are not present in IPv6, such as IPv4 supports features that are not present in IPv6, such as
SO_BROADCAST. SO_BROADCAST.
4.2. ICMP Message Handling 4.2. Socket bindings
BIH SHOULD select a source address for a socket from the recommended
source address pool if a socket used for communications has not been
explicitly bound to any IPv4 address.
Binding of explicitly bound socket MUST NOT be changed by the BIH.
4.3. ICMP Message Handling
When an application needs ICMP messages values (e.g., Type, Code, When an application needs ICMP messages values (e.g., Type, Code,
etc.) sent from the network layer, ICMPv4 message values MAY be etc.) sent from the network layer, ICMPv4 message values MAY be
translated into ICMPv6 message values based on SIIT translated into ICMPv6 message values based on SIIT
[I-D.ietf-behave-v6v4-xlate], and vice versa. [I-D.ietf-behave-v6v4-xlate], and vice versa.
4.3. IPv4 Address Pool and Mapping Table 4.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 possible chances will decrease as IPv6 support increases. The applications
problem can also mitigated with smart management techniques of the may use IPv4 addresses they learn for much longer period than DNS
address pool. For example, entries with the longest inactivity time time-to-live indicates. Therefore, the mapping table entries should
can be cleared and IPv4 addresses reused for creating new entries. 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
time to the address it learns. When address mapping table clean-up
is required the BIH may utilize techniques used by network address
translators, such as described in [RFC2663], [RFC5382], and
[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 have a risk of conflicting with other The RFC1918 addresses used by the BIH have a risk of conflicting with
interfaces. The conflicts can be mitigated by using a least commonly addresses used in host's possible IPv4 interfaces and corresponding
used portion of the RFC1918 address space. Addresses from 172.16/12 local networks. The conflicts can be mitigated, but not fully
are thought to be less likely to conflict than addresses from 10/8 or avoided, by using less commonly used portions of the RFC1918 address
192.168/16 spaces, hence the RECOMMENDED IPv4 addresses are following space. Addresses from 172.16/12 are thought to be less likely to be
(Editor's comment: this is first proposal, educated better guesses in conflict than addresses from 10/8 or 192.168/16 spaces. A source
are welcome): address can usually be selected in non-conflicting manner, but small
possibility exist for synthesized destination addresses being in
conflict with real addresses used in local IPv4 networks.
Source addresses: 172.21.112.0/30. Source addresses have to be The RECOMMENDED IPv4 addresses are following:
allocated because applications use getsockname() calls and in the BIS
mode an IP address of the IPv4 interface has to be shown (e.g., by
'ifconfig'). More than one address is allocated to allow
implementation flexibility, e.g., for cases where a host has multiple
IPv6 interfaces. The source addresses are from different subnets
than destination addresses to that ensure applications would not make
on-link assumptions and would instead enable NAT traversal functions.
Primary destination addresses: 172.21.80.0/20. The address mapper Primary source addresses: 172.21.112.0/30. Source addresses have to
be allocated because applications use getsockname() calls and in the
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
allow implementation flexibility, e.g., for cases where a host has
multiple IPv6 interfaces. The source addresses are from different
subnets than destination addresses to that ensure applications would
not make on-link assumptions and would instead enable NAT traversal
functions.
Secondary source addresses: 10.170.224.0/20. These addresses are
recommended a if host has conflict with primary source addresses.
Primary destination addresses: 10.170.160.0/20. The address mapper
will select destination addresses primarily out of this pool. will select destination addresses primarily out of this pool.
Secondary destination addresses: 10.170.160.0/20. The address mapper Secondary destination addresses: 172.21.80.0/20. The address mapper
will select destination addresses out of this pool if the node has a will select destination addresses out of this pool if the node has a
dual-stack connection conflicting with primary destination addresses. dual-stack connection conflicting with primary destination addresses.
4.4. Multi-interface 4.5. Multi-interface
In the case of dual-stack destinations BIH MUST NOT do protocol In the case of dual-stack destinations BIH MUST NOT do protocol
translation from IPv4 to IPv6 when the host has any IPv4 interfaces, translation from IPv4 to IPv6 when the host has any IPv4 interfaces,
native or tunneled, available for use. native or tunneled, available for use.
It is possible that an IPv4 interface is activated during BIH It is possible that an IPv4 interface is activated during BIH
operation, for example if a node moves to a coverage area of an IPv4- operation, for example if a node moves to a coverage area of an IPv4-
enabled network. In such an event, BIH MUST stop initiating protocol enabled network. In such an event, BIH MUST stop initiating protocol
translation sessions for new connections and BIH MAY disconnect translation sessions for new connections and BIH MAY disconnect
active sessions. The choice of disconnection is left for active sessions. The choice of disconnection is left for
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.5. Multicast 4.6. Multicast
Protocol translation for multicast is not supported. Protocol translation for multicast is not supported.
4.6. DNS cache 4.7. DNS cache
When BIH shuts down, e.g., due to an IPv4 interface becoming When BIH shuts down, e.g., due to an IPv4 interface becoming
available, BIH MUST flush the node's DNS cache of possible locally available, BIH MUST flush the node's DNS cache of possible locally
generated entries. This cache may be in the ENR itself, but also generated entries. This cache may be in the ENR itself, but also
possibly host's caching stub resolver. possibly host's caching stub resolver.
5. Considerations due ALG requirements 5. Considerations due ALG requirements
No ALG functionality is specified herein as ALG design is generally No ALG functionality is specified herein as ALG design is generally
not encouraged for host-based translation and as BIH is intended for not encouraged for host-based translation and as BIH is intended for
skipping to change at page 20, line 11 skipping to change at page 22, line 11
5. Standards track instead of experimental/informational 5. Standards track instead of experimental/informational
6. Supporting reverse (PTR) queries 6. Supporting reverse (PTR) queries
8. Acknowledgments 8. Acknowledgments
The author thanks the discussion from Gang Chen, Dapeng Liu, Bo Zhou, The author thanks the discussion from Gang Chen, Dapeng Liu, Bo Zhou,
Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of
this document. this document.
The efforts of Suresh Krishnan, Mohamed Boucadair, Yiu L. Lee, James The efforts of Mohamed Boucadair, Dean Cheng, Lorenzo Colitti, Paco
Woodyatt, Lorenzo Colitti, Qibo Niu, Pierrick Seite, Dean Cheng, Cortes, Marnix Goossens, Ala Hamarsheh, Ed Jankiewizh, Suresh
Christian Vogt, Jan M. Melen, Ed Jankiewizh, Marnix Goossens, Ala Krishnan, Julien Laganier, Yiu L. Lee, Jan M. Melen, Qibo Niu,
Hamarsheh, Dan Wing, Magnus Westerlun and Julien Laganier in Pierrick Seite, Christian Vogt, Magnus Westerlund, Dan Wing, and
reviewing this document are gratefully acknowledged. James Woodyatt in reviewing this document are gratefully
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 21, line 51 skipping to change at page 23, line 51
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000. IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A.
Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)",
RFC 3338, October 2002. RFC 3338, October 2002.
9.2. Informative References 9.2. Informative References
[I-D.arkko-ipv6-transition-guidelines]
Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment",
draft-arkko-ipv6-transition-guidelines-14 (work in
progress), December 2010.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003. RFC 3493, February 2003.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
April 2009.
Appendix A. Implementation option for the ENR Appendix A. Implementation option for the ENR
It is not necessary to implement the ENR at the kernel level, but it It is not necessary to implement the ENR at the kernel level, but it
can be implemented instead at the user space by setting the host's can be implemented instead at the user space by setting the host's
default DNS server to point to 127.0.0.1. DNS queries would then default DNS server to point to 127.0.0.1. DNS queries would then
always be sent to the ENR, which furthermore ensures that both A and always be sent to the ENR, which furthermore ensures that both A and
AAAA queries are sent to the actual DNS server and A queries are AAAA queries are sent to the actual DNS server and A queries are
always answered and required mappings created. always answered and required mappings created.
Appendix B. API list intercepted by BIH Appendix B. API list intercepted by BIH
skipping to change at page 25, line 22 skipping to change at page 27, line 22
sockaddr_in sockaddr_in6 sockaddr_in sockaddr_in6
gethostbyname() getaddrinfo() gethostbyname() getaddrinfo()
gethostbyaddr() getnameinfo() gethostbyaddr() getnameinfo()
inet_ntoa()/inet_addr() inet_pton()/inet_ntop() inet_ntoa()/inet_addr() inet_pton()/inet_ntop()
INADDR_ANY in6addr_any INADDR_ANY in6addr_any
Figure 8 Figure 8
BIH MAY intercept inet_ntoa() and inet_addr() and use the address BIH MAY intercept inet_ntoa() and inet_addr() and use the address
mapper for those. Doing that enables BIH to support literal IP mapper for those. Doing that enables BIH to support literal IP
addresses. addresses. However, IPv4 address literals can only be used after a
mapping entry between the IPv4 address and corresponding IPv6 address
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
 End of changes. 22 change blocks. 
56 lines changed or deleted 108 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/