क्या "IPv10" एक मजाक है या एक गंभीर RFC ड्राफ्ट है?


72

इंटरनेट प्रोटोकॉल संस्करण 10 (IPv10) विशिष्टता

नाम मजाकिया है (IPv4 + IPv6 == IPv10), लेकिन वास्तविक प्रस्ताव अजीब लगता है (पैकेट स्वरूपों के बीच असंगतता से लड़ने के लिए एक और पैकेट प्रारूप)।

क्या यह एक सामान्य प्रस्ताव है जिसमें गंभीर चेहरे के साथ "आईपीवी 10" का मजाक बनाने के लिए संतुलित पेशेवरों और विपक्षों या सिर्फ एक न्यूनतम व्यवहार्य दस्तावेज है?

यदि गंभीर है, तो कृपया इसे "tl; डॉ।" फैशन में बताएं। क्यों यह और nat64 / teredo की तरह एक और संक्रमण तकनीक नहीं?


9
जब शुरू में लिंक का अनुसरण कर रहा था तो मुझे "1 अप्रैल" देखने की उम्मीद थी।
वि।


4
जबकि प्रस्ताव एक मजाक हो सकता है, नाम नहीं है। IPv9 के माध्यम से IPv4 पहले से ही आरक्षित हैं (हालाँकि केवल IPv4 और IPv6 का उपयोग किया जाता है)। IPv10 अगला उपलब्ध अप्रकाशित संस्करण है।
user4556274

5
दिलचस्प बात यह है कि, लेखक ASN क्षेत्र के लिए 16bit का उपयोग करने का प्रस्ताव रखता है, जब 32bit ASN पहले से ही सामान्य अभ्यास है
Hagen von Eitzen

4
1 अप्रैल को पारंपरिक रूप से प्रकाशित, हल्के-फुल्के RFC की एक अच्छी परंपरा है। en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments शुरू करने के लिए एक अच्छी जगह है।
डोमिनिक क्रोनिन

जवाबों:


84

जैसा कि रॉन ने कहा, कोई भी एक प्रस्ताव लिख सकता है। मेरे पास एक कठिन समय है जो किसी ऐसे व्यक्ति से प्रस्तावों को गंभीरता से लेता है जो ऑप्टिकल फाइबर के साथ उपग्रहों को परस्पर जोड़ने का सुझाव देता है ।

इसके अलावा, मैं इस वास्तविक प्रस्ताव की कल्पना नहीं कर सकता, विशेष रूप से इस नोट के कारण:

सभी इंटरनेट से जुड़े होस्ट IPv10 होस्ट होने चाहिए जो कि उपयोग किए गए IP संस्करण की परवाह किए बिना संवाद करने में सक्षम हों, और IPv10 परिनियोजन प्रक्रिया को सभी नेटवर्किंग कंपनियों द्वारा पूरा किया जा सकता है जो होस्ट नेटवर्किंग और सुरक्षा उपकरणों के लिए OS विकसित कर रही हैं।

इसलिए, IPv4- केवल होस्ट की समस्या को हल करने के लिए IPv6- केवल होस्ट (और इसके विपरीत) से बात करने में सक्षम नहीं होने पर आपको एक और प्रोटोकॉल लागू करने की आवश्यकता है : IPv10। फिर, इससे परेशान क्यों न हों और उस IPv4 को केवल होस्ट पर ही लागू करें और उसके साथ काम करें।

इसके अलावा, जैसा कि RFC7059 में पढ़ा जा सकता है , पहले से ही पर्याप्त सुरंग तंत्र उपलब्ध हैं जिनका उपयोग इस समस्या के कुछ हिस्सों को हल करने के लिए किया जा सकता है।

ईमानदार होने के लिए, मुझे लगता है कि लेखक कॉपीराइट का दावा करके कुछ व्यावसायिक सफलता की उम्मीद कर रहा है, जैसा कि इन ट्वीट्स में पढ़ा जा सकता है :

घोषणा: कॉपीराइट की रक्षा करते हुए, #The_Road_Series CEO द्वारा # IPv10 और KHALED रूटिंग प्रोटोकॉल (#KRP या #RRP) विकसित किए गए हैं।

उन्हें अपने डेवलपर @Eng_Khaled_Omar से अनुमोदन के बिना किसी भी संगठन द्वारा प्रतिनिधित्व या प्रकाशित नहीं किया जाना चाहिए

आज २६ मई, २०१,, # रिपॉजिटरी से # IPv10 #KRP (#RRP) ड्राफ्ट निकालने के लिए एक २ निवेदन ietf को भेजा गया था।


15
वैसे आप जानते हैं कि वे क्या कहते हैं - आप अमूर्त की एक और परत के साथ सभी समस्याओं को हल कर सकते हैं, अमूर्त की कई परतों की समस्या को छोड़कर!
बाय

13
फाइबर द्वारा जुड़े उपग्रहों में ROFL। IPoAC जितना ही उचित लगता है।
रीहराब

14
वह कॉपीराइट से भाग्य से बाहर है। उन्होंने पहले से ही RFC प्रक्रिया में उलझाने के द्वारा IETF को कॉपीराइट सौंपा है, चाहे वह दस्तावेज के पाठ में ऐसा कुछ भी कहे, जो IETF नीतियों के अनुरूप नहीं है ।
user207421

14
मेरे दिमाग को फिर से प्रशिक्षित करने का समय नहीं जो कि मैं आरएफसी फॉर्मेट में पढ़ी गई बातों पर भरोसा नहीं करता।
मैट

6
ट्वीट लिंक ने मेरा दिन (/ सप्ताह / महीना) बना दिया
असफल वैज्ञानिक

27

आपको याद रखना चाहिए कि कोई भी IETF को प्रस्ताव प्रस्तुत कर सकता है, और उन्हें गंभीरता से लिया जाता है, जब तक कि वे ब्याज की कमी के कारण या तो अपनाए जाते हैं या मर जाते हैं।

यह विशेष प्रस्ताव समाप्त हो गया है और लेखक द्वारा कई बार नवीनीकृत किया गया है। ऐसा प्रतीत नहीं होता है, यदि कोई है, तो समर्थन करता है, और इसमें प्रस्तावित RFC स्थिति, जैसे मानक ट्रैक भी नहीं है। लेखक शायद अपने प्रस्ताव के बारे में गंभीर है, लेकिन वह इस प्रस्ताव के लिए किसी गंभीर समर्थन के लिए तैयार नहीं हुआ है।

वहाँ का प्रस्ताव है सूर्यास्त आईपीवी 4 कि है गंभीर है, और यह इसके पीछे एक पूर्ण कार्य समूह है, लेकिन यह पूर्ण गोद लेने के लिए इसे से आगे एक लंबी मुश्किल सड़क है। यह IPv4 से IPv6 के लिए संक्रमण में निहित समस्याओं को संबोधित करने का इरादा रखता है।


19

क्या "IPv10" एक मजाक है या एक गंभीर RFC ड्राफ्ट है?

दोनों। मुझे लगता है कि ब्लोक गंभीर है और उसे नहीं पता कि वह कौन सी हास्यास्पद योजनाएँ पेश कर रहा है। उस पर चुटकुला।

फाइबर उपग्रह प्रस्ताव भी अधिक ऊटपटांग के रूप में यह फाइबर लंबाई की आवश्यकता की उपेक्षा करता और पूरी तरह से कक्षीय यांत्रिकी पर ध्यान नहीं देता है।

IETF को उन्हें ट्रोलिंग के लिए ब्लॉक करना चाहिए।



1

यह एक वास्तविक समस्या को हल करने का एक गंभीर प्रयास है। समाधान अच्छा है या बुरा (यह शायद बकवास है), इसका समस्या कथन सही है: आईपीवी 6 को लागू करने की कोशिश की वर्तमान रणनीति अब तक विफल रही है। जैसा कि इसकी शुरूआत कहती है, आईपीवी 6 के 19 साल और अभी भी कोई रास्ता नहीं है कि हम खुद को किसी भी सार्थक तरीके से बदल सकें।

जैसा कि यह उल्लेख करता है, हमें पहले से ही कुछ समाधान मिल गए हैं जैसे कि NAT64 (इसमें दूसरों का भी उल्लेख है)। ये ठीक हैं और अच्छे हैं, लेकिन फिर भी IPv6 को पूर्ण संक्रमण की अनुमति नहीं देते हैं - वे मानते हैं कि सार्वजनिक IPv4- केवल होस्ट यहां रहने के लिए हैं।

उस ने कहा, मुझे इस बात पर संदेह है कि यह विनिर्देश आईपीवी 6 के संक्रमण के साथ मूलभूत समस्याओं को देखने में मेरी मदद कैसे करेगा । मैंने यह समझने में प्रयास करने में अधिक समय नहीं लगाया है कि यह कैसे करने की कोशिश करता है, और शायद यह मेरे मुकाबले समझदार है (हालांकि अन्य उत्तरों के बीच आम सहमति मुझे सही लगती है), लेकिन यह वही बूटस्ट्रैपिंग समस्या से ग्रस्त है जो IPv6 में है पहले स्थान पर।

उत्तर देने के लिए लेकिन यह अभी भी समस्या को हल करने का एक गंभीर प्रयास है।


1
सब कुछ आईपीवी 6 के लिए सालों से तैयार है। वास्तविक गोद लेना धीमा लग सकता है, और इसका कारण केवल यह है कि IPv4 अभी भी "काम करता है"। हालाँकि IPv6 ट्रैफिक लगभग 20% है और यह काफी तेजी से बढ़ रहा है। 2017 में आईपीवी 6 प्रदान नहीं करने वाली एक इंटरनेट सेवा को वास्तव में अपनी स्थिति पर पुनर्विचार करना चाहिए। वास्तव में अब जिस चीज की हमें जरूरत नहीं है वह एक और संक्रमण तंत्र है।
ch7kor

सब सच। लेकिन मुझे लगता है कि IPv6 कभी भी सार्थक पैठ तक नहीं पहुंचेगा (पहले 20% सबसे आसान माना जाता है, अंतिम 20% बहुत कठिन होना चाहिए) और एक दिन लोग आगे किसी और तरीके से फैसला करेंगे। संक्रमण को कम करने के इरादे से प्रौद्योगिकियों के बारे में बात यह है कि एक बार जब वे लंबे समय तक पर्याप्त होते हैं, तो आप महसूस करते हैं कि वे नए इंटरनेट बन गए हैं
थॉमस 23 अक्टूबर

3
दरअसल, कोई यह तर्क दे सकता है कि अंतिम 20% सबसे आसान होगा क्योंकि जब IPv6 में 80% इंटरनेट ट्रैफ़िक होगा, तो IPv4 को सूर्यास्त करने का प्रस्ताव शायद मानक होगा, और अधिकांश ISP IPv4 ट्रैफ़िक को रूट करना बंद कर देंगे। IPv6 की स्थापना से स्थिति को उलट दिया जाएगा ताकि IPv4 ट्रैफ़िक को (IPv6) इंटरनेट पर टनल किया जाए।
रॉन Maupin

0

एक नए प्रोटोकॉल के कार्यान्वयन के साथ कुछ वैधता है। वर्तमान अनुवाद प्रोटोकॉल NAT64 है।

NAT64 एक IPv6 संक्रमण तंत्र है जो नेटवर्क एड्रेस ट्रांसलेशन (NAT) के एक फॉर्म का उपयोग करके IPv6 और IPv4 होस्ट के बीच संचार की सुविधा प्रदान करता है। NAT64 गेटवे IPv4 और IPv6 प्रोटोकॉल के बीच एक अनुवादक है, 1 जिसके लिए इसे कम से कम एक IPv4 पता और IPv6 नेटवर्क सेगमेंट की आवश्यकता होती है जिसमें 32-बिट एड्रेस स्पेस होता है। IPv6 क्लाइंट IPv6 नेटवर्क सेगमेंट के होस्ट भाग का उपयोग करके संवाद करने की इच्छा रखने वाले IPv4 पते को एम्बेड करता है, जिसके परिणामस्वरूप IPv4-एम्बेडेड IPv6 पते (इसलिए IPv6 नेटवर्क सेगमेंट में 32-बिट एड्रेस स्पेस), और पैकेट भेजता है। परिणामी पता। NAT64 गेटवे IPv6 और IPv4 पतों के बीच एक मैपिंग बनाता है, जिसे मैन्युअल रूप से कॉन्फ़िगर या स्वचालित रूप से निर्धारित किया जा सकता है।

स्रोत

IPv10 के लिए मुख्य विचार NAT64 का उन्मूलन होगा। कड़े शब्दों में, NAT हमेशा एक अड़चन रहा है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.