RFC 6225
Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information
RFC 6225: Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information 🦋
Okay bestie, this is Part 1 of 7, so grab a snack 🍓 and let's get into it.
RFC 6225 is an IETF Standards Track document (ISSN 2070-1721), published in July 2011. Four people wrote it: J. Polk, M. Linsner (both from Cisco Systems), M. Thomson (from Andrew Corporation), and B. Aboba, Ed. (from Microsoft Corporation). It is also the one that obsoletes RFC 3825 💅 so if you're still reading 3825, it's time to upgrade.
Abstract
This document specifies Dynamic Host Configuration Protocol options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6225.
Copyright Notice
Copyright (c) 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
1.2. Resolution and Uncertainty .................................4
2. DHCP Option Formats .............................................6
2.1. DHCPv6 GeoLoc Option .......................................6
2.2. DHCPv4 Options .............................................8
2.3. Latitude and Longitude Fields .............................11
2.4. Altitude ..................................................14
2.5. Datum .....................................................16
3. Security Considerations ........................................17
4. IANA Considerations ............................................17
4.1. DHCP Options ..............................................17
4.2. Altitude Type Registry ....................................18
4.3. Datum Registry ............................................18
4.4. GeoLoc Option Version Registry ............................19
5. Acknowledgments ................................................20
6. References .....................................................20
6.1. Normative References ......................................20
6.2. Informative References ....................................21
Appendix A. GML Mapping ...........................................23
A.1. GML Templates ............................................23
Appendix B. Calculations of Resolution ............................27
B.1. Location Configuration Information of "White House"
(Example 1) ..............................................27
B.2. Location Configuration Information of "Sears Tower"
(Example 2) ..............................................29
Appendix C. Calculations of Uncertainty ...........................30
C.1. Location Configuration Information of "Sydney Opera
House" (Example 3) .......................................30
Appendix D. Changes from RFC 3825 .................................341. Introduction ✨
Okay so, knowing where a device is physically located is a big deal 🌸 There are tons of applications that need it, and emergency telephony is the big one. Emergency calls rely on knowing where the caller is so they can get routed to the correct emergency center. Iconic, but also high stakes.
A device's location can be written in two flavours: geospatial (or geodetic) coordinates, or a civic address. Different apps like different flavours, so both the geodetic and civic forms may be used at the same time. Main character energy for flexibility 🦋
This document is where the DHCP options for the coordinate-based location live. It covers both Dynamic Host Configuration Protocol v4 (DHCPv4) [RFC2131] and DHCPv6 [RFC3315], and the server is the one who provides them to the client. Meanwhile, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information" [RFC4776] handles the options for civic addresses 💜
The geodetic coordinate options in this document and the civic address options in RFC 4776 [RFC4776] together let a DHCP client figure out its location. For example, a wired Ethernet host might use these options for location determination. In that case, the location info could be 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 could match the Circuit ID with the geographic spot where that circuit ends, like the location of the wall jack 🧚
The mechanism here can also give location to wireless hosts. DHCP relay agent sub-options (RAIO) [RFC3046] are one method a DHCP server might use for host location determination. Right now, though, the relay agent sub-options don't include the data sets needed for device-level location determination of wireless hosts 🙈 When the DHCP server uses RAIO for location determination, a wireless host can use this mechanism to find out where the radio access point is, or the area of coverage for that access point.
One big feature here: after the relevant DHCP exchanges happen, the location info is stored on the end device itself, instead of somewhere else where getting it back might be a pain in practice. Literally so smart 👑
1.1. Conventions Used in This Document
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]. (Translation: these capital words are the official rule words, and they mean exactly what [RFC2119] says 🫶)
1.2. Resolution and Uncertainty
The DHCP options defined in this document include fields that quantify the resolution or uncertainty associated with a target location. No inferences relating to privacy policies can be drawn from either uncertainty or resolution values. Don't go reading privacy stuff into these numbers, bestie 🔥
Here, resolution means the accuracy of a reported location, expressed by the number of valid bits in each of the Latitude, Longitude, and Altitude fields.
The Latitude (LaRes), Longitude (LoRes), and Altitude (AltRes) Resolution fields are encoded as 6-bit, unsigned integer values. In the DHCPv4 GeoConf Option 123, the LaRes, LoRes, and AltRes fields are used to encode the number of bits of resolution. The resolution sub-fields make it easy to adjust how precise a reported location is. Contents beyond the claimed resolution MAY be randomized to obscure greater precision that might be available. (Yes, that MAY is capitalised on purpose: it's a real permission, and it's giving privacy-minded 🌈)
In the context of location technology, uncertainty is a quantification of errors. Any method for determining location is subject to some sources of error, and uncertainty describes how much error 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 where the target is located. In this document, each of the three axes can be assigned an uncertainty value. Put together, that describes a rectangular prism, which may be used as a coarse representation of a more complex shape that fits inside it. See Section 2.3.2 for more detail on the correspondence between shapes and uncertainty 🦋
When representing locations from sources that can quantify uncertainty, the goal is to find the smallest possible rectangular prism that this format can describe. You do that by taking the minimum and maximum values on each axis and making sure the final encoding covers those points. This makes the region of uncertainty bigger, but it guarantees that the described region encompasses the target location. Bigger box, but it definitely contains the thing 💖
The DHCPv4 option formats in this document support resolution and uncertainty parameters. The DHCPv4 GeoConf Option 123 includes a resolution parameter for each dimension of location. Since that resolution parameter doesn't need to apply to all dimensions equally, a resolution value is included for each of the three location elements. The DHCPv4 GeoLoc Option 144 and the DHCPv6 GeoLoc Option 63 formats use an uncertainty parameter instead 🎀
Appendix A describes how DHCP option values map to the Geography Markup Language (GML). Appendix B of this document has examples showing how resolution values are calculated. Appendix C has an example that walks through calculating uncertainty values ⭐
Since the Presence Information Data Format Location Object (PIDF-LO) [RFC4119] [RFC5491] is used to convey location and its associated uncertainty within an emergency call [Convey], there needs to be a mechanism that converts the info in the DHCPv4 and DHCPv6 options to PIDF-LO. This document describes the following conversions:
- DHCPv4 GeoConf Option 123 to PIDF-LO
- DHCPv4 GeoLoc Option 144 and DHCPv6 GeoLoc Option 63 to PIDF-LO
- PIDF-LO to DHCP GeoLoc Option 144 and DHCPv6 GeoLoc Option 63
Converting to PIDF-LO does not increase uncertainty. Converting from PIDF-LO to the DHCPv4 GeoLoc Option 144 and the DHCPv6 GeoLoc Option 63 increases uncertainty by less than a factor of 2 in each dimension. Since it isn't possible to translate an arbitrary PIDF-LO to the DHCP GeoConf Option 123 with a bounded increase in uncertainty, that conversion is not specified. Not every road leads there, and this doc is honest about it 🌸
Next up: Section 2, where the actual option formats live. It's giving packet bytes, so stay hydrated 💜
2. DHCP Option Formats ✨
okay bestie, this part is where we get into the actual bits and bytes 🤓💖 this section defines the format for the DHCPv4 and DHCPv6 options, and they're basically cousins. they look super similar and mostly only differ in their option code 🧚
2.1. DHCPv6 GeoLoc Option
the DHCPv6 [RFC3315] GeoLoc Option looks like this, and yes the diagram is giving main character energy 🎀
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 (63) | OptLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LatUnc | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lat (cont'd) | LongUnc | Longitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude (cont'd) | AType | AltUnc | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude (cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's what each piece does 💅
Code: 16 bits. the code for the DHCP Option Code (63) 🔢OptLen: Option Length. for version 1, the option length is 16 ✨LatUnc: 6 bits. when theVerfield = 1, this field represents latitude uncertainty. the contents of this field are undefined for other values of theVerfield 🙈Latitude: a 34-bit fixed-point value made of 9 bits of integer and 25 bits of fraction, interpreted as described in Section 2.3 📍LongUnc: 6 bits. when theVerfield = 1, this field represents longitude uncertainty. the contents of this field are undefined for other values of theVerfield 🧭Longitude: a 34-bit fixed-point value made of 9 bits of integer and 25 bits of fraction, interpreted as described in Section 2.3 🌍AType: 4 bits. Altitude Type, defined in Section 2.4 ⛰️AltUnc: 6 bits. when theVerfield = 1, this field represents altitude uncertainty. the contents of this field are undefined for other values of theVerfield 🦋Altitude: a 30-bit value defined by theATypefield, described in Section 2.4 🎈Ver: theVerfield is 2 bits, which gives four potential versions. this spec defines the behaviour of version 1. theVerfield is always at the same offset from the beginning of the option, no matter which version is in use 🔐
okay the Ver part is where it gets serious, so pay attention 👑 DHCPv6 clients implementing this specification MUST support receiving version 1 responses. DHCPv6 servers implementing this specification MUST send version 1 responses. no vibes-based interpretation here, it's a hard rule 💀
Res: 3 bits. theResfield is reserved. these bits have been used by [IEEE-802.11y], but they're not defined within this specification 🌸Datum: 3 bits. the Map Datum used for the coordinates given in this option 🗺️
2.2. DHCPv4 Options
2.2.1. DHCPv4 GeoConf Option
the DHCPv4 GeoConf Option is laid out like this 🎀
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 | LaRes | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LoRes | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltRes | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt.(cont'd) | Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the breakdown 🧁
Code: 8 bits. the code for the DHCPv4 GeoConf Option (123) 🔢Length: 8 bits. the length of the option, in octets. the option length is 16 ✨LaRes: 6 bits. this field represents latitude resolution 📏Latitude: a 34-bit fixed-point value made of 9 bits of signed integer and 25 bits of fraction, interpreted as described in Section 2.3 📍LoRes: 6 bits. this field represents longitude resolution 📐Longitude: a 34-bit fixed-point value made of 9 bits of signed integer and 25 bits of fraction, interpreted as described in Section 2.3 🌍AType: 4 bits. Altitude Type, defined in Section 2.4 ⛰️AltRes: 6 bits. this field represents altitude resolution 🦋Altitude: a 30-bit value defined by theATypefield, described in Section 2.4 🎈Res: 5 bits. theResfield is reserved. these bits have been used by IEEE 802.11y [IEEE-802.11y], but they're not defined within this specification 🌸Datum: 3 bits. the Map Datum used for the coordinates given in this option 🗺️
2.2.2. DHCPv4 GeoLoc Option
and here's the DHCPv4 GeoLoc Option, which is basically its sibling with a different code 💜
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 144 | Length | LatUnc | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LongUnc | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltUnc | Altitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt.(cont'd) |Ver| Res |Datum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the breakdown 🫶
Code: 8 bits. the code for the DHCPv4 GeoLoc Option (144) 🔢Length: 8 bits. the length of the option, in octets. for version 1, the option length is 16 ✨LatUnc: 6 bits. when theVerfield = 1, this field represents latitude uncertainty. the contents of this field are undefined for other values of theVerfield 🙈Latitude: a 34-bit fixed-point value made of 9 bits of integer and 25 bits of fraction, interpreted as described in Section 2.3 📍LongUnc: 6 bits. when theVerfield = 1, this field represents longitude uncertainty. the contents of this field are undefined for other values of theVerfield 🧭Longitude: a 34-bit fixed-point value made of 9 bits of integer and 25 bits of fraction, interpreted as described in Section 2.3 🌍AType: 4 bits. Altitude Type, defined in Section 2.4 ⛰️AltUnc: 6 bits. when theVerfield = 1, this field represents altitude uncertainty. the contents of this field are undefined for other values of theVerfield 🦋Altitude: a 30-bit value defined by theATypefield, described in Section 2.4 🎈Ver: theVerfield is 2 bits, which gives four potential versions. this spec defines the behaviour of version 1. theVerfield is always at the same offset from the beginning of the option, no matter which version is in use 🔐Res: 3 bits. theResfield is reserved. these bits have been used by [IEEE-802.11y], but they're not defined within this specification 🌸Datum: 3 bits. the Map Datum used for the coordinates given in this option 🗺️
2.2.3. Option Support
2.2.3.1. Client Support
DHCPv4 clients implementing this specification MUST support receiving the DHCPv4 GeoLoc Option 144 (version 1), and MAY support receiving the DHCPv4 GeoConf Option 123 (originally defined in RFC 3825 [RFC3825]). so the GeoLoc one is the must-have, and GeoConf is a bonus if you want it 🎀
DHCPv4 clients request GeoConf Option 123, GeoLoc Option 144, or both from the DHCPv4 server by including the Parameter Request List option. as noted in Section 9.8 of RFC 2132 [RFC2132]:
This option is used by a DHCP client to request values for specified configuration parameters. The list of requested parameters is specified as n octets, where each octet is a valid DHCP option code as defined in this document. The client MAY list the options in order of preference. The DHCP server is not required to return the options in the requested order, but MUST try to insert the requested options in the order requested by the client.
when DHCPv4 and DHCPv6 clients implementing this specification don't understand a datum value, they MUST assume a World Geodetic System 1984 (WGS84) [WGS84] datum (European Petroleum Survey Group (EPSG) [EPSG] 4326 or 4979, depending on whether there is an altitude value present) and carry on from there. assuming a less accurate location is better than none, so this makes sure the client still gets some location, even if it's a little fuzzy 🥹🌈
2.2.3.2. Server Option Selection
a DHCPv4 server implementing this specification MUST support sending GeoLoc Option 144 version 1 and SHOULD support sending GeoConf Option 123 in responses. ✨
a DHCPv4 server that provides location information SHOULD honor the Parameter Request List included by the DHCPv4 client, so it can decide whether to send GeoConf Option 123, GeoLoc Option 144, or both in the Response. listening to what the client asked for is very much the vibe 💅
2.3. Latitude and Longitude Fields
okay, the coordinates. latitude and longitude in this spec are encoded as 34-bit, two's complement, fixed-point values with 9 integer bits and 25 fractional bits 🔢 the exact meaning is decided by the datum, and the description in this section applies to the datums defined in this document. this document uses the same definition for all datums it specifies 🗺️
when encoding, latitude and longitude values are rounded to the nearest 34-bit binary representation. this imprecision is considered acceptable for what this form is meant for, and it's ignored when decoding 🤷♀️✨
positive latitudes are north of the equator, and negative latitudes are south of the equator 🌏 positive longitudes are east of the Prime Meridian, and negative (two's complement) longitudes are west of the Prime Meridian 🧭
within the coordinate reference systems defined in this document (Datum values 1-3), longitude values outside the range of -180 to 180 decimal degrees, or latitude values outside the range of -90 to 90 degrees, MUST be considered invalid. server implementations SHOULD prevent invalid values from being entered within the selected coordinate reference system. location consumers MUST ignore invalid location coordinates and SHOULD log errors related to invalid location. 🚫 no bad coords allowed, bestie 😭🫶
2.3.1. Latitude and Longitude Resolution ✨
okay so in the DHCPv4 GeoConf Option 123, the LaRes value tells you how many high-order latitude bits MUST be considered valid 💅 Any bits to the right of that limit MUST NOT be considered valid, and they might be purposely false or zeroed by the sender 🙈 The examples in Appendix B show that a smaller number in the resolution field makes the area the device could be in bigger 🗺️ A LaRes value of 2 means a precision of no greater than 1/6th of the globe (see the first example of Appendix B) 🌍 A LaRes value of 34 means a precision of about 3.11 mm in latitude at the equator 🤯
The LoRes value in the DHCPv4 GeoConf Option 123 is the same vibe but for longitude 🌸 It tells you how many high-order longitude bits MUST be considered valid, and any bits to the right of that limit MUST NOT be considered valid, and might be purposely false or zeroed by the sender 🫶 A LoRes value of 2 is also a precision of no greater than 1/6th of the globe (see the first example of Appendix B) 🌐 A LoRes value of 34 gets you a precision of about 2.42 mm in longitude (at the equator) 🔥 Lines of longitude meet at the poles, so the distance is smaller (aka better precision) for places away from the equator 🧭
2.3.2. Latitude and Longitude Uncertainty
so the LatUnc and LongUnc fields in the DHCPv6 GeoLoc Option 63 and the DHCPv4 GeoLoc Option 144 are the uncertainty for latitude and longitude, respectively 🎀 A value of 0 is reserved to mean the uncertainty is unknown, and values greater than 34 are reserved too 🙅♀️
Next, you pick a point somewhere inside the region of uncertainty to be the encoded point, and the centroid is often a good pick 🦋 The uncertainty value is the distance from that selected point to the furthest edge of the region on that axis ✨ Check out this figure, which shows a two-dimensional polygon projected onto each axis. The "X" is the point that's selected, and the ranges marked with "U" are the uncertainty 💜
___ ___________
^ | / |
| | / |
| | / |
U | / |
| | ( |
V | | |
--X | X |
| | `---------.
| | |
| | |
| | |
- `-------------------------'
|---------X---------------|
|<------U------>| Key
---
V, ^ = vertical arrows, delimiting the vertical uncertainty range.
<> = horizontal arrows, delimiting the horizontal uncertainty
range.Uncertainty applies to each axis independently 🌈
You can work out the amount of uncertainty from the encoding by doing 2 to the power of 8, minus the encoded value, like this formula (where "x" is the encoded integer value) 🧮
uncertainty = 2 ^ ( 8 - x )The result is in degrees of latitude or longitude 📐 Add the uncertainty to the base latitude or longitude to get the maximum value of the uncertainty range, and subtract it from the base value to get the minimum 💖 Lines of longitude converge at the poles, so the actual distance this uncertainty covers changes depending on how far you are from the equator 🌏
If the maximum or minimum latitude values after applying uncertainty go outside the range of -90 to +90, they get trimmed to fit in that range ✂️ If the maximum or minimum longitude values go outside the range of -180 to +180, they get normalized into that range by adding or subtracting 360 as needed 🔄
The encoded value is found by taking 8 minus the next highest whole integer value of the base 2 logarithm of the uncertainty, following this formula. The uncertainty here is the midpoint of the known range minus the lower bound of that range 🧠
x = 8 - ceil( log2( uncertainty ) )Here's the tea: encoding this value bumps the range of uncertainty up to the next available power of two, and repeated encodings and decodings don't change the value after that 🍓 Only increasing the uncertainty means the associated confidence doesn't have to go down 💅
2.4. Altitude
okay so how the altitude value gets interpreted depends on the Altitude Type (AType) value and the datum you pick 🏔️ There are three Altitude Type values defined in this document: unknown (0), meters (1), and floors (2) ⭐
2.4.1. No Known Altitude (AType = 0)
sometimes the altitude of the location just isn't provided 🤷♀️ An Altitude Type value of zero means the altitude isn't given to the client 💀 In this case the Altitude and Altitude Uncertainty fields can hold any value, and they MUST be ignored 🚫
2.4.2. Altitude in Meters (AType = 1)
if the Altitude Type is one, the altitude is measured in meters, relative to the zero set by the vertical datum 📏 For AType = 1, the altitude value is a 30-bit, fixed-point, two's complement integer with 22 integer bits and 8 fractional bits 🔢
2.4.3. Altitude in Floors (AType = 2)
a value of two for Altitude Type means the altitude is measured in floors 🏢 Since altitude in meters might not be known inside a building, a floor indication can be way more useful 🙌 For AType = 2, the altitude value is also a 30-bit, fixed-point, two's complement integer with 22 integer bits and 8 fractional bits 🤓
This value only means something in relation to a building, and it's relative to the ground level of that building 🏗️ Floors below ground level are negative values 🕳️ In some buildings it might not be clear which floor is at ground level, or an intermediate floor might be hard to spot as one, and figuring out what counts as ground level and what counts as a sub-floor versus a naturally numbered floor is left up to local interpretation 🤷♀️
Larger values mean floors that are farther away from floor 0, like this:
- if positive, the floor value is farther above the ground floor.
- if negative, the floor value is farther below the ground floor.
Non-integer values can represent intermediate or sub-floors, like mezzanine levels 🪜 Example: a mezzanine between floor 1 and floor 2 could be represented as a value of 1.25 💜 Example: mezzanines between floor 4 and floor 5 could be represented as values of 4.5 and 4.75 🦋
2.4.4. Altitude Resolution
in the DHCPv4 GeoConf Option 123, the altitude resolution (AltRes) value encodes the number of high-order altitude bits that should be considered valid 📊 Values above 30 (decimal) are undefined and reserved 🚧
If the Altitude Type value is one (AType = 1), an AltRes value of 0.0 would mean an unknown altitude 🌫️ The most precise altitude would have an AltRes value of 30 🎯 Lots of AltRes values would hide any variation caused by vertical datum differences 🙈
The AltRes field SHOULD be set to maximum precision when AType = 2 (floors) and a floor value is included in the DHCP Reply, or when AType = 0, to show that the floor isn't known 🏢 An altitude coded as AType = 2, AltRes = 30, and Altitude = 0.0 is still meaningful even outside a building 🌿 It represents ground level at the given latitude and longitude 🧚
2.4.5. Altitude Uncertainty
in the DHCPv6 GeoLoc Option 63 or the DHCPv4 GeoLoc Option 144, the AltUnc value quantifies how uncertain the altitude value is 📈 Same as with LatUnc and LongUnc, a value of 0 for AltUnc is reserved to mean altitude uncertainty isn't known, and values above 30 are reserved too 🙅♀️ Altitude uncertainty only applies to Altitude Type 1 📏
You can figure out the amount of altitude uncertainty with this formula, where x is the encoded integer value 🧮
Uncertainty = 2 ^ ( 21 - x )This value uses the same units as the associated altitude ✨
And you can go the other way too, deriving the encoded integer value with this formula 🔁
x = 21 - ceil( log2( uncertainty ) )2.5. Datum
the Datum field decides how coordinates are organized and how they relate 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 Geodetic 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) 👑
3. Security Considerations 🔒
okay bestie, this part is serious, so listen up 🚨 Geopriv requirements (including security requirements) are discussed in "Geopriv Requirements" [RFC3693] 📜 A threat analysis is provided in "Threat Analysis of the Geopriv Protocol" [RFC3694] 🕵️♀️
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 LCI 😱 This one is a big deal!
To minimize the unintended exposure of location information, the LCI option SHOULD be returned by DHCP servers only when the DHCP client has included this option in its 'parameter request list' (Section 3.5 of [RFC2131], Section 9.8 of [RFC2132]) 🛡️
Where critical decisions might be based on the value of this option, DHCP authentication as defined in "Authentication for DHCP Messages" [RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3315] SHOULD be used to protect the integrity of the DHCP options 🔐
Link-layer confidentiality and integrity protection may also be employed to reduce the risk of location disclosure and tampering 🫶
4. IANA Considerations ✨
4.1. DHCP Options ✨
Okay so this document defines the DHCPv6 GeoLoc Option (see Section 2.1), which got DHCPv6 option code 63 per [RFC3315] 💖:
Value Description Reference
---- ------------------ ----------
63 OPTION_GEOLOCATION RFC 6225It also defines the DHCPv4 GeoConf Option (see Section 2.2.1), which got DHCPv4 option code 123 from the DHCP Option space 🎀.
And then there's the DHCPv4 GeoLoc Option (see Section 2.2.2), which got DHCPv4 option code 144 per [RFC2132] [RFC2939] 🦋:
Data
Tag Name Length Meaning Reference
---- ---- ------ ------- ---------
144 GeoLoc 16 Geospatial Location RFC 6225
with Uncertainty4.2. Altitude Type Registry 🌸
IANA has created and now maintains the Altitude Type registry, following the guidelines below. It's giving organised 💅.
The registry has three values: Altitude Type, Description, and Reference. Here's the tea on each one.
Altitude Type is an integer that refers to the value used in the DHCPv4 GeoConf and the DHCPv4 and DHCPv6 GeoLoc options described in this document. Values 0 - 2 are assigned, and values 3 - 15 are Unassigned [RFC5226].
Description is the description of the altitude that this code describes.
Reference is the reference to the document that describes the altitude code. This reference MUST define the way that the 30-bit altitude values and the associated 6-bit uncertainty are interpreted. Non-negotiable, bestie 👑.
The initial values are below. New assignments are made following the "Standards Action" policies [RFC5226] 🧚.
+------+---------------------+--------------+
| # | Description | Reference |
+------+---------------------+--------------+
| 0 | No known altitude | RFC 6225 |
| 1 | Altitude in meters | RFC 6225 |
| 2 | Altitude in floors | RFC 6225 |
| 3-15 | Unassigned | |
+------+---------------------+--------------+4.3. Datum Registry 🍓
IANA has created and now maintains the Datum registry, following the guidelines below. Same energy as the last one, just with more numbers 🤓.
The registry has three values: Datum, Description, and Reference.
Datum is an integer that refers to the value used in the DHCPv4 GeoConf and the DHCPv4 and DHCPv6 GeoLoc options described in this document. Value 0 is Reserved. Values 1 - 3 are assigned, and values 4 - 7 are Unassigned [RFC5226].
Description is the description of the altitude that this code describes. (Yes, it says altitude even though this is the datum registry, and yes, that's what the text says 🙈.)
Reference is the reference to the document that describes the Datum code. This reference MUST include specification of both the horizontal and vertical datum, and MUST define the way that the 34-bit values and the respective 6-bit uncertainties are interpreted. Both of those MUSTs are doing a lot of work 💀.
The initial values are below. New assignments are made following the "Standards Action" policies [RFC5226] ✨.
+------+----------------------------------------+--------------+
| # | Description | Reference |
+------+----------------------------------------+--------------+
| 0 | Reserved | RFC 6225 |
+------+----------------------------------------+--------------+
| 1 | Vertical datum WGS 84 defined by EPSG | RFC 6225 |
| | CRS Code 4327 | |
+------+----------------------------------------+--------------+
| 2 | Vertical datum NAD83 defined by EPSG | RFC 6225 |
| | CRS Code 4269 with North American | |
| | Vertical Datum of 1988 (NAVD88) | |
+------+----------------------------------------+--------------+
| 3 | Vertical datum NAD83 defined by EPSG | RFC 6225 |
| | CRS Code 4269 with Mean Lower Low Water| |
| | (MLLW) as associated vertical datum | |
+------+----------------------------------------+--------------+
| 4-7 | Unassigned | |
+------+----------------------------------------+--------------+4.4. GeoLoc Option Version Registry 🌈
IANA has created and now maintains the GeoLoc Option Version registry, following the guidelines below. Okay, we're in the home stretch 🏃♀️.
The registry has three values: GeoLoc Option Version, Description, and Reference.
GeoLoc Option Version is an integer that refers to the version used in the DHCPv4 and DHCPv6 GeoLoc options described in this document. Value 0 is Reserved. Value 1 has been assigned, and values 2 - 3 are Unassigned [RFC5226].
Description is the description of the version that this code describes.
Reference is the reference to the document that describes the Version code.
The initial values are below. New assignments are made following the "Standards Action" policies [RFC5226] 💜.
+------+---------------------------------------+--------------+
| # | Description | Reference |
+------+---------------------------------------+--------------+
| 0 | Reserved | RFC 6225 |
+------+---------------------------------------+--------------+
| 1 | Implementations utilizing uncertainty | RFC 6225 |
| | parameters for both DHCPv4 and DHCPv6 | |
| | GeoLoc options | |
+------+---------------------------------------+--------------+
| 2-3 | Unassigned | |
+------+---------------------------------------+--------------+5. Acknowledgments 🫶
The authors would like to thank Randall Gellens, Patrik Falstrom, Ralph Droms, Ted Hardie, Jon Peterson, Robert Sparks, Nadine Abbott, and Mykyta Yevstifeyev for their inputs and constructive comments regarding this document. The whole squad 💖.
They also thank Greg Troxel for the education on vertical datums, as well as Carl Reed. Thanks to Richard Barnes for his contribution on GML mapping for resolution ⭐.
6. References 📚
6.1. Normative References
[EPSG]European Petroleum Survey Group,<http://www.epsg.org/>and<http://www.epsg-registry.org/>.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2131]Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.[RFC2132]Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.[RFC2939]Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.[RFC3118]Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.[RFC3315]Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.[WGS84]US National Imagery and Mapping Agency, "Department of Defense (DoD) World Geodetic System 1984 (WGS 84), Third Edition", NIMA TR8350.2, January 2000,<https://www1.nga.mil/PRODUCTSSERVICES/GEODESYGEOPHYSICS/WORLDGEODETICSYSTEM/Pages/default.aspx>and<http://www.ngs.noaa.gov/faq.shtml#WGS84>.
6.2. Informative References
[Convey]Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", Work in Progress, May 2011.[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 Specification 06-142, Version: 0.0.9, December 2006.[IEEE-802.11y]IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 3: 3650-3700 MHz Operation in USA, November 2008.[NENA]National Emergency Number Association (NENA), NENA Technical Information Document on Model Legislation Enhanced 911 for Multi-Line Telephone Systems,<www.nena.org>.[OGC-GML3.1.1]Portele, C., Cox, S., Daisy, P., Lake, R., and A. Whiteside, "Geography Markup Language (GML) 3.1.1", OGC 03-105r1, July 2003.[OGP.Geodesy]International Association of Oil & Gas Producers (OGP) Geodesy Resources, Geomatics Committee,<http://info.ogp.org.uk/geodesy/>.[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.[RFC3825]Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 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.[RFC5491]Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
Appendix A. GML Mapping ✨
okay so this appendix is all about how a decoded DHCP option gets turned into GML 🗺️ The DHCP location format basically describes a geodetic prism, a rectangle, or a point, and which one you get depends on whether altitude and uncertainty values are given 💅 With no uncertainty info, the decoded value can be a single point, and that's true whether you're reading the version 0 or version 1 uncertainty fields. If the point has altitude, it uses a three-dimensional CRS. Otherwise it's two-dimensional. If every field is included along with uncertainty, the shape is a rectangular prism, and that makes sense because uncertainty comes in separately for each axis 🧚
If altitude or altitude uncertainty (AltUnc) isn't specified, the shape is a rectangle drawn with the "gml:Polygon" shape. If altitude is available, you get a 3D CRS, and if not, a 2D one 🌸
Heads up for the NAD83 datums (values 2 or 3)! There's no CRS URN that covers 3D coordinates, so locations in those datums can only be 2D: either a 2D point or a polygon 🙈
If the Altitude Type is 2 (floors), that value can be represented with a civic address object [RFC5139] shown right alongside the geodetic object 🏠
This appendix explains how a geodetic location encoded in DHCP format can be expressed in GML. The mapping works for the DHCPv6 GeoLoc Option, for both the DHCPv4 GeoConf and GeoLoc options, and for the datum values defined right now (1, 2, and 3). Future version or datum definitions should come with similar mappings ✨
To get the GML, you first compute the bounds described by the coordinate and uncertainty fields, then encode the result as a GML Polygon or Prism shape 💖
A.1. GML Templates
If altitude is given in meters (AType 1) and the datum is WGS84 (value 1), the right GML shape is a Prism, shaped like this (where $value$ means a value computed from the DHCP option, as explained below):
<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>
$lowLatitude$ $lowLongitude$ $lowAltitude$
$lowLatitude$ $highLongitude$ $lowAltitude$
$highLatitude$ $highLongitude$ $lowAltitude$
$highLatitude$ $lowLongitude$ $lowAltitude$
$lowLatitude$ $lowLongitude$ $lowAltitude$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
$highAltitude - lowAltitude$
</gs:height>
</gs:Prism>The Polygon shape gets used if altitude is left out or given in floors, or if either NAD83 datum is used (value 2 or 3). The matching GML Polygon looks like this:
<gml:Polygon srsName="$2D-CRS-URN$"
xmlns:gml="http://www.opengis.net/gml">>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$lowLatitude$ $lowLongitude$
$lowLatitude$ $highLongitude$
$highLatitude$ $highLongitude$
$highLatitude$ $lowLongitude$
$lowLatitude$ $lowLongitude$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>The "2D-CRS-URN" value depends on the datum. For WGS84 (value 1), the 2D-CRS-URN is "urn:ogc:def:crs:EPSG::4326". For NAD83 (value 2 or 3), it's "urn:ogc:def:crs:EPSG::4269" 🔥
A Polygon with the WGS84 three-dimensional CRS shows up when the datum is WGS84 (value 1) and the altitude is in meters (Altitude Type 1), but there's no altitude uncertainty (so AltUnc is 0). In that case, the Altitude value gets added after each of the points above, and the srsName attribute is set to the 3D WGS84 CRS, "urn:ogc:def:crs:EPSG::4979" 🦋
A simple point shape is used if either latitude uncertainty (LatUnc) or longitude uncertainty (LongUnc) isn't specified. With altitude it uses a 3D CRS, and otherwise a 2D one:
<gml:Point srsName="$CRS-URN$"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>$Latitude$ $Longitude$ $[Altitude]$</gml:pos>
</gml:Point>A.1.1. Finding Low and High Values Using Uncertainty Fields
For the DHCPv4 GeoConf Option 123, the resolution fields are used (LaRes, LoRes, AltRes). They tell you how many bits of a value actually hold information, and any bits past that can be either zero or one 🧩
For the DHCPv6 GeoLoc Option 63 and the DHCPv4 GeoLoc Option 144, the LatUnc, LongUnc, and AltUnc fields give uncertainty distances, which mark the bounds of the location region described by the DHCP location object 🎯
The next two sections explain how to compute the latitude, longitude, and altitude bounds (like $lowLatitude$ and $highAltitude$) in the templates above. The first one covers the "resolution encoding" (DHCPv4 GeoConf Option 123), and the second covers the "uncertainty encoding" (DHCPv6 GeoLoc Option 63 and DHCPv4 GeoLoc Option 144) 💜
A.1.1.1. Resolution Encoding
Given a number of resolution bits (that's the value of a resolution field), if every bit past those is set to zero, you get the lowest possible value. Set all of them to one and you get the highest possible value ✨
If the encoded latitude/longitude value and its resolution (LaRes, LoRes) are treated as 34-bit unsigned integers, you can use the following. Here ">>" is a bitwise right shift, "&" is a bitwise AND, "~" is a bitwise negation, and "|" is a bitwise OR:
mask = 0x3ffffffff >> resolution
lowvalue = value & ~mask
highvalue = value | mask + 1Once you have those values, you can turn them into floating-point numbers by dividing by 2^25 (since there are 25 bits of fraction in the fixed-point representation) 🧮
Or, if you want, you can find the lowest possible value by using the resolution to work out the size of the range. This method's advantage is that it works on the already-decoded floating-point values. It's equivalent to the first mechanism, with a possible error of 2^-25 (2^-8 for altitude) 🫶
scale = 2 ^ ( 9 - resolution )
lowvalue = floor( value / scale ) * scale
highvalue = lowvalue + scaleAltitude resolution (AltRes) works the same way, just with different constants. There are 22 whole bits in the altitude encoding (instead of 9) and 30 bits in total (instead of 34) 📐
A.1.1.2. Uncertainty Encoding
In the uncertainty encoding, the uncertainty fields (LongUnc/LatUnc) directly represent the logarithms of uncertainty distances. So the low and high bounds get computed by first working out the uncertainty distances, then adding and subtracting them from the provided value. If "uncertainty" is the unsigned integer value of the uncertainty field and "value" is the value of the coordinate field:
distance = 2 ^ (8 - uncertainty)
lowvalue = value - distance
highvalue = value + distanceAltitude uncertainty (AltUnc in version 1) uses the same process with different constants:
distance = 2 ^ (21 - uncertainty)
lowvalue = value - distanceAppendix B. Calculations of Resolution
Here we've got two example locations showing how the resolution values for latitude, longitude, and altitude (used in DHCPv4 GeoConf Option 123) can be worked out. In both examples the geo-location values came from maps using the WGS84 map datum, so the Datum field in these examples would have a value = 1 (00000001, or 0x01) 🗽
B.1. Location Configuration Information of "White House" (Example 1)
The grounds of the White House in Washington D.C. (1600 Pennsylvania Ave. NW, Washington, DC 20006) can be found between 38.895375 and 38.898653 degrees North and 77.037911 and 77.035116 degrees West. In this example, we're standing on the sidewalk on the north side of the White House, between driveways. Since we're not inside a structure, we assume an altitude value of 15 meters, interpolated from the US Geological survey map, Washington, Washington West quadrangle 🇺🇸
The address was NOT picked for any political reason. It can easily be found on the Internet or in mapping software, and it was picked just as an easily identifiable spot on our planet 🌎
In this example, the requirement of emergency responders in North America, via their National Emergency Number Association (NENA) Model Legislation [NENA], could be met by a LaRes value of 21 and a LoRes value of 20. That would yield a geo-location that is latitude 38.8984375 north to latitude 38.8988616 north and longitude -77.0371094 to longitude -77.0375977. It's an area of approximately 89 feet by 75 feet, or 6669 square feet, which is very close to the 7000 square feet NENA asked for. In this example, a service provider could enforce that a device sends location configuration information with this minimum amount of resolution for this particular location when calling emergency services 🚨
An approximate representation of this location might be given using the DHCPv4 GeoConf Option 123 encoding like this:
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) | LaRes | Latitude .
|0 1 1 1 1 0 1 1|0 0 0 1 0 0 0 0|0 1 0 0 1 0|0 0 0 1 0 0 1 1 0 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Latitude (cont'd) | LoRes | .
.1 1 0 0 1 0 1 1 1 0 0 1 1 0 0 0 0 1 1 0 0 0 1 1|0 1 0 0 0 1|1 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Longitude (cont'd) |
.0 1 1 0 0 1 0 1 1 1 1 0 1 1 0 1 0 1 0 0 0 0 1 0 1 1 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AType | AltRes | Altitude .
|0 0 0 1|0 1 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Alt (cont'd) | Res |Datum|
.0 0 0 0 0 0 0 0|0 0 0 0 0|0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+In hexadecimal, this comes out as 7B10484D CB986347 65ED42C4 1440000F 0001 🌸
B.1.1. Decoding Location Configuration Information with Resolution ✨
okay so decoding this option gives us a latitude of 38.897647 (to 7 decimal places) with 18 bits of resolution, a longitude of -77.0366000 with 17 bits of resolution, an Altitude Type of meters with a value of 15 and 17 bits of resolution, version 0 (resolution), and the WGS84 datum 🗺️💖
for the latitude, 18 bits of resolution allow for values from 38.8964844 to 38.8984375. for the longitude, 17 bits of resolution allow for values from -77.0390625 to -77.0351563. and having 17 bits of resolution in the altitude allows for values from 0 to 32 meters. the bits really said "be precise" 💅
B.1.2. GML Representation of Decoded Location Configuration Information 🧚
this GML shows the value we just decoded 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>38.897647 -77.0366 15</gml:pos>
</gml:Point>this representation ignores the values in the resolution parameters. if resolution values are provided, a rectangular prism can be used to represent the location, which is kind of iconic honestly 🎀
here's the example that uses all of the decoded info from the previous one:
<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>
38.8964844 -77.0390625 0
38.8964844 -77.0351563 0
38.8984375 -77.0351563 0
38.8984375 -77.0390625 0
38.8964844 -77.0390625 0
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
32
</gs:height>
</gs:Prism>B.2. Location Configuration Information of "Sydney Opera House" (Example 2)
wait, I mixed up the numbering there. the next part is actually B.2, the "Sears Tower" example, so let's keep it in order 💀
okay for real this time: B.2 is the "Sears Tower" example, and that one lives in the earlier part, so we pick up right after the Prism code above. bestie, the next thing we actually need is Appendix C, so here it is 🦋
Appendix C. Calculations of Uncertainty 🌸
this example shows how uncertainty values for latitude, longitude, and altitude (LatUnc, LongUnc, and AltUnc used in the DHCPv6 GeoLoc Option 63 as well as DHCPv4 GeoLoc Option 144) can be calculated. it's literally the math behind the vibes 🧮✨
C.1. Location Configuration Information of "Sydney Opera House" (Example 3)
this section describes an example of encoding and decoding the geodetic DHCP Option. the textual results are expressed in GML [OGC-GML3.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 (AType = 1). no cap, the setup is clean 💅
C.1.1. Encoding a Location into DHCP Geodetic Form 🏛️
this example draws a rough polygon around the Sydney Opera House. the polygon has these 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 Ethe top of the building is 67.4 meters above sea level, and a starting altitude of 0 meters above the WGS84 geoid is assumed. the sea level part is giving main character energy 🌊
the first step is to find the range of latitude and longitude values. latitude ranges from -33.857720 to -33.856299, and longitude ranges from 151.214495 to 151.215906.
for this example, the point we encode is the middle of each range, which is (-33.8570095, 151.2152005). that gets encoded as (1110111100010010010011011000001101, 0100101110011011100010111011000011) in binary, or (3BC49360D, 12E6E2EC3) in hexadecimal notation (with an extra 2 bits of leading padding on each). the altitude is set at 33.7 meters, which is 000000000000000010000110110011 (binary) or 000021B3 (hexadecimal). ate 🍓
the latitude uncertainty (LatUnc) comes from inserting the difference between the center value and the outer value into the formula from Section 2.3.2. so it looks like this:
x = 8 - ceil( log2( -33.8570095 - -33.857720 ) )the result of this equation is 18, so the uncertainty is encoded as 010010 in binary.
longitude uncertainty (LongUnc) works the same way:
x = 8 - ceil( log2( 151.2152005 - 151.214495 ) )the result here is also 18, or 010010 in binary. slay, consistent 🔥
altitude uncertainty (AltUnc) uses the formula from Section 2.4.5:
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) gives us this DHCPv4 GeoLoc Option 144 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 (144) | 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) |Ver| Res |Datum|
.1 0 1 1 0 0 1 1|0 1|0 0 0|0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+in hexadecimal, this is 7B104BBC 49360D49 2E6E2EC3 13C00021 B341. the DHCPv6 form only differs in the code and option length portion, so that's a glow-up with a tiny change 🦋
C.1.2. Decoding a Location from DHCP Geodetic Form 🔍
if we receive the binary form we just made, this section describes how it gets interpreted. the result is then represented as a GML object, as defined in [GeoShape]. 💜
a latitude value of 1110111100010010010011011000001101 decodes to -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 two's complement negative), then subtract 2 to the power of 34 (the total number of bits). 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 of 0.0009765625 using the formula from Section 2.3.2. so the decoded latitude 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). pure precision 🎯
the encoded altitude of 000000000000000010000110110011 decodes to 33.69921875. the encoded uncertainty of 15 gives a value of 64, so the final uncertainty is 33.69921875 +/- 64 (or the range from -30.30078125 to 97.69921875). that's a wide range, bestie, but it's honest 🙈
C.1.2.1. GML Representation of Decoded Locations 🌈
the following GML shows the value we just decoded 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>and here's the example that uses all of the decoded info from the previous one:
<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). 🙏
Appendix D. Changes from RFC 3825 ✨
okay so this is the glow-up log 💅 it lists the major changes between RFC 3825 and this document. minor stuff like style, grammar, spelling, and editorial tweaks isn't mentioned here, so don't come for me if you spot a typo 🙈
- Section 1 now includes clarifications on wired and wireless uses. 📡
- The former Sections 1.2 and 1.3 have been removed. Section 1.2 now defines the concepts of uncertainty and resolution, as well as conversion between the DHCP option formats and PIDF-LO. 🧚
- A DHCPv6 GeoLoc Option is now defined (Section 2.1) as well as a new DHCPv4 GeoLoc Option (Section 2.2.2). 🎀
- The former Datum field has been split into three fields: Ver, Res, and Datum. These fields are used in both the DHCPv4 GeoLoc Option and the DHCPv6 GeoLoc Option. ✨
- Section 2.2.3 has been added, describing option support requirements on DHCP clients and servers. 💖
- Section 2.3 has been added, describing the Latitude and Longitude fields. 🌸
- Section 2.3.1 has been added, covering latitude and longitude resolution. 🦋
- Section 2.3.2 has been added, covering latitude and longitude uncertainty. 🫶
- Section 2.4 has been added, covering values of the Altitude field (Sections 2.4.1, 2.4.2, and 2.4.3), altitude resolution (Section 2.4.4), and altitude uncertainty (Section 2.4.5). ⭐
- Section 2.5 has been added, covering the Datum field. 👑
- Section 3 (Security Considerations) has added a recommendation on link-layer confidentiality. 🔥
- Section 4 (IANA Considerations) has consolidated material relating to parameter allocation for both the DHCPv4 and DHCPv6 option parameters, and has been rewritten to conform to the practices recommended in RFC 5226. 🍓
- The material formerly in Appendix A has been updated and shortened and has been moved to Appendix B. 🧁
- An Appendix A on GML mapping has been added. 🌈
- Appendix C has been added, providing an example of uncertainty encoding. 💜
- Appendix D has been added, detailing the changes from RFC 3825. (yes, this section is literally describing itself, main character energy 💅✨)
Authors' Addresses 💌
these are the people who made it happen, bestie 🫶 here's where you can reach them:
James M. Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX 75082
USA
EMail: jmpolk@cisco.com
Marc Linsner
Cisco Systems
Marco Island, FL 34145
USA
EMail: marc.linsner@cisco.com
Martin Thomson
Andrew Corporation
PO Box U40
Wollongong University Campus, NSW 2500
AU
EMail: martin.thomson@andrew.com
Bernard Aboba (editor)
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: bernard_aboba@hotmail.com📦 where this page comes from
- ietf: rfc6225 2011-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms