Re: question on RDNSS, RFC 6106 part 5.1

Dan Luedtke <> Tue, 15 May 2012 07:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12E2621F8790 for <>; Tue, 15 May 2012 00:47:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.729
X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mbt5odncp6aq for <>; Tue, 15 May 2012 00:47:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5953C21F863E for <>; Tue, 15 May 2012 00:47:51 -0700 (PDT)
Received: by dacx6 with SMTP id x6so7196311dac.31 for <>; Tue, 15 May 2012 00:47:51 -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=SOqORwzqP2MLvO6kF5LECo1epflxtF8Iht8qxiDi62k=; b=rPtQVHJxI18aFqYR85o+toAHshgA7jo5B4ln1Bi2L3Ie4gaOL2YUbKwfnxcIA5vdNO d7/KZtlmKgwwRBKLiIKooH8q+0HpaRmiuPl72HRKR5vTQnlIgq88VHya1iDQy0L1SLti aW/kJJW5056JOVwqwEUuXrOwjUKSBKnYuqS+ModKfl3NijBYSG1Q5K7Ge6mBcaeTOcuN wR05HIuLYziP+olS2WAWqgJCl9gErhJ6n/bchJsCFavgmu3BJsSFXiGTdQu/mlfzvw52 NAjEELUmpEy/WdFm6PN6JB/GsiA905x6ruIjBckumspX8gIyfqPbWvsJ2GqbEOpk7lfW 1KuA==
MIME-Version: 1.0
Received: by with SMTP id nw3mr2653414pbb.150.1337068071115; Tue, 15 May 2012 00:47:51 -0700 (PDT)
Received: by with HTTP; Tue, 15 May 2012 00:47:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 15 May 2012 09:47:50 +0200
Message-ID: <>
Subject: Re: question on RDNSS, RFC 6106 part 5.1
From: Dan Luedtke <>
To: Teemu Savolainen <>
Content-Type: text/plain; charset="UTF-8"
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: Tue, 15 May 2012 07:47:52 -0000

> Since then, router solicitations would be issued regularly until
> 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.

Dan Luedtke