[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 3825) 00 01 02 03

GEOPRIV WG                                                    M. Thomson
Internet-Draft                                           J. Winterbottom
Obsoletes: 3825 (if approved)                                     Andrew
Intended status: Standards Track                        January 18, 2009
Expires: July 22, 2009


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 July 22, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.






Thomson & Winterbottom    Expires July 22, 2009                 [Page 1]


Internet-Draft                DHCP Geodetic                 January 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Uncertainty  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Major Changes from RFC 3825  . . . . . . . . . . . . . . .  4
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  DHCP Option Format . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  DHCPv4 Geodetic Location Option  . . . . . . . . . . . . .  5
     2.2.  DHCPv6 Geodetic Location Option  . . . . . . . . . . . . .  6
     2.3.  Latitude and Longitude Fields  . . . . . . . . . . . . . .  6
     2.4.  Altitude . . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.5.  Datum  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.  Encoding and Decoding Example  . . . . . . . . . . . . . . . . 11
     3.1.  Encoding a Location into DHCP Geodetic Form  . . . . . . . 11
     3.2.  Decoding a Location from DHCP Geodetic Form  . . . . . . . 12
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20



















Thomson & Winterbottom    Expires July 22, 2009                 [Page 2]


Internet-Draft                DHCP Geodetic                 January 2009


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] 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
   [RFC2131], DHCPv6 [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
   [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 [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 [RFC3694] are in the Security
   Considerations section of this document (Section 4).



Thomson & Winterbottom    Expires July 22, 2009                 [Page 3]


Internet-Draft                DHCP Geodetic                 January 2009


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) [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].

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].





Thomson & Winterbottom    Expires July 22, 2009                 [Page 4]


Internet-Draft                DHCP Geodetic                 January 2009


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 [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:  Latitude (34 bits).  See Section 2.3.

   LongUnc:  Longitude Uncertainty (6 bits).  See Section 2.3.1.

   Longitude:  Longitude (34 bits).  See Section 2.3.

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

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

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

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






Thomson & Winterbottom    Expires July 22, 2009                 [Page 5]


Internet-Draft                DHCP Geodetic                 January 2009


2.2.  DHCPv6 Geodetic Location Option

   The format of the geodetic option for DHCPv6 [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                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Lat. (cont'd) |  LongUnc  |               Longitude           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Longitude (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



Thomson & Winterbottom    Expires July 22, 2009                 [Page 6]


Internet-Draft                DHCP Geodetic                 January 2009


   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



Thomson & Winterbottom    Expires July 22, 2009                 [Page 7]


Internet-Draft                DHCP Geodetic                 January 2009


   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.






Thomson & Winterbottom    Expires July 22, 2009                 [Page 8]


Internet-Draft                DHCP Geodetic                 January 2009


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 [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]:

   1: WGS84 (Latitude, Longitude, Altitude):
      The World Geodesic System 1984 [WGS84] coordinate reference
      system.




Thomson & Winterbottom    Expires July 22, 2009                 [Page 9]


Internet-Draft                DHCP Geodetic                 January 2009


      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 (Section 5) by
   a Standards Track RFC.  New geodetic coordinate datums MUST be three
   dimensional that define both horizontal and vertical components.
















Thomson & Winterbottom    Expires July 22, 2009                [Page 10]


Internet-Draft                DHCP Geodetic                 January 2009


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
   [OGC.GML-3.1.1] form, suitable for inclusion in PIDF-LO [RFC4119].

   These examples all assume a datum of WGS84 (datum = 1) and an
   altitude type of meters (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.  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.





Thomson & Winterbottom    Expires July 22, 2009                [Page 11]


Internet-Draft                DHCP Geodetic                 January 2009


   Altitude uncertainty uses the formula from Section 2.4.4:
        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].

   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).




Thomson & Winterbottom    Expires July 22, 2009                [Page 12]


Internet-Draft                DHCP Geodetic                 January 2009


      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 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.











Thomson & Winterbottom    Expires July 22, 2009                [Page 13]


Internet-Draft                DHCP Geodetic                 January 2009


   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] 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 [RFC5139] that is presented
   alongside the geodetic object.






Thomson & Winterbottom    Expires July 22, 2009                [Page 14]


Internet-Draft                DHCP Geodetic                 January 2009


4.  Security Considerations

   Security considerations related to the privacy of location
   information as discussed in the GEOPRIV documents RFC 3693 [RFC3693]
   and RFC 3694 [RFC3694] apply.

   Where critical decisions might be based on the value of this option,
   DHCPv4 authentication in RFC 3118 [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 [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 [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.





















Thomson & Winterbottom    Expires July 22, 2009                [Page 15]


Internet-Draft                DHCP Geodetic                 January 2009


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 (Section 2.4) and the datum field (Section 2.5).
   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" [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)
















Thomson & Winterbottom    Expires July 22, 2009                [Page 16]


Internet-Draft                DHCP Geodetic                 January 2009


6.  Acknowledgements

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















































Thomson & Winterbottom    Expires July 22, 2009                [Page 17]


Internet-Draft                DHCP Geodetic                 January 2009


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

7.2.  Informative References

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [RFC3694]  Danley, M., Mulligan, D., Morris, J., and J. Peterson,
              "Threat Analysis of the Geopriv Protocol", RFC 3694,
              February 2004.

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

   [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4776, November 2006.

   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for Presence Information Data Format Location
              Object (PIDF-LO)", RFC 5139, February 2008.

   [GeoShape]
              Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
              Application Schema for use by the Internet Engineering
              Task Force (IETF)", Candidate OpenGIS Implementation



Thomson & Winterbottom    Expires July 22, 2009                [Page 18]


Internet-Draft                DHCP Geodetic                 January 2009


              Specification 06-142, Version: 0.0.9, December 2006.

   [OGP.Geodesy]
              OGP, "International Association of Oil & Gas Producers
              (OGP) Geodesy Resources",
              <http://info.ogp.org.uk/geodesy/>.

   [WGS84]    US National Imagery and Mapping Agency, "Department of
              Defense (DoD) World Geodetic System 1984 (WGS 84), Third
              Edition", NIMA TR8350.2, January 2000.

   [OGC.GML-3.1.1]
              Cox, S., Daisey, P., Lake, R., Portele, C., and A.
              Whiteside, "Geographic information - Geography Markup
              Language (GML)", OpenGIS 03-105r1, April 2004,
              <http://portal.opengeospatial.org/files/
              ?artifact_id=4700>.


































Thomson & Winterbottom    Expires July 22, 2009                [Page 19]


Internet-Draft                DHCP Geodetic                 January 2009


Authors' Addresses

   Martin Thomson
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2915
   Email: martin.thomson@andrew.com
   URI:   http://www.andrew.com/


   James Winterbottom
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2938
   Email: james.winterbottom@andrew.com
   URI:   http://www.andrew.com/





























Thomson & Winterbottom    Expires July 22, 2009                [Page 20]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/