1.4 Relationship to Other Protocols

DHCPv4 (as specified in [RFC2131]) is based on the Bootstrap Protocol (BOOTP), as specified in [RFC951]. The format of the DHCPv4 messages is based on the format of the BOOTP messages. The relationship between these two protocols is defined in [RFC1534].

The vendor-specific options specified in this document rely on and are transported within DHCPv4.

DHCPv4 can be used as one of the enforcement mechanisms defined for Network Access Protection (NAP), as described in [MSDN-NAP]. The vendor-specific options used for DHCPv4-based enforcement of NAP are defined in [MS-DHCPN] section 1. [MS-DHCPN] affects the contents of DHCPv4 messages when NAP is used.

The NetBIOS over TCP/IP protocol is defined in [RFC1001] and [RFC1002]. The vendor-specific option defined in this specification provides the capability to enable or disable the use of the NetBIOS over TCP/IP protocol on client and server machines.

[MS-DHCPM] affects the contents of DHCPv4 messages extended by this protocol by setting or modifying DHCP server configurations.

The following diagram illustrates the layering of the protocol in this section with other protocols in its stack.

Figure 5: Protocol layering diagram

The following data flow diagram illustrates the interaction of the server implementation of this protocol with those of other protocols in its stack.

Figure 6: Server-side interaction with related protocols

The following is the relationship between [MS-DHCPM] ADM elements and the elements defined by [RFC2131] and [RFC3315] which are extended by this extension.

1. The subnet ([RFC2131] section 2) is represented by the DHCPv4Scope element, a shared ADM element (see [MS-DHCPM] section 3.1.1.2). The DHCPv4 server will process an incoming DHCPv4 client message only if there exists a DHCPv4Scope object in its configuration that matches either the IP address of the network interface on which it received the message or the IP address of the relay agent in the client message (as specified in [RFC2131] section 4.3.1).

2. The DHCPv4IpRange, a shared ADM element (see [MS-DHCPM] section 3.1.1.4), restricts the range of available network addresses ([RFC2131] section 3.1 point 2) for allocation within a DHCPv4Scope. Once a subnet is selected, the DHCPv4 server identifies a DHCPv4IpRange object (we allow only up to 1 object to be configured) in the DHCPv4Scope which has available addresses in it. If no range is configured or the range is full, the DHCPv4 server will not respond to the client message. Otherwise the IP address to be assigned will be decided based on the available address in the range.

3. The DHCPv4ExclusionRange, a shared ADM element (see [MS-DHCPM] section 3.1.1.5), marks a range of address within a subnet as excluded from allocation. The IP addresses within the DHCPv4ExclusionRange will not be counted as available network addresses ([RFC2131] section 3.1 point 2). The DHCPv4 server will also check for the existence of DHCPv4ExclusionRange objects (these can be multiple). IP addresses will not be assigned from these ranges.

4. Manual allocation ([RFC2131] section 1) is achieved by the DHCPv4Reservation element, a shared ADM element (see [MS-DHCPM] section 3.1.1.6). The DHCPv4 server also checks for the existence of a DHCPv4Reservation object that corresponds to the hardware address in the client message. If a matching reservation exists, the corresponding IP address will be assigned to the client even if it lies outside of the DHCPv4IpRange or within a DHCPv4ExclusionRange.

5. The database of allocated addresses and leases ([RFC2131] section 4) is represented by the DHCPv4Client element, a shared ADM element (see [MS-DHCPM] section 3.1.1.7). Whenever a client accepts the IP address assigned to it by the DHCPv4 server, the latter will create a DHCPv4Client object and add it to the subnet's client list.

6. The DHCPv4Filter elements, shared ADM elements (see [MS-DHCPM] section 3.1.1.30), implement DHCPv4 server administrative controls ([RFC2131] section 4.2). The DHCPv4FiltersList element, a shared ADM element (see [MS-DHCPM] section 3.1.1.1), defines global allow/deny lists that determine the clients to which the server allocates addresses. The DHCPv4FilterStatus element, a shared ADM element (see [MS-DHCPM] section 3.1.1.1), can be used by the administrator to enable/disable enforcement of the allow/deny lists. The enforcement works in the following way:

   1. If neither DHCPv4FilterStatus.EnforceAllowList nor DHCPv4FilterStatus.EnforceDenyList is set to TRUE, the client message is processed further for the DHCPv4 protocol and no further checking for a DHCPv4 filter element is done.

   2. If the incoming client message has the client hardware address ([RFC2131] section 2) that matches a DHCPv4Filter entry in the DHCPv4FiltersList with ListType Deny and the DHCPv4FilterStatus.EnforceDenyList is set to TRUE, then the client message is not processed further or responded to.

   3. If the incoming client message has the client hardware address ([RFC2131] section 2) that matches a DHCPv4Filter entry in the DHCPv4FiltersList with ListType Allow and the DHCPv4FilterStatus.EnforceAllowList is set to TRUE, then the client message is processed further for the DHCPv4 protocol and no further checking for a DHCPv4 filter element is done.

   4. If the DHCPv4FilterStatus.EnforceAllowList is set to true and the client hardware address ([RFC2131] section 2) does not match any DHCPv4Filter entry in the DHCPv4FiltersList with ListType Allow, then the client message is not processed further or responded to.

7. The DHCPv4SuperScope element, a shared ADM element (see [MS-DHCPM] section 3.1.1.3), allows configuration of network architectures with more than one IP subnets assigned to a physical network segment ([RFC2131] section 4.3.1). If the subnet that would be normally chosen by the DHCPv4 server according to the relay agent IP address has exhausted all addresses and happens to have a non-zero DHCPv4Scope.SuperScopeId, a shared ADM element (see [MS-DHCPM] section 3.1.1.23.1.1.2), then the server can allocate an address from any other subnet configured with the same DHCPv4Scope.SuperScopeId.

8. The DHCPv4ServerOptValueList, a shared ADM element (see [MS-DHCPM] section 3.1.1.1), the DHCPv4Scope.DHCPv4ScopeOptValuesList, a shared ADM element (see [MS-DHCPM] section 3.1.1.2), and the DHCPv4Reservation. DHCPv4ResvOptValuesList, a shared ADM element (see [MS-DHCPM] section 3.1.1.6), allow explicit configuration of a default value for parameters requested by the client ([RFC2131] section 4.3.1). The order of selecting a configured default value is:

   1. DHCPv4OptionValue configured in the DHCPv4Reservation. DHCPv4ResvOptValuesList for a DHCPv4Reservation matching the client hardware address ([RFC2131] section 2) / client identifier ([RFC2132] section 9.14).

   2. DHCPv4OptionValue configured in the DHCPv4Scope.DHCPv4ScopeOptValuesList for a DHCPv4Scope selected as outlined above.

   3. DHCPv4OptionValue configured in the DHCPv4ServerOptValueList

9. Wherever the client message contains a user class option ([RFC3004]) and there exists a DHCPv4ClassDef object, a shared ADM element (see [MS-DHCPM] section 3.1.1.8), whose DHCPv4ClassDef.ClassData and DHCPv4ClassDef.ClassDataLength match the user class option data then any parameter values configured in DHCPv4Reservation. DHCPv4ResvOptValuesList, DHCPv4Scope.DHCPv4ScopeOptValuesList or DHCPv4ServerOptValueList with the corresponding DHCPv4ClassDef.ClassName in the DHCPv4OptionValue.UserClass, a shared ADM element (see [MS-DHCPM] section 3.1.1.11), will be selected in preference to parameters configured without a ClassName in any list. The overall order of selecting a configured default value is:

   1. DHCPv4OptionValue with matching ClassName configured in the DHCPv4Reservation. DHCPv4ResvOptValuesList for a DHCPv4Reservation matching the client hardware address ([RFC2131] section 2) / client identifier ([RFC2132] section 9.14).

   2. DHCPv4OptionValue with matching ClassName configured in the DHCPv4Scope.DHCPv4ScopeOptValuesList for a DHCPv4Scope selected as outlined above.

   3. DHCPv4OptionValue with matching ClassName configured in the DHCPv4ServerOptValueList

   4. DHCPv4OptionValue with no ClassName configured in the DHCPv4Reservation. DHCPv4ResvOptValuesList for a DHCPv4Reservation matching the client hardware address ([RFC2131] section 2) / client identifier ([RFC2132] section 9.14).

   5. DHCPv4OptionValue with no ClassName configured in the DHCPv4Scope.DHCPv4ScopeOptValuesList for a DHCPv4Scope selected as outlined above.

   6. DHCPv4OptionValue with no ClassName configured in the DHCPv4ServerOptValueList

10. The DHCPv4ServerMibInfo element, a shared ADM element (see [MS-DHCPM] section 3.1.1.1), is updated by the server with the counts of various DHCPv4 messages ([RFC2131] section 3.1) processed or sent by it. Specifically, DHCPv4ServerMibInfo.Discovers, DHCPv4ServerMibInfo.Offers, DHCPv4ServerMibInfo.Requests, DHCPv4ServerMibInfo.Declines and DHCPv4ServerMibInfo.Releases are updated with the counts of DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPDECLINE and DHCPRELEASE messages processed by the server respectively. DHCPv4ServerMibInfo.Acks and DHCPv4ServerMibInfo.Naks are updated with the counts of DHCPACK and DHCPNAK messages sent by the server respectively.

11. IPv6 prefixes ([RFC3315] section 4.1) are configured on the server as DHCPv4Scope elements, shared ADM elements (see [MS-DHCPM] section 3.1.1.14). IP addresses are selected for assignment to an IA ([RFC3315] section 11) based on the existence in configuration of a prefix corresponding to the address of the interface over which a direct message was received or the address of the forwarding relay agent in the case of relay forwarded messages.

12. The DHCPv6ExclusionRange element, a shared ADM element (see [MS-DHCPM] section 3.1.1.15), marks a range of address within a subnet as excluded from allocation. While selecting addresses for assignment to an IA ([RFC3315] section 11) the server will not select addresses so excluded from allocation.

13. The DHCPv6Reservation element, a shared ADM element (see [MS-DHCPM] section 3.1.1.16), implements a manual allocation scheme on par with the one outlined for DHCPv4 processing above.

14. The DHCPv6ClientInfo element, a shared ADM element ([MS-DHCPM] section 3.1.1.18), represents a DHCPv6 binding which contains information about the identity association ([RFC3315] section 4.2). Whenever a client accepts the IP address assigned to it by the DHCPv6 server, the latter will create a DHCPv6ClientInfo object and add it to the DHCPv6Scope. DHCPv6ClientInfoList.

15. The DHCPv6ServerClassedOptValueList, a shared ADM element (see [MS-DHCPM] section 3.1.1.1), DHCPv6Scope.DHCPv6ScopeClassedOptValueList, a shared ADM element (see [MS-DHCPM] section 3.1.1.14), and DHCPv6Reservation.DHCPv6ResvClassedOptValueList, a shared ADM element (see [MS-DHCPM] section 3.1.1.16), allow the server to be configured to return options to the client as described in ([RFC3315] sections 17.2.2 and 18.2). The order of selecting a configured option is:

    1. DHCPv6OptionValue configured in the DHCPv6Reservation.DHCPv6ResvClassedOptValueList for a DHCPv6Reservation matching the client identifier and IAID specified in the client message.

    2. DHCPv6OptionValue configured in the DHCPv6Scope.DHCPv6ScopeClassedOptValueList for a DHCPv6Scope which corresponds to the prefix used in address selection as outlined above.

    3. DHCPv6OptionValue configured in the DHCPv6ServerClassedOptValueList

    1. Wherever the client message contains a user class option ([RFC3315] section 22.15) and there exists a DHCPv6ClassDef object, a shared ADM element (see [MS-DHCPM] section 3.1.1.19), whose DHCPv6ClassDef.ClassData and DHCPv6ClassDef.ClassDataLength match the user class option data then any parameter values configured in DHCPv6Reservation.DHCPv6ResvClassedOptValueList, DHCPv6Scope.DHCPv6ScopeClassedOptValueList or DHCPv6ServerClassedOptValueList with the corresponding DHCPv6ClassDef.ClassName in the DHCPv6OptionValue.UserClass, a shared ADM element (see [MS-DHCPM] section 3.1.1.21), will be selected in preference to a parameter configured without a ClassName in the corresponding list. The overall order of selecting a configured default value is:

       1. DHCPv6OptionValue with matching ClassName configured in the DHCPv6Reservation.DHCPv6ResvClassedOptValueList for a DHCPv6Reservation matching the client identifier and IAID specified in the client message.

       2. DHCPv6OptionValue with no ClassName configured in the DHCPv6Reservation.DHCPv6ResvClassedOptValueList for a DHCPv6Reservation matching the client identifier and IAID specified in the client message.

       3. DHCPv6OptionValue with matching ClassName configured in the DHCPv6Scope.DHCPv6ScopeClassedOptValueList for a DHCPv6Scope selected as outlined above.

       4. DHCPv6OptionValue with no ClassName configured in the DHCPv6Scope.DHCPv6ScopeClassedOptValueList for a DHCPv6Scope selected as outlined above.

       5. DHCPv6OptionValue with matching ClassName configured in the DHCPv6ServerClassedOptValueList

       6. DHCPv6OptionValue with no ClassName configured in the DHCPv6ServerClassedOptValueList

16. The DHCPv6ServerMibInfo element, a shared ADM element (see [MS-DHCPM] section 3.1.1.1), is updated by the server with the counts of various DHCPv6 messages ([RFC2131] section 3.1) processed or sent by it. Specifically, DHCPv6ServerMibInfo.Solicits, DHCPv6ServerMibInfo.Requests, DHCPv6ServerMibInfo.Renews, DHCPv6ServerMibInfo.Rebinds, DHCPv6ServerMibInfo.Confirms and DHCPv6ServerMibInfo.Declines, DHCPv6ServerMibInfo.Releases, DHCPv6ServerMibInfo.Informs are updated with the counts of DHCPv6 Solicit, Request, Renew, Rebind, Confirm, Decline, Release and Inform messages processed by the server respectively. DHCPv6ServerMibInfo.Advertises and DHCPv6ServerMibInfo.Replies are updated with the counts of DHCPv6 Advertise and Reply messages sent by the server, respectively.

17. The DHCPv4ServerMcastMibInfo element, a shared ADM element (see [MS-DHCPM] section 3.1.1.1), is updated by the server with the counts of various MADCAP messages ([RFC2730] section 2.2) processed or sent by it.