Hi, So how do we proceed from here?
Would it be enough to discuss and agree an errata for the RFC? Doing full RFC6106bis might be overkill. Chairs? Best regards, Teemu 2012/4/27 Pavel Simerda <[email protected]> > Hello, > > my proposition is the same as Teemu's or very similar. > > 1) I propose to change the default Lifetime from > [MaxRtrAdvInterval, 2*MaxRtrAdvInterva] to a single > agreed-upon recommended default value. Almost nobody > would need to change this default value. > > 5*MaxRtrAdvInterval is IMO a good value to start with. This should > be enough to avoid the need to send RS. > > 2) I propose to add at least some best practice about router > solicitations. Typically, RS should only be used as a last resort. > > I suggest to start sending RS at 0.8*Lifetime +/- 0.1*Lifetime (if > sending RS at all) and repeat let's say every 10-20 seconds. > > Note: > > Please remember that wireless links *sometimes* lose packets. Please > remember that wireless links *often* lose multicast packets. Even > some ethernet switches do. > > Example: > > MaxRtrAdvInterval = 10 minutes > AdvRDNSSLifetime = (Default) 5*MaxRtrAdvInterval = 50 minutes > 0.8*Lifetime = 40 minutes > 0.1*Lifetime = 5 minutes > > Let's simplify the situation and act as if MaxRtrAdvInterval is the > absolute interval (it is not!). > > 00:00 Router Advertisement, Lifetime = 50 minutes > 00:10 Lifetime = 40 minutes (it could already time out according to the > current RFC) > 00:10 Router Advertisement (lost) > 00:20 Lifetime = 30 minutes > 00:20 Router Advertisement (lost again) > 00:30 Lifetime = 20 minutes > 00:30 Router Advertisement (lost the third time!) > 00:35 Lifetime = 15 minutes > 00:35 This is the first time RS can be sent with this best practice > (the last time is 00:45, counted like that 0.8*00:50 +/- 0.1*00:50) > 00:35 Router Solicitation > > Since then, router solicitations would be issued regularly until > client recieves RA with RDNSS, connection is cancelled by user or: > > 00:50 Lifetime = 0 > 00:50 RDNSS expired > > Note: > > It is not perfect. The concept of finitely valid RDNSS is quite new. > There is an open question, when to consider RDNSS information lost. It > could be: > > 1) Last RDNSS from RAs expired. > 2) Last IPv6 RDNSS expired (RDNSS or DHCPv6) > 3) Last RDNSS lost (IPv6 or IPv4) > > Pavel Simerda > > > On Thu, 2012-04-26 at 14:00 +0200, Ole Trøan wrote: > > Pavel, > > > > I concur with your description of the problem. > > do you have a proposal for how it can be solved? > > > > Best regards, > > Ole > > > > > > On Apr 19, 2012, at 23:32 , Pavel Šimerda wrote: > > > > > 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 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
