ITBlog

In meiner Freizeit pflege ich die net-tools für Linux. Das ist eine Sammlung der grundlegenden Netzwerk Konfigurationsbefehle wie netstat, arp und ifconfig. Deswegen bekomme ich öfters Anfragen und Fehlermeldungen wegen unerwartetem Verhalten dieser (und anderer) Netzwerk Programme, bei der Eingabe von IPv4-Addressen mit führenden Nullen, wie zum Beispiel: 010.010.010.010 oder 120.130.130.099. In der Literatur (RFC790 macht dies falsch), und vor allem beim Umgang mit dem Rechner sollte man diese formatierungen vermeiden (besonders fatal ist es, wenn Programme diese Art von formatierung selbst verwenden!). Der Grund: eine Reihe von Implementierungen erlauben traditionell eine gaze Reihe von Schreibweisen für IPv4 Addressen. Darunter fällt auch die Interpretation der einzelnen Punkt-getrennten Nummern als Octalzahlen (statt Decimal), wenn diese eine führende null besitzen (oder hexadezimale Interpretation bei einem 0x Prefix, wie in C üblich). Nicht alle Programme erlauben diese Schreibweise, und noch weniger Menschen ist diese geläufig. Das ist wohl auch ein guter Grund, warum man diese nicht verwenden sollte. Allerdings sollte man sich bewusst sein, dass manche Software die Zahlen anders interpretiert (oder sogar abweist, weil 100.100.100.09 keine gültige Octal-Zahl ist)

# ifconfig lo 010.010.010.010
# ifconfig lo | grep inet
inet addr:8.8.8.8  Mask:255.0.0.0
# ping -c 1 010.010.010.010
PING 010.010.010.010 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=64 time=0.070 ms
# ping -c 1 0x08080808
PING 0x08080808 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=64 time=0.078 ms

(Das Windows XP Ping.exe verhält sich übrigens genauso). Für Techniker: traditionell wird in der Unix Welt die Umsetzung von Strings in IPV4 Addressen mit der C-Library Funtion inet_aton(3) gemacht, die diese Interpretation vornimmt. Diese Function erlaubt auch die Angabe einer IP Addresse in Hexadezimalschreibweise 0x08080808 oder mit einer 16bit Komponente: 8.8.2056 oder eben mit Octal/Hexadecimal Prefix. Übrigens erlaubt RFC3986 (der den Syntax für URLs angibt) diese Schreibweise nicht, und definiert nur Decimal-Zahlen. Das ist auch eine Konsequenz aus den Angriffen auf String-basierende URL Fillter die sich zu leicht durch die vielen unterschiedlichen Schreibweisen haben auf das Kreuz legen lassen. Im Zuge der Umstellung auf IPv6 wurde die Fähigkeit der alternativen Schreibweisen übrigens in den meisten Implementierungen entfernt, z.b. inet_ntop weist diese Funktion nicht auf. Die IPv6 RFCs (RFC3531) haben den selben Fehler wie die IPv4 RFCs gemacht, und vergessen die IPv6 Literale formal zu definieren (keine BNF Definition), auch dies wurde in RFC3986 nachgeholt.