IPv6CP क्या तय करता है, और किसे अब भी प्रीफ़िक्स चाहिए
PPP इंटरफ़ेस पर लिंक-लोकल पता सेटअप का एक चरण है, IPv6 पहुँच नहीं। पहचानकर्ता की अदला-बदली को प्रीफ़िक्स, रूट और क्लाइंट एकीकरण से अलग रखें।
PPP इंटरफ़ेस पर IPv6 ऊपर आता है, एक लिंक-लोकल पता दिखाई देता है, और बदलाव को पूरा घोषित कर दिया जाता है। फिर कुछ भी रूट नहीं होता, कोई वैश्विक पता नहीं होता, और किसी सार्वजनिक गंतव्य तक की जाँच विफल हो जाती है जबकि इंटरफ़ेस अब भी कॉन्फ़िगर दिखता है। लिंक ऊपर आया; नेटवर्क कभी नहीं। नीचे दी गई चार जाँचें क्रम से करें और उसी पर रुकें जो अंतर समझाती है।
लिंक-लोकल पता वास्तव में क्या सिद्ध करता है
IPv6CP PPP लिंक पर IPv6 ऊपर लाता है और हर पक्ष के लिए एक इंटरफ़ेस पहचानकर्ता तय करता है। वह पहचानकर्ता एक लिंक-लोकल पता बनाता है, जो लिंक के पार साथी से बात करने के लिए पर्याप्त है और किसी और चीज़ तक पहुँचने के लिए पर्याप्त नहीं है। पता सिद्ध करता है कि लिंक IPv6 के लिए तैयार है, और साथी के पीछे के नेटवर्क के बारे में कुछ भी सिद्ध नहीं करता। इसे पहुँच पते के रूप में पढ़ना वही गलती है जिससे इनमें से अधिकांश जाँचें शुरू होती हैं।
नीचे दिए गए चार प्रश्न लिंक परत जो तय करती है, उसे इससे अलग करते हैं कि सेवा को क्या देना है। उनके उत्तर क्रम से दें, क्योंकि जब तक पहला प्रश्न खुला है, बाद वाले का उत्तर नहीं दिया जा सकता।
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
प्रीफ़िक्स कहाँ से आना चाहिए
वैश्विक पते को कहीं से एक प्रीफ़िक्स चाहिए: राउटर की घोषणा, सौंपा गया प्रीफ़िक्स, DHCPv6 या स्थिर कॉन्फ़िगरेशन। IPv6CP कोई प्रीफ़िक्स नहीं ले जाता, और लिंक पर कितना भी इंतज़ार करने से वह पैदा नहीं होगा। RFC 5072 IPv6CP को वह सेटअप चरण मानता है जो लिंक पर दूसरे IPv6 प्रोटोकॉल काम करने से पहले चलता है, और यही उसका पूरा दायरा है: लिंक तैयार करना, नेटवर्क को क्रमांक देना नहीं। प्रीफ़िक्स दें और इंटरफ़ेस केवल मौजूद रहने के बजाय ट्रैफ़िक ले जाने लगेगा।
राउटर की घोषणाएँ लैन पर सामान्य उत्तर हैं और पॉइंट-टू-पॉइंट टनल पर कम भरोसेमंद हैं, क्योंकि क्लाइंट को अनुरोध भेजना और उत्तर स्वीकार करना दोनों करना पड़ता है। कुछ टनल क्लाइंट इनमें से कोई भी नहीं करते। सर्वर को यह भेजना चाहिए या नहीं, यह तय करने से पहले जाँचें कि क्लाइंट क्या स्वीकार करने को तैयार है।
वही प्रीफ़िक्स दूसरे छोर से भी पहुँच योग्य होना चाहिए। जिस क्लाइंट के पास वैश्विक पता है पर वापसी का कोई रास्ता नहीं, वह कॉन्फ़िगर है, जुड़ा नहीं है।
रूट एक अलग वादा हैं
पते के बावजूद, क्लाइंट को जानना होगा कि कौन-से गंतव्य टनल के हैं, और सर्वर को उन गंतव्यों के लिए वापसी का रास्ता चाहिए। ये दो निर्णय दो जगह लिए जाते हैं। जो टनल सारा IPv6 ट्रैफ़िक ले जाती है, उसे क्लाइंट पर डिफ़ॉल्ट रूट और सर्वर पर वापसी रूट चाहिए; विभाजित टनल के लिए दोनों पक्षों को एक ही प्रीफ़िक्स सूची पर सहमत होना पड़ता है। जब वे सहमत नहीं होते, ट्रैफ़िक निकल जाता है और कभी वापस नहीं आता।
कुछ भी कॉन्फ़िगर करने से पहले सूची लिखें। यदि योजना कहती है कि केवल कॉर्पोरेट प्रीफ़िक्स टनल से जाता है, तो क्लाइंट के पास डिफ़ॉल्ट IPv6 रूट नहीं होना चाहिए, और सर्वर को उसकी घोषणा नहीं करनी चाहिए।
क्लाइंट एकीकरण बाकी तय करता है
कुछ टनल क्लाइंट IPv6 को स्पष्ट रूप से कॉन्फ़िगर करते हैं। उदाहरण के लिए, Apple का Network Extension टनल के लिए पता, प्रीफ़िक्स और रूट का एक समूह लेता है, इसलिए इसका उपयोग करने वाला ऐप्लिकेशन Ethernet शैली की घोषणा का इंतज़ार नहीं करता। अन्य लिंक पर आने वाली राउटर घोषणाओं पर निर्भर करते हैं। दोनों मॉडल वैध हैं और अलग सर्वर व्यवहार चाहते हैं, इसलिए गलत चुनाव ऐसा क्लाइंट बनाता है जो हमेशा ऐसे संदेश का इंतज़ार करता है जिसे कोई नहीं भेजता। सर्वर बदलने से पहले मॉडल पहचानें।
ppp0 जैसा पुराना इंटरफ़ेस नाम आज चल रहे स्टैक के बारे में कुछ सिद्ध नहीं करता। आधुनिक क्लाइंट PPP इंटरफ़ेस के बजाय पैकेट-टनल API का उपयोग कर सकता है, और यह मानना कि वह ऐतिहासिक कनेक्शन की तरह व्यवहार करता है, काम कर रहे डिज़ाइन को तोड़ने का तरीका है। इंटरफ़ेस नाम नहीं, क्लाइंट संस्करण और प्रोविज़निंग विधि पूछें।
वह योजना लिखें जो क्लाइंट को चाहिए
पूरा विवरण तीन बातें शामिल करता है: क्लाइंट के पास कौन-सा पता है, टनल को कौन-से गंतव्य ले जाने चाहिए, और नेटवर्क उत्तर वापस कैसे भेजता है। लिंक-लोकल पता इनमें से किसी का उत्तर नहीं देता, और स्वीकृत घोषणा केवल एक के एक भाग का उत्तर देती है। हरे संकेतक को स्वीकार करने के बजाय हर मद को अलग से जाँचें। फिर दर्ज करें कि किस तंत्र ने हर उत्तर दिया, क्योंकि वह अभिलेख अगली IPv6 रिपोर्ट को दो मिनट की जाँच बना देता है।
अभिलेख को सेवा दस्तावेज़ के साथ रखें और क्लाइंट बदलने पर उसे अद्यतन करें। PPP क्लाइंट के लिए सही योजना उसी सेवा पर पैकेट-टनल क्लाइंट के लिए गलत हो सकती है। चार प्रश्न वही रहते हैं; केवल उत्तर बदलते हैं।