Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)
draft-ietf-geopriv-dhcp-lbyr-uri-option-17

The information below is for an old version of the document
Document Type Active Internet-Draft (geopriv WG)
Last updated 2013-01-29 (latest revision 2013-01-28)
Replaces draft-polk-geopriv-dhcp-lbyr-uri-option
Stream IETF
Intended RFC status Proposed Standard
Formats plain text pdf html bibtex
Stream WG state WG Document
Document shepherd None
Shepherd write-up Show (last changed 2012-05-31)
IESG IESG state IESG Evaluation
Consensus Boilerplate Unknown
Telechat date
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Responsible AD Robert Sparks
IESG note The document shepherd for this document is Alissa Cooper (acooper@cdt.org).
Send notices to geopriv-chairs@tools.ietf.org, draft-ietf-geopriv-dhcp-lbyr-uri-option@tools.ietf.org
Network WG                                                   James Polk
Internet-Draft                                            Cisco Systems
Intended status: Proposed Standard                         Jan 28, 2013
Expires: June 28, 2013

        Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 
         Option for a Location Uniform Resource Identifier (URI)
              draft-ietf-geopriv-dhcp-lbyr-uri-option-17

Abstract

   This document creates a Dynamic Host Configuration Protocol (DHCP) 
   Option for transmitting a client's geolocation Uniform Resource 
   Identifier (URI), and another Option to explicitly indicate how long
   that location URI is to be considered valid. This Location URI can 
   then be dereferenced in a separate transaction by the client or sent
   to another entity and dereferenced to learn physically where the 
   client is located, but only while valid.  

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on June 28, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with 
   respect to this document.  Code Components extracted from this 
   document must include Simplified BSD License text as described in 
   Section 4.e of the Trust Legal Provisions and are provided without 
   warranty as described in the Simplified BSD License. 

Polk                    Expires June 28, 2013                  [Page 1]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Format of the DHCP LocationURI and Valid-For Options  . . . .  4
       2.1.  Overall Format of LocationURI Option in IPv4  . . . . .  4
       2.2.  Overall Format of LocationURI Option in IPv6  . . . . .  5
       2.3.  Overall Format of Valid-For Option in IPv4  . . . . . .  5
       2.4.  Overall Format of Valid-For Option in IPv6  . . . . . .  6
       2.5.  Rules for both LocationURI and Valid-For Options  . . .  6
   3.  DHCP Option Operation . . . . . . . . . . . . . . . . . . . .  8
       3.1 Architectural Assumptions . . . . . . . . . . . . . . . .  9
       3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 10
       3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 10
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 12
       7.1. Normative References . . . . . . . . . . . . . . . . . . 12
       7.2. Informative References . . . . . . . . . . . . . . . . . 13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 14

   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].

1.  Introduction

   This document creates a Dynamic Host Configuration Protocol (DHCP) 
   Option for transmitting a client's geolocation Uniform Resource 
   Identifier (URI), and another Option to explicitly indicate how long
   that location URI is to be considered valid. In this scenario, the 
   DHCP client is a Geopriv Target (i.e., the entity whose geolocation 
   is associated with the location URI). The DHCP implementation of the
   client can then make this location information available to other 
   applications for their usage.  This location URI points a Location 
   Server [RFC5808] which has the geolocation of the client (e.g., 
   uploaded into a wiremap database when the client attached wall-jack,
   or by means of 802.11 geolocation mechanisms).  

   Applications within the Target can then choose to deference this 
   location URI and/or transmit the URI to another entity as a means of
   conveying where the Target is located. Both Conveying and 
   Dereferencing a location URI is described in [RFC6442]. Session 
   Initiation Protocol (SIP) is not the only protocol that can 
   dereference a location URI; there is also HTTP-Enabled Location 
   Delivery (HELD)  [RFC6753] and HTTP [RFC2616].

   A Location Server (LS) stores the Target's location as a presence 
   document, called a Presence Information Data Format - Location 

Polk                    Expires June 28, 2013                  [Page 2]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

   Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server
   is the entity contacted during the act of dereferencing a Target's 
   location.  If the dereferencing entity has permission, defined in 
   [RFC6772], the location of the target will be received.  The LS 
   will grant permission to location inquiries based on the rules 
   established by a Rule Holder [RFC3693].  The LS has the ability to 
   challenge any request for a target's location, thereby providing 
   additive security properties before location revelation. 

   Possessing a location URI has advantages over having a PIDF-LO, 
   especially when a target's location changes.  With a location URI, 
   when a target moves, the location URI does not change (at least 
   within the same domain). The location URI can still be given out as 
   the reference to the Target's current location. The opposite is true
   if the location is conveyed by value in a message. Once the Target 
   moves, the previously given location is no longer valid, and if the 
   Target wants to inform another entity about its location, it has to 
   send the PIDF-LO to the location recipient (again). 

   A problem exists within existing RFCs that provide location to the 
   UA ([RFC6225] and [RFC4776]). Those DHCP Options for geolocation 
   values require an update of the entire location information (LI) 
   every time a client moves.  Not all clients will move frequently, 
   but some will.  Refreshing location values every time a client moves
   does not scale in certain networks/environments, such as IP-based 
   cellular networks, enterprise networks or service provider networks 
   with mobile endpoints.  An 802.11 based access network is one 
   example of this. Constantly updating Location Configuration 
   Information (LCI) to endpoints might not scale in mobile 
   (residential or enterprise or municipal) networks in which the 
   client is moving through more than one network attachment point, 
   perhaps as a person walks or drives with their client down a 
   neighborhood street or apartment complex or a shopping center or 
   through a municipality (that has IP connectivity as a service). 

   If the client was provided a location URI reference to retain and 
   hand out when it wants or needs to convey its location (in a 
   protocol other than DHCP), a location URI that would not change as 
   the client's location changes (within a domain).Scaling issues 
   would be significantly reduced to needing an update of the location 
   URI only when a client changes administrative domains - which is 
   much less often.  This delivery of an indirect location has the 
   added benefit of not using up valuable or limited bandwidth to the 
   client with the constant updates.  It also relieves the client from 
   having to determine when it has moved far enough to consider asking 
   for a refresh of its location.  

   In enterprise networks, if a known location is assigned to each 
   individual Ethernet port in the network, a device that attaches to 
   the network, such as a wall-jack (directly associated with a 
   specific Ethernet Switch port) will be associated with a known 
   location via a unique circuit-ID that's used by the Relay Agent 

Polk                    Expires June 28, 2013                  [Page 3]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

   Information Option (RAIO) defined in RFC 3046  [RFC3046].  This 
   assumes wall-jacks have an updated wiremap database.  RFC 6225 
   [RFC6225] and RFC 4776 [RFC4776] would return an LCI value of 
   location for either IPv4 or IPv6.  This document specifies how a 
   location URI is returned using DHCP.  The location URI points to a 
   PIDF-LO contained on an LS. Performing a dereferencing transaction, 
   that Target's PIDF-LO will be returned.  If local configuration has 
   the requirement of only assigning unique location URIs to each 
   client at the same attachment point to the network (i.e., same RJ-45
   jack or same 802.11 Access Point - except when triangulation is 
   used), then unique location URIs will be given out. They will all 
   have the same location at the record, relieving the backend Sighter 
   or LS from individually maintaining each location independently.

   The location URI Option can be useful in IEEE 802.16e connected 
   endpoints or IP cellular endpoints.  The location URI Option can be 
   configured on a router, such as a residential home gateway, such 
   that the router receives this Location URI Option as a client with 
   the ability to communicate to downstream endpoints as a server.

   How an LS responds to a dereference request can vary, and a policy 
   established by a Ruleholder [RFC3693] for a Location Target as to 
   what type of challenge(s) is to be used, how strong a challenge is 
   used or how precise the location information is given to a 
   Location Recipient (LR). This document does not provide mechanisms 
   for the LS to tell the client about policies or for the client to 
   specify a policy for the LS. While an LS should apply an appropriate
   access-control policy, clients must assume that the LS will provide 
   location in response to any request (following the possession model
   [RFC5808]).  For further discussion of privacy, see the Security 
   Considerations.

   This document IANA-registers the new IPv4 and IPv6 DHCP Options for 
   a location URI and Valid-For.

2.  Format of the DHCP LocationURI Option

2.1 Overall Format of LocationURI Option in IPv4

   The LocationURI Option format for IPv4 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    |   Length=XX   |                             .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .....                       LocationURI...                      .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .....                                                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Polk                    Expires June 28, 2013                  [Page 4]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

    Figure 1. IPv4 Fields for this LocationURI Option

   Code XXX:     The code for this DHCPv4 option (IANA assigned).

   Length=XX:    The length of this option, counted in bytes - not 
                 counting the Code and Length bytes. This is a variable
                 length Option, therefore the length value will change 
                 based on the length of the URI within the Option.

   LocationURI:  Location URI - This field, in bytes, is the URI 
                 pointing at the location record where the PIDF-LO for 
                 the Location Target resides. The LocationURI is always
                 represented in ASCII.

2.2 Overall Format of LocationURI Option in IPv6

   The LocationURI Option format for IPv6 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          option-code          |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        LocationURI...                       .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .....                                                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2. IPv6 fields of this LocationURI Option

   option-code: The code for this DHCPv6 option (IANA assigned).

   option-len:  The length of this option, counted in bytes - not 
                counting the option-code and option-len bytes. This is 
                a variable length Option, therefore the length value 
                will change based on the length of the URI within the 
                Option.

   LocationURI: see Section 2.1

2.3 Overall Format of Valid-For Option in IPv4

   The Valid-For Option format for IPv4 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    |                   Valid-For                 .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Polk                    Expires June 28, 2013                  [Page 5]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

  .....             |
    +-+-+-+-+-+-+-+-+

    Figure 1. IPv4 Fields for this Valid-For Option

   Code XXX:     The code for this DHCPv4 option (IANA assigned).

   Valid-For:    Valid-For - The time, in seconds, the LocationURI - 
                 received in the same DHCP message - is to be 
                 considered valid for dereferencing. The Valid-For is 
                 always represented as a four-byte unsigned integer.

2.4 Overall Format of Valid-For Option in IPv6

   The Valid-For Option format for IPv6 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          option-code          |           Valid-For         .....
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .....     Valid-For (Cont'd)      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2. IPv6 fields of this Valid-For Option

   option-code:  The code for this DHCPv6 option (IANA assigned).

   Valid-For:    see Section 2.3

2.5 Rules for both LocationURI and Valid-For Options

   The LocationURI and Valid-For Options have the following 
   rules:

   o Implementation of the Location URI Option is mandatory on the DHCP
     server and client, per this specification.

   o Implementation of the Valid-For Option is OPTIONAL on the DHCP 
     server and client, per this specification.

   o The Location URI Option MUST be sent from a server, and received 
     by a client with or without an accompanying Valid-For Option.

   The Valid-For Option offers no meaningful information to a client 
   without an accompanying Location URI Option, and might be 
   misunderstood or misapplied, therefore

   o The Valid-For Option MUST NOT be sent from a server, and received 
     by a client, without an accompanying Location URI Option.

Polk                    Expires June 28, 2013                  [Page 6]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

   o A client receiving a Valid-For Option without a Location URI 
     Option MUST ignore the Valid-For Option.

   o The Valid-For Option MUST only be considered in relation to the 
     Location URI Option. It has no other purpose in DHCP then in 
     relation to the Location URI (i.e., there is no other Option in 
     DHCP to which it has meaning).

   o The Valid-For Option MUST NOT cause any error in handling the 
     Location URI, i.e., if not understood, it MUST be ignored.

   o Servers MUST assume that clients will overwrite any existing, 
     previously sent values of Location URI Option and/or Valid-For 
     Option.

   o Clients MUST overwrite any existing, previously sent values of 
     Location URI Option and/or Valid-For Option when receiving the 
     next instance of either Option.

   The choice of the Valid-For value is a policy decision for the 
   operator of the DHCP server.  Like location URIs themselves, it can 
   be statically configured on the DHCP server or provisioned 
   dynamically (via an out-of-band exchange with a Location Information
   Server) as requests for location URIs are received.    

   o Clients receiving both a Location URI and Valid-For Options start 
     the Valid-For timer upon receipt of the DHCP message containing 
     both Options.

   o Applications MUST NOT make use of a location URI after it becomes 
     invalid (i.e., after the Valid-For timer expires).

   The Valid-For timer is used only at the application layer, as an 
   indication of when the URI can be used to access location.  It is 
   independent of the DHCP lease timer, and in no way related to the 
   DHCP state machine. 

   o Clients MUST NOT trigger an automatic DHCP refresh on expiry of 
     the Valid-For timer; rather, they SHOULD follow normal DHCP 
     mechanics.  

   Server operators should consider the relation between the Valid-For 
   time and the lease time.  Clients typically request a lease refresh 
   when half the lease time is up. If the Valid-For time is less than 
   the typical refresh rate (i.e., half the lease time), then for the 
   remaining interval, clients will run the risk of not having a usable
   location URI for applications.  If the Valid-For time is less than 
   half the typical refresh rate, it is a near certainty clients will 
   not have a usable location URI for the interval between the 
   Valid-For time and the typical refresh time for applications. For 
   example, if a lease is set to 24 hours, the typical refresh request 

Polk                    Expires June 28, 2013                  [Page 7]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

   is set to initiate at the 12 hour mark. If the Valid-For timer is 
   set to less than 24 hours, but more than 12 hours (in this example),
   the client might not be refreshed at the 12 hour mark and runs the 
   risk of not have a location URI for applications that request it.  
   If, on the other hand, the Valid-For timer is less than 12 hours (in
   this example, which is before a typical client would ask for a 
   refresh, applications will be without a usable location URI until 
   the full refresh has been received.

3. DHCP Option Operation

   The [RFC3046] RAIO can 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, per RFC 
   3396 [RFC3396].

   Per [RFC2131], subsequent LocationURI Options, which are 
   non-concatenated, overwrite the previous value.

   Location URIs MUST NOT reveal identity information of the user of 
   the device, since DHCP is a cleartext delivery protocol. For 
   example, creating a location URI such as

      sips:34LKJH534663J54@example.com 

   is better than a location URI such as

      sips:aliceisat123mainstatlantageorgiaus@example.com

   The username portion of the first example URI provides no direct 
   identity information (in which 34LKJH534663J54 is considered to be a
   random number in this example).

   In the <presence> element of a PIDF-LO document, there is an 
   'entity' attribute that identifies what entity *this* presence 
   document (including the associated location) refers to.  It is up to
   the PIDF-LO generator, either Location Server or an application in 
   the endpoint, to insert the identity in the 'entity' attribute.  
   This can be seen in [RFC4119].  The considerations for populating 
   the entity attribute value in a PIDF-LO document are independent 
   from the considerations for avoiding exposing identification 
   information in the username part of a location URI.

Polk                    Expires June 28, 2013                  [Page 8]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

   This Option is used only for communications between a DHCP client 
   and a DHCP server.  It can be solicited (requested) by the client, 
   or it can be pushed by the server without a request for it.  DHCP 
   Options not understood MUST be ignored [RFC2131].  A DHCP server 
   supporting this Option might or might not have the location of a 
   client.  If a server does not have a client's location, but needs to
   provide this Location URI Option to a client (for whatever reason), 
   an LS is contacted.  This server-to-LS transaction is not DHCP, 
   therefore it is out of scope of this document. Note that this 
   server-to-LS transaction could delay the DHCP messaging to the 
   client. If the server fails to have location before it transmits its
   message to the client, location will not be part of that DHCP 
   message. Any timers involved here are a matter of local 
   configuration.

   The deference of a target's location URI would not involve DHCP, but
   an application layer protocol, such as SIP or HTTP, therefore 
   dereferencing is out of scope of this document. 

   In the case of residential gateways being DHCP servers, they usually
   perform as DHCP clients in a hierarchical fashion up into a service 
   provider's network DHCP server(s), or learn what information to 
   provide via DHCP to residential clients through a protocol, such as 
   PPP.  In these cases, the location URI would likely indicate the 
   residence's civic address to all wired or wireless clients within 
   that residence.  

3.1 Architectural Assumptions

   The following assumptions have been made for use of this LocationURI
   Option for a client to learn its location URI (in no particular 
   order):

   o  Any user control (what [RFC3693] calls a 'Ruleholder') for access
      to the dereferencing step is assumed to be out of scope of this 
      document. An example authorization policy is in [RFC6772].

   o  The authorization security model vs. possession security model 
      discussion can be found in [RFC5606], describing what is expected
      in each model of operation.  It should be assumed that a location
      URI attained using DHCP will operate under an possession model by
      default. An authorization model can be instituted as a matter of 
      local policy.  An authorization model means possessing the 
      location URI does not give that entity the right to view the 
      PIDF-LO of the target whose location is indicated in a presence 
      document.  The dereference transaction will be challenged by the 
      Location Server only in an authorization model.  The nature of 
      this challenge is out of scope of this document.  

   o  This document does not prevent some environments from operating 
      in an authorization model, for example - in less tightly 

Polk                    Expires June 28, 2013                  [Page 9]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

      controlled networks. The costs associated with authorization vs. 
      possession models are discussed in Section 3.3.2 of [RFC5606].

3.2 Harmful URIs and URLs

   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 
   scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 
   pages that have scripts.  Therefore,

   o URIs received via this Option MUST NOT be automatically sent to a 
     general-browser to connect to a web page, because they could have 
     harmful scripts.

   o This Option MUST NOT contain "data:" URLs, because they could 
     contain harmful scripts.

   o Section 3.3 IANA registers acceptable location URI schemes (or 
     types) for use by this specification. Clients MUST reject URI 
     schemes not currently registered in IANA.

3.3  Valid Location URI Schemes or Types

   This section specifies which URI types are acceptable as a location 
   URI scheme (or type) for this DHCP Option:

   1. sip:
   2. sips:
   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 [RFC6753].  Clients can
   indicate which MIME types they support using the "Accept" header 
   field in SIP [RFC3261] or HTTP [RFC2616].

   See RFC 3922 [RFC3922] for using the "pres:" URI with XMPP.

   It is RECOMMENDED that implementers follow Section 4.6 of RFC 6442 
   [RFC6442] as guidance regarding which Location URI schemes to 
   provide in DHCP. That document discusses what a receiving entity 
   does when receiving a URI scheme that is not understood. Awareness 
   to the two URI types there is important for conveying location, if 
   SIP is used to convey a Location URI provided by DHCP.

Polk                    Expires June 28, 2013                 [Page 10]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

4.  IANA Considerations

4.1 The IPv4 Option number for the Location URI Option

   This document IANA registers the Location URI IPv4 Option number XXX 
   (to be assigned by IANA once this document becomes an RFC).

4.2 The IPv6 Option-Code for the Location URI Option

   This document IANA registers the Location URI IPv6 Option-Code XXX 
   (to be assigned by IANA once this document becomes an RFC).

4.3 The IPv4 Option number for the Valid-For Option

   This document IANA registers the Valid-For IPv4 Option number XXX 
   (to be assigned by IANA once this document becomes an RFC).

4.4 The IPv6 Option-Code for the Valid-For Option

   This document IANA registers the Valid-For IPv6 Option-Code XXX (to 
   be assigned by IANA once this document becomes an RFC).

5.  Security Considerations

   Where critical decisions might be based on the value of this 
   location URI option, DHCP authentication in [RFC3118] SHOULD be used
   to protect the integrity of the DHCP options.  

   A real concern with RFC 3118 is that it is not widely deployed 
   because it requires pre-shared keys to successfully work (i.e., in 
   the client and in the server).  Most implementations do not 
   accommodate this.

   DHCP, initially, is a broadcast request (a client looking for a 
   server), and a unicast response (answer from a server) type of 
   protocol.  It does not provide security at the network layer.  
   Instead, it relies on lower-layer security mechanisms.  

   Once a client has a Location URI, it needs information on how the 
   location server will control access to dereference requests.  A 
   client might treat a tightly access-controlled URI differently from 
   one that can be dereferenced by anyone on the Internet (i.e., one 
   following the "possession model").  Since the client does not know 
   what policy will be applied during this validity interval, clients 
   MUST handle location URIs as if they could be dereferenced by 
   anybody until they expire.  For example, such open location URIs 
   should only be transmitted in encrypted channels.  Nonetheless, 
   location servers SHOULD apply appropriate access control policies, 

Polk                    Expires June 28, 2013                 [Page 11]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

   for example by limiting the number of queries that any given client 
   can make, or limiting access to users within an enterprise.  

   Extensions to this option, such as [ID-POLICY-URI] can provide 
   mechanisms for accessing and provisioning policy.  Giving users 
   access to policy information will allow them to make more informed 
   decisions about how to use their location URIs.  Allowing users to 
   provide policy information to the LS will enable them to tailor 
   access control policies to their needs (within the bounds of policy 
   that the LS will accept).

   As to the concerns about the location URI itself, as stated in the 
   document (see Section 3), it MUST NOT have any user identifying 
   information in the URI user-part/string itself.  The location URI 
   also needs to be hard to guess that it belongs to a specific user.  

   In some cases a DHCP server may be implemented across an 
   uncontrolled network.  In those cases, it would be appropriate for a
   network administrator to perform a threat analysis (see RFC 3552) 
   and take precautions as needed.

6.  Acknowledgements 

   Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 
   Robert Sparks for their useful comments. And to Lisa Dusseault for 
   her concerns about the types of URIs that can cause harm.  To 
   Richard Barnes for inspiring a more robust Security Considerations 
   section, and for offering the text to incorporate HTTP URIs.  To 
   Hannes Tschofenig and Ted Hardie for riding me to comply with their 
   concerns, including a good scrubbing of the nearly final doc. 

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.

 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
           March 1997.

 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 
           3046, January 2001.

 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 
           Messages", RFC 3118, June 2001.

 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
           Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
           Session Initiation Protocol", RFC 3261, May 2002.

Polk                    Expires June 28, 2013                 [Page 12]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic
           Host Configuration Protocol (DHCPv4)", RFC 3396, November 
           2002

 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 
           Initiation Protocol (SIP)", RFC 3856, August 2004

 [RFC3922] P. Saint-Andre, " Mapping the Extensible Messaging and 
           Presence Protocol (XMPP) to Common Presence and Instant 
           Messaging (CPIM)", RFC 3922, October 2004

 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 
           Format", RFC 4119, December 2005

 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 
           for the Session Initiation Protocol", RFC 6442, December 
           2011.

7.2.  Informative References

 [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

 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 
           "Geopriv Requirements", RFC 3693, February 2004

 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, 
           "Dynamic Host Configuration Protocol Options for 
           Coordinate-Based Location Configuration Information", 
           RFC 6225, July 2011.

 [RFC4776] H. Schulzrinne, "Dynamic Host Configuration Protocol 
           (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
           Information ", RFC 4776, November 2006

 [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of 
           'retransmission-allowed' for SIP Location Conveyance", 
           August 2009

 [RFC5808] R. Marshall, "Requirements for a Location-by-Reference 
           Mechanism", RFC 5808, May 2010  

 [RFC6753] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson, 
           M. Dawson, "A Location Dereferencing Protocol Using HELD", 
           "work in progress", October 2011

 [RFC6772] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. 
           Polk, "Geolocation Policy: A Document Format for Expressing 
           Privacy Preferences for Location Information", "work in 

Polk                    Expires June 28, 2013                 [Page 13]
Internet-Draft     Geopriv DHCP Location URI Option            Jan 2013

           progress", October 2011  

 [ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location 
           Configuration Extensions for Policy Management", "work in 
           progress", November 2011

Authors' Address

   James Polk
   3913 Treemont Circle
   Colleyville, Texas 76034 
   USA

   Email: jmpolk@cisco.com
   

Polk                    Expires June 28, 2013                 [Page 14]