RFC 3245

The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)

📅 published March 2002, from ietf

RFC 3245: The History and Context of Telephone Number Mapping (ENUM) Operational Decisions ✨

Bestie, this one is the IETF explaining its own ENUM decisions to the ITU-T folks. 💖

Title block 📋: It's RFC 3245, from the Network Working Group, with J. Klensin, Ed. as the editor and the IAB as the author body. It's Informational (🎀 not a standard, just info for the community) and dated March 2002. The header doesn't list anything it obsoletes or updates. Totally clean slate 🦋

The full title is The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2).

Status of this Memo

This memo gives info to the Internet community. It does not specify an Internet standard of any kind, so no vibes of "you must implement this" 🙅‍♀️ Distribution is unlimited.

Copyright (C) The Internet Society (2002). All Rights Reserved. 💅

Abstract

okay so RFC 2916 gave the IAB a bunch of the admin and ops stuff for ENUM 🗂️ It also expected that the ITU would decide whether applicants for delegation of "country code"-level subdomains of the top-level ENUM domain were legit and appropriate 🌍 Recently, three memos were written for ITU-T Study Group 2 (SG2) to explain the background and reasoning behind those decisions 📝 The IAB also gave the RIPE NCC a set of procedural instructions for their part of the model 🦋 This document shares the content of all three memos with the IETF community. Main character energy from the start 👑

Table of Contents 🌸

   1. Introduction: ENUM Background Information .....................  2
   2. Why one and only one domain is used in ENUM ...................  2
   3. Why .ARPA was selected as the top level domain for ENUM .......  4
   4. The selection of an operator for E164.ARPA ....................  7
   5. Procedures to be followed by RIPE NCC .........................  8
   6. References ....................................................  8
   6.1. Normative references ........................................  8
   6.2. Informative and explanatory references ......................  8
   7. Security Considerations .......................................  9
   8. IANA Considerations ...........................................  9
   9. Authors' Addresses ............................................  9
   10. Full Copyright Statement ..................................... 10

1. Introduction: ENUM Background Information ✨

So in January 2002 🗓️ the ITU-T Study Group 2 (just "SG2" from here on) had questions, specifically from their "Questions 1 and 2" group. Members of the IETF and telecom folks had questions too 🙋‍♀️ Scott Bradner, who was the Area Director for ENUM work and ISOC Vice President for Standards, started an effort to write up explanations of the IETF's ENUM admin decisions 📚 That effort ended up involving him, Patrik Faltstrom (author of RFC 2916), and several IAB members. Iconic teamwork 🫶

The documents have been sent to ITU-T and are being published as internal SG2 documents. This doc gives the IETF community a copy of what went to SG2 🎀 Section 2 has the same content as COM 2-11-E, section 3 has the same content as COM 2-12-E, and section 4 has the same content as SG2 document COM 2-10-E. The SG2 versions list their source as "THE INTERNET SOCIETY ON BEHALF OF THE IETF." That's just a formality, because ISOC holds an ITU sector membership on behalf of the IETF 💅

2. Why one and only one domain is used in ENUM 🌈

2.1. Introduction

This is one of a series of contributions the IETF gave to ITU-T SG2 💌 They explain the background of the IETF's ENUM Working Group deliberations and decisions. This particular one covers the IETF's decision that only a single domain could be supported in ENUM. It's giving "one source of truth" 🍓

2.2. The need for a single root in the DNS

In the Domain Name System (DNS), every domain name is globally unique. This is a fundamental fact of DNS 🧚 It follows mathematically from how the system is built, plus the resource identification needs of the Internet. Which DNS server is authoritative for a specific domain is set by delegations from the parent domain. That repeats recursively until you hit the so-called root zone, which is handled by a well-known set of DNS servers 🌳

Heads up: words like "authoritative" and "delegation" (and their variations) are used here in their specific, technical, DNS sense 🤓 They might not mean what they normally would in an ITU context.

Start from that well-known root zone, and every party querying DNS ends up at the same set of servers for the same domain. It doesn't matter who sends the query, when they send it, or where in the network it starts 🦋 In May 2000 the IAB published a document on the need for a single root in the DNS, and this section goes deeper into those issues. See RFC 2826 (http://www.ietf.org/rfc/rfc2826.txt). 📖

2.3. Storing E.164 numbers in the DNS

An E.164 number is also globally unique, so it has most of the same properties as a domain name 🔥 That's why storing E.164 numbers in DNS is technically a simple mapping. ENUM is just that: a way to store E.164 numbers in DNS.

Now the tea ☕ If there were multiple ENUM trees in the DNS hierarchy, it would be like letting every carrier assign a different meaning to an E.164 country code. Each one could map the same number to a different circuit, or reject it entirely 💀 On the Internet, if there were multiple trees, there'd be no way to figure out which domains might contain ENUM records. So every application using ENUM would have to be manually configured with a list of domains to search. That brings back the same scaling and update problems that led to the development of DNS in the first place 😭

The goal with ENUM is that one party can look up information in DNS that another party stored in DNS ✨ This must be possible with only the E.164 number as input to the algorithm.

Here's the puzzle 🧩 If the party storing info in DNS has two (or more) places to choose from and picks one, how does a second party doing the lookup know which place was picked? Imagine you only knew "www.whitehouse" and not the TLD, and you asked people to go to that website. Is the correct domain name www.whitehouse.gov, www.whitehouse.com, or www.whitehouse.se? It should be noted that www.whitehouse.com exists, and it's a pornography site 🙈

So the only way to know where to look up E.164/ENUM numbers in DNS is to use one and only one domain, and have everyone agree on what that domain is 🎯 ENUM is a system for E.164 numbers in their general, global context. Nothing technical can, or should, try to stop parties who want to use ENUM-like mechanisms (or other systems with the same general structure as telephone numbers) from working out private, out-of-band agreements to support those apps. Still, those apps are neither E.164 nor ENUM, any more than internal extension numbers in a PBX are normally considered part of either 📞💜

3. Why .ARPA was selected as the top level domain for ENUM 🦋

3.1. Introduction

This memo is one of a series the IETF gave to SG2 💌 It gives background on the IETF's ENUM Working Group deliberations and decisions. This one covers the IETF's decision that the ENUM DNS tree would use the .ARPA top level domain. Slay ⚡

3.2. IAB Statement on Infrastructure Domain and Subdomains

(Taken from http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt, May 2000.)

Over the last several months, the IAB has been reviewing, and discussing with ICANN and other parties, how to handle various Internet Protocol-related infrastructure components. The community has concluded these should be placed into the DNS 🧠

Historically, the most visible infrastructure domain has been the IPv4 address reverse-mapping domain 👀 It was placed in in-addr.arpa as part of the initial ARPANET transition strategy from host table naming (see RFC 881-http://www.ietf.org/rfc/ rfc0881.txt). Apart from the IPv4 reverse-mapping subdomain, it became the only active subdomain of that domain, as the <host-table-name>.ARPA names that were part of the transition were gradually removed. Other infrastructure domains were, in the past, placed under the "INT" TLD and various organizational names 🗃️

For general Internet stability, it's important to pay adequate attention to where secondary DNS servers go, plus administrative cleanliness 🧹 So the IAB wants to start rationalizing this by putting new infrastructure subdomains in a single domain, and moving existing ones there as appropriate. It looks like the original infrastructure domain "ARPA" is best suited for this. It was redesignated from an abbreviation for "ARPANET" to an acronym for "Address and Routing Parameters Area" 💖

3.3. Infrastructure subdomains

Operationally, DNS is way easier to keep stable if there are as few DNS zones as possible used for infrastructure parameters 🧚‍♀️ Today, new infrastructure domains go in ARPA, and old assignments made in other domains are being migrated to ARPA. Right now ARPA is used for in-addr.arpa (reverse mapping of IPv4 addresses), ip6.arpa (reverse mapping of IPv6 addresses), and e164.arpa (the subject of this memo). In the future, URI schemes, URN namespaces, and other new address families will be stored in ARPA too 🌈

In theory, each set of infrastructure parameters could get its own domain as a TLD. For example, .URI, .UNI, or .IPV6 could each be a new TLD. But new TLDs can only be created through the ICANN process, which might take a year or more 🐢 Doing that for every parameter set would unnecessarily and undesirably flatten the DNS tree 😤 It's much easier to have one TLD with easily created new subdomains (2nd level domains), one for each parameter. So it was logical to store E.164 numbers in ARPA 🎀

3.4. The ARPA domain (derived from RFC 3172, September 2001) 🦋

okay so the "arpa" domain has been around since the very beginning of DNS. It was set up as a transition mechanism away from the Host Tables that the ARPANET used to rely on 🕰️ It also got a permanent home for IPv4 address-to-name mappings (the "reverse mappings") that used to live in those Host Tables too. The Internet Architecture Board (IAB), working with the Internet Corporation for Assigned Names and Numbers (ICANN), is the one currently in charge of the Top Level Domain (TLD) "arpa" 👑 That setup is written down in Appendix A of RFC 3172. This domain is the root of the name hierarchy for reverse mapping of IP addresses to domain names, and it's also a limited-use domain for Internet infrastructure applications. It gives protocol values a name root so they can be mapped to names of service entities, and it provides a name root for turning protocol values into lookup keys that fetch operationally critical protocol infrastructure data records or objects for the Internet. literally the backbone 🧚

The IAB may add other infrastructure uses to the "arpa" domain in the future. Any of those additions or changes will follow the procedures in Section 2.1 and Section 3 of this document. [referring to RFC 3172] This domain is called an "infrastructure domain" because its whole job is supporting the operating infrastructure of the Internet 🌸 So the "arpa" domain is not to be used the same way other generic Top Level Domains are often used, like for naming hosts. main character energy, but make it infrastructure 💅

The operational administration of this domain has to be handled by the IANA under the terms of the MoU between the IAB and ICANN concerning the IANA [RFC 2860], following the provisions in this document.

3.5. Assignment of the .ARPA top level domain 🎀

As documented in appendix A of RFC 3172, on April 28, 2000, the US Department of Commerce told ICANN to run the .ARPA TLD under the guidance of the IAB. This was done under the authority of its purchase order with ICANN, and the domain was meant to be a limited-use domain for Internet infrastructure applications ✨

3.6. Name Server Requirements for .ARPA (from RFC 3172) 🔥

ngl this part is so serious, bestie. Since this domain is part of the operationally critical infrastructure of the Internet, how stable, safe, and efficient its operation is matters to every Internet user 🫶

The "arpa" domain sits at the top level so it can avoid operational instability. Otherwise you'd need multiple DNS lookups across several operational domains just to find the servers for each parent name of a more deeply nested infrastructure name 🙈 The maximal lookup set for ARPA is one lookup: ask a root server for the name servers of the "arpa" domain, and the query agent then gets a list of authoritative "arpa" name servers. efficient and iconic 🧚

The efficient and correct operation of the "arpa" domain is considered critical enough that the operational requirements for the root servers apply to the "arpa" servers too. All the operational requirements noted in RFC 2870, as they apply to the root servers, shall apply to the operation of the "arpa" servers. Any revision to RFC 2870 about operating the root servers shall also apply to the operation of the "arpa" servers 🔥

Many of the servers that are authoritative for the root zone (or the "." zone) also currently serve as authoritative for the "arpa" zone. As noted in RFC 2870, this arrangement is likely to change in the future 🌈

3.7. Summary: ENUM use of .ARPA 💖

The ARPA domain is the preferred TLD for infrastructure and parameter use 👑 The ENUM structure should be placed in a single domain subtree (see separate contribution, COM 2-11). It's expected to grow into important Internet infrastructure, so it should be placed there too 🦋 This decision is backed by the MOU between ICANN and IETF and by the instructions from the US Government to ICANN, which provide for IAB supervision of that domain.

Now, there's some confusion because the name matches a US Department of Defense agency, DARPA. But these uses are consistent with all of the historical uses of the ARPA domain, which have always been for infrastructure purposes 🙄 That goes back to when the hierarchical DNS was created to replace the old flat namespace of the ARPANET. The domain was never used for any internal or specific DARPA purpose, so no drama there 💅

Recognizing the potential difficulties with multiple infrastructure domains, the Internet Architecture Board concluded in May 2000 that all new infrastructure information was to be stored in the ARPA domain, and existing infrastructure subtrees were to be migrated there as feasible. For more context on these decisions, see http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt 🧚

The ENUM Working Group decided to follow that recommendation 🎉

4. The selection of an operator for E164.ARPA 🌸

4.1. Introduction 🎀

This contribution is one of a series the IETF provided to SG2 so they'd have background info on the IETF's ENUM Working Group deliberations and decisions. This particular one covers how the IETF picked an operator for the E164.ARPA domain ✨

4.2. Name server operator requirements 👑

RFC 2870 (http://www.ietf.org/rfc/rfc2780.txt) describes the requirements for operating DNS root servers 💅 Important DNS-based infrastructure services need their servers run with the same level of attention to reliability and security that the root servers get. For an infrastructure service like E164.ARPA, the IAB also felt some extra requirements were important. Organizations that run core services like IN-ADDR.ARPA and E164.ARPA must have a history of reliable DNS server operation, and they must be highly respected for both their technical skills and their fairness and impartiality 🫶

The IAB also felt the organization running infrastructure domains must be non-profit and public-service-oriented. That removes any incentive for exploitative, profit-driven behavior, like depending on the number of records in the database, even if a reasonable registration fee is charged to recover costs 🙈 They also wanted an organization with good, extensive experience working with governments when necessary, and one with experience working with the IAB and the IETF more generally 🦋

4.3. Evaluating possible operators 🔥

The IAB looked into various operator options and concluded that the regional IP address registries (RIRs) met all of the criteria. They all had extensive experience providing and supporting infrastructure services reliably and securely, and all three had a long history of working with the IETF 🌈

4.4. Selecting a particular operator 💖

Since all of the RIRs would have met the criteria, picking one meant looking at other factors. The IAB concluded that RIPE NCC would be the best operator for E164.ARPA. That was based largely on their somewhat greater experience running DNS servers and on their location in a neutral legal jurisdiction 🧚

4.5. Country administration of cc subdomains ✨

Of course, once a subdomain associated with a country code is assigned for registration and operations to an appropriately designated entity for the associated country or numbering plan, administration of that subdomain is entirely a National Matter. No involvement is anticipated from the IAB/IETF, the E164.ARPA registry, or the ITU 🌸

5. Procedures to be followed by RIPE NCC 🎀

The IAB and the RIPE NCC have agreed on procedures for RIPE NCC to follow when making ENUM registrations at the country code level 💅 Those instructions are expected to evolve as experience builds up. The current versions will be posted on the IAB and/or RIPE NCC web sites 🫶

6. References 🦋

6.1. Normative references 🔥

None. This document is intended to be self-contained and purely informational 🙈

6.2. Informative and explanatory references. 👑

  • [RFC 2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000.
  • [RFC 2870] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000.
  • [RFC 2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
  • [RFC 3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ('arpa')", BCP 52, RFC 3172, September 2001.

7. Security Considerations 🔒

This document provides information only and raises no new security issues 🫶 The security issues associated with the underlying protocols are described in RFC 2916. Go check that one out, it's the real deal 💀

8. IANA Considerations 🌈

There are no IANA considerations regarding this document. Sections 3 and 4 contain a record of actions already performed by IANA, along with partial explanations for them ✨

9. Authors' Addresses 💌

Internet Architecture Board EMail: iab@iab.org

Membership at time this document was completed:

  • Harald Alvestrand
  • Ran Atkinson
  • Rob Austein
  • Fred Baker
  • Steve Bellovin
  • Brian Carpenter
  • Jon Crowcroft
  • Leslie Daigle
  • Steve Deering
  • Sally Floyd
  • Geoff Huston
  • John Klensin
  • Henning Schulzrinne

Scott Bradner EMail: sob@harvard.edu

Patrik Faltstrom EMail: paf@cisco.com

Copyright (C) The Internet Society (2002). All Rights Reserved. Okay, legal stuff, but it's pretty chill 🌙

This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or that help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind. The condition is that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's needed to translate it into languages other than English 🫶

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns 💖

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 🙈

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 🎀

📦 where this page comes from