ietf-corpus

rfc-5719

Updated IANA Considerations for Diameter Command Code Allocations

D. Romascanu, H. Tschofenig
date2010-01 streamIETF areaops wgdime statusPROPOSED STANDARD pages5 canonicalhttps://www.rfc-editor.org/rfc/rfc5719 doi10.17487/RFC5719
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. [STANDARDS-TRACK]

obsoleted by

updates

Extracted elements (8)

design-rationale §1

The command code space was split into ranges with different allocation policies to align the extensibility rules for Diameter commands with those for Diameter application identifiers, allowing other SDOs to define new commands without requiring IETF consensus while still avoiding overloading of existing commands.

diameter

design-rationale §1

The prior RFC 3588 requirement for IETF consensus to define new Diameter commands caused other SDOs to define new applications on existing commands rather than requesting new command codes, leading to poor design choices and interoperability problems; this document corrects that incentive structure.

diameter

interoperability-note §4

Command codes 16,777,214 and 16,777,215 (0xfffffe–0xffffff) are reserved for experimental and testing purposes only; no guarantee of interoperability between Diameter peers using experimental commands is made, per RFC 3692.

diameter

normative-requirement §4 SHOULD

A 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 interoperability between independent implementations.

diameter, registry

normative-requirement §4 MUST

If the specification for a vendor-specific command code 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.

diameter, registry

protocol-element §4

Diameter command codes 257, 258, 271, 274, 275, 280, and 282 are defined by RFC 3588 within the standard range (256–8,388,607) and assigned in Section 3.1 of that specification.

diameter

registry §4

The Diameter Command Code namespace is split into four ranges: 0–255 reserved for RADIUS backward compatibility, 256–8,388,607 for permanent standard commands requiring IETF Review, 8,388,608–16,777,213 for vendor-specific codes allocated First Come First Served, and 16,777,214–16,777,215 reserved for experimental commands.

diameter, registry

security-consideration §3

Delegating Diameter command code work to organizations outside the IETF means security reviews may be conducted differently; other organizations become responsible for the quality of the specifications they produce, and the DIME WG is aware of these risks.

diameter, security