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

Nick Hilliard <nick@foobar.org> Sat, 20 September 2014 17:26 UTC

Return-Path: <nick@foobar.org>
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 436621A0191 for <v6ops@ietfa.amsl.com>; Sat, 20 Sep 2014 10:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 iZMpXebpQv3H for <v6ops@ietfa.amsl.com>; Sat, 20 Sep 2014 10:25:58 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1311A016B for <v6ops@ietf.org>; Sat, 20 Sep 2014 10:25:58 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from vpn-251.int.inex.ie (vpn-251.int.inex.ie [193.242.111.251]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s8KHOC1X015992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 20 Sep 2014 18:25:01 +0100 (IST) (envelope-from nick@foobar.org)
Message-ID: <541DB824.7080408@foobar.org>
Date: Sat, 20 Sep 2014 18:23:48 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Nalini Elkins <nalini.elkins@insidethestack.com>, Andrew 👽 Yourtchenko <ayourtch@gmail.com>
References: <201409191147.s8JBl1Fe016458@irp-lnx1.cisco.com> <CAPi140O_WkcS9uFCSK0+tVDF3Z1sB4_UF5Zv9kpNEMh7m94Vww@mail.gmail.com> <1411154671.21942.YahooMailNeo@web125102.mail.ne1.yahoo.com> <CAPi140Ob+TeDyYfw_1A2Q55gEF5-rNrLynQ1LkGHOVnGcNcpLA@mail.gmail.com> <1411164118.44574.YahooMailNeo@web125106.mail.ne1.yahoo.com> <CAPi140M+RjEr_edAXZBuUv9dYTztQUHq5J6rTd6Ca0qHcuhrCA@mail.gmail.com> <1411170563.16646.YahooMailNeo@web125101.mail.ne1.yahoo.com> <CAPi140PC_rjguOVpyes74=by-Y504hcpsbWFxVfQ8GiudbR6sA@mail.gmail.com> <1411185266.51203.YahooMailNeo@web125102.mail.ne1.yahoo.com> <541D45DB.5010703@foobar.org> <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com>
In-Reply-To: <1411222548.10128.YahooMailNeo@web125105.mail.ne1.yahoo.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/D_QuT9zDH_Ptb5yy6JVICWHUBn0
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>
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes
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: <http://www.ietf.org/mail-archive/web/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: Sat, 20 Sep 2014 17:26:00 -0000

On 20/09/2014 15:15, Nalini Elkins wrote:
> Situation:  node A is on a subnet with 25 other nodes (B-Z)
>
> 1.  Node A sends 10 ICMP ping requests to FF02::1
> 2.  Nodes B through Z send Node A back ICMP 10 ping replies each
>
> Impact: with very little work by Node A, he has made B - Z do work &
> created network congestion with 250+ packets.

If the hosting provider has any sense, this will count towards node A's 
bandwidth allocation and if they persist in doing this, they will end up 
with a large bill as well as having trashed their connectivity.

The lesson is that if you shoot yourself in the foot, it will hurt.  If 
your network design is such that shooting yourself in the foot causes other 
hosts to be shot in the foot, then your network design may have a problem.

If you are a commercial hosting provider who provides third party shared 
tenancy networks which use this design, then you should expect problems of 
this sort.

Most hosting providers know these things and there is no need for the IETF 
to remind them.

Nick