Re: [v4v6interim] Single namespace

Andrew Sullivan <ajs@commandprompt.com> Thu, 02 October 2008 04:52 UTC

Return-Path: <v4v6interim-bounces@ietf.org>
X-Original-To: v4v6interim-archive@ietf.org
Delivered-To: ietfarch-v4v6interim-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2BC28C0CF; Wed, 1 Oct 2008 21:52:05 -0700 (PDT)
X-Original-To: v4v6interim@core3.amsl.com
Delivered-To: v4v6interim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272913A6835 for <v4v6interim@core3.amsl.com>; Wed, 1 Oct 2008 21:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.735
X-Spam-Level:
X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17v6qQFvzSZT for <v4v6interim@core3.amsl.com>; Wed, 1 Oct 2008 21:52:03 -0700 (PDT)
Received: from lists.commandprompt.com (host-159.commandprompt.net [207.173.203.159]) by core3.amsl.com (Postfix) with ESMTP id 4CF7C3A6803 for <v4v6interim@ietf.org>; Wed, 1 Oct 2008 21:52:03 -0700 (PDT)
Received: from commandprompt.com ([206.172.31.194]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m924u72V019000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <v4v6interim@ietf.org>; Wed, 1 Oct 2008 21:56:12 -0700
Date: Thu, 02 Oct 2008 00:52:21 -0400
From: Andrew Sullivan <ajs@commandprompt.com>
To: v4v6interim@ietf.org
Message-ID: <20081002045221.GA36568@commandprompt.com>
References: <BD0BD783-9F12-4415-85B3-9593584BB12D@cisco.com> <090C6392-9082-4660-AE68-FA384B788C03@apple.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <090C6392-9082-4660-AE68-FA384B788C03@apple.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Wed, 01 Oct 2008 21:56:13 -0700 (PDT)
Subject: Re: [v4v6interim] Single namespace
X-BeenThere: v4v6interim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of coexistence topics for the 01-Oct-2008 v4-v6 coexistence interim meeting <v4v6interim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/v4v6interim>
List-Post: <mailto:v4v6interim@ietf.org>
List-Help: <mailto:v4v6interim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

On Wed, Oct 01, 2008 at 11:34:30AM -0700, james woodyatt wrote:

> The "gross indecency" here is, apparently, admitting in public that we 
> cannot escape the need to amend the DNS standards to recognize, for the 
> first time, that we need more than one public horizon, i.e. the V4V6COEX 
> public horizon and the IPv6 public horizon.

While I understand that suggestion, and even have a certain amount of
sympathy with it, I note that there's a practical reason that many
DNS-heads don't like multiple versions of the namespace: they tend to
leak into other contexts.  Since we have experience with this
already, it would be prudent to plan that such leaks will be part of
any future deployment of "split-brain" approaches.

This is bad enough in the context of corporate NATs with RFC 1918
addresses inside, but at least one has a hope of spotting this (by
virtue of the 1918 address itself).  I appreciate what Fred said
earlier, that applications don't always care about the distinction
between 1918 and non-1918 address spaces; but the distinction is an
old one, and applications (or just help desk workers) that need to
deal with these cases can use that distinction to help them.  Since by
definition, in this case, what we're trying to address are
applications that can't learn new things (or they'd use IPv6
natively), I'm pretty worried that we'll create new modes of failure
that will be very hard to troubleshoot, because we'll have inserted a
new device in the network whose whole purpose is to intercept DNS
packets and change them into something else.

To be clear, I'm not saying, "Disaster! Bad! Evil! No! DNS purity!"
I'm just raising a caution that there seems to be a boom on for
split-brain DNS answers, and such answers come not only with DNSSEC
problems, but other issues as well.

A

-- 
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim