Protokół ARP (ang. address resolution protocol) został zaprojektowany w celu odwzorowania adresów IP na adres sprzętowy. Z zasady działania sieci komputerowych, a właściwie ze stosu protokołów TCP/IP, ISO/OSI, wynika sposób enkapsulacji w ramach przechodzenia danych przez poszczególne warstwy modelu ISO/OSI, czy też TCP/IP. W trakcie enkapsulacji pakietów pochodzących z warstwy sieciowej (L3) do nagłówka warstwy łącza danych wpisywany jest adres sprzętowy odbiorcy ramki. Jeśli pakiet jest wysyłany do komputera znajdującego się w sieci lokalnej, to w pole to wpisywany jest MAC-adres interfejsu komputera docelowego. Jeśli pakiet jest wysyłany do komputera znajdującego się w odległej lokalizacji, to w pole adresu sprzętowego ramki wpisywany jest MAC adres routera.

O ile MAC adres nadawcy ramki jest znany, o tyle adres odbiorcy może być nieznany. Przed wysłaniem ramki pole przeznaczone na ten adres musi zostać uzupełnione.

Zadaniem protokołu ARP jest zatem odwzorowanie 32 bitowego adresu IP (w IPv4) w 48 bitowy adres sprzętowy.

Załóżmy, że komputer X chce przesłać dane do komputera Y.

Adresy sprzętowy przechowywany jest w tablicy ARP, która jest swego rodzaju pamięcią podręczną. Przed wysłaniem ramki host sprawdza tablicę ARP, czy znajduje się już tam adres hosta docelowego. Jeśli jest już tam ten adres wpisany, to ramka jest wysyłana.

Natomiast jeśli nie ma tam wpisanego MAC adresu to komputer X wysyła żądanie przesłania MAC adresu komputera Y, na adres rozgłoszeniowy 255.255.255.255. Pakiet taki zostanie odebrany przez wszystkie komputery w sieci. Komputer Y, którego adres IP został przypisany do poszukiwanego MAC adresu odpowie poprzez wysłanie swojego adresu sprzętowego. Adres ten zostanie wpisany w tablicę ARP hosta X, który wysyłał żądanie ARP. Dla zmniejszenia nakładów potrzebnych do ustalenia MAC adresu komputera X, który żądał przesłania adresu również komputer Y, który odpowiedział wysyłając swój adres sprzętowy zapisuje sobie adres fizyczny komputera X.

W ten sposób w przypadku potrzeby późniejszego wysyłania pakietów do tego samego hosta, komputer wysyłający ma już w pamięci podręcznej wpisany ten adres.

Gdyby za każdym razem, każdy komputer wysyłał taki żądanie na adres rozgłoszeniowy, to nastąpiłoby znaczne obciążenie sieci. Z tego względu algorytm ten ma kilka udoskonaleń. Jednocześnie z przesłaniem żądania ARP wszystkie komputery, które to żądanie otrzymały zapisują sobie MAC adres nadawcy takiego żądania (komputera X) do tablicy ARP oraz odpowiedź komputera Y. Zwykle pierwsze zapytanie ARP jest wysyłane tuż po uruchomieniu komputera. Gdy poszukiwanego komputera nie ma w sieci lokalnej na zapytanie odpowiada router podając MAC adres swojego interfejsu.

Na slajdzie został pokazany zrzut z ekranu uzyskany po wywołaniu programu arp dla stacji roboczej działającej pod system operacyjnym UNIX. Jak widać na załączonym listingu w pamięci podręcznej przechowywane są dane dotyczące interfejsu adresu IP. Najważniejsze z nich to informacje o adresie IP (w przykładzie jest podany jego symboliczny odpowiednik) oraz odpowiadającym mu adresie sprzętowym.

Protokół ARP służył do znalezienia adresu sprzętowego dla hosta o znanym numerze IP. W hostach starszej generacji (ale również obecnie), w maszynach bezdyskowych istniał problem braku adresu IP maszyny po restarcie. Większość maszyn ma zwykle zapisany na dysku swój adres IP. Ze względu na brak takiej możliwości w urządzeniach bezdyskowych należało jakoś ten adres uzyskać z odpowiedniego serwera. Zadaniem takim był obarczony protokół wstecznego rozwiązywania adresów RARP (ang. Reverse Address Resolution Protocol). Protokół ten pozwala również zapytywać nie tylko o adres IP danej stacji wysyłającej to żądanie, ale również inne hosty. Na zapytania bezdyskowych stacji roboczych odpowiada dedykowany serwer RARP.

Protokoły ARP i RARP mają taki sam format pakietu. Różnią się tylko wartościami wpisów w poszczególne pola.

Poszczególne pola pakietu mają następujące znaczenie: Typ sprzętu - 2B - określa typ interfejsu sieciowego stosowanego przez nadawcę. W przypadku interfejsu Internet wpisana jest tam wartość 1. Typ protokołu - 2B - podaje typ protokołu, który wysłał żądanie (odpowiedź). W przypadku protokołu IP wpisana jest tam wartość 0x0800. HLen - 1B - Długość adresu sprzętowego, w przypadku protokołu Ethernet 48 bitów. PLen - 1B - długość adresu protokołu warstwy sieciowej (L3), który został wyspecyfikowany w polu Typ protokołu. W przypadku IPv4 32 bity.

Operacja (Działanie) - 2B - identyfikuje czy jest to żądanie, czy też odpowiedź protokołu ARP lub RARP. Poszczególne wartości oznaczają: 1 - żądanie ARP, 2 - odpowiedź ARP, 3 - żądanie RARP, 4 - odpowiedź RARP

Adres sprzętowy nadawcy (ang. Sender hardwer address) - MAC adres urządzenia nadającego. Adres protokołowy nadawcy - logiczny adres urządzenia nadającego w protokole warstwy sieciowej (L3), wskazanym w polu Typ protokołu. Adres sprzętowy odbiorcy - podaje MAC adres urządzenia docelowego, pod warunkiem, że jest znany przez nadawcę. Adres protokołowy odbiorcy - logiczny adres urządzenia docelowego w protokole warstwy sieciowej (L3), wskazanym w polu Typ protokołu.

W trakcie wymiany komunikatów pomiędzy urządzeniami następuje wypełnianie brakujących pól: adresu sprzętowego lub adresu logicznego w zależności od typu protokołu. Adresy nadawcy zamieniane są z adresem odbiorcy. Zmieniane jest również pole Operacja i wstawiana jest tam wartość identyfikująca odpowiedź.

W przypadku wysyłania pakietu ARP na adres rozgłoszeniowy w pole adresu sprzętowego wpisywana jest wartość sprzętowego adresu rozgłoszeniowego. W przypadku protokołu Ethernet jest to wartość MAC FF:FF:FF:FF:FF:FF.

Protokół RARP posiada niestety kilka istotnych niedociągnięć, które wyeliminowały go z powszechnego użycia. Istotnym ograniczeniem jest brak możliwości przesyłania innych parametrów sieci, np. natmaski. W związku z tym stał się bezużyteczny w sieciach o adresacji bezklasowej.

Innym bardzo uciążliwym mankamentem jest identyfikowanie hosta tylko po MAC adresie. Zatem jest bezużyteczny w sieciach, w których adresy sprzętowe są przydzielane w sposób dynamiczny.

Protokół ten ma obecnie marginalne znaczenie również ze względu na fakt, że nie zwraca wielu innych, bardzo potrzebnych informacji o sieci. Rozwinięciem tego protokołu są BOOTP oraz DHCP, które zastąpiły RARP.

Innym protokołem, który umożliwia dynamiczne przydzielenie adresów jest protokół BOOTP (ang. Bootstrap Protocol). Protokół ten był zaprojektowany w celu zastąpienia protokołu RARP, ze względu na istotne braki tego ostatniego. M.in. protokół BOOTP może być używany w sieciach, w których adresy sprzętowe są przydzielane w sposób dynamiczny, choć tutaj również ten protokół nie spisuje się najlepiej.

Protokół BOOTP używa w warstwie transportowej do komunikacji protokołu UDP.

Pakiet protokołu BOOTP zawiera 15 pól. Długość tych pól nie ulega zmianie. Ułatwia to znacznie kwestie związane z implementacją protokołu. Format pakietu protokołu BOOTP został przedstawiony na rysunku. Znaczenie poszczególnych pól jest następujące:

Op - 1B - typ wiadomości, która będzie przesyłana. Może być to żądanie przesłania pakietu BOOTP (BOOTREQEST) lub odpowiedź na takie żądanie (BOOTREPLY). HType - 1B - typ adresu sprzętowego. HLen - 1B - długość adresu sprzętowego. Hops - określa liczbę serwerów, przez które komunikat był już przesyłany. Na początku klient ustawia wartość tego pola na 0. W czasie przesyłania tego komunikatu do kolejnych serwerów liczba ta (Hops) jest zwiększana o 1. XID - 4B - generowana losowo liczba całkowita, używana do identyfikacji żądania wysłanego przez klienta z odpowiedzią na to żądanie Sekundy - 2B - pole przechowujące czas wyrażony w sekundach od uruchomienia klienta. Nie używane - 2B - pole nie używane

Ciaddr - 4B - pole na adres IP klienta. Jeśli klient nie zna jeszcze swojego adresu, to w to pole wstawiana jest wartość 0. Jeżeli znany jest adres to znajduje się tam jego wartość.

Yiaddr - 4B - przydzielony adres klienta. Pole adresu ustawiane przez serwer. Siaddr - 4B - adres IP serwera, który jest używany w procesie uruchamiania. Giaddr - 4B - adres IP bramy. Chaddr - 16B - adres sprzętowy klienta. Nazwa serwera - 64B - pole ustawiane przez serwer. Nazwa pliku ładującego - 128B. Plik używany przy starcie. Dane specyficzne dla producenta.

Protokół ten nie został zaprojektowany do dynamicznego przydzielania adresów. W związku z tym administrator musi stworzyć plik konfiguracyjny dla każdego urządzenia. Plik ten zawiera odpowiednie parametry sieci. Administrator musi dodawać do niego w sposób ręczny hosty oraz zarządzać bazą danych protokołu BOOTP. Relacja pomiędzy liczbą adresów a liczbą hostów jest jak 1:1. Innymi słowy każdy z hostów, któremu będzie przydzielany adres IP musi mieć profil BOOTP z przypisanym dla niego adresem IP. Każdy z profili musi mieć różne adresy IP, żeby uniknąć przypisania jednocześnie dwóm różnym hostom takich samych adresów logicznych.

Protokół DHCP (ang. Dynamic Host Configuration Protocol) bazuje na BOOTP i jest jego ulepszoną wersją.

Standard tego protokołu został opublikowany w roku 1993 w dokumencie RFC 2131.

Do współpracy z nowszą wersją protokołu IPv6 został opracowany protokół DHCPv6. Standard tego protokołu został opublikowany w dokumencie RFC 3315

Oprócz dostarczania adresu IP protokół DHCP został zaprojektowany również do przekazywania innych cennych parametrów konfiguracyjnych. Te dodatkowe funkcjonalności zostały opisane w dokumencie RFC 2132.

Tabela przedstawia porównanie cech protokołów DHCP i BOOTP.

Serwer DHCP może przydzielać adresy IP na trzy różne sposoby:

Alokacja ręczna – adres IP dla klienta jest przydzielany przez administratora. Protokół DHCP przesyła adres do klienta. Alokacja automatyczna – protokół DHCP przypisuje klientowi stały adres IP. Alokacja dynamiczna – protokół DHCP dzierżawi klientowi adres IP na pewien ograniczony odcinek czasu.

DHCP DISCOVER - poszukiwanie serwera DHCP

DHCP Offer - oferta DHCP DHCP Request - żądanie DHCP DHCP Acknowledge - odpowiedź na żądanie

Działanie protokołu DHCP składa się z kilku faz:

Po uruchomieniu stacji klienckiej rozpoczyna się faza inicjacji. Klient rozgłasza w sieci komunikat poszukiwania serwera DHCP (DHCPDISCOVER). Jeśli serwer DHCP znajduje się w innej sieci, to musi być zapewnione przesyłanie tego komunikatu przez router. Serwery, które otrzymały komunikat DHCPDISCOVER i mogą przydzielić adres IP wysyłają komunikat oferty DHCPOFFER. W komunikacie tym zawarte są: adres IP i dane konfiguracyjne. Klient może otrzymać odpowiedzi od różnych serwerów musi zatem wybrać jedną z tych ofert. Po wybraniu oferty, klient wysyła do wybranego serwera komunikat żądania (DHCPREQUEST) prosząc o dane konfiguracyjne.

Serwer potwierdza otrzymanie żądania wysyłając komunikat pozytywnego potwierdzenia (DHCPACK). Komunikat ten zawiera informacje na temat dzierżawy oraz informacje konfiguracyjne.

Klient po otrzymaniu potwierdzenia wchodzi w stan powiązania. W stanie tym klient ma przypisany adres IP danej sieci. Klient ma przypisane trzy liczniki czasu dla informacji o dzierżawie (wygaśnięcie, odnowienie, ponowne nawiązanie dzierżawy) Klient ma ustawione parametry dzierżawy i w zależności od tych parametrów po upływie 50% czasu dzierżawy lub też dopiero po upłynięciu dzierżawy próbuje odnowić dzierżawę. Wysyła w tym celu do serwera udzielającego dzierżawy adresu IP komunikat DHCPREQUEST. Możliwe jest też zwolnienie adresu IP przed czasem. Klient wysyła wtedy komunikat DHCPRELEASE.

Klient po wysłaniu żądania do serwera wchodzi w stan odnowienia w oczekiwaniu na odpowiedź serwera. Serwer przyjmując żądanie może przyjąć to żądanie - wysyła wtedy komunikat DHCPACK. Jeśli serwer odrzuci żądanie przedłużenia dzierżawy, to wysyła komunikat DHCPNACK. Po odrzuceniu żądania klient przechodzi do stanu inicjacji (zwalnia również adres IP).

Jeśli klient nie otrzyma od serwera odpowiedzi w określonym czasie, to przechodzi do rozgłaszania komunikatu DHCPREQUEST do wszystkich serwerów DHCP. Jeśli klient otrzyma pozytywną odpowiedź to przechodzi do stanu powiązania.

Na slajdzie została przedstawiona sekwencja wymiany komunikatów DHCP pomiędzy klientem a serwerem:

Klient wysyła komunikat DHCPDISCOVER Serwer(y) odpowiadają komunikatem DHCPOFFER Klient po wybraniu oferty wysyła komunikat DHCPREQUEST Serwer potwierdza wysyłając komunikat DHCPACK

Format pakietu DHCP jest prawie identyczny z formatem pakietu BOOTP.

Różnica występuje tylko na dwóch polach: Pole Flagi — 2B - jest odpowiednikiem nie używanego pola w pakiecie BOOTP, w którym wszystkie bity pola mają wartość 0. W pakiecie DHCP najstarszy bit tego pola ma wartość 1, zaś wszystkie pozostałe mają wartość 0. Wartość najbardziej znaczącego bitu oznacza komunikat rozgłoszeniowy. Klient DHCP może zażądać od serwera DHCP wysłania odpowiedzi przy pomocy komunikatu rozgłoszeniowego IP. Pole Opcje — 64B jest odpowiednikiem pola Dane producenta w komunikatach BOOTP. Pole to zawiera dodatkowe dane konfiguracyjne, takie jak: okres dzierżawy, maska podsieci dla lokalnej sieci, adres IP serwera czasu, adres IP serwera domeny oraz rozmiar pliku inicjującego.

Pozostałe pola mają takie samo znaczenie jak w BOOTP

Wypełnienie (kod opcji 0) — dopełnia poniższe pola do granic pełnych słów.

Maska podsieci (kod opcji 1) — przedstawia maskę podsieci dla danej podsieci fizycznej. Przesunięcie czasu (kod opcji 2) — oznacza czas UCT (Universal Coordinated Time) w sekundach. Router (kod opcji 3) — wymienia adresy IP wszystkich routerów dostępnych w podsieci. Serwery czasu (kod opcji 4) — wymienia adresy IP wszystkich serwerów czasu dostępnych dla klienta.

Serwery nazw (kod opcji 5) — wymienia adresy IP wszystkich serwerów nazw dostępnych dla klienta.

Serwery DNS (kod opcji 6) — wymienia adresy IP wszystkich serwerów DNS dostępnych dla klienta. Serwery dziennika (kod opcji 7) — wymienia adresy IP wszystkich serwerów dziennika dostępnych dla klienta. Serwery cookie (kod opcji 8) — wymienia adresy IP wszystkich serwerów cookie dostępnych dla klienta. Serwery LPR (kod opcji 9) — wymienia adresy IP wszystkich serwerów drukarek wierszowych (Line PRinter) dostępnych dla klienta.

Serwery Impress (kod opcji 10) — wymienia adresy IP wszystkich serwerów Imagen Impress dostępnych dla klienta.

Serwery lokalizacji zasobów (kod opcji 11) — wymienia adresy IP wszystkich serwerów lokalizacji zasobów dostępnych dla klienta. Nazwa hosta (kod opcji 12) — przedstawia nazwę klienta, która może mieć długość do 63 bajtów. Rozmiar pliku inicjującego (kod opcji 13) — przedstawia rozmiar domyślnego pliku inicjującego klienta.

Plik zrzutu zawartości (kod opcji 14) — przedstawia ścieżkę do pliku, do którego powinien zostać zrzucony obraz pamięci klienta w przypadku jego załamania. Ten plik jest używany w sytuacjach, gdy domyślny plik inicjujący klienta staje się niedostępny z uwagi na awarię serwera.

Nazwa domeny (kod opcji 15) — przedstawia nazwę domeny DNS, która powinna być użyta przez klienta do rozwiązania nazwy DNS hosta. Serwer wymiany (kod opcji 16) — przedstawia adres IP serwera wymiany dostępnego dla klienta. Główna ścieżka dostępu (kod opcji 17) — przedstawia ścieżkę do dysku systemowego klienta. Ścieżka do rozszerzeń (kod opcji 18) — oznacza plik zawierający informacje, podobnie jak pole danych producenta w komunikacie odpowiedzi BOOTP. Plik można pobrać za pomocą TFTP.

Częstym przypadkiem jest stawianie serwerów DHCP w jednej z podsieci. Komputery, które chcą uzyskać pakiet z serwera DHCP muszą skorzystać z routera pośredniczącego (bramy). Uzyskanie parametrów konfiguracyjnych odbywa się w następujących fazach:

1. Klient DHCP wysyła przez port 68 TCP żądanie parametrów konfiguracyjnych. 2. Brama przekazująca przechwytuje żądanie i rozpoznaje podsieć, do której zadanie trzeba przesłać. 3. W docelowej podsieci jeden lub kilka serwerów DHCP odbierze rozgłoszenie i może odpowiedzieć klientowi, przekazując parametry konfiguracyjne (w tym podając dostępny adres IP). 4. Brama przekazująca DHCP/BOOTP przesyła odpowiedzi do klienta, który wybiera jedną z nich. Następnie klient wysyła komunikat żądania od odpowiedniego serwera i otrzymuje dzierżawę, która ponownie zostaje przekazana przez bramę.

W module tym zostały opisane metody uzyskiwania adresu IP.

Metoda statyczna wymaga kontaktu użytkownika z administratorem w celu uzyskania parametrów do pliku konfiguracyjnego. Metody automatycznego pozyskiwania adresu takie jak RARP, BOOTP, czy DHCP mogą to zadanie ułatwić. Obecnie najszerzej jest stosowana metoda DHCP. Wraz z wprowadzaniem IPv6 będzie również stosowany protokół DHCPv6