Re: question on RDNSS, RFC 6106 part 5.1

[Dan Luedtke <[e-mail]>]

> Since then, router solicitations would be issued regularly until
> client recieves RA with RDNSS, connection is cancelled by user or:

We have a setup here were we have 50+ clients on some access points
with about 100 access points distributed over the campus, all merged
into one network. Let's say we have about 3k clients in the network
which is a good average value. Let us further assume we loose these
three RA before they reach the access points, so that no access point
sends them out. (Of course they usually get lost on some access
points, not on all at the same time, but it might happen in some
situations). Since not all clients connected to the network at the
same time, we assume that one third of them hasn't received the third
RA in a row at some point in time. At this particular point at least
1k clients start sending out RS in a short period of time, at least
until the first RA makes it through. A way of distributing this RS on
a time scale might be a good idea. At some point we should use a
random value to make the hosts delay sending RS with different values

Long story short: Please include Teemu's suggestion (randomization) in
a possible errata. IMHO this must be part of it!

FYI: Although I see the race condition and I would also like to see an
errata on this issue, I'd like to point anyone having problems with
lossy links to RFC 1256, page 3.
> Links that suffer high packet loss rates or frequent partitioning are accommodated by increasing the rate of advertisements, rather than increasing the number of solicitations that hosts are permitted to send.

regards
  Dan
-- 
Dan Luedtke
http://www.danrl.de