Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6

From: Changming Liu <[email-masked]>
Date: Tue, 2 Mar 2004 17:31:09 -0800

For unplanned change, how can you set the lifetime? The solution should
work for both planned and unplanned changes. The unplanned changes are more
demanding. Please see the scenario described in my previous email.

For reconfig, we already have one defined, but unicast only. So the
infrastruture should be there.

 It only problem is it's unicast which does not scale well. The problem is
well defined in this draft and no need to repeat here.

Changming

-----Original Message-----
From: Ted Lemon
To: Changming Liu
Cc: 'JINMEI Tatuya / ???? '; [email-masked] '; 'Tim Chown '
Sent: 3/2/2004 4:01 PM
Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6

Why would the lifetime solution cause packet storms?  We don't have 
similar problems with similar protocols.   Choosing a lifetime is easy, 
and you can adjust the lifetime when you plan a change.   I don't 
understand the objection.

Reconfigure would work, but it opens a vulnerability on the client 
(which now has to be listening for DHCP messages all the time), and 
requires a lot more infrastructure support than the lifetime solution.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Mar 2004 12:41:06 +0900

> demanding. Please see the scenario described in my previous email.

Your scenario seems like a configuration error.   Setting things up so 
that the client has to update DNS server information immediately on a 
frequent basis is simply bad network design.   I don't think the goal 
of this renumbering effort is to accommodate that kind of 
configuration.   The right way to fix this is to put a DNS cache 
downstream of the flaky link.

It's true that the mass-reconfigure solution would make your problem 
less bad, but it wouldn't make it go away - your clients would still 
experience flakiness.   The reason is that, first of all, a running 
application may not notice that the configuration has changed, even if 
the client on which it is running gets a Reconfigure and successfully 
reconfigures.   Secondly, there is always going to be a time lag 
between when your network configuration changes and when all the 
clients have been reconfigured.   This lag is the sum of the time it 
takes for your system to notice that the network configuration has 
changed and the time that it takes for any given client to actually 
complete the reconfiguration process after it has been notified.   
During this window, all DNS lookups will fail, even for new 
applications that haven't cached DNS server information.

So I think that your scenario isn't actually a good justification for 
doing reconfigure - yes, reconfigure makes it less bad, but no, it 
doesn't solve the problem.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 3 Mar 2004 07:41:49 +0100

> downstream of the flaky link.
[...]

My thinking is that with a network or environment that is known to be
unstable and with not too many clients, you can set the lifetime to a
small value. It might be okay to set it to small values like 10 minutes.
It's rather short, but with few hosts it wouldn't really be a problem.

I guess you could come up with cases where you need things to change
immediately. I agree that lifetime doesn't help you then. In addition
it would help if hosts make a new request when RAs give you a new
prefix or perhaps if host is connected to new link.

To fully solve the unplanned change case you need reconfigure. The
question is whether it's worth the cost. I'm not sure you can do that
safely without state on server.

Stig