Re: [dhcwg] Comments - draft-ietf-dhc-l2ra-extensions-00

On Fri, Oct 17, 2008 at 09:42:31PM +0530, pavan_kurapati wrote:
> Pavan> This problem can be solved in 2 ways. 1) Obsolte the broadcast flag 2) Use unicast option

Maybe I am confused; the unicast option is a DHCPv6 feature, the
broadcast flag is a DHCPv4 (bootp header) feature?

> To do option 1 we have to formally obsolte the same. Option 2 is a cleaner solution for RA to pick up the address given in the option and unicast it back. Either way, it has to come through a draft and get WG approval. Ignoring broadcast flag otherwise is not DHCP standard compliant.

Presuming DHCPv4 contextually; DHCPv4 agents may, at their ability,
unicast or broadcast.  The only thing that is certain is that if the
broadcast flag is set, they MUST broadcast.  With the broadcast flag
cleared (indicating desire to unicast), they may still broadcast if
they cannot unicast-without-arp (for example).

Modern day networks realistically have software support for unicast.
It is very rare to find instances where broadcast replies are
actually used, excepting of course now that Vista sets the broadcast
flag.  Even where DHCP server software is running on 'odd' server
hardware (lacking sufficient raw packet support), a modern relay agent
can be used to bridge the gap.

So this is a condition that I think "IETF DHCP Extensions" must
formally support, even if it hopefully has very little, if any,
actual use.  Replies may be broadcast to the L2RA no matter what
we do.

An area where L2RA can and should extend this featureset is in a
missing indication between the DHCP Agent and the L2RA.

The broadcast flag properly indicates the client's needs, meaning
between the L2RA and the client.  The DHCPv4 protocol is missing a
field that hints at the path between the server-side DHCP agent and
L2RA.

This could be solved with a relay agent information option scoped
broadcast-request flag (perhaps extending the 'flags' option).

The DHCP agent would use the relay agent information flags option
contents to deliver the packet to the L2RA, which would use the
bootp header flag to deliver to the client (limiting the broadcast
to their specific port).

> Woj> Unless we have a good reason for it to cache, I'd say it should go.

Now that I consider it, I think there is a lease-time associated with
active assignments, and no expiration time associated with inactive
assignments.  To these ends, caching negative replies is probably
actively harmful; it could be assigned at any moment, including the
next nanosecond.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins