DHC Working Group James Polk Internet Draft Cisco Systems Expiration: March 6th, 2006 September 6th, 2005 File: draft-polk-dhc-uri-00.txt A Dynamic Host Configuration Protocol Option for Requesting and Receiving Uniform Resource Identifiers 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 March 6th, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a new Dynamic Host Configuration Protocol (DHC) Option to allow one or more URIs to be transmitted from a server to a client within one or more messages, and for one or more URIs, each with a unique purpose, to be specifically requested by a client of a server. Included in this Option is a purpose field to identify the type of URI being requested by the client, or the type of URI in the DHCP reply from the server. Polk Expires March 6th, 2006 [Page 1]
Internet-Draft DHC URI Option Sept 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Conventions used in this document . . . . . . . . . . . . 4 1.2 Terms, Acronyms and Definitions . . . . . . . . . . . . . 4 2. DHC Relay Option Format . . . . . . . . . . . . . . . . . . . 5 2.1 Rules of Usage . . . . . . . . . . . . . . . . . . . . . 5 3. Purposes of Different URI Types . . . . . . . . . . . . . . . 6 3.1 Primary SIP/SIPS URI of Public Safety Answering Point . . 7 3.2 Secondary SIP/SIPS URI of Public Safety Answering Point . 7 3.3 Client's Location By-Reference URI . . . . . . . . . . . 7 3.4 SIP/SIPS URI of Emergency Services Gateway (ESGW) . . . . 8 3.5 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP) . 8 3.6 URI of Organization Providing LCI . . . . . . . . . . . . 8 3.7 URI for Geocoding or Reverse Geocoding Function . . . . . 8 3.8 Primary URI for Geo Mapping Service . . . . . . . . . . . 9 3.9 Secondary URI for Geo Mapping Service . . . . . . . . . . 9 3.10 Primary URI for Civic Mapping Service . . . . . . . . . . 9 3.11 Secondary URI for Civic Mapping Service . . . . . . . . . 9 4. Open Items for Discussion . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . 11 8.2 Informative References . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . 12 1. Introduction There are times in which a Uniform Resource Identifier (URI) is an essential part of configuration information necessary for usage by an endpoint (client) for the particular purpose of contacting what is at that URI. This document defines a new Dynamic Host Configuration Protocol (DHC) Option [RFC 2131] to allow URIs of specific types, or purposes, to be requested by a client of a server, and transmitted unrequested from a server to a client. Because URIs can be used for many purposes, and to ensure extensibility, this client option has a sub-option "purpose" field to identify the type of URI included in the message. The motivation of creating the ability to have sub-options within the same DHCP Option here is because there are currently 11 unique URIs described within this document, and each should not take up valuable option number assignments when there is a limited set of DHCP Option values. Therefore this document specifies one DHCP Option for all URIs, allowing up to 255 uniquely identified URIs to be defined as sub-options. This document will IANA Register each purpose URI for interoperability. Polk Expires March 6th, 2006 [Page 2]
Internet-Draft DHC URI Option Sept 2005 This document does not limit the means of an client from gaining knowledge of a URI to DHCP, but provides DHCP as a means for a client to gain knowledge of a URI or series of URIs determined through local configuration, that are considered essential to that client for use by applications within that client. This determination MAY be made at client boot-up, or when a particular application launches. One example of this URI download would be one specifically for the SIP or SIPS URI of the appropriate Public Safety Answer Point (PSAP) for the client when the user of that client calls for emergency help (911 or 112-type of help). This is not a transaction that should take place when a voice application wants to make such a critical call set-up. It is more appropriate that this information be downloaded to the client when the voice (or other) application boots up in case it is needed at a later time. An Internet Access Provider (IAP) would be in a better position to have knowledge of where the client is than an Internet Service Provider (ISP); the latter becoming more divorced from the physical location of the client, especially in the case of the ISP being an Application Service Provider (ASP) on a regional, national or international scale. This was part of the motivation for Option 123 (GeoConf) [RFC 3825]. Examples of IAPs are DSL providers with known endpoints of their cabling infrastructure, Hybrid Fiber Coax (HFC) Cable providers with knowledge of where their logical endpoints are, and small or large enterprise infrastructures. The DSL or HFC Cable provides are not limited in this context to a single client at the subscriber's endpoint, but could have few to many clients being served by an access device of those infrastructures, all with a common need for the particular URI, or series of URIs. A client may request more than one URI be sent to it within the same DHCPDISCOVER or DHCPREQUEST message. Each URI will be inside its own payload container with an Option number, a length field and a purpose field. This means that if more than one URI is being requested or downloaded, there can be more than one DHCP Option XXX (this document's option number) in the same IP message. Each URI will be inside the DHCP Option payload shown in section 2 of this document. There is no meaning to the order of URIs in a message. Section 1.2 reviews the terminology and acronyms used in this document that are fairly new to DHCP. Section 2.1 discusses the rules of usage of this Option. Section 3 lists the unique numbering of the purpose fields to the purpose type that is explained in section 3.1 - 3.11. Section 4 discusses open issues to be addressed. Section 5 is the IANA Considerations section of this DHCP Option as well as the purpose field sub-options. Polk Expires March 6th, 2006 [Page 3]
Internet-Draft DHC URI Option Sept 2005 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 [RFC 2119]. 1.2 Terms, Acronyms and Definitions The following terms and acronyms are used within this document: Civic Mapping - the process a server receiving the civic format location of a client, processing that location to determine the appropriate PSAP for that location, and returning that PSAP URI to the client Emergency Services Gateway - The special IP to circuit-switched gateway that front-ends an emergency services Selective Router (which directs all TDM based 911/112 type calls to the appropriate PSAP) Emergency Services Routing Proxy - a special instance of a SIP Proxy that understands emergency routing to a PSAP based on the location of the caller ESGW - Emergency Services Gateway ESRP - Emergency Services Routing Proxy Geo Mapping - the process a server receiving the geo format location of a client, processing that location to determine the appropriate PSAP for that location, and returning that PSAP URI to the client IAP - Internet Access Provider Internet Access Provider - typically the organization that provides Internet or IP access to the client, and could be the same as the ISP in certain circumstances Internet Service Provider - Provider of advanced services, such as application layer message processing, filtering and routing, and services such as voice/video/instant messaging over IP, and could be the same as the IAP in certain circumstances ISP - Internet Service Provider PSAP - Public Safety Answering Point Public Safety Answering Point - the emergency response call center talking the local emergency calls from people in distress. This facility can be logical, and can transfer (reroute) any request sent to it to another facility deemed more appropriate to receive Polk Expires March 6th, 2006 [Page 4]
Internet-Draft DHC URI Option Sept 2005 the request. 2. DHC Relay Option Format The format for this Option 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 | URI Purpose | URI + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URI (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URI (cont'd to a maximum of 254 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code = The IANA Assigned Option number Length = This is a variable length value of the number of bytes in the Option, including this length field URI Purpose = This is what the URI is used for by applications within the client URI = This is a variable length field containing the URI being transmitted, to a maximum of 254 bytes in length This URI may be a partial URI, with concatenation- required if multiple Option XXXs are present in the same message with the same purpose value; see the rules section below. 2.1 Rules of Usage The following are the rules of usage of this DHCP Option: - Each URI requested for by a client, or transmitted by the server, MUST have a purpose identifier indicating the intended usage for this URI by applications within the client - there MAY be more than one URI requested by the client in the same message - If more than one URI is requested for by the client, or transmitted by the server, each MUST be in separate Option fields (i.e. there is no provision for multiple URIs within the same Option as there is no length field for an individual URI) - The certain URI fields MAY be populated with a URL of a server Polk Expires March 6th, 2006 [Page 5]
Internet-Draft DHC URI Option Sept 2005 - Purpose=6 "URI of Organization Providing Location Configuration Information" SHOULD be included when Option 123 (GeoConf) or the Option for [ID-CIVIC] is downloaded to the client. - URIs that denote public identifiers, such as for a PSAP, are not as much at risk as other URIs transmitted to the client. That said, URIs with specific information of the client, such as its location by-reference URI SHOULD NOT be transmitted by the server without being requested by the client first, and SHOULD only be requested by the client once it learns the specific IP address of the server. In keeping with established rules of option lengths [RFC2131], the length of a single option containing one URI MUST NOT exceed 255 bytes, unless following the rules established in [RFC3396] for "concatenation-required" values, which states clearly that if the same option appears more than once in the same message, to consider that a split option value, to be concatenated prior to processing at the receiving end. This document provides a unique, therefore modified, usage of this rule in DHCP, in which the literal meaning of [RFC3396] does not apply, as this Option has sub-options (called 'purposes' here). However, this [RFC3396] rule is modified here to state that: - if the same purpose field value appears in the same message more than once, the receiving entity MUST concatenate the URI values prior to processing as a single value. This procedure MUST only to be done when the URI value is longer than 255 bytes (per the rules of [RFC2131] and [RFC3396]), therefore MUST NOT be done otherwise. The rest of [RFC3396] applies as written, as long as the reader adjusts their understanding of that RFC to mean the purpose field in this document, and not the Option field. - multiple instances of this Option XXX in the same message with different purpose values MUST NOT be considered for [RFC3396] concatenation. 3. Purposes of Different URI Types This section lists the initial set of purpose fields which can be used by a client for different requests, or a server for different transmissions: Purpose = 1 (Primary PSAP URI) Purpose = 2 (Secondary PSAP URI) Purpose = 3 (Location By-Reference of Client) Purpose = 4 (ESGW URI of Client) Purpose = 5 (ESRP URI of Client) Polk Expires March 6th, 2006 [Page 6]
Internet-Draft DHC URI Option Sept 2005 Purpose = 6 (Location Providing Location for Client) Purpose = 7 (URI of Geocoding/Reverse Geocoding) Purpose = 8 (Primary URI of Geo Mapping Service) Purpose = 9 (Secondary URI of Geo Mapping Service) Purpose = 10 (Primary URI of Civic Mapping Service) Purpose = 11 (Secondary URI of Civic Mapping Service) Others can be added based on discussion of this document. 3.1 Primary SIP/SIPS URI of Public Safety Answering Point (PSAP) This purpose=1 URI is the primary URI used by a SIP [RFC3261] enabled element in the Request-URI field for the appropriate PSAP for this client when the SIP user agent (UA) is attempting to call for emergency help (such as the police or ambulance). 3.2 Secondary SIP/SIPS URI of Public Safety Answering Point (PSAP) Related to Purpose=1. This purpose=2 URI is the secondary or backup SIP or SIPS URI of same PSAP facility or of another PSAP facility to be used when the primary URI fails to connect, due to a timeout or a SIP final failure message. This SHOULD NOT be used if the initial attempt to contact the PSAP fails for any reason, as many failures are recoverable within SIP [RFC 3261]. In fact, many non-successful responses are not uncommon in SIP before a transaction is successfully responded to. 3.3 Client's Location By-Reference URI This purpose=3 URI is the pointer to the client's by-reference location on a server external to the client [ID-SIP-LOC]. Location of a client can be signified in two ways: by-value - meaning the client possesses its location information locally, and by-reference - meaning the client's location information is stored on a remote element such as a server. Storing location information by-reference external to the client may be for many reasons, including because the client does not know how to store its location, because the client chooses to store it remotely for a URI reference to be given to others to save bandwidth during transmission, or because a service provider may decide to keep this information from the client by-value. If the client knows where its location is by-reference, it merely needs to provide that reference to another entity when it decides to reveal where it is. This URI is the retrieval identifier for a protocol to fetch the client's location from. Examples of usable protocols are: HTTP, Polk Expires March 6th, 2006 [Page 7]
Internet-Draft DHC URI Option Sept 2005 SIP, etc. 3.4 SIP/SIPS URI of Emergency Services Gateway (ESGW) This purpose=4 URI is for the Emergency Services Gateway that an IP client would contact when setting up an emergency call with a PSAP that is not IP enabled. Having this information locally in the client will allow it to contact the ESGW directly and not have to rely on an intermediary to determine which ESGW is the right one for this client, and possibly fail the call set-up during that determination. 3.5 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP) This purpose=5 URI is for the Emergency Services Routing Proxy that is tasked with determining which PSAP the client needs to contact when attempting to establish a call with a PSAP. In SIP for example, not all SIP Proxies or intermediaries are expected to have knowledge of how to determine which is the appropriate PSAP of a client based on where the client is located. There may be difficult in a non-updated SIP intermediary in this determination, even in determining which SIP intermediary knows how to do this function. This SIP/SIPS URI is the Request-URI of such a SIP intermediary that knows how to determine which is the correct PSAP given the included PIDF-LO [ID-SIP-LOC] in the session set-up message (the SIP INVITE) to that intermediary. 3.6 URI of Organization Providing Location Configuration Information This purpose=6 URI is the organization that provided location configuration information (LCI) to the DHCP client. In building a proper XML Location Message Body [ID-PIDF-LO], the location generator [RFC 3693] will include a <provided-by> element indicating which organization was responsible for delivering this location information to the client. This URI is used to populate this <provided-by> element without further interaction. 3.7 URI for Geocoding or Reverse Geocoding Function This purpose=7 URI of a server that can perform a geocoding or reverse geocoding function. DHCP has the ability to provide Location Configuration Information to a client in the geo format using Option 123 [RFC 3825] or the civic format [ID-CIVIC], or the client can learn is location through manual configuration or an internal GPS process. Various applications on a client MAY prefer one format over another and not possess the ability to geocode or reverse geocode the available location information. This URI (purpose=7) provides the client with the server known to have this Polk Expires March 6th, 2006 [Page 8]
Internet-Draft DHC URI Option Sept 2005 ability prior to the client requiring the new format. 3.8 Primary URI for Geo Mapping Service This purpose=8 URI gives the client the ability to transmit its location, perhaps downloaded from DHCP Option 123 [RFC3825], and contact a "primary" server at this URI to perform a location-to- PSAP-URI mapping function before the client attempts to contact a PSAP. This transmission of client location to the primary mapping server that includes the request to map this location to the appropriate PSAP for that location is done with another protocol, and not DHCP. 3.9 Secondary URI for Geo Mapping Service This purpose=9 URI gives the client the ability to transmit its location, perhaps downloaded from DHCP Option 123 [RFC3825], and contact a "secondary" server at this URI to perform a location-to- PSAP-URI mapping function before the client attempts to contact a PSAP. This transmission of client location to the secondary mapping server that includes the request to map this location to the appropriate PSAP for that location is done with another protocol, and not DHCP. 3.10 Primary URI for Civic Mapping Service This purpose=10 URI gives the client the ability to transmit its location, perhaps downloaded from the civic format DHCP Option [ID- CIVIC], and contact a "primary" server at this URI to perform a location-to-PSAP-URI mapping function before the client attempts to contact a PSAP. This transmission of client location to the primary mapping server that includes the request to map this location to the appropriate PSAP for that location is done with another protocol, and not DHCP. 3.11 Secondary URI for Civic Mapping Service This purpose=11 URI gives the client the ability to transmit its location, perhaps downloaded from the civic format DHCP Option [ID- CIVIC], and contact a "secondary" server at this URI to perform a location-to-PSAP-URI mapping function before the client attempts to contact a PSAP. This transmission of client location to the secondary mapping server that includes the request to map this location to the appropriate Polk Expires March 6th, 2006 [Page 9]
Internet-Draft DHC URI Option Sept 2005 PSAP for that location is done with another protocol, and not DHCP. 4. Open Items for Discussion There are several open items that need to be addressed in following versions of this ID (if it moves forward). #1 - Does Purpose=5 (URI of the ESRP) need to be pulled into two separate URIs, one for a Routing Proxy that knows geo format mapping, and the other that knows civic format mapping? This may be too granular at this point. 5. IANA Considerations IANA has assigned a DHCP option code of [XXX] for the URI option defined in this document. This URI Option defines one field for which IANA maintains a registry: the Purpose field (see Section 2). The initial values of the Purpose registry are as follows: Purpose Description Reference ------- ------------ --------- 1 Primary PSAP URI [This RFC] 2 Secondary PSAP URI [This RFC] 3 Location By-Reference of Client [This RFC] 4 ESGW URI of Client [This RFC] 5 ESRP URI of Client [This RFC] 6 Location Providing Location for Client [This RFC] 7 URI of Geocoding/Reverse Geocoding [This RFC] 8 Primary URI of Geo Mapping Service [This RFC] 9 Secondary URI of Geo Mapping Service [This RFC] 10 Primary URI of Civic Mapping Service [This RFC] 11 Secondary URI of Civic Mapping Service [This RFC] IANA registration of new purpose field values MUST be done in a standards track RFC. 6. Security Considerations Where critical decisions might be based on the value of this 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 client and destination DHCP server to capture any URIs in transit. Polk Expires March 6th, 2006 [Page 10]
Internet-Draft DHC URI Option Sept 2005 When implementing a DHC server that will serve clients across an uncontrolled network, one should consider the potential security risks. 7. Acknowledgements To Andy Newton and Ralph Droms for guidance and assistance in the shaping of this effort. To Josh Littlefield for his help. 8. References 8.1 Normative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [ID-PIDF-LO] J. Peterson, "Presence Information Data Format - Location Object", draft-ietf-Geopriv-pidf-lo-03, "work in progress", Sept 2004 8.2 Informative References [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf- sip-location-conveyance-01.txt, "work in progress", June 2005 Polk Expires March 6th, 2006 [Page 11]
Internet-Draft DHC URI Option Sept 2005 [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", draft-ietf-geopriv-dhcp-civil-06, "work in progress", May 2005 Author's Address James M. Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Fax: none Email: jmpolk@cisco.com Intellectual Property Statement 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. Disclaimer of Validity 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 Polk Expires March 6th, 2006 [Page 12]
Internet-Draft DHC URI Option Sept 2005 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Polk Expires March 6th, 2006 [Page 13]