I believe Fernando will forgive me. For the curious, an *unofficial* version of our work can be found here:
http://git.pavlix.net/gitweb/?p=rdnss.git;a=summary Cheers, Pavel On Mon, 2012-05-14 at 15:37 +0300, Teemu Savolainen wrote: > 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 <pav...@pavlix.net> > 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 > > > ipv6@ietf.org > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
