One document matched: draft-ietf-enum-combined-09.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc1034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc3761 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3761.xml'>
<!ENTITY rfc3986 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml'>
<!ENTITY rfc3401 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3401.xml'>
<!ENTITY rfc2672 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2672.xml'>
<!ENTITY ienum-reqs PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5067.xml'>
<!ENTITY enum-infra PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-enum-infrastructure.xml'>
]>
<rfc ipr='trust200811' docName='draft-ietf-enum-combined-09' category='info'>
<?rfc toc='yes' ?>
<?rfc tocompact='no' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='yes' ?>
<front>
<title abbrev='Combined User and Infrastructure ENUM'>
Combined User and Infrastructure ENUM in the e164.arpa tree
</title>
<author initials='M.' surname='Haberler' fullname='Michael Haberler'>
<organization abbrev='IPA'>
Internet Foundation Austria
</organization>
<address>
<postal>
<street>Karlsplatz 1/2/9</street>
<city>Wien</city>
<code>1010</code>
<country>Austria</country>
</postal>
<phone>+43 664 4213465</phone>
<email>mah@inode.at</email>
<uri>http://www.nic.at/ipa/</uri>
</address>
</author>
<author initials='O.' surname='Lendl' fullname='Otmar Lendl'>
<organization abbrev='enum.at'>
enum.at GmbH
</organization>
<address>
<postal>
<street>Karlsplatz 1/2/9</street>
<city>Wien</city>
<code>A-1010</code>
<country>Austria</country>
</postal>
<phone>+43 1 5056416 33</phone>
<email>otmar.lendl@enum.at</email>
<uri>http://www.enum.at/</uri>
</address>
</author>
<author initials='R.' surname='Stastny' fullname='Richard Stastny'>
<organization abbrev='Oefeg'>
Oefeg
</organization>
<address>
<postal>
<street>Postbox 147</street>
<city>Vienna</city>
<code>A-1030</code>
<country>Austria</country>
</postal>
<phone>+43 664 420 4100</phone>
<email>richard.stastny@oefeg.at</email>
<uri>http://www.oefeg.at</uri>
</address>
</author>
<date month='March' year='2009' />
<area>RAI</area>
<workgroup>ENUM -- Telephone Number Mapping Working Group</workgroup>
<keyword>ENUM</keyword>
<keyword>carrier</keyword>
<keyword>infrastucture</keyword>
<keyword>operator</keyword>
<keyword>E.164</keyword>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section anchor='intro' title='Introduction'>
<t>ENUM (E.164 Number Mapping, <xref target="RFC3761">RFC 3761</xref>)
is a system that
transforms <xref target="refs.E164">E.164 numbers</xref> into domain names and
then queries the <xref target="RFC1034">DNS (Domain Name Service) </xref>
for <xref target="RFC3401">NAPTR (Naming Authority Pointer) records</xref>
to look up which services are available for a specific domain name.
</t>
<t>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.</t>
<t>Infrastructure ENUM is defined as the use of the technology in
<xref target="RFC3761">RFC 3761</xref>
by the <xref target="RFC5067">carrier-of-record
</xref> (voice service
provider) for a specific <xref target="refs.E164">E.164 number</xref> to
publish a mapping of this telephone number to
one or more <xref target="RFC3986">Uniform Resource Identifiers (URIs)</xref>.
</t>
<!--
<t>
FIXME: Mir gefaellt das so nicht. Ich haett da gern drinnen, dass
a) das mapping URI->Ingress point nicht so trivial sein muss wie bei
user-enum, und b), dass nicht davon ausgegangen werden kann, dass
der ingress-point fuer jeden erreichbar ist
</t>
-->
<t>
Other voice service providers can query the DNS for this mapping and use the
resulting URIs as input into their call routing algorithm.
<!--
This way the
originating party can derive specific points of interconnection
into the destination's service provider's network
<t>
Other voice service providers can query the DNS for this mapping and use the
resulting URIs to derive specific points of interconnection in the
destination network
originating party can derive specific points of interconnection
into the destination's service provider's network
<t>
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.
</t>
<t>The requirements, terms and definitions for Infrastructure
ENUM are defined in
<xref target="RFC5067"></xref>.
</t>
<t>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 <xref target="RFC3401">(DDDS)</xref> application for
Infrastructure ENUM is work in progress
<xref target="I-D.ietf-enum-infrastructure"></xref>. This is called the
long term solution.</t>
<t>
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 <xref target="alg"/>.
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 <xref target="pos"/>.
Finally, <xref target="transition"/> provides a way that implementations following
the procedures of <xref target="alg"/> and 5 may be seamlessly redirected to
the long-term solution, when it becomes available.
</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>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,
<xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section anchor='Interim' title='Interim Solution'>
<t>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.
</t>
<t>It is also required that existing ENUM clients querying User ENUM as
defined in <xref target="RFC3761">RFC 3761</xref> continue to work without any
modification.</t>
<t>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.</t>
<t>
In order to avoid the delays associated with the long term solution, the
existing delegations and agreements around e164.arpa need to be
leveraged.</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<section anchor='alg' title='The Algorithm'>
<t>
RFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS)
application according to <xref target="RFC3401">RFC 3401</xref>.
As such, ENUM defines the following components of the DDDS algorithm:
</t>
<vspace blankLines='1' />
<list style="numbers">
<t>Application Unique String</t>
<t>First Well Known Rule</t>
<t>Expected Output</t>
<t>Valid Databases</t>
</list>
<t>
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:
</t>
<vspace blankLines='1' />
<list style="numbers">
<t>Remove all characters with the exception of the digits.</t>
<t>Put dots (".") between each digit.</t>
<t>Reverse the order of the digits.</t>
<t>Append the string ".e164.arpa" to the end.</t>
</list>
<t>
The Interim Solution for Infrastructure ENUM uses a modified version
of this algorithm:
</t>
<list style="numbers">
<vspace blankLines='1' />
<t>
Determine the proper POSITION parameter for this E.164 number
according to the algorithm in <xref target="pos"/>.
</t>
<vspace blankLines='1' />
<t>Build an ordered list of single-digit strings from all digits appearing
in the telephone number.
All non-digit characters are ignored.
</t>
<vspace blankLines='1' />
<t>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.
</t>
<vspace blankLines='1' />
<t>Reverse the order of the list.</t>
<vspace blankLines='1' />
<t>Append the string "e164.arpa" to the end of the list.</t>
<vspace blankLines='1' />
<t>Create a single domain-name by joining the list together with dots
(".") between each string.</t>
</list>
<t>
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.
</t>
</section>
<section anchor='pos' title='Determing the Position of the Branch'>
<t>
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.
</t>
<t>
For international E.164-numbers for geographic areas
(<xref target="refs.E164"/> 6.2.1) and for
international E.164-numbers for global services
(<xref target="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.
</t>
<t>
For international E.164-number for networks
(<xref target="refs.E164"/> 6.2.3) the appropriate choice
for POSITION is the combined length of the CC (Country Code)
and IC (Identification Code) fields.
</t>
<t>
For international E.164-number for groups of countries
(<xref target="refs.E164"/> 6.2.4) the value
for POSITION is 4.
</t>
<t>
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
<xref target="refs.E164"/>. The current version of this complement is available from
ITU website under "ITU-T / Service Publications".
</t>
<t>
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.
</t>
<t>
As of 2007, the POSITION value for a specific E.164 number can be determined with the
following algorithm:
</t>
<figure anchor="ccalg">
<artwork>
</artwork>
<list style='symbols'>
<t>If the number starts with 1 or 7 then POSITION is 1</t>
<t>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.</t>
<t>If the number starts with 388 or 881, then POSITION is 4</t>
<t>If the number starts with 878 or 882, then POSITION is 5</t>
<t>If the number starts with 883 and the next digit is < 5, then POSITION is 6</t>
<t>If the number starts with 883 and the next digit is >= 5, then POSITION is 7</t>
<t>In all other cases, POSITION is 3.</t>
</list>
</figure>
<t>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.
</t>
<t>
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.
</t>
</section>
<section anchor='transition' title='Transition to the long-term Solution'>
<t>
The proposed long-term solution for Infrastructure ENUM
<xref target="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.
</t>
<t>
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.
</t>
<t>
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
<xref target="RFC2672">DNAME</xref>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor='examples' title='Examples'>
<t>
These are two examples of how E.164 numbers translate to to
Infrastructure ENUM domains according to the Interim Solution.
<artwork>
+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
</artwork>
</t>
<t>Here is the list of the intermediate steps for the second example to visualize how the
algorithm as defined in <xref target="alg"/> operates on "+44 2079460123":
</t>
<list style="numbers">
<vspace blankLines='1' />
<t>
"+44 2079460123" is within a 2-digit country code, thus
POSITION is 2.
</t>
<vspace blankLines='1' />
<t>The list of strings is ("4","4","2","0","7","9","4","6","0","1","2","3").
</t>
<vspace blankLines='1' />
<t>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")
</t>
<vspace blankLines='1' />
<t>Reversing the list gives:
("3","2","1","0","6","4","9","7","0","2","i","4","4")
</t>
<vspace blankLines='1' />
<t>Appending "e164.arpa" yields:
("3","2","1","0","6","4","9","7","0","2","i","4","4","e164.arpa")
</t>
<vspace blankLines='1' />
<t>Concatenation with dots: "3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa"
</t>
</list>
<t>
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:
<artwork>
i.4.4.e164.arpa. IN DNAME 4.4.ienum.example.net.
</artwork>
This way, clients using the interim I-ENUM solution end up querying
the same tree as clients implementing the long-term solution.
</t>
</section>
<section anchor='security' title='Security considerations'>
<t>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.
</t>
<t>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.
</t>
<t>Entering all numbers in an allocated number range, whether
serviced or not, or listed or unlisted, will prevent mining
attempts for such number attributes.
</t>
<t>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.
</t>
<t>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 .
</t>
</section>
<section anchor='IANA' title='IANA considerations'>
<t>None.</t>
</section>
<section anchor='acknowledgments' title='Acknowledgments'>
<t>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.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc3761;
<reference anchor="refs.E164">
<front>
<title>The International Public Telecommunication Number Plan</title>
<author>
<organization abbrev="ITU-T">ITU-T</organization>
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date month="February" year="2005" />
</front>
<seriesInfo name="Recommendation" value="E.164" />
</reference>
&rfc1034;
&rfc3401;
&rfc3986;
&rfc2119;
&rfc2672;
</references>
<references title='Informative References'>
&ienum-reqs;
&enum-infra;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:39:23 |