Semestrální projekt do SPS

·    Zprávy protokolu ICMP (IP v.4)

 

 

 

 

 

 

 

 

Vypracoval: Milan Rumplík (rum015)

Datum: 15.5.2005

Úvod

IP se snaží o nejlepší doručování paketů(best effort). IP(internet protocol) nemá žádný mechanismus, jak zajistit, aby byla data bezpečně doručena k cíli - to znamená, pokud dojde ke ztrátě paketu z důvodu jakékoliv chyby, IP nemá žádný mechanismus jak toto zjistit. Data nemusí dosáhnout svého cíle z různých důvodů, jako jsou: porucha sítového zařízení(např. směrovače) nebo vedení, nesprávná konfigurace nebo nesprávné směrovací informace. Na pomoc, jak identifikovat tato selhání, IP užívá protokol internetových řídících zpráv (ICMP - internet Control Message Protocol), které oznamují odesílateli dat že někde nastala chyba při přenosu dat. Protokol internetových řídících zpráv ICMP je součástí TCP/IP protokolového vybavení(protocol stack), který pokrývá toto základní omezení IP. ICMP nepřekoná nespolehlivostní problémy v IP, spolehlivost musí být poskytnutá vyšší vrstvou protokolu, je-li to potřebné.

 

 

Hlášení chyb a oprava chyb

 

ICMP hlásí chyby vzniklé při přenosu protokolem IP. Když se při směrování paketu vyskytne jakákoliv chyba, ICMP je užito pro oznámení této chyby zpět do zdroje. ICMP neprovádí žádné opravy paketu, pouze informuje zdroj o vyskytlé chybě. Řešení tohoto problému je ponecháno na vyšší vrstvě.

 

Zapouzdření ICMP

 

ICMP zprávy jsou zapouzdřené (encapsulated) do paketů stejně  jako jiná data, která jsou přenášena použítím IP. Obrázek ukazuje zapouzdření ICMP dat uvnitř IP paketu.

 

 

Protože jsou ICMP zprávy přenášeny stejným způsobem jako jiná data, též podléhají stejným doručovacím pravidlům. Toto vytváří scénář, kde chybové zprávy můžou generovat další chybové zprávy, způsobující ještě větší dopravu na již zahlcené síti. Z tohoto důvodu chyby způsobené ICMP zprávami negenerují další ICMP zprávy. Může tedy nastat situace kdy ztráta paketu není nikdy oznámená zpět odesílateli dat.

 

 

 

 

Tipy ICMP zpráv

 

ICMP zprávy mají speciální formát. Každý typ ICMP zprávy má vlastní jedinečný  parametr, ale všechny ICMP zprávy začínají stejnými třemi poli:

 

Typ signalizuje typ ICMP zprávy, která je poslána.

Kód dále specifikuje vznik ICMP pro daný typ.

Kontrolní součet, jako v dalších typech paketů, je užíván pro ověření integrity dat.

 

Typy ICMP zpráv

 

0

Echo reply

3

Destination unreachable

4

Source quench

5

Redirect/change request

8

Echo reguest

9

Router advertisement

10

Router selection

11

Time exceeded

12

Parameter problem

13

Timestamp request

14

Timestamp reply

15

Information request

16

Information reply

17

Address mask request

18

Address mask reply

 

 

 

Příklady ICMP a jejich modelové situace vzniku

 

V této sekci si ukážeme co přesně jednotlivé ICMP zprávy znamenají a jak může dojít k jejich vzniku. Také si zde ukážeme jak tyto pakety vypadají, pokud je zachytíme nějakým vhodným nástrojem(např. Ethereal).

 

 

Destination unreachable (typ 3)

 

Síťová komunikace závisí na jistých základních podmínkách.:

  1. posílající a přijímající zařízení musí mít TCP/IP protokolové vybavení řádně konfigurované

 

  1. Na cestě paketu ze zdrojového zařízení k jeho cíli se musí vyskytovat zprostředkující zařízení. K této funkci slouží Směrovače(router). Směrovač  musí mít také TCP/IP protokol řádně konfigurován na jeho rozhraních a musí používat vhodný směrovácí protokol.

 

Jestliže výše zmíněné podmínky nejsou splněny, pak síťová komunikace nemůže řádně fungovat. V těchto případech, ale i například pokud:

·        pošleme paket k neexistující adrese(cíl neexistuje nebo je odpojen)

·        došlo k přerušení spojení ve směru cesty paketu

·        došlo k poruše směrovače

můžeme obdržet ICMP zprávu Destination unreachable

Zprávu Destination unreachable obdržíme vždy pokud je cíl, port nebo síť nedostupná.

Typ zprávy Destination unreachable: 3.

Kódy zpráv Destination unreachable:

 

Kódy zpráv 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 unknow

7

Destination host unknow

8

Source host isolated

9

Communiction with destination network administratively prohibited

10

Communiction with destination host administratively prohibited

11

Network unreachable for type device

12

host unreachable for type of service

13

Communication administrativeli filtered

 

 

 

 

Příklady ICMP paketů

 

 

Host unreachable

Stanice A pošle ping na stanici B. Stanici B se chvíli před touto událostí přeruší spojení. Směrovač RA pak pošle zpět do stanice A ICMP zprávu host unreachable.

 

Port unreachable

Stanice A pošle požadavek k RA na port 1002. RA má tento port nedostupný a pošle zpět ke stanici A ICMP zprávu port unreachable.

 

Communication administratively filtered

Stanice A pošle ping ke stanici B. Na RB je nastaven access-list, který omezuje veškerou dopravu ze stanice A do B. Jakmile RB obdrží paket ze stanice A do B, zruší jej a pošle stanici A ICMP zprávu Communication administratively filtered

 

 

 

 

 

Echo request and reply (ping, typ 8 a 0)

 

ICMP protokol může být použitý pro testování dostupnosti určitého cíle. Obrázek ukazuje jak stanice A(192.168.7.2) vysílá ICMP echo request(ping) pro ověření, že cíl B(192.168.1.2) je dostupný. V případě, že stanice B obdrží echo request,  odpoví stanici která tuto zprávu zaslala(stanici A), pošle echo reply. Jakmile stanice A obdrží echo reply oznámí uživateli, že cíl je dostupný a zobrazí jak dlouho od poslání echo request trvalo než stanice A obdržela echo reply.

 

 

 

 

Příklady ICMP paketů

Pakety echo request and reply se spárují podle podle čísla id(identifier)

 

 

 

 

 

time-to-live (TTL) - time exceeded (typ 11)

 

Tato situace může nastat v síťové komunikaci, kde paket cestuje v kruhu a nikdy nedosáhne svého cíle. Tento případ by se mohl vyskytovat, jestliže směrovače ustavičně směrují paket mezi sebou, z důvodů nekonzistence ve směrovací tabulce. Toto je příkladem vadné směrovací informace.

TTL hodnota je definovaná v každém paketu a jak každý směrovač zpracovává paket, snižuje TTL hodnotu o jeden. Když TTL paketu dosáhne nuly, paket již není dále směrován. ICMP používá time exceeded zprávu k oznámení zdroji, že TTL paketu byl překročený.

Omezení plynoucí ze směrujícího protokolu mohou mít za následek, že cíle můžou být nedosažitelné pokud je od sebe dělí dosti velký počet směrovačů.

 

Příklad:

Směrovací protokol RIP má směrovací mez(TTL), kterou může paket projít 15, což znamená, že paket bude schopný cestovat maximálně přes 15 směrovačů(viz obrázek).

 

 

 

Příklad ICMP paketů

 

Počet průchodu přes směrovače překročil maximálni dovolenou mez. Tzn., že hodnota TTL v paketu byla tak dlouho zmenšována o 1, až dosáhla 0 a paket již nebyl dále směrovačem směrován. Směrovač do zdroje tohoto paketu odeslal ICMP zprávu time-to-live exceeded.

 

 

 

host unreachable for type of service (typ 12)

 

Zařízení, která zpracovávají pakety, nesmí být schopná směrovat dále pakety, kvůli nějakému druhu chyby v jejich záhlaví. Pokud se vyskytne tato chyba paket musí být „zahozen“. V tomto případě, ICMP typ 12 - parameter problem zpráva je poslána zpět zdroji paketu.

 

Kód zprávy zahrnuje ukazatel v hlavičce. Když hodnota kódu je 0, ukazatel signalizuje byt paketu, který vyprodukoval chybu.

 

 

ICMP redirect/change requests(typ 5)

 

Jedna z běžných ICMP zpráv je ICMP redirect/change requests. Všechny stanice, které komunikují s více IP sítěmi, musí mít konfigurovanou default gateway, přes kterou dosahují ke vzdáleným sítím(internet). Běžně je stanice připojena k jednomu směrovači, nicméně v některých případech může být stanice přímo připojena ke dvěma nebo více směrovačům. V tomto případě, může směrovač potřebovat použít ICMP redirect/change requestst, k informaci zdroje o nejlepší cestě k síti(viz obrázek).

 

Směrovače posílají ICMP redirect/change requestst, jestliže nastane některý z těchto případů(samozřejmě pokud je konfigurován na posílání přesměrování):

 

ICMP redirect/change requests zpráva užívá typ zprávy 5 a hodnotu kódu 0, 1, 2, nebo 3.

 

Kódy redirect/change requestst zpráv

 

0

Redirected datagrams for the network

1

Redirected datagrams for the host

2

Redirected datagrams for the type of services and networks

3

Redirected datagrams for the type of services and host

 

 

Příklady ICMP paketů

 

Stanice A má nastavenou default gateway na rozhraní 192.168.1.1. Pokud se stanice A rozhodne poslat paket(např. ping-viz ICMP paket níže) do stanice 192.168.3.1, pošle RA  po obdržení prvního paketu do této sítě stanici A redirect/change requestst, informující tento zdroj o tom, aby příště až bude posílat paket do sítě 192.168.3.0, aby ho posílal přímo na rozhraní RB,192.168.1.2.

 

 

 

Timestamp request/reply message(typ13,14)

 

TCP/IP protokolové vybavení umožňuje systému spojovat se přes velké vzdálenosti, skrz více sítí. Každá z těchto jednotlivých sítí poskytuje časovou synchronizaci svým vlastním způsobem. Následkem toho, stanice na různých sítích kteří chtějí komunikovat a používají funkční vybavení které vyžaduje časovou synchronizaci by mohli někdy čelit problémům, z důvodů různé časové synchronizace zdroje a cíle. Typ zprávy ICMP timestamp(časová značka) je navržený k tomu, aby pomáhal zmírnit tento problém.

 

ICMP timestamp request zpráva umožňuje jednotlivým stanicím zeptat se na aktuální čas platný  pro vzdálený cíl. Vzdálený cíl použije  ICMP timestamp reply zprávu k odpovědi na žádost.

 

Typ ICMP zprávy bude buď 13 při timestamp request nebo 14 pro timestamp reply. Kód zprávy bude mít vždy hodnotu 0, protože zde nejsou žádné další možnosti.  ICMP timestamp request obsahuje:

·        Původní(originate) časovou značku, kde je čas žádající stanice právě před odesláním timestamp request.

·        Přijmutou(receive) časovou značku, kde je čas, ve kterém cíl přijal ICMP timestamp request.

·        Časová značka přenosu(transmit timestamp) je vyplněna před odesláním ICMP timestamp reply.

Původní, přijmutá a přenosová(transmit timestamp) značka je vypočítána v počtu milisekund uplynutých od půlnoci světového času UT(Universal Time).

ICMP timestamp reply zprávy obsahují původní, přijmutou a přenosovou značku. Použitím těchto tří značek může zdroj odhadovat dobu přenosu přes síť, odečtením původního času od přenosového času. Je to však pouze odhad, protože doba přenosu se může velice lišit v závislosti na aktuálním provozu na síti. Stanice která poslala timestamp request může také odhadovat čas na vzdáleném počítači.

 

ICMP timestamp zprávy poskytují jednoduchý způsob, jak odhadovat čas vzdálené stanice a dobu přenosu. To však není nejlepší způsob, jak získat tuto informaci. Na místo toho existují lepší protokoly, jako například Network Time Protocol (NTP) ve vyšších vrstvách TCP/IP protokolového vybavení, které vykonávají tuto hodinovou synchronizaci více spolehlivě.

 

 

Příklady ICMP paketů

 

Při generování této ICMP zprávy sem použil příkaz ping se speciálním příznakem, který sem našel v nápovědě k danému příkazu(pro windows: ping ip_adresa –s 1-4). Tento příkaz ovšem nevygeneroval ICMP zprávu timestamp request(typ 13), ale pouze ICMP zprávu echo request, která si při průchodu přes jednotlivé směrovače vyžaduje jejich časová razítka(time stamp) a ty pak ukládá do IP time stamp options, který potom navrátí v ICMP zprávě echo reply. Tohle se dá využít k získání odhadu zpoždění mezi jednotlivými směrovači, avšak nedojde k vygenerování ICMP zprávy, typ 13,14.

Následuje obrázek této situace a ukázka zachycených paketů.:

 

 

 

 

 

 

 

Information request/reply message(typ 15,16)

 

ICMP information requests and reply zprávy byly původně navrženy z toho důvodu, aby umožnili stanici zjistit její IP adresu.

V této zprávě jsou dostupné dva typy. Typ 15 označuje information request zprávu, a typ 16 označuje information reply zprávu. Tyto zvláštní typy zpráv jsou považovány za zastaralé. Jiné protokoly jako BOOTP a DHCP nyní umožňují stanicím získat jejich IP adresy.

Kód zprávy bude mít vždy hodnotu 0, protože zde nejsou žádné další možnosti. 

 

 

 

Address mask message(Typ 17,18)

 

Když síťový administrátor používá proces podsíťování(subnetting), tak že dělí adresu náležící do některé třídy a vytváří podsítě, vytváří též nové masky. Tato nová maska podsíťě je velmi důležitá k poznání bitů sítě, podsítě a stanice v IP adrese. Jestliže stanice nezná masku podsíťě, může poslat address mask request lokálnímu směrovači. Jestliže adresa směrovače je známá, může být tato žádost poslána přímo do směrovače. Jinak bude žádost vyslána jako broadcast. Když směrovač přijme address mask request, odpoví pomocí address mask reply. Tato address mask reply bude identifikovat správnou masku podsíťě.

 

Typ ICMP zprávy bude buď 17 pro address mask request nebo 18 pro address mask reply.

 

Příklad:

Stanice A zná svou IP adresu, ale nezná masku podsítě(viz obrázek). Pošle tedy address mask request(broadcastem nebo na konkrétní IP adresu směrovače,pokud ho zná). RA po obdržení této zprávy pošle do stanice A address mask reply obsahující masku podsítě.

 

 

 

Router selection/advertisement message(typ 10,9)

 

Typ zprávy je 9(10) a kód bude vždy nastaven na 0.

Když se stanice přihlašuje k síti a nemá manuálně konfigurovanou default gateway, může se ji naučit od dostupných směrovačů pomocí procesu router discovery(router discovery – je protokol 2.vrstvy, sloužící k získávání informací o směrovačích). 

Tento proces začíná tak, že stanice pošle zprávu se žádostí(selection message), všem směrovačům používajícím multicastovou adresu 224.0.0.2 jako cílovou. Když směrovač obdrží router selection message pošle zpět stanici, která tuto zprávu zaslala router advertisement message(viz obrázek).

Router advertisement message může být poslána také jako broadcast nebo multicast. Směrovače můžou router advertisement message šířit automaticky na určená rozhraní v pravidelných intervalech(viz ukázka zachyceného ICMP paketu).

 

 

Příklad ICMP paketu-router advertisement

 

Popis paketu:

 

 

 

 

Source-quench message(typ 4)

 

Jestliže se více stanic pokouší přistoupit ve stejnou chvíli, stejnou linkou k nějakému cíli, může nastat zahlcení této linky. Ta může též nastat pokud například přistupujeme z rychlé interní sítě na internet přes pomalou linku. Z tohoto důvodu může být potřeba provést snížení toku paketu ze zdroje. K tomu nám slouží ICMP source-quench message. Tato zpráva je používána k redukci množství ztráty dat a to tak, že se zdroji říká aby zpomalil posílaní paketů do cíle. Jakmile zdroje sníží množství zasílaných dat, měla by se pomalu snižovat zátěž na rozhraní této zahlcené linky. Zdroje po obdržení source-quench messages sníží množství posílaných dat a po určité době budou opět toto množství zvyšovat a to až do té doby dokud opět neobdrží source-quench messages.

Tato ICMP  zpráva se většinou neimplementuje, protože stanice by na tuto zprávu nemusely reagovat. Řešení tohoto problému se provádí tak, že směrovač který je na rozhrání této zahlcované linky, v případě, že dostává podstatně více dat, než je schopný touto linkou posílat, začne „zahazovat“ acknowledgementy pro jednotlivé stanice a ty pak automaticky sníží rychlost posílání dat – stanice sníží počet zasílaných paketů do obdržení acknowledgementu  (viz funkce slide-window).