Internet Control Message Protocol (ICMP) je režijním protokolem Internetu. Slouží k ohlašování chybových stavů, testování dosažitelnosti a všeobecně k výměně některých provozních informací. Jeho implementace je povinná v každém zařízení podporujícím IP.
Verze pro IPv6 je definována v RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. Tento dokument však definuje jen základy – formát paketu a základní druhy zpráv. Další typy ICMP zpráv a pravidla pro jejich generování pak doplňují různé komponenty IPv6, jako je objevování sousedů, podpora skupinových adres a podobně. Důsledkem je, že definice ICMPv6 je rozložena do několika RFC.

Skutečnost, že IP datagram nese ICMP zprávu, signalizuje hodnota 58 v položce Další hlavička. Všechny ICMP zprávy mají jednotný základ, který vidíte na obrázku. Typ (Type) určuje základní druh zprávy. V jeho rámci se může vyskytovat několik podtypů, které jsou identifikovány Kódem (Code). Formát Těla zprávy (Message body) pak pochopitelně závisí na jejím typu. Zpravidla obsahuje čtyřbajtovou položku, která buď nese užitečnou informaci, nebo je nevyužita. Za ní pak následuje co největší část datagramu, který vyvolal odeslání dané ICMP zprávy.
Zprávy jsou rozděleny do dvou tříd: na chybové (jejichž Typ leží v intervalu od 0 do 127) a informační (Typ 128 až 255). Přehled definovaných typů uvádí tabulka 1.
| Chyby | |
|---|---|
1 |
cíl je nedosažitelný |
2 |
příliš velký paket |
3 |
vypršela životnost paketu |
4 |
problém s parametry |
Echo |
|
128 |
požadavek na echo |
129 |
odpověď na echo |
MLD (skupinové adresování) |
|
130 |
dotaz na členství ve skupině |
131 |
ohlášení členství ve skupině |
132 |
ukončení členství ve skupině |
143 |
ohlášení členství ve skupině (MLDv2) |
Objevování sousedů |
|
133 |
výzva směrovači |
134 |
ohlášení směrovače |
135 |
výzva sousedovi |
136 |
ohlášení souseda |
137 |
přesměrování |
148 |
žádost o certifikační cestu |
149 |
ohlášení certifikační cesty |
Informace o uzlu |
|
139 |
dotaz na informace |
140 |
odpověď s informacemi |
Inverzní objevování sousedů |
|
141 |
IND výzva |
142 |
IND ohlášení |
Mobilita |
|
144 |
žádost o adresy domácích agentů |
145 |
odpověď s adresami domácích agentů |
146 |
žádost o mobilní prefix |
147 |
ohlášení mobilního prefixu |
154 |
rychlé předání |
Objevování skupinových směrovačů |
|
151 |
ohlášení skupinového směrovače |
152 |
výzva skupinovému směrovači |
153 |
ukončení skupinového směrovače |
Kromě hodnot uvedených v tabulce jsou typy 100, 101, 200 a 201 určeny pro soukromé experimenty a poslední hodnoty obou částí 127 a 255 rezervovány pro případné budoucí rozšiřování ICMP. Aktuální přehled definovaných typů najdete na adrese:
Formát ICMP zprávy je velice jednoduchý. Ostatně Internet představuje jednu dlouhou řadu vítězství jednoduchých, byť nedokonalých přístupů nad hypersuperdokonalými vzdušnými zámky. Přesto to lidem nedá a červíček „ještě by to mohlo umět …“ pořád hlodá. V případě ICMP vyhlodal RFC 4884: Extended ICMP to Support Multi-Part Messages. Definuje rozšíření, kterými lze do těla zprávy přidávat další informace. Zároveň drobně upravuje některé existující zprávy (konkrétně o nedosažitelnosti cíle a vypršení času), kde prvnímu bajtu původně nevyužité čtyřbajtové položky za základní ICMP hlavičkou přiřazuje význam délky vloženého datagramu.
Rozšíření, jehož formát vidíte na obrázku 2, se přidává na konec těla ICMP zprávy. Za úvodní hlavičkou poskytující jen číslo verze a kontrolní součet se nachází libovolný počet rozšiřujících objektů. Každý z nich má svou vlastní hlavičku, obsahující jeho Délku (Length), Třídu (Class-Num) a Podtyp (C-Type). Za ní pak následují vlastní data rozšiřujícího objektu.

V době vzniku tohoto textu existoval jediný rozšiřující objekt, jehož prostřednictvím mohou směrovače přepravující paket přidávat do ICMP zprávy informace související s MPLS. Jeho definici najdete v RFC 4950: ICMP Extensions for Multiprotocol Label Switching. Zejména v případě nedoručitelnosti datagramu mohou být tyto údaje velmi podstatné.
Chybové zprávy
Současná verze ICMP definuje čtyři typy chybových zpráv. Má-li položka Typ hodnotu 1, oznamuje nedosažitelnost cíle. Posílá ji směrovač, pokud dostal ke zpracování datagram s takovou cílovou adresou, která neumožňuje doručení. Kód v ICMP zprávě pak podrobněji specifikuje důvod nedoručitelnosti. Přehled definovaných kódů uvádí tabulka 2.
| 0 | neznám žádnou cestu k cíli |
|---|---|
1 |
správce zakázal komunikaci |
2 |
mimo dosah zdrojové adresy |
3 |
nedosažitelná adresa (cíl neodpovídá) |
4 |
nedosažitelný port (cíl neodpovídá) |
5 |
zdrojová adresa odporuje vstupně/výstupní politice |
6 |
cesta k cíli je zakázána |
7 |
chyba v hlavičce se zdrojovou cestou |
Kód 0 je evidentní. Kód 1 ohlašuje, že datagram porušil nějaká pravidla ve firewallu a jeho odeslání bylo tedy zakázáno správcem. Pokud chce filtrující zařízení poskytnout podrobnější informace, může místo jedničky použít jeden z později přidaných kódů 5 a 6. Pokud je nepřípustná zdrojová adresa, sáhne po kódu 5. Jestliže se na černé listině nachází cílová adresa, pošle kód 6.
Kód 2 se použije, pokud by směrovač měl předat datagram do rozhraní, které leží mimo dosah zdrojové adresy. To znamená, že příjemce datagramu by neměl jak poslat zpět odpověď. Kódy 3 a 4 signalizují, že z hlediska směrování je vše v pořádku, ale směrovač nebyl schopen datagram předat, protože následující prvek v cestě se nechová korektně (nepodařilo se zjistit jeho linkovou adresu, na příslušném portu nikdo nenaslouchá a podobně). Kód 7 byl definován pro směrování v nízkonapěťových a ztrátových sítích (RPL, RFC 6550).
Typ s hodnotou 2 ohlašuje příliš velký datagram. IPv6 má ve srovnání se svým předchůdcem podstatně omezený model fragmentace, je to popsáno zde. Pokud má být paket odeslán linkou, jejíž MTU je menší než velikost paketu, směrovač jej nesmí fragmentovat. Místo toho datagram zahodí a pošle odesilateli ICMP zprávu typu 2. Čtyřbajtová položka následující za kontrolním součtem obsahuje hodnotu MTU linky, jež problém způsobila. Tyto zprávy se používají například při objevování MTU cesty, které je popsáno zde.
Když datagramu vyprší doba platnosti (hodnota položky Maximum skoků klesne na nulu), směrovač jej zahodí a pošle odesilateli ICMP zprávu s Typem 3 a Kódem 0. Druhou možnou příčinou pro odeslání zprávy Typu 3 je, pokud se příjemce nedočká v daném časovém limitu všech fragmentů skládaného datagramu. V tom případě má Kód hodnotu 1.
Zpráva Typu 4 signalizuje, že příjemce obdržel datagram, s jehož parametry se nebyl schopen vypořádat. Konkrétní problém je identifikován Kódem – viz tabulka 4.
| 0 | chybná položka v hlavičce |
|---|---|
1 |
neznámý typ v poli Další hlavička |
2 |
neznámá volba |
3 |
hlavičky přesahují první fragment |
Čtyřbajtová položka za kontrolním součtem identifikuje problematický údaj. Udává počet bajtů od začátku datagramu, kde začíná položka, které příjemce nerozuměl.
Informační zprávy
RFC 2463 definuje pouhé dvě informační zprávy: výzva a odpověď na echo. Používá je dobře známý program ping (resp. ping6) k testování, zda je určitý stroj dostupný.
Výzva i odpověď mají stejný formát. Za kontrolním součtem následují dvě šestnáctibitové položky:
-
Identifikátor
-
a Pořadové číslo.
Typické volání pingu vyvolá sekvenci žádostí se stejným identifikátorem a postupně narůstajícím pořadovým číslem. Navíc lze do těla vložit data podle potřeby. Každý IPv6 uzel je povinen na výzvu reagovat odpovědí. V ní zopakuje identifikátor, pořadové číslo a data z výzvy, aby příjemce poznal, ke které z jeho výzev se odpověď vztahuje.
Zatímco služba echo poskytuje spíše informace o síti (zda funguje a jak dlouho trvá obrátka k cí- lovému stroji a zpět), RFC 4620: IPv6 Node Information Queries zavádí experimentální protokol, kterým se dají získávat jednoduché informace o uzlech. Konkrétně umožňuje zeptat se uzlu na jméno nebo jeho IPv6 či IPv4 adresu. Tyto zprávy se nesnaží konkurovat DNS, ale poskytnout základní informace v případě, že DNS není k dispozici. Protokol má sloužit spíše pro správu sítě, nikoli jako běžná služba koncových počítačů.
Pro své účely zavádí dva typy ICMP zpráv. Dotaz nese Typ 139 a jeho Kód podrobněji informuje, jaký druh informací požaduje. V těle pak obsahuje vlastní data dotazu – jméno či adresu, k nimž shání protějšek. Odpověď je konstruována podobně a nese ji ICMP zpráva typu 140.
Jako možné využití zmiňuje RFC 4620 mimo jiné i objevování počítačů v síti. Samozřejmě pro ty dobré účely. Určitý problém vidím v tom, že počítače v síti bývají daleko častěji objevovány pro ty špatné účely – aby bylo na co útočit. Na masivní podporu informačního protokolu bych proto příliš nesázel.
Další informační zprávy jsou definovány v jiných RFC dokumentech, protože jsou součástí komplexnějších mechanismů IPv6. Konkrétně zprávy související se členstvím ve skupinách jsou prvkem skupinového adresování IPv6. Výzva a ohlášení směrovače či souseda stejně jako přesměrování patří do automatické konfigurace a objevování sousedů. Také návrh podpory mobilních zařízení přišel se svými zprávami.
Bezpečnostní aspekty ICMP
ICMP ze světa IPv4 má ve své skvělé historii několik šrámů, kdy bylo zneužito k omezení funkčnosti sítě. Princip těchto útoků byl celkem jednoduchý: cílový stroj se zahltil haldou ICMP zpráv a skoro nic jiného nemělo šanci projít. Důsledkem bylo, že správci některých serverů či lokálních sítí zablokovali příjem ICMP, což je jednak proti RFC (implementace ICMP je povinná), jednak to omezuje diagnostiku chyb či parametrů sítě.
Aby se správci nemuseli uchylovat k takto drastickým metodám, má ICMPv6 implementována bezpečnostní opatření. Ta by měla zabránit jeho zneužití pro výše uvedené účely.
První z nich spočívá v tom, že implementace by měla umožnit svému správci nastavit některé kvantitativní parametry – průměrný počet ICMP zpráv za jednotku času či jejich maximální podíl na celkové šířce pásma, které daný stroj generuje. Tato omezení zaručují, že v odesílaných datech zbude dost prostoru na reálný provoz.
Druhá skupina opatření se týká spolupráce s bezpečnostními mechanismy IPv6. Zprávy lze opatřit autentizační či šifrovací hlavičkou a uzel by to měl dělat, pokud pro cíl dané ICMP zprávy existuje bezpečnostní asociace. Pokud má přijatá zpráva bezpečnostní hlavičku, musí být prověřena a pokud neodpovídá, zahodí se. Dále by správce měl mít možnost konfigurovat uzel tak, že přijímá jen zabezpečené ICMP zprávy. Ostatní ignoruje.
Problém s filtrováním ICMPv6 spočívá i v tom, že některé mechanismy IPv6 je pro svou činnost potřebují. RFC 4890 proto přineslo konkrétní doporučení, jak by mělo vypadat kvalifikované filtrování ICMPv6, které zadrží škodlivé zprávy, ale propustí jenom ty potřebné.
| Zpráva | Typ/Kód | Tranzitní | Koncová |
|---|---|---|---|
Destination Unreachable |
1 |
propustit! |
propustit! |
Packet Too Big |
2 |
propustit! |
propustit! |
Time Exceeded |
3/0 |
propustit! |
propustit! |
Time Exceeded |
3/1 |
propustit |
propustit |
Parameter Problem |
4/0 |
propustit |
propustit |
Parameter Problem |
4/1 |
propustit! |
propustit! |
Parameter Problem |
4/2 |
propustit! |
propustit! |
nepřiřazené chybové zprávy |
5—99 |
rozhodnout |
rozhodnout |
experimentální |
100—101 |
zahodit |
zahodit |
nepřiřazené chybové zprávy |
102-126 |
rozhodnout |
rozhodnout |
rozšiřující |
127 |
zahodit |
zahodit |
Echo Request |
128 |
propustit! |
propustit! |
Echo Response |
129 |
propustit! |
propustit! |
Listener Query |
130 |
netřeba |
propustit! |
Listener Report |
131 |
netřeba |
propustit! |
Listener Done |
132 |
netřeba |
propustit! |
Router Solicitation |
133 |
netřeba |
propustit! |
Router Advertisement |
134 |
netřeba |
propustit! |
Neighbor Solicitation |
135 |
netřeba |
propustit! |
Neighbor Advertisement |
136 |
netřeba |
propustit! |
Redirect |
137 |
netřeba |
rozhodnout |
Router Renumbering |
138 |
zahodit |
netřeba |
Node Information Query |
139 |
zahodit |
rozhodnout |
Node Information Response |
140 |
zahodit |
rozhodnout |
Inverse Neighbor Discovery Solicitation |
141 |
netřeba |
propustit! |
Inverse Neighbor Discovery Advertisement |
142 |
netřeba |
propustit! |