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

Owen DeLong <> Tue, 21 July 2015 15:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0CE651A8A3E for <>; Tue, 21 Jul 2015 08:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.811
X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kzqx1Tz7maAB for <>; Tue, 21 Jul 2015 08:38:19 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 94FAA1A8A3D for <>; Tue, 21 Jul 2015 08:38:19 -0700 (PDT)
Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by (8.14.5/8.14.2) with ESMTP id t6LFc5er006663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2015 08:38:05 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Tue, 21 Jul 2015 08:38:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: =?utf-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= <>
X-Mailer: Apple Mail (2.2098)
Archived-At: <>
Cc: v6ops list <>, "" <>
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: Tue, 21 Jul 2015 15:38:21 -0000

It seems to me that the following algorithm would be relatively easy to implement
and provide reasonable network optimization…

On receipt of an RS:

	if(multicast_ra_time_remaining > 15 seconds)

In this way, if the timing is reasonably close, you multicast a packet you were about to send
anyway, but if the timing isn’t close, you’re not wasting multicast bandwidth answering a single
node where nobody else cares.

Overall, I’ve always thought that multicast response to RS was kind of silly. It’s probably most
harmful on WiFi.


> On Jul 21, 2015, at 02:33 , Andrew 👽 Yourtchenko <> wrote:
> On 7/20/15, Erik Nordmark <> wrote:
>> On 7/17/15 9:34 AM, Fred Baker (fred) wrote:
>>>> So the next logical thing to do would be to have the router default to
>>>> unicast Router Advertisements, measure the rate of received Router
>>>> Solicitations, and switch to multicast RA mode past a certain
>>>> threshold to cover this sort of situation. Once the number of RSes
>>>> falls, it switches back to unicast RA mode.
>>>> That would get rid of the configuration knob proposed in this ID, and
>>>> is behaviour that I think could be universal for all link types,
>>>> rather than just for the case of wireless ones with mobile devices.
>>> If it were me implementing it, I think I would go about this in a little
>>> different way, hopefully simpler. I would want to send at most one (e.g.,
>>> either zero or one) RA per some interval (a second?). In the normal case,
>>> that is sent unicast. However, having sent a unicast RA at time t, if I
>>> now receive another RS before t+1, I send the next one (at time t+1) as a
>>> multicast.
>> First of all I support this document as a WG document.
>> But in terms of implementation, isn't it simpler to always(*) respond to
>> a RS with a unicast RA?
> Yes. I did not respond on-list yet - but from operational perspective
> "always send solRA unicast" / "always send solRA multicast" definitely
> wins in my book, and I'd avoid premature optimizations (but maybe we
> can say the implementers are explicitly free to do their own
> optimizations if they see fit)
> That said, will be very interesting to hear data from folks who will
> run "all-unicast solRA", in real networks and then compare the effect
> of their proposal optimizations on their real-world scenarios.
>> As background, the text in RFC4861 comes from the old concern that all
>> devices might boot at the same time when the power is re-established
>> after a building power failure; that doesn't happen since most devices
>> (laptops, smartphones, IoT devices) have batteries today. In that case
>> it might have made sense to sending fewer RA messages by using multicast.
>> (*) the only case in RFC 4861 when I think a multicast response might be
>> considered is when the source IPv6 address in the RS is the unspecified
>> address. Further, an implementation which rate limits received RS
>> packets (e.g., CoPP in a router) might also want to detect when the rate
>> limit might have dropped RS packets and multicast an RA in that case.
>> I do wonder why implementations haven't already changed to send unicast
>> solicited RA, and whether it would make a difference if we have an
> TBH that's my concern as well. I think we should tweak the text in
> 4861 to encourage a bit more consideration on the implementer's side.
>> informational document asking them to do this. Alternatively we could
>> have a proposed standard which updates section 6.2.6 to change the "MAY
>> unicast" to a "SHOULD unicast".
> Yeah, I actually have had the different text aimed for 6man, but
> Lorenzo's concern was 6man would say "there is no protocol update
> here, go away", so he rewrote it for v6ops.
> We should probably discuss this at the mic and get the opinion of the
> 6man chairs - if there is no outright "no" on this, a normative doc
> would be a better way to convince the implementers ?
>> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6.
> Nice catch, thanks!
> --a
>> Thanks,
>>    Erik
>>> _______________________________________________
>>> v6ops mailing list
>> _______________________________________________
>> v6ops mailing list
> _______________________________________________
> v6ops mailing list