Internet DRAFT - draft-tschofenig-dhc-lost-discovery
draft-tschofenig-dhc-lost-discovery
Network Working Group H. Tschofenig
Internet-Draft Siemens
Intended status: Standards Track August 22, 2006
Expires: February 23, 2007
A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service
Translation Protocol (LoST) Discovery Procedure
draft-tschofenig-dhc-lost-discovery-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 February 23, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Tschofenig Expires February 23, 2007 [Page 1]
Internet-Draft DHCP-based LoST Discovery August 2006
Abstract
The Location-to-Service Translation Protocol (LoST) describes an XML-
based protocol for mapping service identifiers and geospatial or
civic location information to service contact Uniform Resource
Locators (URIs). LoST servers can be located anywhere but a
placement closer to the end host, i.e., in the access network, is
desireable. Such a LoST server placement provides benefits in
disaster situations with intermittent network connectivity regarding
the resiliency of emergency service communication.
This document describes such a LoST discovery procedure based on
DHCP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Location-to-Service Translation Protocol (LoST) DHCPv4
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Location-to-Service Translation Protocol (LoST) DHCPv6
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Tschofenig Expires February 23, 2007 [Page 2]
Internet-Draft DHCP-based LoST Discovery August 2006
1. Introduction
The Location-to-Service Translation Protocol (LoST) describes an XML-
based protocol for mapping service identifiers and geospatial or
civic location information to service contact Uniform Resource
Locators (URIs). The typical procedure for running LoST at an end
host can be described via the following example. Note that the
details of the LoST protocol mechanisms are not relevant for this
protocol. The example aims to motive the scenario behind this
document. More information about LoST can be found at
[I-D.ietf-ecrit-lost].
After performing link layer attachment an end host performs stateful
address autoconfiguration using DHCP. Then, DHCP provides the end
host with civic location (as described in
[I-D.ietf-geopriv-dhcp-civil]) or with geospatial location
information (as described in [RFC3825]). The following example below
shows civic location information returned to the end host via DHCP.
Note that other protocols may be used to provide the end host with
location information. Furthermore, manual configuration or GPS might
be used.
The following example shown in Figure 1 indicates a location in the
US, state=New York, city=New York, group of streets=Broadway,
additional location information=Suite 75, and zip code=10027-0401.
+--------+---------------+
| CAtype | CAvalue |
+--------+---------------+
| 0 | US |
| 1 | New York |
| 3 | New York |
| 6 | Broadway |
| 22 | Suite 75 |
| 24 | 10027-0401 |
+--------+---------------+
Figure 1: DHCP Civic Information Example
Additionally, DHCP may provide information about the LoST server that
can be contacted. This document describes such an extension to allow
the DHCP server to also provide the IP address of the LoST server.
The end host can trigger the LoST protocol at any time: at
attachment time, at call time or some time in between. When the end
host initiates a LoST request, it includes its civic location and the
desired service URN in the message. Examples of service URNs can be
Tschofenig Expires February 23, 2007 [Page 3]
Internet-Draft DHCP-based LoST Discovery August 2006
found in [I-D.ietf-ecrit-service-urn]. The request in Figure 2 shows
the location information received with DHCP (as shown in Figure 1)
together with a request for an emergency service, namely
'urn:service:sos.police'.
<?xml version="1.0"?>
<findLoSTByCivic
validate="false"
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<civicLocation>
<p2:country>US</p2:country>
<p2:A1>New York</p2:A1>
<p2:A3>New York</p2:A3>
<p2:A6>Broadway</p2:A6>
<p2:LOC>Suite 75</p2:LOC>
<p2:PC>10027-0401</p2:PC>
</civicLocation>
<service>urn:service:sos.police</service>
</findLoSTByCivic>
Figure 2: Mapping Request
In our example we assume that the LoST server has the requested
information available and returns a successful response. The
response indicates, as a human readable display string that the 'New
York City Police Department' is responsible for the given
geographical area. The indicated URI allows the user to start
communication using SIP or XMPP. The 'validated' element indicates
which parts of the civic address were matched successfully against a
database and represent a known address. Other parts of the address,
in this example, the suite number, were ignored and not validated.
The returned service boundary indicates that all of New York City
would result in the same response. The service-number element
indicates that the service can be reached via the dial string 9-1-1.
Tschofenig Expires February 23, 2007 [Page 4]
Internet-Draft DHCP-based LoST Discovery August 2006
<?xml version="1.0" encoding="UTF-8"?>
<responseCivic
timeToLive="10000"
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc">
<displayName>New York City Police Department</displayName>
<region>
<civicLocation>
<p2:country>US</p2:country>
<p2:A1>New York</p2:A1>
<p2:A3>New York</p2:A3>
</civicLocation>
</region>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<service-number>911</service-number>
</responseCivic>
Figure 3: Mapping Response
The received URIs then serve, for example, as input to SIP as
described in [I-D.rosen-ecrit-framework] whereby the SIP message
might carry location information as shown in
[I-D.ietf-sip-location-conveyance].
This document describes only a LoST discovery procedure based on
information returned by the DHCP server. Other documents listed in
the example above provide further building blocks in order to obtain
location information via DHCP (see [I-D.ietf-geopriv-dhcp-civil] and
[RFC3825]), to map location and a service identifier to a service URI
(using LoST [I-D.ietf-ecrit-lost]), and a mechanism to convey the
received information in SIP using [I-D.ietf-sip-location-conveyance].
Tschofenig Expires February 23, 2007 [Page 5]
Internet-Draft DHCP-based LoST Discovery August 2006
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119
[RFC2119].
Within this document we use terminology from
[I-D.ietf-ecrit-requirements].
Tschofenig Expires February 23, 2007 [Page 6]
Internet-Draft DHCP-based LoST Discovery August 2006
3. Location-to-Service Translation Protocol (LoST) DHCPv4 Option
This section defines a LoST option that carries a list of 32-bit
(binary) IPv4 addresses indicating one or more Location-to-Service
Translation Protocol (LoST) servers available to the end host.
The DHCPv4 option for the LoST server has the format shown in
Figure 4.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ LoST IPv4 Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Location-to-Service Translation Protocol (LoST) DHCPv4
Option
option-code: OPTION_LOST (TBD)
option-length: Length of the 'options' field in octets;
MUST be a multiple of four (4)
LOST IPv4 Address: IPv4 address of a LoST server for the client to use.
The LoST servers are listed in the order of preference
for use by the client.
A DHCPv4 client requests the LOST DHCPv4 Option in a Parameter
Request List as described in [RFC2131] and [RFC2132].
The DHCPv4 client MUST try the records in the order listed in the
LOST DHCPv4 option.
Tschofenig Expires February 23, 2007 [Page 7]
Internet-Draft DHCP-based LoST Discovery August 2006
4. Location-to-Service Translation Protocol (LoST) DHCPv6 Option
This section defines a DHCPv6 option that carries a list of 128-bit
(binary) IPv6 addresses indicating one or more Location-to-Service
Translation Protocol (LoST) servers available to the end host.
The DHCPv6 option for Location-to-Service Translation Protocol (LoST)
server has the format shown in Figure 6.
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 | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ LoST IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Location-to-Service Translation Protocol (LoST) DHCPv6
Option
option-code: OPTION_LOST (TBD)
option-length: Length of the 'options' field in octets;
MUST be a multiple of sixteen (16)
LOST IPv6 Address: IPv6 address of a LoST server for the client to use.
The LoST servers are listed in the order of preference
for use by the client.
A DHCPv6 client requests the LOST DHCPv6 option in an Options Request
Option (ORO) as described in the DHCPv6 specification [RFC3315].
The DHCPv6 client MUST try the records in the order listed in the
LOST DHCPv6 option.
Tschofenig Expires February 23, 2007 [Page 8]
Internet-Draft DHCP-based LoST Discovery August 2006
5. IANA Considerations
The following DHCPv4 option code for the Location-to-Service
Translation Protocol (LoST) server option must be assigned by IANA:
Option Name Value Described in
-----------------------------------------------
OPTION_LOST TBD Section 5
The following DHCPv6 option codes for the Location-to-Service
Translation Protocol (LoST) options must be assigned by IANA:
Option Name Value Described in
------------------------------------------------
OPTION_LOST TBD Section 6
Tschofenig Expires February 23, 2007 [Page 9]
Internet-Draft DHCP-based LoST Discovery August 2006
6. Security Considerations
If an adversary manages to modify the response from a DHCP server or
insert its own response, a LoST client could be led to contact a
rogue LoST server. As a consequence the address of a non-existent
LoST server could be returned to the end host. Alternatively, the
adversary returns an IP address of a LoST server under the control of
the adversary. These threats are documented in
[I-D.ietf-ecrit-security-threats]. The security considerations in
[RFC2131], [RFC2132] and [RFC3315] are applicable to this document.
Tschofenig Expires February 23, 2007 [Page 10]
Internet-Draft DHCP-based LoST Discovery August 2006
7. Acknowledgements
The author of this document used draft-ietf-dhc-paa-option as a
template. Hence, acknowledgements go to the draft authors of
draft-ietf-dhc-paa-option.
The author would like to thank Christian Dickmann and Mayutan
Arumaithurai for their draft review.
Tschofenig Expires February 23, 2007 [Page 11]
Internet-Draft DHCP-based LoST Discovery August 2006
8. References
8.1. Normative References
[I-D.ietf-ecrit-lost]
Hardie, T., "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-00 (work in progress),
June 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, 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.
[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.
8.2. Informative References
[I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-11 (work in progress),
August 2006.
[I-D.ietf-ecrit-security-threats]
Taylor, T., "Security Threats and Requirements for
Emergency Call Marking and Mapping",
draft-ietf-ecrit-security-threats-03 (work in progress),
July 2006.
[I-D.ietf-ecrit-service-urn]
Schulzrinne, H., "A Uniform Resource Name (URN) for
Services", draft-ietf-ecrit-service-urn-04 (work in
progress), August 2006.
[I-D.ietf-geopriv-dhcp-civil]
Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information",
draft-ietf-geopriv-dhcp-civil-09 (work in progress),
January 2006.
Tschofenig Expires February 23, 2007 [Page 12]
Internet-Draft DHCP-based LoST Discovery August 2006
[I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Session Initiation Protocol
Location Conveyance",
draft-ietf-sip-location-conveyance-03 (work in progress),
June 2006.
[I-D.rosen-ecrit-framework]
Rosen, B., "Framework for Emergency Calling in Internet
Multimedia", draft-rosen-ecrit-framework-00 (work in
progress), June 2006.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
Tschofenig Expires February 23, 2007 [Page 13]
Internet-Draft DHCP-based LoST Discovery August 2006
Author's Address
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Phone: +49 89 636 40390
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Tschofenig Expires February 23, 2007 [Page 14]
Internet-Draft DHCP-based LoST Discovery August 2006
Full Copyright Statement
Copyright (C) The Internet Society (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 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).
Tschofenig Expires February 23, 2007 [Page 15]
