doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc3338.txt b/doc/rfc/rfc3338.txt
new file mode 100644
index 0000000..57f6591
--- /dev/null
+++ b/doc/rfc/rfc3338.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                             S. Lee
+Request for Comments: 3338                                     M-K. Shin
+Category: Experimental                                          Y-J. Kim
+                                                                    ETRI
+                                                             E. Nordmark
+                                                               A. Durand
+                                                        Sun Microsystems
+                                                            October 2002
+
+
+             Dual Stack Hosts Using "Bump-in-the-API" (BIA)
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document specifies a mechanism of dual stack hosts using a
+   technique called "Bump-in-the-API"(BIA) which allows for the hosts to
+   communicate with other IPv6 hosts using existing IPv4 applications.
+   The goal of this mechanism is the same as that of the Bump-in-the-
+   stack mechanism, but this mechanism provides the translation method
+   between the IPv4 APIs and IPv6 APIs.  Thus, the goal is simply
+   achieved without IP header translation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al.                   Experimental                      [Page 1]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+Table of Contents:
+
+   1.  Introduction ................................................  2
+   2.  Applicability and Disclaimer ................................  3
+   2.1 Applicability ...............................................  3
+   2.2 Disclaimer ..................................................  4
+   3.  Dual Stack Host Architecture Using BIA ......................  4
+   3.1 Function Mapper .............................................  4
+   3.2 Name Resolver ...............................................  5
+   3.3 Address Mapper ..............................................  5
+   4.  Behavior Example ............................................  6
+   4.1 Originator Behavior .........................................  6
+   4.2 Recipient Behavior ..........................................  8
+   5.  Considerations  ............................................. 10
+   5.1 Socket API Conversion ....................................... 10
+   5.2 ICMP Messages Handling ...................................... 10
+   5.3 IPv4 Address Pool and Mapping Table ......................... 10
+   5.4 Internally Assigned IPv4 Addresses .......................... 10
+   5.5 Mismatch Between DNS Result and Peer Application Version .... 11
+   5.6 Implementation Issues ....................................... 11
+   6.  Limitations ................................................. 12
+   7.  Security Considerations ..................................... 12
+   8.  Acknowledgments ............................................. 12
+   9.  References .................................................. 12
+   Appendix:  API list intercepted by BIA .......................... 14
+   Authors Addresses ............................................... 16
+   Full Copyright Statement ........................................ 17
+
+1. Introduction
+
+   RFC2767 [BIS] specifies a host translation mechanism using a
+   technique called "Bump-in-the-Stack".  It translates IPv4 into IPv6,
+   and vice versa using the IP conversion mechanism defined in [SIIT].
+   BIS allows hosts to communicate with other IPv6 hosts using existing
+   IPv4 applications.  However, this approach is to use an API
+   translator which is inserted between the TCP/IP module and network
+   card driver, so that it has the same limitations as the [SIIT] based
+   IP header translation methods.  In addition, its implementation is
+   dependent upon the network interface driver.
+
+   This document specifies a new mechanism of dual stack hosts called
+   Bump-in-the-API(BIA) technique.  The BIA technique inserts an API
+   translator between the socket API module and the TCP/IP module in the
+   dual stack hosts, so that it translates the IPv4 socket API function
+   into IPv6 socket API function and vice versa.  With this mechanism,
+   the translation can be simplified without IP header translation.
+
+
+
+
+
+Lee, et al.                   Experimental                      [Page 2]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+   Using BIA, the dual stack host assumes that there exists both
+   TCP(UDP)/IPv4 and TCP(UDP)/IPv6 stacks on the local node.
+
+   When IPv4 applications on the dual stack communicate with other IPv6
+   hosts, the API translator detects the socket API functions from IPv4
+   applications and invokes the IPv6 socket API functions to communicate
+   with the IPv6 hosts, and vice versa.  In order to support
+   communication between IPv4 applications and the target IPv6 hosts,
+   pooled IPv4 addresses will be assigned through the name resolver in
+   the API translator.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+   This document uses terms defined in [IPv6],[TRANS-MECH] and [BIS].
+
+2. Applicability and Disclaimer
+
+2.1 Applicability
+
+   The main purposes of BIA are the same as BIS [BIS].  It makes IPv4
+   applications communicate with IPv6 hosts without any modification of
+   those IPv4 applications.  However, while BIS is for systems with no
+   IPv6 stack, BIA is for systems with an IPv6 stack, but on which some
+   applications are  not yet available on IPv6 and source code is not
+   available preventing the application from being ported.  It's good
+   for early adopters who do not have all applications handy, but not
+   for mainstream production usage.
+
+   There is an issue about a client node running BIA trying to contact a
+   dual stack node on a port number that is only associated with an IPv4
+   application (see section 5.5).  There are 2 approaches.
+
+   - The client application SHOULD cycle through all the addresses and
+     end up trying the IPv4 one.
+
+   - BIA SHOULD do the work.
+
+   It is not clear at this time which behavior is desirable (it may very
+   well be application dependent), so we need to get feedback from
+   experimentation.
+
+
+
+
+
+
+
+
+
+Lee, et al.                   Experimental                      [Page 3]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+2.2 Disclaimer
+
+   BIA SHOULD NOT be used for an IPv4 application for which source code
+   is available.  We strongly recommend that application programmers
+   SHOULD NOT use this mechanism when application source code is
+   available.  As well, it SHOULD NOT be used as an excuse not to port
+   software or delay porting.
+
+3. Dual Stack Host Architecture Using BIA
+
+   Figure 1 shows the architecture of the host in which BIA is
+   installed.
+
+               +----------------------------------------------+
+               | +------------------------------------------+ |
+               | |                                          | |
+               | |             IPv4 applications            | |
+               | |                                          | |
+               | +------------------------------------------+ |
+               | +------------------------------------------+ |
+               | |           Socket API (IPv4, IPv6)        | |
+               | +------------------------------------------+ |
+               | +-[ API translator]------------------------+ |
+               | | +-----------+ +---------+ +------------+ | |
+               | | | Name      | | Address | | Function   | | |
+               | | | Resolver  | | Mapper  | | Mapper     | | |
+               | | +-----------+ +---------+ +------------+ | |
+               | +------------------------------------------+ |
+               | +--------------------+ +-------------------+ |
+               | |                    | |                   | |
+               | |    TCP(UDP)/IPv4   | |   TCP(UDP)/IPv6   | |
+               | |                    | |                   | |
+               | +--------------------+ +-------------------+ |
+               +----------------------------------------------+
+
+            Figure 1 Architecture of the dual stack host using BIA
+
+   Dual stack hosts defined in RFC2893 [TRANS-MECH] need applications,
+   TCP/IP modules and addresses for both IPv4 and IPv6.  The proposed
+   hosts in this document have an API translator to communicate with
+   other IPv6 hosts using existing IPv4 applications.  The API
+   translator consists of 3 modules, a name resolver, an address mapper
+   and a function mapper.
+
+3.1 Function Mapper
+
+   It translates an IPv4 socket API function into an IPv6 socket API
+   function, and vice versa.
+
+
+
+Lee, et al.                   Experimental                      [Page 4]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+   When detecting the IPv4 socket API functions from IPv4 applications,
+   it intercepts the function call and invokes new IPv6 socket API
+   functions which correspond to the IPv4 socket API functions.  Those
+   IPv6 API functions are used to communicate with the target IPv6
+   hosts.  When detecting the IPv6 socket API functions from the data
+   received from the IPv6 hosts, it works symmetrically in relation to
+   the previous case.
+
+3.2 Name Resolver
+
+   It returns a proper answer in response to the IPv4 application's
+   request.
+
+   When an IPv4 application tries to resolve names via the resolver
+   library (e.g. gethostbyname()), BIA intercept the function call and
+   instead call the IPv6 equivalent functions (e.g. getnameinfo()) that
+   will resolve both A and AAAA records.
+
+   If the AAAA record is available, it requests the address mapper to
+   assign an IPv4 address corresponding to the IPv6 address, then
+   creates the A record for the assigned IPv4 address, and returns the A
+   record to the application.
+
+3.3 Address Mapper
+
+   It internally maintains a table of the pairs of an IPv4 address and
+   an IPv6 address.  The IPv4 addresses are assigned from an IPv4
+   address pool.  It uses the unassigned IPv4 addresses
+   (e.g., 0.0.0.1 ~ 0.0.0.255).
+
+   When the name resolver or the function mapper requests it to assign
+   an IPv4 address corresponding to an IPv6 address, it selects and
+   returns an IPv4 address out of the pool, and registers a new entry
+   into the table dynamically.  The registration occurs in the following
+   2 cases:
+
+   (1) When the name resolver gets only an 'AAAA' record for the target
+       host name and there is not a mapping entry for the IPv6 address.
+
+   (2) When the function mapper gets a socket API function call from the
+       data received and there is not a mapping entry for the IPv6
+       source address.
+
+   NOTE: This is the same as that of the Address Mapper in [BIS].
+
+
+
+
+
+
+
+Lee, et al.                   Experimental                      [Page 5]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+4. Behavior Examples
+
+   This section describes behaviors of the proposed dual stack host
+   called "dual stack", which communicates with an IPv6 host called
+   "host6" using an IPv4 application.
+
+   In this section, the meanings of arrows are as follows:
+
+       ---> A DNS message for name resolving created by the applications
+            and the name resolver in the API translator.
+       +++> An IPv4 address request to and reply from the address mapper
+            for the name resolver and the function mapper.
+       ===> Data flow by socket API functions created by the
+            applications and the function mapper in the API translator.
+
+4.1 Originator Behavior
+
+   This sub-section describes the behavior when the "dual stack" sends
+   data to "host6".
+
+   When an IPv4 application sends a DNS query to its name server, the
+   name resolver intercepts the query and then creates a new query to
+   resolve both A and AAAA records.  When only the AAAA record is
+   resolved, the name resolver requests the address mapper to assign an
+   IPv4 address corresponding to the IPv6 address.
+
+   The name resolver creates an A record for the assigned IPv4 address
+   and returns it to the IPv4 applications.
+
+   In order for the IPv4 application to send IPv4 packets to host6, it
+   calls the IPv4 socket API function.
+
+   The function mapper detects the socket API function from the
+   application.  If the result is from IPv6 applications, it skips the
+   translation.  In the case of IPv4 applications, it requires an IPv6
+   address to invoke the IPv6 socket API function, thus the function
+   mapper requests an IPv6 address to the address mapper.  The address
+   mapper selects an IPv4 address from the table and returns the
+   destination IPv6 address.  Using this IPv6 address, the function
+   mapper invokes an IPv6 socket API function corresponding to the IPv4
+   socket API function.
+
+   When the function mapper receives an IPv6 function call,it requests
+   the IPv4 address to the address mapper in order to translate the IPv6
+   socket API function into an IPv4 socket API function.  Then, the
+   function mapper invokes the socket API function for the IPv4
+   applications.
+
+
+
+
+Lee, et al.                   Experimental                      [Page 6]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+   Figure 2 illustrates the behavior described above:
+
+"dual stack"                                                "host6"
+IPv4    Socket |     [ API Translator ]    | TCP(UDP)/IP          Name
+appli-  API    |Name      Address  Function| (v6/v4)             Server
+cation         |Resolver  Mapper   Mapper  |
+ |        |        |        |        |         |              |       |
+<<Resolve an IPv4 address for "host6".>>       |              |       |
+ |        |        |        |        |         |              |       |
+ |--------|------->|  Query of 'A' records for host6.         |       |
+ |        |        |        |        |         |              |       |
+ |        |        |--------|--------|---------|--------------|------>|
+ |        |        |  Query of 'A' records and 'AAAA' for host6       |
+ |        |        |        |        |         |              |       |
+ |        |        |<-------|--------|---------|--------------|-------|
+ |        |        |  Reply with the 'AAAA' record.           |       |
+ |        |        |        |        |         |              |
+ |        |        |<<The 'AAAA' record is resolved.>>        |
+ |        |        |        |        |         |              |
+ |        |        |+++++++>|  Request one IPv4 address       |
+ |        |        |        |  corresponding to the IPv6 address.
+ |        |        |        |        |         |              |
+ |        |        |        |<<Assign one IPv4 address.>>     |
+ |        |        |        |        |         |              |
+ |        |        |<+++++++|  Reply with the IPv4 address.   |
+ |        |        |        |        |         |              |
+ |        |        |<<Create 'A' record for the IPv4 address.>>
+ |        |        |        |        |         |              |
+ |<-------|--------| Reply with the 'A' record.|              |
+ |        |        |        |        |         |              |
+
+              Figure 2 Behavior of the originator (1/2)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al.                   Experimental                      [Page 7]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+"dual stack"                                               "host6"
+IPv4    Socket |     [ API Translator ]    | TCP(UDP)/IP
+appli-  API    |Name      Address  Function| (v6/v4)
+cation         |Resolver  Mapper   Mapper  |
+ |        |        |        |        |         |              |
+<<Call IPv4 Socket API function >>   |         |              |
+ |        |        |        |        |         |              |
+ |========|========|========|=======>|An IPv4 Socket API function Call
+ |        |        |        |        |         |              |
+ |        |        |        |<+++++++|  Request IPv6 addresses|
+ |        |        |        |        |  corresponding to the  |
+ |        |        |        |        |  IPv4 addresses.       |
+ |        |        |        |        |         |              |
+ |        |        |        |+++++++>| Reply with the IPv6 addresses.
+ |        |        |        |        |         |              |
+ |        |        |        |        |<<Translate IPv4 into IPv6.>>
+ |        |        |        |        |         |              |
+ |  An IPv6 Socket API function call.|=========|=============>|
+ |        |        |        |        |         |              |
+ |        |        |        |        |<<Reply an IPv6 data    |
+ |        |        |        |        |  to dual stack.>>      |
+ |        |        |        |        |         |              |
+ |  An IPv6 Socket API function call.|<========|==============|
+ |        |        |        |        |         |              |
+ |        |        |        |        |<<Translate IPv6 into IPv4.>>
+ |        |        |        |        |         |              |
+ |        |        |        |<+++++++|  Request IPv4 addresses|
+ |        |        |        |        |  corresponding to the  |
+ |        |        |        |        |  IPv6 addresses.       |
+ |        |        |        |        |         |              |
+ |        |        |        |+++++++>| Reply with the IPv4 addresses.
+ |        |        |        |        |         |              |
+ |<=======|========|========|========|  An IPv4 Socket function call.
+ |        |        |        |        |         |              |
+
+              Figure 2 Behavior of the originator (2/2)
+
+4.2 Recipient Behavior
+
+   This subsection describes the recipient behavior of "dual stack".
+   The communication is triggered by "host6".
+
+   "host6" resolves the address of "dual stack" with 'AAAA' records
+   through its name server, and then sends an IPv6 packet to the "dual
+   stack".
+
+   The IPv6 packet reaches the "dual stack" and the function mapper
+   detects it.
+
+
+
+Lee, et al.                   Experimental                      [Page 8]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+   The function mapper requests the IPv4 address to the address mapper
+   in order to invoke the IPv4 socket API function to communicate with
+   the IPv4 application.  Then the function mapper invokes the
+   corresponding IPv4 socket API function for the IPv4 applications
+   corresponding to the IPv6 functions.
+
+   Figure 3 illustrates the behavior described above:
+
+   "dual stack"                                               "host6"
+   IPv4    Socket |     [ API Translator ]    | TCP(UDP)/IP
+   appli-  API    |Name      Address  Function| (v6/v4)
+   cation         |Resolver  Mapper   Mapper  |
+    |        |        |        |        |         |              |
+   <<Receive data from "host6".>>       |         |              |
+    |        |        |        |        |         |              |
+    |      An IPv6 Socket function call.|<========|==============|
+    |        |        |        |        |         |              |
+    |        |        |        |<+++++++|  Request IPv4 addresses|
+    |        |        |        |        |  corresponding to the IPv6
+    |        |        |        |        |  addresses.            |
+    |        |        |        |        |         |              |
+    |        |        |        |+++++++>| Reply with the IPv4 addresses.
+    |        |        |        |        |         |              |
+    |        |        |        |        |<<Translate IPv6 into IPv4.>>
+    |        |        |        |        |         |              |
+    |<=======|========|========|========|  An IPv4 function call |
+    |        |        |        |        |         |              |
+   <<Reply an IPv4 data to "host6".>>   |         |              |
+    |        |        |        |        |         |              |
+    |========|========|========|=======>|  An IPv4 function call |
+    |        |        |        |        |         |              |
+    |        |        |        |        |<<Translate IPv4 into IPv6.>>
+    |        |        |        |        |         |              |
+    |        |        |        |<+++++++|  Request IPv6 addresses|
+    |        |        |        |        |  corresponding to the IPv4
+    |        |        |        |        |  addresses.            |
+    |        |        |        |        |         |              |
+    |        |        |        |+++++++>| Reply with the IPv6 addresses.
+    |        |        |        |        |         |              |
+    |      An IPv6 Socket function call.|=========|=============>|
+    |        |        |        |        |         |              |
+
+             Figure 3 Behavior of Receiving data from IPv6 host
+
+
+
+
+
+
+
+
+Lee, et al.                   Experimental                      [Page 9]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+5. Considerations
+
+5.1 Socket API Conversion
+
+   IPv4 socket API functions are translated into semantically the same
+   IPv6 socket API functions and vice versa.  See Appendix A for the API
+   list intercepted by BIA.  IP addresses embedded in application layer
+   protocols (e.g., FTP) can be translated in API functions.  Its
+   implementation depends on operating systems.
+
+   NOTE: Basically, IPv4 socket API functions are not fully compatible
+   with IPv6 since the IPv6 has new advanced features.
+
+5.2 ICMP Message Handling
+
+   When an application needs ICMP messages values (e.g., Type, Code,
+   etc.) sent from a network layer, ICMPv4 message values MAY be
+   translated into ICMPv6 message values based on [SIIT], and vice
+   versa.  It can be implemented using raw socket.
+
+5.3 IPv4 Address Pool and Mapping Table
+
+   The address pool consists of the unassigned IPv4 addresses.  This
+   pool can be implemented at different granularity in the node e.g., a
+   single pool per node, or at some finer granularity such as per user
+   or per process.  However, if a number of IPv4 applications
+   communicate with IPv6 hosts, the available address spaces will be
+   exhausted.  As a result, it will be impossible for IPv4 applications
+   to communicate with IPv6 nodes.  It requires smart management
+   techniques for address pool.  For example, it is desirable for the
+   mapper to free the oldest entry and reuse the IPv4 address for
+   creating a new entry.  This issues is the same as [BIS].  In case of
+   a per-node address mapping table, it MAY cause a larger risk of
+   running out of address.
+
+5.4 Internally Assigned IPv4 Addresses
+
+   The IPv4 addresses, which are internally assigned to IPv6 target
+   hosts out of the pool, are the unassigned IPv4 addresses (e.g.,
+   0.0.0.1 ~ 0.0.0.255).  There is no potential collision with another
+   use of the private address space when the IPv4 address flows out from
+   the host.
+
+
+
+
+
+
+
+
+
+Lee, et al.                   Experimental                     [Page 10]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+5.5 Mismatch between DNS result(AAAA) and Peer Application
+    Version(v4)
+
+   If a server application you are using does not support IPv6 yet, but
+   runs on a machine that supports other IPv6 services and this is
+   listed with a AAAA record in the DNS, a client IPv4 application using
+   BIA might fail to connect to the server application, because there is
+   a mismatch between DNS query result (i.e., AAAA) and a server
+   application version(i.e., IPv4).  A solution is to try all the
+   addresses listed in the DNS and just not fail after the first
+   attempt.  We have two approaches:  the client application itself
+   SHOULD cycle through all the addresses and end up trying the IPv4
+   one.  Or it SHOULD be done by some extensions of name resolver and
+   API translator in BIA.  For this, BIA SHOULD do iterated jobs for
+   finding the working address used by the other application out of
+   addresses returned by the extended name resolver.  It may very well
+   be application dependent.  Note that BIA might be able to do the
+   iteraction over all addresses for TCP sockets, since BIA can observe
+   when the connect call fails.  But for UDP sockets it is hard if not
+   impossible for BIA to know which address worked, hence the
+   application must do the iteraction over all addresses until it finds
+   a working address.
+
+   Another way to avoid this type of problems is to make BIA only come
+   into effect when no A records exist for the peer.  Thus traffic from
+   an application using BIA on a dual-stack host to a dual-stack host
+   would use IPv4.
+
+5.6 Implementation Issues
+
+   Some operating systems support the preload library functions, so it
+   is easy to implement the API translator by using it.  For example,
+   the user can replace all existing socket API functions with user-
+   defined socket API functions which translate the socket API function.
+   In this case, every IPv4 application has its own translation library
+   using a preloaded library which will be bound into the application
+   before executing it dynamically.
+
+   Some other operating systems support the user-defined layered
+   protocol allowing a user to develop some additional protocols and put
+   them in the existing protocol stack.  In this case, the API
+   translator can be implemented as a layered protocol module.
+
+   In the above two approaches, it is assumed that there exists both
+   TCP(UDP)/IPv4 and TCP(UDP)/IPv6 stacks and there is no need to modify
+   or to add a new TCP-UDP/IPv6 stack.
+
+
+
+
+
+Lee, et al.                   Experimental                     [Page 11]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+6. Limitations
+
+   In common with [NAT-PT], BIA needs to translate IP addresses embedded
+   in application layer protocols, e.g., FTP.  So it may not work for
+   new applications which embed addresses in payloads.
+
+   This mechanism supports unicast communications only.  In order to
+   support multicast functions, some other additional functionalities
+   must be considered in the function mapper module.
+
+   Since the IPv6 API has new advanced features, it is difficult to
+   translate such kinds of IPv6 APIs into IPv4 APIs.  Thus, IPv6 inbound
+   communication with advanced features may be discarded.
+
+7. Security Considerations
+
+   The security consideration of BIA mostly relies on that of [NAT-PT].
+   The differences are due to the address translation occurring at the
+   API and not in the network layer.  That is, since the mechanism uses
+   the API translator at the socket API level, hosts can utilize the
+   security of the network layer (e.g., IPsec) when they communicate
+   with IPv6 hosts using IPv4 applications via the mechanism.  As well,
+   there isn't a DNS ALG as in NAT-PT, so there is no interference with
+   DNSSEC.
+
+   The use of address pooling may open a denial of service attack
+   vulnerability.  So BIA should employ the same sort of protection
+   techniques as [NAT-PT] does.
+
+8. Acknowledgments
+
+   We would like to acknowledge the implementation contributions by
+   Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation
+   (www.i2soft.net).
+
+9. References
+
+   [TRANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+                IPv6 Hosts and Routers", RFC 2893, August 2000.
+
+   [SIIT]       Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC
+                2765, February 2000.
+
+   [FTP]        Postel, J. and J. Reynolds, "File Transfer Protocol",
+                STD 9, RFC 959, October 1985.
+
+
+
+
+
+
+Lee, et al.                   Experimental                     [Page 12]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+   [NAT]        Srisuresh, P. and K. Egevang, "Traditional IP Network
+                Address Translator (Traditional NAT)", RFC 3022, January
+                2001.
+
+   [IPV4]       Postel, J., "Internet Protocol", STD 5, RFC 791,
+                September 1981.
+
+   [IPV6]       Deering, S. and R. Hinden, "Internet Protocol, Version 6
+                (IPv6) Specification", RFC 2460, December 1998.
+
+   [NAT-PT]     Tsirtsis, G. and P. Srisuresh, "Network Address
+                Translation - Protocol Translation (NAT-PT)", RFC 2766,
+                February 2000.
+
+   [BIS]        Tsuchiya, K., Higuchi, H. and Y. Atarashi, "Dual Stack
+                Hosts using the "Bump-In-the-Stack" Technique (BIS)",
+                RFC 2767, February 2000.
+
+   [SOCK-EXT]   Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
+                "Basic Socket Interface Extensions for IPv6", RFC 2553,
+                March 1999.
+
+   [RFC 2119]   Bradner S., "Key words for use in RFCs to indicate
+                Requirement Levels", RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al.                   Experimental                     [Page 13]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+Appendix A : API list intercepted by BIA
+
+   The following functions are the API list which SHOULD be intercepted
+   by BIA module.
+
+   The functions that the application uses to pass addresses into the
+   system are:
+
+      bind()
+      connect()
+      sendmsg()
+      sendto()
+
+   The functions that return an address from the system to an
+   application are:
+
+      accept()
+      recvfrom()
+      recvmsg()
+      getpeername()
+      getsockname()
+
+   The functions that are related to socket options are:
+
+      getsocketopt()
+      setsocketopt()
+
+   The functions that are used for conversion of IP addresses embedded
+   in application layer protocol (e.g., FTP, DNS, etc.) are:
+
+      recv()
+      send()
+      read()
+      write()
+
+   As well, raw sockets for IPv4 and IPv6 MAY be intercepted.
+
+   Most of the socket functions require a pointer to the socket address
+   structure as an argument.  Each IPv4 argument is mapped into
+   corresponding an IPv6 argument, and vice versa.
+
+   According to [SOCK-EXT], the following new IPv6 basic APIs and
+   structures are required.
+
+
+
+
+
+
+
+
+Lee, et al.                   Experimental                     [Page 14]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+      IPv4                     new IPv6
+      ------------------------------------------------
+      AF_INET                  AF_INET6
+      sockaddr_in              sockaddr_in6
+      gethostbyname()          getaddrinfo()
+      gethostbyaddr()          getnameinfo()
+      inet_ntoa()/inet_addr()  inet_pton()/inet_ntop()
+      INADDR_ANY               in6addr_any
+
+   BIA MAY intercept inet_ntoa() and inet_addr() and use the address
+   mapper for those.  Doing that enables BIA to support literal IP
+   addresses.
+
+   The gethostbyname() call return a list of addresses.  When the name
+   resolver function invokes getaddrinfo() and  getaddrinfo() returns
+   multiple IP addresses, whether IPv4 or IPv6, they SHOULD all be
+   represented in the addresses returned by gethostbyname().  Thus if
+   getaddrinfo() returns multiple IPv6 addresses, this implies that
+   multiple address mappings will be created; one for each IPv6 address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al.                   Experimental                     [Page 15]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+Authors' Addresses
+
+   Seungyun Lee
+   ETRI PEC
+   161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea
+   Tel: +82 42 860 5508
+   Fax: +82 42 861 5404
+   EMail: syl@pec.etri.re.kr
+
+   Myung-Ki Shin
+   ETRI PEC
+   161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea
+   Tel: +82 42 860 4847
+   Fax: +82 42 861 5404
+   EMail: mkshin@pec.etri.re.kr
+
+   Yong-Jin Kim
+   ETRI
+   161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea
+   Tel: +82 42 860 6564
+   Fax: +82 42 861 1033
+   EMail: yjkim@pec.etri.re.kr
+
+   Alain Durand
+   Sun Microsystems, inc.
+   25 Network circle
+   Menlo Park, CA 94025, USA
+   Fax: +1 650 786 5896
+   EMail: Alain.Durand@sun.com
+
+   Erik Nordmark
+   Sun Microsystems Laboratories
+   180, avenue de l'Europe
+   38334 SAINT ISMIER Cedex, France
+   Tel: +33 (0)4 76 18 88 03
+   Fax: +33 (0)4 76 18 88 88
+   EMail: erik.nordmark@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al.                   Experimental                     [Page 16]
+
+RFC 3338               Dual Stack Hosts Using BIA           October 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al.                   Experimental                     [Page 17]
+