Subject: question on RDNSS, RFC 6106 part 5.1

From: Pavel Šimerda <[email-masked]>
Date: Thu, 19 Apr 2012 23:32:45 +0200

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

---

From: Ole Trøan <[email-masked]>
Date: Thu, 26 Apr 2012 14:00:33 +0200

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:

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

---

From: Pavel Simerda <[email-masked]>
Date: Fri, 27 Apr 2012 17:25:37 +0200

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

---

From: Pavel Simerda <[email-masked]>
Date: Fri, 27 Apr 2012 17:27:30 +0200

Hello,

Note:

Example:

00:50 Lifetime = 0
00:50 RDNSS expired

Note:

Pavel Simerda