Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage
updates
- rfc-3588 — Diameter Base Protocol
Extracted elements (23)
NAPTR-based Diameter peer discovery for applications defining client/server roles should only be used by a client to discover servers, because the peer role is not advertised in NAPTR tags and is not communicated during Diameter capability negotiation.
The existing RFC 3588 NAPTR mechanism did not include the Diameter Application Identifier in the service field, forcing a peer to perform a Diameter capability exchange with every discovered node to find one supporting the required application. The extended S-NAPTR format eliminates this overhead by encoding the application ID directly in the DNS record.
The extended S-NAPTR application service tag is explicitly unrelated to the IANA 'Service Name and Transport Protocol Port Number Registry' (RFC 6335), even though both registries use similar-looking string formats.
The S-NAPTR application protocol tag uses '.' as a delimiter (e.g., 'diameter.sctp') purely for readability. This choice follows existing S-NAPTR registry conventions but explicitly does not imply structural or namespace semantics, and the tag MUST NOT be parsed by implementations.
This document updates RFC 3588 Section 5.2 NAPTR query procedure. Realms that have not provisioned extended S-NAPTR records will return legacy 'aaa:X' or 'aaa' service fields; the querying peer must handle all five NAPTR response patterns to interoperate with both old and new deployments.
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.
A vendor-specific Diameter application that requires S-NAPTR discovery MUST be associated with an 'aaa-service' tag formatted as defined in this specification and allocated in accordance with IANA policy.
DNS administrators SHOULD provision legacy RFC 3588-style NAPTR records in addition to extended S-NAPTR records to guarantee backwards compatibility with RFC 3588-compliant Diameter peers.
Every IETF Standards Track Diameter application MUST be associated with an 'aaa-service' tag formatted as defined in this specification and allocated in accordance with IANA policy.
For a vendor-specific Diameter application to reserve an S-NAPTR Application Service Tag, an RFC of any category MUST be published that reserves the tag corresponding to the Vendor-Specific Diameter Application ID.
Future Diameter versions that introduce new transport protocols MUST reserve an appropriate S-NAPTR Application Protocol Tag in the registry created by RFC 3958.
Future IETF Diameter applications MUST reserve the S-NAPTR application service tag corresponding to the allocated Diameter Application ID as defined in Section 3.
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 purely cosmetic.
When both extended S-NAPTR records and legacy RFC 3588 NAPTR records are provisioned, the extended S-NAPTR records MUST have higher priority (lower order and/or preference values) than legacy NAPTR records.
The extended NAPTR records provide a mapping from a domain to an SRV or A/AAAA record for a server supporting a specific transport protocol and Diameter application. Records contain an empty regular expression and a replacement value pointing to the SRV or A/AAAA record.
The extended S-NAPTR service field uses the tag format 'aaa+ap<appln-id>' where appln-id is the Diameter Application Identifier expressed as a decimal integer without leading zeros. This allows a querying node to discover which Diameter applications a peer supports without performing a capability exchange.
The S-NAPTR application protocol tags for Diameter transport are formatted as 'diameter.<transport>' where transport is one of 'tcp', 'sctp', or 'tls.tcp'. The delimiter '.' improves readability but does not imply any namespace hierarchy.
IANA has reserved 'aaa' as the base Diameter S-NAPTR Application Service Tag and allocated tags 'aaa+ap1' through 'aaa+ap9' for IETF Diameter applications (NASREQ, Mobile IPv4, Base Accounting, Credit Control, EAP, SIP, Mobile IPv6 IKE, Mobile IPv6 Auth, QoS) and 'aaa+ap4294967295' for the Relay application, in the S-NAPTR Application Service Tag registry.
IANA has reserved S-NAPTR application service tags for ten WiMAX Forum Diameter applications (aaa+ap16777281 through aaa+ap16777290) covering network access authentication, accounting, MIP4, MIP6, DHCP, location, and policy/charging control applications.
IANA has reserved three S-NAPTR Application Protocol Tags for Diameter transport protocols: 'diameter.tcp' (TCP), 'diameter.sctp' (SCTP), and 'diameter.tls.tcp' (TLS over TCP), in the S-NAPTR Application Protocol Tag registry created by RFC 3958.
The security considerations of RFC 3588 apply to this document; no additional security mechanisms are required. However, a malicious host performing S-NAPTR queries can learn the Diameter applications supported by agents in a realm more efficiently than via capability exchange, potentially enabling faster scanning of targets with known application vulnerabilities.
The extended NAPTR-based Diameter peer discovery procedure defines six steps: (a) query NAPTR for target realm; (b) if 'aaa+apX:Y' returned and X matches application and Y matches transport, resolve replacement; (c) if 'aaa+apX' returned and X matches, resolve and try all transports per RFC 3588 order; (d) if 'aaa:X' returned, resolve if transport matches; (e) if 'aaa' returned, resolve and try all transports; (f) if no NAPTR support, fall back to RFC 3588 Section 5.2 next mechanism.
The aaa-service tag is defined as 'aaa+ap' followed by an appln-id of 1–10 decimal digits (no leading zeros), encoding a 32-bit unsigned Diameter Application Identifier. The aaa-protocol tag is 'diameter.' followed by 'tcp', 'sctp', or 'tls.tcp'. The combined NAPTR service field must not exceed 256 octets including a one-octet length field.