Počítačové sítě \(\Psi\): Internet Control Message Protocol — ICMP

Hlavička ICMP začíná za hlavičkou IPv4 a je identifikována číslem protokolu IP '1'. Všechny ICMP pakety mají osmibajtovou hlavičku a datovou sekci proměnné velikosti. První 4 bajty hlavičky mají pevný formát, zatímco poslední 4 bajty závisí na typu/kódu daného ICMP paketu.

Chybové zprávy ICMP obsahují datovou část, která obsahuje kopii celé hlavičky IPv4 plus alespoň prvních osm bajtů dat z paketu IPv4, který chybovou zprávu způsobil. Délka chybových zpráv ICMP by neměla přesáhnout 576 bajtů. 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 bytech dat původního datagramu.

Byla využita proměnná velikost datové části ICMP paketů. V "Ping of death" jsou velké nebo fragmentované ICMP pakety používány pro útoky denial-of-service. Data ICMP lze také použít k vytvoření skrytých kanálů pro komunikaci. Tyto kanály jsou známé jako ICMP tunely.

Ostatní datagramy jsou používány spíše vzácně, někdy je používání ICMP znemožněno špatným nastavením firewallu.

Přesměrování požaduje odeslání datových paketů alternativní cestou. ICMP Redirect je mechanismus pro směrovače, který přenáší informace o směrování hostitelům. Zpráva informuje hostitele, aby aktualizoval své směrovací informace (k odeslání paketů alternativní cestou). Pokud se hostitel pokusí odeslat data přes router (R1) a R1 odešle data na jiný router (R2) a je k dispozici přímá cesta z hostitele do R2 (to znamená, že hostitel a R2 jsou ve stejné podsíti), pak R1 odešle přesměrovací zprávu, aby informoval hostitele, že nejlepší cesta k cíli je přes R2. Hostitel by pak měl změnit informace o své trase a odeslat pakety pro tento cíl přímo do R2. Router stále odešle původní datagram do zamýšleného cíle. Pokud však datagram obsahuje informace o směrování, tato zpráva nebude odeslána, i když je k dispozici lepší cesta. RFC 1122 uvádí, že přesměrování by měly být odesílány pouze bránami a neměly by být odesílány strojům v Internetu.

Překročení času je generováno bránou, aby informovalo zdroj o vyřazeném datagramu, protože TTL dosáhl nuly. Zprávu o překročení času může také odeslat hostitel, pokud se mu nepodaří znovu sestavit fragmentovaný datagram ve svém časovém limitu.

Zprávy o překročení času používá obslužný program traceroute k identifikaci bran na cestě mezi dvěma hostiteli.

Typ musí být nastaven na 11.

Hlavička IP a prvních 64 bitů původního paketu se použije hostitel, co dostal ICMP zprávu, aby našel u ebe vyřezený datagram. U protokolů vyšší úrovně TCP a UDP tam najde sdrojový a cílový port.

Žádost o čas a odpověď s časem se používá k synchronizaci času na zařízeních, které nemají hodiny reálného času (s baterií), a také nemají požnost použít protokol aplikační vrstvy NTP. Jsou to všelijaké mini krabičky. Krabička pošle ICMP zprávu Timestamp stroji, který má sychronizované hodiny a v odpověď dostane ICMP zprávu Timestmp Reply s aktuálním časem. Tak může nastavit svoje vlastní hodiny na přibližně synchronní čas. Není to tak přesné jeko NTP protokol, ale pro většinu zařízení to dostačuje.

Timestamp se používá pro synchronizaci času. Původní časové razítko je nastaveno na čas (v milisekundách od půlnoci), kdy se odesílatel naposledy dotkl paketu. Časová razítka příjmu a vysílání se nepoužívají.

Typ musí byýt nastaven an 13.

Kód musí být nastaven na 0

Identifikátor a sekvenční číslo se používá k porovnání s odpovědí Timestamp Reply.

Timestamp reply je odpověď na zprávu Timestamp. Skládá se z původního časového razítka zaslaného odesílatelem časového razítka, jakož i časového razítka příjmu indikujícího, kdy bylo časové razítko přijato, a časového razítka vysílání indikujícího, kdy byla odeslána odpověď časového razítka.

Všechna časová razítka jsou v jednotkách milisekund od půlnoci UT. Pokud čas není k dispozici v milisekundách nebo jej nelze poskytnout s ohledem na půlnoční UT, pak lze do časové značky vložit libovolný čas za předpokladu, že bit vysokého řádu časové značky je také nastaven tak, aby indikoval tuto nestandardní hodnotu.

Použití zpráv Timestamp a Timestamp Reply k synchronizaci hodin internetových uzlů bylo z velké části nahrazeno protokolem Network Time Protocol (NTP) a Precision Time Protocol založeným na UDP, které jsou přesnější.

Požadavek na masku adresy je obvykle odesílán hostitelem směrovači, aby získal vhodnou masku podsítě.

Příjemci by měli na tuto zprávu odpovědět zprávou s odpovědí masky adresy.

Kde:

ICMP Address Mask Request může být použit 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í na Cisco IOS zakázáno.

Odpověď masky sítě se používá k odpovědi na zprávu s žádostí o masku sítě s příslušnou maskou podsítě.

Kde:

Cíl nedostupný je generován hostitelem nebo jeho příchozí bránou, aby informoval 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 fragmentována, ale je zapnutý příznak „nefragmentovat“. Nedosažitelné porty TCP reagují zejména pomocí TCP RST spíše než nedosažitelný cíl typu 3, jak by se dalo očekávat. Nedosažitelný cíl není nikdy hlášen pro přenosy vícesměrového vysílání (multicast) IP.

Kde:

Source Quench požaduje, aby odesílatel snížil rychlost zpráv odesílaných směrovači nebo hostiteli. Tato zpráva může být generována, pokud směrovač nebo hostitel nemá dostatečný prostor ve vyrovnávací paměti pro zpracování požadavku, nebo se může objevit, pokud se vyrovnávací paměť směrovače nebo hostitele blíží svému limitu.

Data jsou odesílána velmi vysokou rychlostí z hostitele nebo z několika hostitelů současně do konkrétního směrovače v síti. Přestože má směrovač možnosti ukládání do vyrovnávací paměti, ukládání do vyrovnávací paměti je omezeno na specifikovaný rozsah. Router nemůže zařadit do fronty více dat, než je kapacita omezeného vyrovnávací paměti. Pokud se tedy fronta zaplní, příchozí data se zahazují, dokud fronta již není plná. Ale protože v síťové vrstvě není přítomen žádný potvrzovací mechanismus, klient neví, zda data úspěšně dosáhla cíle. Síťová vrstva by proto měla přijmout některá nápravná opatření, aby se těmto situacím vyhnula. Tato opatření se označují jako source quench (zdrojové zhášení).

V mechanismu zdrojového zhášení router zjistí, že rychlost příchozích dat je mnohem vyšší než rychlost odchozích dat, a pošle klientům zprávu ICMP, která je informuje, že by měli zpomalit rychlost přenosu dat nebo počkat určitý čas pokusem o odeslání dalších dat. Když klient obdrží tuto zprávu, automaticky zpomalí rychlost odchozích dat nebo počká dostatečně dlouhou dobu, což routeru umožní vyprázdnit frontu. Zpráva ICMP o zhášení zdroje tedy působí jako řízení toku v síťové vrstvě.

Protože výzkum naznačoval, že „ICMP Source Quench [bylo] neúčinným (a nespravedlivým) lékem na přetížení“, vytváření zdrojových zpráv zhášení pomocí směrovačů bylo v roce 1995 odmítnuto RFC 1812. Kromě toho přeposílání a jakýkoli druh reakce na (akce řízení toku) zprávy o zhášení zdroje byly od roku 2012 podle RFC 6633 zastaralé.