Subject: [dhcwg] Order of occurence of DHCPv6 options

From: "Vijayabhaskar A K" <[email-masked]>
Date: Sat, 15 Jun 2002 23:00:56 +0530

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 19 Jun 2002 17:51:59 -0400

Just as a note to another doc.  For IPv6 processing you MUST process all options/extensions an implementation is not allowed to skip them.  
/jim

> -----Original Message-----
> From: Vijayabhaskar A K [mailto:[email-masked]]
> Sent: Monday, June 17, 2002 6:19 AM
> To: 'Bernie Volz (EUD)'; [email-masked]
> Subject: RE: [dhcwg] Order of occurence of DHCPv6 options
> 
> 
> Hi Bernie,
> 
> The requirement here is PERFORMANCE. Assume there are 1000 
> requests passing
> through a server which are NOT intended to be handled by this 
> server. This
> will happen since most of the messages are Multicast only. 
> This is not the
> corner case situation as you said, this will happen in most 
> of the cases.
> There is nothing wrong in mandating this. This is something 
> like specifying
> these options in a fixed mesg header. The server/client will 
> ignore the
> remaining
> option field, if there is any error in the mesg header.
> 
> All of the above, the relay should be lightweight, if the admin has
> configured
> the relay to load balance based on Elapsed time option and how bad the
> performance will be if the relay has to search for this 
> option by parsing
> the whole message.
> 
> > 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).
> 
> Then, this is a poor implementation. If the first option itself is
> erraneous, (for ex. auth itself fails), then there is no need to
> parse remaining stuff. We should leave these kind of implementation
> as corner case and go on mandating options' order of occurence.
> 
> ~ Vijay
> 
> -----Original Message-----
> From: Bernie Volz (EUD) [mailto:[email-masked]]
> Sent: Saturday, June 15, 2002 11:06 PM
> To: [email-masked]'; [email-masked]
> Subject: 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:[email-masked]]
> Sent: Saturday, June 15, 2002 1:31 PM
> To: [email-masked]
> Subject: [dhcwg] Order of occurence of DHCPv6 options
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 19 Jun 2002 18:00:26 -0400

Vijay,

I think Ralph is not disagreeing with you.  But for proposed standard I think is our first goal here.  I don't think we will get agreement on the ordering at all quickly.  

Also though I am a strong believer in extrapolation I do think it wise to do some implementation benchmarks to support any decision in this direction if for no other reason than it just reinforces a critical point.  Also one OS virtual memory might lend itself to parsing options far different than another.  Such as a router OS with flat virtual memory space vs a huge lab server with GBs of memory and VM threads.   So any extrapolation can be argued to not be 100% scientifically.

I do agree though that options should not be permitted to be skipped in the sense that one does not look at the option code in an implementation.  Steve Deering pushed this very strongly for IPv6 options and for very good reason.  I believe those principles hold here too for DHCPv6.

regards,
/jim

> Sent: Monday, June 17, 2002 10:02 AM
> To: 'Ralph Droms'
> Cc: 'Bernie Volz (EUD)'; [email-masked]
> Ralph,
> For something like this, we dont need implementations at all.
> Its very sure that there willl be performance degradation
> in relay, if the Elapsed time option is not the first one.
> If the relay is configured to do load balance, then the relay has to
> process the whole message in search of this option, leading to the
> performance degradation in relay. we suppose relay to be light weight.
> Similar case is for server, if the authentication or server-id is not
> first, then it is going to process the whole message to discard the
> packet.
> 
> This is something like, rejecting the dhcpv6 packet, if
> 1 <= message type <= 13 is not true. If there are more important
> options defined later, which has to occur first, then in
> that specification, we can rearrage the order and precedence.
> I think, we can define the order of the known important options now.
> 
> ~ Vijay
> From: Ralph Droms [mailto:[email-masked]]
> Sent: Monday, June 17, 2002 6:29 PM
> To: [email-masked]
> Cc: 'Bernie Volz (EUD)'; [email-masked]
> Unitl we have more experience with real implementations, it's 
> hard to know
> exactly what to optimize.  So, let's run some experiments once we have
> interopable implementations and get some experience with real 
> deployments
> so we can understand where the performance hits and improvement
> opportunities are.  Then we can write up that experience and a
> specification for option ordering...
> 
> - Ralph
> 
> At 03:49 PM 6/17/2002 +0530, Vijayabhaskar A K wrote:
> >Hi Bernie,
> >
> >through a server which are NOT intended to be handled by 
> this server. This
> >On the order of options, we chose specifically NOT to 
> specify this. There
> >really is no
> >do this, but it is difficult to specify this and a client 
> and server MUST
> >assume the
> >worst anyway.
> and depending
> on
> (for example,
> if
> >1. Elapsed Time option - Since based on this value only, the 
> relay/server
> is
> >-------------------------------------------------------------
> --------------
> -
> >--
> >-------------------------------------------------------------
> --------------
> -
> >--
> >R-forw.    *                        *     *      *      *
> >R-repl.    *                        *     *      *      *