DHCP, protokol dynamické konfigurace hostitelského počítače - Dynamic Host Configuration Protocol
Sada internetových protokolů |
---|
Aplikační vrstva |
Transportní vrstva |
Internetová vrstva |
Odkazová vrstva |
Dynamic Host Configuration Protocol ( DHCP ) je protokol pro správu sítě použít na Internet Protocol sítě (IP) pro automatické přidělování IP adres a dalších komunikačních parametrů do zařízení připojených k síti pomocí klient-server architekturu.
Tato technologie eliminuje potřebu individuální konfigurace síťových zařízení ručně a skládá se ze dvou síťových komponent, centrálně nainstalovaného síťového serveru DHCP a klientských instancí zásobníku protokolů na každém počítači nebo zařízení. Když je klient připojen k síti a poté pravidelně, požaduje od serveru DHCP sadu parametrů pomocí protokolu DHCP.
DHCP lze implementovat v sítích různých velikostí, od obytných sítí po rozsáhlé kampusové sítě a regionální sítě ISP. Mnoho routerů a obytných bran má schopnost serveru DHCP. Většina routerů pro obytnou síť dostává v rámci sítě ISP jedinečnou IP adresu. V rámci místní sítě přiřadí server DHCP každému zařízení místní IP adresu.
Služby DHCP existují pro sítě s internetovým protokolem verze 4 (IPv4), stejně jako verze 6 ( IPv6 ). Verze IPv6 protokolu DHCP se běžně nazývá DHCPv6 .
Dějiny
Reverse Address Resolution Protocol (RARP) byl definován v RFC 903 v roce 1984 pro konfiguraci jednoduchých zařízení, jako jsou bezdiskové pracovní stanice , s vhodnou IP adresu. Jednání ve vrstvě datového odkazu ztěžovalo implementaci na mnoha serverových platformách. Vyžadovalo to, aby byl server přítomen na každém jednotlivém síťovém odkazu. RARP byl nahrazen protokolem Bootstrap Protocol ( BOOTP ) definovaným v RFC 951 v září 1985. To zavedlo koncept reléového agenta, který umožňoval předávání paketů BOOTP napříč sítěmi, což jednomu centrálnímu serveru BOOTP umožnilo obsluhovat hostitele na mnoha IP podsítích.
DHCP je založen na BOOTP, ale může dynamicky přidělovat IP adresy z fondu a získat je zpět, když se již nepoužívají. Lze jej také použít k poskytování široké škály dalších konfiguračních parametrů pro IP klienty, včetně parametrů specifických pro platformu. DHCP byl poprvé definován v RFC 1531 v říjnu 1993, ale kvůli chybám v redakčním procesu byl téměř okamžitě znovu vydán jako RFC 1541.
O čtyři roky později přidal typ zprávy DHCPINFORM a další malé změny RFC 2131; který od roku 2014 zůstává standardem pro sítě IPv4.
DHCPv6 byl původně popsán RFC 3315 v roce 2003, ale toto bylo aktualizováno mnoha následujícími RFC. RFC 3633 přidal mechanismus DHCPv6 pro delegování předpon a automatická konfigurace adres bez státní příslušnosti byla přidána RFC 3736.
Přehled
Internet Protocol (IP) definuje, jak zařízení komunikují v rámci místních sítí a mezi nimi na internetu. Server DHCP může spravovat nastavení IP pro zařízení ve své místní síti, například přiřazením IP adres těmto zařízením automaticky a dynamicky.
DHCP funguje na základě modelu klient -server . Když se počítač nebo jiné zařízení připojí k síti, klientský software DHCP odešle dotaz na vysílání DHCP požadující potřebné informace. Žádost může obsluhovat jakýkoli server DHCP v síti. Server DHCP spravuje soubor IP adres a informací o parametrech konfigurace klienta, jako je výchozí brána , název domény , jmenné servery a časové servery . Po obdržení požadavku DHCP může server DHCP reagovat s konkrétními informacemi pro každého klienta, jak byl dříve nakonfigurován správcem, nebo s konkrétní adresou a dalšími informacemi platnými pro celou síť a pro časové období, po které je přidělování ( pronájem) ) je platná. Klient DHCP se na tyto informace obvykle dotazuje bezprostředně po spuštění a poté pravidelně před vypršením platnosti informací. Když klient DHCP obnovuje přiřazení, zpočátku požaduje stejné hodnoty parametrů, ale server DHCP může přiřadit novou adresu na základě zásad přiřazení nastavených správci.
Ve velkých sítích, které se skládají z více propojení, může jeden server DHCP obsluhovat celou síť, když mu pomáhají agenti přenosu DHCP umístěná na propojovacích směrovačích. Takoví agenti předávají zprávy mezi klienty DHCP a servery DHCP umístěnými v různých podsítích.
V závislosti na implementaci může mít server DHCP tři způsoby přidělování IP adres:
- Dynamická alokace
- A správce sítě rezervuje určitý rozsah IP adres pro DHCP, a každý klient DHCP v síti LAN je konfigurována pro požadování IP adresy z DHCP serveru během inicializace sítě. Proces žádosti a udělení používá koncept pronájmu s kontrolovatelným časovým obdobím, což umožňuje serveru DHCP získat zpět a poté znovu přidělit IP adresy, které nejsou obnoveny.
- Automatické přidělení
- Server DHCP trvale přiřadí IP adresu žádajícímu klientovi z rozsahu definovaného správcem. Je to jako dynamické přidělení, ale server DHCP uchovává tabulku minulých přiřazení IP adres, takže může klientovi přednostně přiřadit stejnou IP adresu, kterou měl klient dříve.
- Ruční přidělování
- Tato metoda je také různě nazývá statická alokace DHCP , pevné přidělování adres , rezervace , a MAC / IP adresa závazná . Správce mapuje jedinečný identifikátor ( ID klienta nebo MAC adresu ) pro každého klienta na IP adresu, která je nabízena žádajícímu klientovi. Servery DHCP mohou být nakonfigurovány tak, aby se v případě neúspěchu uchýlily k jiným metodám.
Pro protokol IP verze 4 (IPv4) a IPv6 se používají služby DHCP . Podrobnosti o protokolu pro IPv4 a IPv6 se dostatečně liší, takže je lze považovat za samostatné protokoly. Pro provoz IPv6 mohou zařízení alternativně používat automatickou konfiguraci bezstavové adresy . Hostitelé IPv6 mohou také používat lokální adresové propojení k dosažení operací omezených na místní síťové propojení.
Úkon
DHCP využívá model služby bez připojení pomocí protokolu UDP ( User Datagram Protocol ). Je implementován se dvěma čísly portů UDP pro své operace, které jsou stejné jako pro protokol bootstrap ( BOOTP ). Číslo portu UDP 67 je cílový port serveru a číslo portu UDP 68 používá klient.
Operace DHCP spadají do čtyř fází: zjišťování serveru, nabídka pronájmu IP, požadavek na zapůjčení IP a potvrzení pronájmu IP. Tyto fáze jsou často zkráceny jako DORA pro objev, nabídku, žádost a potvrzení.
Operace DHCP začíná tím, že klienti vysílají požadavek. Pokud jsou klient a server v různých podsítích, lze použít pomocníka DHCP nebo agenta přenosu DHCP . Klienti požadující obnovení stávajícího pronájmu mohou komunikovat přímo prostřednictvím UDP unicast , protože klient již v tomto bodě má zavedenou IP adresu. Kromě toho existuje příznak BROADCAST (1 bit v poli 2 bajtových příznaků, kde jsou všechny ostatní bity vyhrazeny a jsou nastaveny na 0), které může klient použít k označení, jakým způsobem (vysílání nebo unicast) může přijímat DHCPOFFER: 0x8000 pro vysílání, 0x0000 pro unicast. DHCPOFFER je obvykle odesílán přes unicast. U těch hostitelů, kteří před konfigurací IP adres nemohou přijímat pakety unicast, lze tento problém vyřešit pomocí tohoto příznaku.
Objev
Klient DHCP vysílá zprávu DHCPDISCOVER v podsíti sítě pomocí cílové adresy 255.255.255.255 (omezené vysílání) nebo konkrétní adresy vysílání podsítě (směrované vysílání). Klient DHCP může také požádat o svou poslední známou adresu IP. Pokud klient zůstane připojen ke stejné síti, server může žádosti vyhovět. Jinak záleží na tom, zda je server nastaven jako autoritativní nebo ne. Autoritativní server požadavek odmítne, což způsobí, že klient vydá nový požadavek. Neautoritativní server jednoduše ignoruje požadavek, což vede k vypršení časového limitu závislého na implementaci, kdy klient požadavek vyprší a požádá o novou IP adresu.
Pokud je například HTYPE nastaven na 1, aby bylo uvedeno, že použité médium je Ethernet , HLEN se nastaví na 6, protože ethernetová adresa (MAC adresa) je dlouhá 6 oktetů. CHADDR je nastavena na MAC adresu používanou klientem. Jsou nastaveny také některé možnosti.
Ethernet: zdroj = MAC odesílatele; místo určení = FF: FF: FF: FF: FF: FF |
|||
IP: zdroj = 0,0.0,0; destinace = 255.255.255.255 |
|||
Oktet 0 | Oktet 1 | Octet 2 | Octet 3 |
---|---|---|---|
OP | HTYPE | HLEN | CHMEL |
0x01 | 0x01 | 0x06 | 0x00 |
XID | |||
0x3903F326 | |||
SEKCE | VLAJKY | ||
0x0000 | 0x0000 | ||
CIADDR (IP adresa klienta) | |||
0x00000000 | |||
YIADDR (vaše IP adresa) | |||
0x00000000 | |||
SIADDR (IP adresa serveru) | |||
0x00000000 | |||
GIADDR (IP adresa brány) | |||
0x00000000 | |||
CHADDR (hardwarová adresa klienta) | |||
0x00053C04 | |||
0x8D590000 | |||
0x00000000 | |||
0x00000000 | |||
192 oktetů 0 s nebo přeplněný prostor pro další možnosti; Legenda BOOTP . | |||
Kouzelný cookie | |||
0x63825363 | |||
Možnosti DHCP | |||
0x350101 53: 1 (DHCP Discover) | |||
0x3204c0a80164 50: 192.168.1.100 požadováno | |||
0x370401030f06 55 (seznam požadavků na parametry):
|
|||
0xff 255 (koncová značka) |
Nabídka
Když server DHCP přijme od klienta zprávu DHCPDISCOVER, což je požadavek na zapůjčení adresy IP, server DHCP rezervuje adresu IP pro klienta a nabídne pronájem odesláním zprávy DHCPOFFER klientovi. Tato zpráva obsahuje klientovo ID klienta (tradičně MAC adresu), IP adresu, kterou server nabízí, masku podsítě, dobu zapůjčení a IP adresu serveru DHCP, který nabídku nabízí. Server DHCP může také zaznamenat MAC adresu hardwarové úrovně v podkladové přenosové vrstvě: podle aktuálních RFC může být použita MAC adresa transportní vrstvy, pokud v paketu DHCP není uvedeno žádné ID klienta.
Server DHCP určuje konfiguraci na základě hardwarové adresy klienta, jak je uvedeno v poli CHADDR (hardwarová adresa klienta). Zde server 192.168.1.1 určuje IP adresu klienta v poli YIADDR (vaše IP adresa).
Ethernet: zdroj = MAC odesílatele; destinace = adresa MAC klienta |
||||
IP: zdroj = 192.168.1.1; destinace = 192.168.1.100 |
||||
Oktet 0 | Oktet 1 | Octet 2 | Octet 3 | |
---|---|---|---|---|
OP | HTYPE | HLEN | CHMEL | |
0x02 | 0x01 | 0x06 | 0x00 | |
XID | ||||
0x3903F326 | ||||
SEKCE | VLAJKY | |||
0x0000 | 0x0000 | |||
CIADDR (IP adresa klienta) | ||||
0x00000000 | ||||
YIADDR (vaše IP adresa) | ||||
0xC0A80164 (192.168.1.100) | ||||
SIADDR (IP adresa serveru) | ||||
0xC0A80101 (192.168.1.1) | ||||
GIADDR (IP adresa brány) | ||||
0x00000000 | ||||
CHADDR (hardwarová adresa klienta) | ||||
0x00053C04 | ||||
0x8D590000 | ||||
0x00000000 | ||||
0x00000000 | ||||
192 oktetů 0 s; Legenda BOOTP . | ||||
Kouzelný cookie | ||||
0x63825363 | ||||
Možnosti DHCP | ||||
53: 2 (nabídka DHCP) | ||||
1 (maska podsítě): 255.255.255.0 | ||||
3 (směrovač): 192.168.1.1 | ||||
51 (doba pronájmu IP adresy): 86400s (1 den) | ||||
54 (server DHCP): 192.168.1.1 | ||||
6 (servery DNS):
|
Žádost
V reakci na nabídku DHCP klient odpoví zprávou DHCPREQUEST, vyslanou na server, požadující nabízenou adresu. Klient může přijímat nabídky DHCP z více serverů, ale bude přijímat pouze jednu nabídku DHCP. Klient vytvoří bezplatný ARP, aby zjistil, zda je v síti jiný hostitel se stejnou IP adresou. Pokud jiný hostitel neodpoví, není v síti žádný hostitel se stejnou konfigurací IP a zpráva je vyslána na server, který ukazuje přijetí IP adresy. Klient musí odeslat možnost identifikace serveru ve zprávě požadavku s uvedením serveru, jehož nabídku si klient vybral. Když tuto zprávu obdrží jiné servery DHCP, stáhnou všechny nabídky, které klientovi poskytli, a vrátí nabízenou adresu IP do skupiny dostupných adres.
Ethernet: zdroj = MAC odesílatele; místo určení = FF: FF: FF: FF: FF: FF |
||||
IP: zdroj = 0,0.0,0; místo určení = 255.255.255.255; |
||||
Oktet 0 | Oktet 1 | Octet 2 | Octet 3 | |
---|---|---|---|---|
OP | HTYPE | HLEN | CHMEL | |
0x01 | 0x01 | 0x06 | 0x00 | |
XID | ||||
0x3903F326 | ||||
SEKCE | VLAJKY | |||
0x0000 | 0x0000 | |||
CIADDR (IP adresa klienta) | ||||
0xC0A80164 (192.168.1.100) | ||||
YIADDR (vaše IP adresa) | ||||
0x00000000 | ||||
SIADDR (IP adresa serveru) | ||||
0xC0A80101 (192.168.1.1) | ||||
GIADDR (IP adresa brány) | ||||
0x00000000 | ||||
CHADDR (hardwarová adresa klienta) | ||||
0x00053C04 | ||||
0x8D590000 | ||||
0x00000000 | ||||
0x00000000 | ||||
192 oktetů 0 s; Legenda BOOTP . | ||||
Kouzelný cookie | ||||
0x63825363 | ||||
Možnosti DHCP | ||||
53: 3 (požadavek DHCP) | ||||
50: 192.168.1.100 požadováno | ||||
54 (server DHCP): 192.168.1.1 |
Potvrzení
Když server DHCP přijme od klienta zprávu DHCPREQUEST, proces konfigurace přejde do závěrečné fáze. Fáze potvrzení zahrnuje odeslání paketu DHCPACK klientovi. Tento paket zahrnuje dobu pronájmu a veškeré další konfigurační informace, které si klient mohl vyžádat. V tomto okamžiku je proces konfigurace IP dokončen.
Protokol očekává, že klient DHCP nakonfiguruje své síťové rozhraní s vyjednanými parametry.
Poté, co klient získá IP adresu, měl by prozkoumat nově přijatou adresu (např. Pomocí protokolu ARP Address Resolution Protocol ), aby se předešlo konfliktům adres způsobeným překrývajícím se adresním fondem serverů DHCP. Pokud tato sonda najde jiný počítač využívající tuto adresu, měl by počítač odeslat server DHCPDECLINE, broadcast.
Ethernet: zdroj = MAC odesílatele; destinace = MAC klienta |
|||
IP: zdroj = 192.168.1.1; destinace = 192.168.1.100 |
|||
Oktet 0 | Oktet 1 | Octet 2 | Octet 3 |
---|---|---|---|
OP | HTYPE | HLEN | CHMEL |
0x02 | 0x01 | 0x06 | 0x00 |
XID | |||
0x3903F326 | |||
SEKCE | VLAJKY | ||
0x0000 | 0x0000 | ||
CIADDR (IP adresa klienta) | |||
0x00000000 | |||
YIADDR (vaše IP adresa) | |||
0xC0A80164 (192.168.1.100) | |||
SIADDR (IP adresa serveru) | |||
0xC0A80101 (192.168.1.1) | |||
GIADDR (IP adresa brány přepínána relé) | |||
0x00000000 | |||
CHADDR (hardwarová adresa klienta) | |||
0x00053C04 | |||
0x8D590000 | |||
0x00000000 | |||
0x00000000 | |||
192 oktetů 0 s. BOOTP dědictví | |||
Kouzelný cookie | |||
0x63825363 | |||
Možnosti DHCP | |||
53: 5 (DHCP ACK) | |||
1 (maska podsítě): 255.255.255.0 | |||
3 (směrovač): 192.168.1.1 | |||
51 (doba pronájmu IP adresy): 86400s (1 den) | |||
54 (server DHCP): 192.168.1.1 | |||
6 (servery DNS):
|
Informace
Klient DHCP může požadovat více informací než server odeslaný s původním DHCPOFFER. Klient může také požadovat opakování dat pro konkrétní aplikaci. Prohlížeče například používají DHCP Inform k získání nastavení webového proxy prostřednictvím WPAD .
Uvolnění
Klient odešle požadavek serveru DHCP na uvolnění informací DHCP a klient deaktivuje svou IP adresu. Jelikož klientská zařízení obvykle nevědí, kdy je uživatelé mohou odpojit od sítě, protokol nezakazuje odesílání DHCP Release .
Konfigurační parametry klienta
Server DHCP může klientovi poskytovat volitelné konfigurační parametry. RFC 2132 popisuje dostupné možnosti DHCP definované úřadem Internet Assigned Numbers Authority (IANA) - DHCP a BOOTP PARAMETERS.
Klient DHCP může vybírat, manipulovat a přepisovat parametry poskytované serverem DHCP. V systémech podobných Unixu toto upřesnění na úrovni klienta obvykle probíhá podle hodnot v konfiguračním souboru /etc/dhclient.conf .
Možnosti
Možnosti jsou oktetové řetězce různé délky. Toto se nazývá kódování typu délka - hodnota . První oktet je kód opce, druhý oktet je počet následujících oktetů a zbývající oktety jsou závislé na kódu. Například možnost typu zprávy DHCP pro nabídku se zobrazí jako 0x35, 0x01, 0x02, kde 0x35 je kód 53 pro „typ zprávy DHCP“, 0x01 znamená, že následuje jeden oktet a 0x02 je hodnota „nabídky“.
Následující tabulky obsahují seznam dostupných možností DHCP uvedených v registrech RFC 2132 a IANA.
Kód | název | Délka | Poznámky |
---|---|---|---|
0 | Podložka | 0 oktetů | Lze použít k vyplnění dalších možností tak, aby byly zarovnány k hranici slova; není následován délkovým bajtem |
1 | Maska podsítě | 4 oktety | Musí být odesláno před možností routeru (možnost 3), pokud jsou zahrnuty oba |
2 | Časový posun | 4 oktety | |
3 | Router | Násobky 4 oktety | Dostupné směrovače by měly být uvedeny v pořadí podle preference |
4 | Časový server | Násobky 4 oktety | Dostupné časové servery, se kterými se má synchronizovat, by měly být uvedeny v pořadí podle preference |
5 | Jmenný server | Násobky 4 oktety | Dostupné jmenné servery IEN 116 by měly být uvedeny v pořadí podle preference |
6 | Server doménových jmen | Násobky 4 oktety | Dostupné servery DNS by měly být uvedeny v pořadí podle preference |
7 | Protokol server | Násobky 4 oktety | Dostupné protokolovací servery by měly být uvedeny v pořadí podle preference. |
8 | Cookie server | Násobky 4 oktety | Cookie v tomto případě znamená „fortune cookie“ nebo „citát dne“, drobná nebo vtipná anekdota často zasílaná jako součást přihlašovacího procesu na velkých počítačích; nemá to nic společného se soubory cookie odeslanými webovými stránkami . |
9 | Server LPR | Násobky 4 oktety | |
10 | Zapůsobit na server | Násobky 4 oktety | |
11 | Server umístění zdrojů | Násobky 4 oktety | |
12 | Jméno hostitele | Minimálně 1 oktet | |
13 | Velikost spouštěcího souboru | 2 oktety | Délka spouštěcího obrazu v blocích 4KiB |
14 | Soubor zásluh | Minimálně 1 oktet | Cesta, kde by měly být uloženy nouzové skládky |
15 | Doménové jméno | Minimálně 1 oktet | |
16 | Vyměnit server | 4 oktety | |
17 | Kořenová cesta | Minimálně 1 oktet | |
18 | Cesta rozšíření | Minimálně 1 oktet | |
255 | Konec | 0 oktetů | Slouží k označení konce pole možností dodavatele |
Kód | název | Délka | Poznámky |
---|---|---|---|
19 | Povolení/zakázání přesměrování IP | 1 oktet | |
20 | Povolení/zakázání směrování jiného než lokálního zdroje | 1 oktet | |
21 | Filtr zásad | Násobky 8 oktetů | |
22 | Maximální velikost opětovné montáže datagramu | 2 oktety | |
23 | Výchozí doba života IP | 1 oktet | |
24 | Časový limit stárnutí cesty MTU | 4 oktety | |
25 | Path MTU plateau table | Násobky 2 oktety |
Kód | název | Délka | Poznámky |
---|---|---|---|
26 | Rozhraní MTU | 2 oktety | |
27 | Všechny podsítě jsou místní | 1 oktet | |
28 | Adresa vysílání | 4 oktety | |
29 | Proveďte zjišťování masky | 1 oktet | |
30 | Dodavatel masky | 1 oktet | |
31 | Proveďte zjišťování routeru | 1 oktet | |
32 | Adresa pro vyžádání směrovače | 4 oktety | |
33 | Statická trasa | Násobky 8 oktetů | Seznam párů cíl/router |
Kód | název | Délka | Poznámky |
---|---|---|---|
34 | Možnost zapouzdření přívěsu | 1 oktet | |
35 | Časový limit mezipaměti ARP | 4 oktety | |
36 | Zapouzdření ethernetu | 1 oktet |
Kód | název | Délka | Poznámky |
---|---|---|---|
37 | TCP výchozí TTL | 1 oktet | |
38 | Interval udržování TCP | 4 oktety | |
39 | Keepalive smetí TCP | 1 oktet |
Kód | název | Délka | Poznámky |
---|---|---|---|
40 | Doména služby síťových informací | Minimálně 1 oktet | |
41 | Síťové informační servery | Násobky 4 oktety | |
42 | Servery NTP ( Network Time Protocol ) | Násobky 4 oktety | |
43 | Informace specifické pro dodavatele | Minimálně 1 oktet | |
44 | NetBIOS přes server jmen TCP/IP | Násobky 4 oktety | |
45 | NetBIOS přes datagram distribučního serveru TCP/IP | Násobky 4 oktety | |
46 | NetBIOS přes typ uzlu TCP/IP | 1 oktet | |
47 | NetBIOS přes rozsah TCP/IP | Minimálně 1 oktet | |
48 | Server písem X Window System | Násobky 4 oktety | |
49 | Správce zobrazení X Window System | Násobky 4 oktety | |
64 | Síťová informační služba + doména | Minimálně 1 oktet | |
65 | Síťová informační služba+ servery | Násobky 4 oktety | |
68 | Mobilní IP domácí agent | Násobky 4 oktety | |
69 | Server SMTP ( Simple Mail Transfer Protocol ) | Násobky 4 oktety | |
70 | Server Post Office Protocol (POP3) | Násobky 4 oktety | |
71 | Server NNTP ( Network News Transfer Protocol ) | Násobky 4 oktety | |
72 | Výchozí World Wide Web serveru (WWW) | Násobky 4 oktety | |
73 | Výchozí server protokolu Finger | Násobky 4 oktety | |
74 | Výchozí server IRC ( Internet Relay Chat ) | Násobky 4 oktety | |
75 | Server StreetTalk | Násobky 4 oktety | |
76 | Server StreetTalk Directory Assistance (STDA) | Násobky 4 oktety |
Kód | název | Délka | Poznámky |
---|---|---|---|
50 | Požadovaná IP adresa | 4 oktety | |
51 | Doba pronájmu IP adresy | 4 oktety | |
52 | Možnost přetížení | 1 oktet | |
53 | Typ zprávy DHCP | 1 oktet | |
54 | Identifikátor serveru | 4 oktety | |
55 | Seznam požadavků na parametry | Minimálně 1 oktet | |
56 | Zpráva | Minimálně 1 oktet | |
57 | Maximální velikost zprávy DHCP | 2 oktety | |
58 | Časová hodnota obnovy (T1) | 4 oktety | |
59 | Hodnota času opětovné vazby (T2) | 4 oktety | |
60 | Identifikátor třídy dodavatele | Minimálně 1 oktet | |
61 | Identifikátor klienta | Minimálně 2 oktety | |
66 | Název serveru TFTP | Minimálně 1 oktet | |
67 | Název spouštěcího souboru | Minimálně 1 oktet |
Typy zpráv DHCP
Tato tabulka uvádí typy zpráv DHCP, dokumentované v RFC 2132, RFC 3203, RFC 4388, RFC 6926 a RFC 7724. Tyto kódy jsou hodnotou v rozšíření 53 DHCP, jak je uvedeno v tabulce výše.
Kód | název | Délka | RFC |
---|---|---|---|
1 | DHCPDISCOVER | 1 oktet | rfc2132 |
2 | DHCPOFFER | 1 oktet | rfc2132 |
3 | DHCPREQUEST | 1 oktet | rfc2132 |
4 | DHCPDECLINE | 1 oktet | rfc2132 |
5 | DHCPACK | 1 oktet | rfc2132 |
6 | DHCPNAK | 1 oktet | rfc2132 |
7 | DHCPRELEASE | 1 oktet | rfc2132 |
8 | DHCPINFORM | 1 oktet | rfc2132 |
9 | DHCPFORCERENEW | 1 oktet | rfc3203 |
10 | DHCPLEASEQUERY | 1 oktet | rfc4388 |
11 | DHCPLEASEUNASSIGNED | 1 oktet | rfc4388 |
12 | DHCPLEASEUNKNOWNOWN | 1 oktet | rfc4388 |
13 | DHCPLEASEACTIVE | 1 oktet | rfc4388 |
14 | DHCPBULKLEASEQUERY | 1 oktet | rfc6926 |
15 | DHCPLEASEQUERYDONE | 1 oktet | rfc6926 |
16 | DHCPACTIVELEASEQUERY | 1 oktet | rfc7724 |
17 | DHCPLEASEQUERYSTATUS | 1 oktet | rfc7724 |
18 | DHCPTLS | 1 oktet | rfc7724 |
Identifikace dodavatele klienta
Existuje možnost identifikovat dodavatele a funkce klienta DHCP. Informace jsou řetězce znaků nebo oktetů s proměnnou délkou, jejichž význam je určen prodejcem klienta DHCP. Jednou z metod, kterou může klient DHCP komunikovat se serverem, který používá určitý typ hardwaru nebo firmwaru, je nastavit hodnotu v jeho požadavcích DHCP nazývanou identifikátor třídy dodavatele (VCI) (možnost 60). Tato metoda umožňuje serveru DHCP rozlišovat mezi těmito dvěma typy klientských počítačů a odpovídajícím způsobem zpracovávat požadavky ze dvou typů modemů. Některé typy set-top boxů také nastavují VCI (možnost 60), aby informovaly server DHCP o typu hardwaru a funkcích zařízení. Hodnota, na kterou je tato možnost nastavena, poskytuje serveru DHCP nápovědu o všech požadovaných dodatečných informacích, které tento klient potřebuje v odpovědi DHCP.
Další rozšíření
Kód | název | Délka | RFC |
---|---|---|---|
82 | Informace o agentovi relé | Minimálně 2 oktety | RFC 3046 |
85 | Servery Novell Directory Service (NDS) | Minimálně 4 oktety, násobek 4 oktetů | RFC 2241 |
86 | Název stromu NDS | Variabilní | RFC 2241 |
87 | Kontext NDS | Variabilní | RFC 2241 |
100 | Časové pásmo , styl POSIX | Variabilní | RFC 4833 |
101 | Časové pásmo , styl databáze tz | Variabilní | RFC 4833 |
114 | Captive-Portal DHCP | Variabilní | RFC 8910 |
119 | Hledání domény | Variabilní | RFC 3397 |
121 | Beztřídní statická trasa | Variabilní | RFC 3442 |
209 | Konfigurační soubor | Variabilní | RFC 5071 |
210 | Předpona cesty | Variabilní | RFC 5071 |
211 | Čas restartu | Variabilní | RFC 5071 |
Dílčí možnosti informací o reléovém agentovi
Možnost informace o agentovi přenosu (volba 82) určuje kontejner pro připojení dílčích možností k požadavkům DHCP přenášeným mezi přenosem DHCP a serverem DHCP.
Kód | název | Délka | RFC |
---|---|---|---|
1 | ID obvodu agenta | Minimálně 1 oktet | RFC 3046 |
2 | Agent Remote ID | Minimálně 1 oktet | RFC 3046 |
4 | Třída zařízení DOCSIS (Data-Over-Cable Service Interface Specification) | 4 oktety | RFC 3256 |
Relé
V malých sítích, kde je spravována pouze jedna podsíť IP, klienti DHCP komunikují přímo se servery DHCP. Servery DHCP však mohou také poskytovat adresy IP pro více podsítí. V tomto případě klient DHCP, který dosud nezískal IP adresu, nemůže komunikovat přímo se serverem DHCP, který není ve stejné podsíti, protože vysílání klienta lze přijímat pouze ve vlastní podsíti.
Aby mohli klienti DHCP v podsítích, které nejsou přímo obsluhovány servery DHCP, komunikovat se servery DHCP, lze do těchto podsítí nainstalovat agenty přenosu DHCP. Klient DHCP vysílá na místním odkazu; agent přenosu přijímá vysílání a přenáší ho na jeden nebo více serverů DHCP pomocí unicast . Agent přenosu ukládá vlastní IP adresu do pole GIADDR paketu DHCP. Server DHCP používá hodnotu GIADDR k určení podsítě, ve které agent přenosu obdržel vysílání, a v této podsíti přidělí adresu IP. Když server DHCP odpoví klientovi, odešle odpověď na adresu GIADDR, opět pomocí unicast. Agent přenosu pak znovu odešle odpověď v místní síti.
V této situaci komunikace mezi agentem přenosu a serverem DHCP obvykle používá zdrojový i cílový port UDP 67.
Stavy klientů
Jak je popsáno v RFC 2131, klient DHCP může přijímat tyto zprávy ze serveru:
- DHCPOFFER
- DHCPACK
- DHCPNAK
Klient se pohybuje ve stavech DHCP v závislosti na tom, jak server reaguje na zprávy, které klient odešle.
Spolehlivost
DHCP zajišťuje spolehlivost několika způsoby: pravidelná obnova, rebinding a převzetí služeb při selhání. Klientům DHCP jsou přiděleny leasingy, které trvají po určitou dobu. Klienti se začnou pokoušet obnovit své pronájmy, jakmile vyprší polovina intervalu pronájmu. Dělají to odesláním zprávy unicast DHCPREQUEST na server DHCP, který poskytl původní zapůjčení. Pokud je tento server nefunkční nebo nedostupný, neodpoví na DHCPREQUEST . V takovém případě však klient čas od času opakuje DHCPREQUEST , takže pokud se server DHCP obnoví nebo bude znovu dosažitelný, klient DHCP se mu podaří ho kontaktovat a obnovit zapůjčení.
Pokud je server DHCP delší dobu nedostupný, klient DHCP se pokusí o opětovné vytvoření vazby, a to tak , že bude vysílat svůj DHCPREQUEST, nikoli jej unicastovat . Protože je vysílána , zpráva DHCPREQUEST se dostane na všechny dostupné servery DHCP. Pokud je nějaký jiný server DHCP schopen obnovit zapůjčení, udělá to v tuto chvíli.
Aby rebinding fungoval, když klient úspěšně kontaktuje záložní server DHCP, musí mít tento server přesné informace o vazbě klienta. Udržování přesných vazebných informací mezi dvěma servery je komplikovaný problém; pokud jsou oba servery schopné aktualizovat stejnou zapůjčenou databázi, musí existovat mechanismus, který zabrání konfliktům mezi aktualizacemi na nezávislých serverech. Návrh na implementaci serverů DHCP odolných proti chybám byl předložen pracovní skupině pro internetové inženýrství, ale nikdy nebyl formalizován.
Pokud rebinding selže, nájemní smlouva nakonec vyprší. Po vypršení platnosti leasingu musí klient přestat používat IP adresu, která mu byla přidělena v jeho pronájmu. V té době restartuje proces DHCP od začátku vysíláním DHCPDISCOVER
zprávy. Vzhledem k tomu, že jeho pronájem vypršel, bude přijímat jakoukoli IP adresu, která mu bude nabídnuta. Jakmile bude mít novou IP adresu (pravděpodobně z jiného serveru DHCP), bude moci znovu používat síť. Protože se však jeho IP adresa změnila, všechna probíhající připojení budou přerušena.
Sítě IPv6
Základní metodika DHCP byla vyvinuta pro sítě založené na internetovém protokolu verze 4 (IPv4). Od vývoje a nasazení sítí IPv6 se DHCP používá také k přiřazování parametrů v těchto sítích, a to navzdory inherentním funkcím IPv6 pro automatickou konfiguraci adres bez státní příslušnosti . Verze protokolu IPv6 je označena jako DHCPv6 .
Bezpečnostní
Základní DHCP neobsahuje žádný mechanismus ověřování. Z tohoto důvodu je zranitelný vůči řadě útoků. Tyto útoky spadají do tří hlavních kategorií:
- Neautorizované servery DHCP poskytující klientům nepravdivé informace.
- Neautorizovaní klienti získávají přístup ke zdrojům.
- Útoky vyčerpání zdrojů ze škodlivých klientů DHCP.
Protože klient nemá možnost ověřit identitu serveru DHCP, lze v sítích provozovat neautorizované servery DHCP (běžně nazývané „ nepoctiví DHCP “), které klientům DHCP poskytují nesprávné informace. To může sloužit buď jako útok odmítnutí služby, který brání klientovi v získání přístupu k připojení k síti, nebo jako útok typu man-in-the-middle . Protože server DHCP poskytuje klientovi DHCP adresy IP serveru, například adresu IP jednoho nebo více serverů DNS, může útočník přesvědčit klienta DHCP, aby provedl vyhledávání DNS prostřednictvím svého vlastního serveru DNS, a proto může poskytnout vlastní odpovědi. na dotazy DNS od klienta. To zase umožňuje útočníkovi přesměrovat síťový provoz přes sebe, což mu umožňuje odposlouchávat spojení mezi klientem a síťovými servery, které kontaktuje, nebo tyto síťové servery jednoduše nahradit svými vlastními.
Protože server DHCP nemá žádný zabezpečený mechanismus pro ověřování klienta, mohou klienti získat neoprávněný přístup k adresám IP předložením přihlašovacích údajů, jako jsou identifikátory klientů, které patří jiným klientům DHCP. To také umožňuje klientům DHCP vyčerpat úložiště IP adres serveru DHCP - tím, že klient předloží nová pověření pokaždé, když požádá o adresu, může spotřebovat všechny dostupné IP adresy na konkrétním síťovém propojení, což brání ostatním klientům DHCP v poskytování služeb.
DHCP poskytuje některé mechanismy ke zmírnění těchto problémů. Relay Agent Informace Možnost rozšíření protokolu (RFC 3046, obvykle odkazoval se na v průmyslu jejím skutečným počtem as Varianta 82 ) umožňuje provozovatelům sítí připojit značky ke zprávám DHCP, protože tyto zprávy dorazí na důvěryhodné sítě operátora. Tato značka se poté použije jako autorizační token k řízení přístupu klienta k síťovým prostředkům. Protože klient nemá přístup k síti před agentem přenosu, nedostatek ověřování nezabrání operátorovi serveru DHCP spoléhat se na autorizační token.
Další rozšíření, Authentication for DHCP Messages ( RFC 3118 ), provides a mechanism for authentication DHCP messages. Jak 2002, RFC 3118 neviděl rozsáhlé přijetí kvůli problémům se správou klíčů pro velký počet klientů DHCP. Kniha z roku 2007 o technologiích DSL poznamenala, že:
proti bezpečnostním opatřením navrženým RFC 3118 byla identifikována řada bezpečnostních chyb. Tato skutečnost v kombinaci se zavedením standardu 802.1x zpomalila nasazení a rychlost přijímání ověřeného DHCP a nikdy nebyla široce nasazena.
Kniha z roku 2010 uvádí, že:
[t] zde bylo velmi málo implementací ověřování DHCP. Výzvy spojené se zpožděním správy a zpracování v důsledku výpočtu hash byly považovány za příliš vysokou cenu za vnímané výhody.
Architektonické návrhy z roku 2008 zahrnují autentizaci požadavků DHCP pomocí 802.1x nebo PANA (oba transportují EAP ). Byl předložen návrh IETF na zahrnutí EAP do samotného DHCP, takzvaného EAPoDHCP ; nezdá se, že by to pokročilo nad úroveň návrhu IETF, z nichž poslední se datuje do roku 2010.
Dokumenty standardů IETF
- RFC 2131 , Dynamic Host Configuration Protocol
- RFC 2132 , možnosti DHCP a rozšíření BOOTP Vendor
- RFC 3046 , možnost informací o agentu DHCP Relay Agent
- RFC 3397 , možnost vyhledávání v doméně Dynamic Host Configuration Protocol (DHCP)
- RFC 3942 , reklasifikace možností protokolu Dynamic Host Configuration Protocol verze čtyři (DHCPv4)
- RFC 4242 , Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
- RFC 4361 , identifikátory klientů specifické pro uzel pro protokol Dynamic Host Configuration Protocol verze čtyři (DHCPv4)
- RFC 4436 , Detection Network Attachment in IPv4 (DNAv4)
- RFC 3442 , možnost bez statické trasy pro protokol DHCP (Dynamic Host Configuration Protocol) verze 4
- RFC 3203 , rozšíření rekonfigurace DHCP
- RFC 4388 , Dynamic Host Configuration Protocol (DHCP) Leasequery
- Hromadný leasingový dotaz RFC 6926 , DHCPv4
- RFC 7724 , aktivní dotaz na pronájem DHCPv4
Viz také
- Boot Service Discovery Protocol (BSDP) - rozšíření DHCP používané NetBootem společnosti Apple
- Porovnání softwaru serveru DHCP
- Peg DHCP (RFC 2322)
- Prostředí před spuštěním (PXE)
- Protokol pro rozlišení obrácené adresy (RARP)
- Rogue DHCP
- Pomocná adresa UDP - nástroj pro směrování požadavků DHCP přes hranice podsítě
- Zeroconf - Síť s nulovou konfigurací
Poznámky
Reference
externí odkazy
- Média související s protokolem Dynamic Host Configuration Protocol (DHCP) na Wikimedia Commons