IP address parsing का मज़ा

• तेज़ IPv4+v6 parser बनाते समय सीखी गई बातों को आसान तरीके से व्यवस्थित करने वाला लेख

• Canonical representation

→ v4 : 192.168.0.1 , 1-byte के Dotted Quad

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

[IPv6]

• बीच में 0 बहुत ज़्यादा आने की वजह से :: से एक या अधिक 0 हटाए जा सकते हैं

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

• आख़िरी 32-bit को v4 के Dotted Quad तरीके से भी लिखा जा सकता है

→ 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

• :: के बिल्कुल शुरू या आखिर में आने वाले case भी होते हैं, इसलिए यह थोड़ा और जटिल हो जाता है

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

• IPv6 Colon-Hex के सभी fields 4-digit hexadecimal होते हैं, और आगे के 0 हटाए जा सकते हैं

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

[IPv4]

• मज़ेदार बात यह है कि IPv6 में आख़िरी 32-bit को Dotted Quad में लिखने के औपचारिक होने से पहले, इसे किसी दस्तावेज़ में standardize नहीं किया गया था

→ इसलिए आम तौर पर उद्योग का de-facto standard यह था: "क्या 4.2BSD इसे interpret कर सकता है?" और "जब दूसरे OS ने 4.2BSD की नकल की, तो उन्होंने क्या बनाए रखा?"

• लेकिन 4.2BSD थोड़ा अजीब (whacky) है

→ 192.168.140.255 = 3232271615 के बराबर है

→ यानी, Chrome में http://3232271615 खोलने पर http://192.168.140.255 लोड होता है। क्योंकि यह 4-byte संख्या है!

→ octal वाला http://0300.0250.0214.0377 भी संभव है

→ तो फिर, hexadecimal https://0xc0.0xa8.0x8c.0xff भी वही address है

• CIDR (Classless Inter-Domain Routing) का IP address पर भी असर पड़ता है

→ class C notation 192.168.140.255 को class B में http://192.168.36095 और class A में http://192.11046143 के रूप में लिखा जा सकता है

→ इसी वजह से ping 127.1 = 127.0.0.1 काम करता है। यह IPv6 की तरह duplicate 0 हटाना नहीं है, बल्कि इसका मतलब है network 127 का पहला host। यानी 24-bit संख्या 1

• हर Quad में संख्या के आगे 0 कितने लगाए जा सकते हैं?

→ 001.002.003.004 ? 0000000001.0000000002.0000000003.000000004 ?

→ ( Chrome में http://0000000001.0000000002.0000000003.000000004 भी चलता है )

→ तब सवाल यह है कि इन संख्याओं को octal पढ़ना चाहिए या hexadecimal? : हाल की implementations ने octal/hexadecimal छोड़कर, आगे के 0 को decimal की तरह treat करना शुरू किया है

• यह leading 0 की समस्या IPv6 को भी प्रभावित करती है

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

→ ज़्यादातर आधुनिक parsers बस "parse integer" library का उपयोग करते हैं, इसलिए आगे बहुत सारे 0 होने पर भी सब स्वीकार कर लेते हैं

यानी, सभी IP address को parse करना हो तो इन सारी बेहूदा बातों को ध्यान में रखना पड़ता है, लेकिन...

लेखक का parser मोटे तौर पर सिर्फ़ इतना support करता है

• पारंपरिक v4 तरीके में dot से अलग किए गए integers, और आगे 0 की संख्या पर कोई सीमा नहीं

• class A/B notation और 8/16-base notation को handle नहीं करता

• एक ही unit32 संख्या से सब कुछ व्यक्त करने वाला रूप भी handle नहीं करता

• IPv6 में canonical colon-hex तरीका, :: short form, और आख़िरी 32-bit में IPv4 जोड़ने वाला रूप स्वीकार करता है (इस IPv4 पर ऊपर वाले नियम लागू होते हैं)। हर field में आगे के 0 की संख्या असीमित हो सकती है

• शुरुआत में IPv4 से IPv6 में आसान migration के लिए आखिर में IPv4 address जोड़ने वाला तरीका शामिल किया गया था, लेकिन व्यवहार में यह बहुत कम दिखाई देता है। इसलिए support तो है, पर लेखक को यह बहुत उपयोगी नहीं लगता

[minhoryang]

ओह, मज़ेदार है! इसमें अटैक करते समय ट्विस्ट देने के लिए काफ़ी अच्छी तकनीकें दिख रही हैं!

[galadbran]

नहीं, IP address लिखने के लिए अगर इतने जटिल नियम इस्तेमाल करने पड़ें, तो लगता है कि यह बेवजह computing resources की बर्बादी है ^^;;