One document matched: draft-polk-geopriv-dhcp-lbyr-uri-option-00.txt
Geopriv WG James Polk
Internet-Draft Cisco Systems
Intended status: Standards Track May 11th, 2007
Expires: November 11th, 2007
Dynamic Host Configuration Protocol (DHCP) Option for a
Location-by-Reference (LbyR) Uniform Resource Identifier (URI)
draft-polk-geopriv-dhcp-lbyr-uri-option-00
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 November 11th, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for the Location-by-Reference (LbyR) Uniform Resource
Identifier (URI) of an endpoint. For example, an endpoint can be a
Session Initiation Protocol (SIP) User Agent Client (UAC), i.e., a
phone. This LbyR URI can be included in a UA's messages to inform
other nodes of that UA's geographic location, once the URI is
dereferenced by a Location Recipient.
Polk Expires Nov, 2007 [Page 1]
Internet-Draft Geopriv DHCP LbyR URI Option May 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in this Document . . . . . . . . . . . 3
2. DHC Location URI Elements . . . . . . . . . . . . . . . . . . 3
2.1. Elements of the Location Configuration Information . . 4
3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . 6
1. Introduction
This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for the Location-by-Reference (LbyR) Uniform Resource
Identifier (URI) of an endpoint. For example, an endpoint can be a
Session Initiation Protocol (SIP) User Agent Client (UAC), i.e., a
phone. This LbyR URI can be included in a UA's messages to inform
other nodes of that UA's geographic location, once the URI is
dereferenced by a Location Recipient [ID-SIP-LOC].
Endpoints will require their geographic location for a growing
number of services. A popular use-case currently is for emergency
services, in which SIP requires its location to be placed in a SIP
INVITE request message towards a public safety answering point
(PSAP). The reason for this is twofold:
o An emergency services SIP request must be routed/retargeted to the
appropriate PSAP that is local to where the PSAP is.
o The first responders require the UAC's location in order to know
where to go to render aid to the caller.
There are other use-cases, such as calling the appropriate Pizza Hut
without having to look up which store is closest. A UAC knowing its
location can call a main/national/international Pizza Hut number or
address and let the UAC's location tell Pizza Hut enough information
to have them route/retarget the SIP request to the appropriate store
within the Pizza Hut organization to deliver the pizza to the
caller.
A problem exists within existing RFCs that provide location to the
UAC, [RFC3825] and [RFC4776], that location has to be updated every
time a UAC moves. This does not scale in certain
networks/environments, such as enterprise networks or service
Polk Expires Nov, 2007 [Page 2]
Internet-Draft Geopriv DHCP LbyR URI Option May 2007
provider networks with mobile endpoints. An 802.11 based access
network is an example of this. This also might not scale in mobile
residential networks in which the UAC is hopping between more than
one network attachment point, perhaps as a person walks with their
UA down a neighborhood street or apartment complex.
If the UAC were provided a URI reference to retain and hand out when
it wants to convey its location, one that would not change as the
UAC's location changes, scaling issues would be significantly
reduced. This delivery of an indirect location has the added
benefit of not using up valuable or limited bandwidth to the UAC
with the constant updates. A service provider would merely update
what location is at the URI the UAC already has, with this new DHCP
Option.
In enterprise networks, a URI can be assigned to individual Ethernet
ports; meaning whatever is attached to a particular port will get
the same URI because that device is at a known location. This
scenario applies to 802.11 Access Points (AP), in which the AP's
location is what's known. The same URI can be given to all devices
attached to the same AP. Just as with residential router/gateways,
which can be wired or wireless, in which all devices understanding
this Option will be giving the location of the residence. The Option
also benefits from the URI not needing identity information to still
be useful.
APs that triangulate can also have a individual URI downloaded to
each endpoint with this Option, for the endpoint to hand out
whenever it is configured to in whatever protocol it is capable of.
This Option can be useful in WiMAX connected endpoints or IP
cellular endpoints. The Location URI Option can be configured as a
client if it is a router, such as a residential home gateway, with
the ability to communicate to downstream endpoints as a server.
This document IANA registers the new DHC Option for a Location URI.
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].
2. DHC Location URI Elements
DHCP is a binary Protocol; URIs are alphanumeric text based. There
is one byte per URI character.
[Editor's question: should UTF-8 vs. UTF-16 be accounted for?]
Polk Expires Nov, 2007 [Page 3]
Internet-Draft Geopriv DHCP LbyR URI Option May 2007
The Location URI Option format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code XXX | Option Length | Location URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location URI (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ .... \
\ .... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location URI (cont'd) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1. Elements of the Location Configuration Information
Code XXX: The code for this DHCP option.
Option Length: The length of this option variable.
Location URI: The Location URI
There are no additional fields within this Option, as the value of
the URI is contained within the URI field, including all URI
parameters and (what could become another protocol's) header
parameters.
3. DHC Option Operation
The [RFC3046] RAIO MUST be utilized to provide the appropriate
indication to the DHCP Server where this DISCOVER or REQUEST message
came from, in order to supply the correct response.
Caution SHOULD always be used involving the creation of large
Options, meaning that this Option MAY need to be in its own INFORM,
OPTION or ACK message.
It is RECOMMENDED to avoid building URIs, with any parameters,
larger than what a single DHCP response can be. However, if a
message is larger than 255 bytes, concatenation is allowed to be
used [RFC3396].
Per [RFC2131], subsequent LbyR URI Options, which are
non-concatenated, overwrite the previous value.
LbyR URIs SHOULD NOT reveal identity information of the user of the
device, since DHCP is a cleartext delivery protocol.
[Editor's question: can the above SHOULD NOT be a MUST NOT?]
Polk Expires Nov, 2007 [Page 4]
Internet-Draft Geopriv DHCP LbyR URI Option May 2007
4. Acknowledgements
You name here.... or if you write a fair piece of text, you can be a
co-author.
5. IANA Considerations
IANA is requested to assigned a DHCP option code of XXX for the
Location URI option defined in Section 2.0 of this document.
Any additional Location URI parameters to be defined for use via
this DHC Option MUST be done through a Standards Track RFC.
6. Security Considerations
Where critical decisions might be based on the value of this
LbyR URI option, DHCP authentication in [RFC3118] SHOULD be used to
protect the integrity of the DHCP options.
Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the DHCP server and
requesting client can discover this LbyR URI. Other than capturing
the URI, the location of the client benefits from the protection of
whatever server challenge mechanisms are available and configured
for any device attempting access of the location record that the
URI.
LbyR URIs need to reduce or eliminate client identity information
within the URI itself, because DHCP is a cleartext delivery
protocol.
When implementing a DHC server that will serve clients across an
uncontrolled network, one should consider the potential security
risks.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
Polk Expires Nov, 2007 [Page 5]
Internet-Draft Geopriv DHCP LbyR URI Option May 2007
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
7.2. Informative References
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance",
draft-ietf-sip-location-conveyance-07.txt, "work in
progress", Feb 2007
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", RFC 4776, November 2006
Authors' Address
James M. Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082 USA
EMail: jmpolk@cisco.com
USA
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Polk Expires Nov, 2007 [Page 6]
Internet-Draft Geopriv DHCP LbyR URI Option May 2007
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).
Polk Expires November 2007 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 01:31:27 |