Re: IPv4 Outage Planned for IETF 71 Plenary

Eric Rescorla <ekr@networkresonance.com> Thu, 20 December 2007 16:44 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 1J5OVP-0007CM-Nw; Thu, 20 Dec 2007 11:44:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J56Us-0001zK-1l; Wed, 19 Dec 2007 16:30:34 -0500
Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J56Ur-0007xE-NI; Wed, 19 Dec 2007 16:30:34 -0500
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2C22D5081A; Wed, 19 Dec 2007 13:30:10 -0800 (PST)
Date: Wed, 19 Dec 2007 13:30:10 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: alh-ietf@tndh.net
In-Reply-To: <083301c84284$c835e270$58a1a750$@net>
References: <E1J3IFS-0002yV-CG@ietf.org> <200712142154.lBELs1ne090300@drugs.dv.isc.org> <200712181644.lBIGisBx090029@romeo.rtfm.com> <476800BC.5030504@dcrocker.net> <38033976C354EAB237181075@[192.168.101.1]> <p06250103c38dc78214d8@[74.134.5.163]> <080c01c84276$ec9a79e0$c5cf6da0$@net> <tsl8x3qphdd.fsf@mit.edu> <2788466ED3E31C418E9ACC5C31661557084FAF@mou1wnexmb09.vcorp.ad.vrsn.com> <083301c84284$c835e270$58a1a750$@net>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20071219213010.2C22D5081A@romeo.rtfm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
X-Mailman-Approved-At: Thu, 20 Dec 2007 11:44:17 -0500
Cc: ietf@ietf.org, iaoc@ietf.org, 'John C Klensin' <john-ietf@jck.com>, 'IETF Chair' <chair@ietf.org>, dcrocker@bbiw.net, 'Pete Resnick' <presnick@qualcomm.com>, 'Sam Hartman' <hartmans-ietf@mit.edu>, iesg@ietf.org
Subject: Re: IPv4 Outage Planned for IETF 71 Plenary
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>
Errors-To: ietf-bounces@ietf.org

At Wed, 19 Dec 2007 13:19:03 -0800,
Tony Hain wrote:
> 
> Hallam-Baker, Phillip wrote:
> > The double NAT approach is much closer to what the actual 
> > transition is going to look like. The only difference is that 
> > I think we might just be able to work out a viable means of 
> > punching holes so that video-conferencing works if we actually 
> > set our minds to it.
> 
> Since you are the one that is routinely taking the operator's position, why
> should we allow punching holes in the IETF nat when that will never happen
> in a real ISP? No ISP is going to trust their customer base to modify the
> configuration of their infrastructure, so whatever the IETF experiment ends
> up being has to mimic that reality. 

Tony,

I'm trying to understand on what evidence you're basing this
assertion.  Remember that the IETF hole punching techniques only
implicitly modify the configuration of the NAT, relying on the
ordinary NAT state management mechanisms.

I would encourage you to read 
draft-sipping-stucker-media-path-middleboxes-00.txt, which 
describes the sorts of enforcement mechanisms that 3G style
providers are starting to deploy, which indeed do incorporate
hole punching mechanisms for the media traffic.

-Ekr


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