Internet Engineering Task Force (IETF) J. Woodyatt, Ed.
Request for Comments: 6092 Apple
Category: Informational January 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Woodyatt, Ed.
Request for Comments: 6092 Apple
Category: Informational January 2011
ISSN: 2070-1721
Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service
提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能
Abstract
摘要
This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices.
本文档为设备制造商确定了一套建议，并描述了如何在支持互联网的家庭和小型办公室的局域网IPv6网络周边提供“简单安全”功能。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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/rfc6092.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6092.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关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 ....................................................3
1.1. Special Language ...........................................3
1.2. Use of Normative Keywords ..................................3
2. Overview ........................................................4
2.1. Basic Sanitation ...........................................5
2.2. Internet Layer Protocols ...................................5
2.3. Transport Layer Protocols ..................................6
3. Detailed Recommendations ........................................6
3.1. Stateless Filters ..........................................7
3.2. Connection-Free Filters ....................................8
3.2.1. Internet Control and Management .....................8
3.2.2. Upper-Layer Transport Protocols .....................8
3.2.3. UDP Filters ........................................10
3.2.4. IPsec and Internet Key Exchange (IKE) ..............11
3.2.5. Mobility Support in IPv6 ...........................12
3.3. Connection-Oriented Filters ...............................13
3.3.1. TCP Filters ........................................14
3.3.2. SCTP Filters .......................................17
3.3.3. DCCP Filters .......................................20
3.3.4. Level 3 Multihoming Shim Protocol for IPv6
(Shim6) ............................................23
3.4. Passive Listeners .........................................23
3.5. Management Applications ...................................24
4. Summary of Recommendations .....................................25
5. Contributors ...................................................31
6. Security Considerations ........................................32
7. References .....................................................33
7.1. Normative References ......................................33
7.2. Informative References ....................................35
1. Introduction ....................................................3
1.1. Special Language ...........................................3
1.2. Use of Normative Keywords ..................................3
2. Overview ........................................................4
2.1. Basic Sanitation ...........................................5
2.2. Internet Layer Protocols ...................................5
2.3. Transport Layer Protocols ..................................6
3. Detailed Recommendations ........................................6
3.1. Stateless Filters ..........................................7
3.2. Connection-Free Filters ....................................8
3.2.1. Internet Control and Management .....................8
3.2.2. Upper-Layer Transport Protocols .....................8
3.2.3. UDP Filters ........................................10
3.2.4. IPsec and Internet Key Exchange (IKE) ..............11
3.2.5. Mobility Support in IPv6 ...........................12
3.3. Connection-Oriented Filters ...............................13
3.3.1. TCP Filters ........................................14
3.3.2. SCTP Filters .......................................17
3.3.3. DCCP Filters .......................................20
3.3.4. Level 3 Multihoming Shim Protocol for IPv6
(Shim6) ............................................23
3.4. Passive Listeners .........................................23
3.5. Management Applications ...................................24
4. Summary of Recommendations .....................................25
5. Contributors ...................................................31
6. Security Considerations ........................................32
7. References .....................................................33
7.1. Normative References ......................................33
7.2. Informative References ....................................35
Some IPv6 gateway devices that enable delivery of Internet services in residential and small-office settings may be augmented with "simple security" capabilities as described in "Local Network Protection for IPv6" [RFC4864]. In general, these capabilities cause packets to be discarded in an attempt to make local networks and the Internet more secure. However, it is worth noting that some packets sent by legitimate applications may also be discarded in this process, affecting reliability and ease of use for these applications.
如“IPv6本地网络保护”[RFC4864]中所述，一些能够在住宅和小型办公室环境中提供Internet服务的IPv6网关设备可能会增加“简单安全”功能。通常，这些功能会导致丢弃数据包，以使本地网络和Internet更加安全。但是，值得注意的是，合法应用程序发送的某些数据包也可能在该过程中被丢弃，从而影响这些应用程序的可靠性和易用性。
There is a constructive tension between the desires of users for transparent end-to-end connectivity on the one hand, and the need for local-area network administrators to detect and prevent intrusion by unauthorized public Internet users on the other. This document is intended to highlight reasonable limitations on end-to-end transparency where security considerations are deemed important to promote local and Internet security.
一方面，用户希望端到端连接透明，另一方面，局域网管理员需要检测和防止未经授权的公共互联网用户的入侵，这两者之间存在着建设性的紧张关系。本文件旨在强调对端到端透明度的合理限制，其中安全考虑被视为促进本地和互联网安全的重要因素。
The reader is cautioned always to remember that the typical residential or small-office network administrator has no expertise whatsoever in Internet engineering. Configuration interfaces for router/gateway appliances marketed toward them should be easy to understand and even easier to ignore. In particular, extra care should be used in the design of baseline operating modes for unconfigured devices, since most devices will never be changed from their factory configurations.
读者应始终记住，典型的住宅或小型办公室网络管理员在互联网工程方面没有任何专业知识。面向它们销售的路由器/网关设备的配置接口应该易于理解，甚至更容易忽略。特别是，在设计未配置设备的基准运行模式时应格外小心，因为大多数设备永远不会改变其出厂配置。
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]中所述进行解释。
Additionally, the key word "DEFAULT" is to be interpreted in this document as pertaining to a configuration as applied by a vendor, prior to the administrator changing it for its initial activation.
此外，在管理员更改初始激活之前，本文档中的关键字“DEFAULT”应解释为与供应商应用的配置有关。
NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. It uses the normative keywords defined in the previous section only for precision.
请注意：本文档不是一个标准，声明符合IPv6的IETF标准并不需要符合它。它使用上一节中定义的规范性关键字仅用于精确性。
Particular attention is drawn to recommendation REC-49, which calls for an easy way to set a gateway to a transparent mode of operation.
特别值得注意的是建议REC-49，该建议要求用一种简单的方法将网关设置为透明的操作模式。
For the purposes of this document, residential Internet gateways are assumed to be fairly simple devices with a limited subset of the full range of possible features. They function as default routers [RFC4294] for a single local-area network, e.g., an Ethernet network, a Wi-Fi network, or a bridge between two or more such segments. They have only one interface by which they can access the Internet service at any one time, using any of several possible sub-IP mechanisms, including tunnels and transition mechanisms.
在本文件中，住宅互联网网关被假定为相当简单的设备，具有全系列可能功能的有限子集。它们用作单个局域网的默认路由器[RFC4294]，例如以太网、Wi-Fi网络或两个或多个此类网段之间的网桥。他们只有一个接口，通过该接口，他们可以在任何时候访问Internet服务，使用几种可能的子IP机制中的任何一种，包括隧道和转换机制。
In referring to the security capabilities of residential gateways, it is reasonable to distinguish between their "interior" network, i.e., the local-area network, and their "exterior" networks, e.g., the public Internet and the networks of Internet service providers. This document is concerned only with the behavior of IP packet filters that police the flow of traffic between the interior IPv6 network and the exterior IPv6 networks of residential Internet gateways.
在提及住宅网关的安全能力时，有理由区分其“内部”网络，即局域网和“外部”网络，例如公共互联网和互联网服务提供商的网络。本文档仅涉及IP数据包过滤器的行为，该过滤器监控住宅互联网网关内部IPv6网络和外部IPv6网络之间的流量。
The operational goals of security capabilities in Internet gateways are described with more detail in "Local Network Protection for IPv6" [RFC4864], but they can be summarized as follows.
Internet网关安全功能的操作目标在“IPv6本地网络保护”[RFC4864]中有更详细的描述，但可概括如下。
o Check all traffic to and from the public Internet for basic sanity, e.g., filter for spoofs and misdirected (sometimes called "Martian") packets [RFC4949].
o 检查进出公共互联网的所有流量是否基本正常，例如，过滤欺骗和定向错误（有时称为“火星”）数据包[RFC4949]。
o Allow tracking of application usage by source and destination network addresses and ports.
o 允许按源和目标网络地址和端口跟踪应用程序使用情况。
o Provide a barrier against untrusted external influences on the interior network by requiring filter state to be activated by traffic originating at interior network nodes.
o 通过要求内部网络节点上的流量激活过滤器状态，为内部网络上不受信任的外部影响提供屏障。
o Allow manually configured exceptions to the stateful filtering rules according to network administrative policy.
o 根据网络管理策略，允许手动配置有状态筛选规则的异常。
o Isolate local network DHCPv6 and DNS resolver services from the public Internet.
o 将本地网络DHCPv6和DNS解析程序服务与公共Internet隔离。
Prior to the widespread availability of IPv6 Internet service, homes and small offices often used private IPv4 network address realms [RFC1918] with Network Address Translation (NAT) functions deployed to present all the hosts on the interior network as a single host to
在IPv6 Internet服务普及之前，家庭和小型办公室通常使用专用IPv4网络地址域[RFC1918]，并部署网络地址转换（NAT）功能，将内部网络上的所有主机作为单个主机呈现给用户
the Internet service provider. The stateful packet filtering behavior of NAT set user expectations that persist today with residential IPv6 service. "Local Network Protection for IPv6" [RFC4864] recommends applying stateful packet filtering at residential IPv6 gateways that conforms to the user expectations already in place.
互联网服务提供商。NAT的有状态数据包过滤行为设定了用户的期望，这种期望在住宅IPv6服务中仍然存在。“IPv6本地网络保护”[RFC4864]建议在住宅IPv6网关上应用符合现有用户期望的有状态数据包过滤。
Conventional stateful packet filters activate new states as a side effect of forwarding outbound flow initiations from interior network nodes. This requires applications to have advance knowledge of the addresses of exterior nodes with which they expect to communicate. Several proposals are currently under consideration for allowing applications to solicit inbound traffic from exterior nodes without advance knowledge of their addresses. While consensus within the Internet engineering community has emerged that such protocols are necessary to implement in residential IPv6 gateways, the best current practice has not yet been established.
传统的有状态包过滤器激活新状态，作为从内部网络节点转发出站流启动的副作用。这要求应用程序提前了解它们希望与之通信的外部节点的地址。目前正在考虑一些建议，允许应用程序在不事先知道外部节点地址的情况下从外部节点请求入站流量。虽然互联网工程界已达成共识，认为在住宅IPv6网关中实施此类协议是必要的，但目前的最佳实践尚未确立。
In addition to the functions required of all IPv6 routers [RFC4294], residential gateways are expected to have basic stateless filters for prohibiting certain kinds of traffic with invalid headers, e.g., "Martian" packets, spoofs, routing header type code zero, etc. (See Section 3.1 for more details.)
除了所有IPv6路由器[RFC4294]所需的功能外，住宅网关还应具有基本的无状态过滤器，用于禁止具有无效报头的某些类型的流量，例如“火星”数据包、欺骗、路由报头类型代码为零等（更多详细信息，请参阅第3.1节）
Conversely, simple Internet gateways are not expected to prohibit the development of new applications. In particular, packets with end-to-end network security and routing extension headers for mobility are expected to pass Internet gateways freely.
相反，简单的互联网网关预计不会阻止新应用程序的开发。特别是，具有端到端网络安全性和用于移动性的路由扩展头的数据包有望自由通过因特网网关。
Finally, Internet gateways that route multicast traffic are expected to implement appropriate filters for multicast traffic to limit the scope of multicast groups that span the demarcation between residential networks and service provider networks.
最后，路由多播流量的Internet网关应为多播流量实施适当的过滤器，以限制跨越住宅网络和服务提供商网络之间界限的多播组的范围。
As virtual private networking tunnels are regarded as an unacceptably wide attack surface, this document recommends that the DEFAULT operating mode for residential IPv6 simple security be to treat Generic Packet Tunneling [RFC2473] and similar protocols as opaque transport layers, i.e., inbound tunnel initiations are denied and outbound tunnel initiations are accepted.
由于虚拟专用网络隧道被视为不可接受的广泛攻击面，本文件建议住宅IPv6简单安全的默认操作模式是将通用数据包隧道[RFC2473]和类似协议视为不透明传输层，即。，拒绝入站隧道启动，并接受出站隧道启动。
IPsec transport and tunnel modes are explicitly secured by definition, so this document recommends that the DEFAULT operating mode permit IPsec. To facilitate the use of IPsec in support of IPv6
IPsec传输和隧道模式由定义明确保护，因此本文档建议默认操作模式允许IPsec。为方便使用IPsec支持IPv6
mobility, the Internet Key Exchange (IKE) protocol [RFC5996] and the Host Identity Protocol (HIP) [RFC5201] should also be permitted in the DEFAULT operating mode.
在默认操作模式下，还应允许移动、互联网密钥交换（IKE）协议[RFC5996]和主机标识协议（HIP）[RFC5201]。
IPv6 simple security functions are principally concerned with the
stateful filtering of the Internet Control Message Protocol (ICMPv6)
[RFC4443] and transport layers like the User Datagram Protocol (UDP)
[RFC0768], the Lightweight User Datagram Protocol (UDP-Lite)
[RFC3828], the Transmission Control Protocol (TCP) [RFC0793], the
Stream Control Transmission Protocol (SCTP) [RFC4960], the Datagram
Congestion Control Protocol (DCCP) [RFC4340], and potentially any
standards-track transport protocols to be defined in the future.
IPv6 simple security functions are principally concerned with the
stateful filtering of the Internet Control Message Protocol (ICMPv6)
[RFC4443] and transport layers like the User Datagram Protocol (UDP)
[RFC0768], the Lightweight User Datagram Protocol (UDP-Lite)
[RFC3828], the Transmission Control Protocol (TCP) [RFC0793], the
Stream Control Transmission Protocol (SCTP) [RFC4960], the Datagram
Congestion Control Protocol (DCCP) [RFC4340], and potentially any
standards-track transport protocols to be defined in the future.
The general operating principle is that transport layer traffic is not forwarded into the interior network of a residential IPv6 gateway unless it has been solicited explicitly by interior transport endpoints, e.g., by matching the reverse path for previously forwarded outbound traffic, or by matching configured exceptions set by the network administrator. All other traffic is expected to be discarded or rejected with an ICMPv6 error message to indicate the traffic is administratively prohibited.
一般工作原理是，传输层流量不会转发到住宅IPv6网关的内部网络，除非内部传输端点明确请求，例如，通过匹配先前转发的出站流量的反向路径，或者通过匹配网络管理员设置的配置异常。所有其他通信都将被丢弃或拒绝，并显示一条ICMPv6错误消息，指示该通信被管理禁止。
This section describes the specific recommendations made by this document in full detail. Section 4 is a summary.
本节详细介绍了本文件提出的具体建议。第四节是总结。
Some recommended filters are to be applied to all traffic that passes through residential Internet gateways regardless of the direction they are to be forwarded. Other recommended filters are intended to be sensitive to the "direction" of traffic flows. Applied to bidirectional transport flows, "direction" has a specific meaning in this document.
一些推荐的过滤器将应用于通过住宅互联网网关的所有流量，而不管其转发方向如何。其他推荐的过滤器旨在对交通流的“方向”敏感。对于双向运输流，“方向”在本文件中具有特定含义。
Packets are said to be "outbound" if they originate at nodes located in the interior network for exterior destinations, and "inbound" if they arrive from exterior sources with interior destinations.
如果数据包起源于位于外部目的地内部网络中的节点，则称为“出站”，如果数据包从具有内部目的地的外部源到达，则称为“入站”。
Flows are said to be "outbound" if the originator of the initial packet in any given transport association is an interior node and one or more of the participants are located in the exterior. Flows are said to be "inbound" if the originator of the initial packet is an exterior node and one or more of the participants are nodes on the interior network.
如果任何给定传输关联中初始数据包的发起人是内部节点，并且一个或多个参与者位于外部，则流被称为“出站”。如果初始数据包的发起人是外部节点，并且一个或多个参与者是内部网络上的节点，则称流为“入站”。
Certain kinds of IPv6 packets MUST NOT be forwarded in either direction by residential Internet gateways regardless of network state. These include packets with multicast source addresses, packets to destinations with certain non-routable and/or reserved prefixes, and packets with deprecated extension headers.
无论网络状态如何，某些类型的IPv6数据包都不能由住宅互联网网关向任一方向转发。其中包括具有多播源地址的数据包、到具有某些不可路由和/或保留前缀的目的地的数据包，以及具有不推荐使用的扩展头的数据包。
Other stateless filters are recommended to implement ingress filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope boundaries, and to isolate certain local network services from the public Internet.
建议使用其他无状态过滤器来实现入口过滤（请参见[RFC2827]和[RFC3704]），以强制多播作用域边界，并将某些本地网络服务与公共互联网隔离。
REC-1: Packets bearing multicast source addresses in their outer IPv6 headers MUST NOT be forwarded or transmitted on any interface.
REC-1：外部IPv6报头中包含多播源地址的数据包不得在任何接口上转发或传输。
REC-2: Packets bearing multicast destination addresses in their outer IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address Architecture" [RFC4007]) than the configured scope boundary level of the gateway MUST NOT be forwarded in any direction. The DEFAULT scope boundary level SHOULD be organization-local scope, and it SHOULD be configurable by the network administrator.
REC-2：在其外部IPv6报头中承载多播目标地址的数据包的作用域等于或小于网关配置的作用域边界级别（请参阅“IPv6作用域地址体系结构”[RFC4007]），不得向任何方向转发。默认范围边界级别应为组织本地范围，并且应由网络管理员进行配置。
REC-3: Packets bearing source and/or destination addresses forbidden to appear in the outer headers of packets transmitted over the public Internet MUST NOT be forwarded. In particular, site-local addresses are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use of address blocks of types IPv4-Mapped Addresses, IPv4-Compatible Addresses, Documentation Prefix, and Overlay Routable Cryptographic Hash IDentifiers (ORCHID).
REC-3：不得转发带有禁止出现在通过公共互联网传输的数据包的外部报头中的源地址和/或目的地址的数据包。特别是，[RFC3879]不推荐使用站点本地地址，[RFC5156]明确禁止使用IPv4映射地址、IPv4兼容地址、文档前缀和覆盖可路由加密哈希标识符（RAYD）类型的地址块。
REC-4: Packets bearing deprecated extension headers prior to their first upper-layer-protocol header SHOULD NOT be forwarded or transmitted on any interface. In particular, all packets with routing extension header type 0 [RFC2460] preceding the first upper-layer-protocol header MUST NOT be forwarded. See [RFC5095] for additional background.
REC-4：在第一个上层协议头之前带有不推荐的扩展头的数据包不应在任何接口上转发或传输。特别是，在第一上层协议报头之前具有路由扩展报头类型0[RFC2460]的所有数据包不得转发。更多背景信息，请参见[RFC5095]。
REC-5: Outbound packets MUST NOT be forwarded if the source address in their outer IPv6 header does not have a unicast prefix configured for use by globally reachable nodes on the interior network.
REC-5：如果出站数据包的外部IPv6报头中的源地址没有配置供内部网络上的全局可访问节点使用的单播前缀，则不得转发出站数据包。
REC-6: Inbound packets MUST NOT be forwarded if the source address in their outer IPv6 header has a global unicast prefix assigned for use by globally reachable nodes on the interior network.
REC-6：如果入站数据包的外部IPv6报头中的源地址具有分配给内部网络上全局可访问节点使用的全局单播前缀，则不得转发入站数据包。
REC-7: By DEFAULT, packets with unique local source and/or destination addresses [RFC4193] SHOULD NOT be forwarded to or from the exterior network.
REC-7：默认情况下，具有唯一本地源和/或目标地址[RFC4193]的数据包不应转发到外部网络或从外部网络转发。
REC-8: By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server.
REC-8：默认情况下，任何集成DNS解析服务器都不能处理在外部接口上接收的入站DNS查询。
REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on exterior interfaces MUST NOT be processed by any integrated DHCPv6 server or relay agent.
REC-9:外部接口上接收的入站DHCPv6发现数据包[RFC3315]不得由任何集成DHCPv6服务器或中继代理处理。
NOTE WELL: Nothing in this document relieves residential Internet gateways, when processing headers to identify valid sequences of upper-layer transport packets, from any of the requirements of the "Internet Protocol, Version 6 (IPv6) Specification" [RFC2460], including any and all future updates and revisions.
请注意：本文件中的任何内容均不免除住宅互联网网关在处理报头以识别上层传输数据包的有效序列时遵守“互联网协议，第6版（IPv6）规范”[RFC2460]的任何要求，包括任何和所有未来的更新和修订。
Some Internet applications use connection-free transport protocols with no release semantics, e.g., UDP. These protocols pose a special difficulty for stateful packet filters because most of the application state is not carried at the transport level. State records are created when communication is initiated and are abandoned when no further communication is detected after some period of time.
一些Internet应用程序使用无连接传输协议，但没有发布语义，例如UDP。这些协议给有状态数据包过滤器带来了特殊的困难，因为大多数应用程序状态都不是在传输级别进行的。状态记录在通信启动时创建，在一段时间后未检测到进一步通信时放弃。
Recommendations for filtering ICMPv6 messages in firewall devices are described separately in [RFC4890] and apply to residential gateways, with the additional recommendation that incoming "Destination Unreachable" and "Packet Too Big" error messages that don't match any filtering state should be dropped.
[RFC4890]中分别介绍了在防火墙设备中过滤ICMPv6消息的建议，并适用于住宅网关，另外还建议删除与任何过滤状态不匹配的传入“目标不可访问”和“数据包太大”错误消息。
REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing IP headers that do not match generic upper-layer transport state records.
REC-10:IPv6网关不应转发包含与通用上层传输状态记录不匹配的IP头的ICMPv6“目标不可访问”和“数据包太大”消息。
Residential IPv6 gateways are not expected to prohibit the use of applications to be developed using future upper-layer transport protocols. In particular, transport protocols not otherwise discussed in subsequent sections of this document are expected to be treated consistently, i.e., as having connection-free semantics and no special requirements to inspect the transport headers.
住宅IPv6网关预计不会禁止使用将使用未来上层传输协议开发的应用程序。特别是，本文件后续章节中未另行讨论的传输协议应得到一致的处理，即具有无连接语义，且无检查传输头的特殊要求。
In general, upper-layer transport filter state records are expected to be created when an interior endpoint sends a packet to an exterior address. The filter allocates (or reuses) a record for the duration of communications, with an idle timer to delete the state record when no further communications are detected.
通常，当内部端点向外部地址发送数据包时，需要创建上层传输筛选器状态记录。过滤器在通信期间分配（或重用）一条记录，并使用空闲计时器在未检测到进一步通信时删除状态记录。
One key aspect of how a packet filter behaves is the way it evaluates the exterior address of an endpoint when applying a filtering rule. A gateway is said to have "endpoint-independent filtering" behavior when the exterior address is not evaluated when matching a packet with a flow. A gateway is said to have "address-dependent filtering" behavior when the exterior address of a packet is required to match the exterior address for its flow.
包过滤器的一个关键方面是应用过滤规则时，它评估端点外部地址的方式。当外部地址在匹配数据包和流时未被评估时，网关被称为具有“端点独立过滤”行为。当要求数据包的外部地址与其流的外部地址匹配时，网关被称为具有“地址相关过滤”行为。
REC-11: If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for generic upper-layer transport protocols. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
REC-11：如果应用程序透明性是最重要的，那么有状态数据包过滤器应该具有通用上层传输协议的“端点独立过滤”行为。如果更严格的过滤行为是最重要的，那么过滤器应该具有“地址相关过滤”行为。过滤行为可以是网络管理员可配置的选项，并且它可以独立于其他协议的过滤行为。默认情况下，在没有服务提供商管理的情况下用于资源调配的网关中，筛选行为应该与端点无关。
REC-12: Filter state records for generic upper-layer transport protocols MUST NOT be deleted or recycled until an idle timer not less than two minutes has expired without having forwarded a packet matching the state in some configurable amount of time. By DEFAULT, the idle timer for such state records is five minutes.
REC-12：通用上层传输协议的过滤器状态记录不得删除或回收，直到空闲计时器超过不少于两分钟，且未在某个可配置的时间内转发与状态匹配的数据包。默认情况下，此类状态记录的空闲计时器为5分钟。
The Internet security community is never completely at rest. New attack surfaces, and vulnerabilities in them, are typically discovered faster than they can be patched by normal equipment upgrade cycles. It's therefore important for vendors of residential gateway equipment to provide automatic software updates to patch vulnerabilities as they are discovered.
互联网安全社区永远不会完全处于静止状态。新的攻击面及其漏洞的发现速度通常比正常的设备升级周期更快。因此，住宅网关设备的供应商在发现漏洞时提供补丁漏洞的自动软件更新非常重要。
REC-13: Residential IPv6 gateways SHOULD provide a convenient means to update their firmware securely, for the installation of security patches and other manufacturer-recommended changes.
REC-13：住宅IPv6网关应提供一种方便的方式来安全地更新其固件，以便安装安全补丁和其他制造商建议的更改。
Vendors can expect users and operators to have differing viewpoints on the maintenance of patches, with some preferring automatic update and some preferring manual procedures. Those preferring automatic update may also prefer either to download from a vendor site or from one managed by their network provider. To handle the disparity, vendors are advised to provide both manual and automatic options. In
供应商可以期望用户和操作员对修补程序的维护有不同的观点，有些更喜欢自动更新，有些更喜欢手动操作。那些更喜欢自动更新的用户也可能更喜欢从供应商网站或其网络提供商管理的网站下载。为了处理这种差异，建议供应商提供手动和自动选项。在里面
the automatic case, they would do well to facilitate pre-configuration of the download URL and a means of validating the software image, such as a certificate.
在自动情况下，它们会很好地促进下载URL的预配置和验证软件映像的方法，例如证书。
"Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" [RFC4787] defines the terminology and best current practice for stateful filtering of UDP applications in IPv4 with NAT, which serves as the model for behavioral requirements for simple UDP security in IPv6 gateways, notwithstanding the requirements related specifically to network address translation.
“单播UDP的网络地址转换（NAT）行为要求”[RFC4787]定义了使用NAT对IPv4中的UDP应用程序进行有状态过滤的术语和最佳当前实践，该术语和实践作为IPv6网关中简单UDP安全行为要求的模型，尽管有专门与网络地址转换相关的要求。
An interior endpoint initiates a UDP flow through a stateful packet filter by sending a packet to an exterior address. The filter allocates (or reuses) a filter state record for the duration of the flow. The state record defines the interior and exterior IP addresses and ports used between all packets in the flow.
内部端点通过向外部地址发送数据包，通过有状态数据包过滤器启动UDP流。过滤器在流的持续时间内分配（或重用）过滤器状态记录。状态记录定义流中所有数据包之间使用的内部和外部IP地址和端口。
State records for UDP flows remain active while they are in use and are only abandoned after an idle period of some time.
UDP流的状态记录在使用时保持活动状态，只有在空闲一段时间后才会被放弃。
REC-14: A state record for a UDP flow where both source and destination ports are outside the well-known port range (ports 0-1023) MUST NOT expire in less than two minutes of idle time. The value of the UDP state record idle timer MAY be configurable. The DEFAULT is five minutes.
REC-14：源端口和目标端口都在已知端口范围（端口0-1023）之外的UDP流的状态记录不得在两分钟的空闲时间内过期。UDP状态记录空闲计时器的值可以配置。默认值为5分钟。
REC-15: A state record for a UDP flow where one or both of the source and destination ports are in the well-known port range (ports 0-1023) MAY expire after a period of idle time shorter than two minutes to facilitate the operation of the IANA-registered service assigned to the port in question.
REC-15:UDP流的状态记录，其中一个或两个源端口和目标端口均在已知端口范围（端口0-1023）内，空闲时间短于两分钟后可能会过期，以便于分配给相关端口的IANA注册服务的运行。
As [RFC4787] notes, outbound refresh is necessary for allowing the interior endpoint to keep the state record alive. Inbound refresh may be useful for applications with no outbound UDP traffic. However, allowing inbound refresh can allow an attacker in the exterior or a misbehaving application to keep a state record alive indefinitely. This could be a security risk. Also, if the process is repeated with different ports, over time, it could use up all the state record memory and resources in the filter.
正如[RFC4787]所指出的，出站刷新是允许内部端点保持状态记录活动的必要条件。入站刷新对于没有出站UDP通信的应用程序可能很有用。但是，允许入站刷新可能会使外部攻击者或行为不端的应用程序使状态记录无限期保持活动状态。这可能是一种安全风险。此外，如果使用不同的端口重复此过程，随着时间的推移，可能会耗尽筛选器中的所有状态记录内存和资源。
REC-16: A state record for a UDP flow MUST be refreshed when a packet is forwarded from the interior to the exterior, and it MAY be refreshed when a packet is forwarded in the reverse direction.
REC-16：当数据包从内部转发到外部时，UDP流的状态记录必须刷新，当数据包反向转发时，状态记录可能会刷新。
As described in Section 5 of [RFC4787], the connection-free semantics of UDP pose a difficulty for packet filters in trying to recognize which packets comprise an application flow and which are unsolicited. Various strategies have been used in IPv4/NAT gateways with differing effects.
如[RFC4787]第5节所述，UDP的无连接语义给数据包过滤器在试图识别哪些数据包包含应用程序流以及哪些数据包是未经请求的时带来了困难。IPv4/NAT网关中使用了各种策略，但效果不同。
REC-17: If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for UDP. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for TCP and other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
REC-17：如果应用程序透明性是最重要的，那么有状态数据包过滤器应该具有UDP的“端点独立过滤”行为。如果更严格的过滤行为是最重要的，那么过滤器应该具有“地址相关过滤”行为。过滤行为可以是网络管理员配置的选项，它可以独立于TCP和其他协议的过滤行为。默认情况下，在没有服务提供商管理的情况下用于资源调配的网关中，筛选行为应该与端点无关。
Application mechanisms may depend on the reception of ICMPv6 error messages triggered by the transmission of UDP messages. One such mechanism is path MTU discovery [RFC1981].
应用机制可能取决于UDP消息传输触发的ICMPv6错误消息的接收。其中一种机制是路径MTU发现[RFC1981]。
REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing UDP headers that match the flow state record.
REC-18：如果网关转发UDP流，它还必须转发包含与流状态记录匹配的UDP头的ICMPv6“目标不可访问”和“数据包太大”消息。
REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a UDP flow.
REC-19:接收任何类型的ICMPv6消息不得终止UDP流的状态记录。
REC-20: UDP-Lite flows [RFC3828] SHOULD be handled in the same way as UDP flows, except that the upper-layer transport protocol identifier for UDP-Lite is not the same as UDP; therefore, UDP packets MUST NOT match UDP-Lite state records, and vice versa.
REC-20:UDP Lite流[RFC3828]的处理方式应与UDP流相同，但UDP Lite的上层传输协议标识符与UDP不同；因此，UDP数据包必须与UDP Lite状态记录不匹配，反之亦然。
The Internet Protocol security (IPsec) suite offers greater flexibility and better overall security than the simple security of stateful packet filtering at network perimeters. Therefore, residential IPv6 gateways need not prohibit IPsec traffic flows.
Internet协议安全性（IPsec）套件提供了比网络周边有状态数据包过滤的简单安全性更大的灵活性和更好的总体安全性。因此，住宅IPv6网关不需要禁止IPsec流量。
REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with destination extension headers of type "Authentication Header (AH)" [RFC4302] in their outer IP extension header chain.
REC-21：在其默认操作模式下，IPv6网关不得禁止在其外部IP扩展头链中使用类型为“Authentication Header（AH）”[RFC4302]的目标扩展头向合法节点地址转发数据包。
REC-22: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with an upper-layer protocol of type "Encapsulating Security Payload (ESP)" [RFC4303] in their outer IP extension header chain.
REC-22：在默认操作模式下，IPv6网关不得禁止在其外部IP扩展头链中使用“封装安全有效负载（ESP）”[RFC4303]类型的上层协议向合法节点地址转发数据包。
REC-23: If a gateway forwards an ESP flow, it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing ESP headers that match the flow state record.
REC-23：如果网关转发ESP流，它还必须转发（反向）包含与流状态记录匹配的ESP头的ICMPv6“目的地不可访问”和“数据包太大”消息。
Internet Key Exchange (IKE) is a secure mechanism for performing mutual authentication, exchanging cryptographic material, and establishing IPsec Security Associations between peers. Residential IPv6 gateways are expected to facilitate the use of IPsec security policies by allowing inbound IKE flows.
Internet密钥交换（IKE）是一种安全机制，用于执行相互身份验证、交换加密材料以及在对等方之间建立IPsec安全关联。住宅IPv6网关通过允许入站IKE流，有望促进IPsec安全策略的使用。
REC-24: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of any UDP packets, to and from legitimate node addresses, with a destination port of 500, i.e., the port reserved by IANA for the Internet Key Exchange (IKE) protocol [RFC5996].
REC-24：在默认操作模式下，IPv6网关不得禁止将任何UDP数据包转发到合法节点地址或从合法节点地址转发，目标端口为500，即IANA为互联网密钥交换（IKE）协议保留的端口[RFC5996]。
REC-25: In all operating modes, IPv6 gateways SHOULD use filter state records for Encapsulating Security Payload (ESP) [RFC4303] that are indexable by a 3-tuple comprising the interior node address, the exterior node address, and the ESP protocol identifier. In particular, the IPv4/NAT method of indexing state records also by the security parameters index (SPI) SHOULD NOT be used. Likewise, any mechanism that depends on detection of Internet Key Exchange (IKE) [RFC5996] initiations SHOULD NOT be used.
REC-25：在所有操作模式下，IPv6网关应使用筛选器状态记录来封装安全有效负载（ESP）[RFC4303]，该记录可通过包含内部节点地址、外部节点地址和ESP协议标识符的三元组进行索引。特别是，不应使用同样通过安全参数索引（SPI）对状态记录进行索引的IPv4/NAT方法。同样，不应使用任何依赖于检测Internet密钥交换（IKE）[RFC5996]启动的机制。
The Host Identity Protocol (HIP) is a secure mechanism for establishing host identity and secure communications between authenticated hosts. Residential IPv6 gateways need not prohibit inbound HIP flows.
主机身份协议（HIP）是一种安全机制，用于在经过身份验证的主机之间建立主机身份和安全通信。住宅IPv6网关不需要禁止入站HIP流。
REC-26: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with destination extension headers of type "Host Identity Protocol (HIP)" [RFC5201] in their outer IP extension header chain.
REC-26：在其默认操作模式下，IPv6网关不得禁止在其外部IP扩展头链中使用类型为“Host Identity Protocol（HIP）”[RFC5201]的目标扩展头向合法节点地址转发数据包。
Mobility support in IPv6 [RFC3775] relies on the use of an encapsulation mechanism in flows between mobile nodes and their correspondent nodes, involving the use of the Type 2 IPv6 Routing Header, the Home Address destination header option, and the Mobility
IPv6[RFC3775]中的移动性支持依赖于在移动节点及其对应节点之间的流中使用封装机制，包括使用类型2 IPv6路由报头、归属地址-目的地报头选项和移动性
extension header. In contrast to mobility support in IPv4, mobility is a standard feature of IPv6, and no security benefit is generally to be gained by denying communications with either interior or exterior mobile nodes.
扩展标题。与IPv4中的移动性支持不同，移动性是IPv6的一个标准功能，通常不通过拒绝与内部或外部移动节点的通信来获得安全好处。
Not all usage scenarios of mobility support in IPv6 are expected to be compatible with IPv6 simple security. In particular, exterior mobile nodes are expected to be prohibited from establishing bindings with interior correspondent nodes by the filtering of unsolicited inbound Mobility Header messages, unless they are the subject of an IPsec security policy.
并非所有IPv6中移动支持的使用场景都希望与IPv6简单安全兼容。特别是，外部移动节点被禁止通过过滤未经请求的入站移动报头消息与内部对应节点建立绑定，除非它们是IPsec安全策略的主体。
REC-27: The state records for flows initiated by outbound packets that bear a Home Address destination option [RFC3775] are distinguished by the addition of the home address of the flow as well as the interior care-of address. IPv6 gateways MUST NOT prohibit the forwarding of any inbound packets bearing type 2 routing headers, which otherwise match a flow state record, and where A) the address in the destination field of the IPv6 header matches the interior care-of address of the flow, and B) the Home Address field in the Type 2 Routing Header matches the home address of the flow.
REC-27：带有家庭地址目的地选项[RFC3775]的出站数据包启动的流的状态记录通过添加流的家庭地址以及内部转交地址来区分。IPv6网关不得禁止转发任何带有类型2路由报头的入站数据包，否则这些报头将与流状态记录匹配，其中a）IPv6报头的目的地字段中的地址与流的内部转交地址匹配，和B）类型2路由报头中的Home Address字段与流的Home Address匹配。
REC-28: Valid sequences of Mobility Header [RFC3775] packets MUST be forwarded for all outbound and explicitly permitted inbound Mobility Header flows.
REC-28：必须为所有出站和明确允许的入站移动报头流转发有效的移动报头序列[RFC3775]数据包。
REC-29: If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward, in both directions, the IPv4 and IPv6 packets that are encapsulated in IPv6 associated with the tunnel between the home agent and the correspondent node.
REC-29：如果网关转发移动报头[RFC3775]流，那么它还必须在两个方向上转发封装在IPv6中的IPv4和IPv6数据包，这些数据包与归属代理和对应节点之间的隧道相关。
REC-30: If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing any headers that match the associated flow state records.
REC-30：如果网关转发移动报头[RFC3775]流，那么它还必须转发（反向）ICMPv6“目的地不可到达”和“数据包太大”消息，其中包含与相关流状态记录匹配的任何报头。
Most Internet applications use connection-oriented transport protocols with orderly release semantics. These protocols include TCP, SCTP, DCCP, and potentially any future IETF Standards-Track transport protocols that use such semantics. Stateful packet filters track the state of individual transport flows and prohibit the forwarding of packets that do not match the state of an active flow and do not conform to a rule for the automatic creation of such state.
大多数Internet应用程序使用具有有序释放语义的面向连接的传输协议。这些协议包括TCP、SCTP、DCCP，以及潜在的任何未来IETF标准跟踪使用这种语义的传输协议。有状态数据包筛选器跟踪单个传输流的状态，并禁止转发与活动流状态不匹配且不符合自动创建此类状态规则的数据包。
An interior endpoint initiates a TCP flow through a stateful packet filter by sending a SYN packet. The filter allocates (or reuses) a filter state record for the flow. The state record defines the interior and exterior IP addresses and ports used for forwarding all packets for that flow.
内部端点通过发送SYN数据包，通过有状态数据包过滤器发起TCP流。筛选器为流分配（或重用）筛选器状态记录。状态记录定义用于转发该流的所有数据包的内部和外部IP地址和端口。
Some peer-to-peer applications use an alternate method of connection initiation termed "simultaneous-open" ([RFC0793], Figure 8) to traverse stateful filters. In the simultaneous-open mode of operation, both peers send SYN packets for the same TCP flow. The SYN packets cross in the network. Upon receiving the other end's SYN packet, each end responds with a SYN-ACK packet, which also cross in the network. The connection is established at each endpoint once the SYN-ACK packets are received.
一些对等应用程序使用另一种称为“同时打开”（图8中的[RFC0793]）的连接启动方法来遍历有状态过滤器。在同时打开的操作模式下，两个对等方为相同的TCP流发送SYN数据包。SYN数据包在网络中交叉。在接收到另一端的SYN数据包后，每一端用SYN-ACK数据包进行响应，该数据包也在网络中交叉。一旦接收到SYN-ACK数据包，就会在每个端点建立连接。
To provide stateful packet filtering service for TCP, it is necessary for a filter to receive, process, and forward all packets for a flow that conform to valid transitions of the TCP state machine ([RFC0793], Figure 6).
要为TCP提供有状态数据包过滤服务，过滤器必须接收、处理和转发符合TCP状态机有效转换的流的所有数据包（[RFC0793]，图6）。
REC-31: All valid sequences of TCP packets (defined in [RFC0793]) MUST be forwarded for outbound flows and explicitly permitted inbound flows. In particular, both the normal TCP 3-way handshake mode of operation and the simultaneous-open mode of operation MUST be supported.
REC-31:TCP数据包的所有有效序列（在[RFC0793]中定义）必须针对出站流和明确允许的入站流进行转发。特别是，必须支持正常的TCP 3路握手操作模式和同时打开操作模式。
It is possible to reconstruct enough of the state of a TCP flow to allow forwarding between an interior and exterior node, even when the filter starts operating after TCP enters the established state. In this case, because the filter has not seen the TCP window-scale option, it is not possible for the filter to enforce the TCP window invariant by dropping out-of-window segments.
可以重构足够多的TCP流状态，以允许内部和外部节点之间的转发，即使在TCP进入已建立状态后过滤器开始运行时也是如此。在这种情况下，由于筛选器未看到TCP窗口缩放选项，因此筛选器无法通过退出窗口段来强制执行TCP窗口不变。
REC-32: The TCP window invariant MUST NOT be enforced on flows for which the filter did not detect whether the window-scale option (see [RFC1323]) was sent in the 3-way handshake or simultaneous-open.
REC-32：对于筛选器未检测到窗口缩放选项（请参见[RFC1323]）是以三向握手还是同时打开的方式发送的流，不得强制执行TCP窗口不变量。
A stateful filter can allow an existing state record to be reused by an externally initiated flow if its security policy permits. Several different policies are possible, as described in [RFC4787] and extended in [RFC5382].
如果安全策略允许，有状态筛选器可以允许外部启动的流重用现有状态记录。可以使用几种不同的策略，如[RFC4787]中所述，并在[RFC5382]中进行了扩展。
REC-33: If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for TCP. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering"
REC-33：如果应用程序透明性是最重要的，那么有状态数据包过滤器应该具有TCP的“端点独立过滤”行为。如果更严格的过滤行为是最重要的，那么过滤器应该具有“地址相关过滤”
behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for UDP and other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
行为过滤行为可以是网络管理员配置的选项，它可以独立于UDP和其他协议的过滤行为。默认情况下，在没有服务提供商管理的情况下用于资源调配的网关中，筛选行为应该与端点无关。
If an inbound SYN packet is filtered, either because a corresponding state record does not exist or because of the filter's normal behavior, a filter has two basic choices: to discard the packet silently, or to signal an error to the sender. Signaling an error through ICMPv6 messages allows the sender to detect that the SYN did not reach the intended destination. Discarding the packet, on the other hand, allows applications to perform simultaneous-open more reliably. A more detailed discussion of this issue can be found in [RFC5382], but the basic outcome of it is that filters need to wait on signaling errors until simultaneous-open will not be impaired.
如果由于相应的状态记录不存在或由于筛选器的正常行为而对入站SYN数据包进行了筛选，则筛选器有两个基本选择：以静默方式丢弃数据包，或向发送方发送错误信号。通过ICMPv6消息发出错误信号允许发送方检测SYN未到达预期目的地。另一方面，丢弃数据包允许应用程序更可靠地执行同步打开。[RFC5382]中对此问题进行了更详细的讨论，但其基本结果是，过滤器需要等待信号错误，直到同时打开不会受损。
REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) to any unsolicited inbound SYN packet after waiting at least 6 seconds without first forwarding the associated outbound SYN or SYN/ACK from the interior peer.
REC-34：默认情况下，网关在等待至少6秒钟后，必须使用ICMPv6“Destination Unreachable”错误代码1（与目的地的通信管理禁止）响应任何未经请求的入站SYN数据包，而不首先从内部对等方转发相关的出站SYN或SYN/ACK。
A TCP filter maintains state associated with in-progress connections and established flows. Because of this, a filter is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the interior attempts to cause the filter to exhaust its capacity for creating state records. To defend against such attacks, a filter needs to abandon unused state records after a sufficiently long period of idleness.
TCP筛选器维护与正在进行的连接和已建立的流关联的状态。因此，筛选器容易受到资源耗尽攻击，内部攻击者（或病毒）会试图使筛选器耗尽其创建状态记录的能力。为了抵御此类攻击，过滤器需要在闲置足够长的时间后放弃未使用的状态记录。
A common method used for TCP filters in IPv4/NAT gateways is to abandon preferentially flow state records for crashed endpoints, followed by closed flows and partially open flows. A gateway can check if an endpoint for a session has crashed by sending a TCP keep-alive packet on behalf of the other endpoint and receiving a TCP RST packet in response. If the gateway cannot determine whether the endpoint is active, then the associated state record needs to be retained until the TCP flow has been idle for some time.
IPv4/NAT网关中TCP筛选器使用的一种常用方法是优先放弃崩溃端点的流状态记录，然后是关闭流和部分打开流。网关可以通过代表另一个端点发送TCP保持活动数据包并接收TCP RST数据包作为响应来检查会话的端点是否已崩溃。如果网关无法确定端点是否处于活动状态，则需要保留关联的状态记录，直到TCP流空闲一段时间。
Note: An established TCP flow can stay idle (but live) indefinitely; hence, there is no fixed value for an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by recommendations in [RFC1122] and [RFC4294] can reduce the chances of abandoning a live flow.
注意：已建立的TCP流可以无限期地保持空闲（但活动）；因此，不存在适用于所有应用程序的空闲超时的固定值。但是，由[RFC1122]和[RFC4294]中的建议激发的大空闲超时可以减少放弃活动流的机会。
TCP flows can stay in the established phase indefinitely without exchanging packets. Some end-hosts can be configured to send keep-alive packets on such idle flows; by default, such packets are sent every two hours, if enabled [RFC1122]. Consequently, a filter that waits for slightly over two hours can detect idle flows with keep-alive packets being sent at the default rate. TCP flows in the partially open or closing phases, on the other hand, can stay idle for at most four minutes while waiting for in-flight packets to be delivered [RFC1122].
TCP流可以无限期地停留在已建立的阶段，而无需交换数据包。一些终端主机可以配置为在这种空闲流上发送保持活动的数据包；默认情况下，如果启用[RFC1122]，则每两小时发送一次此类数据包。因此，等待稍超过两小时的过滤器可以检测空闲流，并以默认速率发送保持活动的数据包。另一方面，处于部分打开或关闭阶段的TCP流在等待传输中的数据包时最多可以保持空闲四分钟[RFC1122]。
The "established flow idle-timeout" for a stateful packet filter is defined as the minimum time a TCP flow in the established phase must remain idle before the filter considers the associated state record a candidate for collection. The "transitory flow idle-timeout" for a filter is defined as the minimum time a TCP flow in the partially open or closing phases must remain idle before the filter considers the associated state record a candidate for collection. TCP flows in the TIME-WAIT state are not affected by the "transitory flow idle-timeout" parameter.
有状态数据包筛选器的“已建立流空闲超时”定义为在筛选器将相关状态记录视为收集候选之前，TCP流在已建立阶段必须保持空闲的最短时间。筛选器的“临时流空闲超时”定义为在筛选器将相关状态记录视为收集候选之前，TCP流在部分打开或关闭阶段必须保持空闲的最短时间。处于TIME-WAIT状态的TCP流不受“瞬态流空闲超时”参数的影响。
REC-35: If a gateway cannot determine whether the endpoints of a TCP flow are active, then it MAY abandon the state record if it has been idle for some time. In such cases, the value of the "established flow idle-timeout" MUST NOT be less than two hours four minutes, as discussed in [RFC5382]. The value of the "transitory flow idle-timeout" MUST NOT be less than four minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-35：如果网关无法确定TCP流的端点是否处于活动状态，那么如果状态记录已空闲一段时间，它可能会放弃状态记录。在这种情况下，“已建立的流空闲超时”的值不得小于2小时4分钟，如[RFC5382]中所述。“瞬态流量空闲超时”的值不得小于四分钟。空闲超时值可由网络管理员配置。
Behavior for handling RST packets or TCP flows in the TIME-WAIT state is left unspecified. A gateway MAY hold state for a flow in the TIME-WAIT state to accommodate retransmissions of the last ACK. However, since the TIME-WAIT state is commonly encountered by interior endpoints properly closing the TCP flow, holding state for a closed flow can limit the throughput of flows through a gateway with limited resources. [RFC1337] discusses hazards associated with TIME-WAIT assassination.
未指定在等待时间状态下处理RST数据包或TCP流的行为。网关可以在时间等待状态中保持流的状态，以适应最后ACK的重传。但是，由于内部端点通常会遇到正确关闭TCP流的等待时间状态，因此保持关闭流的状态可能会限制通过资源有限的网关的流吞吐量。[RFC1337]讨论了与等待时间暗杀相关的危险。
The handling of non-SYN packets for which there is no active state record is left unspecified. Such packets can be received if the gateway abandons a live flow, or abandons a flow in the TIME-WAIT state before the four-minute TIME-WAIT period expires. The decision either to discard or to respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) is left up to the implementation.
没有活动状态记录的非SYN数据包的处理未指定。如果网关放弃实时流，或者在四分钟等待时间到期之前放弃处于等待状态的流，则可以接收此类数据包。放弃或使用ICMPv6“Destination Unreachable”（目标不可访问）错误代码1（与目标的通信被行政禁止）进行响应的决定由实现来决定。
Behavior for notifying endpoints when abandoning live flows is left unspecified. When a gateway abandons a live flow, for example due to a timeout expiring, the filter MAY send a TCP RST packet to each
未指定放弃活动流时通知端点的行为。当网关放弃实时流时，例如由于超时过期，过滤器可以向每个网关发送TCP RST数据包
endpoint on behalf of the other. Sending a RST notification allows endpoint applications to recover more quickly; however, notifying endpoints might not always be possible if, for example, state records are lost due to power interruption.
端点代表另一个端点。发送RST通知允许端点应用程序更快地恢复；但是，如果状态记录由于电源中断而丢失，则通知端点可能并不总是可能的。
Several TCP mechanisms depend on the reception of ICMPv6 error messages triggered by the transmission of TCP segments. One such mechanism is path MTU discovery, which is required for correct operation of TCP.
有几种TCP机制依赖于TCP段传输触发的ICMPv6错误消息的接收。其中一种机制是路径MTU发现，这是TCP正确运行所必需的。
REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing TCP headers that match the flow state record.
REC-36：如果网关转发TCP流，它还必须转发包含与流状态记录匹配的TCP头的ICMPv6“目标不可访问”和“数据包太大”消息。
REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a TCP flow.
REC-37:接收任何类型的ICMPv6消息不得终止TCP流的状态记录。
Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows can be terminated at multiple network addresses, IPv6 simple security functions cannot achieve full transparency for SCTP applications. In multipath traversal scenarios, full transparency requires coordination between all the packet filter processes in the various paths between the endpoint network addresses. Such coordination is not "simple", and it is, therefore, beyond the scope of this recommendation.
由于流控制传输协议（SCTP）[RFC4960]流可以在多个网络地址终止，IPv6简单的安全功能无法实现SCTP应用程序的完全透明。在多路径遍历场景中，完全透明要求在端点网络地址之间的各种路径中的所有包过滤进程之间进行协调。这种协调并非“简单”，因此超出了本建议的范围。
However, some SCTP applications are capable of tolerating the inherent unipath restriction of IPv6 simple security, even in multipath traversal scenarios. They expect connection-oriented filtering behaviors similar to those for TCP, but at the level of SCTP associations, not stream connections. This section describes specific recommendations for SCTP filtering for such traversal scenarios.
然而，一些SCTP应用程序能够容忍IPv6简单安全性固有的单路径限制，即使在多路径穿越场景中也是如此。他们期望类似于TCP的面向连接的过滤行为，但在SCTP关联级别，而不是流连接级别。本节描述了针对此类遍历场景的SCTP筛选的具体建议。
An interior endpoint initiates SCTP associations through a stateful packet filter by sending a packet comprising a single INIT chunk. The filter allocates (or reuses) a filter state record for the association. The state record defines the interior and exterior IP addresses and the observed verification tag used for forwarding packets in that association.
内部端点通过发送包含单个INIT块的数据包，通过有状态数据包过滤器发起SCTP关联。筛选器为关联分配（或重用）筛选器状态记录。状态记录定义内部和外部IP地址以及用于在该关联中转发数据包的观察到的验证标记。
Some peer-to-peer SCTP applications use an alternate method of association initiation, termed "simultaneous-open", to traverse stateful filters. In the simultaneous-open mode of operation, both peers send INIT chunks at the same time to establish an association. Upon receiving the other end's INIT chunk, each end responds with an
一些对等SCTP应用程序使用另一种关联启动方法，称为“同时打开”，以遍历有状态过滤器。在同步开放操作模式下，两个对等方同时发送INIT块以建立关联。在接收到另一端的INIT块时，每一端都用一个
INIT-ACK packet, which is expected to traverse the same path in reverse. Because only one SCTP association may exist between any two network addresses, one of the peers in the simultaneous-open mode of operation will send an ERROR or ABORT chunk along with the INIT-ACK chunk. The association is established at each endpoint once an INIT-ACK chunk without an ERROR or ABORT chunk is received at one end.
INIT-ACK数据包，该数据包应反向穿过同一路径。由于任何两个网络地址之间可能只存在一个SCTP关联，因此同时打开操作模式下的一个对等方将发送错误或中止块以及INIT-ACK块。一旦在一端接收到没有错误或中止块的INIT-ACK块，就会在每个端点建立关联。
To provide stateful packet filtering service for SCTP, it is necessary for a filter to receive, process, and forward all packets for an association that conform to valid transitions of the SCTP state machine ([RFC4960], Figure 3).
为了为SCTP提供有状态数据包过滤服务，过滤器必须接收、处理和转发符合SCTP状态机有效转换的关联的所有数据包（[RFC4960]，图3）。
REC-38: All valid sequences of SCTP packets (defined in [RFC4960]) MUST be forwarded for outbound associations and explicitly permitted inbound associations. In particular, both the normal SCTP association establishment and the simultaneous-open mode of operation MUST be supported.
REC-38:SCTP数据包的所有有效序列（在[RFC4960]中定义）必须转发给出站关联和明确允许的入站关联。特别是，必须支持正常的SCTP关联建立和同时开放的操作模式。
If an inbound INIT packet is filtered, either because a corresponding state record does not exist or because of the filter's normal behavior, a filter has two basic choices: to discard the packet silently, or to signal an error to the sender. Signaling an error through ICMPv6 messages allows the sender to detect that the INIT packet did not reach the intended destination. Discarding the packet, on the other hand, allows applications to perform simultaneous-open more reliably. Delays in signaling errors can prevent the impairment of the simultaneous-open mode of operation.
如果由于相应的状态记录不存在或由于筛选器的正常行为而过滤入站INIT数据包，则筛选器有两个基本选择：以静默方式丢弃数据包，或向发送方发送错误信号。通过ICMPv6消息发出错误信号允许发送方检测到初始数据包未到达预期目的地。另一方面，丢弃数据包允许应用程序更可靠地执行同步打开。信号错误的延迟可防止同时开放操作模式的损害。
REC-39: By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited), to any unsolicited inbound INIT packet after waiting at least 6 seconds without first forwarding the associated outbound INIT from the interior peer.
REC-39：默认情况下，网关必须在等待至少6秒钟后，使用ICMPv6“Destination Unreachable”（目的地不可访问）错误代码1（与目的地的通信管理禁止）响应任何未经请求的入站初始化数据包，而不首先从内部对等方转发相关的出站初始化。
An SCTP filter maintains state associated with in-progress and established associations. Because of this, a filter is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the interior attempts to cause the filter to exhaust its capacity for creating state records. To defend against such attacks, a filter needs to abandon unused state records after a sufficiently long period of idleness.
SCTP筛选器维护与正在进行和已建立的关联相关的状态。因此，筛选器容易受到资源耗尽攻击，内部攻击者（或病毒）会试图使筛选器耗尽其创建状态记录的能力。为了抵御此类攻击，过滤器需要在闲置足够长的时间后放弃未使用的状态记录。
A common method used for TCP filters in IPv4/NAT gateways is to abandon preferentially sessions for crashed endpoints, followed by closed associations and partially opened associations. A similar method is an option for SCTP filters in IPv6 gateways. A gateway can check if an endpoint for an association has crashed by sending
IPv4/NAT网关中TCP筛选器使用的一种常见方法是优先放弃崩溃端点的会话，然后是关闭的关联和部分打开的关联。IPv6网关中的SCTP筛选器也可以使用类似的方法。网关可以通过发送消息来检查关联的端点是否已崩溃
HEARTBEAT chunks and looking for the HEARTBEAT ACK response. If the gateway cannot determine whether the endpoint is active, then the associated state record needs to be retained until the SCTP association has been idle for some time.
HEARTBEAT块并查找HEARTBEAT ACK响应。如果网关无法确定端点是否处于活动状态，则需要保留关联的状态记录，直到SCTP关联空闲一段时间。
Note: An established SCTP association can stay idle (but live) indefinitely; hence, there is no fixed value of an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by recommendations in [RFC4294] can reduce the chances of abandoning a live association.
注意：已建立的SCTP关联可以无限期地保持空闲（但有效）；因此，不存在适用于所有应用程序的空闲超时的固定值。但是，由[RFC4294]中的建议引发的大量空闲超时可以减少放弃实时关联的机会。
SCTP associations can stay in the ESTABLISHED state indefinitely without exchanging packets. Some end-hosts can be configured to send HEARTBEAT chunks on such idle associations, but [RFC4960] does not specify (or even suggest) a default time interval. A filter that waits for slightly over two hours can detect idle associations with HEARTBEAT packets being sent at the same rate as most hosts use for TCP keep-alive, which is a reasonably similar system for this purpose. SCTP associations in the partially open or closing states, on the other hand, can stay idle for at most four minutes while waiting for in-flight packets to be delivered (assuming the suggested SCTP protocol parameter values in Section 15 of [RFC4960]).
SCTP关联可以无限期地保持在已建立的状态，而无需交换数据包。一些终端主机可以配置为在这种空闲关联上发送心跳数据块，但是[RFC4960]没有指定（甚至没有建议）默认时间间隔。等待时间略超过两个小时的过滤器可以检测到与心跳数据包的空闲关联，心跳数据包的发送速率与大多数主机用于TCP保持活动的速率相同，这是一个相当类似的系统。另一方面，处于部分打开或关闭状态的SCTP关联在等待传送飞行中的数据包时最多可以保持空闲四分钟（假设[RFC4960]第15节中建议的SCTP协议参数值）。
The "established association idle-timeout" for a stateful packet filter is defined as the minimum time an SCTP association in the established phase must remain idle before the filter considers the corresponding state record a candidate for collection. The "transitory association idle-timeout" for a filter is defined as the minimum time an SCTP association in the partially open or closing phases must remain idle before the filter considers the corresponding state record a candidate for collection.
有状态数据包筛选器的“已建立关联空闲超时”定义为在筛选器将相应状态记录视为收集候选之前，已建立阶段中的SCTP关联必须保持空闲的最短时间。筛选器的“临时关联空闲超时”定义为在筛选器将相应状态记录视为收集候选之前，部分打开或关闭阶段的SCTP关联必须保持空闲的最短时间。
REC-40: If a gateway cannot determine whether the endpoints of an SCTP association are active, then it MAY abandon the state record if it has been idle for some time. In such cases, the value of the "established association idle-timeout" MUST NOT be less than two hours four minutes. The value of the "transitory association idle-timeout" MUST NOT be less than four minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-40：如果网关无法确定SCTP关联的端点是否处于活动状态，那么如果状态记录已空闲一段时间，它可能会放弃状态记录。在这种情况下，“已建立关联空闲超时”的值不得小于2小时4分钟。“临时关联空闲超时”的值不得小于四分钟。空闲超时值可由网络管理员配置。
Behavior for handling ERROR and ABORT packets is left unspecified. A gateway MAY hold state for an association after its closing phases have completed to accommodate retransmissions of its final SHUTDOWN ACK packets. However, holding state for a closed association can limit the throughput of associations traversing a gateway with limited resources. The discussion in [RFC1337] regarding the hazards of TIME-WAIT assassination is relevant.
未指定处理错误和中止数据包的行为。网关可以在其关闭阶段完成后保持关联的状态，以适应其最终关闭ACK数据包的重新传输。但是，保持封闭关联的状态可能会限制通过资源有限的网关的关联的吞吐量。[RFC1337]中关于等待时间暗杀危害的讨论是相关的。
The handling of inbound non-INIT packets for which there is no active state record is left unspecified. Such packets can be received if the gateway abandons a live flow, or abandons an association in the closing states before the transitory association idle-timeout expires. The decision either to discard or to respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) is left to the implementation.
未指定没有活动状态记录的入站非INIT数据包的处理。如果网关在临时关联空闲超时到期之前放弃活动流，或者在关闭状态下放弃关联，则可以接收此类数据包。放弃或使用ICMPv6“Destination Unreachable”（目标不可访问）错误代码1（与目标的通信在管理上被禁止）进行响应的决定留给实现。
Behavior for notifying endpoints when abandoning live associations is left unspecified. When a gateway abandons a live association, for example due to a timeout expiring, the filter MAY send an ABORT packet to each endpoint on behalf of the other. Sending an ABORT notification allows endpoint applications to recover more quickly; however, notifying endpoints might not always be possible if, for example, state records are lost due to power interruption.
未指定放弃活动关联时通知端点的行为。当网关例如由于超时过期而放弃实时关联时，过滤器可以代表另一个端点向每个端点发送中止数据包。发送中止通知允许端点应用程序更快地恢复；但是，如果状态记录由于电源中断而丢失，则通知端点可能并不总是可能的。
Several SCTP mechanisms depend on the reception of ICMPv6 error messages triggered by the transmission of SCTP packets.
一些SCTP机制依赖于接收由SCTP数据包传输触发的ICMPv6错误消息。
REC-41: If a gateway forwards an SCTP association, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing SCTP headers that match the association state record.
REC-41：如果网关转发SCTP关联，它还必须转发包含与关联状态记录匹配的SCTP头的ICMPv6“目标不可访问”和“数据包太大”消息。
REC-42: Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for an SCTP association.
REC-42:接收任何类型的ICMPv6消息不得终止SCTP关联的状态记录。
The connection semantics described in the "Datagram Congestion Control Protocol (DCCP)" [RFC4340] are very similar to those of TCP. An interior endpoint initiates a DCCP flow through a stateful packet filter by sending a DCCP-Request packet. Simultaneous-open is not defined for DCCP.
“数据报拥塞控制协议（DCCP）”[RFC4340]中描述的连接语义与TCP非常相似。内部端点通过发送DCCP请求数据包，通过有状态数据包过滤器发起DCCP流。未为DCCP定义同时打开。
In order to provide stateful packet filtering service for DCCP, it is necessary for a filter to receive, process, and forward all packets for a flow that conform to valid transitions of the DCCP state machine ([RFC4340], Section 8).
为了为DCCP提供有状态数据包过滤服务，过滤器必须接收、处理和转发符合DCCP状态机有效转换的流的所有数据包（[RFC4340]，第8节）。
REC-43: All valid sequences of DCCP packets (defined in [RFC4340]) MUST be forwarded for all flows to exterior servers, and for any flows to interior servers that have explicitly permitted service codes.
REC-43:DCCP数据包的所有有效序列（定义见[RFC4340]）必须转发给外部服务器的所有流，以及明确允许服务代码的内部服务器的任何流。
It is possible to reconstruct enough of the state of a DCCP flow to allow forwarding between an interior and exterior node, even when the filter starts operating after DCCP enters the OPEN state. Also, a filter can allow an existing state record to be reused by an externally initiated flow if its security policy permits. As with TCP, several different policies are possible, with a good discussion of the issue involved presented in [RFC4787] and extended in [RFC5382].
可以重构足够多的DCCP流状态，以允许内部和外部节点之间的转发，即使在DCCP进入打开状态后过滤器开始工作时也是如此。此外，如果安全策略允许，筛选器可以允许外部启动的流重用现有状态记录。与TCP一样，有几种不同的策略是可能的，在[RFC4787]中对涉及的问题进行了很好的讨论，并在[RFC5382]中进行了扩展。
If an inbound DCCP-Request packet is filtered, either because a corresponding state record does not already exist for it or because of the filter's normal behavior of refusing flows not explicitly permitted, then a filter has two basic choices: to discard the packet silently, or to signal an error to the sender. Signaling an error through ICMPv6 messages allows the sender to detect that the DCCP-Request did not reach the intended destination. Discarding the packet, on the other hand, only delays the failure to connect and provides no measurable security.
如果对入站DCCP请求数据包进行筛选，或者是因为该数据包的相应状态记录不存在，或者是因为该筛选器拒绝未明确允许的流的正常行为，那么筛选器有两个基本选择：以静默方式丢弃该数据包，或者向发送方发送错误信号。通过ICMPv6消息发出错误信号允许发送方检测DCCP请求未到达预期目的地。另一方面，丢弃数据包只会延迟连接失败，并且不会提供可测量的安全性。
A DCCP filter maintains state associated with in-progress connections and established flows. Because of this, a filter is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the interior attempts to cause the filter to exhaust its capacity for creating state records. To prevent such an attack, a filter needs to abandon unused state records after a sufficiently long period of idleness.
DCCP筛选器维护与正在进行的连接和已建立的流相关的状态。因此，筛选器容易受到资源耗尽攻击，内部攻击者（或病毒）会试图使筛选器耗尽其创建状态记录的能力。为了防止这种攻击，过滤器需要在足够长的空闲时间后放弃未使用的状态记录。
A common method used for TCP filters in IPv4/NAT gateways is to abandon preferentially sessions for crashed endpoints, followed by closed TCP flows and partially open flows. No such method exists for DCCP, and flows can stay in the OPEN phase indefinitely without exchanging packets. Hence, there is no fixed value for an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by recommendations in [RFC4294] can reduce the chances of abandoning a live flow.
IPv4/NAT网关中用于TCP筛选器的常用方法是优先放弃崩溃端点的会话，然后是关闭的TCP流和部分打开的流。DCCP不存在这样的方法，流可以无限期地停留在开放阶段而不交换数据包。因此，不存在适用于所有应用程序的空闲超时的固定值。但是，由[RFC4294]中的建议激发的大空闲超时可以减少放弃活动流的机会。
DCCP flows in the partially open or closing phases can stay idle for at most eight minutes while waiting for in-flight packets to be delivered.
部分打开或关闭阶段的DCCP流在等待传输中的数据包时最多可以保持空闲八分钟。
The "open flow idle-timeout" for a stateful packet filter is defined as the minimum time a DCCP flow in the open state must remain idle before the filter considers the associated state record a candidate
有状态数据包筛选器的“开放流空闲超时”定义为处于开放状态的DCCP流在筛选器将相关状态记录视为候选之前必须保持空闲的最短时间
for collection. The "transitory flow idle-timeout" for a filter is defined as the minimum time a DCCP flow in the partially open or closing phases must remain idle before the filter considers the associated state record a candidate for collection. DCCP flows in the TIMEWAIT state are not affected by the "transitory flow idle-timeout" parameter.
收集。过滤器的“瞬态流空闲超时”定义为在过滤器将相关状态记录视为收集候选之前，DCCP流在部分打开或关闭阶段必须保持空闲的最短时间。处于TIMEWAIT状态的DCCP流不受“瞬态流空闲超时”参数的影响。
REC-44: A gateway MAY abandon a DCCP state record if it has been idle for some time. In such cases, the value of the "open flow idle-timeout" MUST NOT be less than two hours four minutes. The value of the "transitory flow idle-timeout" MUST NOT be less than eight minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-44：如果DCCP状态记录闲置一段时间，网关可能会放弃该记录。在这种情况下，“开放流空闲超时”的值不得小于2小时4分钟。“瞬态流空闲超时”的值不得小于8分钟。空闲超时值可由网络管理员配置。
Behavior for handling DCCP-Reset packets or flows in the TIMEWAIT state is left unspecified. A gateway MAY hold state for a flow in the TIMEWAIT state to accommodate retransmissions of the last DCCP-Reset. However, since the TIMEWAIT state is commonly encountered by interior endpoints properly closing the DCCP flow, holding state for a closed flow can limit the throughput of flows through a gateway with limited resources. [RFC1337] discusses hazards associated with TIME-WAIT assassination in TCP, and similar hazards exist for DCCP.
未指定在TIMEWAIT状态下处理DCCP重置数据包或流的行为。网关可以将流的状态保持在TIMEWAIT状态，以适应最后一次DCCP重置的重传。但是，由于正确关闭DCCP流的内部端点通常会遇到TIMEWAIT状态，因此保持关闭流的状态可能会限制通过资源有限的网关的流的吞吐量。[RFC1337]讨论了TCP中与等待时间暗杀相关的危险，以及DCCP中存在的类似危险。
The handling of non-SYN packets for which there is no active state record is left unspecified. Such packets can be received if the gateway abandons a live flow, or abandons a flow in the TIMEWAIT state before the four-minute 2MSL period (two times the maximum segment lifetime [RFC4340]) expires. The decision either to discard or to respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) is left up to the implementation.
没有活动状态记录的非SYN数据包的处理未指定。如果网关在四分钟2MSL周期（最大段生存期[RFC4340]的两倍）到期之前放弃实时流，或者放弃处于TIMEWAIT状态的流，则可以接收此类数据包。放弃或使用ICMPv6“Destination Unreachable”（目标不可访问）错误代码1（与目标的通信被行政禁止）进行响应的决定由实现来决定。
Behavior for notifying endpoints when abandoning live flows is left unspecified. When a gateway abandons a live flow, for example due to a timeout expiring, the filter MAY send a DCCP-Reset packet to each endpoint on behalf of the other. Sending a DCCP-Reset notification allows endpoint applications to recover more quickly; however, notifying endpoints might not always be possible if, for example, state records are lost due to power interruption.
未指定放弃活动流时通知端点的行为。当网关例如由于超时过期而放弃实时流时，过滤器可以代表另一个端点向每个端点发送DCCP重置数据包。发送DCCP重置通知允许端点应用程序更快地恢复；但是，如果状态记录由于电源中断而丢失，则通知端点可能并不总是可能的。
Several DCCP mechanisms depend on the reception of ICMPv6 error messages triggered by the transmission of DCCP packets. One such mechanism is path MTU discovery, which is required for correct operation.
有几种DCCP机制依赖于接收由DCCP数据包传输触发的ICMPv6错误消息。其中一种机制是路径MTU发现，这是正确操作所必需的。
REC-45: If an Internet gateway forwards a DCCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing DCCP headers that match the flow state record.
REC-45：如果Internet网关转发DCCP流，它还必须转发包含与流状态记录匹配的DCCP头的ICMPv6“目标不可访问”和“数据包太大”消息。
REC-46: Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a DCCP flow.
REC-46：接收任何类型的ICMPv6消息不得终止DCCP流的状态记录。
While IPv6 simple security is applicable to residential networks with only one Internet service provider at a time, the use of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] is necessary for communications with some multihomed exterior destinations. No special recommendations are made in this document for processing the Shim6 message format (protocol 140) beyond the recommendations in Section 3.2.2. The content of the Shim6 payload extension header may be ignored.
虽然IPv6简单安全性适用于一次只有一个Internet服务提供商的住宅网络，但对于与一些多宿外部目的地的通信，有必要使用IPv6的3级多宿Shim协议（Shim6）[RFC5533]。除第3.2.2节中的建议外，本文件中未对处理Shim6消息格式（协议140）提出特别建议。可以忽略Shim6有效负载扩展标头的内容。
REC-47: Valid sequences of packets bearing Shim6 payload extension headers in their outer IP extension header chains MUST be forwarded for all outbound and explicitly permitted flows. The content of the Shim6 payload extension header MAY be ignored for the purpose of state tracking.
REC-47：对于所有出站和明确允许的流，必须转发在其外部IP扩展头链中承载Shim6有效负载扩展头的数据包的有效序列。出于状态跟踪的目的，可以忽略Shim6有效负载扩展报头的内容。
Some applications expect to solicit traffic from exterior nodes without advance knowledge of the exterior addresses of their peers. This requirement is met by IPv4/NAT gateways, typically by the use of either the NAT Port Mapping Protocol [NAT-PMP] or the Universal Plug and Play Internet Gateway Device [UPnP-IGD] standardized device control protocol. On IPv4/NAT networks connected by gateways without such services, applications must use techniques like Session Traversal Utilities for NAT (STUN) [RFC5389] to obtain and maintain connectivity, despite the translation and filtering effects of NAT.
一些应用程序期望从外部节点请求通信量，而不事先知道其对等节点的外部地址。IPv4/NAT网关通常通过使用NAT端口映射协议[NAT-PMP]或通用即插即用互联网网关设备[UPnP IGD]标准化设备控制协议来满足这一要求。在由网关连接而没有此类服务的IPv4/NAT网络上，应用程序必须使用NAT会话遍历实用程序（STUN）[RFC5389]等技术来获取和维护连接，尽管NAT具有转换和过滤效果。
While NAT for IPv6 is unlikely to be used in most residential gateways, the simple security functions recommended by this document, and their filtering effects, are derived from comparable functions already in widespread use on the IPv4 Internet. A similar barrier to communication at passive listeners is a natural outcome of the deployment of NAT for IPv6. To avoid the need for IPv6 applications to use techniques like STUN for opening and maintaining dynamic filter state, something similar to NAT-PMP and UPnP-IGD, but without actually supporting NAT, could be deployed. Alas, no consensus has yet emerged in the Internet engineering community as to what is most appropriate for residential IPv6 usage scenarios.
虽然IPv6的NAT不太可能在大多数住宅网关中使用，但本文档推荐的简单安全功能及其过滤效果源自IPv4 Internet上已广泛使用的类似功能。被动侦听器上的通信障碍类似于IPv6 NAT部署的自然结果。为了避免IPv6应用程序需要使用STUN等技术来打开和维护动态过滤器状态，可以部署类似于NAT-PMP和UPnP IGD的东西，但实际上不支持NAT。遗憾的是，互联网工程界尚未就什么最适合住宅IPv6使用场景达成共识。
One proposal that has been offered is the Application Listener Discovery Protocol [WOODYATT-ALD] document. It remains to be seen whether the Internet Gateway Device profile of the Universal Plug and Play protocol will be extended for IPv6. Other proposals of note include the Middlebox Communication Protocol [RFC5189] and the Next Steps in Signaling framework [RFC4080]. Until a consensus emerges around a specific method, the following recommendations are the best guidance available.
提供的一个建议是应用程序侦听器发现协议[WOODYATT-ALD]文档。通用即插即用协议的Internet网关设备配置文件是否将扩展到IPv6，还有待观察。其他值得注意的建议包括中间箱通信协议[RFC5189]和信令框架中的下一步[RFC4080]。在就具体方法达成共识之前，以下建议是可用的最佳指南。
REC-48: Internet gateways with IPv6 simple security capabilities SHOULD implement a protocol to permit applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate.
REC-48：具有IPv6简单安全功能的互联网网关应实施一种协议，允许应用程序请求入站流量，而无需事先知道它们希望与之通信的外部节点的地址。
REC-49: Internet gateways with IPv6 simple security capabilities MUST provide an easily selected configuration option that permits a "transparent mode" of operation that forwards all unsolicited flows regardless of forwarding direction, i.e., not to use the IPv6 simple security capabilities of the gateway. The transparent mode of operation MAY be the default configuration.
REC-49：具有IPv6简单安全功能的互联网网关必须提供一个易于选择的配置选项，该选项允许“透明模式”的操作，该模式转发所有未经请求的流，而不管转发方向如何，即不使用网关的IPv6简单安全功能。透明操作模式可能是默认配置。
In general, "transparent mode" will enable more flexibility and reliability for applications that require devices to be contacted inside the home directly, particularly in the absence of a protocol as described in REC-48. Operating in transparent mode may come at the expense of security if there are IPv6 nodes in the home that do not have their own host-based firewall capability and require a firewall in the gateway in order not to be compromised.
一般而言，“透明模式”将为需要在家中直接接触设备的应用提供更大的灵活性和可靠性，特别是在没有REC-48中所述协议的情况下。如果家庭中的IPv6节点没有自己的基于主机的防火墙功能，并且需要在网关中安装防火墙以避免受到危害，则在透明模式下操作可能会牺牲安全性。
Subscriber-managed residential gateways are unlikely ever to be completely zero-configuration, but their administrators will very often possess no particular expertise in Internet engineering. In general, the specification of management interfaces for residential gateways is out of scope for this document, but the security of subscriber-managed gateways merits special attention here.
用户管理的住宅网关不太可能完全为零配置，但其管理员通常不具备互联网工程方面的专门知识。一般来说，住宅网关的管理接口规范不在本文件的范围内，但用户管理网关的安全性值得特别注意。
REC-50: By DEFAULT, subscriber-managed residential gateways MUST NOT offer management application services to the exterior network.
REC-50：默认情况下，用户管理的住宅网关不得向外部网络提供管理应用程序服务。
This section collects all of the recommendations made in this document into a convenient list.
本节将本文档中提出的所有建议收集到一个方便的列表中。
REC-1 Packets bearing multicast source addresses in their outer IPv6 headers MUST NOT be forwarded or transmitted on any interface.
在外部IPv6报头中包含多播源地址的REC-1数据包不得在任何接口上转发或传输。
REC-2 Packets bearing multicast destination addresses in their outer IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address Architecture" [RFC4007]) than the configured scope boundary level of the gateway MUST NOT be forwarded in any direction. The DEFAULT scope boundary level SHOULD be organization-local scope, and it SHOULD be configurable by the network administrator.
REC-2数据包在其外部IPv6报头中承载的多播目标地址的作用域等于或小于网关配置的作用域边界级别（请参阅“IPv6作用域地址体系结构”[RFC4007]），不得向任何方向转发。默认范围边界级别应为组织本地范围，并且应由网络管理员进行配置。
REC-3 Packets bearing source and/or destination addresses forbidden to appear in the outer headers of packets transmitted over the public Internet MUST NOT be forwarded. In particular, site-local addresses are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use of address blocks of types IPv4-Mapped Addresses, IPv4-Compatible Addresses, Documentation Prefix, and Overlay Routable Cryptographic Hash IDentifiers (ORCHID).
不得转发带有源地址和/或目的地址的REC-3数据包，这些地址禁止出现在通过公共互联网传输的数据包的外部报头中。特别是，[RFC3879]不推荐使用站点本地地址，[RFC5156]明确禁止使用IPv4映射地址、IPv4兼容地址、文档前缀和覆盖可路由加密哈希标识符（RAYD）类型的地址块。
REC-4 Packets bearing deprecated extension headers prior to their first upper-layer-protocol header SHOULD NOT be forwarded or transmitted on any interface. In particular, all packets with routing extension header type 0 [RFC2460] preceding the first upper-layer-protocol header MUST NOT be forwarded. See [RFC5095] for additional background.
不应在任何接口上转发或传输在其第一个上层协议头之前带有不推荐的扩展头的REC-4数据包。特别是，在第一上层协议报头之前具有路由扩展报头类型0[RFC2460]的所有数据包不得转发。更多背景信息，请参见[RFC5095]。
REC-5 Outbound packets MUST NOT be forwarded if the source address in their outer IPv6 header does not have a unicast prefix configured for use by globally reachable nodes on the interior network.
如果REC-5出站数据包的外部IPv6报头中的源地址没有配置供内部网络上的全局可访问节点使用的单播前缀，则不得转发该数据包。
REC-6 Inbound packets MUST NOT be forwarded if the source address in their outer IPv6 header has a global unicast prefix assigned for use by globally reachable nodes on the interior network.
如果REC-6入站数据包的外部IPv6报头中的源地址具有分配给内部网络上全局可访问节点使用的全局单播前缀，则不得转发该数据包。
REC-7 By DEFAULT, packets with unique local source and/or destination addresses [RFC4193] SHOULD NOT be forwarded to or from the exterior network.
REC-7默认情况下，具有唯一本地源和/或目标地址[RFC4193]的数据包不应转发到外部网络或从外部网络转发。
REC-8 By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server.
REC-8默认情况下，外部接口上接收的入站DNS查询不得由任何集成DNS解析服务器处理。
REC-9 Inbound DHCPv6 discovery packets [RFC3315] received on exterior interfaces MUST NOT be processed by any integrated DHCPv6 server or relay agent.
在外部接口上接收的REC-9入站DHCPv6发现数据包[RFC3315]不得由任何集成DHCPv6服务器或中继代理处理。
REC-10 IPv6 gateways SHOULD NOT forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing IP headers that do not match generic upper-layer transport state records.
REC-10 IPv6网关不应转发包含与通用上层传输状态记录不匹配的IP头的ICMPv6“目标不可访问”和“数据包太大”消息。
REC-11 If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for generic upper-layer transport protocols. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
REC-11如果应用程序透明性是最重要的，那么对于通用上层传输协议，有状态数据包过滤器应该具有“端点独立过滤”行为。如果更严格的过滤行为是最重要的，那么过滤器应该具有“地址相关过滤”行为。过滤行为可以是网络管理员可配置的选项，并且它可以独立于其他协议的过滤行为。默认情况下，在没有服务提供商管理的情况下用于资源调配的网关中，筛选行为应该与端点无关。
REC-12 Filter state records for generic upper-layer transport protocols MUST NOT be deleted or recycled until an idle timer not less than two minutes has expired without having forwarded a packet matching the state in some configurable amount of time. By DEFAULT, the idle timer for such state records is five minutes.
通用上层传输协议的REC-12过滤器状态记录不得删除或回收，直到空闲计时器超过不少于两分钟，且在某些可配置的时间内未转发与状态匹配的数据包。默认情况下，此类状态记录的空闲计时器为5分钟。
REC-13 Residential IPv6 gateways SHOULD provide a convenient means to update their firmware securely, for the installation of security patches and other manufacturer-recommended changes.
REC-13住宅IPv6网关应提供一种方便的方法来安全地更新其固件，以便安装安全补丁和其他制造商建议的更改。
REC-14 A state record for a UDP flow where both source and destination ports are outside the well-known port range (ports 0-1023) MUST NOT expire in less than two minutes of idle time. The value of the UDP state record idle timer MAY be configurable. The DEFAULT is five minutes.
REC-14源端口和目标端口都在已知端口范围（端口0-1023）之外的UDP流的状态记录不得在两分钟的空闲时间内过期。UDP状态记录空闲计时器的值可以配置。默认值为5分钟。
REC-15 A state record for a UDP flow where one or both of the source and destination ports are in the well-known port range (ports 0-1023) MAY expire after a period of idle time shorter than two minutes to facilitate the operation of the IANA-registered service assigned to the port in question.
REC-15一个UDP流的状态记录，其中一个或两个源端口和目标端口都在众所周知的端口范围（端口0-1023）内，空闲时间短于两分钟后可能会过期，以便于分配给相关端口的IANA注册服务的操作。
REC-16 A state record for a UDP flow MUST be refreshed when a packet is forwarded from the interior to the exterior, and it MAY be refreshed when a packet is forwarded in the reverse direction.
REC-16当数据包从内部转发到外部时，UDP流的状态记录必须刷新，当数据包反向转发时，状态记录可能会刷新。
REC-17 If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for UDP. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for TCP and other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
REC-17如果应用程序透明性是最重要的，那么有状态数据包过滤器应该具有UDP的“端点独立过滤”行为。如果更严格的过滤行为是最重要的，那么过滤器应该具有“地址相关过滤”行为。过滤行为可以是网络管理员配置的选项，它可以独立于TCP和其他协议的过滤行为。默认情况下，在没有服务提供商管理的情况下用于资源调配的网关中，筛选行为应该与端点无关。
REC-18 If a gateway forwards a UDP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing UDP headers that match the flow state record.
REC-18如果网关转发UDP流，它还必须转发包含与流状态记录匹配的UDP头的ICMPv6“目标不可访问”和“数据包太大”消息。
REC-19 Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a UDP flow.
REC-19接收任何类型的ICMPv6消息不得终止UDP流的状态记录。
REC-20 UDP-Lite flows [RFC3828] SHOULD be handled in the same way as UDP flows, except that the upper-layer transport protocol identifier for UDP-Lite is not the same as UDP; therefore, UDP packets MUST NOT match UDP-Lite state records, and vice versa.
REC-20 UDP Lite流[RFC3828]的处理方式应与UDP流相同，但UDP Lite的上层传输协议标识符与UDP不同；因此，UDP数据包必须与UDP Lite状态记录不匹配，反之亦然。
REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with destination extension headers of type "Authentication Header (AH)" [RFC4302] in their outer IP extension header chain.
REC-21在其默认操作模式下，IPv6网关不得禁止在其外部IP扩展头链中使用类型为“Authentication Header（AH）”[RFC4302]的目标扩展头向合法节点地址和从合法节点地址转发数据包。
REC-22 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with an upper-layer protocol of type "Encapsulating Security Payload (ESP)" [RFC4303] in their outer IP extension header chain.
REC-22在其默认操作模式下，IPv6网关不得禁止在其外部IP扩展头链中使用“封装安全有效负载（ESP）”[RFC4303]类型的上层协议向合法节点地址转发数据包。
REC-23 If a gateway forwards an ESP flow, it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing ESP headers that match the flow state record.
REC-23如果网关转发ESP流，它还必须转发（反向）包含与流状态记录匹配的ESP头的ICMPv6“目的地不可访问”和“数据包太大”消息。
REC-24 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of any UDP packets, to and from legitimate node addresses, with a destination port of 500, i.e., the port reserved by IANA for the Internet Key Exchange (IKE) Protocol [RFC5996].
REC-24在其默认操作模式下，IPv6网关不得禁止将任何UDP数据包转发到合法节点地址或从合法节点地址转发，目标端口为500，即IANA为互联网密钥交换（IKE）协议保留的端口[RFC5996]。
REC-25 In all operating modes, IPv6 gateways SHOULD use filter state records for Encapsulating Security Payload (ESP) [RFC4303] that are indexable by a 3-tuple comprising the interior node address, the exterior node address, and the ESP protocol identifier. In particular, the IPv4/NAT method of indexing state records also by security parameters index (SPI) SHOULD NOT be used. Likewise, any mechanism that depends on detection of Internet Key Exchange (IKE) [RFC5996] initiations SHOULD NOT be used.
REC-25在所有操作模式下，IPv6网关应使用筛选器状态记录来封装安全有效负载（ESP）[RFC4303]，该记录可通过包含内部节点地址、外部节点地址和ESP协议标识符的三元组进行索引。特别是，不应使用也通过安全参数索引（SPI）对状态记录进行索引的IPv4/NAT方法。同样，不应使用任何依赖于检测Internet密钥交换（IKE）[RFC5996]启动的机制。
REC-26 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with destination extension headers of type "Host Identity Protocol (HIP)" [RFC5201] in their outer IP extension header chain.
REC-26在其默认操作模式下，IPv6网关不得禁止在其外部IP扩展报头链中使用类型为“主机标识协议（HIP）”[RFC5201]的目标扩展报头向合法节点地址和从合法节点地址转发数据包。
REC-27 The state records for flows initiated by outbound packets that bear a Home Address destination option [RFC3775] are distinguished by the addition of the home address of the flow as well as the interior care-of address. IPv6 gateways MUST NOT prohibit the forwarding of any inbound packets bearing type 2 routing headers, which otherwise match a flow state record, and where A) the address in the destination field of the IPv6 header matches the interior care-of address of the flow, and B) the Home Address field in the Type 2 Routing Header matches the home address of the flow.
REC-27由带有家庭地址目的地选项[RFC3775]的出站数据包启动的流的状态记录通过添加流的家庭地址以及内部转交地址来区分。IPv6网关不得禁止转发任何带有类型2路由报头的入站数据包，否则这些报头将与流状态记录匹配，其中a）IPv6报头的目的地字段中的地址与流的内部转交地址匹配，和B）类型2路由报头中的Home Address字段与流的Home Address匹配。
REC-28 Valid sequences of Mobility Header [RFC3775] packets MUST be forwarded for all outbound and explicitly permitted inbound Mobility Header flows.
REC-28必须为所有出站和明确允许的入站移动报头流转发有效的移动报头序列[RFC3775]数据包。
REC-29 If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward, in both directions, the IPv4 and IPv6 packets that are encapsulated in IPv6 associated with the tunnel between the home agent and the correspondent node.
REC-29如果网关转发移动报头[RFC3775]流，那么它还必须在两个方向上转发封装在IPv6中的IPv4和IPv6数据包，这些数据包与归属代理和对应节点之间的隧道相关。
REC-30 If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing any headers that match the associated flow state records.
REC-30如果网关转发移动报头[RFC3775]流，则它还必须转发（反向）ICMPv6“目的地不可到达”和“数据包太大”消息，其中包含与相关流状态记录匹配的任何报头。
REC-31 All valid sequences of TCP packets (defined in [RFC0793]) MUST be forwarded for outbound flows and explicitly permitted inbound flows. In particular, both the normal TCP 3-way handshake mode of operation and the simultaneous-open mode of operation MUST be supported.
REC-31所有有效的TCP数据包序列（在[RFC0793]中定义）必须针对出站流和明确允许的入站流进行转发。特别是，必须支持正常的TCP 3路握手操作模式和同时打开操作模式。
REC-32 The TCP window invariant MUST NOT be enforced on flows for which the filter did not detect whether the window-scale option (see [RFC1323]) was sent in the 3-way handshake or simultaneous-open.
REC-32对于筛选器未检测到窗口缩放选项（请参见[RFC1323]）是以三向握手还是同时打开的方式发送的流，不得强制执行TCP窗口不变量。
REC-33 If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for TCP. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for UDP and other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
REC-33如果应用程序透明性是最重要的，那么有状态数据包过滤器应该具有TCP的“端点独立过滤”行为。如果更严格的过滤行为是最重要的，那么过滤器应该具有“地址相关过滤”行为。过滤行为可以是网络管理员配置的选项，它可以独立于UDP和其他协议的过滤行为。默认情况下，在没有服务提供商管理的情况下用于资源调配的网关中，筛选行为应该与端点无关。
REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited), to any unsolicited inbound SYN packet after waiting at least 6 seconds without first forwarding the associated outbound SYN or SYN/ACK from the interior peer.
REC-34默认情况下，网关在等待至少6秒钟后，必须使用ICMPv6“无法到达目的地”错误代码1（与目的地的通信管理禁止）响应任何未经请求的入站SYN数据包，而不首先从内部对等方转发相关的出站SYN或SYN/ACK。
REC-35 If a gateway cannot determine whether the endpoints of a TCP flow are active, then it MAY abandon the state record if it has been idle for some time. In such cases, the value of the "established flow idle-timeout" MUST NOT be less than two hours four minutes, as discussed in [RFC5382]. The value of the "transitory flow idle-timeout" MUST NOT be less than four minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-35如果网关无法确定TCP流的端点是否处于活动状态，则如果状态记录已空闲一段时间，它可能会放弃状态记录。在这种情况下，“已建立的流空闲超时”的值不得小于2小时4分钟，如[RFC5382]中所述。“瞬态流量空闲超时”的值不得小于四分钟。空闲超时值可由网络管理员配置。
REC-36 If a gateway forwards a TCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing TCP headers that match the flow state record.
REC-36如果网关转发TCP流，它还必须转发包含与流状态记录匹配的TCP头的ICMPv6“目标不可访问”和“数据包太大”消息。
REC-37 Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a TCP flow.
REC-37接收任何类型的ICMPv6消息不得终止TCP流的状态记录。
REC-38 All valid sequences of SCTP packets (defined in [RFC4960]) MUST be forwarded for outbound associations and explicitly permitted inbound associations. In particular, both the normal SCTP association establishment and the simultaneous-open mode of operation MUST be supported.
REC-38所有有效的SCTP数据包序列（在[RFC4960]中定义）必须转发给出站关联和明确允许的入站关联。特别是，必须支持正常的SCTP关联建立和同时开放的操作模式。
REC-39 By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) to any unsolicited inbound INIT packet after waiting at least 6 seconds without first forwarding the associated outbound INIT from the interior peer.
REC-39默认情况下，网关在等待至少6秒钟后，必须使用ICMPv6“Destination Unreachable”（目的地不可访问）错误代码1（与目的地的通信管理禁止）响应任何未经请求的入站初始化数据包，而不首先从内部对等方转发相关的出站初始化。
REC-40 If a gateway cannot determine whether the endpoints of an SCTP association are active, then it MAY abandon the state record if it has been idle for some time. In such cases, the value of the "established association idle-timeout" MUST NOT be less than two hours four minutes. The value of the "transitory association idle-timeout" MUST NOT be less than four minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-40如果网关无法确定SCTP关联的端点是否处于活动状态，则如果状态记录已空闲一段时间，则可能会放弃状态记录。在这种情况下，“已建立关联空闲超时”的值不得小于2小时4分钟。“临时关联空闲超时”的值不得小于四分钟。空闲超时值可由网络管理员配置。
REC-41 If a gateway forwards an SCTP association, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing SCTP headers that match the association state record.
REC-41如果网关转发SCTP关联，它还必须转发包含与关联状态记录匹配的SCTP头的ICMPv6“目的地不可访问”和“数据包太大”消息。
REC-42 Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for an SCTP association.
REC-42接收任何类型的ICMPv6消息不得终止SCTP关联的状态记录。
REC-43 All valid sequences of DCCP packets (defined in [RFC4340]) MUST be forwarded for all flows to exterior servers, and for any flows to interior servers with explicitly permitted service codes.
REC-43所有有效的DCCP数据包序列（在[RFC4340]中定义）必须转发给外部服务器的所有流，以及带有明确允许的服务代码的内部服务器的任何流。
REC-44 A gateway MAY abandon a DCCP state record if it has been idle for some time. In such cases, the value of the "open flow idle-timeout" MUST NOT be less than two hours four minutes. The value of the "transitory flow idle-timeout" MUST NOT be less than eight minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-44如果DCCP状态记录闲置一段时间，网关可能会放弃该记录。在这种情况下，“开放流空闲超时”的值不得小于2小时4分钟。“瞬态流空闲超时”的值不得小于8分钟。空闲超时值可由网络管理员配置。
REC-45 If an Internet gateway forwards a DCCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing DCCP headers that match the flow state record.
REC-45如果Internet网关转发DCCP流，它还必须转发包含与流状态记录匹配的DCCP头的ICMPv6“无法到达目的地”和“数据包太大”消息。
REC-46 Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a DCCP flow.
REC-46接收任何类型的ICMPv6消息不得终止DCCP流的状态记录。
REC-47 Valid sequences of packets bearing Shim6 payload extension headers in their outer IP extension header chains MUST be forwarded for all outbound and explicitly permitted flows. The content of the Shim6 payload extension header MAY be ignored for the purpose of state tracking.
REC-47必须为所有出站和明确允许的流转发在其外部IP扩展头链中承载Shim6有效负载扩展头的数据包的有效序列。出于状态跟踪的目的，可以忽略Shim6有效负载扩展报头的内容。
REC-48 Internet gateways with IPv6 simple security capabilities SHOULD implement a protocol to permit applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate.
具有IPv6简单安全功能的REC-48互联网网关应实施一种协议，允许应用程序在不预先知道其预期通信的外部节点地址的情况下请求入站流量。
REC-49 Internet gateways with IPv6 simple security capabilities MUST provide an easily selected configuration option that permits a "transparent mode" of operation that forwards all unsolicited flows regardless of forwarding direction, i.e., not to use the IPv6 simple security capabilities of the gateway. The transparent mode of operation MAY be the default configuration.
具有IPv6简单安全功能的REC-49 Internet网关必须提供一个易于选择的配置选项，该配置选项允许“透明模式”的操作，该操作转发所有未经请求的流，而不管转发方向如何，即不使用网关的IPv6简单安全功能。透明操作模式可能是默认配置。
REC-50 By DEFAULT, subscriber-managed residential gateways MUST NOT offer management application services to the exterior network.
REC-50默认情况下，用户管理的住宅网关不得向外部网络提供管理应用程序服务。
Comments and criticisms during the development of this document were received from the following IETF participants:
本文件编制过程中收到以下IETF参与者的评论和批评：
+-------------------+----------------------------+
| Jari Arkko | Ran Atkinson |
| Fred Baker | Norbert Bollow |
| Cameron Byrne | Brian Carpenter |
| Remi Despres | Arnaud Ebalard |
| Fabrice Fontaine | Jun-ichiro "itojun" Hagino |
| Thomas Herbst | Christian Huitema |
| Joel Jaeggli | Cullen Jennings |
| Suresh Krishnan | Erik Kline |
| Julien Laganier | Kurt Erik Lindqvist |
| Mohamed Boucadair | Keith Moore |
| Robert Moskowitz | Teemu Savolainen |
| Hemant Singh | Yaron Sheffer |
| Mark Townsley | Iljitsch van Beijnum |
| Magnus Westerlund | Dan Wing |
+-------------------+----------------------------+
+-------------------+----------------------------+
| Jari Arkko | Ran Atkinson |
| Fred Baker | Norbert Bollow |
| Cameron Byrne | Brian Carpenter |
| Remi Despres | Arnaud Ebalard |
| Fabrice Fontaine | Jun-ichiro "itojun" Hagino |
| Thomas Herbst | Christian Huitema |
| Joel Jaeggli | Cullen Jennings |
| Suresh Krishnan | Erik Kline |
| Julien Laganier | Kurt Erik Lindqvist |
| Mohamed Boucadair | Keith Moore |
| Robert Moskowitz | Teemu Savolainen |
| Hemant Singh | Yaron Sheffer |
| Mark Townsley | Iljitsch van Beijnum |
| Magnus Westerlund | Dan Wing |
+-------------------+----------------------------+
The editor thanks them all for their contributions.
编辑感谢他们的贡献。
It must be noted that a substantial portion of the text describing the detailed requirements for TCP and UDP filtering is derived or transposed from [RFC4787] and [RFC5382]. The editors of those documents, Francois Audet and Saikat Guha, also deserve substantial credit for the form of the present document.
必须注意的是，描述TCP和UDP过滤详细要求的大部分文本源自或转置自[RFC4787]和[RFC5382]。这些文件的编辑弗朗索瓦·奥德特和赛卡特·古哈也因本文件的形式而值得赞扬。
The IPv6 stateful filtering behavior described in this document is intended to be similar in function to the filtering behavior of commonly used IPv4/NAT gateways, which have been widely sold as a security tool for residential and small-office/home-office networks. As noted in the Security Considerations section of [RFC2993], the true impact of these tools may be a reduction in security. It may be generally assumed that the impacts discussed in that document related to filtering (and not translation) are to be expected with the simple IPv6 security mechanisms described here.
本文档中描述的IPv6有状态过滤行为在功能上与常用IPv4/NAT网关的过滤行为类似，后者已被广泛用作住宅和小型办公室/家庭办公室网络的安全工具。如[RFC2993]的安全注意事项部分所述，这些工具的真正影响可能是降低安全性。通常可以假设，该文档中讨论的与过滤（而非翻译）相关的影响将在这里描述的简单IPv6安全机制中得到预期。
In particular, it is worth noting that stateful filters create the illusion of a security barrier, but without the managed intent of a firewall. Appropriate security mechanisms implemented in the end nodes, in conjunction with the [RFC4864] local network protection methods, function without reliance on network layer hacks and transport filters that may change over time. Also, defined security barriers assume that threats originate in the exterior, which may lead to practices that result in applications being fully exposed to interior attack and which therefore make breaches much easier.
特别值得注意的是，有状态过滤器产生了安全屏障的假象，但没有防火墙的管理意图。在终端节点中实施的适当安全机制，结合[RFC4864]本地网络保护方法，在不依赖可能随时间变化的网络层黑客和传输过滤器的情况下发挥作用。此外，定义的安全屏障假定威胁源自外部，这可能导致应用程序完全暴露于内部攻击的做法，从而使漏洞更容易被破解。
The security functions described in this document may be considered redundant in the event that all IPv6 hosts using a particular gateway have their own IPv6 host firewall capabilities enabled. At the time of this writing, the vast majority of commercially available operating systems with support for IPv6 include IPv6 host firewall capability.
如果使用特定网关的所有IPv6主机都启用了自己的IPv6主机防火墙功能，则本文档中描述的安全功能可能被认为是冗余的。在撰写本文时，绝大多数支持IPv6的商用操作系统都包括IPv6主机防火墙功能。
Also worth noting explicitly, a practical side-effect of the recommendations in Section 3.2.4, to allow inbound IPsec and IKE flows from exterior to interior, is to facilitate more transparent communication by the use of an unauthenticated mode of IPsec, as described in "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec" [RFC5386], and this may be a departure from expectations of transparency set by traditional IPv4/NAT residential gateways.
同样值得明确指出的是，第3.2.4节中的建议（允许入站IPsec和IKE从外部流向内部）的一个实际副作用是通过使用未经验证的IPsec模式来促进更透明的通信，如“比没有更好的安全性：未经验证的IPsec模式”[RFC5386]中所述，这可能与传统IPv4/NAT住宅网关对透明度的期望有所不同。
Finally, residential gateways that implement simple security functions are a bastion between the interior and the exterior, and therefore are a target of denial-of-service attacks against the
最后，实现简单安全功能的住宅网关是内部和外部之间的堡垒，因此是针对网络的拒绝服务攻击的目标
interior network itself by processes designed to consume the resources of the gateway, e.g., a ping or SYN flood. Gateways should employ the same sorts of protection techniques as application servers on the Internet.
内部网络本身由设计用于消耗网关资源的进程（例如ping或SYN洪水）构成。网关应采用与Internet上的应用程序服务器相同的保护技术。
The IETF makes no statement, expressed or implied, as to whether using the capabilities described in this document ultimately improves security for any individual users or for the Internet community as a whole.
IETF未就使用本文件中描述的功能是否最终提高了任何个人用户或整个互联网社区的安全性做出任何明示或暗示的声明。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，B.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，和G.Fairhurst，“轻量级用户数据报协议（UDP Lite）”，RFC 38282004年7月。
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[RFC3879]Huitema，C.和B.Carpenter，“不推荐现场本地地址”，RFC 3879，2004年9月。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[RFC4007]Deering，S.，Haberman，B.，Jinmei，T.，Nordmark，E.，和B.Zill，“IPv6作用域地址体系结构”，RFC 4007，2005年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]Davies，E.和J.Mohacsi，“防火墙中过滤ICMPv6消息的建议”，RFC 48902007年5月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[RFC5095]Abley，J.，Savola，P.，和G.Neville Neil，“IPv6中0型路由头的弃用”，RFC 5095，2007年12月。
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008.
[RFC5156]Blanchet，M.，“特殊用途IPv6地址”，RFC 5156，2008年4月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[NAT-PMP]柴郡，S.，克罗奇马尔，M.，和K.塞卡尔，“NAT港口映射协议（NAT-PMP）”，正在进行的工作，2008年4月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
[RFC1337]Braden，B.，“TCP中的等待时间暗杀危险”，RFC 1337，1992年5月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[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月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294]Loughney，J.，“IPv6节点要求”，RFC 42942006年4月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communication (MIDCOM) Protocol Semantics", RFC 5189, March 2008.
[RFC5189]Stieemerling，M.，Quittek，J.，和T.Taylor，“中间盒通信（MIDCOM）协议语义”，RFC 5189，2008年3月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]Guha，S.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月。
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
[RFC5386]Williams，N.和M.Richardson，“比没有更好的安全性：未经验证的IPsec模式”，RFC 5386，2008年11月。
[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月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 55332009年6月。
[UPnP-IGD] UPnP Forum, "Universal Plug and Play Internet Gateway Device Standardized Device Control Protocol", September 2010, <http://upnp.org/specs/gw/igd2/>.
[UPnP IGD]UPnP论坛，“通用即插即用互联网网关设备标准化设备控制协议”，2010年9月<http://upnp.org/specs/gw/igd2/>.
[WOODYATT-ALD] Woodyatt, J., "Application Listener Discovery (ALD) for IPv6", Work in Progress, July 2008.
[WOODYATT-ALD]WOODYATT，J.，“IPv6应用程序侦听器发现（ALD）”，正在进行的工作，2008年7月。
Author's Address
作者地址
James Woodyatt (editor) Apple Inc. 1 Infinite Loop Cupertino, CA 95014 US
James Woodyatt（编辑）苹果公司1无限循环库比蒂诺，加利福尼亚州95014美国
EMail: jhw@apple.com
EMail: jhw@apple.com