From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6408.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc6408.txt (limited to 'doc/rfc/rfc6408.txt') diff --git a/doc/rfc/rfc6408.txt b/doc/rfc/rfc6408.txt new file mode 100644 index 0000000..2ebbca2 --- /dev/null +++ b/doc/rfc/rfc6408.txt @@ -0,0 +1,787 @@ + + + + + + +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. + + + + + + + + + + + + + +Jones, et al. Standards Track [Page 1] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 2.1. Requirements Language ......................................3 + 3. Extended NAPTR Service Field Format .............................3 + 3.1. IETF Standards Track Diameter Applications .................5 + 3.2. Vendor-Specific Diameter Applications ......................5 + 4. Backwards Compatibility .........................................5 + 5. Extended NAPTR-Based Diameter Peer Discovery ....................6 + 5.1. Examples ...................................................7 + 6. Usage Guidelines ................................................8 + 7. IANA Considerations .............................................9 + 7.1. IETF Diameter Application Service Tags .....................9 + 7.2. 3GPP Diameter Application Service Tags .....................9 + 7.3. WiMAX Forum Diameter Application Service Tags .............10 + 7.4. Vendor-Specific Diameter Application Service Tags .........10 + 7.5. Diameter Application Protocol Tags ........................11 + 8. Security Considerations ........................................11 + 9. Acknowledgments ................................................11 + 10. References ....................................................12 + 10.1. Normative References .....................................12 + 10.2. Informative References ...................................14 + +1. 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 + + + + + + +Jones, et al. Standards Track [Page 2] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + + 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. + +2. 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. + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Extended NAPTR Service Field Format + + The NAPTR service field 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. + + + + + +Jones, et al. Standards Track [Page 3] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + + 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]). + + + + + + + + + + +Jones, et al. Standards Track [Page 4] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + +3.1. 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. + +3.2. 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. + +4. 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. + + + + + + +Jones, et al. Standards Track [Page 5] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + +5. 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. + + + + + + + + +Jones, et al. Standards Track [Page 6] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + + 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]. + +5.1. Examples + + As an example, consider a client that wishes to discover a Diameter + server in the ex1.example.com realm that supports the Credit Control + application. The client performs a NAPTR query for that domain, and + the following NAPTR records are returned: + + + + + + +Jones, et al. Standards Track [Page 7] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + + ;; 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. + +6. 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. + + + +Jones, et al. Standards Track [Page 8] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + +7. IANA Considerations + +7.1. 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. + +7.2. 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. + + + + +Jones, et al. Standards Track [Page 9] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + +7.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]. + + +----------------+--------------------------------------------------+ + | Tag | Diameter Application | + +----------------+--------------------------------------------------+ + | aaa+ap16777281 | WiMAX Network Access Authentication and | + | | Authorization Diameter Application (WNAAADA) | + | | [WiMAX-BASE] | + | aaa+ap16777282 | WiMAX Network Accounting Diameter Application | + | | (WNADA) [WiMAX-BASE] | + | aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) | + | | [WiMAX-BASE] | + | aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) | + | | [WiMAX-BASE] | + | aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) | + | | [WiMAX-BASE] | + | aaa+ap16777286 | WiMAX Location Authentication Authorization | + | | Diameter Application (WLAADA) [WiMAX-LBS] | + | aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies | + | | Diameter Application (WiMAX PCC-R3-P) | + | | [WiMAX-PCC] | + | aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline | + | | Charging Diameter Application (WiMAX PCC-R3-OFC) | + | | [WiMAX-PCC] | + | aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline | + | | Charging Prime Diameter Application (WiMAX | + | | PCC-R3-OFC-PRIME) [WiMAX-PCC] | + | aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online | + | | Charging Diameter Application (WiMAX PCC-R3-OC) | + | | [WiMAX-PCC] | + +----------------+--------------------------------------------------+ + + 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. + +7.4. Vendor-Specific Diameter Application Service Tags + + Vendor-Specific Diameter Application IDs are allocated by IANA + according to the "First Come First Served" policy and do not require + an IETF specification. However, the S-NAPTR application service tag + registry created by [RFC3958] defines a registration policy of + + + +Jones, et al. Standards Track [Page 10] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + + "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. + +7.5. 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]. + +8. 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. + +9. Acknowledgments + + We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Sebastien + Decugis, Dan Romascanu, Adrian Farrel, David Harrington, Pete + Resnick, Robert Sparks, Stephen Farrell, Wesley Eddy, Ralph Droms, + and Joe Touch for their comprehensive review comments. + + + + + +Jones, et al. Standards Track [Page 11] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + +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. + + + + +Jones, et al. Standards Track [Page 12] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + + [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)", + . + + [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)", + . + + [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)", + . + + [WiMAX-BASE] WiMAX Forum, "WMF-T33-001-R015v02 - WiMAX Forum(R) + Network Architecture - Detailed Protocols and + Procedures, Base Specification - Release 1.5", + . + + [WiMAX-LBS] WiMAX Forum, "WMF-T33-110-R015v01 - WiMAX Forum(R) + Network Architecture - Protocols and Procedures for + Location Based Services - Release 1.5", + . + + + + + + + +Jones, et al. Standards Track [Page 13] + +RFC 6408 Diameter S-NAPTR Usage November 2011 + + + [WiMAX-PCC] WiMAX Forum, "WMF-T33-109-R015v02 - WiMAX Forum(R) + Network Architecture - Detailed Protocols and + Procedures, Policy and Charging Control - Release 1.5", + . + +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: mark@azu.ca + + + Jouni Korhonen + Nokia Siemens Networks + + EMail: jouni.nospam@gmail.com + + + Lionel Morand + Orange Labs + + EMail: lionel.morand@orange.com + + + + + + + + + + + + + + + + + + + +Jones, et al. Standards Track [Page 14] + -- cgit v1.2.3