< draft-ietf-shim6-locator-pair-selection-03.txt		draft-ietf-shim6-locator-pair-selection-04.txt >
	Network Working Group M. Bagnulo		Network Working Group M. Bagnulo
	Internet-Draft UC3M		Internet-Draft UC3M
	Intended status: Informational February 22, 2008		Intended status: Informational October 23, 2008
	Expires: August 25, 2008		Expires: April 26, 2009
	Default Locator-pair selection algorithm for the SHIM6 protocol		Default Locator-pair selection algorithm for the SHIM6 protocol
	draft-ietf-shim6-locator-pair-selection-03		draft-ietf-shim6-locator-pair-selection-04
	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 34 ¶		skipping to change at page 1, line 34 ¶
	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 August 25, 2008.		This Internet-Draft will expire on April 26, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	In this note, we present a locator-pair selection mechanism for the		In this note, we present a locator-pair selection mechanism for the
	shim6 protocol. The presented mechanism provides an ordered list of		shim6 protocol. The presented mechanism provides an ordered list of
	available locator-pairs that can be used for outgoing traffic.		available locator-pairs that can be used for outgoing traffic.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Preliminary considerations . . . . . . . . . . . . . . . . . . 4		2. Preliminary considerations . . . . . . . . . . . . . . . . . . 4
	2.1. Candidate Locator-pair set . . . . . . . . . . . . . . . . 4		2.1. Candidate Locator-pair set . . . . . . . . . . . . . . . . 4
	2.2. Locator-pair States . . . . . . . . . . . . . . . . . . . 5		2.2. Locator-pair States . . . . . . . . . . . . . . . . . . . 5
	2.3. Locator preferences . . . . . . . . . . . . . . . . . . . 5		2.3. Locator preferences . . . . . . . . . . . . . . . . . . . 5
	2.3.1. Remote locator preferences . . . . . . . . . . . . . . 5		2.3.1. Remote locator preferences . . . . . . . . . . . . . . 5
	2.3.2. Source locator preferences . . . . . . . . . . . . . . 6		2.3.2. Source locator preferences . . . . . . . . . . . . . . 6
	2.4. Locator-pair selection table . . . . . . . . . . . . . . . 6		2.4. Locator-pair selection table . . . . . . . . . . . . . . . 6
	3. Default Locator-Pair Selection Algorithm . . . . . . . . . . . 6		3. Default Locator-Pair Selection Algorithm . . . . . . . . . . . 7
	4. Security considerations . . . . . . . . . . . . . . . . . . . 8		4. Security considerations . . . . . . . . . . . . . . . . . . . 8
	4.1. Privacy considerations . . . . . . . . . . . . . . . . . . 8		4.1. Privacy considerations . . . . . . . . . . . . . . . . . . 8
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Intellectual Property and Copyright Statements . . . . . . . . . . 11		Intellectual Property and Copyright Statements . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Once that a shim6 context is established between two peers, they are		Once that a shim6 context is established between two peers, they are
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	communication even if no outage has occurred.		communication even if no outage has occurred.
	In this note, we present a locator-pair selection mechanism for the		In this note, we present a locator-pair selection mechanism for the
	shim6 protocol. The presented mechanism provides an ordered list of		shim6 protocol. The presented mechanism provides an ordered list of
	available locator-pairs that can be used for outgoing traffic (note		available locator-pairs that can be used for outgoing traffic (note
	that since unidirectional locator pairs are supported by the shim6		that since unidirectional locator pairs are supported by the shim6
	protocol, the locator pair used in the outgoing direction may not		protocol, the locator pair used in the outgoing direction may not
	affect the locator pair used by the peer to send incoming traffic).		affect the locator pair used by the peer to send incoming traffic).
	The motivation for having a locator selection mechanism different		The motivation for having a locator selection mechanism different
	than RFC 3484 [3] is that RFC 3484 was designed to select addresses		than RFC 3484 [RFC4291] is that RFC 3484 was designed to select
	that were both identifiers and locators, so, in some cases the		addresses that were both identifiers and locators, so, in some cases
	selection criteria differs from the one used when selecting addresses		the selection criteria differs from the one used when selecting
	that will used only as locators. In particular, when addresses are		addresses that will used only as locators. In particular, when
	to be used as identifiers and as locators, stable addresses such as		addresses are to be used as identifiers and as locators, stable
	Home Addresses are preferred over more temporary addresses as Care-		addresses such as Home Addresses are preferred over more temporary
	Off Addresses. If an address is to be used only as a locator,		addresses as Care-Off Addresses. If an address is to be used only as
	probably the stability property is not as important as achieving a		a locator, probably the stability property is not as important as
	more direct path, making a Care-off Address more attractive than a		achieving a more direct path, making a Care-off Address more
	Home Address. Similar considerations can be made with respect to		attractive than a Home Address. Similar considerations can be made
	private and public addresses. In addition, the locator pair		with respect to private and public addresses. In addition, the
	selection mechanism described in this document incorporates into the		locator pair selection mechanism described in this document
	selection mechanism shim-specific information, such as available		incorporates into the selection mechanism shim-specific information,
	reachability information and local and remote locator preferences		such as available reachability information and local and remote
	obtained through the shim6 protocol. Finally, the mechanism		locator preferences obtained through the shim6 protocol. Finally,
	presented in this note is a locator pair selection mechanism as		the mechanism presented in this note is a locator pair selection
	opposed to separate source address and destination address selection		mechanism as opposed to separate source address and destination
	mechanisms as described in RFC 3484. We think that such approach is		address selection mechanisms as described in RFC 3484. We think that
	more appropriate for the shim6 protocol, since reachability seems to		such approach is more appropriate for the shim6 protocol, since
	be a property of an address pair rather than a property of a single		reachability seems to be a property of an address pair rather than a
	address.		property of a single address.
	The presented mechanism takes into account general properties of the		The presented mechanism takes into account general properties of the
	available addresses, in particular the address family (v4 or v6),		available addresses, in particular the address family (v4 or v6),
	address scope [3], mobility consideration (Home-Addresses and Care-		address scope [RFC4291], mobility consideration (Home-Addresses and
	off Addresses) [4], status of the addresses (Preferred and Deprecated		Care-off Addresses) [RFC3775], status of the addresses (Preferred and
	addresses) [5], privacy considerations (Public and Temporary		Deprecated addresses) [RFC2462], privacy considerations (Public and
	addresses) [6]. In addition it also takes into account shim6		Temporary addresses) [RFC3041]. In addition it also takes into
	specific information such as whether the addresses are known to be		account shim6 specific information such as whether the addresses are
	locally operational (as defined in [2]), if locator pairs are know to		known to be locally operational (as defined in [faildet]), if locator
	be unidirectionally operational [2], the local and remote preferences		pairs are know to be unidirectionally operational [faildet], the
	for the different locators available in the shim6 context.		local and remote preferences for the different locators available in
			the shim6 context.
	Multicast addresses are out of the scope of the document.		Multicast addresses are out of the scope of the document.
	2. Preliminary considerations		2. Preliminary considerations
	2.1. Candidate Locator-pair set		2.1. Candidate Locator-pair set
	We define the local set of locally-operational locators (LOLs(local))		We define the local set of locally-operational locators (LOLs(local))
	as the local locators that are included in the local locator set		as the local locators that are included in the local locator set
	(Ls(local) as defined in [1]) and that are locally operational as		(Ls(local) as defined in [shim]) and that are locally operational as
	defined in [2]. Locally operational addresses are discovered through		defined in [faildet]. Locally operational addresses are discovered
	local means that are outside of the scope of this document.		through local means that are outside of the scope of this document.
	We define the set of the locally-operational locators of the peer		We define the set of the locally-operational locators of the peer
	(LOLs(peer)) as the remote locators that are included in the peer		(LOLs(peer)) as the remote locators that are included in the peer
	locator set (Ls(peer) as defined in [1]) and that are locally		locator set (Ls(peer) as defined in [shim]) and that are locally
	operational in the peer as defined in [2]. The peers' locally		operational in the peer as defined in [faildet]. The peers' locally
	operational locators are discovered through the Locator List Option		operational locators are discovered through the Locator List Option
	and the Locator Preferences Option (in particular the BROKEN flag)		and the Locator Preferences Option (in particular the BROKEN flag)
	defined in the shim protocol [1].		defined in the shim protocol [shim].
	The candidate locator-pair set is the set of locator pairs that can		The candidate locator-pair set is the set of locator pairs that can
	be used to send packets in a shim context.		be used to send packets in a shim context.
	The candidate locator-pair set contains in all the possible locator		The candidate locator-pair set contains in all the possible locator
	pairs formed with the first of them belonging to the local set of		pairs formed with the first of them belonging to the local set of
	locally-operational locators (LOLs(local)) and the second locator		locally-operational locators (LOLs(local)) and the second locator
	belonging to the locally-operational locators of the peer		belonging to the locally-operational locators of the peer
	(LOLs(peer)).		(LOLs(peer)).
	skipping to change at page 5, line 11 ¶		skipping to change at page 5, line 12 ¶
	Question: should we allow locator pairs with all types of scope		Question: should we allow locator pairs with all types of scope
	combinations or should we restrict the type of scope combinations for		combinations or should we restrict the type of scope combinations for
	the inclusion in the cadidate set? If we don't allow all the		the inclusion in the cadidate set? If we don't allow all the
	combinations, we can remove rule 1 aboput scopes		combinations, we can remove rule 1 aboput scopes
	2.2. Locator-pair States		2.2. Locator-pair States
	Locator pairs can be in the following state:		Locator pairs can be in the following state:
	o Unidirectionally Operational state: As defined in [2], is when		o Unidirectionally Operational state: As defined in [faildet], is
	packets send with the first locator as the source address and the		when packets send with the first locator as the source address and
	second locator as a destination address are known to reach the		the second locator as a destination address are known to reach the
	destination. In the shim6 case, a locator pair is know to be		destination. In the shim6 case, a locator pair is know to be
	unidirectionally operational when there is fresh information about		unidirectionally operational when there is fresh information about
	packets reaching the peer, using the mechanisms defined in [2] or		packets reaching the peer, using the mechanisms defined in
	thanks to recent ULP feedback. When the information about		[faildet] or thanks to recent ULP feedback. When the information
	reachability expires, the locator pair moves to Unknown state.		about reachability expires, the locator pair moves to Unknown
			state.
	o Non-Operational state: The locator pair is known to be non-		o Non-Operational state: The locator pair is known to be non-
	operational i.e. that packets containing the first locator as		operational i.e. that packets containing the first locator as
	source address and the second locator as destination address do		source address and the second locator as destination address do
	not reach the destination. In the shim6 case this can be known		not reach the destination. In the shim6 case this can be known
	because recent attempts to exchange packets have failed. When the		because recent attempts to exchange packets have failed. When the
	information about unreachability expires, the locator pair moves		information about unreachability expires, the locator pair moves
	to Unknown state.		to Unknown state.
	o Unknown state: No recent reachability information is available for		o Unknown state: No recent reachability information is available for
	this locator-pair.		this locator-pair.
	2.3. Locator preferences		2.3. Locator preferences
	2.3.1. Remote locator preferences		2.3.1. Remote locator preferences
	Remote locator preferences can be obtained through the shim6 protocol		Remote locator preferences can be obtained through the shim6 protocol
	using the Locator Preference option. The preferences consist in a		using the Locator Preference option. The preferences consist in a
	Flag octet, a Priority octet and an optional Weight octet.		Flag octet, a Priority octet and an optional Weight octet.
	The weight field express the relative weight for locators with the		The weight field express the relative weight for locators with the
	same priority, and as defined in [7] larger weights should be given a		same priority, and as defined in [RFC2782] larger weights should be
	proportionally higher probability of being selected. In order to		given a proportionally higher probability of being selected. In
	include this probability information in the locator-pair selection		order to include this probability information in the locator-pair
	algorithm, a new weight* information is generated from the weight		selection algorithm, a new weight* information is generated from the
	values as following:		weight values as following:
	We order each set of destination addresses with the same priority and		We order each set of destination addresses with the same priority and
	defined weight values using the following algorithm defined in [7]:		defined weight values using the following algorithm defined in
			[RFC2782]:
	Arrange all addresses (that have not been ordered yet) in any order,		Arrange all addresses (that have not been ordered yet) in any order,
	except that all those with weight 0 are placed at the beginning of		except that all those with weight 0 are placed at the beginning of
	the list.		the list.
	Compute the sum of the weights of those addresses, and with each		Compute the sum of the weights of those addresses, and with each
	address associate the running sum in the selected order. Then choose		address associate the running sum in the selected order. Then choose
	a uniform (pseudo)random number between 0 and the sum computed		a uniform (pseudo)random number between 0 and the sum computed
	(inclusive), and select the address whose running sum value is the		(inclusive), and select the address whose running sum value is the
	first in the selected order which is greater than or equal to the		first in the selected order which is greater than or equal to the
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 30 ¶
	The procedure is repeated for each one of the sets containing		The procedure is repeated for each one of the sets containing
	destination addresses with equal priority.		destination addresses with equal priority.
	The Weight information is not used in the locator-pair selection		The Weight information is not used in the locator-pair selection
	mechanism, but the Weight* information is.		mechanism, but the Weight* information is.
	2.3.2. Source locator preferences		2.3.2. Source locator preferences
	With respect to the local locator preferences, this document assumes		With respect to the local locator preferences, this document assumes
	that the host will have a mechanism to express Priority and Weight		that the host will have a mechanism to express Priority and Weight
	information for local locators similar to the one defined in [7].		information for local locators similar to the one defined in
			[RFC2782].
	The same procedure is used to assign Weight* values to the source		The same procedure is used to assign Weight* values to the source
	locators that have the same priority value.		locators that have the same priority value.
	Note that destination and source addresses are never included in the		Note that destination and source addresses are never included in the
	same set, even if they have the same priority value.		same set, even if they have the same priority value.
	The Weight information is not used in the locator-pair s election		The Weight information is not used in the locator-pair s election
	mechanism, but the Weight* information is.		mechanism, but the Weight* information is.
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 12 ¶
	address in the RFC2462 sense and src2 is a deprecated		address in the RFC2462 sense and src2 is a deprecated
	address in the RFC2462 sense, then prefer (src1,dst1)		address in the RFC2462 sense, then prefer (src1,dst1)
	Rule 9: Prefer Local Priority: If src1 of (src1,dst1) has a lowest		Rule 9: Prefer Local Priority: If src1 of (src1,dst1) has a lowest
	Priority than src2 of (src2,dst2) then prefer (src1,dst1)		Priority than src2 of (src2,dst2) then prefer (src1,dst1)
	Rule 10: Prefer Local Weight*: If src1 of (src1,dst1) has a lowest		Rule 10: Prefer Local Weight*: If src1 of (src1,dst1) has a lowest
	Weight* than src2 of (src2,dst2) then prefer (src1,dst1)		Weight* than src2 of (src2,dst2) then prefer (src1,dst1)
	Rule 11: Prefer Local Care-off Addresses: If src1 is a Care-off		Rule 11: Prefer Local Care-off Addresses: If src1 is a Care-off
	address [4] and src2 is a Home Address, the prefer		address [RFC3775] and src2 is a Home Address, the prefer
	(src1,dst1). This only applies to Mobile IP [4].		(src1,dst1). This only applies to Mobile IP [RFC3775].
	Rule 12: Prefer Remote Priority: If dst1 of (src1,dst1) has a lowest		Rule 12: Prefer Remote Priority: If dst1 of (src1,dst1) has a lowest
	Priority than dst2 of (src2,dst2) then prefer (src1,dst1)		Priority than dst2 of (src2,dst2) then prefer (src1,dst1)
	Rule 13: Prefer Remote Weight*: If dst1 of (src1,dst1) has a lowest		Rule 13: Prefer Remote Weight*: If dst1 of (src1,dst1) has a lowest
	Weight* than dst2 of (src2,dst2) then prefer (src1,dst1)		Weight* than dst2 of (src2,dst2) then prefer (src1,dst1)
	Rule 14: Prefer Remote Care-off Addresses: If dst1 is a Care-off		Rule 14: Prefer Remote Care-off Addresses: If dst1 is a Care-off
	address (Temporary flag set in the Locator preferences		address (Temporary flag set in the Locator preferences
	options defined in [1]) and dst2 is not a Care-off address,		options defined in [shim]) and dst2 is not a Care-off
	the prefer (src1,dst1). This only applies to Mobile IP [4].		address, the prefer (src1,dst1). This only applies to
			Mobile IP [RFC3775].
	Other rules that may be worth taking into account are:		Other rules that may be worth taking into account are:
	o Prefer native transport		o Prefer native transport
	o Prefer smaller scope		o Prefer smaller scope
	o Prefer most dissimilar locator pair to the currently used		o Prefer most dissimilar locator pair to the currently used
	o Prefer locator pair contained in incoming packet		o Prefer locator pair contained in incoming packet
	o Longest prefix match		o Longest prefix match
	o Should we eliminate the site and link local addresses from the		o Should we eliminate the site and link local addresses from the
	accpetable locator set?		accpetable locator set?
	skipping to change at page 8, line 43 ¶		skipping to change at page 8, line 47 ¶
	Note that according to the shim6 protocol specification, locators are		Note that according to the shim6 protocol specification, locators are
	included in the Ls(peer) only after HBA/CGA verification has been		included in the Ls(peer) only after HBA/CGA verification has been
	successful. This eliminates the possibility of using locators that		successful. This eliminates the possibility of using locators that
	do not belong to the peer. Besides, it should be noted that before		do not belong to the peer. Besides, it should be noted that before
	using a given locator pair to actually send data packets, a		using a given locator pair to actually send data packets, a
	reachability test is performed in order to prevent flooding attacks.		reachability test is performed in order to prevent flooding attacks.
	4.1. Privacy considerations		4.1. Privacy considerations
	Including or not RFC3041 [6] addresses in the Locator set available		Including or not RFC3041 [RFC3041] addresses in the Locator set
	for a shim6 context may have privacy implications. This is so		available for a shim6 context may have privacy implications. This is
	because of two reaosns: First, the inclusion of RFC 3041 addresses in		so because of two reaosns: First, the inclusion of RFC 3041 addresses
	the locator set discloses the RFC3041 addresses of the host to the		in the locator set discloses the RFC3041 addresses of the host to the
	peer. Second, the locator sets of both peers are exchanged in clear		peer. Second, the locator sets of both peers are exchanged in clear
	text during the shim6 context establishment and/or in the subsequent		text during the shim6 context establishment and/or in the subsequent
	UPDATE messages. This means that an attacker located along the path		UPDATE messages. This means that an attacker located along the path
	that can observe such packets can discover that all the addresses		that can observe such packets can discover that all the addresses
	included in the locator set belong to the same host, beating the		included in the locator set belong to the same host, beating the
	purpose of RFC3041 private addresses. So, when forming the locator		purpose of RFC3041 private addresses. So, when forming the locator
	set of a shim6 context the host must take into account these privacy		set of a shim6 context the host must take into account these privacy
	considerations in order to decide whether to include RFC3041		considerations in order to decide whether to include RFC3041
	addresses in the locator set of a shim6 context.		addresses in the locator set of a shim6 context.
	skipping to change at page 9, line 23 ¶		skipping to change at page 9, line 27 ¶
	probability in the locator-pair selection process was suggested by		probability in the locator-pair selection process was suggested by
	Albert Banchs.		Albert Banchs.
	Marcelo Bagnulo worked on this document while visiting Ericsson		Marcelo Bagnulo worked on this document while visiting Ericsson
	Research laboratory Nomadiclab.		Research laboratory Nomadiclab.
	Iljitsch van Beijnum provided a detailed review of this document.		Iljitsch van Beijnum provided a detailed review of this document.
	6. References		6. References
	[1] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim		[shim] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim
	protocol", draft-ietf-shim6-proto-04 (work in progress),		protocol", draft-ietf-shim6-proto-04 (work in progress),
	March 2006.		March 2006.
	[2] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair		[faildet] Arkko, J. and I. Beijnum, "Failure Detection and Locator
	Exploration Protocol for IPv6 Multihoming",		Pair Exploration Protocol for IPv6 Multihoming",
	draft-ietf-shim6-failure-detection-03 (work in progress),		draft-ietf-shim6-failure-detection-03 (work in progress),
	December 2005.		December 2005.
	[3] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, February 2006.
	[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	IPv6", RFC 3775, June 2004.		in IPv6", RFC 3775, June 2004.
	[5] Thomson, S. and T. Narten, "IPv6 Stateless Address		[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
	Autoconfiguration", RFC 2462, December 1998.		Autoconfiguration", RFC 2462, December 1998.
	[6] Narten, T. and R. Draves, "Privacy Extensions for Stateless		[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
	Address Autoconfiguration in IPv6", RFC 3041, January 2001.		Stateless Address Autoconfiguration in IPv6", RFC 3041,
			January 2001.
	[7] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	February 2000.		February 2000.
	[8] Draves, R., "Default Address Selection for Internet Protocol		[RFC3484] Draves, R., "Default Address Selection for Internet
	version 6 (IPv6)", RFC 3484, February 2003.		Protocol version 6 (IPv6)", RFC 3484, February 2003.
	Author's Address		Author's Address
	Marcelo Bagnulo		Marcelo Bagnulo
	Universidad Carlos III de Madrid		Universidad Carlos III de Madrid
	Av. Universidad 30		Av. Universidad 30
	Leganes, Madrid 28911		Leganes, Madrid 28911
	SPAIN		SPAIN
	Phone: 34 91 6248814		Phone: 34 91 6248814
	skipping to change at page 11, line 44 ¶		skipping to change at line 444 ¶
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		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 that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 26 change blocks.
	85 lines changed or deleted		87 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/