< 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.
Table of Contents: Table of Contents:
1. Introduction .............................................. 3 1. Introduction .............................................. 3
2. Overview of IPv6 Application Transition ................... 3 2. Overview of IPv6 Application Transition ................... 3
3. Problems with IPv6 Application Transition ................. 5 3. Problems with IPv6 Application Transition ................. 5
3.1 IPv6 support in the OS and applications are unrelated.... 5 3.1 IPv6 support in the OS and applications are unrelated.... 5
3.2 DNS does not indicate which IP version will be used ..... 5 3.2 DNS does not indicate which IP version will be used ..... 5
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
temporary addresses to the applications and locally make a temporary addresses to the applications and locally make a
translation between IPv4 and IPv6 communication. Hence, these IPv4 translation between IPv4 and IPv6 communication. Hence, these IPv4
temporary addresses are only valid in the node scope." temporary addresses are only valid in the node scope."
4.2 IPv6 Applications in a Dual-stack Node 4.2 IPv6 Applications in a Dual-stack Node
As we have seen in the previous section, applications should be As we have seen in the previous section, applications should be
ported to IPv6. The easiest way to port an IPv4 application is to ported to IPv6. The easiest way to port an IPv4 application is to
substitute the old IPv4 API references with the new IPv6 APIs with substitute the old IPv4 API references with the new IPv6 APIs with
one-to-one mapping. This way the application will be IPv6-only. one-to-one mapping. This way the application will be IPv6-only.
This IPv6-only source code can not work in IPv4-only nodes, so the This IPv6-only source code can not work in IPv4-only nodes, so the
old IPv4 application should be maintained in these nodes. Then, we old IPv4 application should be maintained in these nodes. Then, we
will get two similar applications working with different protocol will get two similar applications working with different protocol
versions, depending on the node they are running (e.g., telnet and versions, depending on the node they are running (e.g., telnet and
telnet6). This case is undesirable since maintaining two versions telnet6). This case is undesirable since maintaining two versions
of the same source code per application could be a difficult task. of the same source code per application could be a difficult task.
In addition, this approach would cause problems for the users when In addition, this approach would cause problems for the users when
having to select which version of the application to use, as having to select which version of the application to use, as
described in section 3.3. described in section 3.3.
Most implementations of dual stack allow IPv6-only applications to Most implementations of dual stack allow IPv6-only applications to
interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to
IPv6 applications on a dual-stack node reach their destination IPv6 applications on a dual-stack node reach their destination
because their addresses are mapped to IPv6 ones using IPv4-mapped because their addresses are mapped to IPv6 ones using IPv4-mapped
IPv6 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4 IPv6 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4
skipping to change at page 10, line 15 skipping to change at page 10, line 24
particular system is controlled by the OS owner and not particular system is controlled by the OS owner and not
necessarilly by a developer. This complicates the developer's work necessarilly by a developer. This complicates the developer's work
as he now has to rewrite the daemon network code to handle both as he now has to rewrite the daemon network code to handle both
environments, even for the same OS. environments, even for the same OS.
4.3 IPv4/IPv6 Applications in a Dual-stack Node 4.3 IPv4/IPv6 Applications in a Dual-stack Node
Applications should be ported to support both IPv4 and IPv6; such Applications should be ported to support both IPv4 and IPv6; such
applications are sometimes called IP version-independent applications are sometimes called IP version-independent
applications. After that, the existing IPv4-only applications applications. After that, the existing IPv4-only applications
could be removed. Since we have only one version of each could be removed. Since we have only one version of each
application, the source code will be typically easy to maintain and application, the source code will be typically easy to maintain and
to modify, and there are no problems managing which application to to modify, and there are no problems managing which application to
select for which communication. select for which communication.
This transition case is the most advisable. During the IPv6 This transition case is the most advisable. During the IPv6
transition period applications supporting both IPv4 and IPv6 should transition period applications supporting both IPv4 and IPv6 should
be able to communicate with other applications, irrespective of the be able to communicate with other applications, irrespective of the
versions of the protocol stack or the application in the node. versions of the protocol stack or the application in the node.
Dual applications allow more interoperability between heterogeneous Dual applications allow more interoperability between heterogeneous
applications and nodes. applications and nodes.
If the source code is written in a protocol-independent way, If the source code is written in a protocol-independent way,
without dependencies on either IPv4 or IPv6, applications will be without dependencies on either IPv4 or IPv6, applications will be
able to communicate with any combination of applications and types able to communicate with any combination of applications and types
of nodes. of nodes.
skipping to change at page 10, line 45 skipping to change at page 10, line 54
The resolver returns a list of valid addresses for the remote node The resolver returns a list of valid addresses for the remote node
and applications can iterate through all of them until connection and applications can iterate through all of them until connection
succeeds. succeeds.
Applications writers should be aware of this typical by-default Applications writers should be aware of this typical by-default
ordering, but the applications themselves typically need not be ordering, but the applications themselves typically need not be
aware of the the local protocol ordering [RFC 3484]. aware of the the local protocol ordering [RFC 3484].
If the source code is written in a protocol-dependent way, the If the source code is written in a protocol-dependent way, the
application will support IPv4 and IPv6 explicitly using 2 separate application will support IPv4 and IPv6 explicitly using 2 separate
sockets. Note that there are some differences in bind() sockets. Note that there are some differences in bind()
implementation, whether you can first bind to the IPv6, and then implementation, whether you can first bind to the IPv6, and then
IPv4, wildcard addresses. It can be a pain to write applications IPv4, wildcard addresses. It can be a pain to write applications
that cope with this. If IPV6_V6ONLY is implemented, this becomes that cope with this. If IPV6_V6ONLY is implemented, this becomes
simpler. The reason the IPv4 wildcard bind fails on some systems is simpler. The reason the IPv4 wildcard bind fails on some systems is
that the IPv4 address space is embedded into IPv6 address space that the IPv4 address space is embedded into IPv6 address space
when using IPv4-mapped IPv6 addresses. when using IPv4-mapped IPv6 addresses.
A more detailed porting guideline is described in section 6. A more detailed porting guideline is described in section 6.
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 13, line 25 skipping to change at page 13, line 50
address literals differently; for example, SMTP [RFC 2821] uses address literals differently; for example, SMTP [RFC 2821] uses
[IPv6:2001:db8::1]. [IPv6:2001:db8::1].
Note that the use of address literals is strongly discouraged for Note that the use of address literals is strongly discouraged for
general purpose direct input to the applications; host names and general purpose direct input to the applications; host names and
DNS should be used instead. DNS should be used instead.
5.2 Transport Layer API 5.2 Transport Layer API
Communication applications often include a transport module that Communication applications often include a transport module that
establishes communications. Usually this module manages everything establishes communications. Usually this module manages everything
related to communications and uses a transport layer API, typically related to communications and uses a transport layer API, typically
as a network library. When porting an application to IPv6, most as a network library. When porting an application to IPv6, most
changes should be made in this application transport module in changes should be made in this application transport module in
order to be adapted to the new IPv6 API. order to be adapted to the new IPv6 API.
In the general case, porting an existing application to IPv6 In the general case, porting an existing application to IPv6
requires an examination of the following issues related to the API: requires an examination of the following issues related to the API:
- Network information storage: IP address data structures. - Network information storage: IP address data structures.
The new structures must contain 128-bit IP addresses. The use of The new structures must contain 128-bit IP addresses. The use of
skipping to change at page 14, line 24 skipping to change at page 14, line 50
From the application point of view, the name and address resolution From the application point of view, the name and address resolution
is a system-independent process. An application calls functions in is a system-independent process. An application calls functions in
a system library, the resolver, which is linked into the a system library, the resolver, which is linked into the
application when this is built. However, these functions use IP application when this is built. However, these functions use IP
address structures, which are protocol dependent, and must be address structures, which are protocol dependent, and must be
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.
Typically nodes, not applications, automatically solve the source Typically nodes, not applications, automatically solve the source
address selection. A node will choose the source address for a address selection. A node will choose the source address for a
communication following some rules of best choice, [RFC 3484], but communication following some rules of best choice, [RFC 3484], but
also allowing applications to make changes in the ordering rules. also allowing applications to make changes in the ordering rules.
When selecting the destination address, applications usually ask a When selecting the destination address, applications usually ask a
resolver for the destination IP address. The resolver returns a set resolver for the destination IP address. The resolver returns a set
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 16, line 9 skipping to change at page 16, line 33
- IP addresses can change throughout time, for instance - IP addresses can change throughout time, for instance
after a renumbering process. after a renumbering process.
- The same node can reach a destination host using different - The same node can reach a destination host using different
IP addresses, possibly with a different protocol version. IP addresses, possibly with a different protocol version.
When possible, applications should store names such as FQDNs, or When possible, applications should store names such as FQDNs, or
other protocol-independent identities instead of storing addresses. other protocol-independent identities instead of storing addresses.
In this case applications are only bound to specific addresses at In this case applications are only bound to specific addresses at
run time, or for the duration of a cache lifetime. Other types of run time, or for the duration of a cache lifetime. Other types of
applications, such as massive peer to peer systems with their own applications, such as massive peer to peer systems with their own
rendezvous and discovery mechanisms, may need to cache addresses rendezvous and discovery mechanisms, may need to cache addresses
for performance reasons, but cached addresses should not be treated for performance reasons, but cached addresses should not be treated
as permanent, reliable information. In highly dynamic networks any as permanent, reliable information. In highly dynamic networks any
form of name resolution may be impossible, and here again addresses form of name resolution may be impossible, and here again addresses
must be cached. must be cached.
5.5 Multicast Applications 5.5 Multicast Applications
There is an additional problem in porting multicast applications. There is an additional problem in porting multicast applications.
skipping to change at page 17, line 9 skipping to change at page 17, line 33
Another generic problem for multiparty conferencing applications, Another generic problem for multiparty conferencing applications,
which is similar to the issues with peer-to-peer applications, is which is similar to the issues with peer-to-peer applications, is
that all the users of the session must use the same protocol that all the users of the session must use the same protocol
version (IPv4 or IPv6), or some form of proxies or translators must version (IPv4 or IPv6), or some form of proxies or translators must
be used (e.g., [MUL-GW]). be used (e.g., [MUL-GW]).
6. Developing IP version-independent Applications 6. Developing IP version-independent Applications
As we have seen before, dual applications working with both IPv4 As we have seen before, dual applications working with both IPv4
and IPv6 are recommended. These applications should avoid IP and IPv6 are recommended. These applications should avoid IP
dependencies in the source code. However, if IP dependencies are dependencies in the source code. However, if IP dependencies are
required, one of the best solutions is based on building a required, one of the best solutions is based on building a
communication library which provides an IP version independent API communication library which provides an IP version independent API
to applications and hides all dependencies. to applications and hides all dependencies.
In order to develop IP version independent applications, the In order to develop IP version independent applications, the
following guidelines should be considered. following guidelines should be considered.
6.1 IP version-independent Structures 6.1 IP version-independent Structures
All of the memory structures and APIs should be IP version- All of the memory structures and APIs should be IP version-
independent. In that sense, one should avoid structs in_addr, independent. In that sense, one should avoid structs in_addr,
in6_addr, sockaddr_in and sockaddr_in6. in6_addr, sockaddr_in and sockaddr_in6.
Suppose you pass a network address to some function, foo(). If you Suppose you pass a network address to some function, foo(). If you
use struct in_addr or struct in6_addr, you will end up with an use struct in_addr or struct in6_addr, you will end up with an
extra parameter to indicate address family, as below: extra parameter to indicate address family, as below:
struct in_addr in4addr; struct in_addr in4addr;
struct in6_addr in6addr; struct in6_addr in6addr;
/* IPv4 case */ /* IPv4 case */
foo(&in4addr, AF_INET); foo(&in4addr, AF_INET);
/* IPv6 case */ /* IPv6 case */
foo(&in6addr, AF_INET6); foo(&in6addr, AF_INET6);
However, this leads to duplicated code and having to consider each However, this leads to duplicated code and having to consider each
scenario from both perspectives independently; this is difficult to scenario from both perspectives independently; this is difficult to
maintain. So, we should use struct sockaddr_storage like below. maintain. So, we should use struct sockaddr_storage like below.
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 32 skipping to change at page 25, line 7
7. Transition Mechanism Considerations 7. Transition Mechanism Considerations
A mechanism, [NAT-PT], introduces a special set of addresses, A mechanism, [NAT-PT], introduces a special set of addresses,
formed of NAT-PT prefix and an IPv4 address; this refers to IPv4 formed of NAT-PT prefix and an IPv4 address; this refers to IPv4
addresses, translated by NAT-PT DNS-ALG. In some cases, one might addresses, translated by NAT-PT DNS-ALG. In some cases, one might
be tempted to handle these differently. be tempted to handle these differently.
However, IPv6 applications must not be required to distinguish However, IPv6 applications must not be required to distinguish
"normal" and "NAT-PT translated" addresses (or any other kind of "normal" and "NAT-PT translated" addresses (or any other kind of
special addresses, including the IPv4-mapped IPv6-addresses): that special addresses, including the IPv4-mapped IPv6-addresses): that
would be completely impractical, and if such distinction must be would be completely impractical, and if such distinction must be
made, it must be done elsewhere (e.g. kernel, system libraries). made, it must be done elsewhere (e.g. kernel, system libraries).
8. Security Considerations 8. Security Considerations
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
ETRI PEC
161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
Tel : +82 42 860 4847
Fax : +82 42 861 5404
E-mail : mkshin@pec.etri.re.kr
Yong-Guen Hong Myung-Ki Shin
ETRI PEC ETRI/NIST
161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 820 West Diamond Avenue
Tel : +82 42 860 6447 Gaithersburg, MD 20899, USA
Fax : +82 42 861 5404 Tel : +1 301 975-3613
E-mail : yghong@pec.etri.re.kr Fax : +1 301 590-0932
E-mail : mshin@nist.gov
Jun-ichiro itojun HAGINO Yong-Guen Hong
Research Laboratory, Internet Initiative Japan Inc. ETRI PEC
Takebashi Yasuda Bldg., 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
3-13 Kanda Nishiki-cho, Tel : +82 42 860 6447
Chiyoda-ku,Tokyo 101-0054, JAPAN Fax : +82 42 861 5404
Tel: +81-3-5259-6350 E-mail : yghong@pec.etri.re.kr
Fax: +81-3-5259-6351
E-mail: itojun@iijlab.net
Pekka Savola Jun-ichiro itojun HAGINO
CSC/FUNET Research Laboratory, Internet Initiative Japan Inc.
Espoo, Finland Takebashi Yasuda Bldg.,
E-mail: psavola@funet.fi 3-13 Kanda Nishiki-cho,
Chiyoda-ku,Tokyo 101-0054, JAPAN
Tel: +81-3-5259-6350
Fax: +81-3-5259-6351
E-mail: itojun@iijlab.net
Eva M. Castro Pekka Savola
Rey Juan Carlos University (URJC) CSC/FUNET
Departamento de Informatica, Estadistica y Telematica Espoo, Finland
C/Tulipan s/n E-mail: psavola@funet.fi
28933 Madrid - SPAIN
E-mail: eva@gsyc.escet.urjc.es Eva M. Castro
Rey Juan Carlos University (URJC)
Departamento de Informatica, Estadistica y Telematica
C/Tulipan s/n
28933 Madrid - SPAIN
E-mail: eva@gsyc.escet.urjc.es
Appendix A. Other binary/Presentation Format Conversions Appendix A. Other binary/Presentation Format Conversions
Section 6.2.3 described the preferred way of performing Section 6.2.3 described the preferred way of performing
binary/presentation format conversions; these can also be done binary/presentation format conversions; these can also be done
using inet_pton() and inet_ntop() by writing protocol-dependent using inet_pton() and inet_ntop() by writing protocol-dependent
code. This is not recommended, but provided here for reference and code. This is not recommended, but provided here for reference and
comparison. comparison.
Note that inet_ntop()/inet_pton() lose the scope identifier (if Note that inet_ntop()/inet_pton() lose the scope identifier (if
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. 59 change blocks. 
165 lines changed or deleted 199 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/