Subject: Re: [dhcwg] IETF76 dhcwg agenda UPDATE

From: "Lu Huang" <[email-masked]>
Date: Wed, 18 Nov 2009 17:24:49 +0800

Hi, Ted

I'm not sure whether my understanding is right, maybe there are two possible ways:

1. When 2nd relay agent receives discovery message, it change the type from "discovery" to "RELAY FORWARD" and add in information as needed before forwarding message to server. But the problem is server may be unable to recognize RELAY FORWARD message and no more work could go on because there's no discovery message any more.

2. When 2nd relay agent receives discovery message, it forwards the message as normal and create a new RELAY FORWARD message to convey information as needed. But firstly, server may be unable to recognize RELAY FORWARD message (it still can handle discovery message). Secondly, if server support the new type, maybe it should wait until having received both discovery and RELAY FORWARD message, then go ahead. If one of these two message lose on the way, we have to make a waiting timer for limitation. It will slow down the processing of those discovery messages not requiring RELAYFORWARD.

Thanks

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

======= 2009-11-18 11:36:24 您在来信中写道：=======

>On Nov 17, 2009, at 10:19 PM, Huang Lu wrote:
>> 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.
>
>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?
>
>
>__________ Information from ESET NOD32 Antivirus, version of virus signature database 4613 (20091116) __________
>
>The message was checked by ESET NOD32 Antivirus.
>
>http://www.eset.com