[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-conroy-enum-experiences) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5483

ENUM                                                           L. Conroy
Internet-Draft                                                      RMRL
Expires: December 27, 2006                                   K. Fujiwara
                                                                    JPRS
                                                           June 25, 2006


               ENUM Implementation Issues and Experiences
                  <draft-ietf-enum-experiences-05.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document captures experience in implementing systems based on
   the ENUM protocol, and experience of ENUM data that have been created
   by others.  As such, it is advisory, and produced as a help to others
   in reporting what is "out there" and the potential pitfalls in
   interpreting the set of documents that specify the protocol.





Conroy & Fujiwara       Expires December 27, 2006               [Page 1]

Internet-Draft              ENUM Experiences                   June 2006


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Interpretation of Recommendations  . . . . . . . . . . . .  4
   3.  Character Sets and ENUM  . . . . . . . . . . . . . . . . . . .  6
     3.1.  Character Sets - Non-ASCII considered harmful  . . . . . .  6
     3.2.  Case Sensitivity . . . . . . . . . . . . . . . . . . . . .  9
     3.3.  RegExp field delimiter . . . . . . . . . . . . . . . . . .  9
     3.4.  RegExp Meta-character Issue  . . . . . . . . . . . . . . . 10
   4.  ORDER/PRIORITY Processing  . . . . . . . . . . . . . . . . . . 11
     4.1.  Order/Priority values - general processing . . . . . . . . 11
     4.2.  NAPTRs with identical ORDER/PRIORITY values  . . . . . . . 13
       4.2.1.  Compound NAPTRs and implicit ORDER/REFERENCE Values  . 13
     4.3.  Compound NAPTR Processing  . . . . . . . . . . . . . . . . 14
     4.4.  Processing Order value across Zones  . . . . . . . . . . . 14
   5.  Non-Terminal NAPTR Processing  . . . . . . . . . . . . . . . . 16
     5.1.  Non-Terminal NAPTRs - necessity  . . . . . . . . . . . . . 16
     5.2.  Non-Terminal NAPTRs - future implementation  . . . . . . . 17
       5.2.1.  Non-Terminal NAPTRs - general  . . . . . . . . . . . . 17
       5.2.2.  Non-Terminal NAPTRs - loop detection and response  . . 17
     5.3.  Interpretation of RFC 3403 and RFC 3761  . . . . . . . . . 18
       5.3.1.  Flags field content with Non-Terminal NAPTRs . . . . . 18
       5.3.2.  Services field content with Non-Terminal NAPTRs  . . . 18
       5.3.3.  Regular Expression and Replacement field content
               with non-terminal NAPTRs . . . . . . . . . . . . . . . 19
   6.  General DNS Issues . . . . . . . . . . . . . . . . . . . . . . 22
     6.1.  DNS Specifications . . . . . . . . . . . . . . . . . . . . 22
     6.2.  ENUM needs EDNS0 support . . . . . . . . . . . . . . . . . 22
     6.3.  ENUM EDNS0 message size support  . . . . . . . . . . . . . 24
     6.4.  Intermediary Devices . . . . . . . . . . . . . . . . . . . 25
     6.5.  Times To Live and NAPTRs . . . . . . . . . . . . . . . . . 26
   7.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . . 28
     7.1.  Services field syntax  . . . . . . . . . . . . . . . . . . 28
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 33
     11.2. Informative References . . . . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 36









Conroy & Fujiwara       Expires December 27, 2006               [Page 2]

Internet-Draft              ENUM Experiences                   June 2006


1.  Terminology

   This document is Advisory, and does not specify a standard of any
   kind.  Note that recommendations here contain the words "MUST",
   "REQUIRE", "SHOULD", and "MAY".  This particular document does not
   form a standard and so these terms DO NOT hold their normative
   definitions.  The proposals include these terms from observation of
   behaviour and for internal consistency, where Client and Server
   recommendations have to match.










































Conroy & Fujiwara       Expires December 27, 2006               [Page 3]

Internet-Draft              ENUM Experiences                   June 2006


2.  Introduction

   The ENUM protocol ([1]) and the Dynamic Delegation Discovery System
   (DDDS, [2] [3] [4] [5] [6]) are defined elsewhere, and those
   documents alone form the normative definition of the ENUM system.
   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.

   From experience of creating ENUM data and of developing client
   systems to process that data it is apparent that there are some
   subtleties in the specifications that have led to different
   interpretations; in addition there are common syntactic mistakes in
   data currently "out there" on the Internet.

   This document is intended to help others avoid the potential pitfalls
   in interpreting the set of documents that specify the protocol.  It
   also reports the kind of data they will "find" and so how to process
   the intent of the publisher of that ENUM data, regardless of the
   syntax used.  As such, it is in keeping with the principle evinced in
   RFC 791 that "In general, an implementation must be conservative in
   its sending behavior, and liberal in its receiving behavior".

   Of course, no client should fail if it receives data that is illegal;
   typical "defensive programming" techniques should be applied with
   ENUM clients as with any other protocol handler.  DNS processing does
   add some factors not typical for other protocols.  For example, it is
   legal (but unwise) for a string within a NAPTR to include a NUL
   character (U+0000).  Such a character can even legally be used as a
   delimiter in the RegExp field.  This may well cause problems for many
   clients that rely on simplistic 'C' string processing libraries.
   Whilst we advise specifically against that (see Section 3.3), and
   more generally, use of "non-printable" characters (see Section 3.1),
   a client may encounter these and must not assume that everyone shares
   the same assumptions on design or data validity; a string has a very
   specific meaning in DNS.  Finally, note that the DDDS system is
   intricate and so in some places there are several potential
   interpretations of the specifications.  This document proposes a
   suggested interpretation for some of these points, but they are just
   that; suggestions.

2.1.  Interpretation of Recommendations

   Any ENUM implementation issue has two sides:

   o  the "Server" side covering the expected behaviour of the ENUM zone
      provisioning system and expectations Registrants may make, and




Conroy & Fujiwara       Expires December 27, 2006               [Page 4]

Internet-Draft              ENUM Experiences                   June 2006


   o  the "Client" side covering behaviour that has been observed and
      that can be expected of the Client, together with the expectations
      that an end user who requests an ENUM lookup may make.

   For each of the issues, we have split the recommendations into
   "Client" and "Server" proposals.  In three cases, we have indicated
   proposals that relate to ENUMservice specifications, rather than
   implementations; these are labelled as "Spec".  Also, there is one
   recommendation that concerns "Middleboxes" (such as any intervening
   Firewalls) rather than the DNS entities involved directly in an ENUM
   query.  This recommendation is labelled as "MidBox".

   Few if any Client programs handling ENUM NAPTRs have implemented all
   of the features described in RFC 3761 and in the DDDS specifications.
   Thus the recommendations have tried to follow best practice rather
   than leaving interpretation to each of the individual implementation
   teams.  Likewise, we have reflected the likely behaviour of Client
   programs, rather than being purely prescriptive.  Any developer of
   Provisioning Systems that populate ENUM NAPTRs will need to know what
   his or her "opposite number" developing Client programs has decided -
   to do anything else would be a disservice.

   There are undoubtedly other issues, and developers are asked to raise
   any others they find on the appropriate IETF Working group's mailing
   list and/or by e-mail to the authors (see later for contact
   information).  Finally, note that the authors are not aware of any
   IPR issues that are involved in the suggestions made in this
   document.























Conroy & Fujiwara       Expires December 27, 2006               [Page 5]

Internet-Draft              ENUM Experiences                   June 2006


3.  Character Sets and ENUM

3.1.  Character Sets - Non-ASCII considered harmful

   RFC 3761 and RFC 3403 ([1] and [2]) specify respectively that ENUM
   and NAPTRs support Unicode using the UTF-8 encoding specified in [7].
   This raises an issue where 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 [20] 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.  Similarly, if NAPTR content
   is shown to an end user so that he or she may choose, it is important
   that the content is "human readable".  Thus it is unwise to use non-
   printable characters 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
   as string processing should not be applied to them.  The "string
   based" fields are the Flags, Services, and RegExp fields.  The
   Replacement field holds a domain name encoded according to the
   standard DNS mechanism [8][9].  With the introduction of
   Internationalized Domain Name (IDN) support, this domain name MUST be
   further encoded using Punycode [10].  As this 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
   character as specified in RFC 3761.  These characters all fall into
   the US-ASCII equivalent range, so multi-byte characters cannot occur.

   The Services field includes the DDDS Application identifier ("E2U")



Conroy & Fujiwara       Expires December 27, 2006               [Page 6]

Internet-Draft              ENUM Experiences                   June 2006


   used for ENUM, the '+' character used to separate tokens, and a set
   of ENUMservice identifiers, any of which may include the ':'
   separator character.  In section 2.4.2 of RFC 3761 these identifiers
   are specified as 1*32 ALPHA/DIGIT, so there is no possibility of non-
   ASCII characters in the Services field.

   The RegExp field is more complex.  It forms a sed-like substitution
   expression, defined in [2], and consists of two sub-fields:

   o  the POSIX Extended Regular Expression (ERE) sub-field [11]

   o  a replacement (repl) sub-field [2].

   Additionally, RFC 3403 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 later in this
   document.

   The ERE sub-field matches against the "Application Unique String";
   for ENUM, this is defined in RFC 3761 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 [12], but with
   visual-separators removed.  In short, it is a telephone number (see
   [13]) 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.  Thus, for ENUM, there will be no
   multi-byte characters within this sub-field.

   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 RFC 3403.  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 [14] 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 characters will be pre-processed; they will not occur in
   the explicit text used to construct a URI within the repl sub-field.
   However, the Internationalized Resource Identifier (IRI) is defined
   in [15] as extending the syntax of URIs, and specifies a mapping from
   an IRI to a URI.  IRI syntax allows characters with multi-byte UTF-8
   encoding.

   Given that this is the only place within an ENUM NAPTR where such



Conroy & Fujiwara       Expires December 27, 2006               [Page 7]

Internet-Draft              ENUM Experiences                   June 2006


   multi-byte encodings might reasonably be found, a simple solution is
   to use the mapping method specified in section 3.1 of [15] 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 the IRI document 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.

   Taking into account the existing client base, it is RECOMMENDED that:

     Spec    ENUMservice registrations should REQUIRE that any static
             text in the repl sub-field is encoded using only characters
             in the US-ASCII equivalent range that are "printable".  If
             any of the static text characters do fall outside this
             range then they MUST be pre-processed using an IRI/
             URI-specific "escape" mechanism to re-encode them only
             using US-ASCII equivalent printable characters (those in
             the range U+0020 to U+007E).

   At the least, it is RECOMMENDED that:

     Spec    Any ENUMservice registration that allows characters
             requiring multi-byte UTF-8 encoding to be present in the
             repl sub-field must have a clear indication that there may
             be characters outside of the US-ASCII equivalent range.
             Such an ENUMservice registration is strongly discouraged,
             as the mechanisms specified in section 3.1 of [15] will
             suffice.

   Finally, the majority of ENUM clients in use today do not support
   multi-byte encodings of the Unicode Consortium's Universal Character
   Set (UCS).  This is a reasonable choice, particularly for "small
   footprint" implementations, and they may not be able to support NAPTR
   content that is non-printable as they need to present the content to
   an end user for selection.  Thus, it is RECOMMENDED that:

     Client  ENUM clients may discard NAPTRs in which they detect
             characters not in the US-ASCII "printable" range (0x20 to
             0x7E hexadecimal).

   ENUM zone provisioning systems should consider this.  It is
   RECOMMENDED that:





Conroy & Fujiwara       Expires December 27, 2006               [Page 8]

Internet-Draft              ENUM Experiences                   June 2006


     Server  ENUM zone provisioning systems should not use non-ASCII
             characters in the NAPTRs they generate unless it is clear
             that all ENUM clients they are designed to support will be
             able correctly to process such characters.

3.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.  Thus this flag is redundant for E2U NAPTRs, as it does
   not act on the repl sub-field contents.

   To avoid the confusion that this generates, It is RECOMMENDED that:

     Server  When populating ENUM zones with NAPTRs, provisioning
             systems should not use the 'i' RegExp field flag, as it has
             no effect and some ENUM clients do not expect it.

     Client  ENUM clients should not assume that the delimiter is the
             last character of the field.

3.3.  RegExp field delimiter

   It is not possible to select a delimiter character that cannot appear
   in one of the sub-fields.  Some old clients are "hardwired" to expect
   the character '!' as a delimiter.  This is used in an example in RFC
   3403.

   It is RECOMMENDED that:

     Server  ENUM zone provisioning systems should use '!'  (U+0021) as
             their RegExp delimiter character.

     Client  ENUM clients may discard NAPTRs that do not use '!' as a
             RegExp delimiter.

   This character cannot 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).  Thus, it is further RECOMMENDED that:







Conroy & Fujiwara       Expires December 27, 2006               [Page 9]

Internet-Draft              ENUM Experiences                   June 2006


     Server  ENUM zone provisioning systems must ensure that, 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 RFC 3402 (i.e. "\!", U+005C U+0021).

   Finally, in keeping with RFC 3402:

     Client  ENUM clients should discard NAPTRs that have more or less
             than 3 "unescaped" instances of the delimiter character
             within the RegExp field.

3.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 as '+' is a meta-character in POSIX Extended
   Regular Expression syntax.

   The following NAPTR example is incorrect:

   * IN NAPTR 100 10 "u" "E2U+sip" "!^+46555(.*)$!sip:\1@example.net!" .

   This example MUST be written as:

   * IN NAPTR 100 10 "u" "E2U+sip" "!^\+46555(.*)$!sip:\1@example.net!"
   .

   Thus, it is RECOMMENDED that:

     Server  If present in the ERE sub-field of an ENUM NAPTR, '+' must
             be written as "\+" (i.e.  U+005C U+002B).


















Conroy & Fujiwara       Expires December 27, 2006              [Page 10]

Internet-Draft              ENUM Experiences                   June 2006


4.  ORDER/PRIORITY Processing

4.1.  Order/Priority values - general processing

   RFC 3761 and RFC 3403 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 less
   preferred ORDER values must only be dealt with once the current ones
   with a "winning" ORDER value have been processed.

   However, this expected behaviour is a simplification; ENUM clients
   may not behave this way in practice, and so there is a conflict
   between the specification and practice.  For example, ENUM clients
   will be incapable of using most NAPTRs as they do not support the
   ENUMservice (and the URI generated by those NAPTRs).  As such, they
   will discard the "unusable" NAPTRs and continue with processing the
   "next best" NAPTR in the list.

   The end user may have pre-specified his or her own preference for
   services to be used.  Thus, an end user may specify that he or she
   would prefer to use contacts with a "sip" ENUMservice, and then those
   with "email:mailto" service, and is not interested in any other
   options.  Thus the sorted list as proposed by the Registrant (and
   published via ENUM) may be reordered.  For example, a NAPTR with a
   "sip" ENUMservice may have a "losing" ORDER field value, and yet is
   chosen before a NAPTR with an "h323" ENUMservice and a "winning"
   ORDER value.  This may occur even if the node the end user controls
   is capable of handling other ENUMservices.

   ENUM clients may also include the end user "in the decision loop",
   offering the end user the choice from a list of possible NAPTRs.
   Given that the ORDER field value is the major sort term, one would
   expect a conforming ENUM client to present only those NAPTRs with a
   "winning" ORDER field value as choices.  However, if all the options
   presented 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
   "in one go".

   In summary, some ENUM clients will take into account the Services
   field value along with the ORDER and PREFERENCE/PRIORITY field
   values, and may consider the preferences of the end user.

   The Registrant and the ENUM zone provisioning system he or she uses
   must be aware of this and should not rely on ENUM clients taking



Conroy & Fujiwara       Expires December 27, 2006              [Page 11]

Internet-Draft              ENUM Experiences                   June 2006


   account of the value of the ORDER and the PREFERENCE/PRIORITY fields.

   Specifically, it is unsafe to assume that a ENUM client will not
   consider another NAPTR until it has discarded one with a "winning"
   ORDER value.  The instruction (in RFC 3403 section 4.1 and section 8)
   may or may not be followed strictly by different ENUM clients for
   perfectly justifiable reasons.

   To avoid the risk of variable behaviour, it is RECOMMENDED that:

     Server  ENUM zone provisioning systems should not use different
             ORDER values for NAPTRs within a zone.

   In our experience, incorrect ORDER values in ENUM zones is a major
   source of problems.  Although it is by no means required, it is
   further RECOMMENDED that:

     Server  ENUM zone provisioning systems should use a value of 100 as
             the default ORDER value to be used with all NAPTRs.

   As such, when populating a zone with NAPTRs, it is RECOMMENDED that:

     Server  A Registrant should not expect the ENUM client to ignore
             NAPTRs with higher ORDER field values - the "winning" ones
             may have been discarded.

     Server  A Registrant should not expect ENUM clients to conform to
             the ORDER and PREFERENCE/PRIORITY sort order he or she has
             specified for NAPTRs; end users may have their own
             preferences for ENUMservices.

     Client  Each ENUM client may reorder the NAPTRs it receives only to
             match an explicit preference pre-specified by its end user.

     Client  ENUM clients that offer a list of contacts to the end user
             for his or her choice may present all NAPTRs, not just the
             ones with the highest currently unprocessed ORDER field
             value.

     Server  A Registrant should not assume which NAPTR choices will be
             presented "at once".

   The impact of this is that a Registrant should place into his or her
   zone only contacts that he or she is willing to support; even those
   with the "least preferred" ORDER and PREFERENCE/PRIORITY values may
   be selected by an end user.

   Finally, we have noticed a number of ENUM zones with NAPTRs that have



Conroy & Fujiwara       Expires December 27, 2006              [Page 12]

Internet-Draft              ENUM Experiences                   June 2006


   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.

   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.

4.2.  NAPTRs with identical ORDER/PRIORITY values

   From experience, 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 occur.
   However, in the spirit of being liberal in what is allowed:

   It is RECOMMENDED that:

     Client  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 may
             do this already).

   Conversely, populating the records with these identical values is
   unwise, as it may lead to indeterminate client behaviour, and so it
   is RECOMMENDED that:

     Server  When populating ENUM zones with NAPTRs, ENUM zone
             provisioning systems should not have more than one NAPTR
             with the same ORDER and the same PREFERENCE/PRIORITY field
             values in any given zone, as ENUM clients may reject the
             response, and the sequence in which these NAPTRs are
             delivered to the client may vary.

4.2.1.  Compound NAPTRs and implicit ORDER/REFERENCE Values

   There is one special case in which one could derive a set of NAPTRs
   with identical ORDER and identical PREFERENCE/PRIORITY fields.  This
   will not exist explicitly in the Resource Record Set ("RRSet")
   delivered to the client, but may occur whilst processing a "Compound"
   NAPTR, and is dealt with next.






Conroy & Fujiwara       Expires December 27, 2006              [Page 13]

Internet-Draft              ENUM Experiences                   June 2006


4.3.  Compound NAPTR Processing

   With RFC 3761, it is possible to have more than one ENUMservice
   associated with a single NAPTR.  Of course, the different
   ENUMservices share the same RegExp field and so generate the same
   URI.  Such a "compound" NAPTR could well be used to indicate, for
   example, a mobile phone that supports both "voice:tel" and "sms:tel"
   ENUMservices.

   This compound NAPTR may be reconstructed into a set of NAPTRs each
   holding a single ENUMservice.  However, in this case the members of
   this set all logically hold the same ORDER and PREFERENCE/PRIORITY
   field values.

   In this case, it is RECOMMENDED that:

     Client  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.

     Server  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.

   As a final point on ENUM client processing of compound NAPTRs, it is
   quite possible that the client is incapable of processing one of the
   ENUMservices indicated.

   To clarify, it is RECOMMENDED that:

     Client  When an ENUM client encounters a compound NAPTR and cannot
             process one of the ENUMservices within it, that ENUM client
             should ignore it 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.

4.4.  Processing Order value across Zones

   Using a different ORDER field value in different zones is unimportant
   for most queries.  However, DDDS includes a mechanism for continuing
   a search for NAPTRs in another zone by including a reference to that
   other zone in a "non-terminal" NAPTR.  The treatment of non-terminal
   NAPTRs is covered in the next section, but if these are supported
   then it does have a bearing on the way that ORDER and PREFERENCE/
   PRIORITY field values are processed.




Conroy & Fujiwara       Expires December 27, 2006              [Page 14]

Internet-Draft              ENUM Experiences                   June 2006


   Two main questions remain from the specifications of DDDS and RFC
   3671:

   o  If there is a different (lower) order field value in a zone
      referred to by a non-terminal NAPTR, then does this mean that the
      ENUM client discards any remaining NAPTRs in the referring zone?

   o  Conversely, if the zone referred to by a non-terminal NAPTR
      contains entries that have a higher ORDER field value, then does
      the ENUM client ignore those NAPTRs in the referenced zone?

   Whilst one interpretation of section 1.3 of RFC 3761 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.

   Thus, to reflect the interpretation that is made by those systems
   that have implemented non-terminal NAPTRs, it is RECOMMENDED that:

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



     Client  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.

















Conroy & Fujiwara       Expires December 27, 2006              [Page 15]

Internet-Draft              ENUM Experiences                   June 2006


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 "points to" 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
   "pointed to" 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 forms 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" 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, most existing ENUM clients do not support non-terminal
   NAPTRs and ignore them if received.  To avoid interoperability
   problems, some kind of acceptable requirement is needed on non-
   terminal NAPTRs.  Given the lack of current support and the issues
   raised, we propose that in general one should not use non-terminal
   NAPTRs in ENUM.

   Thus, it is RECOMMENDED that:



Conroy & Fujiwara       Expires December 27, 2006              [Page 16]

Internet-Draft              ENUM Experiences                   June 2006


     Server  ENUM zone provisioning systems should not generate non-
             terminal NAPTRs (i.e.  NAPTRs with an empty Flags field)
             unless it is clear that all ENUM clients they are designed
             to support can process these.

     Client  ENUM clients may discard non-terminal NAPTRs (i.e. they may
             only support ENUM NAPTRs with a Flags field value of "u").

5.2.  Non-Terminal NAPTRs - future implementation

   The following specific issues need to be considered if non-terminal
   NAPTRs are to be supported in the future.  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 zone refers to the
   NAPTRs contained in another zone.  The NAPTRs in the zone referred to
   by the non-terminal NAPTR may have a different ORDER value from that
   in the referring non-terminal NAPTR.  See Section 4.4 for details.

   In addition, to Clarify, it is RECOMMENDED that:

     Client  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).

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, this implies a "non-terminal
   loop".  To ensure consistent behaviour, it is RECOMMENDED that:

     Client  ENUM clients should consider that processing a chain of
             more than 5 "non-terminal" NAPTRs in a single ENUM query
             indicates that a loop may have been detected, and act
             accordingly.







Conroy & Fujiwara       Expires December 27, 2006              [Page 17]

Internet-Draft              ENUM Experiences                   June 2006


     Server  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.



     Client  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 "non-terminal 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.

5.3.  Interpretation of RFC 3403 and RFC 3761

   The set of specifications defining DDDS and its applications are
   complex and multi-layered.  This reflects the flexibility that the
   system provides, but it does mean that some of the specifications
   need clarification as to their interpretation, particularly where
   non-terminal rules are concerned.

5.3.1.  Flags field content with Non-Terminal NAPTRs

   RFC 3761, section 2.4.1 states that the only flag character valid for
   use with the "E2U" DDDS Application is 'u'.  The flag 'u' is defined
   (in RFC 3404 [5], section 4.3) thus: 'The "u" flag means that the
   output of the Rule is a URI'.

   RFC 3761 section 2.4.1 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 RFC 3404.  One
   could well argue that this is a feature potentially common to all
   DDDS Applications, and so should have been specified in RFC 3402 or
   RFC 3403.

5.3.2.  Services field content with Non-Terminal NAPTRs

   Furthermore, RFC 3761 section 3.1.1 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 there can be no valid (non-empty) Services



Conroy & Fujiwara       Expires December 27, 2006              [Page 18]

Internet-Draft              ENUM Experiences                   June 2006


   field content for a NAPTR to be used with the "E2U" DDDS application.
   Section 2.4.2 of RFC 3761 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 can be
   no definition of a non-terminal ENUMservice (and so no such
   Registered ENUMservice identifier), this syntax cannot be met with a
   non-terminal NAPTR.

   A reasonable interpretation of the specifications in their current
   state is that 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.  To ensure
   consistent behaviour, it is RECOMMENDED that:

     Client  ENUM clients should ignore any content of the Services
             field when encountering a non-terminal NAPTR with an empty
             Flags field.

     Server  ENUM zone provisioning systems should ensure that the
             Services field of any non-terminal NAPTR (with an empty
             Flags field) is also empty.

5.3.3.  Regular Expression and Replacement field content with non-
        terminal NAPTRs

   The descriptive text in section 4.1 of RFC 3403 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.

   RFC 3403 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, is does
   not specify which is used with terminal and non-terminal rules.

   The descriptive text of section 4.1 of RFC 3403 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



Conroy & Fujiwara       Expires December 27, 2006              [Page 19]

Internet-Draft              ENUM Experiences                   June 2006


   were to 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.

   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 to specify 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 the expected output).  ENUM (as specified
   in section 2.4.1 of RFC 3761) specifies 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 examples "out in the wild".  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.

   In keeping with current implementations, we suggest that a non-
   terminal NAPTR with an empty Flags field must be provisioned using
   the (non-empty) Replacement element to hold the domain name that
   forms the "next key" output from this non-terminal rule.

   Thus it is RECOMMENDED that:

     Client  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, and



Conroy & Fujiwara       Expires December 27, 2006              [Page 20]

Internet-Draft              ENUM Experiences                   June 2006


             should be ignored by ENUM clients

     Server  with an empty Flags field into an ENUM zone must ensure
             that the "target" domain name is set into the Replacement
             field of this NAPTR.  It must not use the RegExp field in
             such a non-terminal NAPTR.

   In the future, it would be possible to update RFC 3761 (sections
   3.1.1 and 2.4.1) to add a new flag to indicate a non-terminal NAPTR,
   and to change the ENUMservice template to permit specification of an
   ENUMservice that operates with this new flag in non-terminal NAPTRs.
   In doing this, it would be possible to include a syntactically valid
   non-empty Services field in such non-terminal NAPTRs.  To
   differentiate from the case of an empty Flags field, this new flag
   could also indicate that the RegExp field was to be non-empty, and to
   be processed - by implication, this would mean that the Replacement
   field would be empty.  However, such a change would require an update
   to RFC 3761, and so will have to wait.

































Conroy & Fujiwara       Expires December 27, 2006              [Page 21]

Internet-Draft              ENUM Experiences                   June 2006


6.  General DNS Issues

   Whilst these issues covered in this section are not ENUM-specific,
   they do "bite" when developing ENUM-aware systems, and are important
   for ENUM deployment.  This section makes strong recommendations over
   support for EDNS0 and TCP.  These are crucial, as they will have a
   major impact on ENUM deployments, particularly when ENUM Clients are
   connected to the Internet over access networks that exhibit higher
   latencies (such as cellular mobile networks, where latencies can be
   of the order of hundreds of milliseconds or more).

   In addition, there are several elements of behaviour of the DNS that
   can complicate testing.  As advice to developers, some of the more
   subtle issues are covered here, gleaned from the experience of those
   groups already developing and deploying ENUM systems.

6.1.  DNS Specifications

   The DNS protocol is defined in RFC 1034 [8] and RFC 1035 [9], and is
   clarified in RFC 2181 [16], whilst Requirements for Internet Hosts
   are specified in RFC 1123 [17].  Security threats to DNS are covered
   in RFC 3833 [21], and DNSSEC (DNS Security) is specified in RFC 4033
   [22], RFC 4034 [23], and in RFC 4035 [24], whilst EDNS0 (an extension
   mechanism for DNS) is specified in RFC 2671 [18].

   Supporting UDP queries is mandatory, but support for TCP queries is
   recommended also, and is (in effect) required as RFC 1123 requires
   that a DNS client discard a truncated response sent in response to
   its initial (UDP) query and retry using another transport protocol.
   In effect, Authoritative Name Servers that do not answer TCP queries
   after returning truncated responses are not able to answer queries
   correctly.

   Amongst other things, the EDNS0 mechanism allows the querying client
   to indicate the size of UDP packet that it can process.  RFC 1035
   restricts the maximum size of a UDP DNS response to 512 bytes.  This
   limit has proven to be too low for reasonably sized NAPTR Resource
   Record Sets.  EDNS0 provides a mechanism for DNS clients and servers
   to use larger UDP payloads.  Partially due to the larger response
   sizes involved and the need for extended flags, support for DNSSEC
   also requires the use of EDNS0.

6.2.  ENUM needs EDNS0 support

   The performance of ENUM resolution is much reduced if a mechanism to
   handle larger responses efficiently is not available.  ENUM RRSets
   often have more records than will fit into a basic "RFC 1035" UDP
   response.  EDNS0 (as specified in RFC 2671 [18]) with a suitably



Conroy & Fujiwara       Expires December 27, 2006              [Page 22]

Internet-Draft              ENUM Experiences                   June 2006


   large buffer size is the current official mechanism to support these
   larger messages with maximum efficiency.  Lack of EDNS0 support and
   use of its size option by querying clients causes degradation of the
   system by requiring retransmission via TCP once a basic RFC 1035 UDP
   query results a "truncated" error response from the queried DNS
   Server.  As ENUM RRSets typically contain more records than are
   returned for other queries, this is a much more frequent condition.
   Processing truncated responses adds latency to ENUM resolution and
   may consume excessive TCP resources on the DNS Server, such as data
   structures needed to maintain connection state.

   (see section 4.2.2 of [9] for the requirement for a DNS server to
   leave each TCP port used for queries open for several minutes,
   otherwise relying on the client to close the port explicitly when no
   longer needed).

   The impact of larger response messages where EDNS0 is not used can be
   significant.  Instead of two messages (the query indicating EDNS0
   support, and its response, using EDNS0), if the method described in
   RFC 1035 and RFC 1123 is used there will be many more - two messages
   for the query and the truncated UDP response, several messages to
   make the TCP connection, at least one for the query, and at least one
   for the response, with several more messages being needed to tear
   down the TCP connection.  Especially if these messages are exchanged
   via an access network with significant latency for data transport,
   the total time needed to perform ENUM resolution can be excessive (of
   the order of seconds over a cellular access network), and much more
   than would be needed for the UDP query.  In practice, not using EDNS0
   where clients may be connected via these networks means that ENUM
   deployment will not meet acceptable performance targets for RRSets
   with larger sets of records.

   Note that this is not ENUM-specific but instead a standard feature of
   DNS - it just comes into play more often with ENUM and other queries
   that return large response messages.

   Thus to ensure efficient resolution of ENUM queries, it is
   RECOMMENDED that:

     Server  All servers involved in ENUM resolution that carry messages
             including NAPTR RRsets must support EDNS0.

     Client  ENUM Clients should use EDNS0 in their queries.  The sole
             exception to this is when the Client knows that a server
             does not support EDNS0 (due to some misconfiguration).
             This adaptation is normal behaviour for a DNS Resolver that
             supports EDNS0 (see section 5 of [18]).




Conroy & Fujiwara       Expires December 27, 2006              [Page 23]

Internet-Draft              ENUM Experiences                   June 2006


6.3.  ENUM EDNS0 message size support

   The next issue has no deterministic answer.  Whilst it is impossible
   to be definitive over the size of messages exchanged during ENUM
   resolution, it is possible to state that the message sizes are
   considerably larger than has typically been the case for most DNS
   queries so far.  Selecting appropriate sizes for EDNS0 support aims
   to ensure that the percentage of queries that still require a
   "fallback" to TCP is minimal for all realistically populated ENUM
   RRSets.

   In practice, zones "seen" so far have rarely required more than 2
   kilobytes in response size.  However, with the introduction of IPv6
   and DNSSEC support, this is very likely to increase in the near
   future, so we recommend that ENUM Clients should indicate their
   support for a larger buffer size than might be necessary at this
   point.  It should be noted that the penalty of choosing too low a
   size for EDNS0 support may be even more severe that the standard
   method described in RFC 1035 and RFC 1123.  Thus it is good practice
   to select a larger size than is likely to be needed, to counteract
   that greater cost where fallbacks still occur.  Sections 2.4 and
   particularly 2.5 of [24] explain the rationale for using the size
   option of EDNS0 for queries that return larger responses.  In that
   document, section 3.1 describes expected server behaviour, section
   4.1 describes expected Resolver behaviour, whilst section 3
   summarises the proposed message sizes to be supported by Servers and
   Resolvers.  These same size recommendations are repeated here, as it
   is felt that ENUM already has a similar issue with larger responses,
   and will certainly need the larger messages sizes with the
   introduction of IPv6 and DNSSEC support.

   It is RECOMMENDED that:

     Client  An ENUM Client should be willing to handle DNS responses of
             up to 4000 bytes in length, and should indicate in its
             queries that it supports responses up to 4000 bytes in
             length using the EDNS0 technique specified in [18].

   It is further RECOMMENDED that:

     Client  An ENUM Client should consider an indicated supported value
             of 1220 bytes in its EDNS0 queries to be a bare minimum
             whilst avoiding fragmentation of response packets over most
             deployed networks.







Conroy & Fujiwara       Expires December 27, 2006              [Page 24]

Internet-Draft              ENUM Experiences                   June 2006


6.4.  Intermediary Devices

   From our experiences a Name Server may support TCP queries, but there
   may well be an intervening packet filter that does not allow TCP
   traffic to pass correctly.  It is unfortunately common for people
   managing a firewall to block traffic to or from the DNS TCP port
   without considering the impact.  Thus if TCP queries do not seem to
   work, it is worthwhile considering this possibility; the Name Server
   may be operating correctly, but the TCP SYN or SYN-ACK packets may be
   blocked, effectively disabling the Server from contact with the World
   beyond the firewall.

   An incorrect assumption is made by some deployed packet filters that
   MAY affect transport of EDNS0 responses.  It has been noticed that
   some older equipment may be configured by default to discard all UDP
   packets containing DNS messages if these are more than 512 bytes in
   size.  Since the introduction of EDNS0 in 1999, such a configuration
   has been and is incorrect.  Both of these behaviours can be very hard
   to debug.

   In particular, odd behaviour has been detected within several
   cellular networks that claim to provide Internet access; it appears
   that these networks include firewalls or application level proxies
   that do not handle larger DNS messages carried over UDP well.  This
   is a basic error in network infrastructure configuration that may
   affect their customers, particularly when these customers attempt
   ENUM resolution.  Experimental results have shown that such access
   network components typically seem to behave as "transparent" proxies
   for all traffic sent to the default DNS port (port 53), discarding
   larger packets regardless of content.

   Thus, although it should be obvious, we RECOMMEND that:

   MidBox    Name Servers should support TCP queries, and must support
             EDNS0 if they are to host ENUM data.  Thus intermediate
             systems such as firewalls should not be configured to
             filter traffic to or from a Name Server; notably, these
             should not block TCP transport for DNS queries, and must
             not simply block DNS messages of greater than 512 bytes in
             size without examining them for correct EDNS0 support.
             Note that this may require stateful packet inspection.

   Unfortunately, it is still necessary to note that:

     Client  Developers of ENUM clients should be aware of these
             potential problems and clients must be able to adapt to
             such misconfigured systems, in accordance with RFC 2671
             [18].  However, developers should also be aware that, in



Conroy & Fujiwara       Expires December 27, 2006              [Page 25]

Internet-Draft              ENUM Experiences                   June 2006


             the case of malfunctioning intermediary systems, the
             proposal made there (to "probe" for DNS server capability
             prior to placing requests) may not succeed in exposing an
             infrastructure that will disable normally functioning
             servers.  Small "probe" messages may pass, indicating EDNS0
             support, whilst longer messages in subsequent queries do
             not.

6.5.  Times To Live and NAPTRs

   Section 5.2 of [16] clarifies the normal operation of DNS where more
   than one Resource Record (RR) is returned in a response.  It defines
   the requirement that Time To Live (TTL) values must be the same in
   those circumstances, and the treatment by Resolvers of response
   messages containing sets of Resource Records.  As a query on an ENUM
   zone for NAPTRs will typically return a set of resource records
   consisting of more than one record, this has an impact on ENUM
   processing, and it is worth exploring it in this document.

   It is important that all NAPTRs in a zone have Time To Live fields
   set to the same value, or else "strange things" will happen with
   Recursive Resolvers that are hard to debug.  A query for type NAPTR
   will return the available collection of such RRs.  From the
   perspective of the Recursive Resolver, if records in this set have
   different TTL, then the zone will be re-queried only once ALL queried
   Records have expired.

   Given this behaviour by DNS Resolvers, it is unwise to have different
   TTL in the various NAPTRs in a zone.  Some of these resource records
   will seem to "disappear" over time from the list of available records
   returned and that will lead to variable and often unexpected
   behaviour - if nothing else, it may well confuse the end user as the
   list of options he or she is offered grows and shrinks.

   This is true for RR type-specific queries, but it is also true for
   general queries within a zone.  For example, a DNS query with a Query
   Type value of 255 asks for "ANY Resource Records for that domain name
   that you you have".  Thus if a Recursive Resolver holds RRs for a
   zone in its cache, and a cached RR from that zone has a long TTL,
   then it will be returned even after others have expired - no onward
   query will be made unless there are no RRs at all available at the
   Recursive Resolver for the queried zone.  In this case, however, the
   TTL of ALL the records that may well exist in a queried zone have to
   be taken into account, rather than just those of the NAPTR records
   themselves.  This may well not be the case, so this kind of query
   should be avoided.

   In summary, in keeping with the standards:



Conroy & Fujiwara       Expires December 27, 2006              [Page 26]

Internet-Draft              ENUM Experiences                   June 2006


     Server  ENUM provisioning systems must follow the guidance of
             section 5.2 of RFC 2181 [16].  All TTL values must be
             identical for Resource Records of a given class and type.

     Client  ENUM clients must follow the guidance of section 5.2 of RFC
             2181 [16].

     Client  ENUM clients should not issue queries with Query Type = 255
             (commonly known as an 'ANY' query), as the results may well
             be unexpected.









































Conroy & Fujiwara       Expires December 27, 2006              [Page 27]

Internet-Draft              ENUM Experiences                   June 2006


7.  Backwards Compatibility

7.1.  Services field syntax

   RFC 3761 is the current standard for the syntax for NAPTRs supporting
   the ENUM DDDS application.  This obsoletes the original specification
   that was given in RFC 2916.  There has been a change to the syntax of
   the Services field of the NAPTR that reflects a refinement of the
   concept of ENUM processing.

   As defined in RFC 3403, there is now a single identifier that
   indicates the DDDS Application.  In the obsolete specification (RFC
   2915), there were zero or more "Resolution Service" identifiers (the
   equivalent of the DDDS Application).  The same identifier string is
   defined in both RFC 3761 and in the old RFC 2916 specifications for
   the DDDS identifier or the Resolution Service; "E2U".

   Also, RFC 3761 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.  RFC 3761 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.  RFC 2916 specified that the protocol sub-
   field was the leftmost, followed by the '+' delimiter, in turn
   followed by the "E2U" resolution service tag.

   RFC 2915 and RFC 2916 have been obsoleted by RFC 3401 - RFC 3404 and
   by RFC 3761.  Thus it is RECOMMENDED that:

     Server  ENUM zone provisioning systems must not generate NAPTRs
             according to the syntax defined in RFC 2916.  All zones
             must hold ENUM NAPTRs according to RFC 3761 (and
             ENUMservice specifications according to the framework
             specified there).

   However, RFC 3824 [19] 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.

   It is RECOMMENDED that:

     Client  ENUM clients must support ENUM NAPTRs according to RFC 3761
             syntax.  ENUM clients should also support ENUM NAPTRs
             according to the obsolete syntax of RFC 2916; there are
             still zones that hold "old" syntax NAPTRs.



Conroy & Fujiwara       Expires December 27, 2006              [Page 28]

Internet-Draft              ENUM Experiences                   June 2006


   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.

   There is one subtle implication of this scheme.  It is RECOMMENDED
   that:

     Spec    Registrations for an ENUMservice with the type string of
             "E2U" and an empty sub-type string must not be accepted.








































Conroy & Fujiwara       Expires December 27, 2006              [Page 29]

Internet-Draft              ENUM Experiences                   June 2006


8.  Security Considerations

   This document does not specify any standard.  It does however make
   some recommendations, and so the implications of following those
   suggestions have to be considered.

   In addition to these issues, 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 3, Section 4, and Section 7 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       Expires December 27, 2006              [Page 30]

Internet-Draft              ENUM Experiences                   June 2006


9.  IANA Considerations

   This document is only advisory, and does not include any IANA
   considerations other than the proposals labelled as "Spec".  These
   are the recommendation (in Section 3.1) that ENUMservice
   Registrations should at least indicate if characters outside of the
   US-ASCII equivalent range are permitted, and the suggestion (at the
   end of Section 7.1) that no-one should specify an ENUMservice with
   the identifying tag "E2U".










































Conroy & Fujiwara       Expires December 27, 2006              [Page 31]

Internet-Draft              ENUM Experiences                   June 2006


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 [25] 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 rigourous framework on which to build.
   This document reflects how complex a system it is: Without the
   intricacy of RFC 3401 - RFC 3404 and the work that went into them, it
   could have been quite different.































Conroy & Fujiwara       Expires December 27, 2006              [Page 32]

Internet-Draft              ENUM Experiences                   June 2006


11.  References

11.1.  Normative References

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

   [2]   Mealling, M., "Dynamic Delegation Discovery System (DDDS)  Part
         Three: The Domain Name System (DNS) Database", RFC 3403,
         October 2002.

   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS)  Part
         One: The Comprehensive DDDS", RFC 3401, October 2002.

   [4]   Mealling, M., "Dynamic Delegation Discovery System (DDDS)  Part
         Two: The Algorithm", RFC 3402, October 2002.

   [5]   Mealling, M., "Dynamic Delegation Discovery System (DDDS)  Part
         Four: The Uniform Resource Identifiers (URI)", RFC 3404,
         October 2002.

   [6]   Mealling, M., "Dynamic Delegation Discovery System (DDDS)  Part
         Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.

   [7]   Yergeau, F., "UTF-8, a transformation format of ISO 10646",
         STD 63, RFC 3629, November 2003.

   [8]   Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
         RFC 1034, November 1987.

   [9]   Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.

   [10]  Costello, A., "Punycode: A Bootstring encoding of Unicode for
         Internationalized Domain Names in Applications (IDNA)",
         RFC 3492, March 2003.

   [11]  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.

   [12]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
         December 2004.

   [13]  ITU-T, "The International Public Telecommunication Number
         Plan", Recommendation E.164, May 1997.



Conroy & Fujiwara       Expires December 27, 2006              [Page 33]

Internet-Draft              ENUM Experiences                   June 2006


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

   [15]  Duerst, M. and M. Suignard, "Internationalized Resource
         Identifiers (IRIs)", RFC 3987, January 2005.

   [16]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
         RFC 2181, July 1997.

   [17]  Braden, R., "Requirements for Internet Hosts -- Application and
         Support", RFC 1123, October 1989.

   [18]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
         August 1999.

   [19]  Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164
         numbers with the Session Initiation Protocol (SIP)", RFC 3824,
         June 2004.

11.2.  Informative References

   [20]  American National Standards Institute, "Coded Character Set --
         7-bit American Standard Code for Information Interchange",
         ANSI X3.4, 1986.

   [21]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
         System (DNS)", RFC 3833, August 2004.

   [22]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "DNS Security Introduction and Requirements", RFC 4033,
         March 2005.

   [23]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Resource Records for the DNS Security Extensions", RFC 4034,
         March 2005.

   [24]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Protocol Modifications for the DNS Security Extensions",
         RFC 4035, March 2005.

   [25]  ETSI, "Minimum Requirements for Interoperability of European
         ENUM Implementations", ETSI TS 102 172, October 2004.








Conroy & Fujiwara       Expires December 27, 2006              [Page 34]

Internet-Draft              ENUM Experiences                   June 2006


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 Service 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.jp/en/




























Conroy & Fujiwara       Expires December 27, 2006              [Page 35]

Internet-Draft              ENUM Experiences                   June 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Conroy & Fujiwara       Expires December 27, 2006              [Page 36]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/