draft-ietf-geopriv-rfc3825bis-02.txt   draft-ietf-geopriv-rfc3825bis-03.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 ISOC Category: Standards Track ISOC
Expires: April 7, 2010 M. Linsner Expires: May 11, 2010 M. Linsner
7 October 2009 Cisco Systems 11 November 2009 Cisco Systems
M. Thomson M. Thomson
Andrew Andrew
B. Aboba (ed) B. Aboba (ed)
Microsoft Corporation Microsoft Corporation
Dynamic Host Configuration Protocol Option for Dynamic Host Configuration Protocol Option for
Coordinate-based Location Configuration Information Coordinate-based Location Configuration Information
draft-ietf-geopriv-rfc3825bis-02.txt draft-ietf-geopriv-rfc3825bis-03.txt
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 50 skipping to change at page 1, line 50
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 April 7, 2010. This Internet-Draft will expire on May 11, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Resolution and Uncertainty . . . . . . . . . . . . . . . 4 1.2 Resolution and Uncertainty . . . . . . . . . . . . . . . 4
2. DHCP Option Format . . . . . . . . . . . . . . . . . . . . . . 4 2. DHCP Option Format . . . . . . . . . . . . . . . . . . . . . . 4
2.1 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . 5 2.1 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . 5
2.2 DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 6 2.2 DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 6
2.3 Latitude and Longitude Fields . . . . . . . . . . . . . 8 2.3 Latitude and Longitude Fields . . . . . . . . . . . . . 8
2.4 Altitude . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4 Altitude . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Datum . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5 Datum . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . 14
6.2. Informational References . . . . . . . . . . . . . . . . 14 6.2. Informational References . . . . . . . . . . . . . . . . 14
Appendix A. Calculations of Imprecision possible with the DHC LCI 15 Appendix A. Calculations of Imprecision possible with the DHCP LCI 15
A.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 15 A.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 15
A.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 17 A.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 17
Appendix B. Changes from RFC 3825 . . . . . . . . . . . . . . . . 19 Appendix B. Changes from RFC 3825 . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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
skipping to change at page 3, line 43 skipping to change at page 3, line 43
terminates (such as the location of the wall jack). terminates (such as the location of the wall jack).
The options defined in this document have limited applicability for The options defined in this document have limited applicability for
mobile hosts. Typically DHCP clients refresh their configuration in mobile hosts. Typically DHCP clients refresh their configuration in
response to changes in interface state or pending lease expirations. response to changes in interface state or pending lease expirations.
As a result, when a mobile host changes location without subsequently As a result, when a mobile host changes location without subsequently
completing another DHCP exchange, location configuration information completing another DHCP exchange, location configuration information
initially obtained via DHCP could become outdated. initially obtained via DHCP could become outdated.
An important feature of this specification is that after the relevant An important feature of this specification is that after the relevant
DHC exchanges have taken place, the location information is stored on DHCP exchanges have taken place, the location information is stored
the end device rather than somewhere else, where retrieving it might on the end device rather than somewhere else, where retrieving it
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
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Resolution and Uncertainty 1.2. Resolution and Uncertainty
The DHCPv4 option format defined in this document utilizes both The DHCPv4 option format defined in this document utilizes both
resolution and uncertainty parameters. The DHCPv6 option format only resolution and uncertainty parameters. The DHCPv6 option format only
utilizes an uncertainty parameter. utilizes an uncertainty parameter.
Version 0 of the DHCPv4 option format defined in this document Version 0 of the DHCPv4 option format defined in this document
includes a resolution parameter for each of the dimensions of includes a resolution parameter for each of the dimensions of
location. Since this resolution parameter need not apply to all location. Since this resolution parameter need not apply to all
dimensions equally, a resolution value is included for each of the 3 dimensions equally, a resolution value is included for each of the 3
location elements. Resolution does not define Geographic Privacy location elements. No inferences relating to privacy policies can be
policy. drawn from either uncertainty or resolution values.
Appendix A of this document provides some arithmetic examples of the Appendix A of this document provides some arithmetic examples of the
implication of different resolution values on the La/Lo/Alt. implication of different resolution values on the La/Lo/Alt.
The DHCPv6 option format as well as version 1 of the DHCPv4 option The DHCPv6 option format as well as version 1 of the DHCPv4 option
format utilizes an uncertainty parameter. In the context of location format utilizes an uncertainty parameter. In the context of location
technology, uncertainty is a quantification of errors. Any method technology, uncertainty is a quantification of errors. Any method
for determining location is subject to some sources of error; for determining location is subject to some sources of error;
uncertainty describes the amount of error that is present. uncertainty describes the amount of error that is present.
Uncertainty might be the coverage area of a wireless transmitter, the Uncertainty might be the coverage area of a wireless transmitter, the
skipping to change at page 7, line 45 skipping to change at page 7, line 45
useful since receiving two copies of the same Option (either in the useful since receiving two copies of the same Option (either in the
same response or a separate response) causes a DHCP client to replace same response or a separate response) causes a DHCP client to replace
the information in the old Option with the information in the new the information in the old Option with the information in the new
Option. Option.
A server uses configuration to determine which version to send in a A server uses configuration to determine which version to send in a
response. For example, where a mixture of v0 and v1 clients are response. For example, where a mixture of v0 and v1 clients are
expected, the server could be configured to send v0 or v1 depending expected, the server could be configured to send v0 or v1 depending
on configuration (possibly making the choice based on information on configuration (possibly making the choice based on information
such as the client MAC address). Where few v0 clients are expected, such as the client MAC address). Where few v0 clients are expected,
the server could be configured to send only v1 responses. the server could be configured to send only v1 responses. Version 0
options will provide resolution, while version 1 options will provide
an area of uncertainty.
Servers that opt to send location in v1 format are likely to cause An RFC 3825 DHCPv4 client that receives a version 1 option, as
clients that support only v0 to reject the Option. This results in a defined in this document, will either reject the Option or will not
v0-only client not obtaining location information, with no ability to understand the additions to the datum field and will misinterpret the
indicate to the server that v1 was unsupported. Therefore, in LoRes, LaRes, and AltRes values. If the RFC 3825 DHCPv4 client does
situations where some clients are known to support only v0, by not reject the option and utilizes the location data it will most
default the server SHOULD send a v0 response. likely assume a datum and interpret the LoRes/LaRes/AltRes values as
significant digits and apply them to the Latitude, Longitude, and
Altitude values. The resultant location value will be in error up to
a full degree of latitude and longitude, and a full increment of
altitude. This results in a v0-only client either not obtaining
location information (with no ability to indicate to the server that
v1 was unsupported), or misinterpreting the option.
Therefore, in situations where some clients are known to support only
v0, by default the server SHOULD send a v0 response. It is also
RECOMMENDED that DHCPv4 client implementations support version 1, so
the versioning capability added by this document does not cause
errors interpreting the latitude, longitude and altitude values.
Moving forward, clients not understanding a datum value MUST assume a
World Geodesic System 1984 (WGS84) [WGS84] datum (EPSG [EPSG] 4326 or
4979, depending on whether there is an altitude value present) and
proceed accordingly. Assuming that a less accurate location value is
better than none, this ensures that some (perhaps less accurate)
location is available to the client.
2.3. Latitude and Longitude Fields 2.3. Latitude and Longitude Fields
The Latitude and Longitude values in this format are encoded as 34 The Latitude and Longitude values in this format are encoded as 34
bit, twos complement, fixed point values with 9 integer bits and 25 bit, twos complement, fixed point values with 9 integer bits and 25
fractional bits. The exact meaning of these values is determined by fractional bits. The exact meaning of these values is determined by
the datum; the description in this section applies to the datums the datum; the description in this section applies to the datums
defined in this document. defined in this document.
New datums MUST define the way that the 34 bit values and the New datums MUST define the way that the 34 bit values and the
skipping to change at page 12, line 32 skipping to change at page 12, line 50
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]). [RFC2131]).
When implementing a DHC server that will serve clients across an When implementing a DHCP server that will serve clients across an
uncontrolled network, one should consider the potential security uncontrolled network, one should consider the potential security
risks. risks.
4. IANA Considerations 4. IANA Considerations
IANA has assigned a DHCP option code of 123 for the GeoConf option IANA has assigned a DHCP option code of 123 for the GeoConf option
defined in this document. defined in this document.
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 (AT) field (see Section 2) and the Datum field registry: The Altitude (AT) field (see Section 2) and the Datum field
skipping to change at page 13, line 15 skipping to change at page 13, line 34
the vertical datum the vertical datum
Datum = 2 denotes the vertical datum NAD83 as defined by the EPSG as Datum = 2 denotes the vertical datum NAD83 as defined by the EPSG as
their CRS Code 4269; North American Vertical Datum of 1988 their CRS Code 4269; North American Vertical Datum of 1988
(NAVD88) is the associated vertical datum for NAD83 (NAVD88) is the associated vertical datum for NAD83
Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as
their CRS Code 4269; Mean Lower Low Water (MLLW) is the their CRS Code 4269; Mean Lower Low Water (MLLW) is the
associated vertical datum for NAD83 associated vertical datum for NAD83
Any additional LCI datum(s) to be defined for use via this DHC Option Any additional LCI datum(s) to be defined for use via this DHCP
MUST be done through a Standards Track RFC. Option MUST be done through a Standards Track RFC.
This document defines the Ver field, with values as follows: This document defines the Ver field, with values as follows:
0: Implementations conforming to [RFC3825] 0: Implementations conforming to [RFC3825]
1: Implementations of this specification 1: Implementations of this specification
Any additional Ver field values to be defined for use with this DHC Any additional Ver field values to be defined for use with this DHCP
Option MUST be done through a Standards Track RFC. Option MUST be done through a Standards Track RFC.
5. Acknowledgements 5. Acknowledgements
The authors would like to thank Patrik Falstrom, Ralph Droms, Ted The authors would like to thank Patrik Falstrom, Ralph Droms, Ted
Hardie, Jon Peterson, and Nadine Abbott for their inputs and Hardie, Jon Peterson, and Nadine Abbott for their inputs and
constructive comments regarding this document. Additionally, the constructive comments regarding this document. Additionally, the
authors would like to thank Greg Troxel for the education on vertical authors would like to thank Greg Troxel for the education on vertical
datums, as well as Carl Reed. datums, as well as Carl Reed.
skipping to change at page 15, line 5 skipping to change at page 15, line 12
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004. Configuration Information", RFC 3825, July 2004.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) Option for Civic Addresses Configuration and DHCPv6) Option for Civic Addresses Configuration
Information", RFC 4776, November 2006. Information", RFC 4776, November 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008. Considerations Section in RFCs", RFC 5226, May 2008.
Appendix A. Calculations of Imprecision Possible with the DHC LCI Appendix A. Calculations of Imprecision Possible with the DHCP LCI
The following examples for two different locations demonstrate how The following examples for two different locations demonstrate how
the Resolution values for Latitude, Longitude, and Altitude can be the Resolution values for Latitude, Longitude, and Altitude can be
used. In both examples the geo-location values were derived from used. In both examples the geo-location values were derived from
maps using the WGS84 map datum, therefore in these examples, the maps using the WGS84 map datum, therefore in these examples, the
datum field would have a value = 1 (00000001, or 0x01). datum field would have a value = 1 (00000001, or 0x01).
A.1. Location Configuration Information of "White House" (Example 1) A.1. Location Configuration Information of "White House" (Example 1)
The address was NOT picked for any political reason and can easily be The address was NOT picked for any political reason and can easily be
skipping to change at page 19, line 9 skipping to change at page 19, line 9
to show LaRes as value 18 (0x12 or 010010) and LoRes as value 18 to show LaRes as value 18 (0x12 or 010010) and LoRes as value 18
(0x12 or 010010). This would be describing a geo-location area that (0x12 or 010010). This would be describing a geo-location area that
is latitude 41.8769531 to latitude 41.8789062 and extends from is latitude 41.8769531 to latitude 41.8789062 and extends from
-87.6367188 degrees to -87.6347657 degrees longitude. This is an -87.6367188 degrees to -87.6347657 degrees longitude. This is an
area of approximately 373412 square feet (713.3 ft. x 523.5 ft.). area of approximately 373412 square feet (713.3 ft. x 523.5 ft.).
Appendix B. Changes from RFC 3825 Appendix B. Changes from RFC 3825
Technical changes: Technical changes:
-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 -02: Added Section 1.2 introducing uncertainty and resolution
concepts. Added Section 2.1 defining DHCPv6 option format. concepts. Added Section 2.1 defining DHCPv6 option format.
-01: Within Section 2.1, split Datum field from RFC 3825 into three -01: Within Section 2.1, split Datum field from RFC 3825 into three
fields: Ver, Res and Datum fields. Explained that the Ver fields: Ver, Res and Datum fields. Explained that the Ver
field is always located at the same offset. Added Section 2.2 field is always located at the same offset. Added Section 2.2
relating to Version Support. relating to Version Support.
-00: None -00: None
Editorial changes: Editorial changes:
-03: Changed "DHC" to "DHCP" in some usages. Clarified relatinoship
of resolution and uncertainty to privacy.
-02: Reorganized Sections 1 and 2. -02: Reorganized Sections 1 and 2.
-01: Added references to IEEE 802.11y, RFC 3825. -01: Added references to IEEE 802.11y, RFC 3825.
-00: Changed boilerplate. Added B. Aboba as editor. Re-positioned -00: Changed boilerplate. Added B. Aboba as editor. Re-positioned
Appendix A and Acknowledgements sections. Changed reference Appendix A and Acknowledgements sections. Changed reference
numbers to names, added reference to RFC 5226 (since RFC 3825 numbers to names, added reference to RFC 5226 (since RFC 3825
was missing a reference to RFC 2434, now obsolete), updated was missing a reference to RFC 2434, now obsolete), updated
references (and URLs). Updated author affiliations and email references (and URLs). Updated author affiliations and email
addresses. Changed references to "the appendix" to Appendix A. addresses. Changed references to "the appendix" to Appendix A.
 End of changes. 17 change blocks. 
25 lines changed or deleted 53 lines changed or added

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