[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-haberler-carrier-enum) 00 01 02 03 04 05 06 07 08 09 RFC 5527

ENUM -- Telephone Number Mapping                             M. Haberler
Working Group                                                        IPA
Internet-Draft                                                R. Stastny
Intended status: Informational                                     Oefeg
Expires: December 15, 2007                                 June 13, 2007


      Combined User and Infrastructure ENUM in the e164.arpa tree
                      draft-ietf-enum-combined-05

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 15, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This memo defines an interim solution for Infrastructure ENUM to
   allow a combined User and Infrastructure ENUM implementation in
   e164.arpa as a national choice until the long-term solution is
   approved.  This interim solution will be deprecated after approval of
   the long-term solution.





Haberler & Stastny      Expires December 15, 2007               [Page 1]

Internet-Draft    Combined User and Infrastructure ENUM        June 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  Interim Solution . . . . . . . . . . . . . . . . . . . . . . .  3

   4.  Leveraging the e164.arpa infrastructure  . . . . . . . . . . .  4

   5.  Locating the Infrastructure ENUM Branch  . . . . . . . . . . .  4

   6.  Position of the IEBL Record  . . . . . . . . . . . . . . . . .  5

   7.  Recommended resolver behaviour . . . . . . . . . . . . . . . .  6

   8.  Security considerations  . . . . . . . . . . . . . . . . . . .  7

   9.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  8

   10. Interoperability considerations  . . . . . . . . . . . . . . .  8

   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9

   12. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     12.1.  Normative References  . . . . . . . . . . . . . . . . . .  9
     12.2.  Informative References  . . . . . . . . . . . . . . . . .  9

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11





















Haberler & Stastny      Expires December 15, 2007               [Page 2]

Internet-Draft    Combined User and Infrastructure ENUM        June 2007


1.  Introduction

   ENUM (E.164 Number Mapping, RFC 3761 [2]) is a system that transforms
   E.164 numbers [3] into domain names and then uses DNS (Domain Name
   Service) [6] services like delegation through Name Server (NS)
   records and NAPTR (Naming Authority Pointer) records [4] to look up
   which services are available for a specific domain name.

   ENUM as defined in RFC 3761 (User-ENUM) is not well suited for the
   purpose of interconnection by carriers and voice service providers,
   as can be seen by the use of various private tree arrangements based
   on ENUM mechanisms.

   Infrastructure ENUM is defined as the use of the technology in RFC
   3761 [2] by the carrier-of-record [8] (Voice service provider) for a
   specific E.164 number [3] to map a telephone number into one or more
   Uniform Resource Identifiers (URIs) [5].

   These URIs will be used to derive specific points of interconnection
   into the service provider's network that could enable the originating
   party to establish communication with the associated terminating
   party.  These URIs are separate from any URIs that the end-user who
   registers his E.164 number in ENUM may wish to associate with that
   E.164 number.

   The requirements, terms and definitions for Infrastructure ENUM are
   defined in [8].

   Using the same E.164 number to domain mapping techniques for other
   applications under a different, internationally agreed apex (instead
   of e164.arpa) is straightforward on the technical side.  Establishing
   the international agreements necessary to delegate the country-code
   level subdomains under the new apex is non-trivial and time-
   consuming.  This process of defining the Dynamic Delegation Discovery
   System (DDDS) [4] application for Infrastructure ENUM is work in
   progress [9].  This is called the long term solution.


2.  Terminology

   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 BCP 14, RFC 2119 [1].


3.  Interim Solution

   As stated above, the agreements to establish the long-term solution



Haberler & Stastny      Expires December 15, 2007               [Page 3]

Internet-Draft    Combined User and Infrastructure ENUM        June 2007


   may take some time.  It was therefore decided to develop an Interim
   Solution that can be used by individual countries to implement an
   interoperable Infrastructure ENUM tree immediately.  The Interim
   Solution will be deprecated upon approval (loosely timed) of the
   long-term solution.  It is therefore also required that the Interim
   Solution includes a smooth migration path to the long-term solution.

   It is also required that existing ENUM clients querying User ENUM as
   defined in RFC 3761 [2] continue to work without any modification.

   Because of various reasons, sharing a single domain name between the
   user itself and the respective carrier for a number is not possible.
   Hence, a different domain name must be used to store infrastructure
   ENUM information.

   The method most easily fulfilling this is to branch off the e164.arpa
   tree into a subdomain at or somewhere below the country code
   delegation level below e164.arpa, and deploy an Infrastructure ENUM
   subtree underneath without touching User ENUM semantics at all.


4.  Leveraging the e164.arpa infrastructure

   A convention is needed how, given a fully qualified E.164 number [3],
   a resolver can determine the location of the Infrastructure ENUM
   domain for this number.  In order to avoid the delays associated with
   the long term solution, the existing delegations and agreements
   around e164.arpa need to be leveraged for the discovery algorithm.

   Under this approach, ITU-T and IETF (IAB) involvement is only
   lightweight, e.g. to recommend the proper algorithm defined here to
   enable international interoperability.

   This allows to introduce the Interim Solution as a national matter by
   the concerned National Regulation Authority (NRA) or as a regional
   opt-in within in a given Numbering Plan Area (NPA) such as the North
   American NPA.

   Beyond the setup phase, an NRA need not be involved operationally -
   it is sufficient to establish a convention linking the national
   definition of a carrier of record to the credentials for write access
   to the Infrastructure ENUM tree.


5.  Locating the Infrastructure ENUM Branch

   [7] specifies an extension to the ENUM DDDS application which adds an
   extra mapping step using a DNS resource record (Infrastructure ENUM



Haberler & Stastny      Expires December 15, 2007               [Page 4]

Internet-Draft    Combined User and Infrastructure ENUM        June 2007


   Branch Location - IEBL) to the E.164 to domain-name translation
   algorithm.

   The decision where to place the Infrastructure ENUM tree is a
   national or group-of-countries decision.  The IEBL affecting the
   translation of any E.164 number thus needs to reside under the
   e164.arpa tree for the country code of that number.

   The IEBL contains the following parameters:
   1.  a SEPARATOR,
   2.  a POSITION,
   3.  an APEX.

   Together, these three parameters describe the tree shape for a
   country's Infrastructure ENUM tree according to the Interim Solution.
   These parameters provide enough flexibility to describe setups
   ranging from branches under e164.arpa at NPA level, branches at
   country-code level, independent trees per country, and also the long-
   term solution.

   o  Existence of the IEBL Record: The national or group-of-country's
      decision to implement the Interim Solution is documented in the
      e164.arpa tree by inserting an IEBL resource record at the country
      code level.

   o  SEPARATOR: This branching label will be inserted into the ENUM
      domain to branch off from the User-ENUM tree into the
      Infrastructure ENUM sub-tree.  This MAY be an empty (zero-length)
      string which means no label will be inserted.

   o  POSITION: A number indicating after which digit this label
      (SEPARATOR) should be inserted.  A value of 0 means to the right
      of all digits.

   o  APEX: A domain name indicating what domain replaces "e164.arpa"
      for this application. "e164.arpa" MAY also be replaced by itself.

   o  The IEBL record is extremely well suited for caching: The layout
      of a country's Infrastructure ENUM setup is very static
      information, allowing large TTLs on the IEBL records.  Overall,
      the number of possible IEBL records in the DNS is bounded by the
      number of countries, which in combination means very high cache
      hit rates.


6.  Position of the IEBL Record

   The EBL record for Infrastructure ENUM (IEBL), as defined in [7]), is



Haberler & Stastny      Expires December 15, 2007               [Page 5]

Internet-Draft    Combined User and Infrastructure ENUM        June 2007


   stored in the DNS at the country code level within the e164.arpa ENUM
   tree.

   If a country or group-of-countries decides to implement the interim
   solution for Infrastructure ENUM, then it SHALL put an IEBL record at
   the level of individual country codes as assigned by ITU-T.

   The same algorithm applies for non-geographic country codes (global
   services, e.g. +800, +878, +808 or networks, e.g. +882): If I-ENUM is
   introduced for these numbers, the IEBL record SHALL be stored at
   X.Y.Z.e164.arpa, even if the Tier-1 delegation is not at that level
   in the ENUM tree.

   The only remaining a-priori knowledge an Infrastructure ENUM resolver
   needs to have is the current list of country codes, or an equivalent
   method to determine where the country code in the number ends.

   The authoritative source for up-to-date country code allocations is
   published by ITU-T as complement to the recommendation E.164 [3].
   The current version of this complement is available from ITU website
   under "ITU-T / Service Publications".

   As of 2007, the country code length can be determined with the
   following simple algorithm:


   o  3 digits is the default length of a country code.
   o  country codes 1 and 7 are a single digit.
   o  the following country codes are two digits: 20, 27, 30-34, 36, 39,
      40, 41, 43-49, 51-58, 60-66, 81, 82, 84, 86, 90-95, 98.

                                 Figure 1

   Given the fact that the ITU-T recently allocated only 3-digit country
   codes, there are no more spare 1- and 2-digit country codes and
   existing 1- and 2-digit country codes are extremely unlikely to be
   recovered, the above table consisting of the existing 1- and 2-digit
   country codes can be considered very stable.  The only problem may be
   a country split as happened recently e.g. to Yugoslavia.

   Examples can be found in [7]


7.  Recommended resolver behaviour

   An User ENUM resolver as per RFC 3761 need not be aware of any
   Infrastructure ENUM conventions at all.  A combined User and
   Infrastructure ENUM resolver shall behave as follows:



Haberler & Stastny      Expires December 15, 2007               [Page 6]

Internet-Draft    Combined User and Infrastructure ENUM        June 2007


   The input to the resolver routine shall be:
   1.  the E.164 number in fully qualified (international) format,
   2.  a mode parameter indicating whether resolution should follow User
       ENUM or Infrastructure ENUM rules,
   3.  optionally a table or algorithm to calculate country code lengths
       (Section 6),
   4.  any other parameters used to drive the search, for instance an
       enumservice type.  These parameters are outside the scope of this
       draft.

   The resolver shall proceed as follows:
   o  If the mode parameter indicates a User ENUM search, proceed as per
      RFC 3761.
   o  If the mode parameter indicates an Infrastructure ENUM query:
      *  Determine country code length, and thus the location of the
         IEBL record.
      *  Check for a cached IEBL lookup result.
      *  If no cached result is present:

         Retrieve the IEBL record from the country code zone, and store
         the result in a cache.  For positive result, normal DNS caching
         semantics apply.  For negative results, it is RECOMMENDED that
         the ENUM client sets the caching timeout to 24 hours.
      *  If no IEBL is present at the calculated position in the DNS,
         return an error.
      *  If an IEBL was found, construct a domain name according to the
         algorithm given in [7].
      *  Search the DNS for any ENUM NAPTR records for the resulting
         domain name.

   It is assumed that the location of the Infrastructure ENUM tree for
   each country will be rather static.  Extensive caching of discovered
   IEBL records (and their absence) is thus recommended.


8.  Security considerations

   Privacy issues have been raised regarding unwarranted disclosure of
   user information by publishing Infrastructure ENUM information in the
   public DNS, for instance the use for harvesting of numbers in
   service, or unlisted numbers.

   Given that number range allocation is public information, we believe
   the easiest way to cope with such concerns is to fully unroll
   allocated number ranges in the Infrastructure ENUM subtree, wherever
   such privacy concerns exist.  Whether a number is served or not would
   be exposed by the carrier of record when an attempt is made to
   contact the corresponding URI.  We assume this to be an authenticated



Haberler & Stastny      Expires December 15, 2007               [Page 7]

Internet-Draft    Combined User and Infrastructure ENUM        June 2007


   operation, which would not leak information to unauthorized parties.

   Entering all numbers in an allocated number range, whether serviced
   or not, or listed or unlisted, will prevent mining attempts for such
   number attributes.

   The result would be that the information in the public DNS would
   mirror number range allocation information, but not more.
   Infrastructure ENUM will not tell you more than you can get by just
   dialing numbers.

   The URI pointing to the destination network of the Carrier of Record
   should also not disclose any privacy information about the identity
   of end-user.  It is therefore recommended to use either anonymized
   UserIDs or the E.164 number itself in the user-part of the URI, such
   as in sip:+441632960084@example.com .

   The usage of the Branch Location record conveys only static setup
   information under a country code subtree of e164.arpa.  The intended
   use of DNS Security Extensions (DNSSEC) within ENUM will prove
   authenticity of the conveyed value.


9.  IANA considerations

   None.


10.  Interoperability considerations

   An application using the combined resolver needs to indicate which
   information is requested - User or Infrastructure ENUM, or both.  A
   user-ENUM-only resolver need not be aware of the Infrastructure ENUM
   subtree and no changes with respect to RFC 3761 semantics are
   required.  A resolver desiring to retrieve Infrastructure ENUM or
   both types of records needs to be aware of the conventions laid out
   in this draft.

   When the long-term solution is adopted, each country using the
   interim solution may decide on its own when to migrate to the long-
   term solution.  The IEBL records for this country would then be
   changed to the values "position=0", "separator="" and
   "apex=example.com" (whatever is defined).  When finally all countries
   have migrated, the IEBL records may be removed.







Haberler & Stastny      Expires December 15, 2007               [Page 8]

Internet-Draft    Combined User and Infrastructure ENUM        June 2007


11.  Acknowledgements

   We gratefully acknowledge suggestions and improvements by Jason
   Livingood and Tom Creighton of Comcast, Penn Pfautz of ATT, Lawrence
   Conroy of Roke Manor Research, and Alexander Mayrhofer and Otmar
   Lendl of enum.at.


12.  References

12.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
        Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
        Application (ENUM)", RFC 3761, April 2004.

   [3]  ITU-T, "The International Public Telecommunication Number Plan",
        Recommendation E.164, February 2005.

   [4]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        One: The Comprehensive DDDS", RFC 3401, October 2002.

   [5]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
        January 2005.

   [6]  Mockapetris, P., "Domain names - concepts and facilities",
        STD 13, RFC 1034, November 1987.

   [7]  Lendl, O., "The ENUM Branch Location Record",
        draft-ietf-enum-branch-location-record-03 (work in progress),
        June 2007.

12.2.  Informative References

   [8]  Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements",
        draft-ietf-enum-infrastructure-enum-reqs-04 (work in progress),
        May 2007.

   [9]  Livingood, J., "The E.164 to Uniform Resource Identifiers (URI)
        Dynamic Delegation Discovery  System (DDDS) Application for
        Infrastructure ENUM", draft-ietf-enum-infrastructure-05 (work in
        progress), January 2007.





Haberler & Stastny      Expires December 15, 2007               [Page 9]

Internet-Draft    Combined User and Infrastructure ENUM        June 2007


Authors' Addresses

   Michael Haberler
   Internet Foundation Austria
   Waehringerstrasse 3/19
   Wien  A-1090
   Austria

   Phone: +43 664 4213465
   Email: mah@inode.at
   URI:   http://www.nic.at/ipa/


   Richard Stastny
   Oefeg
   Postbox 147
   Vienna  A-1030
   Austria

   Phone: +43 664 420 4100
   Email: richard.stastny@oefeg.at
   URI:   http://www.oefeg.at





























Haberler & Stastny      Expires December 15, 2007              [Page 10]

Internet-Draft    Combined User and Infrastructure ENUM        June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Haberler & Stastny      Expires December 15, 2007              [Page 11]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/