IETF Logo Mail Archive

Re: [v6ops] Please review the No IPv4 draft

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 30 April 2014 04:09 UTC

Return-Path: <swmike@swm.pp.se>
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 AA2511A0A0A for <v6ops@ietfa.amsl.com>; Tue, 29 Apr 2014 21:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level:
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 qRTAYaSnt3NB for <v6ops@ietfa.amsl.com>; Tue, 29 Apr 2014 21:09:48 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 25D421A0A07 for <v6ops@ietf.org>; Tue, 29 Apr 2014 21:09:47 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8B6BDA6; Wed, 30 Apr 2014 06:09:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1398830984; bh=enV/vQCs2Dcv655Lt7uOMg+kdtMajN+lAp/JfpHyNxA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lbiI+Xvhy0XHzpvlM9qt0lYaWykdJ9hj3Gk8CjIwSrf/sonsj6abZTcV2/bVaHYyg S/o74NAp2p86s/lNlKzOnfp9DEXeVMT76agEzqNi0+Rns8EdJOxZNu3DJY1p5mWr7U h8iRBVUS/P/8O0EOFAZ+BzDaWB+ysIOrxvdcFAzk=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7F841A5; Wed, 30 Apr 2014 06:09:44 +0200 (CEST)
Date: Wed, 30 Apr 2014 06:09:44 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Nick Hilliard <nick@foobar.org>
In-Reply-To: <536033DD.8020800@foobar.org>
Message-ID: <alpine.DEB.2.02.1404300607110.29282@uplift.swm.pp.se>
References: <9B4139A3-77F7-4109-93AD-A822395E5007@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> <536033DD.8020800@foobar.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9OtRTNv0J0c1ZE5pEADvD6W1hxk
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: Wed, 30 Apr 2014 04:09:51 -0000

On Wed, 30 Apr 2014, Nick Hilliard wrote:

> 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, if you're not doing this today you're exposing your customers to 
MITM attacks and all kinds of other bad things. What this proposal is 
doing is adding one more reason to implement proper L2 security. You're 
already screwed, this mechanism just adds one more way you're screwed.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email