Subject: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug?

From: Tim Chown <[email-masked]>
Date: Thu, 13 Nov 2003 19:11:45 +0000

Hi,

I was mulling over the renumbering scenario for hosts that use
stateless autoconf for address allocation and DHCPv6 Light (stateless
DHCPv6) for DNS options.

Let's assume either the site renumbers, or the DNS servers are
renumbered.   The latter case means that you can't just use a new
prefix on an RA as a hint to re-request DNS options via DHCPv6 Light.

With an RA method for DNS option configuration, you put the new DNS
option information in the RA.

With DHCPv6 Light for DNS option configuration, how is the client told
that DNS options have changed?  The reconfigure message seems to be
unicast to the clients, but if the DHCPv6 server is stateless, it won't
have a list of clients (with leased IPs) to send that Reconfigure
message to?

Is this a general problem for any options set by a host that only uses 
stateless DHCPv6 for options, and use RFC2462 for addresses.

One option for passing the new DNS options from the DHCPv6 Light server
to the client is a multicast Reconfigure message.    That would work 
if the DHCPv6 Light server is on link, but if relays are used and there
is no multicast routing on site, this seems to be a gap (and a case for the 
RA method - though of course with RA method you still need to reconfigure 
the router for the new RA...)

Thoughts?

Tim

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

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Fri, 14 Nov 2003 05:12:05 +0900 (JST)

On Thu, 13 Nov 2003 19:11:45 +0000,
> the router for the new RA...)

Both setting the trigger of re-request on renumbering of prefix in RA,
and a multicast Reconfigure message might cause all nodes to rush on
the single DHCPv6-lite server for information-request reply exchange.
It could work with small number of clients though.

Periodical information-request from client side as Ralph suggested,
and multicast advertisement of DNS option itself (w/ DHCPv6-lite, RA, SLP)
seems to work with large number of clients.

--
SHIRASAKI Yasuhiro

---

From: Vijayabhaskar A K <[email-masked]>
Date: Fri, 14 Nov 2003 01:46:30 +0530

I guess, "stateless" means the server doesn't need to maintain the 
lifetime of the configuration information it has assigned to the clients 
and it doesn't mean that it doesn't need to maintain the information 
about the clients..

The proposal of sending multicast reconfigure message was discussed, but 
it was dropped as its very difficult to achieve multicast security and 
reconfigure mechanism mandates auth...

Vijay

-- 
__________________________________________________________
Vijayabhaskar A K            Phone : +91-80-2053085
Hewlett Packard              Mobile: +91-9845241382
29 Cunningham Road           Telnet: 847-3085
Bangalore 52                 Email : [email-masked]

Until you have the courage to lose sight of the shore,
you will not know the terror of being forever lost at sea.
 __________________________________________________________

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Nov 2003 20:59:31 +0000

> It could work with small number of clients though.

I guess you could add some random delays, but you should also scale your
DHCPv6 server provision to have multiple servers?

I guess we can say that:

(1) Automatic renumbering is broken if people hard-code data in clients

(2) If a secure environment for reconfigure is needed, a multicast message
    adds some complexity

(3) The Reconfigure message is really designed for a fully stateful DHCPv6
    environment, not a purely stateless one providing options info (?)

(4) Periodic polling of the DHCPv6 server by clients allows renumbering
    but is not a full solution for more rapid (unplanned) renumbering.

(5) There isn't really a ethod now for a client to be informed of a
    renumbering event of a stateless DHCPv6 option (DNS, NTP)

(6) We don't want to use RA method because that would also mean an NTP
    extension for RA (?)

(7) If the network renumbers, statelessly configuring hosts should/could
    use the new prefix seen on an RA as a hint to re-request DHCPv6
    options if the O bit is set.

So is something overlooked, or do we not feel we need a solution to (5),
given we could use (7)?   Not sure how explicit (7) is...

Tim

---

From: Vijayabhaskar A K <[email-masked]>
Date: Fri, 14 Nov 2003 02:55:20 +0530

Stig Venaas wrote:

>On Fri, Nov 14, 2003 at 01:46:30AM +0530, Vijayabhaskar A K wrote:
>  
>
>But it's certainly an advantage not having too.
>  
>
Considering the disadvantages due to mutlicast reconfigure, the gain is 
less...

>You could have DHCP server multicast reconfigure to relays, that then
>use link-scope multicast to send reconfiguration to the clients. DHCP
>server could also possibly have a list of relays and use unicast to
>the relays.
>
>Security shouldn't be a problem I think, you're only asking clients to
>send requests, you're not giving the clients any config information.
>  
>
An intruder relay can trigger the clients to initiate the renewal of 
config info by sending the reconfigure message, leading to flooding of 
dhcp packets from all the dhcpv6 client nodes and DoS attack on the 
server... Thats the reason why Reconfigure message needs to be 
authenticated...

Vijay

---

From: Vijayabhaskar A K <[email-masked]>
Date: Fri, 14 Nov 2003 02:59:33 +0530

>    but is not a full solution for more rapid (unplanned) renumbering.
Though, rapid renumbering is not more likely to happen, periodic polling 
will take some network bandwidth,

>given we could use (7)?   Not sure how explicit (7) is...

I guess, (7) is better than inventing a solution for (5)... The client 
can assume the prefix change mean, there is a very good chance that some 
of the configuration information may have changed and it can go ahead 
and initiate re-request in the case O bit is set in RAs..

Vijay

---

From: Stig Venaas <[email-masked]>
Date: Thu, 13 Nov 2003 21:55:38 +0100

Stig

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Nov 2003 14:05:11 -0600

On 13-nov-03, at 13:11, Tim Chown wrote:

> that DNS options have changed?

Operationally, you'd probably have to support these addresses forever. 
Not just because of DHCP issues but also because users tend to jot down 
dynamic stuff and then hardcode it. (For instance for hosts that don't 
support dynamic DNS discovery (which obviously are almost all of them 
today (in IPv6)).)

> to the client is a multicast Reconfigure message.

Hm, I can already imagine the posters on the men's room at IETF 63: 
"whoever is sending "reconfigure DNS" multicast messages every second, 
quit it as the 1200 DHCPv6 requests per second are killing the wireless 
performance".

There are DoS issues here.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 13 Nov 2003 22:40:47 +0100

> server... Thats the reason why Reconfigure message needs to be 

Ah ok, I see. One could possibly do authentication for multicasted
messages too, but the current authentication method wouldn't work
I think.

Stig

---

From: Vijayabhaskar A K <[email-masked]>
Date: Fri, 14 Nov 2003 04:04:16 +0530

>messages too, but the current authentication method wouldn't work
There is some work going on multicast security,
http://www.ietf.org/html.charters/msec-charter.html
It could be used here...

Vijay

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 14 Nov 2003 09:13:42 -0500

There was some discussion about adding a "configuration lifetime" option for
Information-Request/Reply messages. This would be similar to the address
lifetimes and the idea would be that this would give the client an
indication of when to obtain updated configuration information. While this
does not solve the problem completely, it would help solve the problem when
scheduled changes in the network are planned.

We may also want to have clients that initiate an Information-Request after
detecting a configuration change that may invalidate existing information
(such as prefixes in configuration information that are no longer valid) use
a random delay before sending the Information-Request (just as they would
for the 'first' Information-Request). Perhaps this just means clarifying
what is meant in section 18.1.5 (RFC 3115) by first:

   The first Information-request message from the client on the
   interface MUST be delayed by a random amount of time between 0 and
   INF_MAX_DELAY.

There are also larger issues here when renumbering happens as the client may
need to its DNS information (dynamic DNS), etc. So, when renumbering happens
(new addresses are added or old ones are deprecated), the client needs to do
some thinking and one of the outcomes is to obtain updated configuration
information.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
Chown
Sent: Thursday, November 13, 2003 4:00 PM
To: SHIRASAKI Yasuhiro
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug?

I guess we can say that:

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Nov 2003 07:24:06 +0900

Tim Chown;

I think that it is silently assumed that DHCPv6-lite is configured
of DNS server addresses without relaying requests to others.

That is, reconfiguration upon renumbering is necessary.

Or, DHCPv6-lite may be (pre)configured with well known addresses,
as I suggested at the last meeting.

But, let's assume relaying is performed, which is a likely scenario
on "stateful" cases, anyway.

> the router for the new RA...)

W.r.t. inter-link multicast, what multicast protocols is intended
to be used by people in DHC WG?

If it is CBT, PIM-SM or SSM, what happens if CORE, RP or SS crashes
or is renumbered?

Is a well known unicast address is assigned to a primary and
a back-up CORE/RP/SS, which means ANYCAST.

Is DVMRP assumed, instead?

Or, will we wait until yet another multicast protocol is
standardized, hoping that it will solve all the problems?

Assuming that some multicast protocol solves all the
problems, another question is on multicast address.

Is it a well known multicast address? If so, is there any
configuration necessary at a site (or something like that)
border router? If so, what happens if a customer want to relay
DHCP request to ISP's DHCP server? What happens the border
router is wrongly configured?

						Masataka Ohta

PS

It seems to me that relying on multicast does not solve but merely
refer the problem, which is better solved at the point (protocol)
where it is observed.

---

From: Stig Venaas <[email-masked]>
Date: Sun, 16 Nov 2003 12:35:24 +0100

On Fri, Nov 14, 2003 at 07:24:06AM +0900, Masataka Ohta wrote:
> >is no multicast routing on site, this seems to be a gap (and a case for 
> >the RA method - though of course with RA method you still need to 
> >reconfigure the router for the new RA...)

I'll comment on your mail, but let me first present how I suggest
it be done.

I suggest for server to send reconfigure to clients via relays.

>From server to relay:

    If multicast routing available in the site:

	site scoped multicast from server to relays

    If multicast routing not available in the site:

	unicast to each relay, server has a list of relays

Then from relay to client you can always use multicast on link.

Reconfigure messages should be protected due to possible DoS
attacks. I didn't consider that at first. I think that can be
done using public key crypto. Server has a single key pair.
Clients get public key together with the config info, and the
reconfigure message is signed with the private key.

Now to your comments.

> to be used by people in DHC WG?

I'm not sure that should be specified. At least as long as it
isn't SSM, the DHCP infrastructure is completely independent
of which multicast protocols are used, just like other
multicast applications.

> If it is CBT, PIM-SM or SSM, what happens if CORE, RP or SS crashes

Interesting question. It's relatively easy with standard
PIM-SM. You only need to reconfigure the RP address on the
routers, and if you use say BSR, you only need to change on
the c-BSRs and c-RPs. And only within the site. There are
also ways to secure multicast against RP crashes etc.
Discussion on multicast reliability and renumbering could be
a good topic for mboned wg. It doesn't belong here.

For SSM, relays would need to know unicast addresses of DHCP
servers, and if you do reconfigure with multicast, you also
need servers to know unicast addresses of relays. Then you
might as well use unicast.

> a back-up CORE/RP/SS, which means ANYCAST.

Anycast might be used

> Is DVMRP assumed, instead?

Nothing is assumed I think.

> problems, another question is on multicast address.

I think multicast works pretty well, but this should rather
be discussed in mboned.

> Is it a well known multicast address? If so, is there any

Yes

> router is wrongly configured?

Of course things can be wrongly configured, but most things
can break then. If you want to relay DHCP requests out of the
site, the best is to use unicast between relay and server I
think, using site multicast is only an option.

Stig

---

From: Thomas Narten <[email-masked]>
Date: Tue, 18 Nov 2003 12:55:12 -0500

> have a list of clients (with leased IPs) to send that Reconfigure

note that there are issues with unicast reconfigure. During the IESG
review of the DHCv6 spec, concerns were raised about the
appropriateness of _requiring_ that all nodes have an open port on
which DHC messages could be sent. This is viewed as a security
issue. E.g., for security reasons, some sites require that clients
have no open ports on which they are listening for arbitrary packets
from anyone. Consequently, the DHCPv6 spec was revised to make the use
of this feature more of a negotiation between the client and
server. See the RFC for details.

Point is, requiring that a node always be ready to receive an
asynchronous message from an arbitrary DHC server is potentially
problematical in practice.

Personally, I think something along the lines of Bernie's suggestion
seems the simplest. E.g., just define a lifetime that applies to all
options that don't themselves have a lifetime.  Client can then
recheck at appropriate intervals.

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Nov 2003 22:39:53 +0000

> server. See the RFC for details.

There may be other methods to give the hint for a (RFC2462) client to send 
a new (options) request to the (stateless) DHCP server.   This might involve
something in an RA, some new form of Reconfigure message (although I can see
this isn't favoured, it is specified for stateful servers to use), or some
other method.

> recheck at appropriate intervals.

A timer is an improvement; at least then the timer could be tuned down a
bit like DNS TTL for a planned renumbering event, or for simpler events
like adding a new NTP server or changing the DNS search path.

Attached is a draft that I've just submitted describing the problem
statement.  Vijay and Stig are both working on proposals for solutions.
It would be great to get your input on those based on the IESG discussion
experience (for example on the security requirements).

The problem/gap is a bit broader then just site renumbering, so the draft
name is not ideal.

Tim

---

From: Stig Venaas <[email-masked]>
Date: Mon, 17 Nov 2003 23:46:23 +0100

> >I suggest for server to send reconfigure to clients via relays.

After some thinking I see that this is much harder than I first
anticipated (like always...). I'm still thinking about it, but
it's not easy.

> "site" is not a useful concept for autoconfiguration, when
> the "site" is really small, which is, perhaps, the primary
> target case of "stateless", which is why I asked multicast
> over site boundaries.

Yes, I also see cases where it wouldn't work. Unicast to relays
have advantages, also wrt to security. Only issue is that server
will need to know their addresses.

> is a rational approach for either case.

I may agree. I'm trying to think of good ways to do reconfigure.
For now I think I'll do more thinking of that before I go into
possible solutions. As I said above it seems to be rather complex.

> Of course, the server have a stable storage.
> 
> However, some says "has a list of relays" is a "stateful"
> approach and is no good.

Yes, my feeling too.

> Lack of well definedness of "stateless" is making design and
> discussion very hard.

Yes. I would say that the DHCP server has configuration state,
but no dynamic state. A static list of relays is not ideal, but
might be ok. There are levels of dynamic state too though, it
should be avoided, but I feel the most essential is to not
require state through restarts/reboots. If reconfigure requires
state, it may be better to forget it.

> It is unreliable that relays also should have lists of clients
> and stable storages or the server directly take care of the
> clients, in either of which case, unicast is good enough.

Yes, relays should not have lists of clients. I'm not insisting
on multicast in itself, but multicast is the only way I see to
avoid having per client state.

> Sorry, public key crypto is computationary expensive that it
> rather amplifies than prevents DoS effect.

Yes, that is a good point.

> With your case, reconfigure messages with bogus signature will
> force clients perform expensive public key crypto computation.

Yes. It can avoid DoS attack on DHCP server (because all clients
do reconfigure), but it puts a big burden on clients. This is a
problem.

> I asked not "specified" but "intended".

I can't speak for people's intentions, but I don't expect people
to have given it much thought. I may be wrong. But SSM will not
work with current spec. Current spec allows site multicast to be
used, but doesn't require it. So I would say it's up to the
implementor and administrator.

> >the c-BSRs and c-RPs.
> It is more straight forward to change addresses of a DHCP server
> on relayes to be used for unicast relaying. However, a DHCP server
> is a single point of failure.

I don't agree on this. And if you have multicast deployed, you
will make sure that works as well.

> I'm afraid it is not an attractive idea to involve yet another
> WG in the thread.

I agree, and I'm removing dnsop from this one. I don't think they
are interested in these details. But if you want to discuss
multicast and renumbering in general, you could if you like
create a new thread on mboned and not mention DHCP. Well, just a
suggestion. My point is that discussions on that problem is
much better in that group. There is more expertise there, and
I'm not sure how interested people are in dhc...

> Yup. But, is it "stateless"?

Not sure, I would like to avoid it though. It for sure adds
complexity to implementation.

> An interesting fact is that there are someone who don't want to
> use "anycast" for DNS servers, because it intermingles DNS and
> routing system. However DNS servers by DHCP with multicast is 
> already eaqually bad. Then, are we having DHCP with multicast
> with anycast CORE/RP/SS?

I'm not too sure about using anycast myself. But if you use
anycast for RP, that's limited to the network. But let's not
discuss how to make multicast reliable here.

> Sure. However, mboned is the worst place to discuss "multicast
> does not work at all".

Well yes, people may not like it (; But there are people there
that think that multicast could be improved. And I'm not sure
renumbering has been given much thought.

> My intention here is to demonstrate that, with multicast, routing
> and DHCP are intermingled.

I would say that multicast and routing is in the network, while
DHCP is an application making use of multicast and routing.

DHCP may use site-scoped multicast if available, but it's not
required. However link-local multicast is required for IPv6 in
general, also DHCP.

Stig

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 18 Nov 2003 00:57:01 +0900

Stig;

> I'll comment on your mail, but let me first present how I suggest

Thanks.

Note also that "site" local unicast addresses are to be
deprecated.

Moreover, multicast is unreliable unless the server have a list
of relays, unless unicast ACK is returned from each relay.

And, then, use of multicast reduces the number of traffic
by half (ignoring frequent multicast control traffic some are
broadcast over a domain), which is not essential.

So,

 

When we want to analyse specific application, we must take into
account all the layers to calculate number of packets, periods
of delay, redundancy, security etc.

> And only within the site.

"site" is not a good idea.

> There are

This type of approach improve reliability for certain
types of failure but does not improve or rather disimprove
reliability for other types.

 

> can break then.

Yes.

> If you want to relay DHCP requests out of the

And, multicast is not a useful option, which means we need something
for redundancy.

						Masataka Ohta

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 18 Nov 2003 19:41:25 -0500

Tim/Ralph:

Personally, I'd prefer we take two approaches to address these problems
(text taken from Tim's document, section 5):

   o  Conveying a valid lifetime timer to clients for stateless
      DHCPv6-assigned settings.  This could primarily enable planned
      events, but with a small time-out it could to some extent handle
      unplanned events at the expense of the additional request traffic.

   o  Using some form of Router Advertisement as a hint to request new
      stateless DHCPv6-assigned settings.  Using only an observed new
      Router Advertisement prefix as a hint to re-request settings would
      not handle changes that are purely to NTP, DNS or other options.

The first handles planned changes. The second handles renumbering. For the
second case, the client SHOULD send an Information-Request when any prefix
for an address conveyed in the last Reply transitions from a) preferred to
valid (i.e., preferred lifetime expires) or b) is no longer valid (i.e.,
valid lifetime expires). [I'm not certain how easy this is to implement in
most operating systems, but periodic polls by the DHCP Client can probably
discover these changes within reasonable time periods. Note that care must
be taken for the client not to consider prefixes it knows nothing about.]

There is no mechanism to address unplanned changes (such as changing a DNS
server's address as discussed in 3.2). But, that's where redundancy comes in
- by having multiple servers a client can contact, this problem can be
minimized (until the "valid lifetime timer" expires). This IS covered by a
client (and server) supporting Reconfigure in the Information-Request case -
RFC 3315 does not prohibit this in an Information-Request (and Appendix A
shows it is allowed). So, in essence, all THREE of Tim's Section 5 possible
solutions are available. It would be optional, because as Thomas indicated
there are security concerns for forcing a client to listen for unsolicited
traffic (and a server may also choose not to support it).

So what actions are needed?

1. Someone needs to publish a "valid lifetime" draft. Tim, are you planning
on doing this? Ralph?

2. Words should be added to draft-ietf-dhc-dhcpv6-stateless-01.txt to
recommend (SHOULD?) that clients use certain events to trigger resending
Information-Requests (see above and also the triggers for sending Confirm
messages in RFC 3315?).

3. Perhaps the stateless draft should also add words to the effect that
supporting Reconfigure has advantages. Personally, this is where my view of
what draft-ietf-dhc-dhcpv6-stateless-*.txt should discuss and what it does
differ. I don't feel it should say that DHCP servers and clients are
stateless, just what is required when DHCP is NOT used for address
allocation (because stateless address configuration is being used in the
network). I believe this ONLY impacts text in the Abstract and section 1,
Introduction, of draft-ietf-dhc-dhcpv6-stateless-01.txt.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
Chown
Sent: Tuesday, November 18, 2003 5:40 PM
To: [email-masked]; [email-masked]
Subject: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug?

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Nov 2003 17:01:10 +0900

Stig;

> avoid having per client state.

Even if you use multicast, the addresses are necessary, anyway, to
confirm receipt of notification.

> will make sure that works as well.

BSR assumes that all the routers cooperate, which is not a case
when an ISP and its subscribers constitute a domain. There are
maliciousy or wrongly configured routers at subscribers.

It should also be noted that an RP with forwarding functionaliry
disabled may still announce its precense as an RP to a BSR, which
means there is no real robustness.

Intradomain multicast has its own area of application. However,
the area is a lot smaller than one might expect and does not
contain real robustness.

Other protocols should not simply expect the area satisfies
its requirement.

> But let's not

Just accept that it is not reliable.

> that think that multicast could be improved.

That is the problem.

When I overturned their grand design on interdomain multicast
by proving that multicast routing table can not be aggregated
(distribution of receivers of adjacent TV channels is no
identical, so are of those of adjacent multicast addresses. See
my paper presented at INET'98 for furthere details), such
people tried to (and still trying, perhaps) *IMPROVE*
multicast to make the impossible possible.

> required.

It is required that all relay implimentations have code
supporting multicast, because no server addresses may be
configured.

Do you recognize that control traffic of interlink multicast is
often a lot lot more than that of applications like DHCP?

> However link-local multicast is required for IPv6 in
> general, also DHCP.

Link local multicast is a lot simper than interlink ones and just
works. Howvever, it works because broadcast works and broadcast
is just enough. Note, for example, that there is no IGMP snooping
on link local multicast that packets are broadcast to the entire
link. So, there is the amount of link bandwidht is same.

So, don't expect multicast too much.

Instead, I think it is necessary for DHCP WG to develop guideline
on robust relaying without relying on multicast.

For example, is the behaviour of relay with multiple unicast
addresses of servers specified somewhere?

					Masataka Ohta

---

From: Stig Venaas <[email-masked]>
Date: Wed, 19 Nov 2003 14:28:52 +0100

I've now submitted the draft draft-venaas-dhc-lifetime-00.txt on a
lifetime timer. Which is one of the options in Tim's document. I
also think this is one of the better approaches.

Draft is attached.

On Tue, Nov 18, 2003 at 07:41:25PM -0500, Bernie Volz wrote:
[...]
> 1. Someone needs to publish a "valid lifetime" draft. Tim, are you planning
[...]

So this is done (:

I have some open questions.

What should client do if it can't update the configured data. I strongly
feel it should keep it and retry. But how often. Can it be a function of
the lifetime, or would we need an additional value?

When should client add it to the option request list and when should
server put it in replies. I have some SHOULD/MAY text which may need
to be changed.

The usage should be pretty clear. In unstable environments the value
can be set to a small value. If a renumbering or other changes are
planned, the administrator can gradually decrease the value, similar
to DNS and ttls.

Hope for some discussion on this and related topics.

Stig

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 19 Nov 2003 09:24:48 -0500

>the lifetime, or would we need an additional value?

RFC 3315, section 18.1.5, already covers the sending and retransmission of
the Information-Request. I think that the client should keep retrying (just
as if it was booted and was trying to obtain configuration information
initially). The only difference being that the client SHOULD continue to use
the information it has until it is successful in updating the information
and refreshing the lifetime.

I also feel that the client MUST use a random time delay before sending the
first Information-Request after the valid lifetime expires. Think of the
situation where all the clients are time synchronized ... if the server sent
a lifetime based on an absolute time of when a configuration change was
scheduled or all of the clients booted nearly at the same time, the server
could be flooded with lots of requests (as INF_MAX_DELAY is one second and
most clients will likely use timers with 1 second resolution, they may all
detect the expired lifetime simultaneously).

>server put it in replies. I have some SHOULD/MAY text which may need

I think what you have is fine.

>planned, the administrator can gradually decrease the value, similar

I think adding something about this to the draft would be beneficial.

It might also be worth while to move the text in the Introduction about how
a client uses this information to a separate section.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stig
Venaas
Sent: Wednesday, November 19, 2003 8:29 AM
To: Bernie Volz
Cc: 'Tim Chown'; 'Ralph Droms'; [email-masked]
Subject: Re: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug?

Draft is attached.

[...]

So this is done (:

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 19 Nov 2003 15:52:06 +0100

> and refreshing the lifetime.

Sounds good.

> detect the expired lifetime simultaneously).

I thought about this. My thinking was that the initial requests were not
replied to simultaneously, so it would be ok. But you're quite right.

So, after expired lifetime is detected, the request should be delayed a
random time between 0 and MAX_DELAY, what should it be? Can we use
INF_MAX_DELAY so that the entire update process (both first message and
retries) are as in 18.1.5? A larger value would be fine too though, and
perhaps safer.

> I think adding something about this to the draft would be beneficial.

Will do.

> a client uses this information to a separate section.

OK. I'll wait a bit for other comments, and probably post rev 01 soon.

Thanks for comments,

Stig

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 19 Nov 2003 11:00:15 -0500

>retries) are as in 18.1.5? A larger value would be fine too though, and

I think INF_MAX_DELAY would be fine. The point is to desynchronize the
requests and that will do the trick. If the server is still overloaded, the
retransmissions will handle that as those clients that failed to receive a
response will just retry.

- Bernie