Re: question on RDNSS, RFC 6106 part 5.1

Teemu Savolainen <> Thu, 26 April 2012 09:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A040621F86E5 for <>; Thu, 26 Apr 2012 02:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ANZdKImO0LS0 for <>; Thu, 26 Apr 2012 02:09:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8ED1B21F86E2 for <>; Thu, 26 Apr 2012 02:09:28 -0700 (PDT)
Received: by dady13 with SMTP id y13so1951369dad.27 for <>; Thu, 26 Apr 2012 02:09:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7cYarMUULVGLhgljRNHhoW6V5/XzGHG1WeYoGdBUr3E=; b=0hx07IzN+chANzaVKYix/emhOG0JVm1+Sl+REuKNdN2ICF5pwZPwFcKWEMb972BE0/ FJZnHvlgvjx9wlmBmfRwTu98qG43fkBu6cctwo0d7XoUq2fz69ENqoE0ZoJyvQTdCB0h ThBDzp1wSpmG/H1HsruqpxHBtVrdEHnAwbe3SsAujbUyVkv9vvKAqyfScm+ngTsAsFV6 5zPzurMvxJV9ktOZMUVQ+snLau5nCO57+9lBHj2UkGu8xZsxg7LZJ0+KfuQVAOrljsj9 jaIx9U6ulw/PJhgiyR5VN+3YPk8JNVKOyXho6m7OibfJC/AkkiQlYlMZ2WzR8loKc3J/ GdBg==
MIME-Version: 1.0
Received: by with SMTP id pn8mr7640058pbb.106.1335431368230; Thu, 26 Apr 2012 02:09:28 -0700 (PDT)
Received: by with HTTP; Thu, 26 Apr 2012 02:09:28 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 26 Apr 2012 12:09:28 +0300
Message-ID: <>
Subject: Re: question on RDNSS, RFC 6106 part 5.1
From: Teemu Savolainen <>
To: Pavel Šimerda <>
Content-Type: multipart/alternative; boundary="047d7b10c86153485004be9158d4"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Apr 2012 09:09:29 -0000


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

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

Best regards,


20. huhtikuuta 2012 0.10 Pavel Šimerda <> kirjoitti:

> 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
> Administrative Requests:
> --------------------------------------------------------------------