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/