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

Lorenzo Colitti <> Tue, 21 July 2015 09:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 73E071A89EB for <>; Tue, 21 Jul 2015 02:36:11 -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 6uzeo19m0e6z for <>; Tue, 21 Jul 2015 02:36:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 040411A87F0 for <>; Tue, 21 Jul 2015 02:36:10 -0700 (PDT)
Received: by ykax123 with SMTP id x123so161064648yka.1 for <>; Tue, 21 Jul 2015 02:36:09 -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=P2ECDvXjr8VWa9Z+DFCapFDg1La3u97ZGAORoD4TNQg=; b=FtYaZSJqSuPZJ51liyL3V0WgTT+oIjP9tR/oCPn7HiS7X/NSSEy1qo4oLDC02lTQ6P B7FCgsAg6mLfnJsCisPlqmPRh0Ti+S6zOe5lf4HBV7FeQgTr+KD18TzUBvXDtk+3Y3Li yQL6AsBylHw5TMtMMC9HuhyvKu9ybQKfyFYO5MR6OvaH+q/sGy4fhEUBwXB11Eu47wsi 7iR0OeDaGxQqL4m3iSv1NS6Hm+aGiVplx4HRcJKUqDTaBvOGX8AUh0DoDSO5Ky7kXk6y fP8VIfPgWkEvZBnq8ua/xZ+j4sU8nExB+T2iwTaWWFjz39AtSDutU3KNMErT3ImjwYxw Wodw==
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=P2ECDvXjr8VWa9Z+DFCapFDg1La3u97ZGAORoD4TNQg=; b=KTYDTBaBlPG9p4AsQ+1vVKrBxHxsrM9VRU09FYs9CN1Bi3v9wyop0/q0gzyQLaC4iI RxU+st2aJmTH0asH+rePLLHK8mpUkZSY7nq74+ZRxDTmjBSpJMj5X++zgW52qP54G3gS a/r76h8Jd1WydxOZb9lUUI+xudbUhvreKizFaC2EWPUQp0SZ1UK7MsJJtv0oS2axqBhf NoixWR4i/SgSPrFpgBgBI10GJBaBlYzFcY7G9OSUnMamiGye95lKIen7XVchqKn+KfNA YBf7BHnSQ5kTqCC3BcX5pLznsSE9zsb2CR1pJ16TkNwegtSknr7rdh7vtKmtRtFQFWfn bFdg==
X-Gm-Message-State: ALoCoQnOO/L29g/2sAZ/YgPZyUQ5YSiPwNHKOTH3ucq8H8kxlGC+/iBjn7KjqATQutpy2hOm4Z2s
X-Received: by with SMTP id 184mr32475280ykl.119.1437471369377; Tue, 21 Jul 2015 02:36:09 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 21 Jul 2015 02:35:49 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Tue, 21 Jul 2015 11:35:49 +0200
Message-ID: <>
To: Erik Nordmark <>
Content-Type: multipart/alternative; boundary=001a11378f34591e53051b5f6284
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 09:36:11 -0000

On Mon, Jul 20, 2015 at 8:18 PM, Erik Nordmark <> wrote:

> But in terms of implementation, isn't it simpler to always(*) respond to a
> RS with a unicast RA?

It would be simpler to document, yes, but I don't know that we should make
a one-size-fits all recommendation, because there might be link types or
environments where this is more expensive.

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.

This sort of thing can still happen. If lots of devices join at once,
(e.g., if something happens at a large-scale event when hundreds of people
pull their phones out of their pockets and turn them on at the same time),
it may well be cheaper for the network to send one multicast RA.

I'm not opposed to changing the standards as well, but I think respinning
RFC 4861 would require much more careful consideration than simply
publishing an operational guidance document such as this one. Perhaps we
can just recommend in this document that 6man consider this operational
need and consider modifying the protocol?