DHCP (ang. Dynamic Host Configuration Protocol – protokół dynamicznego konfigurowania hostów) – protokół komunikacyjny umożliwiający hostom uzyskanie od serwera danych konfiguracyjnych, np. adresu IP hosta, adresu IP bramy sieciowej, adresu serwera DNS, maski podsieci. Protokół DHCP jest zdefiniowany w RFC 2131 ↓ i jest następcą BOOTP. DHCP został opublikowany jako standard w roku 1993.
W kolejnej generacji protokołu IP, czyli IPv6, jako integralną część dodano nową wersję DHCP, czyli DHCPv6. Jego specyfikacja została opisana w RFC 3315 ↓.
W sieci opartej na protokole TCP/IP każdy komputer ma co najmniej jeden adres IP i jedną maskę podsieci; dzięki temu może się komunikować z innymi urządzeniami w sieci.
Komunikaty[1]
- DHCPDISCOVER – klient DHCP wysyła ten komunikat w trybie broadcast, aby znaleźć serwer DHCP,
- DHCPOFFER – serwery DHCP odpowiadają tym komunikatem na komunikat DHCP, oferując dzierżawę adresu IP klientowi,
- DHCPREQUEST — klient akceptuje pierwszą ofertę wysłaną przez DHCPOFFER, która oferowała dzierżawę adresu IP, żąda tego adresu,
- DHCPACK — jeżeli adres, którego żąda klient może być użyty, to serwer akceptuje to żądanie wysyłając właśnie ten komunikat
- DHCPNAK — jeżeli adres, którego żąda klient nie może być użyty, to serwer wysyła komunikat DHCPNAK, po tym klient musi rozpocząć cały proces komunikacji z serwerem od nowa,
- DHCPDECLINE — jeżeli klient określi, że oferowana mu konfiguracja parametrów jest nieprawidłowa, wysyła serwerowi komunikat DHCPDECLINE, po tym klient musi rozpocząć cały proces komunikacji z serwerem od nowa,
- DHCPRELEASE — klient wysyła ten komunikat, aby odrzucić przydzielony mu przez serwer adres IP i anulować dzierżawę adresu IP,
- DHCPINFORM — nowy typ komunikatu, zdefiniowany w RFC-2131, komunikat ten używany jest by uzyskiwać opcje DHCP.
Nagłówek DHCP
00 – 07 | 08 – 15 | 16 – 23 | 24 – 31 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
operacja | typ sprzętu | długość adresu sprzętowego | liczba skoków | ||||||||||||||||||||||||||||
xid (identyfikator transakcji) | |||||||||||||||||||||||||||||||
liczba sekund | flagi | ||||||||||||||||||||||||||||||
adres IP klienta | |||||||||||||||||||||||||||||||
przydzielony adres IP klienta | |||||||||||||||||||||||||||||||
adres IP serwera | |||||||||||||||||||||||||||||||
adres IP bramki (routera) | |||||||||||||||||||||||||||||||
adres sprzętowy klienta (16 oktetów) | |||||||||||||||||||||||||||||||
nazwa serwera (64 oktety) | |||||||||||||||||||||||||||||||
plik startowy (128 oktetów) | |||||||||||||||||||||||||||||||
opcje producenta (długość zmienna) |
- Operacja
- Typ nagłówka. 1 = BOOTREQUEST, 2 = BOOTREPLY
- Typ sprzętu
- Liczba z zakresu 1-28 oznaczająca typ sprzętu (karty sieciowej). Dla sieci ethernetowej przyjmuje wartość 1.
- Długość adresu sprzętowego
- Oznaczenie długości używanego adresu sprzętowego np. 6 dla Ethernetu 10 Mbps.
- Liczba skoków
- Pole jest opcjonalne. Zlicza liczbę pośrednich routerów biorących udział w transmisji pakietu.
- Identyfikator transakcji
- Wybierany losowo przez klienta identyfikator (w sytuacji, gdy serwer nie będzie w stanie "zrozumieć" adresu sprzętowego klienta. Wyśle odpowiedź na broadcast, a xid będzie jedynym sposobem rozpoznania odpowiedzi kierowanej do klienta).
- Liczba sekund
- Mierzony w sekundach czas, jaki upłynął od momentu pierwszego wysłania przez klienta wiadomości typu BOOTREQUEST.
- Flagi
- W tej chwili używany tylko 1 bit (BROADCAST flag). Pozostałe 15 bitów jest zarezerwowane na zastosowanie w przyszłości.
- Adres IP klienta
- Pole nieobowiązkowe. Wypełniane w przypadku np. odświeżania adresu.
- Przydzielony adres IP klienta
- Trzy możliwości przydzielania adresu: ręcznie (na podstawie MAC), automatycznie (kolejność zgłaszania) i dynamicznie (tylko na pewien okres).
- Adres IP serwera
- Ustawiane przez serwer.
- Adres IP bramki
- Ustawiane przez serwer.
- Adres sprzętowy klienta
- Adres MAC klienta.
- Nazwa serwera
- Pole opcjonalne. Nazwa hosta serwera.
- Plik startowy
- Używany w mechanizmie ciasteczek (Magic Cookie).
- Opcje
- Zestaw ponumerowanych opcji 0-254. RFC 1533 ↓ np.
DHCP option 50: 192.168.1.100 requested
- Klient prosi serwer o przydzielenie danego adresu IP.
Przydzielanie adresów IP
Protokół DHCP opisuje trzy techniki przydzielania adresów IP:
- przydzielanie ręczne oparte na tablicy adresów MAC oraz odpowiednich dla nich adresów IP. Jest ona tworzona przez administratora serwera DHCP. W takiej sytuacji prawo do pracy w sieci mają tylko komputery zarejestrowane wcześniej przez obsługę systemu.
- przydzielanie automatyczne, gdzie wolne adresy IP z zakresu ustalonego przez administratora są przydzielane kolejnym zgłaszającym się po nie klientom.
- przydzielanie dynamiczne, pozwalające na ponowne użycie adresów IP. Administrator sieci nadaje zakres adresów IP do rozdzielenia. Wszyscy klienci mają tak skonfigurowane interfejsy sieciowe, że po starcie systemu automatycznie pobierają swoje adresy. Każdy adres przydzielany jest na pewien czas. Taka konfiguracja powoduje, że zwykły użytkownik ma ułatwioną pracę z siecią.
Niektóre serwery DHCP dodatkowo przydzielają każdemu klientowi własny adres DNS, przekazywany na serwer nazw protokołem zgodnym ze specyfikacją RFC 2136 ↓.
Parametry konfiguracji przekazywane do klienta
Serwer DHCP może dostarczać swoim klientom dodatkowe dane pozwalające na konfigurację sieci. Zostały one opisane w specyfikacji RFC 2132 ↓.
Niektóre z dodatkowych opcji:
- adres IP serwera DNS
- nazwa DNS
- adres IP bramy sieciowej (ang. gateway)
- adres broadcast
- maska podsieci
- maksymalny czas oczekiwania na odpowiedź w protokole ARP
- wartość MTU (maksymalny rozmiar pakietu)
- adresy serwerów NIS
- domena NIS
- adres IP serwera SMTP
- adres serwera TFTP
- adres serwera nazw NetBIOS
- adres serwera WINS
Najpopularniejsze serwery DHCP
Microsoft wprowadził DHCP do systemu Windows NT w wersji 3.5 w roku 1994, jednak to nie ta firma opracowała sam protokół.
Fundacja Internet Systems Consortium opracowała serwer DHCP w wersji 1.0.0 dla systemów Unix. ISC DHCP został wydany 6 grudnia 1997, a w 1999 pojawiła się wersja 2.0, bardziej zgodna ze specyfikacją[2].
W dystrybucjach Linuksa serwer ISC DHCP jest zwykle dostępny w pakiecie pod nazwą dhcpd (ang. Dynamic Host Configuration Protocol Daemon).
Korporacja Cisco opracowała własny serwer DHCP dla systemu IOS 12.0 w roku 1999. System operacyjny Solaris firmy Sun został wyposażony w pełną obsługę protokołu w roku 2001.
Niektórzy producenci routerów rozszerzyli ich możliwości o obsługę serwera DHCP.
Dynamiczny przydział adresów na łączu punkt-punkt (PPP)
W przypadku korzystania z protokołu PPP (i jego wariantów) do zestawienia połączenia punkt-punkt, np. do połączenia z dostawcą Internetu (ISP) można zastosować protokół DHCP do ustalenia adresów IP, o ile zastosuje się odpowiednie identyfikatory klienta DHCP (na łączu PPP nie stosuje się adresów MAC).
Do ustalania adresów IP na łączu służy przede wszystkim protokół IPCP, więc w typowym przypadku (ustalenie adresów IP maszyny) nie zachodzi potrzeba wykorzystania DHCP. Protokół IPCP posiada rozszerzenie[3], dzięki któremu możliwe jest przekazanie informacji o serwerach DNS i NetBIOS.
W przeciwieństwie do protokołu DHCP, komputery na łączu PPP są równoważne, to znaczy nie ma odróżnienia klienta pobierającego adres i serwera przydzielającego adres. Może być np. tak, że strona inicjująca połączenie PPP proponuje adres IP drugiej stronie.
Porty
DHCP używa protokołu UDP. Wszystkie pakiety wysyłane przez klienta mają port źródłowy 68 i port docelowy 67. Pakiety wysyłane przez serwer mają port źródłowy 67 i port docelowy 68. W przypadku DHCPv6 dla adresów IPv6 klient wysyła zapytania na port docelowy 547, natomiast odpowiedzi z serwera są wysyłane na port źródłowy 546.
Pakiety protokołu DHCP
Poszukiwanie serwera DHCP
Klient chcący się połączyć z serwerem wysyła do sieci lokalnej pakiety rozgłoszeniowe zaadresowane do wszystkich odbiorców. Procedura ta nosi nazwę DHCP DISCOVER – odkrywanie DHCP. Czasami routery są konfigurowane, aby przekazywały pakiety DHCP do właściwego serwera w innej podsieci. Pakiety mają adres docelowy rozgłoszeniowy 255.255.255.255 i zawierają prośbę o ostatnio używany adres IP (np. 192.168.1.100). Może ona zostać zignorowana przez serwer.
Oferta DHCP
Oferta DHCP (ang. DHCP Offer) jest składana przez serwer, który określa właściwą konfigurację klienta na podstawie sprzętowego adresu urządzenia sieciowego określonego w polu CHADDR (w sieci lokalnej to adres MAC). W polu YIADDR serwer przekazuje klientowi jego adres IP.
Żądanie DHCP
Żądanie DHCP (ang. DHCP Request) jest wysyłane przez klienta, który już rozpoznał serwer DHCP, ale chce uzyskać inne parametry konfiguracji. Może np. ponownie zażądać adresu IP 192.168.1.100. RFC 2131 ↓ wprowadza dodatkowo zapytanie typu DHCPINFORM. Klient stosuje je, gdy ma już przypisany adres IP (np. ręcznie), lecz nadal nie zna pozostałych wymaganych parametrów. W odpowiedzi serwer wysyła pakiet potwierdzenia DHCP z pustym polem YIADDR oraz nieustawionym czasem dzierżawy adresu.
Potwierdzenie DHCP
Potwierdzenie DHCP (ang. DHCP Acknowledge) jest wysyłane jako odpowiedź na żądanie. Zakłada się, że reakcją klienta na potwierdzenie będzie odpowiednie skonfigurowanie interfejsu sieciowego.
Odświeżanie DHCP
Elementem przydzielenia klientowi adresu IP przez serwer DHCP jest przyznanie dodatkowo tzw. czasu dzierżawy (lease). Określa on czas ważności ustawień. W tle pracują dwa zegary – T1 odmierza połowę czasu użytkowania, zaś T2 – 87,5% pełnego czasu użytkowania. Obie wartości można zmienić w opcjonalnych ustawieniach serwera DHCP – jeśli takie funkcje zostały zaimplementowane. Po upływie czasu T1 klient wysyła komunikat DHCPREQUEST do serwera i pyta, czy serwer może przedłużyć czas użytkowania. Stan ten określa się jako renewing status. Z reguły serwer odpowiada wiadomością DHCPACK i przydziela nowy czas użytkowania. Serwer resetuje wówczas zegary T1 i T2.
Jeżeli po upływie czasu T2 klient nie otrzyma wiadomości DHCPACK, rozpoczyna się tak zwany rebinding status. Klient musi wysłać komunikat DHCPREQUEST, żeby uzyskać przedłużenie czasu użytkowania. Serwer może odpowiedzieć na to żądanie potwierdzeniem DHCPACK. Jeżeli jednak i to żądanie pozostanie bez odpowiedzi, klient musi zażądać nowego adresu IP. Wkracza wówczas ponownie opisany na początku mechanizm, który rozsyła zapytania do wszystkich serwerów DHCP w sieci.
Zobacz też
Przypisy
- ↑ DHCP Messages, DHCPDiscover, DHCPOffer, DHCPRequest, DHCPAcknowledgment, DHCPNak, DHCPDecline, DHCPRelease, DHCPInform [online], www.omnisecu.com [dostęp 2019-11-17] .
- ↑ ISC DHCP Enterprise Grade Solution for Configuration Needs. Internet Systems Consortium. [dostęp 2016-03-17]. [zarchiwizowane z tego adresu (2005-01-02)]. (ang.).
- ↑ S. Cobb , PPP Internet Protocol Control Protocol Extensions for Name Server Addresses, RFC 1877, IETF, grudzień 1995, DOI: 10.17487/RFC1877, ISSN 2070-1721, OCLC 943595667 (ang.).
Linki zewnętrzne
- Debian Reference (version 1) Część 10 – Konfiguracja sieci. [dostęp 2014-05-12]. [zarchiwizowane z tego adresu (2013-12-22)].
- John Wobus: DHCP FAQ. 26 października 1998. [dostęp 2004-10-05]. [zarchiwizowane z tego adresu (2011-05-17)]. (ang.).
- S. Alexander , R. Droms , DHCP Options and BOOTP Vendor Extensions, RFC 1533, IETF, październik 1993, DOI: 10.17487/RFC1533, ISSN 2070-1721, OCLC 943595667 (ang.).
- R. Droms , Dynamic Host Configuration Protocol, RFC 2131, IETF, marzec 1997, DOI: 10.17487/RFC2131, ISSN 2070-1721, OCLC 943595667 (ang.).
- S. Alexander , R. Droms , DHCP Options and BOOTP Vendor Extensions, RFC 2132, IETF, marzec 1997, DOI: 10.17487/RFC2132, ISSN 2070-1721, OCLC 943595667 (ang.).
- P. Vixie i inni, Dynamic Updates in the Domain Name System (DNS UPDATE), RFC 2136, IETF, kwiecień 1997, DOI: 10.17487/RFC2136, ISSN 2070-1721, OCLC 943595667 (ang.).
- R. Droms i inni, Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC 3315, IETF, lipiec 2003, DOI: 10.17487/RFC3315, ISSN 2070-1721, OCLC 943595667 (ang.).