draft-ietf-geopriv-dhcp-lbyr-uri-option-02.txt   draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt 
Geopriv WG James Polk Geopriv WG James Polk
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: Dec 17, 2008 June 17, 2008 Intended status: Standards Track (PS) Nov 3, 2008
Intended status: Standards Track (PS) Expires: May 3, 2009
Dynamic Host Configuration Protocol (DHCP) Option for a Dynamic Host Configuration Protocol (DHCP) Option for a
Location Uniform Resource Identifier (URI) Location Uniform Resource Identifier (URI)
draft-ietf-geopriv-dhcp-lbyr-uri-option-02 draft-ietf-geopriv-dhcp-lbyr-uri-option-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 Dec 17, 2008. This Internet-Draft will expire on May 3, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document creates a Dynamic Host Configuration Protocol (DHCP) This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for the Location Uniform Resource Identifier (URI) of an Option for the downloading of a Uniform Resource Identifier (URI)
endpoint. For example, an endpoint can be a Session Initiation pointing to the geolocation record of an endpoint. This URI, called
Protocol (SIP) User Agent (i.e., a phone). This Location-URI can be a Location-by-Reference (LbyR), points to a record on a location
included in a UA's signaling messages to inform other nodes of that server which tracks the geolocation of the endpoint. Once
entity's geographic location, once the URI is dereferenced by a downloaded by an endpoint, this LbyR can be forwarded to another
Location Recipient. entity, to be dereferenced if this entity wants to learn the
geolocation of the sender endpoint.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DHC Location-URI Elements . . . . . . . . . . . . . . . . . . 4 2. DHC Location-URI Elements . . . . . . . . . . . . . . . . . . 4
2.1. Elements of the Location Configuration Information . . 5 2.1. Elements of the Location Configuration Information . . 5
3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 5 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 5
3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 7 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 7
3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 7 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 7
3.3 Valid Location-URI Schemes or Types . . . . . . . . . . 7 3.3 Valid Location-URI Schemes or Types . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . 11
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 delivery of a client's Location Uniform Resource Option for the downloading of a Uniform Resource Identifier (URI)
Identifier (URI). For example, a client can be a Session Initiation pointing to the geolocation record of an endpoint. A client, for
Protocol (SIP) User Agent (UA) [RFC3261] (i.e., a Phone). This example, can be a Session Initiation Protocol (SIP) User Agent (UA)
Location-URI can be included in a UA's signaling messages [RFC3261] (i.e., a Phone). This URI, called a
[ID-SIP-LOC] to inform remote devices (i.e., other phones or servers Location-by-Reference (LbyR), points to a record on a location
or applications) of that UA's geographic location. This is an server [ID-LBYR-REQ] which tracks the geolocation of the endpoint
indirect means of passing a Location Target's location to another (through means not defined in this document). The LbyR record
entity, called a dereference (of a URI). In other words, if an stores the Geolocation of a Location Target. Once downloaded by an
entity has the Location URI, it can access the location record at endpoint (the target in this case), this LbyR can be forwarded to
the server the URI points to, if the requestor has permission to another entity, using SIP as defined in [ID-SIP-LOC], to be
access it there. Where the location record is will likely be an dereferenced if this second entity wants to learn the geolocation of
entity called a Location Information Server (LIS) [ID-LBYR-REQ], the Location Target.
which stores the locations of many Location Targets, which has the
ability to challenge each dereference request by whatever means it
is capable of, thus providing additive security properties to
location revelation.
A Location Recipient is a device that has received location from The act of dereferencing location is explained in [ID-SIP-CON],
another entity. If this location is delivered by a URI, the URI has which demonstrates how a possessor of a LbyR subscribes to a
to be dereferenced by the Location Recipient to learn the remote Location Server to attain the location of the Target. If the
device's geographic location. Dereferencing can be done in SIP by dereferencer has permission, defined in [ID-GEO-POL], the location
use of the SUBSCRIBE/NOTIFY Methods [RFC3265] to either a sip:, of the target will be returned to the Location Seeker. The Location
sips: or pres: scheme URI. Each of these URI schemes are IANA Server will grant permission to location inquires based on the rules
registered in Section 5 of this document as valid for use by this established by a Rule Holder [RFC3693]. Therefore, the Location
Server has the ability to challenge any location seeker's request,
thus providing additive security properties to location revelation.
Option. 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
skipping to change at page 5, line 16 skipping to change at page 5, line 16
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 | Option Length | Valid-For |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location-URI | | Location-URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ .... \ / .... \
\ .... / \ .... /
/ .... \
\ .... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location-URI (cont'd) + | Location-URI (cont'd) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1. Elements of the Location Configuration Information 2.1. Elements of the Location Configuration Information
Code XXX: The code for this DHCP option. Code XXX: The code for this DHCP option.
Option Length: The length of this option variable. Option Length: The length of this option variable.
skipping to change at page 6, line 25 skipping to change at page 6, line 26
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 may be solicited (requested) by the client, or it DHCP server. It can be solicited (requested) by the client, or it
may 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 URI. 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,
in many implementations, each client can be assigned unique LbyRs,
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
skipping to change at page 10, line 22 skipping to change at page 10, line 25
[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",
draft-ietf-sip-location-conveyance-10.txt, "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-02.txt, Mechanism", draft-ietf-geopriv-lbyr-requirements-04.txt,
"work in progress", Feb 08 "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.
Polk, "Geolocation Policy: A Document Format for Expressing
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 Full Copyright Statement
 End of changes. 14 change blocks. 
40 lines changed or deleted 49 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/