One document matched: draft-polk-dhc-uri-03.txt
Differences from draft-polk-dhc-uri-02.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-21 10:52:18 |