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

From Vigyanwiki
No edit summary
No edit summary
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]] के लिए ICMP में परिभाषित किया गया है {{IETF RFC|792}}. RFC 4443 द्वारा परिभाषित एक अलग [[ICMPv6]], [[IPv6]] के साथ प्रयोग किया जाता है।
[[IPv4]] के लिए आईसीएमपीमें परिभाषित किया गया है {{IETF RFC|792}}. RFC 4443 द्वारा परिभाषित एक अलग [[ICMPv6]], [[IPv6]] के साथ प्रयोग किया जाता है।


{{IPstack}}
{{IPstack}}


== तकनीकी विवरण ==
== तकनीकी विवरण ==
ICMP [[इंटरनेट प्रोटोकॉल]] सूट का हिस्सा है जैसा कि RFC 792 में परिभाषित किया गया है। ICMP संदेश आमतौर पर निदान या नियंत्रण उद्देश्यों के लिए उपयोग किए जाते हैं या इंटरनेट प्रोटोकॉल संचालन में त्रुटियों के जवाब में उत्पन्न होते हैं (जैसा कि RFC 1122 में निर्दिष्ट है)। ICMP त्रुटियाँ मूल पैकेट के स्रोत IP पते पर निर्देशित की जाती हैं।<ref name="Forouzan" />  
आईसीएमपी[[इंटरनेट प्रोटोकॉल]] सूट का भाग है जैसा कि RFC 792 में परिभाषित किया गया है। आईसीएमपीसंदेश सामान्यतः निदान या नियंत्रण उद्देश्यों के लिए उपयोग किए जाते हैं या इंटरनेट प्रोटोकॉल संचालन में त्रुटियों के उत्तर में उत्पन्न होते हैं (जैसा कि RFC 1122 में निर्दिष्ट है)। आईसीएमपीत्रुटियाँ मूल पैकेट के स्रोत आईपी पते पर निर्देशित की जाती हैं।<ref name="Forouzan" />  
उदाहरण के लिए, प्रत्येक डिवाइस (जैसे एक इंटरमीडिएट राउटर (कंप्यूटिंग)) एक आईपी [[आंकड़ारेख]] को अग्रेषित करने से पहले आईपी हेडर में रहने के समय (टीटीएल) फ़ील्ड को एक से कम कर देता है। यदि परिणामी TTL 0 है, तो पैकेट को छोड़ दिया जाता है और डेटाग्राम के स्रोत पते पर एक ICMP #समय से अधिक संदेश भेजा जाता है।


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


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


ICMP एक [[ नेटवर्क परत ]]|नेटवर्क-लेयर प्रोटोकॉल है, जो इसे 7 लेयर OSI मॉडल द्वारा लेयर 3 प्रोटोकॉल बनाता है। 4 परत टीसीपी/आईपी मॉडल के आधार पर, आईसीएमपी एक [[इंटरनेट परत]] है। इंटरनेट-परत प्रोटोकॉल, जो इसे परत 2 प्रोटोकॉल (4 परतों वाला इंटरनेट मानक आरएफसी 1122 टीसीपी/आईपी मॉडल) या आधुनिक 5 परत टीसीपी पर आधारित परत 3 प्रोटोकॉल बनाता है। /आईपी प्रोटोकॉल परिभाषाएँ (कोज़िएरोक, कॉमर, तनेनबाउम, फ़ोरोज़न, कुरोज़, स्टालिंग्स द्वारा)।{{CN|date=January 2023}} Forouzan और Kurose अपनी TCP/IP मॉडल परिभाषा में इंटरनेट-लेयर के बजाय नेटवर्क-लेयर का उपयोग करते हैं। मॉडलों के बीच ये अंतर अक्सर व्यर्थ और अंतहीन बहस का कारण बनते हैं।{{According to whom|date=April 2023}}
आईसीएमपीआईपी के मूल समर्थन का उपयोग करता है जैसे कि यह एक उच्च-स्तरीय प्रोटोकॉल था, चुकीं, आईसीएमपीवास्तव में आईपी का एक अभिन्न अंग है। चुकीं आईसीएमपीसंदेश मानक आईपी पैकेट में समाहित होते हैं, आईसीएमपीसंदेशों को सामान्यतः एक विशेष स्थितियों के रूप में संसाधित किया जाता है, जो सामान्य आईपी प्रसंस्करण से अलग होता है। कई स्थितियों में, आईसीएमपी संदेश की सामग्री का निरीक्षण करना और आईपी पैकेट को प्रेषित करने के लिए जिम्मेदार एप्लिकेशन को उचित त्रुटि संदेश देना आवश्यक है जिससे आईसीएमपी संदेश भेजा जा सके।
 
आईसीएमपीएक [[ नेटवर्क परत | नेटवर्क परत]] '''| नेटवर्क-लेयर''' प्रोटोकॉल है, जो इसे 7 लेयर OSI मॉडल द्वारा लेयर 3 प्रोटोकॉल बनाता है। 4 परत टीसीपी/आईपी मॉडल के आधार पर, आईसीएमपी एक [[इंटरनेट परत]] है। इंटरनेट-परत प्रोटोकॉल, जो इसे परत 2 प्रोटोकॉल (4 परतों वाला इंटरनेट मानक आरएफसी 1122 टीसीपी/आईपी मॉडल) या आधुनिक 5 परत टीसीपी पर आधारित परत 3 प्रोटोकॉल बनाता है। /आईपी प्रोटोकॉल परिभाषाएँ (कोज़िएरोक, कॉमर, तनेनबाउम, फ़ोरोज़न, कुरोज़, स्टालिंग्स द्वारा)।{{CN|date=January 2023}} फ़ोरोज़न और कुरोस अपनी टीसीपी /आईपी मॉडल परिभाषा में इंटरनेट-लेयर के अतिरिक्त  नेटवर्क-लेयर का उपयोग करते हैं। मॉडलों के बीच ये अंतर अक्सर व्यर्थ और अंतहीन बहस का कारण बनते हैं।{{According to whom|date=April 2023}}
 
आईसीएमपीपैकेट के साथ कोई टीसीपी  या यूडीपी पोर्ट नंबर नहीं जुड़ा है क्योंकि ये नंबर ऊपर [[ ट्रांसपोर्ट परत | ट्रांसपोर्ट परत]] से जुड़े हैं।<ref>{{Cite web | title = ओएसआई मॉडल सात परतों की परिभाषा और कार्यों की व्याख्या| work = Microsoft Support | access-date = 2014-12-28 | url = https://support.microsoft.com/kb/103884}}</ref>


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




== डेटाग्राम संरचना ==
== डेटाग्राम संरचना ==
ICMP पैकेट IPv4 पैकेट में समाहित है।<ref name="Forouzan" />पैकेट में हेडर और डेटा सेक्शन होते हैं।
आईसीएमपीपैकेट IPv4 पैकेट में समाहित है।<ref name="Forouzan" /> पैकेट में हेडर और डेटा सेक्शन होते हैं।


=== हैडर ===
=== हैडर ===
ICMP हेडर IPv4#Header के बाद शुरू होता है और IP प्रोटोकॉल नंबर '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> सभी ICMP पैकेट में 8-बाइट हेडर और वेरिएबल-साइज़ डेटा सेक्शन होता है। हेडर के पहले 4 बाइट्स का प्रारूप निश्चित होता है, जबकि अंतिम 4 बाइट्स उस ICMP पैकेट के प्रकार/कोड पर निर्भर करते हैं।<ref name="Forouzan" />
आईसीएमपी हेडर 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" />


{| class="wikitable"
{| class="wikitable"
|+ICMP header format
|+आईसीएमपी हेडर प्रारूप
|-
|-
! ''Offsets''
! ''Offsets''
Line 102: Line 104:
! 0
! 0
! 0
! 0
| colspan="8"|[[#header_type|Type]]
| colspan="8"|प्रकार
| colspan="8"|[[#header_code|Code]]
| colspan="8"|कोड
| colspan="16"|[[#header_checksum|Checksum]]
| colspan="16"|[[#header_checksum|चेक योग]]
|- style="text-align:center;"
|- style="text-align:center;"
! 4
! 4
! 32
! 32
| colspan="32"|[[#header_rest|Rest of header]]
| colspan="32"|[[#header_rest|बाकी हेडर]]
|-
|-
|}
|}
; प्रकार {{anchor|header_type}}: ICMP प्रकार, देखें {{slink||Control messages}}.
; प्रकार {{anchor|header_type}}: आईसीएमपी प्रकार, देखें {{slink||संदेशों को नियंत्रित करें}}.
; कोड {{anchor|header_code}}: ICMP उपप्रकार, देखें {{slink||Control messages}}.
; कोड {{anchor|header_code}}: आईसीएमपी उपप्रकार, देखें {{slink||संदेशों को नियंत्रित करें}}.
; अंततः, {{anchor|header_checksum}}: त्रुटि जाँच के लिए इंटरनेट चेकसम (RFC 1071), ICMP हेडर से गणना की जाती है और इस फ़ील्ड के लिए मान 0 के साथ डेटा प्रतिस्थापित किया जाता है।
; अंततः, {{anchor|header_checksum}}: त्रुटि जाँच के लिए इंटरनेट चेकसम (RFC 1071), आईसीएमपीहेडर से गणना की जाती है और इस फ़ील्ड के लिए मान 0 के साथ डेटा प्रतिस्थापित किया जाता है।
; बाकी हेडर {{anchor|header_rest}}: चार-बाइट फ़ील्ड, सामग्री ICMP प्रकार और कोड के आधार पर भिन्न होती है।
; बाकी हेडर {{anchor|header_rest}}: चार-बाइट फ़ील्ड, सामग्री आईसीएमपी प्रकार और कोड के आधार पर भिन्न होती है।


=== डेटा ===
=== डेटा ===
ICMP त्रुटि संदेशों में एक डेटा खंड होता है जिसमें संपूर्ण IPv4 हेडर की एक प्रति, साथ ही IPv4 पैकेट से डेटा के कम से कम पहले आठ बाइट्स शामिल होते हैं जो त्रुटि संदेश का कारण बनते हैं। ICMP त्रुटि संदेशों की लंबाई 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/>


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


== नियंत्रण संदेश ==
== नियंत्रण संदेश ==
नियंत्रण संदेशों को प्रकार फ़ील्ड में मान द्वारा पहचाना जाता है। कोड फ़ील्ड संदेश के लिए अतिरिक्त संदर्भ जानकारी देता है। प्रोटोकॉल के पहली बार पेश किए जाने के बाद से कुछ नियंत्रण संदेशों को बहिष्कृत कर दिया गया है।
नियंत्रण संदेशों को प्रकार फ़ील्ड में मान द्वारा पहचाना जाता है। कोड फ़ील्ड संदेश के लिए अतिरिक्त संदर्भ जानकारी देता है। प्रोटोकॉल के पहली बार पेश किए जाने के बाद से कुछ नियंत्रण संदेशों को बहिष्कृत कर दिया गया है।
{| class="wikitable"
{| class="wikitable"
|+Notable control messages<ref>{{cite web|url=https://www.iana.org/assignments/icmp-parameters |title=IANA ICMP Parameters |publisher=Iana.org |date=2012-09-21 |access-date=2013-01-07}}</ref><ref>{{cite book |title=Computer Networking: A Top-Down Approach |author1=Kurose, J.F |author2=Ross, K.W. |isbn=9780321418494 |series=World student series |url=https://books.google.com/books?id=QXIwPwAACAAJ |date=2006 |publisher=Addison-Wesley}}</ref>
|+उल्लेखनीय नियंत्रण संदेश<ref>{{cite web|url=https://www.iana.org/assignments/icmp-parameters |title=IANA ICMP Parameters |publisher=Iana.org |date=2012-09-21 |access-date=2013-01-07}}</ref><ref>{{cite book |title=Computer Networking: A Top-Down Approach |author1=Kurose, J.F |author2=Ross, K.W. |isbn=9780321418494 |series=World student series |url=https://books.google.com/books?id=QXIwPwAACAAJ |date=2006 |publisher=Addison-Wesley}}</ref>
!        Type !! Code !! Status !! Description
!        प्रकार !! कोड !! स्थिति !! विवरण
|-
|-
||0 – Echo Reply<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    || || Echo reply (used to [[Ping (networking utility)|ping]])
|                0    || || प्रतिध्वनि उत्तर '''(used to''' [[Ping (networking utility)|(पिंग के लिए प्रयुक्त)]])
|-
|-
||1 and 2
||1 और 2
|                      || {{n/a|unassigned}} || ''Reserved''
|                      || {{n/a|unassigned}} || ''Reserved''
|-
|-
Line 196: Line 198:
|                  1  || || Fragment reassembly time exceeded
|                  1  || || Fragment reassembly time exceeded
|-
|-
|rowspan=3| 12 – Parameter Problem: Bad IP header
|rowspan=3| 12 – Parameter Problem: Bad आईपी header
|                  0  || || Pointer indicates the error
|                  0  || || Pointer indicates the error
|-
|-
Line 244: Line 246:
| 38          ||      || {{dc|deprecated}}|| Domain Name Reply
| 38          ||      || {{dc|deprecated}}|| Domain Name Reply
|-
|-
| 39          ||      || {{dc|deprecated}}|| SKIP Algorithm Discovery Protocol, [[Simple Key-Management for Internet Protocol]]
| 39          ||      || {{dc|deprecated}}|| SKआईपी Algorithm Discovery Protocol, [[Simple Key-Management for Internet Protocol]]
|-
|-
| 40          ||      || || [[Photuris (protocol)|Photuris]], Security failures
| 40          ||      || || [[Photuris (protocol)|Photuris]], Security failures
|-
|-
| 41          ||      || {{table-experimental}} || ICMP for experimental mobility protocols such as [[Seamoby]] [RFC4065]
| 41          ||      || {{table-experimental}} || आईसीएमपीfor experimental mobility protocols such as [[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>
Line 277: Line 279:
स्रोत बुझाना अनुरोध करता है कि प्रेषक राउटर या होस्ट को भेजे गए संदेशों की दर कम कर देता है। यह संदेश उत्पन्न हो सकता है यदि राउटर या होस्ट के पास अनुरोध को संसाधित करने के लिए पर्याप्त बफर स्थान नहीं है, या यदि राउटर या होस्ट बफर अपनी सीमा तक पहुंच रहा है तो यह संदेश उत्पन्न हो सकता है।
स्रोत बुझाना अनुरोध करता है कि प्रेषक राउटर या होस्ट को भेजे गए संदेशों की दर कम कर देता है। यह संदेश उत्पन्न हो सकता है यदि राउटर या होस्ट के पास अनुरोध को संसाधित करने के लिए पर्याप्त बफर स्थान नहीं है, या यदि राउटर या होस्ट बफर अपनी सीमा तक पहुंच रहा है तो यह संदेश उत्पन्न हो सकता है।


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


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


{| class="wikitable"
{| class="wikitable"
Line 294: Line 296:
| colspan="32" style="text-align:center;"| unused
| colspan="32" style="text-align:center;"| unused
|-
|-
| colspan="32" style="text-align:center;"| IP header and first 8 bytes of original datagram's data
| colspan="32" style="text-align:center;"| आईपी header and first 8 bytes of original datagram's data
|}
|}
कहाँ:
कहाँ:
: प्रकार 4 पर सेट होना चाहिए
: प्रकार 4 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
: कोड 0 पर सेट होना चाहिए
: IP हेडर और अतिरिक्त डेटा का उपयोग प्रेषक द्वारा संबंधित अनुरोध के साथ उत्तर का मिलान करने के लिए किया जाता है
: आईपी हेडर और अतिरिक्त डेटा का उपयोग प्रेषक द्वारा संबंधित अनुरोध के साथ उत्तर का मिलान करने के लिए किया जाता है


=== रीडायरेक्ट ===
=== रीडायरेक्ट ===
[[File:ICMPv4 redirect message example-en.svg|thumb|ICMPv4 रीडायरेक्ट संदेश कैसे काम करता है इसका एक उदाहरण]]रीडायरेक्ट अनुरोध डेटा पैकेट वैकल्पिक मार्ग पर भेजे जाएं। ICMP रीडायरेक्ट राउटर्स के लिए मेजबानों को रूटिंग जानकारी देने के लिए एक तंत्र है। संदेश एक मेजबान को अपनी रूटिंग जानकारी अपडेट करने के लिए सूचित करता है (वैकल्पिक मार्ग पर पैकेट भेजने के लिए)। यदि कोई होस्ट एक राउटर (कंप्यूटिंग) (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"
Line 316: Line 318:
| colspan="16"| Checksum
| colspan="16"| Checksum
|-
|-
| colspan="32" style="text-align:center;"| IP address
| colspan="32" style="text-align:center;"| आईपी address
|-
|-
| colspan="32" style="text-align:center;"| IP header and first 8 bytes of original datagram's data
| colspan="32" style="text-align:center;"| आईपी header and first 8 bytes of original datagram's data
|}
|}
कहाँ:
कहाँ:
Line 340: Line 342:
| Redirect for Type of Service and Host
| Redirect for Type of Service and Host
|}
|}
: IP पता गेटवे का 32-बिट पता है जिस पर पुनर्निर्देशन भेजा जाना चाहिए।
: आईपी पता गेटवे का 32-बिट पता है जिस पर पुनर्निर्देशन भेजा जाना चाहिए।
: आईपी हेडर और अतिरिक्त डेटा शामिल किया गया है ताकि होस्ट को उस अनुरोध के साथ उत्तर का मिलान करने की अनुमति मिल सके जो पुनर्निर्देशन उत्तर का कारण बना।
: आईपी हेडर और अतिरिक्त डेटा सम्मिलित  किया गया है ताकि होस्ट को उस अनुरोध के साथ उत्तर का मिलान करने की अनुमति मिल सके जो पुनर्निर्देशन उत्तर का कारण बना।


=== समय पार हो गया ===
=== समय पार हो गया ===
Line 361: Line 363:
| colspan="32" style="text-align:center;"| unused
| colspan="32" style="text-align:center;"| unused
|-
|-
| colspan="32" style="text-align:center;"| IP header and first 8 bytes of original datagram's data
| colspan="32" style="text-align:center;"| आईपी header and first 8 bytes of original datagram's data
|}
|}
कहाँ:
कहाँ:
: प्रकार 11 पर सेट होना चाहिए
: प्रकार 11 पर सेट होना चाहिए
: कोड 'समय से अधिक' संदेश का कारण निर्दिष्ट करता है, इसमें निम्नलिखित शामिल हैं:
: कोड 'समय से अधिक' संदेश का कारण निर्दिष्ट करता है, इसमें निम्नलिखित सम्मिलित  हैं:
::{| class="wikitable"
::{| class="wikitable"
! Code || Description
! Code || Description
Line 375: Line 377:
| Fragment reassembly time exceeded.
| Fragment reassembly time exceeded.
|}
|}
: आईपी हेडर और मूल [[पेलोड (कंप्यूटिंग)]] के पहले 64 बिट्स का उपयोग स्रोत होस्ट द्वारा छोड़े गए डेटाग्राम के समय से अधिक संदेश से मिलान करने के लिए किया जाता है। उपयोगकर्ता डेटाग्राम प्रोटोकॉल और ट्रांसमिशन कंट्रोल प्रोटोकॉल जैसे उच्च-स्तरीय प्रोटोकॉल के लिए 64-बिट पेलोड में हटाए गए पैकेट के स्रोत और गंतव्य पोर्ट शामिल होंगे।
: आईपी हेडर और मूल [[पेलोड (कंप्यूटिंग)]] के पहले 64 बिट्स का उपयोग स्रोत होस्ट द्वारा छोड़े गए डेटाग्राम के समय से अधिक संदेश से मिलान करने के लिए किया जाता है। उपयोगकर्ता डेटाग्राम प्रोटोकॉल और ट्रांसमिशन कंट्रोल प्रोटोकॉल जैसे उच्च-स्तरीय प्रोटोकॉल के लिए 64-बिट पेलोड में हटाए गए पैकेट के स्रोत और गंतव्य पोर्ट सम्मिलित  होंगे।


=== [[ TIMESTAMP ]] ===
=== [[ TIMESTAMP ]] ===
Line 468: Line 470:
: पता मुखौटा 0 पर सेट किया जा सकता है
: पता मुखौटा 0 पर सेट किया जा सकता है


लक्ष्य नेटवर्क पर जानकारी इकट्ठा करने के लिए ICMP एड्रेस मास्क अनुरोध का उपयोग टोही हमले के एक भाग के रूप में किया जा सकता है, इसलिए ICMP एड्रेस मास्क रिप्लाई सिस्को 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>




Line 496: Line 498:


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


  {| class="wikitable"
  {| class="wikitable"
Line 512: Line 514:
| colspan="16"| Next-hop MTU
| colspan="16"| Next-hop MTU
|-
|-
| colspan="32" style="text-align:center;"| IP header and first 8 bytes of original datagram's data
| colspan="32" style="text-align:center;"| आईपी header and first 8 bytes of original datagram's data
|}
|}
कहाँ:
कहाँ:
Line 569: Line 571:
|}
|}
: नेक्स्ट-हॉप एमटीयू फील्ड (बिट्स 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>
: आईपी हेडर और अतिरिक्त डेटा शामिल किया गया है ताकि क्लाइंट को उस अनुरोध के साथ उत्तर का मिलान करने की अनुमति मिल सके जिसके कारण गंतव्य तक पहुंचने योग्य उत्तर नहीं मिला।
: आईपी हेडर और अतिरिक्त डेटा सम्मिलित  किया गया है ताकि क्लाइंट को उस अनुरोध के साथ उत्तर का मिलान करने की अनुमति मिल सके जिसके कारण गंतव्य तक पहुंचने योग्य उत्तर नहीं मिला।


== यह भी देखें ==
== यह भी देखें ==
Line 598: Line 600:
==बाहरी संबंध==
==बाहरी संबंध==
{{Wikiversity | Internet Control Message Protocol}}
{{Wikiversity | Internet Control Message Protocol}}
* [https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml IANA ICMP parameters]
* [https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml IANA आईसीएमपीparameters]
* [https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml IANA protocol numbers]
* [https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml IANA protocol numbers]
* {{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}}

Revision as of 00:17, 23 May 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 प्रोटोकॉल बनाता है। /आईपी प्रोटोकॉल परिभाषाएँ (कोज़िएरोक, कॉमर, तनेनबाउम, फ़ोरोज़न, कुरोज़, स्टालिंग्स द्वारा)।[citation needed] फ़ोरोज़न और कुरोस अपनी टीसीपी /आईपी मॉडल परिभाषा में इंटरनेट-लेयर के अतिरिक्त नेटवर्क-लेयर का उपयोग करते हैं। मॉडलों के बीच ये अंतर अक्सर व्यर्थ और अंतहीन बहस का कारण बनते हैं।[according to whom?]

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


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

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

हैडर

आईसीएमपी हेडर IPv4#Header के बाद प्रारंभ होता है और आईपी प्रोटोकॉल नंबर '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 प्रतिध्वनि उत्तर (used to (पिंग के लिए प्रयुक्त))
1 और 2 unassigned Reserved
3 – Destination Unreachable[6]: 4  0 Destination network unreachable
1 Destination host unreachable
2 Destination protocol unreachable
3 Destination port unreachable
4 Fragmentation required, and DF flag set
5 Source route failed
6 Destination network unknown
7 Destination host unknown
8 Source host isolated
9 Network administratively prohibited
10 Host administratively prohibited
11 Network unreachable for ToS
12 Host unreachable for ToS
13 Communication administratively prohibited
14 Host Precedence Violation
15 Precedence cutoff in effect
4 – Source Quench 0 deprecated Source quench (congestion control)
5 – Redirect Message 0 Redirect Datagram for the Network
1 Redirect Datagram for the Host
2 Redirect Datagram for the ToS & network
3 Redirect Datagram for the ToS & host
6 deprecated Alternate Host Address
7 unassigned Reserved
8 – Echo Request 0 Echo request (used to ping)
9 – Router Advertisement 0 Router Advertisement
10 – Router Solicitation 0 Router discovery/selection/solicitation
11 – Time Exceeded[6]: 6  0 TTL expired in transit
1 Fragment reassembly time exceeded
12 – Parameter Problem: Bad आईपी header 0 Pointer indicates the error
1 Missing a required option
2 Bad length
13 – Timestamp 0 Timestamp
14 – Timestamp Reply 0 Timestamp reply
15 – Information Request 0 deprecated Information Request
16 – Information Reply 0 deprecated Information Reply
17 – Address Mask Request 0 deprecated Address Mask Request
18 – Address Mask Reply 0 deprecated Address Mask Reply
19 reserved Reserved for security
20 through 29 reserved Reserved for robustness experiment
30 – Traceroute 0 deprecated Information Request
31 deprecated Datagram Conversion Error
32 deprecated Mobile Host Redirect
33 deprecated Where-Are-You (originally meant for IPv6)
34 deprecated Here-I-Am (originally meant for IPv6)
35 deprecated Mobile Registration Request
36 deprecated Mobile Registration Reply
37 deprecated Domain Name Request
38 deprecated Domain Name Reply
39 deprecated SKआईपी Algorithm Discovery Protocol, Simple Key-Management for Internet Protocol
40 Photuris, Security failures
41 Experimental आईसीएमपीfor experimental mobility protocols such as Seamoby [RFC4065]
42 – Extended Echo Request[9] 0 Request Extended Echo (XPing - see Extended Ping (Xping))
43 – Extended Echo Reply[9] 0 No Error
1 Malformed Query
2 No Such Interface
3 No Such Table Entry
4 Multiple Interfaces Satisfy Query
44 through 252 unassigned Reserved
253 Experimental RFC3692-style Experiment 1 (RFC 4727)
254 Experimental RFC3692-style Experiment 2 (RFC 4727)
255 reserved Reserved


स्रोत बुझाना

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

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

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

Source quench message[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
Type = 4 Code = 0 Checksum
unused
आईपी header and first 8 bytes of original datagram's data

कहाँ:

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

रीडायरेक्ट

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

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

Redirect message[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
Type = 5 Code Checksum
आईपी address
आईपी header and first 8 bytes of original datagram's data

कहाँ:

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

समय पार हो गया

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

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

Time exceeded message[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
Type = 11 Code Checksum
unused
आईपी header and first 8 bytes of original datagram's data

कहाँ:

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

TIMESTAMP

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

Timestamp message[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
Type = 13 Code = 0 Checksum
Identifier Sequence number
Originate timestamp
Receive timestamp
Transmit timestamp

कहाँ:

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

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

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

Timestamp reply message[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
Type = 14 Code = 0 Checksum
Identifier Sequence number
Originate timestamp
Receive timestamp
Transmit timestamp

कहाँ:

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

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


पता मुखौटा अनुरोध

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

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

Address mask request
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
Type = 17 Code = 0 Checksum
Identifier Sequence number
Address mask

कहाँ:

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

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


पता मुखौटा उत्तर

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

Address mask reply
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
Type = 18 Code = 0 Checksum
Identifier Sequence number
Address mask

कहाँ:

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

गंतव्य अगम्य

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

Destination unreachable message[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
Type = 3 Code Checksum
unused Next-hop MTU
आईपी header and first 8 bytes of original datagram's data

कहाँ:

टाइप फ़ील्ड (बिट्स 0–7) को 3 पर सेट किया जाना चाहिए
कोड फ़ील्ड (बिट्स 8-15) का उपयोग त्रुटि के प्रकार को निर्दिष्ट करने के लिए किया जाता है, और निम्न में से कोई भी हो सकता है:
Code Description
0 Network unreachable error.
1 Host unreachable error.
2 Protocol unreachable error (the designated transport protocol is not supported).
3 Port unreachable error (the designated protocol is unable to inform the host of the incoming message).
4 The datagram is too big. Packet fragmentation is required but the 'don't fragment' (DF) flag is on.
5 Source route failed error.
6 Destination network unknown error.
7 Destination host unknown error.
8 Source host isolated error.
9 The destination network is administratively prohibited.
10 The destination host is administratively prohibited.
11 The network is unreachable for Type Of Service.
12 The host is unreachable for Type Of Service.
13 Communication administratively prohibited (administrative filtering prevents packet from being forwarded).
14 Host precedence violation (indicates the requested precedence is not permitted for the combination of host or network and port).
15 Precedence cutoff in effect (precedence of datagram is below the level set by the network administrators).
नेक्स्ट-हॉप एमटीयू फील्ड (बिट्स 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=176882’