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

Erik Nordmark <> Mon, 20 July 2015 18:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AB0C21B2A81 for <>; Mon, 20 Jul 2015 11:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lNTF398fdqjG for <>; Mon, 20 Jul 2015 11:18:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 806BF1B2A80 for <>; Mon, 20 Jul 2015 11:18:25 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.15.1/8.15.1) with ESMTPSA id t6KIIEme025178 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 11:18:17 -0700
To: "Fred Baker (fred)" <>, Mark Smith <>
References: <> <> <> <> <> <> <> <>
From: Erik Nordmark <>
Message-ID: <>
Date: Mon, 20 Jul 2015 20:18:12 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVbArd0O464AVQjlJw4Vhauvpkt5lvyVPmDcp6is4X7guduc8bWqT1FQ3xla9ayJRGTTp98qTmOpXVboVf/CBBfb
X-Sonic-ID: C;zFKrrwsv5RGvPIM848vClw== M;qmuFsQsv5RGvPIM848vClw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
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: Mon, 20 Jul 2015 18:18:26 -0000

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?
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 
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".

FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6.


> _______________________________________________
> v6ops mailing list