[要約] RFC 5973は、NAT/Firewall NSIS Signaling Layer Protocol（NSLP）に関する仕様です。このプロトコルは、ネットワークアドレス変換（NAT）やファイアウォールを通過するネットワークサービスの制御を目的としています。
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)
NAT/ファイアウォールNSISシグナリングレイヤープロトコル（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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5973.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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を動的に構成しています。別のアプローチは、Middlebox通信（Midcom）です。このアプローチでは、ファイアウォールまたはNATの外部ALGSは、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-Firewall]は、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 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].
このメモは、NATFW NSISシグナリング層プロトコル（NSLP）と呼ばれるNSISのフレームワーク内のNATおよびファイアウォール構成のパス結合シグナル伝達プロトコルを定義します。NSIの一般的な要件は[RFC3726]で定義されており、NSISの一般的なフレームワークは[RFC4080]で概説されています。NSIS輸送層とNSISシグナリング層の間に分割を導入します。NSLPメッセージの輸送は、NSISネットワークトランスポートレイヤープロトコル（NTLP）によって処理され、一般的なインターネットシグナル伝達輸送（GIST）[RFC5971]が抽象的なNTLPの実装です。QOSおよびNATFWシグナル伝達のシグナル伝達ロジックは、異なるNSLPで実装されています。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レシーバー）から論理的に分解されたデータレシーバーが含まれますが、双方はNSIをサポートしています。このシナリオでは、インターネット全体、または少なくともすべてのNATとファイアウォールでNSISの展開を想定しています。このシナリオは、特に明記されていない場合、基本的な仮定として使用されます。
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. ネットワークの1つのエンドホストまたは領域のみが、データ受信機またはデータ送信者のいずれかで、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には、NSIの広範な展開の前後に遭遇する可能性のあるさまざまなシナリオに対処するのに十分な2つの基本的なシグナリングメッセージがあります。
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.
作成および外部メッセージは、NSISイニシエーター（NI）によってNSIS Responder（NR）に送信されます。両方のタイプのメッセージは、後続の応答メッセージによって認められます。この応答メッセージは、要求された構成を確立できる場合、NRによって生成されます。それ以外の場合、NRまたはNSLPフォワーダー（NFS）のいずれかも、エラーが発生した場合にそのようなメッセージを生成することもできます。NFSとNRは、いわゆる通知メッセージであるNIに通知する非同期メッセージを生成することもできます。
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.
データレシーバーがプライベートアドレス指定の領域またはファイアウォールの後ろに存在し、エッジナット/エッジファイアウォールを事前に設定して、データ送信者が使用するための（公開）到達可能なアドレスを提供する必要がある場合、外部メッセージと作成メッセージの組み合わせを提供する必要があります。使用されている。
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.
NSIの導入中、データ送信者と受信者のいずれかがNSISに認識されない可能性があります。これらの場合、NATFW NSLPは、データ送信者とデータ受信機の間のパスでNSISを認識したミドルボックスを利用して、Proxy NATFW NSLPサービス（つまり、プロキシモード）を提供できます。通常、これらのボックスは、エンドホストが配置されている領域の境界にあります。
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.
作成および外部メッセージは、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 (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.
このメモは次のように構成されています。セクション2では、NATFW NSLPシグナル伝達のネットワーク環境について説明します。セクション3では、NATFWシグナル伝達プロトコルを定義し、セクション4では、メッセージコンポーネントとプロトコルで使用される全体的なメッセージを定義します。ドキュメントの本体の残りの部分は、セクション5のセクション5、セクション6の一方的な自己アドレス固定（UNSAF）[RFC3424]に関するIABの考慮事項、およびセクション7のIANAの考慮事項をカバーしています。ネットワーク内の可能性のある場所は、セクション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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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のコンテキストでは、条件はルールが適用されるパケットのセットの仕様です。アクションのセットには、常にルールごとに単一の要素のみが含まれており、アクション「拒否」またはアクション「許可」のいずれかに限定されます。
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.
o 予約されたポリシールール：NATまたはファイアウォールに保存されたポリシールールは、後の異なるシグナリング交換によって活性化するためにアクティブ化します。このタイプのポリシールールは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.
o インストールされたポリシールール：NATまたはファイアウォールで運用されているポリシールール。このタイプのルールは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.
o 記憶されたポリシールール：信号交換が正常に完了するとすぐに、即時使用するためにNATとファイアウォールに保存されたポリシールール。
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 ネットワークアドレス翻訳者：ネットワークアドレス変換は、ホスト間で透明なルーティングを提供するために、IPアドレスがあるIPアドレスの領域から別のIPアドレスの領域にマッピングされる方法です（[RFC2663を参照]）。ネットワークアドレス翻訳者は、パケットを通過するパケットを変更することにより、この作業を実行するデバイスです。
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ピア（または単に「ピア」）：nsis natfw nslpノードは、[rfc5971]で定義されているようにNTLP隣接性が作成されています。
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 Edge-Nat：An Edge-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 パブリックネットワーク：「グローバルまたはパブリックネットワークは、インターネットに割り当てられた数字の権限（IANA）または同等のアドレスレジストリによって割り当てられた一意のネットワークアドレスを備えたアドレスの領域です。このネットワークは、NATディスカッション中に外部ネットワークとも呼ばれます」[RFC2663]。
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.
o シグナリング宛先アドレス（SDA）：一般に公開/グローバル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.
「Middlebox」という用語は、さまざまなデバイスをカバーし、[RFC3234]で明確に定義されています。そして、目的地ホスト」。そのため、ミドルボックスは、幅広い機能を備えた多くのカテゴリに分類されますが、そのすべてが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 2回ナット
o Multihomed 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 Actions for firewalls are usually one or more of:
o ファイアウォールの輸送ソースおよび宛先ポート番号アクションは、通常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.
o ソースIPアドレスとポート番号をグローバルにルーティング可能なIPアドレスと関連するポート番号に変更します。
o Change destination IP address and transport port number to a private IP address and associated port number.
o 宛先IPアドレスと輸送ポート番号をプライベートIPアドレスと関連するポート番号に変更します。
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.
ミドルボックスには、ポリシールールの2つの論理表現が含まれる場合があることに注意してください。ポリシールールには、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つのミドルボックスがあることを意味します（図1のNATFW）。これらのエンドホストにあるアプリケーションは、他のそのようなエンドホストで対応するアプリケーションとのコミュニケーションを確立しようとします。この通信確立は、アプリケーションが両当事者間のランデブーポイントとして機能するアプリケーションサーバーに連絡して、IPアドレスとポートを交換することを要求する場合があります。ローカルアプリケーションは、ローカルホストのNSISエンティティをトリガーし、前向きデータパスに沿ったミドルボックストラバーサルのプロビジョニングを制御します（たとえば、API呼び出しを介して）。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は、1つ以上のNATFWノードを指すことに注意してください。
Figure 1: Generic View of NSIS with NATs and/or Firewalls
図1：NATおよび/またはファイアウォールを使用したNSIの一般的なビュー
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 Responder（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に行うことができます。
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の背後にあります。エッジナット（MB2およびMB3）として知られる最も外側のNATは、両側のパブリックインターネットに接続されています。これらのデバイスは確かにNAT機能を実装するが、ファイアウォール機能を実装できるため、NATは一般的にMBX（Middlebox No. X用）としてラベル付けされています。
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.
両側の図3には2つのミドルボックス（MB）のみが示されていますが、一般に、各側の任意の数のMBを考慮する必要があります。
+----+ +----+ //----\\ +----+ +----+
NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR
+----+ +----+ \\----// +----+ +----+
private public private
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB：MiddleboxNi：NSISイニシエーターNR：NSIS Responder
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.
NIからNRへの信号トラフィックは、パス上のすべてのミドルボックス（この順序でMB1からMB4）を横断する必要があり、NSISシグナリングがそれらを通過できるようにすべてのミドルボックスを適切に構成する必要があります。NATFWシグナリングは、すべてのミドルボックスを構成し、この構成がさらにシグナリングすることに起因するアドレス変換を考慮する必要があります。送信者（NI）は、受信機（NR）のIPアドレスを事前に知る必要があります。そうしないと、NSISシグナリングメッセージをレスポンダーに送信することはできません。このIPアドレスは、レスポンダーのプライベートIPアドレスではなく、NATのパブリックIPアドレス（MB3のIPアドレス）であることに注意してください。代わりに、NATバインディング（パブリックIPアドレスを含む）をNAT MB3に以前にインストールする必要があります。このNATバインディングにより、その後、NATに到達するパケットをプライベートアドレス領域内の受信機に転送できます。受信機には、パブリックIPアドレスとポート番号（NATFW NSLPを含む）を学習する方法がいくつかある場合があり、アプリケーションレベルのシグナリングプロトコルを使用してこの情報を送信者に信号に信号する必要がある場合があります。
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.
このシナリオは、1つ以上のNATの背後にある送信ノードのアプリケーションインスタンスを示しています（一般的なMBとして表示され、セクション2.2の説明を参照）。レシーバーは公開インターネットにあります。
+----+ +----+ //----\\
NI --| MB |-----| MB |---| |--- NR
+----+ +----+ \\----//
private public
民間公衆
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB：MiddleboxNi：NSISイニシエーターNR：NSIS Responder
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 Responderのアドレスに直接送信します。パスに沿ったミドルボックスは、信号メッセージをインターセプトし、それに応じて構成します。
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).
データを受信するアプリケーションインスタンスは、MBとして示されている1つ以上のNATの背後にあります（セクション2.2の説明を参照）。
//----\\ +----+ +----+
NI ---| |---| MB |-----| MB |--- NR
\\----// +----+ +----+
public private
パブリックプライベート
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB：MiddleboxNi：NSISイニシエーターNR：NSIS Responder
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 Responderは、外部ミドルボックスで公開されるIPアドレスを決定し、このアドレスについてNSISイニシエーターに通知する必要があります。1つの可能性は、アプリケーションレベルのプロトコルが使用されていることです。つまり、パブリック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).
これは特別なケースであり、主な問題は、両端のホストが論理的に同じアドレス空間内にあることを検出する必要性から生じますが、2回のNATの両側にあるアドレス領域の2つのパーティションにもあります（[RFC2663を参照してください] 2回のナット機能の議論のために）。
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：MiddleboxNi：NSISイニシエーターNR：NSIS Responder
Figure 6: NAT to Public, Sender and Receiver on Either Side of a Twice-NAT Scenario
図6：2倍のナットシナリオの両側にある公開、送信者、レシーバーへの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に示されているミドルボックスは2倍です。つまり、両側にIPアドレスとポート番号をマッピングします。つまり、プライベートおよびパブリックインターフェイスでのソースおよび宛先IPアドレスのマッピングを意味します。
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 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.
このシナリオには、DNSサーバーなどのアプリケーションレベルのエンティティの支援が必要です。アプリケーションレベルのエンティティは、シンボリック名に基づいたリクエストを処理し、データパケットがNIからNRに正しく転送されるようにミドルボックスを構成する必要があります。これらのミドルボックスの構成には、Midcom [RFC3303]など、他のミドルボックス通信プロトコルが必要になる場合があります。NSISシグナル伝達は、2回のナットタイプのミドルボックスは通常他の手段で構成されているため、2回の唯一のケースでは必要ありません。それにもかかわらず、パスにファイアウォールもある場合、NSISシグナル伝達が役立つ可能性があります。この場合、NSISは2倍のナットでポリシールールを構成しませんが、パス上のファイアウォールでポリシールールを構成します。NSISシグナル伝達プロトコルは、このシナリオに耐えるのに少なくとも十分に堅牢でなければなりません。これには、2回のナットがNATFW NSLPも実装し、NATFWシグナリングセッションに参加する必要がありますが、NATの構成は変更されません。つまり、アドレスマッピング情報をNATから読み取り、メッセージルーティング情報を翻訳する必要があります。MRI、[RFC5971]）それに応じてNSLPおよび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シグナル伝達とその後のデータパケットは、イニシエーターからパブリックIPアドレスのレスポンダー（初めて）、およびレスポンダーのパブリックIPアドレスからレスポンダーへ（2回目）に2回NATを通過します。
NI public
\ +----+ //----\\
+-| MB |----| |
/ +----+ \\----//
NR
private
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB：MiddleboxNi：NSISイニシエーターNR：NSIS Responder
Figure 7: NAT to Public, Both Hosts behind Same NAT
図7：Nat to Public、両方のホストの背後にあるホスト
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
MB：MiddleboxNi：NSISイニシエーターNR：NSIS Responder
Figure 8: Multihomed Network with Two NATs
図8：2つの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は、おそらくデータトラフィックがNIからNRへのどのパスを取るかを知らずに、NRからNIにインバウンドする外部メッセージをルーティングする必要があります（付録Cも参照）。
+----+
NR -------| FW |\
\ +----+ \ //---\\
\ -| |-- NI
\ \\---//
\ +----+ |
--| FW |-------+
+----+
private
private public
民間公衆
FW: Firewall NI: NSIS Initiator NR: NSIS Responder
FW：ファイアウォールNI：NSISイニシエーターNR：NSISレスポンダー
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の場合、1つ以上の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.
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は、[RFC5971]で定義されている一般的なインターネットシグナリングトランスポート（GIST、NTLPの実装）に掲載されます。NATFW NSLPメッセージは、NSISイニシエーター（NI）によって開始され、NSLPフォワーダー（NFS）によって処理され、NSIS Responder（NR）が受信します。少なくともNiとNRがこのNSLPを実装する必要があります。中間NFは、関連するミドルボックス関数を提供する場合にのみこのNSLPを実装します。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シグナリングを開始する必要があります。これにより、DSに関連付けられたNIがDRのアドレスに向かってNSLPシグナル伝達を起動します（図10を参照）。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レスポンダーに送信します。このリクエストメッセージは、新しいNATFW NSLPシグナリングセッションを作成する最初のメッセージです。NIとNRは、NATFW NSLPシグナリングセッションを開始する前に、すでにアプリケーションセッションを共有する可能性が高いです。両方のセッションの違いに注意してください。
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要求メッセージは、NATFW NSLPサポートを備えたNFが移動するたびに処理されます。要求メッセージを傍受し、さらなる治療のためにそれを受け入れている各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応答者は、応答メッセージを生成し、同じNFSのチェーンを介してホップバイホップをNiに送り返します（同じNFチェーンのトラバーサルは、NTLPの確立された逆メッセージルーティング状態を介して保証されます）。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 応答メッセージは、以前の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セッションが作成メッセージで開始された場合、データ送信者はデータフローをデータ受信機に送信し始めることができます。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シグナリングはDSからDRへのデータパスに従うため、これにより、データパス上のファイアウォールのみが送信者側の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.
同じことは、デフォルトですべてのトラフィックをブロックするファイアウォールの背後にあるNRSについて部分的に当てはまります。この場合、NRは、インバウンドNATFW NSLPシグナル伝達と対応するデータトラフィックのインバウンドファイアウォールを指示する必要があります。NRがインバウンドファイアウォールを通知すると、アプリケーションレベルの信号を開始してNIとの通信を開始できます。このメカニズムは、ファイアウォールの背後にあるサービスをホストするマシンでも使用できます。この場合、NRは説明されているようにインバウンドファイアウォールを通知しますが、これをNISに通信する必要はありません。
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は、公開可能なIPアドレス、つまりこの特定のNATFW NSLPシグナリングセッションの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は、新しいNATFW NSLPシグナリングセッションを作成し、DRのパブリックIPアドレスに直接信号を送信します。このパブリックIPアドレスは、NIの間にNATがない場合にNIのアドレスとして使用され、ミドルボックスでポリシールールを作成します。予約により、信号メッセージの転送のみが許可されているが、データフローパケットは許可されないことに注意してください。NIからNRへの信号が肯定的な応答メッセージで確認されると、以前の外部メッセージ信号によって設定されたデータフローパケットの転送を許可するポリシールールがアクティブになります。外部メッセージについては、セクション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.
上記の使用法は、通信サポートNSIの両端を想定していますが、NSISがパスの一方の端にのみ展開されている場合に失敗します。この場合、送信側（図11を参照）または受信側（図12を参照）の1つのみがNSISが認識し、両方と同時にではありません。NATFW NSLPは、セクション3.7.6で説明されているように、プロキシモードを使用して両方のシナリオ（つまり、DSまたはDRがNSIをサポートしていない）をサポートしています。
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は、適切なアクションを実行できるように障害を返す必要があります。エラー応答メッセージを送信することにより、リクエストメッセージ処理中に（同期）、または通知通知メッセージを送信していつでも（非同期に）これを行うことができます。
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 作成：NATFW NSLPシグナリングセッションの作成、変更、更新、削除に使用されるリクエストメッセージ。つまり、DSからDRへのデータパスを開きます。
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シグナリングセッションの予約、変更、リフレッシュ、削除に使用される要求メッセージ。外部メッセージは、エッジナットまたはエッジファイアウォールに転送され、インバウンド作成メッセージをNRに転送できるようにします。さらに、外部メッセージは外部アドレスを予約し、該当する場合はエッジナットでポート番号を予約します。
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.
応答メッセージは、NSLPフォワーダーとレスポンダーによる外部メッセージを作成して同期して生成され、NATFW NSLPシグナリングセッションまたはノードに関連する操作の成功または失敗、またはいくつかの情報を報告します。通知や応答など、他のメッセージに対して応答メッセージを生成してはなりません。
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.
すべての応答メッセージは、エラークラスコードと応答コードを含むNATFW_INFOオブジェクトを搭載する必要があります（セクション4.2.5を参照）。このセクションでは、エラークラスに応じて応答メッセージのグループの用語を定義します。
o Successful RESPONSE: Messages carrying NATFW_INFO with error class 'Success' (2).
o 応答の成功：エラークラス「成功」（2）を伴うNATFW_INFOを伝えるメッセージ。
o Informational RESPONSE: Messages carrying NATFW_INFO with error class 'Informational' (1) (only used with NOTIFY messages).
o 情報応答：エラークラス「情報 '（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レベルに保存されているSignaling 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シグナリングセッションが作成され、ノードは作成または外部メッセージへの応答メッセージを待っています。州の「保留中」のNATFW NSLPシグナリングセッションは、ローカルに付与されたNATFW NSLPシグナリングセッションの寿命の期間内に対応する応答メッセージが受信されていない場合、「死んだ」とマークする必要があります（セクション3.4で説明されています。）。
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シグナリングセッションの寿命がこれ以降カウントされます。状態「確立」のNATFW NSLPシグナリングセッションは、ローカルで付与されたNATFW NSLPシグナリングセッションの寿命（セクション3.4で説明されている）の時間内に更新メッセージが受信されていない場合、「デッド」としてマークする必要があります。
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 DEAD：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 Transitory：ノードは非同期メッセージ、つまり通知を受信しており、しばらくすると必要に応じてNATFW NSLPシグナリングセッションを削除できます。ノードが通知メッセージを受信した場合、シグナリングセッションを「一時的」としてマークします。このシグナリングセッションは、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）の適切なエラーがある応答メッセージ（3）コードが再回復不可能な構文エラーが検出された場合に生成されます。たとえば、回復可能なエラーは、ノードがゼロ以外の値に設定された予約フラグを持つメッセージを受信する場合です。これは、セクション4.2によると、未知のNSLPオブジェクトとその取り扱いを指します。メッセージがNATFW NSLPに配信された場合、これは、NTLPレイヤーがデータベース内のセッションID（SID）およびMRIエントリと相関することができることを意味します。したがって、メッセージとルーティング情報のソースを識別するのに十分な情報があり、NTLPメッセージングアソシエーションの確立されたチェーンを介してメッセージをNIに戻します。構文のエラーが検出された場合、メッセージはさらに転送されません。オブジェクトの処理に起因する特定の応答コードは、それぞれのオブジェクト定義セクションで説明されています（セクション4を参照）。このチェックに合格した後、NATFW NSLPノードは、セクション3.6で説明されている認証および認証関連のチェックを実行します。これらのテストが正常に渡された場合にのみ、さらなる処理が実行されます。それ以外の場合、処理が停止し、エラー応答が返されます。
Further message processing stops whenever an error RESPONSE message is generated, and the EXTERNAL or CREATE message is discarded.
エラー応答メッセージが生成され、外部または作成メッセージが破棄されるたびに、さらなるメッセージ処理が停止します。
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イニシエーターは、NATFW NSLP Signalingセッションを送信する前に、NATFW NSLPシグナリングセッションのライフタイム値（数秒で表される）を選択する必要があります。NATFW NSLPシグナリングセッションのライフタイム値は、次のことを計算することをお勧めします。
o the number of lost refresh messages with which NFs should cope;
o NFSが対処すべき失われた更新メッセージの数。
o the end-to-end delay between the NI and NR;
o NiとNRの間のエンドツーエンドの遅延。
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;
o NATFW NSLPシグナル伝達セッションハイジャック（[RFC4081]）によるネットワークの脆弱性、NATFW NSLPシグナリングセッションハイジャックは、NIがNATFW NSLPシグナリングセッションを明示的に削除しない場合に容易になります。
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;
o NATFW NSLPシグナリングセッションが実際に必要とされなくなった後に存在する許容時間。たとえば、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.
o NIのIPアドレスのリース時間。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: 1. The refresh message timer to be randomly set to a value in the range [0.5R, 1.5R].
RSVP仕様[RFC2205]は、NATFW NSLPシグナリングセッションの寿命を計算するための適切なアルゴリズムと、NATFW NSLPシグナリングセッション間のメッセージの同期を更新する手段を提供します。[RFC2205]推奨：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（LTがNATFW NSLPシグナリングセッションのライフタイムである）は、LT> =（K 0.5）*1.5*rを満たす必要があります。ここで、Kは小整数です。その後、最悪の場合、状態を削除せずに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シグナリングセッションのライフタイム値の変更は必要ありません。該当する場合、作成または外部メッセージは転送されます。
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オブジェクトに新しい値を保存する必要があります。作成または外部メッセージは転送されます。
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.
NSLP転送またはNSLPレスポンダーは、要求されたNATFW NSLPシグナリングセッションのライフタイム値を大きすぎると拒否し、クラス「シグナリングセッション障害」のエラー応答メッセージを生成する必要があります。）拒否時。エラーメッセージを生成する代わりに、寿命を削減することが推奨されます。
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レスポンダーは、要求されたNATFW NSLPシグナリングセッションのライフタイム値を小さくて拒否し、クラス「シグナリングセッションの失敗」のエラー応答メッセージを生成する必要があります。）拒否時。
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レスポンダーは、受信した作成または外部メッセージの成功した応答を生成し、NATFW NSLPシグナリングセッションのライフタイム値をNATFW_LTオブジェクトのライフタイム値を上記の寿命に設定し、メッセージを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シグナリングセッションの寿命を受け入れる必要があります。許容可能な値は、作成または外部メッセージを処理する際にNSLPフォワーダーが受け入れた値を指します。許容値よりも大きい受信値の場合、NSLPフォワーダーは、「シグナリングセッション障害」（7）の応答コード「修正された寿命が大きすぎる」（0x11）の応答メッセージを生成する必要があります。このノードの許容可能なシグナリングセッションの寿命。ノードローカルポリシーで受け入れられる値よりも低い受信値の場合、NSLPフォワーダーは、クラス「シグナリングセッションの失敗」（7）の応答コード「修正された寿命が小さすぎる」（0x12）の応答メッセージを生成する必要があります。このノードの最小許容信号セッションの寿命を運ぶオブジェクト。どちらの場合も、「変更された寿命が大きすぎる」（0x11）または「変更された寿命が小さすぎる」（0x12）のいずれかで、NFは通知メッセージを生成し、エラークラスを「情報」に設定してアウトバウンドを送信する必要があります（1）また、「NATFWシグナリングセッションが終了した」（0x05）に設定された応答コードを使用します。
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フォワーダーがNATFW NSLPシグナリングセッションのライフタイム値の15秒で応答メッセージを受信すると、この値が許容値に低いか等しいかをチェックします。
+-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+
| |---------------->| NSLP |---------------->| |
| NI | | forwarder | | NR |
| |<----------------| check 15<20 |<----------------| |
+-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+
lt = lifetime
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は、送信されるメッセージごとにMSNを1つずつ増分する必要があります。MSNが最大値に達すると、次の値はゼロになります。すべてのNATFW NSLPノードは、[RFC1982]で定義されているアルゴリズムを使用して、MSNラップアラウンドを検出する必要があります。
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とNRSには、生成する対応する応答メッセージに受信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.
作成または外部メッセージを受信する場合、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ノード提供されているよりも多くの情報を必要とするNSLPノードは、応答コード「認証が失敗した」（0x01）または応答コード「認証が失敗した」（0x02）を使用して、クラス「永続的な障害」（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ベースの電話システム、エンタープライズネットワーク、ホームネットワークなどのさまざまな環境で実行されると予想されます。これらのユースケース間では、認証と承認に関する要件はまったく異なります。NSIを使用するホームゲートウェイ、またはインターネットカフェは、シグナリングの承認のための「ネットワーク内からの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）のエラー応答を送信する必要があり、応答コード「認証が失敗しました」（0x02）。
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は、MRI、たとえば宛先ポートとソースポート、およびNATFW NSLPからの情報を使用して、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).
Createメッセージを使用することにより、NATFW NSLPでは、Middleboxの存在下でも2つのホストがデータを交換できるようにします。NI（データ送信者またはプロキシのいずれか）は、セクション4.3.1で定義されているように作成されたメッセージを生成し、NTLPに渡します。NTLPは、メッセージ全体をNRに向けてメッセージルーティング情報（MRI）に基づいて転送します。NATFW NSLPを実装するパスに沿った各NSLPフォワーダーは、NSLPメッセージを処理します。転送はホップバイホップで行われますが、NATFW NSLP機能とNSLPホップウェイポイント間の非NSIS認識ルーターを含まないNSLPフォワーダーを透過的に通過する場合があります。メッセージがNRに到達すると、NRは要求を受け入れるか、拒否できます。NRは作成への応答を生成し、この応答はNIにホップバイホップされます。NATFW NSLPフォワーダーは、いつでもリクエストを拒否する場合があります。図14は、Ni（この例のDS）、NF（NATなど）、およびNR（この例のDR）の間のメッセージフローをスケッチします。
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.
o NATFW NSLPシグナリングセッションの寿命を延長することは、セクション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ノードタイプごとに異なります。ONSLPイニシエーター：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転送業者：次のホップに作成メッセージを転送できないNFSは、クラス「永久障害」（5）のエラー応答を生成する必要があります。NTLPレイヤーが別のNFまたはNRのいずれかのNATFW NSLPピアを見つけることができず、GIST API（GISTによって報告されたタイムアウトエラー）を介してエラーを返す場合、このケースが発生する可能性があります。NFSでの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：NATのパブリック側で最初の作成メッセージが受信されると、外部メッセージを使用して事前に予約を探します（セクション3.7.2を参照）。一致するプロセスでは、セクション3.8で説明されているように、受信したMRI情報と保存されたMRI情報を考慮します。一致する予約が見つからない場合、つまり予約が事前に行われていない場合、NSLPはクラス「シグナリングセッション障害の障害のエラー応答」（7）を返す必要があります。（0x03）。一致する予約がある場合、NSLPは、ポリシールールのソースIPアドレスの一部としてデータ送信者のアドレス（および該当する場合）を保存します（「記憶されたポリシールール」）をロードし、メッセージを次のように転送します。NRの内部（ほとんどの場合プライベート）アドレスに設定されている宛先IPアドレス。初期の作成メッセージがプライベート側で受信されると、NAT結合は割り当てられますが、アクティブ化されません（付録D.3も参照）。要求されたポリシールールをすぐに予約できない場合、クラス「シグナリングセッションの障害」（7）の応答コード「要求されたポリシールールがポリシー競合のために拒否された」（0x4）のエラー応答メッセージが生成されます。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).
* ファイアウォール：最初の作成メッセージが受信されると、NSLPは要求されたポリシールールを覚えていますが、ポリシールールをインストールしません。その後、メッセージはNRに向かって転送されます。要求されたポリシールールをすぐに予約できない場合、クラス「信号セッションの障害」（7）のエラー応答メッセージが生成されます。
* 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レシーバー：NRS初期作成メッセージを受信するNRSクラス「成功」（2）の成功応答で返信する必要があります。それ以外の場合、適切な応答コードを使用して応答メッセージを生成する必要があります。応答メッセージは、応答コード、成功またはエラーのいずれかに関係なく、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.
ミドルボックスでの記憶されているポリシールールは、それらを記憶した原因となった作成メッセージと同じSIDで対応する成功した応答メッセージを受信するときにのみインストールする必要があります。これは、いくつかの問題への対策です。たとえば、作成するメッセージが何らかの理由で最終NRに届かない場合の中間NFSでポリシールールを読み込むことによるリソースの無駄です。
Processing of a RESPONSE message is different for every NSIS node type:
応答メッセージの処理は、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.
o NSLPフォワーダー：NFSは、一致するSIDを使用した成功した応答メッセージが受信された場合、記憶されているポリシールールをインストールします。一致するSIDを含むエラー応答メッセージが受信された場合、NATFW NSLPセッションは「死んでいる」とマークされ、ポリシールールはインストールされず、記憶されたルールは破棄されます。
o NSIS responder: The NR should never receive RESPONSE messages and MUST silently drop any such messages received.
o NSIS Responder：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は、適切な応答コードセットで通知メッセージを生成することにより、いつでも作成セッションを取り壊すこともできます。
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 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.
NSISシグナル伝達は、パスでNATやファイアウォールが存在する場合でも、エンドツーエンドを移動することを目的としています。これは、セクション3.7.1で説明されているように、データ送信者自体がNATまたはファイアウォールの背後にある場合にうまく機能します。データ受信機が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シグナル伝達とデータフローを着信することについて、ローカルNSISインフラストラクチャ（つまり、インバウンドファイアウォール/NAT）に伝える必要があります。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にインバウンドデータを転送する「許可」アクションで適切なルールがないため、到達可能になりたい博士ノードが到達できない状況に対処しています。ただし、特定のシナリオでは、指定されたアドレスからトラフィックが送信されないように要求されていない限り、インバウンドデータトラフィック（「デフォルトの許可」を備えたファイアウォール）をブロックしないインバウンドファイアウォールの後ろに位置するノード。この場合、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+
| | | |
| | | |
| | | |
| | 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）は、後のメッセージを作成するためのNSISイニシエーター（NI）であり、シグナル伝達（NR）のNSISターゲットになる可能性があります。
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やファイアウォールによって傍受される場合があります。
Basically, there are two different signaling scenarios. Either
基本的に、2つの異なるシグナリングシナリオがあります。また
1. the DR behind the NAT/firewall knows the IP address of the DS in advance, or
1. NAT/ファイアウォールの背後にあるDRは、事前にDSのIPアドレスを知っている、または
2. the address of the DS is not known in advance.
2. DSのアドレスは事前に知られていません。
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を参照）で送信する必要があります。（SDA、付録Aも参照）。ファイアウォールの背後にあるDRを備えたシナリオについては、特別な条件が適用されます（付録Cのアプリケーションステートメントを参照）。データレシーバーは、適切なメッセージルーティング方法を選択するために、ファイアウォールまたはNATの背後にのみ配置されているかどうかを判断するために挑戦されます。この決定は、おそらくDHCPを介して与えられたローカル構成パラメーターに依存するか、ネットワーク構成の他の非NSLP関連テストを通じて発見することができます。既知のデータ送信者のIPアドレスでPC-MRMを使用することをお勧めします。これにより、要点は可能な限り最高のハンドルを与え、メッセージ「アップストリーム」（アウトバウンド）をルーティングします。データ送信者の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の場合、NI（データレシーバーDRまたはプライベートネットワーク内の他のホストにあります）は、信号宛先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.
外部信号メッセージは、使用されたメッセージルーティング方法とは無関係に、遭遇した中間NSIS NATFWピアでNSIS NATFWシグナリングセッションを作成します。さらに、このプロセスの一部としてエッジナットまたはエッジファイアウォールデバイスが発見されるようにする必要があります。エンドホストは、このデバイスを知ることを想定することはできません。代わりに、NATまたはファイアウォールボックス自体がネットワークの外側の周囲にあることを知っていると想定されています。このエンティティを超えた外部メッセージの転送は必要ありません。内部ホストの機能に関する情報を提供する可能性があるため、禁止する必要があります。この発見プロセス中に見つける必要があるのは、それが最も外側のNATまたはファイアウォールであることに注意する必要があります。たとえば、ネットワークボーダーのアウトバウンドパスにNATと（その後）ファイアウォールがある場合、ファイアウォールはエッジファイアウォールです。すべてのメッセージは、トポロジごとの最も外側のエッジデバイスに転送する必要があります。このデバイスが、受信メッセージの作成のためのNATFW NSLPシグナリングセッションについて知っていることを確認する必要があります。ただし、NATは、パブリック側にグローバルにルーティング可能なIPアドレスを公開しているため、まだエッジナットです。これは、エッジナットとパブリックネットワークの間のファイアウォールの影響を受けません。
Possible edge arrangements are:
可能なエッジの配置は次のとおりです。
Public Net ----------------- Private net --------------
| Public Net|--|Edge-FW|--|FW|...|FW|--|DR|
|パブリックネット| - | edge-fw | - | fw | ... | fw | - | dr |
| Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR|
|パブリックネット| - | edge-fw | - | edge-nat | ... | natまたはfw | - | dr |
| Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR|
|パブリックネット| - | edge-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.
パブリックレルムに最も近いエッジナットまたはエッジファイアウォールデバイスは、応答メッセージを成功させて外部リクエストメッセージに応答します。Edge-natには、natfw_external_ipオブジェクト（セクション4.2.2を参照）、公開可能な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に外部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つの関数は、あらゆる種類の作成および外部メッセージに対して同じように動作するため、別のセクションで説明されています。
o Extending the lifetime of NATFW NSLP signaling sessions is described in Section 3.7.3.
o NATFW NSLPシグナリングセッションの寿命を延長することは、セクション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を参照）。この情報は、NATFW_DTINFOオブジェクトに、少なくとも「DSTポート番号」および「プロトコル」フィールドを含める必要があります。これは、NATのタイプに応じて、途中のNATが必要とする可能性があるためです。他のすべてのフィールドは、可能なNISのセットを制限するためにNIによって設定される場合があります。Edge-natは、NATFW_DTINFOオブジェクトで提供される情報を使用して、一致するMRIを転送するNATFW作成メッセージのみを可能にします。NATFW作成メッセージのMRIは、DSからDRへのフローのソースIPアドレス/ポートとして、NATFW_DTINFOオブジェクト（「SRC IPv4/ V6アドレス」、「SRCポート番号」、「プロトコル」）に設定されたパラメーターを使用する必要があります。NATFW_DTINFOで携帯される情報を必要とするNATは、クラス「シグナルセッション障害」の多くのエラー応答メッセージを生成できます（7）：
o 'Requested policy rule denied due to policy conflict' (0x04)
o 「政策の競合により拒否された要求された政策規則」（0x04）
o 'Unknown policy rule action' (0x05)
o 「不明なポリシールールアクション」（0x05）
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フィールドでの要求値は許可されていません」（0x08）
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 「ソースIPアドレスの範囲が大きすぎる」（0x0c）o '宛先IPアドレス範囲が大きすぎます」（0x0d）
o 'Source L4-port range is too large' (0x0E)
o 「ソースL4ポート範囲が大きすぎる」（0x0e）
o 'Destination L4-port range is too large' (0x0F)
o 「宛先L4ポートの範囲が大きすぎる」（0x0F）
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フォワーダー：NFSでのNSLPメッセージ処理は、ミドルボックスタイプに依存します。
* 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 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：NATは、メッセージが外部（ほとんどの場合）アドレスで受信されているか、内部（プライベート）アドレスで受信されているかどうかを確認します。外部アドレスで受信した場合、NFはクラス「プロトコルエラー」（3）のエラー応答を生成する必要があります。「外部側の外部要求メッセージ」（0x0B）を受信します。内部（プライベートアドレス）で受信し、NATFW_EFIオブジェクトにアクション「拒否」が含まれている場合、クラス「プロトコルエラー」（3）のエラー応答「応答コード」「要求されたルールアクション」（0x06）を生成する必要があります。内部アドレスで受信した場合、IPアドレス、および該当する場合は1つ以上のポートが予約されています。NATFW_EXTERNAL_BINDINGオブジェクトがメッセージに存在する場合、EDGE-NATではないNATには、割り当てられた外部IPアドレスを含める必要があります。それがエッジナットであり、それ以降のエッジファイアウォールがない場合、NSLPメッセージはそれ以上転送されず、翻訳されたアドレスを保持しているNATFW_EXTERNAL_IPオブジェクトを含む成功した応答メッセージが生成されます。外部メッセージの結果として。Edge-natは、オブジェクトが外部メッセージに含まれている場合、NATFW_External_bindingオブジェクトを応答メッセージにコピーする必要があります。応答メッセージはNIに向かって送り返されます。エッジナットでない場合、NSLPメッセージは、翻訳されたIPアドレスをLE-MRMのシグナリングソースIPアドレスとして使用してさらに転送され、フィールドのNATFW_DTINFOオブジェクトの翻訳されたポート「DRポート番号」、つまりNATFW_DTINFO翻訳されたポート番号を反映するようにオブジェクトが更新されます。Edge-natまたはその他のNATは、NATFW_DTINFOオブジェクトを運ばない外部メッセージを拒否する必要があります。または、このオブジェクト内のアドレス情報が無効であるか、ローカルポリシーに準拠していない場合（たとえば、提供される情報は、さまざまなアドレスに関連しています（「ワイルドカード」）しかし、Edge-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がリクエストでLE-MRMに設定されている場合、さらにNATFW_EXTERNAL_IPオブジェクトが応答メッセージに含まれ、翻訳されたアドレスを保持し、該当するポート、情報を保持します。。この情報は、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）のエラー応答メッセージを生成する必要があります。
Processing of a RESPONSE message is different for every NSIS node type:
応答メッセージの処理は、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フォワーダー：NFSは、リクエストされた予約のために状態を維持する限り、このメッセージを「成功」に設定したNATFW_INFOオブジェクトが含まれている場合、単にこのメッセージを転送するだけです（2）。応答メッセージに「成功」にならないクラスを設定した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.
o NSIS Responder：このタイプのメッセージは、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は、適切な応答コードセットで通知メッセージを生成することにより、いつでも外部セッションを取り壊すこともできます。
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.
外部で作成されたアクション「許可」による予約は、その後の作成メッセージによって有効にする必要があります。NIが特定のNATFW NSLPシグナリングセッションを再リッシュし、複数の異なる作成メッセージに対して再利用できる限り、外部（選択されたアクションから独立した）で行われた予約は、生存されています。NIは、作成メッセージを受信した直後に予約を取り壊すことを決定する場合があります。これは、新しい作成メッセージごとに新しいNATFW NSLPシグナル伝達セッションを作成する必要があることを意味します。作成メッセージは、外部によって作成された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.
作成（セクション3.7.1を参照）または外部プロキシモード（セクション3.7.6を参照）を使用せずに（セクション3.7.6を参照）、エッジナットまたはエッジファイアウォールを超えてDRにデータトラフィックは転送されません。外部の唯一の機能は、NRに向かって移動するその後のメッセージを作成することを保証することです。着信の相関は、外部予約状態にメッセージを作成します。セクション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によって維持される必要があり、外部によって作成された状態は外部によって維持される必要があります。メッセージを更新することは、最初のメッセージと同じセッションIDを運ぶメッセージと、ゼロより大きい寿命のNATFW_LTライフタイムオブジェクトです。同じSIDを持つが、異なるMRIを運ぶメッセージは、ポリシールールの更新として扱われ、セクション3.10で定義されているように処理されます。すべての更新作成または外部メッセージは、NRによって生成された適切な応答メッセージによって確認される必要があります。各NSLPフォワーダーによる受信時に、指定されたセッションIDの状態は、提案された更新メッセージ期間に基づいて計算された期間、NATFW NSLPシグナリングセッションの更新期間によって拡張されます。NATFW NSLPシグナル伝達セッションの新しい（拡張）寿命は、現在の現地時間と提案された生涯値（NATFW NSLPシグナリングセッションの更新期間）として計算されます。セクション3.4は、寿命を詳細に計算するプロセスを定義します。
NI Public Internet NAT Private address NR
Ni Public Internet Nat Private Address Nr
| | space |
| CREATE[lifetime > 0] | |
|----------------------------->| |
| | |
| | |
| | CREATE[lifetime > 0] |
| |--------------------------->|
| | |
| | RESPONSE[Success/Error] |
| RESPONSE[Success/Error] |<---------------------------|
|<-----------------------------| |
| | |
| | |
Figure 16: Successful Refresh Message Flow, CREATE as Example
図16：リフレッシュメッセージフローが成功し、例として作成
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 Signalingセッションの前にNATFW NSLPシグナリングセッションの作成/外部メッセージを生成できます。更新/外部メッセージが送信されるレートと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を受け入れるNRS NSLPシグナリングセッションの更新/外部メッセージは、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イニシエーターは、図17に示すように、ライフタイム値が0に設定されている作成または外部メッセージを使用することにより、この削除をトリガーできます。作成または外部メッセージタイプが使用されるかどうかは、NATFW NSLPシグナリングセッションの作成方法によって異なります。
NI Public Internet NAT Private address NR
Ni Public Internet Nat Private Address Nr
| | space |
| CREATE[lifetime=0] | |
|----------------------------->| |
| | |
| | CREATE[lifetime=0] |
| |--------------------------->|
| | |
Figure 17: Delete message flow, CREATE as Example
図17：メッセージフローを削除し、例として作成
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に達するまで転送されます。0の生涯値を持つ作成/外部メッセージは、パスに沿ったノードにNSIS状態が残っていないため、正または負の応答を生成しません。
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イニシエーターは、寿命設定された[ゼロ]をゼロにゼロにして作成/外部メッセージを使用して、単一の作成または外部メッセージが複数のNATFW NSLPシグナリングセッションを終了するようにします。NISは、NATFW NSLPシグナリングセッションの削除要求を集約することを好む場合、この手順に従うことができます。NIは、セッションIDをゼロに設定し、MRIのソースアドレスを使用したIPアドレスに設定して作成または外部メッセージを使用します。終了するそれぞれのNATFW NSLPシグナリングセッションの他のすべてのフィールドも設定されています。それ以外の場合、これらのフィールドは完全にワイルドカードされています。NSLPメッセージは、セクション5.2.1および7.1.4で説明されているように、「明示的なルーティング」を要求する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は、クラス「永続的な障害」のエラー応答（5）でそれを拒否する必要があります（5）認証が失敗した場合、クラスのエラー応答が失敗した場合、応答コード「認証が失敗しました」（0x01）失敗 '（5）応答コード「認証が失敗した」（0x02）承認が失敗した場合。NATFW NSLPシグナリングセッションの所有権の証明は、このメモで定義されているように（セクション5.2.1を参照）、複数のセッション終了にこの集約を使用する場合は不可能です。ただし、アウトバウンドNFは、受信したCREATEメッセージまたは外部メッセージの情報と、リクエストが受信されたGISTメッセージングアソシエーションとの関係を使用できます。アウトバウンドNFは、NIとの確立されたGISTメッセージング関連を介して、この集計された作成または外部メッセージのみを受け入れる必要があります。アウトバウンドNFは、この集計された作成または外部メッセージを伝播してはなりませんが、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とNRSは、非同期イベントに通知メッセージを生成する場合があり、NATFW_INFOオブジェクトがイベントの理由を示しています。これらの理由は、NATFW_INFOオブジェクト（クラスは、Notifyメッセージ内の「情報」（1）（1）に設定する必要があります）に携帯することができます。このリストは、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 「ルートの変更：アウトバウンドパスでの可能なルート変更」（0x01）：セクション3.9の指示に従ってください。シグナリングセッションが「一時的」を除く状態である場合、これはインバウンドとアウトバウンドを送信する必要があります。シグナリングセッションはとにかく一時的なものであるため、州の一時的なシグナリングセッションの通知メッセージは破棄する必要があります。NTLPにSIIハンドルを提供することにより、アウトバウンドNotifyメッセージを明示的なルーティングで送信する必要があります。
o 'Re-authentication required' (0x02): The NI should re-send the authentication. This MUST be sent inbound.
o 「再認証が必要」（0x02）：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ノードはまもなくダウンします」（0x03）：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シグナリングセッションが終了しました」（0x05）：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に到達するか、NIに到達するまで、常に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:
通知メッセージを受信するときの初期処理は、すべてのNATFWノードで同じです。NATFWノードは、すでに確立されたNTLPメッセージングアソシエーションを介して通知メッセージを受け入れる必要があります。さらなる処理は、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は通知メッセージを生成してはなりません。
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に向かってniまたはアウトバウンドに向かって転送する必要があります。NFSは、アウトバウンドを受信したが、「再認可が必要」（0x02）などのインバウンドのみを送信することのみが許可されているメッセージを通知することを静かに破棄する必要があります。
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レスポンダー：NRSは、報告されたイベントに基づいた応答コードを含む非同期イベントに対して通知メッセージを生成する必要があります。NRは、アウトバウンドを受信したが、「再認可が必要」（0x02）などのインバウンドのみを送信することのみが許可されているメッセージを通知することを静かに廃棄する必要があります。
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シグナル伝達セッションごとに通知メッセージを生成し、インバウンドを送信しようとします。送信される通知メッセージの数があるため、すべてのメッセージを同時に送信できるわけではないため、ノードのシャットダウンが不必要に長くなる可能性があります。このケースは、多数のNATFW NSLPシグナリングセッションが関与している場合、Notify Stormとして説明できます。
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シグナリングセッションは、説明されているこのようなシナリオまたは同様のケースでメッセージを通知します。NFSはこの手順に従う必要があります。NFは、NTLPセットのセッションIDを使用して通知メッセージを使用し、MRIは完全にワイルドカードを使用して使用します。、[RFC5971]のセクション5.2.1および7.1.4で説明されている「明示的なルーティング」を使用します。このタイプの通知を受け取るインバウンドNFは、MRIをvoidと一致させるピアからのすべてのNATFW NSLPシグナリングセッションをすぐにすぐに見ます。このメッセージは通常、インバウンドNFで複数の通知メッセージになります。つまり、NFは、終了したNATFW NSLPシグナリングセッションA Notifyメッセージを生成できます。ただし、NFは、ここで説明するように通知メッセージを集約することもできます。
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のいずれかになります。通常、Edge-NatまたはEdge-Firewallを使用して、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.
このプロキシモードの操作では、新しい作成または外部メッセージタイプは必要ありませんが、拡張された作成および外部メッセージタイプに依存しています。それらはそれぞれ、プロキシと外部プロキシを作成し、NSLPヘッダーのPフラグをp = 1に設定することにより区別されます。このフラグは、問題のNATFW NSLPシグナリングセッションのプロキシモードで動作するようにそれらを受け取るエッジナットとエッジファイアウォールを指示します。作成と外部のメッセージタイプのセマンティクスは変更されず、さまざまなノードタイプの動作は、プロキシノードを除き、セクション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は、受信側のみがNSIを実行している場合でも、アウトバウンドデータパケットのデータ送信者に向かってインバウンドパスに状態をインストールする機能をNRに与えます（図18を示すように）。説明されている方法の目標は、Edge-Nat/ Edge-Firewallをトリガーして、データ受信機に代わって作成メッセージを生成することです。この場合、NRは、セクション3.7.2のように標準の外部メッセージ処理シナリオで実行されるため、ネットワークの境界に向かって信号を送ることができます。メッセージは、エッジナット/エッジファイアウォールに到達するまで転送されます。パブリックIPアドレスとポート番号は、Edge-Nat/Edge-Firewallで予約されています。図18に示すように、標準の外部メッセージ処理ケースとは異なり、エッジナット/エッジファイアウォールは、いくつかのファイアウォールまたはNATを横断する新しい逆パスで作成メッセージを送信するようにトリガーされます。Createの新しい逆パスは、Edge-Nat/Edge-FirewallとDRの間のルーティングの非対称性を処理するために必要です。作成と外部メッセージのセマンティクスは変更されないこと、つまりそれぞれが前述のように処理されないことを強調する必要があります。
DS Public Internet NAT/FW Private address DR
No NI NF space 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オブジェクトがないことは、Edge-NatではなくDSによって開始された作成を示します。2つのシグナリングセッション、つまり外部プロキシのセッションと作成のセッションは独立していません。プライマリセッションは外部プロキシセッションです。作成セッションは、外部プロキシセッションに続発します。つまり、外部プロキシセッションがシグナリング状態が「確立された」または「一時的」である限り、作成セッションは有効です。外部プロキシの他のシグナル伝達状態、つまり「保留中」または「死んでいる」の作成セッションはありません。これにより、2つのシグナリングセッション間の運命共有が保証されます。
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.
外部プロキシメッセージのこれらの処理ルールは、通常の外部処理に追加されます。ONSLPイニシエーター（NI）：NIは、NATFW_NONCEオブジェクトの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.
o NSLPフォワーダーはEdge-NatまたはEdge-Firewallのいずれかです：NFが外部プロキシメッセージを受け入れると、それがNRであるかのように成功した応答メッセージを生成し、セクション3.7.1で定義された作成メッセージを生成し、受信したNATFW_NONCEオブジェクトと同じ値を持つNATFW_NONCEオブジェクト。NFは、作成プロキシメッセージを生成してはなりません。NFは、外部プロキシ更新メッセージが最初に受信された場合にのみ、作成メッセージ信号セッションを更新する必要があります。これには、シグナリングセッションを引き裂くことも含まれます。つまり、NFは、0に設定されたLifetimeセットの外部プロキシメッセージが最初に受信された場合にのみ、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はDSがNSISを認識していると仮定し、
b) the DS is NSIS aware but the DR assumes the DS to be NSIS unaware.
b) DSはNSIS認識ですが、DRはDSがNSISを認識しないと想定しています。
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.
ケースa）DSが予想される作成メッセージを送信しないため、データトラフィックをブロックするミドルボックスになります。ケースB）により、DRはエッジナットまたはエッジファイアウォールによるプロキシモードのサポートを正常に要求します。Edge-Nat/Edge-Firewallは作成メッセージを送信し、DSは作成メッセージも送信します。両方の作成メッセージは、分離されたNATFW NSLPシグナリングセッションとして処理されるため、NATFW NSLPシグナリングセッションごとの一般的なルールが適用されます。NATFW_NONCEオブジェクトは、NI開始の作成メッセージからEdge-Nat/Edge-Firewallによって生成されたメッセージの作成を区別するために使用されます。データ送信者の側がNSIが認識している場合に外部プロキシシグナリングセッションを取り壊すかどうかを決定することは、NRの責任ですが、DRによってそうでないと誤って想定されていました。DSが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.
外部プロキシへの応答メッセージと、Edge-Natによって生成された作成メッセージの間には、可能な人種条件があります。作成メッセージは、応答メッセージよりも早く到着できます。NIは、外部プロキシへの応答メッセージが受信されなかった場合でも、Edge-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-AWAREノードが必要です。つまり、このノードは応答メッセージを生成しています。この最後のノードは、Edge-Nat/ Edge-Firewall、またはNRが利用可能でないことを検出する他のNatfw NSLPピアである可能性があります（おそらくGISTタイムアウトの結果ですが、他のトリガーがあるかもしれません）。
DS Private Address NAT/FW Public Internet NR
NI Space NF no 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メッセージと応答メッセージの処理は、セクション3.7.1に似ています。ただし、エッジナット/エッジファイアウォールで転送が停止していることを除きます。Edge-Nat/Edge-Firewallは、状況（エラー/成功）に応じて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-Proxyモードは、エッジデバイスで終了するため、データパスに沿ってすべての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は、一部のネットワークエッジで最初に徐々に展開される可能性がありますが、後でネットワークの他の部分でも徐々に展開される可能性があります。プロキシモードを使用すると、NIがNATFW NSLPを使用するようにネットワークの他の部分もアップグレードされているかどうかをNIが決定することができなくなります。NIからNRへのパスがNATFW-NSLP対応であるかどうかを判断する1つの方法は、通常の作成メッセージを使用して、応答成功またはエラー応答を待つことです。これにより、作成されたメッセージが作成されるように、追加のメッセージが送信されます。
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により、プロキシモードの使用と、エッジナットまたはエッジファイアウォールによるパスのさらなる調査が可能になります。NIは、記載されているようにプロキシモードの処理を要求し、Eフラグ（図20を参照）を設定して、Edge-NatまたはEdge-FirewallにNATFW NSLP対応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.
受信したプロキシモードメッセージに通常のプロキシモードの取り扱いに加えて、eフラグセットがある場合、エッジナットまたはエッジファイアウォールは、create-proxyまたはexternal-proxyをNRに向けて送信する必要があります。Edge-NatまたはEdge-Firewallは、NRPに到達可能な別の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またはファイアウォールです。現在、NATFW NSLPがネットワークの実際のエッジであるNATまたはファイアウォールのどれを自動的に検出させる既知の方法はありません。したがって、ネットワークオペレーターは、エッジナットまたはエッジファイアウォールを構成し、これらのデバイスがエッジになくなっていない場合は、これらのデバイスを再構成することが重要です。たとえば、エッジナットはISP内にあり、ISPはこのエッジナットの前に別のNATを配置することを選択します。この場合、ISPは、古いEdge-natを通常のNATFW NLSP NATにするために再構成し、新しくインストールされたNATをEdge-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の作成メッセージが予約アドレスにどのように関連しているかを知る必要があります。
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.
Demultiplexingメソッドは、ローカルNATFW NSLPノードおよびポリシールールに保存されている情報を使用します。ポリシールールでは、LE-MRM MRIソースアドレス（[RFC5971]を参照）をフロー宛先IPアドレスとして、ネットワーク層バージョン（IP-ver）をIPバージョンとして使用します。NATの外部IPアドレスは、外部フロー宛先IPアドレスとして保存されます。フロー宛先IPアドレス以外のポリシールールの他のすべてのパラメーターは、NATFW_DTINFOオブジェクトが外部メッセージに含まれていない場合、ワイルドカードです。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で作成メッセージを受信すると、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.
（w）でマークされたテーブルエントリはワイルドカードを使用でき、（n/u）がマークされたエントリはマッチングには使用されません。
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.
NIまたはNI以外のNATFW NSLPノードは、NTLP仕様またはその他に記載されている手段により、ルートの変更を検出するNIまたはNI以外のNODEが、この変更を示す通知メッセージを生成し、NIに向かってNRに向かって送信します（セクション3.7.5も参照してください。）。NIに向かう途中の中間NFSは、この情報を使用して、セクション3.2.8で説明されているように、特定の期間内に更新を受け取らない場合、NATFW NSLPシグナリングセッションをローカルで削除できるかどうかを後で決定できます。セクション3.7.5で義務付けられているように、通知メッセージの輸送制限を考慮することが重要です。
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.
このNotifyメッセージを受信するNIは、新しい作成または外部メッセージを生成し、同じセッションIDを使用した最初のメッセージに関するNATFW NSLPシグナリングセッションの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 Next-Hop発見など、残りの処理とメッセージ転送はすべて、特定のセクションで説明されているように、定期的なNSLP処理の対象となります。通常のルーティングは、変更されたルートに沿った新しい作成または外部メッセージを正しいNFSに導きます。これらの新しい作成または外部メッセージを受信する元のパスにあったNFS（セクション3.10も参照）は、セッションIDを使用して既存のNATFW NSLPシグナリングセッションを更新できます。一方、元のパスになかったNFSは、このNATFW NSLPシグナリングセッションの新しい状態を作成します。次のセクションでは、ポリシールールの更新方法について説明します。
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アドレスから別のIPアドレスに移動している）、ルートの変更（これにより、別のNATデバイスで異なるNATマッピングになる可能性がある）、またはNIが単純に変更することの願いがあるため、ポリシールールの更新が必要になります。ルール。NISは、既存のNATFW NSLPシグナリングセッションのポリシールールを更新できます。適切な作成または外部メッセージ（セクション3.4と同様）を変更したメッセージルーティング情報（MRI）を以前にインストールしたものと比較して送信できますが、既存のセッションIDを使用して意図したものを識別します。更新のターゲット。承認と認証に関して、この更新の作成または外部メッセージは、最初のメッセージとまったく同じ方法で扱われます。したがって、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メッセージに携帯されており、オブジェクトは、Big Endian（ネットワーク順序付け）バイナリデータ表現を使用してエンコードされたType-Length-Value（TLV）です。ヘッダーとオブジェクトは、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-DATAオブジェクトは、オブジェクトの最初の32ビットとしてこの共通ヘッダーを含める必要があります（これはGIST共通ヘッダーと同じではありません）。NSLPメッセージタイプとPフラグの2つのフィールドと、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：作成
o 0x2: EXTERNAL
o 0x2：外部
o 0x3: RESPONSE
o 0x3：応答
o 0x4: NOTIFY
o 0x4：通知
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.
別のタイプのメッセージが受信される場合、応答コード「違法メッセージタイプ」（0x01）を使用したクラス「プロトコルエラー」（3）のエラー応答が生成する必要があります。
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に設定する必要があります。プロキシモードは、メッセージタイプの作成と外部と組み合わせてのみ使用する必要があります。タイプ応答または通知を使用してメッセージを処理する場合は、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フラグは、プロキシモードで、エッジナットまたはエッジファイアウォールがNRにメッセージを送信し続ける必要があるかどうか、つまりエンドツーエンドであるかどうかを示します。Eフラグは、Pフラグが設定されている場合にのみ1に設定できます。それ以外の場合は、無視する必要があります。Eフラグは、メッセージタイプの作成と外部と組み合わせてのみ使用する必要があります。タイプ応答または通知を使用してメッセージを処理する場合は、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.
NATFW NSLPオブジェクト図21で定義された共通ヘッダー形式を使用します。オブジェクトヘッダーには、これらのフィールドが含まれています。2つのフラグ、2つの予約ビット、NSLPオブジェクトタイプ、4ビットの予約フィールド、およびオブジェクト長。その総長は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オブジェクトを定義する後続のセクションにリストされています。クラス「プロトコルエラー」のエラー応答（3）応答コード「間違ったオブジェクトの長さ」（0x07）を生成する必要があります。オブジェクトの長さ。NSLPオブジェクトヘッダーの2つの主要なビットを使用して、このメモで定義されていないオブジェクトの目的の処理（[RFC5971]、付録A.2.1を参照）、つまりオブジェクトタイプは定義されていません。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）のエラー応答で拒否する必要があります。
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（ "optional"）：オブジェクトが理解されていない場合、削除してから、メッセージの残りを通常どおり処理します。
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（ "Forward"）：オブジェクトが理解されていない場合、メッセージ処理の結果として転送されたメッセージで変更されずに保持する必要がありますが、ローカルに保存されません。
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アドレス、および該当する場合はポート番号をエッジナットで運びます。
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.
たとえば、従来のNATによってIPアドレスのみが予約されている場合は、フィールド「ポート番号」を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）メッセージに含めることができます。マルチレベルのNAT展開については、1つまたは複数の外部バインディングアドレス、および該当するポート番号を搭載しています（たとえば、セクション2.5を参照）。このオブジェクトに掲載された情報の利用は、付録Bで説明されています。
Type: NATFW_EXTERNAL_BINDING (0x00E)
タイプ：natfw_external_binding（0x00e）
Length: 1 + number of IPv4 addresses
長さ：1 IPv4アドレスの数
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.
たとえば、従来のNATによってIPアドレスのみが予約されている場合は、フィールド「ポート番号」を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)
タイプ：natfw_efi（0x00f）
Length: 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:
このオブジェクトには、「ルールアクション」と「sub_ports」の2つのフィールドがあります。「ルールアクション」フィールドには、これらの意味があります。
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 0x0002：拒否：このアクションを備えたポリシールールは、Middleboxと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も0x0002も含まれていない場合、クラス「シグナルセッション障害」（7）のエラー応答（7）の応答コード「不明なポリシールールアクション」（0x05）を生成する必要があります。
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」フィールドには、このルールが適用される連続輸送層ポートの数が含まれています。このフィールドのデフォルト値は0です。つまり、NTLPのMRMまたはNATFW_DTINFOオブジェクトで指定されたポートのみがポリシールールに使用されます。1の値は、NTLPのMRM（PORT1）で指定されたポートに加えて、2番目のポート（PORT2）が使用されていることを示しています。ポート2のこの値は次のように計算されます。PORT2= PORT1 1. 0以外の値は、このフィールドで使用してはなりません。クラス「シグナルセッション障害」（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.
このオブジェクトは、「応答コード」フィールドの値に応じて、成功または失敗した作成または外部メッセージのいずれかを示す応答メッセージで応答コードを搭載しています。このオブジェクトは、通知の理由を指定するために通知メッセージにも掲載されています。
Type: NATFW_INFO (0x010)
タイプ：natfw_info（0x010）
Length: 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つのビットは、常にゼロに設定され、無視されます。4ビットクラスフィールドには、エラークラスが含まれています。次のクラスが定義されています。
o 0: Reserved
o 0：予約済み
o 1: Informational (NOTIFY only)
o 1：情報（通知のみ）
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.
* 0x01：ルートの変更：アウトバウンドパスでの可能なルート変更。
* 0x02: Re-authentication required.
* 0x02：再認証が必要です。
* 0x03: NATFW node is going down soon.
* 0x03：NATFWノードはまもなくダウンします。
* 0x04: NATFW signaling session lifetime expired.
* 0x04：NATFWシグナリングセッションの寿命が切れました。
* 0x05: NATFW signaling session terminated.
* 0x05：NATFWシグナリングセッションが終了しました。
o Success:
o 成功：
* 0x01: All successfully processed.
* 0x01：すべてが正常に処理されました。
o Protocol error:
o プロトコルエラー：
* 0x01: Illegal message type: the type given in the Message Type field of the NSLP header is unknown.
* 0x01：違法なメッセージタイプ：NSLPヘッダーのメッセージタイプフィールドに与えられたタイプは不明です。
* 0x02: Wrong message length: the length given for the message in the NSLP header does not match the length of the message data.
* 0x02：間違ったメッセージの長さ：NSLPヘッダーのメッセージに与えられた長さは、メッセージデータの長さと一致しません。
* 0x03: Bad flags value: an undefined flag or combination of flags was set in the NSLP header.
* 0x03：悪いフラグの値：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.
* 0x05：違法なオブジェクトの存在：このタイプのメッセージで使用してはならないオブジェクトが存在していました。
* 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:
o 一時的な障害：
* 0x01: Requested resources temporarily not available.
* 0x01：一時的に利用できないリクエストされたリソース。
o Permanent failure:
o 永続的な失敗：
* 0x01: Authentication failed.
* 0x01：認証に失敗しました。
* 0x02: Authorization failed.
* 0x02：承認が失敗しました。
* 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.
* 0x01：セッションが非同期に終了しました。
* 0x02: Requested lifetime is too big.
* 0x02：リクエストされた生涯が大きすぎます。
* 0x03: No reservation found matching the MRI of the CREATE request.
* 0x03：作成要求のMRIに一致する予約は見つかりませんでした。
* 0x04: Requested policy rule denied due to policy conflict.
* 0x04：ポリシーの競合により拒否された政策規則の要求。
* 0x05: Unknown policy rule action.
* 0x05：不明なポリシールールアクション。
* 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で説明されているように、NonCE値を運びます。
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：NonCeオブジェクト
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) Length: variable. Maximum 3.
タイプ：NATFW_DTINFO（0x013）長さ：変数。最大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.
o P：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.
SPIフィールドは、Sが設定されている場合にのみ存在します。ポート番号は、Pが設定されている場合にのみ存在します。フラグPとSを同時に設定してはなりません。応答コードを使用したクラス「プロトコルエラー」（3）のエラー応答「Flag-Fieldの組み合わせ」（0x09）が両方とも設定されている場合は、生成する必要があります。PまたはSが設定されている場合、私も設定する必要があり、プロトコルフィールドは特定のプロトコルを運ぶ必要があります。sまたはpが設定されている場合、応答コード「無効なフラグフィールドの組み合わせ」（0x09）を使用した「プロトコルエラー」（3）のエラー応答（3）が生成する必要がありますが、iは設定されていません。
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アドレスでは、「送信者プレフィックス」を32に設定する必要があります。値は、IPアドレスワイルドカードを示します。
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
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.
タイプ：8ビットフィールドこのルールが適用されるICMPタイプの値を指定します。
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オブジェクトヘッダーで常にFLAGの組み合わせAB = 00を運びます。クラス「プロトコルエラー」（3）の応答コード「必須オブジェクトの欠落」（0x04）のエラー応答メッセージ（0x04）は、必須の宣言されたオブジェクトが欠落している場合は生成する必要があります。クラス「プロトコルエラー」（3）の応答コード「違法オブジェクトが表示される」（0x05）のエラー応答メッセージ（0x05）は、このタイプのメッセージで使用してはならないオブジェクトが存在する場合は生成する必要があります。クラス「プロトコルエラー」のエラー応答メッセージ（3）応答コード「Object Object Present」（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シグナリングセッションを作成し、ポリシールールを作成するために使用されます。さらに、CREATEメッセージは、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 NSLPヘッダーでPフラグが1に設定されている場合、NONCEオブジェクト（M）
o ICMP Types Object (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).
o ICMPタイプオブジェクト（o）NTLPのメッセージルーティング情報は、ソースIPアドレスとしてDSに、DRは宛先IPアドレスとして設定する必要があります。他のすべてのパラメーターは、必要なポリシールールに従って設定する必要があります。[下流]（アウトバウンド）に設定された方向を使用して、パス結合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.
外部メッセージは、a）NATの外部IPアドレス/ポートを予約するために使用されます。b）NSIS対応DRに関するファイアウォールに通知するか、c）インバウンドファイアウォールで着信データトラフィックをブロックします。
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 NSLPヘッダーでPフラグが1に設定されている場合、NONCEオブジェクト（M）
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.
応答メッセージは、作成および外部メッセージへの応答です。通知や応答など、他のメッセージに対して応答メッセージを生成してはなりません。
The RESPONSE message for the class 'Success' (2) carries these objects: o Signaling Session Lifetime object (M)
クラス「成功」の応答メッセージ（2）にはこれらのオブジェクトが含まれます。
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 Hop-by-Hopに向かってルーティングされます。このメッセージに使用されるMRMは、対応する作成または外部メッセージで使用される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は、対応する作成または外部メッセージで使用される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.
一般にNSIに焦点を当てたセキュリティの脅威は[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ノードを含む可能性のあるプロトコルであり、そのため、2パーティのプロトコルではありません。[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).
許可を提供するためのセキュリティソリューションは、異なるNSLPの治療に直接影響を与えます。QoS NSLP [RFC5974]および対応する直径QOS作業[RFC5866]からわかるように、会計と充電はQoS予約の重要な役割を果たしているように見えますが、金銭的側面はNATおよびFirewall Signalingの承認決定に間接的に影響を与える可能性があります。したがって、QoSとNATFWシグナリングの間で認可処理のセマンティクスには違いがあります。NATFW-AWAREノードは、ピンホールまたはNATバインディングの確立を要求するエンティティ（ユーザーまたはマシンなど）を承認することを望んでいます。承認決定の結果は許可または禁止されていますが、QoS認可決定は、QoSパラメーターの異なるセットが承認されていることを示している可能性があります（例として[RFC5866]を参照）。
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.
最も単純なシナリオから始めて、隣接するノードは互いに認証され、シグナリングメッセージ通信を保護するためのキーイング資料を確立できると想定されています。ノードは、認証に加えて、互いに承認する必要があります。「セキュリティコンテキスト」という用語を、セキュリティ手順全体、これが機能するために必要な必要なインフラストラクチャ（例：主要な管理）および確立されたセキュリティ関連の状態を参照するためのプレースホルダーとして使用します。認証に使用される必要な長期キー（対称キーまたは非対称キー）は、2つの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認識ノード間の関係の可能性を示しています。ホストAは、たとえば、会社のファイアウォール（Middlebox 1）にキーイングマテリアル（たとえば、共有秘密）を確立したエンタープライズネットワークのホストです。ネットワークA（Company Network）のネットワーク管理者は、ホストA（または特定の会社が使用したい識別子）のアクセス制御リストを作成しました。ネットワークBのホストBとMiddlebox 2の間でまったく同じ手順を使用することもできます。Middlebox1とMiddlebox 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は、信号メッセージ開始者の追加の承認が必要になる場合があります（隣接ノードの承認に加えて）。認証と認証情報が最初の信号メッセージに添付されていない場合、Middlebox 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）は、NTLPで携帯されているセッションID（SID）を使用して、NATFW NSLPシグナリングセッションの所有権を示します。セッションIDはランダムな方法で生成される必要があり、それにより、オフパスの敵が標的攻撃の取り付けを防ぐ必要があります。したがって、敵は攻撃を実行するためにランダムに生成されたセッションIDを学習する必要があります。モビリティ環境では、現在オフパスである以前のオンパスノードが攻撃を行うことができます。特定のNATFW NSLPシグナリングセッションのメッセージは、NTLPによってNATFW NSLPに処理され、さらなる処理が行われます。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.
一部のシナリオは、承認トークンの使用の恩恵を受ける場合もあります。彼らの目的は、2つの異なるシグナル伝達プロトコル（SIPやNSIなど）と許可決定を関連付けることです。これらのトークンは、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プロキシによって提供されます。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を完全に開くことを許可しないでください（つまり、All-Allポリシーを適用する必要はありません）が、DRSが非常に特定のポリシーを予約できるようにする必要があります。たとえば、DRは、Jabberファイル転送の受信TCP接続の「許可」ポリシールールの予約を要求できます。この予約されたポリシー（図15を参照）ルールは、作成リクエストメッセージ（図15を参照）に一致させることでアクティブにする必要があります。このメカニズムにより、認証と承認の問題を特定のエッジネットワークでローカルに管理できます。逆方向には、作成要求メッセージは、認証と承認に関して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.
上記の段落で説明されている使用法は、増分展開のためにさらに簡素化されます。作成リクエストメッセージを使用して予約されたポリシールールをアクティブにする要件はありません。これは、外部プロキシリクエストメッセージと関連する作成要求メッセージによって完全に処理されます。どちらもローカル認証および承認スキームによって処理されます。
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を指定します。NSIは一般的に、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
o NATFW NSLPメッセージタイプ
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
o NSLPメッセージオブジェクト
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メッセージタイプを追加しました：Create（0x1）、外部（0x2）、応答（0x3）、および通知（0x4）を追加しました。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、Pフラグ（ビット8）とEフラグ（ビット9）の2つのフラグのみが定義されています。各レジストリエントリは、値、ビット位置、説明（セクション番号を含む）、および参照で構成されています。
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.
セクション4.2では、このドキュメントでは、NATFW NSLPの9つのオブジェクトを定義しています。NATFW_LT、NATFW_EXTERNAL_IP、NATFW_EXTERNAL_BINDING、NATFW_EFI、NATFW_INFO、NATFW_NONCE、NATFW_MSN、NATFW_DTINFO、NATFW_ICMP_TYPES。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レビューが必要です。IANAは、エラークラスのセクション4.2.5に記載されているように、およびエラークラスごとの応答値の数についても割り当てています。各レジストリエントリは、応答コード、値、説明、および参照で構成されています。
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）レジストリに1つの新しい値（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;
o Marcus BrunnerとHenning Schulzrinneは、このドキュメントから始めたIETFドキュメントの作業について。
o Miquel Martin for his large contribution on the initial version of this document and one of the first prototype implementations;
o Miquel Martinは、このドキュメントの初期バージョンでの大きな貢献と、最初のプロトタイプ実装の1つについて。
o Srinath Thiruvengadam and Ali Fessi work for their work on the NAT/firewall threats document;
o Srinath ThiruvengadamとAli Fessiは、NAT/Firewallの脅威文書の作業のために働いています。
o Henning Peters for his comments and suggestions;
o 彼のコメントと提案についてヘニングピーターズ。
o Ben Campbell as Gen-ART reviewer;
o Gen-ArtレビュアーとしてのBen Campbell。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Hancock、「Gist：General Internet Signaling Transport」、RFC 5971、2010年10月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982] Elz、R。およびR. Bush、「シリアル番号算術」、RFC 1982、1996年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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] Hancock、R.、Karagiannis、G.、Loughney、J。、およびS. van den Bosch、「シグナルの次のステップ（NSIS）：フレームワーク」、RFC 4080、2005年6月。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726] Brunner、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] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のための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] Sun、D.、McCann、P.、Tschofenig、H.、Tsou、T.、Doria、A。、およびG. Zorn、「直径のサービス品質アプリケーション」、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] MANNER、J.、Bless、R.、Loughney、J。、およびE. Davies、「NSISプロトコルファミリーの使用と拡張」、RFC 5978、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.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communication Architecture and Framework」、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. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、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] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス翻訳全体の一方的な自己アドレス固定（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「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.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、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] Hamer、L-N。、Gage、B.、Kosinski、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] Hamer、L-N。、Gage、B。、およびH. Shieh、「メディア認可とのセットアップのフレームワーク」、RFC 3521、2003年4月。
[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-Firewall] Roedig、U.、Goertz、M.、Karten、M.、およびR. Steinmetz、「RSVP as rsvp as firewall Signaling Protocol」、コンピューターと通信に関する第6回IEEEシンポジウムの議事録、Hammamet、Tunisia、pp。57から62、IEEE Computer Society Press、2001年7月。
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アドレス、つまりデータ送信者またはデータ送信者と受信機の両方の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.
可能な場合は、データ送信者のIPアドレスをSDAとして選択することをお勧めします。データ送信者の受信したIPアドレスを区別する必要があります。一部のアプリケーションレベルのシグナリングプロトコル（SIPなど）には、データ送信者の複数の連絡先IPアドレスを転送する機能があります。たとえば、プライベートIPアドレス、NATでのパブリックIPアドレス、リレーのパブリックIPアドレス。すべての非Private IPアドレスをSDAとして使用することをお勧めします。
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パケットが、エッジナットまたはエッジファイアウォールにルーティングされることが保証されます。
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オブジェクトには、パブリックインターネットを介して到達できるようにNIのアプリケーションで使用できるパブリックIPアドレスと潜在的にポート番号があります。ただし、図35に示すように、さまざまなNISが同じパブリックNATの背後にあるが、マルチレベルのNAT展開の対象となる場合があります。（たとえば、NR1とNR2を含むNI）しかし、可能な限り短い方法があるにもかかわらず、彼らはエッジ・ナットからトラフィックを送ることを余儀なくされています。
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
NI -192.168.0/24-- NAT1--10.0.0.0/8--Nat2インターネット（パブリック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に外部メッセージを送信し、外部アドレスポートバインディングを取得します。その後、彼らはその外部バインディングを交換し、すべてのトラフィックはNAT1によって最短経路をNAT3に直接取るのではなく、NAT2に固定されます。ただし、そのためには、NR1とNIの両方が、それぞれNat1とNat3の外側にアドレスがあることに注意する必要があります。ICEが展開され、実際に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とパブリックインターネットの間にオーバーラップアドレスドメインがある場合、通常のルーティングでは、パケットを適切なドメインに送信する必要がないことに注意してください。
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では、ミドルボックスの背後にあるデータ受信機がインバウンドファイアウォール/NATにNATFW NSLPシグナルを転送するように指示する方法について説明します。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を参照）、データトラフィックをルーティングする特定のファイアウォールを確認する必要があります。。NATFW NSLPのシグナリングメッセージは、NI /NRから送信され、NRに向けて外部メッセージ交換中に送信されます。NTLPにより、データトラフィックによっても渡されるエッジファイアウォールにルーティングする必要があります。NTLPは、DSとDRの間のパスを決定するために、インターネット内のルーティングに注意する必要があります。これから、NTLPは、NATFW NSLPシグナル伝達を転送するために、EDED-FIREWALLSのどれを選択する必要があるかを決定できます。図36に示すように、間違ったエッジファイアウォールへの信号は、間違ったデバイスにNATFW NSLPポリシールールをインストールします。これにより、ブロックされたデータフロー（ポリシールールが「許可」されている場合）または進行中の攻撃（ポリシールールが「拒否」される場合）のいずれかを引き起こします。NTLPにインターネット内のルーティングについてすべてを知るように要求することは間違いなく難しい課題であり、通常は不可能です。説明されている場合、NTLPは基本的にあきらめてNSLPレベルにエラーを返す必要があり、次のホップ発見が不可能であることを示しています。
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バインディングは、自然な方法で説明されています。つまり、一般的な実装で見つける方法で説明されています。
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アドレス、トランスポートレイヤーポート番号、およびIPペイロード（またはIPv6の次のヘッダー）に適用されます。ワイルドカードの処理は、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アドレスが設定されたMRI（ワイルドカードではない）、輸送プロトコルTCP、およびTCPポート番号を完全にワイルドカードします。ローカルポリシーで、すべてのポートが設定され、ワイルドカードではなく設定されたTCPのリクエストのみが許可されている場合、リクエストは拒否されます。
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ポリシールールがファイアウォールルールにマッピングされる方法について説明します。MRIは次のように設定されています。
o network-layer-version=IPv4
o ネットワークレイヤーバージョン= IPv4
o source-address=192.0.2.100, prefix-length=32
o source-address = 192.0.2.100、プレフィックスレングス= 32
o destination-address=192.0.50.5, prefix-length=32
o Destination-Address = 192.0.50.5、プレフィックスレングス= 32
o IP-protocol=UDP
o ip-protocol = udp
o L4-source-port=34543, L4-destination-port=23198
o l4-source-port = 34543、l4-destination-port = 23198
The NATFW_EFI object is set to action=allow and sub_ports=0.
NATFW_EFIオブジェクトは、アクション= aotおよび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.
結果のポリシールール（ファイアウォールルール）は、次のように見えます。
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:
このセクションでは、NSLPポリシールールが外部メッセージで合図された方法がNATバインディングにマッピングされる方法について説明します。外部メッセージは、NATの後ろにあるNIによって送信され、NATFW_DTINFOオブジェクトが含まれていると想定されています。MRIは、実際のデータ送信者のIPアドレスが不明であるため、信号宛先アドレスを使用して後に設定されます。
o network-layer-version=IPv4
o ネットワークレイヤーバージョン= IPv4
o source-address= 192.168.5.100
o Source-Address = 192.168.5.100
o destination-address=SDA
o Destination-Address = SDA
o IP-protocol=UDP
o ip-protocol = udp
The NATFW_EFI object is set to action=allow and sub_ports=0. The NATFW_DTINFO object contains these parameters:
NATFW_EFIオブジェクトは、アクション= aotおよびsub_ports = 0に設定されています。NATFW_DTINFOオブジェクトには、これらのパラメーターが含まれています。
o P=1
o p = 1
o dest prefix=0
o DESTプレフィックス= 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.
Edge-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バインディング）は次のように見えます。UDPを任意の192.0.2.79ポート= 45000から192.168.5.100ポート= 20230に翻訳します。
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に記載されているように、2回ナットの動的構成には、アプリケーションレベルのサポートが必要です。NATFW NSLPは、アプリケーションレベルのサポートが必要な場合、2回ナットの構成には使用できません。このデバイスにインストールされている2回NATとNATFW NSLPの構成を実行するアプリケーションレベルのサポートを仮定すると、NATFW NSLPはそれをトラバースできる必要があります。NSLPは、他のデータトラフィックと同様に、おそらく2回NATを通過することができますが、NTLPのMRIに保存されているフロー情報は、ソースおよび宛先IPアドレスの変換により無効になります。2回NATでのNATFW NSLP実装は、他のNATFW NSLPノードと同様に、NATFW NSLPおよびNTLPシグナリングメッセージを傍受する必要があります。指定されたシグナリングフローの場合、NATFW NSLPノードは、対応するIPアドレス変換を検索し、それに応じてNTLP/NSLPシグナリングを変更する必要があります。この変更により、ソースおよび宛先IPアドレスに関して更新されたMRIが表示されます。
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.
このセクションでは、NATの背後にあるレシーバーにNATFW NLSPを使用する方法についての例を示します。FTPは、実用的な例を表示するアプリケーションとして想定しています。図5に示すように、FTPサーバーはNATの後ろにあり、NATFW NSLPを使用して、FTPプロトコルの制御およびデータチャネルにNATバインディングを割り当てます。サーバーに到達する場所に関する情報は、DS側に別のプロトコル（電子メール、チャットなど）によって通知されます。
Public Internet Private Address
Space
FTP Client FTP Server
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に送信された外部要求メッセージ：シグナリングセッションライフタイム、拡張フロー情報オブジェクト（ルールアクション= Allow、sub_ports = 0）、メッセージシーケンス番号オブジェクト、NonCeオブジェクト（CREATEのNONCEを運ぶ）、およびデータ端末情報オブジェクト（i/p-flags set、sender prefix = 0、protocol = tcp、dr port number = 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).
2. これらのオブジェクトを使用してNIに送信された成功した応答：シグナリングセッションのライフタイム、メッセージシーケンス番号オブジェクト、情報コードオブジェクト（ 'success'：2）、外部アドレスオブジェクト（port = 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).
3. NATは、これらのオブジェクトを使用して、NIに作成を送信します。シグナリングセッションのライフタイム、拡張フロー情報オブジェクト（ルールアクション= aopt、sub_ports = 0）、メッセージシーケンス番号オブジェクト、nonceオブジェクト（（1）からのコピー値付き）;PC-MRM（SRC-IP = A.B.C.D、SRC-PORT = XYZ、DST-IP = NI、DST-PORT = 21、下流）を使用します。
4. Successful RESPONSE sent to NAT, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2).
4. これらのオブジェクトを使用して、NATに送信された成功した応答：シグナリングセッションのライフタイム、メッセージシーケンス番号オブジェクト、情報コードオブジェクト（「成功」：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でのアプリケーションは、外部NATバインディング情報、つまりDSのFTPクライアントに送信します。
6. The FTP client connects the FTP control channel to port=XYZ, IP=a.b.c.d.
6. FTPクライアントは、FTP制御チャネルをport = xyz、ip = a.b.c.dに接続します。
7. The FTP client sends a get command for file X.
7. FTPクライアントは、ファイルXのGETコマンドを送信します。
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. これらのオブジェクトを使用してNATに送信された外部要求メッセージ：シグナリングセッションライフタイム、拡張フロー情報オブジェクト（ルールアクション= Allow、sub_ports = 0）、メッセージシーケンス番号オブジェクト、NonCeオブジェクト（CREATEのNONCEを運ぶ）、およびデータ端末情報オブジェクト（i/p-flags set、sender prefix = 32、protocol = tcp、dr port number = 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).
9. これらのオブジェクトを使用してNIに送信された成功した応答：シグナリングセッションライフタイム、メッセージシーケンス番号オブジェクト、情報コードオブジェクト（ 'success'：2）、外部アドレスオブジェクト（port = 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).
10. NATは、これらのオブジェクトを使用して、NIに作成を送信します。シグナリングセッションのライフタイム、拡張フロー情報オブジェクト（ルールアクション= aopt、sub_ports = 0）、メッセージシーケンス番号オブジェクト、nonceオブジェクト（（1）からのコピー値付き）;PC-MRM（src-ip = a.b.c.d、src-port = foo、dst-ip = ni、dst-port = 20、下流）を使用します。
11. Successful RESPONSE sent to NAT, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2).
11. これらのオブジェクトを使用して、NATに送信された成功した応答：シグナリングセッションのライフタイム、メッセージシーケンス番号オブジェクト、情報コードオブジェクト（「成功」：2）。
12. The FTP server responses with port=FOO and IP=a.b.c.d.
12. port = fooおよびip = a.b.c.dを使用したFTPサーバーの応答
13. The FTP clients connects the data channel to port=FOO and IP=a.b.c.d.
13. FTPクライアントは、データチャネルをport = fooおよびip = A.B.C.Dに接続します。
Authors' Addresses
著者のアドレス
Martin Stiemerling NEC Europe Ltd. and University of Goettingen Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Martin Stiemerling Nec Europe Ltd.およびGoettingen University of Goettingen Kurfuersten-Anlage 36 Heidelberg 69115ドイツ
Phone: +49 (0) 6221 4342 113
EMail: Martin.Stiemerling@neclab.eu
URI: http://www.stiemerling.org
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Cedric Aoun Consultant Paris, France
セドリックAONコンサルタントパリ、フランス
EMail: cedaoun@yahoo.fr
Elwyn Davies Folly Consulting Soham UK
Elwyn Davies Folly Consulting Soham UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com