At 10:35 AM 2/16/2005 -0800, Dave Thaler wrote:
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.
I don't know of better behavior and, in fact, I wasn't aware of this
behavior in 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.
That text is fine with me.
-Dave
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
