メインコンテンツまでスキップ

1. はじめに

1. はじめに​

TACACS [RFC1492] や RADIUS [RFC2865] などの認証、認可、課金（AAA）プロトコルは、当初、ダイヤルアップ PPP [RFC1661] およびターミナルサーバーアクセスを提供するために展開されました。時間の経過とともに、多くの新しいアクセス技術で AAA サポートが必要となり、AAA ネットワークの規模と複雑さが増大し、AAA は新しいアプリケーション（VoIP など）でも使用されるようになりました。これにより、AAA プロトコルへの新しい要求が生じました。

AAA プロトコルのネットワークアクセス要件は、Aboba 他 [RFC2989] にまとめられています。これらには以下が含まれます：

フェイルオーバー

[RFC2865] はフェイルオーバーメカニズムを定義しておらず、その結果、フェイルオーバー動作は実装によって異なります。明確に定義されたフェイルオーバー動作を提供するために、Diameter はアプリケーション層の確認応答をサポートし、フェイルオーバーアルゴリズムと関連するステートマシンを定義しています。

トランスミッションレベルのセキュリティ

RADIUS [RFC2865] は、応答パケットでのみ使用が要求されるアプリケーション層の認証と完全性スキームを定義しています。[RFC2869] は追加の認証と完全性メカニズムを定義していますが、使用は拡張認証プロトコル（EAP）[RFC3748] セッション中にのみ要求されます。属性の隠蔽はサポートされていますが、[RFC2865] はパケット単位の機密性のサポートを提供していません。課金では、[RFC2866] はリプレイ保護がプロトコル自体ではなくバックエンド課金サーバーによって提供されることを前提としています。

[RFC3162] は RADIUS での IPsec の使用を定義していますが、IPsec のサポートは必須ではありません。トランスミッションレベルのセキュリティの普遍的なサポートを提供し、ドメイン内およびドメイン間の AAA 展開を可能にするために、Diameter は TLS/TCP および DTLS/SCTP のサポートを提供します。セキュリティについては、セクション 13 で説明します。

信頼性の高いトランスポート

RADIUS は UDP 上で実行され、再送信動作を定義していません。その結果、信頼性は実装によって異なります。[RFC2975] で説明されているように、これは課金における主要な問題であり、パケット損失が直接収益損失につながる可能性があります。明確に定義されたトランスポート動作を提供するために、Diameter は [RFC3539] で定義されているように、信頼性の高いトランスポートメカニズム（TCP、ストリーム制御伝送プロトコル（SCTP））上で実行されます。

エージェントサポート

RADIUS は、プロキシ、リダイレクト、リレーを含むエージェントの明示的なサポートを提供していません。期待される動作が定義されていないため、実装によって異なります。Diameter はエージェントの動作を明示的に定義しています。これについては、セクション 2.8 で説明します。

サーバー開始メッセージ

サーバー開始メッセージは RADIUS [RFC5176] で定義されていますが、サポートはオプションです。これにより、異種展開において、要求されていない切断や要求に応じた再認証/再認可などの機能を実装することが困難になります。この問題に対処するために、Diameter ではサーバー開始メッセージのサポートが必須です。

移行サポート

Diameter は RADIUS と共通のプロトコルデータユニット（PDU）を共有していませんが、両方のプロトコルを同じネットワークに展開できるように、RADIUS との下位互換性を実現するためにかなりの努力が払われています。当初は、Diameter が新しいネットワークデバイス内、およびレガシー RADIUS デバイスと Diameter エージェント間の通信を可能にするゲートウェイ内に展開されることが予想されます。この機能により、RADIUS と Diameter の両方を話すゲートウェイまたはサーバーを追加することで、レガシーネットワークに Diameter サポートを追加できます。

上記の要件に対処することに加えて、Diameter は以下のサポートも提供します：

能力ネゴシエーション

RADIUS は、エラーメッセージ、能力ネゴシエーション、または属性の必須/非必須フラグをサポートしていません。RADIUS クライアントとサーバーはお互いの能力を認識していないため、相互に受け入れ可能なサービスの交渉に成功できない場合や、場合によっては実装されたサービスが何であるかさえ認識できない場合があります。Diameter には、エラー処理（セクション 7）、能力ネゴシエーション（セクション 5.3）、および必須/非必須属性値ペア（AVP）（セクション 4.1）のサポートが含まれています。

ピア検出と設定

RADIUS 実装では通常、サーバーまたはクライアントの名前またはアドレスと、対応する共有秘密を手動で設定する必要があります。これにより、管理上の負担が大きくなり、RADIUS 共有秘密を再利用する誘惑が生じます。これは、[RFC2865] で要求されているように、リクエスト認証子がグローバルかつ時間的に一意でない場合、重大なセキュリティ脆弱性をもたらす可能性があります。DNS を通じて、Diameter はピアの動的検出を可能にします（セクション 5.2 を参照）。動的セッションキーの導出は、トランスミッションレベルのセキュリティを介して有効になります。

時間の経過とともに、ネットワークアクセスサーバー（NAS）デバイスの能力は大幅に向上しました。その結果、Diameter は RADIUS よりもかなり洗練されたプロトコルですが、組み込みデバイスに実装することは依然として実行可能です。

1.1. Diameter プロトコル​

Diameter 基本プロトコルは、以下の機能を提供します：

  • メッセージを交換し、AVP を配信する能力
  • 能力ネゴシエーション
  • エラー通知
  • [RFC2989] で要求されている、新しいアプリケーション、コマンド、AVP の追加による拡張性
  • ユーザーセッションの処理や課金などのアプリケーションに必要な基本サービス

プロトコルによって配信されるすべてのデータは、AVP の形式です。これらの AVP 値の一部は Diameter プロトコル自体によって使用され、他の値は Diameter を使用する特定のアプリケーションに関連するデータを配信します。AVP は Diameter メッセージに任意に追加できますが、唯一の制限は、コマンドコード形式（CCF）仕様（セクション 3.2）を満たす必要があることです。基本 Diameter プロトコルは、以下の必須機能をサポートするために AVP を使用します：

  • Diameter サーバーがユーザーを認証できるようにするための、ユーザー認証情報の転送
  • クライアントとサーバー間のサービス固有の認可情報の転送。ピアがユーザーのアクセス要求を許可すべきかどうかを決定できるようにする
  • 課金目的、容量計画などに使用される可能性のあるリソース使用情報の交換
  • サーバー階層を通じた Diameter メッセージのルーティング、リレー、プロキシ、およびリダイレクト

Diameter 基本プロトコルは、[RFC2989] で指定されている AAA プロトコルの最小要件を満たしています。基本プロトコルは、課金目的のみに単独で使用することも、モバイル IPv4 [RFC4004] やネットワークアクセス [RFC4005] などの Diameter アプリケーションと一緒に使用することもできます。また、基本プロトコルは、新しいコマンドや AVP の追加により、新しいアプリケーションで使用するために拡張することもできます。Diameter の最初の焦点は、ネットワークアクセスと課金アプリケーションでした。多くのアプリケーションで使用される真に汎用的な AAA プロトコルは、Diameter が提供していない機能を提供する可能性があります。したがって、新しいアプリケーションの設計者が Diameter を使用する前に要件を理解することが不可欠です。Diameter アプリケーションの詳細については、セクション 1.3.4 を参照してください。

任意のノードがリクエストを開始できます。その意味で、Diameter はピアツーピアプロトコルです。このドキュメントでは、Diameter クライアントは、ネットワークアクセスサーバー（NAS）やフォーリンエージェント（FA）など、ネットワークのエッジでアクセス制御を実行するデバイスです。Diameter クライアントは、ユーザーの認証、認可、課金サービスを要求するために Diameter メッセージを生成します。Diameter エージェントは、ローカルユーザー認証または認可サービスを提供しないノードです。エージェントには、プロキシ、リダイレクト、およびリレーエージェントが含まれます。Diameter サーバーは、ユーザーの認証および/または認可を実行します。Diameter ノードは、特定のリクエストのエージェントとして機能しながら、他のリクエストのサーバーとして機能することができます。

Diameter プロトコルは、特定のユーザーへのサービスを中止する要求など、サーバー開始メッセージもサポートしています。

1.1.1. ドキュメントセットの説明​

Diameter 仕様は、基本プロトコル仕様（このドキュメント）とトランスポートプロファイル [RFC3539] の更新版で構成されています。このドキュメントは、RFC 3588 と RFC 5719 の両方を廃止します。このドキュメントに含まれる基本プロトコルの更新の要約は、セクション 1.1.3 にあります。

このドキュメントは、課金のサポートを含む AAA の基本プロトコル仕様を定義しています。また、認証、認可、課金のためにこの基本仕様を使用するアプリケーションを説明する無数のアプリケーションドキュメントもあります。これらのアプリケーションドキュメントは、アプリケーションのコンテキスト内で Diameter プロトコルを使用する方法を指定しています。

トランスポートプロファイルドキュメント [RFC3539] は、AAA プロトコルで発生するトランスポート層の問題と、これらの問題を克服する方法に関する推奨事項について説明しています。このドキュメントは、Diameter フェイルオーバーアルゴリズムとステートマシンも定義しています。

「ユーザー名とレルムに基づく Diameter リクエストのルーティングに関する説明」[RFC5729] は、ユーザー名 AVP（属性値ペア）の内容に基づいてリクエストをルーティングする方法に関する特定の動作を定義しています。

1.1.2. このドキュメントで使用される規則​

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、[RFC2119] で説明されているように解釈されるものとします。

1.1.3. RFC 3588 からの変更​

このドキュメントは RFC 3588 を廃止しますが、そのドキュメントと完全に下位互換性があります。このドキュメントで導入された変更は、Diameter（RFC 3588）の実装中に表面化した問題の修正に焦点を当てています。主な変更点の概要を以下に示します。

  • トランスポート層セキュリティ（TLS）[RFC5246] のネゴシエーションのための Inband-Security AVP の使用を非推奨にしました。Inband-Security AVP を介した TLS のブートストラップは、CER/CEA（能力交換要求/能力交換応答）で運ばれる情報を完全に保護しないため、特定のセキュリティリスクを生じさせると一般的に考えられています。このバージョンの Diameter は、ピアが TLS/TCP および DTLS/SCTP を介して通信するときに使用する必要がある既知のセキュアポートを定義する一般的なアプローチを採用しています。この新しいアプローチは、既存の帯域内セキュリティネゴシエーションを強化しますが、完全に置き換えるものではありません。古い方法は、下位互換性の理由で保持されています。

  • オープン状態での CER/CEA メッセージの交換を非推奨にしました。この機能は RFC 3588 のピアステートマシンテーブルで暗示されていましたが、そのドキュメントの他の場所では明確に定義されていませんでした。このドキュメントの作業が進むにつれて、CER/CEA メッセージ（およびメッセージ自体）における Application-Id AVP の意味と使用の多重性が Diameter 拡張性ルールの乱用と見なされ、したがって簡素化が必要であることが明らかになりました。オープン状態での能力交換は、この機能の新しいコマンドを明確に定義する別の仕様 [RFC6737] で再導入されました。

  • セキュリティ要件を簡素化しました。Diameter メッセージの交換にセキュアなトランスポートを使用することは引き続き必須です。ただし、TLS/TCP および DTLS/SCTP が Diameter を保護する主要な方法となり、IPsec は二次的な代替手段となりました。詳細については、セクション 13 を参照してください。エンドツーエンドセキュリティフレームワーク（E2E-Sequence AVP および AVP ヘッダーの 'P' ビット）のサポートも非推奨になりました。

  • Diameter の拡張性を変更しました。これには、Diameter アプリケーション設計者をより良く支援するための Diameter 拡張性の説明（セクション 1.3 など）の修正が含まれます。さらに、新しい仕様は、ベンダー固有の使用のためのコマンドコードの割り当てに関するポリシーを緩和しています。

  • アプリケーション ID の使用を明確化しました。Diameter メッセージ内の複数の場所にあるアプリケーション ID 情報の適切な使用を明確にします。これには、メッセージヘッダーと AVP で見つかったアプリケーション ID の相関が含まれます。これらの変更は、特定の基本プロトコルメッセージ（ASR/ASA、STR/STA）に使用する適切なアプリケーション ID 値も明確に指定し、Vendor-Specific-Application-Id の内容と使用を明確にします。

  • ルーティングの修正を明確化しました。このドキュメントは、一般的なルーティング決定を行うために使用できる情報（AVP とアプリケーション ID）をより明確に指定しています。リダイレクトを介して複数のルートエントリが見つかった場合のリダイレクトルーティング基準の優先順位付けのルールも追加されました（セクション 6.13 を参照）。

  • Diameter ピア検出を簡素化しました。Diameter 検出プロセスは、広く使用されている検出スキームのみをサポートするようになりました。残りは非推奨になりました（詳細については、セクション 5.2 を参照）。

このドキュメントには、他にも多くのさまざまな修正が導入されており、重要とは見なされないかもしれませんが、それでも価値があります。例としては、廃止されたタイプの削除、ステートマシンの修正、選挙プロセスの明確化、メッセージ検証、Failed-AVP および Result-Code AVP 値の修正などがあります。このドキュメントの公開前に RFC 3588 に対して提出されたすべての正誤表は対処されています。実用的な理由から、変更の包括的なリストはここには示されていません。

1.2. 用語​

AAA

認証、認可、課金。

ABNF

拡張バッカス・ナウア記法 [RFC5234]。独自の正式な構文とルールを持つメタ言語。バッカス・ナウア記法に基づいており、双方向通信プロトコルでのメッセージ交換を定義するために使用されます。

課金（Accounting）

容量計画、監査、請求、またはコスト配分の目的でリソース使用に関する情報を収集する行為。

課金レコード（Accounting Record）

課金レコードは、セッション全体にわたるユーザーのリソース消費の要約を表します。課金レコードを作成する課金サーバーは、中間課金イベントまたは同じユーザーにサービスを提供する複数のデバイスからの課金イベントを処理することによってこれを行う場合があります。

認証（Authentication）

エンティティ（サブジェクト）の ID を検証する行為。

認可（Authorization）

要求エンティティ（サブジェクト）がリソース（オブジェクト）へのアクセスを許可されるかどうかを決定する行為。

属性値ペア（Attribute-Value Pair, AVP）

Diameter プロトコルは、ヘッダーとそれに続く 1 つ以上の属性値ペア（AVP）で構成されます。AVP にはヘッダーが含まれ、プロトコル固有のデータ（ルーティング情報など）や認証、認可、課金情報をカプセル化するために使用されます。

コマンドコード形式（Command Code Format, CCF）

Diameter コマンドを定義するために使用される ABNF の変更形式（セクション 3.2 を参照）。

Diameter エージェント（Diameter Agent）

Diameter エージェントは、リレー、プロキシ、リダイレクト、または変換サービスを提供する Diameter ノードです。

Diameter クライアント（Diameter Client）

Diameter クライアントは、Diameter クライアントアプリケーションと基本プロトコルをサポートする Diameter ノードです。Diameter クライアントは、多くの場合、ネットワークのエッジに位置するデバイスに実装され、そのネットワークにアクセス制御サービスを提供します。Diameter クライアントの典型的な例には、ネットワークアクセスサーバー（NAS）とモバイル IP フォーリンエージェント（FA）が含まれます。

Diameter ノード（Diameter Node）

Diameter ノードは、Diameter プロトコルを実装し、クライアント、エージェント、またはサーバーとして機能するホストプロセスです。

Diameter ピア（Diameter Peer）

直接 TCP または SCTP トランスポート接続を共有する 2 つの Diameter ノードは、Diameter ピアと呼ばれます。

Diameter サーバー（Diameter Server）

Diameter サーバーは、特定のレルムの認証、認可、課金リクエストを処理する Diameter ノードです。その性質上、Diameter サーバーは、基本プロトコルに加えて Diameter サーバーアプリケーションをサポートする必要があります。

ダウンストリーム（Downstream）

ダウンストリームは、ホームサーバーから Diameter クライアントへの特定の Diameter メッセージの方向を識別するために使用されます。

ホームレルム（Home Realm）

ホームレルムは、ユーザーがアカウント関係を維持している管理ドメインです。

ホームサーバー（Home Server）

ホームレルムにサービスを提供する Diameter サーバー。

中間課金（Interim Accounting）

中間課金メッセージは、ユーザーのセッション中の使用状況のスナップショットを提供します。通常、デバイスの再起動またはその他のネットワーク問題がセッション要約メッセージまたはセッションレコードの配信を妨げる場合に、ユーザーのセッションの部分的な課金を提供するために実装されます。

ローカルレルム（Local Realm）

ローカルレルムは、ユーザーにサービスを提供する管理ドメインです。管理ドメインは、特定のユーザーのローカルレルムとして機能する一方で、他のユーザーのホームレルムになることがあります。

マルチセッション（Multi-session）

マルチセッションは、複数のセッションの論理的なリンクを表します。マルチセッションは、Acct-Multi-Session-Id を使用して追跡されます。マルチセッションの例は、マルチリンク PPP バンドルです。バンドルの各レッグはセッションであり、バンドル全体はマルチセッションになります。

ネットワークアクセス識別子（Network Access Identifier）

ネットワークアクセス識別子、または NAI [RFC4282] は、Diameter プロトコルでユーザーの ID とレルムを抽出するために使用されます。ID は、認証および/または認可中にユーザーを識別するために使用され、レルムはメッセージルーティング目的に使用されます。

プロキシエージェントまたはプロキシ（Proxy Agent or Proxy）

リクエストとレスポンスの転送に加えて、プロキシはリソースの使用とプロビジョニングに関連するポリシー決定を行います。通常、これは NAS デバイスの状態を追跡することによって達成されます。プロキシは通常、サーバーからレスポンスを受信する前にクライアントリクエストに応答しませんが、ポリシー違反の場合に拒否メッセージを発信する場合があります。その結果、プロキシは、それらを通過するメッセージのセマンティクスを理解する必要があり、すべての Diameter アプリケーションをサポートしない場合があります。

レルム（Realm）

NAI の '@' 文字の直後に続く文字列。NAI レルム名は一意である必要があり、DNS 名前空間の管理にピギーバックされています。Diameter はレルム（ドメインとも緩く呼ばれる）を使用して、メッセージをローカルで満たすことができるか、ルーティングまたはリダイレクトする必要があるかを判断します。RADIUS では、レルム名は必ずしも DNS 名前空間にピギーバックされておらず、それとは独立している場合があります。

リアルタイム課金（Real-Time Accounting）

リアルタイム課金には、定義された時間枠内でのリソース使用に関する情報の処理が含まれます。通常、財務リスクを制限するために時間制約が課せられます。Diameter クレジット制御アプリケーション [RFC4006] は、リアルタイム課金機能を定義するアプリケーションの例です。

リレーエージェントまたはリレー（Relay Agent or Relay）

リレーは、ルーティング関連の AVP とルーティングテーブルエントリに基づいてリクエストとレスポンスを転送します。リレーはポリシー決定を行わないため、非ルーティング AVP を検査または変更しません。その結果、リレーはメッセージを発信せず、メッセージまたは非ルーティング AVP のセマンティクスを理解する必要がなく、任意の Diameter アプリケーションまたはメッセージタイプを処理できます。リレーはルーティング AVP とレルム転送テーブルの情報に基づいて決定を下すため、NAS リソースの使用または進行中のセッションに関する状態を保持しません。

リダイレクトエージェント（Redirect Agent）

リダイレクトエージェントは、クライアントとサーバー間でリクエストとレスポンスを転送する代わりに、クライアントをサーバーに参照し、それらが直接通信できるようにします。リダイレクトエージェントは転送パスに存在しないため、クライアントとサーバー間を通過する AVP を変更しません。リダイレクトエージェントはメッセージを発信せず、任意のメッセージタイプを処理できますが、特定のタイプのメッセージのみをリダイレクトするように構成され、他のタイプのリレーまたはプロキシエージェントとして機能する場合があります。リレーエージェントと同様に、リダイレクトエージェントはセッションまたは NAS リソースに関する状態を保持しません。

セッション（Session）

セッションは、特定のアクティビティに専念する関連イベントの進行です。Diameter アプリケーションドキュメントは、セッションがいつ開始および終了するかに関するガイドラインを提供します。同じ Session-Id を持つすべての Diameter パケットは、同じセッションの一部と見なされます。

ステートフルエージェント（Stateful Agent）

ステートフルエージェントは、すべての認可されたアクティブセッションを追跡することにより、セッション状態情報を維持するエージェントです。各認可されたセッションは特定のサービスにバインドされ、その状態は、別の通知があるまで、または有効期限が切れるまでアクティブと見なされます。

サブセッション（Sub-session）

サブセッションは、特定のセッションに提供される異なるサービス（QoS やデータ特性など）を表します。これらのサービスは、同時に（同じセッション中の同時音声とデータ転送など）または連続的に発生する場合があります。セッションのこれらの変化は、Accounting-Sub-Session-Id で追跡されます。

トランザクション状態（Transaction State）

Diameter プロトコルでは、エージェントがフェイルオーバー目的で使用されるトランザクション状態を維持する必要があります。トランザクション状態は、リクエストを転送する際に、Hop-by-Hop Identifier が保存されることを意味します。このフィールドは、ローカルに一意の識別子に置き換えられ、対応する応答を受信すると元の値に復元されます。リクエストの状態は、応答の受信時に解放されます。ステートレスエージェントは、トランザクション状態のみを維持するエージェントです。

変換エージェント（Translation Agent）

変換エージェント（図 4 の TLA）は、Diameter と別の AAA プロトコル（RADIUS など）の間でプロトコル変換を実行するステートフル Diameter ノードです。

アップストリーム（Upstream）

アップストリームは、Diameter クライアントからホームサーバーへの特定の Diameter メッセージの方向を識別するために使用されます。

ユーザー（User）

Diameter クライアントがリクエストを生成した、何らかのリソースを要求または使用するエンティティまたはデバイス。

1.3. 拡張性へのアプローチ​

Diameter プロトコルは、以下を含むいくつかのメカニズムを使用して拡張可能に設計されています：

  • 新しい AVP 値の定義
  • 新しい AVP の作成
  • 新しいコマンドの作成
  • 新しいアプリケーションの作成

拡張性の観点から、Diameter の認証、認可、課金アプリケーションは同じ方法で扱われます。

注：プロトコル設計者は、既存の機能、つまり AVP 値、AVP、コマンド、Diameter アプリケーションを再利用しようとする必要があります。再利用により、標準化と実装が簡素化されます。潜在的な相互運用性の問題を回避するには、再利用される機能のセマンティクスが十分に理解されていることを確認することが重要です。Diameter は RADIUS 属性を Diameter AVP として運ぶこともできるため、このような再利用の考慮事項は、Diameter アプリケーションで有用である可能性のある既存の RADIUS 属性にも適用されます。

1.3.1. 新しい AVP 値の定義​

Diameter 基本プロトコルで定義された AVP の新しい AVP 値を割り当てるには、IETF が AVP 値を説明する新しい RFC を承認する必要があります。これらの AVP 値の IANA 考慮事項は、セクション 11.3 で説明されています。

他の AVP の AVP 値の割り当ては、それらの AVP を定義するドキュメントの IANA 考慮事項によって導かれます。通常、RFC で定義された AVP の新しい値の割り当てには IETF レビュー [RFC5226] が必要ですが、ベンダー固有の AVP の値はベンダーが割り当てることができます。

1.3.2. 新しい AVP の作成​

定義されている新しい AVP は、セクション 4.2 または 4.3 にリストされているデータ型のいずれかを使用する必要があります。適切な派生データ型がすでに定義されている場合は、再利用性と優れた設計実践を奨励するために、基本データ型の代わりにそれを使用する必要があります。

AVP の論理的なグループ化が必要であり、特定のコマンドで複数の「グループ」が可能な場合は、グループ化された AVP を使用することをお勧めします（セクション 4.4 を参照）。

新しい AVP の作成は、さまざまな方法で行うことができます。推奨されるアプローチは、IETF が承認した標準トラック RFC で新しい汎用 AVP を定義することです。ただし、セクション 11.1.1 で説明されているように、他のメカニズムもあります。

1.3.3. 新しいコマンドの作成​

必要な AVP（CCF 定義で {AVP} として示されているもの）が既存のコマンドに追加、削除、または再定義される場合（たとえば、必須 AVP をオプションのものに変更することによって）、新しいコマンドコードを割り当てる必要があります。

さらに、コマンドのトランスポート特性が変更される場合（たとえば、必要なラウンドトリップ数に関して）、新しいコマンドコードを登録する必要があります。

上記のようなコマンドの CCF への変更は、新しいコマンドコードの定義をもたらす必要があります。これにより、その新しいコマンドを使用するアプリケーションの新しい Diameter アプリケーションを定義する必要が生じます。

コマンドコードの IANA 考慮事項は、セクション 3.1 で説明されています。

1.3.4. 新しい Diameter アプリケーションの作成​

Diameter アプリケーションは、新しいコマンドコード、AVP、および関連するセマンティクスを定義できます。新しい Diameter アプリケーションの作成には、通常、IETF が承認した標準トラック RFC が必要です。詳細については、セクション 11.2.1 を参照してください。

に最終更新