Re: [v4v6interim] Single namespace

Iljitsch van Beijnum <iljitsch@muada.com> Thu, 02 October 2008 09:48 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 EEE503A6C00; Thu, 2 Oct 2008 02:48:12 -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 76C6A3A6C00 for <v4v6interim@core3.amsl.com>; Thu, 2 Oct 2008 02:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 gwpMpL8VM1gk for <v4v6interim@core3.amsl.com>; Thu, 2 Oct 2008 02:48:11 -0700 (PDT)
Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 86F2F3A6803 for <v4v6interim@ietf.org>; Thu, 2 Oct 2008 02:48:11 -0700 (PDT)
Received: from c0248.aw.cl.cam.ac.uk (c0248.aw.cl.cam.ac.uk [128.232.100.248]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m929mNjc082763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Oct 2008 11:48:23 +0200 (CEST) (envelope-from iljitsch@muada.com)
Message-Id: <839EAB12-81CD-4FD7-BCB8-7A76D9222180@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Andrew Sullivan <ajs@commandprompt.com>
In-Reply-To: <20081002045221.GA36568@commandprompt.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 02 Oct 2008 10:48:30 +0100
References: <BD0BD783-9F12-4415-85B3-9593584BB12D@cisco.com> <090C6392-9082-4660-AE68-FA384B788C03@apple.com> <20081002045221.GA36568@commandprompt.com>
X-Mailer: Apple Mail (2.929.2)
Cc: v4v6interim@ietf.org
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

On 2 okt 2008, at 5:52, Andrew Sullivan wrote:

> 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).

If we use a well known prefix for the translator then the problem is  
no worse than in the RFC 1918 case.

> 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.

Nobody wants to put a device in the network that _intercepts_ DNS  
packets.
_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim