RFC 5719

RFC 5719: Updated IANA Considerations for Diameter Command Code Allocations 🦋

okay bestie, this one is Standards Track and it's from January 2010 💅 It's written by Dan Romascanu (Avaya) and Hannes Tschofenig (Nokia Siemens Networks), and it's published under ISSN 2070-1721. It updates RFC 3588 (the Diameter Base Protocol spec) and doesn't obsolete anything. The intro also says the upcoming RFC 3588 revision will obsolete both RFC 3588 and this doc once it's approved 👑

Abstract

okay so the Diameter base spec (RFC 3588) gives you a few ways to extend Diameter: new commands (the messages Diameter apps use) and whole new applications, which are the biggest glow-ups 🌸 RFC 3588 explains when you need a new application or a new command. Depending on how big the extension is, IETF action may be needed. Making a new application doesn't need IETF consensus, but making a new command does, per RFC 3588. 🙈

This led to some sketchy design choices from other Standards Development Organizations (SDOs). They defined new applications on top of existing commands, instead of asking for new command codes, just so they could dodge bringing their specs to the IETF. Sometimes that caused interoperability problems because overloading existing commands was a bad idea 💀

This document lines up the extensibility rules of the Diameter application with the Diameter commands. It also gives other SDOs a way to take on Diameter work and extend it without making poor design choices ✨

Status of This Memo

this is an Internet Standards Track document 🎀

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.

for the current status, any errata, and how to send feedback, check out:

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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they were on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 📜

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 ✨

so the Diameter Base spec ([RFC3588]) gives you a bunch of ways to extend Diameter, with new commands (messages used by Diameter apps) and whole new applications as the biggest moves 💖 [RFC3588] explains when you need a new application or a new command. Depending on the scope, IETF action might be required. Defining new applications doesn't need IETF consensus, but defining new commands does, per RFC 3588. 😭

this has caused some questionable design choices from other Standards Development Organizations (SDOs). They chose to define new applications on existing commands, instead of asking for new command codes, purely so they could avoid bringing their specs to the IETF. In some cases, interoperability problems showed up because overloading existing commands led to poor design 💀

this document lines up the extensibility rules for Diameter command codes with the ones already defined for Diameter application identifiers. It also gives a consistent way to hand Diameter work off to other SDOs so they can extend Diameter without making poor design choices 🫶

here's the plan. The command code space gets split into ranges, and each range has its own allocation policy. The first range is reserved for RADIUS backward compatibility. Allocating a command code in the second number range requires IETF review. The third range is for vendor-specific command codes, and the last range is for experimental commands. Section 4 has the details on the number ranges, and the allocation policies are described in [RFC5226] 🌈

a revision of RFC 3588 is in progress in the IETF DIME WG ([RFC3588bis]). Once it's approved, it'll obsolete RFC 3588 and this document. The goal here is to change the command code allocation policy ahead of time, so interoperability problems like the ones above get 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 🔥

okay this section is important, so listen up 👀

this document changes how Diameter command codes get allocated by IANA, compared to RFC 3588. The process change by itself doesn't raise security concerns. BUT the command code space is split into a standard command code space and a vendor-specific one. The vendor-specific space is allocated on a First Come, First Served basis by IANA, at the request of vendors or other standards organizations.

every time work gets handed to organizations outside the IETF, there's always a chance the security reviews will happen differently, and the criteria and style of those reviews might not match what the IETF does. The DIME working group knows about the risks of using different security and quality review processes, and they also know people want to offload work (for example, to ease the IETF's workload) to other organizations. So those other organizations are made responsible for the quality of the specs they produce. ⚠️

4. IANA Considerations 💅

this section describes the changes to the IANA Considerations sections in RFC 3588, which cover how IANA allocates command codes.

the command code namespace identifies Diameter commands. The values 0 - 255 (0x00 - 0xff) are reserved for RADIUS backward compatibility, and they're defined as "RADIUS Packet Type Codes" in [RADTYPE]. The 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 how the namespace is assigned in that spec. ✨

the values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved for vendor-specific command codes, 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 enough detail to help independent implementations interoperate. If that spec can't be made publicly available, the request for a vendor-specific command code MUST include the contact information of the people 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. Since these codes are only for experiments and testing, there's no guarantee of interoperability between Diameter peers using experimental commands, as outlined in [RFC3692]. 🧪

5. Acknowledgements 🫶

this doc is the result of work in the IETF Diameter Maintenance and Extensions (DIME) working group, so we want to thank all the WG members who took part in those discussions 💜 The authors say that while this looks like a pretty small change to the allocation policy, the effect on implementations is honestly pretty dramatic 😭

they also 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

---

that's the whole RFC, bestie 🌈💖 go slay your Diameter implementation 💅✨