draft-ietf-geopriv-dhcp-lbyr-uri-option-15.txt		draft-ietf-geopriv-dhcp-lbyr-uri-option-16.txt
	Network WG James Polk		Network WG James Polk
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Proposed Standard May 31, 2012		Intended status: Proposed Standard Jan 27, 2013
	Expires: Nov 30, 2012		Expires: June 27, 2013
	Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6		Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6
	Option for a Location Uniform Resource Identifier (URI)		Option for a Location Uniform Resource Identifier (URI)
	draft-ietf-geopriv-dhcp-lbyr-uri-option-15		draft-ietf-geopriv-dhcp-lbyr-uri-option-16
	Abstract		Abstract
	This document creates a Dynamic Host Configuration Protocol (DHCP)		This document creates a Dynamic Host Configuration Protocol (DHCP)
	Option for transmitting a client's geolocation Uniform Resource		Option for transmitting a client's geolocation Uniform Resource
	Identifier (URI). This Location URI can then be dereferenced in a		Identifier (URI), and another Option to explicitly indicate how long
	separate transaction by the client or sent to another entity and		that location URI is to be considered valid. This Location URI can
	dereferenced to learn physically where the client is located.		then be dereferenced in a separate transaction by the client or sent
			to another entity and dereferenced to learn physically where the
			client is located, but only while valid.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 30, 2012.		This Internet-Draft will expire on June 27, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	warranty as described in the Simplified BSD License.		warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Format of the DHCP LocationURI Option . . . . . . . . . . . . 4		2. Format of the DHCP LocationURI and Valid-For Options . . . . 4
	2.1. Overall Format of LocationURI Option in IPv4 . . . . . 4		2.1. Overall Format of LocationURI Option in IPv4 . . . . . 4
	2.2. Overall Format of LocationURI Option in IPv6 . . . . . 5		2.2. Overall Format of LocationURI Option in IPv6 . . . . . 5
	2.3. LocationURI Format for both IPv4 and IPv6 . . . . . . . 5		2.3. Overall Format of Valid-For Option in IPv4 . . . . . . 5
			2.4. Overall Format of Valid-For Option in IPv6 . . . . . . 6
			2.5. Rules for both LocationURI and Valid-For Options . . . 6
	3. DHCP Option Operation . . . . . . . . . . . . . . . . . . . . 6		3. DHCP Option Operation . . . . . . . . . . . . . . . . . . . . 6
	3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8		3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8
	3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8		3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8
	3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9		3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . 12		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . 12		7.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1. Introduction		1. Introduction
	This document creates a Dynamic Host Configuration Protocol (DHCP)		This document creates a Dynamic Host Configuration Protocol (DHCP)
	Option for transmitting a client's geolocation Uniform Resource		Option for transmitting a client's geolocation Uniform Resource
	Identifier (URI). The DHCP implementation of the client can then		Identifier (URI), and another Option to explicitly indicate how long
	make this location information available to upper layer protocols		that location URI is to be considered valid. In this scenario, the
	for their usage. This location URI points a Location Server		DHCP client is a Geopriv Target (i.e., the entity whose geolocation
	[RFC5808] which has the geolocation of the client (through means		is associated with the location URI). The DHCP implementation of the
	not defined in this document). In this scenario, the DHCP client		client can then make this location information available to other
	is a Geopriv Target (i.e., the entity whose geolocation is		applications for their usage. This location URI points a Location
	associated with the location URI).		Server [RFC5808] which has the geolocation of the client (e.g.,
			uploaded into a wiremap database when the client attached wall-jack,
	Applications using upper layer protocols within the Target can then		or by means of 802.11 geolocation mechanisms).
	choose to deference this location URI and/or transmit the URI to
	another entity as a means of conveying where the Target is located.
	Dereferencing a location URI is described in [RFC6442]. Conveying
	a location URI is also described in [RFC6442]. Session Initiation
	Protocol (SIP) is not the only protocol that can dereference a
	location URI; there is also HTTP-Enabled Location Delivery (HELD)
	[ID-HELD-DEREF] and HTTP [RFC2616].
	Having a location URI has advantages over having a PIDF-LO,		Applications within the Target can then choose to deference this
	especially when a target's location changes. With a location URI,		location URI and/or transmit the URI to another entity as a means of
	when a target moves, the location URI does not change (at least		conveying where the Target is located. Both Conveying and
	within the same domain). It can still be given out as the reference		Dereferencing a location URI is described in [RFC6442]. Session
	to the Target's current location. The opposite is true if the		Initiation Protocol (SIP) is not the only protocol that can
	location is conveyed by value in a message. Once the Target moves,		dereference a location URI; there is also HTTP-Enabled Location
	the previously given location is no longer valid, and if the Target		Delivery (HELD) [ID-HELD-DEREF] and HTTP [RFC2616].
	wants to inform another entity about its location, it has to send
	the PIDF-LO to the location recipient (again).
	A Location Server (LS) stores the Target's location as a presence		A Location Server (LS) stores the Target's location as a presence
	document, called a Presence Information Data Format - Location		document, called a Presence Information Data Format - Location
	Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server		Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server
	is the entity contacted during the act of dereferencing a Target's		is the entity contacted during the act of dereferencing a Target's
	location. If the dereferencing entity has permission, defined in		location. If the dereferencing entity has permission, defined in
	[ID-GEO-POL], the location of the target will be received. The LS		[ID-GEO-POL], the location of the target will be received. The LS
	will grant permission to location inquires based on the rules		will grant permission to location inquiries based on the rules
	established by a Rule Holder [RFC3693]. The LS has the ability to		established by a Rule Holder [RFC3693]. The LS has the ability to
	challenge any request for a target's location, thereby providing		challenge any request for a target's location, thereby providing
	additive security properties before location revelation.		additive security properties before location revelation.
			Possessing a location URI has advantages over having a PIDF-LO,
			especially when a target's location changes. With a location URI,
			when a target moves, the location URI does not change (at least
			within the same domain). The location URI can still be given out as
			the reference to the Target's current location. The opposite is true
			if the location is conveyed by value in a message. Once the Target
			moves, the previously given location is no longer valid, and if the
			Target wants to inform another entity about its location, it has to
			send the PIDF-LO to the location recipient (again).
	A problem exists within existing RFCs that provide location to the		A problem exists within existing RFCs that provide location to the
	UA ([RFC6225] and [RFC4776]). These DHCP Options for geolocation		UA ([RFC6225] and [RFC4776]). Those DHCP Options for geolocation
	values require an update of the entire location information (LI)		values require an update of the entire location information (LI)
	every time a client moves. Not all clients will move frequently,		every time a client moves. Not all clients will move frequently,
	but some will. Refreshing location values every time a client moves		but some will. Refreshing location values every time a client moves
	does not scale in certain networks/environments, such as IP-based		does not scale in certain networks/environments, such as IP-based
	cellular networks, enterprise networks or service provider networks		cellular networks, enterprise networks or service provider networks
	with mobile endpoints. An 802.11 based access network is one		with mobile endpoints. An 802.11 based access network is one
	example of this. Constantly updating LCI to endpoints might not		example of this. Constantly updating Location Configuration
	scale in mobile (residential or enterprise or municipal) networks in		Information (LCI) to endpoints might not scale in mobile
	which the client is moving through more than one network attachment		(residential or enterprise or municipal) networks in which the
	point, perhaps as a person walks or drives with their client down a		client is moving through more than one network attachment point,
			perhaps as a person walks or drives with their client down a
	neighborhood street or apartment complex or a shopping center or		neighborhood street or apartment complex or a shopping center or
	through a municipality (that has IP connectivity as a service).		through a municipality (that has IP connectivity as a service).
	If the client was provided a location URI reference to retain and		If the client was provided a location URI reference to retain and
	hand out when it wants or needs to convey its location (in a		hand out when it wants or needs to convey its location (in a
	protocol other than DHCP), a location URI that would not change as		protocol other than DHCP), a location URI that would not change as
	the client's location changes (within a domain), scaling issues		the client's location changes (within a domain).Scaling issues
	would be significantly reduced to needing an update of the location		would be significantly reduced to needing an update of the location
	URI only when a client changes administrative domains - which is		URI only when a client changes administrative domains - which is
	much less often. This delivery of an indirect location has the		much less often. This delivery of an indirect location has the
	added benefit of not using up valuable or limited bandwidth to the		added benefit of not using up valuable or limited bandwidth to the
	client with the constant updates. It also relieves the client from		client with the constant updates. It also relieves the client from
	having to determine when it has moved far enough to consider asking		having to determine when it has moved far enough to consider asking
	for a refresh of its location.		for a refresh of its location.
	In enterprise networks, if a known location is assigned to each		In enterprise networks, if a known location is assigned to each
	individual Ethernet port in the network, a device that attaches to		individual Ethernet port in the network, a device that attaches to
	the network a wall-jack (directly associated with a specific		the network, such as a wall-jack (directly associated with a
	Ethernet Switch port) will be associated with a known location via a		specific Ethernet Switch port) will be associated with a known
	unique circuit-ID that's used by the RAIO Option defined in RFC 3046		location via a unique circuit-ID that's used by the Relay Agent
	[RFC3046]. This assumes wall-jacks have an updated wiremap		Information Option (RAIO) defined in RFC 3046 [RFC3046]. This
	database. RFC 6225 and RFC 4776 would return an LCI value of		assumes wall-jacks have an updated wiremap database. RFC 6225
	location. This document specifies how a location URI is returned
	using DHCP. The location URI points to a PIDF-LO contained on an
	LS. Performing a dereferencing transaction, that Target's PIDF-LO
	will be returned. If local configuration has the requirement of
	only assigning unique location URIs to each client at the same
	attachment point to the network (i.e., same RJ-45 jack or same
	802.11 Access Point - except when triangulation is used), then
	unique location URIs will be given out, though they will all have
	the same location at the record, relieving the backend Sighter or LS
	from individually maintaining each location independently.
	This Option can be useful in IEEE 802.16e connected endpoints or IP		[RFC6225] and RFC 4776 [RFC4776] would return an LCI value of
	cellular endpoints. The location URI Option can be configured on a		location for either IPv4 or IPv6. This document specifies how a
	router, such as a residential home gateway, such that the router		location URI is returned using DHCP. The location URI points to a
	receives this Location URI Option as a client with the ability to		PIDF-LO contained on an LS. Performing a dereferencing transaction,
	communicate to downstream endpoints as a server.		that Target's PIDF-LO will be returned. If local configuration has
			the requirement of only assigning unique location URIs to each
			client at the same attachment point to the network (i.e., same RJ-45
			jack or same 802.11 Access Point - except when triangulation is
			used), then unique location URIs will be given out. They will all
			have the same location at the record, relieving the backend Sighter
			or LS from individually maintaining each location independently.
			The location URI Option can be useful in IEEE 802.16e connected
			endpoints or IP cellular endpoints. The location URI Option can be
			configured on a router, such as a residential home gateway, such
			that the router receives this Location URI Option as a client with
			the ability to communicate to downstream endpoints as a server.
	How an LS responds to a dereference request can vary, and a policy		How an LS responds to a dereference request can vary, and a policy
	established by a Ruleholder [RFC3693] for a Location Target as to		established by a Ruleholder [RFC3693] for a Location Target as to
	what type of challenge(s) is to be used, how strong a challenge is		what type of challenge(s) is to be used, how strong a challenge is
	used or how precise the location information is given to a		used or how precise the location information is given to a
	Location Recipient (LR). This document does not provide mechanisms		Location Recipient (LR). This document does not provide mechanisms
	for the LS to tell the client about policies or for the client to		for the LS to tell the client about policies or for the client to
	specify a policy for the LS. While an LS should apply an appropriate		specify a policy for the LS. While an LS should apply an appropriate
	access-control policy, clients must assume that the LS will provide		access-control policy, clients must assume that the LS will provide
	location in response to any request (following the possession model		location in response to any request (following the possession model
	[RFC5808]). For further discussion of privacy, see the Security		[RFC5808]). For further discussion of privacy, see the Security
	Considerations.		Considerations.
	This document IANA-registers the new IPv4 and IPv6 DHCP Options for		This document IANA-registers the new IPv4 and IPv6 DHCP Options for
	a location URI.		a location URI and Valid-For.
	2. Format of the DHCP LocationURI Option		2. Format of the DHCP LocationURI Option
	2.1 Overall Format of LocationURI Option in IPv4		2.1 Overall Format of LocationURI Option in IPv4
	The LocationURI Option format for IPv4 is as follows:		The LocationURI Option format for IPv4 is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Code XXX | Length=XX | .		| Code XXX | Length=XX | .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
	. LocationURI... ...		. LocationURI... |
	. (see Section 2.3 for details) ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1. IPv4 Fields for this LocationURI Option		Figure 1. IPv4 Fields for this LocationURI Option
	Code XXX: The code for this DHCPv4 option (IANA assigned).		Code XXX: The code for this DHCPv4 option (IANA assigned).
	Length=XX: The length of this option, counted in bytes - not		Length=XX: The length of this option, counted in bytes - not
	counting the Code and Length bytes. This is a variable		counting the Code and Length bytes. This is a variable
	length Option, therefore the length value will change		length Option, therefore the length value will change
	based on the length of the URI within the Option.		based on the length of the URI within the Option.
	LocationURI: see Section 2.3 for details		LocationURI: Location URI - This field, in bytes, is the URI
			pointing at the location record where the PIDF-LO for
			the Location Target resides. The LocationURI is always
			represented in ASCII.
	2.2 Overall Format of LocationURI Option in IPv6		2.2 Overall Format of LocationURI Option in IPv6
	The LocationURI Option format for IPv6 is as follows:		The LocationURI Option format for IPv6 is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| option-code | option-len |		| option-code | option-len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LocationURI... .		| LocationURI... .
	. (see Section 2.3 for details) |		. |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2. IPv6 fields of this LocationURI Option		Figure 2. IPv6 fields of this LocationURI Option
	option-code: The code for this DHCPv6 option (IANA assigned).		option-code: The code for this DHCPv6 option (IANA assigned).
	option-len: The length of this option, counted in bytes - not		option-len: The length of this option, counted in bytes - not
	counting the Code and Length bytes. This is a variable		counting the option-code and option-len bytes. This is
	length Option, therefore the length value will change		a variable length Option, therefore the length value
	based on the length of the URI within the Option.		will change based on the length of the URI within the
			Option.
	LocationURI: see below (Section 2.3 for details).		LocationURI: see Section 2.1
	2.3 LocationURI Format for both IPv4 and IPv6		2.3 Overall Format of Valid-For Option in IPv4
	The LocationURI, in both DHCPv4 and DHCPv6, have the following		The Valid-For Option format for IPv4 is as follows:
	format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LuriType | LuriLength | LuriValue ...		| Code XXX | Valid-For .....
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			..... Valid-For |
			+-+-+-+-+-+-+-+-+
	Figure 3. LocationURI TLV Format for both IPv4 and IPv6		Figure 1. IPv4 Fields for this Valid-For Option
	LuriType: A one-byte identifier of the data location value.		Code XXX: The code for this DHCPv4 option (IANA assigned).
	LuriLength: The length of the LuriValue, not including the		Valid-For: Valid-For - The time, in seconds, the LocationURI -
	LuriLength field itself, up to a maximum of 255		received in the same DHCP message - is to be
	units. The unit of measurement is defined by the		considered valid for dereferencing. The Valid-For is
	LuriType field definition. The LuriLength itself is		always represented as a four-byte unsigned integer.
	always a one-byte unsigned integer.
	LuriValue: The LocationURI value, as described in detail below.		2.4 Overall Format of Valid-For Option in IPv6
	The LuriTypes this document defines for a point are:		The Valid-For Option format for IPv6 is as follows:
	LuriType=1 Location URI - This field, in bytes, is the URI		0 1 2 3
	pointing at the location record where the PIDF-LO for		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	the Location Target resides. The LuriValue of		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	LuriType=1 is always represented in UTF-8.		| option-code | Valid-For .....
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			..... Valid-For (Cont'd) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	LuriType=2 Valid-For - The time, in seconds, this URI is to be		Figure 2. IPv6 fields of this Valid-For Option
	considered Valid for dereferencing. The timer
	associated with this LuriType starts upon receipt of
	this Option by the client. The LuriValue of LuriType=2
	is always represented as a four-byte unsigned integer.
	The Valid-For (LuriType=2) indicates how long, in seconds, the		option-code: The code for this DHCPv6 option (IANA assigned).
	client is to consider this location URI (LuriType=1) valid.
	Applications MUST NOT make use of a location URI after it becomes		Valid-For: see Section 2.3
	invalid (i.e., after the Valid-For timer expires).
			2.5 Rules for both LocationURI and Valid-For Options
			The LocationURI and Valid-For Options have the following
			rules:
			o Implementation of the Location URI Option is mandatory on the DHCP
			server and client, per this specification.
			o Implementation of the Valid-For Option is OPTIONAL on the DHCP
			server and client, per this specification.
			o The Location URI Option MUST be sent from a server, and received
			by a client with or without an accompanying Valid-For Option.
			The Valid-For Option offers no meaningful information to a client
			without an accompanying Location URI Option, and might be
			misunderstood or misapplied, therefore
			o The Valid-For Option MUST NOT be sent from a server, and received
			by a client, without an accompanying Location URI Option.
			o A client receiving a Valid-For Option without a Location URI
			Option MUST ignore the Valid-For Option.
			o The Valid-For Option MUST only be considered in relation to the
			Location URI Option. It has no other purpose in DHCP then in
			relation to the Location URI (i.e., there is no other Option in
			DHCP to which it has meaning).
			o The Valid-For Option MUST NOT cause any error in handling the
			Location URI, i.e., if not understood, it MUST be ignored.
			o Servers MUST assume that clients will overwrite any existing,
			previously sent values of Location URI Option and/or Valid-For
			Option.
			o Clients MUST overwrite any existing, previously sent values of
			Location URI Option and/or Valid-For Option when receiving the
			next instance of either Option.
	The choice of the Valid-For value is a policy decision for the		The choice of the Valid-For value is a policy decision for the
	operator of the DHCP server. Like location URIs themselves, it can		operator of the DHCP server. Like location URIs themselves, it can
	be statically configured on the DHCP server or provisioned		be statically configured on the DHCP server or provisioned
	dynamically (via an out-of-band exchange with a Location Information		dynamically (via an out-of-band exchange with a Location Information
	Server) as requests for location URIs are received.		Server) as requests for location URIs are received.
			o Clients receiving both a Location URI and Valid-For Options start
			the Valid-For timer upon receipt of the DHCP message containing
			both Options.
			o All Valid-For Options MUST be no longer than the existing DHCP
			lease timer. All received Valid-For values MUST be tuned by the
			client to the client's existing refresh timer.
			o For any received Valid-For values longer than the existing DHCP
			lease time, the client MUST tune to the client's to be no longer
			than existing lease timer.
			o For Valid-For values shorter than the client's lease time, the
			Location URI Option MUST be deleted (i.e., not accessible to any
			client applications) unless both the Location URI and Valid-For
			Options are refreshed.
			o Applications MUST NOT make use of a location URI after it becomes
			invalid (i.e., after the Valid-For timer expires).
	The Valid-For timer is used only at the application layer, as an		The Valid-For timer is used only at the application layer, as an
	indication of when the URI can be used to access location. It is		indication of when the URI can be used to access location. It is
	independent of the DHCP lease timer, and in no way related to the		independent of the DHCP lease timer, and in no way related to the
	DHCP state machine. Clients MUST NOT trigger an automatic DHCP		DHCP state machine.
	refresh on expiry of the Valid-For timer; rather, they should follow
	normal DHCP mechanics.		o Clients MUST NOT trigger an automatic DHCP refresh on expiry of
			the Valid-For timer; rather, they SHOULD follow normal DHCP
			mechanics.
	Server operators should consider the relation between the Valid-For		Server operators should consider the relation between the Valid-For
	time and the lease time. Clients typically request a lease refresh		time and the lease time. Clients typically request a lease refresh
	when half the lease time is up. If the Valid-For time is less than		when half the lease time is up. If the Valid-For time is less than
	the typical refresh rate (i.e., half the lease time), then for the		the typical refresh rate (i.e., half the lease time), then for the
	remaining interval, clients will run the risk of not having a usable		remaining interval, clients will run the risk of not having a usable
	location URI for applications. If the Valid-For time is less than		location URI for applications. If the Valid-For time is less than
	half the typical refresh rate, it is a near certainty clients will		half the typical refresh rate, it is a near certainty clients will
	not have a usable location URI for the interval between the		not have a usable location URI for the interval between the
	Valid-For time and the typical refresh time for applications.		Valid-For time and the typical refresh time for applications. For
			example, if a lease is set to 24 hours, the typical refresh request
	For example, if a lease is set to 24 hours, the typical refresh		is set to initiate at the 12 hour mark. If the Valid-For timer is
	request is set to initiate at the 12 hour mark. If the Valid-For		set to less than 24 hours, but more than 12 hours (in this example),
	timer is set to less than 24 hours, but more than 12 hours (in this		the client might not be refreshed at the 12 hour mark and runs the
	example), the client might not be refreshed at the 12 hour mark and		risk of not have a location URI for applications that request it.
	runs the risk of not have a location URI for applications that		If, on the other hand, the Valid-For timer is less than 12 hours (in
	request it. If, on the other hand, the Valid-For timer is less than		this example, which is before a typical client would ask for a
	12 hours (in this example, which is before a typical client would		refresh, applications will be without a usable location URI until
	ask for a refresh, applications will be without a usable location		the full refresh has been received.
	URI until the full refresh has been received.
	It should be expected that clients will overwrite any previous
	Option values when receiving a new instance of that Option number.
	The Valid-For (LuriType=2) offers no meaningful information without
	an accompanying Location URI (LuriType=1), therefore a Valid-For
	(LuriType=2) MUST NOT be sent without a Location URI (LuriType=1).
	The Valid-For (LuriType=2) is not mandated for use by this document.
	However, its presence MUST NOT cause any error in handling the
	location URI (i.e., if not understood, it MUST be ignored).
	This Option format is highly extensible. Additional LuriType types
	created MUST be done so through IANA registration with a standards
	track RFC.
	3. DHCP Option Operation		3. DHCP Option Operation
	The [RFC3046] RAIO can be utilized to provide the appropriate		The [RFC3046] RAIO can be utilized to provide the appropriate
	indication to the DHCP Server where this DISCOVER or REQUEST message		indication to the DHCP Server where this DISCOVER or REQUEST message
	came from, in order to supply the correct response.		came from, in order to supply the correct response.
	Caution SHOULD always be used involving the creation of large		Caution SHOULD always be used involving the creation of large
	Options, meaning that this Option MAY need to be in its own INFORM,		Options, meaning that this Option MAY need to be in its own INFORM,
	OPTION or ACK message.		OPTION or ACK message.
	skipping to change at page 7, line 48		skipping to change at page 8, line 47
	non-concatenated, overwrite the previous value.		non-concatenated, overwrite the previous value.
	Location URIs MUST NOT reveal identity information of the user of		Location URIs MUST NOT reveal identity information of the user of
	the device, since DHCP is a cleartext delivery protocol. For		the device, since DHCP is a cleartext delivery protocol. For
	example, creating a location URI such as		example, creating a location URI such as
	sips:34LKJH534663J54@example.com		sips:34LKJH534663J54@example.com
	is better than a location URI such as		is better than a location URI such as
	sips:aliceisat123mainstalantageorgiaus@example.com		sips:aliceisat123mainstatlantageorgiaus@example.com
	The username portion of the first example URI provides no direct		The username portion of the first example URI provides no direct
	identity information (in which 34LKJH534663J54 is considered to be a		identity information (in which 34LKJH534663J54 is considered to be a
	random number in this example).		random number in this example).
	In the <presence> element of a PIDF-LO document, there is an		In the <presence> element of a PIDF-LO document, there is an
	'entity' attribute that identities what entity *this* document		'entity' attribute that identifies what entity *this* presence
	(including the associated location) refers to. It is up to the		document (including the associated location) refers to. It is up to
	PIDF-LO generator, either Location Server or an application in the		the PIDF-LO generator, either Location Server or an application in
	endpoint, to insert the identity in the 'entity' attribute. This		the endpoint, to insert the identity in the 'entity' attribute.
	can be seen in [RFC4119]. The considerations for populating the		This can be seen in [RFC4119]. The considerations for populating
	entity attribute value in a PIDF-LO document are independent from		the entity attribute value in a PIDF-LO document are independent
	the considerations for avoiding exposing identification information		from the considerations for avoiding exposing identification
	in the username part of a location URI.		information in the username part of a location URI.
	This Option is used only for communications between a DHCP client		This Option is used only for communications between a DHCP client
	and a DHCP server. It can be solicited (requested) by the client,		and a DHCP server. It can be solicited (requested) by the client,
	or it can be pushed by the server without a request for it. DHCP		or it can be pushed by the server without a request for it. DHCP
	Options not understood MUST be ignored [RFC2131]. A DHCP server		Options not understood MUST be ignored [RFC2131]. A DHCP server
	supporting this Option might or might not have the location of a		supporting this Option might or might not have the location of a
	client. If a server does not have a client's location, but needs to		client. If a server does not have a client's location, but needs to
	provide this Location URI Option to a client (for whatever reason),		provide this Location URI Option to a client (for whatever reason),
	an LS is contacted. This server-to-LS transaction is not DHCP,		an LS is contacted. This server-to-LS transaction is not DHCP,
	therefore it is out of scope of this document. Note that this		therefore it is out of scope of this document. Note that this
	skipping to change at page 8, line 50		skipping to change at page 9, line 49
	3.1 Architectural Assumptions		3.1 Architectural Assumptions
	The following assumptions have been made for use of this LocationURI		The following assumptions have been made for use of this LocationURI
	Option for a client to learn its location URI (in no particular		Option for a client to learn its location URI (in no particular
	order):		order):
	o Any user control (what [RFC3693] calls a 'Ruleholder') for access		o Any user control (what [RFC3693] calls a 'Ruleholder') for access
	to the dereferencing step is assumed to be out of scope of this		to the dereferencing step is assumed to be out of scope of this
	document. An example authorization policy is in [ID-GEO-POL].		document. An example authorization policy is in [ID-GEO-POL].
	o The authorization vs. possession security model can be found in		o The authorization security model vs. possession security model
	[RFC5808], describing what is expected in each model of		discussion can be found in [RFC5606], describing what is expected
	operation. It should be assumed that a location URI attained		in each model of operation. It should be assumed that a location
	using DHCP will operate under an possession model by default.		URI attained using DHCP will operate under an possession model by
			default. An authorization model can be instituted as a matter of
	An authorization model can be instituted as a matter of local		local policy. An authorization model means possessing the
	policy. An authorization model means possessing the location URI		location URI does not give that entity the right to view the
	does not give that entity the right to view the PIDF-LO of the		PIDF-LO of the target whose location is indicated in a presence
	target whose location is indicated in a presence document. The		document. The dereference transaction will be challenged by the
	dereference transaction will be challenged by the Location Server		Location Server only in an authorization model. The nature of
	only in an authorization model. The nature of this challenge is		this challenge is out of scope of this document.
	out of scope of this document.
	o This document does not prevent some environments from operating		o This document does not prevent some environments from operating
	in an authorization model, for example - in less tightly		in an authorization model, for example - in less tightly
	controlled networks. The costs associated with authorization vs.		controlled networks. The costs associated with authorization vs.
	possession models are discussed in Section 3.3.2 of [RFC5606].		possession models are discussed in Section 3.3.2 of [RFC5606].
	3.2 Harmful URIs and URLs		3.2 Harmful URIs and URLs
	There are, in fact, some types of URIs that are not good to receive,		There are, in fact, some types of URIs that are not good to receive,
	due to security concerns. For example, any URLs that can have		due to security concerns. For example, any URLs that can have
	scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web		scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web
	pages that have scripts. Therefore,		pages that have scripts. Therefore,
	o URIs received via this Option MUST NOT be automatically sent to a		o URIs received via this Option MUST NOT be automatically sent to a
	general-browser to connect to a web page, because they could have		general-browser to connect to a web page, because they could have
	harmful scripts.		harmful scripts.
	o This Option MUST NOT contain "data:" URLs, because they could		o This Option MUST NOT contain "data:" URLs, because they could
	contain harmful scripts.		contain harmful scripts.
	Instead of listing all the types of URIs and URLs that can be		o Section 3.3 IANA registers acceptable location URI schemes (or
	misused or potentially have harmful effects, Section 3.3 IANA		types) for use by this specification. Clients MUST reject URI
	registers acceptable location URI schemes (or types).		schemes not currently registered in IANA.
	3.3 Valid Location URI Schemes or Types		3.3 Valid Location URI Schemes or Types
	This section specifies which URI types are acceptable as a location		This section specifies which URI types are acceptable as a location
	URI scheme (or type) for this DHCP Option:		URI scheme (or type) for this DHCP Option:
	1. sip:		1. sip:
	2. sips:		2. sips:
	3. pres:		3. pres:
	4. http:		4. http:
	skipping to change at page 10, line 6		skipping to change at page 11, line 5
	URIs using the "pres" scheme are dereferenced using the presence		URIs using the "pres" scheme are dereferenced using the presence
	event package for SIP [RFC3856], so they will reference a PIDF-LO		event package for SIP [RFC3856], so they will reference a PIDF-LO
	document when location is available. Responses to requests for URIs		document when location is available. Responses to requests for URIs
	with other schemes ("sip", "sips", "http", and "https") MUST have		with other schemes ("sip", "sips", "http", and "https") MUST have
	MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS		MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS
	URIs MAY refer to information with MIME type 'application/held+xml',		URIs MAY refer to information with MIME type 'application/held+xml',
	in order to support HELD dereferencing [ID-HELD-DEREF]. Clients can		in order to support HELD dereferencing [ID-HELD-DEREF]. Clients can
	indicate which MIME types they support using the "Accept" header		indicate which MIME types they support using the "Accept" header
	field in SIP [RFC3261] or HTTP [RFC2616].		field in SIP [RFC3261] or HTTP [RFC2616].
	See RFC 3922 [RFC3922] for using the pres: URI with XMPP.		See RFC 3922 [RFC3922] for using the "pres:" URI with XMPP.
	It is RECOMMENDED that implementers follow Section 4.6 of RFC 6442		It is RECOMMENDED that implementers follow Section 4.6 of RFC 6442
	[RFC6442] as guidance regarding which Location URI schemes to		[RFC6442] as guidance regarding which Location URI schemes to
	provide in DHCP. That document discusses what a receiving entity		provide in DHCP. That document discusses what a receiving entity
	does when receiving a URI scheme that is not understood. Awareness		does when receiving a URI scheme that is not understood. Awareness
	to the two URI types there is important for conveying location, if		to the two URI types there is important for conveying location, if
	SIP is used to convey a Location URI provided by DHCP.		SIP is used to convey a Location URI provided by DHCP.
	4. IANA Considerations		4. IANA Considerations
	4.1 The IPv4 Option number for this Option		4.1 The IPv4 Option number for the Location URI Option
	This document IANA registers this IPv4 Option number XXX (to be
	assigned by IANA once this document becomes an RFC).
	4.2 The IPv6 Option-Code for this Option		This document IANA registers the Location URI IPv4 Option number XXX
			(to be assigned by IANA once this document becomes an RFC).
	This document IANA registers this IPv6 Option-Code XXX (to be		4.2 The IPv6 Option-Code for the Location URI Option
	assigned by IANA once this document becomes an RFC).
	4.3 IANA Considerations for LuriTypes		This document IANA registers the Location URI IPv6 Option-Code XXX
			(to be assigned by IANA once this document becomes an RFC).
	IANA is requested to create a new registry for acceptable location		4.3 The IPv4 Option number for the Valid-For Option
	types defined in Section 3.2 of this document, arranged similar to
	this:
	+------------+----------------------------------------+-----------+		This document IANA registers the Valid-For IPv4 Option number XXX
	| LuriType | Name | Reference |		(to be assigned by IANA once this document becomes an RFC).
	+------------+----------------------------------------+-----------+
	| 1 | Location URI | RFC XXXX* |
	| 2 | Valid-For | RFC XXXX* |
	+------------+----------------------------------------+-----------+
	* RFC XXXX is to be replaced with this document's RFC-Editor RFC		4.4 The IPv6 Option-Code for the Valid-For Option
	number.
	Additions to this registry require a standards track RFC.		This document IANA registers the Valid-For IPv6 Option-Code XXX (to
			be assigned by IANA once this document becomes an RFC).
	5. Security Considerations		5. Security Considerations
	Where critical decisions might be based on the value of this		Where critical decisions might be based on the value of this
	location URI option, DHCP authentication in [RFC3118] SHOULD be used		location URI option, DHCP authentication in [RFC3118] SHOULD be used
	to protect the integrity of the DHCP options.		to protect the integrity of the DHCP options.
	A real concern with RFC 3118 it is that not widely deployed because		A real concern with RFC 3118 is that it is not widely deployed
	it requires pre-shared keys to successfully work (i.e., in the		because it requires pre-shared keys to successfully work (i.e., in
	client and in the server). Most implementations do not		the client and in the server). Most implementations do not
	accommodate this.		accommodate this.
	DHCP, initially, is a broadcast request (a client looking for a		DHCP, initially, is a broadcast request (a client looking for a
	server), and a unicast response (answer from a server) type of		server), and a unicast response (answer from a server) type of
	protocol. It does not provide security at the network layer.		protocol. It does not provide security at the network layer.
	Instead, it relies on lower-layer security mechanisms.		Instead, it relies on lower-layer security mechanisms.
	Once a client has a URI, it needs information on how the location		Once a client has a Location URI, it needs information on how the
	server will control access to dereference requests. A client might		location server will control access to dereference requests. A
	treat a tightly access-controlled URI differently from one that can		client might treat a tightly access-controlled URI differently from
	be dereferenced by anyone on the Internet (i.e., one following the		one that can be dereferenced by anyone on the Internet (i.e., one
	"possession model"). With the LuriTypes defined in this document,		following the "possession model"). Since the client does not know
	the DHCP option for delivering location URIs can only tell the user		what policy will be applied during this validity interval, clients
	how long the URI will be valid. Since the client does not know what		MUST handle location URIs as if they could be dereferenced by
	policy will be applied during this validity interval, clients MUST		anybody until they expire. For example, such open location URIs
	handle location URIs as if they could be dereferenced by anybody		should only be transmitted in encrypted channels. Nonetheless,
	until they expire. For example, such open location URIs should only		location servers SHOULD apply appropriate access control policies,
	be transmitted in encrypted channels. Nonetheless, location servers		for example by limiting the number of queries that any given client
	SHOULD apply appropriate access control policies, for example by		can make, or limiting access to users within an enterprise.
	limiting the number of queries that any given client can make, or
	limiting access to users within an enterprise.
	Extensions to this option, such as [ID-POLICY-URI] can provide		Extensions to this option, such as [ID-POLICY-URI] can provide
	mechanisms for accessing and provisioning policy. Giving users		mechanisms for accessing and provisioning policy. Giving users
	access to policy information will allow them to make more informed		access to policy information will allow them to make more informed
	decisions about how to use their location URIs. Allowing users to		decisions about how to use their location URIs. Allowing users to
	provide policy information to the LS will enable them to tailor		provide policy information to the LS will enable them to tailor
	access control policies to their needs (within the bounds of policy		access control policies to their needs (within the bounds of policy
	that the LS will accept).		that the LS will accept).
	As to the concerns about the location URI itself, as stated in the		As to the concerns about the location URI itself, as stated in the
	document (see Section 3), it MUST NOT have any user identifying		document (see Section 3), it MUST NOT have any user identifying
	information in the URI user-part/string itself. The location URI		information in the URI user-part/string itself. The location URI
	also needs to be hard to guess that it belongs to a specific user.		also needs to be hard to guess that it belongs to a specific user.
	When implementing a DHCP server that will serve clients across an		In some cases a DHCP server may be implemented across an
	uncontrolled network, one should consider the potential security		uncontrolled network. In those cases, it would be appropriate for a
	risks therein.		network administrator to perform a threat analysis (see RFC 3552)
			and take precautions as needed.
	6. Acknowledgements		6. Acknowledgements
	Thanks to James Winterbottom, Marc Linsner, Roger Marshall and		Thanks to James Winterbottom, Marc Linsner, Roger Marshall and
	Robert Sparks for their useful comments. And to Lisa Dusseault for		Robert Sparks for their useful comments. And to Lisa Dusseault for
	her concerns about the types of URIs that can cause harm. To		her concerns about the types of URIs that can cause harm. To
	Richard Barnes for inspiring a more robust Security Considerations		Richard Barnes for inspiring a more robust Security Considerations
	section, and for offering the text to incorporate HTTP URIs. To		section, and for offering the text to incorporate HTTP URIs. To
	Hannes Tschofenig and Ted Hardie for riding me to comply with their		Hannes Tschofenig and Ted Hardie for riding me to comply with their
	concerns, including a good scrubbing of the nearly final doc.		concerns, including a good scrubbing of the nearly final doc.
	skipping to change at page 13, line 16		skipping to change at page 14, line 8
	(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration		(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
	Information ", RFC 4776, November 2006		Information ", RFC 4776, November 2006
	[RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of		[RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of
	'retransmission-allowed' for SIP Location Conveyance",		'retransmission-allowed' for SIP Location Conveyance",
	August 2009		August 2009
	[RFC5808] R. Marshall, "Requirements for a Location-by-Reference		[RFC5808] R. Marshall, "Requirements for a Location-by-Reference
	Mechanism", RFC 5808, May 2010		Mechanism", RFC 5808, May 2010
	[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M.		[RFC6753] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson,
	Thomson, M. Dawson, "A Location Dereferencing Protocol Using		M. Dawson, "A Location Dereferencing Protocol Using HELD",
	HELD", "work in progress", October 2011		"work in progress", October 2011
	[ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J.		[RFC6772] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J.
	Polk, "Geolocation Policy: A Document Format for Expressing		Polk, "Geolocation Policy: A Document Format for Expressing
	Privacy Preferences for Location Information", "work in		Privacy Preferences for Location Information", "work in
	progress", October 2011		progress", October 2011
	[ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location		[ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location
	Configuration Extensions for Policy Management", "work in		Configuration Extensions for Policy Management", "work in
	progress", November 2011		progress", November 2011
	Authors' Address		Authors' Address
End of changes. 58 change blocks.
	200 lines changed or deleted		246 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/