IETF Logo Mail Archive

question on RDNSS, RFC 6106 part 5.1

Pavel Šimerda <pavlix@pavlix.net> Thu, 19 April 2012 21:32 UTC

Return-Path: <pavlix@pavlix.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4440411E80C9 for <ipv6@ietfa.amsl.com>; Thu, 19 Apr 2012 14:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.113
X-Spam-Level:
X-Spam-Status: No, score=0.113 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+KtHmEZBc7W for <ipv6@ietfa.amsl.com>; Thu, 19 Apr 2012 14:32:46 -0700 (PDT)
Received: from fox.pavlix.net (fox.pavlix.net [84.246.161.104]) by ietfa.amsl.com (Postfix) with ESMTP id A77C111E80C5 for <ipv6@ietf.org>; Thu, 19 Apr 2012 14:32:46 -0700 (PDT)
Received: from [IPv6:2a00:1268:1ff:f001:9912:c1ba:54e:4eec] (unknown [127.0.0.1]) by fox.pavlix.net (Postfix) with ESMTPSA id D318F1763F6A for <ipv6@ietf.org>; Thu, 19 Apr 2012 23:32:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=pavlix.net; s=default; t=1334871165; bh=Du1MaHqvRm9ImvEYh254DROjbhjxMJjs3Kl+VnGOHQ8=; h=Message-ID:Subject:From:To:Date:Content-Type: Content-Transfer-Encoding:Mime-Version; b=XgH19/KvIyipsxzxWRSU52S+9EGUoZPirUmtcBRRB3f5MGJvkw0TMXqeQQAhB/mBH KfmndXglsXzggs+g0ULpYzT8FwvApbOTwuoT+wxC5TUe1jq5JOOzGzYDPR8K6Y9Ix1 RPtRZqpQqDfNzEFKMCWzUx4B8uop0LIE/krLhWOM=
Message-ID: <1334871165.15947.2.camel@dragon.pavlix.net>
Subject: question on RDNSS, RFC 6106 part 5.1
From: Pavel Šimerda <pavlix@pavlix.net>
To: ipv6@ietf.org
Date: Thu, 19 Apr 2012 23:32:45 +0200
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.1 (3.4.1-1.fc17)
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Apr 2012 21:32:47 -0000

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

v2.23.0 | Report a Bug | By Email