👩‍👩‍👧‍👧 👨🏿‍🚀 😯 IPv6 - आप इसे गलत कर रहे हैं 🧀 🛄 ☺️

IPv6 के आसपास बहुत सारी भ्रांतियाँ और मिथक हैं। अक्सर, होस्टिंग प्रदाता गलतफहमी करते हैं कि इसका उपयोग कैसे करें और आईपीवी 4 की दुनिया से आउटडेटेड दृष्टिकोणों को सोचें। उदाहरण के लिए, IPv6 पतों के ऑक्टिलियन होने के बाद, होस्टर्स ग्राहकों से पतों को व्यक्तिगत रूप से बेचता है, बजाय एक पूर्ण / 64 नेटवर्क आवंटित करने के, जैसा कि सिफारिशों से होता है।

ऐसा होता है कि होस्टर्स एक ही / 64 नेटवर्क के भीतर अलग-अलग क्लाइंट को IPv6 एड्रेस देते हैं। उसी समय, बड़ी सेवाएँ, जैसे कि Google, एक ग्राहक के रूप में / 64 रेंज के भीतर सभी पते का अनुभव करती हैं। नतीजतन, ग्राहक एक बैंडमेट की गतिविधियों के कारण पीड़ित हो सकते हैं।

IPv6 पतों की उपलब्धता आपको आंतरिक संसाधनों जैसे कंटेनर या वीपीएन क्लाइंट के लिए पूर्ण बाहरी पते आवंटित करने की अनुमति देती है। ऐसा करने के लिए, होस्ट को क्लाइंट को एक अलग रूट किए गए नेटवर्क के साथ प्रदान करना होगा। दुर्भाग्य से, लगभग कोई भी ऐसा नहीं कर सकता है।

इस लेख में, हम IPv6 प्रदाताओं के उपयोग में मुख्य त्रुटियों का विश्लेषण करेंगे।

स्टोरीलाइन: आरएफसी 3177

2001 में, सुझाए गए पतों के आवंटन पर सिफारिशें (टॉटोलॉजी के लिए खेद है, यह महत्वपूर्ण है) हाइलाइट करने के लिए:

/ 48 सामान्य रूप से
/ 64 यदि इसके पीछे एक और केवल एक सबनेट है
/ 128 यदि एक और केवल एक उपकरण

आक्रामक दस्तावेज़ RFC 2119, जो निर्देशों के साथ अनिवार्य अनुपालन के विभिन्न स्तरों के अनुप्रयोग को नियंत्रित करता है, "अनुशंसित" को इस प्रकार परिभाषित करता है:
"चाहिए" या "अनुशंसित" शब्दों का अर्थ है कि कुछ परिस्थितियों में इस तरह से कार्य नहीं करने के लिए उचित कारण हो सकते हैं, हालांकि, व्यवहार की एक अलग लाइन का विकल्प। परिणामों की पूरी समझ के साथ किया गया एक संतुलित निर्णय होना चाहिए।
शायद किसी को भी उस समय परिणामों की पूरी समझ नहीं थी, शायद "कुछ परिस्थितियों" को परिभाषित नहीं किया गया था, लेकिन, एक तरह से या किसी अन्य, सभी ने सिफारिशों का पालन किया।

सामान्य तौर पर, दस्तावेज़ लिखने के समय, आईपीवी 6 ट्रैफ़िक अत्यंत दुर्लभ था और उत्सुक उत्साही लोगों के संस्थानों और व्यक्तिगत नेटवर्क में, अधिकांश भाग के लिए पाया गया था। कुछ वास्तविक समस्याओं का संचय और विश्लेषण शुरू हुआ, लेकिन इसमें बहुत समय लगा।
2005 में रिथिंकिंग शुरू हुई। आखिरकार, इन सिफारिशों को 2011 में हटा दिया गया।

समस्या की जागरूकता: RFC 6177

नई एड्रेसिंग पॉलिसी में स्पष्ट रूप से कहा गया है कि / 48 केवल एक इच्छा है, आवश्यकता नहीं है। विशिष्ट संख्याओं का कोई संकेत नहीं दिया गया है, हालांकि, यह संकेत दिया जाता है कि सामान्य परिस्थितियों में / 64 या उससे कम काम करता है।

अंतिम उपभोक्ता को ब्लॉक / 48 जारी करने के आकार की सिफारिश करने में मुख्य तर्क तीन लक्ष्यों का पीछा किया।

सबसे पहले, निर्दिष्ट पते का स्थान उपभोक्ता उद्देश्यों के लिए और आसानी से एक्स्टेंसिबल होना चाहिए, बिना बारबेल स्क्वैट्स के। हां, ठीक यही बात है, केवल अंग्रेजी संस्करण में - हुप्स के माध्यम से कूदो। IPv6 पर स्विच करने का एक महत्वपूर्ण कारण मौजूदा गंतव्य आकार को "एकल पते" से "एकाधिक सबनेट" में बदलना है।

दूसरे, प्रदाता का परिवर्तन न्यूनतम समस्याओं के साथ होना चाहिए था। यदि आप नए पते के स्थान पर जाते समय पुरानी सबनेट एड्रेस स्कीम को सहेज सकते हैं, तो यह बहुत काम बचाएगा

। तीसरा, ब्लॉक / 48 का आवंटन एक विकासशील उपभोक्ता के पते की जगह की जरूरतों में वृद्धि को कवर करना चाहिए।

हालाँकि ये सभी शर्तें पूरी हो गई थीं, लेकिन यह स्पष्ट हो गया कि सिफारिश / 48 थी, इसे हल्के ढंग से, बेमानी करने के लिए।

अंक की इकाइयों के रूप में पिन / 64

वितरण आदेश के अलावा, अन्य बिंदु भी थे। यह पता चला है कि यदि नेटवर्क उपसर्ग / 64 नहीं है तो IPv6 की कई विशेषताएं काम नहीं करती हैं। अर्थात्, वे काम नहीं करते हैं:

पड़ोसी डिस्कवरी (ND)
सुरक्षित पड़ोसी डिस्कवरी (भेजें)
मोबाइल IPv6 के कुछ हिस्से
IPv6 इंटरमीडिएशन द्वारा साइट मल्टीहोमिंग
कई अलग छोटी चीजें

एक अतिरिक्त कारक यह तथ्य था कि डिज़ाइन की जा रही कई प्रौद्योगिकियाँ ऐसे नेटवर्क उपसर्ग पर सटीक रूप से निर्भर करती हैं।

न केवल न्यूफ़ाउंड मानक को तोड़ने का खतरा, नई सिफारिशें लिखने का कारण था। संदिग्ध वैधता के दो मत भी बहुत लोकप्रिय थे।
सबसे पहले, कई डिवाइस आईपीवी 6 राउटिंग को प्रोग्रामिक रूप से लागू करते हैं, बैसाखी और साइकिल के साथ, और इसलिए इसके लिए पूर्ण संक्रमण के लिए तैयार नहीं हैं। देरी की एक संभावित वृद्धि कई बार बढ़ सकती है, अगर परिमाण का क्रम नहीं। / 64 सबनेट की डिफ़ॉल्ट परिभाषा इन देरी को बहुत कम कर देगी।

दूसरा, एक नए मानक पर स्विच करना हमेशा तकनीकी सहायता और सिस्टम प्रशासक के लिए दर्द होता है। एक एकल / 64 उपसर्ग को इस दर्द को स्वीकार्य मूल्य तक कम करना था।

मोर्चों पर स्थिति

जैसा कि 2001 में पहले ही हो चुका था, कई बड़े इंटरनेट प्लेयर्स द्वारा सिफारिश / 64 को एक मानक के रूप में माना जाता है। एक ओर यह अच्छा है, दूसरी ओर यह उतना अच्छा नहीं है।

कई रेटिंग प्रणालियों के लिए, उदाहरण के लिए, स्पैम मान्यता के लिए, एक ब्लॉक के सभी पते एक स्पैमर से संबंधित माने जाएंगे। सिद्धांत रूप में, यह उपयोगकर्ता के लिए जीवन को आसान बनाना चाहिए, वास्तव में, इसके ठीक विपरीत।

अक्सर, प्रदाता सामान्य प्रथाओं के बारे में सीखने जैसी चीजों से परेशान नहीं होते हैं। पते किसी भी सिद्धांत के अनुसार जारी किए जा सकते हैं, कम से कम कुंडली के अनुसार भी।

कई विशिष्ट समस्याएं हैं, और उनमें से सभी एक तरफ प्रदाता द्वारा सिफारिशों के उल्लंघन से उपजी हैं, और दूसरी तरफ कुछ अन्य संगठनों द्वारा उनका कड़ाई से पालन।
एक ब्लॉक से कई उपयोगकर्ताओं के पते जारी करना इस तथ्य को जन्म दे सकता है कि उन्हें सभी को एक वास्तविक उपयोगकर्ता माना जाएगा, उदाहरण के लिए, संगठन के नेटवर्क में मशीनें।

यदि इस ब्लॉक के कई लोग एक ही समय में बिल्लियों की तलाश शुरू करते हैं, तो Google यह तय कर सकता है कि यह बॉटनेट खोज घोटाले या कुछ अन्य चीजों के लिए अनुरोध भेजेगा। उनके दृष्टिकोण से, यह सभी एक उपयोगकर्ता है। तार्किक परिणाम एक तेजी से जटिल कैप्चा है।

जैसा कि आप जानते हैं, यह एक काल्पनिक घोटाले का सबसे हानिरहित जवाब है।
रिवर्स स्थिति विभिन्न ब्लॉकों के पते के एक उपयोगकर्ता को जारी करना है। यदि इन ब्लॉकों के उपयोगकर्ता किसी की ब्लैकलिस्ट में आते हैं, तो एक ईमानदार उपयोगकर्ता के पते उनके साथ गिर जाएंगे। विशेष रूप से दिलचस्प कहानी: आपके कुछ पते एक विज्ञापन नेटवर्क द्वारा प्रतिबंधित किए गए थे, कुछ को दूसरे द्वारा प्रतिबंधित किया गया था।

इसके अलावा, अन्य अप्रिय आश्चर्य संभव हैं। उदाहरण के लिए, आपने / 64 ब्लॉक प्राप्त किया, लेकिन यह डायनेमिक ब्लॉक है, डायनेमिक एड्रेस के रूप में - आज 2001: DA8: 1D01: FA13 :: / 64, कल 2001: DA8: 1D01: FC15 :: / 64। हर दिन नया रोमांच!
इन समस्याओं और उपांग में अन्य काल्पनिक घुमावदार रेक के विभिन्न संयोजनों को पूरा करने का काफी मौका है।

हमारे सर्वर से IPv6 जारी करें

यदि हमारे पास एक क्विंटिलियन आईपी पते हैं, तो असली आईपी पते क्यों न दें, उदाहरण के लिए, वीपीएन ग्राहकों को ताकि वे नेट के बिना इंटरनेट पर जाएं और दुनिया से आने वाले कनेक्शन स्वीकार कर सकें। यह बहुत अच्छा लगता है, लेकिन व्यवहार में यह इतना आसान नहीं है। इसके लिए एक अलग IPv6 नेटवर्क की आवश्यकता होगी जिसे आईपी इंटरफेस के माध्यम से सर्वर इंटरफ़ेस को सौंपा गया हो।

मान लीजिए कि एक सर्वर को एक पता सौंपा गया है 2a01:baba::c0fee:dead/64, तो वीपीएन ग्राहकों को एक अलग नेटवर्क की आवश्यकता होगी, जैसे 2a01:baba:fafa:0f0f::/64पते के माध्यम से रूट किया गया 2a01:baba::c0fee:dead/64।

दुर्भाग्य से, बहुत कम होस्टिंग प्रदाताओं के पास ऐसे नेटवर्क क्लाइंट्स को जारी करने के लिए उपकरण हैं, जिसके कारण आपको ND प्रॉक्सी जैसे बैसाखी का उपयोग करना पड़ता है ।

निष्कर्ष

IETF सिफारिशों को पढ़ना सबसे दिलचस्प गतिविधि नहीं है, लेकिन यह बेहद उपयोगी है। लंबी सर्दियों की शाम के साथ उन्हें भरना स्पष्ट रूप से इसके लायक नहीं है, लेकिन उन वर्गों को पढ़ने की उपेक्षा करना जो आपके लिए महत्वपूर्ण हैं, अवांछनीय भी हैं।

प्रदाता चुनते समय, सुनिश्चित करें कि वह इस दृष्टिकोण को साझा करता है।

आपको यह समझने की आवश्यकता है कि पते के आवंटन के लिए गलत दृष्टिकोण प्रदाता को किसी भी तरह से नुकसान नहीं पहुंचाता है, और अधिकांश अनुबंधों के तहत यह क्षति के लिए मुआवजा प्राप्त करने का आधार भी नहीं हो सकता है।
हालाँकि, यह आपके लिए एक महत्वपूर्ण कारक हो सकता है, हालाँकि आप स्वयं इस पर अभी तक संदेह नहीं करते हैं।