Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6274 UK CPNI
Category: Informational July 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6274 UK CPNI
Category: Informational July 2011
ISSN: 2070-1721
Security Assessment of the Internet Protocol Version 4
Internet协议版本4的安全评估
Abstract
摘要
This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI).
本文档包含对Internet协议版本4的IETF规范以及流行IPv4实现使用的许多机制和策略的安全评估。它基于英国国家基础设施保护中心（CPNI）开展的一个项目的结果。
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/rfc6274.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6274.
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许可证中所述的无担保。
Table of Contents
目录
1. Preface .........................................................4
1.1. Introduction ...............................................4
1.2. Scope of This Document .....................................6
1.3. Organization of This Document ..............................7
2. The Internet Protocol ...........................................7
3. Internet Protocol Header Fields .................................8
3.1. Version ....................................................9
3.2. IHL (Internet Header Length) ..............................10
3.3. Type of Service (TOS) .....................................10
3.3.1. Original Interpretation ............................10
3.3.2. Standard Interpretation ............................12
3.3.2.1. Differentiated Services Field .............12
3.3.2.2. Explicit Congestion Notification (ECN) ....13
3.4. Total Length ..............................................14
3.5. Identification (ID) .......................................15
3.5.1. Some Workarounds Implemented by the Industry .......16
3.5.2. Possible Security Improvements .....................17
3.5.2.1. Connection-Oriented Transport Protocols ...17
3.5.2.2. Connectionless Transport Protocols ........18
3.6. Flags .....................................................19
3.7. Fragment Offset ...........................................21
3.8. Time to Live (TTL) ........................................22
3.8.1. Fingerprinting the Operating System in Use
by the Source Host .................................24
3.8.2. Fingerprinting the Physical Device from
which the Packets Originate ........................24
3.8.3. Mapping the Network Topology .......................24
3.8.4. Locating the Source Host in the Network Topology ...25
3.8.5. Evading Network Intrusion Detection Systems ........26
3.8.6. Improving the Security of Applications That
Make Use of the Internet Protocol (IP) .............27
3.8.7. Limiting Spread ....................................28
3.9. Protocol ..................................................28
3.10. Header Checksum ..........................................28
3.11. Source Address ...........................................29
3.12. Destination Address ......................................30
3.13. Options ..................................................30
3.13.1. General Issues with IP Options ....................31
3.13.1.1. Processing Requirements ..................31
3.13.1.2. Processing of the Options by the
Upper-Layer Protocol .....................32
3.13.1.3. General Sanity Checks on IP Options ......32
3.13.2. Issues with Specific Options ......................34
3.13.2.1. End of Option List (Type=0) ..............34
3.13.2.2. No Operation (Type=1) ....................34
1. Preface .........................................................4
1.1. Introduction ...............................................4
1.2. Scope of This Document .....................................6
1.3. Organization of This Document ..............................7
2. The Internet Protocol ...........................................7
3. Internet Protocol Header Fields .................................8
3.1. Version ....................................................9
3.2. IHL (Internet Header Length) ..............................10
3.3. Type of Service (TOS) .....................................10
3.3.1. Original Interpretation ............................10
3.3.2. Standard Interpretation ............................12
3.3.2.1. Differentiated Services Field .............12
3.3.2.2. Explicit Congestion Notification (ECN) ....13
3.4. Total Length ..............................................14
3.5. Identification (ID) .......................................15
3.5.1. Some Workarounds Implemented by the Industry .......16
3.5.2. Possible Security Improvements .....................17
3.5.2.1. Connection-Oriented Transport Protocols ...17
3.5.2.2. Connectionless Transport Protocols ........18
3.6. Flags .....................................................19
3.7. Fragment Offset ...........................................21
3.8. Time to Live (TTL) ........................................22
3.8.1. Fingerprinting the Operating System in Use
by the Source Host .................................24
3.8.2. Fingerprinting the Physical Device from
which the Packets Originate ........................24
3.8.3. Mapping the Network Topology .......................24
3.8.4. Locating the Source Host in the Network Topology ...25
3.8.5. Evading Network Intrusion Detection Systems ........26
3.8.6. Improving the Security of Applications That
Make Use of the Internet Protocol (IP) .............27
3.8.7. Limiting Spread ....................................28
3.9. Protocol ..................................................28
3.10. Header Checksum ..........................................28
3.11. Source Address ...........................................29
3.12. Destination Address ......................................30
3.13. Options ..................................................30
3.13.1. General Issues with IP Options ....................31
3.13.1.1. Processing Requirements ..................31
3.13.1.2. Processing of the Options by the
Upper-Layer Protocol .....................32
3.13.1.3. General Sanity Checks on IP Options ......32
3.13.2. Issues with Specific Options ......................34
3.13.2.1. End of Option List (Type=0) ..............34
3.13.2.2. No Operation (Type=1) ....................34
3.13.2.3. Loose Source and Record Route
(LSRR) (Type=131) ........................34
3.13.2.4. Strict Source and Record Route
(SSRR) (Type=137) ........................37
3.13.2.5. Record Route (Type=7) ....................39
3.13.2.6. Stream Identifier (Type=136) .............40
3.13.2.7. Internet Timestamp (Type=68) .............40
3.13.2.8. Router Alert (Type=148) ..................43
3.13.2.9. Probe MTU (Type=11) (Obsolete) ...........44
3.13.2.10. Reply MTU (Type=12) (Obsolete) ..........44
3.13.2.11. Traceroute (Type=82) ....................44
3.13.2.12. Department of Defense (DoD)
Basic Security Option (Type=130) ........45
3.13.2.13. DoD Extended Security Option
(Type=133) ..............................46
3.13.2.14. Commercial IP Security Option
(CIPSO) (Type=134) ......................47
3.13.2.15. Sender Directed
Multi-Destination Delivery (Type=149) ...47
4. Internet Protocol Mechanisms ...................................48
4.1. Fragment Reassembly .......................................48
4.1.1. Security Implications of Fragment Reassembly .......49
4.1.1.1. Problems Related to Memory Allocation .....49
4.1.1.2. Problems That Arise from the
Length of the IP Identification Field .....51
4.1.1.3. Problems That Arise from the
Complexity of the Reassembly Algorithm ....52
4.1.1.4. Problems That Arise from the
Ambiguity of the Reassembly Process .......52
4.1.1.5. Problems That Arise from the Size
of the IP Fragments .......................53
4.1.2. Possible Security Improvements .....................53
4.1.2.1. Memory Allocation for Fragment
Reassembly ................................53
4.1.2.2. Flushing the Fragment Buffer ..............54
4.1.2.3. A More Selective Fragment Buffer
Flushing Strategy .........................55
4.1.2.4. Reducing the Fragment Timeout .............57
4.1.2.5. Countermeasure for Some NIDS
Evasion Techniques ........................58
4.1.2.6. Countermeasure for Firewall-Rules
Bypassing .................................58
4.2. Forwarding ................................................58
4.2.1. Precedence-Ordered Queue Service ...................58
4.2.2. Weak Type of Service ...............................59
4.2.3. Impact of Address Resolution on Buffer Management ..60
4.2.4. Dropping Packets ...................................61
4.3. Addressing ................................................61
3.13.2.3. Loose Source and Record Route
(LSRR) (Type=131) ........................34
3.13.2.4. Strict Source and Record Route
(SSRR) (Type=137) ........................37
3.13.2.5. Record Route (Type=7) ....................39
3.13.2.6. Stream Identifier (Type=136) .............40
3.13.2.7. Internet Timestamp (Type=68) .............40
3.13.2.8. Router Alert (Type=148) ..................43
3.13.2.9. Probe MTU (Type=11) (Obsolete) ...........44
3.13.2.10. Reply MTU (Type=12) (Obsolete) ..........44
3.13.2.11. Traceroute (Type=82) ....................44
3.13.2.12. Department of Defense (DoD)
Basic Security Option (Type=130) ........45
3.13.2.13. DoD Extended Security Option
(Type=133) ..............................46
3.13.2.14. Commercial IP Security Option
(CIPSO) (Type=134) ......................47
3.13.2.15. Sender Directed
Multi-Destination Delivery (Type=149) ...47
4. Internet Protocol Mechanisms ...................................48
4.1. Fragment Reassembly .......................................48
4.1.1. Security Implications of Fragment Reassembly .......49
4.1.1.1. Problems Related to Memory Allocation .....49
4.1.1.2. Problems That Arise from the
Length of the IP Identification Field .....51
4.1.1.3. Problems That Arise from the
Complexity of the Reassembly Algorithm ....52
4.1.1.4. Problems That Arise from the
Ambiguity of the Reassembly Process .......52
4.1.1.5. Problems That Arise from the Size
of the IP Fragments .......................53
4.1.2. Possible Security Improvements .....................53
4.1.2.1. Memory Allocation for Fragment
Reassembly ................................53
4.1.2.2. Flushing the Fragment Buffer ..............54
4.1.2.3. A More Selective Fragment Buffer
Flushing Strategy .........................55
4.1.2.4. Reducing the Fragment Timeout .............57
4.1.2.5. Countermeasure for Some NIDS
Evasion Techniques ........................58
4.1.2.6. Countermeasure for Firewall-Rules
Bypassing .................................58
4.2. Forwarding ................................................58
4.2.1. Precedence-Ordered Queue Service ...................58
4.2.2. Weak Type of Service ...............................59
4.2.3. Impact of Address Resolution on Buffer Management ..60
4.2.4. Dropping Packets ...................................61
4.3. Addressing ................................................61
4.3.1. Unreachable Addresses ..............................61
4.3.2. Private Address Space ..............................61
4.3.3. Former Class D Addresses (224/4 Address Block) .....62
4.3.4. Former Class E Addresses (240/4 Address Block) .....62
4.3.5. Broadcast/Multicast Addresses and
Connection-Oriented Protocols ......................62
4.3.6. Broadcast and Network Addresses ....................63
4.3.7. Special Internet Addresses .........................63
5. Security Considerations ........................................65
6. Acknowledgements ...............................................65
7. References .....................................................66
7.1. Normative References ......................................66
7.2. Informative References ....................................68
4.3.1. Unreachable Addresses ..............................61
4.3.2. Private Address Space ..............................61
4.3.3. Former Class D Addresses (224/4 Address Block) .....62
4.3.4. Former Class E Addresses (240/4 Address Block) .....62
4.3.5. Broadcast/Multicast Addresses and
Connection-Oriented Protocols ......................62
4.3.6. Broadcast and Network Addresses ....................63
4.3.7. Special Internet Addresses .........................63
5. Security Considerations ........................................65
6. Acknowledgements ...............................................65
7. References .....................................................66
7.1. Normative References ......................................66
7.2. Informative References ....................................68
The TCP/IP protocols were conceived in an environment that was quite different from the hostile environment in which they currently operate. However, the effectiveness of the protocols led to their early adoption in production environments, to the point that, to some extent, the current world's economy depends on them.
TCP/IP协议是在一个与其当前运行的敌对环境完全不同的环境中构思的。然而，这些协议的有效性导致了它们在生产环境中的早期采用，以至于在某种程度上，当前的世界经济依赖于它们。
While many textbooks and articles have created the myth that the Internet protocols were designed for warfare environments, the top level goal for the Defense Advanced Research Projects Agency (DARPA) Internet Program was the sharing of large service machines on the ARPANET [Clark1988]. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications.
虽然许多教科书和文章制造了互联网协议是为战争环境设计的神话，但国防高级研究计划局（DARPA）互联网计划的最高目标是在ARPANET上共享大型服务机器[Clark1988]。因此，许多协议规范只关注它们指定的协议的操作方面，而忽略了它们的安全含义。
While the Internet technology evolved since its inception, the Internet's building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years, many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some of them were based on flaws in some protocol implementations, affecting only a reduced number of systems, while others were based on flaws in the protocols themselves, affecting virtually every existing implementation [Bellovin1989]. Even in the last couple of years, researchers were still working on security problems in the core protocols [RFC5927] [Watson2004] [NISCC2004] [NISCC2005].
虽然互联网技术从一开始就在发展，但互联网的构建块基本上与20多年前ARPANET采用的核心协议相同。在过去二十年中，在许多系统的TCP/IP堆栈中发现了许多漏洞。其中一些是基于某些协议实现中的缺陷，仅影响较少的系统，而另一些是基于协议本身的缺陷，影响几乎所有现有实现[Bellovin1989]。即使在过去几年中，研究人员仍在研究核心协议[RFC5927][Watson2004][NISC2004][NISCC2005]中的安全问题。
The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats and the best mitigations known at the time the
TCP/IP协议漏洞的发现导致许多CSIRT（计算机安全事件响应团队）和供应商发布了报告，这有助于提高对威胁的认识，以及当时已知的最佳缓解措施
reports were published. Unfortunately, this also led to the documentation of the discovered protocol vulnerabilities being spread among a large number of documents, which are sometimes difficult to identify.
报告已经发表。不幸的是，这也导致发现的协议漏洞的文档散布在大量文档中，有时难以识别。
For some reason, much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force). This basically led to a situation in which "known" security problems have not always been addressed by all vendors. In addition, in many cases, vendors have implemented quick "fixes" to protocol flaws without a careful analysis of their effectiveness and their impact on interoperability [Silbersack2005].
出于某种原因，安全团体在互联网协议方面的许多努力并没有导致IETF（互联网工程任务组）发布正式文件（RFC）。这基本上导致了“已知”安全问题并非总是由所有供应商解决的情况。此外，在许多情况下，供应商在没有仔细分析协议缺陷的有效性及其对互操作性的影响的情况下，对协议缺陷实施了快速“修复”[Silbersack2005]。
The lack of adoption of these fixes by the IETF means that any system built in the future according to the official TCP/IP specifications will reincarnate security flaws that have already hit our communication systems in the past.
IETF没有采用这些修复，这意味着未来根据官方TCP/IP规范构建的任何系统都将重现过去已经影响我们通信系统的安全缺陷。
Nowadays, producing a secure TCP/IP implementation is a very difficult task, in part because of the lack of a single document that serves as a security roadmap for the protocols. Implementers are faced with the hard task of identifying relevant documentation and differentiating between that which provides correct advisory and that which provides misleading advisory based on inaccurate or wrong assumptions.
如今，生成一个安全的TCP/IP实现是一项非常困难的任务，部分原因是缺少作为协议安全路线图的单个文档。实施者面临着一项艰巨的任务，即识别相关文档，区分提供正确咨询的文档和基于不准确或错误假设提供误导性咨询的文档。
There is a clear need for a companion document to the IETF specifications; one that discusses the security aspects and implications of the protocols, identifies the possible threats, discusses the possible countermeasures, and analyzes their respective effectiveness.
显然需要IETF规范的配套文件；讨论协议的安全方面和含义，识别可能的威胁，讨论可能的对策，并分析其各自的有效性。
This document is the result of an assessment of the IETF specifications of the Internet Protocol version 4 (IPv4), from a security point of view. Possible threats were identified and, where possible, countermeasures were proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. Furthermore, this document does not limit itself to performing a security assessment of the relevant IETF specifications, but also provides an assessment of common implementation strategies found in the real world.
本文件是从安全角度对互联网协议版本4（IPv4）的IETF规范进行评估的结果。确定了可能的威胁，并在可能的情况下提出了对策。此外，许多导致安全漏洞的实现缺陷已被提及，希望未来的实现不会产生同样的问题。此外，本文件不限于对相关IETF规范进行安全评估，还提供了对现实世界中常见实施策略的评估。
Many IP implementations have also been subject of the so-called "packet-of-death" vulnerabilities, in which a single specially crafted packet causes the IP implementation to crash or otherwise misbehave. In most cases, the attack packet is simply malformed; in
许多IP实现也受到所谓的“死亡数据包”漏洞的影响，其中一个精心编制的数据包会导致IP实现崩溃或行为异常。在大多数情况下，攻击数据包只是格式不正确；在里面
other cases, the attack packet is well-formed, but exercises a little used path through the IP stack. Well-designed IP implementations should protect against these attacks, and therefore this document describes a number of sanity checks that are expected to prevent most of the aforementioned "packet-of-death" attack vectors. We note that if an IP implementation is found to be vulnerable to one of these attacks, administrators must resort to mitigating them by packet filtering.
在其他情况下，攻击数据包格式良好，但在IP堆栈中使用很少的路径。设计良好的IP实现应该能够防止这些攻击，因此本文档描述了一些健全性检查，这些检查有望防止上述大多数“死亡数据包”攻击向量。我们注意到，如果发现IP实现容易受到这些攻击之一的攻击，管理员必须通过数据包过滤来减轻这些攻击。
Additionally, this document analyzes the security implications from changes in the operational environment since the Internet Protocol was designed. For example, it analyzes how the Internet Protocol could be exploited to evade Network Intrusion Detection Systems (NIDSs) or to circumvent firewalls.
此外，本文件还分析了自设计互联网协议以来，操作环境变化对安全的影响。例如，它分析了如何利用互联网协议规避网络入侵检测系统（NIDS）或防火墙。
This document does not aim to be the final word on the security of the Internet Protocol (IP). On the contrary, it aims to raise awareness about many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the Internet Protocol (IP), but also provides insights about the security aspects of the Internet Protocol that may be of help to the Internet operations community.
本文件的目的并不是要对互联网协议（IP）的安全性做出最终决定。相反，它的目的是提高人们对基于IP协议的许多安全威胁的认识，这些威胁过去曾面临过，现在我们正面临，将来我们可能仍要应对。它为Internet协议（IP）的安全实施提供了建议，但也提供了有关Internet协议安全方面的见解，这可能对Internet操作社区有所帮助。
Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new threats are discovered.
我们非常鼓励社区提供反馈，以帮助本文档尽可能准确，并在发现新威胁时不断更新。
This document is heavily based on the "Security Assessment of the Internet Protocol" [CPNI2008] released by the UK Centre for the Protection of National Infrastructure (CPNI), available at http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx.
本文件主要基于英国国家基础设施保护中心（CPNI）发布的“互联网协议安全评估”[CPNI2008]，可在http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx.
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
While there are a number of protocols that affect the way in which IP systems operate, this document focuses only on the specifications of the Internet Protocol (IP). For example, routing and bootstrapping protocols are considered out of the scope of this project.
虽然有许多协议会影响IP系统的运行方式，但本文档仅关注Internet协议（IP）的规范。例如，路由和引导协议被认为不在本项目的范围之内。
The following IETF RFCs were selected as the primary sources for the assessment as part of this work:
以下IETF RFC被选为评估的主要来源，作为本工作的一部分：
o RFC 791, "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION" (45 pages).
o RFC 791，“互联网协议DARPA互联网程序协议规范”（45页）。
o RFC 815, "IP DATAGRAM REASSEMBLY ALGORITHMS" (9 pages).
o RFC 815，“IP数据报重组算法”（9页）。
o RFC 919, "BROADCASTING INTERNET DATAGRAMS" (8 pages).
o RFC 919，“广播互联网数据报”（8页）。
o RFC 950, "Internet Standard Subnetting Procedure" (18 pages)
o RFC 950，“互联网标准子网程序”（18页）
o RFC 1112, "Host Extensions for IP Multicasting" (17 pages)
o RFC 1112，“IP多播的主机扩展”（17页）
o RFC 1122, "Requirements for Internet Hosts -- Communication Layers" (116 pages).
o RFC 1122，“互联网主机的要求——通信层”（116页）。
o RFC 1812, "Requirements for IP Version 4 Routers" (175 pages).
o RFC 1812，“IP版本4路由器的要求”（175页）。
o RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" (20 pages).
o RFC 2474，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”（20页）。
o RFC 2475, "An Architecture for Differentiated Services" (36 pages).
o RFC 2475，“差异化服务的体系结构”（36页）。
o RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP" (63 pages).
o RFC 3168，“向IP添加显式拥塞通知（ECN）”（63页）。
o RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan" (27 pages).
o RFC 4632，“无类别域间路由（CIDR）：互联网地址分配和聚合计划”（27页）。
This document is basically organized in two parts: "Internet Protocol header fields" and "Internet Protocol mechanisms". The former contains an analysis of each of the fields of the Internet Protocol header, identifies their security implications, and discusses possible countermeasures for the identified threats. The latter contains an analysis of the security implications of the mechanisms implemented by the Internet Protocol.
本文档基本上分为两部分：“Internet协议头字段”和“Internet协议机制”。前者包含对Internet协议头的每个字段的分析，确定其安全含义，并讨论针对已识别威胁的可能对策。后者包含对互联网协议实现的机制的安全影响的分析。
The Internet Protocol (IP) provides a basic data transfer function for passing data blocks called "datagrams" from a source host to a destination host, across the possible intervening networks. Additionally, it provides some functions that are useful for the interconnection of heterogeneous networks, such as fragmentation and reassembly.
互联网协议（IP）提供了一种基本的数据传输功能，用于将称为“数据报”的数据块从源主机通过可能的中间网络传递到目标主机。此外，它还提供了一些对异构网络互连有用的功能，如分段和重组。
The "datagram" has a number of characteristics that makes it convenient for interconnecting systems [Clark1988]:
“数据报”具有许多特性，便于互连系统[Clark1988]：
o It eliminates the need of connection state within the network, which improves the survivability characteristics of the network.
o 它消除了网络内连接状态的需要，提高了网络的生存性特征。
o It provides a basic service of data transport that can be used as a building block for other transport services (reliable data transport services, etc.).
o 它提供了数据传输的基本服务，可以用作其他传输服务（可靠的数据传输服务等）的构建块。
o It represents the minimum network service assumption, which enables IP to be run over virtually any network technology.
o 它代表了最小网络服务假设，使IP能够在几乎任何网络技术上运行。
The IETF specifications of the Internet Protocol define the syntax of the protocol header, along with the semantics of each of its fields. Figure 1 shows the format of an IP datagram, as specified in [RFC0791].
互联网协议的IETF规范定义了协议头的语法及其每个字段的语义。图1显示了[RFC0791]中指定的IP数据报的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Options ] | [ Padding ] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Options ] | [ Padding ] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Internet Protocol Header Format
图1：Internet协议头格式
Even though the minimum IP header size is 20 bytes, an IP module might be handed an (illegitimate) "datagram" of less than 20 bytes. Therefore, before doing any processing of the IP header fields, the following check should be performed by the IP module on the packets handed by the link layer:
即使最小IP报头大小为20字节，IP模块也可能会收到一份小于20字节的（非法）“数据报”。因此，在对IP报头字段进行任何处理之前，IP模块应对链路层传递的数据包执行以下检查：
LinkLayer.PayloadSize >= 20
LinkLayer.PayloadSize>=20
where LinkLayer.PayloadSize is the length (in octets) of the datagram passed from the link layer to the IP layer.
其中LinkLayer.PayloadSize是从链路层传递到IP层的数据报的长度（以八位字节为单位）。
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并应记录该事件（例如，计数器可递增以反映数据包丢弃）。
The following subsections contain further sanity checks that should be performed on IP packets.
以下小节包含应在IP数据包上执行的进一步健全性检查。
This is a 4-bit field that indicates the version of the Internet Protocol (IP), and thus the syntax of the packet. For IPv4, this field must be 4.
这是一个4位字段，指示Internet协议（IP）的版本，从而指示数据包的语法。对于IPv4，此字段必须为4。
When a link-layer protocol de-multiplexes a packet to an Internet module, it does so based on a Protocol Type field in the data-link packet header.
当链路层协议将分组解复用到因特网模块时，它基于数据链路分组报头中的协议类型字段进行解复用。
In theory, different versions of IP could coexist on a network by using the same Protocol Type at the link layer, but a different value in the Version field of the IP header. Thus, a single IP module could handle all versions of the Internet Protocol, differentiating them by means of this field.
理论上，通过在链路层使用相同的协议类型，但在IP头的版本字段中使用不同的值，不同版本的IP可以在网络上共存。因此，单个IP模块可以处理所有版本的Internet协议，通过此字段区分它们。
However, in practice different versions of IP are identified by a different Protocol Type (e.g., EtherType in the case of Ethernet) number in the link-layer protocol header. For example, IPv4 datagrams are encapsulated in Ethernet frames using an EtherType of 0x0800, while IPv6 datagrams are encapsulated in Ethernet frames using an EtherType of 0x86DD [IANA_ET].
然而，在实践中，不同版本的IP由链路层协议报头中的不同协议类型（例如，以太网中的EtherType）编号标识。例如，IPv4数据报使用以太网类型0x0800封装在以太网帧中，而IPv6数据报使用以太网类型0x86DD[IANA_ET]封装在以太网帧中。
Therefore, if an IPv4 module receives a packet, the Version field must be checked to be 4. If this check fails, the packet should be silently dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop). If an implementation does not perform this check, an attacker could use a different value for the Version field, possibly evading NIDSs that decide which pattern-matching rules to apply based on the Version field.
因此，如果IPv4模块接收到数据包，则必须将版本字段检查为4。如果该检查失败，数据包应该被静默丢弃，并且应该记录该事件（例如，计数器可以增加以反映数据包丢弃）。如果某个实现未执行此检查，则攻击者可能会对版本字段使用不同的值，从而可能规避根据版本字段决定应用哪种模式匹配规则的NIDS。
If the link-layer protocol employs a specific "Protocol Type" value for encapsulating IPv4 packets (e.g., as is the case of Ethernet), a node should check that IPv4 packets are de-multiplexed to the IPv4 module when such value was used for the Protocol Type field of the link-layer protocol. If a packet does not pass this check, it should be silently dropped.
如果链路层协议使用特定的“协议类型”值来封装IPv4数据包（例如，如以太网），则当该值用于链路层协议的协议类型字段时，节点应检查IPv4数据包是否被解复用到IPv4模块。如果一个包没有通过这个检查，它应该被悄悄地丢弃。
An attacker could encapsulate IPv4 packets using other link-layer "Protocol Type" values to try to subvert link-layer Access Control Lists (ACLs) and/or for tampering with NIDSs.
攻击者可以使用其他链路层“协议类型”值封装IPv4数据包，试图破坏链路层访问控制列表（ACL）和/或篡改NIDS。
The IHL (Internet Header Length) field indicates the length of the Internet header in 32-bit words (4 bytes). The following paragraphs describe a number of sanity checks to be performed on the IHL field, such that possible packet-of-death vulnerabilities are avoided.
IHL（Internet标头长度）字段以32位字（4字节）表示Internet标头的长度。以下段落描述了将在IHL字段上执行的一些健全性检查，以避免可能的死亡漏洞包。
As the minimum datagram size is 20 bytes, the minimum legal value for this field is 5. Therefore, the following check should be enforced:
由于最小数据报大小为20字节，因此该字段的最小法定值为5。因此，应执行以下检查：
IHL >= 5
国际人道主义法>=5
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并应记录该事件（例如，计数器可递增以反映数据包丢弃）。
For obvious reasons, the Internet header cannot be larger than the whole Internet datagram of which it is part. Therefore, the following check should be enforced:
由于明显的原因，Internet报头不能大于它所属的整个Internet数据报。因此，应执行以下检查：
IHL * 4 <= Total Length
IHL * 4 <= Total Length
This needs to refer to the size of the datagram as specified by the sender in the Total Length field, since link layers might have added some padding (see Section 3.4).
这需要参考发送方在“总长度”字段中指定的数据报大小，因为链接层可能添加了一些填充（参见第3.4节）。
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并应记录该事件（例如，计数器可递增以反映数据包丢弃）。
The above check allows for Internet datagrams with no data bytes in the payload that, while nonsensical for virtually every protocol that runs over IP, are still legal.
上面的检查允许有效负载中没有数据字节的Internet数据报，虽然对于几乎所有通过IP运行的协议来说都是不合理的，但仍然是合法的。
Figure 2 shows the original syntax of the Type of Service field, as defined by RFC 791 [RFC0791] and updated by RFC 1349 [RFC1349]. This definition has been superseded long ago (see Sections 3.3.2.1 and 3.3.2.2), but it is still assumed by some deployed implementations.
图2显示了由RFC 791[RFC0791]定义并由RFC 1349[RFC1349]更新的服务类型字段的原始语法。这一定义早已被取代（见第3.3.2.1节和第3.3.2.2节），但仍由一些已部署的实现假设。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | D | T | R | C | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | D | T | R | C | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 2: Type of Service Field (Original Interpretation)
图2：服务领域类型（原始解释）
+----------+----------------------------------------------+
| Bits 0-2 | Precedence |
+----------+----------------------------------------------+
| Bit 3 | 0 = Normal Delay, 1 = Low Delay |
+----------+----------------------------------------------+
| Bit 4 | 0 = Normal Throughput, 1 = High Throughput |
+----------+----------------------------------------------+
| Bit 5 | 0 = Normal Reliability, 1 = High Reliability |
+----------+----------------------------------------------+
| Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost |
+----------+----------------------------------------------+
| Bits 7 | Reserved for Future Use (must be zero) |
+----------+----------------------------------------------+
+----------+----------------------------------------------+
| Bits 0-2 | Precedence |
+----------+----------------------------------------------+
| Bit 3 | 0 = Normal Delay, 1 = Low Delay |
+----------+----------------------------------------------+
| Bit 4 | 0 = Normal Throughput, 1 = High Throughput |
+----------+----------------------------------------------+
| Bit 5 | 0 = Normal Reliability, 1 = High Reliability |
+----------+----------------------------------------------+
| Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost |
+----------+----------------------------------------------+
| Bits 7 | Reserved for Future Use (must be zero) |
+----------+----------------------------------------------+
Table 1: Semantics of the TOS Bits
表1:TOS位的语义
+-----+-----------------+
| 111 | Network Control |
+-----+-----------------+
| 110 | Internetwork |
+-----+-----------------+
| 101 | CRITIC/ECP |
+-----+-----------------+
| 100 | Flash Override |
+-----+-----------------+
| 011 | Flash |
+-----+-----------------+
| 010 | Immediate |
+-----+-----------------+
| 001 | Priority |
+-----+-----------------+
| 000 | Routine |
+-----+-----------------+
+-----+-----------------+
| 111 | Network Control |
+-----+-----------------+
| 110 | Internetwork |
+-----+-----------------+
| 101 | CRITIC/ECP |
+-----+-----------------+
| 100 | Flash Override |
+-----+-----------------+
| 011 | Flash |
+-----+-----------------+
| 010 | Immediate |
+-----+-----------------+
| 001 | Priority |
+-----+-----------------+
| 000 | Routine |
+-----+-----------------+
Table 2: Semantics of the Possible Precedence Field Values
表2：可能优先字段值的语义
The Type of Service field can be used to affect the way in which the packet is treated by the systems of a network that process it. Section 4.2.1 ("Precedence-Ordered Queue Service") and Section 4.2.2
服务类型字段可用于影响处理数据包的网络系统处理数据包的方式。第4.2.1节（“优先顺序队列服务”）和第4.2.2节
("Weak Type of Service") of this document describe the security implications of the Type of Service field in the forwarding of packets.
本文档的（“弱服务类型”）描述了数据包转发中服务类型字段的安全含义。
The Differentiated Services Architecture is intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop [RFC2475]. RFC 2474 [RFC2474] redefined the IP "Type of Service" octet, introducing a Differentiated Services Field (DS Field). Figure 3 shows the format of the field.
区分服务体系结构旨在实现互联网中的可扩展服务区分，而无需每个流状态和每个跃点的信令[RFC2475]。RFC 2474[RFC2474]重新定义了IP“服务类型”八位组，引入了区分服务字段（DS字段）。图3显示了字段的格式。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
Figure 3: Revised Structure of the Type of Service Field (RFC 2474)
图3：服务领域类型的修订结构（RFC 2474）
The DSCP ("Differentiated Services CodePoint") is used to select the treatment the packet is to receive within the Differentiated Services Domain. The CU ("Currently Unused") field was, at the time the specification was issued, reserved for future use. The DSCP field is used to select a PHB (Per-Hop Behavior), by matching against the entire 6-bit field.
DSCP（“区分服务代码点”）用于选择分组在区分服务域内要接收的处理。在发布规范时，CU（“当前未使用”）字段保留供将来使用。DSCP字段用于通过匹配整个6位字段来选择PHB（每跳行为）。
Considering that the DSCP field determines how a packet is treated within a Differentiated Services (DS) domain, an attacker could send packets with a forged DSCP field to perform a theft of service or even a Denial-of-Service (DoS) attack. In particular, an attacker could forge packets with a codepoint of the type '11x000' which, according to Section 4.2.2.2 of RFC 2474 [RFC2474], would give the packets preferential forwarding treatment when compared with the PHB selected by the codepoint '000000'. If strict priority queuing were utilized, a continuous stream of such packets could cause a DoS to other flows that have a DSCP of lower relative order.
考虑到DSCP字段确定如何在区分服务（DS）域中处理数据包，攻击者可以发送带有伪造DSCP字段的数据包，以执行服务盗窃甚至拒绝服务（DoS）攻击。特别是，攻击者可以伪造具有“11x000”类型代码点的数据包，根据RFC 2474[RFC2474]第4.2.2.2节，与代码点“000000”选择的PHB相比，该代码点将给予数据包优先转发处理。如果使用严格的优先级队列，则此类数据包的连续流可能会导致对具有较低相对顺序的DSCP的其他流的拒绝服务。
As the DS field is incompatible with the original Type of Service field, both DS domains and networks using the original Type of Service field should protect themselves by remarking the corresponding field where appropriate, probably deploying remarking boundary nodes. Nevertheless, care must be taken so that packets received with an unrecognized DSCP do not cause the handling system to malfunction.
由于DS字段与原始类型的服务字段不兼容，因此使用原始类型的服务字段的DS域和网络都应通过在适当的情况下标记相应字段来保护自己，可能会部署标记边界节点。然而，必须小心，以确保使用未识别的DSCP接收的数据包不会导致处理系统故障。
RFC 3168 [RFC3168] specifies a mechanism for routers to signal congestion to hosts exchanging IP packets, by marking the offending packets rather than discarding them. RFC 3168 defines the ECN field, which utilizes the CU field defined in RFC 2474 [RFC2474]. Figure 4 shows the current syntax of the IP Type of Service field, with the DSCP field used for Differentiated Services and the ECN field.
RFC 3168[RFC3168]指定了一种路由器向交换IP数据包的主机发送拥塞信号的机制，方法是标记有问题的数据包，而不是丢弃它们。RFC 3168定义了ECN字段，该字段使用RFC 2474[RFC2474]中定义的CU字段。图4显示了IP类型服务字段的当前语法，其中DSCP字段用于区分服务，ECN字段用于区分服务。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4: The Differentiated Services and ECN Fields in IP
图4:IP中的区分服务和ECN字段
As such, the ECN field defines four codepoints:
因此，ECN字段定义了四个代码点：
+-----------+-----------+
| ECN field | Codepoint |
+-----------+-----------+
| 00 | Not-ECT |
+-----------+-----------+
| 01 | ECT(1) |
+-----------+-----------+
| 10 | ECT(0) |
+-----------+-----------+
| 11 | CE |
+-----------+-----------+
+-----------+-----------+
| ECN field | Codepoint |
+-----------+-----------+
| 00 | Not-ECT |
+-----------+-----------+
| 01 | ECT(1) |
+-----------+-----------+
| 10 | ECT(0) |
+-----------+-----------+
| 11 | CE |
+-----------+-----------+
Table 3: ECN Codepoints
表3:ECN代码点
ECN is an end-to-end transport protocol mechanism based on notifications by routers through which a packet flow passes. To allow this interaction to happen on the fast path of routers, the ECN field is located at a fixed location in the IP header. However, its use must be negotiated at the transport layer, and the accumulated congestion notifications must be communicated back to the sending node using transport protocol means. Thus, ECN support must be specified per transport protocol.
ECN是一种端到端传输协议机制，基于路由器的通知，包流通过路由器。为了允许这种交互在路由器的快速路径上发生，ECN字段位于IP报头中的固定位置。然而，必须在传输层协商其使用，并且必须使用传输协议手段将累积的拥塞通知传回发送节点。因此，必须根据传输协议指定ECN支持。
[RFC6040] specifies how the Explicit Congestion Notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel.
[RFC6040]指定在进入和退出IP隧道中的任何IP时，应如何构造IP头的显式拥塞通知（ECN）字段。
The security implications of ECN are discussed in detail in a number of Sections of RFC 3168. Of the possible threats discussed in the ECN specification, we believe that one that can be easily exploited is that of a host falsely indicating ECN-Capability.
RFC3168的许多章节详细讨论了ECN的安全含义。在ECN规范中讨论的可能威胁中，我们认为一个容易被利用的威胁是主机错误地指示ECN能力。
An attacker could set the ECT codepoint in the packets it sends, to signal the network that the endpoints of the transport protocol are ECN-capable. Consequently, when experiencing moderate congestion, routers using active queue management based on Random Early Detection (RED) would mark the packets (with the CE codepoint) rather than discard them. In this same scenario, packets of competing flows that do not have the ECT codepoint set would be dropped. Therefore, an attacker would get better network service than the competing flows.
攻击者可以在其发送的数据包中设置ECT代码点，以向网络发出传输协议端点支持ECN的信号。因此，当遇到中度拥塞时，使用基于随机早期检测（RED）的主动队列管理的路由器将标记数据包（使用CE码点），而不是丢弃它们。在同一场景中，不具有ECT码点集的竞争流的数据包将被丢弃。因此，攻击者将获得比竞争流更好的网络服务。
However, if this moderate congestion turned into heavy congestion, routers should switch to drop packets, regardless of whether or not the packets have the ECT codepoint set.
然而，如果这种中度拥塞转变为重度拥塞，路由器应该切换到丢弃数据包，不管数据包是否设置了ECT码点。
A number of other threats could arise if an attacker was a man in the middle (i.e., was in the middle of the path the packets travel to get to the destination host). For a detailed discussion of those cases, we urge the reader to consult Section 16 of RFC 3168.
如果攻击者是中间人（即，在分组到达目的地主机的路径的中间），可能会出现许多其他威胁。对于这些案例的详细讨论，我们敦促读者参考RFC 3168第16节。
There is also ongoing work in the research community and the IETF to define alternate semantics for the CU/ECN field of IP TOS octet (see [RFC5559], [RFC5670], and [RFC5696]). The application of these methods must be confined to tightly administered domains, and on exit from such domains, all packets need to be (re-)marked with ECN semantics.
研究社区和IETF也正在进行工作，为IP TOS八位字节的CU/ECN字段定义替代语义（参见[RFC5559]、[RFC5670]和[RFC5696]）。这些方法的应用必须局限于严格管理的域，并且在从这些域退出时，所有数据包都需要用ECN语义（重新）标记。
The Total Length field is the length of the datagram, measured in bytes, including both the IP header and the IP payload. Being a 16-bit field, it allows for datagrams of up to 65535 bytes. RFC 791 [RFC0791] states that all hosts should be prepared to receive datagrams of up to 576 bytes (whether they arrive as a whole, or in fragments). However, most modern implementations can reassemble datagrams of at least 9 Kbytes.
Total Length字段是数据报的长度，以字节为单位，包括IP报头和IP有效负载。作为一个16位字段，它允许最多65535字节的数据报。RFC 791[RFC0791]指出，所有主机都应准备好接收多达576字节的数据报（无论它们是作为一个整体到达，还是以片段到达）。然而，大多数现代实现可以重新组装至少9KB的数据报。
Usually, a host will not send to a remote peer an IP datagram larger than 576 bytes, unless it is explicitly signaled that the remote peer is able to receive such "large" datagrams (for example, by means of TCP's Maximum Segment Size (MSS) option). However, systems should assume that they may receive datagrams larger than 576 bytes, regardless of whether or not they signal their remote peers to do so. In fact, it is common for Network File System (NFS) [RFC3530]
通常，主机不会向远程对等方发送大于576字节的IP数据报，除非明确表示远程对等方能够接收此类“大”数据报（例如，通过TCP的最大段大小（MSS）选项）。然而，系统应该假设它们可以接收大于576字节的数据报，而不管它们是否向远程对等方发出这样做的信号。事实上，网络文件系统（NFS）[RFC3530]
implementations to send datagrams larger than 576 bytes, even without explicit signaling that the destination system can receive such "large" datagram.
发送大于576字节的数据报的实现，即使没有明确的信号表明目标系统可以接收如此“大”的数据报。
Additionally, see the discussion in Section 4.1 ("Fragment Reassembly") regarding the possible packet sizes resulting from fragment reassembly.
此外，参见第4.1节（“片段重组”）中关于片段重组可能产生的数据包大小的讨论。
Implementations should be aware that the IP module could be handed a packet larger than the value actually contained in the Total Length field. Such a difference usually has to do with legitimate padding bytes at the link-layer protocol, but it could also be the result of malicious activity by an attacker. Furthermore, even when the maximum length of an IP datagram is 65535 bytes, if the link-layer technology in use allows for payloads larger than 65535 bytes, an attacker could forge such a large link-layer packet, meaning it for the IP module. If the IP module of the receiving system were not prepared to handle such an oversized link-layer payload, an unexpected failure might occur. Therefore, the memory buffer used by the IP module to store the link-layer payload should be allocated according to the payload size reported by the link layer, rather than according to the Total Length field of the IP packet it contains.
实现应该知道，IP模块可能会收到一个大于总长度字段中实际包含的值的数据包。这种差异通常与链路层协议中的合法填充字节有关，但也可能是攻击者恶意活动的结果。此外，即使当IP数据报的最大长度为65535字节时，如果使用的链路层技术允许有效负载大于65535字节，攻击者也可能伪造如此大的链路层数据包，这意味着它适用于IP模块。如果接收系统的IP模块未准备好处理这种超大链路层有效负载，则可能会发生意外故障。因此，IP模块用于存储链路层有效载荷的存储器缓冲器应当根据链路层报告的有效载荷大小而不是根据其包含的IP分组的总长度字段来分配。
The IP module could also be handed a packet that is smaller than the actual IP packet size claimed by the Total Length field. This could be used, for example, to produce an information leakage. Therefore, the following check should be performed:
IP模块还可以被传递一个小于总长度字段声明的实际IP数据包大小的数据包。例如，这可用于产生信息泄漏。因此，应进行以下检查：
LinkLayer.PayloadSize >= Total Length
LinkLayer.PayloadSize>=总长度
If this check fails, the IP packet should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop). As the previous expression implies, the number of bytes passed by the link layer to the IP module should contain at least as many bytes as claimed by the Total Length field of the IP header.
如果此检查失败，则应丢弃IP数据包，并记录此事件（例如，计数器可以增加以反映数据包丢弃）。正如前面的表达式所暗示的，链路层传递到IP模块的字节数应至少包含IP头的Total Length字段所声明的字节数。
[US-CERT2002] is an example of the exploitation of a forged IP Total Length field to produce an information leakage attack.
[US-CERT2002]是利用伪造IP全长字段进行信息泄漏攻击的一个示例。
The Identification field is set by the sending host to aid in the reassembly of fragmented datagrams. At any time, it needs to be unique for each set of {Source Address, Destination Address, Protocol}.
标识字段由发送主机设置，以帮助重新组装碎片数据报。在任何时候，它都需要对每一组{源地址、目标地址、协议}都是唯一的。
In many systems, the value used for this field is determined at the IP layer, on a protocol-independent basis. Many of those systems also simply increment the IP Identification field for each packet they send.
在许多系统中，用于此字段的值是在IP层根据独立于协议的基础上确定的。许多这样的系统也只是简单地增加他们发送的每个数据包的IP标识字段。
This implementation strategy is inappropriate for a number of reasons. Firstly, if the Identification field is set on a protocol-independent basis, it will wrap more often than necessary, and thus the implementation will be more prone to the problems discussed in [Kent1987] and [RFC4963]. Secondly, this implementation strategy opens the door to an information leakage that can be exploited in a number of ways.
由于许多原因，这种实施战略是不合适的。首先，如果标识字段是在独立于协议的基础上设置的，那么它将比必要时更频繁地包装，因此实现将更容易出现[Kent1987]和[RFC4963]中讨论的问题。第二，这种实施策略为信息泄漏打开了大门，这种信息泄漏可以通过多种方式加以利用。
[Sanfilippo1998a] describes how the Identification field can be leveraged to determine the packet rate at which a given system is transmitting information. Later, [Sanfilippo1998b] described how a system with such an implementation can be used to perform a stealth port scan to a third (victim) host. [Sanfilippo1999] explained how to exploit this implementation strategy to uncover the rules of a number of firewalls. [Bellovin2002] explains how the IP Identification field can be exploited to count the number of systems behind a NAT. [Fyodor2004] is an entire paper on most (if not all) of the ways to exploit the information provided by the Identification field of the IP header.
[Sanfilippo1998a]描述了如何利用标识字段来确定给定系统传输信息的分组速率。稍后，[Sanfilippo1998b]描述了如何使用具有这种实现的系统对第三台（受害者）主机执行隐形端口扫描。[Sanfilippo1999]解释了如何利用此实施策略来揭示许多防火墙的规则。[Bellovin2002]解释了如何利用IP标识字段统计NAT背后的系统数量。[Fyodor2004]是一篇关于利用IP报头标识字段提供的信息的大多数（如果不是全部）方法的完整论文。
Section 4.1 contains a discussion of the security implications of the IP fragment reassembly mechanism, which is the primary "consumer" of this field.
第4.1节讨论了IP片段重组机制的安全含义，该机制是该领域的主要“使用者”。
As the IP Identification field is only used for the reassembly of datagrams, some operating systems (such as Linux) decided to set this field to 0 in all packets that have the DF bit set. This would, in principle, avoid any type of information leakage. However, it was detected that some non-RFC-compliant middle-boxes fragmented packets even if they had the DF bit set. In such a scenario, all datagrams originally sent with the DF bit set would all result in fragments with an Identification field of 0, which would lead to problems ("collision" of the Identification number) in the reassembly process.
由于IP标识字段仅用于重新组装数据报，一些操作系统（如Linux）决定在所有设置了DF位的数据包中将该字段设置为0。原则上，这将避免任何类型的信息泄漏。然而，检测到一些不符合RFC的中间盒即使设置了DF位也会将数据包分割。在这种情况下，最初使用DF位集发送的所有数据报都将导致标识字段为0的片段，这将导致重新组装过程中出现问题（“标识号冲突”）。
Linux (and Solaris) later set the IP Identification field on a per-IP-address basis. This avoids some of the security implications of the IP Identification field, but not all. For example, systems behind a load balancer can still be counted.
Linux（和Solaris）随后会根据每个IP地址设置IP标识字段。这避免了IP标识字段的一些安全影响，但不是全部。例如，负载平衡器后面的系统仍然可以计数。
Contrary to common wisdom, the IP Identification field does not need to be system-wide unique for each packet, but has to be unique for each {Source Address, Destination Address, Protocol} tuple.
与常识相反，IP标识字段不需要在系统范围内对每个数据包都是唯一的，但对每个{源地址、目标地址、协议}元组都必须是唯一的。
For instance, the TCP specification defines a generic send() function that takes the IP ID as one of its arguments.
例如，TCP规范定义了一个通用的send（）函数，该函数将IP ID作为其参数之一。
We provide an analysis of the possible security improvements that could be implemented, based on whether the protocol using the services of IP is connection-oriented or connection-less.
基于使用IP服务的协议是面向连接的还是少连接的，我们分析了可能实现的安全改进。
To avoid the security implications of the information leakage described above, a pseudo-random number generator (PRNG) could be used to set the IP Identification field on a {Source Address, Destination Address} basis (for each connection-oriented transport protocol).
为了避免上述信息泄漏的安全影响，可以使用伪随机数生成器（PRNG）在{源地址、目标地址}的基础上（针对每个面向连接的传输协议）设置IP标识字段。
[RFC4086] provides advice on the generation of pseudo-random numbers.
[RFC4086]提供关于生成伪随机数的建议。
[Klein2007] is a security advisory that describes a weakness in the pseudo-random number generator (PRNG) employed for the generation of the IP Identification by a number of operating systems.
[Kle2007]是一个安全咨询，描述了用于由多个操作系统生成IP标识的伪随机数生成器（PRNG）中的一个弱点。
While in theory a pseudo-random number generator could lead to scenarios in which a given Identification number is used more than once in the same time span for datagrams that end up getting fragmented (with the corresponding potential reassembly problems), in practice, this is unlikely to cause trouble.
虽然从理论上讲，伪随机数生成器可能会导致在同一时间段内对数据报多次使用给定的标识号，最终导致数据报碎片化（存在相应的潜在重组问题），但在实践中，这不太可能造成问题。
By default, most implementations of connection-oriented protocols, such as TCP, implement some mechanism for avoiding fragmentation (such as the Path-MTU Discovery mechanism described in [RFC1191]). Thus, fragmentation will only take place if a non-RFC-compliant middle-box that still fragments packets even when the DF bit is set is placed somewhere along the path that the packets travel to get to the destination host. Once the sending system is signaled by the middle-box (by means of an ICMP "fragmentation needed and DF bit set" error message) that it should reduce the size of the packets it sends, fragmentation would be avoided. Also, for reassembly problems to arise, the same Identification value would need to be reused very frequently, and either strong packet reordering or packet loss would need to take place.
默认情况下，大多数面向连接的协议（如TCP）实现了一些避免碎片的机制（如[RFC1191]中描述的路径MTU发现机制）。因此，只有当一个不符合RFC的中间盒（即使设置了DF位，该中间盒仍然对数据包进行分段）被放置在数据包到达目的主机的路径上的某个位置时，才会发生分段。一旦中间框（通过ICMP“需要碎片和DF位设置”错误消息）通知发送系统应减小其发送的数据包的大小，就可以避免碎片。此外，对于出现的重新组装问题，需要非常频繁地重用相同的标识值，并且需要发生强数据包重新排序或数据包丢失。
Nevertheless, regardless of what policy is used for selecting the Identification field, with the current link speeds fragmentation is already bad enough (i.e., very likely to lead to fragment reassembly errors) to rely on it. A mechanism for avoiding fragmentation (such as [RFC1191] or [RFC4821] should be implemented, instead.
然而，无论使用何种策略来选择标识字段，在当前链路速度下，碎片已经足够糟糕（即，极有可能导致碎片重新组装错误）以至于依赖它。相反，应该实现避免碎片的机制（例如[RFC1191]或[RFC4821]）。
Connectionless transport protocols often have these characteristics:
无连接传输协议通常具有以下特征：
o lack of flow-control mechanisms,
o 缺乏流量控制机制，
o lack of packet sequencing mechanisms, and/or,
o 缺少数据包排序机制，和/或，
o lack of reliability mechanisms (such as "timeout and retransmit").
o 缺乏可靠性机制（如“超时和重新传输”）。
This basically means that the scenarios and/or applications for which connection-less transport protocols are used assume that:
这基本上意味着使用无连接传输协议的场景和/或应用程序假定：
o Applications will be used in environments in which packet reordering is very unlikely (such as Local Area Networks), as the transport protocol itself does not provide data sequencing.
o 由于传输协议本身不提供数据排序，因此应用程序将用于不太可能重新排序数据包的环境（如局域网）。
o The data transfer rates will be low enough that flow control will be unnecessary.
o 数据传输速率将足够低，因此不需要流量控制。
o Packet loss is can be tolerated and/or is unlikely.
o 数据包丢失是可以容忍和/或不太可能的。
With these assumptions in mind, the Identification field could still be set according to a pseudo-random number generator (PRNG).
考虑到这些假设，仍然可以根据伪随机数生成器（PRNG）设置识别字段。
[RFC4086] provides advice on the generation of pseudo-random numbers.
[RFC4086]提供关于生成伪随机数的建议。
In the event a given Identification number was reused while the first instance of the same number is still on the network, the first IP datagram would be reassembled before the fragments of the second IP datagram get to their destination.
如果在相同号码的第一个实例仍在网络上时重用了给定的标识号，则在第二个IP数据报的片段到达目的地之前，将重新组装第一个IP数据报。
In the event this was not the case, the reassembly of fragments would result in a corrupt datagram. While some existing work [Silbersack2005] assumes that this error would be caught by some upper-layer error detection code, the error detection code in question (such as UDP's checksum) might not be able to reliably detect data corruption arising from the replacement of a complete data block (as is the case in corruption arising from collision of IP Identification numbers).
如果情况并非如此，则片段的重新组装将导致损坏的数据报。虽然一些现有工作[Silbersack2005]假设此错误会被某个上层错误检测代码捕获，但所讨论的错误检测代码（如UDP的校验和）可能无法可靠地检测因替换完整数据块而导致的数据损坏（与IP标识号冲突导致的腐败一样）。
In the case of UDP, unfortunately some systems have been known to not enable the UDP checksum by default. For most applications, packets containing errors should be dropped by the transport layer and not delivered to the application. A small number of applications may benefit from disabling the checksum; for example, streaming media where it is desired to avoid dropping a complete sample for a single-bit error, and UDP tunneling applications where the payload (i.e., the inner packet) is protected by its own transport checksum or other error detection mechanism.
在UDP的情况下，不幸的是，一些系统在默认情况下不启用UDP校验和。对于大多数应用程序，包含错误的数据包应该由传输层丢弃，而不是交付给应用程序。少数应用程序可能受益于禁用校验和；例如，流媒体（其中希望避免丢失单个位错误的完整样本）和UDP隧道应用（其中有效负载（即内部数据包）由其自身的传输校验和或其他错误检测机制保护）。
In general, if IP Identification number collisions become an issue for the application using the connection-less protocol, the application designers should consider using a different transport protocol (which hopefully avoids fragmentation).
一般来说，如果IP标识号冲突成为应用无连接协议的应用程序的问题，应用程序设计者应该考虑使用不同的传输协议（希望避免碎片化）。
It must be noted that an attacker could intentionally exploit collisions of IP Identification numbers to perform a DoS attack, by sending forged fragments that would cause the reassembly process to result in a corrupt datagram that either would be dropped by the transport protocol or would incorrectly be handed to the corresponding application. This issue is discussed in detail in Section 4.1 ("Fragment Reassembly").
必须注意的是，攻击者可以通过发送伪造的片段，故意利用IP标识号的冲突来执行DoS攻击，这将导致重新组装过程产生损坏的数据报，该数据报可能会被传输协议丢弃，也可能会被错误地交给相应的应用程序。第4.1节（“碎片重组”）详细讨论了该问题。
The IP header contains 3 control bits, two of which are currently used for the fragmentation and reassembly function.
IP报头包含3个控制位，其中两个当前用于分段和重新组装功能。
As described by RFC 791, their meaning is:
如RFC 791所述，其含义为：
o Bit 0: reserved, must be zero (i.e., reserved for future standardization)
o 位0：保留，必须为零（即保留用于未来标准化）
o Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment
o 第1位：（DF）0=可能碎片，1=不碎片
o Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments
o 第2位：（MF）0=最后一个片段，1=更多片段
The DF bit is usually set to implement the Path-MTU Discovery (PMTUD) mechanism described in [RFC1191]. However, it can also be exploited by an attacker to evade Network Intrusion Detection Systems. An attacker could send a packet with the DF bit set to a system monitored by a NIDS, and depending on the Path-MTU to the intended recipient, the packet might be dropped by some intervening router (because of being too big to be forwarded without fragmentation), without the NIDS being aware of it.
DF位通常设置为实现[RFC1191]中描述的路径MTU发现（PMTUD）机制。但是，攻击者也可以利用它来规避网络入侵检测系统。攻击者可以将DF位设置为的数据包发送到NIDS监控的系统，并且根据到目标接收者的MTU路径，该数据包可能会被某些介入路由器丢弃（因为太大，无法在没有碎片的情况下转发），而NIDS不知道它。
+---+
| H |
+---+ Victim host
|
Router A | MTU=1500
|
+---+ +---+ +---+
| R |-----| R |---------| R |
+---+ +---+ +---+
| MTU=17914 Router B
+---+ |
| S |-----+
+---+ |
|
NIDS Sensor |
|
_ ___/---\______ Attacker
/ \_/ \_ +---+
/ Internet |---------| H |
\_ __/ +---+
\__ __ ___/ <------
\___/ \__/ 17914-byte packet
DF bit set
+---+
| H |
+---+ Victim host
|
Router A | MTU=1500
|
+---+ +---+ +---+
| R |-----| R |---------| R |
+---+ +---+ +---+
| MTU=17914 Router B
+---+ |
| S |-----+
+---+ |
|
NIDS Sensor |
|
_ ___/---\______ Attacker
/ \_/ \_ +---+
/ Internet |---------| H |
\_ __/ +---+
\__ __ ___/ <------
\___/ \__/ 17914-byte packet
DF bit set
Figure 5: NIDS Evasion by Means of the Internet Protocol DF Bit
图5：通过互联网协议DF Bit的NIDS规避
In Figure 3, an attacker sends a 17914-byte datagram meant for the victim host in the same figure. The attacker's packet probably contains an overlapping IP fragment or an overlapping TCP segment, aiming at "confusing" the NIDS, as described in [Ptacek1998]. The packet is screened by the NIDS sensor at the network perimeter, which probably reassembles IP fragments and TCP segments for the purpose of assessing the data transferred to and from the monitored systems. However, as the attacker's packet should transit a link with an MTU smaller than 17914 bytes (1500 bytes in this example), the router that encounters that this packet cannot be forwarded without fragmentation (Router B) discards the packet, and sends an ICMP "fragmentation needed and DF bit set" error message to the source host. In this scenario, the NIDS may remain unaware that the screened packet never reached the intended destination, and thus get an incorrect picture of the data being transferred to the monitored systems.
在图3中，攻击者发送一个17914字节的数据报，用于同一图中的受害主机。攻击者的数据包可能包含重叠的IP片段或重叠的TCP段，旨在“混淆”NID，如[Ptacek1998]所述。网络周边的NIDS传感器会对数据包进行筛选，可能会重新组装IP片段和TCP段，以评估传输到监控系统和从监控系统传输的数据。但是，由于攻击者的数据包应传输MTU小于17914字节（本例中为1500字节）的链路，因此遇到此数据包无法在没有碎片的情况下转发的路由器（路由器B）丢弃该数据包，并向源主机发送ICMP“需要碎片和DF位设置”错误消息。在这种情况下，nid可能仍然不知道经过筛选的分组从未到达预期目的地，从而获得被传输到被监视系统的数据的错误图片。
[Shankar2003] introduces a technique named "Active Mapping" that prevents evasion of a NIDS by acquiring sufficient knowledge about the network being monitored, to assess which packets will arrive at the intended recipient, and how they will be interpreted by it.
[Shankar2003]介绍了一种名为“主动映射”的技术，该技术通过获取有关被监控网络的充分信息，评估哪些数据包将到达预期的接收者，以及如何解释这些数据包，来防止NIDS的规避。
Some firewalls are known to drop packets that have both the MF (More Fragments) and the DF (Don't Fragment) bits set. While in principle such a packet might seem nonsensical, there are a number of reasons for which non-malicious packets with these two bits set can be found in a network. First, they may exist as the result of some middle-box processing a packet that was too large to be forwarded without fragmentation. Instead of simply dropping the corresponding packet and sending an ICMP error message to the source host, some middle-boxes fragment the packet (copying the DF bit to each fragment), and also send an ICMP error message to the originating system. Second, some systems (notably Linux) set both the MF and the DF bits to implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should be taken into account when configuring firewalls and/or tuning NIDSs.
已知有些防火墙会丢弃设置了MF（更多片段）和DF（不片段）位的数据包。虽然在原则上，这样的数据包可能看起来毫无意义，但在网络中可以找到设置了这两个位的非恶意数据包的原因有很多。首先，它们可能是一些中间盒处理数据包的结果，该数据包太大，无法在没有碎片的情况下转发。与简单地丢弃相应的数据包并向源主机发送ICMP错误消息不同，一些中间框对数据包进行分段（将DF位复制到每个分段），并向原始系统发送ICMP错误消息。其次，一些系统（特别是Linux）同时设置MF和DF位来实现UDP的路径MTU发现（PMTUD）。在配置防火墙和/或调优NIDS时，应考虑这些场景。
Section 4.1 contains a discussion of the security implications of the IP fragment reassembly mechanism.
第4.1节讨论了IP片段重组机制的安全含义。
The Fragment Offset is used for the fragmentation and reassembly of IP datagrams. It indicates where in the original datagram payload the payload of the fragment belongs, and is measured in units of eight bytes. As a consequence, all fragments (except the last one), have to be aligned on an 8-byte boundary. Therefore, if a packet has the MF flag set, the following check should be enforced:
片段偏移量用于IP数据报的分段和重新组装。它指示片段的有效载荷在原始数据报有效载荷中所属的位置，并以八字节为单位进行度量。因此，所有片段（最后一个片段除外）都必须在8字节边界上对齐。因此，如果数据包设置了MF标志，则应执行以下检查：
(Total Length - IHL * 4) % 8 == 0
(Total Length - IHL * 4) % 8 == 0
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并应记录该事件（例如，计数器可递增以反映数据包丢弃）。
Given that Fragment Offset is a 13-bit field, it can hold a value of up to 8191, which would correspond to an offset 65528 bytes within the original (non-fragmented) datagram. As such, it is possible for a fragment to implicitly claim to belong to a datagram larger than 65535 bytes (the maximum size for a legitimate IP datagram). Even when the fragmentation mechanism would seem to allow fragments that could reassemble into such large datagrams, the intent of the specification is to allow for the transmission of datagrams of up to 65535 bytes. Therefore, if a given fragment would reassemble into a datagram of more than 65535 bytes, the resulting datagram should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop). To detect such a case, the following check should be enforced on all packets for which the Fragment Offset contains a non-zero value:
假设片段偏移量是一个13位字段，它最多可以保存8191的值，这将对应于原始（非片段化）数据报中的偏移量65528字节。因此，片段可能隐式声明属于大于65535字节（合法IP数据报的最大大小）的数据报。即使碎片机制似乎允许碎片重新组合成如此大的数据报，本规范的目的是允许传输高达65535字节的数据报。因此，如果给定的片段将重新组合成超过65535字节的数据报，则应丢弃生成的数据报，并且应记录该事件（例如，可增加计数器以反映数据包丢弃）。要检测这种情况，应对片段偏移量包含非零值的所有数据包执行以下检查：
Fragment Offset * 8 + (Total Length - IHL * 4) + IHL_FF * 4 <= 65535
Fragment Offset * 8 + (Total Length - IHL * 4) + IHL_FF * 4 <= 65535
where IHL_FF is the IHL field of the first fragment (the one with a Fragment Offset of 0).
其中，IHL_FF是第一个片段（片段偏移量为0的片段）的IHL字段。
If a fragment does not pass this check, it should be dropped.
如果某个片段未通过此检查，则应将其删除。
If IHL_FF is not yet available because the first fragment has not yet arrived, for a preliminary, less rigid test, IHL_FF == IHL should be assumed, and the test is simplified to:
如果由于第一个碎片尚未到达而导致IHL_FF不可用，则对于初步的、不太严格的测试，应假设IHL_FF==IHL，并将测试简化为：
Fragment Offset * 8 + Total Length <= 65535
Fragment Offset * 8 + Total Length <= 65535
Once the first fragment is received, the full sanity check described earlier should be applied, if that fragment contains "don't copy" options.
一旦收到第一个片段，如果该片段包含“不复制”选项，则应应用前面描述的完整完整性检查。
In the worst-case scenario, an attacker could craft IP fragments such that the reassembled datagram reassembled into a datagram of 131043 bytes.
在最坏的情况下，攻击者可以手工制作IP片段，使重新组装的数据报重新组装成131043字节的数据报。
Such a datagram would result when the first fragment has a Fragment Offset of 0 and a Total Length of 65532, and the second (and last) fragment has a Fragment Offset of 8189 (65512 bytes), and a Total Length of 65535. Assuming an IHL of 5 (i.e., a header length of 20 bytes), the reassembled datagram would be 65532 + (65535 - 20) = 131047 bytes.
当第一个片段的片段偏移量为0，总长度为65532，第二个（也是最后一个）片段的片段偏移量为8189（65512字节），总长度为65535时，就会产生这样的数据报。假设IHL为5（即，报头长度为20字节），重新组装的数据报将为65532+（65535-20）=131047字节。
Additionally, the IP module should implement all the necessary measures to be able to handle such illegitimate reassembled datagrams, so as to avoid them from overflowing the buffer(s) used for the reassembly function.
此外，IP模块应实施所有必要措施，以便能够处理此类非法重新组装的数据报，从而避免它们溢出用于重新组装功能的缓冲区。
[CERT1996c] and [Kenney1996] describe the exploitation of this issue to perform a DoS attack.
[CERT1996c]和[Kenney1996]描述了利用此问题执行DoS攻击的情况。
Section 4.1 contains a discussion of the security implications of the IP fragment reassembly mechanism.
第4.1节讨论了IP片段重组机制的安全含义。
The Time to Live (TTL) field has two functions: to bound the lifetime of the upper-layer packets (e.g., TCP segments) and to prevent packets from looping indefinitely in the network.
生存时间（TTL）字段有两个功能：限制上层数据包（例如TCP段）的生存期，以及防止数据包在网络中无限循环。
Originally, this field was meant to indicate the maximum time a datagram was allowed to remain in the Internet system, in units of seconds. As every Internet module that processes a datagram must
最初，此字段表示允许数据报在Internet系统中保留的最长时间，单位为秒。每个处理数据报的互联网模块都必须
decrement the TTL by at least one, the original definition of the TTL field became obsolete, and in practice it is interpreted as a hop count (see Section 5.3.1 of [RFC1812]).
将TTL减量至少一，TTL字段的原始定义就过时了，实际上它被解释为跳数（参见[RFC1812]第5.3.1节）。
Most systems allow the administrator to configure the TTL to be used for the packets they originate, with the default value usually being a power of 2, or 255 (e.g., see [Arkin2000]). The recommended value for the TTL field, as specified by the IANA is 64 [IANA_IP_PARAM]. This value reflects the assumed "diameter" of the Internet, plus a margin to accommodate its growth.
大多数系统允许管理员将TTL配置为用于它们发起的数据包，默认值通常为2或255的幂（例如，请参见[Arkon2000]）。IANA指定的TTL字段的建议值为64[IANA_IP_PARAM]。这个值反映了假定的“直径”的互联网，加上保证金，以适应其增长。
The TTL field has a number of properties that are interesting from a security point of view. Given that the default value used for the TTL is usually either a power of two, or 255, chances are that unless the originating system has been explicitly tuned to use a non-default value, if a packet arrives with a TTL of 60, the packet was originally sent with a TTL of 64. In the same way, if a packet is received with a TTL of 120, chances are that the original packet had a TTL of 128.
TTL字段有许多从安全角度来看很有趣的属性。假设TTL使用的默认值通常是2的幂或255，除非始发系统已明确调整为使用非默认值，否则如果数据包以60的TTL到达，则数据包最初以64的TTL发送。同样，如果接收到的数据包的TTL为120，则原始数据包的TTL可能为128。
This discussion assumes there was no protocol scrubber, transparent proxy, or some other middle-box that overwrites the TTL field in a non-standard way, between the originating system and the point of the network in which the packet was received.
本讨论假设在发起系统和接收数据包的网络点之间没有协议洗涤器、透明代理或其他以非标准方式覆盖TTL字段的中间框。
Determining the TTL with which a packet was originally sent by the source system can help to obtain valuable information. Among other things, it may help in:
确定源系统最初发送数据包的TTL有助于获得有价值的信息。除其他事项外，它可能有助于：
o Fingerprinting the originating operating system.
o 对原始操作系统进行指纹识别。
o Fingerprinting the originating physical device.
o 对原始物理设备进行指纹识别。
o Mapping the network topology.
o 映射网络拓扑。
o Locating the source host in the network topology.
o 在网络拓扑中查找源主机。
o Evading Network Intrusion Detection Systems.
o 规避网络入侵检测系统。
However, it can also be used to perform important functions such as:
但是，它也可用于执行重要功能，例如：
o Improving the security of applications that make use of the Internet Protocol (IP).
o 提高使用Internet协议（IP）的应用程序的安全性。
o Limiting spread of packets.
o 限制数据包的传播。
Different operating systems use a different default TTL for the packets they send. Thus, asserting the TTL with which a packet was originally sent will help heuristics to reduce the number of possible operating systems in use by the source host. It should be noted that since most systems use only a handful of different default values, the granularity of OS fingerprinting that this technique provides is negligible. Additionally, these defaults may be configurable (system-wide or per protocol), and managed systems may employ such opportunities for operational purposes and to defeat the capability of fingerprinting heuristics.
不同的操作系统对发送的数据包使用不同的默认TTL。因此，断言最初发送数据包的TTL将有助于启发式减少源主机可能使用的操作系统的数量。应该注意的是，由于大多数系统只使用少数几个不同的默认值，因此该技术提供的操作系统指纹的粒度可以忽略不计。此外，这些默认值可能是可配置的（系统范围或每个协议），并且受管系统可能会利用这些机会用于操作目的，并挫败指纹提取启发式的能力。
3.8.2. Fingerprinting the Physical Device from which the Packets Originate
3.8.2. 对数据包来源的物理设备进行指纹识别
When several systems are behind a middle-box such as a NAT or a load balancer, the TTL may help to count the number of systems behind the middle-box. If each of the systems behind the middle-box uses a different default TTL value for the packets it sends, or each system is located at different distances in the network topology, an attacker could stimulate responses from the devices being fingerprinted, and responses that arrive with different TTL values could be assumed to come from a different devices.
当多个系统位于中间箱（如NAT或负载平衡器）后面时，TTL可能有助于统计中间箱后面的系统数量。如果中间框后面的每个系统对其发送的数据包使用不同的默认TTL值，或者每个系统位于网络拓扑中的不同距离，则攻击者可能会激发被提取指纹的设备的响应，可以假设，以不同TTL值到达的响应来自不同的设备。
Of course, there are many other (and much more precise) techniques to fingerprint physical devices. One weakness of this method is that, while many systems differ in the default TTL value that they use, there are also many implementations which use the same default TTL value. Additionally, packets sent by a given device may take different routes (e.g., due to load sharing or route changes), and thus a given packet may incorrectly be presumed to come from a different device, when in fact it just traveled a different route.
当然，还有许多其他（更精确的）技术可以对物理设备进行指纹识别。这种方法的一个缺点是，虽然许多系统使用的默认TTL值不同，但也有许多实现使用相同的默认TTL值。此外，由给定设备发送的分组可能采用不同的路由（例如，由于负载共享或路由改变），因此，当给定分组实际上只是通过不同的路由时，可能会错误地假定其来自不同的设备。
However, these defaults may be configurable (system-wide or per protocol) and managed systems may employ such opportunities for operational purposes and to defeat the capability of fingerprinting heuristics.
然而，这些默认值可能是可配置的（系统范围或每个协议），并且受管系统可能会将这些机会用于操作目的，并挫败指纹提取启发式的能力。
An originating host may set the TTL field of the packets it sends to progressively increasing values in order to elicit an ICMP error message from the routers that decrement the TTL of each packet to zero, and thereby determine the IP addresses of the routers on the path to the packet's destination. This procedure has been traditionally employed by the traceroute tool.
始发主机可以将其发送的分组的TTL字段设置为逐渐增大的值，以便从路由器获取将每个分组的TTL减小为零的ICMP错误消息，从而确定到分组目的地的路径上的路由器的IP地址。该程序传统上由traceroute工具使用。
The TTL field may also be used to locate the source system in the network topology [Northcutt2000].
TTL字段也可用于在网络拓扑中定位源系统[Northcutt2000]。
+---+ +---+ +---+ +---+ +---+
| A |-----| R |------| R |----| R |-----| R |
+---+ +---+ +---+ +---+ +---+
/ | / \
/ | / \
/ | / +---+
/ +---+ +---+ +---+ | E |
/ | R |----| R |------| R |-- +---+
/ +---+ +---+\ +---+ \
/ / / \ \ \
/ ---- / +---+ \ \+---+
/ / / | F | \ | D |
+---+ +---+ +---+ \ +---|
| R |----------| R |-- \
+---+ +---+ \ \
| \ / \ +---+| +---+
| \ / ----| R |------| R |
| \ / +---+ +---+
+---+ \ +---+ +---+
| B | \| R |----| C |
+---+ +---+ +---+
+---+ +---+ +---+ +---+ +---+
| A |-----| R |------| R |----| R |-----| R |
+---+ +---+ +---+ +---+ +---+
/ | / \
/ | / \
/ | / +---+
/ +---+ +---+ +---+ | E |
/ | R |----| R |------| R |-- +---+
/ +---+ +---+\ +---+ \
/ / / \ \ \
/ ---- / +---+ \ \+---+
/ / / | F | \ | D |
+---+ +---+ +---+ \ +---|
| R |----------| R |-- \
+---+ +---+ \ \
| \ / \ +---+| +---+
| \ / ----| R |------| R |
| \ / +---+ +---+
+---+ \ +---+ +---+
| B | \| R |----| C |
+---+ +---+ +---+
Figure 6: Tracking a Host by Means of the TTL Field
图6：通过TTL字段跟踪主机
Consider network topology of Figure 6. Assuming that an attacker ("F" in the figure) is performing some type of attack that requires forging the Source Address (such as for a TCP-based DoS reflection attack), and some of the involved hosts are willing to cooperate to locate the attacking system.
考虑图6的网络拓扑结构。假设攻击者（图中的“F”）正在执行某种类型的攻击，需要伪造源地址（例如基于TCP的DoS反射攻击），并且一些相关主机愿意合作定位攻击系统。
Assuming that:
假设：
o All the packets A gets have a TTL of 61.
o A得到的所有数据包的TTL都是61。
o All the packets B gets have a TTL of 61.
o B得到的所有数据包的TTL都是61。
o All the packets C gets have a TTL of 61.
o C得到的所有数据包的TTL都是61。
o All the packets D gets have a TTL of 62.
o D得到的所有数据包的TTL都是62。
Based on this information, and assuming that the system's default value was not overridden, it would be fair to assume that the original TTL of the packets was 64. With this information, the number of hops between the attacker and each of the aforementioned hosts can be calculated.
基于此信息，并假设系统的默认值未被覆盖，则公平地假设数据包的原始TTL为64。利用此信息，可以计算攻击者与上述每个主机之间的跳数。
The attacker is:
攻击者是：
o Four hops away from A.
o 离A四跳。
o Four hops away from B.
o 离B四跳。
o Four hops away from C.
o 离C四跳。
o Four hops away from D.
o 离D四跳。
In the network setup of Figure 3, the only system that satisfies all these conditions is the one marked as the "F".
在图3的网络设置中，唯一满足所有这些条件的系统是标记为“F”的系统。
The scenario described above is for illustration purposes only. In practice, there are a number of factors that may prevent this technique from being successfully applied:
上述场景仅用于说明目的。实际上，有许多因素可能会妨碍该技术的成功应用：
o Unless there is a "large" number of cooperating systems, and the attacker is assumed to be no more than a few hops away from these systems, the number of "candidate" hosts will usually be too large for the information to be useful.
o 除非存在“大量”的协作系统，并且假定攻击者与这些系统之间的距离不超过几跳，否则“候选”主机的数量通常太大，无法提供有用的信息。
o The attacker may be using a non-default TTL value, or, what is worse, using a pseudo-random value for the TTL of the packets it sends.
o 攻击者可能使用非默认TTL值，或者更糟糕的是，对其发送的数据包的TTL使用伪随机值。
o The packets sent by the attacker may take different routes, as a result of a change in network topology, load sharing, etc., and thus may lead to an incorrect analysis.
o 由于网络拓扑、负载共享等的变化，攻击者发送的数据包可能会采用不同的路由，因此可能导致错误的分析。
The TTL field can be used to evade Network Intrusion Detection Systems. Depending on the position of a sensor relative to the destination host of the examined packet, the NIDS may get a different picture from that of the intended destination system. As an example, a sensor may process a packet that will expire before getting to the destination host. A general countermeasure for this type of attack is to normalize the traffic that gets to an organizational network. Examples of such traffic normalization can be found in [Paxson2001]. OpenBSD Packet Filter is an example of a packet filter that includes TTL-normalization functionality [OpenBSD-PF]
TTL字段可用于规避网络入侵检测系统。根据传感器相对于被检查分组的目的地主机的位置，nid可以获得与预期目的地系统不同的图片。例如，传感器可以处理在到达目的地主机之前将过期的数据包。针对此类攻击的一般对策是使到达组织网络的流量正常化。此类流量标准化的示例可在[Paxson2001]中找到。OpenBSD数据包过滤器是包含TTL规范化功能的数据包过滤器的示例[OpenBSD PF]
3.8.6. Improving the Security of Applications That Make Use of the Internet Protocol (IP)
3.8.6. 提高使用Internet协议（IP）的应用程序的安全性
In some scenarios, the TTL field can be also used to improve the security of an application, by restricting the hosts that can communicate with the given application [RFC5082]. For example, there are applications for which the communicating systems are typically in the same network segment (i.e., there are no intervening routers). Such an application is the BGP (Border Gateway Protocol) utilized by two peer routers (usually on a shared link medium).
在某些情况下，TTL字段还可以通过限制可以与给定应用程序通信的主机来提高应用程序的安全性[RFC5082]。例如，存在通信系统通常位于同一网段中的应用（即，没有中间路由器）。这样的应用是由两个对等路由器（通常在共享链路介质上）使用的BGP（边界网关协议）。
If both systems use a TTL of 255 for all the packets they send to each other, then a check could be enforced to require all packets meant for the application in question to have a TTL of 255.
如果两个系统对彼此发送的所有数据包都使用255的TTL，则可以强制执行一项检查，要求所有用于相关应用程序的数据包的TTL为255。
As all packets sent by systems that are not in the same network segment will have a TTL smaller than 255, those packets will not pass the check enforced by these two cooperating peers. This check reduces the set of systems that may perform attacks against the protected application (BGP in this case), thus mitigating the attack vectors described in [NISCC2004] and [Watson2004].
由于不在同一网段中的系统发送的所有数据包的TTL都将小于255，因此这些数据包将无法通过这两个合作对等方强制执行的检查。该检查减少了可能对受保护应用程序（本例中为BGP）执行攻击的系统集，从而缓解了[NISCC2004]和[Watson2004]中描述的攻击向量。
This same check is enforced for related ICMP error messages, with the intent of mitigating the attack vectors described in [NISCC2005] and [RFC5927].
对相关ICMP错误消息执行相同的检查，目的是缓解[NISCC2005]和[RFC5927]中描述的攻击向量。
The TTL field can be used in a similar way in scenarios in which the cooperating systems are not in the same network segment (i.e., multi-hop peering). In that case, the following check could be enforced:
TTL字段可以在协作系统不在同一网段（即多跳对等）的场景中以类似的方式使用。在这种情况下，可以执行以下检查：
TTL >= 255 - DeltaHops
TTL >= 255 - DeltaHops
This means that the set of hosts from which packets will be accepted for the protected application will be reduced to those that are no more than DeltaHops away. While for obvious reasons the level of protection will be smaller than in the case of directly connected peers, the use of the TTL field for protecting multi-hop peering still reduces the set of hosts that could potentially perform a number of attacks against the protected application.
这意味着，受保护应用程序将从中接受数据包的主机集将减少到距离DeltaHops不远的主机集。虽然由于明显的原因，保护级别将小于直接连接对等的情况，但使用TTL字段保护多跳对等仍会减少可能对受保护应用程序执行若干攻击的主机集。
This use of the TTL field has been officially documented by the IETF under the name "Generalized TTL Security Mechanism" (GTSM) in [RFC5082].
TTL字段的使用已由IETF在[RFC5082]中以“通用TTL安全机制”（GTSM）的名义正式记录。
Some protocol scrubbers enforce a minimum value for the TTL field of the packets they forward. It must be understood that depending on the minimum TTL being enforced, and depending on the particular network setup, the protocol scrubber may actually help attackers to fool the GTSM, by "raising" the TTL of the attacking packets.
一些协议洗涤器对它们转发的数据包的TTL字段强制执行最小值。必须理解的是，根据实施的最小TTL以及特定的网络设置，协议洗涤器实际上可能通过“提高”攻击数据包的TTL来帮助攻击者愚弄GTSM。
The originating host sets the TTL field to a small value (frequently 1, for link-scope services) in order to artificially limit the (topological) distance the packet is allowed to travel. This is suggested in Section 4.2.2.9 of RFC 1812 [RFC1812]. Further discussion of this technique can be found in RFC 1112 [RFC1112].
发起主机将TTL字段设置为一个较小的值（对于链路作用域服务，通常为1），以人为地限制数据包允许移动的（拓扑）距离。RFC 1812[RFC1812]第4.2.2.9节中建议了这一点。RFC 1112[RFC1112]中对该技术进行了进一步讨论。
The Protocol field indicates the protocol encapsulated in the Internet datagram. The Protocol field may not only contain a value corresponding to a protocol implemented by the system processing the packet, but also a value corresponding to a protocol not implemented, or even a value not yet assigned by the IANA [IANA_PROT_NUM].
协议字段表示封装在Internet数据报中的协议。协议字段不仅可以包含与处理分组的系统实现的协议相对应的值，还可以包含与未实现的协议相对应的值，或者甚至包括尚未由IANA分配的值[IANA_PROT_NUM]。
While in theory there should not be security implications from the use of any value in the protocol field, there have been security issues in the past with systems that had problems when handling packets with some specific protocol numbers [Cisco2003] [CERT2003].
虽然理论上，在协议字段中使用任何值都不会产生安全影响，但过去系统在处理具有特定协议编号的数据包时存在安全问题[Cisco2003][CERT2003]。
A host (i.e., end-system) that receives an IP packet encapsulating a Protocol it does not support should drop the corresponding packet, log the event, and possibly send an ICMP Protocol Unreachable (type 3, code 2) error message.
接收到封装其不支持的协议的IP数据包的主机（即终端系统）应丢弃相应的数据包，记录事件，并可能发送ICMP协议无法访问（类型3，代码2）错误消息。
The Header Checksum field is an error-detection mechanism meant to detect errors in the IP header. While in principle there should not be security implications arising from this field, it should be noted that due to non-RFC-compliant implementations, the Header Checksum might be exploited to detect firewalls and/or evade NIDSs.
标头校验和字段是一种错误检测机制，用于检测IP标头中的错误。虽然原则上此字段不应产生安全影响，但应注意，由于不符合RFC的实现，可能会利用报头校验和来检测防火墙和/或规避NIDS。
[Ed3f2002] describes the exploitation of the TCP checksum for performing such actions. As there are Internet routers known to not check the IP Header Checksum, and there might also be middle-boxes (NATs, firewalls, etc.) not checking the IP checksum allegedly due to performance reasons, similar malicious activity to the one described in [Ed3f2002] might be performed with the IP checksum.
[Ed3f2002]描述了利用TCP校验和执行此类操作的情况。由于已知存在不检查IP报头校验和的Internet路由器，并且可能存在据称由于性能原因而不检查IP校验和的中间框（NAT、防火墙等），因此可能会使用IP校验和执行与[Ed3f2002]中所述类似的恶意活动。
The Source Address of an IP datagram identifies the node from which the packet originated.
IP数据报的源地址标识数据包起源的节点。
Strictly speaking, the Source Address of an IP datagram identifies the interface of the sending system from which the packet was sent, (rather than the originating "system"), as in the Internet Architecture there's no concept of "node address".
严格地说，IP数据报的源地址标识发送数据包的发送系统的接口（而不是原始“系统”），因为在互联网体系结构中没有“节点地址”的概念。
Unfortunately, it is trivial to forge the Source Address of an Internet datagram because of the apparent lack of consistent "egress filtering" near the edge of the network. This has been exploited in the past for performing a variety of DoS attacks [NISCC2004] [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a] and for impersonating other systems in scenarios in which authentication was based on the Source Address of the sending system [daemon91996].
不幸的是，伪造互联网数据报的源地址是微不足道的，因为在网络边缘附近明显缺乏一致的“出口过滤”。过去曾利用此漏洞执行各种DoS攻击[NISCC2004][RFC4987][CERT1996a][CERT1996b][CERT1998a]，并在验证基于发送系统的源地址[daemon91996]的情况下模拟其他系统。
The extent to which these attacks can be successfully performed in the Internet can be reduced through deployment of ingress/egress filtering in the Internet routers. [NISCC2006] is a detailed guide on ingress and egress filtering. [RFC2827] and [RFC3704] discuss ingress filtering. [GIAC2000] discusses egress filtering. [SpooferProject] measures the Internet's susceptibility to forged Source Address IP packets.
通过在互联网路由器中部署入口/出口过滤，可以降低这些攻击在互联网中成功执行的程度。[NISCC2006]是关于入口和出口过滤的详细指南。[RFC2827]和[RFC3704]讨论入口过滤。[GIAC2000]讨论了出口过滤。[SpooferProject]测量Internet对伪造源地址IP数据包的易感性。
Even when the obvious field on which to perform checks for ingress/egress filtering is the Source Address and Destination Address fields of the IP header, there are other occurrences of IP addresses on which the same type of checks should be performed. One example is the IP addresses contained in the payload of ICMP error messages, as discussed in [RFC5927] and [Gont2006].
即使要对其执行入口/出口过滤检查的明显字段是IP报头的源地址和目标地址字段，也会出现其他IP地址，应对其执行相同类型的检查。一个例子是ICMP错误消息有效负载中包含的IP地址，如[RFC5927]和[Gont2006]中所述。
There are a number of sanity checks that should be performed on the Source Address of an IP datagram. Details can be found in Section 4.3 ("Addressing").
应该对IP数据报的源地址执行许多健全性检查。详情见第4.3节（“地址”）。
Additionally, there exist freely available tools that allow administrators to monitor which IP addresses are used with which MAC addresses [LBNL2006]. This functionality is also included in many NIDSs.
此外，还有一些免费提供的工具，允许管理员监视哪些IP地址与哪些MAC地址一起使用[LBNL2006]。此功能也包含在许多NIDS中。
It is also very important to understand that authentication should never rely solely on the Source Address used by the communicating systems.
了解身份验证决不能仅仅依赖于通信系统使用的源地址，这一点也非常重要。
The Destination Address of an IP datagram identifies the destination host to which the packet is meant to be delivered.
IP数据报的目标地址标识数据包要传送到的目标主机。
Strictly speaking, the Destination Address of an IP datagram identifies the interface of the destination network interface, rather than the destination "system", as in the Internet Architecture there's no concept of "node address".
严格来说，IP数据报的目标地址标识的是目标网络接口的接口，而不是目标“系统”，因为在Internet体系结构中没有“节点地址”的概念。
There are a number of sanity checks that should be performed on the Destination Address of an IP datagram. Details can be found in Section 4.3 ("Addressing").
应该对IP数据报的目标地址执行许多健全性检查。详情见第4.3节（“地址”）。
According to RFC 791, IP options must be implemented by all IP modules, both in hosts and gateways (i.e., end-systems and intermediate-systems). This means that the general rules for assembling, parsing, and processing of IP options must be implemented. RFC 791 defines a set of options that "must be understood", but this set has been updated by RFC 1122 [RFC1122], RFC 1812 [RFC1812], and other documents. Section 3.13.2 of this document describes for each option type the current understanding of the implementation requirements. IP systems are required to ignore options they do not implement.
根据RFC 791，IP选项必须由主机和网关（即终端系统和中间系统）中的所有IP模块实现。这意味着必须实现组装、解析和处理IP选项的一般规则。RFC 791定义了一组“必须理解”的选项，但这组选项已由RFC 1122[RFC1122]、RFC 1812[RFC1812]和其他文档更新。本文件第3.13.2节描述了每种选项类型对实施要求的当前理解。IP系统必须忽略它们未实现的选项。
It should be noted that while a number of IP options have been specified, they are generally only used for troubleshooting purposes (except for the Router Alert option and the different Security options).
应该注意的是，虽然指定了许多IP选项，但它们通常仅用于故障排除目的（路由器警报选项和不同的安全选项除外）。
There are two cases for the format of an option:
选项的格式有两种情况：
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：选项类型字节、选项长度字节和实际选项数据字节。
In Case 2, the option-length byte counts the option-type byte and the option-length byte, as well as the actual option-data bytes.
在案例2中，选项长度字节统计选项类型字节和选项长度字节，以及实际选项数据字节。
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位：选项编号。
This format allows for the creation of new options for the extension of the Internet Protocol (IP) and their transparent treatment on intermediate-systems that do not "understand" them, under direction of the first three functional parts.
该格式允许在前三个功能部分的指导下，为扩展互联网协议（IP）创建新选项，并对不“理解”它们的中间系统进行透明处理。
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=保留供将来使用。
Finally, the option number identifies the syntax of the rest of the option.
最后，选项编号标识选项其余部分的语法。
[IANA_IP_PARAM] contains the list of the currently assigned IP option numbers. It should be noted that IP systems are required to ignore those options they do not implement.
[IANA_IP_PARAM]包含当前分配的IP选项编号列表。需要注意的是，IP系统必须忽略它们没有实现的选项。
The following subsections discuss security issues that apply to all IP options. The proposed checks should be performed in addition to any option-specific checks proposed in the next sections.
以下小节讨论适用于所有IP选项的安全问题。除了在下一节中建议的任何选项特定检查外，还应执行建议的检查。
Router manufacturers tend to do IP option processing on the main processor, rather than on line cards. Unless special care is taken, this represents DoS risk, as there is potential for overwhelming the router with option processing.
路由器制造商倾向于在主处理器上进行IP选项处理，而不是在线卡上。除非特别小心，否则这代表DoS风险，因为有可能用选项处理压倒路由器。
To reduce the impact of these packets on the system performance, a few countermeasures could be implemented:
为了减少这些数据包对系统性能的影响，可以实施一些对策：
o Rate-limit the number of packets with IP options that are processed by the system.
o 速率限制系统处理的具有IP选项的数据包数。
o Enforce a limit on the maximum number of options to be accepted on a given Internet datagram.
o 对给定Internet数据报上要接受的选项的最大数量实施限制。
The first check avoids a flow of packets with IP options to overwhelm the system in question. The second check avoids packets with many IP options to affect the performance of the system.
第一次检查避免了带有IP选项的数据包流，从而淹没了所讨论的系统。第二个检查可避免包含许多IP选项的数据包影响系统性能。
Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the IP options received in IP datagrams must be passed to the transport layer (or to ICMP processing when the datagram is an ICMP message). Therefore, care in option processing must be taken not only at the Internet layer but also in every protocol module that may end up processing the options included in an IP datagram.
RFC 1122[RFC1122]第3.2.1.8节规定，IP数据报中接收的所有IP选项必须传递给传输层（或当数据报是ICMP消息时，传递给ICMP处理）。因此，不仅在互联网层，而且在可能最终处理IP数据报中包含的选项的每个协议模块中，都必须注意选项处理。
There are a number of sanity checks that should be performed on IP options before further option processing is done. They help prevent a number of potential security problems, including buffer overflows. When these checks fail, the packet carrying the option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
在进行进一步的选项处理之前，应该对IP选项执行许多健全性检查。它们有助于防止一些潜在的安全问题，包括缓冲区溢出。当这些检查失败时，应丢弃携带该选项的数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem" message to the originating system when a packet is dropped because of an invalid value in a field, such as the cases discussed in the following subsections. Sending such a message might help in debugging some network problems. However, it would also alert attackers about the system that is dropping packets because of the invalid values in the protocol fields.
RFC 1122[RFC1122]建议在由于字段中的无效值而丢弃数据包时，向发起系统发送ICMP“参数问题”消息，如以下小节中讨论的情况。发送这样的消息可能有助于调试某些网络问题。但是，它也会提醒攻击者，由于协议字段中的无效值，系统正在丢弃数据包。
We advice that systems default to sending an ICMP "Parameter Problem" error message when a packet is dropped because of an invalid value in a protocol field (e.g., as a result of dropping a packet due to the sanity checks described in this section). However, we recommend that systems provide a system-wide toggle that allows an administrator to override the default behavior so that packets can be silently dropped when an invalid value in a protocol field is encountered.
我们建议，当由于协议字段中的无效值（例如，由于本节所述的健全性检查而丢弃数据包）而丢弃数据包时，系统默认发送ICMP“参数问题”错误消息。但是，我们建议系统提供一个系统范围的切换，允许管理员覆盖默认行为，以便在遇到协议字段中的无效值时可以无声地丢弃数据包。
Option length
选项长度
Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer must not crash as the result of an option length that is outside the possible range, and mentions that erroneous option lengths have been observed to put some IP implementations into infinite loops.
RFC 1122的第3.2.1.8节明确指出，IP层不得因超出可能范围的选项长度而崩溃，并提到已观察到错误的选项长度，从而将一些IP实现放入无限循环中。
For options that belong to the "Case 2" described in the previous section, the following check should be performed:
对于属于上一节所述“情况2”的选项，应执行以下检查：
option-length >= 2
选项长度>=2
The value "2" accounts for the option-type byte and the option-length byte.
值“2”表示选项类型字节和选项长度字节。
This check prevents, among other things, loops in option processing that may arise from incorrect option lengths.
除其他外，此检查可防止选项处理中因选项长度不正确而产生的循环。
Additionally, while the option-length byte of IP options of "Case 2" allows for an option length of up to 255 bytes, there is a limit on legitimate option length imposed by the space available for options in the IP header.
此外，虽然“案例2”的IP选项的选项长度字节允许最多255字节的选项长度，但IP报头中的选项可用空间对合法选项长度施加了限制。
For all options of "Case 2", the following check should be enforced:
对于“案例2”的所有选项，应执行以下检查：
option-offset + option-length <= IHL * 4
option-offset + option-length <= IHL * 4
Where option-offset is the offset of the first byte of the option within the IP header, with the first byte of the IP header being assigned an offset of 0.
其中，option offset是IP报头中选项的第一个字节的偏移量，IP报头的第一个字节的偏移量为0。
This check assures that the option does not claim to extend beyond the IP header. If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
此检查确保选项不会声明扩展到IP标头之外。如果数据包未通过该检查，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
The aforementioned check is meant to detect forged option-length values that might make an option overlap with the IP payload. This would be particularly dangerous for those IP options that request the processing systems to write information into the option-data area (such as the Record Route option), as it would allow the generation of overflows.
上述检查旨在检测伪造的选项长度值，该值可能使选项与IP有效负载重叠。这对于那些请求处理系统将信息写入选项数据区域（例如记录路由选项）的IP选项来说尤其危险，因为这将允许产生溢出。
Data types
数据类型
Many IP options use pointer and length fields. Care must be taken as to the data type used for these fields in the implementation. For example, if an 8-bit signed data type were used to hold an 8-bit pointer, then, pointer values larger than 128 might mistakenly be interpreted as negative numbers, and thus might lead to unpredictable results.
许多IP选项使用指针和长度字段。在实现中，必须注意用于这些字段的数据类型。例如，如果使用8位有符号数据类型来保存8位指针，则大于128的指针值可能会被错误地解释为负数，从而可能导致不可预测的结果。
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. Octets in the IP header following the "End of Option List" are to be regarded as padding (they should set to 0 by the originator and must to be ignored by receiving nodes).
在选项结束与Internet协议标头结束不一致的情况下，此选项用于指示“选项结束”。IP报头中“选项列表结束”后的八位字节将被视为填充（发起者应将其设置为0，接收节点必须忽略）。
However, an originating node could alternatively fill the remaining space in the Internet header with No Operation options (see Section 3.13.2.2). The End of Option List option allows slightly more efficient parsing on receiving nodes and should be preferred by packet originators. All IP systems are required to understand both encodings.
但是，发起节点也可以在没有操作选项的情况下填充Internet报头中的剩余空间（参见第3.13.2.2节）。选项列表的末尾选项允许在接收节点上进行稍微更有效的解析，并且应该是数据包发起者的首选。所有IP系统都需要理解这两种编码。
The No Operation option is basically meant to allow the sending system to align subsequent options in, for example, 32-bit boundaries, but it can also be used at the end of the options (see Section 3.13.2.1).
无操作选项基本上旨在允许发送系统在例如32位边界中对齐后续选项，但也可在选项末尾使用（见第3.13.2.1节）。
With a single exception (see Section 3.13.2.13), this option is the only IP option defined so far that can occur in multiple instances in a single IP packet.
除了一个例外（见第3.13.2.13节），该选项是迄今为止定义的唯一一个在单个IP数据包的多个实例中出现的IP选项。
This option does not have security implications.
此选项不涉及安全问题。
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 ISP (Internet Service Provider) peering agreements require support for this option in the routers within the peer of the ISP.
LSSR选项有助于调试某些网络问题。某些ISP（Internet服务提供商）对等协议要求在ISP的对等路由器中支持此选项。
The LSRR option has well-known security implications. Among other things, the option can be used to:
LSRR选项具有众所周知的安全含义。除其他事项外，该选项可用于：
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 the 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选项）限制了放大系数。
While the LSSR option may be of help in debugging some network problems, its security implications outweigh any legitimate use.
虽然LSSR选项可能有助于调试某些网络问题，但它的安全影响超过了任何合法使用。
All systems should, by default, drop IP packets that contain an LSRR option, and should log this event (e.g., a counter could be incremented to reflect the packet drop). However, they should provide a system-wide toggle to enable support for this option for those scenarios in which this option is required. Such system-wide toggle should default to "off" (or "disable").
默认情况下，所有系统都应该丢弃包含LSRR选项的IP数据包，并且应该记录此事件（例如，可以增加计数器以反映数据包丢弃）。但是，它们应该提供系统范围的切换，以便在需要此选项的场景中支持此选项。此类系统范围切换应默认为“关闭”（或“禁用”）。
[OpenBSD1998] is a security advisory about an improper implementation of such a system-wide toggle in 4.4BSD kernels.
[OpenBSD1998]是关于在4.4BSD内核中不当实现此类系统范围切换的安全建议。
Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to act as an intermediate hop in a source route, forwarding a source-routed datagram to the next specified hop. We strongly discourage host software from forwarding source-routed datagrams.
RFC 1122[RFC1122]第3.3.5节规定，主机可以充当源路由中的中间跳，将源路由数据报转发到下一个指定跳。我们强烈反对主机软件转发源路由数据报。
If processing of source-routed datagrams is explicitly enabled in a system, the following sanity checks should be performed.
如果在系统中明确启用了源路由数据报的处理，则应执行以下健全性检查。
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选项组合的数据包，并记录此事件（例如，可增加计数器以反映数据包丢弃）。
As all other IP options of "Case 2", the LSSR contains a Length field that indicates the length of the option. Given the format of the option, the Length field should be checked to have a minimum value of three and be 3 (3 + n*4):
与“案例2”的所有其他IP选项一样，LSSR包含一个指示选项长度的长度字段。根据选项的格式，应检查长度字段的最小值为3且为3（3+n*4）：
LSRR.Length % 4 == 3 && LSRR.Length != 0
LSRR.Length % 4 == 3 && LSRR.Length != 0
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
The Pointer is relative to this option. Thus, the minimum legal value is 4. Therefore, the following check should be performed.
指针是相对于此选项的。因此，最低法定值为4。因此，应执行以下检查。
LSRR.Pointer >= 4
LSRR.指针>=4
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Additionally, the Pointer field should be a multiple of 4. Consequently, the following check should be performed:
如果数据包未通过该检查，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。此外，指针字段应为4的倍数。因此，应进行以下检查：
LSRR.Pointer % 4 == 0
LSRR.指针%4==0
If a packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果数据包未通过此检查，则应丢弃该数据包，并且应记录此事件（例如，可增加计数器以反映数据包丢弃）。
When a system receives an IP packet with the LSRR option passing the above checks, it should check whether or not the source route is empty. The option is empty if:
当系统接收到一个带有LSRR选项且通过上述检查的IP数据包时，它应该检查源路由是否为空。如果出现以下情况，则该选项为空：
LSRR.Pointer > LSRR.Length
LSRR.Pointer>LSRR.Length
In that case, routing should be based on the Destination Address field, and no further processing should be done on the LSRR option.
在这种情况下，路由应该基于Destination Address字段，并且不应该对LSRR选项进行进一步的处理。
[Microsoft1999] is a security advisory about a vulnerability arising from improper validation of the LSRR.Pointer field.
[Microsoft1999]是一个关于因LSRR.Pointer字段的不正确验证而产生的漏洞的安全建议。
If the address in the Destination Address field has been reached, and the option is not empty, the next address in the source route replaces the address in the Destination Address field, and the IP address of the interface that will be used to forward this datagram is recorded in its place in the LSRR.Data field. Then, the LSRR.Pointer. is incremented by 4.
如果已到达目标地址字段中的地址，且选项不为空，则源路由中的下一个地址将替换目标地址字段中的地址，并且将用于转发此数据报的接口的IP地址将记录在LSRR.数据字段中的相应位置。然后是LSRR.Pointer。增加4。
Note that the sanity checks for the LSRR.Length and the LSRR.Pointer fields described above ensure that if the option is not empty, there will be (4*n) octets in the option. That is, there will be at least one IP address to read and enough room to record the IP address of the interface that will be used to forward this datagram.
请注意，上述LSRR.Length和LSRR.Pointer字段的健全性检查可确保如果该选项不为空，则该选项中将有（4*n）个八位字节。也就是说，至少有一个IP地址需要读取，并且有足够的空间记录用于转发此数据报的接口的IP地址。
The LSRR must be copied on fragmentation. This means that if a packet that carries the LSRR is fragmented, each of the fragments will have to go through the list of systems specified in the LSRR option.
必须在碎片上复制LSRR。这意味着，如果携带LSRR的数据包被分段，则每个分段都必须经过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 SSSR option can be of help in debugging some network problems. Some ISP (Internet Service Provider) peering agreements require support for this option in the routers within the peer of the ISP.
SSSR选项可以帮助调试某些网络问题。某些ISP（Internet服务提供商）对等协议要求在ISP的对等路由器中支持此选项。
The SSRR option has the same security implications as the LSRR option. Please refer to Section 3.13.2.3 for a discussion of such security implications.
SSRR选项与LSRR选项具有相同的安全含义。有关此类安全影响的讨论，请参考第3.13.2.3节。
As with the LSRR, while the SSSR option may be of help in debugging some network problems, its security implications outweigh any legitimate use of it.
与LSRR一样，虽然SSSR选项可能有助于调试某些网络问题，但它的安全影响超过了它的任何合法使用。
All systems should, by default, drop IP packets that contain an SSRR option, and should log this event (e.g., a counter could be incremented to reflect the packet drop). However, they should provide a system-wide toggle to enable support for this option for those scenarios in which this option is required. Such system-wide toggle should default to "off" (or "disable").
默认情况下，所有系统都应丢弃包含SSRR选项的IP数据包，并应记录此事件（例如，可以增加计数器以反映数据包丢弃）。但是，它们应该提供系统范围的切换，以便在需要此选项的场景中支持此选项。此类系统范围切换应默认为“关闭”（或“禁用”）。
[OpenBSD1998] is a security advisory about an improper implementation of such a system-wide toggle in 4.4BSD kernels.
[OpenBSD1998]是关于在4.4BSD内核中不当实现此类系统范围切换的安全建议。
In the event processing of the SSRR option were explicitly enabled, the same sanity checks described for the LSRR option in Section 3.13.2.3 should be performed on the SSRR option. Namely, sanity checks should be performed on the option length (SSRR.Length) and the pointer field (SSRR.Pointer).
在明确启用SSRR选项的事件处理时，应对SSRR选项执行第3.13.2.3节中描述的LSRR选项的相同健全性检查。也就是说，应该对选项长度（SSRR.length）和指针字段（SSRR.pointer）执行健全性检查。
If the packet passes the aforementioned sanity checks, the receiving system should determine whether the Destination Address of the packet corresponds to one of its IP addresses. If does not, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果数据包通过上述健全性检查，则接收系统应确定数据包的目的地地址是否对应于其IP地址之一。如果没有，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
Contrary to the IP Loose Source and Record Route (LSRR) option, the SSRR option does not allow in the route other routers than those contained in the option. If the system implements the weak end-system model, it is allowed for the system to receive a packet destined to any of its IP addresses, on any of its interfaces. If the system implements the strong end-system model, a packet destined to it can be received only on the interface that corresponds to the IP address contained in the Destination Address field [RFC1122].
与IP松散源和记录路由（LSRR）选项相反，SSRR选项不允许在路由中使用选项中包含的路由器以外的其他路由器。如果系统实现弱端系统模型，则允许系统在其任何接口上接收目的地为其任何IP地址的数据包。如果系统实现强端系统模型，则只能在与目标地址字段[RFC1122]中包含的IP地址相对应的接口上接收目的地为其的数据包。
If the packet passes this check, the receiving system should determine whether the source route is empty or not. The option is empty if:
如果数据包通过此检查，接收系统应确定源路由是否为空。如果出现以下情况，则该选项为空：
SSRR.Pointer > SSRR.Length
SSRR.指针>SSRR.长度
In that case, if the address in the destination field has not been reached, the packet should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
在这种情况下，如果未到达目的地字段中的地址，则应丢弃数据包，并且应记录此事件（例如，可增加计数器以反映数据包丢弃）。
[Microsoft1999] is a security advisory about a vulnerability arising from improper validation of the SSRR.Pointer field.
[Microsoft1999]是一个关于因SSRR.Pointer字段验证不当而产生的漏洞的安全建议。
If the option is not empty, and the address in the Destination Address field has been reached, the next address in the source route replaces the address in the Destination Address field, and the IP address of the interface that will be used to forward this datagram is recorded in its place in the source route (SSRR.Data field). Then, the SSRR.Pointer is incremented by 4.
如果该选项不为空，且已到达目标地址字段中的地址，则源路由中的下一个地址将替换目标地址字段中的地址，并将用于转发此数据报的接口的IP地址记录在源路由（SSRR.Data字段）中的相应位置。然后，SSRR.指针增加4。
Note that the sanity checks for the SSRR.Length and the SSRR.Pointer fields described above ensure that if the option is not empty, there will be (4*n) octets in the option. That is, there will be at least one IP address to read, and enough room to record the IP address of the interface that will be used to forward this datagram.
请注意，上述SSRR.Length和SSRR.Pointer字段的健全性检查可确保如果该选项不为空，则该选项中将有（4*n）个八位字节。也就是说，至少有一个IP地址要读取，并且有足够的空间记录用于转发此数据报的接口的IP地址。
The SSRR option must be copied on fragmentation. This means that if a packet that carries the SSRR is fragmented, each of the fragments will have to go through the list of systems specified in the SSRR option.
必须在碎片上复制SSRR选项。这意味着，如果携带SSRR的数据包被分割，则每个片段都必须经过SSRR选项中指定的系统列表。
This option provides a means to record the route that a given packet follows.
此选项提供了记录给定数据包遵循的路由的方法。
The option begins with an 8-bit option code, which is equal to 7. The second byte is the option length, which includes the option-type byte, the option-length byte, the pointer byte, and the actual option-data. The third byte is a pointer into the route data, indicating the first byte of the area in which to store the next route data. The pointer is relative to the option start.
该选项以8位选项代码开始，该代码等于7。第二个字节是选项长度，包括选项类型字节、选项长度字节、指针字节和实际选项数据。第三个字节是指向路由数据的指针，指示存储下一个路由数据的区域的第一个字节。指针是相对于选项“开始”的。
RFC 791 states that this option should appear, at most, once in a given packet. Therefore, if a packet has 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规定该选项在给定数据包中最多出现一次。因此，如果一个数据包具有此选项的多个实例，则应丢弃该数据包，并且应记录此事件（例如，可增加计数器以反映数据包丢弃）。
The same sanity checks performed for the Length field and the Pointer field of the LSRR and the SSRR options should be performed on the Length field (RR.Length) and the Pointer field (RR.Pointer) of the RR option. As with the LSRR and SSRR options, if the packet does not pass these checks it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
对于LSRR和SSRR选项的长度字段和指针字段，应在RR选项的长度字段（RR.Length）和指针字段（RR.Pointer）上执行相同的健全性检查。与LSRR和SSRR选项一样，如果数据包未通过这些检查，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
When a system receives an IP packet with the Record Route option that passes the above checks, it should check whether there is space in the option to store route information. The option is full if:
当系统接收到带有记录路由选项的IP数据包并通过上述检查时，应检查该选项中是否有存储路由信息的空间。如果出现以下情况，则该选项已满：
RR.Pointer > RR.Length
RR.指针>RR.长度
If the option is full, the datagram should be forwarded without further processing of this option.
如果选项已满，则应转发数据报，而无需进一步处理此选项。
If the option is not full (i.e., RR.Pointer <= RR.Length), the IP address of the interface that will be used to forward this datagram should be recorded into the area pointed to by the RR.Pointer, and RR.Pointer should then incremented by 4.
如果该选项未满（即RR.Pointer<=RR.Length），则将用于转发此数据报的接口的IP地址应记录到RR.Pointer指向的区域中，然后RR.Pointer应递增4。
This option is not copied on fragmentation, and thus appears in the first fragment only. If a fragment other than the one with offset 0 contains the Record Route option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
此选项不会在片段中复制，因此仅出现在第一个片段中。如果偏移量为0的片段以外的片段包含记录路由选项，则应丢弃该片段，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
The Record Route option can be exploited to learn about the topology of a network. However, the limited space in the IP header limits the usefulness of this option for that purpose if the target network is several hops away.
可以利用记录路由选项了解网络拓扑。但是，如果目标网络距离目标网络几跳远，则IP报头中的有限空间限制了此选项的用途。
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 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. Therefore, it must be ignored by the processing systems.
但是，如RFC 1812[RFC1812]第4.2.2.1节所述，该选项已过时。因此，处理系统必须忽略它。
In the case of legacy systems still using this option, the length field of the option should be checked to be 4. If the option does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果遗留系统仍使用此选项，则该选项的长度字段应选中为4。如果该选项未通过此检查，则应丢弃该选项，并记录此事件（例如，可增加计数器以反映数据包丢弃）。
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 provides a means for recording the time at which each system processed this datagram. The timestamp option has a number of security implications. Among them are the following:
此选项提供了一种记录每个系统处理此数据报的时间的方法。时间戳选项有许多安全含义。其中包括：
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 它可以通过分析时钟偏移来对物理设备进行指纹识别。
Therefore, by default, the timestamp option should be ignored.
因此，默认情况下，应该忽略timestamp选项。
For those systems that have been explicitly configured to honor this option, the rest of this subsection describes some sanity checks that should be enforced on the option before further processing.
对于那些已明确配置为遵守此选项的系统，本小节的其余部分描述了在进一步处理之前应对该选项实施的一些健全性检查。
The option begins with an option-type byte, which must be equal to 68. The second byte is the option-length, which includes the option-type byte, the option-length byte, the pointer, and the overflow/flag byte. The minimum legal value for the option-length byte is 4, which corresponds to an Internet Timestamp option that is empty (no space to store timestamps). Therefore, upon receipt of a packet that contains an Internet Timestamp option, the following check should be performed:
该选项以选项类型字节开始，该字节必须等于68。第二个字节是选项长度，包括选项类型字节、选项长度字节、指针和溢出/标志字节。选项长度字节的最小法定值为4，对应于空的Internet时间戳选项（没有空间存储时间戳）。因此，在收到包含Internet时间戳选项的数据包时，应执行以下检查：
IT.Length >= 4
它的长度>=4
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
The Pointer is an index within this option, counting the option type octet as octet #1. It points to the first byte of the area in which the next timestamp data should be stored and thus, the minimum legal value is 5. Since the only change of the Pointer allowed by RFC 791 is incrementing it by 4 or 8, the following checks should be performed on the Internet Timestamp option, depending on the Flag value (see below).
指针是此选项内的索引，将选项类型octet计算为octet#1。它指向存储下一个时间戳数据的区域的第一个字节，因此，最小合法值为5。由于RFC 791允许的唯一指针更改是将其递增4或8，因此应根据标志值对Internet时间戳选项执行以下检查（见下文）。
If IT.Flag is equal to 0, the following check should be performed:
如果.Flag等于0，则应执行以下检查：
IT.Pointer %4 == 1 && IT.Pointer != 1
IT.Pointer %4 == 1 && IT.Pointer != 1
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
Otherwise, the following sanity check should be performed on the option:
否则，应对该选项执行以下健全性检查：
IT.Pointer % 8 == 5
指针%8==5
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
The flag field has three possible legal values:
标志字段有三个可能的合法值：
o 0: Record time stamps only, stored in consecutive 32-bit words.
o 0：仅记录时间戳，存储在连续的32位字中。
o 1: Record each timestamp preceded with the Internet address of the registering entity.
o 1：记录每个时间戳之前的注册实体的互联网地址。
o 3: The internet address fields of the option are pre-specified. An IP module only registers its timestamp if it matches its own address with the next specified Internet address.
o 3：选项的internet地址字段是预先指定的。IP模块仅在其自身地址与下一个指定的Internet地址匹配时才注册其时间戳。
Therefore the following check should be performed:
因此，应进行以下检查：
IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3
IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
The timestamp field is a right-justified 32-bit timestamp in milliseconds since UTC. If the time is not available in milliseconds, or cannot be provided with respect to UTC, then any time may be inserted as a timestamp, provided the high-order bit of the timestamp is set, to indicate this non-standard value.
timestamp字段是自UTC以来以毫秒为单位的右对齐32位时间戳。如果时间以毫秒为单位不可用，或者无法提供UTC相关时间，则可以将任何时间作为时间戳插入，前提是设置了时间戳的高阶位，以指示该非标准值。
According to RFC 791, the initial contents of the timestamp area must be initialized to zero, or Internet address/zero pairs. However, Internet systems should be able to handle non-zero values, possibly discarding the offending datagram.
根据RFC 791，时间戳区域的初始内容必须初始化为零，或互联网地址/零对。然而，互联网系统应该能够处理非零值，可能会丢弃有问题的数据报。
When an Internet system receives a packet with an Internet Timestamp option, it decides whether it should record its timestamp in the option. If it determines that it should, it should then determine whether the timestamp data area is full, by means of the following check:
当Internet系统接收到带有Internet时间戳选项的数据包时，它决定是否应在该选项中记录其时间戳。如果确定应该，则应通过以下检查确定时间戳数据区域是否已满：
IT.Pointer > IT.Length
IT.Pointer>IT.Length
If this condition is true, the timestamp data area is full. If not, there is room in the timestamp data area.
如果此条件为真，则时间戳数据区域已满。如果没有，则时间戳数据区域中有空间。
If the timestamp data area is full, the overflow byte should be incremented, and the packet should be forwarded without inserting the timestamp. If the overflow byte itself overflows, the packet should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果时间戳数据区域已满，则溢出字节应增加，并且应在不插入时间戳的情况下转发数据包。如果溢出字节本身溢出，则应丢弃数据包，并记录此事件（例如，可增加计数器以反映数据包丢弃）。
If the timestamp data area is not full, then processing continues as follows (note that the above checks on IT.Pointer ensure that there is room for another entry in the option):
如果时间戳数据区域未满，则按如下方式继续处理（请注意，上面对其进行了检查。指针确保选项中有空间容纳另一个条目）：
o If IT.Flag is 0, then the system's 32-bit timestamp is stored into the area pointed to by the pointer byte and the pointer byte is incremented by 4.
o 如果IT.Flag为0，则系统的32位时间戳存储在指针字节指向的区域中，指针字节递增4。
o If IT.Flag is 1, then the IP address of the system is stored into the area pointed to by the pointer byte, followed by the 32-bit system timestamp, and the pointer byte is incremented by 8.
o 如果IT.Flag为1，则系统的IP地址存储在指针字节指向的区域中，后跟32位系统时间戳，指针字节递增8。
o Otherwise (IT.Flag is 3), if the IP address in the first 4 bytes pointed to by IT.Pointer matches one of the IP addresses assigned to an interface of the system, then the system's timestamp is stored into the area pointed to by IT.Pointer + 4, and the pointer byte is incremented by 8.
o 否则（IT.Flag为3），如果指针指向的前4个字节中的IP地址与分配给系统接口的IP地址之一匹配，则系统的时间戳存储在指针指向的区域中。指针+4，指针字节递增8。
[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时间戳选项来实现。
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]). 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".
路由器警报选项在RFC 2113[RFC2113]中定义，RFC 5350[RFC5350]已对其更新进行了澄清。它包含一个由IANA注册表管理的16位值（请参见[RFC5350]）。路由器警报选项的语义是“如果路由器参与选项值所表示的功能，则应更仔细地检查此数据包”。
According to the syntax of the option as defined in RFC 2113, the following check should be enforced, if the router supports this option:
根据RFC 2113中定义的选项语法，如果路由器支持此选项，则应执行以下检查：
RA.Length == 4
RA.长度==4
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
A packet that contains a Router Alert option with an option value corresponding to functionality supported by an active module in the router will not go through the router's fast-path but will be processed in the slow path of the router, handing it over for closer inspection to the modules that has registered the matching option value. Therefore, this option may impact the performance of the systems that handle the packet carrying it.
包含路由器警报选项（选项值与路由器中活动模块支持的功能相对应）的数据包将不会通过路由器的快速路径，而是在路由器的慢速路径中处理，将其移交给已注册匹配选项值的模块进行更近距离的检查。因此，此选项可能会影响处理承载它的数据包的系统的性能。
[ROUTER-ALERT] analyzes the security implications of the Router Alert option, and identifies controlled environments in which the Router Alert option can be used safely.
[ROUTER-ALERT]分析路由器警报选项的安全含义，并确定路由器警报选项可安全使用的受控环境。
As explained in RFC 2113 [RFC2113], hosts should ignore this option.
如RFC 2113[RFC2113]中所述，主机应忽略此选项。
This option was defined in RFC 1063 [RFC1063] and originally provided a mechanism to discover the Path-MTU.
该选项在RFC1063[RFC1063]中定义，最初提供了一种发现路径MTU的机制。
This option is obsolete, and therefore any packet that is received containing this option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
此选项已过时，因此接收到的包含此选项的任何数据包都应丢弃，并且应记录此事件（例如，可以增加计数器以反映数据包丢弃）。
This option is defined in RFC 1063 [RFC1063], and originally provided a mechanism to discover the Path-MTU.
该选项在RFC1063[RFC1063]中定义，最初提供了一种发现路径MTU的机制。
This option is obsolete, and therefore any packet that is received containing this option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
此选项已过时，因此接收到的包含此选项的任何数据包都应丢弃，并且应记录此事件（例如，可以增加计数器以反映数据包丢弃）。
This option is defined in RFC 1393 [RFC1393], and originally provided a mechanism to trace the path to a host.
该选项在RFC 1393[RFC1393]中定义，最初提供了一种跟踪主机路径的机制。
The Traceroute option was specified as "experimental", and it was never deployed on the public Internet. Therefore, any packet that is received containing this option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
Traceroute选项被指定为“实验性”，它从未部署在公共Internet上。因此，应丢弃接收到的包含此选项的任何数据包，并记录此事件（例如，可增加计数器以反映数据包丢弃）。
This option is used by Multi-Level-Secure (MLS) end-systems and intermediate-systems in specific environments to [RFC1108]:
此选项由特定环境中的多级安全（MLS）终端系统和中间系统使用，用于[RFC1108]：
o Transmit from source to destination in a network standard representation the common security labels required by computer security models,
o 以网络标准表示形式将计算机安全模型所需的通用安全标签从源传输到目标，
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 确保数据报所采用的路由被保护到数据报上指示的所有保护机构所要求的级别。
It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 [RFC1038]).
RFC 1108[RFC1108]（淘汰RFC 1038[RFC1038]）规定了该标准。
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. The "Security Option" specified in RFC 791 is considered obsolete by Section 3.2.1.8 of RFC 1122, 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 1122第3.2.1.8节认为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节规定路由器“应实现此选项”。
The DoD Basic Security option is currently implemented in a number of operating systems (e.g., [IRIX2008], [SELinux2009], [Solaris2007], and [Cisco2008]), and deployed in a number of high-security networks.
国防部基本安全选项目前在许多操作系统中实施（例如，[IRIX2008]、[SELinux2009]、[Solaris2007]和[Cisco2008]），并部署在许多高安全网络中。
Systems that belong to networks in which this option is in use should process the DoD Basic Security option contained in each packet as specified in [RFC1108].
属于使用此选项的网络的系统应按照[RFC1108]中的规定处理每个数据包中包含的国防部基本安全选项。
RFC 1108 states that the option should appear at most once in a datagram. Therefore, if more than one DoD Basic Security option (BSO) appears in a given datagram, the corresponding datagram should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
RFC1108规定，该选项在数据报中最多出现一次。因此，如果给定数据报中出现一个以上的国防部基本安全选项（BSO），则应丢弃相应的数据报，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
RFC 1108 states that the option Length is variable, with a minimum option Length of 3 bytes. Therefore, the following check should be performed:
RFC 1108说明选项长度是可变的，最小选项长度为3字节。因此，应进行以下检查：
BSO.Length >= 3
BSO.长度>=3
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
Current deployments of the security options described in this section and the two subsequent sections have motivated the specification of a "Common Architecture Label IPv6 Security Option (CALIPSO)" for the IPv6 protocol [RFC5570].
本节和后续两节中描述的安全选项的当前部署推动了IPv6协议的“通用体系结构标签IPv6安全选项（CALIPSO）”规范[RFC5570]。
This option permits additional security labeling information, beyond that present in the Basic Security option (Section 3.13.2.13), to be supplied in an IP datagram to meet the needs of registered authorities. It is specified by RFC 1108 [RFC1108].
该选项允许在IP数据报中提供除基本安全选项（第3.13.2.13节）之外的附加安全标签信息，以满足注册机构的需要。由RFC 1108[RFC1108]规定。
This option may be present only in conjunction with the DoD Basic Security option. Therefore, if a packet contains a DoD Extended Security option (ESO), but does not contain a DoD Basic Security option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). It should be noted that, unlike the DoD Basic Security option, this option may appear multiple times in a single IP header.
该选项仅可与国防部基本安全选项结合使用。因此，如果数据包包含国防部扩展安全选项（ESO），但不包含国防部基本安全选项，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。应该注意的是，与国防部基本安全选项不同，该选项可能在单个IP报头中多次出现。
Systems that belong to networks in which this option is in use, should process the DoD Extended Security option contained in each packet as specified in RFC 1108 [RFC1108].
属于使用此选项的网络的系统应按照RFC 1108[RFC1108]的规定处理每个数据包中包含的国防部扩展安全选项。
RFC 1108 states that the option Length is variable, with a minimum option Length of 3 bytes. Therefore, the following check should be performed:
RFC 1108说明选项长度是可变的，最小选项长度为3字节。因此，应进行以下检查：
ESO.Length >= 3
ESO.长度>=3
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果数据包未通过该检查，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
This option was proposed by the Trusted Systems Interoperability Group (TSIG), with the intent of meeting trusted networking requirements for the commercial trusted systems market place. It is specified in [CIPSO1992] and [FIPS1994].
此选项由可信系统互操作性小组（TSIG）提出，旨在满足商业可信系统市场的可信网络要求。[CIPSO1992]和[FIPS1994]对其进行了规定。
The TSIG proposal was taken to the Commercial Internet Security Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an Internet-Draft was produced [CIPSO1992]. 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]，并编制了互联网草案[CIPSO1992]。互联网草案从未作为RFC发布，但该提案后来被美国国家标准与技术研究所（NIST）标准化为“联邦信息处理标准出版物188”[FIPS1994]。
It is currently implemented in a number of operating systems (e.g., IRIX [IRIX2008], Security-Enhanced Linux [SELinux2009], and Solaris [Solaris2007]), and deployed in a number of high-security networks.
它目前在许多操作系统中实施（例如，IRIX[IRIX2008]、安全增强型Linux[SELinux2009]和Solaris[Solaris2007]），并部署在许多高安全性网络中。
[Zakrzewski2002] and [Haddad2004] provide an overview of a Linux implementation.
[Zakrzewski2002]和[Haddad2004]提供了Linux实现的概述。
Systems that belong to networks in which this option is in use should process the CIPSO option contained in each packet as specified in [CIPSO1992].
属于使用此选项的网络的系统应按照[CIPSO1992]中的规定处理每个数据包中包含的CIPSO选项。
According to the option syntax specified in [CIPSO1992], the following validation check should be performed:
根据[CIPSO1992]中规定的选项语法，应执行以下验证检查：
CIPSO.Length >= 6
CIPSO.长度>=6
If a packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果数据包未通过此检查，则应丢弃该数据包，并且应记录此事件（例如，可增加计数器以反映数据包丢弃）。
This option is defined in RFC 1770 [RFC1770] and originally provided unreliable UDP delivery to a set of addresses included in the option.
该选项在RFC 1770[RFC1770]中定义，最初为选项中包含的一组地址提供了不可靠的UDP传递。
This option is obsolete. If a received packet contains this option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
此选项已过时。如果接收到的数据包包含此选项，则应丢弃该数据包，并记录此事件（例如，可增加计数器以反映数据包丢弃）。
To accommodate networks with different Maximum Transmission Units (MTUs), the Internet Protocol provides a mechanism for the fragmentation of IP packets by end-systems (hosts) and/or intermediate-systems (routers). Reassembly of fragments is performed only by the end-systems.
为了适应具有不同最大传输单元（MTU）的网络，互联网协议提供了一种通过终端系统（主机）和/或中间系统（路由器）对IP数据包进行分段的机制。碎片的重新组装仅由末端系统执行。
[Cerf1974] provides the rationale for why packet reassembly is not performed by intermediate-systems.
[Cerf1974]提供了为什么中间系统不执行数据包重组的基本原理。
During the last few decades, IP fragmentation and reassembly has been exploited in a number of ways, to perform actions such as evading NIDSs, bypassing firewall rules, and performing DoS attacks.
在过去几十年中，IP碎片和重组被以多种方式利用，以执行诸如规避NIDS、绕过防火墙规则和执行DoS攻击等操作。
[Bendi1998] and [Humble1998] are examples of the exploitation of
these issues for performing DoS attacks. [CERT1997] and
[CERT1998b] document these issues. [Anderson2001] is a survey of
fragmentation attacks. [US-CERT2001] is an example of the
exploitation of IP fragmentation to bypass firewall rules.
[CERT1999] describes the implementation of fragmentation attacks
in Distributed Denial-of-Service (DDoS) attack tools.
[Bendi1998] and [Humble1998] are examples of the exploitation of
these issues for performing DoS attacks. [CERT1997] and
[CERT1998b] document these issues. [Anderson2001] is a survey of
fragmentation attacks. [US-CERT2001] is an example of the
exploitation of IP fragmentation to bypass firewall rules.
[CERT1999] describes the implementation of fragmentation attacks
in Distributed Denial-of-Service (DDoS) attack tools.
The problem with IP fragment reassembly basically has to do with the complexity of the function, in a number of aspects:
IP片段重组的问题基本上与功能的复杂性有关，在许多方面：
o Fragment reassembly is a stateful operation for a stateless protocol (IP). The IP module at the host performing the reassembly function must allocate memory buffers both for temporarily storing the received fragments and to perform the reassembly function. Attackers can exploit this fact to exhaust memory buffers at the system performing the fragment reassembly.
o 片段重组是无状态协议（IP）的有状态操作。执行重组功能的主机上的IP模块必须分配内存缓冲区，用于临时存储接收到的片段和执行重组功能。攻击者可以利用这一事实在执行片段重组的系统中耗尽内存缓冲区。
o The fragmentation and reassembly mechanisms were designed at a time in which the available bandwidths were very different from the bandwidths available nowadays. With the current available bandwidths, a number of interoperability problems may arise, and these issues may be intentionally exploited by attackers to perform DoS attacks.
o 碎片和重组机制是在可用带宽与当前可用带宽大不相同的时候设计的。在当前可用带宽下，可能会出现许多互操作性问题，攻击者可能会故意利用这些问题执行DoS攻击。
o Fragment reassembly must usually be performed without any knowledge of the properties of the path the fragments follow. Without this information, hosts cannot make any educated guess on how long they should wait for missing fragments to arrive.
o 片段重组通常必须在不知道片段所遵循路径的属性的情况下执行。如果没有这些信息，主机就无法对丢失的片段应该等待多长时间做出任何有根据的猜测。
o The fragment reassembly algorithm, as described by the IETF specifications, is ambiguous, and allows for a number of interpretations, each of which has found place in different TCP/IP stack implementations.
o IETF规范中描述的片段重组算法是不明确的，并且允许多种解释，每种解释都存在于不同的TCP/IP堆栈实现中。
o The reassembly process is somewhat complex. Fragments may arrive out of order, duplicated, overlapping each other, etc. This complexity has lead to numerous bugs in different implementations of the IP protocol.
o 重新组装的过程有些复杂。片段可能会无序、重复、相互重叠等。这种复杂性导致IP协议的不同实现中存在大量错误。
When an IP datagram is received by an end-system, it will be temporarily stored in system memory, until the IP module processes it and hands it to the protocol machine that corresponds to the encapsulated protocol.
当终端系统接收到IP数据报时，它将临时存储在系统内存中，直到IP模块对其进行处理并将其交给对应于封装协议的协议机器。
In the case of fragmented IP packets, while the IP module may perform preliminary processing of the IP header (such as checking the header for errors and processing IP options), fragments must be kept in system buffers until all fragments are received and are reassembled into a complete Internet datagram.
在碎片化IP数据包的情况下，虽然IP模块可以执行IP报头的初步处理（例如检查报头的错误和处理IP选项），但碎片必须保存在系统缓冲区中，直到所有碎片都被接收并重新组装成完整的互联网数据报。
As mentioned above, because the Internet layer will not usually have information about the characteristics of the path between the system and the remote host, no educated guess can be made on the amount of time that should be waited for the other fragments to arrive. Therefore, the specifications recommend to wait for a period of time that is acceptable for virtually all the possible network scenarios in which the protocols might operate. After that time has elapsed, all the received fragments for the corresponding incomplete packet are discarded.
如上所述，由于Internet层通常不具有关于系统和远程主机之间的路径特征的信息，因此无法对应等待其他片段到达的时间进行有根据的猜测。因此，规范建议等待一段时间，这段时间对于协议可能运行的几乎所有可能的网络场景都是可接受的。在该时间过后，对应的不完整数据包的所有接收片段都将被丢弃。
The original IP Specification, RFC 791 [RFC0791], states that systems should wait for at least 15 seconds for the missing fragments to arrive. Systems that follow the "Example Reassembly Procedure" described in Section 3.2 of RFC 791 may end up using a reassembly timer of up to 4.25 minutes, with a minimum of 15 seconds. Section 3.3.2 ("Reassembly") of RFC 1122 corrected this advice, stating that the reassembly timeout should be a fixed value between 60 and 120 seconds.
原始IP规范RFC 791[RFC0791]规定，系统应至少等待15秒，等待丢失的碎片到达。遵循RFC 791第3.2节所述“示例重新组装程序”的系统最终可能使用最长4.25分钟的重新组装计时器，最短15秒。RFC 1122第3.3.2节（“重新组装”）更正了该建议，指出重新组装超时应为60到120秒之间的固定值。
However, the longer the system waits for the missing fragments to arrive, the longer the corresponding system resources must be tied to the corresponding packet. The amount of system memory is finite, and even with today's systems, it can still be considered a scarce resource.
但是，系统等待丢失的片段到达的时间越长，相应的系统资源必须绑定到相应的数据包的时间就越长。系统内存的数量是有限的，即使在今天的系统中，它仍然可以被视为稀缺资源。
An attacker could take advantage of the uncomfortable situation the system performing fragment reassembly is in, by sending forged fragments that will never reassemble into a complete datagram. That is, an attacker would send many different fragments, with different IP IDs, without ever sending all the necessary fragments that would be needed to reassemble them into a full IP datagram. For each of the fragments, the IP module would allocate resources and tie them to the corresponding fragment, until the reassembly timer for the corresponding packet expires.
攻击者可以利用执行片段重组的系统所处的不舒适情况，通过发送永远不会重组为完整数据报的伪造片段。也就是说，攻击者会发送许多具有不同IP ID的不同片段，而不会发送将它们重新组装成完整IP数据报所需的所有必要片段。对于每个片段，IP模块将分配资源并将它们绑定到相应的片段，直到相应数据包的重新组装计时器过期。
There are some implementation strategies which could increase the impact of this attack. For example, upon receipt of a fragment, some systems allocate a memory buffer that will be large enough to reassemble the whole datagram. While this might be beneficial in legitimate cases, this just amplifies the impact of the possible attacks, as a single small fragment could tie up memory buffers for the size of an extremely large (and unlikely) datagram. The implementation strategy suggested in RFC 815 [RFC0815] leads to such an implementation.
有一些实施策略可能会增加此攻击的影响。例如，在接收到一个片段后，一些系统会分配一个足够大的内存缓冲区来重新组装整个数据报。虽然这在合法情况下可能是有益的，但这只是放大了可能的攻击的影响，因为一个小片段可能会占用内存缓冲区，以容纳一个非常大（而且不太可能）的数据报。RFC 815[RFC0815]中建议的实施策略导致了这种实施。
The impact of the aforementioned attack may vary depending on some specific implementation details:
上述攻击的影响可能因某些具体实施细节而异：
o If the system does not enforce limits on the amount of memory that can be allocated by the IP module, then an attacker could tie all system memory to fragments, at which point the system would become unusable, perhaps crashing.
o 如果系统没有对IP模块可以分配的内存量实施限制，那么攻击者可能会将所有系统内存绑定到碎片上，此时系统将变得不可用，甚至崩溃。
o If the system enforces limits on the amount of memory that can be allocated by the IP module as a whole, then, when this limit is reached, all further IP packets that arrive would be discarded, until some fragments time out and free memory is available again.
o 如果系统强制限制IP模块作为一个整体可以分配的内存量，那么，当达到该限制时，所有到达的IP数据包都将被丢弃，直到一些片段超时并且空闲内存再次可用。
o If the system enforces limits on the amount memory that can be allocated for the reassembly of fragments, then, when this limit is reached, all further fragments that arrive would be discarded, until some fragment(s) time out and free memory is available again.
o 如果系统对可分配用于片段重组的内存量实施限制，则当达到该限制时，将丢弃所有到达的进一步片段，直到部分片段超时且可用内存再次可用。
4.1.1.2. Problems That Arise from the Length of the IP Identification Field
4.1.1.2. IP标识字段长度引起的问题
The Internet Protocols are currently being used in environments that are quite different from the ones in which they were conceived. For instance, the availability of bandwidth at the time the Internet Protocol was designed was completely different from the availability of bandwidth in today's networks.
互联网协议目前正在使用的环境与设想它们的环境大不相同。例如，互联网协议设计时的带宽可用性与当今网络中的带宽可用性完全不同。
The Identification field is a 16-bit field that is used for the fragmentation and reassembly function. In the event a datagram gets fragmented, all the corresponding fragments will share the same {Source Address, Destination Address, Protocol, Identification number} four-tuple. Thus, the system receiving the fragments will be able to uniquely identify them as fragments that correspond to the same IP datagram. At a given point in time, there must be at most only one packet in the network with a given four-tuple. If not, an Identification number "collision" might occur, and the receiving system might end up "mixing" fragments that correspond to different IP datagrams which simply reused the same Identification number.
标识字段是用于碎片和重新组装功能的16位字段。如果数据报被分割，所有相应的片段将共享相同的{源地址、目标地址、协议、标识号}四个元组。因此，接收片段的系统将能够唯一地将它们标识为对应于相同IP数据报的片段。在给定的时间点，网络中最多只能有一个具有给定四元组的数据包。否则，可能会发生标识号“冲突”，并且接收系统可能会最终“混合”对应于不同IP数据报的片段，而这些IP数据报只是重复使用相同的标识号。
For example, sending over a 1 Gbit/s path a continuous stream of (UDP) packets of roughly 1 kb size that all get fragmented into two equally sized fragments of 576 octets each (minimum reassembly buffer size) would repeat the IP Identification values within less than 0.65 seconds (assuming roughly 10% link layer overhead); with shorter packets that still get fragmented, this figure could easily drop below 0.4 seconds. With a single IP packet dropped in this short time frame, packets would start to be reassembled wrongly and continuously once in such interval until an error detection and recovery algorithm at an upper layer lets the application back out.
例如，通过1 Gbit/s路径发送大小约为1 kb的连续（UDP）数据包流，这些数据包被分割成两个大小相等的片段，每个片段为576个八位字节（最小重组缓冲区大小），将在不到0.65秒内重复IP标识值（假设链路层开销约为10%）；如果短的数据包仍然被碎片化，这个数字很容易降到0.4秒以下。在短时间内丢弃单个IP数据包时，数据包将开始错误地重新组合，并在这样的间隔内连续重新组合一次，直到上层的错误检测和恢复算法允许应用程序退出。
For each group of fragments whose Identification numbers "collide", the fragment reassembly will lead to corrupted packets. The IP payload of the reassembled datagram will be handed to the corresponding upper-layer protocol, where the error will (hopefully) be detected by some error detecting code (such as the TCP checksum) and the packet will be discarded.
对于标识号“冲突”的每组碎片，碎片重组将导致损坏的数据包。重新组装的数据报的IP有效载荷将被交给相应的上层协议，在上层协议中，一些错误检测代码（如TCP校验和）将（希望）检测到错误，并且数据包将被丢弃。
An attacker could exploit this fact to intentionally cause a system to discard all or part of the fragmented traffic it gets, thus performing a DoS attack. Such an attacker would simply establish a flow of fragments with different IP Identification numbers, to trash all or part of the IP Identification space. As a result, the receiving system would use the attacker's fragments for the reassembly of legitimate datagrams, leading to corrupted packets which would later (and hopefully) get dropped.
攻击者可以利用这一事实，故意使系统丢弃其获得的所有或部分碎片流量，从而执行DoS攻击。这样的攻击者只需建立一个具有不同IP标识号的片段流，即可将所有或部分IP标识空间都丢弃。因此，接收系统将使用攻击者的片段重新组装合法数据报，从而导致损坏的数据包，这些数据包稍后（希望如此）会被丢弃。
In most cases, use of a long fragment timeout will benefit the attacker, as forged fragments will keep the IP Identification space trashed for a longer period of time.
在大多数情况下，使用较长的片段超时将使攻击者受益，因为伪造的片段将使IP标识空间在较长时间内处于垃圾状态。
4.1.1.3. Problems That Arise from the Complexity of the Reassembly Algorithm
4.1.1.3. 由重组算法的复杂性引起的问题
As IP packets can be duplicated by the network, and each packet may take a different path to get to the destination host, fragments may arrive not only out of order and/or duplicated but also overlapping. This means that the reassembly process can be somewhat complex, with the corresponding implementation being not specifically trivial.
由于网络可以复制IP分组，并且每个分组可以采用不同的路径到达目的地主机，因此片段不仅可能无序和/或重复，而且可能重叠。这意味着重新组装过程可能有点复杂，相应的实现并不特别简单。
[Shannon2001] analyzes the causes and attributes of fragment traffic measured in several types of WANs.
[Shannon 2001]分析了在几种类型的广域网中测量的碎片流量的原因和属性。
During the years, a number of attacks have exploited bugs in the reassembly function of several operating systems, producing buffer overflows that have led, in most cases, to a crash of the attacked system.
在过去的几年中，一些攻击利用了多个操作系统重组功能中的漏洞，产生了缓冲区溢出，在大多数情况下导致被攻击系统崩溃。
4.1.1.4. Problems That Arise from the Ambiguity of the Reassembly Process
4.1.1.4. 由于重新组装过程的模糊性而产生的问题
Network Intrusion Detection Systems (NIDSs) typically monitor the traffic on a given network with the intent of identifying traffic patterns that might indicate network intrusions.
网络入侵检测系统（NIDSs）通常监控给定网络上的流量，目的是识别可能指示网络入侵的流量模式。
In the presence of IP fragments, in order to detect illegitimate activity at the transport or application layers (i.e., any protocol layer above the network layer), a NIDS must perform IP fragment reassembly.
在存在IP片段的情况下，为了检测传输层或应用层（即网络层之上的任何协议层）的非法活动，NIDS必须执行IP片段重组。
In order to correctly assess the traffic, the result of the reassembly function performed by the NIDS should be the same as that of the reassembly function performed by the intended recipient of the packets.
为了正确评估通信量，NIDS执行的重新组装功能的结果应与数据包的预期接收者执行的重新组装功能的结果相同。
However, a number of factors make the result of the reassembly process ambiguous:
然而，许多因素使重新组装过程的结果模糊不清：
o The IETF specifications are ambiguous as to what should be done in the event overlapping fragments were received. Thus, in the presence of overlapping data, the system performing the reassembly function is free to honor either the first set of data received, the latest copy received, or any other copy received in between.
o IETF规范对于在收到重叠片段的情况下应该做什么不明确。因此，在存在重叠数据的情况下，执行重新组装功能的系统可以自由地接受接收到的第一组数据、接收到的最新副本或其间接收到的任何其他副本。
o As the specifications do not enforce any specific fragment timeout value, different systems may choose different values for the fragment timeout. This means that given a set of fragments received at some specified time intervals, some systems will reassemble the fragments into a full datagram, while others may timeout the fragments and therefore drop them.
o 由于规范没有强制执行任何特定的片段超时值，不同的系统可能会为片段超时选择不同的值。这意味着，给定在某个指定的时间间隔接收到的一组片段，一些系统会将片段重新组装成完整的数据报，而其他系统可能会使片段超时，从而丢弃它们。
o As mentioned before, as the fragment buffers get full, a DoS condition will occur unless some action is taken. Many systems flush part of the fragment buffers when some threshold is reached. Thus, depending on fragment load, timing issues, and flushing policy, a NIDS may get incorrect assumptions about how (and if) fragments are being reassembled by their intended recipient.
o 如前所述，当片段缓冲区变满时，除非采取某些操作，否则将出现DoS条件。当达到某个阈值时，许多系统会刷新部分片段缓冲区。因此，根据片段加载、计时问题和刷新策略，NIDS可能会对其预期接收者如何（以及是否）重新组装片段做出错误的假设。
As originally discussed by [Ptacek1998], these issues can be exploited by attackers to evade intrusion detection systems.
正如[Ptacek1998]最初讨论的那样，攻击者可以利用这些问题规避入侵检测系统。
There exist freely available tools to forcefully fragment IP datagrams so as to help evade Intrusion Detection Systems. Frag router [Song1999] is an example of such a tool; it allows an attacker to perform all the evasion techniques described in [Ptacek1998]. Ftester [Barisani2006] is a tool that helps to audit systems regarding fragmentation issues.
有免费提供的工具可以强制分割IP数据报，以帮助规避入侵检测系统。Frag路由器[Song1999]就是此类工具的一个例子；它允许攻击者执行[Ptacek1998]中描述的所有规避技术。Ftester[Barisani2006]是一种帮助审计系统碎片问题的工具。
One approach to fragment filtering involves keeping track of the results of applying filter rules to the first fragment (i.e., the fragment with a Fragment Offset of 0), and applying them to subsequent fragments of the same packet. The filtering module would maintain a list of packets indexed by the Source Address, Destination Address, Protocol, and Identification number. When the initial fragment is seen, if the MF bit is set, a list item would be allocated to hold the result of filter access checks. When packets with a non-zero Fragment Offset come in, look up the list element with a matching Source Address/Destination Address/Protocol/ Identification and apply the stored result (pass or block). When a fragment with a zero MF bit is seen, free the list element. Unfortunately, the rules of this type of packet filter can usually be bypassed. [RFC1858] describes the details of the involved technique.
片段过滤的一种方法涉及跟踪将过滤规则应用于第一个片段（即片段偏移量为0的片段）并将其应用于同一数据包的后续片段的结果。过滤模块将维护由源地址、目的地址、协议和标识号索引的数据包列表。当看到初始片段时，如果设置了MF位，将分配一个列表项来保存过滤器访问检查的结果。当具有非零片段偏移量的数据包进入时，查找具有匹配的源地址/目标地址/协议/标识的列表元素，并应用存储的结果（pass或block）。当看到MF位为零的片段时，释放list元素。不幸的是，这种类型的包过滤器的规则通常可以被绕过。[RFC1858]描述了所涉及技术的细节。
A design choice usually has to be made as to how to allocate memory to reassemble the fragments of a given packet. There are basically two options:
通常必须选择如何分配内存来重新组装给定数据包的片段。基本上有两种选择：
o Upon receipt of the first fragment, allocate a buffer that will be large enough to concatenate the payload of each fragment.
o 在收到第一个片段后，分配一个足够大的缓冲区来连接每个片段的有效负载。
o Upon receipt of the first fragment, create the first node of a linked list to which each of the following fragments will be linked. When all fragments have been received, copy the IP payload of each of the fragments (in the correct order) to a separate buffer that will be handed to the protocol being encapsulated in the IP payload.
o 收到第一个片段后，创建链接列表的第一个节点，以下每个片段都将链接到该节点。收到所有片段后，将每个片段的IP有效负载（按正确顺序）复制到一个单独的缓冲区，该缓冲区将交给封装在IP有效负载中的协议。
While the first of the choices might seem to be the most straightforward, it implies that even when a single small fragment of a given packet is received, the amount of memory that will be allocated for that fragment will account for the size of the complete IP datagram, thus using more system resources than what is actually needed.
虽然第一种选择似乎是最直接的，但它意味着即使在接收到给定数据包的单个小片段时，为该片段分配的内存量也将占到整个IP数据报的大小，因此使用的系统资源比实际需要的要多。
Furthermore, the only situation in which the actual size of the whole datagram will be known is when the last fragment of the packet is received first, as that is the only packet from which the total size of the IP datagram can be asserted. Otherwise, memory should be allocated for the largest possible packet size (65535 bytes).
此外，将知道整个数据报的实际大小的唯一情况是当首先接收到分组的最后片段时，因为这是可以断言IP数据报的总大小的唯一分组。否则，应为可能的最大数据包大小（65535字节）分配内存。
The IP module should also enforce a limit on the amount of memory that can be allocated for IP fragments, as well as a limit on the number of fragments that at any time will be allowed in the system. This will basically limit the resources spent on the reassembly process, and prevent an attacker from trashing the whole system memory.
IP模块还应限制可分配给IP片段的内存量，以及限制系统中随时允许的片段数量。这将基本上限制重新组装过程中花费的资源，并防止攻击者破坏整个系统内存。
Furthermore, the IP module should keep a different buffer for IP fragments than for complete IP datagrams. This will basically separate the effects of fragment attacks on non-fragmented traffic. Most TCP/IP implementations, such as that in Linux and those in BSD-derived systems, already implement this.
此外，IP模块应该为IP片段保留与完整IP数据报不同的缓冲区。这将基本上分离碎片攻击对非碎片流量的影响。大多数TCP/IP实现，例如Linux和BSD派生系统中的TCP/IP实现，已经实现了这一点。
[Jones2002] analyzes the amount of memory that may be needed for the fragment reassembly buffer depending on a number of network characteristics.
[Jones2002]根据许多网络特征，分析片段重组缓冲区可能需要的内存量。
In the case of those attacks that aim to consume the memory buffers used for fragments, and those that aim to cause a collision of IP Identification numbers, there are a number of countermeasures that can be implemented.
对于那些旨在消耗用于碎片的内存缓冲区的攻击，以及那些旨在造成IP标识号冲突的攻击，有许多可以实施的对策。
Even with these countermeasures in place, there is still the issue of what to do when the buffer pool used for IP fragments gets full. Basically, if the fragment buffer is full, no instance of communication that relies on fragmentation will be able to progress.
即使有了这些应对措施，当用于IP片段的缓冲池满了时，仍然存在着如何做的问题。基本上，如果片段缓冲区已满，则依赖于片段的通信实例将无法进行。
Unfortunately, there are not many options for reacting to this situation. If nothing is done, all the instances of communication that rely on fragmentation will experience a denial of service. Thus, the only thing that can be done is flush all or part of the fragment buffer, on the premise that legitimate traffic will be able to make use of the freed buffer space to allow communication flows to progress.
不幸的是，对这种情况作出反应的选择不多。如果不采取任何措施，所有依赖碎片的通信实例都将经历拒绝服务。因此，唯一可以做的事情就是刷新全部或部分片段缓冲区，前提是合法通信将能够利用释放的缓冲区空间来允许通信流进行。
There are a number of factors that should be taken into consideration when flushing the fragment buffers. First, if a fragment of a given packet (i.e., fragment with a given Identification number) is flushed, all the other fragments that correspond to the same datagram should be flushed. As in order for a packet to be reassembled all of its fragments must be received by the system performing the reassembly function, flushing only a subset of the fragments of a given packet would keep the corresponding buffers tied to fragments that would never reassemble into a complete datagram. Additionally, care must be taken so that, in the event that subsequent buffer flushes need to be performed, it is not always the same set of fragments that get dropped, as such a behavior would probably cause a selective DoS to the traffic flows to which that set of fragments belongs.
在刷新片段缓冲区时，应该考虑许多因素。首先，如果给定数据包的片段（即具有给定标识号的片段）被刷新，则应刷新与相同数据报对应的所有其他片段。为了重新组装数据包，执行重新组装功能的系统必须接收其所有片段，仅刷新给定数据包片段的子集将使相应的缓冲区与永远不会重新组装成完整数据报的片段相关联。此外，必须小心，以便在需要执行后续缓冲区刷新的情况下，不总是丢弃相同的片段集，因为这样的行为可能会对该片段集所属的流量流造成选择性拒绝。
Many TCP/IP implementations define a threshold for the number of fragments that, when reached, triggers a fragment-buffer flush. Some systems flush 1/2 of the fragment buffer when the threshold is reached. As mentioned before, the idea of flushing the buffer is to create some free space in the fragment buffer, on the premise that this will allow for new and legitimate fragments to be processed by the IP module, thus letting communication survive the overwhelming situation. On the other hand, the idea of flushing a somewhat large portion of the buffer is to avoid flushing always the same set of packets.
许多TCP/IP实现为片段数量定义了一个阈值，当达到该阈值时，会触发片段缓冲区刷新。一些系统在达到阈值时刷新1/2的片段缓冲区。如前所述，刷新缓冲区的想法是在片段缓冲区中创建一些空闲空间，前提是这将允许IP模块处理新的合法片段，从而使通信能够在压倒性的情况下生存。另一方面，刷新缓冲区的较大部分的想法是避免总是刷新同一组数据包。
One of the difficulties in implementing countermeasures for the fragmentation attacks described throughout Section 4.1 is that it is difficult to perform validation checks on the received fragments. For instance, the fragment on which validity checks could be performed, the first fragment, may be not the first fragment to arrive at the destination host.
实施第4.1节所述碎片攻击对策的困难之一是难以对接收到的碎片执行验证检查。例如，可以对其执行有效性检查的片段（第一个片段）可能不是到达目标主机的第一个片段。
Fragments cannot only arrive out of order because of packet reordering performed by the network, but also because the system (or systems) that fragmented the IP datagram may indeed transmit the fragments out of order. A notable example of this is the Linux TCP/IP stack, which transmits the fragments in reverse order.
由于网络执行的数据包重新排序，片段不能无序到达，还因为对IP数据报进行分段的系统（或多个系统）可能确实会无序传输片段。一个值得注意的例子是LinuxTCP/IP堆栈，它以相反的顺序传输片段。
This means that we cannot enforce checks on the fragments for which we allocate reassembly resources, as the first fragment we receive for a given packet may be some other fragment than the first one (the one with an Fragment Offset of 0).
这意味着我们不能对分配重组资源的片段强制执行检查，因为我们为给定数据包接收的第一个片段可能是第一个片段以外的其他片段（片段偏移量为0的片段）。
However, at the point in which we decide to free some space in the fragment buffer, some refinements can be done to the flushing policy. The first thing we would like to do is to stop different types of traffic from interfering with each other. This means, in principle, that we do not want fragmented UDP traffic to interfere with fragmented TCP traffic. In order to implement this traffic separation for the different protocols, a different fragment buffer pool would be needed, in principle, for each of the 256 different protocols that can be encapsulated in an IP datagram.
但是，在我们决定释放片段缓冲区中的一些空间时，可以对刷新策略进行一些改进。我们想做的第一件事是阻止不同类型的交通相互干扰。这意味着，原则上，我们不希望分段UDP通信干扰分段TCP通信。为了实现不同协议的流量分离，原则上，对于可以封装在IP数据报中的256个不同协议中的每一个，都需要不同的片段缓冲池。
We believe a trade-off is to implement two separate fragment buffers: one for IP datagrams that encapsulate IPsec packets and another for the rest of the traffic. This basically means that traffic not protected by IPsec will not interfere with those flows of communication that are being protected by IPsec.
我们认为一个折衷方案是实现两个独立的片段缓冲区：一个用于封装IPsec数据包的IP数据报，另一个用于其余的流量。这基本上意味着不受IPsec保护的通信不会干扰受IPsec保护的通信流。
The processing of each of these two different fragment buffer pools would be completely independent from each other. In the case of the IPsec fragment buffer pool, when the buffers needs to be flushed, the following refined policy could be applied:
这两个不同片段缓冲池中的每一个的处理都是完全独立的。对于IPsec片段缓冲池，当需要刷新缓冲区时，可以应用以下优化策略：
o First, for each packet for which the IPsec header has been received, check that the Security Parameters Index (SPI) field of the IPsec header corresponds to an existing IPsec Security Association (SA), and probably also check that the IPsec sequence number is valid. If the check fails, drop all the fragments that correspond to this packet.
o 首先，对于已接收到IPsec头的每个数据包，检查IPsec头的安全参数索引（SPI）字段是否对应于现有的IPsec安全关联（SA），并且可能还检查IPsec序列号是否有效。如果检查失败，请删除与此数据包对应的所有片段。
o Second, if still more fragment buffers need to be flushed, drop all the fragments that correspond to packets for which the full IPsec header has not yet been received. The number of packets for which this flushing is performed depends on the amount of free space that needs to be created.
o 其次，如果还需要刷新更多的片段缓冲区，则删除与尚未接收完整IPsec头的数据包相对应的所有片段。执行此刷新的数据包数取决于需要创建的可用空间量。
o Third, if after flushing packets with invalid IPsec information (First step), and packets on which validation checks could not be performed (Second step), there is still not enough space in the
o 第三，如果在刷新包含无效IPsec信息的数据包（第一步）和无法执行验证检查的数据包（第二步）之后，数据包中仍然没有足够的空间
fragment buffer, drop all the fragments that correspond to packets that passed the checks of the first step, until the necessary free space is created.
片段缓冲区，删除与通过第一步检查的数据包对应的所有片段，直到创建必要的可用空间。
The rationale behind this policy is that, at the point of flushing fragment buffers, we prefer to keep those packets on which we could successfully perform a number of validation checks, over those packets on which those checks failed, or the checks could not even be performed.
此策略背后的基本原理是，在刷新片段缓冲区时，我们更愿意保留那些可以成功执行大量验证检查的数据包，而不是那些检查失败或甚至无法执行检查的数据包。
By checking both the IPsec SPI and the IPsec sequence number, it is virtually impossible for an attacker that is off-path to perform a DoS attack to communication flows being protected by IPsec.
通过检查IPsec SPI和IPsec序列号，不在路径上的攻击者几乎不可能对受IPsec保护的通信流执行DoS攻击。
Unfortunately, some IP implementations (such as that in Linux [Linux]), when performing fragmentation, send the corresponding fragments in reverse order. In such cases, at the point of flushing the fragment buffer, legitimate fragments will receive the same treatment as the possible forged fragments.
不幸的是，某些IP实现（例如Linux[Linux]）在执行碎片时，会以相反的顺序发送相应的碎片。在这种情况下，在刷新碎片缓冲区时，合法碎片将得到与可能伪造碎片相同的处理。
This refined flushing policy provides an increased level of protection against this type of resource exhaustion attack, while not making the situation of out-of-order IPsec-secured traffic worse than with the simplified flushing policy described in the previous section.
这种改进的刷新策略针对此类资源耗尽攻击提供了更高级别的保护，同时不会使无序的IPsec安全通信情况比上一节中描述的简化刷新策略更糟。
RFC 1122 [RFC1122] states that the reassembly timeout should be a fixed value between 60 and 120 seconds. The rationale behind these long timeout values is that they should accommodate any path characteristics, such as long-delay paths. However, it must be noted that this timer is really measuring inter-fragment delays, or, more specifically, fragment jitter.
RFC 1122[RFC1122]规定重新组装超时应为60到120秒之间的固定值。这些长超时值背后的基本原理是，它们应该适应任何路径特征，例如长延迟路径。然而，必须注意的是，这个计时器实际上是在测量片段间延迟，或者更具体地说，是片段抖动。
If all fragments take paths of similar characteristics, the inter-fragment delay will usually be, at most, a few seconds. Nevertheless, even if fragments take different paths of different characteristics, the recommended 60 to 120 seconds are, in practice, excessive.
如果所有片段都采用具有相似特征的路径，则片段间延迟通常最多为几秒钟。然而，即使碎片具有不同特征的不同路径，建议的60到120秒在实践中也是多余的。
Some systems have already reduced the fragment timeout to 30 seconds [Linux]. The fragment timeout could probably be further reduced to approximately 15 seconds; although further research on this issue is necessary.
一些系统已经将片段超时时间减少到30秒[Linux]。片段超时可能进一步减少到大约15秒；尽管对这个问题的进一步研究是必要的。
It should be noted that in network scenarios of long-delay and high-bandwidth (usually referred to as "Long-Fat Networks"), using a long fragment timeout would likely increase the probability of collision of IP ID numbers. Therefore, in such scenarios it is highly desirable to avoid the use of fragmentation with techniques such as PMTUD [RFC1191] or PLPMTUD [RFC4821].
应该注意的是，在长延迟和高带宽的网络场景中（通常称为“长Fat网络”），使用长片段超时可能会增加IP ID号冲突的概率。因此，在这样的场景中，非常希望避免使用诸如PMTUD[rfc191]或PLPMTUD[RFC4821]之类的技术来使用碎片。
[Shankar2003] introduces a technique named "Active Mapping" that
prevents evasion of a NIDS by acquiring sufficient knowledge about
the network being monitored, to assess which packets will arrive at
the intended recipient, and how they will be interpreted by it.
[Novak2005] describes some techniques that are applied by the Snort
[Snort] NIDS to avoid evasion.
[Shankar2003] introduces a technique named "Active Mapping" that
prevents evasion of a NIDS by acquiring sufficient knowledge about
the network being monitored, to assess which packets will arrive at
the intended recipient, and how they will be interpreted by it.
[Novak2005] describes some techniques that are applied by the Snort
[Snort] NIDS to avoid evasion.
One of the classical techniques to bypass firewall rules involves sending packets in which the header of the encapsulated protocol is fragmented. Even when it would be legal (as far as the IETF specifications are concerned) to receive such a packets, the MTUs of the network technologies used in practice are not that small to require the header of the encapsulated protocol to be fragmented (e.g., see [RFC2544]). Therefore, the system performing reassembly should drop all packets which fragment the upper-layer protocol header, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
绕过防火墙规则的经典技术之一涉及发送封装协议的报头被分段的数据包。即使接收这样的数据包是合法的（就IETF规范而言），实际使用的网络技术的MTU也不会太小，以至于需要将封装协议的报头分段（例如，参见[RFC2544]）。因此，执行重新组装的系统应丢弃将上层协议头分割成碎片的所有数据包，并且应记录该事件（例如，可增加计数器以反映数据包丢弃）。
Additionally, given that many middle-boxes such as firewalls create state according to the contents of the first fragment of a given packet, it is best that, in the event an end-system receives overlapping fragments, it honors the information contained in the fragment that was received first.
此外，考虑到许多中间框（如防火墙）根据给定数据包的第一个片段的内容创建状态，最好是在终端系统接收到重叠片段的情况下，尊重首先接收到的片段中包含的信息。
RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858.
RFC1858[RFC1858]描述了滥用IP碎片来绕过防火墙规则的情况。RFC 3128[RFC3128]更正了RFC 1858中的一些错误。
Section 5.3.3.1 of RFC 1812 [RFC1812] states that routers should implement precedence-ordered queue service. This means that when a packet is selected for output on a (logical) link, the packet of highest precedence that has been queued for that link is sent. Section 5.3.3.2 of RFC 1812 advises routers to default to maintaining strict precedence-ordered service.
RFC 1812[RFC1812]第5.3.3.1节规定路由器应实现优先顺序队列服务。这意味着，当选择一个数据包作为（逻辑）链路上的输出时，将发送为该链路排队的优先级最高的数据包。RFC 1812第5.3.3.2节建议路由器默认维护严格的优先顺序服务。
Unfortunately, given that it is trivial to forge the IP precedence field of the IP header, an attacker could simply forge a high precedence number in the packets it sends to illegitimately get better network service. If precedence-ordered queued service is not required in a particular network infrastructure, it should be disabled, and thus all packets would receive the same type of service, despite the values in their Type of Service or Differentiated Services fields.
不幸的是，由于伪造IP报头的IP优先级字段很简单，攻击者只需在其发送的数据包中伪造一个高优先级数字，即可非法获得更好的网络服务。如果特定网络基础设施中不需要优先顺序排队服务，则应禁用该服务，因此所有数据包都将接收相同类型的服务，而不管其服务类型或区分服务字段中的值如何。
When precedence-ordered queue service is required in the network infrastructure, in order to mitigate the attack vector discussed in the previous paragraph, edge routers or switches should be configured to police and remark the Type of Service or Differentiated Services values, according to the type of service at which each end-system has been allowed to send packets.
当在网络基础设施中需要优先排序队列服务时，为了减轻前一段中讨论的攻击向量，边缘路由器或交换机应该被配置为对服务类型或区分服务值进行警戒和评论，根据允许每个终端系统发送数据包的服务类型。
Bullet 4 of Section 5.3.3.3 of RFC 1812 states that routers "MUST NOT change precedence settings on packets it did not originate". However, given the security implications of the Precedence field, it is fair for routers, switches, or other middle-boxes, particularly those in the network edge, to overwrite the Type of Service (or Differentiated Services) field of the packets they are forwarding, according to a configured network policy (this is the specified behavior for DS domains [RFC2475]).
RFC 1812第5.3.3.3节的项目符号4规定，路由器“不得更改其未发起的数据包的优先级设置”。然而，考虑到优先字段的安全含义，路由器、交换机或其他中间盒，特别是网络边缘的路由器、交换机或其他中间盒，根据配置的网络策略覆盖它们转发的数据包的服务类型（或区分服务）字段是公平的（这是DS域[RFC2475]的指定行为）。
Sections 5.3.3.1 and 5.3.6 of RFC 1812 state that if precedence-ordered queue service is implemented and enabled, the router "MUST NOT discard a packet whose precedence is higher than that of a packet that is not discarded". While this recommendation makes sense given the semantics of the Precedence field, it is important to note that it would be simple for an attacker to send packets with forged high Precedence value to congest some internet router(s), and cause all (or most) traffic with a lower Precedence value to be discarded.
RFC 1812第5.3.3.1和5.3.6节规定，如果实现并启用了优先顺序队列服务，路由器“不得丢弃优先级高于未丢弃数据包优先级的数据包”。尽管考虑到优先级字段的语义，此建议是有意义的，但需要注意的是，攻击者发送伪造的高优先级数据包以堵塞某些internet路由器，并导致丢弃所有（或大部分）优先级较低的流量，这将是很简单的。
Section 5.2.4.3 of RFC 1812 describes the algorithm for determining the next-hop address (i.e., the forwarding algorithm). Bullet 3, "Weak TOS", addresses the case in which routes contain a "type of service" attribute. It states that in case a packet contains a non-default TOS (i.e., 0000), only routes with the same TOS or with the default TOS should be considered for forwarding that packet. However, this means that if among the longest match routes for a given packet are routes with some TOS other than the one contained in the received packet, and no routes with the default TOS, the corresponding packet would be dropped. This may or may not be a desired behavior.
RFC 1812第5.2.4.3节描述了确定下一跳地址的算法（即转发算法）。项目符号3“弱TOS”解决了路由包含“服务类型”属性的情况。它指出，如果数据包包含非默认TOS（即0000），则只有具有相同TOS或默认TOS的路由才应考虑转发该数据包。然而，这意味着，如果给定分组的最长匹配路由中有一些TOS而不是包含在接收分组中的TOS的路由，并且没有具有默认TOS的路由，则相应的分组将被丢弃。这可能是也可能不是期望的行为。
An alternative for the case in which among the "longest match" routes there are only routes with non-default type of service that do not match the TOS contained in the received packet, would be to use a route with any other TOS. While this route would most likely not be able to address the type of service requested by packet, it would, at least, provide a "best effort" service.
在“最长匹配”路由中，只有非默认服务类型的路由与接收到的数据包中包含的TOS不匹配的情况下，另一种选择是与任何其他TOS一起使用路由。虽然此路由很可能无法处理数据包请求的服务类型，但它至少可以提供“尽力而为”的服务。
It must be noted that Section 5.3.2 of RFC 1812 allows routers to not honor the TOS field. Therefore, the proposed alternative behavior is still compliant with the IETF specifications.
必须注意的是，RFC 1812第5.3.2节允许路由器不遵守TOS字段。因此，建议的替代行为仍然符合IETF规范。
While officially specified in the RFC series, TOS-based routing is not widely deployed in the Internet.
虽然在RFC系列中有正式规定，但基于TOS的路由并没有在Internet中广泛部署。
In the case of broadcast link-layer technologies, in order for a system to transfer an IP datagram it must usually first map an IP address to the corresponding link-layer address (for example, by means of the Address Resolution Protocol (ARP) [RFC0826]) . This means that while this operation is being performed, the packets that would require such a mapping would need to be kept in memory. This may happen both in the case of hosts and in the case of routers.
在广播链路层技术的情况下，为了使系统传输IP数据报，通常必须首先将IP地址映射到相应的链路层地址（例如，通过地址解析协议（ARP）[RFC0826]）。这意味着在执行此操作时，需要这种映射的数据包需要保存在内存中。这可能发生在主机和路由器的情况下。
This situation might be exploited by an attacker, which could send a large amount of packets to a non-existent host that would supposedly be directly connected to the attacked router. While trying to map the corresponding IP address into a link-layer address, the attacked router would keep in memory all the packets that would need to make use of that link-layer address. At the point in which the mapping function times out, depending on the policy implemented by the attacked router, only the packet that triggered the call to the mapping function might be dropped. In that case, the same operation would be repeated for every packet destined to the non-existent host. Depending on the timeout value for the mapping function, this situation might lead the router to run out of free buffer space, with the consequence that incoming legitimate packets would have to be dropped, or that legitimate packets already stored in the router's buffers might get dropped. Both of these situations would lead either to a complete DoS or to a degradation of the network service.
攻击者可能会利用这种情况，向不存在的主机发送大量数据包，该主机可能直接连接到受攻击的路由器。当试图将相应的IP地址映射到链路层地址时，受攻击的路由器将在内存中保留使用该链路层地址所需的所有数据包。在映射函数超时时，根据受攻击路由器实施的策略，只有触发映射函数调用的数据包可能会被丢弃。在这种情况下，将对发送到不存在的主机的每个数据包重复相同的操作。根据映射函数的超时值，这种情况可能会导致路由器耗尽可用的缓冲区空间，从而导致必须丢弃传入的合法数据包，或者丢弃已经存储在路由器缓冲区中的合法数据包。这两种情况都会导致完全拒绝服务或网络服务降级。
One countermeasure to this problem would be to drop, at the point the mapping function times out, all the packets destined to the address that timed out. In addition, a "negative cache entry" might be kept in the module performing the matching function, so that for some amount of time, the mapping function would return an error when the IP module requests to perform a mapping for some address for which the mapping has recently timed out.
解决这个问题的一个对策是，在映射函数超时时丢弃所有发送到超时地址的数据包。此外，在执行匹配功能的模块中可能会保留一个“负缓存条目”，以便在一段时间内，当IP模块请求对最近映射超时的某个地址执行映射时，映射功能将返回一个错误。
A common implementation strategy for routers is that when a packet is received that requires an ARP resolution to be performed before the packet can be forwarded, the packet is dropped and the router is then engaged in the ARP procedure.
路由器的一种常见实现策略是，当接收到需要在转发数据包之前执行ARP解析的数据包时，丢弃该数据包，然后路由器参与ARP过程。
In some scenarios, it may be necessary for a host or router to drop packets from the output queue. In the event that one of such packets happens to be an IP fragment, and there were other fragments of the same packet in the queue, those other fragments should also be dropped. The rationale for this policy is that it is nonsensical to spend system resources on those other fragments, because, as long as one fragment is missing, it will be impossible for the receiving system to reassemble them into a complete IP datagram.
在某些情况下，主机或路由器可能需要从输出队列中丢弃数据包。如果其中一个数据包恰好是IP片段，并且队列中存在同一数据包的其他片段，那么这些其他片段也应该被丢弃。此策略的基本原理是，将系统资源花费在这些其他片段上是毫无意义的，因为只要缺少一个片段，接收系统就不可能将其重新组装成完整的IP数据报。
Some systems have been known to drop just a subset of fragments of a given datagram, leading to a denial-of-service condition, as only a subset of all the fragments of the packets were actually transferred to the next hop.
已知一些系统仅丢弃给定数据报片段的子集，从而导致拒绝服务情况，因为实际上只有数据包所有片段的子集被传输到下一跳。
It is important to understand that while there are some addresses that are supposed to be unreachable from the public Internet (such as the private IP addresses described in RFC 1918 [RFC1918], or the "loopback" address), there are a number of tricks an attacker can perform to reach those IP addresses that would otherwise be unreachable (e.g., exploit the LSRR or SSRR IP options). Therefore, when applicable, packet filtering should be performed at the private network boundary to assure that those addresses will be unreachable.
重要的是要了解，虽然有些地址被认为是无法从公共互联网访问的（如RFC 1918[RFC1918]中描述的私有IP地址或“环回”地址），但攻击者可以使用许多技巧来访问那些原本无法访问的IP地址（例如，利用LSRR或SSRR IP选项）。因此，如果适用，应在专用网络边界执行数据包过滤，以确保无法访问这些地址。
Similarly, link-local unicast addresses [RFC3927] and multicast addresses with limited scope (link- and site-local addresses) should not be accessible from outside the proper network boundaries and not be passed across these boundaries.
类似地，链路本地单播地址[RFC3927]和范围有限的多播地址（链路和站点本地地址）不应从适当的网络边界之外访问，也不应跨越这些边界传递。
[RFC5735] provides a summary of special use IPv4 addresses.
[RFC5735]提供了特殊用途IPv4地址的摘要。
The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:
互联网分配号码管理局（IANA）为私人互联网保留了以下三块IP地址空间：
o 10.0.0.0 - 10.255.255.255 (10/8 prefix)
o 10.0.0.0-10.255.255.255（10/8前缀）
o 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
o 172.16.0.0-172.31.255.255（172.16/12前缀）
o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
o 192.168.0.0-192.168.255.255（192.168/16前缀）
Use of these address blocks is described in RFC 1918 [RFC1918].
RFC 1918[RFC1918]中描述了这些地址块的使用。
Where applicable, packet filtering should be performed at the organizational perimeter to assure that these addresses are not reachable from outside the private network where such addresses are employed.
在适用的情况下，应在组织外围执行数据包过滤，以确保这些地址无法从使用这些地址的专用网络外部访问。
The former Class D addresses correspond to the 224/4 address block and are used for Internet multicast. Therefore, if a packet is received with a "Class D" address as the Source Address, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Additionally, if an IP packet with a multicast Destination Address is received for a connection-oriented protocol (e.g., TCP), the packet should be dropped (see Section 4.3.5), and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
前D类地址对应于224/4地址块，用于Internet多播。因此，如果接收到以“D类”地址作为源地址的数据包，则应丢弃该数据包，并且应记录该事件（例如，可增加计数器以反映数据包丢弃）。此外，如果针对面向连接的协议（例如TCP）接收到具有多播目的地地址的IP数据包，则应丢弃该数据包（参见第4.3.5节），并应记录该事件（例如，可增加计数器以反映数据包丢弃）。
The former Class E addresses correspond to the 240/4 address block, and are currently reserved for experimental use. As a result, a most routers discard packets that contain a "Class" E address as the Source Address or Destination Address. If a packet is received with a 240/4 address as the Source Address and/or the Destination Address, the packet should be dropped and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
前E类地址对应于240/4地址块，目前保留供实验使用。结果，大多数路由器丢弃包含“Class”E地址作为源地址或目标地址的数据包。如果接收到的数据包的源地址和/或目的地址为240/4，则应丢弃该数据包并记录该事件（例如，可增加计数器以反映数据包丢弃）。
It should be noted that the broadcast address 255.255.255.255 still must be treated as indicated in Section 4.3.7 of this document.
应注意的是，广播地址255.255.255.255仍必须按照本文件第4.3.7节的规定处理。
For connection-oriented protocols, such as TCP, shared state is maintained between only two endpoints at a time. Therefore, if an IP packet with a multicast (or broadcast) Destination Address is received for a connection-oriented protocol (e.g., TCP), the packet should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
对于面向连接的协议，如TCP，一次只在两个端点之间维护共享状态。因此，如果针对面向连接的协议（例如，TCP）接收到具有多播（或广播）目的地地址的IP数据包，则应丢弃该数据包，并且应记录该事件（例如，可增加计数器以反映数据包丢弃）。
Originally, the IETF specifications did not permit IP addresses to have the value 0 or -1 (shorthand for all bits set to 1) for any of the Host number, network number, or subnet number fields, except for the cases indicated in Section 4.3.7. However, this changed fundamentally with the deployment of Classless Inter-Domain Routing (CIDR) [RFC4632], as with CIDR a system cannot know a priori what the subnet mask is for a particular IP address.
最初，IETF规范不允许IP地址的任何主机号、网络号或子网号字段的值为0或-1（所有位的缩写设置为1），但第4.3.7节中指出的情况除外。然而，随着无类域间路由（CIDR）[RFC4632]的部署，这种情况发生了根本性的变化，因为对于CIDR，系统无法预先知道特定IP地址的子网掩码是什么。
Many systems now allow administrators to use the values 0 or -1 for those fields. Despite that according to the original IETF specifications these addresses are illegal, modern IP implementations should consider these addresses to be valid.
许多系统现在允许管理员对这些字段使用值0或-1。尽管根据原始IETF规范，这些地址是非法的，但现代IP实现应该考虑这些地址是有效的。
RFC 1812 [RFC1812] discusses the use of some special Internet addresses, which is of interest to perform some sanity checks on the Source Address and Destination Address fields of an IP packet. It uses the following notation for an IP address:
RFC 1812[RFC1812]讨论了一些特殊Internet地址的使用，这对于在IP数据包的源地址和目标地址字段上执行一些健全性检查很有意义。它对IP地址使用以下符号：
{ <Network-prefix>, <Host-number> }
{ <Network-prefix>, <Host-number> }
where the length of the network prefix is generally implied by the network mask assigned to the IP interface under consideration.
其中，网络前缀的长度通常由分配给所考虑的IP接口的网络掩码暗示。
RFC 1122 [RFC1122] contained a similar discussion of special Internet addresses, including some of the form { <Network-prefix>, <Subnet-number>, <Host-number> }. However, as explained in Section 4.2.2.11 of RFC 1812, in a CIDR world, the subnet number is clearly an extension of the network prefix and cannot be distinguished from the remainder of the prefix.
RFC 1122[RFC1122]包含了对特殊互联网地址的类似讨论，包括一些形式{<Network prefix>，<Subnet number>，<Host number>}。然而，如RFC 1812第4.2.2.11节所述，在CIDR世界中，子网编号显然是网络前缀的扩展，不能与前缀的其余部分区分开来。
{0, 0}
{0, 0}
This address means "this host on this network". It is meant to be used only during the initialization procedure, by which the host learns its own IP address.
此地址表示“此网络上的此主机”。它仅在初始化过程中使用，主机通过初始化过程学习自己的IP地址。
If a packet is received with 0.0.0.0 as the Source Address for any purpose other than bootstrapping, the corresponding packet should be silently dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). If a packet is received with 0.0.0.0 as the Destination Address, it should be silently dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
如果出于除引导以外的任何目的接收到以0.0.0.0作为源地址的数据包，则应静默丢弃相应的数据包，并记录此事件（例如，可增加计数器以反映数据包丢弃）。如果接收到以0.0.0.0作为目标地址的数据包，则应静默丢弃该数据包，并且应记录该事件（例如，可增加计数器以反映数据包丢弃）。
{0, Host number}
{0，主机号}
This address means "the specified host, in this network". As in the previous case, it is meant to be used only during the initialization procedure by which the host learns its own IP address. If a packet is received with such an address as the Source Address for any purpose other than bootstrapping, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). If a packet is received with such an address as the Destination Address, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
此地址表示“此网络中的指定主机”。与前一种情况一样，它仅在主机学习其自身IP地址的初始化过程中使用。如果出于除引导以外的任何目的接收到的数据包的地址作为源地址，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。如果接收到的数据包的地址为目的地地址，则应丢弃该数据包，并记录该事件（例如，可增加计数器以反映数据包丢弃）。
{-1, -1}
{-1, -1}
This address is the local broadcast address. It should not be used as a source IP address. If a packet is received with 255.255.255.255 as the Source Address, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
这个地址是本地广播地址。不应将其用作源IP地址。如果接收到以255.255.255.255作为源地址的数据包，则应丢弃该数据包，并且应记录该事件（例如，可增加计数器以反映数据包丢弃）。
Some systems, when receiving an ICMP echo request, for example, will use the Destination Address in the ICMP echo request packet as the Source Address of the response they send (in this case, an ICMP echo reply). Thus, when such systems receive a request sent to a broadcast address, the Source Address of the response will contain a broadcast address. This should be considered a bug, rather than a malicious use of the limited broadcast address.
例如，一些系统在接收ICMP回显请求时，将使用ICMP回显请求数据包中的目标地址作为其发送的响应的源地址（在本例中，为ICMP回显回复）。因此，当这样的系统接收到发送到广播地址的请求时，响应的源地址将包含广播地址。这应该被视为一个bug，而不是恶意使用有限的广播地址。
{Network number, -1}
{Network number, -1}
This is the directed broadcast to the specified network. As recommended by RFC 2644 [RFC2644], routers should not forward network-directed broadcasts. This avoids the corresponding network from being utilized as, for example, a "smurf amplifier" [CERT1998a].
这是指向指定网络的定向广播。根据RFC 2644[RFC2644]的建议，路由器不应转发网络定向广播。这避免了相应的网络被用作例如“蓝精灵放大器”[CERT1998a]。
As noted in Section 4.3.6 of this document, many systems now allow administrators to configure these addresses as unicast addresses for network interfaces. In such scenarios, routers should forward these addresses as if they were traditional unicast addresses.
如本文件第4.3.6节所述，许多系统现在允许管理员将这些地址配置为网络接口的单播地址。在这种情况下，路由器应该转发这些地址，就像它们是传统的单播地址一样。
In some scenarios, a host may have knowledge about a particular IP address being a network-directed broadcast address, rather than a unicast address (e.g., that IP address is configured on the local system as a "broadcast address"). In such scenarios, if a system can infer that the Source Address of a received packet is a network-
在一些场景中，主机可能知道特定IP地址是网络定向广播地址，而不是单播地址（例如，该IP地址在本地系统上配置为“广播地址”）。在这种情况下，如果系统可以推断接收到的数据包的源地址是网络-
directed broadcast address, the packet should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
定向广播地址，应丢弃数据包，并且应记录此事件（例如，可增加计数器以反映数据包丢弃）。
As noted in Section 4.3.6 of this document, with the deployment of CIDR [RFC4632], it may be difficult for a system to infer whether a particular IP address that does not belong to a directly attached subnet is a broadcast address.
如本文件第4.3.6节所述，随着CIDR[RFC4632]的部署，系统可能难以推断不属于直连子网的特定IP地址是否为广播地址。
{127.0.0.0/8, any}
{127.0.0.0/8, any}
This is the internal host loopback address. Any packet that arrives on any physical interface containing this address as the Source Address, the Destination Address, or as part of a source route (either LSRR or SSRR), should be dropped.
这是内部主机环回地址。任何到达任何物理接口（包含此地址作为源地址、目标地址或作为源路由（LSRR或SSRR）的一部分）的数据包都应丢弃。
For example, packets with a Destination Address in the 127.0.0.0/8 address block that are received on an interface other than loopback should be silently dropped. Packets received on any interface other than loopback with a Source Address corresponding to the system receiving the packet should also be dropped.
例如，在127.0.0.0/8地址块中具有目标地址的数据包（在环回以外的接口上接收）应被静默丢弃。在任何接口（环回除外）上接收的数据包，其源地址与接收数据包的系统对应，也应丢弃。
In all the above cases, when a packet is dropped, this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
在上述所有情况下，当数据包被丢弃时，应记录此事件（例如，可增加计数器以反映数据包丢弃）。
This document discusses the security implications of the Internet Protocol (IP) and a number of implementation strategies that help to mitigate a number of vulnerabilities found in the protocol during the last 25 years or so.
本文件讨论了互联网协议（IP）的安全含义以及一些实施策略，这些策略有助于缓解过去25年左右在协议中发现的一些漏洞。
The author wishes to thank Alfred Hoenes for providing very thorough reviews of earlier versions of this document, thus leading to numerous improvements.
作者希望感谢Alfred Hoenes对本文件的早期版本进行了非常彻底的审查，从而带来了许多改进。
The author would like to thank Jari Arkko, Ron Bonica, Stewart Bryant, Adrian Farrel, Joel Jaeggli, Warren Kumari, Bruno Rohee, and Andrew Yourtchenko for providing valuable comments on earlier versions of this document.
作者要感谢贾里·阿尔科、罗恩·博尼卡、斯图尔特·布莱恩特、阿德里安·法雷尔、乔尔·贾格利、沃伦·库马里、布鲁诺·罗希和安德鲁·尤琴科对本文件早期版本提供了宝贵的意见。
This document was written by Fernando Gont on behalf of the UK CPNI (United Kingdom's Centre for the Protection of National Infrastructure), and is heavily based on the "Security Assessment of the Internet Protocol" [CPNI2008] published by the UK CPNI in 2008.
本文件由Fernando Gont代表英国CPNI（英国国家基础设施保护中心）编写，主要基于英国CPNI于2008年发布的“互联网协议安全评估”[CPNI2008]。
The author would like to thank Randall Atkinson, John Day, Juan Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka Savola, and Christos Zoulas for providing valuable comments on earlier versions of [CPNI2008], on which this document is based.
作者感谢Randall Atkinson、John Day、Juan Fraschini、Roque Gagliano、Guillermo Gont、Martin Marino、Pekka Savola和Christos Zoulas对本文件所依据的[CPNI2008]早期版本提出了宝贵意见。
The author would like to thank Randall Atkinson and Roque Gagliano, who generously answered a number of questions.
作者要感谢Randall Atkinson和Roque Gagliano，他们慷慨地回答了许多问题。
Finally, the author would like to thank UK CPNI (formerly NISCC) for their continued support.
最后，作者要感谢英国CPNI（前NISCC）的持续支持。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC0826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[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", RFC 1108, November 1991.
[RFC1108]肯特，S.，“美国”，RFC11081991年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[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月。
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[RFC1349]Almquist，P.，“互联网协议套件中的服务类型”，RFC1349，1992年7月。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393]Malkin，G.“使用IP选项的跟踪路由”，RFC 1393，1993年1月。
[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
[RFC1770]Graff，C.，“发送方定向多目的地交付的IPv4选项”，RFC1770，1995年3月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[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月。
[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月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[RFC2644]Senie，D.，“更改路由器中定向广播的默认设置”，BCP 34，RFC 2644，1999年8月。
[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月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[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月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[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月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]Cotton，M.和L.Vegoda，“特殊用途IPv4地址”，BCP 153，RFC 57352010年1月。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.
[RFC6040]Briscoe，B.，“明确拥塞通知的隧道挖掘”，RFC 60402010年11月。
[Anderson2001] Anderson, J., "An Analysis of Fragmentation Attacks", 2001, <http://www.ouah.org/fragma.html>.
[Anderson 2001]Anderson，J.，“碎片攻击分析”，2001年<http://www.ouah.org/fragma.html>.
[Arkin2000] Arkin, "IP TTL Field Value with ICMP (Oops - Identifying Windows 2000 again and more)", 2000, <http://ofirarkin.files.wordpress.com/2008/11/ ofirarkin2000-06.pdf>.
[Arkin，2000]Arkin，“具有ICMP的IP TTL字段值（Oops-再次识别Windows 2000和更多）”，2000<http://ofirarkin.files.wordpress.com/2008/11/ Ofirakin2000-06.pdf>。
[Barisani2006] Barisani, A., "FTester - Firewall and IDS testing tool", 2001, <http://dev.inversepath.com/trac/ftester>.
[Barisani 2006]Barisani，A.，“FTester-防火墙和IDS测试工具”，2001年<http://dev.inversepath.com/trac/ftester>.
[Bellovin1989] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review Vol. 19, No. 2, pp. 32-48, 1989.
[Bellovin1989]Bellovin，S.，“TCP/IP协议套件中的安全问题”，《计算机通信评论》第19卷，第2期，第32-48页，1989年。
[Bellovin2002] Bellovin, S., "A Technique for Counting NATted Hosts", IMW'02 Nov. 6-8, 2002, Marseille, France, 2002.
[Bellovin2002]Bellovin，S.，“计算NATted宿主的技术”，IMW'02，2002年11月6-8日，法国马赛，2002年。
[Bendi1998] Bendi, "Bonk exploit", 1998, <http://www.insecure.org/sploits/ 95.NT.fragmentation.bonk.html>.
[Bendi1998]Bendi，“邦克剥削”，1998年<http://www.insecure.org/sploits/ 95.NT.fragmentation.bonk.html>。
[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>.
[CERT1996a] CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of-Service Attack", 1996, <http://www.cert.org/advisories/CA-1996-01.html>.
[CERT1996a]证书，“证书咨询CA-1996-01：UDP端口拒绝服务攻击”，1996年<http://www.cert.org/advisories/CA-1996-01.html>.
[CERT1996b] CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP Spoofing Attacks", 1996, <http://www.cert.org/advisories/CA-1996-21.html>.
[CERT1996b]CERT，“CERT咨询CA-1996-21：TCP SYN洪泛和IP欺骗攻击”，1996年<http://www.cert.org/advisories/CA-1996-21.html>.
[CERT1996c] CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack via ping", 1996, <http://www.cert.org/advisories/CA-1996-26.html>.
[CERT1996c]CERT，“CERT咨询CA-1996-26：通过ping的拒绝服务攻击”，1996年<http://www.cert.org/advisories/CA-1996-26.html>.
[CERT1997] CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service Attacks", 1997, <http://www.cert.org/advisories/CA-1997-28.html>.
[CERT 1997]CERT，“CERT咨询CA-1997-28：IP拒绝服务攻击”，1997年<http://www.cert.org/advisories/CA-1997-28.html>.
[CERT1998a] CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of-Service Attacks", 1998, <http://www.cert.org/advisories/CA-1998-01.html>.
[CERT1998a]证书，“证书咨询CA-1998-01:Smurf IP拒绝服务攻击”，1998年<http://www.cert.org/advisories/CA-1998-01.html>.
[CERT1998b] CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain TCP/IP Implementations", 1998, <http://www.cert.org/advisories/CA-1998-13.html>.
[CERT1998b]CERT，“证书咨询CA-1998-13：某些TCP/IP实施中的漏洞”，1998年<http://www.cert.org/advisories/CA-1998-13.html>.
[CERT1999] CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools", 1999, <http://www.cert.org/advisories/CA-1999-17.html>.
[CERT1999]CERT，“CERT咨询CA-1999-17：拒绝服务工具”，1999年<http://www.cert.org/advisories/CA-1999-17.html>.
[CERT2003] CERT, "CERT Advisory CA-2003-15: Cisco IOS Interface Blocked by IPv4 Packet", 2003, <http://www.cert.org/advisories/CA-2003-15.html>.
[CERT2003]证书，“证书咨询CA-2003-15：IPv4数据包阻止的Cisco IOS接口”，2003年<http://www.cert.org/advisories/CA-2003-15.html>.
[CIPSO1992] CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", Work in Progress, 1992.
[CIPSO1992]CIPSO，“商业IP安全选项（CIPSO 2.2）”，正在进行的工作，1992年。
[CIPSOWG1994] CIPSOWG, "Commercial Internet Protocol Security Option (CIPSO) Working Group", 1994, <http://www.ietf.org/ proceedings/94jul/charters/cipso-charter.html>.
[CIPSOWG1994]CIPSOWG，“商业互联网协议安全选项（CIPSO）工作组”，1994年<http://www.ietf.org/ 会议记录/94jul/charters/cipso charter.html>。
[CPNI2008] Gont, F., "Security Assessment of the Internet Protocol", 2008, <http://www.cpni.gov.uk/Docs/InternetProtocol.pdf>.
[CPNI2008]Gont，F.，“互联网协议的安全评估”，2008年<http://www.cpni.gov.uk/Docs/InternetProtocol.pdf>.
[Cerf1974] Cerf, V. and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications Vol. 22, No. 5, May 1974, pp. 637-648, 1974.
[Cerf1974]Cerf，V.和R.Kahn，“分组网络内部通信协议”，IEEE通信交易卷22，第5期，1974年5月，第637-6481974页。
[Cisco2003] Cisco, "Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 packet", 2003, <http://www.cisco.com/en/ US/products/ products_security_advisory09186a00801a34c2.shtml>.
[Cisco 2003]Cisco，“Cisco安全咨询：被IPv4数据包阻止的Cisco IOS接口”，2003年<http://www.cisco.com/en/ 美国/产品/产品安全咨询09186A00801A34C2.shtml>。
[Cisco2008] Cisco, "Cisco IOS Security Configuration Guide, Release 12.2", 2003, <http://www.cisco.com/en/US/docs/ios/12_2/ security/configuration/guide/scfipso.html>.
[Cisco 2008]Cisco，“Cisco IOS安全配置指南，12.2版”，2003年<http://www.cisco.com/en/US/docs/ios/12_2/ security/configuration/guide/scfipso.html>。
[Clark1988] Clark, D., "The Design Philosophy of the DARPA Internet Protocols", Computer Communication Review Vol. 18, No. 4, 1988.
[Clark1988]Clark，D.，“DARPA互联网协议的设计哲学”，《计算机通信评论》第18卷，第4期，1988年。
[Ed3f2002] Ed3f, "Firewall spotting and networks analysis with a broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c, Phile #0x0c of 0x10, 2002, <http://www.phrack.org/ issues.html?issue=60&id=12&mode=txt>.
[Ed3f2002]Ed3f，“在CRC损坏的情况下发现防火墙和进行网络分析”，Phrack杂志，第0x0b卷，第0x3c期，Phile#0x0c，第0x10期，2002年<http://www.phrack.org/ issues.html？issue=60&id=12&mode=txt>。
[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酒吧188，1994<http://csrc.nist.gov/publications/fips/ fips188/fips188.pdf>。
[Fyodor2004] Fyodor, "Idle scanning and related IP ID games", 2004, <http://www.insecure.org/nmap/idlescan.html>.
[Fyodor 2004]Fyodor，“空闲扫描和相关IP ID游戏”，2004年<http://www.insecure.org/nmap/idlescan.html>.
[GIAC2000] GIAC, "Egress Filtering v 0.2", 2000, <http://www.sans.org/y2k/egress.htm>.
[GIAC2000]GIAC，“出口过滤V0.2”，2000年<http://www.sans.org/y2k/egress.htm>.
[Gont2006] Gont, F., "Advanced ICMP packet filtering", 2006, <http://www.gont.com.ar/papers/icmp-filtering.html>.
[Gont2006]Gont，F.，“高级ICMP包过滤”，2006年<http://www.gont.com.ar/papers/icmp-filtering.html>.
[Haddad2004] Haddad, I. and M. Zakrzewski, "Security Distribution for Linux Clusters", Linux Journal, 2004, <http://www.linuxjournal.com/article/6943>.
[Haddad2004]Haddad，I.和M.Zakrzewski，“Linux集群的安全分发”，Linux杂志，2004年<http://www.linuxjournal.com/article/6943>.
[Humble1998] Humble, "Nestea exploit", 1998, <http://www.insecure.org/sploits/ linux.PalmOS.nestea.html>.
[Humble1998]Humble，“Nestea剥削”，1998年<http://www.insecure.org/sploits/ linux.PalmOS.nestea.html>。
[IANA_ET] IANA, "Ether Types", <http://www.iana.org/assignments/ethernet-numbers>.
[IANA_ET]IANA，“乙醚类型”<http://www.iana.org/assignments/ethernet-numbers>.
[IANA_IP_PARAM] IANA, "IP Parameters", <http://www.iana.org/assignments/ip-parameters>.
[IANA_IP_PARAM]IANA，“IP参数”<http://www.iana.org/assignments/ip-parameters>.
[IANA_PROT_NUM] IANA, "Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.
[IANA_PROT_NUM]IANA，“协议编号”<http://www.iana.org/assignments/protocol-numbers>.
[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>。
[Jones2002] Jones, R., "A Method Of Selecting Values For the Parameters Controlling IP Fragment Reassembly", 2002, <ftp://ftp.cup.hp.com/dist/networking/briefs/ ip_reass_tuning.txt>.
[Jones2002]Jones，R.“为控制IP片段重组的参数选择值的方法”，2002年<ftp://ftp.cup.hp.com/dist/networking/briefs/ ip\u resa\u tuning.txt>。
[Kenney1996] Kenney, M., "The Ping of Death Page", 1996, <http://www.insecure.org/sploits/ping-o-death.html>.
[Kenney1996]Kenney，M.，“死亡页的平”，1996年<http://www.insecure.org/sploits/ping-o-death.html>.
[Kent1987] Kent, C. and J. Mogul, "Fragmentation considered harmful", Proc. SIGCOMM '87 Vol. 17, No. 5, October 1987, 1987.
[Kent 1987]Kent，C.和J.Mogul，“碎片被认为是有害的”，Proc。SIGCOMM'87第17卷，第5期，1987年10月，1987年。
[Klein2007] Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability", 2007, <http://www.trusteer.com/files/ OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP _ID_Vulnerability.pdf>.
[Klein2007]Klein，A.，“OpenBSD DNS缓存中毒和多O/S可预测IP ID漏洞”，2007年<http://www.trusteer.com/files/ OpenBSD\u DNS\u缓存\u中毒\u和\u多个\u操作系统\u可预测的\u IP\u ID\u漏洞。pdf>。
[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年。
[LBNL2006] LBNL/NRG, "arpwatch tool", 2006, <http://ee.lbl.gov/>.
[LBNL2006]LBNL/NRG，“arpwatch工具”，2006年<http://ee.lbl.gov/>.
[Linux] Linux Kernel Organization, "The Linux Kernel Archives", <http://www.kernel.org>.
[Linux]Linux内核组织，“Linux内核档案”<http://www.kernel.org>.
[Microsoft1999] Microsoft, "Microsoft Security Program: Microsoft Security Bulletin (MS99-038). Patch Available for "Spoofed Route Pointer" Vulnerability", 1999, <http://www.microsoft.com/ technet/security/bulletin/ms99-038.mspx>.
[Microsoft1999]Microsoft，“Microsoft安全计划：Microsoft安全公告（MS99-038）”。可用于“伪造路由指针”漏洞的修补程序，1999<http://www.microsoft.com/ technet/security/bulletin/ms99-038.mspx>。
[NISCC2004] NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability Issues in TCP", 2004, <http://www.cpni.gov.uk>.
[NISCC2004]NISCC，“NISCC漏洞咨询236929：TCP中的漏洞问题”，2004年<http://www.cpni.gov.uk>.
[NISCC2005] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: Vulnerability Issues in ICMP packets with TCP payloads", 2005, <http://www.gont.com.ar/advisories/index.html>.
[NISCC2005]NISCC，“NISCC漏洞咨询532967/NISCC/ICMP：具有TCP有效负载的ICMP数据包中的漏洞问题”，2005年<http://www.gont.com.ar/advisories/index.html>.
[NISCC2006] NISCC, "NISCC Technical Note 01/2006: Egress and Ingress Filtering", 2006, <http://www.cpni.gov.uk>.
[NISCC2006]NISCC，“NISCC技术说明01/2006：进出口过滤”，2006年<http://www.cpni.gov.uk>.
[Northcutt2000] Northcut, S. and Novak, "Network Intrusion Detection - An Analyst's Handbook", Second Edition New Riders Publishing, 2000.
[Northcut2000]Northcut，S.和Novak，“网络入侵检测-分析人员手册”，第二版新骑手出版社，2000年。
[Novak2005] Novak, "Target-Based Fragmentation Reassembly", 2005, <http://www.snort.org/assets/165/target_based_frag.pdf>.
[Novak2005]Novak，“基于目标的碎片重组”，2005年<http://www.snort.org/assets/165/target_based_frag.pdf>.
[OpenBSD-PF] Sanfilippo, S., "PF: Scrub (Packet Normalization)", 2010, <ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf>.
[OpenBSD PF]Sanfilippo，S.，“PF:Scrub（数据包规范化）”，2010年<ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf>.
[OpenBSD1998] OpenBSD, "OpenBSD Security Advisory: IP Source Routing Problem", 1998, <http://www.openbsd.org/advisories/sourceroute.txt>.
[OpenBSD1998]OpenBSD，“OpenBSD安全咨询：IP源路由问题”，1998年<http://www.openbsd.org/advisories/sourceroute.txt>.
[Paxson2001] Paxson, V., Handley, M., and C. Kreibich, "Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics", USENIX Conference, 2001.
[Paxson 2001]Paxson，V.，Handley，M.，和C.Kreibich，“网络入侵检测：规避，流量规范化和端到端协议语义”，USENIX会议，2001年。
[Ptacek1998] Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection", 1998, <http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps>.
[Ptacek1998]Ptacek，T.和T.Newsham，“插入、规避和拒绝服务：逃避网络入侵检测”，1998年<http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps>.
[RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, July 1982.
[RFC0815]Clark，D.，“IP数据报重组算法”，RFC 815，1982年7月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858]Ziemba，G.，Reed，D.，和P.Trana，“IP片段过滤的安全考虑”，RFC 1858，1995年10月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC2544]Bradner，S.和J.McQuaid，“网络互连设备的基准测试方法”，RFC 2544，1999年3月。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3128]Miller，I.，“防止微小碎片攻击的变体（RFC 1858）”，RFC 31281001年6月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530]Shepler，S.，Callaghan，B.，Robinson，D.，Thurlow，R.，Beame，C.，Eisler，M.，和D.Noveck，“网络文件系统（NFS）版本4协议”，RFC 3530，2003年4月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963]Heffner，J.，Mathis，M.，和B.Chandler，“高数据速率下的IPv4重组错误”，RFC 4963，2007年7月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，2007年8月。
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559]Eardley，P.，“拥塞前通知（PCN）体系结构”，RFC555592009年6月。
[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月。
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670]Eardley，P.，“PCN节点的计量和标记行为”，RFC 56702009年11月。
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009.
[RFC5696]Moncaster，T.，Briscoe，B.，和M.Minth，“拥堵前信息的基线编码和传输”，RFC 56962009年11月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927]Gont，F.，“针对TCP的ICMP攻击”，RFC 5927，2010年7月。
[ROUTER-ALERT] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", Work in Progress, June 2011.
[路由器警报]Le Faucheur，F.，Ed.，“IP路由器警报注意事项和使用”，正在进行的工作，2011年6月。
[SELinux2009] NSA, "Security-Enhanced Linux", <http://www.nsa.gov/research/selinux/>.
[SELinux2009]NSA，“安全增强型Linux”<http://www.nsa.gov/research/selinux/>.
[Sanfilippo1998a] Sanfilippo, S., "about the ip header id", Post to Bugtraq mailing-list, Mon Dec 14 1998, <http://www.kyuzz.org/antirez/papers/ipid.html>.
[Sanfilippo1998a]Sanfilippo，S.，“关于ip头id”，发布到Bugtraq邮件列表，1998年12月14日，周一<http://www.kyuzz.org/antirez/papers/ipid.html>.
[Sanfilippo1998b] Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1998, <http://www.kyuzz.org/antirez/papers/dumbscan.html>.
[Sanfilippo1998b]Sanfilippo，S.，“空闲扫描”，发布到Bugtraq邮件列表，1998年<http://www.kyuzz.org/antirez/papers/dumbscan.html>.
[Sanfilippo1999] Sanfilippo, S., "more ip id", Post to Bugtraq mailing-list, 1999, <http://www.kyuzz.org/antirez/papers/moreipid.html>.
[Sanfilippo1999]Sanfilippo，S.，“更多ip id”，发布到Bugtraq邮件列表，1999年<http://www.kyuzz.org/antirez/papers/moreipid.html>.
[Shankar2003] Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS Evasion Without Altering Traffic", 2003, <http://www.icir.org/vern/papers/activemap-oak03.pdf>.
[Shankar2003]Shankar，U.和V.Paxson，“主动测绘：在不改变流量的情况下抵抗NIDS规避”，2003年<http://www.icir.org/vern/papers/activemap-oak03.pdf>.
[Shannon2001] Shannon, C., Moore, D., and K. Claffy, "Characteristics of Fragmented IP Traffic on Internet Links", 2001.
[Shannon 2001]Shannon，C.，Moore，D.，和K.Claffy，“互联网链接上碎片化IP流量的特征”，2001年。
[Silbersack2005] Silbersack, M., "Improving TCP/IP security through randomization without sacrificing interoperability", EuroBSDCon 2005 Conference, 2005, <http://www.silby.com/eurobsdcon05/eurobsdcon_slides.pdf>.
[Silbersack 2005]Silbersack，M.，“通过随机化改进TCP/IP安全性，而不牺牲互操作性”，EuroBSDCon 2005年会议，2005年<http://www.silby.com/eurobsdcon05/eurobsdcon_slides.pdf>.
[Snort] Sourcefire, Inc., "Snort", <http://www.snort.org>.
[Snort]Sourcefire，Inc.，“Snort”<http://www.snort.org>.
[Solaris2007] Oracle, "ORACLE SOLARIS WITH TRUSTED EXTENSIONS", 2007, <h ttp://www.oracle.com/us/products/servers-storage/solaris/ solaris-trusted-ext-ds-075583.pdf>.
[Solaris2007]Oracle，“带可信扩展的Oracle SOLARIS”，2007，<http://www.oracle.com/us/products/servers-storage/solaris/ solaris-trusted-ext-ds-075583.pdf>。
[Song1999] Song, D., "Frag router tool", <http://www.monkey.org/~dugsong/fragroute/>.
[Song1999]Song，D.，“Frag路由器工具”<http://www.monkey.org/~dugsong/fragroute/>。
[SpooferProject] MIT ANA, "Spoofer Project", 2010, <http://spoofer.csail.mit.edu/index.php>.
[Spoofer项目]麻省理工学院全日空，“Spoofer项目”，2010年<http://spoofer.csail.mit.edu/index.php>.
[US-CERT2001] US-CERT, "US-CERT Vulnerability Note VU#446689: Check Point FireWall-1 allows fragmented packets through firewall if Fast Mode is enabled", 2001, <http://www.kb.cert.org/vuls/id/446689>.
[US-CERT2001]US-CERT，“US-CERT漏洞说明VU#446689：检查点防火墙-1在启用快速模式的情况下允许碎片数据包通过防火墙”，2001<http://www.kb.cert.org/vuls/id/446689>.
[US-CERT2002] US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS discloses fragments of previous packets when Express Forwarding is enabled", 2002.
[US-CERT2002]US-CERT，“US-CERT漏洞说明VU#310387:Cisco IOS在启用快速转发时披露以前数据包的碎片”，2002年。
[Watson2004] Watson, P., "Slipping in the Window: TCP Reset Attacks", CanSecWest Conference, 2004.
[Watson2004]Watson，P.，“在窗口中滑动：TCP重置攻击”，CanSecWest会议，2004年。
[Zakrzewski2002] Zakrzewski, M. and I. Haddad, "Linux Distributed Security Module", 2002, <http://www.linuxjournal.com/article/6215>.
[Zakrzewski2002]Zakrzewski，M.和I.Haddad，“Linux分布式安全模块”，2002年<http://www.linuxjournal.com/article/6215>.
[daemon91996] daemon9, route, and infinity, "IP-spoofing Demystified (Trust-Relationship Exploitation)", Phrack Magazine, Volume Seven, Issue Forty-Eight, File 14 of 18, 1988, <htt p://www.phrack.org/issues.html?issue=48&id=14&mode=txt>.
[daemon91996]daemon9，route and infinity，“IP欺骗解密（信任关系利用）”，Phrack杂志，第七卷，第四十八期，1988年第14期，第18期文件，<htt p://www.Phrack.org/issues.html？Issue=48&id=14&mode=txt>。
Author's Address
作者地址
Fernando Gont UK Centre for the Protection of National Infrastructure
费尔南多·贡特英国国家基础设施保护中心
EMail: fernando@gont.com.ar
URI: http://www.cpni.gov.uk
EMail: fernando@gont.com.ar
URI: http://www.cpni.gov.uk