Re: Version 6 Question: Client trying to get new parameters

Gernot Riegert <riegert@nm.informatik.uni-muenchen.de> Tue, 16 April 1996 21:34 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23180; 16 Apr 96 17:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23176; 16 Apr 96 17:34 EDT
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa15846; 16 Apr 96 17:34 EDT
Received: from localhost by reef.bucknell.edu with SMTP (5.65/IDA-1.2.8) id AA16575; Tue, 16 Apr 1996 17:20:13 -0400
Date: Tue, 16 Apr 1996 17:20:13 -0400
Message-Id: <Pine.HPP.3.91.960416223411.5604A-100000@hpheger7.nm.informatik.uni-muenchen.de>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
X-Orig-Sender: dhcp-v4@bucknell.edu
Precedence: bulk
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Gernot Riegert <riegert@nm.informatik.uni-muenchen.de>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: Version 6 Question: Client trying to get new parameters
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
Mime-Version: 1.0

On Fri, 12 Apr 1996, Charlie Perkins wrote:

> 
> > In the latest draft concerning DHCPv6 the way to reconfigure at least one 
> > DHCP client is that the server sends a DHCP Reconfigure message to the 
> > host(s) with the parameters that have to be changed.
> > 
> > But what if a client states that some of its parameters aren't valid 
> > anymore? In the draft, I don't see how a client can ask for a new 
> > configuration if the old one doesn't "fit" any more besides cancelling 
> > his connection. So, the client is urged to start a new configuration 
> > process, which is rather superfluous in my oppinion. 
> 
> The client can ask for a new configuration whether or not its
> old configuration fits, although I'm not sure exactly what "fit"
> means here.  Can you give some more concrete examples?  In the
> worst case, when the client cannot identify to the server anything
> about its old configuration, presumably the server will just carry
> the old configuration as excess baggage until it expires.  Part of
> our job with DHCPv6 will be to minimize the number of cases where
> such excess baggage cannot be eliminated.

I am thinking of situations where some configuration parameters change 
(e.g. a printer is under repair and the client knows only this printer 
as line printer or perhaps you just want to reconfigure some of your 
configuration parameters from the client's side - think of renumbering 
or mobile systems like laptops)  In my opinion, these scenarios are not 
described clearly enough in the draft. My question was mainly whether the 
client can say "hey server, give me some new parameters for my current 
lease" or if he just can send a DHCP Release and restart the 
configuration process. I could imagine that the client just sends a new 
DHCP Request with the extension for "give  me a new printer adress", but 
I can't read this imagination out of the DHCPv6 draft.   

> > > Gernot Riegert 

> > Charles Perkins
> 

and again Gernot Riegert