Die Spezifikationen zu den NULL-Paketen wurden im Request for Comments 6592 vom Autor C. Pignataro am 1. April 2012 veröffentlicht. In diesem Dokument versucht er der Natur der in zahlreichen TCP/IP-Dokumenten erwähnten NULL-Pakete auf die Spur zu kommen und korrigiert die gültige Lehrmeinung zu diesen Paketen indem er eine endgültige Spezifikation dieser Pakettypen veröffentlicht.
Eine erste Erwähnung der NULL-Pakete ist bei Van Jacobson im Dokument zur TCP/IP-Header-Komprimierung (RFC 1144) zu finden. Es ist zu beachten, dass ein NULL-Paket nicht durch Komprimieren eines Pakets bis zum Nichts entsteht. Eine solche Kompression wäre möglicherweise nicht reversibel, Der Abschnitt 3.2.4 im RFC 1144 beschreibt jedoch das explizite Ausbleiben einer Reaktion auf ein NULL- Paket.
In vielen weiteren Dokumenten wird versucht das Wesen der NULL-Pakete zu definieren, es werden für die Pakete sogar Code-Points und Protokoll-IDs ( PIDs ) festgelegt (siehe RFC 4259, RFC 4571, RFC 5320). Allerdings ist eine solche Übung sinnlos, da ein NULL-Paket eigentlich keine PID besitzen kann.
Auch der IPv6-Next-Header-Wert = 59 (No Next Header) (siehe Abschnitt 4.7 von RFC 2460) führt nicht zur Übermittlung eines echten NULL-Pakets.
Ein NULL-Paket ist somit ein nulldimensionales Paket. Trotzdem verwechseln viele Experten die NULL-Pakete mit imaginären Paketen. Imaginäre Pakete können jede Dimension annehmen und unterscheiden sich dadurch bereits von klassischen NULL-Paketen. Beispielsweise enthält ein imaginäres Paket die IP-Version 4i oder 6i.
Die NULL-Pakete sollten auch nicht mit der Funktion des Bit-Bucket-Blackholes des Null-Device verwechselt werden. Grund: die NULL-Pakete vernichten keine Pakete. Die Verwirrung könnte aus der Tatsache herrühren, dass sich das Verhalten dem ähnlich dem Lesens eines Input-Streams von /dev/null (d.h. nichts wird zurückgegeben) ähnelt.
Ein Protokoll, welches NULL-Paket übermittelt sendet Pakete mit der effektiven Länge von Null. Ein Charakteristikum der Übermittlung von NULL-Paketen besagt, dass die Erhöhung der Geschwindigkeit, mit der Null-Pakete gesendet werden, nicht die Bitrate des NULL-Paket-Verkehrs erhöht. Die Bitrate bleibt in allen Fällen = null. Die einzige Ausnahme würde der Fall bilden, wenn eine unendliche Anzahl von NULL-Paketen pro Zeiteinheit gesendet werden könnte. Folglich sollte das Stoppen der Übermittlung von NULL-Paketen keinerlei Auswirkungen auf die Bitrate übermittelter NULL-Pakete haben. Daher sind auch die traditionellen Verkehrs-Performance-Metriken nicht gut geeignet, um den Verkehr von NULL-Paketen zu qualifizieren. Diese Tatsache spricht für die Schaffung neuer Arten von Performance-Metriken, die nur noch positiv getesteten (auf Nützlichkeit) Verkehr qualifizieren. (siehe hierzu Abschnitt 5.2 von RFC 6390) .
Verwendet man NULL-Pakete in einer Multiprotokoll-Label-Switching (MPLS) Umgebung darf nur ein implizites NULL-Label (siehe Abschnitt 4.1.5 von RFC 3031) genutzt werden. Das implizite NULL-Label ist ein zwar ein gültiges Label, welches jedoch nie in MPLS-Paketen vorkommt.
Die Sicherheit für NULL-Pakete bleibt weiterhin undefiniert. Obwohl man davon ausgehen kann, dass Null-Pakete eine gutartige Natur aufweisen, sind diese ziemlich nutzlos. Auch wenn NULL-Pakete eine bösartige Natur aufweisen würden, wären diese Pakete ziemlich ineffizient. Trotzdem haben viele Firewalls und andere Sicherheitseinrichtungen Probleme mit der Identifizierung von NULL-Paketen. Man ist sich in der Fachwelt noch nicht einig, ob das Herauszufiltern von NULL-Paketen effektiv und mühelos von statten gehen könnte. Es bleibt jedoch die unbeantwortete Frage: Kann man auf einer Firewall eine Filterregel erstellen die eine Übermittlung von Innen nach Außen bzw. in umgekehrter Richtung verhindert?
Bei NULL-Pakete muss per Definition nicht das „Evil-Bit“ (E) (RFC 3514) gesetzt werden. Folglich gehören diese Pakete nicht zu den bösartigen Paketen.
Die allgemein akzeptierte Praxis zur Verbesserung der Sicherheit legt fest, dass wichtige Daten verschlüsselt werden sollen. Bei NULL-Paketen muss man jedoch darauf achten, dass es zu keiner NULL-Verschlüsselung (RFC 2410) kommt.
NULL-Pakete lassen sich nicht blockieren, kommen in der Praxis jedoch kaum auf Netzwerken vor. Vielleicht liegt es daran, dass diese ungewöhnlichen Pakete schwer zu fälschen sind oder weil deren Time to Live (TTL) oder Hop-Limit nicht verändert (RFC 5082) werden kann.
Fazit
NULL-Pakete werden zwar in den verschiedensten RFCs beschrieben, sind in der Praxis jedoch nicht zu beweisen. Daraus lässt sich der Lehrsatz ableiten: Das Verwerfen von NULL-Paketen erzeugt keine Paketverluste.
