[要約] RFC 6408は、DiameterプロトコルでのStraightforward-Naming Authority Pointer (S-NAPTR)の使用方法について説明しています。このRFCの目的は、DiameterネットワークでのS-NAPTRの適切な使用方法を定義し、ネットワークの効率と信頼性を向上させることです。
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 6408 Bridgewater Systems
Updates: 3588 J. Korhonen
Category: Standards Track Nokia Siemens Networks
ISSN: 2070-1721 L. Morand
Orange Labs
November 2011
Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage
直径ストレートネーミングオーソリティポインター（S-NAPTR）の使用
Abstract
概要
The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates RFC 3588, "Diameter Base Protocol", and describes an improvement using an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) application service tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand.
直径ベースプロトコルは、特定の領域が直径ノードとサポートされている輸送プロトコルを宣伝できるメカニズムを指定します。ただし、これらのメカニズムは、各ノードがサポートする直径アプリケーションを明らかにしていません。領域外のピアは、必要なアプリケーションをサポートするものを発見するまで、すべてのノードで直径機能交換を実行する必要があります。このドキュメントは、RFC 3588、「直径ベースプロトコル」を更新し、直径の能力交換を事前に実行せずにサポートされているアプリケーションの発見を可能にする、単純な名前の権限ポインター（S-NAPTR）アプリケーションサービスタグの拡張形式を使用した改善について説明します。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
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/rfc6408.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6408で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................3
3. Extended NAPTR Service Field Format .............................3
3.1. IETF Standards Track Diameter Applications .................5
3.2. Vendor-Specific Diameter Applications ......................5
4. Backwards Compatibility .........................................5
5. Extended NAPTR-Based Diameter Peer Discovery ....................6
5.1. Examples ...................................................7
6. Usage Guidelines ................................................8
7. IANA Considerations .............................................9
7.1. IETF Diameter Application Service Tags .....................9
7.2. 3GPP Diameter Application Service Tags .....................9
7.3. WiMAX Forum Diameter Application Service Tags .............10
7.4. Vendor-Specific Diameter Application Service Tags .........10
7.5. Diameter Application Protocol Tags ........................11
8. Security Considerations ........................................11
9. Acknowledgments ................................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................14
The Diameter base protocol [RFC3588] specifies three mechanisms for Diameter peer discovery. One of these involves the Diameter implementation performing a Naming Authority Pointer (NAPTR) query [RFC3403] for a server in a particular realm. These NAPTR records
直径ベースプロトコル[RFC3588]は、直径ピアディスカバリーの3つのメカニズムを指定します。これらの1つには、特定の領域のサーバーの命名権限ポインター（NAPTR）クエリ[RFC3403]を実行する直径の実装が含まれます。これらのNAPTRレコード
provide a mapping from a domain to the DNS Service Locator (SRV) record [RFC2782] or A/AAAA record [RFC1035] [RFC3596] for contacting a server with the specific transport protocol in the NAPTR services field.
ドメインからDNSサービスロケーター（SRV）レコード[RFC2782]またはA/AAAAレコード[RFC1035] [RFC3596]へのマッピングを提供して、NAPTRサービスフィールドの特定のトランスポートプロトコルと接触します。
The extended NAPTR usage for Diameter peer discovery defined by this document is based on the Straightforward-NAPTR (S-NAPTR) Dynamic Delegation Discovery System (DDDS) application defined in [RFC3958]. This document updates the Diameter peer discovery procedure described in Section 5.2 of [RFC3588] and defines S-NAPTR application service and application protocol tag values that permit the discovery of Diameter peers that support a specific Diameter application and transport protocol.
このドキュメントで定義された直径ピアディスカバリーの拡張NAPTR使用は、[RFC3958]で定義されたStarnforward-NAPTR（S-NAPTR）動的委任ディスカバリーシステム（DDDS）アプリケーションに基づいています。このドキュメントは、[RFC3588]のセクション5.2で説明されている直径ピアディスカバリー手順を更新し、特定の直径アプリケーションと輸送プロトコルをサポートする直径ピアの発見を可能にするS-NAPTRアプリケーションサービスおよびアプリケーションプロトコルタグ値を定義します。
The Diameter base protocol specification (Section 1.3 of [RFC3588]) and the Straightforward-NAPTR (S-NAPTR) DDDS application (Section 2.1 of [RFC3958]) define the terminology used in this document.
直径ベースプロトコル仕様（[RFC3588]のセクション1.3）およびStarient-NAPTR（S-NAPTR）DDDSアプリケーション（[RFC3958]のセクション2.1）は、このドキュメントで使用される用語を定義します。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The NAPTR service field format defined by the S-NAPTR DDDS application in [RFC3958] follows this Augmented Backus-Naur Form (ABNF) [RFC5234]:
[RFC3958]のS-NAPTR DDDSアプリケーションによって定義されたNAPTRサービスフィールド形式は、この増強されたBackus-Naurフォーム（ABNF）[RFC5234]に従います。
service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUMSYM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive.
This specification refines the "iana-registered-service" tag definition for the discovery of Diameter agents supporting a specific Diameter application as defined below.
この仕様は、以下に定義するように特定の直径アプリケーションをサポートする直径エージェントの発見のための「IANA登録サービス」タグ定義を改良します。
iana-registered-service =/ aaa-service
aaa-service = "aaa+ap" appln-id
appln-id = 1*10DIGIT
; Application Identifier expressed as
; a decimal integer without leading
; zeros.
The appln-id element is the Application Identifier used to identify a specific Diameter application. The Diameter Application Identifier is a 32-bit unsigned integer, and values are allocated by IANA as defined in [RFC3588].
Appln-ID要素は、特定の直径アプリケーションを識別するために使用されるアプリケーション識別子です。直径アプリケーション識別子は32ビットの符号なし整数であり、[RFC3588]で定義されているように、値はIANAによって割り当てられます。
This specification also refines the "iana-registered-protocol" tag definition for the discovery of Diameter agents supporting a specific Diameter transport protocol as defined below.
この仕様では、以下に定義する特定の直径輸送プロトコルをサポートする直径エージェントの発見のための「IANA-Registered-Protocol」タグ定義も改善します。
iana-registered-protocol =/ aaa-protocol
aaa-protocol = "diameter." aaa-transport
aaa-transport = "tcp" / "sctp" / "tls.tcp"
The S-NAPTR application protocol tags defined by this specification MUST NOT be parsed in any way by the querying application or resolver. The delimiter (".") is present in the tag to improve readability and does not imply a structure or namespace of any kind. The choice of delimiter (".") for the application protocol tag follows the format of existing S-NAPTR application protocol tag registry entries, but this does not imply that it shares semantics with any other specifications that create registry entries with the same format.
この仕様で定義されたS-NAPTRアプリケーションプロトコルタグは、クエリアプリケーションまたはリゾルバーによっていかなる方法でも解析されてはなりません。Delimiter（ "。"）は、読みやすさを向上させるためにタグに存在し、いかなる種類の構造や名前空間を意味しません。アプリケーションプロトコルタグのDelimiter（ "。"）の選択は、既存のS-NAPTRアプリケーションプロトコルタグレジストリエントリの形式に従いますが、これは、同じ形式のレジストリエントリを作成する他の仕様とセマンティクスを共有することを意味するものではありません。
The S-NAPTR application service and application protocol tags defined by this specification are unrelated to the IANA "Service Name and Transport Protocol Port Number Registry" (see [RFC6335]).
この仕様で定義されたS-NAPTRアプリケーションサービスおよびアプリケーションプロトコルタグは、IANA「サービス名と輸送プロトコル番号レジストリ」とは無関係です（[RFC6335を参照]）。
The maximum length of the NAPTR service field is 256 octets, including a one-octet length field (see Section 4.1 of [RFC3403] and Section 3.3 of [RFC1035]).
NAPTRサービスフィールドの最大長は256オクテットです。これには、1オクテットの長さフィールドが含まれます（[RFC3403]のセクション4.1を参照[RFC1035]のセクション3.3）。
A Diameter agent MUST be capable of using the extended S-NAPTR application service tag for dynamic discovery of a Diameter agent supporting Standards Track applications. Therefore, every IETF Standards Track Diameter application MUST be associated with a "aaa-service" tag formatted as defined in this specification and allocated in accordance with IANA policy (see Section 7).
直径エージェントは、拡張されたS-NAPTRアプリケーションサービスタグを使用して、標準サポート標準を追跡する直径エージェントの動的発見を行うことができなければなりません。したがって、すべてのIETF標準は、直径アプリケーションを追跡することは、この仕様で定義され、IANAポリシーに従って割り当てられた「AAA-Service」タグに関連付けられている必要があります（セクション7を参照）。
For example, a NAPTR service field value of:
たとえば、次のNAPTRサービスフィールド値値
'aaa+ap6:diameter.sctp'
'aaa ap6：diameter.sctp」
means that the Diameter node in the SRV or A/AAAA record supports the Diameter Session Initiation Protocol (SIP) application ('6') and the Stream Control Transmission Protocol (SCTP) as the transport protocol.
SRVまたはA/AAAAレコードの直径ノードは、輸送プロトコルとしての直径セッション開始プロトコル（SIP）アプリケーション（ '6'）およびストリーム制御伝送プロトコル（SCTP）をサポートすることを意味します。
S-NAPTR application service and application protocol tag values can also be used to discover Diameter peers that support a vendor-specific Diameter application. In this case, the vendor-specific Diameter application MUST be associated with a "aaa-service" tag formatted as defined in this specification and allocated in accordance with IANA policy (see Section 7).
S-NAPTRアプリケーションサービスおよびアプリケーションプロトコルタグ値を使用して、ベンダー固有の直径アプリケーションをサポートする直径ピアを発見することもできます。この場合、ベンダー固有の直径アプリケーションは、この仕様で定義され、IANAポリシーに従って割り当てられた「AAA-Service」タグに関連付けられている必要があります（セクション7を参照）。
For example, a NAPTR service field value of:
たとえば、次のNAPTRサービスフィールド値値
'aaa+ap16777251:diameter.sctp'
'AAA AP16777251：diameter.sctp'
means that the Diameter node in the SRV or A/AAAA record supports the Diameter Third Generation Partnership Project (3GPP) S6a application ('16777251') and SCTP as the transport protocol.
SRVまたはA/AAAAレコードの直径ノードは、輸送プロトコルとしての直径第3世代パートナーシッププロジェクト（3GPP）S6Aアプリケーション（ '16777251'）およびSCTPをサポートすることを意味します。
Domain Name System (DNS) administrators SHOULD also provision legacy NAPTR records [RFC3403] in the RFC 3588 style in order to guarantee backwards compatibility with legacy Diameter peers that are RFC 3588 compliant. If the DNS administrator provisions both extended S-NAPTR records as defined in this specification and legacy RFC 3588 NAPTR records, then the extended S-NAPTR records MUST have higher priority (e.g., lower order and/or preference values) than legacy NAPTR records.
ドメイン名システム（DNS）管理者は、RFC 3588スタイルでRFC 3588スタイルでレガシーNAPTRレコード[RFC3403]を提供する必要があります。DNS管理者が、この仕様で定義されている拡張S-NAPTRレコードとレガシーRFC 3588 NAPTRレコードの両方を提供する場合、拡張S-NAPTRレコードは、Legacy NAPTRレコードよりも優先度が高い（例：低次および/または選好値）が必要です。
The Diameter Peer Discovery principles are described in Section 5.2 of [RFC3588]. This specification updates the NAPTR query procedure in the Diameter peer discovery mechanism by allowing the querying node to determine which applications are supported by resolved Diameter peers.
直径ピアディスカバリーの原則は、[RFC3588]のセクション5.2で説明されています。この仕様は、クエリノードが解決された直径ピアによってサポートされているアプリケーションを決定できるようにすることにより、直径ピアディスカバリーメカニズムのNAPTRクエリ手順を更新します。
The extended-format NAPTR records provide a mapping from a domain to the SRV record or A/AAAA record for contacting a server supporting a specific transport protocol and Diameter application. The resource record will contain an empty regular expression and a replacement value, which is the SRV record or the A/AAAA record for that particular transport protocol.
拡張フォーマットNAPTRレコードは、特定のトランスポートプロトコルと直径アプリケーションをサポートするサーバーに連絡するために、ドメインからSRVレコードまたはA/AAAAレコードへのマッピングを提供します。リソースレコードには、空の正規表現と置換値が含まれます。これは、SRVレコードまたはその特定の輸送プロトコルのA/AAAAレコードです。
The assumption for this mechanism to work is that the DNS administrator of the queried domain has first provisioned the DNS with extended-format NAPTR entries. The steps below replace the NAPTR query procedure steps in Section 5.2 of [RFC3588].
このメカニズムが機能するための仮定は、クエリドメインのDNS管理者が最初に拡張フォーマットNAPTRエントリを備えたDNSをプロビジョニングしたことです。以下の手順は、[RFC3588]のセクション5.2のNAPTRクエリ手順の手順を置き換えます。
a. The Diameter implementation performs a NAPTR query for a server in a particular realm. The Diameter implementation has to know in advance in which realm to look for a Diameter agent, and in which Application Identifier it is interested. For example, the realm could be deduced from the Network Access Identifier (NAI) in the User-Name attribute-value pair (AVP) or extracted from the Destination-Realm AVP.
a. 直径の実装は、特定の領域内のサーバーのNAPTRクエリを実行します。直径の実装は、どの領域で直径エージェントを探すか、どの領域がどのアプリケーション識別子に興味があるかを知る必要があります。たとえば、領域は、ユーザー名属性値ペア（AVP）のネットワークアクセス識別子（NAI）から推定したり、宛先-RealM AVPから抽出したりすることができます。
b. If the returned NAPTR service fields contain entries formatted as "aaa+apX:Y" where "X" indicates the Application Identifier and "Y" indicates the supported transport protocol(s), the target realm supports the extended format for NAPTR-based Diameter peer discovery defined in this document.
b. 返されたNAPTRサービスフィールドに「AAA APX：Y」としてフォーマットされたエントリが含まれている場合、「X」はアプリケーション識別子を示し、「Y」はサポートされている輸送プロトコルを示します。このドキュメントで定義されている発見。
If "X" contains the required Application Identifier and "Y" matches a supported transport protocol, the Diameter implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field.
「x」が必要なアプリケーション識別子を含み、「y」がサポートされているトランスポートプロトコルと一致する場合、直径の実装は、「フラグ」フィールドに適したルックアップメソッドを使用してターゲットホストへの「交換」フィールドエントリを解決します。
If "X" does not contain the required Application Identifier or "Y" does not match a supported transport protocol, the Diameter implementation abandons the peer discovery.
「x」に必要なアプリケーション識別子または「Y」がサポートされている輸送プロトコルと一致しない場合、直径の実装はピアディスカバリーを禁止します。
c. If the returned NAPTR service fields contain entries formatted as "aaa+apX" where "X" indicates the Application Identifier, the target realm supports the extended format for NAPTR-based Diameter peer discovery defined in this document.
c. 返されたNAPTRサービスフィールドに「AAA APX」としてフォーマットされたエントリが含まれている場合、「X」はアプリケーション識別子を示します。ターゲットレルムは、このドキュメントで定義されているNAPTRベースの直径ピアディスカバリーの拡張形式をサポートします。
If "X" contains the required Application Identifier, the Diameter implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field and attempts to connect using all supported transport protocols following the order specified in Section 2.1 of [RFC3588].
「x」に必要なアプリケーション識別子が含まれている場合、直径の実装は、「フラグ」フィールドに適したルックアップメソッドを使用してターゲットホストへの「交換」フィールドエントリを解決し、セクションで指定された順序に従って支持されたすべてのトランスポートプロトコルを使用して接続しようとします[RFC3588]の2.1。
If "X" does not contain the required Application Identifier, the Diameter implementation abandons the peer discovery.
「x」に必要なアプリケーション識別子が含まれていない場合、直径の実装はピアディスカバリーを放棄します。
d. If the returned NAPTR service fields contain entries formatted as "aaa:X" where "X" indicates the supported transport protocol(s), the target realm supports Diameter but does not support the extended format for NAPTR-based Diameter peer discovery defined in this document.
d. 返されたNAPTRサービスフィールドに「AAA：X」としてフォーマットされたエントリが含まれている場合、「X」はサポートされている輸送プロトコルを示します。資料。
If "X" matches a supported transport protocol, the Diameter implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field.
「x」がサポートされているトランスポートプロトコルと一致する場合、直径の実装は、「フラグ」フィールドに適したルックアップメソッドを使用して、ターゲットホストへの「交換」フィールドエントリを解決します。
e. If the returned NAPTR service fields contain entries formatted as "aaa", the target realm supports Diameter but does not support the extended format for NAPTR-based Diameter peer discovery defined in this document. The Diameter implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field and attempts to connect using all supported transport protocols following the order specified in Section 2.1 of [RFC3588].
e. 返されたNAPTRサービスフィールドに「AAA」としてフォーマットされたエントリが含まれている場合、ターゲットレルムは直径をサポートしますが、このドキュメントで定義されているNAPTRベースの直径ピアディスカバリーの拡張形式をサポートしていません。直径の実装は、「フラグ」フィールドに適したルックアップ方法を使用してターゲットホストへの「交換」フィールドエントリを解決し、[RFC3588]のセクション2.1で指定された順序に従って、サポートされているすべての輸送プロトコルを使用して接続しようとします。
f. If the target realm does not support NAPTR-based Diameter peer discovery, the client proceeds with the next peer discovery mechanism described in Section 5.2 of [RFC3588].
f. ターゲットレルムがNAPTRベースの直径ピアディスカバリーをサポートしていない場合、クライアントは[RFC3588]のセクション5.2で説明されている次のピアディスカバリーメカニズムに進みます。
As an example, consider a client that wishes to discover a Diameter server in the ex1.example.com realm that supports the Credit Control application. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
例として、クレジットコントロールアプリケーションをサポートするEx1.example.com Realmで直径サーバーを発見したいクライアントを検討してください。クライアントは、そのドメインに対してNAPTRクエリを実行し、次のNAPTRレコードが返されます。
;; order pref flags service regexp replacement IN NAPTR 50 50 "s" "aaa:diameter.sctp" "" _diameter._sctp.ex1.example.com IN NAPTR 50 50 "s" "aaa+ap1:diameter.sctp" "" _diameter._sctp.ex1.example.com IN NAPTR 50 50 "s" "aaa+ap4:diameter.sctp" "" _diameter._sctp.ex1.example.com
;;NAPTR 50 "s" "AAA：diameter.sctp" "" _diameter.ex1.example.comのNaptr 50 "s" "aaa：diameter.sctpのnaptr flags regexp交換を注文する注文は、naptr 50 50" s "" aaa ap1：diameter.sctp "" "_diameter。_sctp.ex1.example.com in naptr 50 50 "s" "aaa ap4：diameter.sctp" "" _diameter._sctp.ex1.example.com
This indicates that the server supports NASREQ (ID=1) and Credit Control (ID=4) applications over SCTP. If the client supports SCTP, it will be used, targeted to a host determined by an SRV lookup of _diameter._sctp.ex1.example.com.
これは、サーバーがSCTPよりもNasReq（ID = 1）およびクレジットコントロール（ID = 4）アプリケーションをサポートしていることを示しています。クライアントがSCTPをサポートしている場合、_diameter._sctp.ex1.example.comのSRVルックアップによって決定されるホストをターゲットにすることを標的とします。
That SRV lookup would return:
そのSRV検索は戻ります：
;; Priority Weight Port Target IN SRV 0 1 3868 server1.ex1.example.com IN SRV 0 2 3868 server2.ex1.example.com
;;SRV 0 1 3868 server1.ex1.example.comの優先ウェイトポートターゲットSRV 0 2 3868 server2.ex1.example.com
As an alternative example, a client wishes to discover a Diameter server in the ex2.example.com realm that supports the NASREQ application over SCTP. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
別の例として、クライアントは、SCTPを介したNASREQアプリケーションをサポートするEx2.example.com Realmで直径サーバーを発見したいと考えています。クライアントは、そのドメインに対してNAPTRクエリを実行し、次のNAPTRレコードが返されます。
;; order pref flags service regexp replacement IN NAPTR 150 50 "a" "aaa:diameter.sctp" "" server1.ex2.example.com IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" server2.ex2.example.com IN NAPTR 150 50 "a" "aaa+ap1:diameter.sctp" "" server1.ex2.example.com IN NAPTR 150 50 "a" "aaa+ap1:diameter.tls.tcp" "" server2.ex2.example.com
;;NAPTR 150 "a" "aaa：diameter.sctp" "" server1.ex2.example.com in naptr 150 "a" "aaa：diameter.tls.tcp" "" "" server2.ex2.example.com in Naptr 150 50 "a" "aaa ap1：diameter.sctp" "" "server1.ex2.example.com in naptr 150 50" a "".example.com
This indicates that the server supports NASREQ (ID=1) over SCTP and Transport Layer Security (TLS)/TCP via hosts server1.ex2.example.com and server2.ex2.example.com, respectively.
これは、サーバーがSCTPおよびTransport Layer Security（TLS）/TCPを介してそれぞれNASREQ（ID = 1）をサポートしていることを示しています。
Diameter is a peer-to-peer protocol, whereas most of the applications that extend the base protocol behave like client/server applications. The role of the peer is not advertised in the NAPTR tags and not even communicated during Diameter capability negotiation (Capabilities-Exchange-Request and Capabilities-Exchange-Answer message exchange). For this reason, NAPTR-based Diameter peer discovery for an application defining client/server roles should only be used by a client to discover servers.
直径はピアツーピアプロトコルですが、ベースプロトコルを拡張するアプリケーションのほとんどは、クライアント/サーバーアプリケーションのように動作します。ピアの役割はNAPTRタグでは宣伝されておらず、直径の能力交渉中に通信されることさえありません（機能 - 交換と能力 - エクスチャンジ - 回答メッセージ交換）。このため、クライアント/サーバーの役割を定義するアプリケーションのNAPTRベースの直径ピアディスカバリーは、クライアントがサーバーを発見するためにのみ使用する必要があります。
IANA has reserved a value of "aaa" for Diameter in the "(S-NAPTR) Application Service Tag" registry created by [RFC3958]. IANA has also reserved the following S-NAPTR application service tags for existing IETF Diameter applications in the same registry.
IANAは、[RFC3958]によって作成された「（S-NAPTR）アプリケーションサービスタグ「レジストリ」の直径の「AAA」の値を予約しています。IANAは、同じレジストリ内の既存のIETF直径アプリケーションの次のS-NAPTRアプリケーションサービスタグも予約しています。
+------------------+----------------------------+
| Tag | Diameter Application |
+------------------+----------------------------+
| aaa+ap1 | NASREQ [RFC3588] |
| aaa+ap2 | Mobile IPv4 [RFC4004] |
| aaa+ap3 | Base Accounting [RFC3588] |
| aaa+ap4 | Credit Control [RFC4006] |
| aaa+ap5 | EAP [RFC4072] |
| aaa+ap6 | SIP [RFC4740] |
| aaa+ap7 | Mobile IPv6 IKE [RFC5778] |
| aaa+ap8 | Mobile IPv6 Auth [RFC5778] |
| aaa+ap9 | QoS [RFC5866] |
| aaa+ap4294967295 | Relay [RFC3588] |
+------------------+----------------------------+
Future IETF Diameter applications MUST reserve the S-NAPTR application service tag corresponding to the allocated Diameter Application ID as defined in Section 3.
将来のIETF直径アプリケーションは、セクション3で定義されているように、割り当てられた直径アプリケーションIDに対応するS-NAPTRアプリケーションサービスタグを予約する必要があります。
IANA has reserved the following S-NAPTR application service tags for existing 3GPP Diameter applications in the "S-NAPTR Application Service Tag" registry created by [RFC3958].
IANAは、[RFC3958]によって作成された「S-NAPTRアプリケーションサービスタグ」レジストリで、既存の3GPP直径アプリケーションの次のS-NAPTRアプリケーションサービスタグを予約しています。
+----------------+----------------------+
| Tag | Diameter Application |
+----------------+----------------------+
| aaa+ap16777250 | 3GPP STa [TS29.273] |
| aaa+ap16777251 | 3GPP S6a [TS29.272] |
| aaa+ap16777264 | 3GPP SWm [TS29.273] |
| aaa+ap16777267 | 3GPP S9 [TS29.215] |
+----------------+----------------------+
Future 3GPP Diameter applications can reserve entries in the "S-NAPTR Application Service Tag" registry created by [RFC3958] that correspond to the allocated Diameter Application IDs as defined in Section 3.
将来の3GPP直径アプリケーションは、セクション3で定義されているように、割り当てられた直径アプリケーションIDに対応する[RFC3958]によって作成された[RFC3958]によって作成された「S-NAPTRアプリケーションサービスタグ」レジストリにエントリを予約できます。
IANA has reserved the following S-NAPTR application service tags for existing Worldwide Interoperability for Microwave Access (WiMAX) Forum Diameter applications in the "S-NAPTR Application Service Tag" registry created by [RFC3958].
IANAは、[RFC3958]によって作成された「S-NAPTRアプリケーションサービスタグ」レジストリで、マイクロ波アクセス（WIMAX）フォーラムの直径アプリケーションの既存の世界的な相互運用性のための次のS-NAPTRアプリケーションサービスタグを予約しています。
+----------------+--------------------------------------------------+
| Tag | Diameter Application |
+----------------+--------------------------------------------------+
| aaa+ap16777281 | WiMAX Network Access Authentication and |
| | Authorization Diameter Application (WNAAADA) |
| | [WiMAX-BASE] |
| aaa+ap16777282 | WiMAX Network Accounting Diameter Application |
| | (WNADA) [WiMAX-BASE] |
| aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) |
| | [WiMAX-BASE] |
| aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) |
| | [WiMAX-BASE] |
| aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) |
| | [WiMAX-BASE] |
| aaa+ap16777286 | WiMAX Location Authentication Authorization |
| | Diameter Application (WLAADA) [WiMAX-LBS] |
| aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies |
| | Diameter Application (WiMAX PCC-R3-P) |
| | [WiMAX-PCC] |
| aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline |
| | Charging Diameter Application (WiMAX PCC-R3-OFC) |
| | [WiMAX-PCC] |
| aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline |
| | Charging Prime Diameter Application (WiMAX |
| | PCC-R3-OFC-PRIME) [WiMAX-PCC] |
| aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online |
| | Charging Diameter Application (WiMAX PCC-R3-OC) |
| | [WiMAX-PCC] |
+----------------+--------------------------------------------------+
Future WiMAX Forum Diameter applications can reserve entries in the "S-NAPTR Application Service Tag" registry created by [RFC3958] that correspond to the allocated Diameter Application IDs as defined in Section 3.
将来のWIMAXフォーラムの直径アプリケーションは、セクション3で定義されている割り当てられた直径アプリケーションIDに対応する[RFC3958]によって作成された[S-NAPTRアプリケーションサービスタグ]レジストリにエントリを予約できます。
Vendor-Specific Diameter Application IDs are allocated by IANA according to the "First Come First Served" policy and do not require an IETF specification. However, the S-NAPTR application service tag registry created by [RFC3958] defines a registration policy of
ベンダー固有の直径アプリケーションIDは、「First Come First Servent」ポリシーに従ってIANAによって割り当てられ、IETF仕様は必要ありません。ただし、[RFC3958]によって作成されたS-NAPTRアプリケーションサービスタグレジストリは、
"Specification Required" with a further stipulation that the "specification" is an RFC (of any category). If a vendor-specific Diameter application requires the functionality defined in this document, an RFC of any category MUST be published that reserves the S-NAPTR Application Service Tag corresponding to the Vendor-Specific Diameter Application ID as defined in Section 3.
「仕様」が「仕様」が（任意のカテゴリの）RFCであるというさらなる規定を伴う「仕様が必要」。ベンダー固有の直径アプリケーションがこのドキュメントで定義されている機能を必要とする場合、セクション3で定義されているベンダー固有の直径アプリケーションIDに対応するS-NAPTRアプリケーションサービスタグを留保するカテゴリのRFCを公開する必要があります。
IANA has reserved the following S-NAPTR Application Protocol Tags for the Diameter transport protocols in the "S-NAPTR Application Protocol Tag" registry created by [RFC3958].
IANAは、[RFC3958]によって作成された「S-NAPTRアプリケーションプロトコルタグ」レジストリの直径輸送プロトコルの次のS-NAPTRアプリケーションプロトコルタグを予約しています。
+------------------+----------+
| Tag | Protocol |
+------------------+----------+
| diameter.tcp | TCP |
| diameter.sctp | SCTP |
| diameter.tls.tcp | TLS/TCP |
+------------------+----------+
Future Diameter versions that introduce new transport protocols MUST reserve an appropriate S-NAPTR Application Protocol Tag in the "S-NAPTR Application Protocol Tag" registry created by [RFC3958].
新しい輸送プロトコルを導入する将来の直径バージョンは、[RFC3958]によって作成された「S-NAPTRアプリケーションプロトコルタグ」レジストリに適切なS-NAPTRアプリケーションプロトコルタグを予約する必要があります。
This document specifies an enhancement to the NAPTR service field format defined in RFC 3588 and also modifications to the NAPTR processing logic defined in RFC 3588. The enhancement and modifications are based on the S-NAPTR, which is actually a simplification of the NAPTR, and therefore the same security considerations described in RFC 3588 [RFC3588] are applicable to this document. No further extensions are required beyond the security mechanisms offered by RFC 3588. However, a malicious host doing S-NAPTR queries learns applications supported by Diameter agents in a certain realm faster, which might help the malicious host to scan potential targets for an attack more efficiently when some applications have known vulnerabilities.
このドキュメントは、RFC 3588で定義されているNAPTRサービスフィールド形式の強化と、RFC 3588で定義されたNAPTR処理ロジックの変更を指定します。強化と変更は、実際にNAPTRの単純化であるS-NAPTRに基づいています。したがって、RFC 3588 [RFC3588]で説明されている同じセキュリティ上の考慮事項がこのドキュメントに適用されます。RFC 3588が提供するセキュリティメカニズムを超えて、それ以上の拡張機能は必要ありません。ただし、S-NAPTRクエリを実行する悪意のあるホストは、特定の領域の直径エージェントによってサポートされているアプリケーションをより速く学習します。一部のアプリケーションが脆弱性を知っている場合に効率的に。
We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Sebastien Decugis, Dan Romascanu, Adrian Farrel, David Harrington, Pete Resnick, Robert Sparks, Stephen Farrell, Wesley Eddy, Ralph Droms, and Joe Touch for their comprehensive review comments.
グレン・ゾルン、アヴィ・リオール、イサム・タナカ、セバスチャン・デコギス、ダン・ロマスカヌ、エイドリアン・ファレル、デビッド・ハリントン、ピート・レストニック、ロバート・スパークス、スティーブン・ファレル、ウェスリー・エディ、ラルフ・ドロム、ジョー・タッチの魅力的なレビューコメントのコメントに感謝します。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS拡張機能IPバージョン6」、RFC 3596、2003年10月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958] Daigle、L。およびA. Newton、「SRV RRSおよびThe Dynamic Deligation Discovery Service（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 3958、2005年1月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004] Calhoun、P.、Johansson、T.、Perkins、C.、Hiller、T.、Ed。、およびP. McCann、「直径モバイルIPv4アプリケーション」、RFC 4004、2005年8月。
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005.
[RFC4006] Hakala、H.、Mattila、L.、Koskinen、J-P。、Stura、M。、およびJ. Loughney、「Diameter Credit-Control Application」、RFC 4006、2005年8月。
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、Ed。、Hiller、T。、およびG. Zorn、「直径拡張可能な認証プロトコル（EAP）アプリケーション」、RFC 4072、2005年8月。
[RFC4740] Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006.
[RFC4740] Garcia-Martin、M.、Ed。、Belinchon、M.、Pallares-Lopez、M.、Canales-Valenzuela、C.、およびK. Tammi、「直径セッション開始プロトコル（SIP）アプリケーション」、RFC 4740、2006年11月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5778] Korhonen, J., Ed., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", RFC 5778, February 2010.
[RFC5778] Korhonen、J.、Ed。、Tschofenig、H.、Bournelle、J.、Giaretta、G。、およびM. Nakhjiri、「直径のモバイルIPv6：直径のサーバーの相互作用のサポート」、RFC 5778、2月2月2010年。
[RFC5866] Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, Ed., "Diameter Quality-of-Service Application", RFC 5866, May 2010.
[RFC5866] Sun、D.、ed。、McCann、P.、Tschofenig、H.、Tsou、T.、Doria、A。、およびG. Zorn、ed。、「直径のサービス品質アプリケーション」、RFC5866、2010年5月。
[TS29.215] 3rd Generation Partnership Project, "3GPP TS 29.215; Technical Specification Group Core Network and Terminals; Policy and Charging Control (PCC) over S9 reference point; Stage 3 (Release 8)", <http://www.3gpp.org/ftp/Specs/html-info/29215.htm>.
[TS29.215]第3世代パートナーシッププロジェクト、「3GPP TS 29.215;技術仕様グループコアネットワークおよび端末、S9参照ポイント上のポリシーと充電制御（PCC）、ステージ3（リリース8）」、<http：// www。3gpp.org/ftp/specs/html-info/29215.htm>。
[TS29.272] 3rd Generation Partnership Project, "3GPP TS 29.272; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) Related Interfaces Based on Diameter Protocol (Release 8)", <http://www.3gpp.org/ftp/Specs/html-info/29272.htm>.
[TS29.272]第3世代パートナーシッププロジェクト、「3GPP TS 29.272;技術仕様グループコアネットワークおよび端末、進化したパケットシステム（EPS）;モビリティ管理エンティティ（MME）およびサービングGPRSサポートノード（SGSN）関連インターフェイスに基づく直径のプロトコルに基づくサポートノード（SGSN）関連インターフェイス（リリース8） "、<http://www.3gpp.org/ftp/specs/html-info/29272.htm>。
[TS29.273] 3rd Generation Partnership Project, "3GPP TS 29.273; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); 3GPP EPS AAA interfaces (Release 8)", <http://www.3gpp.org/ftp/Specs/html-info/29273.htm>.
[TS29.273]第3世代パートナーシッププロジェクト、「3GPP TS 29.273;技術仕様グループコアネットワークおよび端末、進化したパケットシステム（EPS）; 3GPP EPS AAAインターフェイス（リリース8）」、<http://www.3gpp.org/ftp/specs/html-info/29273.htm>。
[WiMAX-BASE] WiMAX Forum, "WMF-T33-001-R015v02 - WiMAX Forum(R) Network Architecture - Detailed Protocols and Procedures, Base Specification - Release 1.5", <http://www.wimaxforum.org/resources/ documents/technical/T33>.
[Wimax-Base] Wimax Forum、 "WMF-T33-001-R015V02-WIMAX FORUM（R）ネットワークアーキテクチャ - 詳細なプロトコルと手順、ベース仕様-Reeleas 1.5"、<http://www.wimaxforum.org/resources/ドキュメント/テクニカル/T33>。
[WiMAX-LBS] WiMAX Forum, "WMF-T33-110-R015v01 - WiMAX Forum(R) Network Architecture - Protocols and Procedures for Location Based Services - Release 1.5", <http://www.wimaxforum.org/resources/ documents/technical/T33>.
[Wimax-LBS] Wimax Forum、 "WMF-T33-110-R015V01-WIMAXフォーラム（R）ネットワークアーキテクチャ - ロケーションベースのサービスのプロトコルと手順 - リリース1.5"、<http://www.wimaxforum.org/resources/ドキュメント/テクニカル/T33>。
[WiMAX-PCC] WiMAX Forum, "WMF-T33-109-R015v02 - WiMAX Forum(R) Network Architecture - Detailed Protocols and Procedures, Policy and Charging Control - Release 1.5", <http://www.wimaxforum.org/resources/ documents/technical/T33>.
[Wimax-PCC] Wimax Forum、 "WMF-T33-109-R015V02-WIMAX FORUM（R）ネットワークアーキテクチャ - 詳細なプロトコルと手順、ポリシーおよび充電制御-1.5"、<http://www.wimaxforum.org/リソース/ドキュメント/技術/T33>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.
[RFC6335] Cotton、M.、Eggert、L.、Touch、J.、Westerlund、M。、およびS. Cheshire、「インターネットが割り当てられた数字権（IANA）手順サービス名と輸送プロトコルポート番号レジストリの管理のための手順"、BCP 165、RFC 6335、2011年8月。
Authors' Addresses
著者のアドレス
Mark Jones Bridgewater Systems
マークジョーンズブリッジウォーターシステム
EMail: mark@azu.ca
Jouni Korhonen Nokia Siemens Networks
Jouni Korhonen Nokia Siemensネットワーク
EMail: jouni.nospam@gmail.com
Lionel Morand Orange Labs
Lionel Morand Orange Labs
EMail: lionel.morand@orange.com