RE: WG Review: Behavior Engineering for Hindrance Avoidance (beha ve) (fwd)

"Peterson, Jon" <jon.peterson@neustar.biz> Mon, 20 September 2004 21:32 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23794; Mon, 20 Sep 2004 17:32:31 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9VsC-0002fJ-J8; Mon, 20 Sep 2004 17:39:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9VSk-0004O7-9e; Mon, 20 Sep 2004 17:12:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9UAf-00012V-Ap; Mon, 20 Sep 2004 15:49:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05951; Mon, 20 Sep 2004 15:49:55 -0400 (EDT)
Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9UGt-0005Yq-0W; Mon, 20 Sep 2004 15:56:23 -0400
Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by willow.neustar.com (8.12.8/8.11.6) with ESMTP id i8KJn3ZB006454; Mon, 20 Sep 2004 19:49:03 GMT
Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id <MMGH3W9G>; Mon, 20 Sep 2004 15:49:03 -0400
Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF41A3@stntexch04.cis.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: 'Brian E Carpenter' <brc@zurich.ibm.com>, Pekka Savola <pekkas@netcore.fi>
Date: Mon, 20 Sep 2004 15:49:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
X-Mailman-Approved-At: Mon, 20 Sep 2004 17:12:40 -0400
Cc: "'fluffy@cisco.com'" <fluffy@cisco.com>, "'jiri@iptel.org'" <jiri@iptel.org>, iesg@ietf.org, ietf@ietf.org
Subject: RE: WG Review: Behavior Engineering for Hindrance Avoidance (beha ve) (fwd)
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>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc

The consensus of the room at the BEHAVE BoF (which included a number of
prominent NAT vendors) was not only that the IETF could draft
recommendations to make NATs a lesser evil, but further, that some important
NAT vendors would be likely to follow these recommendations. Regardless of
how tactical this work may be, given longer-term solutions to the addressing
problem, I think there is value in executing on it, and a significant
community of interest behind it. 

I must agree with Harald that the number of IPv4 NATs sold is likely to
increase for at least a few more years now, especially in residential
Ethernet hubs/WiFi base stations, most of which have regular firmware
upgrades, etc. I certainly don't think it is impossible for us to influence
the design of these devices. If consumers at least have the option of buying
such devices that are more favorable to their applications, then I think we
will have made a significant difference here.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Brian E Carpenter [mailto:brc@zurich.ibm.com]
> Sent: Monday, September 20, 2004 5:04 AM
> To: Pekka Savola
> Cc: iesg@ietf.org; ietf@ietf.org
> Subject: Re: WG Review: Behavior Engineering for Hindrance Avoidance
> (behave) (fwd)
> 
> 
> I think the real point is that it's quite unrealistic at this
> stage in the history of NAT to imagine that we can make the mess
> (which was inevitable anyway) any better by codifying the
> least-bad form of NAT behaviour. The NAT codes are shipped, burnt
> into lots of devices, and the IETF can't do much about it.
> So I think this would be wasted effort.
> 
>     Brian
> 
> Pekka Savola wrote:
> > [[ Resending the comment to ietf@ietf.org as
> > ietf-behave@list.sipfoundry.org illegitimately *) automatically
> > rejects the posts by non-subscribers.
> > 
> > *) http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt
> > ]]
> > 
> > On Fri, 17 Sep 2004, The IESG wrote:
> > 
> >>A new IETF working group has been proposed in the Transport 
> Area.  The IESG has 
> >>not made any determination as yet. The following 
> description was submitted, 
> >>and is provided for informational purposes only. Please 
> send your comments to 
> >>the IESG mailing list (iesg@ietf.org) by September 24.
> > 
> > 
> > I do not think it's useful to spend too much energy in trying to 
> > figure how NATs work (or do not work).
> > 
> > Further, even though the draft charter talks about IPv6 and eventual
> > deployment, it seems to be ignoring the fact that if you use an IPv6
> > transition mechanism which is specifically designed to traverse NATs
> > (see e.g., draft-huitema-v6ops-teredo-xx [this should probably be on
> > the 'reading list']), you don't have these problems.
> > 
> > And if you are able to use a transition mechanism which is 
> not tied to
> > the IP versions supported by your ISP own, the barrier for IPv6
> > deployment should be significantly reduced.
> > 
> > Therefore the issue seems to boil down to whether the NAT traversal
> > mechanism described in draft-huitema-v6ops-teredo-xx is 
> sufficient to
> > traverse the NATs, and whether the support for something like Teredo
> > is expected to be sufficiently commonplace to depend on it.
> >  
> 

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