From owner-dhcp-v4@bucknell.edu  Wed May  2 07:28:48 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05887
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 2 May 2001 07:28:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f42BLGe19851;
	Wed, 2 May 2001 07:21:16 -0400 (EDT)
Received: from fsnt.future.futsoft.com ([203.197.140.35])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f42BL6e18759
	for <dhcp-v4@bucknell.edu>; Wed, 2 May 2001 07:21:06 -0400 (EDT)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0000038618@fsnt.future.futsoft.com> for <dhcp-v4@bucknell.edu>;
 Wed, 02 May 2001 16:56:48 +0530
Received: from radhard (radhard.future.futsoft.com [10.6.2.24])
	by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f42BKjw05617
	for <dhcp-v4@bucknell.edu>; Wed, 2 May 2001 16:50:46 +0530
Received: by localhost with Microsoft MAPI; Wed, 2 May 2001 16:44:41 +0530
Message-Id: <01C0D327.2F095560.radhard@future.futsoft.com>
From: Radha Rani <radhard@future.futsoft.com>
Reply-To: "radhard@future.futsoft.com" <radhard@future.futsoft.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Questions regarding the DHCP Relay Agent Information Option
Date: Wed, 2 May 2001 16:44:38 +0530
Organization: Future Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Hi,
* Does the ISC DHCP Relay Agent code support the DHCP Relay Agent Information 
Option?
* If it supports then How to configure it? How to enable it?
* Can we configure Relay Agent Information Option per interface basic?

Thanks and Regards,
Radha



From owner-dhcp-v4@bucknell.edu  Wed May  2 21:19:27 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27898
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 2 May 2001 21:19:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f431DYe29582;
	Wed, 2 May 2001 21:13:34 -0400 (EDT)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f431DJe25610
	for <dhcp-v4@bucknell.edu>; Wed, 2 May 2001 21:13:19 -0400 (EDT)
Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19)
	id <JHZ8AWVN>; Wed, 2 May 2001 18:13:22 -0700
Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JHZ8AW48; Wed, 2 May 2001 18:02:43 -0700
From: "Scott G. Kelly" <skelly@redcreek.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: ietf-ipsra@vpnc.org, dhcp-v4@bucknell.edu,
        Marcus Leech
	 <mleech@nortelnetworks.com>
Message-ID: <3AF0ADBD.541ED3C5@redcreek.com>
Date: Wed, 02 May 2001 18:00:45 -0700
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: draft-ietf-ipsec-dhcp-09.txt
References: <200104241831.OAA09411@rotala.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: skelly@redcreek.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Thomas Narten wrote:
<trimmed...>

> > 6.2.  DHCPOFFER message processing
> >
> > Typically, the security gateway will also store the xid and the chaddr
> > gleaned from the DHCPDISCOVER in a table so as to be able to route the
> > corresponding DHCPOFFER message(s) back to the remote host.
> 
> This would appear to be a fundamental change in relay agent model
> compared to standard DHCP. That is, traditional relay agents are
> stateless. All the info that a relay agent needs in order to relay
> DHCP packets is contained in those packets. No per-client state is
> needed.  The above text suggests that the relay agent caches the
> chaddr field in order to be able to route back DHCP responses. Why is
> this needed? Isn't this info in the packet that needs to be relayed?
> 
> The answer appears to be no, as the chaddr field as defined in this
> document isn't sufficiently useful for this.
> 
> Wouldn't it be better to (say) have the relay agent add a relay agent
> option that includes information about the SA over which the packet
> was received? When the server responds, that relay agent option could
> contain the information needed properly forward the packet. This would
> be consistent with existing DHCP specifications and would eliminate
> the need for the relay agent to maintain per-client state.

The text in the latest rev (11) has been modified to suggest using the
relay option, but I wonder if this doesn't raise backward compatibility
issues. A large number of deployed dhcp servers do not support the relay
agent option, and in these cases, per-client state must be maintained. I
wonder if we shouldn't have some language to this effect. Does anyone
disagree?

Scott



From owner-dhcp-v4@bucknell.edu  Thu May  3 06:30:50 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18201
	for <DHC-ARCHIVE@odin.IETF.ORG>; Thu, 3 May 2001 06:30:50 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f43AHpe14106;
	Thu, 3 May 2001 06:17:51 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:root@cichlid.adsl.duke.edu [152.16.64.203])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f43AHhe32714
	for <dhcp-v4@bucknell.edu>; Thu, 3 May 2001 06:17:43 -0400 (EDT)
Received: from hygro.adsl.duke.edu (narten@localhost)
	by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f43AGu402673;
	Thu, 3 May 2001 06:16:57 -0400
Message-Id: <200105031016.f43AGu402673@hygro.adsl.duke.edu>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: ietf-ipsra@vpnc.org, dhcp-v4@bucknell.edu,
        Marcus Leech <mleech@nortelnetworks.com>
Subject: Re: draft-ietf-ipsec-dhcp-09.txt 
In-Reply-To: Message from "Scott G. Kelly" <skelly@redcreek.com> 
   of "Wed, 02 May 2001 18:00:45 PDT." <3AF0ADBD.541ED3C5@redcreek.com> 
Date: Thu, 03 May 2001 06:16:56 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Reply-To: narten@raleigh.ibm.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> The text in the latest rev (11) has been modified to suggest using the
> relay option, but I wonder if this doesn't raise backward compatibility
> issues. A large number of deployed dhcp servers do not support the relay
> agent option, and in these cases, per-client state must be maintained. I
> wonder if we shouldn't have some language to this effect. Does anyone
> disagree?

I would spin the backwards compatability issue differently. In both
cases, it would seem that new code needs to be written, since neither
approach is presumably widely deployed today. Do we recommend that
implementors implement an existing standard that *is* being
implemented in deployed in some environments because it meets a need
(i.e., the reason the relay agent option was defined in the first
place) or do we recommend a different and non-standard way? The choice
seems obvious to me.

Thomas



From owner-dhcp-v4@bucknell.edu  Thu May  3 12:11:59 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28688
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 3 May 2001 12:11:59 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f43G5Me08877;
	Thu, 3 May 2001 12:05:22 -0400 (EDT)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f43G57e25729
	for <dhcp-v4@bucknell.edu>; Thu, 3 May 2001 12:05:08 -0400 (EDT)
Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19)
	id <JHZ8AXQH>; Thu, 3 May 2001 09:05:07 -0700
Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JHZ8AXPX; Thu, 3 May 2001 08:55:51 -0700
From: "Scott G. Kelly" <skelly@redcreek.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: ietf-ipsra@vpnc.org, dhcp-v4@bucknell.edu,
        Marcus Leech
	 <mleech@nortelnetworks.com>
Message-ID: <3AF17F0F.3F9AB4A6@redcreek.com>
Date: Thu, 03 May 2001 08:53:51 -0700
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: draft-ietf-ipsec-dhcp-09.txt
References: <200105031016.f43AGu402673@hygro.adsl.duke.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: skelly@redcreek.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Hi Thomas,

Thomas Narten wrote:
> 
> > The text in the latest rev (11) has been modified to suggest using the
> > relay option, but I wonder if this doesn't raise backward compatibility
> > issues. A large number of deployed dhcp servers do not support the relay
> > agent option, and in these cases, per-client state must be maintained. I
> > wonder if we shouldn't have some language to this effect. Does anyone
> > disagree?
> 
> I would spin the backwards compatability issue differently. In both
> cases, it would seem that new code needs to be written, since neither
> approach is presumably widely deployed today. Do we recommend that
> implementors implement an existing standard that *is* being
> implemented in deployed in some environments because it meets a need
> (i.e., the reason the relay agent option was defined in the first
> place) or do we recommend a different and non-standard way? The choice
> seems obvious to me.

I think I understand your position, and I agree from a philosophical
standpoint. I have always thought the relay agent option was the best
way to implement this. However, from a practical standpoint, we could
not have deployed the units we have out there which use DHCP (in the
thousands, I think) if we had relied upon the relay agent option. I am
not advocating that we suggest an alternative method which may be used
even if the relay option is available; I am suggesting adding text (an
implementation note?) explaining that if the relay agent option is not
supported, that state must be maintained in order for this to work. This
might help to avoid implementer confusion.

I don't feel strongly about this, but thought (based on years of
implementing protocols based upon RFC's) that some clarifying language
might be useful.

Scott



From owner-dhcp-v4@bucknell.edu  Fri May  4 11:28:35 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14342
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 4 May 2001 11:28:34 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f44FKde08603;
	Fri, 4 May 2001 11:20:41 -0400 (EDT)
Received: from internaut.com ([64.38.134.99])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f44FKGe02023
	for <dhcp-v4@bucknell.edu>; Fri, 4 May 2001 11:20:17 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id IAA02817;
	Fri, 4 May 2001 08:12:11 -0700 (PDT)
	(envelope-from aboba@internaut.com)
Date: Fri, 4 May 2001 08:12:11 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: Thomas Narten <narten@raleigh.ibm.com>, ietf-ipsra@vpnc.org,
        dhcp-v4@bucknell.edu, Marcus Leech <mleech@nortelnetworks.com>
Subject: Re: draft-ietf-ipsec-dhcp-09.txt
In-Reply-To: <3AF17F0F.3F9AB4A6@redcreek.com>
Message-ID: <Pine.BSF.4.21.0105040811230.2721-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: aboba@internaut.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Is there some text that someone would like to add to the
draft to address this issue?

On Thu, 3 May 2001, Scott G. Kelly wrote:

> Hi Thomas,
> 
> Thomas Narten wrote:
> > 
> > > The text in the latest rev (11) has been modified to suggest using the
> > > relay option, but I wonder if this doesn't raise backward compatibility
> > > issues. A large number of deployed dhcp servers do not support the relay
> > > agent option, and in these cases, per-client state must be maintained. I
> > > wonder if we shouldn't have some language to this effect. Does anyone
> > > disagree?
> > 
> > I would spin the backwards compatability issue differently. In both
> > cases, it would seem that new code needs to be written, since neither
> > approach is presumably widely deployed today. Do we recommend that
> > implementors implement an existing standard that *is* being
> > implemented in deployed in some environments because it meets a need
> > (i.e., the reason the relay agent option was defined in the first
> > place) or do we recommend a different and non-standard way? The choice
> > seems obvious to me.
> 
> I think I understand your position, and I agree from a philosophical
> standpoint. I have always thought the relay agent option was the best
> way to implement this. However, from a practical standpoint, we could
> not have deployed the units we have out there which use DHCP (in the
> thousands, I think) if we had relied upon the relay agent option. I am
> not advocating that we suggest an alternative method which may be used
> even if the relay option is available; I am suggesting adding text (an
> implementation note?) explaining that if the relay agent option is not
> supported, that state must be maintained in order for this to work. This
> might help to avoid implementer confusion.
> 
> I don't feel strongly about this, but thought (based on years of
> implementing protocols based upon RFC's) that some clarifying language
> might be useful.
> 
> Scott
> 



From owner-dhcp-v4@bucknell.edu  Fri May  4 21:37:26 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24415
	for <DHC-ARCHIVE@odin.IETF.ORG>; Fri, 4 May 2001 21:37:25 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f451W0e31643;
	Fri, 4 May 2001 21:32:00 -0400 (EDT)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f451Vse30308
	for <dhcp-v4@bucknell.edu>; Fri, 4 May 2001 21:31:55 -0400 (EDT)
Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19)
	id <JHZ8A886>; Fri, 4 May 2001 18:31:49 -0700
Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JHZ8A885; Fri, 4 May 2001 18:31:46 -0700
From: "Scott G. Kelly" <skelly@redcreek.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: Thomas Narten <narten@raleigh.ibm.com>, ietf-ipsra@vpnc.org,
        dhcp-v4@bucknell.edu, Marcus Leech <mleech@nortelnetworks.com>
Message-ID: <3AF35784.DF61B04D@redcreek.com>
Date: Fri, 04 May 2001 18:29:40 -0700
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: draft-ietf-ipsec-dhcp-09.txt
References: <Pine.BSF.4.21.0105040811230.2721-100000@internaut.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: skelly@redcreek.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Here's the current text:

----------------------------
Since DHCP Relays are stateless, it is necessary for the security
gateway to insert appropriate information in the DHCP Relay Agent
Information Option [17] prior to forwarding the message to one or more
DHCP servers. This enables the security gateway to route the
corresponding DHCPOFFER message(s) back to the remote host on the
correct IPSec tunnel, without having to keep state gleaned from the
DISCOVER, such as a table of the xid, chaddr and tunnel. This is
accomplished by identification of the virtual port number of the tunnel
via the Agent Circuit ID Sub-option (sub-option code 1) of the DHCP
Relay Agent Information Option, as described in [17].
-----------------------------

How about adding this:

If attempting to interoperate with a legacy DHCP server which does not
support the required options, stateless relay agent behavior will not be
possible. In such cases, implementations may devise a mapping between
the xid, chaddr, and tunnel in order to route the DHCP server response
to the appropriate tunnel endpoint.


--Scott


Bernard Aboba wrote:
> 
> Is there some text that someone would like to add to the
> draft to address this issue?
> 
> On Thu, 3 May 2001, Scott G. Kelly wrote:
> 
> > Hi Thomas,
> >
> > Thomas Narten wrote:
> > >
> > > > The text in the latest rev (11) has been modified to suggest using the
> > > > relay option, but I wonder if this doesn't raise backward compatibility
> > > > issues. A large number of deployed dhcp servers do not support the relay
> > > > agent option, and in these cases, per-client state must be maintained. I
> > > > wonder if we shouldn't have some language to this effect. Does anyone
> > > > disagree?
> > >
> > > I would spin the backwards compatability issue differently. In both
> > > cases, it would seem that new code needs to be written, since neither
> > > approach is presumably widely deployed today. Do we recommend that
> > > implementors implement an existing standard that *is* being
> > > implemented in deployed in some environments because it meets a need
> > > (i.e., the reason the relay agent option was defined in the first
> > > place) or do we recommend a different and non-standard way? The choice
> > > seems obvious to me.
> >
> > I think I understand your position, and I agree from a philosophical
> > standpoint. I have always thought the relay agent option was the best
> > way to implement this. However, from a practical standpoint, we could
> > not have deployed the units we have out there which use DHCP (in the
> > thousands, I think) if we had relied upon the relay agent option. I am
> > not advocating that we suggest an alternative method which may be used
> > even if the relay option is available; I am suggesting adding text (an
> > implementation note?) explaining that if the relay agent option is not
> > supported, that state must be maintained in order for this to work. This
> > might help to avoid implementer confusion.
> >
> > I don't feel strongly about this, but thought (based on years of
> > implementing protocols based upon RFC's) that some clarifying language
> > might be useful.
> >
> > Scott
> >



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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <JQHXW17Z>; Mon, 7 May 2001 22:49:15 -0500
Message-ID: <66F66129A77AD411B76200508B65AC694CBAB8@eambunt705.ena-east.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>Reconfigure-Inits</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- Bernie Volz</FONT>
</P>

</BODY>
</HTML>
------_=_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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <JQ4AJS2D>; Mon, 7 May 2001 22:50:20 -0500
Message-ID: <66F66129A77AD411B76200508B65AC694CBAB9@eambunt705.ena-east.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>Status of -19 Draft??</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ralph, Jim, ...</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks in advance!</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- Bernie Volz</FONT>
</P>

</BODY>
</HTML>
------_=_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 <dhcp-v6@bucknell.edu>; 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 <seamus@bit-net.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Reconfigure-Inits
In-Reply-To: <66F66129A77AD411B76200508B65AC694CBAB8@eambunt705.ena-east.ericsson.se>
Message-Id: <Pine.OSF.3.95.1010508002820.2823A-100000@www.bit-net.com>
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-v4@bucknell.edu  Wed May  9 13:13:33 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17727
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 9 May 2001 13:13:29 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f49H64W02764;
	Wed, 9 May 2001 13:06:05 -0400 (EDT)
Received: from smtp-2.enteract.com (smtp-2.enteract.com [207.229.143.4])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f49H5vW15846
	for <dhcp-v4@bucknell.edu>; Wed, 9 May 2001 13:05:58 -0400 (EDT)
Received: from shell-1.enteract.com (shell-1.enteract.com [207.229.143.40])
	by smtp-2.enteract.com (Postfix) with ESMTP id E636D5F40
	for <dhcp-v4@bucknell.edu>; Wed,  9 May 2001 12:05:40 -0500 (CDT)
Date: Wed, 9 May 2001 12:05:40 -0500 (CDT)
From: RM <richardm@gowinnt.com>
X-X-Sender:  <richardm@shell-1.enteract.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Newbie Post - Assembly Line DHCP Problem
Message-ID: <Pine.BSF.4.33L2.0105091124020.94095-100000@shell-1.enteract.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: richardm@gowinnt.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


I should probably lurk for a bit before posting, but the situation has
become critical and we need a fix.  I hope someone here can help shed some
light on this issue.

I am trying to help a manufacturing company solve a DHCP problem on their
assembly line.  They have a large number of new PC's that connect to the
network using PXE implementation.  They then begin a software image
download process.

Our problem lies in the grace period that NT and 2000 server imposes on
expired DHCP leases.  The expiration time has been set to five minutes
(no, that's not a typo), which works exactly as planned.  The grace
period, however, prevents these expired leases from being immediately
returned to the pool of available addresses.  With NT4, it's about 24
hours (per Q153072).  The DatabaseCleanupInterval registry key can be set
to any number of minutes, but this seems to have little or no effect on
the grace period for expired leases.

With Win2000, it's a little bit different.  Q261964 documents the grace
period as being four hours - with a twist.  Quote: "any lease that falls
within the grace period (inactive) may be issued by the DHCP server if the
available leases fall to 0."

Well, it DOES work as described.  Sort of.  When the scope fills, the next
database cleanup will indeed delete the "expired but within grace period"
leases so that the addresses are once again available.  Trouble is, the
database cleanup only runs once per minute (the default is 1440 minutes
but we tweaked the aforementioned registry key).  This means that once a
scope fills, there will be a delay of up to 60 seconds before the cleanup
occurs and addresses are once again available.  In our high-speed
manufacturing environment, this is not tolerable.

Does anyone know of a way to totally eliminate the grace period with these
DHCP server products?

I see several possibilities here:

1. Live with it.

2. Redesign the network to use much larger subnets.  Right now, the
software download areas are in /24 subnets.  The scopes are 200 addresses
each.  We could go to /16 subnets and then potentially create huge scopes
that would never run out of addresses - grace period would be a non-issue.

3. Switch to a 3rd party DHCP product with configurable grace periods.
What product could we use?  I *might* be able to get a Sun workstation or
even a Linux/Intel box in here for DHCP services, but I'm not going to
hold my breath...

4. Get the clients to somehow do a DHCP release before they get boxed up
and sent out the door.  I don't know if these servers impose a grace
period on released leases (or only on expired leases), so this may not be
an option.

Thoughts?

RM














From owner-dhcp-v4@bucknell.edu  Wed May  9 14:36:47 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20749
	for <DHC-ARCHIVE@odin.IETF.ORG>; Wed, 9 May 2001 14:36:46 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f49ITQW30213;
	Wed, 9 May 2001 14:29:27 -0400 (EDT)
Received: from schools.hcde.org ([208.183.183.174])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f49ITKW26626
	for <dhcp-v4@bucknell.edu>; Wed, 9 May 2001 14:29:20 -0400 (EDT)
Received: by SCHOOLS with Internet Mail Service (5.5.2650.21)
	id <KPLH0PY7>; Wed, 9 May 2001 14:31:09 -0400
Message-ID: <B40E8C0DA10CA340BB939AA13AC527BF010226@SCHOOLS1.hcde.org>
From: Cramer Ron <Cramer_R@hcde.org>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Is there a way?
Date: Wed, 9 May 2001 14:26:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Cramer_R@hcde.org
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Is there a way to do a complete backup of a dhcp server? Let me explain a
little more. I have dhcp setup on a w2k server doing multiple scopes (82) to
all of my schools. Sometimes we have another network person that thinks the
server is causing network problems and they shut it off. I want to be able
to take a disk and put it on another machine and go with dhcp without having
to re type all the info. Is there a way to do this? Thanks



Ronnie Cramer
Network Engineer
Hamilton County Dept of Education
Chattanooga, Tennessee
(423) 209-5507



From owner-dhcp-v4@bucknell.edu  Wed May  9 18:01:33 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26706
	for <DHC-ARCHIVE@odin.IETF.ORG>; Wed, 9 May 2001 18:01:33 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f49Lt6W21960;
	Wed, 9 May 2001 17:55:06 -0400 (EDT)
Received: from firewall.ma.virata.com (agranat.com [198.113.147.2])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f49LspW10424
	for <dhcp-v4@bucknell.edu>; Wed, 9 May 2001 17:54:51 -0400 (EDT)
Received: from agranat.com (IDENT:root@alice.agranat.com [10.21.0.130])
	by firewall.ma.virata.com (8.9.0/8.9.0) with ESMTP id RAA31972
	for <dhcp-v4@bucknell.edu>; Wed, 9 May 2001 17:54:36 -0400
Received: from localhost.localdomain (IDENT:root@dhcp75.ma.virata.com [10.21.0.75])
	by agranat.com (8.9.3/8.9.3) with ESMTP id RAA07352
	for <dhcp-v4@bucknell.edu>; Wed, 9 May 2001 17:54:36 -0400
Received: (from worley@localhost)
	by localhost.localdomain (8.11.0/8.8.7) id f49Lsa301057;
	Wed, 9 May 2001 17:54:36 -0400
Date: Wed, 9 May 2001 17:54:36 -0400
Message-Id: <200105092154.f49Lsa301057@localhost.localdomain>
X-Authentication-Warning: localhost.localdomain: worley set sender to dworley@virata.com using -f
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
In-reply-to: <Pine.BSF.4.33L2.0105091124020.94095-100000@shell-1.enteract.com>
	(message from RM on Wed, 9 May 2001 12:05:40 -0500 (CDT))
Subject: Re: Newbie Post - Assembly Line DHCP Problem
References:  <Pine.BSF.4.33L2.0105091124020.94095-100000@shell-1.enteract.com>
From: worley@agranat.com
Reply-To: worley@agranat.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


   From: RM <richardm@gowinnt.com>

   Well, it DOES work as described.  Sort of.  When the scope fills, the next
   database cleanup will indeed delete the "expired but within grace period"
   leases so that the addresses are once again available.  Trouble is, the
   database cleanup only runs once per minute (the default is 1440 minutes
   but we tweaked the aforementioned registry key).  This means that once a
   scope fills, there will be a delay of up to 60 seconds before the cleanup
   occurs and addresses are once again available.  In our high-speed
   manufacturing environment, this is not tolerable.

I'm not familiar with the Windows implementations, but your situation
has a philosophical difference with the situations that DHCP is
designed for: It is expected that DHCP will be used to give each
machine on the network an address, which it will use as long as it is
functioning.  The result is that one always assigns more addresses to
the pool than one has machines and exhausting the pool is not a common
problem.

I gather from your message that your machines only keep a lease while
they're doing the download, and you have far more machines than
addresses.

One way to avoid this would be to use a large, private address space
for your machines.  E.g., the reserved class A network, 10.0.0.0/8.

I expect that minimizing grace periods will not help a great deal.
I've seen DHCP response times of a minute or more in large networks,
and it can be the slowest component of network initialization.  You've
made it clear that you need to start a download faster than that.  It
would be easier to get fast network services if all the machines
obtained and kept DHCP leases at all times, so they would never have
to wait.

Dale
-- 
Dale R. WORLEY    Project Manager - UPnP        <dworley@virata.com>
Virata Corp.	  Applications Infrastructure   http://emweb.com



From owner-dhcp-v4@bucknell.edu  Thu May 10 11:57:49 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01323
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 10 May 2001 11:57:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f4AFpcW07041;
	Thu, 10 May 2001 11:51:38 -0400 (EDT)
Received: from smtp-1.enteract.com (mail.enteract.com [207.229.143.33])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f4AFpZW21378
	for <dhcp-v4@bucknell.edu>; Thu, 10 May 2001 11:51:35 -0400 (EDT)
Received: from shell-2.enteract.com (shell-2.enteract.com [207.229.143.41])
	by smtp-1.enteract.com (Postfix) with ESMTP id E0F555FA3
	for <dhcp-v4@bucknell.edu>; Thu, 10 May 2001 10:50:10 -0500 (CDT)
Date: Thu, 10 May 2001 10:50:10 -0500 (CDT)
From: RM <richardm@gowinnt.com>
X-X-Sender:  <richardm@shell-2.enteract.com>
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: Newbie Post - Assembly Line DHCP Problem
In-Reply-To: <200105092154.f49Lsa301057@localhost.localdomain>
Message-ID: <Pine.BSF.4.33L2.0105101027330.73557-100000@shell-2.enteract.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: richardm@gowinnt.com
Sender: owner-dhcp-v4@bucknell.edu
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


On Wed, 9 May 2001 worley@agranat.com wrote:

>I'm not familiar with the Windows implementations, but your situation
>has a philosophical difference with the situations that DHCP is designed
>for: It is expected that DHCP will be used to give each machine on the
>network an address, which it will use as long as it is functioning.

Very true.  In our case, once PXE is done, IP connectivity is no longer
needed until the machine reboots.  PXE is used again on the second reboot,
but not on subsequent reboots.  It would be nice if we could somehow issue
a DHCPRELEASE message once the TFTP transfer of the boot image is
complete.

>The result is that one always assigns more addresses to the pool than
>one has machines and exhausting the pool is not a common problem.

Very true again.  Our scope has 201 addresses and we never exceed 201
clients at any one time - the max is 125 or so.  The trouble happens when
we bring a new batch of 125 machines in for downloading 30-60 minutes
later (and take the old one out).  All but 75 leases are now in their
grace period.  That leaves about 50 machines that cannot connect until
Win2k's DHCP runs a database cleanup, notices that the scope is full, and
prematurely deletes all the grace period leases.  As I mentioned, this
database cleanup can be triggered every 60 seconds, so these 50 machines
are in limbo for up to 60 seconds.

>I gather from your message that your machines only keep a lease while
>they're doing the download, and you have far more machines than
>addresses.

See above.  We have fewer.  Sorry I was unclear.

>One way to avoid this would be to use a large, private address space for
>your machines.  E.g., the reserved class A network, 10.0.0.0/8.

You are the fourth person who has suggested this and it is a very good
idea.  Trouble is, getting network changes made here would be like mating
elephants:

1. It's accomplished at a very high level.
2. There's a lot of kicking and screaming involved.
3. It takes 18-22 months to produce results.

MegaCorps are not nimble.

>I expect that minimizing grace periods will not help a great deal. I've
>seen DHCP response times of a minute or more in large networks, and it
>can be the slowest component of network initialization.

Our DHCP here is fast.  PXE consistently gets an address within two
seconds, provided our CRAPPY PXE server product doesn't have the four Xeon
700's pegged out at 100% utilization (this is a post for a different
list).

Thanks for your reply! (and to everyone else).

RM




From owner-dhcp-v4@bucknell.edu  Thu May 10 13:07:44 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03612
	for <DHC-ARCHIVE@odin.IETF.ORG>; Thu, 10 May 2001 13:07:44 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4AH25J05679;
	Thu, 10 May 2001 13:02:05 -0400 (EDT)
Received: from firewall.ma.virata.com (agranat.com [198.113.147.2])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4AH21J21915
	for <dhcp-v4@bucknell.edu>; Thu, 10 May 2001 13:02:02 -0400 (EDT)
Received: from agranat.com (IDENT:root@alice.agranat.com [10.21.0.130])
	by firewall.ma.virata.com (8.9.0/8.9.0) with ESMTP id NAA03637
	for <dhcp-v4@bucknell.edu>; Thu, 10 May 2001 13:01:45 -0400
Received: from localhost.localdomain (IDENT:root@dhcp75.ma.virata.com [10.21.0.75])
	by agranat.com (8.9.3/8.9.3) with ESMTP id NAA19001
	for <dhcp-v4@bucknell.edu>; Thu, 10 May 2001 13:01:45 -0400
Received: (from worley@localhost)
	by localhost.localdomain (8.11.0/8.8.7) id f4AH1iY02717;
	Thu, 10 May 2001 13:01:44 -0400
Date: Thu, 10 May 2001 13:01:44 -0400
Message-Id: <200105101701.f4AH1iY02717@localhost.localdomain>
X-Authentication-Warning: localhost.localdomain: worley set sender to dworley@virata.com using -f
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: worley@agranat.com
In-reply-to: <Pine.BSF.4.33L2.0105101027330.73557-100000@shell-2.enteract.com>
	(message from RM on Thu, 10 May 2001 10:50:10 -0500 (CDT))
Subject: Re: Newbie Post - Assembly Line DHCP Problem
References:  <Pine.BSF.4.33L2.0105101027330.73557-100000@shell-2.enteract.com>
Reply-To: worley@agranat.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

   From: RM <richardm@gowinnt.com>

   Very true again.  Our scope has 201 addresses and we never exceed 201
   clients at any one time - the max is 125 or so.  The trouble happens when
   we bring a new batch of 125 machines in for downloading 30-60 minutes
   later (and take the old one out).

So: the Windows DHCP server has a 1 day grace period, you have batches
of 125 machines, and you swap batches every 30-60 minutes, so you are
stuck with an effective population of 1000 to 6000 machines.  Ow.

Might there be some way to trigger DHCP database cleanup when there
are somewhat more than 0 addresses available?  (Or, ugh, reboot the
DHCP server, if that is sufficient to get it to forget...)  And of
course, there's no way to manuall trigger it.

Dale
-- 
Dale R. WORLEY    Project Manager - UPnP        <dworley@virata.com>
Virata Corp.	  Applications Infrastructure   http://emweb.com



From owner-dhcp-v4@bucknell.edu  Thu May 10 13:28:00 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04341
	for <DHC-ARCHIVE@odin.IETF.ORG>; Thu, 10 May 2001 13:27:59 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4AHQJJ30534;
	Thu, 10 May 2001 13:26:20 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4AHQ9J02877
	for <dhcp-v4@bucknell.edu>; Thu, 10 May 2001 13:26:09 -0400 (EDT)
Received: from grosse.bisbee.fugue.com ([204.174.65.205]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f4AHPEa13626; Thu, 10 May 2001 10:25:14 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f4AHNUR00432; Thu, 10 May 2001 10:23:30 -0700 (PDT)
Message-Id: <200105101723.f4AHNUR00432@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: Newbie Post - Assembly Line DHCP Problem 
In-Reply-To: Message from RM <richardm@gowinnt.com> 
   of "Wed, 09 May 2001 12:05:40 CDT." <Pine.BSF.4.33L2.0105091124020.94095-100000@shell-1.enteract.com> 
Date: Thu, 10 May 2001 10:23:30 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


The ISC DHCP server does roughly what you want - rather than having a
grace period, it simply sorts leases by expiry time, allocating the
least-recently-expired lease first.  I have never heard of this grace
period feature - I suspect, actually, that most DHCP servers you could
buy do not have it.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Thu May 10 14:40:49 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05969
	for <DHC-ARCHIVE@odin.IETF.ORG>; Thu, 10 May 2001 14:40:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4AIZ6J01877;
	Thu, 10 May 2001 14:35:06 -0400 (EDT)
Received: from smtp-2.enteract.com (smtp-2.enteract.com [207.229.143.4])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4AIYxJ01060
	for <dhcp-v4@bucknell.edu>; Thu, 10 May 2001 14:34:59 -0400 (EDT)
Received: from shell-1.enteract.com (shell-1.enteract.com [207.229.143.40])
	by smtp-2.enteract.com (Postfix) with ESMTP id 912936079
	for <dhcp-v4@bucknell.edu>; Thu, 10 May 2001 13:34:43 -0500 (CDT)
Date: Thu, 10 May 2001 13:34:43 -0500 (CDT)
From: RM <richardm@gowinnt.com>
X-X-Sender:  <richardm@shell-1.enteract.com>
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: Newbie Post - Assembly Line DHCP Problem
In-Reply-To: <200105101701.f4AH1iY02717@localhost.localdomain>
Message-ID: <Pine.BSF.4.33L2.0105101329010.44993-100000@shell-1.enteract.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: richardm@gowinnt.com
Sender: owner-dhcp-v4@bucknell.edu
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


On Thu, 10 May 2001 worley@agranat.com wrote:

>>Very true again.  Our scope has 201 addresses and we never exceed 201
>>clients at any one time - the max is 125 or so.  The trouble happens
>>when we bring a new batch of 125 machines in for downloading 30-60
>>minutes later (and take the old one out).

>So: the Windows DHCP server has a 1 day grace period, you have batches
>of 125 machines, and you swap batches every 30-60 minutes, so you are
>stuck with an effective population of 1000 to 6000 machines.  Ow.

Except that this facility is running way below capacity at the moment.
They'd *love* to build that many machines in a day.  Hell, I might be a
permanent employee with benefits if that were going on.  Times are lean,
however.  Soft-landing, dot-com crash, yattayatta.

>Might there be some way to trigger DHCP database cleanup when there are
>somewhat more than 0 addresses available?  (Or, ugh, reboot the DHCP
>server, if that is sufficient to get it to forget...)  And of course,
>there's no way to manuall trigger it.

With NT4, no.  It'll sit there with a full scope as long as it takes for
the leases to exit the grace period.  Win2k will clean 'em out once the
scope fills, but the scope has to fill first.  A manual delete must happen
by hand.  My next step is to see if the obscure new Netsh thingy in Win2k
can work with DHCP leases.  If so, I might be able to script something and
trigger it with the scheduler service.  Wishful thinking, but I could be
on to something.

RM





From owner-dhcp-v4@bucknell.edu  Wed May 16 18:38:06 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20343
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 16 May 2001 18:38:05 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4GMWKJ23683;
	Wed, 16 May 2001 18:32:20 -0400 (EDT)
Received: from mail1.ee.byu.edu (mail.ee.byu.edu [128.187.31.153])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4GMW6J12617
	for <dhcp-v4@bucknell.edu>; Wed, 16 May 2001 18:32:06 -0400 (EDT)
Received: from sandman.ee.byu.edu (sandman.ee.byu.edu [128.187.30.159])
	by mail1.ee.byu.edu (8.11.2/8.11.2) with ESMTP id f4GMW6L04327
	for <dhcp-v4@bucknell.edu>; Wed, 16 May 2001 16:32:06 -0600
Date: Wed, 16 May 2001 16:32:06 -0600 (MDT)
From: Beau Neal <beau@ee.byu.edu>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: dhcpd.conf
Message-ID: <Pine.HPX.4.33.0105161628340.10700-100000@sandman.ee.byu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: beau@ee.byu.edu
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


I am new to dhcp.  I need to edit a dhcpd.conf file (running on linux) and
I am looking for a good resource to learn how.  Could someone please
direct me to a good place to learn how to write and edit a dhcpd.conf
file.  Specifically I need to understand the syntax to the range value.

--
Beau Neal
beau@ee.byu.edu



From owner-dhcp-v4@bucknell.edu  Wed May 16 19:31:00 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21185
	for <DHC-ARCHIVE@odin.IETF.ORG>; Wed, 16 May 2001 19:30:59 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4GNQMJ27866;
	Wed, 16 May 2001 19:26:22 -0400 (EDT)
Received: from neimail.networkengines.com (wks7.networkengines.com [64.55.6.7] (may be forged))
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4GNQDJ18659
	for <dhcp-v4@bucknell.edu>; Wed, 16 May 2001 19:26:13 -0400 (EDT)
Received: by neimail.networkengines.com with Internet Mail Service (5.5.2653.19)
	id <K6MXCTXT>; Wed, 16 May 2001 19:25:58 -0400
Message-ID: <40B9F6A0587D9D4CB1872FD7E1449672044383@NEIMAIL2.NetworkEngines.Com>
From: Steve Gonczi <Steve.Gonczi@networkengines.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: dhcpd.conf
Date: Wed, 16 May 2001 19:25:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Steve.Gonczi@networkengines.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

How about: 

"man dhcpd.conf"

Also, the Ted Lemon/Ralph Droms book:
http://www1.fatbrain.com/asp/BookInfo/BookInfo.asp?theisbn=1578701376&from=x
jb375

Best of luck,

/sG



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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>
Message-ID: <CA256A4F.00213EBA.00@d73mta05.au.ibm.com>
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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <JQ4A85JY>; Thu, 17 May 2001 08:51:54 -0500
Message-ID: <66F66129A77AD411B76200508B65AC694CBB5E@eambunt705.ena-east.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: Reconfigure-init message in DHCPv6</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>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).</FONT></P>

<P><FONT SIZE=3D2>See <A =
HREF=3D"http://www.listproc.bucknell.edu/archives/dhcp-v6/200104/msg0000=
3.html" =
TARGET=3D"_blank">http://www.listproc.bucknell.edu/archives/dhcp-v6/2001=
04/msg00003.html</A>. www.dhcp.org also has some other notes.</FONT>
</P>

<P><FONT SIZE=3D2>- Bernie Volz</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: skodati@in.ibm.com [<A =
HREF=3D"mailto:skodati@in.ibm.com">mailto:skodati@in.ibm.com</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Thursday, May 17, 2001 12:54 AM</FONT>
<BR><FONT SIZE=3D2>To: DHCPv6 discussion list</FONT>
<BR><FONT SIZE=3D2>Subject: Reconfigure-init message in DHCPv6</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I have a few doubts in draft-ietf-dhc-dhcpv6-18 =
reconfigure-init messages,</FONT>
<BR><FONT SIZE=3D2>draft18 says, &quot;server may unicat a =
reconfigure-init messages directly to a</FONT>
<BR><FONT SIZE=3D2>single client or use a multicast....&quot;,</FONT>
</P>

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

<P><FONT SIZE=3D2>thanks and regards</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Suresh Kodati</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0DED8.87423820--



From owner-dhcp-v4@bucknell.edu  Fri May 18 10:52:40 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28130
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 18 May 2001 10:52:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4IEn2J20327;
	Fri, 18 May 2001 10:49:03 -0400 (EDT)
Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4IEmlJ17623
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 10:48:47 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62])
	by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id JAA19829
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 09:49:24 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Fri, 18 May 2001 07:41:15 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <K0VN1C9H>; Fri, 18 May 2001 07:48:07 -0700
Message-ID: <4F973E944951D311B6660008C7917CF005882EC8@zsc4c008.us.nortel.com>
From: "Mark Llacuna" <mllacuna@nortelnetworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: DHCP Packets with Option 82 from Trusted Circuit
Date: Fri, 18 May 2001 07:48:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DFA9.8BC9F730"
X-Orig: <mllacuna@americasm06.nt.com>
Reply-To: mllacuna@nortelnetworks.com
Sender: owner-dhcp-v4@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_01C0DFA9.8BC9F730
Content-Type: text/plain;
	charset="iso-8859-1"


Hello Everyone,

Section 2.1 of RFC 3046 says:

  A trusted circuit may contain a trusted downstream (closer to client)
  network element (bridge) between the relay agent and the client that
  MAY add a relay agent option but not set the giaddr field.  In this
  case, the relay agent does NOT add a "second" relay agent option, but
  forwards the DHCP packet per normal DHCP relay agent operations,
  setting the giaddr field as it deems appropriate.

>From an email exchange with the author of the RFC, it was clarified that
the keywords "does NOT" in the last statement, above, should be
interpreted as "MUST NOT". What was not clarified, however, was whether
or not the statement also prohibits any relay agent action that alters or
replaces the option 82.

Because we are not sure what the correct meaning of the statement is, we
are also not sure if our solution to the following problem is correct and
compliant to the RFC.  In our setup, there's a bridging DSLAM, our relay
agent, and a DHCP server as shown --

              +--------+       +-------+       +--------+
              | Bridge | _____ | Relay | _____ |  DHCP  |
              | DSLAM  |       | Agent |       | Server |
              +--------+       +-------+       +--------+


Every DHCP request that goes through the DSLAM is encoded with an option
82 and giaddr=0 by the DSLAM before it is passed onto our Relay Agent.
The problem is before forwarding the request to the DHCP Server, our Relay
Agent also needs to encode an option 82 in the request (in addition to
setting the giaddr to some appropriate value) for it to be able to forward
the corresponding response back to the DSLAM.

I understand that in the case where the DHCP server lease assignment policy
involves the use of the DSLAM's option 82, the relay agent must forward the
DHCP packet without touching the option 82.

But what about in the case where the DHCP server does not use the option 82:
will encapsulating the DSLAM's option 82 within the Relay Agent's option 82
be an acceptable solution?


Mark

------_=_NextPart_001_01C0DFA9.8BC9F730
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>DHCP Packets with Option 82 from Trusted Circuit</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Hello Everyone,</FONT>
</P>

<P><FONT SIZE=3D2>Section 2.1 of RFC 3046 says:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; A trusted circuit may contain a trusted =
downstream (closer to client)</FONT>
<BR><FONT SIZE=3D2>&nbsp; network element (bridge) between the relay =
agent and the client that</FONT>
<BR><FONT SIZE=3D2>&nbsp; MAY add a relay agent option but not set the =
giaddr field.&nbsp; In this</FONT>
<BR><FONT SIZE=3D2>&nbsp; case, the relay agent does NOT add a =
&quot;second&quot; relay agent option, but</FONT>
<BR><FONT SIZE=3D2>&nbsp; forwards the DHCP packet per normal DHCP =
relay agent operations,</FONT>
<BR><FONT SIZE=3D2>&nbsp; setting the giaddr field as it deems =
appropriate.</FONT>
</P>

<P><FONT SIZE=3D2>From an email exchange with the author of the RFC, it =
was clarified that</FONT>
<BR><FONT SIZE=3D2>the keywords &quot;does NOT&quot; in the last =
statement, above, should be</FONT>
<BR><FONT SIZE=3D2>interpreted as &quot;MUST NOT&quot;. What was not =
clarified, however, was whether</FONT>
<BR><FONT SIZE=3D2>or not the statement also prohibits any relay agent =
action that alters or</FONT>
<BR><FONT SIZE=3D2>replaces the option 82.</FONT>
</P>

<P><FONT SIZE=3D2>Because we are not sure what the correct meaning of =
the statement is, we</FONT>
<BR><FONT SIZE=3D2>are also not sure if our solution to the following =
problem is correct and</FONT>
<BR><FONT SIZE=3D2>compliant to the RFC.&nbsp; In our setup, there's a =
bridging DSLAM, our relay</FONT>
<BR><FONT SIZE=3D2>agent, and a DHCP server as shown --</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; +--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------+</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; | Bridge | _____ | Relay | _____ |&nbsp; DHCP&nbsp; =
|</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; | DSLAM&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | =
Agent |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Server |</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; +--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------+</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Every DHCP request that goes through the DSLAM is =
encoded with an option</FONT>
<BR><FONT SIZE=3D2>82 and giaddr=3D0 by the DSLAM before it is passed =
onto our Relay Agent.</FONT>
<BR><FONT SIZE=3D2>The problem is before forwarding the request to the =
DHCP Server, our Relay</FONT>
<BR><FONT SIZE=3D2>Agent also needs to encode an option 82 in the =
request (in addition to</FONT>
<BR><FONT SIZE=3D2>setting the giaddr to some appropriate value) for it =
to be able to forward</FONT>
<BR><FONT SIZE=3D2>the corresponding response back to the DSLAM.</FONT>
</P>

<P><FONT SIZE=3D2>I understand that in the case where the DHCP server =
lease assignment policy</FONT>
<BR><FONT SIZE=3D2>involves the use of the DSLAM's option 82, the relay =
agent must forward the</FONT>
<BR><FONT SIZE=3D2>DHCP packet without touching the option 82.</FONT>
</P>

<P><FONT SIZE=3D2>But what about in the case where the DHCP server does =
not use the option 82:</FONT>
<BR><FONT SIZE=3D2>will encapsulating the DSLAM's option 82 within the =
Relay Agent's option 82</FONT>
<BR><FONT SIZE=3D2>be an acceptable solution?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Mark</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0DFA9.8BC9F730--



From owner-dhcp-v4@bucknell.edu  Fri May 18 11:20:47 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28676
	for <DHC-ARCHIVE@odin.IETF.ORG>; Fri, 18 May 2001 11:20:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4IFK3J21500;
	Fri, 18 May 2001 11:20:03 -0400 (EDT)
Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4IFJcJ31859
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 11:19:39 -0400 (EDT)
Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com
	with Novell_GroupWise; Fri, 18 May 2001 09:19:14 -0600
Message-Id: <sb04e912.022@prv-mail25.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Fri, 18 May 2001 09:19:04 -0600
From: "Dhiraj Kant Dhiraj" <GDhiraj@novell.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Ietf standard support by ISC Reference Code
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f4IFJfJ18489
Reply-To: GDhiraj@novell.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 8bit

I have one query regarding the standard (IETF) supported by the isc Code. Can any body help me to find this out. 

Does these RFC and draft are supported by ISC dhcpv3 or not

RFC 2131 (DHCP protocol)
RFC 2132 (DHCP options)
RFC 2241 (NDS)
RFC 2242 (Netware/IP)
RFC 2485 (User Authentication Protocol)
RFC 2489 (Stateless AutoConfiguration)
RFC 2610 (SLP option)
RFC 2936 ( Name Server Selection Option )
RFC 3004 ( User Class Option )
RFC 3011 ( IPv4 Subnet Selection Option )
RFC 3046 ( Relay Agent Information option )
RFC 3074 ( Laod Balancing )

draft-ietf-dhc-fialover protocol
draft-ietf-dhc-dhcp-dns-X.txt
draft-ietf-dhc-ddns-resolution-X.txt
draft-ietf-dhc-authentication.X.txt
draft-ietf-dhc-options-cont-01.txt


Regards
dhiraj



From owner-dhcp-v4@bucknell.edu  Fri May 18 12:05:54 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29733
	for <DHC-ARCHIVE@odin.IETF.ORG>; Fri, 18 May 2001 12:05:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4IG2XJ18003;
	Fri, 18 May 2001 12:02:33 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4IG2RJ19480
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 12:02:27 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f4IG1DL00896; Fri, 18 May 2001 09:01:13 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f4IFvmt00326; Fri, 18 May 2001 08:57:48 -0700 (MST)
Message-Id: <200105181557.f4IFvmt00326@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP Packets with Option 82 from Trusted Circuit 
In-Reply-To: Message from "Mark Llacuna" <mllacuna@nortelnetworks.com> 
   of "Fri, 18 May 2001 07:48:05 MST." <4F973E944951D311B6660008C7917CF005882EC8@zsc4c008.us.nortel.com> 
Date: Fri, 18 May 2001 08:57:47 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I understand that in the case where the DHCP server lease assignment policy
> involves the use of the DSLAM's option 82, the relay agent must forward the
> DHCP packet without touching the option 82.
> 
> But what about in the case where the DHCP server does not use the option 82:
> will encapsulating the DSLAM's option 82 within the Relay Agent's option 82
> be an acceptable solution?

Are the two devices adding competing information?   That is, are both,
for example, adding a remote-id suboption?   If not, you might
consider having the cable modem simply add its own suboptions to the
existing option 82.

I don't think the existing draft talks about encapsulating option 82
within option 82, so I don't think there's a standard way of doing
this.

Where you're really going to run into trouble is if somebody buys your
DSLAM and someone else's relay agent, or vice versa.   If that's not a
possibility, then you can just make sure that whatever leaves the
relay agent is conformant.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Fri May 18 13:10:07 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01889
	for <DHC-ARCHIVE@odin.IETF.ORG>; Fri, 18 May 2001 13:10:07 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4IH76J24938;
	Fri, 18 May 2001 13:07:06 -0400 (EDT)
Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4IH6vJ18514
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 13:06:57 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id MAA03278
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 12:07:34 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Fri, 18 May 2001 12:06:44 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <K0VN1HYP>; Fri, 18 May 2001 10:06:15 -0700
Message-ID: <4F973E944951D311B6660008C7917CF005882EC9@zsc4c008.us.nortel.com>
From: "Mark Llacuna" <mllacuna@nortelnetworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: DHCP Packets with Option 82 from Trusted Circuit
Date: Fri, 18 May 2001 10:06:08 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DFBC.D4D9E7B0"
Reply-To: mllacuna@nortelnetworks.com
Sender: owner-dhcp-v4@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_01C0DFBC.D4D9E7B0
Content-Type: text/plain;
	charset="iso-8859-1"



: -----Original Message-----
: From: Ted Lemon [mailto:mellon@nominum.com]
: Sent: Friday, May 18, 2001 8:58 AM
: To: Llacuna, Mark [SC9:T337:EXCH]
: Cc: DHCPv4 discussion list
: Subject: Re: DHCP Packets with Option 82 from Trusted Circuit
: 
: 
: 
: > I understand that in the case where the DHCP server lease 
: assignment policy
: > involves the use of the DSLAM's option 82, the relay agent 
: must forward the
: > DHCP packet without touching the option 82.
: > 
: > But what about in the case where the DHCP server does not 
: use the option 82:
: > will encapsulating the DSLAM's option 82 within the Relay 
: Agent's option 82
: > be an acceptable solution?
: 
: Are the two devices adding competing information?   That is, are both,
: for example, adding a remote-id suboption?   If not, you might
: consider having the cable modem simply add its own suboptions to the
: existing option 82.

Our relay agent may add a circuit id and/or a remote id depending
on the configuration.  However, it needs to be configured to add
a circuit id in the scenario I've mentioned wherein the agent requires
additional information for it to relay responses back to the DSLAM.


: 
: I don't think the existing draft talks about encapsulating option 82
: within option 82, so I don't think there's a standard way of doing
: this.
: 
: Where you're really going to run into trouble is if somebody buys your
: DSLAM and someone else's relay agent, or vice versa.   If that's not a
: possibility, then you can just make sure that whatever leaves the
: relay agent is conformant.

If ever we decide to go with the "encapsulation" strategy, we'll
probably allow it to be enabled/disabled.  But as you said,
enabling it is non-standard behavior.


: 
: 			       _MelloN_
: 

Thank!


Mark

------_=_NextPart_001_01C0DFBC.D4D9E7B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: DHCP Packets with Option 82 from Trusted Circuit</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>: -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>: From: Ted Lemon [<A =
HREF=3D"mailto:mellon@nominum.com">mailto:mellon@nominum.com</A>]</FONT>=

<BR><FONT SIZE=3D2>: Sent: Friday, May 18, 2001 8:58 AM</FONT>
<BR><FONT SIZE=3D2>: To: Llacuna, Mark [SC9:T337:EXCH]</FONT>
<BR><FONT SIZE=3D2>: Cc: DHCPv4 discussion list</FONT>
<BR><FONT SIZE=3D2>: Subject: Re: DHCP Packets with Option 82 from =
Trusted Circuit</FONT>
<BR><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: &gt; I understand that in the case where the DHCP =
server lease </FONT>
<BR><FONT SIZE=3D2>: assignment policy</FONT>
<BR><FONT SIZE=3D2>: &gt; involves the use of the DSLAM's option 82, =
the relay agent </FONT>
<BR><FONT SIZE=3D2>: must forward the</FONT>
<BR><FONT SIZE=3D2>: &gt; DHCP packet without touching the option =
82.</FONT>
<BR><FONT SIZE=3D2>: &gt; </FONT>
<BR><FONT SIZE=3D2>: &gt; But what about in the case where the DHCP =
server does not </FONT>
<BR><FONT SIZE=3D2>: use the option 82:</FONT>
<BR><FONT SIZE=3D2>: &gt; will encapsulating the DSLAM's option 82 =
within the Relay </FONT>
<BR><FONT SIZE=3D2>: Agent's option 82</FONT>
<BR><FONT SIZE=3D2>: &gt; be an acceptable solution?</FONT>
<BR><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: Are the two devices adding competing =
information?&nbsp;&nbsp; That is, are both,</FONT>
<BR><FONT SIZE=3D2>: for example, adding a remote-id =
suboption?&nbsp;&nbsp; If not, you might</FONT>
<BR><FONT SIZE=3D2>: consider having the cable modem simply add its own =
suboptions to the</FONT>
<BR><FONT SIZE=3D2>: existing option 82.</FONT>
</P>

<P><FONT SIZE=3D2>Our relay agent may add a circuit id and/or a remote =
id depending</FONT>
<BR><FONT SIZE=3D2>on the configuration.&nbsp; However, it needs to be =
configured to add</FONT>
<BR><FONT SIZE=3D2>a circuit id in the scenario I've mentioned wherein =
the agent requires</FONT>
<BR><FONT SIZE=3D2>additional information for it to relay responses =
back to the DSLAM.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: I don't think the existing draft talks about =
encapsulating option 82</FONT>
<BR><FONT SIZE=3D2>: within option 82, so I don't think there's a =
standard way of doing</FONT>
<BR><FONT SIZE=3D2>: this.</FONT>
<BR><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: Where you're really going to run into trouble is =
if somebody buys your</FONT>
<BR><FONT SIZE=3D2>: DSLAM and someone else's relay agent, or vice =
versa.&nbsp;&nbsp; If that's not a</FONT>
<BR><FONT SIZE=3D2>: possibility, then you can just make sure that =
whatever leaves the</FONT>
<BR><FONT SIZE=3D2>: relay agent is conformant.</FONT>
</P>

<P><FONT SIZE=3D2>If ever we decide to go with the =
&quot;encapsulation&quot; strategy, we'll</FONT>
<BR><FONT SIZE=3D2>probably allow it to be enabled/disabled.&nbsp; But =
as you said,</FONT>
<BR><FONT SIZE=3D2>enabling it is non-standard behavior.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _MelloN_</FONT>
<BR><FONT SIZE=3D2>: </FONT>
</P>

<P><FONT SIZE=3D2>Thank!</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Mark</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0DFBC.D4D9E7B0--



From owner-dhcp-v4@bucknell.edu  Fri May 18 13:21:02 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02400
	for <DHC-ARCHIVE@odin.IETF.ORG>; Fri, 18 May 2001 13:21:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4IHKRJ28959;
	Fri, 18 May 2001 13:20:28 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4IHKEJ29069
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 13:20:14 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f4IHIxZ00411; Fri, 18 May 2001 10:18:59 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f4IHFTt01063; Fri, 18 May 2001 10:15:29 -0700 (MST)
Message-Id: <200105181715.f4IHFTt01063@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP Packets with Option 82 from Trusted Circuit 
In-Reply-To: Message from "Mark Llacuna" <mllacuna@nortelnetworks.com> 
   of "Fri, 18 May 2001 10:06:08 MST." <4F973E944951D311B6660008C7917CF005882EC9@zsc4c008.us.nortel.com> 
Date: Fri, 18 May 2001 10:15:28 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Our relay agent may add a circuit id and/or a remote id depending
> on the configuration.  However, it needs to be configured to add
> a circuit id in the scenario I've mentioned wherein the agent requires
> additional information for it to relay responses back to the DSLAM.

Hrm, so you might need a circuit ID for the relay agent, and then a
different circuit ID for the DSLAM?

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Fri May 18 13:47:40 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05595
	for <DHC-ARCHIVE@odin.IETF.ORG>; Fri, 18 May 2001 13:47:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4IHivJ15805;
	Fri, 18 May 2001 13:44:57 -0400 (EDT)
Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4IHifJ17142
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 13:44:41 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62])
	by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id MAA15017
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 12:45:19 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Fri, 18 May 2001 10:37:14 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <K0VN1JC0>; Fri, 18 May 2001 10:44:06 -0700
Message-ID: <4F973E944951D311B6660008C7917CF005882ECA@zsc4c008.us.nortel.com>
From: "Mark Llacuna" <mllacuna@nortelnetworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: DHCP Packets with Option 82 from Trusted Circuit
Date: Fri, 18 May 2001 10:44:00 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DFC2.1F56B700"
X-Orig: <mllacuna@americasm06.nt.com>
Reply-To: mllacuna@nortelnetworks.com
Sender: owner-dhcp-v4@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_01C0DFC2.1F56B700
Content-Type: text/plain;
	charset="iso-8859-1"


: > Our relay agent may add a circuit id and/or a remote id depending
: > on the configuration.  However, it needs to be configured to add
: > a circuit id in the scenario I've mentioned wherein the 
: agent requires
: > additional information for it to relay responses back to the DSLAM.
: 
: Hrm, so you might need a circuit ID for the relay agent, and then a
: different circuit ID for the DSLAM?
: 
: 			       _MelloN_
:

Yes. Either we'll have the relay agent encode the entire DSLAM's
option 82 as an extension of its circuit id suboption, or as
separate suboptions in addition to the relay agent suboptions
(whichever is the better non-standard solution.)


Mark

------_=_NextPart_001_01C0DFC2.1F56B700
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: DHCP Packets with Option 82 from Trusted Circuit</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>: &gt; Our relay agent may add a circuit id and/or a =
remote id depending</FONT>
<BR><FONT SIZE=3D2>: &gt; on the configuration.&nbsp; However, it needs =
to be configured to add</FONT>
<BR><FONT SIZE=3D2>: &gt; a circuit id in the scenario I've mentioned =
wherein the </FONT>
<BR><FONT SIZE=3D2>: agent requires</FONT>
<BR><FONT SIZE=3D2>: &gt; additional information for it to relay =
responses back to the DSLAM.</FONT>
<BR><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: Hrm, so you might need a circuit ID for the relay =
agent, and then a</FONT>
<BR><FONT SIZE=3D2>: different circuit ID for the DSLAM?</FONT>
<BR><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _MelloN_</FONT>
<BR><FONT SIZE=3D2>:</FONT>
</P>

<P><FONT SIZE=3D2>Yes. Either we'll have the relay agent encode the =
entire DSLAM's</FONT>
<BR><FONT SIZE=3D2>option 82 as an extension of its circuit id =
suboption, or as</FONT>
<BR><FONT SIZE=3D2>separate suboptions in addition to the relay agent =
suboptions</FONT>
<BR><FONT SIZE=3D2>(whichever is the better non-standard =
solution.)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Mark</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0DFC2.1F56B700--



From owner-dhcp-v4@bucknell.edu  Fri May 18 14:09:28 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10117
	for <DHC-ARCHIVE@odin.IETF.ORG>; Fri, 18 May 2001 14:09:27 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4II8lJ23525;
	Fri, 18 May 2001 14:08:47 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4II8iJ00342
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 14:08:44 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f4II7TZ00482; Fri, 18 May 2001 11:07:29 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f4II3tt01142; Fri, 18 May 2001 11:03:55 -0700 (MST)
Message-Id: <200105181803.f4II3tt01142@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP Packets with Option 82 from Trusted Circuit 
In-Reply-To: Message from "Mark Llacuna" <mllacuna@nortelnetworks.com> 
   of "Fri, 18 May 2001 10:44:00 MST." <4F973E944951D311B6660008C7917CF005882ECA@zsc4c008.us.nortel.com> 
Date: Fri, 18 May 2001 11:03:55 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


I think the right thing to do is to define a standard suboption that
says "this is an encapsulated relay agent option".

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Fri May 18 14:33:50 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11127
	for <DHC-ARCHIVE@odin.IETF.ORG>; Fri, 18 May 2001 14:33:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4IIVDJ07544;
	Fri, 18 May 2001 14:31:13 -0400 (EDT)
Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4IIVBJ12816
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 14:31:11 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id NAA29779
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 13:31:38 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Fri, 18 May 2001 13:31:00 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <K0VN1KWL>; Fri, 18 May 2001 11:30:31 -0700
Message-ID: <4F973E944951D311B6660008C7917CF005882ECC@zsc4c008.us.nortel.com>
From: "Mark Llacuna" <mllacuna@nortelnetworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: DHCP Packets with Option 82 from Trusted Circuit
Date: Fri, 18 May 2001 11:30:29 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DFC8.9D4FCD80"
Reply-To: mllacuna@nortelnetworks.com
Sender: owner-dhcp-v4@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_01C0DFC8.9D4FCD80
Content-Type: text/plain;
	charset="iso-8859-1"



: I think the right thing to do is to define a standard suboption that
: says "this is an encapsulated relay agent option".
: 
: 			       _MelloN_
: 

I agree.


Mark

------_=_NextPart_001_01C0DFC8.9D4FCD80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: DHCP Packets with Option 82 from Trusted Circuit</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>: I think the right thing to do is to define a =
standard suboption that</FONT>
<BR><FONT SIZE=3D2>: says &quot;this is an encapsulated relay agent =
option&quot;.</FONT>
<BR><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _MelloN_</FONT>
<BR><FONT SIZE=3D2>: </FONT>
</P>

<P><FONT SIZE=3D2>I agree.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Mark</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0DFC8.9D4FCD80--



From owner-dhcp-v4@bucknell.edu  Fri May 18 16:48:57 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16084
	for <DHC-ARCHIVE@odin.IETF.ORG>; Fri, 18 May 2001 16:48:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4IKjeJ27977;
	Fri, 18 May 2001 16:45:40 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4IKjWJ28490
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 16:45:32 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f4IKiHZ00764; Fri, 18 May 2001 13:44:17 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f4IKeWt01329; Fri, 18 May 2001 13:40:32 -0700 (MST)
Message-Id: <200105182040.f4IKeWt01329@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP Packets with Option 82 from Trusted Circuit 
In-Reply-To: Message from "Mark Llacuna" <mllacuna@nortelnetworks.com> 
   of "Fri, 18 May 2001 11:30:29 MST." <4F973E944951D311B6660008C7917CF005882ECC@zsc4c008.us.nortel.com> 
Date: Fri, 18 May 2001 13:40:32 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I agree.

So are you going to write it up?   :')

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Fri May 18 18:10:19 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17494
	for <DHC-ARCHIVE@odin.IETF.ORG>; Fri, 18 May 2001 18:10:19 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4IM60J16846;
	Fri, 18 May 2001 18:06:00 -0400 (EDT)
Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4IM5mJ09381
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 18:05:48 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id RAA28073
	for <dhcp-v4@bucknell.edu>; Fri, 18 May 2001 17:06:16 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Fri, 18 May 2001 17:05:33 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <K0VN1QP7>; Fri, 18 May 2001 15:05:04 -0700
Message-ID: <4F973E944951D311B6660008C7917CF005882ED0@zsc4c008.us.nortel.com>
From: "Mark Llacuna" <mllacuna@nortelnetworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: DHCP Packets with Option 82 from Trusted Circuit
Date: Fri, 18 May 2001 15:05:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0DFE6.9761B910"
Reply-To: mllacuna@nortelnetworks.com
Sender: owner-dhcp-v4@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_01C0DFE6.9761B910
Content-Type: text/plain;
	charset="iso-8859-1"


: 
: > I agree.
: 
: So are you going to write it up?   :')
: 
: 			       _MelloN_
:

I knew you were gonna ask.

Hmmm... let me discuss this with the rest
of my team.


Mark

 

------_=_NextPart_001_01C0DFE6.9761B910
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: DHCP Packets with Option 82 from Trusted Circuit</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: &gt; I agree.</FONT>
<BR><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: So are you going to write it up?&nbsp;&nbsp; =
:')</FONT>
<BR><FONT SIZE=3D2>: </FONT>
<BR><FONT SIZE=3D2>: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _MelloN_</FONT>
<BR><FONT SIZE=3D2>:</FONT>
</P>

<P><FONT SIZE=3D2>I knew you were gonna ask.</FONT>
</P>

<P><FONT SIZE=3D2>Hmmm... let me discuss this with the rest</FONT>
<BR><FONT SIZE=3D2>of my team.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Mark</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0DFE6.9761B910--



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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>
Message-ID: <CA256A53.0030CDDE.00@d73mta05.au.ibm.com>
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-v4@bucknell.edu  Tue May 22 01:39:30 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28096
	for <DHC-ARCHIVE@odin.IETF.ORG>; Tue, 22 May 2001 01:39:29 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4M5WoJ27937;
	Tue, 22 May 2001 01:32:51 -0400 (EDT)
Received: from fs-sd-exch2.coppermountain.com (fs-sd-exch2.coppermountain.com [209.246.224.234])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4M5WjJ07262
	for <dhcp-v4@bucknell.edu>; Tue, 22 May 2001 01:32:45 -0400 (EDT)
Received: by fs-sd-exch2.coppermountain.com with Internet Mail Service (5.5.2653.19)
	id <LM3NJS93>; Mon, 21 May 2001 22:32:56 -0700
Message-ID: <583EFB625043D511920400D0B74178C8347C9C@fs-sd-exch2.coppermountain.com>
From: emichelsen@coppermountain.com
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: DHCP Packets with Option 82 from Trusted Circuit
Date: Mon, 21 May 2001 22:32:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: emichelsen@coppermountain.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> -----Original Message-----
> From: Mark Llacuna [mailto:mllacuna@nortelnetworks.com]
> Sent: Friday, May 18, 2001 7:48
> To: DHCPv4 discussion list
> Subject: DHCP Packets with Option 82 from Trusted Circuit
> 
> Hello Everyone, 
> Section 2.1 of RFC 3046 says: 
>   A trusted circuit may contain a trusted downstream (closer 
> to client) 
>   network element (bridge) between the relay agent and the 
> client that 
>   MAY add a relay agent option but not set the giaddr field.  In this 
>   case, the relay agent does NOT add a "second" relay agent 
> option, but 
>   forwards the DHCP packet per normal DHCP relay agent operations, 
>   setting the giaddr field as it deems appropriate. 

> From an email exchange with the author of the RFC, it was 
> clarified that 
> the keywords "does NOT" in the last statement, above, should be 
> interpreted as "MUST NOT".

I think the RFC is correct in not using "MUST NOT," and implementers should
not interpret it as "MUST NOT."  The RFC simply gives an example of a policy
that network operators might implement.  They might implement another
policy.  The protocol does not care, and network operator policies are not a
matter for standardization.

Here's an example of a policy that operators might implement:

The DSLAM uses one suboption for its ID (say, Remote-ID)
The relay-agent uses the other suboption (say, Circuit-ID)

Each agent can deal with his own piece of the pie.  This is completely
standard, though not necessarily all implementations are capable of it.



From owner-dhcp-v4@bucknell.edu  Tue May 22 11:40:13 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22918
	for <DHC-ARCHIVE@odin.IETF.ORG>; Tue, 22 May 2001 11:40:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4MFaEJ02520;
	Tue, 22 May 2001 11:36:14 -0400 (EDT)
Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4MFa3J12278
	for <dhcp-v4@bucknell.edu>; Tue, 22 May 2001 11:36:03 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id KAA10459
	for <dhcp-v4@bucknell.edu>; Tue, 22 May 2001 10:36:29 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Tue, 22 May 2001 10:35:34 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <K0VNGJ9T>; Tue, 22 May 2001 08:35:03 -0700
Message-ID: <4F973E944951D311B6660008C7917CF005882ED9@zsc4c008.us.nortel.com>
From: "Mark Llacuna" <mllacuna@nortelnetworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: DHCP Packets with Option 82 from Trusted Circuit
Date: Tue, 22 May 2001 08:34:55 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E2D4.C07C0030"
Reply-To: mllacuna@nortelnetworks.com
Sender: owner-dhcp-v4@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_01C0E2D4.C07C0030
Content-Type: text/plain;
	charset="iso-8859-1"


: 
: I think the RFC is correct in not using "MUST NOT," and 
: implementers should
: not interpret it as "MUST NOT."  The RFC simply gives an 
: example of a policy
: that network operators might implement.  They might implement another
: policy.  The protocol does not care, and network operator 
: policies are not a
: matter for standardization.

>From my perspective, that section of the RFC is NOT very
clear in its intention, and your interpretation of it could
be one of many, if not the only correct one.

As I have mentioned, I asked Michael Patrick what "does NOT"
meant in that context. In an email he replied that it meant
"MUST NOT", which is contrary to what you think its
interpretation should be.

Aside from that, it's not clear what "a "second" relay agent
option" means. Why is "second" quoted? Does it refer to a
relay agent option encoded next to another relay agent option?
Can a relay agent option encapsulated in another (which is not
dealt in the RFC) be also considered a "second" option?  

If indeed the RFC only meant the section as "an example of a
policy that network operators might implement", I think it
should also state this intention to avoid ambiguities. 


: 
: Here's an example of a policy that operators might implement:
: 
: The DSLAM uses one suboption for its ID (say, Remote-ID)
: The relay-agent uses the other suboption (say, Circuit-ID)
: 
: Each agent can deal with his own piece of the pie.  This is completely
: standard, though not necessarily all implementations are 
: capable of it.
: 

What if both the DSLAM and Relay Agent need to be configured
or have to use the same suboption?


Mark


------_=_NextPart_001_01C0E2D4.C07C0030
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: DHCP Packets with Option 82 from Trusted Circuit</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>: </FONT>
<BR><FONT SIZE=2>: I think the RFC is correct in not using &quot;MUST NOT,&quot; and </FONT>
<BR><FONT SIZE=2>: implementers should</FONT>
<BR><FONT SIZE=2>: not interpret it as &quot;MUST NOT.&quot;&nbsp; The RFC simply gives an </FONT>
<BR><FONT SIZE=2>: example of a policy</FONT>
<BR><FONT SIZE=2>: that network operators might implement.&nbsp; They might implement another</FONT>
<BR><FONT SIZE=2>: policy.&nbsp; The protocol does not care, and network operator </FONT>
<BR><FONT SIZE=2>: policies are not a</FONT>
<BR><FONT SIZE=2>: matter for standardization.</FONT>
</P>

<P><FONT SIZE=2>From my perspective, that section of the RFC is NOT very</FONT>
<BR><FONT SIZE=2>clear in its intention, and your interpretation of it could</FONT>
<BR><FONT SIZE=2>be one of many, if not the only correct one.</FONT>
</P>

<P><FONT SIZE=2>As I have mentioned, I asked Michael Patrick what &quot;does NOT&quot;</FONT>
<BR><FONT SIZE=2>meant in that context. In an email he replied that it meant</FONT>
<BR><FONT SIZE=2>&quot;MUST NOT&quot;, which is contrary to what you think its</FONT>
<BR><FONT SIZE=2>interpretation should be.</FONT>
</P>

<P><FONT SIZE=2>Aside from that, it's not clear what &quot;a &quot;second&quot; relay agent</FONT>
<BR><FONT SIZE=2>option&quot; means. Why is &quot;second&quot; quoted? Does it refer to a</FONT>
<BR><FONT SIZE=2>relay agent option encoded next to another relay agent option?</FONT>
<BR><FONT SIZE=2>Can a relay agent option encapsulated in another (which is not</FONT>
<BR><FONT SIZE=2>dealt in the RFC) be also considered a &quot;second&quot; option?&nbsp; </FONT>
</P>

<P><FONT SIZE=2>If indeed the RFC only meant the section as &quot;an example of a</FONT>
<BR><FONT SIZE=2>policy that network operators might implement&quot;, I think it</FONT>
<BR><FONT SIZE=2>should also state this intention to avoid ambiguities. </FONT>
</P>
<BR>

<P><FONT SIZE=2>: </FONT>
<BR><FONT SIZE=2>: Here's an example of a policy that operators might implement:</FONT>
<BR><FONT SIZE=2>: </FONT>
<BR><FONT SIZE=2>: The DSLAM uses one suboption for its ID (say, Remote-ID)</FONT>
<BR><FONT SIZE=2>: The relay-agent uses the other suboption (say, Circuit-ID)</FONT>
<BR><FONT SIZE=2>: </FONT>
<BR><FONT SIZE=2>: Each agent can deal with his own piece of the pie.&nbsp; This is completely</FONT>
<BR><FONT SIZE=2>: standard, though not necessarily all implementations are </FONT>
<BR><FONT SIZE=2>: capable of it.</FONT>
<BR><FONT SIZE=2>: </FONT>
</P>

<P><FONT SIZE=2>What if both the DSLAM and Relay Agent need to be configured</FONT>
<BR><FONT SIZE=2>or have to use the same suboption?</FONT>
</P>
<BR>

<P><FONT SIZE=2>Mark</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0E2D4.C07C0030--



From owner-dhcp-v4@bucknell.edu  Thu May 24 11:04:27 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14888
	for <DHC-ARCHIVE@odin.IETF.ORG>; Thu, 24 May 2001 11:04:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4OF0EJ04393;
	Thu, 24 May 2001 11:00:14 -0400 (EDT)
Received: from ashd1-1.relay.mail.uu.net (ashd1-1.relay.mail.uu.net [199.171.54.245])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4OF08J14836
	for <dhcp-v4@bucknell.edu>; Thu, 24 May 2001 11:00:08 -0400 (EDT)
Received: from AVIANSERVER.aviancommunications.com by mr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.119.86.6])
	id QQkqki20645
	for <dhcp-v4@bucknell.edu>; Thu, 24 May 2001 15:00:07 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Subject: DHCP attributes in 3GPP/GPRS networks...
Date: Thu, 24 May 2001 11:00:02 -0400
Message-ID: <DE6495F924D2304DA0FAD60FC1C0060109EF3F@AVIANSERVER.aviancommunications.com>
Thread-Topic: DHCP attributes in 3GPP/GPRS networks...
Thread-Index: AcDkYjV3JyAOurx+Q8qOSNfYZff7xw==
From: "Umesh Sirsiwal" <Umesh@aviancommunications.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.bucknell.edu id f4OF08J17771
Reply-To: Umesh@aviancommunications.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 8bit

 
I don't know if this is the right place to post this query. However
I do not know any better place either.
 
In GPRS networks, GGSN (which acts as access concentrator
in landline networks) performs the DHCP request on behalf of
mobile phone. Also the end host can also perform DHCP request.
 
I wanted to know if there are any standards with respect to what
are hardware address and/or client identification used by
the GGSN. Is it MSISDN?
 
 
-Umesh



From owner-dhcp-v4@bucknell.edu  Thu May 24 12:37:27 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16856
	for <DHC-ARCHIVE@odin.IETF.ORG>; Thu, 24 May 2001 12:37:25 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4OGXKJ12611;
	Thu, 24 May 2001 12:33:20 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4OGX5J03566
	for <dhcp-v4@bucknell.edu>; Thu, 24 May 2001 12:33:05 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id MAA21855; Thu, 24 May 2001 12:32:35 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 24 May 2001 12:32:16 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <K83J7M32>; Thu, 24 May 2001 12:32:19 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9CA5B458@zcard031.ca.nortel.com>
From: "Louis-Nicolas Hamer" <nhamer@nortelnetworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: DHCP attributes in 3GPP/GPRS networks...
Date: Thu, 24 May 2001 12:32:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0E46F.172976B0"
X-Orig: <nhamer@americasm01.nt.com>
Reply-To: nhamer@nortelnetworks.com
Sender: owner-dhcp-v4@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_01C0E46F.172976B0
Content-Type: text/plain;
	charset="utf-8"

You should read spec 23.228. It is available at www.3gpp.org.

L-N



-----Original Message-----
From: Umesh Sirsiwal [mailto:Umesh@aviancommunications.com]
Sent: Thursday, May 24, 2001 11:00 AM
To: DHCPv4 discussion list
Subject: DHCP attributes in 3GPP/GPRS networks...


 
I don't know if this is the right place to post this query. However
I do not know any better place either.
 
In GPRS networks, GGSN (which acts as access concentrator
in landline networks) performs the DHCP request on behalf of
mobile phone. Also the end host can also perform DHCP request.
 
I wanted to know if there are any standards with respect to what
are hardware address and/or client identification used by
the GGSN. Is it MSISDN?
 
 
-Umesh


------_=_NextPart_001_01C0E46F.172976B0
Content-Type: text/html;
	charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: DHCP attributes in 3GPP/GPRS networks...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>You should read spec 23.228. It is available at www.3gpp.org.</FONT>
</P>

<P><FONT SIZE=2>L-N</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Umesh Sirsiwal [<A HREF="mailto:Umesh@aviancommunications.com">mailto:Umesh@aviancommunications.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, May 24, 2001 11:00 AM</FONT>
<BR><FONT SIZE=2>To: DHCPv4 discussion list</FONT>
<BR><FONT SIZE=2>Subject: DHCP attributes in 3GPP/GPRS networks...</FONT>
</P>
<BR>

<P><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>I don't know if this is the right place to post this query. However</FONT>
<BR><FONT SIZE=2>I do not know any better place either.</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>In GPRS networks, GGSN (which acts as access concentrator</FONT>
<BR><FONT SIZE=2>in landline networks) performs the DHCP request on behalf of</FONT>
<BR><FONT SIZE=2>mobile phone. Also the end host can also perform DHCP request.</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>I wanted to know if there are any standards with respect to what</FONT>
<BR><FONT SIZE=2>are hardware address and/or client identification used by</FONT>
<BR><FONT SIZE=2>the GGSN. Is it MSISDN?</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>-Umesh</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0E46F.172976B0--



From owner-dhcp-v4@bucknell.edu  Thu May 24 13:30:07 2001
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17760
	for <DHC-ARCHIVE@odin.IETF.ORG>; Thu, 24 May 2001 13:30:06 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.11.3/8.11.3) with SMTP id f4OHR9J30329;
	Thu, 24 May 2001 13:27:09 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by mail.bucknell.edu (8.11.3/8.11.3) with ESMTP id f4OHR4J01319
	for <dhcp-v4@bucknell.edu>; Thu, 24 May 2001 13:27:04 -0400 (EDT)
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2650.21)
	id <KSHAJXTA>; Thu, 24 May 2001 13:27:03 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484203AE@meshpdc.meshnetworks.com>
From: =?utf-8?B?S2V2aW4gRmFybGV5?= <KFarley@MeshNetworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: =?utf-8?B?UkU6IERIQ1AgYXR0cmlidXRlcyBpbiAzR1BQL0dQUlMgbmV0d29y?=
	=?utf-8?B?a3MuLi4=?=
Date: Thu, 24 May 2001 13:26:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0E476.BCDEC9C8"
Reply-To: KFarley@MeshNetworks.com
Sender: owner-dhcp-v4@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_01C0E476.BCDEC9C8
Content-Type: text/plain;
	charset="utf-8"

Without reading all 126 pages, could someone point me to the right place in
the document? Or is there a straightforward answer to the question from
Umesh?
 
- Kevin
 

-----Original Message-----
From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com]
Sent: Thursday, May 24, 2001 12:32 PM
To: DHCPv4 discussion list
Subject: RE: DHCP attributes in 3GPP/GPRS networks...



You should read spec 23.228. It is available at www.3gpp.org. 

L-N 



-----Original Message----- 
From: Umesh Sirsiwal [ mailto:Umesh@aviancommunications.com
<mailto:Umesh@aviancommunications.com> ] 
Sent: Thursday, May 24, 2001 11:00 AM 
To: DHCPv4 discussion list 
Subject: DHCP attributes in 3GPP/GPRS networks... 



I don't know if this is the right place to post this query. However 
I do not know any better place either. 
  
In GPRS networks, GGSN (which acts as access concentrator 
in landline networks) performs the DHCP request on behalf of 
mobile phone. Also the end host can also perform DHCP request. 
  
I wanted to know if there are any standards with respect to what 
are hardware address and/or client identification used by 
the GGSN. Is it MSISDN? 
  
  
-Umesh 


------_=_NextPart_001_01C0E476.BCDEC9C8
Content-Type: text/html;
	charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<TITLE>RE: DHCP attributes in 3GPP/GPRS networks...</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=943532017-24052001><FONT face=Arial color=#0000ff 
size=2>Without reading all 126 pages, could someone point me to the right place 
in the document? Or is there a straightforward answer to the question from 
Umesh?</FONT></SPAN></DIV>
<DIV><SPAN class=943532017-24052001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=943532017-24052001><FONT face=Arial color=#0000ff size=2>- 
Kevin</FONT></SPAN></DIV>
<DIV><SPAN class=943532017-24052001></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Louis-Nicolas Hamer 
  [mailto:nhamer@nortelnetworks.com]<BR><B>Sent:</B> Thursday, May 24, 2001 
  12:32 PM<BR><B>To:</B> DHCPv4 discussion list<BR><B>Subject:</B> RE: DHCP 
  attributes in 3GPP/GPRS networks...<BR><BR></FONT></DIV>
  <P><FONT size=2>You should read spec 23.228. It is available at 
  www.3gpp.org.</FONT> </P>
  <P><FONT size=2>L-N</FONT> </P><BR><BR>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Umesh 
  Sirsiwal [<A 
  href="mailto:Umesh@aviancommunications.com">mailto:Umesh@aviancommunications.com</A>]</FONT> 
  <BR><FONT size=2>Sent: Thursday, May 24, 2001 11:00 AM</FONT> <BR><FONT 
  size=2>To: DHCPv4 discussion list</FONT> <BR><FONT size=2>Subject: DHCP 
  attributes in 3GPP/GPRS networks...</FONT> </P><BR>
  <P><FONT size=2></FONT> <BR><FONT size=2>I don't know if this is the right 
  place to post this query. However</FONT> <BR><FONT size=2>I do not know any 
  better place either.</FONT> <BR><FONT size=2>&nbsp;</FONT> <BR><FONT size=2>In 
  GPRS networks, GGSN (which acts as access concentrator</FONT> <BR><FONT 
  size=2>in landline networks) performs the DHCP request on behalf of</FONT> 
  <BR><FONT size=2>mobile phone. Also the end host can also perform DHCP 
  request.</FONT> <BR><FONT size=2>&nbsp;</FONT> <BR><FONT size=2>I wanted to 
  know if there are any standards with respect to what</FONT> <BR><FONT 
  size=2>are hardware address and/or client identification used by</FONT> 
  <BR><FONT size=2>the GGSN. Is it MSISDN?</FONT> <BR><FONT size=2>&nbsp;</FONT> 
  <BR><FONT size=2>&nbsp;</FONT> <BR><FONT size=2>-Umesh</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0E476.BCDEC9C8--



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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <jmarchan@rennes.enst-bretagne.fr>
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 <dhcp-v6@bucknell.edu>
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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>
cc: bsuparna@in.ibm.com, rsharada@in.ibm.com
Message-ID: <CA256A5D.0022DE64.00@d73mta01.au.ibm.com>
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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <JQ4B4MHW>; Thu, 31 May 2001 04:40:50 -0500
Message-ID: <66F66129A77AD411B76200508B65AC694CBBB8@eambunt705.ena-east.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
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 <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
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: Reconfigure-init message in DHCPv6</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>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 &lt;N&gt; =
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.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>- Bernie Volz</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: skodati@in.ibm.com [<A =
HREF=3D"mailto:skodati@in.ibm.com">mailto:skodati@in.ibm.com</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Thursday, May 31, 2001 2:12 AM</FONT>
<BR><FONT SIZE=3D2>To: DHCPv6 discussion list</FONT>
<BR><FONT SIZE=3D2>Cc: bsuparna@in.ibm.com; rsharada@in.ibm.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Reconfigure-init message in =
DHCPv6</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt;&gt;Per discussions during a design team meeting =
and at the March IETF, we</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;hope to punt on the multicast =
reconfigure-init support for now.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Yes, Reconfigure-init will *not* have multicast =
as an option in the next</FONT>
<BR><FONT SIZE=3D2>&gt;DHCP spec draft.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;- Ralph</FONT>
</P>

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

<P><FONT SIZE=3D2>Is the transaction id is going to be same for all =
messages or different in</FONT>
<BR><FONT SIZE=3D2>both the cases.....</FONT>
</P>

<P><FONT SIZE=3D2>suresh.</FONT>
</P>

</BODY>
</HTML>
------_=_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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: RE: Reconfigure-init message in DHCPv6
Cc: DHCPv6 discussion list <dhcp-v6@bucknell.edu>, 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 <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.



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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
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 <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.



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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <JQ4B40PP>; Thu, 31 May 2001 10:41:40 -0500
Message-ID: <66F66129A77AD411B76200508B65AC694CBBBC@eambunt705.ena-east.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
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 <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
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: Reconfigure-init message in DHCPv6</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ralph:</FONT>
</P>

<P><FONT SIZE=3D2>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 &lt;n&gt; =
seconds of the Reply to the Request, treat this as a duplicate; =
otherwise it is a new request.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>- Bernie</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ralph Droms [<A =
HREF=3D"mailto:rdroms@cisco.com">mailto:rdroms@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 31, 2001 10:08 AM</FONT>
<BR><FONT SIZE=3D2>To: DHCPv6 discussion list</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Reconfigure-init message in =
DHCPv6</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Oops, sorry.&nbsp; I responded without thinking all =
the way through Thomas' </FONT>
<BR><FONT SIZE=3D2>suggested mechanism for Reconfigure-init - in fact, =
I think it actually </FONT>
<BR><FONT SIZE=3D2>does solve the transaction ID problem...</FONT>
</P>

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

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

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

<P><FONT SIZE=3D2>I'll write up this new mechanism in the next draft of =
the spec.</FONT>
</P>

<P><FONT SIZE=3D2>- Ralph</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 06:21 AM 5/31/2001 -0400, Ralph Droms =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;I agree with Bernie that the mechanisms for =
sending Reconfigure-init to </FONT>
<BR><FONT SIZE=3D2>&gt;multiple clients is an implementation issue and =
shouldn't be specified in </FONT>
<BR><FONT SIZE=3D2>&gt;the spec.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;The next draft will use a slightly different =
strategy for the transaction </FONT>
<BR><FONT SIZE=3D2>&gt;ID.&nbsp; As suggested by Thomas Narten, the =
transaction ID in the client's </FONT>
<BR><FONT SIZE=3D2>&gt;Request message can be independent of the =
transaction ID in the </FONT>
<BR><FONT SIZE=3D2>&gt;Reconfigure-init message.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;However, we still have an issue with the =
transaction ID in retransmitted </FONT>
<BR><FONT SIZE=3D2>&gt;Reconfigure-init messages.&nbsp; If the server =
uses the same transaction ID in </FONT>
<BR><FONT SIZE=3D2>&gt;a retransmitted message, how does the client =
differentiate retransmission </FONT>
<BR><FONT SIZE=3D2>&gt;from duplicate messages?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;- Ralph</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;At 04:40 AM 5/31/2001 -0500, Bernie Volz (EUD) =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;I would think that how a server deals with =
this is an implementation </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;issue and should not be covered by the =
protocol. The protocol can </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;accommodate either mode - it really is up to =
the server to deal with </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;this. I would suspect that (1) is more =
likely. Perhaps the most typically </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;implementation may be to send requests to =
&lt;N&gt; clients and then wait for </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;the clients to respond (or timeout) and as =
they do, send additional </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;requests. This avoids flooding the network =
with packets and also staggers </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;client responses some. Approach (2) is =
likely not very good as it would, </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;as you point out, take a very long time if =
there are a lot of clients.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;I don't believe there is any need for the =
transaction id to be the same </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;for all clients (retransmitted requests to a =
particular client should use </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;the same id). Note though that there is =
little reason why the server </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;would necessarily need a new transaction id =
for each client - it could </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;use the same for all clients if it wanted =
to. Again, I think this is an </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;implementation issue.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;- Bernie Volz</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;From: skodati@in.ibm.com </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;[&lt;<A =
HREF=3D"mailto:skodati@in.ibm.com">mailto:skodati@in.ibm.com</A>&gt;<A =
HREF=3D"mailto:skodati@in.ibm.com">mailto:skodati@in.ibm.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt;&gt;Sent: Thursday, May 31, 2001 2:12 AM</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;To: DHCPv6 discussion list</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Cc: bsuparna@in.ibm.com; =
rsharada@in.ibm.com</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Subject: RE: Reconfigure-init message in =
DHCPv6</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;&gt;Per discussions during a design =
team meeting and at the March IETF, we</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;&gt;hope to punt on the multicast =
reconfigure-init support for now.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;Yes, Reconfigure-init will *not* have =
multicast as an option in the next</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;DHCP spec draft.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;- Ralph</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;I have doubt on how does a server send =
RECONFIG message If it tries to</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;reconfigure a network. Does it send</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1) RECONFIG =
to all the clients once, and waits for REQUEST from</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;clients.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Or)</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2)&nbsp; it =
sends RECONFIG messages one by one to all clients and ensures</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;that all clients gets reconfigured. In that =
case the server should wait for</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;RECCREP_MSG_TIMEOUT ( default 2000 ms) for =
REC_MSG_ATTEMPTS ( default 10)</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;times, which means it has to wait for 20 =
seconds for a node, and it may</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;take too long to configure whole =
network.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Is the transaction id is going to be same =
for all messages or different in</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;both the cases.....</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;suresh.</FONT>
</P>

</BODY>
</HTML>
------_=_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 <dhcp-v6@bucknell.edu>; Thu, 31 May 2001 12:24:46 -0400 (EDT)
Date: Thu, 31 May 2001 12:24:13 -0400 (EDT)
From: "Ralph E. Droms" <droms@bucknell.edu>
X-Sender: droms@leo
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Reconfigure-init message in DHCPv6
In-Reply-To: <66F66129A77AD411B76200508B65AC694CBBBC@eambunt705.ena-east.ericsson.se>
Message-ID: <Pine.GSO.4.03.10105311213140.20432-100000@leo>
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 <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



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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <JQ4BVG3W>; Thu, 31 May 2001 11:34:39 -0500
Message-ID: <66F66129A77AD411B76200508B65AC694CBBC2@eambunt705.ena-east.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
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 <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
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: Reconfigure-init message in DHCPv6</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ralph:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;How is this, then, different from my =
proposal?</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>---</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>- Bernie</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ralph E. Droms [<A =
HREF=3D"mailto:droms@bucknell.edu">mailto:droms@bucknell.edu</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Thursday, May 31, 2001 12:24 PM</FONT>
<BR><FONT SIZE=3D2>To: DHCPv6 discussion list</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Reconfigure-init message in =
DHCPv6</FONT>
</P>
<BR>
<BR>
<BR>

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

<P><FONT SIZE=3D2>Another issue is that the client will need to =
remember previous</FONT>
<BR><FONT SIZE=3D2>transaction IDs for some period of time.</FONT>
</P>

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

<P><FONT SIZE=3D2>How is this, then, different from my proposal?</FONT>
</P>

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

<P><FONT SIZE=3D2>Yeah, I agree...</FONT>
</P>

<P><FONT SIZE=3D2>- Ralph</FONT>
</P>

</BODY>
</HTML>
------_=_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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>
cc: bsuparna@in.ibm.com, rsharada@in.ibm.com
Subject: Re: Reconfigure-init message in DHCPv6 
In-Reply-To: Message from Ralph Droms <rdroms@cisco.com> 
   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 <narten@RALEIGH.IBM.COM>
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 <dhcp-v6@bucknell.edu>; 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 <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: Reconfigure-init message in DHCPv6 
Cc: DHCPv6 discussion list <dhcp-v6@bucknell.edu>, bsuparna@in.ibm.com,
        rsharada@in.ibm.com
In-Reply-To: <200105312321.f4VNLJC00966@hygro.adsl.duke.edu>
References: <Message from Ralph Droms <rdroms@cisco.com>
 <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?