Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast

Lorenzo Colitti <> Mon, 20 July 2015 16:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A035B1A8AA8 for <>; Mon, 20 Jul 2015 09:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FLnuXYZ8v9Nj for <>; Mon, 20 Jul 2015 09:29:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B53A1A8974 for <>; Mon, 20 Jul 2015 09:29:29 -0700 (PDT)
Received: by ykdu72 with SMTP id u72so142900632ykd.2 for <>; Mon, 20 Jul 2015 09:29:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pbFhHV/m7j7AXuhbKDv0pUmBz58nRKssHfyXu/AgyLA=; b=Z0Ye6Cb56K0ZskbJZ4/+CT/ayj4UWRuadzT6b7ij8O8VR2kBCORSmoTEYb+yWP3lb+ Gte9bPrgxkcHZd2KU04RXTyV+DfBiv8B+lot1HP8z6luwmwGZxErkVEtLbFKPoR45aYm 6yAlwZUnprMdIVHlVDc6AyKEqYMptGx3zJDo31aG8z69HBC/HcxNyxk1I6fTptOs7BRx TFy4Rj+tvsLzGuiecQlY9K0RqbZweBgjNfrEI05MrUCAQORdp7kEOPRzhfg8eD3uouqJ JVVbR+CIIg2LaP8oZAZEDntlG/l2M96LL+wySHdHttQz6rpTXkkRfsCkbHptpodAan7a 7+kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pbFhHV/m7j7AXuhbKDv0pUmBz58nRKssHfyXu/AgyLA=; b=W5SWB/5y4BaUMA/+L6AkyIz1HVGMSdhuvYj0UhZ6FZwuWb/IA/uLTwTU3dZ4xd00rK qyAoliX5BEDzOSxsQvJntH3wBtFE/59bZoY50MIxZtFuQ5JnEajZLELRFpHYXNjxesoQ AoEUurLTFP0t1z7cQYz5jPcrK1PBogZuJ+tE9aRax8hI1ildAl/N88rwgP0OvCoOWrHl 8W5SnKHN6h+uCpNUsWYggqErBP7kA9r5J39ihH1wFC/Q4HxudBaS1cgdpffAOobE+SeB sgXdmwlLzA6Cz0qs1eBvzno1FezkUgzmBD4pk33to5UuOUzfVfxkyq/jH59MRHbATvOK StzA==
X-Gm-Message-State: ALoCoQkCaM2D33za+cjEmBKEa/Rv2h8W8t1+h9e8TgNow0DKOBWxHOOQAKXlziyPO0pItUngCAsY
X-Received: by with SMTP id 20mr1555988yki.47.1437409768571; Mon, 20 Jul 2015 09:29:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Jul 2015 09:29:08 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Lorenzo Colitti <>
Date: Mon, 20 Jul 2015 18:29:08 +0200
Message-ID: <>
To: Mark Smith <>
Content-Type: multipart/alternative; boundary=001a1137aa94a76be7051b510ac2
Archived-At: <>
Cc:, " WG" <>
Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jul 2015 16:29:30 -0000

On Thu, Jul 9, 2015 at 7:08 AM, Mark Smith <> wrote:

> It was my understanding that the idea behind multicasting solicited
> RAs was to also update hosts who were soon going to be issuing
> multicast RSes, which would then reduce the volume of multicast RSes.
> If those hosts are now not going to receive the multicast solicited
> RAs, then they I think they would now be issuing multicast RSes more
> often where as in the past they wouldn't.

Yes. In the (rare) case where a large number of nodes joins the network at
the same time, sending a single multicast RA would likely be more
efficient. That would need to be weighed against the power implications on
the nodes that are already connected, so it probably only makes sense if
the router is seeing large enough numbers of RS packets that it believes
that it cannot handle them efficiently.

We could put something in the draft saying that "routers configured in this
mode MAY send solicited RAs multicast in conditions where it is likely that
doing so will be more efficient (e.g., if a large number of clients is
sending RS packets at the same time and the packets are being dropped due
to control plane limiting).

As a side note, the radvd RA daemon already supports a UnicastOnly option:
> --
> UnicastOnly on|off
> Indicates that the interface link type only supports unicast. This
> will prevent unsolicited advertisements from being sent, and will
> cause solicited advertisements to be unicast to the soliciting node.
> This option is necessary for non-broadcast, multiple-access links,
> such as ISATAP.

That doesn't help because it doesn't do unsolicited advertisements.