[Geopriv] [geopriv] #34: Version implementation requirements

From: geopriv issue tracker ^lt;trac@tools.ietf.org>
Date: Tue Jun 22 2010 - 02:41:19 EDT

#34: Version implementation requirements
 Reporter: bernard_aboba@… | Owner:
     Type: defect | Status: new
 Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
 Severity: In WG Last Call | Keywords:
 Section 2.2.1 does not indicate what versions need to be implemented by
 DHCPv4 and DHCPv6 clients and servers.

 Proposed fix: Client Version Support

    DHCPv6 clients implementing this specification MUST support receiving
    version 1 responses. DHCPv4 clients implementing this specification
    MUST support receiving responses of versions 0 and 1. It is required
    that DHCPv4 client implementations support version 1 so the
    versioning capability added by this document does not cause errors
    interpreting the Latitude, Longitude and Altitude values. Since this
    specification utilizes the same DHCPv4 option code as [RFC3825], the
    option format does not provide a means for the DHCPv4 client to
    indicate the highest version that it supports to the DHCPv6 server.

    Moving forward, DHCPv4 and DHCPv6 clients not understanding a datum
    value MUST assume a World Geodesic System 1984 (WGS84) [WGS84] datum
    (EPSG [EPSG] 4326 or 4979, depending on whether there is an Altitude
    value present) and proceed accordingly. Assuming that a less
    accurate location value is better than none, this ensures that some
    (perhaps less accurate) location is available to the client. Server Version Selection

    DHCPv6 servers implementing this specifiction MUST support sending
    version 1 responses. A DHCPv4 server implementing this specification
    MUST support sending version 1 responses and SHOULD support sending
    version 0 responses. A DHCPv4 server that provides location
    information cannot provide options with both version 0 and version 1
    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 DHCPv4 client to replace the information in the
    old Option with the information in the new Option.

    A DHCPv4 server uses configuration to determine which version to send
    in a response. For example, where a mixture of version 0 and version
    1 clients are expected, the DHCPv4 server could be configured to send
    version 0 or version 1 depending on configuration (possibly making
    the choice based on information such as the client MAC address).
    Where few version 0 clients are expected, the DHCPv4 server could be
    configured to send only version 1 responses. Version 0 options will
    provide resolution, while version 1 options will provide an area of

    An RFC 3825 DHCPv4 client that receives a version 1 option, as
    defined in this document, will either reject the Option or will not
    understand the additions to the Datum field and will misinterpret the
    LongUnc, LatUnc, and AltUnc values.

    If the RFC 3825 DHCPv4 client does not reject the option and utilizes
    the location data it will most likely assume a datum. Assuming one
    of the RFC 3825 datums causes correct interpretation of
    Latitude/Longitude/Altitude values. The values for
    LongUnc/LatUnc/AltUnc are mistakenly interpreted as representing
    significant digits. The resultant location value will be in error up
    to a full degree of latitude and longitude, and a full increment of

    This results in a version 0-only DHCPv4 client either not obtaining
    location information (with no ability to indicate to the server that
    version 1 was unsupported), or misinterpreting the option.
    Therefore, in situations where some DHCPv4 clients are known to
    support only version 0, by default the DHCPv4 server SHOULD send a
    version 0 response.

Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/34>
geopriv <http://tools.ietf.org/geopriv/>
Geopriv mailing list
Received on Tue, 22 Jun 2010 06:41:19 -0000

This archive was generated by hypermail 2.1.8 : Tue Jun 22 2010 - 02:43:05 EDT