Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)

Bob Hinden <> Mon, 20 September 2004 22:47 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA03154; Mon, 20 Sep 2004 18:47:56 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C9X3D-0004zv-0J; Mon, 20 Sep 2004 18:54:27 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C9WmJ-0005gn-NP; Mon, 20 Sep 2004 18:36:59 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C9WMl-00039m-1K; Mon, 20 Sep 2004 18:10:35 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA27781; Mon, 20 Sep 2004 18:10:32 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C9WSy-0003kU-UP; Mon, 20 Sep 2004 18:17:02 -0400
Received: (from root@localhost) by (8.11.0/8.11.0-DARKSTAR) id i8KLh0v21083; Mon, 20 Sep 2004 14:43:00 -0700
X-mProtect: <200409202143> Nokia Silicon Valley Messaging Protection
Received: from (, claiming to be "") by smtpdHbLLCQ; Mon, 20 Sep 2004 14:42:59 PDT
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 20 Sep 2004 15:09:33 -0700
To: Harald Tveit Alvestrand <>
From: Bob Hinden <>
In-Reply-To: <239B699D32BD4A0F33F883AB@B50854F0A9192E8EC6CDA126>
References: <> <> <239B699D32BD4A0F33F883AB@B50854F0A9192E8EC6CDA126>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc:, Pekka Savola <>,
Subject: Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228


>My take (which is obviously biased) is that the number of NAT devices 2 
>years from now is likely to be significantly larger than the number of NAT 
>devices currently deployed.
>And - here I am making a real leap of faith - if the IETF recommendations 
>for NAT devices make manufacturers who listen to them create NAT devices 
>that make their customers more happy, then many of these new NAT devices 
>may  be conformant to IETF recommendations.

I think this ship has left port a long time ago and the likelihood that the 
IETF can now effect enough change to make it possible to write new 
applications that work consistently in the presence of NATs is very 
low.   The installed base is much to large and NAT is showing up in devices 
being built by people who don't pay too much attention to the IETF.  The 
same folks who do not build in IPv6, who break path MTU discovery, who 
strip out TCP options, etc.  Now we expect them to build "good" NATs...

This is the IETF and if there is a constituency for working on this then I 
think it should happen.  However, I hope no one will be surprised in 2-3 
years that nothing much has changed.


Ietf mailing list