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

Erik Nordmark <nordmark@acm.org> Mon, 20 July 2015 18:18 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0C21B2A81 for <v6ops@ietfa.amsl.com>; Mon, 20 Jul 2015 11:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNTF398fdqjG for <v6ops@ietfa.amsl.com>; Mon, 20 Jul 2015 11:18:25 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806BF1B2A80 for <v6ops@ietf.org>; Mon, 20 Jul 2015 11:18:25 -0700 (PDT)
Received: from [130.129.5.149] (dhcp-hotel-wired-5-95.meeting.ietf.org [130.129.5.149] (may be forged)) (authenticated bits=0) by c.mail.sonic.net (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)" <fred@cisco.com>, Mark Smith <markzzzsmith@gmail.com>
References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <CAO42Z2x7mNFbB_w_+W+80pY+LeCAKXaOBXMmQvkcaMSWhwW60g@mail.gmail.com> <EF21B630-5D0A-415A-A93F-9058900CC80C@cisco.com> <CAO42Z2zAqMXhBZ2wa=q0wtHGhMpMWU9TSjfFyd2quiki9w0oSw@mail.gmail.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <CAO42Z2w3fOxGJHasKqYZRfGZ2u=7FnZBm+jgLtgDvfZ7HYW=iw@mail.gmail.com> <CAO42Z2z+DwOin23HQTysrZ9dNP924+LQ-vOExmJc_xZUEB4yCQ@mail.gmail.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com>
From: Erik Nordmark <nordmark@acm.org>
Message-ID: <55AD3B64.5070400@acm.org>
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: <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com>
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: <http://mailarchive.ietf.org/arch/msg/v6ops/AFgRmN3m5nyjYuxbrhTlWFmmGpU>
Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" <draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org>, v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=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.

Thanks,
    Erik

>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops