RFC 6408
Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage
RFC 6408: Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage ✨
okay bestie, here's the tea 🫶 This is RFC 6408, titled Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage, published in November 2011 by the IETF. It's a Standards Track doc, which means it's the real deal and not just an opinion piece. The authors are M. Jones (Bridgewater Systems), J. Korhonen (Nokia Siemens Networks), and L. Morand (Orange Labs). It's an IETF stream document with ISSN 2070-1721. The header says it updates RFC 3588 (the Diameter base protocol) and doesn't list anything it obsoletes 💜
Abstract
okay so the Diameter base protocol lets a realm advertise its Diameter nodes and which transport protocol they speak 🦋 but here's the problem: it doesn't tell you which Diameter applications each node supports 😭 so a peer outside the realm would have to do a full Diameter capability exchange with every single node until it finds one that does the job. that's so much work, not me 💀
this doc fixes that with an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) application service tag. with it, you can discover the supported applications without doing the capability exchange first. iconic ✨
Status of This Memo
this is an Internet Standards Track document 🌸
it's a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, received public review, and got approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 💅
info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6408 🎀
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🔥
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. please actually read those, bestie, because they spell out your rights and restrictions 🙈 and if you pull Code Components out of this doc, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per 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 ...................................141. Introduction 🧚
the Diameter base protocol [RFC3588] gives you three mechanisms for Diameter peer discovery 💖 one of them has the Diameter implementation send a Naming Authority Pointer (NAPTR) query [RFC3403] for a server in a particular realm. those NAPTR records map a domain to either a DNS Service Locator (SRV) record [RFC2782] or an A/AAAA record [RFC1035] [RFC3596], which is how you reach a server using the transport protocol named in the NAPTR services field ✨
the extended NAPTR usage for Diameter peer discovery in this doc is built on the Straightforward-NAPTR (S-NAPTR) Dynamic Delegation Discovery System (DDDS) application defined in [RFC3958] 🦋 it updates the Diameter peer discovery procedure from Section 5.2 of [RFC3588] and defines S-NAPTR application service and application protocol tag values. those tags let you discover Diameter peers that support a specific Diameter application and transport protocol 👑
2. Terminology 🌈
the terms used here come from the Diameter base protocol spec (Section 1.3 of [RFC3588]) and the Straightforward-NAPTR (S-NAPTR) DDDS application (Section 2.1 of [RFC3958]) 💜
2.1. Requirements Language 💅
here's the key-word bit 🙈 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.this spec refines the "iana-registered-service" tag so you can discover Diameter agents that support a specific Diameter application, like so 🌸
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 is the Application Identifier that picks out one specific Diameter application 🧚 the Diameter Application Identifier is a 32-bit unsigned integer, and IANA allocates the values as defined in [RFC3588] 💖
this spec also refines the "iana-registered-protocol" tag so you can discover Diameter agents that support a specific Diameter transport protocol 🦋
iana-registered-protocol =/ aaa-protocol
aaa-protocol = "diameter." aaa-transport
aaa-transport = "tcp" / "sctp" / "tls.tcp"bestie, important: the S-NAPTR application protocol tags defined by this spec MUST NOT be parsed in any way by the querying application or resolver 🚨 the "." delimiter is only there to make the tag easier to read. it doesn't imply any structure or namespace at all 💀
the "." delimiter in the application protocol tag matches the format of existing S-NAPTR application protocol tag registry entries, but that does not mean it shares meaning with any other spec that makes registry entries in the same format 🌈
the S-NAPTR application service and application protocol tags defined here are unrelated to the IANA "Service Name and Transport Protocol Port Number Registry" (see [RFC6335]) ✨
the NAPTR service field can be at most 256 octets long, counting a one-octet length field (see Section 4.1 of [RFC3403] and Section 3.3 of [RFC1035]) 👑
3.1. IETF Standards Track Diameter Applications 🌸
a Diameter agent MUST be capable of using the extended S-NAPTR application service tag to dynamically discover a Diameter agent that supports Standards Track applications 😭 so every IETF Standards Track Diameter application MUST be associated with an "aaa-service" tag formatted the way this spec defines and allocated under IANA policy (see Section 7) 🫶
here's an example. a NAPTR service field value of:
'aaa+ap6:diameter.sctp'means the Diameter node in the SRV or A/AAAA record supports the Diameter Session Initiation Protocol (SIP) application (6) and uses the Stream Control Transmission Protocol (SCTP) as its 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 that case, the vendor-specific Diameter application MUST be associated with an "aaa-service" tag formatted the way this spec defines and allocated under IANA policy (see Section 7) 🔥
example time 🧚 a NAPTR service field value of:
'aaa+ap16777251:diameter.sctp'means the Diameter node in the SRV or A/AAAA record supports the Diameter Third Generation Partnership Project (3GPP) S6a application (16777251) and uses SCTP as its transport protocol 👑
4. Backwards Compatibility 💖
okay this part is about the glow-up for old peers 🥹 Domain Name System (DNS) administrators SHOULD also provision legacy NAPTR records [RFC3403] in the RFC 3588 style, so that legacy Diameter peers that are RFC 3588 compliant keep working ✨ and if the DNS admin provisions both the extended S-NAPTR records from this spec and the legacy RFC 3588 NAPTR records, then the extended S-NAPTR records MUST have higher priority (for example, lower order and/or preference values) than the legacy NAPTR records 🌈
5. Extended NAPTR-Based Diameter Peer Discovery ✨
okay so the Diameter peer discovery principles are all in Section 5.2 of [RFC3588] 💅. This spec gives the NAPTR query procedure a glow-up 🦋. Now the querying node can figure out which applications the resolved Diameter peers actually support 🔥.
The extended-format NAPTR records basically map a domain to the SRV record or A/AAAA record for reaching a server that supports a specific transport protocol and Diameter application 🧚. The record has an empty regular expression and a replacement value, which is the SRV record or the A/AAAA record for that particular transport protocol 💖.
The whole thing only works if the DNS administrator of the queried domain has already provisioned the DNS with extended-format NAPTR entries first 🫶. Here are the steps, which 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 💅. It has to know in advance which realm to look in for a Diameter agent, and which Application Identifier it's interested in 🎀. 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), then 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 moves on to the next peer discovery mechanism described in Section 5.2 of [RFC3588] 🧚.
5.1. Examples
okay so let's say a client wants to find a Diameter server in the ex1.example.com realm that supports the Credit Control application 💅. It does a NAPTR query for that domain, and gets back these NAPTR records:
;; 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.comThis tells us the server supports NASREQ (ID=1) and Credit Control (ID=4) applications over SCTP 🎀. If the client supports SCTP, it'll be used, targeted to a host found 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.comNow for the alternative example 🦋. A client wants to find a Diameter server in the ex2.example.com realm that supports the NASREQ application over SCTP. It does a NAPTR query for that domain, and gets back these:
;; 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.comSo this tells us the server supports NASREQ (ID=1) over SCTP and Transport Layer Security (TLS)/TCP, via server1.ex2.example.com and server2.ex2.example.com respectively 💖.
6. Usage Guidelines
okay real talk, Diameter is a peer-to-peer protocol 🤝, but most of the applications that extend the base protocol act like client/server applications 🙈. The role of the peer isn't advertised in the NAPTR tags, and it isn't even communicated during Diameter capability negotiation (the Capabilities-Exchange-Request and Capabilities-Exchange-Answer message exchange) 💀. So for an application that defines client/server roles, NAPTR-based Diameter peer discovery should only be used by a client to discover servers 🫶.
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 🧚.
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 💅
Okay so, Vendor-Specific Diameter Application IDs get handed out by IANA under the "First Come First Served" policy, which means no IETF spec needed 🎀 But the S-NAPTR application service tag registry from [RFC3958] is a little pickier. It uses "Specification Required," and the "specification" has to be an RFC (any category, so not too strict 🫶). So if a vendor-specific Diameter app wants the functionality from this document, an RFC of any category MUST be published that reserves the S-NAPTR Application Service Tag matching its Vendor-Specific Diameter Application ID, as defined in Section 3 ✨
7.5. Diameter Application Protocol Tags 🦋
IANA already reserved these S-NAPTR Application Protocol Tags for the Diameter transport protocols in the "S-NAPTR Application Protocol Tag" registry from [RFC3958]. Here's the lineup 👑
+------------------+----------+
| Tag | Protocol |
+------------------+----------+
| diameter.tcp | TCP |
| diameter.sctp | SCTP |
| diameter.tls.tcp | TLS/TCP |
+------------------+----------+Future Diameter versions that bring in new transport protocols MUST reserve an appropriate S-NAPTR Application Protocol Tag in that same "S-NAPTR Application Protocol Tag" registry created by [RFC3958] 🌈
8. Security Considerations 💀
Okay, serious moment, bestie 🙈 This document is an upgrade to the NAPTR service field format defined in RFC 3588, and it also tweaks the NAPTR processing logic from RFC 3588. The upgrade and tweaks are built on S-NAPTR, which is basically a simplified version of NAPTR, so the same security considerations described in RFC 3588 [RFC3588] still apply here. No extra extensions are needed beyond the security mechanisms RFC 3588 already offers 🔥
Here's the part you cannot skip: a malicious host doing S-NAPTR queries can learn which applications Diameter agents in a certain realm support, and it can learn that faster. That might help the bad actor scan for targets more efficiently, especially when some applications have known vulnerabilities. Be careful out there 🧚💜
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 🌸 Iconic reviewers, every single one ✨
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: mark@azu.ca
Jouni Korhonen
Nokia Siemens Networks
EMail: jouni.nospam@gmail.com
Lionel Morand
Orange Labs
EMail: lionel.morand@orange.com📦 where this page comes from
- ietf: rfc6408 2011-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms