From owner-dhcp-v6@bucknell.edu Mon May 7 23:52:33 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29982; Mon, 7 May 2001 23:52:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f483nSW23481; Mon, 7 May 2001 23:49:29 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f483nHW06276 for ; Mon, 7 May 2001 23:49:18 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f483nM816528 for ; Mon, 7 May 2001 22:49:22 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f483nG704872 for ; Mon, 7 May 2001 22:49:16 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Mon May 07 22:49:15 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 22:49:15 -0500 Message-ID: <66F66129A77AD411B76200508B65AC694CBAB8@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: Reconfigure-Inits Date: Mon, 7 May 2001 22:49:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D771.D9A2B810" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D771.D9A2B810 Content-Type: text/plain; charset="iso-8859-1" One item to consider ... presently, the -18 draft wording has the Reconfigure-Init (unicast case) going directly to the client. This means that this message bypasses any relay-agent. And, there is no mechanism to prevent this. Might we want to consider that the server should save the relay-agent information (if any) along with the client information and use the relay-agent to forward the Reconfigure-Init to the client? This would either be the default (so that all traffic goes via the relay) and there's some negotiation to allow direct communication or to we allow the client and server to communicate directly and by default and have a mechanism to disable this? I know there are many that would like to allow direct communication between client and server, but think of the security implications. It is easier to secure the server to relay-agent path than the server to client path, meaning the relay could easily drop any spoofed packets and never allow them into the network. Relay-agent logic is drop all Reconfigure-Init messages except those relayed thru me from a known list of server (and perhaps the Relay-Reply needs some special authentication information in addition). This is especially attractive in cable-modem and DSL environment I should think. - Bernie Volz ------_=_NextPart_001_01C0D771.D9A2B810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reconfigure-Inits

One item to consider ... presently, = the -18 draft wording has the Reconfigure-Init (unicast case) going = directly to the client. This means that this message bypasses any = relay-agent. And, there is no mechanism to prevent this.

Might we want to consider that the = server should save the relay-agent information (if any) along with the = client information and use the relay-agent to forward the = Reconfigure-Init to the client? This would either be the default (so = that all traffic goes via the relay) and there's some negotiation to = allow direct communication or to we allow the client and server to = communicate directly and by default and have a mechanism to disable = this?

I know there are many that would like = to allow direct communication between client and server, but think of = the security implications. It is easier to secure the server to = relay-agent path than the server to client path, meaning the relay = could easily drop any spoofed packets and never allow them into the = network. Relay-agent logic is drop all Reconfigure-Init messages except = those relayed thru me from a known list of server (and perhaps the = Relay-Reply needs some special authentication information in addition). = This is especially attractive in cable-modem and DSL environment I = should think.

- Bernie Volz

------_=_NextPart_001_01C0D771.D9A2B810-- From owner-dhcp-v6@bucknell.edu Mon May 7 23:53:23 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00017; Mon, 7 May 2001 23:53:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f483oxW23377; Mon, 7 May 2001 23:50:59 -0400 (EDT) Received: from imr2.ericy.com ([12.34.240.68]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f483ofW21037 for ; Mon, 7 May 2001 23:50:41 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f483oL803733 for ; Mon, 7 May 2001 22:50:25 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f483oL705428 for ; Mon, 7 May 2001 22:50:21 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon May 07 22:50:20 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 22:50:20 -0500 Message-ID: <66F66129A77AD411B76200508B65AC694CBAB9@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: Status of -19 Draft?? Date: Mon, 7 May 2001 22:50:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D772.002A2720" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D772.002A2720 Content-Type: text/plain; charset="iso-8859-1" Ralph, Jim, ... Can we get an update on where things stand on the -19 draft? When can we expect it? Is there any assistance we (I) can provide? Thanks in advance! - Bernie Volz ------_=_NextPart_001_01C0D772.002A2720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Status of -19 Draft??

Ralph, Jim, ...

Can we get an update on where things = stand on the -19 draft? When can we expect it? Is there any assistance = we (I) can provide?

Thanks in advance!

- Bernie Volz

------_=_NextPart_001_01C0D772.002A2720-- From owner-dhcp-v6@bucknell.edu Tue May 8 00:32:04 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00850; Tue, 8 May 2001 00:32:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f484TdW32565; Tue, 8 May 2001 00:29:39 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f484TQW11169 for ; Tue, 8 May 2001 00:29:26 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA12619; Tue, 8 May 2001 00:29:25 -0400 Date: Tue, 8 May 2001 00:29:25 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: Reconfigure-Inits In-Reply-To: <66F66129A77AD411B76200508B65AC694CBAB8@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN There should be no use of relay agent for reconfigure-init at this point. If we want to add it at a later date that is fine. I do not think this is important to get a spec out. /jim On Mon, 7 May 2001, Bernie Volz (EUD) wrote: > One item to consider ... presently, the -18 draft wording has the Reconfigure-Init (unicast case) going directly to the client. This means that this message bypasses any relay-agent. And, there is no mechanism to prevent this. > > Might we want to consider that the server should save the relay-agent information (if any) along with the client information and use the relay-agent to forward the Reconfigure-Init to the client? This would either be the default (so that all traffic goes via the relay) and there's some negotiation to allow direct communication or to we allow the client and server to communicate directly and by default and have a mechanism to disable this? > > I know there are many that would like to allow direct communication between client and server, but think of the security implications. It is easier to secure the server to relay-agent path than the server to client path, meaning the relay could easily drop any spoofed packets and never allow them into the network. Relay-agent logic is drop all Reconfigure-Init messages except those relayed thru me from a known list of server (and perhaps the Relay-Reply needs some special authentication information in addition). This is especially attractive in cable-modem and DSL environment I should think. > > - Bernie Volz > > From owner-dhcp-v6@bucknell.edu Thu May 17 02:20:02 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08360; Thu, 17 May 2001 02:20:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4H6FTJ11345; Thu, 17 May 2001 02:15:29 -0400 (EDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4H6FEJ32549 for ; Thu, 17 May 2001 02:15:14 -0400 (EDT) Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id QAA50852 for ; Thu, 17 May 2001 16:01:43 +1000 From: skodati@in.ibm.com Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m3/NCO v4.96) with SMTP id QAA43464 for ; Thu, 17 May 2001 16:13:55 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A4F.002143E2 ; Thu, 17 May 2001 16:03:20 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: DHCPv6 discussion list Message-ID: Date: Thu, 17 May 2001 10:24:17 +0530 Subject: Reconfigure-init message in DHCPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have a few doubts in draft-ietf-dhc-dhcpv6-18 reconfigure-init messages, draft18 says, "server may unicat a reconfigure-init messages directly to a single client or use a multicast....", If the server wants to multicast the message, Do we need to have a predefined 'All DHCP Clients' multicast address ( which is put under discussion in draft) so that the server send the reconfigure-init message to that multicast address, If so, what should be the scope of the address? If it is site-local (as put under discussion), how can a server send a reconfigure-init message to specific subnet (asume that there is a single server for more than one subnet). thanks and regards Suresh Kodati From owner-dhcp-v6@bucknell.edu Thu May 17 09:55:19 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17679; Thu, 17 May 2001 09:55:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4HDq5J15361; Thu, 17 May 2001 09:52:05 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4HDpuJ03388 for ; Thu, 17 May 2001 09:51:56 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f4HDpta21612 for ; Thu, 17 May 2001 08:51:55 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f4HDptI02853 for ; Thu, 17 May 2001 08:51:55 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu May 17 08:51:54 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 08:51:54 -0500 Message-ID: <66F66129A77AD411B76200508B65AC694CBB5E@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Reconfigure-init message in DHCPv6 Date: Thu, 17 May 2001 08:51:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DED8.87423820" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0DED8.87423820 Content-Type: text/plain; charset="iso-8859-1" Per discussions during a design team meeting and at the March IETF, we hope to punt on the multicast reconfigure-init support for now. The problem is that security is difficult to do in this situation and making sure that a client doesn't reconfigure multiple times in case the message is sent several times is tricky (and unicast might be needed anyway if only a few clients don't response to the multicast). See http://www.listproc.bucknell.edu/archives/dhcp-v6/200104/msg00003.html. www.dhcp.org also has some other notes. - Bernie Volz -----Original Message----- From: skodati@in.ibm.com [mailto:skodati@in.ibm.com] Sent: Thursday, May 17, 2001 12:54 AM To: DHCPv6 discussion list Subject: Reconfigure-init message in DHCPv6 I have a few doubts in draft-ietf-dhc-dhcpv6-18 reconfigure-init messages, draft18 says, "server may unicat a reconfigure-init messages directly to a single client or use a multicast....", If the server wants to multicast the message, Do we need to have a predefined 'All DHCP Clients' multicast address ( which is put under discussion in draft) so that the server send the reconfigure-init message to that multicast address, If so, what should be the scope of the address? If it is site-local (as put under discussion), how can a server send a reconfigure-init message to specific subnet (asume that there is a single server for more than one subnet). thanks and regards Suresh Kodati ------_=_NextPart_001_01C0DED8.87423820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Reconfigure-init message in DHCPv6

Per discussions during a design team meeting and at = the March IETF, we hope to punt on the multicast reconfigure-init = support for now. The problem is that security is difficult to do in = this situation and making sure that a client doesn't reconfigure = multiple times in case the message is sent several times is tricky (and = unicast might be needed anyway if only a few clients don't response to = the multicast).

See http://www.listproc.bucknell.edu/archives/dhcp-v6/2001= 04/msg00003.html. www.dhcp.org also has some other notes.

- Bernie Volz

-----Original Message-----
From: skodati@in.ibm.com [mailto:skodati@in.ibm.com]=
Sent: Thursday, May 17, 2001 12:54 AM
To: DHCPv6 discussion list
Subject: Reconfigure-init message in DHCPv6


I have a few doubts in draft-ietf-dhc-dhcpv6-18 = reconfigure-init messages,
draft18 says, "server may unicat a = reconfigure-init messages directly to a
single client or use a multicast....",

If the server wants to multicast the message,
      Do we need to have a = predefined 'All DHCP Clients' multicast address
( which is put under discussion in draft) so that = the server send the
reconfigure-init message to that multicast address, = If so, what should be
the scope of the address? If it is site-local (as = put under discussion),
how can a server send a reconfigure-init message to = specific subnet (asume
that there is a single server for more than one = subnet).

thanks and regards
   Suresh Kodati

------_=_NextPart_001_01C0DED8.87423820-- From owner-dhcp-v6@bucknell.edu Mon May 21 05:34:27 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04339; Mon, 21 May 2001 05:34:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4L9WiJ24688; Mon, 21 May 2001 05:32:44 -0400 (EDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4L9WWJ29246 for ; Mon, 21 May 2001 05:32:32 -0400 (EDT) Received: from f03n07e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id TAA59252 for ; Mon, 21 May 2001 19:19:05 +1000 From: skodati@in.ibm.com Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m3/NCO v4.96) with SMTP id TAA49824 for ; Mon, 21 May 2001 19:31:21 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A53.00344D0D ; Mon, 21 May 2001 19:31:15 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: DHCPv6 discussion list Message-ID: Date: Mon, 21 May 2001 14:13:24 +0530 Subject: Renew and Rebind messages: DHCPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >From the draft 18 on DHCPv6 I have the following doubts on DHCP RENEW and REBIND messages:- 1. Significance of server preference field in REPLY message for RENEW:- Since the client is contacting a particular server from which it acquired parameters, is the any importance to the preference field of REPLY message for RENEW. Or it is simply to bring commonality for REPLY messages. 2. Why we need to have RENEW and REBIND as seperate messages:- There is no significant difference between the message formats, except that in RENEW the server address field is the address of server from which the client acquired the parameters, and in case of REBIND it is 0's. There is no difference in the way the server reacts when it receives a renew or rebind messages ( except if something goes into 'implementation specific manner'). Or any security factors are involved. thanks and regards Suresh Kodati Email:- skodati@in.ibm.com From owner-dhcp-v6@bucknell.edu Mon May 28 08:42:24 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04170; Mon, 28 May 2001 08:42:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4SCfkJ09816; Mon, 28 May 2001 08:41:46 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4SCfVJ20543 for ; Mon, 28 May 2001 08:41:31 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f4SCfNF18036 for ; Mon, 28 May 2001 14:41:24 +0200 Received: from rennes.enst-bretagne.fr (jugon.rennes.enst-bretagne.fr [193.52.74.50]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA11160 for ; Mon, 28 May 2001 14:41:23 +0200 (MET DST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3B124770.FC80E25F@rennes.enst-bretagne.fr> Date: Mon, 28 May 2001 14:41:20 +0200 From: Jerome MARCHAND Organization: ENST Bretagne X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: DHCPv6 Threats Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: jmarchan@rennes.enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCPv6 Threats Author(s) : N. Prigent, J. Marchand, F. Dupont, B. Cousin, M. Laurent-Maknavicius, J. Bournelle Filename : draft-prigent-dhcpv6-threats-00.txt Location : http://www.ietf.org/internet-drafts/draft-prigent-dhcpv6-threats-00.txt Pages : 19 Date : 24-May-01 N. Prigent, J. Marchand From owner-dhcp-v6@bucknell.edu Wed May 30 15:24:57 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22296; Wed, 30 May 2001 15:24:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4UJMZJ16780; Wed, 30 May 2001 15:22:35 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4UJMOJ30665 for ; Wed, 30 May 2001 15:22:24 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-120.cisco.com [161.44.149.120]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA12938 for ; Wed, 30 May 2001 15:21:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20010530151856.03a36860@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 May 2001 15:20:48 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: Reconfigure-init message in DHCPv6 In-Reply-To: <66F66129A77AD411B76200508B65AC694CBB5E@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 08:51 AM 5/17/2001 -0500, Bernie Volz (EUD) wrote: >Per discussions during a design team meeting and at the March IETF, we >hope to punt on the multicast reconfigure-init support for now. Yes, Reconfigure-init will *not* have multicast as an option in the next DHCP spec draft. - Ralph From owner-dhcp-v6@bucknell.edu Thu May 31 02:32:54 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15742; Thu, 31 May 2001 02:32:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4V6VdJ14155; Thu, 31 May 2001 02:31:39 -0400 (EDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4V6VSJ16788 for ; Thu, 31 May 2001 02:31:28 -0400 (EDT) Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id QAA48444 for ; Thu, 31 May 2001 16:17:56 +1000 From: skodati@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f03n05e.au.ibm.com (8.8.8m3/NCO v4.96) with SMTP id QAA63368 for ; Thu, 31 May 2001 16:29:03 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A5D.0022EA0E ; Thu, 31 May 2001 16:21:21 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: DHCPv6 discussion list cc: bsuparna@in.ibm.com, rsharada@in.ibm.com Message-ID: Date: Thu, 31 May 2001 11:41:52 +0530 Subject: RE: Reconfigure-init message in DHCPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >>Per discussions during a design team meeting and at the March IETF, we >>hope to punt on the multicast reconfigure-init support for now. > >Yes, Reconfigure-init will *not* have multicast as an option in the next >DHCP spec draft. > > >- Ralph I have doubt on how does a server send RECONFIG message If it tries to reconfigure a network. Does it send 1) RECONFIG to all the clients once, and waits for REQUEST from clients. (Or) 2) it sends RECONFIG messages one by one to all clients and ensures that all clients gets reconfigured. In that case the server should wait for RECCREP_MSG_TIMEOUT ( default 2000 ms) for REC_MSG_ATTEMPTS ( default 10) times, which means it has to wait for 20 seconds for a node, and it may take too long to configure whole network. Is the transaction id is going to be same for all messages or different in both the cases..... suresh. From owner-dhcp-v6@bucknell.edu Thu May 31 05:42:37 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19010; Thu, 31 May 2001 05:42:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4V9ewJ23569; Thu, 31 May 2001 05:40:58 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4V9erJ21571 for ; Thu, 31 May 2001 05:40:53 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f4V9eqa13249 for ; Thu, 31 May 2001 04:40:52 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f4V9eq909704 for ; Thu, 31 May 2001 04:40:52 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu May 31 04:40:50 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 04:40:50 -0500 Message-ID: <66F66129A77AD411B76200508B65AC694CBBB8@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Cc: bsuparna@in.ibm.com, rsharada@in.ibm.com Subject: RE: Reconfigure-init message in DHCPv6 Date: Thu, 31 May 2001 04:40:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E9B5.C70B41D0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0E9B5.C70B41D0 Content-Type: text/plain; charset="iso-8859-1" I would think that how a server deals with this is an implementation issue and should not be covered by the protocol. The protocol can accommodate either mode - it really is up to the server to deal with this. I would suspect that (1) is more likely. Perhaps the most typically implementation may be to send requests to clients and then wait for the clients to respond (or timeout) and as they do, send additional requests. This avoids flooding the network with packets and also staggers client responses some. Approach (2) is likely not very good as it would, as you point out, take a very long time if there are a lot of clients. I don't believe there is any need for the transaction id to be the same for all clients (retransmitted requests to a particular client should use the same id). Note though that there is little reason why the server would necessarily need a new transaction id for each client - it could use the same for all clients if it wanted to. Again, I think this is an implementation issue. - Bernie Volz -----Original Message----- From: skodati@in.ibm.com [mailto:skodati@in.ibm.com] Sent: Thursday, May 31, 2001 2:12 AM To: DHCPv6 discussion list Cc: bsuparna@in.ibm.com; rsharada@in.ibm.com Subject: RE: Reconfigure-init message in DHCPv6 >>Per discussions during a design team meeting and at the March IETF, we >>hope to punt on the multicast reconfigure-init support for now. > >Yes, Reconfigure-init will *not* have multicast as an option in the next >DHCP spec draft. > > >- Ralph I have doubt on how does a server send RECONFIG message If it tries to reconfigure a network. Does it send 1) RECONFIG to all the clients once, and waits for REQUEST from clients. (Or) 2) it sends RECONFIG messages one by one to all clients and ensures that all clients gets reconfigured. In that case the server should wait for RECCREP_MSG_TIMEOUT ( default 2000 ms) for REC_MSG_ATTEMPTS ( default 10) times, which means it has to wait for 20 seconds for a node, and it may take too long to configure whole network. Is the transaction id is going to be same for all messages or different in both the cases..... suresh. ------_=_NextPart_001_01C0E9B5.C70B41D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Reconfigure-init message in DHCPv6

I would think that how a server deals with this is an = implementation issue and should not be covered by the protocol. The = protocol can accommodate either mode - it really is up to the server to = deal with this. I would suspect that (1) is more likely. Perhaps the = most typically implementation may be to send requests to <N> = clients and then wait for the clients to respond (or timeout) and as = they do, send additional requests. This avoids flooding the network = with packets and also staggers client responses some. Approach (2) is = likely not very good as it would, as you point out, take a very long = time if there are a lot of clients.

I don't believe there is any need for the transaction = id to be the same for all clients (retransmitted requests to a = particular client should use the same id). Note though that there is = little reason why the server would necessarily need a new transaction = id for each client - it could use the same for all clients if it wanted = to. Again, I think this is an implementation issue.

- Bernie Volz

-----Original Message-----
From: skodati@in.ibm.com [mailto:skodati@in.ibm.com]=
Sent: Thursday, May 31, 2001 2:12 AM
To: DHCPv6 discussion list
Cc: bsuparna@in.ibm.com; rsharada@in.ibm.com
Subject: RE: Reconfigure-init message in = DHCPv6



>>Per discussions during a design team meeting = and at the March IETF, we
>>hope to punt on the multicast = reconfigure-init support for now.
>
>Yes, Reconfigure-init will *not* have multicast = as an option in the next
>DHCP spec draft.
>
>
>- Ralph

I have doubt on how does a server send RECONFIG = message If it tries to
reconfigure a network. Does it send
     1) RECONFIG to all the = clients once, and waits for REQUEST from
clients.
     (Or)
     2)  it sends RECONFIG = messages one by one to all clients and ensures
that all clients gets reconfigured. In that case the = server should wait for
RECCREP_MSG_TIMEOUT ( default 2000 ms) for = REC_MSG_ATTEMPTS ( default 10)
times, which means it has to wait for 20 seconds for = a node, and it may
take too long to configure whole network.

Is the transaction id is going to be same for all = messages or different in
both the cases.....

suresh.

------_=_NextPart_001_01C0E9B5.C70B41D0-- From owner-dhcp-v6@bucknell.edu Thu May 31 06:24:15 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19324; Thu, 31 May 2001 06:24:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4VAMwJ29602; Thu, 31 May 2001 06:22:58 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4VAMoJ06071 for ; Thu, 31 May 2001 06:22:50 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn-tmp30.cisco.com [10.21.64.30]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA06593; Thu, 31 May 2001 06:22:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20010531061506.00ba1728@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 May 2001 06:21:44 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: Reconfigure-init message in DHCPv6 Cc: DHCPv6 discussion list , bsuparna@in.ibm.com, rsharada@in.ibm.com In-Reply-To: <66F66129A77AD411B76200508B65AC694CBBB8@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I agree with Bernie that the mechanisms for sending Reconfigure-init to multiple clients is an implementation issue and shouldn't be specified in the spec. The next draft will use a slightly different strategy for the transaction ID. As suggested by Thomas Narten, the transaction ID in the client's Request message can be independent of the transaction ID in the Reconfigure-init message. However, we still have an issue with the transaction ID in retransmitted Reconfigure-init messages. If the server uses the same transaction ID in a retransmitted message, how does the client differentiate retransmission from duplicate messages? - Ralph At 04:40 AM 5/31/2001 -0500, Bernie Volz (EUD) wrote: >I would think that how a server deals with this is an implementation issue >and should not be covered by the protocol. The protocol can accommodate >either mode - it really is up to the server to deal with this. I would >suspect that (1) is more likely. Perhaps the most typically implementation >may be to send requests to clients and then wait for the clients to >respond (or timeout) and as they do, send additional requests. This avoids >flooding the network with packets and also staggers client responses some. >Approach (2) is likely not very good as it would, as you point out, take a >very long time if there are a lot of clients. > >I don't believe there is any need for the transaction id to be the same >for all clients (retransmitted requests to a particular client should use >the same id). Note though that there is little reason why the server would >necessarily need a new transaction id for each client - it could use the >same for all clients if it wanted to. Again, I think this is an >implementation issue. > >- Bernie Volz > >-----Original Message----- >From: skodati@in.ibm.com >[mailto:skodati@in.ibm.com] >Sent: Thursday, May 31, 2001 2:12 AM >To: DHCPv6 discussion list >Cc: bsuparna@in.ibm.com; rsharada@in.ibm.com >Subject: RE: Reconfigure-init message in DHCPv6 > > > >>Per discussions during a design team meeting and at the March IETF, we > >>hope to punt on the multicast reconfigure-init support for now. > > > >Yes, Reconfigure-init will *not* have multicast as an option in the next > >DHCP spec draft. > > > > > >- Ralph > >I have doubt on how does a server send RECONFIG message If it tries to >reconfigure a network. Does it send > 1) RECONFIG to all the clients once, and waits for REQUEST from >clients. > (Or) > 2) it sends RECONFIG messages one by one to all clients and ensures >that all clients gets reconfigured. In that case the server should wait for >RECCREP_MSG_TIMEOUT ( default 2000 ms) for REC_MSG_ATTEMPTS ( default 10) >times, which means it has to wait for 20 seconds for a node, and it may >take too long to configure whole network. > >Is the transaction id is going to be same for all messages or different in >both the cases..... > >suresh. From owner-dhcp-v6@bucknell.edu Thu May 31 10:10:48 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25831; Thu, 31 May 2001 10:10:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4VE9hJ03748; Thu, 31 May 2001 10:09:43 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4VE9XJ19801 for ; Thu, 31 May 2001 10:09:33 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-120.cisco.com [161.44.149.120]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA24192 for ; Thu, 31 May 2001 10:09:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20010531072121.03620f00@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 May 2001 10:08:28 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: Reconfigure-init message in DHCPv6 In-Reply-To: <4.3.2.7.2.20010531061506.00ba1728@mail.bucknell.edu> References: <66F66129A77AD411B76200508B65AC694CBBB8@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Oops, sorry. I responded without thinking all the way through Thomas' suggested mechanism for Reconfigure-init - in fact, I think it actually does solve the transaction ID problem... As I understand it, the Reconfigure-init message acts as a trigger that signals the client to complete a successful Request/Reply message exchange. Once the client has received a Recongfigure-init, the client proceeds with the Request/Reply message exchange (retransmitting the Request if necessary); the client ignores any additional Reconfigure-init messages (regardless of the transaction ID in the Reconfigure-init message) until the Request/Reply exchange is complete. Subsequent Reconfigure-init messages (again independent of the transaction ID) cause the client to initiate a new Request/Reply exchange. OK, so how does this mechanism work in the face of duplicated or retransmitted Reconfigure-init messages? Duplicate messages will be ignored because the client will begin the Request/Reply exchange after the receipt of the first Reconfigure-init. Retransmitted messages will either trigger the Request/Reply exchange (if the first Reconfigure-init was not received by the client) or will be ignored. The server can discontinue retransmission of Reconfigure-init messages to the client once the server receives the client's Request. It might be possible for a duplicate or retransmitted Reconfigure-init to be sufficiently delayed (and delivered out of order) to arrive at the client after the Request/Reply exchange (initiated by the original Reconfigure-init) has been completed. In this case, the client would initiate a redundant Request/Reply exchange. I think (although I could be convinced otherwise) that the likelihood of delayed and out of order delivery is small enough to be ignored. Also, the consequence of the redundant exchange is inefficiency rather than incorrect operation. I'll write up this new mechanism in the next draft of the spec. - Ralph At 06:21 AM 5/31/2001 -0400, Ralph Droms wrote: >I agree with Bernie that the mechanisms for sending Reconfigure-init to >multiple clients is an implementation issue and shouldn't be specified in >the spec. > >The next draft will use a slightly different strategy for the transaction >ID. As suggested by Thomas Narten, the transaction ID in the client's >Request message can be independent of the transaction ID in the >Reconfigure-init message. > >However, we still have an issue with the transaction ID in retransmitted >Reconfigure-init messages. If the server uses the same transaction ID in >a retransmitted message, how does the client differentiate retransmission >from duplicate messages? > >- Ralph > >At 04:40 AM 5/31/2001 -0500, Bernie Volz (EUD) wrote: > >>I would think that how a server deals with this is an implementation >>issue and should not be covered by the protocol. The protocol can >>accommodate either mode - it really is up to the server to deal with >>this. I would suspect that (1) is more likely. Perhaps the most typically >>implementation may be to send requests to clients and then wait for >>the clients to respond (or timeout) and as they do, send additional >>requests. This avoids flooding the network with packets and also staggers >>client responses some. Approach (2) is likely not very good as it would, >>as you point out, take a very long time if there are a lot of clients. >> >>I don't believe there is any need for the transaction id to be the same >>for all clients (retransmitted requests to a particular client should use >>the same id). Note though that there is little reason why the server >>would necessarily need a new transaction id for each client - it could >>use the same for all clients if it wanted to. Again, I think this is an >>implementation issue. >> >>- Bernie Volz >> >>-----Original Message----- >>From: skodati@in.ibm.com >>[mailto:skodati@in.ibm.com] >>Sent: Thursday, May 31, 2001 2:12 AM >>To: DHCPv6 discussion list >>Cc: bsuparna@in.ibm.com; rsharada@in.ibm.com >>Subject: RE: Reconfigure-init message in DHCPv6 >> >> >> >>Per discussions during a design team meeting and at the March IETF, we >> >>hope to punt on the multicast reconfigure-init support for now. >> > >> >Yes, Reconfigure-init will *not* have multicast as an option in the next >> >DHCP spec draft. >> > >> > >> >- Ralph >> >>I have doubt on how does a server send RECONFIG message If it tries to >>reconfigure a network. Does it send >> 1) RECONFIG to all the clients once, and waits for REQUEST from >>clients. >> (Or) >> 2) it sends RECONFIG messages one by one to all clients and ensures >>that all clients gets reconfigured. In that case the server should wait for >>RECCREP_MSG_TIMEOUT ( default 2000 ms) for REC_MSG_ATTEMPTS ( default 10) >>times, which means it has to wait for 20 seconds for a node, and it may >>take too long to configure whole network. >> >>Is the transaction id is going to be same for all messages or different in >>both the cases..... >> >>suresh. From owner-dhcp-v6@bucknell.edu Thu May 31 11:43:23 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29153; Thu, 31 May 2001 11:43:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4VFh0J24855; Thu, 31 May 2001 11:43:00 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4VFgpJ28953 for ; Thu, 31 May 2001 11:42:51 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4VFgZ814068 for ; Thu, 31 May 2001 10:42:36 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f4VFgZv19126 for ; Thu, 31 May 2001 10:42:35 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu May 31 10:41:40 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 10:41:40 -0500 Message-ID: <66F66129A77AD411B76200508B65AC694CBBBC@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Reconfigure-init message in DHCPv6 Date: Thu, 31 May 2001 10:41:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E9E8.2E3B8130" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0E9E8.2E3B8130 Content-Type: text/plain; charset="iso-8859-1" Ralph: Why not require that a new transaction id is used for subsequent reconfigure-inits? The reason is that this would solve the last problem - if a retransmitted or duplicated reconfigure-init is received by the client after the Request/Reply exchange has occurred. The only additional issue with this is that the server does need to generate unique transaction-ids, otherwise it is possible that a transaction id is duplicated if a server restarts. However, this is fairly easy to solve at the client by simply adding a time check - ie, if the transaction id of a reconfigure-init is the same as the last reconfigure-init from that server and was received within seconds of the Reply to the Request, treat this as a duplicate; otherwise it is a new request. I guess if you wanted to go with your proposal, then the transaction id in the reconfigure-init is really a don't care field (at least to the client) and it can ignore it completely. So, perhaps to make this clear it would be good to have the server not supply one or document that it is useless. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, May 31, 2001 10:08 AM To: DHCPv6 discussion list Subject: RE: Reconfigure-init message in DHCPv6 Oops, sorry. I responded without thinking all the way through Thomas' suggested mechanism for Reconfigure-init - in fact, I think it actually does solve the transaction ID problem... As I understand it, the Reconfigure-init message acts as a trigger that signals the client to complete a successful Request/Reply message exchange. Once the client has received a Recongfigure-init, the client proceeds with the Request/Reply message exchange (retransmitting the Request if necessary); the client ignores any additional Reconfigure-init messages (regardless of the transaction ID in the Reconfigure-init message) until the Request/Reply exchange is complete. Subsequent Reconfigure-init messages (again independent of the transaction ID) cause the client to initiate a new Request/Reply exchange. OK, so how does this mechanism work in the face of duplicated or retransmitted Reconfigure-init messages? Duplicate messages will be ignored because the client will begin the Request/Reply exchange after the receipt of the first Reconfigure-init. Retransmitted messages will either trigger the Request/Reply exchange (if the first Reconfigure-init was not received by the client) or will be ignored. The server can discontinue retransmission of Reconfigure-init messages to the client once the server receives the client's Request. It might be possible for a duplicate or retransmitted Reconfigure-init to be sufficiently delayed (and delivered out of order) to arrive at the client after the Request/Reply exchange (initiated by the original Reconfigure-init) has been completed. In this case, the client would initiate a redundant Request/Reply exchange. I think (although I could be convinced otherwise) that the likelihood of delayed and out of order delivery is small enough to be ignored. Also, the consequence of the redundant exchange is inefficiency rather than incorrect operation. I'll write up this new mechanism in the next draft of the spec. - Ralph At 06:21 AM 5/31/2001 -0400, Ralph Droms wrote: >I agree with Bernie that the mechanisms for sending Reconfigure-init to >multiple clients is an implementation issue and shouldn't be specified in >the spec. > >The next draft will use a slightly different strategy for the transaction >ID. As suggested by Thomas Narten, the transaction ID in the client's >Request message can be independent of the transaction ID in the >Reconfigure-init message. > >However, we still have an issue with the transaction ID in retransmitted >Reconfigure-init messages. If the server uses the same transaction ID in >a retransmitted message, how does the client differentiate retransmission >from duplicate messages? > >- Ralph > >At 04:40 AM 5/31/2001 -0500, Bernie Volz (EUD) wrote: > >>I would think that how a server deals with this is an implementation >>issue and should not be covered by the protocol. The protocol can >>accommodate either mode - it really is up to the server to deal with >>this. I would suspect that (1) is more likely. Perhaps the most typically >>implementation may be to send requests to clients and then wait for >>the clients to respond (or timeout) and as they do, send additional >>requests. This avoids flooding the network with packets and also staggers >>client responses some. Approach (2) is likely not very good as it would, >>as you point out, take a very long time if there are a lot of clients. >> >>I don't believe there is any need for the transaction id to be the same >>for all clients (retransmitted requests to a particular client should use >>the same id). Note though that there is little reason why the server >>would necessarily need a new transaction id for each client - it could >>use the same for all clients if it wanted to. Again, I think this is an >>implementation issue. >> >>- Bernie Volz >> >>-----Original Message----- >>From: skodati@in.ibm.com >>[mailto:skodati@in.ibm.com] >>Sent: Thursday, May 31, 2001 2:12 AM >>To: DHCPv6 discussion list >>Cc: bsuparna@in.ibm.com; rsharada@in.ibm.com >>Subject: RE: Reconfigure-init message in DHCPv6 >> >> >> >>Per discussions during a design team meeting and at the March IETF, we >> >>hope to punt on the multicast reconfigure-init support for now. >> > >> >Yes, Reconfigure-init will *not* have multicast as an option in the next >> >DHCP spec draft. >> > >> > >> >- Ralph >> >>I have doubt on how does a server send RECONFIG message If it tries to >>reconfigure a network. Does it send >> 1) RECONFIG to all the clients once, and waits for REQUEST from >>clients. >> (Or) >> 2) it sends RECONFIG messages one by one to all clients and ensures >>that all clients gets reconfigured. In that case the server should wait for >>RECCREP_MSG_TIMEOUT ( default 2000 ms) for REC_MSG_ATTEMPTS ( default 10) >>times, which means it has to wait for 20 seconds for a node, and it may >>take too long to configure whole network. >> >>Is the transaction id is going to be same for all messages or different in >>both the cases..... >> >>suresh. ------_=_NextPart_001_01C0E9E8.2E3B8130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Reconfigure-init message in DHCPv6

Ralph:

Why not require that a new transaction id is used for = subsequent reconfigure-inits? The reason is that this would solve the = last problem - if a retransmitted or duplicated reconfigure-init is = received by the client after the Request/Reply exchange has occurred. = The only additional issue with this is that the server does need to = generate unique transaction-ids, otherwise it is possible that a = transaction id is duplicated if a server restarts. However, this is = fairly easy to solve at the client by simply adding a time check - ie, = if the transaction id of a reconfigure-init is the same as the last = reconfigure-init from that server and was received within <n> = seconds of the Reply to the Request, treat this as a duplicate; = otherwise it is a new request.

I guess if you wanted to go with your proposal, then = the transaction id in the reconfigure-init is really a don't care field = (at least to the client) and it can ignore it completely. So, perhaps = to make this clear it would be good to have the server not supply one = or document that it is useless.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, May 31, 2001 10:08 AM
To: DHCPv6 discussion list
Subject: RE: Reconfigure-init message in = DHCPv6


Oops, sorry.  I responded without thinking all = the way through Thomas'
suggested mechanism for Reconfigure-init - in fact, = I think it actually
does solve the transaction ID problem...

As I understand it, the Reconfigure-init message acts = as a trigger that
signals the client to complete a successful = Request/Reply message
exchange.  Once the client has received a = Recongfigure-init, the client
proceeds with the Request/Reply message exchange = (retransmitting the
Request if necessary); the client ignores any = additional Reconfigure-init
messages (regardless of the transaction ID in the = Reconfigure-init message)
until the Request/Reply exchange is complete.  = Subsequent Reconfigure-init
messages (again independent of the transaction ID) = cause the client to
initiate a new Request/Reply exchange.

OK, so how does this mechanism work in the face of = duplicated or
retransmitted Reconfigure-init messages?  = Duplicate messages will be
ignored because the client will begin the = Request/Reply exchange after the
receipt of the first Reconfigure-init.  = Retransmitted messages will either
trigger the Request/Reply exchange (if the first = Reconfigure-init was not
received by the client) or will be ignored.  = The server can discontinue
retransmission of Reconfigure-init messages to the = client once the server
receives the client's Request.

It might be possible for a duplicate or retransmitted = Reconfigure-init to
be sufficiently delayed (and delivered out of order) = to arrive at the
client after the Request/Reply exchange (initiated = by the original
Reconfigure-init) has been completed.  In this = case, the client would
initiate a redundant Request/Reply exchange.  I = think (although I could be
convinced otherwise) that the likelihood of delayed = and out of order
delivery is small enough to be ignored.  Also, = the consequence of the
redundant exchange is inefficiency rather than = incorrect operation.

I'll write up this new mechanism in the next draft of = the spec.

- Ralph


At 06:21 AM 5/31/2001 -0400, Ralph Droms = wrote:
>I agree with Bernie that the mechanisms for = sending Reconfigure-init to
>multiple clients is an implementation issue and = shouldn't be specified in
>the spec.
>
>The next draft will use a slightly different = strategy for the transaction
>ID.  As suggested by Thomas Narten, the = transaction ID in the client's
>Request message can be independent of the = transaction ID in the
>Reconfigure-init message.
>
>However, we still have an issue with the = transaction ID in retransmitted
>Reconfigure-init messages.  If the server = uses the same transaction ID in
>a retransmitted message, how does the client = differentiate retransmission
>from duplicate messages?
>
>- Ralph
>
>At 04:40 AM 5/31/2001 -0500, Bernie Volz (EUD) = wrote:
>
>>I would think that how a server deals with = this is an implementation
>>issue and should not be covered by the = protocol. The protocol can
>>accommodate either mode - it really is up to = the server to deal with
>>this. I would suspect that (1) is more = likely. Perhaps the most typically
>>implementation may be to send requests to = <N> clients and then wait for
>>the clients to respond (or timeout) and as = they do, send additional
>>requests. This avoids flooding the network = with packets and also staggers
>>client responses some. Approach (2) is = likely not very good as it would,
>>as you point out, take a very long time if = there are a lot of clients.
>>
>>I don't believe there is any need for the = transaction id to be the same
>>for all clients (retransmitted requests to a = particular client should use
>>the same id). Note though that there is = little reason why the server
>>would necessarily need a new transaction id = for each client - it could
>>use the same for all clients if it wanted = to. Again, I think this is an
>>implementation issue.
>>
>>- Bernie Volz
>>
>>-----Original Message-----
>>From: skodati@in.ibm.com
>>[<mailto:skodati@in.ibm.com>mailto:skodati@in.ibm.com]=
>>Sent: Thursday, May 31, 2001 2:12 AM
>>To: DHCPv6 discussion list
>>Cc: bsuparna@in.ibm.com; = rsharada@in.ibm.com
>>Subject: RE: Reconfigure-init message in = DHCPv6
>>
>>
>> >>Per discussions during a design = team meeting and at the March IETF, we
>> >>hope to punt on the multicast = reconfigure-init support for now.
>> >
>> >Yes, Reconfigure-init will *not* have = multicast as an option in the next
>> >DHCP spec draft.
>> >
>> >
>> >- Ralph
>>
>>I have doubt on how does a server send = RECONFIG message If it tries to
>>reconfigure a network. Does it send
>>      1) RECONFIG = to all the clients once, and waits for REQUEST from
>>clients.
>>      (Or)
>>      2)  it = sends RECONFIG messages one by one to all clients and ensures
>>that all clients gets reconfigured. In that = case the server should wait for
>>RECCREP_MSG_TIMEOUT ( default 2000 ms) for = REC_MSG_ATTEMPTS ( default 10)
>>times, which means it has to wait for 20 = seconds for a node, and it may
>>take too long to configure whole = network.
>>
>>Is the transaction id is going to be same = for all messages or different in
>>both the cases.....
>>
>>suresh.

------_=_NextPart_001_01C0E9E8.2E3B8130-- From owner-dhcp-v6@bucknell.edu Thu May 31 12:25:09 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00868; Thu, 31 May 2001 12:25:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4VGOpJ06707; Thu, 31 May 2001 12:24:51 -0400 (EDT) Received: from dns.dhcp.org (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4VGOkJ07851 for ; Thu, 31 May 2001 12:24:46 -0400 (EDT) Date: Thu, 31 May 2001 12:24:13 -0400 (EDT) From: "Ralph E. Droms" X-Sender: droms@leo To: DHCPv6 discussion list Subject: RE: Reconfigure-init message in DHCPv6 In-Reply-To: <66F66129A77AD411B76200508B65AC694CBBBC@eambunt705.ena-east.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN On Thu, 31 May 2001, Bernie Volz (EUD) wrote: > Why not require that a new transaction id is used for subsequent > reconfigure-inits? The reason is that this would solve the last problem > - if a retransmitted or duplicated reconfigure-init is received by the > client after the Request/Reply exchange has occurred. The only > additional issue with this is that the server does need to generate > unique transaction-ids, otherwise it is possible that a transaction id > is duplicated if a server restarts. Another issue is that the client will need to remember previous transaction IDs for some period of time. > However, this is fairly easy to > solve at the client by simply adding a time check - ie, if the > transaction id of a reconfigure-init is the same as the last > reconfigure-init from that server and was received within seconds of > the Reply to the Request, treat this as a duplicate; otherwise it is a > new request. How is this, then, different from my proposal? > I guess if you wanted to go with your proposal, then the transaction id > in the reconfigure-init is really a don't care field (at least to the > client) and it can ignore it completely. So, perhaps to make this clear > it would be good to have the server not supply one or document that it > is useless. Yeah, I agree... - Ralph From owner-dhcp-v6@bucknell.edu Thu May 31 12:35:02 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01182; Thu, 31 May 2001 12:35:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4VGYsJ32099; Thu, 31 May 2001 12:34:54 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4VGYeJ11575 for ; Thu, 31 May 2001 12:34:40 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f4VGYda15527 for ; Thu, 31 May 2001 11:34:39 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f4VGYdC19628 for ; Thu, 31 May 2001 11:34:39 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu May 31 11:34:38 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 11:34:39 -0500 Message-ID: <66F66129A77AD411B76200508B65AC694CBBC2@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Reconfigure-init message in DHCPv6 Date: Thu, 31 May 2001 11:34:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E9EF.9576F2B0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0E9EF.9576F2B0 Content-Type: text/plain; charset="iso-8859-1" Ralph: >How is this, then, different from my proposal? I don't recall your detailed proposal, so perhaps it is the same? I thought that this was a bit different since it basically incorporates Thomas's proposal for dealing with normal retransmissions (or new reconfigure-inits) in that *ALL* of these are ignored until the client completes the reconfiguration process. The transaction id/time check is ONLY done on reconfigure-inits received AFTER the client has completed the reconfiguration process. --- I have no major issue if we just say that the transaction id in the reconfigure-init is useless and should be ignored by the client (and the server may supply any value it desires). I think this means that the server never needs to generate transaction ids that have any meaning and that might simplify their implementation. - Bernie -----Original Message----- From: Ralph E. Droms [mailto:droms@bucknell.edu] Sent: Thursday, May 31, 2001 12:24 PM To: DHCPv6 discussion list Subject: RE: Reconfigure-init message in DHCPv6 On Thu, 31 May 2001, Bernie Volz (EUD) wrote: > Why not require that a new transaction id is used for subsequent > reconfigure-inits? The reason is that this would solve the last problem > - if a retransmitted or duplicated reconfigure-init is received by the > client after the Request/Reply exchange has occurred. The only > additional issue with this is that the server does need to generate > unique transaction-ids, otherwise it is possible that a transaction id > is duplicated if a server restarts. Another issue is that the client will need to remember previous transaction IDs for some period of time. > However, this is fairly easy to > solve at the client by simply adding a time check - ie, if the > transaction id of a reconfigure-init is the same as the last > reconfigure-init from that server and was received within seconds of > the Reply to the Request, treat this as a duplicate; otherwise it is a > new request. How is this, then, different from my proposal? > I guess if you wanted to go with your proposal, then the transaction id > in the reconfigure-init is really a don't care field (at least to the > client) and it can ignore it completely. So, perhaps to make this clear > it would be good to have the server not supply one or document that it > is useless. Yeah, I agree... - Ralph ------_=_NextPart_001_01C0E9EF.9576F2B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Reconfigure-init message in DHCPv6

Ralph:

>How is this, then, different from my = proposal?

I don't recall your detailed proposal, so perhaps it = is the same? I thought that this was a bit different since it basically = incorporates Thomas's proposal for dealing with normal retransmissions = (or new reconfigure-inits) in that *ALL* of these are ignored until the = client completes the reconfiguration process. The transaction id/time = check is ONLY done on reconfigure-inits received AFTER the client has = completed the reconfiguration process.

---

I have no major issue if we just say that the = transaction id in the reconfigure-init is useless and should be ignored = by the client (and the server may supply any value it desires). I think = this means that the server never needs to generate transaction ids that = have any meaning and that might simplify their = implementation.

- Bernie

-----Original Message-----
From: Ralph E. Droms [mailto:droms@bucknell.edu]=
Sent: Thursday, May 31, 2001 12:24 PM
To: DHCPv6 discussion list
Subject: RE: Reconfigure-init message in = DHCPv6




On Thu, 31 May 2001, Bernie Volz (EUD) wrote:
> Why not require that a new transaction id is = used for subsequent
> reconfigure-inits? The reason is that this = would solve the last problem
> - if a retransmitted or duplicated = reconfigure-init is received by the
> client after the Request/Reply exchange has = occurred. The only
> additional issue with this is that the server = does need to generate
> unique transaction-ids, otherwise it is = possible that a transaction id
> is duplicated if a server restarts.

Another issue is that the client will need to = remember previous
transaction IDs for some period of time.

> However, this is fairly easy to
> solve at the client by simply adding a time = check - ie, if the
> transaction id of a reconfigure-init is the = same as the last
> reconfigure-init from that server and was = received within <n> seconds of
> the Reply to the Request, treat this as a = duplicate; otherwise it is a
> new = request.         

How is this, then, different from my proposal?

> I guess if you wanted to go with your proposal, = then the transaction id
> in the reconfigure-init is really a don't care = field (at least to the
> client) and it can ignore it completely. So, = perhaps to make this clear
> it would be good to have the server not supply = one or document that it
> is useless.

Yeah, I agree...

- Ralph

------_=_NextPart_001_01C0E9EF.9576F2B0-- From owner-dhcp-v6@bucknell.edu Thu May 31 17:10:46 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08167; Thu, 31 May 2001 17:10:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4VL9pJ31338; Thu, 31 May 2001 17:09:51 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4VL9dJ13757 for ; Thu, 31 May 2001 17:09:39 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-120.cisco.com [161.44.149.120]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA17537 for ; Thu, 31 May 2001 17:09:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20010531170657.00bbcd28@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 May 2001 17:07:55 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Spec text for Reconfigure-init Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here's some proposed text describing the use of the Reconfigure-init message. I've extracted this text from the draft spec, so watch the section numbers to be warned of elided text. - Ralph 7. DHCP Constants This section describes various program and networking constants used by DHCP. 7.5. Configuration Variables This section presents a table of client and server configuration variables and the default or initial values for these variables. The client-specific variables MAY be configured on the server and MAY be delivered to the client through the "DHCP Retransmission Parameter Option" in a Reply message. _________________________________________________________________________ |Parameter__________|Default|_Description______________________________|_ |MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_ |MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_ |ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_ |ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_ |SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_ |REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_ |QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_ |REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_ |RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_ |REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_ |REC_THRESHOLD______|100____|_%_of_required_clients____________________|_ |SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_ 9. Message Formats Each DHCP message has an identical fixed format header; some messages also allow a variable format area for options. Not all fields in the header are used in every message. In this section, every field is described for every message and fields that are not used in a message are marked as "unused". All unused fields in a message MUST be transmitted as zeroes and ignored by the receiver of the message. The DHCP message header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | preference | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | client-link-local-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . options . | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9.10. DHCP Reconfigure-init Message Format msg-type RECONF-INIT preference (unused) MUST be 0 transaction-ID An unsigned integer generated by the server to identify this Reconfigure-init message client-link-local-address (unused) MUST be 0 server-address The IP address of the DHCP server issuing the Reconfigure-init message. MUST be of sufficient scope to be reachable by all clients. options See section 17. 14. DHCP Server-Initiated Configuration Exchange A server initiates a configuration exchange to force DHCP clients to obtain new addresses and other configuration information. For example, an administrator may use a server-initiated configuration exchange when links in the DHCP domain are to be renumbered. Other examples include changes in the location of directory servers, addition of new services such as printing, and availability of new software (system or application). 14.1. Reconfigure-init Message Validation Agents MUST silently discard any received Reconfigure-init messages. Clients MUST discard any Reconfigure-init messages that do not contain an authentication option or that fail the client's authentication check. 14.2. Server Behavior A server sends a Reconfigure-init message to cause a client to initiate immediately a Request/Reply message exchange with the server. 14.2.1. Creation and sending of Reconfigure-init messages The server sets the "msg-type" field to RECONFIG-INIT. The server generates a transaction-ID and inserts it in the "transaction-ID" field. The server places its address (of appropriate scope) in the "server-address" field. The server MAY include an ORO option to inform the client of what information has been changed or new information that has been added. The server MUST include an authentication option with the appropriate settings and add that option as the last option in the "options" field of the Reconfigure-init message. The server MUST NOT include any other options in the Reconfigure-init except as specifically allowed in the definition of individual options. The server unicasts the Reconfigure-init message to one client. The server may unicast Reconfigure-init messages to more than one client concurrently; for example, to reliably reconfigure all known clients, the server will unicast a Reconfigure-init message to each client. After the server sends the Reconfigure-init message, it waits for a Request message from those clients confirming that each client has received the Reconfigure-init and are thus initiating a Request/Reply transaction with the server. 14.2.2. Time out and retransmission of Reconfigure-init messages If the server does not receive a Request message from the client in RECREP_MSG_TIMEOUT milliseconds, the server retransmits the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT value and waits again. The server continues this process until REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point the server SHOULD abort the reconfigure process. Default and initial values for RECREP_MSG_TIMEOUT and REC_MSG_ATTEMPTS are documented in section 7.5. 14.2.3. Receipt of Request messages The server generates and sends Reply message(s) to the client as described in section 13.4.6, including in the "option" field new values for configuration parameters. 14.3. Client Behavior A client MUST always monitor UDP port 546 for Reconfigure-init messages on interfaces upon which it has acquired DHCP parameters. Since the results of a reconfiguration event may affect application layer programs, the client SHOULD log these events, and MAY notify these programs of the change through an implementation-specific interface. 14.3.1. Receipt of Reconfigure-init messages Upon receipt of a valid Reconfigure-init message, the client initiates a Request/Reply transaction with the server. While the Request/Reply transaction is in progress, the client silently discards any Reconfigure-init messages it receives. DISCUSSION: The Reconfigure-init message acts as a trigger that signals the client to complete a successful Request/Reply message exchange. Once the client has received a Recongfigure-init, the client proceeds with the Request/Reply message exchange (retransmitting the Request if necessary); the client ignores any additional Reconfigure-init messages (regardless of the transaction ID in the Reconfigure-init message) until the Request/Reply exchange is complete. Subsequent Reconfigure-init messages (again independent of the transaction ID) cause the client to initiate a new Request/Reply exchange. How does this mechanism work in the face of duplicated or retransmitted Reconfigure-init messages? Duplicate messages will be ignored because the client will begin the Request/Reply exchange after the receipt of the first Reconfigure-init. Retransmitted messages will either trigger the Request/Reply exchange (if the first Reconfigure-init was not received by the client) or will be ignored. The server can discontinue retransmission of Reconfigure-init messages to the client once the server receives the client's Request. It might be possible for a duplicate or retransmitted Reconfigure-init to be sufficiently delayed (and delivered out of order) to arrive at the client after the Request/Reply exchange (initiated by the original Reconfigure-init) has been completed. In this case, the client would initiate a redundant Request/Reply exchange. The likelihood of delayed and out of order delivery is small enough to be ignored. The consequence of the redundant exchange is inefficiency rather than incorrect operation. 14.3.2. Creation and sending of Request messages When responding to a Reconfigure-init, the client creates and sends the Request message in exactly the same manner as outlined in section 13.3.1 with the following difference: IAs The client includes IA options containing the addresses the client currently has assigned to those IAs for the interface through which the Reconfigure-init message was received. 14.3.3. Time out and retransmission of Request messages The client uses the same variables and retransmission algorithm as it does with Request messages generated as part of a client-initiated configuration exchange. See section 13.3.1 for details. 14.3.4. Receipt of Reply messages Upon the receipt of a valid Reply message, the client extracts the contents of the "options" field, and sets (or resets) configuration parameters appropriately. The client records and updates the lifetimes for any addresses specified in IAs in the Reply message. If the configuration parameters changed were requested by the application layer, the client notifies the application layer of the changes using an implementation-specific interface. 17. DHCP options Options are used to carry additional information and parameters in DHCP messages. Every option shares a common base format, as described in section 17.1. This document describes the DHCP options defined as part of the base DHCP specification. Other options may be defined in the future in a separate document. 17.1. Format of DHCP options 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | (option-len octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code An unsigned integer identifying the specific option type carried in this option. option-len An unsigned integer giving the length of the data in this option in octets. option-data The data for the option; the format of this data depends on the definition of the option. 17.3. Option request option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ORO | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | requested-option-code-1 | requested-option-code-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_ORO (2) option-len Variable; equal to twice the number of option codes carried in this option. option-data A list of the option codes for the options requested in this option. From owner-dhcp-v6@bucknell.edu Thu May 31 19:25:32 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10020; Thu, 31 May 2001 19:25:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4VNNKJ26765; Thu, 31 May 2001 19:23:20 -0400 (EDT) Received: from hygro.adsl.duke.edu ([131.107.37.43]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4VNN8J32057 for ; Thu, 31 May 2001 19:23:08 -0400 (EDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f4VNLJC00966; Thu, 31 May 2001 19:21:19 -0400 Message-Id: <200105312321.f4VNLJC00966@hygro.adsl.duke.edu> To: DHCPv6 discussion list cc: bsuparna@in.ibm.com, rsharada@in.ibm.com Subject: Re: Reconfigure-init message in DHCPv6 In-Reply-To: Message from Ralph Droms of "Thu, 31 May 2001 06:21:44 EDT." <4.3.2.7.2.20010531061506.00ba1728@mail.bucknell.edu> Date: Thu, 31 May 2001 19:21:19 -0400 From: Thomas Narten Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The next draft will use a slightly different strategy for the transaction > ID. As suggested by Thomas Narten, the transaction ID in the client's > Request message can be independent of the transaction ID in the > Reconfigure-init message. > However, we still have an issue with the transaction ID in retransmitted > Reconfigure-init messages. If the server uses the same transaction ID in a > retransmitted message, how does the client differentiate retransmission > from duplicate messages? Does it need to? If the client is in the process of contacting the server when the retrasmission comes in, it knows it's a retransmission (i.e., that is presumably why it is trying to contact the server) and it just ignores the retransmission. The other case is where the client responds to the server's Reconfigure-Init does a transaction (that completes) and *then* a retransmission arrives essentially saying "contact me again". I few observations: 1) this is somewhat pathological situation. Either the server is broken (it's retransmitting even after its original request has been "acknowledged" via the client contacting it and getting the new options) or the network is delaying some packets for a real long time. 2) if the client contacts the server again, nothing breaks, though there is a performance penalty. The client just gets the same info over again. 3) if this was a real concern, the client can retain state (even after contacting the server) that keeps track of the last transaction ID, in which case it would recognize the retransmission and ignore it. Or do I misunderstand the concern? Thomas From owner-dhcp-v6@bucknell.edu Thu May 31 21:32:05 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11433; Thu, 31 May 2001 21:32:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f511TWJ27270; Thu, 31 May 2001 21:29:32 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f511TOJ23071 for ; Thu, 31 May 2001 21:29:24 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn-352.cisco.com [10.21.65.96]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA04494; Thu, 31 May 2001 21:29:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20010531212618.00b679c0@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 May 2001 21:28:18 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: Reconfigure-init message in DHCPv6 Cc: DHCPv6 discussion list , bsuparna@in.ibm.com, rsharada@in.ibm.com In-Reply-To: <200105312321.f4VNLJC00966@hygro.adsl.duke.edu> References: <4.3.2.7.2.20010531061506.00ba1728@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thomas - you're right, the client doesn't need to consider the transaction ID. I think I got the argument right in my followup note (that crossed in flight with your e-mail). Please see if you agree with the DISCUSSION section in the text snippet I posted. - Ralph At 07:21 PM 5/31/2001 -0400, Thomas Narten wrote: > > However, we still have an issue with the transaction ID in retransmitted > > Reconfigure-init messages. If the server uses the same transaction ID > in a > > retransmitted message, how does the client differentiate retransmission > > from duplicate messages? > >Does it need to?