Subject: question on RDNSS, RFC 6106 part 5.1

From: Pavel Šimerda <[email-masked]>
Date: Thu, 19 Apr 2012 23:10:02 +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: Teemu Savolainen <[email-masked]>
Date: Thu, 26 Apr 2012 12:09:28 +0300

Hi,

We have seen this same problem as well.

Does anyone have any idea why the lifetime is bound with SHOULD to this
very short time period? For example, if the Lifetime == MaxRtrAdvInterval,
a host often would effectively be forced to send RS to refresh the RDNSS
information before RDNSS expiration? Also in Lifetime ==
2*MaxRtrAdvInterval, a single lost RA (or in some case maybe two) could
force host to send RS.

Another question is that does anyone know why the time for sending RS is
not specified? To help avoid simultaneous sending of RS by many hosts (if
nobody got periodic RA)? I.e. could it be, say, 1.7*MaxRtrAdvInterval with
random(0.2*MaxRtAdvInterval) delay to avoid hosts sending RS'es
simultaneously?

If this is agreed to be an issue, could we do ERRATA that extends the
lifetime and specifies better when RS should be sent for information
refreshing?

Best regards,

Teemu

20. huhtikuuta 2012 0.10 Pavel Šimerda <[email-masked]> kirjoitti:

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