Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes

Nick,

Try doing :

PING FF02::1 -n 10

How many devices have you on link with you?

Am happy to share the PCAP with you privately.   Pls let me know.

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

----- Original Message -----
From: Nick Hilliard <nick@foobar.org>
To: Andrew 👽 Yourtchenko <ayourtch@gmail.com>
Cc: "draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org" <draft-elkins-v6ops-multicast-virtual-nodes@tools.ietf.org>; "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Friday, September 19, 2014 4:34 PM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes

On 19/09/2014 23:24, Andrew 👽  Yourtchenko wrote:
> If the draft had just the (2) above (even limit it to just
> observations, maybe? Could someone else from the community chime in
> who thinks it is a problem?),and also discussed whether one can use
> larger scopes (what happens if ff05::1?), and the *operational*
> measures that can be taken today to prevent that threat, this would
> make it self-contained. 

the draft describes that when pinging the mcast all-hosts address, a bunch
of replies are received from third party hosts which populated the nd cache
on the author's machine with a bunch of entries.  The authors have not
provided enough detail in the email to show the cause of the amplification;
anecdotally on my home network, pinging ff02::1%en0 causes some ND packets
and gets a single echo reply per node, which is nothing like what the
authors of this draft are seeing.

It would be more useful at this stage for the authors to upload a pcap file
for analysis rather than assuming there is a protocol level problem.  It
seems unusual that 10 icmp requests would result in 2840 replies but
without details, it's not possible to tell what's going on and on that
basis, an ID seems premature.

As a side note, the ND cache entries look like they're derived from Xen MAC
adddresses (00:16:3E:*).  If the virtual hosting provider in question has
made ipv6 end-user access available on a shared broadcast domain on Xen,
then large ND caches are probably the least of their worries: neither Xen
nor openvswitch support RA guard at the time of writing, which means that
if the authors were to inject fake RAs, they could trivially take over the
entire ipv6 network.

Nick

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops