[dhcwg] draft-kinnear-dhc-relay-agent-flags-00.txt

Folks,

At the Dallas IETF, we discussed having a DHCPv4 relay agent
sub-option for flags, where the first flags was to indicate
whether the DHCP request forwarded from a Relay Agent was
received by the Relay Agent as a unicast or a broadcast.

The initial impetus for this sub-option was David Hankins'
realization that the server-id-override draft:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override-03.txt

was obscuring the difference between a DHCPv4 client's broadcast
and unicast transmission of a DHCPREQUEST/RENEW, thus making the
DHCPBROADCAST/RENEW look like a DHCPREQUEST/REBINDING.  This made
it difficult or impossible to adhere directly to RFC2131.  It
also made load balancing effectively useless if the
server-id-override capability was exercised.

We have put together a draft which specifies a flags sub-option
for the relay agent info option, and includes a flag for unicast
or broadcast reception by the Relay Agent:

http://www.ietf.org/internet-drafts/draft-kinnear-dhc-relay-agent-flags-00.txt

There has been some off-list discussion about whether to push
this forward as a separate draft or whether to include this new
sub-option inside of the existing server-id-override draft.

Several people initially felt that combining the drafts was the
most expeditious approach, and I don't deny that.  Certainly if
we need the server-id-override draft to reference (in pretty much
any way, even using a SHOULD) the relay-agent-flags draft, they
should probably be together.

Alternatively, the relay-agent-flags byte is useful outside of
the scope of the server-id-override option, and may well have
more general applicability -- which makes combining the drafts a
bit awkward, since the relay-agent-flags could easily get lost in
the other draft.

In any case, whatever we decide to do here (and it doesn't make
*that* much difference), we thought that reviewing the ideas and
words might be easier using a separate draft.  Once we get
general agreement that we have the sub-option we want, we can
integrate it into the server-id-override draft or continue to
push it as a separate draft.

If we can get feedback soon on this draft, then we can fix it in
time for the submission deadline for the next IETF and integrate
it if that is the sense of the list.

Enjoy -- Kim

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg