Dynamic Host Configuration Protocol Option for Geodetic Location Information
draft-thomson-geopriv-3825bis-02

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 5, 2009.

Abstract

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with an indication of uncertainty for each. Separate parameters indicate the reference datum for each of these values.

Table of Contents

1.  Introduction
    1.1.  Uncertainty
    1.2.  Major Changes from RFC 3825
    1.3.  Terminology
2.  DHCP Option Format
    2.1.  DHCPv4 Geodetic Location Option
    2.2.  DHCPv6 Geodetic Location Option
    2.3.  Latitude and Longitude Fields
    2.4.  Altitude
    2.5.  Datum
3.  Encoding and Decoding Example
    3.1.  Encoding a Location into DHCP Geodetic Form
    3.2.  Decoding a Location from DHCP Geodetic Form
4.  Security Considerations
5.  IANA Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The physical location of a network device has a range of applications. In particular, emergency telephony applications rely on knowing the location of a caller in order to determine the correct emergency center.

There are two primary means for representing the location of a device; either through geospatial (or geodetic) coordinates, or through civic addresses. A related document [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) describes a DHCP encoding for civic addresses; this document defines an encoding for geodetic location information. Different applications may be more suited to one form of location information; therefore, both the geodetic and civic forms may be used simultaneously.

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [RFC2131], DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315]) option for the coordinate-based geographic location of the client, to be provided by the server.

The goal of this document is to enable a wired Ethernet host to obtain its location. This location information is derived from a wiremap by the DHCP server, using the Circuit-ID Relay Agent Information Option (RAIO) defined (as Sub-Option 1) in RFC 3046 (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) [RFC3046]. The DHCP server is assumed to have access to a service that can correlate a Circuit-ID with the geographic location where the identified circuit terminates. For instance, this might be an Ethernet wall jack.

This geodetic location information option has limited application to wireless technologies, or other instances where a client is able to move without requiring new addressing information. DHCP provides static configuration information, which is not dynamically or automatically refreshed. If a client moves between when the configuration was provided and when the information is used, the information is incorrect.

This document only defines the delivery of location information from the DHCP server to the client, due to security concerns related to using DHCP to update the database. Within the GEOPRIV architecture as defined by RFC 3693 (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.) [RFC3693], the defined mechanism in this document for conveying initial location information is known as a "sighting" function. Sighting functions are not required to have security capabilities and are only intended to be configured in trusted and controlled environments. (A classic example of the sighting function is a Global Positioning System wired directly to a network node.) Further discussion of the protections that must be provided according to RFC 3694 (Danley, M., Mulligan, D., Morris, J., and J. Peterson, “Threat Analysis of the Geopriv Protocol,” February 2004.) [RFC3694] are in the Security Considerations section of this document (Security Considerations).

1.1.  Uncertainty

In the context of location technology, uncertainty is a quantification of errors. Any method for determining location is subject to some sources of error; uncertainty describes the amount of error that is present. Uncertainty might be the coverage area of a wireless transmitter, the extent of a building or a single room.

Uncertainty is usually represented as an area within which the target is located. In this document, each of the three axes can be assigned an uncertainty value. In effect, this describes a rectangular prism.

When representing locations from sources that can quantify uncertainty, the goal is to find the smallest possible rectangular prism that this format can describe. This is achieved by taking the minimum and maximum values on each axis and ensuring that the final encoding covers these points. This increases the region of uncertainty, but ensures that the region that is described encompasses the target location.

1.2.  Major Changes from RFC 3825

An option for DHCPv6 is included in this document.

The way in which uncertainty is described is changed from the previous version. There was some confusion with the way that the word "resolution" was used in the previous version. Uncertainty is now used in place of resolution and more explanation is included.

The uncertainty components have changed in their meaning. The previous version was unclear/misleading on how these values should be interpreted. This is clarified. This is illustrated with a new set of normative examples, including both encoding and decoding of these values. Geographic Markup Language (GML) (Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, “Geographic information - Geography Markup Language (GML),” April 2004.) [OGC.GML‑3.1.1] is used for these examples.

An altitude type of 0 (no altitude) was previously described in text, but not registered in the IANA registry. This document formally registers this type. Altitude type 2 is deprecated in favour of [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.).

1.3.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  DHCP Option Format

This section defines the format for the DHCPv4 and DHCPv6 options. These options use the same basic format, differing only in the option code.

2.1.  DHCPv4 Geodetic Location Option

The format of the geodetic option for DHCPv4 (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [RFC2131] is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Code (123)  |  OptLen (16)  |  LatUnc   |     Latitude      .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                Latitude (cont'd)              |  LongUnc  |   .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                       Longitude (cont'd)                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AType |   AltUnc  |                Altitude                   .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .  Alt (cont'd) |     Datum     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code:

GEOCONF_GEODETIC (8 bits). The code for this DHCPv4 option is 123.

OptLen:

Option Length (8 bits). This option is fixed size, the value of this octet will always be 16.

LatUnc:

Latitude Uncertainty (6 bits). See Section 2.3.1 (Latitude and Longitude Uncertainty).

Latitude:

Latitude (34 bits). See Section 2.3 (Latitude and Longitude Fields).

LongUnc:

Longitude Uncertainty (6 bits). See Section 2.3.1 (Latitude and Longitude Uncertainty).

Longitude:

Longitude (34 bits). See Section 2.3 (Latitude and Longitude Fields).

AType:

Altitude Type (4 bits). See Section 2.4 (Altitude).

AltUnc:

Altitude Uncertainty (6 bits). See Section 2.4.4 (Altitude Uncertainty).

Altitude:

Altitude (30 bits). See Section 2.4 (Altitude).

Datum:

Datum (8 bits). See Section 2.5 (Datum).

2.2.  DHCPv6 Geodetic Location Option

The format of the geodetic option for DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315] is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Option Code (TBD)       |  OptLen (16)  |  LatUnc   |   .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                     Latitude (cont'd)                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  LongUnc  |               Longitude                           .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    . Long (cont'd) | AType |   AltUnc  |         Altitude          .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .      Altitude (cont'd)        |     Datum     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Code:

OPTION_GEOCONF_GEODETIC (16 bits). The code for this DHCPv6 option is TBD.

The remaining fields are identical to the DHCPv4 fields.

2.3.  Latitude and Longitude Fields

The Latitude and Longitude values in this format are encoded as 34 bit, twos complement, fixed point values with 9 integer bits and 25 fractional bits. The exact meaning of these values is determined by the datum; the description in this section applies to the datums defined in this document.

New datums MUST define the way that the 34 bit values and the respective 6 bit uncertainties are interpreted. This document uses the same definition for all datums it specifies.

Latitude values MUST be constrained to the range from -90 to +90 degrees. Positive latitudes are north of the equator; negative latitude are south of the equator.

Longitude values SHOULD be normalized to the range from -180 to +180 degrees. Values outside this range are normalized by adding or subtracting 360 until they fall within this range. Positive longitudes are east of the Prime Meridian (Greenwich); negative longitudes are west of the Prime Meridian.

When encoding, latitude and longitude values are rounded to the nearest 34-bit binary representation. This imprecision is considered acceptable for the purposes to which this form is intended to be applied and is ignored when decoding.

2.3.1.  Latitude and Longitude Uncertainty

The latitude and longitude uncertainty fields are encoded as 6 bit, unsigned integer values. These values quantify the amount of uncertainty in each of the latitude and longitude values respectively. A value of 0 is reserved to indicate that the uncertainty is unknown; values greater than 34 are reserved.

A point within the region of uncertainty is selected to be the encoded point; the centroid of the region is often an appropriate choice. The value for uncertainty is taken as the distance from the selected point to the furthest extreme of the region of uncertainty on that axis.

The following figure shows a two-dimensional figure that is projected to each axis. In the figure, X marks the point that is selected; the ranges marked with U is the uncertainty.

  ___          ___________
  ^ |         /           |
  | |        /            |
  | |       /             |
  U |      /              |
  | |     (               |
  V |     |               |
  --X     |         X     |
    |     |               `---------.
    |     |                         |
    |     |                         |
    |     |                         |
    -     `-------------------------'

          |---------X---------------|
                    |<------U------>|

Uncertainty applies to each axis independently. If necessary, decoders MAY assume a normal distribution and that the overall uncertainty represented is at 95% confidence (which equates to approximately 2.24 standard deviations in each dimension).

The amount of uncertainty can be determined from the encoding by taking 2 to the power of 8, less the encoded value. As is shown in the following formula, where x is the encoded integer value:

    uncertainty = 2 ^ ( 8 - x )

The result of this formula is expressed in degrees of latitude or longitude. The uncertainty is added to the base latitude or longitude value to determine the maximum value in the uncertainty range; similarly, the uncertainty is subtracted from the base value to determine the minimum value. Note that because lines of longitude converge at the poles, the actual distance represented by this uncertainty changes with the distance from the equator.

If the maximum or minimum latitude values derived from applying uncertainty are outside the range of -90 to +90, these values are trimmed to within this range. If the maximum or minimum longitude values derived from applying uncertainty are outside the range of -180 to +180, then these values are normalized to this range by adding or subtracting 360 as necessary.

The encoded value is determined by subtracting the next highest whole integer value for the base 2 logarithm of uncertainty from 8. As is shown by the following formula, where uncertainty is the midpoint of the known range less the lower bound of that range:

    x = 8 - ceil( log2( uncertainty ) )

Note that the result of encoding this value increases the range of uncertainty to the next available power of two; subsequent repeated encodings and decodings do not change the value. Only increasing uncertainty means that the associated confidence does not have to decrease.

2.4.  Altitude

The altitude is expressed as a 30 bit, fixed point, twos complement integer with 22 integer bits and 8 fractional bits. How the altitude value is interpreted depends on the type of altitude and the selected datum.

New altitude types and datums MUST define the way that the 30 bit value and the associated 6 bit uncertainty are interpreted.

Three altitude types are defined in this document: unknown (0), meters (1) and floors (2). Additional altitude types MUST be defined in a Standards Track RFC.

2.4.1.  No Known Altitude (AT = 0)

In some cases, the altitude of the location might not be known. An altitude type of 0 indicates that the altitude is not known. In this case, the altitude and altitude uncertainty fields can contain any value and are ignored.

2.4.2.  Altitude in Meters (AT = 1)

If the altitude type has a value of 1, the altitude is measured in meters. The altitude is measured in relation to the zero set by the vertical datum.

2.4.3.  Altitude in Floors (AT = 2)

A value of 2 for altitude type indicates that the altitude value is measured in floors. This value is relevant only in relation to a building; the value is relative to the ground level of the building. In this definition, numbering starts at ground level, which is floor 0 regardless of local convention.

Non-integer values can be used to represent intermediate or sub-floors, such as mezzanine levels. For instance, a mezzanine between floors 4 and 5 could be represented as 4.1.

Use of altitude in floors is deprecated in favor of the floors field (CAtype 27) in the civic address option (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.) [RFC4776].

2.4.4.  Altitude Uncertainty

Altitude uncertainty uses the same form of expression as latitude and longitude uncertainty. Like latitude and longitude, a value of 0 is reserved to indicate that uncertainty is not known; values above 30 are also reserved. Altitude uncertainty only applies to altitude type 1.

The amount of altitude uncertainty can be determined by the following formula, where x is the encoded integer value:

    uncertainty = 2 ^ ( 21 - x )

This value uses the same units as the associated altitude.

Similarly, a value for the encoded integer value can be derived by the following formula:

    x = 21 - ceil( log2( x ) )

2.5.  Datum

The datum field determines how coordinates are organized and related to the real world. Three datums are defined in this document, based on the definitions in [OGP.Geodesy] (OGP, “International Association of Oil & Gas Producers (OGP) Geodesy Resources,” .):

1: WGS84 (Latitude, Longitude, Altitude):

The World Geodesic System 1984 (US National Imagery and Mapping Agency, “Department of Defense (DoD) World Geodetic System 1984 (WGS 84), Third Edition,” January 2000.) [WGS84] coordinate reference system.

This datum is identified by the European Petroleum Survey Group (EPSG)/International Association of Oil & Gas Producers (OGP) with the code 4979, or by the URN urn:ogc:def:crs:EPSG::4979. Without altitude, this datum is identified by the EPSG/OGP code 4326 and the URN urn:ogc:def:crs:EPSG::4326.

2: NAD83 (Latitude, Longitude) + NAVD88:

This datum uses a combination of the North American Datum 1983 (NAD83) for horizontal (latitude and longitude) values, plus the North American Vertical Datum of 1988 (NAVD88) vertical datum.

This datum is used for referencing location on land (not near tidal water) within North America.

NAD83 is identified by the EPSG/OGP code of 4269, or the URN urn:ogc:def:crs:EPSG::4269. NAVD88 is identified by the EPSG/OGP code of 5703, or the URN urn:ogc:def:crs:EPSG::5703.

3: NAD83 (Latitude, Longitude) + MLLW:

This datum uses a combination of the North American Datum 1983 (NAD83) for horizontal (latitude and longitude) values, plus the Mean Lower Low Water (MLLW) vertical datum.

This datum is used for referencing location on or near tidal water within North America.

NAD83 is identified by the EPSG/OGP code of 4269, or the URN urn:ogc:def:crs:EPSG::4269. MLLW does not have a specific code or URN.

All hosts MUST support the WGS84 datum (Datum 1).

New datum codes can be registered in the IANA registry (IANA Considerations) by a Standards Track RFC. New geodetic coordinate datums MUST be three dimensional that define both horizontal and vertical components.

3.  Encoding and Decoding Example

This section describes an example of encoding and decoding the geodetic DHCP option. The textual results are expressed in GML (Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, “Geographic information - Geography Markup Language (GML),” April 2004.) [OGC.GML‑3.1.1] form, suitable for inclusion in PIDF-LO (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) [RFC4119].

These examples all assume a datum of WGS84 (datum = 1) and an altitude type of meters (AT = 1).

3.1.  Encoding a Location into DHCP Geodetic Form

This example draws a rough polygon around the Sydney Opera House. This polygon consists of the following six points:

    33.856625 S, 151.215906 E
    33.856299 S, 151.215343 E
    33.856326 S, 151.214731 E
    33.857533 S, 151.214495 E
    33.857720 S, 151.214613 E
    33.857369 S, 151.215375 E

The top of the building 67.4 meters above sea level, and a starting altitude of 0 meters above the WGS84 geoid is assumed.

The first step is to determine the range of latitude and longitude values. Latitude ranges from -33.857720 to -33.856299; longitude ranges from 151.214495 to 151.215906.

For this example, the point that is encoded is chosen by finding the middle of each range, that is (-33.8570095, 151.2152005). This is encoded as (1110111100010010010011011000001101, 0100101110011011100010111011000011) in binary, or (3BC49360D, 12E6E2EC3) in hexadecimal notation (with an extra 2 bits of leading padding on each). Altitude is set at 33.7 meters, which is 000000000000000010000110110011 (binary) or 000021B3 (hexadecimal).

The latitude uncertainty is given by inserting the difference between the center value and the outer value into the formula from Section 2.3.1 (Latitude and Longitude Uncertainty). This gives:

     x = 8 - ceil( log2( -33.8570095 - -33.857720 ) )

The result of this equation is 18, therefore the uncertainty is encoded as 010010 in binary.

Similarly, longitude uncertainty is given by the formula:

     x = 8 - ceil( log2( 151.2152005 - 151.214495 ) )

The result of this equation is also 18, or 010010 in binary.

Altitude uncertainty uses the formula from Section 2.4.4 (Altitude Uncertainty):

     x = 21 - ceil( log2( 33.7 - 0 ) )

The result of this equation is 15, which is encoded as 001111 in binary.

Adding an Altitude Type of 1 (meters) and a Datum of 1 (WGS84), this gives the following DHCPv4 form:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Code (123)  |  OptLen (16)  |  LatUnc   |     Latitude      .
    |0 1 1 1 1 0 1 1|0 0 0 1 0 0 0 0|0 1 0 0 1 0|1 1 1 0 1 1 1 1 0 0.
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                Latitude (cont'd)              |  LongUnc  |   .
    .0 1 0 0 1 0 0 1 0 0 1 1 0 1 1 0 0 0 0 0 1 1 0 1|0 1 0 0 1 0|0 1.
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                       Longitude (cont'd)                      |
    .0 0 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 0 1 0 1 1 1 0 1 1 0 0 0 0 1 1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AType |   AltUnc  |                Altitude                   .
    |0 0 0 1|0 0 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1.
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .  Alt (cont'd) |     Datum     |
    .1 0 1 1 0 0 1 1|0 0 0 0 0 0 0 1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In hexadecimal, this is 7B104BBC 49360D49 2E6E2EC3 13C00021 B301. The DHCPv6 form only differs in the code and option length portion.

3.2.  Decoding a Location from DHCP Geodetic Form

If receiving the binary form created in the previous section, this section describes how that would be interpreted. The result is then represented as a GML object, as defined in [GeoShape] (Thomson, M. and C. Reed, “GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF),” December 2006.).

A latitude value of 1110111100010010010011011000001101 decodes to a value of -33.8570095003 (to 10 decimal places). The longitude value of 0100101110011011100010111011000011 decodes to 151.2152005136.

Decoding Tip:

If the raw values of latitude and longitude are placed in integer variables, the actual value can be derived by the following process:

1. If the highest order bit is set (i.e. the number is a twos complement negative), then subtract 2 to the power of 34 (the total number of bits).
2. Divide the result by 2 to the power of 25 (the number of fractional bits) to determine the final value.

The same principle can be applied when decoding altitude values, except with different powers of 2 (30 and 8 respectively).

The latitude and longitude uncertainty are both 18, which gives an uncertainty value using the formula from Section 2.3.1 (Latitude and Longitude Uncertainty) of 0.0009765625. Therefore, the decoded latitudes is -33.8570095003 +/- 0.0009765625 (or the range from -33.8579860628 to -33.8560329378) and the decoded longitude is 151.2152005136 +/- 0.0009765625 (or the range from 151.2142239511 to 151.2161770761).

The encoded altitude of 000000000000000010000110110011 decodes to 33.69921875. The encoded uncertainty of 15 gives a value of 64, therefore the final uncertainty is 33.69921875 +/- 64 (or the range from -30.30078125 to 97.69921875).

3.2.1.  GML Representation of Decoded Locations

The GML representation of a decoded DHCP option depends on what fields are specified. Uncertainty can be omitted from all of the respective fields, and altitude can also be absent.

In the absence of uncertainty information, the value decoded from the DHCP form can be expressed as a single point. If the point includes altitude, it uses a three dimensional CRS, otherwise it uses a two dimensional CRS.

The following GML shows the value decoded in the previous example as a point in a three dimensional CRS:

    <gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
               xmlns:gml="http://www.opengis.net/gml">
      <gml:pos>-33.8570095003 151.2152005136 33.69921875</gml:pos>
    </gml:Point>

If all fields are included along with uncertainty, the shape described is a rectangular prism. Note that this is necessary given that uncertainty for each axis is provided idependently.

The following example uses all of the decoded information from the previous example:

  <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"
      xmlns:gs="http://www.opengis.net/pidflo/1.0"
      xmlns:gml="http://www.opengis.net/gml">
    <gs:base>
      <gml:Polygon>
        <gml:exterior>
          <gml:LinearRing>
            <gml:posList>
              -33.8579860628 151.2142239511 -30.30078125
              -33.8579860628 151.2161770761 -30.30078125
              -33.8560329378 151.2161770761 -30.30078125
              -33.8560329378 151.2142239511 -30.30078125
              -33.8579860628 151.2142239511 -30.30078125
            </gml:posList>
          </gml:LinearRing>
        </gml:exterior>
      </gml:Polygon>
    </gs:base>
    <gs:height uom="urn:ogc:def:uom:EPSG::9001">
      128
    </gs:height>
  </gs:Prism>

Note that this representation is only appropriate if the uncertainty is sufficiently small. [GeoShape] (Thomson, M. and C. Reed, “GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF),” December 2006.) recommends that distances between polygon vertices be kept short. A GML representation like this one is only appropriate where uncertainty is less than 1 degree (an encoded value of 9 or greater).

If altitude or altitude uncertainty is not specified, the shape is described as a rectangle using the gml:Polygon shape. If altitude is available, a three dimensional CRS is used, otherwise a two dimensional CRS is used.

For Datum values of 2 or 3 (NAD83), there is no available CRS URN that covers three dimensional coordinates. By necessity, locations described in these datums can be represented by two dimensional shapes only; that is, either a two dimensional point or a polygon.

If the altitude type is 2 (floors), then this value can be represented using a civic address object (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) [RFC5139] that is presented alongside the geodetic object.

4.  Security Considerations

Security considerations related to the privacy of location information as discussed in the GEOPRIV documents RFC 3693 (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.) [RFC3693] and RFC 3694 (Danley, M., Mulligan, D., Morris, J., and J. Peterson, “Threat Analysis of the Geopriv Protocol,” February 2004.) [RFC3694] apply.

Where critical decisions might be based on the value of this option, DHCPv4 authentication in RFC 3118 (Droms, R. and W. Arbaugh, “Authentication for DHCP Messages,” June 2001.) [RFC3118] SHOULD be used to protect the integrity of the DHCP options.

Since there is no privacy protection for DHCP messages, an eavesdropper who can monitor the link between the DHCP server and requesting client can discover this option. Thus, usage of the option on networks without access restrictions or network-layer or link-layer privacy protection is NOT RECOMMENDED.

To minimize the unintended exposure of location information, the GEOCONF_GEODETIC option SHOULD be returned by DHCPv4 servers only when the DHCPv4 client has included this option in its 'parameter request list' (RFC 2131 (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [RFC2131], Section 3.5). Similarly, the OPTION_GEOCONF_GEODETIC option SHOULD be returned by DHCPv6 servers only when the DHCPv6 client has included this option in its OPTION_ORO.

After initial location information has been introduced, it MUST be afforded the protections defined in RFC 3694 (Danley, M., Mulligan, D., Morris, J., and J. Peterson, “Threat Analysis of the Geopriv Protocol,” February 2004.) [RFC3694]. Therefore, location information SHOULD NOT be sent from a DHCP client to a DHCP server. If a client decides to send location information to the server, it is implicitly granting that server unlimited retention and distribution permissions.

5.  IANA Considerations

The IANA has registered DHCPv4 and DHCPv6 option codes for the Geodetic Location option (GEOCONF_GEODETIC = 123 and OPTION_GEOCONF_GEODETIC = XXX, respectively).

The IANA has established two registries for GeoConf items: the altitude type field (Altitude) and the datum field (Datum). It is requested of IANA that the registry refer to this document for the definition of these items. New values for both these registries require "Standards Action" (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.) [RFC2434].

Values registered in the Altitude Type registry are:

AT = 0

denotes that no altitude information is present

AT = 1

denotes an altitude in meters as defined by the associated datum

AT = 2

denotes an altitude in floors within the context of a building (deprecated)

Values registered in the Datum registry are:

Datum = 1

denotes the WGS84 datum as defined by the EPSG/OGP with the code 4326 (with no altitude) or 4979 (with altitude)

Datum = 2

denotes the NAD83 datum for latitude and longitude as defined by the EPSG/OGP with the code of 4269 (no altitude); the corresponding vertical datum is the North American Vertical Datum of 1988 (NAVD88) as defined by the EPSG/OGP with the code of 5703

Datum = 3

denotes the NAD83 datum for latitude and longitude as defined by the EPSG/OGP with the code of 4269 (no altitude); the corresponding vertical datum is the Mean Lower Low Water (MLLW)

6.  Acknowledgements

Special thanks go to Klaus Darilion and Alexander Mayrhofer for reviewing the document and pointing out a few errors.

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.