draft-ietf-geopriv-dhcp-lbyr-uri-option-06.txt   draft-ietf-geopriv-dhcp-lbyr-uri-option-07.txt 
Geopriv WG James Polk Geopriv WG James Polk
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track (PS) Sept 14, 2009 Intended status: Standards Track (PS) March 7, 2010
Expires: March 14, 2010 Expires: Sept 7, 2010
Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6
Option for a Location Uniform Resource Identifier (URI) Option for a Location Uniform Resource Identifier (URI)
draft-ietf-geopriv-dhcp-lbyr-uri-option-06 draft-ietf-geopriv-dhcp-lbyr-uri-option-07
Abstract
This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for transmitting a client's geolocation Uniform Resource
Identifier (URI) of a client, which can be dereferenced in a
separate transaction by the client or an entity the client sends
this URI to.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. This document may contain the provisions of BCP 78 and BCP 79.
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 14, 2010. This Internet-Draft will expire on September 7, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your publication of this document. Please review these documents
rights and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
Legal document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
This documents and the information contained therein are provided on warranty as described in the BSD License.
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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Abstract
This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for transmitting a client's geolocation Uniform Resource
Identifier (URI) of a client, which can be dereferenced in a
separate transaction by the client or an entity the client sends
this URI to.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Format of the DHCP LuriElement Option . . . . . . . . . . . . 4 2. Format of the DHCP LuriElement Option . . . . . . . . . . . . 4
2.1. Overall Format of LuriElement Option in IPv4 . . . . . 5 2.1. Overall Format of LuriElement Option in IPv4 . . . . . 4
2.2. Overall Format of LuriElement Option in IPv6 . . . . . 5 2.2. Overall Format of LuriElement Option in IPv6 . . . . . 5
2.3. LuriElement Format for both IPv4 and IPv6 . . . . . . . 6 2.3. LuriElement Format for both IPv4 and IPv6 . . . . . . . 5
3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 7 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 6
3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8
3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 9 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8
3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 8, line 54 skipping to change at page 8, line 32
to view the PIDF-LO of the target whose location is indicated in to view the PIDF-LO of the target whose location is indicated in
a presence document. The dereference transaction will be, in a presence document. The dereference transaction will be, in
many environments, challenged by the Location Server. The nature many environments, challenged by the Location Server. The nature
of this challenge is out of scope of this document. of this challenge is out of scope of this document.
o This document does not prevent some environments from operating o This document does not prevent some environments from operating
in a possession model, for example - tightly controlled in a possession model, for example - tightly controlled
enterprise networks, but this operation SHOULD NOT be assumed to enterprise networks, but this operation SHOULD NOT be assumed to
exist as a matter of local policy. The costs associated with exist as a matter of local policy. The costs associated with
authorization vs. possession models are discussed in Section authorization vs. possession models are discussed in Section
3.3.2 of [ID-GEO-RA]. 3.3.2 of [RFC5606].
3.2 Harmful URIs and URLs 3.2 Harmful URIs and URLs
There are, in fact, some types of URIs that are not good to receive, There are, in fact, some types of URIs that are not good to receive,
due to security concerns. For example, any URLs that can have due to security concerns. For example, any URLs that can have
scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web
pages that have scripts. Therefore, pages that have scripts. Therefore,
o URIs received via this Option SHOULD NOT be sent to a o URIs received via this Option SHOULD NOT be sent to a
general-browser to connect to a web page, because they could have general-browser to connect to a web page, because they could have
skipping to change at page 9, line 31 skipping to change at page 9, line 13
registers acceptable location URI schemes (or types). registers acceptable location URI schemes (or types).
3.3 Valid Location URI Schemes or Types 3.3 Valid Location URI Schemes or Types
This section specifies which URI types are acceptable as a location This section specifies which URI types are acceptable as a location
URI scheme (or type) for this DHCP Option: URI scheme (or type) for this DHCP Option:
1. sip: 1. sip:
2. sips: 2. sips:
3. pres: 3. pres:
4. http:
5. https:
URIs using the "pres" scheme are dereferenced using the presence
event package for SIP [RFC3856], so they will reference a PIDF-LO
document when location is available. Responses to requests for URIs
with other schemes ("sip", "sips", "http", and "https") MUST have
MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS
URIs MAY refer to information with MIME type 'application/held+xml',
in order to support HELD dereferencing [ID-HELD-DEREF]. Clients can
indicate which MIME types they support using the "Accept" header
field in SIP [RFC3261] or HTTP [RFC2616].
These location URI types are IANA registered in Section 4.2 of this These location URI types are IANA registered in Section 4.2 of this
document. document.
4. IANA Considerations 4. IANA Considerations
4.1 The IPv4 Option number for this Option 4.1 The IPv4 Option number for this Option
This document IANA registers this IPv4 Option number XXX (to be This document IANA registers this IPv4 Option number XXX (to be
assigned by IANA once this document becomes an RFC). assigned by IANA once this document becomes an RFC).
skipping to change at page 10, line 15 skipping to change at page 10, line 10
4.4 IANA Considerations for Acceptable Location URI Types 4.4 IANA Considerations for Acceptable Location URI Types
IANA is requested to create a new registry for acceptable location IANA is requested to create a new registry for acceptable location
URI types. URI types.
The following 3 URI types are registered by this document: The following 3 URI types are registered by this document:
1. sip: 1. sip:
2. sips: 2. sips:
3. pres: 3. pres:
4. http:
5. https:
Any additional location URI types to be defined for use via Any additional location URI types to be defined for use via
this DHC Option need to be created and IANA registered with peer this DHC Option need to be created and IANA registered with peer
review and an RFC. review and an RFC.
4.5 IANA Considerations for LuriTypes 4.5 IANA Considerations for LuriTypes
IANA is requested to create a new registry for acceptable location IANA is requested to create a new registry for acceptable location
types defined in Section 3.2 of this document, arranged similar to types defined in Section 3.2 of this document, arranged similar to
this: this:
skipping to change at page 11, line 36 skipping to change at page 11, line 35
When implementing a DHC server that will serve clients across an When implementing a DHC server that will serve clients across an
uncontrolled network, one should consider the potential security uncontrolled network, one should consider the potential security
risks therein. risks therein.
6. Acknowledgements 6. Acknowledgements
Thanks to James Winterbottom, Marc Linsner, Roger Marshall and Thanks to James Winterbottom, Marc Linsner, Roger Marshall and
Robert Sparks for their useful comments. And to Lisa Dusseault for Robert Sparks for their useful comments. And to Lisa Dusseault for
her concerns about the types of URIs that can cause harm. To her concerns about the types of URIs that can cause harm. To
Richard Barnes for inspiring a more robust Security Considerations Richard Barnes for inspiring a more robust Security Considerations
section. To Hannes Tschofenig and Ted Hardie for riding me to section, and for offering the text to incorporate HTTP URIs. To
comply with their concerns, including a good scrubbing of the nearly Hannes Tschofenig and Ted Hardie for riding me to comply with their
final doc. concerns, including a good scrubbing of the nearly final doc.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
skipping to change at page 12, line 22 skipping to change at page 12, line 19
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic
Host Configuration Protocol (DHCPv4)", RFC 3396, November Host Configuration Protocol (DHCPv4)", RFC 3396, November
2002 2002
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005 Format", RFC 4119, December 2005
[RFC3856] J. Rosenberg, "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004
7.2. Informative References 7.2. Informative References
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in
progress", July 2009 progress", Feb 2010
[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M.
Thomson, M. Dawson, "A Location Dereferencing Protocol Using Thomson, M. Dawson, "A Location Dereferencing Protocol Using
HELD", "work in progress", July 2009 HELD", "work in progress", January 2010
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004 Configuration Information", RFC 3825, July 2004
[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", RFC 4776, November 2006 Information ", RFC 4776, November 2006
[ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference
Mechanism", "work in progress", Feb 2009 Mechanism", "work in progress", November 2009
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004 "Geopriv Requirements", RFC 3693, February 2004
[ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J.
Polk, "Geolocation Policy: A Document Format for Expressing Polk, "Geolocation Policy: A Document Format for Expressing
Privacy Preferences for Location Information", "work in Privacy Preferences for Location Information", "work in
progress", Feb 2009 progress", July 2009
[ID-GEO-RA] J. Peterson, T. Hardie, J. Morris, " Implications of [RFC5606] J. Peterson, T. Hardie, J. Morris, " Implications of
'retransmission-allowed' for SIP Location Conveyance", 'retransmission-allowed' for SIP Location Conveyance",
"work in progress", March 2009 August 2009
[RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L.,
Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer
Protocol - HTTP/1.1", RFC 2616, June 1999
Authors' Address Authors' Address
James Polk James Polk
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas 76034 Colleyville, Texas 76034
USA USA
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
 End of changes. 21 change blocks. 
55 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/