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

Mark Smith <markzzzsmith@gmail.com> Thu, 23 July 2015 00:37 UTC

Return-Path: <markzzzsmith@gmail.com>
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 3ED9C1B3002 for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 17:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duNwIS7qCkCh for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 17:37:36 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 8F39A1B2FE0 for <v6ops@ietf.org>; Wed, 22 Jul 2015 17:37:35 -0700 (PDT)
Received: by igbpg9 with SMTP id pg9so1481329igb.0 for <v6ops@ietf.org>; Wed, 22 Jul 2015 17:37:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JpG/udKX0rmHtmwOSO9WHBjUl/mFKw1nGLjZgoZZIts=; b=fMDGuepskrGFoYpqTGZpUmQR/S97p7T1rqvE0K0X6mkpUe5bTeVDKjUs9DzbakMG8Y TIiFE7ZOFDLGa7rNkEAq7BHdvVdoM0osrYXCilElwL4a2kZOc3cOnlweKKfs2di72sRM N35PVKDOvAu69MNVU0hfhXSZa9va4jMjqAj1NKFIyzlMwGdf5Fns7pD6j6P6zwVHiZrt UyJ1E/taNhyHTjNkyeCza5jQIxABB5cmiIZs97CN86Hq0bzL5n9lLIXSbtZzEw3pxDLO s5LPxferdghdEr2+tEQy0wNSJb+RPOv+ByY5YwwNwLiFCDgmyMHaXKp5vwjv10QpbXL5 A07Q==
X-Received: by 10.107.29.209 with SMTP id d200mr8726171iod.94.1437611855096; Wed, 22 Jul 2015 17:37:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.169.143 with HTTP; Wed, 22 Jul 2015 17:37:05 -0700 (PDT)
In-Reply-To: <55B0177F.8050703@acm.org>
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> <CAAedzxqapiWuy4Gk5t3zEe3XmaLyRc3nc5=aA1ED0tzfeXckbA@mail.gmail.com> <CAKD1Yr3Hn9qJTaM0v3+hr7NfQbLc=mOWYGwrTK-XXxKp5v+dpg@mail.gmail.com> <CAAedzxpdFsCy2Y7U0gFmQeHEvJjNj-243g_ffoJsVUeRz5RpZw@mail.gmail.com> <CAKD1Yr1uR+HyBTB=Yhy5hGs1Z6Wv=HT3wwFgLYDosDJ7a78-PA@mail.gmail.com> <D1D2A832.1B7D8F%sgundave@cisco.com> <CAAedzxoX1dD3MQO5YCS6+u1esThW0sVv=JMmivJXZ92FKZ0sZg@mail.gmail.com> <CAO42Z2w8D+G7ONS5uXDP2kgf4da2JgiHHubEMt3TVumfFbkWOA@mail.gmail.com> <55B0177F.8050703@acm.org>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 23 Jul 2015 10:37:05 +1000
Message-ID: <CAO42Z2yTrjLudtCnbR_ziTGAKYkwtCguF+yEB4e78jEVUUT-Cg@mail.gmail.com>
To: Erik Nordmark <nordmark@acm.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/pnbZw8FojNlJvhuflDkYTAxDP1Q>
Cc: v6ops list <v6ops@ietf.org>, "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" <draft-yc-v6ops-solicited-ra-unicast@tools.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: Thu, 23 Jul 2015 00:37:37 -0000

Hi Erik,

On 23 July 2015 at 08:21, Erik Nordmark <nordmark@acm.org>; wrote:
> On 7/21/15 1:25 PM, Mark Smith wrote:
>>
>>
>> I thought that could be an option, however I encountered RSes without
>> the Source Link Layer Option, which means if RFC6085 is to be used,
>> the link-layer header has to be available to get the source link-layer
>> address from.
>>
>> After I wondered about the efficiency benefit of using multicasts for
>> solicited RAs, Fred asked me to do some testing/investigation. I wrote
>> up what I found here, the few unusual RS cases I saw the following,
>> which I put down some thoughts about handling via e.g., RFC6085.
>>
>> o  RSes with a :: source address
>>
>> o  RSes with a link-local source addresses, but no Source Link-Layer
>> Address Option
>
>
> Yes, both of those are important (I had forgotten about the second one).
>
> As you say, an implementation might be able to use the link-layer header and
> unicast back a packet. If the source was :: then that approach would rely on
> sending to the multicast ff02::1 while the link-layer destination is
> unicast.
>
> If not, then the implementation needs to multicast the RA.
>

I was wondering if instead the implementation could trigger an ND/NS
transaction for the RS source address at that point, and then unicast
the RA when that completes.

RFC4861 seems to be a bit vague about being able to do that. It says
that if the SLLO is not present, the router still can unicast the RA.
As RFC4861 is pre RFC6085, then performing a ND/NS first would be the
only way to do that. The last sentence also seems to be permitting NC
entries to be created when there is no SLLO ("or not a Source
Link-Layer is provided" ... "Neighbor Cache entry" ... "(or is
created)").

"If there is no existing Neighbor Cache
   entry and no Source Link-Layer Address option was present in the
   solicitation, the router may respond with either a multicast or a
   unicast router advertisement.  Whether or not a Source Link-Layer
   Address option is provided, if a Neighbor Cache entry for the
   solicitation's sender exists (or is created) the entry's IsRouter
   flag MUST be set to FALSE."

Performing an NS/ND to resolve the source address of the RS without a
SLLO would seem consistent with the corresponding RS SLLO handling -
to load the Neighbor Cache with entries for nodes that have sent RSes.


Regards,
Mark.

>    Erik
>
>>
>> https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html
>>
>>
>>
>>
>> https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html
>>
>>> But I would not say it's sufficient, if only from an "explicit
>>> clarity" standpoint.  I think explicit mention of RAs and the other
>>> discussion is helpful for implementors not inclined to dig to great
>>> depths or just seeking explicit confirmation.
>>>
>>
>>
>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>