Internet Engineering Task Force (IETF) M. Stiemerling
Request for Comments: 5973 NEC
Category: Experimental H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
C. Aoun
Consultant
E. Davies
Folly Consulting
October 2010
NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
Abstract
抽象
This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo.
このメモは、ネットワークアドレス変換器（NAT）とファイアウォールのためのNSISシグナリング層プロトコル（NSLP）を定義します。このNSLPは、NATのファイアウォールは、アプリケーションデータフローのニーズに応じて設定するためにホストがデータ経路上の信号を可能にします。例えば、それはデータトラフィックを受信するために、ファイアウォールの背後に公に到達可能アドレスとホストを得るために、NATの背後にあるホストを可能にします。全体的なアーキテクチャは、シグナリング（NSIS）ワーキンググループにおける次のステップによって規定されたフレームワークと要件によって与えられます。パス結合シグナリングのためのネットワーク・シナリオ、プロトコル自体、および実施例は、この文書に記載されています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc5973.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5973で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 8
1.3. Notes on the Experimental Status . . . . . . . . . . . . . 10
1.4. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10
1.5. General Scenario for NATFW Traversal . . . . . . . . . . . 11
2. Network Deployment Scenarios Using the NATFW NSLP . . . . . . 13
2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13
2.2. NAT with Two Private Networks . . . . . . . . . . . . . . 14
2.3. NAT with Private Network on Sender Side . . . . . . . . . 15
2.4. NAT with Private Network on Receiver Side Scenario . . . . 15
2.5. Both End Hosts behind Twice-NATs . . . . . . . . . . . . . 16
2.6. Both End Hosts behind Same NAT . . . . . . . . . . . . . . 17
2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18
2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 18
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 19
3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 19
3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 20
3.2.1. Signaling for Outbound Traffic . . . . . . . . . . . . 20
3.2.2. Signaling for Inbound Traffic . . . . . . . . . . . . 22
3.2.3. Signaling for Proxy Mode . . . . . . . . . . . . . . . 23
3.2.4. Blocking Traffic . . . . . . . . . . . . . . . . . . . 24
3.2.5. State and Error Maintenance . . . . . . . . . . . . . 24
3.2.6. Message Types . . . . . . . . . . . . . . . . . . . . 25
3.2.7. Classification of RESPONSE Messages . . . . . . . . . 25
3.2.8. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 26
3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 27
3.4. Calculation of Signaling Session Lifetime . . . . . . . . 27
3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 31
3.6. Authentication, Authorization, and Policy Decisions . . . 32
3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 32
3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 32
3.7.2. Reserving External Addresses . . . . . . . . . . . . . 35
3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 43
3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 45
3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 46
3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 48
3.8. Demultiplexing at NATs . . . . . . . . . . . . . . . . . . 53
3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 54
3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 55
4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 55
4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 56
4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 58
4.2.2. External Address Object . . . . . . . . . . . . . . . 58
4.2.3. External Binding Address Object . . . . . . . . . . . 59
4.2.4. Extended Flow Information Object . . . . . . . . . . . 59
4.2.5. Information Code Object . . . . . . . . . . . . . . . 60
4.2.6. Nonce Object . . . . . . . . . . . . . . . . . . . . . 64
4.2.7. Message Sequence Number Object . . . . . . . . . . . . 64
4.2.8. Data Terminal Information Object . . . . . . . . . . . 64
4.2.9. ICMP Types Object . . . . . . . . . . . . . . . . . . 66
4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 67
4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.2. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 69
5. Security Considerations . . . . . . . . . . . . . . . . . . . 69
5.1. Authorization Framework . . . . . . . . . . . . . . . . . 70
5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 70
5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 71
5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 72
5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 73
5.2.1. Security Protection between Neighboring NATFW NSLP
Nodes . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2.2. Security Protection between Non-Neighboring NATFW
NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 74
5.3. Implementation of NATFW NSLP Security . . . . . . . . . . 75
6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 76
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77
7.1. NATFW NSLP Message Type Registry . . . . . . . . . . . . . 77
7.2. NATFW NSLP Header Flag Registry . . . . . . . . . . . . . 77
7.3. NSLP Message Object Registry . . . . . . . . . . . . . . . 78
7.4. NSLP Response Code Registry . . . . . . . . . . . . . . . 78
7.5. NSLP IDs and Router Alert Option Values . . . . . . . . . 78
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.1. Normative References . . . . . . . . . . . . . . . . . . . 79
9.2. Informative References . . . . . . . . . . . . . . . . . . 79
Appendix A. Selecting Signaling Destination Addresses for
EXTERNAL . . . . . . . . . . . . . . . . . . . . . . 81
Appendix B. Usage of External Binding Addresses . . . . . . . . . 82
Appendix C. Applicability Statement on Data Receivers behind
Firewalls . . . . . . . . . . . . . . . . . . . . . . 83
Appendix D. Firewall and NAT Resources . . . . . . . . . . . . . 84
D.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 84
D.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 84
D.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 85
D.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 85
Appendix E. Example for Receiver Proxy Case . . . . . . . . . . . 86
Firewalls and Network Address Translators (NATs) have both been used throughout the Internet for many years, and they will remain present for the foreseeable future. Firewalls are used to protect networks against certain types of attacks from internal networks and the Internet, whereas NATs provide a virtual extension of the IP address space. Both types of devices may be obstacles to some applications, since they only allow traffic created by a limited set of applications to traverse them, typically those that use protocols with relatively predetermined and static properties (e.g., most HTTP traffic, and other client/server applications). Other applications, such as IP telephony and most other peer-to-peer applications, which have more dynamic properties, create traffic that is unable to traverse NATs and firewalls without assistance. In practice, the traffic of many applications cannot traverse autonomous firewalls or NATs, even when they have additional functionality that attempts to restore the transparency of the network.
ファイアウォールとネットワークアドレス変換（NAT）は、両方の長年のためにインターネット全体で使用されている、と彼らは予見可能な将来のために存在し続けます。 NATのは、IPアドレス空間の仮想拡張を提供し、一方、ファイアウォールは、内部ネットワークとインターネットからの攻撃の特定の種類からネットワークを保護するために使用されています。彼らは唯一、通常、アプリケーションの限定セットによって作成されたトラフィックがそれらを横断する比較的一定と静的な特性（例えば、ほとんどのHTTPトラフィック、およびその他のクライアント/サーバーとのプロトコルを使用するものを許容するので、両方のタイプのデバイスは、いくつかのアプリケーションへの障害かもしれアプリケーション）。このようなIP電話とより動的な性質を有する他のほとんどのピア・ツー・ピア・アプリケーションのような他のアプリケーションは、補助なしのNATやファイアウォールを通過することができないトラフィックを作成します。実際には、多くのアプリケーションのトラフィックは、彼らがネットワークの透明性を回復しようとする追加機能を持っている場合でも、自律ファイアウォールやNATのを通過することはできません。
Several solutions to enable applications to traverse such entities have been proposed and are currently in use. Typically, application-level gateways (ALGs) have been integrated with the firewall or NAT to configure the firewall or NAT dynamically. Another approach is middlebox communication (MIDCOM). In this approach, ALGs external to the firewall or NAT configure the corresponding entity via the MIDCOM protocol [RFC3303]. Several other work-around solutions are available, such as Session Traversal Utilities for NAT (STUN) [RFC5389]. However, all of these approaches introduce other problems that are generally hard to solve, such as dependencies on the type of NAT implementation (full-cone, symmetric, etc.), or dependencies on certain network topologies.
そのような実体を横断するアプリケーションを有効にするには、いくつかの解決策が提案され、現在使用されているされています。典型的には、アプリケーションレベルゲートウェイ（のALG）は、動的にファイアウォールまたはNATを構成するために、ファイアウォールまたはNATと一体化されています。別のアプローチは、ミドル通信（MIDCOM）です。このアプローチでは、ファイアウォールまたはNATの外部のALGはMIDCOMプロトコル[RFC3303]を介して、対応するエンティティを設定します。他のいくつかの回避策ソリューションは、このようなNAT（STUN）[RFC5389]のためのセッショントラバーサルユーティリティとして、ご利用いただけます。しかしながら、これらのアプローチの全ては、特定のネットワークトポロジ上のNAT実装（フルコーン、対称、など）、または依存関係の種類に依存関係として解くことが一般に困難である他の問題を導入します。
NAT and firewall (NATFW) signaling shares a property with Quality-of-Service (QoS) signaling -- each must reach any device that is on the data path and is involved in (respectively) NATFW or QoS treatment of data packets. This means that for both NATFW and QoS it is convenient if signaling travels path-coupled, i.e., the signaling messages follow exactly the same path that the data packets take. The Resource Reservation Protocol (RSVP) [RFC2205] is an example of a current QoS signaling protocol that is path-coupled. [rsvp-firewall] proposes the use of RSVP as a firewall signaling protocol but does not include NATs.
NATやファイアウォール（NATFW）シグナリングのサービス品質（QoS）と共有財産シグナル - 各すると、データ・パス上にあり、データパケットの（それぞれ）NATFWまたはQoS治療に関与している任意のデバイスに到達しなければなりません。これは、シグナリングはすなわち、シグナリングメッセージは、データパケットが取ることが全く同じ経路をたどる、パス結合移動する場合NATFWおよびQoSの両方のために、それが便利であることを意味します。リソース予約プロトコル（RSVP）[RFC2205]はパス結合されているプロトコルシグナリング現在のQoSの一例です。 [RSVP-ファイアウォール]ファイアウォールシグナリングプロトコルとしてRSVPを使用することを提案しているが、NATのを含みません。
This memo defines a path-coupled signaling protocol for NAT and firewall configuration within the framework of NSIS, called the NATFW NSIS Signaling Layer Protocol (NSLP). The general requirements for
このメモは、NSISの枠組みの中でNATやファイアウォールの設定のための経路結合シグナリングプロトコルを定義し、NATFW NSISシグナリング層プロトコル（NSLP）と呼ばれます。以下のための一般的な要件
NSIS are defined in [RFC3726] and the general framework of NSIS is outlined in [RFC4080]. It introduces the split between an NSIS transport layer and an NSIS signaling layer. The transport of NSLP messages is handled by an NSIS Network Transport Layer Protocol (NTLP, with General Internet Signaling Transport (GIST) [RFC5971] being the implementation of the abstract NTLP). The signaling logic for QoS and NATFW signaling is implemented in the different NSLPs. The QoS NSLP is defined in [RFC5974].
NSISは、[RFC3726]で定義され、NSISの一般的なフレームワークは[RFC4080]に概説されています。これは、NSISトランスポート層とNSISシグナリング層との間の分割を導入します。 NSLPメッセージの輸送はNSISネットワークトランスポート層プロトコル（一般的なインターネットシグナリング交通とNTLP、（GIST）[RFC5971]抽象NTLPの実装である）によって処理されます。 QoSおよびNATFWシグナリングのためのシグナリング・ロジックが異なるNSLPsに実装されています。 QoS NSLPは[RFC5974]で定義されています。
The NATFW NSLP is designed to request the dynamic configuration of NATs and/or firewalls along the data path. Dynamic configuration includes enabling data flows to traverse these devices without being obstructed, as well as blocking of particular data flows at inbound firewalls. Enabling data flows requires the loading of firewall rules with an action that allows the data flow packets to be forwarded and NAT bindings to be created. The blocking of data flows requires the loading of firewall rules with an action that will deny forwarding of the data flow packets. A simplified example for enabling data flows: a source host sends a NATFW NSLP signaling message towards its data destination. This message follows the data path. Every NATFW NSLP-enabled NAT/firewall along the data path intercepts this message, processes it, and configures itself accordingly. Thereafter, the actual data flow can traverse all these configured firewalls/NATs.
NATFW NSLPは、データパスに沿ってのNAT及び/又はファイアウォールの動的設定を要求するために設計されています。動的コンフィギュレーションデータを有効にすると邪魔されることなく、これらのデバイスを横断するように流れることを含む、特定のデータの、並びにブロッキングがインバウンドファイアウォールで流れます。フローデータを有効にすると、データフローのパケットが転送されると、NATバインディングを作成することを可能にする作用をもつファイアウォールルールのロードを必要とします。データフローのブロックは、データフローパケットの転送を拒否するアクションと、ファイアウォールルールのロードを必要とします。データを有効にするための簡単な例は、フロー：ソースホストは、そのデータの宛先に向かっNATFW NSLPシグナリングメッセージを送信します。このメッセージは、データ経路をたどります。データパスに沿ってすべてのNATFW NSLP対応のNAT /ファイアウォールは、このメッセージを傍受し、それを処理し、それに応じて自分自身を設定します。その後、実際のデータの流れは、これらすべての構成のファイアウォール/ NATのを通過することができます。
It is necessary to distinguish between two different basic scenarios when operating the NATFW NSLP, independent of the type of the middleboxes to be configured.
それはNATFW NSLPを操作するときに、2つの異なる基本的なシナリオを区別する必要がある、中間装置のタイプとは無関係に構成することができます。
1. Both the data sender and data receiver are NSIS NATFW NSLP aware. This includes the cases in which the data sender is logically decomposed from the initiator of the NSIS signaling (the so-called NSIS initiator) or the data receiver logically decomposed from the receiver of the NSIS signaling (the so-called NSIS receiver), but both sides support NSIS. This scenario assumes deployment of NSIS all over the Internet, or at least at all NATs and firewalls. This scenario is used as a base assumption, if not otherwise noted.
1.データ送信側とデータ受信側の両方がNSIS NATFW NSLPが認識しています。これは、データの送信者が論理的NSISシグナリング（いわゆるNSIS開始剤）または論理的NSISシグナリング（いわゆるNSIS受信機）の受信機から分解データ受信の開始から分解された場合を含むが両サイドにはNSISをサポートしています。このシナリオでは、すべてのインターネット上でNSISの展開を想定している、あるいは少なくともすべてのNATやファイアウォールで。特記しない場合、このシナリオは、基地前提として使用されます。
2. Only one end host or region of the network is NSIS NATFW NSLP aware, either the data receiver or data sender. This scenario is referred to as proxy mode.
ネットワークの2つだけエンドホストまたは領域は、データ受信またはデータ送信側のいずれか、NSIS NATFW NSLPが認識しています。このシナリオは、プロキシモードと呼ばれています。
The NATFW NSLP has two basic signaling messages that are sufficient to cope with the various possible scenarios likely to be encountered before and after widespread deployment of NSIS:
NATFW NSLPはNSISの広範な展開の前と後に遭遇する可能性が高い様々な可能なシナリオに対処するのに十分である二つの基本的なシグナリング・メッセージがあります。
CREATE message: Sent by the data sender for configuring a path outbound from a data sender to a data receiver.
メッセージを作成：データ受信機へのデータ送信元からのパスアウトバウンドを構成するためのデータの送信者によって送信されます。
EXTERNAL message: Used by a data receiver to locate inbound NATs/ firewalls and prime them to expect inbound signaling and used at NATs to pre-allocate a public address. This is used for data receivers behind these devices to enable their reachability.
外部メッセージ：彼らはインバウンドシグナリングを期待するのは、インバウンドのNAT /ファイアウォールと素数を見つけるためにデータ受信機によって使用され、事前に割り当てるパブリックアドレスにNATのに使用。これは、彼らの到達可能性を可能にするために、これらのデバイスの背後にあるデータ受信器に使用されます。
CREATE and EXTERNAL messages are sent by the NSIS initiator (NI) towards the NSIS responder (NR). Both types of message are acknowledged by a subsequent RESPONSE message. This RESPONSE message is generated by the NR if the requested configuration can be established; otherwise, the NR or any of the NSLP forwarders (NFs) can also generate such a message if an error occurs. NFs and the NR can also generate asynchronous messages to notify the NI, the so-called NOTIFY messages.
CREATEおよび外部メッセージはNSIS応答者（NR）に向かってNSIS開始剤（NI）によって送信されます。メッセージの両方のタイプは、後続の応答メッセージによって確認されています。要求された構成を確立することができる場合は、この応答メッセージは、NRによって生成されます。エラーが発生した場合、さもなければ、NRまたはNSLPフォワーダ（NFS）のいずれかはまた、そのようなメッセージを生成することができます。 NFSとNRもNI、NOTIFYいわゆるメッセージを通知する非同期メッセージを生成することができます。
If the data receiver resides in a private addressing realm or behind a firewall, and it needs to preconfigure the edge-NAT/edge-firewall to provide a (publicly) reachable address for use by the data sender, a combination of EXTERNAL and CREATE messages is used.
データ受信機は、プライベートアドレス指定の領域でまたはファイアウォールの背後にある、それは、データの送信者が使用するために（公的）到達可能なアドレスを提供EXTERNALの組み合わせとメッセージを作成するために、エッジ-NAT /エッジファイアウォールを事前設定する必要がある場合使用されている。
During the introduction of NSIS, it is likely that one or the other of the data sender and receiver will not be NSIS aware. In these cases, the NATFW NSLP can utilize NSIS-aware middleboxes on the path between the data sender and data receiver to provide proxy NATFW NSLP services (i.e., the proxy mode). Typically, these boxes will be at the boundaries of the realms in which the end hosts are located.
NSISの導入時には、データの送信者と受信者のどちらか一方がNSIS気づかないだろうと思われます。これらのケースでは、NATFW NSLPプロキシNATFW NSLPサービス（すなわち、プロキシモード）を提供するために、データ送信元とデータ受信装置との間の経路上のNSIS認識中間装置を利用することができます。典型的には、これらのボックスは、エンドホストが配置されているレルムの境界であろう。
The CREATE and EXTERNAL messages create NATFW NSLP and NTLP state in NSIS entities. NTLP state allows signaling messages to travel in the forward (outbound) and the reverse (inbound) direction along the path between a NAT/firewall NSLP sender and a corresponding receiver. This state is managed using a soft-state mechanism, i.e., it expires unless it is refreshed from time to time. The NAT bindings and firewall rules being installed during the state setup are bound to the particular signaling session. However, the exact local implementation of the NAT bindings and firewall rules are NAT/ firewall specific and it is out of the scope of this memo.
CREATEおよび外部メッセージは、NSIS実体にNATFW NSLPとNTLPステートを作成します。 NTLP状態は、フォワード（アウトバウンド）とNAT /ファイアウォールNSLP送信側と対応する受信機との間の経路に沿って逆方向（受信）方向に移動するシグナリングメッセージを可能にします。この状態は、それがリフレッシュされない限り、すなわち、それは時間から時間に満了し、ソフトステートメカニズムを使用して管理されています。状態のセットアップ時にインストールされているNATバインディングとファイアウォールルールは、特定のシグナリングセッションにバインドされています。しかし、NATバインディングとファイアウォールルールの正確な局所的な実装がNAT /ファイアウォール固有のものであり、それはこのメモの範囲外です。
This memo is structured as follows. Section 2 describes the network environment for NATFW NSLP signaling. Section 3 defines the NATFW signaling protocol and Section 4 defines the message components and the overall messages used in the protocol. The remaining parts of the main body of the document cover security considerations Section 5, IAB considerations on UNilateral Self-Address Fixing
次のようにこのメモは構成されています。第2節ではNATFW NSLPシグナリングのためのネットワーク環境を説明しています。セクション3はNATFWシグナリングプロトコルを定義し、セクション4は、メッセージコンポーネント及びプロトコルで使用される全体的なメッセージを定義します。原稿カバーSecurity Considerations部5の本体の残りの部分は、一方的な自己アドレスのIABの考慮事項が修正します
(UNSAF) [RFC3424] in Section 6, and IANA considerations in Section 7. Please note that readers familiar with firewalls and NATs and their possible location within networks can safely skip Section 2.
第7節6（UNSAF）[RFC3424]、およびIANA問題はネットワーク内のファイアウォールおよびNATの精通読者及びそれらの可能な位置が安全セクション2をスキップすることができることに注意してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document uses a number of terms defined in [RFC3726] and [RFC4080]. The following additional terms are used:
このドキュメントは[RFC3726]及び[RFC4080]で定義された多数の用語を使用します。次の追加の用語が使用されます。
o Policy rule: A policy rule is "a basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions - where the conditions are evaluated to determine whether the actions are performed" [RFC3198]. In the context of NSIS NATFW NSLP, the conditions are the specification of a set of packets to which the rule is applied. The set of actions always contains just a single element per rule, and is limited to either action "deny" or action "allow".
Oポリシールール：ポリシールールは、「ポリシーベースのシステムの基本的なビルディングブロックこれは条件のセットにアクションのセットの結合されている - 条件はアクションが実行されているかどうかを決定するために評価されている。」[RFC3198 ]。 NSIS NATFW NSLPの文脈では、条件は、ルールが適用されるパケットのセットの仕様です。アクションのセットは、常にルールごとに1つだけの要素が含まれており、いずれかのアクション「拒否」またはアクション「許可」に限定されています。
o Reserved policy rule: A policy rule stored at NATs or firewalls for activation by a later, different signaling exchange. This type of policy rule is kept in the NATFW NSLP and is not loaded into the firewall or NAT engine, i.e., it does not affect the data flow handling.
以降、異なるシグナリング交換により活性化するためのNATまたはファイアウォールに記憶されたポリシールール：Oポリシールールを予約。ポリシールールのこのタイプはNATFW NSLPに保管されており、ファイアウォールやNATエンジンにロードされていない、すなわち、それは、データフローの処理には影響を与えません。
o Installed policy rule: A policy rule in operation at NATs or firewalls. This type of rule is kept in the NATFW NSLP and is loaded into the firewall or NAT engine, i.e., it is affecting the data flow.
NATのか、ファイアウォールで動作して政策ルール：Oポリシールールをインストール。このタイプのルールはNATFW NSLPに保管されており、ファイアウォールやNATエンジンにロードされ、すなわち、それは、データフローに影響を及ぼしています。
o Remembered policy rule: A policy rule stored at NATs and firewalls for immediate use, as soon as the signaling exchange is successfully completed.
すぐにシグナリング交換が正常に完了すると、すぐに使用するためのNATやファイアウォールで保存されたポリシールール：Oポリシールールを思い出しました。
o Firewall: A packet filtering device that matches packets against a set of policy rules and applies the actions.
Oファイアウォール：ポリシールールのセットに対してパケットを照合し、アクションを適用パケットフィルタリング装置。
o Network Address Translator: Network Address Translation is a method by which IP addresses are mapped from one IP address realm to another, in an attempt to provide transparent routing between hosts (see [RFC2663]). Network Address Translators are devices that perform this work by modifying packets passing through them.
Oネットワークアドレス変換：ネットワークアドレス変換（[RFC2663]を参照）ホスト間の透過的なルーティングを提供するための試みにおいて、IPアドレスが別のIPアドレス領域からマッピングされる方法です。ネットワークアドレス変換は、それらを通過するパケットを変更することで、この作業を実行する装置です。
o Data Receiver (DR): The node in the network that is receiving the data packets of a flow.
Oデータ受信（DR）：フローのデータ・パケットを受信しているネットワーク内のノード。
o Data Sender (DS): The node in the network that is sending the data packets of a flow.
Oデータ送信側（DS）：フローのデータ・パケットを送信しているネットワーク内のノード。
o NATFW NSLP peer (or simply "peer"): An NSIS NATFW NSLP node with which an NTLP adjacency has been created as defined in [RFC5971].
O NATFW NSLPピア（または単に「ピア」）：[RFC5971]で定義されるようにNTLP隣接関係が作成されたとNSIS NATFW NSLPノード。
o NATFW NSLP signaling session (or simply "signaling session"): A signaling session defines an association between the NI, NFs, and the NR related to a data flow. All the NATFW NSLP peers on the path, including the NI and the NR, use the same identifier to refer to the state stored for the association. The same NI and NR may have more than one signaling session active at any time. The state for the NATFW NSLP consists of NSLP state and associated policy rules at a middlebox.
O NATFW NSLPは、セッションシグナリング（または単に「セッションシグナリング」）：シグナリングセッションは、データフローに関連するNI、NFS、およびNR間の関連付けを定義します。 NIおよびNR含む経路上の全てのNATFW NSLPピアは、関連付けのために保存された状態を指すために同じ識別子を使用します。同じNIおよびNRはいつでもアクティブに複数のシグナリングセッションを有していてもよいです。 NATFW NSLPのための状態は、ミドルにNSLP状態と関連するポリシー・ルールから成ります。
o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP address that is reachable from the public Internet.
Oエッジ-NAT：エッジ-NATは、パブリックインターネットから到達可能であるグローバルにルーティング可能なIPアドレスを持つNATデバイスです。
o Edge-firewall: An edge-firewall is a firewall device that is located on the borderline of an administrative domain.
Oエッジファイアウォール：エッジファイアウォールは、管理ドメインの境界に位置しているファイアウォールデバイスです。
o Public Network: "A Global or Public Network is an address realm with unique network addresses assigned by Internet Assigned Numbers Authority (IANA) or an equivalent address registry. This network is also referred as external network during NAT discussions" [RFC2663].
Oパブリックネットワーク：[RFC2663]「グローバルまたはパブリックネットワークは、IANA（Internet Assigned Numbers Authority）のまたは同等のアドレスレジストリによって割り当てられた固有のネットワークアドレスとアドレスレルムである。このネットワークは、NAT議論の中に外部ネットワークと呼ばれています」。
o Private/Local Network: "A private network is an address realm independent of external network addresses. Private network may also be referred alternately as Local Network. Transparent routing between hosts in private realm and external realm is facilitated by a NAT router" [RFC2663].
Oローカル/プライベートネットワーク：「プライベートネットワークが外部ネットワークアドレスとは無関係にアドレス領域であるプライベートネットワークは、ローカルネットワークとして交互に呼ばれることがあるプライベート領域と外部領域内のホスト間の透過的なルーティングは、NATルータによって促進される。」[RFC2663 ]。
o Public/Global IP address: An IP address located in the public network according to Section 2.7 of [RFC2663].
O公開/グローバルIPアドレス：[RFC2663]のセクション2.7に応じてパブリックネットワークにあるIPアドレス。
o Private/Local IP address: An IP address located in the private network according to Section 2.8 of [RFC2663].
Oプライベート/ローカルIPアドレス：[RFC2663]のセクション2.8に応じてプライベートネットワーク内にあるIPアドレス。
o Signaling Destination Address (SDA): An IP address generally taken from the public/global IP address range, although, the SDA may, in certain circumstances, be part of the private/local IP address range. This address is used in EXTERNAL signaling message exchanges, if the data receiver's IP address is unknown.
宛先アドレス（SDA）シグナリング（O）が、一般的にグローバル/パブリックIPアドレスの範囲から採取したIPアドレスを、SDAは、特定の状況において、ローカル/プライベートIPアドレス範囲の一部であってもよいです。データ受信者のIPアドレスが不明な場合は、このアドレスは、外部シグナリングメッセージの交換に使用されています。
The same deployment issues and extensibility considerations described in [RFC5971] and [RFC5978] also apply to this document.
展開の問題と[RFC5971]と[RFC5978]で説明した拡張性の考慮も同様で、この文書に適用されます。
The term "middlebox" covers a range of devices and is well-defined in [RFC3234]: "A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and a destination host". As such, middleboxes fall into a number of categories with a wide range of functionality, not all of which is pertinent to the NATFW NSLP. Middlebox categories in the scope of this memo are firewalls that filter data packets against a set of filter rules, and NATs that translate packet addresses from one address realm to another address realm. Other categories of middleboxes, such as QoS traffic shapers, are out of the scope of this memo.
用語「ミドル」は、デバイスの範囲をカバーし、[RFC3234]に明確に定義されている：「ミドルボックスは、ソースホストとの間のデータグラムの経路上のIPルータの通常の、標準的な機能以外の機能を実行する任意の中間デバイスとして定義されていますそして、宛先ホスト」。このように、中間装置はNATFW NSLPに適切ではないすべてが幅広い機能とカテゴリの数に落ちます。このメモの範囲におけるミドルカテゴリは別のアドレス領域を一つのアドレス領域からパケットのアドレスを変換フィルタ規則のセット、およびNATのに対してフィルタデータパケットファイアウォールです。そのようなQoSトラフィックシェーパーとしてミドルボックスの他のカテゴリでは、このメモの範囲外です。
The term "NAT" used in this document is a placeholder for a range of different NAT flavors. We consider the following types of NATs:
この文書で使用される用語「NAT」は、異なるNAT風味の範囲のプレースホルダです。私たちは、NATを、次のタイプを考慮してください。
o Traditional NAT (basic NAT and NAPT)
Oの伝統的なNAT（基本NATとNAPT）
o Bi-directional NAT
O双方向NAT
o Twice-NAT
OトワイスNAT
o Multihomed NAT
マルチホームNAT O
For definitions and a detailed discussion about the characteristics of each NAT type, please see [RFC2663].
定義と各NATタイプの特性についての詳細な議論については、[RFC2663]を参照してください。
All types of middleboxes under consideration here use policy rules to make a decision on data packet treatment. Policy rules consist of a flow identifier that selects the packets to which the policy applies and an associated action; data packets matching the flow identifier are subjected to the policy rule action. A typical flow identifier is the 5-tuple selector that matches the following fields of a packet to configured values:
ここで検討中のミドルボックスのすべての種類は、データパケット処理上の意思決定を行うためにポリシールールを使用します。ポリシールールは、ポリシーが適用されるパケットと関連付けられたアクションを選択するフロー識別子から成ります。フロー識別子と一致するデータパケットは、ポリシールールアクションが施されます。典型的なフロー識別子が設定された値にパケットの次のフィールドに一致する5タプルセレクタです。
o Source and destination IP addresses
Oソースと宛先のIPアドレス
o Transport protocol number
Oトランスポートプロトコル番号
o Transport source and destination port numbers
Oトランスポート送信元と送信先のポート番号
Actions for firewalls are usually one or more of:
ファイアウォールのためのアクションは、通常、1つまたは複数、次のとおりです。
o Allow: forward data packet
O許可：順方向データ・パケットを
o Deny: block data packet and discard it
ブロックデータパケットを、それを破棄します。o拒否
o Other actions such as logging, diverting, duplicating, etc.
ロギングなど他のアクション、複製、転用Oなど
Actions for NATs include (amongst many others):
NATのためのアクションは、（他の多くの中で）次のとおりです。
o Change source IP address and transport port number to a globally routable IP address and associated port number.
グローバルにルーティング可能なIPアドレスと関連付けられたポート番号にOを変更し、送信元IPアドレスとトランスポートのポート番号。
o Change destination IP address and transport port number to a private IP address and associated port number.
プライベートIPアドレスと関連付けられているポート番号に変更し、宛先IPアドレス、Oおよび輸送ポート番号。
It should be noted that a middlebox may contain two logical representations of the policy rule. The policy rule has a representation within the NATFW NSLP, comprising the message routing information (MRI) of the NTLP and NSLP information (such as the rule action). The other representation is the implementation of the NATFW NSLP policy rule within the NAT and firewall engine of the particular device. Refer to Appendix D for further details.
ミドルボックスは、ポリシールールの二つの論理表現を含んでいてもよいことに留意すべきです。ポリシールールは、（ルールアクションとして）NTLP及びNSLP情報のメッセージルーティング情報（MRI）を含む、NATFW NSLP内表現を有しています。他の表現は、特定のデバイスのNATやファイアウォールエンジン内NATFW NSLPポリシールールの実装です。詳細については、付録Dを参照してください。
The purpose of NSIS NATFW signaling is to enable communication between endpoints across networks, even in the presence of NAT and firewall middleboxes that have not been specially engineered to facilitate communication with the application protocols used. This removes the need to create and maintain application layer gateways for specific protocols that have been commonly used to provide transparency in previous generations of NAT and firewall middleboxes. It is assumed that these middleboxes will be statically configured in such a way that NSIS NATFW signaling messages themselves are allowed to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP signaling is used to dynamically install additional policy rules in all NATFW middleboxes along the data path that will allow transmission of the application data flow(s). Firewalls are configured to forward data packets matching the policy rule provided by the NSLP signaling. NATs are configured to translate data packets matching the policy rule provided by the NSLP signaling. An additional capability, that is an exception to the primary goal of NSIS NATFW signaling, is that the NATFW nodes can request blocking of particular data flows instead of enabling these flows at inbound firewalls.
NSIS NATFWシグナリングの目的は、さらに特別に使用されるアプリケーションプロトコルとの通信を容易にするように操作されていないNAT及びファイアウォール中間装置の存在下で、ネットワークを介してエンドポイント間の通信を可能にすることです。これは、一般的にNATやファイアウォールミドルボックスの前の世代の透明性を提供するために使用されている特定のプロトコルのためのアプリケーションレイヤゲートウェイを作成し、維持する必要がなくなります。これらのミドルボックスは、静的にNSIS NATFW自体はローカルにインストールNATFW NSLPデーモンに到達するために許可されているシグナリングメッセージを、このような方法で構成されることが想定されます。 NSIS NATFW NSLPシグナリングは、動的にアプリケーション・データ・フロー（単数または複数）の送信を可能にするデータパスに沿ったすべてのNATFWの中間装置に追加のポリシールールをインストールするために使用されます。ファイアウォールはNSLPシグナリングによって提供されるポリシールールに合致するデータパケットを転送するように構成されています。 NATはNSLPシグナリングによって提供されるポリシールールに合致するデータ・パケットを変換するように構成されています。追加機能、すなわちNSIS NATFWシグナル伝達の主な目標に例外で、NATFWノードが特定のデータのブロックを要求することができることをインバウンドファイアウォールでこれらの流れを可能にするのではなく流れます。
The basic high-level picture of NSIS usage is that end hosts are located behind middleboxes, meaning that there is at least one middlebox on the data path from the end host in a private network to the external network (NATFW in Figure 1). Applications located at these end hosts try to establish communication with corresponding applications on other such end hosts. This communication establishment may require that the applications contact an application server that serves as a rendezvous point between both parties to exchange their IP address and port(s). The local applications trigger the NSIS entity at the local host to control provisioning for middlebox traversal along the prospective data path (e.g., via an API call). The NSIS entity, in turn, uses NSIS NATFW NSLP signaling to establish policy rules along the data path, allowing the data to travel from the sender to the receiver without obstruction.
NSISの使用の基本的なハイレベルの画像は、エンドホストが外部ネットワーク（図1のNATFW）に、プライベートネットワーク内のエンドホストからのデータ・パス上の少なくとも一つのミドルがあることを意味し、中間装置の背後に配置されることです。これらのエンドホストに配置されたアプリケーションは、そのような他のエンドホスト上の対応するアプリケーションとの通信を確立しよう。この通信の確立は、アプリケーションがそれらのIPアドレスとポート（単数または複数）を交換するために、両当事者間のランデブーポイントとして機能するアプリケーションサーバに連絡することを必要とするかもしれません。ローカルアプリケーション（例えば、API呼び出しを介して）将来のデータ経路に沿ってミドルトラバーサルのプロビジョニングを制御するローカルホストにおいてNSISエンティティをトリガーします。 NSISエンティティは、順番に、データが障害なく送信者から受信者へ旅行することができ、データパスに沿って政策ルールを確立するためのシグナリングNSIS NATFW NSLPを使用しています。
Application Application Server (0, 1, or more) Application
アプリケーションアプリケーションサーバ（0、1、またはそれ以上）のアプリケーション
+----+ +----+ +----+
| +------------------------+ +------------------------+ |
+-+--+ +----+ +-+--+
| |
| NSIS Entities NSIS Entities |
+-+--+ +----+ +-----+ +-+--+
| +--------+ +----------------------------+ +-----+ |
+-+--+ +-+--+ +--+--+ +-+--+
| | ------ | |
| | //// \\\\\ | |
+-+--+ +-+--+ |/ | +-+--+ +-+--+
| | | | | Internet | | | | |
| +--------+ +-----+ +----+ +-----+ |
+----+ +----+ |\ | +----+ +----+
\\\\ /////
sender NATFW (1+) ------ NATFW (1+) receiver
Note that 1+ refers to one or more NATFW nodes.
1+一個の以上NATFWノードを指すことに留意されたいです。
Figure 1: Generic View of NSIS with NATs and/or Firewalls
図1：NATのおよび/またはファイアウォールとNSISの汎用ビュー
For end-to-end NATFW signaling, it is necessary that each firewall and each NAT along the path between the data sender and the data receiver implements the NSIS NATFW NSLP. There might be several NATs and FWs in various possible combinations on a path between two hosts. Section 2 presents a number of likely scenarios with different combinations of NATs and firewalls. However, the scenarios given in the following sections are only examples and should not be treated as limiting the scope of the NATFW NSLP.
エンドツーエンドNATFWシグナリングのためには、各ファイアウォールとデータ送信元とデータ受信装置との間の経路に沿った各NATがNSIS NATFW NSLPを実装することが必要です。 2つのホスト間のパス上の様々な可能な組み合わせでいくつかのNATとのFWがあるかもしれません。第2節では、NATのファイアウォールの異なる組み合わせを持つ可能性の高いシナリオの数を示します。ただし、以下のセクションで与えられたシナリオは単なる例であり、NATFW NSLPの範囲を限定するものとして扱われるべきではありません。
This section introduces several scenarios for middlebox placement within IP networks. Middleboxes are typically found at various different locations, including at enterprise network borders, within enterprise networks, as mobile phone network gateways, etc. Usually, middleboxes are placed more towards the edge of networks than in network cores. Firewalls and NATs may be found at these locations either alone or combined; other categories of middleboxes may also be found at such locations, possibly combined with the NATs and/or firewalls.
このセクションでは、IPネットワーク内のミドル配置のためのいくつかのシナリオを紹介します。中間装置は、典型的には、通常、中間装置は、ネットワークコアにおけるよりもネットワークのエッジに向かって複数に配置されている等の携帯電話ネットワークゲートウェイ、として、企業ネットワーク内で、企業ネットワークの境界を含め、様々な異なる場所で発見されます。ファイアウォールおよびNATは、単独または組み合わせのいずれかで、これらの場所で見つけることができます。中間装置の他のカテゴリも、おそらくのNAT及び/又はファイアウォールと組み合わせて、そのような場所で見つけることができます。
NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the regular data path to the NSIS responder (NR). On the data path, NATFW NSLP signaling messages reach different NSIS nodes that implement the NATFW NSLP. Each NATFW NSLP node processes the signaling messages according to Section 3 and, if necessary, installs policy rules for subsequent data packets.
NSIS開始剤（NI）NSIS応答者（NR）に通常のデータ経路を介してNSIS NATFW NSLPシグナリングメッセージを送信します。データ経路上、NATFW NSLPシグナリングメッセージはNATFW NSLPを実装異なるNSISノードに到達します。各NATFW NSLPノードは、セクション3に記載のシグナリングメッセージを処理し、必要に応じて、後続のデータパケットのためのポリシールールをインストールします。
Each of the following sub-sections introduces a different scenario for a different set of middleboxes and their ordering within the topology. It is assumed that each middlebox implements the NSIS NATFW NSLP signaling protocol.
以下のサブセクションでは、それぞれ異なるミドルボックスのセットと、トポロジ内での順序のための別のシナリオを紹介します。各ミドルボックスは、NSIS NATFW NSLPシグナリングプロトコルを実装しているものとします。
This section describes a scenario with firewalls only; NATs are not involved. Each end host is behind a firewall. The firewalls are connected via the public Internet. Figure 2 shows the topology. The part labeled "public" is the Internet connecting both firewalls.
このセクションでは、ファイアウォールとのシナリオについて説明します。 NATは関与していません。各エンドホストがファイアウォールの背後にあります。ファイアウォールは、公共のインターネットを介して接続されています。図2は、トポロジーを示します。 「公共」と表示された部分は、両方のファイアウォールを接続するインターネットです。
+----+ //----\\ +----+
NI -----| FW |---| |------| FW |--- NR
+----+ \\----// +----+
private public private
プライベート、パブリック、プライベート
FW: Firewall NI: NSIS Initiator NR: NSIS Responder
FW：ファイアウォールNI：NSISイニシエータNR：NSISレスポンダ
Figure 2: Firewall Traversal Scenario
図2：ファイアウォールトラバーサルシナリオ
Each firewall on the data path must provide traversal service for NATFW NSLP in order to permit the NSIS message to reach the other end host. All firewalls process NSIS signaling and establish appropriate policy rules, so that the required data packet flow can traverse them.
データパス上の各ファイアウォールは、他のエンドホストに到達するためにNSISメッセージを可能にするためにNATFW NSLPのためのトラバーサルサービスを提供しなければなりません。すべてのファイアウォールプロセスNSISシグナリングおよび必要なデータ・パケット・フローがそれらを通過することができるように、適切なポリシールールを確立します。
There are several very different ways to place firewalls in a network topology. To distinguish firewalls located at network borders, such as administrative domains, from others located internally, the term edge-firewall is used. A similar distinction can be made for NATs, with an edge-NAT fulfilling the equivalent role.
ネットワークトポロジでファイアウォールを配置するには、いくつかの非常に異なる方法があります。内部に配置他人から、そのような管理ドメインなどのネットワークの境界に位置するファイアウォールを、区別するために、用語のエッジファイアウォールが使用されています。同様の区別は、エッジNAT同等の役割を果たしと、NATのために作製することができます。
Figure 3 shows a scenario with NATs at both ends of the network. Therefore, each application instance, the NSIS initiator and the NSIS responder, are behind NATs. The outermost NAT, known as the edge-NAT (MB2 and MB3), at each side is connected to the public Internet. The NATs are generically labeled as MBX (for middlebox No. X), since those devices certainly implement NAT functionality, but can implement firewall functionality as well.
図3は、ネットワークの両端にNATを有するシナリオを示します。したがって、各アプリケーションインスタンスは、NSISイニシエータとNSISレスポンダは、NATの背後にあります。各側縁NAT（MB2及びMB3）として知られている最も外側のNATは、公衆インターネットに接続されています。 NATのは、これらのデバイスは、確かにNAT機能を実装するため一般的に、（ミドル番号Xの場合）MBXとしてラベル付けされているが、同様に、ファイアウォール機能を実装することができます。
Only two middleboxes (MBs) are shown in Figure 3 at each side, but in general, any number of MBs on each side must be considered.
2つだけの中間装置（MBS）は、各側に、図3に示されているが、一般的に、各側のMBの任意の数を考慮しなければなりません。
+----+ +----+ //----\\ +----+ +----+
NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR
+----+ +----+ \\----// +----+ +----+
private public private
プライベート、パブリック、プライベート
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB：ミドルNI：NRイニシエータNSIS：NSISレスポンダ
Figure 3: NAT with two Private Networks Scenario
図3：2つのプライベートネットワークシナリオとNAT
Signaling traffic from the NI to the NR has to traverse all the middleboxes on the path (MB1 to MB4, in this order), and all the middleboxes must be configured properly to allow NSIS signaling to traverse them. The NATFW signaling must configure all middleboxes and consider any address translation that will result from this configuration in further signaling. The sender (NI) has to know the IP address of the receiver (NR) in advance, otherwise it will not be possible to send any NSIS signaling messages towards the responder. Note that this IP address is not the private IP address of the responder but the NAT's public IP address (here MB3's IP address). Instead, a NAT binding (including a public IP address) has to be previously installed on the NAT MB3. This NAT binding subsequently allows packets reaching the NAT to be forwarded to the receiver within the private address realm. The receiver might have a number of ways to learn its public IP address and port number (including the NATFW NSLP) and might need to signal this information to the sender using an application-level signaling protocol.
NRにNIからのトラフィックをシグナリングパス（この順序でMB4にMB1）上のすべての中間装置を横断しなければ、すべての中間装置は、それらを横断するシグナリングNSISを可能にするように適切に構成されなければなりません。 NATFWシグナリングは、すべてのミドルボックスを設定し、さらにシグナリングにおけるこの構成に起因する任意のアドレス変換を考慮する必要があります。送信者（NI）は、それ以外の場合は、応答者の方にどんなNSISシグナリングメッセージを送信することができません、事前に受信機（NR）のIPアドレスを知っている必要があります。このIPアドレスは、応答者のプライベートIPアドレスが、NATのパブリックIPアドレス（ここでMB3のIPアドレス）ではないことに注意してください。代わりに、NAT（パブリックIPアドレスを含む）結合は、以前NAT MB3にインストールする必要があります。その後結合このNATはNATに到達したパケットは、プライベートアドレス領域内の受信機に転送することができます。受信機は、（NATFW NSLPを含む）は、そのパブリックIPアドレスとポート番号を学ぶために、アプリケーション・レベルのシグナリングプロトコルを使用して送信者にこの情報をシグナリングする必要があるかもしれないいくつかの方法があるかもしれません。
This scenario shows an application instance at the sending node that is behind one or more NATs (shown as generic MB, see discussion in Section 2.2). The receiver is located in the public Internet.
このシナリオは、一つ以上のNAT（一般MBとして示され、セクション2.2で議論を参照）の背後にある送信ノードでアプリケーションインスタンスを示します。受信機は、公共のインターネットに位置しています。
+----+ +----+ //----\\
NI --| MB |-----| MB |---| |--- NR
+----+ +----+ \\----//
private public
官民
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB：ミドルNI：NRイニシエータNSIS：NSISレスポンダ
Figure 4: NAT with Private Network on Sender Side
図4：送信側のプライベートネットワークとNAT
The traffic from NI to NR has to traverse middleboxes only on the sender's side. The receiver has a public IP address. The NI sends its signaling message directly to the address of the NSIS responder. Middleboxes along the path intercept the signaling messages and configure accordingly.
NIからのNRへのトラフィックは、送信者の側にミドルボックスを通過しなければなりません。受信機は、パブリックIPアドレスを持っています。 NIは、NSIS応答者のアドレスに直接そのシグナリング・メッセージを送信します。シグナリングメッセージインターセプト経路に沿った中間装置及びそれに応じて設定します。
The data sender does not necessarily know whether or not the receiver is behind a NAT; hence, it is the receiving side that has to detect whether or not it is behind a NAT.
データ送信側は、必ずしも受信側がNATの背後にあるかどうか分かりません。したがって、それはNATの背後にあるか否かを検出する必要があり、受信側です。
The application instance receiving data is behind one or more NATs shown as MB (see discussion in Section 2.2).
データを受信したアプリケーションインスタンスは（セクション2.2の考察を参照）MBとして示す一つ以上のNATの背後にあります。
//----\\ +----+ +----+
NI ---| |---| MB |-----| MB |--- NR
\\----// +----+ +----+
public private
官民
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB：ミドルNI：NRイニシエータNSIS：NSISレスポンダ
Figure 5: NAT with Private Network on Receiver Scenario
図5：レシーバシナリオにプライベートネットワークを持つNAT
Initially, the NSIS responder must determine its publicly reachable IP address at the external middlebox and notify the NSIS initiator about this address. One possibility is that an application-level protocol is used, meaning that the public IP address is signaled via this protocol to the NI. Afterwards, the NI can start its signaling towards the NR and therefore establish the path via the middleboxes in the receiver side private network.
最初は、NSIS応答者は、外部のミドルでその公に到達可能なIPアドレスを決定し、このアドレスについてNSISイニシエータに通知しなければなりません。一つの可能性は、パブリックIPアドレスがNIにこのプロトコルを介してシグナリングされることを意味し、アプリケーションレベルのプロトコルが使用されることです。その後、NIは、NRに対するそのシグナル伝達を開始することができ、したがって、受信側プライベートネットワーク内の中間装置を介してパスを確立します。
This scenario describes the use case for the EXTERNAL message of the NATFW NSLP.
このシナリオはNATFW NSLPの外部メッセージのためのユースケースを記述しています。
This is a special case, where the main problem arises from the need to detect that both end hosts are logically within the same address space, but are also in two partitions of the address realm on either side of a twice-NAT (see [RFC2663] for a discussion of twice-NAT functionality).
これは、（[RFC2663を参照してください主な問題は、両方のエンドホストが同じアドレス空間内に論理的ですが、二回-NATのいずれかの側のアドレスレルムの2つのパーティションにもあることを検出する必要性から生じる特殊なケースであり、 ]）を2回-NAT機能の議論のために。
Sender and receiver are both within a single private address realm, but the two partitions potentially have overlapping IP address ranges. Figure 6 shows the arrangement of NATs.
送信者と受信者は、単一のプライベートアドレス領域内の両方のですが、2つのパーティションには、潜在的にオーバーラップするIPアドレスの範囲を持っています。図6は、のNATの構成を示しています。
public
公
+----+ +----+ //----\\
NI --| MB |--+--| MB |---| |
+----+ | +----+ \\----//
|
| +----+
+--| MB |------------ NR
+----+
private
民間
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB：ミドルNI：NRイニシエータNSIS：NSISレスポンダ
Figure 6: NAT to Public, Sender and Receiver on Either Side of a Twice-NAT Scenario
図6：トワイスNATのシナリオのいずれかの側に公開、送信者と受信者へのNAT
The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP addresses and port numbers on both sides, meaning the mapping of source and destination IP addresses at the private and public interfaces.
図6に示す中間装置、すなわち、彼らはプライベートとパブリックインターフェイスで送信元および宛先IPアドレスのマッピングを意味し、両側のIPアドレスとポート番号をマッピングし、二回のNATです。
This scenario requires the assistance of application-level entities, such as a DNS server. The application-level entities must handle requests that are based on symbolic names and configure the middleboxes so that data packets are correctly forwarded from NI to
このシナリオでは、このようなDNSサーバなどのアプリケーションレベルのエンティティの援助を必要とします。アプリケーションレベルのエンティティは、シンボル名に基づいて要求を処理し、データパケットが正しくにNIから転送されるように、ミドルボックスを設定する必要があります
NR. The configuration of those middleboxes may require other middlebox communication protocols, such as MIDCOM [RFC3303]. NSIS signaling is not required in the twice-NAT only case, since middleboxes of the twice-NAT type are normally configured by other means. Nevertheless, NSIS signaling might be useful when there are also firewalls on the path. In this case, NSIS will not configure any policy rule at twice-NATs, but will configure policy rules at the firewalls on the path. The NSIS signaling protocol must be at least robust enough to survive this scenario. This requires that twice-NATs must implement the NATFW NSLP also and participate in NATFW signaling sessions, but they do not change the configuration of the NAT, i.e., they only read the address mapping information out of the NAT and translate the Message Routing Information (MRI, [RFC5971]) within the NSLP and NTLP accordingly. For more information, see Appendix D.4.
NR。これらの中間装置の構成は、MIDCOM [RFC3303]などの他のミドル通信プロトコルを必要とするかもしれません。トワイスNATタイプの中間装置は、通常、他の手段によって構成されているので、NSISシグナリングは、トワイスNAT場合にのみ必要とされません。また、パス上にファイアウォールがある場合にもかかわらず、NSISシグナリングが便利かもしれません。この場合、NSISは二回、NATので任意のポリシールールを設定しませんが、パス上のファイアウォールで、ポリシールールを設定します。 NSISシグナリングプロトコルは、このシナリオを生き残るために少なくとも十分に堅牢でなければなりません。これを2回-NATのは（もNATFW NSLPを実装し、シグナリングセッションNATFWに参加し、彼らはNATの設定を変更しない、すなわち、彼らは唯一のNATのうち、アドレスマッピング情報を読み、メッセージのルーティング情報を翻訳しなければならないことを要求しますしたがってNSLP内MRI、[RFC5971]）とNTLP。詳細については、付録D.4を参照してください。
When the NSIS initiator and NSIS responder are behind the same NAT (thus, being in the same address realm, see Figure 7), they are most likely not aware of this fact. As in Section 2.4, the NSIS responder must determine its public IP address in advance and transfer it to the NSIS initiator. Afterwards, the NSIS initiator can start sending the signaling messages to the responder's public IP address. During this process, a public IP address will be allocated for the NSIS initiator at the same middlebox as for the responder. Now, the NSIS signaling and the subsequent data packets will traverse the NAT twice: from initiator to public IP address of responder (first time) and from public IP address of responder to responder (second time).
NSISイニシエータとNSIS応答者が同じNATの背後にある場合には、彼らが最も可能性の高いこの事実を認識していない、（したがって、同じアドレスレルムにある、図7を参照）。 2.4節と同様に、NSIS応答者は、事前にそのパブリックIPアドレスを決定しなければならないとNSISイニシエータに転送します。その後、NSISイニシエータは、レスポンダのパブリックIPアドレスへのシグナリングメッセージの送信を開始することができます。このプロセスの間、パブリックIPアドレスは、応答者の場合と同じミドルでNSISイニシエータに割り当てられます。今、NSISシグナリング及び後続のデータパケットは、二回NATを横断する：イニシエータからレスポンダのパブリックIPアドレス（1回目）およびレスポンダのパブリックIPアドレスからの（2回目）をレスポンダに。
NI public
\ +----+ //----\\
+-| MB |----| |
/ +----+ \\----//
NR
private
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB：ミドルNI：NRイニシエータNSIS：NSISレスポンダ
Figure 7: NAT to Public, Both Hosts behind Same NAT
図7：公衆へのNAT、同じNATの背後にある両方のホスト
The previous sub-sections sketched network topologies where several NATs and/or firewalls are ordered sequentially on the path. This section describes a multihomed scenario with two NATs placed on alternative paths to the public network.
前のサブセクションでは、いくつかのNATおよび/またはファイアウォールがパス上に順次順序付けされるネットワークトポロジをスケッチ。このセクションでは、公衆網への代替パスに配置された2つのNATを有するマルチホームシナリオを記述する。
+----+ //---\\
NI -------| MB |---| |
\ +----+ \\-+-//
\ |
\ +----- NR
\ |
\ +----+ //-+-\\
--| MB |---| |
+----+ \\---//
private public
官民
MB: Middlebox
NI: NSIS Initiator
NR: NSIS Responder
Figure 8: Multihomed Network with Two NATs
図8：二つのNATを持つマルチホームネットワーク
Depending on the destination, either one or the other middlebox is used for the data flow. Which middlebox is used, depends on local policy or routing decisions. NATFW NSLP must be able to handle this situation properly, see Section 3.7.2 for an extended discussion of this topic with respect to NATs.
先に応じて、一方または他方のミドルは、データフローのために使用されます。使用されているミドル、ローカルポリシーやルーティングの決定に依存します。 NATFW NSLPは、NATをに関して、このトピックの延長の議論については、セクション3.7.2を参照してください、この状況を適切に処理できなければなりません。
This section describes a multihomed scenario with two firewalls placed on alternative paths to the public network (Figure 9). The routing in the private and public networks decides which firewall is being taken for data flows. Depending on the data flow's direction, either outbound or inbound, a different firewall could be traversed. This is a challenge for the EXTERNAL message of the NATFW NSLP where the NSIS responder is located behind these firewalls within the private network. The EXTERNAL message is used to block a particular data flow on an inbound firewall. NSIS must route the EXTERNAL message inbound from NR to NI probably without knowing which path the data traffic will take from NI to NR (see also Appendix C).
このセクションでは、公衆網への代替パス上に配置された2つのファイアウォール（図9）とマルチホームシナリオを記述する。プライベートおよびパブリックネットワークのルーティング、ファイアウォール、データ・フローのために取られているかを決定します。送信または受信のどちらか、データフローの方向に応じて、異なるファイアウォールを横断することができます。これは、NSIS応答者がプライベートネットワーク内でこれらのファイアウォールの背後に配置されているNATFW NSLPの外部メッセージのための挑戦です。外部メッセージは、インバウンドファイアウォール上の特定のデータフローを遮断するために使用されます。 NSISは（また、付録Cを参照してください）、おそらくデータトラフィックがNRにNIからかかりますどのパスを知らずにルートNIにNRからのインバウンド外部メッセージをしなければなりません。
+----+
NR -------| FW |\
\ +----+ \ //---\\
\ -| |-- NI
\ \\---//
\ +----+ |
--| FW |-------+
+----+
private
private public
官民
FW: Firewall
NI: NSIS Initiator
NR: NSIS Responder
Figure 9: Multihomed Network with Two Firewalls
図9：2つのファイアウォールを持つマルチホームネットワーク
This section defines messages, objects, and protocol semantics for the NATFW NSLP.
このセクションでは、NATFW NSLPのメッセージ、オブジェクト、およびプロトコルのセマンティクスを定義します。
Policy rules, bound to a NATFW NSLP signaling session, are the building blocks of middlebox devices considered in the NATFW NSLP. For firewalls, the policy rule usually consists of a 5-tuple and an action such as allow or deny. The information contained in the tuple includes source/destination IP addresses, transport protocol, and source/destination port numbers. For NATs, the policy rule consists of the action 'translate this address' and further mapping information, that might be, in the simplest case, internal IP address and external IP address.
NATFW NSLPシグナリング・セッションにバインドされたポリシールールは、NATFW NSLPで考慮ミドルデバイスのビルディングブロックです。ファイアウォールは、ポリシールールは、通常、5タプルと許可または拒否などのアクションから成ります。タプルに含まれる情報は、送信元/宛先IPアドレス、トランスポートプロトコル、および送信元/宛先ポート番号を含みます。 NATのために、政策ルールは、最も単純なケースでは、内部IPアドレスと外部IPアドレス、あるかもしれないアクション「は、このアドレスを変換する」とさらにマッピング情報、から構成されています。
The NATFW NSLP carries, in conjunction with the NTLP's Message Routing Information (MRI), the policy rules to be installed at NATFW peers. This policy rule is an abstraction with respect to the real policy rule to be installed at the respective firewall or NAT. It conveys the initiator's request and must be mapped to the possible configuration on the particular used NAT and/or firewall in use. For pure firewalls, one or more filter rules must be created, and for pure NATs, one or more NAT bindings must be created. In mixed firewall and NAT boxes, the policy rule must be mapped to filter rules and bindings observing the ordering of the firewall and NAT engine. Depending on the ordering, NAT before firewall or vice versa, the firewall rules must carry public or private IP addresses. However, the exact mapping depends on the implementation of the firewall or NAT that is possibly different for each implementation.
NATFW NSLPがNTLPメッセージルーティング情報（MRI）と連携して、ポリシールールがNATFWピアにインストールされるように、運びます。このポリシールールは、それぞれのファイアウォールやNATに設置することが本当のポリシールールに関して抽象化です。それは、イニシエータの要求を伝えると、使用中の可能性、特定の使用NATの設定および/またはファイアウォールにマップする必要があります。純粋なファイアウォールのために、1つ以上のフィルタルールを作成する必要があり、そして純粋なNATのために、一つ以上のNATバインディングを作成する必要があります。混合ファイアウォールやNATボックスに、ポリシールールは、ファイアウォールやNATエンジンの順序を観察するルールとバインディングをフィルタリングするためにマッピングされなければなりません。順序によっては、NATファイアウォールまたはその逆の前に、ファイアウォールのルールは、パブリックまたはプライベートIPアドレスを運ぶ必要があります。しかし、正確なマッピングは、各実装の可能性が異なっているファイアウォールやNATの実装に依存します。
The policy rule at the NATFW NSLP level comprises the message routing information (MRI) part, carried in the NTLP, and the information available in the NATFW NSLP. The information provided by the NSLP is stored in the 'extend flow information' (NATFW_EFI) and 'data terminal information' (NATFW_DTINFO) objects, and the message type. Additional information, such as the external IP address and port number, stored in the NAT or firewall, will be used as well. The MRI carries the filter part of the NAT/firewall-level policy rule that is to be installed.
NATFW NSLPレベルのポリシールールはNTLPに伝えられるメッセージルーティング情報（MRI）部分、およびNATFW NSLPで利用可能な情報を含みます。 NSLPによって提供される情報は、「延びるフロー情報」（NATFW_EFI）とのデータ端末情報」（NATFW_DTINFO）オブジェクト、およびメッセージ・タイプに格納されています。 NATやファイアウォールに保存され、外部IPアドレスやポート番号などの追加情報は、同様に使用されます。 MRIは、インストールするNAT /ファイアウォールのレベルのポリシールールのフィルタ部を搬送します。
The NATFW NSLP specifies two actions for the policy rules: deny and allow. A policy rule with action set to deny will result in all packets matching this rule to be dropped. A policy rule with action set to allow will result in all packets matching this rule to be forwarded.
denyおよびallow：NATFW NSLPは、ポリシールールのための2つのアクションを指定します。拒否するように設定されたアクションを持つポリシールールがドロップされるこのルールに一致するすべてのパケットになります。許可するように設定されたアクションを持つポリシールールが転送されるように、このルールに一致するすべてのパケットになります。
The NSIS NATFW NSLP is carried over the General Internet Signaling Transport (GIST, the implementation of the NTLP) defined in [RFC5971]. NATFW NSLP messages are initiated by the NSIS initiator (NI), handled by NSLP forwarders (NFs) and received by the NSIS responder (NR). It is required that at least NI and NR implement this NSLP, intermediate NFs only implement this NSLP when they provide relevant middlebox functions. NSLP forwarders that do not have any NATFW NSLP functions just forward these packets as they have no interest in them.
NSIS NATFW NSLPは、一般的なインターネットシグナリングトランスポート（GIST、NTLPの実装）[RFC5971]で定義された上で行われます。 NATFW NSLPメッセージは、NSIS開始剤（NI）によって開始NSLPフォワーダ（NFS）によって処理され、NSIS応答者（NR）によって受信されます。彼らが関連するミドル機能を提供する際に、中間NFSはこれだけNSLPを実装し、NRこのNSLPを実装し、少なくともNIことが必要とされます。彼らはそれらに興味を持っていないとして任意のNATFW NSLP機能を持っていないNSLPフォワーダーは、単にこれらのパケットを転送します。
A data sender (DS), intending to send data to a data receiver (DR), has to start NATFW NSLP signaling. This causes the NI associated with the DS to launch NSLP signaling towards the address of the DR (see Figure 10). Although it is expected that the DS and the NATFW NSLP NI will usually reside on the same host, this specification does not rule out scenarios where the DS and NI reside on different hosts, the so-called proxy mode (see Section 3.7.6).
データ送信側（DS）は、データ受信（DR）にデータを送信するつもり、NATFW NSLPシグナリングを開始しなければなりません。これは、DRのアドレスに向けてシグナリングNSLPを（図10参照）を起動するためにDSに関連付けられたNIを引き起こします。それはDSとNATFW NSLP NIは、通常、同じホスト上に存在することが予想されるが、DSおよびNIが異なるホスト上に存在するシナリオを排除しないこの仕様は、いわゆるプロキシモード（セクション3.7.6を参照してください） 。
+-------+ +-------+ +-------+ +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR |
| |--->| NF1 |--->| NF2 |--->| |
+-------+ +-------+ +-------+ +-------+
========================================>
Data Traffic Direction (outbound)
---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSLP forwarder 1
MB2 : Middlebox 2 and NSLP forwarder 2
Figure 10: General NSIS Signaling
図10：一般NSISシグナリング
The following list shows the normal sequence of NSLP events without detailing the interaction with the NTLP and the interactions on the NTLP level.
以下のリストは、NTLPとNTLPレベルでの相互作用との相互作用を詳述することなく、NSLPイベントの通常のシーケンスを示します。
o NSIS initiators generate request messages (which are either CREATE or EXTERNAL messages) and send these towards the NSIS responder. This request message is the initial message that creates a new NATFW NSLP signaling session. The NI and the NR will most likely already share an application session before they start the NATFW NSLP signaling session. Note well the difference between both sessions.
O NSIS開始剤はとNSIS応答者の方にこれらを送信する（CREATEまたは外部メッセージのどちらかである）要求メッセージを生成します。この要求メッセージは、新しいNATFW NSLPシグナリングセッションを作成し、最初のメッセージです。彼らはNATFW NSLPシグナリング・セッションを開始する前に、NIおよびNRは最も可能性の高い、既にアプリケーションセッションを共有します。うまく両方のセッションの違いに注意してください。
o NSLP request messages are processed each time an NF with NATFW NSLP support is traversed. Each NF that is intercepting a request message and is accepting it for further treatment is joining the particular NATFW NSLP signaling session. These nodes process the message, check local policies for authorization and authentication, possibly create policy rules, and forward the signaling message to the next NSIS node. The request message is forwarded until it reaches the NSIS responder.
O NSLP要求メッセージは、NF NATFW NSLPとサポートが横断されるたびに処理されています。要求メッセージをインターセプトし、さらなる処理のためにそれを受け入れている各NFは、特定NATFW NSLPシグナリングセッションに参加しています。これらのノードは、おそらくポリシールールを作成し、認可および認証用のローカルポリシーをチェックして、次のNSISノードにシグナリングメッセージを転送し、メッセージを処理します。それはNSIS応答者に到達するまで要求メッセージが転送されます。
o NSIS responders will check received messages and process them if applicable. NSIS responders generate RESPONSE messages and send them hop-by-hop back to the NI via the same chain of NFs (traversal of the same NF chain is guaranteed through the established reverse message routing state in the NTLP). The NR is also joining the NATFW NSLP signaling session if the request message is accepted.
O NSIS応答者は、受信したメッセージを確認し、該当する場合は、それらを処理します。 NSISレスポンダは、（同じNF鎖はNTLP状態ルーティング確立逆メッセージを介して保証されるのトラバーサル）応答メッセージを生成し、NFSの同じチェーンを介してホップバイホップバックNIに送ります。要求メッセージが受け入れられた場合NRもNATFW NSLPシグナリングセッションに参加しています。
o The RESPONSE message is processed at each NF that has been included in the prior NATFW NSLP signaling session setup.
O RESPONSEメッセージは前NATFW NSLPシグナリングセッションのセットアップに含まれている各NFで処理されます。
o If the NI has received a successful RESPONSE message and if the signaling NATFW NSLP session started with a CREATE message, the data sender can start sending its data flow to the data receiver. If the NI has received a successful RESPONSE message and if the signaling NATFW NSLP session started with an EXTERNAL message, the data receiver is ready to receive further CREATE messages.
O NIは、成功した応答メッセージを受信したとシグナリングNATFW NSLPセッションは、CREATEメッセージを開始した場合、データ送信側はデータ受信機にそのデータフローの送信を開始することができます。 NIは、成功した応答メッセージを受信したとシグナリングNATFW NSLPセッションが外部メッセージを開始した場合、データ受信装置は、さらにメッセージを作成受信する準備ができている場合。
Because NATFW NSLP signaling follows the data path from DS to DR, this immediately enables communication between both hosts for scenarios with only firewalls on the data path or NATs on the sender side. For scenarios with NATs on the receiver side, certain problems arise, as described in Section 2.4.
NATFW NSLPシグナリングがDRにDSからのデータ経路をたどるので、これは直ちに送信側のデータパスまたはNATの上でのみファイアウォールを持つシナリオで両方のホストとの間の通信を可能にします。セクション2.4で説明したように、受信側のNATを有するシナリオでは、特定の問題が生じます。
When the NR and the NI are located in different address realms and the NR is located behind a NAT, the NI cannot signal to the NR address directly. The DR/NR is not reachable from other NIs using the private address of the NR and thus NATFW signaling messages cannot be sent to the NR/DR's address. Therefore, the NR must first obtain a NAT binding that provides an address that is reachable for the NI. Once the NR has acquired a public IP address, it forwards this information to the DS via a separate protocol. This application-layer signaling, which is out of the scope of the NATFW NSLP, may involve third parties that assist in exchanging these messages.
NRおよびNIは、異なるアドレスレルムに配置され、NRがNATの背後に配置されている場合、NIは直接NRアドレスに信号を送ることができません。 DR / NRは、NRのプライベートアドレスを使用して他のNISから到達可能ではありませんので、NATFWシグナリングメッセージは、NR / DRのアドレスに送信することはできません。したがって、NRは、第すなわちNIのために到達可能なアドレスを提供する結合NATを取得しなければなりません。 NRは、パブリックIPアドレスを取得したら、それは別のプロトコルを介してDSにこの情報を転送します。 NATFW NSLPの範囲外であり、このアプリケーション層シグナリングは、これらのメッセージを交換するのを助ける第三者を含むことができます。
The same holds partially true for NRs located behind firewalls that block all traffic by default. In this case, NR must tell its inbound firewalls of inbound NATFW NSLP signaling and corresponding data traffic. Once the NR has informed the inbound firewalls, it can start its application-level signaling to initiate communication with the NI. This mechanism can be used by machines hosting services behind firewalls as well. In this case, the NR informs the inbound firewalls as described, but does not need to communicate this to the NIs.
同じことが、デフォルトではすべてのトラフィックをブロックするファイアウォールの背後にあるのNRのために、部分的にも当てはまります。この場合、NRは、シグナリングおよびデータトラフィックを対応するインバウンドNATFW NSLPのそのインバウンドファイアウォールを伝える必要があります。 NRは、インバウンドファイアウォールを通知した後、それは、NIとの通信を開始するために、そのアプリケーション・レベルのシグナリングを開始することができます。このメカニズムは、同様に、ファイアウォールの背後にあるサービスをホストするマシンで使用することができます。この場合、NRは、説明するように、インバウンドファイアウォールを通知しますが、のNIにこれを通信する必要はありません。
NATFW NSLP signaling supports this scenario by using the EXTERNAL message.
NATFW NSLPシグナリングは外部メッセージを使用して、このシナリオをサポートしています。
1. The DR acquires a public address by signaling on the reverse path (DR towards DS) and thus making itself available to other hosts. This process of acquiring public addresses is called reservation. During this process the DR reserves publicly reachable addresses and ports suitable for further usage in application-level signaling and the publicly reachable address for further NATFW NSLP signaling. However, the data traffic will not be allowed to use this address/port initially (see next point). In the process of reservation, the DR becomes the NI for the messages necessary to obtain the publicly reachable IP address, i.e., the NI for this specific NATFW NSLP signaling session.
1. DRは、リバースパス（DSに向かってDR）上でシグナリング、したがって他のホストに自身が利用できるようにすることによって、パブリックアドレスを取得します。パブリックアドレスを取得するこのプロセスは、予約と呼ばれています。このプロセス中にDRは、公的に到達可能なアドレスおよびアプリケーションレベルシグナリングさらにNATFW NSLPシグナリングのために公に到達可能アドレスにおけるさらなる使用のために適切なポートを予約します。ただし、データトラフィックは、最初は（次のポイントを参照）、このアドレス/ポートを使用することはできません。予約の過程で、DRは、この特定NATFW NSLPシグナリングセッションのために公的に到達可能なIPアドレスを得るために必要なメッセージ、すなわち用NI、NIとなります。
2. Now on the side of the DS, the NI creates a new NATFW NSLP signaling session and signals directly to the public IP address of the DR. This public IP address is used as NR's address, as the NI would do if there is no NAT in between, and creates policy rules at middleboxes. Note, that the reservation will only allow forwarding of signaling messages, but not data flow packets. Policy rules allowing forwarding of data flow packets set up by the prior EXTERNAL message signaling will be activated when the signaling from NI towards NR is confirmed with a positive RESPONSE message. The EXTERNAL message is described in Section 3.7.2.
2.次にDSの側に、NIは、DRのパブリックIPアドレスに直接セッションとシグナリング信号新しいNATFW NSLPを作成します。そこの間にはNATでなく、ミドルボックスで、ポリシールールを作成した場合、NIはどうしたら、このパブリックIPアドレスは、NRのアドレスとして使用されます。予約は唯一のシグナリングメッセージの転送を許可することに、注意してくださいではなく、データフローパケット。 NR向かっNIからのシグナリングは肯定応答メッセージで確認されたときに前外部メッセージシグナリングによって設定データフローパケットの転送を許可するポリシールールが有効になります。外部メッセージは、セクション3.7.2に記載されています。
administrative domain
----------------------------------\
|
+-------+ +-------+ +-------+ | +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ | | | DR |
| |--->| NF1 |--->| NR | | | |
+-------+ +-------+ +-------+ | +-------+
|
----------------------------------/
========================================>
Data Traffic Direction (outbound)
---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSLP forwarder 1
MB2 : Middlebox 2 and NSLP responder
Figure 11: Proxy Mode Signaling for Data Sender
図11：データ送信側のプロキシモードのシグナリング
The above usage assumes that both ends of a communication support NSIS, but fails when NSIS is only deployed at one end of the path. In this case, only one of the sending side (see Figure 11) or receiving side (see Figure 12) is NSIS aware and not both at the same time. NATFW NSLP supports both scenarios (i.e., either the DS or DR does not support NSIS) by using a proxy mode, as described in Section 3.7.6.
上記使用は、通信支援NSISの両端を想定するが、NSISのみパスの一方の端部に配備されたときに失敗します。この場合、送信側の一方のみまたは受信側（図12参照）（図11を参照）NSIS同時に認識しないの両方です。セクション3.7.6に記載したようにNATFW NSLPは、プロキシモードを使用することによって（すなわち、DSまたはDRのいずれかがNSISをサポートしていない）両方のシナリオをサポートします。
administrative domain
/ ----------------------------------
|
+-------+ | +-------+ +-------+ +-------+
| DS | | | MB2/ |~~~>| MB1/ |~~~>| DR |
| | | | NR |<---| NF1 |<---| |
+-------+ | +-------+ +-------+ +-------+
|
\----------------------------------
========================================>
Data Traffic Direction (inbound)
---> : NATFW NSLP request signaling
~~~> : NATFW NSLP response signaling
DS/NI : Data sender and NSIS initiator
DR/NR : Data receiver and NSIS responder
MB1 : Middlebox 1 and NSLP forwarder 1
MB2 : Middlebox 2 and NSLP responder
Figure 12: Proxy Mode Signaling for Data Receiver
図12：データ受信のためのプロキシモードのシグナリング
The basic functionality of the NATFW NSLP provides for opening firewall pin holes and creating NAT bindings to enable data flows to traverse these devices. Firewalls are normally expected to work on a "deny-all" policy, meaning that traffic not explicitly matching any firewall filter rule will be blocked. Similarly, the normal behavior of NATs is to block all traffic that does not match any already configured/installed binding or NATFW NSLP session. However, some scenarios require support of firewalls having "allow-all" policies, allowing data traffic to traverse the firewall unless it is blocked explicitly. Data receivers can utilize NATFW NSLP's EXTERNAL message with action set to "deny" to install policy rules at inbound firewalls to block unwanted traffic.
NATFW NSLPの基本的な機能は、ファイアウォールピンホールを開いてデータを有効にするためにNATバインディングを作成するために提供するこれらのデバイスを横断するように流れます。ファイアウォールは通常、明示的にファイアウォールフィルタルールに一致しないトラフィックはブロックされますことを意味し、「拒否 - すべての」政策に取り組むことが期待されています。同様に、NATの通常の動作は、任意の既に結合又はNATFW NSLPセッションインストール/構成に一致しないすべてのトラフィックをブロックすることです。しかし、いくつかのシナリオは、それが明示的にブロックされない限り、データトラフィックがファイアウォールを通過できるように、「許可 - すべての」ポリシーを持つファイアウォールのサポートを必要とします。データ受信機は、不要なトラフィックをブロックするために、インバウンドファイアウォールでポリシールールをインストールするには、「拒否」に設定アクションでNATFW NSLPの外部メッセージを利用することができます。
The protocol works on a soft-state basis, meaning that whatever state is installed or reserved on a middlebox will expire, and thus be uninstalled or forgotten after a certain period of time. To prevent premature removal of state that is needed for ongoing communication, the NATFW NI involved will have to specifically request a NATFW NSLP signaling session extension. An explicit NATFW NSLP state deletion capability is also provided by the protocol.
プロトコルは失効するため、一定時間後にアンインストールしたり忘れたりしたことがどんな状態ミドルにインストールまたは予約されていることを意味し、ソフトステートベースで動作します。進行中の通信のために必要とされている状態の早期除去を防ぐために、関与NATFW NIは、具体的NATFW NSLPシグナリングのセッションの延長を要求する必要があります。明示的なNATFW NSLP状態の削除機能は、プロトコルによって提供されます。
If the actions requested by a NATFW NSLP message cannot be carried out, NFs and the NR must return a failure, such that appropriate actions can be taken. They can do this either during the request message handling (synchronously) by sending an error RESPONSE message or at any time (asynchronously) by sending a NOTIFY notification message.
NATFW NSLPメッセージによって要求されたアクションを行うことができない場合は、NFSとNRは、適切な行動をとることができるような失敗を、返さなければなりません。彼らはどちらかのエラー応答メッセージを送信することにより、または（非同期）NOTIFY通知メッセージを送信することにより、任意の時点で（同期）ハンドリング要求メッセージ中にこれを行うことができます。
The next sections define the NATFW NSLP message types and formats, protocol operations, and policy rule operations.
次のセクションでは、NATFW NSLPメッセージタイプとフォーマット、プロトコル操作、およびポリシールールの動作を定義します。
The protocol uses four messages types:
プロトコルは、4つのメッセージタイプを使用しています。
o CREATE: a request message used for creating, changing, refreshing, and deleting NATFW NSLP signaling sessions, i.e., open the data path from DS to DR.
O CREATE：すなわち、作成、変更、リフレッシュ、およびNATFW NSLPシグナリングセッションを削除するための要求メッセージを、DRにDSからのデータパスを開きます。
o EXTERNAL: a request message used for reserving, changing, refreshing, and deleting EXTERNAL NATFW NSLP signaling sessions. EXTERNAL messages are forwarded to the edge-NAT or edge-firewall and allow inbound CREATE messages to be forwarded to the NR. Additionally, EXTERNAL messages reserve an external address and, if applicable, port number at an edge-NAT.
O：外部、予約変更、リフレッシュ、および外部NATFW NSLPシグナリングセッションを削除するための要求メッセージ。外部メッセージは、エッジ-NATまたはエッジファイアウォールに転送され、着信がNRに転送するメッセージを作成できるようにしています。また、外部メッセージは、エッジNATに該当する場合、ポート番号、外部アドレスを予約して。
o NOTIFY: an asynchronous message used by NATFW peers to alert other NATFW peers about specific events (especially failures).
O NOTIFY：NATFWピアによって使用される非同期メッセージは、特定のイベント（特に障害）に関する他NATFWピアに警告します。
o RESPONSE: used as a response to CREATE and EXTERNAL request messages.
O応答：作成するために応答して、外部からの要求メッセージとして使用します。
RESPONSE messages will be generated synchronously to CREATE and EXTERNAL messages by NSLP forwarders and responders to report success or failure of operations or some information relating to the NATFW NSLP signaling session or a node. RESPONSE messages MUST NOT be generated for any other message, such as NOTIFY and RESPONSE.
応答メッセージは、成功または失敗の操作やNATFW NSLPシグナリングセッションまたはノードに関連するいくつかの情報を報告するNSLPフォワーダと応答でメッセージを作成し、Externalに同期して生成されます。応答メッセージは、NOTIFYと応答として、他の任意のメッセージを生成してはいけません。
All RESPONSE messages MUST carry a NATFW_INFO object that contains an error class code and a response code (see Section 4.2.5). This section defines terms for groups of RESPONSE messages depending on the error class.
すべての応答メッセージ（セクション4.2.5を参照してください）エラークラスコードと応答コードが含まれているNATFW_INFOオブジェクトを運ばなければなりません。このセクションでは、エラークラスに応じた応答メッセージのグループのための用語を定義します。
o Successful RESPONSE: Messages carrying NATFW_INFO with error class 'Success' (2).
O正常な応答：エラークラス「成功」とNATFW_INFOを運ぶメッセージ（2）。
o Informational RESPONSE: Messages carrying NATFW_INFO with error class 'Informational' (1) (only used with NOTIFY messages).
O情報RESPONSE：エラー・クラス（1）（のみNOTIFYメッセージで使用される）「情報」とNATFW_INFOを運ぶメッセージ。
o Error RESPONSE: Messages carrying NATFW_INFO with error class other than 'Success' or 'Informational'.
Oエラー応答：「成功」または「情報」以外のエラークラスにNATFW_INFOを運ぶメッセージ。
A NATFW NSLP signaling session defines an association between the NI, NFs, and the NR related to a data flow. This association is created when the initial CREATE or EXTERNAL message is successfully received at the NFs or the NR. There is signaling NATFW NSLP session state stored at the NTLP layer and at the NATFW NSLP level. The NATFW NSLP signaling session state for the NATFW NSLP comprises NSLP state and the associated policy rules at a middlebox.
NATFW NSLPシグナリングセッションは、データフローに関連するNI、NFS、およびNR間の関連付けを定義します。この関連付けは、初期の作成時に作成されるか、外部メッセージは、NFSまたはNRで正常に受信されます。 NTLP層において及びNATFW NSLPレベルで保存されたシグナルNATFW NSLPセッション状態があります。 NATFW NSLPためNATFW NSLPシグナリングセッション状態はNSLP状態とミドルに関連するポリシールールを含みます。
The NATFW NSLP signaling session is identified by the session ID (plus other information at the NTLP level). The session ID is generated by the NI before the initial CREATE or EXTERNAL message is sent. The value of the session ID MUST be generated as a cryptographically random number (see [RFC4086]) by the NI, i.e., the output MUST NOT be easily guessable by third parties. The session ID is not stored in any NATFW NSLP message but passed on to the NTLP.
NATFW NSLPシグナリングセッションは、セッションID（プラスNTLPレベルの他の情報）によって識別されます。初期に作成する前に、セッションIDは、NIによって生成されるか、または外部メッセージが送信されます。セッションIDの値は、NIによる暗号乱数（[RFC4086]を参照）のように生成されなければならない、すなわち、出力は、第三者によって容易に推測可能であるはずがありません。セッションIDは、任意のNATFW NSLPメッセージに格納されているが、NTLPに渡されていません。
A NATFW NSLP signaling session has several conceptual states that describe in what state a signaling session is at a given time. The signaling session can have these states at a node:
NATFW NSLPシグナリングセッションは、シグナリングセッションは、所定の時間にあるもの状態に記述いくつかの概念的な状態を有します。シグナリングセッションは、ノードでこれらの状態を持つことができます。
o Pending: The NATFW NSLP signaling session has been created and the node is waiting for a RESPONSE message to the CREATE or EXTERNAL message. A NATFW NSLP signaling session in state 'Pending' MUST be marked as 'Dead' if no corresponding RESPONSE message has been received within the time of the locally granted NATFW NSLP signaling session lifetime of the forwarded CREATE or EXTERNAL message (as described in Section 3.4).
O保留：NATFW NSLPシグナリングセッションが作成され、ノードは、CREATEまたは外部メッセージに対する応答メッセージを待っています。 「保留」状態NATFW NSLPシグナリングセッションは、次のようにマークされなければならない「デッド」のセクション3.4に記載したように該当する応答メッセージが転送され、CREATEまたは外部メッセージの局所付与NATFW NSLPシグナリングセッション存続時間（の時間内に受信されていない場合）。
o Established: The NATFW NSLP signaling session is established, i.e, the signaling has been successfully performed and the lifetime of NATFW NSLP signaling session is counted from now on. A NATFW NSLP signaling session in state 'Established' MUST be marked as 'Dead' if no refresh message has been received within the time of the locally granted NATFW NSLP signaling session lifetime of the RESPONSE message (as described in Section 3.4).
O設立：NATFW NSLPシグナリングセッションが確立され、すなわち、シグナリングが成功したとNATFW NSLPシグナリングセッションの寿命は今からカウントされます。いかなるリフレッシュメッセージは（セクション3.4で説明したように）応答メッセージを局所的に付与さNATFW NSLPシグナリングセッション存続時間の時間内に受信されなかった場合は「設立」状態NATFW NSLPシグナリングセッションは、「デッド」としてマークされなければなりません。
o Dead: Either the NATFW NSLP signaling session is timed out or the node has received an error RESPONSE message for the NATFW NSLP signaling session and the NATFW NSLP signaling session can be deleted.
Oデッドは：NATFW NSLPシグナリングセッションがタイムアウトされるか、またはノードがNATFW NSLPシグナリングセッションのエラー応答メッセージを受信したとNATFW NSLPシグナリングセッションを削除することができます。
o Transitory: The node has received an asynchronous message, i.e., a NOTIFY, and can delete the NATFW NSLP signaling session if needed after some time. When a node has received a NOTIFY message, it marks the signaling session as 'Transitory'. This signaling session SHOULD NOT be deleted before a minimum hold time of 30 seconds, i.e., it can be removed after 30 seconds or more. This hold time ensures that the existing signaling session can be reused by the NI, e.g., a part of a signaling session that is not affected by the route change can be reused once the updating request message is received.
O一過：ノードは、非同期メッセージ、すなわち、NOTIFYを受信し、そしていくつかの時間の後に、必要に応じてNATFW NSLPシグナリングセッションを削除することができます。ノードはNOTIFYメッセージを受信したとき、それは一過 'とシグナリングセッションをマークします。このシグナリングセッションは、すなわち、それは30秒以上の後に除去することができ、30秒の最小ホールド時間前に削除しないでください。この保持時間は更新要求メッセージが受信されると、例えば、経路変更によって影響されないシグナリングセッションの一部を再利用することができ、既存のシグナリングセッションは、NIによって再利用できることを保証します。
All NATFW messages are subject to some basic message processing when received at a node, independent of the message type. Initially, the syntax of the NSLP message is checked and a RESPONSE message with an appropriate error of class 'Protocol error' (3) code is generated if a non-recoverable syntax error is detected. A recoverable error is, for instance, when a node receives a message with reserved flags set to values other than zero. This also refers to unknown NSLP objects and their handling, according to Section 4.2. If a message is delivered to the NATFW NSLP, this implies that the NTLP layer has been able to correlate it with the session ID (SID) and MRI entries in its database. There is therefore enough information to identify the source of the message and routing information to route the message back to the NI through an established chain of NTLP messaging associations. The message is not further forwarded if any error in the syntax is detected. The specific response codes stemming from the processing of objects are described in the respective object definition section (see Section 4). After passing this check, the NATFW NSLP node performs authentication- and authorization-related checks, described in Section 3.6. Further processing is executed only if these tests have been successfully passed; otherwise, the processing stops and an error RESPONSE is returned.
ノードで受信されたときに、すべてのNATFWメッセージは、メッセージタイプとは無関係に、いくつかの基本的なメッセージ処理の対象となっています。最初に、NSLPメッセージの構文がチェックされ、回復不可能な構文エラーが検出された場合クラスのプロトコルエラー」の適切なエラー応答メッセージは、（3）コードが生成されます。回復可能なエラーは、ノードがゼロ以外の値に設定された予約フラグ付きメッセージを受信した場合、例えば、です。また、これは、セクション4.2によると、未知のNSLPオブジェクトとその取扱いを指します。メッセージはNATFW NSLPに送達される場合、これはNTLP層は、そのデータベース内のセッションID（SID）とMRIエントリとそれを相関させることができたことを意味します。 NTLPメッセージングアソシエーションの確立されたチェーンを介してメッセージの送信元とメッセージバックNIにルーティングするルーティング情報を識別するための十分な情報が存在します。構文に誤りが検出された場合のメッセージは、さらに転送されません。オブジェクトの処理に起因する特定の応答コードは、それぞれのオブジェクト定義のセクションに記載されている（セクション4を参照）。このチェックを通過した後、NATFW NSLPノードは、セクション3.6で説明authentication-と許可関連のチェックを行います。さらなる処理は、これらのテストが正常に渡されている場合にのみ実行されます。そうでない場合、処理が停止し、エラー応答が返されます。
Further message processing stops whenever an error RESPONSE message is generated, and the EXTERNAL or CREATE message is discarded.
さらに、メッセージ処理は、エラー応答メッセージが生成されるたびに停止し、外部またはメッセージが破棄され、CREATE。
NATFW NSLP signaling sessions, and the corresponding policy rules that may have been installed, are maintained via a soft-state mechanism. Each signaling session is assigned a signaling session lifetime and the signaling session is kept alive as long as the lifetime is valid. After the expiration of the signaling session lifetime, signaling sessions and policy rules MUST be removed automatically and resources bound to them MUST be freed as well. Signaling session lifetime is handled at every NATFW NSLP node. The NSLP forwarders and NSLP responder MUST NOT trigger signaling session lifetime extension refresh messages (see Section 3.7.3): this is the task of the NSIS initiator.
セッションシグナリングNATFW NSLP、およびインストールされていてもよい対応するポリシー・ルールは、ソフトステート機構を介して維持されます。各セッションシグナリングは、シグナリングセッションの有効期間を割り当てられ、シグナリングセッションは限り寿命が有効であるとして生かされています。シグナリングセッションの有効期間の満了後、シグナルセッションとポリシールールが自動的に削除されなければならないし、それらに結合しているリソースも同様に解放しなければなりません。シグナリングセッションの有効期間は、すべてのNATFW NSLPノードで処理されます。 NSLPフォワーダとNSLPの応答は、セッションの有効期間の延長リフレッシュメッセージ（セクション3.7.3を参照）シグナリングをトリガはいけません。これはNSISイニシエータの課題です。
The NSIS initiator MUST choose a NATFW NSLP signaling session lifetime value (expressed in seconds) before sending any message, including the initial message that creates the NATFW NSLP signaling session, to other NSLP nodes. It is RECOMMENDED that the NATFW NSLP signaling session lifetime value is calculated based on:
NSIS開始剤は他のNSLPノードに、NATFW NSLPシグナリングセッションを作成する最初のメッセージを含む任意のメッセージを送信する前に（秒で表される）NATFW NSLPシグナリングセッションの寿命値を選択する必要があります。 NATFW NSLPシグナリングのセッションの有効期間の値はに基づいて計算されることをお勧めします。
o the number of lost refresh messages with which NFs should cope;
NFSが対処すべきで失われたリフレッシュメッセージの数O;
o the end-to-end delay between the NI and NR;
NIとNRとの間のエンドツーエンド遅延O。
o network vulnerability due to NATFW NSLP signaling session hijacking ([RFC4081]), NATFW NSLP signaling session hijacking is made easier when the NI does not explicitly remove the NATFW NSLP signaling session;
NIは、明示的NATFW NSLPシグナリングセッションを削除しない場合、NATFW NSLPシグナリングセッションハイジャックが容易になるセッションハイジャック（[RFC4081]）をシグナリングによるNATFW NSLPにOネットワークの脆弱性。
o the user application's data exchange duration, in terms of time and networking needs. This duration is modeled as R, with R the message refresh period (in seconds);
時間的およびネットワーキングのニーズのユーザー・アプリケーションのデータ交換期間、O。この期間は、R（秒）メッセージリフレッシュ周期で、Rとしてモデル化されます。
o the load on the signaling plane. Short lifetimes imply more frequent signaling messages;
シグナリングプレーンの負荷O。短い寿命はより頻繁にシグナリング・メッセージを暗示します。
o the acceptable time for a NATFW NSLP signaling session to be present after it is no longer actually needed. For example, if the existence of the NATFW NSLP signaling session implies a monetary cost and teardown cannot be guaranteed, shorter lifetimes would be preferable;
それはもはや、実際に必要ではありません後NATFW NSLPシグナリングのセッションの許容時間が存在するように、O。 NATFW NSLPシグナリングのセッションの存在が金銭的コストを意味し、ティアダウンを保証できない場合たとえば、短い寿命が望ましいだろう。
o the lease time of the NI's IP address. The lease time of the IP address must be longer than the chosen NATFW NSLP signaling session lifetime; otherwise, the IP address can be re-assigned to a different node. This node may receive unwanted traffic, although it never has requested a NAT/firewall configuration, which might be an issue in environments with mobile hosts.
NIのIPアドレスのリース時間O。 IPアドレスのリース時間は、選択されたNATFW NSLPシグナリングのセッションの寿命よりも長くなければなりません。そうでない場合は、IPアドレスが別のノードに再割り当てすることができます。それは、モバイルホストとの環境では問題になる可能性がありますNAT /ファイアウォール設定を要求したことがないが、このノードは、不要なトラフィックを受け取ることができます。
The RSVP specification [RFC2205] provides an appropriate algorithm for calculating the NATFW NSLP signaling session lifetime as well as a means to avoid refresh message synchronization between NATFW NSLP signaling sessions. [RFC2205] recommends:
RSVP仕様[RFC2205]はNATFW NSLPシグナリングセッションの寿命ならびにNATFW NSLPシグナリングセッションの間にリフレッシュメッセージの同期を回避する手段を算出するための適切なアルゴリズムを提供します。 [RFC2205]は推奨しています：
1. The refresh message timer to be randomly set to a value in the range [0.5R, 1.5R].
1.リフレッシュメッセージタイマがランダム範囲[0.5R、1.5R]の値に設定します。
2. To avoid premature loss of state, lt (with lt being the NATFW NSLP signaling session lifetime) must satisfy lt >= (K + 0.5)*1.5*R, where K is a small integer. Then, in the worst case, K-1 successive messages may be lost without state being deleted. Currently, K = 3 is suggested as the default. However, it may be necessary to set a larger K value for hops with high loss rate. Other algorithms could be used to define the relation between the NATFW NSLP signaling session lifetime and the refresh message period; the algorithm provided is only given as an example.
2. LT> =（K + 0.5）を満たさなければならない（LTがNATFW NSLPシグナリングセッションの寿命である）状態の早期喪失、LTを避けるため* 1.5 * Kが小さい整数であるR、。そして、最悪の場合には、K-1の連続したメッセージは、状態が削除されずに失われる可能性があります。現在、K = 3がデフォルトとして提案されています。しかし、高い損失率とのホップのためにより大きいK値を設定する必要があるかもしれません。他のアルゴリズムは、セッションの存続期間とリフレッシュメッセージ期間をシグナリングNATFW NSLPとの間の関係を定義するために使用することができます。提供されるアルゴリズムは、例としてのみ与えられています。
It is RECOMMENDED to use a refresh timer of 300 s (5 minutes), unless the NI or the requesting application at the NI has other requirements (e.g., flows lasting a very short time).
NiまたはNiで要求しているアプリケーションは、他の要件がない限り、（例えば、非常に短い時間を持続フロー）、300秒（5分）のリフレッシュタイマを使用することが推奨されます。
This requested NATFW NSLP signaling session lifetime value lt is stored in the NATFW_LT object of the NSLP message.
これはNATFW NSLPシグナリングセッション存続時間値LTがNSLPメッセージのNATFW_LTオブジェクトに格納されている要求されました。
NSLP forwarders and the NSLP responder can execute the following behavior with respect to the requested lifetime handling:
NSLPフォワーダとNSLP応答者は、要求された寿命の取り扱いに関して、以下の動作を実行することができます。
Requested signaling session lifetime acceptable:
許容可能なセッションの有効期間をシグナリングを要求しました。
No changes to the NATFW NSLP signaling session lifetime values are needed. The CREATE or EXTERNAL message is forwarded, if applicable.
NATFW NSLPシグナリングセッションライフタイム値を変更する必要はありません。該当する場合は、CREATEまたは外部メッセージは、転送されます。
Signaling session lifetime can be lowered:
シグナリングセッション寿命を低下させることができます。
An NSLP forwarded or the NSLP responder MAY also lower the requested NATFW NSLP signaling session lifetime to an acceptable value (based on its local policies). If an NF changes the NATFW NSLP signaling session lifetime value, it MUST store the new value in the NATFW_LT object. The CREATE or EXTERNAL message is forwarded.
NSLPは、転送またはNSLPレスポンダはまた、（そのローカルポリシーに基づいて）許容値を要求NATFW NSLPシグナリングセッションの寿命を低下させることができます。 NFはNATFW NSLPシグナリングのセッションの有効期間の値を変更した場合、それはNATFW_LTオブジェクトに新しい値を保存しなければなりません。 CREATEまたは外部のメッセージが転送されます。
Requested signaling session lifetime is too big:
要求されたシグナリングのセッションの有効期間が大きすぎます。
An NSLP forwarded or the NSLP responder MAY reject the requested NATFW NSLP signaling session lifetime value as being too big and MUST generate an error RESPONSE message of class 'Signaling session failure' (7) with response code 'Requested lifetime is too big' (0x02) upon rejection. Lowering the lifetime is preferred instead of generating an error message.
0×02（「要求寿命が大きすぎる」NSLPは、転送またはNSLPレスポンダは大きすぎるものとして、セッションの寿命値をシグナリング要求NATFW NSLPを拒絶するかもしれなくて、クラスのエラー応答メッセージを生成しなければなりません応答コードと（7）「セッションの失敗をシグナリング」 ）の拒絶時に。寿命を低下させることに代えて、エラーメッセージを生成することが好ましいです。
Requested signaling session lifetime is too small:
要求されたシグナリングのセッションの有効期間は小さすぎます。
An NSLP forwarded or the NSLP responder MAY reject the requested NATFW NSLP signaling session lifetime value as being to small and MUST generate an error RESPONSE message of class 'Signaling session failure' (7) with response code 'Requested lifetime is too small' (0x10) upon rejection.
NSLPは、転送またはNSLPレスポンダは、（0×10を小にあるように要求されたNATFW NSLPシグナリングセッションの寿命値を拒絶するかもしれなくて、（7）応答コードと「要求寿命が小さすぎる」「セッションの失敗をシグナリング」クラスのエラー応答メッセージを生成しなければなりません）の拒絶時に。
NFs or the NR MUST NOT increase the NATFW NSLP signaling session lifetime value. Messages can be rejected on the basis of the NATFW NSLP signaling session lifetime being too long when a NATFW NSLP signaling session is first created and also on refreshes.
NFSまたはNRはNATFW NSLPシグナリングのセッションの生涯価値を高めてはなりません。メッセージはNATFW NSLPシグナリングのセッションが最初のリフレッシュにも作成されたときに長すぎるNATFW NSLPシグナリングのセッションの有効期間に基づいて拒否することができます。
The NSLP responder generates a successful RESPONSE for the received CREATE or EXTERNAL message, sets the NATFW NSLP signaling session lifetime value in the NATFW_LT object to the above granted lifetime and sends the message back towards NSLP initiator.
NSLPレスポンダは、受信したCREATEまたは外部メッセージのための正常な応答は、上記付与された寿命にNATFW_LTオブジェクト内NATFW NSLPシグナリングセッション存続時間値を設定し、NSLP開始向かっバックメッセージを送信生成します。
Each NSLP forwarder processes the RESPONSE message and reads and stores the granted NATFW NSLP signaling session lifetime value. The forwarders MUST accept the granted NATFW NSLP signaling session lifetime, if the lifetime value is within the acceptable range. The acceptable value refers to the value accepted by the NSLP forwarder when processing the CREATE or EXTERNAL message. For received values greater than the acceptable value, NSLP forwarders MUST generate a RESPONSE message of class 'Signaling session failure' (7) with response code 'Modified lifetime is too big' (0x11), including a Signaling Session Lifetime object that carries the maximum acceptable signaling session lifetime for this node. For received values lower than the values acceptable by the node local policy, NSLP forwarders MUST generate a RESPONSE message of class 'Signaling session failure' (7) with response code 'Modified lifetime is too small' (0x12), including a Signaling Session Lifetime object that carries the minimum acceptable signaling session lifetime for this node. In both cases, either 'Modified lifetime is too big' (0x11) or 'Modified lifetime is too small' (0x12), the NF MUST generate a NOTIFY message and send it outbound with the error class set to 'Informational' (1) and with the response code set to 'NATFW signaling session terminated' (0x05).
各NSLPフォワーダは、応答メッセージを処理し、許可されNATFW NSLPシグナリングセッションの寿命値を読み出して格納します。ライフタイム値が許容範囲内であればフォワーダは、付与されたNATFW NSLPシグナリングセッション寿命を受け入れなければなりません。許容値は、CREATEまたは外部メッセージを処理するときNSLPフォワーダによって受け入れられた値を指します。許容値よりも大きい受信値に対して、NSLPフォワーダは、応答コードと（7）「セッションの失敗をシグナリング」クラスの応答メッセージを生成しなければなりません「修飾寿命が大きすぎる」（0x11を）、最大値を運ぶシグナリングセッション存続時間オブジェクトを含みますこのノードのために許容されるシグナリングセッション存続時間。ノードローカルポリシーにより許容される値よりも低い受信値に対して、NSLPフォワーダ（7）「セッションの失敗をシグナリング」クラスの応答メッセージを生成しなければならないレスポンスコードと「修飾寿命が小さすぎる」（0x12を）、シグナリングセッション存続時間を含みますこのノードのための最小許容シグナリングセッションの寿命を運ぶオブジェクト。両方の場合において、いずれか（0x12を）、NFはNOTIFYメッセージを生成しなければならなくて、「情報」（1）に設定されたエラー・クラスとのOutboundそれを送る（0x11を）「修飾寿命が大きすぎる」または「改変寿命が小さすぎます」応答コードを（0×05）「末端NATFWシグナリングセッション」に設定。
Figure 13 shows the procedure with an example, where an initiator requests 60 seconds lifetime in the CREATE message and the lifetime is shortened along the path by the forwarder to 20 seconds and by the responder to 15 seconds. When the NSLP forwarder receives the RESPONSE message with a NATFW NSLP signaling session lifetime value of 15 seconds it checks whether this value is lower or equal to the acceptable value.
図13は、イニシエータが作成したメッセージで60秒の寿命を要求する例の手順を示しており、寿命は20秒にフォワーダによって15秒に応答して、パスに沿って短縮されます。 NSLPフォワーダは、15秒のNATFW NSLPシグナリングセッションの寿命値と応答メッセージを受信すると、この値が許容値より低いかまたは等しいかどうかをチェックします。
+-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+
| |---------------->| NSLP |---------------->| |
| NI | | forwarder | | NR |
| |<----------------| check 15<20 |<----------------| |
+-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+
lt = lifetime
LT =寿命
Figure 13: Signaling Session Lifetime Setting Example
図13：設定例セッションの有効期間をシグナリング
NATFW NSLP messages need to carry an identifier so that all nodes along the path can distinguish messages sent at different points in time. Messages can be lost along the path or duplicated. So, all NATFW NSLP nodes should be able to identify messages that have been received before (duplicated) or lost before (loss). For message replay protection, it is necessary to keep information about messages that have already been received and requires every NATFW NSLP message to carry a message sequence number (MSN), see also Section 4.2.7.
NATFW NSLPメッセージは、経路に沿った全てのノードが異なる時点で送信されたメッセージを区別できるように識別子を運ぶ必要があります。メッセージは、パスに沿って失われたり複製することができます。だから、すべてのNATFW NSLPノードが（損失）の前に（重複）前に受信または失われたメッセージを識別することができるはずです。メッセージの再生保護のために、それは既に受信し、メッセージシーケンス番号（MSN）を運ぶために、すべてのNATFW NSLPメッセージを必要とされているメッセージに関する情報を保持する必要があり、また、セクション4.2.7を参照してください。
The MSN MUST be set by the NI and MUST NOT be set or modified by any other node. The initial value for the MSN MUST be generated randomly and MUST be unique only within the NATFW NSLP signaling session for which it is used. The NI MUST increment the MSN by one for every message sent. Once the MSN has reached the maximum value, the next value it takes is zero. All NATFW NSLP nodes MUST use the algorithm defined in [RFC1982] to detect MSN wrap-arounds.
MSNは、NIによって設定しなければならなくて、他のノードによって設定されたまたは修飾されてはいけません。 MSNのための初期値はランダムに生成されなければならないだけ、それが使用されるためNATFW NSLPシグナリングセッション内で一意でなければなりません。 NIは、送信されたメッセージごとに1によってMSNを増加しなければなりません。 MSNが最大値に達すると、それが取る次の値はゼロです。全てNATFW NSLPノードは、MSNのラップアラウンドを検出するために[RFC1982]で定義されたアルゴリズムを使用しなければなりません。
NSLP forwarders and the responder store the MSN from the initial CREATE or EXTERNAL packet that creates the NATFW NSLP signaling session as the start value for the NATFW NSLP signaling session. NFs and NRs MUST include the received MSN value in the corresponding RESPONSE message that they generate.
NSLPフォワーダとNATFW NSLPシグナリングセッションの開始値としてNATFW NSLPシグナリングセッションを作成応答初期からMSN作成ストアまたは外部パケット。 NFSとのNRは、それらが生成する対応する応答メッセージで受信したMSNの値を含まなければなりません。
When receiving a CREATE or EXTERNAL message, a NATFW NSLP node uses the MSN given in the message to determine whether the state being requested is different from the state already installed. The message MUST be discarded if the received MSN value is equal to or lower than the stored MSN value. Such a received MSN value can indicate a duplicated and delayed message or replayed message. If the received MSN value is greater than the already stored MSN value, the NATFW NSLP MUST update its stored state accordingly, if permitted by all security checks (see Section 3.6), and store the updated MSN value accordingly.
CREATEまたは外部メッセージを受信した場合、NATFW NSLPノードが要求されている状態が既にインストールされた状態と異なっているかどうかを決定するためにメッセージに与えられたMSNを使用します。受信されたMSNの値が格納されているMSNの値以下である場合、メッセージは破棄されなければなりません。そのような受信されたMSNの値が複製および遅延メッセージまたは再生メッセージを示すことができます。受信されたMSNの値がすでに格納されているMSNの値よりも大きい場合、NATFW NSLPは、すべてのセキュリティチェックによって許可されている場合（3.6節を参照）、それに応じてその記憶された状態を更新し、それに応じて更新されたMSNの値を格納しなければなりません。
NATFW NSLP nodes receiving signaling messages MUST first check whether this message is authenticated and authorized to perform the requested action. NATFW NSLP nodes requiring more information than provided MUST generate an error RESPONSE of class 'Permanent failure' (0x5) with response code 'Authentication failed' (0x01) or with response code 'Authorization failed' (0x02).
NATFW NSLPは、最初にこのメッセージが認証され、要求されたアクションを実行する権限があるかどうかをチェックしなければならないシグナリングメッセージを受信ノード。 NATFW NSLPは、（0×02）「認証が失敗した」（0×01）「認証失敗」レスポンスコードでクラスの永久故障 '（0x5）のエラー応答を生成しなければなりません提供されるよりも多くの情報を要求または応答コードを持つノード。
The NATFW NSLP is expected to run in various environments, such as IP-based telephone systems, enterprise networks, home networks, etc. The requirements on authentication and authorization are quite different between these use cases. While a home gateway, or an Internet cafe, using NSIS may well be happy with a "NATFW signaling coming from inside the network" policy for authorization of signaling, enterprise networks are likely to require more strongly authenticated/authorized signaling. This enterprise scenario may require the use of an infrastructure and administratively assigned identities to operate the NATFW NSLP.
NATFW NSLPは、認証と承認の要件は、これらのユースケースの間でかなり異なっているなどIPベースの電話システム、企業ネットワーク、ホームネットワーク、など様々な環境で実行することが予想されます。ホームゲートウェイ、またはインターネットカフェが、NSISがうまくシグナリングの承認のための政策「NATFWは、ネットワーク内部からのシグナル伝達」と幸せかもしれ使用して、企業ネットワークは、より強力な認証/認可シグナリングを必要とする可能性があります。この企業のシナリオでは、インフラストラクチャの使用を必要とし、管理NATFW NSLPを動作させるためにIDを割り当ててもよいです。
Once the NI is authenticated and authorized, another step is performed. The requested policy rule for the NATFW NSLP signaling session is checked against a set of policy rules, i.e., whether the requesting NI is allowed to request the policy rule to be loaded in the device. If this fails, the NF or NR must send an error RESPONSE of class 'Permanent failure' (5) and with response code 'Authorization failed' (0x02).
NIが認証および承認されると、別のステップが実行されます。 NATFW NSLPシグナリングセッションの要求されたポリシールールは、要求NIが装置にロードされるポリシールールを要求するために許可されているかどうか、即ち、ポリシールールのセットと照合されます。これが失敗した場合、NFまたはNRは、クラスのエラー応答を送信する必要があります（5）と応答コードと「常設失敗」「認証に失敗しました」（0×02）。
This section defines the protocol operations including how to create NATFW NSLP signaling sessions, maintain them, delete them, and how to reserve addresses.
このセクションでは、NATFW NSLPシグナリングセッションを作成し、それらを維持し、それらを削除し、どのようにアドレスを予約する方法などのプロトコル操作を定義しています。
This section requires a good knowledge of the NTLP [RFC5971] and the message routing method mechanism and the associated message routing information (MRI). The NATFW NSLP uses information from the MRI, e.g., the destination and source ports, and the NATFW NSLP to construct the policy rules used on the NATFW NSLP level. See also Appendix D for further information about this.
このセクションでは、NTLP [RFC5971]の十分な知識と方法機構及び関連するメッセージルーティング情報（MRI）をメッセージルーティングを必要とします。 NATFW NSLPはNATFW NSLPレベルで使用されるポリシールールを構築するために、例えば、宛先および送信元ポートをMRIからの情報を使用し、NATFW NSLP。付録Dは、これに関する詳細についても参照してください。
Allowing two hosts to exchange data even in the presence of middleboxes is realized in the NATFW NSLP by the use of the CREATE message. The NI (either the data sender or a proxy) generates a CREATE message as defined in Section 4.3.1 and hands it to the NTLP. The NTLP forwards the whole message on the basis of the message routing information (MRI) towards the NR. Each NSLP forwarder along the path that implements NATFW NSLP processes the NSLP message. Forwarding is done hop-by-hop but may pass transparently through NSLP forwarders that do not contain NATFW NSLP functionality and non-NSIS-aware routers between NSLP hop way points. When the message reaches the NR, the NR can accept the request or reject it. The NR generates a response to CREATE and this response is transported hop-by-hop towards the NI. NATFW NSLP forwarders may reject requests at any time. Figure 14 sketches the message flow between the NI (DS in this example), an NF (e.g., NAT), and an NR (DR in this example).
2つのホストがあっても中間装置の存在下でデータを交換することを可能にするCREATEメッセージを使用することによってNATFW NSLPで実現されます。 NI（データ送信側またはプロキシのいずれか）は、セクション4.3.1で定義されるように、CREATEメッセージを生成し、NTLPにそれを渡します。 NTLPはNR向かってメッセージルーティング情報（MRI）に基づいて、メッセージ全体を転送します。 NATFW NSLPを実装経路に沿った各NSLPフォワーダはNSLPメッセージを処理します。フォワーディングは、ホップバイホップをやっているが、NSLPホップウェイポイント間のNATFW NSLP機能と非NSIS対応のルータを含まないNSLPフォワーダを透過的に通過してもよいです。メッセージは、NRに達したときに、NRは、要求を受け入れるか、拒否することができます。 NRは、作成する応答を生成し、この応答は、NIに向かってホップバイホップに搬送されます。 NATFW NSLPフォワーダは、いつでも要求を拒否することができます。 NI（この例ではDS）、NF（例えば、NAT）、およびNR（この例ではDR）との間の図14のスケッチメッセージフロー。
NI Private Network NF Public Internet NR
| | |
| CREATE | |
|----------------------------->| |
| | |
| | |
| | CREATE |
| |--------------------------->|
| | |
| | RESPONSE |
| RESPONSE |<---------------------------|
|<-----------------------------| |
| | |
| | |
Figure 14: CREATE Message Flow with Success RESPONSE
図14：成功応答でメッセージフローを作成
There are several processing rules for a NATFW peer when generating and receiving CREATE messages, since this message type is used for creating new NATFW NSLP signaling sessions, updating existing ones, and extending the lifetime and deleting NATFW NSLP signaling sessions. The three latter functions operate in the same way for all kinds of CREATE messages, and are therefore described in separate sections:
生成し、このメッセージタイプは、セッションシグナリング既存のものを更新し、寿命を延ばし、NATFW NSLPシグナリングセッションを削除し、新しいNATFW NSLPを作成するために使用されているので、メッセージを作成受信NATFWピアのいくつかの処理ルールがあります。 3つの後者の機能は、メッセージを作成するすべての種類のために同じように動作し、したがって、別のセクションに記載されています。
o Extending the lifetime of NATFW NSLP signaling sessions is described in Section 3.7.3.
NATFW NSLPシグナリングセッションの寿命を拡張oを、セクション3.7.3に記載されています。
o Deleting NATFW NSLP signaling sessions is described in Section 3.7.4.
Oシグナリングセッションの削除NATFW NSLPは、セクション3.7.4に記載されています。
o Updating policy rules is described in Section 3.10.
ポリシールールの更新oを3.10節に記述されています。
For an initial CREATE message creating a new NATFW NSLP signaling session, the processing of CREATE messages is different for every NATFW node type: o NSLP initiator: An NI only generates CREATE messages and hands them over to the NTLP. The NI should never receive CREATE messages and MUST discard them.
最初のための新しいNATFW NSLPシグナリングセッションを作成メッセージを作成、メッセージを作成する処理は、すべてNATFWノードタイプについて異なる：NSLP開始○：NIは、メッセージを作成生成しNTLPにそれらの上に渡します。 NIは、メッセージを作成受けることはありませんし、それらを捨てなければなりません。
o NATFW NSLP forwarder: NFs that are unable to forward the CREATE message to the next hop MUST generate an error RESPONSE of class 'Permanent failure' (5) with response code 'Did not reach the NR' (0x07). This case may occur if the NTLP layer cannot find a NATFW NSLP peer, either another NF or the NR, and returns an error via the GIST API (a timeout error reported by GIST). The NSLP message processing at the NFs depends on the middlebox type:
O NATFW NSLPフォワーダ：クラスの永久故障 '（5）応答コードとNR「に到達しなかった」（0x07の）のエラー応答を生成しなければならない次のホップにCREATEメッセージを転送することができないのNF。この場合は、NTLP層がNATFW NSLPピアを見つけることができない場合、別のNFまたはNRのいずれかを発生し、GISTのAPI（GISTによって報告されたタイムアウトエラー）を介して、エラーを返してもよいです。 NFのNSLPメッセージ処理はミドルタイプによって異なります。
* NAT: When the initial CREATE message is received at the public side of the NAT, it looks for a reservation made in advance, by using an EXTERNAL message (see Section 3.7.2). The matching process considers the received MRI information and the stored MRI information, as described in Section 3.8. If no matching reservation can be found, i.e., no reservation has been made in advance, the NSLP MUST return an error RESPONSE of class 'Signaling session failure' (7) with response code 'No reservation found matching the MRI of the CREATE request' (0x03). If there is a matching reservation, the NSLP stores the data sender's address (and if applicable port number) as part of the source IP address of the policy rule ('the remembered policy rule') to be loaded, and forwards the message with the destination IP address set to the internal (private in most cases) address of the NR. When the initial CREATE message is received at the private side, the NAT binding is allocated, but not activated (see also Appendix D.3). An error RESPONSE message is generated, if the requested policy rule cannot be reserved right away, of class 'Signaling session failure' (7) with response code 'Requested policy rule denied due to policy conflict' (0x4). The MRI information is updated to reflect the address, and if applicable port, translation. The NSLP message is forwarded towards the NR with source IP address set to the NAT's external address from the newly remembered binding.
* NAT：最初のCREATEメッセージはNATのパブリック側で受信されると、それは外部メッセージ（セクション3.7.2を参照）を使用することにより、事前に行われた予約を探します。 3.8節で説明したように、マッチングプロセスは、受信されたMRI情報と格納されたMRI情報を考慮する。一致する予約が見つからない場合、すなわち、何の予約が事前に行われていない、NSLPは、「セッションの失敗をシグナリング」クラスのエラー応答を返さなければなりません（7）レスポンスコード「CREATE要求のMRIを一致が見つかりません予約」を持ちます（0×03）。マッチング予約がある場合は、NSLPがロードされるポリシールール（「覚えポリシールール」）の送信元IPアドレスの一部として、データ送信者のアドレス（及び該当するポート番号場合）を格納し、使用してメッセージを転送しますNRの内部（ほとんどの場合プライベート）のアドレスに設定された宛先IPアドレス。最初のCREATEメッセージがプライベート側で受信されると、NATバインディングが割り当てられますが、（これも付録D.3を参照）が活性化されません。要求されたポリシールールは、（0x4の）レスポンスコード「によるポリシーの競合に拒否された要求されたポリシールール」で（7）「セッションの失敗をシグナリング」クラスで、すぐに予約することができない場合は、エラー応答メッセージは、生成されます。 MRI情報は、アドレスを反映するように更新し、該当する場合ポート、翻訳されています。 NSLPメッセージを新たに結合思い出したからNATの外部アドレスに設定されたソースIPアドレスを持つNRの方に転送されます。
* Firewall: When the initial CREATE message is received, the NSLP just remembers the requested policy rule, but does not install any policy rule. Afterwards, the message is forwarded towards the NR. If the requested policy rule cannot be reserved right away, an error RESPONSE message is generated, of class 'Signaling session failure' (7) with response code 'Requested policy rule denied due to policy conflict' (0x4).
*ファイアウォール：最初のCREATEメッセージを受信すると、NSLPだけで要求されたポリシールールを覚えているが、任意のポリシールールはインストールされません。その後、メッセージは、NRの方に転送されます。要求されたポリシールールをすぐに予約することができない場合は、エラー応答メッセージは、（7）（0x4の）応答コード「ポリシーの競合が原因で拒否された要求されたポリシールール」で、「セッションの失敗をシグナリング」クラスで生成されます。
* Combined NAT and firewall: Processing at combined firewall and NAT middleboxes is the same as in the NAT case. No policy rules are installed. Implementations MUST take into account the order of packet processing in the firewall and NAT functions within the device. This will be referred to as "order of functions" and is generally different depending on whether the packet arrives at the external or internal side of the middlebox.
*複合NATやファイアウォール：組み合わせファイアウォールやNATミドルボックスでの処理は、NATの場合と同じです。いいえポリシールールはインストールされていません。実装は、デバイス内のファイアウォールやNAT機能で考慮にパケット処理の順序を取る必要があります。これは、「機能の順序」と呼ばれ、パケットは、ミドルボックスの外部または内部側に到着するかどうかに応じて、一般的に異なるであろう。
o NSLP receiver: NRs receiving initial CREATE messages MUST reply with a success RESPONSE of class 'Success' (2) with response code set to 'All successfully processed' (0x01), if they accept the CREATE message. Otherwise, they MUST generate a RESPONSE message with a suitable response code. RESPONSE messages are sent back NSLP hop-by-hop towards the NI, irrespective of the response codes, either success or error.
O NSLP受信機：（2）彼らはCREATEメッセージを受け入れた場合、（0×01）「すべて正常に処理さ」に設定応答コードを持つクラス「成功」の成功応答で返答しなければならない最初のCREATEメッセージを受け取るのNR。そうでなければ、彼らは、適切な応答コードで応答メッセージを生成しなければなりません。応答メッセージは、応答コードに関係なく、成功またはエラーのいずれかをNSLPホップバイホップNI向かっに返送されます。
Remembered policy rules at middleboxes MUST be only installed upon receiving a corresponding successful RESPONSE message with the same SID as the CREATE message that caused them to be remembered. This is a countermeasure to several problems, for example, wastage of resources due to loading policy rules at intermediate NFs when the CREATE message does not reach the final NR for some reason.
中間装置に記憶してポリシールールは、それらを記憶させ、CREATEメッセージと同じSIDに対応する成功した応答メッセージを受信すると、インストールする必要があります。これはいくつかの問題への対策としては、例えば、何らかの理由で、最終NRに達していないメッセージを作成中のNFにローディングポリシールールによるリソースの浪費。
Processing of a RESPONSE message is different for every NSIS node type:
RESPONSEメッセージの処理がすべてのNSISノードタイプによって異なります。
o NSLP initiator: After receiving a successful RESPONSE, the data path is configured and the DS can start sending its data to the DR. After receiving an error RESPONSE message, the NI MAY try to generate the CREATE message again or give up and report the failure to the application, depending on the error condition.
O NSLP開始：成功応答を受信した後、データパスが設定され、DSはDRへのデータの送信を開始することができます。エラー応答メッセージを受信した後、NIは、エラー状態に応じて、再びメッセージを作成またはアプリケーションに失敗をあきらめ、レポートを生成しようとするかもしれません。
o NSLP forwarder: NFs install the remembered policy rules, if a successful RESPONSE message with matching SID is received. If an ERROR RESPONSE message with matching SID is received, the NATFW NSLP session is marked as 'Dead', no policy rule is installed and the remembered rule is discarded.
NSLPフォワーダO：一致SIDで成功応答メッセージが受信された場合NFSは、記憶してポリシールールをインストールします。 SIDが一致するエラー応答メッセージを受信した場合、NATFW NSLPセッションが「デッド」としてマークされ、ポリシールールがインストールされていないと思い出したルールは破棄されます。
o NSIS responder: The NR should never receive RESPONSE messages and MUST silently drop any such messages received.
O NSIS応答者：NRは、応答メッセージを受信することはありませんし、静かにどのようなメッセージを受け取っドロップしなければなりません。
NFs and the NR can also tear down the CREATE session at any time by generating a NOTIFY message with the appropriate response code set.
NFSおよびNRはまた、適切な応答コードセットでNOTIFYメッセージを生成することによって、いつでも、CREATEセッションを切断することができます。
NSIS signaling is intended to travel end-to-end, even in the presence of NATs and firewalls on-path. This works well in cases where the data sender is itself behind a NAT or a firewall as described in Section 3.7.1. For scenarios where the data receiver is located
NSISシグナリングは偶数でパスのNAT及びファイアウォールの存在下での、エンド・ツー・エンドを移動することが意図されています。これは、3.7.1項で説明したように、データ送信側はNATやファイアウォールの背後に、それ自体である場合に適しています。データ受信装置が配置されているシナリオに
behind a NAT or a firewall and it needs to receive data flows from outside its own network (usually referred to as inbound flows, see Figure 5), the problem is more troublesome.
それはそれ自身のネットワークの外部から流入するデータを受信する必要がNATまたはファイアウォールの背後に、問題がより面倒で、（通常は図5を参照して、インバウンドフローと呼びます）。
NSIS signaling, as well as subsequent data flows, are directed to a particular destination IP address that must be known in advance and reachable. Data receivers must tell the local NSIS infrastructure (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP signaling and data flows before they can receive these flows. It is necessary to differentiate between data receivers behind NATs and behind firewalls to understand the further NATFW procedures. Data receivers that are only behind firewalls already have a public IP address and they need only to be reachable for NATFW signaling. Unlike data receivers that are only behind firewalls, data receivers behind NATs do not have public IP addresses; consequently, they are not reachable for NATFW signaling by entities outside their addressing realm.
NSISシグナリング、ならびに後続のデータフローは、事前に知られており、到達可能でなければならない特定の宛先IPアドレスに向けられています。データ受信機は、着信NATFW NSLPシグナリングおよびデータについて（すなわち、インバウンドファイアウォール/ NATの）ローカルNSISインフラストラクチャを伝える必要があり、彼らはこれらのフローを受け取ることができる前に流れています。 NATの背後にあると、さらにNATFW手順を理解するためのファイアウォールの背後にあるデータ受信機を区別する必要があります。唯一のファイアウォールの背後にあるデータ受信機は、既にパブリックIPアドレスを持っているし、彼らは唯一のNATFWシグナリングのために到達する必要があります。唯一のファイアウォールの背後にあるデータ受信機とは異なり、NATの背後にあるデータ受信機は、パブリックIPアドレスを持っていません。その結果、彼らはNATFWが自分のアドレス指定領域外の事業体によるシグナル伝達のために到達できません。
The preceding discussion addresses the situation where a DR node that wants to be reachable is unreachable because the NAT lacks a suitable rule with the 'allow' action that would forward inbound data. However, in certain scenarios, a node situated behind inbound firewalls that do not block inbound data traffic (firewalls with "default to allow") unless requested might wish to prevent traffic being sent to it from specified addresses. In this case, NSIS NATFW signaling can be used to achieve this by installing a policy rule with its action set to 'deny' using the same mechanisms as for 'allow' rules.
前述の議論は、NATは、インバウンド・データを転送します「許可」アクションを持つ、適切なルールがないため、到達可能であることを望んでいるDRノードに到達できないような状況に対処しています。ただし、特定のシナリオでは、要求されない限り、インバウンドデータトラフィック（「許可するデフォルト」とのファイアウォール）をブロックしていないインバウンドファイアウォールの背後に位置するノードは、指定されたアドレスからそれに送信されるトラフィックを阻止したいかもしれません。この場合には、NSIS NATFWシグナリングが「許可」ルールと同じメカニズムを使用して「拒否」に設定されたアクションとポリシールールをインストールすることによって、これを達成するために使用することができます。
The required result is obtained by sending an EXTERNAL message in the inbound direction of the intended data flow. When using this functionality, the NSIS initiator for the 'Reserve External Address' signaling is typically the node that will become the DR for the eventual data flow. To distinguish this initiator from the usual case where the NI is associated with the DS, the NI is denoted by NI+ and the NSIS responder is similarly denoted by NR+.
必要な結果が意図したデータフローのインバウンド方向に外部メッセージを送信することによって得られます。この機能を使用する場合、「予約外部アドレス」のNSIS開始剤は、シグナル伝達は、典型的には、最終的なデータフローのDRとなるであろうノードです。 NIは、DSに関連付けられている通常の場合から、このイニシエータを区別するために、NIは、NI +によって示され、NSISレスポンダは、同様NR +で示されています。
Public Internet Private Address
Space
Edge NI(DS) NAT/FW NAT NR(DR) NR+ NI+
エッジNI（DS）NAT / FW NAT NR（DR）NO + NI +
| | | |
| | | |
| | | |
| | EXTERNAL[(DTInfo)] | EXTERNAL[(DTInfo)] |
| |<----------------------|<----------------------|
| | | |
| |RESPONSE[Success/Error]|RESPONSE[Success/Error]|
| |---------------------->|---------------------->|
| | | |
| | | |
============================================================>
Data Traffic Direction
Figure 15: Reservation Message Flow for DR behind NAT or Firewall
図15：NATやファイアウォールの背後にあるDRのための予約メッセージフロー
Figure 15 shows the EXTERNAL message flow for enabling inbound NATFW NSLP signaling messages. In this case, the roles of the different NSIS entities are:
図15は、インバウンドNATFW NSLPシグナリングメッセージを可能にするための外部メッセージフローを示します。この場合、別のNSIS実体の役割は以下のとおりです。
o The data receiver (DR) for the anticipated data traffic is the NSIS initiator (NI+) for the EXTERNAL message, but becomes the NSIS responder (NR) for following CREATE messages.
O予想されるデータトラフィックのためのデータ受信機（DR）は、外部メッセージのNSIS開始剤（NI +）があるが、メッセージを作成するために、次のNSIS応答者（NR）となります。
o The actual data sender (DS) will be the NSIS initiator (NI) for later CREATE messages and may be the NSIS target of the signaling (NR+).
O実際のデータ送信側（DS）は、後にメッセージを作成し、シグナリング（NR +）のNSISの標的とすることができるためNSIS開始剤（NI）であろう。
o It may be necessary to use a signaling destination address (SDA) as the actual target of the EXTERNAL message (NR+) if the DR is located behind a NAT and the address of the DS is unknown. The SDA is an arbitrary address in the outermost address realm on the other side of the NAT from the DR. Typically, this will be a suitable public IP address when the 'outside' realm is the public Internet. This choice of address causes the EXTERNAL message to be routed through the NATs towards the outermost realm and would force interception of the message by the outermost NAT in the network at the boundary between the private address and the public address realm (the edge-NAT). It may also be intercepted by other NATs and firewalls on the path to the edge-NAT.
O、外部メッセージDRは、NATの背後に配置され、DSのアドレスが不明な場合（NR +）の実際のターゲットとしてシグナリング宛先アドレス（SDA）を使用する必要があるかもしれません。 SDAは、DRからNATの反対側の最も外側のアドレス領域内の任意のアドレスです。 「外」レルムが公共のインターネットである場合、通常、これは、適切なパブリックIPアドレスになります。アドレスのこの選択は、外部メッセージは、最も外側の領域に向けてNATを介してルーティングされるようにすると、プライベートアドレスとパブリックアドレスレルム（エッジ-NAT）との境界に、ネットワーク内の最も外側のNATによるメッセージの傍受を強制します。また、エッジNATへのパス上の他のNATやファイアウォールによって遮断されてもよいです。
Basically, there are two different signaling scenarios. Either
基本的には、二つの異なるシグナリングシナリオがあります。どちらか
1. the DR behind the NAT/firewall knows the IP address of the DS in advance, or
1. NAT /ファイアウォールの背後にあるDRは、事前にDSのIPアドレスを知っている、または
Case 1 requires the NATFW NSLP to request the path-coupled message routing method (PC-MRM) from the NTLP. The EXTERNAL message MUST be sent with PC-MRM (see Section 5.8.1 in [RFC5971]) with the direction set to 'upstream' (inbound). The handling of case 2 depends on the situation of the DR: if the DR is solely located behind a firewall, the EXTERNAL message MUST be sent with the PC-MRM, direction 'upstream' (inbound), and the data flow source IP address set to 'wildcard'. If the DR is located behind a NAT, the EXTERNAL message MUST be sent with the loose-end message routing method (LE-MRM, see Section 5.8.2 in [RFC5971]), the destination-address set to the signaling destination IP address (SDA, see also Appendix A). For scenarios with the DR behind a firewall, special conditions apply (see applicability statement in Appendix C). The data receiver is challenged to determine whether it is solely located behind firewalls or NATs in order to choose the right message routing method. This decision can depend on a local configuration parameter, possibly given through DHCP, or it could be discovered through other non-NSLP related testing of the network configuration. The use of the PC-MRM with the known data sender's IP address is RECOMMENDED. This gives GIST the best possible handle to route the message 'upstream' (outbound). The use of the LE-MRM, if and only if the data sender's IP address is not known and the data receiver is behind a NAT, is RECOMMENDED.
ケース1は、NTLPからパス結合メッセージルーティング方法（PC-MRM）を要求するNATFW NSLPを必要とします。外部メッセージは、「上流」（インバウンド）に設定さ方向とPC-MRM（[RFC5971]セクション5.8.1を参照）で送信されなければなりません。ケース2の取り扱いがDRの状況に依存する：DRは、単にファイアウォールの背後にある場合、外部メッセージは、PC-MRM、方向「上流」（インバウンド）、およびデータフローの送信元IPアドレスと送信されなければなりません「ワイルドカード」に設定します。 DRは、NATの背後に配置された場合、外部メッセージは方法ルーティングルーズエンドメッセージで送信されなければならない（LE-MRMを、[RFC5971]セクション5.8.2を参照）、宛先アドレスセットシグナリング宛先IPアドレスに（SDAは、付録Aも参照します）。ファイアウォールの背後にあるDRとのシナリオでは、特別な条件が適用されます（付録Cでの適用性の文を参照してください）。データ受信機は、それが単に適切なメッセージルーティング方法を選択するために、ファイアウォールまたはNATの背後に配置されているかどうかを決定するために挑戦されています。ローカル設定パラメータに依存することができます。この決定は、おそらくDHCPによって与えられた、またはそれは、ネットワーク構成の他の非NSLP関連のテストで発見することができます。既知のデータ送信者のIPアドレスを持つPC-MRMの使用が推奨されます。これは、GISTにルートメッセージ「上流」（アウトバウンド）に可能な限り最高のハンドルを提供します。データの送信者のIPアドレスが知られており、データ受信がNATの背後にあるされていない場合にのみ、LE-MRMの使用は、場合や、推奨されます。
For case 2 with NAT, the NI+ (which could be on the data receiver DR or on any other host within the private network) sends the EXTERNAL message targeted to the signaling destination IP address. The message routing for the EXTERNAL message is in the reverse direction of the normal message routing used for path-coupled signaling where the signaling is sent outbound (as opposed to inbound in this case). When establishing NAT bindings (and a NATFW NSLP signaling session), the signaling direction does not matter since the data path is modified through route pinning due to the external IP address at the NAT. Subsequent NSIS messages (and also data traffic) will travel through the same NAT boxes. However, this is only valid for the NAT boxes, but not for any intermediate firewall. That is the reason for having a separate CREATE message enabling the reservations made with EXTERNAL at the NATs and either enabling prior reservations or creating new pinholes at the firewalls that are encountered on the outbound path depending on whether the inbound and outbound routes coincide.
NATの場合と2の場合、（データ受信DRまたはプライベートネットワーク内の他のホスト上であってもよい）NI +シグナリング宛先IPアドレスを標的とする外部メッセージを送信します。外部メッセージのルーティングメッセージ（この場合インバウンドとは対照的に）シグナリングがアウトバウンド送信される経路結合シグナリングのために使用される通常のメッセージルーティングの逆方向です。 NATバインディング（およびNATFW NSLPシグナリングセッション）を確立する際のデータパスがNATの外部IPアドレスによるピニング経路を介して変更されるので、シグナリング方向は問題ではありません。後続のNSISメッセージ（ともデータトラフィックは）同じNATボックスを通過します。しかし、これはNATボックスのではなく、任意の中間ファイアウォールに対してのみ有効です。すなわち、別のNATのの外部で作られた予約を可能にするメッセージを作成有し、いずれかの先行予約を有効またはインバウンドおよびアウトバウンドルートが一致するか否かに応じてアウトバウンド経路に遭遇するファイアウォールで新たなピンホールを作成するための理由です。
The EXTERNAL signaling message creates an NSIS NATFW signaling session at any intermediate NSIS NATFW peer(s) encountered, independent of the message routing method used. Furthermore, it has to be ensured that the edge-NAT or edge-firewall device is discovered as part of this process. The end host cannot be assumed to know this device -- instead the NAT or firewall box itself is assumed to know that it is located at the outer perimeter of the network. Forwarding of the EXTERNAL message beyond this entity is not necessary, and MUST be prohibited as it may provide information on the capabilities of internal hosts. It should be noted, that it is the outermost NAT or firewall that is the edge-device that must be found during this discovery process. For instance, when there are a NAT and (afterwards) a firewall on the outbound path at the network border, the firewall is the edge-firewall. All messages must be forwarded to the topology-wise outermost edge-device to ensure that this device knows about the NATFW NSLP signaling sessions for incoming CREATE messages. However, the NAT is still the edge-NAT because it has a public globally routable IP address on its public side: this is not affected by any firewall between the edge-NAT and the public network.
EXTERNALシグナリングメッセージを使用する方法をメッセージルーティングとは無関係に発生した中間NSIS NATFWピア（複数可）におけるNSIS NATFWシグナリングセッションを作成します。また、エッジNATまたはエッジファイアウォールデバイスは、このプロセスの一部として検出されることが保証されなければなりません。エンドホストは、このデバイスを知っていると仮定することができない - の代わりにNATまたはファイアウォール・ボックス自体は、それがネットワークの外周に配置されていることを知っているものとします。このエンティティを越えて外部メッセージの転送は不要であり、それは、内部ホストの能力に関する情報を提供することができるように禁止されなければなりません。この発見プロセス中に見つけなければならないエッジデバイスで最も外側のNATやファイアウォールであることに留意すべきです。 NAT及び（後）ネットワーク境界におけるアウトバウンド経路上のファイアウォールが存在する場合、例えば、ファイアウォールは、エッジファイアウォールです。すべてのメッセージは、このデバイスはNATFW NSLPがメッセージを作成着信のためのシグナリングセッションについて知っていることを保証するために、トポロジごとの最も外側のエッジデバイスに転送する必要があります。それはその公共側のパブリックグローバルにルーティング可能なIPアドレスを持っているのでしかし、NATはまだエッジ-NATである：これは、エッジ-NATとパブリックネットワークの間のすべてのファイアウォールで、影響を受けません。
Possible edge arrangements are:
可能なエッジの配置は、次のとおりです。
Public Net ----------------- Private net --------------
| Public Net|--|Edge-FW|--|FW|...|FW|--|DR|
|公共ネット| - |エッジFW | - | FW | ... | FW | - | DR |
| Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR|
|公共ネット| - |エッジFW | - |エッジ-NAT | ... | NATまたはFW | - | DR |
| Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR|
|公共ネット| - |エッジ-NAT | - | NATまたはFW | ... | NATまたはFW | - | DR |
The edge-NAT or edge-firewall device closest to the public realm responds to the EXTERNAL request message with a successful RESPONSE message. An edge-NAT includes a NATFW_EXTERNAL_IP object (see Section 4.2.2), carrying the publicly reachable IP address, and if applicable, a port number.
公共分野へのエッジ-NATまたはエッジファイアウォールデバイス最も近い正常な応答メッセージで外部からの要求メッセージに応答します。エッジ-NATは、公的に到達可能なIPアドレスを保有する、（セクション4.2.2を参照）NATFW_EXTERNAL_IPオブジェクトを含み、該当する場合、ポート番号。
The NI+ can request each intermediate NAT (i.e., a NAT that is not the edge-NAT) to include the external binding address (and if applicable port number) in the external binding address object. The external binding address object stores the external IP address (and port) at the particular NAT. The NI+ has to include the external binding address (see Section 4.2.3) object in the request message, if it wishes to obtain the information.
NI +は、外部バインディングアドレスオブジェクトに外部結合アドレス（及び該当する場合のポート番号）を含むように各中間NAT（エッジNATではない、すなわち、NAT）を要求することができます。外部のバインディングアドレスのオブジェクトは、特定のNATの外部IPアドレス（およびポート）を格納します。 NI +は、それが情報を得たい場合には、要求メッセージ内の外部結合アドレス（セクション4.2.3を参照）オブジェクトを含むことがあります。
There are several processing rules for a NATFW peer when generating and receiving EXTERNAL messages, since this message type is used for creating new reserve NATFW NSLP signaling sessions, updating existing, extending the lifetime, and deleting NATFW NSLP signaling session. The three latter functions operate in the same way for all kinds of CREATE and EXTERNAL messages, and are therefore described in separate sections:
このメッセージタイプは、既存の更新、新しい予備NATFW NSLPシグナリングセッションを作成寿命を延長し、セッションシグナリングNATFW NSLPを削除するために使用されているので、生成し外部メッセージを受信した場合、いくつかの処理規則はNATFWピアのために存在します。 3つの後者の機能は、CREATEと外部メッセージのすべての種類のために同じように動作し、したがって、別のセクションに記載されています。
o Extending the lifetime of NATFW NSLP signaling sessions is described in Section 3.7.3.
NATFW NSLPシグナリングセッションの寿命を拡張oを、セクション3.7.3に記載されています。
o Deleting NATFW NSLP signaling sessions is described in Section 3.7.4.
Oシグナリングセッションの削除NATFW NSLPは、セクション3.7.4に記載されています。
o Updating policy rules is described in Section 3.10.
ポリシールールの更新oを3.10節に記述されています。
The NI+ MUST always include a NATFW_DTINFO object in the EXTERNAL message. Especially, the LE-MRM does not include enough information for some types of NATs (basically, those NATs that also translate port numbers) to perform the address translation. This information is provided in the NATFW_DTINFO (see Section 4.2.8). This information MUST include at least the 'dst port number' and 'protocol' fields, in the NATFW_DTINFO object as these may be required by NATs that are en route, depending on the type of the NAT. All other fields MAY be set by the NI+ to restrict the set of possible NIs. An edge-NAT will use the information provided in the NATFW_DTINFO object to allow only a NATFW CREATE message with a matching MRI to be forwarded. The MRI of the NATFW CREATE message has to use the parameters set in NATFW_DTINFO object ('src IPv4/v6 address', 'src port number', 'protocol') as the source IP address/ port of the flow from DS to DR. A NAT requiring information carried in the NATFW_DTINFO can generate a number of error RESPONSE messages of class 'Signaling session failure' (7):
NI +は、常に外部メッセージ内NATFW_DTINFOオブジェクトを含まなければなりません。特に、LE-MRMは、アドレス変換を実行するためのNATのいくつかのタイプのための十分な情報（また、ポート番号を変換し、基本的に、それらのNAT）を含みません。この情報はNATFW_DTINFO（4.2.8を参照）が設けられています。これらはNATのタイプに応じて、途中であるのNATによって必要とされ得るように、この情報はNATFW_DTINFOオブジェクトに、少なくとも「DSTポート番号」と「プロトコル」フィールドを含まなければなりません。他のすべてのフィールドは可能なのNIのセットを制限するためにNI +によって設定されるかもしれません。エッジNATのみNATFWを転送するマッチングMRIでメッセージを作成できるようにNATFW_DTINFOオブジェクトに提供された情報を使用します。メッセージを作成NATFWのMRIはNATFW_DTINFOオブジェクト（「SRCのIPv4 / v6のアドレス」、「SRCポート番号」、「プロトコル」）DRのDSからのフローの送信元IPアドレス/ポートとして設定されたパラメータを使用しなければなりません。 NATFW_DTINFOで運ばれる情報を必要とするNATは、（7）「セッションの失敗をシグナリング」クラスのエラー応答メッセージの数を生成することができます。
o 'Requested policy rule denied due to policy conflict' (0x04)
O「によるポリシーの競合に拒否された要求されたポリシールール」（0x04を）
o 'Unknown policy rule action' (0x05)
O「不明なポリシールールアクション」（0×05）
o 'Requested rule action not applicable' (0x06)
O「要求されたルールのアクションは適用されません」（0x06で）
o 'NATFW_DTINFO object is required' (0x07)
O 'NATFW_DTINFOオブジェクトが必要である'（0x07の）
o 'Requested value in sub_ports field in NATFW_EFI not permitted' (0x08)
O「許可されていないNATFW_EFIでsub_portsフィールドの要求された値」（0×08）
o 'Requested IP protocol not supported' (0x09)
O 'はサポートされていません要求されたIPプロトコル'（0x09の）
o 'Plain IP policy rules not permitted -- need transport layer information' (0x0A)
O「平野IPポリシールールが許可されていない - 必要トランスポートレイヤ情報」（0x0Aを）
o 'Source IP address range is too large' (0x0C) o 'Destination IP address range is too large' (0x0D)
O（0x0Cの）はO「宛先IPアドレスの範囲が大きすぎる」「送信元IPアドレスの範囲が大きすぎる」（0x0Dが）
o 'Source L4-port range is too large' (0x0E)
O「ソースL4ポートの範囲が大きすぎる」（0x0Eの）
o 'Destination L4-port range is too large' (0x0F)
O（0x0Fの）「宛先L4ポート範囲が大きすぎます」
Processing of EXTERNAL messages is specific to the NSIS node type:
外部メッセージの処理には、NSISノードタイプに固有のものです：
o NSLP initiator: NI+ only generate EXTERNAL messages. When the data sender's address information is known in advance, the NI+ can include a NATFW_DTINFO object in the EXTERNAL message, if not anyway required to do so (see above). When the data sender's IP address is not known, the NI+ MUST NOT include an IP address in the NATFW_DTINFO object. The NI should never receive EXTERNAL messages and MUST silently discard it.
O NSLP開始剤：NI +は唯一の外部メッセージを生成します。データの送信者のアドレス情報が予め分かっている場合には、とにかく（上記参照）そうするために必要とされていない場合、NI +は、外部メッセージにNATFW_DTINFOオブジェクトを含めることができます。データの送信者のIPアドレスが知られていない場合は、NI +はNATFW_DTINFOオブジェクト内のIPアドレスを含んではいけません。 NIは、外部メッセージを受信することはありませんし、静かにそれを捨てなければなりません。
o NSLP forwarder: The NSLP message processing at NFs depends on the middlebox type:
O NSLPフォワーダ：NSLPメッセージ処理のNFでは、ミドルボックスのタイプに依存します。
* NAT: NATs check whether the message is received at the external (public in most cases) address or at the internal (private) address. If received at the external address, an NF MUST generate an error RESPONSE of class 'Protocol error' (3) with response code 'Received EXTERNAL request message on external side' (0x0B). If received at the internal (private address) and the NATFW_EFI object contains the action 'deny', an error RESPONSE of class 'Protocol error' (3) with response code 'Requested rule action not applicable' (0x06) MUST be generated. If received at the internal address, an IP address, and if applicable, one or more ports, are reserved. If the NATFW_EXTERNAL_BINDING object is present in the message, any NAT that is not an edge-NAT MUST include the allocated external IP address, and if applicable one or more ports, (the external binding address) in the NATFW_EXTERNAL_BINDING object. If it is an edge-NAT and there is no edge-firewall beyond, the NSLP message is not forwarded any further and a successful RESPONSE message is generated containing a NATFW_EXTERNAL_IP object holding the translated address, and if applicable, port information from the binding reserved as a result of the EXTERNAL message. The edge-NAT MUST copy the NATFW_EXTERNAL_BINDING object to response message, if the object is included in the EXTERNAL message. The RESPONSE message is sent back towards the NI+. If it is not an edge-NAT, the NSLP message is forwarded further using the translated IP address as signaling source IP address in the LE-MRM and translated port in the NATFW_DTINFO object in the field 'DR port number', i.e., the NATFW_DTINFO object is updated to reflect the translated port number. The edge-NAT or any other
* NAT：NATはアドレスまたは内部（プライベート）アドレスにメッセージが（ほとんどの場合、公共の）外で受信されているかどうかを確認してください。外部アドレスで受信された場合、NF（3）（0x0Bの）応答コード「外部側に受信した外部要求メッセージ」とクラス「プロトコルエラー」のエラー応答を生成しなければなりません。内部（プライベートアドレス）で受信されNATFW_EFIオブジェクトは、アクション「拒否」、「適用されない要求されたルールアクション」（0x06で）生成されなければならないクラスの応答コードで「プロトコルエラー」（3）のエラー応答が含まれている場合。内部アドレス、IPアドレスで受信され、そしてもし該当する場合、一つ以上のポートが予約されています。 NATFW_EXTERNAL_BINDINGオブジェクトがメッセージに存在する場合、エッジNATではない任意のNATは、割り当てられた外部IPアドレスを含み、NATFW_EXTERNAL_BINDINGオブジェクトに適用可能な一つ以上のポート、（外部バインディングアドレス）ならなければなりません。それはエッジNATであり、全くエッジファイアウォールを越えない場合、NSLPメッセージはそれ以上転送されないと正常な応答メッセージが変換されたアドレスを保持するNATFW_EXTERNAL_IPオブジェクトを含む生成され、そして結合予約から適用可能な場合、ポート情報であります外部メッセージの結果として。オブジェクトが外部メッセージに含まれていれば、エッジ-NATは、応答メッセージにNATFW_EXTERNAL_BINDINGオブジェクトをコピーする必要があります。応答メッセージはNI +に向けて送り返されます。それはエッジNATない場合、NSLPメッセージがフィールドにLE-MRM内のソースIPアドレスをシグナリングするよう変換されたIPアドレスを使用してさらに転送さNATFW_DTINFOオブジェクトのポートに翻訳される「DRポート番号」、すなわち、NATFW_DTINFOオブジェクトは、翻訳されたポート番号を反映するように更新されます。エッジNATまたは任意の他の
NAT MUST reject EXTERNAL messages not carrying a NATFW_DTINFO object or if the address information within this object is invalid or is not compliant with local policies (e.g., the information provided relates to a range of addresses ('wildcarded') but the edge-NAT requires exact information about DS's IP address and port) with the above mentioned response codes.
NATはNATFW_DTINFOオブジェクトを持っていない外部メッセージを拒絶しなければなりませんか、このオブジェクト内のアドレス情報が無効であるか、ローカルポリシーに準拠していない場合（例えば、提供される情報は、アドレスの範囲に関し、（「ワイルドカード」）が、エッジ-NATが必要です上記の応答コードとDSのIPアドレスとポート）についての正確な情報。
* Firewall: Non edge-firewalls remember the requested policy rule, keep NATFW NSLP signaling session state, and forward the message. Edge-firewalls stop forwarding the EXTERNAL message. The policy rule is immediately loaded if the action in the NATFW_EFI object is set to 'deny' and the node is an edge-firewall. The policy rule is remembered, but not activated, if the action in the NATFW_EFI object is set to 'allow'. In both cases, a successful RESPONSE message is generated. If the action is 'allow', and the NATFW_DTINFO object is included, and the MRM is set to LE-MRM in the request, additionally a NATFW_EXTERNAL_IP object is included in the RESPONSE message, holding the translated address, and if applicable port, information. This information is obtained from the NATFW_DTINFO object's 'DR port number' and the source-address of the LE-MRM. The edge-firewall MUST copy the NATFW_EXTERNAL_BINDING object to response message, if the object is included in the EXTERNAL message.
*ファイアウォール：非エッジファイアウォールでは、セッション状態を知らせるNATFW NSLPを維持し、メッセージを転送し、要求されたポリシールールを覚えています。エッジファイアウォールは、外部メッセージの転送を停止します。 NATFW_EFIオブジェクトにおけるアクションが「拒否」をするように設定されている場合、ポリシー・ルールは、即座にロードされ、ノードがエッジファイアウォールです。ポリシールールは覚えていますが、NATFW_EFIオブジェクト内のアクションが「許可」に設定されている場合、活性化されていません。どちらの場合も、正常な応答メッセージが生成されます。アクションがある場合に「許可」、およびNATFW_DTINFOオブジェクトが含まれ、MRMは、変換されたアドレスを保持し、さらにNATFW_EXTERNAL_IPオブジェクトが応答メッセージに含まれる要求にLE-MRMに設定され、該当するポート、情報なら。この情報は、NATFW_DTINFOオブジェクトの「DRポート番号」とLE-MRMの送信元アドレスから取得されます。オブジェクトが外部メッセージに含まれていれば、エッジファイアウォールは、応答メッセージにNATFW_EXTERNAL_BINDINGオブジェクトをコピーする必要があります。
* Combined NAT and firewall: Processing at combined firewall and NAT middleboxes is the same as in the NAT case.
*複合NATやファイアウォール：組み合わせファイアウォールやNATミドルボックスでの処理は、NATの場合と同じです。
o NSLP receiver: This type of message should never be received by any NR+, and it MUST generate an error RESPONSE message of class 'Permanent failure' (5) with response code 'No edge-device here' (0x06).
O NSLP受信機：このタイプのメッセージは、任意のNR +によって受信すべきではない、それは（5）応答コード「ここにはエッジデバイス」（0x06で）を用いてクラスの永続的な障害」のエラー応答メッセージを生成しなければなりません。
Processing of a RESPONSE message is different for every NSIS node type:
RESPONSEメッセージの処理がすべてのNSISノードタイプによって異なります。
o NSLP initiator: Upon receiving a successful RESPONSE message, the NI+ can rely on the requested configuration for future inbound NATFW NSLP signaling sessions. If the response contains a NATFW_EXTERNAL_IP object, the NI can use IP address and port pairs carried for further application signaling. After receiving an error RESPONSE message, the NI+ MAY try to generate the EXTERNAL message again or give up and report the failure to the application, depending on the error condition.
O NSLP開始剤：成功の応答メッセージを受信すると、NI +は、将来のインバウンドNATFW NSLPシグナリングセッションのために要求された構成に依存することができます。応答がNATFW_EXTERNAL_IPオブジェクトが含まれている場合、NIは、さらに、アプリケーションシグナリングに運ばIPアドレスとポートのペアを使用することができます。エラー応答メッセージを受信した後、NI +は再び外部メッセージを生成するか、あきらめとエラー状態に応じて、アプリケーションに失敗を報告しようとするかもしれません。
o NSLP forwarder: NFs simply forward this message as long as they keep state for the requested reservation, if the RESPONSE message contains NATFW_INFO object with class set to 'Success' (2). If the RESPONSE message contains NATFW_INFO object with class set not to 'Success' (2), the NATFW NSLP signaling session is marked as 'Dead'.
O NSLPフォワーダ：RESPONSEメッセージは「成功」（2）に設定されたクラスとNATFW_INFOオブジェクトが含まれている場合、NFSは、単純に、限り、彼らが要求された予約の状態を保つよう、このメッセージを転送します。応答メッセージはありません「成功」に設定されたクラスでNATFW_INFOオブジェクトが含まれている場合（2）、NATFW NSLPシグナリングのセッションは「死者」としてマークされています。
o NSIS responder: This type of message should never be received by any NR+. The NF should never receive response messages and MUST silently discard it.
NSIS応答者（O）メッセージのこのタイプは、任意のNRの+が受信してはいけません。 NFは、応答メッセージを受信することはありませんし、静かにそれを捨てなければなりません。
NFs and the NR can also tear down the EXTERNAL session at any time by generating a NOTIFY message with the appropriate response code set.
NFSおよびNRはまた、適切な応答コードセットでNOTIFYメッセージを生成することによって、いつでも外部セッションを切断することができます。
Reservations with action 'allow' made with EXTERNAL MUST be enabled by a subsequent CREATE message. A reservation made with EXTERNAL (independent of selected action) is kept alive as long as the NI+ refreshes the particular NATFW NSLP signaling session and it can be reused for multiple, different CREATE messages. An NI+ may decide to tear down a reservation immediately after receiving a CREATE message. This implies that a new NATFW NSLP signaling session must be created for each new CREATE message. The CREATE message does not re-use the NATFW NSLP signaling session created by EXTERNAL.
アクションでのご予約は、外部で作られた「許可」以降のCREATEメッセージで有効にする必要があります。 NI +は特定のNATFW NSLPシグナリングセッションをリフレッシュするように、外部で作られた予約（選択されたアクションとは無関係）が長くとして生かされ、それは、メッセージを作成、異なる複数のために再利用することができます。 NI +はすぐにCREATEメッセージを受信した後、予約を取り壊すことを決定することができます。これは、新しいNATFW NSLPシグナリングセッションはそれぞれの新しいCREATEメッセージのために作成しなければならないことを意味します。メッセージEXTERNALによって作成されていない再使用NATFW NSLPシグナリング・セッションを作成します。
Without using CREATE (see Section 3.7.1) or EXTERNAL in proxy mode (see Section 3.7.6) no data traffic will be forwarded to the DR beyond the edge-NAT or edge-firewall. The only function of EXTERNAL is to ensure that subsequent CREATE messages traveling towards the NR will be forwarded across the public-private boundary towards the DR. Correlation of incoming CREATE messages to EXTERNAL reservation states is described in Section 3.8.
CREATE使用せずに、プロキシモードまたはEXTERNAL（3.7.1項を参照）のデータトラフィックは、エッジ-NATまたはエッジファイアウォールを越えてDRに転送されません（セクション3.7.6を参照してください）。 EXTERNALの唯一の機能は、後続のNRへ向かうメッセージを作成することを確実にするためであるDRに向けた官民の境界を越えて転送されます。 EXTERNAL予約状態への着信CREATEメッセージの相関関係は、3.8節に記述されています。
NATFW NSLP signaling sessions are maintained on a soft-state basis. After a specified timeout, sessions and corresponding policy rules are removed automatically by the middlebox, if they are not refreshed. Soft-state is created by CREATE and EXTERNAL and the maintenance of this state must be done by these messages. State created by CREATE must be maintained by CREATE, state created by EXTERNAL must be maintained by EXTERNAL. Refresh messages, are messages carrying the same session ID as the initial message and a NATFW_LT lifetime object with a lifetime greater than zero. Messages with the same SID but which carry a different MRI are treated as updates of the policy rules and are processed as defined in Section 3.10. Every refresh CREATE or EXTERNAL message MUST be acknowledged by an appropriate response message generated by the NR. Upon reception by each NSLP forwarder, the state for the given session ID is extended by the NATFW NSLP signaling session refresh period, a period of time calculated based on a proposed refresh message period. The new (extended) lifetime of a NATFW NSLP signaling session is calculated as current local time plus proposed lifetime value (NATFW NSLP signaling session refresh period). Section 3.4 defines the process of calculating lifetimes in detail.
NATFW NSLPシグナリングセッションは、ソフトステートベースで維持されています。彼らがリフレッシュされていない場合、指定されたタイムアウトの後、セッションおよび対応するポリシールールは、ミドルによって自動的に削除されます。ソフト状態は、CREATEおよび外部で作成され、この状態の維持は、これらのメッセージによって行われなければなりません。 CREATEにより作成された状態では、外部で作成された状態がEXTERNALによって維持されなければならない、CREATEによって維持されなければなりません。リフレッシュメッセージは、ゼロより大きい寿命の最初のメッセージと同じセッションID及びNATFW_LT寿命オブジェクトを担持するメッセージです。同じSIDを持つメッセージが、これは異なるMRIを運ぶポリシールールの更新として扱われ、3.10で定義されるように処理されます。すべては、CREATEリフレッシュまたは外部メッセージはNRによって生成された適切な応答メッセージによって確認されなければなりません。各NSLPフォワーダによって受信すると、指定されたセッションIDの状態は、セッションリフレッシュ期間、提案されたリフレッシュメッセージの期間に基づいて算出された時間の期間をシグナリングNATFW NSLPによって拡張されます。 NATFW NSLPシグナリングセッションの新しい（拡張）寿命は、現在のローカル時間と提案寿命値（NATFW NSLPセッションリフレッシュ期間をシグナリング）として算出されます。 3.4節を詳細に寿命を計算するプロセスを定義します。
NI Public Internet NAT Private address NR
NI公衆インターネットNATプライベートアドレスNR
| | space | | CREATE[lifetime > 0] | |
| |スペース| | CREATE [寿命> 0] | |
|----------------------------->| |
| | |
| | |
| | CREATE[lifetime > 0] |
| |--------------------------->|
| | |
| | RESPONSE[Success/Error] |
| RESPONSE[Success/Error] |<---------------------------|
|<-----------------------------| |
| | |
| | |
Figure 16: Successful Refresh Message Flow, CREATE as Example
図16：成功のリフレッシュメッセージフローは、例として、CREATE
Processing of NATFW NSLP signaling session refresh CREATE and EXTERNAL messages is different for every NSIS node type:
NATFW NSLPセッションリフレッシュがCREATEシグナリングと外部メッセージの処理がすべてのNSISノードタイプによって異なります。
o NSLP initiator: The NI/NI+ can generate NATFW NSLP signaling session refresh CREATE/EXTERNAL messages before the NATFW NSLP signaling session times out. The rate at which the refresh CREATE/EXTERNAL messages are sent and their relation to the NATFW NSLP signaling session state lifetime is discussed further in Section 3.4.
O NSLP開始剤は：NI / NI +は、セッションがタイムアウトを知らせるNATFW NSLP前/セッションリフレッシュは、CREATE EXTERNALシグナリングメッセージをNATFW NSLPを生成することができます。リフレッシュ/ EXTERNALメッセージを作成する速度が送信され、NATFW NSLPシグナリングセッション状態の寿命との関係は、3.4節で詳しく説明されています。
o NSLP forwarder: Processing of this message is independent of the middlebox type and is as described in Section 3.4.
O NSLPフォワーダ：このメッセージの処理は、ミドルタイプとは無関係であり、セクション3.4に記載されているようです。
o NSLP responder: NRs accepting a NATFW NSLP signaling session refresh CREATE/EXTERNAL message generate a successful RESPONSE message, including the granted lifetime value of Section 3.4 in a NATFW_LT object.
O NSLPレスポンダ：NATFW NSLPシグナリングセッションのリフレッシュを受け入れるのNRがNATFW_LTオブジェクト内のセクション3.4の付与された寿命値を含む成功応答メッセージを、生成/外部メッセージを作成します。
NATFW NSLP signaling sessions can be deleted at any time. NSLP initiators can trigger this deletion by using a CREATE or EXTERNAL messages with a lifetime value set to 0, as shown in Figure 17. Whether a CREATE or EXTERNAL message type is use depends on how the NATFW NSLP signaling session was created.
NATFW NSLPシグナリングセッションはいつでも削除することができます。 NSLP開始剤は、CREATEまたは外部メッセージタイプが使用であるかどうかを図17に示すように、0に設定寿命値とCREATEまたは外部メッセージを使用して、この削除をトリガすることができNATFW NSLPシグナリングセッションが作成された方法に依存します。
NI Public Internet NAT Private address NR
NI公衆インターネットNATプライベートアドレスNR
| | space |
| CREATE[lifetime=0] | |
|----------------------------->| |
| | |
| | CREATE[lifetime=0] |
| |--------------------------->|
| | |
Figure 17: Delete message flow, CREATE as Example
図17：メッセージ・フローを削除し、一例として、CREATE
NSLP nodes receiving this message delete the NATFW NSLP signaling session immediately. Policy rules associated with this particular NATFW NSLP signaling session MUST be also deleted immediately. This message is forwarded until it reaches the final NR. The CREATE/ EXTERNAL message with a lifetime value of 0, does not generate any response, either positive or negative, since there is no NSIS state left at the nodes along the path.
NSLPは、このメッセージがすぐにNATFW NSLPシグナリングのセッションを削除する受信ノード。この特定のNATFW NSLPシグナリングセッションに関連付けられたポリシールールもすぐに削除する必要があります。それは、最終的なNRに達するまで、このメッセージが転送されます。パスに沿ったノードに残されたNSIS状態が存在しないので0の生涯値/ CREATE EXTERNALメッセージは、正または負のいずれかで、任意の応答を生成しません。
NSIS initiators can use CREATE/EXTERNAL message with lifetime set to zero in an aggregated way, such that a single CREATE or EXTERNAL message is terminating multiple NATFW NSLP signaling sessions. NIs can follow this procedure if they like to aggregate NATFW NSLP signaling session deletion requests: the NI uses the CREATE or EXTERNAL message with the session ID set to zero and the MRI's source-address set to its used IP address. All other fields of the respective NATFW NSLP signaling sessions to be terminated are set as well; otherwise, these fields are completely wildcarded. The NSLP message is transferred to the NTLP requesting 'explicit routing' as described in Sections 5.2.1 and 7.1.4. in [RFC5971].
NSIS開始剤は、単一のCREATEまたは外部メッセージが複数NATFW NSLPシグナリングセッションを終了するように集約方法でゼロに設定さ寿命の/外部メッセージを作成し使用することができます。彼らはNATFW NSLPシグナリングのセッション削除要求を集約したい場合はNISは、この手順に従うことができます：NIは、CREATEまたはその使用済みのIPアドレスに設定し、ゼロにセッションIDのセットとMRIのソース・アドレスを持つ外部メッセージ使用しています。それぞれのNATFW NSLPシグナリングセッションの他のすべてのフィールドも同様に設定されて終了します。そうでない場合は、これらのフィールドは完全にワイルドカード化されています。セクション5.2.1および7.1.4に記載したようにNSLPメッセージはNTLP要求「明示的ルーティング」に転送されます。 [RFC5971]インチ
The outbound NF receiving such an aggregated CREATE or EXTERNAL message MUST reject it with an error RESPONSE of class 'Permanent failure' (5) with response code 'Authentication failed' (0x01) if the authentication fails and with an error RESPONSE of class 'Permanent failure' (5) with response code 'Authorization failed' (0x02) if the authorization fails. Proof of ownership of NATFW NSLP signaling sessions, as it is defined in this memo (see Section 5.2.1), is not possible when using this aggregation for multiple session termination. However, the outbound NF can use the relationship between the information of the received CREATE or EXTERNAL message and the GIST messaging association where the request has been received. The outbound NF MUST only accept this aggregated CREATE or EXTERNAL message through already established GIST messaging associations with the NI. The outbound NF MUST NOT propagate this aggregated CREATE or EXTERNAL message but it MAY generate and forward per NATFW NSLP signaling session CREATE or EXTERNAL messages.
アウトバウンドNFは受信そのような凝集は、CREATEまたは外部メッセージが「永久故障」クラスのエラー応答でそれを拒絶しなければなりません（5）応答コードで「認証に失敗しました」（0×01）認証に失敗した場合と永久」クラスのエラー応答に認証が失敗した場合の応答コード（5） 『障害が許可（0×02』）に失敗しました。複数セッション終了のために、この集約を使用する場合、それがこのメモで定義される通りであるNATFW NSLPシグナリングセッションの所有権の証拠は、（セクション5.2.1を参照）、不可能です。しかし、アウトバウンドNFは、CREATE受信または外部メッセージ及び要求を受信したGISTメッセージング関連の情報との間の関係を使用することができます。アウトバウンドNFは、これがNIと既に確立さGISTメッセージング関連付けを介してメッセージを作成または外部集約受け入れなければなりません。アウトバウンドNFは、このCREATE集約または外部メッセージを伝播してはならないが、それは生成し、セッションCREATEまたは外部信号メッセージをNATFW NSLPごとに転送することができます。
NATFW NSLP forwarders and NATFW NSLP responders must have the ability to report asynchronous events to other NATFW NSLP nodes, especially to allow reporting back to the NATFW NSLP initiator. Such asynchronous events may be premature NATFW NSLP signaling session termination, changes in local policies, route change or any other reason that indicates change of the NATFW NSLP signaling session state.
NATFW NSLPフォワーダとNATFW NSLPレスポンダはNATFW NSLPイニシエータに戻って報告できるように、特に、他のNATFW NSLPノードに非同期イベントをレポートする機能を持っている必要があります。そのような非同期イベントは、早期NATFW NSLPシグナリングセッション終了、ローカルポリシー、経路変更またはNATFW NSLPシグナリングセッション状態の変化を示し、他の理由で変更することができます。
NFs and NRs may generate NOTIFY messages upon asynchronous events, with a NATFW_INFO object indicating the reason for event. These reasons can be carried in the NATFW_INFO object (class MUST be set to 'Informational' (1)) within the NOTIFY message. This list shows the response codes and the associated actions to take at NFs and the NI:
NFSとのNRは、イベントの理由を示すNATFW_INFOオブジェクトと、非同期イベント時にNOTIFYメッセージを生成してもよいです。これらの理由は、NOTIFYメッセージ内（クラスは、（1）「情報」に設定しなければならない）NATFW_INFOオブジェクトで行うことができます。このリストは、NFSおよびNIで取るために応答コードとそれに関連するアクションを示しています。
o 'Route change: Possible route change on the outbound path' (0x01): Follow instructions in Section 3.9. This MUST be sent inbound and outbound, if the signaling session is any state except 'Transitory'. The NOTIFY message for signaling sessions in state Transitory MUST be discarded, as the signaling session is anyhow Transitory. The outbound NOTIFY message MUST be sent with explicit routing by providing the SII-Handle to the NTLP.
O「ルート変更：往路の可能性のあるルート変更は」（0×01）：3.9節の指示に従ってください。シグナリングセッションは「一過性」を除くすべての状態がある場合、これは、インバウンドとアウトバウンド送らなければなりません。シグナリングセッションがとにかく一過であるような状態一過でセッションをシグナリングするためのNOTIFYメッセージは、破棄されなければなりません。アウトバウンドNOTIFYメッセージはNTLPにSIIハンドルを提供することによって、明示的な経路で送信されなければなりません。
o 'Re-authentication required' (0x02): The NI should re-send the authentication. This MUST be sent inbound.
O「の再認証を必要とは」（0×02）：NIは、認証を再送信する必要があります。これは、インバウンドを送らなければなりません。
o 'NATFW node is going down soon' (0x03): The NI and other NFs should be prepared for a service interruption at any time. This message MAY be sent inbound and outbound.
O「NATFWノードがすぐに下がっている」（0×03）：NIおよび他のNFSは、いつでもサービスの中断のために準備されるべきです。このメッセージは、インバウンドとアウトバウンド送信されるかもしれません。
o 'NATFW signaling session lifetime expired' (0x04): The NATFW signaling session has expired and the signaling session is invalid now. NFs MUST mark the signaling session as 'Dead'. This message MAY be sent inbound and outbound.
O「NATFWシグナリングのセッションの有効期間の期限が切れ」（0x04を）：NATFWシグナリングのセッションが期限切れになったと、シグナリングセッションが無効になっています。 NFSは「死者」としてシグナリングセッションをマークする必要があります。このメッセージは、インバウンドとアウトバウンド送信されるかもしれません。
o 'NATFW signaling session terminated' (0x05): The NATFW signaling session has been terminated for some reason and the signaling session is invalid now. NFs MUST mark the signaling session as 'Dead'. This message MAY be sent inbound and outbound.
O「NATFWは、セッション終了を知らせる」（0×05）：NATFWのシグナリングセッションが何らかの理由で終了したとシグナリングセッションは現在無効です。 NFSは「死者」としてシグナリングセッションをマークする必要があります。このメッセージは、インバウンドとアウトバウンド送信されるかもしれません。
NOTIFY messages are always sent hop-by-hop inbound towards NI until they reach NI or outbound towards the NR as indicated in the list above.
彼らはNIに達するか、上記のリストに示されているようNRへの発信までNOTIFYメッセージは常にNIへのホップバイホップの着信を送っています。
The initial processing when receiving a NOTIFY message is the same for all NATFW nodes: NATFW nodes MUST only accept NOTIFY messages through already established NTLP messaging associations. The further processing is different for each NATFW NSLP node type and depends on the events notified:
NOTIFYメッセージを受信する最初の処理は、すべてのNATFWのノードで同じである：NATFWノードは既に確立さNTLPメッセージング協会を通じてNOTIFYメッセージを受け入れなければなりません。さらなる処理は、各NATFW NSLPノードタイプに対して異なり、通知されたイベントに依存します。
o NSLP initiator: NIs analyze the notified event and behave appropriately based on the event type. NIs MUST NOT generate NOTIFY messages.
O NSLP開始剤：NISが通知されたイベントを分析し、イベントタイプに基づいて適切に振る舞います。 NISはNOTIFYメッセージを生成してはなりません。
o NSLP forwarder: NFs analyze the notified event and behave based on the above description per response code. NFs SHOULD generate NOTIFY messages upon asynchronous events and forward them inbound towards the NI or outbound towards the NR, depending on the received direction, i.e., inbound messages MUST be forwarded further inbound and outbound messages MUST be forwarded further outbound. NFs MUST silently discard NOTIFY messages that have been received outbound but are only allowed to be sent inbound, e.g., 'Re-authentication required' (0x02).
O NSLPフォワーダ：NFSは、通知されたイベントを分析し、応答コードあたりの上記の説明に基づいて振る舞います。 NFSは、すなわち、インバウンドメッセージを転送する必要があり、さらに、インバウンドおよびアウトバウンドメッセージをさらに送信を転送する必要があり、非同期イベント時にメッセージを通知し、NI向かっインバウンドそれらを転送または受信方向に応じて、NR向かって発信生成する必要があります。 NFSは静かに、アウトバウンド受信されているだけです（0×02）「再認証が必要」、例えば、インバウンド送信することが許可されているNOTIFYメッセージを捨てなければなりません。
o NSLP responder: NRs SHOULD generate NOTIFY messages upon asynchronous events including a response code based on the reported event. The NR MUST silently discard NOTIFY messages that have been received outbound but are only allowed to be sent inbound, e.g., 'Re-authentication required' (0x02).
O NSLP応答者：のNRは、報告されたイベントに基づいて応答コードを含む非同期イベント時にNOTIFYメッセージを生成する必要があります。 NRは静かアウトバウンド受信されただけ（0×02）「再認証が必要」、例えば、インバウンド送信することが許可されるNOTIFYメッセージを捨てなければなりません。
NATFW NSLP forwarders, keeping multiple NATFW NSLP signaling sessions at the same time, can experience problems when shutting down service suddenly. This sudden shutdown can be as a result of local node failure, for instance, due to a hardware failure. This NF generates NOTIFY messages for each of the NATFW NSLP signaling sessions and tries to send them inbound. Due to the number of NOTIFY messages to be sent, the shutdown of the node may be unnecessarily prolonged, since not all messages can be sent at the same time. This case can be described as a NOTIFY storm, if a multitude of NATFW NSLP signaling sessions is involved.
突然サービスをシャットダウンするときNATFW NSLPフォワーダは、同時に複数のNATFW NSLPシグナリング・セッションを保ち、問題が発生することができます。この突然のシャットダウンは、ハードウェア障害には、例えば、ローカルノード障害の結果であり得ます。このNFはNATFW NSLPシグナリング・セッションごとに、NOTIFYメッセージを生成し、インバウンドそれらを送信しようとします。 NOTIFYメッセージの数を送信することに起因しないすべてのメッセージを同時に送信することができるので、ノードのシャットダウンが必要以上に長くすることができます。 NATFW NSLPシグナリングセッションの多くが関与する場合、この場合は、NOTIFY嵐のように記述することができます。
To avoid the need for generating per NATFW NSLP signaling session NOTIFY messages in such a scenario described or similar cases, NFs SHOULD follow this procedure: the NF uses the NOTIFY message with the session ID in the NTLP set to zero, with the MRI completely wildcarded, using the 'explicit routing' as described in Sections 5.2.1 and 7.1.4 of [RFC5971]. The inbound NF receiving this type of NOTIFY immediately regards all NATFW NSLP signaling sessions from that peer matching the MRI as void. This message will typically result in multiple NOTIFY messages at the inbound NF, i.e., the NF can generate per terminated NATFW NSLP signaling session a NOTIFY message. However, an NF MAY also aggregate the NOTIFY messages as described here.
セッションシグナリングNATFW NSLPごとに生成する必要性を避けるために、説明または類似の場合、そのようなシナリオでは、NOTIFYメッセージ、NFSは、この手順に従うべきである：NFは完全にワイルドカード化MRIを用いて、ゼロに設定NTLPのセッションIDを持つNOTIFYメッセージを使用し、セクション5.2.1及び[RFC5971]の7.1.4に記載されているように「明示的なルーティング」を使用。直ちにNOTIFYこのタイプの受信インバウンドNFはボイドとしてMRIに一致そのピアからのすべてのNATFW NSLPシグナリングセッションについて。このメッセージは、典型的には、インバウンドNFにNOTIFYメッセージを複数になり、すなわち、NFは終了NATFW NSLPシグナリングセッションごとにNOTIFYメッセージを生成することができます。ここで説明するようにしかし、NFもNOTIFYメッセージを集約することができます。
Some migration scenarios need specialized support to cope with cases where NSIS is only deployed in some areas of the Internet. End-to-end signaling is going to fail without NSIS support at or near both data sender and data receiver terminals. A proxy mode of operation is needed. This proxy mode of operation must terminate the NATFW NSLP signaling topologically-wise as close as possible to the terminal for which it is proxying and proxy all messages. This NATFW NSLP node doing the proxying of the signaling messages becomes either the NI or the NR for the particular NATFW NSLP signaling session, depending on whether it is the DS or DR that does not support NSIS. Typically, the edge-NAT or the edge-firewall would be used to proxy NATFW NSLP messages.
いくつかの移行シナリオはNSISはインターネットのみの一部の地域で展開されている場合に対処するために専門的な支援を必要としています。エンドツーエンドシグナリングは、データ送信側とデータ受信端末の両方またはその付近NSISのサポートなしで失敗する予定です。操作のプロキシモードが必要とされています。この動作プロキシモードでは、それはすべてのメッセージプロキシとプロキシであるため、端末にできるだけ位相幾何学ワイズの近くのシグナリングNATFW NSLPを終了する必要があります。シグナリングメッセージのプロキシを実行し、このNATFW NSLPノードは、NSISをサポートしていないDSまたはDRであるかどうかに応じて、特定のNATFW NSLPシグナリングセッションのためNIまたはNRのいずれかとなります。典型的には、エッジNATまたはエッジファイアウォール、プロキシNATFW NSLPメッセージに使用されるであろう。
This proxy mode operation does not require any new CREATE or EXTERNAL message type, but relies on extended CREATE and EXTERNAL message types. They are called, respectively, CREATE-PROXY and EXTERNAL-PROXY and are distinguished by setting the P flag in the NSLP header to P=1. This flag instructs edge-NATs and edge-firewalls receiving them to operate in proxy mode for the NATFW NSLP signaling session in question. The semantics of the CREATE and EXTERNAL message types are not changed and the behavior of the various node types is as defined in Sections 3.7.1 and 3.7.2, except for the proxying node. The following paragraphs describe the proxy mode operation for data receivers behind middleboxes and data senders behind middleboxes.
このプロキシモードの動作は、任意の新規作成や外部メッセージタイプを必要とするが、延長CREATEおよび外部メッセージの種類に依存していません。これらはそれぞれ、CREATE-PROXYおよび外部プロキシと呼ばれ、P = 1にNSLPヘッダにPフラグを設定することによって区別されます。このフラグは、エッジのNAT及び当該NATFW NSLPシグナリングセッションのプロキシモードで動作するようにそれらを受信するエッジファイアウォールを指示します。セマンティクスCREATEおよび外部メッセージタイプがプロキシノードを除いて、セクション3.7.1及び3.7.2で変更されず、様々なノードタイプの挙動は以下のように定義されています。次の段落では、ミドルボックスの背後にあるミドルボックスとデータの送信者の背後にあるデータ受信用のプロキシモードの動作を説明します。
The NATFW NSLP gives the NR the ability to install state on the inbound path towards the data sender for outbound data packets, even when only the receiving side is running NSIS (as shown in Figure 18). The goal of the method described is to trigger the edge-NAT/ edge-firewall to generate a CREATE message on behalf of the data receiver. In this case, an NR can signal towards the network border as it is performed in the standard EXTERNAL message handling scenario as in Section 3.7.2. The message is forwarded until the edge-NAT/ edge-firewall is reached. A public IP address and port number is reserved at an edge-NAT/edge-firewall. As shown in Figure 18, unlike the standard EXTERNAL message handling case, the edge-NAT/ edge-firewall is triggered to send a CREATE message on a new reverse path that traverse several firewalls or NATs. The new reverse path for CREATE is necessary to handle routing asymmetries between the edge-NAT/edge-firewall and the DR. It must be stressed that the semantics of the CREATE and EXTERNAL messages are not changed, i.e., each is processed as described earlier.
NATFW NSLP（図18に示すように）のみ、受信側はNSISを実行している場合でも、NRをアウトバウンド・データ・パケットのためのデータ送信側に向かって復路で状態をインストールすることができます。記載された方法の目的は、データ受信の代わりにCREATEメッセージを生成するエッジNAT /ファイアウォールエッジをトリガすることです。それは、セクション3.7.2のようなシナリオを扱う標準外部メッセージで実行されるように、この場合には、NRは、ネットワーク境界に向かって信号を送ることができます。エッジ-NAT /エッジファイアウォールが到達するまでのメッセージが転送されます。パブリックIPアドレスとポート番号は、エッジ-NAT /エッジファイアウォールで予約されています。標準外部メッセージ処理の場合とは異なり、図18に示すように、エッジNAT /エッジファイアウォールは、いくつかのファイアウォールまたはNATのを横切る新しい逆の経路で作成メッセージを送信するようにトリガされます。 CREATEのための新しい逆の経路は、エッジ・NAT /エッジファイアウォールとDRの間でルーティングの非対称性に対処することが必要です。 CREATEおよび外部メッセージのセマンティクスは、変更されていない前述のように、すなわち、それぞれが処理されることを強調しなければなりません。
DS Public Internet NAT/FW Private address DR No NI NF space NR NR+ NI+
DS公衆インターネットNAT / FWプライベートアドレスDRませんNI NFスペースNR NR + NI +
| | EXTERNAL-PROXY[(DTInfo)] |
| |<------------------------- |
| | RESPONSE[Error/Success] |
| | ---------------------- > |
| | CREATE |
| | ------------------------> |
| | RESPONSE[Error/Success] |
| | <---------------------- |
| | |
Figure 18: EXTERNAL Triggering Sending of CREATE Message
図18：外部トリガメッセージを作成する送信します
A NATFW_NONCE object, carried in the EXTERNAL and CREATE message, is used to build the relationship between received CREATEs at the message initiator. An NI+ uses the presence of the NATFW_NONCE object to correlate it to the particular EXTERNAL-PROXY. The absence of a NONCE object indicates a CREATE initiated by the DS and not by the edge-NAT. The two signaling sessions, i.e., the session for EXTERNAL-PROXY and the session for CREATE, are not independent. The primary session is the EXTERNAL-PROXY session. The CREATE session is secondary to the EXTERNAL-PROXY session, i.e., the CREATE session is valid as long as the EXTERNAL-PROXY session is the signaling states 'Established' or 'Transitory'. There is no CREATE session in any other signaling state of the EXTERNAL-PROXY, i.e., 'Pending' or 'Dead'. This ensures fate-sharing between the two signaling sessions.
メッセージを作成し、外部で運ばNATFW_NONCEオブジェクトは、受信したメッセージのイニシエータで作成との間の関係を構築するために使用されます。 NI +は、特定の外部プロキシにそれを相関させるNATFW_NONCEオブジェクトの存在を利用します。 NONCEオブジェクトが存在しないことは、DSによってではなくエッジNATによって開始CREATE示します。 2つのシグナリングセッションは、すなわち、外部プロキシとCREATEのセッションのためのセッションは、独立していません。主なセッションは、EXTERNAL-PROXYセッションです。セッションは、外部プロキシセッションに二次的であるCREATE、すなわち、セッションを作成すると、外部PROXYセッション限り有効でシグナリング状態「が設立」または「一過」です。何即ち、「保留中」または「デッド」に、外部プロキシの他のシグナリング状態でセッションを作成が存在しません。これは、二つのシグナリングセッションの間に運命共有を保証します。
These processing rules of EXTERNAL-PROXY messages are added to the regular EXTERNAL processing: o NSLP initiator (NI+): The NI+ MUST take the session ID (SID) value of the EXTERNAL-PROXY session as the nonce value of the NATFW_NONCE object.
外部PROXYメッセージのこれら処理規則は、規則的な外部の処理に追加される：NSLP開始剤（NI +）O：NI +はNATFW_NONCEオブジェクトのナンス値などの外部プロキシセッションのセッションID（SID）値を取らなければなりません。
o NSLP forwarder being either edge-NAT or edge-firewall: When the NF accepts an EXTERNAL-PROXY message, it generates a successful RESPONSE message as if it were the NR, and it generates a CREATE message as defined in Section 3.7.1 and includes a NATFW_NONCE object having the same value as of the received NATFW_NONCE object. The NF MUST NOT generate a CREATE-PROXY message. The NF MUST refresh the CREATE message signaling session only if an EXTERNAL-PROXY refresh message has been received first. This also includes tearing down signaling sessions, i.e., the NF must tear down the CREATE signaling session only if an EXTERNAL-PROXY message with lifetime set to 0 has been received first.
エッジNATまたはエッジファイアウォールのいずれかであるフォワーダNSLP O：NFは、外部プロキシメッセージを受け付けると、それがNRであるかのように、それが成功した応答メッセージを生成し、セクション3.7.1で定義されるように、それは、CREATEメッセージを生成し受信NATFW_NONCEオブジェクトのと同じ値を有するNATFW_NONCEオブジェクトを含みます。 NFは、CREATE-PROXYメッセージを生成してはなりません。 NFは、外部プロキシリフレッシュメッセージが最初に受信された場合にのみ、CREATEメッセージシグナリングセッションをリフレッシュする必要があります。また、これはすなわち、NFは0に設定さ寿命の外部PROXYメッセージが最初に受信された場合にのみ、CREATEシグナリングセッションを切断する必要があり、セッションシグナリングダウン引き裂く含みます。
The scenario described in this section challenges the data receiver because it must make a correct assumption about the data sender's ability to use NSIS NATFW NSLP signaling. It is possible for the DR to make the wrong assumption in two different ways:
それはNSIS NATFW NSLPシグナリングを使用するデータ送信者の能力に関する正しい仮定をしなければならないので、このセクションで説明するシナリオは、データ受信に挑戦します。 DRは、2つの異なる方法で間違った仮定をすることが可能です：
a) the DS is NSIS unaware but the DR assumes the DS to be NSIS aware, and
A）DSはNSIS気づかないが、DRはNSISを認識するようにDSを想定しており、
b) the DS is NSIS aware but the DR assumes the DS to be NSIS unaware.
B）DSは認識してNSISですが、DRはNSIS気づかないためにDSを前提としています。
Case a) will result in middleboxes blocking the data traffic, since the DS will never send the expected CREATE message. Case b) will result in the DR successfully requesting proxy mode support by the edge-NAT or edge-firewall. The edge-NAT/edge-firewall will send CREATE messages and DS will send CREATE messages as well. Both CREATE messages are handled as separated NATFW NSLP signaling sessions and therefore the common rules per NATFW NSLP signaling session apply; the NATFW_NONCE object is used to differentiate CREATE messages generated by the edge-NAT/edge-firewall from the NI-initiated CREATE messages. It is the NR's responsibility to decide whether to tear down the EXTERNAL-PROXY signaling sessions in the case where the data sender's side is NSIS aware, but was incorrectly assumed not to be so by the DR. It is RECOMMENDED that a DR behind NATs use the proxy mode of operation by default, unless the DR knows that the DS is NSIS aware. The DR MAY cache information about data senders that it has found to be NSIS aware in past NATFW NSLP signaling sessions.
DSは、CREATE期待されるメッセージを送信することはありませんので、ケースA）は、データトラフィックをブロックする中間ボックスになります。ケースb）はDRが正常にエッジNATまたはエッジファイアウォールによってプロキシモードのサポートを要求することになります。エッジ-NAT /エッジファイアウォールは、メッセージを作成、送信されますとDSは、同様のメッセージを作成、送信します。双方は、メッセージが分離NATFW NSLPシグナリングセッションとして処理され、したがって、セッションシグナリングNATFW NSLPにつき共通のルールが適用され、CREATE。 NATFW_NONCEオブジェクトは、メッセージを作成NI-開始からエッジNAT /エッジファイアウォールによって生成されたメッセージを作成区別するために使用されます。データ送信者側が認識してNSISである場合にEXTERNAL-PROXYシグナリングセッションを切断するかどうかを決定するためのNRの責任ですが、間違ってDRでそうではないと仮定しました。 DRは、DSはNSISが認識していることを知っていない限り、NATの背後にあるDRは、デフォルトで操作のプロキシモードを使用することをお勧めします。 DRは、それが過去NATFW NSLPシグナリングのセッションで意識NSISであることが判明したデータの送信者に関する情報をキャッシュすることができます。
There is a possible race condition between the RESPONSE message to the EXTERNAL-PROXY and the CREATE message generated by the edge-NAT. The CREATE message can arrive earlier than the RESPONSE message. An NI+ MUST accept CREATE messages generated by the edge-NAT even if the RESPONSE message to the EXTERNAL-PROXY was not received.
EXTERNAL-PROXYとエッジNATによって生成されたCREATEメッセージに対する応答メッセージの間の可能な競合状態があります。 CREATEメッセージは、応答メッセージよりも早く到着することができます。 NI +は、外部プロキシに対する応答メッセージが受信されなかった場合でもエッジNATによって生成されたメッセージを作成受け入れなければなりません。
As with data receivers behind middleboxes, data senders behind middleboxes can require proxy mode support. The issue here is that there is no NSIS support at the data receiver's side and, by default, there will be no response to CREATE messages. This scenario requires the last NSIS NATFW NSLP-aware node to terminate the forwarding and to proxy the response to the CREATE message, meaning that this node is generating RESPONSE messages. This last node may be an edge-NAT/ edge-firewall, or any other NATFW NSLP peer, that detects that there is no NR available (probably as a result of GIST timeouts but there may be other triggers).
ミドルボックスの背後にあるデータ受信機と同様に、ミドルボックスの背後にあるデータの送信者は、プロキシモードのサポートを必要とすることができます。ここでの問題は、デフォルトでは、メッセージを作成するには、応答はありません、データ受信者側では一切NSISサポートがないことであると。このシナリオでは、このノードが応答メッセージを生成していることを意味し、転送や代理するために作成するメッセージへの応答を終了するために、最後のNSIS NATFW NSLP認識ノードが必要です。この最後のノードが利用可能なNRが存在しない（おそらく、GISTタイムアウトの結果としては、他のトリガがあってもよい）ことを検出するエッジNAT /エッジファイアウォール、または他の任意のNATFW NSLPピアであってもよいです。
DS Private Address NAT/FW Public Internet NR NI Space NF no NR
DSプライベートアドレスNAT / FW公衆インターネットNR NIスペースNFなしNR
| | |
| CREATE-PROXY | |
|------------------------------>| |
| | |
| RESPONSE[SUCCESS/ERROR] | |
|<------------------------------| |
| | |
Figure 19: Proxy Mode CREATE Message Flow
図19：プロキシモードでは、メッセージフローを作成
The processing of CREATE-PROXY messages and RESPONSE messages is similar to Section 3.7.1, except that forwarding is stopped at the edge-NAT/edge-firewall. The edge-NAT/edge-firewall responds back to NI according to the situation (error/success) and will be the NR for future NATFW NSLP communication.
CREATE-PROXYメッセージと応答メッセージの処理は、その転送がエッジNAT /エッジファイアウォールで停止している以外は、セクション3.7.1に類似しています。エッジ-NAT /エッジファイアウォールは、状況（エラー/成功）によるバックNIに応答し、将来のNATFW NSLPの通信のためのNRとなります。
The NI can choose the proxy mode of operation although the DR is NSIS aware. The CREATE-PROXY mode would not configure all NATs and firewalls along the data path, since it is terminated at the edge-device. Any device beyond this point will never receive any NATFW NSLP signaling for this flow.
DRは、NSIS認識しているものの、NIは、操作のプロキシモードを選択することができます。それはエッジデバイスで終端されているので、CREATEプロキシモードは、データパスに沿ったすべてのNATやファイアウォールを設定しないであろう。このポイントを超えて任意のデバイスは、このフローのためのシグナリングの任意NATFW NSLPを受け取ることはありません。
The above sections described the proxy mode for cases where the NATFW NSLP is solely deployed at the network edges. However, the NATFW NSLP might be incrementally deployed first in some network edges, but later on also in other parts of the network. Using the proxy mode only would prevent the NI from determining whether the other parts of the network have also been upgraded to use the NATFW NSLP. One way of determining whether the path from the NI to the NR is NATFW-NSLP-capable is to use the regular CREATE message and to wait for a successful response or an error response. This will lead to extra messages being sent, as a CREATE message, in addition to the CREATE-PROXY message (which is required anyhow), is sent from the NI.
上記のセクションでは、NATFW NSLPは、単にネットワークエッジに配備されている場合にプロキシモードを記載しています。しかし、NATFW NSLPはインクリメンタルネットワークの他の部分でも、後にいくつかのネットワークエッジで最初の展開が、可能性があります。プロキシモードを使用すると、唯一のネットワークの他の部分でもNATFW NSLPを使用するようにアップグレードされているかどうかを判断するからNIを防止するであろう。 NRのNIからのパスがNATFW-NSLP-可能であるかどうかを決定する1つの方法は、通常、CREATEメッセージを使用して、成功した応答またはエラー応答を待つことです。 （とにかく必要とされる）を作成し、PROXYメッセージに加えて、メッセージを作成すると、これは、余分なメッセージが送信されることにつながる、NIから送信されます。
The NATFW NSLP allows the usage of the proxy-mode and a further probing of the path by the edge-NAT or edge-firewall. The NI can request proxy-mode handling as described, and can set the E flag (see Figure 20) to request the edge-NAT or edge-firewall to probe the further path for NATFW NSLP enabled NFs or an NR.
NATFW NSLPは、プロキシモードとエッジNATまたはエッジファイアウォールによって経路のさらなるプロービングの使用を可能にします。 NIは、記載されているように、プロキシモードの処理を要求することができ、およびEフラグを設定することができる（図20参照）NATFW NSLPのための更なる経路を探索するためにエッジNATまたはエッジファイアウォールを要求するために、NFSまたはNRを可能にしました。
The edge-NAT or edge-firewall MUST continue to send the CREATE-PROXY or EXTERNAL-proxy towards the NR, if the received proxy-mode message has the E flag set, in addition to the regular proxy mode handling. The edge-NAT or edge-firewall relies on NTLP measures to determine whether or not there is another NATFW NSLP reachable towards the NR. A failed attempt to forward the request message to the NR will be silently discarded. A successful attempt of forwarding the request message to the NR will be acknowledged by the NR with a successful response message, which is subject to the regular behavior described in the proxy-mode sections.
エッジNATまたはエッジファイアウォールは、受信したプロキシモードのメッセージは、通常のプロキシモードの処理に加えて、Eフラグが設定されている場合、NR向かっCREATE-PROXYまたは外部プロキシを送信し続けなければなりません。エッジ-NATまたはエッジファイアウォールは、NRの方に到達可能な別のNATFW NSLPがあるかどうかを判断するためにNTLP対策に依存しています。 NRに要求メッセージを転送するように失敗した試みは黙って破棄されます。 NRに要求メッセージを転送するの成功の試みは、プロキシモードのセクションで説明正規動作の対象となる正常な応答メッセージとNRによって確認されるであろう。
The proxy mode assumes that the edge-NAT or edge-firewall are properly configured by network operator, i.e., the edge-device is really the final NAT or firewall of that particular network. There is currently no known way of letting the NATFW NSLP automatically detect which of the NAT or firewalls are the actual edge of a network. Therefore, it is important for the network operator to configure the edge-NAT or edge-firewall and also to re-configure these devices if they are not at the edge anymore. For instance, an edge-NAT is located within an ISP and the ISP chooses to place another NAT in front of this edge-NAT. In this case, the ISP needs to reconfigure the old edge-NAT to be a regular NATFW NLSP NAT and to configure the newly installed NAT to be the edge-NAT.
プロキシモード、すなわち、エッジデバイスが実際にその特定のネットワークの最終的なNATまたはファイアウォールであり、エッジNATまたはエッジファイアウォールが適切にネットワークオペレータによって設定されていることを前提としています。 NATFW NSLPは、自動的にネットワークの実際のエッジいるNATやファイアウォールのかを検出させることのない既知の方法はありません。彼らはもう縁でない場合は、ネットワークオペレータは、これらのデバイスを再構成するためにも、エッジ-NATまたはエッジファイアウォールを設定し、するので、それが重要です。例えば、エッジ-NATは、ISP内に配置されており、ISPは、このエッジNATの前に別のNATを配置することを選択します。この場合、ISPは、定期的なNATFW NLSP NATすると、エッジ-NATであることを新たにインストールされたNATを設定するには、古いエッジ-NATを再設定する必要があります。
Section 3.7.2 describes how NSIS nodes behind NATs can obtain a publicly reachable IP address and port number at a NAT and how the resulting mapping rule can be activated by using CREATE messages (see Section 3.7.1). The information about the public IP address/port number can be transmitted via an application-level signaling protocol and/or third party to the communication partner that would like to send data toward the host behind the NAT. However, NSIS signaling flows are sent towards the address of the NAT at which this particular IP address and port number is allocated and not directly to the allocated IP address and port number. The NATFW NSLP forwarder at this NAT needs to know how the incoming NSLP CREATE messages are related to reserved addresses, meaning how to demultiplex incoming NSIS CREATE messages.
セクション3.7.2は、NATの背後にあるNSISノードがNATで公に到達可能なIPアドレスとポート番号を取得する方法について説明し、どのように得られたマッピングルールメッセージ（セクション3.7.1を参照）を作成し使用することによって活性化することができます。パブリックIPアドレス/ポート番号の情報は、アプリケーションレベルのシグナリングプロトコルおよび/またはNATの背後にあるホストに向かってデータを送信したい通信相手に第三者を介して伝送することができます。しかし、NSISシグナリングフローは、この特定のIPアドレスとポート番号が割り当てられたIPアドレスとポート番号に直接割り当てられていないされたNATのアドレスに向けて送られます。このNATでNATFW NSLPフォワーダは、着信NSLPメッセージがメッセージを作成、着信NSISを分離する方法を意味し、予約されたアドレスに関連しているCREATE方法を知っておく必要があります。
The demultiplexing method uses information stored at the local NATFW NSLP node and in the policy rule. The policy rule uses the LE-MRM MRI source-address (see [RFC5971]) as the flow destination IP address and the network-layer-version (IP-ver) as IP version. The external IP address at the NAT is stored as the external flow destination IP address. All other parameters of the policy rule other than the flow destination IP address are wildcarded if no NATFW_DTINFO object is included in the EXTERNAL message. The LE-MRM MRI destination-address MUST NOT be used in the policy rule, since it is solely a signaling destination address.
分離方法は、ローカルNATFW NSLPノードにおいて、ポリシールールに格納された情報を使用します。ポリシー・ルールは、IPバージョンとしてフロー宛先IPアドレスとネットワーク層バージョン（IP-VER）としてLE-MRM MRIソース・アドレス（[RFC5971]を参照）を使用します。 NATの外部IPアドレスは、外部フローの宛先IPアドレスとして記憶されます。何NATFW_DTINFOオブジェクトが外部メッセージに含まれていない場合、フローの宛先IPアドレス以外のポリシールールの他のすべてのパラメータは、ワイルドカードされています。それは単にシグナリング宛先アドレスであるので、LE-MRM MRI宛先アドレスは、ポリシールールに使用してはいけません。
If the NATFW_DTINFO object is included in the EXTERNAL message, the policy rule is filled with further information. The 'dst port number' field of the NATFW_DTINFO is stored as the flow destination port number. The 'protocol' field is stored as the flow protocol. The 'src port number' field is stored as the flow source port number. The 'data sender's IPv4 address' is stored as the flow source IP address. Note that some of these fields can contain wildcards.
NATFW_DTINFOオブジェクトが外部メッセージに含まれている場合、ポリシールールは、さらに情報が充填されています。 NATFW_DTINFOの「DSTポート番号」フィールドは、フローの宛先ポート番号として記憶されます。 「プロトコル」フィールドは、フロープロトコルとして格納されます。 「SRCポート番号」フィールドは、フロー送信元ポート番号として格納されています。 「データの送信者のIPv4アドレスは、」フローの送信元IPアドレスとして格納されています。これらのフィールドのいくつかはワイルドカードを含めることができることに注意してください。
When receiving a CREATE message at the NATFW NSLP, the NATFW NSLP uses the flow information stored in the MRI to do the matching process. This table shows the parameters to be compared against each other. Note that not all parameters need be present in an MRI at the same time.
NATFW NSLPでCREATEメッセージを受信すると、NATFW NSLPは、マッチング処理を行うためにMRIに格納されたフロー情報を使用します。このテーブルには、互いに比較されるパラメータを示しています。いないすべてのパラメータが同時にMRIに存在する必要があることに注意してください。
+-------------------------------+--------------------------------+
| Flow parameter (Policy Rule) | MRI parameter (CREATE message) |
+-------------------------------+--------------------------------+
| IP version | network-layer-version |
| Protocol | IP-protocol |
| source IP address (w) | source-address (w) |
| external IP address | destination-address |
| destination IP address (n/u) | N/A |
| source port number (w) | L4-source-port (w) |
| external port number (w) | L4-destination-port (w) |
| destination port number (n/u) | N/A |
| IPsec-SPI | ipsec-SPI |
+-------------------------------+--------------------------------+
Table entries marked with (w) can be wildcarded and
entries marked with (n/u) are not used for the matching.
Table 1
表1
It should be noted that the Protocol/IP-protocol entries in Table 1 refer to the 'Protocol' field in the IPv4 header or the 'next header' entry in the IPv6 header.
表1のプロトコル/ IPプロトコルエントリがIPv4ヘッダーまたはIPv6ヘッダの「次ヘッダ」エントリに「プロトコル」フィールドを参照することに留意すべきです。
The NATFW NSLP needs to react to route changes in the data path. This assumes the capability to detect route changes, to perform NAT and firewall configuration on the new path and possibly to tear down NATFW NSLP signaling session state on the old path. The detection of route changes is described in Section 7 of [RFC5971], and the NATFW NSLP relies on notifications about route changes by the NTLP. This notification will be conveyed by the API between NTLP and NSLP, which is out of the scope of this memo.
NATFW NSLPデータパスにおけるルート変更に反応する必要があります。これは新しいパスにNATやファイアウォールの設定を行うために、おそらく、古いパスにセッション状態を知らせるNATFW NSLPを取り壊すために、ルート変更を検出する能力を前提としています。ルート変更の検出は、[RFC5971]のセクション7に記載され、そしてNATFW NSLPがNTLPによってルート変更についての通知に依存しています。この通知は、このメモの範囲の外にNTLPとNSLP間のAPIによって搬送されます。
A NATFW NSLP node other than the NI or NI+ detecting a route change, by means described in the NTLP specification or others, generates a NOTIFY message indicating this change and sends this inbound towards NI and outbound towards the NR (see also Section 3.7.5). Intermediate NFs on the way to the NI can use this information to decide later if their NATFW NSLP signaling session can be deleted locally, if they do not receive an update within a certain time period, as described in Section 3.2.8. It is important to consider the transport limitations of NOTIFY messages as mandated in Section 3.7.5.
NTLP仕様等に記載の手段により経路変更を検出NiまたはNi +以外NATFW NSLPノードは、この変化を示すNOTIFYメッセージを生成し、NIに向かって、この着信を送信し、（NR向かって発信セクション3.7.5も参照します）。 3.2.8項で説明したように、彼らは、一定の期間内に更新を受信しない場合、そのNATFW NSLPシグナリング・セッションは、ローカルで削除することができた場合にNIへの道上の中間NFSは後で決めるために、この情報を使用することができます。セクション3.7.5に義務付けられNOTIFYメッセージの輸送制限を考慮することが重要です。
The NI receiving this NOTIFY message MAY generate a new CREATE or EXTERNAL message and send it towards the NATFW NSLP signaling session's NI as for the initial message using the same session ID.
CREATE新規または外部メッセージを生成し、同じセッションIDを使用して、初期メッセージのようNATFW NSLPシグナリングのセッションのNIの方にそれを送信することが、このNOTIFYメッセージを受信するNI。
All the remaining processing and message forwarding, such as NSLP next-hop discovery, is subject to regular NSLP processing as described in the particular sections. Normal routing will guide the new CREATE or EXTERNAL message to the correct NFs along the changed route. NFs that were on the original path receiving these new CREATE or EXTERNAL messages (see also Section 3.10), can use the session ID to update the existing NATFW NSLP signaling session; whereas NFs that were not on the original path will create new state for this NATFW NSLP signaling session. The next section describes how policy rules are updated.
特定のセクションに記載されているようなNSLPネクストホップ発見として、残りのすべての処理とメッセージの転送は、定期的なNSLP処理の対象となります。通常のルーティングは、変更ルートに沿って正しいのNFに新規作成または外部のメッセージを案内します。これらの新規作成または外部メッセージを受信し、元の経路上にあったNFSは、既存のNATFW NSLPシグナリングセッションを更新するために、セッションIDを使用することができ、（セクション3.10を参照します）。このNATFW NSLPシグナリングのセッションのための新しい状態を作成する元のパスにありませんでしたのNF一方。次のセクションでは、ポリシールールが更新される方法を説明します。
NSIS initiators can request an update of the installed/reserved policy rules at any time within a NATFW NSLP signaling session. Updates to policy rules can be required due to node mobility (NI is moving from one IP address to another), route changes (this can result in a different NAT mapping at a different NAT device), or the wish of the NI to simply change the rule. NIs can update policy rules in existing NATFW NSLP signaling sessions by sending an appropriate CREATE or EXTERNAL message (similar to Section 3.4) with modified message routing information (MRI) as compared with that installed previously, but using the existing session ID to identify the intended target of the update. With respect to authorization and authentication, this update CREATE or EXTERNAL message is treated in exactly the same way as any initial message. Therefore, any node along in the NATFW NSLP signaling session can reject the update with an error RESPONSE message, as defined in the previous sections.
NSIS開始剤はNATFW NSLPシグナリングセッション内の任意の時点でインストール/予約ポリシールールの更新を要求することができます。ポリシールールの更新は単に変化によるノードのモビリティ（NIは別のIPアドレスから移動している）、ルート変更（これは異なるNAT装置で異なるNATマッピングをもたらすことができる）、またはNIの希望に必要とされ得ますルール。 NISはNATFW NSLPはそれが以前にインストールと比較して修正されたメッセージルーティング情報（MRI）と（セクション3.4と同様）を作成し、適切なまたは外部メッセージを送信することによってセッションシグナリング既存のが、意図識別するために、既存のセッションIDを使用してポリシールールを更新することができますアップデートの対象。認可および認証に関しては、この更新プログラムには、CREATEまたは外部メッセージは、任意の初期メッセージと全く同じように扱われます。したがって、NATFW NSLPシグナリングセッションに沿った任意のノードは、前のセクションで定義されるように、エラー応答メッセージで更新を拒否することができます。
The message processing and forwarding is executed as defined in the particular sections. An NF or the NR receiving an update simply replaces the installed policy rules installed in the firewall/NAT. The local procedures on how to update the MRI in the firewall/NAT is out of the scope of this memo.
特定のセクションに定義されているメッセージ処理と転送が実行されます。アップデートを受信NFまたはNRは、単にファイアウォール/ NATにインストールされインストールされたポリシールールを置き換えます。ファイアウォール/ NATでMRIを更新する方法について地元の手順は、このメモの範囲外です。
A NATFW NSLP message consists of an NSLP header and one or more objects following the header. The NSLP header is carried in all NATFW NSLP messages and objects are Type-Length-Value (TLV) encoded using big endian (network ordered) binary data representations. Header and objects are aligned to 32-bit boundaries and object lengths that are not multiples of 32 bits must be padded to the next higher 32-bit multiple.
NATFW NSLPメッセージはNSLPヘッダおよびヘッダに続く1つまたは複数のオブジェクトで構成されています。 NSLPヘッダはすべてNATFW NSLPメッセージやオブジェクトである行われるタイプレングス値（TLV）ビッグエンディアン（ネットワークは、順序付けられた）バイナリデータ表現を使用してエンコード。ヘッダと、オブジェクトは、32ビット境界に位置合わせされ、32ビットの倍数ではない物体の長さは、次の上位32ビットの倍数にパディングされなければなりません。
The whole NSLP message is carried as payload of a NTLP message.
全体NSLPメッセージはNTLPメッセージのペイロードとして搬送されます。
Note that the notation 0x is used to indicate hexadecimal numbers.
表記0Xは16進数を示すために使用されることに留意されたいです。
All GIST NSLP-Data objects for the NATFW NSLP MUST contain this common header as the first 32 bits of the object (this is not the same as the GIST Common Header). It contains two fields, the NSLP message type and the P Flag, plus two reserved fields. The total length is 32 bits. The layout of the NSLP header is defined by Figure 20.
NATFW NSLPのための全てのGIST NSLP・データ・オブジェクト（これはGIST共通ヘッダと同じではない）オブジェクトの最初の32ビットとして共通ヘッダを含まなければなりません。それは2つのフィールド、NSLPメッセージのタイプとP旗、プラス2つの予約フィールドが含まれています。全長は32ビットです。 NSLPヘッダのレイアウトは、図20によって定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message type |P|E| reserved | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Common NSLP Header
図20：一般的なNSLPヘッダー
The reserved field MUST be set to zero in the NATFW NSLP header before sending and MUST be ignored during processing of the header.
予約フィールドは、送信前NATFW NSLPヘッダにゼロに設定しなければならなくて、ヘッダの処理中に無視しなければなりません。
The defined messages types are:
定義されたメッセージの種類は次のとおりです。
o 0x1: CREATE
Oの0x1の：CREATE
o 0x2: EXTERNAL
Oの0x2の：EXTERNAL
o 0x3: RESPONSE
Oの0x3の：レスポンス
o 0x4: NOTIFY
Oの0x4の：NOTIFY
If a message with another type is received, an error RESPONSE of class 'Protocol error' (3) with response code 'Illegal message type' (0x01) MUST be generated.
別のタイプのメッセージを受信した場合、レスポンスコードとクラスのプロトコルエラー '（3）のエラー応答「不正なメッセージタイプ」（0×01）が生成されなければなりません。
The P flag indicates the usage of proxy mode. If the proxy mode is used, it MUST be set to 1. Proxy mode MUST only be used in combination with the message types CREATE and EXTERNAL. The P flag MUST be ignored when processing messages with type RESPONSE or NOTIFY.
Pフラグは、プロキシモードの使用を示しています。プロキシモードを使用する場合、それは1プロキシモードに設定しなければならない唯一のタイプの作成と外部メッセージと組み合わせて使用されなければなりません。型応答またはNOTIFYのメッセージを処理するときにPフラグは無視しなければなりません。
The E flag indicates, in proxy mode, whether the edge-NAT or edge-firewall MUST continue sending the message to the NR, i.e., end-to-end. The E flag can only be set to 1 if the P flag is set; otherwise, it MUST be ignored. The E flag MUST only be used in combination with the message types CREATE and EXTERNAL. The E flag MUST be ignored when processing messages with type RESPONSE or NOTIFY.
Eフラグは、エッジNATまたはエッジファイアウォールはNR、即ち、エンド・ツー・エンドにメッセージを送信し続ける必要があるかどうか、プロキシモードで、示しています。 Pフラグが設定されている場合、Eフラグは、1に設定することができます。そうでない場合は、それを無視しなければなりません。 Eフラグは、タイプ、作成および外部メッセージと組み合わせて使用されなければなりません。型応答またはNOTIFYのメッセージを処理するときにEフラグは無視しなければなりません。
NATFW NSLP objects use a common header format defined by Figure 21. The object header contains these fields: two flags, two reserved bits, the NSLP object type, a reserved field of 4 bits, and the object length. Its total length is 32 bits.
二つのフラグ、2つの予約ビットで、NSLPオブジェクト型、4ビットの予約フィールド、及び物体長：NATFW NSLPオブジェクトは、オブジェクトヘッダは、これらのフィールドが含まれ、図21で定義された共通ヘッダフォーマットを使用します。その全長は32ビットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Object Type |r|r|r|r| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Common NSLP Object Header
図21：一般的なNSLPのオブジェクトヘッダ
The object length field contains the total length of the object without the object header. The unit is a word, consisting of 4 octets. The particular values of type and length for each NSLP object are listed in the subsequent sections that define the NSLP objects. An error RESPONSE of class 'Protocol error' (3) with response code 'Wrong object length' (0x07) MUST be generated if the length given in the object header is inconsistent with the type of object specified or the message is shorter than implied by the object length. The two leading bits of the NSLP object header are used to signal the desired treatment for objects whose treatment has not been defined in this memo (see [RFC5971], Appendix A.2.1), i.e., the Object Type has not been defined. NATFW NSLP uses a subset of the categories defined in GIST:
オブジェクトの長さフィールドは、オブジェクトヘッダなしでオブジェクトの全体の長さを含んでいます。ユニットは、4つのオクテットからなる単語です。各NSLPオブジェクトのタイプと長さの特定の値は、NSLPオブジェクトを定義する後続のセクションに記載されています。オブジェクトヘッダに所定の長さは、指定されたオブジェクトのタイプと矛盾するまたはメッセージにより暗示さより短い場合、レスポンスコード「間違ったオブジェクトの長さ」（0x07の）を有するクラスのプロトコルエラー '（3）のエラー応答を生成しなければなりませんオブジェクトの長さ。 NSLPオブジェクトヘッダ二リーディングビットは治療このメモで定義されていない（付録A.2.1、[RFC5971]を参照）、すなわち、オブジェクト・タイプが定義されていないオブジェクトの所望の処置を知らせるために使用されます。 NATFW NSLPはGISTで定義されたカテゴリのサブセットを使用しています。
o AB=00 ("Mandatory"): If the object is not understood, the entire message containing it MUST be rejected with an error RESPONSE of class 'Protocol error' (3) with response code 'Unknown object present' (0x06).
O AB = 00（「必須」）：オブジェクトが理解されていない場合、それを含むメッセージ全体がクラス「プロトコルエラー」のエラー応答で拒否されなければならない（3）「本未知のオブジェクト」（0x06で）応答コードを有します。
o AB=01 ("Optional"): If the object is not understood, it should be deleted and then the rest of the message processed as usual.
O AB = 01（「オプション」）：オブジェクトが理解されていない場合、それは削除されるべきであり、次いで、メッセージの残りの部分は通常通り処理されます。
o AB=10 ("Forward"): If the object is not understood, it should be retained unchanged in any message forwarded as a result of message processing, but not stored locally.
O AB = 10（「フォワード」）：オブジェクトが理解されていない場合は、メッセージ処理の結果として転送されたメッセージで不変保持するが、ローカルに格納されていないしなければなりません。
The combination AB=11 MUST NOT be used and an error RESPONSE of class 'Protocol error' (3) with response code 'Invalid Flag-Field combination' (0x09) MUST be generated.
組合せAB = 11を使用してはいけませんと応答コードとクラスのプロトコルエラー '（3）のエラー応答「無効フラグ・フィールドの組み合わせ」（0x09の）を生成しなければなりません。
The following sections do not repeat the common NSLP object header, they just list the type and the length.
次のセクションでは、彼らはただのタイプと長さをリスト、共通NSLPオブジェクトヘッダを繰り返さないでください。
The signaling session lifetime object carries the requested or granted lifetime of a NATFW NSLP signaling session measured in seconds.
シグナリングのセッションの有効期間オブジェクトは、秒単位で測定NATFW NSLPシグナリングセッションの要求または許可された寿命を運びます。
Type: NATFW_LT (0x00C)
タイプ：NATFW_LT（0x00C）
Length: 1
長さ：1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NATFW NSLP signaling session lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Signaling Session Lifetime Object
図22：シグナリングセッション生涯オブジェクト
The external address object can be included in RESPONSE messages (Section 4.3.3) only. It carries the publicly reachable IP address, and if applicable port number, at an edge-NAT.
外部アドレスオブジェクトは、応答メッセージ（4.3.3）に含めることができます。それは公に到達可能なIPアドレスを運び、そしてエッジ-NATで適切なポート番号、あれば。
Type: NATFW_EXTERNAL_IP (0x00D)
タイプ：NATFW_EXTERNAL_IP（0x00D）
Length: 2
長さ：2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number |IP-Ver | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: External Address Object for IPv4 Addresses
図23：IPv4アドレスのための外部アドレスオブジェクト
Please note that the field 'port number' MUST be set to 0 if only an IP address has been reserved, for instance, by a traditional NAT. A port number of 0 MUST be ignored in processing this object.
唯一のIPアドレスは、伝統的なNATにより、例えば、予約されている場合、フィールド「ポート番号が」0に設定しなければならないことに注意してください。 0のポート番号は、このオブジェクトを処理する際に無視しなければなりません。
IP-Ver (4 bits): The IP version number. This field MUST be set to 4.
IP-VER（4ビット）：IPのバージョン番号。このフィールドは4に設定しなければなりません。
The external binding address object can be included in RESPONSE messages (Section 4.3.3) and EXTERNAL (Section 3.7.2) messages. It carries one or multiple external binding addresses, and if applicable port number, for multi-level NAT deployments (for an example, see Section 2.5). The utilization of the information carried in this object is described in Appendix B.
外部のバインディングアドレスオブジェクトが応答メッセージ（4.3.3）と外部（セクション3.7.2）メッセージに含めることができます。これは、1つのまたは複数の外部結合のアドレスを搬送し、マルチレベルNATの展開に適用ポート番号は、（例えば、セクション2.5を参照）場合。この目的で搬送される情報の利用は、付録Bに記載されています
Type: NATFW_EXTERNAL_BINDING (0x00E)
タイプ：NATFW_EXTERNAL_BINDING（0x00E）
Length: 1 + number of IPv4 addresses
長さ：IPv4アドレスの1つの+数
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number |IP-Ver | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: External Binding Address Object
図24：外部バインディングアドレスオブジェクト
Please note that the field 'port number' MUST be set to 0 if only an IP address has been reserved, for instance, by a traditional NAT. A port number of 0 MUST be ignored in processing this object.
唯一のIPアドレスは、伝統的なNATにより、例えば、予約されている場合、フィールド「ポート番号が」0に設定しなければならないことに注意してください。 0のポート番号は、このオブジェクトを処理する際に無視しなければなりません。
IP-Ver (4 bits): The IP version number. This field MUST be set to 4.
IP-VER（4ビット）：IPのバージョン番号。このフィールドは4に設定しなければなりません。
In general, flow information is kept in the message routing information (MRI) of the NTLP. Nevertheless, some additional information may be required for NSLP operations. The 'extended flow information' object carries this additional information about the action of the policy rule for firewalls/NATs and a potential contiguous port.
一般的に、情報はNTLPのメッセージルーティング情報（MRI）に保持されているフロー。それにもかかわらず、いくつかの追加情報は、NSLP操作のために必要な場合があります。 「拡張フロー情報」オブジェクトは、ファイアウォール/ NATのためのポリシールールのアクションと電位隣接ポートに関するこの追加情報を搬送します。
Type: NATFW_EFI (0x00F)
タイプ：NATYO_EFI（0x00F）
Length: 1
長さ：1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule action | sub_ports |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Extended Flow Information
図25：拡張フロー情報
This object has two fields, 'rule action' and 'sub_ports'. The 'rule action' field has these meanings:
このオブジェクトは次の2つのフィールド、「ルールのアクション」と「sub_ports」を有します。 「ルールアクション」フィールドは、これらの意味があります。
o 0x0001: Allow: A policy rule with this action allows data traffic to traverse the middlebox and the NATFW NSLP MUST allow NSLP signaling to be forwarded.
Oは0x0001：許可：このアクションを持つポリシー・ルールは、データトラフィックがミドルを通過することを可能とNATFW NSLPはNSLPシグナリングの転送を許可しなければなりません。
o 0x0002: Deny: A policy rule with this action blocks data traffic from traversing the middlebox and the NATFW NSLP MUST NOT allow NSLP signaling to be forwarded.
O 0×0002：拒否：ミドルとNATFW NSLPを横断するから、このアクションブロックを持つポリシールールをデータトラフィックはNSLPを転送するシグナリングを許してはなりません。
If the 'rule action' field contains neither 0x0001 nor 0x0002, an error RESPONSE of class 'Signaling session failure' (7) with response code 'Unknown policy rule action' (0x05) MUST be generated.
「ルールアクション」フィールドは、0x0001のも0×0002のいずれもが含まれている場合は、応答コードと（7）「セッションの失敗をシグナリング」クラスのエラー応答「不明なポリシールールアクション」（0×05）に生成されなければなりません。
The 'sub_ports' field contains the number of contiguous transport layer ports to which this rule applies. The default value of this field is 0, i.e., only the port specified in the NTLP's MRM or NATFW_DTINFO object is used for the policy rule. A value of 1 indicates that additionally to the port specified in the NTLP's MRM (port1), a second port (port2) is used. This value of port 2 is calculated as: port2 = port1 + 1. Other values than 0 or 1 MUST NOT be used in this field and an error RESPONSE of class 'Signaling session failure' (7) with response code 'Requested value in sub_ports field in NATFW_EFI not permitted' (0x08) MUST be generated. These two contiguous numbered ports can be used by legacy voice over IP equipment. This legacy equipment assumes two adjacent port numbers for its RTP/RTCP flows, respectively.
「sub_ports」フィールドは、このルールが適用される連続したトランスポート層ポートの数が含まれています。このフィールドのデフォルト値、すなわち、NTLPのMRM又はNATFW_DTINFOオブジェクトに指定された唯一のポートは、ポリシールールのために使用され、0です。 1の値は、さらに、NTLPのMRM（ポート1）に指定されたポートに、第二のポート（ポート2）が使用されることを示します。ポート2のこの値は次のように計算される：PORT2 = PORT1 + 1の他の値0または1は、この分野で使用され、（7）応答コードと「要求された値「セッションの失敗をシグナリング」クラスのエラー応答sub_portsにしてはいけませんよりNATFW_EFIのフィールド許可されていない」（0x08の）生成されなければなりません。これらの2つの連続番号のポートは、IP機器上でレガシー音声で使用することができます。このレガシー機器は、それぞれ、そのRTP / RTCPフローのための2つの隣接するポート番号を想定しています。
This object carries the response code in RESPONSE messages, which indicates either a successful or failed CREATE or EXTERNAL message depending on the value of the 'response code' field. This object is also carried in a NOTIFY message to specify the reason for the notification.
このオブジェクトは、成功またはメッセージが「応答コード」フィールドの値に応じて、CREATEまたは外部失敗のいずれかを指示する、応答メッセージで応答コードを運びます。このオブジェクトは、通知の理由を指定するNOTIFYメッセージで運ばれます。
Type: NATFW_INFO (0x010)
タイプ：NATFW_INFO（0x010）
Length: 1
長さ：1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv. | Class | Response Code |r|r|r|r| Object Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Information Code Object
図26：情報コードオブジェクト
The field 'resv.' is reserved for future extensions and MUST be set to zero when generating such an object and MUST be ignored when receiving. The 'Object Type' field contains the type of the object causing the error. The value of 'Object Type' is set to 0, if no object is concerned. The leading fours bits marked with 'r' are always set to zero and ignored. The 4-bit class field contains the error class. The following classes are defined:
フィールド「RESV」。将来の拡張のために予約されており、そのようなオブジェクトを生成し、受信した場合、無視されなければならない場合、ゼロに設定しなければなりません。 「オブジェクト・タイプ」フィールドは、エラーの原因となったオブジェクトの種類が含まれています。オブジェクトが懸念されていない場合「オブジェクト・タイプ」の値は、0に設定されています。 「R」が付い大手四つんばいビットは常にゼロに設定され、無視されます。 4ビットクラスのフィールドは、エラークラスが含まれています。以下のクラスが定義されています。
o 0: Reserved
0：予約済み
o 1: Informational (NOTIFY only)
O 1：通知（NOTIFYのみ）
o 2: Success
O 2：成功
o 3: Protocol error
O 3：プロトコルエラー
o 4: Transient failure
O 4：一時的な障害
o 5: Permanent failure
O 5：永久的な失敗
o 7: Signaling session failure
O 7：シグナリングセッション失敗
Within each error class a number of responses codes are defined as follows.
次のように各エラー・クラス内の応答コードの数が定義されています。
o Informational:
情報O：
* 0x01: Route change: possible route change on the outbound path.
* 0×01：ルート変更：往路の可能ルート変更。
* 0x02: Re-authentication required.
* 0×02：再認証が必要です。
* 0x03: NATFW node is going down soon.
* 0x03の：NATFWノードはすぐに下がっています。
* 0x04: NATFW signaling session lifetime expired.
* 0x04を：セッションの有効期間を知らせるNATFWが満了しました。
* 0x05: NATFW signaling session terminated.
* 0×05：NATFWのシグナリングセッションを終了しました。
o Success:
成功O：
* 0x01: All successfully processed.
* 0×01：すべて正常に処理。
o Protocol error:
Oプロトコルエラー：
* 0x01: Illegal message type: the type given in the Message Type field of the NSLP header is unknown.
* 0×01：不正なメッセージタイプ：NSLPヘッダのメッセージタイプフィールドで指定されたタイプが不明です。
* 0x02: Wrong message length: the length given for the message in the NSLP header does not match the length of the message data.
* 0×02：誤ったメッセージの長さ：NSLPヘッダ内のメッセージに指定された長さは、メッセージデータの長さと一致しません。
* 0x03: Bad flags value: an undefined flag or combination of flags was set in the NSLP header.
* 0×03：不良フラグ値：フラグの未定義のフラグまたは組み合わせがNSLPヘッダに設定しました。
* 0x04: Mandatory object missing: an object required in a message of this type was missing.
* 0x04を：必須オブジェクトが欠落している：このタイプのメッセージに必要なオブジェクトが欠落していました。
* 0x05: Illegal object present: an object was present that must not be used in a message of this type.
* 0×05：不正なオブジェクトの存在：オブジェクトは、このタイプのメッセージに使用されてはならない存在でした。
* 0x06: Unknown object present: an object of an unknown type was present in the message.
* 0x06で：不明なオブジェクトの存在：未知のタイプのオブジェクトがメッセージに存在しました。
* 0x07: Wrong object length: the length given for the object in the object header did not match the length of the object data present.
* 0x07の：間違ったオブジェクトの長さ：オブジェクトヘッダ内のオブジェクトのために指定された長さは、オブジェクトデータに存在する長さと一致しませんでした。
* 0x08: Unknown object field value: a field in an object had an unknown value.
* 0x08に：不明なオブジェクトフィールド値：オブジェクト内のフィールドは、未知の値を持っていました。
* 0x09: Invalid Flag-Field combination: An object contains an invalid combination of flags and/or fields.
* 0x09の：無効なフラグ・フィールドの組み合わせ：オブジェクトは、フラグおよび/またはフィールドの無効な組み合わせが含まれています。
* 0x0A: Duplicate object present.
*は0x0A：オブジェクトの存在を複製します。
* 0x0B: Received EXTERNAL request message on external side.
* 0x0Bの外部側に外部からの要求メッセージを受信しました。
o Transient failure:
一時的な障害○：
* 0x01: Requested resources temporarily not available.
* 0×01：要求されたリソースを一時的利用できません。
o Permanent failure:
永続的なエラーO：
* 0x01: Authentication failed.
* 0×01：認証に失敗しました。
* 0x02: Authorization failed.
* 0×02：認証に失敗しました。
* 0x04: Internal or system error.
* 0x04の：内部またはシステム・エラー。
* 0x06: No edge-device here.
* 0x06で：ここにはエッジデバイス。
* 0x07: Did not reach the NR.
* 0x07の：NRに達しありませんでした。
o Signaling session failure:
シグナリングセッション失敗O：
* 0x01: Session terminated asynchronously.
* 0×01：セッション非同期に終了しました。
* 0x02: Requested lifetime is too big.
* 0×02：要求寿命が大きすぎます。
* 0x03: No reservation found matching the MRI of the CREATE request.
* 0x03の：CREATE要求のMRIを一致が見つかりません予約。
* 0x04: Requested policy rule denied due to policy conflict.
* 0x04を：ポリシーの競合が原因で拒否されたポリシールールを要請しました。
* 0x05: Unknown policy rule action.
* 0×05：不明なポリシールールアクション。
* 0x06: Requested rule action not applicable.
* 0x06で：要求されたルールアクションは適用されません。
* 0x07: NATFW_DTINFO object is required.
* 0x07の：NATFW_DTINFOオブジェクトが必要です。
* 0x08: Requested value in sub_ports field in NATFW_EFI not permitted.
* 0x08に：NATFW_EFIでsub_portsフィールドで要求された値は許されません。
* 0x09: Requested IP protocol not supported.
* 0x09の：要求されたIPプロトコルサポートされていません。
* 0x0A: Plain IP policy rules not permitted -- need transport layer information.
*は0x0A：平野IPポリシールール許可されていない - 必要トランスポート層の情報を。
* 0x0B: ICMP type value not permitted.
* 0x0Bの：ICMPタイプの値が許可されていません。
* 0x0C: Source IP address range is too large.
* 0x0Cの：ソースIPアドレスの範囲が大きすぎます。
* 0x0D: Destination IP address range is too large.
* 0x0Dを：送信先IPアドレスの範囲が大きすぎます。
* 0x0E: Source L4-port range is too large.
* 0x0Eの：ソースL4ポートの範囲が大きすぎます。
* 0x0F: Destination L4-port range is too large.
* 0x0Fの：宛先L4ポートの範囲が大きすぎます。
* 0x10: Requested lifetime is too small.
* 0x10の：要求寿命が小さすぎます。
* 0x11: Modified lifetime is too big.
* 0x11を：修正寿命が大きすぎます。
* 0x12: Modified lifetime is too small.
* 0x12を：修正寿命が小さすぎます。
This object carries the nonce value as described in Section 3.7.6.
セクション3.7.6に記載したように、この目的は、ノンス値を運びます。
Type: NATFW_NONCE (0x011)
タイプ：NATFW_NONCE（0x011）
Length: 1
長さ：1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Nonce Object
図27：ナンスオブジェクト
This object carries the MSN value as described in Section 3.5.
セクション3.5で説明したように、この目的は、MSNの値を搬送します。
Type: NATFW_MSN (0x012)
タイプ：NATFW_MSN（0x012）
Length: 1
長さ：1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Message Sequence Number Object
図28：メッセージシーケンス番号オブジェクト
The 'data terminal information' object carries additional information that MUST be included the EXTERNAL message. EXTERNAL messages are transported by the NTLP using the Loose-End message routing method (LE-MRM). The LE-MRM contains only the DR's IP address and a signaling destination address (destination IP address). This destination IP address is used for message routing only and is not necessarily reflecting the address of the data sender. This object contains information about (if applicable) DR's port number (the destination port number), the DS's port number (the source port number), the used transport protocol, the prefix length of the IP address, and DS's IP address.
「データ端末情報」の目的は、外部メッセージを含まなければならない付加的な情報を搬送します。外部メッセージは、ルースエンドメッセージルーティング方法（LE-MRM）を用いNTLPによって輸送されます。 LE-MRMは、DRのIPアドレスとシグナリング宛先アドレス（宛先IPアドレス）を含みます。この宛先IPアドレスは、メッセージのみルーティング、必ずしもデータの送信元のアドレスを反映していないために使用されます。このオブジェクトは、DRのポート番号（宛先ポート番号）、DSのポート番号（送信元ポート番号）、使用されるトランスポート・プロトコル、IPアドレスのプレフィックス長、およびDSのIPアドレス（該当する場合）についての情報を含みます。
Type: NATFW_DTINFO (0x013)
タイプ：NATFW_DTINFO（0x013）
Length: variable. Maximum 3.
長さ：変数。最大3。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|P|S| reserved | sender prefix | protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DR port number | DS port number :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPsec-SPI :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data sender's IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: Data Terminal IPv4 Address Object
図29：データ端末のIPv4アドレスオブジェクト
The flags are:
フラグは次のとおりです。
o I: I=1 means that 'protocol' should be interpreted.
O I：I = 1 'プロトコル' は解釈されるべきであることを意味します。
o P: P=1 means that 'dst port number' and 'src port number' are present and should be interpreted.
P O：P = 1「DSTポート番号」と「SRCポート番号」が存在すると解釈されるべきであることを意味します。
o S: S=1 means that SPI is present and should be interpreted.
O S：S = 1は、SPIが存在していると解釈されるべきであることを意味します。
The SPI field is only present if S is set. The port numbers are only present if P is set. The flags P and S MUST NOT be set at the same time. An error RESPONSE of class 'Protocol error' (3) with response code 'Invalid Flag-Field combination' (0x09) MUST be generated if they are both set. If either P or S is set, I MUST be set as well and the protocol field MUST carry the particular protocol. An error RESPONSE of class 'Protocol error' (3) with response code 'Invalid Flag-Field combination' (0x09) MUST be generated if S or P is set but I is not set.
Sが設定されている場合、SPIフィールドが唯一の存在です。ポート番号は、Pが設定されている場合にのみ存在しています。フラグPとSを同時に設定してはいけません。応答コードとクラスのプロトコルエラー '（3）のエラー応答「無効フラグ・フィールドの組み合わせ」それらが両方とも設定されている場合（0x09の）生成されなければなりません。 PまたはSのいずれかが設定されている場合、私は同様に設定しなければならなくて、プロトコルフィールドは、特定のプロトコルを実行する必要があります。 S又はPが設定されている場合（3）応答コード「無効フラグ・フィールドの組み合わせ」（0x09の）を有するクラスのプロトコルエラー」のエラー応答が生成されなければならないが、私は設定されません。
The fields MUST be interpreted according to these rules:
フィールドは、これらの規則に従って解釈されなければなりません。
o (data) sender prefix: This parameter indicates the prefix length of the 'data sender's IP address' in bits. For instance, a full IPv4 address requires 'sender prefix' to be set to 32. A value of 0 indicates an IP address wildcard.
O（データ）送信元の接頭辞：このパラメータは、ビット単位でのデータの送信者のIPアドレス "のプレフィックス長を示します。例えば、完全なIPv4アドレスが0の値は、IPアドレスワイルドカードを表す32に設定する「送信者プレフィックス」を必要とします。
o protocol: The IP protocol field. This field MUST be interpreted if I=1; otherwise, it MUST be set to 0 and MUST be ignored.
Oプロトコル：IPプロトコルフィールド。 I = 1の場合、このフィールドは解釈されなければなりません。それ以外の場合は、0に設定しなければならなくて、無視しなければなりません。
o DR port number: The port number at the data receiver (DR), i.e., the destination port. A value of 0 indicates a port wildcard, i.e., the destination port number is not known. Any other value indicates the destination port number.
O DRポート番号：データ受信ポート番号（DR）、すなわち、宛先ポート。 0の値は、ポートワイルドカード、すなわち、宛先ポート番号が不明であることを示します。他の値は、宛先ポート番号を示します。
o DS port number: The port number at the data sender (DS), i.e., the source port. A value of 0 indicates a port wildcard, i.e., the source port number is not known. Any other value indicates the source port number.
O DSポート番号：データ送信元ポート番号（DS）、すなわち、送信元ポート。 0の値は、ポートワイルドカード、すなわち、送信元ポート番号が不明であることを示します。他の値は、送信元ポート番号を示します。
o data sender's IPv4 address: The source IP address of the data sender. This field MUST be set to zero if no IP address is provided, i.e., a complete wildcard is desired (see the dest prefix field above).
Oデータ送信側のIPv4アドレス：データ送信側の送信元IPアドレス。このフィールドにはIPアドレスが提供されていない場合、ゼロに設定されなければならない、すなわち、完全なワイルドカード（上記DESTプレフィックスフィールドを参照のこと）が望ましいです。
The 'ICMP types' object contains additional information needed to configure a NAT of firewall with rules to control ICMP traffic. The object contains a number of values of the ICMP Type field for which a filter action should be set up:
「ICMPタイプ」オブジェクトは、ICMPトラフィックを制御するルールとファイアウォールのNATを設定するために必要な追加情報が含まれています。オブジェクトは、フィルタアクションを設定する必要のあるICMPタイプフィールドの値の数が含まれています。
Type: NATFW_ICMP_TYPES (0x014)
タイプ：NATFW_ICMP_TYPES（0x014）
Length: Variable = ((Number of Types carried + 1) + 3) DIV 4
長さ：変数=（（実施種類+ 1の数）+ 3）DIV 4
Where DIV is an integer division.
DIVは整数除算です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | Type | Type | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ | Type | (Padding) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: ICMP Types Object
図30：ICMPタイプオブジェクト
The fields MUST be interpreted according to these rules:
フィールドは、これらの規則に従って解釈されなければなりません。
count: 8-bit integer specifying the number of 'Type' entries in the object.
カウント：オブジェクトの「タイプ」のエントリの数を指定する8ビット整数。
type: 8-bit field specifying an ICMP Type value to which this rule applies.
タイプ：このルールが適用されるICMPタイプの値を指定する8ビットのフィールド。
padding: Sufficient 0 bits to pad out the last word so that the total size of the object is an even multiple of words. Ignored on reception.
パディング：最後の単語アウトパッドのに十分な0ビットは、オブジェクトの合計サイズは、単語の偶数倍であるようにします。受信時には無視されます。
This section defines the content of each NATFW NSLP message type. The message types are defined in Section 4.1.
このセクションでは、各NATFW NSLPメッセージタイプのコンテンツを定義します。メッセージタイプは、セクション4.1で定義されています。
Basically, each message is constructed of an NSLP header and one or more NSLP objects. The order of objects is not defined, meaning that objects may occur in any sequence. Objects are marked either with mandatory (M) or optional (O). Where (M) implies that this particular object MUST be included within the message and where (O) implies that this particular object is OPTIONAL within the message. Objects defined in this memo always carry the flag combination AB=00 in the NSLP object header. An error RESPONSE message of class 'Protocol error' (3) with response code 'Mandatory object missing' (0x04) MUST be generated if a mandatory declared object is missing. An error RESPONSE message of class 'Protocol error' (3) with response code 'Illegal object present' (0x05) MUST be generated if an object was present that must not be used in a message of this type. An error RESPONSE message of class 'Protocol error' (3) with response code 'Duplicate object present' (0x0A) MUST be generated if an object appears more than once in a message.
基本的に、各メッセージはNSLPのヘッダと1つ以上のNSLPオブジェクトで構成されています。オブジェクトの順序は、オブジェクトは、任意の順序で起こり得ることを意味し、定義されていません。オブジェクトは（M）またはオプション（O）必須のいずれかでマークされています。ここでは（M）は、この特定のオブジェクトがメッセージ内に含まれ、ここで、（O）でなければならないことを意味し、この特定のオブジェクトがメッセージ内のオプションであることを意味します。このメモで定義されたオブジェクトは、常にNSLPオブジェクトヘッダ内のフラグ組み合わせAB = 00を運びます。必須の宣言されたオブジェクトが存在しない場合（3）応答コード「必須オブジェクトが欠落している」とクラスのプロトコルエラー」のエラー応答メッセージは、（0×04）を生成しなければなりません。クラスのエラー応答メッセージ「プロトコルエラー」（3） '本不正オブジェクトのレスポンスコードとオブジェクトがこのタイプのメッセージに使用されてはならないこと存在した場合（0×05）が生成されなければなりません。オブジェクトが一度メッセージに以上現れる場合、応答コードでクラスのプロトコルエラー '（3）のエラー応答メッセージ「存在複製オブジェクト」（0x0Aの）が生成されなければなりません。
Each section elaborates the required settings and parameters to be set by the NSLP for the NTLP, for instance, how the message routing information is set.
各セクションは、メッセージルーティング情報が設定されている方法、必要な設定やパラメータは、例えば、NTLPためNSLPによって設定されるように詳しく説明します。
The CREATE message is used to create NATFW NSLP signaling sessions and to create policy rules. Furthermore, CREATE messages are used to refresh NATFW NSLP signaling sessions and to delete them.
CREATEメッセージはNATFW NSLPシグナリングセッションを作成し、ポリシールールを作成するために使用されます。さらに、作成したメッセージはNATFW NSLPシグナリングセッションをリフレッシュするために、それらを削除するために使用されています。
The CREATE message carries these objects:
メッセージを作成、これらのオブジェクトを運びます：
o Signaling Session Lifetime object (M)
Oシグナリングセッション存続時間オブジェクト（M）
o Extended flow information object (M)
O拡張フロー情報オブジェクト（M）
o Message sequence number object (M)
Oメッセージシーケンス番号オブジェクト（M）
o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise (O)
OノンスオブジェクトPフラグはNSLPヘッダに1に設定されている場合（M）、そうでなければ（O）
o ICMP Types Object (O)
O ICMPタイプオブジェクト（O）
The message routing information in the NTLP MUST be set to DS as source IP address and DR as destination IP address. All other parameters MUST be set according to the required policy rule. CREATE messages MUST be transported by using the path-coupled MRM with the direction set to 'downstream' (outbound).
NTLPの情報をメッセージルーティングは、宛先IPアドレスと送信元IPアドレス及びDRとしてDSに設定しなければなりません。他のすべてのパラメータは、必要なポリシールールに応じて設定しなければなりません。 CREATEメッセージは、「下流」（アウトバウンド）に設定さ方向と経路結合MRMを使用して輸送しなければなりません。
The EXTERNAL message is used to a) reserve an external IP address/ port at NATs, b) to notify firewalls about NSIS capable DRs, or c) to block incoming data traffic at inbound firewalls.
外部メッセージをするために使用される）b）のNSISできるのDRについてファイアウォールを通知するために、または、c）インバウンドファイアウォールで着信データトラフィックをブロックするために、NATので外部IPアドレス/ポートを予約します。
The EXTERNAL message carries these objects:
外部メッセージは、これらのオブジェクトを運びます：
o Signaling Session Lifetime object (M)
Oシグナリングセッション存続時間オブジェクト（M）
o Message sequence number object (M)
Oメッセージシーケンス番号オブジェクト（M）
o Extended flow information object (M)
O拡張フロー情報オブジェクト（M）
o Data terminal information object (M)
Oデータ端末情報オブジェクト（M）
o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise (O)
OノンスオブジェクトPフラグはNSLPヘッダに1に設定されている場合（M）、そうでなければ（O）
o ICMP Types Object (O)
O ICMPタイプオブジェクト（O）
o External binding address object (O)
O外部アドレスバインディングオブジェクト（O）
The selected message routing method of the EXTERNAL message depends on a number of considerations. Section 3.7.2 describes exhaustively how to select the correct method. EXTERNAL messages can be transported via the path-coupled message routing method (PC-MRM) or via the loose-end message routing method (LE-MRM). In the case of PC-MRM, the source-address is set to the DS's address and the destination-address is set to the DR's address, the direction is set to inbound. In the case of LE-MRM, the destination-address is set to the DR's address or to the signaling destination IP address. The source-address is set to the DS's address.
外部メッセージの選択されたメッセージルーティング方法が検討事項の数に依存します。セクション3.7.2には、正しい方法を選択する方法を徹底的に説明しています。外部メッセージは、パス結合メッセージルーティング方法（PC-MRM）を介して、または緩いエンドメッセージルーティング方法（LE-MRM）を介して搬送することができます。 PC-MRMの場合には、送信元アドレスをDSのアドレスに設定され、宛先アドレスがDRのアドレスに設定され、方向は、インバウンドに設定されています。 LE-MRMの場合、宛先アドレスは、DRのアドレスまたはシグナリング宛先IPアドレスに設定されています。送信元アドレスは、DSのアドレスに設定されています。
RESPONSE messages are responses to CREATE and EXTERNAL messages. RESPONSE messages MUST NOT be generated for any other message, such as NOTIFY and RESPONSE.
応答メッセージは、作成するのに応答し、外部メッセージです。応答メッセージは、NOTIFYと応答として、他の任意のメッセージを生成してはいけません。
The RESPONSE message for the class 'Success' (2) carries these objects: o Signaling Session Lifetime object (M)
クラス「成功」の応答メッセージは、（2）これらのオブジェクト運ぶ：セッション寿命オブジェクトシグナリングOを（M）
o Message sequence number object (M)
Oメッセージシーケンス番号オブジェクト（M）
o Information code object (M)
O情報コードオブジェクト（M）
o External address object (O)
O外部アドレスオブジェクト（O）
o External binding address object (O)
O外部アドレスバインディングオブジェクト（O）
The RESPONSE message for other classes than 'Success' (2) carries these objects:
「成功」以外のクラスの応答メッセージは、（2）これらのオブジェクトを運びます。
o Message sequence number object (M)
Oメッセージシーケンス番号オブジェクト（M）
o Information code object (M)
O情報コードオブジェクト（M）
o Signaling Session Lifetime object (O)
Oシグナリングセッション存続時間オブジェクト（O）
This message is routed towards the NI hop-by-hop, using existing NTLP messaging associations. The MRM used for this message MUST be the same as MRM used by the corresponding CREATE or EXTERNAL message.
このメッセージは、既存のNTLPメッセージの関連付けを使用して、NIホップバイホップに向けてルーティングされます。このメッセージのために使用さMRMは、CREATE対応または外部メッセージによって使用されるMRMと同じでなければなりません。
The NOTIFY messages is used to report asynchronous events happening along the signaled path to other NATFW NSLP nodes.
NOTIFYメッセージは、他のNATFW NSLPノードへのシグナリング経路に沿って起こって非同期イベントを報告するために使用されます。
The NOTIFY message carries this object:
NOTIFYメッセージは、このオブジェクトを運びます。
o Information code object (M)
O情報コードオブジェクト（M）
The NOTIFY message is routed towards the next NF, NI, or NR hop-by-hop using the existing inbound or outbound node messaging association entry within the node's Message Routing State table. The MRM used for this message MUST be the same as MRM used by the corresponding CREATE or EXTERNAL message.
NOTIFYメッセージは、ノードのメッセージルーティングステートテーブル内の既存の着信または発信ノードのメッセージ関連のエントリを使用して次NF、NI、又はNRホップバイホップに向けてルーティングされます。このメッセージのために使用さMRMは、CREATE対応または外部メッセージによって使用されるMRMと同じでなければなりません。
Security is of major concern particularly in the case of firewall traversal. This section provides security considerations for the NAT/firewall traversal and is organized as follows.
セキュリティは、特にファイアウォールトラバーサルの場合の主要な懸念です。このセクションでは、NAT /ファイアウォール越えのためのセキュリティの考慮事項を提供し、次のように構成されています。
In Section 5.1, we describe how the participating entities relate to each other from a security point of view. That subsection also motivates a particular authorization model.
5.1節では、我々は、参加エンティティは、セキュリティの観点から、互いにどのように関係するかを説明します。そのサブセクションは、特定の許可モデルを動機付けます。
Security threats that focus on NSIS in general are described in [RFC4081] and they are applicable to this document as well.
一般的にはNSISに焦点を当て、セキュリティ上の脅威は[RFC4081]に記載されており、彼らは同様に、この文書に適用されます。
Finally, we illustrate how the security requirements that were created based on the security threats can be fulfilled by specific security mechanisms. These aspects will be elaborated in Section 5.2.
最後に、我々は、セキュリティ上の脅威に基づいて作成されたセキュリティ要件は、特定のセキュリティメカニズムによって満たすことができる方法を示しています。これらの側面は、5.2節で詳述します。
The NATFW NSLP is a protocol that may involve a number of NSIS nodes and is, as such, not a two-party protocol. Figures 1 and 2 of [RFC4081] already depict the possible set of communication patterns. In this section, we will re-evaluate these communication patterns with respect to the NATFW NSLP protocol interaction.
NATFW NSLPはNSISノードの数を含むとされ、例えば、ない二者のプロトコルとしてもよいプロトコルです。 [RFC4081]の図1及び2は、既に通信パターンの可能なセットを示しています。このセクションでは、我々はNATFW NSLPプロトコルの相互作用に関して、これらの通信パターンを再評価します。
The security solutions for providing authorization have a direct impact on the treatment of different NSLPs. As it can be seen from the QoS NSLP [RFC5974] and the corresponding Diameter QoS work [RFC5866], accounting and charging seems to play an important role for QoS reservations, whereas monetary aspects might only indirectly effect authorization decisions for NAT and firewall signaling. Hence, there are differences in the semantics of authorization handling between QoS and NATFW signaling. A NATFW-aware node will most likely want to authorize the entity (e.g., user or machine) requesting the establishment of pinholes or NAT bindings. The outcome of the authorization decision is either allowed or disallowed, whereas a QoS authorization decision might indicate that a different set of QoS parameters is authorized (see [RFC5866] as an example).
認可を提供するためのセキュリティソリューションは、異なるNSLPsの治療に直接影響を与えます。それは、QoS NSLP [RFC5974]から見ることができ、対応する直径QoSは、[RFC5866]を仕事として金銭的な側面は、NATやファイアウォールのシグナリングのための間接的にしか効果認可決定かもしれないのに対し、会計、充電は、QoS予約のために重要な役割を果たしているようです。したがって、QoSおよびNATFWシグナリングの間の取り扱いの許可の意味に違いがあります。 NATFW認識ノードは、最も可能性の高いピンホールやNATバインディングの確立を要求するエンティティ（例えば、ユーザまたはマシン）を承認することになるでしょう。認可判定の結果が許可又は禁止されるか、QoSの許可決定が（例として、[RFC5866]を参照）QoSパラメータの異なるセットが許可されていることを示している可能性があり、一方。
Starting with the simplest scenario, it is assumed that neighboring nodes are able to authenticate each other and to establish keying material to protect the signaling message communication. The nodes will have to authorize each other, additionally to the authentication. We use the term 'Security Context' as a placeholder for referring to the entire security procedure, the necessary infrastructure that needs to be in place in order for this to work (e.g., key management) and the established security-related state. The required long-term keys (symmetric or asymmetric keys) used for authentication either are made available using an out-of-band mechanism between the two NSIS NATFW nodes or are dynamically established using mechanisms not further specified in this document. Note that the deployment environment will most likely have an impact on the choice of credentials being used. The choice of these credentials used is also outside the scope of this document.
最も単純なシナリオで始まる、隣接ノードが互いを認証し、シグナリングメッセージの通信を保護するための材料を合わせる確立することができることが想定されます。ノードは、さらに、認証のために、お互いを認証する必要があります。私たちは、全体のセキュリティの手順、動作するように、このためには所定の位置にする必要があります必要なインフラ（例えば、鍵管理）と、確立されたセキュリティ関連の状態を参照するためのプレースホルダとして用語「セキュリティコンテキスト」を使用します。認証のいずれかのために使用される必要な長期鍵（対称または非対称鍵）は、二つのNSIS NATFWノード間の帯域外メカニズムを使用して利用可能にされるか、または動的にさらに本書で指定されていないメカニズムを使用して確立されます。デプロイメント環境が最も可能性の高い使用されている資格情報の選択に影響を与えることに注意してください。使用されるこれらの資格情報の選択は、この文書の範囲外でもあります。
+------------------------+ +-------------------------+
|Network A | | Network B|
| +---------+ +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | Security | box 2 | | |
| | +---------+ Context +---------+ | |
| | Security | | Security | |
| | Context | | Context | |
| | | | | |
| +--+---+ | | +--+---+ |
| | Host | | | | Host | |
| | A | | | | B | |
| +------+ | | +------+ |
+------------------------+ +-------------------------+
Figure 31: Peer-to-Peer Relationship
図31：ピア・ツー・ピア関係
Figure 31 shows a possible relationship between participating NSIS-aware nodes. Host A might be, for example, a host in an enterprise network that has keying material established (e.g., a shared secret) with the company's firewall (Middlebox 1). The network administrator of Network A (company network) has created access control lists for Host A (or whatever identifiers a particular company wants to use). Exactly the same procedure might also be used between Host B and Middlebox 2 in Network B. For the communication between Middlebox 1 and Middlebox 2 a security context is also assumed in order to allow authentication, authorization, and signaling message protection to be successful.
図31は、参加NSIS対応ノードの間の可能な関係を示しています。ホストであるかもしれない、例えば、企業のファイアウォール（ミドル1）と（例えば、共有秘密）を設立材料をキーイングしている企業ネットワーク内のホスト。ネットワークA（企業ネットワーク）のネットワーク管理者は、ホストAのためのアクセス制御リストを作成した（または特定の会社が使用したいものは何でも識別子）。全く同じ手順では、セキュリティコンテキストは、認証、認可、およびシグナリングメッセージ保護を成功させることを可能にするために想定されるミドル1、ミドル2との間の通信のためのネットワークB内のホストBとミドル2との間で使用されるかもしれません。
In larger corporations, for example, a middlebox is used to protect individual departments. In many cases, the entire enterprise is controlled by a single (or a small number of) security department(s), which give instructions to the department administrators. In such a scenario, the previously discussed peer-to-peer relationship might be prevalent. Sometimes it might be necessary to preserve authentication and authorization information within the network. As a possible solution, a centralized approach could be used, whereby an interaction between the individual middleboxes and a central entity (for example, a policy decision point - PDP) takes place. As an alternative, individual middleboxes exchange the authorization decision with another middlebox within the same trust domain. Individual middleboxes within an administrative domain may exploit their relationship instead of requesting authentication and authorization of the signaling initiator again and again. Figure 32 illustrates a network structure that uses a centralized entity.
大企業では、例えば、ミドルは、個々の部門を保護するために使用されます。多くの場合、企業全体の部門管理者に指示を与えており、単一の（または少数の）セキュリティ部門（複数可）によって制御されます。そのようなシナリオでは、先に論じたピア・ツー・ピア関係が優勢であるかもしれません。時にはネットワーク内での認証と承認情報を保存する必要がある場合があります。行わ - 個々の中間装置及び中央エンティティ（PDP例えば、ポリシー決定ポイント）との間の相互作用が可能となる解決策として、集中型のアプローチが、使用され得ます。別の方法として、個々のミドルボックスは、同じ信頼ドメイン内の別のミドルでの承認決定を交換します。管理ドメイン内の個々のミドルボックスではなく、何度も何度もシグナリングイニシエータの認証と承認を要求する彼らの関係を利用することができます。図32は、集中型のエンティティを使用するネットワーク構造を示す図です。
+-----------------------------------------------------------+
| Network A |
| +---------+ +---------+
| +----///--------+ Middle- +------///------++ Middle- +---
| | Security | box 2 | Security | box 2 |
| | Context +----+----+ Context +----+----+
| +----+----+ | | |
| | Middle- +--------+ +---------+ | |
| | box 1 | | | | |
| +----+----+ | | | |
| | Security | +----+-----+ | |
| | Context | | Policy | | |
| +--+---+ +-----------+ Decision +----------+ |
| | Host | | Point | |
| | A | +----------+ |
| +------+ |
+-----------------------------------------------------------+
Figure 32: Intra-Domain Relationship
図32：ドメイン内の関係
The interaction between individual middleboxes and a policy decision point (or AAA server) is outside the scope of this document.
個々の中間装置とポリシー決定ポイント（またはAAAサーバ）との間の相互作用は、この文書の範囲外です。
The peer-to-peer relationship between neighboring NSIS NATFW NSLP nodes might not always be sufficient. Network B might require additional authorization of the signaling message initiator (in addition to the authorization of the neighboring node). If authentication and authorization information is not attached to the initial signaling message then the signaling message arriving at Middlebox 2 would result in an error message being created, which indicates the additional authorization requirement. In many cases, the signaling message initiator might already be aware of the additionally required authorization before the signaling message exchange is executed.
近隣NSIS NATFW NSLPノード間のピア・ツー・ピア関係は必ずしも十分ではないかもしれません。ネットワークBは、（隣接ノードの権限に加えて）シグナリングメッセージのイニシエータの追加の許可を必要とするかもしれません。認証および認可情報を初期シグナリングメッセージに添付されていない場合、ミドル2に到着するシグナリングメッセージは、追加の許可要件を示して作成されるエラーメッセージをもたらします。シグナリングメッセージ交換が実行される前に、多くのケースでは、シグナリングメッセージのイニシエータは、すでに別途必要な権限を知っている可能性があります。
Figure 33 shows this scenario.
図33は、このシナリオを示しています。
+--------------------+ +---------------------+
| Network A | |Network B |
| | Security | |
| +---------+ Context +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | +-------+ box 2 | | |
| | +---------+ | +---------+ | |
| |Security | | | Security | |
| |Context | | | Context |
| | | | | | |
| +--+---+ | | | +--+---+ |
| | Host +----///----+------+ | | Host | |
| | A | | Security | | B | |
| +------+ | Context | +------+ |
+--------------------+ +---------------------+
Figure 33: End-to-Middle Relationship
図33：エンドツー中東の関係
The following list of security requirements has been created to ensure proper secure operation of the NATFW NSLP.
セキュリティ要件の以下のリストはNATFW NSLPの適切な安全な動作を確保するために作成されています。
Based on the analyzed threats, it is RECOMMENDED to provide, between neighboring NATFW NSLP nodes, the following mechanisms:
分析脅威に基づいて、隣接NATFW NSLPノード間で、以下のメカニズムを提供することをお勧めします。
o data origin authentication,
Oデータ発信元認証、
o replay protection,
O再生保護、
o integrity protection, and,
O整合性の保護、および、
o optionally, confidentiality protection
Oオプションで、機密性保護
It is RECOMMENDED to use the authentication and key exchange security mechanisms provided in [RFC5971] between neighboring nodes when sending NATFW signaling messages. The proposed security mechanisms of GIST provide support for authentication and key exchange in addition to denial-of-service protection. Depending on the chosen security protocol, support for multiple authentication protocols might be provided. If security between neighboring nodes is desired, then the usage of C-MODE with a secure transport protocol for the delivery of most NSIS messages with the usage of D-MODE only to discover the next NATFW NSLP-aware node along the path is highly RECOMMENDED. See [RFC5971] for the definitions of C-MODE and D-MODE. Almost all security threats at the NATFW NSLP-layer can be prevented by using a mutually authenticated Transport Layer secured connection and by relying on authorization by the neighboring NATFW NSLP entities.
NATFWシグナリングメッセージを送信するとき、隣接ノード間で[RFC5971]に提供された認証及び鍵交換セキュリティ・メカニズムを使用することが推奨されます。 GISTの提案セキュリティメカニズムは、認証およびサービス拒否の保護に加えて、鍵交換のためのサポートを提供しています。選択したセキュリティプロトコルに応じて、複数の認証プロトコルのサポートが提供される可能性があります。隣接ノード間のセキュリティが望まれる場合には、D-MODEの用途に最もNSISメッセージの送達のためのセキュアな転送プロトコルとCモードの使用は、強く推奨されるパスに沿って次NATFW NSLP対応ノードを発見します。 CモードとDモードの定義については、[RFC5971]を参照。 NATFW NSLP層でほとんどすべてのセキュリティ上の脅威は、相互認証トランスポート層セキュリティで保護された接続を使用することにより、隣接NATFW NSLPエンティティによって承認に依存することによって防ぐことができます。
The NATFW NSLP relies on an established security association between neighboring peers to prevent unauthorized nodes from modifying or deleting installed state. Between non-neighboring nodes the session ID (SID) carried in the NTLP is used to show ownership of a NATFW NSLP signaling session. The session ID MUST be generated in a random way and thereby prevents an off-path adversary from mounting targeted attacks. Hence, an adversary would have to learn the randomly generated session ID to perform an attack. In a mobility environment a former on-path node that is now off-path can perform an attack. Messages for a particular NATFW NSLP signaling session are handled by the NTLP to the NATFW NSLP for further processing. Messages carrying a different session ID not associated with any NATFW NSLP are subject to the regular processing for new NATFW NSLP signaling sessions.
NATFW NSLPは、インストールされた状態を変更または削除する権限のないノードを防止するために、隣接ピア間で確立されたセキュリティアソシエーションに依存しています。非隣接はNTLPで運ばれるセッションID（SID）をノード間NATFW NSLPシグナリングセッションの所有権を示すために使用されます。セッションIDは、ランダムに生成され、それによって標的の攻撃を実装からオフパス攻撃を防止しなければなりません。したがって、敵が攻撃を実行するために、ランダムに生成されたセッションIDを学ばなければならないでしょう。モビリティ環境では、オフパス今で元のパスのノードが攻撃を実行することができます。特定NATFW NSLPシグナリングセッションのためのメッセージは、さらなる処理のためNATFW NSLPにNTLPによって処理されます。任意NATFW NSLPに関連付けられていない異なるセッションIDを運ぶメッセージは、新しいNATFW NSLPシグナリングセッションのための通常処理の対象となっています。
Based on the security threats and the listed requirements, it was noted that some threats also demand authentication and authorization of a NATFW signaling entity (including the initiator) towards a non-neighboring node. This mechanism mainly demands entity authentication. The most important information exchanged at the NATFW NSLP is information related to the establishment for firewall pinholes and NAT bindings. This information can, however, not be protected over multiple NSIS NATFW NSLP hops since this information might change depending on the capability of each individual NATFW NSLP node.
セキュリティの脅威と記載されている要件に基づいて、それはいくつかの脅威はまた、非隣接ノードに向けて（開始剤を含む）NATFWシグナリングエンティティの認証と承認を要求することが認められました。このメカニズムは、主に、エンティティ認証を要求します。 NATFW NSLPで交換最も重要な情報は、ファイアウォールピンホールやNATバインディングの確立に関連した情報です。この情報は、しかし、この情報は、個々のNATFW NSLPノードの能力に応じて変更される場合がありますので、複数のNSIS NATFW NSLPホップオーバー保護することはできません。
Some scenarios might also benefit from the usage of authorization tokens. Their purpose is to associate two different signaling protocols (e.g., SIP and NSIS) and their authorization decision. These tokens are obtained by non-NSIS protocols, such as SIP or as part of network access authentication. When a NAT or firewall along the path receives the token it might be verified locally or passed to the AAA infrastructure. Examples of authorization tokens can be found in RFC 3520 [RFC3520] and RFC 3521 [RFC3521]. Figure 34 shows an example of this protocol interaction.
いくつかのシナリオは、許可トークンの利用の恩恵を受ける可能性があります。彼らの目的は、二つの異なるシグナリングプロトコル（例えば、SIPおよびNSIS）とそれらの認可判断を関連付けることです。これらのトークンは、SIPとして、またはネットワークアクセス認証の一部として、非NSISプロトコルによって得られます。パスに沿ってNATやファイアウォールがトークンを受信した場合には、ローカルで検証またはAAAインフラストラクチャに渡されるかもしれません。許可トークンの例は、RFC 3520 [RFC3520]及びRFC 3521 [RFC3521]に見出すことができます。図34は、このプロトコル相互作用の一例を示しています。
An authorization token is provided by the SIP proxy, which acts as the assertion generating entity and gets delivered to the end host with proper authentication and authorization. When the NATFW signaling message is transmitted towards the network, the authorization token is attached to the signaling messages to refer to the previous authorization decision. The assertion-verifying entity needs to process the token or it might be necessary to interact with the assertion-granting entity using HTTP (or other protocols). As a result of a successfully authorization by a NATFW NSLP node, the requested action is executed and later a RESPONSE message is generated.
許可トークンは、アサーション発生エンティティとして機能し、適切な認証および許可を有するエンドホストに配信されるSIPプロキシによって提供されます。 NATFWシグナリングメッセージをネットワークに向けて送信されると、認証トークンは、前の許可決定を参照するためにシグナリングメッセージに取り付けられています。アサーション検証エンティティは、トークンを処理する必要があるか、HTTP（または他のプロトコル）を使用して、アサーション認可エンティティと対話する必要があるかもしれません。 NATFW NSLPノードによる正常承認の結果として、要求されたアクションが実行され、それ以降の応答メッセージが生成されます。
+----------------+ Trust Relationship +----------------+
| +------------+ |<.......................>| +------------+ |
| | Protocol | | | | Assertion | |
| | requesting | | HTTP, SIP Request | | Granting | |
| | authz | |------------------------>| | Entity | |
| | assertions | |<------------------------| +------------+ |
| +------------+ | Artifact/Assertion | Entity Cecil |
| ^ | +----------------+
| | | ^ ^|
| | | . || HTTP,
| | | Trust . || other
| API Access | Relationship. || protocols
| | | . ||
| | | . ||
| | | v |v
| v | +----------------+
| +------------+ | | +------------+ |
| | Protocol | | NSIS NATFW CREATE + | | Assertion | |
| | using authz| | Assertion/Artifact | | Verifying | |
| | assertion | | ----------------------- | | Entity | |
| +------------+ | | +------------+ |
| Entity Alice | <---------------------- | Entity Bob |
+----------------+ RESPONSE +----------------+
Figure 34: Authorization Token Usage
図34：許可トークンの使用
Threats against the usage of authorization tokens have been mentioned in [RFC4081]. Hence, it is required to provide confidentiality protection to avoid allowing an eavesdropper to learn the token and to use it in another NATFW NSLP signaling session (replay attack). The token itself also needs to be protected against tempering.
認証トークンの利用に対する脅威は[RFC4081]で言及されています。したがって、トークンを学ぶために、別のNATFW NSLPシグナリング・セッション（リプレイ攻撃）でそれを使用するために盗聴を可能避けるために、機密保護を提供するために必要とされます。トークン自体も焼戻しから保護する必要があります。
The prior sections describe how to secure the NATFW NSLP in the presence of established trust between the various players and the particular relationships (e.g., intra-domain, end-to-middle, or peer-to-peer). However, in typical Internet deployments there is no established trust, other than granting access to a network, but not between various sites in the Internet. Furthermore, the NATFW NSLP may be incrementally deployed with a widely varying ability to be able to use authentication and authorization services.
前のセクションでは、様々なプレーヤーとの特定の関係の間に確立された信頼関係（例えば、イントラドメイン、エンド・ツー・ミドル、またはピア・ツー・ピア）の存在下でNATFW NSLPを確保する方法について説明します。しかし、一般的なインターネットの展開にネットワークへのアクセスを許可する以外にはなく、インターネット上のさまざまなサイトの間に確立された信頼は、ありません。さらに、NATFW NSLPは漸進認証および承認サービスを使用することができるように大きく変化する能力を展開させることができます。
The NATFW NSLP offers a way to keep the authentication and authorization at the "edge" of the network. The local edge network can deploy and use any type of Authentication and Authorization (AA) scheme without the need to have AA technology match with other edges in the Internet (assuming that firewalls and NATs are deployed at the edges of the network and not somewhere in the cores).
NATFW NSLPは、ネットワークの「エッジ」での認証と承認を維持する方法を提供しています。局所エッジネットワークは、インターネットで他のエッジとのAA技術一致を有する必要なしに認証および許可（AA）方式の任意のタイプを展開して使用することができる（ファイアウォールおよびNATのは、ネットワークのエッジで配備されていないどこかにあることを仮定コア）。
Each network edge that has the NATFW NSLP deployed can use the EXTERNAL request message to allow a secure access to the network. Using the EXTERNAL request message does allow the DR to open the firewall/NAT on the receiver's side. However, the edge-devices should not allow the firewall/NAT to be opened up completely (i.e., should not apply an allow-all policy), but should let DRs reserve very specific policies. For instance, a DR can request reservation of an 'allow' policy rule for an incoming TCP connection for a Jabber file transfer. This reserved policy (see Figure 15) rule must be activated by matching the CREATE request message (see Figure 15). This mechanism allows for the authentication and authorization issues to be managed locally at the particular edge-network. In the reverse direction, the CREATE request message can be handled independently on the DS side with respect to authentication and authorization.
NATFW NSLPが展開している各ネットワークエッジは、ネットワークへの安全なアクセスを可能にするために、外部要求メッセージを使用することができます。外部要求メッセージを使用すると、DRは、受信者側でファイアウォール/ NATを開くことができません。しかし、エッジ・デバイス（すなわち、許可-すべてのポリシーを適用するべきではありません）、ファイアウォール/ NATが完全に開くことができるようにするべきではありませんが、のDRの準備に非常に具体的な政策をさせてください。例えば、DRは、Jabberのファイル転送のための着信TCP接続のためのポリシールールを「許可」の予約を要求することができます。この予約ポリシー（図15参照）ルール作成要求メッセージを照合することによって活性化されなければならない（図15参照）。このメカニズムは、特定のエッジ・ネットワークでローカルに管理される認証および承認の問題が可能になります。逆方向では、CREATE要求メッセージは、認証および認可に対してDS側に独立に扱うことができます。
The usage described in the above paragraph is further simplified for an incremental deployment: there is no requirement to activate a reserved policy rule with a CREATE request message. This is completely handled by the EXTERNAL-PROXY request message and the associated CREATE request message. Both of them are handled by the local authentication and authorization scheme.
上の段落で説明した使用は、増分展開のためにさらに簡略化される：生成要求メッセージを予約ポリシールールを有効にする必要はありません。これは、完全に外部PROXY要求メッセージによって処理され、関連する要求メッセージを作成します。それらの両方がローカル認証および許可方式によって処理されます。
UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a process at originating endpoints that attempts to determine or fix the address (and port) by which they are known to another endpoint. UNSAF proposals, such as STUN [RFC5389] are considered as a general class of workarounds for NAT traversal and as solutions for scenarios with no middlebox communication.
片側自アドレス固定（UNSAF）はアドレス（およびポート）を決定または修正することを試みる発信エンドポイントの処理として、[RFC3424]に記載され、それらは別のエンドポイントに知られているれます。そのようなSTUN [RFC5389]としてUNSAF提案は、NATトラバーサルのための回避策の一般的なクラスとして、ノーミドル通信にシナリオのためのソリューションとして考えられています。
This memo specifies a path-coupled middlebox communication protocol, i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are not intended as a short-term workaround, but more as a long-term solution for middlebox communication. In NSIS, endpoints are involved in allocating, maintaining, and deleting addresses and ports at the middlebox. However, the full control of addresses and ports at the middlebox is at the NATFW NSLP daemon located at the respective NAT.
このメモは、パス結合ミドル通信プロトコル、すなわち、NSIS NATFW NSLPを指定します。一般にNSISとNATFW NSLPは、短期的な回避策として意図され、より多くのミドル通信のための長期的なソリューションとしてれていません。 NSISでは、エンドポイントは、割り当て維持、及びミドルにアドレスとポートを削除するに関与しています。しかし、ミドルでのアドレスとポートの完全な制御は、それぞれのNATに位置NATFW NSLPデーモンです。
Therefore, this document addresses the UNSAF considerations in [RFC3424] by proposing a long-term alternative solution.
したがって、この文書は、長期的な代替ソリューションを提案することにより、[RFC3424]でUNSAF考慮事項に対処しています。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the NATFW NSLP, in accordance with BCP 26, RFC 5226 [RFC5226].
このセクションでは、BCP 26、RFC 5226 [RFC5226]に従って、NATFW NSLPに関連する値の登録に関してインターネット割り当て番号機関（IANA）へのガイダンスを提供します。
The NATFW NSLP requires IANA to create a number of new registries:
NATFW NSLPは、新しいレジストリの数を作成するために、IANAが必要です。
o NATFW NSLP Message Types
NATFW NSLPメッセージタイプO
o NATFW NSLP Header Flags
O NATFW NSLPヘッダーのフラグ
o NSLP Response Codes
O NSLP応答コード
It also requires registration of new values in a number of registries:
また、レジストリの数の新しい値の登録が必要です。
o NSLP Message Objects
NSLPメッセージオブジェクトO
o NSLP Identifiers (under GIST Parameters)
O NSLP識別子（GISTパラメータの下で）
o Router Alert Option Values (IPv4 and IPv6)
Oルータアラートオプション値（IPv4およびIPv6）
The NATFW NSLP Message Type is an 8-bit value. The allocation of values for new message types requires IETF Review. Updates and deletion of values from the registry are not possible. This specification defines four NATFW NSLP message types, which form the initial contents of this registry. IANA has added these four NATFW NSLP Message Types: CREATE (0x1), EXTERNAL (0x2), RESPONSE (0x3), and NOTIFY (0x4). 0x0 is Reserved. Each registry entry consists of value, description, and reference.
NATFW NSLPメッセージタイプは、8ビットの値です。新しいメッセージタイプの値の割り当てはIETFレビューが必要です。レジストリからの値の更新と削除はできません。この仕様は、このレジストリの初期内容を形成する4つのNATFW NSLPメッセージタイプを定義します。 IANAは、これらの4つのNATFW NSLPメッセージタイプを追加しました：（0x1の）、EXTERNAL（0x2の）、応答（0x3の）を作成し、（0x4の）NOTIFY。 0x0のが予約されています。各レジストリエントリの値、説明、および基準から成ります。
NATFW NSLP messages have a message-specific 8-bit flags/reserved field in their header. The registration of flags is subject to IANA registration. The allocation of values for flag types requires IETF Review. Updates and deletion of values from the registry are not possible. This specification defines only two flags in Section 4.1, the P flag (bit 8) and the E flag (bit 9). Each registry entry consists of value, bit position, description (containing the section number), and reference.
NATFW NSLPメッセージは、そのヘッダ内のメッセージ固有の8ビット・フラグ/予約済みフィールドを有しています。フラグの登録はIANA登録の対象となります。フラグの種類の値の割り当てはIETFレビューが必要です。レジストリからの値の更新と削除はできません。この仕様は、4.1節に2つだけのフラグを定義し、Pフラグ（ビット8）およびEフラグ（ビット9）。各レジストリエントリの値、ビット位置、記述（セクション番号を含む）、及び基準から成ります。
In Section 4.2 this document defines 9 objects for the NATFW NSLP: NATFW_LT, NATFW_EXTERNAL_IP, NATFW_EXTERNAL_BINDING, NATFW_EFI, NATFW_INFO, NATFW_NONCE, NATFW_MSN, NATFW_DTINFO, NATFW_ICMP_TYPES. IANA has assigned values for them from the NSLP Message Objects registry.
NATFW_LT、NATFW_EXTERNAL_IP、NATFW_EXTERNAL_BINDING、NATFW_EFI、NATFW_INFO、NATFW_NONCE、NATFW_MSN、NATFW_DTINFO、NATFW_ICMP_TYPES：第4.2節では、この文書はNATFW NSLP 9つのオブジェクトを定義します。 IANAはNSLPメッセージオブジェクトレジストリからそれらの値を割り当てました。
In addition, this document defines a number of Response Codes for the NATFW NSLP. These can be found in Section 4.2.5 and have been assigned values from the NSLP Response Code registry. The allocation of new values for Response Codes requires IETF Review. IANA has assigned values for them as given in Section 4.2.5 for the error class and also for the number of responses values per error class. Each registry entry consists of response code, value, description, and reference.
また、この文書はNATFW NSLPのための応答コードの数を定義します。これらは、4.2.5項で見つけることができるとNSLP応答コードレジストリから値を割り当てられています。応答コードのための新しい値の割り当てはIETFレビューが必要です。エラークラスごとの応答値の数についても、エラーのクラスについては、セクション4.2.5で与えられているIANAは、それらの値を割り当てました。各レジストリエントリは、応答コード、値、説明、および基準から成ります。
GIST NSLPID
GIST NSLPID
This specification defines an NSLP for use with GIST and thus requires an assigned NSLP identifier. IANA has added one new value (33) to the NSLP Identifiers (NSLPID) registry defined in [RFC5971] for the NATFW NSLP.
この仕様は、GISTで使用するためのNSLPを定義し、したがって、割り当てられたNSLP識別子を必要とします。 IANAはNATFW NSLPのために[RFC5971]で定義されたNSLP識別子（NSLPID）レジストリに一つの新たな値（33）を加えました。
IPv4 and IPv6 Router Alert Option (RAO) value
IPv4とIPv6ルータ警告オプション（RAO）値
The GIST specification also requires that each NSLP-ID be associated with specific Router Alert Option (RAO) value. For the purposes of the NATFW NSLP, a single IPv4 RAO value (65) and a single IPv6 RAO value (68) have been allocated.
GISTの仕様は、各NSLP-IDは、特定のルータ警告オプション（RAO）値に関連付けられることを要求します。 NATFW NSLP、単一のIPv4 RAO値（65）と、単一のIPv6 RAO値（68）の目的のために割り当てられています。
We would like to thank the following individuals for their contributions to this document at different stages:
私たちは、さまざまな段階で、この文書への貢献のために以下の個人に感謝したいと思います：
o Marcus Brunner and Henning Schulzrinne for their work on IETF documents that led us to start with this document;
マーカス・ブルナーと、この文書を開始するために私たちを導いたIETF文書上の自分の仕事のためのヘニングSchulzrinneとO;
o Miquel Martin for his large contribution on the initial version of this document and one of the first prototype implementations;
Oこの文書と最初のプロトタイプの実装の1つの初期のバージョンで彼の大きな貢献のためのミケル・マーティン。
o Srinath Thiruvengadam and Ali Fessi work for their work on the NAT/firewall threats document;
O Srinath ThiruvengadamとアリFessi NAT /ファイアウォールの脅威の文書上の自分の仕事のための仕事。
o Henning Peters for his comments and suggestions;
彼のコメントや提案のためのヘニング・ピーターズO;
o Ben Campbell as Gen-ART reviewer;
Oベン・キャンベルは、ジェン・ARTのREVIの水差しです。
o and the NSIS working group.
OとNSISワーキンググループ。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971] Schulzrinneと、H.とR.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、RFC 5971、2010年10月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982]エルツ、R.とR.ブッシュ大統領、 "シリアル番号演算"、RFC 1982、1996年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC4080]ハンコック、R.、Karagiannis、G.、Loughney、J.、およびS.ヴァンデンボッシュ、 "シグナル伝達における次のステップ（NSIS）：フレームワーク"、RFC 4080、2005年6月。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726]ブルナー、M.、 "シグナリングプロトコルのための要件"、RFC 3726、2004年4月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]マナー、J.、Karagiannis、G.、およびA.マクドナルド、 "NSISシグナリング層プロトコルクオリティ・オブ・サービスシグナリングのための（NSLP）"、RFC 5974、2010年10月。
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010.
[RFC5866]日、D.、マッキャン、P.、Tschofenig、H.、ツオウ、T.、ドリア、A.、およびG.ツォルン、 "直径サービス品質の応用"、RFC 5866、2010年5月。
[RFC5978] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
[RFC5978]マナー、J.、ブレス、R.、Loughney、J.、およびE.デイヴィス、RFC 5978 "NSISプロトコルファミリを使用すると拡張" 2010年10月。
[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.、ローゼンバーグ、J.、モリター、A.、およびA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、RFC 3303、2002年8月。
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081] Tschofenig、H.およびD. Kroeselberg、 "シグナリングにおける次のステップのためのセキュリティの脅威（NSIS）"、RFC 4081、2005年6月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
[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、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[RFC3198] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、クイン、B.、ヘルツォーク、S.、フイン、A.、カールソン、M.、ペリー、J.、およびS 。Waldbusser、 "ポリシーベースの管理のための用語"、RFC 3198、2001年11月。
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[RFC3520]ハマー、L-N。、ゲージ、B.、コジンスキー、B.、およびH. Shieh、 "セッション認可ポリシーの要素"、RFC 3520、2003年4月。
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003.
[RFC3521]ハマー、L-N。、RFC 3521、2003年4月、ゲージ、B.、およびH. Shieh、 "メディア認証とセッションのセットアップのためのフレームワーク"。
[rsvp-firewall] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as firewall Signalling Protocol", Proceedings of the 6th IEEE Symposium on Computers and Communications, Hammamet, Tunisia, pp. 57 to 62, IEEE Computer Society Press, July 2001.
[RSVP-ファイアウォール] Roedig、U.、Goertz、M.、Karten、M.、およびR.シュタインメッツ、 "ファイアウォールのシグナリングプロトコルとしてRSVP"、第6回IEEEコンピュータシンポジウム通信、ハマメット、PPの議事録。 62から57、IEEEコンピュータ学会出版、2001年7月。
Appendix A. Selecting Signaling Destination Addresses for EXTERNAL
EXTERNALのための宛先アドレスをシグナリング付録A.選択
As with all other message types, EXTERNAL messages need a reachable IP address of the data sender on the GIST level. For the path-coupled MRM, the source-address of GIST is the reachable IP address (i.e., the real IP address of the data sender, or a wildcard). While this is straightforward, it is not necessarily so for the loose-end MRM. Many applications do not provide the IP address of the communication counterpart, i.e., either the data sender or both a data sender and receiver. For the EXTERNAL messages, the case of data sender is of interest only. The rest of this section gives informational guidance about determining a good destination-address of the LE-MRM in GIST for EXTERNAL messages.
他のすべてのメッセージタイプと同じように、外部メッセージは、GISTレベルでのデータ送信側の到達可能なIPアドレスが必要です。パス結合MRMため、GISTのソース・アドレスが到達可能なIPアドレス（すなわち、データの送信者の実際のIPアドレス、またはワイルドカード）です。これは簡単ですが、それは必ずしもそう緩いエンドMRMのためではありません。多くのアプリケーションでは、通信相手、すなわち、データ送信側のいずれか、またはデータ送信者と受信者の両方のIPアドレスを提供しません。外部メッセージの場合は、データの送信者の場合にのみ関心があります。このセクションの残りの部分は、外部メッセージのためのGISTにおけるLE-MRMの良い宛先アドレスを決定に関する情報のガイダンスを提供します。
This signaling destination address (SDA, the destination-address in GIST) can be the data sender, but for applications that do not provide an address upfront, the destination IP address has to be chosen independently, as it is unknown at the time when the NATFW NSLP signaling has to start. Choosing the 'correct' destination IP address may be difficult and it is possible that there is no 'right answer' for all applications relying on the NATFW NSLP.
このシグナリング宛先アドレス（SDAは、GISTの宛先アドレス）は、データの送信者することができますが、それは時間では不明であるとして先行アドレスを提供しないアプリケーションのために、送信先のIPアドレスは、独立して選択しなければならないときNATFW NSLPシグナリングを開始する必要があります。 「正しい」の宛先IPアドレスを選択することは困難なこと、NATFW NSLPに依存するすべてのアプリケーションのための「正しい答えが」存在しないことも可能であることがあります。
Whenever possible, it is RECOMMENDED to chose the data sender's IP address as the SDA. It is necessary to differentiate between the received IP addresses on the data sender. Some application-level signaling protocols (e.g., SIP) have the ability to transfer multiple contact IP addresses of the data sender. For instance, private IP addresses, public IP addresses at a NAT, and public IP addresses at a relay. It is RECOMMENDED to use all non-private IP addresses as SDAs.
可能な限り、SDAとして、データ送信者のIPアドレスを選択したことをお勧めします。データ送信側で受信したIPアドレスを区別する必要があります。いくつかのアプリケーション・レベルのシグナリングプロトコル（例えば、SIP）は、データ送信側の複数のコンタクトのIPアドレスを転送する能力を有します。たとえば、プライベートIPアドレス、NATのパブリックIPアドレス、およびリレーのパブリックIPアドレス。のSDAとして、すべての非プライベートIPアドレスを使用することをお勧めします。
A different SDA must be chosen, if the IP address of the data sender is unknown. This can have multiple reasons: the application-level signaling protocol cannot determine any data sender IP address at this point in time or the data receiver is server behind a NAT, i.e., accepting inbound packets from any host. In this case, the NATFW NSLP can be instructed to use the public IP address of an application server or any other node. Choosing the SDA in this case is out of the scope of the NATFW NSLP and depends on the application's choice. The local network can provide a network-SDA, i.e., an SDA that is only meaningful to the local network. This will ensure that GIST packets with destination-address set to this network-SDA are going to be routed to an edge-NAT or edge-firewall.
データ送信元のIPアドレスが不明な場合は、別のSDAは、選択されなければなりません。これは複数の理由を持つことができる：アプリケーションレベルのシグナリングプロトコルはこの時点で任意のデータ送信元IPアドレスを決定することができない、またはデータ受信機、すなわち、任意のホストからの着信パケットを受け入れ、NATの背後のサーバです。この場合、NATFW NSLPは、アプリケーションサーバーまたは他のノードのパブリックIPアドレスを使用するように指示することができます。この場合にはSDAを選択すると、NATFW NSLPの範囲外であり、アプリケーションの選択に依存します。ローカルネットワークは、ネットワークSDA、即ち、ローカルネットワークにのみ意味がSDAを提供することができます。これは、このネットワーク-SDAに設定された宛先アドレスを持つことGISTパケットがエッジ-NATまたはエッジファイアウォールにルーティングしようとしていることを確認します。
Appendix B. Usage of External Binding Addresses
外部バインディングアドレスの付録B.使用方法
The NATFW_EXTERNAL_BINDING object carries information, which has a different utility to the information carried within the NATFW_EXTERNAL_IP object. The NATFW_EXTERNAL_IP object has the public IP address and potentially port numbers that can be used by the application at the NI to be reachable via the public Internet. However, there are cases in which various NIs are located behind the same public NAT, but are subject to a multi-level NAT deployment, as shown in Figure 35. They can use their public IP address port assigned to them to communicate between each other (e.g., NI with NR1 and NR2) but they are forced to send their traffic through the edge-NAT, even though there is a shorter way possible.
NATFW_EXTERNAL_BINDINGオブジェクトはNATFW_EXTERNAL_IPオブジェクト内に搬送される情報とは異なる有用性を有する情報を運びます。 NATFW_EXTERNAL_IPオブジェクトは、パブリックIPアドレスとパブリックインターネット経由で到達可能であることをNIのアプリケーションで使用することができ、潜在的にポート番号を持っています。しかしながら、種々のNIは、同じパブリックNATの背後に配置されている場合があるが、図35に示すように、これらは相互に通信するために割り当てられ、それらのパブリックIPアドレスポートを使用することができ、マルチレベルNAT展開の対象となっています（例えば、NR1とNR2とNI）が、それらは可能な短い方法があるにもかかわらず、エッジ-NATを介して自分のトラフィックを送信することを余儀なくされています。
NI --192.168.0/24-- NAT1--10.0.0.0/8--NAT2 Internet (public IP)
|
NR1--192.168.0/24-- NAT3--
|
NR2 10.1.2.3
Figure 35: Multi-Level NAT Scenario
図35：マルチレベルNATのシナリオ
Figure 35 shows an example that is explored here:
図35は、ここで探求した例を示しています。
1. NI -> NR1: Both NI and NR1 send EXTERNAL messages towards NAT2 and get an external address+port binding. Then, they exchange that external binding and all traffic gets pinned to NAT2 instead of taking the shortest path by NAT1 to NAT3 directly. However, to do that, NR1 and NI both need to be aware that they also have the address on the external side of NAT1 and NAT3, respectively. If ICE is deployed and there is actually a STUN server in the 10/8 network configured, it is possible to get the shorter path to work. The NATFW NSLP provides all external addresses in the NATFW_EXTERNAL_BINDING towards the public network it could allow for optimizations.
1. NI - > NR1：NIとNR1の両方がNAT2に向けて外部メッセージを送信し、外部アドレス+ポートバインディングを取得します。その後、彼らは外部結合と、すべてのトラフィックではなく、直接NAT3にNAT1で最短経路を取るのNAT2に固定されることを交換します。しかし、それを行うには、NR1とNIの両方が、彼らはまた、それぞれ、NAT1とNAT3の外部側のアドレスを持っていることを認識する必要があります。 ICEが展開し、STUNサーバが設定10/8ネットワーク内に実際に存在している場合は、動作するように短いパスを取得することが可能です。 NATFW NSLPはそれが最適化のための可能性があり、公衆網へのNATFW_EXTERNAL_BINDING内のすべての外部アドレスを提供します。
2. For the case NI -> NR2 is even more obvious. Pinning this to NAT2 is an important fallback, but allowing for trying for a direct path between NAT1 and NAT3 might be worth it.
2.ケースのためにNIは - > NR2はさらに明白です。 NAT2にこれを確保すると、重要なフォールバックですが、NAT1とNAT3間の直接経路のためにしようとを可能にすると、その価値があるかもしれません。
Please note that if there are overlapping address domains between NR and the public Internet, the regular routing will not necessary allow sending the packet to the right domain.
NRと公共のインターネット間のアドレスドメインの重複がある場合は、通常のルーティングは、右のドメインにパケットを送信できるようになる必要はないことに注意してください。
Appendix C. Applicability Statement on Data Receivers behind Firewalls
ファイアウォールの背後にあるデータ受信機の付録C.適用性に関する声明
Section 3.7.2 describes how data receivers behind middleboxes can instruct inbound firewalls/NATs to forward NATFW NSLP signaling towards them. Finding an inbound edge-NAT in an address environment with NAT'ed addresses is quite easy. It is only required to find some edge-NAT, as the data traffic will be route-pinned to the NAT. Locating the appropriate edge-firewall with the PC-MRM sent inbound is difficult. For cases with a single, symmetric route from the Internet to the data receiver, it is quite easy; simply follow the default route in the inbound direction.
セクション3.7.2は、ミドルボックスの背後にあるデータ受信機は、それらに向けてのシグナリングNATFW NSLPを転送するために、インバウンドファイアウォール/ NATのを指示する方法について説明します。 NATによるアドレスを持つアドレス環境でのインバウンドエッジ-NATを見つけることは非常に簡単です。データトラフィックは、NATにルート固定されるように、唯一の、いくつかのエッジ-NATを見つけるために必要とされます。 PC-MRMで適切なエッジファイアウォールを配置することインバウンドが困難である送られました。データ受信機へのインターネットからの単一の対称経路を有する場合は、それは非常に簡単です。単にインバウンド方向でのデフォルトルートをたどります。
+------+ Data Flow
+-------| EFW1 +----------+ <===========
| +------+ ,--+--.
+--+--+ / \
NI+-----| FW1 | (Internet )----NR+/NI/DS
NR +--+--+ \ /
| +------+ `--+--'
+-------| EFW2 +----------+
+------+
~~~~~~~~~~~~~~~~~~~~~>
Signaling Flow
Figure 36: Data Receiver behind Multiple Firewalls Located in Parallel
図36：データ受信の並列に配置された複数のファイアウォールの背後にあります
When a data receiver, and thus NR, is located in a network site that is multihomed with several independently firewalled connections to the public Internet (as shown in Figure 36), the specific firewall through which the data traffic will be routed has to be ascertained. NATFW NSLP signaling messages sent from the NI+/NR during the EXTERNAL message exchange towards the NR+ must be routed by the NTLP to the edge-firewall that will be passed by the data traffic as well. The NTLP would need to be aware about the routing within the Internet to determine the path between the DS and DR. Out of this, the NTLP could determine which of the edge-firewalls, either EFW1 or EFW2, must be selected to forward the NATFW NSLP signaling. Signaling to the wrong edge-firewall, as shown in Figure 36, would install the NATFW NSLP policy rules at the wrong device. This causes either a blocked data flow (when the policy rule is 'allow') or an ongoing attack (when the policy rule is 'deny'). Requiring the NTLP to know all about the routing within the Internet is definitely a tough challenge and usually not possible. In a case as described, the NTLP must basically give up and return an error to the NSLP level, indicating that the next hop discovery is not possible.
データ受信機、及び従ってNRは、（図36に示すように）公衆インターネットへのいくつかの独立しファイアウォール接続でマルチホームであるネットワークサイトに位置しているときに、データトラフィックがルーティングされる介して特定のファイアウォールが確認されなければなりません。 NR +に向かって外部メッセージ交換中にNI + / NRから送信されたシグナリングメッセージNATFW NSLPは、同様に、データトラフィックによって渡されるエッジファイアウォールにNTLPによってルーティングされなければなりません。 NTLPはDSとDRとの間のパスを決定するために、インターネット内のルーティングについて注意する必要があります。このうち、NTLPは、NATFW NSLPシグナリングを転送するために選択されなければならないエッジファイアウォールのどの、EFW1又はEFW2どちらか決定することができます。間違ったエッジファイアウォールへのシグナリング、図36に示すように、間違ったデバイスにNATFW NSLPポリシールールをインストールすることになります。 （政策ルールは「拒否」の場合）これは（政策ルールが「許可」である）ブロックされたデータの流れや、進行中の攻撃のどちらかになります。インターネット内のルーティングについてのすべてを知っているNTLPを要求することは間違いなくタフな挑戦と、通常は不可能です。記載されているように場合には、NTLPは、基本的にはあきらめなければならず、次のホップの発見は不可能であることを示す、NSLPレベルにエラーを返します。
Appendix D. Firewall and NAT Resources
付録D.ファイアウォールやNATリソース
This section gives some examples on how NATFW NSLP policy rules could be mapped to real firewall or NAT resources. The firewall rules and NAT bindings are described in a natural way, i.e., in a way that one will find in common implementations.
このセクションでは、NATFW NSLPポリシールールは、実際のファイアウォールやNATリソースにマッピングすることができる方法のいくつかの例を示します。ファイアウォールルールとNATバインディングは1は一般的な実装で見つける方法で、自然な方法、すなわちで説明されています。
D.1. Wildcarding of Policy Rules
D.1。ポリシールールのワイルドカード
The policy rule/MRI to be installed can be wildcarded to some degree. Wildcarding applies to IP address, transport layer port numbers, and the IP payload (or next header in IPv6). Processing of wildcarding splits into the NTLP and the NATFW NSLP layer. The processing at the NTLP layer is independent of the NSLP layer processing and per-layer constraints apply. For wildcarding in the NTLP, see Section 5.8 of [RFC5971].
インストールするポリシールール/ MRIはある程度ワイルドカードすることができます。ワイルドカードは、IPアドレス、トランスポート層ポート番号、および（IPv6のまたは次のヘッダ）IPペイロードに適用されます。ワイルドカードの処理はNTLPとNATFW NSLP層に分かれます。 NTLP層の処理はNSLPレイヤ処理から独立しており、毎層の制約が適用されます。 NTLPでワイルドカードの場合は、[RFC5971]のセクション5.8を参照してください。
Wildcarding at the NATFW NSLP level is always a node local policy decision. A signaling message carrying a wildcarded MRI (and thus policy rule) arriving at an NSLP node can be rejected if the local policy does not allow the request. For instance, take an MRI with IP addresses set (not wildcarded), transport protocol TCP, and TCP port numbers completely wildcarded. If the local policy allows only requests for TCP with all ports set and not wildcarded, the request is going to be rejected.
NATFW NSLPレベルでのワイルドカードは、常にノードのローカルポリシーの決定です。ローカル・ポリシーが要求を許可しない場合NSLPノードに到着する（こうして、ポリシールール）ワイルドカードMRIを運ぶシグナリングメッセージを拒否することができます。例えば、完全にワイルドカード化（ワイルドカードを使っていない）に設定、IPアドレス、トランスポートプロトコルTCP、およびTCPポート番号のMRIを撮ります。ローカルポリシーは、すべてのポートを設定し、ワイルドカードではないとのTCPの要求だけを許可する場合、要求は拒否されようとしています。
D.2. Mapping to Firewall Rules
D.2。ファイアウォールのルールへのマッピング
This section describes how a NSLP policy rule signaled with a CREATE message is mapped to a firewall rule. The MRI is set as follows:
このセクションでは、NSLPポリシールールは、CREATEメッセージがファイアウォールルールにマッピングされていると合図する方法について説明します。次のようにMRIが設定されています：
o network-layer-version=IPv4
Oネットワーク層バージョンのIPv4 =
o source-address=192.0.2.100, prefix-length=32
Oソースアドレス= 192.0.2.100、接頭語長= 32
o destination-address=192.0.50.5, prefix-length=32
O宛先アドレス= 192.0.50.5、接頭語長= 32
o IP-protocol=UDP
O IPプロトコル= UDP
o L4-source-port=34543, L4-destination-port=23198
O L4元ポート= 34543、L4-宛先ポート= 23198
The NATFW_EFI object is set to action=allow and sub_ports=0.
NATFW_EFIオブジェクトが可能とsub_ports = 0 =アクションに設定されています。
The resulting policy rule (firewall rule) to be installed might look like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198.
インストールされる結果のポリシールール（ファイアウォールルール）は次のようになります。192.0.2.100ポート= 34543 192.0.50.5にポート= 23198からUDPを許可します。
D.3. Mapping to NAT Bindings
D.3。 NATバインディングへのマッピング
This section describes how a NSLP policy rule signaled with an EXTERNAL message is mapped to a NAT binding. It is assumed that the EXTERNAL message is sent by a NI+ located behind a NAT and does contain a NATFW_DTINFO object. The MRI is set following using the signaling destination address, since the IP address of the real data sender is not known:
ここでは、外部メッセージがバインディングNATにマッピングされるとNSLPポリシールールはシグナリング方法について説明します。外部メッセージは、NATの背後に配置NI +によって送信され、NATFW_DTINFOオブジェクトが含まれていたものとします。実際のデータ送信元のIPアドレスが知られていないので、MRIは、シグナリング宛先アドレスを使用して、以下の設定されます。
o network-layer-version=IPv4
Oネットワーク層バージョンのIPv4 =
o source-address= 192.168.5.100
Oソースアドレス= 192.168.5.100
o destination-address=SDA
O宛先アドレス= SDA
o IP-protocol=UDP
O IPプロトコル= UDP
The NATFW_EFI object is set to action=allow and sub_ports=0. The NATFW_DTINFO object contains these parameters:
NATFW_EFIオブジェクトが可能とsub_ports = 0 =アクションに設定されています。 NATFW_DTINFOオブジェクトは、これらのパラメータが含まれています：
o P=1
P = 1
o dest prefix=0
O接頭辞= 0
o protocol=UDP
Oプロトコル= UDP
o dst port number = 20230, src port number=0
O DSTポート番号= 20230、SRCポート番号= 0
o src IP=0.0.0.0
O SRC IP = 0.0.0.0
The edge-NAT allocates the external IP 192.0.2.79 and port 45000.
エッジ-NATは、外部IP 192.0.2.79、ポート45000を割り当てます。
The resulting policy rule (NAT binding) to be installed could look like: translate udp from any to 192.0.2.79 port=45000 to 192.168.5.100 port=20230.
結果の政策ルール（NAT結合）にインストールすることは次のようになります。20230 = 192.168.5.100ポートに192.0.2.79ポート= 45000までの任意のUDPを翻訳します。
D.4. NSLP Handling of Twice-NAT
D.4。トワイスNATのNSLP取り扱い
The dynamic configuration of twice-NATs requires application-level support, as stated in Section 2.5. The NATFW NSLP cannot be used for configuring twice-NATs if application-level support is needed. Assuming application-level support performing the configuration of the twice-NAT and the NATFW NSLP being installed at this devices, the NATFW NSLP must be able to traverse it. The NSLP is probably able to traverse the twice-NAT, as is any other data traffic, but the flow information stored in the NTLP's MRI will be invalidated through the translation of source and destination IP addresses. The NATFW NSLP implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP signaling messages as any other NATFW NSLP node does. For the given signaling flow, the NATFW NSLP node MUST look up the corresponding IP address translation and modify the NTLP/NSLP signaling accordingly. The modification results in an updated MRI with respect to the source and destination IP addresses.
セクション2.5で述べたように二回のNATの動的構成は、アプリケーション・レベルのサポートを必要とします。 NATFW NSLPは、アプリケーション・レベルのサポートが必要な場合は二回-NATの設定に使用することはできません。トワイスNATこのデバイスに設置されNATFW NSLPの設定を行うアプリケーションレベルのサポートを仮定すると、NATFW NSLPは、それを通過することができなければなりません。他のデータトラフィックですが、NTLPのMRIに保存されたフロー情報を送信元と送信先のIPアドレスの変換によって無効とされるようにNSLPは、おそらく二回-NATを通過することができます。二回-NATのNATFW NSLPの実装は、他のNATFW NSLPノードがするようNATFW NSLPとNTLPがシグナリングメッセージを傍受しなければなりません。与えられたシグナリング・フローについては、NATFW NSLPノードは、対応するIPアドレス変換を検索し、それに応じて、シグナリングNTLP / NSLPを変更する必要があります。送信元と送信先のIPアドレスに関して更新MRIでの修正結果。
Appendix E. Example for Receiver Proxy Case
レシーバープロキシケース付録E.例
This section gives an example on how to use the NATFW NLSP for a receiver behind a NAT, where only the receiving side is NATFW NSLP enabled. We assume FTP as the application to show a working example. An FTP server is located behind a NAT, as shown in Figure 5, and uses the NATFW NSLP to allocate NAT bindings for the control and data channel of the FTP protocol. The information about where to reach the server is communicated by a separate protocol (e.g., email, chat) to the DS side.
このセクションでは、受信側のみがNATFW NSLPが有効になっているNAT、背後にある受信機のためNATFW NLSPを使用する方法の例を示します。私たちは、作業例を示すアプリケーションとしてFTPを想定しています。 FTPサーバは、図5に示すように、NATの後ろに位置し、FTPプロトコルの制御及びデータチャネルのためのNATバインディングを割り当てるNATFW NSLPを使用しています。サーバに到達する場所についての情報は、DS側に別のプロトコル（例えば、電子メール、チャット）により通信されます。
Public Internet Private Address Space FTP Client FTP Server
公衆インターネットプライベートアドレス空間FTPクライアントFTPサーバー
DS NAT NI+
| | |
| | EXTERNAL |
| |<---------------------------|(1)
| | |
| |RESPONSE[Success] |
| |--------------------------->|(2)
| |CREATE |
| |--------------------------->|(3)
| |RESPONSE[Success] |
| |<---------------------------|(4)
| | |
| | <Use port=XYZ, IP=a.b.c.d> |
|<=======================================================|(5)
|FTP control port=XYZ | FTP control port=21 |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(6)
| | |
| FTP control/get X | FTP control/get X |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(7)
| | EXTERNAL |
| |<---------------------------|(8)
| | |
| |RESPONSE[Success] |
| |--------------------------->|(9)
| |CREATE |
| |--------------------------->|(10)
| |RESPONSE[Success] |
| |<---------------------------|(11)
| | |
| Use port=FOO, IP=a.b.c.d | Use port=FOO, IP=a.b.c.d |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~|<~~~~~~~~~~~~~~~~~~~~~~~~~~~|(12)
| | |
|FTP data to port=FOO | FTP data to port=20 |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(13)
Figure 37: Flow Chart
図37：フローチャート
1. EXTERNAL request message sent to NAT, with these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, nonce object (carrying nonce for CREATE), and the data terminal information object (I/P-flags set, sender prefix=0, protocol=TCP, DR port number = 21, DS's IP address=0); using the LE-MRM. This is used to allocate the external binding for the FTP control channel (TCP, port 21).
1.外部これらのオブジェクトと、NATに送信されたリクエストメッセージ：シグナリングセッション寿命、拡張フロー情報オブジェクト（ルールアクション=許可、sub_ports = 0）、メッセージシーケンス番号オブジェクト、ノンスオブジェクト（CREATEためのノンスを担持する）、およびデータ端末情報オブジェクト（I / P-フラグが設定され、送信者のプレフィックス= 0、プロトコル= TCP、DRポート番号= 21、DSのIPアドレス= 0）。 LE-MRMを使用。これは、FTP制御チャネル（TCP、ポート21）に対する結合の外部を割り当てるために使用されます。
2. Successful RESPONSE sent to NI+, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2), external address object (port=XYZ, IPv4 addr=a.b.c.d).
これらのオブジェクトとNI +に送信2.正常な応答：シグナリングセッション寿命、メッセージシーケンス番号、オブジェクト、情報コードオブジェクト（「成功」：2）、外部アドレスオブジェクト（ポート= XYZ、IPv4のADDR = A.B.C.D）。
3. The NAT sends a CREATE towards NI+, with these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, nonce object (with copied value from (1)); using the PC-MRM (src-IP=a.b.c.d, src-port=XYZ, dst-IP=NI+, dst-port=21, downstream).
（（1）からコピーされた値を有する）（sub_ports = 0 =ルールアクション可能）、メッセージシーケンス番号オブジェクト、ナンスオブジェクトシグナリングセッション寿命、拡張フロー情報オブジェクト3. NATは、これらのオブジェクトを、NI +向かっCREATE送信しますPC-MRM使用（SRC-IP = A.B.C.D、SRC-ポート= XYZ、DST-IP = NI +、DSTポート= 21、下流）。
4. Successful RESPONSE sent to NAT, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2).
これらのオブジェクトと、NATに送信4.正常な応答：セッション寿命、メッセージシーケンス番号、オブジェクト、情報コードオブジェクトシグナリング（「成功」：2）。
5. The application at NI+ sends external NAT binding information to the other end, i.e., the FTP client at the DS.
5. NI +のアプリケーションでは、DSで、すなわち、FTPクライアント、他端に外部NATバインディング情報を送信します。
6. The FTP client connects the FTP control channel to port=XYZ, IP=a.b.c.d.
6. FTPクライアントは、ポート= XYZ、IP = A.B.C.DにFTP制御チャネルを接続しています。
8. EXTERNAL request message sent to NAT, with these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, nonce object (carrying nonce for CREATE), and the data terminal information object (I/P-flags set, sender prefix=32, protocol=TCP, DR port number = 20, DS's IP address=DS-IP); using the LE-MRM. This is used to allocate the external binding for the FTP data channel (TCP, port 22).
8. EXTERNALこれらのオブジェクトと、NATに送信されたリクエストメッセージ：シグナリングセッション寿命、拡張フロー情報オブジェクト（ルールアクション=許可、sub_ports = 0）、メッセージシーケンス番号オブジェクト、ノンスオブジェクト（CREATEためのノンスを担持する）、およびデータ端末情報オブジェクト（I / P-フラグが設定され、送信元プレフィックスが= 32、プロトコル= TCP、DRポート番号= 20、DSのIPアドレス=のDS-IP）。 LE-MRMを使用。これは、外部のFTPデータチャネルのための結合（TCP、ポート22）を割り当てるために使用されます。
9. Successful RESPONSE sent to NI+, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2), external address object (port=FOO, IPv4 addr=a.b.c.d).
これらのオブジェクトとNI +に送信9成功応答：シグナリングセッション寿命、メッセージシーケンス番号、オブジェクト、情報コードオブジェクト（「成功」：2）、外部アドレスオブジェクト（ポート= FOO、IPv4のADDR = A.B.C.D）。
10. The NAT sends a CREATE towards NI+, with these objects: signaling session lifetime, extended flow information object (rule action=allow, sub_ports=0), message sequence number object, nonce object (with copied value from (1)); using the PC-MRM (src-IP=a.b.c.d, src-port=FOO, dst-IP=NI+, dst-port=20, downstream).
（（1）からコピーされた値を有する）（sub_ports = 0 =ルールアクション可能）、メッセージシーケンス番号オブジェクト、ナンスオブジェクトシグナリングセッション寿命、拡張フロー情報オブジェクト：10. NATは、これらのオブジェクトを、NI +向かっCREATE送信しますPC-MRMを使用して（SRC-IP = A.B.C.D、SRCポート= FOO、DST-IP = NI +、DSTポート= 20、下流）。
11. Successful RESPONSE sent to NAT, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2).
これらのオブジェクトと、NATに送信11.正常な応答：セッション寿命、メッセージシーケンス番号、オブジェクト、情報コードオブジェクトシグナリング（「成功」：2）。
13. The FTP clients connects the data channel to port=FOO and IP=a.b.c.d.
13. FTPクライアントは、ポート= FOO及びIP = A.B.C.Dにデータチャネルを接続します。
Authors' Addresses
著者のアドレス
Martin Stiemerling NEC Europe Ltd. and University of Goettingen Kurfuersten-Anlage 36 Heidelberg 69115 Germany
マーティンStiemerling NECヨーロッパ社とゲッティンゲン大学Kurfuersten-Anlageの36ハイデルベルクドイツ69115
Phone: +49 (0) 6221 4342 113 EMail: Martin.Stiemerling@neclab.eu URI: http://www.stiemerling.org
電話：+49（0）6221 4342 113電子メール：Martin.Stiemerling@neclab.eu URI：http://www.stiemerling.org
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@nsn.com URI：http://www.tschofenig.priv.at
Cedric Aoun Consultant Paris, France
セドリック・アウン・コンサルタントパリ、フランス
EMail: cedaoun@yahoo.fr
メールアドレス：cedaoun@yahoo.fr
Elwyn Davies Folly Consulting Soham UK
エルウィン・デイヴィスフォリーコンサルティングソーハム英国
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
電話：+44 7889 488 335 Eメール：elwynd@dial.pipex.com