diff options
Diffstat (limited to 'doc/rfc/rfc6225.txt')
| -rw-r--r-- | doc/rfc/rfc6225.txt | 2019 |
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc6225.txt b/doc/rfc/rfc6225.txt new file mode 100644 index 0000000..74ab9f1 --- /dev/null +++ b/doc/rfc/rfc6225.txt @@ -0,0 +1,2019 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Polk +Request for Comments: 6225 M. Linsner +Obsoletes: 3825 Cisco Systems +Category: Standards Track M. Thomson +ISSN: 2070-1721 Andrew Corporation + B. Aboba, Ed. + Microsoft Corporation + July 2011 + + + Dynamic Host Configuration Protocol Options for + Coordinate-Based Location Configuration Information + +Abstract + + This document specifies Dynamic Host Configuration Protocol options + (both DHCPv4 and DHCPv6) for the coordinate-based geographic location + of the client. The Location Configuration Information (LCI) includes + Latitude, Longitude, and Altitude, with resolution or uncertainty + indicators for each. Separate parameters indicate the reference + datum for each of these values. This document obsoletes RFC 3825. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6225. + + + + + + + + + + + + + + + + +Polk, et al. Standards Track [Page 1] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Polk, et al. Standards Track [Page 2] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................4 + 1.2. Resolution and Uncertainty .................................4 + 2. DHCP Option Formats .............................................6 + 2.1. DHCPv6 GeoLoc Option .......................................6 + 2.2. DHCPv4 Options .............................................8 + 2.3. Latitude and Longitude Fields .............................11 + 2.4. Altitude ..................................................14 + 2.5. Datum .....................................................16 + 3. Security Considerations ........................................17 + 4. IANA Considerations ............................................17 + 4.1. DHCP Options ..............................................17 + 4.2. Altitude Type Registry ....................................18 + 4.3. Datum Registry ............................................18 + 4.4. GeoLoc Option Version Registry ............................19 + 5. Acknowledgments ................................................20 + 6. References .....................................................20 + 6.1. Normative References ......................................20 + 6.2. Informative References ....................................21 + Appendix A. GML Mapping ...........................................23 + A.1. GML Templates ............................................23 + Appendix B. Calculations of Resolution ............................27 + B.1. Location Configuration Information of "White House" + (Example 1) ..............................................27 + B.2. Location Configuration Information of "Sears Tower" + (Example 2) ..............................................29 + Appendix C. Calculations of Uncertainty ...........................30 + C.1. Location Configuration Information of "Sydney Opera + House" (Example 3) .......................................30 + Appendix D. Changes from RFC 3825 .................................34 + +1. Introduction + + The physical location of a network device has a range of + applications. In particular, emergency telephony applications rely + on knowing the location of a caller in order to determine the correct + emergency center. + + The location of a device can be represented either in terms of + geospatial (or geodetic) coordinates, or as a civic address. + Different applications may be more suited to one form of location + information; therefore, both the geodetic and civic forms may be used + simultaneously. + + + + + + +Polk, et al. Standards Track [Page 3] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + This document specifies Dynamic Host Configuration Protocol v4 + (DHCPv4) [RFC2131] and DHCPv6 [RFC3315] options for the coordinate- + based geographic location of the client, to be provided by the + server. "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) + Option for Civic Addresses Configuration Information" [RFC4776] + specifies DHCP options for civic addresses. + + The geodetic coordinate options defined in this document and the + civic address options defined in RFC 4776 [RFC4776] enable a DHCP + client to obtain its location. For example, a wired Ethernet host + might use these options for location determination. In this case, + the location information could be derived from a wiremap by the DHCP + server, using the Circuit ID Relay Agent Information Option (RAIO) + defined (as Sub-Option 1) in RFC 3046 [RFC3046]. The DHCP server + could correlate the Circuit ID with the geographic location where the + identified circuit terminates (such as the location of the wall + jack). + + The mechanism defined here may also be utilized to provide location + to wireless hosts. DHCP relay agent sub-options (RAIO) [RFC3046] + provide one method a DHCP server might use to perform host location + determination. Currently, the relay agent sub-options do not include + data sets required for device-level location determination of + wireless hosts. In cases where the DHCP server uses RAIO for + location determination, a wireless host can use this mechanism to + discover the location of the radio access point, or the area of + coverage for the radio access point. + + An important feature of this specification is that after the relevant + DHCP exchanges have taken place, the location information is stored + on the end device rather than somewhere else, where retrieving it + might be difficult in practice. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2. Resolution and Uncertainty + + The DHCP options defined in this document include fields quantifying + the resolution or uncertainty associated with a target location. No + inferences relating to privacy policies can be drawn from either + uncertainty or resolution values. + + + + + + +Polk, et al. Standards Track [Page 4] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + As utilized in this document, resolution refers to the accuracy of a + reported location, as expressed by the number of valid bits in each + of the Latitude, Longitude, and Altitude fields. + + The Latitude (LaRes), Longitude (LoRes), and Altitude (AltRes) + Resolution fields are encoded as 6-bit, unsigned integer values. In + the DHCPv4 GeoConf Option 123, the LaRes, LoRes, and AltRes fields + are used to encode the number of bits of resolution. The resolution + sub-fields accommodate the desire to easily adjust the precision of a + reported location. Contents beyond the claimed resolution MAY be + randomized to obscure greater precision that might be available. + + In the context of location technology, uncertainty is a + quantification of errors. Any method for determining location is + subject to some sources of error; uncertainty describes the amount of + error that is present. Uncertainty might be the coverage area of a + wireless transmitter, the extent of a building, or a single room. + + Uncertainty is usually represented as an area within which the target + is located. In this document, each of the three axes can be assigned + an uncertainty value. In effect, this describes a rectangular prism, + which may be used as a coarse representation of a more complex shape + that fits within it. See Section 2.3.2 for more detail on the + correspondence between shapes and uncertainty. + + When representing locations from sources that can quantify + uncertainty, the goal is to find the smallest possible rectangular + prism that this format can describe. This is achieved by taking the + minimum and maximum values on each axis and ensuring that the final + encoding covers these points. This increases the region of + uncertainty, but ensures that the region that is described + encompasses the target location. + + The DHCPv4 option formats defined in this document support resolution + and uncertainty parameters. The DHCPv4 GeoConf Option 123 includes a + resolution parameter for each of the dimensions of location. Since + this resolution parameter need not apply to all dimensions equally, a + resolution value is included for each of the three location elements. + The DHCPv4 GeoLoc Option 144 as well as the DHCPv6 GeoLoc Option 63 + format utilize an uncertainty parameter. + + Appendix A describes the mapping of DHCP option values to the + Geography Markup Language (GML). Appendix B of this document + provides examples showing the calculation of resolution values. + Appendix C provides an example demonstrating calculation of + uncertainty values. + + + + + +Polk, et al. Standards Track [Page 5] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + Since the Presence Information Data Format Location Object (PIDF-LO) + [RFC4119] [RFC5491] is used to convey location and the associated + uncertainty within an emergency call [Convey], a mechanism is needed + to convert the information contained within the DHCPv4 and DHCPv6 + options to PIDF-LO. This document describes the following + conversions: + + o DHCPv4 GeoConf Option 123 to PIDF-LO + + o DHCPv4 GeoLoc Option 144 and DHCPv6 GeoLoc Option 63 to PIDF-LO + + o PIDF-LO to DHCP GeoLoc Option 144 and DHCPv6 GeoLoc Option 63 + + Conversion to PIDF-LO does not increase uncertainty; conversion from + PIDF-LO to the DHCPv4 GeoLoc Option 144 and the DHCPv6 GeoLoc Option + 63 increases uncertainty by less than a factor of 2 in each + dimension. Since it is not possible to translate an arbitrary + PIDF-LO to the DHCP GeoConf Option 123 with a bounded increase in + uncertainty, the conversion is not specified. + +2. DHCP Option Formats + + This section defines the format for the DHCPv4 and DHCPv6 options. + These options utilize a similar format, differing primarily in the + option code. + +2.1. DHCPv6 GeoLoc Option + + The format of the DHCPv6 [RFC3315] GeoLoc Option is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option Code (63) | OptLen | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LatUnc | Latitude + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Lat (cont'd) | LongUnc | Longitude + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Longitude (cont'd) | AType | AltUnc | Altitude + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Altitude (cont'd) |Ver| Res |Datum| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code: 16 bits. The code for the DHCP Option Code (63). + + OptLen: Option Length. For version 1, the option length is 16. + + + + +Polk, et al. Standards Track [Page 6] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + LatUnc: 6 bits. When the Ver field = 1, this field represents + latitude uncertainty. The contents of this field are + undefined for other values of the Ver field. + + 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: 6 bits. When the Ver field = 1, this field represents + longitude uncertainty. The contents of this field are + undefined for other values of the Ver field. + + 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: 4 bits. Altitude Type, defined in Section 2.4. + + AltUnc: 6 bits. When the Ver field = 1, this field represents + altitude uncertainty. The contents of this field are + undefined for other values of the Ver field. + + Altitude: A 30-bit value defined by the AType field, described in + Section 2.4. + + Ver: The Ver field is 2 bits, providing for four potential + versions. This specification defines the behavior of + version 1. The Ver field is always located at the same + offset from the beginning of the option, regardless of + the version in use. DHCPv6 clients implementing this + specification MUST support receiving version 1 responses. + DHCPv6 servers implementing this specification MUST send + version 1 responses. + + Res: 3 bits. The Res field is reserved. These bits have been + used by [IEEE-802.11y], but are not defined within this + specification. + + Datum: 3 bits. The Map Datum used for the coordinates given in + this option. + + + + + + + + + + + +Polk, et al. Standards Track [Page 7] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + +2.2. DHCPv4 Options + +2.2.1. DHCPv4 GeoConf Option + + The format of the DHCPv4 GeoConf Option is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code 123 | Length | LaRes | Latitude + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Latitude (cont'd) | LoRes | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Longitude | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AType | AltRes | Altitude + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Alt.(cont'd) | Res |Datum| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code: 8 bits. The code for the DHCPv4 GeoConf Option (123). + + Length: 8 bits. The length of the option, in octets. + The option length is 16. + + LaRes: 6 bits. This field represents latitude resolution. + + Latitude: A 34-bit fixed-point value consisting of 9 bits of signed + integer and 25 bits of fraction, interpreted as described + in Section 2.3. + + LoRes: 6 bits. This field represents longitude resolution. + + Longitude: A 34-bit fixed-point value consisting of 9 bits of signed + integer and 25 bits of fraction, interpreted as described + in Section 2.3. + + AType: 4 bits. Altitude Type, defined in Section 2.4. + + AltRes: 6 bits. This field represents altitude resolution. + + Altitude: A 30-bit value defined by the AType field, described in + Section 2.4. + + + + + + + + +Polk, et al. Standards Track [Page 8] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + Res: 5 bits. The Res field is reserved. These bits have been + used by IEEE 802.11y [IEEE-802.11y], but are not defined + within this specification. + + Datum: 3 bits. The Map Datum used for the coordinates given in + this option. + +2.2.2. DHCPv4 GeoLoc Option + + The format of the DHCPv4 GeoLoc Option is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code 144 | Length | LatUnc | Latitude + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Latitude (cont'd) | LongUnc | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Longitude | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AType | AltUnc | Altitude + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Alt.(cont'd) |Ver| Res |Datum| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code: 8 bits. The code for the DHCPv4 GeoLoc Option (144). + + Length: 8 bits. The length of the option, in octets. + For version 1, the option length is 16. + + LatUnc: 6 bits. When the Ver field = 1, this field represents + latitude uncertainty. The contents of this field are + undefined for other values of the Ver field. + + 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: 6 bits. When the Ver field = 1, this field represents + longitude uncertainty. The contents of this field are + undefined for other values of the Ver field. + + 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: 4 bits. Altitude Type, defined in Section 2.4. + + + + +Polk, et al. Standards Track [Page 9] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + AltUnc: 6 bits. When the Ver field = 1, this field represents + altitude uncertainty. The contents of this field are + undefined for other values of the Ver field. + + Altitude: A 30-bit value defined by the AType field, described in + Section 2.4. + + Ver: The Ver field is 2 bits, providing for four potential + versions. This specification defines the behavior of + version 1. The Ver field is always located at the same + offset from the beginning of the option, regardless of + the version in use. + + Res: 3 bits. The Res field is reserved. These bits have been + used by [IEEE-802.11y], but are not defined within this + specification. + + Datum: 3 bits. The Map Datum used for the coordinates given in + this option. + +2.2.3. Option Support + +2.2.3.1. Client Support + + DHCPv4 clients implementing this specification MUST support receiving + the DHCPv4 GeoLoc Option 144 (version 1), and MAY support receiving + the DHCPv4 GeoConf Option 123 (originally defined in RFC 3825 + [RFC3825]). + + DHCPv4 clients request the DHCPv4 server to send GeoConf Option 123, + GeoLoc Option 144, or both via inclusion of the Parameter Request + List option. As noted in Section 9.8 of RFC 2132 [RFC2132]: + + This option is used by a DHCP client to request values for + specified configuration parameters. The list of requested + parameters is specified as n octets, where each octet is a valid + DHCP option code as defined in this document. + + The client MAY list the options in order of preference. The DHCP + server is not required to return the options in the requested + order, but MUST try to insert the requested options in the order + requested by the client. + + + + + + + + + +Polk, et al. Standards Track [Page 10] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + When DHCPv4 and DHCPv6 clients implementing this specification do not + understand a datum value, they MUST assume a World Geodetic System + 1984 (WGS84) [WGS84] datum (European Petroleum Survey Group (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.3.2. Server Option Selection + + A DHCPv4 server implementing this specification MUST support sending + GeoLoc Option 144 version 1 and SHOULD support sending GeoConf Option + 123 in responses. + + A DHCPv4 server that provides location information SHOULD honor the + Parameter Request List included by the DHCPv4 client in order to + decide whether to send GeoConf Option 123, GeoLoc Option 144, or both + in the Response. + +2.3. Latitude and Longitude Fields + + The latitude and longitude values in this specification are encoded + as 34-bit, two's complement, fixed-point values with 9 integer bits + and 25 fractional bits. The exact meaning of these values is + determined by the datum; the description in this section applies to + the datums defined in this document. This document uses the same + definition for all datums it specifies. + + When encoding, latitude and longitude values are rounded to the + nearest 34-bit binary representation. This imprecision is considered + acceptable for the purposes to which this form is intended to be + applied and is ignored when decoding. + + Positive latitudes are north of the equator, and negative latitudes + are south of the equator. Positive longitudes are east of the Prime + Meridian, and negative (two's complement) longitudes are west of the + Prime Meridian. + + Within the coordinate reference systems defined in this document + (Datum values 1-3), longitude values outside the range of -180 to 180 + decimal degrees or latitude values outside the range of -90 to 90 + degrees MUST be considered invalid. Server implementations SHOULD + prevent the entry of invalid values within the selected coordinate + reference system. Location consumers MUST ignore invalid location + coordinates and SHOULD log errors related to invalid location. + + + + + + +Polk, et al. Standards Track [Page 11] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + +2.3.1. Latitude and Longitude Resolution + + In the DHCPv4 GeoConf Option 123, the LaRes value encodes the number + of high-order latitude bits that MUST be considered valid. Any bits + entered to the right of this limit MUST NOT be considered valid and + might be purposely false, or zeroed by the sender. The examples in + Appendix B illustrate that a smaller value in the resolution field + increases the area within which the device is located. A value of 2 + in the LaRes field indicates a precision of no greater than 1/6th + that of the globe (see the first example of Appendix B). A value of + 34 in the LaRes field indicates a precision of about 3.11 mm in + latitude at the equator. + + In the DHCPv4 GeoConf Option 123, the LoRes value encodes the number + of high-order longitude bits that MUST be considered valid. Any bits + entered to the right of this limit MUST NOT be considered valid and + might be purposely false, or zeroed by the sender. A value of 2 in + the LoRes field indicates precision of no greater than 1/6th that of + the globe (see the first example of Appendix B). A value of 34 in + the LoRes field indicates a precision of about 2.42 mm in longitude + (at the equator). Because lines of longitude converge at the poles, + the distance is smaller (better precision) for locations away from + the equator. + +2.3.2. Latitude and Longitude Uncertainty + + In the DHCPv6 GeoLoc Option 63 and the DHCPv4 GeoLoc Option 144, the + Latitude and Longitude Uncertainty fields (LatUnc and LongUnc) + quantify the amount of uncertainty in each of the latitude and + longitude values, respectively. A value of 0 is reserved to indicate + that the uncertainty is unknown; values greater than 34 are reserved. + + A point within the region of uncertainty is selected to be the + encoded point; the centroid of the region is often an appropriate + choice. The value for uncertainty is taken as the distance from the + selected point to the furthest extreme of the region of uncertainty + on that axis. This is demonstrated in the figure below, which shows + a two-dimensional polygon that is projected on each axis. In the + figure, "X" marks the point that is selected; the ranges marked with + "U" indicate the uncertainty. + + + + + + + + + + + +Polk, et al. Standards Track [Page 12] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + ___ ___________ + ^ | / | + | | / | + | | / | + U | / | + | | ( | + V | | | + --X | X | + | | `---------. + | | | + | | | + | | | + - `-------------------------' + + |---------X---------------| + |<------U------>| + + Key + --- + + V, ^ = vertical arrows, delimiting the vertical uncertainty range. + <> = horizontal arrows, delimiting the horizontal uncertainty + range. + + Uncertainty applies to each axis independently. + + The amount of uncertainty can be determined from the encoding by + taking 2 to the power of 8, less the encoded value, as is shown in + the following formula, where "x" is the encoded integer value: + + uncertainty = 2 ^ ( 8 - x ) + + The result of this formula is expressed in degrees of latitude or + longitude. The uncertainty is added to the base latitude or + longitude value to determine the maximum value in the uncertainty + range; similarly, the uncertainty is subtracted from the base value + to determine the minimum value. Note that because lines of longitude + converge at the poles, the actual distance represented by this + uncertainty changes with the distance from the equator. + + If the maximum or minimum latitude values derived from applying + uncertainty are outside the range of -90 to +90, these values are + trimmed to within this range. If the maximum or minimum longitude + values derived from applying uncertainty are outside the range of + -180 to +180, then these values are normalized to this range by + adding or subtracting 360 as necessary. + + + + + +Polk, et al. Standards Track [Page 13] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + The encoded value is determined by subtracting the next highest whole + integer value for the base 2 logarithm of uncertainty from 8, as is + shown by the following formula, where uncertainty is the midpoint of + the known range less the lower bound of that range: + + x = 8 - ceil( log2( uncertainty ) ) + + Note that the result of encoding this value increases the range of + uncertainty to the next available power of two; subsequent repeated + encodings and decodings do not change the value. Only increasing + uncertainty means that the associated confidence does not have to + decrease. + +2.4. Altitude + + How the altitude value is interpreted depends on the Altitude Type + (AType) value and the selected datum. Three Altitude Type values are + defined in this document: unknown (0), meters (1), and floors (2). + +2.4.1. No Known Altitude (AType = 0) + + In some cases, the altitude of the location might not be provided. + An Altitude Type value of zero indicates that the altitude is not + given to the client. In this case, the Altitude and Altitude + Uncertainty fields can contain any value and MUST be ignored. + +2.4.2. Altitude in Meters (AType = 1) + + If the Altitude Type has a value of one, altitude is measured in + meters, in relation to the zero set by the vertical datum. For AType + = 1, the altitude value is expressed as a 30-bit, fixed-point, two's + complement integer with 22 integer bits and 8 fractional bits. + +2.4.3. Altitude in Floors (AType = 2) + + A value of two for Altitude Type indicates that the altitude value is + measured in floors. Since altitude in meters may not be known within + a building, a floor indication may be more useful. For AType = 2, + the altitude value is expressed as a 30-bit, fixed-point, two's + complement integer with 22 integer bits and 8 fractional bits. + + This value is relevant only in relation to a building; the value is + relative to the ground level of the building. Floors located below + ground level are represented by negative values. In some buildings, + it might not be clear which floor is at ground level, or an + intermediate floor might be hard to identify as such. Determining + + + + + +Polk, et al. Standards Track [Page 14] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + what floor is at ground level and what constitutes a sub-floor as + opposed to a naturally numbered floor is left to local + interpretation. + + Larger values represent floors that are farther away from floor 0 + such that: + + - if positive, the floor value is farther above 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-floors, such as mezzanine levels. Example: a mezzanine between + floor 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 of 4.5 and 4.75. + +2.4.4. Altitude Resolution + + In the DHCPv4 GeoConf Option 123, the altitude resolution (AltRes) + value encodes the number of high-order altitude bits that should be + considered valid. Values above 30 (decimal) are undefined and + reserved. + + If the Altitude Type value is one (AType = 1), an AltRes value of 0.0 + would indicate an unknown altitude. The most precise altitude would + have an AltRes value of 30. Many values of AltRes would obscure any + variation due to vertical datum differences. + + 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 + 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 + outside a building, and represents ground level at the given latitude + and longitude. + +2.4.5. Altitude Uncertainty + + In the DHCPv6 GeoLoc Option 63 or the DHCPv4 GeoLoc Option 144, the + AltUnc value quantifies the amount of uncertainty in the altitude + value. As with LatUnc and LongUnc, a value of 0 for AltUnc is + reserved to indicate that altitude uncertainty is not known; values + above 30 are also reserved. Altitude uncertainty only applies to + Altitude Type 1. + + + + + + + +Polk, et al. Standards Track [Page 15] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + The amount of altitude uncertainty can be determined by the following + formula, where x is the encoded integer value: + + Uncertainty = 2 ^ ( 21 - x ) + + This value uses the same units as the associated altitude. + + Similarly, a value for the encoded integer value can be derived by + the following formula: + + x = 21 - ceil( log2( uncertainty ) ) + +2.5. Datum + + The Datum field determines how coordinates are organized and related + to the real world. Three datums are defined in this document, based + on the definitions in [OGP.Geodesy]: + + 1: WGS84 (Latitude, Longitude, Altitude): The World Geodetic System + 1984 [WGS84] coordinate reference system. + + This datum is identified by the European Petroleum Survey Group + (EPSG)/International Association of Oil & Gas Producers (OGP) with + the code 4979, or by the URN "urn:ogc:def:crs:EPSG::4979". + Without altitude, this datum is identified by the EPSG/OGP code + 4326 and the URN "urn:ogc:def:crs:EPSG::4326". + + 2: NAD83 (Latitude, Longitude) + NAVD88: This datum uses a + combination of the North American Datum 1983 (NAD83) for + horizontal (Latitude and Longitude) values, plus the North + American Vertical Datum of 1988 (NAVD88) vertical datum. + + This datum is used for referencing location on land (not near + tidal water) within North America. + + NAD83 is identified by the EPSG/OGP code of 4269, or the URN + "urn:ogc:def:crs:EPSG::4269". NAVD88 is identified by the EPSG/ + OGP code of 5703, or the URN "urn:ogc:def:crs:EPSG::5703". + + 3: NAD83 (Latitude, Longitude) + MLLW: This datum uses a combination + of the North American Datum 1983 (NAD83) for horizontal (Latitude + and Longitude) values, plus the Mean Lower Low Water (MLLW) + vertical datum. + + This datum is used for referencing location on or near tidal water + within North America. + + + + + +Polk, et al. Standards Track [Page 16] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + 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 + or URN. + + All hosts MUST support the WGS84 datum (Datum 1). + +3. Security Considerations + + Geopriv requirements (including security requirements) are discussed + in "Geopriv Requirements" [RFC3693]. A threat analysis is provided + in "Threat Analysis of the Geopriv Protocol" [RFC3694]. + + Since there is no privacy protection for DHCP messages, an + eavesdropper who can monitor the link between the DHCP server and + requesting client can discover this LCI. + + To minimize the unintended exposure of location information, the LCI + option SHOULD be returned by DHCP servers only when the DHCP client + has included this option in its 'parameter request list' (Section 3.5 + of [RFC2131], Section 9.8 of [RFC2132]). + + Where critical decisions might be based on the value of this option, + DHCP authentication as defined in "Authentication for DHCP Messages" + [RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" + [RFC3315] SHOULD be used to protect the integrity of the DHCP + options. + + Link-layer confidentiality and integrity protection may also be + employed to reduce the risk of location disclosure and tampering. + +4. IANA Considerations + +4.1. DHCP Options + + This document defines the DHCPv6 GeoLoc Option (see Section 2.1), + which has been assigned a DHCPv6 option code of 63 per [RFC3315]: + + Value Description Reference + ---- ------------------ ---------- + 63 OPTION_GEOLOCATION RFC 6225 + + 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. + + + + + + + +Polk, et al. Standards Track [Page 17] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + This document also defines the DHCPv4 GeoLoc Option (see + Section 2.2.2), which has been assigned a DHCPv4 option code of 144 + per [RFC2132] [RFC2939]: + + Data + Tag Name Length Meaning Reference + ---- ---- ------ ------- --------- + 144 GeoLoc 16 Geospatial Location RFC 6225 + with Uncertainty + +4.2. Altitude Type Registry + + IANA has created and now maintains 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 0 - 2 are assigned. Values 3 - 15 are + Unassigned [RFC5226]. + + 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 6225 | + | 1 | Altitude in meters | RFC 6225 | + | 2 | Altitude in floors | RFC 6225 | + | 3-15 | Unassigned | | + +------+---------------------+--------------+ + +4.3. Datum Registry + + IANA has created and now maintains the Datum registry following the + guidelines below. + + The registry consists of three values: Datum, Description, and + Reference. These are described below. + + + +Polk, et al. Standards Track [Page 18] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + Datum: An integer, refers to the value used in the DHCPv4 GeoConf and + the DHCPv4 and DHCPv6 GeoLoc options described in this document. + Value 0 is Reserved. Values 1 - 3 are assigned. Values 4 - 7 are + Unassigned [RFC5226]. + + 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-bit values and the respective 6-bit uncertainties are + interpreted. + + Initial values are given below; new assignments are to be made + following the "Standards Action" policies [RFC5226]. + + +------+----------------------------------------+--------------+ + | # | Description | Reference | + +------+----------------------------------------+--------------+ + | 0 | Reserved | RFC 6225 | + +------+----------------------------------------+--------------+ + | 1 | Vertical datum WGS 84 defined by EPSG | RFC 6225 | + | | CRS Code 4327 | | + +------+----------------------------------------+--------------+ + | 2 | Vertical datum NAD83 defined by EPSG | RFC 6225 | + | | CRS Code 4269 with North American | | + | | Vertical Datum of 1988 (NAVD88) | | + +------+----------------------------------------+--------------+ + | 3 | Vertical datum NAD83 defined by EPSG | RFC 6225 | + | | CRS Code 4269 with Mean Lower Low Water| | + | | (MLLW) as associated vertical datum | | + +------+----------------------------------------+--------------+ + | 4-7 | Unassigned | | + +------+----------------------------------------+--------------+ + +4.4. GeoLoc Option Version Registry + + IANA has created and now maintains the GeoLoc Option Version registry + following the guidelines below. + + The registry consists of three values: GeoLoc Option Version, + Description, and Reference. These are described below. + + GeoLoc Option Version: An integer; refers to the version used in the + DHCPv4 and DHCPv6 GeoLoc options described in this document. + Value 0 is Reserved. Value 1 has been assigned. Values 2 - 3 are + Unassigned [RFC5226]. + + + + +Polk, et al. Standards Track [Page 19] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + Description: The description of the version described by this code. + + Reference: The reference to the document that describes the Version + code. + + Initial values are given below; new assignments are to be made + following the "Standards Action" policies [RFC5226]. + + +------+---------------------------------------+--------------+ + | # | Description | Reference | + +------+---------------------------------------+--------------+ + | 0 | Reserved | RFC 6225 | + +------+---------------------------------------+--------------+ + | 1 | Implementations utilizing uncertainty | RFC 6225 | + | | parameters for both DHCPv4 and DHCPv6 | | + | | GeoLoc options | | + +------+---------------------------------------+--------------+ + | 2-3 | Unassigned | | + +------+---------------------------------------+--------------+ + +5. Acknowledgments + + The authors would like to thank Randall Gellens, Patrik Falstrom, + Ralph Droms, Ted Hardie, Jon Peterson, Robert Sparks, Nadine Abbott, + and Mykyta Yevstifeyev for their inputs and constructive comments + regarding this document. Additionally, the authors would like to + thank Greg Troxel for the education on vertical datums, as well as + Carl Reed. Thanks to Richard Barnes for his contribution on GML + mapping for resolution. + +6. References + +6.1. Normative References + + [EPSG] European Petroleum Survey Group, + <http://www.epsg.org/> and + <http://www.epsg-registry.org/>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP + Vendor Extensions", RFC 2132, March 1997. + + + + + +Polk, et al. Standards Track [Page 20] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + [RFC2939] Droms, R., "Procedures and IANA Guidelines for + Definition of New DHCP Options and Message Types", + BCP 43, RFC 2939, September 2000. + + [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication + for DHCP Messages", RFC 3118, June 2001. + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., + Perkins, C., and M. Carney, "Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, + July 2003. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 5226, May 2008. + + [WGS84] US National Imagery and Mapping Agency, "Department of + Defense (DoD) World Geodetic System 1984 (WGS 84), + Third Edition", NIMA TR8350.2, January 2000, + <https://www1.nga.mil/PRODUCTSSERVICES/ + GEODESYGEOPHYSICS/WORLDGEODETICSYSTEM/ + Pages/default.aspx> and + <http://www.ngs.noaa.gov/faq.shtml#WGS84>. + +6.2. Informative References + + [Convey] Polk, J., Rosen, B., and J. Peterson, "Location + Conveyance for the Session Initiation Protocol", Work + in Progress, May 2011. + + [GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape + Application Schema for use by the Internet Engineering + Task Force (IETF)", Candidate OpenGIS Implementation + Specification 06-142, Version: 0.0.9, December 2006. + + [IEEE-802.11y] IEEE Standard for Information technology - + Telecommunications and information exchange between + systems - Local and metropolitan area networks - + Specific requirements - Part 11: Wireless LAN Medium + Access Control (MAC) and Physical Layer (PHY) + specifications Amendment 3: 3650-3700 MHz Operation in + USA, November 2008. + + [NENA] National Emergency Number Association (NENA), NENA + Technical Information Document on Model Legislation + Enhanced 911 for Multi-Line Telephone Systems, + <www.nena.org>. + + + + +Polk, et al. Standards Track [Page 21] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + [OGC-GML3.1.1] Portele, C., Cox, S., Daisy, P., Lake, R., and A. + Whiteside, "Geography Markup Language (GML) 3.1.1", + OGC 03-105r1, July 2003. + + [OGP.Geodesy] International Association of Oil & Gas Producers (OGP) + Geodesy Resources, Geomatics Committee, + <http://info.ogp.org.uk/geodesy/>. + + [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", + RFC 3046, January 2001. + + [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., + and J. Polk, "Geopriv Requirements", RFC 3693, + February 2004. + + [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, + "Threat Analysis of the Geopriv Protocol", RFC 3694, + February 2004. + + [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic + Host Configuration Protocol Option for Coordinate- + based Location Configuration Information", RFC 3825, + July 2004. + + [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location + Object Format", RFC 4119, December 2005. + + [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol + (DHCPv4 and DHCPv6) Option for Civic Addresses + Configuration Information", RFC 4776, November 2006. + + [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic + Location Format for Presence Information Data Format + Location Object (PIDF-LO)", RFC 5139, February 2008. + + [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, + "GEOPRIV Presence Information Data Format Location + Object (PIDF-LO) Usage Clarification, Considerations, + and Recommendations", RFC 5491, March 2009. + + + + + + + + + + + + +Polk, et al. Standards Track [Page 22] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + +Appendix A. GML Mapping + + The GML representation of a decoded DHCP option depends on what + fields are specified. The DHCP format for location logically + describes a geodetic prism, rectangle, or point, depending on whether + altitude and uncertainty values are provided. In the absence of + uncertainty information, the value decoded from the DHCP form can be + expressed as a single point; this is true regardless of whether the + version 0 or version 1 interpretations of the uncertainty fields are + used. If the point includes altitude, it uses a three-dimensional + Coordinate Reference System (CRS); otherwise, it uses a two- + dimensional CRS. If all fields are included along with uncertainty, + the shape described is a rectangular prism. Note that this is + necessary given that uncertainty for each axis is provided + independently. + + If altitude or altitude uncertainty (AltUnc) is not specified, the + shape is described as a rectangle using the "gml:Polygon" shape. If + altitude is available, a three-dimensional CRS is used; otherwise, a + two-dimensional CRS is used. + + For Datum values of 2 or 3 (NAD83), there is no available CRS URN + that covers three-dimensional coordinates. By necessity, locations + described in these datums can be represented by two-dimensional + shapes only; that is, either a two-dimensional point or a polygon. + + If the Altitude Type is 2 (floors), then this value can be + represented using a civic address object [RFC5139] that is presented + alongside the geodetic object. + + This Appendix describes how the location value encoded in DHCP format + for geodetic location can be expressed in GML. The mapping is valid + for the DHCPv6 GeoLoc Option as well as both of the DHCPv4 GeoConf + and GeoLoc options, and for the currently defined datum values (1, 2, + and 3). Further version or datum definitions should provide similar + mappings. + + These shapes can be mapped to GML by first computing the bounds that + are described using the coordinate and uncertainty fields, then + encoding the result in a GML Polygon or Prism shape. + +A.1. GML Templates + + 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 + following form (where $value$ indicates a value computed from the + DHCP option as described below): + + + + +Polk, et al. Standards Track [Page 23] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979" + xmlns:gs="http://www.opengis.net/pidflo/1.0" + xmlns:gml="http://www.opengis.net/gml"> + <gs:base> + <gml:Polygon> + <gml:exterior> + <gml:LinearRing> + <gml:posList> + $lowLatitude$ $lowLongitude$ $lowAltitude$ + $lowLatitude$ $highLongitude$ $lowAltitude$ + $highLatitude$ $highLongitude$ $lowAltitude$ + $highLatitude$ $lowLongitude$ $lowAltitude$ + $lowLatitude$ $lowLongitude$ $lowAltitude$ + </gml:posList> + </gml:LinearRing> + </gml:exterior> + </gml:Polygon> + </gs:base> + <gs:height uom="urn:ogc:def:uom:EPSG::9001"> + $highAltitude - lowAltitude$ + </gs:height> + </gs:Prism> + + The Polygon shape is used if altitude is omitted or specified in + floors, or if either NAD83 datum is used (value 2 or 3). The + corresponding GML Polygon has the following form: + + <gml:Polygon srsName="$2D-CRS-URN$" + xmlns:gml="http://www.opengis.net/gml">> + <gml:exterior> + <gml:LinearRing> + <gml:posList> + $lowLatitude$ $lowLongitude$ + $lowLatitude$ $highLongitude$ + $highLatitude$ $highLongitude$ + $highLatitude$ $lowLongitude$ + $lowLatitude$ $lowLongitude$ + </gml:posList> + </gml:LinearRing> + </gml:exterior> + </gml:Polygon> + + 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". + If the datum is NAD83 (value 2 or 3), then the 2D-CRS-URN is + "urn:ogc:def:crs:EPSG::4269". + + + + + +Polk, et al. Standards Track [Page 24] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + 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 + (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 + after each of the points above, and the srsName attribute is set to + the three-dimensional WGS84 CRS, namely "urn:ogc:def:crs:EPSG::4979". + + A simple point shape is used if either latitude uncertainty (LatUnc) + or longitude uncertainty (LongUnc) is not specified. With altitude, + this uses a three-dimensional CRS; otherwise, it uses a two- + dimensional CRS. + + <gml:Point srsName="$CRS-URN$" + xmlns:gml="http://www.opengis.net/gml"> + <gml:pos>$Latitude$ $Longitude$ $[Altitude]$</gml:pos> + </gml:Point> + +A.1.1. Finding Low and High Values Using Uncertainty Fields + + For the DHCPv4 GeoConf Option 123, resolution fields are used (LaRes, + LoRes, AltRes), indicating how many bits of a value contain + information. Any bits beyond those indicated can be either zero or + one. + + For the DHCPv6 GeoLoc Option 63 and DHCPv4 GeoLoc Option 144, the + LatUnc, LongUnc, and AltUnc fields indicate uncertainty distances, + denoting the bounds of the location region described by the DHCP + location object. + + The two sections below describe how to compute the latitude, + longitude, and altitude bounds (e.g., $lowLatitude$, $highAltitude$) + in the templates above. The first section describes how these bounds + are computed in the "resolution encoding" (DHCPv4 GeoConf + Option 123), while the second section addresses the "uncertainty + encoding" (DHCPv6 GeoLoc Option 63 and DHCPv4 GeoLoc Option 144). + +A.1.1.1. Resolution Encoding + + 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 + lowest possible value. The highest possible value can be found + setting all bits to one. + + If the encoded value of latitude/longitude and resolution (LaRes, + LoRes) are treated as 34-bit unsigned integers, the following can be + used (where ">>" is a bitwise right shift, "&" is a bitwise AND, "~" + is a bitwise negation, and "|" is a bitwise OR). + + + + +Polk, et al. Standards Track [Page 25] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + mask = 0x3ffffffff >> resolution + lowvalue = value & ~mask + highvalue = value | mask + 1 + + Once these values are determined, the corresponding floating-point + numbers can be computed by dividing the values by 2^25 (since there + are 25 bits of fraction in the fixed-point representation). + + Alternatively, the lowest possible value can be found by using + resolution to determine the size of the range. This method has the + advantage that it operates on the decoded floating-point values. It + is equivalent to the first mechanism, to a possible error of 2^-25 + (2^-8 for altitude). + + scale = 2 ^ ( 9 - resolution ) + lowvalue = floor( value / scale ) * scale + highvalue = lowvalue + scale + + Altitude resolution (AltRes) uses the same process with different + constants. There are 22 whole bits in the altitude encoding (instead + of 9) and 30 bits in total (instead of 34). + +A.1.1.2. Uncertainty Encoding + + In the uncertainty encoding, the uncertainty fields (LongUnc/LatUnc) + directly represent the logarithms of uncertainty distances. So the + low and high bounds are computed by first computing the uncertainty + distances, then adding and subtracting these from the value provided. + If "uncertainty" is the unsigned integer value of the uncertainty + field and "value" is the value of the coordinate field: + + distance = 2 ^ (8 - uncertainty) + lowvalue = value - distance + highvalue = value + distance + + Altitude uncertainty (AltUnc in version 1) uses the same process with + different constants: + + distance = 2 ^ (21 - uncertainty) + lowvalue = value - distance + + + + + + + + + + + +Polk, et al. Standards Track [Page 26] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + +Appendix B. Calculations of Resolution + + The following examples for two different locations demonstrate how + the resolution values for latitude, longitude, and altitude (used in + DHCPv4 GeoConf Option 123) can be calculated. In both examples, the + geo-location values were derived from maps using the WGS84 map datum; + therefore, in these examples, the Datum field would have a value = 1 + (00000001, or 0x01). + +B.1. Location Configuration Information of "White House" (Example 1) + + The grounds of the White House in Washington D.C. (1600 Pennsylvania + 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 + 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 + inside a structure, we assume an altitude value of 15 meters, + interpolated from the US Geological survey map, Washington, + Washington West quadrangle. + + The address was NOT picked for any political reason and can easily be + found on the Internet or mapping software, but was picked as an + easily identifiable location on our planet. + + In this example, the requirement of emergency responders in North + America via their National Emergency Number Association (NENA) Model + Legislation [NENA] could be met by a LaRes value of 21 and a LoRes + value of 20. This would yield a geo-location that is latitude + 38.8984375 north to latitude 38.8988616 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 is very + close to the 7000 square feet requested by NENA. In this example, a + service provider could enforce that a device send location + configuration information with this minimum amount of resolution for + this particular location when calling emergency services. + + An approximate representation of this location might be provided + using the DHCPv4 GeoConf Option 123 encoding as follows: + + + + + + + + + + + + + +Polk, et al. Standards Track [Page 27] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . 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. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . Longitude (cont'd) | + .0 1 1 0 0 1 0 1 1 1 1 0 1 1 0 1 0 1 0 0 0 0 1 0 1 1 0 0 0 1 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AType | AltRes | Altitude . + |0 0 0 1|0 1 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . Alt (cont'd) | Res |Datum| + .0 0 0 0 0 0 0 0|0 0 0 0 0|0 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + In hexadecimal, this is 7B10484D CB986347 65ED42C4 1440000F 0001. + +B.1.1. Decoding Location Configuration Information with Resolution + + Decoding this option gives a latitude of 38.897647 (to 7 decimal + places) with 18 bits of resolution, a longitude of -77.0366000 with + 17 bits of resolution, an Altitude Type of meters with a value of 15 + and 17 bits of resolution, version 0 (resolution), and the WGS84 + datum. + + For the latitude value, 18 bits of resolution allow for values in the + range from 38.8964844 to 38.8984375. For the longitude value, 17 + bits of resolution allow for values in the range from -77.0390625 to + -77.0351563. Having 17 bits of resolution in the altitude allows for + values in the range from 0 to 32 meters. + +B.1.2. GML Representation of Decoded Location Configuration Information + + The following GML shows the value decoded in the previous example as + a point in a three-dimensional CRS: + + <gml:Point srsName="urn:ogc:def:crs:EPSG::4979" + xmlns:gml="http://www.opengis.net/gml"> + <gml:pos>38.897647 -77.0366 15</gml:pos> + </gml:Point> + + This representation ignores the values included in the resolution + parameters. If resolution values are provided, a rectangular prism + can be used to represent the location. + + + +Polk, et al. Standards Track [Page 28] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + The following example uses all of the decoded information from the + previous example: + + <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979" + xmlns:gs="http://www.opengis.net/pidflo/1.0" + xmlns:gml="http://www.opengis.net/gml"> + <gs:base> + <gml:Polygon> + <gml:exterior> + <gml:LinearRing> + <gml:posList> + 38.8964844 -77.0390625 0 + 38.8964844 -77.0351563 0 + 38.8984375 -77.0351563 0 + 38.8984375 -77.0390625 0 + 38.8964844 -77.0390625 0 + </gml:posList> + </gml:LinearRing> + </gml:exterior> + </gml:Polygon> + </gs:base> + <gs:height uom="urn:ogc:def:uom:EPSG::9001"> + 32 + </gs:height> + </gs:Prism> + +B.2. Location Configuration Information of "Sears Tower" (Example 2) + + Postal Address: + Sears Tower + 103rd Floor + 233 S. Wacker Dr. + Chicago, IL 60606 + + Viewing the Chicago area from the Observation Deck of the Sears + Tower: + + Latitude 41.87884 degrees North (or +41.87884 degrees) + Using two's complement, 34-bit fixed point, 25 bits of fraction + Latitude = 0x053c1f751, + Latitude = 0001010011110000011111011101010001 + Longitude 87.63602 degrees West (or -87.63602 degrees) + Using two's complement, 34-bit fixed point, 25 bits of fraction + Longitude = 0xf50ba5b97, + Longitude = 1101010000101110100101101110010111 + + Altitude 103 + + + + +Polk, et al. Standards Track [Page 29] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + In this example, we are inside a structure; therefore, we will assume + an altitude value of 103 to indicate the floor we are on. The + Altitude Type value is 2, indicating floors. The AltRes field would + indicate that all bits in the Altitude field are true, as we want to + accurately represent the floor of the structure where we are located. + + AltRes = 30, 0x1e, 011110 + AType = 2, 0x02, 000010 + Altitude = 103, 0x00006700, 000000000000000110011100000000 + + For the accuracy of the latitude and longitude, the best information + available to us was supplied by a generic mapping service that shows + a single geo-loc for all of the Sears Tower. Therefore, we are going + 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 + is latitude 41.8769531 to latitude 41.8789062 and extends from + -87.6367188 degrees to -87.6347657 degrees longitude. This is an + area of approximately 373412 square feet (713.3 ft. x 523.5 ft.). + +Appendix C. Calculations of Uncertainty + + The following example demonstrates how uncertainty values for + latitude, longitude, and altitude (LatUnc, LongUnc, and AltUnc used + in the DHCPv6 GeoLoc Option 63 as well as DHCPv4 GeoLoc Option 144) + can be calculated. + +C.1. Location Configuration Information of "Sydney Opera House" + (Example 3) + + This section describes an example of encoding and decoding the + geodetic DHCP Option. The textual results are expressed in GML + [OGC-GML3.1.1] form, suitable for inclusion in PIDF-LO [RFC4119]. + + These examples all assume a datum of WGS84 (datum = 1) and an + Altitude Type of meters (AType = 1). + +C.1.1. Encoding a Location into DHCP Geodetic Form + + This example draws a rough polygon around the Sydney Opera House. + This polygon consists of the following six points: + + 33.856625 S, 151.215906 E + 33.856299 S, 151.215343 E + 33.856326 S, 151.214731 E + 33.857533 S, 151.214495 E + 33.857720 S, 151.214613 E + 33.857369 S, 151.215375 E + + + + +Polk, et al. Standards Track [Page 30] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + The top of the building is 67.4 meters above sea level, and a + starting altitude of 0 meters above the WGS84 geoid is assumed. + + The first step is to determine the range of latitude and longitude + values. Latitude ranges from -33.857720 to -33.856299; longitude + ranges from 151.214495 to 151.215906. + + For this example, the point that is encoded is chosen by finding the + middle of each range, that is (-33.8570095, 151.2152005). This is + encoded as (1110111100010010010011011000001101, + 0100101110011011100010111011000011) in binary, or (3BC49360D, + 12E6E2EC3) in hexadecimal notation (with an extra 2 bits of leading + padding on each). Altitude is set at 33.7 meters, which is + 000000000000000010000110110011 (binary) or 000021B3 (hexadecimal). + + The latitude uncertainty (LatUnc) is given by inserting the + difference between the center value and the outer value into the + formula from Section 2.3.2. This gives: + + x = 8 - ceil( log2( -33.8570095 - -33.857720 ) ) + + The result of this equation is 18; therefore, the uncertainty is + encoded as 010010 in binary. + + Similarly, longitude uncertainty (LongUnc) is given by the formula: + + x = 8 - ceil( log2( 151.2152005 - 151.214495 ) ) + + The result of this equation is also 18, or 010010 in binary. + + Altitude uncertainty (AltUnc) uses the formula from Section 2.4.5: + + x = 21 - ceil( log2( 33.7 - 0 ) ) + + The result of this equation is 15, which is encoded as 001111 in + binary. + + Adding an Altitude Type of 1 (meters) and a Datum of 1 (WGS84), this + gives the following DHCPv4 GeoLoc Option 144 form: + + + + + + + + + + + + +Polk, et al. Standards Track [Page 31] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code (144) | 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. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . 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. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . 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| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . Alt (cont'd) |Ver| Res |Datum| + .1 0 1 1 0 0 1 1|0 1|0 0 0|0 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + In hexadecimal, this is 7B104BBC 49360D49 2E6E2EC3 13C00021 B341. + The DHCPv6 form only differs in the code and option length portion. + +C.1.2. Decoding a Location from DHCP Geodetic Form + + If receiving the binary form created in the previous section, this + section describes how that would be interpreted. The result is then + represented as a GML object, as defined in [GeoShape]. + + A latitude value of 1110111100010010010011011000001101 decodes to a + value of -33.8570095003 (to 10 decimal places). The longitude value + of 0100101110011011100010111011000011 decodes to 151.2152005136. + + Decoding Tip: If the raw values of latitude and longitude are placed + in integer variables, the actual value can be derived by the + following process: + + 1. If the highest order bit is set (i.e., the number is a two's + complement negative), then subtract 2 to the power of 34 (the + total number of bits). + + 2. Divide the result by 2 to the power of 25 (the number of + fractional bits) to determine the final value. + + The same principle can be applied when decoding altitude values, + except with different powers of 2 (30 and 8, respectively). + + + + + + +Polk, et al. Standards Track [Page 32] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + The latitude and longitude uncertainty are both 18, which gives an + uncertainty value of 0.0009765625 using the formula from + Section 2.3.2. Therefore, the decoded latitude is -33.8570095003 +/- + 0.0009765625 (or the range from -33.8579860628 to -33.8560329378) and + the decoded longitude is 151.2152005136 +/- 0.0009765625 (or the + range from 151.2142239511 to 151.2161770761). + + The encoded altitude of 000000000000000010000110110011 decodes to + 33.69921875. The encoded uncertainty of 15 gives a value of 64; + therefore, the final uncertainty is 33.69921875 +/- 64 (or the range + from -30.30078125 to 97.69921875). + +C.1.2.1. GML Representation of Decoded Locations + + The following GML shows the value decoded in the previous example as + a point in a three-dimensional CRS: + + <gml:Point srsName="urn:ogc:def:crs:EPSG::4979" + xmlns:gml="http://www.opengis.net/gml"> + <gml:pos>-33.8570095003 151.2152005136 33.69921875</gml:pos> + </gml:Point> + + The following example uses all of the decoded information from the + previous example: + + <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979" + xmlns:gs="http://www.opengis.net/pidflo/1.0" + xmlns:gml="http://www.opengis.net/gml"> + <gs:base> + <gml:Polygon> + <gml:exterior> + <gml:LinearRing> + <gml:posList> + -33.8579860628 151.2142239511 -30.30078125 + -33.8579860628 151.2161770761 -30.30078125 + -33.8560329378 151.2161770761 -30.30078125 + -33.8560329378 151.2142239511 -30.30078125 + -33.8579860628 151.2142239511 -30.30078125 + </gml:posList> + </gml:LinearRing> + </gml:exterior> + </gml:Polygon> + </gs:base> + <gs:height uom="urn:ogc:def:uom:EPSG::9001"> + 128 + </gs:height> + </gs:Prism> + + + + +Polk, et al. Standards Track [Page 33] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + Note that this representation is only appropriate if the uncertainty + is sufficiently small. [GeoShape] recommends that distances between + polygon vertices be kept short. A GML representation like this one + is only appropriate where uncertainty is less than 1 degree (an + encoded value of 9 or greater). + +Appendix D. Changes from RFC 3825 + + This section lists the major changes between RFC 3825 and this + document. Minor changes, including style, grammar, spelling, and + editorial changes, are not mentioned here. + + 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 + now defines the concepts of uncertainty and resolution, as well as + conversion between the DHCP option formats and PIDF-LO. + + o A DHCPv6 GeoLoc Option is now defined (Section 2.1) as well as a + new DHCPv4 GeoLoc Option (Section 2.2.2). + + o The former Datum field has been split into three fields: Ver, Res, + and Datum. These fields are used in both the DHCPv4 GeoLoc Option + and the DHCPv6 GeoLoc Option. + + 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 Longitude + fields. + + o Section 2.3.1 has been added, covering latitude and longitude + resolution. + + o Section 2.3.2 has been added, covering latitude and longitude + uncertainty. + + 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 + (Section 2.4.4), and altitude uncertainty (Section 2.4.5). + + o Section 2.5 has been added, covering the Datum field. + + o Section 3 (Security Considerations) has added a recommendation on + link-layer confidentiality. + + + + + + +Polk, et al. Standards Track [Page 34] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + + o Section 4 (IANA Considerations) has consolidated material relating + to parameter allocation for both the DHCPv4 and 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 shortened + and has been moved to Appendix B. + + o An Appendix A on GML mapping has been added. + + o Appendix C has been added, providing an example of uncertainty + encoding. + + o Appendix D has been added, detailing the changes from RFC 3825. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Polk, et al. Standards Track [Page 35] + +RFC 6225 DHCP Options for Coordinate LCI July 2011 + + +Authors' Addresses + + James M. Polk + Cisco Systems + 2200 East President George Bush Turnpike + Richardson, TX 75082 + USA + + EMail: jmpolk@cisco.com + + + Marc Linsner + Cisco Systems + Marco Island, FL 34145 + USA + + EMail: marc.linsner@cisco.com + + + Martin Thomson + Andrew Corporation + PO Box U40 + Wollongong University Campus, NSW 2500 + AU + + EMail: martin.thomson@andrew.com + + + Bernard Aboba (editor) + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + USA + + EMail: bernard_aboba@hotmail.com + + + + + + + + + + + + + + + + +Polk, et al. Standards Track [Page 36] + |