RFC 5719 PROPOSED STANDARD IANA · DIAMETER · REGISTRY
Updated IANA Considerations for Diameter Command Code Allocations
Changing how IANA hands out Diameter protocol command codes.
RFC EDITOR
Romascanu, D. and H. Tschofenig, "Updated IANA Considerations for Diameter Command Code Allocations", RFC 5719, DOI 10.17487/RFC5719, January 2010, <https://www.rfc-editor.org/info/rfc5719>.
BIBTEX
@misc{rfc5719,
series = {Request for Comments},
number = 5719,
howpublished = {RFC 5719},
publisher = {RFC Editor},
doi = {10.17487/RFC5719},
url = {https://www.rfc-editor.org/info/rfc5719},
author = {D. Romascanu and H. Tschofenig},
title = {{Updated IANA Considerations for Diameter Command Code Allocations}},
pagetotal = 5,
year = 2010,
month = jan,
} RFC text
Contents
Internet Engineering Task Force (IETF) D. Romascanu Request for Comments: 5719 Avaya Updates: 3588 H. Tschofenig Category: Standards Track Nokia Siemens Networks ISSN: 2070-1721 January 2010 Updated IANA Considerations for Diameter Command Code Allocations Abstract The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. 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/rfc5719. Copyright Notice Copyright (c) 2010 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. Conventions Used in This Document . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 1. Introduction The Diameter Base specification, described in [RFC3588], provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. [RFC3588] illustrates the conditions that require the definition of a new Diameter application or a new command. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations (SDOs), which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of poor the design caused by overloading existing commands. This document aligns the extensibility rules for Diameter command codes with those defined for Diameter application identifiers and offers a consistent way to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. This is achieved by splitting the command code space into ranges and providing different allocation policies to them: the first range is reserved for RADIUS backward compatibility, allocation of a command code in the second number range requires IETF review, the third range is utilized by vendor-specific command codes, and finally the last range is for experimental commands. Section 4 provides more details about the command code number ranges, and the different allocation policies are described in [RFC5226]. A revision of RFC 3588 is currently in development in the IETF DIME WG [RFC3588bis]; when approved, it will obsolete RFC 3588 as well as this document. A goal of this document is to provide in advance the change in the command codes allocation policy, so that interoperability problems like the ones described above are avoided as soon as possible. 2. Conventions Used in This Document 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. Security Considerations This document modifies the IANA allocation of Diameter command codes in relationship to RFC 3588. This process change itself does not raise security concerns, but the command code space is split into a standard command code space and a vendor-specific command code space, the latter being allocated on a First Come, First Served basis by IANA at the request of vendors or other standards organizations. Whenever work gets delegated to organizations outside the IETF, there is always the chance that security reviews will be conducted in different manner and that the criteria and style of those reviews will be different than the reviews performed in the IETF. The members of the DIME working group are aware of the risks involved in using different security and quality review processes and of the desire to offload work (e.g., to reduce the workload in the IETF) to other organizations. Other organizations are therefore made responsible for the quality of the specifications they produce. 4. IANA Considerations This section describes changes to the IANA Considerations sections outlined in RFC 3588 regarding the allocation of command codes by IANA. The command code namespace is used to identify Diameter commands. The values 0 - 255 (0x00 - 0xff) are reserved for RADIUS backward compatibility and are defined as "RADIUS Packet Type Codes" in [RADTYPE]. Values 256 - 8,388,607 (0x100 - 0x7fffff) are for permanent, standard commands allocated by IETF Review [RFC5226]. [RFC3588] defines the command codes 257, 258, 271, 274, 275, 280, and 282; see Section 3.1 in [RFC3588] for the assignment of the namespace in that specification. The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved for vendor-specific command codes, to be allocated on a First Come, First Served basis by IANA [RFC5226]. The request to IANA for a vendor-specific command code SHOULD include a reference to a publicly available specification that documents the command in sufficient detail to aid in interoperability between independent implementations. If the specification cannot be made publicly available, the request for a vendor-specific command code MUST include the contact information of persons and/or entities responsible for authoring and maintaining the command. The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - 0xffffff) are reserved for experimental commands. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between Diameter peers using experimental commands, as outlined in [RFC3692]. 5. Acknowledgements The content of this document is the result of the work in the IETF Diameter Maintenance and Extensions (DIME) working group. We would therefore like to thank all the working group members who were involved in that discussion. While it appears to be a fairly small change in the allocation policy, the effect on implementations is rather dramatic. We would like to thank Mark Jones for his review comments. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 6.2. Informative References [RADTYPE] IANA, "Radius Types", <http://www.iana.org>. [RFC3588bis] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", Work in Progress, September 2009. Authors' Addresses Dan Romascanu Avaya Industrial Park Atidim, Bldg#3 Tel Aviv 61581 Israel Phone: +972-3-645-8414 EMail: dromasca@avaya.com Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
AI ELI5
On this page
PROBLEMDiameter command codes required IETF consensus for assignment, which caused other standards organizations to work around the rule by overloading existing commands instead of requesting new codes.
MECHANISMRFC 5719 splits the command code space into ranges with different allocation policies: RADIUS compatibility, IETF review, vendor-specific, and experimental.
WHY IT CHANGEDStandards organizations outside the IETF can now allocate vendor-specific command codes without going through IETF consensus, removing the incentive to reuse existing codes. This RFC was replaced by RFC 6733.
§1The Problem with Command Codes
Diameter is a base protocol that can be extended with new applications and commands. RFC 3588 required IETF consensus to define new Diameter command codes. This led standards organizations outside the IETF to define new applications on existing commands instead, avoiding the IETF consensus step.
Reusing commands for different purposes caused interoperability problems and poor design. RFC 5719 solves this by creating allocation policies that let standards organizations request new command codes without full IETF consensus.
Groups wanted new command numbers but had to ask the whole IETF. So they reused old numbers instead and broke things. New rules let them ask a different way.
§2Command Code Ranges and Policies
The command code namespace is split into four ranges. Codes 0-255 are reserved for RADIUS backward compatibility. Codes 256 to 8,388,607 are for permanent standard commands, allocated by IETF Review. Codes 8,388,608 to 16,777,213 are for vendor-specific commands, allocated on a First Come, First Served basis. Codes 16,777,214 and 16,777,215 are reserved for experimental commands.
The vendor-specific range lets standards organizations and vendors request code allocation with public documentation, removing the need for IETF consensus on each vendor extension.
The codes are split into chunks: some for old systems, some for official standards, some for vendors, and some for experiments.
§3IANA Assignment Rules
IANA assigns codes within each range according to the policy for that range. Vendors requesting a code in the vendor-specific range should provide a publicly available specification explaining the command. If public specification is not possible, they must provide contact information for persons responsible for the code.
The change lets the DIME working group delegate Diameter extension work to other standards organizations while maintaining interoperability and proper documentation.
IANA hands out the codes. Vendors can get them faster if they write down what their code does.
§4References
[1]RFC 3588Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.September 2003[2]RFC 5226Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.May 2008[3]RFC 3692Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.January 2004