Internet Engineering Task Force James M. Polk
Internet Draft John Schnizlein
Expiration: April 21st, 2003 Marc Linsner
File: draft-polk-dhcp-geo-loc-option-00.txt Cisco Systems
DHCP Option for Geographic Location
October 21st, 2002
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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.
Abstract
This document specifies a Dynamic Host Configuration Protocol option for
the geographic location of the client. The location includes latitude,
longitude, and altitude, with resolution indicators for each.
Polk/Schnizlein/Linsner Page 1
Internet Draft DHCP Option for Location Insertion Oct 21st, 2002
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.0 Format of DHCP Location Option . . . . . . . . . . . . . . . . . . 4
2.1 Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.0 Security Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 5
5.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.0 Author Information . . . . . . . . . . . . . . . . . . . . . . . . 5
1.0 Introduction
This document specifies a Dynamic Host Configuration Protocol [1] Option
for the geographic location of the client, to be provided by the server.
The DHCP server is assumed to have determined the location from the
Circuit-ID RAIO defined (as SubOpt 1) in [2]. In order to translate the
circuit (switch port identifier) into a location, the DHCP server is
assumed to have access to a service that maps from circuit-ID to the
location at which the circuit connected to that port terminates in the
building; for example, the location of the wall jack.
1.1 Conventions
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 RFC-2119 [3].
1.2 Motivation
As applications such as IP Telephony are replacing conventional telephony,
users are expecting the same (or greater) level of services with the new
technology. One service offered by conventional telephony that is
missing, in any standardized fashion, within IP Telephony is for a user to
be automatically located by emergency responders, in a timely fashion,
when the user summons help (by dialing 911 in North America, for example).
Unless strict administrative rules are followed, the mobility of a wired
Ethernet device within a campus negates any opportunity for an emergency
responder to locate the device with any degree of expediency. Users do
not want to give up this mobility. Informing the host device of its geo-
location at host configuration time will allow the device to utilize this
geo-location information to inform others of it's current geo-location, if
Polk/Schnizlein/Linsner Page 2
Internet Draft DHCP Option for Location Insertion Oct 21st, 2002
the user and/or application so desires.
The goal of this option is to enable a wired Ethernet host to provide its
location to an emergency responder, as one example.
Wireless hosts can utilize this option to gain knowledge of the location
of the radio access point used during host configuration, but will need
some more exotic mechanisms, maybe GPS, or maybe a future DHCP option,
which includes a list of geo-loc objects like that defined here, which
has the locations of the radio access points that are close to the client.
1.3 Rationale
Latitude and Longitude are represented in fixed-point 2s-complement binary
degrees, for the economy of a smaller option size compared to the string
encoding of digits in [4]. The integer parts of these fields are 9 bits
long to accommodate +/- 180 degrees. The fractional part is 25 bits long,
better than the precision of 7 decimal digits of precision. Each parameter
is 40 bits total, in length.
Altitude is represented in measurement units (MU) indicated by the MU
field, which is 4 bits long. Two measurement units are defined here,
meters (code=1) and floors (code=2), both of which are 2s-complement
fixed-point with 8 bits of fraction. Additional measurement units MAY be
assigned by IANA. The floor of a building is often the relevant location
information, and not necessarily computable from meters of altitude. The
30-bit length of this field, with 8 bits of fractional part provides
precision comparable (~4 mm) to the fractional-degree parameters.
Each of these 3 variables is preceded by an accuracy sub-field of 6 bits,
indicating the number of bits of resolution. This resolution sub-field
accommodates the [GEOPRIV] requirement to easily adjust the accuracy of
a reported location. Contents beyond the claimed resolution MAY be
randomized to obscure greater precision that might be available.
Polk/Schnizlein/Linsner Page 3
Internet Draft DHCP Option for Location Insertion Oct 21st, 2002
2.0 Format of DHCP Location Option
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 TBD | 15 | LaRes | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LoRes | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MU | AltRes | Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt (cont'd) |
+-+-+-+-+-+-+-+-+
2.1 Elements
Code TBD: The code for this DHCP option is TBD by IANA.
15: The length of this option is 15 bytes.
LaRes: Latitude resolution. 6 bits indicating the valid number of
reliable bits in the fixed-point value of Latitude.
Values above decimal 34 are currently Undefined and reserved.
Latitude: Latitude a 34 bit fixed point value consisting of 9 bits
of integer and 25 bits of fraction. Latitude SHOULD be
normalized to within +- 90 degrees.
LoRes: Longitude resolution. 6 bits indicating the number of valid
bits in the fixed-point value of Longitude.
Values above decimal 34 are currently undefined and reserved.
Longitude: a 34 bit fixed point value consisting of 9 bits of integer
and 25 bits of fraction. Longitude SHOULD be normalized to
within +- 180 degrees.
AltRes: Altitude resolution. 6 bits indicating the number of valid
bits in the altitude. Values above 30 decimal are undefined
and reserved.
MU: Measurement unit for altitude. Codes defined here are:
1: Meters - in 2s-complement fixed-point 22-bit integer part with
8-bit fraction
2: Floors - in 2s-complement fixed-point 22-bit integer part with
8-bit fraction
Polk/Schnizlein/Linsner Page 4
Internet Draft DHCP Option for Location Insertion Oct 21st, 2002
Other MU codes TBD by IANA.
Altitude: 30-bit value with format defined by the Measurement Unit.
3.0 Security Considerations
Where critical decisions might be based on the value of this GeoLoc
option, DHCP authentication in [5] SHOULD be used to protect the integrity
of the DHCP options.
4.0 IANA Considerations
The DHCP option code for the GeoLoc option is TBD.
Altitude Measurement Units beyond the two defined in this document are
TBD.
5.0 References
[1] Droms R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997
[2] Patrick M., "DHCP Relay Agent Information Option", RFC 3046, January
2001
[3] Bradner S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997
[4] Farrell C., Schulze M., Pleitner S. and Baldoni D., "DNS Encoding of
Geographical Location", RFC 1712, November 1994.
[5] Droms R., "Authentication for DHCP Messages", RFC 3118, June 2001
6.0 Author Information
James M. Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082 USA
jmpolk@cisco.com
John Schnizlein
Cisco Systems
9123 Loughran Road
Fort Washington, MD 20744 USA
john.schnizlein@cisco.com
Polk/Schnizlein/Linsner Page 5
Internet Draft DHCP Option for Location Insertion Oct 21st, 2002
Marc Linsner
Cisco Systems
210 Waterway Ct. #101
Marco Island, FL 34145 USA
marc.linsner@cisco.com
"Copyright (C) The Internet Society (February 23rd, 2001).
All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."
The Expiration date for this Internet Draft is:
April 21st, 2003
Polk/Schnizlein/Linsner Page 6