Protokół IP nie posiada mechanizmów sygnalizujących błędy oraz mechanizmów umożliwiających kontrolowanie przepływu pakietów. Z tego względu zgłaszaniem problemów z przesyłaniem datagramów oraz sterowaniem zajmuje się protokół ICMP
Innym protokołem, który umożliwia bardziej efektywne rozsyłanie pakietów jest protokół IGMP. Protokół ten działa w oparciu o adresy rozsyłania grupowego.
Powszechnie stosowaną wersją protokołu IP jest wersja 4. Jednak ze względu na ograniczenia dotyczące adresowania logicznego spowodowane niedostateczną, w stosunku do potrzeb, liczbą bitów przeznaczonych na adres IP protokół ten będzie zastąpiony nowszą wersją IPv6. Szczegóły dotyczące adresacji w obu tych protokołach zostaną przedstawione w następnym module.
W module tym zostaną pokrótce omówione protokoły: IPv4, IPv6, ICMP, IGMP.
Protokół IP jest protokołem bezpołączeniowym. Oznacza to, że w celu przesłania pakietów nie jest nawiązywane połączenie z hostem docelowym. Pakiety mogą być przesyłane różnymi trasami do miejsca przeznaczenia, gdzie są następnie składane w całość. Podobna zasada działa przy przesyłaniu listów tradycyjnym systemem pocztowym. Tutaj również w momencie wysyłania listu adresat nie musi potwierdzać, że przesyłkę odbierze.
Do przesyłania danych protokół IP używa specjalnego formatu pakietu. Pakiet ten składa się z nagłówka pakietu oraz danych do przesłania. Zgodnie z zasadą przesyłania strumieniowego dane protokołu IP są danymi pochodzącymi z wyższych warstw modelu ISO/OSI. Dane te są następnie enkapsulowane do postaci pakietu IP. Przy przejściu do warstwy łącza danych pakiet IP jest enkapsulowany do postaci ramki Ethernetowej.
Poszczególne pola pakietu mają następujące znaczenie: - wersja (VERS) - pole 4-bitowe określające typ protokołu IP. Jeśli jest tam wpisana wartość 4 oznacza to wersję czwartą protokołu. Jeśli jest tam wartość 6 oznacza to IPv6. Rozróżnianie pomiędzy pakietami wersji 4 i 6 jest przeprowadzane już przy analizowaniu ramki warstwy drugiej poprzez badanie pola typu protokołu. długość nagłówka (HLEN) - pole 4 bitowe określające długość datagramu wyrażoną jako wielokrotność słów 32 bitowych. typ usługi (TOS ang. Type-of-Service) - 8-bitowe pole określające poziom ważności jaki został nadany przez protokół wyższej warstwy. Znaczenie poszczególnych bitów tego pola jest następujące: pierwsze 3 bity: wartość 0 - stopień normalny, wartość 7 - sterowanie siecią czwarty bit - O - prośba o krótkie czasy oczekiwania piąty bit - S - prośba o przesyłanie danych szybkimi łączami szósty bit P - prośba o dużą pewność przesyłania danych bity 6, 7 nieużywane całkowita długość - pole 16-bitowe. Długość całego pakietu wyrażona w bajtach. W celu uzyskania długości pola danych należy odjąć od długości całkowitej długość nagłówka. Wartość minimalna wynosi 576 oktetów zaś maksymalna 65535 oktetów, tzn. 64 kB Identyfikacja - 16 bitowe pole używane do określania numeru sekwencyjnego bieżącego datagramu. Znaczniki - 3 bitowe pole. Pierwszy najbardziej znaczący ma zawsze wartość 0. Kolejne znaczące bity sterują fragmentacją (0- oznacza, czy pakiet może zostać podzielony na fragmenty, 1 - nie może być podzielony). Trzeci bit oznacza: ostatni pakiet powstały w wyniku podzielenia (jeśli ma wartość 1) lub pakiet ze środka 0. Przesunięcie fragmentu - 13-bitowe pole służące do składania fragmentów datagramu. Czas życia (TTL, ang. Time To Live) - 8-bitowe pole określające liczbę routerów (przeskoków), przez które może być przesłany pakiet. Wartość tego pola jest zmniejszana przy przejście przez każdy router na ścieżce. Gdy wartość tego pola wynosi 0, wtedy pakiet taki jest odrzucany. Zasada ta pozwala na stosowanie mechanizmów zapobiegających zapętlaniu się tras routingu. Protokół - 8-bitowe pole określające, który z protokołów warstwy wyższej odpowiada za przetworzenie pola Dane. Możliwe opcje tego pola zostały przedstawione na następnych slajdach. Suma kontrolna nagłówka - 16-bitowe pole z sumą kontrolną nagłówka pozwalającą stwierdzić, czy nie nastąpiło, naruszenie integralności nagłówka. Ze względu na fakt, że każdy router dokonuje zmian w nagłówku musi ona być przeliczona na każdym z routerów. Adres IP nadawcy - 32-bitowe pole z adresem IP nadawcy pakietu Adres IP odbiorcy - 32-bitowe pole z adresem IP odbiorcy pakietu Opcje - pole to nie występuje we wszystkich pakietach. Szczegółowe wartości tego pola zostaną omówione na następnym slajdzie.
Uzupełnienie (Wypełnienie) - pole to jest wypełnione zerami i jest potrzebne, żeby długość nagłówka była wielokrotnością 32 bitów (patrz-> Długość nagłówka) Dane - pole od długości do 64kB zawierające dane pochodzące z wyższych warstw.
Wartości pól kodu opcji mają następujące znaczenie:
Znaczenie pól poszczególnych opcji zostało podane w tabeli.
Wartości wpisane w pole „protokół” nagłówka IP mają następujące znaczenie: 1 - ICMP (ang. Internet Control Message Protocol) - protokół komunikacyjny sterowania siecią Internet 2 - IGMP (ang. Internet Group Message Protocol) - protokół zarządzania grupami Internetowymi 6 - TCP - (ang. Transmission Control Protocol) - protokół sterujący transmisją 8 - EGP - (ang. Exterior Gateway Protocol) - zewnętrzny protokół bramowy 17 - UDP - (ang. User Datagram Protocol) - protokół datagramów użytkownika
W ramach warstwy sieciowej sprawdzaniem dostępności sieci docelowej zajmuje się protokół ICMP (ang. Internet Control Message Protocol). Jego zadaniem nie jest rozwiązywanie problemów z zawodnością IP, ale zgłaszanie braku łączności. Protokół ten został zdefiniowany w dokumencie RFC 792.
Komunikaty ICMP wysyłają zwykle bramy lub hosty. Najczęstsze powody wysyłania tych komunikatów to: zbytnie obciążenie routera lub hosta - wysyłany jest komunikat ICMP, że należy zwolnić prędkość przesyłania komunikatów, bo host nie nadąża je przetwarzać
Struktura datagramu ICMP jest odmienna od struktury datagramu IP. Wspólny jest tylko sposób adresacji.
Pole Typ: 0 - odpowiedź z echem (ang. Echo Reply) 3 - odbiorca nieosiągalny (ang. Destination Unreachable). 4 - zmniejszenie szybkości nadawania - tłumienie źródła (ang. source quench) 5 - zmiana trasowania - przekierowanie (ang. redirect). 8 - prośba o echo (ang. echo request) 9 - rozgłaszanie routera (ang. router advertisement) 10 - wywołanie routera (ang. router solicitation) 11 - przekroczenie TTL (ang. Time Exceeded) 12 - kłopot z parametrami datagramu 13 - prośba / żądanie o wysłanie znacznika czasu (ang. timestamp request) 14 - odpowiedź na prośbę / żądanie o wysłanie znacznika czasu (ang. timestamp reply) 15 - prośba o informację 16 - odpowiedź z informacją 17 - prośba o maskę adresu 18 - odpowiedź z maską adresu 30 - Traceroute 31 - błąd konwersji datagramu (ang. Datagram Conversion Error) 32 - przekierowanie hosta mobilnego (ang. Mobile Host Redirect) 33 - IPv6 Where-Are-You 34 - IPv6 Here-I-Am 35 - prośba o zarejestrowanie urządzenia mobilnego (ang. Mobile Registration Request) 36 - odpowiedź na prośbę o zarejestrowanie urządzenia mobilnego (ang. Mobile Registration Reply) 37 - żądanie nazw domeny (ang. Domain Name Request) 38 - zwrot nazwy domeny (ang. Domain Name Reply) 39 - SKIP Algorithm Discovery Protocol 40 - Photuris, Security Failures
W zależności od wartości występującej w polu Typ, wartość pola Kod może zawierać różne liczby. Najczęściej spotykane wartości par Typ, Komunikat zostaną przedstawione na następnych slajdach.
Następujące wartości pola Typ są zarezerwowane : 1,2,7,19 (zarezerwowane dla bezpieczeństwa), 20-29, 41-255.
Tego typu komunikaty ICMP są wykorzystywane przez podstawowe programy testujące, takie jak ping czy traceroute. Przykłady wywołania tych programów zostaną podane na kolejnych slajdach.
W zależności od przyczyny błędu w polu „Kod” pojawiają się wartości liczbowe powiązane z następującymi usterkami: 0 - sieć niedostępna 1 - host niedostępny 2 - protokół niedostępny 3 - port niedostępny 4 - niezbędna fragmentacja, ustawiona wartość DF 5 - nie powiodło się określenie trasy przez nadawcę (ang. source route) 6 - nieznana sieć docelowa 7 - nieznany host docelowy 8 - host źródłowy odizolowany 9 - komunikacja z siecią docelową zablokowana przez administratora 10 - komunikacja z hostem docelowym zablokowana przez administratora 11 - sieć niedostępna dla tego typu usługi 12 - host niedostępny dla tego typu usługi
Komunikat o niedostępnym adresie wysyłany jest również w przypadku, gdy przesyłany pakiet musi zostać podzielony na mniejsze datagramy, np. przy przesyłaniu z sieci typu Token Ring do sieci Ethernet, a znacznik w nagłówku pakietu nie pozwala na taką fragmentację. Wysyłany jest wtedy kod błędu o wartości 4.
W przypadku zablokowania przez administratora określonych usług sieciowych, takich jak np. www, również nie można przesłać pakietów z żądaniem wyświetlenia strony. Generowany jest wtedy komunikat o niedostępnym adresacie ze stosowną wartością kodu błędu.
Innym powszechnie stosowanym programem narzędziowym jest program traceroute. Przykład efektu wywołania tego programu został przedstawiony na slajdzie.
Jeśli pole „Kod” ma wartość 0, to wartość w polu „Wskaźnik” wskazuje numer oktetu nagłówka datagramu, w którym występuje błędna wartość parametru.
W przykładzie na rysunku pokazany jest przypadek wysłania komunikatu tłumienia źródła przez router, który jest połączony z dostawcą Internetu przy pomocy łącza o niewielkiej przepustowości (np. 100 Mb), zaś sieć lokalna pracuje z wyższą prędkością.
W przykładzie zamieszczonym na rysunku host H1, o numerze IP 192.168.1.10/24, chce przesłać pakiet do hosta H2 o numerze IP 10.1.2.10/8. Host H1 ma ustawioną bramę domyślną o adresie 192.168.1.1/24 i do niej mógłby wysyłać pakiety skierowane do hosta H2. Jednak pakiety te wysłane na interfejs E0 routera A będą przez ten router kierowane na ten sam interfejs i wysyłane do routera B, który następnie będzie przesyłał dalej do hosta H2. Aby uniknąć niepotrzebnego przesyłania pakietów przez router A urządzenie to prześle komunikat ICMP do hosta H1, żeby przyszłe pakiety do hosta H1 oraz sieci 10.1.2.0/8, wysyłał na adres routera B (192.168.1.2/24)..
I tak w przypadku wykrycia lepszej trasy dla pakietów wysyłany jest komunikat o wartości pola Typ równej 5. Oznacza on zmianę trasowania / przekierowanie (ang. redirect). Za wysłanie takiego komunikatu odpowiada host będący domyślną bramą, żeby komunikat taki został wysłany muszą być jednak spełnione następujące warunki: - pakiet przesyłany do routera na jego interfejs jest następnie zawracany i kierowany przez ten sam interfejs do innego routera - adres sieci IP nadawcy jest taki sam jak routera następnego przeskoku routowanego pakietu - trasa pakietu nie jest określona przez nadawcę - trasa określona po przekierowaniu nie jest trasą domyślną lub kolejnym przekierowaniem ICMP - router jest skonfigurowany do wysyłania żądań przekierowania pakietów.
Żądanie przekierowania pakietów w zależności od wartości pola Kod może dotyczyć zarówno sieci jak i hostów: - 0 - datagramy przekierowania dla sieci - 1 - datagramy przekierowania dla hosta - 2 - datagramy przekierowania dla typu usługi i sieci - 3 - datagramy przekierowania dla typu usługi i hosta W polu „adres internetowy routera” (ang. Router Internet Address) wskazywany jest adres urządzenia, które będzie pełniło bramę dla pakietów przesyłanych do sieci, dla których zostało wygenerowane żądanie przekierowania.
W celu synchronizacji zegarów na danym hoście (serwerze) z innym hostem (serwerem) wysyłany jest stosowny komunikat ICMP żądanie / prośba wysłania znacznika czasowego (ang. timestamp request) o wartości pola Typ równej 13. W odpowiedzi na taką prośbę wysyłany jest komunikat odpowiedzi o wartości pola Typ równej 14. Pola kodu w przypadku obu typów komunikatów są równe 0. Pola, w których będą umieszczane znaczniki czasu są wypełniane czasem podanym w milisekundach liczonych od północy czasu uniwersalnego (UTC). Przed wysłaniem komunikatu wypełniane jest pole „Początkowy znacznik czasu” wartością daty i godziny czasu dla hosta źródłowego. W polu „Znacznik czasu odbioru” wstawiany jest czas odbioru przez host docelowy komunikatu z żądaniem wysłania znacznika czasu. Następnie, przed wysłaniem komunikatu z odpowiedzią, wypełniany jest aktualny czas do pola „Znacznik czasu wysłania”.
Analiza trzech pól przesłanych w odpowiedzi na prośbę o znacznik czasu umożliwia oszacowanie czasu przesyłania pakietu przez sieć zarówno w jedną jak i drugą stronę. W praktyce zamiast tego typu pomiarów stosuje się protokoły wyższych warstw stosu protokołów TCP/IP, np. protokół NTP (ang. Network Time Protocol).
W praktyce obecnie nie są wykorzystywane, gdyż informacje takie są przesyłane w sposób bardziej dogodny przez protokoły takie jak BOOTP, RARP czy też DHCP. Protokoły służące uzyskiwaniu adresów zostaną omówione w kolejnym module poświęconym automatycznemu uzyskiwaniu adresów IP.
W przypadku, gdy host zna adres routera w danej podsieci, komunikat żądanie maski adresowej wysyłany jest na adres tego komputera. W przeciwnym razie komunikat ten wysyłany jest na adres rozgłoszeniowy. W odpowiedzi router wysyła na adres hosta, który wysłał żadanie, netmaskę w odpowiednim polu komunikatu zwrotnego.
Pola „Identyfikator” jak i „Numer sekwencyjny” służą do skojarzenia zapytań i odpowiedzi. Mogą mieć wartość 0.
Jednym z nich jest cykliczne wysyłanie przez router komunikatów rozgłaszania routera (ang. router advertisement), które mogą zostać odebrane przez hosty w sieci lokalnej. Komunikat taki ma w polu Typ wpisaną wartość 9. Komunikaty rozgłaszania routera nie służą do wyboru najlepszego routera do przesyłania pakietów do określonej lokalizacji. Gdy host wybierze router, który nie jest optymalny do przesyłania pakietów do określonej lokalizacji, to powinien zostać o tym poinformowany poprzez komunikat ICMP o przekierowaniu (komunikat ten został omówiony na jednym z wcześniejszych slajdów.
Drugim sposobem jest wysłanie przez nowo podłączony do sieci host komunikatu wywołania routera (ang. router solicitation). Taki komunikat ma w polu Typ wpisaną wartość 10.
Wyżej wymienione typy komunikatów zostaną przedstawione na kolejnych slajdach. Należy podkreślić, że ze względu na własności protokołu DHCP (zostanie on omówiony w module poświęconym automatycznemu pozyskiwaniu adresów IP) znaczenie protokołu IRDP jest obecnie niewielkie.
Działanie takie jest możliwe, dzięki transmisjom grupowym (ang. multicasting). W tym typie transmisji pakiety wysyłane są na adres grupowy IP. Routery wiedzą, które komputery znajdują się w grupie obsługiwanej przez daną aplikację. Pozwala to na jednokrotne wysłanie określonych danych do wszystkich hostów z danej grupy. Jest to działanie bardziej efektywne niż transmisje kierowane (ang. unicasting), czy też wysyłanie poprzez adres rozgłoszeniowy (ang. broadcasting).
-host powiadamia router o tym, że chce się przyłączyć do danej grupy -host wiąże w sposób dynamiczny IP z adresem grupowym, który jest zarezerwowany dla danej aplikacji oraz z zarezerwowanym adresem Ethernetowym
Opuszczenie danej grupy odbywa się poprzez wysłanie komunikatu IGMP Explicit Leave. Host powinien powiadomić lokalne routery o zamiarze opuszczenia grupy poprzez wysłanie właśnie takiego komunikatu.
Routery okresowo sprawdzają czy w dalszym ciągu istnieje potrzeba przesyłania pakietów na adres grupowy. Kontrola taka odbywa się poprzez wysłanie zapytania przy użyciu adresu grupowego przeznaczonego dla wszystkich hostów (224.0.0.1). Pakiety które są wysyłane pod ten zarezerwowany numer IP mają ustawione pole TTL na wartość jeden, dzięki temu nie są rozsyłane dalej przez inne routery. W odpowiedzi hosty powinny przesłać pakiet raportu z adresem takim jaki jest zarezerwowany dla tej grupy. Po sprawdzeniu, które z grup jeszcze istnieją routery będą przesyła tylko pakiety dla funkcjonujących grup, natomiast pakiety z adresem grupowym będą odrzucane przez router.
Wersja - 4b - wersja pakietu IGMP Typ - 4b - typ komunikatu. Wartości tam zapisane oznaczają odpowiednio;
Nie używane - 8b - pole nie wykorzystywane Suma kontrolna - 16b - pole wykorzystywane do przesyłania liczby umożliwiającej sprawdzenie integralności pakietu Adres grupy - 32b - gdy pakiet jest przesyłany w celu zapytania o przynależność hosta, to pole to jest puste. Gdy host odpowiada raportem o przynależność do grupy, to w polu tym przesyłany jest adres rozsyłania grupowego konkretnej grupy.
Wśród najczęściej spotykanych protokołów rozsyłania grupowego działających pomiędzy routerami sa: PIM (ang. Protocol Independent Multicast Protocol) - protokół adresowania grupowego niezależny od protokołów. Standard ten został opisany w dokumencie RFC 2117. MOSPF (ang. Multicast Extensions to OSPF) - rozszerzenie protokołu OSPF o adresowanie grupowe. Protokół ten został opisany w dokumencie RFC 1584 DVMRP (ang. Distance Vector Multicast Routing Protocol) - protokół routingu grupowego na podstawie wektorów odległości. Protokół ten opisano w dokumencie RFC 1075.
Innym powiązanym z poprzednim, wymaganiem jest potrzeba zapewnienia ustalonych parametrów transmisji dla ruchu multimedialnego. Technologie wprowadzane coraz powszechniej: telefonia IP, telewizja cyfrowa, wideo na życzenie itp. wymagają stałych parametrów przesyłania.
Innym, równie istotnym, wymogiem jest kwestia autoryzacji nadawcy, która nie była możliwa w IPv4.
Te oraz inne niewymienione czynniki bardzo istotnie przemawiają za szybką migracją do IPv6, który również bywa nazywany protokołem następnej generacji IPNG (IP Next Genaration).
Warto podkreślić fakt, że zmiana protokołu warstwy sieciowej modelu ISO (protokołu warstwy Internetowej stosu protokołów TCP/IP) nie powoduje potrzeby dostosowywania protokołów pozostałych. Część z dostawców Internetu (ISP) oferuje już dostęp do IPv6. Ze względu na fakt, że w dalszym ciągu powszechnie używany jest IPv4, to ruch IPv6 jest tunelowany w starszej wersji protokołu (IPv6-in-IPv4). Protokół IPv6 opisują dokumenty RFC 1883 oraz RFC 1884.
Jedną z podstawowych zalet, chociaż nie najważniejszą, jest liczba dostępnych adresów w nowej wersji protokołu. Ze względu na to, że do zapisania adresu w IPv6 użytych jest 128 bitów, to dostępna pula wynosi ok. 3,4x10^38 adresów. W przeliczeniu na powierzchnię Ziemi daje to ok. 6,7x10^17/mm^2. W ten sposób zapotrzebowanie na pulę adresów dla nowych rozwiązań sieciowych powinno zostać spełnione. Więcej informacji na temat adresacji znajduje się w dedykowanym module.
Wśród zdefiniowanych nagłówków dodatkowych można wymienić: Hop-by-hop options header Destinations options header-1 Source routing header Fragmentation header Authentication header IPv6 encryption header Destination option header-2