idnits 2.17.00 (12 Aug 2021) /tmp/idnits30191/draft-ietf-geopriv-rfc3825bis-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3825, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'EPSG' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. 'WGS84' == Outdated reference: draft-ietf-sipcore-location-conveyance has been published as RFC 6442 -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV Working Group J. Polk 3 INTERNET-DRAFT Cisco Systems 4 Obsoletes: 3825 (if approved) J. Schnizlein 5 Category: Standards Track Individual Contributor 6 Expires: May 7, 2011 M. Linsner 7 7 November 2010 Cisco Systems 8 M. Thomson 9 Andrew 10 B. Aboba (ed) 11 Microsoft Corporation 13 Dynamic Host Configuration Protocol Options for 14 Coordinate-based Location Configuration Information 16 draft-ietf-geopriv-rfc3825bis-13.txt 18 Abstract 20 This document specifies Dynamic Host Configuration Protocol Options 21 (both DHCPv4 and DHCPv6) for the coordinate-based geographic location 22 of the client. The Location Configuration Information (LCI) includes 23 Latitude, Longitude, and Altitude, with resolution or uncertainty 24 indicators for each. Separate parameters indicate the reference 25 datum for each of these values. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on May 7, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 5 81 1.2 Resolution and Uncertainty . . . . . . . . . . . . . . . 5 82 2. DHCP Option Format . . . . . . . . . . . . . . . . . . . . . . 6 83 2.1 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . 6 84 2.2 DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 8 85 2.3 Latitude and Longitude Fields . . . . . . . . . . . . . 10 86 2.4 Altitude . . . . . . . . . . . . . . . . . . . . . . . . 13 87 2.5 Datum . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 15 89 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16 90 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 91 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 93 6.2. Informational References . . . . . . . . . . . . . . . . 18 94 Appendix A. GML Mapping . . . . . . . . . . . . . . . . . . . . . 20 95 A.1. GML Templates . . . . . . . . . . . . . . . . . . . . . 20 96 Appendix B. Calculations of Resolution . . . . . . . . . . . . . . 23 97 B.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 23 98 B.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 26 99 Appendix C. Calculations of Uncertainty . . . . . . . . . . . . . 27 100 C.1 LCI of "Sydney Opera House" (Example 3) . . . . . . . . 27 101 Appendix D. Changes from RFC 3825 . . . . . . . . . . . . . . . . 31 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 104 1. Introduction 106 The physical location of a network device has a range of 107 applications. In particular, emergency telephony applications rely 108 on knowing the location of a caller in order to determine the correct 109 emergency center. 111 The location of a device can be represented either in terms of 112 geospatial (or geodetic) coordinates, or as a civic address. 113 Different applications may be more suited to one form of location 114 information; therefore, both the geodetic and civic forms may be used 115 simultaneously. 117 This document specifies Dynamic Host Configuration Protocol v4 118 (DHCPv4) [RFC2131] and DHCPv6 [RFC3315] options for the coordinate- 119 based geographic location of the client, to be provided by the 120 server. "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) 121 Option for Civic Addresses Configuration Information" [RFC4776] 122 specifies DHCP options for civic addresses. 124 The geodetic coordinate options defined in this document and the 125 civic address options defined in RFC 4776 [RFC4776] enable a DHCP 126 client to obtain its location. For example, a wired Ethernet host 127 might use these options for location determination. In this case, 128 the location information could be derived from a wiremap by the DHCP 129 server, using the Circuit-ID Relay Agent Information Option (RAIO) 130 defined (as Sub-Option 1) in RFC 3046 [RFC3046]. The DHCP server 131 could correlate the Circuit-ID with the geographic location where the 132 identified circuit terminates (such as the location of the wall 133 jack). 135 The mechanism defined here may also be utilized to provide location 136 to wireless hosts. DHCP relay agent sub-options (RAIO) [RFC3046] is 137 one method a DHCP server might use to perform host location 138 determination. Currently, the relay agent sub-options do not include 139 data sets required for device level location determination of 140 wireless hosts. In cases where the DHC server uses RAIO for location 141 determination, a wireless host can use this mechanism to discover 142 location of the radio access point, or the area of coverage for the 143 radio access point. 145 An important feature of this specification is that after the relevant 146 DHCP exchanges have taken place, the location information is stored 147 on the end device rather than somewhere else, where retrieving it 148 might be difficult in practice. 150 1.1. Conventions used in this document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 1.2. Resolution and Uncertainty 158 The DHCP options defined in this document include fields quantifying 159 the resolution or uncertainty associated with a target location. No 160 inferences relating to privacy policies can be drawn from either 161 uncertainty or resolution values. 163 As utilized in this document, resolution refers to the accuracy of a 164 reported location, as expressed by the number of valid bits in each 165 of the Latitude, Longitude and Altitude fields. 167 In the context of location technology, uncertainty is a 168 quantification of errors. Any method for determining location is 169 subject to some sources of error; uncertainty describes the amount of 170 error that is present. Uncertainty might be the coverage area of a 171 wireless transmitter, the extent of a building or a single room. 173 Uncertainty is usually represented as an area within which the target 174 is located. In this document, each of the three axes can be assigned 175 an uncertainty value. In effect, this describes a rectangular prism, 176 which may be used as a coarse representation of a more complex shape 177 that fits within it. See Section 2.3.2 for more detail on the 178 correspondence between shapes and uncertainty. 180 When representing locations from sources that can quantify 181 uncertainty, the goal is to find the smallest possible rectangular 182 prism that this format can describe. This is achieved by taking the 183 minimum and maximum values on each axis and ensuring that the final 184 encoding covers these points. This increases the region of 185 uncertainty, but ensures that the region that is described 186 encompasses the target location. 188 The DHCPv4 option format defined in this document supports both 189 resolution and uncertainty parameters. Version 0 of the DHCPv4 190 option format includes a resolution parameter for each of the 191 dimensions of location. Since this resolution parameter need not 192 apply to all dimensions equally, a resolution value is included for 193 each of the three location elements. Since version 0 of the DHCPv6 194 option format is not defined, the DHCPv6 option does not support a 195 resolution parameter. Version 1 of the DHCPv4 and DHCPv6 option 196 format utilizes an uncertainty parameter. Appendix A describes the 197 mapping of DHCP option values to GML. Appendix B of this document 198 provides examples showing the calculation of resolution values. 199 Appendix C provides an example demonstrating calculation of 200 uncertainty values. 202 Since the PIDF-LO format [RFC4119][RFC5491] is used to conveying 203 location and the associated uncertainty within an emergency call 204 [Convey], a mechanism is needed to convert the information contained 205 within the DHCPv4 and DHCPv6 options to PIDF-LO. This document 206 describes the following conversions: 208 version 0 to PIDF-LO 209 version 1 to PIDF-LO 210 PIDF-LO to version 1 212 Conversion to PIDF-LO does not increase uncertainty; conversion from 213 PIDF-LO to version 1 increases uncertainty by less than a factor of 2 214 in each dimension. Since it is not possible to translate an 215 arbitrary PIDF-LO to version 0 with a bounded increase in 216 uncertainty, the conversion to version 0 is not specified. 218 2. DHCP Option Format 220 This section defines the format for the DHCPv4 and DHCPv6 options. 221 These options utilize a similar format, differing primarily in the 222 option code. 224 2.1. DHCPv6 Option 226 The DHCPv6 [RFC3315] option format is as follows: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Option Code (TBD) | OptLen (16) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | LatUnc | Latitude + 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Lat (cont'd) | LongUnc | Longitude + 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Longitude (cont'd) | AType | AltUnc | Altitude + 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Altitude (cont'd) |Ver| Res |Datum| 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Code: GEOCONF_GEODETIC (16 bits). 244 OptLen: Option Length (16). This option has a fixed length, so 245 that the value of this octet will always be 16. 247 LatUnc: 6 bits. When the Ver field = 1, this field represents 248 latitude uncertainty. The contents of this field is 249 undefined for other values of the Ver field. 251 Latitude: a 34 bit fixed point value consisting of 9 bits of 252 integer and 25 bits of fraction, interpreted as 253 described in Section 2.3. 255 LongUnc: 6 bits. When the Ver field = 1, this field represents 256 longitude uncertainty. The contents of this field is 257 undefined for other values of the Ver field. 259 Longitude: a 34 bit fixed point value consisting of 9 bits of 260 integer and 25 bits of fraction, interpreted as 261 described in Section 2.3. 263 AType: Altitude Type (4 bits). 265 AltUnc: 6 bits. When the Ver field = 1, this field represents 266 altitude uncertainty. The contents of this field is 267 undefined for other values of the Ver field. 269 Altitude: A 30 bit value defined by the AType field. 271 Ver: The Ver field is two bits, providing for four potential 272 versions. This specification defines the behavior of 273 version 1. The Ver field is always located at the same 274 offset from the beginning of the option, regardless of 275 the version in use. 277 Res: The Res field which is 3 bits, is reserved. These bits 278 have been used by [IEEE-802.11y], but are not defined 279 within this specification. 281 Datum: 3 bits. The Map Datum used for the coordinates given in 282 this Option. 284 2.2. DHCPv4 Option 286 The DHCPv4 option format is as follows: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Code 123 | Length | LatUnc | Latitude + 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Latitude (cont'd) | LongUnc | + 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Longitude | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | AType | AltUnc | Altitude + 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Alt.(cont'd) |Ver| Res |Datum| 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Code: 8 bits. The code for the DHCPv4 option (123). 304 Length: 8 bits. The length of the DHCPv4 option, in octets. 305 For versions 0 and 1, the option length is 16. 307 LatUnc: 6 bits. When the Ver field = 0, this field represents 308 latitude resolution. When the Ver field = 1, 309 this field represents latitude uncertainty. 311 Latitude: a 34 bit fixed point value consisting of 9 bits of 312 signed integer and 25 bits of fraction, interpreted 313 as described in Section 2.3. 315 LongUnc: 6 bits. When the Ver field = 0, this field represents 316 longitude resolution. When the Ver field = 1, 317 this field represents longitude uncertainty. 319 Longitude: a 34 bit fixed point value consisting of 9 bits of 320 signed integer and 25 bits of fraction, interpreted 321 as described in Section 2.3. 323 AType: Altitude Type (4 bits). 325 AltUnc: 6 bits. When the Ver field = 0, this field represents 326 altitude resolution. When the Ver field = 1, 327 this field represents altitude uncertainty. 329 Altitude: A 30 bit value defined by the AType field. 331 Ver: The Ver field is two bits, providing for four potential 332 versions. This specification defines the behavior of 333 version 0 (originally specified in [RFC3825]) as well as 334 version 1. The Ver field is always located at the same 335 offset from the beginning of the option, regardless of 336 the version in use. 338 Res: The Res field which is 3 bits, is reserved. These bits 339 have been used by [IEEE-802.11y], but are not defined 340 within this specification. 342 Datum: 3 bits. The Map Datum used for the coordinates given in 343 this Option. 345 2.2.1. Version Support 347 2.2.1.1. Client Version Support 349 DHCPv6 clients implementing this specification MUST support receiving 350 version 1 responses. DHCPv4 clients implementing this specification 351 MUST support receiving responses of versions 0 and 1. It is required 352 that DHCPv4 client implementations support version 1 so the 353 versioning capability added by this document does not cause errors 354 interpreting the Latitude, Longitude and Altitude values. Since this 355 specification utilizes the same DHCPv4 option code as [RFC3825], the 356 option format does not provide a means for the DHCPv4 client to 357 indicate the highest version that it supports to the DHCPv4 server. 359 Moving forward, DHCPv4 and DHCPv6 clients not understanding a datum 360 value MUST assume a World Geodesic System 1984 (WGS84) [WGS84] datum 361 (EPSG [EPSG] 4326 or 4979, depending on whether there is an Altitude 362 value present) and proceed accordingly. Assuming that a less 363 accurate location value is better than none, this ensures that some 364 (perhaps less accurate) location is available to the client. 366 2.2.1.2. Server Version Selection 368 DHCPv6 servers implementing this specification MUST support sending 369 version 1 responses. A DHCPv4 server implementing this specification 370 MUST support sending version 1 responses and SHOULD support sending 371 version 0 responses. A DHCPv4 server that provides location 372 information cannot provide options with both version 0 and version 1 373 formats in the same response. This is not useful since receiving two 374 copies of the same Option (either in the same response or a separate 375 response) causes a DHCPv4 client to replace the information in the 376 old Option with the information in the new Option. 378 A DHCPv4 server uses configuration to determine which version to send 379 in a response. For example, where a mixture of version 0 and version 380 1 clients are expected, the DHCPv4 server could be configured to send 381 version 0 or version 1 depending on configuration (possibly making 382 the choice based on information such as the client MAC address). 383 Where few version 0 clients are expected, the DHCPv4 server could be 384 configured to send only version 1 responses. Version 0 options will 385 provide resolution, while version 1 options will provide an area of 386 uncertainty. 388 An RFC 3825 DHCPv4 client that receives a version 1 option, as 389 defined in this document, will either reject the Option or will not 390 understand the additions to the Datum field and will misinterpret the 391 LongUnc, LatUnc, and AltUnc values. If the RFC 3825 DHCPv4 client 392 does not reject the option and utilizes the location data it will 393 most likely assume a datum. Assuming one of the RFC 3825 datums 394 causes correct interpretation of Latitude/Longitude/Altitude values. 395 The values for LongUnc/LatUnc/AltUnc are mistakenly interpreted as 396 representing significant digits. The resultant location value will 397 be in error up to a full degree of latitude and longitude, and a full 398 increment of altitude. 400 This results in a version 0-only DHCPv4 client either not obtaining 401 location information (with no ability to indicate to the server that 402 version 1 was unsupported), or misinterpreting the option. 403 Therefore, in situations where some DHCPv4 clients are known to 404 support only version 0, by default the DHCPv4 server SHOULD send a 405 version 0 response. 407 2.3. Latitude and Longitude Fields 409 The Latitude and Longitude values in this specification are encoded 410 as 34 bit, twos complement, fixed point values with 9 integer bits 411 and 25 fractional bits. The exact meaning of these values is 412 determined by the datum; the description in this section applies to 413 the datums defined in this document. This document uses the same 414 definition for all datums it specifies. 416 Latitude values encoded by the DHCP server MUST be constrained to the 417 range from -90 to +90 degrees. Location consumers MUST be prepared 418 to normalize values outside this range. Values outside the range are 419 normalized by clamping (e.g. values less than -90 degrees are set to 420 -90; values greater than 90 degrees are set to +90). Positive 421 latitudes are north of the equator and negative latitudes are south 422 of the equator. 424 Longitude values encoded by the DHCP server MUST be normalized to the 425 range from -180 to +180 degrees. Location consumers MUST be prepared 426 to normalize values outside this range. Values outside the range are 427 normalized by wrapping (e.g. adding or subtracting 360 until they 428 fall within the range of -180 to 180). Positive longitudes are east 429 of the Prime Meridian (Greenwich) and negative (2s complement) 430 longitudes are west of the Prime Meridian. 432 When encoding, Latitude and Longitude values are rounded to the 433 nearest 34-bit binary representation. This imprecision is considered 434 acceptable for the purposes to which this form is intended to be 435 applied and is ignored when decoding. 437 2.3.1. Latitude and Longitude Resolution 439 The Latitude (LatUnc), Longitude (LongUnc) and Altitude (AltUnc) 440 Uncertainty fields are encoded as 6 bit, unsigned integer values. In 441 the version 0 DHCPv4 Option, the LatUnc, LongUnc and AltUnc fields 442 are used to encode the number of bits of resolution. The resolution 443 sub-fields accommodate the desire to easily adjust the precision of a 444 reported location. Contents beyond the claimed resolution MAY be 445 randomized to obscure greater precision that might be available. 447 In the version 0 DHCPv4 Option, the LatUnc value encodes the number 448 of high-order latitude bits that should be considered valid. Any 449 bits entered to the right of this limit should not be considered 450 valid and might be purposely false, or zeroed by the sender. The 451 examples in Appendix B illustrate that a smaller value in the 452 resolution field increases the area within which the device is 453 located. A value of 2 in the LatUnc field indicates a precision of 454 no greater than 1/6th that of the globe (see the first example of 455 Appendix B). A value of 34 in the LatUnc field indicates a precision 456 of about 3.11 mm in latitude at the equator. 458 In the version 0 DHCPv4 Option, the LongUnc value encodes the number 459 of high-order longitude bits that should be considered valid. Any 460 bits entered to the right of this limit should not be considered 461 valid and might be purposely false, or zeroed by the sender. A value 462 of 2 in the LongUnc field indicates precision of no greater than 463 1/6th that of the globe (see the first example of Appendix B). A 464 value of 34 in the LongUnc field indicates a precision of about 2.42 465 mm in Longitude (at the equator). Because lines of longitude 466 converge at the poles, the distance is smaller (better precision) for 467 locations away from the equator. 469 2.3.2. Latitude and Longitude Uncertainty 471 In the DHCPv6 option and the version 1 DHCPv4 option, the Latitude 472 and Longitude Uncertainty fields (LatUnc and LongUnc) quantify the 473 amount of uncertainty in each of the Latitude and Longitude values 474 respectively. A value of 0 is reserved to indicate that the 475 uncertainty is unknown; values greater than 34 are reserved. 477 A point within the region of uncertainty is selected to be the 478 encoded point; the centroid of the region is often an appropriate 479 choice. The value for uncertainty is taken as the distance from the 480 selected point to the furthest extreme of the region of uncertainty 481 on that axis. This is demonstrated in the figure below, which shows 482 a two-dimensional polygon that is projected on each axis. In the 483 figure, "X" marks the point that is selected; the ranges marked with 484 "U" is the uncertainty. 486 ___ ___________ 487 ^ | / | 488 | | / | 489 | | / | 490 U | / | 491 | | ( | 492 V | | | 493 --X | X | 494 | | `---------. 495 | | | 496 | | | 497 | | | 498 - `-------------------------' 500 |---------X---------------| 501 |<------U------>| 503 Key 504 --- 506 V, ^ = vertical arrows, delimiting the vertical uncertainty range. 507 <> = horizontal arrows, delimiting the horizontal uncertainty 508 range. 510 Uncertainty applies to each axis independently. 512 The amount of uncertainty can be determined from the encoding by 513 taking 2 to the power of 8, less the encoded value. As is shown in 514 the following formula, where "x" is the encoded integer value: 516 uncertainty = 2 ^ ( 8 - x ) 518 The result of this formula is expressed in degrees of latitude or 519 longitude. The uncertainty is added to the base latitude or 520 longitude value to determine the maximum value in the uncertainty 521 range; similarly, the uncertainty is subtracted from the base value 522 to determine the minimum value. Note that because lines of longitude 523 converge at the poles, the actual distance represented by this 524 uncertainty changes with the distance from the equator. 526 If the maximum or minimum latitude values derived from applying 527 uncertainty are outside the range of -90 to +90, these values are 528 trimmed to within this range. If the maximum or minimum longitude 529 values derived from applying uncertainty are outside the range of 530 -180 to +180, then these values are normalized to this range by 531 adding or subtracting 360 as necessary. 533 The encoded value is determined by subtracting the next highest whole 534 integer value for the base 2 logarithm of uncertainty from 8. As is 535 shown by the following formula, where uncertainty is the midpoint of 536 the known range less the lower bound of that range: 538 x = 8 - ceil( log2( uncertainty ) ) 540 Note that the result of encoding this value increases the range of 541 uncertainty to the next available power of two; subsequent repeated 542 encodings and decodings do not change the value. Only increasing 543 uncertainty means that the associated confidence does not have to 544 decrease. 546 2.4. Altitude 548 The Altitude value is expressed as a 30 bit, fixed point, twos 549 complement integer with 22 integer bits and 8 fractional bits. How 550 the Altitude value is interpreted depends on the Altitude Type 551 (AType) value and the selected datum. Three Altitude Type values are 552 defined in this document: unknown (0), meters (1) and floors (2). 554 2.4.1. No Known Altitude (AType = 0) 556 In some cases, the altitude of the location might not be provided. 557 An Altitude Type value of zero indicates that the altitude is not 558 given to the client. In this case, the Altitude and Altitude 559 Uncertainty fields can contain any value and MUST be ignored. 561 2.4.2. Altitude in Meters (AType = 1) 563 If the Altitude Type has a value of one, Altitude is measured in 564 meters, in relation to the zero set by the vertical datum. 566 2.4.3. Altitude in Floors (AType = 2) 568 A value of two for Altitude Type indicates that the Altitude value is 569 measured in floors. This value is relevant only in relation to a 570 building; the value is relative to the ground level of the building. 571 In this definition, numbering starts at ground level, which is floor 572 0 regardless of local convention. 574 Non-integer values can be used to represent intermediate or sub- 575 floors, such as mezzanine levels. For instance, a mezzanine between 576 floors 4 and 5 could be represented as 4.1. 578 2.4.4. Altitude Resolution 580 In the version 0 DHCPv4 Option, the Altitude Uncertainty (AltUnc) 581 value encodes the number of high-order altitude bits that should be 582 considered valid. Values above 30 (decimal) are undefined and 583 reserved. 585 If the Altitutde Type value is one (AType = 1), an AltUnc value 0.0 586 would indicate unknown Altitude. The most precise altitude would 587 have an AltUnc value of 30. Many values of AltUnc would obscure any 588 variation due to vertical datum differences. 590 The AltUnc field SHOULD be set to maximum precision when AType = 2 591 (floors) when a floor value is included in the DHCP Reply, or when 592 AType = 0, to denote that the floor isn't known. An altitude coded 593 as AType = 2, AltRes = 30, and Altitude = 0.0 is meaningful even 594 outside a building, and represents ground level at the given latitude 595 and longitude. 597 2.4.5. Altitude Uncertainty 599 In the DHCPv6 option or the version 1 DHCPv4 option, the AltUnc value 600 quantifies the amount of uncertainty in the Altitude value. As with 601 LatUnc and LongUnc, a value of 0 for AltUnc is reserved to indicate 602 that Altitude Uncertainty is not known; values above 30 are also 603 reserved. Altitude Uncertainty only applies to Altitude Type 1. 605 The amount of Altitude Uncertainty can be determined by the following 606 formula, where x is the encoded integer value: 608 Uncertainty = 2 ^ ( 21 - x ) 610 This value uses the same units as the associated altitude. 612 Similarly, a value for the encoded integer value can be derived by 613 the following formula: 615 x = 21 - ceil( log2( uncertainty ) ) 617 2.5. Datum 619 The Datum field determines how coordinates are organized and related 620 to the real world. Three datums are defined in this document, based 621 on the definitions in [OGP.Geodesy]: 623 1: WGS84 (Latitude, Longitude, Altitude): 624 The World Geodesic System 1984 [WGS84] coordinate reference 625 system. 627 This datum is identified by the European Petroleum Survey Group 628 (EPSG)/International Association of Oil & Gas Producers (OGP) with 629 the code 4979, or by the URN "urn:ogc:def:crs:EPSG::4979". 630 Without Altitude, this datum is identified by the EPSG/OGP code 631 4326 and the URN "urn:ogc:def:crs:EPSG::4326". 633 2: NAD83 (Latitude, Longitude) + NAVD88: 634 This datum uses a combination of the North American Datum 1983 635 (NAD83) for horizontal (Latitude and Longitude) values, plus the 636 North American Vertical Datum of 1988 (NAVD88) vertical datum. 638 This datum is used for referencing location on land (not near 639 tidal water) within North America. 641 NAD83 is identified by the EPSG/OGP code of 4269, or the URN 642 "urn:ogc:def:crs:EPSG::4269". NAVD88 is identified by the EPSG/ 643 OGP code of 5703, or the URN "urn:ogc:def:crs:EPSG::5703". 645 3: NAD83 (Latitude, Longitude) + MLLW: 646 This datum uses a combination of the North American Datum 1983 647 (NAD83) for horizontal (Latitude and Longitude) values, plus the 648 Mean Lower Low Water (MLLW) vertical datum. 650 This datum is used for referencing location on or near tidal water 651 within North America. 653 NAD83 is identified by the EPSG/OGP code of 4269, or the URN 654 "urn:ogc:def:crs:EPSG::4269". MLLW does not have a specific code 655 or URN. 657 All hosts MUST support the WGS84 datum (Datum 1). 659 3. Security Considerations 661 Geopriv requirements (including security requirements) are discussed 662 in "Geopriv Requirements" [RFC3693]. A threat analysis is provided 663 in "Threat Analysis of the Geopriv Protocol" [RFC3694]. 665 Since there is no privacy protection for DHCP messages, an 666 eavesdropper who can monitor the link between the DHCP server and 667 requesting client can discover this LCI. 669 To minimize the unintended exposure of location information, the LCI 670 option SHOULD be returned by DHCP servers only when the DHCP client 671 has included this option in its 'parameter request list' (section 3.5 672 [RFC2131]). 674 Where critical decisions might be based on the value of this option, 675 DHCP authentication as defined in "Authentication for DHCP Messages" 676 [RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" 677 [RFC3315] SHOULD be used to protect the integrity of the DHCP 678 options. 680 Link layer confidentiality and integrity protection may also be 681 employed to reduce the risk of location disclosure and tampering. 683 4. IANA Considerations 685 IANA has assigned a DHCPv4 option code of 123 for the GeoConf option 686 defined in this document. Assignment of a DHCPv6 option code is 687 requested. 689 The GeoConf Option defines two fields for which IANA maintains a 690 registry: The Altitude Type (AType) field and the Datum field (see 691 Section 2). The datum indicator MUST include specification of both 692 horizontal and vertical datum. New values for the Altitude Type 693 (AType) and Datum fields are assigned through "Standards Action" 694 [RFC5226]. New Altitude Types MUST define the way that the 30 bit 695 altitude values and the associated 6 bit uncertainty are interpreted. 696 New datums MUST define the way that the 34 bit values and the 697 respective 6 bit uncertainties are interpreted. The initial values 698 of the Altitude registry are as follows: 700 AType = 0 No known altitude. 702 AType = 1 meters of altitude defined by the vertical datum 703 specified. 705 AType = 2 building floors of altitude. 707 Datum = 1 denotes the vertical datum WGS 84 as defined by the EPSG 708 as their CRS Code 4327; CRS Code 4327 also specifies WGS 84 709 as the vertical datum. 711 Datum = 2 denotes the vertical datum NAD83 as defined by the EPSG as 712 their CRS Code 4269; North American Vertical Datum of 1988 713 (NAVD88) is the associated vertical datum for NAD83. 715 Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as 716 their CRS Code 4269; Mean Lower Low Water (MLLW) is the 717 associated vertical datum for NAD83. 719 This document defines the Ver field for the DHCPv4 and DHCPv6 720 options. New values for the Ver field are assigned through 721 "Standards Action" [RFC5226]. Initial values are as follows: 723 0: DHCPv4 Implementations conforming to [RFC3825] 724 1: Implementations of this specification (for both DHCPv4 and DHCPv6) 726 5. Acknowledgments 728 The authors would like to thank Randall Gellens, Patrik Falstrom, 729 Ralph Droms, Ted Hardie, Jon Peterson, Robert Sparks and Nadine 730 Abbott for their inputs and constructive comments regarding this 731 document. Additionally, the authors would like to thank Greg Troxel 732 for the education on vertical datums, as well as Carl Reed. Thanks 733 to Richard Barnes for his contribution on GML mapping for resolution. 735 6. References 737 6.1. Normative References 739 [EPSG] European Petroleum Survey Group, http://www.epsg.org/ and 740 http://www.epsg-registry.org/ 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, March 1997. 745 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 746 March 1997. 748 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 749 3046, January 2001. 751 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 752 Messages", RFC 3118, June 2001. 754 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 755 M. Carney, "Dynamic Host Configuration Protocol for IPv6 756 (DHCPv6)", RFC 3315, July 2003. 758 [WGS84] US National Imagery and Mapping Agency, "Department of 759 Defense (DoD) World Geodetic System 1984 (WGS 84), Third 760 Edition", NIMA TR8350.2, January 2000, 761 https://www1.nga.mil/PRODUCTSSERVICES/GEODESYGEOPHYSICS/ 762 WORLDGEODETICSYSTEM/Pages/default.aspx and 763 http://www.ngs.noaa.gov/faq.shtml#WGS84 765 6.2. Informational References 767 [Convey] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance 768 for the Session Initiation Protocol", Internet draft (work 769 in progress), draft-ietf-sipcore-location- 770 conveyance-04.txt, October 25, 2010. 772 [GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 773 Application Schema for use by the Internet Engineering Task 774 Force (IETF)", Candidate OpenGIS Implementation 775 Specification 06-142, Version: 0.0.9, December 2006. 777 [IEEE-802.11y] 778 Information technology - Telecommunications and information 779 exchange between systems - Local and metropolitan area 780 networks - Specific requirements - Part 11: Wireless LAN 781 Medium Access Control (MAC) and Physical Layer (PHY) 782 specifications Amendment 3: 3650-3700 MHz Operation in USA, 783 November 2008. 785 [NENA] National Emergency Number Association (NENA) www.nena.org 786 NENA Technical Information Document on Model Legislation 787 Enhanced 911 for Multi-Line Telephone Systems. 789 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 790 3046, January 2001. 792 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. 793 Polk, "Geopriv Requirements", RFC 3693, February 2004. 795 [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, 796 "Threat Analysis of the Geopriv Protocol", RFC 3694, 797 February 2004. 799 [RFC3825] Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host 800 Configuration Protocol Option for Coordinate-based Location 801 Configuration Information", RFC 3825, July 2004. 803 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 804 Format", RFC 4119, December 2005. 806 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 807 (DHCPv4 and DHCPv6) Option for Civic Addresses 808 Configuration Information", RFC 4776, November 2006. 810 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 811 Format for Presence Information Data Format Location Object 812 (PIDF-LO)", RFC 5139, February 2008. 814 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 815 IANA Considerations Section in RFCs", RFC 5226, May 2008. 817 [RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV 818 PIDF-LO Usage Clarification, Considerations, and 819 Recommendations ", RFC 5491, March 2009 821 Appendix A. GML Mapping 823 The GML representation of a decoded DHCP option depends on what 824 fields are specified. The DHCP format for location logically 825 describes a geodetic prism, rectangle, or point, depending on whether 826 Altitude and uncertainty values are provided. In the absence of 827 uncertainty information, the value decoded from the DHCP form can be 828 expressed as a single point; this is true regardless of whether the 829 version 0 or version 1 interpretations of the uncertainty fields are 830 used. If the point includes Altitude, it uses a three dimensional 831 CRS, otherwise it uses a two dimensional CRS. If all fields are 832 included along with uncertainty, the shape described is a rectangular 833 prism. Note that this is necessary given that uncertainty for each 834 axis is provided independently. 836 If Altitude or Altitude Uncertainty (AltUnc) is not specified, the 837 shape is described as a rectangle using the "gml:Polygon" shape. If 838 Altitude is available, a three dimensional CRS is used, otherwise a 839 two dimensional CRS is used. 841 For Datum values of 2 or 3 (NAD83), there is no available CRS URN 842 that covers three dimensional coordinates. By necessity, locations 843 described in these datums can be represented by two dimensional 844 shapes only; that is, either a two dimensional point or a polygon. 846 If the Altitude Type is 2 (floors), then this value can be 847 represented using a civic address object [RFC5139] that is presented 848 alongside the geodetic object. 850 This Appendix describes how the location value encoded in DHCP format 851 for geodetic location can be expressed in GML. The mapping is valid 852 for the DHCPv6 option as well as versions 0 and 1 of the DHCPv4 853 option, and for the currently-defined datum values (1, 2, and 3). 854 Further version or datum definitions should provide similar mappings. 856 These shapes can be mapped to GML by first computing the bounds that 857 are described using the coordinate and uncertainty fields, then 858 encoding the result in a GML Polygon or Prism shape. 860 A.1. GML Templates 862 If Altitude is provided in meters (Altitude Type 1) and the datum 863 value is WGS84 (value 1), then the proper GML shape is a Prism, with 864 the following form (where $value$ indicates a value computed from the 865 DHCP option as described below): 867 870 871 872 873 874 875 $lowLatitude$ $lowLongitude$ $lowAltitude$ 876 $lowLatitude$ $highLongitude$ $lowAltitude$ 877 $highLatitude$ $highLongitude$ $lowAltitude$ 878 $highLatitude$ $lowLongitude$ $lowAltitude$ 879 $lowLatitude$ $lowLongitude$ $lowAltitude$ 880 881 882 883 884 885 886 $highAltitude - lowAltitude$ 887 888 890 The Polygon shape is used if Altitude is omitted or specified in 891 floors, or if either NAD83 datum is used (value 2 or 3). The 892 corresponding GML Polygon has the following form: 894 > 896 897 898 899 $lowLatitude$ $lowLongitude$ 900 $lowLatitude$ $highLongitude$ 901 $highLatitude$ $highLongitude$ 902 $highLatitude$ $lowLongitude$ 903 $lowLatitude$ $lowLongitude$ 904 905 906 907 909 The value "2D-CRS-URN" is defined by the datum value: If the datum is 910 WGS84 (value 1), then the 2D-CRS-URN is "urn:ogc:def:crs:EPSG::4326". 911 If the datum is NAD83 (value 2 or 3), then the 2D-CRS-URN is 912 "urn:ogc:def:crs:EPSG::4269". 914 A Polygon shape with the WGS84 three-dimensional CRS is used if the 915 datum is WGS84 (value 1) and the Altitude is specified in meters 916 (Altitude type 1), but no Altitude uncertainty is specified (that is, 917 AltUnc is 0). In this case, the value of the Altitude field is added 918 after each of the points above, and the srsName attribute is set to 919 the three-dimensional WGS84 CRS, namely "urn:ogc:def:crs:EPSG::4979". 921 A simple point shape is used if either Latitude uncertainty (LatUnc) 922 or Longitude uncertainty (LongUnc) is not specified. With Altitude, 923 this uses a three-dimensional CRS; otherwise, it uses a two- 924 dimensional CRS. 926 928 $Latitude$ $Longitude$ $[Altitude]$ 929 931 A.1.1. Finding Low and High Values using Uncertainty Fields 933 The uncertainty fields (LatUnc, LongUnc, AltUnc) indicate the bounds 934 of the location region described by a DHCP location object. For 935 version 0 of the DHCPv4 option, the uncertainty fields represent 936 resolution, indicating how many bits of a value contain information. 937 Any bits beyond those indicated can be either zero or one. For the 938 DHCPv6 option and version 1 of the DHCPv4 option, the LatUnc, LongUnc 939 and AltUnc fields indicate uncertainty distances. 941 The two sections below describe how to compute the Latitude, 942 Longitude, and Altitude bounds (e.g., $lowLatitude$, $highAltitude$) 943 in the templates above. The first section describes how these bounds 944 are computed in the "resolution encoding" (version 0), while the 945 second section addresses the "uncertainty encoding" (version 1). 947 A.1.1.1. Resolution Encoding 949 Given a number of resolution bits (i.e., the value of a resolution 950 field), if all bits beyond those bits are set to zero, this gives the 951 lowest possible value. The highest possible value can be found 952 setting all bits to one. 954 If the encoded value of Latitude/Longitude and resolution (LatUnc, 955 LongUnc) are treated as 34-bit unsigned integers, the following can 956 be used (where ">>" is a bitwise right shift, "&" is a bitwise AND, 957 "~" is a bitwise negation, and "|" is a bitwise OR). 959 mask = 0x3ffffffff >> resolution 960 lowvalue = value & ~mask 961 highvalue = value | mask + 1 963 Once these values are determined, the corresponding floating point 964 numbers can be computed by dividing the values by 2^25 (since there 965 are 25 bits of fraction in the fixed-point representation). 967 Alternatively, the lowest possible value can be found by using 968 resolution to determine the size of the range. This method has the 969 advantage that it operates on the decoded floating point values. It 970 is equivalent to the first mechanism, to a possible error of 2^-25 971 (2^-8 for altitude). 973 scale = 2 ^ ( 9 - resolution ) 974 lowvalue = floor( value / scale ) * scale 975 highvalue = lowvalue + scale 977 Altitude resolution (AltUnc for v0) uses the same process with 978 different constants. There are 22 whole bits in the Altitude 979 encoding (instead of 9) and 30 bits in total (instead of 34). 981 A.1.1.2. Uncertainty Encoding 983 In the uncertainty encoding, the uncertainty fields (LongUnc/LatUnc 984 in version 1) directly represent the logarithms of uncertainty 985 distances. So the low and high bounds are computed by first 986 computing the uncertainty distances, then adding and subtracting 987 these from the value provided. If "uncertainty" is the unsigned 988 integer value of the uncertainty field and "value" is the value of 989 the coordinate field: 991 distance = 2 ^ (8 - uncertainty) 992 lowvalue = value - distance 993 highvalue = value + distance 995 Altitude uncertainty (AltUnc in version 1) uses the same process with 996 different constants: 998 distance = 2 ^ (21 - uncertainty) 999 lowvalue = value - distance 1001 Appendix B. Calculations of Resolution 1003 The following examples for two different locations demonstrate how 1004 the Resolution values for Latitude, Longitude, and Altitude (used in 1005 the version 0 DHCPv4 option) can be calculated. In both examples, 1006 the geo-location values were derived from maps using the WGS84 map 1007 datum, therefore in these examples, the Datum field would have a 1008 value = 1 (00000001, or 0x01). 1010 B.1. Location Configuration Information of "White House" (Example 1) 1012 The grounds of the White House in Washington D.C. (1600 Pennsylvania 1013 Ave. NW, Washington, DC 20006) can be found between 38.895375 and 1014 38.898653 degrees North and 77.037911 and 77.035116 degrees West. In 1015 this example, we assume that we are standing on the sidewalk on the 1016 north side of the White House, between driveways. Since we are not 1017 inside a structure, we assume an Altitude value of 15 meters, 1018 interpolated from the US Geological survey map, Washington Washington 1019 West quadrangle. 1021 The address was NOT picked for any political reason and can easily be 1022 found on the Internet or mapping software, but was picked as an 1023 easily identifiable location on our planet. 1025 In this example, the requirement of emergency responders in North 1026 America via their NENA Model Legislation [NENA] could be met by a 1027 LatUnc value of 21 and a LongUnc value of 20. This would yield a 1028 geo-location that is Latitude 38.8984375 north to Latitude 38.8988616 1029 north and Longitude -77.0371094 to Longitude -77.0375977. This is an 1030 area of approximately 89 feet by 75 feet or 6669 square feet, which 1031 is very close to the 7000 square feet requested by NENA. In this 1032 example, a service provider could enforce that a device send a 1033 Location Configuration Information with this minimum amount of 1034 resolution for this particular location when calling emergency 1035 services. 1037 An approximate representation of this location might be provided using 1038 the version 0 encoding as follows: 1040 0 1 2 3 1041 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 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Code (123) | OptLen (16) | LatUnc | Latitude . 1044 |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. 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 . Latitude (cont'd) | LongUnc | . 1047 .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. 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 . Longitude (cont'd) | 1050 .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| 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | AType | AltUnc | Altitude . 1053 |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. 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 . Alt (cont'd) |Ver| Res |Datum| 1056 .0 0 0 0 0 0 0 0|0 0|0 0 0|0 0 1| 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 In hexadecimal, this is 7B10484D CB986347 65ED42C4 1440000F 0001. 1061 Decoding Location Configuration Information with Resolution 1063 Decoding this option gives a latitude of 38.897647 (to 7 decimal 1064 places) with 18 bits of resolution; a longitude of -77.0366000 with 1065 17 bits of resolution; an altitude type of meters with a value of 15 1066 and 17 bits of resolution; version 0 (resolution) and the WGS84 1067 datum. 1069 For the latitude value, 18 bits of resolution allow for values in the 1070 range from 38.8964844 to 38.8984375. For the longitude value, 17 1071 bits of resolution allow for values in the range from -77.0390625 to 1072 -77.0351563. Having 17 bits of resolution in the altitude allows for 1073 values in the range from 0 to 32 meters. 1075 GML Representation of Decoded Location Configuration Information 1077 The following GML shows the value decoded in the previous example as 1078 a point in a three dimensional CRS: 1080 1082 38.897647 -77.0366 15 1083 1085 This representation ignores the values included in the resolution 1086 parameters. If resolution values are provided, a rectangular prism 1087 can be used to represent the location. 1089 The following example uses all of the decoded information from the 1090 previous example: 1092 1095 1096 1097 1098 1099 1100 38.8964844 -77.0390625 0 1101 38.8964844 -77.0351563 0 1102 38.8984375 -77.0351563 0 1103 38.8984375 -77.0390625 0 1104 38.8964844 -77.0390625 0 1105 1106 1107 1108 1110 1111 1112 32 1113 1114 1116 B.2. Location Configuration Information of "Sears Tower" (Example 2) 1118 Postal Address: 1119 Sears Tower 1120 103rd Floor 1121 233 S. Wacker Dr. 1122 Chicago, IL 60606 1124 Viewing the Chicago area from the Observation Deck of the Sears 1125 Tower. 1127 Latitude 41.87884 degrees North (or +41.87884 degrees) 1128 Using 2s complement, 34 bit fixed point, 25 bit fraction 1129 Latitude = 0x053c1f751, 1130 Latitude = 0001010011110000011111011101010001 1131 Longitude 87.63602 degrees West (or -87.63602 degrees) 1132 Using 2s complement, 34 bit fixed point, 25 bit fraction 1133 Longitude = 0xf50ba5b97, 1134 Longitude = 1101010000101110100101101110010111 1136 Altitude 103 1138 In this example, we are inside a structure, therefore we will assume 1139 an Altitude value of 103 to indicate the floor we are on. The 1140 Altitude Type value is 2, indicating floors. The AltUnc field would 1141 indicate that all bits in the Altitude field are true, as we want to 1142 accurately represent the floor of the structure where we are located. 1144 AltUnc = 30, 0x1e, 011110 1145 AType = 2, 0x02, 000010 1146 Altitude = 103, 0x00006700, 000000000000000110011100000000 1148 For the accuracy of the Latitude and Longitude, the best information 1149 available to us was supplied by a generic mapping service that shows 1150 a single geo-loc for all of the Sears Tower. Therefore we are going 1151 to show LatUnc as value 18 (0x12 or 010010) and LongUnc as value 18 1152 (0x12 or 010010). This would be describing a geo-location area that 1153 is Latitude 41.8769531 to Latitude 41.8789062 and extends from 1154 -87.6367188 degrees to -87.6347657 degrees Longitude. This is an 1155 area of approximately 373412 square feet (713.3 ft. x 523.5 ft.). 1157 Appendix C. Calculations of Uncertainty 1159 The following example demonstrates how uncertainty values for 1160 Latitude, Longitude, and Altitude (LatUnc, LongUnc and AltUnc 1161 used in the DHCPv6 Option as well as the version 1 DHCPv4 option) 1162 can be calculated. 1164 C.1. Location Configuration Information of "Sydney Opera House" 1165 (Example 3) 1167 This section describes an example of encoding and decoding the 1168 geodetic DHCP Option. The textual results are expressed in GML 1169 [OGC.GML-3.1.1] form, suitable for inclusion in PIDF-LO [RFC4119]. 1171 These examples all assume a datum of WGS84 (datum = 1) and an 1172 Altitude type of meters (AType = 1). 1174 C.1.1. Encoding a Location into DHCP Geodetic Form 1176 This example draws a rough polygon around the Sydney Opera House. 1177 This polygon consists of the following six points: 1179 33.856625 S, 151.215906 E 1180 33.856299 S, 151.215343 E 1181 33.856326 S, 151.214731 E 1182 33.857533 S, 151.214495 E 1183 33.857720 S, 151.214613 E 1184 33.857369 S, 151.215375 E 1186 The top of the building 67.4 meters above sea level, and a starting 1187 Altitude of 0 meters above the WGS84 geoid is assumed. 1189 The first step is to determine the range of Latitude and Longitude 1190 values. Latitude ranges from -33.857720 to -33.856299; Longitude 1191 ranges from 151.214495 to 151.215906. 1193 For this example, the point that is encoded is chosen by finding the 1194 middle of each range, that is (-33.8570095, 151.2152005). This is 1195 encoded as (1110111100010010010011011000001101, 1196 0100101110011011100010111011000011) in binary, or (3BC49360D, 1197 12E6E2EC3) in hexadecimal notation (with an extra 2 bits of leading 1198 padding on each). Altitude is set at 33.7 meters, which is 1199 000000000000000010000110110011 (binary) or 000021B3 (hexadecimal). 1201 The Latitude Uncertainty (LatUnc) is given by inserting the 1202 difference between the center value and the outer value into the 1203 formula from Section 2.3.1. This gives: 1205 x = 8 - ceil( log2( -33.8570095 - -33.857720 ) ) 1207 The result of this equation is 18, therefore the uncertainty is 1208 encoded as 010010 in binary. 1210 Similarly, Longitude Uncertainty (LongUnc) is given by the formula: 1212 x = 8 - ceil( log2( 151.2152005 - 151.214495 ) ) 1214 The result of this equation is also 18, or 010010 in binary. 1216 Altitude Uncertainty (AltUnc) uses the formula from Section 2.4.4: 1218 x = 21 - ceil( log2( 33.7 - 0 ) ) 1220 The result of this equation is 15, which is encoded as 001111 in 1221 binary. 1223 Adding an Altitude Type of 1 (meters) and a Datum of 1 (WGS84), this 1224 gives the following DHCPv4 form: 1226 0 1 2 3 1227 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 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Code (123) | OptLen (16) | LatUnc | Latitude . 1230 |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. 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 . Latitude (cont'd) | LongUnc | . 1233 .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. 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 . Longitude (cont'd) | 1236 .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| 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | AType | AltUnc | Altitude . 1239 |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. 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 . Alt (cont'd) |Ver| Res |Datum| 1242 .1 0 1 1 0 0 1 1|0 1|0 0 0|0 0 1| 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 In hexadecimal, this is 7B104BBC 49360D49 2E6E2EC3 13C00021 B341. 1246 The DHCPv6 form only differs in the code and option length portion. 1248 C.1.2. Decoding a Location from DHCP Geodetic Form 1250 If receiving the binary form created in the previous section, this 1251 section describes how that would be interpreted. The result is then 1252 represented as a GML object, as defined in [GeoShape]. 1254 A Latitude value of 1110111100010010010011011000001101 decodes to a 1255 value of -33.8570095003 (to 10 decimal places). The Longitude value 1256 of 0100101110011011100010111011000011 decodes to 151.2152005136. 1258 Decoding Tip: If the raw values of Latitude and Longitude are placed 1259 in integer variables, the actual value can be derived by the 1260 following process: 1262 1. If the highest order bit is set (i.e. the number is a twos 1263 complement negative), then subtract 2 to the power of 34 (the 1264 total number of bits). 1266 2. Divide the result by 2 to the power of 25 (the number of 1267 fractional bits) to determine the final value. 1269 The same principle can be applied when decoding Altitude values, 1270 except with different powers of 2 (30 and 8 respectively). 1272 The Latitude and Longitude Uncertainty are both 18, which gives an 1273 uncertainty value using the formula from Section 2.3.1 of 1274 0.0009765625. Therefore, the decoded Latitudes is -33.8570095003 +/- 1275 0.0009765625 (or the range from -33.8579860628 to -33.8560329378) and 1276 the decoded Longitude is 151.2152005136 +/- 0.0009765625 (or the 1277 range from 151.2142239511 to 151.2161770761). 1279 The encoded Altitude of 000000000000000010000110110011 decodes to 1280 33.69921875. The encoded uncertainty of 15 gives a value of 64, 1281 therefore the final uncertainty is 33.69921875 +/- 64 (or the range 1282 from -30.30078125 to 97.69921875). 1284 C.1.2.1. GML Representation of Decoded Locations 1286 The following GML shows the value decoded in the previous example as 1287 a point in a three dimensional CRS: 1289 1291 -33.8570095003 151.2152005136 33.69921875 1292 1294 The following example uses all of the decoded information from the 1295 previous example: 1297 1300 1301 1302 1303 1304 1305 -33.8579860628 151.2142239511 -30.30078125 1306 -33.8579860628 151.2161770761 -30.30078125 1307 -33.8560329378 151.2161770761 -30.30078125 1308 -33.8560329378 151.2142239511 -30.30078125 1309 -33.8579860628 151.2142239511 -30.30078125 1310 1311 1312 1313 1314 1315 1316 128 1317 1318 1320 Note that this representation is only appropriate if the uncertainty 1321 is sufficiently small. [GeoShape] recommends that distances between 1322 polygon vertices be kept short. A GML representation like this one 1323 is only appropriate where uncertainty is less than 1 degree (an 1324 encoded value of 9 or greater). 1326 Appendix D. Changes from RFC 3825 1328 This section lists the major changes between [RFC3825] and this 1329 document. Minor changes, including style, grammar, spelling and 1330 editorial changes are not mentioned here. 1332 o Section 1 now includes clarifications on wired and wireless uses. 1333 o The former Sections 1.2 and 1.3 have been removed. Section 1.2 1334 now defines the concepts of uncertainty and resolution, as well 1335 as conversion between the DHCP option format and PIDF-LO. 1336 o A DHCPv6 option is now defined (Section 2.1) as well 1337 as a DHCPv4 option (Section 2.2). 1338 o The former Datum field has been split into three fields: 1339 Ver, Res and Datum. These fields are used in both the 1340 DHCPv4 and DHCPv6 options. 1341 o Section 2.2.1 has been added, describing Version support. 1342 o Section 2.3 has been added, describing the Latitude and 1343 Longitude fields. 1344 o Section 2.3.1 has been added, covering Latitude and Longitude 1345 resolution. 1346 o Section 2.3.2 has been added, covering Latitude and Longitude 1347 uncertainty. 1348 o Section 2.4 has been added, covering values of the Altitude 1349 field (Sections 2.4.1, 2.4.2 and 2.4.3), Altitude resolution 1350 (Section 2.4.4), and Altitude uncertainty (Section 2.4.5). 1351 o Section 2.5 has been added, covering the Datum field. 1352 o Section 3 (Security Considerations) has added a recommendation 1353 on link layer confidentiality. 1354 o Section 4 (IANA Considerations) has consolidated material 1355 relating to parameter allocation for both the DHCPv4 and 1356 DHCPv6 option parameters. 1357 o The material formerly in Appendix A has been updated and 1358 shortened and has been moved to Appendix B. 1359 o An Appendix A on GML mapping has been added. 1360 o Appendix C has been added, providing an example of uncertainty 1361 encoding. 1362 o Appendix D has been added, detailing the changes from RFC 3825. 1364 Authors' Addresses 1366 James M. Polk 1367 Cisco Systems 1368 2200 East President George Bush Turnpike 1369 Richardson, Texas 75082 USA 1370 USA 1372 EMail: jmpolk@cisco.com 1374 John Schnizlein 1376 EMail: john@schnizlein.org 1378 Marc Linsner 1379 Cisco Systems 1380 Marco Island, FL 34145 USA 1381 USA 1383 EMail: marc.linsner@cisco.com 1385 Martin Thomson 1386 Andrew 1387 PO Box U40 1388 Wollongong University Campus, NSW 2500 1389 AU 1391 EMail: martin.thomson@andrew.com 1393 Bernard Aboba 1394 Microsoft Corporation 1395 One Microsoft Way 1396 Redmond, WA 98052 USA 1397 USA 1399 EMail: bernarda@microsoft.com