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

Tore Anderson <> Tue, 07 July 2015 14:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 014F21ACD25 for <>; Tue, 7 Jul 2015 07:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0A91Oj9uj9qS for <>; Tue, 7 Jul 2015 07:55:56 -0700 (PDT)
Received: from ( [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D8501AC41C for <>; Tue, 7 Jul 2015 07:55:56 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=57855 by with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <>) id 1ZCUHo-0006ep-ER; Tue, 07 Jul 2015 16:55:52 +0200
Date: Tue, 7 Jul 2015 16:55:51 +0200
From: Tore Anderson <>
Message-ID: <>
In-Reply-To: <>
References: <>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <>
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, 07 Jul 2015 14:55:58 -0000


> A new draft has been posted, at
> Please take a look at it and comment.

Support WG adoption.


1) Nit: Abstract: s/network/networks/ (Or so I think. I'm not a native

2) Section 2, second bullet: Would like to add that the lost
connectivity (due to default route expiring) persists after the device
has woken back up again. This is another big reason for a network
operator to send RAs frequently, to ensure that a device re-gains its
connectivity as soon as the user starts interacting with his device.
Furthermore, a reference to draft-ietf-6man-rs-refresh might be prudent

3) Section 3: Did you consider recommending making unicast the default
behaviour for solicited RAs on all networks, not just the ones with
sleepy devices? I was thinking about it for a while and I couldn't
immediately see any big issue with that, but I might be missing
something. If the recommended approach isn't also suitable for, say, an
enterprise wired LAN with desktop PCs, or a data centre server LAN,
maybe include some text describing why not?

4) Section 3: I think that for a complete solution you should also
recommend that hosts MUST not ignore multicast RAs when they're
sleeping. Otherwise, you're missing a big part of the solution - the
hosts I discussed in #2 still lost their connectivity while sleeping
and after waking back up, and the way to combat that would still be for
the network to send unsolicited (multicast) RAs frequently.