Subject: [dhcwg] Geographic position option

From: Sam Critchley <[email-masked]>
Date: Fri, 16 Aug 2002 16:51:32 +0200 (MET DST)

Hi,

Included below is a draft proposing an option to allow a DHCP server to
pass its geographic location to a DHCP client.

From RFC 2489:

"Preferably, the author will submit the Internet Draft to the DHC Working
Group,..."

and

"The specification is reviewed by the DHC WG (if it exists) or by the
IETF."

So, I'd be interested in people's comments on this document. What should I
do with the document now?

Many thanks,

Sam

Here is the draft:

************************************************************************

Network Working Group                                      Sam Critchley
Internet Draft                                             Worldcom, Inc

                                                            August, 2002
                                                   Expires January, 2003

	     The Geographic Position Option for DHCP
           <draft-critchley-dhc-location-option-00.txt>

Status of this Memo

   This document is an Internet-Draft and is subject to 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   This document describes a DHCP option in which the geographic
   position of the DHCP server is passed to the DHCP client in order
   to allow the client to make use of Location-Based Services.

1. 	Introduction

   Mobile telephony networks are able to make use of certain
   technologies which supply the geographic location of a mobile
   suscriber's handset to a Location-Based Services (LBS) provider. The
   mobile subscriber is then able to take advantage of such services
   as point-of-interest (POI) location, mapping, route-determination,
   traffic services and location-aware mobile instant messaging.

   There is currently no standardised mechanism in place to supply
   a geographic location to Internet hosts not connected to mobile
   telephony network, including, but not limited to, hosts connecting
   using IEEE 802.11x wireless protocols, and those connected to
   wire-based networks but configured with non-static IP addresses.
   Consequently, these hosts are more limited in their ability to
   take advantage of LBS, including having to manually enter a
   geographic position or street address in many cases.

   This document defines a DHCP option by which a DHCP server can pass
   its geographical location, in the form of a latitude, longitude and
   altitude position, to its clients.

   This document does not seek to define a method to allow a host to
   pass its location to a LBS server, as there are already in place
   several standards which propose these mechanisms, such as the Mobile
   Location Protocol (MLP) developed by the Location Interoperability
   Forum (LIF), although it does make one security recommendation in
   this area.

   Furthermore, this document does not attempt to propose a mechanism
   which would perform in the same manner as critical emergency location
   services such as the Enhanced 911 (E-911) service being implemented
   in US mobile telephony networks, nor does it propose a mechanism
   to be used for highly accurate positioning applications, such as that   provided by the Global Positioning System (GPS).

   However, the Geographic Position Option for DHCP does propose a
   mechanism which, in many cases, will provide a position to the same
   degree of accuracy as that provided by mobile telephony networks'
   geographic location mechanisms.

2. 	The Geographic Position Option for DHCP

2.1	DHCP Option field definitions.

   This option contains the following fields:

   a) Option Code - TBD
   b) Option length in bytes
   c) DHCP Server Geographic Position Sentence

    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  |    Length     |  Geographic Position Sentence |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Geographic Position Sentence                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . . .                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            . . . .                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2 	DHCP Server Geographic Position Sentence

   The DHCP Server Geographic Position Sentence takes the form of a
   comma-separated ASCII string of position terms. This is in some ways
   similar to the format used in the National Marine Electronics
   Association's NMEA 0183 and NMEA 2000 standards, commonly used by
   GPS navigation devices for passing location information to other
   devices.

   The sentence takes the following form:

   DHCPPS,A,B,C,D,E,F,G,H,I,J,K

   Where the following are field definitions:

   - DHCPPS - DHCP Position Sentence. Indicates to the DHCP client that
   this is a sentence designed to provide the geographic position of
   the DHCP server to the DHCP client, as opposed to any other
   information.

   - A - Latitude. Expressed in decimal degrees, to a maximum of 6
   decimal places.

   - B - Latitude N/S. Whether the latitude figure expressed is North or
   South of the equator, expressed simply as the letter "N" or the
   letter "S" in upper case.

   - C - Longitude. Expressed in decimal degrees, to a maximum of 6
   decimal places.

   - D - Longitude E/W. Whether the longitude figure expressed is East
   or West of the Greenwhich Meridian, expressed simply as the letter
   "E" or the letter "W" in upper case.

   - E - Altitude. The altitude, expressed to a maximum of 2 decimal
   places, and preceded with a "+" or a "-" symbol to indicate whether
   the value is above mean sea level (positive) or below mean sea level
   (negative).

   - F - Altitude unit. The upper-case letter "M" to indicate that the
   unit is in Metres, or the upper-case letters "FT" to indicate that
   the unit is in feet.

   - G - Horizontal Accuracy. The horizontal accuracy of the latitude
   and longitude position obtained by the DHCP client from the DHCP
   server. Intended to represent the maximum horizontal distance that
   a DHCP client will be from its DHCP server, and useful, for example,
   in the case of DHCP scenarios such as IEEE 802.11b setups using
   bridging, and where the DHCP client can expect to be some distance
   from the DHCP server. Figure given to a maximum of three decimal
   places.

   - H - Horizontal Accuracy unit. The upper-case letter "M" to indicate
   that the unit is in metres, the upper-case letters "KM" to indicate
   that the unit is in kilometres, the upper-case letters "FT" to
   indicate that the unit is in feet, or the upper-case letters "ML" to
   indicate that the unit is in miles.

   - I - Vertical Accuracy. The vertical accuracy of the Altitude
   position obtained by the DHCP client from the DHCP server. Intended
   to represent the maximum vertical distance that a DHCP client will be
   located from its DHCP server, and useful, for example, in the case
   of network segments located in tall buildings.

   - J - Vertical Accuracy unit. The upper-case letter "M" to indicate
   that the unit is in metres, the upper-case letters "KM" to indicate
   that the unit is in kilometres, the upper-case letters "FT" to
   indicate that the unit is in feet, or the upper-case letters "ML" to
   indicate that the unit is in miles.

   - K - Geodesic Datum. The standard abbreviated form of the geodesic
   datum used to calculate position. This term has a default value of
   "WGS84" should no datum be specified.

   The DHCP Server Geographic Position Sentence would normally have a
   maximum length of between 49 and 64 bytes, depending on the values
   used.

   Apart from the first term of the DHCP Server Geographic Position
   Sentence, which always must have a value of "DHCPPS", and must be
   present, the presence of a value in all other fields is optional.
   However, all fields, whether a value is present or not, must be
   comma-separated. Furthermore, it is understood that a DHCPPS
   containing few or no values might be of little use in determining
   the position of the DHCP client.

2.2.1 	Example of a DHCP Server Geographic Position Sentence

   DHCPPS,52.3742,N,4.8925,E,+3.12,M,50.9,M,5,M,WGS84

   This sentence indicates that the DHCP server is located at 52.3742
   degrees North, 4.8925 degrees East, at 3.12 metres above mean sea
   level, that the DHCP client is a maximum of 50.9 metres horizontally
   from the DHCP server, a maximum of 5 metres altitude above or below
   the DHCP server, and that the datum used to calculate this position
   was WGS-84.

2.3	Security Concerns

   Whilst this document does not seek to define a method to allow a
   host to pass its location to a LBS server, it does note that
   there are possible security concerns involved in the location of
   an Internet host being passed to an LBS server. In the case of mobile
   telephony networks, most subscriber locations are passed to an LBS
   server from a mobile provider's location server, not directly from
   the mobile handset, and the list of permitted LBS servers is strictly
   controlled. However, in the case of a Geographic Position option for
   DHCP, this security infrastructure may not be in place, and it is
   therefore recommended that any client application supplying a
   DHCP-acquired position to an LBS server should implement an adequate
   security mechanism to protect users from any possible wrongdoing.
   Such mechanisms might include implementing a list of permitted LBS
   servers, popup alerts when passing a host's location to an LBS
   server, or the ability to turn on/off the passing of location
   information.

3.	Author's Address

   Sam Critchley
   Worldcom EMEA Network Service
   Joan Muyskenweg 22
   1096 CJ Amsterdam
   The Netherlands

   Phone: +31 20 711 6082
   Email: [email-masked]

***************************************************************************

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ryan Scripps <[email-masked]>
Date: Fri, 16 Aug 2002 08:49:42 -0700 (PDT)

This is an interesting option, but I don't understand
it's relevance.  A DHCP client only talks to a DHCP
server when negotiating a lease.  Physical location is
unimportant in this transaction since physical
closeness does not necessarily imply "network
closeness".  Furthermore, as stated in the draft,
other mechanisms exist to query the physical location
of a client.

I look forward to further discussion.

-Ryan Scripps

>    to be used for highly accurate positioning
> applications, such as that   provided by the Global
> Positioning System (GPS).
> 
>     0                   1                   2       
>            3
>    |                            . . . .             
>               |
>    |                            . . . .             
>               |
>    Association's NMEA 0183 and NMEA 2000 standards,
> commonly 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

---

From: Sam Critchley <[email-masked]>
Date: Mon, 19 Aug 2002 12:35:34 +0200 (MET DST)

Hi Ryan,

Thanks for the comments as well, please see mine inline:

> other mechanisms exist to query the physical location

Well, in the case of growth in mobile access in the future, there
currently seem to be two main areas:

1. Mobile telephony-based systems, such as 2.5/3G solutions (GPRS, CDMA
1x, CDMA2000, UMTS etc). Content based a lot on i-Mode, WAP 2.0 etc. For
example, i-Mode here in the Netherlands seems to work pretty well and
there are a lot of services being developed.

2. 802.11-based access, with roaming across national/international
networks in many locations. Roaming agreements are in place, vendors are
shipping equipment with 802.11 devices built in, and apparently sales of
802.11b cards for laptops/PDAs etc are running around 1 million per month.

There are also combinations of the above, where with one subscription you
can have mobile telephony in most places, but switch to higher speed
802.11 when in range.

A lot of work is going in LBS mechanisms for the first option (and in
South Korea, for example, there are already over a million GPS-enabled
mobile phones which use them), but (as far as I can see) little is
happening for the second one, and I don't yet see a mechanism in place
which will tell me or an LBS server my location adequately, certainly not
with the security level I would require. To have a DHCP-based system which
would give you your position to, in many cases, a few metres accuracy,
would seem to at least be adequate to use many of the LBS services being
put together, in the absence of a host being able to acquire its exact
location.

> I look forward to further discussion.

Me too. :-)

Thanks,

Sam

> > do with the document now?

******************************************************
Sam Critchley           Technology Integration Manager
                        Network Services EMEA
[email-masked]  Worldcom
                       	Joan Muyskenweg 22
Tel: +31 20 711 6082    1096 CJ Amsterdam
                        The Netherlands
******************************************************