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

Mark Smith <> Thu, 16 July 2015 09:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7CF401A8716 for <>; Thu, 16 Jul 2015 02:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K7P-tAyIgivu for <>; Thu, 16 Jul 2015 02:19:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CFD01A8714 for <>; Thu, 16 Jul 2015 02:19:19 -0700 (PDT)
Received: by ietj16 with SMTP id j16so51755635iet.0 for <>; Thu, 16 Jul 2015 02:19:19 -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=BtLRwz+2bLhJt9yrumF0L3DC5V1IyVIBRiJGWVQFVQ0=; b=AkyvKbNKumAON0abPxE2N52ugWur/oUVk2V2hd+v1+uXeeCT/U38ZyLRCs6t/r9s3T YsJm9KmCyqi+bT4G8BCSIsJEh0QJBePShC7HRyJmn7Q9MtiunzYjbNaR9BuPMwqqzphI 3b1ZFClXADN3FSuJ0fJxMZTgL7irjcXBTt9gOypBuJ5ZpvwbIYxP04P352nIZ6MmTQj6 urkKoalZu7OPeHdzaNqtMItFBt/lo7HSzfcxqJB41M3OWnqiXeVgh/3e7ezdO4FIup0y icpiktZQl/OwSYXY0LKNYszkImoukiX05rTBW5ZUZQnBMsQwkAuSHz15GbtVuyvutNV1 56HQ==
X-Received: by with SMTP id p2mr3054335igr.9.1437038358969; Thu, 16 Jul 2015 02:19:18 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 16 Jul 2015 02:18:49 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Mark Smith <>
Date: Thu, 16 Jul 2015 19:18:49 +1000
Message-ID: <>
To: "Fred Baker (fred)" <>
Content-Type: text/plain; charset=UTF-8
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: Thu, 16 Jul 2015 09:19:20 -0000

Hi Fred,

On 16 July 2015 at 18:23, Fred Baker (fred) <> wrote:
>> On Jul 16, 2015, at 10:15 AM, Mark Smith <> wrote:
>> I think this means that unicasting solicited RAs on certain link types
>> would usefully reduce multicasts. It does raise the question as to why
>> solicited RAs were multicast in the first place.
> Not sure. RFC 826, which is the obvious predecessor, calls for the response to an ARP request to be unicast.

Now you've mentioned an old RFC, it has reminded me of RC1256, "ICMP
Router Discovery Messages", which I came across again fairly recently.
It describes RS/RAs for IPv4, and somewhat surprisingly
implementations of it seem to be fairly available - Cisco and Juniper
call it IRDP, and e.g., my Fedora 22 host has a client for it
installed by default ('rdisc').

It says that RAs can be unicast, multicast or broadcast. It seems to
give a bit of a clue as to why multicast solicited RAs would be

"A unicast response may be delayed, and a multicast
   response must be delayed, for a small random interval not greater
   than MAX_RESPONSE_DELAY, in order to prevent synchronization with
   other responding routers, and to allow multiple, closely-spaced
   solicitations to be answered with a single multicast advertisement."

In 1991, hosts were pretty much mains powered, fixed location and
wired, so they could all rush to send multicast RSes after a mains
power outage or the 10BASE2 cable broke and was then fixed, and they
wouldn't have come and gone much from the link either. A single
multicast RA in response to the first RS in a flood of them could have
caused a lot of later RSes to be suppressed.

> Thanks for your note.

No worries.