Diameter Maintenance and Extensions
Internet Engineering Task Force (IETF)                          M. Jones
(DIME)
Request for Comments: 6408                           Bridgewater Systems
Internet-Draft                                               J. Korhonen
Updates: 3588 (if approved)                                                J. Korhonen
Category: Standards Track                         Nokia Siemens Networks
Intended status: Standards Track
ISSN: 2070-1721                                                L. Morand
Expires: February 4, 2012
                                                             Orange Labs
                                                          August 3,
                                                          September 2011

   Diameter S-NAPTR Straightforward-Naming Authority Pointer (S-NAPTR) Usage
                   draft-ietf-dime-extended-naptr-09

Abstract

   The Diameter base protocol specifies mechanisms whereby a given realm
   may advertise Diameter nodes and the supported transport protocol.
   However, these mechanisms do not reveal the Diameter applications
   that each node supports.  A peer outside the realm would have to
   perform a Diameter capability exchange with every node until it
   discovers one that supports the required application.  This document
   updates RFC3588 RFC 3588, "Diameter Base Protocol" Protocol", and describes an
   improvement using an extended format for the Straightforward-Naming
   Authority Pointer (S-NAPTR) Application Service Tag application service tag that allows for
   discovery of the supported applications without doing Diameter
   capability exchange beforehand.

Requirements Language

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

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 4, 2012.
   http://www.rfc-editor.org/info/rfc6408.

Copyright Notice

   Copyright (c) 2011 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   3.  Extended NAPTR Service Field Format  . . . . . . . . . . . . .  3
     3.1.  IETF Standard Standards Track Diameter Applications . . . . . . . .  4  5
     3.2.  Vendor-specific  Vendor-Specific Diameter Applications  . . . . . . . . . .  5
   4.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . .  5
   5.  Extended NAPTR-based NAPTR-Based Diameter Peer Discovery . . . . . . . . .  5  6
     5.1.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8  9
     7.1.  IETF Diameter Application Service Tags . . . . . . . . . .  8  9
     7.2.  3GPP Diameter Application Service Tags . . . . . . . . . .  9
     7.3.  WiMAX Forum Diameter Application Service Tags  . . . . . .  9 10
     7.4.  Vendor-Specific Diameter Application Service Tags  . . . . 10 11
     7.5.  Diameter Application Protocol Tags . . . . . . . . . . . . 10 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11 12
   10. Editor's Notes References . . . . . . . . . . . . . . . . . . . . . . . . 11
   11. Normative References . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . .
     10.2. Informative Reference  . . . . . . . . . . . . . . . . . . 14

1.  Introduction

   The Diameter base protocol [RFC3588] specifies three mechanisms for
   the
   Diameter peer discovery.  One of these involves the Diameter
   implementation performing a Naming Authority Pointer (NAPTR) query
   [RFC3403] for a server in a particular realm.  These NAPTR records
   provide a mapping from a domain, domain to the DNS Service Locator (SRV)
   record [RFC2782] or A/AAAA record [RFC1035][RFC3596] [RFC1035] [RFC3596] for contacting
   a server with the specific transport protocol in the NAPTR services
   field.

   The extended NAPTR usage for Diameter peer discovery defined by this
   document is based on the Straightforward-NAPTR (S-NAPTR) Dynamic
   Delegation Discovery System (DDDS) Application application defined in [RFC3958].
   This document updates the Diameter peer discovery procedure described
   in Section 11.6 5.2 of [RFC3588] and defines S-NAPTR Application Service application service
   and Application Protocol Tag application protocol tag values that permit the discovery of
   Diameter peers that support a specific Diameter application and
   transport protocol.

2.  Terminology

   The Diameter base protocol specification (Section 1.4 1.3 of [RFC3588])
   and the Straightforward-NAPTR (S-NAPTR) DDDS application (section (Section 2.1
   in
   of [RFC3958]) define the terminology used in this document.

2.1.  Requirements Language

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

3.  Extended NAPTR Service Field Format

   The NAPTR Service Field service field format defined by the S-NAPTR DDDS
   application in [RFC3958] follows this Augmented Backus-Naur Form
   (ABNF, [RFC5234]):
   (ABNF) [RFC5234]:

       service-parms = [ [app-service] *(":" app-protocol)]
       app-service   = experimental-service  / iana-registered-service
       app-protocol  = experimental-protocol / iana-registered-protocol
       experimental-service      = "x-" 1*30ALPHANUMSYM
       experimental-protocol     = "x-" 1*30ALPHANUMSYM
       iana-registered-service   = ALPHA *31ALPHANUMSYM
       iana-registered-protocol  = ALPHA *31ALPHANUMSYM
       ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
       DIGIT         =  %x30-39 ; 0-9
       SYM           =  %x2B / %x2D / %x2E  ; "+" / "-" / "."
       ALPHANUMSYM   =  ALPHA / DIGIT / SYM
       ; The app-service and app-protocol tags are limited to 32
       ; characters and must start with an alphabetic character.
       ; The service-parms are considered case-insensitive.

   This specification refines the "iana-registered-service" tag
   definition for the discovery of Diameter agents supporting a specific
   Diameter application as defined below.

       iana-registered-service =/ aaa-service
       aaa-service             = "aaa+ap" appln-id
       appln-id                = 1*10DIGIT
                                 ; Application identifier Identifier expressed as
                                 ; a decimal integer without leading
                                 ; zeros.

   The appln-id element is the Application Identifier used to identify a
   specific Diameter Application. application.  The Diameter Application Identifier
   is a 32-bit unsigned integer integer, and values are allocated by IANA as
   defined in [RFC3588].

   This specification also refines the "iana-registered-protocol" tag
   definition for the discovery of Diameter agents supporting a specific
   Diameter transport protocol as defined below.

       iana-registered-protocol =/ aaa-protocol /
       aaa-protocol             = "diameter." aaa-transport
       aaa-transport            = "tcp" / "sctp" / "tls.tcp"

   The S-NAPTR Application Protocol application protocol tags defined by this specification
   MUST NOT be parsed in any way by the querying application or
   resolver.  The delimiter (".") is present in the tag to improve
   readability and does not imply a structure or namespace of any kind.
   The choice of delimiter (".") for the Application Protocol application protocol tag
   follows the format of existing S-NAPTR Application Protocol application protocol tag
   registry entries entries, but this does not imply that that it shares semantics
   with any other specifications that create registry entries with the
   same format.

   The S-NAPTR Application Service application service and Protocol application protocol tags defined
   by this specification are unrelated to the IANA Service "Service Name and
   Transport Protocol Port Number Registry Registry" (see [I-D.ietf-tsvwg-iana-ports]). [RFC6335]).

   The maximum length of the NAPTR service field is 256 octets octets,
   including
   one octet a one-octet length field (see Section 4.1 of RFC 3403 [RFC3403] and
   Section 3.3 of [RFC1035]).

3.1.  IETF Standard Standards Track Diameter Applications

   A Diameter agent MUST be capable of using the extended S-NAPTR
   Application Service Tag
   application service tag for dynamic discovery of a Diameter agent
   supporting Standard Standards Track applications.  Therefore, every IETF
   Standard
   Standards Track Diameter application MUST be associated with a "aaa-
   service"
   "aaa-service" tag formatted as defined in this specification and
   allocated in accordance with the IANA policy (see Section 7).

   For example, a NAPTR service field value of:

      'aaa+ap6:diameter.sctp'

      Means

   means that the Diameter node in the SRV or A/AAAA record supports the
   Diameter Session Initiation Protocol (SIP) Application application ('6') and SCTP the
   Stream Control Transmission Protocol (SCTP) as the transport
   protocol.

3.2.  Vendor-specific  Vendor-Specific Diameter Applications

   S-NAPTR Application Service application service and Application Protocol Tag application protocol tag values can
   also be used to discover Diameter peers that support a vendor-
   specific Diameter application.  In this case, the vendor-specific
   Diameter application MUST be associated with a "aaa-service" tag
   formatted as defined in this specification and allocated in
   accordance with the IANA policy (see Section 7).

   For example, a NAPTR service field value of:

      'aaa+ap16777251:diameter.sctp'

      Means

   means that the Diameter node in the SRV or A/AAAA record supports the
   Diameter 3GPP Third Generation Partnership Project (3GPP) S6a Application application
   ('16777251') and SCTP as the transport protocol.

4.  Backwards Compatibility

   Domain Name System (DNS) administrators SHOULD also provision legacy
   RFC 3588 style
   NAPTR records [RFC3403] in the RFC 3588 style in order to guarantee
   backwards compatibility with legacy Diameter peers that are RFC 3588 compliant Diameter
   peers.
   compliant.  If the DNS administrator provisions both extended S-NAPTR
   records as defined in this specification and legacy RFC 3588 NAPTR
   records, then the extended S-NAPTR records MUST have higher priority
   (e.g.
   (e.g., lower order and/or preference values) than legacy NAPTR
   records.

5.  Extended NAPTR-based NAPTR-Based Diameter Peer Discovery

   The Diameter Peer Discovery principles are described in Section 5.2
   of [RFC3588].  This specification updates the NAPTR query procedure
   in the Diameter peer discovery mechanism by allowing the querying
   node to determine which applications are supported by resolved
   Diameter peers.

   The extended format extended-format NAPTR records provide a mapping from a domain to
   the SRV record or A/AAAA record for contacting a server supporting a
   specific transport protocol and Diameter application.  The resource
   record will contain an empty regular expression and a replacement
   value, which is the SRV record or the A/AAAA record for that
   particular transport protocol.

   The assumption for this mechanism to work is that the DNS
   administrator of the queried domain has first provisioned the DNS
   with extended format extended-format NAPTR entries.  The steps below replace the
   NAPTR query procedure steps in Section 5.2 of [RFC3588].

   a. The Diameter implementation performs a NAPTR query for a server in
      a particular realm.  The Diameter implementation has to know in
      advance in which realm to look for a Diameter agent in agent, and in which
      Application Identifier it is interested in. interested.  For example, the realm
      could be deduced from the Network Access Identifier (NAI) in the
      User-Name AVP attribute-value pair (AVP) or extracted from the
      Destination-Realm AVP.

   b. If the returned NAPTR service fields contain entries formatted as
      "aaa+apX:Y" where "X" indicates the Application Identifier and "Y"
      indicates the supported transport protocol(s), the target realm
      supports the extended format for NAPTR-based Diameter peer
      discovery defined in this document.

         If "X" contains the required Application Identifier and "Y"
         matches a supported transport protocol, the Diameter
         implementation resolves the "replacement" field entry to a
         target host using the lookup method appropriate for the "flags"
         field.

         If "X" does not contain the required Application Identifier or
         "Y" does not match a supported transport protocol, the Diameter
         implementation abandons the peer discovery.

   c. If the returned NAPTR service fields contain entries formatted as
      "aaa+apX" where "X" indicates the Application Identifier, the
      target realm supports the extended format for NAPTR-based Diameter
      peer discovery defined in this document.

         If "X" contains the required Application Identifier, the
         Diameter implementation resolves the "replacement" field entry
         to a target host using the lookup method appropriate for the
         "flags" field and attempts to connect using all supported
         transport protocols following the order specified in section
         Section 2.1 of [RFC3588].

         If "X" does not contain the required Application Identifier,
         the Diameter implementation abandons the peer discovery.

   d. If the returned NAPTR service fields contain entries formatted as
      "aaa:X" where "X" indicates the supported transport protocol(s),
      the target realm supports Diameter but does not support the
      extended format for NAPTR-based Diameter peer discovery defined in
      this document.

         If "X" matches a supported transport protocol, the Diameter
         implementation resolves the "replacement" field entry to a
         target host using the lookup method appropriate for the "flags"
         field.

   e. If the returned NAPTR service fields contain entries formatted as
      "aaa", the target realm supports Diameter but does not support the
      extended format for NAPTR-based Diameter peer discovery defined in
      this document.  The Diameter implementation resolves the
      "replacement" field entry to a target host using the lookup method
      appropriate for the "flags" field and attempts to connect using
      all supported transport protocols following the order specified in
      section
      Section 2.1 of [RFC3588].

   f. If the target realm does not support NAPTR-based Diameter peer
      discovery, the client proceeds with the next peer discovery
      mechanism described in Section 5.2 of [RFC3588].

5.1.  Examples

   As an example, consider a client that wishes to discover a Diameter
   server in the ex1.example.com realm that supports the Credit Control
   Application.
   application.  The client performs a NAPTR query for that domain, and
   the following NAPTR records are returned:

       ;;        order pref flags service   regexp replacement
       IN NAPTR  50    50   "s"   "aaa:diameter.sctp" ""
                    _diameter._sctp.ex1.example.com
       IN NAPTR  50    50   "s"   "aaa+ap1:diameter.sctp" ""
                    _diameter._sctp.ex1.example.com
       IN NAPTR  50    50   "s"   "aaa+ap4:diameter.sctp" ""
                    _diameter._sctp.ex1.example.com

   This indicates that the server supports NASREQ (ID=1) and Credit
   Control (ID=4) Applications applications over SCTP.  If the client supports SCTP,
   it will be used, targeted to a host determined by an SRV lookup of
   _diameter._sctp.ex1.example.com.

   That SRV lookup would return:

       ;;       Priority  Weight  Port    Target
       IN SRV   0         1       3868    server1.ex1.example.com
       IN SRV   0         2       3868    server2.ex1.example.com

   As an alternative example, a client that wishes to discover a Diameter
   server in the ex2.example.com realm that supports the NASREQ
   application over SCTP.  The client performs a NAPTR query for that
   domain, and the following NAPTR records are returned:

       ;;        order pref flags service   regexp replacement
       IN NAPTR  150   50   "a"   "aaa:diameter.stcp"   "aaa:diameter.sctp"  ""
                    server1.ex2.example.com
       IN NAPTR  150   50   "a"   "aaa:diameter.tls.tcp"  ""
                    server2.ex2.example.com
       IN NAPTR  150   50   "a"   "aaa+ap1:diameter.stcp"   "aaa+ap1:diameter.sctp"  ""
                    server1.ex2.example.com
       IN NAPTR  150   50   "a"   "aaa+ap1:diameter.tls.tcp"  ""
                    server2.ex2.example.com

   This indicates that the server supports NASREQ (ID=1) over SCTP and
   TLS/TCP
   Transport Layer Security (TLS)/TCP via hosts server1.ex2.example.com
   and server2.ex2.example.com server2.ex2.example.com, respectively.

6.  Usage Guidelines

   Diameter is a peer to peer protocol peer-to-peer protocol, whereas most of the applications
   that extend the base protocol behave like client/server applications.
   The role of the peer is not advertised in the NAPTR tags and not even
   communicated during Diameter capability negotiation (Capabilities-
   Exchange-Request
   (Capabilities-Exchange-Request and Capabilities-Exchange-Answer
   message exchange).  For this reason, NAPTR-based Diameter peer
   discovery for an application defining client/server roles should only
   be used by a client to discover servers.

7.  IANA Considerations

7.1.  IETF Diameter Application Service Tags

   IANA is requested to reserve has reserved a value of "aaa" for Diameter in the
   S-NAPTR "(S-NAPTR)
   Application Service Tag Tag" registry created by [RFC3958].  IANA
   is has
   also requested to reserve reserved the following S-NAPTR Application
   Service Tags application service tags for
   existing IETF Diameter applications in the same registry.

             +------------------+----------------------------+
             | Tag              | Diameter Application       |
             +------------------+----------------------------+
             | aaa+ap1          | NASREQ [RFC3588]           |
             | aaa+ap2          | Mobile IPv4 [RFC4004]      |
             | aaa+ap3          | Base Accounting [RFC3588]  |
             | aaa+ap4          | Credit Control [RFC4006]   |
             | aaa+ap5          | EAP [RFC4072]              |
             | aaa+ap6          | SIP [RFC4740]              |
             | aaa+ap7          | Mobile IPv6 IKE [RFC5778]  |
             | aaa+ap8          | Mobile IPv6 Auth [RFC5778] |
             | aaa+ap9          | QoS [RFC5866]              |
             | aaa+ap4294967295 | Relay [RFC3588]            |
             +------------------+----------------------------+

   Future IETF Diameter applications MUST reserve the S-NAPTR
   Application Service Tag
   application service tag corresponding to the allocated Diameter
   Application ID as defined in Section 3.

7.2.  3GPP Diameter Application Service Tags

   IANA is requested to reserve has reserved the following S-NAPTR Application
   Service Tags application service tags for
   existing 3GPP Diameter applications in the S-NAPTR "S-NAPTR Application
   Service Tag Tag" registry created by [RFC3958].

                 +----------------+----------------------+
                 | Tag            | Diameter Application |
                 +----------------+----------------------+
                 | aaa+ap16777250 | 3GPP STa [TS29.273]  |
                 | aaa+ap16777251 | 3GPP S6a [TS29.272]  |
                 | aaa+ap16777264 | 3GPP SWm [TS29.273]  |
                 | aaa+ap16777267 | 3GPP S9 [TS29.215]   |
                 +----------------+----------------------+

   Future 3GPP Diameter applications can reserve entries in the S-NAPTR "S-NAPTR
   Application Service Tag Tag" registry created by [RFC3958] which that
   correspond to the allocated Diameter Application IDs as defined in
   Section 3.

7.3.  WiMAX Forum Diameter Application Service Tags

   IANA is requested to reserve has reserved the following S-NAPTR Application
   Service Tags following S-NAPTR application service tags for
   existing WiMAX Worldwide Interoperability for Microwave Access (WiMAX)
   Forum Diameter applications in the
   S-NAPTR "S-NAPTR Application Service Tag Tag"
   registry created by [RFC3958].

   +----------------+--------------------------------------------------+
   | Tag            | Diameter Application                             |
   +----------------+--------------------------------------------------+
   | aaa+ap16777281 | WiMAX Network Access Authentication and          |
   |                | Authorization Diameter Application (WNAAADA)     |
   |                | [WiMAX] [WiMAX-BASE]                                     |
   | aaa+ap16777282 | WiMAX Network Accounting Diameter Application    |
   |                | (WNADA) [WiMAX] [WiMAX-BASE]                             |
   | aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) [WiMAX]          |
   |                | [WiMAX-BASE]                                     |
   | aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) [WiMAX]          |
   |                | [WiMAX-BASE]                                     |
   | aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) [WiMAX]           |
   |                | [WiMAX-BASE]                                     |
   | aaa+ap16777286 | WiMAX Location Authentication Authorization      |
   |                | Diameter Application (WLAADA) [WiMAX] [WiMAX-LBS]        |
   | aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies    |
   |                | Diameter Application (WiMAX PCC-R3-P) [WiMAX]            |
   |                | [WiMAX-PCC]                                      |
   | aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline     |
   |                | Charging Diameter Application (WiMAX PCC-R3-OFC) |
   |                | [WiMAX] [WiMAX-PCC]                                      |
   | aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline     |
   |                | Charging Prime Diameter Application (WiMAX       |
   |                | PCC-R3-OFC-PRIME) [WiMAX] [WiMAX-PCC]                    |
   | aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online      |
   |                | Charging Diameter Application (WiMAX PCC-R3-OC)  |
   |                | [WiMAX] [WiMAX-PCC]                                      |
   +----------------+--------------------------------------------------+

   Future WiMAX Forum Diameter applications can reserve entries in the
   S-NAPTR
   "S-NAPTR Application Service Tag Tag" registry created by [RFC3958] which that
   correspond to the allocated Diameter Application IDs as defined in
   Section 3.

7.4.  Vendor-Specific Diameter Application Service Tags

   Vendor-Specific Diameter Application IDs are allocated by IANA
   according to the "First Come First Served" policy and do not require
   an IETF specification.  However, the S-NAPTR Application Service Tag application service tag
   registry created by [RFC3958] defines a registration policy of
   "Specification Required" with a further stipulation that the
   "specification" is an RFC (of any category).  If a Vendor-Specific vendor-specific
   Diameter Application application requires the functionality defined in this
   document, an RFC of any category MUST be published which that reserves the
   S-NAPTR Application Service Tag corresponding to the Vendor-Specific
   Diameter Application ID as defined in Section 3.

7.5.  Diameter Application Protocol Tags

   IANA is requested to reserve has reserved the following S-NAPTR Application Protocol Tags for
   the Diameter transport protocols in the S-NAPTR "S-NAPTR Application Protocol Tag
   Tag" registry created by [RFC3958].

                      +------------------+----------+
                      | Tag              | Protocol |
                      +------------------+----------+
                      | diameter.tcp     | TCP      |
                      | diameter.sctp    | SCTP     |
                      | diameter.tls.tcp | TLS/TCP  |
                      +------------------+----------+

   Future Diameter versions which that introduce new transport protocols MUST
   reserve an appropriate S-NAPTR Application Protocol Tag in the
   S-NAPTR
   "S-NAPTR Application Protocol Tag Tag" registry created by [RFC3958].

8.  Security Considerations

   This document specifies an enhancement to RFC 3588 Diameter base
   protocol defined the NAPTR service field
   format defined in RFC 3588 and also modifications to the NAPTR
   processing logic defined. defined in RFC 3588.  The enhancements enhancement and
   modifications are based on the S-NAPTR, which is actually a
   simplification of the NAPTR, and therefore the same security
   considerations described in RFC 3588 [RFC3588] are applicable to this
   document.  No further extensions are required beyond the security
   mechanisms offered by RFC 3588.  However, a malicious host doing
   S-NAPTR queries learns applications supported by Diameter agents in a
   certain realm faster, which might help the malicious host to scan
   potential targets for an attack more efficiently when some
   applications have known vulnerabilities.

9.  Acknowledgments

   We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Sebastien
   Decugis, Dan Romascanu, Adrian Farrel, David Harrington, Pete
   Resnick, Robert Sparks, Stephen Farrell, Wesley Eddy, Ralph Droms Droms,
   and Joe Touch and for their comprehensive review comments.

10.  Editor's Notes

   This section to be removed prior to publication.

   This draft updates sections of RFC3588 that are also being updated by
   RFC3588bis.  At the time this draft was started, it was uncertain
   whether RFC3588bis would be published first.  The authors of this
   draft decided to proceed optimistically assuming this draft would be
   published first with the understanding that minor updates are
   required if this is not the case.

   The application-neutral aspects of Diameter S-NAPTR usage (e.g "aaa:
   diameter.sctp") were also contributed to RFC3588bis to ensure that it
   would be functionally complete if it got published first and this
   draft would come along later to add the application-specific S-NAPTR
   entries (e.g."aaa+ap5:diameter.sctp").

   Depending on the publication order, the S-NAPTR Application Service
   Tag registry value of "aaa" and the S-NAPTR Application Protocol Tags
   values ("diameter.tcp"/"diameter.sctp"/"diameter.tls.tcp") will need
   to be removed either from this draft or RFC3588bis.

11.  References

10.1.  Normative References

   [I-D.ietf-tsvwg-iana-ports]
              Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry",
              draft-ietf-tsvwg-iana-ports-10 (work in progress),
              February 2011.

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

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

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

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", RFC 3596,
              October 2003.

   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
              Service Location Using SRV RRs and the Dynamic Delegation
              Discovery Service (DDDS)", RFC 3958, January 2005.

   [RFC4004]  Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed.,
              and P. McCann, "Diameter Mobile IPv4 Application",
              RFC 4004, August 2005.

   [RFC4006]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
              Loughney, "Diameter Credit-Control Application", RFC 4006,
              August 2005.

   [RFC4072]  Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
              Extensible Authentication Protocol (EAP) Application",
              RFC 4072, August 2005.

   [RFC4740]  Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez, M.,
              Canales-Valenzuela, C., and K. Tammi, "Diameter Session
              Initiation Protocol (SIP) Application", RFC 4740,
              November 2006.

   [RFC5234]  Crocker, D. D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5778]  Korhonen, J., Ed., Tschofenig, H., Bournelle, J.,
              Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6:
              Support for Home Agent to Diameter Server Interaction",
              RFC 5778, February 2010.

   [RFC5866]  Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T., Doria,
              A., and G. Zorn, Ed., "Diameter Quality-of-Service
              Application", RFC 5866, May 2010.

   [TS29.215]
              3rd Generation Partnership Project, "3GPP TS 29.215;
              Technical Specification Group Core Network and Terminals;
              Policy and Charging Control (PCC) over S9 reference point;
              Stage 3 (Release 8)",
              <http://www.3gpp.org/ftp/Specs/html-info/29215.htm>.

   [TS29.272]
              3rd Generation Partnership Project, "3GPP TS 29.272;
              Technical Specification Group Core Network and Terminals;
              Evolved Packet System; System (EPS); Mobility Management Entity
              (MME) and Serving GPRS Support Node (SGSN) Related
              Interfaces Based on Diameter Protocol (Release 8)",
              <http://www.3gpp.org/ftp/Specs/html-info/29272.htm>.

   [TS29.273]
              3rd Generation Partnership Project, "3GPP TS 29.273;
              Technical Specification Group Core Network and Terminals;
              Evolved Packet System; System (EPS); 3GPP EPS AAA interfaces
              (Release 8)",
              <http://www.3gpp.org/ftp/Specs/html-info/29273.htm>.

   [WiMAX]

   [WiMAX-BASE]
              WiMAX Forum, "WMF-T33-001-R015v02 - WiMAX Forum(R) Network
              Architecture - Detailed Protocols and Procedures, Base
              Specification - Release 1.5", <http://www.wimaxforum.org/
              resources/documents/technical/T33>.

   [WiMAX-LBS]
              WiMAX Forum, "WMF-T33-110-R015v01 - WiMAX Forum(R) Network
              Architecture - Protocols and Procedures for Location Based
              Services - Release 1.5", <http://www.wimaxforum.org/
              resources/documents/technical/T33>.

   [WiMAX-PCC]
              WiMAX Forum, "WiMAX "WMF-T33-109-R015v02 - WiMAX Forum(R) Network
              Architecture - Detailed Protocols and Procedures, Policy
              and Charging Control - Release 1.5", <http://
              www.wimaxforum.org/resources/documents/technical/T33>.

10.2.  Informative Reference

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, August 2011.

Authors' Addresses

   Mark Jones
   Bridgewater Systems

   Email:

   EMail: mark@azu.ca

   Jouni Korhonen
   Nokia Siemens Networks

   Email:

   EMail: jouni.nospam@gmail.com

   Lionel Morand
   Orange Labs

   Email: lionel.morand@orange-ftgroup.com

   EMail: lionel.morand@orange.com