RFC 5527

Combined User and Infrastructure ENUM in the e164.arpa Tree

📅 published May 2009, from ietf

Combined User and Infrastructure ENUM in the e164.arpa Tree 🎀

Okay bestie, this is RFC 5527 🦋, published in May 2009 and written by M. Haberler (IPA), O. Lendl (enum.at), and R. Stastny (Unaffiliated). It's an Informational doc, so it gives info to the community and doesn't set an Internet standard. The title block doesn't list any RFCs that it obsoletes or updates, so there's no drama there 💅.

Status of This Memo ✨

This memo gives info to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

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.

Abstract 🌸

So the gist is this: the memo defines an interim solution for Infrastructure ENUM 🧚. It lets a combined User and Infrastructure ENUM setup live in e164.arpa, as a national choice 🇺🇳. This interim solution gets deprecated once the long-term solution is implemented.

Table of Contents 🍓

1. Introduction ....................................................2
2. Terminology .....................................................3
3. Interim Solution ................................................3
4. The Algorithm ...................................................4
5. Determining the Position of the Branch ..........................5
6. Transition to the Long-Term Solution ............................6
7. Examples ........................................................7
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
   10.1. Normative References ......................................9
   10.2. Informative References ....................................9

1. Introduction 🦋

Okay so first, ENUM (E.164 Number Mapping, [RFC3761]) is a system that takes E.164 numbers [E164] and turns them into domain names 🔄. Then it asks the DNS (Domain Name Service) [RFC1034] for NAPTR (Naming Authority Pointer) records [RFC3401] to find out which services are available for that domain name. It's giving phone-number-to-internet-address glow-up ✨.

ENUM as defined in RFC 3761 (User ENUM) is not well suited for interconnection between carriers and voice-service providers, and you can see that from all the private tree setups people built on ENUM mechanisms 🙈.

Infrastructure ENUM is defined as using the technology in RFC 3761 [RFC3761] by the carrier-of-record (voice service provider) [RFC5067] for a specific E.164 number [E164]. The point is to publish a mapping from that phone number to one or more Uniform Resource Identifiers (URIs) [RFC3986] 📞.

Other voice service providers can query the DNS for this mapping and feed the resulting URIs into their call-routing algorithm 🛣️. These URIs are separate from any URIs that the end-user, who registers an E.164 number in ENUM, may want to link to that number. Two different vibes, bestie 💅.

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 ✨. Defining the Dynamic Delegation Discovery System (DDDS) [RFC3401] application for Infrastructure ENUM is what [RFC5526] does, and that's the long-term solution 👑.

This document presents an interim solution for Infrastructure ENUM, plus a mechanism for moving over to the long-term solution 🌈. The interim solution is based on setting up a branch in the e164.arpa tree, which resolvers can find by following the algorithm in Section 4. Where that branch sits depends on country-code length, so resolvers have to figure out the position of the branch using the method in Section 5 🧮. Last but not least, Section 6 explains how implementations that follow the procedures in Sections 4 and 5 can be seamlessly redirected to the long-term solution once it's available 🫶.

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 set up the long-term solution might take a while ⏳. So the crew decided to make an interim solution that individual countries can use right away to run an interoperable Infrastructure ENUM tree 🚀. The interim solution will be deprecated once the long-term solution [RFC5526] is deployed. It's therefore also required that the interim solution include a smooth migration path to the long-term solution 🛤️.

It's also required that existing ENUM clients querying User ENUM as defined in RFC 3761 [RFC3761] keep working without any modification 🙌.

Because of various reasons (for example, potentially different delegation points, different reliability requirements, and the use of DNS wildcards), the user and the respective carrier for a given number can't share a single domain name. So a different domain name must be used to store Infrastructure ENUM information 🙅‍♀️.

To avoid the delays that come with the long-term solution, the existing delegations and agreements around e164.arpa need to be leveraged 🧠.

The approach that most easily meets the requirements is to branch off the e164.arpa tree into a subdomain at the country-code delegation level below e164.arpa, then deploy an Infrastructure ENUM subtree underneath it. That doesn't touch User ENUM semantics at all 🦋.

This lets countries that have a dedicated country code introduce the interim solution as a national matter, with the concerned National Regulation Authority (NRA) 🏛️. The governing body of a shared country code and the owner of a global network code can also choose to implement this solution within their area of responsibility 💅.

Under this approach, ITU-T (International Telecommunication Union / Telecommunication Standardization Sector), IETF, and IAB involvement is only lightweight. For example, they might recommend the proper algorithm defined here so international interoperability works 🌍.

4. The Algorithm 🧮

RFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS) application according to RFC 3401 [RFC3401]. So 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 is where an E.164 telephone number gets transformed into a domain name 🔁. Section 2.4 of RFC 3761 uses this 4-step algorithm for it:

  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 of this document.
  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" into this list, after POSITION strings. 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 spot where the interim Infrastructure ENUM (I-ENUM) solution differs from straight RFC 3761 ENUM 🎯. All the other parts of User ENUM, including the enumservices registrations, apply to I-ENUM as well 🫶.

5. Determining the Position of the Branch 🌈

So the whole point here is that the interim solution can be deployed independently of IAB/ITU-T/RIPE-NCC negotiations 🤝. That's why the branching label "i" cannot be inserted in the Tier-0 zone (i.e., the e164.arpa zone itself), which the RIPE NCC currently manages 🙅‍♀️. This condition acts as a lower bound on the choice of the POSITION parameter.

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

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

For an international E.164 number for groups of countries (Section 6.2.4 of [E164]), the value for POSITION is 4 🌏.

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

Heads up, bestie: country code 1 of the North American Numbering Plan (NANP) does NOT fall under the ITU classification of "groups of countries". It's a "shared country code" for a geographic area, so the POSITION parameter for the NANP is 1 🇺🇸.

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

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

Since the ITU-T recently allocated only 3-digit country codes, there are no more spare 1- and 2-digit country codes 🙃. Existing 1- and 2-digit country codes are extremely unlikely to be recovered, so the list above of existing 1- and 2-digit country codes can be considered very stable 💎. The only problem might come up for a country that has split, which is what happened recently to Yugoslavia 💔.

As for network codes, up to 2007 the ITU-T had only allocated 1- and 2-digit ICs. Assignments of 3- and 4-digit ICs started in May 2007 in the +883 country code 📅. Any further change in ITU-T policy in this respect will need to be reflected in the above algorithm 🔔.

6. Transition to the Long-Term Solution 🦋

okay so the long-term plan for Infrastructure ENUM [RFC5526] is making a brand new zone apex for that tree 👑. It's basically doing the same job that "e164.arpa" does for User ENUM, just for the infrastructure side. iconic 💅

Be realistic though: not every country and every ENUM client is gonna switch over at the exact same moment 😭. That would be wild. So we need to plan for an incremental transition, one step at a time 🧚.

To make that happen, clients using the interim solution need to get redirected to the long-term I-ENUM tree for every country code that has already moved over 🌈. The way to do this is to put DNAME [RFC2672] records at the branch (the "i") label, pointing at the matching domain name in the long-term I-ENUM tree. This SHOULD be done that way 🎀. And all descendants at that branch label location, where the DNAME record gets inserted, MUST be removed, as required by Section 3 of RFC 2672 💜.

So ALL entities that make or answer DNS queries for I-ENUM MUST fully support the DNAME record type and what it means 💖. Anyone doing I-ENUM lookups MUST correctly handle responses with synthesized CNAMEs, which can pop up because of DNAME processing done by some other element in the resolution. Usually that's an iterative mode resolving name server 🫶.

These entities MUST also use proper measures to detect loops and stop non-terminating resolutions. This matters because of badly configured DNAME records or weird combos of DNAME and CNAME records 💀.

Heads up: some caching name server implementations are known to handle DNAMEs incorrectly 😬. In the worst case, those bugs could hide out undetected until a country switches to the long-term solution. So making sure full DNAME support is there from the start (and actually testing that it works) is super important 🔥.

Once the transition is finished and every entity involved in I-ENUM has moved to the new zone apex for I-ENUM, the domain name for the branch location and its DNAME record SHOULD be removed 🌸. Clean up after the party ✨.

7. Examples 🍓

These are two examples of how E.164 numbers turn into Infrastructure ENUM domains under 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's the step-by-step for the second one, so you can see how the algorithm from Section 4 works on "+44 2079460123" 🤓:

  1. "+44 2079460123" is within a 2-digit country code, so 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, so "i" gets inserted between the second and the third string, giving ("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" gives ("3","2","1","0","6","4","9","7","0","2","i","4","4","e164.arpa").
  6. Concatenating with dots gives "3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa".

Now imagine the long-term Infrastructure ENUM is live, with "ienum.example.net" as the new apex for I-ENUM 👑. The +44 admins can make a smooth transition by putting this DNAME record in their zone 🫶:

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

And honestly this is the best part 😭: clients using the interim I-ENUM solution end up querying the same tree as clients using the long-term solution. Everybody's on the same page 💅✨.

8. Security Considerations 🙈

Okay, this section is serious, bestie 🚨. Privacy issues have been raised about the unwarranted disclosure of user info that would happen if Infrastructure ENUM info got published in the public DNS 😱. For example, that kind of disclosure could be used to harvest numbers in service, or to find unlisted numbers 💀.

Number-range allocation is public information 📖. So we think the easiest way to deal with these worries is to fully unroll allocated number ranges in the Infrastructure ENUM subtree, anywhere the privacy concerns exist 🌈. Whether a number is actually served would be revealed by the carrier-of-record when someone tries to contact the matching URI 📞. We assume that's an authenticated operation, so it wouldn't leak info to unauthorized parties 🔐.

Entering every number in an allocated range, whether serviced or not, listed or unlisted, will stop mining attempts for those number attributes 🛡️. Lowkey genius.

The end result is that the public DNS will mirror number-range allocation info, and nothing more 🎀. Infrastructure ENUM won't tell you anything you couldn't find out by just dialing numbers 📱. No extra tea ☕.

The URI pointing to the destination network of the carrier-of-record also shouldn't disclose any privacy info about the identity of the 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 sip:+441632960084@example.com 💜.

9. Acknowledgments 🫶

Big thank-yous to Jason Livingood and Tom Creighton of Comcast, Penn Pfautz of AT&T, Lawrence Conroy of Roke Manor Research, Jim Reid, and Alexander Mayrhofer of enum.at 💖. You all are literally the MVPs 👑.

10. References 📚

10.1. Normative References

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

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

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

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

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

10.2. Informative References

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

[RFC5526]  Livingood, J., Pfautz, P., and R. Stastny, "The E.164 to
           Uniform Resource Identifiers (URI) Dynamic Delegation
           Discovery System (DDDS) Application for Infrastructure
           ENUM", RFC 5526, April 2007.

Authors' Addresses 💌

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

Phone: +43 664 4213465
EMail: ietf@mah.priv.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
Unaffiliated
Anzbachgasse 43
1140 Vienna
Austria

Phone: +43 664 420 4100
EMail: richardstastny@gmail.com

That's the whole RFC, bestie 🦋💖

📦 where this page comes from