Subject: Re: question on RDNSS, RFC 6106 part 5.1

From: Teemu Savolainen <[email-masked]>
Date: Mon, 14 May 2012 15:37:23 +0300

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-masked]>

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

---

From: Dan Luedtke <[email-masked]>
Date: Tue, 15 May 2012 09:47:50 +0200

> 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!

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
-- 
Dan Luedtke
http://www.danrl.de

---

From: Pavel Simerda <[email-masked]>
Date: Tue, 15 May 2012 10:54:28 +0200

> 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

---

From: Pavel Simerda <[email-masked]>
Date: Tue, 15 May 2012 12:10:18 +0200

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:
> Would it be enough to discuss and agree an errata for the RFC? Doing
> full RFC6106bis might be overkill.
> 
> Chairs?
> 
> Best regards,
> 
> Teemu
> 
>         > > Moreover, any Lifetime in this interval can timeout with
>         just one or two
>         > > lost RAs.
>         > >
>         > > I appreciate any help to get this right both in the
>         standards and in the
>         > > software.
>         > >
>         > > Cheers,
>         > >
>         > > Pavel Šimerda
>         > >
>         > >
>         > >
>         > > Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
>         > >
>         Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6