Re: [v6ops] Please review the No IPv4 draft

Fernando Gont <fernando@gont.com.ar> Wed, 30 April 2014 15:05 UTC

Return-Path: <fernando@gont.com.ar>
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 0370A1A6FC2 for <v6ops@ietfa.amsl.com>; Wed, 30 Apr 2014 08:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 V0kGge1f-lbu for <v6ops@ietfa.amsl.com>; Wed, 30 Apr 2014 08:05:25 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5B81A6F88 for <v6ops@ietf.org>; Wed, 30 Apr 2014 08:05:24 -0700 (PDT)
Received: from 114-174-17-190.fibertel.com.ar ([190.17.174.114] helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <fernando@gont.com.ar>) id 1WfW4T-00005U-KR; Wed, 30 Apr 2014 17:05:17 +0200
Message-ID: <536110FD.4020708@gont.com.ar>
Date: Wed, 30 Apr 2014 12:04:29 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Ted Lemon <ted.lemon@nominum.com>, Sander Steffann <sander@steffann.nl>
References: <9B4139A3-77F7-4109-93AD-A822395E5007@nominum.com> <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> <B5BC5D48-3D5D-40A4-89F6-B0E1AEC860D6@steffann.nl> <F3225E37-C37B-426D-9127-25C74C25F814@nominum.com>
In-Reply-To: <F3225E37-C37B-426D-9127-25C74C25F814@nominum.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qPrH04nCoQ7WP9leRtitPQXhnjo
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 15:05:28 -0000

On 04/30/2014 09:44 AM, Ted Lemon wrote:
> On Apr 30, 2014, at 5:35 AM, Sander Steffann <sander@steffann.nl>
> wrote:
>> Ouch, a solution like that would then increase the cost of
>> deploying IPv6 later on. I agree it is effective to prevent (rogue)
>> IPv6 stuff, but it would be a bit too effective for my taste.
> 
> Yup, I don't think the IETF should be recommending this.   That's why
> I abstained when the draft came up for IESG review.

FWIW, the draft doesn't recommend that. It discusses a problem, and
evaluates possible mitigations. There are trade-offs among them
(including whether you can cope with the implied risk, feasibility, etc.).


> RA guard is a
> much better solution; it's too bad that it (apparently) isn't
> universally available.

It's not just "availability", but also about quality of implementation.
-- hopefully RFC7113 will help in this latter area.

At the time we reported this to a few vendors years ago, they argued
that they would improve RA-Guard, because the right fix for these
problems was SEND...

That's when the folk needing to address these issues starts thinking
about employing whatever he has at hand...

Cheers,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1