BOOTP (BOOTstrap Protocol)

BOOTP – protokół ładowania początkowego – powstał w 1985 r. jako alternatywa RARP dla urządzeń bezdyskowych: stacji, X-terminali, ruterów czy koncentratorów, które musiały mieć adres IP i często oprogramowanie operacyjne ładowane przez sieć. BOOTP może także dostarczać wiele innych ważnych informacji, takich jak adres IP rutera, maska podsieci klienta lub adresy IP serwerów DNS, NTP, wydruków albo też adresy komputerów używanych jako zdalne terminale. Umożliwia wygodne gromadzenie adresów IP na serwerze centralnym, a nie na każdej stacji roboczej. Wyposażenie w dysk nie stanowi kryterium stosowania tego protokołu. Systemy bezdyskowe muszą przechowywać w swojej pamięci kilka stałych protokołów: BOOTP, UDP, IP, TFTP, i sterownik karty sieciowej. Takie urządzenia początkowo nie znają adresu serwera, skąd mogłyby pobrać oprogramowanie sieciowe i swój adres IP.

Protokołem transportowym dla BOOTP jest UDP. Dzięki temu zapytania i odpowiedzi BOOTP mogą być przetwarzane, w przeciwieństwie do RARP, przez rutery lub przełączniki z modułem trasowania.

Znaczenia pól pakietu BOOTP są następujące:

1. Code – kod operacji: 1 = zapytanie, 2 = odpowiedź;
2. Hwtype – typ sprzętu (przykłady: 1=Ethernet 10 Mb/s, 6=IEEE 802);
3. Hlength – długość adresu sprzętowego podawana w bajtach (dla Ethernetu i Token Ring wynosi 6);
4. Hops – liczba skoków. Klient wpisuje 0. Jeśli serwer BOOTP, który otrzymał zapytanie, przekazuje go innemu urządzeniu, wpisuje w to pole 1 itd… Jednak zawartość tego pola nie może przekroczyć 3;
5. Transaction ID – identyfikator operacji, który na stacjach bezdyskowych umożliwia kojarzenie par zapytanie–odpowiedź. Wpisuje go klient i wysyła wiadomość do serwera. Czyni to przy każdym zapytaniu;
6. Seconds – czas rozpoczęcia procesu ładowania (BOOT). Wpisuje go klient po zainicjowaniu procesu;
7. Flags – pole flag. Jedynka na pierwszej pozycji oznacza rozgłaszanie, pozostałe pozycje muszą być zerami;
8. Client IP Address – adres wpisywany przez klienta. Zawiera 0.0.0.0.0 lub adres IP, jeśli go klient zna;
9. Your IP Address – adres klienta, który podał 0.0.0.0. Wpisuje serwer;
10. Server IP Address – adres wpisany przez serwer;
11. Router IP Address – adres wpisany przez ruter, jeśli ładowanie odbywa się za jego pośrednictwem. Wtedy też jest modyfikowane pole Hops;
12. Client hardware address – adres sprzętowy wpisywany przez klienta, używany przez serwer BOOTP do identyfikowania klienta przed ładowaniem;
13. Server host name – nazwa serwera, który wpisuje nazwę pliku do załadowania;
14. Boot file name – pełna ścieżka pliku do załadowania;
15. Vendor specific area – przestrzeń dla informacji uzupełniających. Rozpoczyna się ona 4-bajtowym znacznikiem stanu, od którego zależy format następujących po nim pól. Liczba 99.130.83.99 w polu znacznika sygnalizuje przenoszenie jakiejś wiadomości. Wtedy za tym polem znajdą się kolejno następujące: Typ, opcjonalnie Kod, Długość w bajtach, Wiadomość i znak końca (255). Tą drogą można otrzymać maskę podsieci (lepiej niż przez CMIP), dokładny czas, adresy ruterów, serwerów DNS, NTP i wydruków oraz dziesiątki innych wiadomości (RFC 1553 i 2132).

Klient BOOTP używa do komunikacji z serwerem numeru portu = 68, a serwer BOOTP numeru portu = 67. Klient rozgłasza początkowo zapytanie, kierując je pod adresem 255.255.255. 255. W pole swojego adresu wpisuje zwykle 0.0.0.0. Serwer nie musi znajdować się w tej samej sieci co klient i wtedy do procesu ładowania włącza się ruter (port 67). Kiedy po wstępnych procedurach ma dojść do ładowania pliku, BOOTP do transmisji tego pliku z serwera używa protokołu TFTP. W tym wypadku klient będzie obsługiwany na numerze portu = 69.

Tworzenie serwera BOOTP jest znacznie prostsze nie serwera RARP, ponieważ zapytania i odpowiedzi BOOTP są przenoszone w datagramach UDP, a nie w specjalnych ramkach, nie przetwarzanych przez rutery. Te ostanie mogą z powodzeniem pełnić dla serwerów rolę agentów i kierować zapytania klientów do odległych serwerów BOOTP.

BOOTP jest opisany w RFC 951 – Bootstrap Protocol i RFC 1497 – BOOTP Vendor Information Extensions. Są również rozszerzenia, które umożliwiają współpracę tego protokołu z DHCP – obydwa protokoły posługują się tą samą ramką.

Zostały one przedstawione w RFC 1542 – Clarifications and Extensions for the Bootstrap Protocol, poszerzającym RFC 951, i w RFC 1533 – DHCP Options and BOOTP Vendor Extensions zastępującym RFC 1497. W RFC 1533 zostało m.in. zwiększone pole Vendor-specific area do 312 bajtów. RFC 2132 DHCP Options and BOOTP Vendor Extensions już zastępuje wspomniane RFC 1533.