Subject: [dhcwg] draft-asati-dhc-relay-agent-config-00.txt

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Sep 2010 13:05:52 -0700

Rajiv Asati and Ralph Droms have published a new draft describing a container option for delivering configuration information to relay agents:

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

It might be worth taking a look at.

Ralph, Rajiv, I have some questions to kick off the discussion.

First, why are you defining a container, and not defining what goes in it?

Second, why not just define some RAIO options that contain configuration information?

Third, in what message exchange do you anticipate that these options will be carried? In Appendix A, you propose that the client will broadcast a DHCP request, but don't say what sort of request you intend to broadcast.

---

From: Andre Kostur <[email-masked]>
Date: Thu, 30 Sep 2010 13:42:42 -0700

> First, why are you defining a container, and not defining what goes in it?

Same question.  What sort of configuration items are going to go into this option?  Can they be configured through other already existing options?

> Second, why not just define some RAIO options that contain configuration information?

I don't think that RAIO can be used in this case.  This option appears to be intended to be used by the relay agent to request certain sub-options (I guess) from the server, and the server composes a new instance of this option to put in the returned packet.  An RAIO option would need to be composed by the relay agent, and the server is only allowed to copy it verbatim into the replay, which means that the server doesn't get an opportunity to modify the contents of the RAIO before sending it back to the relay.

> Third, in what message exchange do you anticipate that these options will be carried? In Appendix A, you propose that the client will broadcast a DHCP request, but don't say what sort of request yo…

Same question.  I could suggest that the relay emit a DHCPINFORM to obtain this information.  In this case you don't even need to have the special processing requirements of putting this option into a particular location within the packet.

For the authors:

Section 1, 3rd paragraph:  RFC 3046 doesn't defined "DHCP Relay Agent functionality".  That's back in 2131 (and as I recall, refers back to the BOOTP specs).

Section 5.1.1: Talks about how a trusted downstream relay may have added this option and the middle relay is to just pass it along up to the server.  What it doesn't talk about is the return path.  Section 5.1 specifies that the relay agent MUST remove the relay agent configuration option, and thus the trusted downstream would never hear the response.

And.. what's the implications of this in the IPv6 world?  Is there to be a corresponding DHCPv6 option for the same purposes?