draft-ietf-v6ops-application-transition-02.txt   draft-ietf-v6ops-application-transition-03.txt 
v6ops Working Group M-K. Shin (ed.) v6ops Working Group M-K. Shin (ed.)
INTERNET DRAFT Y-G. Hong INTERNET DRAFT ETRI/NIST
Expires: September 2004 ETRI Expires: December 2004 Y-G. Hong
ETRI
J. Hagino J. Hagino
IIJ IIJ
P. Savola P. Savola
CSC/FUNET CSC/FUNET
E. M. Castro E. M. Castro
GSYC/URJC GSYC/URJC
March 2004 June 2004
Application Aspects of IPv6 Transition Application Aspects of IPv6 Transition
<draft-ietf-v6ops-application-transition-02.txt> <draft-ietf-v6ops-application-transition-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
Internet Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsolete by other documents months and may be updated, replaced, or obsoleted by other docu-
at anytime. It is inappropriate to use Internet Drafts as reference ments at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2004.
Abstract Abstract
As IPv6 networks are deployed and the network transition discussed, As IPv6 networks are deployed and the network transition discussed,
one should also consider how to enable IPv6 support in applications one should also consider how to enable IPv6 support in applications
running on IPv6 hosts, and the best strategy to develop IP protocol running on IPv6 hosts, and the best strategy to develop IP protocol
support in applications. This document specifies scenarios and support in applications. This document specifies scenarios and
aspects of application transition. It also proposes guidelines on aspects of application transition. It also proposes guidelines on
how to develop IP version-independent applications during the how to develop IP version-independent applications during the
transition period. transition period.
skipping to change at page 2, line 29 skipping to change at page 2, line 29
5.1 Presentation Format for an IP address ...................12 5.1 Presentation Format for an IP address ...................12
5.2 Transport Layer API .....................................13 5.2 Transport Layer API .....................................13
5.3 Name and Address Resolution .............................14 5.3 Name and Address Resolution .............................14
5.4 Specific IP Dependencies ............................... 14 5.4 Specific IP Dependencies ............................... 14
5.4.1 IP Address Selection .................................14 5.4.1 IP Address Selection .................................14
5.4.2 Application Framing ..................................15 5.4.2 Application Framing ..................................15
5.4.3 Storage of IP addresses ..............................15 5.4.3 Storage of IP addresses ..............................15
5.5 Multicast Applications ..................................16 5.5 Multicast Applications ..................................16
6. Developing IP version-independent Applications ............17 6. Developing IP version-independent Applications ............17
6.1 IP version-independent Structures .......................17 6.1 IP version-independent Structures .......................17
6.2 IP version-independent APIs .............................17 6.2 IP version-independent APIs .............................18
6.2.1 Example of Overly Simplistic TCP Server Application ..18 6.2.1 Example of Overly Simplistic TCP Server Application ..19
6.2.2 Example of Overly Simplistic TCP Client Application ..19 6.2.2 Example of Overly Simplistic TCP Client Application ..20
6.2.3 Binary/Presentation Format Conversion ................20 6.2.3 Binary/Presentation Format Conversion ................21
6.3 Iterated Jobs for Finding the Working Address ...........21 6.3 Iterated Jobs for Finding the Working Address ...........22
6.3.1 Example of TCP Server Application ....................21 6.3.1 Example of TCP Server Application ....................22
6.3.2 Example of TCP Client Application ....................24 6.3.2 Example of TCP Client Application ....................23
7. Transition Mechanism Considerations .......................24 7. Transition Mechanism Considerations .......................24
8. Security Considerations ...................................24 8. Security Considerations ...................................25
9. Acknowledgements .........................................25 9. Acknowledgements .........................................25
10. References ...............................................25 10. References ...............................................25
Authors' Addresses ...........................................27 Authors' Addresses ...........................................27
Appendix A. Other Binary/Presentation Format Conversions .....27 Appendix A. Other Binary/Presentation Format Conversions .....28
A.1 Binary to Presentation using inet_ntop() ................28 A.1 Binary to Presentation using inet_ntop() ................28
A.2 Presentation to Binary using inet_pton() ................28 A.2 Presentation to Binary using inet_pton() ................29
1. Introduction 1. Introduction
As IPv6 is introduced in the IPv4-based Internet, several general As IPv6 is introduced in the IPv4-based Internet, several general
issues arise such as routing, addressing, DNS, scenarios, etc. issues arise such as routing, addressing, DNS, scenarios, etc.
One important key to a successful IPv6 transition is the One important key to a successful IPv6 transition is the
compatibility with the large installed base of IPv4 hosts and compatibility with the large installed base of IPv4 hosts and
routers. This issue had been already been extensively studied, and routers. This issue had been already been extensively studied, and
the work is still in progress. In particular, [2893BIS] describes the work is still in progress. In particular, [2893BIS] describes
skipping to change at page 6, line 5 skipping to change at page 6, line 5
The issue of DNS name resolution related to application transition, The issue of DNS name resolution related to application transition,
is that a client application can not be certain of the version of is that a client application can not be certain of the version of
the peer application by only doing a DNS name lookup. For example, the peer application by only doing a DNS name lookup. For example,
if a server application does not support IPv6 yet, but runs on a if a server application does not support IPv6 yet, but runs on a
dual-stack machine for other IPv6 services, and this host is listed dual-stack machine for other IPv6 services, and this host is listed
with a AAAA record in the DNS, the client application will fail to with a AAAA record in the DNS, the client application will fail to
connect to the server application. This is caused by a mis-match connect to the server application. This is caused by a mis-match
between the DNS query result (i.e. IPv6 addresses) and a server between the DNS query result (i.e. IPv6 addresses) and a server
application version (i.e. IPv4). application version (i.e. IPv4).
It is bad practise to add an AAAA record for a node that does not Using SRV records would avoid these problems. Unfortunately, they
support all the services using IPv6 (rather, an AAAA record for the are not sufficiently widely used to be applicable in most cases.
specific service name and address should be used). However, the Hence an operational technique is to use "service names" in the
application cannot depend on "good practise", and this must be DNS, that is, if a node is offering multiple services, but only
handled. some of them over IPv6, add a DNS name for each of these services
(with the associated A/AAAA records), not just a single name for
the whole node, also including the AAAA records. However, the
applications cannot depend on such operational practices.
In consequence, the application should request all IP addresses In consequence, the application should request all IP addresses
without address family constraints and try all the records returned without address family constraints and try all the records returned
from the DNS, in some order, until a working address is found. In from the DNS, in some order, until a working address is found. In
particular, the application has to be able to handle all IP particular, the application has to be able to handle all IP
versions returned from the DNS. This issue is discussed in more versions returned from the DNS. This issue is discussed in more
detail in [DNSOPV6]. detail in [DNSOPV6].
3.3 Supporting many versions of an application is difficult 3.3 Supporting many versions of an application is difficult
During the application transition period, system administrators may During the application transition period, system administrators may
have various versions of the same application (an IPv4-only have various versions of the same application (an IPv4-only
application, an IPv6-only application, or an application supporting application, an IPv6-only application, or an application supporting
both IPv4 and IPv6). both IPv4 and IPv6).
Typically one cannot know which IP versions must be supported prior Typically one cannot know which IP versions must be supported prior
to doing a DNS lookup *and* trying (see section 3.2) the addresses to doing a DNS lookup *and* trying (see section 3.2) the addresses
returned. Therefore, the users have a difficulty selecting the returned. Therefore, the local users have a difficulty selecting
right application version supporting the exact IP version required the right application version supporting the exact IP version
if multiple versions of the same application are available. required if multiple versions of the same application are
available.
To avoid problems with one application not supporting the specified To avoid problems with one application not supporting the specified
protocol version, it is desirable to have hybrid applications protocol version, it is desirable to have hybrid applications
supporting both of the protocol versions. supporting both of the protocol versions.
An alternative approach is to have a "wrapper application" which One could argue that an alternative approach for local client
applications could be to have a "wrapper application" which
performs certain tasks (like figures out which protocol version performs certain tasks (like figures out which protocol version
will be used) and calls the IPv4/IPv6-only applications as will be used) and calls the IPv4/IPv6-only applications as
necessary. However, these wrapper applications will actually have necessary. In other words, such applications would perform
to do more than just perform a DNS lookup or figure out the literal connection establishment (or similar), and pass the opened socket
IP address given. Thus, they may get complex, and only work for to the other application. However, as these applications would
certain kinds of, usually simple, applications. have to do more than just perform a DNS lookup or figure out the
literal IP address given, they will get complex -- likely much more
Nonetheless, there should be some reasonable logic to enable the complex than writing a hybrid application. Furthermore, "wrapping"
users to use the applications with any supported protocol version; applications which perform complex operations with IP addresses
the users should not have to select from various versions of (like FTP clients) might be even more challenging or even
applications, some supporting only IPv4, others only IPv6, and yet impossible. In summary, wrapper applications does not look like a
some both versions by themselves. robust approach for application transition.
4. Description of Transition Scenarios and Guidelines 4. Description of Transition Scenarios and Guidelines
Once the IPv6 network is deployed, applications supporting IPv6 can Once the IPv6 network is deployed, applications supporting IPv6 can
use IPv6 network services and establish IPv6 connections. However, use IPv6 network services and establish IPv6 connections. However,
upgrading every node to IPv6 at the same time is not feasible and upgrading every node to IPv6 at the same time is not feasible and
transition from IPv4 to IPv6 will be a gradual process. transition from IPv4 to IPv6 will be a gradual process.
Dual-stack nodes are one of the ways to maintain IPv4 compatibility Dual-stack nodes are one of the ways to maintain IPv4 compatibility
in unicast communications. In this section we will analyze in unicast communications. In this section we will analyze
skipping to change at page 7, line 24 skipping to change at page 7, line 31
IPv6-capable applications aren't yet available or installed. IPv6-capable applications aren't yet available or installed.
Although the node implements the dual stack, IPv4 applications can Although the node implements the dual stack, IPv4 applications can
only manage IPv4 communications. Then, IPv4 applications can only only manage IPv4 communications. Then, IPv4 applications can only
accept/establish connections from/to nodes which implement an IPv4 accept/establish connections from/to nodes which implement an IPv4
stack. stack.
In order to allow an application to communicate with other nodes In order to allow an application to communicate with other nodes
using IPv6, the first priority is to port applications to IPv6. using IPv6, the first priority is to port applications to IPv6.
In some cases (e.g. no source code is available), existing IPv4 In some cases (e.g. no source code is available), existing IPv4
applications can work if the [BIS] or [BIA] mechanism is installed applications can work if the Bump-in-the-Stack [BIS] or Bump-in-
in the node. However, these mechanisms should not be used when the-API [BIA] mechanism is installed in the node. We strongly
application source code is available to prevent their mis-use, for recommend that application developers sould not use these
example, as an excuse not to port software. mechanisms when application source code is available. Also, it
should not be used as an excuse not to port software or delay
porting.
When [BIA] or [BIS] is used, the problem described in section 3.2 When [BIA] or [BIS] is used, the problem described in section 3.2
--the IPv4 client in a [BIS]/[BIA] node trying to connect to an --the IPv4 client in a [BIS]/[BIA] node trying to connect to an
IPv4 server in a dual stack system-- arises. However, one can rely IPv4 server in a dual stack system-- arises. However, one can rely
on the [BIA]/[BIS] mechanism, which should cycle through all the on the [BIA]/[BIS] mechanism, which should cycle through all the
addresses instead of applications. addresses instead of applications.
[BIS] or [BIA] does not work with all kinds of applications. In [BIS] or [BIA] does not work with all kinds of applications. In
particular, the applications which exchange IP addresses as particular, the applications which exchange IP addresses as
application data (e.g., FTP). These mechanisms provide IPv4 application data (e.g., FTP). These mechanisms provide IPv4
skipping to change at page 11, line 14 skipping to change at page 11, line 21
4.4. IPv4/IPv6 Applications in an IPv4-only Node 4.4. IPv4/IPv6 Applications in an IPv4-only Node
As the transition is likely to happen over a longer timeframe, As the transition is likely to happen over a longer timeframe,
applications that have already been ported to support both IPv4 and applications that have already been ported to support both IPv4 and
IPv6 may be run on IPv4-only nodes. This would typically be done to IPv6 may be run on IPv4-only nodes. This would typically be done to
avoid having to support two application versions for older and avoid having to support two application versions for older and
newer operating systems, or to support the case that the user wants newer operating systems, or to support the case that the user wants
to disable IPv6 for some reason. to disable IPv6 for some reason.
The most important case is the application support on systems where
IPv6 support can be dynamically enabled or disabled by the users.
Applications on such a system should be able to handle the
situation where IPv6 would not be enabled. The secondary scenario
is when an application could be deployed on older systems which do
not support IPv6 at all (even the basic getaddrinfo etc. APIs). In
that case the application designer has to make a case-by-case
judgement call whether it makes sense to have compile-time toggle
between an older and newer API (having to support both in the
code), or whether to provide getaddrinfo etc. function support on
older platforms as part of the application libraries.
Depending on how application/operating system support is done, some Depending on how application/operating system support is done, some
may want to ignore this case, but usually no assumptions can be may want to ignore this case, but usually no assumptions can be
made and applications should also work in this scenario. made and applications should also work in this scenario.
An example is an application that issues a socket() command, first An example is an application that issues a socket() command, first
trying AF_INET6 and then AF_INET. However, if the kernel does not trying AF_INET6 and then AF_INET. However, if the kernel does not
have IPv6 support, the call will result in an EPROTONOSUPPORT or have IPv6 support, the call will result in an EPROTONOSUPPORT or
EAFNOSUPPORT error. Typically, encountering errors like these leads EAFNOSUPPORT error. Typically, encountering errors like these leads
to exiting the socket loop, and AF_INET will not even be tried. to exiting the socket loop, and AF_INET will not even be tried.
The application will need to handle this case or build the loop in The application will need to handle this case or build the loop in
skipping to change at page 12, line 35 skipping to change at page 13, line 4
presentation format. presentation format.
Usually, the allocated memory to contain an IPv4 address Usually, the allocated memory to contain an IPv4 address
representation as a string is unable to contain an IPv6 address. representation as a string is unable to contain an IPv6 address.
Applications should be modified to prevent buffer overflows made Applications should be modified to prevent buffer overflows made
possible by the larger IPv6 address. possible by the larger IPv6 address.
IPv4 and IPv6 do not use the same presentation format. IPv4 uses a IPv4 and IPv6 do not use the same presentation format. IPv4 uses a
dot (.) to separate the four octets written in decimal notation and dot (.) to separate the four octets written in decimal notation and
IPv6 uses a colon (:) to separate each pair of octets written in IPv6 uses a colon (:) to separate each pair of octets written in
hexadecimal notation. In order to support both IPv4 and IPv6, the hexadecimal notation [RFC 3513]. In cases where it one must be
management functions of presentation format, such as IP address able to specify e.g., port numbers with the address (see below), it
parsers, should be changed to be compliant with both of the formats may be desirable to require placing the address inside the square
[TextRep]. brackets [TextRep].
A particular problem with IP address parsers comes when the input A particular problem with IP address parsers comes when the input
is actually a combination of IP address and port number. With IPv4 is actually a combination of IP address and port number. With IPv4
these are often coupled with a semi-colon such as "192.0.2.1:80". these are often coupled with a colon such as "192.0.2.1:80".
However, such an approach would be ambiguous with IPv6 as colons However, such an approach would be ambiguous with IPv6 as colons
are already used to structure the address. are already used to structure the address.
Therefore, the IP address parsers which take the port number Therefore, the IP address parsers which take the port number
separated with a colon should represent IPv6 addresses somehow. separated with a colon should represent IPv6 addresses somehow.
One way is to enclose the address in brackets, as is done with One way is to enclose the address in brackets, as is done with
Uniform Resource Locators (URLs) [RFC 2732], like Uniform Resource Locators (URLs) [RFC 2732], like
http://[2001:db8::1]:80. http://[2001:db8::1]:80.
Prefix/len format should be also considered if surrounding brackets Some applications also need to specify IPv6 prefixes and lengths;
are used. In order to avoid ambiguity, the format, like the prefix length should be inserted outside of the square
[2001:db8::]/64 is recommended. brackets, if used, like [2001:db8::]/64 or 2001:db8::/64 -- not for
example [2001:db8::/64]. Note that prefix/length notation is
syntactically indistinguishable from a legal URI; therefore the
prefix/length notation must not be used when it isn't clear from
the context that it's used to specify the prefix and length and
not e.g., a URI.
In some specific cases, it may be necessary to give a zone In some specific cases, it may be necessary to give a zone
identifier as part of the address, like fe80::1%eth0. In general, identifier as part of the address, like fe80::1%eth0. In general,
applications should not need to parse these identifiers. applications should not need to parse these identifiers.
The IP address parsers should support enclosing the IPv6 address in The IP address parsers should support enclosing the IPv6 address in
brackets even when it's not used in conjunction with a port number, brackets even when it's not used in conjunction with a port number,
but requiring that the user always gives a literal IP address but requiring that the user always gives a literal IP address
enclosed in brackets is not recommended. enclosed in brackets is not recommended.
skipping to change at page 14, line 29 skipping to change at page 15, line 5
reviewed to support the new IPv6 resolution calls. reviewed to support the new IPv6 resolution calls.
There are two basic resolution functions. The first function There are two basic resolution functions. The first function
returns a list of all configured IP addresses for a hostname. These returns a list of all configured IP addresses for a hostname. These
queries can be constrained to one protocol family, for instance queries can be constrained to one protocol family, for instance
only IPv4 or only IPv6 addresses. However, the recommendation is only IPv4 or only IPv6 addresses. However, the recommendation is
that all configured IP addresses should be obtained to allow that all configured IP addresses should be obtained to allow
applications to work with every kind of node. And the second applications to work with every kind of node. And the second
function returns the hostname associated to an IP address. function returns the hostname associated to an IP address.
5.4. Specific IP Dependencies 5.4 Specific IP Dependencies
5.4.1 IP Address Selection 5.4.1 IP Address Selection
IPv6 promotes the configuration of multiple IP addresses per node, IPv6 promotes the configuration of multiple IP addresses per node,
which is a difference when compared with the IPv4 model; however which is a difference when compared with the IPv4 model; however
applications only use a destination/source pair for a applications only use a destination/source pair for a
communication. Choosing the right IP source and destination communication. Choosing the right IP source and destination
addresses is a key factor that may determine the route of IP addresses is a key factor that may determine the route of IP
datagrams. datagrams.
skipping to change at page 15, line 23 skipping to change at page 15, line 48
5.4.2 Application Framing 5.4.2 Application Framing
The Application Level Framing (ALF) architecture controls The Application Level Framing (ALF) architecture controls
mechanisms that traditionally fall within the transport layer. mechanisms that traditionally fall within the transport layer.
Applications implementing ALF are often responsible for packetizing Applications implementing ALF are often responsible for packetizing
data into Application Data Units (ADUs). The application problem data into Application Data Units (ADUs). The application problem
when using ALF is the ADU size selection to obtain better when using ALF is the ADU size selection to obtain better
performance. performance.
Application framing is typically needed by applications using Application framing is typically needed by applications using
connectionless protocols (such as UDP). The application will have connectionless protocols (such as UDP). Such applications have
to know, or be able to detect, the packet sizes which can be sent three choices: (1) to use packet sizes no larger than IPv6 IPv6
and received, end-to-end, on the network. minimum Maximum Transmission Unit (MTU) of 1280 bytes [RFC2460],
(2) to use whatever packet sizes but force IPv6
Applications can use 1280 octets as a data length: every IPv6 link fragmentation/reassembly when necessary, or (3) to optimize the
must have a Maximum Transmission Unit (MTU) of 1280 octets or packet size and avoid unnecessary fragmentation/reassembly, guess
greater [RFC 2460]. However, in order to get better performance, or find out the optimal packet sizes which can be sent and
ADU size should be calculated based on the length of transmission received, end-to-end, on the network. This memo takes no stance on
unit of underlying protocols. which approach to adopt.
Note that the most optimal ALF depends on dynamic factors such as Note that the most optimal ALF depends on dynamic factors such as
Path MTU or whether IPv4 or IPv6 is being used (due to different Path MTU or whether IPv4 or IPv6 is being used (due to different
header sizes, possible IPv6-in-IPv4 tunneling overhead, etc.). header sizes, possible IPv6-in-IPv4 tunneling overhead, etc.).
These have to be taken into consideration when implementing These have to be taken into consideration when implementing
application framing. application framing.
5.4.3 Storage of IP Addresses 5.4.3 Storage of IP Addresses
Some applications store IP addresses as information of remote Some applications store IP addresses as information of remote
skipping to change at page 17, line 48 skipping to change at page 18, line 22
struct sockaddr_storage ss; struct sockaddr_storage ss;
int sslen; int sslen;
/* AF independent! - use sockaddr when passing a pointer */ /* AF independent! - use sockaddr when passing a pointer */
/* note: it's typically necessary to also pass the length /* note: it's typically necessary to also pass the length
explicitly */ explicitly */
foo((struct sockaddr *)&ss, sslen); foo((struct sockaddr *)&ss, sslen);
6.2 IP version-independent APIs 6.2 IP version-independent APIs
getaddrinfo() and getnameinfo() are new address independent getaddrinfo() and getnameinfo() are new address independent
variants that hide the gory details of name-to-address and variants that hide the gory details of name-to-address and address-
address-to-name translations. They implement functionalities of to-name translations. They implement functionalities of the
the following functions: following functions:
gethostbyname() gethostbyname()
gethostbyaddr() gethostbyaddr()
getservbyname() getservbyname()
getservbyport() getservbyport()
They also obsolete the functionality of gethostbyname2(), defined They also obsolete the functionality of gethostbyname2(), defined
in [RFC2133]. in [RFC2133].
These can perform hostname/address and service name/port lookups, These can perform hostname/address and service name/port lookups,
skipping to change at page 24, line 46 skipping to change at page 25, line 22
There are a number of security considerations with IPv6 transition There are a number of security considerations with IPv6 transition
but those are outside the scope of this memo. but those are outside the scope of this memo.
To ensure the availability and robustness of the service even when To ensure the availability and robustness of the service even when
transitioning to IPv6, this memo described a number of ways to make transitioning to IPv6, this memo described a number of ways to make
applications more resistant to failures by cycling through applications more resistant to failures by cycling through
addresses until a working one is found. Doing this properly is addresses until a working one is found. Doing this properly is
critical to avoid unavailability and loss of service. critical to avoid unavailability and loss of service.
One particular point about application transition is how IPv4- One particular point about application transition is how
mapped IPv6-addresses are handled. The use in the API can be seen IPv4-mapped IPv6 addresses are handled. The use in the API can be
as both a merit (easier application transition) and as a burden seen as both a merit (easier application transition) and as a
(difficulty in ensuring whether the use was legimate) [V6MAPPED]. burden (difficulty in ensuring whether the use was legimate) Note
This should be considered in more detail when designing that some systems will disable (by default) support for internal
applications. IPv4-mapped IPv6 addresses. The security concerns regarding
IPv4-mapped IPv6 addresses on the wire are legitimate but disabling
it internally breaks one transition mechanism for server
applications which were originally written to bind() and listen()
to a single socket using a wildcard address [V6MAPPED]. This
should be considered in more detail when designing applications.
9. Acknowledgements 9. Acknowledgements
Some of guidelines for development of IP version-independent Some of guidelines for development of IP version-independent
applications (section 6) were first brought up by [AF-APP]. Other applications (section 6) were first brought up by [AF-APP]. Other
work to document application porting guidelines has also been in work to document application porting guidelines has also been in
progress, for example [IP-GGF] and [PRT]. We would like to thank progress, for example [IP-GGF] and [PRT]. We would like to thank
the members of the the v6ops working group and the application area the members of the the v6ops working group and the application area
for helpful comments. Special thanks are due to Brian E. for helpful comments. Special thanks are due to Brian E.
Carpenter, Antonio Querubin, Stig Venaas, Chirayu Patel, and Jordi Carpenter, Antonio Querubin, Stig Venaas, Chirayu Patel, Jordi
Palet for extensive review of this document. We acknowledge Ron Palet, and Jason Lin for extensive review of this document. We
Pike for proofreading the document. acknowledge Ron Pike for proofreading the document.
10. References 10. References
Normative References Normative References
[RFC 3493] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic [RFC 3493] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic
Socket Interface Extensions for IPv6," RFC 3493, February Socket Interface Extensions for IPv6," RFC 3493, February
2003. 2003.
[RFC 3542] W. Stevens, M. Thomas, E. Nordmark, T. Jinmei, "Advanced [RFC 3542] W. Stevens, M. Thomas, E. Nordmark, T. Jinmei, "Advanced
skipping to change at page 25, line 38 skipping to change at page 26, line 18
[BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts [BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts
using the "Bump-In-the-Stack" Technique (BIS)," RFC 2767, using the "Bump-In-the-Stack" Technique (BIS)," RFC 2767,
February 2000. February 2000.
[BIA] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand, [BIA] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand,
"Dual Stack Hosts using "Bump-in-the-API" (BIA)," RFC "Dual Stack Hosts using "Bump-in-the-API" (BIA)," RFC
3338, October 2002. 3338, October 2002.
[RFC 2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 [RFC 2460] S. Deering, R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification,", RFC 2460, December 1998. (IPv6) Specification," RFC 2460, December 1998.
[RFC 3484] R. Draves, "Default Address Selection for IPv6," [RFC 3484] R. Draves, "Default Address Selection for IPv6,"
RFC 3484, February 2003. RFC 3484, February 2003.
[RFC 3513] R. Hinden, S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture," RFC 3513, April 2003.
Informative References Informative References
[2893BIS] E. Nordmark, R. E. Gilligan, "Basic Transition Mechanisms [2893BIS] E. Nordmark, R. E. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers," <draft-ietf-v6ops-mech-v2- for IPv6 Hosts and Routers," <draft-ietf-v6ops-mech-v2-
02.txt>, January 2004, Work-in-progress. 03.txt>, June 2004, Work-in-progress.
[RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal [RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
IPv6 Addresses in URL's," RFC 2732, December 1999. IPv6 Addresses in URL's," RFC 2732, December 1999.
[RFC 2821] J. Klensin, "Simple Mail Transfer Protocol," RFC 2821, [RFC 2821] J. Klensin, "Simple Mail Transfer Protocol," RFC 2821,
April 2001. April 2001.
[TextRep] A. Main, "Textual Representation of IPv4 and IPv6 [TextRep] A. Main, "Textual Representation of IPv4 and IPv6
Addresses," <draft-main-ipaddr-text-rep-01.txt>, Oct 2003, Addresses," <draft-main-ipaddr-text-rep-01.txt>, Oct 2003,
Work in Progress. Work in Progress.
[NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation [NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation
- Protocol Translation (NAT-PT)," RFC 2766, February 2000. - Protocol Translation (NAT-PT)," RFC 2766, February 2000.
[DNSTRANS] A. Durand, J. Ihren, "DNS IPv6 transport operational [DNSTRANS] A. Durand, J. Ihren, "DNS IPv6 transport operational
guidelines," <draft-ietf-dnsop-ipv6-transport-guidelines- guidelines," <draft-ietf-dnsop-ipv6-transport-guidelines-
00.txt>, June 2003, Work in Progress. 02.txt>, March 2004, Work in Progress.
[DNSOPV6] A. Durand, J. Ihren, P. Savola, "Operational Considerations [DNSOPV6] A. Durand, J. Ihren, P. Savola, "Operational Considerations
and Issues with IPv6 DNS," <draft-ietf-dnsop-ipv6-dns- and Issues with IPv6 DNS," <draft-ietf-dnsop-ipv6-dns-
issues-03.txt>, November 2003, Work in Progress. issues-07.txt>, May 2004, Work in Progress.
[AF-APP] J. Hagino, "Implementing AF-independent application", [AF-APP] J. Hagino, "Implementing AF-independent application",
http://www.kame.net/newsletter/19980604/, 2001. http://www.kame.net/newsletter/19980604/, 2001.
[V6MAPPED] J. Hagino, "IPv4 mapped address considered harmful", [V6MAPPED] J. Hagino, "IPv4 mapped address considered harmful",
<draft-itojun-v6ops-v4mapped-harmful-00.txt>, Apr 2002, <draft-itojun-v6ops-v4mapped-harmful-02.txt>, Apr 2002,
Work in Progress. Work in Progress.
[IP-GGF] T. Chown, J. Bound, S. Jiang, P. O'Hanlon, "Guidelines for [IP-GGF] T. Chown, J. Bound, S. Jiang, P. O'Hanlon, "Guidelines for
IP version independence in GGF specifications," Global IP version independence in GGF specifications," Global
Grid Forum(GGF) Documentation, September 2003, Work in Grid Forum(GGF) Documentation, September 2003, Work in
Progress. Progress.
[Embed-RP] P. Savola, B. Haberman, "Embedding the Address of RP in [Embed-RP] P. Savola, B. Haberman, "Embedding the Address of RP in
IPv6 Multicast Address," <draft-ietf-mboned-embeddedrp- IPv6 Multicast Address," <draft-ietf-mboned-embeddedrp-
00.txt>, October 2003, Work in Progress. 00.txt>, October 2003, Work in Progress.
skipping to change at page 27, line 6 skipping to change at page 27, line 33
2004. 2004.
[MUL-GW] S. Venaas, "An IPv4 - IPv6 multicast gateway," <draft- [MUL-GW] S. Venaas, "An IPv4 - IPv6 multicast gateway," <draft-
venaas-mboned-v4v6mcastgw-00.txt>, February 2003, venaas-mboned-v4v6mcastgw-00.txt>, February 2003,
Work in Progress. Work in Progress.
[PRT] E. M. Castro, "Programming guidelines on transition to [PRT] E. M. Castro, "Programming guidelines on transition to
IPv6, LONG project, January 2003. IPv6, LONG project, January 2003.
Authors' Addresses Authors' Addresses
Myung-Ki Shin Myung-Ki Shin
ETRI PEC ETRI/NIST
161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 820 West Diamond Avenue
Tel : +82 42 860 4847 Gaithersburg, MD 20899, USA
Fax : +82 42 861 5404 Tel : +1 301 975-3613
E-mail : mkshin@pec.etri.re.kr Fax : +1 301 590-0932
E-mail : mshin@nist.gov
Yong-Guen Hong Yong-Guen Hong
ETRI PEC ETRI PEC
161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
Tel : +82 42 860 6447 Tel : +82 42 860 6447
Fax : +82 42 861 5404 Fax : +82 42 861 5404
E-mail : yghong@pec.etri.re.kr E-mail : yghong@pec.etri.re.kr
Jun-ichiro itojun HAGINO Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc. Research Laboratory, Internet Initiative Japan Inc.
skipping to change at page 29, line 27 skipping to change at page 30, line 8
default: default:
/* handle unknown family */ /* handle unknown family */
} }
Note, the address family of the presentation format must be known. Note, the address family of the presentation format must be known.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; neither does it represent that it rights might or might not be available; nor does it represent that
has made any effort to identify any such rights. Information on the it has made any independent effort to identify any such rights.
IETF's procedures with respect to rights in standards-track and Information on the procedures with respect to rights in RFC
standards-related documentation can be found in BCP-11. Copies of documents can be found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made Copies of IPR disclosures made to the IETF Secretariat and any
to obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification attempt made to obtain a general license or permission for the use
can be obtained from the IETF Secretariat. of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on
others, and derivative works that comment on or otherwise explain an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
it or assist in its implementation may be prepared, copied, REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
published and distributed, in whole or in part, without restriction THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
of any kind, provided that the above copyright notice and this EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
paragraph are included on all such copies and derivative works. THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
However, this document itself may not be modified in any way, such ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
as by removing the copyright notice or references to the Internet PARTICULAR PURPOSE.
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 Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on Copyright (C) The Internet Society (2004). This document is
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET subject to the rights, licenses and restrictions contained in BCP
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 78, and except as set forth therein, the authors retain all their
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF rights.
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/