इंटरनेट नियंत्रण संदेश प्रोटोकॉल: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(5 intermediate revisions by 3 users not shown)
Line 30: Line 30:
{{about|आईसीएमपीवी4|आईसीएमपीवी6|आईसीएमपीवी6}}
{{about|आईसीएमपीवी4|आईसीएमपीवी6|आईसीएमपीवी6}}


इंटरनेट कंट्रोल मैसेज प्रोटोकॉल (आईसीएमपी) [[इंटरनेट प्रोटोकॉल सूट]] में एक सहायक [[संचार प्रोटोकॉल]] है। इसका उपयोग [[राउटर (कंप्यूटिंग)]] सहित [[नेटवर्क उपकरण]]ों द्वारा किया जाता है, त्रुटि संदेश भेजने के लिए और किसी अन्य आईपी पते के साथ संचार करते समय सफलता या विफलता का संकेत देने वाली परिचालन जानकारी, उदाहरण के लिए, एक अनुरोधित सेवा उपलब्ध नहीं होने पर एक त्रुटि इंगित की जाती है या एक होस्ट ( नेटवर्क) या राउटर तक नहीं पहुंचा जा सका।<ref name="Forouzan">{{cite book | author=Forouzan, Behrouz A. | title=डेटा संचार और नेटवर्किंग| url=https://archive.org/details/datacommunicatio00foro_184 | url-access=limited | edition=Fourth | publisher=McGraw-Hill | location=Boston | year=2007 |pages=[https://archive.org/details/datacommunicatio00foro_184/page/n657 621]–630 | isbn=978-0-07-296775-3 }}</ref> आईसीएमपी [[ प्रसारण नियंत्रण प्रोटोकॉल ]] और [[डेटाग्राम प्रोटेकॉलका उपयोग करें]] जैसे [[ परिवहन प्रोटोकॉल ]] से अलग है, क्योंकि यह सामान्यतः सिस्टम के बीच डेटा का आदान-प्रदान करने के लिए उपयोग नहीं किया जाता है, न ही यह एंड-यूज़र नेटवर्क एप्लिकेशन द्वारा नियमित रूप से नियोजित किया जाता है '''(कुछ''' '''डायग्नोस्टिक टूल जैसे''' पिंग '''(नेटवर्किंग) के अपवाद के साथ। यूटिलिटी)''' और [[ट्रेसरूट]] ) जैसे कुछ नैदानिक ​​उपकरणों के अपवाद के साथ)।।
इंटरनेट कंट्रोल मैसेज प्रोटोकॉल (आईसीएमपी) [[इंटरनेट प्रोटोकॉल सूट]] में सहायक [[संचार प्रोटोकॉल]] है। इसका उपयोग [[राउटर (कंप्यूटिंग)]] सहित [[नेटवर्क उपकरण]] द्वारा किया जाता है, त्रुटि संदेश भेजने के लिए और किसी अन्य आईपी पते के साथ संचार करते समय सफलता या विफलता का संकेत देने वाली परिचालन जानकारी, उदाहरण के लिए, अनुरोधित सेवा उपलब्ध नहीं होने पर त्रुटि इंगित की जाती है या होस्ट ( नेटवर्क) या राउटर तक नहीं पहुंचा जा सका।<ref name="Forouzan">{{cite book | author=Forouzan, Behrouz A. | title=डेटा संचार और नेटवर्किंग| url=https://archive.org/details/datacommunicatio00foro_184 | url-access=limited | edition=Fourth | publisher=McGraw-Hill | location=Boston | year=2007 |pages=[https://archive.org/details/datacommunicatio00foro_184/page/n657 621]–630 | isbn=978-0-07-296775-3 }}</ref> आईसीएमपी [[ प्रसारण नियंत्रण प्रोटोकॉल |प्रसारण नियंत्रण प्रोटोकॉल]] और [[डेटाग्राम प्रोटेकॉलका उपयोग करें]] जैसे [[ परिवहन प्रोटोकॉल |परिवहन प्रोटोकॉल]] से अलग है, क्योंकि यह सामान्यतः सिस्टम के बीच डेटा का आदान-प्रदान करने के लिए उपयोग नहीं किया जाता है, न ही यह एंड-यूज़र नेटवर्क एप्लिकेशन द्वारा नियमित रूप से नियोजित किया जाता है और [[ट्रेसरूट]] ) जैसे कुछ नैदानिक ​​उपकरणों के अपवाद के साथ)


[[IPv4]] के लिए आईसीएमपीमें परिभाषित किया गया है {{IETF RFC|792}}. RFC 4443 द्वारा परिभाषित एक अलग [[ICMPv6]], [[IPv6]] के साथ प्रयोग किया जाता है।
[[IPv4]] के लिए आईसीएमपीमें परिभाषित किया गया है {{IETF RFC|792}}. RFC 4443 द्वारा परिभाषित एक अलग [[ICMPv6]], [[IPv6]] के साथ प्रयोग किया जाता है।
Line 39: Line 39:
आईसीएमपी[[इंटरनेट प्रोटोकॉल]] सूट का भाग है जैसा कि RFC 792 में परिभाषित किया गया है। आईसीएमपीसंदेश सामान्यतः निदान या नियंत्रण उद्देश्यों के लिए उपयोग किए जाते हैं या इंटरनेट प्रोटोकॉल संचालन में त्रुटियों के उत्तर में उत्पन्न होते हैं (जैसा कि RFC 1122 में निर्दिष्ट है)। आईसीएमपीत्रुटियाँ मूल पैकेट के स्रोत आईपी पते पर निर्देशित की जाती हैं।<ref name="Forouzan" />  
आईसीएमपी[[इंटरनेट प्रोटोकॉल]] सूट का भाग है जैसा कि RFC 792 में परिभाषित किया गया है। आईसीएमपीसंदेश सामान्यतः निदान या नियंत्रण उद्देश्यों के लिए उपयोग किए जाते हैं या इंटरनेट प्रोटोकॉल संचालन में त्रुटियों के उत्तर में उत्पन्न होते हैं (जैसा कि RFC 1122 में निर्दिष्ट है)। आईसीएमपीत्रुटियाँ मूल पैकेट के स्रोत आईपी पते पर निर्देशित की जाती हैं।<ref name="Forouzan" />  


उदाहरण के लिए, प्रत्येक डिवाइस (जैसे एक इंटरमीडिएट राउटर (कंप्यूटिंग)) एक आईपी [[आंकड़ारेख]] को अग्रेषित करने से पहले आईपी हेडर में रहने के समय (टीटीएल) फ़ील्ड को एक से कम कर देता है। यदि परिणामी TTL 0 है, तो पैकेट को छोड़ दिया जाता है और डेटाग्राम के स्रोत पते पर एक आईसीएमपी#समय से अधिक संदेश भेजा जाता है।
उदाहरण के लिए, प्रत्येक डिवाइस (जैसे इंटरमीडिएट राउटर (कंप्यूटिंग)) आईपी [[आंकड़ारेख]] को अग्रेषित करने से पहले आईपी हेडर में रहने के समय (टीटीएल) फ़ील्ड को एक से कम कर देता है। यदि परिणामी TTL 0 है, तो पैकेट को छोड़ दिया जाता है और डेटाग्राम के स्रोत पते पर आईसीएमपी समय से अधिक संदेश भेजा जाता है।


सामान्यतः उपयोग की जाने वाली कई नेटवर्क उपयोगिताएँ आईसीएमपीसंदेशों पर आधारित होती हैं। ट्रेसरूट कमांड को आईपी डेटाग्राम को विशेष रूप से सेट आईपी टीटीएल हेडर फ़ील्ड के साथ प्रसारित करके कार्यान्वित किया जा सकता है, और आईसीएमपी समय पारगमन में पार हो गया है और प्रतिक्रिया में उत्पन्न # गंतव्य अगम्य संदेशों की तलाश कर रहा है। संबंधित पिंग (नेटवर्किंग यूटिलिटी) यूटिलिटी आईसीएमपीइको रिक्वेस्ट और इको रिप्लाई मैसेज का उपयोग करके कार्यान्वित की जाती है।
सामान्यतः उपयोग की जाने वाली कई नेटवर्क उपयोगिताएँ आईसीएमपीसंदेशों पर आधारित होती हैं। ट्रेसरूट कमांड को आईपी डेटाग्राम को विशेष रूप से सेट आईपी टीटीएल हेडर फ़ील्ड के साथ प्रसारित करके कार्यान्वित किया जा सकता है, और आईसीएमपी समय पारगमन में पार हो गया है और प्रतिक्रिया में उत्पन्न # गंतव्य अगम्य संदेशों की तलाश कर रहा है। संबंधित पिंग (नेटवर्किंग यूटिलिटी) यूटिलिटी आईसीएमपीइको रिक्वेस्ट और इको रिप्लाई मैसेज का उपयोग करके कार्यान्वित की जाती है।


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


आईसीएमपीएक [[ नेटवर्क परत | नेटवर्क परत]] '''| नेटवर्क-लेयर''' प्रोटोकॉल है, जो इसे 7 लेयर OSI मॉडल द्वारा लेयर 3 प्रोटोकॉल बनाता है। 4 परत टीसीपी/आईपी मॉडल के आधार पर, आईसीएमपी एक [[इंटरनेट परत]] है। इंटरनेट-परत प्रोटोकॉल, जो इसे परत 2 प्रोटोकॉल (4 परतों वाला इंटरनेट मानक आरएफसी 1122 टीसीपी/आईपी मॉडल) या आधुनिक 5 परत टीसीपी पर आधारित परत 3 प्रोटोकॉल बनाता है। /आईपी प्रोटोकॉल परिभाषाएँ (कोज़िएरोक, कॉमर, तनेनबाउम, फ़ोरोज़न, कुरोज़, स्टालिंग्स द्वारा)।{{CN|date=January 2023}} फ़ोरोज़न और कुरोस अपनी टीसीपी /आईपी मॉडल परिभाषा में इंटरनेट-लेयर के अतिरिक्त नेटवर्क-लेयर का उपयोग करते हैं। मॉडलों के बीच ये अंतर अक्सर व्यर्थ और अंतहीन बहस का कारण बनते हैं।{{According to whom|date=April 2023}}
आईसीएमपी[[ नेटवर्क परत | नेटवर्क परत]] प्रोटोकॉल है, जो इसे 7 लेयर OSI मॉडल द्वारा लेयर 3 प्रोटोकॉल बनाता है। 4 परत टीसीपी/आईपी मॉडल के आधार पर, आईसीएमपी [[इंटरनेट परत]] है। इंटरनेट-परत प्रोटोकॉल, जो इसे परत 2 प्रोटोकॉल (4 परतों वाला इंटरनेट मानक आरएफसी 1122 टीसीपी/आईपी मॉडल) या आधुनिक 5 परत टीसीपी पर आधारित परत 3 प्रोटोकॉल बनाता है। /आईपी प्रोटोकॉल परिभाषाएँ (कोज़िएरोक, कॉमर, तनेनबाउम, फ़ोरोज़न, कुरोज़, स्टालिंग्स द्वारा)। फ़ोरोज़न और कुरोस अपनी टीसीपी /आईपी मॉडल परिभाषा में इंटरनेट-लेयर के अतिरिक्त नेटवर्क-लेयर का उपयोग करते हैं। मॉडलों के बीच ये अंतर अक्सर व्यर्थ और अंतहीन बहस का कारण बनते हैं।


आईसीएमपीपैकेट के साथ कोई टीसीपी या यूडीपी पोर्ट नंबर नहीं जुड़ा है क्योंकि ये नंबर ऊपर [[ ट्रांसपोर्ट परत | ट्रांसपोर्ट परत]] से जुड़े हैं।<ref>{{Cite web | title = ओएसआई मॉडल सात परतों की परिभाषा और कार्यों की व्याख्या| work = Microsoft Support | access-date = 2014-12-28 | url = https://support.microsoft.com/kb/103884}}</ref>
आईसीएमपीपैकेट के साथ कोई टीसीपी या यूडीपी पोर्ट नंबर नहीं जुड़ा है क्योंकि ये नंबर ऊपर [[ ट्रांसपोर्ट परत |ट्रांसपोर्ट परत]] से जुड़े हैं।<ref>{{Cite web | title = ओएसआई मॉडल सात परतों की परिभाषा और कार्यों की व्याख्या| work = Microsoft Support | access-date = 2014-12-28 | url = https://support.microsoft.com/kb/103884}}</ref>




Line 55: Line 55:


=== हैडर ===
=== हैडर ===
आईसीएमपी हेडर IPv4#Header के बाद प्रारंभ होता है और आईपी प्रोटोकॉल नंबर '1' की सूची द्वारा पहचाना जाता है।<ref>{{cite web|title=प्रोटोकॉल नंबर|url=https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml|publisher=Internet Assigned Numbers Authority|access-date=2011-06-23}}</ref> सभी आईसीएमपी पैकेट में 8-बाइट हेडर और वेरिएबल-साइज़ डेटा सेक्शन होता है। हेडर के पहले 4 बाइट्स का प्रारूप निश्चित होता है, जबकि अंतिम 4 बाइट्स उस आईसीएमपीपैकेट के प्रकार/कोड पर निर्भर करते हैं।<ref name="Forouzan" />
आईसीएमपी हेडर IPv4 हैडर के बाद प्रारंभ होता है और आईपी प्रोटोकॉल नंबर '1' की सूची द्वारा पहचाना जाता है।<ref>{{cite web|title=प्रोटोकॉल नंबर|url=https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml|publisher=Internet Assigned Numbers Authority|access-date=2011-06-23}}</ref> सभी आईसीएमपी पैकेट में 8-बाइट हेडर और वेरिएबल-साइज़ डेटा सेक्शन होता है। हेडर के पहले 4 बाइट्स का प्रारूप निश्चित होता है, जबकि अंतिम 4 बाइट्स उस आईसीएमपीपैकेट के प्रकार/कोड पर निर्भर करते हैं।<ref name="Forouzan" />


{| class="wikitable"
{| class="wikitable"
Line 113: Line 113:
|-
|-
|}
|}
; प्रकार {{anchor|header_type}}: आईसीएमपी प्रकार, देखें {{slink||संदेशों को नियंत्रित करें}}.
; प्रकार : आईसीएमपी प्रकार, देखें {{slink||संदेशों को नियंत्रित करें}}.
; कोड {{anchor|header_code}}: आईसीएमपी उपप्रकार, देखें {{slink||संदेशों को नियंत्रित करें}}.
; कोड : आईसीएमपी उपप्रकार, देखें {{slink||संदेशों को नियंत्रित करें}}.
; अंततः, {{anchor|header_checksum}}: त्रुटि जाँच के लिए इंटरनेट चेकसम (RFC 1071), आईसीएमपीहेडर से गणना की जाती है और इस फ़ील्ड के लिए मान 0 के साथ डेटा प्रतिस्थापित किया जाता है।
; अंततः, : त्रुटि जाँच के लिए इंटरनेट चेकसम (RFC 1071), आईसीएमपीहेडर से गणना की जाती है और इस फ़ील्ड के लिए मान 0 के साथ डेटा प्रतिस्थापित किया जाता है।
; बाकी हेडर {{anchor|header_rest}}: चार-बाइट फ़ील्ड, सामग्री आईसीएमपी प्रकार और कोड के आधार पर भिन्न होती है।
; बाकी हेडर : चार-बाइट फ़ील्ड, सामग्री आईसीएमपी प्रकार और कोड के आधार पर भिन्न होती है।


=== डेटा ===
=== डेटा ===
आईसीएमपी त्रुटि संदेशों में एक डेटा खंड होता है जिसमें संपूर्ण IPv4 हेडर की एक प्रति, साथ ही IPv4 पैकेट से डेटा के कम से कम पहले आठ बाइट्स सम्मिलित होते हैं जो त्रुटि संदेश का कारण बनते हैं। आईसीएमपी त्रुटि संदेशों की लंबाई 576 बाइट्स से अधिक नहीं होनी चाहिए।<ref>{{cite IETF |rfc=1812 |title=Requirements for IP Version 4 Routers}}</ref> इस डेटा का उपयोग होस्ट द्वारा संदेश को उपयुक्त प्रक्रिया से मिलाने के लिए किया जाता है। यदि एक उच्च स्तरीय प्रोटोकॉल पोर्ट नंबरों का उपयोग करता है, तो उन्हें मूल डेटाग्राम के डेटा के पहले आठ बाइट्स में माना जाता है।<ref name=rfc792/>
आईसीएमपी त्रुटि संदेशों में डेटा खंड होता है जिसमें संपूर्ण IPv4 हेडर की प्रति, साथ ही IPv4 पैकेट से डेटा के कम से कम पहले आठ बाइट्स सम्मिलित होते हैं जो त्रुटि संदेश का कारण बनते हैं। आईसीएमपी त्रुटि संदेशों की लंबाई 576 बाइट्स से अधिक नहीं होनी चाहिए।<ref>{{cite IETF |rfc=1812 |title=Requirements for IP Version 4 Routers}}</ref> इस डेटा का उपयोग होस्ट द्वारा संदेश को उपयुक्त प्रक्रिया से मिलाने के लिए किया जाता है। यदि उच्च स्तरीय प्रोटोकॉल पोर्ट नंबरों का उपयोग करता है, तो उन्हें मूल डेटाग्राम के डेटा के पहले आठ बाइट्स में माना जाता है।<ref name=rfc792/>


आईसीएमपी पैकेट डेटा सेक्शन का चर आकार [[शोषण (कंप्यूटर सुरक्षा)]] किया गया है। मौत के पिंग में, बड़े या खंडित आईसीएमपी पैकेट का उपयोग डिनायल-ऑफ़-सर्विस हमलों के लिए किया जाता है। संचार के लिए [[गुप्त चैनल]] बनाने के लिए आईसीएमपीडेटा का भी उपयोग किया जा सकता है। इन चैनलों को आईसीएमपीटनल के रूप में जाना जाता है।
आईसीएमपी पैकेट डेटा सेक्शन का चर आकार [[शोषण (कंप्यूटर सुरक्षा)]] किया गया है। मौत के पिंग में, बड़े या खंडित आईसीएमपी पैकेट का उपयोग डिनायल-ऑफ़-सर्विस हमलों के लिए किया जाता है। संचार के लिए [[गुप्त चैनल]] बनाने के लिए आईसीएमपीडेटा का भी उपयोग किया जा सकता है। इन चैनलों को आईसीएमपीटनल के रूप में जाना जाता है।
Line 130: Line 130:
|-
|-
||0 –इको रिप्लाई<ref name="rfc792">{{cite rfc|title=Internet Control Message Protocol|rfc=792|last=Postel|first=J.|date=September 1981|publisher=[[Internet Engineering Task Force|IETF]]}}</ref>{{rp|14}}
||0 –इको रिप्लाई<ref name="rfc792">{{cite rfc|title=Internet Control Message Protocol|rfc=792|last=Postel|first=J.|date=September 1981|publisher=[[Internet Engineering Task Force|IETF]]}}</ref>{{rp|14}}
|                0    || || प्रतिध्वनि उत्तर '''(used to''' [[Ping (networking utility)|(पिंग के लिए प्रयुक्त)]])
|                0    || || प्रतिध्वनि उत्तर [[Ping (networking utility)|(पिंग के लिए प्रयुक्त)]])
|-
|-
||1 और 2
||1 और 2
|                      || {{n/a|unassigned}} || ''Reserved''
|                      || {{n/a|unassigned}} || ''आरक्षित''
|-
|-
|rowspan=16|3 – Destination Unreachable<ref name=rfc792/>{{rp|4}}
|rowspan=16|3 – Destination Unreachable<ref name=rfc792/>{{rp|4}}
|                  0  || || Destination network unreachable
|                  0  || || गंतव्य नेटवर्क पहुंच से बाहर है
|-
|-
|                  1  || || Destination host unreachable
|                  1  || || मेजबान के गंतव्य संपर्क से बाहर है
|-
|-
|                  2  || || Destination protocol unreachable
|                  2  || || गंतव्य प्रोटोकॉल पहुंच योग्य नहीं है
|-
|-
|                  3  || || Destination port unreachable
|                  3  || || गंतव्य बंदरगाह पहुंच योग्य नहीं है
|-
|-
|                  4  || || Fragmentation required, and [[IPv4 packet|DF flag]] set
|                  4  || || विखंडन की आवश्यकता है, और [[IPv4 packet|DF फ्लैग]] सेट
|-
|-
|                  5  || || Source route failed
|                  5  || || स्रोत मार्ग विफल रहा
|-
|-
|                  6  || || Destination network unknown
|                  6  || || गंतव्य नेटवर्क अज्ञात
|-
|-
|                  7  || || Destination host unknown
|                  7  || || गंतव्य नेटवर्क अज्ञात
|-
|-
|                  8  || || Source host isolated
|                  8  || || स्रोत होस्ट अलग किया गया
|-
|-
|                  9  || || Network administratively prohibited
|                  9  || || नेटवर्क प्रशासनिक रूप से प्रतिबंधित है
|-
|-
|                10  || || Host administratively prohibited
|                10  || || मेजबान प्रशासनिक रूप से निषिद्ध
|-
|-
|                11  || || Network unreachable for [[Type of service|ToS]]
|                11  || || नेटवर्क के लिए पहुंच योग्य नहीं है [[Type of service|ToS]]
|-
|-
|                12  || || Host unreachable for [[Type of service|ToS]]
|                12  || || होस्ट के लिए पहुंच योग्य नहीं है [[Type of service|ToS]]
|-
|-
|                13  || || Communication administratively prohibited
|                13  || || संचार प्रशासनिक रूप से प्रतिबंधित है
|-
|-
|                14  || || Host Precedence Violation
|                14  || || होस्ट प्राथमिकता का उल्लंघन
|-
|-
|                15  || || Precedence cutoff in effect
|                15  || || वरीयता कटऑफ प्रभावी है
|-
|-
| 4 – Source Quench
| 4 – Source Quench
|                  0  || {{dc|deprecated}}|| Source quench (congestion control)
|                  0  || {{dc|deprecated}}|| स्रोत शमन (भीड़ नियंत्रण)
|-
|-
|rowspan=4| 5 – Redirect Message
|rowspan=4| 5 – Redirect Message
|                  0  || || Redirect Datagram for the Network
|                  0  || || नेटवर्क के लिए पुनर्निर्देशित डेटाग्राम
|-
|-
|                  1  || || Redirect Datagram for the Host
|                  1  || || होस्ट के लिए रीडायरेक्ट डेटाग्राम
|-
|-
|                  2  || || Redirect Datagram for the [[Type of service|ToS]] & network
|                  2  || || के लिए पुनर्निर्देशित डेटाग्राम [[Type of service|ToS]] & नेटवर्क
|-
|-
|                  3  || || Redirect Datagram for the [[Type of service|ToS]] & host
|                  3  || || के लिए पुनर्निर्देशित डेटाग्राम [[Type of service|ToS]] & होस्ट
|-
|-
| 6            ||      || {{dc|deprecated}}|| Alternate Host Address
| 6            ||      || {{dc|deprecated}}|| वैकल्पिक होस्ट पता
|-
|-
| 7            ||      || {{n/a|unassigned}} || ''Reserved''
| 7            ||      || {{n/a|unassigned}} || ''आरक्षित''
|-
|-
| 8 – Echo Request
| 8 – Echo Request
|                  0  || || Echo request (used to ping)
|                  0  || || इको अनुरोध (पिंग करने के लिए प्रयुक्त)
|-
|-
| 9 – [[ICMP Router Discovery Protocol|Router Advertisement]]
| 9 – [[ICMP Router Discovery Protocol|Router Advertisement]]
|                  0  || || Router Advertisement
|                  0  || || राउटर विज्ञापन
|-
|-
| 10 – [[ICMP Router Discovery Protocol|Router Solicitation]]
| 10 – [[ICMP Router Discovery Protocol|Router Solicitation]]
|                  0  || || Router discovery/selection/solicitation
|                  0  || || राउटर की खोज/चयन/याचना
|-
|-
|rowspan=2| 11 – [[ICMP Time Exceeded|Time Exceeded]]<ref name=rfc792/>{{rp|6}}
|rowspan=2| 11 – [[ICMP Time Exceeded|Time Exceeded]]<ref name=rfc792/>{{rp|6}}
|                  0  || || TTL expired in transit
|                  0  || || TTL ट्रांज़िट में समाप्त हो गया
|-
|-
|                  1  || || Fragment reassembly time exceeded
|                  1  || || फ़्रैगमेंट को फिर से जोड़ने का समय पार हो गया है
|-
|-
|rowspan=3| 12 – Parameter Problem: Bad आईपी header
|rowspan=3| 12 – Parameter Problem: Bad आईपी header
|                  0  || || Pointer indicates the error
|                  0  || || सूचक त्रुटि को इंगित करता है
|-
|-
|                  1  || || Missing a required option
|                  1  || || एक आवश्यक विकल्प गुम है
|-
|-
|                  2  || || Bad length
|                  2  || || खराब लंबाई
|-
|-
| 13 – Timestamp
| 13 – समय-चिह्न
|                  0  || || Timestamp
|                  0  || || समय-चिह्न
|-
|-
| 14 – Timestamp Reply
| 14 – टाइमस्टैम्प उत्तर
|                  0  || || Timestamp reply
|                  0  || || टाइमस्टैम्प उत्तर
|-
|-
| 15 – Information Request
| 15 – जानकारी अनुरोध
|                  0  || {{dc|deprecated}}|| Information Request
|                  0  || {{dc|deprecated}}|| जानकारी अनुरोध
|-
|-
| 16 – Information Reply
| 16 – सूचना उत्तर
|                  0  || {{dc|deprecated}}|| Information Reply
|                  0  || {{dc|deprecated}}|| सूचना उत्तर
|-
|-
| 17 – Address Mask Request
| 17 – एड्रेस मास्क रिक्वेस्ट
|                  0  || {{dc|deprecated}}|| Address Mask Request
|                  0  || {{dc|deprecated}}|| एड्रेस मास्क रिक्वेस्ट
|-
|-
| 18 – Address Mask Reply
| 18 – एड्रेस मास्क रिक्वेस्ट
|                  0  || {{dc|deprecated}}|| Address Mask Reply
|                  0  || {{dc|deprecated}}|| एड्रेस मास्क रिक्वेस्ट
|-
|-
| 19          ||      || reserved || ''Reserved'' for security
| 19          ||      || reserved || सुरक्षा के लिए आरक्षित
|-
|-
| 20 through 29||      || reserved || ''Reserved'' for robustness experiment
| 20 through 29||      || reserved || मजबूती प्रयोग के लिए आरक्षित
|-
|-
| 30 – [[Traceroute]]
| 30 – [[Traceroute]]
|                  0  || {{dc|deprecated}}|| Information Request
|                  0  || {{dc|deprecated}}|| जानकारी अनुरोध
|-
|-
| 31          ||      || {{dc|deprecated}}|| Datagram Conversion Error
| 31          ||      || {{dc|deprecated}}|| डेटाग्राम रूपांतरण त्रुटि
|-
|-
| 32          ||      || {{dc|deprecated}}|| Mobile Host Redirect
| 32          ||      || {{dc|deprecated}}|| मोबाइल होस्ट पुनर्निर्देशन
|-
|-
| 33          ||      || {{dc|deprecated}}|| Where-Are-You (originally meant for [[IPv6]])
| 33          ||      || {{dc|deprecated}}|| व्हेयर-अरे-यू (मूल रूप से के लिए [[IPv6]] था)
|-
|-
| 34          ||      || {{dc|deprecated}}|| Here-I-Am (originally meant for IPv6)
| 34          ||      || {{dc|deprecated}}|| हियर-आई-एम (मूल रूप से इसका अर्थ IPv6 था)
|-
|-
| 35          ||      || {{dc|deprecated}}|| Mobile Registration Request
| 35          ||      || {{dc|deprecated}}|| मोबाइल पंजीकरण अनुरोध
|-
|-
| 36          ||      || {{dc|deprecated}}|| Mobile Registration Reply
| 36          ||      || {{dc|deprecated}}|| मोबाइल पंजीकरण उत्तर
|-
|-
| 37          ||      || {{dc|deprecated}}|| Domain Name Request
| 37          ||      || {{dc|deprecated}}|| डोमेन नाम अनुरोध
|-
|-
| 38          ||      || {{dc|deprecated}}|| Domain Name Reply
| 38          ||      || {{dc|deprecated}}|| डोमेन नाम उत्तर
|-
|-
| 39          ||      || {{dc|deprecated}}|| SKआईपी Algorithm Discovery Protocol, [[Simple Key-Management for Internet Protocol]]
| 39          ||      || {{dc|deprecated}}|| एसकेआईपी एल्गोरिथम डिस्कवरी प्रोटोकॉल, [[Simple Key-Management for Internet Protocol|इंटरनेट प्रोटोकॉल के लिए सरल कुंजी-प्रबंधन]]
|-
|-
| 40          ||      || || [[Photuris (protocol)|Photuris]], Security failures
| 40          ||      || || [[Photuris (protocol)|फोटोरिस]], सुरक्षा विफलताएं
|-
|-
| 41          ||      || {{table-experimental}} || आईसीएमपीfor experimental mobility protocols such as [[Seamoby]] [RFC4065]
| 41          ||      || {{table-experimental}} || आईसीएमपी प्रयोगात्मक गतिशीलता प्रोटोकॉल के लिए जैसे [[Seamoby|सीमोबी]] [RFC4065]
|-
|-
| 42 – Extended Echo Request<ref name="RFC 8335">{{cite IETF |title=PROBE: A Utility for Probing Interfaces |rfc=8335}}</ref>
| 42 – Extended Echo Request<ref name="RFC 8335">{{cite IETF |title=PROBE: A Utility for Probing Interfaces |rfc=8335}}</ref>
|                  0  || || Request Extended Echo (XPing - see [https://tools.ietf.org/html/draft-bonica-intarea-eping-04 '''Extended Ping (Xping)'''])
|                  0  || || विस्तारित इको का अनुरोध करें (XPing - see [https://tools.ietf.org/html/draft-bonica-intarea-eping-04 '''Extended Ping (Xping)'''])
|-
|-
| rowspan=5| 43 – Extended Echo Reply<ref name="RFC 8335"/>
| rowspan=5| 43 – Extended Echo Reply<ref name="RFC 8335"/>
|                  0  || || No Error
|                  0  || || कोई ग़लती नहीं
|-
|-
|                  1  || || Malformed Query
|                  1  || || विकृत क्वेरी
|-
|-
|                  2  || || No Such Interface
|                  2  || || ऐसा कोई इंटरफ़ेस नहीं
|-
|-
|                  3  || || No Such Table Entry
|                  3  || || ऐसी कोई तालिका प्रविष्टि नहीं
|-
|-
|                  4  || || Multiple Interfaces Satisfy Query
|                  4  || || एकाधिक इंटरफेस क्वेरी को संतुष्ट करते हैं
|-
|-
| 44 through 252 ||    || {{n/a|unassigned}} || ''Reserved''
| 44 through 252 ||    || {{n/a|unassigned}} || ''सुरक्षित''
|-
|-
| 253 || || {{table-experimental}} || RFC3692-style Experiment 1 (RFC 4727)
| 253 || || {{table-experimental}} || RFC3692-शैली प्रयोग 1 (RFC 4727)
|-
|-
| 254 || || {{table-experimental}} || RFC3692-style Experiment 2 (RFC 4727)
| 254 || || {{table-experimental}} || RFC3692-शैली प्रयोग 2 (RFC 4727)
|-
|-
| 255 || || reserved || Reserved
| 255 || || सुरक्षित || सुरक्षित
|}
|}


Line 279: Line 279:
स्रोत बुझाना अनुरोध करता है कि प्रेषक राउटर या होस्ट को भेजे गए संदेशों की दर कम कर देता है। यह संदेश उत्पन्न हो सकता है यदि राउटर या होस्ट के पास अनुरोध को संसाधित करने के लिए पर्याप्त बफर स्थान नहीं है, या यदि राउटर या होस्ट बफर अपनी सीमा तक पहुंच रहा है तो यह संदेश उत्पन्न हो सकता है।
स्रोत बुझाना अनुरोध करता है कि प्रेषक राउटर या होस्ट को भेजे गए संदेशों की दर कम कर देता है। यह संदेश उत्पन्न हो सकता है यदि राउटर या होस्ट के पास अनुरोध को संसाधित करने के लिए पर्याप्त बफर स्थान नहीं है, या यदि राउटर या होस्ट बफर अपनी सीमा तक पहुंच रहा है तो यह संदेश उत्पन्न हो सकता है।


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


चूंकि अनुसंधान ने सुझाव दिया कि आईसीएमपीस्रोत कुंच [था] भीड़भाड़ के लिए एक अप्रभावी (और अनुचित) मारक है,<ref>{{IETF RFC|6633}}</ref> 1995 में RFC 1812 द्वारा रूटर के सोर्स क्वेंच संदेशों के निर्माण को रोक दिया गया था।
चूंकि अनुसंधान ने सुझाव दिया कि आईसीएमपीस्रोत कुंच [था] भीड़भाड़ के लिए अप्रभावी (और अनुचित) मारक है,<ref>{{IETF RFC|6633}}</ref> 1995 में RFC 1812 द्वारा रूटर के सोर्स क्वेंच संदेशों के निर्माण को रोक दिया गया था।


{| class="wikitable"
{| class="wikitable"
|+Source quench message<ref name=rfc792/>{{rp|9}}
|+स्रोत शमन संदेश<ref name=rfc792/>{{rp|9}}
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
Line 290: Line 290:
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="8"| Type = 4
| colspan="8"| टाइप = 4
| colspan="8"| Code = 0
| colspan="8"| कोड = 0
| colspan="16"| Checksum
| colspan="16"| चेकसम
|-
|-
| colspan="32" style="text-align:center;"| unused
| colspan="32" style="text-align:center;"| अप्रयुक्त
|-
|-
| colspan="32" style="text-align:center;"| आईपी header and first 8 bytes of original datagram's data
| colspan="32" style="text-align:center;"| आईपी हेडर और मूल डेटाग्राम के डेटा के पहले 8 बाइट्स
|}
|}
कहाँ:
जहाँ:
: प्रकार 4 पर सेट होना चाहिए
: प्रकार 4 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
Line 304: Line 304:


=== रीडायरेक्ट ===
=== रीडायरेक्ट ===
[[File:ICMPv4 redirect message example-en.svg|thumb|ICMPv4 रीडायरेक्ट संदेश कैसे काम करता है इसका एक उदाहरण]]रीडायरेक्ट अनुरोध डेटा पैकेट वैकल्पिक मार्ग पर भेजे जाएं। आईसीएमपीरीडायरेक्ट राउटर्स के लिए मेजबानों को रूटिंग जानकारी देने के लिए एक तंत्र है। संदेश एक मेजबान को अपनी रूटिंग जानकारी अपडेट करने के लिए सूचित करता है (वैकल्पिक मार्ग पर पैकेट भेजने के लिए)। यदि कोई होस्ट एक राउटर (कंप्यूटिंग) (R1) के माध्यम से डेटा भेजने की कोशिश करता है और R1 दूसरे राउटर (R2) पर डेटा भेजता है और होस्ट से R2 के लिए एक सीधा रास्ता उपलब्ध है (यानी, होस्ट और R2 एक ही पर हैं) [[ subnetwork ]]), तो R1 मेजबान को सूचित करने के लिए एक पुनर्निर्देशित संदेश भेजेगा कि गंतव्य के लिए सबसे अच्छा मार्ग R2 के माध्यम से है। इसके बाद मेजबान को अपनी रूट सूचना बदलनी चाहिए और उस गंतव्य के लिए सीधे R2 को पैकेट भेजना चाहिए। राउटर अभी भी मूल डेटाग्राम को इच्छित गंतव्य पर भेजेगा।<ref>{{cite web |url=http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094702.shtml |title=When Are ICMP Redirects Sent? |publisher=[[Cisco Systems]] |date=2008-06-28 |access-date=2013-08-15 }}</ref> चुकीं, यदि डेटाग्राम में रूटिंग जानकारी है, तो बेहतर मार्ग उपलब्ध होने पर भी यह संदेश नहीं भेजा जाएगा। RFC 1122 में कहा गया है कि रीडायरेक्ट केवल [[गेटवे (दूरसंचार)]] द्वारा भेजा जाना चाहिए और इंटरनेट होस्ट द्वारा नहीं भेजा जाना चाहिए।
[[File:ICMPv4 redirect message example-en.svg|thumb|ICMPv4 रीडायरेक्ट संदेश कैसे काम करता है इसका उदाहरण]]रीडायरेक्ट अनुरोध डेटा पैकेट वैकल्पिक मार्ग पर भेजे जाएं। आईसीएमपीरीडायरेक्ट राउटर्स के लिए मेजबानों को रूटिंग जानकारी देने के लिए तंत्र है। संदेश एक मेजबान को अपनी रूटिंग जानकारी अपडेट करने के लिए सूचित करता है (वैकल्पिक मार्ग पर पैकेट भेजने के लिए)। यदि कोई होस्ट राउटर (कंप्यूटिंग) (R1) के माध्यम से डेटा भेजने की कोशिश करता है और R1 दूसरे राउटर (R2) पर डेटा भेजता है और होस्ट से R2 के लिए सीधा रास्ता उपलब्ध है (यानी, होस्ट और R2 एक ही पर हैं) [[ subnetwork |सब नेटवर्क]] ), तो R1 मेजबान को सूचित करने के लिए पुनर्निर्देशित संदेश भेजेगा कि गंतव्य के लिए सबसे अच्छा मार्ग R2 के माध्यम से है। इसके बाद मेजबान को अपनी रूट सूचना बदलनी चाहिए और उस गंतव्य के लिए सीधे R2 को पैकेट भेजना चाहिए। राउटर अभी भी मूल डेटाग्राम को इच्छित गंतव्य पर भेजेगा।<ref>{{cite web |url=http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094702.shtml |title=When Are ICMP Redirects Sent? |publisher=[[Cisco Systems]] |date=2008-06-28 |access-date=2013-08-15 }}</ref> चुकीं, यदि डेटाग्राम में रूटिंग जानकारी है, तो बेहतर मार्ग उपलब्ध होने पर भी यह संदेश नहीं भेजा जाएगा। RFC 1122 में कहा गया है कि रीडायरेक्ट केवल [[गेटवे (दूरसंचार)]] द्वारा भेजा जाना चाहिए और इंटरनेट होस्ट द्वारा नहीं भेजा जाना चाहिए।


{| class="wikitable"
{| class="wikitable"
|+ Redirect message<ref name="rfc792" />{{rp|11}}
|+ पुनर्निर्देशित संदेश<ref name="rfc792" />{{rp|11}}
|-
|-
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
Line 314: Line 314:
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="8"| Type = 5
| colspan="8"| टाइप = 5
| colspan="8"| Code
| colspan="8"| कोड
| colspan="16"| Checksum
| colspan="16"| चेकसम
|-
|-
| colspan="32" style="text-align:center;"| आईपी address
| colspan="32" style="text-align:center;"| आईपी एड्रेस
|-
|-
| colspan="32" style="text-align:center;"| आईपी header and first 8 bytes of original datagram's data
| colspan="32" style="text-align:center;"| आईपी हेडर और मूल डेटाग्राम के डेटा के पहले 8 बाइट्स
|}
|}
कहाँ:
जहाँ:
: प्रकार 5 पर सेट होना चाहिए।
: प्रकार 5 पर सेट होना चाहिए।
: कोड पुनर्निर्देशन का कारण निर्दिष्ट करता है, और निम्न में से कोई एक हो सकता है:
: कोड पुनर्निर्देशन का कारण निर्दिष्ट करता है, और निम्न में से कोई एक हो सकता है:
:: {| class="wikitable"
:: {| class="wikitable"
|-
|-
! Code
! कोड
! Description
! विवरण
|-
|-
! 0
! 0
| Redirect for Network
| नेटवर्क के लिए पुनर्निर्देशित करें
|-
|-
! 1
! 1
| Redirect for Host
| होस्ट के लिए रीडायरेक्ट करें
|-
|-
! 2
! 2
| Redirect for Type of Service and Network
| सेवा और नेटवर्क के प्रकार के लिए रीडायरेक्ट करें
|-
|-
! 3
! 3
| Redirect for Type of Service and Host
| सेवा के प्रकार और होस्ट के लिए रीडायरेक्ट करें
|}
|}
: आईपी पता गेटवे का 32-बिट पता है जिस पर पुनर्निर्देशन भेजा जाना चाहिए।
: आईपी पता गेटवे का 32-बिट पता है जिस पर पुनर्निर्देशन भेजा जाना चाहिए।
: आईपी हेडर और अतिरिक्त डेटा सम्मिलित किया गया है ताकि होस्ट को उस अनुरोध के साथ उत्तर का मिलान करने की अनुमति मिल सके जो पुनर्निर्देशन उत्तर का कारण बना।
: आईपी हेडर और अतिरिक्त डेटा सम्मिलित किया गया है ताकि होस्ट को उस अनुरोध के साथ उत्तर का मिलान करने की अनुमति मिल सके जो पुनर्निर्देशन उत्तर का कारण बना।


=== समय पार हो गया ===
=== समय पार हो गया ===
टाइम एक्सीडेड एक [[गेटवे (कंप्यूटर नेटवर्किंग)]] द्वारा उत्पन्न होता है, जो लाइव फ़ील्ड के शून्य तक पहुँचने के समय के कारण एक छोड़े गए डेटाग्राम के स्रोत को सूचित करता है। एक समय से अधिक संदेश एक मेजबान द्वारा भी भेजा जा सकता है यदि वह अपनी समय सीमा के भीतर एक आईपी विखंडन डेटाग्राम को फिर से इकट्ठा करने में विफल रहता है।
टाइम एक्सीडेड [[गेटवे (कंप्यूटर नेटवर्किंग)]] द्वारा उत्पन्न होता है, जो लाइव फ़ील्ड के शून्य तक पहुँचने के समय के कारण छोड़े गए डेटाग्राम के स्रोत को सूचित करता है। एक समय से अधिक संदेश मेजबान द्वारा भी भेजा जा सकता है यदि वह अपनी समय सीमा के अन्दर आईपी विखंडन डेटाग्राम को फिर से इकट्ठा करने में विफल रहता है।


दो मेजबानों के बीच पथ पर गेटवे की पहचान करने के लिए ट्रेसरूट यूटिलिटी द्वारा समय से अधिक संदेशों का उपयोग किया जाता है।
दो मेजबानों के बीच पथ पर गेटवे की पहचान करने के लिए ट्रेसरूट यूटिलिटी द्वारा समय से अधिक संदेशों का उपयोग किया जाता है।


{| class="wikitable"
{| class="wikitable"
|+Time exceeded message<ref name=rfc792/>{{rp|5}}
|+समय पार हो गया संदेश<ref name=rfc792/>{{rp|5}}
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
Line 357: Line 357:
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="8"| Type = 11
| colspan="8"| टाइप = 11
| colspan="8"| Code
| colspan="8"| कोड
| colspan="16"| Checksum
| colspan="16"| चेकसम
|-
|-
| colspan="32" style="text-align:center;"| unused
| colspan="32" style="text-align:center;"| अप्रयुक्त
|-
|-
| colspan="32" style="text-align:center;"| आईपी header and first 8 bytes of original datagram's data
| colspan="32" style="text-align:center;"| आईपी हेडर और मूल डेटाग्राम के डेटा के पहले 8 बाइट्स
|}
|}
कहाँ:
जहाँ:
: प्रकार 11 पर सेट होना चाहिए
: प्रकार 11 पर सेट होना चाहिए
: कोड 'समय से अधिक' संदेश का कारण निर्दिष्ट करता है, इसमें निम्नलिखित सम्मिलित हैं:
: कोड 'समय से अधिक' संदेश का कारण निर्दिष्ट करता है, इसमें निम्नलिखित सम्मिलित हैं:
::{| class="wikitable"
::{| class="wikitable"
! Code || Description
! कोड || विवरण
|-
|-
! 0
! 0
| Time-to-live exceeded in transit.
| ट्रांज़िट में टाइम-टू-लाइव पार हो गया है।
|-
|-
! 1
! 1
| Fragment reassembly time exceeded.
| फ़्रैगमेंट को फिर से जोड़ने का समय पार हो गया है।
|}
|}
: आईपी हेडर और मूल [[पेलोड (कंप्यूटिंग)]] के पहले 64 बिट्स का उपयोग स्रोत होस्ट द्वारा छोड़े गए डेटाग्राम के समय से अधिक संदेश से मिलान करने के लिए किया जाता है। उपयोगकर्ता डेटाग्राम प्रोटोकॉल और ट्रांसमिशन कंट्रोल प्रोटोकॉल जैसे उच्च-स्तरीय प्रोटोकॉल के लिए 64-बिट पेलोड में हटाए गए पैकेट के स्रोत और गंतव्य पोर्ट सम्मिलित होंगे।
: आईपी हेडर और मूल [[पेलोड (कंप्यूटिंग)]] के पहले 64 बिट्स का उपयोग स्रोत होस्ट द्वारा छोड़े गए डेटाग्राम के समय से अधिक संदेश से मिलान करने के लिए किया जाता है। उपयोगकर्ता डेटाग्राम प्रोटोकॉल और ट्रांसमिशन कंट्रोल प्रोटोकॉल जैसे उच्च-स्तरीय प्रोटोकॉल के लिए 64-बिट पेलोड में हटाए गए पैकेट के स्रोत और गंतव्य पोर्ट सम्मिलित होंगे।


=== [[ TIMESTAMP ]] ===
=== [[ TIMESTAMP |टाइम स्टाम्प्स]] ===
Timestamp का उपयोग समय तुल्यकालन के लिए किया जाता है। मूल टाइमस्टैम्प उस समय पर सेट होता है (आधी रात से मिलीसेकंड में) प्रेषक ने आखिरी बार पैकेट को छुआ था। प्राप्त और संचारित टाइमस्टैम्प का उपयोग नहीं किया जाता है।
टाइम स्टाम्प्स का उपयोग समय तुल्यकालन के लिए किया जाता है। मूल टाइमस्टैम्प उस समय पर सेट होता है (आधी रात से मिलीसेकंड में) प्रेषक ने आखिरी बार पैकेट को छुआ था। प्राप्त और संचारित टाइमस्टैम्प का उपयोग नहीं किया जाता है।


{| class="wikitable"
{| class="wikitable"
|+Timestamp message<ref name=rfc792/>{{rp|15}}
|+टाइम स्टाम्प्स मेसेज<ref name=rfc792/>{{rp|15}}
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
Line 389: Line 389:
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="8"| Type = 13
| colspan="8"| टाइप = 13
| colspan="8"| Code = 0
| colspan="8"| कोड = 0
| colspan="16"| Checksum
| colspan="16"| चेकसम
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="16"| Identifier
| colspan="16"| पहचानकर्ता
| colspan="16"| Sequence number
| colspan="16"| अनुक्रम संख्या
|-
|-
| colspan="32" style="text-align:center;"| ''Originate'' timestamp
| colspan="32" style="text-align:center;"| मूल टाइमस्टैम्प
|-
|-
| colspan="32" style="text-align:center;"| ''Receive'' timestamp
| colspan="32" style="text-align:center;"| टाइमस्टैम्प प्राप्त करें
|-
|-
| colspan="32" style="text-align:center;"| ''Transmit'' timestamp
| colspan="32" style="text-align:center;"| टाइमस्टैम्प संचारित करें
|}
|}
कहाँ:
जहाँ:
: प्रकार 13 पर सेट होना चाहिए
: प्रकार 13 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
Line 409: Line 409:


=== टाइमस्टैम्प उत्तर ===
=== टाइमस्टैम्प उत्तर ===
टाइमस्टैम्प उत्तर #टाइमस्टैम्प संदेश का उत्तर देता है। इसमें टाइमस्टैम्प के प्रेषक द्वारा भेजे गए मूल टाइमस्टैम्प के साथ-साथ एक प्राप्त टाइमस्टैम्प होता है जो इंगित करता है कि टाइमस्टैम्प कब प्राप्त हुआ था और एक ट्रांसमिट टाइमस्टैम्प इंगित करता है कि टाइमस्टैम्प उत्तर कब भेजा गया था।
टाइमस्टैम्प उत्तर टाइमस्टैम्प संदेश का उत्तर देता है। इसमें टाइमस्टैम्प के प्रेषक द्वारा भेजे गए मूल टाइमस्टैम्प के साथ-साथ प्राप्त टाइमस्टैम्प होता है जो इंगित करता है कि टाइमस्टैम्प कब प्राप्त हुआ था और एक ट्रांसमिट टाइमस्टैम्प इंगित करता है कि टाइमस्टैम्प उत्तर कब भेजा गया था।


{| class="wikitable"
{| class="wikitable"
|+Timestamp reply message<ref name=rfc792/>{{rp|15}}
|+टाइमस्टैम्प रिप्लाई मेसेज<ref name=rfc792/>{{rp|15}}
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
Line 418: Line 418:
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="8"| Type = 14
| colspan="8"| टाइप = 14
| colspan="8"| Code = 0
| colspan="8"| कोड = 0
| colspan="16"| Checksum
| colspan="16"| चेकसम
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="16"| Identifier
| colspan="16"| पहचानकर्ता
| colspan="16"| Sequence number
| colspan="16"| अनुक्रम संख्या
|-
|-
| colspan="32" style="text-align:center;"| ''Originate'' timestamp
| colspan="32" style="text-align:center;"| ''उत्पत्ति'' टाइमस्टैम्प
|-
|-
| colspan="32" style="text-align:center;"| ''Receive'' timestamp
| colspan="32" style="text-align:center;"| ''प्राप्त करना'' टाइमस्टैम्प
|-
|-
| colspan="32" style="text-align:center;"| ''Transmit'' timestamp
| colspan="32" style="text-align:center;"| ''संचारित'' टाइमस्टैम्प
|}
|}
कहाँ:
जहाँ:
: प्रकार 14 पर सेट होना चाहिए
: प्रकार 14 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
Line 444: Line 444:




=== पता मुखौटा अनुरोध ===
=== एड्रेस मास्क रिक्वेस्ट ===
उपयुक्त [[सबनेट मास्क]] प्राप्त करने के लिए एड्रेस मास्क अनुरोध सामान्य रूप से [[सर्वर (कंप्यूटिंग)]] द्वारा राउटर (कंप्यूटिंग) को भेजा जाता है।
उपयुक्त [[सबनेट मास्क]] प्राप्त करने के लिए एड्रेस मास्क अनुरोध सामान्य रूप से [[सर्वर (कंप्यूटिंग)]] द्वारा राउटर (कंप्यूटिंग) को भेजा जाता है।


Line 450: Line 450:


{| class="wikitable"
{| class="wikitable"
|+Address mask request
|+एड्रेस मास्क रिक्वेस्ट
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
Line 456: Line 456:
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="8"| Type = 17
| colspan="8"| टाइप = 17
| colspan="8"| Code = 0
| colspan="8"| कोड = 0
| colspan="16"| Checksum
| colspan="16"| चेकसम
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="16"| Identifier
| colspan="16"| पहचानकर्ता
| colspan="16"| Sequence number
| colspan="16"| अनुक्रम संख्या
|-
|-
| colspan="32" style="text-align:center;"| Address mask
| colspan="32" style="text-align:center;"| एड्रेस मास्क
|}
|}
कहाँ:
जहाँ:
: प्रकार 17 पर सेट होना चाहिए
: प्रकार 17 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
: पता मुखौटा 0 पर सेट किया जा सकता है
: पता मुखौटा 0 पर सेट किया जा सकता है


लक्ष्य नेटवर्क पर जानकारी इकट्ठा करने के लिए आईसीएमपीएड्रेस मास्क अनुरोध का उपयोग टोही हमले के एक भाग के रूप में किया जा सकता है, इसलिए आईसीएमपीएड्रेस मास्क रिप्लाई सिस्को IOS पर डिफ़ॉल्ट रूप से अक्षम है।<ref>{{cite web |url=http://www.cisco.com/en/US/docs/ios/12_3/ipaddr/command/reference/ip1_i2g.html#wp1078496 |title=Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and Services, Release 12.3 - IP Addressing and Services Commands: ip mask-reply through ip web-cache |publisher=[[Cisco Systems]] |access-date=2013-01-07 |url-status=dead |archive-url=https://web.archive.org/web/20130102124241/http://www.cisco.com/en/US/docs/ios/12_3/ipaddr/command/reference/ip1_i2g.html#wp1078496 |archive-date=2013-01-02 }}</ref>
लक्ष्य नेटवर्क पर जानकारी इकट्ठा करने के लिए आईसीएमपीएड्रेस मास्क अनुरोध का उपयोग टोही हमले के भाग के रूप में किया जा सकता है, इसलिए आईसीएमपीएड्रेस मास्क रिप्लाई सिस्को IOS पर डिफ़ॉल्ट रूप से अक्षम है।<ref>{{cite web |url=http://www.cisco.com/en/US/docs/ios/12_3/ipaddr/command/reference/ip1_i2g.html#wp1078496 |title=Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and Services, Release 12.3 - IP Addressing and Services Commands: ip mask-reply through ip web-cache |publisher=[[Cisco Systems]] |access-date=2013-01-07 |url-status=dead |archive-url=https://web.archive.org/web/20130102124241/http://www.cisco.com/en/US/docs/ios/12_3/ipaddr/command/reference/ip1_i2g.html#wp1078496 |archive-date=2013-01-02 }}</ref>




=== पता मुखौटा उत्तर ===
=== एड्रेस मास्क रिप्लाई ===
एड्रेस मास्क रिप्लाई का उपयोग एड्रेस मास्क रिक्वेस्ट मैसेज का उपयुक्त सबनेट मास्क के साथ जवाब देने के लिए किया जाता है।
एड्रेस मास्क रिप्लाई का उपयोग एड्रेस मास्क रिक्वेस्ट मैसेज का उपयुक्त सबनेट मास्क के साथ जवाब देने के लिए किया जाता है।


{| class="wikitable"
{| class="wikitable"
|+Address mask reply
|+एड्रेस मास्क रिप्लाई
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
Line 483: Line 483:
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="8"| Type = 18
| colspan="8"| टाइप = 18
| colspan="8"| Code = 0
| colspan="8"| कोड = 0
| colspan="16"| Checksum
| colspan="16"| चेकसम
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="16"| Identifier
| colspan="16"| पहचानकर्ता
| colspan="16"| Sequence number
| colspan="16"| अनुक्रम संख्या
|-
|-
| colspan="32" style="text-align:center;"| Address mask
| colspan="32" style="text-align:center;"| एड्रेस मास्क
|}
|}
कहाँ:
जहाँ:
: प्रकार 18 पर सेट होना चाहिए
: प्रकार 18 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
Line 498: Line 498:


===गंतव्य अगम्य===
===गंतव्य अगम्य===
गंतव्य अगम्य मेजबान या उसके इनबाउंड गेटवे द्वारा उत्पन्न होता है<ref name=rfc792/>ग्राहक को सूचित करने के लिए कि गंतव्य किसी कारण से पहुंच योग्य नहीं है। इस संदेश के कारणों में सम्मिलित हो सकते हैं: मेजबान से भौतिक संबंध मौजूद नहीं है (दूरी अनंत है); संकेतित प्रोटोकॉल या पोर्ट सक्रिय नहीं है; डेटा खंडित होना चाहिए लेकिन 'टुकड़ा न करें' ध्वज चालू है। अगम्य टीसीपी पोर्ट विशेष रूप से टीसीपी आरएसटी के अतिरिक्त 'गंतव्य अगम्य' टाइप 3 के साथ प्रतिक्रिया करते हैं, जैसा कि उम्मीद की जा सकती है। [[आईपी ​​​​मल्टीकास्ट]] प्रसारण के लिए ''गंतव्य अगम्य'' की कभी सूचना नहीं दी जाती है।
गंतव्य अगम्य मेजबान या उसके इनबाउंड गेटवे द्वारा उत्पन्न होता है<ref name=rfc792/> ग्राहक को सूचित करने के लिए कि गंतव्य किसी कारण से पहुंच योग्य नहीं है। इस संदेश के कारणों में सम्मिलित हो सकते हैं: मेजबान से भौतिक संबंध उपस्थित नहीं है (दूरी अनंत है); संकेतित प्रोटोकॉल या पोर्ट सक्रिय नहीं है; डेटा खंडित होना चाहिए लेकिन 'टुकड़ा न करें' ध्वज चालू है। अगम्य टीसीपी पोर्ट विशेष रूप से टीसीपी आरएसटी के अतिरिक्त 'गंतव्य अगम्य' टाइप 3 के साथ प्रतिक्रिया करते हैं, जैसा कि उम्मीद की जा सकती है। [[आईपी ​​​​मल्टीकास्ट]] प्रसारण के लिए ''गंतव्य अगम्य'' की कभी सूचना नहीं दी जाती है।


  {| class="wikitable"
  {| class="wikitable"
|+Destination unreachable message<ref name=rfc792/>{{rp|3}}
|+गंतव्य अगम्य संदेश<ref name=rfc792/>{{rp|3}}
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
Line 507: Line 507:
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="8"| Type = 3
| colspan="8"| टाइप = 3
| colspan="8"| Code
| colspan="8"| कोड
| colspan="16"| Checksum
| colspan="16"| चेकसम
|- style="text-align:center;"
|- style="text-align:center;"
| colspan="16"| unused
| colspan="16"| अप्रयुक्त
| colspan="16"| Next-hop MTU
| colspan="16"| नेक्स्ट-हॉप एमटीयू
|-
|-
| colspan="32" style="text-align:center;"| आईपी header and first 8 bytes of original datagram's data
| colspan="32" style="text-align:center;"| आईपी हेडर और मूल डेटाग्राम के डेटा के पहले 8 बाइट्स
|}
|}
कहाँ:
जहाँ:
:टाइप फ़ील्ड (बिट्स 0–7) को 3 पर सेट किया जाना चाहिए
:टाइप फ़ील्ड (बिट्स 0–7) को 3 पर सेट किया जाना चाहिए
: कोड फ़ील्ड (बिट्स 8-15) का उपयोग त्रुटि के प्रकार को निर्दिष्ट करने के लिए किया जाता है, और निम्न में से कोई भी हो सकता है:
: कोड फ़ील्ड (बिट्स 8-15) का उपयोग त्रुटि के प्रकार को निर्दिष्ट करने के लिए किया जाता है, और निम्न में से कोई भी हो सकता है:
::{| class="wikitable"
::{| class="wikitable"
! Code || Description
! कोड || विवरण
|-
|-
! 0
! 0
| Network unreachable error.
| नेटवर्क अगम्य त्रुटि
|-
|-
! 1
! 1
| Host unreachable error.
| होस्ट अगम्य त्रुटि।
|-
|-
! 2
! 2
| Protocol unreachable error (the designated transport protocol is not supported).
| प्रोटोकॉल अगम्य त्रुटि (निर्दिष्ट परिवहन प्रोटोकॉल समर्थित नहीं है)।
|-
|-
! 3
! 3
| Port unreachable error (the designated protocol is unable to inform the host of the incoming message).
| पोर्ट अगम्य त्रुटि (निर्दिष्ट प्रोटोकॉल आने वाले संदेश के होस्ट को सूचित करने में असमर्थ है)
|-
|-
! 4
! 4
| The datagram is too big. Packet fragmentation is required but the 'don't fragment' (DF) flag is on.
| डेटाग्राम बहुत बड़ा है। पैकेट फ़्रेग्मेंटेशन आवश्यक है लेकिन 'फ़्रैगमेंट न करें' (DF) फ़्लैग चालू है।
|-
|-
! 5
! 5
| Source route failed error.
| स्रोत मार्ग विफल त्रुटि।
|-
|-
! 6
! 6
| Destination network unknown error.
| गंतव्य नेटवर्क अज्ञात त्रुटि।
|-
|-
! 7
! 7
| Destination host unknown error.
| गंतव्य होस्ट अज्ञात त्रुटि।
|-
|-
! 8
! 8
| Source host isolated error.
| स्रोत होस्ट पृथक त्रुटि।
|-
|-
! 9
! 9
| The destination network is administratively prohibited.
| गंतव्य नेटवर्क प्रशासनिक रूप से प्रतिबंधित है।
|-
|-
! 10
! 10
| The destination host is administratively prohibited.
| गंतव्य होस्ट प्रशासनिक रूप से प्रतिबंधित है।
|-
|-
! 11
! 11
| The network is unreachable for Type Of Service.
| ऑफ सर्विस के लिए नेटवर्क पहुंच योग्य नहीं है।
|-
|-
! 12
! 12
| The host is unreachable for Type Of Service.
| ऑफ सर्विस के लिए होस्ट पहुंच योग्य नहीं है।
|-
|-
! 13
! 13
| Communication administratively prohibited (administrative filtering prevents packet from being forwarded).
| संचार प्रशासनिक रूप से प्रतिबंधित है (प्रशासनिक फ़िल्टरिंग पैकेट को अग्रेषित होने से रोकता है)।
|-
|-
! 14
! 14
| Host precedence violation (indicates the requested precedence is not permitted for the combination of host or network and port).
| होस्ट वरीयता उल्लंघन (होस्ट या नेटवर्क और पोर्ट के संयोजन के लिए अनुरोधित प्राथमिकता की अनुमति नहीं है) इंगित करता है।
|-
|-
! 15
! 15
| Precedence cutoff in effect (precedence of datagram is below the level set by the network administrators).
| वरीयता कटऑफ प्रभाव में है (डेटाग्राम की प्राथमिकता नेटवर्क प्रशासकों द्वारा निर्धारित स्तर से नीचे है)।
|}
|}
: नेक्स्ट-हॉप एमटीयू फील्ड (बिट्स 48-63) में नेक्स्ट-हॉप नेटवर्क का एमटीयू होता है यदि कोड 4 त्रुटि होती है।<ref>{{cite IETF |rfc=4884 |title=Extended ICMP to Support Multi-Part Messages}}</ref>
: नेक्स्ट-हॉप एमटीयू फील्ड (बिट्स 48-63) में नेक्स्ट-हॉप नेटवर्क का एमटीयू होता है यदि कोड 4 त्रुटि होती है।<ref>{{cite IETF |rfc=4884 |title=Extended ICMP to Support Multi-Part Messages}}</ref>
: आईपी हेडर और अतिरिक्त डेटा सम्मिलित किया गया है ताकि क्लाइंट को उस अनुरोध के साथ उत्तर का मिलान करने की अनुमति मिल सके जिसके कारण गंतव्य तक पहुंचने योग्य उत्तर नहीं मिला।
: आईपी हेडर और अतिरिक्त डेटा सम्मिलित किया गया है ताकि क्लाइंट को उस अनुरोध के साथ उत्तर का मिलान करने की अनुमति मिल सके जिसके कारण गंतव्य तक पहुंचने योग्य उत्तर नहीं मिला।


== यह भी देखें ==
== यह भी देखें ==
{{Div col|colwidth=20em}}
{{Div col|colwidth=20em}}
* आईसीएमपी सुरंग
* आईसीएमपी सुरंग
* [[ICMP होल पंचिंग]]
* [[आईसीएमपी होल पंचिंग]]
* [[ ICMP राउटर डिस्कवरी प्रोटोकॉल ]]
* [[ आईसीएमपी राउटर डिस्कवरी प्रोटोकॉल ]]
* [[पाथिंग]]
* [[पाथिंग]]
* [[पथ एमटीयू डिस्कवरी]]
* [[पथ एमटीयू डिस्कवरी]]
Line 604: Line 604:
* {{web archive |title=Explanation of ICMP Redirect Behavior |url=https://web.archive.org/web/20150110205151/http://support.microsoft.com/kb/195686 |date=2015-01-10}}
* {{web archive |title=Explanation of ICMP Redirect Behavior |url=https://web.archive.org/web/20150110205151/http://support.microsoft.com/kb/195686 |date=2015-01-10}}


{{Authority control}}
[[Category:Articles with hatnote templates targeting a nonexistent page]]
[[Category: इंटरनेट प्रोटोकॉल]] [[Category: इंटरनेट मानक]] [[Category: इंटरनेट परत प्रोटोकॉल]] [[Category: नेटवर्क परत प्रोटोकॉल]]
 
 
 
[[Category: Machine Translated Page]]
[[Category:Created On 11/05/2023]]
[[Category:Created On 11/05/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Multi-column templates]]
[[Category:Pages using div col with small parameter]]
[[Category:Pages with script errors]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:Templates using under-protected Lua modules]]
[[Category:Webarchive template wayback links]]
[[Category:Wikipedia fully protected templates|Div col]]
[[Category:इंटरनेट परत प्रोटोकॉल]]
[[Category:इंटरनेट प्रोटोकॉल]]
[[Category:इंटरनेट मानक]]
[[Category:नेटवर्क परत प्रोटोकॉल]]

Latest revision as of 08:04, 13 June 2023

Internet Control Message Protocol
Communication protocol
ICMP header - General-en.svg
A general header for ICMPv4
PurposeAuxiliary protocol for IPv4[1]
Developer(s)DARPA
Introduction1981
OSI layerNetwork layer
RFC(s)RFC 792
This article is about आईसीएमपीवी4. For आईसीएमपीवी6, see आईसीएमपीवी6.

इंटरनेट कंट्रोल मैसेज प्रोटोकॉल (आईसीएमपी) इंटरनेट प्रोटोकॉल सूट में सहायक संचार प्रोटोकॉल है। इसका उपयोग राउटर (कंप्यूटिंग) सहित नेटवर्क उपकरण द्वारा किया जाता है, त्रुटि संदेश भेजने के लिए और किसी अन्य आईपी पते के साथ संचार करते समय सफलता या विफलता का संकेत देने वाली परिचालन जानकारी, उदाहरण के लिए, अनुरोधित सेवा उपलब्ध नहीं होने पर त्रुटि इंगित की जाती है या होस्ट ( नेटवर्क) या राउटर तक नहीं पहुंचा जा सका।[2] आईसीएमपी प्रसारण नियंत्रण प्रोटोकॉल और डेटाग्राम प्रोटेकॉलका उपयोग करें जैसे परिवहन प्रोटोकॉल से अलग है, क्योंकि यह सामान्यतः सिस्टम के बीच डेटा का आदान-प्रदान करने के लिए उपयोग नहीं किया जाता है, न ही यह एंड-यूज़र नेटवर्क एप्लिकेशन द्वारा नियमित रूप से नियोजित किया जाता है और ट्रेसरूट ) जैसे कुछ नैदानिक ​​उपकरणों के अपवाद के साथ)

IPv4 के लिए आईसीएमपीमें परिभाषित किया गया है RFC 792. RFC 4443 द्वारा परिभाषित एक अलग ICMPv6, IPv6 के साथ प्रयोग किया जाता है।

Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

तकनीकी विवरण

आईसीएमपीइंटरनेट प्रोटोकॉल सूट का भाग है जैसा कि RFC 792 में परिभाषित किया गया है। आईसीएमपीसंदेश सामान्यतः निदान या नियंत्रण उद्देश्यों के लिए उपयोग किए जाते हैं या इंटरनेट प्रोटोकॉल संचालन में त्रुटियों के उत्तर में उत्पन्न होते हैं (जैसा कि RFC 1122 में निर्दिष्ट है)। आईसीएमपीत्रुटियाँ मूल पैकेट के स्रोत आईपी पते पर निर्देशित की जाती हैं।[2]

उदाहरण के लिए, प्रत्येक डिवाइस (जैसे इंटरमीडिएट राउटर (कंप्यूटिंग)) आईपी आंकड़ारेख को अग्रेषित करने से पहले आईपी हेडर में रहने के समय (टीटीएल) फ़ील्ड को एक से कम कर देता है। यदि परिणामी TTL 0 है, तो पैकेट को छोड़ दिया जाता है और डेटाग्राम के स्रोत पते पर आईसीएमपी समय से अधिक संदेश भेजा जाता है।

सामान्यतः उपयोग की जाने वाली कई नेटवर्क उपयोगिताएँ आईसीएमपीसंदेशों पर आधारित होती हैं। ट्रेसरूट कमांड को आईपी डेटाग्राम को विशेष रूप से सेट आईपी टीटीएल हेडर फ़ील्ड के साथ प्रसारित करके कार्यान्वित किया जा सकता है, और आईसीएमपी समय पारगमन में पार हो गया है और प्रतिक्रिया में उत्पन्न # गंतव्य अगम्य संदेशों की तलाश कर रहा है। संबंधित पिंग (नेटवर्किंग यूटिलिटी) यूटिलिटी आईसीएमपीइको रिक्वेस्ट और इको रिप्लाई मैसेज का उपयोग करके कार्यान्वित की जाती है।

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

आईसीएमपी नेटवर्क परत प्रोटोकॉल है, जो इसे 7 लेयर OSI मॉडल द्वारा लेयर 3 प्रोटोकॉल बनाता है। 4 परत टीसीपी/आईपी मॉडल के आधार पर, आईसीएमपी इंटरनेट परत है। इंटरनेट-परत प्रोटोकॉल, जो इसे परत 2 प्रोटोकॉल (4 परतों वाला इंटरनेट मानक आरएफसी 1122 टीसीपी/आईपी मॉडल) या आधुनिक 5 परत टीसीपी पर आधारित परत 3 प्रोटोकॉल बनाता है। /आईपी प्रोटोकॉल परिभाषाएँ (कोज़िएरोक, कॉमर, तनेनबाउम, फ़ोरोज़न, कुरोज़, स्टालिंग्स द्वारा)। फ़ोरोज़न और कुरोस अपनी टीसीपी /आईपी मॉडल परिभाषा में इंटरनेट-लेयर के अतिरिक्त नेटवर्क-लेयर का उपयोग करते हैं। मॉडलों के बीच ये अंतर अक्सर व्यर्थ और अंतहीन बहस का कारण बनते हैं।

आईसीएमपीपैकेट के साथ कोई टीसीपी या यूडीपी पोर्ट नंबर नहीं जुड़ा है क्योंकि ये नंबर ऊपर ट्रांसपोर्ट परत से जुड़े हैं।[3]


डेटाग्राम संरचना

आईसीएमपीपैकेट IPv4 पैकेट में समाहित है।[2] पैकेट में हेडर और डेटा सेक्शन होते हैं।

हैडर

आईसीएमपी हेडर IPv4 हैडर के बाद प्रारंभ होता है और आईपी प्रोटोकॉल नंबर '1' की सूची द्वारा पहचाना जाता है।[4] सभी आईसीएमपी पैकेट में 8-बाइट हेडर और वेरिएबल-साइज़ डेटा सेक्शन होता है। हेडर के पहले 4 बाइट्स का प्रारूप निश्चित होता है, जबकि अंतिम 4 बाइट्स उस आईसीएमपीपैकेट के प्रकार/कोड पर निर्भर करते हैं।[2]

आईसीएमपी हेडर प्रारूप
Offsets Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 प्रकार कोड चेक योग
4 32 बाकी हेडर
प्रकार
आईसीएमपी प्रकार, देखें § संदेशों को नियंत्रित करें.
कोड
आईसीएमपी उपप्रकार, देखें § संदेशों को नियंत्रित करें.
अंततः,
त्रुटि जाँच के लिए इंटरनेट चेकसम (RFC 1071), आईसीएमपीहेडर से गणना की जाती है और इस फ़ील्ड के लिए मान 0 के साथ डेटा प्रतिस्थापित किया जाता है।
बाकी हेडर
चार-बाइट फ़ील्ड, सामग्री आईसीएमपी प्रकार और कोड के आधार पर भिन्न होती है।

डेटा

आईसीएमपी त्रुटि संदेशों में डेटा खंड होता है जिसमें संपूर्ण IPv4 हेडर की प्रति, साथ ही IPv4 पैकेट से डेटा के कम से कम पहले आठ बाइट्स सम्मिलित होते हैं जो त्रुटि संदेश का कारण बनते हैं। आईसीएमपी त्रुटि संदेशों की लंबाई 576 बाइट्स से अधिक नहीं होनी चाहिए।[5] इस डेटा का उपयोग होस्ट द्वारा संदेश को उपयुक्त प्रक्रिया से मिलाने के लिए किया जाता है। यदि उच्च स्तरीय प्रोटोकॉल पोर्ट नंबरों का उपयोग करता है, तो उन्हें मूल डेटाग्राम के डेटा के पहले आठ बाइट्स में माना जाता है।[6]

आईसीएमपी पैकेट डेटा सेक्शन का चर आकार शोषण (कंप्यूटर सुरक्षा) किया गया है। मौत के पिंग में, बड़े या खंडित आईसीएमपी पैकेट का उपयोग डिनायल-ऑफ़-सर्विस हमलों के लिए किया जाता है। संचार के लिए गुप्त चैनल बनाने के लिए आईसीएमपीडेटा का भी उपयोग किया जा सकता है। इन चैनलों को आईसीएमपीटनल के रूप में जाना जाता है।

नियंत्रण संदेश

नियंत्रण संदेशों को प्रकार फ़ील्ड में मान द्वारा पहचाना जाता है। कोड फ़ील्ड संदेश के लिए अतिरिक्त संदर्भ जानकारी देता है। प्रोटोकॉल के पहली बार पेश किए जाने के बाद से कुछ नियंत्रण संदेशों को बहिष्कृत कर दिया गया है।

उल्लेखनीय नियंत्रण संदेश[7][8]
प्रकार कोड स्थिति विवरण
0 –इको रिप्लाई[6]: 14  0 प्रतिध्वनि उत्तर (पिंग के लिए प्रयुक्त))
1 और 2 unassigned आरक्षित
3 – Destination Unreachable[6]: 4  0 गंतव्य नेटवर्क पहुंच से बाहर है
1 मेजबान के गंतव्य संपर्क से बाहर है
2 गंतव्य प्रोटोकॉल पहुंच योग्य नहीं है
3 गंतव्य बंदरगाह पहुंच योग्य नहीं है
4 विखंडन की आवश्यकता है, और DF फ्लैग सेट
5 स्रोत मार्ग विफल रहा
6 गंतव्य नेटवर्क अज्ञात
7 गंतव्य नेटवर्क अज्ञात
8 स्रोत होस्ट अलग किया गया
9 नेटवर्क प्रशासनिक रूप से प्रतिबंधित है
10 मेजबान प्रशासनिक रूप से निषिद्ध
11 नेटवर्क के लिए पहुंच योग्य नहीं है ToS
12 होस्ट के लिए पहुंच योग्य नहीं है ToS
13 संचार प्रशासनिक रूप से प्रतिबंधित है
14 होस्ट प्राथमिकता का उल्लंघन
15 वरीयता कटऑफ प्रभावी है
4 – Source Quench 0 deprecated स्रोत शमन (भीड़ नियंत्रण)
5 – Redirect Message 0 नेटवर्क के लिए पुनर्निर्देशित डेटाग्राम
1 होस्ट के लिए रीडायरेक्ट डेटाग्राम
2 के लिए पुनर्निर्देशित डेटाग्राम ToS & नेटवर्क
3 के लिए पुनर्निर्देशित डेटाग्राम ToS & होस्ट
6 deprecated वैकल्पिक होस्ट पता
7 unassigned आरक्षित
8 – Echo Request 0 इको अनुरोध (पिंग करने के लिए प्रयुक्त)
9 – Router Advertisement 0 राउटर विज्ञापन
10 – Router Solicitation 0 राउटर की खोज/चयन/याचना
11 – Time Exceeded[6]: 6  0 TTL ट्रांज़िट में समाप्त हो गया
1 फ़्रैगमेंट को फिर से जोड़ने का समय पार हो गया है
12 – Parameter Problem: Bad आईपी header 0 सूचक त्रुटि को इंगित करता है
1 एक आवश्यक विकल्प गुम है
2 खराब लंबाई
13 – समय-चिह्न 0 समय-चिह्न
14 – टाइमस्टैम्प उत्तर 0 टाइमस्टैम्प उत्तर
15 – जानकारी अनुरोध 0 deprecated जानकारी अनुरोध
16 – सूचना उत्तर 0 deprecated सूचना उत्तर
17 – एड्रेस मास्क रिक्वेस्ट 0 deprecated एड्रेस मास्क रिक्वेस्ट
18 – एड्रेस मास्क रिक्वेस्ट 0 deprecated एड्रेस मास्क रिक्वेस्ट
19 reserved सुरक्षा के लिए आरक्षित
20 through 29 reserved मजबूती प्रयोग के लिए आरक्षित
30 – Traceroute 0 deprecated जानकारी अनुरोध
31 deprecated डेटाग्राम रूपांतरण त्रुटि
32 deprecated मोबाइल होस्ट पुनर्निर्देशन
33 deprecated व्हेयर-अरे-यू (मूल रूप से के लिए IPv6 था)
34 deprecated हियर-आई-एम (मूल रूप से इसका अर्थ IPv6 था)
35 deprecated मोबाइल पंजीकरण अनुरोध
36 deprecated मोबाइल पंजीकरण उत्तर
37 deprecated डोमेन नाम अनुरोध
38 deprecated डोमेन नाम उत्तर
39 deprecated एसकेआईपी एल्गोरिथम डिस्कवरी प्रोटोकॉल, इंटरनेट प्रोटोकॉल के लिए सरल कुंजी-प्रबंधन
40 फोटोरिस, सुरक्षा विफलताएं
41 Experimental आईसीएमपी प्रयोगात्मक गतिशीलता प्रोटोकॉल के लिए जैसे सीमोबी [RFC4065]
42 – Extended Echo Request[9] 0 विस्तारित इको का अनुरोध करें (XPing - see Extended Ping (Xping))
43 – Extended Echo Reply[9] 0 कोई ग़लती नहीं
1 विकृत क्वेरी
2 ऐसा कोई इंटरफ़ेस नहीं
3 ऐसी कोई तालिका प्रविष्टि नहीं
4 एकाधिक इंटरफेस क्वेरी को संतुष्ट करते हैं
44 through 252 unassigned सुरक्षित
253 Experimental RFC3692-शैली प्रयोग 1 (RFC 4727)
254 Experimental RFC3692-शैली प्रयोग 2 (RFC 4727)
255 सुरक्षित सुरक्षित


स्रोत बुझाना

स्रोत बुझाना अनुरोध करता है कि प्रेषक राउटर या होस्ट को भेजे गए संदेशों की दर कम कर देता है। यह संदेश उत्पन्न हो सकता है यदि राउटर या होस्ट के पास अनुरोध को संसाधित करने के लिए पर्याप्त बफर स्थान नहीं है, या यदि राउटर या होस्ट बफर अपनी सीमा तक पहुंच रहा है तो यह संदेश उत्पन्न हो सकता है।

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

चूंकि अनुसंधान ने सुझाव दिया कि आईसीएमपीस्रोत कुंच [था] भीड़भाड़ के लिए अप्रभावी (और अनुचित) मारक है,[10] 1995 में RFC 1812 द्वारा रूटर के सोर्स क्वेंच संदेशों के निर्माण को रोक दिया गया था।

स्रोत शमन संदेश[6]: 9 
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
टाइप = 4 कोड = 0 चेकसम
अप्रयुक्त
आईपी हेडर और मूल डेटाग्राम के डेटा के पहले 8 बाइट्स

जहाँ:

प्रकार 4 पर सेट होना चाहिए
कोड 0 पर सेट होना चाहिए
आईपी हेडर और अतिरिक्त डेटा का उपयोग प्रेषक द्वारा संबंधित अनुरोध के साथ उत्तर का मिलान करने के लिए किया जाता है

रीडायरेक्ट

ICMPv4 रीडायरेक्ट संदेश कैसे काम करता है इसका उदाहरण

रीडायरेक्ट अनुरोध डेटा पैकेट वैकल्पिक मार्ग पर भेजे जाएं। आईसीएमपीरीडायरेक्ट राउटर्स के लिए मेजबानों को रूटिंग जानकारी देने के लिए तंत्र है। संदेश एक मेजबान को अपनी रूटिंग जानकारी अपडेट करने के लिए सूचित करता है (वैकल्पिक मार्ग पर पैकेट भेजने के लिए)। यदि कोई होस्ट राउटर (कंप्यूटिंग) (R1) के माध्यम से डेटा भेजने की कोशिश करता है और R1 दूसरे राउटर (R2) पर डेटा भेजता है और होस्ट से R2 के लिए सीधा रास्ता उपलब्ध है (यानी, होस्ट और R2 एक ही पर हैं) सब नेटवर्क ), तो R1 मेजबान को सूचित करने के लिए पुनर्निर्देशित संदेश भेजेगा कि गंतव्य के लिए सबसे अच्छा मार्ग R2 के माध्यम से है। इसके बाद मेजबान को अपनी रूट सूचना बदलनी चाहिए और उस गंतव्य के लिए सीधे R2 को पैकेट भेजना चाहिए। राउटर अभी भी मूल डेटाग्राम को इच्छित गंतव्य पर भेजेगा।[11] चुकीं, यदि डेटाग्राम में रूटिंग जानकारी है, तो बेहतर मार्ग उपलब्ध होने पर भी यह संदेश नहीं भेजा जाएगा। RFC 1122 में कहा गया है कि रीडायरेक्ट केवल गेटवे (दूरसंचार) द्वारा भेजा जाना चाहिए और इंटरनेट होस्ट द्वारा नहीं भेजा जाना चाहिए।

पुनर्निर्देशित संदेश[6]: 11 
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
टाइप = 5 कोड चेकसम
आईपी एड्रेस
आईपी हेडर और मूल डेटाग्राम के डेटा के पहले 8 बाइट्स

जहाँ:

प्रकार 5 पर सेट होना चाहिए।
कोड पुनर्निर्देशन का कारण निर्दिष्ट करता है, और निम्न में से कोई एक हो सकता है:
कोड विवरण
0 नेटवर्क के लिए पुनर्निर्देशित करें
1 होस्ट के लिए रीडायरेक्ट करें
2 सेवा और नेटवर्क के प्रकार के लिए रीडायरेक्ट करें
3 सेवा के प्रकार और होस्ट के लिए रीडायरेक्ट करें
आईपी पता गेटवे का 32-बिट पता है जिस पर पुनर्निर्देशन भेजा जाना चाहिए।
आईपी हेडर और अतिरिक्त डेटा सम्मिलित किया गया है ताकि होस्ट को उस अनुरोध के साथ उत्तर का मिलान करने की अनुमति मिल सके जो पुनर्निर्देशन उत्तर का कारण बना।

समय पार हो गया

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

दो मेजबानों के बीच पथ पर गेटवे की पहचान करने के लिए ट्रेसरूट यूटिलिटी द्वारा समय से अधिक संदेशों का उपयोग किया जाता है।

समय पार हो गया संदेश[6]: 5 
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
टाइप = 11 कोड चेकसम
अप्रयुक्त
आईपी हेडर और मूल डेटाग्राम के डेटा के पहले 8 बाइट्स

जहाँ:

प्रकार 11 पर सेट होना चाहिए
कोड 'समय से अधिक' संदेश का कारण निर्दिष्ट करता है, इसमें निम्नलिखित सम्मिलित हैं:
कोड विवरण
0 ट्रांज़िट में टाइम-टू-लाइव पार हो गया है।
1 फ़्रैगमेंट को फिर से जोड़ने का समय पार हो गया है।
आईपी हेडर और मूल पेलोड (कंप्यूटिंग) के पहले 64 बिट्स का उपयोग स्रोत होस्ट द्वारा छोड़े गए डेटाग्राम के समय से अधिक संदेश से मिलान करने के लिए किया जाता है। उपयोगकर्ता डेटाग्राम प्रोटोकॉल और ट्रांसमिशन कंट्रोल प्रोटोकॉल जैसे उच्च-स्तरीय प्रोटोकॉल के लिए 64-बिट पेलोड में हटाए गए पैकेट के स्रोत और गंतव्य पोर्ट सम्मिलित होंगे।

टाइम स्टाम्प्स

टाइम स्टाम्प्स का उपयोग समय तुल्यकालन के लिए किया जाता है। मूल टाइमस्टैम्प उस समय पर सेट होता है (आधी रात से मिलीसेकंड में) प्रेषक ने आखिरी बार पैकेट को छुआ था। प्राप्त और संचारित टाइमस्टैम्प का उपयोग नहीं किया जाता है।

टाइम स्टाम्प्स मेसेज[6]: 15 
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
टाइप = 13 कोड = 0 चेकसम
पहचानकर्ता अनुक्रम संख्या
मूल टाइमस्टैम्प
टाइमस्टैम्प प्राप्त करें
टाइमस्टैम्प संचारित करें

जहाँ:

प्रकार 13 पर सेट होना चाहिए
कोड 0 पर सेट होना चाहिए
पहचानकर्ता और अनुक्रम संख्या का उपयोग क्लाइंट द्वारा टाइमस्टैम्प अनुरोध के साथ #टाइमस्टैम्प उत्तर से मिलान करने के लिए किया जा सकता है।
ओरिजिनेट टाइमस्टैम्प मध्यरात्रि यूनिवर्सल टाइम (यूटी) के बाद से मिलीसेकंड की संख्या है। यदि कोई यूटी संदर्भ उपलब्ध नहीं है तो गैर-मानक समय मान को इंगित करने के लिए सबसे महत्वपूर्ण बिट सेट किया जा सकता है।

टाइमस्टैम्प उत्तर

टाइमस्टैम्प उत्तर टाइमस्टैम्प संदेश का उत्तर देता है। इसमें टाइमस्टैम्प के प्रेषक द्वारा भेजे गए मूल टाइमस्टैम्प के साथ-साथ प्राप्त टाइमस्टैम्प होता है जो इंगित करता है कि टाइमस्टैम्प कब प्राप्त हुआ था और एक ट्रांसमिट टाइमस्टैम्प इंगित करता है कि टाइमस्टैम्प उत्तर कब भेजा गया था।

टाइमस्टैम्प रिप्लाई मेसेज[6]: 15 
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
टाइप = 14 कोड = 0 चेकसम
पहचानकर्ता अनुक्रम संख्या
उत्पत्ति टाइमस्टैम्प
प्राप्त करना टाइमस्टैम्प
संचारित टाइमस्टैम्प

जहाँ:

प्रकार 14 पर सेट होना चाहिए
कोड 0 पर सेट होना चाहिए
पहचानकर्ता और अनुक्रम संख्या का उपयोग क्लाइंट द्वारा उत्तर के अनुरोध के साथ उत्तर से मिलान करने के लिए किया जा सकता है।
ओरिजिनेट टाइमस्टैम्प वह समय है जब प्रेषक ने संदेश भेजने से पहले आखिरी बार संदेश को छुआ था।
रिसीव टाइमस्टैम्प वह समय है जब रिसीव करने वाले ने रिसीव होने पर सबसे पहले इसे छुआ था।
ट्रांसमिट टाइमस्टैम्प वह समय है जब इकोर ने आखिरी बार संदेश भेजने पर उसे छुआ था।
सभी टाइमस्टैम्प मिलीसेकंड की इकाइयों में आधी रात यूटी के बाद से हैं। यदि समय मिलीसेकंड में उपलब्ध नहीं है या मध्यरात्रि यूटी के संबंध में प्रदान नहीं किया जा सकता है तो टाइमस्टैम्प में किसी भी समय को डाला जा सकता है बशर्ते टाइमस्टैम्प का उच्च क्रम बिट भी इस गैर-मानक मान को इंगित करने के लिए सेट हो।

इंटरनेट नोड्स की घड़ियों को सिंक्रनाइज़ करने के लिए टाइमस्टैम्प और टाइमस्टैम्प उत्तर संदेशों का उपयोग बड़े पैमाने पर यूडीपी-आधारित नेटवर्क टाइम प्रोटोकॉल और सटीक समय प्रोटोकॉल द्वारा प्रतिस्थापित किया गया है।[12]


एड्रेस मास्क रिक्वेस्ट

उपयुक्त सबनेट मास्क प्राप्त करने के लिए एड्रेस मास्क अनुरोध सामान्य रूप से सर्वर (कंप्यूटिंग) द्वारा राउटर (कंप्यूटिंग) को भेजा जाता है।

प्राप्तकर्ताओं को इस संदेश का उत्तर #Address मास्क उत्तर संदेश के साथ देना चाहिए।

एड्रेस मास्क रिक्वेस्ट
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
टाइप = 17 कोड = 0 चेकसम
पहचानकर्ता अनुक्रम संख्या
एड्रेस मास्क

जहाँ:

प्रकार 17 पर सेट होना चाहिए
कोड 0 पर सेट होना चाहिए
पता मुखौटा 0 पर सेट किया जा सकता है

लक्ष्य नेटवर्क पर जानकारी इकट्ठा करने के लिए आईसीएमपीएड्रेस मास्क अनुरोध का उपयोग टोही हमले के भाग के रूप में किया जा सकता है, इसलिए आईसीएमपीएड्रेस मास्क रिप्लाई सिस्को IOS पर डिफ़ॉल्ट रूप से अक्षम है।[13]


एड्रेस मास्क रिप्लाई

एड्रेस मास्क रिप्लाई का उपयोग एड्रेस मास्क रिक्वेस्ट मैसेज का उपयुक्त सबनेट मास्क के साथ जवाब देने के लिए किया जाता है।

एड्रेस मास्क रिप्लाई
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
टाइप = 18 कोड = 0 चेकसम
पहचानकर्ता अनुक्रम संख्या
एड्रेस मास्क

जहाँ:

प्रकार 18 पर सेट होना चाहिए
कोड 0 पर सेट होना चाहिए
एड्रेस मास्क सबनेट मास्क पर सेट होना चाहिए

गंतव्य अगम्य

गंतव्य अगम्य मेजबान या उसके इनबाउंड गेटवे द्वारा उत्पन्न होता है[6] ग्राहक को सूचित करने के लिए कि गंतव्य किसी कारण से पहुंच योग्य नहीं है। इस संदेश के कारणों में सम्मिलित हो सकते हैं: मेजबान से भौतिक संबंध उपस्थित नहीं है (दूरी अनंत है); संकेतित प्रोटोकॉल या पोर्ट सक्रिय नहीं है; डेटा खंडित होना चाहिए लेकिन 'टुकड़ा न करें' ध्वज चालू है। अगम्य टीसीपी पोर्ट विशेष रूप से टीसीपी आरएसटी के अतिरिक्त 'गंतव्य अगम्य' टाइप 3 के साथ प्रतिक्रिया करते हैं, जैसा कि उम्मीद की जा सकती है। आईपी ​​​​मल्टीकास्ट प्रसारण के लिए गंतव्य अगम्य की कभी सूचना नहीं दी जाती है।

गंतव्य अगम्य संदेश[6]: 3 
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
टाइप = 3 कोड चेकसम
अप्रयुक्त नेक्स्ट-हॉप एमटीयू
आईपी हेडर और मूल डेटाग्राम के डेटा के पहले 8 बाइट्स

जहाँ:

टाइप फ़ील्ड (बिट्स 0–7) को 3 पर सेट किया जाना चाहिए
कोड फ़ील्ड (बिट्स 8-15) का उपयोग त्रुटि के प्रकार को निर्दिष्ट करने के लिए किया जाता है, और निम्न में से कोई भी हो सकता है:
कोड विवरण
0 नेटवर्क अगम्य त्रुटि
1 होस्ट अगम्य त्रुटि।
2 प्रोटोकॉल अगम्य त्रुटि (निर्दिष्ट परिवहन प्रोटोकॉल समर्थित नहीं है)।
3 पोर्ट अगम्य त्रुटि (निर्दिष्ट प्रोटोकॉल आने वाले संदेश के होस्ट को सूचित करने में असमर्थ है)
4 डेटाग्राम बहुत बड़ा है। पैकेट फ़्रेग्मेंटेशन आवश्यक है लेकिन 'फ़्रैगमेंट न करें' (DF) फ़्लैग चालू है।
5 स्रोत मार्ग विफल त्रुटि।
6 गंतव्य नेटवर्क अज्ञात त्रुटि।
7 गंतव्य होस्ट अज्ञात त्रुटि।
8 स्रोत होस्ट पृथक त्रुटि।
9 गंतव्य नेटवर्क प्रशासनिक रूप से प्रतिबंधित है।
10 गंतव्य होस्ट प्रशासनिक रूप से प्रतिबंधित है।
11 ऑफ सर्विस के लिए नेटवर्क पहुंच योग्य नहीं है।
12 ऑफ सर्विस के लिए होस्ट पहुंच योग्य नहीं है।
13 संचार प्रशासनिक रूप से प्रतिबंधित है (प्रशासनिक फ़िल्टरिंग पैकेट को अग्रेषित होने से रोकता है)।
14 होस्ट वरीयता उल्लंघन (होस्ट या नेटवर्क और पोर्ट के संयोजन के लिए अनुरोधित प्राथमिकता की अनुमति नहीं है) इंगित करता है।
15 वरीयता कटऑफ प्रभाव में है (डेटाग्राम की प्राथमिकता नेटवर्क प्रशासकों द्वारा निर्धारित स्तर से नीचे है)।
नेक्स्ट-हॉप एमटीयू फील्ड (बिट्स 48-63) में नेक्स्ट-हॉप नेटवर्क का एमटीयू होता है यदि कोड 4 त्रुटि होती है।[14]
आईपी हेडर और अतिरिक्त डेटा सम्मिलित किया गया है ताकि क्लाइंट को उस अनुरोध के साथ उत्तर का मिलान करने की अनुमति मिल सके जिसके कारण गंतव्य तक पहुंचने योग्य उत्तर नहीं मिला।

यह भी देखें

संदर्भ

  1. ↑ F. Baker (June 1995). Baker, F (ed.). Requirements for IP Version 4 Routers. p. 52. RFC 1812.
  2. ↑ 2.0 2.1 2.2 2.3 Forouzan, Behrouz A. (2007). डेटा संचार और नेटवर्किंग (Fourth ed.). Boston: McGraw-Hill. pp. 621–630. ISBN 978-0-07-296775-3.
  3. ↑ "ओएसआई मॉडल सात परतों की परिभाषा और कार्यों की व्याख्या". Microsoft Support. Retrieved 2014-12-28.
  4. ↑ "प्रोटोकॉल नंबर". Internet Assigned Numbers Authority. Retrieved 2011-06-23.
  5. ↑ Requirements for IP Version 4 Routers. doi:10.17487/RFC1812. RFC 1812.
  6. ↑ 6.00 6.01 6.02 6.03 6.04 6.05 6.06 6.07 6.08 6.09 6.10 Postel, J. (September 1981). Internet Control Message Protocol. IETF. doi:10.17487/RFC0792. RFC 792.
  7. ↑ "IANA ICMP Parameters". Iana.org. 2012-09-21. Retrieved 2013-01-07.
  8. ↑ Kurose, J.F; Ross, K.W. (2006). Computer Networking: A Top-Down Approach. World student series. Addison-Wesley. ISBN 9780321418494.
  9. ↑ 9.0 9.1 PROBE: A Utility for Probing Interfaces. doi:10.17487/RFC8335. RFC 8335.
  10. ↑ RFC 6633
  11. ↑ "When Are ICMP Redirects Sent?". Cisco Systems. 2008-06-28. Retrieved 2013-08-15.
  12. ↑ D.L. Mills (September 1985). नेटवर्क टाइम प्रोटोकॉल (NTP). doi:10.17487/RFC0958. RFC 958. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both.
  13. ↑ "Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and Services, Release 12.3 - IP Addressing and Services Commands: ip mask-reply through ip web-cache". Cisco Systems. Archived from the original on 2013-01-02. Retrieved 2013-01-07.
  14. ↑ Extended ICMP to Support Multi-Part Messages. doi:10.17487/RFC4884. RFC 4884.


स्रोत

आरएफसी

  • RFC 792, इंटरनेट नियंत्रण संदेश प्रोटोकॉल
  • RFC 950, इंटरनेट मानक सबनेटिंग प्रक्रिया
  • RFC 1016, होस्ट कुछ ऐसा कर सकता है जो सोर्स क्वेंच के साथ कर सकता है: सोर्स क्वेंच इंट्रोड्यूस्ड डिले (SQuID)
  • RFC 1122, इंटरनेट होस्ट के लिए आवश्यकताएँ - संचार परतें
  • RFC 1716, आईपी रूटर्स के लिए आवश्यकताओं की ओर
  • RFC 1812, आईपी संस्करण 4 रूटर्स के लिए आवश्यकताएँ
  • RFC 4884, मल्टी-पार्ट संदेशों का समर्थन करने के लिए विस्तारित ICMP

बाहरी संबंध

Wikiversity has learning resources about Internet Control Message Protocol
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=इंटरनेट_नियंत्रण_संदेश_प्रोटोकॉल&oldid=184800’