इंटरनेट नियंत्रण संदेश प्रोटोकॉल: 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]] के लिए आईसीएमपीमें परिभाषित किया गया है {{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
Line 248: Line 248:
| 39          ||      || {{dc|deprecated}}|| एसकेआईपी एल्गोरिथम डिस्कवरी प्रोटोकॉल, [[Simple Key-Management for Internet Protocol|इंटरनेट प्रोटोकॉल के लिए सरल कुंजी-प्रबंधन]]
| 39          ||      || {{dc|deprecated}}|| एसकेआईपी एल्गोरिथम डिस्कवरी प्रोटोकॉल, [[Simple Key-Management for Internet Protocol|इंटरनेट प्रोटोकॉल के लिए सरल कुंजी-प्रबंधन]]
|-
|-
| 40          ||      || || [[Photuris (protocol)|फोटोरिस]],'''फोटोरिस''', सुरक्षा विफलताएं
| 40          ||      || || [[Photuris (protocol)|फोटोरिस]], सुरक्षा विफलताएं
|-
|-
| 41          ||      || {{table-experimental}} || आईसीएमपी प्रयोगात्मक गतिशीलता प्रोटोकॉल के लिए जैसे [[Seamoby|सीमोबी]] [RFC4065]
| 41          ||      || {{table-experimental}} || आईसीएमपी प्रयोगात्मक गतिशीलता प्रोटोकॉल के लिए जैसे [[Seamoby|सीमोबी]] [RFC4065]
Line 279: Line 279:
स्रोत बुझाना अनुरोध करता है कि प्रेषक राउटर या होस्ट को भेजे गए संदेशों की दर कम कर देता है। यह संदेश उत्पन्न हो सकता है यदि राउटर या होस्ट के पास अनुरोध को संसाधित करने के लिए पर्याप्त बफर स्थान नहीं है, या यदि राउटर या होस्ट बफर अपनी सीमा तक पहुंच रहा है तो यह संदेश उत्पन्न हो सकता है।
स्रोत बुझाना अनुरोध करता है कि प्रेषक राउटर या होस्ट को भेजे गए संदेशों की दर कम कर देता है। यह संदेश उत्पन्न हो सकता है यदि राउटर या होस्ट के पास अनुरोध को संसाधित करने के लिए पर्याप्त बफर स्थान नहीं है, या यदि राउटर या होस्ट बफर अपनी सीमा तक पहुंच रहा है तो यह संदेश उत्पन्न हो सकता है।


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


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


{| class="wikitable"
{| class="wikitable"
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"
Line 346: Line 346:


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


दो मेजबानों के बीच पथ पर गेटवे की पहचान करने के लिए ट्रेसरूट यूटिलिटी द्वारा समय से अधिक संदेशों का उपयोग किया जाता है।
दो मेजबानों के बीच पथ पर गेटवे की पहचान करने के लिए ट्रेसरूट यूटिलिटी द्वारा समय से अधिक संदेशों का उपयोग किया जाता है।
Line 365: Line 365:
| colspan="32" style="text-align:center;"| आईपी हेडर और मूल डेटाग्राम के डेटा के पहले 8 बाइट्स
| colspan="32" style="text-align:center;"| आईपी हेडर और मूल डेटाग्राम के डेटा के पहले 8 बाइट्स
|}
|}
कहाँ:
जहाँ:
: प्रकार 11 पर सेट होना चाहिए
: प्रकार 11 पर सेट होना चाहिए
: कोड 'समय से अधिक' संदेश का कारण निर्दिष्ट करता है, इसमें निम्नलिखित सम्मिलित  हैं:
: कोड 'समय से अधिक' संदेश का कारण निर्दिष्ट करता है, इसमें निम्नलिखित सम्मिलित  हैं:
Line 409: Line 409:


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


{| class="wikitable"
{| class="wikitable"
Line 470: Line 470:
: पता मुखौटा 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>




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: इंटरनेट प्रोटोकॉल]] [[Category: इंटरनेट मानक]] [[Category: इंटरनेट परत प्रोटोकॉल]] [[Category: नेटवर्क परत प्रोटोकॉल]]  
[[Category: इंटरनेट प्रोटोकॉल]] [[Category: इंटरनेट मानक]] [[Category: इंटरनेट परत प्रोटोकॉल]] [[Category: नेटवर्क परत प्रोटोकॉल]]  


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

आईसीएमपीपैकेट के साथ कोई टीसीपी या यूडीपी पोर्ट नंबर नहीं जुड़ा है क्योंकि ये नंबर ऊपर ट्रांसपोर्ट परत से जुड़े हैं।[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=176884’