RFC 5067

RFC 5067 🎀 Infrastructure ENUM Requirements

Okay bestie, this one is from November 2007 and it's an Informational doc (so it's giving advice, not a binding standard 💅). Written by Steven Lind and Penn Pfautz, both at AT&T. It doesn't obsolete or update anything. The whole vibe is about how carriers can use ENUM (the E.164 number-to-URI mapping system from RFC 3761) for interconnection. Let's go ✨

1. Infrastructure ENUM ✨

1.1. Definition

Okay so infrastructure ENUM is basically when the carrier-of-record (the provider in charge of a given E.164 number) uses RFC 3761 tech to publish a mapping from that number to a URI 📞 that points to their own interconnection point. This is totally separate from any URIs an end user might want tied to their number. Main character energy for carriers, fr fr 💖

It's giving contrast with End User ENUM (also RFC 3761 🦋), where the person or entity who has the right to use the number calls all the shots about the domain and zone content. In infrastructure ENUM, the carrier-of-record is the one with that discretion and acts as the registrant 👑. The carrier-of-record is:

• The Service Provider the E.164 number was allocated to for end user assignment, whether by the National Regulatory Authority (NRA) or the International Telecommunication Union (ITU). Examples are a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878). Or,
• If the number got ported, the service provider it was ported to. Or,
• Where numbers are assigned straight to end users, the service provider the end user chose to provide a Public Switched Telephone Network/Public Land Mobile Network (PSTN/PLMN) point-of-interconnect for the number 🧚.

Ngl, the definition of carrier-of-record can be changed by national authorities in a given jurisdiction 🌍.

1.2. Background

Voice service providers still use E.164 numbers as their main naming and routing thing 📱. Infrastructure ENUM in e164.arpa (or another public tree) lets providers link Internet resources like URIs to E.164 numbers 🔗. This means providers can peer over IP-based protocols as well as interconnect over the PSTN/PLMN, or even only over IP 🌸.

Providers can announce every E.164 number or number range they host, whether the final end user device is on the Internet, on IP-based open or closed Next Generation Networks (NGNs), or on the PSTN or PLMN. The one condition is that some kind of access point to the destination provider's network has to be available on the Internet 🙈. There's also no guarantee the originating provider querying infrastructure ENUM can reach the destination provider's ingress network element. Extra peering and accounting agreements that need authentication might be necessary 💀. The access might also go to a shared network of several providers, which resolves the final destination network inside that shared network 🫶.

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, RFC2119 [4]. Those are the official requirement words, so read them carefully 🎀.

3. Requirements for Infrastructure ENUM 💅

1. Infrastructure ENUM SHALL provide a means for a provider to populate DNS resource records (RRs) for the E.164 numbering resources for which it is the carrier-of-record in a single common publicly accessible namespace. That single common namespace might or might not be the same one designated for End User ENUM (e164.arpa.). The Fully-Qualified Domain Name (FQDN) in the resulting resource records will not necessarily belong to or identify the carrier-of-record 🦋.
2. Queries of infrastructure ENUM fully qualified domain names MUST return a result, even if the result is Refused (RCODE = 5). Queries must not be rejected without response, e.g., based on access control lists 🙅‍♀️.
3. Infrastructure ENUM SHALL support RRs providing a URI that can identify a point of interconnection for delivery to the carrier-of-record of communications addressed to the E.164 number 🧚.
4. Infrastructure ENUM SHOULD be able to support an Internet Registry Information Service (IRIS) [5] capability that lets qualified parties get information about the E.164 numbering resources and the matching carrier-of-record. Deciding what information, if any, is available to which parties for geographic numbers is a national matter 🌍.
5. Implementation of infrastructure ENUM MUST NOT restrict the ability of an end user, in a competitive environment, to choose a Registrar and/or name server provider for End User ENUM registrations 👑.
6. The domain name chosen for infrastructure ENUM and any parent domains MUST be hosted on name servers that have performance characteristics and supporting infrastructure comparable to those deployed for the Internet root name servers. Those name servers for infrastructure ENUM should be configured and operated according to the guidelines described in [6] 🌸.
7. Infrastructure ENUM MUST meet all reasonable privacy concerns about visibility of information over which an end user has no control. It SHOULD, for example, support mechanisms to prevent discovery of unlisted numbers by comparison of ENUM registrations against directory listings, or inadvertent disclosure of user identity 🙈.
8. Proposed implementations of infrastructure ENUM SHOULD:

A. Minimize changes required to existing requirements that are part of RFC 3761.

B. Work with open as well as closed numbering plans.

C. Not require additional functionality of resolvers at large, though they may require additional functionality in service provider resolvers that would make use of infrastructure ENUM.

D. Minimize the number of lookups required to obtain as many NAPTR (Naming Authority Pointer) records (end user and infrastructure) as possible.

E. Minimize knowledge of the numbering plan required of resolvers making use of Infrastructure ENUM.

F. Maximize synergies with End User ENUM.

G. Support interworking with private ENUM trees. (In this context, a private ENUM tree is one that is not under e164.arpa or whatever namespace is chosen for infrastructure ENUM, but instead uses a privately held domain 💜.)

4. Security Considerations 💀

Okay this part is serious, bestie 😭. Existing security considerations for ENUM (detailed in [1]) still apply. Since infrastructure ENUM involves carriers, while RFC 3761 mainly considered individuals, implementations meeting these requirements SHOULD reconsider the RFC 3761 security model given this difference in actors. Some registration validation issues for End User ENUM may not apply to infrastructure ENUM. Where the Tier 1 registry is able to identify the provider serving a number (for example, from industry data for number block assignments and number portability), registration might be easier to automate and a separate registrar might not be required 🔥.

Some parties are worried that infrastructure ENUM could compromise end user privacy by letting others identify unlisted or unpublished numbers based on their ENUM registration 😱. This can be avoided if providers register all of their allocated (as opposed to assigned) numbers. Unassigned numbers SHOULD be provisioned to route to the provider's network the same way assigned numbers are, and only then give an indication that they are unassigned. That way, a provider's registration of a number in ENUM gives no more information about the number's status than dialing it would 🫶.

Implementers should take care to avoid inadvertent disclosure of user identities, for example in the URIs returned in response to infrastructure ENUM queries 🙈.

5. IANA Considerations 🌈

This document includes no actions to be taken by IANA. The architecture ultimately chosen to meet the requirements may require IANA actions 🧚.

6. Normative References 📚

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

[2] International Telecommunication Union-Telecommunication Standardization Sector, "The International Public Telecommunication Numbering Plan", Recommendation E.164", February 2005.

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

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

[5] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.

[6] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000.

Authors' Addresses 💖

Steven Lind AT&T Labs 180 Park Ave Florham Park, NJ 07932-0971 USA

EMail: sdlind@att.com

Penn Pfautz AT&T 200 S. Laurel Ave Middletown, NJ 07748 USA

EMail: ppfautz@att.com

Full Copyright Statement ✨

okay so this part is the legal bit, but make it cute 🎀 Copyright (C) The IETF Trust (2007). this doc is subject to the rights, licenses and restrictions in BCP 78, and unless BCP 78 says otherwise, the authors keep all their rights 💅

the doc and everything in it is given to you "AS IS" 🫶 and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 💀

---

Intellectual Property

okay the IETF is being very honest here 🧚 it does not take a position on whether any Intellectual Property Rights (or other rights) that someone might claim over the tech in this doc are valid or in scope, and it also doesn't say whether a license for those rights is actually available. it hasn't independently gone hunting for those rights either 🔍 if you want the procedures for rights in RFC docs, check out BCP 78 and BCP 79 ✨

if you want copies of IPR disclosures that were sent to the IETF Secretariat, or any assurances of licenses, or the result of trying to get a general license or permission for implementers or users of this spec to use those proprietary rights, the place to look is the IETF on-line IPR repository at http://www.ietf.org/ipr 🌸

and bestie, the IETF is literally asking everyone 🫶 if you know of any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard, please tell them at ietf-ipr@ietf.org. the IETF wants to hear from you 💖