Movatterモバイル変換

Internet Engineering Task Force (IETF)                      D. RomascanuRequest for Comments: 5719                                         AvayaUpdates:3588                                              H. TschofenigCategory: Standards Track                         Nokia Siemens NetworksISSN: 2070-1721                                             January 2010Updated IANA Considerations for Diameter Command Code AllocationsAbstract   The Diameter base specification, described inRFC 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 perRFC 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 inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc5719.Romascanu & Tschofenig      Standards Track                     [Page 1]

RFC 5719        Diameter Command Code Allocation Policy     January 2010Copyright Notice   Copyright (c) 2010 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .22.  Conventions Used in This Document . . . . . . . . . . . . . . .33.  Security Considerations . . . . . . . . . . . . . . . . . . . .34.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .35.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .46.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .46.1.  Normative References  . . . . . . . . . . . . . . . . . . .46.2.  Informative References  . . . . . . . . . . . . . . . . . .51.  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 perRFC 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 ofRFC 3588 is currently in development in the IETF DIME   WG [RFC3588bis]; when approved, it will obsoleteRFC 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 toRFC 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 inRFC 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 backwardRomascanu & 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; seeSection 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.  References6.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.atRomascanu & Tschofenig      Standards Track                     [Page 5]