draft-ietf-v6ops-addr-select-req-03.txt		draft-ietf-v6ops-addr-select-req-04.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: April 14, 2008 R. Hiromi		Expires: May 9, 2008 R. Hiromi
	K. Kanayama		K. Kanayama
	Intec Netcore		Intec Netcore
	October 12, 2007		November 6, 2007
	Requirements for address selection mechanisms		Requirements for address selection mechanisms
	draft-ietf-v6ops-addr-select-req-03.txt		draft-ietf-v6ops-addr-select-req-04.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 37		skipping to change at page 1, line 37
	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 April 14, 2008.		This Internet-Draft will expire on May 9, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	In a multi-prefix environment, nodes could have multiple addresses on		In a multi-prefix environment, nodes could have multiple addresses on
	one network interface. RFC 3484 defines a source and destination		one network interface. RFC 3484 defines a source and destination
	address-selection algorithm, which is commonly deployed in current		address-selection algorithm, which is commonly deployed in current
	skipping to change at page 2, line 21		skipping to change at page 2, line 21
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements of Address Selection . . . . . . . . . . . . . . . 3		2. Requirements of Address Selection . . . . . . . . . . . . . . . 3
	2.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 4		2.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . . 4
	2.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 4		2.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 4
	2.5. Application-Specific Behavior . . . . . . . . . . . . . . . 4		2.5. Application-Specific Behavior . . . . . . . . . . . . . . . 4
	2.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 4		2.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 4
	2.7. Central Control . . . . . . . . . . . . . . . . . . . . . . 4		2.7. Central Control . . . . . . . . . . . . . . . . . . . . . . 4
	2.8. Next-hop Selection . . . . . . . . . . . . . . . . . . . . 4		2.8. Next-hop Selection . . . . . . . . . . . . . . . . . . . . 4
	3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4		2.9. Compatibility with RFC 3493 . . . . . . . . . . . . . . . . 4
			3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	3.1. List of threats introduced by new address-selection		3.1. List of threats introduced by new address-selection
	mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5		mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. List of recommendations in which security mechanism		3.2. List of recommendations in which security mechanism
	should be applied . . . . . . . . . . . . . . . . . . . . . 5		should be applied . . . . . . . . . . . . . . . . . . . . . 5
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 6		5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	5.2. Informative References . . . . . . . . . . . . . . . . . . 6		5.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6		Appendix A. Appendix. Revision History . . . . . . . . . . . . . . 6
	Intellectual Property and Copyright Statements . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
			Intellectual Property and Copyright Statements . . . . . . . . . . 9
	1. Introduction		1. Introduction
	One physical network can have multiple logical networks. In that		One physical network can have multiple logical networks. In that
	case, an end-host has multiple IP addresses. (e.g., in the IPv4-IPv6		case, an end-host has multiple IP addresses. (e.g., in the IPv4-IPv6
	dual-stack environment, in a site that uses both ULA [RFC4193] and		dual-stack environment, in a site that uses both ULA [RFC4193] and
	global scope addresses or in a site connected to multiple upstream		global scope addresses or in a site connected to multiple upstream
	IPv6 networks) For such a host, RFC 3484 [RFC3484] defines default		IPv6 networks) For such a host, RFC 3484 [RFC3484] defines default
	address-selection rules for the source and destination addresses.		address-selection rules for the source and destination addresses.
	skipping to change at page 4, line 48		skipping to change at page 4, line 48
	have effect on address-selection behavior at their users' hosts.		have effect on address-selection behavior at their users' hosts.
	2.8. Next-hop Selection		2.8. Next-hop Selection
	The mechanism can control next-hop-selection behavior at hosts or		The mechanism can control next-hop-selection behavior at hosts or
	cooperate with other routing mechanisms, such as routing protocols		cooperate with other routing mechanisms, such as routing protocols
	and RFC 4191 [RFC4191]. If the address-selection mechanism is used		and RFC 4191 [RFC4191]. If the address-selection mechanism is used
	with a routing mechanism, the two mechanisms have to be able to work		with a routing mechanism, the two mechanisms have to be able to work
	synchronously.		synchronously.
			2.9. Compatibility with RFC 3493
			The mechanism can allow an application that uses the basic socket
			interface defined in RFC 3493 [RFC3493] to work correctly. That is,
			with the basic socket interface the application can select an
			appropriate source and destination addresses and can communicate with
			the destination host. This requirement does not necessarily mean
			that OS protocol stack and socket libraries should not be changed.
	3. Security Considerations		3. Security Considerations
	3.1. List of threats introduced by new address-selection mechanism		3.1. List of threats introduced by new address-selection mechanism
	There are some security incidents when combining these requirements		There are some security incidents when combining these requirements
	described in Section 2 into a protocol. In particular, here are six		described in Section 2 into a protocol. In particular, here are six
	possible threats.		possible threats.
	1. Hijacking or tapping from malicious nodes connecting from beyond		1. Hijacking or tapping from malicious nodes connecting from beyond
	unapproved network boundaries.		unapproved network boundaries.
	skipping to change at page 6, line 20		skipping to change at page 6, line 28
	This document has no actions for IANA.		This document has no actions for IANA.
	5. References		5. References
	5.1. Normative References		5.1. Normative References
	[I-D.ietf-v6ops-addr-select-ps]		[I-D.ietf-v6ops-addr-select-ps]
	Matsumoto, A., "Problem Statement of Default Address		Matsumoto, A., "Problem Statement of Default Address
	Selection in Multi-prefix Environment: Operational Issues		Selection in Multi-prefix Environment: Operational Issues
	of RFC3484 Default Rules",		of RFC3484 Default Rules",
	draft-ietf-v6ops-addr-select-ps-01 (work in progress),		draft-ietf-v6ops-addr-select-ps-02 (work in progress),
	April 2007.		October 2007.
	[RFC3484] Draves, R., "Default Address Selection for Internet		[RFC3484] Draves, R., "Default Address Selection for Internet
	Protocol version 6 (IPv6)", RFC 3484, February 2003.		Protocol version 6 (IPv6)", RFC 3484, February 2003.
			[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
			Stevens, "Basic Socket Interface Extensions for IPv6",
			RFC 3493, February 2003.
	5.2. Informative References		5.2. Informative References
	[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and		[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
	More-Specific Routes", RFC 4191, November 2005.		More-Specific Routes", RFC 4191, November 2005.
	[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast		[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Addresses", RFC 4193, October 2005.		Addresses", RFC 4193, October 2005.
			Appendix A. Appendix. Revision History
			04:
			A new requirement item "Compatibility with RFC 3493" was added,
			which reflected a comment from Remi Denis-Courmont at the v6ops
			mailing list.
			03:
			Security Consideration section was rewritten according to comments
			from SECDIR.
			02:
			The description and evaluation of solution approaches were
			separated into a new document called
			draft-arifumi-v6ops-addr-select-sol-00.
			01:
			Other than policy table distribution approach, the solution
			section included several solutions discussed at 67th IETF meeting.
	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
	Email: arifumi@nttv6.net		Email: arifumi@nttv6.net
End of changes. 10 change blocks.
	9 lines changed or deleted		42 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/