draft-ietf-geopriv-dhcp-lbyr-uri-option-08.txt   draft-ietf-geopriv-dhcp-lbyr-uri-option-09.txt 
Geopriv WG James Polk Geopriv WG James Polk
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track (PS) July 28, 2010 Intended status: Standards Track (PS) Oct 13, 2010
Expires: January 28, 2011 Expires: April 13, 2011
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-08 draft-ietf-geopriv-dhcp-lbyr-uri-option-09
Abstract Abstract
This document creates a Dynamic Host Configuration Protocol (DHCP) This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for transmitting a client's geolocation Uniform Resource Option for transmitting a client's geolocation Uniform Resource
Identifier (URI) of a client, which can be dereferenced in a Identifier (URI) of a client, which can be dereferenced in a
separate transaction by the client or an entity the client sends separate transaction by the client or an entity the client sends
this URI to. this URI to.
Status of this Memo Status of this Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 January 28, 2011. This Internet-Draft will expire on April 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1. Introduction 1. Introduction
This document creates a Dynamic Host Configuration Protocol (DHCP) This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for transmitting a client's geolocation Uniform Resource Option for transmitting a client's geolocation Uniform Resource
Identifier (URI). The DHCP implementation of the client can then Identifier (URI). The DHCP implementation of the client can then
make this location information available to upper layer protocols make this location information available to upper layer protocols
for their usage. This location URI points a Location Server for their usage. This location URI points a Location Server
[ID-LBYR-REQ] which has the geolocation of the client (through means [RFC5808] which has the geolocation of the client (through means
not defined in this document). In this scenario, the DHCP client not defined in this document). In this scenario, the DHCP client
is a Geopriv Target (i.e., the entity whose geolocation is is a Geopriv Target (i.e., the entity whose geolocation is
associated by the location URI). associated by the location URI).
Applications using upper layer protocols within the Target can then Applications using upper layer protocols within the Target can then
choose to deference this location URI and/or transmit the URI to choose to deference this location URI and/or transmit the URI to
another entity as a means of conveying where the Target is located. another entity as a means of conveying where the Target is located.
Dereferencing a location URI is described in [ID-SIP-LOC]. Conveying Dereferencing a location URI is described in [ID-SIP-LOC]. Conveying
a location URI is also described in [ID-SIP-LOC]. Session Initiation a location URI is also described in [ID-SIP-LOC]. Session Initiation
Protocol (SIP) is not the only protocol that can dereference a Protocol (SIP) is not the only protocol that can dereference a
skipping to change at page 4, line 45 skipping to change at page 4, line 45
2. Format of the DHCP LuriElement Option 2. Format of the DHCP LuriElement Option
2.1 Overall Format of LuriElement Option in IPv4 2.1 Overall Format of LuriElement Option in IPv4
The LuriElement Option format for IPv4 is as follows: The LuriElement Option format for IPv4 is as follows:
0 1 2 3 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 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 | Length=XX | Ver | Resv | . | Code XXX | Length=XX | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. LuriElements... ... . LuriElements... ...
. (see Section 2.3 for details) ... . . (see Section 2.3 for details) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. IPv4 Fields for this LuriElement Option Figure 1. IPv4 Fields for this LuriElement Option
Code XXX: The code for this DHCPv4 option (IANA assigned). Code XXX: The code for this DHCPv4 option (IANA assigned).
Length=XX: The length of this option, counted in bytes - not Length=XX: The length of this option, counted in bytes - not
counting the Code and Length bytes. This is a variable counting the Code and Length bytes. This is a variable
length Option, therefore the length value will change length Option, therefore the length value will change
based on the length of the URI within the Option. based on the length of the URI within the Option.
Ver: (4 bits) The version of this Option. This document
defines version 1 of this Option.
Resv: (4 bits) reserved for future use.
LuriElement: see Section 2.3 for details LuriElement: see Section 2.3 for details
2.2 Overall Format of LuriElement Option in IPv6 2.2 Overall Format of LuriElement Option in IPv6
The LuriElement Option format for IPv6 is as follows: The LuriElement Option format for IPv6 is as follows:
0 1 2 3 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 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-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Resv | . | LuriElements... .
+---------------+ . . (see Section 2.3 for details) |
. LuriElements... .
. (see Section 2.3 for details) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. IPv6 fields of this LuriElement Option Figure 2. IPv6 fields of this LuriElement Option
option-code: The code for this DHCPv6 option (IANA assigned). option-code: The code for this DHCPv6 option (IANA assigned).
option-len: The length of this option, counted in bytes - not option-len: The length of this option, counted in bytes - not
counting the Code and Length bytes. This is a variable counting the Code and Length bytes. This is a variable
length Option, therefore the length value will change length Option, therefore the length value will change
based on the shape within the Option. based on the length of the URI within the Option.
Ver: See above (Section 2.1). This will specify version 1.
Resv: See above (Section 2.1).
LuriElement: see below (Section 2.3 for details). LuriElement: see below (Section 2.3 for details).
2.3 LuriElement Format for both IPv4 and IPv6 2.3 LuriElement Format for both IPv4 and IPv6
The LuriElement, in both DHCPv4 and DHCPv6, have the following The LuriElement, in both DHCPv4 and DHCPv6, have the following
format: format:
0 1 2 3 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 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
skipping to change at page 6, line 32 skipping to change at page 6, line 19
The LuriTypes this document defines (and IANA registers) for a point The LuriTypes this document defines (and IANA registers) for a point
are: are:
LuriType=1 Location URI - This is the URI pointing at the LuriType=1 Location URI - This is the URI pointing at the
location record where the PIDF-LO resides which location record where the PIDF-LO resides which
indicates the location of the Location Target. indicates the location of the Location Target.
LuriType=2 Valid-For - The time, in seconds, this URI is to be LuriType=2 Valid-For - The time, in seconds, this URI is to be
considered Valid for dereferencing. The timer considered Valid for dereferencing. The timer
associated with this LuriType starts upon receipt of associated with this LuriType starts upon receipt of
this Option. this Option by the client.
The LuriType=2 (Valid-For) indicates how long, in seconds, the The LuriType=2 (Valid-For) indicates how long, in seconds, the
client is to consider this LuriType=1 (location URI) valid client is to consider this LuriType=1 (location URI) valid
before performing a refresh of this Option, with a refreshed before performing a refresh of this Option, with a refreshed
LuriType=2 (Valid-For) value. A Location URI refresh SHOULD be done LuriType=2 (Valid-For) value. A Location URI refresh SHOULD be done
the normal DHCP refresh rate, or necessitated by this timer, perhaps the normal DHCP refresh rate, or necessitated by this timer, perhaps
with the client only requesting this Option be refreshed. with the client only requesting this Option be refreshed.
If the LuriType=2 (Valid-For) timer is received (solicited or If the LuriType=2 (Valid-For) timer is received (solicited or
unsolicited), it is RECOMMENDED that the client refresh the Location unsolicited), it is RECOMMENDED that the client refresh the Location
URI when the (Valid-For) counter value has reaches the halfway URI when the (Valid-For) counter value has reaches the halfway
point. For example, if 16000 was the initial value of the point. For example, if 16000 was the initial value of the
LuriType=2 (Valid-For) value, when 8000 seconds have passed, the LuriType=2 (Valid-For) value, when 8000 seconds have passed, the
Option SHOULD be refreshed. Option SHOULD be refreshed.
The LuriType=2 (Valid-For) is not mandated for use by this document. The LuriType=2 (Valid-For) is not mandated for use by this document.
However, its presence MUST NOT cause any error in handling the However, its presence MUST NOT cause any error in handling the
location URI (i.e., if not understood, it MUST be ignored). location URI (i.e., if not understood, it MUST be ignored).
This Option format is highly extensible. Additional LuriType types This Option format is highly extensible. Additional LuriType types
created MUST be done so through IANA registration with peer review created MUST be done so through IANA registration with a standards
and an RFC. track RFC.
3. DHC Option Operation 3. DHC Option Operation
The [RFC3046] RAIO MUST be utilized to provide the appropriate The [RFC3046] RAIO can be utilized to provide the appropriate
indication to the DHCP Server where this DISCOVER or REQUEST message indication to the DHCP Server where this DISCOVER or REQUEST message
came from, in order to supply the correct response. That said, this came from, in order to supply the correct response.
Option SHOULD NOT be in a DISCOVER message, because there is zero
knowledge by the client of which Server will answer.
Caution SHOULD always be used involving the creation of large Caution SHOULD always be used involving the creation of large
Options, meaning that this Option MAY need to be in its own INFORM, Options, meaning that this Option MAY need to be in its own INFORM,
OPTION or ACK message. OPTION or ACK message.
It is RECOMMENDED to avoid building URIs, with any parameters, It is RECOMMENDED to avoid building URIs, with any parameters,
larger than what a single DHCP response can be. However, if a larger than what a single DHCP response can be. However, if a
message is larger than 255 bytes, concatenation is allowed, per RFC message is larger than 255 bytes, concatenation is allowed, per RFC
3396 [RFC3396]. 3396 [RFC3396].
skipping to change at page 8, line 24 skipping to change at page 8, line 11
The following assumptions have been made for use of this LuriElement The following assumptions have been made for use of this LuriElement
Option for a client to learn its location URI (in no particular Option for a client to learn its location URI (in no particular
order): order):
o Any user control (what [RFC3693] calls a 'Ruleholder') for access o Any user control (what [RFC3693] calls a 'Ruleholder') for access
to the dereferencing step is assumed to be out of scope of this to the dereferencing step is assumed to be out of scope of this
document. An example authorization policy is in [ID-GEO-POL]. document. An example authorization policy is in [ID-GEO-POL].
o The authorization vs. possession security model can be found in o The authorization vs. possession security model can be found in
[ID-LBYR-REQ], describing what is expected in each model of [RFC5808], describing what is expected in each model of
operation. It should be assumed that a location URI attained operation. It should be assumed that a location URI attained
using DHCP will operate under an authorization model. This means using DHCP will operate under an authorization model. This means
possessing the location URI does not give that entity the right possessing the location URI does not give that entity the right
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
skipping to change at page 9, line 45 skipping to change at page 9, line 32
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).
4.2 The IPv6 Option-Code for this Option 4.2 The IPv6 Option-Code for this Option
This document IANA registers this IPv6 Option-Code XXX (to be This document IANA registers this IPv6 Option-Code XXX (to be
assigned by IANA once this document becomes an RFC). assigned by IANA once this document becomes an RFC).
4.3 The Version number for this Option 4.3 IANA Considerations for Acceptable Location URI Types
This document IANA registers the version number 1 of this Option.
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: 4. http:
5. https: 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.4 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:
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
| LuriType | Name | Reference | | LuriType | Name | Reference |
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
| 1 | Location URI | RFC XXXX* | | 1 | Location URI | RFC XXXX* |
| 2 | Valid-For | RFC XXXX* | | 2 | Valid-For | RFC XXXX* |
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
* RFC XXXX is to be replaced with this document's RFC-Editor RFC * RFC XXXX is to be replaced with this document's RFC-Editor RFC
number. number.
Additions to this list require a standards track RFC. Additions to this registry require a standards track RFC.
5. Security Considerations 5. Security Considerations
Where critical decisions might be based on the value of this Where critical decisions might be based on the value of this
location URI option, DHCP authentication in [RFC3118] SHOULD be used location URI option, DHCP authentication in [RFC3118] SHOULD be used
to protect the integrity of the DHCP options. to protect the integrity of the DHCP options.
A real concern with RFC 3118 it is that not widely deployed because A real concern with RFC 3118 it is that not widely deployed because
it requires pre-shared keys to successfully work (i.e., in the it requires pre-shared keys to successfully work (i.e., in the
client and in the server). Most implementations do not client and in the server). Most implementations do not
skipping to change at page 12, line 25 skipping to change at page 12, line 5
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002. Session Initiation Protocol", RFC 3261, May 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
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 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004 Initiation Protocol (SIP)", RFC 3856, August 2004
[RFC5808] R. Marshall, Ed., "Requirements for a Location-by-Reference [RFC5808] R. Marshall, Ed., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010 Mechanism", RFC 5808, May 2010
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, J. Peterson, "SIP Location
progress", Feb 2010 Conveyance", "work in progress", July 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", January 2010 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 [RFC5808] R. Marshall, "Requirements for a Location-by-Reference
Mechanism", "work in progress", November 2009 Mechanism", RFC 5808, May 2010
[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", July 2009 progress", July 2010
[RFC5606] 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",
August 2009 August 2009
[RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L.,
Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer
Protocol - HTTP/1.1", RFC 2616, June 1999 Protocol - HTTP/1.1", RFC 2616, June 1999
[ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location [ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location
 End of changes. 21 change blocks. 
45 lines changed or deleted 25 lines changed or added

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