Re: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt

Keith Moore <moore@network-heretics.com> Wed, 02 March 2011 23:08 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: nat66@core3.amsl.com
Delivered-To: nat66@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 105A63A68E8 for <nat66@core3.amsl.com>; Wed, 2 Mar 2011 15:08:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 5fo35om69670 for <nat66@core3.amsl.com>; Wed, 2 Mar 2011 15:08:40 -0800 (PST)
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id D25C33A68B5 for <nat66@ietf.org>; Wed, 2 Mar 2011 15:08:39 -0800 (PST)
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 534FF20992; Wed, 2 Mar 2011 18:09:44 -0500 (EST)
Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 02 Mar 2011 18:09:44 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=zWdbsa0gz/9rsSNRDS3Rk6YYjZg=; b=Z4JujSBnxUI86sg+8/OCP6RXTsJ0w+dUlnrbePoDhu5IVQ60ktuSkaQgHP9E/tmPEdK04rEnoNnOrZWpu8GEAIh8M3w4kDGU01IMfNYM3YuYvC79qYErm2DO94Vf2TM8MM0RFd3czMdNZfTX5STRVeLUZYPGO+ewO3MKOUqulbs=
X-Sasl-enc: 4Kkgu2JspdaLw8Rk143OIl2Hyvf6dGEXYDI75qAEqw5a 1299107384
Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id AF4B444193F; Wed, 2 Mar 2011 18:09:43 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <4D6EB08E.9000109@gmail.com>
Date: Wed, 2 Mar 2011 18:09:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <124ACD72-33A3-4A5F-B253-8EFC6FFBDAA1@network-heretics.com>
References: <20110228223003.13022.10464.idtracker@localhost> <845A4F08-46E7-48EE-B294-0C8368BAD1CB@cisco.com> <20110302072822.GA20321@serpens.de> <5AC61190-49B0-49B5-ACB1-1FA5082C0380@cisco.com> <20110302203006.GI23030@serpens.de> <4D6EB08E.9000109@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1082)
Cc: NAT66 HappyFunBall <nat66@ietf.org>
Subject: Re: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt
X-BeenThere: nat66@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "List for discussion of IPv6-to-IPv6 NAT." <nat66.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nat66>
List-Post: <mailto:nat66@ietf.org>
List-Help: <mailto:nat66-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2011 23:08:41 -0000

On Mar 2, 2011, at 4:03 PM, Brian E Carpenter wrote:

> On 2011-03-03 09:30, S.P.Zeidler wrote:
> ...
>> Which applications will have trouble with address stability and
>> provider independence, thus requiring you to make the benefits of NPTv6
>> line up with the applications you want to use??
> 
> The usual ones - those that for whatever reason have explicit
> dependency on the IP address of the peer. We've known for 15 years
> that this is bad design, but it hasn't stopped us doing it.

Actually, I'd say that we've known for 15 years that having the network alter IP addresses is a bad design, but it hasn't stopped people from doing it.

Application writers have known for about as long that depending on DNS names to work in every instance, and from every location on the Internet, is a bad design.  The widespread use of NATs, coupled with numerous problems in the way DNS is maintained and deployed, mean that there is no single host name or token that an application instance can reliably use to reach a particular peer.

Keith