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/