---------------------------------------+------------------------------------
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:
2.2.1.1. 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.
2.2.1.2. 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
uncertainty.
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
altitude.
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
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
