RE: IPv4 Outage Planned for IETF 71 Plenary

"Tony Hain" <alh-ietf@tndh.net> Wed, 19 December 2007 21:10 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 1J56Br-00069m-Pm; Wed, 19 Dec 2007 16:10:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J56Bq-000675-3W for ietf@ietf.org; Wed, 19 Dec 2007 16:10:54 -0500
Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J56Bp-0007Xo-HN for ietf@ietf.org; Wed, 19 Dec 2007 16:10:54 -0500
Received: from eagle (192.168.123.10:1265) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id <SB582DD> for <ietf@ietf.org> from <alh-ietf@tndh.net>; Wed, 19 Dec 2007 13:10:49 -0800
From: Tony Hain <alh-ietf@tndh.net>
To: 'Sam Hartman' <hartmans-ietf@mit.edu>
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>
In-Reply-To: <tsl8x3qphdd.fsf@mit.edu>
Date: Wed, 19 Dec 2007 13:10:43 -0800
Message-ID: <083201c84283$9e4489e0$dacd9da0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AchCfHSeoVPVZe4qQVuO46To9nBCqAABX/KQ
Content-Language: en-us
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: ietf@ietf.org, iaoc@ietf.org, 'Pete Resnick' <presnick@qualcomm.com>, 'IETF Chair' <chair@ietf.org>, dcrocker@bbiw.net, 'John C Klensin' <john-ietf@jck.com>, 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
Reply-To: alh-ietf@tndh.net
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

Sam,

While I understand the virtue in behave-compatible nats, how realistic is it
to believe that any service provider is going to allow a consumer to
directly signal their infrastructure? This assumption was the failing of
RSVP as an endpoint qos tool. 

There is lots of noise about ISPs just putting up massive nat farms to push
their customers out, but when it comes right down to it there is no way that
will work for anything but the most trivial client apps. All of the
assumptions about nat working today are built around local control of the
mappings. When that mapping function has to move to a third party, all bets
are off. Worse, when that third party has strong disincentives which keep
them from allowing their customers to punch holes, there is no chance that
apps will work. ISPs are disincented by even the simple issue of
after-the-fact diagnostics being more complicated by dynamic mappings, let
alone the problem of conflict resolution between customers. 

Behave compatible nats are a nice concept for enterprises with multiple
levels of internal nat, but third-party trust issues will kill any real
deployment of a signaling based approach. 

Tony

> -----Original Message-----
> From: Sam Hartman [mailto:hartmans-ietf@mit.edu]
> Sent: Wednesday, December 19, 2007 12:19 PM
> To: alh-ietf@tndh.net
> Cc: 'IETF Chair'; ietf@ietf.org; iaoc@ietf.org; 'John C Klensin';
> dcrocker@bbiw.net; 'Pete Resnick'; iesg@ietf.org
> Subject: Re: IPv4 Outage Planned for IETF 71 Plenary
> 
> >>>>> "Tony" == Tony Hain <alh-ietf@tndh.net> writes:
> 
>     Tony> the right experiment. It is not right because it does
>     Tony> nothing positive, other than the threat -maybe- spurring
>     Tony> some action. A more realistic experiment would be to run the
>     Tony> entire week with a double-nat for IPv4 (and nats between the
>     Tony> access points to simulate consumer-to-consumer
>     Tony> configurations), where the most public one has absolutely no
>     Tony> provision for punching holes (because realistically an ISP
>     Tony> is not going to punch inbound holes for its customers, or
>     Tony> allow them to).
> 
> I strongly support this experiment and believe it would be a really
> good idea to run.  I do think behave-compatible nats should be used,
> but besides that, I think the experiment you propose is far more
> valuable than the v6-only experiment.


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