diff options
Diffstat (limited to 'doc/rfc/rfc5719.txt')
| -rw-r--r-- | doc/rfc/rfc5719.txt | 283 |
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc5719.txt b/doc/rfc/rfc5719.txt new file mode 100644 index 0000000..7a0cc86 --- /dev/null +++ b/doc/rfc/rfc5719.txt @@ -0,0 +1,283 @@ + + + + + + +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. + + + + + + +Romascanu & Tschofenig Standards Track [Page 1] + +RFC 5719 Diameter Command Code Allocation Policy January 2010 + + +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. + + + +Romascanu & Tschofenig Standards Track [Page 2] + +RFC 5719 Diameter Command Code Allocation Policy January 2010 + + + 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 + + + +Romascanu & Tschofenig Standards Track [Page 3] + +RFC 5719 Diameter Command Code Allocation Policy January 2010 + + + 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. + + + +Romascanu & Tschofenig Standards Track [Page 4] + +RFC 5719 Diameter Command Code Allocation Policy January 2010 + + + [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 + + + + + + + + + + + + + + + + + + +Romascanu & Tschofenig Standards Track [Page 5] + |