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/