draft-ietf-geopriv-rfc3825bis-16.txt   draft-ietf-geopriv-rfc3825bis-17.txt 
GEOPRIV Working Group J. Polk GEOPRIV Working Group J. Polk
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT M. Linsner
Obsoletes: 3825 (if approved) J. Schnizlein Obsoletes: 3825 (if approved) Cisco Systems
Category: Standards Track Individual Contributor Category: Standards Track M. Thomson
Expires: July 25, 2011 M. Linsner Expires: August 26, 2011 Andrew Corporation
25 January 2011 Cisco Systems 26 February 2011 B. Aboba (ed)
M. Thomson
Andrew
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-16.txt draft-ietf-geopriv-rfc3825bis-17.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. This document obsoletes RFC 3825. datum for each of these values. This document obsoletes RFC 3825.
skipping to change at page 1, line 49 skipping to change at page 1, line 46
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 July 25, 2011. This Internet-Draft will expire on August 26, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Resolution and Uncertainty . . . . . . . . . . . . . . . 5 1.2 Resolution and Uncertainty . . . . . . . . . . . . . . . 5
2. DHCP Option Format . . . . . . . . . . . . . . . . . . . . . . 6 2. DHCP Option Formats . . . . . . . . . . . . . . . . . . . . . 6
2.1 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . 6 2.1 DHCPv6 GeoLoc Option . . . . . . . . . . . . . . . . . . 6
2.2 DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . 8 2.2 DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . 8
2.3 Latitude and Longitude Fields . . . . . . . . . . . . . 11 2.3 Latitude and Longitude Fields . . . . . . . . . . . . . 11
2.4 Altitude . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4 Altitude . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Datum . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5 Datum . . . . . . . . . . . . . . . . . . . . . . . . . 16
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 16 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 17 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 17
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 4.1 DHCP Options . . . . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Altitude Type Registry . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . 18 4.3 Datum Registry . . . . . . . . . . . . . . . . . . . . . 18
6.2. Informational References . . . . . . . . . . . . . . . . 19 4.4 GeoLoc Option Version Registry . . . . . . . . . . . . . 19
Appendix A. GML Mapping . . . . . . . . . . . . . . . . . . . . . 21 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
A.1. GML Templates . . . . . . . . . . . . . . . . . . . . . 21 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. Calculations of Resolution . . . . . . . . . . . . . . 24 6.1. Normative References . . . . . . . . . . . . . . . . . . 20
B.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 25 6.2. Informational References . . . . . . . . . . . . . . . . 21
B.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 27 Appendix A. GML Mapping . . . . . . . . . . . . . . . . . . . . . 23
Appendix C. Calculations of Uncertainty . . . . . . . . . . . . . 28 A.1. GML Templates . . . . . . . . . . . . . . . . . . . . . 23
C.1 LCI of "Sydney Opera House" (Example 3) . . . . . . . . 28 Appendix B. Calculations of Resolution . . . . . . . . . . . . . . 26
Appendix D. Changes from RFC 3825 . . . . . . . . . . . . . . . . 32 B.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 B.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 29
Appendix C. Calculations of Uncertainty . . . . . . . . . . . . . 30
C.1 LCI of "Sydney Opera House" (Example 3) . . . . . . . . 30
Appendix D. Changes from RFC 3825 . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
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 5, line 44 skipping to change at page 5, line 44
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 formats defined in this document support resolution The DHCPv4 option formats defined in this document support resolution
and uncertainty parameters. DHCPv4 Option 123 includes a resolution and uncertainty parameters. The DHCPv4 GeoConf Option 123 includes a
parameter for each of the dimensions of location. Since this resolution parameter for each of the dimensions of location. Since
resolution parameter need not apply to all dimensions equally, a this resolution parameter need not apply to all dimensions equally, a
resolution value is included for each of the three location elements. resolution value is included for each of the three location elements.
DHCPv4 Option TBD as well as the DHCPv6 option format utilize an The DHCPv4 GeoLoc Option TBD1 as well as the DHCPv6 GeoLoc Option
uncertainty parameter. TBD2 format utilize an uncertainty parameter.
Appendix A describes the mapping of DHCP option values to the Appendix A describes the mapping of DHCP option values to the
Geography Markup Language (GML). Appendix B of this document Geography Markup Language (GML). Appendix B of this document
provides examples showing the calculation of resolution values. provides examples showing the calculation of resolution values.
Appendix C provides an example demonstrating calculation of Appendix C provides an example demonstrating calculation of
uncertainty values. uncertainty values.
Since the Presence Information Data Format Location Object (PIDF-LO) Since the Presence Information Data Format Location Object (PIDF-LO)
[RFC4119][RFC5491] is used to conveying location and the associated [RFC4119][RFC5491] is used to conveying location and the associated
uncertainty within an emergency call [Convey], a mechanism is needed uncertainty within an emergency call [Convey], a mechanism is needed
to convert the information contained within the DHCPv4 and DHCPv6 to convert the information contained within the DHCPv4 and DHCPv6
options to PIDF-LO. This document describes the following options to PIDF-LO. This document describes the following
conversions: conversions:
DHCPv4 Option 123 to PIDF-LO DHCPv4 GeoConf Option 123 to PIDF-LO
DHCPv4 Option TBD and DHCPv6 option to PIDF-LO DHCPv4 GeoLoc Option TBD1 and DHCPv6 GeoLoc Option TBD2 to PIDF-LO
PIDF-LO to DHCP Option TBD and DHCPv6 option PIDF-LO to DHCP GeoLoc Option TBD1 and DHCPv6 GeoLoc Option TBD2
Conversion to PIDF-LO does not increase uncertainty; conversion from Conversion to PIDF-LO does not increase uncertainty; conversion from
PIDF-LO to DHCPv4 Option TBD and the DHCPv6 option increases PIDF-LO to the DHCPv4 GeoLoc Option TBD1 and the DHCPv6 GeoLoc Option
uncertainty by less than a factor of 2 in each dimension. Since it TBD2 increases uncertainty by less than a factor of 2 in each
is not possible to translate an arbitrary PIDF-LO to DHCP Option 123 dimension. Since it is not possible to translate an arbitrary PIDF-
with a bounded increase in uncertainty, the conversion is not LO to the DHCP GeoConf Option 123 with a bounded increase in
specified. uncertainty, the conversion is not specified.
2. DHCP Option Format 2. DHCP Option Formats
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 GeoLoc Option
The DHCPv6 [RFC3315] option format is as follows: The format of the DHCPv6 [RFC3315] GeoLoc Option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code (TBD) | OptLen | | Option Code (TBD2) | OptLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LatUnc | Latitude + | LatUnc | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lat (cont'd) | LongUnc | Longitude + | Lat (cont'd) | LongUnc | Longitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude (cont'd) | AType | AltUnc | Altitude + | Longitude (cont'd) | AType | AltUnc | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude (cont'd) |Ver| Res |Datum| | Altitude (cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: DHCP Option Code TBD (16 bits). Code: DHCP Option Code TBD2 (16 bits).
OptLen: Option Length. For version 1, the option length is 16. OptLen: Option Length. For version 1, the option length is 16.
LatUnc: 6 bits. When the Ver field = 1, this field represents LatUnc: 6 bits. When the Ver field = 1, this field represents
latitude uncertainty. The contents of this field is latitude uncertainty. The contents of this field is
undefined for other values of the Ver field. undefined for other values of the Ver field.
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, interpreted as integer and 25 bits of fraction, interpreted as
described in Section 2.3. described in Section 2.3.
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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.
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. DHCPv4 Options 2.2. DHCPv4 Options
2.2.1. DHCPv4 Option 123 2.2.1. DHCPv4 GeoConf Option
The format of DHCPv4 Option 123 is as follows: The format of the DHCPv4 GeoConf Option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code 123 | Length | LaRes | Latitude + | Code 123 | Length | LaRes | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LoRes | + | Latitude (cont'd) | LoRes | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude | | Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltRes | Altitude + | AType | AltRes | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt.(cont'd) | Res |Datum| | Alt.(cont'd) | Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 8 bits. The code for the DHCPv4 option (123). Code: 8 bits. The code for the DHCPv4 GeoConf Option (123).
Length: 8 bits. The length of the DHCPv4 option, in octets. Length: 8 bits. The length of the option, in octets.
The option length is 16. The option length is 16.
LaRes: 6 bits. This field represents latitude resolution. LaRes: 6 bits. This field represents latitude resolution.
Latitude: a 34 bit fixed point value consisting of 9 bits of Latitude: a 34 bit fixed point value consisting of 9 bits of
signed integer and 25 bits of fraction, interpreted signed integer and 25 bits of fraction, interpreted
as described in Section 2.3. as described in Section 2.3.
LoRes: 6 bits. This field represents longitude resolution. LoRes: 6 bits. This field represents longitude resolution.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
Altitude: A 30 bit value defined by the AType field, described in Altitude: A 30 bit value defined by the AType field, described in
Section 2.4. Section 2.4.
Res: The Res field which is 5 bits, is reserved. These bits Res: The Res field which is 5 bits, is reserved. These bits
have been used by IEEE 802.11y [IEEE-802.11y], but are have been used by IEEE 802.11y [IEEE-802.11y], but are
not defined within this specification. not defined 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.2. DHCPv4 Option TBD 2.2.2. DHCPv4 GeoLoc Option
The format of DHCPv4 option TBD is as follows: The format of DHCPv4 GeoLoc Option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code TBD | Length | LatUnc | Latitude + | Code TBD1 | Length | LatUnc | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LongUnc | + | Latitude (cont'd) | LongUnc | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude | | Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltUnc | Altitude + | AType | AltUnc | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt.(cont'd) |Ver| Res |Datum| | Alt.(cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: 8 bits. The code for the DHCPv4 option (TBD). Code: 8 bits. The code for the DHCPv4 GeoLoc Option (TBD1).
Length: 8 bits. The length of the DHCPv4 option, in octets. Length: 8 bits. The length of the option, in octets.
For version 1, the option length is 16. For version 1, the option length is 16.
LatUnc: 6 bits. When the Ver field = 1, this field represents LatUnc: 6 bits. When the Ver field = 1, this field represents
latitude uncertainty. The contents of this field is latitude uncertainty. The contents of this field is
undefined for other values of the Ver field. undefined for other values of the Ver field.
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, interpreted as integer and 25 bits of fraction, interpreted as
described in Section 2.3. described in Section 2.3.
skipping to change at page 10, line 26 skipping to change at page 10, line 26
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.3. Option Support 2.2.3. Option Support
2.2.3.1. Client Support 2.2.3.1. Client Support
DHCPv4 clients implementing this specification MUST support receiving DHCPv4 clients implementing this specification MUST support receiving
DHCPv4 Option TBD (version 1), and MAY support receiving DHCPv4 the DHCPv4 GeoLoc Option TBD1 (version 1), and MAY support receiving
Option 123 (originally defined in RFC 3825 [RFC3825]). the DHCPv4 GeoConf Option 123 (originally defined in RFC 3825
[RFC3825]).
DHCPv4 clients request the DHCPv4 server to send Option 123, Option DHCPv4 clients request the DHCPv4 server to send GeoConf Option 123,
TBD or both via inclusion of the Parameter Request List option. As GeoLoc Option TBD1 or both via inclusion of the Parameter Request
noted in Section 9.8 of RFC 2132 [RFC2132]: List option. As noted in Section 9.8 of RFC 2132 [RFC2132]:
This option is used by a DHCP client to request values for This option is used by a DHCP client to request values for
specified configuration parameters. The list of requested specified configuration parameters. The list of requested
parameters is specified as n octets, where each octet is a valid parameters is specified as n octets, where each octet is a valid
DHCP option code as defined in this document. DHCP option code as defined in this document.
The client MAY list the options in order of preference. The DHCP The client MAY list the options in order of preference. The DHCP
server is not required to return the options in the requested server is not required to return the options in the requested
order, but MUST try to insert the requested options in the order order, but MUST try to insert the requested options in the order
requested by the client. requested by the client.
skipping to change at page 11, line 8 skipping to change at page 11, line 8
understand a datum value, they MUST assume a World Geodesic System understand a datum value, they MUST assume a World Geodesic System
1984 (WGS84) [WGS84] datum (EPSG [EPSG] 4326 or 4979, depending on 1984 (WGS84) [WGS84] datum (EPSG [EPSG] 4326 or 4979, depending on
whether there is an Altitude value present) and proceed accordingly. whether there is an Altitude value present) and proceed accordingly.
Assuming that a less accurate location value is better than none, Assuming that a less accurate location value is better than none,
this ensures that some (perhaps less accurate) location is available this ensures that some (perhaps less accurate) location is available
to the client. to the client.
2.2.3.2. Server Option Selection 2.2.3.2. Server Option Selection
A DHCPv4 server implementing this specification MUST support sending A DHCPv4 server implementing this specification MUST support sending
Option TBD version 1 and SHOULD support sending Option 123 in GeoLoc Option TBD1 version 1 and SHOULD support sending GeoConf
responses. Option 123 in responses.
A DHCPv4 server that provides location information SHOULD honor the A DHCPv4 server that provides location information SHOULD honor the
Parameter Request List included by the DHCPv4 client in order to Parameter Request List included by the DHCPv4 client in order to
decide whether to send Option 123, Option TBD or both in the decide whether to send GeoConf Option 123, GeoLoc Option TBD1 or both
Response. in the Response.
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. This document uses the same the datums defined in this document. This document uses the same
definition for all datums it specifies. definition for all datums it specifies.
skipping to change at page 11, line 47 skipping to change at page 11, line 47
decimal degrees or latitude values outside the range of -90 to 90 decimal degrees or latitude values outside the range of -90 to 90
degrees MUST be considered invalid. Server implementations SHOULD degrees MUST be considered invalid. Server implementations SHOULD
prevent the entry of invalid values within the selected coordinate prevent the entry of invalid values within the selected coordinate
reference system. Location consumers MUST ignore invalid location reference system. Location consumers MUST ignore invalid location
coordinates and SHOULD log invalid location errors. coordinates and SHOULD log invalid location errors.
2.3.1. Latitude and Longitude Resolution 2.3.1. Latitude and Longitude Resolution
The Latitude (LaRes), Longitude (LoRes) and Altitude (AltRes) The Latitude (LaRes), Longitude (LoRes) and Altitude (AltRes)
Resolution fields are encoded as 6 bit, unsigned integer values. In Resolution fields are encoded as 6 bit, unsigned integer values. In
the DHCPv4 Option 123, the LaRes, LoRes and AltRes fields are used to the DHCPv4 GeoConf Option 123, the LaRes, LoRes and AltRes fields are
encode the number of bits of resolution. The resolution sub-fields used to encode the number of bits of resolution. The resolution sub-
accommodate the desire to easily adjust the precision of a reported fields accommodate the desire to easily adjust the precision of a
location. Contents beyond the claimed resolution MAY be randomized reported location. Contents beyond the claimed resolution MAY be
to obscure greater precision that might be available. randomized to obscure greater precision that might be available.
In the DHCPv4 Option 123, the LaRes value encodes the number of high- In the DHCPv4 GeoConf Option 123, the LaRes value encodes the number
order latitude bits that should be considered valid. Any bits of high-order latitude bits that should be considered valid. Any
entered to the right of this limit should not be considered valid and bits entered to the right of this limit should not be considered
might be purposely false, or zeroed by the sender. The examples in valid and might be purposely false, or zeroed by the sender. The
Appendix B illustrate that a smaller value in the resolution field examples in Appendix B illustrate that a smaller value in the
increases the area within which the device is located. A value of 2 resolution field increases the area within which the device is
in the LaRes field indicates a precision of no greater than 1/6th located. A value of 2 in the LaRes field indicates a precision of no
that of the globe (see the first example of Appendix B). A value of greater than 1/6th that of the globe (see the first example of
34 in the LaRes field indicates a precision of about 3.11 mm in Appendix B). A value of 34 in the LaRes field indicates a precision
latitude at the equator. of about 3.11 mm in latitude at the equator.
In the DHCPv4 Option 123, the LoRes value encodes the number of high- In the DHCPv4 GeoConf Option 123, the LoRes value encodes the number
order longitude bits that should be considered valid. Any bits of high-order longitude bits that should be considered valid. Any
entered to the right of this limit should not be considered valid and bits entered to the right of this limit should not be considered
might be purposely false, or zeroed by the sender. A value of 2 in valid and might be purposely false, or zeroed by the sender. A value
the LoRes field indicates precision of no greater than 1/6th that of of 2 in the LoRes field indicates precision of no greater than 1/6th
the globe (see the first example of Appendix B). A value of 34 in that of the globe (see the first example of Appendix B). A value of
the LoRes field indicates a precision of about 2.42 mm in Longitude 34 in the LoRes field indicates a precision of about 2.42 mm in
(at the equator). Because lines of longitude converge at the poles, Longitude (at the equator). Because lines of longitude converge at
the distance is smaller (better precision) for locations away from the poles, the distance is smaller (better precision) for locations
the equator. away from the equator.
2.3.2. Latitude and Longitude Uncertainty 2.3.2. Latitude and Longitude Uncertainty
In the DHCPv6 option and the DHCPv4 Option TBD, the Latitude and In the DHCPv6 GeoLoc Option TBD2 and the DHCPv4 GeoLoc Option TBD1,
Longitude Uncertainty fields (LatUnc and LongUnc) quantify the amount the Latitude and Longitude Uncertainty fields (LatUnc and LongUnc)
of uncertainty in each of the Latitude and Longitude values quantify the amount of uncertainty in each of the Latitude and
respectively. A value of 0 is reserved to indicate that the Longitude values respectively. A value of 0 is reserved to indicate
uncertainty is unknown; values greater than 34 are reserved. that the 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. This is demonstrated in the figure below, which shows on that axis. This is demonstrated in the figure below, which shows
a two-dimensional polygon that is projected on each axis. In the a two-dimensional polygon that is projected on each axis. In the
figure, "X" marks the point that is selected; the ranges marked with figure, "X" marks the point that is selected; the ranges marked with
"U" is the uncertainty. "U" is the uncertainty.
skipping to change at page 15, line 19 skipping to change at page 15, line 19
- if negative, the floor value is farther below the ground floor. - if negative, the floor value is farther below the ground floor.
Non-integer values can be used to represent intermediate or sub- Non-integer values can be used to represent intermediate or sub-
floors, such as mezzanine levels. Example: a mezzanine between floor floors, such as mezzanine levels. Example: a mezzanine between floor
1 and floor 2 could be represented as a value of 1.25. Example: 1 and floor 2 could be represented as a value of 1.25. Example:
mezzanines between floor 4 and floor 5 could be represented as values mezzanines between floor 4 and floor 5 could be represented as values
of 4.5 and 4.75. of 4.5 and 4.75.
2.4.4. Altitude Resolution 2.4.4. Altitude Resolution
In the DHCPv4 Option 123, the Altitude Resolution (AltRes) value In the DHCPv4 GeoConf Option 123, the Altitude Resolution (AltRes)
encodes the number of high-order altitude bits that should be value encodes the number of high-order altitude bits that should be
considered valid. Values above 30 (decimal) are undefined and considered valid. Values above 30 (decimal) are undefined and
reserved. reserved.
If the Altitude Type value is one (AType = 1), an AltRes value 0.0 If the Altitude Type value is one (AType = 1), an AltRes value 0.0
would indicate unknown Altitude. The most precise altitude would would indicate unknown Altitude. The most precise altitude would
have an AltRes value of 30. Many values of AltRes would obscure any have an AltRes value of 30. Many values of AltRes would obscure any
variation due to vertical datum differences. variation due to vertical datum differences.
The AltRes field SHOULD be set to maximum precision when AType = 2 The AltRes field SHOULD be set to maximum precision when AType = 2
(floors) when a floor value is included in the DHCP Reply, or when (floors) when a floor value is included in the DHCP Reply, or when
AType = 0, to denote that the floor isn't known. An altitude coded AType = 0, to denote that the floor isn't known. An altitude coded
as AType = 2, AltRes = 30, and Altitude = 0.0 is meaningful even as AType = 2, AltRes = 30, and Altitude = 0.0 is meaningful even
outside a building, and represents ground level at the given latitude outside a building, and represents ground level at the given latitude
and longitude. and longitude.
2.4.5. Altitude Uncertainty 2.4.5. Altitude Uncertainty
In the DHCPv6 option or the DHCPv4 Option TBD, the AltUnc value In the DHCPv6 GeoLoc Option TBD2 or the DHCPv4 GeoLoc Option TBD1,
quantifies the amount of uncertainty in the Altitude value. As with the AltUnc value quantifies the amount of uncertainty in the Altitude
LatUnc and LongUnc, a value of 0 for AltUnc is reserved to indicate value. As with LatUnc and LongUnc, a value of 0 for AltUnc is
that Altitude Uncertainty is not known; values above 30 are also reserved to indicate that Altitude Uncertainty is not known; values
reserved. Altitude Uncertainty only applies to Altitude Type 1. above 30 are also reserved. Altitude Uncertainty only applies to
Altitude Type 1.
The amount of Altitude Uncertainty can be determined by the following The amount of Altitude Uncertainty can be determined by the following
formula, where x is the encoded integer value: formula, where x is the encoded integer value:
Uncertainty = 2 ^ ( 21 - x ) Uncertainty = 2 ^ ( 21 - x )
This value uses the same units as the associated altitude. This value uses the same units as the associated altitude.
Similarly, a value for the encoded integer value can be derived by Similarly, a value for the encoded integer value can be derived by
the following formula: the following formula:
skipping to change at page 17, line 26 skipping to change at page 17, line 31
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.
Link layer confidentiality and integrity protection may also be Link layer confidentiality and integrity protection may also be
employed to reduce the risk of location disclosure and tampering. 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. 4.1. DHCP Options
Assignment of an additional DHCPv4 option code as well as a DHCPv6
option code is requested.
IANA maintains registries for the Altitude Type (AType), Datum and This document defines the DHCPv6 GeoLoc option (see Section 2.1)
Version fields. New values for each of these registries are assigned which requires assignment of DHCPv6 option code TBD2 [RFC3315]:
through "Standards Actions" [RFC5226].
Each AType registry entry MUST define the way that the 30 bit Value Description Reference
altitude values and the associated 6 bit uncertainty are interpreted. ---- ------------------ ----------
TBD2 OPTION_GEOLOCATION RFC xxxx
[RFC Editor: Please replace xxxx with the RFC number
assigned to this document.]
Each Datum registry entry MUST include specification of both This document defines the DHCPv4 GeoConf option (see Section 2.2.1)
which has been assigned a DHCPv4 option code of 123 from the DHCP
Option space.
This document also defines the DHCPv4 GeoLoc option (see Section
2.2.2) which requires assignment of DHCPv4 option code TBD1
[RFC2132][RFC2939]:
Data
Tag Name Length Meaning Reference
---- ---- ------ ------- ---------
TBD1 GeoLoc 16 Geospatial Location RFC xxxx
with Uncertainty
[RFC Editor: Please replace xxxx with the RFC number
assigned to this document.]
4.2. Altitude Type Registry
IANA is asked to create and maintain the Altitude Type registry
following the guidelines below.
The registry consists of three values: Altitude Type, Description
and Reference. These are described below.
Altitude Type: an integer, refers to the value used in the DHCPv4
GeoConf and the DHCPv4 and DHCPv6 GeoLoc Options described in this
document. Values from 0 to 15 are assigned.
Description: the description of the altitude described by this code.
Reference: the reference to the document that describes the altitude
code. This reference MUST define the way that the 30 bit altitude
values and the associated 6 bit uncertainty are interpreted.
Initial values are given below; new assignments are to be made
following the "Standards Action" policies [RFC5226].
+------+---------------------+--------------+
| # | Description | Reference |
+------+---------------------+--------------+
| 0 | No known altitude | RFC xxxx |
| 1 | Altitude in meters | RFC xxxx |
| 2 | Altitude in floors | RFC xxxx |
| 3-15 | Unassigned | RFC xxxx |
+------+---------------------+--------------+
[RFC Editor: Please replace xxxx with the RFC number
assigned to this document.]
4.3. Datum Registry
IANA is asked to create and maintain the Datum registry following the
guidelines below.
The registry consists of three values: Datum, Description and
Reference. These are described below.
Datum: an integer, refers to the value used in the DHCPv4 GeoConf and
the DHCPv4 and DHCPv6 GeoLoc Options described in this document.
Values from 1 to 7 are assigned.
Description: the description of the altitude described by this code.
Reference: the reference to the document that describes the Datum
code. This reference MUST include specification of both the
horizontal and vertical datum, and MUST define the way that the 34 horizontal and vertical datum, and MUST define the way that the 34
bit values and the respective 6 bit uncertainties are interpreted. bit values and the respective 6 bit uncertainties are interpreted.
The initial AType registry is: Initial values are given below; new assignments are to be made
following the "Standards Action" policies [RFC5226].
AType = 0 No known altitude. +------+----------------------------------------+--------------+
| # | Description | Reference |
+------+----------------------------------------+--------------+
| 0 | Reserved | RFC xxxx |
+------+----------------------------------------+--------------+
| 1 | Vertical datum WGS 84 defined by EPSG | RFC xxxx |
| | CRS Code 4327 | |
+------+----------------------------------------+--------------+
| 2 | Vertical datum NAD83 defined by EPSG | RFC xxxx |
| | CRS Code 4269 with North American | |
| | Vertical Datum of 1988 (NAVD88) | |
+------+----------------------------------------+--------------+
| 3 | Vertical datum NAD83, defined by EPSG | RFC xxxx |
| | CRS Code 4269 with Mean Lower Low Water| |
| | (MLLW) as associated vertical datum | |
+------+----------------------------------------+--------------+
| 4-7 | Unassigned | RFC xxxx |
+------+----------------------------------------+--------------+
[RFC Editor: Please replace xxxx with the RFC number
assigned to this document.]
AType = 1 meters of altitude defined by the vertical datum 4.4. GeoLoc Option Version Registry
specified.
AType = 2 building floors of altitude. IANA is asked to create and maintain the GeoLoc Option Version
registry following the guidelines below.
The initial Datum registry is: The registry consists of three values: GeoLoc Option Version,
Description and Reference. These are described below.
Datum = 1 denotes the vertical datum WGS 84 as defined by the EPSG GeoLoc Option Version: an integer, refers to the version used in the
as their CRS Code 4327; CRS Code 4327 also specifies WGS 84 DHCPv4 and DHCPv6 GeoLoc Options described in this document. Values
as the vertical datum. from 1 to 3 are assigned.
Datum = 2 denotes the vertical datum NAD83 as defined by the EPSG as Description: the description of the version described by this code.
their CRS Code 4269; North American Vertical Datum of 1988
(NAVD88) is the associated vertical datum for NAD83.
Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as Reference: the reference to the document that describes the Version
their CRS Code 4269; Mean Lower Low Water (MLLW) is the code.
associated vertical datum for NAD83.
The initial Version registry is: Initial values are given below; new assignments are to be made
following the "Standards Action" policies [RFC5226].
1: Implementations utilizing uncertainty parameters +------+---------------------------------------+--------------+
(for both DHCPv4 and DHCPv6). | # | Description | Reference |
+------+---------------------------------------+--------------+
| 0 | Reserved | RFC xxxx |
+------+---------------------------------------+--------------+
| 1 | Implementations utilizing uncertainty | RFC xxxx |
| | parameters for both DHCPv4 and DHCPv6 | |
| | GeoLoc options | |
+------+---------------------------------------+--------------+
| 2-3 | Unassigned | RFC xxxx |
+------+---------------------------------------+--------------+
[RFC Editor: Please replace xxxx with the RFC number
assigned to this document.]
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, Robert Sparks, Ralph Droms and Ralph Droms, Ted Hardie, Jon Peterson, Robert Sparks, Ralph Droms,
Nadine Abbott for their inputs and constructive comments regarding Nadine Abbott and Mykyta Yevstifeyev for their inputs and
this document. Additionally, the authors would like to thank Greg constructive comments regarding this document. Additionally, the
Troxel for the education on vertical datums, as well as Carl Reed. authors would like to thank Greg Troxel for the education on vertical
Thanks to Richard Barnes for his contribution on GML mapping for datums, as well as Carl Reed. Thanks to Richard Barnes for his
resolution. 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 2131,
March 1997. March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC2132, March 1997. Extensions", RFC2132, March 1997.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
of New DHCP Options and Message types", BCP 43, RFC 2939,
September 2000.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008.
[WGS84] US National Imagery and Mapping Agency, "Department of [WGS84] US National Imagery and Mapping Agency, "Department of
Defense (DoD) World Geodetic System 1984 (WGS 84), Third Defense (DoD) World Geodetic System 1984 (WGS 84), Third
Edition", 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
[Convey] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance [Convey] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", Internet draft (work for the Session Initiation Protocol", Internet draft (work
in progress), draft-ietf-sipcore-location- in progress), draft-ietf-sipcore-location-
conveyance-04.txt, October 25, 2010. conveyance-06.txt, February 23, 2011.
[GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape [GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Engineering Task Application Schema for use by the Internet Engineering Task
Force (IETF)", Candidate OpenGIS Implementation Force (IETF)", Candidate OpenGIS Implementation
Specification 06-142, Version: 0.0.9, December 2006. Specification 06-142, Version: 0.0.9, December 2006.
[IEEE-802.11y] [IEEE-802.11y]
Information technology - Telecommunications and information Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area exchange between systems - Local and metropolitan area
networks - Specific requirements - Part 11: Wireless LAN networks - Specific requirements - Part 11: Wireless LAN
skipping to change at page 20, line 16 skipping to change at page 22, line 27
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.
[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 Object
(PIDF-LO)", RFC 5139, February 2008. (PIDF-LO)", RFC 5139, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008.
[RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations, and PIDF-LO Usage Clarification, Considerations, and
Recommendations ", RFC 5491, March 2009 Recommendations ", RFC 5491, March 2009
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
skipping to change at page 21, line 36 skipping to change at page 23, line 36
that covers three dimensional coordinates. By necessity, locations that covers three dimensional coordinates. By necessity, locations
described in these datums can be represented by two dimensional described in these datums can be represented by two dimensional
shapes only; that is, either a two dimensional point or a polygon. shapes only; that is, either a two dimensional point or a polygon.
If the Altitude Type is 2 (floors), then this value can be If the Altitude Type is 2 (floors), then this value can be
represented using a civic address object [RFC5139] that is presented represented using a civic address object [RFC5139] that is presented
alongside the geodetic object. alongside the geodetic object.
This Appendix describes how the location value encoded in DHCP format This Appendix describes how the location value encoded in DHCP format
for geodetic location can be expressed in GML. The mapping is valid for geodetic location can be expressed in GML. The mapping is valid
for the DHCPv6 option as well as both of the DHCPv4 options, and for for the DHCPv6 GeoLoc Option as well as both of the DHCPv4 GeoConf
the currently-defined datum values (1, 2, and 3). Further version or and GeoLoc options, and for the currently-defined datum values (1, 2,
datum definitions should provide similar mappings. and 3). Further version or datum definitions should provide similar
mappings.
These shapes can be mapped to GML by first computing the bounds that These shapes can be mapped to GML by first computing the bounds that
are described using the coordinate and uncertainty fields, then are described using the coordinate and uncertainty fields, then
encoding the result in a GML Polygon or Prism shape. encoding the result in a GML Polygon or Prism shape.
A.1. GML Templates A.1. GML Templates
If Altitude is provided in meters (AType 1) and the datum value is If Altitude is provided in meters (AType 1) and the datum value is
WGS84 (value 1), then the proper GML shape is a Prism, with the WGS84 (value 1), then the proper GML shape is a Prism, with the
following form (where $value$ indicates a value computed from the following form (where $value$ indicates a value computed from the
skipping to change at page 23, line 20 skipping to change at page 25, line 21
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>
A.1.1. Finding Low and High Values using Uncertainty Fields A.1.1. Finding Low and High Values using Uncertainty Fields
For the DHCPv4 Option 123, resolution fields are used (LaRes, LoRes, For the DHCPv4 GeoConf Option 123, resolution fields are used (LaRes,
AltRes), indicating how many bits of a value contain information. LoRes, AltRes), indicating how many bits of a value contain
Any bits beyond those indicated can be either zero or one. information. Any bits beyond those indicated can be either zero or
one.
For the DHCPv6 option and DHCPv4 Option TBD, the LatUnc, LongUnc and For the DHCPv6 GeoLoc Option TBD2 and DHCPv4 GeoLoc Option TBD1, the
AltUnc fields indicate uncertainty distances, denoting the bounds of LatUnc, LongUnc and AltUnc fields indicate uncertainty distances,
the location region described by the DHCP location object. denoting the bounds of the location region described by the DHCP
location object.
The two sections below describe how to compute the Latitude, The two sections below describe how to compute the Latitude,
Longitude, and Altitude bounds (e.g., $lowLatitude$, $highAltitude$) Longitude, and Altitude bounds (e.g., $lowLatitude$, $highAltitude$)
in the templates above. The first section describes how these bounds in the templates above. The first section describes how these bounds
are computed in the "resolution encoding" (DHCPv4 Option 123), while are computed in the "resolution encoding" (DHCPv4 GeoConf Option
the second section addresses the "uncertainty encoding" (DHCPv6 123), while the second section addresses the "uncertainty encoding"
Option and DHCPv4 Option TBD). (DHCPv6 GeoLoc Option TBD2 and DHCPv4 GeoLoc Option TBD1).
A.1.1.1. Resolution Encoding A.1.1.1. Resolution Encoding
Given a number of resolution bits (i.e., the value of a resolution Given a number of resolution bits (i.e., the value of a resolution
field), if all bits beyond those bits are set to zero, this gives the field), if all bits beyond those bits are set to zero, this gives the
lowest possible value. The highest possible value can be found lowest possible value. The highest possible value can be found
setting all bits to one. setting all bits to one.
If the encoded value of Latitude/Longitude and resolution (LaRes, If the encoded value of Latitude/Longitude and resolution (LaRes,
LoRes) are treated as 34-bit unsigned integers, the following can be LoRes) are treated as 34-bit unsigned integers, the following can be
skipping to change at page 24, line 44 skipping to change at page 26, line 47
Altitude uncertainty (AltUnc in version 1) uses the same process with Altitude uncertainty (AltUnc in version 1) uses the same process with
different constants: different constants:
distance = 2 ^ (21 - uncertainty) distance = 2 ^ (21 - uncertainty)
lowvalue = value - distance lowvalue = value - distance
Appendix B. Calculations of Resolution Appendix B. Calculations of Resolution
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 (used in the Resolution values for Latitude, Longitude, and Altitude (used in
DHCPv4 Option 123) can be calculated. In both examples, the geo- DHCPv4 GeoConf Option 123) can be calculated. In both examples, the
location values were derived from maps using the WGS84 map datum, geo-location values were derived from maps using the WGS84 map datum,
therefore in these examples, the Datum field would have a value = 1 therefore in these examples, the Datum field would have a value = 1
(00000001, or 0x01). (00000001, or 0x01).
B.1. Location Configuration Information of "White House" (Example 1) B.1. Location Configuration Information of "White House" (Example 1)
The grounds of the White House in Washington D.C. (1600 Pennsylvania The grounds of the White House in Washington D.C. (1600 Pennsylvania
Ave. NW, Washington, DC 20006) can be found between 38.895375 and Ave. NW, Washington, DC 20006) can be found between 38.895375 and
38.898653 degrees North and 77.037911 and 77.035116 degrees West. In 38.898653 degrees North and 77.037911 and 77.035116 degrees West. In
this example, we assume that we are standing on the sidewalk on the this example, we assume that we are standing on the sidewalk on the
north side of the White House, between driveways. Since we are not north side of the White House, between driveways. Since we are not
skipping to change at page 25, line 33 skipping to change at page 27, line 33
location that is Latitude 38.8984375 north to Latitude 38.8988616 location that is Latitude 38.8984375 north to Latitude 38.8988616
north and Longitude -77.0371094 to Longitude -77.0375977. This is an north and Longitude -77.0371094 to Longitude -77.0375977. This is an
area of approximately 89 feet by 75 feet or 6669 square feet, which area of approximately 89 feet by 75 feet or 6669 square feet, which
is very close to the 7000 square feet requested by NENA. In this is very close to the 7000 square feet requested by NENA. In this
example, a service provider could enforce that a device send a example, a service provider could enforce that a device send a
Location Configuration Information with this minimum amount of Location Configuration Information with this minimum amount of
resolution for this particular location when calling emergency resolution for this particular location when calling emergency
services. services.
An approximate representation of this location might be provided using An approximate representation of this location might be provided using
the DHCPv4 Option 123 encoding as follows: the DHCPv4 GeoConf Option 123 encoding as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code (123) | OptLen (16) | LaRes | Latitude . | Code (123) | OptLen (16) | LaRes | Latitude .
|0 1 1 1 1 0 1 1|0 0 0 1 0 0 0 0|0 1 0 0 1 0|0 0 0 1 0 0 1 1 0 1. |0 1 1 1 1 0 1 1|0 0 0 1 0 0 0 0|0 1 0 0 1 0|0 0 0 1 0 0 1 1 0 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Latitude (cont'd) | LoRes | . . Latitude (cont'd) | LoRes | .
.1 1 0 0 1 0 1 1 1 0 0 1 1 0 0 0 0 1 1 0 0 0 1 1|0 1 0 0 0 1|1 1. .1 1 0 0 1 0 1 1 1 0 0 1 1 0 0 0 0 1 1 0 0 0 1 1|0 1 0 0 0 1|1 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 9 skipping to change at page 30, 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 C. Calculations of Uncertainty Appendix C. Calculations of Uncertainty
The following example demonstrates how uncertainty values for The following example demonstrates how uncertainty values for
Latitude, Longitude, and Altitude (LatUnc, LongUnc and AltUnc Latitude, Longitude, and Altitude (LatUnc, LongUnc and AltUnc
used in the DHCPv6 option as well as DHCPv4 Option TBD) used in the DHCPv6 GeoLoc Option TBD2 as well as DHCPv4 GeoLoc
can be calculated. Option TBD1) can be calculated.
C.1. Location Configuration Information of "Sydney Opera House" C.1. Location Configuration Information of "Sydney Opera House"
(Example 3) (Example 3)
This section describes an example of encoding and decoding the This section describes an example of encoding and decoding the
geodetic DHCP Option. The textual results are expressed in GML geodetic DHCP Option. The textual results are expressed in GML
[OGC.GML-3.1.1] form, suitable for inclusion in PIDF-LO [RFC4119]. [OGC.GML-3.1.1] form, suitable for inclusion in PIDF-LO [RFC4119].
These examples all assume a datum of WGS84 (datum = 1) and an These examples all assume a datum of WGS84 (datum = 1) and an
Altitude type of meters (AType = 1). Altitude type of meters (AType = 1).
skipping to change at page 29, line 24 skipping to change at page 31, line 24
The result of this equation is also 18, or 010010 in binary. The result of this equation is also 18, or 010010 in binary.
Altitude Uncertainty (AltUnc) uses the formula from Section 2.4.4: Altitude Uncertainty (AltUnc) uses the formula from Section 2.4.4:
x = 21 - ceil( log2( 33.7 - 0 ) ) x = 21 - ceil( log2( 33.7 - 0 ) )
The result of this equation is 15, which is encoded as 001111 in The result of this equation is 15, which is encoded as 001111 in
binary. binary.
Adding an Altitude Type of 1 (meters) and a Datum of 1 (WGS84), this Adding an Altitude Type of 1 (meters) and a Datum of 1 (WGS84), this
gives the following DHCPv4 Option TBD form: gives the following DHCPv4 GeoLoc Option TBD1 form:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code (TBD) | OptLen (16) | LatUnc | Latitude . | Code (TBD1) | OptLen (16) | LatUnc | Latitude .
|0 1 1 1 1 0 1 1|0 0 0 1 0 0 0 0|0 1 0 0 1 0|1 1 1 0 1 1 1 1 0 0. |0 1 1 1 1 0 1 1|0 0 0 1 0 0 0 0|0 1 0 0 1 0|1 1 1 0 1 1 1 1 0 0.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Latitude (cont'd) | LongUnc | . . Latitude (cont'd) | LongUnc | .
.0 1 0 0 1 0 0 1 0 0 1 1 0 1 1 0 0 0 0 0 1 1 0 1|0 1 0 0 1 0|0 1. .0 1 0 0 1 0 0 1 0 0 1 1 0 1 1 0 0 0 0 0 1 1 0 1|0 1 0 0 1 0|0 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Longitude (cont'd) | . Longitude (cont'd) |
.0 0 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 0 1 0 1 1 1 0 1 1 0 0 0 0 1 1| .0 0 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 0 1 0 1 1 1 0 1 1 0 0 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltUnc | Altitude . | AType | AltUnc | Altitude .
|0 0 0 1|0 0 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1. |0 0 0 1|0 0 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1.
skipping to change at page 32, line 14 skipping to change at page 34, line 14
Appendix D. Changes from RFC 3825 Appendix D. Changes from RFC 3825
This section lists the major changes between RFC 3825 and this This section lists the major changes between RFC 3825 and this
document. Minor changes, including style, grammar, spelling and document. Minor changes, including style, grammar, spelling and
editorial changes are not mentioned here. editorial changes are not mentioned here.
o Section 1 now includes clarifications on wired and wireless uses. o Section 1 now includes clarifications on wired and wireless uses.
o The former Sections 1.2 and 1.3 have been removed. Section 1.2 o The former Sections 1.2 and 1.3 have been removed. Section 1.2
now defines the concepts of uncertainty and resolution, as well now defines the concepts of uncertainty and resolution, as well
as conversion between the DHCP option format and PIDF-LO. as conversion between the DHCP option formats and PIDF-LO.
o A DHCPv6 option is now defined (Section 2.1) as well o A DHCPv6 GeoLoc Option is now defined (Section 2.1) as well
as DHCPv4 options (Section 2.2). as a new DHCPv4 GeoLoc Option (Section 2.2.2).
o The former Datum field has been split into three fields: o The former Datum field has been split into three fields:
Ver, Res and Datum. These fields are used in both the Ver, Res and Datum. These fields are used in both the
DHCPv4 and DHCPv6 options. DHCPv4 GeoLoc Option and the DHCPv6 GeoLoc Option.
o Section 2.2.3 has been added, describing option support. o Section 2.2.3 has been added, describing option support
requirements on DHCP clients and servers.
o Section 2.3 has been added, describing the Latitude and o Section 2.3 has been added, describing the Latitude and
Longitude fields. Longitude fields.
o Section 2.3.1 has been added, covering Latitude and Longitude o Section 2.3.1 has been added, covering Latitude and Longitude
resolution. resolution.
o Section 2.3.2 has been added, covering Latitude and Longitude o Section 2.3.2 has been added, covering Latitude and Longitude
uncertainty. uncertainty.
o Section 2.4 has been added, covering values of the Altitude o Section 2.4 has been added, covering values of the Altitude
field (Sections 2.4.1, 2.4.2 and 2.4.3), Altitude resolution field (Sections 2.4.1, 2.4.2 and 2.4.3), Altitude resolution
(Section 2.4.4), and Altitude uncertainty (Section 2.4.5). (Section 2.4.4), and Altitude uncertainty (Section 2.4.5).
o Section 2.5 has been added, covering the Datum field. o Section 2.5 has been added, covering the Datum field.
o Section 3 (Security Considerations) has added a recommendation o Section 3 (Security Considerations) has added a recommendation
on link layer confidentiality. on link layer confidentiality.
o Section 4 (IANA Considerations) has consolidated material o Section 4 (IANA Considerations) has consolidated material
relating to parameter allocation for both the DHCPv4 and relating to parameter allocation for both the DHCPv4 and
DHCPv6 option parameters. DHCPv6 option parameters, and has been rewritten to
conform to the practices recommended in RFC 5226.
o The material formerly in Appendix A has been updated and o The material formerly in Appendix A has been updated and
shortened and has been moved to Appendix B. shortened and has been moved to Appendix B.
o An Appendix A on GML mapping has been added. o An Appendix A on GML mapping has been added.
o Appendix C has been added, providing an example of uncertainty o Appendix C has been added, providing an example of uncertainty
encoding. encoding.
o Appendix D has been added, detailing the changes from RFC 3825. 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
John Schnizlein
EMail: john@schnizlein.org
Marc Linsner Marc Linsner
Cisco Systems Cisco Systems
Marco Island, FL 34145 USA Marco Island, FL 34145 USA
USA USA
EMail: marc.linsner@cisco.com EMail: marc.linsner@cisco.com
Martin Thomson Martin Thomson
Andrew Andrew Corporation
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
EMail: martin.thomson@andrew.com EMail: martin.thomson@andrew.com
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 USA Redmond, WA 98052 USA
 End of changes. 67 change blocks. 
166 lines changed or deleted 267 lines changed or added

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