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
- Re: Deployment Cases Rémi Després
- Re: Deployment Cases Marc Manthey
- Re: Deployment Cases Rémi Després
- Deployment Cases Hallam-Baker, Phillip
- Re: Deployment Cases Brian E Carpenter
- Re: Deployment Cases Franck Martin
- Re: Deployment Cases Hallam-Baker, Phillip
- Re: Deployment Cases Spencer Dawkins
- Re: Deployment Cases Brian E Carpenter
- Re: Deployment Cases Dave Crocker
- RE: Deployment Cases Christian Huitema
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Franck Martin
- Re: Deployment Cases TS Glassey
- Re: Deployment Cases Iljitsch van Beijnum
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Henning Schulzrinne
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Henning Schulzrinne
- Re: Deployment Cases Franck Martin
- Re: Deployment Cases Ned Freed
- Re: Deployment Cases Julian Reschke
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Iljitsch van Beijnum
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Dave Crocker
- Re: Deployment Cases Tony Finch
- RE: Deployment Cases Ping Pan
- Re: Deployment Cases Franck Martin
- RE: Deployment Cases Ping Pan
- Re: Deployment Cases Franck Martin
- RE: Deployment Cases Hallam-Baker, Phillip
- RE: Deployment Cases Hallam-Baker, Phillip
- Re: Deployment Cases Iljitsch van Beijnum
- RE: Deployment Cases Tony Finch
- Re: Deployment Cases Joel Jaeggli
- RE: Deployment Cases Ping Pan
- RE: Deployment Cases michael.dillon
- Re: Deployment Cases Jeroen Massar
- Re: Deployment Cases Tony Hansen
- Re: Deployment Cases Stewart Bryant
- RE: Deployment Cases michael.dillon
- Re: Deployment Cases Jeroen Massar
- RE: Deployment Cases Hallam-Baker, Phillip
- Re: Deployment Cases Iljitsch van Beijnum
- Re: Deployment Cases Brian E Carpenter
- RE: Deployment Cases Hallam-Baker, Phillip
- Re: Deployment Cases Lars Eggert
- Re: Deployment Cases Marshall Eubanks
- RE: Deployment Cases Hallam-Baker, Phillip