Serunya Parsing Alamat IP

• Tulisan yang merangkum dengan mudah dibaca hal-hal yang dipelajari saat membuat parser IPv4+v6 yang cepat

• Representasi formal (canonical)

→ v4 : 192.168.0.1 , Dotted Quad dari byte-byte 1-byte

→ v6 : 1:2:3:4:5:6:7:8 , Colon-Hex dari unit-unit 2-byte

[IPv6]

• Karena sering ada banyak angka 0 di tengah, :: dapat dipakai untuk menghilangkan satu atau lebih blok 0

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

• 32-bit terakhir bisa ditulis memakai format Dotted Quad milik v4

→ 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

• Menjadi sedikit lebih rumit karena ada kasus :: muncul di paling depan/paling belakang

→ ::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

• Semua field pada IPv6 Colon-Hex adalah bilangan heksadesimal 4 digit, dan nol di depan boleh dihapus

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

[IPv4]

• Yang menarik, sebelum format Dotted Quad untuk 32-bit terakhir di IPv6 diformalkan, format ini tidak pernah distandardisasi di dokumen mana pun

→ Karena itu, standar industri de-facto biasanya adalah “bisa ditafsirkan oleh 4.2BSD?” dan “saat OS lain menyalin 4.2BSD, perilaku apa yang dipertahankan?”

• Tapi 4.2BSD agak aneh (whacky)

→ 192.168.140.255 = sama dengan 3232271615

→ Artinya, kalau membuka http://3232271615 di Chrome, yang dimuat adalah http://192.168.140.255 . Karena itu angka 4-byte!

→ Bentuk oktal seperti http://0300.0250.0214.0377 juga bisa

→ Maka tentu saja bentuk heksadesimal seperti https://0xc0.0xa8.0x8c.0xff juga alamat yang sama

• CIDR (Classless Inter-Domain Routing) juga memengaruhi alamat IP

→ Notasi kelas C 192.168.140.255, jika ditulis sebagai kelas B menjadi http://192.168.36095 , dan jika ditulis sebagai kelas A menjadi http://192.11046143

→ Itulah sebabnya ping 127.1 bisa berarti 127.0.0.1. Bukan karena nol berurutan dihapus seperti IPv6, tetapi karena itu berarti host pertama di jaringan kelas A 127. Dengan kata lain, angka 24-bit bernilai 1

• Berapa banyak nol di depan yang boleh ada pada angka di tiap Quad?

→ 001.002.003.004 ? 0000000001.0000000002.0000000003.000000004 ?

→ ( Chrome juga menerima http://0000000001.0000000002.0000000003.000000004 )

→ Dalam kasus ini, apakah angkanya harus dibaca sebagai oktal, atau heksadesimal? Implementasi terbaru meninggalkan oktal/heksadesimal, lalu memperlakukan nol di depan sebagai desimal

• Masalah nol di depan ini juga memengaruhi IPv6

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

→ Karena kebanyakan parser modern memakai library “parse integer”, semua nol di depan biasanya tetap diterima

Jadi, untuk mem-parsing semua alamat IP, semua kekacauan menyebalkan ini sebenarnya harus dipertimbangkan, tetapi...

Parser penulis hanya memilih mendukung kira-kira yang berikut ini

• Gaya v4 klasik: integer yang dipisahkan titik, dengan jumlah nol di depan tak terbatas

• Tidak menangani notasi kelas A/B maupun oktal/heksadesimal

• Juga tidak menangani representasi semua hal sebagai satu angka unit32

• Untuk IPv6, menerima format colon-hex formal, bentuk singkat ::, dan juga penempelan IPv4 pada 32-bit terakhir (IPv4 ini mengikuti aturan di atas). Jumlah nol di depan pada tiap field juga tak terbatas

• Awalnya format menempelkan alamat IPv4 di bagian akhir dimasukkan untuk memudahkan migrasi dari IPv4 ke IPv6, tetapi di praktiknya format ini jarang terlihat. Jadi walaupun didukung, penulis merasa ini tidak terlalu berguna

[minhoryang]

Wah, menarik ya! Kelihatan ada banyak teknik yang bagus untuk dipelintir saat menyerang!

[galadbran]

Saya jadi berpikir, kalau sampai harus memakai aturan serumit ini hanya untuk menuliskan alamat IP, bukankah itu malah pemborosan sumber daya komputasi yang tidak perlu? ^^;;