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

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

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

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

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

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

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

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

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

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

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


 * प्रकार : आईसीएमपी प्रकार, देखें.
 * कोड : आईसीएमपी उपप्रकार, देखें.
 * अंततः, : त्रुटि जाँच के लिए इंटरनेट चेकसम (RFC 1071), आईसीएमपीहेडर से गणना की जाती है और इस फ़ील्ड के लिए मान 0 के साथ डेटा प्रतिस्थापित किया जाता है।
 * बाकी हेडर : चार-बाइट फ़ील्ड, सामग्री आईसीएमपी प्रकार और कोड के आधार पर भिन्न होती है।

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

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

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

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

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

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

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

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

कहाँ:
 * प्रकार 5 पर सेट होना चाहिए।
 * कोड पुनर्निर्देशन का कारण निर्दिष्ट करता है, और निम्न में से कोई एक हो सकता है:
 * {| class="wikitable"

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

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

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

कहाँ:
 * प्रकार 11 पर सेट होना चाहिए
 * कोड 'समय से अधिक' संदेश का कारण निर्दिष्ट करता है, इसमें निम्नलिखित सम्मिलित हैं:
 * {| class="wikitable"

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

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

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

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

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


 * सभी टाइमस्टैम्प मिलीसेकंड की इकाइयों में आधी रात यूटी के बाद से हैं। यदि समय मिलीसेकंड में उपलब्ध नहीं है या मध्यरात्रि यूटी के संबंध में प्रदान नहीं किया जा सकता है तो टाइमस्टैम्प में किसी भी समय को डाला जा सकता है बशर्ते टाइमस्टैम्प का उच्च क्रम बिट भी इस गैर-मानक मान को इंगित करने के लिए सेट हो।

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

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

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

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

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

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

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

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

कहाँ:
 * टाइप फ़ील्ड (बिट्स 0–7) को 3 पर सेट किया जाना चाहिए
 * कोड फ़ील्ड (बिट्स 8-15) का उपयोग त्रुटि के प्रकार को निर्दिष्ट करने के लिए किया जाता है, और निम्न में से कोई भी हो सकता है:
 * {| class="wikitable"

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

यह भी देखें

 * आईसीएमपी सुरंग
 * ICMP होल पंचिंग
 * ICMP राउटर डिस्कवरी प्रोटोकॉल
 * पाथिंग
 * पथ एमटीयू डिस्कवरी
 * स्मर्फ हमला

आरएफसी

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

बाहरी संबंध

 * IANA आईसीएमपीparameters
 * IANA protocol numbers