अवलोकन
रिलीज़ 0.9.32 के अनुसार, नेट्डब विनिर्देशन को अपडेट करें ताकि राउटर इन्फोस में होस्टनेम को अप्रचलित किया जा सके, या अधिक सटीक रूप से, व्यक्तिगत राउटर एड्रेस में। सभी I2P कार्यान्वयनों में, होस्टनेम के साथ कॉन्फ़िगर किए गए राउटर को प्रकाशित करते समय प्रकाशित करने से पहले होस्टनेम को आईपी में बदल देना चाहिए, और अन्य राउटर को होस्टनेम के साथ एड्रेस को नजरअंदाज करना चाहिए। राउटर को प्रकाशित होस्टनेम की DNS खोज नहीं करनी चाहिए।
प्रेरणा
I2P की शुरुआत से ही राउटर एड्रेस में होस्टनेम की अनुमति दी गई है। हालांकि, बहुत कम राउटर होस्टनेम प्रकाशित करते हैं, क्योंकि इसके लिए दोनों एक सार्वजनिक होस्टनेम की आवश्यकता होती है (जो बहुत कम उपयोगकर्ताओं के पास होता है), और मैन्युअल कॉन्फ़िगरेशन (जो बहुत कम उपयोगकर्ता करने की परवाह करते हैं) की होती है। एक हाल के नमूने में, 0.7% राउटर एक होस्टनेम प्रकाशित कर रहे थे।
होस्टनेम के मूल उद्देश्य का उद्देश्य उन उपयोगकर्ताओं की सहायता करना था जिनके IP बार-बार बदलते हैं और उनके IP बदलने पर कनेक्टिविटी न खोने के लिए एक डायनामिक DNS सेवा (जैसे कि http://dyn.com/dns/) का उपयोग करना था। हालांकि, तब नेटवर्क छोटा था और राउटर इन्फो का समाप्ति अधिक लंबा था। इसके अलावा, जावा कोड के पास स्थानीय IP बदलते समय राउटर को पुनःचालू करने या राउटर इन्फो को पुनःप्रकाशित करने के लिए कामकाजी तर्क नहीं था।
इसके अलावा, शुरुआत में, I2P IPv6 का समर्थन नहीं करता था, इसलिए होस्टनेम को IPv4 या IPv6 एड्रेस में हल करने की जटिलता मौजूद नहीं थी।
Java I2P में, यह हमेशा कॉन्फ़िगर किए गए होस्टनेम को दोनों प्रकाशित ट्रांसपोर्ट्स में प्रचारित करने के लिए एक चुनौती रही है, और स्थिति IPv6 के साथ और अधिक जटिल हो गई। यह स्पष्ट नहीं है कि एक डुअल-स्टैक होस्ट को दोनों होस्टनेम और एक व्यापक IPv6 एड्रेस प्रकाशित करना चाहिए या नहीं। होस्टनेम SSU एड्रेस के लिए प्रकाशित होता है लेकिन NTCP एड्रेस के लिए नहीं।
हाल ही में, DNS मुद्दों को (दोनों अप्रत्यक्ष रूप से और प्रत्यक्ष रूप से) … को जारी रखने की आवश्यकता है
डिज़ाइन
प्रकाशित राउटर इन्फो कोड के लिए, कार्यान्वयकों के पास दो विकल्प हैं, या तो होस्टनेम के लिए कॉन्फ़िगरेशन विकल्प को निष्क्रिय/हटा दें, या प्रकाशित करते समय कॉन्फ़िगर किए गए होस्टनेम को IP में बदल दें। किसी भी मामले में, राउटर को तुरंत पुनःप्रकाशित करना चाहिए जब उनका IP बदलता है।
राउटर इन्फो सत्यापन और ट्रांसपोर्ट कनेक्शन कोड के लिए, कार्यान्वयकों को होस्टनेम युक्त राउटर एड्रेस को अनदेखा करना चाहिए, और प्रकाशित एड्रेस का उपयोग करना चाहिए जो IP समाहित करते हैं, यदि कोई है। यदि राउटर इन्फो में कोई एड्रेस IP समाहित नहीं करते हैं, तो राउटर को प्रकाशित राउटर से कनेक्ट नहीं करना चाहिए। किसी भी मामले में, राउटर को प्रकाशित होस्टनेम की DNS खोज नहीं करनी चाहिए, या तो सीधे या एक अंतर्निहित लाइब्रेरी के माध्यम से।
विनिर्देशन
NTCP और SSU ट्रांसपोर्ट विवरण को बदलें ताकि “होस्ट” पैरामीटर एक IP हो, न कि होस्टनेम, और ताकि राउटर को व्यक्तिगत राउटर एड्रेस को नजरअंदाज करना चाहिए जो होस्टनेम समाहित करते हैं।
इसका अनुप्रयोग “ihost0”, “ihost1”, और “ihost2” पैरामीटर में भी होता है SSU एड्रेस में। राउटर को होस्टनेम समाहित करने वाले परिचायक एड्रेस को नजरअंदाज करना चाहिए।
टिप्पणियाँ
यह प्रस्ताव रिसीड होस्ट के लिए होस्टनेम को संबोधित नहीं करता। हालांकि रिसीड होस्ट के लिए DNS खोज बहुत कम बार होती है, वे अभी भी एक मुद्दा हो सकते हैं। यदि आवश्यक हो, तो इसे होस्टनेम को IPs के साथ हार्डकोडेड URL की सूची में बदलकर आसानी से ठीक किया जा सकता है; कोई विनिर्देश या कोड परिवर्तन की आवश्यकता नहीं होगी।
प्रवास
यह प्रस्ताव तुरंत लागू किया जा सकता है, बिना किसी क्रमिक प्रवास के, क्योंकि बहुत कम राउटर होस्टनेम प्रकाशित करते हैं, और जो करते हैं आमतौर पर सभी एड्रेस में होस्टनेम प्रकाशित नहीं करते।
राउटर प्रकाशित राउटर के संस्करण की जांच करने की आवश्यकता नहीं है होस्टनेम को नजरअंदाज करने का निर्णय लेने से पहले, और विभिन्न राउटर कार्यान्वयों के बीच एक समन्वित रिलीज़ या आम रणनीति की आवश्यकता नहीं है।
उन राउटर के लिए जो अभी भी होस्टनेम प्रकाशित कर रहे हैं, उन्हें कम इनबाउंड कनेक्शन प्राप्त होंगे, और संभवतः अंतर्निहित सुरंगों का निर्माण करने में कठिनाई होगी।
प्रभाव को और कम करने के लिए, कार्यान्वायक केवल बाढ़भरे राउटर के लिए होस्टनेम के साथ राउटर एड्रेस को नजरअंदाज करना शुरू कर सकते हैं, या उन राउटर के लिए जिनका प्रकाशित संस्करण 0.9.32 से कम है, और सभी राउटर के लिए बाद के रिलीज में होस्टनेम को नजरअंदाज करते हैं।