< draft-ietf-geopriv-dhcp-lbyr-uri-option-17.txt   draft-ietf-geopriv-dhcp-lbyr-uri-option-19.txt >
Network WG James Polk Network WG James Polk
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Proposed Standard Jan 28, 2013 Intended status: Proposed Standard Feb 25, 2013
Expires: June 28, 2013 Expires: Aug 25, 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-17 draft-ietf-geopriv-dhcp-lbyr-uri-option-19
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), and another Option to explicitly indicate how long Identifier (URI). This Location URI can then be dereferenced in a
that location URI is to be considered valid. This Location URI can separate transaction by the client or sent to another entity and
then be dereferenced in a separate transaction by the client or sent dereferenced to learn physically where the client is located, but
to another entity and dereferenced to learn physically where the only while valid.
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 June 28, 2013. This Internet-Draft will expire on August 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 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 and Valid-For Options . . . . 4 2. DHCP LocationURI Option Format and Rules .. . . . . . . . . . 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. Overall Format of Valid-For Option in IPv4 . . . . . . 5 2.3. Rules for both LocationURI and Valid-For Options . . . 6
2.4. Overall Format of Valid-For Option in IPv6 . . . . . . 6 3. DHCP Option Operation . . . . . . . . . . . . . . . . . . . . 7
2.5. Rules for both LocationURI and Valid-For Options . . . 6 4. Architectural Assumptions . . . . . . . . . . . . . . . . . . 8
3. DHCP Option Operation . . . . . . . . . . . . . . . . . . . . 8 4.1 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8
3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 9 4.2 Valid Location URI Schemes or Types . . . . . . . . . . . 9
3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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), and another Option to explicitly indicate how long Identifier (URI) [RFC3986]. In this scenario, the DHCP client is a
that location URI is to be considered valid. In this scenario, the Geopriv Target (i.e., the entity whose geolocation is associated
DHCP client is a Geopriv Target (i.e., the entity whose geolocation with the location URI). The DHCP implementation of the client can
is associated with the location URI). The DHCP implementation of the then make this location information available to other applications
client can then make this location information available to other for their usage. This location URI points to a Location Server
applications for their usage. This location URI points a Location [RFC5808] which has the geolocation of the client (e.g., previously
Server [RFC5808] which has the geolocation of the client (e.g., uploaded into a wiremap database then the client attaches to a known
uploaded into a wiremap database when the client attached wall-jack, wall-jack, or by means of 802.11 geolocation mechanisms).
or by means of 802.11 geolocation mechanisms).
Applications within the Target can then choose to deference this Applications within the Target can then choose to dereference this
location URI and/or transmit the URI to another entity as a means of location URI and/or transmit the URI to another entity as a means of
conveying where the Target is located. Both Conveying and conveying where the Target is located. Both Conveying and
Dereferencing a location URI is described in [RFC6442]. Session Dereferencing a location URI is described in [RFC6442]. Session
Initiation Protocol (SIP) is not the only protocol that can Initiation Protocol (SIP) [RFC3261] is not the only protocol that
dereference a location URI; there is also HTTP-Enabled Location can dereference a location URI; there is also HTTP-Enabled Location
Delivery (HELD) [RFC6753] and HTTP [RFC2616]. Delivery (HELD) [RFC6753] and HTTP [RFC2616].
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
[RFC6772], the location of the target will be received. The LS [RFC6772], the location of the target will be received. The LS
will grant permission to location inquiries 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
skipping to change at page 3, line 42 skipping to change at page 3, line 34
Information (LCI) to endpoints might not scale in mobile Information (LCI) to endpoints might not scale in mobile
(residential or enterprise or municipal) networks in which the (residential or enterprise or municipal) networks in which the
client is moving through more than one network attachment point, client is moving through more than one network attachment point,
perhaps as a person walks or drives with their client down a 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
skipping to change at page 4, line 39 skipping to change at page 4, line 30
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 and Valid-For. a location URI and Valid-For.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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 | Valid-For .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..... LocationURI... ..... ..... Valid-For (Cont'd) | LocationURI... .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..... | ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Valid-For: The time, in seconds, the LocationURI is to be
considered valid for dereferencing. The Valid-For is
always represented as a four-byte unsigned integer.
LocationURI: Location URI - This field, in bytes, is the URI LocationURI: Location URI - This field, in bytes, is the URI
pointing at the location record where the PIDF-LO for pointing at the location record where the PIDF-LO for
the Location Target resides. The LocationURI is always the Location Target resides. The LocationURI is always
represented in ASCII. 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... ..... | Valid-For |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LocationURI... .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..... | ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 option-code and option-len bytes. This is counting the option-code and option-len bytes. This is
a variable length Option, therefore the length value a variable length Option, therefore the length value
will change based on the length of the URI within the will change based on the length of the URI within the
Option. Option.
LocationURI: see Section 2.1 Valid-For: see Section 2.1
2.3 Overall Format of Valid-For Option in IPv4
The Valid-For Option format for IPv4 is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code XXX | Valid-For .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..... |
+-+-+-+-+-+-+-+-+
Figure 1. IPv4 Fields for this Valid-For Option
Code XXX: The code for this DHCPv4 option (IANA assigned).
Valid-For: Valid-For - The time, in seconds, the LocationURI -
received in the same DHCP message - is to be
considered valid for dereferencing. The Valid-For is
always represented as a four-byte unsigned integer.
2.4 Overall Format of Valid-For Option in IPv6
The Valid-For Option format for IPv6 is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | Valid-For .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..... Valid-For (Cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. IPv6 fields of this Valid-For Option
option-code: The code for this DHCPv6 option (IANA assigned).
Valid-For: see Section 2.3
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 LocationURI: see Section 2.1
server and client, per this specification.
o Implementation of the Valid-For Option is OPTIONAL on the DHCP 2.3 Rules for the LocationURI Option
server and client, per this specification.
o The Location URI Option MUST be sent from a server, and received The LocationURI Option has the following rules:
by a client with or without an accompanying Valid-For Option.
The Valid-For Option offers no meaningful information to a client o Implementation of the Location URI Option is REQUIRED on the DHCP
without an accompanying Location URI Option, and might be server and client.
misunderstood or misapplied, therefore
o The Valid-For Option MUST NOT be sent from a server, and received o Clients SHOULD be expected to have to request the Location URI
by a client, without an accompanying Location URI Option. Option from servers. Although local policy can have servers
perform an unsolicited push of a Location URI Option to a client.
o A client receiving a Valid-For Option without a Location URI Applications on a client can use the Location URI (value) until the
Option MUST ignore the Valid-For Option. Valid-For value reaches zero. If there is no Valid-For Option value,
then the counter did not ever start (a null value), and applications
on a client continue to use the Location URI value until given a new
Location URI Option (with or without a Valid-For value) which
overwrites any previous Location URI and Valid-For Option values.
o The Valid-For Option MUST only be considered in relation to the o A Location URI Option with a non-zero Valid-For field MUST NOT
Location URI Option. It has no other purpose in DHCP then in transmit the Location URI once the Valid-For field counts down to
relation to the Location URI (i.e., there is no other Option in zero.
DHCP to which it has meaning).
o The Valid-For Option MUST NOT cause any error in handling the o A received Location URI Option containing all zeros in the
Location URI, i.e., if not understood, it MUST be ignored. Valid-For field means that Location URI has no lifetime, and not
"no lifetime left". All zeros in the Valid-For field equates to a
null value.
o Servers MUST assume that clients will overwrite any existing, o Receipt of the Location URI Option containing all zeros in the
previously sent values of Location URI Option and/or Valid-For Valid-For field MUST NOT cause any error in handling the Location
Option. URI.
o Clients MUST overwrite any existing, previously sent values of o When the Valid-For timer reaches zero, the client MUST purge any
Location URI Option and/or Valid-For Option when receiving the location URI received via DHCP from its memory.
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 o Clients receiving a Location URI Option start the Valid-For timer
the Valid-For timer upon receipt of the DHCP message containing upon receipt of the DHCP message containing the Option.
both Options.
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
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
DHCP state machine.
o Clients MUST NOT trigger an automatic DHCP refresh on expiry of o Clients MUST NOT trigger an automatic DHCP refresh on expiry of
the Valid-For timer; rather, they SHOULD follow normal DHCP the Valid-For timer; rather, they MUST follow normal DHCP
mechanics. mechanics.
Server operators should consider the relation between the Valid-For If the Valid-For timer is set to expire before the lease refresh,
time and the lease time. Clients typically request a lease refresh the client will not have the ability to hand out its location until
when half the lease time is up. If the Valid-For time is less than the lease refresh, inadvertently allowing a gap of coverage. If the
the typical refresh rate (i.e., half the lease time), then for the Valid-For timer is set to expire after the lease refresh, some
remaining interval, clients will run the risk of not having a usable wayward application on the client can divulge that location URI
location URI for applications. If the Valid-For time is less than after it is no longer valid, meaning the location could be stale or
half the typical refresh rate, it is a near certainty clients will just plain wrong.
not have a usable location URI for the interval between the
Valid-For time and the typical refresh time for applications. For o Servers SHOULD set the Valid-For timer to that of the lease
example, if a lease is set to 24 hours, the typical refresh request refresh, or bad things can happen.
is set to initiate at the 12 hour mark. If the Valid-For timer is
set to less than 24 hours, but more than 12 hours (in this example),
the client might not be refreshed at the 12 hour mark and runs the
risk of not have a location URI for applications that request it.
If, on the other hand, the Valid-For timer is less than 12 hours (in
this example, which is before a typical client would ask for a
refresh, applications will be without a usable location URI until
the full refresh has been received.
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. DHCP messages are limited in size, and long
URIs will require the use of multiple messages and concatenation
It is RECOMMENDED to avoid building URIs, with any parameters, [RFC3396]. It is, therefore, best to limit the total length of a
larger than what a single DHCP response can be. However, if a URI, including any parameters, to 220 bytes.
message is larger than 255 bytes, concatenation is allowed, per RFC
3396 [RFC3396].
Per [RFC2131], subsequent LocationURI Options, which are
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:aliceisat123mainstatlantageorgiaus@example.com sips:aliceisat123mainstatlantageorgiaus@example.com
skipping to change at page 9, line 20 skipping to change at page 8, line 5
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
server-to-LS transaction could delay the DHCP messaging to the server-to-LS transaction could delay the DHCP messaging to the
client. If the server fails to have location before it transmits its client. If the server fails to have location before it transmits its
message to the client, location will not be part of that DHCP message to the client, location will not be part of that DHCP
message. Any timers involved here are a matter of local message. Any timers involved here are a matter of local
configuration. configuration.
The deference of a target's location URI would not involve DHCP, but The dereference of a target's location URI would not involve DHCP,
an application layer protocol, such as SIP or HTTP, therefore but an application layer protocol, such as SIP or HTTP, therefore
dereferencing is out of scope of this document. dereferencing is out of scope of this document.
In the case of residential gateways being DHCP servers, they usually In the case of residential gateways being DHCP servers, they usually
perform as DHCP clients in a hierarchical fashion up into a service perform as DHCP clients in a hierarchical fashion up into a service
provider's network DHCP server(s), or learn what information to provider's network DHCP server(s), or learn what information to
provide via DHCP to residential clients through a protocol, such as provide via DHCP to residential clients through a protocol, such as
PPP. In these cases, the location URI would likely indicate the PPP. In these cases, the location URI would likely indicate the
residence's civic address to all wired or wireless clients within residence's civic address to all wired or wireless clients within
that residence. that residence.
3.1 Architectural Assumptions 4. Architectural Assumptions
The following assumptions have been made for use of this LocationURI The following assumptions are made once the client has obtained a
Option for a client to learn its location URI (in no particular location URI, and not about DHCP operation specifics (in no
order): particular 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 [RFC6772]. document. An example authorization policy is in [RFC6772].
o The authorization security model vs. possession security model o The authorization security model vs. possession security model
discussion can be found in [RFC5606], describing what is expected discussion can be found in [RFC5606], describing what is expected
in each model of operation. It should be assumed that a location in each model of operation. It should be assumed that a location
URI attained using DHCP will operate under an possession model by URI attained using DHCP will operate under a possession model by
default. An authorization model can be instituted as a matter of default. An authorization model can be instituted as a matter of
local policy. An authorization model means possessing the local policy. An authorization model means possessing the
location URI does not give that entity the right to view the location URI does not give that entity the right to view the
PIDF-LO of the target whose location is indicated in a presence PIDF-LO of the target whose location is indicated in a presence
document. The dereference transaction will be challenged by the document. The dereference transaction will be challenged by the
Location Server only in an authorization model. The nature of Location Server only in an authorization model. The nature of
this challenge is out of scope of this document. this challenge is 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 4.1 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 SHOULD NOT be automatically sent to
general-browser to connect to a web page, because they could have a general-browser to connect to a web page, because they could
harmful scripts. have harmful scripts, unless
o the browser has been set up to defend against harmful scripts,
o This Option MUST NOT contain "data:" URLs, because they could or
contain harmful scripts.
o Section 3.3 IANA registers acceptable location URI schemes (or o the browser does not run scripts automatically.
types) for use by this specification. Clients MUST reject URI
schemes not currently registered in IANA.
3.3 Valid Location URI Schemes or Types o This Option MUST NOT contain "data:" URLs [RFC2397], because they
could contain harmful scripts.
This section specifies which URI types are acceptable as a location 4.2 Valid Location URI Schemes or Types
URI scheme (or type) for this DHCP Option:
URIs carried by this DHCP Option MUST have one of the following URI
schemes:
1. sip: 1. sip:
2. sips: 2. sips:
3. pres: 3. pres:
4. http: 4. http:
5. https: 5. https:
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 media type 'application/pidf+xml'[RFC4119]. Alternatively, HTTP and
URIs MAY refer to information with MIME type 'application/held+xml', HTTPS URIs MAY refer to information with media type
in order to support HELD dereferencing [RFC6753]. Clients can 'application/held+xml', in order to support HELD dereferencing
indicate which MIME types they support using the "Accept" header [RFC6753]. Clients can indicate which media types they support
field in SIP [RFC3261] or HTTP [RFC2616]. using the "Accept" header 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 5. IANA Considerations
4.1 The IPv4 Option number for the Location URI Option 5.1 The IPv4 Option number for the Location URI Option
This document IANA registers the Location URI IPv4 Option number XXX This document IANA registers the DHCP Location URI Option Number in
(to be assigned by IANA once this document becomes an RFC). the BOOTP Vendor Extensions and DHCP Options subregistry of the
Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol
(BOOTP) Parameters registry located.
4.2 The IPv6 Option-Code for the Location URI Option Data
Tag Name Length Meaning Reference
---- ---- ------ ------- ---------
XXX LocationURI N GeoLocation URI [this document]
This document IANA registers the Location URI IPv6 Option-Code XXX The authors have no preference at this time on what number IANA
(to be assigned by IANA once this document becomes an RFC). chooses.
4.3 The IPv4 Option number for the Valid-For Option 5.2 The IPv6 Option-Code for the Location URI Option
This document IANA registers the Valid-For IPv4 Option number XXX This document IANA registers the DHCPv6 Option Code in the DHCP
(to be assigned by IANA once this document becomes an RFC). Option Codes subregistry of the Dynamic Host Configuration Protocol
for IPv6 (DHCPv6) registry.
4.4 The IPv6 Option-Code for the Valid-For Option Value Description Reference
---- ------------------ ----------
XX OPTION_GEOLOCATION_URI [this document]
This document IANA registers the Valid-For IPv6 Option-Code XXX (to The authors have no preference at this time on what number IANA
be assigned by IANA once this document becomes an RFC). chooses.
5. Security Considerations 5.3 Valid Location URI Schemes
This document creates a new IANA registry (Valid Location URI
Schemes) of acceptable location URI schemes (or types) for this DHCP
Location URI Option of the Dynamic Host Configuration Protocol
(DHCP) and Bootstrap Protocol (BOOTP) Parameters registry.
Initial values are given below; new assignments are to be made
following the "IETF Review" policies [RFC5226].
"Valid Location URI Schemes"
Location
URI Scheme Reference
---------- ---------
sip: [this document]
sips: [this document]
pres: [this document]
http: [this document]
https: [this document]
6. 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 as defined in
"Authentication for DHCP Messages" [RFC3118] and "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)" [RFC3315] 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 is that it is not widely deployed A real concern with RFC 3118 or RFC 3315 is that neither is widely
because it requires pre-shared keys to successfully work (i.e., in deployed because each requires pre-shared keys to successfully work
the client and in the server). Most implementations do not (i.e., in the client and in the server). Most implementations do
accommodate this. not 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. There is no privacy protection for DHCP messages, an
Instead, it relies on lower-layer security mechanisms. eavesdropper who can monitor the link between the DHCP server and
requesting client can discover the Location URI.
Once a client has a Location URI, it needs information on how the Once a client has a Location URI, it needs information on how the
location server will control access to dereference requests. A location server will control access to dereference requests. A
client might treat a tightly access-controlled URI differently from client might treat a tightly access-controlled URI differently from
one that can be dereferenced by anyone on the Internet (i.e., one one that can be dereferenced by anyone on the Internet (i.e., one
following the "possession model"). Since the client does not know following the "possession model"). Since the client does not know
what policy will be applied during this validity interval, clients what policy will be applied during this validity interval, clients
MUST handle location URIs as if they could be dereferenced by MUST handle location URIs as if they could be dereferenced by
anybody until they expire. For example, such open location URIs anybody until they expire. For example, such open location URIs
should only be transmitted in encrypted channels. Nonetheless, should only be transmitted in encrypted channels. Nonetheless,
skipping to change at page 12, line 25 skipping to change at page 11, line 47
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.
In some cases a DHCP server may be implemented across an In some cases a DHCP server may be implemented across an
uncontrolled network. In those cases, it would be appropriate for a uncontrolled network. In those cases, it would be appropriate for a
network administrator to perform a threat analysis (see RFC 3552) network administrator to perform a threat analysis (see RFC 3552)
and take precautions as needed. and take precautions as needed.
6. Acknowledgements Link-layer confidentiality and integrity protection may also be
employed to reduce the risk of location disclosure and tampering.
7. 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.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002. Session Initiation Protocol", RFC 3261, May 2002.
[RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic
Host Configuration Protocol (DHCPv4)", RFC 3396, November Host Configuration Protocol (DHCPv4)", RFC 3396, November
2002 2002
[RFC3856] J. Rosenberg, "A Presence Event Package for the Session [RFC3856] J. Rosenberg, "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004 Initiation Protocol (SIP)", RFC 3856, August 2004
[RFC3922] P. Saint-Andre, " Mapping the Extensible Messaging and [RFC3922] P. Saint-Andre, " Mapping the Extensible Messaging and
Presence Protocol (XMPP) to Common Presence and Instant Presence Protocol (XMPP) to Common Presence and Instant
Messaging (CPIM)", RFC 3922, October 2004 Messaging (CPIM)", RFC 3922, October 2004
[RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifier (URI): Generic Syntax", RFC 3986, January 2005
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005 Format", RFC 4119, December 2005
[RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", RFC 6442, December for the Session Initiation Protocol", RFC 6442, December
2011. 2011.
7.2. Informative References [RFC6753] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson,
M. Dawson, "A Location Dereferencing Protocol Using HELD",
October 2012
8.2. Informative References
[RFC2397] L. Masinter, "The "data" URL scheme", RFC 2397, August 1998
[RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L.,
Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer
Protocol - HTTP/1.1", RFC 2616, June 1999 Protocol - HTTP/1.1", RFC 2616, June 1999
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004 "Geopriv Requirements", RFC 3693, February 2004
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba,
"Dynamic Host Configuration Protocol Options for "Dynamic Host Configuration Protocol Options for
skipping to change at page 13, line 48 skipping to change at page 13, line 38
(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
[RFC6753] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson,
M. Dawson, "A Location Dereferencing Protocol Using HELD",
"work in progress", October 2011
[RFC6772] 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", January 2013
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
James Polk James Polk
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas 76034 Colleyville, Texas 76034
 End of changes. 64 change blocks. 
211 lines changed or deleted 195 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/