Internet Control Message Protocol - Internet Control Message Protocol
Komunikační protokol | |
![]() Obecná hlavička pro ICMPv4. | |
Účel | Pomocný protokol pro IPv4 [1] |
---|---|
Vývojáři | DARPA |
Představený | 1981 |
OSI vrstva | Síťová vrstva |
RFC | RFC 792 |
The Internet Control Message Protocol (ICMP) je podpůrná protokol v Sada internetového protokolu. Používá se síťová zařízení, počítaje v to směrovače, posílat chybové zprávy a provozní informace indikující úspěch nebo selhání při komunikaci s jiným IP adresa například chyba je indikována, když požadovaná služba není k dispozici, nebo že a hostitel nebo router nebyl dosažitelný.[2] ICMP se liší od transportní protokoly jako TCP a UDP v tom, že se obvykle nepoužívá k výměně dat mezi systémy, ani jej pravidelně nepoužívají síťové aplikace koncových uživatelů (s výjimkou některých diagnostických nástrojů, jako je ping a traceroute ).
ICMP pro IPv4 je definována v RFC 792.
Sada internetového protokolu |
---|
Aplikační vrstva |
Transportní vrstva |
Internetová vrstva |
Propojit vrstvu |
Technické údaje
ICMP je součástí sady internetového protokolu, jak je definována v RFC 792. Zprávy ICMP se obvykle používají pro diagnostické nebo kontrolní účely nebo se generují v reakci na chyby v IP operace (jak je uvedeno v RFC 1122 ). Chyby ICMP jsou směrovány na zdrojovou adresu IP původního paketu.[2]
Například každé zařízení (například meziprodukt router ) přeposílání IP datagram první dekrementuje čas žít (TTL) pole v hlavičce IP o jednu. Pokud je výsledný TTL 0, paket je zahozen a ICMP překročil čas při přepravě zpráva je odeslána na zdrojovou adresu datagramu.
Mnoho běžně používaných síťových nástrojů je založeno na zprávách ICMP. The traceroute příkaz lze implementovat přenosem IP datagramů se speciálně nastavenými poli záhlaví IP TTL a hledáním překročení času ICMP při přenosu a Cíl nedosažitelný zprávy generované jako odpověď. Související ping nástroj je implementován pomocí ICMP požadavek na ozvěnu a echo odpověď zprávy.
ICMP používá základní podporu IP, jako by šlo o protokol vyšší úrovně, avšak ICMP je ve skutečnosti nedílnou součástí IP. Ačkoli jsou zprávy ICMP obsaženy ve standardních paketech IP, zprávy ICMP se obvykle zpracovávají jako speciální případ, odlišený od běžného zpracování IP. V mnoha případech je nutné zkontrolovat obsah zprávy ICMP a doručit příslušnou chybovou zprávu aplikaci odpovědné za přenos IP paketu, který vyzval k odeslání zprávy ICMP.
ICMP je a síťová vrstva protokol. S pakety ICMP není spojeno žádné číslo portu TCP nebo UDP, protože tato čísla jsou spojena s transportní vrstva výše.[3]
Struktura datagramu
Paket ICMP je zapouzdřen v paketu IPv4.[2] Paket se skládá z hlavičky a datové sekce.
Záhlaví
Záhlaví ICMP začíná po Záhlaví IPv4 a je identifikován Číslo protokolu IP '1'.[4] Všechny pakety ICMP mají 8bajtovou hlavičku a datovou sekci s proměnnou velikostí. První 4 bajty záhlaví mají pevný formát, zatímco poslední 4 bajty závisí na typu / kódu daného paketu ICMP.[2]
Ofsety | Oktet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Oktet | 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 | Typ | Kód | Kontrolní součet | |||||||||||||||||||||||||||||
4 | 32 | Zbytek záhlaví |
- Typ
- Typ ICMP, viz Kontrolní zprávy.
- Kód
- Podtyp ICMP, viz Kontrolní zprávy.
- Kontrolní součet
- Internetový kontrolní součet (RFC 1071 ) pro kontrolu chyb, počítáno z hlavičky ICMP a dat s hodnotou 0 nahrazenou tímto polem.
- Zbytek záhlaví
- Pole se čtyřmi bajty, obsah se liší podle typu a kódu ICMP.
Data
Chybové zprávy ICMP obsahují datovou část, která obsahuje kopii celého záhlaví IPv4 plus alespoň prvních osm bajtů dat z paketu IPv4, který způsobil chybovou zprávu. Maximální délka chybových zpráv ICMP je 576 bajtů.[5] Tato data používá hostitel k přiřazení zprávy k příslušnému procesu. Pokud protokol vyšší úrovně používá čísla portů, předpokládá se, že jsou v prvních osmi bajtech dat původního datagramu.[6]
Proměnná velikost sekce datových paketů ICMP byla využíván. V „Ping smrti ", jsou použity velké nebo fragmentované pakety ICMP útoky odmítnutí služby. Data ICMP lze také použít k vytvoření skryté kanály pro komunikaci. Tyto kanály jsou známé jako ICMP tunely.
Kontrolní zprávy
Řídicí zprávy jsou identifikovány podle hodnoty v typ pole. The kód pole poskytuje další kontextové informace pro zprávu. Některé kontrolní zprávy byly zastaralé od prvního zavedení protokolu.
Typ | Kód | Postavení | Popis |
---|---|---|---|
0 - Echo Reply[6]:14 | 0 | Echo odpověď (zvyklá na ping ) | |
1 a 2 | Nepřiřazeno | Rezervováno | |
3 - Cíl nedosažitelný[6]:4 | 0 | Cílová síť nedosažitelná | |
1 | Cílový hostitel nedosažitelný | ||
2 | Cílový protokol nedosažitelný | ||
3 | Cílový port nedosažitelný | ||
4 | Vyžaduje se fragmentace a Příznak DF soubor | ||
5 | Trasa zdroje se nezdařila | ||
6 | Cílová síť neznámá | ||
7 | Cílový hostitel neznámý | ||
8 | Hostitel zdroje izolován | ||
9 | Síť je administrativně zakázána | ||
10 | Hostitel je administrativně zakázán | ||
11 | Síť nedostupná pro ToS | ||
12 | Hostitel nedosažitelný pro ToS | ||
13 | Administrativně zakázaná komunikace | ||
14 | Porušení hostitelské priority | ||
15 | Platí mezní hodnota priority | ||
4 - Zdroj Quench | 0 | Utlumení zdroje (kontrola přetížení) | |
5 - Přesměrování zprávy | 0 | Přesměrovat datagram pro síť | |
1 | Přesměrovat datagram pro hostitele | ||
2 | Přesměrovat datagram pro ToS & síť | ||
3 | Přesměrovat datagram pro ToS & hostitel | ||
6 | Alternativní adresa hostitele | ||
7 | Nepřiřazeno | Rezervováno | |
8 - Echo Request | 0 | Echo požadavek (zvyklý na ping) | |
9 – Směrovací reklama | 0 | Směrovací reklama | |
10 – Žádost o směrovač | 0 | Objevení / výběr / vyžádání směrovače | |
11 – Čas překročen[6]:6 | 0 | Při přepravě vypršela platnost TTL | |
1 | Byl překročen čas opětovného sestavení fragmentu | ||
12 - Problém s parametrem: Špatná hlavička IP | 0 | Ukazatel označuje chybu | |
1 | Chybí požadovaná možnost | ||
2 | Špatná délka | ||
13 - Časové razítko | 0 | Časové razítko | |
14 - Odpověď na časové razítko | 0 | Odpověď s časovým razítkem | |
15 - Žádost o informace | 0 | Žádost o informace | |
16 - Informační odpověď | 0 | Informační odpověď | |
17 - Žádost o masku adresy | 0 | Žádost o adresu masky | |
18 - Odpověď na masku adresy | 0 | Odpověď na masku adresy | |
19 | Rezervováno | Rezervováno kvůli bezpečnosti | |
20 až 29 | Rezervováno | Rezervováno pro experiment robustnosti | |
30 – Traceroute | 0 | Žádost o informace | |
31 | Chyba převodu datagramu | ||
32 | Přesměrování mobilního hostitele | ||
33 | Where-Are-You (původně určeno pro IPv6 ) | ||
34 | Here-I-Am (původně určen pro IPv6) | ||
35 | Žádost o mobilní registraci | ||
36 | Odpověď na mobilní registraci | ||
37 | Žádost o doménové jméno | ||
38 | Odpověď na název domény | ||
39 | SKIP Algorithm Discovery Protocol, Jednoduchá správa klíčů pro internetový protokol | ||
40 | Photuris „Selhání zabezpečení | ||
41 | Experimentální | ICMP pro experimentální protokoly mobility, jako je Seamoby [RFC4065] | |
42 - Rozšířený požadavek na ozvěnu[9] | 0 | Vyžádejte si Extended Echo (XPing - viz Extended Ping (Xping) ) | |
43 - Extended Echo Reply[9] | 0 | Žádná chyba | |
1 | Poškozený dotaz | ||
2 | Žádné takové rozhraní | ||
3 | Žádná položka v tabulce | ||
4 | Více rozhraní uspokojuje dotazy | ||
44 až 252 | Nepřiřazeno | Rezervováno | |
253 | Experimentální | Experiment 1 ve stylu RFC3692 (RFC 4727 ) | |
254 | Experimentální | Experiment 2 ve stylu RFC3692 (RFC 4727 ) | |
255 | Rezervováno | Rezervováno |
Ukončení zdroje
Zdroj Quench požaduje, aby odesílatel snížil rychlost zpráv odesílaných na router nebo hostitele. Tato zpráva může být generována, pokud router nebo hostitel nemá dostatek místa ve vyrovnávací paměti pro zpracování požadavku, nebo se může objevit, pokud se router nebo hostitelská vyrovnávací paměť blíží svému limitu.
Data jsou odesílána velmi vysokou rychlostí z hostitele nebo z několika hostitelů současně na konkrétní router v síti. Přestože má router možnosti ukládání do vyrovnávací paměti, je ukládání do vyrovnávací paměti omezeno na zadaný rozsah. Směrovač nemůže zařadit do fronty více dat, než je kapacita omezeného vyrovnávacího prostoru. Pokud se tedy fronta zaplní, příchozí data se zahodí, dokud fronta již není plná. Ale protože v síťové vrstvě není žádný mechanismus potvrzení, klient neví, zda data úspěšně dosáhla cíle. Síťová vrstva by proto měla přijmout určitá nápravná opatření, aby se těmto druhům situací vyhnula. Tato opatření se označují jako zdrojové utlumení. V mechanismu utlumení zdroje router zjistí, že rychlost příchozích dat je mnohem rychlejší než rychlost odchozích dat, a pošle klientům zprávu ICMP s informací, že by měli zpomalit rychlost přenosu dat nebo počkat na určité množství čas před pokusem o odeslání dalších dat. Když klient obdrží tuto zprávu, automaticky zpomalí rychlost odchozích dat nebo počká na dostatečné množství času, což routeru umožní vyprázdnit frontu. Zpráva ICMP utišující zdroj tak funguje jako řízení toku v síťové vrstvě.
Vzhledem k tomu, že výzkum naznačil, že „ICMP Source Quench [bylo] neúčinné (a nespravedlivé) protijed na přetížení“,[10] vytváření směrovacích zpráv zdrojových směrovačů bylo v roce 1995 zastaralé RFC 1812. Kromě toho bylo od roku 2012 zastaralé předávání a jakékoli reakce na (akce řízení toku) zprávy o ukončení zdroje RFC 6633.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Typ = 4 | Kód = 0 | Kontrolní součet | |||||||||||||||||||||||||||||
nepoužitý | |||||||||||||||||||||||||||||||
Záhlaví IP a prvních 8 bajtů dat původního datagramu |
Kde:
- Typ musí být nastavena na 4
- Kód musí být nastavena na 0
- IP hlavička a další data používá odesílatel k porovnání odpovědi s přidruženým požadavkem
Přesměrování

Přesměrování požaduje odeslání datových paketů alternativní cestou. ICMP Redirect je mechanismus pro směrovače k přenosu směrovacích informací k hostitelům. Zpráva informuje hostitele o aktualizaci informací o jeho směrování (k odesílání paketů na alternativní trase). Pokud se hostitel pokusí odeslat data prostřednictvím a router (R1) a R1 odesílají data na jiném routeru (R2) a je k dispozici přímá cesta z hostitele do R2 (tj. Hostitel a R2 jsou ve stejném segmentu Ethernetu), poté R1 odešle zprávu s přesměrováním, aby informovala hostitel, že nejlepší trasa pro cíl je přes R2. Hostitel by pak měl odeslat pakety pro cíl přímo do R2. Směrovač stále odešle originál datagram do zamýšleného cíle.[11] Pokud však datagram obsahuje informace o směrování, tato zpráva nebude odeslána, i když je k dispozici lepší trasa. RFC 1122 uvádí, že přesměrování by měla odesílat pouze brány a neměli by být odesíláni hostiteli internetu.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Typ = 5 | Kód | Kontrolní součet | |||||||||||||||||||||||||||||
IP adresa | |||||||||||||||||||||||||||||||
Záhlaví IP a prvních 8 bajtů dat původního datagramu |
Kde:
- Typ musí být nastavena na 5.
- Kód určuje důvod přesměrování, může být jeden z následujících:
Kód Popis 0 Přesměrování pro síť 1 Přesměrování pro hostitele 2 Přesměrování pro typ služby a síť 3 Přesměrování pro typ služby a hostitele
- IP adresa je 32bitová adresa brány, na kterou by mělo být odesláno přesměrování.
- IP hlavička a jsou zahrnuta další data, která umožňují hostiteli porovnat odpověď s požadavkem, který způsobil odpověď na přesměrování.
Čas byl překročen
Čas překročen je generován a brána informovat zdroj vyřazených datagram v důsledku čas žít pole dosahující nuly. Zpráva o překročení času může být také odeslána hostitelem, pokud se jí nepodaří znovu sestavit roztříštěný datagram v jeho časovém limitu.
Zprávy o překročení času používá traceroute nástroj pro identifikaci bran na cestě mezi dvěma hostiteli.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Typ = 11 | Kód | Kontrolní součet | |||||||||||||||||||||||||||||
nepoužitý | |||||||||||||||||||||||||||||||
Záhlaví IP a prvních 8 bajtů dat původního datagramu |
Kde:
- Typ musí být nastaveno na 11
- Kód určuje důvod zprávy o překročení času, obsahuje následující:
Kód Popis 0 Během přepravy byla překročena doba životnosti. 1 Byl překročen čas opětovného sestavení fragmentu.
- IP hlavička a prvních 64 bitů originálu užitečné zatížení jsou používány zdrojovým hostitelem k přizpůsobení zprávy o překročení času vyřazenému datagramu. Pro protokoly vyšší úrovně, jako je UDP a TCP 64bitové užitečné zatížení bude zahrnovat zdrojové a cílové porty vyřazeného paketu.
Časové razítko
Časové razítko slouží k synchronizaci času. Původní časové razítko je nastaven na čas (v milisekundách od půlnoci), kdy se odesílatel naposledy dotkl paketu. Časová razítka pro příjem a vysílání se nepoužívají.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Typ = 13 | Kód = 0 | Kontrolní součet | |||||||||||||||||||||||||||||
Identifikátor | Pořadové číslo | ||||||||||||||||||||||||||||||
Původní časové razítko | |||||||||||||||||||||||||||||||
Získejte časové razítko | |||||||||||||||||||||||||||||||
Přenést časové razítko |
Kde:
- Typ musí být nastaveno na 13
- Kód musí být nastavena na 0
- Identifikátor a Pořadové číslo může být použit klientem k přizpůsobení odpověď časového razítka s požadavkem na časové razítko.
- Původní časové razítko je počet milisekund od půlnoci Světový čas (UT). Pokud není k dispozici reference UT, lze nastavit nejvýznamnější bit pro indikaci nestandardní časové hodnoty.
Odpověď s časovým razítkem
Odpověď na časové razítko odpovědi na a Časové razítko zpráva. Skládá se z původního časového razítka zaslaného odesílatelem Časové razítko stejně jako časové razítko příjmu označující, kdy Časové razítko byla přijata a časová značka přenosu indikující, kdy Odpověď s časovým razítkem byl odeslán.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Typ = 14 | Kód = 0 | Kontrolní součet | |||||||||||||||||||||||||||||
Identifikátor | Pořadové číslo | ||||||||||||||||||||||||||||||
Původní časové razítko | |||||||||||||||||||||||||||||||
Získejte časové razítko | |||||||||||||||||||||||||||||||
Přenést časové razítko |
Kde:
- Typ musí být nastaveno na 14
- Kód musí být nastavena na 0
- Identifikátor a Pořadové číslo může být klientem použit k porovnání odpovědi s požadavkem, který způsobil odpověď.
- Původní časové razítko je čas, kdy se odesílatel naposledy dotkl zprávy před odesláním.
- Získejte časové razítko je čas, kdy se ho ozvěna poprvé dotkla při přijetí.
- Přenést časové razítko je čas, kdy se ozvěna naposledy dotkla zprávy při jejím odeslání.
- Všechna časová razítka jsou od půlnoci UT v jednotkách milisekund. Pokud čas není k dispozici v milisekundách nebo jej nelze poskytnout s ohledem na půlnoční UT, lze do časového razítka vložit libovolný čas za předpokladu, že je také nastaven bit vyššího řádu časového razítka, který označuje tuto nestandardní hodnotu.
Žádost o masku adresy
Žádost o masku adresy je obvykle odesílána a hostitel do a router za účelem získání příslušného maska podsítě.
Příjemci by na tuto zprávu měli odpovědět pomocí Odpověď na masku adresy zpráva.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Typ = 17 | Kód = 0 | Kontrolní součet | |||||||||||||||||||||||||||||
Identifikátor | Pořadové číslo | ||||||||||||||||||||||||||||||
Maska adresy |
Kde:
- Typ musí být nastaveno na 17
- Kód musí být nastavena na 0
- Maska adresy lze nastavit na 0
ICMP Address Mask Request lze použít jako součást průzkumného útoku ke shromažďování informací v cílové síti, proto je ICMP Address Mask Reply ve výchozím nastavení v systému Cisco IOS zakázán.[12]
Odpověď na masku adresy
Odpověď na masku adresy se používá k odpovědi na zprávu s požadavkem na masku adresy pomocí příslušné masky podsítě.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Typ = 18 | Kód = 0 | Kontrolní součet | |||||||||||||||||||||||||||||
Identifikátor | Pořadové číslo | ||||||||||||||||||||||||||||||
Maska adresy |
Kde:
- Typ musí být nastaveno na 18
- Kód musí být nastavena na 0
- Maska adresy by měla být nastavena na masku podsítě
Cíl nedosažitelný
Cíl nedosažitelný je generován hostitelem nebo jeho příchozí bránou[6] informovat klienta, že cíl je z nějakého důvodu nedosažitelný. Důvody pro tuto zprávu mohou zahrnovat: fyzické připojení k hostiteli neexistuje (vzdálenost je nekonečná); uvedený protokol nebo port není aktivní; data musí být fragmentovaná, ale je zapnut příznak „nefragmentovat“. Nedostupné porty TCP zejména reagují pomocí TCP RST spíše než a cíl nedosažitelný typ 3, jak by se dalo očekávat. Cíl nedosažitelný nikdy není hlášen pro Multicast IP přenosy.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Typ = 3 | Kód | Kontrolní součet | |||||||||||||||||||||||||||||
nepoužitý | Next-hop MTU | ||||||||||||||||||||||||||||||
Záhlaví IP a prvních 8 bajtů dat původního datagramu |
Kde:
- Typ pole (bity 0-7) musí být nastaveno na 3
- Kód pole (bity 8-15) se používá k určení typu chyby a může to být kterékoli z následujících:
Kód Popis 0 Chyba nedostupnosti sítě. 1 Chyba nedosažitelnosti hostitele. 2 Nedosažitelná chyba protokolu (určený přenosový protokol není podporován). 3 Chyba nedosažitelnosti portu (určený protokol není schopen informovat hostitele o příchozí zprávě). 4 Datagram je příliš velký. Je nutná fragmentace paketů, ale je zapnut příznak „nefragmentovat“ (DF). 5 Chyba zdrojové trasy. 6 Neznámá chyba cílové sítě. 7 Neznámá chyba cílového hostitele. 8 Izolovaná chyba hostitele zdroje. 9 Cílová síť je administrativně zakázána. 10 Cílový hostitel je administrativně zakázán. 11 Síť je pro Typ služby nedostupná. 12 Hostitel je pro Typ služby nedostupný. 13 Komunikace je administrativně zakázána (administrativní filtrování zabraňuje přeposílání paketů). 14 Porušení priority hostitele (označuje, že požadovaná priorita není povolena pro kombinaci hostitele nebo sítě a portu). 15 Platí omezení priority (priorita datagramu je pod úrovní nastavenou správci sítě).
- Next-hop MTU pole (bity 48-63) obsahuje MTU sítě next-hop, pokud dojde k chybě kódu 4.
- IP hlavička a jsou zahrnuta další data, která klientovi umožní porovnat odpověď s požadavkem, který způsobil, že cíl nedosáhne odpovědi.
Viz také
Reference
- ^ F. Baker (červen 1995). Baker, F (ed.). „RFC 1812, Požadavky na směrovače IP verze 4“: 52. doi:10.17487 / RFC1812. Citovat deník vyžaduje
| deník =
(Pomoc) - ^ A b C d Forouzan, Behrouz A. (2007). Datová komunikace a sítě (Čtvrté vydání). Boston: McGraw-Hill. str.621 –630. ISBN 978-0-07-296775-3.
- ^ „Model OSI definuje sedm vrstev a vysvětluje funkce“. Podpora společnosti Microsoft. Citováno 2014-12-28.
- ^ "Čísla protokolu". Autorita pro internetová přidělená čísla. Citováno 2011-06-23.
- ^ Požadavky na směrovače IP verze 4. doi:10.17487 / RFC1812. RFC 1812.
- ^ A b C d E F G h i j k Postel, J. (září 1981). Internet Control Message Protocol. IETF. doi:10.17487 / RFC0792. RFC 792.
- ^ „Parametry IANA ICMP“. Iana.org. 21. 09. 2012. Citováno 2013-01-07.
- ^ Kurose, J.F .; Ross, K.W. (2006). Počítačové sítě: přístup shora dolů. Světová studentská série. Addison-Wesley. ISBN 9780321418494.
- ^ A b SONDA: Nástroj pro snímání rozhraní. doi:10.17487 / RFC8335. RFC 8335.
- ^ RFC 6633
- ^ „Kdy se odesílají přesměrování ICMP?“. Systémy Cisco. 2008-06-28. Citováno 2013-08-15.
- ^ „Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and Services, Release 12.3 - IP Addressing and Services Commands: ip mask-response through ip web-cache“. Systémy Cisco. Archivovány od originál dne 02.01.2013. Citováno 2013-01-07.
RFC
- RFC 792, Internet Control Message Protocol
- RFC 950, Standardní internetový postup podsítě
- RFC 1016, Něco, co by hostitel mohl udělat s Quench zdroje: Zdroj Quench představil zpoždění (SQuID)
- RFC 1122, Požadavky na hostitele internetu - komunikační vrstvy
- RFC 1716, Směrem k požadavkům na směrovače IP
- RFC 1812, Požadavky na směrovače IP verze 4
externí odkazy
- Parametry IMPA ICMP
- Čísla protokolu IANA
- Vysvětlení chování ICMP Redirect na Wayback Machine (archivováno 2015-01-10)