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]