Organizacje związane ze standaryzacją sieci komputerowych

Transkrypt

1 Organizacje związane ze standaryzacją sieci komputerowych ITU International Telecommunication Union Prapoczątki sięgają 1865 roku (znormalizowanie telegrafu). W 1947 roku ITU stała się agencją ONZ. ITU dzieli się na trzy sektory: Radiocommunications Sector (ITU- R) Telecommunications Standarization Sector (ITU- T) Development Sector (ITU- D) Z punktu widzenia standardów sieci komputerowych najważniejszą sekcją jest ITU- T. Sekcja ta zajmuje się telefonią i przesyłaniem danych. W latach 1956 do 1993 znana była pod nazwą CCITT. Do ITU- T należą członkowie czterech klas: 1) instytucje reprezentujące władze państwowe (ok. 200, prawie wszyscy członkowie ONZ) 2) członkowie branżowi (firmy, np. Cisco, Nokia, AT&T, Vodafone, Apple, Microsoft, Intel; około 500) 3) członkowie stowarzyszeni (mniejsze organizacje zainteresowane konkretną grupą badawczą) 4) agencje nadzorcze (nadzór branży telekomunikacyjnej). Przykłady standardów: CCITT X.25 (ITU- T X.25), V24 (RS- 232), V.90, H.323. ISO International Standards Organization Założona w 1946 roku. Członkami są krajowe organizacje normalizacyjne, np. ANSI (USA), BSI (Wielka Brytania), DIN (Niemcy), PKN (Polska) i ponad 80 innych. Cel normalizacja wszystkiego (przykłady: ziarna kakaowe ISO 2451, sieci rybackie ISO 1530). ISO ma ponad 200 ponumerowanych komitetów technicznych (TC Technical Commitee). TC dzieli się na podkomitety (SC) a te dzielą się na grupy robocze (WG). ISO współpracuje z ITU- T. Przyjęto procedurę przyjmowania przez ISO standardów. Najpierw powstaje grupa robocza do napisania wstępnej wersji standardu, grupa ta tworzy CD (Commitee Draft). CD jest rozprowadzany wśród organizacji członkowskich, które mają 6 miesięcy na krytykę. Potem powstaje poprawiony dokument o nazwie DIS (Draft International Standard), rozprowadzany do komentarzy i głosowania. Na koniec powstaje IS (International Standard). Przykłady grup roboczych: ( Ethernet ) (sieci bezprzewodowe) (Bluetooth) (WiMAX) IAB Internet Architecture Board W 1983 nieformalny komitet nadzorczy dla ARPANETu został sformalizowany i nazwany Internet Activities Board (potem nazwę zmieniono na Internet Architecture Board).

2 Pierwotne zadanie kierować badaczy zaangażowanych w rozwój ARPANET- u (A. Tanenbaum pisze, że przypominało to zadanie zaganiania kotów w stado J ). Do IAB należało ok. 10 osób. Osoby te spotykały się kilka razy w roku, aby omówić wyniki prac i powiadomić Departament Obrony. Jeśli zachodziła potrzeba nowego standardu lub zmiany istniejącego (np. zastosowania innego algorytmu) członkowie IAB rozpracowywali problem i ogłaszali zmianę. Podstawowy sposób komunikowania się stanowiły Requests For Comments (RFC). W 1989 IAB został zreorganizowany. Badacze zostali przeniesieni do Internet Research Task Force (IRTF), która pozostała podległa pod IAB. Drugą jednostką podległą jest Internet Engineering Task Force (IETF). W skład IAB przyjęto osoby reprezentujące szerszy zakres organizacji i firm niż tylko społeczność naukowców. Potem utworzono Internet Society (ISOC) społeczność ludzi i organizacji zainteresowanych Internetem. Internet Society jest zarządzany przez wybieranych członków zarządu, którzy z kolei wybierają członków IAB. Internet Society jest zatem w pewnym sensie zwierzchnikiem IAB. IRTF skupia się na badaniach długofalowych, IETF skupia się na pracy doraźnej. IETF jest podzielony na grupy robocze (ponad 70). Grupy zostały pogrupowane w obszary, których przewodniczący spotykają się jako komitet nadzorczy. Inne ważne organizacje. Przyznawaniem numerów IP, numerów portów parametrów oraz nazw zajmuje się ICANN Internet Corporation For Assigned Names and Numbers Numerami portów i parametrami zajmuje się IANA (Internet Assigned Numbers Authority), która kiedyś była jedyną odpowiedzialną za numery i nazwy, teraz jest podległa ICANN. ICANN oddelegowała fragmenty przestrzeni adresowej IP do: Asia Pacific Network Information Centre (APNIC): Region Azji i Pacyfiku. American Registry for Internet Numbers (ARIN): Ameryka Północna, część Karaibów, część Afryki na południe od równika. Latin American and Caribbean Internet Addresses Registry (LACNIC): Ameryka Łacińska, część Karaibów. Réseaux IP Européens Network Coordination Center (RIPE NCC): Europa, Środkowy Wschód, Azja centralna, Afryka na północ od równika. Dokumenty RFC, Standardy Internetowe (Internet Standard, STD) RFC Request for Comments. RFC jest dokumentem tekstowym, napisanym w formie memorandum, zawierającym opisy techniczne i organizacyjne różnych zagadnień, związanych z Internetem, np. standardów, specyfikacji, protokołów, procedur, koncepcji, propozycji, dobrych praktyk, metod, nowości, prac badawczych itd. RFC są wydawane przez Internet Engineering Task Force (IETF). Każdy dokument RFC ma swój unikalny numer, który służy do odwołań. Dokument jest statyczny, nie zmienia się po opublikowaniu. Zamiast wprowadzania zmian w

3 opublikowanych dokumentach, są tworzone nowe dokumenty, z nowymi numerami. Nowe dokumenty mogą uzupełniać starsze lub całkiem je dezaktualizować. Unieważnione dokumenty są określane jako przestarzałe (deprecated, obsolete). Na przykład protokół IPv4 był opisany w RFC 760, ale dokument ten został unieważniony i IPv4 jest opisany w RFC 791. Zatem zbiór dokumentów RFC stanowi też swoisty zapis historii rozwoju Internetu. Język dokumentów RFC jest bardzo klarowny i precyzyjny, format opisu tekstowy, również rysunki są tworzone ze znaków ASCII (są też dostępne inne wersje, np. PDF). Często dokumenty RFC zawierają pewne określenia, których znaczenie jest precyzowane na początku dokumentu. Znaczenie powszechnie używanych określeń jest opisane w RFC 2119, np. MUST, MUST NOT, NOT RECOMMENDED. Nie wszystkie RFC są standardami internetowymi, ale wszystkie standardy są dokumentami RFC. RFC zostały wymyślone przez Steva Crockera w 1969 roku w celu zapisu oraz wymiany uwag i notatek związanych z rozwojem ARPANET u. Przez pewien czas pełniły rolę rzeczywistych próśb o komentarze, zawierały pytania bez odpowiedzi i miały mniej sztywną formę. Osoby tworzące dokumenty RFC nie tworzyły formalnej organizacji ani komitetu, byli to naukowcy zainteresowani i związani z projektem ARPANET. Z biegiem czasu zostały sformalizowane zasady tworzenia i publikowania dokumentów RFC. Dokument musi być zatwierdzony przez edytora RFC (RFC Editor), który nadaje mu numer seryjny. Przez wiele lat (od 1969 do 1998) edytorem RFC była jedna osoba: Jon Postel. Obecnie jest to grupa osób. Zasady tworzenia i publikowania RFC i tworzenie standardów są opisane w RFC 2026 i innych (krótki opis i odwołania są tu: process.html). Każdy dokument RFC ma swój status w procesie standaryzacji Internetu. Statusy: Informational, Experimental, Best Current Practice (BCP), Standards Track, Historic. Dokumenty o statusie Standard Track można przypisać do jednej z trzech kategorii: Proposed Standard, Draft Standard, Internet Standard. Jak dokument RFC staje się standardem internetowym (Internet Standard STD), dostaje numer standardu, ale zatrzymuje też swój dotychczasowy numer RFC. Numer standardu nie zmienia się, ale mogą się zmieniać związane z nim RFC. Lista standardów internetowych określona jest w standardzie internetowym numer 1 Internet Standard, STD 1: Internet Official Protocol Standards. Dokumenty o statusie BCP też mają swoje numery. Np. wspomniany wyżej RFC 2026 (zasady tworzenia RFC i standardów) jest częścią BCP 9. Są dwie ścieżki tworzenia i publikowania RFC. Wszystkie dokumenty RFC muszą obecnie być najpierw opublikowane jako Internet- Drafts (I- Ds). Jednak nie wszystkie I- Ds. stają się RFC. W procesie zgłaszania RFC (RFC submission process) są teraz dwie ścieżki ( editor.org/pubprocess.html): RFC s from IETF oraz Independent submissions. W ramach pierwszej ścieżki propozycja dociera do edytora od IESG (Internet Engeneering Steering Group), która jest odpowiedzialna za zarządzanie IETF i składa się z Area Directors, odpowiedzialnych za poszczególne grupy robocze. W ramach drugiej ścieżki każdy może zgłosić propozycję RFC, ale tylko z grupy Informational lub Experimental.

4 Przyjęto formalny sposób standaryzacji (wzorowany na organizacji ISO). Obecnie proces składa się z kilku etapów. W ramach pierwszego etapu proponowany standard jest opublikowany w formie wspomnianego już Interntet Draft. Następnie ogłaszane są różne poprawki (revisions). W pewnym momencie, po osiągnięciu odpowiedniej dojrzałości, propozycja staje się Proposed Standard. Kolejny krok zawiera odpowiednio opisane procedury testowania (przynajmniej przez 4 miesiące w dwóch niezależnych lokalizacjach). Na koniec RFC uznawany jest za Internet Standard. Jeśli nie liczyć etapu Internet Draft, obecnie procedura ma dwa poziomy: Proposed Standard i Internet Standard (do października 2011 były określone trzy poziomy: Proposed Standard, Draft Standard i Internet Standard). Zmiana została wprowadzona przez RFC Ważny RFC opisujący IETF: RFC Inne ciekawe RFC informacyjne: RFC 1983 Internet User s Glossary (wyjaśnia wiele pojęć używanych w sieciach komputerowych). Inna grupa (J ): RFC RFC RFC RFC 3251.

5 Protokół IPv4 Protokół IP jest protokołem warstwy trzeciej modelu ISO OSI. Implementacja protokołu IP składa się z oprogramowania spełniającego różne funkcje. Oprogramowanie to jest odpowiedzialne za adresowanie IP, tworzenie datagramów IP (pakietów) i uczestniczy w kierowaniu ich w sieci z punktu początkowego do punktu docelowego. IP realizuje usługę zawodną, tzn. zawiera mechanizmy dostarczania datagramów, ale w przypadku jakiegoś niepowodzenia (np. przepełnienie buforów routera) datagram IP nie jest przesyłany ponownie. Datagram może zaginąć, czasem jest celowo usuwany przez routery i wówczas wysyłany jest odpowiedni komunikat do nadawcy. Jest to komunikat protokołu ICMP. Mechanizmy niezawodności muszą być dostarczone przez protokoły warstwy wyższej. Datagram IP składa się z nagłówka (header) i bloku danych (payload). Nagłówek dzięki informacjom w nim zawartym umożliwia obsługę routowania, identyfikację bloku danych, określenie rozmiaru nagłówka i datagramu oraz obsługę fragmentacji. W nagłówku mogą się znaleźć również tzw. opcje rozszerzające. Nagłówek IP ma zmienną długość (20 do 60 bajtów, co 4 bajty). Blok danych może mieć długość do bajtów. Nagłówek IPv4 Nagłówek zawiera następujące pola (w kolejności): Wersja (4 bity) Długość nagłówka IP (IHL Internet Header Length) (4 bity) Typ usługi (8 bitów) Długość całkowita (16 bitów) Identyfikator (16 bitów) Flagi (3 bity) Przesunięcie fragmentu (13 bitów) Czas życia (TTL) (8 bitów) Protokół (8 bitów) Suma kontrolna nagłówka (16 bitów) Adres IP źródła (32 bity) Adres IP docelowy (32 bity) Dodatkowe opcje i wypełnienie (32 bity + ew. więcej). Za nagłówkiem IP w datagramie znajdują się dane (segment TCP, datagram UDP, komunikat ICMP).

6 Opis pól w nagłówku IP Wersja liczba 4 dla podstawowego obecnie IPv4 (0100 binarnie). Długość nagłówka liczba 4- bajtowych bloków. Najczęściej nagłówek ma 20 bajtów, a więc 5 bloków (0101 binarnie). Maksymalnie długość nagłówka może wynosić 15*4 = 60 bajtów ( = ). Typ usługi (TOS) zawiera dodatkowe informacje używane w routingu. Według pierwszych specyfikacji TOS powinien zawierać informacje o jakości usługi za pomocą której datagram ma być przesyłany w sieci. Routery na podstawie informacji z TOS mogą wybierać inne trasy dla różnych TOS. Pola TOS zawierają informacje o priorytecie (priorytet 1 bit) oraz o tym, czy ma być realizowana minimalizacja opóźnień (opóźnienie 1 bit), maksymalizacja szybkości przesyłania (przepustowość 1 bit), maksymalizacja poprawności (niezawodność 1 bit, używane przy zatorach w routerze, datagramy z ustawioną jedynką są odrzucane w ostatniej kolejności), minimalizacja kosztów (koszt 1 bit). TOS jest ustawiane przez hosta nadającego i nie jest modyfikowane przez routery. Pole to może być używane do obsługi tzw. QoS (Quality of Services). W rzeczywistości jednak TOS może nie być obsługiwany przez wiele routerów i jego wykorzystanie jest problematyczne. Powstały różne propozycje jak to pole wykorzystać. Całkowita długość na podstawie tego pola oraz pola Długość nagłówka można określić wielkość bloku danych oraz początek tego bloku. Całkowita długość podawana jest w bajtach. Ze względu na to, że jest to pole 16 bitowe, to maksymalna możliwa długość datagramu IP może wynosić Jednak rozmiar największego datagramu IP, który jest przesyłany przez pewien fragment sieci zależy od technologii sieciowej, która jest w tym fragmencie używana. Rozmiar ten jest określany jako MTU Maximum Transfer Unit. Specyfikacja IPv6 umożliwia przesyłanie pakietów większych, tzw. Jumbogramów. Identyfikacja identyfikacja kolejnych datagramów. Wartość jest wpisywana przez host nadający i dla kolejnych datagramów jest zwiększana. Flagi 3 bity tworzące dwie flagi używane przy fragmentacji datagramów. Fragmentacja będzie omówiona w dalszej części wykładu. Przesunięcie fragmentu 13 bitów, używane przy fragmentacji datagramów. Czas życia (TTL Time to Live) określa przez ile łączy może przejść datagram zanim zostanie odrzucony przez router. Jest to licznik, zmniejszany o 1 przez każdy router na drodze datagramu. Host docelowy nie sprawdza TTL. Jeśli TTL=0, wówczas pakiet jest odrzucany i wysyłany jest komunikat ICMP Time Expired TTL Expired. TTL zabezpiecza przed długimi pętlami. TTL dotyczy licznika połączeń ( skoków ) a nie routerów. Na przykład, jeśli komputer docelowy oddzielony jest od źródłowego przez 4 routery, to liczba skoków wynosi 5. Datagram wysłany między tymi komputerami z ustawionym TTL na 4 zostanie odrzucony przez czwarty router. Pole TTL zabezpiecza przed sytuacją, w której datagram wędrowałby w nieskończoność (lub zbyt długo ) przez sieć. TTL jest ustawiany przez system operacyjny lub aplikację, może wynosić np. 128, 254. Niektóre systemy filtrujące i modyfikujące datagramy (tzw. zapory sieciowe, ściany ogniowe, firewalls) potrafią modyfikować pole TTL. Protokół to jednobajtowe pole w nagłówku określa do jakiego protokołu warstwy wyższej należy przekazać datagram. Przykładowe wartości to 1 ICMP, 6 TCP, 17 UDP.

7 Suma kontrolna nagłówka liczona jest tylko dla nagłówka (nie dla danych). Cały nagłówek dzielony jest na słowa 16- to bitowe. W miejscu sumy kontrolnej wpisywane są same zera. Słowa te są dodawane a wynik jest uzupełniony do 1 (tzn. jedynki zamieniane na zera i odwrotnie). Wynik umieszczany jest w polu sumy kontrolnej. W miejscu docelowym suma kontrolna jest ponownie obliczana. Ponieważ nagłówek w miejscu docelowym zawiera wyliczoną w komputerze źródłowym sumę kontrolną, to komputer w miejscu docelowym powinien wyliczyć sumę składającą się z samych jedynek. Jeśli suma kontrolna w miejscu docelowym jest inna niż same jedynki, to znaczy, że nagłówek uległ uszkodzeniu. Wówczas oprogramowanie IP odrzuca odebrany pakiet i nie jest tworzony żaden komunikat o błędzie. Po przejściu przez router jest modyfikowane pole TTL, zatem suma kontrolna powinna ulec zmianie. Dopuszcza się odjęcie przez router jedynki od pola sumy kontrolnej (po uzupełnieniu bitów sumy do 1) lub dodanie jedynki bez zmiany bitów sumy zamiast ponownego wyliczania całej sumy kontrolnej. Adres źródła adres IP komputera źródłowego (chyba, że została zastosowana translacja adresów NAT). Adres docelowy adres IP komputera docelowego (chyba, że została zastosowana translacja adresów NAT). Opcje nagłówka IP Opcje to dodatkowe pola dołączane do 20 bajtowego nagłówka, zawierają opcjonalne, dodatkowe informacje, których długość może być różna. Opcje mogą zająć maksymalnie 40 bajtów i mogą zawierać m.in.: zapis trasy (zapisywany adres każdego routera, przez który przeszedł datagram) zapis czasu timestamp (zapisywany adres każdego routera, przez który przeszedł datagram oraz czas przejścia) swobodne punkty rutowania (rutowanie źródłowe) loose source routing (lista adresów IP, przez które musi przejść datagram) dokładne punkty rutowania (rutowanie źródłowe) strict source routing (podobnie jak poprzednio, tylko datagram musi przejść wyłącznie przez podane routery) Pole opcji zawsze zajmuje wielokrotność 4 bajtów, stąd czasem jest uzupełniane zerami. Opcja zapisu trasy Opcja RR (Record Route). Problemem jest maksymalna długość nagłówka, która ogranicza liczbę adresów IP w nagłówku do maksymalnie 9. Struktura zapisu opcji RR:

8 kod 1 bajt (typ opcji) RR=7 length 1 bajt ptr adres IP 1 (liczba bajtów 1 bajt (4 bajty) opcji, max=39) (numer bajtu wolnego miejsca na wpisanie kolejnego adresu IP, na początku = 4) adres IP 9 (4 bajty) Pytanie: jakie wartości może przyjmować wskaźnik ptr? Niektóre wersje programu ping mają opcje r, oznaczającą wymaganie zapisywania adresów routerów, przez które przechodzi datagram. Routery wpisują adresy interfejsu, poprzez który przekazują datagram dalej. Opcja zapis czasu (timestamp) Struktura zapisu opcji timestamp: kod 1 bajt (typ opcji) timestamp =0x44 length 1 bajt (liczba bajtów opcji, zwykle 36 lub 40) ptr 1 bajt (numer bajtu wolnego miejsca na kolejny wpis, na początku = 5) OF (4 bity) FL (4 bity) timestamp 1 (4 bajty) timestamp 9 (4 bajty) OF flaga (znacznik) przepełnienia. Jeśli router nie może dopisać swojego czasu, bo nie ma już miejsca, to powiększa OF o jeden. Na początku OF = 0. FL znacznik: 0 zapisuj tylko czasy (8 pozycji czterobajtowych, raczej nieużywane) 1 zapisuj adres IP i czas (4 wpisy po cztery + cztery bajty) 2 wysyłający wpisuje adresy IP, router wpisuje czas jeśli to jego adres IP. Czas powinien być wpisany jako liczba milisekund, które upłynęły od północy UTC, ale dopuszczalne są też inne zapisy czasu używane przez różne routery. Opcje routowania źródłowego Normalnie to routery wybierają dynamicznie trasę datagramów (na podstawie odpowiednich tabel, które zmieniają się również dynamicznie). Można jednak określić trasę datagramu w opcjach nagłówka IP. Rutowanie źródłowe dokładne wysyłający komputer określa dokładną trasę, jaką musi przejść datagram. Jeśli kolejne routery na tej trasie są przedzielone jakimś innym routerem,

9 to wysyła komunikat ICMP source route failed (typ 3 z dodatkowo ustawionym polem kod na wartość 3) i datagram jest odrzucany. Routowanie źródłowe swobodne wysyłający określa listę adresów IP, przez jakie musi przejść datagram, ale datagram może przechodzić również przez inne routery. Uwaga. Programy traceroute (Unix) i tracert (MS Windows) mają możliwość włączenia rutowania źródłowego z wyświetlaniem wyników przejścia datagramu po określonej trasie. Podobnie możliwość taką ma program ping. Fragmentacja datagramów IPv4 MTU (Maximum Transmission Unit) to największa porcja danych, jaka może być przesłana w ramce przez pewną sieć (lub połączone sieci) przy wykorzystaniu konkretnej technologii. Jeśli datagram IP jest większy niż wynika to z MTU dla warstwy łącza w danej technologii (np. dla Ethernet II MTU wynosi 1500 bajtów), to IP dokonuje fragmentacji dzielenia datagramu na mniejsze części. Różne zagadnienia związane z MTU (w tym typowe wartości MTU) opisuje RFC W systemie Unix informacje o MTU dla danego interfejsu (np. karty sieciowej) wyświetla polecenie netstat (polecenie to wyświetla jeszcze sporo innych informacji, polecenie to jest też w Microsoft Windows). Jeśli datagram IP przechodzi przez kilka sieci, kolejne MTU mogą być różne. Najmniejsze MTU po drodze nazywa się ścieżką MTU. RFC 1191 określa mechanizm ustalania ścieżki MTU. Fragmentacja IP może być wykonana na komputerze wysyłającym, bądź na którymś z routerów. Jeśli nastąpiła fragmentacja, to fragmenty docierają do miejsca docelowego, w którym oprogramowanie warstwy IP składa je z powrotem w pakiety oryginalnej wielkości. Fragmenty też mogą być dalej dzielone, informacje z nagłówka IP wystarczają do odtworzenia wyjściowych pakietów. Fragmenty stają się samodzielnymi pakietami, które są dostarczane przez oprogramowanie warstwy IP niezależnie tak jak normalne pakiety niepodzielone. Składanie fragmentów w całość odbywa się na komputerze docelowym. Pole identyfikator (16 bitów) w nagłówku IP zawiera numer wysłanego pakietu. Pole powinno być inicjowane przez protokół warstwy wyższej. Warstwa IP zwiększa identyfikator o 1 dla kolejnych pakietów. Pole to jest kopiowane do pola identyfikacja każdego fragmentu. Pole flagi (3 bity) : Bit 0: zarezerwowane, musi być zero Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. Jeśli bit 1 jest ustawiony (tzn. równy 1), to znaczy, że pakiet nie może być dzielony. Taki pakiet w przypadku konieczności dzielenia jest odrzucany i do nadawcy wysyłany jest komunikat ICMP (typ 3 z dodatkowo ustawionym polem kod na wartość 4).

10 W ostatnim fragmencie pakietu bit 2 jest wyzerowany (w pozostałych fragmentach jest ustawiony). Pole przesunięcie fragmentu zawiera informację o przesunięciu fragmentu względem początku oryginalnego pakietu. Przesunięcie wyrażane jest w blokach ośmiobajtowych, przesunięcie pierwszego fragmentu wynosi 0. Np. w sieci Ethernet II w części danych ramki można przesłać 1500 oktetów, czyli przy 20- bajtowym nagłówku w rzeczywistości na dane pozostaje 1480 bajtów. Stąd przesunięcie pierwszego fragmentu wynosi 1480 bajtów, czyli 185 bloków po 8 bajtów. Przesunięcie drugiego 1480 bloku danych wynosiłoby 370 itd. Jeśli zgubiony zostanie chociaż jeden fragment (i nie można odtworzyć oryginalnego pakietu), wówczas cały wyjściowy pakiet jest odrzucony. Jest to jeden z powodów, dla których fragmentacja pakietów jest uznawana za coś niekorzystnego. Jeśli np. segment TCP jest wysyłany w wielu pakietach, to utrata chociaż jednego fragmentu wymaga retransmitowania całego segmentu (TCP zawiera mechanizmy retransmisji segmentów, które nie dotarły do miejsca docelowego). Drugim powodem, dla którego fragmentacja IPv4 nie jest korzystna, jest fakt, że fragmentacja może bardzo obciążać routery. Fragmentację można wywołać np. przez wysyłanie większych komunikatów ICMP przy pomocy programu ping (opcja l). Ustawianie flagi DF może być wykorzystywane w programach, które ustalają ścieżkę MTU między dwoma komputerami. Ułatwieniem jest określenie dopuszczalnych wartości MTU (RFC 1191).

11 ICMP (Internet Control Message Protocol) Protokół ICMP opisują dokumenty RFC 792, 950, 1812, 112, 1191, 1256, Cel raportowanie routingu, dostarczanie informacji o błędach podczas przesyłania ze źródła do komputera docelowego. ICMP dostarcza też funkcji sprawdzających czy komputery mogą się ze sobą komunikować przez sieć z wykorzystaniem protokołu IP a także pomaga w automatycznej konfiguracji hostów. Komunikaty ICMP wysyłane są w pakietach IP. W efekcie w ramce znajduje się nagłówek IP, nagłówek ICMP oraz dane komunikatu ICMP. Struktura komunikatu ICMP Typ (1 oktet) Kod (1 oktet) Suma kontrolna (2 oktety) Dane charakterystyczne dla typu (różna długość) Typy komunikatów ICMP 0 Odpowiedź echa (echo reply) 3 Miejsce docelowe nieosiągalne (destination unreachable) 4 Tłumienie źródła (source quench) 5 Przekierowanie (redirect) 8 Żądanie echa (echo request) 9 Ogłoszenie routera (router advertisement) 10 Wybór routera (router selection) 11 Przekroczenie czasu (time exceeded) 12 Problem parametru (parameter problem) Żądanie i odpowiedź echa Cel wysłanie prostego komunikatu do węzła IP i odebranie echa tego komunikatu. Bardzo użyteczne przy usuwaniu problemów i naprawianiu sieci. Narzędzia takie jak ping oraz tracert i traceroute używają tych komunikatów ICMP do uzyskania informacji o dostępności węzła docelowego. Żądanie echa: Typ = 8 Kod = 0 Suma kontrolna (2 oktety) Identyfikator (2 oktety) Numer sekwencji (2 oktety) Opcjonalne dane (różna długość)

12 Odpowiedź echa: Typ = 0 Kod = 0 Suma kontrolna (2 oktety) Identyfikator Numer sekwencji Opcjonalne dane. W echo reply pola Identyfikator, Numer sekwencji oraz Opcjonalne dane są przepisywane z echo request.