Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7126 UTN-FRH / SI6 Networks
BCP: 186 R. Atkinson
Category: Best Current Practice Consultant
ISSN: 2070-1721 C. Pignataro
Cisco
February 2014
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7126 UTN-FRH / SI6 Networks
BCP: 186 R. Atkinson
Category: Best Current Practice Consultant
ISSN: 2070-1721 C. Pignataro
Cisco
February 2014
Recommendations on Filtering of IPv4 Packets Containing IPv4 Options
关于过滤包含IPv4选项的IPv4数据包的建议
Abstract
摘要
This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain.
本文档提供了有关根据IPv4数据包包含的IPv4选项筛选IPv4数据包的建议。此外，本文还讨论了基于包含的IP选项丢弃数据包的操作和互操作性影响。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。互联网工程指导小组（IESG）已批准将其出版。有关BCP的更多信息，请参见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/rfc7126.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7126.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Conventions Used in This Document . . . . 3
1.2. Operational Focus . . . . . . . . . . . . . . . . . . . . 4
2. IP Options . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Security Implications of IP Options . . . . . . . . . 5
3.1. Processing Requirements . . . . . . . . . . . . . . . . . 5
4. Advice on the Handling of Packets with Specific IP Options . 7
4.1. End of Option List (Type = 0) . . . . . . . . . . . . . . 7
4.2. No Operation (Type = 1) . . . . . . . . . . . . . . . . . 7
4.3. Loose Source and Record Route (LSRR) (Type = 131) . . . . 8
4.4. Strict Source and Record Route (SSRR) (Type = 137) . . . 10
4.5. Record Route (Type = 7) . . . . . . . . . . . . . . . . . 11
4.6. Stream Identifier (Type = 136) (obsolete) . . . . . . . . 12
4.7. Internet Timestamp (Type = 68) . . . . . . . . . . . . . 13
4.8. Router Alert (Type = 148) . . . . . . . . . . . . . . . . 14
4.9. Probe MTU (Type = 11) (obsolete) . . . . . . . . . . . . 15
4.10. Reply MTU (Type = 12) (obsolete) . . . . . . . . . . . . 16
4.11. Traceroute (Type = 82) . . . . . . . . . . . . . . . . . 16
4.12. DoD Basic Security Option (Type = 130) . . . . . . . . . 17
4.13. DoD Extended Security Option (Type = 133) . . . . . . . . 20
4.14. Commercial IP Security Option (CIPSO) (Type = 134) . . . 22
4.15. VISA (Type = 142) . . . . . . . . . . . . . . . . . . . . 23
4.16. Extended Internet Protocol (Type = 145) . . . . . . . . . 24
4.17. Address Extension (Type = 147) . . . . . . . . . . . . . 25
4.18. Sender Directed Multi-Destination Delivery (Type = 149) . 25
4.19. Dynamic Packet State (Type = 151) . . . . . . . . . . . . 26
4.20. Upstream Multicast Pkt. (Type = 152) . . . . . . . . . . 26
4.21. Quick-Start (Type = 25) . . . . . . . . . . . . . . . . . 27
4.22. RFC3692-Style Experiment (Types = 30, 94, 158, and 222) . 28
4.23. Other IP Options . . . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Normative References . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Conventions Used in This Document . . . . 3
1.2. Operational Focus . . . . . . . . . . . . . . . . . . . . 4
2. IP Options . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Security Implications of IP Options . . . . . . . . . 5
3.1. Processing Requirements . . . . . . . . . . . . . . . . . 5
4. Advice on the Handling of Packets with Specific IP Options . 7
4.1. End of Option List (Type = 0) . . . . . . . . . . . . . . 7
4.2. No Operation (Type = 1) . . . . . . . . . . . . . . . . . 7
4.3. Loose Source and Record Route (LSRR) (Type = 131) . . . . 8
4.4. Strict Source and Record Route (SSRR) (Type = 137) . . . 10
4.5. Record Route (Type = 7) . . . . . . . . . . . . . . . . . 11
4.6. Stream Identifier (Type = 136) (obsolete) . . . . . . . . 12
4.7. Internet Timestamp (Type = 68) . . . . . . . . . . . . . 13
4.8. Router Alert (Type = 148) . . . . . . . . . . . . . . . . 14
4.9. Probe MTU (Type = 11) (obsolete) . . . . . . . . . . . . 15
4.10. Reply MTU (Type = 12) (obsolete) . . . . . . . . . . . . 16
4.11. Traceroute (Type = 82) . . . . . . . . . . . . . . . . . 16
4.12. DoD Basic Security Option (Type = 130) . . . . . . . . . 17
4.13. DoD Extended Security Option (Type = 133) . . . . . . . . 20
4.14. Commercial IP Security Option (CIPSO) (Type = 134) . . . 22
4.15. VISA (Type = 142) . . . . . . . . . . . . . . . . . . . . 23
4.16. Extended Internet Protocol (Type = 145) . . . . . . . . . 24
4.17. Address Extension (Type = 147) . . . . . . . . . . . . . 25
4.18. Sender Directed Multi-Destination Delivery (Type = 149) . 25
4.19. Dynamic Packet State (Type = 151) . . . . . . . . . . . . 26
4.20. Upstream Multicast Pkt. (Type = 152) . . . . . . . . . . 26
4.21. Quick-Start (Type = 25) . . . . . . . . . . . . . . . . . 27
4.22. RFC3692-Style Experiment (Types = 30, 94, 158, and 222) . 28
4.23. Other IP Options . . . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Normative References . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . 32
This document discusses the filtering of IPv4 packets based on the IPv4 options they contain. Since various protocols may use IPv4 options to some extent, dropping packets based on the options they contain may have implications on the proper functioning of such protocols. Therefore, this document attempts to discuss the operational and interoperability implications of such dropping. Additionally, it outlines what a network operator might do in typical enterprise or Service Provider environments. This document also draws and is partly derived from [RFC6274], which also received review from the operational community.
本文档讨论根据IPv4数据包包含的IPv4选项筛选IPv4数据包。由于各种协议可能在某种程度上使用IPv4选项，因此基于其包含的选项丢弃数据包可能会影响此类协议的正常运行。因此，本文档试图讨论此类删除的操作和互操作性影响。此外，它还概述了网络运营商在典型的企业或服务提供商环境中可能做的事情。本文件还引用了[RFC6274]，部分来源于[RFC6274]，该文件也接受了作战团体的审查。
We note that data seems to indicate that there is a current widespread practice of blocking IPv4 optioned packets. There are various plausible approaches to minimize the potential negative effects of IPv4 optioned packets while allowing some option semantics. One approach is to allow for specific options that are expected or needed, and have a default deny. A different approach is to deny unneeded options and have a default allow. Yet a third possible approach is to allow for end-to-end semantics by ignoring options and treating packets as un-optioned while in transit. Experiments and currently available data tend to support the first or third approaches as more realistic. Some results regarding the current state of affairs with respect to dropping packets containing IP options can be found in [MEDINA] and [FONSECA]. Additionally, [BREMIER-BARR] points out that the deployed Internet already has many routers that do not process IP options.
我们注意到，数据似乎表明，目前存在阻止IPv4可选数据包的广泛做法。有各种看似合理的方法来最小化IPv4可选数据包的潜在负面影响，同时允许一些选项语义。一种方法是允许预期或需要的特定选项，并具有默认拒绝。另一种方法是拒绝不需要的选项，并使用默认的“允许”。然而，第三种可能的方法是通过忽略选项并在传输过程中将数据包视为未选择的，从而允许端到端语义。实验和目前可用的数据倾向于支持第一种或第三种更为现实的方法。在[MEDINA]和[FONSECA]中可以找到关于丢弃包含IP选项的数据包的当前状态的一些结果。此外，[BREMIER-BARR]指出，部署的Internet已经有许多不处理IP选项的路由器。
We also note that while this document provides advice on dropping packets on a "per IP option type", not all devices (routers, security gateways, and firewalls) may provide this capability with such granularity. Additionally, even in cases in which such functionality is provided, an operator might want to specify a dropping policy with a coarser granularity (rather than on a "per IP option type" granularity), as indicated above.
我们还注意到，虽然本文档提供了在“每IP选项类型”上丢弃数据包的建议，但并非所有设备（路由器、安全网关和防火墙）都可以提供这种粒度的功能。此外，即使在提供此类功能的情况下，运营商也可能希望以更粗的粒度（而不是“每IP选项类型”粒度）指定丢弃策略，如上所述。
Finally, in scenarios in which processing of IP options by intermediate systems is not required, a widespread approach is to simply ignore IP options and process the corresponding packets as if they do not contain any IP options.
最后，在不需要中间系统处理IP选项的场景中，一种广泛的方法是忽略IP选项，并处理相应的数据包，就像它们不包含任何IP选项一样。
The terms "fast path", "slow path", and associated relative terms ("faster path" and "slower path") are loosely defined as in Section 2 of [RFC6398].
术语“快速路径”、“慢速路径”和相关术语（“快速路径”和“慢速路径”）的定义在[RFC6398]第2节中较为宽松。
Because of the security-oriented nature of this document, we are deliberately including some historical citations. The goal is to explicitly retain and show history, as well as remove ambiguity and confusion.
由于本文件的安全性，我们特意加入了一些历史引文。目标是明确地保留和展示历史，以及消除歧义和混乱。
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]中所述进行解释。
All of the recommendations in this document have been made in an effort to optimize for operational community consensus, as best the authors have been able to determine that. This has included not only accepting feedback from public lists, but also accepting off-list feedback from people at various network operators (e.g. Internet Service Providers, content providers, educational institutions, commercial firms).
本文件中的所有建议都是为了优化运营社区共识而提出的，正如作者所能确定的那样。这不仅包括接受公众名单的反馈，还包括接受不同网络运营商（如互联网服务提供商、内容提供商、教育机构、商业公司）人员的名单外反馈。
IP options allow for the extension of the Internet Protocol. As specified in [RFC0791], there are two cases for the format of an option:
IP选项允许扩展Internet协议。如[RFC0791]所述，选项的格式有两种情况：
o Case 1: A single byte of option-type.
o 情况1：选项类型的单个字节。
o Case 2: An option-type byte, an option-length byte, and the actual option-data bytes.
o 案例2：选项类型字节、选项长度字节和实际选项数据字节。
IP options of Case 1 have the following syntax:
案例1的IP选项具有以下语法：
+-+-+-+-+-+-+-+-+- - - - - - - - -
| option-type | option-data
+-+-+-+-+-+-+-+-+- - - - - - - - -
+-+-+-+-+-+-+-+-+- - - - - - - - -
| option-type | option-data
+-+-+-+-+-+-+-+-+- - - - - - - - -
The length of IP options of Case 1 is implicitly specified by the option-type byte.
案例1的IP选项长度由选项类型byte隐式指定。
IP options of Case 2 have the following syntax:
案例2的IP选项具有以下语法：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| option-type | option-length | option-data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| option-type | option-length | option-data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
In this case, the option-length byte counts the option-type byte and the option-length byte, as well as the actual option-data bytes.
在这种情况下，选项长度字节统计选项类型字节和选项长度字节，以及实际选项数据字节。
All current and future options, except "End of Option List" (Type = 0) and "No Operation" (Type = 1), are of Class 2.
除“选项列表结束”（类型=0）和“无操作”（类型=1）外，所有当前和未来选项均为2类。
The option-type has three fields:
选项类型有三个字段：
o 1 bit: copied flag.
o 1位：复制的标志。
o 2 bits: option class.
o 2位：选项类。
o 5 bits: option number.
o 5位：选项编号。
The copied flag indicates whether this option should be copied to all fragments in the event the packet carrying it needs to be fragmented:
“复制”标志指示在承载该选项的数据包需要分段时，是否应将该选项复制到所有片段：
o 0 = not copied.
o 0=未复制。
o 1 = copied.
o 1=已复制。
The values for the option class are:
选项类的值为：
o 0 = control.
o 0=控制。
o 1 = reserved for future use.
o 1=保留供将来使用。
o 2 = debugging and measurement.
o 2=调试和测量。
o 3 = reserved for future use.
o 3=保留供将来使用。
This format allows for the creation of new options for the extension of the Internet Protocol (IP).
此格式允许创建用于扩展Internet协议（IP）的新选项。
Finally, the option number identifies the syntax of the rest of the option.
最后，选项编号标识选项其余部分的语法。
The "IP OPTION NUMBERS" registry [IANA-IP] contains the list of the currently assigned IP option numbers.
“IP选项编号”注册表[IANA-IP]包含当前分配的IP选项编号列表。
Historically, most IP routers used a general-purpose CPU to process IP packets and forward them towards their destinations. This same CPU usually also processed network management traffic (e.g., SNMP), configuration commands (e.g., command line interface), and various routing protocols (e.g., RIP, OSPF, BGP, IS-IS) or other control protocols (e.g., RSVP, ICMP). In such architectures, it has been common for the general-purpose CPU also to perform any packet
历史上，大多数IP路由器使用通用CPU处理IP数据包并将其转发到目的地。该CPU通常还处理网络管理通信（例如SNMP）、配置命令（例如命令行接口）和各种路由协议（例如RIP、OSPF、BGP、IS-IS）或其他控制协议（例如RSVP、ICMP）。在这样的体系结构中，通用CPU也可以执行任何数据包
filtering that has been enabled on the router (or router interface). An IP router built using this architecture often has a significant Distributed Denial-of-Service (DDoS) attack risk if the router control plane (e.g., CPU) is overwhelmed by a large number of IPv4 packets that contain IPv4 options.
已在路由器（或路由器接口）上启用的筛选。如果路由器控制平面（例如CPU）被包含IPv4选项的大量IPv4数据包淹没，则使用此体系结构构建的IP路由器通常具有显著的分布式拒绝服务（DDoS）攻击风险。
From about 1995 onwards, a growing number of IP routers have incorporated silicon specialized for IP packet processing (i.e., Field-Programmable Gate Array (FPGA), Application-Specific Integrated Circuit (ASIC)), thereby separating the function of IP packet forwarding from the other functions of the router. Such router architectures tend to be more resilient to DDoS attacks that might be seen in the global public Internet. Depending upon various implementation and configuration details, routers with a silicon packet-forwarding engine can handle high volumes of IP packets containing IP options without any adverse impact on packet-forwarding rates or on the router's control plane (e.g., general-purpose CPU). Some implementations have a configuration knob simply to forward all IP packets containing IP options at wire-speed in silicon, as if the IP packet did not contain any IP options ("ignore options & forward"). Other implementations support wire-speed silicon-based packet filtering, thereby enabling packets containing certain IP options to be selectively dropped ("drop"), packets containing certain other IP options to have those IP options ignored ("ignore options & forward"), and other packets containing different IP options to have those options processed, either on a general-purpose CPU or using custom logic (e.g., FPGA, ASIC), while the packet is being forwarded ("process option & forward").
大约从1995年起，越来越多的IP路由器已结合专门用于IP分组处理的硅（即现场可编程门阵列（FPGA）、专用集成电路（ASIC）），从而将IP分组转发功能与路由器的其他功能分离。这种路由器架构往往更能抵御全球公共互联网中可能出现的DDoS攻击。根据各种实现和配置细节，具有硅包转发引擎的路由器可以处理包含IP选项的大量IP包，而不会对包转发速率或路由器的控制平面（例如，通用CPU）产生任何不利影响。一些实现有一个配置旋钮，用于在硅中以线速转发包含IP选项的所有IP数据包，就好像该IP数据包不包含任何IP选项一样（“忽略选项&转发”）。其他实现支持线速硅基数据包过滤，从而使包含某些IP选项的数据包能够被选择性丢弃（“丢弃”），包含某些其他IP选项的数据包能够被忽略这些IP选项（“忽略选项&转发”），以及包含不同IP选项的其他数据包，以便在转发数据包时在通用CPU上或使用自定义逻辑（例如FPGA、ASIC）处理这些选项（“处理选项&转发”）。
Broadly speaking, any IP packet that requires processing by an IP router's general-purpose CPU can be a DDoS risk to that router's general-purpose CPU (and thus to the router itself). However, at present, the particular architectural and engineering details of the specific IP router being considered are important to understand when evaluating the operational security risks associated with a particular IP packet type or IP option type.
广义地说，任何需要由IP路由器的通用CPU处理的IP数据包都可能对该路由器的通用CPU（以及路由器本身）构成DDoS风险。然而，目前，在评估与特定IP包类型或IP选项类型相关的操作安全风险时，需要了解所考虑的特定IP路由器的特定架构和工程细节。
Operators are urged to consider the capabilities of potential IP routers for IP option filtering and handling as they make deployment decisions in the future.
运营商敦促考虑潜在IP路由器的IP选项过滤和处理能力，因为他们在未来部署决策。
Additional considerations for protecting the control plane from packets containing IP options can be found in [RFC6192].
有关保护控制平面免受包含IP选项的数据包攻击的其他注意事项，请参见[RFC6192]。
Finally, in addition to advice to operators, this document also provides advice to router, security gateway, and firewall implementers in terms of providing the capability to filter packets
最后，除了向运营商提供建议外，本文档还向路由器、安全网关和防火墙实施者提供关于提供数据包过滤功能的建议
with different granularities: both on a "per IP option type" granularity (to maximize flexibility) as well as more coarse filters (to minimize configuration complexity).
具有不同的粒度：既基于“每IP选项类型”粒度（以最大化灵活性），也基于更粗的过滤器（以最小化配置复杂性）。
The following subsections contain a description of each of the IP options that have so far been specified, a discussion of possible interoperability implications if packets containing such options are dropped, and specific advice on whether to drop packets containing these options in a typical enterprise or Service Provider environment.
以下小节包含到目前为止已指定的每个IP选项的描述，如果丢弃包含这些选项的数据包，可能的互操作性影响的讨论，以及关于是否在典型企业或服务提供商环境中丢弃包含这些选项的数据包的具体建议。
This option is used to indicate the "end of options" in those cases in which the end of options would not coincide with the end of the Internet Protocol header.
在选项结束与Internet协议标头结束不一致的情况下，此选项用于指示“选项结束”。
Specified in RFC 791 [RFC0791].
RFC 791[RFC0791]中规定。
No specific security issues are known for this IPv4 option.
此IPv4选项不存在特定的安全问题。
Packets containing any IP options are likely to include an End of Option List. Therefore, if packets containing this option are dropped, it is very likely that legitimate traffic is blocked.
包含任何IP选项的数据包都可能包含选项列表的末尾。因此，如果包含此选项的数据包被丢弃，则很可能会阻止合法通信。
Routers, security gateways, and firewalls SHOULD NOT drop packets because they contain this option.
路由器、安全网关和防火墙不应丢弃数据包，因为它们包含此选项。
The no-operation option is basically meant to allow the sending system to align subsequent options in, for example, 32-bit boundaries.
无操作选项基本上意味着允许发送系统在例如32位边界中对齐后续选项。
Specified in RFC 791 [RFC0791].
RFC 791[RFC0791]中规定。
No specific security issues are known for this IPv4 option.
此IPv4选项不存在特定的安全问题。
Packets containing any IP options are likely to include a No Operation option. Therefore, if packets containing this option are dropped, it is very likely that legitimate traffic is blocked.
包含任何IP选项的数据包都可能包含无操作选项。因此，如果包含此选项的数据包被丢弃，则很可能会阻止合法通信。
Routers, security gateways, and firewalls SHOULD NOT drop packets because they contain this option.
路由器、安全网关和防火墙不应丢弃数据包，因为它们包含此选项。
RFC 791 states that this option should appear at most once in a given packet. Thus, if a packet contains more than one LSRR option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Additionally, packets containing a combination of LSRR and SSRR options should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
RFC 791规定该选项在给定数据包中最多出现一次。因此，如果一个数据包包含多个LSRR选项，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。此外，应丢弃包含LSRR和SSRR选项组合的数据包，并记录此事件（例如，可增加计数器以反映数据包丢弃）。
This option lets the originating system specify a number of intermediate systems a packet must pass through to get to the destination host. Additionally, the route followed by the packet is recorded in the option. The receiving host (end-system) must use the reverse of the path contained in the received LSRR option.
此选项允许发起系统指定数据包必须经过的多个中间系统才能到达目标主机。此外，数据包遵循的路由记录在选项中。接收主机（终端系统）必须使用与接收的LSRR选项中包含的路径相反的路径。
The LSSR option can be of help in debugging some network problems. Some Internet Service Provider (ISP) peering agreements require support for this option in the routers within the peer of the ISP.
LSSR选项有助于调试某些网络问题。某些Internet服务提供商（ISP）对等协议要求在ISP对等内的路由器中支持此选项。
Specified in RFC 791 [RFC0791].
RFC 791[RFC0791]中规定。
The LSRR option has well-known security implications [RFC6274]. Among other things, the option can be used to:
LSRR选项具有众所周知的安全含义[RFC6274]。除其他事项外，该选项可用于：
o Bypass firewall rules.
o 绕过防火墙规则。
o Reach otherwise unreachable internet systems.
o 到达其他无法访问的internet系统。
o Establish TCP connections in a stealthy way.
o 以隐蔽的方式建立TCP连接。
o Learn about the topology of a network.
o 了解网络的拓扑结构。
o Perform bandwidth-exhaustion attacks.
o 执行带宽耗尽攻击。
Of these attack vectors, the one that has probably received least attention is the use of the LSRR option to perform bandwidth exhaustion attacks. The LSRR option can be used as an amplification method for performing bandwidth-exhaustion attacks, as an attacker could make a packet bounce multiple times between a number of systems by carefully crafting an LSRR option.
在这些攻击向量中，最不受关注的是使用LSRR选项执行带宽耗尽攻击。LSRR选项可用作执行带宽耗尽攻击的放大方法，因为攻击者可以通过精心设计LSRR选项使数据包在多个系统之间多次反弹。
This is the IPv4 version of the IPv6 amplification attack that was widely publicized in 2007 [Biondi2007]. The only difference is that the maximum length of the IPv4 header (and hence the LSRR option) limits the amplification factor when compared to the IPv6 counterpart.
这是2007年广泛宣传的IPv6放大攻击的IPv4版本[Biondi2007]。唯一的区别是，与IPv6头相比，IPv4头的最大长度（以及LSRR选项）限制了放大系数。
Additionally, some implementations have been found to fail to include proper sanity checks on the LSRR option, thus leading to security issues. These specific issues are believed to be solved in all modern implementations.
此外，已发现一些实现未能在LSRR选项上包含适当的健全性检查，从而导致安全问题。这些具体问题相信在所有现代实现中都能得到解决。
[Microsoft1999] is a security advisory about a vulnerability arising from improper validation of the Pointer field of the LSRR option.
[Microsoft1999]是一个关于因错误验证LSRR选项的指针字段而产生的漏洞的安全建议。
Finally, we note that some systems were known for providing a system-wide toggle to enable support for this option for those scenarios in which this option is required. However, improper implementation of such a system-wide toggle caused those systems to support the LSRR option even when explicitly configured not to do so.
最后，我们注意到，一些系统提供了系统范围的切换，以便在需要此选项的场景中支持此选项。但是，这种系统范围切换的不当实现导致这些系统支持LSRR选项，即使明确配置为不支持LSRR选项。
[OpenBSD1998] is a security advisory about an improper implementation of such a system-wide toggle in 4.4BSD kernels. This issue was resolved in later versions of the corresponding operating system.
[OpenBSD1998]是关于在4.4BSD内核中不当实现此类系统范围切换的安全建议。此问题已在相应操作系统的更高版本中得到解决。
Network troubleshooting techniques that may employ the LSRR option (such as ping or traceroute with the appropriate arguments) would break when using the LSRR option. (Ping and traceroute without IPv4 options are not impacted.) Nevertheless, it should be noted that it is virtually impossible to use the LSRR option for troubleshooting, due to widespread dropping of packets that contain the option.
当使用LSRR选项时，可能使用LSRR选项的网络故障排除技术（如ping或带有适当参数的traceroute）将中断。（不带IPv4选项的Ping和traceroute不受影响。）但是，应该注意，由于包含该选项的数据包的广泛丢弃，实际上不可能使用LSRR选项进行故障排除。
Routers, security gateways, and firewalls SHOULD implement an option-specific configuration knob to select whether packets with this option are dropped, packets with this IP option are forwarded as if they did not contain this IP option, or packets with this option are processed and forwarded as per [RFC0791]. The default setting for this knob SHOULD be "drop", and the default setting MUST be documented.
路由器、安全网关和防火墙应实施特定于选项的配置旋钮，以选择是否丢弃带有此选项的数据包，转发带有此IP选项的数据包，就像它们不包含此IP选项一样，或者按照[RFC0791]处理和转发带有此选项的数据包。此旋钮的默认设置应为“下降”，并且必须记录默认设置。
Please note that treating packets with LSRR as if they did not contain this option can result in such packets being sent to a different device than the initially intended destination. With appropriate ingress filtering, this should not open an attack vector into the infrastructure. Nonetheless, it could result in traffic that would never reach the initially intended destination. Dropping these packets prevents unnecessary network traffic and does not make end-to-end communication any worse.
请注意，如果将带有LSRR的数据包视为不包含此选项，则会导致将此类数据包发送到不同于最初预期目的地的设备。通过适当的入口过滤，这不应该向基础设施中打开攻击向量。尽管如此，它可能会导致流量永远无法到达最初预期的目的地。丢弃这些数据包可以防止不必要的网络流量，并且不会使端到端通信变得更糟。
This option allows the originating system to specify a number of intermediate systems a packet must pass through to get to the destination host. Additionally, the route followed by the packet is recorded in the option, and the destination host (end-system) must use the reverse of the path contained in the received SSRR option.
此选项允许发起系统指定数据包必须经过的多个中间系统才能到达目标主机。此外，数据包遵循的路由记录在选项中，目标主机（终端系统）必须使用与接收到的SSRR选项中包含的路径相反的路径。
This option is similar to the Loose Source and Record Route (LSRR) option, with the only difference that in the case of SSRR, the route specified in the option is the exact route the packet must take (i.e., no other intervening routers are allowed to be in the route).
该选项类似于松散源和记录路由（LSRR）选项，唯一的区别是，在SSRR的情况下，该选项中指定的路由是数据包必须采用的确切路由（即，不允许其他介入路由器位于路由中）。
The SSRR option can be of help in debugging some network problems. Some ISP peering agreements require support for this option in the routers within the peer of the ISP.
SSRR选项可以帮助调试某些网络问题。某些ISP对等协议要求在ISP对等内的路由器中支持此选项。
Specified in RFC 791 [RFC0791].
RFC 791[RFC0791]中规定。
The SSRR option has the same security implications as the LSRR option. Please refer to Section 4.3 for a discussion of such security implications.
SSRR选项与LSRR选项具有相同的安全含义。有关此类安全影响的讨论，请参阅第4.3节。
Network troubleshooting techniques that may employ the SSRR option (such as ping or traceroute with the appropriate arguments) would break when using the SSRR option. (Ping and traceroute without IPv4 options are not impacted.) Nevertheless, it should be noted that it is virtually impossible to use the SSRR option for trouble-shooting, due to widespread dropping of packets that contain such option.
使用SSRR选项时，可能使用SSRR选项的网络故障排除技术（如ping或带有适当参数的traceroute）将中断。（没有IPv4选项的Ping和traceroute不受影响。）然而，应该注意的是，由于包含该选项的数据包的广泛丢弃，几乎不可能使用SSRR选项进行故障排除。
Routers, security gateways, and firewalls SHOULD implement an option-specific configuration knob to select whether packets with this option are dropped, packets with this IP option are forwarded as if they did not contain this IP option, or packets with this option are processed and forwarded as per [RFC0791]. The default setting for this knob SHOULD be "drop", and the default setting MUST be documented.
路由器、安全网关和防火墙应实施特定于选项的配置旋钮，以选择是否丢弃带有此选项的数据包，转发带有此IP选项的数据包，就像它们不包含此IP选项一样，或者按照[RFC0791]处理和转发带有此选项的数据包。此旋钮的默认设置应为“下降”，并且必须记录默认设置。
Please note that treating packets with SSRR as if they did not contain this option can result in such packets being sent to a different device that the initially intended destination. With appropriate ingress filtering this should not open an attack vector into the infrastructure. Nonetheless, it could result in traffic that would never reach the initially intended destination. Dropping these packets prevents unnecessary network traffic, and does not make end-to-end communication any worse.
请注意，使用SSRR处理数据包时，如果它们不包含此选项，则可能会导致将此类数据包发送到最初指定目的地的不同设备。通过适当的入口过滤，这不应该向基础设施中打开攻击向量。尽管如此，它可能会导致流量永远无法到达最初预期的目的地。丢弃这些数据包可以防止不必要的网络流量，并且不会使端到端通信变得更糟。
This option provides a means to record the route that a given packet follows.
此选项提供了记录给定数据包遵循的路由的方法。
Specified in RFC 791 [RFC0791].
RFC 791[RFC0791]中规定。
This option can be exploited to map the topology of a network. However, the limited space in the IP header limits the usefulness of this option for that purpose.
可以利用此选项映射网络拓扑。但是，IP报头中的有限空间限制了此选项在该用途中的用途。
Network troubleshooting techniques that may employ the RR option (such as ping with the RR option) would break when using the RR option. (Ping without IPv4 options is not impacted.) Nevertheless, it should be noted that it is virtually impossible to use such techniques due to widespread dropping of packets that contain RR options.
使用RR选项时，可能会中断使用RR选项的网络故障排除技术（例如使用RR选项ping）。（没有IPv4选项的Ping不会受到影响。）然而，应该注意的是，由于包含RR选项的数据包的广泛丢弃，使用此类技术几乎是不可能的。
Routers, security gateways, and firewalls SHOULD implement an option-specific configuration knob to select whether packets with this option are dropped, packets with this IP option are forwarded as if they did not contain this IP option, or packets with this option are processed and forwarded as per [RFC0791]. The default setting for this knob SHOULD be "drop", and the default setting MUST be documented.
路由器、安全网关和防火墙应实施特定于选项的配置旋钮，以选择是否丢弃带有此选项的数据包，转发带有此IP选项的数据包，就像它们不包含此IP选项一样，或者按照[RFC0791]处理和转发带有此选项的数据包。此旋钮的默认设置应为“下降”，并且必须记录默认设置。
The Stream Identifier option originally provided a means for the 16-bit SATNET stream Identifier to be carried through networks that did not support the stream concept.
流标识符选项最初提供了通过不支持流概念的网络传输16位SATNET流标识符的方法。
However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. Therefore, it must be ignored by the processing systems. See also [IANA-IP] and [RFC6814].
然而，如RFC 1122[RFC1122]第3.2.1.8节和RFC 1812[RFC1812]第4.2.2.1节所述，该选项已过时。因此，处理系统必须忽略它。另见[IANA-IP]和[RFC6814]。
RFC 791 states that this option appears at most once in a given datagram. Therefore, if a packet contains more than one instance of this option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
RFC 791指出，该选项在给定数据报中最多出现一次。因此，如果一个数据包包含此选项的多个实例，则应丢弃该数据包，并记录此事件（例如，可增加计数器以反映数据包丢弃）。
This option is obsolete. There is no current use for this option.
此选项已过时。此选项当前没有任何用途。
Specified in RFC 791 [RFC0791], and deprecated in RFC 1122 [RFC1122] and RFC 1812 [RFC1812]. This option has been formally obsoleted by [RFC6814].
在RFC 791[RFC0791]中指定，并在RFC 1122[RFC1122]和RFC 1812[RFC1812]中弃用。此选项已被[RFC6814]正式淘汰。
No specific security issues are known for this IPv4 option.
此IPv4选项不存在特定的安全问题。
None.
没有一个
Routers, security gateways, and firewalls SHOULD drop IP packets containing a Stream Identifier option.
路由器、安全网关和防火墙应丢弃包含流标识符选项的IP数据包。
This option provides a means for recording the time at which each system (or a specified set of systems) processed this datagram, and it may optionally record the addresses of the systems providing the timestamps.
该选项提供用于记录每个系统（或指定的一组系统）处理该数据报的时间的方法，并且它可以选择性地记录提供时间戳的系统的地址。
Specified by RFC 791 [RFC0791].
由RFC 791[RFC0791]指定。
The timestamp option has a number of security implications [RFC6274]. Among them are:
时间戳选项有许多安全含义[RFC6274]。其中包括:
o It allows an attacker to obtain the current time of the systems that process the packet, which the attacker may find useful in a number of scenarios.
o 它允许攻击者获取处理数据包的系统的当前时间，攻击者可能会发现这在许多情况下都很有用。
o It may be used to map the network topology in a similar way to the IP Record Route option.
o 它可用于以与IP记录路由选项类似的方式映射网络拓扑。
o It may be used to fingerprint the operating system in use by a system processing the datagram.
o 它可用于对处理数据报的系统正在使用的操作系统进行指纹识别。
o It may be used to fingerprint physical devices by analyzing the clock skew.
o 它可以通过分析时钟偏移来对物理设备进行指纹识别。
[Kohno2005] describes a technique for fingerprinting devices by measuring the clock skew. It exploits, among other things, the timestamps that can be obtained by means of the ICMP timestamp request messages [RFC0791]. However, the same fingerprinting method could be implemented with the aid of the Internet Timestamp option.
[Kohno2005]描述了一种通过测量时钟偏移来对设备进行指纹识别的技术。除其他外，它利用可通过ICMP时间戳请求消息[RFC0791]获得的时间戳。然而，同样的指纹识别方法可以借助于Internet时间戳选项来实现。
Network troubleshooting techniques that may employ the Internet Timestamp option (such as ping with the Timestamp option) would break when using the Timestamp option. (Ping without IPv4 options is not impacted.) Nevertheless, it should be noted that it is virtually impossible to use such techniques due to widespread dropping of packets that contain Internet Timestamp options.
使用时间戳选项时，可能使用Internet时间戳选项（例如使用时间戳选项ping）的网络故障排除技术将中断。（没有IPv4选项的Ping不会受到影响。）然而，应该注意的是，由于包含Internet时间戳选项的数据包的广泛丢弃，使用此类技术几乎是不可能的。
Routers, security gateways, and firewalls SHOULD drop IP packets containing an Internet Timestamp option.
路由器、安全网关和防火墙应丢弃包含Internet时间戳选项的IP数据包。
The Router Alert option has the semantic "routers should examine this packet more closely, if they participate in the functionality denoted by the Value of the option".
路由器警报选项的语义是“如果路由器参与选项值所表示的功能，则应更仔细地检查此数据包”。
The Router Alert option is defined in RFC 2113 [RFC2113] and later updates to it have been clarified by RFC 5350 [RFC5350]. It contains a 16-bit Value governed by an IANA registry (see [RFC5350]).
路由器警报选项在RFC 2113[RFC2113]中定义，RFC 5350[RFC5350]已对其更新进行了澄清。它包含一个由IANA注册表管理的16位值（请参见[RFC5350]）。
The security implications of the Router Alert option have been discussed in detail in [RFC6398]. Basically, the Router Alert option might be exploited to perform a DoS attack by exhausting CPU resources at the processing routers.
[RFC6398]中详细讨论了路由器警报选项的安全含义。基本上，通过耗尽处理路由器的CPU资源，可以利用路由器警报选项执行DoS攻击。
Applications that employ the Router Alert option (such as RSVP [RFC2205]) would break.
使用路由器警报选项的应用程序（如RSVP[RFC2205]）将中断。
This option SHOULD be allowed only in controlled environments, where the option can be used safely. [RFC6398] identifies some such environments. In unsafe environments, packets containing this option SHOULD be dropped.
只有在受控环境中才允许使用此选项，因为在受控环境中该选项可以安全使用。[RFC6398]确定了一些这样的环境。在不安全的环境中，应丢弃包含此选项的数据包。
A given router, security gateway, or firewall system has no way of knowing a priori whether this option is valid in its operational environment. Therefore, routers, security gateways, and firewalls SHOULD, by default, ignore the Router Alert option. Additionally, routers, security gateways, and firewalls SHOULD have a configuration setting that governs their reaction in the presence of packets containing the Router Alert option. This configuration setting SHOULD allow to honor and process the option, ignore the option, or drop packets containing this option.
给定的路由器、安全网关或防火墙系统无法事先知道此选项在其操作环境中是否有效。因此，默认情况下，路由器、安全网关和防火墙应忽略路由器警报选项。此外，路由器、安全网关和防火墙应具有一个配置设置，以控制它们在存在包含路由器警报选项的数据包时的反应。此配置设置应允许接受和处理选项、忽略选项或丢弃包含此选项的数据包。
This option originally provided a mechanism to discover the Path-MTU. It has been declared obsolete.
此选项最初提供了一种发现路径MTU的机制。它已被宣布过时。
This option was originally defined in RFC 1063 [RFC1063] and was obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as RFC 1191 obsoletes RFC 1063 without using IP options.
该选项最初在RFC 1063[RFC1063]中定义，并在RFC 1191[RFC1191]中被淘汰。该选项现在已过时，因为RFC1191在不使用IP选项的情况下淘汰了RFC1063。
This option is obsolete. This option could have been exploited to cause a host to set its Path MTU (PMTU) estimate to an inordinately low or an inordinately high value, thereby causing performance problems.
此选项已过时。利用此选项可能会导致主机将其路径MTU（PMTU）估计值设置为异常低或异常高的值，从而导致性能问题。
None
没有一个
This option is NOT employed with the modern "Path MTU Discovery" (PMTUD) mechanism [RFC1191], which employs special ICMP messages (Type 3, Code 4) in combination with the IP DF bit. Packetization Layer PMTUD (PLPMTUD) [RFC4821] can perform PMTUD without the need for any special packets.
此选项不适用于现代“路径MTU发现”（PMTUD）机制[RFC1191]，该机制结合IP DF位使用特殊ICMP消息（类型3，代码4）。分组化层PMTUD（PLPMTUD）[RFC4821]可以执行PMTUD，而不需要任何特殊的分组。
Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Probe MTU option.
路由器、安全网关和防火墙应丢弃包含探测MTU选项的IP数据包。
This option originally provided a mechanism to discover the Path-MTU. It is now obsolete.
此选项最初提供了一种发现路径MTU的机制。现在已经过时了。
This option was originally defined in RFC 1063 [RFC1063] and was obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as RFC 1191 obsoletes RFC 1063 without using IP options.
该选项最初在RFC 1063[RFC1063]中定义，并在RFC 1191[RFC1191]中被淘汰。该选项现在已过时，因为RFC1191在不使用IP选项的情况下淘汰了RFC1063。
This option is obsolete. This option could have been exploited to cause a host to set its PMTU estimate to an inordinately low or an inordinately high value, thereby causing performance problems.
此选项已过时。利用此选项可能会导致主机将其PMTU估计值设置为过低或过高的值，从而导致性能问题。
None
没有一个
This option is NOT employed with the modern "Path MTU Discovery" (PMTUD) mechanism [RFC1191], which employs special ICMP messages (Type 3, Code 4) in combination with the IP DF bit. PLPMTUD [RFC4821] can perform PMTUD without the need of any special packets.
此选项不适用于现代“路径MTU发现”（PMTUD）机制[RFC1191]，该机制结合IP DF位使用特殊ICMP消息（类型3，代码4）。PLPMTUD[RFC4821]可以在不需要任何特殊数据包的情况下执行PMTUD。
Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Reply MTU option.
路由器、安全网关和防火墙应丢弃包含应答MTU选项的IP数据包。
This option originally provided a mechanism to trace the path to a host.
此选项最初提供了一种跟踪主机路径的机制。
This option was originally specified by RFC 1393 [RFC1393] as "experimental", and it was never widely deployed on the public Internet. This option has been formally obsoleted by [RFC6814].
该选项最初由RFC 1393[RFC1393]指定为“实验性”，从未在公共互联网上广泛部署。此选项已被[RFC6814]正式淘汰。
This option is obsolete. Because this option required each router in the path both to provide special processing and to send an ICMP message, it could have been exploited to perform a DoS attack by exhausting CPU resources at the processing routers.
此选项已过时。由于此选项要求路径中的每个路由器提供特殊处理和发送ICMP消息，因此可能会利用此选项通过耗尽处理路由器的CPU资源来执行DoS攻击。
None
没有一个
Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Traceroute option.
路由器、安全网关和防火墙应丢弃包含跟踪路由选项的IP数据包。
This option [RFC1108] is used by Multi-Level Secure (MLS) end-systems and intermediate systems in specific environments to:
此选项[RFC1108]用于特定环境中的多级安全（MLS）终端系统和中间系统：
o transmit from source to destination in a network standard representation the common security labels required by computer security models [Landwehr81],
o 以网络标准表示形式将计算机安全模型要求的通用安全标签从源传输到目标[Landwehr81]，
o validate the datagram as appropriate for transmission from the source and delivery to the destination, and,
o 验证数据报是否适合从源传输并传送到目的地，以及，
o ensure that the route taken by the datagram is protected to the level required by all protection authorities indicated on the datagram.
o 确保数据报所采用的路由被保护到数据报上指示的所有保护机构所要求的级别。
The DoD Basic Security Option (BSO) was implemented in IRIX [IRIX2008] and is currently implemented in a number of operating systems (e.g., Security-Enhanced Linux [SELinux2008], Solaris [Solaris2008], and Cisco IOS [Cisco-IPSO]). It is also currently deployed in a number of high-security networks. These networks are typically either in physically secure locations, protected by military/governmental communications security equipment, or both.
国防部基本安全选项（BSO）在IRIX[IRIX2008]中实施，目前在许多操作系统中实施（例如，安全增强型Linux[SELinux2008]、Solaris[Solaris2008]和Cisco IOS[Cisco IPSO]）。它目前还部署在一些高安全性网络中。这些网络通常位于物理安全位置，由军事/政府通信安全设备保护，或两者兼而有之。
Such networks are typically built using commercial off-the-shelf (COTS) IP routers and Ethernet switches, but they are not normally interconnected with the global public Internet. MLS systems are much more widely deployed now than they were at the time the then-IESG decided to remove IPSO (IP Security Options) from the IETF Standards Track. Since nearly all MLS systems also support IPSO BSO and IPSO ESO, this option is believed to have more deployment now than when the IESG removed this option from the IETF Standards Track. [RFC5570] describes a similar option recently defined for IPv6 and has much more detailed explanations of how sensitivity label options are used in real-world deployments.
此类网络通常使用商用现货（COTS）IP路由器和以太网交换机构建，但它们通常不与全球公共互联网互连。MLS系统现在的部署比当时IESG决定从IETF标准轨道上删除IPSO（IP安全选项）时要广泛得多。由于几乎所有MLS系统也支持IPSO BSO和IPSO ESO，因此与IESG将该选项从IETF标准轨道上删除时相比，该选项现在的部署量更大。[RFC5570]介绍了最近为IPv6定义的一个类似选项，并更详细地解释了在实际部署中如何使用敏感标签选项。
It is specified by RFC 1108 [RFC1108], which obsoleted RFC 1038 [RFC1038] (which in turn obsoleted the Security Option defined in RFC 791 [RFC0791]).
它由RFC 1108[RFC1108]规定，该条款废除了RFC 1038[RFC1038]（该条款又废除了RFC 791[RFC0791]中定义的安全选项）。
RFC 791 [RFC0791] defined the "Security Option" (Type = 130), which used the same option type as the DoD Basic Security option discussed in this section. Later, RFC 1038 [RFC1038] revised the IP security options, and in turn was obsoleted by RFC 1108 [RFC1108]. The "Security Option" specified in RFC 791 is considered obsolete by Section 3.2.1.8 of RFC 1122 [RFC1122] and Section 4.2.2.1 of RFC 1812 [RFC1812], and therefore the discussion in this section is focused on the DoD Basic Security option specified by RFC 1108 [RFC1108].
RFC 791[RFC0791]定义了“安全选项”（类型=130），该选项使用了与本节讨论的国防部基本安全选项相同的选项类型。后来，RFC 1038[RFC1038]修改了IP安全选项，并被RFC 1108[RFC1108]淘汰。RFC 1122[RFC1122]第3.2.1.8节和RFC 1812[RFC1812]第4.2.2.1节认为RFC 791中规定的“安全选项”已过时，因此本节讨论的重点是RFC 1108[RFC1108]规定的国防部基本安全选项。
Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement [this option]".
RFC 1812第4.2.2.1节规定路由器“应实现[此选项]”。
Some private IP networks consider IP router-based per-interface selective filtering of packets based on (a) the presence of an IPSO option (including BSO and ESO) and (b) the contents of that IPSO option to be important for operational security reasons. The recent IPv6 Common Architecture Label IPv6 Security Option (CALIPSO) specification discusses this in additional detail, albeit in an IPv6 context [RFC5570].
一些私有IP网络考虑基于每个路由器的接口选择性过滤的IP路由器，基于（a）存在IPSO选项（包括BSO和ESO）和（b）该IPSO选项的内容对于操作安全原因是重要的。最近的IPv6通用体系结构标签IPv6安全选项（CALIPSO）规范对此进行了详细讨论，尽管是在IPv6上下文中[RFC5570]。
Such private IP networks commonly are built using both commercial and open-source products -- for hosts, guards, firewalls, switches, routers, etc. Some commercial IP routers support this option, as do some IP routers that are built on top of MLS operating systems (e.g., on top of Trusted Solaris [Solaris2008] or Security-Enhanced Linux [SELinux2008]).
此类专用IP网络通常使用商用和开源产品构建——用于主机、防护装置、防火墙、交换机、路由器等。一些商用IP路由器支持此选项，一些构建在MLS操作系统（例如，受信任的Solaris[Solaris2008]或安全增强的Linux）之上的IP路由器也支持此选项[SELinux2008]）。
For example, many Cisco routers that run Cisco IOS include support for selectively filtering packets that contain the IP Security Options (IPSO) with per-interface granularity. This capability has been present in many Cisco routers since the early 1990s [Cisco-IPSO-Cmds]. Some government-sector products reportedly also support the IP Security Options (IPSO), for example, CANEWARE [RFC4949].
例如，许多运行Cisco IOS的Cisco路由器都支持选择性过滤包含IP安全选项（IPSO）的数据包，这些数据包具有每个接口粒度。自20世纪90年代初以来，许多Cisco路由器都具有这种功能[Cisco IPSO Cmds]。据报道，一些政府部门产品还支持IP安全选项（IPSO），例如CANEWARE[RFC4949]。
Support for the IPSO Basic Security Option also is included in the "IPsec Configuration Policy Information Model" [RFC3585] and in the "IPsec Security Policy Database Configuration MIB" [RFC4807]. Section 4.6.1 of the IP Security Domain of Interpretation [RFC2407] includes support for labeled IPsec security associations compatible with the IP Security Options. (Note: RFC 2407 was obsoleted by [RFC4306], which was obsoleted by [RFC5996].)
对IPSO基本安全选项的支持也包含在“IPsec配置策略信息模型”[RFC3585]和“IPsec安全策略数据库配置MIB”[RFC4807]中。IP安全解释域[RFC2407]第4.6.1节包括对与IP安全选项兼容的标记IPsec安全关联的支持。（注：RFC 2407已被[RFC4306]淘汰，而[RFC5996]已淘汰。）
Presence of this option in a packet does not by itself create any specific new threat. Packets with this option ought not normally be seen on the global public Internet.
数据包中存在此选项本身不会产生任何特定的新威胁。具有此选项的数据包通常不应出现在全球公共互联网上。
If packets with this option are blocked or if the option is stripped from the packet during transmission from source to destination, then the packet itself is likely to be dropped by the receiver because it is not properly labeled. In some cases, the receiver might receive the packet but associate an incorrect sensitivity label with the received data from the packet whose BSO was stripped by an intermediate router or firewall. Associating an incorrect sensitivity label can cause the received information either to be handled as more sensitive than it really is ("upgrading") or as less sensitive than it really is ("downgrading"), either of which is problematic.
如果具有此选项的数据包被阻止，或者如果在从源到目的地的传输过程中该选项被从数据包中剥离，则数据包本身可能会被接收器丢弃，因为它没有正确标记。在某些情况下，接收器可能接收到数据包，但将不正确的敏感度标签与来自其BSO被中间路由器或防火墙剥离的数据包的接收数据相关联。关联错误的敏感度标签可能会导致接收到的信息被处理为比实际敏感度更高（“升级”）或比实际敏感度更低（“降级”），这两者都有问题。
A given IP router, security gateway, or firewall has no way to know a priori what environment it has been deployed into. Even closed IP deployments generally use exactly the same commercial routers, security gateways, and firewalls that are used in the public Internet.
给定的IP路由器、安全网关或防火墙无法事先知道它部署到了什么环境中。即使是封闭式IP部署也通常使用与公共Internet中使用的完全相同的商用路由器、安全网关和防火墙。
Since operational problems result in environments where this option is needed if either the option is dropped or IP packets containing this option are dropped, but no harm results if the option is carried in environments where it is not needed, the default configuration SHOULD NOT (a) modify or remove this IP option or (b) drop an IP packet because the IP packet contains this option.
由于操作问题会导致在丢弃该选项或丢弃包含该选项的IP数据包时需要该选项的环境，但如果在不需要该选项的环境中携带该选项，则不会造成伤害，因此默认配置不应（a）修改或删除该IP选项或（b）丢弃IP数据包，因为IP数据包包含此选项。
A given IP router, security gateway, or firewall MAY be configured to drop this option or to drop IP packets containing this option in an environment known to not use this option.
给定的IP路由器、安全网关或防火墙可配置为丢弃此选项，或在已知不使用此选项的环境中丢弃包含此选项的IP数据包。
For auditing reasons, routers, security gateways, and firewalls SHOULD be capable of logging the numbers of packets containing the BSO on a per-interface basis. Also, routers, security gateways, and firewalls SHOULD be capable of dropping packets based on the BSO presence as well as the BSO values.
出于审计原因，路由器、安全网关和防火墙应能够记录每个接口上包含BSO的数据包数。此外，路由器、安全网关和防火墙应该能够根据BSO的存在以及BSO值丢弃数据包。
This option permits additional security labeling information, beyond that present in the Basic Security Option (Section 4.12), to be supplied in an IP datagram to meet the needs of registered authorities.
该选项允许在IP数据报中提供除基本安全选项（第4.12节）之外的其他安全标签信息，以满足注册机构的需要。
The DoD Extended Security Option (ESO) is specified by RFC 1108 [RFC1108].
国防部扩展安全选项（ESO）由RFC 1108[RFC1108]规定。
Some private IP networks consider IP router-based per-interface selective filtering of packets based on (a) the presence of an IPSO option (including BSO and ESO) and (b) based on the contents of that IPSO option to be important for operational security reasons. The recent IPv6 CALIPSO option specification discusses this in additional detail, albeit in an IPv6 context [RFC5570].
一些私有IP网络考虑基于每个路由器的接口选择性过滤的IP路由器，基于（a）存在IPSO选项（包括BSO和ESO），和（b）基于该IPSO选项的内容对于操作安全原因是重要的。最近的IPv6 CALIPSO选项规范更详细地讨论了这一点，尽管是在IPv6上下文中[RFC5570]。
Such private IP networks commonly are built using both commercial and open-source products -- for hosts, guards, firewalls, switches, routers, etc. Some commercial IP routers support this option, as do some IP routers that are built on top of MLS operating systems (e.g., on top of Trusted Solaris [Solaris2008] or Security-Enhanced Linux [SELinux2008]).
此类专用IP网络通常使用商用和开源产品构建——用于主机、防护装置、防火墙、交换机、路由器等。一些商用IP路由器支持此选项，一些构建在MLS操作系统（例如，受信任的Solaris[Solaris2008]或安全增强的Linux）之上的IP路由器也支持此选项[SELinux2008]）。
For example, many Cisco routers that run Cisco IOS include support for selectively filtering packets that contain the IP Security Options (IPSO) with per-interface granularity. This capability
例如，许多运行Cisco IOS的Cisco路由器都支持选择性过滤包含IP安全选项（IPSO）的数据包，这些数据包具有每个接口粒度。这种能力
has been present in many Cisco routers since the early 1990s [Cisco-IPSO-Cmds]. Some government sector products reportedly also support the IP Security Options (IPSO), for example, CANEWARE [RFC4949].
自20世纪90年代初以来，已出现在许多Cisco路由器中[Cisco IPSO Cmds]。据报道，一些政府部门产品还支持IP安全选项（IPSO），例如CANEWARE[RFC4949]。
Support for the IPSO Extended Security Option also is included in the "IPsec Configuration Policy Information Model" [RFC3585] and in the "IPsec Security Policy Database Configuration MIB" [RFC4807]. Section 4.6.1 of the IP Security Domain of Interpretation [RFC2407] includes support for labeled IPsec security associations compatible with the IP Security Options.
对IPSO扩展安全选项的支持也包含在“IPsec配置策略信息模型”[RFC3585]和“IPsec安全策略数据库配置MIB”[RFC4807]中。IP安全解释域[RFC2407]第4.6.1节包括对与IP安全选项兼容的标记IPsec安全关联的支持。
Presence of this option in a packet does not by itself create any specific new threat. Packets with this option ought not normally be seen on the global public Internet.
数据包中存在此选项本身不会产生任何特定的新威胁。具有此选项的数据包通常不应出现在全球公共互联网上。
If packets with this option are blocked or if the option is stripped from the packet during transmission from source to destination, then the packet itself is likely to be dropped by the receiver because it is not properly labeled. In some cases, the receiver might receive the packet but associate an incorrect sensitivity label with the received data from the packet whose ESO was stripped by an intermediate router or firewall. Associating an incorrect sensitivity label can cause the received information either to be handled as more sensitive than it really is ("upgrading") or as less sensitive than it really is ("downgrading"), either of which is problematic.
如果具有此选项的数据包被阻止，或者如果在从源到目的地的传输过程中该选项被从数据包中剥离，则数据包本身可能会被接收器丢弃，因为它没有正确标记。在某些情况下，接收器可能会接收到数据包，但会将错误的敏感度标签与从其ESO被中间路由器或防火墙剥离的数据包接收到的数据相关联。关联错误的敏感度标签可能会导致接收到的信息被处理为比实际敏感度更高（“升级”）或比实际敏感度更低（“降级”），这两者都有问题。
A given IP router, security gateway, or firewall has no way to know a priori what environment it has been deployed into. Even closed IP deployments generally use exactly the same commercial routers, security gateways, and firewalls that are used in the public Internet.
给定的IP路由器、安全网关或防火墙无法事先知道它部署到了什么环境中。即使是封闭式IP部署也通常使用与公共Internet中使用的完全相同的商用路由器、安全网关和防火墙。
Since operational problems result in environments where this option is needed if either the option is dropped or IP packets containing this option are dropped, but no harm results if the option is carried in environments where it is not needed, the default configuration SHOULD NOT (a) modify or remove this IP option or (b) drop an IP packet because the IP packet contains this option.
由于操作问题会导致在丢弃该选项或丢弃包含该选项的IP数据包时需要该选项的环境，但如果在不需要该选项的环境中携带该选项，则不会造成伤害，因此默认配置不应（a）修改或删除该IP选项或（b）丢弃IP数据包，因为IP数据包包含此选项。
A given IP router, security gateway, or firewall MAY be configured to drop this option or to drop IP packets containing this option in an environment known to not use this option.
给定的IP路由器、安全网关或防火墙可配置为丢弃此选项，或在已知不使用此选项的环境中丢弃包含此选项的IP数据包。
For auditing reasons, routers, security gateways, and firewalls SHOULD be capable of logging the numbers of packets containing the ESO on a per-interface basis. Also, routers, security gateways, and firewalls SHOULD be capable of dropping packets based on the ESO presence as well as the ESO values.
出于审计原因，路由器、安全网关和防火墙应能够记录每个接口上包含ESO的数据包数。此外，路由器、安全网关和防火墙应能够基于ESO存在以及ESO值丢弃数据包。
This option was proposed by the Trusted Systems Interoperability Group (TSIG), with the intent of meeting trusted networking requirements for the commercial trusted systems marketplace.
此选项由可信系统互操作性小组（TSIG）提出，旨在满足商业可信系统市场的可信网络要求。
It was implemented in IRIX [IRIX2008] and is currently implemented in a number of operating systems (e.g., Security-Enhanced Linux [SELinux2008] and Solaris [Solaris2008]). It is also currently deployed in a number of high-security networks.
它是在IRIX[IRIX2008]中实现的，目前在许多操作系统中实现（例如，安全增强型Linux[SELinux2008]和Solaris[Solaris2008]）。它目前还部署在一些高安全性网络中。
This option is specified in [CIPSO] and [FIPS1994]. There are zero known IP router implementations of CIPSO. Several MLS operating systems support CIPSO, generally the same MLS operating systems that support IPSO.
[CIPSO]和[FIPS1994]中规定了该选项。CIPSO的已知IP路由器实现为零。多个MLS操作系统支持CIPSO，通常与支持IPSO的MLS操作系统相同。
The TSIG proposal was taken to the Commercial Internet Security Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an Internet-Draft was produced [CIPSO]. The Internet-Draft was never published as an RFC, but the proposal was later standardized by the U.S. National Institute of Standards and Technology (NIST) as "Federal Information Processing Standard Publication 188" [FIPS1994].
TSIG提案已提交给IETF的商业互联网安全选项（CIPSO）工作组[CIPSOWG1994]，并编制了互联网草案[CIPSO]。互联网草案从未作为RFC发布，但该提案后来被美国国家标准与技术研究所（NIST）标准化为“联邦信息处理标准出版物188”[FIPS1994]。
Presence of this option in a packet does not by itself create any specific new threat. Packets with this option ought not normally be seen on the global public Internet.
数据包中存在此选项本身不会产生任何特定的新威胁。具有此选项的数据包通常不应出现在全球公共互联网上。
If packets with this option are blocked or if the option is stripped from the packet during transmission from source to destination, then the packet itself is likely to be dropped by the receiver because it is not properly labeled. In some cases, the receiver might receive the packet but associate an incorrect sensitivity label with the received data from the packet whose CIPSO was stripped by an intermediate router or firewall. Associating an incorrect sensitivity label can cause the received information either to be handled as more sensitive than it really is ("upgrading") or as less sensitive than it really is ("downgrading"), either of which is problematic.
如果具有此选项的数据包被阻止，或者如果在从源到目的地的传输过程中该选项被从数据包中剥离，则数据包本身可能会被接收器丢弃，因为它没有正确标记。在某些情况下，接收器可能接收到数据包，但将不正确的敏感度标签与从其CIPSO被中间路由器或防火墙剥离的数据包接收到的数据相关联。关联错误的敏感度标签可能会导致接收到的信息被处理为比实际敏感度更高（“升级”）或比实际敏感度更低（“降级”），这两者都有问题。
Because of the design of this option, with variable syntax and variable length, it is not practical to support specialized filtering using the CIPSO information. No routers or firewalls are known to support this option. However, routers, security gateways, and firewalls SHOULD NOT by default modify or remove this option from IP packets and SHOULD NOT by default drop packets because they contain this option. For auditing reasons, routers, security gateways, and firewalls SHOULD be capable of logging the numbers of packets containing the CIPSO on a per-interface basis. Also, routers, security gateways, and firewalls SHOULD be capable of dropping packets based on the CIPSO presence.
由于此选项的设计具有可变语法和可变长度，因此不支持使用CIPSO信息进行专门过滤。没有已知的路由器或防火墙支持此选项。但是，路由器、安全网关和防火墙在默认情况下不应修改或删除IP数据包中的此选项，并且在默认情况下不应丢弃数据包，因为它们包含此选项。出于审计原因，路由器、安全网关和防火墙应能够记录每个接口上包含CIPSO的数据包数。此外，路由器、安全网关和防火墙应能够基于CIPSO的存在丢弃数据包。
This options was part of an experiment at the University of Southern California (USC) and was never widely deployed.
这些选项是南加州大学（USC）的一部分实验，从未被广泛应用。
The original option specification is not publicly available. This option has been formally obsoleted by [RFC6814].
原始选项规范不公开。此选项已被[RFC6814]正式淘汰。
Not possible to determine (other than the general security implications of IP options discussed in Section 3), since the corresponding specification is not publicly available.
无法确定（第3节中讨论的IP选项的一般安全影响除外），因为相应的规范不公开。
None.
没有一个
Routers, security gateways, and firewalls SHOULD drop IP packets that contain this option.
路由器、安全网关和防火墙应丢弃包含此选项的IP数据包。
The EIP option was introduced by one of the proposals submitted during the IP Next Generation (IPng) efforts to address the problem of IPv4 address exhaustion.
EIP选项是在IP下一代（IPng）努力解决IPv4地址耗尽问题期间提交的一项提案中引入的。
Specified in [RFC1385]. This option has been formally obsoleted by [RFC6814].
在[RFC1385]中指定。此选项已被[RFC6814]正式淘汰。
This option is obsolete. This option was used (or was intended to be used) to signal that a packet superficially similar to an IPv4 packet actually contained a different protocol, opening up the possibility that an IPv4 node that simply ignored this option would process a received packet in a manner inconsistent with the intent of the sender. There are no known threats arising from this option, other than the general security implications of IP options discussed in Section 3.
此选项已过时。此选项用于（或打算用于）发出信号，表明表面上类似于IPv4数据包的数据包实际上包含不同的协议，从而使忽略此选项的IPv4节点有可能以与发送方意图不一致的方式处理接收到的数据包。除第3节讨论的IP选项的一般安全影响外，此选项不会产生任何已知威胁。
None.
没有一个
Routers, security gateways, and firewalls SHOULD drop packets that contain this option.
路由器、安全网关和防火墙应丢弃包含此选项的数据包。
The Address Extension option was introduced by one of the proposals submitted during the IPng efforts to address the problem of IPv4 address exhaustion.
地址扩展选项是在IPng努力解决IPv4地址耗尽问题期间提交的一项提案中引入的。
Specified in [RFC1475]. This option has been formally obsoleted by [RFC6814].
在[RFC1475]中规定。此选项已被[RFC6814]正式淘汰。
There are no known threats arising from this option, other than the general security implications of IP options discussed in Section 3.
除第3节讨论的IP选项的一般安全影响外，此选项不会产生任何已知威胁。
None.
没有一个
Routers, security gateways, and firewalls SHOULD drop packets that contain this option.
路由器、安全网关和防火墙应丢弃包含此选项的数据包。
This option originally provided unreliable UDP delivery to a set of addresses included in the option.
此选项最初为选项中包含的一组地址提供了不可靠的UDP传递。
This option is specified in RFC 1770 [RFC1770]. It has been formally obsoleted by [RFC6814].
该选项在RFC 1770[RFC1770]中指定。它已被[RFC6814]正式淘汰。
This option could have been exploited for bandwidth-amplification in DoS attacks.
此选项可能在DoS攻击中被用于带宽放大。
None.
没有一个
Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Sender Directed Multi-Destination Delivery option.
路由器、安全网关和防火墙应丢弃包含发送方定向多目的地传递选项的IP数据包。
The Dynamic Packet State option was used to specify the Dynamic Packet State (DPS) in the context of the differentiated services architecture.
动态数据包状态选项用于在区分服务体系结构的上下文中指定动态数据包状态（DPS）。
The Dynamic Packet State option was specified in [DIFFSERV-DPS]. The aforementioned document was meant to be published as "Experimental", but never made it into an RFC. This option has been formally obsoleted by [RFC6814].
[DIFFSERV-DPS]中指定了动态数据包状态选项。上述文件本应作为“实验性”文件发布，但从未将其纳入RFC。此选项已被[RFC6814]正式淘汰。
Possible threats include theft of service and denial of service. However, we note that this option has never been widely implemented or deployed.
可能的威胁包括窃取服务和拒绝服务。然而，我们注意到，这一选择从未得到广泛实施或部署。
None.
没有一个
Routers, security gateways, and firewalls SHOULD drop packets that contain this option.
路由器、安全网关和防火墙应丢弃包含此选项的数据包。
This option was meant to solve the problem of doing upstream forwarding of multicast packets on a multi-access LAN.
此选项旨在解决在多址LAN上进行多播数据包上游转发的问题。
This option was originally specified in [BIDIR-TREES]. It was never formally standardized in the RFC series and was never widely implemented and deployed. Its use was obsoleted by [RFC5015], which
此选项最初在[BIDIR-TREES]中指定。它从未在RFC系列中正式标准化，也从未广泛实施和部署。[RFC5015]废除了其使用
employs a control-plane mechanism to solve the problem of doing upstream forwarding of multicast packets on a multi-access LAN. This option has been formally obsoleted by [RFC6814].
采用控制平面机制来解决在多址LAN上进行多播数据包上游转发的问题。此选项已被[RFC6814]正式淘汰。
This option is obsolete. A router that ignored this option instead of processing it as specified in [BIDIR-TREES] could have forwarded multicast packets to an unintended destination.
此选项已过时。忽略此选项而不是按照[BIDIR-TREES]中的规定处理它的路由器可能已将多播数据包转发到非预期目的地。
None.
没有一个
Routers, security gateways, and firewalls SHOULD drop packets that contain this option.
路由器、安全网关和防火墙应丢弃包含此选项的数据包。
This IP Option is used in the specification of Quick-Start for TCP and IP, which is an experimental mechanism that allows transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period) [RFC4782].
该IP选项用于TCP和IP的快速启动规范中，这是一种实验机制，允许传输协议与路由器合作，以确定允许的发送速率，在开始时，有时在数据传输的中间（例如，在空闲周期之后）[RCF482]。
Specified in RFC 4782 [RFC4782], on the "Experimental" track.
RFC 4782[RFC4782]中规定，在“试验”轨道上。
Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two kinds of attacks:
[RFC4782]第9.6节指出，“快速启动”易受两种攻击：
o attacks to increase the routers' processing and state load, and,
o 增加路由器处理和状态负载的攻击，以及，
o attacks with bogus Quick-Start Requests to temporarily tie up available Quick-Start bandwidth, preventing routers from approving Quick-Start Requests from other connections.
o 使用虚假快速启动请求进行攻击，暂时占用可用的快速启动带宽，阻止路由器批准来自其他连接的快速启动请求。
The Quick-Start functionality would be disabled, and additional delays in TCP's connection establishment (for example) could be introduced. (Please see Section 4.7.2 of [RFC4782].) We note, however, that Quick-Start has been proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet [RFC4782].
快速启动功能将被禁用，TCP的连接建立（例如）可能会引入额外的延迟。（请参见[RFC4782]第4.7.2节）。然而，我们注意到，快速启动被提议作为一种机制，可用于受控环境，而不是一种旨在或适合在全球互联网[RFC4782]中普遍部署的机制。
A given router, security gateway, or firewall system has no way of knowing a priori whether this option is valid in its operational environment. Therefore, routers, security gateways, and firewalls SHOULD, by default, ignore the Quick-Start option. Additionally, routers, security gateways, and firewalls SHOULD have a configuration setting that governs their reaction in the presence of packets containing the Quick-Start option. This configuration setting SHOULD allow to honor and process the option, ignore the option, or drop packets containing this option. The default configuration is to ignore the Quick-Start option.
给定的路由器、安全网关或防火墙系统无法事先知道此选项在其操作环境中是否有效。因此，默认情况下，路由器、安全网关和防火墙应该忽略快速启动选项。此外，路由器、安全网关和防火墙应具有一个配置设置，以控制它们在存在包含快速启动选项的数据包时的反应。此配置设置应允许接受和处理选项、忽略选项或丢弃包含此选项的数据包。默认配置是忽略快速启动选项。
We note that if routers in a given environment do not implement and enable the Quick-Start mechanism, only the general security implications of IP options (discussed in Section 3) would apply.
我们注意到，如果给定环境中的路由器未实现并启用快速启动机制，则仅适用IP选项的一般安全含义（在第3节中讨论）。
Section 2.5 of RFC 4727 [RFC4727] allocates an option number with all defined values of the "copy" and "class" fields for RFC3692-style experiments. This results in four distinct option type codes: 30, 94, 158, and 222.
RFC 4727[RFC4727]第2.5节为RFC3692样式实验分配了一个选项编号，其中包含“复制”和“类”字段的所有定义值。这将导致四个不同的选项类型代码：30、94、158和222。
It is only appropriate to use these values in explicitly configured experiments; they MUST NOT be shipped as defaults in implementations.
只适合在明确配置的实验中使用这些值；它们在实现中不能作为默认值提供。
Specified in RFC 4727 [RFC4727] in the context of RFC3692-style experiments.
在RFC 4727[RFC4727]中，在RFC3692样式实验的上下文中指定。
No specific security issues are known for this IPv4 option.
此IPv4选项不存在特定的安全问题。
None.
没有一个
Routers, security gateways, and firewalls SHOULD have configuration knobs for IP packets that contain RFC3692-style Experiment options to select between "ignore & forward" and "drop & log". Otherwise, no legitimate experiment using these options will be able to traverse any IP router.
路由器、安全网关和防火墙应该为包含RFC3692风格实验选项的IP数据包配置旋钮，以在“忽略和转发”和“删除和记录”之间进行选择。否则，使用这些选项的合法实验将无法遍历任何IP路由器。
Special care needs to be taken in the case of "drop & log". Devices SHOULD count the number of packets dropped, but the logging of drop events SHOULD be limited so as to not overburden device resources.
在“跌落和记录”的情况下，需要特别小心。设备应统计丢弃的数据包的数量，但应限制丢弃事件的记录，以免设备资源负担过重。
The aforementioned configuration knob SHOULD default to "drop & log".
上述配置旋钮应默认为“drop&log”。
Unrecognized IP options are to be ignored. Section 3.2.1.8 of RFC 1122 [RFC1122] specifies this behavior as follows:
无法识别的IP选项将被忽略。RFC 1122[RFC1122]第3.2.1.8节规定了以下行为：
The IP and transport layer MUST each interpret those IP options that they understand and silently ignore the others.
IP层和传输层必须各自解释它们理解的IP选项，并且默默地忽略其他选项。
Additionally, Section 4.2.2.6 of RFC 1812 [RFC1812] specifies it as follows:
此外，RFC 1812[RFC1812]第4.2.2.6节规定如下：
A router MUST ignore IP options which it does not recognize.
路由器必须忽略它无法识别的IP选项。
This document adds that unrecognized IP options MAY also be logged.
本文档补充说，还可能记录无法识别的IP选项。
Further, routers, security gateways, and firewalls MUST provide the ability to log drop events of IP packets containing unrecognized or obsolete options.
此外，路由器、安全网关和防火墙必须能够记录包含未识别或过时选项的IP数据包的丢弃事件。
A number of additional options are listed in the "IP OPTION NUMBERS" IANA registry [IANA-IP] as of the time this document was last edited. Specifically:
截至本文档上次编辑时，“IP选项编号”IANA注册表[IANA-IP]中列出了许多其他选项。明确地：
Copy Class Number Value Name
---- ----- ------ ----- -------------------------------------------
0 0 10 10 ZSU - Experimental Measurement
1 2 13 205 FINN - Experimental Flow Control
0 0 15 15 ENCODE - ???
1 0 16 144 IMITD - IMI Traffic Descriptor
1 0 22 150 - Unassigned (Released 18 Oct. 2005)
Copy Class Number Value Name
---- ----- ------ ----- -------------------------------------------
0 0 10 10 ZSU - Experimental Measurement
1 2 13 205 FINN - Experimental Flow Control
0 0 15 15 ENCODE - ???
1 0 16 144 IMITD - IMI Traffic Descriptor
1 0 22 150 - Unassigned (Released 18 Oct. 2005)
The ENCODE option (type 15) has been formally obsoleted by [RFC6814].
编码选项（类型15）已被[RFC6814]正式淘汰。
The lack of open specifications for these options makes it impossible to evaluate their security implications.
由于缺乏这些选项的开放规范，因此无法评估它们的安全影响。
The lack of open specifications for these options makes it impossible to evaluate the operational and interoperability impact if packets containing these options are blocked.
如果包含这些选项的数据包被阻止，由于缺少这些选项的开放规范，因此无法评估操作和互操作性影响。
Routers, security gateways, and firewalls SHOULD have configuration knobs for IP packets containing these options (or other options not recognized) to select between "ignore & forward" and "drop & log".
路由器、安全网关和防火墙应该为包含这些选项（或其他无法识别的选项）的IP数据包配置旋钮，以便在“忽略和转发”和“删除和记录”之间进行选择。
Section 4.23.1 points out that [RFC1122] and [RFC1812] specify that unrecognized IP options MUST be ignored. However, the previous paragraph states that routers, security gateways, and firewalls SHOULD have a configuration option for dropping and logging IP packets containing unrecognized options. While it is acknowledged that this advice contradicts the previous RFCs' requirements, the advice in this document reflects current operational reality.
第4.23.1节指出，[RFC1122]和[RFC1812]规定必须忽略未识别的IP选项。但是，前一段指出，路由器、安全网关和防火墙应具有用于丢弃和记录包含无法识别选项的IP数据包的配置选项。虽然承认该建议与之前的RFC要求相矛盾，但本文件中的建议反映了当前的运营现实。
Special care needs to be taken in the case of "drop & log". Devices SHOULD count the number of packets dropped, but the logging of drop events SHOULD be limited so as to not overburden device resources.
在“跌落和记录”的情况下，需要特别小心。设备应统计丢弃的数据包的数量，但应限制丢弃事件的记录，以免设备资源负担过重。
This document provides advice on the filtering of IP packets that contain IP options. Dropping such packets can help to mitigate the security issues that arise from use of different IP options. Many of the IPv4 options listed in this document are deprecated and cause no operational impact if dropped. However, dropping packets containing IPv4 options that are in use can cause real operational problems in deployed networks. Therefore, the practice of dropping all IPv4 packets containing one or more IPv4 options without careful consideration is not recommended.
本文档提供有关过滤包含IP选项的IP数据包的建议。丢弃这样的数据包有助于缓解由于使用不同的IP选项而产生的安全问题。本文档中列出的许多IPv4选项都已弃用，如果放弃，将不会对操作造成影响。但是，丢弃包含正在使用的IPv4选项的数据包可能会在已部署的网络中造成实际的操作问题。因此，不建议在不仔细考虑的情况下丢弃包含一个或多个IPv4选项的所有IPv4数据包。
The authors would like to thank (in alphabetical order) Ron Bonica, C. M. Heard, Merike Kaeo, Panos Kampanakis, Suresh Krishnan, Arturo Servin, SM, and Donald Smith for providing thorough reviews and valuable comments. Merike Kaeo also contributed text used in this document.
作者要感谢（按字母顺序排列）Ron Bonica、C.M.Heard、Merike Kaeo、Panos Kampanakis、Suresh Krishnan、Arturo Servin、SM和Donald Smith提供了全面的评论和有价值的评论。Merike Kaeo还提供了本文件中使用的文本。
The authors also wish to thank various network operations folks who supplied feedback on earlier versions of this document but did not wish to be named explicitly in this document.
作者还想感谢各种网络运营人员，他们提供了关于本文档早期版本的反馈，但不希望在本文档中明确提及。
Part of this document is initially based on the document "Security Assessment of the Internet Protocol" [CPNI2008] that is the result of a project carried out by Fernando Gont on behalf of UK CPNI (formerly NISCC). Fernando Gont would like to thank UK CPNI (formerly NISCC) for their continued support.
本文件的一部分最初基于文件“互联网协议的安全评估”[CPNI2008]，该文件是费尔南多·冈特代表英国CPNI（前NISCC）开展的一个项目的结果。费尔南多·冈特感谢英国CPNI（前NISCC）的持续支持。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年2月。
[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月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[RFC6398] Le Faucheur, F., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, October 2011.
[RFC6398]Le Faucheur，F.，“IP路由器警报注意事项和使用”，BCP 168，RFC 6398，2011年10月。
[RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4 Options", RFC 6814, November 2012.
[RFC6814]Pignataro，C.和F.Gont，“正式反对某些IPv4选项”，RFC 6814，2012年11月。
[BIDIR-TREES] Estrin, D. and D. Farinacci, "Bi-Directional Shared Trees in PIM-SM", Work in Progress, May 1999.
[BIDIR-TREES]Estrin，D.和D.Farinaci，“PIM-SM中的双向共享树”，正在进行的工作，1999年5月。
[BREMIER-BARR] Bremier-Barr, A. and H. Levy, "Spoofing prevention method", Proceedings of IEEE InfoCom 2005, Volume 1, pp. 536-547, March 2005.
[BREMIER-BARR]BREMIER-BARR，A.和H.Levy，“欺骗预防方法”，IEEE InfoCom 2005年会议记录，第1卷，第536-547页，2005年3月。
[Biondi2007] Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", CanSecWest 2007 Security Conference, 2007, <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.
[Biondi2007]Biondi，P.和A.Ebalard，“IPv6路由头安全”，CanSecWest 2007安全会议，2007年<http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.
[CIPSOWG1994] IETF CIPSO Working Group, "Commercial Internet Protocol Security Option (CIPSO) Charter", 1994, <http://www.ietf.org/proceedings/94jul/charters/ cipso-charter.html>.
[CIPSOWG1994]IETF CIPSO工作组，“商业互联网协议安全选项（CIPSO）宪章”，1994年<http://www.ietf.org/proceedings/94jul/charters/ cipso charter.html>。
[CIPSO] IETF CIPSO Working Group, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", Work in Progress, 1992.
[CIPSO]IETF CIPSO工作组，“商业IP安全选项（CIPSO 2.2）”，正在进行的工作，1992年。
[CPNI2008] Gont, F., "Security Assessment of the Internet Protocol", 2008, <http://www.gont.com.ar/papers/InternetProtocol.pdf>.
[CPNI2008]Gont，F.，“互联网协议的安全评估”，2008年<http://www.gont.com.ar/papers/InternetProtocol.pdf>.
[Cisco-IPSO-Cmds] Cisco Systems, Inc., "IP Security Options Commands", Cisco IOS Security Command Reference, Release 12.2, <http://www.cisco.com/en/US/docs/ios/12_2/security/ command/reference/srfipso.html>.
[Cisco IPSO Cmds]Cisco Systems，Inc.，“IP安全选项命令”，Cisco IOS安全命令参考，12.2版<http://www.cisco.com/en/US/docs/ios/12_2/security/ 命令/reference/srfipso.html>。
[Cisco-IPSO] Cisco Systems, Inc., "Configuring IP Security Options", Cisco IOS Security Configuration Guide, Release 12.2, 2006, <http://www.cisco.com/en/US/docs/ios/12_2/security/ configuration/guide/scfipso.html>.
[Cisco IPSO]Cisco Systems，Inc.，“配置IP安全选项”，Cisco IOS安全配置指南，2006年12.2版<http://www.cisco.com/en/US/docs/ios/12_2/security/ 配置/guide/scfipso.html>。
[DIFFSERV-DPS] Stoica, I., Zhang, H., Venkitaram, N., and J. Mysore, "Per Hop Behaviors Based on Dynamic Packet State", Work in Progress, October 2002.
[DIFFSERV-DPS]Stoica，I.，Zhang，H.，Venkitaram，N.，和J.Mysore，“基于动态数据包状态的每跳行为”，正在进行的工作，2002年10月。
[FIPS1994] FIPS, "Standard Security Label for Information Transfer", Federal Information Processing Standards Publication, FIP PUBS 188, 1994, <http://csrc.nist.gov/publications/fips/ fips188/fips188.pdf>.
[FIPS1994]FIPS，“信息传输的标准安全标签”，联邦信息处理标准出版物，FIP PUBS 188，1994<http://csrc.nist.gov/publications/fips/ fips188/fips188.pdf>。
[FONSECA] Fonseca, R., Porter, G., Katz, R., Shenker, S., and I. Stoica, "IP Options are not an option", EECS Department, University of California, Berkeley, December 2005, <http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/ EECS-2005-24.html>.
〔丰塞卡〕丰塞卡，R，Porter，G.，卡茨，R，Shenker，S.和S.ToCICA，“IP选项不是一个选项”，加利福尼亚大学ECES系，伯克利，2005年12月，<http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/ EECS-2005-24.html>。
[IANA-IP] IANA, "IP OPTION NUMBERS", <http://www.iana.org/assignments/ip-parameters>.
[IANA-IP]IANA，“IP选项编号”<http://www.iana.org/assignments/ip-parameters>.
[IRIX2008] IRIX, "IRIX 6.5 trusted_networking(7) manual page", 2008, <http://techpubs.sgi.com/library/tpl/cgi-bin/ getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/ cat7/trusted_networking.z>.
[IRIX2008]IRIX，“IRIX 6.5可信网络（7）手册页”，2008年<http://techpubs.sgi.com/library/tpl/cgi-bin/ getdoc.cgi？coll=0650&db=man&fname=/usr/share/catman/a_man/cat7/trusted_networking.z>。
[Kohno2005] Kohno, T., Broido, A., and kc. Claffy, "Remote Physical Device Fingerprinting", IEEE Transactions on Dependable and Secure Computing, Vol. 2, No. 2, 2005.
[Kohno2005]Kohno，T.，Broido，A.，和kc。Claffy，“远程物理设备指纹”，IEEE可靠和安全计算交易，第2卷，第2期，2005年。
[Landwehr81] Landwehr, C., "Formal Models for Computer Security", ACM Computing Surveys, Vol. 13, No. 3, Association for Computing Machinery, New York, NY, USA, September 1981.
[Landwehr81]Landwehr，C.，“计算机安全的正式模型”，ACM计算调查，第13卷，第3期，计算机械协会，纽约，纽约，美国，1981年9月。
[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Measurement, October 2004.
[MEDINA]MEDINA，A.，Allman，M.，和S.Floyd，“测量传输协议和中间盒之间的交互”，Proc。第四届ACM SIGCOMM/USENIX互联网测量会议，2004年10月。
[Microsoft1999] Microsoft, "Microsoft Security Program: Microsoft Security Bulletin (MS99-038). Patch Available for "Spoofed Route Pointer" Vulnerability", September 1999, <http://www.microsoft.com/technet/security/bulletin/ ms99-038.mspx>.
[Microsoft1999]Microsoft，“Microsoft安全计划：Microsoft安全公告（MS99-038）”。可用于“伪造路由指针”漏洞的修补程序，1999年9月<http://www.microsoft.com/technet/security/bulletin/ ms99-038.mspx>。
[OpenBSD1998] OpenBSD, "OpenBSD Security Advisory: IP Source Routing Problem", February 1998, <http://www.openbsd.org/advisories/sourceroute.txt>.
[OpenBSD1998]OpenBSD，“OpenBSD安全咨询：IP源路由问题”，1998年2月<http://www.openbsd.org/advisories/sourceroute.txt>.
[RFC1038] St. Johns, M., "Draft revised IP security option", RFC 1038, January 1988.
[RFC1038]圣约翰，M.，“修订后的IP安全选项草案”，RFC 1038，1988年1月。
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU discovery options", RFC 1063, July 1988.
[RFC1063]Mogul，J.，Kent，C.，Partridge，C.，和K.McCloghrie，“IP MTU发现选项”，RFC 1063，1988年7月。
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.
[RFC1108]Kent，S.，“美国国防部互联网协议的安全选项”，RFC1108，1991年11月。
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992.
[RFC1385]Wang，Z.，“EIP：扩展互联网协议”，RFC1385，1992年11月。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393]Malkin，G.“使用IP选项的跟踪路由”，RFC 1393，1993年1月。
[RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, June 1993.
[RFC1475]Ullmann，R.，“TP/IX：下一个互联网”，RFC 14751993年6月。
[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
[RFC1770]Graff，C.，“发送方定向多目的地交付的IPv4选项”，RFC1770，1995年3月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec Configuration Policy Information Model", RFC 3585, August 2003.
[RFC3585]Jason，J.，Rafalow，L.，和E.Vyncke，“IPsec配置策略信息模型”，RFC 3585，2003年8月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, January 2007.
[RFC4782]Floyd，S.，Allman，M.，Jain，A.，和P.Sarolahti，“TCP和IP的快速启动”，RFC 4782，2007年1月。
[RFC4807] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, "IPsec Security Policy Database Configuration MIB", RFC 4807, March 2007.
[RFC4807]Baer，M.，Charlet，R.，Hardaker，W.，Story，R.，和C.Wang，“IPsec安全策略数据库配置MIB”，RFC 4807，2007年3月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the IPv4 and IPv6 Router Alert Options", RFC 5350, September 2008.
[RFC5350]Way，J.和A.McDonald，“IPv4和IPv6路由器警报选项的IANA注意事项”，RFC 5350，2008年9月。
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, July 2009.
[RFC5570]StJohns，M.，Atkinson，R.，和G.Thomas，“通用架构标签IPv6安全选项（CALIPSO）”，RFC 55702009年7月。
[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月。
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011.
[RFC6192]Dugal，D.，Pignataro，C.，和R.Dunn，“保护路由器控制平面”，RFC 61922011年3月。
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol Version 4", RFC 6274, July 2011.
[RFC6274]Gont，F.，“互联网协议版本4的安全评估”，RFC 62742011年7月。
[SELinux2008] National Security Agency (United States), "Security-Enhanced Linux - NSA/CSS", January 2009, <http://www.nsa.gov/research/selinux/index.shtml>.
[SELinux2008]美国国家安全局，“安全增强型Linux-NSA/CSS”，2009年1月<http://www.nsa.gov/research/selinux/index.shtml>.
[Solaris2008] "Solaris Trusted Extensions: Labeled Security for Absolute Protection", 2008, <http://www.oracle.com/technetwork/server-storage/ solaris10/overview/trusted-extensions-149944.pdf>.
[Solaris2008]“Solaris受信任扩展：标记为绝对保护的安全性”，2008年<http://www.oracle.com/technetwork/server-storage/ solaris10/overview/trusted-extensions-149944.pdf>。
Authors' Addresses
作者地址
Fernando Gont UTN-FRH / SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont UTN-FRH/SI6 Networks Evaristo Carriego 2644 Haedo，布宜诺斯艾利斯省1706阿根廷
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
RJ Atkinson Consultant McLean, VA 22103 USA
RJ阿特金森咨询公司麦克莱恩，弗吉尼亚州22103美国
EMail: rja.lists@gmail.com
EMail: rja.lists@gmail.com
Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA
Carlos Pignataro Cisco Systems，Inc.美国北卡罗来纳州Kit Creek Road研究三角公园7200-12号，邮编：27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com