Der Spaß am Parsen von IP-Adressen

• Ein gut lesbarer Artikel, der zusammenfasst, was man beim Bau eines schnellen IPv4+v6-Parsers gelernt hat

• Kanonische Darstellung

→ v4 : 192.168.0.1 , Dotted Quad aus 1-Byte-Werten

→ v6 : 1:2:3:4:5:6:7:8 , Colon-Hex aus 2-Byte-Werten

[IPv6]

• Da in der Mitte oft viele 0en vorkommen, kann man mit :: eine oder mehrere 0en weglassen

→ 1:2::3:4 = 1:2:0:0:0:0:3:4

• Die letzten 32 Bit können auch in der Dotted-Quad-Schreibweise von v4 dargestellt werden

→ 1:2:3:4:5:6:77.77.88.88 = 1:2:3:4:5:6:4d4d:5858

→ fe80::1.2.3.4 = fe80:0:0:0:0:0:102:304

• Weil :: am Anfang oder Ende stehen kann, wird es etwas komplizierter

→ ::1 = 0:0:0:0:0:0:0:1

→ 1:: = 1:0:0:0:0:0:0:0

→ :: = 0:0:0:0:0:0:0:0

• Alle Felder von IPv6 Colon-Hex sind 4-stellige Hexzahlen, führende 0en können weggelassen werden

→ :: = 0000:0000:0000:0000:0000:0000:0000:0000

[IPv4]

• Interessant ist, dass es vor der offiziellen Festlegung der Dotted-Quad-Darstellung für die letzten 32 Bit in IPv6 in keinem Dokument jemals standardisiert wurde

→ Deshalb war der übliche De-facto-Industriestandard meist: „Kann 4.2BSD das interpretieren?“ und „Was wurde beibehalten, wenn andere OS 4.2BSD kopiert haben?“

• Aber 4.2BSD ist etwas seltsam (whacky)

→ 192.168.140.255 = 3232271615

→ Wenn man also in Chrome http://3232271615 aufruft, lädt es http://192.168.140.255. Es ist schließlich eine 4-Byte-Zahl!

→ Auch die oktale Form http://0300.0250.0214.0377 ist möglich

→ Dann ist natürlich auch die hexadezimale Form https://0xc0.0xa8.0x8c.0xff dieselbe Adresse

• CIDR (Classless Inter-Domain Routing) wirkt sich ebenfalls auf IP-Adressen aus

→ Die Klasse-C-Darstellung 192.168.140.255 kann als Klasse B http://192.168.36095 und als Klasse A http://192.11046143 geschrieben werden

→ Deshalb funktioniert ping 127.1 = 127.0.0.1. Dabei wurden nicht wie bei IPv6 doppelte 0en entfernt, sondern es bedeutet den ersten Host im Class-A-Netz 127, also die 24-Bit-Zahl 1

• Wie viele führende 0en dürfen vor den Zahlen der einzelnen Quads stehen?

→ 001.002.003.004 ? 0000000001.0000000002.0000000003.000000004 ?

→ ( Chrome akzeptiert auch http://0000000001.0000000002.0000000003.000000004 )

→ Sollte man diese Zahlen dann als oktal oder als hexadezimal lesen? Neuere Implementierungen verzichten auf Oktal/Hex und behandeln führende 0en dezimal

• Dieses Problem mit führenden 0en betrifft auch IPv6

→ 000001::00001.00002.00003.00004 = 1::1.2.3.4, oder 1::102:304

→ Moderne Parser verwenden meist eine „parse integer“-Bibliothek und erlauben deshalb beliebig viele führende 0en

Um wirklich alle IP-Adressen zu parsen, müsste man also all diesen Mist berücksichtigen, aber …

Der Parser des Autors unterstützt nur ungefähr Folgendes:

• Klassische v4-Schreibweise mit durch Punkte getrennten Ganzzahlen; beliebig viele führende 0en sind erlaubt

• Class-A/B-Schreibweisen und Oktal/Hex werden nicht verarbeitet

• Auch die Darstellung aller Werte als eine einzelne uint32-Zahl wird nicht verarbeitet

• Bei IPv6 sind die normale Colon-Hex-Schreibweise, die Verkürzung mit :: sowie das Anhängen einer IPv4-Adresse an die letzten 32 Bit erlaubt (für diese IPv4 gelten die obigen Regeln). Bei jedem Feld sind beliebig viele führende 0en erlaubt

• Anfangs wurde das Anhängen einer IPv4-Adresse am Ende eingebaut, um den einfachen Übergang von IPv4 zu IPv6 zu unterstützen, in der Praxis sieht man das aber kaum. Deshalb wird es zwar unterstützt, aber besonders nützlich findet der Autor es nicht

[minhoryang]

Oh, interessant! Da sieht man viele Techniken, die sich gut zum Verdrehen bei Angriffen eignen!

[galadbran]

Ich denke mir dabei nur: Wenn man für die Darstellung von IP-Adressen derart komplizierte Regeln verwenden muss, ist das dann nicht eine Verschwendung unnötiger Rechenressourcen? ^^;;