ENUM -- Telephone Number Mapping                             M. Haberler
Working Group                                                        IPA
Internet-Draft                                                R. Stastny
Intended status: Informational                                     Oefeg
Expires: June 2, 2007                                  November 29, 2006

      Combined User and Infrastructure ENUM in the e164.arpa tree

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on June 2, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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 June 2, 2007                  [Page 1]

Internet-Draft    Combined User and Infrastructure ENUM    November 2006

Table of Contents

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

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

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

   4.  Introducing a branch into the e164.arpa tree . . . . . . . . .  4

   5.  Defining the Infrastructure ENUM branch location . . . . . . .  4

   6.  Finding the ENUM branch location record  . . . . . . . . . . .  5

   7.  Construction of the FQDN . . . . . . . . . . . . . . . . . . .  6

   8.  Recommended resolver behaviour . . . . . . . . . . . . . . . .  7

   9.  Security considerations  . . . . . . . . . . . . . . . . . . .  7

   10. IANA considerations  . . . . . . . . . . . . . . . . . . . . .  8

   11. Interoperability considerations  . . . . . . . . . . . . . . .  8

   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9

   13. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     13.1.  Normative References  . . . . . . . . . . . . . . . . . .  9
     13.2.  Informative References  . . . . . . . . . . . . . . . . . 10

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

Haberler & Stastny        Expires June 2, 2007                  [Page 2]

Internet-Draft    Combined User and Infrastructure ENUM    November 2006

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 RFC3761 (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
   RFC3761 [2] by the carrier-of-record [8] (Voice service provider) for
   a specific E.164 number [3] to map a telephone number into an Uniform
   Resource Identifier (URI) [5].  This URI identifies a specific point
   of interconnection to the service provider's network that could
   enable the originating party to establish communication with the
   associated terminating party.  This URI is 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 for domain mapping techniques used 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",
   document are to be interpreted as described in BCP 14, RFC2119 [1].

3.  Interim Solution

   As stated above, the agreements to establish the long-term solution
   may take some time.  It was therefore decided to develop an interim
   solution that can be used by individual countries to implement an

Haberler & Stastny        Expires June 2, 2007                  [Page 3]

Internet-Draft    Combined User and Infrastructure ENUM    November 2006

   interoperable Infrastructure ENUM tree immediately.  The Interim
   solution will be deprecated upon approval (loosely timed) of the
   long-term solution.

   Is is therefore also required that the Interim solution is compatible
   with the long-term solution to allow for easy migration.

4.  Introducing a branch into the e164.arpa tree

   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 country.  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.

   The method most easily fulfilling the above mentioned requirements 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.

5.  Defining the Infrastructure ENUM branch location

   The decision where to place the Infrastructure ENUM tree below
   e164.arpa is a national or group-of-countries decision.  To branch
   off the e164.arpa tree for a given country code, a DNS label is
   inserted at a specific position into the ENUM fully qualified domain
   name (FQDN).

   For international interoperability and to allow for maximum
   flexibility, the following parameters SHOULD be used in ENUM tree

   1.  the name of the application,

Haberler & Stastny        Expires June 2, 2007                  [Page 4]

Internet-Draft    Combined User and Infrastructure ENUM    November 2006

   2.  a seperator,
   3.  the position,
   4.  an apex.

   We propose a mechanism to discover these parameters dynamically for
   any given tree shape as follows:

   o  the national or group-of-countries decision about subdomain
      location is documented in the e164.arpa tree by inserting a
      special DNS resource record at the country code level, called ENUM
      Branch Location Record (EBL) [7], into a subdomain in the country
      code zone.
   o  In case of the Infrastructure ENUM application, the label of the
      subdomain MUST be "infrastructure".  This ENUM Branch Location
      Record carries three values for maximum flexibility:
      1.  the branching label (separator) to be inserted into the ENUM
          domain to branch off to the application-specific tree.  This
          MAY be an empty (zero-length) string which means no label will
          be inserted.
      2.  an insertion position, indicating after which digit this label
          (separator) should be inserted into the ENUM domain to branch
          off to the application-specific tree.  A value of 0 means to
          the right of all digits.
      3.  an apex indicating what domain MUST replace "e164.arpa" for
          this application. "e164.arpa" MAY also be replaced by itself.
   o  a resolver looking for an Infrastructure ENUM domain needs to
      retrieve this EBL once during first resolution within a country
      code.  This is decribed in Section 6.
   o  The construction of the FQDN is described in Section 7., the
      recommended resolver behavior in Section 8.

6.  Finding the ENUM branch location record

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

   To prime the country code extraction algorithm, the current scheme to
   determine country code length as follows could be employed:

   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.

Haberler & Stastny        Expires June 2, 2007                  [Page 5]

Internet-Draft    Combined User and Infrastructure ENUM    November 2006

                                 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.

   If a branch location record is not found according to this table (for
   instance, in the unlikely case the ITU-T allocates a country code not
   according to these rules), it is still possible to determine the
   branch location record by "iterating down" the tree digit-by-digit.
   Such a fallback strategy would rely on the assumption that there is
   never a branch location record inserted above the country code zone,
   for which there would be no use in the first place.

   It seems unlikely that inspection of more than the first five digits
   will be required to locate the branch location record under any
   realistic numbering administrative partitioning.

7.  Construction of the FQDN

   For Infrastructure ENUM the construction of the FQDN deviates from
   the rules given in RFC3761 Section 2.4 in the following way:

   The output of the First Well Known Rule for the ENUM Application is
   the E.164 number minus all non-digit characters except for the +.  In
   order to convert this to a unique key the string is converted into a
   domain-name according to this algorithm:
   1.  Remove all characters with the exception of the digits.  For
       example, the First Well Known Rule produced the Key
       "+442079460148 ".  This step would simply remove the leading "+",
       producing "442079460148".
   2.  Put dots (".") between each digit.  Example:
   3.  Reverse the order of the digits.  Example:
   4.  Insert the "separator" given in the EBL at the place given by the
       "position" in the EBL.  Example:
   5.  Append the string given by the apex in the EBL to the end.

   The EBL used in the example is:

   infrastructure.4.4.e164.arpa.  IN EBL 2 "i" e164.arpa.

Haberler & Stastny        Expires June 2, 2007                  [Page 6]

Internet-Draft    Combined User and Infrastructure ENUM    November 2006

8.  Recommended resolver behaviour

   A 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:

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

   The resolver shall proceed as follows:
   o  if the mode parameter indicates a User ENUM search, proceed as per
   o  If the mode parameter indicates an Infrastructure ENUM query:
      *  determine country code length.
      *  consult table if an EBL record for this country code was
         already retrieved since resolver boot time.
      *  if not:
         +  retrieve the EBL record from the 'infrastructure' subdomain
            of the country code zone, and store the country code and
            associated EBL values in an EBL table.
         +  optional fallback for irregular country code not covered by
            the CC extraction algorithm (Figure 1) if the last step
            fails, iterate over the number up to five digits and try to
            retrieve the EBL record in the 'infrastructure' subdomain
            each time, again storing the country code and associated EBL
            values if successful.
         +  if both attempts fail, return NXDOMAIN.
      *  valid EBL record found: use the algorithm given in Section 7.
         to construct the FQDN
      *  search the DNS for any ENUM NAPTR records for the resulting
         domain name.

   It is assumed that already discovered EBL values are stored in a
   table of country code and already discovered EBL parameters.

9.  Security considerations

   Privacy issues have been raised regarding unwarranted disclosure of

Haberler & Stastny        Expires June 2, 2007                  [Page 7]

Internet-Draft    Combined User and Infrastructure ENUM    November 2006

   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
   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 definition of a new resource record (RR) type or a new
   enumservice does not introduce security problems into the DNS.  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.

10.  IANA considerations

   This document defines the name of the "application" label to be used
   to store the EBLs for the Infrastructure ENUM application as

11.  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 RFC3761 semantics are

Haberler & Stastny        Expires June 2, 2007                  [Page 8]

Internet-Draft    Combined User and Infrastructure ENUM    November 2006

   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 EBL records for this country would then be
   changed to the values "position=0", "seperator="" and
   "apex=example.com" (whatever is defined).  When finally all countries
   have migrated, the EBL records may be removed.

12.  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.

13.  References

13.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 Identifiers (URI): Generic Syntax", RFC 2396,
        August 1998.

   [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-01 (work in progress),
        November 2006.

Haberler & Stastny        Expires June 2, 2007                  [Page 9]

Internet-Draft    Combined User and Infrastructure ENUM    November 2006

13.2.  Informative References

   [8]  Lind, S. and P. Pfautz, "Infrastrucure ENUM Requirements",
        draft-ietf-enum-infrastructure-enum-reqs-03 (work in progress),
        August 2006.

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

Authors' Addresses

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

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

   Richard Stastny
   Postbox 147
   Vienna  A-1030

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

Haberler & Stastny        Expires June 2, 2007                 [Page 10]

Internet-Draft    Combined User and Infrastructure ENUM    November 2006

Full 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.

   This document and the information contained herein are provided on an

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

   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


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

Haberler & Stastny        Expires June 2, 2007                 [Page 11]