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

Pekka Savola <> Mon, 20 September 2004 05:43 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA14854; Mon, 20 Sep 2004 01:43:04 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C9H3D-0004xr-48; Mon, 20 Sep 2004 01:49:24 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C9Gtr-0003XC-FV; Mon, 20 Sep 2004 01:39:43 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C9GtA-0003Pm-Nr; Mon, 20 Sep 2004 01:39:00 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA14661; Mon, 20 Sep 2004 01:38:59 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C9GzG-0004ss-GS; Mon, 20 Sep 2004 01:45:19 -0400
Received: from localhost (pekkas@localhost) by (8.11.6/8.11.6) with ESMTP id i8K5cSV23938; Mon, 20 Sep 2004 08:38:28 +0300
Date: Mon, 20 Sep 2004 08:38:28 +0300
From: Pekka Savola <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
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: 9ed51c9d1356100bce94f1ae4ec616a9

[[ Resending the comment to as illegitimately *) automatically
rejects the posts by non-subscribers.


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 ( 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.
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Ietf mailing list