ENUM Validation Architecture
RFC 4725

Document Type RFC - Informational (November 2006; No errata)
Last updated 2013-03-02
Replaces draft-mayrhofer-enum-validation-arch
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 4725 (Informational)
Telechat date
Responsible AD Jon Peterson
Send notices to enum-chairs@ietf.org
Network Working Group                                       A. Mayrhofer
Request for Comments: 4725                                       enum.at
Category: Informational                                     B. Hoeneisen
                                                                  Switch
                                                           November 2006

                      ENUM Validation Architecture

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.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   An ENUM domain name is tightly coupled with the underlying E.164
   number.  The process of verifying whether or not the Registrant of an
   ENUM domain name is identical to the Assignee of the corresponding
   E.164 number is commonly called "validation".  This document
   describes validation requirements and a high-level architecture for
   an ENUM validation infrastructure.

Mayrhofer & Hoeneisen        Informational                      [Page 1]
RFC 4725              ENUM Validation Architecture         November 2006

Table of Contents

   1. Introduction ....................................................3
   2. Requirements ....................................................3
   3. ENUM Provisioning Model and Roles ...............................4
      3.1. Number Assignment Entity (NAE) .............................5
      3.2. Assignee ...................................................7
      3.3. Registrant .................................................7
      3.4. Validation Entity (VE) .....................................7
      3.5. Registry ...................................................8
      3.6. Registrar ..................................................8
      3.7. Domain Name System Service Provider (DNS-SP) ...............8
      3.8. Application Service Provider (ASP) .........................8
   4. Validation Process Assumptions ..................................9
      4.1. Workflow ...................................................9
      4.2. Trust Relations ...........................................10
      4.3. Data Flow and Format ......................................11
   5. Example Scenarios ..............................................11
      5.1. E.164 Number Assignment along with ENUM Registration ......11
      5.2. Fully Disjoint Roles ......................................13
   6. Security Considerations ........................................14
      6.1. Fraud Prevention ..........................................14
      6.2. Assignee Data .............................................14
   7. Acknowledgements ...............................................15
   8. References .....................................................15
      8.1. Normative References ......................................15
      8.2. Informative References ....................................15

Mayrhofer & Hoeneisen        Informational                      [Page 2]
RFC 4725              ENUM Validation Architecture         November 2006

1.  Introduction

   E.164 Number Mapping (ENUM) [1] uses the Domain Name System (DNS) [4]
   to refer from E.164 numbers [2] to Uniform Resource Identifiers
   (URIs) [3].  E.164 numbers are mapped to domain names through means
   described further in RFC 3761 [1].

   "Ordinary" domain names are usually allocated on a first-come-first-
   served basis, where the associated registration data is the complete
   source of ownership.  However, ENUM domain names are linked to E.164
   numbers, and thus intrinsically tied to the status and the "Assignee"
   (defined in Section 3.2) of the corresponding E.164 number.

2.  Requirements

   Preserving integrity between ENUM and E.164 is one of the main
   concerns in ENUM implementations, and often one of the reasons why
   "trials" precede commercial implementations.

   To maintain this relationship between E.164 numbers and ENUM domain
   names, registration processes must ensure that the following
   requirements are fulfilled during the entire lifetime of an ENUM
   delegation:

   o  The ENUM domain name corresponds either to an assigned E.164
      number or to a respective E.164 number that is assigned during the
      registration process itself.

   o  The corresponding E.164 number is within a number range approved
      to be used with ENUM.

   o  The registration of the ENUM domain name is authorized by the
      Assignee of the corresponding E.164 number; i.e., the entity
      requesting the registration of an ENUM domain name is either the
Show full document text