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

John C Klensin <john-ietf@jck.com> Tue, 21 September 2004 02:30 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 WAA17505; Mon, 20 Sep 2004 22:30:58 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9aX4-0000JZ-Mv; Mon, 20 Sep 2004 22:37:30 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9aP1-0007kb-I5; Mon, 20 Sep 2004 22:29:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9aKu-0006iH-K6; Mon, 20 Sep 2004 22:24:56 -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 WAA17190; Mon, 20 Sep 2004 22:24:54 -0400 (EDT)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9aRB-0000DS-6U; Mon, 20 Sep 2004 22:31:26 -0400
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1C9aKp-000LH5-S2; Mon, 20 Sep 2004 22:24:51 -0400
Date: Mon, 20 Sep 2004 22:24:51 -0400
From: John C Klensin <john-ietf@jck.com>
To: Harald Tveit Alvestrand <harald@alvestrand.no>, Michael Richardson <mcr@sandelman.ottawa.on.ca>, iesg@ietf.org, ietf@ietf.org
Message-ID: <936CCF554FA0DE0E7DB6D470@scan.jck.com>
In-Reply-To: <8D335B8F20E6A6FD4CF2CE18@askvoll.hjemme.alvestrand.no>
References: <Pine.LNX.4.44.0409200834140.22679-100000@netcore.fi> <414EC71C.6030109@zurich.ibm.com> <239B699D32BD4A0F33F883AB@B50854F0A9192E8EC6CDA126> <4924.1095705531@marajade.sandelman.ottawa.on.ca> <8D335B8F20E6A6FD4CF2CE18@askvoll.hjemme.alvestrand.no>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Subject: Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (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: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit


--On Monday, 20 September, 2004 21:38 +0200 Harald Tveit
Alvestrand <harald@alvestrand.no> wrote:

>>   Do we really want customers of NAT devices to be happy?
> 
> Given that I'm one of them, and will continue to be one until
> the IPv4 Internet fades to where I can ignore it.... yes.

Harald, let me make an observation that I made a few weeks ago
that that, to my astonishment, actually made Latif happy.

In your case, this is just a guess, but you are probably behind
a NAT for two reasons (Melinda's observation about increasing
corporate policies might well be a third).  One is the perceived
shortage of IPv4 space.  Whether that perception is real, or is
a marketing mechanism by ISPs who would prefer to sell you
something more expensive, or is just a delusion is irrelevant
for this purpose.  The point is that you are behind a NAT, in
part, because no one has given you enough IPv4 space.

The second is that, if I'm a vendor of cheap "cable/ DSL
routers", I've got to love NATs.  My device gets one address
from the ISP.  Every single clueless customer of the device has
the same address space, the same netmask, etc.  It is a customer
support dream because no one calls up and asks unique questions
about address ranges, funny masks, trick routing between
addresses on both sides of the router, and so on.  Until and
unless we have arrangements for IPv6 that use public address
space but

	* can be built into cheap products,  and
	
	* don't impose any greater customer support costs on
	those vendors, or the ISPs whose customers patronize
	them, then the current devices do, 

I think it is safe to predict that IPv6 will not reduce the NAT
frequency for SOHO situations one bit.

I hate that conclusion but I fear it is realistic.  To a certain
extent, we are _causing_ NATs, especially in IPv6 environments.
Now, is it worthwhile, given that, to allocate resources into
this proposed WG or should the resources be put into tidying up
the edges of IPv6 configuration?  I don't know, but I strongly
suspect that the people who are likely to do the work are
different.  And, if they are, this is probably a good idea,
however distasteful some of us find it.

     john


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