यदि मान लीजिए कि क्लाइंट 68 पोर्ट पर नहीं सुनता है, तो जब डीएचसीपी सर्वर अनुरोध प्राप्त करता है, तो यह उसे उस अनुरोध से भेज सकता है जहां से यह अनुरोध प्राप्त हुआ है (भेजने के समय ग्राहक द्वारा चुने गए क्षणिक बंदरगाह के साथ), तो प्रोटोकॉल क्लाइंट को निर्दिष्ट क्यों करता है पोर्ट 68 पर सुनने के लिए?डीएचसीपी क्लाइंट पोर्ट 68 पर क्यों सुनता है?
क्योंकि यह आरएफसी (टिप्पणियों के लिए अनुरोध) में है जो निर्दिष्ट करता है कि डीएचसीपी कैसे व्यवहार करता है। आरएफसी 2131 वह दस्तावेज है जो निर्दिष्ट करता है कि एक डीएचसीपी क्लाइंट और सर्वर को कैसे व्यवहार करना चाहिए।
डीएचसीपी (विशेष रूप से धारा 4.1) पर अधिक जानकारी के लिए here देखें। आरएफसी क्या हैं, इस बारे में जानकारी के लिए here देखें।
मुख्य कारण यह है कि डीएचसीपी सर्वर मैक स्तर पर "डीएचसीपी प्रस्ताव" प्रसारित कर सकता है, इसे मैक पते पर यूनिकास्ट भेजने के बजाय अनुरोध प्राप्त हुआ था। यदि बंदरगाह स्थिर नहीं था, तो कुछ होस्ट जो इस यादृच्छिक बंदरगाह के मौके से सुन रहे हैं, पैकेट 5 - एप्लिकेशन परत पर पैकेट स्वीकार करेंगे। दूसरे शब्दों में, एक आवेदन पूरी तरह से अलग आवेदन से संदेश प्राप्त करेगा, स्वस्थ स्थिति नहीं।
यह उत्तर 3+ साल पहले से एक जैसा प्रतीत नहीं होता है। यदि आप कुछ जोड़ना चाहते हैं, तो मौजूदा, स्वीकृत उत्तर में एक संपादन का सुझाव देने पर विचार करें :) –
धन्यवाद, यह वास्तव में सही उत्तर है। – Parzifal
प्रासंगिक प्रश्न: क्या मैं इस पोर्ट को सामान्य सेटअप में सुरक्षित रूप से फ़ायरवॉल कर सकता हूं जहां आईपी पते प्राप्त करने के लिए एक डीएचसीपी क्लाइंट का उपयोग किया जाता है? अर्थात। वास्तविक दुनिया में प्रासंगिक * हो सकता है *? – Zero3
मैं सिर्फ अपने आप को एक ही सवाल का सामना करना पड़ा, और कुछ शोध के बाद, मैं, RFC 2131, जो DHCP प्रोटोकॉल का वर्णन करता है पर निम्नलिखित पाया धारा के तहत 1.6 डिजाइन लक्ष्य:
यूडीपी हैडर: मौजूदा BOOTP ग्राहकों
इसके अलावा, जो BOOTP प्रोटोकॉल का वर्णन, हम निम्नलिखित पा सकते हैं स्रोत और गंतव्य पोर्ट नंबर शामिल हैं। BOOTP प्रोटोकॉल दो आरक्षित पोर्ट नंबर, 'BOOTP क्लाइंट' (68) और 'BOOTP सर्वर' (67) का उपयोग करता है। क्लाइंट गंतव्य पोर्ट के रूप में 'BOOTP सर्वर' का उपयोग करके अनुरोध भेजता है; यह आमतौर पर एक प्रसारण है। सर्वर गंतव्य पोर्ट के रूप में 'BOOTP क्लाइंट' का उपयोग करके जवाब भेजता है; सर्वर में कर्नेल या ड्राइवर सुविधाओं के आधार पर, यह हो सकता है या प्रसारण नहीं हो सकता है (यह नीचे दिए गए 'चिकन/अंडे के मुद्दों' शीर्षक वाले अनुभाग में आगे बताया गया है)। दो आरक्षित बंदरगाहों का उपयोग किया जाता है, 'जागने' से बचने और BOOTP सर्वर डिमन्स शेड्यूल करने के लिए, जब एक बूटरली को क्लाइंट को प्रसारित किया जाना चाहिए। चूंकि सर्वर और अन्य होस्ट 'BOOTP क्लाइंट' पोर्ट, पर नहीं सुनेंगे, ऐसे किसी भी आने वाले प्रसारण कर्नेल स्तर पर फ़िल्टर किए जाएंगे। हम क्लाइंट को यूडीपी स्रोत पोर्ट फ़ील्ड के लिए 'यादृच्छिक' पोर्ट नंबर चुनने की अनुमति नहीं दे सके; चूंकि सर्वर का उत्तर प्रसारण हो सकता है, एक यादृच्छिक रूप से चुने गए पोर्ट नंबर अन्य होस्ट को भ्रमित कर सकता है जो उस बंदरगाह पर सुन रहा था।
तो प्रश्न का उत्तर उपर्युक्त से आता है। डीएचसीपी ग्राहकों को यूओडी पोर्ट 68 का उपयोग करने की आवश्यकता है, ताकि डीओसीपी बीओओटीपी प्रोटोकॉल के साथ संगत हो सके और BOOTP प्रोटोकॉल को क्लाइंट के लिए एक विशिष्ट बंदरगाह की आवश्यकता हो, क्योंकि BOOTPREPLIES को प्रसारित किया जा सकता है, और यदि क्लाइंट के लिए एक यादृच्छिक पोर्ट चुना गया था , इसके परिणामस्वरूप एक ही बंदरगाह पर अन्य मेजबानों के भ्रम का परिणाम हो सकता है।
प्रश्न पढ़ता है "प्रोटोकॉल क्लाइंट को बंदरगाह 68 पर सुनने के लिए क्यों निर्दिष्ट करता है?", तो वे जो पूछ रहे हैं वह अधिक है "आरएफसी ऐसा क्यों कहता है?" –
डीएचसीपी पहले के BOOTP प्रोटोकॉल पर आधारित है जो पोर्ट्स 67 (सर्वर) और 68 (क्लाइंट) का उपयोग करता है।बीओओटीपी ने उन बंदरगाहों का उपयोग क्यों किया क्योंकि संभवतः वे उस समय के किसी अन्य प्रोटोकॉल द्वारा अप्रयुक्त थे (एसएमटीपी 25 का उपयोग करता है, एफ़टीपी 21 का उपयोग करता है आदि)। जबकि एक मेजबान के पास आमतौर पर एक ही आईपी पता होता है, इसमें हजारों बंदरगाह हो सकते हैं। विशिष्ट प्रोटोकॉल को विशेष पोर्ट नंबर निर्दिष्ट करके कई पार्टियों के लिए मानक सेवाओं और ग्राहकों को विकसित करना संभव था। जब तक आप सही बंदरगाह पर सुनते हैं, तो आप अपना स्वयं का डीएचसीपी क्लाइंट या सर्वर लिख सकते हैं। – TLiebe
ठीक है मतलब कोई तकनीकी कारण नहीं है? – avd