INFORMATIONAL

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. 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. 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. 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. Pignataro Informational [Page 1]

RFC 6592 The Null Packet 1 April 2012 4.1 . The Paradoxical Firewall 4.2 . The Null Packet is Good 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. 4.3 . Just Encrypt It, Carefully 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.) 4.4 . Denial of Denial of Service 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). An important corollary is that dropping Null Packets does not generate packets. 5 . IANA Considerations Pignataro Informational [Page 4]

RFC 6592 The Null Packet 1 April 2012