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.
直径ベースプロトコルは、与えられたレルムがDiameterノードとサポートされているトランスポート・プロトコルを広告することができるれるメカニズムを指定します。しかし、これらのメカニズムは、各ノードがサポートするDiameterアプリケーションを明らかにしないでください。レルム外部ピアは、それが必要なアプリケーションをサポートしているものを発見するまで、すべてのノードとのDiameter能力交換を実行しなければなりません。この文書は、更新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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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]はDiameterピア発見のための3つの機構を指定します。これらの一つは、特定の領域内のサーバの命名権限ポインタ（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.
NAPTRサービスフィールドに特定のトランスポートプロトコルを用いてサーバに接触するためにDNSサービスロケータ（SRV）レコード[RFC2782]またはA / AAAAレコード[RFC1035]、[RFC3596]のドメインからのマッピングを提供します。
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.
このドキュメントによって定義されたDiameterピア発見のための拡張されたNAPTRの使用は[RFC3958]で定義されたわかりやすい-NAPTR（S-NAPTR）ダイナミックな委譲発見システム（DDDS）アプリケーションに基づいています。このドキュメントは[RFC3588]のセクション5.2に記載のDiameterピア発見手順を更新し、特定のDiameterアプリケーションおよびトランスポートプロトコルをサポートするDiameterピアの発見を可能にする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）で直接的-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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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サービスフィールドの形式は、この増補バッカス - ナウアフォーム（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.
この仕様は、以下に定義される特定のDiameterアプリケーションをサポート直径剤の発見のための「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].
文献1】-id要素は、特定のDiameterアプリケーションを識別するために使用されるアプリケーション識別子です。直径アプリケーション識別子は、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.
本明細書はまた、以下に定義されるような特定のDiameterトランスポートプロトコルをサポート直径剤の発見のための「IANAに登録されたプロトコル」タグの定義を洗練します。
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アプリケーションプロトコルタグは、問合せアプリケーションやレゾルバによって任意の方法で解析されてはいけません。デリミタは、（「」）可読性を改善するために、タグ内に存在し、あらゆる種類の構造または名前空間を意味するものではありません。アプリケーションプロトコルタグの区切り文字の選択は、（「」）は、既存の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アプリケーションサービスおよびアプリケーションプロトコルタグは、「サービス名とトランスポートプロトコルポート番号レジストリ」（[RFC6335]を参照）IANAとは無関係です。
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サービスフィールドの最大長は（[RFC3403]のセクション4.1と[RFC1035]のセクション3.3を参照）は1オクテットの長さフィールドを含む256オクテットです。
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).
直径剤は、標準化過程のアプリケーションをサポートするDiameterエージェントの動的な発見のための拡張されたS-NAPTRアプリケーションサービスタグを使用できなければなりません。したがって、すべてのIETF標準化過程のDiameterアプリケーションは、本明細書で定義され、IANAポリシーに従って割り当てとしてフォーマット「AAAサービス」タグに関連付けられている必要があり（セクション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レコードのDiameterノードは、トランスポートプロトコルとしてのDiameterセッション開始プロトコル（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アプリケーションサービスとアプリケーションプロトコルタグ値はまた、ベンダー固有のDiameterアプリケーションをサポートするDiameterピアを発見するために使用することができます。この場合には、ベンダー固有のDiameterアプリケーションは、本明細書で定義され、IANAポリシーに従って割り当てとしてフォーマット「AAAサービス」タグに関連付けられている必要があり（セクション7参照）。
For example, a NAPTR service field value of:
例えば、のNAPTRサービスフィールド値：
'aaa+ap16777251:diameter.sctp'
ミート+ 8月16777251：Dimitr.sketbi
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レコードのDiameterノードは、トランスポートプロトコルとして直径第三世代パートナーシッププロジェクト（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のスタイルでSHOULDも提供レガシーNAPTRレコード[RFC3403] RFC 3588に準拠しているレガシーの直径のピアとの下位互換性を保証するためです。本明細書及び従来のRFC 3588枚のNAPTRレコードに定義されるようにDNS管理者規定の両方拡張S-NAPTRレコード場合は、その後、拡張S-NAPTRレコードは、レガシー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に記載されています。この仕様は、解決のDiameterピアによってサポートされるアプリケーションを決定するためにクエリノードを可能にすることによって、Diameterピア発見機構における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レコードは、特定のトランスポートプロトコル及びDiameterアプリケーションをサポートするサーバーに接続するための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問合せを行います。 Diameter実装は、Diameterエージェントを探すためにどの分野で事前に知る必要があり、その中にアプリケーション識別子それが興味を持っています。例えば、領域は、ユーザ名属性値ペア（AVP）にネットワークアクセス識別子（NAI）から推定することができ、または宛先レルム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」がサポートされているトランスポート・プロトコル（s）は、標的領域は、NAPTRベースの直径の拡張フォーマットをサポートして示しこの文書で定義されたピア発見。
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.
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サービスフィールドが「X」は、アプリケーション識別子を示す「AAA + APX」としてフォーマットされたエントリが含まれている場合、標的領域は、この文書で定義されたNAPTRベースDiameterピア発見のための拡張フォーマットをサポートします。
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].
If "X" does not contain the required Application Identifier, the Diameter implementation abandons the peer discovery.
「X」は、必要なアプリケーション識別子が含まれていない場合は、Diameter実装は、ピア発見を放棄します。
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サービスフィールドはとしてフォーマットエントリ含まれている場合：「X」がサポートされているトランスポート・プロトコル（単数または複数）を示す「AAA X」を、標的領域は、Diameterをサポートするが、この中で定義されたNAPTRベースDiameterピア発見のための拡張フォーマットをサポートしていません資料。
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.
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].
電子。返されたNAPTRサービスフィールドが「AAA」としてフォーマットのエントリが含まれている場合は、対象領域は、Diameterをサポートしていますが、この文書で定義されたNAPTRベースのDiameterピア発見のための拡張フォーマットをサポートしていません。直径実装は、「フラグ」フィールドに適切な検索方法を使用して、ターゲットホストに「置換」フィールドエントリを解決し、[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ベースのDiameterピア発見をサポートしていない場合、クライアントは、[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レルムにDiameterサーバを発見することを希望するクライアントを考えてみましょう。クライアントは、そのドメインの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
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
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レルムにDiameterサーバを発見したいです。クライアントは、そのドメインの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
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.
これは、サーバーがそれぞれのホストserver1.ex2.example.comとserver2.ex2.example.com、経由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タグでアドバタイズしないとさえ直径機能ネゴシエーション（交換機能リクエストおよび機能交換-Answerメッセージ交換）中に通信されません。このため、クライアント/サーバーの役割を定義するアプリケーションのための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 Diameterアプリケーションのために、以下の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.
セクション3で定義されるように将来IETF Diameterアプリケーションは、割り当てられたDIAMETERアプリケーション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 Diameterアプリケーションのために、以下の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 Diameterアプリケーションは、セクション3で定義されるように割り当てられたDIAMETERアプリケーションIDに対応する[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の）フォーラムのDiameterアプリケーションのための世界的な相互運用性を既存の以下の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フォーラムのDiameterアプリケーションは、セクション3で定義されるように割り当てられたDiameterアプリケーション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
ベンダー固有のDiameterアプリケーションIDは、「まず第一に役立っ是非」ポリシーに従って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でさらに規定と「仕様が必要です」。ベンダー固有のDiameterアプリケーションは、この文書で定義された機能を必要とする場合は、任意のカテゴリのRFCは、第3節で定義されたベンダー固有のDIAMETERアプリケーションIDに対応するS-NAPTRアプリケーションサービスタグを留保している公開する必要があります。
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.
私たちは彼らの包括的なレビュー・コメントのグレンソーン、アビLIOR、Itsuma田中、セバスチャンDecugis、ダンRomascanu、エードリアンファレル、デヴィッド・ハリントン、ピート・レズニック、ロバート・スパークス、スティーブン・ファレル、ウェズリーエディ、ラルフDroms、そしてジョー・タッチに感謝したいと思います。
[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、 "ダイナミックな委譲発見システム（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]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、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]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、RFC 3596、2003年10月 "DNSの拡張機能は、IPバージョン6をサポートします"。
[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.ニュートン、RFC 3958、2005年1月 "SRVのRRを使用したアプリケーションサービスの場所とダイナミックな委譲発見サービス（DDDS）をドメインベース"。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004]カルフーン、P.、ヨハンソン、T.、パーキンス、C.、ヒラー、T.編、及びP.マッキャン、 "直径モバイル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.、コスキネン、J-P。、Stura、M.、およびJ. Loughney、 "直径クレジット制御アプリケーション"、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.編、ヒラー、T.、およびG.ゾルン、 "直径拡張認証プロトコル（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]ガルシア - マーチン、M.編、Belinchon、M.、Pallares - ロペス、M.、カナーレス-ヴァレンズエラ、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.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、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.、エド、Tschofenig、H.、Bournelle、J.、Giaretta、G.、およびM. Nakhjiri、 "直径モバイルIPv6：直径サーバの対話にホームエージェントのサポート"、RFC 5778、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.、編、マッキャン、P.、Tschofenig、H.、ツオウ、T.、ドリア、A.、およびG.ゾルン、編、 "直径クオリティ・オブ・サービスアプリケーション"、RFC 5866、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）関連インタフェース（リリース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フォーラム、 "WMF-T33-001-R015v02 - WiMAXフォーラム（R）ネットワークアーキテクチャ - 詳細なプロトコルおよび手順、基本仕様は、 - 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フォーラムは、http://www.wimaxforum.org/resources/ < "WMF-T33-110-R015v01 - WiMAXフォーラム（R）ネットワークアーキテクチャ - - 位置情報サービスのためのプロトコルと手順は、1.5をリリース"ドキュメント/技術/ 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フォーラム、 "WMF-T33-109-R015v02 - WiMAXフォーラム（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]コットン、M.、エッゲルト、L.、タッチ、J.、ウェスター、M.、およびS.チェシャー、「IANA（Internet Assigned Numbers Authority）のサービス名とトランスポートプロトコルポート番号レジストリの管理のための手順」、BCP 165、RFC 6335、2011年8月。
Authors' Addresses
著者のアドレス
Mark Jones Bridgewater Systems
マーク・ジョーンズブリッジウォーターシステムズ
EMail: mark@azu.ca
メールアドレス：mark@azu.ca
Jouni Korhonen Nokia Siemens Networks
Jouni Korhonen、ノキア・シーメンス・ネットワークス
EMail: jouni.nospam@gmail.com
メールアドレス：jouni.nospam@gmail.com
Lionel Morand Orange Labs
ライオネル・モランオレンジ研究所
EMail: lionel.morand@orange.com
メールアドレス：lionel.morand@orange.com