RE: Deployment Cases

"Hallam-Baker, Phillip" <pbaker@verisign.com> Thu, 03 January 2008 20:38 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAWpS-0005jB-0f; Thu, 03 Jan 2008 15:38:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAWpQ-0005j6-SD for ietf@ietf.org; Thu, 03 Jan 2008 15:38:12 -0500
Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAWpP-0007tN-TP for ietf@ietf.org; Thu, 03 Jan 2008 15:38:12 -0500
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id m03KVGg3017365; Thu, 3 Jan 2008 12:31:16 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jan 2008 20:38:07 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 03 Jan 2008 12:38:06 -0800
Message-ID: <2788466ED3E31C418E9ACC5C31661557084FCF@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Deployment Cases
Thread-Index: AchOQMhSy4/lyRUYQCGxe2w7HTC8LwABkmZ/
References: <2788466ED3E31C418E9ACC5C316615570462E8@mou1wnexmb09.vcorp.ad.vrsn.com><066001c84892$a33f7850$6601a8c0@china.huawei.com><4774103E.4000407@dcrocker.net><AFE0AC8DCDE68842B94E8EC69D5F21D635E6CD4501@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com><47744661.3060808@bbiw.net><47749A8B.1080502@sopac.org><9BE39E8B-7B1F-4243-985C-025A24D105EB@muada.com><47794C95.7050005@dcrocker.net><1474DFBA-8B77-46B8-AABA-373689555331@cs.columbia.edu><47795548.7000303@bbiw.net><66006D08-6F13-4BDF-8960-3D747F44FB0E@cs.columbia.edu><477970FE.8090302@sopac.org><01MPJP2QLGWE00BDC1@mauve.mrochek.com> <2788466ED3E31C418E9ACC5C31661557084FC2@mou1wnexmb09.vcorp.ad.vrsn.com> <D03E4899F2FB3D4C8464E8C76B3B68B001AB742C@E03MVC4-UKBR.domain1.systemhost.net> <477C2B52.8040408@spaghetti.zurich.ibm.com> <D03E4899F2FB3D4C8464E8C76B3B68B001AB753F@E03MVC4-UKBR.domain1.systemhost.net> <477CBC70.6080402@spaghetti.zurich.ibm.com> <2788466ED3E31C418E9ACC5C31661557084FCB@mou1wnexmb09.vcorp.ad.vrsn.com> <47! 7D3A98.50 30206@gmail.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-OriginalArrivalTime: 03 Jan 2008 20:38:07.0113 (UTC) FILETIME=[8BDC1F90:01C84E48]
X-Spam-Score: -2.2 (--)
X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d
Cc: ietf@ietf.org
Subject: RE: Deployment Cases
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1323830802=="
Errors-To: ietf-bounces@ietf.org

Brian,
 
Yes I did object, we had the same argument then.
 
At the time my position was a distinctly minority one. Today I think I have won that argument and I think that people are looking at NAT as an opportunity, not merely an annoyance.
 
NAT is only about 30% of the solution. The other two essential components are an administration model for the transition and a new layering model that properly abstracts and separates the applications layer from the layer we are attempting to change.
 
At this point I am pretty confident that people are going to do the right thing on NAT. Certainly there are people who know a lot more than me at that layer of the stack. I can add most value here by pushing on the other two pieces of the puzzle where I believe change is necessary and where currently my position is still a minority one.
 
 
IPv6 transition is not going to happen unless it is 100% transparent to application developers and end users.
 

________________________________

From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
Sent: Thu 03/01/2008 2:42 PM
To: Hallam-Baker, Phillip
Cc: Jeroen Massar; michael.dillon@bt.com; ietf@ietf.org
Subject: Re: Deployment Cases



On 2008-01-04 05:30, Hallam-Baker, Phillip wrote:
> Yes, as you point out the generic answer to the problem is NAT-PT which was recently squashed after a cabal got together.

That's a bizarre statement. Which of the technical arguments
in RFC 4966 are you referring to as being products of a cabal?
Did you raise your objections to those arguments during the
IETF Last Call on draft-ietf-v6ops-natpt-to-historic
(issued 2007-03-08)?

> My point here is that the thinking on the transition in the IETF to date has all been of the form 'well everyone is going to have to become like us, only they can't possibly expect to so its a bit of a problem but not our problem'.

Have you been contributing to ngtrans and v6ops over the last
ten years to correct this wrong way of thinking?

> 
> I received a lot of criticism when I first proposed that the IETF embrace NAT as a transition tool rather than deprecate it. The idea that we should actively encourage the NAT-ing of IPv4 was considered as unacceptable as Brian and others now find my proposals for changing the way that the IETF operates and the considerations it takes into account.

That comparison is a category mistake. And given that NAT-PT was defined
as a co-existence technique in February 2000 (RFC 2766), I'm not sure
I see your point exactly.

> I don't see much dispute on that point today. Pretty much everyone seems to now accept that we are going to run out of IPv4 addresses before IPv6 deployment is complete and that some form of address sharing is therefore inevitable. What we have failled to do so far is to act on that.

Well, the original plan was that IPv6 would deploy before sharing
of IPv4 addresses started. That didn't happen and of course it's
unfortunate. It's true that those of us who were aghast at the
negative consequences of address sharing did nothing to make it work
better, and wrote about the negative consequences. I make no apology
for my part in that.

Given today's reality, some of the aghast are thinking actively about
how to define a method that isn't broken in the ways described by
RFC 4966.

    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf