draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt   draft-ietf-geopriv-dhcp-lbyr-uri-option-04.txt 
Geopriv WG James Polk Geopriv WG James Polk
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track (PS) Nov 3, 2008 Intended status: Standards Track (PS) March 9, 2009
Expires: May 3, 2009 Expires: September 9, 2009
Dynamic Host Configuration Protocol (DHCP) Option for a Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6
Location Uniform Resource Identifier (URI) Option for a Location Uniform Resource Identifier (URI)
draft-ietf-geopriv-dhcp-lbyr-uri-option-03 draft-ietf-geopriv-dhcp-lbyr-uri-option-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with
applicable patent or other IPR claims of which he or she is aware the provisions of BCP 78 and BCP 79. This document may contain
have been or will be disclosed, and any of which he or she becomes material from IETF Documents or IETF Contributions published or made
aware will be disclosed, in accordance with Section 6 of BCP 79. publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an
adequate license from the person(s) controlling the copyright in
such materials, this document may not be modified outside the IETF
Standards Process, and derivative works of it may not be created
outside the IETF Standards Process, except to format it for
publication as an RFC or to translate it into languages other than
English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 3, 2009. This Internet-Draft will expire on September 9, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Legal
This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Abstract Abstract
This document creates a Dynamic Host Configuration Protocol (DHCP) This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for the downloading of a Uniform Resource Identifier (URI) Option for the downloading of a Uniform Resource Identifier (URI)
pointing to the geolocation record of an endpoint. This URI, called pointing to the geolocation record of an endpoint. This URI, called
a Location-by-Reference (LbyR), points to a record on a location a Location-by-Reference (LbyR), points to a record on a location
server which tracks the geolocation of the endpoint. Once server which tracks the geolocation of the endpoint. Once
downloaded by an endpoint, this LbyR can be forwarded to another downloaded by an endpoint, this LbyR can be forwarded to another
entity, to be dereferenced if this entity wants to learn the entity, to be dereferenced if this entity wants to learn the
geolocation of the sender endpoint. geolocation of the sender endpoint.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. DHC Location-URI Elements . . . . . . . . . . . . . . . . . . 4 2. Format of the DHCP LbyrElement Option . . . . . . . . . . . . 5
2.1. Elements of the Location Configuration Information . . 5 2.1. Overall Format of LbyrElement Option in IPv4 . . . . . 5
3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 5 2.2. Overall Format of LbyrElement Option in IPv6 . . . . . 6
3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 7 2.3. LbyrElement Format for both IPv4 and IPv6 . . . . . . . 6
3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 7 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 7
3.3 Valid Location-URI Schemes or Types . . . . . . . . . . 7 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12
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 the downloading of a Uniform Resource Identifier (URI) Option for the downloading of a Uniform Resource Identifier (URI)
pointing to the geolocation record of an endpoint. A client, for pointing to the geolocation record of an endpoint. A client, for
example, can be a Session Initiation Protocol (SIP) User Agent (UA) example, can be a Session Initiation Protocol (SIP) User Agent (UA)
[RFC3261] (i.e., a Phone). This URI, called a [RFC3261] (i.e., a Phone). This URI, called a
Location-by-Reference (LbyR), points to a record on a location Location-by-Reference (LbyR), points to a record on a location
server [ID-LBYR-REQ] which tracks the geolocation of the endpoint server [ID-LBYR-REQ] which tracks the geolocation of the endpoint
(through means not defined in this document). The LbyR record (through means not defined in this document). The LbyR record
stores the Geolocation of a Location Target. Once downloaded by an stores the Geolocation of a Location Target, where the location of
endpoint (the target in this case), this LbyR can be forwarded to the Location Target changing at the record, but not in the URI used
another entity, using SIP as defined in [ID-SIP-LOC], to be to access the record. Once downloaded by an endpoint (the target in
dereferenced if this second entity wants to learn the geolocation of this case), this LbyR can be forwarded to another entity, for
the Location Target. example, using SIP as defined in [ID-SIP-LOC], to be dereferenced if
this second entity wants to learn the geolocation of the Location
Target.
The act of dereferencing location is explained in [ID-SIP-CON], The act of dereferencing location is explained in [ID-SIP-LOC],
which demonstrates how a possessor of a LbyR subscribes to a which demonstrates how a Location Recipient of an LbyR subscribes to
Location Server to attain the location of the Target. If the a Location Server to attain the location of the Target. If the
dereferencer has permission, defined in [ID-GEO-POL], the location dereferencer has permission, defined in [ID-GEO-POL], the location
of the target will be returned to the Location Seeker. The Location of the target will be returned to the Location Seeker. The Location
Server will grant permission to location inquires based on the rules Server will grant permission to location inquires based on the rules
established by a Rule Holder [RFC3693]. Therefore, the Location established by a Rule Holder [RFC3693]. The Location Server has the
Server has the ability to challenge any location seeker's request, ability to challenge any Location Seeker's request, thereby
thus providing additive security properties to location revelation. providing additive security properties to location revelation.
Option.
Endpoints will require their geographic location for a growing Endpoints will require their geographic location for a growing
number of services. A popular use-case currently is for emergency number of services. A popular use-case currently is for emergency
services, in which SIP requires its location to be placed in a SIP services, in which SIP requires its location to be placed in a SIP
INVITE request [ID-SIP-LOC] towards a public safety answering point INVITE request [ID-SIP-LOC] towards a public safety answering point
(PSAP), i.e., an emergency response center. The reason for this is (PSAP), i.e., an emergency response center. The reason for this is
twofold: twofold:
o An emergency services SIP request must be routed/retargeted to the o An emergency services SIP request must be routed/retargeted to the
appropriate PSAP that is local to where the calling device is. appropriate PSAP that is local to where the calling device is.
skipping to change at page 3, line 30 skipping to change at page 4, line 6
There are other use-cases, such as calling the appropriate Pizza Hut There are other use-cases, such as calling the appropriate Pizza Hut
without having to look up in a directory which store is closest. A without having to look up in a directory which store is closest. A
UA knowing its location can call a main/national/international Pizza UA knowing its location can call a main/national/international Pizza
Hut number or address and let the UA's location tell Pizza Hut Hut number or address and let the UA's location tell Pizza Hut
enough information to have them route/retarget the SIP request to enough information to have them route/retarget the SIP request to
the appropriate store within the Pizza Hut organization to deliver the appropriate store within the Pizza Hut organization to deliver
the pizza to the caller's location. the pizza to the caller's location.
A problem exists within existing RFCs that provide location to the A problem exists within existing RFCs that provide location to the
UA ([RFC3825] and [RFC4776]) that type of location has to be updated UA ([RFC3825] and [RFC4776]), these types of DHCP Options for
every time a UA moves. Not all UAs will move frequently, but some geolocation requires an update of the entire location information
will. Refreshing location every time a UA moves does not scale in (LI)every time a UA moves. Not all UAs will move frequently, but
certain networks/environments, such as IP based cellular networks, some will. Refreshing location every time a UA moves does not scale
enterprise networks or service provider networks with mobile in certain networks/environments, such as IP based cellular
endpoints. An 802.11 based access network is one example of this. networks, enterprise networks or service provider networks with
Constantly updating location to endpoints might not scale in mobile mobile endpoints. An 802.11 based access network is one example of
(residential or enterprise or municipal) networks in which the UA is this. Constantly updating LI to the endpoints might not scale in
moving through more than one network attachment point, perhaps as a mobile (residential or enterprise or municipal) networks in which
person walks or drives with their UA down a neighborhood street or the UA is moving through more than one network attachment point,
apartment complex or a shopping center. perhaps as a person walks or drives with their UA down a
neighborhood street or apartment complex or a shopping center.
If the UA were provided a URI reference to retain and hand out when If the UA were provided a URI reference to retain and hand out when
it wants or needs to convey its location (in a protocol other than it wants or needs to convey its location (in a protocol other than
DHCP), a Location-URI reference that would not change as the UA's DHCP), a Location URI reference that would not change as the UA's
location changes, scaling issues would be significantly reduced. location changes, scaling issues would be significantly reduced to
This delivery of an indirect location has the added benefit of not needing an update of the URI only when a client changes
using up valuable or limited bandwidth to the UA with the constant administrative domains - which is much less often. This delivery of
updates. It also relieves the UA from having to determine when it an indirect location has the added benefit of not using up valuable
has moved far enough to consider asking for a refresh of its or limited bandwidth to the UA with the constant updates. It also
location. Many endpoints will not have this ability, so relying on relieves the UA from having to determine when it has moved far
it could prove fruitless. Once the UA has a Location-URI, a service enough to consider asking for a refresh of its location. Many
provider, however it Sights the Location Target, as described in RFC endpoints will not have this ability, so relying on it could prove
3693 [RFC3693], would merely update the actual location in the LIS fruitless. Once the UA has a Location URI, a service provider,
record, i.e., the URI the UA already points towards. This document however it Sights the Location Target, as described in RFC 3693
does not define how this update is done, as it will not be done with [RFC3693], would merely update the actual location in the LIS
record, i.e., the record the URI points towards. This document does
not define how this update is done, as it will not be done with
DHCP. DHCP.
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 a wall-jack (directly associated with a specific
Ethernet Switch port) will be associated with a known location via a Ethernet Switch port) will be associated with a known location via a
unique circuit-ID that's used by the RAIO Option defined in RFC 3046 unique circuit-ID that's used by the RAIO Option defined in RFC 3046
[RFC3046]. This assumes wall-jacks have an updated wiremap [RFC3046]. This assumes wall-jacks have an updated wiremap
database. RFC 3825 and RFC 4776 would return an LCI value of database. RFC 3825 and RFC 4776 would return an LCI value of
location. This document specifies how a Location-URI is returned by location. This document specifies how a Location URI is returned by
DHCP. Behind the DHCP server, in the backend of the network, via DHCP. Behind the DHCP server, in the backend of the network, via
the (logical entity of a) LIS has a PIDF-LO in each location record the (logical entity of a) LIS has a PIDF-LO in each location record
a URI points to. a Location URI points to.
If an 802.11 Access Port (AP) is at a specific known location within If an 802.11 Access Port (AP) is at a specific known location within
this enterprise network, all wireless Ethernet devices attaching to this enterprise network, all wireless Ethernet devices attaching to
the network through this AP would be given the same location in the network through this AP could be given the same location in
their respective location records because the DHCP server would know their respective location records because the DHCP server would know
each device was attaching from a known location, in this case, the each device was attaching from a known location, in this case, the
same location. This is assuming no 802.11 triangulation is same location. This is assuming no 802.11 triangulation is
occurring, this would give a more precise location to be placed in occurring, this would give a more precise location to be placed in
the location record (URI) of each device. the location record (URI) of each device.
If local configuration has the requirement of only assigning unique
Location URIs to each client, then unique LbyRs will be given out,
though they will all have the same location at the record, relieving
the backend Sighter from individually maintaining each location
independently.
This Option can be useful in WiMAX connected endpoints or IP This Option can be useful in WiMAX connected endpoints or IP
cellular endpoints. The Location-URI Option can be configured as a cellular endpoints. The Location URI Option can be configured as a
client if it is a router, such as a residential home gateway, with client if it is a router, such as a residential home gateway, with
the ability to communicate to downstream endpoints as a server. the ability to communicate to downstream endpoints as a server.
The means of challenge by any given LIS can vary, and a policy The means of challenge by any given LIS can vary, and a policy
established by a rulemaker [RFC3693] for a Location Target as to established by a rulemaker [RFC3693] for a Location Target as to
what type of challenge(s) are used, how strong a challenge is used what type of challenge(s) are used, how strong a challenge is used
or how precise the location information is given to a requestor. All or how precise the location information is given to a requestor. All
of this is outside the scope of this document (since this will not of this is outside the scope of this document (since this will not
be accomplished using DHCP). be accomplished using DHCP).
This document IANA registers the new DHC Option for a Location URI. This document IANA registers the new IPv4 and IPv6 DHC Options for a
Location URI.
2. DHC Location-URI Elements 2. Format of the DHCP LbyrElement Option
DHCP is a binary Protocol; URIs are alphanumeric (text) based. 2.1 Overall Format of LbyrElement Option in IPv4
There is one byte per URI character.
The Location-URI Option format is as follows: The LbyrElement 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 | Option Length | Valid-For | | Code XXX | Length=XX | Ver | Resv | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. LbyrElements... ...
. (see section 2.3 for details) ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location-URI |
Figure 1. IPv4 Fields for this LbyrElement Option
Code XXX: The code for this DHCPv4 option (IANA assigned).
Length=XX: The length of this option, counted in bytes - not
counting the Code and Length bytes. This is a variable
length Option, therefore the length value will change
based on the length of the LbyR within the Option.
Ver: (4 bits) The version of this Option. This will specify
version 1.
Resv: (4 bits) reserved for future use.
LbyrElement: see section 2.3 for details
2.2 Overall Format of LbyrElement Option in IPv6
The LbyrElement 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 | option-len |
\ .... /
/ .... \
\ .... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location-URI (cont'd) + | Ver | Resv | .
+---------------+ .
. LbyrElements... .
. (see section 2.3 for details) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1. Elements of the Location Configuration Information Figure 2. IPv6 fields of this LbyrElement Option
Code XXX: The code for this DHCP option. option-code: The code for this DHCPv6 option (IANA assigned).
Option Length: The length of this option variable. option-len: The length of this option, counted in bytes - not
counting the Code and Length bytes. This is a variable
length Option, therefore the length value will change
based on the shape within the Option.
Valid-For: The time, in seconds, this URI is to be considered Ver: See above (Section 2.1). This will specify version 1.
Valid for dereferencing.
Location-URI: The Location-by-Reference URI for the client Resv: See above (Section 2.1).
The <Valid-For> field indicates how long, in seconds, the client is LbyrElement: see below (Section 2.3 for details).
to consider this Location-URI valid before performing a refresh of
this Option, with a refreshed <Valid-For> value. A refresh MAY be
done merely at the normal DHCP refresh rate, or necessitated by this
timer, perhaps with the client just requesting this Option be
refreshed.
It is RECOMMENDED when the counter associated with this <valid-for> 2.3 LbyrElement Format for both IPv4 and IPv6
value has passed, the client perform a refresh of this Option. For
example, if 600 was the initial value of the <valid-for> field, when The LbyrElement, in both DHCPv4 and DHCPv6, have the following
300 seconds have passed, the Option SHOULD be refreshed. format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LbyrType | LbyrLength | LbyrValue ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. LbyrElement Format for both IPv4 and IPv6
LbyrType: A one-byte identifier of the data location value.
LbyrLength: The length, in bytes, of the LbyrValue, not including
the LbyrLength field itself, up to a maximum of 255
bytes.
LbyrValue: The LbyrElement value, as described in detail below.
The LbyrValue is always in UTP-8.
The LbyrTypes this document defines (and IANA registers) for a point
are:
LbyrType=1 Location-by-Reference URI - This is the URI pointing
at the location record where the PIDF-LO resides which
indicates the location of the Location Target.
LbyrType=2 Valid-For - The time, in seconds, this URI is to be
considered Valid for dereferencing. The timer
associated with this LbyrType starts upon receipt of
this Option.
The LbyrType=2 (Valid-For) indicates how long, in seconds, the
client is to consider this LbyrType=1 (Location-by-Reference URI)
valid before performing a refresh of this Option, with a refreshed
LbyrType=2 (Valid-For) value. A refresh MAY be done merely at the
normal DHCP refresh rate, or necessitated by this timer, perhaps
with the client only requesting this Option be refreshed.
It is RECOMMENDED when the counter associated with this LbyrType=2
(Valid-For) value has passed, the client perform a refresh of this
Option. For example, if 16000 was the initial value of the
LbyrType=2 (Valid-For) value, when 8000 seconds have passed, the
Option SHOULD be refreshed.
The LbyrType=2 (Valid-For) 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 LbyrType types
created MUST be done so through IANA registration with peer review
and an RFC.
3. DHC Option Operation 3. DHC Option Operation
The [RFC3046] RAIO MUST be utilized to provide the appropriate The [RFC3046] RAIO MUST 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. That said, this came from, in order to supply the correct response. That said, this
Option SHOULD NOT be in a DISCOVER message, because there is zero Option SHOULD NOT be in a DISCOVER message, because there is zero
knowledge by the client of which Server will answer. knowledge by the client of which Server will answer.
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.
It is RECOMMENDED to avoid building URIs, with any parameters, It is RECOMMENDED to avoid building URIs, with any parameters,
larger than what a single DHCP response can be. However, if a larger than what a single DHCP response can be. However, if a
message is larger than 255 bytes, concatenation is allowed, per RFC message is larger than 255 bytes, concatenation is allowed, per RFC
3396 [RFC3396]. 3396 [RFC3396].
Per [RFC2131], subsequent Location-URI Options, which are Per [RFC2131], subsequent LbyrElement Options, which are
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, Location URIs such as example, Location URIs such as
sips:34LKJH534663J54@example.com sips:34LKJH534663J54@example.com
should be done, providing no identity information, rather than a SHOULD be done, providing no identity information, rather than a
Location-URI such as this Location URI such as this
sips:aliceisinatlanta@example.com sips:aliceisinatlanta@example.com
This Option is for only communications between a DHCP client and a This Option is for only communications between a DHCP client and a
DHCP server. It can be solicited (requested) by the client, or it DHCP server. It can be solicited (requested) by the client, or it
can be pushed by the server without a request for it. DHCP Options can be pushed by the server without a request for it. DHCP Options
not understood are ignored. A DHCP server might or might not have not understood are ignored. A DHCP server might or might not have
the location of a client, therefore direct knowledge of a the location of a client, therefore direct knowledge of a
Location-URI within the server. If a server does not have a Location URI within the server. If a server does not have a
client's location, a communication path (or request) to a LIS would client's location, a communication path (or request) to a LIS would
be necessary. be necessary.
The LIS function, which is logical, is what creates the LbyR. The The LIS function, which is logical, is what creates the LbyR. The
coordination between the logical entity of a DHCP server and the coordination between the logical entity of a DHCP server and the
logical entity of a LIS as to which circuit-ID gets which logical entity of a LIS as to which circuit-ID gets which
Location-URI is not done via DHCP, therefore it is not defined Location URI is not done via DHCP, therefore it is not defined
here. Further, any location revelation rules and policies a user here. Further, any location revelation rules and policies a user
has regarding the treatment of their actual location, and who can has regarding the treatment of their actual location, and who can
access (what precision of) their location will be done with other access (what precision of) their location will be done with other
than DHCP, and likely will be done before anything other than than DHCP, and likely will be done before anything other than
default authentication and authorization permissions are used when a default authentication and authorization permissions are used when a
Location Seeker, as defined in RFC 3693, requests a for a Target's Location Seeker, as defined in RFC 3693, requests a for a Target's
location. location.
Differentiating clients is done via client identifiers. Therefore, Differentiating clients is done via client identifiers. Therefore,
in many implementations, each client can be assigned unique LbyRs, in many implementations, each client can be assigned unique LbyRs,
though this is not mandatory. though this is not mandatory.
Any dereferencing of a client's Location-URI would not involve DHCP Any dereferencing of a client's Location URI would not involve DHCP
either, but more likely by an application layer protocol such as either, but more likely by an application layer protocol such as
SIP, through a subscription to the Location-URI on the LIS. The LIS SIP, through a subscription to the Location URI on the LIS. The LIS
would also handle all authentication and authorization of location would also handle all authentication and authorization of location
requests, which is also not performed with DHCP, therefore not requests, which is also not performed with DHCP, therefore not
defined here. defined here.
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. This is not inconsistent with what's stated above. that residence. This is not inconsistent with what's stated above.
3.1 Architectural Assumptions 3.1 Architectural Assumptions
The following assumptions have been made for use of this URI Option The following assumptions have been made for use of this LbyrElement
for a client to learn it's Location-URI (in no particular order): Option for a client to learn its Location URI (in no particular
order):
o Any user control (what Geopriv calls a 'rulemaker') for the o Any user control (what Geopriv calls a 'rulemaker') for the
parameters and profile options a Location-Object will have is out parameters and profile options a Location-Object will have is out
of scope of this document, but assumed to take place via an of scope of this document, but assumed to take place via an
external web interface between the user and the LIS (direct or external web interface between the user and the LIS (direct or
indirect). indirect).
o Any user attempting to gain access to the information at this URI o Any user attempting to gain access to the information at this URI
will be challenged by the LIS, not the DHCP server for will be challenged by the LIS, not the DHCP server for
credentials and permissions. credentials and permissions.
skipping to change at page 7, line 44 skipping to change at page 9, line 42
o URIs received via this Option SHOULD NOT be sent to a o URIs received via this Option SHOULD NOT be 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 SHOULD NOT contain "data:" URLs, because they could o This Option SHOULD 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 Instead of listing all the types of URIs and URLs that can be
misused or potentially have harmful affects, Section 3.3 IANA misused or potentially have harmful affects, Section 3.3 IANA
registers acceptable Location-URI schemes (or types). registers acceptable Location URI schemes (or types).
3.3 Valid Location-URI Schemes or Types 3.3 Valid Location URI Schemes or Types
Therefore, this document specifies which URI types are acceptable as Therefore, this document specifies which URI types are acceptable as
a Location-URI scheme (or type): a Location URI scheme (or type):
1. sip: 1. sip:
2. sips: 2. sips:
3. pres: 3. pres:
These Location-URI types are IANA registered in section 4.2 of this These Location URI types are IANA registered in section 4.2 of this
document. document.
4. IANA Considerations 4. IANA Considerations
4.1 IANA Considerations for DHCP Option Numbering 4.1 The IPv4 Option number for this Option
IANA is requested to assigned a DHCP option code of XXX for the This document IANA registers this IPv4 Option number XXX (to be
Location-URI option, defined in Section 2.0 of this document. assigned by IANA once this document becomes an RFC).
Any additional Location-URI parameters to be defined for use via 4.2 The IPv6 Option-Code for this Option
this DHC Option MUST be done through a Standards Track RFC.
4.2 IANA Considerations for Acceptable Location-URI Types This document IANA registers this IPv6 Option-Code XXX (to be
assigned by IANA once this document becomes an RFC).
4.3 The Version number for this Option
This document IANA registers the version number 1 of this Option.
4.4 IANA Considerations for Acceptable Location URI Types
IANA is requested to create a new registry for acceptable Location IANA is requested to create a new registry for acceptable Location
URI types. URI types.
The following 3 URI types are registered by this document: The following 3 URI types are registered by this document:
1. sip: 1. sip:
2. sips: 2. sips:
3. pres: 3. pres:
Any additional Location-URI types to be defined for use via Any additional Location URI types to be defined for use via
this DHC Option MUST be done through a Standards Track RFC. this DHC Option need to be created and IANA registered with peer
review and 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 it is that not widely deployed because
it requires keys on both ends of a communication to work (i.e., in it requires keys on both ends of a communication to work (i.e., in
the client and in the server). Most implementations do not the client and in the server). Most implementations do not
accommodate this. accommodate this.
DHCP is a broadcast initially (a client looking for a server), DHCP is a broadcast initially (a client looking for a server),
unicast response (answer from a server) type of protocol. It is not unicast response (answer from a server) type of protocol. It is not
secure in a practical sense. In today's infrastructures, it will be secure in a practical sense. In today's infrastructures, it will be
primarily used over a wired, switched Ethernet network, requiring primarily used over a wired, switched Ethernet network, requiring
physical access to within a wire to gain access. Further, within an physical access to within a wire to gain access. Further, within an
802.11 wireless network, the 802.11 specs have layer 2 security 802.11 wireless network, the 802.11 specs have layer 2 security
mechanisms in place to help prevent a Location-URI from being mechanisms in place to help prevent a Location URI from being
learned by an unauthorized entity. learned by an unauthorized entity.
That said, having the Location-URI does not mean this unauthorized That said, having the Location URI does not mean this unauthorized
entity has the location of a client. The Location-URI still needs entity has the location of a client. The Location URI still needs
to be dereferenced to learn the location of the client. This to be dereferenced to learn the location of the client. This
dereferencing function, which is not done using DHCP, is done by dereferencing function, which is not done using DHCP, is done by
requesting the location record at a Location Information Server, or requesting the location record at a Location Information Server, or
LIS, which is a defined entity built to challenge each request it LIS, which is a defined entity built to challenge each request it
receives based on a joint policy of what is called a rulemaker. The receives based on a joint policy of what is called a rulemaker. The
rulemaker, as defined in RFC 3693, configures the authentication and rulemaker, as defined in RFC 3693, configures the authentication and
authorization policies for the location revelation of a Target. authorization policies for the location revelation of a Target.
This includes giving out more or less precise location information This includes giving out more or less precise location information
in an answer, therefore it can answer a bad-hat, but not allow it in an answer, therefore it can answer a bad-hat, but not allow it
from learning exactly where a user is. The rulemaker, which is a from learning exactly where a user is. The rulemaker, which is a
combination of the default rules set up by the location provider and combination of the default rules set up by the location provider and
those decided on by the user of the Target device. Likely, the those decided on by the user of the Target device. Likely, the
rules the user wants will not be allowed to go past some limits rules the user wants will not be allowed to go past some limits
established by the location provider, i.e., the administrator of the established by the location provider, i.e., the administrator of the
LIS, for various capability or security reasons. LIS, for various capability or security reasons.
Penetrating a LIS is supposed to be hard, and hopefully vendors that Penetrating a LIS is supposed to be hard, and hopefully vendors that
implement a LIS accomplish this goal. implement a LIS accomplish this goal.
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 here (in Section 3.), it must not have any user identifying document here (in Section 3.), it must not have any user identifying
information in the URI string itself. The Location-URI also must be information in the URI string itself. The Location URI also must be
hard to guess that it belongs to a specific user. There is some hard to guess that it belongs to a specific user. There is some
debate as to whether this Location-URI need be a random alphanumeric debate as to whether this Location URI need be a random alphanumeric
string or just unique. If the latter, there is some debate as to string or just unique. If the latter, there is some debate as to
the how we define unique. Is that through space as time, as RFC 3261 the how we define unique. Is that through space as time, as RFC 3261
defines a SIP Call-ID needs to be (meaning: never a duplicate, ever, defines a SIP Call-ID needs to be (meaning: never a duplicate, ever,
by any device, ever)? Or is it unique to within a specific domain by any device, ever)? Or is it unique to within a specific domain
for as long as it is actively assigned to a client (plus some for as long as it is actively assigned to a client (plus some
interval). interval).
When implementing a DHC server that will serve clients across an When implementing a DHC server that will serve clients across an
uncontrolled network, one should consider the potential security uncontrolled network, one should consider the potential security
risks therein. risks therein.
skipping to change at page 10, line 24 skipping to change at page 12, line 34
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 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
7.2. Informative References 7.2. Informative References
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in
draft-ietf-sip-location-conveyance-11.txt, "work in
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
(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
[ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-04.txt,
"work in progress", Nov 08
[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
[ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. [ID-GEO-POL] 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
Authors' Address Authors' Address
James Polk James Polk
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas 76034 Colleyville, Texas 76034
USA USA
EMail: jmpolk@cisco.com Email: jmpolk@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 59 change blocks. 
128 lines changed or deleted 242 lines changed or added

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