draft-ietf-geopriv-rfc3825bis-09.txt   draft-ietf-geopriv-rfc3825bis-10.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: September 15, 2010 M. Linsner Expires: December 25, 2010 M. Linsner
7 March 2010 Cisco Systems 22 June 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-09.txt draft-ietf-geopriv-rfc3825bis-10.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.
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 in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), 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 months Internet-Drafts are draft documents valid for a maximum of six months
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 September 15, 2010. This Internet-Draft will expire on December 25, 2010.
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 24 skipping to change at page 3, line 24
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 . . . . . . . . . . . . . . . . . . . . . 18
A.1. GML Templates . . . . . . . . . . . . . . . . . . . . . 18 A.1. GML Templates . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. Calculations of Resolution . . . . . . . . . . . . . . 22 Appendix B. Calculations of Resolution . . . . . . . . . . . . . . 21
B.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 22 B.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 21
B.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 25 B.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 24
Appendix C. Calculations of Uncertainty . . . . . . . . . . . . . 26 Appendix C. Calculations of Uncertainty . . . . . . . . . . . . . 25
C.1 LCI of "Sydney Opera House" (Example 3) . . . . . . . . 26 C.1 LCI of "Sydney Opera House" (Example 3) . . . . . . . . 25
Appendix D. Changes from RFC 3825 . . . . . . . . . . . . . . . . 30 Appendix D. Changes from RFC 3825 . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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.
Different applications may be more suited to one form of location Different applications may be more suited to one form of location
information; therefore, both the geodetic and civic forms may be used information; therefore, both the geodetic and civic forms may be used
simultaneously. simultaneously.
This document specifies Dynamic Host Configuration Protocol (DHCPv4) This document specifies Dynamic Host Configuration Protocol v4
[RFC2131] and DHCPv6 [RFC3315]) options for the coordinate-based (DHCPv4) [RFC2131] and DHCPv6 [RFC3315] options for the coordinate-
geographic location of the client, to be provided by the server. based geographic location of the client, to be provided by the
"Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for server. "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6)
Civic Addresses Configuration Information" [RFC4776] specifies DHCP Option for Civic Addresses Configuration Information" [RFC4776]
options for civic addresses. specifies DHCP options for civic addresses.
The geodetic coordinate options defined in this document and the The geodetic coordinate options defined in this document and the
civic address options defined in [RFC4776] enable a DHCP client to civic address options defined in RFC 4776 [RFC4776] enable a DHCP
obtain its location. For example, a wired Ethernet host might use client to obtain its location. For example, a wired Ethernet host
these options for location determination. In this case, the location might use these options for location determination. In this case,
information could be derived from a wiremap by the DHCP server, using the location information could be derived from a wiremap by the DHCP
the Circuit-ID Relay Agent Information Option (RAIO) defined (as Sub- server, using the Circuit-ID Relay Agent Information Option (RAIO)
Option 1) in RFC 3046 [RFC3046]. The DHCP server could correlate the defined (as Sub-Option 1) in RFC 3046 [RFC3046]. The DHCP server
Circuit-ID with the geographic location where the identified circuit could correlate the Circuit-ID with the geographic location where the
terminates (such as the location of the wall jack). identified circuit 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
DHCP exchanges have taken place, the location information is stored DHCP exchanges have taken place, the location information is stored
skipping to change at page 5, line 39 skipping to change at page 5, line 39
When representing locations from sources that can quantify When representing locations from sources that can quantify
uncertainty, the goal is to find the smallest possible rectangular uncertainty, the goal is to find the smallest possible rectangular
prism that this format can describe. This is achieved by taking the prism that this format can describe. This is achieved by taking the
minimum and maximum values on each axis and ensuring that the final minimum and maximum values on each axis and ensuring that the final
encoding covers these points. This increases the region of encoding covers these points. This increases the region of
uncertainty, but ensures that the region that is described uncertainty, but ensures that the region that is described
encompasses the target location. encompasses the target location.
The DHCPv4 option format defined in this document supports both The DHCPv4 option format defined in this document supports both
resolution and uncertainty parameters. Version 0 of the DHCPv4 resolution and uncertainty parameters. Version 0 of the DHCPv4
option format defined in this document includes a resolution option format includes a resolution parameter for each of the
parameter for each of the dimensions of location. Since this dimensions of location. Since this resolution parameter need not
resolution parameter need not apply to all dimensions equally, a apply to all dimensions equally, a resolution value is included for
resolution value is included for each of the 3 location elements. each of the three location elements. Since version 0 of the DHCPv6
The DHCPv6 option format (which supports only version 1) as well as option format is not defined, the DHCPv6 option does not support a
version 1 of the DHCPv4 option format utilizes an uncertainty resolution parameter. Version 1 of the DHCPv4 and DHCPv6 option
parameter. Appendix A describes the mapping of DHCP option values to format utilizes an uncertainty parameter. Appendix A describes the
GML. Appendix B of this document provides examples showing the mapping of DHCP option values to GML. Appendix B of this document
calculation of resolution values. Appendix C provides an example provides examples showing the calculation of resolution values.
demonstrating calculation of uncertainty values. Appendix C provides an example demonstrating calculation of
uncertainty values.
2. DHCP Option Format 2. DHCP Option Format
This section defines the format for the DHCPv4 and DHCPv6 options. This section defines the format for the DHCPv4 and DHCPv6 options.
These options utilize a similar format, differing primarily in the These options utilize a similar format, differing primarily in the
option code. option code.
2.1. DHCPv6 Option 2.1. DHCPv6 Option
The DHCPv6 [RFC3315] option format is as follows: The DHCPv6 [RFC3315] option format is as follows:
skipping to change at page 6, line 31 skipping to change at page 6, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lat (cont'd) | LongUnc | Longitude + | Lat (cont'd) | LongUnc | Longitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude (cont'd) | AT | AltUnc | Altitude + | Longitude (cont'd) | AT | AltUnc | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude (cont'd) |Ver| Res |Datum| | Altitude (cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: GEOCONF_GEODETIC (16 bits). Code: GEOCONF_GEODETIC (16 bits).
OptLen: Option Length (16). This option is fixed size, the OptLen: Option Length (16). This option has a fixed length, so
value of this octet will always be 16. that the value of this octet will always be 16.
LatUnc: Latitude Uncertainty (6 bits). LatUnc: 6 bits. When the Ver field = 1, this field represents
latitude uncertainty. The contents of this field is
undefined for other values of the Ver field.
Latitude: Latitude (34 bits). Latitude: a 34 bit fixed point value consisting of 9 bits of
integer and 25 bits of fraction, interpreted as
described in Section 2.3.
LongUnc: Longitude Uncertainty (6 bits). LongUnc: 6 bits. When the Ver field = 1, this field represents
longitude uncertainty. The contents of this field is
undefined for other values of the Ver field.
Longitude: Longitude (34 bits). Longitude: a 34 bit fixed point value consisting of 9 bits of
integer and 25 bits of fraction, interpreted as
described in Section 2.3.
AType: Altitude Type (4 bits). AType: Altitude Type (4 bits).
AltUnc: Altitude Uncertainty (6 bits). AltUnc: 6 bits. When the Ver field = 1, this field represents
altitude uncertainty. The contents of this field is
undefined for other values of the Ver field.
Altitude: Altitude (30 bits). Altitude: A 30 bit value defined by the AType field.
Ver: The Ver field is two bits, providing for four potential Ver: The Ver field is two bits, providing for four potential
versions. This specification defines the behavior of versions. This specification defines the behavior of
version 1. The Ver field is always located at the same version 1. The Ver field is always located at the same
offset from the beginning of the option, regardless of offset from the beginning of the option, regardless of
the version in use. the version in use.
Res: The Res field which is 3 bits, is reserved. These bits Res: The Res field which is 3 bits, is reserved. These bits
have been used by [IEEE-802.11y], but are not defined have been used by [IEEE-802.11y], but are not defined
within this specification. within this specification.
skipping to change at page 7, line 36 skipping to change at page 7, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt.(cont'd) |Ver| Res |Datum| | Alt.(cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 8 bits. The code for the DHCPv4 option (123). Code: 8 bits. The code for the DHCPv4 option (123).
Length: 8 bits. The length of the DHCPv4 option, in octets. Length: 8 bits. The length of the DHCPv4 option, in octets.
For versions 0 and 1, the option length is 16. For versions 0 and 1, the option length is 16.
LatUnc: 6 bits. When the Ver field = 0, this field represents LatUnc: 6 bits. When the Ver field = 0, this field represents
Latitude resolution. When the Ver field = 1, latitude resolution. When the Ver field = 1,
this field represents latitude uncertainty. this field represents latitude uncertainty.
Latitude: a 34 bit fixed point value consisting of 9 bits of Latitude: a 34 bit fixed point value consisting of 9 bits of
integer and 25 bits of fraction. Latitude SHOULD be signed integer and 25 bits of fraction, interpreted
normalized to within +/- 90 degrees. Positive numbers as described in Section 2.3.
are north of the equator and negative numbers are south
of the equator.
LongUnc: 6 bits. When the Ver field = 0, this field represents LongUnc: 6 bits. When the Ver field = 0, this field represents
longitude resolution. When the Ver field = 1, longitude resolution. When the Ver field = 1,
this field represents longitude uncertainty. this field represents longitude uncertainty.
Longitude: a 34 bit fixed point value consisting of 9 bits of Longitude: a 34 bit fixed point value consisting of 9 bits of
integer and 25 bits of fraction. Longitude SHOULD be signed integer and 25 bits of fraction, interpreted
normalized to within +/- 180 degrees. Positive values as described in Section 2.3.
are East of the prime meridian and negative
(2s complement) numbers are West of the prime meridian.
AType: Altitude Type (4 bits). AType: Altitude Type (4 bits).
AltUnc: 6 bits. When the Ver field = 0, this field represents AltUnc: 6 bits. When the Ver field = 0, this field represents
Altitude resolution. When the Ver field = 1, altitude resolution. When the Ver field = 1,
this field represents altitude uncertainty. this field represents altitude uncertainty.
Altitude: A 30 bit value defined by the AType field. Altitude: A 30 bit value defined by the AType field.
Ver: The Ver field is two bits, providing for four potential Ver: The Ver field is two bits, providing for four potential
versions. This specification defines the behavior of versions. This specification defines the behavior of
version 0 (originally specified in [RFC3825]) as well as version 0 (originally specified in [RFC3825]) as well as
version 1. The Ver field is always located at the same version 1. The Ver field is always located at the same
offset from the beginning of the option, regardless of offset from the beginning of the option, regardless of
the version in use. the version in use.
skipping to change at page 8, line 32 skipping to change at page 8, line 39
have been used by [IEEE-802.11y], but are not defined have been used by [IEEE-802.11y], but are not defined
within this specification. within this specification.
Datum: 3 bits. The Map Datum used for the coordinates given in Datum: 3 bits. The Map Datum used for the coordinates given in
this Option. this Option.
2.2.1. Version Support 2.2.1. Version Support
2.2.1.1. Client Version Support 2.2.1.1. Client Version Support
DHCPv4 clients implementing this specification MUST support receiving DHCPv6 clients implementing this specification MUST support receiving
responses of versions 0 and 1. Since this specification utilizes the version 1 responses. DHCPv4 clients implementing this specification
same DHCPv4 option code as [RFC3825], the option format does not MUST support receiving responses of versions 0 and 1. It is required
provide a means for the client to indicate the highest version that that DHCPv4 client implementations support version 1 so the
it supports to the server. versioning capability added by this document does not cause errors
interpreting the Latitude, Longitude and Altitude values. Since this
specification utilizes the same DHCPv4 option code as [RFC3825], the
option format does not provide a means for the DHCPv4 client to
indicate the highest version that it supports to the DHCPv6 server.
Moving forward, DHCPv4 and DHCPv6 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.2.1.2. Server Version Selection 2.2.1.2. Server Version Selection
A DHCPv4 server that provides location information cannot provide DHCPv6 servers implementing this specifiction MUST support sending
options with both version 0 and version 1 formats in the same version 1 responses. A DHCPv4 server implementing this specification
response. This is not useful since receiving two copies of the same MUST support sending version 1 responses and SHOULD support sending
Option (either in the same response or a separate response) causes a version 0 responses. A DHCPv4 server that provides location
DHCPv4 client to replace the information in the old Option with the information cannot provide options with both version 0 and version 1
information in the new Option. formats in the same response. This is not useful since receiving two
copies of the same Option (either in the same response or a separate
response) causes a DHCPv4 client to replace the information in the
old Option with the information in the new Option.
A server uses configuration to determine which version to send in a A DHCPv4 server uses configuration to determine which version to send
response. For example, where a mixture of version 0 and version 1 in a response. For example, where a mixture of version 0 and version
clients are expected, the server could be configured to send version 1 clients are expected, the DHCPv4 server could be configured to send
0 or version 1 depending on configuration (possibly making the choice version 0 or version 1 depending on configuration (possibly making
based on information such as the client MAC address). Where few the choice based on information such as the client MAC address).
version 0 clients are expected, the server could be configured to Where few version 0 clients are expected, the DHCPv4 server could be
send only version 1 responses. Version 0 options will provide configured to send only version 1 responses. Version 0 options will
resolution, while version 1 options will provide an area of provide resolution, while version 1 options will provide an area of
uncertainty. uncertainty.
An RFC 3825 DHCPv4 client that receives a version 1 option, as An RFC 3825 DHCPv4 client that receives a version 1 option, as
defined in this document, will either reject the Option or will not defined in this document, will either reject the Option or will not
understand the additions to the Datum field and will misinterpret the understand the additions to the Datum field and will misinterpret the
LongUnc, LatUnc, and AltUnc values. If the RFC 3825 DHCPv4 client LongUnc, LatUnc, and AltUnc values. If the RFC 3825 DHCPv4 client
does not reject the option and utilizes the location data it will does not reject the option and utilizes the location data it will
most likely assume a datum and interpret the LongUnc/LatUnc/AltUnc most likely assume a datum. Assuming one of the RFC 3825 datums
values as significant digits and apply them to the Latitude, causes correct interpretation of Latitude/Longitude/Altitude values.
Longitude, and Altitude values. The resultant location value will be The values for LongUnc/LatUnc/AltUnc are mistakenly interpreted as
in error up to a full degree of latitude and longitude, and a full representing significant digits. The resultant location value will
increment of altitude. This results in a version 0-only client be in error up to a full degree of latitude and longitude, and a full
either not obtaining location information (with no ability to increment of altitude.
indicate to the server that version 1 was unsupported), or
misinterpreting the option.
This results in a version 0-only DHCPv4 client either not obtaining
location information (with no ability to indicate to the server that
version 1 was unsupported), or misinterpreting the option.
Therefore, in situations where some DHCPv4 clients are known to Therefore, in situations where some DHCPv4 clients are known to
support only version 0, by default the DHCPv4 server SHOULD send a support only version 0, by default the DHCPv4 server SHOULD send a
version 0 response. It is also RECOMMENDED that DHCPv4 client version 0 response.
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 specification are encoded The Latitude and Longitude values in this specification are encoded
as 34 bit, twos complement, fixed point values with 9 integer bits as 34 bit, twos complement, fixed point values with 9 integer bits
and 25 fractional bits. The exact meaning of these values is and 25 fractional bits. The exact meaning of these values is
determined by the datum; the description in this section applies to determined by the datum; the description in this section applies to
the datums defined in this document. the datums defined in this document. This document uses the same
definition for all datums it specifies.
New datums MUST define the way that the 34 bit values and the
respective 6 bit uncertainties are interpreted. This document uses
the same definition for all datums it specifies.
Latitude values MUST be constrained to the range from -90 to +90 Latitude values encoded by the DHCP server MUST be constrained to the
degrees. Positive latitudes are north of the equator; negative range from -90 to +90 degrees. Location consumers MUST be prepared
latitudes are south of the equator. to normalize values outside this range. Values outside the range are
normalized by clamping (e.g. values less than -90 degrees are set to
-90; values greater than 90 degrees are set to +90). Positive
latitudes are north of the equator and negative latitudes are south
of the equator.
Longitude values SHOULD be normalized to the range from -180 to +180 Longitude values encoded by the DHCP server MUST be normalized to the
degrees. Values outside this range are normalized by adding or range from -180 to +180 degrees. Location consumers MUST be prepared
subtracting 360 until they fall within this range. Positive to normalize values outside this range. Values outside the range are
longitudes are east of the Prime Meridian (Greenwich); negative normalized by wrapping (e.g. adding or subtracting 360 until they
fall within the range of -180 to 180). Positive longitudes are east
of the Prime Meridian (Greenwich) and negative (2s complement)
longitudes are west of the Prime Meridian. longitudes are west of the Prime Meridian.
When encoding, Latitude and Longitude values are rounded to the When encoding, Latitude and Longitude values are rounded to the
nearest 34-bit binary representation. This imprecision is considered nearest 34-bit binary representation. This imprecision is considered
acceptable for the purposes to which this form is intended to be acceptable for the purposes to which this form is intended to be
applied and is ignored when decoding. applied and is ignored when decoding.
2.3.1. Latitude and Longitude Resolution 2.3.1. Latitude and Longitude Resolution
The Latitude (LatUnc), Longitude (LongUnc) and Altitude (AltUnc) The Latitude (LatUnc), Longitude (LongUnc) and Altitude (AltUnc)
skipping to change at page 11, line 11 skipping to change at page 11, line 26
In the DHCPv6 option and the version 1 DHCPv4 option, the Latitude In the DHCPv6 option and the version 1 DHCPv4 option, the Latitude
and Longitude Uncertainty fields (LatUnc and LongUnc) quantify the and Longitude Uncertainty fields (LatUnc and LongUnc) quantify the
amount of uncertainty in each of the Latitude and Longitude values amount of uncertainty in each of the Latitude and Longitude values
respectively. A value of 0 is reserved to indicate that the respectively. A value of 0 is reserved to indicate that the
uncertainty is unknown; values greater than 34 are reserved. uncertainty is unknown; values greater than 34 are reserved.
A point within the region of uncertainty is selected to be the A point within the region of uncertainty is selected to be the
encoded point; the centroid of the region is often an appropriate encoded point; the centroid of the region is often an appropriate
choice. The value for uncertainty is taken as the distance from the choice. The value for uncertainty is taken as the distance from the
selected point to the furthest extreme of the region of uncertainty selected point to the furthest extreme of the region of uncertainty
on that axis. on that axis. This is demonstrated in the figure below, which shows
a two-dimensional polygon that is projected on each axis. In the
The following figure shows a two-dimensional figure that is projected figure, "X" marks the point that is selected; the ranges marked with
to each axis. In the figure, "X" marks the point that is selected; "U" is the uncertainty.
the ranges marked with "U" is the uncertainty.
___ ___________ ___ ___________
^ | / | ^ | / |
| | / | | | / |
| | / | | | / |
U | / | U | / |
| | ( | | | ( |
V | | | V | | |
--X | X | --X | X |
| | `---------. | | `---------.
skipping to change at page 12, line 34 skipping to change at page 12, line 47
uncertainty to the next available power of two; subsequent repeated uncertainty to the next available power of two; subsequent repeated
encodings and decodings do not change the value. Only increasing encodings and decodings do not change the value. Only increasing
uncertainty means that the associated confidence does not have to uncertainty means that the associated confidence does not have to
decrease. decrease.
2.4. Altitude 2.4. Altitude
The altitude is expressed as a 30 bit, fixed point, twos complement The altitude is expressed as a 30 bit, fixed point, twos complement
integer with 22 integer bits and 8 fractional bits. How the Altitude integer with 22 integer bits and 8 fractional bits. How the Altitude
value is interpreted depends on the type of altitude and the selected value is interpreted depends on the type of altitude and the selected
datum. datum. Three Altitude Types are defined in this document: unknown
(0), meters (1) and floors (2).
New Altitude Types and datums MUST define the way that the 30 bit
value and the associated 6 bit uncertainty are interpreted.
Three Altitude Types are defined in this document: unknown (0),
meters (1) and floors (2). Additional Altitude Types MUST be defined
in a Standards Track RFC.
2.4.1. No Known Altitude (AT = 0) 2.4.1. No Known Altitude (AT = 0)
In some cases, the altitude of the location might not be provided. An In some cases, the altitude of the location might not be provided. An
Altitude Type of 0 indicates that the altitude is not given to the Altitude Type of 0 indicates that the altitude is not given to the
client. In this case, the Altitude and Altitude Uncertainty fields client. In this case, the Altitude and Altitude Uncertainty fields
can contain any value and MUST be ignored. can contain any value and MUST be ignored.
2.4.2. Altitude in Meters (AT = 1) 2.4.2. Altitude in Meters (AT = 1)
skipping to change at page 15, line 5 skipping to change at page 15, line 14
This datum is used for referencing location on or near tidal water This datum is used for referencing location on or near tidal water
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).
New Datum codes can be registered in the IANA registry (Section 4) by
a Standards Track RFC.
3. Security Considerations 3. Security Considerations
Where critical decisions might be based on the value of this option, Where critical decisions might be based on the value of this option,
DHCP authentication as defined in "Authentication for DHCP Messages" DHCP authentication as defined in "Authentication for DHCP Messages"
[RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
[RFC3315] SHOULD be used to protect the integrity of the DHCP [RFC3315] SHOULD be used to protect the integrity of the DHCP
options. 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 reduce [RFC2131]). Link layer confidentiality may also be employed to
the risk of location disclosure. reduce the risk of location disclosure.
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 (AT) field and the Datum field (see Section registry: The Altitude Type (AT) field and the Datum field (see
2). The datum indicator MUST include specification of both Section 2). The datum indicator MUST include specification of both
horizontal and vertical datum. New values for the Altitude (AT) horizontal and vertical datum. New values for the Altitude Type (AT)
field are assigned through "Standards Action" [RFC5226]. The initial and Datum fields are assigned through "Standards Action" [RFC5226].
values of the Altitude registry are as follows: New Altitude Types MUST define the way that the 30 bit altitude
values and the associated 6 bit uncertainty are interpreted. New
datums MUST define the way that the 34 bit values and the respective
6 bit uncertainties are interpreted. The initial values of the
Altitude registry are as follows:
AT = 0 No known altitude.
AT = 1 meters of altitude defined by the vertical datum specified. AT = 1 meters of altitude defined by the vertical datum specified.
AT = 2 building floors of altitude. AT = 2 building floors of altitude.
Datum = 1 denotes the vertical datum WGS 84 as defined by the EPSG as Datum = 1 denotes the vertical datum WGS 84 as defined by the EPSG as
their CRS Code 4327; CRS Code 4327 also specifies WGS 84 as their CRS Code 4327; CRS Code 4327 also specifies WGS 84 as
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 the DHCPv4 or
DHCPv6 Options defined in this document MUST be done through a
Standards Track RFC.
This document defines the Ver field for the DHCPv4 and DHCPv6 This document defines the Ver field for the DHCPv4 and DHCPv6
Options, with values as follows: options. New values for the Ver field are assigned through
"Standards Action" [RFC5226]. Initial values are as follows:
0: DHCPv4 Implementations conforming to [RFC3825] 0: DHCPv4 Implementations conforming to [RFC3825]
1: Implementations of this specification (for both DHCPv4 and DHCPv6) 1: Implementations of this specification (for both DHCPv4 and DHCPv6)
Any additional Ver field values to be defined for use with the DHCPv4
or DHCPv6 Options MUST be done through a Standards Track RFC.
5. Acknowledgments 5. Acknowledgments
The authors would like to thank Randall Gellens, Patrik Falstrom, The authors would like to thank Randall Gellens, Patrik Falstrom,
Ralph Droms, Ted Hardie, Jon Peterson, and Nadine Abbott for their Ralph Droms, Ted Hardie, Jon Peterson, and Nadine Abbott for their
inputs and constructive comments regarding this document. inputs and constructive comments regarding this document.
Additionally, the authors would like to thank Greg Troxel for the Additionally, the authors would like to thank Greg Troxel for the
education on vertical datums, as well as Carl Reed. Thanks to education on vertical datums, as well as Carl Reed. Thanks to
Richard Barnes for his contribution on GML mapping for resolution. Richard Barnes for his contribution on GML mapping for resolution.
6. References 6. References
6.1. Normative References 6.1. Normative References
[EPSG] European Petroleum Survey Group, http://www.epsg.org/ and [EPSG] European Petroleum Survey Group, http://www.epsg.org/ and
http://www.epsg-registry.org/ http://www.epsg-registry.org/
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
March 1997. 2131, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
January 2001. 3046, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.
Carney, "Dynamic Host Configuration Protocol for IPv6 and M. Carney, "Dynamic Host Configuration Protocol for
(DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[WGS84] US National Imagery and Mapping Agency, "Department of Defense [WGS84] US National Imagery and Mapping Agency, "Department of
(DoD) World Geodetic System 1984 (WGS 84), Third Edition", Defense (DoD) World Geodetic System 1984 (WGS 84), Third
NIMA TR8350.2, January 2000, Edition", NIMA TR8350.2, January 2000,
https://www1.nga.mil/PRODUCTSSERVICES/GEODESYGEOPHYSICS/ https://www1.nga.mil/PRODUCTSSERVICES/GEODESYGEOPHYSICS/
WORLDGEODETICSYSTEM/Pages/default.aspx and WORLDGEODETICSYSTEM/Pages/default.aspx and
http://www.ngs.noaa.gov/faq.shtml#WGS84 http://www.ngs.noaa.gov/faq.shtml#WGS84
6.2. Informational References 6.2. Informational References
[GeoShape] [GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application Application Schema for use by the Internet Engineering
Schema for use by the Internet Engineering Task Force (IETF)", Task Force (IETF)", Candidate OpenGIS Implementation
Candidate OpenGIS Implementation Specification 06-142, Specification 06-142, Version: 0.0.9, December 2006.
Version: 0.0.9, December 2006.
[IEEE-802.11y] [IEEE-802.11y] Information technology - Telecommunications and
Information technology - Telecommunications and information information exchange between systems - Local and
exchange between systems - Local and metropolitan area metropolitan area networks - Specific requirements - Part
networks - Specific requirements - Part 11: Wireless LAN 11: Wireless LAN Medium Access Control (MAC) and Physical
Medium Access Control (MAC) and Physical Layer (PHY) Layer (PHY) specifications Amendment 3: 3650-3700 MHz
specifications Amendment 3: 3650-3700 MHz Operation in USA, Operation in USA, November 2008.
November 2008.
[NENA] National Emergency Number Association (NENA) www.nena.org NENA [NENA] National Emergency Number Association (NENA) www.nena.org
Technical Information Document on Model Legislation Enhanced NENA Technical Information Document on Model Legislation
911 for Multi-Line Telephone Systems. Enhanced 911 for Multi-Line Telephone Systems.
[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 Location Configuration Protocol Option for Coordinate-based
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 (DHCPv4 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
and DHCPv6) Option for Civic Addresses Configuration (DHCPv4 and DHCPv6) Option for Civic Addresses
Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Object Format for Presence Information Data Format Location
(PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs", RFC 5226, May 2008. IANA Considerations Section in RFCs", RFC 5226, May 2008.
Appendix A. GML Mapping Appendix A. GML Mapping
The GML representation of a decoded DHCP option depends on what The GML representation of a decoded DHCP option depends on what
fields are specified. The DHCP format for location logically fields are specified. The DHCP format for location logically
describes a geodetic prism, rectangle, or point, depending on whether describes a geodetic prism, rectangle, or point, depending on whether
Altitude and uncertainty values are provided. In the absence of Altitude and uncertainty values are provided. In the absence of
uncertainty information, the value decoded from the DHCP form can be uncertainty information, the value decoded from the DHCP form can be
expressed as a single point; this is true regardless of whether the expressed as a single point; this is true regardless of whether the
version 0 or version 1 interpretations of the uncertainty fields are version 0 or version 1 interpretations of the uncertainty fields are
skipping to change at page 20, line 6 skipping to change at page 20, line 6
The value "2D-CRS-URN" is defined by the datum value: If the datum is The value "2D-CRS-URN" is defined by the datum value: If the datum is
WGS84 (value 1), then the 2D-CRS-URN is "urn:ogc:def:crs:EPSG::4326". WGS84 (value 1), then the 2D-CRS-URN is "urn:ogc:def:crs:EPSG::4326".
If the datum is NAD83 (value 2 or 3), then the 2D-CRS-URN is If the datum is NAD83 (value 2 or 3), then the 2D-CRS-URN is
"urn:ogc:def:crs:EPSG::4269". "urn:ogc:def:crs:EPSG::4269".
A Polygon shape with the WGS84 three-dimensional CRS is used if the A Polygon shape with the WGS84 three-dimensional CRS is used if the
datum is WGS84 (value 1) and the Altitude is specified in meters datum is WGS84 (value 1) and the Altitude is specified in meters
(Altitude type 1), but no Altitude uncertainty is specified (that is, (Altitude type 1), but no Altitude uncertainty is specified (that is,
AltUnc is 0). In this case, the value of the Altitude field is added AltUnc is 0). In this case, the value of the Altitude field is added
after each of the points above, and the srsName attribute is set to after each of the points above, and the srsName attribute is set to
the three-dimentional WGS84 CRS, namely "urn:ogc:def:crs:EPSG::4979". the three-dimensional WGS84 CRS, namely "urn:ogc:def:crs:EPSG::4979".
A simple point shape is used if either Latitude uncertainty (LatUnc) A simple point shape is used if either Latitude uncertainty (LatUnc)
or Longitude uncertainty (LongUnc) is not specified. With Altitude, or Longitude uncertainty (LongUnc) is not specified. With Altitude,
this uses a three-dimensional CRS; otherwise, it uses a two- this uses a three-dimensional CRS; otherwise, it uses a two-
dimensional CRS. dimensional CRS.
<gml:Point srsName="$CRS-URN$" <gml:Point srsName="$CRS-URN$"
xmlns:gml="http://www.opengis.net/gml"> xmlns:gml="http://www.opengis.net/gml">
<gml:pos>$Latitude$ $Longitude$ $[Altitude]$</gml:pos> <gml:pos>$Latitude$ $Longitude$ $[Altitude]$</gml:pos>
</gml:Point> </gml:Point>
skipping to change at page 30, line 9 skipping to change at page 29, line 9
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: Technical changes:
-10: Clarified requirements for normalization of the
the Latitude and Longitude fields. Clarified requirements
for version support in clients and servers.
-09: Updated and shortened Appendix B.1. -09: Updated and shortened Appendix B.1.
-08: Added Appendix A on GML mapping. -08: Added Appendix A on GML mapping.
-06: Added recommendation on link layer confidentiality to the -06: Added recommendation on link layer confidentiality to the
Security Considerations section. Security Considerations section.
-05: Added version field to DHCPv6 option. -05: Added version field to DHCPv6 option.
-04: Added Appendix C providing an example relating to -04: Added Appendix C providing an example relating to
uncertainty. Added Section 2.3.1 on Latitude and Longitude uncertainty. Added Section 2.3.1 on Latitude and Longitude
resolution and Section 2.4.4 on Altitude resolution. resolution and Section 2.4.4 on Altitude resolution.
Added definition of Resolution to Section 1.2. Added definition of Resolution to Section 1.2.
-03: Clarified potential behavior of version 0 clients receiving -03: Clarified potential behavior of version 0 clients receiving
skipping to change at page 30, line 31 skipping to change at page 29, line 34
-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:
-10: Consolidated material relating to parameter allocation into
the IANA Considerations section.
-07: Updated boilerplate, cleaned up security considerations section. -07: Updated boilerplate, cleaned up security considerations section.
-06: Added corrections to Section 1.2 "Resolution and Uncertainty". -06: Added corrections to Section 1.2 "Resolution and Uncertainty".
Added the DHCPv6 Option Version field to the IANA Added the DHCPv6 Option Version field to the IANA
Considerations section. Considerations section.
-05: Corrected length of DHCPv6 option. Added Key to uncertainty -05: Corrected length of DHCPv6 option. Added Key to uncertainty
figure. figure.
-04: Changed all uses of the LoRes/LaRes/AltRes terminology to -04: Changed all uses of the LoRes/LaRes/AltRes terminology to
LongUnc/LatUnc/AltUnc, and clarified when these parameters LongUnc/LatUnc/AltUnc, and clarified when these parameters
were used to encode resolution vs. uncertainty. Reorganized were used to encode resolution vs. uncertainty. Re-organized
Section 1.2. Added references to RFC 4119, RFC 5139 and Section 1.2. Added references to RFC 4119, RFC 5139 and
[GeoShape]. [GeoShape].
-03: Changed "DHC" to "DHCP" in some usages. Clarified relationship -03: Changed "DHC" to "DHCP" in some usages. Clarified relationship
of resolution and uncertainty to privacy. of resolution and uncertainty to privacy.
-02: Reorganized Sections 1 and 2. -02: Re-organized 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 B and Acknowledgments sections. Changed reference Appendix B and Acknowledgments 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 B. addresses. Changed references to "the appendix" to Appendix B.
Added this appendix listing changes. Added this appendix listing changes.
Authors' Addresses Authors' Addresses
 End of changes. 56 change blocks. 
185 lines changed or deleted 194 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/