draft-ietf-dime-extended-naptr-09.txt   rfc6408.txt 
Diameter Maintenance and Extensions M. Jones Internet Engineering Task Force (IETF) M. Jones
(DIME) Bridgewater Systems Request for Comments: 6408 Bridgewater Systems
Internet-Draft J. Korhonen Updates: 3588 J. Korhonen
Updates: 3588 (if approved) Nokia Siemens Networks Category: Standards Track Nokia Siemens Networks
Intended status: Standards Track L. Morand ISSN: 2070-1721 L. Morand
Expires: February 4, 2012 Orange Labs Orange Labs
August 3, 2011 November 2011
Diameter S-NAPTR Usage Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage
draft-ietf-dime-extended-naptr-09
Abstract Abstract
The Diameter base protocol specifies mechanisms whereby a given realm The Diameter base protocol specifies mechanisms whereby a given realm
may advertise Diameter nodes and the supported transport protocol. may advertise Diameter nodes and the supported transport protocol.
However, these mechanisms do not reveal the Diameter applications However, these mechanisms do not reveal the Diameter applications
that each node supports. A peer outside the realm would have to that each node supports. A peer outside the realm would have to
perform a Diameter capability exchange with every node until it perform a Diameter capability exchange with every node until it
discovers one that supports the required application. This document discovers one that supports the required application. This document
updates RFC3588 "Diameter Base Protocol" and describes an improvement updates RFC 3588, "Diameter Base Protocol", and describes an
using an extended format for the Straightforward-Naming Authority improvement using an extended format for the Straightforward-Naming
Pointer (S-NAPTR) Application Service Tag that allows for discovery Authority Pointer (S-NAPTR) application service tag that allows for
of the supported applications without doing Diameter capability discovery of the supported applications without doing Diameter
exchange beforehand. 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 Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on February 4, 2012. 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 Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology .....................................................3
3. Extended NAPTR Service Field Format . . . . . . . . . . . . . 3 2.1. Requirements Language ......................................3
3.1. IETF Standard Track Diameter Applications . . . . . . . . 4 3. Extended NAPTR Service Field Format .............................3
3.2. Vendor-specific Diameter Applications . . . . . . . . . . 5 3.1. IETF Standards Track Diameter Applications .................5
4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 5 3.2. Vendor-Specific Diameter Applications ......................5
5. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5 4. Backwards Compatibility .........................................5
5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Extended NAPTR-Based Diameter Peer Discovery ....................6
6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Examples ...................................................7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Usage Guidelines ................................................8
7.1. IETF Diameter Application Service Tags . . . . . . . . . . 8 7. IANA Considerations .............................................9
7.2. 3GPP Diameter Application Service Tags . . . . . . . . . . 9 7.1. IETF Diameter Application Service Tags .....................9
7.3. WiMAX Forum Diameter Application Service Tags . . . . . . 9 7.2. 3GPP Diameter Application Service Tags .....................9
7.4. Vendor-Specific Diameter Application Service Tags . . . . 10 7.3. WiMAX Forum Diameter Application Service Tags .............10
7.5. Diameter Application Protocol Tags . . . . . . . . . . . . 10 7.4. Vendor-Specific Diameter Application Service Tags .........10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7.5. Diameter Application Protocol Tags ........................11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations ........................................11
10. Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments ................................................11
11. Normative References . . . . . . . . . . . . . . . . . . . . . 12 10. References ....................................................12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References .....................................12
10.2. Informative References ...................................14
1. Introduction 1. Introduction
The Diameter base protocol [RFC3588] specifies three mechanisms for The Diameter base protocol [RFC3588] specifies three mechanisms for
the Diameter peer discovery. One of these involves the Diameter Diameter peer discovery. One of these involves the Diameter
implementation performing a Naming Authority Pointer (NAPTR) query 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) provide a mapping from a domain to the DNS Service Locator (SRV)
record [RFC2782] or A/AAAA record [RFC1035][RFC3596] for contacting a record [RFC2782] or A/AAAA record [RFC1035] [RFC3596] for contacting
server with the specific transport protocol in the NAPTR services a server with the specific transport protocol in the NAPTR services
field. field.
The extended NAPTR usage for Diameter peer discovery defined by this The extended NAPTR usage for Diameter peer discovery defined by this
document is based on the Straightforward-NAPTR (S-NAPTR) Dynamic 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 This document updates the Diameter peer discovery procedure described
in Section 11.6 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 and application protocol tag values that permit the discovery of
Diameter peers that support a specific Diameter application and Diameter peers that support a specific Diameter application and
transport protocol. transport protocol.
2. Terminology 2. Terminology
The Diameter base protocol specification (Section 1.4 of [RFC3588]) The Diameter base protocol specification (Section 1.3 of [RFC3588])
and the Straightforward-NAPTR (S-NAPTR) DDDS application (section 2.1 and the Straightforward-NAPTR (S-NAPTR) DDDS application (Section 2.1
in [RFC3958]) define the terminology used in this document. 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 3. Extended NAPTR Service Field Format
The NAPTR Service Field format defined by the S-NAPTR DDDS 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)] service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUMSYM iana-registered-protocol = ALPHA *31ALPHANUMSYM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9 DIGIT = %x30-39 ; 0-9
skipping to change at page 4, line 12 skipping to change at page 4, line 12
; characters and must start with an alphabetic character. ; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive. ; The service-parms are considered case-insensitive.
This specification refines the "iana-registered-service" tag This specification refines the "iana-registered-service" tag
definition for the discovery of Diameter agents supporting a specific definition for the discovery of Diameter agents supporting a specific
Diameter application as defined below. Diameter application as defined below.
iana-registered-service =/ aaa-service iana-registered-service =/ aaa-service
aaa-service = "aaa+ap" appln-id aaa-service = "aaa+ap" appln-id
appln-id = 1*10DIGIT appln-id = 1*10DIGIT
; Application identifier expressed as ; Application Identifier expressed as
; a decimal integer without leading ; a decimal integer without leading
; zeros. ; zeros.
The appln-id element is the Application Identifier used to identify a The appln-id element is the Application Identifier used to identify a
specific Diameter Application. The Diameter Application Identifier specific Diameter application. The Diameter Application Identifier
is a 32-bit unsigned integer and values are allocated by IANA as 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 This specification also refines the "iana-registered-protocol" tag
definition for the discovery of Diameter agents supporting a specific definition for the discovery of Diameter agents supporting a specific
Diameter transport protocol as defined below. Diameter transport protocol as defined below.
iana-registered-protocol =/ aaa-protocol / iana-registered-protocol =/ aaa-protocol
aaa-protocol = "diameter." aaa-transport aaa-protocol = "diameter." aaa-transport
aaa-transport = "tcp" / "sctp" / "tls.tcp" aaa-transport = "tcp" / "sctp" / "tls.tcp"
The S-NAPTR Application Protocol tags defined by this specification The S-NAPTR application protocol tags defined by this specification
MUST NOT be parsed in any way by the querying application or MUST NOT be parsed in any way by the querying application or
resolver. The delimiter (".") is present in the tag to improve resolver. The delimiter (".") is present in the tag to improve
readability and does not imply a structure or namespace of any kind. readability and does not imply a structure or namespace of any kind.
The choice of delimiter (".") for the Application Protocol tag The choice of delimiter (".") for the application protocol tag
follows the format of existing S-NAPTR Application Protocol tag follows the format of existing S-NAPTR application protocol tag
registry entries but this does not imply that that it shares registry entries, but this does not imply that it shares semantics
semantics with any other specifications that create registry entries with any other specifications that create registry entries with the
with the same format. same format.
The S-NAPTR Application Service and Protocol tags defined by this The S-NAPTR application service and application protocol tags defined
specification are unrelated to the IANA Service Name and Transport by this specification are unrelated to the IANA "Service Name and
Protocol Port Number Registry (see [I-D.ietf-tsvwg-iana-ports]). Transport Protocol Port Number Registry" (see [RFC6335]).
The maximum length of the NAPTR service field is 256 octets including The maximum length of the NAPTR service field is 256 octets,
one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 including a one-octet length field (see Section 4.1 of [RFC3403] and
of [RFC1035]). Section 3.3 of [RFC1035]).
3.1. IETF Standard Track Diameter Applications 3.1. IETF Standards Track Diameter Applications
A Diameter agent MUST be capable of using the extended S-NAPTR A Diameter agent MUST be capable of using the extended S-NAPTR
Application Service Tag for dynamic discovery of a Diameter agent application service tag for dynamic discovery of a Diameter agent
supporting Standard Track applications. Therefore, every IETF supporting Standards Track applications. Therefore, every IETF
Standard Track Diameter application MUST be associated with a "aaa- Standards Track Diameter application MUST be associated with a
service" tag formatted as defined in this specification and allocated "aaa-service" tag formatted as defined in this specification and
in accordance with the IANA policy (see Section 7). allocated in accordance with IANA policy (see Section 7).
For example, a NAPTR service field value of: For example, a NAPTR service field value of:
'aaa+ap6:diameter.sctp' 'aaa+ap6:diameter.sctp'
Means that the Diameter node in the SRV or A/AAAA record supports means that the Diameter node in the SRV or A/AAAA record supports the
the Diameter Session Initiation Protocol (SIP) Application ('6') Diameter Session Initiation Protocol (SIP) application ('6') and the
and SCTP as the transport protocol. Stream Control Transmission Protocol (SCTP) as the transport
protocol.
3.2. Vendor-specific Diameter Applications 3.2. Vendor-Specific Diameter Applications
S-NAPTR Application Service and Application Protocol Tag values can S-NAPTR application service and application protocol tag values can
also be used to discover Diameter peers that support a vendor- also be used to discover Diameter peers that support a vendor-
specific Diameter application. In this case, the vendor-specific specific Diameter application. In this case, the vendor-specific
Diameter application MUST be associated with a "aaa-service" tag Diameter application MUST be associated with a "aaa-service" tag
formatted as defined in this specification and allocated in formatted as defined in this specification and allocated in
accordance with the IANA policy (see Section 7). accordance with IANA policy (see Section 7).
For example, a NAPTR service field value of: For example, a NAPTR service field value of:
'aaa+ap16777251:diameter.sctp' 'aaa+ap16777251:diameter.sctp'
Means that the Diameter node in the SRV or A/AAAA record supports means that the Diameter node in the SRV or A/AAAA record supports the
the Diameter 3GPP S6a Application ('16777251') and SCTP as the Diameter Third Generation Partnership Project (3GPP) S6a application
transport protocol. ('16777251') and SCTP as the transport protocol.
4. Backwards Compatibility 4. Backwards Compatibility
Domain Name System (DNS) administrators SHOULD also provision legacy Domain Name System (DNS) administrators SHOULD also provision legacy
RFC 3588 style NAPTR records [RFC3403] in order to guarantee NAPTR records [RFC3403] in the RFC 3588 style in order to guarantee
backwards compatibility with legacy RFC 3588 compliant Diameter backwards compatibility with legacy Diameter peers that are RFC 3588
peers. If the DNS administrator provisions both extended S-NAPTR compliant. If the DNS administrator provisions both extended S-NAPTR
records as defined in this specification and legacy RFC 3588 NAPTR records as defined in this specification and legacy RFC 3588 NAPTR
records, then the extended S-NAPTR records MUST have higher priority records, then the extended S-NAPTR records MUST have higher priority
(e.g. lower order and/or preference values) than legacy NAPTR (e.g., lower order and/or preference values) than legacy NAPTR
records. records.
5. Extended NAPTR-based Diameter Peer Discovery 5. Extended NAPTR-Based Diameter Peer Discovery
The Diameter Peer Discovery principles are described in Section 5.2 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 in the Diameter peer discovery mechanism by allowing the querying
node to determine which applications are supported by resolved node to determine which applications are supported by resolved
Diameter peers. Diameter peers.
The extended format NAPTR records provide a mapping from a domain to 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 the SRV record or A/AAAA record for contacting a server supporting a
specific transport protocol and Diameter application. The resource specific transport protocol and Diameter application. The resource
record will contain an empty regular expression and a replacement record will contain an empty regular expression and a replacement
value, which is the SRV record or the A/AAAA record for that value, which is the SRV record or the A/AAAA record for that
particular transport protocol. particular transport protocol.
The assumption for this mechanism to work is that the DNS The assumption for this mechanism to work is that the DNS
administrator of the queried domain has first provisioned the DNS administrator of the queried domain has first provisioned the DNS
with extended format NAPTR entries. The steps below replace the 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 a. The Diameter implementation performs a NAPTR query for a server in
a particular realm. The Diameter implementation has to know in a particular realm. The Diameter implementation has to know in
advance which realm to look for a Diameter agent in and which advance in which realm to look for a Diameter agent, and in which
Application Identifier it is interested in. For example, the Application Identifier it is interested. For example, the realm
realm could be deduced from the Network Access Identifier (NAI) in could be deduced from the Network Access Identifier (NAI) in the
the User-Name AVP or extracted from the Destination-Realm AVP. User-Name attribute-value pair (AVP) or extracted from the
Destination-Realm AVP.
b. If the returned NAPTR service fields contain entries formatted as b. If the returned NAPTR service fields contain entries formatted as
"aaa+apX:Y" where "X" indicates the Application Identifier and "Y" "aaa+apX:Y" where "X" indicates the Application Identifier and "Y"
indicates the supported transport protocol(s), the target realm indicates the supported transport protocol(s), the target realm
supports the extended format for NAPTR-based Diameter peer supports the extended format for NAPTR-based Diameter peer
discovery defined in this document. discovery defined in this document.
If "X" contains the required Application Identifier and "Y" If "X" contains the required Application Identifier and "Y"
matches a supported transport protocol, the Diameter matches a supported transport protocol, the Diameter
implementation resolves the "replacement" field entry to a implementation resolves the "replacement" field entry to a
skipping to change at page 6, line 49 skipping to change at page 7, line 14
c. If the returned NAPTR service fields contain entries formatted as c. If the returned NAPTR service fields contain entries formatted as
"aaa+apX" where "X" indicates the Application Identifier, the "aaa+apX" where "X" indicates the Application Identifier, the
target realm supports the extended format for NAPTR-based Diameter target realm supports the extended format for NAPTR-based Diameter
peer discovery defined in this document. peer discovery defined in this document.
If "X" contains the required Application Identifier, the If "X" contains the required Application Identifier, the
Diameter implementation resolves the "replacement" field entry Diameter implementation resolves the "replacement" field entry
to a target host using the lookup method appropriate for the to a target host using the lookup method appropriate for the
"flags" field and attempts to connect using all supported "flags" field and attempts to connect using all supported
transport protocols following the order specified in section transport protocols following the order specified in
2.1 of [RFC3588]. Section 2.1 of [RFC3588].
If "X" does not contain the required Application Identifier, If "X" does not contain the required Application Identifier,
the Diameter implementation abandons the peer discovery. the Diameter implementation abandons the peer discovery.
d. If the returned NAPTR service fields contain entries formatted as d. If the returned NAPTR service fields contain entries formatted as
"aaa:X" where "X" indicates the supported transport protocol(s), "aaa:X" where "X" indicates the supported transport protocol(s),
the target realm supports Diameter but does not support the the target realm supports Diameter but does not support the
extended format for NAPTR-based Diameter peer discovery defined in extended format for NAPTR-based Diameter peer discovery defined in
this document. this document.
skipping to change at page 7, line 26 skipping to change at page 7, line 38
target host using the lookup method appropriate for the "flags" target host using the lookup method appropriate for the "flags"
field. field.
e. If the returned NAPTR service fields contain entries formatted as e. If the returned NAPTR service fields contain entries formatted as
"aaa", the target realm supports Diameter but does not support the "aaa", the target realm supports Diameter but does not support the
extended format for NAPTR-based Diameter peer discovery defined in extended format for NAPTR-based Diameter peer discovery defined in
this document. The Diameter implementation resolves the this document. The Diameter implementation resolves the
"replacement" field entry to a target host using the lookup method "replacement" field entry to a target host using the lookup method
appropriate for the "flags" field and attempts to connect using appropriate for the "flags" field and attempts to connect using
all supported transport protocols following the order specified in 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 f. If the target realm does not support NAPTR-based Diameter peer
discovery, the client proceeds with the next peer discovery 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].
5.1. Examples 5.1. Examples
As an example, consider a client that wishes to discover a Diameter As an example, consider a client that wishes to discover a Diameter
server in the ex1.example.com realm that supports the Credit Control server in the ex1.example.com realm that supports the Credit Control
Application. The client performs a NAPTR query for that domain, and application. The client performs a NAPTR query for that domain, and
the following NAPTR records are returned: the following NAPTR records are returned:
;; order pref flags service regexp replacement ;; order pref flags service regexp replacement
IN NAPTR 50 50 "s" "aaa:diameter.sctp" "" IN NAPTR 50 50 "s" "aaa:diameter.sctp" ""
_diameter._sctp.ex1.example.com _diameter._sctp.ex1.example.com
IN NAPTR 50 50 "s" "aaa+ap1:diameter.sctp" "" IN NAPTR 50 50 "s" "aaa+ap1:diameter.sctp" ""
_diameter._sctp.ex1.example.com _diameter._sctp.ex1.example.com
IN NAPTR 50 50 "s" "aaa+ap4:diameter.sctp" "" IN NAPTR 50 50 "s" "aaa+ap4:diameter.sctp" ""
_diameter._sctp.ex1.example.com _diameter._sctp.ex1.example.com
This indicates that the server supports NASREQ (ID=1) and Credit This indicates that the server supports NASREQ (ID=1) and Credit
Control (ID=4) Applications over SCTP. If the client supports SCTP, 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 it will be used, targeted to a host determined by an SRV lookup of
_diameter._sctp.ex1.example.com. _diameter._sctp.ex1.example.com.
That SRV lookup would return: That SRV lookup would return:
;; Priority Weight Port Target ;; Priority Weight Port Target
IN SRV 0 1 3868 server1.ex1.example.com IN SRV 0 1 3868 server1.ex1.example.com
IN SRV 0 2 3868 server2.ex1.example.com IN SRV 0 2 3868 server2.ex1.example.com
As an alternative example, a client that wishes to discover a As an alternative example, a client wishes to discover a Diameter
Diameter server in the ex2.example.com realm that supports the NASREQ server in the ex2.example.com realm that supports the NASREQ
application over SCTP. The client performs a NAPTR query for that application over SCTP. The client performs a NAPTR query for that
domain, and the following NAPTR records are returned: domain, and the following NAPTR records are returned:
;; order pref flags service regexp replacement ;; order pref flags service regexp replacement
IN NAPTR 150 50 "a" "aaa:diameter.stcp" "" IN NAPTR 150 50 "a" "aaa:diameter.sctp" ""
server1.ex2.example.com server1.ex2.example.com
IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" ""
server2.ex2.example.com server2.ex2.example.com
IN NAPTR 150 50 "a" "aaa+ap1:diameter.stcp" "" IN NAPTR 150 50 "a" "aaa+ap1:diameter.sctp" ""
server1.ex2.example.com server1.ex2.example.com
IN NAPTR 150 50 "a" "aaa+ap1:diameter.tls.tcp" "" IN NAPTR 150 50 "a" "aaa+ap1:diameter.tls.tcp" ""
server2.ex2.example.com server2.ex2.example.com
This indicates that the server supports NASREQ (ID=1) over SCTP and This indicates that the server supports NASREQ (ID=1) over SCTP and
TLS/TCP via hosts server1.ex2.example.com and server2.ex2.example.com Transport Layer Security (TLS)/TCP via hosts server1.ex2.example.com
respectively. and server2.ex2.example.com, respectively.
6. Usage Guidelines 6. Usage Guidelines
Diameter is a peer to peer protocol whereas most of the applications Diameter is a peer-to-peer protocol, whereas most of the applications
that extend the base protocol behave like client/server 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 The role of the peer is not advertised in the NAPTR tags and not even
communicated during Diameter capability negotiation (Capabilities- communicated during Diameter capability negotiation
Exchange-Request and Capabilities-Exchange-Answer message exchange). (Capabilities-Exchange-Request and Capabilities-Exchange-Answer
For this reason, NAPTR-based Diameter peer discovery for an message exchange). For this reason, NAPTR-based Diameter peer
application defining client/server roles should only be used by a discovery for an application defining client/server roles should only
client to discover servers. be used by a client to discover servers.
7. IANA Considerations 7. IANA Considerations
7.1. IETF Diameter Application Service Tags 7.1. IETF Diameter Application Service Tags
IANA is requested to reserve a value of "aaa" for Diameter in the IANA has reserved a value of "aaa" for Diameter in the "(S-NAPTR)
S-NAPTR Application Service Tag registry created by [RFC3958]. IANA Application Service Tag" registry created by [RFC3958]. IANA has
is also requested to reserve the following S-NAPTR Application also reserved the following S-NAPTR application service tags for
Service Tags for existing IETF Diameter applications in the same existing IETF Diameter applications in the same registry.
registry.
+------------------+----------------------------+ +------------------+----------------------------+
| Tag | Diameter Application | | 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] |
+------------------+----------------------------+ +------------------+----------------------------+
Future IETF Diameter applications MUST reserve the S-NAPTR Future IETF Diameter applications MUST reserve the S-NAPTR
Application Service Tag corresponding to the allocated Diameter application service tag corresponding to the allocated Diameter
Application ID as defined in Section 3. Application ID as defined in Section 3.
7.2. 3GPP Diameter Application Service Tags 7.2. 3GPP Diameter Application Service Tags
IANA is requested to reserve the following S-NAPTR Application IANA has reserved the following S-NAPTR application service tags for
Service Tags for existing 3GPP Diameter applications in the S-NAPTR existing 3GPP Diameter applications in the "S-NAPTR Application
Application Service Tag registry created by [RFC3958]. Service Tag" registry created by [RFC3958].
+----------------+----------------------+ +----------------+----------------------+
| Tag | Diameter Application | | Tag | Diameter Application |
+----------------+----------------------+ +----------------+----------------------+
| aaa+ap16777250 | 3GPP STa [TS29.273] | | aaa+ap16777250 | 3GPP STa [TS29.273] |
| aaa+ap16777251 | 3GPP S6a [TS29.272] | | aaa+ap16777251 | 3GPP S6a [TS29.272] |
| aaa+ap16777264 | 3GPP SWm [TS29.273] | | aaa+ap16777264 | 3GPP SWm [TS29.273] |
| aaa+ap16777267 | 3GPP S9 [TS29.215] | | aaa+ap16777267 | 3GPP S9 [TS29.215] |
+----------------+----------------------+ +----------------+----------------------+
Future 3GPP Diameter applications can reserve entries in the S-NAPTR Future 3GPP Diameter applications can reserve entries in the "S-NAPTR
Application Service Tag registry created by [RFC3958] which Application Service Tag" registry created by [RFC3958] that
correspond to the allocated Diameter Application IDs as defined in correspond to the allocated Diameter Application IDs as defined in
Section 3. Section 3.
7.3. WiMAX Forum Diameter Application Service Tags 7.3. WiMAX Forum Diameter Application Service Tags
IANA is requested to reserve the following S-NAPTR Application IANA has reserved the following S-NAPTR application service tags for
Service Tags for existing WiMAX Forum Diameter applications in the existing Worldwide Interoperability for Microwave Access (WiMAX)
S-NAPTR Application Service Tag registry created by [RFC3958]. Forum Diameter applications in the "S-NAPTR Application Service Tag"
registry created by [RFC3958].
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Tag | Diameter Application | | Tag | Diameter Application |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| aaa+ap16777281 | WiMAX Network Access Authentication and | | aaa+ap16777281 | WiMAX Network Access Authentication and |
| | Authorization Diameter Application (WNAAADA) | | | Authorization Diameter Application (WNAAADA) |
| | [WiMAX] | | | [WiMAX-BASE] |
| aaa+ap16777282 | WiMAX Network Accounting Diameter Application | | aaa+ap16777282 | WiMAX Network Accounting Diameter Application |
| | (WNADA) [WiMAX] | | | (WNADA) [WiMAX-BASE] |
| aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) [WiMAX] | | aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) |
| aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) [WiMAX] | | | [WiMAX-BASE] |
| aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) [WiMAX] | | aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) |
| | [WiMAX-BASE] |
| aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) |
| | [WiMAX-BASE] |
| aaa+ap16777286 | WiMAX Location Authentication Authorization | | aaa+ap16777286 | WiMAX Location Authentication Authorization |
| | Diameter Application (WLAADA) [WiMAX] | | | Diameter Application (WLAADA) [WiMAX-LBS] |
| aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies | | aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies |
| | Diameter Application (WiMAX PCC-R3-P) [WiMAX] | | | Diameter Application (WiMAX PCC-R3-P) |
| | [WiMAX-PCC] |
| aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline | | aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline |
| | Charging Diameter Application (WiMAX PCC-R3-OFC) | | | Charging Diameter Application (WiMAX PCC-R3-OFC) |
| | [WiMAX] | | | [WiMAX-PCC] |
| aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline | | aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline |
| | Charging Prime Diameter Application (WiMAX | | | Charging Prime Diameter Application (WiMAX |
| | PCC-R3-OFC-PRIME) [WiMAX] | | | PCC-R3-OFC-PRIME) [WiMAX-PCC] |
| aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online | | aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online |
| | Charging Diameter Application (WiMAX PCC-R3-OC) | | | Charging Diameter Application (WiMAX PCC-R3-OC) |
| | [WiMAX] | | | [WiMAX-PCC] |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
Future WiMAX Forum Diameter applications can reserve entries in the Future WiMAX Forum Diameter applications can reserve entries in the
S-NAPTR Application Service Tag registry created by [RFC3958] which "S-NAPTR Application Service Tag" registry created by [RFC3958] that
correspond to the allocated Diameter Application IDs as defined in correspond to the allocated Diameter Application IDs as defined in
Section 3. Section 3.
7.4. Vendor-Specific Diameter Application Service Tags 7.4. Vendor-Specific Diameter Application Service Tags
Vendor-Specific Diameter Application IDs are allocated by IANA Vendor-Specific Diameter Application IDs are allocated by IANA
according to the "First Come First Served" policy and do not require according to the "First Come First Served" policy and do not require
an IETF specification. However, the S-NAPTR Application Service Tag 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 "Specification Required" with a further stipulation that the
"specification" is an RFC (of any category). If a Vendor-Specific "specification" is an RFC (of any category). If a vendor-specific
Diameter Application requires the functionality defined in this Diameter application requires the functionality defined in this
document, an RFC of any category MUST be published which reserves the document, an RFC of any category MUST be published that reserves the
S-NAPTR Application Service Tag corresponding to the Vendor-Specific S-NAPTR Application Service Tag corresponding to the Vendor-Specific
Diameter Application ID as defined in Section 3. Diameter Application ID as defined in Section 3.
7.5. Diameter Application Protocol Tags 7.5. Diameter Application Protocol Tags
IANA is requested to reserve the following S-NAPTR Application IANA has reserved the following S-NAPTR Application Protocol Tags for
Protocol Tags for the Diameter transport protocols in the S-NAPTR the Diameter transport protocols in the "S-NAPTR Application Protocol
Application Protocol Tag registry created by [RFC3958]. Tag" registry created by [RFC3958].
+------------------+----------+ +------------------+----------+
| Tag | Protocol | | Tag | Protocol |
+------------------+----------+ +------------------+----------+
| diameter.tcp | TCP | | diameter.tcp | TCP |
| diameter.sctp | SCTP | | diameter.sctp | SCTP |
| diameter.tls.tcp | TLS/TCP | | diameter.tls.tcp | TLS/TCP |
+------------------+----------+ +------------------+----------+
Future Diameter versions which introduce new transport protocols MUST Future Diameter versions that introduce new transport protocols MUST
reserve an appropriate S-NAPTR Application Protocol Tag in the 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].
8. Security Considerations 8. Security Considerations
This document specifies an enhancement to RFC 3588 Diameter base This document specifies an enhancement to the NAPTR service field
protocol defined NAPTR service field format and also modifications to format defined in RFC 3588 and also modifications to the NAPTR
the NAPTR processing logic defined. The enhancements and processing logic defined in RFC 3588. The enhancement and
modifications are based on the S-NAPTR, which is actually a modifications are based on the S-NAPTR, which is actually a
simplification of the NAPTR, and therefore the same security simplification of the NAPTR, and therefore the same security
considerations described in RFC 3588 are applicable to this document. considerations described in RFC 3588 [RFC3588] are applicable to this
No further extensions are required beyond the security mechanisms document. No further extensions are required beyond the security
offered by RFC 3588. However, a malicious host doing S-NAPTR queries mechanisms offered by RFC 3588. However, a malicious host doing
learns applications supported by Diameter agents in a certain realm S-NAPTR queries learns applications supported by Diameter agents in a
faster, which might help the malicious host to scan potential targets certain realm faster, which might help the malicious host to scan
for an attack more efficiently when some applications have known potential targets for an attack more efficiently when some
vulnerabilities. applications have known vulnerabilities.
9. Acknowledgments 9. Acknowledgments
We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Sebastien We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Sebastien
Decugis, Dan Romascanu, Adrian Farrel, David Harrington, Pete Decugis, Dan Romascanu, Adrian Farrel, David Harrington, Pete
Resnick, Robert Sparks, Stephen Farrell, Wesley Eddy, Ralph Droms and Resnick, Robert Sparks, Stephen Farrell, Wesley Eddy, Ralph Droms,
Joe Touch and for their comprehensive review comments. and Joe Touch for their comprehensive review comments.
10. Editor's Notes
This section to be removed prior to publication. 10. References
This draft updates sections of RFC3588 that are also being updated by 10.1. Normative References
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: [RFC1035] Mockapetris, P., "Domain names - implementation and
diameter.sctp") were also contributed to RFC3588bis to ensure that it specification", STD 13, RFC 1035, November 1987.
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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Tag registry value of "aaa" and the S-NAPTR Application Protocol Tags Requirement Levels", BCP 14, RFC 2119, March 1997.
values ("diameter.tcp"/"diameter.sctp"/"diameter.tls.tcp") will need
to be removed either from this draft or RFC3588bis.
11. Normative References [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)",
RFC 2782, February 2000.
[I-D.ietf-tsvwg-iana-ports] [RFC3403] Mealling, M., "Dynamic Delegation Discovery System
Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. (DDDS) Part Three: The Domain Name System (DNS)
Cheshire, "Internet Assigned Numbers Authority (IANA) Database", RFC 3403, October 2002.
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 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
specification", STD 13, RFC 1035, November 1987. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
Requirement Levels", BCP 14, RFC 2119, March 1997. "DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
specifying the location of services (DNS SRV)", RFC 2782, Service Location Using SRV RRs and the Dynamic
February 2000. Delegation Discovery Service (DDDS)", RFC 3958,
January 2005.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T.,
Part Three: The Domain Name System (DNS) Database", Ed., and P. McCann, "Diameter Mobile IPv4 Application",
RFC 3403, October 2002. RFC 4004, August 2005.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. J. Loughney, "Diameter Credit-Control Application",
RFC 4006, August 2005.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
"DNS Extensions to Support IP Version 6", RFC 3596, Extensible Authentication Protocol (EAP) Application",
October 2003. RFC 4072, August 2005.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application [RFC4740] Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez,
Service Location Using SRV RRs and the Dynamic Delegation M., Canales-Valenzuela, C., and K. Tammi, "Diameter
Discovery Service (DDDS)", RFC 3958, January 2005. Session Initiation Protocol (SIP) Application",
RFC 4740, November 2006.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, Syntax Specifications: ABNF", STD 68, RFC 5234,
August 2005. January 2008.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. [RFC5778] Korhonen, J., Ed., Tschofenig, H., Bournelle, J.,
Loughney, "Diameter Credit-Control Application", RFC 4006, Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6:
August 2005. Support for Home Agent to Diameter Server Interaction",
RFC 5778, February 2010.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible [RFC5866] Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T.,
Authentication Protocol (EAP) Application", RFC 4072, Doria, A., and G. Zorn, Ed., "Diameter
August 2005. Quality-of-Service Application", RFC 5866, May 2010.
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., [TS29.215] 3rd Generation Partnership Project, "3GPP TS 29.215;
Canales-Valenzuela, C., and K. Tammi, "Diameter Session Technical Specification Group Core Network and
Initiation Protocol (SIP) Application", RFC 4740, Terminals; Policy and Charging Control (PCC) over S9
November 2006. reference point; Stage 3 (Release 8)",
<http://www.3gpp.org/ftp/Specs/html-info/29215.htm>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [TS29.272] 3rd Generation Partnership Project, "3GPP TS 29.272;
Specifications: ABNF", STD 68, RFC 5234, January 2008. 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>.
[RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., [TS29.273] 3rd Generation Partnership Project, "3GPP TS 29.273;
and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Technical Specification Group Core Network and
Agent to Diameter Server Interaction", RFC 5778, Terminals; Evolved Packet System (EPS); 3GPP EPS AAA
February 2010. interfaces (Release 8)",
<http://www.3gpp.org/ftp/Specs/html-info/29273.htm>.
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., [WiMAX-BASE] WiMAX Forum, "WMF-T33-001-R015v02 - WiMAX Forum(R)
and G. Zorn, "Diameter Quality-of-Service Application", Network Architecture - Detailed Protocols and
RFC 5866, May 2010. Procedures, Base Specification - Release 1.5",
<http://www.wimaxforum.org/resources/
documents/technical/T33>.
[TS29.215] [WiMAX-LBS] WiMAX Forum, "WMF-T33-110-R015v01 - WiMAX Forum(R)
3rd Generation Partnership Project, "3GPP TS 29.215; Network Architecture - Protocols and Procedures for
Technical Specification Group Core Network and Terminals; Location Based Services - Release 1.5",
Policy and Charging Control (PCC) over S9 reference point; <http://www.wimaxforum.org/resources/
Stage 3 (Release 8)", documents/technical/T33>.
<http://www.3gpp.org/ftp/Specs/html-info/29215.htm>.
[TS29.272] [WiMAX-PCC] WiMAX Forum, "WMF-T33-109-R015v02 - WiMAX Forum(R)
3rd Generation Partnership Project, "3GPP TS 29.272; Network Architecture - Detailed Protocols and
Technical Specification Group Core Network and Terminals; Procedures, Policy and Charging Control - Release 1.5",
Evolved Packet System; Mobility Management Entity (MME) <http://www.wimaxforum.org/resources/
and Serving GPRS Support Node (SGSN) Related Interfaces documents/technical/T33>.
Based on Diameter Protocol (Release 8)",
<http://www.3gpp.org/ftp/Specs/html-info/29272.htm>.
[TS29.273] 10.2. Informative References
3rd Generation Partnership Project, "3GPP TS 29.273;
Technical Specification Group Core Network and Terminals;
Evolved Packet System; 3GPP EPS AAA interfaces (Release
8)", <http://www.3gpp.org/ftp/Specs/html-info/29273.htm>.
[WiMAX] WiMAX Forum, "WiMAX Release 1.5", <http:// [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and
www.wimaxforum.org/resources/documents/technical/T33>. 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 Authors' Addresses
Mark Jones Mark Jones
Bridgewater Systems Bridgewater Systems
Email: mark@azu.ca EMail: mark@azu.ca
Jouni Korhonen Jouni Korhonen
Nokia Siemens Networks Nokia Siemens Networks
Email: jouni.nospam@gmail.com EMail: jouni.nospam@gmail.com
Lionel Morand Lionel Morand
Orange Labs Orange Labs
Email: lionel.morand@orange-ftgroup.com EMail: lionel.morand@orange.com
 End of changes. 95 change blocks. 
260 lines changed or deleted 260 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/