diff options
Diffstat (limited to 'doc/rfc/rfc5483.txt')
| -rw-r--r-- | doc/rfc/rfc5483.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc5483.txt b/doc/rfc/rfc5483.txt new file mode 100644 index 0000000..9d6394e --- /dev/null +++ b/doc/rfc/rfc5483.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group L. Conroy +Request for Comments: 5483 RMRL +Category: Informational K. Fujiwara + JPRS + March 2009 + + + ENUM Implementation Issues and Experiences + +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) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + This document captures experiences in implementing systems based on + the ENUM protocol and experiences of ENUM data that have been created + by others. As such, it clarifies the ENUM and Dynamic Delegation + Discovery System standards. Its aim is to help others by reporting + both what is "out there" and potential pitfalls in interpreting the + set of documents that specify the ENUM protocol. It does not revise + the standards but is intended to provide technical input to future + revisions of those documents. + + + + + + + + + + + + + + + +Conroy & Fujiwara Informational [Page 1] + +RFC 5483 ENUM Experiences March 2009 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Document Goal ..............................................3 + 1.2. Terminology ................................................3 + 2. Character Sets and ENUM .........................................4 + 2.1. Character Sets - Non-ASCII Considered Harmful ..............4 + 2.1.1. Non-ASCII in the Regular Expression Field ...........5 + 2.1.2. Non-ASCII Support - Conclusions .....................6 + 2.2. Case Sensitivity ...........................................7 + 2.3. Regexp Field Delimiter .....................................7 + 2.4. Regexp Meta-Character Issue ................................8 + 3. Unsupported NAPTRs ..............................................8 + 3.1. Non-Compliant Client Behaviour .............................9 + 4. ENUM NAPTR Processing ..........................................10 + 4.1. Common Non-Compliant Client Behaviour .....................11 + 4.1.1. Example ............................................11 + 4.2. Order/Priority Values - Processing Sequence ...............12 + 4.3. Use of Order and Preference Fields ........................13 + 4.4. NAPTRs with Identical ORDER/PRIORITY Values ...............14 + 4.4.1. Compound NAPTRs and Implicit + ORDER/REFERENCE Values .............................14 + 4.5. Processing Order Value across Domains .....................15 + 5. Non-Terminal NAPTR Processing ..................................16 + 5.1. Non-Terminal NAPTRs - Necessity ...........................16 + 5.2. Non-Terminal NAPTRs - Considerations ......................17 + 5.2.1. Non-Terminal NAPTRs - General ......................17 + 5.2.2. Non-Terminal NAPTRs - Loop Detection and Response ..17 + 5.2.3. Field Content in Non-Terminal NAPTRs ...............17 + 6. Backwards Compatibility ........................................20 + 6.1. Services Field Syntax .....................................20 + 7. Collected Implications for ENUM Provisioning ...................21 + 8. Collected Implications for ENUM Clients ........................23 + 8.1. Non-Terminal NAPTR Processing .............................25 + 9. Security Considerations ........................................26 + 10. Acknowledgements ..............................................27 + 11. References ....................................................27 + 11.1. Normative References .....................................27 + 11.2. Informative References ...................................29 + + + + + + + + + + + + +Conroy & Fujiwara Informational [Page 2] + +RFC 5483 ENUM Experiences March 2009 + + +1. Introduction + +1.1. Document Goal + + The goal of this document is to clarify the ENUM and Dynamic + Delegation Discovery System (DDDS) standards. It does not itself + revise ENUM or DDDS standards but is intended to provide technical + input to future revisions of those documents. It also serves to + advise implementers on the pitfalls that they may find. It + highlights areas where ENUM implementations have differed over + interpretation of the standards documents or have outright failed to + implement some features as specified. + + As well as providing clarifications to standards text, this document + also mentions potential choices that can be made, in an attempt to + help foster interworking between components that use this protocol. + The reader is reminded that others may make different choices. + + The core specifications for the E.164 Number Mapping (ENUM) protocol + [RFC3761] and the Dynamic Delegation Discovery System (DDDS) + [RFC3403] [RFC3401] [RFC3402] [RFC3404] [RFC3405] are defined + elsewhere. Unfortunately, this document cannot provide an overview + of the specifications, so the reader is assumed to have read and + understood the complete set of ENUM normative documents. + + The Domain Name System (DNS) is ENUM's database. ENUM uses the NAPTR + (Naming Authority Pointer) resource record type to store its DDDS + rules into DNS domains. ENUM relies on DNS services. Thus, it is + also important for ENUM implementers to carry out a thorough analysis + of all of the existing DNS standard documents to understand what + services are provided to ENUM and what load ENUM provisioning and + queries will place on the DNS. + + A great deal of the rationale for making the choices listed in this + document is available to those who explore the standards. The trick + of course is in understanding those standards and the subtle + implications that are involved in some of their features. In almost + all cases, the choices presented here are merely selections from + values that are permissible within the standards. + +1.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 [RFC2119]. + + + + + + +Conroy & Fujiwara Informational [Page 3] + +RFC 5483 ENUM Experiences March 2009 + + +2. Character Sets and ENUM + +2.1. Character Sets - Non-ASCII Considered Harmful + + [RFC3403] and [RFC3761] specify respectively that NAPTR resource + records and ENUM support Unicode using the UTF-8 encoding defined in + [RFC3629]. This raises an issue when implementations use "single + byte" string-processing routines. If there are multi-byte characters + within an ENUM NAPTR, incorrect processing may well result from these + UTF-8-unaware systems. + + The UTF-8 encoding has a US-ASCII equivalent range, so that all + characters in US-ASCII [ASCII] from 0x00 to 0x7F hexadecimal have an + identity map to the UTF-8 encoding; the encodings are the same. In + UTF-8, characters with Unicode code points above this range will be + encoded using more than one byte, all of which will be in the range + 0x80 to 0xFF hexadecimal. Thus, it is important to consider the + different fields of a NAPTR and whether or not multi-byte characters + can or should appear in them. + + In addition, characters in the non-printable portion of US-ASCII + (0x00 to 0x1F hexadecimal, plus 0x7F hexadecimal) are "difficult". + Although NAPTRs are processed by machine, they may sometimes need to + be written in a human-readable form. Specifically, if NAPTR content + is shown to an end user so that he or she may choose, it is + imperative that the content is human-readable. Thus, it is unwise to + use non-printable characters even if they lie within the US-ASCII + range; the ENUM client may have good reason to reject NAPTRs that + include these characters as they cannot readily be presented to an + end user. + + There are two numeric fields in a NAPTR: the ORDER and PREFERENCE/ + PRIORITY fields. As these contain binary values, no risk is involved + because string processing should not be applied to them. The string- + based fields are the Flags, Services, and Regexp fields. The + Replacement field holds an uncompressed domain name, encoded + according to the standard DNS mechanism [RFC1034][RFC1035]. The + Internationalised Domain Name (IDN) can be supported (as specified in + [RFC3490], [RFC3491], and [RFC3492]). Any such IDN MUST be further + encoded using Punycode [RFC3492]. As the Replacement field holds a + domain name that is not subject to replacement or modification (other + than Punycode processing), it is not of concern here. + + Taking the string fields in turn, the Flags field contains characters + that indicate the disposition of the NAPTR. This may be empty, in + which case the NAPTR is "non-terminal", or it may include a flag + + + + + +Conroy & Fujiwara Informational [Page 4] + +RFC 5483 ENUM Experiences March 2009 + + + character as specified in [RFC3761]. These characters all fall into + the printable US-ASCII equivalent range, so multi-byte characters + cannot occur. + + The Services field includes the DDDS Application identifier ("E2U") + used for ENUM, a set of Enumservice identifiers, any of which may + embed the ':' separator character, together with the '+' character + used to separate Enumservices from one another and from this DDDS + Application identifier. In Section 2.4.2 of [RFC3761], Enumservice + identifier tokens are specified as 1*32 ALPHA/DIGIT, so there is no + possibility of non-ASCII characters in the Services field. + +2.1.1. Non-ASCII in the Regular Expression Field + + The Regexp field is more complex. It forms a sed-like substitution + expression, defined in [RFC3402], and consists of two sub-fields: + + o a POSIX Extended Regular Expression (ERE) sub-field + [IEEE.1003-2.1992] + + o a replacement (Repl) sub-field [RFC3402]. + + Additionally, [RFC3402] specifies that a flag character may be + appended, but the only flag currently defined there (the 'i' case- + insensitivity flag) is not appropriate for ENUM -- see Section 2.2. + + The ERE sub-field matches against the "Application Unique String"; + for ENUM, this is defined in [RFC3761] to consist of digit + characters, with an initial '+' character. It is similar to a + global-number-digits production of a tel: URI, as specified in + [RFC3966], but with visual-separators removed. In short, it is a + telephone number (see [E.164]) in restricted format. All of these + characters fall into the US-ASCII equivalent range of UTF-8 encoding, + as do the characters significant to the ERE processing. + + Strictly, the ERE might include other characters. The ERE could + include choice elements matching against different items, some of + which might not be an ENUM Application Unique String. Those + alternative matching elements might conceivably include non-ASCII + characters. As an operational issue, it is not reasonable to include + such constructs, as ENUM NAPTRs match against telephone numbers. + + In the normal situation in which E2U NAPTRs are provisioned in ENUM + domains, there will be no multi-byte characters within this sub- + field, as the ERE will be intended to match against telephone + numbers. ENUM clients must be able to handle NAPTRs that do contain + such multi-byte characters (as the standard does not preclude them), + but there is no operational reason for these ever being provisioned + + + +Conroy & Fujiwara Informational [Page 5] + +RFC 5483 ENUM Experiences March 2009 + + + in ENUM domains. If NAPTRs provisioned in ENUM domains are + encountered containing such multi-byte characters, these could + reasonably be discarded. + + The Repl sub-field can include a mixture of explicit text used to + construct a URI and characters significant to the substitution + expression, as defined in [RFC3403]. Whilst the latter set all fall + into the US-ASCII equivalent range of UTF-8 encoding, this might not + be the case for all conceivable text used to construct a URI. + Presence of multi-byte characters could complicate URI generation and + processing routines. + + URI generic syntax is defined in [RFC3986] as a sequence of + characters chosen from a limited subset of the repertoire of US-ASCII + characters. The current URIs use the standard URI character escaping + rules specified in the URI generic syntax, and so any multi-byte + character will be pre-processed; they will not occur in the explicit + text used to construct a URI within the Repl sub-field. + +2.1.1.1. Impact of Future Support for IRIs + + As currently specified, ENUM only permits URIs to be generated in the + Regexp field. However, even if this were to be extended in future + revisions of the ENUM specification to allow the use of + Internationalised Resource Identifiers (IRIs), defined in [RFC3987], + further support for non-ASCII characters may be avoided. IRIs are + defined as extending the syntax of URIs, and RFC 3987 specifies a + mapping from IRIs to URIs. IRI syntax allows characters with multi- + byte UTF-8 encoding. + + Given that this is the only place within an ENUM NAPTR where such + multi-byte encodings might reasonably be found, a simple solution is + to use the mapping method specified in Section 3.1 of [RFC3987] to + convert any IRI into its equivalent URI. + + This process consists of two elements; the domain part of an IRI MUST + be processed using Punycode if it has a non-ASCII domain name, and + the remainder MUST be processed using the extended escaping rules + specified in [RFC3987] if it contains characters outside the normal + URI repertoire. Using this process, there will be no non-ASCII + characters in any part of any URI, even if it has been converted from + an IRI that contains such characters. + +2.1.2. Non-ASCII Support - Conclusions + + From the analysis just given, the only place within an ENUM NAPTR + where non-ASCII characters might be found is the Regexp field. It is + possible to remove any requirement to process characters outside the + + + +Conroy & Fujiwara Informational [Page 6] + +RFC 5483 ENUM Experiences March 2009 + + + US-ASCII equivalent range by adding very few operational + restrictions. There is no obvious benefit in providing characters + outside this range. Handling multi-byte characters complicates + development and operation of client programs, and many existing + programs do not include such support. + + As the gain from permitting characters outside the US-ASCII + equivalent range is unclear, and the costs of multi-byte character + processing are very clear, ENUM NAPTRs SHOULD NOT include characters + outside the printable US-ASCII equivalent range. + +2.2. Case Sensitivity + + The only place where NAPTR field content is case sensitive is in any + static text in the Repl sub-field of the Regexp field. Everywhere + else, case-insensitive processing can be used. + + The case-insensitivity flag ('i') could be added at the end of the + Regexp field. However, in ENUM, the ERE sub-field operates on a + string defined as the '+' character, followed by a sequence of digit + characters. This flag is redundant for E2U NAPTRs, as it does not + act on the Repl sub-field contents. + + Thus, the case-sensitivity flag is inappropriate for ENUM, and SHOULD + NOT be provisioned into E2U NAPTRs. + +2.3. Regexp Field Delimiter + + It is not possible to select a delimiter character that cannot appear + in one of the sub-fields. The '!' character is used as a delimiter + in all of the examples in [RFC3403] and in [RFC3761]. It is the only + character seen in existing zones, and a number of different client + implementations are still "hardwired" to expect this character as a + delimiter. + + The '!' character will not normally appear in the ERE sub-field. It + may appear in the content of some URIs, as it is a valid character + (e.g., in http URLs). If it is present in the Regexp field, then + that instance MUST be escaped using the standard technique proposed + in Section 3.2 of [RFC3402]: a backslash character (U+005C) should be + inserted before it in the string. Otherwise, a client may attempt to + process this as a standard delimiter and interpret the Regexp field + contents differently from the system that provisioned it. + + + + + + + + +Conroy & Fujiwara Informational [Page 7] + +RFC 5483 ENUM Experiences March 2009 + + +2.4. Regexp Meta-Character Issue + + In ENUM, the ERE sub-field may include a literal character '+', as + the Application Unique String on which it operates includes this. + However, if it is present, then '+' MUST be escaped using a single + backslash character (to produce the sub-string U+005C U+002B), as '+' + is a meta-character in POSIX Extended Regular Expression syntax. + + Not escaping the '+' character produces an invalid ERE, but is a + common mistake. Even standards have given incorrect examples; the + obsolete [RFC2916] (Section 3.4.3, example 3) has this problem. + + For example, the following NAPTR example is incorrect: + * IN NAPTR 100 10 "u" "E2U+sip" "!^+4655(.*)$!sip:\\1@example.net!" . + + A correct way to write this example is: + * IN NAPTR 100 10 "u" + "E2U+sip" "!^\\+4655(.*)$!sip:\\1@example.net!" . + + Note that when a NAPTR resource record is shown in DNS master file + syntax (as in this example above), the backslash itself must be + escaped using a second backslash. The DNS on-the-wire packet will + have only a single backslash. + +3. Unsupported NAPTRs + + An ENUM client MAY discard a NAPTR received in response to an ENUM + query because: + + o the NAPTR is syntactically or semantically incorrect, + + o the NAPTR has a different (non-empty) DDDS Application identifier + from the 'E2U' used in ENUM, + + o the NAPTR's ERE does not match the Application Unique String for + this ENUM query, + + o the ENUM client does not recognise any Enumservice held in this + NAPTR, or + + o this NAPTR (only) contains an Enumservice that is unsupported. + + These conditions SHOULD NOT cause the whole ENUM query to terminate, + and processing SHOULD continue with the next NAPTR in the returned + Resource Record Set (RRSet). + + + + + + +Conroy & Fujiwara Informational [Page 8] + +RFC 5483 ENUM Experiences March 2009 + + + When an ENUM client encounters a compound NAPTR (i.e., one containing + more than one Enumservice -- see also Section 4.4.1) and cannot + process or cannot recognise 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. + + ENUM uses regular-expression processing when generating URIs from the + Regexp field of "terminal" NAPTRs. Just as with all uses of regular + expressions, there is a potential for buffer overrun when generating + this output. There may be repeated back-reference patterns in a + NAPTR's Repl sub-field, and the output these generate may consume a + considerable amount of buffer space. + + Even if an ENUM client would normally encounter only NAPTRs with + short URIs, it may also receive NAPTRs with repeated back-reference + patterns in their Repl sub-fields that could generate strings longer + than the client's buffer. Such NAPTRs may have been misconfigured + accidentally or by design. The client MUST NOT fail in this case. + It SHOULD NOT discard the entire ENUM query, but instead just discard + the NAPTR that would otherwise have caused this overrun. + + If a problem is detected when processing an ENUM query across + multiple domains (by following non-terminal NAPTR references), then + 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. See + Section 5.2.2 for more details. + +3.1. Non-Compliant Client Behaviour + + Through monitoring current ENUM clients, a number of non-compliant + behaviours have been detected. These behaviours are incorrect, but + may be encountered in still-operational client implementations. + + ENUM clients have been known to discard NAPTRs in which the Services + field holds more than one Enumservice. + + ENUM clients have also been known to discard NAPTRs with a "non- + greedy" ERE sub-field expression (i.e., EREs that are dissimilar to + "^.*$"). + + ENUM clients have been known to discard NAPTRs that do not use '!' as + their Regexp delimiter character. + + ENUM clients have been known to discard NAPTRs in which the delimiter + is NOT the last character in the Regexp field. + + + +Conroy & Fujiwara Informational [Page 9] + +RFC 5483 ENUM Experiences March 2009 + + + ENUM clients have been known to discard NAPTRs with an empty Flags + field (i.e., "non-terminal" NAPTRs). + + ENUM clients have been known to ignore the ORDER field value + entirely, sorting the NAPTRs in an RRSet based solely on the + PREFERENCE/PRIORITY field values. + + Finally, many ENUM clients have been known to discard a NAPTR where + they have local knowledge that the URI that would be generated by + processing the NAPTR is unusable. This behaviour is, strictly + speaking, non-compliant, but might be considered reasonable (see + Section 4.1). + +4. ENUM NAPTR Processing + + ENUM is a DDDS Application, and the way in which NAPTRs in an RRSet + are processed reflects this. The details are described in Section + 3.3 of [RFC3402]. The client is expected to sort the records it + receives into a sequence and then process those records in that + sequence. The sequence reflects the ORDER and PREFERENCE/PRIORITY + field values in each of the NAPTRs. + + The ORDER field value is the major, or most significant, sort term + and the PREFERENCE/PRIORITY field value is the minor, or least + significant, sort term. The combination of ORDER and PREFERENCE/ + PRIORITY field values indicates the sequence chosen by the publisher + of this data, and NAPTRs will be considered in this sequence. + + Once the NAPTRs are sorted into sequence, further processing is done + to determine if each of the NAPTRs is appropriate for this ENUM + evaluation. This involves looking at the Flags field. If the Flags + field is empty, this is a "non-terminal" NAPTR and is processed as + described in Section 5. + + If the "u" Flag is present (and so the NAPTR is a "terminal" rule + that generates a URI), the Services field is checked to ensure that + this NAPTR is intended for ENUM (i.e., that this NAPTR includes the + "E2U" DDDS Application identifier in the Services field). The ERE in + the Regexp field is checked and must match the Application Unique + String (AUS) for this ENUM evaluation (the queried telephone number). + Unless each of these checks succeeds, the NAPTR is discarded and the + next in sequence is processed. + + During this processing, clients will also consider the Enumservices + within the Services field. Enumservices indicate the kind of + interaction that can be achieved through use of the URI this NAPTR + generates. If there is local knowledge that a NAPTR includes only an + Enumservice that is either not supported or not recognised, then this + + + +Conroy & Fujiwara Informational [Page 10] + +RFC 5483 ENUM Experiences March 2009 + + + NAPTR can be discarded and the next in sequence will be processed. + Thus, for a system that has support only for SIP interactions, if it + receives an RRSet in which the "best" NAPTR indicates the H323 + Enumservice, then that client could reasonably discard that NAPTR and + go on to the next in sequence. + +4.1. Common Non-Compliant ENUM Processing + + The processing of ORDER and PREFERENCE/PRIORITY fields has been a + significant source of confusion, and many ENUM clients do not + implement the processing exactly as specified. + + In particular, many ENUM clients use local prior knowledge about URIs + during ENUM processing. If a client has prior knowledge that a + particular URI will not result in an acceptable outcome, it might + discard that NAPTR and consider the next one in the sequence. + Examples of such local prior knowledge include: the URI does not + resolve, authentication has been recently rejected, or user policies + mark a particular URI as unacceptable (the URI could be a "premium + rate" telephone number that would be charged at an unacceptable + rate). + + Strictly speaking, this behaviour is non-compliant if the next NAPTR + record has a different ORDER value. The ENUM algorithm (Section 3.3 + of [RFC3402] and Section 4.1 of [RFC3403]) states that once a match + has been found for the Application Unique String (AUS), and the + service description satisfies the client's requirements, NAPTR + records with larger ORDER values must not be considered (but other + NAPTR records with the same ORDER value can still be considered). + + However, embedding local knowledge about the URI within the ENUM + evaluation process is almost universal in systems employing ENUM. + Also, since the difference between ORDER and PRIORITY/PREFERENCE has + been unclear, NAPTR records have been provisioned in ways that would + make strictly compliant systems unusable in practice. Given that + such systems are intended to provide communications, this non- + compliant, "embedded decision" behaviour is understandable. + + It is proposed that when the ENUM specification is updated, + processing of ORDER and PRIORITY/PREFERENCE should be updated based + on implementation and deployment experiences described in this + document. + +4.1.1. Example + + The example in this section is intended to further understanding + about the difference between what [RFC3402] and [RFC3403] specify and + what existing ENUM clients do. + + + +Conroy & Fujiwara Informational [Page 11] + +RFC 5483 ENUM Experiences March 2009 + + + WARNING: The NAPTR records shown in this section are intended to + illustrate somewhat unclear corner cases, and are not intended as + good examples of how to do ENUM provisioning. + + Consider the following RRset, which maps numbers in the UK drama + range to one server, and all other numbers to a second server: + * 3600 IN NAPTR 1 1 "u" "e2u+sip" + "!^(\\+441632960.*)$!sips:\\1@atlanta.example.com!" . + * 3600 IN NAPTR 2 1 "u" "e2u+sip" + "!^(.*)$!sip:\\1@biloxi.example.com!" . + + According to the processing specified in [RFC3402] and [RFC3403], the + ENUM client is never intended to consider the second rule for e.g., + AUS "+441632960123", even if it does not support "sips" URIs, or the + atlanta.example.com server cannot be reached, or the user indicates + he or she doesn't wish to contact atlanta.example.com. However, + existing ENUM implementations are known to do this, and as described + above, it can be useful if the alternative is failing to communicate + at all. + + To prevent a client from considering the second rule for the UK drama + range, the example could be rewritten to have more predictable + behaviour as follows: + * 3600 IN NAPTR 1 1 "u" "e2u+sip" + "!^(\\+441632960.*)$!sips:\\1@atlanta.example.com!" . + * 3600 IN NAPTR 2 1 "u" "e2u+sip" + "!^(\\+[^4].*|\\+4[^4].*|\\+44[^1].*|\\+441[^6].*|\\+4416[^3].*| + \\+44163[^2].*|\\+441632[^9].*|\\+4416329[^6].*| + \\+44163296[^0].*)$!sip:\\1@biloxi.example.com!" . + +4.2. Order/Priority Values - Processing Sequence + + [RFC3761] and [RFC3403] state that the ENUM client MUST sort the + NAPTRs using the ORDER field value ("lowest value is first") and + SHOULD order the NAPTRs using the PREFERENCE/PRIORITY field value as + the minor sort term (again, lowest value first). The NAPTRs in the + sorted list must be processed in order. Subsequent NAPTRs with worse + ORDER values must only be dealt with once the current ones with a + better ORDER value have been processed. + + However, as described in the introduction to this section, this + stated behaviour is a simplification. Once sorted into a sequence + reflecting ORDER and PREFERENCE/PRIORITY values, other fields are + also considered during evaluation of retrieved NAPTRs; local + knowledge may play a factor in the decision process, once a NAPTR has + reached that point in the sequence at which it is considered. + + + + + +Conroy & Fujiwara Informational [Page 12] + +RFC 5483 ENUM Experiences March 2009 + + + ENUM clients may also include the end user "in the decision loop", + offering the end user the choice from a list of possible NAPTRs. + Conceptually this choice is embedded within step 4 of the DDDS + algorithm (as described in Section 3.3 of [RFC3402]). Given that the + ORDER field value is the major sort term, one would expect a + conforming ENUM client to present only those NAPTRs with the + currently "best" ORDER field value as choices. When/if all the + presented options had been rejected, then the ENUM client might offer + those with the "next best" ORDER field value, and so on. As this may + be confusing for the end user, some clients simply offer all of the + available NAPTRs as options to the end user for his or her selection + at once, in the sequence defined by the ORDER and PREFERENCE/PRIORITY + fields. + + In summary, ENUM clients will take into account the Services field + value, the Flags field, and the Regexp ERE sub-field, along with the + ORDER and PREFERENCE/PRIORITY field values, and may consider local + policies or available local knowledge. + + The Registrant and the ENUM zone provisioning system he or she uses + must be aware of this and SHOULD NOT rely on ENUM clients solely + taking account of the value of the ORDER and the PREFERENCE/PRIORITY + fields alone. + + Specifically, it is unsafe to assume that an ENUM client will not + consider another NAPTR if there is one with a better ORDER value. + The instructions in Section 4.1 and Section 8 of [RFC3403] may or may + not be followed strictly by different ENUM clients for perfectly + justifiable reasons. + + Where the ENUM client presents a list of possible URLs to the end + user for his or her choice, it MUST do so in the sequence defined by + the ORDER and PREFERENCE/PRIORITY values specified by the Registrant. + + However, 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. + +4.3. Use of Order and Preference Fields + + NAPTRs in ENUM zones that hold incorrect ORDER values can cause major + problems. [RFC3403] highlights that having both ORDER and + PREFERENCE/PRIORITY fields is a historical artifact of the NAPTR + resource record type. It is reasonable to have a common default + value for the ORDER field, relying on the PREFERENCE/PRIORITY field + to indicate the preferred sort. + + + + + +Conroy & Fujiwara Informational [Page 13] + +RFC 5483 ENUM Experiences March 2009 + + + We have noticed a number of ENUM domains with NAPTRs that have + identical PREFERENCE/PRIORITY field values and different ORDER + values. This may be the result of an ENUM zone provisioning system + "bug" or a misunderstanding over the uses of the two fields, or + simply a difference of interpretation of the standards. + + To clarify, the ORDER field value is the major sort term, and the + PREFERENCE/PRIORITY field value is the minor sort term. Thus, one + should expect to have a set of NAPTRs in a zone with identical ORDER + field values and different PREFERENCE/PRIORITY field values; not the + other way around. + + To avoid these common interoperability issues, it is recommended that + ENUM NAPTRs SHOULD hold a default value in their ORDER field. + +4.4. NAPTRs with Identical ORDER/PRIORITY Values + + From experience, it has been learned that there are zones that hold + discrete NAPTRs with identical ORDER and identical PREFERENCE/ + PRIORITY field values. This will lead to indeterminate client + behaviour and so SHOULD NOT normally occur. + + Such a condition indicates that these NAPTRs are truly identical in + priority and that there is no preference between the services these + NAPTRs offer. Implementers SHOULD NOT assume that the DNS will + deliver NAPTRs within an RRSet in a particular sequence. + + 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 in priority and + there is no preference between them. + + Some ENUM client implementations have considered this case to be an + error and have rejected such duplicates entirely. Others have + attempted to further randomise the order in which such duplicates are + processed. Thus, use of such duplicate NAPTRs is unwise, as client + implementations exist that will behave in different ways. + +4.4.1. Compound NAPTRs and Implicit ORDER/REFERENCE Values + + With [RFC3761], 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. The Services field in that + case would be "E2U+voice:tel+sms:tel". + + + + + +Conroy & Fujiwara Informational [Page 14] + +RFC 5483 ENUM Experiences March 2009 + + + 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. In this case, the reconstructed + NAPTR holding the leftmost Enumservice within the compound NAPTR has + the best priority, and the reconstructed NAPTR holding the rightmost + Enumservice has the worst priority in this set. + + To avoid indeterminate behaviour, it is recommended that ENUM clients + SHOULD process the Enumservices within a compound NAPTR in a left-to- + right sequence. ENUM provisioning systems SHOULD assume that such a + processing order will be used and provision the Enumservices within a + compound NAPTR accordingly. + +4.5. Processing Order Value across Domains + + Using a different ORDER field value in different domains is + unimportant for most queries. However, DDDS includes a mechanism for + continuing a search for NAPTRs in another domain by including a + reference to that other domain in a "non-terminal" NAPTR. The + treatment of non-terminal NAPTRs is covered in the next section. If + they are supported, then the way that ORDER and PREFERENCE/PRIORITY + field values are processed is affected. + + Two main questions remain from the specifications of DDDS and + [RFC3761]: + + o If there is a different (lower) ORDER field value in a domain + referred to by a non-terminal NAPTR, then does this mean that the + ENUM client discards any remaining NAPTRs in the referring RRSet? + + o Conversely, if the domain referred to by a non-terminal NAPTR + contains entries that only have a higher ORDER field value, then + does the ENUM client ignore those NAPTRs in the referenced domain? + + Whilst one interpretation of [RFC3761] is that the answer to both + questions is "yes", this is not the way that those examples of non- + terminal NAPTRs that do exist (and those ENUM clients that support + them) seem to be designed. + + In keeping with the interpretation made so far, ENUM implementations + MUST consider the ORDER and PREFERENCE/PRIORITY values only within + the context of the domain currently being processed in an ENUM query. + These values MUST be discarded when processing other RRSets in the + query. + + + + + + +Conroy & Fujiwara Informational [Page 15] + +RFC 5483 ENUM Experiences March 2009 + + +5. Non-Terminal NAPTR Processing + +5.1. Non-Terminal NAPTRs - Necessity + + Consider an ENUM RRSet that contains a non-terminal NAPTR record. + This non-terminal NAPTR holds, as its target, another domain that has + a set of NAPTRs. In effect, this is similar to the non-terminal + NAPTR being replaced by the NAPTRs contained in the domain to which + it points. + + It is possible to have a non-terminal NAPTR in a domain that is, + itself, pointed to by another non-terminal NAPTR. Thus, a set of + domains forms a "chain", and the list of NAPTRs to be considered is + the set of all NAPTRs contained in all of the domains in that chain. + + For an ENUM management system to support non-terminal NAPTRs, it is + necessary for it to be able to analyse, validate, and (where needed) + correct not only the NAPTRs in its current ENUM domain but also those + referenced by non-terminal NAPTRs in other domains. If the domains + pointed to have non-terminal NAPTRs of their own, the management + system will have to check each of the referenced domains in turn, as + their contents form part of the result of a query on the "main" ENUM + domain. The domain content in the referenced domains may well not be + under the control of the ENUM management system, and so it may not be + possible to correct any errors in those RRSets. This is both complex + and prone to error in the management system design, and any reported + errors in validation may well be non-intuitive for users. + + For an ENUM client, supporting non-terminal NAPTRs can also be + difficult. Processing non-terminal NAPTRs causes a set of sequential + DNS queries that can take an indeterminate time, and requires extra + resources and complexity to handle fault conditions like non-terminal + loops. The indeterminacy of response time makes ENUM-supported + Telephony Applications difficult (such as in an "ENUM-aware" Private + Branch Exchange (PBX)), whilst the added complexity and resources + needed makes support problematic in embedded devices like "ENUM- + aware" mobile phones. + + Given that, in principle, a non-terminal NAPTR can be replaced by the + NAPTRs in the domain to which it points, support of non-terminal + NAPTRs is not needed and non-terminal NAPTRs may not be useful. + Furthermore, some existing ENUM clients do not support non-terminal + NAPTRs and ignore them if received. + + To avoid interoperability problems, some kind of acceptable advice is + needed on non-terminal NAPTRs. As current support is limited, non- + terminal NAPTRs SHOULD NOT be used in ENUM unless it is clear that + all of the ENUM clients this environment supports can process these. + + + +Conroy & Fujiwara Informational [Page 16] + +RFC 5483 ENUM Experiences March 2009 + + +5.2. Non-Terminal NAPTRs - Considerations + + The following specific issues need to be considered if non-terminal + NAPTRs are to be supported in a particular environment. These issues + are gleaned from experience and indicate the kinds of conditions that + should be considered before support for non-terminal NAPTRs is + contemplated. Note that these issues are in addition to the point + just mentioned on ENUM provisioning or management system complexity + and the potential for that management system to have no control over + the zone contents to which non-terminal NAPTRs in its managed zones + refer. + +5.2.1. Non-Terminal NAPTRs - General + + As mentioned earlier, a non-terminal NAPTR in one RRSet refers to the + NAPTRs contained in another domain. The NAPTRs in the domain + referred to by the non-terminal NAPTR may have a different ORDER + value from that in the referring non-terminal NAPTR. See Section 4.5 + for details. + +5.2.2. Non-Terminal NAPTRs - Loop Detection and Response + + Where a chain of non-terminal NAPTRs refers back to a domain already + traversed in the current query, a "non-terminal" or referential loop + is implied. An implementation MAY treat a chain of more than 5 + domains traversed during a single ENUM query as an indication that a + self-referential loop has been entered. + + There are many techniques that can be used to detect such a loop, but + the simple approach of counting the number of domains queried in the + current ENUM query suffices. + + Where a loop has been detected, processing SHOULD continue at the + next NAPTR in the referring domain (i.e., after the non-terminal + NAPTR that included the reference that triggered the loop detection). + +5.2.3. Field Content in Non-Terminal NAPTRs + + The set of specifications defining DDDS and its applications are + complex and multi-layered. This reflects the flexibility that the + system provides but does mean that some of the specifications need + clarification as to their interpretation, particularly where non- + terminal rules are concerned. + + + + + + + + +Conroy & Fujiwara Informational [Page 17] + +RFC 5483 ENUM Experiences March 2009 + + +5.2.3.1. Flags Field Content with Non-Terminal NAPTRs + + Section 2.4.1 of [RFC3761] states that the only flag character valid + for use with the "E2U" DDDS Application is 'u'. The flag 'u' is + defined (in Section 4.3 of [RFC3404]) thus: 'The "u" flag means that + the output of the Rule is a URI'. + + Section 2.4.1 of [RFC3761] also states that an empty Flags field + indicates a non-terminal NAPTR. This is also the case for other DDDS + Application specifications, such as that specified in [RFC3404]. One + could well argue that this is a feature potentially common to all + DDDS Applications, and so might have been specified in [RFC3402] or + [RFC3403]. + + The Flags field will be empty in non-terminal NAPTRs encountered in + ENUM processing. ENUM does not have any other way to indicate a non- + terminal NAPTR. + +5.2.3.2. Services Field Content with Non-Terminal NAPTRs + + Furthermore, [RFC3761] states that any Enumservice Specification + requires definition of the URI that is the expected output of this + Enumservice. This means that, at present, there is no way to specify + an Enumservice that is non-terminal; such a non-terminal NAPTR has, + by definition, no URI as its expected output, instead returning a key + (DNS domain name) that is to be used in the "next round" of DDDS + processing. + + This in turn means that a non-terminal NAPTR cannot hold a valid + (non-empty) Services field when used in ENUM. Section 2.4.2 of + [RFC3761] specifies the syntax for this field content and requires at + least one element of type <servicespec> (i.e., at least one + Enumservice identifier). Given that there cannot be a non-terminal + Enumservice (and so no such Registered Enumservice identifier), this + syntax cannot be met with a non-terminal NAPTR; there are no non- + terminal Enumservices to put into this field. + + A reasonable interpretation of the specifications is that for a non- + terminal NAPTR, the Services field must also be empty. This appears + to be the approach taken by those clients that do either process non- + terminal NAPTRs or check the validity of the fields. + + It is expected that future revisions of the ENUM standard will + clarify this text, making this interpretation plain. This was the + intent of the current standard, and the intent will be made explicit + in its revision. + + + + + +Conroy & Fujiwara Informational [Page 18] + +RFC 5483 ENUM Experiences March 2009 + + + In keeping with existing implementations, in a non-terminal NAPTR + encountered in an ENUM query, the Services field SHOULD be empty, and + clients SHOULD ignore any content it contains. + + Of course, such non-terminal NAPTRs with an empty Services field are + not specific to any DDDS Application. Thus, other means must be used + to ensure a non-terminal NAPTR that is intended only for a particular + DDDS Application cannot be encountered during a lookup for another + DDDS Application (for example, by ensuring that the same domain is + not used to host NAPTRs for more than one such DDDS Application). + +5.2.3.3. Regular Expression and Replacement Field Content with Non- + Terminal NAPTRs + + The descriptive text in Section 4.1 of [RFC3403] is intended to + explain how the fields are to be used in a NAPTR. However, the + descriptions associated with the Regexp and Replacement elements have + led to some confusion over which of these should be considered when + dealing with non-terminal NAPTRs. + + [RFC3403] is specific; these two elements are mutually exclusive. + This means that if the Regexp element is not empty, then the + Replacement element must be empty, and vice versa. However, + [RFC3403] does not specify which is used with terminal and non- + terminal rules. + + The descriptive text of Section 4.1 of [RFC3403] for the NAPTR + Replacement element shows that this element holds an uncompressed + domain name. Thus, it is clear that this element cannot be used to + deliver the terminal string for any DDDS Application that does not + have a domain name as its intended terminal output. + + However, the first paragraph of descriptive text for the NAPTR Regexp + element has led to some confusion. It appears that the Regexp + element is to be used to find "the next domain name to lookup". This + might be interpreted as meaning that a client program processing the + DDDS Application could need to examine each non-terminal NAPTR to + decide whether the Regexp element or instead the Replacement element + should be used to construct the key (a domain name) to be used next + in non-terminal rule processing. + + Given that a NAPTR holding a terminal rule (a "terminal NAPTR") must + use the Substitution expression field to generate the expected output + of that DDDS Application, the Regexp element is also used in such + rules. Indeed, unless that DDDS Application has a domain name as its + terminal output, the Regexp element is the only possibility. + + + + + +Conroy & Fujiwara Informational [Page 19] + +RFC 5483 ENUM Experiences March 2009 + + + Thus, from the descriptive text of this section, a Replacement + element can be used only in NAPTRs holding a non-terminal rule (a + "non-terminal NAPTR") unless that DDDS Application has a domain name + as its terminal output, whilst the alternative Regexp element may be + used either to generate a domain name as the next key to be used in + the non-terminal case or to generate the output of the DDDS + Application. + + Note that each DDDS Application is free to specify the set of flags + to be used with that application. This includes specifying whether a + particular flag is associated with a terminal or non-terminal rule, + and also includes specifying the interpretation of an empty Flags + field (i.e., whether this is to be interpreted as a terminal or non- + terminal rule, and if it is terminal, then what is the expected + output). ENUM (as specified in Section 2.4.1 of [RFC3761]) uses only + the 'u' flag, with an empty Flags field indicating a non-terminal + NAPTR. + + The general case in which a client program must check which of the + two elements to use in non-terminal NAPTR processing complicates + implementation, and this interpretation has NOT been made in current + ENUM implementations. It would be useful to define exactly when a + client program can expect to process the Regexp element and when to + expect to process the Replacement element, if only to improve + robustness. Generating an ENUM domain name from the Regexp field is + difficult at best and impossible for the general case of a variable- + length telephone number, or one that has more than 9 digits. Thus, + it is proposed that when the ENUM specification is updated, this + option is deprecated, and using the Regexp field for non-terminal + ENUM NAPTRs is prohibited. + + In keeping with current implementations, the target domain of a non- + terminal ENUM NAPTR MUST be placed in the (non-empty) Replacement + field. This field MUST be interpreted as holding the domain name + that forms the next key output from this non-terminal rule. + Conversely, the Regexp field MUST be empty in a non-terminal NAPTR + encountered in ENUM processing, and ENUM clients MUST ignore its + content. + +6. Backwards Compatibility + +6.1. Services Field Syntax + + [RFC3761] is the current standard for the syntax for NAPTRs + supporting the ENUM DDDS Application. This obsoletes the original + specification that was given in [RFC2916]. RFC 3761 made a change to + the syntax of the Services field of the NAPTR that reflects a + refinement of the concept of ENUM processing. + + + +Conroy & Fujiwara Informational [Page 20] + +RFC 5483 ENUM Experiences March 2009 + + + As defined in [RFC3403], there is now a single identifier that + indicates the DDDS Application. In the obsolete specification + [RFC2915], there were zero or more "Resolution Service" identifiers + (the equivalent of the DDDS Application). The same identifier string + for the DDDS identifier or the Resolution Service is defined in both + the [RFC3761] and [RFC2916] specifications: "E2U". + + Also, [RFC3761] defines at least one but potentially several + Enumservice sub-fields; in the obsolete specification, only one + "protocol" sub-field was allowed. + + In many ways, the most important change for implementations is that + the order of the sub-fields has been reversed. [RFC3761] specifies + that the DDDS Application identifier is the leftmost sub-field, + followed by one or more Enumservice sub-fields, each separated by the + '+' character delimiter. [RFC2916] specified that the protocol sub- + field was the leftmost, followed by the '+' delimiter, in turn + followed by the "E2U" resolution service tag. + + [RFC2915] and [RFC2916] have been obsoleted by [RFC3401] - [RFC3404] + and by [RFC3761]. However, [RFC3824] suggests that ENUM clients + should be prepared to accept NAPTRs with the obsolete syntax. Thus, + an ENUM client implementation may have to deal with both forms. This + need not be difficult. For example, an implementation could process + the Services field into a set of tokens and expect exactly one of + these tokens to be "E2U". In this way, the ENUM client might be + designed to handle both the old and the current forms without added + complexity. + + To facilitate this method, IANA should reject any request to register + an Enumservice with the label "E2U". + + To summarise, ENUM clients MUST support ENUM NAPTRs according to + [RFC3761] syntax. ENUM clients SHOULD also support ENUM NAPTRs + according to the obsolete syntax of [RFC2916]; there are still zones + that hold "old" syntax NAPTRs. ENUM zones MUST NOT be provisioned + with NAPTRs according to the obsolete form, and MUST be provisioned + with NAPTRs in which the Services field is according to [RFC3761]. + +7. Collected Implications for ENUM Provisioning + + 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 + + + + +Conroy & Fujiwara Informational [Page 21] + +RFC 5483 ENUM Experiences March 2009 + + + mechanism ([RFC3492], [RFC3987]). Non-printable characters SHOULD + NOT be used, as ENUM clients may need to present NAPTR content in a + human-readable form. + + The case-sensitivity flag ('i') is inappropriate for ENUM, and SHOULD + NOT be provisioned into the Regexp field of E2U NAPTRs. + + ENUM zone provisioning systems SHOULD use '!' (U+0021) as their + Regexp delimiter character. + + 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 [RFC3402] + (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. + + 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. + + 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. + + Many apparent mistakes in ORDER and PREFERENCE/PRIORITY values have + been detected in provisioned ENUM zones. To avoid these common + interoperability issues, provisioning systems SHOULD NOT use + different ORDER field values for NAPTRs in a Resource Record Set + (RRSet). To generalise, all ENUM 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. + + 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. + + 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. + + + + +Conroy & Fujiwara Informational [Page 22] + +RFC 5483 ENUM Experiences March 2009 + + + 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). + + 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. + + 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 (see also Section 3). These + provisioning systems SHOULD check the back-reference replacement + patterns they use, ensuring that regular expression processing will + not produce excessive-length URIs. + + 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. + + 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. + + In a non-terminal NAPTR encountered in an ENUM query (i.e., one with + an empty Flags field), the Services field SHOULD be empty. + + A non-terminal NAPTR MUST include its target domain in the (non- + empty) Replacement field. This field MUST be interpreted as holding + the domain name 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. + + ENUM zones MUST NOT be provisioned with NAPTRs according to the + obsolete form, and MUST be provisioned with NAPTRs in which the + Services field is according to [RFC3761]. + +8. Collected Implications for ENUM Clients + + ENUM clients SHOULD NOT discard NAPTRs in which they detect + characters outside the US-ASCII printable range (0x20 to 0x7E + hexadecimal). + + + + + +Conroy & Fujiwara Informational [Page 23] + +RFC 5483 ENUM Experiences March 2009 + + + 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. + + ENUM clients SHOULD NOT assume that the delimiter is the last + character of the Regexp field. + + 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. + + ENUM clients SHOULD discard NAPTRs that have more or less than 3 + unescaped instances of the delimiter character within the Regexp + field. + + In the spirit of being liberal with what it will accept, if the + ENUM client is sure how the Regexp field should be interpreted, + then 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, then the client + must discard the NAPTR. + + 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 highest currently unprocessed ORDER field value. The + client SHOULD keep to the ORDER and PREFERENCE/PRIORITY values + specified by the Registrant. + + 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 randomising the order in which these are + processed, as intervening DNS Servers might have done this already). + + 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. + + 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. + + ENUM clients MUST be ready to process NAPTRs that use a different + character from '!' as their Regexp Delimiter without failure. + + + +Conroy & Fujiwara Informational [Page 24] + +RFC 5483 ENUM Experiences March 2009 + + + ENUM clients MUST be ready to process NAPTRs that have non-trivial + patterns in their ERE sub-field values without failure. + + ENUM clients MUST be ready to process NAPTRs with a DDDS Application + identifier other than 'E2U' without failure. + + ENUM clients MUST be ready to process NAPTRs with many copies of + back-reference patterns within the Repl sub-field without failure + (see also Section 3). + + 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 Resource Record Set (RRSet). + + When an ENUM client encounters a compound NAPTR (i.e., one containing + more than one Enumservice) and cannot process or cannot recognise 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. + + ENUM clients MUST support ENUM NAPTRs according to [RFC3761] syntax. + ENUM clients SHOULD also support ENUM NAPTRs according to the + obsolete syntax of [RFC2916]; there are still zones that hold "old" + syntax NAPTRs. + +8.1. Non-Terminal NAPTR Processing + + 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. + + ENUM clients SHOULD ignore any content of the Services field when + encountering a non-terminal NAPTR with an empty Flags field. + + ENUM clients receiving a non-terminal NAPTR with an empty Flags field + MUST treat the Replacement field as holding the domain name 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 domain name. 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. + + + + + + +Conroy & Fujiwara Informational [Page 25] + +RFC 5483 ENUM Experiences March 2009 + + + If a problem is detected when processing an ENUM query across + multiple domains (by following non-terminal NAPTR references), then + 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. + + If all NAPTRs in a domain traversed as a result of a reference in a + non-terminal NAPTR have been discarded, then 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). + + 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. + + Where 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, then 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. + +9. Security Considerations + + In addition to the security implications of recommendations in this + document, those in the basic use of ENUM (and specified in the + normative documents for this protocol) should be considered as well; + this document does not negate those in any way. + + The clarifications throughout this document are intended only as + that: clarifications of text in the normative documents. They do not + appear to have any security implications above those mentioned in the + normative documents. + + The suggestions in Section 2, Section 4, and Section 6 do not appear + to have any security considerations (either positive or negative). + + The suggestions in Section 5.2.2 are a valid approach to a known + security threat. It does not open an advantage to an attacker in + causing excess processing or memory usage in the client. It does, + however, mean that an ENUM client will traverse a "tight loop" of + non-terminal NAPTRs in two domains 5 times before the client detects + this as a loop; this does introduce slightly higher processing load + than would be provided using other methods, but avoids the risks they + incur. + + + + + +Conroy & Fujiwara Informational [Page 26] + +RFC 5483 ENUM Experiences March 2009 + + + As mentioned in Section 3, ENUM uses regular expressions to generate + URIs. Though it is a standard feature of DDDS, use of "non-greedy" + regular expressions with multiple back-reference patterns in the Repl + sub-field does create the potential for buffer-overrun attacks. + Provisioning system designers SHOULD be aware of this and SHOULD + limit the repeated use of back-reference replacement patterns. + Conversely, ENUM client implementers SHOULD avoid using fixed + character buffers when generating URIs from Repl sub-fields that + include Back-reference patterns, and MUST avoid failure in the case + of buffer exhaustion. + +10. Acknowledgements + + We would like to thank the various development teams who implemented + ENUM (both creation systems and clients) and who read the normative + documents differently -- without these differences it would have been + harder for us all to develop robust clients and suitably conservative + management systems. We would also thank those who allowed us to + check their implementations to explore behaviour; their trust and + help were much appreciated. + + In particular, thanks to Richard Stastny for his hard work on a + similar task, TS 102 172 [ETSI-TS102172] under the aegis of ETSI, and + for supporting some of the ENUM implementations that exist today. + + Finally, thanks for the dedication of Michael Mealling in giving us + such detailed DDDS specifications, without which the ENUM development + effort would have had a less rigorous framework on which to build. + This document reflects how complex a system it is: without the + intricacy of [RFC3401] - [RFC3404] and the work that went into them, + it could have been very difficult to ensure interoperability. + +11. References + +11.1. Normative References + + [E.164] ITU-T, "The International Public Telecommunication Number + Plan", Recommendation E.164, February 2005. + + [IEEE.1003-2.1992] + Institute of Electrical and Electronics Engineers, + "Information Technology - Portable Operating System + Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", + IEEE Standard 1003.2, January 1993. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + + + +Conroy & Fujiwara Informational [Page 27] + +RFC 5483 ENUM Experiences March 2009 + + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) + Part Two: The Algorithm", RFC 3402, October 2002. + + [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) + Part Three: The Domain Name System (DNS) Database", + RFC 3403, October 2002. + + [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) + Part Four: The Uniform Resource Identifiers (URI)", + RFC 3404, October 2002. + + [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) + Part Five: URI.ARPA Assignment Procedures", BCP 65, + RFC 3405, October 2002. + + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", + RFC 3490, March 2003. + + [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep + Profile for Internationalized Domain Names (IDN)", + RFC 3491, March 2003. + + [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in Applications + (IDNA)", RFC 3492, March 2003. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform + Resource Identifiers (URI) Dynamic Delegation Discovery + System (DDDS) Application (ENUM)", RFC 3761, April 2004. + + [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", + RFC 3966, December 2004. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + + + + +Conroy & Fujiwara Informational [Page 28] + +RFC 5483 ENUM Experiences March 2009 + + + [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRIs)", RFC 3987, January 2005. + +11.2. Informative References + + [ASCII] American National Standards Institute, "Coded Character + Set - 7-bit American Standard Code for Information + Interchange", ANSI X3.4, 1986. + + [ETSI-TS102172] + ETSI, "Minimum Requirements for Interoperability of + European ENUM Implementations", ETSI TS 102 172, + October 2004. + + [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer + (NAPTR) DNS Resource Record", RFC 2915, September 2000. + + [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, + September 2000. + + [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) + Part One: The Comprehensive DDDS", RFC 3401, October 2002. + + [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using + E.164 numbers with the Session Initiation Protocol (SIP)", + RFC 3824, June 2004. + + + + + + + + + + + + + + + + + + + + + + + + + +Conroy & Fujiwara Informational [Page 29] + +RFC 5483 ENUM Experiences March 2009 + + +Authors' Addresses + + Lawrence Conroy + Roke Manor Research + Roke Manor + Old Salisbury Lane + Romsey + United Kingdom + + Phone: +44-1794-833666 + EMail: lconroy@insensate.co.uk + URI: http://www.sienum.co.uk + + + Kazunori Fujiwara + Japan Registry Services Co., Ltd. + Chiyoda First Bldg. East 13F + 3-8-1 Nishi-Kanda Chiyoda-ku + Tokyo 101-0165 + JAPAN + + EMail: fujiwara@jprs.co.jp + URI: http://jprs.co.jp/en/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Conroy & Fujiwara Informational [Page 30] + |