Subject: Re: [dhcwg] IETF76 dhcwg agenda UPDATE

From: "Huang Lu" <[email-masked]>
Date: Wed, 18 Nov 2009 11:19:05 +0800

Hi, all

Through the discussion, I think that it's better to use only one option (not cascade options) to solve the problem, option 82 or a new option. But changing current option 82 will invalidate the signiture. So new option is better.

Further more, I suggest that relay agent ID information should be included in the option whether option82 or the new option, which make sure that server and agent can get correct information instead of depending only on the sequence of different agent's information.

Thanks

B.R.
Lu Huang
[email-masked]
2009-11-18

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Nov 2009 22:36:24 -0500

> Through the discussion, I think that it's better to use only one option (not cascade options) to solve the problem, option 82 or a new option. But changing current option 82 will invalidate the sig…

The suggestion I liked best was Bernie's, which I will translate for those who may not have parsed it correctly (or perhaps I didn't!): he's proposing that we add two new DHCP message types, something like "DHCPRELAYFORWARD" and "DHCPRELAYREPLY".

A relay agent that's capable of encapsulation would simply take the DHCP message and insert into the beginning of the message a dhcp message id option with the DHCPRELAYFORWARD option code.   It would, in addition, include whatever relay agent suboptions it wanted to add, in an option 82 encapsulation.    The DHCP header would be left unmodified, except that it might fiddle giaddr.   This means that filename and sname would be left untouched.

After the relay-added options, there would be a new option code marker, TBD, and either it would have an 8-bit length and we'd use concatenation for long buffers or (my preference) it would just have a 16-bit length.   We'd have to figure out some way to avoid having this crash non-compliant DHCP servers, and the new format would not work with DHCP servers that didn't understand the DHCPRELAYFORWARD message.

I think using the two-byte length field is the right thing because if we didn't do it this way, we'd have to support nesting concatenation, which I think would be really heinous.

Comments?   Thoughts?   Rotten tomatoes?