250M से अधिक आरक्षित IPv4 पते जारी किए जा सकते हैं
लंबे समय से आरक्षित IPv4 ब्लॉक (240.0.0.0/4) को पुनर्वर्गीकृत करने और संभावित उपयोग के लिए पेश किया जा रहा है, जिससे बहस छिड़ गई है कि क्या इससे address shortage वाकई कम होगी या सिर्फ chaos पैदा होगा। Network engineers बताते हैं कि कई routers, operating systems, और consumer devices इस range को या तो block करते हैं या गलत तरीके से संभालते हैं, इसलिए इसे सक्षम करने से connectivity खंडित हो जाएगी और जहाँ ज़रूरत हो वहाँ IPv6 तथा carrier-grade NAT तैनात करना कहीं आसान होगा। अन्य लोग नोट करते हैं कि बड़े संगठनों और governments के पास अब भी कम उपयोग किए गए IPv4 space हैं और तर्क देते हैं कि उन allocations को वापस लेना या बेहतर प्रबंधित करना — साथ ही गंभीर IPv6 rollout — 240/4 को आज के internet में retrofit करने से अधिक प्रभावी होगा।
240/4 प्रस्ताव का दायरा
- 240/4 वर्तमान में “आरक्षित” है; प्रस्ताव इसे unicast के रूप में पुनर्वर्गीकृत करने का है, न कि (मुख्य प्रस्ताव में) निजी RFC1918 space के रूप में।
- यह पहले से कुछ VPNs, SDNs, और cloud/internal networks में non-routable hop space के रूप में उपयोग हो रहा है।
- समर्थकों का तर्क है कि बस IANA/IETF status अपडेट कर देना “वास्तविकता से मेल” खाएगा और यह अधिकतर एक policy/ledger बदलाव है।
व्यवहार्यता और संगतता संबंधी चिंताएँ
- कई टिप्पणीकारों का तर्क है कि public internet पर 240/4 को deploy करना वस्तुतः असंभव है:
- OSes (विशेष रूप से Windows) इसे assign या use करने से इनकार करते हैं।
- Routers और middleboxes अक्सर इसे hard-block करते हैं।
- आंशिक reachability का debug करना एक nightmare होगा (कुछ paths काम करेंगे, कुछ silently drop हो जाएंगे)।
- अन्य लोग जवाब देते हैं कि:
- कई routers (जैसे OpenWRT, विभिन्न IoT OSes) इसे पहले से स्वीकार करते हैं।
- Windows support को “patch Tuesday” में बदला जा सकता है, और 240/4 को special-case करने वाले code paths को बस हटाया जा सकता है।
- इस पर असहमति है कि क्या 240/4 पर मौजूदा internal “squatters” public use को रोकने चाहिए (कुछ कहते हैं “उनकी समस्या,” अन्य कहते हैं कि इससे यह de facto private space बन जाता है)।
Private Space बनाम Public Unicast
- कुछ लोग चाहते हैं कि बड़े internal networks के लिए, जिन्होंने 10/8 समाप्त कर लिया है, खासकर mergers और बहुत बड़े enterprises में, 240/4 को RFC1918 में जोड़ा जाए।
- अन्य लोगों का मानना है कि IPv4 का लगभग 6% private space के रूप में उपयोग करना व्यर्थ है; यदि पुनर्वर्गीकृत किया जाए तो reserved space public बनना चाहिए।
- DoD /8s पर squat करने वाले संगठनों और संघीय सरकार के कई idle /8s रखने से तुलना की जाती है।
IPv6 बनाम IPv4 को निचोड़ना
- बड़ी संख्या का मत: 240/4 को जारी करना “बहुत कम, बहुत देर से” है और IPv6 से ध्यान भटकाता है। एक /4 जल्दी ही समाप्त हो जाएगा और fragmentation बढ़ाएगा।
- प्रतिवाद: 240/4, 0/8, और “.0 broadcast” addresses को वापस लेने से सार्थक IPv4 मुक्त हो सकता है, और 0/8 के लिए पहले से लागू patches ने इंटरनेट को नहीं तोड़ा।
- IPv6 deployment असमान है:
- कुछ ISPs (कई fiber providers सहित) IPv6 नहीं देते; कुछ जो देते हैं वे केवल dynamic /64s या छोटे, अस्थिर prefixes देते हैं।
- Consumer gear में अक्सर buggy या opaque IPv6 implementations होती हैं; support “बहुत अच्छा काम करता है” से लेकर “6 घंटे की परेशानी और custom daemons” तक फैला हुआ है।
- Users को अक्सर “बस IPv6 disable कर दो” कहा जाता है, जिसे कुछ लोग ignorance और कुछ लोग टूटे हुए devices के लिए व्यावहारिक workaround मानते हैं।
CGNAT, सुरक्षा, और नीति
- Residential IPv4 के लिए CGNAT को अपरिहार्य माना जाता है; कुछ लोग external pools के लिए 240/4 का उपयोग करने का सुझाव देते हैं।
- चिंता जताई गई कि routable IPv6 असुरक्षित IoT devices को उजागर करता है; अन्य लोग जवाब देते हैं कि firewalls और विशाल IPv6 space के कारण blind scanning IPv4 की तुलना में बहुत कठिन है।
- यदि 240/4 public बनता है, तो कई लोगों को उम्मीद है कि RIRs allocations को कड़ाई से नियंत्रित करेंगे और संभवतः उन networks को प्राथमिकता देंगे जो पहले से IPv6 deploy करते हैं, जिससे बड़े खिलाड़ियों की hoard करने की क्षमता सीमित होगी।