[Docs] [txt|pdf|xml|html] [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                                                  O. Lendl
Intended status: Informational                                   enum.at
Expires: September 6, 2009                                    R. Stastny
                                                                   Oefeg
                                                           March 5, 2009


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 September 6, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Haberler, et al.        Expires September 6, 2009               [Page 1]

Internet-Draft    Combined User and Infrastructure ENUM       March 2009


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.  This interim solution will be
   deprecated after approval and implementation of the long-term
   solution.


Table of Contents

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

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4

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

   4.  The Algorithm  . . . . . . . . . . . . . . . . . . . . . . . .  5

   5.  Determing the Position of the Branch . . . . . . . . . . . . .  6

   6.  Transition to the long-term Solution . . . . . . . . . . . . .  7

   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8

   8.  Security considerations  . . . . . . . . . . . . . . . . . . .  9

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

   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     11.1.  Normative References  . . . . . . . . . . . . . . . . . . 10
     11.2.  Informative References  . . . . . . . . . . . . . . . . . 10

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10















Haberler, et al.        Expires September 6, 2009               [Page 2]

Internet-Draft    Combined User and Infrastructure ENUM       March 2009


1.  Introduction

   ENUM (E.164 Number Mapping, RFC 3761 [RFC3761]) is a system that
   transforms E.164 numbers [refs.E164] into domain names and then
   queries the DNS (Domain Name Service) [RFC1034] for NAPTR (Naming
   Authority Pointer) records [RFC3401] 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 [RFC3761] by the carrier-of-record [RFC5067] (voice service
   provider) for a specific E.164 number [refs.E164] to publish a
   mapping of this telephone number to one or more Uniform Resource
   Identifiers (URIs) [RFC3986].

   Other voice service providers can query the DNS for this mapping and
   use the resulting URIs as input into their call routing algorithm.
   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 [RFC5067].

   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.  This process
   of defining the Dynamic Delegation Discovery System (DDDS) [RFC3401]
   application for Infrastructure ENUM is work in progress
   [I-D.ietf-enum-infrastructure].  This is called the long term
   solution.

   This document presents an interim solution for Infrastructure ENUM
   and a mechanism for transitioning to a long-term solution.  The
   interim solution is based on establishing a branch in the e164.arpa
   tree, which resolvers may locate by following the algorithm described
   in Section 4.  The location of the branch is dependent upon country
   code length, and thus resolvers must determine the position of the
   branch based on the method described in Section 5.  Finally,
   Section 6 provides a way that implementations following the
   procedures of Section 4 and 5 may be seamlessly redirected to the
   long-term solution, when it becomes available.





Haberler, et al.        Expires September 6, 2009               [Page 3]

Internet-Draft    Combined User and Infrastructure ENUM       March 2009


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
   [RFC2119].


3.  Interim Solution

   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 interoperable
   Infrastructure ENUM tree immediately.  The Interim Solution will be
   deprecated when the long-term solution becomes available.  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 [RFC3761] continue to work without any
   modification.

   Because of various reasons (e.g. potentially different delegation
   points, different reliability requirements, use of DNS wildcards),
   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.

   In order to avoid the delays associated with the long term solution,
   the existing delegations and agreements around e164.arpa need to be
   leveraged.

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

   This allows countries using a dedicated country code to introduce the
   Interim Solution as a national matter by the concerned National
   Regulation Authority (NRA).  The governing body of a shared country
   code and the owner of a global network code can also chose to
   implement this solution within their area of responsibility.

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




Haberler, et al.        Expires September 6, 2009               [Page 4]

Internet-Draft    Combined User and Infrastructure ENUM       March 2009


4.  The Algorithm

   RFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS)
   application according to RFC 3401 [RFC3401].  As such, ENUM defines
   the following components of the DDDS algorithm:

   1.  Application Unique String
   2.  First Well Known Rule
   3.  Expected Output
   4.  Valid Databases

   The "Valid Databases" part contains the transformation of a E.164
   telephone number into a domain name.  Section 2.4 of RFC 3761 uses
   the following four step algorithm for this:

   1.  Remove all characters with the exception of the digits.
   2.  Put dots (".") between each digit.
   3.  Reverse the order of the digits.
   4.  Append the string ".e164.arpa" to the end.

   The Interim Solution for Infrastructure ENUM uses a modified version
   of this algorithm:

   1.  Determine the proper POSITION parameter for this E.164 number
       according to the algorithm in Section 5.

   2.  Build an ordered list of single-digit strings from all digits
       appearing in the telephone number.  All non-digit characters are
       ignored.

   3.  Insert a string consisting of "i" after POSITION strings into
       this list.  If the list of strings was shorter than POSITION
       elements, then report an error.

   4.  Reverse the order of the list.

   5.  Append the string "e164.arpa" to the end of the list.

   6.  Create a single domain-name by joining the list together with
       dots (".") between each string.

   This is the only point where the interim Infrastructure ENUM solution
   differs from straight RFC 3761 ENUM.  All other parts of User-ENUM,
   including the enumservices registrations, apply to I-ENUM as well.







Haberler, et al.        Expires September 6, 2009               [Page 5]

Internet-Draft    Combined User and Infrastructure ENUM       March 2009


5.  Determing the Position of the Branch

   In order to allow for the deployment of this Interim Solution
   independently of IAB/ITU-T/RIPE-NCC negotiations the branching label
   "i" cannot be inserted in the Tier-0 zone (i.e. the e164.arpa zone
   itself) managed currently by RIPE NCC.  This condition acts as a
   lower bound on the choice of the POSITION parameter.

   For international E.164-numbers for geographic areas ([refs.E164]
   6.2.1) and for international E.164-numbers for global services
   ([refs.E164] 6.2.2) the most sensible choice for POSITION is number
   of digits in the country code of the number in question.  This places
   the branch directly under the country code level within the e164.arpa
   ENUM tree.

   For international E.164-number for networks ([refs.E164] 6.2.3) the
   appropriate choice for POSITION is the combined length of the CC
   (Country Code) and IC (Identification Code) fields.

   For international E.164-number for groups of countries ([refs.E164]
   6.2.4) the value for POSITION is 4.

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

   Please note that country code 1 of the North American Numbering Plan
   (NANP) does not fall under the ITU classification of "groups of
   countries", but is a "shared country code" for a geographic area.
   The POSITION parameter for the NANP is thus 1.

   As of 2007, the POSITION value for a specific E.164 number can be
   determined with the following algorithm:


   o  If the number starts with 1 or 7 then POSITION is 1
   o  If the number is in one of the following 2-digit country codes:
      20, 27, 30-34, 36, 39, 40, 41, 43-49, 51-58, 60-66, 81, 82, 84,
      86, 90-95, or 98, then POSITION is 2.
   o  If the number starts with 388 or 881, then POSITION is 4
   o  If the number starts with 878 or 882, then POSITION is 5
   o  If the number starts with 883 and the next digit is < 5, then
      POSITION is 6
   o  If the number starts with 883 and the next digit is >= 5, then
      POSITION is 7




Haberler, et al.        Expires September 6, 2009               [Page 6]

Internet-Draft    Combined User and Infrastructure ENUM       March 2009


   o  In all other cases, POSITION is 3.

                                 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 list of 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.

   Regarding network codes, the ITU-T has up to 2007 only allocated one
   and two digit ICs.  Assignments of three and four digit ICs started
   in May 2007 in the +883 country code.  A further change in the ITU-T
   policy in this respect will need to be reflected in the above
   algorithm.


6.  Transition to the long-term Solution

   The proposed long-term solution for Infrastructure ENUM
   [I-D.ietf-enum-infrastructure] is the establishment of a new zone
   apex for that tree.  This apex will play the same role as "e164.arpa"
   does for User-ENUM.

   It is unrealistic to assume that all countries and all ENUM clients
   will manage to migrate from the Interim Solution to the long-term
   solution at single point in time.  It is thus necessary to plan for
   an incremental transition.

   In order to achieve this, clients using the interim solution need to
   be redirected to the long-term I-ENUM tree for all country codes
   which have already switched to the long-term solution.  This SHOULD
   be done by placing DNAME [RFC2672] records at the branch (the "i")
   label pointing to the appropriate domain name in the long-term I-ENUM
   tree.  All descendants at that branch label location where the DNAME
   record is inserted MUST be removed as required by Section 3 of RFC
   2672.

   Therefore ALL entities involved in making or answering DNS queries
   for I-ENUM MUST fully support the DNAME record type and its
   semantics.  In particular, entities involved in I-ENUM lookups MUST
   correctly handle responses containing synthesized CNAMEs that may be
   generated as a consequence of DNAME processing by any other element
   in resolution, typically an iterative mode resolving name server.
   These entities MUST also apply adequate measures to detect loops and
   prevent non-terminating resolutions because of improperly configured
   DNAME records or combinations of DNAME and CNAME records.



Haberler, et al.        Expires September 6, 2009               [Page 7]

Internet-Draft    Combined User and Infrastructure ENUM       March 2009


   Note: Some caching name server implementations are known to handle
   DNAMEs incorrectly.  In the worst case, such bugs could stay
   undetected until some country transitions to the long-term solution.
   Therefore, ensuring full DNAME support from the start (and carefully
   testing that it actually works) is important.

   The domain name for the branch location and its DNAME record SHOULD
   be removed once the transition to the long-term solution is completed
   and all entities involved in I-ENUM have migrated to the new zone
   apex for I-ENUM.


7.  Examples

   These are two examples of how E.164 numbers translate to to
   Infrastructure ENUM domains according to the Interim Solution.

   +1 21255501234          4.3.2.1.0.5.5.5.2.1.2.i.1.e164.arpa
   +44 2079460123          3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa

   Here is the list of the intermediate steps for the second example to
   visualize how the algorithm as defined in Section 4 operates on "+44
   2079460123":

   1.  "+44 2079460123" is within a 2-digit country code, thus POSITION
       is 2.

   2.  The list of strings is
       ("4","4","2","0","7","9","4","6","0","1","2","3").

   3.  POSITION is 2, thus "i" is inserted between the second and the
       third string, yielding:
       ("4","4","i","2","0","7","9","4","6","0","1","2","3")

   4.  Reversing the list gives:
       ("3","2","1","0","6","4","9","7","0","2","i","4","4")

   5.  Appending "e164.arpa" yields:
       ("3","2","1","0","6","4","9","7","0","2","i","4","4","e164.arpa")

   6.  Concatenation with dots: "3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa"

   After the introduction of the long term Infrastructure ENUM solution
   using for example "ienum.example.net" as the new apex for I-ENUM, the
   administrators of +44 can implement a smooth transition by putting
   the following DNAME record in their zone:

   i.4.4.e164.arpa.    IN DNAME 4.4.ienum.example.net.



Haberler, et al.        Expires September 6, 2009               [Page 8]

Internet-Draft    Combined User and Infrastructure ENUM       March 2009


   This way, clients using the interim I-ENUM solution end up querying
   the same tree as clients implementing the long-term solution.


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


9.  IANA considerations

   None.


10.  Acknowledgments

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





Haberler, et al.        Expires September 6, 2009               [Page 9]

Internet-Draft    Combined User and Infrastructure ENUM       March 2009


11.  References

11.1.  Normative References

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

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

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

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

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

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

   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
              RFC 2672, August 1999.

11.2.  Informative References

   [RFC5067]  Lind, S. and P. Pfautz, "Infrastructure ENUM
              Requirements", RFC 5067, November 2007.

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












Haberler, et al.        Expires September 6, 2009              [Page 10]

Internet-Draft    Combined User and Infrastructure ENUM       March 2009


Authors' Addresses

   Michael Haberler
   Internet Foundation Austria
   Karlsplatz 1/2/9
   Wien  1010
   Austria

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


   Otmar Lendl
   enum.at GmbH
   Karlsplatz 1/2/9
   Wien  A-1010
   Austria

   Phone: +43 1 5056416 33
   Email: otmar.lendl@enum.at
   URI:   http://www.enum.at/


   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, et al.        Expires September 6, 2009              [Page 11]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/