मैक एड्रेस प्राप्त करने के लिए आपको IPv6 नेबर सॉलिसिटर की आवश्यकता क्यों है?

Question

मैं एक सॉफ्टवेयर डेवलपर हूं और बस मुझे Techv पर IPv6 के बारे में एक मुफ्त पुस्तक मिली, जिसे मैं मनोरंजन के लिए पढ़ रहा हूं। उन्होंने इसे दूर कर दिया क्योंकि यह एक पुरानी किताब (W2008) का एक सा है, इसलिए हो सकता है कि चीजें अन्य / नए OSes के लिए अलग हों, लेकिन मैं मैक एड्रेस प्राप्त करने के लिए नेबर डिस्कवरी की आवश्यकता को नहीं समझता।

पुस्तक के अनुसार, प्रत्येक नोड को स्वचालित रूप से एक लिंक-स्थानीय आईपी-पता प्राप्त होता है, जो कि मैक-पते से FF-FEतीसरे और चौथे बाइट्स के बीच डालने और यू / एल बिट को फ़्लिप करके बनाया जाता है, ताकि लिंक-स्थानीय आईपी एक के लिए मैक पते के साथ नोड 00-AA-00-3F-2A-1Cबन जाता है FE80::2AA:FF:FE:3F:2A1C।

लिंक परत मैक पते को निर्धारित करने के लिए, एक पड़ोसी सॉलिसिटेशन संदेश लिंक-स्थानीय आईपी पते पर भेजा जाता है, जो अपने मैक पते वाले संदेश के साथ उत्तर देता है ... लेकिन प्रेषक पहले से ही जानता है, क्योंकि मैक लिंक में एन्कोडेड है- स्थानीय आईपी पता। तो ऐसा लगता है कि किसी को अपना पता पूछने के लिए पोस्टकार्ड मेल करना चाहिए।

Answer 1

प्रत्येक नोड स्वचालित रूप से एक लिंक-स्थानीय पता बनाता है, लेकिन:

• वह पता RFC 2464 में निर्दिष्ट EUI-64 प्रारूप के साथ उत्पन्न नहीं हो सकता है । IPv6 पते क्रिप्टोग्राफिक रूप से उत्पन्न पते ( RFC 3972 ), अस्थायी गोपनीयता पते ( RFC 4941 ), या आधुनिक ऑपरेटिंग सिस्टम में, स्थिर गोपनीयता पते ( RFC 7217 ) हो सकते हैं।

• ऐसा पता जो दिखता है, उसमें EUI-64 इंटरफ़ेस ID है जो वास्तव में किसी व्यवस्थापक द्वारा स्पष्ट कॉन्फ़िगरेशन के कारण संकेतित मैक पते के अनुरूप नहीं हो सकता है।

चूँकि आप मैक पते को सिर्फ "एड्रेस बैक को कन्वर्ट" नहीं कर सकते, इसलिए आपको मैक एड्रेस निर्धारित करने के लिए नेबर सॉलिसिटेशन भेजना होगा।

पड़ोसी के कारण आवश्यक होने के साथ-साथ अन्य कारण भी हैं। इनमें से कुछ हैं:

• डुप्लिकेट एड्रेस डिटेक्शन ( RFC 4862 )। यह संभव है कि कुछ अन्य होस्ट (सही या गलत तरीके से) ने एक पते का दावा किया हो जो एक होस्ट उपयोग करना चाहता है।
• पड़ोसी की अप्रतिस्पर्धी पहचान। पड़ोसी सॉलिसिटेशन की प्रतिक्रिया की कमी एक संकेतक है कि पड़ोसी पहुंच से बाहर है।

किताबें सभी अच्छी और अच्छी हैं, लेकिन बहुत पुरानी किताबें इतनी उपयोगी नहीं हो सकती हैं। यहां तक ​​कि आईपीवी 6 में पिछले दस वर्षों में महत्वपूर्ण संशोधन हुए हैं। सच्चाई का सबसे अच्छा स्रोत प्रासंगिक आरएफसी हैं, दोनों मूल और कोई भी जो उन्हें अद्यतन या बाधित होने के रूप में चिह्नित किया गया है। RFC को पर्याप्त विस्तार से निर्दिष्ट किया जाता है ताकि अनुरूप कार्यान्वयन को लिखा जा सके। आप RFC 4861 को पढ़कर पड़ोसी खोज के सभी विवरण जान सकते हैं ।

Comments

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

— एडविन

@ ईडविन, SLAAC को मूल रूप से सभी IPv6 एड्रेसिंग के लिए इस्तेमाल किया गया था, न केवल लिंक-लोकल एड्रेस के लिए, इसलिए एक होस्ट को ट्रैक किया जा सकता था। लिंक-स्थानीय पते असाइन करने के लिए SLAAC केवल एक विधि है। उन्हें मैन्युअल रूप से भी सौंपा जा सकता है, और यह आपको लिंक-स्थानीय पते में मैक एड्रेस नहीं देगा। मैं कुछ ऐसे लोगों को जानता हूँ जो लिंक लोकल सहित सभी पतों को मैन्युअली असाइन करना चाहते हैं। यह बिना किसी लाभ के बहुत से काम के लिए लगता है, लेकिन यह उन्हें खुश करता है, और एक इंटरफ़ेस पर सभी पतों के सभी IID एक ही हैं, एक क्रम में जिसे वे पसंद करते हैं।

— रॉन मौपिन

@ ईडविन और, प्रत्येक मेजबान वास्तव में एक डेस्टिनेशन कैश (आरएफसी 4861 देखें) बनाए रखेगा, जो आईपीवी 4 एआरपी तालिका के अनुरूप है जो मेजबान बनाए रखता है।

— माइकल हैम्पटन

CGA सरल और अधिक सुरक्षित हो सकता था यदि पते दो बार आकार के होते। आधा युक्ति इंटरफ़ेस पहचानकर्ता में केवल 64 बिट्स के लिए वर्कअराउंड है जहां वे आदर्श रूप से 162 बिट्स के आसपास चाहते थे। यह याद रखने वाली बात है कि जब भी विचार आता है कि 128 बिट्स बहुत अधिक है।

— कास्परड

आप उस Microsoft दस्तावेज़ के बारे में क्या गैर-मानक मानते हैं? मेरे लिए ऐसा लगता है कि यह सिर्फ आपके द्वारा लिंक किए गए RFC को संक्षेप में प्रस्तुत करता है।

— कास्परड

Answer 2

इसलिए, आप या तो गलत समझ रहे हैं या कुछ चीजों पर गलत जानकारी दी गई है।

SLAAC का उपयोग करके एक होस्ट अपने मैक पते का उपयोग करके अपने खुद के IPv6 पते का निर्माण कर सकता है, लेकिन बहुत से लोगों ने सोचा कि यह खतरनाक था, बहुत अधिक जानकारी देना और किसी विशेष होस्ट को ट्रैक करने की अनुमति देना। उसके आधार पर, गोपनीयता एक्सटेंशन और यादृच्छिक पते विकसित किए गए थे, और उनका उपयोग गोपनीयता / सुरक्षा प्रदान करने के लिए OSes द्वारा किया जाता है। इसका मतलब है कि एक मेजबान अपने मैक पते के आधार पर, अपने स्वयं के पते को बना सकता है।

जब एक होस्ट को आईपीवी 4 में पड़ोसी के मैक पते की खोज करने की आवश्यकता होती है, तो वह एआरपी का उपयोग करता है। ARP एक अनुरोध प्रसारित करता है, लेकिन IPv6 का प्रसारण नहीं होता है। इसके बजाय, प्रत्येक होस्ट को एक सॉलिसिटेड नोड मल्टीकास्ट समूह में शामिल होना चाहिए। यह समूह अपने IPv6 पते के अंतिम 24 बिट्स पर आधारित है। चूंकि IPv6 इंटरफेस में किसी भी IPv6 पते की संख्या हो सकती है, एक होस्ट कई सॉलिसिटेड नोड मल्टीकास्ट समूहों में शामिल हो सकता है। एक अन्य होस्ट के मैक पते की तलाश में एक आईपीवी 6 होस्ट, लक्ष्य आईपीवी 6 पते के सॉलिसिटेड नोड मल्टीकास्ट समूह के लिए एक मल्टीकास्ट अनुरोध भेजेगा।

यह IPv4 ARP पर एक लाभ प्रदान करता है। चूँकि ARP अनुरोधों के लिए प्रसारण का उपयोग करता है, इसलिए यह लेयर -2 प्रसारण डोमेन के प्रत्येक होस्ट को बाधित करता है। क्योंकि सॉलिसिटेड नोड मल्टीकास्ट समूह लक्ष्य आईपीवी 6 पते के अंतिम 24 बिट्स का उपयोग करता है, एनडी मल्टीकास्ट अनुरोध शायद लेयर -2 प्रसारण डोमेन पर केवल लक्ष्य होस्ट या संभवतः एक या दो अन्य होस्ट को बाधित करेगा।