Internet DRAFT - draft-polk-ecrit-dhc-emergency-dialstring-option
draft-polk-ecrit-dhc-emergency-dialstring-option
Network Working Group James Polk
Internet-Draft Cisco Systems
Expires: Dec 19th, 2006 Brian Rosen
NeuStar
June 19th, 2006
A Dynamic Host Configuration Protocol Option for the
Locally Significant Emergency Calling Dialstring
draft-polk-ecrit-dhc-emergency-dialstring-option-00
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 December 19th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines a new Dynamic Host Configuration Protocol
Option for a client to be able to request its locally significant
emergency dialstring from the local infrastructure.
Polk & Rosen Expires December, 2006 [Page 1]
Internet-Draft Emergency Dialstring from DHC June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions Used in This Document . . . . . . . . . . . . 3
2. DHC Emergency Dialstring Option Format . . . . . . . . . . . 3
2.1 Rules of Usage of This Option . . . . . . . . . . . . . . 3
3. Open Questions Remaining . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1 Normative References . . . . . . . . . . . . . . . . . 5
Author Information . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . 6
1. Introduction
[ID-SOS] describes a universal emergency call URN to be used to
identify a call as an emergency call. This URN is not intended to
be dialed, but rather is to be used by the User Agent as an address.
The intention is to translate (as with any other dial plan) the
existing emergency dialstring to a URI that can be routed over the
Internet, or some subset thereof, to an appropriate Public Safety
Answering Point (PSAP) for the calling device.
In many countries, short codes are used as emergency dialstrings to
identify emergency calls. In others, a complete local telephone
number is needed. These dialstrings are locally specific, typically
by country, and may vary in length. In some countries, a single
dialstring is used ('999' is the dialstring for all emergency calls
in the United Kingdom). In other countries, there are different
dialstrings for different emergency services; '116' is the
dialstring for police in Switzerland, '117' is the dialstring for
fire.
Users are taught, often from a very early age, what the local
Dialstring(s) for emergency calls are, and it is not practical to
attempt to change the dialstring to a more uniform choice. When
using systems that permit roaming, local laws often require that
telephony systems recognize the local, or "visited", emergency
dialstring.
What is needed is a mechanism for a user agent (or other device that
can place emergency calls) to learn the local emergency
dialstring(s) so that a user agent can recognize an emergency call
when that numeric sequence is dialed by the user. This visited
emergency dialstring(s) may be displayed to the user on its screen
when learned by the device, if the phone has that capability.
This document defines a new Dynamic Host Configuration Protocol
Option [RFC2131] for a client to be able to request its locally
Polk & Rosen Expires December, 2006 [Page 2]
Internet-Draft Emergency Dialstring from DHC June 2006
significant emergency dialstring(s) from the local infrastructure.
The previous version of this ID was
draft-polk-dhc-emergency-dialstring-option-00
The chairs of the two affected WGs concluded this topic should be
discussed in ECRIT, where the subject matter is closest, while DHC
will enforce compliance with DHC format rules.
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 [RFC2119].
2. DHC Emergency Dialstring 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 | Country Code +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID | Dialstring Digits +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dialstring Digits (cont'd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The Emergency Dialstring Option Format
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.
Country Code = The two octet ISO country code.
Service Identifier = the one octet indication of type of dialstring
Dialstring = This is emergency dialstring digits, one per byte, to
a maximum of 16 digits. This is variable in length
based on the number of digits in the dialstring.
2.1 Rules of Usage of This Option
The following are the rules of usage of this DHCP Option:
Polk & Rosen Expires December, 2006 [Page 3]
Internet-Draft Emergency Dialstring from DHC June 2006
- this option can be part of a message with other options, or it can
be the only option in the message.
- the maximum number of base10 digits is 16, to correspond with the
maximum known size of a dialstring in the circuit world.
- the minimum option length is 5 - for when only a country code is
sent.
- the minimum option length with a single digit emergency dialstring
present is 6.
- the country code and Service ID fields can be empty (null) in any
message, but are not deleted for any reason in this Option
- if the length field is 6, and the dialstring field value is
0x00000000, this means the base10 digit is '0', and should not be
considered an empty field
- if there is an emergency dialstring in the option, even if the
value is '0', a Service ID field left empty is equivalent to a
value of 0x00000000 or the general emergency service type of
urn:service:sos (i.e. not police-only, or fire-only).
- The maximum hex value for any one byte of dialstring value is
0x00001001
- A client requesting this option be returned from a server would
Accomplish this by sending this option in a DISCOVER, REQUEST or
INFORM message with a length field of 5, emulating a NULL
dialstring field value.
- If a request with a null country code is made to a DHCP server
which implements the [RFC3825] or [ID-CIVIC] options, and the
server can determine the location it returns or would have
returned for those options, then it MUST return the dialstrings
for the country for that location.
- If a request with a null country code is made to a DHCP server
which does not support [RFC3825] or [ID-CIVIC] or the server
cannot determine the location it returns or would have returned,
but it CAN unambiguously determine which country the requestor is
located in (perhaps because it only serves one country, or it can
determine based on the request and its knowledge of the network
topography and geography that it could only be in one country),
then it MUST return the dialstrings for that country.
- If a request with a null country code is made to a DHCP server
where neither of the above two conditions are met, the DHCP server
MUST return dialstrings for all countries the geography of the
local network covers.
Polk & Rosen Expires December, 2006 [Page 4]
Internet-Draft Emergency Dialstring from DHC June 2006
- It is RECOMMENDED this request be in a REQUEST or INFORM message,
in which case the message is unicast to the server.
3. Open Questions Remaining
The following open questions are left to be answered based on
feedback during the review of this document:
- No open technical questions remain at this time
4. IANA Considerations
IANA has assigned a DHCP option code of [XXX] for the Emergency
Dialstring option defined in this document.
5. Security Considerations
Where critical decisions might be based on the value of this
emergency dialstring 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 emergency dialstrings in
transit. While learning a publicly known emergency dialstring is
not a security risk, having that information altered in transit is a
security risk.
When implementing a DHC server that will serve clients across an
uncontrolled network, one should consider the potential security
risks.
6. Acknowledgements
To Jean-Francois Mule for his support of this effort.
7. References
7.1 Normative References
[ID-SOS] H. Schulzrinne, "A Uniform Resource Name (URN) for
Services", draft-ietf-ecrit-service-urn-03, "work in
progress", May 2006
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
Polk & Rosen Expires December, 2006 [Page 5]
Internet-Draft Emergency Dialstring from DHC June 2006
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[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
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
Author's Address
James Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Email: jmpolk@cisco.com
Brian Rosen
470 Conrad Dr.
Mars, PA 16046
US
Phone: +1 724 382 1051
Email: br@brianrosen.net
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
Polk & Rosen Expires December, 2006 [Page 6]
Internet-Draft Emergency Dialstring from DHC June 2006
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
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 provided by the IETF
Administrative Support Activity (IASA).
Polk & Rosen Expires December, 2006 [Page 7]
