[要約] RFC 6592は、ネットワーク通信におけるNullパケットの定義と使用方法について説明しています。目的は、ネットワークの効率化とパフォーマンスの向上を図るために、Nullパケットの適切な使用方法を提案することです。
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.
絶え間ないNullパケットは、RFCシリーズのドキュメントで多くの言及を受けましたが、明示的に定義されたことはありません。このメモはその省略を修正します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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
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.
ヌルパケットは、受信されない場合は送信も確認もされません。それらは単純さにおいて完璧であり、ネットワーキングの12番目の真実[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".
Nullパケットの初期の言及は、TCP / IPヘッダー圧縮[RFC1144]のコンテキストでVan Jacobsonによるものです。心に留めておきますが、Nullパケットは、パケットが何もなくなるまで圧縮することによっては作成されません。このような圧縮スキームは元に戻せない場合があります。代わりに、[RFC1144]のセクション3.2.4は、「何も（nullパケット）が返されない」という明示的な応答の欠如を説明しています。
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）を定義しようとしています。しかし、そのような運動は無駄です。このメモは、プロトコル構造または値の存在がnullをnullにするため、nullパケットは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を参照）では、Nullパケットは作成されません。
The Null Packet is a zero-dimensional packet. The Null Packet exists since it is non-self-contradictorily definable.
ヌルパケットはゼロ次元パケットです。 Nullパケットは、自己矛盾なく定義できるため存在します。
[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.
多くの専門家は、Nullパケットの存在を証明できないことに直面したときの合理化の試みにおいて、Nullパケットを想像上のパケットと単純に混同しています。参考までに、想像上のパケットには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]).
Nullパケットを送信するプロトコルは、長さがゼロのパケットを効果的に送信します。ヌルパケットトラフィックのフローストリームの特徴の1つは、ヌルパケットの送信レートを上げても、ヌルパケットトラフィックのビットレートが上がらないことです。単位時間あたり無数のNullパケットを送信できない限り、ビットレートは明白にnullのままです。同様に、ユーザーがNullパケットの送信を停止しても、Nullパケットのビットレートは変化しません。従来のトラフィックパフォーマンスメトリックは、ヌルパケットトラフィックの認定にはあまり適していません。この事実は、「有用性」のテストで肯定的なパフォーマンスメトリックの新しいセットの作成を主張しています（[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）環境で使用される場合、Nullパケットは暗黙的NULLラベルのみを使用できます（[RFC3031]のセクション4.1.5を参照）。暗黙的NULLラベルは、配布できるが実際には表示されないラベルです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.
ここで説明するように、ヌルパケットのセキュリティに関する考慮事項は定義されていません。 Nullパケットの「良い」性質はまったく役に立たず、Nullパケットの「悪い」性質はかなり非効率的です。
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"?
多くのファイアウォールやその他のセキュリティデバイスは、Nullパケットを識別できません。また、Nullパケットを非常に効果的かつ簡単に除外できると主張する人もいます。興味深いことに、両方とも正しいかもしれませんが、これは全能のパラドックスを引き起こします：ファイアウォールは、「外部」からのNullパケットをフィルターで除外し、「内部」でNullパケットが許可されないようにするルールを作成できますか？
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.
Nullパケットは、定義上、Evil Bit（ "E"）[RFC3514]を設定できません（セクション2.1を参照）。したがって、Nullパケットが無害であり、悪意がないことは明らかであり、否定できません。
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」のほとんどすべての値に対して、「fooを暗号化する」ステートメントを包括することです。このドキュメントも例外ではありません。ただし、NULL暗号化[RFC2410]をNullパケットに適用しないように外科的注意を払う必要があります。そのような不注意な行為は、ゼロによる除算や「Google」という単語のグーグルよりも不連続性と「おっと」をより叙事詩にする可能性があります（そのような行為はインターネットを破壊する可能性があると噂されていますが、これは不条理によって簡単に反証される可能性があります）。
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).
sysadmins、netadmins、secadmins、およびその他のNOCエンジニアがNullパケットをブロックする明白な不可能性に直面している場合でも（セクション4.1を参照）、Nullパケットを利用した攻撃はそれほど一般的ではなく、seek ^ Wsecurityニュースには見られません。これらの異常なパケットがデータプレーンでスプーフィングするのが難しいか、存続時間（TTL）またはホップリミットが存在しないため変更できないため[RFC5082]、Nullパケットがサービス（DoDoS）。
An important corollary is that dropping Null Packets does not generate packets.
重要な結果として、Nullパケットをドロップしてもパケットは生成されません。
This document explicitly and emphatically, yet very humbly, requests IANA to not create an empty registry for the Null Packet.
このドキュメントは、明示的かつ強調的に、しかし非常に謙虚に、NANAパケット用の空のレジストリを作成しないようIANAに要求しています。
[NULL] "".
[ヌル] ""。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144] Jacobson、V。、「低速シリアルリンクのTCP / IPヘッダーの圧縮」、RFC 1144、1990年2月。
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1996.
[RFC1925] Callon、R。、「The Twelve Networking Truths」、RFC 1925、1996年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、「NULL暗号化アルゴリズムと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]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年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.、Clauseen、H.、Collini-Nocker、B。、およびH. Linder、「A MPEG Frameworkを介した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。、「サブネットワークカプセル化および適応層（SEAL）」、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 6390、2011年10月。
Author's Address
著者のアドレス
Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Carlos Pignataro Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709 US
EMail: cpignata@cisco.com