Re: question on RDNSS, RFC 6106 part 5.1

[Pavel Simerda <[e-mail]>]

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 <[e-mail]>
>         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
>         > > [e-mail]
>         > > Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
>         > >
>         --------------------------------------------------------------------
>         >
>         
>         
>         
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list
>         [e-mail]
>         Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
>         --------------------------------------------------------------------
>         
>