IPv4 रास्ते में खंडित करता है; IPv6 इसके बजाय पैकेट बहुत बड़ा संदेश भेजता है
केवल IPv4 राउटर ही बहुत बड़े पैकेट को खंडित कर सकते हैं। IPv6 अपेक्षा करता है कि भेजने वाला पैकेट बहुत बड़ा संदेश पर प्रतिक्रिया दे, जिसे एक सुरंग या छनी हुई ICMP नियम तोड़ सकते हैं।
IPv6 की विफलताओं का दोष प्रोटोकॉल पर कहीं अधिक मढ़ा जाता है, बजाय उस पैकेट के आकार के जिसने उन्हें पैदा किया। दोनों परिवार वाकई बहुत बड़े पैकेट को अलग तरह से संभालते हैं, और सुरंग ही वह चीज़ है जो इस अंतर को मायने रखने वाला बनाती है। IPv4 राउटर नियमों के अनुमति देने पर पैकेट को खंडित कर सकते हैं, जबकि IPv6 राउटर रास्ते में खंडन बिल्कुल नहीं कर सकते। IPv6 इसके बजाय भेजने वाले को बताता है, और भेजने वाले से प्रतिक्रिया की अपेक्षा होती है। इसके बाद जो कुछ भी गड़बड़ होता है, वह इस बात से निकलता है कि वह संदेश पहुँचता है या नहीं।
हर परिवार क्या करता है
तालिका चार पंक्तियों में तंत्र है, और एक पंक्ति अधिकांश भ्रम समझा देती है।
| Behaviour | IPv4 | IPv6 |
|---|---|---|
| Router fragments an oversized packet | Allowed while DF is clear | Never |
| Signal returned to the sender | ICMP Fragmentation Needed | ICMPv6 Packet Too Big |
| Size that must always work | 68 bytes | 1280 bytes |
| Fragmentation possible | Routers or source | Source only |
IPv6 में रास्ते में खंडन नहीं है और साफ़ करने के लिए कोई DF फ़्लैग नहीं है, इसलिए पैकेट बहुत बड़ा होने पर लौटने के लिए कुछ नहीं है। भेजने वाले को बताना पड़ता है, और भेजने वाले को यह मानना पड़ता है।
सुरंग रास्ते को चुपचाप सँकरा करती है
VPN बाहरी हेडर जोड़ता है, और एन्क्रिप्टेड स्थिति में अखंडता का डेटा भी, इससे पहले कि पैकेट होस्ट छोड़े। भीतरी पैकेट उस इंटरफ़ेस MTU में फ़िट हो सकता है जो वह देखता है, जबकि बाहरी पैकेट अगली कड़ी की सीमा से आगे निकल जाता है, और इसीलिए यह पहले सुरंग में दिखता है। सुरंग इंटरफ़ेस का MTU जानबूझकर घटाएँ, या रास्ते पर TCP MSS कसें, और लिखें कि आपने कौन-सी संख्या चुनी और क्यों।
ESP का ओवरहेड मोड और एल्गोरिदम पर निर्भर है, इसलिए सही सुरंग MTU एक गणना है, कोई परंपरा नहीं। आप जो भी चुनें, उसे पूरे 1280 बाइट के भीतरी IPv6 पैकेट के लिए जगह छोड़नी चाहिए, क्योंकि हर IPv6 कड़ी को इतना ढोना होता है। जो सुरंग 1280 बाइट IPv6 नहीं ढो सकती वह ट्यूनिंग की समस्या नहीं है; वह उस परिवार के लिए टूटा रास्ता है। यही बाधा तब हटती है जब MTU मान किसी केवल-IPv4 परिनियोजन से नक़ल किया जाता है।
लक्षण अटकना क्यों लगता है
विफलता साफ़ त्रुटि नहीं है, और इसीलिए उसका ग़लत निदान होता है। TCP हैंडशेक पूरा होता है, छोटी प्रतिक्रियाएँ आती हैं, और बड़ी प्रतिक्रिया या बड़ा अपलोड शुरू होते ही कनेक्शन अटक जाता है, क्योंकि वही पहले पैकेट हैं जो गिराए जाने के लिए पर्याप्त बड़े हैं। SSH जुड़ता है और फिर पहले बड़े आउटपुट पर अटक जाता है, और पृष्ठ का हेडर लोड होता है जबकि मुख्य भाग कभी पूरा नहीं होता।
अगर ICMPv6 के पैकेट बहुत बड़ा संदेश छान लिए जाएँ, तो भेजने वाले को कभी पता नहीं चलता और वह वही आकार दोहराता रहता है। यह काला छेद है, धीमा रास्ता नहीं, और इसकी पहचान दोहराई जा सकने वाली आकार-सीमा है, न कि यादृच्छिक हानि। संबंधित नियंत्रण ट्रैफ़िक को अनुमत रखना काम करते IPv6 परिनियोजन का हिस्सा है, उपकार नहीं।
जिन संदेशों पर आपका अपना रास्ता निर्भर है उन्हें बंद करके फिर परिणाम को IPv6 की ख़राबी मत कहिए। यही तर्क IPv4 के Fragmentation Needed संदेशों पर भी लागू है, जो फ़ायरवॉल लेखकों में उतने ही अलोकप्रिय और उतने ही ज़रूरी हैं।
सीमा मापें, फिर परत ठीक करें
अनुमान लगाने के बजाय जाँचें: IPv4 पर don't-fragment फ़्लैग और IPv6 पर तय पेलोड आकार इस्तेमाल करें, और दर्ज करें कि प्रतिक्रियाएँ कहाँ रुकती हैं। ping -M do -s 1472 और ping -6 -s 1400 समस्या का आकार तय करने के लिए पर्याप्त हैं, और tracepath रास्ते में खोजा गया पथ MTU बताता है।
फिर उस परत को ठीक करें जिसके पास वह संख्या है: सुरंग इंटरफ़ेस का MTU, TCP के लिए MSS क्लैंप, या रास्ता ही। IPv6 नियम के लिए RFC 8200 संदर्भ है, और यह उस घटना से छोटा पाठ है जिसे यह रोकता है।
उस परिवार की जाँच करें जो एप्लिकेशन वास्तव में इस्तेमाल करता है, क्योंकि दोहरे ढेर वाला नाम एक परिवार पर जवाब दे सकता है और दूसरे पर नहीं, और नेटवर्क बदलने के बाद एप्लिकेशन बदल सकता है। जिस पते की जाँच की उसे दर्ज करें, क्योंकि A रिकॉर्ड के मुक़ाबले परिणाम AAAA रिकॉर्ड के बारे में कुछ नहीं कहता।
आकार-सीमा को प्रमाण मानें
दोहराई जा सकने वाली आकार-सीमा उन गिनी-चुनी नेटवर्क ख़राबियों में है जो हर बार ठीक उसी बाइट संख्या पर, उसी स्रोत से दोहराई जाती हैं। इससे यह रहस्य नहीं, उपहार बन जाती है, और इसका यह भी अर्थ है कि सुधार की आशा करने के बजाय उसे सत्यापित किया जा सकता है।
खोजा गया MTU, आपने कॉन्फ़िगर किया सुरंग MTU और वह परीक्षण जिसने अंतर साबित किया, टिकट में लिखें। अगला व्यक्ति किसी दूसरी कड़ी पर वही गणित पाएगा।