GEOPRIV WG M. Thomson Internet-Draft J. Winterbottom Obsoletes: 3825 (if approved) Andrew Intended status: Standards Track December 13, 2006 Expires: June 16, 2007 Dynamic Host Configuration Protocol Option for Geodetic Location Information draft-thomson-geopriv-3825bis-00.txt 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 June 16, 2007. Copyright Notice Copyright (C) The IETF Trust (2006). Thomson & Winterbottom Expires June 16, 2007 [Page 1]
Internet-Draft DHCP Geodetic December 2006 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Datum . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Encoding a Location into DHCP Geodetic Form . . . . . . . 10 3.2. Decoding a Location from DHCP Geodetic Form . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Thomson & Winterbottom Expires June 16, 2007 [Page 2]
Internet-Draft DHCP Geodetic December 2006 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 [RFC4676] 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 June 16, 2007 [Page 3]
Internet-Draft DHCP Geodetic December 2006 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 acheived 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. 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 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. 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 June 16, 2007 [Page 4]
Internet-Draft DHCP Geodetic December 2006 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: Latitude 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 June 16, 2007 [Page 5]
Internet-Draft DHCP Geodetic December 2006 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 (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. OptLen: Option Length (8 bits). This option is fixed size, the value of this octet will always be 16. 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 MAY change the way that the 34 bit values and the respective 6 bit uncertainties are interpreted. 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. Thomson & Winterbottom Expires June 16, 2007 [Page 6]
Internet-Draft DHCP Geodetic December 2006 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. The amount of uncertainty can be determined 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 value SHOULD be 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 can be normalized to this range by adding or subtracting 360 as necessary. The encoded value is determined by subtracting the next highest 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. 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 MAY change 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. Thomson & Winterbottom Expires June 16, 2007 [Page 7]
Internet-Draft DHCP Geodetic December 2006 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 SHOULD be 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. 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 [RFC4676]. 2.4.4. Altitude Uncertainty Altitude uncertainty is expressed in a similar fashion to latitude or 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. 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]: Thomson & Winterbottom Expires June 16, 2007 [Page 8]
Internet-Draft DHCP Geodetic December 2006 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. 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 June 16, 2007 [Page 9]
Internet-Draft DHCP Geodetic December 2006 3. Examples This section describes a few examples 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. The encoded values for latitude and longitude assume the middle of this range, that is (-33.8570095, 151.2152005). These are encoded as (1110111100010010010011011000001110, 0100101110011011100010111011000011) in binary, or (3BC49360E, 12E6E2EC3) in hexadecimal notation (with an extra 2 bits of 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 June 16, 2007 [Page 10]
Internet-Draft DHCP Geodetic December 2006 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 1 0|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 49360E49 2E6E2EC3 13C00021 B301. The DHCPv6 form only differs in the code. 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 [I-D.thomson-geopriv-geo-shape]. A latitude value of 1110111100010010010011011000001110 decodes to a value of -33.8570094705 (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 June 16, 2007 [Page 11]
Internet-Draft DHCP Geodetic December 2006 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.8570094705 +/- 0.0009765625 (or the range from -33.857986033 to -33.856032908) 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 xmlns:gml="http://www.opengis.net/gml" srsName="urn:ogc:def:crs:EPSG::4979"> <gml:pos>-33.8570094705 151.2152005136 33.69921875</gml:pos> </gml:Point> If all fields are included along with uncertainty, the shape described is a rectangular prism. Thomson & Winterbottom Expires June 16, 2007 [Page 12]
Internet-Draft DHCP Geodetic December 2006 The following example uses all of the decoded information from the previous example: <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979" xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" xmlns:gml="http://www.opengis.net/gml"> <gs:base> <gml:Polygon> <gml:exterior> <gml:LinearRing> <gml:posList> -33.857986033 151.2142239511 -30.30078125 -33.857986033 151.2161770761 -30.30078125 -33.856032908 151.2161770761 -30.30078125 -33.856032908 151.2142239511 -30.30078125 -33.857986033 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. [I-D.thomson-geopriv-geo-shape] 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). 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 [I-D.ietf-geopriv-revised-civic-lo] that is linked to the geodetic object. Thomson & Winterbottom Expires June 16, 2007 [Page 13]
Internet-Draft DHCP Geodetic December 2006 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 June 16, 2007 [Page 14]
Internet-Draft DHCP Geodetic December 2006 5. IANA Considerations The IANA has registered DHCPv4 and DHCPv6 option codes for the Geodetic Location option (GEOCONF_GEODETIC and OPTION_GEOCONF_GEODETIC, respectively). The IANA has established two registries for GeoConf items: the altitude type field (Section 2.4) and the datum field (Section 2.5). 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 Values registered in the Datum registry are: Datum = 1 denotes the WGS 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 June 16, 2007 [Page 15]
Internet-Draft DHCP Geodetic December 2006 6. References 6.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. 6.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. [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4676, October 2006. [I-D.thomson-geopriv-geo-shape] Thomson, M., "Geodetic Shapes for the Representation of Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-02 (work in progress), May 2006. [I-D.ietf-geopriv-revised-civic-lo] Thomson, M. and J. Winterbottom, "Revised Civic Location Thomson & Winterbottom Expires June 16, 2007 [Page 16]
Internet-Draft DHCP Geodetic December 2006 Format for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in progress), September 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 June 16, 2007 [Page 17]
Internet-Draft DHCP Geodetic December 2006 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 June 16, 2007 [Page 18]
Internet-Draft DHCP Geodetic December 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Thomson & Winterbottom Expires June 16, 2007 [Page 19]