One document matched: draft-ietf-enum-3761bis-08.xml

<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='http://greenbytes.de/tech/webdav/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY  RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY  RFC2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY  RFC3492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3492.xml">
<!ENTITY  RFC3987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.xml">
<!ENTITY  RFC3833 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3833.xml">
<!ENTITY  RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">

<!ENTITY  RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">


<!ENTITY  RFC2915 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2915.xml">
<!ENTITY  RFC2916 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2916.xml">

<!ENTITY  RFC3401 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3401.xml">
<!ENTITY  RFC3402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3402.xml">
<!ENTITY  RFC3403 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3403.xml">
<!ENTITY  RFC3404 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3404.xml">

<!ENTITY  RFC3761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3761.xml">

<!ENTITY  RFC5483 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5483.xml">

<!ENTITY  RFC3824 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3824.xml">
]>
<?rfcedstyle='yes'?>
<?rfc rfcedstyle='yes'?>
<?rfc compact='yes'?>
<?rfc subcompact='yes'?>
<?rfc toc='yes'?>
<?rfc tocdepth='5'?>
<?rfc tocindent='no'?>
<?rfc tocompact='yes'?>
<?rfc footer=' '?>
<?rfc comments='no'?>
<?rfc inline='no'?>
<?rfc strict='yes'?>
<?rfc sortrefs='yes'?>
<?rfc symrefs='yes'?>
<rfc ipr="trust200902" category="std" obsoletes="3761" docName="<draft-ietf-enum-3761bis-08.txt>">
<front>
<title abbrev="3761bis">The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)</title>

<!-- ************** Scott Bradner ***************-->
<author initials="" surname="Scott Bradner" fullname="Scott Bradner">
<organization abbrev="Harvard University">Harvard University</organization>
<address>
    <postal>
        <street>29 Oxford St.</street>
        <city>Cambridge MA 02138</city>
        <country>USA</country>
    </postal>
    <phone>+1-617-495-3864</phone>
    <email>sob@harvard.edu</email>
</address>
</author>

<!-- ************** Lawrence Conroy ***************-->
<author initials="" surname="Lawrence Conroy" fullname="Lawrence Conroy">
<organization abbrev="Roke Manor Research">Roke Manor Research</organization>
<address>
    <postal>
        <street>Roke Manor</street>
        <street>Old Salisbury Lane</street>
        <city>Romsey</city>
        <country>United Kingdom</country>
    </postal>
    <phone>+44-1794-833666</phone>
    <email>lconroy@insensate.co.uk</email>
    <uri>http://www.sienum.co.uk</uri>
</address>
</author>

<!-- ************** Kazunori Fujiwara ***************-->
<author initials="" surname="Kazunori Fujiwara" fullname="Kazunori Fujiwara">
<organization abbrev="Japan Registry Service Co., Ltd.">Japan Registry Service Co., Ltd.</organization>
<address>
    <postal>
        <street>Chiyoda First Bldg. East 13F</street>
        <street>3-8-1 Nishi-Kanda Chiyoda-ku</street>
        <city>Tokyo 101-0165</city>
        <country>JAPAN</country>
    </postal>
    <email>fujiwara@jprs.co.jp</email>
    <uri>http://jprs.jp/en/</uri>
</address>
</author>

<date day="04" month="June" year="2010" />
<area>RAI</area>
<workgroup>ENUM</workgroup>
<keyword>DNS</keyword>
<keyword>E.164</keyword>
<keyword>NAPTR</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Protocol Standard</keyword>

<abstract>
<t>This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC3761.</t>
</abstract>

</front>


<middle>

<section anchor="I-D-Intro" title="Introduction">

<t>This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 <xref target="E.164"></xref> numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document includes a Dynamic Delegation Discovery System (DDDS) Application specification, as detailed in the document series described in <xref target="RFC3401"></xref>. This document obsoletes <xref target="RFC3761"></xref>.</t>

<t>Using the process defined in this document, International Public Telecommunication Numbers in the international format defined in ITU Recommendation E.164 <xref target="E.164"></xref> (called here "E.164 numbers") can be transformed into DNS names. Using existing DNS services (such as delegation through NS records and queries for NAPTR resource records), one can look up the services associated with that E.164 number. This takes advantage of standard DNS architectural features of decentralized control and management of the different levels in the lookup process.</t>

<t>The domain "e164.arpa" has been assigned to provide an infrastructure in the DNS for storage of data associated with E.164 numbers. To facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers who want the numbers to be listed in the DNS should contact the appropriate zone administrator as listed in the policy attached to the zone. One should start looking for this information by examining the SOA resource record associated with the zone, just like in normal DNS operations.</t>

<t>Of course, as with other domains, policies for such listings will be controlled on a subdomain basis and may differ in different parts of the world.</t>


<section anchor="Terminology" title="Terminology">

<t>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 <xref target="RFC2119">BCP 14, RFC 2119</xref>.</t>

<t>All other capitalized terms are taken from the vocabulary found in the DDDS algorithm specification found in <xref target="RFC3402"></xref>.</t>

</section>


</section> <!-- section 1 -->

<section anchor="Prohibition" title="Use of These Mechanisms for Private Dialling Plans">

<t>Similar mechanisms might be used for other kinds of digit strings (such as numbers in private dialling plans). If these mechanisms are used for dialling plans (or for other unrelated digit strings), the domain apex used for such translation MUST NOT be e164.arpa, to avoid conflict with this specification.</t>

<t>Also, the Application Unique String (see <xref target="AUS" />) used with dialling plans SHOULD be the full number as specified, without the leading '+' character. The '+' character is used to further distinguish E.164 numbers in international format from dialled digit strings or other digit sequences.</t>
<t><list style='empty'>
<t>For example, to address the E.164 number +44-3069-990038 a user might dial "03069990038" or "00443069990038" or "011443069990038". These dialled digit strings differ from one another, but none of them start with the '+' character.</t>
</list>
</t>

<t>Finally, if these techniques are used for dialling plans or other digit strings, implementers and operators of systems using these techniques for such purpose MUST NOT describe these schemes as "ENUM". The initial "E" in ENUM stands for E.164, and the term "ENUM" is used exclusively to describe application of these techniques to E.164 numbers according to this specification.</t>

</section> <!-- section 2 -->


<section anchor="DDDS-ENUM-Spec" title="The ENUM Application Specifications">


<t>This template defines the ENUM DDDS Application according to the rules and requirements found in <xref target="RFC3402"></xref>. The DDDS database used by this Application is found in <xref target="RFC3403"></xref>, which is the document that defines the NAPTR DNS Resource Record type.</t>

<t>ENUM is designed as a way to translate from E.164 numbers to URIs using NAPTR records stored in DNS. The First Well Known Rule for any ENUM query creates a key (a fully qualified domain name within the e164.arpa domain apex) from an E.164 number. This FQDN is queried for NAPTR records and returned records are processed and interpreted according to this specification.</t>

<section anchor="AUS" title="Application Unique String">

<t>The Application Unique String (AUS) is a fully qualified E.164 number minus any non-digit characters except for the '+' character which appears at the beginning of the number. The '+' is kept to provide a well understood anchor for the AUS in order to distinguish it from other telephone numbers that are not part of the E.164 namespace.</t>
<t>For example, the E.164 number could start out as "+44-116-496-0348". To ensure that no syntactic sugar is allowed into the AUS, all non- digits except for '+' are removed, yielding "+441164960348".</t>

</section>

<section anchor="1WKR" title="First Well Known Rule">

<t>The First Well Known Rule converts an Application Unique String (AUS) into an initial key. That key is used as an index into the Application's Rules Database. For ENUM, the rules database is the DNS, so the key is a fully qualified domain name (FQDN).</t>

<t>In order to convert the AUS to a unique key in this database the string is converted into a domain name according to this algorithm:</t>
<t>
<list style='numbers'>
<t>Remove all characters with the exception of the digits. For example, given the E.164 number "+44-20-7946-0148", this step would simply remove the leading '+', producing "442079460148".</t>
<t>Reverse the order of the digits. Example: "841064970244"</t>
<t>Put dots ('.') between each digit. Example: "4.4.2.0.7.9.4.6.0.1.4.8"</t>
<t>Append the string ".e164.arpa." to the end and interpret as a domain name. Example: 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.</t>
</list>
</t>
<t>The E.164 namespace and this Application's database are organized in such a way that it is possible to go directly from the name to the smallest granularity of the namespace directly from the name itself, so no further processing is required to generate the initial key.</t>
<t>This domain name is used to request NAPTR records. Each of these records may contain the end result or, if its flags field is empty, produces a new key in the form of a domain name that is used to request further NAPTR records from the DNS.</t>

</section>

<section anchor="Exit" title="Expected Output">

<t>The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the <absoluteURI> production in the Collected ABNF found in <xref target="RFC3986"></xref>.</t>

</section>

<section anchor="db" title="Valid Databases">

<t>At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" <xref target="RFC3403"></xref> specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain names.</t>
<t>The charset used for the substitution expression is UTF-8. The allowed input characters are all those characters that are allowed anywhere in an E.164 number. The characters allowed to be in a Key are those that are currently defined for DNS domain names.</t>

<section anchor="bindisms" title="Optional Name Server Additional Section Processing">

<t>Some nameserver implementations attempt to be intelligent about items that are inserted into the additional information section of a given DNS response. For example, BIND will attempt to determine if it is authoritative for a domain whenever it encodes one into a packet. If it is, then it will insert any A records it finds for that domain into the additional information section of the answer until the packet reaches the maximum length allowed. It is therefore potentially useful for a client to check for this additional information.</t>

<t>It is also easy to contemplate an ENUM enhanced nameserver that understands the actual contents of the NAPTR records it is serving and inserts more appropriate information into the additional information section of the response. Thus, DNS servers MAY interpret flag values and use that information to include appropriate resource records in the Additional Information section of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See Section 4.2 of <xref target="RFC3403"></xref> ("Additional Information Processing") for more information on NAPTR records and the Additional Information section of a DNS response packet.</t>

</section>

<section anchor="flags" title="Flags">

<t>This Database contains a field that contains flags that signal when the DDDS algorithm has finished. At this time only one flag, "U", is defined. This means that this Rule is the last one and that the output of the Rule is a URI <xref target="RFC3986"></xref>. See Section 4.3 of <xref target="RFC3404"></xref>.</t>
<t>If a client encounters a record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on fields.</t>
<t>A novel flag might change the interpretation of the Regexp and/or Replacement fields such that it is impossible to determine if a record matched a given target.</t>
<t>If this flag is not present then this rule is non-terminal. If a Rule is non-terminal then the result produced by its rewrite rule MUST be a FQDN. Clients MUST use this result as the new Key in the DDDS loop (i.e., the client will query for NAPTR records at this FQDN).</t>

</section>

<section anchor="services" title="Services Parameters">

<t>Service Parameters for this Application take the following form and are found in the Services field of the NAPTR record that holds a terminal rule. Where the NAPTR holds a non-terminal Rule, the Services field SHOULD be empty, and clients SHOULD ignore its content.</t>
<t>
<figure>
<artwork type='abnf'>
    service-field = "E2U" 1*(servicespec)
    servicespec   = "+" enumservice
    enumservice   = type 0*(subtypespec)
    subtypespec   = ":" subtype
    type          = 1*32(ALPHA / DIGIT / "-")
    subtype       = 1*32(ALPHA / DIGIT / "-")
</artwork>
</figure>
</t>
<t>In other words, a non-optional "E2U" (used to denote ENUM only Rewrite Rules in order to mitigate record collisions) followed by one or more Enumservices which indicate the class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character.</t>

<section anchor="Enumservices" title="ENUM Services">

<t>Enumservices may be specified and registered via the process defined in "IANA Registration of Enumservices: Guide, Template and IANA Considerations" <xref target="SV_GUIDE"></xref>. This registration process is not open to any Enumservice that has '-' as the second character in its type string.</t>
<t>In particular, this registration process is not open to Enumservice types starting with the facet "X-". This "X-" facet is reserved for experimental or trial use, and any such Enumservices cannot be registered using the normal process.</t>
<t>Finally, any Enumservice type that starts with the facet "P-" is intended for use exclusively on private networks. As such, NAPTRs containing Enumservice types starting "P-" should not be seen on the global Internet. Even if an ENUM client recognizes and can engage in the Enumservice, it may be incapable of resolving the URI generated by the containing NAPTR. These Enumservices WILL NOT be registered.</t>
<t>Such Enumservices MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets from entities outside the private network context in which these Enumservices are intended for use. Unless an ENUM client is sure that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet.</t>

</section>

<section anchor="compoundNAPTRs" title="Compound NAPTRs and Implicit ORDER/PREFERENCE Values">

<t>It is possible to have more than one Enumservice associated with a single NAPTR. These Enumservices share the same Regexp field and so generate the same URI. Such a "compound" NAPTR could well be used to indicate a mobile phone that supports both "voice:tel" and "sms:tel" Enumservices.
<vspace blankLines='0' />
The Services field in that case would be "E2U+voice:tel+sms:tel".</t>

<t>A compound NAPTR can be treated as a set of NAPTRs that each hold a single Enumservice. These reconstructed NAPTRs share the same ORDER and PREFERENCE/PRIORITY field values but should be treated as if each had a logically different priority. A left-to-right priority is assumed.</t>

</section>

</section>

</section>

<section anchor="OneRingToRuleThem" title="The ENUM Algorithm Always Returns a Single Rule">

<t>The ENUM algorithm always returns a single rule. Individual applications may have application-specific knowledge or facilities that allow them to present multiple results or speed selection, but these should never change the operation of the algorithm.</t>

</section>

<section anchor="almostInsensitive" title="Case Sensitivity in ENUM">

<t>The only place where NAPTR field content is case sensitive is in any static text in the Repl sub-field of the Regexp field (see Section 3.2 of <xref target="RFC3402"></xref> for Regexp field definitions). Everywhere else, case-insensitive processing SHOULD be used.</t>

</section>

<section anchor="collisionAvoidance" title="Collision Avoidance">

<t>An ENUM-complaint application MUST only pass numbers to the ENUM client query process that it believes are E.164 numbers (e.g. it MUST NOT pass dialled digit strings to the ENUM query process).</t>

<t>Since number plans may change over time, it can be impossible for a client to know if the number it intends to query is assigned and active within the current number plan. Thus it is important that such clients can distinguish data associated with the E.164 number plan from that associated with other digit strings (i.e. numbers NOT according to the E.164 number plan).</t>

<t>It is the responsibility of operators provisioning data into domains to ensure that data associated with a query on an E.164 number cannot be mistaken for data associated with other uses of NAPTRs.</t>

<!-- the e164.arpa domain apex MUST be used ONLY for domains holding content associated with E.164 numbers in international format, and MUST NOT be used for data associated with other digit strings (such as dialled numbers). -->

<t>Three techniques are used to achieve this:</t>
<t><list style='symbols'>
<t>the domain apex used for purposes other than data associated with the E.164 number plan MUST NOT be e164.arpa.</t>
<t>for use other than with E.164 numbers, the Application Unique String MUST NOT begin with the '+' character, whilst for ENUM use, the AUS MUST begin with this character.</t>
<t>NAPTRs that are intended for other DDDS applications MUST NOT include the E2U token in their service field, whilst NAPTRs intended for ENUM use MUST include this token.</t>
</list></t>

</section>

</section> <!-- section 3 -->

<section anchor="Examples" title="ENUM Service Example">
<t><figure><artwork>
  $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
   NAPTR 100 50 "u" "E2U+sip"
       "!^(\\+441632960083)$!sip:\\1@example.com!"    .
   NAPTR 100 51 "u" "E2U+h323"
       "!^\\+441632960083$!h323:operator@example.com!"    .
   NAPTR 100 52 "u" "E2U+email:mailto"
       "!^.*$!mailto:info@example.com!"    .
</artwork></figure></t>

<t>This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is preferably contacted by SIP, secondly via H.323 for voice, and thirdly by SMTP for messaging. Note that the Enumservice tokens "sip", "h323", and "email" are Enumservice Types registered with IANA, and they have no implicit connection with the protocols or URI schemes with the same names.</t>
<t>In all cases, the next step in the resolution process is to use the resolution mechanism for each of the protocols, (specified by the URI schemes sip, h323 and mailto) to know what node to contact.</t>
<t>In each of the first two records, the ERE sub-field matches only queries that have been made for the telephone number +441632960083. In the last record, the ERE matches any Application Unique String value. The first record also demonstrates how the matched pattern can be used in the generated URI.</t>
<t>Note that where NAPTR resource records are shown in DNS master file syntax (as in this example above), each backslash must itself be escaped using a second backslash. The DNS on-the-wire packet will have only a single backslash in each case.</t>
</section> <!-- section 4 -->


<section anchor="ExplainingHowToMakeItWork" title="Clarification of DDDS Use in ENUM">

<t>ENUM is a DDDS Application. This means that it relies on the DDDS for its operation. DDDS is designed to be flexible, but that opens the possibility of differences of interpretation. This section is intended to cover ENUM-specific interpretation of text within the DDDS specifications. The goal is to ensure interoperability between ENUM clients and provisioning systems used to populate domains with E2U NAPTRs.</t>
<t>As part of on-going development work on the ENUM specifications, an analysis has been carried out into the way in which ENUM client and provisioning system implementations behave, and the interoperability issues that have arisen. This (informative) analysis is provided in <xref target="RFC5483"></xref>. The following recommendations reflect that analysis, and further narrative explaining the issues can be found there.</t>

<section anchor="ENUMProvisioningCollected" title="Collected Implications for ENUM Provisioning">

<t>ENUM NAPTRs SHOULD NOT include characters outside the printable US- ASCII equivalent range (U+0020 to U+007E) unless it is clear that all ENUM clients they are designed to support will be able to process such characters correctly. If ENUM zone provisioning systems require non-ASCII characters, these systems SHOULD encode the non-ASCII data to emit only US-ASCII characters by applying the appropriate mechanism (<xref target="RFC3492"></xref>, <xref target="RFC3987"></xref>). Non-printable characters SHOULD NOT be used, as ENUM clients may need to present NAPTR content in a human-readable form.</t>

<t>The case-sensitivity flag ('i') is inappropriate for ENUM, and SHOULD NOT be provisioned into the Regexp field of E2U NAPTRs.</t>


<t>The Registrant and the ENUM zone provisioning system he or she uses SHOULD NOT rely on ENUM clients solely taking account of the value of the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs. Thus, a Registrant SHOULD place into his or her zone only contacts that he or she is willing to support; even those with the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an end user.</t>

<t>All E2U NAPTRs SHOULD hold a default value in their ORDER field. A value of "100" is recommended, as it seems to be used in most provisioned domains.</t>
<t><list style='empty'>
<t>Some ENUM clients have been known to pre-discard NAPTRs within an RRSet simply because these records do not have the lowest ORDER value found in that RRSet. Other ENUM client implementations appear to have confused ORDER and PREFERENCE/PRIORITY fields, using the latter as the major sort term rather than the former as specified. Conversely, ENUM zones have been provisioned within which the ORDER value varies but the PREFERENCE/PRIORITY field value is static. This may have been intentional, but given the different client behaviour in the face of varying ORDER field values, may not produce the desired response.</t>
</list></t>

<t>Multiple NAPTRs with identical ORDER and identical PREFERENCE/ PRIORITY field values SHOULD NOT be provisioned into an RRSet unless the intent is that these NAPTRs are truly identical and there is no preference between them. Implementers SHOULD NOT assume that the DNS will deliver NAPTRs within an RRSet in a particular sequence.</t>

<t>An ENUM zone provisioning system SHOULD assume that, if it generates compound NAPTRs, the Enumservices will normally be processed in left- to-right order within such NAPTRs.</t>

<t>ENUM zone provisioning systems SHOULD assume that, once a non- terminal NAPTR has been selected for processing, the ORDER field value in a domain referred to by that non-terminal NAPTR will be considered only within the context of that referenced domain (i.e., the ORDER value will be used only to sort within the current RRSet and will not be used in the processing of NAPTRs in any other RRSet).</t>


<t>ENUM zone provisioning systems SHOULD use '!'  (U+0021) as their Regexp delimiter character.</t>

<t>If the Regexp delimiter is a character in the static text of the Repl sub-field, it MUST be "escaped" using the escaped-delimiter production of the BNF specification shown in Section 3.2 of <xref target="RFC3402"></xref> (i.e., "\!", U+005C U+0021). Note that when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash.</t>

<t>If present in the ERE sub-field of an ENUM NAPTR, the literal character '+' MUST be escaped as "\+" (i.e. U+005C U+002B). Note that, as always, when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash.</t>

<t>Whilst this client behaviour is non-compliant, ENUM provisioning systems and their users should be aware that some ENUM clients have been detected with poor (or no) support for non-trivial ERE sub-field expressions.</t>

<t>ENUM provisioning systems SHOULD be cautious in the use of multiple back-reference patterns in the Repl sub-field of NAPTRs they provision. Some clients have limited buffer space for character expansion when generating URIs. These provisioning systems SHOULD check the back-reference replacement patterns they use, ensuring that regular expression processing will not produce excessive-length URIs.</t>


<t>ENUM zones MUST NOT be provisioned with NAPTRs according to the obsolete syntax of <xref target="RFC2916"></xref>, and MUST be provisioned with NAPTRs in which the Services field is according to <xref target="services" /> of this document.</t>
<t><list style='empty'>
<t><xref target="RFC2915"></xref> and <xref target="RFC2916"></xref> have been obsoleted by <xref target="RFC3401"></xref>-<xref target="RFC3404"></xref> and by this document, respectively.</t>
</list></t>

<t>Enumservices in which the Enumservice type starts with the facet "P-" MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets from entities outside the private network context in which these Enumservices are intended for use.</t>


<t>As current support is limited, non-terminal NAPTRs SHOULD NOT be provisioned in ENUM zones unless it is clear that all ENUM clients that this environment supports can process these.</t>

<t>When populating a set of domains with NAPTRs, ENUM zone provisioning systems SHOULD NOT configure non-terminal NAPTRs so that more than 5 such NAPTRs will be processed in an ENUM query.</t>

<t>In a non-terminal NAPTR that may be encountered in an ENUM query (i.e., one with an empty Flags field), the Services field SHOULD be empty.</t>

<t>A non-terminal NAPTR MUST include its target domain in the (non- empty) Replacement field as this field will be interpreted as holding the FQDN that forms the next key output from this non-terminal rule. The Regexp field MUST be empty in a non-terminal NAPTR intended to be encountered during an ENUM query.</t>

</section> <!-- section Servers -->

<section anchor="ClientsCollected" title="Collected Implications for ENUM Clients">

<t>If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query to terminate and processing SHOULD continue with the next NAPTR in the returned RRSet.</t>

<t>ENUM clients SHOULD NOT discard NAPTRs in which they detect characters outside the US-ASCII printable range (0x20 to 0x7E hexadecimal).</t>

<t>ENUM clients MAY discard NAPTRs that have octets in the Flags, Services, or Regexp fields that have byte values outside the US-ASCII equivalent range (i.e., byte values above 0x7F). Clients MUST be ready to encounter NAPTRs with such values without failure.</t>

<t>ENUM clients MUST sort the records of a retrieved NAPTR RRSet into sequence using the ORDER and PREFERENCE fields of those records. The ORDER is to be treated as the major sort term, with lowest numerical values being earlier in the sequence. The PREFERENCE/PRIORITY field is to be treated as the minor sort term, with lowest numerical values being earlier in the sequence.</t>

<t>ENUM clients SHOULD NOT discard a NAPTR record until it is considered or a record previous to it in the evaluation sequence has been accepted.</t>
<t><list style='empty'>
<t>Notably, if a record has a "worse" ORDER value than others in this RRSet, that record MUST NOT be discarded before consideration unless a record has been accepted as the result of this ENUM query.</t>
</list></t>

<t>Where the ENUM client presents a list of possible URLs to the end user for his or her choice, it MAY present all NAPTRs -- not just the ones with the lowest currently unprocessed ORDER field value. The client SHOULD observe the ORDER and PREFERENCE/PRIORITY values specified by the Registrant.</t>

<t>ENUM clients SHOULD accept all NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values, and process them in the sequence in which they appear in the DNS response. (There is no benefit in further randomizing the order in which these are processed, as intervening DNS Servers might have done this already).</t>

<t>ENUM clients SHOULD consider the ORDER field value only when sorting NAPTRs within a single RRSet. The ORDER field value SHOULD NOT be taken into account when processing NAPTRs across a sequence of DNS queries created by traversal of non-terminal NAPTR references.</t>


<t>ENUM clients receiving compound NAPTRs (i.e., ones with more than one Enumservice) SHOULD process these Enumservices using a left-to-right sort ordering, so that the first Enumservice to be processed will be the leftmost one, and the last will be the rightmost one.</t>


<t>ENUM clients MUST be ready to process NAPTRs that use a different character from '!' as their Regexp Delimiter without failure.</t>

<t>ENUM clients SHOULD NOT assume that the delimiter is the last character of the Regexp field.</t>
<t><list style='empty'>
<t>Unless they are sure that in their environment this is the case, in general an ENUM client may still encounter NAPTRs that have been provisioned with a following 'i' (case-insensitive) flag, even though that flag has no effect at all in an ENUM scenario.</t>
</list></t>

<t>ENUM clients SHOULD discard NAPTRs that have more or less than 3 unescaped instances of the delimiter character within the Regexp field.</t>
<t><list style='empty'>
<t>In the spirit of being liberal with what it will accept, if the ENUM client is sure how the Regexp field should be interpreted, it MAY choose to process the NAPTR even in the face of an incorrect number of unescaped delimiter characters. If it is not clear how the Regexp field should be interpreted, the client MUST discard the NAPTR.</t>
</list></t>

<t>ENUM clients MUST be ready to process NAPTRs that have non-trivial patterns in their ERE sub-field values without failure.</t>

<t>ENUM clients MUST be ready to process NAPTRs with many copies of back-reference patterns within the Repl sub-field without failure.</t>


<t>ENUM clients MUST be ready to process NAPTRs with a DDDS Application identifier other than 'E2U' without failure.</t>

<t>When an ENUM client encounters a compound NAPTR (i.e., one containing more than one Enumservice) and cannot process or cannot recognize one of the Enumservices within it, that ENUM client SHOULD ignore this Enumservice and continue with the next Enumservice within this NAPTR's Services field, discarding the NAPTR only if it cannot handle any of the Enumservices contained. These conditions SHOULD NOT be considered errors.</t>

<t>ENUM clients MUST support ENUM NAPTRs according to syntax defined in <xref target="services" />. ENUM clients SHOULD also support ENUM NAPTRs according to the obsolete syntax of <xref target="RFC2916"></xref>; there are still zones that hold "old" syntax NAPTRs. The informational <xref target="RFC3824"></xref> recommended such support.</t>

<t>Unless an ENUM client is sure that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet.</t>

<section anchor="ClientsNTNs" title="Non-terminal NAPTR Processing">

<t>ENUM clients MUST be ready to process NAPTRs with an empty Flags field ("non-terminal" NAPTRs) without failure. More generally, non- terminal NAPTR processing SHOULD be implemented, but ENUM clients MAY discard non-terminal NAPTRs they encounter.</t>

<t>ENUM clients SHOULD ignore any content of the Services field when encountering a non-terminal NAPTR with an empty Flags field.</t>

<t>ENUM clients receiving a non-terminal NAPTR with an empty Flags field MUST treat the Replacement field as holding the FQDN to be used in the next round of the ENUM query. An ENUM client MUST discard such a non-terminal NAPTR if the Replacement field is empty or does not contain a valid FQDN. By definition, it follows that the Regexp field will be empty in such a non-terminal NAPTR. If present in a non-terminal NAPTR, a non-empty Regexp field MUST be ignored by ENUM clients.</t>

<t>If a problem is detected when processing an ENUM query across multiple domains (by following non-terminal NAPTR references), the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD continue at the next NAPTR after the non-terminal NAPTR that referred to the domain in which the problem would have occurred.</t>

<t>If all NAPTRs in a domain traversed as a result of a reference in a non-terminal NAPTR have been discarded, the ENUM client SHOULD continue its processing with the next NAPTR in the "referring" RRSet (i.e., the one including the non-terminal NAPTR that caused the traversal).</t>

<t>ENUM clients MUST be prepared to encounter a referential loop in which a sequence of Non-Terminal NAPTRs are retrieved within an ENUM query that refer back to an earlier FQDN. ENUM clients MUST be able to detect and recover from such a loop, without failure.</t>

<t>ENUM clients MAY consider a chain of more than 5 "non-terminal" NAPTRs traversed in a single ENUM query as an indication that a referential loop has been entered.</t>

<t>When a domain is about to be entered as the result of a reference in a non-terminal NAPTR, and the ENUM client has detected a potential referential loop, the client SHOULD discard the non-terminal NAPTR from its processing and continue with the next NAPTR in its list. It SHOULD NOT make the DNS query indicated by that non- terminal NAPTR.</t>

</section>

</section> <!-- section Clients -->

</section> <!-- section 5 -->


<section anchor="IANAcons" title="IANA Considerations">

<t>RFC 2916 and then RFC 3761 (which this document replaces) requested IANA to delegate the E164.ARPA domain following instructions to be provided by the IAB. The domain was delegated according to those instructions. Names within this zone are to be delegated to parties according to the ITU-T Recommendation E.164. The names allocated should be hierarchic in accordance with ITU-T Recommendation E.164, and the codes should be assigned in accordance with that Recommendation.</t>
<t>The IAB is to coordinate with ITU-T TSB if the technical contact for the domain e164.arpa is to change, as ITU-T TSB has an operational working relationship with this technical contact which needs to be reestablished.</t>
<t>Delegations in the zone e164.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert.</t>
<t>See <xref target="SV_GUIDE"></xref> for Enumservice-related IANA Considerations.</t>


</section> <!-- section 6 -->


<section anchor="SecCons" title="Security Considerations">

<section anchor="secDNS" title="DNS Security">

<t>As ENUM uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the data one gets back is authentic. As ENUM is deployed on the global Internet, it is expected to be a popular target for various kind of attacks, and attacking the underlying DNS infrastructure is one way of attacking the ENUM service itself.</t>
<t>There are multiple types of attacks that can happen against DNS that ENUM implementations should consider. See Threat Analysis of the Domain Name System <xref target="RFC3833"></xref> for a review of the various threats to the DNS.</t>
<t>Because of these threats, a deployed ENUM service SHOULD include mechanisms to mitigate these threats. Most of the threats can be solved by verifying the authenticity of the data via mechanisms such as DNS Security (DNSSEC) <xref target="RFC4033"></xref>.</t>
<t>Others, such as Denial-Of-Service attacks, cannot be solved by data authentication. It is important to remember that these threats include not only the NAPTR lookups themselves, but also the various records needed for the services to be useful (for example NS, MX, SRV and A records).</t>
<t>Even if DNSSEC is deployed, a service that uses ENUM for address translation should not blindly trust that the peer is the intended party as DNSSEC deployment cannot protect against every kind of attack on DNS. A service should always authenticate the peers as part of the setup process for the service itself and never blindly trust any kind of addressing mechanism.</t>
<t>Finally, as an ENUM service will be implementing some type of security mechanism, software which implements ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses, including large responses, EDNS0 signaling, unknown RRs, and so on.</t>

</section>

<section anchor="DNScaching" title="Caching Security">

<t>The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR records in the zone that is changed. The use of this in an environment where IP-addresses are dynamically assigned (for example, when using DHCP <xref target="RFC2131"></xref>) must therefore be done very carefully.</t>

</section>

<section anchor="callSec" title="Call Routing Security">

<t>There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name- translation services. In these areas, any system that permits users, or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes.</t>

</section>

<section anchor="URIsec" title="URI Resolution Security">

<t>A large amount of Security Issues have to do with the resolution process itself, and use of the URIs produced by the DDDS mechanism. Those have to be specified in the registration of the Enumservice used, as specified in "IANA Registration of Enumservices: Guide, Template and IANA Considerations" <xref target="SV_GUIDE"></xref>.</t>

</section>


</section> <!-- section 7 -->


<section anchor="Shouts" title="Acknowledgements">

<t>This document is an update of RFC 3761, which was edited by Patrik Faltstrom and Michael Mealling. Please see the Acknowledgements section in that RFC for additional acknowledgements. The authors would also like to thank Alfred Hoenes and Bernie Hoeneisen for their detailed reviews.</t>


</section> <!-- section 8 -->


<section anchor="Changes" title="Changes from RFC 3761">

<t>A section has been added to explain the way in which DDDS is used with this specification. These recommendations have been collected from experience of ENUM deployment.</t>
<t>Clarifications include a default value for the ORDER field and for the Regexp delimiter character, required use of Replacement field in non-terminal NAPTRs, and that string matching is case insensitive (<xref target="almostInsensitive" />).</t>
<t>Substantive changes include removing the discussion of registration mechanisms, (now specified in "IANA Registration of Enumservices: Guide, Template and IANA Considerations" [SV_GUIDE]), correcting an existing error by adding "-" as a valid character in the type and subtype fields specified in Services Parameters (<xref target="services" />) and adding the "P-" private service type (<xref target="Enumservices" />).</t>

<section anchor="DraftDelta" title="Draft Change Log">

<t>change log - RFC Editor - please remove this section for publication.</t>
<t><figure><artwork>
version 01 -> 02
  clean up English - many places
  removed Registration mechanism for Enumservices section
  removed IANA considerations - point to draft-ietf-enum-enumservices-
  guide,
  replace DNS Security Threats in section 6.1 with pointer to RFC 3833
  fold in text from the ENUM Experiences ID - many places

version 02 -> 03
  fixed minor typos
  revised section 2.4.4.1, added P-
  expanded IANA Considerations - Section 6

version 03 -> 04
  Many changes to bring into sync with RFC 5483

version 04 -> 05
  change "ameliorate" to "mitigate" in 7.1
  fix reference to IANA Registration of Enumservices
  clarify ENUM definition of DDDS First Well Known Rule

version 05 -> 06
  fix language in section 2.2
  add Alfred Hoenes to the acknowledgements section

version 06 -> 07
  major re-structuring, collecting together provisioning and client
   recommendations into a their own sub-sections within a new section
   and referring to analysis in RFC 5483 rather than copying text
   directly
  corrected typos in the "Collected Implications" items
  slight rewording of section 1 introductory text and matching abstract
  rewording in section 1.2 to clarify goal
  create a separate sub-section for collision avoidance at the end of
   section 2 (to replace the second paragraph at the start of this
   specification section).
  add Bernie Hoeneisen to the acknowledgements section

 version 07 -> 08
  Renumbered sections to pull out the old section 1.2 as its own
   section.
  Added at end of section 4.1 -- "The informational RFC3824 recommended
   such support."
  Changed phrasing of sentence in introduction paragraph 3 to be
   consistent with abstract and paragraph 1.
  Corrected spelling in Acknowledgements.
</artwork></figure></t>

</section>

</section> <!-- section 9 -->


</middle>

<back>

<references title='Normative References'>

<reference anchor="E.164">
<front>
<title>The International Public Telecommunication Number Plan</title>
<author>
<organization abbrev="ITU-T">ITU-T</organization>
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date month="February" year="2005" />
</front>
<seriesInfo name="Recommendation" value="E.164" />
</reference>

&RFC2131;

&RFC3402;
&RFC3403;
&RFC3404;

&RFC3492;

&RFC3761;

&RFC3986;

&RFC3987;

</references>


<references title='Informative References'>

&RFC2119;

<!--  &RFC2026;  -->

&RFC2915;
<!-- out of date, obsolete, deceased, but needed as clients have to support the following, which refers to this -->
&RFC2916;
<!-- out of date, obsolete, but folk are required to support this due to a quirk of the SIP-related standards process -->
&RFC3824;
<!-- you might also wonder how an informational rfc makes statements on required support for obsolete ENUM formats -->

&RFC3401;
<!-- you might wonder how a document that obsoletes standards track RFCs came out as an informational RFC, but I guess my youngers and betters had an off day -->

&RFC3833;

&RFC4033;

&RFC5483;

<reference anchor="SV_GUIDE">
<front>
<title>IANA Registration of Enumservices: Guide, Template and IANA Considerations</title>
<author initials="B." surname="Hoeneisen" fullname="Bernie Hoeneisen">
<organization>Swisscom</organization>
</author>
<author initials="A." surname="Mayrhofer" fullname="Alex Mayrhofer">
<organization>NIC.AT</organization>
</author>
<author initials="J." surname="Livingood" fullname="Jason Livingood">
<organization>Comcast</organization>
</author>
<date year="2010" month="April" />
</front>
<seriesInfo name="internet-draft" value="draft-ietf-enum-enumservices-guide" />
</reference>

</references>

</back>
</rfc>