Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast
Mark Smith <markzzzsmith@gmail.com> Thu, 16 July 2015 08:16 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 252681B3755 for <v6ops@ietfa.amsl.com>; Thu, 16 Jul 2015 01:16:07 -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 N2-EVhIydvrX for <v6ops@ietfa.amsl.com>; Thu, 16 Jul 2015 01:16:05 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 67D241B3754 for <v6ops@ietf.org>; Thu, 16 Jul 2015 01:16:05 -0700 (PDT)
Received: by igvi1 with SMTP id i1so7989975igv.1 for <v6ops@ietf.org>; Thu, 16 Jul 2015 01:16:04 -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=nkBuhq+FezYuxAcpgRwGRiGu1/aHrQJNjs9QjC32HcA=; b=y5iya7wAKkMj2n/ArE3q6dXjuSo9hpYL89OFLX7Qbx94rJUt2F0T2JKtcWZLUkkWS7 sFsZhy/YZ992/4aPJPTPWdDls3JeFZWbsMl4uNu7cZi1YzT7Awlloa/+OhW2umVFQg5f wcMSZWPBWe5B4wIUs7pA4ka4hUmQmeldXvByvVK+aCuWtQZZkQ6sjrmKHiQR51KTrIa5 EFeh2+aJnxZMpw6mM0ZFCZKO1wiLQ7uSIlfF2u2ocPkHdW1ny/CwfCeuxlEv7NHPGfgZ gSCKcJNxYKr+PW9O2HGTYEFIlGkPGHWXBdBEi8kuVRiYcI7B+s3xFWY8WlpDWyENACnT Zpzw==
X-Received: by 10.107.10.96 with SMTP id u93mr9381715ioi.172.1437034564851; Thu, 16 Jul 2015 01:16:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.205.5 with HTTP; Thu, 16 Jul 2015 01:15:35 -0700 (PDT)
In-Reply-To: <EF21B630-5D0A-415A-A93F-9058900CC80C@cisco.com>
References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <CAO42Z2x7mNFbB_w_+W+80pY+LeCAKXaOBXMmQvkcaMSWhwW60g@mail.gmail.com> <EF21B630-5D0A-415A-A93F-9058900CC80C@cisco.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 16 Jul 2015 18:15:35 +1000
Message-ID: <CAO42Z2zAqMXhBZ2wa=q0wtHGhMpMWU9TSjfFyd2quiki9w0oSw@mail.gmail.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/PAlyHEoxCHtFMK2Js3o45QDquw0>
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: Thu, 16 Jul 2015 08:16:07 -0000
Hi, On 9 July 2015 at 15:38, Fred Baker (fred) <fred@cisco.com> wrote: > >> On Jul 8, 2015, at 10:08 PM, Mark Smith <markzzzsmith@gmail.com> wrote: >> >> One thought I have though is that I wonder if just changing solicited >> RAs from multlicast to unicasts would result in an increase in the >> number of multicast RSes? > > Sounds like you have a tool that you could use to simulate that and find out? So thought about this a bit more, and realised that my thinking wasn't quite right. Hosts don't issue periodic multicast RSes, such that receiving a solicited multicast RA a short period before a periodic multicast RS would have been sent would suppress the multicast RS. Periodic unsolicited multicast RAs keep hosts' knowledge of default routers fresh, so hosts would only issue a multicast RS when they need to discover routers "now" i.e., when an interface comes up. 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. The only other benefit I can see of mulicasting solicited RAs is that it would keep all of the receiving hosts' default router knowledge more accurate and the aging of the default router information more synchronised across all nodes over the periodic unsolicited multicast RAs. I'm not sure if it would matter if the loss of this increased default router accuracy and aging synchronisation would matter if solicited RAs were unicast instead of being multicast. Out of interest, I also captured RSes and RAs on my home Wifi LAN (all hosts were variants of Linux), and also looked up some Windows boot packet captures I have. Here's what I found and some thoughts. o RSes with a :: source address Windows XP sends some early RSes with a source address of the unspecified address. These RSes didn't have the Source Link-Layer Address Option (because :: shouldn't be added to the neighbor cache). This is permitted by RFC4861. It later sends RSes using a link-local source address, now containing the Source Link-Layer Address Option. Later versions of Windows didn't issue RSes with :: source addresses i.e., they waited until they had a link-local address to use (and included the Source Link-Layer Address Option). It isn't possible to use the :: address as a destination address for the solicited RA per RFC4291, so it seems the only choice for the IPv6 destination address is FF02::1. However, if the link-layer header source address of the RS is available to the RA process, then it could link-layer unicast the multicast RA, as per RFC6085, "Address Mapping of IPv6 Multicast Packets on Ethernet". I think it is necessary to describe how to handle these :: source address RSes in this draft, as they're valid and could appear on a "solicited unicast RA only" link. o RSes with a link-local source addresses, but no Source Link-Layer Address Option Some of my Linux hosts issued RSes with a link-local source address, but without the Source Link-Layer Address Option. This also seems permitted by RFC4861. These hosts were Fedora 22 hosts, using the user space Network manager package to perform/handle RS/RA processing in user space, verses other hosts (Android, Chrome OS) which are probably using the Linux kernel's RS/RA facilities. I dug into the Network manager code and found that it was using the libndp.org NDP library, and was using a single call that builds a generic RS without the SLLA option. RFC4861 is pretty clear about what to do when there is an SLLA option in an RS - create or update a neighbor cache entry for the RS source address with the SLLA option value, and set it to STALE. However, I don't find the text about when there is no SLLA option that clear: "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." It seems to be strongly implying that a neighbor cache entry could be created even if there is no SLLA option, because it says it is possible to respond with a unicast RA. However, to be able to use the RS's source IPv6 address to unicast the RA, I think a NS/NA transaction would need to occur first for the RS's source address, before the unicast RA is sent. The implementation could use the link-layer source address from the frame the RS arrived in to send a link-layer unicast solicited unicast RA (i.e., don't use the neighbor cache to resolve the link-layer destination address, use the RS frame's source address). In that case, I think the frame's link-layer source address should only be used for this unicast solicited RA. An entry in the neighbor cache would be created for the RS's source address, and then an NS/NA transaction to verify its reachability independent of sending the RA. Alternatively, the method of link-layer unicasting a multicast solicited RA could be used, although there is probably more broader value in the triggering an NS/NA transaction method. o At least one common IPv6 RA implementation isn't rate limiting sending solicited RAs This is for the current version of OpenWRT, sending way more than one RA per 3 seconds if I solicit them quickly. So it may be worth observing in the ID that RA rate limits may not have been implemented, and unicasting RAs in that case will have the benefit of avoiding sending these RAs to nodes that didn't solicit them. 17:14:47.312209 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router solicitation, length 8 17:14:47.313398 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router solicitation, length 8 17:14:47.314363 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router solicitation, length 8 17:14:47.315563 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router solicitation, length 8 17:14:47.316739 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router solicitation, length 8 17:14:47.529880 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router advertisement, length 192 17:14:47.533531 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router advertisement, length 192 17:14:47.536100 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router advertisement, length 192 17:14:47.538672 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router advertisement, length 192 17:14:47.541194 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router advertisement, length 192 Regards, Mark.
- [v6ops] new draft: draft-yc-v6ops-solicited-ra-un… fred
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Kline
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Tore Anderson
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Fred Baker (fred)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Fred Baker (fred)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Fred Baker (fred)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Ole Troan
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Fred Baker (fred)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Kline
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Jen Linkova
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Kline
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Tarko Tikan
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Sri Gundavelli (sgundave)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Gert Doering
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Ole Troan
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Kline
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Gert Doering
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Hemant Singh (shemant)
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Owen DeLong
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Nabil Benamar
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alejandro Acosta
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Jen Linkova
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Jared Mauch
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Nabil Benamar
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Alexandru Petrescu
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Gert Doering
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Lorenzo Colitti
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Owen DeLong
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Owen DeLong
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Owen DeLong
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Owen DeLong
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Andrew 👽 Yourtchenko
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Ole Troan
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Erik Nordmark
- Re: [v6ops] new draft: draft-yc-v6ops-solicited-r… Mark Smith