Difference between revisions of "RFC6408"

Latest revision as of 11:18, 1 October 2020

Internet Engineering Task Force (IETF) M. Jones Request for Comments: 6408 Bridgewater Systems Updates: 3588 J. Korhonen Category: Standards Track Nokia Siemens Networks ISSN: 2070-1721 L. Morand

                                                         Orange Labs
                                                       November 2011

Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage

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 RFC 3588, "Diameter Base Protocol", and describes an improvement using an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) application service tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6408.

Copyright Notice

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.

1 Introduction
2 Terminology
- 2.1 Requirements Language
3 Extended NAPTR Service Field Format
- 3.1 IETF Standards Track Diameter Applications
- 3.2 Vendor-Specific Diameter Applications
4 Backwards Compatibility
5 Extended NAPTR-Based Diameter Peer Discovery
- 5.1 Examples
6 Usage Guidelines
7 IANA Considerations
8 Security Considerations
9 Acknowledgments

Introduction

The Diameter base protocol RFC3588 specifies three mechanisms for 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 to the DNS Service Locator (SRV) record RFC2782 or A/AAAA record 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 defined in RFC3958. This document updates the Diameter peer discovery procedure described in Section 5.2 of RFC3588 and defines S-NAPTR application service and application protocol tag values that permit the discovery of Diameter peers that support a specific Diameter application and transport protocol.

Terminology

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

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.

Extended NAPTR Service Field Format

The NAPTR service field format defined by the S-NAPTR DDDS application in RFC3958 follows this Augmented Backus-Naur Form (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 expressed as
                             ; a decimal integer without leading
                             ; zeros.

The appln-id element is the Application Identifier used to identify a specific Diameter application. The Diameter Application Identifier is a 32-bit unsigned 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 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 tag follows the format of existing S-NAPTR application protocol tag registry entries, but this does not imply that it shares semantics with any other specifications that create registry entries with the same format.

The S-NAPTR application service and application protocol tags defined by this specification are unrelated to the IANA "Service Name and Transport Protocol Port Number Registry" (see RFC6335).

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

IETF Standards Track Diameter Applications

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

For example, a NAPTR service field value of:

  'aaa+ap6:diameter.sctp'

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

Vendor-Specific Diameter Applications

S-NAPTR application service and 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 IANA policy (see Section 7).

For example, a NAPTR service field value of:

  'aaa+ap16777251:diameter.sctp'

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

Backwards Compatibility

Domain Name System (DNS) administrators SHOULD also provision legacy NAPTR records RFC3403 in the RFC 3588 style in order to guarantee backwards compatibility with legacy Diameter peers that are RFC 3588 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., lower order and/or preference values) than legacy NAPTR records.

Extended 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 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 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, and in which
  Application Identifier it is interested.  For example, the realm
  could be deduced from the Network Access Identifier (NAI) in the
  User-Name 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 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 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.

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. 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 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 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.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.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 Transport Layer Security (TLS)/TCP via hosts server1.ex2.example.com and server2.ex2.example.com, respectively.

Usage Guidelines

Diameter is a 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 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.

IANA Considerations

IETF Diameter Application Service Tags

IANA has reserved a value of "aaa" for Diameter in the "(S-NAPTR) Application Service Tag" registry created by RFC3958. IANA has also reserved the following S-NAPTR 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 corresponding to the allocated Diameter Application ID as defined in Section 3.

3GPP Diameter Application Service Tags

IANA has reserved the following S-NAPTR application service tags for existing 3GPP Diameter applications in the "S-NAPTR Application Service 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 Application Service Tag" registry created by RFC3958 that correspond to the allocated Diameter Application IDs as defined in Section 3.

WiMAX Forum Diameter Application Service Tags

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

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

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 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 Diameter application requires the functionality defined in this document, an RFC of any category MUST be published that reserves the S-NAPTR Application Service Tag corresponding to the Vendor-Specific Diameter Application ID as defined in Section 3.

Diameter Application Protocol Tags

IANA has reserved the following S-NAPTR Application Protocol Tags for the Diameter transport protocols in the "S-NAPTR Application Protocol Tag" registry created by RFC3958.

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

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

Security Considerations

This document specifies an enhancement to the NAPTR service field format defined in RFC 3588 and also modifications to the NAPTR processing logic defined in RFC 3588. The 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.

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, and Joe Touch for their comprehensive review comments.

10. References

10.1. Normative References

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., 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 (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 (EPS); 3GPP EPS AAA
            interfaces (Release 8)",
            <http://www.3gpp.org/ftp/Specs/html-info/29273.htm>.

[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, "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 References

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

Jouni Korhonen Nokia Siemens Networks

EMail: [email protected]

Lionel Morand Orange Labs

EMail: [email protected]

Anonymous

Search

Difference between revisions of "RFC6408"

Namespaces

More

Page actions

Latest revision as of 11:18, 1 October 2020

Contents

Introduction

Terminology

Requirements Language

Extended NAPTR Service Field Format

IETF Standards Track Diameter Applications

Vendor-Specific Diameter Applications

Backwards Compatibility

Extended NAPTR-Based Diameter Peer Discovery

Examples

Usage Guidelines

IANA Considerations

IETF Diameter Application Service Tags

3GPP Diameter Application Service Tags

WiMAX Forum Diameter Application Service Tags

Vendor-Specific Diameter Application Service Tags

Diameter Application Protocol Tags

Security Considerations

Acknowledgments

Navigation

Navigation

Wiki tools

Wiki tools

@@ Line 1: / Line 1: @@
+Internet Engineering Task Force (IETF)                          M. Jones
+Request for Comments: 6408                          Bridgewater Systems
+Updates: 3588                                                J. Korhonen
+Category: Standards Track                        Nokia Siemens Networks
+ISSN: 2070-1721                                                L. Morand
+                                                          Orange Labs
+                                                        November 2011
+Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage
+'''Abstract'''
-Internet Engineering Task Force (IETF)                          M. JonesRequest for Comments: 6408                          Bridgewater SystemsUpdates: 3588                                                J. KorhonenCategory: Standards Track                        Nokia Siemens NetworksISSN: 2070-1721                                                L. Morand                                                          Orange Labs                                                        November 2011
-Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage
-Abstract
 The Diameter base protocol specifies mechanisms whereby a given realm
@@ Line 22: / Line 23: @@
 capability exchange beforehand.
-Status of This Memo
+'''Status of This Memo'''
 This is an Internet Standards Track document.
@@ Line 36: / Line 37: @@
 http://www.rfc-editor.org/info/rfc6408.
+'''Copyright Notice'''
-Copyright Notice
 Copyright (c) 2011 IETF Trust and the persons identified as the
@@ Line 67: / Line 54: @@
 == Introduction ==
-The Diameter base protocol [RFC3588] specifies three mechanisms for
+The Diameter base protocol [[RFC3588]] specifies three mechanisms for
 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
+[[RFC3403]] for a server in a particular realm.  These NAPTR records
 provide a mapping from a domain to the DNS Service Locator (SRV)
-record [RFC2782] or A/AAAA record [RFC1035] [RFC3596] for contacting
+record [[RFC2782]] or A/AAAA record [[RFC1035]] [[RFC3596]] for contacting
 a server with the specific transport protocol in the NAPTR services
 field.
@@ Line 86: / Line 66: @@
 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 defined in [RFC3958].
+Delegation Discovery System (DDDS) application defined in [[RFC3958]].
 This document updates the Diameter peer discovery procedure described
-in Section 5.2 of [RFC3588] and defines S-NAPTR application service
+in Section 5.2 of [[RFC3588]] and defines S-NAPTR application service
 and application protocol tag values that permit the discovery of
 Diameter peers that support a specific Diameter application and
@@ Line 95: / Line 75: @@
 == Terminology ==
-The Diameter base protocol specification (Section 1.3 of [RFC3588])
+The Diameter base protocol specification (Section 1.3 of [[RFC3588]])
 and the Straightforward-NAPTR (S-NAPTR) DDDS application (Section 2.1
-of [RFC3958]) define the terminology used in this document.
+of [[RFC3958]]) define the terminology used in this document.
 === Requirements Language ===
@@ Line 103: / Line 83: @@
 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].
+document are to be interpreted as described in [[RFC2119]].
 == Extended NAPTR Service Field Format ==
 The NAPTR service field format defined by the S-NAPTR DDDS
-application in [RFC3958] follows this Augmented Backus-Naur Form
+application in [[RFC3958]] follows this Augmented Backus-Naur Form
-(ABNF) [RFC5234]:
+(ABNF) [[RFC5234]]:
      service-parms = [ [app-service] *(":" app-protocol)]
@@ Line 125: / Line 105: @@
      ; characters and must start with an alphabetic character.
      ; The service-parms are considered case-insensitive.
 This specification refines the "iana-registered-service" tag
@@ Line 146: / Line 120: @@
 specific Diameter application.  The Diameter Application Identifier
 is a 32-bit unsigned integer, and values are allocated by IANA as
-defined in [RFC3588].
+defined in [[RFC3588]].
 This specification also refines the "iana-registered-protocol" tag
@@ Line 168: / Line 142: @@
 The S-NAPTR application service and application protocol tags defined
 by this specification are unrelated to the IANA "Service Name and
-Transport Protocol Port Number Registry" (see [RFC6335]).
+Transport Protocol Port Number Registry" (see [[RFC6335]]).
 The maximum length of the NAPTR service field is 256 octets,
-including a one-octet length field (see Section 4.1 of [RFC3403] and
+including a one-octet length field (see Section 4.1 of [[RFC3403]] and
-Section 3.3 of [RFC1035]).
+Section 3.3 of [[RFC1035]]).
 === IETF Standards Track Diameter Applications ===
@@ Line 223: / Line 186: @@
 Domain Name System (DNS) administrators SHOULD also provision legacy
-NAPTR records [RFC3403] in the [[RFC3588|RFC 3588]] style in order to guarantee
+NAPTR records [[RFC3403]] in the [[RFC3588|RFC 3588]] style in order to guarantee
 backwards compatibility with legacy Diameter peers that are [[RFC3588|RFC 3588]]
 compliant.  If the DNS administrator provisions both extended S-NAPTR
@@ Line 230: / Line 193: @@
 (e.g., lower order and/or preference values) than legacy NAPTR
 records.
 == Extended 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
+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
@@ Line 256: / Line 212: @@
 administrator of the queried domain has first provisioned the DNS
 with extended-format NAPTR entries.  The steps below replace the
-NAPTR query procedure steps in Section 5.2 of [RFC3588].
+NAPTR query procedure steps in Section 5.2 of [[RFC3588]].
 a. The Diameter implementation performs a NAPTR query for a server in
@@ Line 281: / Line 237: @@
        "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
@@ Line 301: / Line 248: @@
        "flags" field and attempts to connect using all supported
        transport protocols following the order specified in
-       Section 2.1 of [RFC3588].
+       Section 2.1 of [[RFC3588]].
        If "X" does not contain the required Application Identifier,
@@ Line 324: / Line 271: @@
    appropriate for the "flags" field and attempts to connect using
    all supported transport protocols following the order specified in
-   Section 2.1 of [RFC3588].
+   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].
+   mechanism described in Section 5.2 of [[RFC3588]].
 === Examples ===
@@ Line 336: / Line 283: @@
 application.  The client performs a NAPTR query for that domain, and
 the following NAPTR records are returned:
      ;;        order pref flags service  regexp replacement
@@ Line 392: / Line 332: @@
 discovery for an application defining client/server roles should only
 be used by a client to discover servers.
 == IANA Considerations ==
@@ Line 402: / Line 338: @@
 IANA has reserved a value of "aaa" for Diameter in the "(S-NAPTR)
-Application Service Tag" registry created by [RFC3958].  IANA has
+Application Service Tag" registry created by [[RFC3958]].  IANA has
 also reserved the following S-NAPTR application service tags for
 existing IETF Diameter applications in the same registry.
@@ Line 409: / Line 345: @@
            | Tag              | Diameter Application      |
            +------------------+----------------------------+
-           | aaa+ap1          | NASREQ [RFC3588]          |
+           | aaa+ap1          | NASREQ [[RFC3588]]          |
-           | aaa+ap2          | Mobile IPv4 [RFC4004]      |
+           | aaa+ap2          | Mobile IPv4 [[RFC4004]]      |
-           | aaa+ap3          | Base Accounting [RFC3588]  |
+           | aaa+ap3          | Base Accounting [[RFC3588]]  |
-           | aaa+ap4          | Credit Control [RFC4006]  |
+           | aaa+ap4          | Credit Control [[RFC4006]]  |
-           | aaa+ap5          | EAP [RFC4072]              |
+           | aaa+ap5          | EAP [[RFC4072]]              |
-           | aaa+ap6          | SIP [RFC4740]              |
+           | aaa+ap6          | SIP [[RFC4740]]              |
-           | aaa+ap7          | Mobile IPv6 IKE [RFC5778]  |
+           | aaa+ap7          | Mobile IPv6 IKE [[RFC5778]]  |
-           | aaa+ap8          | Mobile IPv6 Auth [RFC5778] |
+           | aaa+ap8          | Mobile IPv6 Auth [[RFC5778]] |
-           | aaa+ap9          | QoS [RFC5866]              |
+           | aaa+ap9          | QoS [[RFC5866]]              |
-           | aaa+ap4294967295 | Relay [RFC3588]            |
+           | aaa+ap4294967295 | Relay [[RFC3588]]            |
            +------------------+----------------------------+
@@ Line 429: / Line 365: @@
 IANA has reserved the following S-NAPTR application service tags for
 existing 3GPP Diameter applications in the "S-NAPTR Application
-Service Tag" registry created by [RFC3958].
+Service Tag" registry created by [[RFC3958]].
                +----------------+----------------------+
@@ Line 441: / Line 377: @@
 Future 3GPP Diameter applications can reserve entries in the "S-NAPTR
-Application Service Tag" registry created by [RFC3958] that
+Application Service Tag" registry created by [[RFC3958]] that
 correspond to the allocated Diameter Application IDs as defined in
 Section 3.
 === WiMAX Forum Diameter Application Service Tags ===
@@ Line 455: / Line 386: @@
 existing Worldwide Interoperability for Microwave Access (WiMAX)
 Forum Diameter applications in the "S-NAPTR Application Service Tag"
-registry created by [RFC3958].
+registry created by [[RFC3958]].
 +----------------+--------------------------------------------------+
@@ Line 488: / Line 419: @@
 Future WiMAX Forum Diameter applications can reserve entries in the
-"S-NAPTR Application Service Tag" registry created by [RFC3958] that
+"S-NAPTR Application Service Tag" registry created by [[RFC3958]] that
 correspond to the allocated Diameter Application IDs as defined in
 Section 3.
@@ Line 497: / Line 428: @@
 according to the "First Come First Served" policy and do not require
 an IETF specification.  However, the S-NAPTR application service tag
-registry created by [RFC3958] defines a registration policy of
+registry created by [[RFC3958]] defines a registration policy of
 "Specification Required" with a further stipulation that the
@@ Line 514: / Line 441: @@
 IANA has reserved the following S-NAPTR Application Protocol Tags for
 the Diameter transport protocols in the "S-NAPTR Application Protocol
-Tag" registry created by [RFC3958].
+Tag" registry created by [[RFC3958]].
                    +------------------+----------+
@@ Line 526: / Line 453: @@
 Future Diameter versions that introduce new transport protocols MUST
 reserve an appropriate S-NAPTR Application Protocol Tag in the
-"S-NAPTR Application Protocol Tag" registry created by [RFC3958].
+"S-NAPTR Application Protocol Tag" registry created by [[RFC3958]].
 == Security Considerations ==
@@ Line 535: / Line 462: @@
 modifications are based on the S-NAPTR, which is actually a
 simplification of the NAPTR, and therefore the same security
-considerations described in [[RFC3588|RFC 3588]] [RFC3588] are applicable to this
+considerations described in [[RFC3588|RFC 3588]] [[RFC3588]] are applicable to this
 document.  No further extensions are required beyond the security
 mechanisms offered by [[RFC3588|RFC 3588]].  However, a malicious host doing
@@ Line 550: / Line 477: @@
 and Joe Touch for their comprehensive review comments.
+.  References
+.1.  Normative References
+[[RFC1035]]    Mockapetris, P., "Domain names - implementation and
+            specification", [[STD13|STD 13]], [[RFC1035|RFC 1035]], November 1987.
+[[RFC2119]]    Bradner, S., "Key words for use in RFCs to Indicate
+            Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997.
+[[RFC2782]]    Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+            specifying the location of services (DNS SRV)",
+            [[RFC2782|RFC 2782]], February 2000.
+[[RFC3403]]    Mealling, M., "Dynamic Delegation Discovery System
+            (DDDS) Part Three: The Domain Name System (DNS)
+            Database", [[RFC3403|RFC 3403]], October 2002.
-== References ==
+[[RFC3588]]    Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
+            Arkko, "Diameter Base Protocol", [[RFC3588|RFC 3588]],
+            September 2003.
-=== Normative References ===
+[[RFC3596]]    Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+            "DNS Extensions to Support IP Version 6", [[RFC3596|RFC 3596]],
+            October 2003.
-[RFC1035]    Mockapetris, P., "Domain names - implementation and            specification", STD 13, [[RFC1035|RFC 1035]], November 1987.
+[[RFC3958]]    Daigle, L. and A. Newton, "Domain-Based Application
-[RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate            Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997.
+            Service Location Using SRV RRs and the Dynamic
-[RFC2782]    Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for            specifying the location of services (DNS SRV)",            [[RFC2782|RFC 2782]], February 2000.
+            Delegation Discovery Service (DDDS)", [[RFC3958|RFC 3958]],
-[RFC3403]    Mealling, M., "Dynamic Delegation Discovery System            (DDDS) Part Three: The Domain Name System (DNS)            Database", [[RFC3403|RFC 3403]], October 2002.
+            January 2005.
-[RFC3588]    Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.            Arkko, "Diameter Base Protocol", [[RFC3588|RFC 3588]],            September 2003.
-[RFC3596]    Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,            "DNS Extensions to Support IP Version 6", [[RFC3596|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)", [[RFC3958|RFC 3958]],             January 2005.
-[RFC4004]    Calhoun, P., Johansson, T., Perkins, C., Hiller, T.,            Ed., and P. McCann, "Diameter Mobile IPv4 Application",            [[RFC4004|RFC 4004]], August 2005.
-[RFC4006]    Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and            J.  Loughney, "Diameter Credit-Control Application",            [[RFC4006|RFC 4006]], August 2005.
-[RFC4072]    Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter            Extensible Authentication Protocol (EAP) Application",            [[RFC4072|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",            [[RFC4740|RFC 4740]], November 2006.
+[[RFC4004]]    Calhoun, P., Johansson, T., Perkins, C., Hiller, T.,
+            Ed., and P. McCann, "Diameter Mobile IPv4 Application",
+            [[RFC4004|RFC 4004]], August 2005.
+[[RFC4006]]    Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and
+            J.  Loughney, "Diameter Credit-Control Application",
+            [[RFC4006|RFC 4006]], August 2005.
+[[RFC4072]]    Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
+            Extensible Authentication Protocol (EAP) Application",
+            [[RFC4072|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",
+            [[RFC4740|RFC 4740]], November 2006.
-[RFC5234]    Crocker, D., Ed., and P. Overell, "Augmented BNF for             Syntax Specifications: ABNF", STD 68, [[RFC5234|RFC 5234]],             January 2008.
+[[RFC5234]]    Crocker, D., Ed., and P. Overell, "Augmented BNF for
-[RFC5778]    Korhonen, J., Ed., Tschofenig, H., Bournelle, J.,            Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6:            Support for Home Agent to Diameter Server Interaction",            [[RFC5778|RFC 5778]], February 2010.
+            Syntax Specifications: ABNF", [[STD68|STD 68]], [[RFC5234|RFC 5234]],
-[RFC5866]    Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T.,            Doria, A., and G. Zorn, Ed., "Diameter            Quality-of-Service Application", [[RFC5866|RFC 5866]], May 2010.
+            January 2008.
-[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 (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 (EPS); 3GPP EPS AAA            interfaces (Release 8)",            <http://www.3gpp.org/ftp/Specs/html-info/29273.htm>.
-[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>.
+[[RFC5778]]    Korhonen, J., Ed., Tschofenig, H., Bournelle, J.,
+            Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6:
+            Support for Home Agent to Diameter Server Interaction",
+            [[RFC5778|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", [[RFC5866|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 (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 (EPS); 3GPP EPS AAA
+            interfaces (Release 8)",
+            <http://www.3gpp.org/ftp/Specs/html-info/29273.htm>.
+[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, "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>.
+[WiMAX-PCC]  WiMAX Forum, "WMF-T33-109-R015v02 - WiMAX Forum(R)
-=== Informative References ===
+            Network Architecture - Detailed Protocols and
+            Procedures, Policy and Charging Control - Release 1.5",
+            <http://www.wimaxforum.org/resources/
+            documents/technical/T33>.
+.2.  Informative References
+[[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", [[BCP165|BCP 165]],
+            [[RFC6335|RFC 6335]], August 2011.
-[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", [[BCP165|BCP 165]],            [[RFC6335|RFC 6335]], August 2011.
 Authors' Addresses
@@ Line 602: / Line 590: @@
 EMail: [email protected]
 Jouni Korhonen
@@ Line 608: / Line 595: @@
 EMail: [email protected]
 Lionel Morand
@@ Line 614: / Line 600: @@
 EMail: [email protected]
 [[Category:Standards Track]]

Anonymous

Search

Difference between revisions of "RFC6408"

Latest revision as of 11:18, 1 October 2020

Contents

Introduction

Terminology

Requirements Language

Extended NAPTR Service Field Format

IETF Standards Track Diameter Applications

Vendor-Specific Diameter Applications

Backwards Compatibility

Extended NAPTR-Based Diameter Peer Discovery

Examples

Usage Guidelines

IANA Considerations

IETF Diameter Application Service Tags

3GPP Diameter Application Service Tags

WiMAX Forum Diameter Application Service Tags

Vendor-Specific Diameter Application Service Tags

Diameter Application Protocol Tags

Security Considerations

Acknowledgments

Navigation

Wiki tools

Page tools

Categories