IPv4: NAGŁÓWEK I OBSŁUGA FRAGMENTACJI
 

Powszechnie stosowaną wersją protokołu IP jest IPv4, czyli wersja 4. Oficjalną specyfikacją IPv4 jest dokument RFC 791. Format nagłówka IPv4 został zobrazowany poniżej. 

  

 

Pierwszy polem w nagłówku, jest 4 bitowe pole Version. Dla IPv4 posiada ono wartość 4. Kolejnym polem jest 4 bitowe pole IHL (Internet Header Length). Określa ono długość nagłówka IPv4 wyrażoną w słowach 4 oktetowych. Minimalna długość nagłówka IPv4 (bez opcji) to 20 oktetów. Pole IHL posiada wtedy wartość 5 (5 * 4 oktety = 20 oktetów). Maksymalna długość nagłówka z dodatkowymi opcjami, to 60 oktetów (15 * 4 oktetów = 60 oktetów). Wynika to z tego, że na 4 bitach możemy zapisać tylko wartości z przedziału od 0 do 15.

8 bitowe pole DSCP (Differentiated Services Code Point) wykorzystywane jest przez mechanizmy zapewniające odpowiednią jakość usługi (QoS - Quality of Service). Więcej o tym polu będzie w innym artykule.

Pole Total Length to 16 bitowe pole określające maksymalną długość całego pakietu IP w oktetach (nagłówek razem z danymi). Korzystając z pola IHL oraz Total Length w łatwy sposób można określić początek i koniec danych pakietu IP. Jest to istotne szczególnie wtedy, kiedy warstwa niższa dodaje do danych wypełnienie, aby utrzymać minimalną długość ramki (np. Ethernet, gdzie ramka musi zawierać minimum 46 oktetów danych, podczas gdy cały pakiet IP może być mniejszy). Maksymalna długość całego pakietu IPv4 razem z nagłówkiem to 65535 oktetów, przy czym pamiętać należy o ograniczeniu związanym z MTU. Jeśli MTU będzie mniejsze od wielkości całego pakietu, to dojdzie do fragmentacji lub pakiet zostanie odrzucony. W przypadku IPv4 minimalna wymagana wielkość MTU to 576 oktetów.  


Podczas procesu enkapsulacji, protokół IP zwraca uwagę na wartość MTU (Maximum Transfer Unit) interfejsu wyjściowego LNI (Local Network Interface). MTU określa maksymalną ilość oktetów, jaką może przyjąć protokół warstwy niższej. Jest to maksymalna wielkość całego pakietu IP (nagłówek razem z danymi). Jeżeli MTU LNI jest mniejsze od pakietu, to protokół IP musi dokonać fragmentacji. W przypadku gdy fragmentacja nie jest możliwa, pakiet zostanie odrzucony.

 

 

Sprawdzenie MTU LNI realizuje Internet Module, zajmujący się obsługą protokołu IP. Dokonuje tego za każdym razem, kiedy pakiet jest przekazywany do kolejnego segmentu sieci. Każde LNI może obsługiwać różne wartości MTU. Zwykle, wynika to z obsługi różnych typów technologii, wykorzystywanych do transmisji w lokalnych segmentach sieci. 


16 bitowe pole Identification jednoznacznie określa każdy wysłany pakiet. Najczęściej, wartość tego pola rośnie o jeden, z każdym kolejno wysłanym pakietem. Pole to także wykorzystywane jest podczas procesu fragmentacji. Jego wartość jest kopiowana do każdego fragmentu pakietu. 

Pole Flags jest 3 bitowym polem. Pierwszy bit zawsze ustawiony jest na 0. Drugi bit to flaga DF (Don’t Fragment). Jeżeli ustawiona jest na 1, to pakiet nie może podlegać fragmentacji. W przypadku natrafienia na mniejsze MTU, pakiet z ustawionym bitem DF zostanie odrzucony. Trzeci bit jest flagą MF (More Fragments). Wartość 1 bitu MF oznacza, że fragment nie jest jeszcze ostatnim fragmentem pakietu. Budowa pola Flags została pokazana poniżej.

Pole Fragment Offset jest 13 bitowym polem przesunięcia, wykorzystywanym do złożenia pakietu. Zawiera przesunięcie fragmentu w stosunku do początku oryginalnego pakietu.

Jeżeli pakiet posiada zerową wartość pola Fragment Offset i flagę MF ma ustawioną na 0, to wiadome jest, że nie podlegał on fragmentacji. W przypadku IPv4, fragmentacja może zostać wykonana zarówno przez nadawcę, jak i na każdym kolejnym węźle na drodze pakietu. Dopuszcza się także przeprowadzenie fragmentacji na już wcześniejszych fragmentach. Informacje zawarte w nagłówku IP, są wystarczające do złożenia wyjściowego pakietu - nawet przy wielokrotnej fragmentacji. Złożenia fragmentów wykonuje dopiero odbiorca i zajmuje się tym warstwa IP (jest to proces całkiem przeźroczysty dla wyższych warstw).

Kiedy dochodzi do fragmentacji, każdy fragment staje się nowo żyjącym pakietem i jest niezależnie routowany przez sieć. W związku z tym, następuje też odpowiednie dostosowanie innych pól, jak np. wartość pola Total Length - wskazuje ona na wielkość fragmentu, który stał się niezależnym pakietem.

Fragmentacja sama w sobie nie jest powołana. Jeżeli zostanie zagubiony jeden fragment pakietu, trzeba niestety przesłać cały pakiet jeszcze raz. Protokół IP tego nie zrealizuje - nie posiada on wbudowanych funkcji retransmisji. Fragmenty sprawiają też problemy przy filtrowaniu ruchu. Kiedy dojdzie do fragmentacji, tylko w pierwszym fragmencie pakietu zawarte są informacje na temat nagłówka protokołu warstwy wyższej, gdzie można znaleźć np. numery portów UDP/TCP - fragmentacja odbywa się względem pola danych protokołu IP. Wszystkie fragmenty oprócz ostatniego przenoszą dane w wielokrotności 8 oktetów.

Pole Time to Live (skrótowo TTL) zapobiega krążeniu pakietów IP w pętli. Określa ono maksymalną liczbę routerów, przez które może przejść pakiet. Początkową wartość temu polu nadaje nadawca, a następnie jest ona zmniejszana o 1 przez każdy węzeł na drodze pakietu. Jest to pole 8 bitowe, więc maksymalna wartość TTL może wynosić 255. W zależności od implementacji, najczęściej wstawianymi wartościami początkowymi są 64, 128 lub 255. Kiedy pole to osiągnie wartość 0, pakiet IP jest usuwany z sieci, a nadawca stosownie informowany o tym fakcie przez protokół ICMP.

Pole Protocol wykorzystywane jest podczas procesu dekapsulacji. Wskazuje ono protokół warstwy wyższej, którego dane są przenoszone w pakiecie IP (np. 1 to ICMP, 6 to TCP, 17 to UDP). Jest to pole 8 bitowe.

16 bitowe pole Header Checksum, jest sumą kontrolną samego nagłówka protokołu IP. Cały nagłówek dzielony jest na 16 bitowe słowa. Algorytm wykonuje ich sumę (pole Header Checksum równe jest zero podczas wyliczania sumy przez nadawcę). Następnie algorytm realizuje dopełnienie sumy (odwrócenie wartości - zera stają się jedynkami, a jedynki zerami) i wstawia uzyskaną wartość w polu Header Checksum. Kiedy odbiorca odbierze pakiet z prawidłowym nagłówkiem, to wyliczona suma kontrolna z dopełnieniem powinna zawierać same zera, a bez dopełnienia same jedynki (pole Header Checksum nie ma już wartości zerowej). Jeżeli tak nie jest, pakiet IP powinien zostać usunięty.

Pole Source Address to 32 bitowe pole w którym znajduje się adres IP nadawcy pakietu.

Pole Destination Address to 32 bitowe pole w którym znajduje się adres IP odbiorcy pakietu.

Ostatnim polem nagłówka jest pole Options, zawierające opcjonalnie dodatkowe opcje, jakie może przenosić nagłówek protokołu IP. Więcej o opcjach zostanie przedstawione w innym artykule. Zawsze, kiedy opcje nie kończą się na granicy 32 bitów, wstawiane jest wypełnienie Padding składające się z samych 0. Wynika to z faktu, że pole długości nagłówka IP jest wielokrotnością 4 oktetów. Pola Options i Padding są opcjonalne i nie muszą znajdować się w pakiecie IPv4.


Zapraszamy do kontaktu drogą mailową This email address is being protected from spambots. You need JavaScript enabled to view it. lub telefonicznie +48 797 004 932.