draft-ietf-v6ops-addr-select-ps-06.txt		draft-ietf-v6ops-addr-select-ps-07.txt
	IPv6 Operations Working Group A. Matsumoto		IPv6 Operations Working Group A. Matsumoto
	Internet-Draft T. Fujisaki		Internet-Draft T. Fujisaki
	Intended status: Informational NTT		Intended status: Informational NTT
	Expires: November 15, 2008 R. Hiromi		Expires: December 14, 2008 R. Hiromi
	K. Kanayama
	Intec Netcore		Intec Netcore
	May 14, 2008		K. Kanayama
			INTEC Systems
			June 12, 2008
	Problem Statement of Default Address Selection in Multi-prefix		Problem Statement of Default Address Selection in Multi-prefix
	Environment: Operational Issues of RFC3484 Default Rules		Environment: Operational Issues of RFC3484 Default Rules
	draft-ietf-v6ops-addr-select-ps-06.txt		draft-ietf-v6ops-addr-select-ps-07.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 38		skipping to change at page 1, line 39
	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		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 November 15, 2008.		This Internet-Draft will expire on December 14, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	A single physical link can have multiple prefixes assigned to it. In		A single physical link can have multiple prefixes assigned to it. In
	that environment, end hosts might have multiple IP addresses and be		that environment, end hosts might have multiple IP addresses and be
	required to use them selectively. RFC 3484 defines default source		required to use them selectively. RFC 3484 defines default source
	and destination address selection rules and is implemented in a		and destination address selection rules and is implemented in a
	variety of OS's. But, it has been too difficult to use operationally		variety of OS's. But, it has been too difficult to use operationally
	for several reasons, In some environment where multiple prefixes are		for several reasons. In some environment where multiple prefixes are
	assigned on a single physical link, the host with the default address		assigned on a single physical link, the host using the default
	selection rules will experience some trouble in communication. This		address selection rules will experience some trouble in
	document describes the possible problems that end hosts could		communication. This document describes the possible problems that
	encounter in an environment with multiple prefixes.		end hosts could encounter in an environment with multiple prefixes.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3		1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Source Address Selection . . . . . . . . . . . . . . . . . 4		2.1. Source Address Selection . . . . . . . . . . . . . . . . . 4
	2.1.1. Multiple Routers on Single Interface . . . . . . . . . 4		2.1.1. Multiple Routers on Single Interface . . . . . . . . . 4
	2.1.2. Ingress Filtering Problem . . . . . . . . . . . . . . 5		2.1.2. Ingress Filtering Problem . . . . . . . . . . . . . . 5
	2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 6		2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 6
	skipping to change at page 3, line 27		skipping to change at page 3, line 27
	unexpected asymmetric routing, filtering by a router or discarding of		unexpected asymmetric routing, filtering by a router or discarding of
	packets bacause there is no route to the host.		packets bacause there is no route to the host.
	Considering a multi-prefix environment, destination address selection		Considering a multi-prefix environment, destination address selection
	is also important for correct or better communication establishment.		is also important for correct or better communication establishment.
	RFC 3484 [RFC3484] defines default source and destination address		RFC 3484 [RFC3484] defines default source and destination address
	selection algorithms and is implemented in a variety of OS's. But,		selection algorithms and is implemented in a variety of OS's. But,
	it has been too difficult to use operationally for several reasons,		it has been too difficult to use operationally for several reasons,
	such as lack of autoconfiguration method. There are some problematic		such as lack of autoconfiguration method. There are some problematic
	cases where the host with the default address selection rules		cases where the hosts using the default address selection rules
	encounter communication troubles.		encounter communication troubles.
	This document describes such possibilities of incorrect address		This document describes such possibilities of incorrect address
	selection which leads to dropping packets and communication failure.		selection which leads to dropping packets and communication failure.
	1.1. Scope of this document		1.1. Scope of this document
	As other mechanisms already exists, the multi-homing techniques for		As other mechanisms already exist, the multi-homing techniques for
	achieving redundancy are basically out of our scope.		achieving redundancy are basically out of our scope.
	We focus on an end-site network environment and unmanaged hosts in		We focus on an end-site network environment and unmanaged hosts in
	such an environment. This is because address selection behavior at		such an environment. This is because address selection behavior at
	this kind of hosts are difficult to manipulate owing to the users's		this kind of hosts is difficult to manipulate owing to the users's
	lack of knowledge, hosts' location, or massiveness of the hosts.		lack of knowledge, hosts' location, or massiveness of the hosts.
	The scope of this document is to sort out problematic cases related		The scope of this document is to sort out problematic cases related
	to address selection. It includes problems that can be solved in the		to address selection. It includes problems that can be solved in the
	framework of RFC 3484 and problems that cannot. For the latter, RFC		framework of RFC 3484 and problems that cannot. For the latter, RFC
	3484 might be modified to meet their needs, or another address		3484 might be modified to meet their needs, or another address
	selection solution might be necessary. For the former, an additional		selection solution might be necessary. For the former, an additional
	mechanism that mitigates the operational difficulty might be		mechanism that mitigates the operational difficulty might be
	necessary.		necessary.
	skipping to change at page 5, line 43		skipping to change at page 5, line 43
	+------+		+------+
	[Fig. 2]		[Fig. 2]
	When a relatively small site, which we call a "customer network", is		When a relatively small site, which we call a "customer network", is
	attached to two upstream ISPs, each ISP delegates a network address		attached to two upstream ISPs, each ISP delegates a network address
	block, which is usually /48, and a host has multiple IPv6 addresses.		block, which is usually /48, and a host has multiple IPv6 addresses.
	When the source address of an outgoing packet is not the one that is		When the source address of an outgoing packet is not the one that is
	delegated by an upstream ISP, there is a possibility that the packet		delegated by an upstream ISP, there is a possibility that the packet
	will be dropped at the ISP by its Ingress Filter. Ingress		will be dropped at the ISP by its Ingress Filter. Ingress filtering
	filtering(uRPF: unicast Reverse Path Forwarding) is becoming more		is becoming more popular among ISPs to mitigate the damage of DoS
	popular among ISPs to mitigate the damage of DoS attacks.		attacks.
	In this example, when the Router chooses the default route to ISP2		In this example, when the Router chooses the default route to ISP2
	and the Host chooses 2001:db8:1000:1::100 as the source address for		and the Host chooses 2001:db8:1000:1::100 as the source address for
	packets sent to a host (2001:db8:2000::1) somewhere on the Internet,		packets sent to a host (2001:db8:2000::1) somewhere on the Internet,
	the packets may be dropped at ISP2 because of Ingress Filtering.		the packets may be dropped at ISP2 because of Ingress Filtering.
	Solution analysis:		Solution analysis:
	One possible solution for this case is adopting source address		One possible solution for this case is adopting source address
	based routing at Router. Another solution may be using static		based routing at Router. Another solution may be using static
	skipping to change at page 9, line 47		skipping to change at page 9, line 47
	web pages or communicating with the general public, but that is bad		web pages or communicating with the general public, but that is bad
	for a service that uses address-based authentication and for logging		for a service that uses address-based authentication and for logging
	purposes.		purposes.
	If you could turn the temporary address on and off, that would be		If you could turn the temporary address on and off, that would be
	better. If you could switch its usage per service (destination		better. If you could switch its usage per service (destination
	address), that would also be better. The same situation can be found		address), that would also be better. The same situation can be found
	when using HA (home address) and CoA (care-of address)in a Mobile		when using HA (home address) and CoA (care-of address)in a Mobile
	IPv6 [RFC3775] network.		IPv6 [RFC3775] network.
	At the Future Work section in RFC 3041, it discusses that the API		The Future Work section in RFC 3041 discusses that an API extension
	extension might be necessary to achieve better address selection		might be necessary to achieve a better address selection mechanism
	mechanism with finer granularity.		with finer granularity.
	Solution analysis:		Solution analysis:
	This problem can not be solved in the RFC 3484 framework. A		This problem can not be solved in the RFC 3484 framework. A
	possible solution is to make applications to select desirable		possible solution is to make applications to select desirable
	addresses by using IPv6 Socket API for Source Address Selection		addresses by using the IPv6 Socket API for Source Address
	defind in RFC 5014 [RFC5014].		Selection defind in RFC 5014 [RFC5014].
	2.2. Destination Address Selection		2.2. Destination Address Selection
	2.2.1. IPv4 or IPv6 prioritization		2.2.1. IPv4 or IPv6 prioritization
	The default policy table gives IPv6 addresses higher precedence than		The default policy table gives IPv6 addresses higher precedence than
	IPv4 addresses. There seem to be many cases, however, where network		IPv4 addresses. There seem to be many cases, however, where network
	administrators want to control the address selection policy of end-		administrators want to control the address selection policy of end-
	hosts the other way around.		hosts the other way around.
	skipping to change at page 13, line 32		skipping to change at page 13, line 32
	4. Security Considerations		4. Security Considerations
	When an intermediate router performs policy routing (e.g. source		When an intermediate router performs policy routing (e.g. source
	address based routing), inappropriate address selection causes		address based routing), inappropriate address selection causes
	unexpected routing. For example, in the network described in 2.1.3,		unexpected routing. For example, in the network described in 2.1.3,
	when Host-A uses a default address selection policy and chooses an		when Host-A uses a default address selection policy and chooses an
	inappropriate address, a packet sent to VPN can be delivered to a		inappropriate address, a packet sent to VPN can be delivered to a
	location via the Internet. This issue can lead to packet		location via the Internet. This issue can lead to packet
	eavesdropping or session hijack. However, sending the packet back to		eavesdropping or session hijack. However, sending the packet back to
	the correct path from the attacker to the node is not easy, so these		the correct path from the attacker to the node is not easy, so these
	two risk are not serious.		two risks are not serious.
	As documented in the security consideration section in RFC 3484,		As documented in the security consideration section in RFC 3484,
	address selection algorithms expose a potential privacy concern.		address selection algorithms expose a potential privacy concern.
	When a malicious host can make a target host perform address		When a malicious host can make a target host perform address
	selection, for example by sending a anycast or a multicast packet,		selection, for example by sending a anycast or a multicast packet,
	the malicious host can know multiple addresses attached to the target		the malicious host can get knowledge multiple addresses attached to
	host. In a case like 2.1.4, if an attacker can make Host to send a		the target host. In a case like 2.1.4, if an attacker can make Host
	multicast packet and Host performs the default address selection		to send a multicast packet and Host performs the default address
	algorithm, the attacker may be able to determine the ULAs attached to		selection algorithm, the attacker may be able to determine the ULAs
	the Host.		attached to the Host.
	These security risks have roots in inappropriate address selection.		These security risks have roots in inappropriate address selection.
	Therefore, if a countermeasure is taken, and hosts always select an		Therefore, if a countermeasure is taken, and hosts always select an
	appropriate address that is suitable to a site's network structure		appropriate address that is suitable to a site's network structure
	and routing, these risks can be avoided.		and routing, these risks can be avoided.
	5. IANA Considerations		5. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	skipping to change at page 15, line 5		skipping to change at page 15, line 5
	[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6		[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
	Socket API for Source Address Selection", RFC 5014,		Socket API for Source Address Selection", RFC 5014,
	September 2007.		September 2007.
	6.2. Informative References		6.2. Informative References
	Appendix A. Appendix. Revision History		Appendix A. Appendix. Revision History
	01:		01:
	IP addresse notations changed to docmentation address.		IP addresse notations changed to documentation address.
	Descriptoin of solutions deleted.		Description of solutions deleted.
	02:		02:
	Security considerations section rewritten according to comments		Security considerations section rewritten according to comments
	from SECDIR.		from SECDIR.
	03:		03:
	Intended status changed to Informational.		Intended status changed to Informational.
	04:		04:
	This version reflects comments from IESG members.		This version reflects comments from IESG members.
	05:		05:
	This version reflects comments from IESG members and Bob Hinden.		This version reflects comments from IESG members and Bob Hinden.
	06:		06:
	This version reflects comments from Thomas Narten.		This version reflects comments from Thomas Narten.
			07:
			This version reflects comments from Alfred Hoenes.
	Authors' Addresses		Authors' Addresses
	Arifumi Matsumoto		Arifumi Matsumoto
	NTT PF Lab		NTT PF Lab
	Midori-Cho 3-9-11		Midori-Cho 3-9-11
	Musashino-shi, Tokyo 180-8585		Musashino-shi, Tokyo 180-8585
	Japan		Japan
	Phone: +81 422 59 3334		Phone: +81 422 59 3334
	skipping to change at page 16, line 5		skipping to change at page 16, line 5
	Ruri Hiromi		Ruri Hiromi
	Intec Netcore, Inc.		Intec Netcore, Inc.
	Shinsuna 1-3-3		Shinsuna 1-3-3
	Koto-ku, Tokyo 136-0075		Koto-ku, Tokyo 136-0075
	Japan		Japan
	Phone: +81 3 5665 5069		Phone: +81 3 5665 5069
	Email: hiromi@inetcore.com		Email: hiromi@inetcore.com
	Ken-ichi Kanayama		Ken-ichi Kanayama
	Intec Netcore, Inc.		INTEC Systems Institute, Inc.
	Shinsuna 1-3-3		Shimoshin-machi 5-33
	Koto-ku, Tokyo 136-0075		Toyama-shi, Toyama 930-0804
	Japan		Japan
	Phone: +81 3 5665 5069		Phone: +81 76 444 8088
	Email: kanayama_kenichi@intec-si.co.jp		Email: kanayama_kenichi@intec-si.co.jp
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
End of changes. 17 change blocks.
	33 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/