[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]