From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3338.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc3338.txt (limited to 'doc/rfc/rfc3338.txt') 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 | + | | | | | | | | +<> | | | + | | | | | | | | + |--------|------->| Query of 'A' records for host6. | | + | | | | | | | | + | | |--------|--------|---------|--------------|------>| + | | | Query of 'A' records and 'AAAA' for host6 | + | | | | | | | | + | | |<-------|--------|---------|--------------|-------| + | | | Reply with the 'AAAA' record. | | + | | | | | | | + | | |<> | + | | | | | | | + | | |+++++++>| Request one IPv4 address | + | | | | corresponding to the IPv6 address. + | | | | | | | + | | | |<> | + | | | | | | | + | | |<+++++++| Reply with 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 | + | | | | | | | +<> | | | + | | | | | | | + |========|========|========|=======>|An IPv4 Socket API function Call + | | | | | | | + | | | |<+++++++| Request IPv6 addresses| + | | | | | corresponding to the | + | | | | | IPv4 addresses. | + | | | | | | | + | | | |+++++++>| Reply with the IPv6 addresses. + | | | | | | | + | | | | |<> + | | | | | | | + | An IPv6 Socket API function call.|=========|=============>| + | | | | | | | + | | | | |<> | + | | | | | | | + | An IPv6 Socket API function call.|<========|==============| + | | | | | | | + | | | | |<> + | | | | | | | + | | | |<+++++++| 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 | + | | | | | | | + <> | | | + | | | | | | | + | An IPv6 Socket function call.|<========|==============| + | | | | | | | + | | | |<+++++++| Request IPv4 addresses| + | | | | | corresponding to the IPv6 + | | | | | addresses. | + | | | | | | | + | | | |+++++++>| Reply with the IPv4 addresses. + | | | | | | | + | | | | |<> + | | | | | | | + |<=======|========|========|========| An IPv4 function call | + | | | | | | | + <> | | | + | | | | | | | + |========|========|========|=======>| An IPv4 function call | + | | | | | | | + | | | | |<> + | | | | | | | + | | | |<+++++++| 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] + -- cgit v1.2.3