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

From Vigyanwiki
Revision as of 00:17, 23 May 2023 by alpha>Shubham
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’