Independent Submission C. Pignataro
Request for Comments: 6592 Cisco
Category: Informational 1 April 2012
ISSN: 2070-1721
Independent Submission C. Pignataro
Request for Comments: 6592 Cisco
Category: Informational 1 April 2012
ISSN: 2070-1721
The Null Packet
空包
Abstract
摘要
The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined. This memo corrects that omission.
在RFC系列的文档中，曾经难以捉摸的Null数据包多次被提及，但它从未被明确定义。这份备忘录纠正了这一遗漏。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc6592.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6592.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Null Packet . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Formal Definition . . . . . . . . . . . . . . . . . . . . . 3
2.2. Faux Amis . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Performance Metrics Considerations . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3
4.1. The Paradoxical Firewall . . . . . . . . . . . . . . . . . 4
4.2. The Null Packet is Good . . . . . . . . . . . . . . . . . . 4
4.3. Just Encrypt It, Carefully . . . . . . . . . . . . . . . . 4
4.4. Denial of Denial of Service . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Null Packet . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Formal Definition . . . . . . . . . . . . . . . . . . . . . 3
2.2. Faux Amis . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Performance Metrics Considerations . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3
4.1. The Paradoxical Firewall . . . . . . . . . . . . . . . . . 4
4.2. The Null Packet is Good . . . . . . . . . . . . . . . . . . 4
4.3. Just Encrypt It, Carefully . . . . . . . . . . . . . . . . 4
4.4. Denial of Denial of Service . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
Null Packets are neither sent nor acknowledged when not received. They are perfect in their simplicity and they are very true, as they extrapolate from the twelfth Truth of networking [RFC1925]: there is *literally* nothing left to take away.
空数据包在未接收时既不发送也不确认。它们在简单性上是完美的，它们是非常真实的，因为它们从第十二个网络真理[RFC1925]中推断：从字面上看，没有什么可以带走的。
An early mention of the Null Packet is attributed to Van Jacobson in the context of TCP/IP Header Compression [RFC1144]. Mind you, the Null Packet is not created by compressing a packet until it disappears into nothingness. Such a compression scheme might not be reversible; instead, Section 3.2.4 of [RFC1144] describes an explicit lack of response as "Nothing (a null packet) is returned".
在TCP/IP报头压缩[RFC1144]的上下文中，Van Jacobson较早地提到了空数据包。请注意，空数据包不是通过压缩数据包创建的，直到它消失为空。这样的压缩方案可能是不可逆的；相反，[RFC1144]的第3.2.4节将明确的响应缺失描述为“未返回任何内容（空数据包）”。
Many documents attempt to define in-the-wire code points and protocol identifiers (PIDs) for a Null Packet [RFC4259] [RFC4571] [RFC5320]. However, such an exercise is futile. This memo postulates that a Null Packet cannot have a PID, as the existence of a protocol construct or value would null the null; this includes the inability to use 0x0, 0x0000, or even 0x00000000, but excludes the restriction to use "" (see Section 2.1).
许多文档试图为空数据包[RFC4259][RFC4571][RFC5320]定义线代码点和协议标识符（PID）。然而，这种做法是徒劳的。此备忘录假定空数据包不能有PID，因为存在协议构造或值将使空数据包为空；这包括无法使用0x0、0x0000甚至0x00000000，但不包括使用“”的限制（参见第2.1节）。
An IPv6 Next Header value of 59 (No Next Header) (see Section 4.7 of [RFC2460]) does not create a Null Packet.
IPv6下一个报头值为59（无下一个报头）（参见[RFC2460]第4.7节）不会创建空数据包。
The Null Packet is a zero-dimensional packet. The Null Packet exists since it is non-self-contradictorily definable.
空数据包是零维数据包。空数据包存在，因为它是非自相矛盾的定义。
[This section is intentionally left blank, see also Section 0 of [NULL].]
[本节有意留空，另请参见[NULL]的第0节。]
Many experts naively confuse the Null Packet with an Imaginary Packet, in a rationalization attempt when faced with the inability to prove the existence of the Null Packet. For reference, an Imaginary Packet contains the IP Version of 4i or 6i. However, protocol purists are not fooled and quickly plea with experts to get real.
许多专家天真地将空数据包与虚构数据包混淆，试图在无法证明空数据包存在的情况下进行合理化。作为参考，虚拟数据包包含4i或6i的IP版本。然而，协议纯粹主义者并没有被愚弄，他们很快就请求专家们去实现。
The Null Packet's qualities should not be confused with the bit-bucket blackhole nature of the null device, since the Null Packet does not discard packets. Confusion might stem from the fact that the behavior is similar to that of input streams reading from /dev/ null (i.e., "nothing is returned").
空数据包的质量不应与空设备的位桶黑洞性质混淆，因为空数据包不会丢弃数据包。混淆可能源于这样一个事实，即该行为类似于从/dev/null读取输入流的行为（即“未返回任何内容”）。
A protocol sending Null Packets effectively sends packets of zero length. One characteristic of flow streams of Null Packet traffic is that increasing the rate at which Null Packets are sent does not increase the bit rate of the Null Packet traffic. The bit rate continues being unequivocally null, unless an infinite number of Null Packets per unit of time could be sent. Similarly, should a user stop sending Null Packets, the bit rate of Null Packets would not vary. Traditional traffic performance metrics are not well suited to qualify Null Packet traffic; this fact argues for the creation of new sets of performance metrics that test positive for "usefulness" (see Section 5.2 of [RFC6390]).
发送空数据包的协议有效地发送零长度的数据包。空分组业务流的一个特征是，增加空分组的发送速率不会增加空分组业务的比特率。除非每单位时间可以发送无限数量的空数据包，否则比特率仍然是明确的空数据包。类似地，如果用户停止发送空数据包，空数据包的比特率将不会改变。传统的流量性能指标不能很好地确定空包流量；这一事实支持创建新的性能指标集，对“有用性”进行正面测试（见[RFC6390]第5.2节）。
When used in a Multiprotocol Label Switching (MPLS) environment, the Null Packet can only use an Implicit NULL label (see Section 4.1.5 of [RFC3031]. The Implicit NULL label is a label that can be distributed, but which never actually appears in the encapsulation. The Nil FEC is not used.
在多协议标签交换（MPLS）环境中使用时，空数据包只能使用隐式空标签（请参见[RFC3031]第4.1.5节）。隐式空标签是一种可以分发的标签，但从未实际出现在封装中。不使用Nil FEC。
The security considerations for the Null Packet are undefined, as hereby described. The "good" nature of Null Packets is quite useless, and the "bad" nature of Null Packets is rather inefficient.
如本文所述，空数据包的安全注意事项未定义。空包的“好”性质是毫无用处的，而空包的“坏”性质是相当低效的。
Many firewalls and other security devices have trouble identifying the Null Packet. Others claim to filter out Null Packets quite effectively and effortlessly. Interestingly, or not, both might be correct, which begs the omnipotence paradox: Can a firewall create a rule to filter out the Null Packet coming from the "outside", and not see Null Packets being allowed on the "inside"?
许多防火墙和其他安全设备难以识别空数据包。其他人则声称可以非常有效且轻松地过滤掉空数据包。有趣的是，两者都可能是正确的，这就引出了全能悖论：防火墙能否创建一个规则来过滤来自“外部”的空包，而不在“内部”看到允许的空包？
The Null Packet cannot have the Evil Bit ("E") [RFC3514] set, by definition (see Section 2.1). Consequently, it is rather clear and undeniable that the Null Packet is harmless, having no evil intent.
根据定义，空数据包不能设置有害位（“E”）[RFC3514]（见第2.1节）。因此，空数据包是无害的，没有恶意，这是相当清楚和不可否认的。
A commonly accepted practice for Security Considerations sections is to wrap a blanket "encrypt around foo" statement, for almost any value of "foo". This document is no exception. However, surgical care must be taken to not apply NULL encryption [RFC2410] to the Null Packet; such a careless act can bring discontinuities and "Oops" more epic than dividing by zero or Googling the word "Google" (it has been rumored that such action can break the Internet, although this can be easily disproved by reductio ad absurdum.)
对于安全注意事项部分，一种普遍接受的做法是为几乎所有的“foo”值包装一个“encrypt-around-foo”语句。这份文件也不例外。但是，必须注意不要对空数据包应用空加密[RFC2410]；这种粗心的行为可能会带来不连续性和“哎哟”，比用零除或谷歌搜索“谷歌”这个词更具史诗色彩（有传言说，这种行为会破坏互联网，尽管这很容易被简化和荒谬所推翻。）
Even when sysadmins, netadmins, secadmins, and other NOC engineers are faced with the undisputed inability to block Null Packets (see Section 4.1), attacks leveraging Null Packets are not quite so common in the wild and are not seen in the seek^Wsecurity news. Perhaps because these unusual packets are hard to spoof in the data plane, or because their Time to Live (TTL) or Hop Limit cannot be altered since it does not exist [RFC5082], the fact is that Null Packets present a denial of denial of service (DoDoS).
即使系统管理员、netadmins、secadmins和其他NOC工程师面临着无法阻止空数据包的无可争议的问题（参见第4.1节），利用空数据包的攻击在野外也不太常见，在seek^Wsecurity新闻中也看不到。可能是因为这些不寻常的数据包很难在数据平面上进行欺骗，或者因为它们的生存时间（TTL）或跃点限制无法更改，因为它不存在[RFC5082]，事实上，空数据包表示拒绝服务（DoDoS）。
An important corollary is that dropping Null Packets does not generate packets.
一个重要的推论是丢弃空数据包不会生成数据包。
This document explicitly and emphatically, yet very humbly, requests IANA to not create an empty registry for the Null Packet.
本文档明确强调但非常谦虚地要求IANA不要为空数据包创建空注册表。
[NULL] "".
[NULL]“”。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP报头”，RFC1144，1990年2月。
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1996.
[RFC1925]卡隆，R.，“十二个网络真理”，RFC19251996年4月。
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003.
[RFC3514]Bellovin，S.，“IPv4报头中的安全标志”，RFC 3514，2003年4月1日。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC4259] Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005.
[RFC4259]Montpetit，M.，Fairhurst，G.，Clausen，H.，Collini Nocker，B.，和H.Linder，“通过MPEG-2网络传输IP数据报的框架”，RFC 4259，2005年11月。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571]Lazzaro，J.，“面向连接传输上的帧实时传输协议（RTP）和RTP控制协议（RTCP）数据包”，RFC 4571，2006年7月。
[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月。
[RFC5320] Templin, F., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010.
[RFC5320]Templin，F.“子网络封装和适配层（密封）”，RFC 5320，2010年2月。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
[RFC6390]Clark，A.和B.Claise，“考虑新性能指标开发的指南”，BCP 170，RFC 63902011年10月。
Author's Address
作者地址
Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
卡洛斯·皮格纳塔罗思科系统公司，美国北卡罗来纳州基特克里克路研究三角公园7200-12号，邮编：27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com