Protokol ICMP (Internet Control Message)

Protokol ICMP je služobný protokol, ktorý je súčasťo/rozšírenie IP-protokolu, prenáša chybové, riadiace a informačné správy. . Protokol ICMP slúži k signalizácii mimoriadnych udalostí v sieťach postavených na IP-protokole. Svoje dátové pakety balí do IP-protokolu, tj. pokiaľ budeme prenášané  datagramy prehliadať, tak v nich za linkovým záhlavím nájdeme záhlavie IP-protokolu nasledované záhlavím ICMP paketu.


            Obrázok - Štruktúra ICMP-paketu

Echo

Je jednoduchý nástroj protokolu ICMP, ktorým môžeme testovať dosiahnuteľnosť jednotlivých uzlov v Internete. Žiadateľ vysiela ICMP-paket “Žiadosť o echo” a cieľový uzol je povinný odpovedať ICMP-paketom “ Echo”. Všetky operačné systémy podporujúce protokol TCP/IP obsahujú program ping, ktorým používateľ môže na cieľový uzol odoslať žiadosť o echo. Program ping potom zobrazuje odpoveď. 
Napr. vo Windows NT chceme zistiť dostupnosť uzla 194.149.105.18: 

C:\>ping 194.149.105.18 
Pinging 194.149.105.18 with 32 bytes of data: 
Reply from 194.149.105.18: bytes=32 time<10ms TTL=63 
Reply from 194.149.105.18: bytes=32 time<10ms TTL=63 
Reply from 194.149.105.18: bytes=32 time<10ms TTL=63 
Reply from 194.149.105.18: bytes=32 time<10ms TTL=63 

Systém odoslal štyrikrát žiadosť o echo. Odpoveď mala 32 bajtov dlhú dátovú časť a získal ju do 10 ms. V odpovedi mala položka TTL hodnotu 63.

Nedoručiteľný IP-datagram

Ak nemôže byť IP-datagram predaný ďalej smerom k adresátovi, potom je zahodený a odosielateľ je protokolom ICMP o tom upovedomený správou “Nedoručiteľný IP-datagram”.

Zníž rýchlosť odosielania

Ak je sieť medzi odosielateľom a príjemcom v niektorom mieste preťažená, tak smerovač, ktorý nie je schopný predávať ďalej všetky IP-datagramy signalizuje odosielateľovi “Zníž rýchlosť odosielania”. Odosielateľ potom v prípade, že používa protokol TCP znižuje rýchlosť odosielania TCP segmentov. V prípade protokolu UDP sa správy “Zníž rýchlosť odosielania” ignorujú.

Zmeň smerovanie (Redirect)

Pomocou tohto ICMP-paketu sa vykonávajú dynamické zmeny v smerovacej tabuľke. 


        Obrázok - Redirect

Na obr. smerovač 1 má IP-datagram smerovať na to isté sieťové rozhranie (interface), ktorým IP-datagram prišiel. Potom ho síce presmeruje, avšak upozorní adresáta ICMP-paketom, aby si zmenil vlastnú smerovaciu tabuľku a takúto službu už viacej nežiadal.
Táto situácia najčastejšie nastáva vtedy, keď máme na lokálnej sieti viacej smerovačov, ale jednotlivé počítače na LAN majú po svojom štarte iba položku default ukazujúcu na jeden zo smerovačov.

Žiadosť o smerovanie

Jedná sa o pomerne novú záležitosť, pomocou ktorej nemusíme do smerovacej tabuľky počítačov na LAN ručne konfigurovať vôbec žiadnu položku default. Počítač po svojom štarte vyšle obežníkom “Žiadosť o smerovanie” a smerovač mu odpovie ICMP-paketom “Odpoveď na žiadosť o smerovanie”, ktorá obsahuje: počet adries smerovača, dĺžku adresy a dvojice IP-adresa a preferencia. Z odpovede môže počítač automaticky vygenerovať položku default. 

Čím má preferencia vyššiu hodnotu, tým je IP-adresa viac preferovaná. Hodnota preferencia 8000000016 signalizuje, že táto adresa sa má zo smerovacej tabuľky vypustiť. Smerovače odpovedajú na žiadosť o smerovanie, ale v náhodnom intervale medzi 450 a 600 sekundami by mali obežníkom sami do lokálnej siete generovať ICMP-pakety “odpoveď na žiadosť o smerovanie”. Položka “dĺžka života” udáva čas, počas ktorého je informácia platná.

Čas vypršal (tíme exceeded)

Tento typ zahŕňa dva veľmi odlišné prípady. Pre kód=0 signalizuje, že položka TTL by bola na smerovači znížená na nulu, t.j. je podozrenie, že IP-datagram v Internete zablúdil, preto bude zlikvidovaný. Pre kód=1 signalizuje, že počítač adresáta nieje schopný v danom čase zostaviť z fragmentov celý IP-datagram.

ICMP-paket čas vypršal kód=0 využíva ku svojej činnosti program traceroute (UNIX) i program tracert (Microsoft). Program tracert je jednoduchší. Tento program odosiela zo zdrojového počítača na cieľový uzol ICMP-pakety “Žiadosť o echo”, ale v prvom pakete nastaví položku TTL na jednotku. Prvý smerovač na ceste paket zahodí a vráti ICMP-paket “Čas vypršal”, pretože musí zmenšiť TTL aspoň o jednotku, ale týmto zmenšením už dostane nulu. Zdrojový počítač tak od prvého smerovača na ceste dostane v IP-datagrame ICMP-paket “čas vypršal”. Z položky adresa odosielateľa v IP-záhlaví možno zistiť adresu prvého smerovača na ceste. Zmeria sa časový interval od odoslania po príjem paketu a zistí sa tak čas prechádzky paketu od odosielateľa k príjemcovi a späť. Toto sa opakuje trikrát a všetky tri časy program zobrazí. Na koniec riadku zobrazí meno smerovača a v hranatých zátvorkách jeho IP-adresu. Meno získa z reverzného prekladu v DNS.


            Obrázok - príklad traceroute

Ak nezíska v časovom intervale odpoveď, zobrazí namiesto času hviezdičku (*). Potom všetko opakuje s hodnotou TTL=2, atď.. Svoju činnosť ukončí ak od cieľového uzla obdrží ICMP-správu “Echo”. K ukončeniu môže pochopiteľne tiež dôjsť aj vtedy, keď nejaký smerovač nepozná cestu k cieľovému počítaču, potom zdrojovému počítaču pošle správu “nedoručiteľný IP-datagram”. 

C:\>tracert kula.usp.ac.fj 

Tracing route to kula.usp.ac.fj [144.120.8.11] over a maximum of 30 hops: 
1 <10 ms 10 ms <10 ms cbuN002e00.pvt.net [194.149.104.193] 
2 10 ms 10 ms 10 ms phucbu.pvt.net [194.149.96.13] 
3 601 ms 561 ms 641 ms 951.Hssi5-0.GW1.NYC2.ALTER.NET [157.130.0.117] 
4 591 ms 571 ms 571 ms 143.ATM2-0.XR1.EWR1.ALTER.NET [146.188.177.50] 
5 591 ms 581 ms 571 ms 193.ATM1-0-0.BR1.EWR1.ALTER.NET [146.188.176.49]
6 400 ms 381 ms 360 ms sl-pen-11-h3.sprintlink.net [137.39.44.130] 
7 811 ms 591 ms 661 ms sl-bb10-pen-0-1.sprintlink.net [144.232.5.5] 
8 500 ms 651 ms 731 ms sl-bb22-stk-6-0.sprintlink.net [144.232.8.178] 
9 871 ms 831 ms 932 ms sl-bb23-stk-8-0.sprintlink.net [144.232.4.110] 
10 691 ms 650 ms 611 ms sl-bb10-sj-6-0.sprintlink.net [144.232.8.193] 
11 811 ms 771 ms 771 ms sl-gw2-sj-0-0-155M.sprintlink.net [144.232.3.38] 
12 641 ms 651 ms 641 ms sl-cais-1.sprintlink.net [144.228.111.18] 
13 801 ms 811 ms 861 ms hssi9-0-0.hk-T3.hkt.net [202.84.128.253] 
14 801 ms * 811 ms f5-0.yck06.hkt.net [205.252.130.201] 
15 821 ms 831 ms 822 ms a6-0.tmh08.hkt.net [205.252.130.81] 
16 1402 ms 1342 ms 1362 ms s4-3b.tmh08.hkt.net [205.252.128.158] 
17 1381 ms 1362 ms 1352 ms 202.84.251.6 
18 1362 ms 1362 ms 1352 ms 202.62.120.6 
19 1422 ms 1372 ms 1392 ms 202.62.125.134 
20 1412 ms 1382 ms 1412 ms kula.usp.ac.fj [144.120.8.11] 
Trace complete. 

Program traceroute pracuje na podobnom princípe, ale neodosiela ICMP-pakety “Echo request”, ale generuje protokolom UDP datagramy (UDP-port je možné modifikovať parametrom –p). Ak je na ceste k cieľovému počítaču použitá filtrácia na smerovači, tak vhodnou voľbou čísla UDP-portu možno často nájsť “dieru” vo filtri a objaviť cestu až k cieľovému počítaču. Dobrým typom pre takýto prípad je číslo portu 53 (-p 53), ktorý používa DNS. 

$ /usr/sbin/traceroute -p 20000 libor.pvt.net 
traceroute to libor.pvt.net (194.149.104.198), 30 hops max, 40 byte packets 
1 cbuN003f00.pvt.net (194.149.105.17) 1 ms 1 ms 1 ms 
2 Libor.pvt.net (194.149.104.198) 1 ms 1 ms 1 ms 

Cieľový počítač spravidla odpovie ICMP-paketom “Port unreacheble” (typ=3, kód=3). Okrem času a hviezdičky program traceroute ešte môže vypísať !H (nedostupný uzol), !N (nedostupná sieť), !A (sieť administratívne uzavretá), či !S (explicitné smerovanie nefunkčné).

Žiadosť o masku

Týmto ICMP-paketom môže bezdisková stanica žiadať o masku svojej siete potom, čo protokolom RARP obdržala svoju IP-adresu. Tento mechanizmus je praxi dnes už málo bežný. Stanica môže získať masku svojej siete protokolom BOOTP, ktorým získa i ďalšie informácie. Avšak aj protokol BOOTP je dnes vytlačovaný protokolom DHCP, ktorý je komplexnejší, tj. poskytuje viac informácií. Protokoly BOOTP a DHCP sú aplikačné protokoly.

Časová synchronizácia

Týmto ICMP-paketom sa žiada cieľový počítač o čas. Mechanizmus je znázornený na obr.1.1-6. Zdrojový počítač do ICMP-paketu “Požiadavka na časovú synchronizáciu (timestamp request)” vyplní čas odoslania žiadosti. Cieľový počítač vyplní do svojej odpovede “Odpoveď na časovú synchronizáciu (timestamp reply)” dva časy:

Zdrojový počítač si zistí čas prijatia odpovede (ten sa pochopiteľne neprepravuje v žiadnom ICMP-pakete). Odpočítaním času odoslania požiadavky od času prijatia odpovede sa získa čas prechádzky od zdrojového počítača k cieľovému a späť (anglicky Round Trip Time – RTT).

Typy zpráv :

Echo - správa pre cieľovú adresu - žiadosť o echo, cieľ odpovie echom - program ping.

Nedoručiteľný IP packet

Zníž rýchlosť vysielania - vysiela router ak nestačí posielať packety ďalej.

Zmeň smerovanie (redirect) - router upozorní že smerovanie cez neho nie je vhodné.

Čas vypršal (time exceeded) - TTL = 0 - packet zablúdil a bude zlikvidovaný, alebo počítač adresáta nie je schopný v definovanom čase zostaviť z fragmentov celý IP packet. Toto využíva program tracert - zistenie adries routrov na ceste packetu.

Časová synchronizácia - požiadavka na časovú synchronizáciu (timestamp request), odpoveď. RTT - round trip time = čas od vyslania požiadavky po návrat dát.
8
  16
32 bits
Type
  Code
Checksum
Identifier
Sequence number
Address mask
ICMP hlavička

ICMP TYPE NUMBERS
Typ Popis Referencia
0 Echo Reply [RFC792]
1 Unassigned [JBP]
2 Unassigned [JBP]
3 Destination Unreachable
0 Net unreachable.
1 Host unreachable.
2 Protocol unreachable.
3 Port unreachable.
4 Fragmentation needed and DF set.
5 Source route failed
6 Destination Network Unknown
7 Destination Host Unknown
8 Source Host Isolated
9 Communication with Destination Network is Administratively Prohibited
10 Communication with Destination Host is Administratively Prohibited
11 Destination Network Unreachable for Type of Service
12 Destination Host Unreachable for Type of Service
13 Communication Administratively Prohibited
14 Host Precedence Violation
15 Precedence cutoff in effect
[RFC792]
4 Source Quench
0 No Code
[RFC792]
5 Redirect
0 Redirect datagrams for the network.
1 Redirect datagrams for the host.
2 Redirect datagrams for the type of service and network.
3 Redirect datagrams for the type of service and host.
[RFC792]
6 Alternate Host Address
0 Alternate Address for Host
[JBP]
7 Unassigned [JBP]
8 Echo
0 No Code
[RFC792]
9 Router Advertisement
0 Normal router advertisement
16 Does not route common traffic
[RFC1256]
10 Router Solicitation
0 No Code
[RFC1256]
11 Time Exceeded
0 Time to live exceeded in transit.
1 Fragment reassemble time exceeded.
[RFC792]
12 Parameter Problem
0 Pointer indicates the error
1 Missing a Required Option
2 Bad Length
[RFC792]
13 Timestamp
0 No Code
[RFC792]
14 Timestamp Reply
0 No Code
[RFC792]
15 Information Request
0 No Code
[RFC792]
16 Information Reply
0 No Code
[RFC792]
17 Address Mask Request
0 No Code
[RFC950]
18 Address Mask Reply
0 No Code
[RFC950]
19 Reserved (for Security) [Solo]
20-29 Reserved (for Robustness Experiment) [ZSu]
30 Traceroute [RFC1393]
31 Datagram Conversion Error [RFC1475]
32 Mobile Host Redirect [David Johnson]
33 IPv6 Where-Are-You [Bill Simpson]
34 IPv6 I-Am-Here [Bill Simpson]
35 Mobile Registration Request [Bill Simpson]
36 Mobile Registration Reply [Bill Simpson]
37 Domain Name Request [RFC1788]
38 Domain Name Reply [RFC1788]
39 SKIP [Markson]
40 Photuris
0 Bad SPI
1 Authentication Failed
2 Decompression Failed
3 Decryption Failed
4 Need Authentication
5 Need Authorization
[RFC2521]
41 ICMP messages utilized by experimental mobility protocols such as Seamoby [RFC-ietf-seamoby-iana-02.txt]
42-255 Reserved [JBP]



REFERENCES
RFC 792 Postel, J., "Internet Control Message Protocol", STD 5, USC/Information Sciences Institute, September 1981.

RFC 950 Mogul, J., and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, Stanford, USC/Information Sciences Institute, August 1985.

RFC 1108 Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.

RFC 1256 Deering, S., Editor, "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991.

RFC 1393 Malkin, G., "Traceroute Using an IP Option", RFC 1393, Xylogics, Inc., January 1993.

RFC 1475 Ullmann, R., "TP/IX: The Next Internet", RFC 1475, Process Software Corporation, June 1993.

RFC 1788 W. Simpson, "ICMP Domain Name Messages", RFC 1788, April 1995.

RFC 1812 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, Cisco Systems, June 1995.

RFC 2002 C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 1996.

RFC 2521 P. Karn and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999.

[RFC-ietf-seamoby-iana-02.txt]
J. Kempf, "Instructions for Seamoby and Experimental Mobility Protocol IANA", RFC XXXX, Month Year.