Jak już wiemy oprogramowanie Internet Protocol realizuje zawodne przenoszenie pakietów bez użycia połączenia za pomocą przekazywania datagramów w routerach.
Datagram wędruje od nadawcy przez różne sieci i routery aż do końcowego odbiorcy.
Jeżeli router nie potrafi ani wyznaczyć trasy ani dostarczyć datagramu, albo gdy wykrywa sytuację mającą wpływ na możliwość dostarczenia datagramu (np. przeciążenie sieci, wyłączenie maszyny docelowej, wyczerpanie się licznika czasu życia datagramu) to musi poinformować pierwotnego nadawcę, aby podjął działania w celu uniknięcia skutków tej sytuacji.
Protokół komunikatów kontrolnych internetu ICMP (ang. Internet Control Message Protocol) powstał aby umożliwić routerom oznajmianie o błędach oraz udostępnianie informacji o niespodziewanych sytuacjach.
Protokół ICMP jest traktowany jako wymagana część IP i musi być realizowany przez każdą implementację IP.
Podobnie jak ruch innego rodzaju komunikaty ICMP podróżują w intersieci w części w częściach datagramów IP przeznaczonych na dane. Jednak odbiorcą końcowym komunikat ICMP nie jest ani program użytkowy, ani użytkownik, ale oprogramowanie IP na tej maszynie. Przychodzący komunikat błędu ICMP jest obsługiwany przez moduł oprogramowania ICMP. Oczywiście gdy ICMP zorientuje się, że problem spowodował dany protokół wyższego rzędu lub program użytkowy, przekaże informacje do odpowiedniego modułu.
Chociaż protokół ICMP powstał, aby umożliwić routerom wysyłanie komunikatów to każda maszyna może wysyłać komunikaty ICMP do dowolnej innej.
Z technicznego punktu widzenia ICMP jest mechanizmem powiadamiania o błędach. Udostępnia on routerom, które rozpoznają błąd, sposób powiadomienia o nim nadawcy, którego błąd dotyczy. Chociaż w specyfikacji protokołu są określone zamierzone sposoby korzystania z ICMP i sugestie na temat tych działań, które mogą być podejmowane w odpowiedzi na komunikaty o błędach, ICMP nie dla każdego możliwego błędu wyszczególnia działania, jakie mają być zapoczątkowane.
Tak więc gdy datagram powoduje błąd, ICMP może jedynie powiadomić pierwotnego nadawcę o przyczynie. Nadawca musi otrzymaną informację przekazać danemu programowi użytkownika, albo podjąć inne działanie mające na celu uporanie się z tym problemem.
Każdy komunikat ICMP ma własny format, ale wszystkie zaczynają się trzema takimi samymi polami:
8-bitowe pole TYP komunikatu identyfikuje komunikat,
8-bitowe pole KOD daje dalsze informacje na temat rodzaju komunikatu,
Pole SUMA KONTROLNA (obliczane podobnie jak suma IP, ale suma kontrolna ICMP odnosi się tylko do komunikatu ICMP).

Oprócz tego komunikaty ICMP oznajmiające o błędach zawsze zawierają nagłówek i pierwsze 64 bity danych datagramu z którym były problemy.
Aby komunikaty ICMP mogły zostać dostarczone wymagają dwóch poziomów kapsułkowania. Każdy komunikat ICMP podróżuje przez intersieć w części datagramu IP przeznaczonej na dane, a ten jak wiemy przemieszcza się przez sieć fizyczną w części dla danych ramki.

Trasy datagramów przenoszących komunikaty ICMP są wyznaczane dokładnie tak, jak dla datagramów przenoszących informacje użytkowników - nie mają one żadnych dodatkowych priorytetów czy zabezpieczeń. W efekcie i same komunikaty o błędach mogą zostać zagubione albo zniszczone. Co więcej w przeciążonej sieci komunikat o błędzie może spowodować dodatkowe przeciążenie. Zrobiono więc wyjątek w procedurach obsługi błędów: komunikaty o błędach nie są tworzone w przypadku gdy błąd został spowodowany przez datagram IP niosący komunikat ICMP.
Ważne jest, że chociaż komunikaty ICMP są kapsułkowane i przenoszone przy użyciu IP, nie są protokołem wyższego rzędu lecz wymaganą częścią IP.
| Wprowadzenie | Sieć komputerowa | Protokoły | Model OSI (Open Systems Interconnection) | TCP/IP a model OSI | Adresowanie fizyczne | Adresy IP |
| Protokół Odwzorowania Adresów (ARP) | Protokół Odwrotnego Odwzorowania Adresów (RARP) | Internet Protocol (IP) | Kapsułkowanie | Fragmentacja |
| Koleje Życia Datagramu | ICMP | Określanie Ostatecznego Adresata | UDP | Multipleksowanie I Demultipleksowanie | Transmission Control Protocol (TCP) |
| Idea przesuwających się okien | Segment TCP | Porty i połączenia | Konfiguracja TCP/IP w systemie Unix | Przyszłość TCP/IP | Bibliografia |