IPv6 नोटेशन में IPv4
IPv6 के भीतर IPv4 पता दिखने के चार तरीके — और इनमें से कोई भी “आपका IPv6 पता” क्यों नहीं है।
8.8.8.8, 192.168.1.1 या 127.0.0.1 आज़माएँ।
IPv4 पते का कोई IPv6 समकक्ष होता ही नहीं। IPv6 पते आपका प्रदाता देता है; वे आपके पास पहले से मौजूद पते से नहीं निकाले जाते। आगे चार अलग-अलग लेखन-शैलियाँ हैं जिनमें IPv4 पता समाया रहता है, हर एक का अपना मक़सद — इनमें से कोई भी ऐसा पता नहीं जिसे DNS रिकॉर्ड में डालकर काम करने की उम्मीद की जाए।
IPv4-मैप्ड
मौजूदा::ffff:203.0.113.5
ड्यूल-स्टैक सॉकेट किसी IPv4 सहभागी को केवल-IPv6 ऐप्लिकेशन के सामने ऐसे ही दिखाता है। ड्यूल-स्टैक मशीनों के सर्वर लॉग में ये मिलते हैं — ::ffff:203.0.113.5 वाली प्रविष्टि साधारण IPv4 कनेक्शन है, IPv6 नहीं। इसे ::ffff:cb00:7105 भी लिखा जाता है।
IPv4-संगत
पुराना पड़ चुका::203.0.113.5
संक्रमण का शुरुआती तरीक़ा, जिसे 2006 में RFC 4291 ने पुराना घोषित किया और अब लागू नहीं किया जाता। यहाँ इसलिए है कि यह अब भी पुराने दस्तावेज़ों और कॉन्फ़िग फ़ाइलों में दिखता है — वहाँ इसे नक़ल करने की नहीं, ग़लती मानने की चीज़ समझें।
6to4 प्रीफ़िक्स
पुराना पड़ चुका2002:cb00:7105::/48
स्वचालित टनलिंग, जो सार्वजनिक IPv4 पते वाले किसी भी होस्ट को IPv6 का पूरा /48 दे देती थी। RFC 7526 ने इसे पुराना घोषित किया — यह सार्वजनिक रिले पर निर्भर थी जिनकी गुणवत्ता की कोई गारंटी नहीं थी, और ऐसे कनेक्शन बनाती थी जिनकी ख़राबी उपयोगकर्ता पकड़ ही नहीं पाते थे।
NAT64 / जाना-पहचाना प्रीफ़िक्स
सिर्फ़ NAT64 नेटवर्क के भीतर64:ff9b::203.0.113.5
केवल-IPv6 क्लाइंट NAT64 गेटवे के ज़रिए केवल-IPv4 सर्वर तक ऐसे पहुँचता है। यह असली और मौजूदा तरीक़ा है, पर मतलब सिर्फ़ उसी नेटवर्क के भीतर रखता है जहाँ ऐसा गेटवे चल रहा हो — खुले इंटरनेट पर इस पते का कोई अर्थ नहीं।
पता ख़ुद
- डॉटेड डेसिमल
- 203.0.113.5
- हेक्साडेसिमल
- 0xCB007105
- 32-बिट पूर्णांक
- 3,40,58,03,781
- बाइनरी
- 11001011.00000000.01110001.00000101
● दस्तावेज़ीकरण — TEST-NET (RFC 5737) — उदाहरणों के लिए आरक्षित। छापना सुरक्षित है, कभी रूट नहीं होता।
आम तौर पर मान्यता ही ग़लत होती है, और यह कोई बुरी बात नहीं
IPv4-से-IPv6 कन्वर्टर ढूँढ़ने वाले ज़्यादातर लोग ऐसी चीज़ खोज रहे होते हैं जो है ही नहीं: एक ऐसा फ़ंक्शन जो उनके मौजूदा पते को लेकर वह IPv6 पता लौटा दे जो उन्हें इस्तेमाल करना चाहिए। ऐसा कोई फ़ंक्शन नहीं है। IPv6 पते आवंटित होते हैं — आपका ISP या होस्टिंग प्रदाता अपने मिले ब्लॉक में से आपको एक ब्लॉक देता है — वे आपके पहले से मौजूद किसी IPv4 पते से गिनकर नहीं निकाले जाते।
जो चीज़ें सचमुच मौजूद हैं वे कई ऐसी लिखावटें हैं जो IPv4 पते को IPv6 की वाक्य-रचना के भीतर रखती हैं, और हर एक किसी ख़ास काम के लिए बनी है। कौन-सी क्या है, यह जानना वाक़ई काम का है, क्योंकि ये आपको लॉग और कॉन्फ़िग फ़ाइलों में मिलेंगी। पर इनमें से किसी को «आपका IPv6 पता» मान लेना काम का नहीं।
जो आपको असल में दिखेगी
::ffff:203.0.113.5 — IPv4-मैप्ड रूप — असल दुनिया में दिखने वाले लगभग हर मामले का यही हिसाब है। यह तब आता है जब कोई प्रोग्राम IPv6 सॉकेट पर सुन रहा हो और कोई IPv4 क्लाइंट जुड़े: ऑपरेटिंग सिस्टम पीयर को इसी रूप में पेश करता है ताकि एप्लिकेशन को सिर्फ़ एक ही तरह का पता सँभालना पड़े।
इसका व्यावहारिक नतीजा दो जगह काटता है। जो लॉग विश्लेषण डॉट वाले चार हिस्सों की उम्मीद करता है, वह इन पंक्तियों से मेल नहीं खाएगा। और स्ट्रिंग मिलाने वाली कोई अनुमति-सूची ::ffff:203.0.113.5 को 203.0.113.5 से नहीं मिला पाएगी — ऐसा नियम जो सही दिखता है, समीक्षा में पास हो जाता है, और चुपचाप कभी चलता ही नहीं। मिलाने से पहले सामान्य रूप में ले आइए।
बाक़ी क्या हैं
IPv4-कम्पैटिबल (::203.0.113.5) संक्रमण का एक शुरुआती विचार था, जिसे 2006 में RFC 4291 ने त्याज्य घोषित किया और आज कोई भी चीज़ उसे लागू नहीं करती। अगर वह आपको किसी कॉन्फ़िग फ़ाइल में मिले तो वह चुनाव नहीं, ख़ामी है।
6to4 (2002::/16) सार्वजनिक IPv4 पते वाले किसी को भी अपने आप /48 IPv6 दे देता था, जो सार्वजनिक रिले से होकर टनल किया जाता था। 2015 में RFC 7526 ने इसे त्याज्य घोषित किया — उन रिले का कोई जवाबदेह ऑपरेटर नहीं था, और इसकी ख़राबियाँ सबसे बुरी क़िस्म की थीं: रुक-रुककर, धीमी, और उपयोगकर्ता के लिए जाँचना नामुमकिन।
NAT64 (64:ff9b::/96) आज भी चलन में है और रोज़ इस्तेमाल होता है। ख़ासकर मोबाइल ऑपरेटर सिर्फ़ IPv6 वाले नेटवर्क चलाते हैं और किनारे पर अनुवाद करते हैं, ताकि सिर्फ़ IPv6 वाला हैंडसेट इसी रास्ते सिर्फ़ IPv4 वाली सेवाओं तक पहुँच सके। यह असली है, पर यह उस नेटवर्क का गुण है जिसके भीतर आप हैं, कोई ऐसा पता नहीं जो आप किसी को दे सकें।
दोनों प्रोटोकॉल आपस में सीधे बात क्यों नहीं कर सकते
तीस साल के संक्रमण को देखते हुए यह वाजिब सवाल है। जवाब यह है कि IPv6 लंबे पतों वाला IPv4 नहीं है — यह अलग हेडर वाला अलग प्रोटोकॉल है, और जो राउटर एक को सँभालता है उसके पास दूसरे का पैकेट आगे भेजने का कोई रास्ता नहीं। IPv4 के हेडर में 128-बिट पता रखने की जगह ही नहीं है।
इसलिए इनके बीच हर रास्ते में बीच में कुछ चाहिए: दोनों चलाने वाला ड्यूल-स्टैक होस्ट, NAT64 जैसा कोई अनुवादक, या ऐसा प्रॉक्सी जो एक कनेक्शन ख़त्म करे और दूसरा शुरू करे। संक्रमण के इतने धीमे होने की पूरी वजह यही है, और इसीलिए «मैं IPv6 का समर्थन कैसे करूँ?» का व्यावहारिक जवाब लगभग हमेशा «ड्यूल-स्टैक चलाइए» होता है, «कुछ बदलिए» नहीं।
संबंधित
आप असल में किस प्रोटोकॉल से इंटरनेट तक पहुँच रहे हैं यह देखने के लिए, IP जाँच बताती है कि आपके कनेक्शन ने कौन-सा एड्रेस फ़ैमिली इस्तेमाल किया। और आपके पास जो पता है उसका सबनेटिंग करने के लिए, सबनेट कैलकुलेटर IPv4 वाला पक्ष सँभालता है।
यह पेज जिन सवालों के लिए बना है
मेरे IPv4 पते के बराबर IPv6 पता क्या है?
ऐसा कोई पता होता ही नहीं, और इस पेज पर यही सबसे ज़रूरी बात है। IPv6 पते वही देता है जो आपको कनेक्टिविटी देता है — वे आपके ISP या होस्टिंग प्रदाता से आते हैं, उन्हें आवंटित ब्लॉक में से। अपने पास पहले से मौजूद IPv4 पते से आप IPv6 पता वैसे ही नहीं निकाल सकते जैसे डाक पते से फ़ोन नंबर नहीं निकाल सकते। यहाँ दिखाई गई लिखावटें ख़ास तकनीकी कामों के लिए IPv4 पते को IPv6 की वाक्य-रचना में जड़ देती हैं — और वह अलग बात है।
मेरे सर्वर लॉग में ::ffff:203.0.113.5 क्यों दिख रहा है?
क्योंकि सॉकेट IPv6 पर सुन रहा है और कनेक्शन IPv4 से आया। ड्यूल-स्टैक सॉकेट IPv4 पीयर को एप्लिकेशन के सामने इसी «IPv4-मैप्ड» रूप में पेश करता है ताकि कोड को सिर्फ़ एक ही तरह का पता सँभालना पड़े। यह एक साधारण IPv4 कनेक्शन है। अगर आप लॉग पार्स कर रहे हैं या पतों को किसी अनुमति-सूची से मिला रहे हैं, तो पहले ::ffff: उपसर्ग हटा दीजिए — इसे अलग पता मान लेना उन नियमों की आम वजह है जो चुपचाप मैच होना बंद कर देते हैं।
क्या मुझे 6to4 पता इस्तेमाल करना चाहिए?
नहीं। 6to4 एक स्वचालित टनलिंग तंत्र था जो 2002::/16 उपसर्ग के ज़रिए सार्वजनिक IPv4 पते वाले किसी भी होस्ट को /48 IPv6 जगह दे देता था। 2015 में RFC 7526 ने इसे औपचारिक रूप से त्याज्य घोषित कर दिया, क्योंकि यह ऐसे सार्वजनिक रिले राउटरों पर टिका था जिनके लिए कोई जवाबदेह नहीं था, और इससे बनने वाले कनेक्शन धीमे होते थे या ऐसे टूटते थे जिनकी जाँच उपयोगकर्ता कर ही नहीं सकता था। IPv6 चाहिए तो अपने प्रदाता से लीजिए, या ऐसे टनल ब्रोकर से जिसका ऑपरेटर जवाबदेह हो।
64:ff9b:: किस काम आता है?
यह NAT64 का सुपरिचित उपसर्ग है, जो RFC 6052 में परिभाषित है। सिर्फ़ IPv6 वाला कोई क्लाइंट अगर सिर्फ़ IPv4 वाले सर्वर तक पहुँचना चाहे, तो वह 64:ff9b:: पर भेजता है और IPv4 पता आख़िरी बत्तीस बिट में जड़ दिया जाता है; रास्ते में बैठा NAT64 गेटवे अनुवाद कर देता है। यह आज भी चलन में है और ख़ूब तैनात है — ख़ासकर उन मोबाइल ऑपरेटरों के यहाँ जो सिर्फ़ IPv6 के नेटवर्क चलाते हैं। पर इसका अर्थ सिर्फ़ उसी नेटवर्क के भीतर है जहाँ ऐसा गेटवे चल रहा हो; खुले इंटरनेट पर यह पता रूट नहीं होता।
क्या IPv4 और IPv6 होस्ट सीधे आपस में बात कर सकते हैं?
नहीं। ये अलग प्रोटोकॉल हैं जिनके पैकेट फ़ॉर्मैट अलग हैं, और इनमें सीधा तालमेल है ही नहीं — यही वजह है कि यह संक्रमण तीस साल खींच चुका है। इनके बीच संवाद के लिए बीच में हमेशा कुछ चाहिए: दोनों बोलने वाला ड्यूल-स्टैक होस्ट, NAT64 जैसा कोई अनुवादक, या ऐसा प्रॉक्सी जो एक सिरा ख़त्म करके दूसरा शुरू करे। इसीलिए «बस पता बदल दो» किसी चीज़ का हल नहीं है।
अंतिम समीक्षा । कुछ पुराना पड़ा हुआ मिला? हमें बताइए.