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
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5973.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 8
1.3. Notes on the Experimental Status . . . . . . . . . . . . . 10
1.4. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10
1.5. General Scenario for NATFW Traversal . . . . . . . . . . . 11
2. Network Deployment Scenarios Using the NATFW NSLP . . . . . . 13
2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13
2.2. NAT with Two Private Networks . . . . . . . . . . . . . . 14
2.3. NAT with Private Network on Sender Side . . . . . . . . . 15
2.4. NAT with Private Network on Receiver Side Scenario . . . . 15
2.5. Both End Hosts behind Twice-NATs . . . . . . . . . . . . . 16
2.6. Both End Hosts behind Same NAT . . . . . . . . . . . . . . 17
2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18
2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 18
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 19
3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 19
3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 20
3.2.1. Signaling for Outbound Traffic . . . . . . . . . . . . 20
3.2.2. Signaling for Inbound Traffic . . . . . . . . . . . . 22
3.2.3. Signaling for Proxy Mode . . . . . . . . . . . . . . . 23
3.2.4. Blocking Traffic . . . . . . . . . . . . . . . . . . . 24
3.2.5. State and Error Maintenance . . . . . . . . . . . . . 24
3.2.6. Message Types . . . . . . . . . . . . . . . . . . . . 25
3.2.7. Classification of RESPONSE Messages . . . . . . . . . 25
3.2.8. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 26
3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 27
3.4. Calculation of Signaling Session Lifetime . . . . . . . . 27
3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 31
3.6. Authentication, Authorization, and Policy Decisions . . . 32
3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 32
3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 32
3.7.2. Reserving External Addresses . . . . . . . . . . . . . 35
3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 43
3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 45
3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 46
3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 48
3.8. Demultiplexing at NATs . . . . . . . . . . . . . . . . . . 53
3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 54
3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 55
4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 55
4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 56
4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 58
4.2.2. External Address Object . . . . . . . . . . . . . . . 58
4.2.3. External Binding Address Object . . . . . . . . . . . 59
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
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）都在互联网上使用了很多年，在可预见的未来它们仍将存在。防火墙用于保护网络免受来自内部网络和Internet的某些类型的攻击，而NAT提供了IP地址空间的虚拟扩展。这两种类型的设备都可能是某些应用程序的障碍，因为它们只允许有限的一组应用程序创建的流量通过它们，通常是那些使用具有相对预定和静态属性的协议（例如，大多数HTTP流量和其他客户机/服务器应用程序）的设备。其他应用程序，如IP电话和大多数其他具有更多动态属性的对等应用程序，创建的流量在没有帮助的情况下无法穿越NAT和防火墙。在实践中，许多应用程序的流量无法通过自主防火墙或NAT，即使它们具有尝试恢复网络透明度的附加功能。
Several solutions to enable applications to traverse such entities have been proposed and are currently in use. Typically, application-level gateways (ALGs) have been integrated with the firewall or NAT to configure the firewall or NAT dynamically. Another approach is middlebox communication (MIDCOM). In this approach, ALGs external to the firewall or NAT configure the corresponding entity via the MIDCOM protocol [RFC3303]. Several other work-around solutions are available, such as Session Traversal Utilities for NAT (STUN) [RFC5389]. However, all of these approaches introduce other problems that are generally hard to solve, such as dependencies on the type of NAT implementation (full-cone, symmetric, etc.), or dependencies on certain network topologies.
已经提出了几种解决方案，使应用程序能够遍历这些实体，目前正在使用。通常，应用程序级网关（ALG）已与防火墙或NAT集成，以动态配置防火墙或NAT。另一种方法是中间箱通信（MIDCOM）。在这种方法中，防火墙或NAT外部的ALG通过MIDCOM协议[RFC3303]配置相应的实体。还有其他几种变通解决方案可用，例如NAT的会话遍历实用程序（STUN）[RFC5389]。然而，所有这些方法都引入了通常难以解决的其他问题，例如依赖于NAT实现的类型（全锥、对称等），或者依赖于某些网络拓扑。
NAT and firewall (NATFW) signaling shares a property with Quality-of-Service (QoS) signaling -- each must reach any device that is on the data path and is involved in (respectively) NATFW or QoS treatment of data packets. This means that for both NATFW and QoS it is convenient if signaling travels path-coupled, i.e., the signaling messages follow exactly the same path that the data packets take. The Resource Reservation Protocol (RSVP) [RFC2205] is an example of a current QoS signaling protocol that is path-coupled. [rsvp-firewall] proposes the use of RSVP as a firewall signaling protocol but does not include NATs.
NAT和防火墙（NATFW）信令与服务质量（QoS）信令共享一个属性——每个都必须到达数据路径上的任何设备，并且（分别）参与数据包的NATFW或QoS处理。这意味着，对于NATFW和QoS而言，如果信令沿着耦合的路径传播，即信令消息遵循与数据分组完全相同的路径，则是方便的。资源预留协议（RSVP）[RFC2205]是路径耦合的当前QoS信令协议的示例。[rsvp 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框架内NAT和防火墙配置的路径耦合信令协议，称为NATFW NSIS信令层协议（NSLP）。一般要求
NSIS are defined in [RFC3726] and the general framework of NSIS is outlined in [RFC4080]. It introduces the split between an NSIS transport layer and an NSIS signaling layer. The transport of NSLP messages is handled by an NSIS Network Transport Layer Protocol (NTLP, with General Internet Signaling Transport (GIST) [RFC5971] being the implementation of the abstract NTLP). The signaling logic for QoS and NATFW signaling is implemented in the different NSLPs. The QoS NSLP is defined in [RFC5974].
NSI的定义见[RFC3726]，NSI的总体框架见[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时，有必要区分两种不同的基本场景，这与要配置的中间盒的类型无关。
1. Both the data sender and data receiver are NSIS NATFW NSLP aware. This includes the cases in which the data sender is logically decomposed from the initiator of the NSIS signaling (the so-called NSIS initiator) or the data receiver logically decomposed from the receiver of the NSIS signaling (the so-called NSIS receiver), but both sides support NSIS. This scenario assumes deployment of NSIS all over the Internet, or at least at all NATs and firewalls. This scenario is used as a base assumption, if not otherwise noted.
1. 数据发送方和数据接收方都支持NSIS NATFW NSLP。这包括数据发送方从NSIS信令的发起方（所谓的NSIS发起方）逻辑分解的情况，或者数据接收方从NSIS信令的接收机（所谓的NSIS接收机）逻辑分解的情况，但是双方都支持NSIS。此场景假设NSI在整个Internet上部署，或者至少在所有NAT和防火墙上部署。如果未另行说明，则将此场景用作基本假设。
2. Only one end host or region of the network is NSIS NATFW NSLP aware, either the data receiver or data sender. This scenario is referred to as proxy mode.
2. 只有一个终端主机或网络区域是NSIS NATFW NSLP感知的，无论是数据接收方还是数据发送方。此场景称为代理模式。
The NATFW NSLP has two basic signaling messages that are sufficient to cope with the various possible scenarios likely to be encountered before and after widespread deployment of NSIS:
NATFW NSLP有两个基本信令消息，足以应对NSI广泛部署前后可能遇到的各种情况：
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响应程序（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.
如果数据接收方位于私有寻址域或防火墙后面，并且需要预配置边缘NAT/边缘防火墙以提供（公开）可访问的地址供数据发送方使用，则使用外部消息和创建消息的组合。
During the introduction of NSIS, it is likely that one or the other of the data sender and receiver will not be NSIS aware. In these cases, the NATFW NSLP can utilize NSIS-aware middleboxes on the path between the data sender and data receiver to provide proxy NATFW NSLP services (i.e., the proxy mode). Typically, these boxes will be at the boundaries of the realms in which the end hosts are located.
在引入NSIS期间，数据发送方和接收方中的一方或另一方可能不知道NSIS。在这些情况下，NATFW NSLP可以利用数据发送方和数据接收方之间路径上的NSIS感知的中间盒来提供代理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
本备忘录的结构如下。第2节描述了NATFW NSLP信令的网络环境。第3节定义了NATFW信令协议，第4节定义了协议中使用的消息组件和整体消息。文件正文的其余部分包括安全考虑第5节，IAB关于单方面自行地址固定的考虑
(UNSAF) [RFC3424] in Section 6, and IANA considerations in Section 7. Please note that readers familiar with firewalls and NATs and their possible location within networks can safely skip Section 2.
（UNSAF）[RFC3424]第6节，IANA考虑因素第7节。请注意，熟悉防火墙和NAT及其在网络中可能的位置的读者可以安全地跳过第2节。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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之间的关联。路径上的所有NATFW NSLP对等方（包括NI和NR）使用相同的标识符来引用为关联存储的状态。同一NI和NR在任何时候都可以有多个信令会话处于活动状态。NATFW NSLP的状态由NSLP状态和位于中间盒的关联策略规则组成。
o Edge-NAT: An edge-NAT is a NAT device with a globally routable IP address that is reachable from the public Internet.
o 边缘NAT：边缘NAT是一种NAT设备，具有可从公共互联网访问的全局可路由IP地址。
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.
术语“中间盒”涵盖一系列设备，并在[RFC3234]中有明确定义：“中间盒定义为在源主机和目标主机之间的数据报路径上执行IP路由器的正常标准功能以外的任何中间设备”。因此，中间盒可分为多个类别，具有广泛的功能，并非所有类别都与NATFW NSLP相关。本备忘录范围内的中间包类别包括根据一组过滤规则过滤数据包的防火墙，以及将数据包地址从一个地址域转换为另一个地址域的NAT。其他类别的中间盒，如QoS流量整形器，不在本备忘录的范围内。
The term "NAT" used in this document is a placeholder for a range of different NAT flavors. We consider the following types of NATs:
本文档中使用的术语“NAT”是一系列不同NAT风格的占位符。我们考虑以下类型的NATS：
o Traditional NAT (basic NAT and NAPT)
o 传统NAT（基本NAT和NAPT）
o Bi-directional NAT
o 双向NAT
o Twice-NAT
o 两次纳特
o Multihomed NAT
o 多宿NAT
For definitions and a detailed discussion about the characteristics of each NAT type, please see [RFC2663].
有关每种NAT类型特征的定义和详细讨论，请参见[RFC2663]。
All types of middleboxes under consideration here use policy rules to make a decision on data packet treatment. Policy rules consist of a flow identifier that selects the packets to which the policy applies and an associated action; data packets matching the flow identifier are subjected to the policy rule action. A typical flow identifier is the 5-tuple selector that matches the following fields of a packet to configured values:
这里考虑的所有类型的中间盒都使用策略规则来决定数据包的处理。策略规则包括选择策略应用到的数据包的流标识符和相关操作；与流标识符匹配的数据包受策略规则操作的约束。典型的流标识符是5元组选择器，它将数据包的以下字段与配置值相匹配：
o Source and destination IP addresses
o 源和目标IP地址
o Transport protocol number
o 传输协议号
o Transport source and destination port numbers
o 传输源和目标端口号
Actions for firewalls are usually one or more of:
防火墙的操作通常是一个或多个：
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.
应该注意的是，中间盒可能包含策略规则的两种逻辑表示形式。策略规则在NATFW NSLP中具有表示，包括NTLP的消息路由信息（MRI）和NSLP信息（例如规则操作）。另一种表示是在特定设备的NAT和防火墙引擎中实现NATFW NSLP策略规则。有关更多详细信息，请参阅附录D。
The purpose of NSIS NATFW signaling is to enable communication between endpoints across networks, even in the presence of NAT and firewall middleboxes that have not been specially engineered to facilitate communication with the application protocols used. This removes the need to create and maintain application layer gateways for specific protocols that have been commonly used to provide transparency in previous generations of NAT and firewall middleboxes. It is assumed that these middleboxes will be statically configured in such a way that NSIS NATFW signaling messages themselves are allowed to reach the locally installed NATFW NSLP daemon. NSIS NATFW NSLP signaling is used to dynamically install additional policy rules in all NATFW middleboxes along the data path that will allow transmission of the application data flow(s). Firewalls are configured to forward data packets matching the policy rule provided by the NSLP signaling. NATs are configured to translate data packets matching the policy rule provided by the NSLP signaling. An additional capability, that is an exception to the primary goal of NSIS NATFW signaling, is that the NATFW nodes can request blocking of particular data flows instead of enabling these flows at inbound firewalls.
NSIS NATFW信令的目的是实现跨网络的端点之间的通信，即使存在NAT和防火墙中间盒，这些中间盒还没有经过专门设计以促进与所使用的应用程序协议的通信。这消除了为特定协议创建和维护应用层网关的需要，这些协议通常用于在前几代NAT和防火墙中间件中提供透明性。假设这些中间盒将以允许NSIS NATFW信令消息本身到达本地安装的NATFW NSLP守护进程的方式进行静态配置。NSIS NATFW NSLP信令用于沿数据路径在所有NATFW中间盒中动态安装额外的策略规则，以允许传输应用程序数据流。防火墙配置为转发与NSLP信令提供的策略规则匹配的数据包。NAT被配置为转换与NSLP信令提供的策略规则匹配的数据包。NSIS NATFW信令主要目标的一个例外是，NATFW节点可以请求阻塞特定数据流，而不是在入站防火墙上启用这些流。
The basic high-level picture of NSIS usage is that end hosts are located behind middleboxes, meaning that there is at least one middlebox on the data path from the end host in a private network to the external network (NATFW in Figure 1). Applications located at these end hosts try to establish communication with corresponding applications on other such end hosts. This communication establishment may require that the applications contact an application server that serves as a rendezvous point between both parties to exchange their IP address and port(s). The local applications trigger the NSIS entity at the local host to control provisioning for middlebox traversal along the prospective data path (e.g., via an API call). The NSIS entity, in turn, uses NSIS NATFW NSLP signaling to establish policy rules along the data path, allowing the data to travel from the sender to the receiver without obstruction.
NSIS使用的基本高级情况是终端主机位于中间箱后面，这意味着从专用网络中的终端主机到外部网络的数据路径上至少有一个中间箱（图1中的NATFW）。位于这些终端主机上的应用程序尝试与其他此类终端主机上的相应应用程序建立通信。此通信建立可能要求应用程序联系作为双方汇合点的应用程序服务器，以交换其IP地址和端口。本地应用程序触发本地主机上的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
+----+ +----+ +----+
| +------------------------+ +------------------------+ |
+-+--+ +----+ +-+--+
| |
| NSIS Entities NSIS Entities |
+-+--+ +----+ +-----+ +-+--+
| +--------+ +----------------------------+ +-----+ |
+-+--+ +-+--+ +--+--+ +-+--+
| | ------ | |
| | //// \\\\\ | |
+-+--+ +-+--+ |/ | +-+--+ +-+--+
| | | | | Internet | | | | |
| +--------+ +-----+ +----+ +-----+ |
+----+ +----+ |\ | +----+ +----+
\\\\ /////
sender NATFW (1+) ------ NATFW (1+) receiver
Note that 1+ refers to one or more NATFW nodes.
请注意，1+表示一个或多个NATFW节点。
Figure 1: Generic View of NSIS with NATs and/or Firewalls
图1：具有NAT和/或防火墙的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。在两台主机之间的路径上，可能有多个NAT和FW以各种可能的组合。第2节介绍了NAT和防火墙不同组合的一些可能场景。但是，以下章节中给出的场景仅为示例，不应视为限制NATFW NSLP的范围。
This section introduces several scenarios for middlebox placement within IP networks. Middleboxes are typically found at various different locations, including at enterprise network borders, within enterprise networks, as mobile phone network gateways, etc. Usually, middleboxes are placed more towards the edge of networks than in network cores. Firewalls and NATs may be found at these locations either alone or combined; other categories of middleboxes may also be found at such locations, possibly combined with the NATs and/or firewalls.
本节介绍在IP网络中放置中间盒的几种方案。中间盒通常位于不同的位置，包括企业网络边界、企业网络内、移动电话网络网关等。通常，中间盒的位置更靠近网络边缘，而不是网络核心。防火墙和NAT可以单独或组合在这些位置；在这些位置还可以找到其他类型的中间盒，可能与NAT和/或防火墙结合使用。
NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the regular data path to the NSIS responder (NR). On the data path, NATFW NSLP signaling messages reach different NSIS nodes that implement the NATFW NSLP. Each NATFW NSLP node processes the signaling messages according to Section 3 and, if necessary, installs policy rules for subsequent data packets.
NSIS启动器（NI）通过常规数据路径向NSIS响应器（NR）发送NSIS NATFW NSLP信令消息。在数据路径上，NATFW NSLP信令消息到达实现NATFW NSLP的不同NSIS节点。每个NATFW NSLP节点根据第3节处理信令消息，并在必要时为后续数据包安装策略规则。
Each of the following sub-sections introduces a different scenario for a different set of middleboxes and their ordering within the topology. It is assumed that each middlebox implements the NSIS NATFW NSLP signaling protocol.
以下每一小节都为不同的一组中间盒及其在拓扑中的顺序介绍了不同的场景。假设每个中间盒实现NSIS NATFW NSLP信令协议。
This section describes a scenario with firewalls only; NATs are not involved. Each end host is behind a firewall. The firewalls are connected via the public Internet. Figure 2 shows the topology. The part labeled "public" is the Internet connecting both firewalls.
本节介绍仅使用防火墙的场景；NAT与此无关。每个终端主机都位于防火墙后面。防火墙通过公共互联网连接。图2显示了拓扑结构。标记为“公共”的部分是连接两个防火墙的互联网。
+----+ //----\\ +----+
NI -----| FW |---| |------| FW |--- NR
+----+ \\----// +----+
+----+ //----\\ +----+
NI -----| FW |---| |------| FW |--- NR
+----+ \\----// +----+
private public private
公私营
FW: Firewall NI: NSIS Initiator NR: NSIS Responder
FW:防火墙NI:NSIS启动器编号：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.
数据路径上的每个防火墙必须为NATFW NSLP提供遍历服务，以便允许NSIS消息到达另一个终端主机。所有防火墙都处理NSIS信令，并建立适当的策略规则，以便所需的数据包流能够遍历它们。
There are several very different ways to place firewalls in a network topology. To distinguish firewalls located at network borders, such as administrative domains, from others located internally, the term edge-firewall is used. A similar distinction can be made for NATs, with an edge-NAT fulfilling the equivalent role.
在网络拓扑中放置防火墙有几种非常不同的方法。为了区分位于网络边界（如管理域）的防火墙与位于内部的其他防火墙，使用了术语边缘防火墙。NAT也有类似的区别，边缘NAT扮演着同等的角色。
Figure 3 shows a scenario with NATs at both ends of the network. Therefore, each application instance, the NSIS initiator and the NSIS responder, are behind NATs. The outermost NAT, known as the edge-NAT (MB2 and MB3), at each side is connected to the public Internet. The NATs are generically labeled as MBX (for middlebox No. X), since those devices certainly implement NAT functionality, but can implement firewall functionality as well.
图3显示了网络两端都有NAT的场景。因此，每个应用程序实例（NSIS启动器和NSIS响应程序）都位于NAT之后。每侧最外层的NAT称为边缘NAT（MB2和MB3），连接到公共互联网。NAT通常被标记为MBX（用于第X号中间包），因为这些设备肯定实现了NAT功能，但也可以实现防火墙功能。
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中每侧仅显示了两个中间箱（MBs），但一般而言，必须考虑每侧的任何MBs数量。
+----+ +----+ //----\\ +----+ +----+
NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR
+----+ +----+ \\----// +----+ +----+
+----+ +----+ //----\\ +----+ +----+
NI --| MB1|-----| MB2|---| |---| MB3|-----| MB4|--- NR
+----+ +----+ \\----// +----+ +----+
private public private
公私营
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB:Middlebox NI:NSIS启动器编号：NSIS响应程序
Figure 3: NAT with two Private Networks Scenario
图3：具有两个专用网络的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.
此场景显示发送节点上位于一个或多个NAT后面的应用程序实例（显示为通用MB，请参阅第2.2节中的讨论）。接收器位于公共互联网上。
+----+ +----+ //----\\
NI --| MB |-----| MB |---| |--- NR
+----+ +----+ \\----//
+----+ +----+ //----\\
NI --| MB |-----| MB |---| |--- NR
+----+ +----+ \\----//
private public
公私合营
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB:Middlebox NI:NSIS启动器编号：NSIS响应程序
Figure 4: NAT with Private Network on Sender Side
图4：在发送方端使用专用网络的NAT
The traffic from NI to NR has to traverse middleboxes only on the sender's side. The receiver has a public IP address. The NI sends its signaling message directly to the address of the NSIS responder. Middleboxes along the path intercept the signaling messages and configure accordingly.
从NI到NR的流量必须仅通过发送方一侧的中间箱。接收方有一个公共IP地址。NI将其信令消息直接发送到NSIS响应程序的地址。路径上的中间盒拦截信令消息并进行相应配置。
The data sender does not necessarily know whether or not the receiver is behind a NAT; hence, it is the receiving side that has to detect whether or not it is behind a NAT.
数据发送方不一定知道接收方是否在NAT后面；因此，接收侧必须检测它是否在NAT后面。
The application instance receiving data is behind one or more NATs shown as MB (see discussion in Section 2.2).
接收数据的应用程序实例位于一个或多个显示为MB的NAT后面（请参阅第2.2节中的讨论）。
//----\\ +----+ +----+
NI ---| |---| MB |-----| MB |--- NR
\\----// +----+ +----+
//----\\ +----+ +----+
NI ---| |---| MB |-----| MB |--- NR
\\----// +----+ +----+
public private
公私合营
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB:Middlebox NI:NSIS启动器编号：NSIS响应程序
Figure 5: NAT with Private Network on Receiver Scenario
图5：在接收器上使用专用网络的NAT场景
Initially, the NSIS responder must determine its publicly reachable IP address at the external middlebox and notify the NSIS initiator about this address. One possibility is that an application-level
最初，NSIS响应程序必须在外部中间盒上确定其可公开访问的IP地址，并将此地址通知NSIS启动器。一种可能性是应用程序级别
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.
使用协议，这意味着通过该协议向NI发送公共IP地址信号。之后，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).
这是一种特殊情况，主要问题是需要检测两个终端主机在逻辑上位于同一地址空间内，但也位于两次NAT两侧的地址域的两个分区中（有关两次NAT功能的讨论，请参阅[RFC2663]）。
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.
发送方和接收方都在一个私有地址域中，但这两个分区可能具有重叠的IP地址范围。图6显示了NAT的安排。
public
平民的
+----+ +----+ //----\\
NI --| MB |--+--| MB |---| |
+----+ | +----+ \\----//
|
| +----+
+--| MB |------------ NR
+----+
+----+ +----+ //----\\
NI --| MB |--+--| MB |---| |
+----+ | +----+ \\----//
|
| +----+
+--| MB |------------ NR
+----+
private
私有的
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB:Middlebox NI:NSIS启动器编号：NSIS响应程序
Figure 6: NAT to Public, Sender and Receiver on Either Side of a Twice-NAT Scenario
图6：两次NAT场景两侧的NAT到公共、发送方和接收方
The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP addresses and port numbers on both sides, meaning the mapping of source and destination IP addresses at the private and public interfaces.
图6中所示的中间盒是两个NAT，即它们在两侧映射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
此场景需要应用程序级实体（如DNS服务器）的协助。应用程序级实体必须处理基于符号名称的请求，并配置中间盒，以便数据包从NI正确转发到NI
NR. The configuration of those middleboxes may require other middlebox communication protocols, such as MIDCOM [RFC3303]. NSIS signaling is not required in the twice-NAT only case, since middleboxes of the twice-NAT type are normally configured by other means. Nevertheless, NSIS signaling might be useful when there are also firewalls on the path. In this case, NSIS will not configure any policy rule at twice-NATs, but will configure policy rules at the firewalls on the path. The NSIS signaling protocol must be at least robust enough to survive this scenario. This requires that twice-NATs must implement the NATFW NSLP also and participate in NATFW signaling sessions, but they do not change the configuration of the NAT, i.e., they only read the address mapping information out of the NAT and translate the Message Routing Information (MRI, [RFC5971]) within the NSLP and NTLP accordingly. For more information, see Appendix D.4.
NR.这些中间箱的配置可能需要其他中间箱通信协议，如MIDCOM[RFC3303]。在仅两次NAT的情况下不需要NSIS信令，因为两次NAT类型的中间盒通常通过其他方式配置。然而，当路径上也有防火墙时，NSIS信令可能很有用。在这种情况下，NSIS不会在两次NAT上配置任何策略规则，而是在路径上的防火墙上配置策略规则。NSIS信令协议必须至少足够健壮，才能在这种情况下生存。这要求两次NAT也必须实现NATFW NSLP并参与NATFW信令会话，但它们不会改变NAT的配置，即，它们只从NAT中读取地址映射信息，并相应地转换NSLP和NTLP中的消息路由信息（MRI，[RFC5971]）。有关更多信息，请参见附录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地址发送信令消息。在此过程中，将在与响应程序相同的中间盒处为NSIS启动器分配公共IP地址。现在，NSIS信令和后续数据包将两次穿越NAT：从发起方到响应方的公共IP地址（第一次）和从响应方的公共IP地址到响应方（第二次）。
NI public
\ +----+ //----\\
+-| MB |----| |
/ +----+ \\----//
NR
private
NI public
\ +----+ //----\\
+-| MB |----| |
/ +----+ \\----//
NR
private
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB:Middlebox NI:NSIS启动器编号：NSIS响应程序
Figure 7: NAT to Public, Both Hosts behind Same NAT
图7:NAT-to-Public，同一NAT后面的两个主机
The previous sub-sections sketched network topologies where several NATs and/or firewalls are ordered sequentially on the path. This section describes a multihomed scenario with two NATs placed on alternative paths to the public network.
前面的小节概述了网络拓扑，其中几个NAT和/或防火墙在路径上顺序排列。本节描述了一个多宿场景，其中两个NAT位于公共网络的备选路径上。
+----+ //---\\
NI -------| MB |---| |
\ +----+ \\-+-//
\ |
\ +----- NR
\ |
\ +----+ //-+-\\
--| MB |---| |
+----+ \\---//
+----+ //---\\
NI -------| MB |---| |
\ +----+ \\-+-//
\ |
\ +----- NR
\ |
\ +----+ //-+-\\
--| MB |---| |
+----+ \\---//
private public
公私合营
MB: Middlebox NI: NSIS Initiator NR: NSIS Responder
MB:Middlebox NI:NSIS启动器编号：NSIS响应程序
Figure 8: Multihomed Network with Two NATs
图8：具有两个NAT的多宿网络
Depending on the destination, either one or the other middlebox is used for the data flow. Which middlebox is used, depends on local policy or routing decisions. NATFW NSLP must be able to handle this situation properly, see Section 3.7.2 for an extended discussion of this topic with respect to NATs.
根据目的地的不同，数据流使用一个或另一个中间盒。使用哪种中间盒取决于本地策略或路由决定。NATFW NSLP必须能够正确处理这种情况，参见第3.7.2节，了解关于NAT的本主题的扩展讨论。
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).
本节描述了一个多宿场景，其中两个防火墙位于公共网络的备选路径上（图9）。专用网络和公用网络中的路由决定了数据流采用哪个防火墙。根据数据流的方向（出站或入站），可以穿越不同的防火墙。这对NATFW NSLP的外部消息是一个挑战，其中NSIS响应程序位于专用网络内这些防火墙的后面。外部消息用于阻止入站防火墙上的特定数据流。NSI必须将入站外部消息从NR路由到NI，可能不知道数据流量将从NI路由到NR（另见附录C）。
+----+
NR -------| FW |\
\ +----+ \ //---\\
\ -| |-- NI
\ \\---//
\ +----+ |
--| FW |-------+
+----+
private
+----+
NR -------| FW |\
\ +----+ \ //---\\
\ -| |-- NI
\ \\---//
\ +----+ |
--| FW |-------+
+----+
private
private public
公私合营
FW: Firewall NI: NSIS Initiator NR: NSIS Responder
FW:防火墙NI:NSIS启动器编号：NSIS响应程序
Figure 9: Multihomed Network with Two Firewalls
图9：具有两个防火墙的多宿网络
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
NATFW NSLP与NTLP的消息路由信息（MRI）一起携带要安装在NATFW对等点上的策略规则。此策略规则是相对于要安装在相应防火墙或NAT上的实际策略规则的抽象。它传递发起者的请求，并且必须映射到所使用的特定NAT和/或防火墙上的可能配置。对于纯防火墙，必须创建一个或多个过滤规则，对于纯NAT，必须创建一个或多个NAT绑定。在混合防火墙和NAT框中，策略规则必须映射到过滤器规则和绑定，以观察防火墙和NAT引擎的顺序。根据订购情况，NAT在防火墙之前还是在防火墙之前
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.
反之亦然，防火墙规则必须包含公共或私有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为策略规则指定了两个操作：拒绝和允许。操作设置为deny的策略规则将导致丢弃与此规则匹配的所有数据包。操作设置为“允许”的策略规则将导致转发与此规则匹配的所有数据包。
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响应器（NR）接收。要求至少NI和NR实现此NSLP，中间NFs仅在提供相关中间盒功能时才实现此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).
打算向数据接收器（DR）发送数据的数据发送器（DS）必须启动NATFW NSLP信令。这导致与DS相关联的NI向DR地址发送NSLP信令（见图10）。虽然预期DS和NATFW NSLP NI通常位于同一主机上，但本规范不排除DS和NI位于不同主机上的情况，即所谓的代理模式（见第3.7.6节）。
+-------+ +-------+ +-------+ +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR |
| |--->| NF1 |--->| NF2 |--->| |
+-------+ +-------+ +-------+ +-------+
+-------+ +-------+ +-------+ +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR |
| |--->| NF1 |--->| NF2 |--->| |
+-------+ +-------+ +-------+ +-------+
========================================>
Data Traffic Direction (outbound)
========================================>
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
---> : 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.
下表显示了NSLP事件的正常顺序，但没有详细说明与NTLP的交互以及NTLP级别的交互。
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 每次遍历具有NATFW NSLP支持的NF时，都会处理NSLP请求消息。正在拦截请求消息并接受其进一步处理的每个NF正在加入特定的NATFW NSLP信令会话。这些节点处理消息，检查本地策略的授权和身份验证，可能创建策略规则，并将信令消息转发给下一个NSIS节点。请求消息被转发，直到它到达NSIS响应程序。
o NSIS responders will check received messages and process them if applicable. NSIS responders generate RESPONSE messages and send them hop-by-hop back to the NI via the same chain of NFs (traversal of the same NF chain is guaranteed through the established reverse message routing state in the NTLP). The NR is also joining the NATFW NSLP signaling session if the request message is accepted.
o NSIS响应者将检查收到的消息，并在适用时对其进行处理。NSIS响应者生成响应消息，并通过相同的NFs链逐跳地将其发送回NI（通过NTLP中建立的反向消息路由状态，可以保证遍历相同的NF链）。如果请求消息被接受，则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会话以CREATE消息启动，则数据发送方可以开始将其数据流发送到数据接收方。如果NI接收到成功的响应消息，并且如果信令NATFW NSLP会话以外部消息启动，则数据接收器准备接收进一步的CREATE消息。
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地址发送信号。使用NR的专用地址无法从其他NIs访问DR/NR，因此NATFW信令消息无法发送到NR/DR的地址。因此，NR必须首先获得NAT绑定，该绑定提供NI可以访问的地址。一旦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
1. DR通过反向路径（DR到DS）上的信令获取公共地址，从而使其自身可供其他主机使用。获取公共地址的过程称为预约。在此过程中，DR会保留可公开访问的地址和端口，以便在应用程序级别进一步使用
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.
信令和用于进一步NATFW NSLP信令的公共可到达地址。但是，最初不允许数据通信使用此地址/端口（请参阅下一点）。在保留过程中，DR成为获取可公开访问的IP地址所需的消息的NI，即，该特定NATFW NSLP信令会话的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地址用作NR的地址，就像NI在中间没有NAT时所做的那样，并在中间盒上创建策略规则。注意，保留将只允许转发信令消息，而不允许转发数据流数据包。当使用肯定响应消息确认从NI到NR的信令时，将激活允许转发由先前外部消息信令设置的数据流分组的策略规则。第3.7.2节描述了外部信息。
administrative domain
----------------------------------\
|
+-------+ +-------+ +-------+ | +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ | | | DR |
| |--->| NF1 |--->| NR | | | |
+-------+ +-------+ +-------+ | +-------+
|
----------------------------------/
administrative domain
----------------------------------\
|
+-------+ +-------+ +-------+ | +-------+
| DS/NI |<~~~| MB1/ |<~~~| MB2/ | | | DR |
| |--->| NF1 |--->| NR | | | |
+-------+ +-------+ +-------+ | +-------+
|
----------------------------------/
========================================>
Data Traffic Direction (outbound)
========================================>
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
---> : 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
上述用法假设通信的两端都支持NSI，但如果NSI仅部署在路径的一端，则会失败。在这种情况下，只有发送端（见图11）或接收端（见图12）中的一个能够感知NSIS，而不是同时感知两者
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.
时间NATFW NSLP通过使用代理模式支持两种方案（即DS或DR不支持NSI），如第3.7.6节所述。
administrative domain
/ ----------------------------------
|
+-------+ | +-------+ +-------+ +-------+
| DS | | | MB2/ |~~~>| MB1/ |~~~>| DR |
| | | | NR |<---| NF1 |<---| |
+-------+ | +-------+ +-------+ +-------+
|
\----------------------------------
administrative domain
/ ----------------------------------
|
+-------+ | +-------+ +-------+ +-------+
| DS | | | MB2/ |~~~>| MB1/ |~~~>| DR |
| | | | NR |<---| NF1 |<---| |
+-------+ | +-------+ +-------+ +-------+
|
\----------------------------------
========================================>
Data Traffic Direction (inbound)
========================================>
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
---> : 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会话不匹配的所有流量。但是，有些场景需要支持具有“allow all”策略的防火墙，允许数据流量穿越防火墙，除非它被明确阻止。数据接收方可以利用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 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,translate error, please retry
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:
该协议使用四种消息类型：
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信令会话的请求消息。外部消息被转发到边缘NAT或边缘防火墙，并允许入站创建消息转发到NR。此外，外部消息在边缘NAT保留外部地址和端口号（如果适用）。
o NOTIFY: an asynchronous message used by NATFW peers to alert other NATFW peers about specific events (especially failures).
o NOTIFY：NATFW对等方使用的异步消息，用于向其他NATFW对等方通知特定事件（尤其是故障）。
o RESPONSE: used as a response to CREATE and EXTERNAL request messages.
o 响应：用作创建和外部请求消息的响应。
RESPONSE messages will be generated synchronously to CREATE and EXTERNAL messages by NSLP forwarders and responders to report success or failure of operations or some information relating to the NATFW NSLP signaling session or a node. RESPONSE messages MUST NOT be generated for any other message, such as NOTIFY and RESPONSE.
响应消息将由NSLP转发器和响应器同步生成，以创建和外部消息，以报告操作的成功或失败，或与NATFW NSLP信令会话或节点相关的一些信息。不得为任何其他消息（如NOTIFY和RESPONSE）生成响应消息。
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_信息对象，该对象包含一个错误类别代码和一个响应代码（见第4.2.5节）。本节根据错误类别定义响应消息组的术语。
o Successful RESPONSE: Messages carrying NATFW_INFO with error class 'Success' (2).
o 成功响应：携带NATFW_信息的消息，错误类别为“Success”（2）。
o Informational RESPONSE: Messages carrying NATFW_INFO with error class 'Informational' (1) (only used with NOTIFY messages).
o 信息性响应：携带NATFW_信息的消息，错误类别为“信息性”（1）（仅用于通知消息）。
o Error RESPONSE: Messages carrying NATFW_INFO with error class other than 'Success' or 'Informational'.
o 错误响应：包含NATFW_信息且错误类别不是“成功”或“信息”的消息。
A NATFW NSLP signaling session defines an association between the NI, NFs, and the NR related to a data flow. This association is created when the initial CREATE or EXTERNAL message is successfully received at the NFs or the NR. There is signaling NATFW NSLP session state stored at the NTLP layer and at the NATFW NSLP level. The NATFW NSLP signaling session state for the NATFW NSLP comprises NSLP state and the associated policy rules at a middlebox.
NATFW NSLP信令会话定义与数据流相关的NI、NFs和NR之间的关联。此关联是在NFs或NR成功接收到初始创建或外部消息时创建的。NTLP层和NATFW NSLP级别上存储有信令NATFW NSLP会话状态。NATFW NSLP的NATFW NSLP信令会话状态包括NSLP状态和中间盒处的相关策略规则。
The NATFW NSLP signaling session is identified by the session ID (plus other information at the NTLP level). The session ID is generated by the NI before the initial CREATE or EXTERNAL message is sent. The value of the session ID MUST be generated as a cryptographically random number (see [RFC4086]) by the NI, i.e., the output MUST NOT be easily guessable by third parties. The session ID is not stored in any NATFW NSLP message but passed on to the NTLP.
NATFW NSLP信令会话由会话ID（加上NTLP级别的其他信息）标识。会话ID由NI在发送初始创建或外部消息之前生成。会话ID的值必须由NI以加密随机数的形式生成（请参见[RFC4086]），即，第三方不能轻易猜测输出。会话ID不存储在任何NATFW NSLP消息中，而是传递给NTLP。
A NATFW NSLP signaling session has several conceptual states that describe in what state a signaling session is at a given time. The signaling session can have these states at a node:
NATFW NSLP信令会话具有多个概念状态，这些状态描述了信令会话在给定时间处于何种状态。信令会话可以在节点处具有以下状态：
o Pending: The NATFW NSLP signaling session has been created and the node is waiting for a RESPONSE message to the CREATE or EXTERNAL message. A NATFW NSLP signaling session in state 'Pending' MUST be marked as 'Dead' if no corresponding RESPONSE message has been received within the time of the locally granted NATFW NSLP signaling session lifetime of the forwarded CREATE or EXTERNAL message (as described in Section 3.4).
o 挂起：NATFW NSLP信令会话已创建，节点正在等待对创建或外部消息的响应消息。如果在转发的创建或外部消息的本地授予的NATFW NSLP信令会话生存期内（如第3.4节所述），没有收到相应的响应消息，则处于“挂起”状态的NATFW NSLP信令会话必须标记为“死”。
o Established: The NATFW NSLP signaling session is established, i.e, the signaling has been successfully performed and the lifetime of NATFW NSLP signaling session is counted from now on. A NATFW NSLP signaling session in state 'Established' MUST be marked as 'Dead' if no refresh message has been received within the time of the locally granted NATFW NSLP signaling session lifetime of the RESPONSE message (as described in Section 3.4).
o 已建立：NATFW NSLP信令会话已建立，即信令已成功执行，从现在开始计算NATFW NSLP信令会话的生存期。如果在响应消息的本地授权NATFW NSLP信令会话生存期内（如第3.4节所述）未收到任何刷新消息，则处于“已建立”状态的NATFW NSLP信令会话必须标记为“死”。
o Dead: Either the NATFW NSLP signaling session is timed out or the node has received an error RESPONSE message for the NATFW NSLP signaling session and the NATFW NSLP signaling session can be deleted.
o 死：NATFW NSLP信令会话超时，或者节点已收到NATFW NSLP信令会话的错误响应消息，并且可以删除NATFW NSLP信令会话。
o Transitory: The node has received an asynchronous message, i.e., a NOTIFY, and can delete the NATFW NSLP signaling session if needed after some time. When a node has received a NOTIFY message, it marks the signaling session as 'Transitory'. This signaling session SHOULD NOT be deleted before a minimum hold time of 30 seconds, i.e., it can be removed after 30 seconds or more. This hold time ensures that the existing signaling session can be reused by the NI, e.g., a part of a signaling session that is not affected by the route change can be reused once the updating request message is received.
o 暂时性：节点已收到一条异步消息，即通知，如果需要，在一段时间后可以删除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）类代码的相应错误的响应消息。例如，当节点接收到保留标志设置为非零值的消息时，会出现可恢复错误。根据第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
NATFW NSLP信令会话以及可能已安装的相应策略规则通过软状态机制进行维护。每个信令会话被分配一个信令会话
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节点上处理。NSLP转发器和NSLP响应器不得触发信令会话生存期延长刷新消息（参见第3.7.3节）：这是NSIS启动器的任务。
The NSIS initiator MUST choose a NATFW NSLP signaling session lifetime value (expressed in seconds) before sending any message, including the initial message that creates the NATFW NSLP signaling session, to other NSLP nodes. It is RECOMMENDED that the NATFW NSLP signaling session lifetime value is calculated based on:
NSIS启动器在向其他NSLP节点发送任何消息（包括创建NATFW NSLP信令会话的初始消息）之前，必须选择NATFW NSLP信令会话生存期值（以秒为单位）。建议根据以下公式计算NATFW NSLP信令会话生存期值：
o the number of lost refresh messages with which NFs should cope;
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]）导致的网络漏洞，当NI未明确移除NATFW NSLP信令会话时，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:
RSVP规范[RFC2205]提供了计算NATFW NSLP信令会话生存期的适当算法，以及避免NATFW NSLP信令会话之间刷新消息同步的方法。[RFC2205]建议：
1. The refresh message timer to be randomly set to a value in the range [0.5R, 1.5R].
1. 将刷新消息计时器随机设置为[0.5R，1.5R]范围内的值。
2. To avoid premature loss of state, lt (with lt being the NATFW NSLP signaling session lifetime) must satisfy lt >= (K + 0.5)*1.5*R, where K is a small integer. Then, in the worst case, K-1 successive messages may be lost without state being deleted. Currently, K = 3 is suggested as the default. However, it may be necessary to set a larger K value for hops with high loss rate. Other algorithms could be used to define the relation between the NATFW NSLP signaling session lifetime and the refresh message period; the algorithm provided is only given as an example.
2. 为了避免过早丢失状态，lt（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).
建议使用300秒（5分钟）的刷新计时器，除非NI或NI的请求应用程序有其他要求（例如，持续时间很短的流）。
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信令会话生存期值太大，并且在拒绝时必须生成“信令会话失败”（7）类的错误响应消息，响应代码为“请求的生存期太大”（0x02）。最好降低生存期，而不是生成错误消息。
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信令会话生存期值太小，并且在拒绝时必须生成“信令会话失败”（7）类的错误响应消息，响应代码为“请求的生存期太小”（0x10）。
NFs or the NR MUST NOT increase the NATFW NSLP signaling session lifetime value. Messages can be rejected on the basis of the NATFW NSLP signaling session lifetime being too long when a NATFW NSLP signaling session is first created and also on refreshes.
NFs或NR不得增加NATFW NSLP信令会话生存期值。当首次创建NATFW NSLP信令会话时，由于NATFW NSLP信令会话生存期太长，以及刷新时，可能会拒绝消息。
The NSLP responder generates a successful RESPONSE for the received CREATE or EXTERNAL message, sets the NATFW NSLP signaling session lifetime value in the NATFW_LT object to the above granted lifetime and sends the message back towards NSLP initiator.
NSLP响应程序为接收到的CREATE或EXTERNAL消息生成成功响应，将NATFW_LT对象中的NATFW NSLP信令会话生存期值设置为上述授予的生存期，并将消息发送回NSLP启动器。
Each NSLP forwarder processes the RESPONSE message and reads and stores the granted NATFW NSLP signaling session lifetime value. The forwarders MUST accept the granted NATFW NSLP signaling session lifetime, if the lifetime value is within the acceptable range. The acceptable value refers to the value accepted by the NSLP forwarder when processing the CREATE or EXTERNAL message. For received values greater than the acceptable value, NSLP forwarders MUST generate a RESPONSE message of class 'Signaling session failure' (7) with response code 'Modified lifetime is too big' (0x11), including a Signaling Session Lifetime object that carries the maximum acceptable signaling session lifetime for this node. For received values lower than the values acceptable by the node local policy, NSLP forwarders MUST generate a RESPONSE message of class 'Signaling session failure' (7) with response code 'Modified lifetime is too small' (0x12), including a Signaling Session Lifetime object that carries the minimum acceptable signaling session lifetime for this node. In both cases, either 'Modified lifetime is too big' (0x11) or 'Modified lifetime is too small' (0x12), the NF MUST generate a NOTIFY message and send it outbound with the error class set to 'Informational' (1) and with the response code set to 'NATFW signaling session terminated' (0x05).
每个NSLP转发器处理响应消息，并读取和存储授予的NATFW NSLP信令会话生存期值。如果生存期值在可接受范围内，则转发器必须接受授予的NATFW NSLP信令会话生存期。可接受值是指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以一个示例显示了该过程，其中启动器在CREATE消息中请求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)+--------+
+-------+ CREATE(lt=60s) +-------------+ CREATE(lt=20s) +--------+
| |---------------->| NSLP |---------------->| |
| NI | | forwarder | | NR |
| |<----------------| check 15<20 |<----------------| |
+-------+ RESPONSE(lt=15s)+-------------+ RESPONSE(lt=15s)+--------+
lt = lifetime
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节点都应该能够识别以前收到（复制）或丢失（丢失）的消息。对于消息重播保护，有必要保留有关已接收消息的信息，并要求每个NATFW NSLP消息携带消息序列号（MSN），另请参见第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的初始值必须随机生成，并且必须仅在使用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信令会话的初始创建或外部数据包中的MSN存储为NATFW NSLP信令会话的起始值。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.
当接收到CREATE或EXTERNAL消息时，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节点必须生成“永久故障”（0x5）类的错误响应，响应代码为“身份验证失败”（0x01），或响应代码为“授权失败”（0x02）。
The NATFW NSLP is expected to run in various environments, such as IP-based telephone systems, enterprise networks, home networks, etc. The requirements on authentication and authorization are quite different between these use cases. While a home gateway, or an Internet cafe, using NSIS may well be happy with a "NATFW signaling coming from inside the network" policy for authorization of signaling, enterprise networks are likely to require more strongly authenticated/authorized signaling. This enterprise scenario may require the use of an infrastructure and administratively assigned identities to operate the NATFW NSLP.
NATFW NSLP预计将在各种环境中运行，如基于IP的电话系统、企业网络、家庭网络等。这些用例之间对身份验证和授权的要求大不相同。虽然使用NSIS的家庭网关或网吧很可能对用于信令授权的“来自网络内部的NATFW信令”策略感到满意，但企业网络可能需要更强的认证/授权信令。此企业场景可能需要使用基础设施和管理分配的标识来操作NATFW NSLP。
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
NATFW NSLP通过使用CREATE消息实现了允许两台主机即使在存在中间盒的情况下也交换数据。NI（数据发送方或代理）生成第4.3.1节中定义的创建消息，并将其交给NTLP。NTLP根据消息转发整个消息
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).
朝向NR的路由信息（MRI）。沿实现NATFW NSLP的路径的每个NSLP转发器处理NSLP消息。转发是逐跳完成的，但可以透明地通过NSLP转发器传递，NSLP转发器不包含NATFW NSLP功能和NSLP跳跃路径点之间的非NSIS感知路由器。当消息到达NR时，NR可以接受或拒绝请求。NR生成要创建的响应，该响应逐跳传输到NI。NATFW NSLP转发器可随时拒绝请求。图14描绘了NI（本例中为DS）、NF（如NAT）和NR（本例中为DR）之间的消息流。
NI Private Network NF Public Internet NR
| | |
| CREATE | |
|----------------------------->| |
| | |
| | |
| | CREATE |
| |--------------------------->|
| | |
| | RESPONSE |
| RESPONSE |<---------------------------|
|<-----------------------------| |
| | |
| | |
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:
生成和接收CREATE消息时，NATFW对等方有若干处理规则，因为此消息类型用于创建新的NATFW NSLP信令会话、更新现有会话、延长生存期和删除NATFW NSLP信令会话。后三种功能对所有类型的CREATE消息的操作方式相同，因此在单独的章节中进行了描述：
o Extending the lifetime of NATFW NSLP signaling sessions is described in Section 3.7.3.
o 第3.7.3节描述了延长NATFW NSLP信令会话的生存期。
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:
对于创建新NATFW NSLP信令会话的初始创建消息，对于每个NATFW节点类型，创建消息的处理是不同的：
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.
o NSLP启动器：NI只生成CREATE消息并将其交给NTLP。NI不应接收CREATE消息，必须丢弃它们。
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）的错误响应，响应代码为“未到达NR”（0x07）。如果NTLP层无法找到NATFW NSLP对等方（另一个NF或NR），并且通过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节）查找预先作出的预订。匹配过程考虑接收到的MRI信息和存储的MRI信息，如第3.8节所述。如果找不到匹配的保留，即事先没有进行任何保留，NSLP必须返回“信令会话失败”（7）类的错误响应，响应代码为“找不到与创建请求的MRI匹配的保留”（0x03）。如果存在匹配的保留，NSLP将数据发送者的地址（以及如果适用的端口号）存储为要加载的策略规则（“记住的策略规则”）的源IP地址的一部分，并将设置了目标IP地址的消息转发到内部（在大多数情况下为专用）NR的地址。当在专用端收到初始创建消息时，分配NAT绑定，但未激活（另见附录D.3）。如果无法立即保留请求的策略规则，则生成“信令会话失败”（7）类的错误响应消息，响应代码为“由于策略冲突而拒绝请求的策略规则”（0x4）。MRI信息会更新，以反映地址以及（如果适用）端口翻译。NSLP消息被转发到NR，源IP地址从新记住的绑定设置为NAT的外部地址。
* 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），响应代码为“由于策略冲突而拒绝请求的策略规则”（0x4）。
* Combined NAT and firewall: Processing at combined firewall and NAT middleboxes is the same as in the NAT case. No policy rules are installed. Implementations MUST take into account
* 组合NAT和防火墙：组合防火墙和NAT中间盒的处理与NAT情况相同。未安装任何策略规则。实现时必须考虑
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功能。这将被称为“功能顺序”，通常根据数据包是到达中间盒的外部还是内部而有所不同。
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如果接受创建消息，则必须使用“成功”（2）类的成功响应进行回复，且响应代码设置为“所有已成功处理”（0x01）。否则，它们必须生成带有适当响应代码的响应消息。无论响应代码是成功还是错误，响应消息都会逐跳向NI发回NSLP。
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的相应成功响应消息时，才能在中间盒中安装记住的策略规则。这是解决几个问题的一种对策，例如，当CREATE消息由于某种原因未达到最终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转发器：如果收到具有匹配SID的成功响应消息，NFs将安装记住的策略规则。如果收到具有匹配SID的错误响应消息，则NATFW NSLP会话将标记为“已死亡”，不会安装任何策略规则，并且会丢弃记住的规则。
o NSIS responder: The NR should never receive RESPONSE messages and MUST silently drop any such messages received.
o NSIS响应程序：NR永远不应该接收响应消息，并且必须以静默方式删除接收到的任何此类消息。
NFs and the NR can also tear down the CREATE session at any time by generating a NOTIFY message with the appropriate response code set.
NFs和NR还可以通过生成带有相应响应代码集的NOTIFY消息，随时中断CREATE会话。
NSIS signaling is intended to travel end-to-end, even in the presence of NATs and firewalls on-path. This works well in cases where the data sender is itself behind a NAT or a firewall as described in Section 3.7.1. For scenarios where the data receiver is located
NSIS信令旨在端到端传输，即使在路径上存在NAT和防火墙的情况下也是如此。如第3.7.1节所述，这在数据发送方自身位于NAT或防火墙后面的情况下效果良好。对于数据接收器所在的场景
behind a NAT or a firewall and it needs to receive data flows from outside its own network (usually referred to as inbound flows, see Figure 5), the problem is more troublesome.
在NAT或防火墙后面，它需要从自己的网络外部接收数据流（通常称为入站流，见图5），问题更麻烦。
NSIS signaling, as well as subsequent data flows, are directed to a particular destination IP address that must be known in advance and reachable. Data receivers must tell the local NSIS infrastructure (i.e., the inbound firewalls/NATs) about incoming NATFW NSLP signaling and data flows before they can receive these flows. It is necessary to differentiate between data receivers behind NATs and behind firewalls to understand the further NATFW procedures. Data receivers that are only behind firewalls already have a public IP address and they need only to be reachable for NATFW signaling. Unlike data receivers that are only behind firewalls, data receivers behind NATs do not have public IP addresses; consequently, they are not reachable for NATFW signaling by entities outside their addressing realm.
NSIS信令以及随后的数据流被定向到特定的目的地IP地址，该地址必须事先已知并可到达。数据接收器必须在接收本地NSIS基础设施（即，入站防火墙/NAT）之前，将传入NATFW NSLP信令和数据流告知本地NSIS基础设施。有必要区分NAT后面和防火墙后面的数据接收器，以了解进一步的NATFW过程。仅位于防火墙后面的数据接收器已经具有公共IP地址，并且只需要NATFW信令就可以访问它们。与仅位于防火墙后面的数据接收器不同，NAT后面的数据接收器没有公共IP地址；因此，NATFW信令无法通过其寻址域之外的实体访问它们。
The preceding discussion addresses the situation where a DR node that wants to be reachable is unreachable because the NAT lacks a suitable rule with the 'allow' action that would forward inbound data. However, in certain scenarios, a node situated behind inbound firewalls that do not block inbound data traffic (firewalls with "default to allow") unless requested might wish to prevent traffic being sent to it from specified addresses. In this case, NSIS NATFW signaling can be used to achieve this by installing a policy rule with its action set to 'deny' using the same mechanisms as for 'allow' rules.
前面的讨论解决了这样一种情况，即由于NAT缺少适当的规则以及转发入站数据的“允许”操作，因此想要访问的DR节点无法访问。但是，在某些情况下，位于入站防火墙后面的节点可能希望阻止从指定地址向其发送流量，除非请求，否则该节点不会阻止入站数据流量（具有“默认允许”功能的防火墙）。在这种情况下，NSIS NATFW信令可以通过使用与“允许”规则相同的机制安装策略规则，并将其操作设置为“拒绝”来实现这一点。
The required result is obtained by sending an EXTERNAL message in the inbound direction of the intended data flow. When using this functionality, the NSIS initiator for the 'Reserve External Address' signaling is typically the node that will become the DR for the eventual data flow. To distinguish this initiator from the usual case where the NI is associated with the DS, the NI is denoted by NI+ and the NSIS responder is similarly denoted by NR+.
通过在预期数据流的入站方向发送外部消息来获得所需的结果。使用此功能时，“保留外部地址”信令的NSIS启动器通常是将成为最终数据流DR的节点。为了将该发起者与通常情况下NI与DS相关联的情况区分开来，NI用NI+表示，NSIS响应者用NR+表示。
Public Internet Private Address Space
公共互联网专用地址空间
Edge
NI(DS) NAT/FW NAT NR(DR)
NR+ NI+
Edge
NI(DS) NAT/FW NAT NR(DR)
NR+ NI+
| | | |
| | | |
| | | |
| | EXTERNAL[(DTInfo)] | EXTERNAL[(DTInfo)] |
| |<----------------------|<----------------------|
| | | |
| |RESPONSE[Success/Error]|RESPONSE[Success/Error]|
| |---------------------->|---------------------->|
| | | |
| | | |
| | | |
| | | |
| | | |
| | EXTERNAL[(DTInfo)] | EXTERNAL[(DTInfo)] |
| |<----------------------|<----------------------|
| | | |
| |RESPONSE[Success/Error]|RESPONSE[Success/Error]|
| |---------------------->|---------------------->|
| | | |
| | | |
============================================================>
Data Traffic Direction
============================================================>
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的地址未知，则可能需要使用信令目的地地址（SDA）作为外部消息（NR+）的实际目标。SDA是来自DR的NAT另一侧最外层地址域中的任意地址。通常，当“外部”域是公共Internet时，这将是合适的公共IP地址。此地址选择导致外部消息通过NAT路由到最外层域，并将强制网络中最外层NAT在专用地址和公共地址域（边缘NAT）之间的边界处拦截消息。它也可能被边缘NAT路径上的其他NAT和防火墙拦截。
Basically, there are two different signaling scenarios. Either
基本上，有两种不同的信令场景。任何一个
1. the DR behind the NAT/firewall knows the IP address of the DS in advance, or
1. NAT/防火墙后面的DR预先知道DS的IP地址，或者
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要求NATFW NSLP从NTLP请求路径耦合消息路由方法（PC-MRM）。外部消息必须与PC-MRM一起发送（见[RFC5971]第5.8.1节），方向设置为“上游”（入站）。案例2的处理取决于灾难恢复的情况：如果灾难恢复仅位于防火墙后面，则必须使用PC-MRM发送外部消息，方向为“上游”（入站），数据流源IP地址设置为“通配符”。如果DR位于NAT后面，则必须使用松散端消息路由方法（LE-MRM，见[RFC5971]第5.8.2节）发送外部消息，将目标地址设置为信令目标IP地址（SDA，另见附录a）。对于DR位于防火墙后的场景，特殊条件适用（参见附录C中的适用性声明）。为了选择正确的消息路由方法，数据接收器需要确定它是否仅位于防火墙或NAT后面。此决定可能取决于本地配置参数，可能通过DHCP给出，也可能通过其他与NSLP无关的网络配置测试发现。建议使用具有已知数据发送方IP地址的PC-MRM。这为GIST提供了路由消息“上游”（出站）的最佳句柄。当且仅当数据发送方的IP地址未知且数据接收方位于NAT后面时，建议使用LE-MRM。
For case 2 with NAT, the NI+ (which could be on the data receiver DR or on any other host within the private network) sends the EXTERNAL message targeted to the signaling destination IP address. The message routing for the EXTERNAL message is in the reverse direction of the normal message routing used for path-coupled signaling where the signaling is sent outbound (as opposed to inbound in this case). When establishing NAT bindings (and a NATFW NSLP signaling session), the signaling direction does not matter since the data path is modified through route pinning due to the external IP address at the NAT. Subsequent NSIS messages (and also data traffic) will travel through the same NAT boxes. However, this is only valid for the NAT boxes, but not for any intermediate firewall. That is the reason for having a separate CREATE message enabling the reservations made with EXTERNAL at the NATs and either enabling prior reservations or creating new pinholes at the firewalls that are encountered on the outbound path depending on whether the inbound and outbound routes coincide.
对于使用NAT的情况2，NI+（可以在数据接收器DR上或在专用网络内的任何其他主机上）发送以信令目的地IP地址为目标的外部消息。外部消息的消息路由与用于路径耦合信令的正常消息路由相反，在路径耦合信令中，信令被发送到出站（在这种情况下与入站相反）。当建立NAT绑定（和NATFW NSLP信令会话）时，信令方向并不重要，因为由于NAT处的外部IP地址，数据路径通过路由固定进行修改。随后的NSIS消息（以及数据流量）将通过相同的NAT盒传输。但是，这仅对NAT盒有效，而对任何中间防火墙无效。这就是为什么要有一个单独的CREATE消息来启用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或防火墙。例如，当网络边界的出站路径上存在NAT和（之后）防火墙时，防火墙就是边缘防火墙。所有消息必须转发到拓扑相关的最外边缘设备，以确保该设备知道传入CREATE消息的NATFW NSLP信令会话。但是，NAT仍然是边缘NAT，因为它的公共端有一个公共的全局可路由IP地址：这不受边缘NAT和公共网络之间任何防火墙的影响。
Possible edge arrangements are:
可能的边缘布置包括：
Public Net ----------------- Private net --------------
Public Net ----------------- Private net --------------
| Public Net|--|Edge-FW|--|FW|...|FW|--|DR|
|公共网络|--| Edge FW |--| FW |…| FW |--|博士|
| Public Net|--|Edge-FW|--|Edge-NAT|...|NAT or FW|--|DR|
|公共网络|--| Edge FW |--| Edge NAT |…| NAT或FW |--|博士|
| Public Net|--|Edge-NAT|--|NAT or FW|...|NAT or FW|--|DR|
|公共网络|--|边缘NAT |--| NAT或FW | | NAT或FW |--|博士|
The edge-NAT or edge-firewall device closest to the public realm responds to the EXTERNAL request message with a successful RESPONSE message. An edge-NAT includes a NATFW_EXTERNAL_IP object (see Section 4.2.2), carrying the publicly reachable IP address, and if applicable, a port number.
最靠近公共领域的边缘NAT或边缘防火墙设备使用成功响应消息响应外部请求消息。边缘NAT包括一个NATFW_外部_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）在外部绑定地址对象中包括外部绑定地址（以及如果适用的端口号）。外部绑定地址对象在特定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
在生成和接收外部消息时，NATFW对等方有几个处理规则，因为此消息类型用于创建新的保留NATFW NSLP信令会话、更新现有会话、延长生存期和删除NATFW NSLP信令
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:
一场后三种功能对所有类型的创建和外部消息的操作方式相同，因此在单独的章节中进行了描述：
o Extending the lifetime of NATFW NSLP signaling sessions is described in Section 3.7.3.
o 第3.7.3节描述了延长NATFW NSLP信令会话的生存期。
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\U DTINFO对象。特别是，LE-MRM没有为某些类型的NAT（基本上是那些也转换端口号的NAT）提供足够的信息来执行地址转换。该信息在NATFW_DTINFO中提供（见第4.2.8节）。此信息必须至少包括NATFW_DTINFO对象中的“dst端口号”和“协议”字段，因为根据NAT的类型，路由中的NAT可能需要这些字段。所有其他字段可由NI+设置，以限制可能的NI设置。边缘NAT将使用NATFW_DTINFO对象中提供的信息，仅允许转发具有匹配MRI的NATFW CREATE消息。NATFW CREATE消息的MRI必须使用NATFW_DTINFO对象（“src IPv4/v6地址”、“src端口号”、“协议”）中设置的参数作为从DS到DR的流的源IP地址/端口。需要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 “源IP地址范围太大”（0x0C）
o 'Destination IP address range is too large' (0x0D)
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:NAT检查消息是在外部（大多数情况下为公共）地址还是在内部（私有）地址接收。如果在外部地址接收到NF，NF必须生成“协议错误”（3）类的错误响应，响应代码为“外部接收到的外部请求消息”（0x0B）。如果在内部（专用地址）接收到并且NATFW_EFI对象包含操作“拒绝”，则必须生成“协议错误”（3）类的错误响应，响应代码为“请求的规则操作不适用”（0x06）。如果在内部地址接收，则保留一个IP地址以及一个或多个端口（如果适用）。如果消息中存在NATFW_外部_绑定对象，则非边缘NAT的任何NAT都必须在NATFW_外部_绑定对象中包括分配的外部IP地址，以及一个或多个端口（如果适用）。如果是边缘NAT，并且没有边缘防火墙，则不会进一步转发NSLP消息，并生成一条成功响应消息，其中包含一个NATFW_外部_IP对象，该对象持有转换后的地址，如果适用，还包含作为外部消息结果保留的绑定端口信息。如果外部消息中包含NATFW_外部_绑定对象，则边缘NAT必须将该对象复制到响应消息。响应消息被发送回NI+。如果不是边缘NAT，则NSLP消息进一步转发，使用翻译后的IP地址作为LE-MRM中的信令源IP地址，并在字段“DR port number”中的NATFW_DTINFO对象中使用翻译后的端口，即更新NATFW_DTINFO对象以反映翻译后的端口号。边缘NAT或任何其他
NAT MUST reject EXTERNAL messages not carrying a NATFW_DTINFO object or if the address information within this object is invalid or is not compliant with local policies (e.g., the information provided relates to a range of addresses ('wildcarded') but the edge-NAT requires exact information about DS's IP address and port) with the above mentioned response codes.
NAT必须拒绝不携带NATFW_DTINFO对象的外部消息，或者如果此对象中的地址信息无效或不符合本地策略（例如，提供的信息与地址范围（“通配符”），但边缘NAT需要有关DS IP地址和端口的准确信息）使用上述响应代码。
* Firewall: Non edge-firewalls remember the requested policy rule, keep NATFW NSLP signaling session state, and forward the message. Edge-firewalls stop forwarding the EXTERNAL message. The policy rule is immediately loaded if the action in the NATFW_EFI object is set to 'deny' and the node is an edge-firewall. The policy rule is remembered, but not activated, if the action in the NATFW_EFI object is set to 'allow'. In both cases, a successful RESPONSE message is generated. If the action is 'allow', and the NATFW_DTINFO object is included, and the MRM is set to LE-MRM in the request, additionally a NATFW_EXTERNAL_IP object is included in the RESPONSE message, holding the translated address, and if applicable port, information. This information is obtained from the NATFW_DTINFO object's 'DR port number' and the source-address of the LE-MRM. The edge-firewall MUST copy the NATFW_EXTERNAL_BINDING object to response message, if the object is included in the EXTERNAL message.
* 防火墙：非边缘防火墙记住请求的策略规则，保持NATFW NSLP信令会话状态，并转发消息。边缘防火墙停止转发外部消息。如果NATFW_EFI对象中的操作设置为“拒绝”，并且节点是边缘防火墙，则会立即加载策略规则。如果NATFW_EFI对象中的操作设置为“允许”，则会记住策略规则，但不会激活该规则。在这两种情况下，都会生成成功的响应消息。如果操作为“允许”，并且包含NATFW_DTINFO对象，并且请求中将MRM设置为LE-MRM，则响应消息中还包含一个NATFW_外部_IP对象，该对象保存转换后的地址和端口信息（如果适用）。该信息来自NATFW_DTINFO对象的“DR端口号”和LE-MRM的源地址。如果NATFW_外部_绑定对象包含在外部消息中，则边缘防火墙必须将该对象复制到响应消息。
* Combined NAT and firewall: Processing at combined firewall and NAT middleboxes is the same as in the NAT case.
* 组合NAT和防火墙：组合防火墙和NAT中间盒的处理与NAT情况相同。
o NSLP receiver: This type of message should never be received by any NR+, and it MUST generate an error RESPONSE message of class 'Permanent failure' (5) with response code 'No edge-device here' (0x06).
o NSLP接收器：任何NR+都不应接收此类消息，并且必须生成“永久故障”（5）类的错误响应消息，响应代码为“此处无边缘设备”（0x06）。
Processing of a RESPONSE message is different for every NSIS node type:
对于每种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_外部_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转发器：如果响应消息包含类设置为“Success”（2）的NATFW_INFO对象，则只要NFs保持请求保留的状态，NFs就会转发此消息。如果响应消息包含NATFW_INFO对象，且类设置为非“Success”（2），则NATFW NSLP信令会话将标记为“Dead”。
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响应程序：任何NR+都不应接收此类消息。NF永远不应该接收响应消息，并且必须以静默方式丢弃它。
NFs and the NR can also tear down the EXTERNAL session at any time by generating a NOTIFY message with the appropriate response code set.
NFs和NR还可以通过生成带有适当响应代码集的NOTIFY消息，随时中断外部会话。
Reservations with action 'allow' made with EXTERNAL MUST be enabled by a subsequent CREATE message. A reservation made with EXTERNAL (independent of selected action) is kept alive as long as the NI+ refreshes the particular NATFW NSLP signaling session and it can be reused for multiple, different CREATE messages. An NI+ may decide to tear down a reservation immediately after receiving a CREATE message. This implies that a new NATFW NSLP signaling session must be created for each new CREATE message. The CREATE message does not re-use the NATFW NSLP signaling session created by EXTERNAL.
必须通过后续的CREATE消息启用使用EXTERNAL执行“allow”操作的保留。只要NI+刷新特定的NATFW NSLP信令会话，使用外部（独立于所选操作）进行的保留将保持活动状态，并且可以对多个不同的CREATE消息重复使用。NI+可能会在收到CREATE消息后立即决定取消保留。这意味着必须为每个新创建消息创建新的NATFW NSLP信令会话。CREATE消息不会重新使用外部服务器创建的NATFW NSLP信令会话。
Without using CREATE (see Section 3.7.1) or EXTERNAL in proxy mode (see Section 3.7.6) no data traffic will be forwarded to the DR beyond the edge-NAT or edge-firewall. The only function of EXTERNAL is to ensure that subsequent CREATE messages traveling towards the NR will be forwarded across the public-private boundary towards the DR. Correlation of incoming CREATE messages to EXTERNAL reservation states is described in Section 3.8.
如果不在代理模式下使用CREATE（参见第3.7.1节）或EXTERNAL（参见第3.7.6节），则不会将数据流量转发到边缘NAT或边缘防火墙之外的DR。EXTERNAL的唯一功能是确保向NR发送的后续创建消息将通过公私边界转发到DR。第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
NATFW NSLP信令会话以软状态为基础进行维护。在指定的超时之后，如果会话和相应的策略规则未刷新，则它们将由中间件自动删除。软状态由CREATE和EXTERNAL创建，必须通过这些消息来维护该状态。由CREATE创建的状态必须由CREATE维护，由EXTERNAL创建的状态必须由EXTERNAL维护。刷新消息是与初始消息具有相同会话ID的消息，以及生存期大于零的NATFW_LT生存期对象。具有相同SID但带有不同MRI的消息将被视为策略规则的更新，并按照第3.10节中的定义进行处理。每个刷新创建或外部消息必须由NR生成的相应响应消息确认。每个NSLP转发器接收到后，给定
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信令会话刷新周期来扩展会话ID，该周期是基于提议的刷新消息周期计算的时间段。NATFW NSLP信令会话的新（延长）生存期计算为当前本地时间加上建议的生存期值（NATFW NSLP信令会话刷新周期）。第3.4节详细定义了计算寿命的过程。
NI Public Internet NAT Private address NR
NI公共互联网NAT专用地址NR
| | space |
| CREATE[lifetime > 0] | |
| | space |
| CREATE[lifetime > 0] | |
|----------------------------->| |
| | |
| | |
| | CREATE[lifetime > 0] |
| |--------------------------->|
| | |
| | RESPONSE[Success/Error] |
| RESPONSE[Success/Error] |<---------------------------|
|<-----------------------------| |
| | |
| | |
|----------------------------->| |
| | |
| | |
| | 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:
对于每种NSIS节点类型，NATFW NSLP信令会话刷新创建和外部消息的处理是不同的：
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信令会话超时之前生成NATFW NSLP信令会话刷新创建/外部消息。第3.4节将进一步讨论刷新创建/外部消息的发送速率及其与NATFW NSLP信令会话状态生存期的关系。
o NSLP forwarder: Processing of this message is independent of the middlebox type and is as described in Section 3.4.
o NSLP转发器：此消息的处理独立于中间盒类型，如第3.4节所述。
o NSLP responder: NRs accepting a NATFW NSLP signaling session refresh CREATE/EXTERNAL message generate a successful RESPONSE message, including the granted lifetime value of Section 3.4 in a NATFW_LT object.
o NSLP响应程序：接受NATFW NSLP信令会话刷新创建/外部消息的NRs生成成功的响应消息，包括NATFW_LT对象中第3.4节授予的生存期值。
NATFW NSLP signaling sessions can be deleted at any time. NSLP initiators can trigger this deletion by using a CREATE or EXTERNAL messages with a lifetime value set to 0, as shown in Figure 17. Whether a CREATE or EXTERNAL message type is use depends on how the NATFW NSLP signaling session was created.
NATFW NSLP信令会话可以随时删除。NSLP启动器可以使用CREATE或外部消息触发此删除，其生存期值设置为0，如图17所示。创建或使用外部消息类型取决于NATFW NSLP信令会话的创建方式。
NI Public Internet NAT Private address NR
NI公共互联网NAT专用地址NR
| | space |
| CREATE[lifetime=0] | |
|----------------------------->| |
| | |
| | CREATE[lifetime=0] |
| |--------------------------->|
| | |
| | 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信令会话的所有其他字段；否则，这些字段将被完全通配符。如第5.2.1节和第7.1.4节所述，NSLP消息被传输到请求“显式路由”的NTLP。在[RFC5971]中。
The outbound NF receiving such an aggregated CREATE or EXTERNAL message MUST reject it with an error RESPONSE of class 'Permanent failure' (5) with response code 'Authentication failed' (0x01) if the authentication fails and with an error RESPONSE of class 'Permanent failure' (5) with response code 'Authorization failed' (0x02) if the authorization fails. Proof of ownership of NATFW NSLP signaling sessions, as it is defined in this memo (see Section 5.2.1), is not possible when using this aggregation for multiple session
接收此类聚合创建或外部消息的出站NF必须拒绝该消息，如果身份验证失败，则响应代码为“身份验证失败”（0x01）的错误响应为“永久失败”（5），响应代码为“授权失败”（0x02）的错误响应为“永久失败”（5）如果授权失败。本备忘录（见第5.2.1节）中定义的NATFW NSLP信令会话的所有权证明，在对多个会话使用此聚合时是不可能的
termination. However, the outbound NF can use the relationship between the information of the received CREATE or EXTERNAL message and the GIST messaging association where the request has been received. The outbound NF MUST only accept this aggregated CREATE or EXTERNAL message through already established GIST messaging associations with the NI. The outbound NF MUST NOT propagate this aggregated CREATE or EXTERNAL message but it MAY generate and forward per NATFW NSLP signaling session CREATE or EXTERNAL messages.
结束然而，出站NF可以使用接收到的CREATE或EXTERNAL消息的信息与接收到请求的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可能会在发生异步事件时生成NOTIFY消息，NATFW_INFO对象指示事件原因。这些原因可以在NOTIFY消息中的NATFW_INFO对象（类必须设置为“information”（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句柄以显式路由发送。
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发送，直到到达NI或向NR发送，如上面列表所示。
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节点，接收NOTIFY消息时的初始处理是相同的：NATFW节点必须仅通过已建立的NTLP消息关联接受NOTIFY消息。对于每种NATFW NSLP节点类型，进一步的处理是不同的，并且取决于通知的事件：
o NSLP initiator: NIs analyze the notified event and behave appropriately based on the event type. NIs MUST NOT generate NOTIFY messages.
o NSLP启动器：NIs分析通知的事件，并根据事件类型进行适当的行为。NIs不得生成通知消息。
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应在异步事件发生时生成NOTIFY消息，并根据接收的方向将它们转发到NI的入站或NR的出站，即，入站消息必须进一步转发到入站，出站消息必须进一步转发到出站。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信令会话生成通知消息，并尝试将其发送入站。由于要发送的NOTIFY消息的数量，节点的关闭可能会不必要地延长，因为并非所有消息都可以同时发送。如果涉及多个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完全通配符，使用本节第5.2.1节和第7.1.4节所述的“显式路由”[RFC5971]。接收此类通知的入站NF立即将来自与MRI匹配的对等方的所有NATFW NSLP信令会话视为无效。此消息通常会在入站NF处产生多条NOTIFY消息，即，NF可以为每个终止的NATFW NSLP信令会话生成一条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仅部署在Internet某些区域的情况。如果在数据发送方和数据接收方终端或其附近没有NSIS支持，端到端信令将失败。需要代理操作模式。此代理操作模式必须在尽可能靠近其代理的终端的拓扑上终止NATFW NSLP信令，并代理所有消息。该代理信令消息的NATFW NSLP节点成为特定NATFW NSLP信令会话的NI或NR，具体取决于不支持NSI的是DS还是DR。通常，边缘NAT或边缘防火墙将用于代理NATFW NSLP消息。
This proxy mode operation does not require any new CREATE or EXTERNAL message type, but relies on extended CREATE and EXTERNAL message types. They are called, respectively, CREATE-PROXY and EXTERNAL-PROXY and are distinguished by setting the P flag in the NSLP header to P=1. This flag instructs edge-NATs and edge-firewalls receiving them to operate in proxy mode for the NATFW NSLP signaling session in question. The semantics of the CREATE and EXTERNAL message types are not changed and the behavior of the various node types is as defined in Sections 3.7.1 and 3.7.2, except for the proxying node. The following paragraphs describe the proxy mode operation for data receivers behind middleboxes and data senders behind middleboxes.
此代理模式操作不需要任何新的创建或外部消息类型，但依赖于扩展的创建和外部消息类型。它们分别被称为CREATE-PROXY和EXTERNAL-PROXY，并通过将NSLP头中的P标志设置为P=1来区分。该标志指示边缘NAT和接收它们的边缘防火墙在代理模式下为所讨论的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
NATFW NSLP使NR能够为出站数据包在指向数据发送方的入站路径上安装状态，即使只有接收方正在运行NSIS（如图18所示）。所述方法的目标是触发边缘NAT/边缘防火墙以代表数据接收器生成创建消息。在这种情况下，NR可以向网络边界发送信号
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.
在第3.7.2节所述的标准外部消息处理场景中执行。消息被转发，直到到达边缘NAT/边缘防火墙。在边缘NAT/边缘防火墙上保留公共IP地址和端口号。如图18所示，与标准的外部消息处理情况不同，边缘NAT/边缘防火墙被触发，以在穿越多个防火墙或NAT的新反向路径上发送创建消息。创建的新反向路径对于处理边缘NAT/边缘防火墙和DR之间的路由不对称是必要的。必须强调的是，创建消息和外部消息的语义没有改变，即，每个消息都按照前面所述进行处理。
DS Public Internet NAT/FW Private address DR No NI NF space NR NR+ NI+
DS公用Internet NAT/FW专用地址DR No NI NF空间NR+NI+
| | EXTERNAL-PROXY[(DTInfo)] |
| |<------------------------- |
| | RESPONSE[Error/Success] |
| | ---------------------- > |
| | CREATE |
| | ------------------------> |
| | RESPONSE[Error/Success] |
| | <---------------------- |
| | |
| | EXTERNAL-PROXY[(DTInfo)] |
| |<------------------------- |
| | RESPONSE[Error/Success] |
| | ---------------------- > |
| | CREATE |
| | ------------------------> |
| | RESPONSE[Error/Success] |
| | <---------------------- |
| | |
Figure 18: EXTERNAL Triggering Sending of CREATE Message
图18:CREATE消息的外部触发发送
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.
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.translate error, please retry
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.
o NSLP启动器（NI+）：NI+必须将外部代理会话的会话ID（SID）值作为NATFW_nonce对象的nonce值。
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转发器是边缘NAT或边缘防火墙：当NF接受外部代理消息时，它会生成一条成功的响应消息，就像它是NR一样，并生成一条第3.7.1节中定义的创建消息，其中包括一个NATFW_NONCE对象，该对象的值与接收到的NATFW_NONCE对象的值相同。NF不得生成CREATE-PROXY消息。只有在首先收到外部代理刷新消息时，NF才必须刷新创建消息信令会话。这还包括拆除信令会话，即，仅当首先接收到生存期设置为0的外部代理消息时，NF必须拆除创建信令会话。
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可能以两种不同的方式做出错误的假设：
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永远不会发送预期的CREATE消息。案例b）将导致DR通过边缘NAT或边缘防火墙成功请求代理模式支持。边缘NAT/边缘防火墙将发送创建消息，DS也将发送创建消息。两个CREATE消息都作为单独的NATFW NSLP信令会话处理，因此每个NATFW NSLP信令会话的通用规则适用；NATFW_NONCE对象用于区分边缘NAT/边缘防火墙生成的创建消息与NI发起的创建消息。如果数据发送方知道NSIS，但DR错误地认为没有，NR有责任决定是否中断外部代理信令会话。建议NAT后面的DR默认使用代理操作模式，除非DR知道DS知道NSIS。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.
外部代理的响应消息和边缘NAT生成的创建消息之间可能存在竞争条件。创建消息可以早于响应消息到达。NI+必须接受由边缘NAT生成的CREATE消息，即使未收到外部代理的响应消息。
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感知节点终止转发并将响应代理给CREATE消息，这意味着此节点正在生成响应消息。最后一个节点可以是边缘NAT/边缘防火墙，或任何其他NATFW NSLP对等节点，检测到没有可用的NR（可能是GIST超时的结果，但可能存在其他触发器）。
DS Private Address NAT/FW Public Internet NR NI Space NF no NR
DS专用地址NAT/FW公共互联网号码NI空间号码NF号码
| | |
| CREATE-PROXY | |
|------------------------------>| |
| | |
| RESPONSE[SUCCESS/ERROR] | |
|<------------------------------| |
| | |
| | |
| 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.
创建代理消息和响应消息的处理类似于第3.7.1节，只是在边缘NAT/边缘防火墙处停止转发。edge NAT/edge防火墙根据情况（错误/成功）响应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.
NI可以选择代理操作模式，尽管DR知道NSIS。创建代理模式不会沿数据路径配置所有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到NR的路径是否支持NATFW NSLP的一种方法是使用常规CREATE消息并等待成功响应或错误响应。这将导致在从NI发送CREATE-PROXY消息（无论如何都是必需的）之外发送额外的消息，如CREATE消息。
The NATFW NSLP allows the usage of the proxy-mode and a further probing of the path by the edge-NAT or edge-firewall. The NI can request proxy-mode handling as described, and can set the E flag (see Figure 20) to request the edge-NAT or edge-firewall to probe the further path for NATFW NSLP enabled NFs or an NR.
NATFW NSLP允许使用代理模式，并通过边缘NAT或边缘防火墙进一步探测路径。NI可以如上所述请求代理模式处理，并可以设置E标志（见图20）以请求边缘NAT或边缘防火墙探测启用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标志，则除了常规代理模式处理外，边缘NAT或边缘防火墙还必须继续向NR发送创建代理或外部代理。边缘NAT或边缘防火墙依靠NTLP措施来确定是否有另一个NATFW NSLP可到达NR。将请求消息转发到NR的失败尝试将被静默放弃。NR将通过成功响应消息确认将请求消息转发至NR的成功尝试，这取决于代理模式部分中描述的常规行为。
The proxy mode assumes that the edge-NAT or edge-firewall are properly configured by network operator, i.e., the edge-device is really the final NAT or firewall of that particular network. There is currently no known way of letting the NATFW NSLP automatically detect which of the NAT or firewalls are the actual edge of a network. Therefore, it is important for the network operator to configure the edge-NAT or edge-firewall and also to re-configure these devices if they are not at the edge anymore. For instance, an edge-NAT is located within an ISP and the ISP chooses to place another NAT in front of this edge-NAT. In this case, the ISP needs to reconfigure the old edge-NAT to be a regular NATFW NLSP NAT and to configure the newly installed NAT to be the edge-NAT.
代理模式假设边缘NAT或边缘防火墙由网络运营商正确配置，即边缘设备实际上是该特定网络的最终NAT或防火墙。目前还没有已知的方法让NATFW NSLP自动检测哪个NAT或防火墙是网络的实际边缘。因此，网络运营商必须配置边缘NAT或边缘防火墙，并在这些设备不再位于边缘时重新配置这些设备。例如，一个边缘NAT位于ISP内，ISP选择在该边缘NAT前面放置另一个NAT。在这种情况下，ISP需要将旧的边缘NAT重新配置为常规NATFW NLSP NAT，并将新安装的NAT配置为边缘NAT。
Section 3.7.2 describes how NSIS nodes behind NATs can obtain a publicly reachable IP address and port number at a NAT and how the resulting mapping rule can be activated by using CREATE messages (see Section 3.7.1). The information about the public IP address/port number can be transmitted via an application-level signaling protocol and/or third party to the communication partner that would like to send data toward the host behind the NAT. However, NSIS signaling flows are sent towards the address of the NAT at which this particular IP address and port number is allocated and not directly to the allocated IP address and port number. The NATFW NSLP forwarder at this NAT needs to know how the incoming NSLP CREATE messages are related to reserved addresses, meaning how to demultiplex incoming NSIS CREATE messages.
第3.7.2节描述了NAT后面的NSIS节点如何在NAT处获得可公开访问的IP地址和端口号，以及如何通过使用创建消息激活生成的映射规则（参见第3.7.1节）。关于公共IP地址/端口号的信息可以通过应用级信令协议和/或第三方传输到想要向NAT后面的主机发送数据的通信伙伴。然而，NSIS信令流被发送到分配该特定IP地址和端口号的NAT地址，而不是直接发送到分配的IP地址和端口号。此NAT的NATFW NSLP转发器需要知道传入NSLP CREATE消息与保留地址的关系，这意味着如何对传入NSI CREATE消息进行多路复用。
The demultiplexing method uses information stored at the local NATFW NSLP node and in the policy rule. The policy rule uses the LE-MRM MRI source-address (see [RFC5971]) as the flow destination IP address and the network-layer-version (IP-ver) as IP version. The external IP address at the NAT is stored as the external flow destination IP address. All other parameters of the policy rule other than the flow destination IP address are wildcarded if no NATFW_DTINFO object is included in the EXTERNAL message. The LE-MRM MRI destination-address MUST NOT be used in the policy rule, since it is solely a signaling destination address.
解复用方法使用存储在本地NATFW NSLP节点和策略规则中的信息。策略规则使用LE-MRM MRI源地址（请参见[RFC5971]）作为流目标IP地址，使用网络层版本（IP版本）作为IP版本。NAT处的外部IP地址存储为外部流目标IP地址。如果外部消息中未包含NATFW_DTINFO对象，则策略规则的所有其他参数（流目标IP地址除外）都是通配符。LE-MRM MRI目的地地址不能用于策略规则，因为它只是一个信令目的地地址。
If the NATFW_DTINFO object is included in the EXTERNAL message, the policy rule is filled with further information. The 'dst port number' field of the NATFW_DTINFO is stored as the flow destination port number. The 'protocol' field is stored as the flow protocol. The 'src port number' field is stored as the flow source port number. The 'data sender's IPv4 address' is stored as the flow source IP address. Note that some of these fields can contain wildcards.
如果NATFW_DTINFO对象包含在外部消息中，则策略规则将填充更多信息。NATFW_DTINFO的“dst端口号”字段存储为流量目标端口号。“协议”字段存储为流协议。“src端口号”字段存储为流源端口号。“数据发送方的IPv4地址”存储为流源IP地址。请注意，其中一些字段可以包含通配符。
When receiving a CREATE message at the NATFW NSLP, the NATFW NSLP uses the flow information stored in the MRI to do the matching process. This table shows the parameters to be compared against each other. Note that not all parameters need be present in an MRI at the same time.
当NATFW NSLP接收到CREATE消息时，NATFW NSLP使用MRI中存储的流信息进行匹配处理。此表显示了要相互比较的参数。请注意，并非所有参数都需要同时出现在MRI中。
+-------------------------------+--------------------------------+
| Flow parameter (Policy Rule) | MRI parameter (CREATE message) |
+-------------------------------+--------------------------------+
| IP version | network-layer-version |
| Protocol | IP-protocol |
| source IP address (w) | source-address (w) |
| external IP address | destination-address |
| destination IP address (n/u) | N/A |
| source port number (w) | L4-source-port (w) |
| external port number (w) | L4-destination-port (w) |
| destination port number (n/u) | N/A |
| IPsec-SPI | ipsec-SPI |
+-------------------------------+--------------------------------+
+-------------------------------+--------------------------------+
| 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发送该入站消息，向NR发送该出站消息（另见第3.7.5节）。在前往NI的途中，如果中间NFs在特定时间段内未收到更新，则可以使用此信息来决定其NATFW NSLP信令会话是否可以在本地删除，如第3.2.8节所述。重要的是考虑在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.
接收该通知消息的NI可以生成新的CREATE或EXTERNAL消息，并使用相同的会话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下一跳发现，都要按照特定章节中所述进行常规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）相比，该消息具有修改后的消息路由信息（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头和头后面的一个或多个对象组成。NSLP头在所有NATFW NSLP消息中携带，对象使用大端（网络有序）二进制数据表示进行类型长度值（TLV）编码。标题和对象与32位边界对齐，并且不是32位倍数的对象长度必须填充到下一个更高的32位倍数。
The whole NSLP message is carried as payload of a NTLP message.
整个NSLP消息作为NTLP消息的有效负载承载。
Note that the notation 0x is used to indicate hexadecimal numbers.
注意，表示法0x用于表示十六进制数。
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数据对象必须包含此公共头作为对象的前32位（这与GIST公共头不同）。它包含两个字段，NSLP消息类型和P标志，以及两个保留字段。总长度为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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
如果收到另一类型的消息，则必须生成“协议错误”（3）类的错误响应，响应代码为“非法消息类型”（0x01）。
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。代理模式只能与消息类型CREATE和EXTERNAL结合使用。处理类型为RESPONSE或NOTIFY的消息时，必须忽略P标志。
The E flag indicates, in proxy mode, whether the edge-NAT or edge-firewall MUST continue sending the message to the NR, i.e., end-to-end. The E flag can only be set to 1 if the P flag is set; otherwise, it MUST be ignored. The E flag MUST only be used in combination with the message types CREATE and EXTERNAL. The E flag MUST be ignored when processing messages with type RESPONSE or NOTIFY.
在代理模式下，E标志指示边缘NAT或边缘防火墙是否必须继续向NR（即端到端）发送消息。如果设置了P标志，则E标志只能设置为1；否则，它必须被忽略。E标志只能与消息类型CREATE和EXTERNAL结合使用。在处理类型为RESPONSE或NOTIFY的消息时，必须忽略E标志。
NATFW NSLP objects use a common header format defined by Figure 21. The object header contains these fields: two flags, two reserved bits, the NSLP object type, a reserved field of 4 bits, and the object length. Its total length is 32 bits.
NATFW NSLP对象使用图21定义的公共头格式。对象头包含以下字段：两个标志、两个保留位、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Object Type |r|r|r|r| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Common NSLP Object Header
图21：通用NSLP对象头
The object length field contains the total length of the object without the object header. The unit is a word, consisting of 4 octets. The particular values of type and length for each NSLP object are listed in the subsequent sections that define the NSLP objects. An error RESPONSE of class 'Protocol error' (3) with response code 'Wrong object length' (0x07) MUST be generated if the length given in the object header is inconsistent with the type of object specified or the message is shorter than implied by the object length. The two leading bits of the NSLP object header are used to signal the desired treatment for objects whose treatment has not been defined in this memo (see [RFC5971], Appendix A.2.1), i.e., the Object Type has not been defined. NATFW NSLP uses a subset of the categories defined in GIST:
“对象长度”字段包含不带对象标头的对象的总长度。这个单位是一个单词，由4个八位组组成。定义NSLP对象的后续章节中列出了每个NSLP对象的类型和长度的特定值。如果对象标头中给出的长度与指定的对象类型不一致，或者消息短于对象长度所暗示的长度，则必须生成响应代码为“错误对象长度”（0x07）的“协议错误”（3）类错误响应。NSLP对象标头的两个前导位用于表示本备忘录中未定义处理的对象的所需处理（参见[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），响应代码为“未知对象存在”（0x06）。
o AB=01 ("Optional"): If the object is not understood, it should be deleted and then the rest of the message processed as usual.
o AB=01（“可选”）：如果不理解该对象，则应删除该对象，然后像往常一样处理消息的其余部分。
o AB=10 ("Forward"): If the object is not understood, it should be retained unchanged in any message forwarded as a result of message processing, but not stored locally.
o AB=10（“转发”）：如果对象不被理解，则应在任何由于消息处理而转发的消息中保持不变，但不在本地存储。
The combination AB=11 MUST NOT be used and an error RESPONSE of class 'Protocol error' (3) with response code 'Invalid Flag-Field combination' (0x09) MUST be generated.
组合AB=11不得使用，必须生成“协议错误”（3）类的错误响应，响应代码为“无效标志字段组合”（0x09）。
The following sections do not repeat the common NSLP object header, they just list the type and the length.
以下部分不重复常见的NSLP对象头，它们只列出类型和长度。
The signaling session lifetime object carries the requested or granted lifetime of a NATFW NSLP signaling session measured in seconds.
信令会话生存期对象承载NATFW NSLP信令会话的请求或授予生存期（以秒为单位）。
Type: NATFW_LT (0x00C)
类型：NATFW_LT（0x00C）
Length: 1
长度：1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NATFW NSLP signaling session lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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节）。它在边缘NAT上携带可公开访问的IP地址和端口号（如果适用）。
Type: NATFW_EXTERNAL_IP (0x00D)
类型：NATFW_外部_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number |IP-Ver | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: External Address Object for IPv4 Addresses
图23:IPv4地址的外部地址对象
Please note that the field 'port number' MUST be set to 0 if only an IP address has been reserved, for instance, by a traditional NAT. A port number of 0 MUST be ignored in processing this object.
请注意，如果仅保留了IP地址（例如，由传统NAT保留），则“端口号”字段必须设置为0。处理此对象时必须忽略端口号0。
IP-Ver (4 bits): The IP version number. This field MUST be set to 4.
IP版本（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部署（例如，请参见第2.5节）。附录B中描述了该对象中信息的利用情况。
Type: NATFW_EXTERNAL_BINDING (0x00E)
类型：NATFW_外部_绑定（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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number |IP-Ver | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: External Binding Address Object
图24：外部绑定地址对象
Please note that the field 'port number' MUST be set to 0 if only an IP address has been reserved, for instance, by a traditional NAT. A port number of 0 MUST be ignored in processing this object.
请注意，如果仅保留了IP地址（例如，由传统NAT保留），则“端口号”字段必须设置为0。处理此对象时必须忽略端口号0。
IP-Ver (4 bits): The IP version number. This field MUST be set to 4.
IP版本（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
长度：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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
此对象有两个字段，“规则操作”和“子端口”。“规则操作”字段具有以下含义：
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:拒绝：具有此操作的策略规则阻止数据流量通过中间箱，并且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）类的错误响应，响应代码为“未知策略规则操作”（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（端口1）中指定的端口外，还使用了第二个端口（端口2）。端口2的此值计算为：端口2=端口1+1。此字段中不得使用0或1以外的值，并且必须生成“信令会话失败”（7）类的错误响应，响应代码为“NATFW_EFI NOT ALLOMITED”（0x08）中sub_ports字段中的请求值”。这两个连续的编号端口可由传统IP语音设备使用。此传统设备假定其RTP/RTCP流分别具有两个相邻端口号。
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_信息（0x010）
Length: 1
长度：1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv. | Class | Response Code |r|r|r|r| Object Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv. | Class | Response Code |r|r|r|r| Object Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Information Code Object
图26：信息代码对象
The field 'resv.' is reserved for future extensions and MUST be set to zero when generating such an object and MUST be ignored when receiving. The 'Object Type' field contains the type of the object causing the error. The value of 'Object Type' is set to 0, if no object is concerned. The leading fours bits marked with 'r' are always set to zero and ignored. The 4-bit class field contains the error class. The following classes are defined:
字段“resv.”保留用于将来的扩展，在生成此类对象时必须设置为零，并且在接收时必须忽略。“对象类型”字段包含导致错误的对象的类型。如果不涉及任何对象，“对象类型”的值设置为0。标有“r”的前导四位始终设置为零并忽略。4位类字段包含错误类。定义了以下类别：
o 0: Reserved
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\U 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
“数据终端信息”对象包含必须包含在外部消息中的附加信息。外部消息由NTLP使用松散端消息路由方法（LE-MRM）传输。LE-MRM仅包含DR的IP地址和信令目的地地址（目的地IP地址）。此目标IP地址仅用于消息路由，不一定反映数据发送方的地址。此对象包含有关（如果适用）DR的端口号（目标端口号）、DS的端口号（源端口号）、使用的传输协议、IP地址的前缀长度和DS的IP地址的信息。
Type: NATFW_DTINFO (0x013)
类型：NATFW\U DTINFO（0x013）
Length: variable. Maximum 3.
长度：可变。最多3个。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|P|S| reserved | sender prefix | protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DR port number | DS port number :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPsec-SPI :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data sender's IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
只有设置了S时，SPI字段才会出现。端口号仅在设置P时存在。不能同时设置标志P和S。如果同时设置了“协议错误”（3）类和“无效标志字段组合”（0x09），则必须生成“协议错误”（3）类的错误响应。如果设置了P或S，则必须同时设置I，并且协议字段必须包含特定的协议。如果设置了S或P但未设置I，则必须生成响应代码为“无效标志字段组合”（0x09）的“协议错误”（3）类错误响应。
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。值0表示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 prefix字段）。
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类型”对象包含配置防火墙NAT所需的附加信息，该NAT具有控制ICMP流量的规则。该对象包含ICMP类型字段的多个值，应为这些值设置筛选操作：
Type: NATFW_ICMP_TYPES (0x014)
类型：NATFW_ICMP_类型（0x014）
Length: Variable = ((Number of Types carried + 1) + 3) DIV 4
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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头和一个或多个NSLP对象构成。对象的顺序没有定义，这意味着对象可能以任何顺序出现。对象标记为强制（M）或可选（O）。其中（M）表示该特定对象必须包含在消息中，而（O）表示该特定对象在消息中是可选的。本备忘录中定义的对象在NSLP对象标题中始终带有标记组合AB=00。如果缺少强制声明的对象，则必须生成“协议错误”（3）类的错误响应消息，响应代码为“缺少强制对象”（0x04）。如果存在不能在此类消息中使用的对象，则必须生成响应代码为“存在非法对象”（0x05）的“协议错误”（3）类错误响应消息。如果对象在消息中出现多次，则必须生成响应代码为“存在重复对象”（0x0A）的“协议错误”（3）类错误响应消息。
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.
每一节详细说明了NSLP为NTLP设置的必要设置和参数，例如，如何设置消息路由信息。
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.
创建消息用于创建NATFW NSLP信令会话和创建策略规则。此外，创建消息用于刷新NATFW NSLP信令会话并删除它们。
The CREATE message carries these objects:
“创建”消息包含以下对象：
o Signaling Session Lifetime object (M)
o 信令会话生存期对象（M）
o Extended flow information object (M)
o 扩展流信息对象（M）
o Message sequence number object (M)
o 消息序列号对象（M）
o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise (O)
o 如果NSLP头中的P标志设置为1，则为Nonce对象（M），否则为（O）
o ICMP Types Object (O)
o ICMP类型对象（O）
The message routing information in the NTLP MUST be set to DS as source IP address and DR as destination IP address. All other parameters MUST be set according to the required policy rule. CREATE messages MUST be transported by using the path-coupled MRM with the direction set to 'downstream' (outbound).
NTLP中的消息路由信息必须设置为DS作为源IP地址，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的DRs，或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）
o ICMP Types Object (O)
o ICMP类型对象（O）
o External binding address object (O)
o 外部绑定地址对象（O）
The selected message routing method of the EXTERNAL message depends on a number of considerations. Section 3.7.2 describes exhaustively how to select the correct method. EXTERNAL messages can be transported via the path-coupled message routing method (PC-MRM) or via the loose-end message routing method (LE-MRM). In the case of PC-MRM, the source-address is set to the DS's address and the destination-address is set to the DR's address, the direction is set to inbound. In the case of LE-MRM, the destination-address is set to the DR's address or to the signaling destination IP address. The source-address is set to the DS's address.
外部消息的所选消息路由方法取决于许多注意事项。第3.7.2节详细描述了如何选择正确的方法。外部消息可以通过路径耦合消息路由方法（PC-MRM）或松散端消息路由方法（LE-MRM）传输。对于PC-MRM，源地址设置为DS地址，目标地址设置为DR地址，方向设置为入站。在LE-MRM的情况下，目的地地址设置为DR的地址或信令目的地IP地址。源地址设置为DS的地址。
RESPONSE messages are responses to CREATE and EXTERNAL messages. RESPONSE messages MUST NOT be generated for any other message, such as NOTIFY and RESPONSE.
响应消息是对创建和外部消息的响应。不得为任何其他消息（如NOTIFY和RESPONSE）生成响应消息。
The RESPONSE message for the class 'Success' (2) carries these objects:
类“Success”（2）的响应消息包含以下对象：
o Signaling Session Lifetime object (M)
o 信令会话生存期对象（M）
o Message sequence number object (M)
o 消息序列号对象（M）
o Information code object (M)
o 信息代码对象（M）
o External address object (O)
o 外部地址对象（O）
o External binding address object (O)
o 外部绑定地址对象（O）
The RESPONSE message for other classes than 'Success' (2) carries these objects:
“成功”（2）以外的其他类的响应消息包含以下对象：
o Message sequence number object (M)
o 消息序列号对象（M）
o Information code object (M)
o 信息代码对象（M）
o Signaling Session Lifetime object (O)
o 信令会话生存期对象（O）
This message is routed towards the NI hop-by-hop, using existing NTLP messaging associations. The MRM used for this message MUST be the same as MRM used by the corresponding CREATE or EXTERNAL message.
使用现有的NTLP消息关联，将此消息逐跳路由到NI。此消息使用的MRM必须与相应的CREATE或EXTERNAL消息使用的MRM相同。
The NOTIFY messages is used to report asynchronous events happening along the signaled path to other NATFW NSLP nodes.
NOTIFY消息用于向其他NATFW NSLP节点报告沿信号路径发生的异步事件。
The NOTIFY message carries this object:
NOTIFY消息包含以下对象：
o Information code object (M)
o 信息代码对象（M）
The NOTIFY message is routed towards the next NF, NI, or NR hop-by-hop using the existing inbound or outbound node messaging association entry within the node's Message Routing State table. The MRM used for this message MUST be the same as MRM used by the corresponding CREATE or EXTERNAL message.
使用节点的消息路由状态表中现有的入站或出站节点消息关联条目，将NOTIFY消息逐跳路由到下一个NF、NI或NR。此消息使用的MRM必须与相应的CREATE或EXTERNAL消息使用的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.
[RFC4081]中描述了主要针对NSI的安全威胁，它们也适用于本文件。
Finally, we illustrate how the security requirements that were created based on the security threats can be fulfilled by specific security mechanisms. These aspects will be elaborated in Section 5.2.
最后，我们将说明如何通过特定的安全机制来满足基于安全威胁创建的安全需求。这些方面将在第5.2节中详细阐述。
The NATFW NSLP is a protocol that may involve a number of NSIS nodes and is, as such, not a two-party protocol. Figures 1 and 2 of [RFC4081] already depict the possible set of communication patterns. In this section, we will re-evaluate these communication patterns with respect to the NATFW NSLP protocol interaction.
NATFW NSLP是一种可能涉及多个NSIS节点的协议，因此不是一种双方协议。[RFC4081]的图1和图2已经描述了一组可能的通信模式。在本节中，我们将根据NATFW NSLP协议交互重新评估这些通信模式。
The security solutions for providing authorization have a direct impact on the treatment of different NSLPs. As it can be seen from the QoS NSLP [RFC5974] and the corresponding Diameter QoS work [RFC5866], accounting and charging seems to play an important role for QoS reservations, whereas monetary aspects might only indirectly effect authorization decisions for NAT and firewall signaling. Hence, there are differences in the semantics of authorization handling between QoS and NATFW signaling. A NATFW-aware node will most likely want to authorize the entity (e.g., user or machine) requesting the establishment of pinholes or NAT bindings. The outcome of the authorization decision is either allowed or disallowed, whereas a QoS authorization decision might indicate that a different set of QoS parameters is authorized (see [RFC5866] as an example).
提供授权的安全解决方案对不同NSLP的处理有直接影响。从QoS NSLP[RFC5974]和相应的Diameter QoS工作[RFC5866]可以看出，记帐和收费似乎在QoS保留方面发挥着重要作用，而货币方面可能只间接影响NAT和防火墙信令的授权决策。因此，QoS和NATFW信令之间的授权处理语义存在差异。NATFW感知节点很可能希望授权请求建立针孔或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.
从最简单的场景开始，假设相邻节点能够相互认证并建立密钥材料以保护信令消息通信。除了身份验证之外，节点还必须相互授权。我们使用术语“安全上下文”作为占位符，用于指代整个安全过程、为使其工作所需的必要基础设施（例如，密钥管理）以及已建立的安全相关状态。用于身份验证的所需长期密钥（对称或非对称密钥）可使用两个NSIS NATFW节点之间的带外机制获得，或使用本文档中未进一步指定的机制动态建立。请注意，部署环境很可能会对正在使用的凭据的选择产生影响。选择使用的这些凭据也不在本文档的范围内。
+------------------------+ +-------------------------+
|Network A | | Network B|
| +---------+ +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | Security | box 2 | | |
| | +---------+ Context +---------+ | |
| | Security | | Security | |
| | Context | | Context | |
| | | | | |
| +--+---+ | | +--+---+ |
| | Host | | | | Host | |
| | A | | | | B | |
| +------+ | | +------+ |
+------------------------+ +-------------------------+
+------------------------+ +-------------------------+
|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可能是企业网络中的主机，该主机已与公司防火墙（中间箱1）建立密钥材料（例如，共享机密）。网络A（公司网络）的网络管理员已为主机A（或特定公司希望使用的任何标识符）创建访问控制列表。在网络B中的主机B和中间箱2之间也可以使用完全相同的过程。对于中间箱1和中间箱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 | +----------+ |
| +------+ |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| Network A |
| +---------+ +---------+
| +----///--------+ Middle- +------///------++ Middle- +---
| | Security | box 2 | Security | box 2 |
| | Context +----+----+ Context +----+----+
| +----+----+ | | |
| | Middle- +--------+ +---------+ | |
| | box 1 | | | | |
| +----+----+ | | | |
| | Security | +----+-----+ | |
| | Context | | Policy | | |
| +--+---+ +-----------+ Decision +----------+ |
| | Host | | Point | |
| | A | +----------+ |
| +------+ |
+-----------------------------------------------------------+
Figure 32: Intra-Domain Relationship
图32：域内关系
The interaction between individual middleboxes and a policy decision point (or AAA server) is outside the scope of this document.
单个中间盒与策略决策点（或AAA服务器）之间的交互不在本文档的范围内。
The peer-to-peer relationship between neighboring NSIS NATFW NSLP nodes might not always be sufficient. Network B might require additional authorization of the signaling message initiator (in addition to the authorization of the neighboring node). If authentication and authorization information is not attached to the initial signaling message then the signaling message arriving at Middlebox 2 would result in an error message being created, which indicates the additional authorization requirement. In many cases, the signaling message initiator might already be aware of the additionally required authorization before the signaling message exchange is executed.
相邻NSIS NATFW NSLP节点之间的对等关系可能并不总是足够的。网络B可能需要信令消息发起方的额外授权（除了相邻节点的授权之外）。如果认证和授权信息未附加到初始信令消息，则到达中间盒2的信令消息将导致创建错误消息，该错误消息指示附加授权需求。在许多情况下，在执行信令消息交换之前，信令消息发起方可能已经知道额外需要的授权。
Figure 33 shows this scenario.
图33显示了这个场景。
+--------------------+ +---------------------+
| Network A | |Network B |
| | Security | |
| +---------+ Context +---------+ |
| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
| | | box 1 | +-------+ box 2 | | |
| | +---------+ | +---------+ | |
| |Security | | | Security | |
| |Context | | | Context |
| | | | | | |
| +--+---+ | | | +--+---+ |
| | Host +----///----+------+ | | Host | |
| | A | | Security | | B | |
| +------+ | Context | +------+ |
+--------------------+ +---------------------+
+--------------------+ +---------------------+
| 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
在发送NATFW信令消息时，建议在相邻节点之间使用[RFC5971]中提供的身份验证和密钥交换安全机制。建议的GIST安全机制除了提供拒绝服务保护外，还提供身份验证和密钥交换支持。根据选择的安全协议，可能会提供对多个身份验证协议的支持。如果需要相邻节点之间的安全性，则强烈建议使用带有安全传输协议的C模式交付大多数NSIS消息，使用D模式仅发现路径上的下一个NATFW NSLP感知节点。有关C模式和D模式的定义，请参见[RFC5971]。NATFW NSLP层的几乎所有安全威胁都可以预防
by using a mutually authenticated Transport Layer secured connection and by relying on authorization by the neighboring NATFW NSLP entities.
通过使用相互认证的传输层安全连接，并依靠相邻NATFW NSLP实体的授权。
The NATFW NSLP relies on an established security association between neighboring peers to prevent unauthorized nodes from modifying or deleting installed state. Between non-neighboring nodes the session ID (SID) carried in the NTLP is used to show ownership of a NATFW NSLP signaling session. The session ID MUST be generated in a random way and thereby prevents an off-path adversary from mounting targeted attacks. Hence, an adversary would have to learn the randomly generated session ID to perform an attack. In a mobility environment a former on-path node that is now off-path can perform an attack. Messages for a particular NATFW NSLP signaling session are handled by the NTLP to the NATFW NSLP for further processing. Messages carrying a different session ID not associated with any NATFW NSLP are subject to the regular processing for new NATFW NSLP signaling sessions.
NATFW NSLP依赖于相邻对等方之间建立的安全关联，以防止未经授权的节点修改或删除已安装状态。在非相邻节点之间，NTLP中携带的会话ID（SID）用于显示NATFW NSLP信令会话的所有权。会话ID必须以随机方式生成，从而防止非路径对手发起目标攻击。因此，对手必须学习随机生成的会话ID才能执行攻击。在移动性环境中，前一个在路径上的节点（现在已脱离路径）可以执行攻击。特定NATFW NSLP信令会话的消息由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绑定的建立相关的信息。但是，该信息不能在多个NSIS NATFW NSLP跳上受到保护，因为该信息可能会根据每个单独NATFW NSLP节点的能力而改变。
Some scenarios might also benefit from the usage of authorization tokens. Their purpose is to associate two different signaling protocols (e.g., SIP and NSIS) and their authorization decision. These tokens are obtained by non-NSIS protocols, such as SIP or as part of network access authentication. When a NAT or firewall along the path receives the token it might be verified locally or passed to the AAA infrastructure. Examples of authorization tokens can be found in RFC 3520 [RFC3520] and RFC 3521 [RFC3521]. Figure 34 shows an example of this protocol interaction.
某些场景还可能受益于授权令牌的使用。它们的目的是将两个不同的信令协议（例如，SIP和NSIS）及其授权决策关联起来。这些令牌通过非NSIS协议（如SIP）或作为网络访问身份验证的一部分获得。当路径上的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
授权令牌由SIP代理提供，它充当断言生成实体，并通过适当的身份验证和授权传递给终端主机。当NATFW信令消息被发送到网络时，授权令牌被附加到信令消息以参考先前的授权决策。断言验证实体需要处理令牌，或者可能需要与令牌交互
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.
使用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 +----------------+
+----------------+ 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。但是，在典型的Internet部署中，除了授予对网络的访问权限之外，没有建立信任，但在Internet中的各个站点之间没有建立信任。此外，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技术与Internet中的其他边缘相匹配（假设防火墙和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完全打开（即，不应应用allow all策略），而应允许DRs保留非常具体的策略。例如，DR可以为Jabber文件传输的传入TCP连接请求保留“允许”策略规则。必须通过匹配CREATEREQUEST消息来激活此保留策略（见图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.
对于增量部署，上述段落中描述的用法得到了进一步简化：不需要使用CREATE request消息激活保留策略规则。这完全由EXTERNAL-PROXY请求消息和关联的CREATE请求消息处理。它们都由本地身份验证和授权方案处理。
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.
[RFC3424]将单边自地址固定（UNSAF）描述为原始端点处的一个过程，试图确定或固定另一个端点已知的地址（和端口）。UNSAF的提案，如STUN[RFC5389]被视为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]的规定，为互联网分配号码管理局（IANA）提供有关注册NATFW NSLP相关数值的指南。
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审查。无法从注册表中更新和删除值。此规范定义了四种NATFW NSLP消息类型，它们构成此注册表的初始内容。IANA添加了这四种NATFW NSLP消息类型：创建（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）。每个注册表项由值、位位置、描述（包含节号）和引用组成。
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_外部_IP、NATFW_外部_绑定、NATFW_EFI、NATFW_信息、NATFW_NONCE、NATFW_MSN、NATFW_DTINFO、NATFW_ICMP_类型。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在[RFC5971]中为NATFW NSLP定义的NSLP标识符（NSLPID）注册表中添加了一个新值（33）。
IPv4 and IPv6 Router Alert Option (RAO) value
IPv4和IPv6路由器警报选项（RAO）值
The GIST specification also requires that each NSLP-ID be associated with specific Router Alert Option (RAO) value. For the purposes of the NATFW NSLP, a single IPv4 RAO value (65) and a single IPv6 RAO value (68) have been allocated.
GIST规范还要求每个NSLP-ID与特定路由器警报选项（RAO）值相关联。就NATFW NSLP而言，已分配单个IPv4 RAO值（65）和单个IPv6 RAO值（68）。
We would like to thank the following individuals for their contributions to this document at different stages:
我们要感谢以下个人在不同阶段对本文件的贡献：
o Marcus Brunner and Henning Schulzrinne for their work on IETF documents that led us to start with this document;
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对本文档的初始版本和第一个原型实现做出了巨大贡献；
o Srinath Thiruvengadam and Ali Fessi work for their work on the NAT/firewall threats document;
o Srinath Thriuvengadam和Ali Fessi为NAT/防火墙威胁文件工作；
o Henning Peters for his comments and suggestions;
o 感谢亨宁·彼得斯的评论和建议；
o Ben Campbell as Gen-ART reviewer;
o 本·坎贝尔（Ben Campbell）担任艺术评论家；
o and the NSIS working group.
o 国家统计局工作组。
[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，“要点：通用互联网信号传输”，RFC 59712010年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 40802005年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]Way，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]Way，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，“中间箱通信架构和框架”，RFC 33032002年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 40812005年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]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年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 22052997年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 34242002年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]威斯特林，A.，施尼兹莱因，J.，斯特拉斯纳，J.，舍林，M.，奎因，B.，赫尔佐格，S.，休恩，A.，卡尔森，M.，佩里，J.，和S.瓦尔德布瑟，“基于政策的管理术语”，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 35212003年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防火墙]罗地格，U.，戈尔茨，M.，卡顿，M.，和R.施泰因梅茨，“rsvp作为防火墙信令协议”，第六届IEEE计算机与通信研讨会论文集，突尼斯哈马米特，第57至62页，IEEE计算机学会出版社，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地址，即数据发送方或数据发送方和接收方。对于外部消息，仅关注数据发送者的情况。本节的其余部分提供了有关确定外部消息的良好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地址。建议将所有非专用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数据包路由到边缘NAT或边缘防火墙。
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_外部_绑定对象携带信息，该信息与NATFW_外部_IP对象中携带的信息具有不同的效用。NATFW_EXTERNAL_IP对象具有公共IP地址和可能的端口号，NI上的应用程序可以通过公共Internet访问这些地址和端口号。然而，在某些情况下，不同的NIs位于同一公共NAT的后面，但受制于多级NAT部署，如图35所示。他们可以使用分配给他们的公共IP地址端口在彼此之间进行通信（例如，NI与NR1和NR2），但他们被迫通过边缘NAT发送流量，即使可能的方式更短。
NI --192.168.0/24-- NAT1--10.0.0.0/8--NAT2 Internet (public IP) | NR1--192.168.0/24-- NAT3-- | NR2 10.1.2.3
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发送外部消息，并获得外部地址+端口绑定。然后，它们交换该外部绑定，所有流量都固定到NAT2，而不是直接通过NAT1到NAT3的最短路径。然而，要做到这一点，NR1和NI都需要知道，它们的地址也分别位于NAT1和NAT3的外部。如果部署了ICE，并且在配置的10/8网络中实际上有一个STUN服务器，则可以使用更短的路径工作。NATFW NSLP在NATFW_外部_绑定中向公共网络提供所有外部地址，以便进行优化。
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和公共Internet之间存在重叠的地址域，则常规路由将不需要将数据包发送到正确的域。
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非常容易。只需要找到一些边缘NAT，因为数据流量将路由固定到NAT。在PC-MRM发送入站的情况下，很难找到合适的边缘防火墙。对于从互联网到数据接收器的单一对称路由的情况，这是非常容易的；只需沿着入站方向的默认路线。
+------+ Data Flow
+-------| EFW1 +----------+ <===========
| +------+ ,--+--.
+--+--+ / \
NI+-----| FW1 | (Internet )----NR+/NI/DS
NR +--+--+ \ /
| +------+ `--+--'
+-------| EFW2 +----------+
+------+
+------+ Data Flow
+-------| EFW1 +----------+ <===========
| +------+ ,--+--.
+--+--+ / \
NI+-----| FW1 | (Internet )----NR+/NI/DS
NR +--+--+ \ /
| +------+ `--+--'
+-------| EFW2 +----------+
+------+
~~~~~~~~~~~~~~~~~~~~~>
Signaling Flow
~~~~~~~~~~~~~~~~~~~~~>
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所示），则必须确定数据流量路由通过的特定防火墙。在外部消息交换过程中，从NI+/NR向NR+发送的NATFW NSLP信令消息必须由NTLP路由到边缘防火墙，该防火墙也将通过数据流量传递。NTLP需要了解Internet内的路由，以确定DS和DR之间的路径。除此之外，NTLP可以确定必须选择哪个边缘防火墙（EFW1或EFW2）来转发NATFW NSLP信令。向错误的边缘防火墙发送信号，如图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地址（不是通配符）、传输协议TCP和TCP端口号完全通配符的MRI为例。如果本地策略只允许设置了所有端口且未进行通配符的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:
本节介绍如何将用CREATE消息发出信号的NSLP策略规则映射到防火墙规则。MRI设置如下：
o network-layer-version=IPv4
o 网络层版本=IPv4
o source-address=192.0.2.100, prefix-length=32
o 源地址=192.0.2.100，前缀长度=32
o destination-address=192.0.50.5, prefix-length=32
o 目标地址=192.0.50.5，前缀长度=32
o IP-protocol=UDP
o IP协议=UDP
o L4-source-port=34543, L4-destination-port=23198
o L4源端口=34543，L4目标端口=23198
The NATFW_EFI object is set to action=allow and sub_ports=0.
NATFW_EFI对象设置为action=allow，sub_port=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.
要安装的结果策略规则（防火墙规则）可能如下所示：允许udp从192.0.2.100端口=34543到192.0.50.5端口=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对象。由于实际数据发送方的IP地址未知，因此使用信令目的地地址对MRI进行如下设置：
o network-layer-version=IPv4
o 网络层版本=IPv4
o source-address= 192.168.5.100
o 源地址=192.168.5.100
o destination-address=SDA
o 目的地址=SDA
o IP-protocol=UDP
o IP协议=UDP
The NATFW_EFI object is set to action=allow and sub_ports=0. The NATFW_DTINFO object contains these parameters:
NATFW_EFI对象设置为action=allow，sub_port=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.
边缘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
如第2.5节所述，两次NAT的动态配置需要应用程序级支持。如果需要应用程序级支持，NATFW NSLP不能用于配置两次NAT。假设应用程序级支持执行在该设备上安装的两次NAT和NATFW NSLP的配置，NATFW NSLP必须能够遍历它。NSLP可能能够像任何其他数据通信一样穿越两次NAT，但是存储在NTLP的MRI中的流信息将通过源和目标IP地址的转换而失效。两次NAT上的NATFW NSLP实现必须拦截NATFW NSLP和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.
与任何其他NATFW NSLP节点一样发送信令消息。对于给定的信令流，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.
本节给出了一个示例，说明如何将NATFW NLSP用于NAT后面的接收器，其中只有接收端启用了NATFW NSLP。我们假设FTP作为应用程序来显示一个工作示例。FTP服务器位于NAT后面，如图5所示，并使用NATFW NSLP为FTP协议的控制和数据通道分配NAT绑定。关于到达服务器的位置的信息通过单独的协议（例如电子邮件、聊天）传送到DS端。
Public Internet Private Address Space FTP Client FTP Server
公用Internet专用地址空间FTP客户端FTP服务器
DS NAT NI+
| | |
| | EXTERNAL |
| |<---------------------------|(1)
| | |
| |RESPONSE[Success] |
| |--------------------------->|(2)
| |CREATE |
| |--------------------------->|(3)
| |RESPONSE[Success] |
| |<---------------------------|(4)
| | |
| | <Use port=XYZ, IP=a.b.c.d> |
|<=======================================================|(5)
|FTP control port=XYZ | FTP control port=21 |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(6)
| | |
| FTP control/get X | FTP control/get X |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(7)
| | EXTERNAL |
| |<---------------------------|(8)
| | |
| |RESPONSE[Success] |
| |--------------------------->|(9)
| |CREATE |
| |--------------------------->|(10)
| |RESPONSE[Success] |
| |<---------------------------|(11)
| | |
| Use port=FOO, IP=a.b.c.d | Use port=FOO, IP=a.b.c.d |
|<~~~~~~~~~~~~~~~~~~~~~~~~~~|<~~~~~~~~~~~~~~~~~~~~~~~~~~~|(12)
| | |
|FTP data to port=FOO | FTP data to port=20 |
|~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(13)
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的外部请求消息，包括以下对象：信令会话生存期、扩展流信息对象（规则操作=允许，子端口=0）、消息序列号对象、nonce对象（携带nonce用于创建）和数据终端信息对象（设置了I/P标志，发送方前缀=0，协议=TCP，DR端口号=21，DS的IP地址=0）；使用LE-MRM。这用于为FTP控制通道（TCP，端口21）分配外部绑定。
2. Successful RESPONSE sent to NI+, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2), external address object (port=XYZ, IPv4 addr=a.b.c.d).
2. 成功向NI+发送响应，对象包括：信令会话生存期、消息序列号对象、信息代码对象（“成功”：2）、外部地址对象（端口=XYZ，IPv4地址=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+发送CREATE，其中包含以下对象：信令会话生存期、扩展流信息对象（规则操作=allow，子端口=0）、消息序列号对象、nonce对象（具有从（1）复制的值）；使用PC-MRM（src IP=a.b.c.d，src端口=XYZ，dst IP=NI+，dst端口=21，下游）。
4. Successful RESPONSE sent to NAT, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2).
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控制通道连接到端口=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的外部请求消息，包括以下对象：信令会话生存期、扩展流信息对象（规则操作=允许，子端口=0）、消息序列号对象、nonce对象（携带nonce用于创建）和数据终端信息对象（设置了I/P标志，发送方前缀=32，协议=TCP，DR端口号=20，DS的IP地址=DS-IP）；使用LE-MRM。这用于为FTP数据通道（TCP，端口22）分配外部绑定。
9. Successful RESPONSE sent to NI+, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2), external address object (port=FOO, IPv4 addr=a.b.c.d).
9. 成功向NI+发送响应，对象包括：信令会话生存期、消息序列号对象、信息代码对象（“成功”：2）、外部地址对象（端口=FOO，IPv4地址=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+发送CREATE，其中包含以下对象：信令会话生存期、扩展流信息对象（规则操作=allow，子端口=0）、消息序列号对象、nonce对象（具有从（1）复制的值）；使用PC-MRM（src IP=a.b.c.d，src端口=FOO，dst IP=NI+，dst端口=20，下游）。
11. Successful RESPONSE sent to NAT, with these objects: signaling session lifetime, message sequence number object, information code object ('Success':2).
11. 成功地将响应发送到NAT，包括以下对象：信令会话生存期、消息序列号对象、信息代码对象（“成功”：2）。
12. The FTP server responses with port=FOO and IP=a.b.c.d.
12. FTP服务器以port=FOO和IP=a.b.c.d响应。
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
马丁-斯蒂芬林NEC欧洲有限公司和哥廷根大学36海德堡69115德国
Phone: +49 (0) 6221 4342 113
EMail: Martin.Stiemerling@neclab.eu
URI: http://www.stiemerling.org
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诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Cedric Aoun Consultant Paris, France
法国巴黎塞德里克奥恩咨询公司
EMail: cedaoun@yahoo.fr
EMail: cedaoun@yahoo.fr
Elwyn Davies Folly Consulting Soham UK
Elwyn Davies Folly咨询英国苏哈姆
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com