Dynamic Host Configuration Protocol: Difference between revisions
Jump to navigation
Jump to search
| [unchecked revision] | [unchecked revision] |
imported>BrainStack Link suggestions feature: 3 links added. |
imported>Indefatigable →Options: {{sticky header}} |
||
| Line 1: | Line 1: | ||
{{short description|Principal protocol used to assign IPv4 addresses on an IPv4 network}} | {{short description|Principal protocol used to assign IPv4 addresses on an IPv4 network}} | ||
{{Expand language|topic=|langcode=Ar|otherarticle=بروتوكول تهيئة المضيف الآلية|date=May 2026}} | |||
{{hatnote group| | {{hatnote group| | ||
{{Redirect|DHCP}} | {{Redirect|DHCP}} | ||
{{Confusion|HDCP}} | {{Confusion|HDCP}} | ||
}} | |||
{{Infobox technology standard | |||
| title = Dynamic Host Configuration Protocol | |||
| long_name = | |||
| image = | |||
DHCP Client-Server model - en.png | |||
| image_size = | |||
| alt = | |||
| caption = The dynamic host configuration protocol (DHCP) according to client/server model, as well as the traffic routing types between the components of the protocol topology. | |||
| abbreviation = | |||
| native_name = <!-- Name in local language. If more than one, separate using {{plain list}} --> | |||
| native_name_lang = <!-- ISO 639-1 code e.g. "fr" for French. If more than one, use {{lang}} inside native_name items instead --> | |||
| status = Active | |||
| year_started = {{Start date and age|1993|10|df=y}} | |||
| first_published = <!-- {{Start date|YYYY|MM|DD|df=y}} --> | |||
| version = | |||
| version_date = | |||
| preview = | |||
| preview_date = | |||
| organization = | |||
| committee = | |||
| series = | |||
| editors = | |||
| authors = | |||
| base_standards = RFC 1531 | |||
| related_standards = | |||
| predecessor = | |||
| successor = | |||
| domain = | |||
| license = | |||
| copyright = | |||
| website = <!-- {{URL|example.com}} --> | |||
}} | }} | ||
{{Internet protocol suite}} | {{Internet protocol suite}} | ||
| Line 32: | Line 65: | ||
;Dynamic allocation: A [[network administrator]] reserves a range of IP addresses for DHCP, and each DHCP client on the [[LAN]] is configured to request an IP address from the DHCP [[Server (computing)|server]] during network initialization. The request-and-grant process uses a lease concept with a controllable time period, allowing the DHCP server to reclaim and then reallocate IP addresses that are not renewed. | ;Dynamic allocation: A [[network administrator]] reserves a range of IP addresses for DHCP, and each DHCP client on the [[LAN]] is configured to request an IP address from the DHCP [[Server (computing)|server]] during network initialization. The request-and-grant process uses a lease concept with a controllable time period, allowing the DHCP server to reclaim and then reallocate IP addresses that are not renewed. | ||
;Automatic allocation: The DHCP server permanently assigns an IP address to a requesting client from a range defined by an administrator. This is like dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had. | ;Automatic allocation: The DHCP server permanently assigns an IP address to a requesting client from a range defined by an administrator. This is like dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had. | ||
;Manual allocation: This method is also variously called ''static DHCP allocation'', ''fixed address allocation'', ''reservation'', and ''MAC/IP address binding''. An administrator maps a unique identifier (a ''client id'' or [[MAC address]]) for each client to an IP address, which is offered to the requesting client. DHCP servers may be configured to fall back to other methods if this fails. | ;Manual allocation: This method is also variously called ''static DHCP allocation'', ''fixed address allocation'', ''reservation'', and ''MAC/IP address binding''. An administrator maps a unique identifier (a ''client id'' or [[MAC address]]) for each client to an IP address, which is offered to the requesting client. DHCP servers may be configured to fall back to other methods if this fails. | ||
DHCP services are used for [[Internet Protocol version 4]] (IPv4) and [[IPv6]]. The details of the protocol for IPv4 and IPv6 differ sufficiently that they may be considered separate protocols.<ref>{{cite book |title = The DHCP Handbook |year = 2003 |isbn = 978-0-672-32327-0 |first1= Ralph |last1=Droms |first2= Ted |last2=Lemon |publisher = [[SAMS Publishing]] |page = 436 }}</ref> For the IPv6 operation, devices may alternatively use | DHCP services are used for [[Internet Protocol version 4]] (IPv4) and [[IPv6]]. The details of the protocol for IPv4 and IPv6 differ sufficiently that they may be considered separate protocols.<ref>{{cite book |title = The DHCP Handbook |year = 2003 |isbn = 978-0-672-32327-0 |first1= Ralph |last1=Droms |first2= Ted |last2=Lemon |publisher = [[SAMS Publishing]] |page = 436 }}</ref> For the IPv6 operation, devices may alternatively use stateless address autoconfiguration. IPv6 hosts may also use [[link-local addressing]] to achieve operations restricted to the local network link. | ||
==Operation== | ==Operation== | ||
| Line 49: | Line 80: | ||
===Discovery=== | ===Discovery=== | ||
The DHCP client | The DHCP client broadcasts a DHCPDISCOVER message on the network subnet using the destination address {{IPaddr|255.255.255.255}} (limited broadcast) or the specific subnet [[broadcast address]] (directed broadcast). A DHCP client may also request an IP address in the DHCPDISCOVER, which the server may take into account when selecting an address to offer. | ||
For example, if HTYPE is set to 1, to specify that the medium used is [[Ethernet]], HLEN is set to 6 because an Ethernet address (MAC address) is 6 octets long. The CHADDR is set to the MAC address used by the client. Some options are set as well. | For example, if HTYPE is set to 1, to specify that the medium used is [[Ethernet]], HLEN is set to 6 because an Ethernet address (MAC address) is 6 octets long. The CHADDR is set to the MAC address used by the client. Some options are set as well. | ||
| Line 104: | Line 135: | ||
{{APHD|0|bits1=64|field1=IPv4 header start}} | {{APHD|0|bits1=64|field1=IPv4 header start}} | ||
{{APHD|8|bits1=8|bits2=8|bits3=16|field1=TTL|field2=Protocol ({{Mono|17}} UDP)|field3=Header Checksum}} | {{APHD|8|bits1=8|bits2=8|bits3=16|field1=TTL|field2=Protocol ({{Mono|17}} UDP)|field3=Header Checksum}} | ||
{{APHD|12|bits1=32|field1=Source Address ({{IPaddr|192.168.1.1}})}} | |||
{{APHD|16|bits1=32|field1=Destination Address ({{IPaddr|192.168.1.100}})}} | |||
{{APHD|end}} | {{APHD|end}} | ||
{{APHD|start|header=no|title=UDP Header}} | {{APHD|start|header=no|title=UDP Header}} | ||
{{APHD|20|bits1=16|bits2=16|field1=Source Port (67)|field2=Destination Port (68)}} | {{APHD|20|bits1=16|bits2=16|field1=Source Port (67)|field2=Destination Port (68)}} | ||
{{APHD|24|bits1=16|bits2=16|field1=Length|field2=Checksum}} | {{APHD|24|bits1=16|bits2=16|field1=Length|field2=Checksum}} | ||
| Line 148: | Line 179: | ||
{{APHD|0|bits1=64|field1=IPv4 header start}} | {{APHD|0|bits1=64|field1=IPv4 header start}} | ||
{{APHD|8|bits1=8|bits2=8|bits3=16|field1=TTL|field2=Protocol ({{Mono|17}} UDP)|field3=Header Checksum}} | {{APHD|8|bits1=8|bits2=8|bits3=16|field1=TTL|field2=Protocol ({{Mono|17}} UDP)|field3=Header Checksum}} | ||
{{APHD|12|bits1=32|field1=Source Address ({{IPaddr|0.0.0.0}})}} | |||
{{APHD|16|bits1=32|field1=Destination Address ({{IPaddr|255.255.255.255}})}} | |||
{{APHD|end}} | {{APHD|end}} | ||
{{APHD|start|header=no|title=UDP Header}} | {{APHD|start|header=no|title=UDP Header}} | ||
{{APHD|20|bits1=16|bits2=16|field1=Source Port (68)|field2=Destination Port (67)}} | {{APHD|20|bits1=16|bits2=16|field1=Source Port (68)|field2=Destination Port (67)}} | ||
{{APHD|24|bits1=16|bits2=16|field1=Length|field2=Checksum}} | {{APHD|24|bits1=16|bits2=16|field1=Length|field2=Checksum}} | ||
| Line 189: | Line 220: | ||
{{APHD|0|bits1=64|field1=IPv4 header start}} | {{APHD|0|bits1=64|field1=IPv4 header start}} | ||
{{APHD|8|bits1=8|bits2=8|bits3=16|field1=TTL|field2=Protocol ({{Mono|17}} UDP)|field3=Header Checksum}} | {{APHD|8|bits1=8|bits2=8|bits3=16|field1=TTL|field2=Protocol ({{Mono|17}} UDP)|field3=Header Checksum}} | ||
{{APHD|12|bits1=32|field1=Source Address ({{IPaddr|192.168.1.1}})}} | |||
{{APHD|16|bits1=32|field1=Destination Address ({{IPaddr|192.168.1.100}})}} | |||
{{APHD|end}} | {{APHD|end}} | ||
{{APHD|start|header=no|title=UDP Header}} | {{APHD|start|header=no|title=UDP Header}} | ||
{{APHD|20|bits1=16|bits2=16|field1=Source Port (67)|field2=Destination Port (68)}} | {{APHD|20|bits1=16|bits2=16|field1=Source Port (67)|field2=Destination Port (68)}} | ||
{{APHD|24|bits1=16|bits2=16|field1=Length|field2=Checksum}} | {{APHD|24|bits1=16|bits2=16|field1=Length|field2=Checksum}} | ||
| Line 239: | Line 270: | ||
The following tables list the available DHCP options.{{Ref RFC|2132}}<ref name=":0" /> | The following tables list the available DHCP options.{{Ref RFC|2132}}<ref name=":0" /> | ||
{{Table alignment}} | |||
{| class="wikitable sortable" | {{sticky header}} | ||
{| class="wikitable sortable sticky-header col1right" | |||
|+ RFC 1497 (BOOTP Vendor Information Extensions) vendor extensions<ref name=rfc2132/>{{rp|Section 3}} | |+ RFC 1497 (BOOTP Vendor Information Extensions) vendor extensions<ref name=rfc2132/>{{rp|Section 3}} | ||
|- | |- | ||
! Code !! Name !! Length !! Notes | ! scope=col | Code !! scope=col | Name !! scope=col | Length !! scope=col | Notes | ||
|- | |- | ||
| 0 || Pad || 0 [[Octet (computing)|octets]] || Can be used to pad other options so that they are aligned to the word boundary; is not followed by length byte | | 0 || Pad || 0 [[Octet (computing)|octets]] || Can be used to pad other options so that they are aligned to the word boundary; is not followed by length byte | ||
| Line 249: | Line 281: | ||
| 1 || Subnet mask || 4 octets || Client's subnet mask as per [https://datatracker.ietf.org/doc/html/rfc950 RFC 950]. If both the subnet mask and the router option (option 3) are included, the subnet mask option must be first. | | 1 || Subnet mask || 4 octets || Client's subnet mask as per [https://datatracker.ietf.org/doc/html/rfc950 RFC 950]. If both the subnet mask and the router option (option 3) are included, the subnet mask option must be first. | ||
|- | |- | ||
| 2 || Time offset || 4 octets || | | 2 || Time offset || 4 octets ||Time offset of the client's subnet in seconds from Coordinated Universal Time (UTC). The offset is expressed as a two's complement 32-bit integer. A positive offset indicates a location east of the zero meridian and a negative offset indicates a location west of the zero meridian. | ||
|- | |- | ||
| 3 || Router || Multiples of 4 octets || Available routers, should be listed in order of preference | | 3 || Router || Multiples of 4 octets || Available routers, should be listed in order of preference | ||
| Line 277: | Line 309: | ||
| 15 || Domain name || Minimum of 1 octet || | | 15 || Domain name || Minimum of 1 octet || | ||
|- | |- | ||
| 16 || Swap server || 4 octets || | | 16 || Swap server || 4 octets ||The IP address of a server where a swap service (e.g., swap over NFS) is provided for diskless workstations<ref>{{Cite book |last=Droms |first=Ralph |title=The DHCP handbook |last2=Lemon |first2=Ted |date=2003 |publisher=Sams |isbn=978-0-672-32327-0 |edition=2nd |location=Indianapolis, Indiana |publication-date=October 2002 |pages=134}}</ref> | ||
|- | |- | ||
| 17 || Root path || Minimum of 1 octet || | | 17 || Root path || Minimum of 1 octet ||The path in the remote filesystem specified by siaddr or sname that the client should mount as its root filesystem (e.g, over NFS) | ||
|- | |- | ||
| 18 || Extensions path || Minimum of 1 octet || | | 18 || Extensions path || Minimum of 1 octet || | ||
| Line 286: | Line 318: | ||
|} | |} | ||
{| class="wikitable sortable" | {{Table alignment}} | ||
{| class="wikitable sortable col1right" | |||
|+ IP layer parameters per host<ref name=rfc2132/>{{rp|Section 4}} | |+ IP layer parameters per host<ref name=rfc2132/>{{rp|Section 4}} | ||
|- | |- | ||
! Code !! Name !! Length !! Notes | ! scope=col | Code !! scope=col | Name !! scope=col | Length !! scope=col | Notes | ||
|- | |- | ||
| 19 || IP forwarding enable/disable || 1 octet || | | 19 || IP forwarding enable/disable || 1 octet || | ||
| Line 306: | Line 339: | ||
|} | |} | ||
{| class="wikitable sortable" | {{Table alignment}} | ||
{| class="wikitable sortable col1right" | |||
|+ IP Layer Parameters per Interface<ref name=rfc2132/>{{rp|Section 5}} | |+ IP Layer Parameters per Interface<ref name=rfc2132/>{{rp|Section 5}} | ||
|- | |- | ||
! Code !! Name !! Length !! Notes | ! scope=col | Code !! scope=col | Name !! scope=col | Length !! scope=col | Notes | ||
|- | |- | ||
| 26 || Interface MTU || 2 octets || | | 26 || Interface MTU || 2 octets || | ||
| Line 328: | Line 362: | ||
|} | |} | ||
{| class="wikitable sortable" | {{Table alignment}} | ||
{| class="wikitable sortable col1right" | |||
|+ Link layer parameters per interface<ref name=rfc2132/>{{rp|Section 6}} | |+ Link layer parameters per interface<ref name=rfc2132/>{{rp|Section 6}} | ||
|- | |- | ||
! Code !! Name !! Length !! Notes | ! scope=col | Code !! scope=col | Name !! scope=col | Length !! scope=col | Notes | ||
|- | |- | ||
| 34 || Trailer encapsulation option || 1 octet || | | 34 || Trailer encapsulation option || 1 octet || | ||
| Line 340: | Line 375: | ||
|} | |} | ||
{| class="wikitable sortable" | {{Table alignment}} | ||
{| class="wikitable sortable col1right" | |||
|+ TCP parameters<ref name=rfc2132/>{{rp|Section 7}} | |+ TCP parameters<ref name=rfc2132/>{{rp|Section 7}} | ||
|- | |- | ||
! Code !! Name !! Length !! Notes | ! scope=col | Code !! scope=col | Name !! scope=col | Length !! scope=col | Notes | ||
|- | |- | ||
| 37 || TCP default TTL || 1 octet || | | 37 || TCP default TTL || 1 octet || | ||
| Line 352: | Line 388: | ||
|} | |} | ||
{| class="wikitable sortable" | {{Table alignment}} | ||
{| class="wikitable sortable col1right" | |||
|+ Application and service parameters<ref name=rfc2132/>{{rp|Section 8}} | |+ Application and service parameters<ref name=rfc2132/>{{rp|Section 8}} | ||
|- | |- | ||
! Code !! Name !! Length !! Notes | ! scope=col | Code !! scope=col | Name !! scope=col | Length !! scope=col | Notes | ||
|- | |- | ||
| 40 || Network information service domain || Minimum of 1 octet || | | 40 || Network information service domain || Minimum of 1 octet || | ||
| Line 400: | Line 437: | ||
|} | |} | ||
{| class="wikitable sortable" | {{Table alignment}} | ||
{| class="wikitable sortable col1right" | |||
|+ DHCP extensions<ref name=rfc2132/>{{rp|Section 9}} | |+ DHCP extensions<ref name=rfc2132/>{{rp|Section 9}} | ||
|- | |- | ||
! Code !! Name !! Length !! Notes | ! scope=col | Code !! scope=col | Name !! scope=col | Length !! scope=col | Notes | ||
|- | |- | ||
| 50 || Requested IP address || 4 octets || | | 50 || Requested IP address || 4 octets || | ||
| Line 438: | Line 476: | ||
These codes are the value in the DHCP extension 53, shown in the table above. | These codes are the value in the DHCP extension 53, shown in the table above. | ||
{| class="wikitable sortable" | {{Table alignment}} | ||
{| class="wikitable sortable col1right" | |||
|+ DHCP message types | |+ DHCP message types | ||
|- | |- | ||
! Code !! Name !! Length !! RFC | ! scope=col | Code !! scope=col | Name !! scope=col | Length !! scope=col | RFC | ||
|- | |- | ||
| 1 || DHCPDISCOVER || 1 octet || {{Sum RFC|2132|plain=yes}}{{Ref RFC|2132|rsection=9.6}} | | 1 || DHCPDISCOVER || 1 octet || {{Sum RFC|2132|plain=yes}}{{Ref RFC|2132|rsection=9.6}} | ||
| Line 483: | Line 522: | ||
An option exists to identify the vendor and functionality of a DHCP client. The information is a [[Variable-length code|variable-length string]] of characters or octets which has a meaning specified by the vendor of the DHCP client. One method by which a DHCP client can communicate to the server that it is using a certain type of hardware or [[firmware]] is to set a value in its DHCP requests called the Vendor Class Identifier (VCI) (Option 60). | An option exists to identify the vendor and functionality of a DHCP client. The information is a [[Variable-length code|variable-length string]] of characters or octets which has a meaning specified by the vendor of the DHCP client. One method by which a DHCP client can communicate to the server that it is using a certain type of hardware or [[firmware]] is to set a value in its DHCP requests called the Vendor Class Identifier (VCI) (Option 60). | ||
The value to which this option is set gives the DHCP server a hint about any required extra information that this client needs in a DHCP response. Some types of [[set-top boxes]] set the VCI to inform the DHCP server about the hardware type and functionality of the device. An [[Aruba Networks|Aruba]] campus [[wireless access point]], for example, supplies value 'ArubaAP' as option 60 in its DHCPDISCOVER message.<ref name="option60">{{cite web|title=Aruba DHCP Option 60|date=7 October 2020 |url=https://the-ethernets.com/2020/10/aruba-dhcp-option-60/}}</ref> The DHCP server can then augment its DHCPOFFER with an IP address of an Aruba [[wireless controller]] in option 43, so the access point knows where to register itself. | The value to which this option is set gives the DHCP server a hint about any required extra information that this client needs in a DHCP response. Some types of [[set-top boxes]] set the VCI to inform the DHCP server about the hardware type and functionality of the device. An [[Aruba Networks|Aruba]] campus [[wireless access point]], for example, supplies value 'ArubaAP' as option 60 in its DHCPDISCOVER message.<ref name="option60">{{cite web|title=Aruba DHCP Option 60|date=7 October 2020 |url=https://the-ethernets.com/2020/10/aruba-dhcp-option-60/|archive-url=https://web.archive.org/web/20220417150426/http://the-ethernets.com/2020/10/aruba-dhcp-option-60/|url-status=usurped|archive-date=April 17, 2022}}</ref> The DHCP server can then augment its DHCPOFFER with an IP address of an Aruba [[wireless controller]] in option 43, so the access point knows where to register itself. | ||
Setting a VCI by the client allows a DHCP server to differentiate between client machines and process the requests from them appropriately. | Setting a VCI by the client allows a DHCP server to differentiate between client machines and process the requests from them appropriately. | ||
===Other extensions=== | ===Other extensions=== | ||
{| class="wikitable sortable" | {| class="wikitable sortable col1right" | ||
|+ Documented DHCP options | |+ Documented DHCP options | ||
|- | |- | ||
| Line 507: | Line 546: | ||
| 101 || [[Time zone]], [[tz database]] style || Variable || {{Sum RFC|4833|plain=yes}} | | 101 || [[Time zone]], [[tz database]] style || Variable || {{Sum RFC|4833|plain=yes}} | ||
|- | |- | ||
| 114 || DHCP Captive | | 114 || DHCP [[Captive Portal]] || Variable || {{Sum RFC|8910|plain=yes|ref=yes}} | ||
|- | |- | ||
| 119 || [[Search domain|Domain search]] || Variable || {{Sum RFC|3397|plain=yes|ref=yes}} | | 119 || [[Search domain|Domain search]] || Variable || {{Sum RFC|3397|plain=yes|ref=yes}} | ||
| Line 518: | Line 557: | ||
|- | |- | ||
| 211 || Reboot Time || Variable || {{Sum RFC|5071|plain=yes}} | | 211 || Reboot Time || Variable || {{Sum RFC|5071|plain=yes}} | ||
|- | |||
| 224–254 || site-specific options || Variable || {{Sum RFC|3942|plain=yes}} | |||
|} | |} | ||
| Line 523: | Line 564: | ||
The relay agent information option (option 82) specifies container for attaching sub-options to DHCP requests transmitted between a DHCP relay and a DHCP server.<ref name="ietf_spec_dhcp82">{{cite journal|last1=Patrick|first1=Michael|title=DHCP Relay Agent Information Option|url=https://tools.ietf.org/html/rfc3046|website=IETF Documents|publisher=[[IETF]]|access-date=22 July 2017|doi=10.17487/RFC3046|date=January 2001|doi-access=|url-access=subscription}}</ref> | The relay agent information option (option 82) specifies container for attaching sub-options to DHCP requests transmitted between a DHCP relay and a DHCP server.<ref name="ietf_spec_dhcp82">{{cite journal|last1=Patrick|first1=Michael|title=DHCP Relay Agent Information Option|url=https://tools.ietf.org/html/rfc3046|website=IETF Documents|publisher=[[IETF]]|access-date=22 July 2017|doi=10.17487/RFC3046|date=January 2001|doi-access=|url-access=subscription}}</ref> | ||
{| class="wikitable sortable" | {| class="wikitable sortable col1right" | ||
|+ Relay agent sub-options | |+ Relay agent sub-options | ||
|- | |- | ||
| Line 533: | Line 574: | ||
|- | |- | ||
| 4 || Data-Over-Cable Service Interface Specifications (DOCSIS) device class || 4 octets || {{Sum RFC|3256|plain=yes|ref=yes}} | | 4 || Data-Over-Cable Service Interface Specifications (DOCSIS) device class || 4 octets || {{Sum RFC|3256|plain=yes|ref=yes}} | ||
|- | |||
| 5 || Link Selection || 4 octets || {{Sum RFC|3527|plain=yes|ref=yes}} | |||
|} | |} | ||
| Line 602: | Line 645: | ||
DHCP does provide some mechanisms for mitigating these problems. The [[#Relay agent information sub-options|Relay Agent Information Option]] protocol extension{{Ref RFC|3046}} (usually referred to in the industry by its actual number as ''Option 82''<ref name="HensCaballero2008">{{cite book |first1 = Francisco J. |last1=Hens |first2 = José M. |last2=Caballero |title = Triple Play: Building the converged network for IP, VoIP and IPTV |url = https://books.google.com/books?id=aS1ZngveBIkC&pg=PA239 |year = 2008 |publisher = John Wiley & Sons |isbn = 978-0-470-75439-9 |page = 239 }}</ref><ref name="Ramirez2008">{{cite book |first= David H. |last=Ramirez |title = IPTV Security: Protecting High-Value Digital Contents |url = https://books.google.com/books?id=70tr_hSDULwC&pg=PA55 |year = 2008 |publisher = John Wiley & Sons |isbn = 978-0-470-72719-5 |page = 55 }}</ref>) allows network operators to attach tags to DHCP messages as these messages arrive on the network operator's trusted network. This tag is then used as an authorization token to control the client's access to network resources. Because the client has no access to the network upstream of the relay agent, the lack of authentication does not prevent the DHCP server operator from relying on the authorization token.{{Ref RFC|3046}}{{rp|sec. 7}} | DHCP does provide some mechanisms for mitigating these problems. The [[#Relay agent information sub-options|Relay Agent Information Option]] protocol extension{{Ref RFC|3046}} (usually referred to in the industry by its actual number as ''Option 82''<ref name="HensCaballero2008">{{cite book |first1 = Francisco J. |last1=Hens |first2 = José M. |last2=Caballero |title = Triple Play: Building the converged network for IP, VoIP and IPTV |url = https://books.google.com/books?id=aS1ZngveBIkC&pg=PA239 |year = 2008 |publisher = John Wiley & Sons |isbn = 978-0-470-75439-9 |page = 239 }}</ref><ref name="Ramirez2008">{{cite book |first= David H. |last=Ramirez |title = IPTV Security: Protecting High-Value Digital Contents |url = https://books.google.com/books?id=70tr_hSDULwC&pg=PA55 |year = 2008 |publisher = John Wiley & Sons |isbn = 978-0-470-72719-5 |page = 55 }}</ref>) allows network operators to attach tags to DHCP messages as these messages arrive on the network operator's trusted network. This tag is then used as an authorization token to control the client's access to network resources. Because the client has no access to the network upstream of the relay agent, the lack of authentication does not prevent the DHCP server operator from relying on the authorization token.{{Ref RFC|3046}}{{rp|sec. 7}} | ||
Another extension, Authentication for DHCP Messages{{Ref RFC|3118}} (RFC 3118), provides a mechanism for authenticating DHCP messages. As of 2002, this extension had not seen widespread adoption because of the problems of managing keys for large numbers of DHCP clients.<ref>{{cite web |url = | Another extension, Authentication for DHCP Messages{{Ref RFC|3118}} (RFC 3118), provides a mechanism for authenticating DHCP messages. As of 2002, this extension had not seen widespread adoption because of the problems of managing keys for large numbers of DHCP clients.<ref>{{cite web |url = https://www.ietf.org/mail-archive/web/dhcwg/current/msg00876.html |title = Implementation of RFC 3118 |first= Ted |last=Lemon |date = April 2002 }}</ref> A 2007 book about DSL technologies remarked that:<blockquote>[T]here were numerous security vulnerabilities identified against the security measures proposed by RFC 3118. This fact, combined with the introduction of [[802.1X]], slowed the deployment and take-rate of authenticated DHCP, and it has never been widely deployed.<ref name="GoldenDedieu2007">{{cite book |first1 = Philip |last1=Golden |first2 = Hervé |last2=Dedieu |first3 = Krista S. |last3=Jacobsen |title = Implementation and Applications of DSL Technology |url = https://books.google.com/books?id=Jjkd74jY47oC&pg=PA484 |year = 2007 |publisher = Taylor & Francis |isbn = 978-1-4200-1307-8 |page = 484 }}</ref></blockquote> A 2010 book notes that:<blockquote>[T]here have been very few implementations of DHCP Authentication. The challenges of key management and processing delays due to hash computation have been deemed too heavy a price to pay for the perceived benefits.<ref name="Rooney2011b">{{cite book |first= Timothy |last=Rooney |title = Introduction to IP Address Management |url = https://books.google.com/books?id=QgRDxkuI1MkC&pg=PA181 |year = 2010 |publisher = John Wiley & Sons |isbn = 978-1-118-07380-3 |pages = 181–182 }}</ref></blockquote> | ||
Architectural proposals from 2008 involve authenticating DHCP requests using [[802.1X]] or [[Protocol for Carrying Authentication for Network Access|PANA]] (both of which transport [[Extensible Authentication Protocol|EAP]]).<ref name="Copeland2008">{{cite book |first= Rebecca |last=Copeland |title = Converging NGN Wireline and Mobile 3G Networks with IMS |url = https://books.google.com/books?id=ruWv8RGkBGgC&pg=PA142 |year = 2008 |publisher = Taylor & Francis |isbn = 978-1-4200-1378-8 |pages = 142–143 }}</ref> An IETF proposal was made for including EAP in DHCP itself, the so-called <abbr>EAPoDHCP</abbr>;<ref name="PrasadMihovska2009">{{cite book |first1 = Ramjee |last1=Prasad |first2 = Albena |last2=Mihovska |title = New Horizons in Mobile and Wireless Communications: Networks, services, and applications |url = https://books.google.com/books?id=w9bEwBwd33MC&pg=PA339 |year = 2009 |publisher = Artech House |isbn = 978-1-60783-970-5 |page = 339 |volume = 2 }}</ref> this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.<ref>{{cite web |url=http://tools.ietf.org/search/draft-pruss-dhcp-auth-dsl-07 |title=Draft-pruss-DHCP-auth-DSL-07 - EAP Authentication Extensions for the Dynamic Host Configuration Protocol for Broadband |access-date=2013-12-12 |archive-url=https://web.archive.org/web/20150403091552/http://tools.ietf.org/search/draft-pruss-dhcp-auth-dsl-07 |archive-date=2015-04-03 }}</ref> | Architectural proposals from 2008 involve authenticating DHCP requests using [[802.1X]] or [[Protocol for Carrying Authentication for Network Access|PANA]] (both of which transport [[Extensible Authentication Protocol|EAP]]).<ref name="Copeland2008">{{cite book |first= Rebecca |last=Copeland |title = Converging NGN Wireline and Mobile 3G Networks with IMS |url = https://books.google.com/books?id=ruWv8RGkBGgC&pg=PA142 |year = 2008 |publisher = Taylor & Francis |isbn = 978-1-4200-1378-8 |pages = 142–143 }}</ref> An IETF proposal was made for including EAP in DHCP itself, the so-called <abbr>EAPoDHCP</abbr>;<ref name="PrasadMihovska2009">{{cite book |first1 = Ramjee |last1=Prasad |first2 = Albena |last2=Mihovska |title = New Horizons in Mobile and Wireless Communications: Networks, services, and applications |url = https://books.google.com/books?id=w9bEwBwd33MC&pg=PA339 |year = 2009 |publisher = Artech House |isbn = 978-1-60783-970-5 |page = 339 |volume = 2 }}</ref> this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.<ref>{{cite web |url=http://tools.ietf.org/search/draft-pruss-dhcp-auth-dsl-07 |title=Draft-pruss-DHCP-auth-DSL-07 - EAP Authentication Extensions for the Dynamic Host Configuration Protocol for Broadband |access-date=2013-12-12 |archive-url=https://web.archive.org/web/20150403091552/http://tools.ietf.org/search/draft-pruss-dhcp-auth-dsl-07 |archive-date=2015-04-03 }}</ref> | ||