IETF Logo Mail Archive

Re: [v6ops] Please review the No IPv4 draft

Owen DeLong <owen@delong.com> Wed, 16 April 2014 21:18 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 5483D1A02CE for <v6ops@ietfa.amsl.com>; Wed, 16 Apr 2014 14:18:50 -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 e8csyx8O-1i6 for <v6ops@ietfa.amsl.com>; Wed, 16 Apr 2014 14:18:46 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA371A01C1 for <v6ops@ietf.org>; Wed, 16 Apr 2014 14:18:46 -0700 (PDT)
Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3GLGiRx005791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Apr 2014 14:16:55 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3GLGiRx005791
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397683015; bh=rEXGyZJ8BOuQMgEjpmCBZ7Bb0Ds=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fOokorkwmfV+suazIj9YI3Elr3sobupfP/qiGQDMTEROH5exy2e+dawudVUW9ilxp PmPJf83q+tvsXcFF09fJ1bZ2ty7XTPl3b/eoSiIRoXibFSKebAYJE+LBt5UL7si+Q+ Sl0KmfFHE28fjgqW3R5aiacd79Ny8BYuNvasw28w=
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.1404162310050.10236@uplift.swm.pp.se>
Date: Wed, 16 Apr 2014 14:16:40 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B21C1073-ABBE-44FE-964F-65AD7849CD31@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>
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]); Wed, 16 Apr 2014 14:16:55 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Fx4JIIe1IdSkF2stcGtUOkDfW-U
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, 16 Apr 2014 21:18:50 -0000

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.


Owen

v2.23.0 | Report a Bug | By Email