Re: [v6ops] Please review the No IPv4 draft

Nick Hilliard <nick@foobar.org> Tue, 29 April 2014 23:21 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 CB5D11A09FD for <v6ops@ietfa.amsl.com>; Tue, 29 Apr 2014 16:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 07lPKCElIRid for <v6ops@ietfa.amsl.com>; Tue, 29 Apr 2014 16:21:06 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id E68B31A09FC for <v6ops@ietf.org>; Tue, 29 Apr 2014 16:21:05 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3TNL1SC076057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 00:21:02 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org
Message-ID: <536033DD.8020800@foobar.org>
Date: Wed, 30 Apr 2014 00:21:01 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Ted Lemon <ted.lemon@nominum.com>
References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <m24n1l8i1a.wl%Niall.oReilly@ucd.ie> <3BA3E5A3-4385-43CE-B73F-A0686AA31B4E@nominum.com> <m238gxpgrt.wl%Niall.oReilly@ucd.ie> <73221D87-5F50-4689-AA42-553AF757ABF5@nominum.com> <m2mwf59uht.wl%Niall.oReilly@ucd.ie> <7310412C-64E9-4A11-9812-92A969082131@nominum.com> <20140428190804.GK43641@Space.Net> <446A720E-1128-4FFF-BB3B-780EACA9610B@nominum.com> <535EBC20.10900@foobar.org> <20140428213045.GL511@havarti.local> <19B5B5AB-FF86-408B-8E73-D5350853965B@foobar.org> <3563D9EE-CD40-4E75-A1CB-C3FB50EEEBC4@nominum.com> <535F3624.4020801@foobar.org> <alpine.DEB.2.02.1404290726011.29282@uplift.swm.pp.se> <535F3A8C.2050902@foobar.org> <E68028C1-2E6D-4D07-A113-60757457E286@nominum.com> <535F99A9.3030402@foobar.org> <0C03200E-B349-44D4-BE3F-512AD6A7A417@nominum.com> <535FCB2C.3030502@foobar.org> <8DB83B3D-D09C-4977-9B4F-75EA2DD3B71D@nominum.com> <53601BED.4050200@foobar.org> <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com>
In-Reply-To: <37DC9152-EEE3-4EEF-81C7-AD5B6D0E9892@nominum.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YEVzdy-HMElA1ThOytf-_wZWeCY
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] Please review the No IPv4 draft
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: Tue, 29 Apr 2014 23:21:10 -0000

On 29/04/2014 23:41, Ted Lemon wrote:
> Fernando's draft actually suggests filtering ethertype 0x86DD in order
> to avoid RA attacks on switches that don't have RA guard, which is why I
> assumed that that was an option for IPv4-only networks that don't want
> to be affected by this proposal.

this creates a new requirement to implement mac layer filtering of 0x86dd
across all ipv4 networks, on all network media, everywhere - in order to
stop casual jokers from trashing people's ipv4 network connectivity, even
if the signal is only the interface option (i.e. semantic option 1).  The
operational cost of this is not feasible.

Nick