On Tue, 2012-05-15 at 09:47 +0200, Dan Luedtke wrote: > > 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!
I agree. We definitely consider this but also other problems. Looking forward to publishing the ideas and discussing it here. Just a note. Current code of NetworkManager for Linux sends RS non-randomized 5 seconds before expiration. Pavel > 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
