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/RFC 5719.






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 [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
   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 [RFC 5226].

   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 [RFC 2119].

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 [RFC 5226].
   [RFC 3588] defines the command codes 257, 258, 271, 274, 275, 280, and
   282; see Section 3.1 in [RFC 3588] 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 [RFC 5226].  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 [RFC 3692].

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

   [RFC 2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC 3588]     Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
                 J. Arkko, "Diameter Base Protocol", RFC 3588,
                 September 2003.

   [RFC 3692]     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


   [RFC 5226]     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 



Updated IANA Considerations for Diameter Command Code Allocations

RFC TOTAL SIZE: 11268 bytes
PUBLICATION DATE: Thursday, January 7th, 2010
LEGAL RIGHTS: The IETF Trust (see BCP 78)