IPv6 परिवहन संवर्धन

नोट

नेटवर्क परिनियोजन और परीक्षण प्रगति पर है। थोड़े सुधार की संभावना है।

अवलोकन

यह प्रस्ताव IPv6 के लिए SSU और NTCP2 परिवहन में सुधार को लागू करने के लिए है।

प्रेरणा

जैसे-जैसे IPv6 का विस्तार हो रहा है और IPv6-केवल सेटअप (विशेषकर मोबाइल पर) अधिक सामान्य हो रहे हैं, हमें IPv6 के लिए अपने समर्थन को सुधारने और इस धारणा को हटाने की आवश्यकता है कि सभी राउटर्स IPv4-क्षमता रखते हैं।

कनेक्टिविटी जाँच

जब टनल के लिए साथियों का चयन करते हैं, या संदेशों के मार्ग के लिए OBEP/IBGW पथों का चयन करते हैं, यह निर्धारित करने में सहायक होता है कि क्या राउटर A राउटर B से जुड़ सकता है। सामान्य रूप से, इसका अर्थ है यह पता लगाना कि A के पास उस परिवहन और एड्रेस प्रकार (IPv4/v6) के लिए आउटबाउंड क्षमता है या नहीं जो B के विज्ञापित इनबाउंड एड्रेस में से किसी एक से मेल खाता है।

हालांकि, कई मामलों में हमें A की क्षमताओं की जानकारी नहीं होती और हमें अनुमान लगाना पड़ता है। अगर A छिपा हुआ या फ़ायरवॉल्ड है, तो एड्रेस प्रकाशित नहीं होते, और हमारे पास सीधी जानकारी नहीं होती - तो हम मानते हैं कि यह IPv4 के सक्षम है, और IPv6 के सक्षम नहीं है। समाधान Router Info में IPv4 और IPv6 के लिए आउटबाउंड क्षमता संकेत करने के लिए दो नए “कैप्स” या क्षमताओं को जोड़ना है।

IPv6 परिचायक

हमारी विशिष्टताओं SSU और SSU-SPEC में त्रुटियाँ और असंगतताएँ हैं कि क्या IPv4 परिचयों के लिए IPv6 परिचायक समर्थित हैं। किसी भी मामले में, इसे न तो जावा I2P में और न ही i2pd में लागू किया गया है। इसे ठीक करने की आवश्यकता है।

IPv6 परिचयों

हमारी विशिष्टताओं SSU और SSU-SPEC स्पष्ट करती हैं कि IPv6 परिचय समर्थित नहीं हैं। यह इस धारणा के तहत था कि IPv6 कभी फ़ायरवॉल्ड नहीं होता। यह स्पष्ट रूप से सही नहीं है, और हमें फ़ायरवॉल्ड IPv6 रूटर्स के लिए समर्थन सुधारने की आवश्यकता है।

परिचय आरेख

लेजेंड: —– IPv4 है, ====== IPv6 है

वर्तमान IPv4-केवल:

      एलिस                         बॉब                  चार्ली
  RelayRequest ---------------------->
       <-------------- RelayResponse    RelayIntro ----------->
       <-------------------------------------------- HolePunch
  SessionRequest -------------------------------------------->
       <-------------------------------------------- SessionCreated
  SessionConfirmed ------------------------------------------>
  Data <--------------------------------------------------> Data

IPv4 परिचय, IPv6 परिचायक

एलिस                         बॉब                  चार्ली
  RelayRequest ======================>
       <============== RelayResponse    RelayIntro ----------->
       <-------------------------------------------- HolePunch
  SessionRequest -------------------------------------------->
       <-------------------------------------------- SessionCreated
  SessionConfirmed ------------------------------------------>
  Data <--------------------------------------------------> Data

IPv6 परिचय, IPv6 परिचायक

एलिस                         बॉब                  चार्ली
  RelayRequest ======================>
       <============== RelayResponse    RelayIntro ===========>
       <============================================ HolePunch
  SessionRequest ============================================>
       <============================================ SessionCreated
  SessionConfirmed ==========================================>
  Data <==================================================> Data

IPv6 परिचय, IPv4 परिचायक

एलिस                         बॉब                  चार्ली
  RelayRequest ---------------------->
       <-------------- RelayResponse    RelayIntro ===========>
       <============================================ HolePunch
  SessionRequest ============================================>
       <============================================ SessionCreated
  SessionConfirmed ==========================================>
  Data <==================================================> Data

डिज़ाइन

तीन बदलाव करने हैं।

• राउटर एड्रेस क्षमताओं में आउटबाउंड IPv4 और IPv6 समर्थन को इंगित करने के लिए “4” और “6” क्षमताएँ जोड़ें
• IPv6 परिचायकों के माध्यम से IPv4 परिचयों के लिए समर्थन जोड़ें
• IPv4 और IPv6 परिचायकों के माध्यम से IPv6 परिचयों के लिए समर्थन जोड़ें

विनिर्देश

4/6 कैप्स

यह मूल रूप से बिना औपचारिक प्रस्ताव के लागू किया गया था, लेकिन यह IPv6 परिचयों के लिए आवश्यक है, इसलिए इसे यहाँ शामिल किया गया है। देखें CAPS भी।

दो नई क्षमताएँ “4” और “6” परिभाषित की गई हैं। ये नई क्षमताएँ “कैप्स” संपत्ति में Router Address में जोड़ी जाएंगी, न कि Router Info कैप्स में। हमारे पास वर्तमान में NTCP2 के लिए “कैप्स” संपत्ति परिभाषित नहीं है। परिचयकों के साथ एक SSU एड्रेस, परिभाषा के अनुसार, अभी IPv4 है। हम IPv6 परिचय का बिल्कुल समर्थन नहीं करते। हालाँकि, यह प्रस्ताव IPv6 परिचयों के साथ संगत है। नीचे देखें।

इसके अलावा, एक राउटर एक ओवरले नेटवर्क के माध्यम से कनेक्टिविटी का समर्थन कर सकता है जैसे I2P-over-Yggdrasil, लेकिन एड्रेस प्रकाशित नहीं करना चाहता, या वह एड्रेस मानक IPv4 या IPv6 प्रारूप नहीं रखता। यह नई क्षमता प्रणाली इन नेटवर्क का समर्थन करने के लिए भी पर्याप्त लचीली होनी चाहिए।

हम निम्नलिखित बदलावों को परिभाषित करते हैं:

NTCP2: “कैप्स” संपत्ति जोड़ें

SSU: एक होस्ट या परिचयकों के बिना राउटर एड्रेस के लिए समर्थन जोड़ें, आउटबाउंड समर्थन को इंगित करने के लिए IPv4, IPv6, या दोनों के लिए।

दोनों ट्रांसपोर्ट्स: निम्नलिखित कैप्स मान परिभाषित करें:

• “4”: IPv4 समर्थन
• “6”: IPv6 समर्थन

एकल पते में कई मान समर्थित हो सकते हैं। नीचे देखें। कम से कम एक इन कैप्स के अनिवार्य हैं अगर Router Address में कोई “होस्ट” मान शामिल नहीं है। यदि Router Address में “होस्ट” मान शामिल है, तो अधिकतम एक इन कैप्स के वैकल्पिक है। ओवरले नेटवर्क या अन्य कनेक्टिविटी के समर्थन के लिए भविष्य में अतिरिक्त परिवहन कैप्स परिभाषित किए जा सकते हैं।

उपयोग मामले और उदाहरण

SSU:

होस्ट के साथ SSU: 4/6 वैकल्पिक, कभी एक से अधिक नहीं। उदाहरण: SSU caps=“4” host=“1.2.3.4” key=… port=“1234”

एक के लिए केवल आउटबाउंड के साथ SSU, अन्य प्रकाशित है: केवल कैप्स, 4/6। उदाहरण: SSU caps=“6”

परिचयकों के साथ SSU: कभी संयोजित नहीं। 4 या 6 आवश्यक है। उदाहरण: SSU caps=“4” iexp0=… ihost0=… iport0=… itag0=… key=…

छुपा हुआ SSU: केवल कैप्स, 4, 6, या 46। एकाधिक अनुमत हैं। 4 और 6 वाला एक पते के लिए दो एड्रेस की आवश्यकता नहीं है। उदाहरण: SSU caps=“46”

NTCP2:

होस्ट के साथ NTCP2: 4/6 वैकल्पिक, कभी एक से अधिक नहीं। उदाहरण: NTCP2 caps=“4” host=“1.2.3.4” i=… port=“1234” s=… v=“2”

एक के लिए केवल आउटबाउंड के साथ NTCP2, अन्य प्रकाशित है: केवल कैप्स, s, v, 4/6/y, एकाधिक अनुमत हैं। उदाहरण: NTCP2 caps=“6” i=… s=… v=“2”

छुपा हुआ NTCP2: केवल कैप्स, s, v, 4/6, एकाधिक अनुमत हैं 4 और 6 वाला एक पते के लिए दो एड्रेस की आवश्यकता नहीं है। उदाहरण: NTCP2 caps=“46” i=… s=… v=“2”

IPv4 के लिए IPv6 परिचायक

विशिष्टताओं में त्रुटियों और असंगतताओं को ठीक करने के लिए निम्नलिखित बदलाव आवश्यक हैं। हमने इसे प्रस्ताव के “भाग 1” के रूप में भी वर्णित किया है।

विशिष्टताओं में बदलाव

SSU वर्तमान में कहता है (IPv6 नोट्स):

IPv6 संस्करण 0.9.8 के रूप में समर्थित है। प्रकाशित रिले एड्रेस IPv4 या IPv6 हो सकता है, और एलिस-बॉब संचार IPv4 या IPv6 के माध्यम से हो सकता है।

निम्नलिखित जोड़ें:

जबकि संस्करण 0.9.8 के रूप में विशिष्टता को बदला गया था, एलिस-बॉब संचार IPv6 के माध्यम से वास्तव में संस्करण 0.9.50 तक समर्थित नहीं था। Java के पहले के संस्करणों ने IPv6 एड्रेस के लिए गलती से ‘C’ क्षमता प्रकाशित की, भले ही वे वास्तव में IPv6 के माध्यम से एक परिचायक के रूप में काम नहीं करते थे। इसलिए, राउटर्स को ‘C’ क्षमता पर केवल तभी भरोसा करना चाहिए जब IPv6 एड्रेस पर राउटर संस्करण 0.9.50 या उच्चतर हो।

SSU-SPEC वर्तमान में कहता है (Relay Request):

IP एड्रेस केवल शामिल किया जाता है यदि यह पैकेट के स्रोत एड्रेस और पोर्ट से अलग होता है। वर्तमान कार्यान्वयन में, IP लंबाई हमेशा 0 है और पोर्ट हमेशा 0 है, और रिसीवर को पैकेट के स्रोत एड्रेस और पोर्ट का उपयोग करना चाहिए। यह संदेश IPv4 या IPv6 के माध्यम से भेजा जा सकता है। अगर IPv6 है, तो एलिस को उसका IPv4 एड्रेस और पोर्ट शामिल करना होगा।

निम्नलिखित जोड़ें:

IP और पोर्ट को IPv6 पर इस संदेश को भेजते समय IPv4 एड्रेस का परिचय देने के लिए शामिल करना होगा। यह रिलीज 0.9.50 के रूप में समर्थित है।

IPv6 परिचाचे

SSU रिले संदेशों (RelayRequest, RelayResponse, और RelayIntro) में IP लंबाई फ़ील्ड होती है (ALice, Bob, या Charlie) IP एड्रेस की लंबाई का संकेत करने के लिए।

इसलिए, संदेशों के प्रारूप में कोई बदलाव की आवश्यकता नहीं है। केवल विशिष्टताओं के पाठ्य परिवर्तन की आवश्यकता है, संकेत देते हुए कि 16-बाइट IP एड्रेस की अनुमति है।

विशिष्टताओं में निम्नलिखित बदलाव आवश्यक हैं। हमने इसे प्रस्ताव के “भाग 2” के रूप में भी वर्णित किया है।

विशिष्टताओं में बदलाव

SSU वर्तमान में कहता है (IPv6 नोट्स):

बॉब-चार्ली और एलिस-चार्ली संचार केवल IPv4 के माध्यम से है।

SSU-SPEC वर्तमान में कहता है (Relay Request):

IPv6 के लिए रिले की योजना नहीं है।

बदलें और कहें:

रिलीज 0.9.xx के रूप में IPv6 के लिए रिले का समर्थन किया गया है

SSU-SPEC वर्तमान में कहता है (Relay Response):

चार्ली का IP एड्रेस IPv4 होना चाहिए, क्योंकि यह वह एड्रेस है जहां एलिस Hole Punch के बाद सत्र अनुरोध भेजेगी। IPv6 के लिए रिले की कोई योजना नहीं है।

बदलें और कहें:

चार्ली का IP एड्रेस IPv4 हो सकता है या, रिलीज 0.9.xx के रूप में, IPv6 हो सकता है। यह एड्रेस है जहां एलिस Hole Punch के बाद सत्र अनुरोध भेजेगी। रिलीज 0.9.xx के अनुसार IPv6 के लिए रिले का समर्थन किया गया है

SSU-SPEC वर्तमान में कहता है (Relay Intro):

वर्तमान कार्यान्वयन में, एलिस का IP एड्रेस हमेशा 4 बाइट्स होता है, क्योंकि एलिस चार्ली के साथ IPv4 के माध्यम से कनेक्ट करने की कोशिश कर रही है। यह संदेश स्थापित IPv4 कनेक्शन के माध्यम से भेजा जाना चाहिए, क्योंकि यही एकमात्र तरीका है जिससे बॉब को पता है कि चार्ली का IPv4 एड्रेस क्या है जिसे एलिस के पास RelayResponse में वापस करना है।

बदलें और कहें:

IPv4 के लिए, एलिस का IP एड्रेस हमेशा 4 बाइट्स होता है, क्योंकि एलिस चार्ली के साथ IPv4 के माध्यम से कनेक्ट करने की कोशिश कर रही है। रिलीज 0.9.xx के अनुसार, IPv6 समर्थित है, और एलिस का IP एड्रेस 16 बाइट्स हो सकता है।

IPv4 के लिए, यह संदेश स्थापित IPv4 कनेक्शन के माध्यम से भेजा जाना चाहिए, क्योंकि यही एकमात्र तरीका है जिससे बॉब को पता है कि चार्ली का IPv4 एड्रेस क्या है जिसे एलिस के पास RelayResponse में वापस करना है। रिलीज 0.9.xx के अनुसार, IPv6 समर्थित है, और यह संदेश स्थापित IPv6 कनेक्शन के माध्यम से भेजा जा सकता है।

इसके अलावा जोड़ें:

रिलीज 0.9.xx के अनुसार, किसी भी SSU पते में परिचयकों के साथ “कैप्स” विकल्प में “4” या “6” होना चाहिए।

माइग्रेशन

सभी पुराने राउटर्स को NTCP2 में “कैप्स” संपत्ति को और SSU कैप्स प्रॉपर्टी में अज्ञात क्षमता वर्णों को नजरअंदाज करना चाहिए।

किसी भी SSU एड्रेस में परिचयकर्ता होते हैं जिसमें “4” या “6” कैप नहीं है जो IPv4 परिचय के लिए समझा जाता है।