idnits 2.17.1 draft-thomson-geopriv-3825bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 18, 2009) is 5578 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV WG M. Thomson 3 Internet-Draft J. Winterbottom 4 Obsoletes: 3825 (if approved) Andrew 5 Intended status: Standards Track January 18, 2009 6 Expires: July 22, 2009 8 Dynamic Host Configuration Protocol Option for Geodetic Location 9 Information 10 draft-thomson-geopriv-3825bis-03 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 22, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This document specifies a Dynamic Host Configuration Protocol (DHCPv4 50 and DHCPv6) Option for the coordinate-based geographic location of 51 the client. The Location Configuration Information (LCI) includes 52 latitude, longitude, and altitude, with an indication of uncertainty 53 for each. Separate parameters indicate the reference datum for each 54 of these values. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Uncertainty . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Major Changes from RFC 3825 . . . . . . . . . . . . . . . 4 61 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. DHCP Option Format . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. DHCPv4 Geodetic Location Option . . . . . . . . . . . . . 5 64 2.2. DHCPv6 Geodetic Location Option . . . . . . . . . . . . . 6 65 2.3. Latitude and Longitude Fields . . . . . . . . . . . . . . 6 66 2.4. Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.5. Datum . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3. Encoding and Decoding Example . . . . . . . . . . . . . . . . 11 69 3.1. Encoding a Location into DHCP Geodetic Form . . . . . . . 11 70 3.2. Decoding a Location from DHCP Geodetic Form . . . . . . . 12 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 76 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 79 1. Introduction 81 The physical location of a network device has a range of 82 applications. In particular, emergency telephony applications rely 83 on knowing the location of a caller in order to determine the correct 84 emergency center. 86 There are two primary means for representing the location of a 87 device; either through geospatial (or geodetic) coordinates, or 88 through civic addresses. A related document [RFC4776] describes a 89 DHCP encoding for civic addresses; this document defines an encoding 90 for geodetic location information. Different applications may be 91 more suited to one form of location information; therefore, both the 92 geodetic and civic forms may be used simultaneously. 94 This document specifies a Dynamic Host Configuration Protocol (DHCPv4 95 [RFC2131], DHCPv6 [RFC3315]) option for the coordinate-based 96 geographic location of the client, to be provided by the server. 98 The goal of this document is to enable a wired Ethernet host to 99 obtain its location. This location information is derived from a 100 wiremap by the DHCP server, using the Circuit-ID Relay Agent 101 Information Option (RAIO) defined (as Sub-Option 1) in RFC 3046 102 [RFC3046]. The DHCP server is assumed to have access to a service 103 that can correlate a Circuit-ID with the geographic location where 104 the identified circuit terminates. For instance, this might be an 105 Ethernet wall jack. 107 This geodetic location information option has limited application to 108 wireless technologies, or other instances where a client is able to 109 move without requiring new addressing information. DHCP provides 110 static configuration information, which is not dynamically or 111 automatically refreshed. If a client moves between when the 112 configuration was provided and when the information is used, the 113 information is incorrect. 115 This document only defines the delivery of location information from 116 the DHCP server to the client, due to security concerns related to 117 using DHCP to update the database. Within the GEOPRIV architecture 118 as defined by RFC 3693 [RFC3693], the defined mechanism in this 119 document for conveying initial location information is known as a 120 "sighting" function. Sighting functions are not required to have 121 security capabilities and are only intended to be configured in 122 trusted and controlled environments. (A classic example of the 123 sighting function is a Global Positioning System wired directly to a 124 network node.) Further discussion of the protections that must be 125 provided according to RFC 3694 [RFC3694] are in the Security 126 Considerations section of this document (Section 4). 128 1.1. Uncertainty 130 In the context of location technology, uncertainty is a 131 quantification of errors. Any method for determining location is 132 subject to some sources of error; uncertainty describes the amount of 133 error that is present. Uncertainty might be the coverage area of a 134 wireless transmitter, the extent of a building or a single room. 136 Uncertainty is usually represented as an area within which the target 137 is located. In this document, each of the three axes can be assigned 138 an uncertainty value. In effect, this describes a rectangular prism. 140 When representing locations from sources that can quantify 141 uncertainty, the goal is to find the smallest possible rectangular 142 prism that this format can describe. This is achieved by taking the 143 minimum and maximum values on each axis and ensuring that the final 144 encoding covers these points. This increases the region of 145 uncertainty, but ensures that the region that is described 146 encompasses the target location. 148 1.2. Major Changes from RFC 3825 150 An option for DHCPv6 is included in this document. 152 The way in which uncertainty is described is changed from the 153 previous version. There was some confusion with the way that the 154 word "resolution" was used in the previous version. Uncertainty is 155 now used in place of resolution and more explanation is included. 157 The uncertainty components have changed in their meaning. The 158 previous version was unclear/misleading on how these values should be 159 interpreted. This is clarified. This is illustrated with a new set 160 of normative examples, including both encoding and decoding of these 161 values. Geographic Markup Language (GML) [OGC.GML-3.1.1] is used for 162 these examples. 164 An altitude type of 0 (no altitude) was previously described in text, 165 but not registered in the IANA registry. This document formally 166 registers this type. Altitude type 2 is deprecated in favour of 167 [RFC4776]. 169 1.3. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 2. DHCP Option Format 177 This section defines the format for the DHCPv4 and DHCPv6 options. 178 These options use the same basic format, differing only in the option 179 code. 181 2.1. DHCPv4 Geodetic Location Option 183 The format of the geodetic option for DHCPv4 [RFC2131] is as follows: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Code (123) | OptLen (16) | LatUnc | Latitude . 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 . Latitude (cont'd) | LongUnc | . 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 . Longitude (cont'd) | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | AType | AltUnc | Altitude . 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 . Alt (cont'd) | Datum | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Code: GEOCONF_GEODETIC (8 bits). The code for this DHCPv4 option is 200 123. 202 OptLen: Option Length (8 bits). This option is fixed size, the 203 value of this octet will always be 16. 205 LatUnc: Latitude Uncertainty (6 bits). See Section 2.3.1. 207 Latitude: Latitude (34 bits). See Section 2.3. 209 LongUnc: Longitude Uncertainty (6 bits). See Section 2.3.1. 211 Longitude: Longitude (34 bits). See Section 2.3. 213 AType: Altitude Type (4 bits). See Section 2.4. 215 AltUnc: Altitude Uncertainty (6 bits). See Section 2.4.4. 217 Altitude: Altitude (30 bits). See Section 2.4. 219 Datum: Datum (8 bits). See Section 2.5. 221 2.2. DHCPv6 Geodetic Location Option 223 The format of the geodetic option for DHCPv6 [RFC3315] is as follows: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Option Code (TBD) | OptLen (16) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | LatUnc | Latitude | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Lat. (cont'd) | LongUnc | Longitude | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Longitude (cont'd) | AType | AltUnc | Altitude | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Altitude (cont'd) | Datum | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Option Code: OPTION_GEOCONF_GEODETIC (16 bits). The code for this 240 DHCPv6 option is TBD. 242 The remaining fields are identical to the DHCPv4 fields. 244 2.3. Latitude and Longitude Fields 246 The Latitude and Longitude values in this format are encoded as 34 247 bit, twos complement, fixed point values with 9 integer bits and 25 248 fractional bits. The exact meaning of these values is determined by 249 the datum; the description in this section applies to the datums 250 defined in this document. 252 New datums MUST define the way that the 34 bit values and the 253 respective 6 bit uncertainties are interpreted. This document uses 254 the same definition for all datums it specifies. 256 Latitude values MUST be constrained to the range from -90 to +90 257 degrees. Positive latitudes are north of the equator; negative 258 latitude are south of the equator. 260 Longitude values SHOULD be normalized to the range from -180 to +180 261 degrees. Values outside this range are normalized by adding or 262 subtracting 360 until they fall within this range. Positive 263 longitudes are east of the Prime Meridian (Greenwich); negative 264 longitudes are west of the Prime Meridian. 266 When encoding, latitude and longitude values are rounded to the 267 nearest 34-bit binary representation. This imprecision is considered 268 acceptable for the purposes to which this form is intended to be 269 applied and is ignored when decoding. 271 2.3.1. Latitude and Longitude Uncertainty 273 The latitude and longitude uncertainty fields are encoded as 6 bit, 274 unsigned integer values. These values quantify the amount of 275 uncertainty in each of the latitude and longitude values 276 respectively. A value of 0 is reserved to indicate that the 277 uncertainty is unknown; values greater than 34 are reserved. 279 A point within the region of uncertainty is selected to be the 280 encoded point; the centroid of the region is often an appropriate 281 choice. The value for uncertainty is taken as the distance from the 282 selected point to the furthest extreme of the region of uncertainty 283 on that axis. 285 The following figure shows a two-dimensional figure that is projected 286 to each axis. In the figure, "X" marks the point that is selected; 287 the ranges marked with "U" is the uncertainty. 289 ___ ___________ 290 ^ | / | 291 | | / | 292 | | / | 293 U | / | 294 | | ( | 295 V | | | 296 --X | X | 297 | | `---------. 298 | | | 299 | | | 300 | | | 301 - `-------------------------' 303 |---------X---------------| 304 |<------U------>| 306 Uncertainty applies to each axis independently. If necessary, 307 decoders MAY assume a normal distribution and that the overall 308 uncertainty represented is at 95% confidence (which equates to 309 approximately 2.24 standard deviations in each dimension). 311 The amount of uncertainty can be determined from the encoding by 312 taking 2 to the power of 8, less the encoded value. As is shown in 313 the following formula, where "x" is the encoded integer value: 314 uncertainty = 2 ^ ( 8 - x ) 315 The result of this formula is expressed in degrees of latitude or 316 longitude. The uncertainty is added to the base latitude or 317 longitude value to determine the maximum value in the uncertainty 318 range; similarly, the uncertainty is subtracted from the base value 319 to determine the minimum value. Note that because lines of longitude 320 converge at the poles, the actual distance represented by this 321 uncertainty changes with the distance from the equator. 323 If the maximum or minimum latitude values derived from applying 324 uncertainty are outside the range of -90 to +90, these values are 325 trimmed to within this range. If the maximum or minimum longitude 326 values derived from applying uncertainty are outside the range of 327 -180 to +180, then these values are normalized to this range by 328 adding or subtracting 360 as necessary. 330 The encoded value is determined by subtracting the next highest whole 331 integer value for the base 2 logarithm of uncertainty from 8. As is 332 shown by the following formula, where uncertainty is the midpoint of 333 the known range less the lower bound of that range: 334 x = 8 - ceil( log2( uncertainty ) ) 335 Note that the result of encoding this value increases the range of 336 uncertainty to the next available power of two; subsequent repeated 337 encodings and decodings do not change the value. Only increasing 338 uncertainty means that the associated confidence does not have to 339 decrease. 341 2.4. Altitude 343 The altitude is expressed as a 30 bit, fixed point, twos complement 344 integer with 22 integer bits and 8 fractional bits. How the altitude 345 value is interpreted depends on the type of altitude and the selected 346 datum. 348 New altitude types and datums MUST define the way that the 30 bit 349 value and the associated 6 bit uncertainty are interpreted. 351 Three altitude types are defined in this document: unknown (0), 352 meters (1) and floors (2). Additional altitude types MUST be defined 353 in a Standards Track RFC. 355 2.4.1. No Known Altitude (AT = 0) 357 In some cases, the altitude of the location might not be known. An 358 altitude type of 0 indicates that the altitude is not known. In this 359 case, the altitude and altitude uncertainty fields can contain any 360 value and are ignored. 362 2.4.2. Altitude in Meters (AT = 1) 364 If the altitude type has a value of 1, the altitude is measured in 365 meters. The altitude is measured in relation to the zero set by the 366 vertical datum. 368 2.4.3. Altitude in Floors (AT = 2) 370 A value of 2 for altitude type indicates that the altitude value is 371 measured in floors. This value is relevant only in relation to a 372 building; the value is relative to the ground level of the building. 373 In this definition, numbering starts at ground level, which is floor 374 0 regardless of local convention. 376 Non-integer values can be used to represent intermediate or sub- 377 floors, such as mezzanine levels. For instance, a mezzanine between 378 floors 4 and 5 could be represented as 4.1. 380 Use of altitude in floors is deprecated in favor of the floors field 381 (CAtype 27) in the civic address option [RFC4776]. 383 2.4.4. Altitude Uncertainty 385 Altitude uncertainty uses the same form of expression as latitude and 386 longitude uncertainty. Like latitude and longitude, a value of 0 is 387 reserved to indicate that uncertainty is not known; values above 30 388 are also reserved. Altitude uncertainty only applies to altitude 389 type 1. 391 The amount of altitude uncertainty can be determined by the following 392 formula, where x is the encoded integer value: 393 uncertainty = 2 ^ ( 21 - x ) 394 This value uses the same units as the associated altitude. 396 Similarly, a value for the encoded integer value can be derived by 397 the following formula: 398 x = 21 - ceil( log2( x ) ) 400 2.5. Datum 402 The datum field determines how coordinates are organized and related 403 to the real world. Three datums are defined in this document, based 404 on the definitions in [OGP.Geodesy]: 406 1: WGS84 (Latitude, Longitude, Altitude): 407 The World Geodesic System 1984 [WGS84] coordinate reference 408 system. 410 This datum is identified by the European Petroleum Survey Group 411 (EPSG)/International Association of Oil & Gas Producers (OGP) with 412 the code 4979, or by the URN "urn:ogc:def:crs:EPSG::4979". 413 Without altitude, this datum is identified by the EPSG/OGP code 414 4326 and the URN "urn:ogc:def:crs:EPSG::4326". 416 2: NAD83 (Latitude, Longitude) + NAVD88: 417 This datum uses a combination of the North American Datum 1983 418 (NAD83) for horizontal (latitude and longitude) values, plus the 419 North American Vertical Datum of 1988 (NAVD88) vertical datum. 421 This datum is used for referencing location on land (not near 422 tidal water) within North America. 424 NAD83 is identified by the EPSG/OGP code of 4269, or the URN 425 "urn:ogc:def:crs:EPSG::4269". NAVD88 is identified by the EPSG/ 426 OGP code of 5703, or the URN "urn:ogc:def:crs:EPSG::5703". 428 3: NAD83 (Latitude, Longitude) + MLLW: 429 This datum uses a combination of the North American Datum 1983 430 (NAD83) for horizontal (latitude and longitude) values, plus the 431 Mean Lower Low Water (MLLW) vertical datum. 433 This datum is used for referencing location on or near tidal water 434 within North America. 436 NAD83 is identified by the EPSG/OGP code of 4269, or the URN 437 "urn:ogc:def:crs:EPSG::4269". MLLW does not have a specific code 438 or URN. 440 All hosts MUST support the WGS84 datum (Datum 1). 442 New datum codes can be registered in the IANA registry (Section 5) by 443 a Standards Track RFC. New geodetic coordinate datums MUST be three 444 dimensional that define both horizontal and vertical components. 446 3. Encoding and Decoding Example 448 This section describes an example of encoding and decoding the 449 geodetic DHCP option. The textual results are expressed in GML 450 [OGC.GML-3.1.1] form, suitable for inclusion in PIDF-LO [RFC4119]. 452 These examples all assume a datum of WGS84 (datum = 1) and an 453 altitude type of meters (AT = 1). 455 3.1. Encoding a Location into DHCP Geodetic Form 457 This example draws a rough polygon around the Sydney Opera House. 458 This polygon consists of the following six points: 460 33.856625 S, 151.215906 E 461 33.856299 S, 151.215343 E 462 33.856326 S, 151.214731 E 463 33.857533 S, 151.214495 E 464 33.857720 S, 151.214613 E 465 33.857369 S, 151.215375 E 467 The top of the building 67.4 meters above sea level, and a starting 468 altitude of 0 meters above the WGS84 geoid is assumed. 470 The first step is to determine the range of latitude and longitude 471 values. Latitude ranges from -33.857720 to -33.856299; longitude 472 ranges from 151.214495 to 151.215906. 474 For this example, the point that is encoded is chosen by finding the 475 middle of each range, that is (-33.8570095, 151.2152005). This is 476 encoded as (1110111100010010010011011000001101, 477 0100101110011011100010111011000011) in binary, or (3BC49360D, 478 12E6E2EC3) in hexadecimal notation (with an extra 2 bits of leading 479 padding on each). Altitude is set at 33.7 meters, which is 480 000000000000000010000110110011 (binary) or 000021B3 (hexadecimal). 482 The latitude uncertainty is given by inserting the difference between 483 the center value and the outer value into the formula from 484 Section 2.3.1. This gives: 485 x = 8 - ceil( log2( -33.8570095 - -33.857720 ) ) 486 The result of this equation is 18, therefore the uncertainty is 487 encoded as 010010 in binary. 489 Similarly, longitude uncertainty is given by the formula: 490 x = 8 - ceil( log2( 151.2152005 - 151.214495 ) ) 491 The result of this equation is also 18, or 010010 in binary. 493 Altitude uncertainty uses the formula from Section 2.4.4: 494 x = 21 - ceil( log2( 33.7 - 0 ) ) 495 The result of this equation is 15, which is encoded as 001111 in 496 binary. 498 Adding an Altitude Type of 1 (meters) and a Datum of 1 (WGS84), this 499 gives the following DHCPv4 form: 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Code (123) | OptLen (16) | LatUnc | Latitude . 505 |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. 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 . Latitude (cont'd) | LongUnc | . 508 .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. 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 . Longitude (cont'd) | 511 .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| 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | AType | AltUnc | Altitude . 514 |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. 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 . Alt (cont'd) | Datum | 517 .1 0 1 1 0 0 1 1|0 0 0 0 0 0 0 1| 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 In hexadecimal, this is 7B104BBC 49360D49 2E6E2EC3 13C00021 B301. 521 The DHCPv6 form only differs in the code and option length portion. 523 3.2. Decoding a Location from DHCP Geodetic Form 525 If receiving the binary form created in the previous section, this 526 section describes how that would be interpreted. The result is then 527 represented as a GML object, as defined in [GeoShape]. 529 A latitude value of 1110111100010010010011011000001101 decodes to a 530 value of -33.8570095003 (to 10 decimal places). The longitude value 531 of 0100101110011011100010111011000011 decodes to 151.2152005136. 533 Decoding Tip: If the raw values of latitude and longitude are placed 534 in integer variables, the actual value can be derived by the 535 following process: 537 1. If the highest order bit is set (i.e. the number is a twos 538 complement negative), then subtract 2 to the power of 34 (the 539 total number of bits). 541 2. Divide the result by 2 to the power of 25 (the number of 542 fractional bits) to determine the final value. 544 The same principle can be applied when decoding altitude values, 545 except with different powers of 2 (30 and 8 respectively). 547 The latitude and longitude uncertainty are both 18, which gives an 548 uncertainty value using the formula from Section 2.3.1 of 549 0.0009765625. Therefore, the decoded latitudes is -33.8570095003 +/- 550 0.0009765625 (or the range from -33.8579860628 to -33.8560329378) and 551 the decoded longitude is 151.2152005136 +/- 0.0009765625 (or the 552 range from 151.2142239511 to 151.2161770761). 554 The encoded altitude of 000000000000000010000110110011 decodes to 555 33.69921875. The encoded uncertainty of 15 gives a value of 64, 556 therefore the final uncertainty is 33.69921875 +/- 64 (or the range 557 from -30.30078125 to 97.69921875). 559 3.2.1. GML Representation of Decoded Locations 561 The GML representation of a decoded DHCP option depends on what 562 fields are specified. Uncertainty can be omitted from all of the 563 respective fields, and altitude can also be absent. 565 In the absence of uncertainty information, the value decoded from the 566 DHCP form can be expressed as a single point. If the point includes 567 altitude, it uses a three dimensional CRS, otherwise it uses a two 568 dimensional CRS. 570 The following GML shows the value decoded in the previous example as 571 a point in a three dimensional CRS: 573 575 -33.8570095003 151.2152005136 33.69921875 576 578 If all fields are included along with uncertainty, the shape 579 described is a rectangular prism. Note that this is necessary given 580 that uncertainty for each axis is provided idependently. 582 The following example uses all of the decoded information from the 583 previous example: 585 588 589 590 591 592 593 -33.8579860628 151.2142239511 -30.30078125 594 -33.8579860628 151.2161770761 -30.30078125 595 -33.8560329378 151.2161770761 -30.30078125 596 -33.8560329378 151.2142239511 -30.30078125 597 -33.8579860628 151.2142239511 -30.30078125 598 599 600 601 602 603 604 128 605 606 608 Note that this representation is only appropriate if the uncertainty 609 is sufficiently small. [GeoShape] recommends that distances between 610 polygon vertices be kept short. A GML representation like this one 611 is only appropriate where uncertainty is less than 1 degree (an 612 encoded value of 9 or greater). 614 If altitude or altitude uncertainty is not specified, the shape is 615 described as a rectangle using the "gml:Polygon" shape. If altitude 616 is available, a three dimensional CRS is used, otherwise a two 617 dimensional CRS is used. 619 For Datum values of 2 or 3 (NAD83), there is no available CRS URN 620 that covers three dimensional coordinates. By necessity, locations 621 described in these datums can be represented by two dimensional 622 shapes only; that is, either a two dimensional point or a polygon. 624 If the altitude type is 2 (floors), then this value can be 625 represented using a civic address object [RFC5139] that is presented 626 alongside the geodetic object. 628 4. Security Considerations 630 Security considerations related to the privacy of location 631 information as discussed in the GEOPRIV documents RFC 3693 [RFC3693] 632 and RFC 3694 [RFC3694] apply. 634 Where critical decisions might be based on the value of this option, 635 DHCPv4 authentication in RFC 3118 [RFC3118] SHOULD be used to protect 636 the integrity of the DHCP options. 638 Since there is no privacy protection for DHCP messages, an 639 eavesdropper who can monitor the link between the DHCP server and 640 requesting client can discover this option. Thus, usage of the 641 option on networks without access restrictions or network-layer or 642 link-layer privacy protection is NOT RECOMMENDED. 644 To minimize the unintended exposure of location information, the 645 "GEOCONF_GEODETIC" option SHOULD be returned by DHCPv4 servers only 646 when the DHCPv4 client has included this option in its 'parameter 647 request list' (RFC 2131 [RFC2131], Section 3.5). Similarly, the 648 "OPTION_GEOCONF_GEODETIC" option SHOULD be returned by DHCPv6 servers 649 only when the DHCPv6 client has included this option in its 650 "OPTION_ORO". 652 After initial location information has been introduced, it MUST be 653 afforded the protections defined in RFC 3694 [RFC3694]. Therefore, 654 location information SHOULD NOT be sent from a DHCP client to a DHCP 655 server. If a client decides to send location information to the 656 server, it is implicitly granting that server unlimited retention and 657 distribution permissions. 659 5. IANA Considerations 661 The IANA has registered DHCPv4 and DHCPv6 option codes for the 662 Geodetic Location option (GEOCONF_GEODETIC = 123 and 663 OPTION_GEOCONF_GEODETIC = XXX, respectively). 665 The IANA has established two registries for GeoConf items: the 666 altitude type field (Section 2.4) and the datum field (Section 2.5). 667 It is requested of IANA that the registry refer to this document for 668 the definition of these items. New values for both these registries 669 require "Standards Action" [RFC2434]. 671 Values registered in the Altitude Type registry are: 673 AT = 0 denotes that no altitude information is present 675 AT = 1 denotes an altitude in meters as defined by the associated 676 datum 678 AT = 2 denotes an altitude in floors within the context of a 679 building (deprecated) 681 Values registered in the Datum registry are: 683 Datum = 1 denotes the WGS84 datum as defined by the EPSG/OGP with 684 the code 4326 (with no altitude) or 4979 (with altitude) 686 Datum = 2 denotes the NAD83 datum for latitude and longitude as 687 defined by the EPSG/OGP with the code of 4269 (no altitude); the 688 corresponding vertical datum is the North American Vertical Datum 689 of 1988 (NAVD88) as defined by the EPSG/OGP with the code of 5703 691 Datum = 3 denotes the NAD83 datum for latitude and longitude as 692 defined by the EPSG/OGP with the code of 4269 (no altitude); the 693 corresponding vertical datum is the Mean Lower Low Water (MLLW) 695 6. Acknowledgements 697 Special thanks go to Klaus Darilion and Alexander Mayrhofer for 698 reviewing the document and pointing out a few errors. 700 7. References 702 7.1. Normative References 704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 705 Requirement Levels", BCP 14, RFC 2119, March 1997. 707 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 708 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 709 October 1998. 711 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 712 RFC 2131, March 1997. 714 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 715 Messages", RFC 3118, June 2001. 717 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 718 and M. Carney, "Dynamic Host Configuration Protocol for 719 IPv6 (DHCPv6)", RFC 3315, July 2003. 721 7.2. Informative References 723 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 724 RFC 3046, January 2001. 726 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 727 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 729 [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, 730 "Threat Analysis of the Geopriv Protocol", RFC 3694, 731 February 2004. 733 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 734 Format", RFC 4119, December 2005. 736 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 737 (DHCPv4 and DHCPv6) Option for Civic Addresses 738 Configuration Information", RFC 4776, November 2006. 740 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 741 Format for Presence Information Data Format Location 742 Object (PIDF-LO)", RFC 5139, February 2008. 744 [GeoShape] 745 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 746 Application Schema for use by the Internet Engineering 747 Task Force (IETF)", Candidate OpenGIS Implementation 748 Specification 06-142, Version: 0.0.9, December 2006. 750 [OGP.Geodesy] 751 OGP, "International Association of Oil & Gas Producers 752 (OGP) Geodesy Resources", 753 . 755 [WGS84] US National Imagery and Mapping Agency, "Department of 756 Defense (DoD) World Geodetic System 1984 (WGS 84), Third 757 Edition", NIMA TR8350.2, January 2000. 759 [OGC.GML-3.1.1] 760 Cox, S., Daisey, P., Lake, R., Portele, C., and A. 761 Whiteside, "Geographic information - Geography Markup 762 Language (GML)", OpenGIS 03-105r1, April 2004, 763 . 766 Authors' Addresses 768 Martin Thomson 769 Andrew 770 PO Box U40 771 Wollongong University Campus, NSW 2500 772 AU 774 Phone: +61 2 4221 2915 775 Email: martin.thomson@andrew.com 776 URI: http://www.andrew.com/ 778 James Winterbottom 779 Andrew 780 PO Box U40 781 Wollongong University Campus, NSW 2500 782 AU 784 Phone: +61 2 4221 2938 785 Email: james.winterbottom@andrew.com 786 URI: http://www.andrew.com/