draft-ietf-6man-addr-select-opt-04.txt		draft-ietf-6man-addr-select-opt-05.txt
	6man Working Group A. Matsumoto		6man Working Group A. Matsumoto
	Internet-Draft T. Fujisaki		Internet-Draft T. Fujisaki
	Intended status: Standards Track J. Kato		Intended status: Standards Track NTT
	Expires: January 17, 2013 NTT		Expires: February 24, 2013 T. Chown
	T. Chown
	University of Southampton		University of Southampton
	July 16, 2012		August 23, 2012
	Distributing Address Selection Policy using DHCPv6		Distributing Address Selection Policy using DHCPv6
	draft-ietf-6man-addr-select-opt-04.txt		draft-ietf-6man-addr-select-opt-05.txt
	Abstract		Abstract
	RFC 3484 defines default address selection mechanisms for IPv6 that		RFC 3484 defines default address selection mechanisms for IPv6 that
	allow nodes to select appropriate address when faced with multiple		allow nodes to select appropriate address when faced with multiple
	source and/or destination addresses to choose between. The RFC 3484		source and/or destination addresses to choose between. The RFC 3484
	allowed for the future definition of methods to administratively		allowed for the future definition of methods to administratively
	configure the address selection policy information. This document		configure the address selection policy information. This document
	defines a new DHCPv6 option for such configuration, allowing a site		defines a new DHCPv6 option for such configuration, allowing a site
	administrator to distribute address selection policy overriding the		administrator to distribute address selection policy overriding the
	skipping to change at page 1, line 41		skipping to change at page 1, line 40
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on January 17, 2013.		This Internet-Draft will expire on February 24, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 6, line 35		skipping to change at page 6, line 35
	When the information from the DHCP server goes stale, the policy		When the information from the DHCP server goes stale, the policy
	received form the DHCP server should be removed and the default		received form the DHCP server should be removed and the default
	policy should be restored.		policy should be restored.
	The received information can be considered stale in several cases,		The received information can be considered stale in several cases,
	such as, when the interface goes down, the DHCP server does not		such as, when the interface goes down, the DHCP server does not
	respond for a certain amount of time, and the Information Refresh		respond for a certain amount of time, and the Information Refresh
	Time is expired.		Time is expired.
	4.3. Processing multiple received policies		4.3. Multi-interface situation
	The policy table, and other parameters specified in this document are		The policy table, and other parameters specified in this document are
	node-global information by its nature. So, the node cannot use		node-global information by its nature. So, the node cannot use
	multiple received policies at the same time. In other words, once		multiple received policies at the same time. In other words, once
	the received policy from one source is merged with another source,		the received policy from one source is merged with one from another
	the policy is more or less changed. The policy table is defined as a		source, the effect of both policy are more or less changed. The
	whole, so the slightest addition/deletion from the policy table		policy table is defined as a whole, so the slightest addition/
	brings a change in semantics of the policy.		deletion from the policy table brings a change in semantics of the
			policy.
	It also should be noted that, when a node is single-homed and has
	only one upstream line, adopting a received policy table does not
	degrade the security level.
	Under the above assumptions, how to handle multiple received policies		It also should be noted that absence of the distributed policy from a
	is specified below.		certain network interface should not be treated as absence of policy
			itself, because it may mean preference for the default address
			selection policy.
	A node MAY use Address Selection options in any of the following two		Under the above assumptions, how to handle received policy is
	cases:		specified below.
	1: The Address Selection option is delivered across the only secure,		A node MAY use Address Selection options by default in any of the
	trusted channel.		following two cases:
	2: The Address Selection option delivery is not secured, but the node
	is single-homed.
	In other cases the node MUST NOT use Policy Table options unless the		1: The host is single-homed, where the host belongs to one
	node is specifically configured to do so.		administrative network domain exclusively usually through one
			active network interface.
			2: The host implements some advanced heuristics to deal with multiple
			received policy, which is outside the scope of this document.
	Discussion: The secure trusted channel does not necessarily mean a		The above restrictions do not preclude implementations from providing
	prioritized route in the routing table. So, such a situation		configuration options to enable this option on a certain network
	could happen that the traffic goes through a non-secure, non-		interface.
	trusted channel and the host follows the delivered policy from a
	secure, truested channel. However, this policy is not for
	optimization of traffic and resources at the local network and the
	hosts, but for implementing the network policy to the hosts in the
	network.
	5. Implementation Considerations		5. Implementation Considerations
	o The value 'label' is passed as an unsigned integer, but there is		o The value 'label' is passed as an unsigned integer, but there is
	no special meaning for the value, that is whether it is a large or		no special meaning for the value, that is whether it is a large or
	small number. It is used to select a preferred source address		small number. It is used to select a preferred source address
	prefix corresponding to a destination address prefix by matching		prefix corresponding to a destination address prefix by matching
	the same label value within the DHCP message. DHCPv6 clients need		the same label value within the DHCP message. DHCPv6 clients need
	to convert this label to a representation specified by each		to convert this label to a representation specified by each
	implementation (e.g., string).		implementation (e.g., string).
	skipping to change at page 10, line 28		skipping to change at page 10, line 25
	o There may be some demands to control the use of special address		o There may be some demands to control the use of special address
	types such as the temporary addresses described in RFC4941		types such as the temporary addresses described in RFC4941
	[RFC4941], address assigned by DHCPv6 and so on. (e.g., informing		[RFC4941], address assigned by DHCPv6 and so on. (e.g., informing
	not to use a temporary address when it communicate within the an		not to use a temporary address when it communicate within the an
	organization's network). It is possible to indicate the type of		organization's network). It is possible to indicate the type of
	addresses using reserved field value.		addresses using reserved field value.
	Authors' Addresses		Authors' Addresses
	Arifumi Matsumoto		Arifumi Matsumoto
	NTT SI Lab		NTT NT Lab
	3-9-11 Midori-Cho		3-9-11 Midori-Cho
	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
	Tomohiro Fujisaki		Tomohiro Fujisaki
	NTT PF Lab		NTT NT Lab
	3-9-11 Midori-Cho		3-9-11 Midori-Cho
	Musashino-shi, Tokyo 180-8585		Musashino-shi, Tokyo 180-8585
	Japan		Japan
	Phone: +81 422 59 7351		Phone: +81 422 59 7351
	Email: fujisaki@nttv6.net		Email: fujisaki@nttv6.net
	Jun-ya Kato
	NTT SI Lab
	3-9-11 Midori-Cho
	Musashino-shi, Tokyo 180-8585
	Japan
	Phone: +81 422 59 2939
	Email: kato@syce.net
	Tim Chown		Tim Chown
	University of Southampton		University of Southampton
	Southampton, Hampshire SO17 1BJ		Southampton, Hampshire SO17 1BJ
	United Kingdom		United Kingdom
	Email: tjc@ecs.soton.ac.uk		Email: tjc@ecs.soton.ac.uk
End of changes. 14 change blocks.
	44 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/