Subject: RE: Issues regarding server-inituated client configuration (Recon figure-init) from San Diego

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 6 Feb 2001 18:48:56 -0600

Ralph:

I think the list is accurate (I'm pretty sure the authentication issue also was raised).

Could some of the multicast reconfiguration problems be solved by:
1) Allowing only link-layer multicasts to be processed (hence, off link requests aren't possible; relays must be used to transmit reconfiguration on a link - this does raise a security issue such that relays only accept messages from proper servers, but that should be possible to handle with IPsec for communications between relay and servers).
2) As there is probably no need to have clients 'immediately' reconfigure, having clients wait a random time interval before responding and making the range something like 60 to 600 seconds. Yes, this means clients will wait at least a minute before reconfiguring. (These values could easily be adjusted.)
3) If multiple reconfiguration requests are received, they are ignored until the client has acted on the first. (And, of course, duplicates are ignored as well.)

Now, what this means is that even if some rogue system is sending multicast reconfigure events, it can't generate a large amount of traffic, since:
- Sending more often than every 60 seconds is meaningless (these are ignored by all clients).
- Sending at that rate, only impacts a very small percentage of the clients (as, on average, half the clients will have acted within 360 seconds)

Thus, very little traffic can be generated. Sure, clients might unnecessarily reconfigure, but that doesn't generate a lot of traffic (on average, each client will send 10 reconfigures per hour worst case).

I guess if you do put thousands of clients on a single 'lan', you can generate a bunch of traffic. But, that network layout is very uncommon and not very effective anyway.

One problem the above doesn't solve is if there are many servers generating the multicast reconfigure requests (since my assumption was the behavior was per server, not for all servers).

Note: If faster reconfiguration times are desired, unicast messages would be used (it won't get all the systems, but at least those the server knows about).

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, February 05, 2001 11:16 AM
To: DHCPv6 discussion list
Subject: Issues regarding server-inituated client configuration
(Reconfigure-init) from San Diego

This was originally the first part of a longer message.  I split that long 
message into two shorter messages to encourage prompt response to either or 
(preferably!) both messages.  Please take a quick look at this first 
message and respond with comments (or with an ACK if you think the list of 
issues is accurate and complete).

In the discussion about reconfiguration at the San Diego IETF, the 
following issues were raised:

* Multicast reconfiguration would be a good thing
* Multicast reconfiguration is required in the case
   where the server does not have a complete list of
   clients; e.g., if the server has been
   delivering configuration information but not
   assigning addresses and has not recorded a list
   of clients that have contacted the server
* Multicast reconfiguration requires additional
   consideration of scaling issues to avoid server
   failure in the event of multiple simultaneous client
   responses
* Clients must be made resilient against the receipt
   of multiple copies of a Reconfigure-init message;
   e.g. because there are mulitple relay agents on the
   link or because the Reconfigure-init message
   was duplicated in transit
* There must be an authentication mechanism that is
   compatible with both unicast and multicast to avoid
   denial of service attacks.

Is this a complete list of issues raised in San Diego?
(I'm not sure we raised authentication in San Diego, but
the problem has to be solved...)
- Ralph