draft-ietf-geopriv-rfc3825bis-11.txt   draft-ietf-geopriv-rfc3825bis-12.txt 
GEOPRIV Working Group J. Polk GEOPRIV Working Group J. Polk
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Obsoletes: 3825 (if approved) J. Schnizlein Obsoletes: 3825 (if approved) J. Schnizlein
Category: Standards Track Individual Contributor Category: Standards Track Individual Contributor
Expires: January 5, 2011 M. Linsner Expires: March 12, 2011 M. Linsner
5 July 2010 Cisco Systems 5 September 2010 Cisco Systems
M. Thomson M. Thomson
Andrew Andrew
B. Aboba (ed) B. Aboba (ed)
Microsoft Corporation Microsoft Corporation
Dynamic Host Configuration Protocol Options for Dynamic Host Configuration Protocol Options for
Coordinate-based Location Configuration Information Coordinate-based Location Configuration Information
draft-ietf-geopriv-rfc3825bis-11.txt draft-ietf-geopriv-rfc3825bis-12.txt
Abstract Abstract
This document specifies Dynamic Host Configuration Protocol Options This document specifies Dynamic Host Configuration Protocol Options
(both DHCPv4 and DHCPv6) for the coordinate-based geographic location (both DHCPv4 and DHCPv6) for the coordinate-based geographic location
of the client. The Location Configuration Information (LCI) includes of the client. The Location Configuration Information (LCI) includes
Latitude, Longitude, and Altitude, with resolution or uncertainty Latitude, Longitude, and Altitude, with resolution or uncertainty
indicators for each. Separate parameters indicate the reference indicators for each. Separate parameters indicate the reference
datum for each of these values. datum for each of these values.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 January 5, 2011. This Internet-Draft will expire on March 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Resolution and Uncertainty . . . . . . . . . . . . . . . 5 1.2 Resolution and Uncertainty . . . . . . . . . . . . . . . 5
2. DHCP Option Format . . . . . . . . . . . . . . . . . . . . . . 5 2. DHCP Option Format . . . . . . . . . . . . . . . . . . . . . . 6
2.1 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . 6 2.1 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . 6
2.2 DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 7 2.2 DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 7
2.3 Latitude and Longitude Fields . . . . . . . . . . . . . 9 2.3 Latitude and Longitude Fields . . . . . . . . . . . . . 10
2.4 Altitude . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4 Altitude . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Datum . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5 Datum . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 15 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 15
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . 16
6.2. Informational References . . . . . . . . . . . . . . . . 17 6.2. Informational References . . . . . . . . . . . . . . . . 17
Appendix A. GML Mapping . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. GML Mapping . . . . . . . . . . . . . . . . . . . . . 19
A.1. GML Templates . . . . . . . . . . . . . . . . . . . . . 18 A.1. GML Templates . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Calculations of Resolution . . . . . . . . . . . . . . 21 Appendix B. Calculations of Resolution . . . . . . . . . . . . . . 22
B.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 21 B.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 22
B.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 24 B.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 25
Appendix C. Calculations of Uncertainty . . . . . . . . . . . . . 25 Appendix C. Calculations of Uncertainty . . . . . . . . . . . . . 26
C.1 LCI of "Sydney Opera House" (Example 3) . . . . . . . . 25 C.1 LCI of "Sydney Opera House" (Example 3) . . . . . . . . 26
Appendix D. Changes from RFC 3825 . . . . . . . . . . . . . . . . 29 Appendix D. Changes from RFC 3825 . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The physical location of a network device has a range of The physical location of a network device has a range of
applications. In particular, emergency telephony applications rely applications. In particular, emergency telephony applications rely
on knowing the location of a caller in order to determine the correct on knowing the location of a caller in order to determine the correct
emergency center. emergency center.
The location of a device can be represented either in terms of The location of a device can be represented either in terms of
geospatial (or geodetic) coordinates, or as a civic address. geospatial (or geodetic) coordinates, or as a civic address.
skipping to change at page 4, line 36 skipping to change at page 4, line 36
civic address options defined in RFC 4776 [RFC4776] enable a DHCP civic address options defined in RFC 4776 [RFC4776] enable a DHCP
client to obtain its location. For example, a wired Ethernet host client to obtain its location. For example, a wired Ethernet host
might use these options for location determination. In this case, might use these options for location determination. In this case,
the location information could be derived from a wiremap by the DHCP the location information could be derived from a wiremap by the DHCP
server, using the Circuit-ID Relay Agent Information Option (RAIO) server, using the Circuit-ID Relay Agent Information Option (RAIO)
defined (as Sub-Option 1) in RFC 3046 [RFC3046]. The DHCP server defined (as Sub-Option 1) in RFC 3046 [RFC3046]. The DHCP server
could correlate the Circuit-ID with the geographic location where the could correlate the Circuit-ID with the geographic location where the
identified circuit terminates (such as the location of the wall identified circuit terminates (such as the location of the wall
jack). jack).
The options defined in this document have limited applicability for The mechanism defined here may also be utilized to provide location
mobile hosts. Typically DHCP clients refresh their configuration in to wireless hosts. DHCP relay agent sub-options (RAIO) [RFC3046] is
response to changes in interface state or pending lease expirations. one method a DHCP server might use to perform host location
As a result, when a mobile host changes location without subsequently determination. Currently, the relay agent sub-options do not include
completing another DHCP exchange, location configuration information data sets required for device level location determination of
initially obtained via DHCP could become outdated. wireless hosts. In cases where the DHC server uses RAIO for location
determination, a wireless host can use this mechanism to discover
location of the radio access point, or the area of coverage for the
radio access point.
An important feature of this specification is that after the relevant An important feature of this specification is that after the relevant
DHCP exchanges have taken place, the location information is stored DHCP exchanges have taken place, the location information is stored
on the end device rather than somewhere else, where retrieving it on the end device rather than somewhere else, where retrieving it
might be difficult in practice. might be difficult in practice.
1.1. Conventions used in this document 1.1. Conventions used in this document
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
skipping to change at page 15, line 16 skipping to change at page 15, line 21
within North America. within North America.
NAD83 is identified by the EPSG/OGP code of 4269, or the URN NAD83 is identified by the EPSG/OGP code of 4269, or the URN
"urn:ogc:def:crs:EPSG::4269". MLLW does not have a specific code "urn:ogc:def:crs:EPSG::4269". MLLW does not have a specific code
or URN. or URN.
All hosts MUST support the WGS84 datum (Datum 1). All hosts MUST support the WGS84 datum (Datum 1).
3. Security Considerations 3. Security Considerations
Where critical decisions might be based on the value of this option, Geopriv requirements (including security requirements) are discussed
DHCP authentication as defined in "Authentication for DHCP Messages" in "Geopriv Requirements" [RFC3693]. A threat analysis is provided
[RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" in "Threat Analysis of the Geopriv Protocol" [RFC3694].
[RFC3315] SHOULD be used to protect the integrity of the DHCP
options.
Since there is no privacy protection for DHCP messages, an Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the DHCP server and eavesdropper who can monitor the link between the DHCP server and
requesting client can discover this LCI. requesting client can discover this LCI.
To minimize the unintended exposure of location information, the LCI To minimize the unintended exposure of location information, the LCI
option SHOULD be returned by DHCP servers only when the DHCP client option SHOULD be returned by DHCP servers only when the DHCP client
has included this option in its 'parameter request list' (section 3.5 has included this option in its 'parameter request list' (section 3.5
[RFC2131]). Link layer confidentiality may also be employed to [RFC2131]).
reduce the risk of location disclosure.
Where critical decisions might be based on the value of this 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.
Link layer confidentiality and integrity protection may also be
employed to reduce the risk of location disclosure and tampering.
4. IANA Considerations 4. IANA Considerations
IANA has assigned a DHCPv4 option code of 123 for the GeoConf option IANA has assigned a DHCPv4 option code of 123 for the GeoConf option
defined in this document. Assignment of a DHCPv6 option code is defined in this document. Assignment of a DHCPv6 option code is
requested. requested.
The GeoConf Option defines two fields for which IANA maintains a The GeoConf Option defines two fields for which IANA maintains a
registry: The Altitude Type (AT) field and the Datum field (see registry: The Altitude Type (AT) field and the Datum field (see
Section 2). The datum indicator MUST include specification of both Section 2). The datum indicator MUST include specification of both
skipping to change at page 17, line 34 skipping to change at page 17, line 46
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications Amendment 3: 3650-3700 MHz Layer (PHY) specifications Amendment 3: 3650-3700 MHz
Operation in USA, November 2008. Operation in USA, November 2008.
[NENA] National Emergency Number Association (NENA) www.nena.org [NENA] National Emergency Number Association (NENA) www.nena.org
NENA Technical Information Document on Model Legislation NENA Technical Information Document on Model Legislation
Enhanced 911 for Multi-Line Telephone Systems. Enhanced 911 for Multi-Line Telephone Systems.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson,
"Threat Analysis of the Geopriv Protocol", RFC 3694,
February 2004.
[RFC3825] Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host [RFC3825] Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004. Location Configuration Information", RFC 3825, July 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
skipping to change at page 29, line 7 skipping to change at page 30, line 7
</gs:Prism> </gs:Prism>
Note that this representation is only appropriate if the uncertainty Note that this representation is only appropriate if the uncertainty
is sufficiently small. [GeoShape] recommends that distances between is sufficiently small. [GeoShape] recommends that distances between
polygon vertices be kept short. A GML representation like this one polygon vertices be kept short. A GML representation like this one
is only appropriate where uncertainty is less than 1 degree (an is only appropriate where uncertainty is less than 1 degree (an
encoded value of 9 or greater). encoded value of 9 or greater).
Appendix D. Changes from RFC 3825 Appendix D. Changes from RFC 3825
Technical changes: This section lists the major changes between [RFC3825] and this
document. Minor changes, including style, grammar, spelling and
-10: Clarified requirements for normalization of the editorial changes are not mentioned here.
the Latitude and Longitude fields. Clarified requirements
for version support in clients and servers.
-09: Updated and shortened Appendix B.1.
-08: Added Appendix A on GML mapping.
-06: Added recommendation on link layer confidentiality to the
Security Considerations section.
-05: Added version field to DHCPv6 option.
-04: Added Appendix C providing an example relating to
uncertainty. Added Section 2.3.1 on Latitude and Longitude
resolution and Section 2.4.4 on Altitude resolution.
Added definition of Resolution to Section 1.2.
-03: Clarified potential behavior of version 0 clients receiving
a version 1 option and added recommendations for clients and
servers.
-02: Added Section 1.2 introducing uncertainty and resolution
concepts. Added Section 2.1 defining DHCPv6 option format.
-01: Within Section 2.1, split Datum field from RFC 3825 into three
fields: Ver, Res and Datum fields. Explained that the Ver
field is always located at the same offset. Added Section 2.2
relating to Version Support.
-00: None
Editorial changes:
-11: Fixed typos. o Section 1 now includes clarifications on wired and wireless uses.
-10: Consolidated material relating to parameter allocation into o The former Sections 1.2 and 1.3 have been removed. Section 1.2
the IANA Considerations section. now defines the concepts of uncertainty and resolution.
-07: Updated boilerplate, cleaned up security considerations section. o A DHCPv6 option is now defined (Section 2.1) as well
-06: Added corrections to Section 1.2 "Resolution and Uncertainty". as a DHCPv4 option (Section 2.2).
Added the DHCPv6 Option Version field to the IANA o The former Datum field has been split into three fields:
Considerations section. Ver, Res and Datum. These fields are used in both the
-05: Corrected length of DHCPv6 option. Added Key to uncertainty DHCPv4 and DHCPv6 options.
figure. o Section 2.2.1 has been added, describing Version support.
-04: Changed all uses of the LoRes/LaRes/AltRes terminology to o Section 2.3 has been added, describing the Latitude and
LongUnc/LatUnc/AltUnc, and clarified when these parameters Longitude fields.
were used to encode resolution vs. uncertainty. Re-organized o Section 2.3.1 has been added, covering Latitude and Longitude
Section 1.2. Added references to RFC 4119, RFC 5139 and resolution.
[GeoShape]. o Section 2.3.2 has been added, covering Latitude and Longitude
-03: Changed "DHC" to "DHCP" in some usages. Clarified relationship uncertainty.
of resolution and uncertainty to privacy. o Section 2.4 has been added, covering values of the Altitude
-02: Re-organized Sections 1 and 2. field (Sections 2.4.1, 2.4.2 and 2.4.3), Altitude resolution
-01: Added references to IEEE 802.11y, RFC 3825. (Section 2.4.4), and Altitude uncertainty (Section 2.4.5).
-00: Changed boilerplate. Added B. Aboba as editor. Re-positioned o Section 2.5 has been added, covering the Datum field.
Appendix B and Acknowledgments sections. Changed reference o Section 3 (Security Considerations) has added a recommendation
numbers to names, added reference to RFC 5226 (since RFC 3825 on link layer confidentiality.
was missing a reference to RFC 2434, now obsolete), updated o Section 4 (IANA Considerations) has consolidated material
references (and URLs). Updated author affiliations and email relating to parameter allocation for both the DHCPv4 and
addresses. Changed references to "the appendix" to Appendix B. DHCPv6 option parameters.
Added this appendix listing changes. o The material formerly in Appendix A has been updated and
shortened and has been moved to Appendix B.
o An Appendix A on GML mapping has been added.
o Appendix C has been added, providing an example of uncertainty
encoding.
o Appendix D has been added, detailing the changes from RFC 3825.
Authors' Addresses Authors' Addresses
James M. Polk James M. Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, Texas 75082 USA Richardson, Texas 75082 USA
USA USA
EMail: jmpolk@cisco.com EMail: jmpolk@cisco.com
 End of changes. 13 change blocks. 
80 lines changed or deleted 81 lines changed or added

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