Individual Submission                                           M. Jones
Internet-Draft                                       Bridgewater Systems
Updates: 3588 (if approved)                                  J. Korhonen
Intended status: Standards Track                  Nokia Siemens Networks
Expires: February 24, 2010                               August 23, 2009

                        Diameter Extended NAPTR

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on February 24, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Jones & Korhonen        Expires February 24, 2010               [Page 1]

Internet-Draft             dime-extended-naptr               August 2009

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   This document describes an extended format for the NAPTR service
   fields used in dynamic Diameter agent discovery.  The extended format
   allows NAPTR queries contain Diameter Application-Id information.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Jones & Korhonen        Expires February 24, 2010               [Page 2]

Internet-Draft             dime-extended-naptr               August 2009

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Extended NAPTR Service Field  . . . . . . . . . . . . . . . . . 4
   4.  Extended NAPTR-based Diameter Peer Discovery  . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Jones & Korhonen        Expires February 24, 2010               [Page 3]

Internet-Draft             dime-extended-naptr               August 2009

1.  Introduction

   The Diameter base protocol [RFC3588] specifies three mechanisms for
   the Diameter peer discovery.  One of these involves the Diameter
   implementation performing a NAPTR query [RFC3403] for a server in a
   particular realm.  These NAPTR records provide a mapping from a
   domain, to the SRV record [RFC2782] for contacting a server with the
   specific transport protocol in the NAPTR services field.

   Section 11.6 of RFC 3588 defines the following NAPTR service fields:

         Services Field               Protocol
         AAA+D2T                       TCP
         AAA+D2S                       SCTP

   However, foreseen network topologies require border AAA nodes that
   will be specialized by Diameter application and the NAPTR service
   field does not allow a Diameter implementation to determine the
   application supported by the AAA node.  Without this information, a
   Diameter implementation must connect and perform a capability
   negotiation with each candidate AAA node.  This document addresses
   this problem by specifying an extended NAPTR service field format
   that permits discovery of Diameter peers that support a specific
   Diameter application.

2.  Terminology

   The Diameter base protocol specification (Section 1.4 of RFC 3588)
   defines most of the terminology used in this document.

3.  Extended NAPTR Service Field

   The Extended NAPTR service field ABNF specification for the discovery
   of Diameter agents supporting a specific Diameter application is show

Jones & Korhonen        Expires February 24, 2010               [Page 4]

Internet-Draft             dime-extended-naptr               August 2009

         naptr-svc-field     = "AAA+D2" < protocol> [ *appln-list ]

         protocol            = "T" / "S"
                               ; "T" for TCP and "S" for SCTP.

         appln-list          = "+AP:" appln-id [ *( "," appln-id ) ]
                               ; Comma separated list of application
                               ; identifiers prefixed by "+AP:".

         appln-id            = *DIGIT
                               ; Application identifier expressed as a
                               ; decimal integer.

   For example, a NAPTR service field value of:


      Means that the Diameter node in the SRV record supports the
      Diameter Session Initiation Protocol (SIP) Application ('6') and
      SCTP as the transport protocol.


      Means that the Diameter node in the SRV record supports the
      Diameter Session Initiation Protocol (SIP) Application ('6'),
      NASREQ Application ('1'), EAP Application ('5') and SCTP as the
      transport protocol.  The Diameter node also provides Relay
      functionality ('4294967295').

   The maximum length of the NAPTR service field is 256 octets including
   one octet length field (see Section 4.1 of RFC 3403 and Section 3.3
   of [RFC1035]).  The DNS administrator of some domain SHOULD also
   provision base RFC 3588 style NAPTR records in order to guarantee
   backwards compatibility with legacy RFC 3588 compliant Diameter

4.  Extended NAPTR-based Diameter Peer Discovery

   The basic Diameter Peer Discover principles are described in Section
   5.2 of RFC 3588.  This specification extends the step 3.  Diameter
   peer discovery mechanism by allowing the querying node examine which
   applications are supported by resolved Diameter peers.  The
   assumption for this mechanism to work is that the DNS administrator
   of the queried domain has provisioned the DNS with extended NAPTRs in
   the first place.  The text below is slightly modified from RFC 3588.

Jones & Korhonen        Expires February 24, 2010               [Page 5]

Internet-Draft             dime-extended-naptr               August 2009

   1. ...

   2. ...

   3. The Diameter implementation performs a NAPTR query for a server in
      a particular realm.  The Diameter implementation has to know in
      advance which realm to look for a Diameter agent in and which
      Application Identifier it is interested in.  The realm could be
      deduced, for example, from the 'realm' in a NAI that a Diameter
      implementation needed to perform a Diameter operation on.

      3.1  The services relevant for the task of transport protocol
         selection are those with NAPTR service fields with values "AAA+
         D2x+AP:y", where 'x' is a letter that corresponds to a
         transport protocol supported by the domain and 'y' is one or
         more Application Identifiers.

      3.2  A client MUST discard any service fields that identify a
         resolution service whose value is not "D2X", for values of X
         that indicate transport protocols supported by the client.  The
         client SHOULD also discard any service fields that do not
         identify support for the application the client is looking for
         i.e. the desired Application Identifier is not listed in

5.  IANA Considerations

   Editor's Note: Verify impacts to IANA registries.

6.  Security Considerations

   This document specifies an enhancement to the NAPTR service field
   format defined in the Diameter base protocol and the same security
   considerations described in RFC 3588 are applicable to this document.
   No further extensions are required beyond the security mechanisms
   offered by RFC 3588.

7.  Normative References

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

Jones & Korhonen        Expires February 24, 2010               [Page 6]

Internet-Draft             dime-extended-naptr               August 2009

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

Authors' Addresses

   Mark Jones
   Bridgewater Systems


   Jouni Korhonen
   Nokia Siemens Networks


Jones & Korhonen        Expires February 24, 2010               [Page 7]