Re: [v6ops] Please review the No IPv4 draft

Owen DeLong <owen@delong.com> Thu, 17 April 2014 11:58 UTC

Return-Path: <owen@delong.com>
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 58B711A0119 for <v6ops@ietfa.amsl.com>; Thu, 17 Apr 2014 04:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.263
X-Spam-Level:
X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 k4REwnrC6AoX for <v6ops@ietfa.amsl.com>; Thu, 17 Apr 2014 04:58:55 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 856CD1A0118 for <v6ops@ietf.org>; Thu, 17 Apr 2014 04:58:54 -0700 (PDT)
Received: from [192.168.2.100] (ip-64-134-38-51.public.wayport.net [64.134.38.51]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3HBuiv9000419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Apr 2014 04:56:46 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3HBuiv9000419
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397735808; bh=QomKBKhZaIXWJfkcmFkbGN/1CW4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=38RKvQXJ0wD7ja26rh8FJ8K+nJwXIXZ3Qq1N7atNm7rmuKwS0LfEQ9bO4wiLKz4c4 4CzKcs6t++MGsdtk1KZd5rMa+pUmt9p9h+h7SGqRNgW6qzDR1OsqZJG2WNFINaYr6d HvI+bOkjDRLd9GWXqcYb95IsbwEe0WzRsNKYG1Tc=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <alpine.DEB.2.02.1404170658440.10236@uplift.swm.pp.se>
Date: Thu, 17 Apr 2014 04:56:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4EABCE38-7CBA-4C95-84EE-686A2300F26E@delong.com>
References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <alpine.DEB.2.02.1404161034220.10236@uplift.swm.pp.se> <CAKD1Yr2D+ZMi-UctuvrMzyqoHqgBy5O26GODT=bRwq0PsvLgLw@mail.gmail.com> <alpine.DEB.2.02.1404161053110.10236@uplift.swm.pp.se> <20140416155714.GB64039@ricotta.doit.wisc.edu> <alpine.DEB.2.02.1404162310050.10236@uplift.swm.pp.se> <B21C1073-ABBE-44FE-964F-65AD7849CD31@delong.com> <alpine.DEB.2.02.1404170658440.10236@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-Mailer: Apple Mail (2.1874)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 17 Apr 2014 04:56:48 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ovhuZ7MmgxhWCsYXLRAA4lESsV8
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: Thu, 17 Apr 2014 11:58:59 -0000

On Apr 16, 2014, at 9:59 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Wed, 16 Apr 2014, Owen DeLong wrote:
> 
>> 
>> On Apr 16, 2014, at 2:11 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>> 
>>> On Wed, 16 Apr 2014, Dale W. Carder wrote:
>>> 
>>>> So, I am not in favor of adding more hints that may or may not observed that result in additional complexity and create an even more diverse set of behavior that has to be managed.  This is why I think the only real solution that would work in practice is ethertype filtering.
>>> 
>>> That still doesn't solve the problem of the enterprise network being IPv6 only but publishes A and AAAA entries for internal resources on the internal DNS zone, because other networks they have are dual stack.
>> 
>> A host which doesn’t have a v4 route to reach a given A record should ignore said A record pretty harmlessly in favor of the AAAA record. A host that does otherwise is a broken host.
> 
> It has a default IPv4 route out to the mobile network.

Providing a mechanism for an IPv6 LAN to shut down the IPv4 mobile network on a device which is unlikely to be enterprise controlled is not a solution in the real world, but only an attack vector.

Sure, 5 years ago, you could make the case that corporate mobile devices might be under sufficient control that this could be an effective solution in many cases. Today, BYOD is becoming more and more the trend and the percentage of mobile devices under sufficient corporate control to make this feasible is small and shrinking rapidly.

Instead, it simply introduces a DoS vector for additional attacks on mobile devices in the wile, which is pretty much the last thing we need at this point.

So, to make Ted happy… I’ll put this into terms he will hopefully consider appropriate:


This won’t work because it introduces a significant new denial of service path to a fairly large fraction of non-afflicted hosts until such time as they turn off the solution leading to...

This won’t work because the solution will work on such a small fraction of the afflicted hosts as to be ineffective at best.

Owen