Subject: [NDProxy#20] DHCPv4

From: "Dave Thaler" <[email-masked]>
Date: Wed, 16 Feb 2005 10:35:21 -0800

Summary (from Ralph Droms):
> There are two small issues with the mechanism for accommodating
DHCPv4.
> First, the mechanism is incompatible with the authentication protocol 
> for DHCPv4 described in RFC 3118. In fact, the mechanism will be 
> incompatible with any authentication that verifies the integrity of
the
> data in the DHCPv4 message header, as changing the broadcast bit from
0
> to 1 should be detected as a change in the contents of the message.
> Second, there should be a warning that a DHCPv4 client might detect, 
> with subsequently undefined behavior, that the broadcast bit has been
> changed from the setting in the message originally set by the client.

Issue page (no further discussion so far):
http://www.icir.org/dthaler/NDProxyIssues.htm#Issue%2020

The text Ralph refers to is section 4.1.3.3:
> If the received packet is a DHCPv4 DISCOVER or REQUEST message,
> then instead of changing the client's hardware address in the
> payload, the BROADCAST (B) flag is set in the proxied packet.
> This ensures that the proxy will be able to receive and proxy the
> response since the response will be broadcast rather than unicast
> to that hardware address.  The hardware address is thus used only
> as a unique identifier and hence need not be a link-layer address
> on the same segment.

Is there a better behavior for DHCPv4 that should be recommended?  The
current rule just documents existing practice in (at least some) ARP
proxies.

Assuming documenting existing practice for information is okay,
here's proposed text to be added after the paragraph quoted above:

> One limitation of this rule is that if the authentication protocol
> for DHCPv4 described in [DHCPAUTH] is used, only clients that set
> the BROADCAST flag themselves will be able to use DHCPv4 through
> the proxy.  If [DHCPAUTH] is not used, a DHCPv4 client might still
> detect, with previously undefined behavior, that the broadcast bit
> has been changed from the setting in the message originally set by
> the client.  However, the point of this rule is not to solve this
> problem, but rather to document existing practice.

-Dave

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------