Protokół dynamicznej konfiguracji hosta — Dynamic Host Configuration Protocol
Pakiet protokołów internetowych |
---|
Warstwa aplikacji |
Warstwa transportowa |
Warstwa internetowa |
Warstwa łącza |
Protokół dynamicznej konfiguracji hosta ( DHCP ) to protokół zarządzania siecią używany w sieciach protokołu internetowego (IP) do automatycznego przypisywania adresów IP i innych parametrów komunikacji do urządzeń podłączonych do sieci przy użyciu architektury klient-serwer .
Technologia ta eliminuje potrzebę indywidualnego ręcznego konfigurowania urządzeń sieciowych i składa się z dwóch komponentów sieciowych, centralnie zainstalowanego sieciowego serwera DHCP oraz klienckich wystąpień stosu protokołów na każdym komputerze lub urządzeniu. Po podłączeniu do sieci, a następnie okresowo, klient żąda zestawu parametrów od serwera DHCP za pomocą protokołu DHCP.
DHCP można wdrożyć w sieciach o różnej wielkości, od sieci domowych po duże sieci kampusowe i regionalne sieci dostawców usług internetowych. Wiele routerów i bram domowych ma możliwość korzystania z serwera DHCP. Większość routerów sieci domowej otrzymuje unikalny adres IP w sieci ISP. W sieci lokalnej serwer DHCP przypisuje każdemu urządzeniu lokalny adres IP.
Usługi DHCP istnieją dla sieci z protokołem internetowym w wersji 4 (IPv4), a także w wersji 6 ( IPv6 ). Wersja IPv6 protokołu DHCP jest powszechnie nazywana DHCPv6 .
Historia
Protokół Reverse Address Resolution Protocol (RARP) został zdefiniowany w RFC 903 w 1984 roku do konfiguracji prostych urządzeń, takich jak bezdyskowe stacje robocze , z odpowiednim adresem IP. Działając w warstwie łącza danych utrudniało to wdrożenie na wielu platformach serwerowych. Wymagało to obecności serwera na każdym indywidualnym łączu sieciowym. RARP został zastąpiony przez protokół Bootstrap ( BOOTP ) zdefiniowany w RFC 951 we wrześniu 1985 r. Wprowadziło to koncepcję agenta przekazującego, który umożliwiał przekazywanie pakietów BOOTP przez sieci, umożliwiając jednemu centralnemu serwerowi BOOTP obsługę hostów w wielu podsieciach IP.
DHCP jest oparty na protokole BOOTP, ale może dynamicznie przydzielać adresy IP z puli i odzyskiwać je, gdy nie są już używane. Może być również używany do dostarczania szerokiej gamy dodatkowych parametrów konfiguracyjnych klientom IP, w tym parametrów specyficznych dla platformy. DHCP został po raz pierwszy zdefiniowany w RFC 1531 w październiku 1993, ale z powodu błędów w procesie redakcyjnym został niemal natychmiast ponownie wydany jako RFC 1541.
Cztery lata później typ wiadomości DHCPINFORM i inne drobne zmiany zostały dodane przez RFC 2131; który od 2014 r. pozostaje standardem dla sieci IPv4.
Protokół DHCPv6 został początkowo opisany w dokumencie RFC 3315 w 2003 r., ale został on zaktualizowany w wielu kolejnych dokumentach RFC. RFC 3633 dodał mechanizm DHCPv6 do delegowania prefiksów , a bezstanowa autokonfiguracja adresów została dodana przez RFC 3736.
Przegląd
Protokół internetowy (IP) określa, w jaki sposób urządzenia komunikują się w sieciach lokalnych i między nimi w Internecie. Serwer DHCP może zarządzać ustawieniami IP urządzeń w swojej sieci lokalnej, np. automatycznie i dynamicznie przypisując tym urządzeniom adresy IP.
DHCP działa w oparciu o model klient-serwer . Gdy komputer lub inne urządzenie łączy się z siecią, oprogramowanie klienta DHCP wysyła zapytanie emisji DHCP, żądając niezbędnych informacji. Dowolny serwer DHCP w sieci może obsłużyć żądanie. Serwer DHCP zarządza pulą adresów IP oraz informacjami o parametrach konfiguracji klienta, takich jak brama domyślna , nazwa domeny , serwery nazw i serwery czasu . Po otrzymaniu żądania DHCP serwer DHCP może odpowiedzieć konkretnymi informacjami dla każdego klienta, zgodnie z wcześniejszą konfiguracją administratora, lub konkretnym adresem i innymi informacjami ważnymi dla całej sieci i przez okres, na który alokacja ( dzierżawa ) jest ważna. Klient DHCP zazwyczaj pyta o te informacje natychmiast po uruchomieniu , a następnie okresowo przed wygaśnięciem informacji. Gdy klient DHCP odświeża przypisanie, początkowo żąda tych samych wartości parametrów, ale serwer DHCP może przydzielić nowy adres na podstawie zasad przydziału ustalonych przez administratorów.
W dużych sieciach, które składają się z wielu łączy, pojedynczy serwer DHCP może obsługiwać całą sieć, gdy wspomagają go agenci przekazujący DHCP znajdujący się na routerach łączących. Tacy agenci przekazują komunikaty między klientami DHCP a serwerami DHCP znajdującymi się w różnych podsieciach.
W zależności od implementacji serwer DHCP może mieć trzy metody przydzielania adresów IP:
- Alokacja dynamiczna
- A administrator sieci rezerwuje pewien zakres adresów IP dla DHCP, a każdy klient DHCP na LAN jest skonfigurowany do żądania adresu IP z DHCP serwer podczas inicjalizacji sieci. Proces żądania i przyznawania wykorzystuje koncepcję dzierżawy z kontrolowanym okresem czasu, umożliwiając serwerowi DHCP odzyskanie, a następnie ponowne przydzielenie adresów IP, które nie są odnawiane.
- Automatyczne przydzielanie
- Serwer DHCP na stałe przypisuje żądającemu klientowi adres IP z zakresu zdefiniowanego przez administratora. Przypomina to alokację dynamiczną, ale serwer DHCP przechowuje tabelę poprzednich przypisań adresów IP, dzięki czemu może preferencyjnie przypisać klientowi ten sam adres IP, który klient miał poprzednio.
- Ręczna alokacja
- Ta metoda jest również różnie nazywana statyczną alokacją DHCP , stałym przydzielaniem adresów , rezerwacją i wiązaniem adresów MAC/IP . Administrator mapuje unikalny identyfikator (identyfikator klienta lub adres MAC ) dla każdego klienta na adres IP, który jest oferowany żądającemu klientowi. Serwery DHCP można skonfigurować tak, aby powróciły do innych metod, jeśli to się nie powiedzie.
Usługi DHCP są używane dla protokołu internetowego w wersji 4 (IPv4) i IPv6 . Szczegóły protokołu dla IPv4 i IPv6 różnią się na tyle, że można je uznać za oddzielne protokoły. W przypadku działania protokołu IPv6 urządzenia mogą alternatywnie używać bezstanowej automatycznej konfiguracji adresów . Hosty IPv6 mogą również używać adresowania lokalnego w celu wykonywania operacji ograniczonych do łącza sieci lokalnej.
Operacja
DHCP wykorzystuje bezpołączeniowy model usług, wykorzystujący protokół UDP ( User Datagram Protocol ). Jest zaimplementowany z dwoma numerami portów UDP dla swoich operacji, które są takie same jak dla protokołu ładowania początkowego ( BOOTP ). Port UDP o numerze 67 jest portem docelowym serwera, a port UDP o numerze 68 jest używany przez klienta.
Operacje DHCP dzielą się na cztery fazy: wykrywanie serwera, oferta dzierżawy IP, żądanie dzierżawy IP i potwierdzenie dzierżawy IP. Te etapy są często określane skrótem DORA dla odkrycia, oferty, prośby i potwierdzenia.
Operacja DHCP rozpoczyna się od rozgłaszania żądania przez klientów . Jeśli klient i serwer znajdują się w różnych podsieciach, można użyć Pomocnika DHCP lub Agenta przekazywania DHCP . Klienci żądający odnowienia istniejącej dzierżawy mogą komunikować się bezpośrednio przez UDP unicast , ponieważ klient ma już ustalony adres IP w tym momencie. Dodatkowo istnieje flaga BROADCAST (1 bit w polu 2 byte flags, gdzie wszystkie inne bity są zarezerwowane i ustawione na 0) klient może użyć do wskazania w jaki sposób (broadcast czy unicast) może otrzymać DHCPOFFER: 0x8000 dla emisji, 0x0000 dla emisji pojedynczej. Zwykle oferta DHCPOFFER jest wysyłana za pośrednictwem emisji pojedynczej. W przypadku tych hostów, które nie mogą akceptować pakietów emisji pojedynczej przed skonfigurowaniem adresów IP, ta flaga może służyć do obejścia tego problemu.
Odkrycie
Klient DHCP rozgłasza komunikat DHCPDISCOVER w podsieci sieci przy użyciu adresu docelowego 255.255.255.255 (rozgłaszanie ograniczone) lub określonego adresu rozgłoszeniowego podsieci (rozgłaszanie bezpośrednie). Klient DHCP może również zażądać swojego ostatniego znanego adresu IP. Jeśli klient pozostaje podłączony do tej samej sieci, serwer może spełnić żądanie. W przeciwnym razie zależy to od tego, czy serwer jest skonfigurowany jako autorytatywny, czy nie. Autorytatywny serwer odrzuca żądanie, powodując, że klient wysyła nowe żądanie. Serwer nieautorytatywny po prostu ignoruje żądanie, co prowadzi do zależnego od implementacji limitu czasu, w którym klient może wygasnąć żądanie i poprosić o nowy adres IP.
Na przykład, jeśli HTYPE jest ustawione na 1, aby określić, że używanym medium jest Ethernet , HLEN jest ustawione na 6, ponieważ adres Ethernet (adres MAC) ma długość 6 oktetów. CHADDR jest ustawiony na adres MAC używany przez klienta. Niektóre opcje są również ustawione.
Ethernet: źródło=MAC nadawcy; miejsce docelowe=FF:FF:FF:FF:FF:FF |
|||
IP: źródło=0.0.0.0; miejsce docelowe=255.255.255.255 |
|||
Oktet 0 | Oktet 1 | Oktet 2 | Oktet 3 |
---|---|---|---|
OP | HTYPE | HLEN | CHMIEL |
0x01 | 0x01 | 0x06 | 0x00 |
XID | |||
0x3903F326 | |||
SECS | FLAGI | ||
0x0000 | 0x0000 | ||
CIADDR (adres IP klienta) | |||
0x00000000 | |||
YIADDR (Twój adres IP) | |||
0x00000000 | |||
SIADDR (adres IP serwera) | |||
0x00000000 | |||
GIADDR (adres IP bramy) | |||
0x00000000 | |||
CHADDR (adres sprzętowy klienta) | |||
0x00053C04 | |||
0x8D590000 | |||
0x00000000 | |||
0x00000000 | |||
192 oktety zer lub przepełnienie przestrzeni dla dodatkowych opcji; Dziedzictwo BOOTP . | |||
Magiczne ciasteczko | |||
0x63825363 | |||
Opcje DHCP | |||
0x350101 53: 1 (Wykrywanie DHCP) | |||
0x3204c0a80164 50: zażądano 192.168.1.100 | |||
0x370401030f06 55 (Lista żądań parametrów):
|
|||
0xff 255 (znacznik końcowy) |
Oferta
Gdy serwer DHCP odbiera od klienta komunikat DHCPDISCOVER, który jest żądaniem dzierżawy adresu IP, serwer DHCP rezerwuje adres IP dla klienta i składa ofertę dzierżawy, wysyłając do klienta komunikat DHCPOFFER. Ten komunikat zawiera identyfikator klienta (tradycyjnie adres MAC), adres IP oferowany przez serwer, maskę podsieci, czas trwania dzierżawy oraz adres IP serwera DHCP składającego ofertę. Serwer DHCP może również zwrócić uwagę na adres MAC na poziomie sprzętowym w podstawowej warstwie transportowej: zgodnie z aktualnymi specyfikacjami RFC adres MAC warstwy transportowej może być używany, jeśli w pakiecie DHCP nie podano identyfikatora klienta.
Serwer DHCP określa konfigurację na podstawie adresu sprzętowego klienta określonego w polu CHADDR (adres sprzętowy klienta). Tutaj serwer, 192.168.1.1, określa adres IP klienta w polu YIADDR (twój adres IP).
Ethernet: źródło=MAC nadawcy; miejsce docelowe=adres MAC klienta |
||||
IP: źródło=192.168.1.1; miejsce docelowe=192.168.1.100 |
||||
Oktet 0 | Oktet 1 | Oktet 2 | Oktet 3 | |
---|---|---|---|---|
OP | HTYPE | HLEN | CHMIEL | |
0x02 | 0x01 | 0x06 | 0x00 | |
XID | ||||
0x3903F326 | ||||
SECS | FLAGI | |||
0x0000 | 0x0000 | |||
CIADDR (adres IP klienta) | ||||
0x00000000 | ||||
YIADDR (Twój adres IP) | ||||
0xC0A80164 (192.168.1.100) | ||||
SIADDR (adres IP serwera) | ||||
0xC0A80101 (192.168.1.1) | ||||
GIADDR (adres IP bramy) | ||||
0x00000000 | ||||
CHADDR (adres sprzętowy klienta) | ||||
0x00053C04 | ||||
0x8D590000 | ||||
0x00000000 | ||||
0x00000000 | ||||
192 oktety zer; Dziedzictwo BOOTP . | ||||
Magiczne ciasteczko | ||||
0x63825363 | ||||
Opcje DHCP | ||||
53: 2 (Oferta DHCP) | ||||
1 (maska podsieci): 255.255.255.0 | ||||
3 (Router): 192.168.1.1 | ||||
51 (czas dzierżawy adresu IP): 86400s (1 dzień) | ||||
54 (serwer DHCP): 192.168.1.1 | ||||
6 (serwery DNS):
|
Wniosek
W odpowiedzi na ofertę DHCP, klient odpowiada komunikatem DHCPREQUEST, emitowanym do serwera, z żądaniem oferowanego adresu. Klient może otrzymywać oferty DHCP z wielu serwerów, ale zaakceptuje tylko jedną ofertę DHCP. Klient wygeneruje bezpłatne ARP, aby sprawdzić, czy w sieci jest jakiś inny host o tym samym adresie IP. Brak odpowiedzi innego hosta oznacza, że w sieci nie ma hosta z taką samą konfiguracją IP i do serwera wysyłany jest komunikat z potwierdzeniem akceptacji adresu IP. Klient musi przesłać opcję identyfikacji serwera w komunikacie żądania wskazując serwer, którego ofertę wybrał klient. Gdy inne serwery DHCP otrzymają tę wiadomość, wycofują wszelkie oferty, które złożyły klientowi, i zwracają oferowany adres IP do puli dostępnych adresów.
Ethernet: źródło=MAC nadawcy; miejsce docelowe=FF:FF:FF:FF:FF:FF |
||||
IP: źródło=0.0.0.0; miejsce docelowe=255.255.255.255; |
||||
Oktet 0 | Oktet 1 | Oktet 2 | Oktet 3 | |
---|---|---|---|---|
OP | HTYPE | HLEN | CHMIEL | |
0x01 | 0x01 | 0x06 | 0x00 | |
XID | ||||
0x3903F326 | ||||
SECS | FLAGI | |||
0x0000 | 0x0000 | |||
CIADDR (adres IP klienta) | ||||
0xC0A80164 (192.168.1.100) | ||||
YIADDR (Twój adres IP) | ||||
0x00000000 | ||||
SIADDR (adres IP serwera) | ||||
0xC0A80101 (192.168.1.1) | ||||
GIADDR (adres IP bramy) | ||||
0x00000000 | ||||
CHADDR (adres sprzętowy klienta) | ||||
0x00053C04 | ||||
0x8D590000 | ||||
0x00000000 | ||||
0x00000000 | ||||
192 oktety zer; Dziedzictwo BOOTP . | ||||
Magiczne ciasteczko | ||||
0x63825363 | ||||
Opcje DHCP | ||||
53:3 (Żądanie DHCP) | ||||
50: 192.168.1.100 zażądano | ||||
54 (serwer DHCP): 192.168.1.1 |
Potwierdzenie
Gdy serwer DHCP otrzyma od klienta komunikat DHCPREQUEST, proces konfiguracji wchodzi w końcową fazę. Faza potwierdzenia obejmuje wysłanie do klienta pakietu DHCPACK. Ten pakiet zawiera czas trwania dzierżawy i wszelkie inne informacje konfiguracyjne, których mógł zażądać klient. W tym momencie proces konfiguracji IP jest zakończony.
Protokół oczekuje, że klient DHCP skonfiguruje swój interfejs sieciowy z wynegocjowanymi parametrami.
Gdy klient uzyska adres IP, powinien sprawdzić nowo otrzymany adres (np. za pomocą protokołu ARP Address Resolution Protocol ), aby zapobiec konfliktom adresów spowodowanym nakładaniem się pul adresów serwerów DHCP. Jeśli sonda znajdzie inny komputer korzystający z tego adresu, komputer powinien wysłać do serwera emisję DHCPDECLINE.
Ethernet: źródło=MAC nadawcy; destination=MAC klienta |
|||
IP: źródło=192.168.1.1; miejsce docelowe=192.168.1.100 |
|||
Oktet 0 | Oktet 1 | Oktet 2 | Oktet 3 |
---|---|---|---|
OP | HTYPE | HLEN | CHMIEL |
0x02 | 0x01 | 0x06 | 0x00 |
XID | |||
0x3903F326 | |||
SECS | FLAGI | ||
0x0000 | 0x0000 | ||
CIADDR (adres IP klienta) | |||
0x00000000 | |||
YIADDR (Twój adres IP) | |||
0xC0A80164 (192.168.1.100) | |||
SIADDR (adres IP serwera) | |||
0xC0A80101 (192.168.1.1) | |||
GIADDR (adres IP bramy przełączany przez przekaźnik) | |||
0x00000000 | |||
CHADDR (adres sprzętowy klienta) | |||
0x00053C04 | |||
0x8D590000 | |||
0x00000000 | |||
0x00000000 | |||
192 oktety zer. Dziedzictwo BOOTP | |||
Magiczne ciasteczko | |||
0x63825363 | |||
Opcje DHCP | |||
53:5 (POTW. DHCP) | |||
1 (maska podsieci): 255.255.255.0 | |||
3 (Router): 192.168.1.1 | |||
51 (czas dzierżawy adresu IP): 86400s (1 dzień) | |||
54 (serwer DHCP): 192.168.1.1 | |||
6 (serwery DNS):
|
Informacja
Klient DHCP może zażądać więcej informacji niż serwer wysłany z oryginalną ofertą DHCPOFFER. Klient może również zażądać powtórzenia danych dla konkretnej aplikacji. Na przykład przeglądarki używają informacji DHCP, aby uzyskać ustawienia serwera proxy sieci Web za pośrednictwem WPAD .
Zwalnianie
Klient wysyła żądanie do serwera DHCP, aby zwolnić informacje DHCP, a klient dezaktywuje swój adres IP. Ponieważ urządzenia klienckie zwykle nie wiedzą, kiedy użytkownicy mogą odłączyć je od sieci, protokół nie nakazuje wysyłania DHCP Release .
Parametry konfiguracyjne klienta
Serwer DHCP może dostarczyć klientowi opcjonalne parametry konfiguracyjne. RFC 2132 opisuje dostępne opcje DHCP zdefiniowane przez Internet Assigned Numbers Authority (IANA) — PARAMETRY DHCP i BOOTP.
Klient DHCP może wybierać, manipulować i nadpisywać parametry udostępniane przez serwer DHCP. W systemach uniksopodobnych to udoskonalenie na poziomie klienta zwykle odbywa się zgodnie z wartościami w pliku konfiguracyjnym /etc/dhclient.conf .
Opcje
Opcje to oktety o różnej długości. Nazywa się to kodowaniem typ-długość-wartość . Pierwszy oktet to kod opcji, drugi oktet to liczba kolejnych oktetów, a pozostałe oktety są zależne od kodu. Na przykład opcja typu komunikatu DHCP dla oferty pojawiłaby się jako 0x35, 0x01, 0x02, gdzie 0x35 to kod 53 dla „typu komunikatu DHCP”, 0x01 oznacza, że następuje jeden oktet, a 0x02 to wartość „oferta”.
W poniższych tabelach wymieniono dostępne opcje DHCP wymienione w rejestrze RFC 2132 i IANA.
Kod | Nazwa | Długość | Uwagi |
---|---|---|---|
0 | Podkładka | 0 oktetów | Może służyć do wypełniania innych opcji, tak aby były wyrównane do granicy słowa; nie następuje bajt długości |
1 | Maska podsieci | 4 oktety | Musi zostać wysłany przed opcją routera (opcja 3), jeśli obie są włączone |
2 | Przesunięcie czasu | 4 oktety | |
3 | Router | Wielokrotność 4 oktetów | Dostępne routery powinny być wymienione w kolejności preferencji |
4 | Serwer czasu | Wielokrotność 4 oktetów | Dostępne serwery czasu do synchronizacji powinny być wymienione w kolejności preferencji |
5 | Serwer nazw | Wielokrotność 4 oktetów | Dostępne serwery nazw IEN 116 powinny być wymienione w kolejności preferencji |
6 | Serwer nazw domen | Wielokrotność 4 oktetów | Dostępne serwery DNS powinny być wymienione w kolejności preferencji |
7 | Serwer dziennika | Wielokrotność 4 oktetów | Dostępne serwery dziennika powinny być wymienione w kolejności preferencji. |
8 | Serwer plików cookie | Wielokrotność 4 oktetów | Plik cookie w tym przypadku oznacza „ciasteczko z wróżbą” lub „cytat dnia”, zwięzłą lub humorystyczną anegdotę często wysyłaną w ramach procesu logowania na dużych komputerach; nie ma to nic wspólnego z plikami cookie wysyłanymi przez strony internetowe . |
9 | Serwer LPR | Wielokrotność 4 oktetów | |
10 | Zaimponuj serwerowi | Wielokrotność 4 oktetów | |
11 | Serwer lokalizacji zasobów | Wielokrotność 4 oktetów | |
12 | Nazwa hosta | Minimum 1 oktet | |
13 | Rozmiar pliku rozruchowego | 2 oktety | Długość obrazu rozruchowego w blokach 4KiB |
14 | Plik zrzutu zasług | Minimum 1 oktet | Ścieżka, w której powinny być przechowywane zrzuty awaryjne |
15 | Nazwa domeny | Minimum 1 oktet | |
16 | Zamień serwer | 4 oktety | |
17 | Ścieżka korzeniowa | Minimum 1 oktet | |
18 | Ścieżka rozszerzeń | Minimum 1 oktet | |
255 | Kończyć się | 0 oktetów | Służy do oznaczania końca pola opcji dostawcy |
Kod | Nazwa | Długość | Uwagi |
---|---|---|---|
19 | Włączanie/wyłączanie przekazywania IP | 1 oktet | |
20 | Włączanie/wyłączanie nielokalnego routingu źródłowego | 1 oktet | |
21 | Filtr zasad | Wielokrotność 8 oktetów | |
22 | Maksymalny rozmiar ponownego złożenia datagramu | 2 oktety | |
23 | Domyślny czas życia IP | 1 oktet | |
24 | Limit czasu starzenia się jednostki MTU ścieżki | 4 oktety | |
25 | Tabela płaskowyżu ścieżki MTU | Wielokrotność 2 oktetów |
Kod | Nazwa | Długość | Uwagi |
---|---|---|---|
26 | Interfejs MTU | 2 oktety | |
27 | Wszystkie podsieci są lokalne | 1 oktet | |
28 | Adres transmisji | 4 oktety | |
29 | Wykonaj wykrywanie masek | 1 oktet | |
30 | Dostawca masek | 1 oktet | |
31 | Wykonaj wykrywanie routera | 1 oktet | |
32 | Adres wywołania routera | 4 oktety | |
33 | Trasa statyczna | Wielokrotność 8 oktetów | Lista par cel/router |
Kod | Nazwa | Długość | Uwagi |
---|---|---|---|
34 | Opcja enkapsulacji przyczepy | 1 oktet | |
35 | Limit czasu pamięci podręcznej ARP | 4 oktety | |
36 | Enkapsulacja Ethernet | 1 oktet |
Kod | Nazwa | Długość | Uwagi |
---|---|---|---|
37 | Domyślne TTL TCP | 1 oktet | |
38 | Interwał utrzymywania aktywności TCP | 4 oktety | |
39 | Śmieci związane z utrzymywaniem aktywności TCP | 1 oktet |
Kod | Nazwa | Długość | Uwagi |
---|---|---|---|
40 | Domena usługi informacyjnej sieci | Minimum 1 oktet | |
41 | Serwery informacji o sieci | Wielokrotność 4 oktetów | |
42 | Serwery Network Time Protocol (NTP) | Wielokrotność 4 oktetów | |
43 | Informacje specyficzne dla dostawcy | Minimum 1 oktet | |
44 | NetBIOS przez serwer nazw TCP/IP | Wielokrotność 4 oktetów | |
45 | Serwer dystrybucji datagramów NetBIOS przez TCP/IP | Wielokrotność 4 oktetów | |
46 | Typ węzła NetBIOS przez TCP/IP | 1 oktet | |
47 | Zakres NetBIOS przez TCP/IP | Minimum 1 oktet | |
48 | Serwer czcionek X Window System | Wielokrotność 4 oktetów | |
49 | Menedżer wyświetlania X Window System | Wielokrotność 4 oktetów | |
64 | Sieciowy Serwis Informacyjny + domena | Minimum 1 oktet | |
65 | Serwery Network Information Service+ | Wielokrotność 4 oktetów | |
68 | Mobilny agent domowy IP | Wielokrotność 4 oktetów | |
69 | Serwer Simple Mail Transfer Protocol (SMTP) | Wielokrotność 4 oktetów | |
70 | Serwer Post Office Protocol (POP3) | Wielokrotność 4 oktetów | |
71 | Serwer Network News Transfer Protocol (NNTP) | Wielokrotność 4 oktetów | |
72 | Domyślny World Wide Web Server (WWW) | Wielokrotność 4 oktetów | |
73 | Domyślny serwer protokołu Finger | Wielokrotność 4 oktetów | |
74 | Domyślny serwer Internet Relay Chat (IRC) | Wielokrotność 4 oktetów | |
75 | Serwer StreetTalk | Wielokrotność 4 oktetów | |
76 | Serwer StreetTalk Directory Assistance (STDA) | Wielokrotność 4 oktetów |
Kod | Nazwa | Długość | Uwagi |
---|---|---|---|
50 | Żądany adres IP | 4 oktety | |
51 | Czas dzierżawy adresu IP | 4 oktety | |
52 | Przeciążenie opcji | 1 oktet | |
53 | Typ wiadomości DHCP | 1 oktet | |
54 | Identyfikator serwera | 4 oktety | |
55 | Lista żądań parametrów | Minimum 1 oktet | |
56 | Wiadomość | Minimum 1 oktet | |
57 | Maksymalny rozmiar wiadomości DHCP | 2 oktety | |
58 | Wartość czasu odnowienia (T1) | 4 oktety | |
59 | Wartość czasu ponownego wiązania (T2) | 4 oktety | |
60 | Identyfikator klasy dostawcy | Minimum 1 oktet | |
61 | Identyfikator klienta | Minimum 2 oktety | |
66 | Nazwa serwera TFTP | Minimum 1 oktet | |
67 | Nazwa pliku rozruchowego | Minimum 1 oktet |
Typy komunikatów DHCP
W tej tabeli wymieniono typy komunikatów DHCP, udokumentowane w RFC 2132, RFC 3203, RFC 4388, RFC 6926 i RFC 7724. Te kody są wartościami w rozszerzeniu DHCP 53, pokazanym w powyższej tabeli.
Kod | Nazwa | Długość | RFC |
---|---|---|---|
1 | ODKRYJ DHCP | 1 oktet | rfc2132 |
2 | OFERTA DHCP | 1 oktet | rfc2132 |
3 | ŻĄDANIE DHCP | 1 oktet | rfc2132 |
4 | ODKRES DHCP | 1 oktet | rfc2132 |
5 | DHCPACK | 1 oktet | rfc2132 |
6 | DHCPNAK | 1 oktet | rfc2132 |
7 | ZWOLNIENIE DHCP | 1 oktet | rfc2132 |
8 | INFORMACJA DHCP | 1 oktet | rfc2132 |
9 | ODNOWIENIE WYMUSZENIA DHCP | 1 oktet | rfc3203 |
10 | DHCPLEASEQUERY | 1 oktet | rfc4388 |
11 | DHCPLEEASEUNASSIGNED | 1 oktet | rfc4388 |
12 | DHCPLEEASEUZNANE | 1 oktet | rfc4388 |
13 | DHCPLEEASYAKTYWNY | 1 oktet | rfc4388 |
14 | DHCPBULKLEASQUERY | 1 oktet | rfc6926 |
15 | Kwerenda DHCPLEEASE WYKONANA | 1 oktet | rfc6926 |
16 | AKTYWNE ZAPYTANIE DHCP | 1 oktet | rfc7724 |
17 | STATUS WYNAJMU DHCP | 1 oktet | rfc7724 |
18 | DHCPTLS | 1 oktet | rfc7724 |
Identyfikacja dostawcy klienta
Istnieje możliwość identyfikacji dostawcy i funkcjonalności klienta DHCP. Informacja jest ciągiem znaków lub oktetów o zmiennej długości, którego znaczenie jest określone przez dostawcę klienta DHCP. Jedną z metod, za pomocą której klient DHCP może komunikować się z serwerem, że używa określonego typu sprzętu lub oprogramowania układowego, jest ustawienie wartości w swoich żądaniach DHCP, zwanej identyfikatorem klasy dostawcy (VCI) (opcja 60). Ta metoda umożliwia serwerowi DHCP rozróżnienie dwóch rodzajów komputerów klienckich i odpowiednie przetwarzanie żądań z dwóch typów modemów. Niektóre typy dekoderów ustawiają również VCI (opcja 60), aby informować serwer DHCP o typie sprzętu i funkcjonalności urządzenia. Wartość, na którą ustawiona jest ta opcja, daje serwerowi DHCP wskazówkę dotyczącą wszelkich wymaganych dodatkowych informacji, których ten klient potrzebuje w odpowiedzi DHCP.
Inne rozszerzenia
Kod | Nazwa | Długość | RFC |
---|---|---|---|
82 | Informacje o agencie przekazującym | Minimum 2 oktety | RFC 3046 |
85 | Serwery Novell Directory Service (NDS) | Minimum 4 oktety, wielokrotność 4 oktetów | RFC 2241 |
86 | Nazwa drzewa NDS | Zmienny | RFC 2241 |
87 | Kontekst NDS | Zmienny | RFC 2241 |
100 | Strefa czasowa , styl POSIX | Zmienny | RFC 4833 |
101 | Strefa czasowa , styl bazy danych tz | Zmienny | RFC 4833 |
114 | Portal przechwytujący DHCP | Zmienny | RFC 8910 |
119 | Wyszukiwanie domeny | Zmienny | RFC 3397 |
121 | Bezklasowa trasa statyczna | Zmienny | RFC 3442 |
209 | Plik konfiguracyjny | Zmienny | RFC 5071 |
210 | Prefiks ścieżki | Zmienny | RFC 5071 |
211 | Czas ponownego uruchomienia | Zmienny | RFC 5071 |
Podopcje informacji o agencie przekazującym
Opcja informacji o agencie przekazywania (opcja 82) określa kontener do dołączania podopcji do żądań DHCP przesyłanych między przekaźnikiem DHCP a serwerem DHCP.
Kod | Nazwa | Długość | RFC |
---|---|---|---|
1 | Identyfikator obwodu agenta | Minimum 1 oktet | RFC 3046 |
2 | Zdalny identyfikator agenta | Minimum 1 oktet | RFC 3046 |
4 | Dane techniczne interfejsu usługi Data-Over-Cable (DOCSIS) klasa urządzenia | 4 oktety | RFC 3256 |
Przekazywanie
W małych sieciach, w których zarządzana jest tylko jedna podsieć IP, klienci DHCP komunikują się bezpośrednio z serwerami DHCP. Jednak serwery DHCP mogą również udostępniać adresy IP dla wielu podsieci. W takim przypadku klient DHCP, który nie uzyskał jeszcze adresu IP, nie może komunikować się bezpośrednio z serwerem DHCP spoza tej samej podsieci, ponieważ emisja klienta może być odbierana tylko we własnej podsieci.
Aby umożliwić klientom DHCP w podsieciach, które nie są bezpośrednio obsługiwane przez serwery DHCP, komunikowanie się z serwerami DHCP, w tych podsieciach można zainstalować agentów przekazywania DHCP. Klient DHCP rozgłasza na łączu lokalnym; agent przekazujący odbiera transmisję i przesyła ją do jednego lub większej liczby serwerów DHCP przy użyciu emisji pojedynczej . Agent przekazujący przechowuje własny adres IP w polu GIADDR pakietu DHCP. Serwer DHCP używa wartości GIADDR do określenia podsieci, w której agent przekazujący odebrał transmisję, i przydziela adres IP w tej podsieci. Gdy serwer DHCP odpowiada klientowi, wysyła odpowiedź na adres GIADDR, ponownie używając emisji pojedynczej. Agent przekazujący następnie retransmituje odpowiedź w sieci lokalnej.
W tej sytuacji komunikacja między agentem przekazującym a serwerem DHCP zwykle używa zarówno źródłowego, jak i docelowego portu UDP 67.
Państwa klientów
Jak opisano w RFC 2131, klient DHCP może odbierać następujące komunikaty z serwera:
- OFERTA DHCP
- DHCPACK
- DHCPNAK
Klient przechodzi przez stany DHCP w zależności od tego, jak serwer odpowiada na wiadomości wysyłane przez klienta.
Niezawodność
DHCP zapewnia niezawodność na kilka sposobów: okresowe odnawianie, ponowne wiązanie i przełączanie awaryjne. Klientom DHCP przydzielane są dzierżawy, które trwają przez pewien czas. Klienci zaczynają próbować odnowić swoje dzierżawy po upływie połowy okresu dzierżawy. Robią to, wysyłając pojedynczy komunikat DHCPREQUEST do serwera DHCP, który przyznał pierwotną dzierżawę. Jeśli serwer jest wyłączony lub nieosiągalny, nie odpowie na żądanie DHCPREQUEST . Jednak w takim przypadku klient powtarza od czasu do czasu żądanie DHCPREQUEST , więc jeśli serwer DHCP powróci lub stanie się ponownie dostępny, klientowi DHCP uda się nawiązać z nim kontakt i odnowić dzierżawę.
Jeśli serwer DHCP jest nieosiągalny przez dłuższy czas, klient DHCP spróbuje ponownie powiązać, rozgłaszając swoje DHCPREQUEST zamiast emisji pojedynczej. Ponieważ jest rozgłaszany , komunikat DHCPREQUEST dotrze do wszystkich dostępnych serwerów DHCP. Jeśli jakiś inny serwer DHCP jest w stanie odnowić dzierżawę, zrobi to w tym momencie.
Aby ponowne powiązanie działało, gdy klient pomyślnie nawiąże kontakt z zapasowym serwerem DHCP, serwer ten musi mieć dokładne informacje o powiązaniu klienta. Utrzymanie dokładnych informacji o wiązaniu między dwoma serwerami to skomplikowany problem; jeśli oba serwery są w stanie aktualizować tę samą bazę danych dzierżaw, musi istnieć mechanizm pozwalający uniknąć konfliktów między aktualizacjami na niezależnych serwerach. Propozycja wdrożenia odpornych na awarie serwerów DHCP została zgłoszona do Internet Engineering Task Force, ale nigdy nie została sformalizowana.
Jeśli ponowne wiązanie się nie powiedzie, dzierżawa ostatecznie wygaśnie. Po wygaśnięciu dzierżawy klient musi przestać używać adresu IP przyznanego mu w dzierżawie. W tym czasie uruchomi ponownie proces DHCP od początku, rozgłaszając DHCPDISCOVER
komunikat. Ponieważ jego dzierżawa wygasła, zaakceptuje każdy oferowany mu adres IP. Gdy uzyska nowy adres IP (prawdopodobnie z innego serwera DHCP), będzie mógł ponownie korzystać z sieci. Jednak ponieważ zmienił się jego adres IP, wszelkie trwające połączenia zostaną zerwane.
Sieci IPv6
Podstawowa metodologia DHCP została opracowana dla sieci opartych na protokole internetowym w wersji 4 (IPv4). Od czasu opracowania i wdrożenia sieci IPv6 , DHCP był również używany do przypisywania parametrów w takich sieciach, pomimo nieodłącznych cech IPv6 dla bezstanowej autokonfiguracji adresów . Wersja protokołu IPv6 jest oznaczona jako DHCPv6 .
Bezpieczeństwo
Podstawowy DHCP nie zawiera żadnego mechanizmu uwierzytelniania. Z tego powodu jest podatny na różne ataki. Ataki te dzielą się na trzy główne kategorie:
- Nieautoryzowane serwery DHCP podające klientom fałszywe informacje.
- Nieautoryzowani klienci uzyskujący dostęp do zasobów.
- Ataki na wyczerpanie zasobów ze strony złośliwych klientów DHCP.
Ponieważ klient nie ma możliwości sprawdzenia tożsamości serwera DHCP, nieautoryzowane serwery DHCP (powszechnie nazywane „ nieuczciwymi DHCP ”) mogą działać w sieci, dostarczając niepoprawne informacje klientom DHCP. Może to służyć jako atak typu „odmowa usługi”, uniemożliwiający klientowi uzyskanie dostępu do łączności sieciowej, lub jako atak typu „ man-in-the-middle” . Ponieważ serwer DHCP udostępnia klientowi DHCP adresy IP serwera, takie jak adres IP jednego lub więcej serwerów DNS, atakujący może przekonać klienta DHCP do wyszukiwania DNS za pośrednictwem własnego serwera DNS, a zatem może dostarczyć własne odpowiedzi do zapytań DNS od klienta. To z kolei umożliwia atakującemu przekierowanie ruchu sieciowego przez siebie, pozwalając mu na podsłuchiwanie połączeń między klientem a serwerami sieciowymi, z którymi się kontaktuje, lub po prostu na zastąpienie tych serwerów sieciowych własnymi.
Ponieważ serwer DHCP nie ma bezpiecznego mechanizmu uwierzytelniania klienta, klienci mogą uzyskać nieautoryzowany dostęp do adresów IP, przedstawiając poświadczenia, takie jak identyfikatory klientów, które należą do innych klientów DHCP. Pozwala to również klientom DHCP na wyczerpanie magazynu adresów IP serwera DHCP — prezentując nowe poświadczenia za każdym razem, gdy prosi o adres, klient może wykorzystać wszystkie dostępne adresy IP na określonym łączu sieciowym, uniemożliwiając innym klientom DHCP uzyskanie usługi.
DHCP zapewnia pewne mechanizmy łagodzenia tych problemów. Relay Informacje o Agencie Opcja przedłużenia protokołu (RFC 3046, zwykle określane w przemyśle przez jego rzeczywistej liczby jako opcja 82 ) pozwala operatorom sieci, aby dołączyć do tagów komunikatów DHCP jako komunikaty te przybywają na zaufanej sieci operatora sieci. Ten tag jest następnie używany jako token autoryzacji do kontrolowania dostępu klienta do zasobów sieciowych. Ponieważ klient nie ma dostępu do sieci przed agentem przekazującym, brak uwierzytelniania nie uniemożliwia operatorowi serwera DHCP polegania na tokenie autoryzacji.
Inne rozszerzenie, Authentication for DHCP Messages ( RFC 3118 ), zapewnia mechanizm uwierzytelniania komunikatów DHCP. Od 2002 r. RFC 3118 nie był powszechnie stosowany ze względu na problemy z zarządzaniem kluczami dla dużej liczby klientów DHCP. W książce z 2007 roku o technologiach DSL zauważono, że:
zidentyfikowano liczne luki w zabezpieczeniach w stosunku do środków bezpieczeństwa proponowanych przez RFC 3118. Fakt ten, w połączeniu z wprowadzeniem 802.1x , spowolnił wdrażanie i szybkość pobierania uwierzytelnionego protokołu DHCP i nigdy nie był szeroko stosowany.
W książce z 2010 r. zauważono, że:
[T]tutaj było bardzo niewiele implementacji uwierzytelniania DHCP. Wyzwania związane z zarządzaniem kluczami i opóźnieniami przetwarzania spowodowane obliczeniami skrótu zostały uznane za zbyt wysoką cenę, aby zapłacić za postrzegane korzyści.
Propozycje architektoniczne z 2008 r. obejmują uwierzytelnianie żądań DHCP przy użyciu 802.1x lub PANA (oba transport EAP ). Zaproponowano IETF włączenie EAP do samego DHCP, tak zwanego EAPoDHCP ; Wydaje się, że nie wyszło to poza poziom projektu IETF, z których ostatni pochodzi z 2010 r.
Dokumenty dotyczące standardów IETF
- RFC 2131 — protokół dynamicznej konfiguracji hosta
- RFC 2132 , opcje DHCP i rozszerzenia dostawcy BOOTP
- RFC 3046 , opcja informacji o agencie przekazywania DHCP
- RFC 3397 , opcja wyszukiwania domeny protokołu dynamicznej konfiguracji hosta (DHCP)
- RFC 3942 , reklasyfikowanie opcji protokołu dynamicznej konfiguracji hosta w wersji czwartej (DHCPv4)
- RFC 4242 , opcja czasu odświeżania informacji dla protokołu dynamicznej konfiguracji hosta dla IPv6
- RFC 4361 , identyfikatory klienta specyficzne dla węzła dla protokołu dynamicznej konfiguracji hosta w wersji czwartej (DHCPv4)
- RFC 4436 , wykrywanie załącznika sieciowego w IPv4 (DNAv4)
- RFC 3442 , opcja bezklasowej trasy statycznej dla protokołu dynamicznej konfiguracji hosta (DHCP) w wersji 4
- RFC 3203 , rozszerzenie rekonfiguracji DHCP
- RFC 4388 — zapytanie dzierżawy protokołu dynamicznej konfiguracji hosta (DHCP)
- RFC 6926 , zapytanie dotyczące dzierżawy zbiorczej DHCPv4
- RFC 7724 , aktywne zapytanie o dzierżawę DHCPv4
Zobacz też
- Boot Service Discovery Protocol (BSDP) – rozszerzenie DHCP używane przez NetBoot firmy Apple
- Porównanie oprogramowania serwera DHCP
- Peg DHCP (RFC 2322)
- Środowisko wykonywania przed uruchomieniem (PXE)
- Protokół odwrotnego rozpoznawania adresów (RARP)
- Nieuczciwy DHCP
- UDP Helper Address – narzędzie do routingu żądań DHCP przez granice podsieci
- Zeroconf – sieć z zerową konfiguracją
Uwagi
Bibliografia
Zewnętrzne linki
- Multimedia związane z protokołem Dynamic Host Configuration Protocol (DHCP) na Wikimedia Commons