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]