Infrastructure ENUM Requirements
How phone companies connect their networks using internet technology.
Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC 5067, DOI 10.17487/RFC5067, November 2007, <https://www.rfc-editor.org/info/rfc5067>.
@misc{rfc5067,
series = {Request for Comments},
number = 5067,
howpublished = {RFC 5067},
publisher = {RFC Editor},
doi = {10.17487/RFC5067},
url = {https://www.rfc-editor.org/info/rfc5067},
author = {S. Lind and P. Pfautz},
title = {{Infrastructure ENUM Requirements}},
pagetotal = 7,
year = 2007,
month = nov,
} RFC text
Contents
Network Working Group S. Lind
Request for Comments: 5067 AT&T Labs
Category: Informational P. Pfautz
AT&T
November 2007
Infrastructure ENUM Requirements
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document provides requirements for "infrastructure" or "carrier"
ENUM (E.164 Number Mapping), defined as the use of RFC 3761
technology to facilitate interconnection of networks for E.164 number
addressed services, in particular but not restricted to VoIP (Voice
over IP.)
Table of Contents
1. Infrastructure ENUM . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for Infrastructure ENUM . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 5
1. Infrastructure ENUM
1.1. Definition
Infrastructure ENUM is defined as the use of the technology in RFC
3761 [1] by the carrier-of-record (as defined below) for a specific
E.164 number [2] to publish the mapping of the E.164 number into a
URI [3] that identifies a specific point of interconnection to that
service provider's network. It is separate from any URIs that the
end user, who registers their E.164 number, may wish to associate
with that E.164 number.
"Infrastructure ENUM" is distinguished from "End User ENUM", defined
in RFC3761 [1], in which the entity or person having the right to use
a number has the sole discretion about the content of the associated
domain and thus the zone content. From a domain registration
perspective, the end user number assignee is thus the registrant.
Within the infrastructure ENUM namespace, we use the term "carrier-
of-record" for the entity having discretion over the domain and zone
content and acting as the registrant. The "carrier-of-record" is:
o The Service Provider to which the E.164 number was allocated for
end user assignment, whether by the National Regulatory Authority
(NRA) or the International Telecommunication Union (ITU), for
instance, a code under "International Networks" (+882) or "Universal
Personal Telecommunications (UPT)" (+878) or,
o if the number is ported, the service provider to which the number
was ported, or
o where numbers are assigned directly to end users, the service
provider that the end user number assignee has chosen to provide a
Public Switched Telephone Network/Public Land Mobile Network (PSTN/
PLMN) point-of-interconnect for the number.
It is understood that the definition of carrier-of-record within a
given jurisdiction is subject to modification by national
authorities.
1.2. Background
Voice service providers use E.164 numbers currently as their main
naming and routing vehicle. Infrastructure ENUM in e164.arpa or
another publicly available tree allows service providers to link
Internet-based resources such as URIs to E.164 numbers. This allows
service providers, in addition to interconnecting via the PSTN/PLMN
(or exclusively), to peer via IP-based protocols. Service providers
may announce all E.164 numbers or number ranges they host, regardless
of 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, provided that an access point of some type to the destination
service provider's network is available on the Internet. There is
also no guarantee that the originating service provider querying
infrastructure ENUM is able to access the ingress network element of
the destination provider's network. Additional peering and
accounting agreements requiring authentication may be necessary. The
access provided may also be to a shared network of a group of
providers, resolving the final destination network within the 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].
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. The single common
namespace ultimately designated may or may not be the same as
that 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 allows
qualified parties to obtain information regarding the E.164
numbering resources and the corresponding carrier-of-record.
Determination of what information, if any, shall be available
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 that is 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 uses instead a privately held domain.)
4. Security Considerations
Existing security considerations for ENUM (detailed in [1]) still
apply. Since infrastructure ENUM involves carriers where RFC 3761
mainly considered indviduals, implementations meeting these
requirements SHOULD reconsider the RFC 3761 security model given this
difference in actors concerned. Note that some registration
validation issues concerning End User ENUM may not apply to
infrastructure ENUM. Where the Tier 1 registry is able to identify
the provider serving a number, e.g., based on industry data for
number block assignments and number portability, registration might
be more easily automated and a separate registrar not required.
Some parties have expressed concern that an infrastructure ENUM could
compromise end user privacy by making it possible for others to
identify unlisted or unpublished numbers based on their registration
in ENUM. This can be avoided if providers register all of the their
allocated (as opposed to assigned) numbers. Unassigned numbers
should be provisioned to route to the provider's network in the same
fashion as assigned numbers and only then provide an indication that
they are unassigned. In that way, provider registration of a number
in ENUM provides no more information about the status of a number
than could be obtained by dialing it.
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
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis 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
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
AI ELI5
On this page
§1What Infrastructure ENUM Is
Infrastructure ENUM is the use of ENUM (E.164 Number Mapping) technology for carriers to publish connection information for their phone number blocks. ENUM, defined in RFC 3761, normally lets individual phone users map their numbers to internet addresses. Infrastructure ENUM applies the same technology at the carrier level.
The carrier-of-record is the phone company that owns or controls a block of phone numbers. This could be the company that originally got the numbers from regulators, the company the numbers were ported to, or the company chosen by the end user. The carrier publishes where to find their network's entry point so other carriers can deliver calls to them.
Infrastructure ENUM is like a special phonebook just for phone companies that shows where their network is on the internet.
§2Why Carriers Need It
Historically, phone companies connected through the Public Switched Telephone Network (PSTN) or wireless networks (PLMN). These are traditional telephone infrastructures. But modern voice services increasingly run on the internet.
Infrastructure ENUM in a public tree (like e164.arpa) lets carriers announce all the phone numbers they serve and point to an internet address where calls can reach them. A carrier can do this whether the end user is on the internet, on a private IP network, or still connected to the traditional phone network. Other carriers can query the ENUM records to find the best way to deliver a call.
This gives carriers flexibility: they can peer with each other via IP without needing direct phone line connections, and they can offer services across both old and new technologies.
Phone companies can now connect to each other over the internet, not just through old phone network cables. Infrastructure ENUM helps them find each other.
§3What Infrastructure ENUM Must Do
The RFC lists eight key requirements. First, carriers must be able to put DNS records for their numbers into a single public namespace, and queries must always get a response (not be silently rejected). Second, the system must support URI records that identify where to send calls.
Third, the system should support IRIS (Internet Registry Information Service) so authorized parties can look up which carrier owns each number block. Fourth, it must not interfere with end users' ability to choose their own registrars for personal ENUM entries.
Fifth, the name servers must be as reliable and fast as the internet root servers. Sixth, the system must protect privacy by preventing discovery of unlisted numbers. Finally, new proposals should minimize changes to RFC 3761, work with both open and closed numbering systems, and maximize compatibility with existing ENUM deployments.
The system needs to always answer queries, keep things private, be super reliable, and not break anything that already works.
§4Privacy and Security Concerns
The main security issue is privacy: if a carrier registers only the phone numbers it has assigned to customers, someone could discover unlisted or unpublished numbers by comparing ENUM entries to public directories. The RFC recommends that carriers register their entire allocated range—both assigned and unassigned numbers—routed the same way. This way, a number appearing in ENUM reveals no more than dialing it would.
Another concern is identity disclosure in the URIs returned. If a company publishes URIs that reveal customer names or details, the ENUM system could leak private information. Implementers must be careful not to expose unnecessary details.
The RFC notes that infrastructure ENUM involves carriers rather than individuals, so the security model from the original RFC 3761 may need reconsideration. Where a registry can automatically identify which carrier serves a number, registration might be automated without requiring separate registrars.
The tricky part is making sure bad actors can't figure out which phone numbers are real just by looking at the ENUM records.
§5Status and Implementation Notes
This RFC is informational: it describes requirements, not a working protocol. The actual architecture to meet these requirements would be designed by others and might require IANA actions later. The document was written by AT&T Labs to guide the design of infrastructure ENUM systems.
Key implementation notes include recognizing that the definition of carrier-of-record varies by jurisdiction and is subject to change by national regulators. The system must be flexible enough to work with different regulatory frameworks. Implementations should also consider that the infrastructure ENUM namespace might be different from the end-user ENUM tree and could be privately operated rather than public.
This document says what needs to happen, but doesn't specify exactly how. Real systems will fill in those details.