はじめに
- この文書は RFC6592 を勉強と好奇心のため適当に訳したものです。
- 翻訳の正確さは全く保証しません。
- 誤字誤訳等の指摘はいつでも大歓迎です。
The Null Packet（NULL パケット）
- Independent Submission
- Request for Comments: 6592
- Category: Informational
- ISSN: 2070-1721
- C. Pignataro
- Cisco
- 1 April 2012
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.
この文書は、インターネット標準過程の仕様ではなく、情報提供を目的として公開されている。
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 エディターによって公開が承認された文書は、どのレベルのインターネット標準の候補にもならない。
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.
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.
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（序論）
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.
NULL パケットは、送信もしなければ、受信もしない。
ネットワークにおける 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).
多くの文書が NULL パケットのための通信用コードポイントとプロトコル識別子 (PID) を定義しようと試みている [RFC4259] [RFC4571] [RFC5320]。
しかし、このような作業は無駄である。
このメモでは、プロトコルの構成要素や値が存在すると NULL が無効になるため、NULL パケットは PID を持てないということを前提とする。
これは、0x0、0x0000、あるいは 0x000000 を使用できないことを含み、しかし "" を使用するという制限は除外する（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 Next Headerの値が 59 (No Next Header) ([RFC2460] の4.7節を参照) の場合、NULL パケットは生成されない。
2. The Null Packet（NULL パケット）
The Null Packet is a zero-dimensional packet.
The Null Packet exists since it is non-self-contradictorily definable.
NULL パケットは 0 次元のパケットである。
NULL パケットは自己矛盾なく定義可能であるため、存在する。
2.1. Formal Definition（正式な定義）
[This section is intentionally left blank, see also Section 0 of [NULL].]
［このセクションは意図的に空白にしてある。[NULL] の 0 章も参照すること。］
2.2. Faux Amis（偽の友達）
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 Version が含まれている。
しかし、プロトコルの純粋主義者は騙されず、すぐに専門家に申し立て、現実（訳注：実数？）を得る。
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").
NULL パケットはパケットを廃棄しないので、NULL パケットの特質をビットバケットのブラックホールと混同してはならない。
混乱は、 /dev/null から読み込む入力ストリームの動作と似ている (すなわち、「何も返さない」) という事実から生じるかもしれない。
3. Performance Metrics Considerations（パフォーマンスメトリクスの考慮事項）
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 パケットを送信するプロトコルは、実質的に長さ 0 のパケットを送信する。
NULL パケット伝送のフローストリームの特徴のひとつは、NULL パケットを送信するレートを上げても、NULL パケット伝送のビットレートが上がらないことである。
単位時間あたりに無限の NULL パケット が送信されないかぎり、ビットレートは明確に NULL でありつづける。
同様に、ユーザーが NULL パケットの送信を停止しても、NULL パケットのビットレートは変化しない。
この事実は、「有用性」([RFC6390] の5.2節参照) を肯定的にテストする新しいパフォーマンスメトリクスのセットを作成することを主張するものである。
4. Security Considerations（セキュリティに関する考慮事項）
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 (Multiprotocol Label Switching) 環境で使用する場合、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 パケットの「良い」性質はかなり無駄であり、NULL パケットの「悪い」性質はかなり非効率的である。
4.1. The Paradoxical Firewall（逆説的ファイアウォール）
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 パケットをフィルタリングしないようにするルールを作ることができるだろうか？
4.2. The Null Packet is Good（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 パケットは悪意がなく無害であることは、むしろ明確であり、否定できるものではない。
4.3. Just Encrypt It, Carefully（暗号化は慎重に）
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" ステートメントを包括的にラップすることである。
この文書も例外ではない。
しかし、NULL パケットに NULL 暗号化 [RFC2410] を適用しないよう、細心の注意を払わなければならない。
このような不注意な行為は、ゼロで割ったり、「Google」という単語をググるよりも壮大な不連続性と、「おっと」（注：失敗）をもたらす (この行為は、還元論不条理によって容易に反証できるが、インターネットを破壊できるという噂がある)。
4.4. Denial of Denial of Service（サービス妨害の妨害）
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).
システム管理者、ネットワーク管理者、セキュリティ管理者、およびその他の NOC エンジニアが NULL パケットをブロックすることができないという議論の余地のない状況に直面しても (4.1 節参照)、NULL パケットを活用した攻撃はそれほど多く出回っておらず、seek、もといセキュリティニュースでも目にすることはない。
おそらく、これらの異常なパケットはデータプレーンでなりすますのが難しいため、またはその TTL (Time To Live) または Hop Limit が存在しないせいで変更できないため [RFC5082]、NULL パケットがサービス妨害の妨害 (DoDoS) を引き起こすことは事実である。
An important corollary is that dropping Null Packets does not generate packets.
重要な補足は、Null Packets をドロップしてもパケットは生成されない。
5. IANA Considerations（IANAに関する考慮事項）
This document explicitly and emphatically, yet very humbly, requests IANA to not create an empty registry for the Null Packet.
この文書は、NULL パケットのための空のレジストリを作成しないよう、IANA に明示的かつ強調的に、しかし非常に謙虚に要請するものである。
6. References
6.1. Normative References
[NULL] "".
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed
serial links", RFC 1144, February 1990.
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1996.
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, April 1 2003.
6.2. Informative References
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[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.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[RFC5320] Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", RFC 5320, February 2010.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
October 2011.
Author's Address
Carlos Pignataro
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
EMail: cpignata@cisco.com