Hi, We have seen this same problem as well.
Does anyone have any idea why the lifetime is bound with SHOULD to this very short time period? For example, if the Lifetime == MaxRtrAdvInterval, a host often would effectively be forced to send RS to refresh the RDNSS information before RDNSS expiration? Also in Lifetime == 2*MaxRtrAdvInterval, a single lost RA (or in some case maybe two) could force host to send RS. Another question is that does anyone know why the time for sending RS is not specified? To help avoid simultaneous sending of RS by many hosts (if nobody got periodic RA)? I.e. could it be, say, 1.7*MaxRtrAdvInterval with random(0.2*MaxRtAdvInterval) delay to avoid hosts sending RS'es simultaneously? If this is agreed to be an issue, could we do ERRATA that extends the lifetime and specifies better when RS should be sent for information refreshing? Best regards, Teemu 20. huhtikuuta 2012 0.10 Pavel Šimerda <[email protected]> kirjoitti: > Hello, > > I'm starting my work on linux NetworkManager. I've been following > several bugreports during the recent months that all lead to problems > with maintaining the list of recursive nameservers. > > I've already spent quite some time analyzing RDNSS problems and I came > to a conclusion that the problem actually lives in the RFC itself. > > Please look at section 5.1. in RFC 6106. It states: > > MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval > > Considering MaxRtrAdvInterval the maximum time between RAs, setting > Lifetime to MaxRtrAdvInterval IMO constitutes a race condition. > Moreover, any Lifetime in this interval can timeout with just one or two > lost RAs. > > This makes RA-based IPv6-only networks drop RDNSS regularly. In many > implementations IPv6 and IPv4 are bound together so that if one of them > fails, the whole link is restarted. This is also the case in > NetworkManager. > > In the current situation, it's not advisable to use RFC 6106 in > production because it can cause problems even to IPv4 applications. > > In the real world, radvd uses Lifetime=MaxRtrAdvInterval by default and > NetworkManager internally adds 10s to the lifetime, that only helps to > avoid the race condition but not lost packets that are common on > wireless networks. > > I appreciate any help to get this right both in the standards and in the > software. > > Cheers, > > Pavel Šimerda > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
