ECRIT Working Group James Polk Internet-Draft Cisco Systems Expires: Aug 27th, 2006 Brian Rosen NeuStar Feb 27th, 2006 A Dynamic Host Configuration Protocol Option for the Locally Significant Emergency Calling Dialstring draft-polk-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 August 27th, 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 August 25th, 2006 [Page 1] Internet-Draft Emergency Dialstring from DHC Feb 2006 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 the universal URN. 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 dialstrings 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 ("visited") emergency dialstrings. 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 it 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 in its screen when learned, 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 significant emergency dialstring(s) from the local infrastructure. 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]. Polk & Rosen Expires August 25th, 2006 [Page 2] Internet-Draft Emergency Dialstring from DHC Feb 2006 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: - 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, - 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 Polk & Rosen Expires August 25th, 2006 [Page 3] Internet-Draft Emergency Dialstring from DHC Feb 2006 - 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 be accomplished 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. - It is RECOMMENDED this request be in a REQUEST or INFORM message, in which case the message is unicast to the server - it is currently not envisioned why a non-empty option would be sent from a client to server. 3. Open Questions The following open questions are left to be answered based on feedback during the review of this document: - Using octets for dialable numbers with a maximum range of 16 is a waste of space. It would be possible to use a more compact form of representation, from a long integer to three hex digits per octet. Polk & Rosen Expires August 25th, 2006 [Page 4] Internet-Draft Emergency Dialstring from DHC Feb 2006 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 Your name here... 7. References 7.1 Normative References [ID-SOS] H. Schulzrinne, "A Uniform Resource Name (URN) for Services", draft-ietf-ecrit-service-urn-00, "work in progress", January 2006 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [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 Polk & Rosen Expires August 25th, 2006 [Page 5] Internet-Draft Emergency Dialstring from DHC Feb 2006 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. Author's Address James M. 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 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 Polk & Rosen Expires August 25th, 2006 [Page 6] Internet-Draft Emergency Dialstring from DHC Feb 2006 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 & Rosen Expires August 25th, 2006 [Page 7]