RE: [dhcwg] Order of occurence of DHCPv6 options
"Vijayabhaskar A K" <vijayak@india.hp.com> Mon, 17 June 2002 10:25 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25466 for <dhcwg-archive@odin.ietf.org>; Mon, 17 Jun 2002 06:25:45 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA04268 for dhcwg-archive@odin.ietf.org; Mon, 17 Jun 2002 06:26:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04058; Mon, 17 Jun 2002 06:17:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04032 for <dhcwg@optimus.ietf.org>; Mon, 17 Jun 2002 06:17:50 -0400 (EDT)
Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25369 for <dhcwg@ietf.org>; Mon, 17 Jun 2002 06:17:11 -0400 (EDT)
Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel8.hp.com (Postfix) with ESMTP id 6135FA00B05; Mon, 17 Jun 2002 06:17:13 -0400 (EDT)
Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by dce.india.hp.com with SMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id PAA26021; Mon, 17 Jun 2002 15:52:28 +0530 (IST)
Reply-To: vijayak@india.hp.com
From: Vijayabhaskar A K <vijayak@india.hp.com>
To: "'Bernie Volz (EUD)'" <Bernie.Volz@am1.ericsson.se>, dhcwg@ietf.org
Subject: RE: [dhcwg] Order of occurence of DHCPv6 options
Date: Mon, 17 Jun 2002 15:49:18 +0530
Message-ID: <001901c215e8$70958bc0$2f290a0f@india.hp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D5D6@EAMBUNT705>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit
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:Bernie.Volz@am1.ericsson.se] Sent: Saturday, June 15, 2002 11:06 PM To: 'vijayak@india.hp.com'; dhcwg@ietf.org 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: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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Order of occurence of DHCPv6 options Vijayabhaskar A K
- RE: [dhcwg] Order of occurence of DHCPv6 options Bernie Volz (EUD)
- RE: [dhcwg] Order of occurence of DHCPv6 options Vijayabhaskar A K
- RE: [dhcwg] Order of occurence of DHCPv6 options Ralph Droms
- RE: [dhcwg] Order of occurence of DHCPv6 options Bernie Volz (EUD)
- RE: [dhcwg] Order of occurence of DHCPv6 options Vijayabhaskar A K
- RE: [dhcwg] Order of occurence of DHCPv6 options Vernon Schryver
- RE: [dhcwg] Order of occurence of DHCPv6 options Mark Stapp
- [dhcwg] unsubscribe Radha Rani D
- Re: [dhcwg] unsubscribe Ralph Droms
- RE: [dhcwg] Order of occurence of DHCPv6 options Bound, Jim
- RE: [dhcwg] Order of occurence of DHCPv6 options Bound, Jim