Subject: Re: [NDProxy#20] DHCPv4

From: Ralph Droms <[email-masked]>
Date: Fri, 18 Feb 2005 16:11:52 -0500

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-masked]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

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

---

From: Markku Savela <[email-masked]>
Date: Sat, 19 Feb 2005 09:22:02 +0200

Sorry about somewhat OT content, but...

For some intended uses, NDproxy is awfully complex way of achieving a
result, which would much easier to do as follows:

1) ISP give /64

2) use internally longer prefix (68 or 72), reserve the one (based on
   ID assigned to the ISP link) for the ISP link, and use rest for own
   private purpose.

3) Run modified router, that taks in /64, and addversises the longer
   prefix on other links with different different prefixes.

This would work just fine, if nodes on internal network take the RA
prefix length as is, and just trunctate their ID-parts from higher
ends (or they could just generate ID randomly). Throw away all this
sillyness with fixed 64-bit ID etc..

---

From: Pekka Savola <[email-masked]>
Date: Sat, 19 Feb 2005 10:23:21 +0200 (EET)

> sillyness with fixed 64-bit ID etc..

This would require changes to the hosts (and have other issues 
besides) -- not good.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Markku Savela <[email-masked]>
Date: Sat, 19 Feb 2005 10:28:55 +0200

> This would require changes to the hosts (and have other issues 

Implementations might already work this way. This should be specified
in the RFC as a correct behaviour with longer prefix, instead of
rejecting them.