DHCP, protokol dynamické konfigurace hostitelského počítače - Dynamic Host Configuration Protocol - Wikipedia

The DHCP, protokol dynamické konfigurace hostitelského počítače (DHCP) je protokol pro správu sítě použitý na internetový protokol (IP) sítí, přičemž DHCP serveru dynamicky přiřadí IP adresa a další konfigurační parametry sítě ke každému zařízení v síti, aby mohla komunikovat s jinými sítěmi IP.^[1] Server DHCP umožňuje počítačům žádost IP adresy a síťové parametry automaticky z poskytovatel internetu (ISP), což snižuje potřebu a správce sítě nebo a uživatel ručně přiřadit adresy IP všem síťovým zařízením.^[1] Pokud není k dispozici server DHCP, je třeba počítači nebo jinému zařízení v síti ručně přidělit adresu IP nebo si přiřadit APIPA adresa, která mu neumožní komunikovat mimo místní adresu podsíť.

DHCP lze implementovat v sítích o velikosti od domácí sítě na velké kampusové sítě a regionální sítě ISP.^[2] A router nebo a obytná brána lze povolit, aby fungoval jako server DHCP. Většina rezidenčních síťových routerů obdrží a celosvětově jedinečný IP adresa v síti ISP. V místní síti přiděluje server DHCP každému zařízení připojenému k síti místní adresu IP.

Dějiny

V roce 1984 Protokol pro reverzní řešení adres (RARP), definované v RFC 903, byl zaveden, aby umožňoval jednoduchá zařízení jako např bezdiskové pracovní stanice dynamicky získat vhodnou IP adresu. Protože však jednalo u vrstva datového spojení znesnadnilo implementaci na mnoha serverových platformách a také vyžadovalo, aby byl na každém jednotlivém síťovém odkazu přítomen server. RARP byl nahrazen protokolem Bootstrap (BOOTP ) definované v RFC 951 v září 1985. Tím byl představen koncept a přenosový agent, což umožnilo předávání paketů BOOTP napříč sítěmi, což umožnilo jednomu centrálnímu serveru BOOTP obsluhovat hostitele v mnoha podsítích IP.^[3]

Protokol DHCP je založen na protokolu BOOTP, ale může dynamicky přidělovat adresy IP ze fondu a znovu je získat, když se již nepoužívají. Lze jej také použít k dodání široké škály dalších konfiguračních parametrů klientům IP, včetně parametrů specifických pro platformu.^[4] 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 typ zprávy DHCPINFORM^[5] a další malé změny přidal uživatel RFC 2131; který od roku 2014^{[Aktualizace]} zůstává standardem pro sítě IPv4.

DHCPv6 byl původně popsán uživatelem RFC 3315 v roce 2003, ale toto bylo aktualizováno mnoha následnými RFC.^[6] RFC 3633 přidal mechanismus DHCPv6 pro delegování předpony, a bezstavová automatická konfigurace adresy přidal uživatel RFC 3736.

Přehled

internetový protokol (IP) definuje, jak zařízení komunikují v rámci místních sítí na internetu a mezi nimi. Server DHCP může spravovat nastavení IP pro zařízení v místní síti, například automatickým a dynamickým přiřazováním adres IP těmto zařízením.

DHCP funguje na základě model klient-server. Když se počítač nebo jiné zařízení připojí k síti, odešle klientský software DHCP DHCP přenos dotaz požadující potřebné informace. Žádost může zpracovat jakýkoli server DHCP v síti. Server DHCP spravuje skupinu adres IP a informace o konfiguračních parametrech klienta, například výchozí brána, doménové jméno, jmenné servery, a časové servery. Po obdržení požadavku DHCP může server DHCP odpovědět konkrétními informacemi pro každého klienta, jak byly dříve nakonfigurovány správcem, nebo konkrétní adresou a jakýmikoli dalšími informacemi platnými pro celou síť a po dobu, po kterou je přidělení (pronájem) je platný. Klient DHCP obvykle vyhledá tyto informace ihned poté bootování, a pravidelně poté před vypršením platnosti informací. Když klient DHCP obnoví 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í stanovených správci.

Ve velkých sítích, které se skládají z více odkazů, může jeden server DHCP obsluhovat celou síť, pokud jsou podporováni agenty přenosu DHCP umístěnými na propojovacích směrovačích. Tito agenti přenášejí 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í adres IP:

Dynamická alokace

A správce sítě vyhrazuje rozsah adres IP pro DHCP a každého klienta DHCP na serveru LAN je nakonfigurován tak, aby vyžadoval IP adresu z DHCP serveru během inicializace sítě. Proces požadavku a udělení používá koncept zapůjčení s kontrolovatelným časovým obdobím, což umožňuje serveru DHCP získat zpět a znovu přidělit adresy IP, které se neobnovují.

Automatické přidělování

Server DHCP trvale přiřadí IP adresu žádajícímu klientovi z rozsahu definovaného správcem. Je to jako dynamická alokace, ale server DHCP uchovává tabulku minulých přiřazení adres IP, aby mohl přednostně přiřadit klientovi stejnou adresu IP, kterou měl klient dříve.

Ruční alokace

Také se běžně nazývá statická alokace a výhrady. Server DHCP vydává soukromou adresu IP v závislosti na každém klientovi ID klienta (nebo tradičně klient MAC adresa ), na základě předdefinovaného mapování správcem. Tato funkce se nazývá různě statické přiřazení DHCP podle DD-WRT, pevná adresa dokumentací dhcpd, Rezervace adresy podle Netgear, DHCP rezervace nebo statický DHCP podle Cisco a Linksys, a Rezervace IP adresy nebo Vazba MAC / IP adresy od různých jiných výrobců routerů. Pokud neexistuje shoda pro klienta ID klienta (je-li k dispozici) nebo MAC adresa (pokud není zadáno žádné ID klienta), server může nebo nemusí spadnout zpět na dynamickou nebo automatickou alokaci.

DHCP se používá pro Internetový protokol verze 4 (IPv4) a IPv6. Zatímco obě verze slouží stejnému účelu, podrobnosti protokolu pro IPv4 a IPv6 se dostatečně liší, takže je lze považovat za samostatné protokoly.^[7] Pro provoz IPv6 mohou zařízení alternativně používat bezstavová automatická konfigurace adresy. Hostitelé protokolu IPv6 mohou také použít link-local adresování k dosažení operací omezených na místní síťové spojení.

Úkon

Ilustrace typické neobnovující se relace DHCP; každá zpráva může být buď vysílání, nebo unicast, v závislosti na možnostech klienta DHCP.^[8]

DHCP zaměstnává a bez připojení model služby pomocí Protokol uživatele Datagram (UDP). Je implementován se dvěma čísly portů UDP pro své operace, která jsou stejná jako pro bootstrap protokol (BOOTP ). UDP port číslo 67 je cílový port serveru a UDP port číslo 68 používá klient.

Operace DHCP spadají do čtyř fází: zjišťování serverů, nabídka pronájmu IP, požadavek na pronájem IP a potvrzení IP pronájmu. Tyto fáze jsou často zkráceny jako DORA pro objev, nabídku, požadavek a potvrzení.

Operace DHCP začíná u klientů vysílání žádost. Pokud jsou klient a server v různých podsítích, a Pomocník DHCP nebo Agent přenosu DHCP může být použit. Klienti požadující obnovení stávajícího nájmu mohou komunikovat přímo přes 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é příznaky, kde jsou všechny ostatní bity rezervovány a jsou tedy nastaveny na 0), pomocí kterých může klient označit, jakým způsobem (všesměrové nebo unicast) může přijímat DHCPOFFER: 0x8000 pro vysílání, 0x0000 pro unicast.^[8] DHCPOFFER se obvykle odesílá prostřednictvím jednosměrového vysílání. U těch hostitelů, kteří nemohou přijímat pakety jednosměrového vysílání před konfigurací adres IP, lze tento problém vyřešit pomocí tohoto příznaku.

Objev

Klient DHCP vysílá zprávu DHCPDISCOVER v síťové podsíti pomocí cílové adresy 255.255.255.255 (omezené vysílání) nebo konkrétní vysílací adresy podsítě (směrované vysílání). Klient DHCP může také požadovat svoji poslední známou IP adresu. Pokud klient zůstane připojen ke stejné síti, může mu server vyhovět. Jinak záleží na tom, zda je server nastaven jako autoritativní nebo ne. Autoritativní server požadavek popírá, což způsobí, že klient vydá nový požadavek. Neautoritativní server jednoduše ignoruje požadavek, což vede k časovému limitu závislému na implementaci, kdy klient vyprší platnost požadavku a požádá o novou IP adresu.

Pokud je například HTYPE nastaven na 1, můžete určit, že použité médium je Ethernet, HLEN je nastavena na 6, protože ethernetová adresa (MAC adresa) je 6 oktetů dlouhá. CHADDR je nastaven na MAC adresu používanou klientem. Jsou nastaveny také některé možnosti.

Nabídka

Když server DHCP obdrží zprávu DHCPDISCOVER od klienta, což je požadavek na zapůjčení adresy IP, server DHCP rezervuje adresu IP pro klienta a učiní nabídku zapůjčení zaslá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 pronájmu a IP adresu DHCP serveru, který nabídku nabízí. Server DHCP může také zaznamenat adresu MAC na hardwarové úrovni v podkladové transportní vrstvě: podle aktuálního RFC MAC adresa transportní vrstvy může být použita, pokud není v paketu DHCP poskytnuto žádné ID klienta.

Server DHCP určuje konfiguraci na základě hardwarové adresy klienta uvedené v poli CHADDR (hardwarová adresa klienta). Zde server, 192.168.1.1, určuje IP adresu klienta do pole YIADDR (vaše IP adresa).

Žádost

V reakci na nabídku DHCP klient odpoví zprávou DHCPREQUEST, vyslanou na server,^[A] požadování nabízené adresy. Klient může přijímat nabídky DHCP z více serverů, ale přijme pouze jednu nabídku DHCP. Klient vytvoří nevděčný ARP, aby zjistil, zda je v síti nějaký jiný hostitel se stejnou adresou IP. Pokud jiný hostitel neodpovídá, není v síti žádný hostitel se stejnou konfigurací TCP a zpráva je vysílána na server s přijetím IP adresy. Na základě požadováno identifikace serveru v požadavku a vysílání zpráv jsou informovány servery, jejichž nabídku klient přijal.^{[10]:Oddíl 3.1, bod 3} Když ostatní servery DHCP obdrží tuto zprávu, stáhnou všechny nabídky, které klientovi učinily, a vrátí nabízenou IP adresu do fondu dostupných adres.

Potvrzení

Když server DHCP přijme od klienta zprávu DHCPREQUEST, proces konfigurace přejde do konečné fáze. Fáze potvrzení zahrnuje odeslání paketu DHCPACK klientovi. Tento paket obsahuje dobu pronájmu a další informace o konfiguraci, které klient mohl požadovat. V tomto okamžiku je proces konfigurace IP dokončen.

Protokol očekává, že klient DHCP nakonfiguruje své síťové rozhraní podle sjednaných parametrů.

Poté, co klient získá adresu IP, měl by prověřit nově přijatou adresu^[11] (např. s ARP Protokol pro řešení adres ), aby se zabránilo konfliktům adres způsobeným překrývajícími se skupinami adres serverů DHCP.

Informace

Klient DHCP může požadovat více informací než server odeslaný s původním DHCPOFFER. Klient může také požadovat opakovaná data pro konkrétní aplikaci. Používají například prohlížeče DHCP Inform získat nastavení webového proxy prostřednictvím WPAD.

Uvolnění

Klient odešle požadavek na server DHCP, aby uvolnil informace DHCP, a deaktivuje svou IP adresu. Protože klientská zařízení obvykle neví, kdy je uživatelé mohou odpojit od sítě, protokol nezadává odeslání Uvolnění DHCP.

Konfigurační parametry klienta

Server DHCP může klientovi poskytovat volitelné konfigurační parametry. RFC 2132 popisuje dostupné možnosti DHCP definované Autorita pro internetová přidělená čísla (IANA) - PARAMETRY DHCP a BOOTP.^[12]

Klient DHCP může vybírat, manipulovat a přepisovat parametry poskytované serverem DHCP. V systémech podobných Unixu se toto zdokonalování na úrovni klienta obvykle provádí podle hodnot v konfiguračním souboru /etc/dhclient.conf.

Možnosti

Možnosti jsou oktetové řetězce různé délky. První oktet je kód možnosti, 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 by se zobrazila 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 „offer“.

Zdokumentováno v RFC 2132

Následující tabulky obsahují seznam dostupných možností DHCP, jak jsou uvedeny v RFC 2132^[13] a registr IANA.^[12]

Typy zpráv DHCP

Tato tabulka uvádí typy zpráv DHCP, dokumentované v RFC 2132, RFC 3203,^[14] RFC 4388,^[15] RFC 6926^[16] a RFC 7724.^[17] Tyto kódy jsou hodnotou v rozšíření DHCP 53, které je uvedeno v tabulce výše.

Identifikace dodavatele klienta

Existuje možnost identifikovat dodavatele a funkce klienta DHCP. Informace je a řetězec s proměnnou délkou znaků nebo oktetů, což má význam určený prodejcem klienta DHCP. Jednou z metod, kterými může klient DHCP komunikovat se serverem, že používá určitý typ hardwaru nebo firmwaru, je nastavení hodnoty v požadavcích DHCP s názvem Identifikátor třídy dodavatele (VCI) (možnost 60). Tato metoda umožňuje serveru DHCP rozlišovat mezi dvěma druhy klientských počítačů a odpovídajícím způsobem zpracovávat požadavky od těchto dvou typů modemů. Některé typy set-top boxy také nastavte VCI (možnost 60), aby informovala server DHCP o typu hardwaru a funkčnosti zařízení. Hodnota, na kterou je tato možnost nastavena, dává serveru DHCP nápovědu k veškerým požadovaným doplňkovým informacím, které tento klient potřebuje v odpovědi DHCP.

Zdokumentováno jinde

Dílčí možnosti informace o přenosovém agentovi

Možnost informace o přenosovém agentovi (možnost 82)^[18] Určuje kontejner pro připojení dílčích možností k požadavkům DHCP přenášeným mezi relé DHCP a serverem DHCP.

Přenos

V malých sítích, kde je spravována pouze jedna podsíť IP, komunikují klienti DHCP 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ý ještě nezískal adresu IP, nemůže komunikovat přímo se serverem DHCP pomocí směrování IP, protože nemá směrovatelnou adresu IP, nezná adresu linkové vrstvy routeru a nezná IP adresa DHCP serveru.

Aby mohli klienti DHCP v podsítích, které nejsou přímo obsluhovány servery DHCP, komunikovat se servery DHCP, mohou být do těchto podsítí nainstalováni agenti přenosu DHCP. Klient DHCP vysílá na místním odkazu; přenosový agent přijímá vysílání a přenáší jej na jeden nebo více serverů DHCP pomocí unicast. Reléový agent ukládá do pole svoji vlastní IP adresu GIADDR pole paketu DHCP. Server DHCP používá hodnotu GIADDR k určení podsítě, ve které přenosový agent přijal vysílání, a přiděluje IP adresu v této podsíti. Když server DHCP odpoví klientovi, odešle odpověď na adresu GIADDR, opět pomocí jednosměrového vysílání. Agent přenosu poté znovu odešle odpověď v místní síti.

V této situaci komunikace mezi přenosovým agentem a serverem DHCP obvykle používá zdrojový i cílový UDP port 67.

Státy klienta

Zjednodušený diagram přechodu stavu klienta DHCP založený na obrázku 5 RFC 2131.

Jak je popsáno v RFC 2131,^{[10]:Oddíl 4.4} klient DHCP může přijímat tyto zprávy ze serveru:

• DHCPOFFER
• DHCPACK
• DHCPNAK

Klient se pohybuje stavy 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: periodická obnova, rebinding,^{[10]:Oddíl 4.4.5} 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čínají pokoušet obnovit své nájmy, jakmile vyprší polovina intervalu nájmu.^{[10]:Oddíl 4.4.5 Odstavec 3} Dělají to odesláním jednosměrového vysílání DHCPREQUEST zpráva na server DHCP, který udělil původní zapůjčení. Pokud je tento server nefunkční nebo nedosažitelný, nebude reagovat na server DHCPREQUEST. V takovém případě však klient opakuje DHCPREQUEST čas od času,^{[10]:Oddíl 4.4.5 Odstavec 8[b]} takže pokud se server DHCP vrátí zpět nebo se stane znovu dosažitelným, klient DHCP se mu podaří kontaktovat a obnovit zapůjčení.

Pokud je server DHCP po delší dobu nedostupný,^{[10]:Oddíl 4.4.5 Odstavec 5} klient DHCP se pokusí znovu vytvořit vazbu tím, že vysílá svůj DHCPREQUEST spíše než rozesílání. Protože to je přenos, DHCPREQUEST zpráva se dostane na všechny dostupné servery DHCP. Pokud je jiný DHCP server schopen obnovit zapůjčení, učiní tak v tuto chvíli.

Aby zpětné vazby fungovaly, 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 informací o vazbě mezi dvěma servery je komplikovaný problém; pokud jsou oba servery schopny aktualizovat stejnou databázi nájmu, musí existovat mechanismus, který zabrání konfliktům mezi aktualizacemi na nezávislých serverech. Návrh na provedení tolerantní k chybám Servery DHCP byly odeslány pracovní skupině Internet Engineering Task Force, ale nikdy nebyly formalizovány.^[24][C]

Pokud vazba selže, nájemní smlouva nakonec skončí. Po vypršení platnosti nájmu musí klient přestat ve svém nájmu používat IP adresu, která mu byla přidělena.^{[10]:Oddíl 4.4.5 Odstavec 9} V tom okamžiku restartuje proces DHCP od začátku vysíláním a DHCPDISCOVER zpráva. Vzhledem k tomu, že jeho leasing vypršel, bude přijímat jakoukoli IP adresu, která mu bude nabídnuta. Jakmile bude mít novou adresu IP (pravděpodobně z jiného serveru DHCP), bude moci znovu používat síť. Protože se však změnila jeho IP adresa, dojde k přerušení veškerých probíhajících připojení.

Moderní aplikace

Jak 2018, DHCP zůstává široce používán pro automatické přidělování IP adres.^[25] Novější iterace pro přiřazování IP adres zahrnují DHCPv6 a SLAAC.^[25]

Bezpečnostní

Základní DHCP neobsahuje žádný mechanismus pro autentizaci.^[26] Z tohoto důvodu je zranitelný vůči různým útokům. Tyto útoky spadají do tří hlavních kategorií:

• Neoprávněné servery DHCP poskytující klientům nepravdivé informace.^[27]
• Neoprávnění klienti získávají přístup ke zdrojům.^[27]
• Útoky vyčerpání zdrojů od škodlivých klientů DHCP.^[27]

Protože klient nemá žádný způsob, jak ověřit identitu serveru DHCP, neautorizované servery DHCP (běžně nazývané „nepoctivý DHCP ") lze provozovat v sítích a poskytovat nesprávné informace klientům DHCP.^[28] To může sloužit buď jako útok typu odmítnutí služby, který klientovi brání v získání přístupu k síťovému připojení,^[29] nebo jako útok man-in-the-middle.^[30] Protože server DHCP poskytuje klientovi DHCP adresy IP serveru, například adresu IP jednoho nebo více serverů DNS,^[27] útočník může přesvědčit klienta DHCP, aby vyhledával DNS prostřednictvím svého vlastního serveru DNS, a může proto poskytovat své vlastní odpovědi na dotazy DNS od klienta.^[31][32] To zase umožňuje útočníkovi přesměrovat síťový provoz přes sebe, což mu umožňuje odposlouchávat připojení mezi klientem a síťovými servery, které kontaktuje, nebo tyto síťové servery jednoduše nahradit vlastními.^[31]

Vzhledem k tomu, že server DHCP nemá zabezpečený mechanismus pro ověřování klienta, mohou klienti získat neoprávněný přístup k IP adresám předložením pověření, jako jsou identifikátory klientů, které patří ostatním klientům DHCP.^[28] To také umožňuje klientům DHCP vyčerpat úložiště IP adres serveru DHCP - předložením nových pověření pokaždé, když požádá o adresu, může klient spotřebovat všechny dostupné adresy IP na konkrétním síťovém odkazu a zabránit ostatním klientům DHCP získat službu.^[28]

DHCP poskytuje některé mechanismy pro zmírnění těchto problémů. The Možnost Informace o přenosovém agentovi rozšíření protokolu (RFC 3046, v průmyslu obvykle označovaný skutečným počtem jako Možnost 82^[33][34]) umožňuje operátorům sítě připojit značky ke zprávám DHCP, jakmile tyto zprávy dorazí do důvěryhodné sítě operátora. Tato značka se poté použije jako autorizační token pro řízení přístupu klienta k síťovým prostředkům. Vzhledem k tomu, že klient nemá žádný přístup k síti proti proudu od přenosového agenta, nedostatek ověřování nezabrání operátorovi serveru DHCP spoléhat se na autorizační token.^[26]

Další rozšíření, Ověření pro zprávy DHCP (RFC 3118 ), poskytuje mechanismus pro ověřování zpráv DHCP. Jak 2002, RFC 3118 nezaznamenal široké přijetí kvůli problémům se správou klíčů pro velký počet klientů DHCP.^[35] Kniha o technologiích DSL z roku 2007 poznamenala, že:

bylo zjištěno mnoho bezpečnostních slabin vůči bezpečnostním opatřením navrženým RFC 3118. Tato skutečnost v kombinaci se zavedením 802.1x, zpomalil nasazení a rychlost ověřeného DHCP a nikdy nebyl široce nasazen.^[36]

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 hodnoty hash byly považovány za příliš vysokou cenu na zaplacení vnímaných výhod.^[37]

Architektonické návrhy od roku 2008 zahrnují ověřování požadavků DHCP pomocí 802.1x nebo PANA (oba transport EAP ).^[38] Byl vytvořen návrh IETF na zahrnutí EAP do samotného DHCP, tzv EAPoDHCP;^[39] nezdá se, že by došlo k překročení úrovně konceptu IETF, z nichž poslední se datuje rokem 2010.^[40]

Dokumenty standardů IETF

• RFC 2131, DHCP, protokol dynamické konfigurace hostitelského počítače
• RFC 2132, Možnosti DHCP a Rozšíření dodavatele BOOTP
• RFC 3046 Možnost Informace o přenosovém agentovi DHCP
• RFC 3397, Možnost hledání domény pomocí protokolu DHCP (Dynamic Host Configuration Protocol)
• RFC 3942 „Reklasifikace možností protokolu Dynamic Host Configuration Protocol verze čtyři (DHCPv4)
• RFC 4242, Možnost Čas aktualizace informací pro protokol Dynamic Host Configuration Protocol pro IPv6
• RFC 4361 „Identifikátory klienta specifické pro uzel pro protokol Dynamic Host Configuration Protocol verze čtyři (DHCPv4)
• RFC 4436, Detekce síťového připojení v IPv4 (DNAv4)
• RFC 3442 Možnost Classless Static Route pro protokol Dynamic Host Configuration Protocol (DHCP) verze 4
• RFC 3203, DHCP překonfigurovat příponu
• RFC 4388, Leasequery, Dynamic Host Configuration Protocol (DHCP)
• RFC 6926, Hromadný dotaz na DHCPv4
• RFC 7724 „Aktivní dotaz na zapůjčení DHCPv4

Viz také

Poznámky

Reference

externí odkazy

• Média související s Dynamic Host Configuration Protocol (DHCP) na Wikimedia Commons