draft-ietf-v6ops-v6onbydefault-01.txt		draft-ietf-v6ops-v6onbydefault-02.txt
	Network Working Group S. Roy		Network Working Group S. Roy
	Internet-Draft A. Durand		Internet-Draft A. Durand
	Expires: August 13, 2004 J. Paugh		Expires: November 5, 2004 J. Paugh
	Sun Microsystems, Inc.		Sun Microsystems, Inc.
	February 13, 2004		May 7, 2004
	Issues with Dual Stack IPv6 on by Default		Issues with Dual Stack IPv6 on by Default
	draft-ietf-v6ops-v6onbydefault-01.txt		draft-ietf-v6ops-v6onbydefault-02.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 32		skipping to change at page 1, line 31
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 August 13, 2004.		This Internet-Draft will expire on November 5, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document discusses problems that can occur when dual stack nodes		This document discusses problems that can occur when dual stack nodes
	that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4		that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4
	and IPv6 environments. The problems include application connection		and IPv6 environments. The problems include application connection
	delays, poor connectivity, and network security. Its purpose is to		delays, poor connectivity, and network insecurity. The purpose of
	raise awareness of these problems so that they can be fixed or worked		this memo is to raise awareness of these problems so that they can be
	around. The purpose of this document is not to try to specify whether		fixed or worked around, not to try to specify whether IPv6 should be
	IPv6 should be enabled by default or not, but to raise awareness of		enabled by default or not.
	the potential issues involved.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. No IPv6 Router . . . . . . . . . . . . . . . . . . . . . . 3		2. No IPv6 Router . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1 Problems with Default Address Selection for IPv6 . . . . . 3		2.1 Problems with Default Address Selection for IPv6 . . . . . 3
	2.2 Neighbor Discovery's On-Link Assumption Considered		2.2 Neighbor Discovery's On-Link Assumption Considered
	Harmful . . . . . . . . . . . . . . . . . . . . . . . . . 5		Harmful . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3 Transport Protocol Robustness . . . . . . . . . . . . . . 6		2.3 Transport Protocol Robustness . . . . . . . . . . . . . . 6
	2.3.1 TCP Implications . . . . . . . . . . . . . . . . . . . . . 6		2.3.1 TCP Implications . . . . . . . . . . . . . . . . . . . 6
	2.3.1.1 TCP Connection Termination . . . . . . . . . . . . . . . . 6		2.3.2 UDP Implications . . . . . . . . . . . . . . . . . . . 8
	2.3.1.2 Asynchronous Application Notification . . . . . . . . . . 7		2.3.3 SCTP Implications . . . . . . . . . . . . . . . . . . 8
	2.3.2 UDP Implications . . . . . . . . . . . . . . . . . . . . . 7		3. Other Problematic Scenarios . . . . . . . . . . . . . . . . . 9
	2.3.3 SCTP Implications . . . . . . . . . . . . . . . . . . . . 8		3.1 IPv6 Network of Smaller Scope . . . . . . . . . . . . . . 9
	3. Other Problematic Scenarios . . . . . . . . . . . . . . . 8		3.1.1 Alleviating the Scope Problem . . . . . . . . . . . . 10
	3.1 IPv6 Network of Smaller Scope . . . . . . . . . . . . . . 8		3.2 Poor IPv6 Network Performance . . . . . . . . . . . . . . 10
	3.1.1 Alleviating the Scope Problem . . . . . . . . . . . . . . 8		3.2.1 Dealing with Poor IPv6 Network Performance . . . . . . 10
	3.2 Poor IPv6 Network Performance . . . . . . . . . . . . . . 8		3.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.2.1 Dealing with Poor IPv6 Network Performance . . . . . . . . 9		3.3.1 Mitigating Security Risks . . . . . . . . . . . . . . 11
	3.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Application Robustness . . . . . . . . . . . . . . . . . . . . 12
	3.3.1 Mitigating Security Risks . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	4. Application Robustness . . . . . . . . . . . . . . . . . . 10		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Security Considerations . . . . . . . . . . . . . . . . . 11		6.1 Normative References . . . . . . . . . . . . . . . . . . . . 12
	Normative References . . . . . . . . . . . . . . . . . . . 11		6.2 Informative References . . . . . . . . . . . . . . . . . . . 13
	Informative References . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12		A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 12		B. Changes from draft-ietf-v6ops-v6onbydefault-01 . . . . . . . . 14
	B. Changes from draft-ietf-v6ops-v6onbydefault-00 . . . . . . 12		C. Changes from draft-ietf-v6ops-v6onbydefault-00 . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . 14		Intellectual Property and Copyright Statements . . . . . . . . 16
	1. Introduction		1. Introduction
	This document specifically addresses operating system implementations		This document specifically addresses operating system implementations
	that implement the dual stack IPv6 model, and would ship with IPv6		that implement the dual stack IPv6 model, and would ship with IPv6
	enabled by default. It addresses the case where such a system is		enabled by default. It addresses the case where such systems are
	installed and placed in an IPv4 only or mixed IPv4 and IPv6		installed and placed in IPv4-only or mixed IPv4 and IPv6
	environment, and documents potential problems that users on such		environments, and documents potential problems that users on such
	systems could experience if the IPv6 connectivity is non-existent or		systems could experience if the IPv6 connectivity is non-existent or
	sub-optimal. The purpose of this document is not to try to specify		sub-optimal. The purpose of this document is not to try to specify
	whether IPv6 should be enabled by default or not, but to raise		whether IPv6 should be enabled by default or not, but to raise
	awareness of the potential issues involved.		awareness of the potential issues involved.
	It begins in Section 2 by examining problems within IPv6		This memo begins in Section 2 by examining problems within IPv6
	implementations that defeat the destination address selection		implementations that defeat the destination address selection
	mechanism defined in [ADDRSEL] and contribute to poor IPv6		mechanism defined in [ADDRSEL] and contribute to poor IPv6
	connectivity. Starting with Section 3 it then examines other issues		connectivity. Starting with Section 3 it then examines other issues
	that network software engineers and network and systems		that network software engineers and network and systems
	administrators should be aware of when deploying dual stack systems		administrators should be aware of when deploying dual stack systems
	with IPv6 enabled.		with IPv6 enabled.
	2. No IPv6 Router		2. No IPv6 Router
	Consider a scenario in which a dual stack system has IPv6 enabled and		Consider a scenario in which a dual stack system has IPv6 enabled and
	placed on a link with no IPv6 routers. The system is using IPv6		is placed on a link with no IPv6 routers. The system is using IPv6
	Stateless Address Autoconfiguration [AUTOCONF], so it only has a		Stateless Address Autoconfiguration [AUTOCONF], so it only has a
	link-local IPv6 address configured. It also has a single IPv4		link-local IPv6 address configured. It also has a single IPv4
	address that happens to be a private address as defined in		address that happens to be a private address as defined in
	[PRIVADDR].		[PRIVADDR].
	An application on this system is trying to communicate with a		An application on this system is trying to communicate with a
	destination whose name resolves to public and global IPv4 and IPv6		destination whose name resolves to public and global IPv4 and IPv6
	addresses. The application uses an address resolution API that		addresses. The application uses an address resolution API that
	implements the destination address selection mechanism described in		implements the destination address selection mechanism described in
	Default Address Selection for IPv6 [ADDRSEL]. The application will		Default Address Selection for IPv6 [ADDRSEL]. The application will
	attempt to connect to each address returned in order until one		attempt to connect to each address, in the order they were returned,
	succeeds. Since the system has no off-link IPv6 routes, the optimal		until one succeeds. Since the system has no off-link IPv6 routes,
	scenario would be if the IPv4 addresses returned were ordered before		the optimal scenario would be if the IPv4 addresses returned were
	the IPv6 addresses. The following sections describe where things can		ordered before the IPv6 addresses. The following sections describe
	go wrong with this scenario.		what things can go wrong with this scenario.
	2.1 Problems with Default Address Selection for IPv6		2.1 Problems with Default Address Selection for IPv6
	The Default Address Selection for IPv6 [ADDRSEL] destination address		The Default Address Selection for IPv6 [ADDRSEL] destination address
	selection mechanism could save the application a few useless		selection mechanism could save the application a few useless
	connection attempts by placing the IPv4 addresses in front of the		connection attempts by placing the IPv4 addresses in front of the
	IPv6 addresses. This would be desired since all IPv6 destinations in		IPv6 addresses. This would be desired since all IPv6 destinations in
	this scenario are unreachable (there's no route to them), and the		this scenario are unreachable (there's no route to them), and the
	system's only IPv6 source address is inadequate to communicate with		system's only IPv6 source address is inadequate to communicate with
	off-link destinations even if it did have an off-link route.		off-link destinations even if it did have an off-link route.
	Let's examine how the destination address selection mechanism behaves		Let's examine how the destination address selection mechanism behaves
	in the face of this scenario when given one IPv4 destination and one		in the face of this scenario when given one IPv4 destination and one
	IPv6 destination.		IPv6 destination.
	The first rule, "Avoid unusable destinations", could prefer the IPv4		The first rule, "Avoid unusable destinations", would prefer the IPv4
	destination over the IPv6 destination, but only if the IPv6		destination over the IPv6 destination, but only if the IPv6
	destination is determined to be unreachable. The unreachability		destination were determined to be unreachable. The unreachability
	determination for a destination as it pertains to this rule is an		determination for a destination as it pertains to this rule is an
	implementation detail. One implementable method is to do a simple		implementation detail. One implementable method is to do a simple
	forwarding table lookup on the destination, and to deem the		forwarding table lookup on the destination, and to deem the
	destination as reachable if the lookup succeeds. The Neighbor		destination as reachable if the lookup succeeds. The Neighbor
	Discovery on-link assumption mentioned in Section 2.2 makes this		Discovery on-link assumption mentioned in Section 2.2 makes this
	method somewhat irrelevant, however, as an implementation of the		method somewhat irrelevant, however, as an implementation of the
	assumption could simply be to insert an IPv6 default on-link route		assumption could simply be to insert an IPv6 default on-link route
	into the system's forwarding table when the default router list is		into the system's forwarding table when the default router list is
	empty. The side-effect is that the rule would always determine that		empty. The side-effect is that the rule would always determine that
	all IPv6 destinations are reachable. Therefore, this rule will not		all IPv6 destinations are reachable. Therefore, this rule will not
	necessarily prefer one destination over the other.		necessarily prefer one destination over the other.
	The second rule, "Prefer matching scope", could prefer the IPv4		The second rule, "Prefer matching scope", could prefer the IPv4
	destination over the IPv6 destination, but only if the IPv4		destination over the IPv6 destination, but only if the IPv4
	destination's scope matches the scope of the system's IPv4 source		destination's scope matches the scope of the system's IPv4 source
	address. Since [ADDRSEL] considers private addresses (as defined in		address. Since [ADDRSEL] considers private addresses (as defined in
	[PRIVADDR]) of site-local scope, then this rule will not prefer		[PRIVADDR]) of site-local scope, then this rule will not prefer
	either destination over the other. The link-local IPv6 source		either destination over the other. The link-local IPv6 source
	doesn't match the global IPv6 destination, and the site-local IPv4		doesn't match the global IPv6 destination, and the "site-local" IPv4
	source doesn't match the global IPv4 destination. The tie-breaking		source doesn't match the global IPv4 destination. The tie-breaking
	rule in this case is rule 6, "Prefer higher precedence". Since IPv6		rule in this case is rule 6, "Prefer higher precedence". Since IPv6
	destinations are of higher precedence than IPv4 destinations in the		destinations are of higher precedence than IPv4 destinations in the
	default policy table, the IPv6 destination will be preferred.		default policy table, the IPv6 destination will be preferred.
	The solution in this case could be to add a new rule after rule 2		The solution in this case could be to add a new rule after rule 2
	(rule 2.5) that avoids non-link-local IPv6 destinations whose source		(rule 2.5) that avoids non-link-local IPv6 destinations whose
	addresses are link-local. Of course, if the host is manually		selected source addresses are link-local. Of course, if the host is
	assigned a global IPv6 source address, then rule 2 will automatically		manually assigned a global IPv6 source address, then rule 2 will
	prefer the IPv6 destination, and there is no fix other than to make		automatically prefer the IPv6 destination, and there is no fix other
	sure rule 1 considers IPv6 destinations unreachable in this scenario.		than to make sure rule 1 considers IPv6 destinations unreachable in
			this scenario.
	Fixing the destination address selection mechanism by adding such a		Fixing the destination address selection mechanism by adding such a
	rule is only a mitigating factor if applications use standard name		rule is only a mitigating factor if applications use standard name
	resolution API's that implement this mechanism, and these		resolution API's that implement this mechanism, and these
	applications try addresses in the order returned. This may not be an		applications try addresses in the order returned. This may not be an
	acceptable assumption in some cases, as there are applications that		acceptable assumption in some cases, as there are applications that
	use hard coded addresses and address search orders (DNS resolver is		use hard coded addresses and address search orders and/or literal
	one example), and/or literal addresses passed in from the user. Such		addresses passed in from the user.
	applications will obviously be subject to whatever connection delays
	are associated with attempting a connection to an unreachable		For example, one such application is the DNS resolver. In this case,
			a configuration file usually contains a list of literal addresses to
			be used as DNS name servers. The resolver client tries these servers
			in the order that they appear in the file, bypassing address
			selection rules.
			Such applications will obviously be subject to whatever connection
			delays are associated with attempting a connection to an unreachable
	destination. This is discussed in more detail in the next few		destination. This is discussed in more detail in the next few
	sections.		sections.
	2.2 Neighbor Discovery's On-Link Assumption Considered Harmful		2.2 Neighbor Discovery's On-Link Assumption Considered Harmful
	Let's assume that the application described in Section 2 is		Let's assume that the application described in Section 2 is
	attempting a connection to an IPv6 address first, either because the		attempting a connection to an IPv6 address first, either because the
	destination address selection mechanism described in Section 2.1		destination address selection mechanism described in Section 2.1
	returned the addresses in that order, or because the application		returned the addresses in that order, or because the application
	isn't trying the addresses in the order returned. Regardless, the		isn't trying the addresses in the order returned. Regardless, the
	skipping to change at page 5, line 32		skipping to change at page 5, line 40
	list is empty, then the host assumes that the destination is on-link.		list is empty, then the host assumes that the destination is on-link.
	This issue is described in detail in [ONLINK]. In summary, this		This issue is described in detail in [ONLINK]. In summary, this
	assumption makes the unreachability detection of off-link nodes in		assumption makes the unreachability detection of off-link nodes in
	the absence of a default router a lengthy operation. This is due to		the absence of a default router a lengthy operation. This is due to
	the cost of attempting Neighbor Discovery link-layer address		the cost of attempting Neighbor Discovery link-layer address
	resolution for each destination, and potential transport layer costs		resolution for each destination, and potential transport layer costs
	associated with connection timeouts. The transport layer issues are		associated with connection timeouts. The transport layer issues are
	discussed later in Section 2.3.		discussed later in Section 2.3.
	On a network that has no IPv6 routing and no IPv6 neighbors, making		On a network that has no IPv6 routing and no IPv6 neighbors, making
	the assumption that every IPv6 destination is on-link will be a		the assumption that every IPv6 destination is on-link will be costly
	costly and incorrect assumption. If an application has a list of		and incorrect. If an application has a list of addresses associated
	addresses associated with a destination and the first 15 are IPv6		with a destination and the first 15 are IPv6 addresses, then the
	addresses, then the application won't be able to successfully send a		application won't be able to successfully send a packet to the
	packet to the destination until the attempts to resolve each IPv6		destination until the attempts to resolve each IPv6 address have
	address have failed. This could take 45 seconds		failed. This could take 45 seconds (MAX_MULTICAST_SOLICIT *
	(MAX_MULTICAST_SOLICIT * RETRANS_TIMER * 15). This could be		RETRANS_TIMER * 15). This could be compounded by any transport
	compounded by any transport timeouts associated with each connection		timeouts associated with each connection attempt, bringing the
	attempt.		timeouts to even dozens of minutes.
	If IPv6 hosts don't assume that destinations are on-link as described		If IPv6 hosts don't assume that destinations are on-link as described
	above, then communication with destinations that are not on-link and		above, then communication with destinations that are not on-link and
	unreachable should immediately fail. The IPv6 implementation should		unreachable should immediately fail. The IPv6 implementation should
	be able to immediately notify applications or the transport layer		be able to immediately notify applications or the transport layer
	that it has no route to such IPv6 destinations, and applications		that it has no route to such IPv6 destinations, so that applications
	won't waste time waiting for address resolution to fail.		won't waste time waiting for address resolution to fail.
	If hosts need to communicate with on-link destinations in the absence		If hosts need to communicate with on-link destinations in the absence
	of default routers, then then they need to be explicitly configured		of default routers, then then they need to be explicitly configured
	to have on-link routes for those destinations.		to have on-link routes for those destinations.
	2.3 Transport Protocol Robustness		2.3 Transport Protocol Robustness
	Making the same set of assumptions as Section 2.2, regardless of how		Making the same set of assumptions as Section 2.2, regardless of how
	long the network layer takes to determine that the IPv6 destination		long the network layer takes to determine that the IPv6 destination
	is unreachable, the delay associated with a connection attempt to an		is unreachable, the delay associated with a connection attempt to an
	unreachable destination can be compounded by the transport layer.		unreachable destination can be compounded by the transport layer.
	When the unreachability of a destination is obviated by the reception		When the unreachability of a destination is obviated by the reception
	of an ICMPv6 destination unreachable message, the transport layer		of an ICMPv6 destination unreachable message, the transport layer
	should make it possible for the application to deal with this by		should make it possible for the application or API to deal with this.
	failing the connection attempt, passing ICMPv6 errors up to the		It could fail the connection attempt, pass ICMPv6 errors up to the
	application, etc... Such messages would be received in the cases		application, or pass them up to an API that is handling this for the
	mentioned in Section 2 in which a node has no default routers and NUD		application, etc.
	fails for destinations assumed to be on-link, and when firewalls or
	other systems that enforce scope boundaries send such ICMPv6 errors		Such messages would be received in the cases mentioned in Section 2
	as described in Section 3.1 and Section 3.3.		in which a node has no default routers and NUD fails for destinations
			assumed to be on-link, and when firewalls or other systems that
			enforce scope boundaries send such ICMPv6 errors as described in
			Section 3.1 and Section 3.3.
	For cases when packets to a destination are essentially black-holed		For cases when packets to a destination are essentially black-holed
	and no ICMPv6 errors are generated, there is very little additional		and no ICMPv6 errors are generated, there is very little additional
	remedy other than the existing timer mechanisms inside transport		remedy other than the existing timer mechanisms inside transport
	layers and applications. The following transport layer implication		layers and applications. The following transport layer implication
	discussions deal with the former case, in which ICMPv6 errors are		discussions deal with the former case, in which ICMPv6 errors are
	received.		received.
	2.3.1 TCP Implications		2.3.1 TCP Implications
	In the case of a socket application attempting a connection via TCP,		In the case of a socket application attempting a connection via TCP,
	it would be unreasonable for the application to block even after the		it would be unreasonable for the application to block even after the
	system has received notification that the destination address is		system has received notification that the destination address is
	unreachable via an ICMPv6 Destination Unreachable message.		unreachable via an ICMPv6 Destination Unreachable message.
	Following are some ways of solving TCP related delays associated with		Following are some ways of solving TCP related delays associated with
	destination unreachability when ICMPv6 errors are generated.		destination unreachability when ICMPv6 errors are generated.
	2.3.1.1 TCP Connection Termination		2.3.1.1 TCP Connection Termination
	One solution is for TCP to abort connections in SYN-SENT or		One solution for TCP is to abort connections in SYN-SENT or
	SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable		SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable
	message.		message.
	It should be noted that the Requirements for Internet Hosts		It should be noted that the Requirements for Internet Hosts
	[HOSTREQS] document, in section 4.2.3.9., states that TCP MUST NOT		[HOSTREQS] document, in section 4.2.3.9., states that TCP MUST NOT
	abort connections when receiving ICMP Destination Unreachable		abort connections when receiving ICMP Destination Unreachable
	messages that indicate "soft errors", where soft errors are defined		messages that indicate "soft errors", where soft errors are defined
	as ICMP codes 0 (network unreachable), 1 (host unreachable), and 5		as ICMP codes 0 (network unreachable), 1 (host unreachable), and 5
	(source route failed), and SHOULD abort connections upon receiving		(source route failed), and SHOULD abort connections upon receiving
	the other codes (which are considered "hard errors"). ICMPv6 didn't		the other codes (which are considered "hard errors"). ICMPv6 didn't
	skipping to change at page 7, line 17		skipping to change at page 7, line 28
	When [HOSTREQS] was written, most applications would mostly only try		When [HOSTREQS] was written, most applications would mostly only try
	one address when establishing communication with a destination. Not		one address when establishing communication with a destination. Not
	aborting a connection was a sane thing to do if re-trying a single		aborting a connection was a sane thing to do if re-trying a single
	address was a better alternative over quitting the application		address was a better alternative over quitting the application
	altogether. With IPv6, and especially on dual stack systems,		altogether. With IPv6, and especially on dual stack systems,
	destinations are often assigned multiple addresses (at least one IPv4		destinations are often assigned multiple addresses (at least one IPv4
	and one IPv6 address), and applications iterate through destination		and one IPv6 address), and applications iterate through destination
	addresses when attempting connections.		addresses when attempting connections.
	Since soft errors conditions are those that would entice an		Since soft errors conditions are those that would cause an
	application to continue iterating to another address, TCP shouldn't		application to continue iterating to another address, TCP could
	make the distinction between ICMPv6 soft errors and hard errors when		simply not make the distinction between ICMPv6 soft errors and hard
	in SYN-SENT or SYN-RECEIVED state. It should abort a connection in		errors when in SYN-SENT or SYN-RECEIVED state. It would abort a
	those states when receiving any ICMPv6 Destination Unreachable		connection in those states when receiving any ICMPv6 Destination
	message. When in any other state, TCP would behave as described in		Unreachable message. When in any other state, TCP would behave as
	[HOSTREQS].		described in [HOSTREQS].
	Many TCP implementations already behave this way, but others do not.		Many TCP implementations already behave this way, but others do not.
	This should be noted as a best current practice in this case.		This should be noted as a best current practice in this case.
	A tangential method of handling the problem in this way would be for		A tangential method of handling the problem in this way would be for
	applications to somehow notify the TCP layer of their preference in		applications to somehow notify the TCP layer of their preference in
	the matter. An application could notify TCP that it should abort a		the matter. An application could notify TCP that it should abort a
	connection upon receipt of particular ICMPv6 errors. Similarly, it		connection upon receipt of particular ICMPv6 errors. Similarly, it
	could notify TCP that it should not abort a connection. This would		could notify TCP that it should not abort a connection. This would
	allow existing TCP implementations to maintain their status quo at		allow existing TCP implementations to maintain their status quo at
	the expense of increased application complexity.		the expense of increased application complexity.
			Drawbacks do exist for this TCP behavior. One drawback involves a
			transient problem existing at the network layer that could cause all
			destinations to be unreachable for a temporary length of time. In
			such a situation, the application could quickly cycle through the
			destinations and return an error, when it could have let TCP retry a
			destination a few seconds later when the transient problem could have
			been mitigated.
			Another drawback is related to the insecurity of ICMP messages.
			Reacting to "soft errors" in all TCP connection states would have
			significant security implications, as it would be possible for anyone
			to reset established sessions, even without IP spoofing. However,
			this document only proposes reacting to such errors in SYN-SENT or
			SYN-RECEIVED states. These states are very short-lived, so the
			window of exposure is very short and the threat is negligible.
	2.3.1.2 Asynchronous Application Notification		2.3.1.2 Asynchronous Application Notification
	In section 4.2.4.1, [HOSTREQS] states that there MUST be a mechanism		In section 4.2.4.1, [HOSTREQS] states that there MUST be a mechanism
	for reporting soft TCP error conditions to the application. Such a		for reporting soft TCP error conditions to the application. Such a
	mechanism (assuming one is implemented) could be used by applications		mechanism (assuming one is implemented) could be used by applications
	to cycle through destination addresses.		to cycle through destination addresses.
			2.3.1.3 Higher Level API
			Regardless of which solution is used, an API that handles connection
			attempts to a destination in a transparent way could remove the
			complexity from applications and handle this scenario gracefully. The
			API could contain the intelligence required to resolve the hostname,
			try each destination address, etc.
			Such an API would also help to build applications that are protocol
			independent, and would reduce the impact on applications when
			transport layer behavior changes.
			The drawback of this approach is the need to change applications to
			use the API.
	2.3.2 UDP Implications		2.3.2 UDP Implications
	As noted in [HOSTREQS] section 4.1.3.3, UDP implementations MUST pass		As noted in [HOSTREQS] section 4.1.3.3, UDP implementations MUST pass
	to the application layer all ICMP error messages that it receives		to the application layer all ICMP error messages that it receives
	from the IP layer. As a result, proper handling destination		from the IP layer, granted that the socket used is connected. As a
	unreachability by UDP applications is the responsibility of the		result, proper handling destination unreachability by UDP
	applications themselves.		applications is the responsibility of the applications themselves.
			A higher level API as mentioned in Section 2.3.1.3 could remove the
			complexity from applications in this case as well.
	2.3.3 SCTP Implications		2.3.3 SCTP Implications
	According to [SCTPIMP], SCTP ignores all ICMPv6 destination		According to [SCTPIMP], SCTP ignores all ICMPv6 destination
	unreachable messages. The existing SCTP specifications do not		unreachable messages that do not indicate that the SCTP protocol
			itself is unreachable. The existing SCTP specifications do not
	suggest any action on the part of the implementation on reception of		suggest any action on the part of the implementation on reception of
	such messages. Investigation needs to be done to determine the		a "soft error".
	implications.
			Unlike TCP, SCTP itself is multihomed and allows a user to specify a
			list of addresses to connect to. Upon reception of a Destination
			Unreachable Message during connection setup SCTP should attempt to
			retransmit the Initiation message to one of its alternate addresses
			and put the address that encountered the "soft error" into the
			unreachable state. This will prevent use of the address after the
			association is set-up until SCTP's heartbeat mechanism finds the
			address to be reachable.
			In some cases the application may not have provided a list of
			addresses. In these cases it may be beneficial for SCTP, at a
			minimum, to mark the address as unreachable so that the application
			can acquire a notification through its application interface. In
			such a case the application could then either take action upon the
			address notification by aborting the connection attempt or allow
			SCTP's normal timer mechanism to continue retransmitting the INIT
			message to the peer's address.
			There is work in progress to specify adding the support for handling
			soft errors to the SCTP specification.
	3. Other Problematic Scenarios		3. Other Problematic Scenarios
	This section describes problems that could arise for a dual stack		This section describes problems that could arise for a dual stack
	system with IPv6 enabled when placed on a network with IPv6		system with IPv6 enabled when placed on a network with IPv6
	connectivity.		connectivity.
	3.1 IPv6 Network of Smaller Scope		3.1 IPv6 Network of Smaller Scope
	A network that has a smaller scope of connectivity for IPv6 as it		A network that has a smaller scope of connectivity for IPv6 as it
	skipping to change at page 9, line 39		skipping to change at page 11, line 9
	Disabling IPv6 on the end nodes is another solution. The idea would		Disabling IPv6 on the end nodes is another solution. The idea would
	be that enabling IPv6 on dual stack nodes is a manual process that		be that enabling IPv6 on dual stack nodes is a manual process that
	would be done when the administrator knows that IPv6 connectivity is		would be done when the administrator knows that IPv6 connectivity is
	adequate.		adequate.
	3.3 Security		3.3 Security
	Enabling IPv6 on a host implies that the services on the host may be		Enabling IPv6 on a host implies that the services on the host may be
	open to IPv6 communication. If the service itself is insecure and		open to IPv6 communication. If the service itself is insecure and
	depends on security policy enforced somewhere else on the network		depends on a security policy enforced somewhere else on the network
	(such as in a firewall), then there is potential for new attacks		(such as in a firewall), then there is potential for new attacks
	against the service.		against the service.
	A firewall, for example, may not be enforcing the same policy for		A firewall may not be enforcing the same policy for IPv4 as for IPv6
	IPv4 as for IPv6 traffic. One possibility is that the firewall could		traffic, which could be due to misconfiguration of the firewall. One
	have more relaxed policy for IPv6, perhaps by letting all IPv6		possibility is that the firewall could have more relaxed policy for
	packets pass through, or by letting all IPv4 protocol 41 packets pass		IPv6, perhaps by letting all IPv6 packets pass through, or by letting
	through. In this scenario, the dual stack hosts within the protected		all IPv4 protocol 41 packets pass through. In this scenario, the
	network could be subject to different attacks than for IPv4.		dual stack hosts within the protected network could be subject to
			different attacks than for IPv4.
	Even if a firewall has a stricter policy or identical policy for IPv6		Even if a firewall has a stricter policy or identical policy for IPv6
	traffic than for IPv4 (the extreme case being that it drops all IPv6		traffic than for IPv4 (the extreme case being that it drops all IPv6
	traffic), IPv6 packets could go through the network untouched if		traffic), IPv6 packets could go through the network untouched if
	tunneled over a transport layer. This could open the host to direct		tunneled over a transport layer. This could open the host to direct
	IPv6 attacks.		IPv6 attacks. It should be noted that IPv4 packets can also be
			tunneled, so this is not a new security concern for IPv6. Firewalls
			must be deliberately and properly configured.
	A similar problem could exist for VPN software. A VPN could protect		A similar problem could exist for virtual private network (VPN)
	all IPv4 packets but transmit all others onto the local subnet		software. A VPN could protect all IPv4 packets but transmit all
	unprotected. At least one widely used VPN behaves this way. This is		others onto the local subnet unprotected. At least one widely used
	problematic on a dual stack host that has IPv6 enabled on its local		VPN behaves this way. This is problematic on a dual stack host that
	network. It establishes its VPN link and attempts to communicate		has IPv6 enabled on its local network. It establishes its VPN link
	with destinations that resolve to both IPv4 and IPv6 addresses. The		and attempts to communicate with destinations that resolve to both
	destination address selection mechanism prefers the IPv6 destination		IPv4 and IPv6 addresses. The destination address selection mechanism
	so the application sends packets to an IPv6 address. The VPN doesn't		prefers the IPv6 destination so the application sends packets to an
	know about IPv6, so instead of protecting the packets and sending		IPv6 address. The VPN doesn't know about IPv6, so instead of
	them to the remote end of the VPN, it passes such packets in the		protecting the packets and sending them to the remote end of the VPN,
	clear to the local network. The reason that packets meant to be		it passes such packets in the clear to the local network.
	protected would be sent in the clear on the local network is either
	because of the on-link assumption discussed in Section 2.2, or of		This is problematic for a number of reasons. The first is that if
	malicious hijacking of traffic by a rogue "fake" router advertising a		the node has a default IPv6 route, the packets will be forwarded
	prefix.		off-link to an unknown destination. Another is if no legitimate
			router is on-link and the node makes the on-link assumption discussed
			in Section 2.2, the packets will simply be sent onto the local link
			to be potentially viewed by a node spoofing the destination. A third
			is if a rogue IPv6 router exists on-link. In that case the malicious
			node will simply be sent all IPv6 packets in the clear.
	3.3.1 Mitigating Security Risks		3.3.1 Mitigating Security Risks
	The security policy implemented in firewalls, VPN software, or other		The security policy implemented in firewalls, VPN software, or other
	devices, must take a stance whether it applies equally to both IPv4		devices, must take a stance whether it applies equally to both IPv4
	and IPv6 traffic. It is probably desirable for policy to apply		and IPv6 traffic. It is probably desirable for the policy to apply
	equally to both IPv4 and IPv6, but the most important thing is to be		equally to both IPv4 and IPv6, but the most important thing is to be
	aware of the potential problem, and to make the policy clear to the		aware of the potential problem, and to make the policy clear to the
	administrator and user.		administrator and user.
	There is still a risk that IPv6 packets could be tunneled over a		There is still a risk that IPv6 packets could be tunneled over a
	transport layer such as UDP, implicitly bypassing security policy.		transport layer such as UDP, implicitly bypassing the security
	Some more complex mechanism could be implemented to apply the correct		policy. Some more complex mechanisms could be implemented to apply
	policy to such packets. This could be easy to do if tunnel endpoints		the correct policy to such packets. This could be easy to do if
	are co-located with a firewall, but more difficult if internal nodes		tunnel endpoints are co-located with a firewall, but more difficult
	do their own IPv6 tunneling.		if internal nodes do their own IPv6 tunneling.
	4. Application Robustness		4. Application Robustness
	Enabling IPv6 on a dual stack node is only useful if applications		Enabling IPv6 on a dual stack node is only useful if applications
	that support IPv6 on that node properly cycle through addresses		that support IPv6 on that node properly cycle through addresses
	returned from name lookups and fall back to IPv4 when IPv6		returned from name lookups and fall back to IPv4 when IPv6
	communication fails. Simply cycling through the list of addresses		communication fails. Simply cycling through the list of addresses
	returned from a name lookup when attempting connections works in most		returned from a name lookup when attempting connections works in most
	cases for most applications, but there are still cases where that's		cases for most applications, but there are still cases where that's
	not enough. Applications also need to be aware that the fact that a		not enough. Applications also need to be aware that the fact that a
	dual stack destination's IPv6 address is published in the DNS does		dual stack destination's IPv6 address is published in the DNS does
	not necessarily imply that all services on that destination function		not necessarily imply that all services on that destination function
	over IPv6. This problem, along with a thorough discussion of IPv6		over IPv6. This problem, along with a thorough discussion of IPv6
	application transition guidelines, is discussed in [APPTRANS].		application transition guidelines, is discussed in [APPTRANS].
	5. Security Considerations		5. Security Considerations
	This document raises security concerns in Section 3.3.		This document raises security concerns in Section 3.3. They are
			summarized below:
	Normative References		o Firewalls need to be configured properly to have deliberate
			security policies for IPv6 packets, including IPv6 packets
			encapsulated in other layers.
			o Implementations of virtual private networks need to have a
			deliberate IPv6 security policy that doesn't allow packets to
			accidentally appear in the clear when they were intended to be
			sent securely over the VPN.
			6. References
			6.1 Normative References
	[ADDRSEL] Draves, R., "Default Address Selection for Internet		[ADDRSEL] Draves, R., "Default Address Selection for Internet
	Protocol version 6 (IPv6)", RFC 3484, February 2003.		Protocol version 6 (IPv6)", RFC 3484, February 2003.
	[APPTRANS]		[APPTRANS]
	Hong, Y-G., Hagino, J., Savola, P. and M. Castro,		Hong, Y-G., Hagino, J., Savola, P. and M. Castro,
	"Application Aspects of IPv6 Transition", October 2003.		"Application Aspects of IPv6 Transition", March 2004.
	draft-ietf-v6ops-application-transition-00		draft-ietf-v6ops-application-transition-02
	[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor		[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
	Discovery for IP Version 6 (IPv6)", RFC 2461, December		Discovery for IP Version 6 (IPv6)", RFC 2461, December
	1998.		1998.
	[ONLINK] Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery		[ONLINK] Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery
	On-Link Assumption Considered Harmful", October 2003.		On-Link Assumption Considered Harmful", October 2003.
	draft-ietf-v6ops-onlinkassumption-00		draft-ietf-v6ops-onlinkassumption-02
	Informative References		6.2 Informative References
	[AUTOCONF]		[AUTOCONF]
	Thomson, S. and T. Narten, "IPv6 Stateless Address		Thomson, S. and T. Narten, "IPv6 Stateless Address
	Autoconfiguration", RFC 2462, December 1998.		Autoconfiguration", RFC 2462, December 1998.
	[HOSTREQS]		[HOSTREQS]
	Braden, R., "Requirements for Internet Hosts --		Braden, R., "Requirements for Internet Hosts --
	Communication Layers", STD 3, RFC 1122, October 1989.		Communication Layers", STD 3, RFC 1122, October 1989.
	[PRIVADDR]		[PRIVADDR]
	skipping to change at page 12, line 34		skipping to change at page 14, line 23
	Sun Microsystems, Inc.		Sun Microsystems, Inc.
	17 Network Circle		17 Network Circle
	UMPK17-202		UMPK17-202
	Menlo Park, CA 94025		Menlo Park, CA 94025
	EMail: james.paugh@sun.com		EMail: james.paugh@sun.com
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The authors gratefully acknowledge the contributions of Jim Bound,		The authors gratefully acknowledge the contributions of Jim Bound,
	Tim Hartrick, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald		Fernando Gont, Tony Hain, Tim Hartrick, Mika Liljeberg, Erik
			Nordmark, Kacheong Poon, Pekka Savola, Randall Stewart, and Ronald
	van der Pol.		van der Pol.
	Appendix B. Changes from draft-ietf-v6ops-v6onbydefault-00		Appendix B. Changes from draft-ietf-v6ops-v6onbydefault-01
			o Added specificity to the DNS resolver problem in Section 2.1.
			o Added a few paragraphs in Section 2.3.1.1 describing potential
			drawbacks to TCP aborting connections ins SYN-SENT or SYN-RECEIVED
			state.
			o Added Section 2.3.1.3 describing how a higher level API could be
			used to manage connections.
			o Expanded Section 2.3.3 to describe desired SCTP behavior when
			encountering soft errors.
			o Added a summary of security concerns to Section 5.
			o Miscellaneous editorial changes.
			Appendix C. Changes from draft-ietf-v6ops-v6onbydefault-00
	o Clarified in the abstract and introduction that the document is		o Clarified in the abstract and introduction that the document is
	meant to raise awareness, and not to specify whether IPv6 should		meant to raise awareness, and not to specify whether IPv6 should
	be enabled by default or not.		be enabled by default or not.
	o Shortened section Section 2.2 and made reference to [ONLINK].		o Shortened Section 2.2 and made reference to [ONLINK].
	o Added clarification in section Section 2.3 about packets that are		o Added clarification in Section 2.3 about packets that are lost
	lost without ICMPv6 notification.		without ICMPv6 notification.
	o Section Section 2.3 now has subsections for TCP, UDP, and SCTP.		o Section 2.3 now has subsections for TCP, UDP, and SCTP.
	o Removed text in Section 2.3.1.1 suggesting that hosts usually were		o Removed text in Section 2.3.1.1 suggesting that hosts usually were
	only assigned one address when [HOSTREQS] was written.		only assigned one address when [HOSTREQS] was written.
	o Added text in Section 2.3.1.1 suggesting a method for applications		o Added text in Section 2.3.1.1 suggesting a method for applications
	to advise TCP of their preference for ICMPv6 handling.		to advise TCP of their preference for ICMPv6 handling.
	o Added section Section 2.3.1.2.		o Added Section 2.3.1.2.
	o Added section Section 2.3.2.		o Added Section 2.3.2.
	o Added section Section 2.3.3.		o Added Section 2.3.3.
	o Strengthened wording in section Section 3.1.1 to suggest that		o Strengthened wording in Section 3.1.1 to suggest that devices
	devices enforcing scope boundaries must send ICMPv6 Destination		enforcing scope boundaries must send ICMPv6 Destination
	Unreachable messages.		Unreachable messages.
	o Clarified that the VPN problem described in Section 3.3 is due to		o Clarified that the VPN problem described in Section 3.3 is due to
	a combination of the VPN software and either the on-link		a combination of the VPN software and either the on-link
	assumption and/or a "bad guy".		assumption and/or a "bad guy".
	o Shortened section Section 4 and made reference to [APPTRANS].		o Shortened Section 4 and made reference to [APPTRANS].
	o Miscellaneous editorial changes.		o Miscellaneous editorial changes.
	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 or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/