DHC Working Group James Polk Internet Draft Cisco Systems Expiration: Sept 6th, 2006 March 6th, 2006 File: draft-polk-dhc-uri-03.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 Sept 6th, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 message from the server. Polk Expires Sept, 2006 [Page 1]
Internet-Draft DHC URI Option March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Conventions used in this document . . . . . . . . . . . . 4 1.2 Terms, Acronyms and Definitions . . . . . . . . . . . . . 4 1.3 What Changed from Previous Versions . . . . . . . . . . . 5 2. DHC Relay Option Format . . . . . . . . . . . . . . . . . . . 6 2.1 Rules of Usage . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Multiple URIs in a message . . . . . . . . . . . . . . . . 8 2.3 Requesting a URI of a Server . . . . . . . . . . . . . . . 9 3. Purposes of Different URI Types . . . . . . . . . . . . . . . 9 3.1 Primary SIP/SIPS URI of Public Safety Answering Point . . 10 3.2 Secondary SIP/SIPS URI of Public Safety Answering Point . 10 3.3 Client's Location By-Reference URI . . . . . . . . . . . . 10 3.4 SIP/SIPS URI of Emergency Services Gateway (ESGW) . . . . 10 3.5 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP) . 11 3.6 URI of Organization Providing LCI . . . . . . . . . . . . 11 3.7 URI for Geocoding or Reverse Geocoding Function . . . . . 12 3.8 Primary URI for Geo Mapping Service . . . . . . . . . . . 12 3.9 Secondary URI for Geo Mapping Service . . . . . . . . . . 12 3.10 Primary URI for Civic Mapping Service . . . . . . . . . . 12 3.11 Secondary URI for Civic Mapping Service . . . . . . . . . 13 4. Open Items for Discussion . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Operational Considerations . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1 Normative References . . . . . . . . . . . . . . . . . . 15 9.2 Informative References . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . 16 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 an Option. This document specifies one DHCP Option for all URIs, allowing up to 255 uniquely identified types of URIs to be defined as sub-options. The format for this comes from [RFC3396]. This document will IANA Register each type of URI for interoperability. Polk Expires Sept, 2006 [Page 2]
Internet-Draft DHC URI Option March 2006 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 for use by applications within that client. The decision of when one or more URIs are essential can be made at client boot-up, or when a particular application launches. One example of this URI download could be one specifically for the SIP(S) URI of the appropriate Public Safety Answer Point (PSAP) for the client when the user calls for emergency help (911 or 112- type of help). Emergency calling is highly localized in nature, and requires knowledge of where the caller is. DHCP in [RFC3825] already provides this level of knowledge to a client, and can, at the same time, perhaps in the same packet, provide that client with its emergency SIP(S) URI. For additional context, see [ID-MAPPING] for where this DHCP Option can fit into the larger architecture of an emergency services infrastructure. Examples of Link Providers 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 providers are not limited in this context to a single client at the subscriber's endpoint, but could have a 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 small business with a single connection is an example of this. It could be the case what all devices within this small office could need the same URIs to access the same services. 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 within the DHCP URI Option, with a purpose field indicating what type of URI it is. This means that more than one URI can be requested or downloaded in 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 order to the URIs in a message. Awareness of how stale a URI may become is something local administrators should consider when implementing this Option. For this particular Option, DHCP servers are assumed to periodically query an authoritative source providing non-stale or updated URIs. How this is accomplished is out of scope for this document. 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 Polk Expires Sept, 2006 [Page 3]
Internet-Draft DHC URI Option March 2006 addressed. Section 5 is the IANA Considerations section of this DHCP Option as well as the purpose field sub-options. Section 6 adds an Operational Considerations section that was brought up during the last IETF meeting. 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: Application Provider - A Service Provider that has a measure of control over an application the client uses. An organization that does voice as an application is one example. 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 Internet Attachment Provider - Provides layer 3 connectivity to the Internet to a client directly, or indirectly through another organization such as an Enterprise network Link Provider - Provides the MAC layer communications link to the client PSAP - Public Safety Answering Point Polk Expires Sept, 2006 [Page 4]
Internet-Draft DHC URI Option March 2006 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 the request. 1.3 What Changed from Previous Versions This is a list of the changes between versions of this document. From the individual -02 version to the individual -03 version there were the following changes: - offered an external applicability statement for URI purpose=1, a PSAP-URI, in [ID-MAPPING]. - clarified how concatenation functions according to RFC 3396 - Added an Operational Considerations Section (6) as was asked for in Vancouver. - rearranged the URI purposes into one group dealing with emergency services and another dealing with location. - subtle modifications to text here and there From the individual -01 version to the individual -02 version there were the following changes: - clarified some acronyms and definitions - clarified how RFC 3396 and concatenation can be used - allowing back in some of what was taken out in the -01 version From the individual -00 version to the individual -01 version there were the following changes: - added a second URI to the main bit format Figure (1) - Added several requirements - Deleted several rules surrounding how to get around RFC3396, which is no longer necessary - brought this document in line with RFC3396, including the sub- option length parameter per URI - removed the ability to concatenate fields - modified the doc to limit the size of a URI to 253 bytes max Polk Expires Sept, 2006 [Page 5]
Internet-Draft DHC URI Option March 2006 - Added a section on how multiple URIs are derived - Added a section on how a client requests one or more URIs - Edited terms to be more consistent with the ECRIT Reqs ID - Added new concerns to the Security Considerations 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 length + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URI (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URI (cont'd to a maximum of 253 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +>| URI Purpose #2| URI length | URI #2 + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | URI (cont'd) + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | URI (cont'd to a maximum of 253 bytes minus URIs above) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +--(This is a second instance of a URI that MAY be in the message;) (See the section 2.2) Figure 1. The URI Option Format Code = The IANA Assigned Option number Length = one octet providing a variable length value of the number of bytes in the Option, including this length field URI Purpose = one octet providing the URI type in this sub-option to be used by applications within the client URI Length = one octet providing the length of the URI associated with a particular purpose, whether or not there are any other URIs in the message URI = This is a variable length field containing the URI being transmitted, to a maximum of 253 bytes in length Polk Expires Sept, 2006 [Page 6]
Internet-Draft DHC URI Option March 2006 2.1 Rules of Usage The following are the rules of usage of this DHCP Option: - Each DHCP Option compliant with this document will have the same Option number - The Length field is for the overall length of the Option (there are individual URI length fields per purpose) - 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 unsolicited, each MUST be in separate "purpose" subsection of the message - Each purpose sub-option will have its own URI Length field for that URI only - No URI Length field will be more than 253 (bytes), complying with [RFC2131] - Clients MUST be prepared to support [RFC3396] for multiple URIs - [RFC2131] limits the size of any one Option to 255 bytes, and allows for a DHCP message to be at least 576 bytes. Therefore, if the aggregate byte count of all URIs (plus purpose and length bytes) is greater than 255 bytes, RFC 3396 rules apply here in which there would be more than one instance of this DHCP Option in the same message and each DHCP message would be concatenated into a single message prior to processing. In this case, as [RFC 3396] states, there can be more total bytes of this one Option than the 255 byte limit. Section 2.2 provides an example of this. [RFC3396 clearly states that the end of a fragmented option can be at a place other than the end of a URI here, because the whole DHCP option is concatenated prior to processing by the recipient. - If consecutive DHCP messages have this Option, and these messages contain another instance of a particular purpose identifier, each instance is to be considered a replacement for what has been received already by the client. - Clients making a request for one or more URIs will send a message to the Server with URI length fields set to zero - Clients MUST NOT request the same purpose more than once in the Polk Expires Sept, 2006 [Page 7]
Internet-Draft DHC URI Option March 2006 same message, but are not limited in how frequently they can make new requests - even for the same URI purpose - If a server receives more than one request for a particular instance of URI in separate packets, each is to be considered a separate request and processed and transmitted back towards the client, barring local policy preventing such a retransmission. - Server responses to a request for more than one URI MAY be in separate messages (i.e. one URI per message), at the server's discretion - Certain URI fields MAY be populated with a URL of a server - Purpose=6 "URI of Organization Providing Location Configuration Information" SHOULD be included when Option 123 (GeoConf) or the Option for [ID-CIVIC] is requested of a server, when 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. 2.2 Multiple URIs in a message There MAY be one URI in the message. However, because some URIs can be fairly short, there MAY be more than one URI in the message - requiring a means to know when one stops and the other one starts. The code field is the same in either case. The Option length field is overall message length in bytes, minus the Option number byte and the Option Length byte. The next byte is a URI purpose byte, followed by a URI Length byte. If this length value is not one byte less than the Option Length value, the DHCP entity knows there is more than one URI in this message. This first URI Length field determines the exact number of bytes in this first URI. The next byte after this field is the purpose byte of the next URI, followed by its URI length field. If the addition of these two URI length fields is not two bytes less than the Option Length field value, the DHCP entity knows there is at least one more URI in this message. This process continues until the byte counts match, or they do not - which means there is an length error. Here is the conceptual format of such a message (where XXX is this Option) that is 253 bytes or less in aggregate length: [code=XXX] [length] [purpose] [uri length] [uri text] [purpose] [uri length] [uri text] [purpose] [uri length] [uri text] [etc] Polk Expires Sept, 2006 [Page 8]
Internet-Draft DHC URI Option March 2006 If the aggregate of the URIs are more than 255 bytes, this would be a conceptual format for a message (where XXX is this Option): [code=XXX] [length] [purpose] [uri length] [uri text] [purpose] [uri length] [uri text] [code=XXX] [length] [purpose] [uri length] [uri text] [purpose] [uri length] [uri text] [purpose] [uri length] [uri text] [etc] The above is a clean version of complete URIs into separate blocks of 255 bytes. [RFC3396] states this is not necessary, as the recipient will concatenate consecutive option blocks prior to processing for maximum efficiency. 2.3 Requesting a URI of a Server Clients can request one or more URIs of a server. Here is the pseudo-format of such a request: [code] [length] [purpose] [uri length=0] [purpose] [uri Length=0] [purpose] [uri length=0] [etc...] The client builds a proper message and zeros out the uri-length fields and does not include anything in the uri fields. There is no limit to the number of URIs a client can request - except: - the Option maximum length is 253 bytes, - the same URI purpose cannot be in a message more than once, and - there is a limit on the number of available purposes to include. Conceivably though, each available URI purpose MAY be in a DHC request message. The client MUST be prepared to receive each URI requested, even in separate messages from the server. The client MUST NOT request the same URI purpose more than once in the same message. 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 URI of Client) Purpose = 4 (ESGW URI of Client) Purpose = 5 (ESRP URI of Client) Purpose = 6 (Organization Providing Location for Client) Polk Expires Sept, 2006 [Page 9]
Internet-Draft DHC URI Option March 2006 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). In many cases, the SIP(S)-URI for the ESRP (purpose=4) will be considered the same as the SIP(S)-URI for the PSAP (purpose=1). The client will not know the difference. Why this is not different to the client is because the ESRP should be the edge boundary of an emergency services network that will be able to do its own processing and message routing to the appropriate PSAP. The goal in these cases was just to get the session set-up message to this stage. 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 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.4 SIP/SIPS URI of Emergency Services Routing Proxy (ESRP) This purpose=5 URI is for the Emergency Services Routing Proxy that Polk Expires Sept, 2006 [Page 10]
Internet-Draft DHC URI Option March 2006 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. In many cases, the SIP(S)-URI for the ESRP (purpose=4) will be considered the same as the SIP(S)-URI for the PSAP (purpose=1). The client will not know the difference. Why this is not different to the client is because the ESRP should be the edge boundary of an emergency services network that will be able to do its own processing and message routing to the appropriate PSAP. The goal in these cases was just to get the session set-up message to this stage. 3.5 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, SIP, etc. 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 [RFC4119], the location Polk Expires Sept, 2006 [Page 11]
Internet-Draft DHC URI Option March 2006 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 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 Polk Expires Sept, 2006 [Page 12]
Internet-Draft DHC URI Option March 2006 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 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 - A proposal: to answer Stig's open question during the Vancouver meeting about "not just having an open ended Option in DHCP". These URIs in this ID are in two groups, Location and Emergency services. Should this effort call for two Options to be created, each with a specific topic of coverage? #2 - whether or not to include more applicability statements in this doc, or to merely reference them - and - how this would change if the proposal above is agreed to? #3 - The author needs help understanding the nuances of unsolicited DHCP messaging to the client. 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] Polk Expires Sept, 2006 [Page 13]
Internet-Draft DHC URI Option March 2006 3 ESGW URI of Client [This RFC] 4 ESRP URI of Client [This RFC] 5 Location By-Reference URI of Client [This RFC] 6 Organization 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. Operational Considerations The types of URIs called for within this document can be divided up into two technology areas: location related (nearest the Geopriv WG activities) and emergency services related (nearest the ECRIT WG activities). Each of the URI groups are here to provide information to a client from the access provider, due to their relationship with the client - through an implicit or explicit contract for connectivity. Each of these two groups of URIs are best served by a service domain that understands the location of the client, or has implicit knowledge of roughly where the client is from their connection to the provider. Supporting an emergency services network means critical information is right the first time. What is not envisioned here is that DHCP would be the primary means of message routing an emergency call set-up, for example a SIP INVITE message to the appropriate PSAP. DHCP is envisioned to mostly be the backup mechanism, in case the primary mechanism fails. No one hopes the primary means fails, but it will on occasion. It is possible that in small cases, DHCP is considered the best means for a client to learn this information. This places a burden on the DHCP administrators for valid information during device boot-times. Operational considerations for a location service is something DHCP already has agreed to with the support of RFC 3825 [RFC3825] and the Civic Location ID [ID-CIVIC]. [NOTE - the author is open to text being sent to modify the above, or to be added to help with this section] 7. 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. Polk Expires Sept, 2006 [Page 14]
Internet-Draft DHC URI Option March 2006 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. When implementing a DHC server that will serve clients across an uncontrolled network, one should consider the potential security risks. There is a risk of old information being provided by this Option. Although many wish the Internet to be truly dynamic in its updates to topology changes (for whatever reason), this does not always happen as planned. Careful consideration needs to be taken in this Option to have some way of leaving a trail of breadcrumbs to find where a problem is related to this Option. URI Option #6 could become a more universal Option in this regard to provide who it was that provided a certain critical piece of information that ended up needing an update. 8. Acknowledgements To Andy Newton and Ralph Droms for guidance and assistance in the shaping of this effort. To Josh Littlefield for his help. To Ted Lemon and Andre Kostur for their constructive comments. 9. References 9.1 Normative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002 [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. [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 Polk Expires Sept, 2006 [Page 15]
Internet-Draft DHC URI Option March 2006 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2006 9.2 Informative References [ID-MAPPING] J. Polk, " Analyzing ECRIT Mapping of a Location to an Emergency URI for Emergency Calling", draft-polk-ecrit-mapping-events-00.txt, "work in progress", February 2006 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf- sip-location-conveyance-02.txt, "work in progress", March 2006 [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", draft-ietf-geopriv-dhcp-civil-09, "work in progress", January 2006 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 Polk Expires Sept, 2006 [Page 16]
Internet-Draft DHC URI Option March 2006 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 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). 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 Sept, 2006 [Page 17]