Subject: Re: [Geopriv] [geopriv] #2: Add DHCPv6 option format

From: "geopriv issue tracker" <[email-masked]>
Date: Thu, 10 Sep 2009 06:13:28 -0000

#2: Add DHCPv6 option format
--------------------------------+-------------------------------------------
 Reporter:  [email-masked]     |        Owner:  [email-masked] 
     Type:  enhancement         |       Status:  new                       
 Priority:  major               |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis          |      Version:                            
 Severity:  Active WG Document  |   Resolution:                            
 Keywords:                      |  
--------------------------------+-------------------------------------------

Comment(by [email-masked]):

 In order to add the DHCPv6 option format and clearly describe the v0 and
 v1 DHCPv4 option formats, Section 2 needs to be re-organized.  As a
 strawman, I have adopted the outline from Section 2 of draft-thomson-
 geopriv-3825bis-03.

 Here is the current state of the -02 draft, after substitution of Section
 2 from  draft-thomson-geopriv-3825bis-03:
 http://www.drizzle.com/~aboba/GEOPRIV/draft-ietf-geopriv-rfc3825bis-02.txt

 There is still quite a bit of work to do, in order to re-integrate
 material from the original Sections 1 and 2 back into this new outline.  I
 am hoping that WG participants will assist in pointing out the required
 changes.

-- 
Ticket URL: <http://rsync.tools.ietf.org/wg/geopriv/trac/ticket/2#comment:6>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Fri, 11 Sep 2009 18:39:17 -0000

Here is the current text of Section 2.  Comments?

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

    The DHCPv6 [RFC3315] option format 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)         |   AT  |   AltUnc  |  Altitude +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Altitude (cont'd)               |     Datum     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code:  GEOCONF_GEODETIC (8 bits).

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

    LatUnc:  Latitude Uncertainty (6 bits).

    Latitude:  Latitude (34 bits).

    LongUnc:  Longitude Uncertainty (6 bits).

    Longitude:  Longitude (34 bits).

    AType:  Altitude Type (4 bits).

    AltUnc:  Altitude Uncertainty (6 bits).

    Altitude:  Altitude (30 bits).

    Datum:  Datum (8 bits).

 2.2.  DHCPv4 Option

    The DHCPv4 option format 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    |    Length     |   LatUnc  |     Latitude      +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Latitude (cont'd)              |  LongUnc  |   +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Longitude                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AType |   AltUnc  |                Altitude                   +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Alt.(cont'd)  |Ver| Res |Datum|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code:     8 bits. The code for the DHCPv4 option (123).

    Length:   8 bits. The length of the DHCPv4 option, in octets.
              For versions 0 and 1, the option length is 16.

    LatUnc:   6 bits. When the Ver field = 0, this field represents
              Latitude resolution.  When the Ver field = 1,
              this field represents Latitude uncertainty.

    Latitude:  a 34 bit fixed point value consisting of 9 bits of integer
               and 25 bits of fraction.  Latitude SHOULD be normalized to
               within +/- 90 degrees.  Positive numbers are north of the
               equator and negative numbers are south of the equator.

    LongUnc:   6 bits. When the Ver field = 0, this field represents
               Longitude resolution.  When the Ver field = 1,
               this field represents Longitude uncertainty.

    Longitude: a 34 bit fixed point value consisting of 9 bits of integer
               and 25 bits of fraction.  Longitude SHOULD be normalized
               to within +/- 180 degrees.  Positive values are East of
               the prime meridian and negative (2s complement) numbers
               are West of the prime meridian.

    AType:     Altitude Type (4 bits).

    AltUnc:    6 bits. When the Ver field = 0, this field represents
               Altitude resolution.  When the Ver field = 1,
               this field represents Altitude Uncertainty.

    Altitude:  A 30 bit value defined by the AType field.

    Ver:       The Ver field is two bits, providing for four potential
               versions.  This specification defines the behavior of
               version 0 (originally specified in [RFC3825]) as well as
               version 1.  The Ver field is always located at the same
               offset from the beginning of the option, regardless of the
               version in use.

    Res:       The Res field which is 3 bits, is reserved.  These bits
               have been used by [IEEE-802.11y], but are not defined within
 this
               specification.

    Datum:     3 bits. The Map Datum used for the coordinates given in this
 Option.

 2.2.1.  Version Support

 2.2.1.1.  Client Version Support

    Clients implementing this specification MUST support receiving
    responses of versions 0 and 1. Since this specification utilizes the
    same DHCP option code as [RFC3825], the option format does not
    provide a means for the client to indicate the highest version that
    it supports to the server.

 2.2.1.2.  Server Version Selection

    A DHCP server that provides location information cannot provide
    options with both v0 and v1 formats in the same response. This is not
    useful since receiving two copies of the same Option (either in the
    same response or a separate response) causes a DHCP client to replace
    the information in the old Option with the information in the new
    Option.

    A server uses configuration to determine which version to send in a
    response. For example, where a mixture of v0 and v1 clients are
    expected, the server could be configured to send v0 or v1 depending
    on configuration (possibly making the choice based on information
    such as the client MAC address). Where few v0 clients are expected,
    the server could be configured to send only v1 responses.

    Servers that opt to send location in v1 format are likely to cause
    clients that support only v0 to reject the Option.  This results in a
    v0-only client not obtaining location information, with no ability to
    indicate to the server that v1 was unsupported.  Therefore, in
    situations where some clients are known to support only v0, by
    default the server SHOULD send a v0 response.

 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.

    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.

 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.

       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.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/2#comment:7>
geopriv <http://tools.ietf.org/geopriv/>