[要約] RFC 6736は、Diameterネットワークアドレスとポート変換制御アプリケーションに関する規格です。このRFCの目的は、Diameterプロトコルを使用してネットワークアドレスとポート変換を制御するための仕様を提供することです。
Internet Engineering Task Force (IETF) F. Brockners
Request for Comments: 6736 S. Bhandari
Category: Standards Track Cisco
ISSN: 2070-1721 V. Singh
V. Fajardo Telcordia Technologies October 2012
V. Fajardo Telcordia Technologies 2012年10月
Diameter Network Address and Port Translation Control Application
Diameterネットワークアドレスおよびポート変換制御アプリケーション
Abstract
概要
This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes.
このドキュメントでは、Diameterネットワークアドレスおよびポート変換制御アプリケーションのフレームワーク、メッセージ、および手順について説明します。このDiameterアプリケーションを使用すると、IPv4アドレス空間の枯渇に対処するためにネットワークに追加される、ネットワークアドレストランスレータとネットワークアドレスおよびポートトランスレータのエンドポイント単位の制御が可能になります。このDiameterアプリケーションを使用すると、外部デバイスがネットワークアドレストランスレータデバイスを構成および管理できます。既存のDiameterベースの認証、承認、アカウンティング（AAA）およびポリシー制御機能を、ネットワークアドレストランスレータとネットワークアドレスおよびポートトランスレータ制御コンポーネントで拡張できます。これらの外部デバイスは、ネットワークアクセスサーバーなどのデータプレーンのネットワーク要素にすることも、AAAサーバーなどのより集中化されたコントロールプレーンデバイスにすることもできます。このDiameterアプリケーションは、ゲートウェイまたはサーバー上のエンドポイント、およびネットワークアドレストランスレーターとネットワークアドレスおよびポートトランスレーターデバイスを一般的に識別および管理するためのコンテキストを確立します。これには、たとえば、許可されるNetwork Address Translatorバインディングの総数の制御や、特定のエンドポイントに対する特定のNetwork Address Translatorバインディングの割り当てが含まれます。さらに、ネットワークアドレストランスレータデバイスは、会計目的に関連する情報を提供できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6736.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6736で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions .....................................................6
3. Deployment Framework ............................................7
3.1. Deployment Scenario ........................................7
3.2. Diameter NAPT Control Application Overview .................9
3.3. Deployment Scenarios for DNCA .............................10
4. DNCA Session Establishment and Management ......................12
4.1. Session Establishment .....................................13
4.2. Session Update ............................................16
4.3. Session and Binding Query .................................18
4.4. Session Termination .......................................20
4.5. Session Abort .............................................21
4.6. Failure Cases of the DNCA Diameter Peers ..................22
5. Use of the Diameter Base Protocol ..............................23
5.1. Securing Diameter Messages ................................23
5.2. Accounting Functionality ..................................24
5.3. Use of Sessions ...........................................24
5.4. Routing Considerations ....................................24
5.5. Advertising Application Support ...........................24
6. DNCA Commands ..................................................25
6.1. NAT-Control-Request (NCR) Command .........................25
6.2. NAT-Control-Answer (NCA) Command ..........................26
7. NAT Control Application Session State Machine ..................26
8. DNCA AVPs ......................................................29
8.1. Reused Base Protocol AVPs .................................29
8.2. Additional Result-Code AVP Values .........................30
8.2.1. Success ............................................30
8.2.2. Transient Failures .................................30
8.2.3. Permanent Failures .................................31
8.3. Reused NASREQ Diameter Application AVPs ...................32
8.4. Reused AVPs from RFC 4675 .................................33
8.5. Reused AVPs from Diameter QoS Application .................33
8.6. Reused AVPs from ETSI ES 283 034, e4 Diameter
Application ...............................................34
8.7. DNCA-Defined AVPs .........................................35
8.7.1. NC-Request-Type AVP ................................36
8.7.2. NAT-Control-Install AVP ............................36
8.7.3. NAT-Control-Remove AVP .............................37
8.7.4. NAT-Control-Definition AVP .........................37
8.7.5. NAT-Internal-Address AVP ...........................38
8.7.6. NAT-External-Address AVP ...........................38
8.7.7. Max-NAT-Bindings ...................................39
8.7.8. NAT-Control-Binding-Template AVP ...................39
8.7.9. Duplicate-Session-Id AVP ...........................39
8.7.10. NAT-External-Port-Style AVP .......................39
9. Accounting Commands ............................................40
9.1. NAT Control Accounting Messages ...........................40
9.2. NAT Control Accounting AVPs ...............................40
9.2.1. NAT-Control-Record .................................41
9.2.2. NAT-Control-Binding-Status .........................41
9.2.3. Current-NAT-Bindings ...............................41
10. AVP Occurrence Tables .........................................41
10.1. DNCA AVP Table for NAT Control Initial and Update
Requests .................................................42
10.2. DNCA AVP Table for Session Query Requests ................43
10.3. DNCA AVP Table for Accounting Messages ...................43
11. IANA Considerations ...........................................44
11.1. Application Identifier ...................................44
11.2. Command Codes ............................................44
11.3. AVP Codes ................................................44
11.4. Result-Code AVP Values ...................................44
11.5. NC-Request-Type AVP ......................................44
11.6. NAT-External-Port-Style AVP ..............................45
11.7. NAT-Control-Binding-Status AVP ...........................45
12. Security Considerations .......................................45
13. Examples ......................................................47
13.1. DNCA Session Establishment Example .......................47
13.2. DNCA Session Update with Port Style Example ..............50
13.3. DNCA Session Query Example ...............................51
13.4. DNCA Session Termination Example .........................53
14. Acknowledgements ..............................................55
15. References ....................................................55
15.1. Normative References .....................................55
15.2. Informative References ...................................56
Internet service providers deploy Network Address Translators (NATs) and Network Address and Port Translators (NAPTs) [RFC3022] in their networks. A key motivation for doing so is the depletion of available public IPv4 addresses. This document defines a Diameter application allowing providers to control the behavior of NAT and NAPT devices that implement IPv4-to-IPv4 network address and port translation [RFC2663] as well as stateful IPv6-to-IPv4 address family translation as defined in [RFC2663], [RFC6145], and [RFC6146]. The use of a Diameter application allows for simple integration into the existing Authentication, Authorization, and Accounting (AAA) environment of a provider.
インターネットサービスプロバイダーは、ネットワークにネットワークアドレストランスレーター（NAT）とネットワークアドレスおよびポートトランスレーター（NAPT）[RFC3022]を展開します。そうするための主な動機は、利用可能なパブリックIPv4アドレスの枯渇です。このドキュメントは、プロバイダーがIPv4-to-IPv4ネットワークアドレスとポート変換[RFC2663]と[RFC2663]で定義されているステートフルIPv6-to-IPv4アドレスファミリー変換を実装するNATおよびNAPTデバイスの動作を制御できるようにするDiameterアプリケーションを定義します、[RFC6145]、および[RFC6146]。 Diameterアプリケーションを使用すると、プロバイダーの既存の認証、承認、およびアカウンティング（AAA）環境に簡単に統合できます。
The Diameter Network address and port translation Control Application (DNCA) offers the following capabilities:
Diameterネットワークアドレスおよびポート変換制御アプリケーション（DNCA）は、次の機能を提供します。
1. Limits or defines the number of NAPT/NAT-bindings made available to an individual endpoint. The main motivation for restricting the number of bindings on a per-endpoint basis is to protect the service of the service provider against denial-of-service (DoS) attacks. If multiple endpoints share a single public IP address, these endpoints can share fate. If one endpoint would (either intentionally, or due to misbehavior, misconfiguration, malware, etc.) be able to consume all available bindings for a given single public IP address, service would be hampered (or might even become unavailable) for those other endpoints sharing the same public IP address. The efficiency of a NAPT deployment depends on the maximum number of bindings an endpoint could use. Given that the typical number of bindings an endpoint uses depends on the type of endpoint (e.g., a personal computer of a broadband user is expected to use a higher number of bindings than a simple mobile phone) and a NAPT device is often shared by different types of endpoints, it is desirable to actively manage the maximum number of bindings. This requirement is specified in REQ-3 of [CGN-REQS].
1. 個々のエンドポイントで利用できるNAPT / NATバインディングの数を制限または定義します。エンドポイントごとにバインディングの数を制限する主な動機は、サービスプロバイダーのサービスをサービス拒否（DoS）攻撃から保護することです。複数のエンドポイントが単一のパブリックIPアドレスを共有する場合、これらのエンドポイントは運命を共有できます。 1つのエンドポイントが（意図的に、または誤動作、設定ミス、マルウェアなどにより）、特定の単一のパブリックIPアドレスに対して利用可能なすべてのバインディングを消費できる場合、それらの他のエンドポイントのサービスは妨害されます（または利用できなくなることもあります）同じパブリックIPアドレスを共有します。 NAPT展開の効率は、エンドポイントが使用できるバインディングの最大数に依存します。エンドポイントが使用するバインディングの一般的な数はエンドポイントのタイプに依存し（たとえば、ブロードバンドユーザーのパーソナルコンピューターは単純な携帯電話よりも多くのバインディングを使用すると予想される）、NAPTデバイスは多くの場合、エンドポイントのタイプによっては、バインディングの最大数をアクティブに管理することが望ましいです。この要件は、[CGN-REQS]のREQ-3で指定されています。
2. Supports the allocation of specific NAPT/NAT-bindings. Two types of specific bindings can be distinguished:
2. 特定のNAPT / NATバインディングの割り当てをサポートします。 2つのタイプの特定のバインディングを区別できます。
* Allocation of a predefined NAT-binding: The internal and external IP addresses as well as the port pair are specified within the request. Some deployment cases, such as access to a web-server within a user's home network with IP address and port, benefit from statically configured bindings.
* 事前定義されたNATバインディングの割り当て：内部および外部IPアドレスとポートのペアは、リクエスト内で指定されます。 IPアドレスとポートを使用してユーザーのホームネットワーク内のWebサーバーにアクセスする場合など、一部の導入ケースでは、静的に構成されたバインディングが役立ちます。
* Allocation of an external IP address for a given internal IP address: The allocated external IP address is reported back to the requester. In some deployment scenarios, the application requires immediate knowledge of the allocated binding for a given internal IP address but does not control the allocation of the external IP address; for example, SIP-proxy server deployments.
* 特定の内部IPアドレスに対する外部IPアドレスの割り当て：割り当てられた外部IPアドレスは、リクエスタに報告されます。一部の展開シナリオでは、アプリケーションは特定の内部IPアドレスに割り当てられたバインディングの即時の知識を必要としますが、外部IPアドレスの割り当てを制御しません。たとえば、SIPプロキシサーバーの展開。
3. Defines the external address pool(s) to be used for allocating an external IP address: External address pools can be either pre-assigned at the NAPT/NAT device or specified within a request. If pre-assigned address pools are used, a request needs to include a reference to identify the pool. Otherwise, the request contains a description of the IP address pool(s) to be used, for example, a list of IP-subnets. Such external address pools can be used to select the external IP address in NAPT/NAT-bindings for multiple subscribers.
3. 外部IPアドレスの割り当てに使用する外部アドレスプールを定義します。外部アドレスプールは、NAPT / NATデバイスで事前に割り当てるか、要求内で指定できます。事前に割り当てられたアドレスプールを使用する場合、リクエストには、プールを識別するための参照を含める必要があります。それ以外の場合、要求には、使用するIPアドレスプールの説明（たとえば、IPサブネットのリスト）が含まれます。そのような外部アドレスプールを使用して、複数のサブスクライバのNAPT / NATバインディングで外部IPアドレスを選択できます。
4. Generates reports and accounting records: Reports established bindings for a particular endpoint. The collected information is used by accounting systems for statistical purposes.
4. レポートとアカウンティングレコードを生成します。特定のエンドポイントの確立されたバインディングをレポートします。収集された情報は、統計目的で会計システムによって使用されます。
5. Queries and retrieves details about bindings on demand: This feature complements the previously mentioned accounting functionality (see item 4). This feature can be used by an entity to find NAT-bindings belonging to one or multiple endpoints on the NAT device. The entity is not required to create a DNCA control session to perform the query but would, obviously, still need to create a Diameter session complying to the security requirements.
5. オンデマンドのバインディングに関する詳細を照会および取得します。この機能は、前述のアカウンティング機能を補完します（アイテム4を参照）。エンティティはこの機能を使用して、NATデバイス上の1つまたは複数のエンドポイントに属するNATバインディングを検索できます。エンティティは、クエリを実行するためにDNCAコントロールセッションを作成する必要はありませんが、明らかに、セキュリティ要件に準拠するDiameterセッションを作成する必要があります。
6. Identifies a subscriber or endpoint on multiple network devices (NAT/NAPT device, the AAA-server, or the Network Access Server (NAS)): Endpoint identification is facilitated through a Global Endpoint ID. Endpoints are identified through a single classifier or a set of classifiers, such as IP address, Virtual Local Area Network (VLAN) identifier, or interface identifier that uniquely identify the traffic associated with a particular global endpoint.
6. 複数のネットワークデバイス（NAT / NAPTデバイス、AAAサーバー、またはネットワークアクセスサーバー（NAS））上のサブスクライバーまたはエンドポイントを識別します。エンドポイントの識別は、グローバルエンドポイントIDによって容易になります。エンドポイントは、特定のグローバルエンドポイントに関連付けられたトラフィックを一意に識別する単一の分類子または一連の分類子（IPアドレス、仮想ローカルエリアネットワーク（VLAN）識別子、インターフェイス識別子など）によって識別されます。
With the above capabilities, DNCA qualifies as a Middlebox Communications (MIDCOM) protocol [RFC3303], [RFC3304], [RFC5189] for middleboxes that perform NAT. The MIDCOM protocol evaluation [RFC4097] evaluated Diameter as a candidate protocol for MIDCOM. DNCA provides the extensions to the Diameter base protocol [RFC6733] following the MIDCOM protocol requirements, such as the support of NAT-specific rule transport, support for oddity of mapped ports, as well as support for consecutive range port numbers. DNCA adds to the MIDCOM protocol capabilities in that it allows the maintenance of the reference to an endpoint representing a user or subscriber in the control operation, enabling the control of the behavior of a NAT device on a per-endpoint basis. Following the requirements of different operators and deployments, different management protocols are employed. Examples include, for example, Simple Network Management Protocol (SNMP) [RFC3411] and Network Configuration (NETCONF) [RFC6241], which can both be used for device configuration. Similarly, DNCA complements existing MIDCOM implementations, offering a MIDCOM protocol option for operators with an operational environment that is Diameter focused that desire the use of Diameter to perform per-endpoint NAT control. Note that in case an operator uses multiple methods and protocols to configure a NAT device, such as, for example, command line interface (CLI), SNMP, NETCONF, or Port Control Protocol (PCP), along with DNCA specified in this document, the operator MUST ensure that the configurations performed using the different methods and protocols do not conflict in order to ensure a proper operation of the NAT service.
上記の機能により、DNCAは、NATを実行するミドルボックスのミドルボックス通信（MIDCOM）プロトコル[RFC3303]、[RFC3304]、[RFC5189]として認定されます。 MIDCOMプロトコル評価[RFC4097]は、MIDCOMの候補プロトコルとしてDiameterを評価しました。 DNCAは、NAT固有のルールトランスポートのサポート、マップされたポートの奇数のサポート、連続した範囲のポート番号のサポートなど、MIDCOMプロトコル要件に従って、Diameter基本プロトコル[RFC6733]の拡張機能を提供します。 DNCAは、制御操作でユーザーまたはサブスクライバーを表すエンドポイントへの参照を維持できるという点でMIDCOMプロトコル機能に追加され、エンドポイントごとにNATデバイスの動作を制御できるようにします。さまざまなオペレーターと展開の要件に従って、さまざまな管理プロトコルが採用されています。例としては、たとえば、シンプルネットワーク管理プロトコル（SNMP）[RFC3411]とネットワーク構成（NETCONF）[RFC6241]があり、どちらもデバイス構成に使用できます。同様に、DNCAは既存のMIDCOM実装を補完し、Diameterを使用してエンドポイントごとのNAT制御を実行することを望むDiameterに重点を置いた運用環境のオペレーターにMIDCOMプロトコルオプションを提供します。オペレーターが複数の方法とプロトコルを使用して、コマンドラインインターフェース（CLI）、SNMP、NETCONF、ポートコントロールプロトコル（PCP）などのNATデバイスを、このドキュメントで指定されているDNCAとともに構成する場合、オペレーターは、NATサービスの適切な操作を保証するために、異なる方法とプロトコルを使用して実行された構成が競合しないことを確認する必要があります。
This document is structured as follows: Section 2 lists terminology, while Section 3 provides an introduction to DNCA and its overall deployment framework. Sections 3.2 to 8 cover DNCA specifics, with Section 3.2 describing session management, Section 5 the use of the Diameter base protocol, Section 6 new commands, Section 8 Attribute Value Pairs (AVPs) used, and Section 9 accounting aspects. Section 10 presents AVP occurrence tables. IANA and security considerations are addressed in Sections 11 and 12, respectively.
このドキュメントは次のように構成されています。セクション2は用語を示し、セクション3はDNCAとその全体的な導入フレームワークの概要を示します。セクション3.2から8はDNCAの詳細をカバーし、セクション3.2はセッション管理について説明し、セクション5はDiameter基本プロトコルの使用、セクション6は新しいコマンド、セクション8は属性値ペア（AVP）を使用し、セクション9はアカウンティングの側面を説明します。セクション10では、AVPオカレンステーブルを示します。 IANAとセキュリティの考慮事項については、それぞれセクション11と12で扱います。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Abbreviations and terminology used in this document:
このドキュメントで使用される略語と用語：
AAA: Authentication, Authorization, Accounting
AAA：認証、承認、アカウンティング
DNCA: Diameter Network address and port translation Control Application
DNCA：Diameterネットワークアドレスおよびポート変換制御アプリケーション
Endpoint: Managed entity of the DNCA. An endpoint represents a network element or device, associated with a subscriber, a user, or a group of users. An endpoint is represented by a single access-session on a NAS. DNCA assumes a 1:1 relationship between an endpoint, the access-session it represents, and the associated DNCA session.
エンドポイント：DNCAの管理対象エンティティ。エンドポイントは、加入者、ユーザー、またはユーザーのグループに関連付けられたネットワーク要素またはデバイスを表します。エンドポイントは、NAS上の単一のアクセスセッションによって表されます。 DNCAは、エンドポイント、エンドポイントが表すアクセスセッション、および関連するDNCAセッションの間の1対1の関係を想定しています。
NAPT: Network Address and Port Translation, see also [RFC3022].
NAPT：ネットワークアドレスとポート変換。[RFC3022]も参照してください。
NAT: Network Address Translation (NAT and NAPT are used in this document interchangeably)
NAT：ネットワークアドレス変換（このドキュメントでは、NATとNAPTは同じ意味で使用されています）
NAT-binding or binding: Association of two IP address/port pairs (with one IP address typically being private and the other one public) to facilitate NAT
NATバインディングまたはバインディング：NATを容易にするための2つのIPアドレス/ポートペアの関連付け（1つのIPアドレスは通常プライベートで、もう1つはパブリックです）
NAT-binding predefined template: A policy template or configuration that is predefined at the NAT device. It may contain NAT-bindings, IP address pools for allocating the external IP address of a NAT-binding, the maximum number of allowed NAT-bindings for endpoints, etc.
NATバインディングの事前定義テンプレート：NATデバイスで事前定義されたポリシーテンプレートまたは構成。これには、NATバインディング、NATバインディングの外部IPアドレスを割り当てるためのIPアドレスプール、エンドポイントに許可されるNATバインディングの最大数などが含まれる場合があります。
NAT device: Network Address Translator or Network Address and Port Translator: An entity performing NAT or NAPT.
NATデバイス：Network Address TranslatorまたはNetwork Address and Port Translator：NATまたはNAPTを実行するエンティティ。
NAT controller: Entity controlling the behavior of a NAT device.
NATコントローラ：NATデバイスの動作を制御するエンティティ。
NAS: Network Access Server
NAS：ネットワークアクセスサーバー
NCR: NAT-Control-Request
NCR：NAT-Control-Request
NCA: NAT-Control-Answer
NCA：NAT-Control-Answer
NAT44: IPv4-to-IPv4 NAPT, see [RFC2663]
NAT44：IPv4-to-IPv4 NAPT、[RFC2663]を参照
NAT64: IPv6-to-IPv4 address family translation, see [RFC6145] and [RFC6146]
NAT64：IPv6-to-IPv4アドレスファミリ変換、[RFC6145]および[RFC6146]を参照
PPP: Point-to-Point Protocol [RFC1661]
PPP：ポイントツーポイントプロトコル[RFC1661]
Figure 1 shows a typical network deployment for IPv4 Internet access. A user's IPv4 host (i.e., endpoint) gains access to the Internet though a NAS, which facilitates the authentication of the endpoint and configures the endpoint's connection according to the authorization and configuration data received from the AAA-server upon successful authentication. Public IPv4 addresses are used throughout the network. DNCA manages an endpoint that represents a network element or device or an IPv4 host, associated with a subscriber, a user or a group of users. An endpoint is represented by a single access-session on a NAS. DNCA assumes a 1:1:1 relationship between an endpoint, the access-session it represents, and the associated DNCA session.
図1は、IPv4インターネットアクセスの一般的なネットワーク配置を示しています。ユーザーのIPv4ホスト（つまり、エンドポイント）は、NASを介してインターネットにアクセスします。これにより、エンドポイントの認証が容易になり、認証が成功したときにAAAサーバーから受信した承認および構成データに従ってエンドポイントの接続が構成されます。パブリックIPv4アドレスはネットワーク全体で使用されます。 DNCAは、加入者、ユーザー、またはユーザーのグループに関連付けられたネットワーク要素またはデバイスまたはIPv4ホストを表すエンドポイントを管理します。エンドポイントは、NAS上の単一のアクセスセッションによって表されます。 DNCAは、エンドポイント、エンドポイントが表すアクセスセッション、および関連するDNCAセッションの間の1：1：1の関係を想定しています。
+---------+
| |
| AAA |
| |
+---------+
|
|
|
|
+---------+ +---------+ +----------+
| IPv4 | | | | IPv4 |
| Host |----------| NAS |-------------| Internet |
| | | | | |
+---------+ +---------+ +----------+
<-------------------- Public IPv4 ---------------------->
Figure 1: Typical Network Deployment for Internet Access
図1：インターネットアクセスの一般的なネットワーク配置
Figure 2 depicts the deployment scenario where a service provider places a NAT between the host and the public Internet. The objective is to provide the customer with connectivity to the public IPv4 Internet. The NAT device performs network address and port (and optionally address family) translation, depending on whether the access network uses private IPv4 addresses or public IPv6 addresses to public IPv4 addresses. Note that there may be more than one NAS, NAT device, or AAA-entity in a deployment, although the figures only depict one entity each for clarity.
図2は、サービスプロバイダーがホストとパブリックインターネットの間にNATを配置する展開シナリオを示しています。目的は、お客様にパブリックIPv4インターネットへの接続を提供することです。 NATデバイスは、アクセスネットワークがプライベートIPv4アドレスを使用するか、パブリックIPv6アドレスからパブリックIPv4アドレスへのパブリックIPv6アドレスを使用するかに応じて、ネットワークアドレスとポート（およびオプションでアドレスファミリ）変換を実行します。図ではわかりやすくするために1つのエンティティのみを示していますが、展開には複数のNAS、NATデバイス、またはAAAエンティティが存在する場合があることに注意してください。
If the NAT device would be put in place without any endpoint awareness, the service offerings of the service provider could be impacted as detailed in [CGN-REQS]. This includes cases like the following:
エンドポイントを認識せずにNATデバイスを配置すると、[CGN-REQS]で詳述されているように、サービスプロバイダーのサービス提供に影響が及ぶ可能性があります。これには、次のようなケースが含まれます。
o Provisioning static NAT-bindings for particular endpoints
o 特定のエンドポイントの静的NATバインディングのプロビジョニング
o Using different public IP address pools for a different set of endpoints (for example, residential or business customers)
o エンドポイントの異なるセット（たとえば、住宅または企業の顧客）に異なるパブリックIPアドレスプールを使用する
o Reporting allocated bindings on a per-endpoint basis
o 割り当てられたバインディングをエンドポイントごとに報告する
o Integrate control of the NAT device into the already existing per-endpoint management infrastructure of the service provider
o NATデバイスの制御を、サービスプロバイダーの既存のエンドポイントごとの管理インフラストラクチャに統合します。
+---------+
| |
| AAA |
| |
+---------+
|
|
|
|
+--------+ +---------+ +--------+ +----------+
| IPv4 |----| |----| NAT- |----| IPv4 |
| Host | | NAS | | device | | Internet |
| | | | | | | |
+--------+ +---------+ +--------+ +----------+
For NAT44 deployments (IPv4 host):
<----- Private IPv4 ----------><--- Public IPv4 --->
For NAT64 deployments (IPv6 host):
<----- Public IPv6 ----------><--- Public IPv4 --->
Figure 2: Access Network Deployment with NAT
図2：NATを使用したアクセスネットワークの配置
Figure 2 shows a typical deployment for IPv4 Internet access involving a NAT device within the service provider network. The figure describes two scenarios: one where an IPv4 host (with a private IPv4 address) accesses the IPv4 Internet, as well as one where an IPv6-host accesses the IPv4 Internet.
図2は、サービスプロバイダーネットワーク内のNATデバイスを含むIPv4インターネットアクセスの一般的な配置を示しています。この図は2つのシナリオを示しています。1つは（プライベートIPv4アドレスを持つ）IPv4ホストがIPv4インターネットにアクセスする場合、もう1つはIPv6ホストがIPv4インターネットにアクセスする場合です。
DNCA runs between two DNCA Diameter peers. One DNCA Diameter peer resides within the NAT device, the other DNCA Diameter peer resides within a NAT controller (discussed in Section 3.3). DNCA allows per-endpoint control and management of NAT within the NAT device. Based on Diameter, DNCA integrates well with the suite of Diameter applications deployed for per-endpoint authentication, authorization, accounting, and policy control in service provider networks.
DNCAは、2つのDNCA Diameterピア間で実行されます。 1つのDNCA DiameterピアはNATデバイス内にあり、もう1つのDNCA DiameterピアはNATコントローラ内にあります（セクション3.3で説明）。 DNCAは、NATデバイス内のNATのエンドポイントごとの制御と管理を可能にします。 Diameterに基づいて、DNCAは、サービスプロバイダーネットワークでのエンドポイントごとの認証、許可、アカウンティング、およびポリシー制御のために導入されたDiameterアプリケーションのスイートとうまく統合します。
DNCA offers:
DNCAが提供するもの：
o Request and answer commands to control the allowed number of NAT-bindings per endpoint, to request the allocation of specific bindings for an endpoint, to define the address pool to be used for an endpoint.
o エンドポイントごとに許可されるNATバインディングの数を制御し、エンドポイントに特定のバインディングの割り当てを要求し、エンドポイントに使用するアドレスプールを定義するための要求および応答コマンド。
o Per-endpoint reporting of the allocated NAT-bindings.
o 割り当てられたNATバインディングのエンドポイントごとのレポート。
o Unique identification of an endpoint on a NAT device, AAA-server, and NAS to simplify correlation of accounting data streams.
o NATデバイス、AAAサーバー、およびNAS上のエンドポイントの一意の識別により、アカウンティングデータストリームの相関を簡素化します。
DNCA allows controlling the behavior of a NAT device on a per-endpoint basis during initial session establishment and at later stages by providing an update procedure for already established sessions. Using DNCA, per-endpoint NAT-binding information can be retrieved using either accounting mechanisms or an explicit session query to the NAT.
DNCAは、すでに確立されたセッションの更新手順を提供することにより、初期セッション確立中および後の段階でエンドポイントごとにNATデバイスの動作を制御できます。 DNCAを使用すると、アカウンティングメカニズムまたはNATへの明示的なセッションクエリを使用して、エンドポイントごとのNATバインディング情報を取得できます。
DNCA can be deployed in different ways. DNCA supports deployments with "n" NAT controllers and "m" NAT devices, with n and m equal to or greater than 1. From a DNCA perspective, an operator should ensure that the session representing a particular endpoint is atomic. Any deployment MUST ensure that, for any given endpoint, only a single DNCA NAT controller and is active at any point in time. This is to ensure that NAT devices controlled by multiple NAT controllers do not receive conflicting control requests for a particular endpoint or that they would not be unclear about to which NAT controller to send accounting information. Operational considerations MAY require an operator to use alternate control mechanisms or protocols such as SNMP or manual configuration via a CLI to apply per-endpoint NAT-specific configuration, for example, static NAT-bindings. For these cases, the NAT device MUST allow the operator to configure a policy on how configuration conflicts are resolved. Such a policy could specify, for example, that manually configured NAT-bindings using the CLI always take precedence over those configured using DNCA.
DNCAはさまざまな方法で展開できます。 DNCAは、nおよびmが1以上の「n」NATコントローラーと「m」NATデバイスのデプロイメントをサポートします。DNCAの観点から、オペレーターは特定のエンドポイントを表すセッションがアトミックであることを確認する必要があります。どの展開でも、特定のエンドポイントについて、単一のDNCA NATコントローラーのみがあり、いつでもアクティブであることを確認する必要があります。これは、複数のNATコントローラーによって制御されるNATデバイスが特定のエンドポイントに対する競合する制御要求を受信しないようにするため、またはどのNATコントローラーにアカウンティング情報を送信するかが不明確にならないようにするためです。運用上の考慮事項は、オペレーターがエンドポイントごとのNAT固有の構成（静的NATバインディングなど）を適用するために、SNMPやCLIを介した手動構成などの代替制御メカニズムまたはプロトコルを使用することを要求する場合があります。これらの場合、NATデバイスは、構成の競合をどのように解決するかに関するポリシーをオペレーターが構成できるようにする必要があります。このようなポリシーは、たとえば、CLIを使用して手動で構成されたNATバインディングが常にDNCAを使用して構成されたものより優先されることを指定できます。
Two common deployment scenarios are outlined in Figure 3 ("Integrated Deployment") and Figure 4 ("Autonomous Deployment"). Per the note above, multiple instances of NAT controllers and NAT devices could be deployed. The figures only show single instances for reasons of clarity. The two shown scenarios differ in which entity fulfills the role of the NAT controller. Within the figures, (C) denotes the network element performing the role of the NAT controller.
2つの一般的な展開シナリオの概要を図3（「統合展開」）および図4（「自律展開」）に示します。上記の注記に従って、NATコントローラーとNATデバイスの複数のインスタンスを展開できます。図は、明確にするために単一のインスタンスのみを示しています。示されている2つのシナリオは、どのエンティティがNATコントローラの役割を果たしているかが異なります。図中の（C）は、NATコントローラーの役割を実行するネットワーク要素を示します。
The integrated deployment approach hides the existence of the NAT device from external servers, such as the AAA-server. It is suited for environments where minimal changes to the existing AAA deployment are desired. The NAS and the NAT device are Diameter peers supporting the DNCA. The Diameter peer within the NAS, performing the role of the NAT controller, initiates and manages sessions with the NAT device, exchanges NAT-specific configuration information, and handles reporting and accounting information. The NAS receives reporting and accounting information from the NAT device. With this information, the NAS can provide a single accounting record for the endpoint. A system correlating the accounting information received from the NAS and NAT device would not be needed.
統合された展開アプローチは、AAAサーバーなどの外部サーバーからNATデバイスの存在を隠します。これは、既存のAAA展開への最小限の変更が望まれる環境に適しています。 NASとNATデバイスは、DNCAをサポートするDiameterピアです。 NAS内のDiameterピアは、NATコントローラの役割を実行し、NATデバイスとのセッションを開始および管理し、NAT固有の構成情報を交換し、レポートおよびアカウンティング情報を処理します。 NASは、NATデバイスからレポートおよびアカウンティング情報を受信します。この情報を使用して、NASはエンドポイントに単一のアカウンティングレコードを提供できます。 NASとNATデバイスから受信したアカウンティング情報を関連付けるシステムは必要ありません。
An example network attachment for an integrated NAT deployment can be described as follows: an endpoint connects to the network, with the NAS being the point of attachment. After successful authentication, the NAS receives endpoint-related authorization data from the AAA-server. A portion of the authorization data applies to per-endpoint configuration on the NAS itself, another portion describes authorization and configuration information for NAT control aimed at the NAT device. The NAS initiates a DNCA session to the NAT device and sends relevant authorization and configuration information for the particular endpoint to the NAT device. This can comprise NAT-bindings, which have to be pre-established for the endpoint, or management-related configuration, such as the maximum number of NAT-bindings allowed for the endpoint. The NAT device sends its per-endpoint accounting information to the NAS, which aggregates the accounting information received from the NAT device with its local accounting information for the endpoint into a single accounting stream towards the AAA-server.
統合NAT展開のネットワーク接続の例は次のように説明できます。エンドポイントがネットワークに接続し、NASが接続のポイントになります。認証に成功すると、NASはAAAサーバーからエンドポイント関連の承認データを受信します。許可データの一部は、NAS自体のエンドポイントごとの構成に適用され、別の部分は、NATデバイスを対象としたNAT制御の許可および構成情報を記述します。 NASは、NATデバイスへのDNCAセッションを開始し、特定のエンドポイントの関連する承認および構成情報をNATデバイスに送信します。これには、エンドポイント用に事前に確立する必要があるNATバインディング、またはエンドポイントに許可されているNATバインディングの最大数などの管理関連の構成を含めることができます。 NATデバイスは、エンドポイントごとのアカウンティング情報をNASに送信します。NASは、NATデバイスから受信したアカウンティング情報を、エンドポイントのローカルアカウンティング情報とともに、AAAサーバーへの単一のアカウンティングストリームに集約します。
+---------+
| |
| AAA |
| |
+---------+
|
|
|
+--------+ +---------+ +--------+ +----------+
| | | (C) | | | | |
| Host |----| NAS |----| NAT- |----| IPv4 |
| | | | | device | | Internet |
+--------+ +---------+ +--------+ +----------+
For NAT44 deployments (IPv4 host):
<----- Private IPv4 ----------><--- Public IPv4 --->
For NAT64 deployments (IPv6 host):
<----- Public IPv6 ----------><--- Public IPv4 --->
Figure 3: NAT Control Deployment: Integrated Deployment
図3：NAT制御の展開：統合された展開
Figure 3 shows examples of integrated deployments. It illustrates two scenarios: one where an IPv4 host (with a private IPv4 address) accesses the IPv4 Internet and another where an IPv6 host accesses the IPv4 Internet.
図3は、統合された配置の例を示しています。これは2つのシナリオを示しています。1つはIPv4ホスト（プライベートIPv4アドレスを持つ）がIPv4インターネットにアクセスするもので、もう1つはIPv6ホストがIPv4インターネットにアクセスするものです。
The autonomous deployment approach decouples endpoint management on the NAS and NAT device. In the autonomous deployment approach, the AAA-system and the NAT device are the Diameter peers running the DNCA. The AAA-system also serves as NAT controller. It manages the connection to the NAT device, controls the per-endpoint configuration, and receives accounting and reporting information from the NAT device. Different from the integrated deployment scenario, the autonomous deployment scenario does not "hide" the existence of the NAT device from the AAA infrastructure. Here, two accounting streams are received by the AAA-server for one particular endpoint: one from the NAS and one from the NAT device.
自律展開アプローチは、NASおよびNATデバイスのエンドポイント管理を分離します。自律展開アプローチでは、AAAシステムとNATデバイスは、DNCAを実行するDiameterピアです。 AAAシステムはNATコントローラとしても機能します。 NATデバイスへの接続を管理し、エンドポイントごとの構成を制御し、NATデバイスからアカウンティングおよびレポート情報を受信します。統合展開シナリオとは異なり、自律展開シナリオでは、AAAインフラストラクチャからNATデバイスの存在を「隠す」ことはありません。ここでは、2つのアカウンティングストリームが1つの特定のエンドポイントのAAAサーバーによって受信されます。1つはNASから、もう1つはNATデバイスからです。
+---------+
| (C) |
| AAA |---------
| | |
+---------+ |
| |
| |
| |
+--------+ +---------+ +---------+ +----------+
| IPv4/ | | | | | | IPv4 |
| IPv6 |----| NAS |----| NAT- |----| Internet |
| Host | | | | device | | |
+--------+ +---------+ +---------+ +----------+
For NAT44 deployments (IPv4 host):
<----- Private IPv4 ----------><--- Public IPv4 --->
For NAT64 deployments (IPv6 host):
<----- Public IPv6 ----------><--- Public IPv4 --->
Figure 4: NAT Control Deployment: Autonomous Deployment
図4：NAT制御の展開：自律展開
Figure 4 shows examples of autonomous deployments. It illustrates two scenarios: one where an IPv4 host (with a private IPv4 address) accesses the IPv4 Internet and another where an IPv6 host accesses the IPv4 Internet.
図4は、自律展開の例を示しています。これは2つのシナリオを示しています。1つはIPv4ホスト（プライベートIPv4アドレスを持つ）がIPv4インターネットにアクセスするもので、もう1つはIPv6ホストがIPv4インターネットにアクセスするものです。
Note that from this section on, there are references to some of the commands and AVPs defined for DNCA. Please refer to Sections 6 and 8 for details. DNCA runs between a Diameter peer residing in a NAT controller and a Diameter peer residing in a NAT device. Note that, per what was already mentioned above, each DNCA session between Diameter peers in a NAT controller and a NAT device represents a single endpoint, with an endpoint being either a network element, a device, or an IPv4 host associated with a subscriber, a user, or a group of users. The Diameter peer within the NAT controller is always the control-requesting entity: it initiates, updates, or terminates the sessions. Sessions are initiated when the NAT controller learns about a new endpoint (i.e., host) that requires a NAT service. This could be due to, for example, the entity hosting the NAT controller receiving authentication, authorization, or accounting requests for or from the endpoint. Alternate methods that could trigger session setup include local configuration, receipt of a packet from a formerly unknown IP address, etc.
このセクション以降、DNCAに定義されたコマンドとAVPの一部への参照があることに注意してください。詳細については、セクション6および8を参照してください。 DNCAは、NATコントローラーにあるDiameterピアとNATデバイスにあるDiameterピアの間で実行されます。前述のとおり、NATコントローラーとNATデバイスのDiameterピア間の各DNCAセッションは単一のエンドポイントを表し、エンドポイントはネットワーク要素、デバイス、またはサブスクライバーに関連付けられたIPv4ホストのいずれかです。ユーザーまたはユーザーのグループ。 NATコントローラ内のDiameterピアは常に制御要求エンティティです。セッションを開始、更新、または終了します。セッションは、NATコントローラーが、NATサービスを必要とする新しいエンドポイント（つまり、ホスト）について学習したときに開始されます。これは、たとえば、NATコントローラーをホストしているエンティティが、エンドポイントに対する、またはエンドポイントからの認証、承認、またはアカウンティング要求を受信していることが原因である可能性があります。セッションのセットアップをトリガーする可能性のある代替方法には、ローカル構成、以前は不明だったIPアドレスからのパケットの受信などがあります。
The DNCA Diameter peer within the NAT controller establishes a session with the DNCA Diameter peer within the NAT device to control the behavior of the NAT function within the NAT device. During session establishment, the DNCA Diameter peer within the NAT controller passes along configuration information to the DNCA Diameter peer within the NAT device. The session configuration information comprises the maximum number of bindings allowed for the endpoint associated with this session, a set of predefined NAT-bindings to be established for this endpoint, or a description of the address pool, from which external addresses are to be allocated.
NATコントローラ内のDNCA Diameterピアは、NATデバイス内のDNCA Diameterピアとのセッションを確立して、NATデバイス内のNAT機能の動作を制御します。セッションの確立中に、NATコントローラー内のDNCA Diameterピアは、構成情報をNATデバイス内のDNCA Diameterピアに渡します。セッション構成情報は、このセッションに関連付けられたエンドポイントに許可されるバインディングの最大数、このエンドポイントに確立される事前定義されたNATバインディングのセット、または外部アドレスが割り当てられるアドレスプールの説明で構成されます。
The DNCA Diameter peer within the NAT controller generates a NAT-Control-Request (NCR) message to the DNCA Diameter peer within the NAT device with the NC-Request-Type AVP set to INITIAL_REQUEST to initiate a Diameter NAT control session. On receipt of an NCR, the DNCA Diameter peer within the NAT device sets up a new session for the endpoint associated with the endpoint classifier(s) contained in the NCR. The DNCA Diameter peer within the NAT device notifies its DNCA Diameter peer within the NAT controller about successful session setup using a NAT-Control-Answer (NCA) message with the Result-Code set to DIAMETER_SUCCESS. Figure 5 shows the initial protocol interaction between the two DNCA Diameter peers.
NATコントローラー内のDNCA Diameterピアは、NAT-Request-Type AVPをINITIAL_REQUESTに設定してNATデバイス内のDNCA DiameterピアにNAT-Control-Request（NCR）メッセージを生成し、Diameter NAT制御セッションを開始します。 NCRを受信すると、NATデバイス内のDNCA Diameterピアは、NCRに含まれるエンドポイント分類子に関連付けられたエンドポイントの新しいセッションをセットアップします。 NATデバイス内のDNCA Diameterピアは、Result-CodeがDIAMETER_SUCCESSに設定されたNAT-Control-Answer（NCA）メッセージを使用して、正常なセッションセットアップについて、NATコントローラー内のDNCA Diameterピアに通知します。図5は、2つのDNCA Diameterピア間の初期プロトコル相互作用を示しています。
The initial NAT-Control-Request MAY contain configuration information for the session, which specifies the behavior of the NAT device for the session. The configuration information that MAY be included, comprises:
最初のNAT-Control-Requestには、セッションのNATデバイスの動作を指定するセッションの構成情報が含まれる場合があります。含まれる可能性のある構成情報には、以下が含まれます。
o A list of NAT-bindings, which should be pre-allocated for the session; for example, in case an endpoint requires a fixed external IP address/port pair for an application.
o セッションに事前に割り当てる必要があるNATバインディングのリスト。たとえば、エンドポイントがアプリケーションに固定の外部IPアドレス/ポートのペアを必要とする場合。
o The maximum number of NAT-bindings allowed for an endpoint.
o エンドポイントに許可されるNATバインディングの最大数。
o A description of the external IP address pool(s) to be used for the session.
o セッションで使用される外部IPアドレスプールの説明。
o A reference to a NAT-binding Predefined template on the NAT device, which is applied to the session. Such a NAT-binding Predefined template on the NAT device may contain, for example, the name of the IP address pool from which external IP addresses should be allocated, the maximum number of bindings permitted for the endpoint, etc.
o セッションに適用される、NATデバイス上のNATバインディング事前定義テンプレートへの参照。 NATデバイス上のそのようなNATバインディング事前定義テンプレートには、たとえば、外部IPアドレスの割り当て元となるIPアドレスプールの名前、エンドポイントに許可されるバインディングの最大数などが含まれる場合があります。
In certain cases, the NAT device may not be able to perform the tasks requested within the NCR. These include the following:
場合によっては、NATデバイスはNCR内で要求されたタスクを実行できないことがあります。これらには以下が含まれます。
o If a DNCA Diameter peer within the NAT device receives an NCR from a DNCA Diameter peer within a NAT controller with the NC-Request-Type AVP set to INITIAL_REQUEST that identifies an already existing session, that is, the endpoint identifier matches an already existing session, the DNCA Diameter peer within the NAT device MUST return an NCA with the Result-Code set to SESSION_EXISTS and provide the Session-Id of the existing session in the Duplicate-Session-Id AVP.
o NATデバイス内のDNCA Diameterピアが、既存のセッションを識別するINITIAL_REQUESTに設定されたNC-Request-Type AVPを使用して、NATコントローラー内のDNCA DiameterピアからNCRを受信する場合、つまり、エンドポイント識別子が既存のセッションと一致する場合、NATデバイス内のDNCA Diameterピアは、Result-CodeをSESSION_EXISTSに設定してNCAを返し、既存のセッションのSession-IdをDuplicate-Session-Id AVPに提供する必要があります。
o If a DNCA Diameter peer within the NAT device receives an NCR from a DNCA Diameter peer within a NAT controller with the NC-Request-Type AVP set to INITIAL_REQUEST that matches more than one of the already existing sessions, that is, the DNCA Diameter peer and endpoint identifier match already existing sessions, the DNCA Diameter peer within the NAT device MUST return an NCA with the Result-Code set to INSUFFICIENT-CLASSIFIERS. In case a DNCA Diameter peer receives an NCA that reports Insufficient-Classifiers, it MAY choose to retry establishing a new session using additional or more specific classifiers.
o NATデバイス内のDNCA Diameterピアが、NC-Request-Type AVPがINITIAL_REQUESTに設定されたNATコントローラー内のDNCA DiameterピアからNCRを受信し、既存の複数のセッション、つまりDNCA Diameterピアと一致する場合エンドポイント識別子が既存のセッションと一致する場合、NATデバイス内のDNCA Diameterピアは、Result-CodeがINSUFFICIENT-CLASSIFIERSに設定されたNCAを返す必要があります。 DNCA DiameterピアがInsufficient-Classifiersを報告するNCAを受信した場合、追加またはより具体的な分類子を使用して新しいセッションの確立を再試行することを選択できます。
o If the NCR contains a NAT-binding Predefined template not defined on the NAT device, the DNCA Diameter peer within the NAT device MUST return an NCA with the Result-Code AVP set to UNKNOWN_BINDING_TEMPLATE_NAME.
o NCRに、NATデバイスで定義されていないNATバインディング事前定義テンプレートが含まれている場合、NATデバイス内のDNCA Diameterピアは、Result-Code AVPがUNKNOWN_BINDING_TEMPLATE_NAMEに設定されたNCAを返す必要があります。
o In case the NAT device is unable to establish all of the bindings requested in the NCR, the DNCA Diameter peer MUST return an NCA with the Result-Code set to BINDING_FAILURE. A DNCA Diameter peer within a NAT device MUST treat an NCR as an atomic operation; hence, none of the requested bindings will be established by the NAT device. Either all requested actions within an NCR MUST be completed successfully or the entire request fails.
o NATデバイスがNCRで要求されたすべてのバインディングを確立できない場合、DNCA Diameterピアは、Result-CodeをBINDING_FAILUREに設定してNCAを返す必要があります。 NATデバイス内のDNCA Diameterピアは、NCRをアトミック操作として扱う必要があります。したがって、要求されたバインディングはどれもNATデバイスによって確立されません。 NCR内で要求されたすべてのアクションが正常に完了する必要があるか、要求全体が失敗します。
o If a NAT device cannot conform to a request to set the maximum number of NAT-bindings allowed for a session, the DNCA Diameter peer in the NAT device MUST return an NCA with the Result-Code AVP set to MAX_BINDINGS_SET_FAILURE. Such a condition can, for example, occur if the operator specified the maximum number of NAT-bindings through another mechanism, which, per the operator's policy, takes precedence over DNCA.
o NATデバイスがセッションに許可されたNATバインディングの最大数を設定する要求に準拠できない場合、NATデバイスのDNCA Diameterピアは、Result-Code AVPがMAX_BINDINGS_SET_FAILUREに設定されたNCAを返す必要があります。このような状況は、たとえば、オペレーターのポリシーに従ってDNCAよりも優先される別のメカニズムを通じてオペレーターがNATバインディングの最大数を指定した場合に発生する可能性があります。
o If a NAT device does not have sufficient resources to process a request, the DNCA Diameter peer MUST return an NCA with the Result-Code set to RESOURCE_FAILURE.
o NATデバイスに要求を処理するための十分なリソースがない場合、DNCA Diameterピアは、Result-CodeがRESOURCE_FAILUREに設定されたNCAを返さなければなりません（MUST）。
o In the case where Max-NAT-Bindings, NAT-Control-Definition, and NAT-Control-Binding-Template are included in the NCR, and the values in Max-NAT-Bindings and NAT-Control-Definition contradict those specified in the pre-provisioned template on the NAT device that NAT-Control-Binding-Template references, Max-NAT-Bindings and NAT-Control-Definition MUST override the values specified in the template to which NAT-Control-Binding-Template refers.
o Max-NAT-Bindings、NAT-Control-Definition、NAT-Control-Binding-TemplateがNCRに含まれており、Max-NAT-BindingsとNAT-Control-Definitionの値が、 NAT-Control-Binding-Templateが参照するNATデバイスで事前にプロビジョニングされたテンプレート、Max-NAT-BindingsおよびNAT-Control-Definitionは、NAT-Control-Binding-Templateが参照するテンプレートで指定された値をオーバーライドする必要があります。
NAT controller (DNCA Diameter peer) NAT device (DNCA Diameter peer)
| |
| |
| |
Trigger |
| |
| NCR |
|------------------------------------------>|
| |
| |
| |
| |
| If able to comply
| with request, then
| create session state
| |
| |
| NCA |
|<------------------------------------------|
| |
| |
Figure 5: Initial NAT-Control-Request and Session Establishment
図5：最初のNAT-Control-Requestとセッションの確立
Note: The DNCA Diameter peer within the NAT device creates session state only if it is able to comply with the NCR. On success, it will reply with an NCA with the Result-Code set to DIAMETER_SUCCESS.
注：NATデバイス内のDNCA Diameterピアは、NCRに準拠できる場合にのみセッション状態を作成します。成功すると、結果コードがDIAMETER_SUCCESSに設定されたNCAで応答します。
A session update is performed if the NAT controller desires to change the behavior of the NAT device for an existing session. A session update could be used, for example, to change the number of allowed bindings for a particular session or establish or remove a predefined binding.
NATコントローラーが既存のセッションのNATデバイスの動作を変更する場合は、セッションの更新が実行されます。セッションの更新は、たとえば、特定のセッションで許可されているバインディングの数を変更したり、事前定義されたバインディングを確立または削除したりするために使用できます。
The DNCA Diameter peer within the NAT controller generates an NCR message to the DNCA Diameter peer within the NAT device with the NC-Request-Type AVP set to UPDATE_REQUEST upon receiving a trigger signal. If the session is updated successfully, the DNCA Diameter peer within the NAT device notifies the DNCA Diameter peer within the NAT controller about the successful session update using a NAT-Control-Answer (NCA) message with the Result-Code set to DIAMETER_SUCCESS. Figure 6 shows the protocol interaction between the two DNCA Diameter peers.
NATコントローラー内のDNCA Diameterピアは、トリガー信号を受信すると、NC-Request-Type AVPがUPDATE_REQUESTに設定された、NATデバイス内のDNCA DiameterピアへのNCRメッセージを生成します。セッションが正常に更新されると、NATデバイス内のDNCA Diameterピアは、Result-CodeがDIAMETER_SUCCESSに設定されたNAT-Control-Answer（NCA）メッセージを使用して、正常なセッション更新についてNATコントローラ内のDNCA Diameterピアに通知します。図6は、2つのDNCA Diameterピア間のプロトコル相互作用を示しています。
In certain cases, the NAT device may not be able to perform the tasks requested within the NCR. These include the following:
場合によっては、NATデバイスはNCR内で要求されたタスクを実行できないことがあります。これらには以下が含まれます。
o If a DNCA Diameter peer within a NAT device receives an NCR update or query request for a non-existent session, it MUST set the Result-Code in the answer to DIAMETER_UNKNOWN_SESSION_ID.
o NATデバイス内のDNCA Diameterピアが、存在しないセッションのNCR更新またはクエリ要求を受信した場合、DIAMETER_UNKNOWN_SESSION_IDへの応答にResult-Codeを設定する必要があります。
o If the NCR contains a NAT-binding Predefined template not defined on the NAT device, an NCA with the Result-Code AVP set to UNKNOWN_BINDING_TEMPLATE_NAME MUST be returned.
o NCRに、NATデバイスで定義されていないNATバインディング事前定義テンプレートが含まれている場合、Result-Code AVPがUNKNOWN_BINDING_TEMPLATE_NAMEに設定されたNCAが返される必要があります。
o If the NAT device cannot establish the requested binding because the maximum number of allowed bindings has been reached for the endpoint classifier, an NCA with the Result-Code AVP set to MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT MUST be returned to the DNCA Diameter peer.
o エンドポイント分類子で許可されているバインディングの最大数に達したために、NATデバイスが要求されたバインディングを確立できない場合、Result-Code AVPがMAXIMUM_BINDINGS_REACHED_FOR_ENDPOINTに設定されたNCAをDNCA Diameterピアに返す必要があります。
o If the NAT device cannot establish some or all of the bindings requested in an NCR, but has not yet reached the maximum number of allowed bindings for the endpoint, an NCA with the Result-Code set to BINDING_FAILURE MUST be returned. As already noted, the DNCA Diameter peer in a NAT device MUST treat an NCR as an atomic operation. Hence, none of the requested bindings will be established by the NAT device in case of failure. Actions requested within an NCR are either all successful or all fail.
o NATデバイスがNCRで要求されたバインディングの一部またはすべてを確立できないが、エンドポイントに許可されているバインディングの最大数にまだ達していない場合、Result-CodeがBINDING_FAILUREに設定されたNCAを返さなければなりません。すでに述べたように、NATデバイスのDNCA Diameterピアは、NCRをアトミック操作として扱う必要があります。したがって、障害が発生した場合、要求されたバインディングはいずれもNATデバイスによって確立されません。 NCR内で要求されたアクションは、すべて成功するか、すべて失敗します。
o If the NAT device cannot conform to a request to set the maximum number of bindings allowed for a session as specified by the Max-NAT-Bindings, the DNCA Diameter peer in the NAT device MUST return an NCA with the Result-Code AVP set to MAX_BINDINGS_SET_FAILURE.
o NATデバイスが、Max-NAT-Bindingsで指定されたセッションに許可されたバインディングの最大数を設定する要求に準拠できない場合、NATデバイスのDNCA Diameterピアは、Result-Code AVPが設定されたNCAを返さなければなりません（MUST）。 MAX_BINDINGS_SET_FAILURE。
o If the NAT device does not have sufficient resources to process a request, an NCA with the Result-Code set to RESOURCE_FAILURE MUST be returned.
o NATデバイスにリクエストを処理するための十分なリソースがない場合、Result-CodeがRESOURCE_FAILUREに設定されたNCAを返さなければなりません（MUST）。
o If an NCR changes the maximum number of NAT-bindings allowed for the endpoint defined through an earlier NCR, the new value MUST override any previously defined limit on the maximum number of NAT-bindings set through the DNCA. Note that, prior to overwriting an existing value, the NAT device MUST check whether the overwrite action conforms to the locally configured policy. Deployment dependent, an existing value could have been set by a protocol or mechanism different from DNCA and with higher priority. In which case, the NAT device will refuse the change and the DNCA Diameter peer in the NAT device MUST return an NCA with the Result-Code AVP set to MAX_BINDINGS_SET_FAILURE. It depends on the implementation of the NAT device on how the NAT device copes with a case where the new value is lower than the actual number of allocated bindings. The NAT device SHOULD refrain from enforcing the new limit immediately (that is, actively remove bindings), but rather disallows the establishment of new bindings until the current number of bindings is lower than the newly established maximum number of allowed bindings.
o NCRが以前のNCRを通じて定義されたエンドポイントに許可されたNATバインディングの最大数を変更する場合、新しい値は、DNCAを通じて設定されたNATバインディングの最大数に対して以前に定義された制限をオーバーライドする必要があります。 NATデバイスは、既存の値を上書きする前に、上書きアクションがローカルに構成されたポリシーに準拠しているかどうかを確認する必要があることに注意してください。展開に依存します。既存の値は、DNCAとは異なる、より高い優先度のプロトコルまたはメカニズムによって設定される可能性があります。その場合、NATデバイスは変更を拒否し、NATデバイスのDNCA Diameterピアは、結果コードAVPがMAX_BINDINGS_SET_FAILUREに設定されたNCAを返す必要があります。新しい値が実際に割り当てられたバインディングの数よりも少ない場合にNATデバイスがどのように対処するかは、NATデバイスの実装によって異なります。 NATデバイスは、新しい制限をすぐに適用すること（つまり、バインディングをアクティブに削除すること）を控える必要があります（ただし、現在のバインディング数が新しく確立された許可されたバインディングの最大数を下回るまで、新しいバインディングの確立を拒否します）。
o If an NCR specifies a new NAT-binding Predefined template on the NAT device, the NAT-binding Predefined template overrides any previously defined rule for the session. Existing NAT-bindings SHOULD NOT be impacted by the change of templates.
o NCRがNATデバイスで新しいNATバインディング事前定義テンプレートを指定する場合、NATバインディング事前定義テンプレートは、セッションに対して以前に定義されたルールを上書きします。既存のNATバインディングは、テンプレートの変更の影響を受けてはなりません（SHOULD NOT）。
o In case Max-NAT-Bindings, NAT-Control-Definition, and NAT-Control-Binding-Template are included in the NCR, and the values in Max-NAT-Bindings and NAT-Control-Definition contradict those specified in the pre-provisioned template on the NAT device that NAT-Control-Binding-Template references, Max-NAT-Bindings and NAT-Control-Definition MUST override the values specified in the template to which the NAT-Control-Binding-Template refers.
o Max-NAT-Bindings、NAT-Control-Definition、NAT-Control-Binding-TemplateがNCRに含まれており、Max-NAT-BindingsとNAT-Control-Definitionの値が事前に指定された値と矛盾する場合NAT-Control-Binding-Templateが参照するNATデバイスでプロビジョニングされたテンプレート、Max-NAT-Bindings、およびNAT-Control-Definitionは、NAT-Control-Binding-Templateが参照するテンプレートで指定された値をオーバーライドする必要があります。
Note: Already established bindings for the session SHOULD NOT be affected in case the tasks requested within the NCR cannot be completed.
注：NCR内で要求されたタスクを完了できない場合に備えて、セッションに対してすでに確立されているバインディングは影響を受けるべきではありません（SHOULD NOT）。
NAT controller (DNCA Diameter peer) NAT device (DNCA Diameter peer)
| |
| |
| |
Change of session |
attributes |
| |
| NCR |
|------------------------------------------>|
| |
| |
| If able to comply
| with the request:
| update session state
| |
| |
| NCA |
|<------------------------------------------|
| |
Figure 6: NAT-Control-Request for Session Update
図6：セッション更新のNAT-Control-Request
A session and NAT-binding query MAY be used by the DNCA Diameter peer within the NAT controller either to retrieve information on the current bindings for a particular session at the NAT device or to discover the session identifier for a particular external IP address/ port pair.
セッションおよびNATバインディングクエリは、NATデバイス内の特定のセッションの現在のバインディングに関する情報を取得するか、特定の外部IPアドレス/ポートペアのセッション識別子を検出するために、NATコントローラー内のDNCA Diameterピアによって使用される場合があります。
A DNCA Diameter peer within the NAT controller starts a session query by sending an NCR message with NC-Request-Type AVP set to QUERY_REQUEST. Figure 7 shows the protocol interaction between the DNCA Diameter peers.
NATコントローラ内のDNCA Diameterピアは、NC-Request-Type AVPがQUERY_REQUESTに設定されたNCRメッセージを送信することにより、セッションクエリを開始します。図7は、DNCA Diameterピア間のプロトコル相互作用を示しています。
Two types of query requests exist. The first type of query request uses the Session-Id as input parameter to the query. It is to allow the DNCA Diameter peer within the NAT controller to retrieve the current set of bindings for a specific session. The second type of query request is used to retrieve the session identifiers, along with the associated bindings, matching a criteria. This enables the DNCA Diameter peer within the NAT controller to find those sessions, which utilize a specific external or internal IP address.
2種類のクエリ要求が存在します。最初のタイプのクエリ要求は、Session-Idをクエリへの入力パラメーターとして使用します。これは、NATコントローラー内のDNCA Diameterピアが特定のセッションの現在のバインディングセットを取得できるようにするためです。 2番目のタイプのクエリ要求は、基準に一致する、関連付けられたバインディングとともにセッション識別子を取得するために使用されます。これにより、NATコントローラー内のDNCA Diameterピアは、特定の外部または内部IPアドレスを利用するセッションを見つけることができます。
1. Request a list of currently allocated NAT-bindings for a particular session: On receiving an NCR, the NAT device SHOULD look up the session information for the Session-Id contained in the NCR and report all currently active NAT-bindings for the session using an NCA message with the Result-Code set to DIAMETER_SUCCESS. In this case, the NCR MUST NOT contain a NAT-Control-Definition AVP. Each NAT-binding is reported in a NAT-Control-Definition AVP. In case the Session-Id is unknown, the DNCA Diameter peer within the NAT device MUST return an NCA message with the Result-Code set to DIAMETER_UNKNOWN_SESSION_ID.
1.特定のセッションに現在割り当てられているNATバインディングのリストを要求します。NCRを受信すると、NATデバイスはNCRに含まれているセッションIDのセッション情報を検索し、そのセッションに対して現在アクティブなすべてのNATバインディングを報告する必要があります（SHOULD）。 Result-CodeがDIAMETER_SUCCESSに設定されたNCAメッセージを使用する。この場合、NCRはNAT-Control-Definition AVPを含んではいけません（MUST NOT）。各NATバインディングは、NAT-Control-Definition AVPで報告されます。 Session-Idが不明の場合、NATデバイス内のDNCA Diameterピアは、Result-CodeがDIAMETER_UNKNOWN_SESSION_IDに設定されたNCAメッセージを返す必要があります。
2. Retrieve Session-Ids and bindings for internal IP address or one or multiple external IP address/port pairs: If the DNCA Diameter peer within the NAT controller wishes to retrieve the Session-Id(s) for an internal IP address or one or multiple external IP address/port pairs, it MUST include the internal IP address as part of the Framed-IP-Address AVP or external IP address/port pair(s) as part of the NAT-External-Address AVP of the NCR. The external IP address/port pair(s) are known in advance by the controller via configuration, AAA interactions, or other means. The Session-Id is not included in the NCR or the NCA for this type of a query. The DNCA Diameter peer within the NAT device SHOULD report the NAT-bindings and associated Session-Ids corresponding to the internal IP address or external IP address/ port pairs in an NCA message using one or multiple instances of the NAT-Control-Definition AVP. The Result-Code is set to DIAMETER_SUCCESS. In case an external IP address/port pair has no associated existing NAT-binding, the NAT-Control-Definition AVP contained in the reply just contains the NAT-External-Address AVP.
2. 内部IPアドレスまたは1つまたは複数の外部IPアドレス/ポートペアのセッションIDおよびバインディングを取得します。NATコントローラー内のDNCA Diameterピアが内部IPアドレスまたは1つまたは複数の外部のセッションIDを取得する場合IPアドレス/ポートのペア。これには、Framed-IP-Address AVPの一部として内部IPアドレス、またはNCRのNAT-External-Address AVPの一部として外部IPアドレス/ポートペアを含める必要があります。外部IPアドレスとポートのペアは、設定、AAAの相互作用、またはその他の手段によって、コントローラによって事前に認識されています。セッションIDは、このタイプのクエリのNCRまたはNCAには含まれていません。 NATデバイス内のDNCA Diameterピアは、NAT-Control-Definition AVPの1つまたは複数のインスタンスを使用して、NCAメッセージ内の内部IPアドレスまたは外部IPアドレス/ポートのペアに対応するNATバインディングおよび関連するセッションIDを報告する必要があります（SHOULD）。 Result-CodeはDIAMETER_SUCCESSに設定されます。外部IPアドレスとポートのペアに既存のNATバインディングが関連付けられていない場合、応答に含まれるNAT-Control-Definition AVPには、NAT-External-Address AVPのみが含まれます。
NAT controller (DNCA Diameter peer) NAT device (DNCA Diameter peer)
| |
| |
| |
DNCA Session Established |
| |
| NCR |
|------------------------------------------>|
| |
| |
| |
| |
| Look up corresponding session
| and associated NAT-bindings
| |
| NCA |
|<------------------------------------------|
| |
| |
| |
Figure 7: Session Query
図7：セッションクエリ
Similar to session initiation, session tear down MUST be initiated by the DNCA Diameter peer within the NAT controller. The DNCA Diameter peer sends a Session-Termination-Request (STR) message to its peer within the NAT device upon receiving a trigger signal. The source of the trigger signal is outside the scope of this document. As part of STR-message processing, the DNCA Diameter peer within the NAT device MAY send an accounting stop record reporting all bindings. All the NAT-bindings belonging to the session MUST be removed, and the session state MUST be cleaned up. The DNCA Diameter peer within the NAT device MUST notify its DNCA Diameter peer in the NAT controller about successful session termination using a Session-Termination-Answer (STA) message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the protocol interaction between the two DNCA Diameter peers.
セッションの開始と同様に、セッションの破棄は、NATコントローラー内のDNCA Diameterピアによって開始されなければなりません（MUST）。 DNCA Diameterピアは、トリガー信号を受信すると、NATデバイス内のピアにSession-Termination-Request（STR）メッセージを送信します。トリガー信号のソースは、このドキュメントの範囲外です。 STRメッセージ処理の一部として、NATデバイス内のDNCA Diameterピアは、すべてのバインディングを報告するアカウンティング停止レコードを送信できます（MAY）。セッションに属するすべてのNATバインディングを削除する必要があり、セッション状態をクリーンアップする必要があります。 NATデバイス内のDNCA Diameterピアは、Result-CodeがDIAMETER_SUCCESSに設定されたSession-Termination-Answer（STA）メッセージを使用して、セッションが正常に終了したことをNATコントローラのDNCA Diameterピアに通知する必要があります。図8は、2つのDNCA Diameterピア間のプロトコル相互作用を示しています。
If a DNCA Diameter peer within a NAT device receives an STR and fails to find a matching session, the DNCA Diameter peer MUST return an STA with the Result-Code set to DIAMETER_UNKNOWN_SESSION_ID.
NATデバイス内のDNCA DiameterピアがSTRを受信し、一致するセッションを見つけられなかった場合、DNCA Diameterピアは、Result-CodeがDIAMETER_UNKNOWN_SESSION_IDに設定されたSTAを返す必要があります。
NAT controller (DNCA Diameter peer) NAT device (DNCA Diameter peer)
| |
| |
Trigger |
| |
| STR |
|------------------------------------------->|
| |
| |
| |
| |
| |
| Send accounting stop |
|<-------------------------------------------|
| reporting all session bindings |
| |
| |
| Remove NAT-bindings
| of session
| |
| Terminate session /
| Remove session state
| |
| |
| |
| STA |
|<-------------------------------------------|
| |
| |
Figure 8: Terminate NAT Control Session
図8：NAT制御セッションの終了
An Abort-Session-Request (ASR) message is sent from the DNCA Diameter peer within the NAT device to the DNCA Diameter peer within the NAT controller when it is unable to maintain a session due to resource limitations. The DNCA Diameter peer within the NAT controller MUST acknowledge a successful session abort using an Abort-Session-Answer (ASA) message with the Result-Code set to DIAMETER_SUCCESS. Figure 9 shows the protocol interaction between the DNCA Diameter peers. The DNCA Diameter peers will start a session termination procedure as described in Section 4.4 following an ASA with the Result-Code set to DIAMETER_SUCCESS.
リソースの制限によりセッションを維持できない場合、Abort-Session-Request（ASR）メッセージは、NATデバイス内のDNCA DiameterピアからNATコントローラ内のDNCA Diameterピアに送信されます。 NATコントローラ内のDNCA Diameterピアは、Result-CodeがDIAMETER_SUCCESSに設定されたAbort-Session-Answer（ASA）メッセージを使用して、成功したセッションアボートを確認する必要があります。図9は、DNCA Diameterピア間のプロトコル相互作用を示しています。 DNCA Diameterピアは、結果コードがDIAMETER_SUCCESSに設定されたASAに続くセクション4.4で説明されているように、セッション終了手順を開始します。
If the DNCA Diameter peer within a NAT controller receives an ASR but fails to find a matching session, it MUST return an ASA with the Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. If the DNCA Diameter peer within the NAT controller is unable to comply with the ASR for any other reason, an ASA with the Result-Code set to DIAMETER_UNABLE_TO_COMPLY MUST be returned.
NATコントローラー内のDNCA DiameterピアがASRを受信しても、一致するセッションを見つけることができない場合は、結果コードをDIAMETER_UNKNOWN_SESSION_IDに設定してASAを返す必要があります。 NATコントローラー内のDNCA Diameterピアが他の理由でASRに準拠できない場合は、Result-CodeがDIAMETER_UNABLE_TO_COMPLYに設定されたASAを返す必要があります。
NAT controller (DNCA Diameter peer) NAT device (DNCA Diameter peer)
| |
| |
| Trigger
| |
| ASR |
|<-------------------------------------------|
| |
| |
| |
| ASA |
|------------------------------------------->|
| |
| |
| |
| On successful ASA |
|<------Session Termination Procedure------->|
Figure 9: Abort NAT Control Session
図9：NAT制御セッションの中止
This document does not specify the behavior in case the NAT device and NAT controller, or their respective DNCA Diameter peers, are out of sync or lose state. This could happen, for example, if one of the entities restarts, in case of a (temporary) loss of network connectivity, etc. Example failure cases include the following:
このドキュメントでは、NATデバイスとNATコントローラ、またはそれぞれのDNCA Diameterピアが同期していないか、状態が失われた場合の動作については説明していません。これは、たとえば、エンティティの1つが再起動した場合、ネットワーク接続が（一時的に）失われた場合などに発生する可能性があります。障害の例としては、次のものがあります。
o NAT controller and the DNCA Diameter peer within the NAT controller lose state (e.g., due to a restart). In this case:
o NATコントローラーと、NATコントローラー内のDNCA Diameterピアが状態を失います（たとえば、再起動のため）。この場合：
* the DNCA Diameter peer within the NAT device MAY receive an NCR with the NC-Request-Type AVP set to INITIAL_REQUEST that matches an existing session of the DNCA Diameter peer within the NAT device. The DNCA Diameter peer within the NAT device MUST return a Result-Code that contains a Duplicate-Session-Id AVP to report the Session-Id of the existing session. The DNCA Diameter peer within the NAT controller MAY send an explicit Session-Termination-Request (STR) for the older session, which was lost.
* NATデバイス内のDNCA Diameterピアは、NATデバイス内のDNCA Diameterピアの既存のセッションと一致するINITIAL_REQUESTに設定されたNC-Request-Type AVPでNCRを受信する場合があります。 NATデバイス内のDNCA Diameterピアは、既存のセッションのSession-Idを報告するために、Duplicate-Session-Id AVPを含むResult-Codeを返す必要があります。 NATコントローラ内のDNCA Diameterピアは、失われた古いセッションの明示的なSession-Termination-Request（STR）を送信できます（MAY）。
* a DNCA Diameter peer MAY receive accounting records for a session that does not exist. The DNCA Diameter peer sends an accounting answer with the Result-Code set to DIAMETER_UNKNOWN_SESSION_ID in response. On receiving the response, the DNCA Diameter peer SHOULD clear the session and remove associated session state.
* DNCA Diameterピアは、存在しないセッションのアカウンティングレコードを受信する場合があります。 DNCA Diameterピアは、応答として、結果コードをDIAMETER_UNKNOWN_SESSION_IDに設定したアカウンティング応答を送信します。応答を受信すると、DNCA Diameterピアはセッションをクリアし、関連するセッション状態を削除する必要があります（SHOULD）。
o The NAT device and the DNCA Diameter peer within NAT device lose state. In such a case, the DNCA Diameter peer MAY receive an NCR with the NC-Request-Type AVP set to UPDATE_REQUEST for a non-existent session. The DNCA Diameter peer MUST return an NCA with the Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. When a DNCA application within a NAT controller receives this NCA with the Result-Code set to DIAMETER_UNKNOWN_SESSION_ID, it MAY try to re-establish DNCA session or disconnect corresponding access session.
o NATデバイスおよびNATデバイス内のDNCA Diameterピアは状態を失います。このような場合、DNCA Diameterピアは、存在しないセッションに対して、NC-Request-Type AVPがUPDATE_REQUESTに設定されたNCRを受信する場合があります。 DNCA Diameterピアは、Result-CodeがDIAMETER_UNKNOWN_SESSION_IDに設定されたNCAを返す必要があります。 NATコントローラ内のDNCAアプリケーションが、Result-CodeがDIAMETER_UNKNOWN_SESSION_IDに設定されたこのNCAを受信すると、DNCAセッションの再確立または対応するアクセスセッションの切断を試行する場合があります。
o The DNCA Diameter peer within the NAT controller is unreachable, for example, it is detected by Diameter device watchdog messages (as defined in Section 5.5 of [RFC6733]) or accounting requests from the DNCA Diameter peer fail to get a response, NAT-bindings and NAT device state pertaining to that session MUST be cleaned up after a grace period that is configurable on the NAT device. The grace period can be configured as zero or higher, depending on operator preference.
o NATコントローラー内のDNCA Diameterピアに到達できません。たとえば、Diameterデバイスウォッチドッグメッセージ（[RFC6733]のセクション5.5で定義）によって検出されるか、DNCA Diameterピアからのアカウンティング要求が応答を取得できない、NATバインディングまた、そのセッションに関連するNATデバイスの状態は、NATデバイスで構成可能な猶予期間後にクリーンアップする必要があります。猶予期間は、オペレーターの好みに応じて、ゼロ以上に構成できます。
o The DNCA Diameter peer within the NAT device is unreachable or down and the NCR fails to get a response. Handling of this case depends on the actual service offering of the service provider. The service provider could, for example, choose to stop offering connectivity service.
o NATデバイス内のDNCA Diameterピアに到達できないかダウンしており、NCRが応答を取得できません。このケースの処理は、サービスプロバイダーの実際のサービス提供に依存します。たとえば、サービスプロバイダーは、接続サービスの提供を停止することを選択できます。
o A discussion of the mechanisms used for a NAT device to clean up state in case the DNCA Diameter peer within the NAT device crashes is outside the scope of this document. Implementers of NAT devices could choose from a variety of options such as coupling the state (e.g., NAT-bindings) to timers that require periodic refresh, or time out otherwise, operating system watchdogs for applications, etc.
o NATデバイス内のDNCA Diameterピアがクラッシュした場合にNATデバイスが状態をクリーンアップするために使用されるメカニズムの説明は、このドキュメントの範囲外です。 NATデバイスの実装者は、状態（NATバインディングなど）を定期的な更新を必要とするタイマーに結合するなどのさまざまなオプションから選択するか、それ以外の場合はタイムアウトして、アプリケーションのオペレーティングシステムウォッチドッグなどを選択できます。
The Diameter base protocol [RFC6733] applies with the clarifications listed in the present specification.
Diameter基本プロトコル[RFC6733]は、本仕様に記載されている説明に適用されます。
For secure transport of Diameter messages, the recommendations in [RFC6733] apply.
Diameterメッセージを安全に転送するには、[RFC6733]の推奨事項が適用されます。
DNCA Diameter peers SHOULD verify their identity during the Capabilities Exchange Request procedure.
DNCA Diameterピアは、ケイパビリティー交換リクエスト手順の間にアイデンティティを検証する必要があります。
A DNCA Diameter peer within the NAT device SHOULD verify that a DNCA Diameter peer that issues an NCR command is allowed to do so based on:
NATデバイス内のDNCA Diameterピアは、NCRコマンドを発行するDNCA Diameterピアが以下に基づいて許可されていることを確認する必要があります（SHOULD）。
o The identity of the DNCA Diameter peer
o DNCA DiameterピアのID
o The type of NCR Command
o NCRコマンドのタイプ
o The content of the NCR Command
o NCRコマンドの内容
o Any combination of the above
o 上記の任意の組み合わせ
Accounting functionality (the accounting session state machine, related Command Codes and AVPs) is defined in Section 9.
アカウンティング機能（アカウンティングセッションステートマシン、関連するコマンドコードおよびAVP）は、セクション9で定義されています。
Each DNCA session MUST have a globally unique Session-Id, as defined in [RFC6733], which MUST NOT be changed during the lifetime of the DNCA session. The Diameter Session-Id serves as the global endpoint identifier. The DNCA Diameter peers maintain state associated with the Session-Id. This globally unique Session-Id is used for updating, accounting, and terminating the session. A DNCA session MUST NOT have more than one outstanding request at any given time. A DNCA Diameter peer sends an Abort-Session-Request as defined in [RFC6733] if it is unable to maintain sessions due to resource limitation.
各DNCAセッションは、[RFC6733]で定義されているように、グローバルに一意のセッションIDを持たなければならず（MUST）、DNCAセッションの存続期間中に変更してはなりません。 DiameterセッションIDは、グローバルエンドポイント識別子として機能します。 DNCA Diameterピアは、Session-Idに関連付けられた状態を維持します。このグローバルに一意のSession-Idは、セッションの更新、アカウンティング、および終了に使用されます。 DNCAセッションには、常に複数の未処理の要求があってはなりません。 DNCA Diameterピアは、リソースの制限によりセッションを維持できない場合、[RFC6733]で定義されているAbort-Session-Requestを送信します。
It is assumed that the DNCA Diameter peer within a NAT controller knows the DiameterIdentity of the Diameter peer within a NAT device for a given endpoint. Both the Destination-Realm and Destination-Host AVPs are present in the request from a DNCA Diameter peer within a NAT controller to a DNCA Diameter peer within a NAT device.
NATコントローラ内のDNCA Diameterピアは、特定のエンドポイントのNATデバイス内のDiameterピアのDiameterIdentityを知っていると想定されています。宛先レルムと宛先ホストAVPの両方が、NATコントローラー内のDNCA DiameterピアからNATデバイス内のDNCA Diameterピアへの要求に存在します。
Diameter nodes conforming to this specification MUST advertise support for DNCA by including the value of 12 in the Auth-Application-Id of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [RFC6733].
この仕様に準拠するDiameterノードは、Capabilities-Exchange-RequestコマンドとCapabilities-Exchange-AnswerコマンドのAuth-Application-Idに値12を含めることにより、DNCAのサポートを通知しなければなりません[RFC6733]。
The following commands are used to establish, maintain, and query NAT-bindings.
次のコマンドは、NATバインディングを確立、維持、および照会するために使用されます。
The NAT-Control-Request (NCR) command, indicated by the command field set to 330 and the 'R' bit set in the Command Flags field, is sent from the DNCA Diameter peer within the NAT controller to the DNCA Diameter peer within the NAT device in order to install NAT-bindings.
330に設定されたコマンドフィールドとコマンドフラグフィールドに設定された「R」ビットで示されるNAT-Control-Request（NCR）コマンドは、NATコントローラー内のDNCA DiameterピアからDN内のDNCA Diameterピアに送信されます。 NATバインディングをインストールするためのNATデバイス。
User-Name, Logical-Access-Id, Physical-Access-ID, Framed-IP-Address, Framed-IPv6-Prefix, Framed-Interface-Id, EGRESS-VLANID, NAS-Port-ID, Address-Realm, and Calling-Station-ID AVPs serve as identifiers for the endpoint.
ユーザー名、論理アクセスID、物理アクセスID、フレーム化IPアドレス、フレーム化IPv6-プレフィックス、フレーム化インターフェースID、EGRESS-VLANID、NASポートID、アドレス領域、および呼び出し-Station-ID AVPは、エンドポイントの識別子として機能します。
Message format:
< NC-Request > ::= < Diameter Header: 330, REQ, PXY>
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ NC-Request-Type }
[ Session-Id ]
[ Origin-State-Id ]
*1 [ NAT-Control-Remove ]
*1 [ NAT-Control-Install ]
[ NAT-External-Address ]
[ User-Name ]
[ Logical-Access-Id ]
[ Physical-Access-ID ]
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
[ Framed-Interface-Id ]
[ EGRESS-VLANID]
[ NAS-Port-ID]
[ Address-Realm ]
[ Calling-Station-ID ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The NAT-Control-Answer (NCA) command, indicated by the Command Code field set to 330 and the 'R' bit cleared in the Command Flags field, is sent by the DNCA Diameter peer within the NAT device in response to the NAT-Control-Request command.
コマンドコードフィールドが330に設定され、コマンドフラグフィールドの「R」ビットがクリアされていることで示されるNAT-Control-Answer（NCA）コマンドは、NAT-に応答して、NATデバイス内のDNCA Diameterピアによって送信されます。 Control-Requestコマンド。
Message format:
<NC-Answer> ::= < Diameter Header: 330, PXY >
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
[ Session-Id ]
[ NC-Request-Type ]
* [ NAT-Control-Definition ]
[ Current-NAT-Bindings ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
* [ Proxy-Info ]
[ Duplicate-Session-Id ]
* [ Redirect-Host]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ Failed-AVP ]
* [ AVP ]
This section contains a set of finite state machines, representing the life cycle of a DNCA session, which MUST be observed by all implementations of the DNCA Diameter application. The DNCA Diameter peers are stateful and the state machine maintained is similar to the stateful client and server authorization state machine described in [RFC6733]. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered an error condition, and an answer, if applicable, MUST be returned to the originator of the message.
このセクションには、DNCAセッションのライフサイクルを表す一連の有限状態マシンが含まれています。これは、DNCA Diameterアプリケーションのすべての実装で監視する必要があります。 DNCA Diameterピアはステートフルであり、維持されるステートマシンは、[RFC6733]で説明されているステートフルクライアントおよびサーバー認証ステートマシンに似ています。セッションがアイドル状態に移行すると、特定のセッションに割り当てられていたすべてのリソースを解放する必要があります。状態マシンにリストされていないイベントは、エラー状態と見なされなければならず、該当する場合は、メッセージの発信者に応答が返されなければなりません（MUST）。
In the state table, the event "Failure to send NCR" means that the DNCA Diameter peer within the NAT controller is unable to send the NCR command to the desired destination. This could be due to the peer being down or due to the peer sending back the transient failure or temporary protocol error notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the Result-Code AVP of an NCA.
状態テーブルでは、「NCRの送信に失敗しました」というイベントは、NATコントローラー内のDNCA DiameterピアがNCRコマンドを目的の宛先に送信できないことを意味します。これは、ピアがダウンしているか、ピアが一時的な障害またはNCAのResult-Code AVPの一時的なプロトコルエラー通知DIAMETER_TOO_BUSYまたはDIAMETER_LOOP_DETECTEDを送り返していることが原因である可能性があります。
In the state table, "FAILED NCA" means that the DNCA Diameter peer within the NAT device was not able to honor the corresponding NCR. This can happen due to any transient or permanent error at the NAT device or its associated DNCA Diameter peer within indicated by the following error Result-Code values: RESOURCE_FAILURE, UNKNOWN_BINDING_TEMPLATE_NAME, MAX_BINDINGS_SET_FAILURE, BINDING_FAILURE, MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT, SESSION_EXISTS, INSUFFICIENT_CLASSIFIERS.
状態テーブルで、「FAILED NCA」は、NATデバイス内のDNCA Diameterピアが対応するNCRを受け入れることができなかったことを意味します。これは、NATデバイスまたはそれに関連するDNCA Diameterピアでの一時的または永続的なエラーが原因で発生する可能性があります。次のエラーResult-Code値で示されます：RESOURCE_FAILURE、UNKNOWN_BINDING_TEMPLATE_NAME、MAX_BINDINGS_SET_FAILURE、BINDING_FAILURE、MAXIMUM_BINDINGS_REACHED_FOR_ENDPOISTS、SESSION_SESSION_
The following state machine is observed by a DNCA Diameter peer within a NAT controller. The state machine description uses the term "access session" to describe the connectivity service offered to the endpoint or host. "Access session" should not be confused with the Diameter session.
次の状態マシンは、NATコントローラー内のDNCA Diameterピアによって監視されます。ステートマシンの説明では、「アクセスセッション」という用語を使用して、エンドポイントまたはホストに提供される接続サービスを説明しています。 「アクセスセッション」とDiameterセッションを混同しないでください。
DNCA Diameter peer within a NAT controller
State Event Action New State
-------------------------------------------------------------
Idle New endpoint detected that Send Pending
requires NAT control NCR
Initial
Request
Idle ASR received Send ASA Idle for unknown session with Result-Code = UNKNOWN_ SESSION_ID
アイドルASRが、結果コード= UNKNOWN_ SESSION_IDの不明なセッションの送信ASAアイドルを受信しました
Pending Successful NCA Setup Open received complete
保留中の成功したNCAセットアップオープンを受け取りました
Pending Successful NCA Send STR Discon received, but peer unable to provide service
保留中の成功したNCA送信STR Disconを受信しましたが、ピアはサービスを提供できません
Pending Error processing successful Send STR Discon NCA
保留中のエラー処理が正常に送信STR Discon NCA
Pending Failed Clean up Idle NCA received
保留中の失敗したクリーンアップアイドルNCAの受信
Open NAT control Send Open update required NCR update request Open Successful Open NCA received
オープンNAT制御を送信オープン更新が必要NCR更新要求を送信オープン成功オープンNCAを受信
Open Failed Clean up Idle NCA received
オープン失敗したクリーンアップアイドルNCAを受信
Open Access session end detected Send STR Discon
オープンアクセスセッションの終了が検出されましたSTR Disconを送信します
Open ASR received, Send ASA Discon access session will be with terminated Result-Code = SUCCESS, Send STR
開いたASRを受信し、ASA Disconアクセスセッションを送信すると、終了したResult-Code = SUCCESS、STRを送信します
Open ASR received, Send ASA Open access session will not with be terminated Result-Code != SUCCESS
オープンASRを受信しました。ASAオープンアクセスセッションを送信すると、終了しませんResult-Code！= SUCCESS
Discon ASR Received Send ASA Idle
Discon ASR受信送信ASAアイドル
Discon STA Received Discon. Idle endpoint
Discon STAがDisconを受け取りました。アイドルエンドポイント
The following state machine is observed by a DNCA Diameter peer within a NAT device.
次の状態マシンは、NATデバイス内のDNCA Diameterピアによって監視されます。
DNCA Diameter peer within a NAT device
State Event Action New State
-------------------------------------------------------------
Idle NCR query request Send Idle
received, and successful
able to provide requested NCA
NAT-binding report
Idle NCR received Send Open and able to successful provide requested NCA NAT control service
アイドルNCRはSend Openを受信し、要求されたNCA NAT制御サービスを正常に提供できます
Idle NCR request Send Idle received, and failed unable to provide requested NCA NAT control service
アイドルNCR要求送信アイドルが受信され、要求されたNCA NAT制御サービスを提供できませんでした
Open NCR request Send Open received, and successful able to provide requested NCA NAT control service
Open NCRリクエストSend Openを受信し、リクエストされたNCA NAT制御サービスを提供することに成功
Open NCR request Send Idle received, and failed unable to provide requested NCA, NAT control service Clean up
オープンNCR要求の送信アイドルを受信し、要求されたNCA、NAT制御サービスのクリーンアップを提供できませんでした
Open Unable to continue Send ASR Discon providing requested NAT control service
Open続行できません要求されたNAT制御サービスを提供するASR Disconを送信します
Open Unplanned loss of session/ Clean up Idle connection to DNCA Diameter peer in NAT controller detected (e.g., due to Diameter watchdog notification)
予期しないセッションの切断を開く/ NATコントローラー内のDNCA Diameterピアへのアイドル接続をクリーンアップ検出（たとえば、Diameterウォッチドッグ通知による）
Discon Failure to send ASR Wait, Discon resend ASR
DisconはASR待機の送信に失敗し、DisconはASRを再送信します
Discon ASR successfully sent and Clean up Idle ASA received with Result-Code
Discon ASRは正常に送信され、結果コードでアイドルASAをクリーンアップしました
Not ASA received None No change Discon
ASAを受信しないなし変更なしDiscon
Any STR received Send STA, Idle Clean up
STRを受信したら、STAを送信し、アイドルクリーンアップします。
The following table describes the AVPs reused from the Diameter base protocol [RFC6733]; their AVP Code values, types, and possible flag values and whether the AVP MAY be encrypted. [RFC6733] specifies the AVP Flag rules for AVPs in Section 4.5. The Diameter AVP rules are defined in [RFC6733], Section 4.
次の表は、Diameter基本プロトコル[RFC6733]から再利用されたAVPを示しています。それらのAVPコード値、タイプ、および可能なフラグ値と、AVPが暗号化されるかどうか。 [RFC6733]は、セクション4.5でAVPのAVPフラグルールを指定します。 Diameter AVPルールは、[RFC6733]のセクション4で定義されています。
+---------+
| AVP |
| Flag |
| rules |
+-----------------------------------------------|-----+---+---------+
| AVP | | | |
| Attribute Name Code Data Type |MUST |MAY| Encr |
+-----------------------------------------------+-----+---+---------+
|Acct-Interim-Interval 85 Unsigned32 | M | P | Y |
|Auth-Application-Id 258 Unsigned32 | M | P | N |
|Destination-Host 293 DiamIdent | M | P | N |
|Destination-Realm 283 DiamIdent | M | P | N |
|Error-Message 281 UTF8String | M | P | N |
|Error-Reporting-Host 294 DiamIdent | M | P | N |
|Failed-AVP 279 Grouped | M | P | N |
|Origin-Host 264 DiamIdent | M | P | N |
|Origin-Realm 296 DiamIdent | M | P | N |
|Origin-State-Id 278 Unsigned32 | M | P | N |
|Proxy-Info 284 Grouped | M | P | N |
|Result-Code 268 Unsigned32 | M | P | N |
|Route-Record 282 DiamIdent | M | | N |
|Session-Id 263 UTF8String | M | P | Y |
|User-Name 1 UTF8String | M | P | Y |
+-----------------------------------------------+-----+---+---------+
Table 1: DIAMETER AVPs from the Diameter Base Protocol
The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to Diameter applications. The value of the Auth-Application-Id for the Diameter NAT Control Application is 12. Please refer to [RFC6733] for the definition of the Diameter AVP flag rules and the associated abbreviations used in the table.
Auth-Application-Id AVP（AVPコード258）は、IANAによってDiameterアプリケーションに割り当てられます。 Diameter NAT制御アプリケーションのAuth-Application-Idの値は12です。DiameterAVPフラグルールの定義と、表で使用されている関連する略語については、[RFC6733]を参照してください。
This section defines new values for the Result-Code AVP that SHALL be supported by all Diameter implementations that conform to the present document.
このセクションでは、現在のドキュメントに準拠するすべてのDiameter実装でサポートされる必要があるResult-Code AVPの新しい値を定義します。
No new Result-Code AVP value is defined within this category.
このカテゴリ内では、新しいResult-Code AVP値は定義されていません。
Result-Code AVP values that fall within the transient failures category are those used to inform a peer that the request could not be satisfied at the time that it was received. The request may be able to be satisfied in the future.
一時的な障害のカテゴリに含まれるResult-Code AVP値は、要求が受信されたときに要求が満たされなかったことをピアに通知するために使用される値です。将来的にはご要望にお応えできるかもしれません。
The following new values of the Result-Code AVP are defined:
Result-Code AVPの次の新しい値が定義されています。
RESOURCE_FAILURE (4014)
RESOURCE_FAILURE（4014）
The DNCA Diameter peer within the NAT device indicates that the binding could not be installed or a new session could not be created due to resource shortage.
NATデバイス内のDNCA Diameterピアは、バインディングがインストールできなかったか、リソース不足のために新しいセッションを作成できなかったことを示しています。
The Result-Code AVP values, which fall within the permanent failures category are used to inform the peer that the request failed and should not be attempted again. The request may be able to be satisfied in the future.
永続的な失敗のカテゴリに含まれるResult-Code AVP値は、リクエストが失敗したことをピアに通知するために使用されます。将来的にはご要望にお応えできるかもしれません。
The following new values of the Result-Code AVP are defined:
Result-Code AVPの次の新しい値が定義されています。
UNKNOWN_BINDING_TEMPLATE_NAME (5042)
UNKNOWN_BINDING_TEMPLATE_NAME（5042）
The DNCA Diameter peer within the NAT device indicates that the binding could not be installed or a new session could not be created because the specified NAT-Control-Binding-Template AVP, which refers to a predefined policy template in the NAT device, is unknown.
NATデバイス内の事前定義されたポリシーテンプレートを参照する指定されたNAT-Control-Binding-Template AVPが不明であるため、NATデバイス内のDNCA Diameterピアがバインディングをインストールできなかったか、新しいセッションを作成できなかったことを示しています。
BINDING_FAILURE (5043)
BINDING_FAILURE（5043）
The DNCA Diameter peer within the NAT device indicates that the requested binding(s) could not be installed. For example, Requested ports are already in use.
NATデバイス内のDNCA Diameterピアが、要求されたバインディングをインストールできなかったことを示しています。たとえば、要求されたポートはすでに使用されています。
MAX_BINDINGS_SET_FAILURE (5044)
MAX_BINDINGS_SET_FAILURE（5044）
The DNCA Diameter peer within the NAT device indicates that it failed to conform to a request to configure the maximum number of bindings for a session. For example, an operator defined the maximum number of bindings on the NAT device using a method or protocol that takes precedence over DNCA.
NATデバイス内のDNCA Diameterピアは、セッションのバインディングの最大数を構成する要求に準拠できなかったことを示しています。たとえば、オペレーターは、DNCAよりも優先されるメソッドまたはプロトコルを使用して、NATデバイス上のバインディングの最大数を定義しました。
MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT (5045)
MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT（5045）
The DNCA Diameter peer within the NAT device denies the request because the maximum number of allowed bindings has been reached for the specified endpoint classifier.
指定されたエンドポイント分類子で許可されているバインディングの最大数に達したため、NATデバイス内のDNCA Diameterピアは要求を拒否します。
SESSION_EXISTS (5046)
SESSION_EXISTS（5046）
The DNCA Diameter peer within the NAT device denies a request to initialize a new session, if it already has a DNCA session that uses the same set of classifiers as indicated by the DNCA Diameter peer within the NAT controller in the new session initialization request.
NATデバイス内のDNCA Diameterピアは、新しいセッション初期化要求のNATコントローラー内のDNCA Diameterピアによって示されるのと同じ分類子のセットを使用するDNCAセッションをすでに持っている場合、新しいセッションを初期化する要求を拒否します。
INSUFFICIENT_CLASSIFIERS (5047)
INSUFFICIENT_CLASSIFIERS（5047）
The DNCA Diameter peer within the NAT device requests to initialize a new session, if the classifiers in the request match more than one of the existing sessions on the DNCA Diameter peer within the NAT device.
NATデバイス内のDNCA Diameterピアは、要求内の分類子がNATデバイス内のDNCA Diameterピア上の既存のセッションの複数と一致する場合、新しいセッションを初期化するよう要求します。
The following table describes the AVPs reused from the Diameter
Network Access Server Application [RFC4005]; their AVP Code values,
types, and possible flag values; and whether the AVP MAY be
encrypted. The [RFC6733] specifies the AVP Flag rules for AVPs in
Section 4.5. The Diameter AVP rules are defined in the [RFC6733],
Section 4.
+---------------------+
| AVP Flag Rules |
+------------------+------+------------|----+-----+----+-----|----+
| | AVP | | | |SHLD| MUST| |
| Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr|
|------------------|------|------------|----+-----+----+-----|----|
| NAS-Port | 5 | Unsigned32 | M | P | | V | Y |
| NAS-Port-Id | 87 | UTF8String | M | P | | V | Y |
| Calling-Station- | 31 | UTF8String | M | P | | V | Y |
| Id | | | | | | | |
| Framed-IP-Address| 8 | OctetString| M | P | | V | Y |
| Framed-Interface-| 96 | Unsigned64 | M | P | | V | Y |
| Id | | | | | | | |
| Framed-IPv6- | 97 | OctetString| M | P | | V | Y |
| Prefix | | | | | | | |
+------------------+------+------------|----+-----+----+-----|----+
Table 2: Reused NASREQ Diameter application AVPs. Please refer to
[RFC6733] for the definition of the Diameter AVP Flag rules and the
associated abbreviations used in the table.
The following table describes the AVPs reused from "RADIUS Attributes
for Virtual LAN and Priority Support" [RFC4675]; their AVP Code
values, types, and possible flag values; and whether the AVP MAY be
encrypted. [RFC6733] specifies the AVP Flag rules for AVPs in
Section 4.5. The Diameter AVP rules are defined in [RFC6733],
Section 4.
+---------------------+
| AVP Flag Rules |
+------------------+------+------------|----+-----+----+-----|----+
| | AVP | | | |SHLD| MUST| |
| Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr|
|------------------|------|------------|----+-----+----+-----|----|
| Egress-VLANID | 56 | OctetString| M | P | | V | Y |
+------------------+------+------------|----+-----+----+-----|----+
Table 3: Reused attributes from [RFC4675]. Please refer to [RFC6733]
for the definition of the Diameter AVP Flag rules and the associated
abbreviations used in the table.
The following table describes the AVPs reused from the "Traffic
Classification and Quality of Service (QoS) Attributes for Diameter"
[RFC5777]; their AVP Code values, types, and possible flag values;
and whether the AVP MAY be encrypted. [RFC6733] specifies the AVP
Flag rules for AVPs in Section 4.5. The Diameter AVP rules are
defined in [RFC6733], Section 4.
+---------+
| AVP |
| Flag |
| Rules |
+-----------------------------------------------|-----+---+---------+
| AVP | | | |
| Attribute Name Code Data Type |MUST |MAY| Encr |
+-----------------------------------------------+-----+---+---------+
|Port 530 Integer32 | M | P | Y |
|Protocol 513 Enumerated | M | P | Y |
|Direction 514 Enumerated | M | P | Y |
+-----------------------------------------------+-----+---+---------+
Table 4: Reused QoS-attributes. Please refer to [RFC6733] for the definition of the Diameter AVP Flag rules and the associated abbreviations used in the table.
表4：再利用されるQoS属性。表で使用されているDiameter AVPフラグルールと関連する略語の定義については、[RFC6733]を参照してください。
The following table describes the AVPs reused from the Diameter e4 Application [ETSIES283034]; their AVP Code values, types, and possible flag values; and whether the AVP MAY be encrypted. [RFC6733] specifies the AVP Flag rules for AVPs in Section 4.5. The Diameter AVP rules are defined in [RFC6733], Section 4. The Vendor-ID field in these AVP header will be set to ETSI (13019).
次の表は、Diameter e4アプリケーション[ETSIES283034]から再利用されるAVPを示しています。それらのAVPコード値、タイプ、および可能なフラグ値。 AVPを暗号化できるかどうか。 [RFC6733]は、セクション4.5でAVPのAVPフラグルールを指定します。 Diameter AVPルールは、[RFC6733]のセクション4で定義されています。これらのAVPヘッダーのVendor-IDフィールドは、ETSI（13019）に設定されます。
+---------+
| AVP |
| Flag |
| Rules |
+-----------------------------------------------|-----+---+---------+
| AVP | | | |
| Attribute Name Code Data Type |MUST |MAY| Encr |
+-----------------------------------------------+-----+---+---------+
|Address-Realm 301 OctetString | M,V | | Y |
|Logical-Access-Id 302 OctetString | V | M | Y |
|Physical-Access-ID 313 UTF8String | V | M | Y |
+-----------------------------------------------+-----+---+---------+
Table 5: Reused AVPs from the Diameter e4 application. Please refer to [RFC6733] for the definition of the Diameter AVP Flag rules and the associated abbreviations used in the table.
表5：Diameter e4アプリケーションからの再利用されたAVP。表で使用されているDiameter AVPフラグルールと関連する略語の定義については、[RFC6733]を参照してください。
The following table describes the new Diameter AVPs defined in this document; their AVP Code values, types, and possible flag values; and whether the AVP MAY be encrypted. [RFC6733] specifies the AVP Flag rules for AVPs in Section 4.5. The Diameter AVP rules are defined in [RFC6733], Section 4. The AVPs defined here MUST NOT have the 'V' bit in the AVP Flags field set.
次の表は、このドキュメントで定義されている新しいDiameter AVPを示しています。それらのAVPコード値、タイプ、および可能なフラグ値。 AVPを暗号化できるかどうか。 [RFC6733]は、セクション4.5でAVPのAVPフラグルールを指定します。 Diameter AVPルールは[RFC6733]のセクション4で定義されています。ここで定義されたAVPは、AVPフラグフィールドセットに「V」ビットがあってはなりません。
+---------+
| AVP |
| Flag |
| Rules |
+--------------------------------------------------|-----+---+------+
| AVP | | | |
| Attribute Name Code Sect. Data Type |MUST |MAY| Encr |
+--------------------------------------------------+-----+---+------+
|NC-Request-Type 595 8.7.1 Enumerated | M | P | Y |
|NAT-Control-Install 596 8.7.2 Grouped | M | P | Y |
|NAT-Control-Remove 597 8.7.3 Grouped | M | P | Y |
|NAT-Control-Definition 598 8.7.4 Grouped | M | P | Y |
|NAT-Internal-Address 599 8.7.5 Grouped | M | P | Y |
|NAT-External-Address 600 8.7.6 Grouped | M | P | Y |
|Max-NAT-Bindings 601 8.7.7 Unsigned32 | M | P | Y |
|NAT-Control- 602 8.7.8 OctetString| M | P | Y |
| Binding-Template | | | |
|Duplicate- 603 8.7.9 UTF8String | M | P | Y |
| Session-Id | | | |
|NAT-External-Port- 604 8.7.10 Enumerated | M | P | Y |
| Style | | | |
|NAT-Control-Record 605 9.2.1 Grouped | M | P | Y |
|NAT-Control- 606 9.2.2 Enumerated | M | P | Y |
| Binding-Status | | | |
|Current-NAT-Bindings 607 9.2.3 Unsigned32 | M | P | Y |
+--------------------------------------------------+-----+---+------+
Table 6: New Diameter AVPs. Please refer to [RFC6733] for the definition of the Diameter AVP Flag rules and the associated abbreviations used in the table.
表6：新しいDiameter AVP。表で使用されているDiameter AVPフラグルールと関連する略語の定義については、[RFC6733]を参照してください。
The NC-Request-Type AVP (AVP Code 595) is of type Enumerated and contains the reason for sending the NAT-Control-Request command. It shall be present in all NAT-Control-Request messages.
NC-Request-Type AVP（AVPコード595）は列挙型であり、NAT-Control-Requestコマンドを送信する理由が含まれています。これは、すべてのNAT-Control-Requestメッセージに存在する必要があります。
The following values are defined:
以下の値が定義されています。
INITIAL_REQUEST (1)
INITIAL_REQUEST（1）
An Initial Request is to initiate a Diameter NAT control session between the DNCA Diameter peers.
最初の要求は、DNCA Diameterピア間でDiameter NAT制御セッションを開始することです。
UPDATE_REQUEST (2)
UPDATE_REQUEST（2）
An Update Request is used to update bindings previously installed on a given access session, to add new binding on a given access session, or to remove one or several binding(s) activated on a given access session.
更新リクエストは、特定のアクセスセッションに以前にインストールされたバインディングを更新する、特定のアクセスセッションに新しいバインディングを追加する、または特定のアクセスセッションでアクティブ化された1つまたは複数のバインディングを削除するために使用されます。
QUERY_REQUEST (3)
QUERY_REQUEST（3）
Query Request is used to query a NAT device about the currently installed bindings for an endpoint classifier.
クエリ要求は、エンドポイント分類子の現在インストールされているバインディングについてNATデバイスにクエリを実行するために使用されます。
The NAT-Control-Install AVP (AVP code 596) is of type Grouped, and it is used to activate or install NAT-bindings. It also contains Max-NAT-Bindings that defines the maximum number of NAT-bindings allowed for an endpoint and the NAT-Control-Binding-Template that references a predefined template on the NAT device that may contain static binding, a maximum number of bindings allowed, an IP address pool from which external binding addresses should be allocated, etc. If the NAT-External-Port-Style AVP is present, then the NAT device MUST select the external ports for the NAT-bindings, per the style specified. The NAT-External-Port-Style is applicable for NAT-bindings defined by the NAT-Control-Definition AVPs whose NAT-External-Address or Port AVPs within the NAT-External-Address are unspecified.
NAT-Control-Install AVP（AVPコード596）はグループ化されたタイプであり、NATバインディングをアクティブ化またはインストールするために使用されます。また、エンドポイントに許可されるNATバインディングの最大数を定義するMax-NAT-Bindingsと、静的バインディング、最大数のバインディングを含む可能性のあるNATデバイス上の事前定義されたテンプレートを参照するNAT-Control-Binding-Templateも含まれています。許可、外部バインディングアドレスの割り当て元となるIPアドレスプールなど。NAT-External-Port-StyleAVPが存在する場合、NATデバイスは、指定されたスタイルに従って、NATバインディング用の外部ポートを選択する必要があります。 NAT-External-Port-Styleは、NAT-External-AddressまたはNAT-External-Address内のポートAVPが指定されていないNAT-Control-Definition AVPによって定義されたNATバインディングに適用できます。
AVP format:
NAT-Control-Install ::= < AVP Header: 596 >
* [ NAT-Control-Definition ]
[ NAT-Control-Binding-Template ]
[ Max-NAT-Bindings ]
[ NAT-External-Port-Style ]
* [ AVP ]
The NAT-Control-Remove AVP (AVP code 597) is of type Grouped, and it is used to deactivate or remove NAT-bindings. At least one of the two AVPs (NAT-Control-Definition AVP or NAT-Control-Binding-Template AVP) SHOULD be present in the NAT-Control-Remove AVP.
NAT-Control-Remove AVP（AVPコード597）はグループ化されたタイプであり、NATバインディングを非アクティブ化または削除するために使用されます。 2つのAVP（NAT-Control-Definition AVPまたはNAT-Control-Binding-Template AVP）の少なくとも1つがNAT-Control-Remove AVPに存在する必要があります。
AVP format:
NAT-Control-Remove ::= < AVP Header: 597 >
* [ NAT-Control-Definition ]
[ NAT-Control-Binding-Template ]
* [ AVP ]
The NAT-Control-Definition AVP (AVP code 598) is of type Grouped, and it describes a binding.
NAT-Control-Definition AVP（AVPコード598）はGroupedタイプであり、バインディングを記述します。
The NAT-Control-Definition AVP uniquely identifies the binding between the DNCA Diameter peers.
NAT-Control-Definition AVPは、DNCA Diameterピア間のバインディングを一意に識別します。
If both the NAT-Internal-Address and NAT-External-Address AVP(s) are supplied, it is a predefined binding.
NAT-Internal-AddressとNAT-External-Addressの両方のAVPが指定されている場合、それは事前定義されたバインディングです。
If the NAT-External-Address AVP is not specified, then the NAT device MUST select the external port as per the NAT-External-Port-Style AVP, if present in the NAT-Control-Definition AVP.
NAT-External-Address AVPが指定されていない場合、NATデバイスは、NAT-Control-Definition AVPに存在する場合、NAT-External-Port-Style AVPに従って外部ポートを選択する必要があります。
The Protocol AVP describes the transport protocol for the binding. The NAT-Control-Definition AVP can contain either zero or one Protocol AVP. If the Protocol AVP is omitted and if both internal and external IP addresses are specified, then the binding reserves the IP addresses for all transport protocols.
プロトコルAVPは、バインディングのトランスポートプロトコルを記述します。 NAT-Control-Definition AVPには、ゼロまたは1つのプロトコルAVPを含めることができます。プロトコルAVPが省略され、内部IPアドレスと外部IPアドレスの両方が指定されている場合、バインディングはすべてのトランスポートプロトコル用にIPアドレスを予約します。
The Direction AVP is of type Enumerated. It specifies the direction for the binding. The values of the enumeration applicable in this context are: "IN","OUT". If Direction AVP is OUT or absent, the NAT-Internal-Address refers to the IP address of the endpoint that needs to be translated. If Direction AVP is "IN", NAT-Internal-Address is the destination IP address that has to be translated.
方向AVPは列挙型です。バインディングの方向を指定します。このコンテキストで適用可能な列挙の値は、「IN」、「OUT」です。方向AVPがOUTまたは存在しない場合、NAT-Internal-Addressは、変換が必要なエンドポイントのIPアドレスを参照します。方向AVPが「IN」の場合、NAT-Internal-Addressは変換する必要がある宛先IPアドレスです。
AVP format:
NAT-Control-Definition ::= < AVP Header: 598 >
{ NAT-Internal-Address }
[ Protocol ]
[ Direction ]
[ NAT-External-Address ]
[ Session-Id ]
* [ AVP ]
The NAT-Internal-Address AVP (AVP code 599) is of type Grouped. It describes the internal IP address and port for a binding. Framed-IPV6-Prefix and Framed-IP-Address AVPs are mutually exclusive. The endpoint identifier Framed-IP-Address, Framed-IPv6-Prefix, and the internal address in this NAT-Internal-Address AVP to install NAT-bindings for the session MUST match.
NAT-Internal-Address AVP（AVPコード599）のタイプはGroupedです。バインディングの内部IPアドレスとポートを記述します。 Framed-IPV6-PrefixおよびFramed-IP-Address AVPは相互に排他的です。セッションのNATバインディングをインストールするには、エンドポイント識別子のFramed-IP-Address、Framed-IPv6-Prefix、およびこのNAT-Internal-Address AVPの内部アドレスが一致する必要があります。
AVP format:
NAT-Internal-Address ::= < AVP Header: 599 >
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
[ Port]
* [ AVP ]
The NAT-External-Address AVP (AVP code 600) is of type Grouped, and it describes the external IP address and port for a binding. The external IP address specified in this attribute can be reused for multiple endpoints by specifying the same address in the respective NAT-External-Address AVPs. If the external IP address is not specified and the NAT-External-Port-Style AVP is specified in the NAT-Control-Definition AVP, then the NAT device MUST select an external port as per the NAT-External-Port-Style AVP.
NAT-External-Address AVP（AVPコード600）はグループ化されたタイプであり、バインディングの外部IPアドレスとポートを記述します。この属性で指定された外部IPアドレスは、それぞれのNAT-External-Address AVPで同じアドレスを指定することにより、複数のエンドポイントで再利用できます。外部IPアドレスが指定されておらず、NAT-Control-Definition AVPでNAT-External-Port-Style AVPが指定されている場合、NATデバイスは、NAT-External-Port-Style AVPに従って外部ポートを選択する必要があります。
AVP format:
NAT-External-Address ::= < AVP Header: 600 >
[ Framed-IP-Address ]
[ Port ]
* [ AVP ]
The Max-NAT-Bindings AVP (AVP code 601) is of type Unsigned32. It indicates the maximum number of NAT-bindings allowed for a particular endpoint.
Max-NAT-Bindings AVP（AVPコード601）のタイプはUnsigned32です。これは、特定のエンドポイントに許可されるNATバインディングの最大数を示します。
The NAT-Control-Binding-Template AVP (AVP code 602) is of type OctetString. It defines a name for a policy template that is predefined at the NAT device. Details on the contents and structure of the template and configuration are outside the scope of this document. The policy to which this AVP refers may contain NAT-bindings, an IP address pool for allocating the external IP address of a NAT-binding, and a maximum number of allowed NAT-bindings. Such a policy template can be reused by specifying the same NAT-Control-Binding-Template AVP in the corresponding NAT-Control-Install AVPs of multiple endpoints.
NAT-Control-Binding-Template AVP（AVPコード602）のタイプはOctetStringです。 NATデバイスで事前定義されているポリシーテンプレートの名前を定義します。テンプレートの内容と構造、および構成の詳細は、このドキュメントの範囲外です。このAVPが参照するポリシーには、NATバインディング、NATバインディングの外部IPアドレスを割り当てるためのIPアドレスプール、および許可されるNATバインディングの最大数を含めることができます。このようなポリシーテンプレートは、複数のエンドポイントの対応するNAT-Control-Install AVPで同じNAT-Control-Binding-Template AVPを指定することで再利用できます。
The Duplicate-Session-Id AVP (AVP Code 603) is of type UTF8String. It is used to report errors and contains the Session-Id of an existing session.
Duplicate-Session-Id AVP（AVPコード603）のタイプはUTF8Stringです。エラーの報告に使用され、既存のセッションのセッションIDが含まれます。
The NAT-External-Port-Style AVP (AVP Code 604) is of type Enumerated and contains the style to be followed while selecting the external port for a NAT-binding relative to the internal port.
NAT-External-Port-Style AVP（AVPコード604）はEnumeratedタイプであり、内部ポートに対するNATバインディングの外部ポートを選択するときに従うべきスタイルが含まれています。
The following values are defined:
以下の値が定義されています。
FOLLOW_INTERNAL_PORT_STYLE (1)
FOLLOW_INTERNAL_PORT_STYLE（1）
External port numbers selected MUST follow the same sequence and oddity as the internal ports of the NAT-bindings. The port oddity is required to support protocols like RTP and RTCP as defined in [RFC3550]. If for example the internal port in a requested NAT-binding is odd numbered, then the external port allocated MUST also be odd numbered, and vice versa for an even numbered port. In addition, the sequence of port numbering is maintained: if internal ports are consecutive, then the NAT device MUST choose consecutive external ports for the NAT-bindings.
選択した外部ポート番号は、NATバインディングの内部ポートと同じシーケンスと奇数に従う必要があります。 [RFC3550]で定義されているように、RTPやRTCPなどのプロトコルをサポートするには、ポートの奇数が必要です。たとえば、要求されたNATバインディングの内部ポートが奇数番号の場合、割り当てられた外部ポートも奇数番号でなければならず（MUST）、偶数番号のポートの場合はその逆になります。さらに、ポート番号付けの順序が維持されます。内部ポートが連続している場合、NATデバイスはNATバインディング用に連続する外部ポートを選択する必要があります。
The DNCA reuses session-based accounting as defined in the Diameter base protocol [RFC6733] to report the bindings per endpoint. This reporting is achieved by sending Diameter Accounting-Request (ACR) commands [Start, Interim, and Stop] from the DNCA Diameter peer within the NAT device to its associated DNCA Diameter peer within the NAT controller.
DNCAは、Diameter基本プロトコル[RFC6733]で定義されているセッションベースのアカウンティングを再利用して、エンドポイントごとのバインディングを報告します。このレポートは、NATデバイス内のDNCA Diameterピアから、NATコントローラー内の関連するDNCA DiameterピアにDiameter Accounting-Request（ACR）コマンド[開始、暫定、および停止]を送信することで実現されます。
The DNCA Diameter peer within the NAT device sends an ACR Start on receiving an NCR with NC-Request-Type AVP set to INITIAL_REQUEST for a session or on creation of the first binding for a session requested in an earlier NCR. DNCA may send ACR Interim updates, if required, either due to a change in bindings resulting from an NCR with NC-Request-Type AVP set to UPDATE_REQUEST, periodically as specified in Acct-Interim-Interval by the DNCA Diameter peer within the NAT controller, or when it creates or tears down bindings. An ACR Stop is sent by the DNCA Diameter peer within the NAT device on receiving an STR message.
NATデバイス内のDNCA Diameterピアは、セッションのNC-Request-Type AVPがINITIAL_REQUESTに設定されたNCRを受信したとき、または以前のNCRで要求されたセッションの最初のバインディングの作成時に、ACR開始を送信します。 DNCAは、必要に応じて、NCRコントローラー内のDNCA DiameterピアによってAcct-Interim-Intervalで指定されているように、NC-Request-Type AVPがUPDATE_REQUESTに設定されたNCRに起因するバインディングの変更により、ACR中間更新を送信する場合があります、またはバインディングを作成または破棄する場合。 ACR Stopは、STRメッセージを受信すると、NATデバイス内のDNCA Diameterピアによって送信されます。
The function of correlating the multiple bindings used by an endpoint at any given time is relegated to the post processor.
ある時点でエンドポイントによって使用される複数のバインディングを関連付ける機能は、ポストプロセッサーに委任されます。
The DNCA Diameter peer within the NAT device may trigger an Interim accounting record when the maximum number of bindings, if received in an NCR, is reached.
NATデバイス内のDNCA Diameterピアは、NCRで受信したバインディングの最大数に達したときに、中間アカウンティングレコードをトリガーすることがあります。
The ACR and ACA messages are reused as defined in the Diameter base protocol [RFC6733] for exchanging endpoint NAT-binding details between the DNCA Diameter peers. The DNCA Application ID is used in the accounting commands. The ACR contains one or more optional NAT-Control-Record AVPs to report the bindings. The NAT device indicates the number of allocated NAT-bindings to the NAT controller using the Current-NAT-Bindings AVP. This number needs to match the number of bindings identified as active within the NAT-Control-Record AVP.
ACRおよびACAメッセージは、Diameter基本プロトコル[RFC6733]で定義されているように再利用され、DNCA Diameterピア間でエンドポイントNATバインディングの詳細を交換します。 DNCAアプリケーションIDは、アカウンティングコマンドで使用されます。 ACRには、バインディングを報告する1つ以上のオプションのNAT-Control-Record AVPが含まれています。 NATデバイスは、Current-NAT-Bindings AVPを使用して、NATコントローラーに割り当てられたNATバインディングの数を示します。この数は、NAT-Control-Record AVP内でアクティブであると識別されたバインディングの数と一致する必要があります。
In addition to AVPs for ACR specified in [RFC6733], the DNCA Diameter peer within the NAT device must add the NAT-Control-Record AVP.
[RFC6733]で指定されたACRのAVPに加えて、NATデバイス内のDNCA Diameterピアは、NAT-Control-Record AVPを追加する必要があります。
The NAT-Control-Record AVP (AVP code 605) is of type Grouped. It
describes a binding and its status. If NAT-Control-Binding-Status is
set to Created, Event-Timestamp indicates the binding creation time.
If NAT-Control-Binding-Status is set to Removed, Event-Timestamp
indicates the binding removal time. If NAT-Control-Binding-Status is
active, Event-Timestamp need not be present; if a value is present,
it indicates that binding is active at the given time.
NAT-Control-Record ::= < AVP Header: 605 >
{ NAT-Control-Definition }
{ NAT-Control-Binding-Status }
[ Event-Timestamp ]
The NAT-Control-Binding-Status AVP (AVP code 606) is of type enumerated. It indicates the status of the binding: created, removed, or active.
NAT-Control-Binding-Status AVP（AVPコード606）は列挙型です。バインディングのステータス（作成、削除、アクティブ）を示します。
The following values are defined:
以下の値が定義されています。
Created (1)
作成済み（1）
NAT-binding is created.
NATバインディングが作成されます。
Active (2)
アクティブ（2）
NAT-binding is active.
NATバインディングがアクティブです。
Removed (3)
削除済み（3）
NAT-binding was removed.
NATバインディングが削除されました。
The Current-NAT-Bindings AVP (AVP code 607) is of type Unsigned32. It indicates the number of NAT-bindings active on the NAT device.
Current-NAT-Bindings AVP（AVPコード607）のタイプはUnsigned32です。これは、NATデバイスでアクティブなNATバインディングの数を示します。
The following sections present the AVPs defined in this document and specify the Diameter messages in which they can be present. Note: AVPs that can only be present within a Grouped AVP are not represented in this table.
次のセクションでは、このドキュメントで定義されているAVPを示し、それらが存在するDiameterメッセージを指定します。注：グループ化されたAVP内にのみ存在できるAVPは、この表には示されていません。
The table uses the following symbols:
この表では次の記号を使用しています。
0 The AVP MUST NOT be present in the message.
0 AVPはメッセージに存在してはなりません。
0+ Zero or more instances of the AVP can be present in the message.
0+ AVPのゼロ個以上のインスタンスがメッセージに存在できます。
0-1 Zero or one instance of the AVP can be present in the message. It is considered an error if there is more than one instance of the AVP.
0-1 AVPのゼロまたは1つのインスタンスがメッセージに存在できます。 AVPのインスタンスが複数ある場合は、エラーと見なされます。
1 One instance of the AVP MUST be present in the message.
1 AVPの1つのインスタンスがメッセージに存在する必要があります。
1+ At least one instance of the AVP MUST be present in the message.
1+ AVPの少なくとも1つのインスタンスがメッセージに存在する必要があります。
The following table lists DNCA-specific AVPs that have to be present in NCRs and NCAs with the NC-Request-Type set to INITIAL_REQUEST or UPDATE_REQUEST.
次の表は、NC-Request-TypeがINITIAL_REQUESTまたはUPDATE_REQUESTに設定されたNCRおよびNCAに存在する必要があるDNCA固有のAVPを示しています。
+-------------------+
| Command Code |
+-----------------------------------+-------------------+
| Attribute Name NCR NCA |
+-------------------------------------------------------+
|NC-Request-Type 1 1 |
|NAT-Control-Install 0-1 0 |
|NAT-Control-Remove 0-1 0 |
|NAT-Control-Definition 0 0 |
|Current-NAT-Bindings 0 0 |
|Duplicate-Session-Id 0 0-1 |
+-------------------------------------------------------+
Note that any combination of NAT-Control-Install and NAT-Control-Remove AVPs could be present in an update or initial requests. Consider the following examples:
NAT-Control-InstallとNAT-Control-Remove AVPの任意の組み合わせが、更新または初期リクエストに存在する可能性があることに注意してください。次の例を検討してください。
Neither the NAT-Control-Install AVP nor the NAT-Control-Remove AVP is present: This could, for example, be the case if the NAT controller would only want to receive accounting information but not control NAT-bindings.
NAT-Control-Install AVPもNAT-Control-Remove AVPも存在しません。これは、たとえば、NATコントローラーがアカウンティング情報を受信するだけで、NATバインディングを制御したくない場合などです。
Only NAT-Control-Install AVP is present: This could, for example, be the case if a new NAT-binding is installed for an existing session.
NAT-Control-Install AVPのみが存在します。これは、たとえば、既存のセッションに新しいNATバインディングがインストールされている場合などです。
Only NAT-Control-Remove AVP is present: This could, for example, be the case if a new NAT-binding is removed from an existing session.
NAT-Control-Remove AVPのみが存在します。これは、たとえば、新しいNATバインディングが既存のセッションから削除された場合などです。
Both, NAT-Control-Install AVP and NAT-Control-Remove AVP are present: This could, for example. be the case if a formerly created NAT-binding is removed and a new NAT-binding is established within the same request.
NAT-Control-Install AVPとNAT-Control-Remove AVPの両方が存在します。これは、たとえば可能性があります。以前に作成されたNATバインディングが削除され、同じリクエスト内で新しいNATバインディングが確立された場合がそうです。
The following table lists DNCA-specific AVPs that have to be present in NCRs and NCAs with the NC-Request-Type set to QUERY_REQUEST.
次の表は、NC-Request-TypeがQUERY_REQUESTに設定されたNCRおよびNCAに存在する必要があるDNCA固有のAVPを示しています。
+-------------------+
| Command Code |
+-----------------------------------+-------------------+
| Attribute Name NCR NCA |
+-------------------------------------------------------+
|NC-Request-Type 1 1 |
|NAT-Control-Install 0 0 |
|NAT-Control-Remove 0 0 |
|NAT-Control-Definition 0 0+ |
|NAT-External-Address 0+ 0 |
|Current-NAT-Bindings 0 1 |
|Duplicate-Session-Id 0 0 |
+-------------------------------------------------------+
The following table lists DNCA-specific AVPs, which may or may not be
present in ACR and ACA messages.
+-------------------+
| Command Code |
+-----------------------------------+-------------------+
| Attribute Name ACR ACA |
+-------------------------------------------------------+
|NAT-Control-Record 0+ 0 |
|Current-NAT-Bindings 1 0 |
+-------------------------------------------------------+
This section contains either the namespaces that have been created in this specification or the values assigned to existing namespaces managed by IANA.
このセクションには、この仕様で作成された名前空間、またはIANAが管理する既存の名前空間に割り当てられた値のいずれかが含まれます。
In the subsections below, when we speak about review by a Designated Expert [RFC5226], please note that the Designated Expert will be assigned by the IESG. Initially, such Expert discussions take place on the AAA WG mailing list.
以下のサブセクションで指定専門家によるレビューについて話すとき[RFC5226]、指定専門家はIESGによって割り当てられることに注意してください。最初、このような専門家による議論はAAA WGメーリングリストで行われます。
This specification assigns the value 12, 'Diameter NAT Control Application', to the Application Identifier namespace defined in [RFC6733]. See Section 4 for more information.
この仕様は、値12「Diameter NAT Control Application」を、[RFC6733]で定義されているアプリケーション識別子の名前空間に割り当てます。詳細については、セクション4を参照してください。
This specification uses the value 330 from the Command code namespace defined in [RFC6733] for the NAT-Control-Request (NCR) and NAT-Control-Answer (NCA) commands. See Section 6.1 and Section 6.2 for more information on these commands.
この仕様は、NAT-Control-Request（NCR）およびNAT-Control-Answer（NCA）コマンドに対して[RFC6733]で定義されたコマンドコード名前空間の値330を使用します。これらのコマンドの詳細については、セクション6.1およびセクション6.2を参照してください。
This specification assigns the values 595-607 from the AVP Code namespace defined in [RFC6733]. See Section 8.7 for the assignment of the namespace in this specification.
この仕様は、[RFC6733]で定義されたAVPコード名前空間からの値595-607を割り当てます。この仕様での名前空間の割り当てについては、8.7節を参照してください。
This specification assigns the values 4014 and 5042-5047 from the Result-Code AVP value namespace defined in [RFC6733]. See Section 8.2 for the assignment of the namespace in this specification.
この仕様は、[RFC6733]で定義されているResult-Code AVP値の名前空間から値4014および5042-5047を割り当てます。この仕様での名前空間の割り当てについては、セクション8.2を参照してください。
As defined in Section 8.7.1, the NC-Request-Type AVP includes Enumerated type values 1-3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [RFC5226].
セクション8.7.1で定義されているように、NC-Request-Type AVPには列挙型の値1〜3が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。残りのすべての値は、Designated Expert [RFC5226]による割り当てに使用できます。
As defined in Section 8.7.10, the NAT-External-Port-Style AVP includes Enumerated type value 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [RFC5226].
セクション8.7.10で定義されているように、NAT-External-Port-Style AVPには列挙型の値1が含まれています。IANAはこのAVPの名前空間を作成して維持しています。残りのすべての値は、Designated Expert [RFC5226]による割り当てに使用できます。
As defined in Section 8.7.1, the NAT-Control-Binding-Status AVP includes Enumerated type values 1-3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [RFC5226].
セクション8.7.1で定義されているように、NAT-Control-Binding-Status AVPには列挙型の値1〜3が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。残りのすべての値は、Designated Expert [RFC5226]による割り当てに使用できます。
This document describes procedures for controlling NAT-related attributes and parameters by an entity, which is non-local to the device performing NAT. This section discusses security considerations for DNCA. This includes the interactions between the Diameter peers within a NAT controller and a NAT device as well as general considerations for a NAT-control in a service provider network.
このドキュメントでは、NATを実行するデバイスに対してローカルではないエンティティによって、NAT関連の属性とパラメータを制御する手順について説明します。このセクションでは、DNCAのセキュリティに関する考慮事項について説明します。これには、NATコントローラとNATデバイス内のDiameterピア間の相互作用、およびサービスプロバイダーネットワークでのNAT制御に関する一般的な考慮事項が含まれます。
Security between a NAT controller and a NAT device has a number of components: authentication, authorization, integrity, and confidentiality.
NATコントローラーとNATデバイス間のセキュリティには、認証、承認、整合性、機密性など、いくつかのコンポーネントがあります。
"Authentication" refers to confirming the identity of an originator for all datagrams received from the originator. Lack of authentication of Diameter messages between the Diameter peers can jeopardize the fundamental service of the peering network elements. A consequence of not authenticating the message sender by the recipient would be that an attacker could spoof the identity of a "legitimate" authorizing entity in order to change the behavior of the receiver. An attacker could, for example, launch a DoS attack by setting the maximum number of bindings for a session on the NAT device to zero; provisioning bindings on a NAT device that includes IP addresses already in use in other parts of the network; or requesting session termination of the Diameter session and hampering an endpoint's (i.e., a user's) connectivity. Lack of authentication of a NAT device to a NAT controller could lead to situations where the NAT device could provide a wrong view of the resources (i.e., NAT-bindings). In addition, a NAT-binding Predefined template on the NAT device could be configured differently than expected by the NAT controller. If either of the two DNCA Diameter peers fail to provide the required credentials, the failure should be subject to logging. The corresponding logging infrastructure of the operator SHOULD be built in a way that it can mitigate potential DoS attacks resulting from large amounts of logging events. This could include proper dimensioning of the logging infrastructure combined with policing the maximum amount of logging events accepted by the logging system to a threshold which the system is known to be able to handle.
「認証」とは、発信者から受信したすべてのデータグラムの発信者のIDを確認することを指します。 Diameterピア間のDiameterメッセージの認証の欠如は、ピアリングネットワーク要素の基本的なサービスを危険にさらす可能性があります。受信者がメッセージの送信者を認証しないと、攻撃者は「正当な」許可エンティティのIDを偽装して受信者の動作を変更する可能性があります。たとえば、攻撃者は、NATデバイス上のセッションのバインディングの最大数をゼロに設定することにより、DoS攻撃を仕掛けることができます。ネットワークの他の部分ですでに使用されているIPアドレスを含むNATデバイスでのバインディングのプロビジョニング。または、Diameterセッションのセッション終了を要求し、エンドポイント（つまり、ユーザー）の接続を妨害します。 NATコントローラーに対するNATデバイスの認証の欠如は、NATデバイスがリソース（つまり、NATバインディング）の誤ったビューを提供する状況を引き起こす可能性があります。さらに、NATデバイス上のNATバインディング事前定義テンプレートは、NATコントローラーが想定するものとは異なる構成にすることができます。 2つのDNCA Diameterピアのいずれかが必要な資格情報の提供に失敗した場合、失敗はロギングの対象になるはずです。オペレーターの対応するロギングインフラストラクチャは、大量のロギングイベントによるDoS攻撃の可能性を軽減できるように構築する必要があります（SHOULD）。これには、ロギングインフラストラクチャの適切なディメンショニングと、システムが処理できることがわかっているしきい値まで、ロギングシステムが受け入れるロギングイベントの最大量のポリシングが含まれる場合があります。
"Authorization" refers to whether a particular authorizing entity is authorized to signal a network element request for one or more applications, adhering to a certain policy profile. Failing the authorization process might indicate a resource theft attempt or failure due to administrative and/or credential deficiencies. In either case, the network element should take the proper measures to log such attempts.
「許可」とは、特定の許可エンティティが、特定のポリシープロファイルに従って、1つまたは複数のアプリケーションに対するネットワーク要素要求を通知することを許可されているかどうかを指します。承認プロセスに失敗した場合は、管理上の問題や資格情報の不足によるリソースの盗難の試みまたは失敗を示している可能性があります。どちらの場合でも、ネットワーク要素はそのような試みをログに記録するために適切な措置をとる必要があります。
Integrity is required to ensure that a Diameter message exchanged between the Diameter peers has not been maliciously altered by intermediate devices. The result of a lack of data integrity enforcement in an untrusted environment could be that an impostor will alter the messages exchanged between the peers. This could cause a change of behavior of the peers, including the potential of a DoS.
整合性は、Diameterピア間で交換されるDiameterメッセージが中間デバイスによって悪意を持って変更されていないことを確認するために必要です。信頼できない環境でのデータ整合性の強制が欠如している結果、詐欺師がピア間で交換されるメッセージを変更する可能性があります。これにより、DoSの可能性など、ピアの動作に変化が生じる可能性があります。
Confidentiality protection of Diameter messages ensures that the signaling data is accessible only to the authorized entities. When signaling messages between the DNCA Diameter peers traverse untrusted networks, lack of confidentiality will allow eavesdropping and traffic analysis.
Diameterメッセージの機密性保護により、許可されたエンティティのみがシグナリングデータにアクセスできるようになります。 DNCA Diameterピア間のシグナリングメッセージが信頼できないネットワークを通過する場合、機密性の欠如により盗聴やトラフィック分析が可能になります。
Diameter offers security mechanisms to deal with the functionality demanded above. DNCA makes use of the capabilities offered by Diameter and the underlying transport protocols to deliver these requirements (see Section 5.1). If the DNCA communication traverses untrusted networks, messages between DNCA Diameter peers SHOULD be secured using either IPsec or TLS. Please refer to [RFC6733], Section 13 for details. DNCA Diameter peers SHOULD perform bilateral authentication, authorization, as well as procedures to ensure integrity and confidentiality of the information exchange. In addition, the Session-Id chosen for a particular Diameter session SHOULD be chosen in a way that it is hard to guess in order to mitigate issues through potential message replay.
Diameterは、上記で要求された機能に対処するためのセキュリティメカニズムを提供します。 DNCAは、Diameterが提供する機能と基盤となるトランスポートプロトコルを利用して、これらの要件を提供します（セクション5.1を参照）。 DNCA通信が信頼できないネットワークを横断する場合、DNCA Diameterピア間のメッセージは、IPsecまたはTLSのいずれかを使用して保護する必要があります。詳細については、[RFC6733]のセクション13を参照してください。 DNCA Diameterピアは、双方向の認証、承認、および情報交換の整合性と機密性を確保するための手順を実行する必要があります（SHOULD）。さらに、特定のDiameterセッション用に選択されたSession-Idは、潜在的なメッセージの再生を通じて問題を軽減するために推測しにくい方法で選択する必要があります（SHOULD）。
DNCA Diameter peers SHOULD have a mutual trust setup. This document does not specify a mechanism for authorization between the DNCA Diameter peers. The DNCA Diameter peers SHOULD be provided with sufficient information to make an authorization decision. The information can come from various sources, for example, the peering devices could store local authentication policy, listing the identities of authorized peers.
DNCA Diameterピアは相互信頼セットアップを持っている必要があります。このドキュメントでは、DNCA Diameterピア間の認証メカニズムを指定していません。 DNCA Diameterピアには、承認決定を行うための十分な情報を提供する必要があります（SHOULD）。情報はさまざまなソースから取得できます。たとえば、ピアリングデバイスは、許可されたピアのIDをリストするローカル認証ポリシーを保存できます。
Any mechanism or protocol providing control of a NAT device, and DNCA is an example of such a control mechanism, could allow for misuse of the NAT device given that it enables the definition of per-destination or per-source rules. Misuse could include anti-competitive practices among providers, censorship, crime, etc. NAT-control could be used as a tool for preventing or redirecting access to particular sites. For instance, by controlling the NAT-bindings, one could ensure that endpoints aren't able to receive particular flows, or that those flows are redirected to a relay that snoops or tampers with traffic instead of directly forwarding the traffic to the intended endpoint. In addition, one could set up a binding in a way that the source IP address used is one of a relay so that traffic coming back can be snooped on or interfered with. The operator also needs to consider security threats resulting from unplanned termination of the DNCA session. Unplanned session termination, which could happen due to, e.g., an attacker taking down the NAT controller, leads to the NAT device cleaning up the state associated with this session after a grace period. If the grace period is set to zero, the endpoint will experience an immediate loss of connectivity to services reachable through the NAT device following the termination of the DNCA session.The protections on DNCA and its Diameter protocol exchanges don't prevent such abuses of NAT-control. Prevention of misuse or misconfiguration of a NAT device by an authorized NAT controller is beyond the scope of this protocol specification. A service provider deploying DNCA needs to make sure that higher-layer processes and procedures are put in place that allow them to detect and mitigate misuses.
NATデバイスの制御を提供するメカニズムまたはプロトコル、およびDNCAはそのような制御メカニズムの例であり、宛先ごとまたはソースごとのルールの定義が可能であれば、NATデバイスの誤用を許す可能性があります。誤用には、プロバイダー間の反競争的な慣行、検閲、犯罪などが含まれる可能性があります。NAT制御は、特定のサイトへのアクセスを防止またはリダイレクトするためのツールとして使用できます。たとえば、NATバインディングを制御することで、エンドポイントが特定のフローを受信できないようにしたり、目的のエンドポイントにトラフィックを直接転送する代わりに、これらのフローがトラフィックをスヌープまたは改ざんするリレーにリダイレクトしたりできます。さらに、使用される送信元IPアドレスがリレーの1つになるようにバインディングを設定して、戻ってくるトラフィックをスヌーピングまたは干渉できるようにすることもできます。オペレーターは、DNCAセッションの予期しない終了によるセキュリティ上の脅威も考慮する必要があります。たとえば、攻撃者がNATコントローラを停止したことが原因で発生する可能性のある予期しないセッションの終了により、NATデバイスは猶予期間後にこのセッションに関連付けられた状態をクリーンアップします。猶予期間がゼロに設定されている場合、エンドポイントでは、DNCAセッションの終了後に、NATデバイスを介して到達可能なサービスへの接続が即座に失われます。DNCAとそのDiameterプロトコル交換の保護は、このようなNATの乱用を防止しません-コントロール。許可されたNATコントローラーによるNATデバイスの誤用または誤設定の防止は、このプロトコル仕様の範囲外です。 DNCAを導入するサービスプロバイダーは、誤用を検出して軽減できるように、上位層のプロセスと手順を確実に導入する必要があります。
This section shows example DNCA message content and exchange.
このセクションでは、DNCAメッセージの内容と交換の例を示します。
Figure 15 depicts a typical call flow for DNCA session establishment.
図15は、DNCAセッション確立の一般的なコールフローを示しています。
In this example, the NAT controller does the following:
この例では、NATコントローラーは次のことを行います。
a. requests a maximum of 100 NAT-bindings for the endpoint.
a. エンドポイントに対して最大100のNATバインディングを要求します。
b. defines a static binding for a TCP connection that associates the internal IP Address:Port 192.0.2.1:80 with the external IP Address:Port 198.51.100.1:80 for the endpoint.
b. 内部IPアドレス：ポート192.0.2.1:80をエンドポイントの外部IPアドレス：ポート198.51.100.1:80に関連付けるTCP接続の静的バインディングを定義します。
c. requests the use of a preconfigured template called "local-policy" while creating NAT-bindings for the endpoint.
c. エンドポイントのNATバインディングを作成するときに、「local-policy」と呼ばれる事前設定されたテンプレートの使用を要求します。
endpoint NAT controller (within NAS) NAT device
| | |
| | |
| 1. Trigger | |
|--------------------------->| |
| +-------------------------------------+ |
| | 2. Determine that NAT control | |
| | is required for the endpoint | |
| +-------------------------------------+ |
| | |
| | |
| ...................................
| .| 3. Diameter Base CER/CEA |.
| .|<----------------------------->|.
| ...................................
| | |
| | |
| | 4. NCR |
| |------------------------------>|
| | |
| | 5. DNCA session
| | established
| | |
| | 6. NCA |
| |<------------------------------|
| | |
| | |
| 7. Data traffic |
|----------------------------------------------------------->|
| | |
| | |
| | 8. NAT-bindings
| | created as per
| | directives in the
| | DNCA session
| | |
Figure 15: Initial NAT-Control-Request and Session Establishment Example
図15：最初のNAT制御要求とセッション確立の例
Detailed description of the steps shown in Figure 15:
図15に示されているステップの詳細な説明：
1. The NAT controller (co-located with the NAS here) creates state for an endpoint based on a trigger. This could, for example, be the successful establishment of a Point-to-Point Protocol (PPP) [RFC1661] access session.
1. （ここではNASと同じ場所にある）NATコントローラーは、トリガーに基づいてエンドポイントの状態を作成します。これは、たとえば、ポイントツーポイントプロトコル（PPP）[RFC1661]アクセスセッションの確立の成功である可能性があります。
2. Based on the configuration of the DNCA Diameter peer within the NAT controller, the NAT controller determines that NAT-control is required and is to be enforced at a NAT device.
2. NATコントローラー内のDNCA Diameterピアの構成に基づいて、NATコントローラーは、NAT制御が必要であり、NATデバイスで実施されることを決定します。
3. If there is no Diameter session already established with the DNCA Diameter peer within NAT device, a Diameter connection is established and Diameter Base CER/CEA are exchanged.
3. NATデバイス内のDNCA Diameterピアとすでに確立されているDiameterセッションがない場合、Diameter接続が確立され、DiameterベースCER / CEAが交換されます。
4. The NAT-Controller creates an NCR message (see below) and sends it to the NAT device. This example shows IPv4 to IPv4 address and port translation. For IPv6 to IPv4 translation, the Framed-IP-Address AVP would be replaced by the Framed-IPv6-Address AVP with the value set to the IPv6 address of the endpoint.
4. NATコントローラーはNCRメッセージ（下記参照）を作成し、NATデバイスに送信します。この例は、IPv4からIPv4へのアドレスおよびポート変換を示しています。 IPv6からIPv4への変換の場合、Framed-IP-Address AVPは、値がエンドポイントのIPv6アドレスに設定されたFramed-IPv6-Address AVPに置き換えられます。
< NC-Request > ::= < Diameter Header: 330, REQ, PXY>
Session-Id = "natC.example.com:33041;23432;"
Auth-Application-Id = <DNCA Application ID>
Origin-Host = "natC.example.com"
Origin-Realm = "example.com"
Destination-Realm = "example.com"
Destination-Host = "nat-device.example.com"
NC-Request-Type = INITIAL_REQUEST
User-Name = "subscriber_example1"
Framed-IP-Address = "192.0.2.1"
NAT-Control-Install = {
NAT-Control-Definition = {
Protocol = TCP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 80
}
NAT-External-Address = {
Framed-IP-Address = "198.51.100.1"
Port = 80
}
}
Max-NAT-Bindings = 100
NAT-Control-Binding-Template = "local-policy"
}
5. The NAT device establishes a DNCA session as it is able to comply with the request.
5. NATデバイスは、要求に準拠できるため、DNCAセッションを確立します。
6. The NAT device sends an NCA to indicate the successful completion of the request.
6. NATデバイスはNCAを送信して、要求が正常に完了したことを示します。
<NC-Answer> ::= < Diameter Header: 330, PXY >
Session-Id = "natC.example.com:33041;23432;"
Origin-Host = "nat-device.example.com"
Origin-Realm = "example.com"
NC-Request-Type = INITIAL_REQUEST
Result-Code = DIAMETER_SUCCESS
7. The endpoint sends packets that reach the NAT device.
7. エンドポイントは、NATデバイスに到達するパケットを送信します。
8. The NAT device performs NAT for traffic received from the endpoint with source address 192.0.2.1. Traffic with source IP address 192.0.2.1 and port 80 are translated to the external IP address 198.51.100.1 and port 80. Traffic with source IP address 192.0.2.1 and a source port different from 80 will be translated to IP address 198.51.100.1 and a port chosen by the NAT device. Note that this example assumes that the NAT device follows typical binding allocation rules for endpoints, in that only a single external IP address is used for all traffic received from a single IP address of an endpoint. The NAT device will allow a maximum of 100 NAT-bindings be created for the endpoint.
8. NATデバイスは、送信元アドレス192.0.2.1のエンドポイントから受信したトラフィックに対してNATを実行します。送信元IPアドレス192.0.2.1およびポート80のトラフィックは、外部IPアドレス198.51.100.1およびポート80に変換されます。送信元IPアドレス192.0.2.1および80以外の送信元ポートを持つトラフィックは、IPアドレス198.51.100.1およびNATデバイスによって選択されたポート。この例では、エンドポイントの単一のIPアドレスから受信したすべてのトラフィックに単一の外部IPアドレスのみが使用されるという点で、NATデバイスがエンドポイントの一般的なバインディング割り当てルールに従うことを前提としています。 NATデバイスでは、エンドポイントに対して最大100のNATバインディングを作成できます。
This section gives an example for a DNCA session update: A new set of NAT-bindings is requested for an existing session. The request contains a directive ( the "NAT-External-Port-Style" AVP set to FOLLOW_INTERNAL_PORT_STYLE) that directs the NAT device to maintain port-sequence and port-oddity for the newly created NAT-bindings. In the example shown, the internal ports are UDP port 1036 and 1037. The NAT device follows the directive selects the external ports accordingly. The NAT device would, for example, create a mapping of 192.0.2.1:1036 to 198.51.100.1:5056 and 192.0.2.1:1037 to 198.51.100.1:5057, thereby maintaining port oddity (1036->5056, 1037->5057) and sequence ( the consecutive internal ports 1036 and 1037 map to the consecutive external ports 5056 and 5057).
このセクションでは、DNCAセッションの更新の例を示します。既存のセッションに対して、NATバインディングの新しいセットが要求されます。リクエストには、新しく作成されたNATバインディングのポートシーケンスとポート奇数を維持するようにNATデバイスに指示するディレクティブ（「NAT-External-Port-Style」AVPがFOLLOW_INTERNAL_PORT_STYLEに設定）が含まれています。示されている例では、内部ポートはUDPポート1036と1037です。NATデバイスはディレクティブに従い、それに応じて外部ポートを選択します。たとえば、NATデバイスは、192.0.2.1：1036から198.51.100.1:5056へのマッピングと192.0.2.1:1037から198.51.100.1:5057へのマッピングを作成し、ポートの奇数（1036-> 5056、1037-> 5057）を維持します。 ）およびシーケンス（連続する内部ポート1036および1037は、連続する外部ポート5056および5057にマップされます）。
< NC-Request > ::= < Diameter Header: 330, REQ, PXY>
Session-Id = "natC.example.com:33041;23432;"
Auth-Application-Id = <DNCA Application ID>
Origin-Host = "natC.example.com"
Origin-Realm = "example.com"
Destination-Realm = "example.com"
Destination-Host = "nat-device.example.com"
NC-Request-Type = UPDATE_REQUEST
NAT-Control-Install = {
NAT-Control-Definition = {
Protocol = UDP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 1035
}
}
NAT-Control-Definition = {
Protocol = UDP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 1036
}
}
NAT-External-Port-
Style = FOLLOW_INTERNAL_PORT_STYLE
}
This section shows an example for DNCA session query for a subscriber
whose internal IP Address is 192.0.2.1.
< NC-Request > ::= < Diameter Header: 330, REQ, PXY>
Auth-Application-Id = <DNCA Application ID>
Origin-Host = "natC.example.com"
Origin-Realm = "example.com"
Destination-Realm = "example.com"
Destination-Host = "nat-device.example.com"
NC-Request-Type = QUERY_REQUEST
Framed-IP-Address = "192.0.2.1"
The NAT device constructs an NCA to report all currently active NAT-bindings whose internal address is 192.0.2.1.
NATデバイスは、内部アドレスが192.0.2.1である現在アクティブなすべてのNATバインディングを報告するNCAを構築します。
<NC-Answer> ::= < Diameter Header: 330, PXY >
Origin-Host = "nat-device.example.com"
Origin-Realm = "example.com"
NC-Request-Type = QUERY_REQUEST
NAT-Control-Definition = {
Protocol = TCP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 80
}
NAT-External-Address = {
Framed-IP-Address = "198.51.100.1"
Port = 80
}
Session-Id = "natC.example.com:33041;23432;"
}
NAT-Control-Definition = {
Protocol = TCP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 1036
}
NAT-External-Address = {
Framed-IP-Address = "198.51.100.1"
Port = 5056
}
Session-Id = "natC.example.com:33041;23432;"
}
NAT-Control-Definition = {
Protocol = TCP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 1037
}
NAT-External-Address = {
Framed-IP-Address = "198.51.100.1"
Port = 5057
}
Session-Id = "natC.example.com:33041;23432;"
}
In this example the NAT controller decides to terminate the previously established DNCA session. This could, for example, be the case as a result of an access session (e.g., a PPP session) associated with an endpoint having been torn down.
この例では、NATコントローラーは以前に確立されたDNCAセッションを終了することを決定します。これは、たとえば、エンドポイントに関連付けられたアクセスセッション（PPPセッションなど）が破棄された結果として発生する可能性があります。
NAT controller NAT device
| |
| |
+--------------+ |
| 1. Trigger | |
+--------------+ |
| |
| |
| 2. STR |
|-------------------------------------->|
| |
| 3. DNCA session
| lookup
| 4. ACR |
|<--------------------------------------|
| |
| 5. ACA |
|-------------------------------------->|
| |
| |
| 6. DNCA bindings
| and session cleanup
| |
| 7. STA |
|<--------------------------------------|
| |
Figure 20: NAT Control Session Termination Example
図20：NAT制御セッション終了の例
The following steps describe the sequence of events for tearing down the DNCA session in the example above:
次の手順では、上記の例でDNCAセッションを破棄するための一連のイベントについて説明します。
1. The NAT controller receives a trigger that a DNCA session associated with a specific endpoint should be terminated. An example event could be the termination of the PPP [RFC1661] access session to an endpoint in a NAS. The NAS correspondingly triggers the NAT controller request to tear down the associated DNCA session.
1. NATコントローラーは、特定のエンドポイントに関連付けられたDNCAセッションを終了する必要があるというトリガーを受け取ります。イベントの例として、NASのエンドポイントへのPPP [RFC1661]アクセスセッションの終了があります。 NASは対応するNATコントローラー要求をトリガーして、関連するDNCAセッションを破棄します。
2. The NAT controller creates the required NCR message and sends it to the NAT device:
2. NATコントローラーは必要なNCRメッセージを作成し、それをNATデバイスに送信します。
< STR > ::= < Diameter Header: 275, REQ, PXY>
Session-Id = "natC.example.com:33041;23432;"
Auth-Application-Id = <DNCA Application ID>
Origin-Host = "natC.example.com"
Origin-Realm = "example.com"
Destination-Realm = "example.com"
Destination-Host = "nat-device.example.com"
Termination-Cause = DIAMETER_LOGOUT
3. The NAT device looks up the DNCA session based on the Session-Id AVP and finds a previously established active session.
3. NATデバイスは、Session-Id AVPに基づいてDNCAセッションを検索し、以前に確立されたアクティブセッションを見つけます。
4. The NAT device reports all NAT-bindings established for that subscriber using an ACR: < ACR > ::= < Diameter Header: 271, REQ, PXY> Session-Id = "natC.example.com:33041;23432;" Auth-Application-Id = <DNCA Application ID> Origin-Host = "nat-device.example.com" Origin-Realm = "example.com" Destination-Realm = "example.com" Destination-Host = "natC.example.com" Accounting-Record-Type = STOP_RECORD Accounting-Record-Number = 1 NAT-Control-Record = { NAT-Control-Definition = { Protocol = TCP Direction = OUT NAT-Internal-Address = { Framed-IP-Address = "192.0.2.1" Port = 5001 } NAT-External-Address = { Framed-IP-Address = "198.51.100.1" Port = 7777 } } NAT-Control-Binding-Status = Removed }
4. NATデバイスは、ACRを使用してそのサブスクライバー用に確立されたすべてのNATバインディングを報告します。<ACR> :: = <Diameterヘッダー：271、REQ、PXY> Session-Id = "natC.example.com:33041;23432;" Auth-Application-Id = <DNCAアプリケーションID> Origin-Host = "nat-device.example.com" Origin-Realm = "example.com" Destination-Realm = "example.com" Destination-Host = "natC.example .com "Accounting-Record-Type = STOP_RECORD Accounting-Record-Number = 1 NAT-Control-Record = {NAT-Control-Definition = {Protocol = TCP Direction = OUT NAT-Internal-Address = {Framed-IP-Address = "192.0.2.1"ポート= 5001} NAT-External-Address = {Framed-IP-Address = "198.51.100.1"ポート= 7777}} NAT-Control-Binding-Status =削除済み}
5. The NAT controller receives and processes the ACR as per its configuration. It responds with an ACA to the NAT device.
5. NATコントローラーは、その構成に従ってACRを受信して処理します。 NATデバイスにACAで応答します。
<ACA> ::= < Diameter Header: 271, PXY >
Session-Id = "natC.example.com:33041;23432;"
Origin-Host = "natC.example.com"
Origin-Realm = "example.com"
Result-Code = DIAMETER_SUCCESS
Accounting-Record-Type = STOP_RECORD
Accounting-Record-Number = 1
6. On receipt of the ACA the NAT device cleans up all NAT-bindings and associated session state for the endpoint.
6. ACAを受信すると、NATデバイスはエンドポイントのすべてのNATバインディングと関連するセッション状態をクリーンアップします。
7. NAT device sends an STA. On receipt of the STA the NAT controller will clean up the corresponding session state. <STA> ::= < Diameter Header: 275, PXY > Session-Id = "natC.example.com:33041;23432;" Origin-Host = "nat-device.example.com" Origin-Realm = "example.com" Result-Code = DIAMETER_SUCCESS
7. NATデバイスがSTAを送信します。 STAを受信すると、NATコントローラーは対応するセッション状態をクリーンアップします。 <STA> :: = <Diameterヘッダー：275、PXY> Session-Id = "natC.example.com:33041;23432;" Origin-Host = "nat-device.example.com" Origin-Realm = "example.com"結果コード= DIAMETER_SUCCESS
The authors would like to thank Jari Arkko, Wesley Eddy, Stephen Farrell, Miguel A. Garcia, David Harrington, Jouni Korhonen, Matt Lepinski, Avi Lior, Chris Metz, Pallavi Mishra, Lionel Morand, Robert Sparks, Martin Stiemerling, Dave Thaler, Hannes Tschofenig, Sean Turner, Shashank Vikram, Greg Weber, and Glen Zorn for their input on this document.
著者は、Jari Arkko、Wesley Eddy、Stephen Farrell、Miguel A. Garcia、David Harrington、Jouni Korhonen、Matt Lepinski、Avi Lior、Chris Metz、Pallavi Mishra、Lionel Morand、Robert Sparks、Martin Stiemerling、Dave Thaler、このドキュメントへの入力については、Hannes Tschofenig、Sean Turner、Shashank Vikram、Greg Weber、およびGlen Zornが担当しました。
[ETSIES283034] ETSI, "Telecommunications and Internet Converged Services and Protocols for Advanced Networks (TISPAN), Network Attachment Sub-System (NASS), e4 interface based on the Diameter protocol.", September 2008.
[ETSIES283034] ETSI、「テレコミュニケーションおよびインターネット統合サービスおよび高度ネットワーク用プロトコル（TISPAN）、ネットワーク接続サブシステム（NASS）、Diameterプロトコルに基づくe4インターフェイス。」、2008年9月。
[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月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4675] Congdon、P.、Sanchez、M。、およびB. Aboba、「仮想LANおよび優先度サポートのRADIUS属性」、RFC 4675、2006年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, February 2010.
[RFC5777] Korhonen、J.、Tschofenig、H.、Arumaithurai、M.、Jones、M.、and A. Lior、 "Traffic Classification and Quality of Service（QoS）Attributes for Diameter"、RFC 5777、February 2010。
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733] Fajardo、V.、Arkko、J.、Loughney、J。、およびG. Zorn、「Diameter Base Protocol」、RFC 6733、2012年10月。
[CGN-REQS] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NATs (CGNs)", Work in Progress, September 2012.
[CGN-REQS] Perreault、S。、山形、I。、宮川、S。、中川、A。、およびH. Ashida、「Common requirements for Carrier Grade NATs（CGNs）」、Work in Progress、2012年9月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、1999年8月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC3303] Srisuresh、P.、Kuthan、J.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「ミドルボックス通信アーキテクチャおよびフレームワーク」、RFC 3303、2002年8月。
[RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002.
[RFC3304] Swale、R.、Mart、P.、Sijben、P.、Brim、S。、およびM. Shore、「Middlebox Communications（midcom）Protocol Requirements」、RFC 3304、2002年8月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「An Simple Describing for Simple Network Management Protocol（SNMP）Management Frameworks」、STD 62、RFC 3411、2002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC4097] Barnes, M., "Middlebox Communications (MIDCOM) Protocol Evaluation", RFC 4097, June 2005.
[RFC4097] Barnes、M。、「Middlebox Communications（MIDCOM）Protocol Evaluation」、RFC 4097、2005年6月。
[RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communication (MIDCOM) Protocol Semantics", RFC 5189, March 2008.
[RFC5189] Stiemerling、M.、Quittek、J。、およびT. Taylor、「Middlebox Communication（MIDCOM）Protocol Semantics」、RFC 5189、2008年3月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP / ICMP変換アルゴリズム」、RFC 6145、2011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、2011年4月。
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241] Enns、R.、Bjorklund、M.、Schoenwaelder、J。、およびA. Bierman、「Network Configuration Protocol（NETCONF）」、RFC 6241、2011年6月。
Authors' Addresses
著者のアドレス
Frank Brockners Cisco Hansaallee 249, 3rd Floor Duesseldorf, Nordrhein-Westfalen 40549 Germany
フランクブロックナーのCisco Hansaallee 249、3rd Floor Duesseldorf、North Rhine-Westphalia 40549 Germany
EMail: fbrockne@cisco.com
Shwetha Bhandari Cisco Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, Karnataka 560 087 India
Shweta Bhandari Cisco Chase's Business Park、Sarjapur Marathalli Outer Ring Roadバンガロール、カルナータカ州
EMail: shwethab@cisco.com
Vaneeta Singh 18, Cambridge Road Bangalore 560008 India
Vaneeta Singh 18、Cambridge Road Bangalore 560008インド
EMail: vaneeta.singh@gmail.com
Victor Fajardo Telcordia Technologies 1 Telcordia Drive #1S-222 Piscataway, NJ 08854 USA
Victor Fajardo Telcordia Technologies 1 Telcordia Drive＃1S-222 Piscataway、NJ 08854 USA
EMail: vf0213@gmail.com