RE: [dhcwg] Order of occurence of DHCPv6 options

Vijay:

On the order of options, we chose specifically NOT to specify this. There really is no
requirement or overwhelming reason to do this. Putting some options earlier than others
improves performance in some situations so it will be wise for clients (and servers) to
do this, but it is difficult to specify this and a client and server MUST assume the 
worst anyway.

For example, I'd argue that putting the Server Identifier option first (or very early)
is best since it allows all servers that receive this (except for the intended one) to
drop the packet almost immediately. Rather than having to look through 4 options, won't
it be better if these servers only had to look at 1 option (the first).

Though, having said that there is no reason to require this and depending on how a client
or server processes packets, the above might not even apply (for example, if a client or
server always decodes all options to validate the packet, it won't save anything).

So, we specifically decided not to specify option ordering and I think that is a wise
decision. 

Regarding the other issues, some clean-up for the draft will be required to remove and
fix items based on the final status codes/option usage.

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Saturday, June 15, 2002 1:31 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Order of occurence of DHCPv6 options

I think, we need to fix the order of options occuring in DHCPv6 messages
for better processing of the messages.

1. Elapsed Time option - Since based on this value only, the relay/server is
going to decide the policy of reply.

2. Status Code - In the case of Failure, this message can be directly
ignored

3. Authentication option - If authentication fails, nothing is needed to
be processed.

4. server-id - If the server id doesn't match, server can ignore it.

5. client-id - If the client id doesn't match, client can ignore it.

6. Rapid commit - Based on this, the server can determine whether it need
to send Advertise or Reply.

If any of these options are occuring, then they MUST occur in this order.

----------------------------------------------------------------------------
--

ConfNoMatch and AddrUnavail are nowhere used. It can be removed.

AuthFailed is also nowhere used. We need to add text saying if the
server/client is not able to authenticate the other, then they
should send reply with error code AuthFailed set.

----------------------------------------------------------------------------
--
R-forw.    *                        *     *      *      *
R-repl.    *                        *     *      *      *

Why Authentication, User class, Vendor class, Vendor specific options
are needed in Relay-fwd and Relay-reply message.

~Vijay

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