RE: IPv4 Outage Planned for IETF 71 Plenary

"Tony Hain" <alh-ietf@tndh.net> Wed, 19 December 2007 22:04 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 1J571N-0000Ya-1L; Wed, 19 Dec 2007 17:04:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J571L-0000YI-5B for ietf@ietf.org; Wed, 19 Dec 2007 17:04:07 -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 1J571K-00016c-Lv for ietf@ietf.org; Wed, 19 Dec 2007 17:04:07 -0500
Received: from eagle (192.168.123.10:2483) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id <SB58813> for <ietf@ietf.org> from <alh-ietf@tndh.net>; Wed, 19 Dec 2007 14:04:02 -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> <2788466ED3E31C418E9ACC5C31661557084FAF@mou1wnexmb09.vcorp.ad.vrsn.com> <083301c84284$c835e270$58a1a750$@net> <tsl8x3qnznl.fsf@mit.edu>
In-Reply-To: <tsl8x3qnznl.fsf@mit.edu>
Date: Wed, 19 Dec 2007 14:03:56 -0800
Message-ID: <085301c8428b$0d6ffeb0$284ffc10$@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: AchChgxUYpMfVAyeT/uHtBnZZbr8awAArhQA
Content-Language: en-us
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: ietf@ietf.org, iaoc@ietf.org, 'John C Klensin' <john-ietf@jck.com>, 'IETF Chair' <chair@ietf.org>, dcrocker@bbiw.net, 'Pete Resnick' <presnick@qualcomm.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 Hartman wrote:
> I think that real ISPs will ship NATs that comply with behave.  If you
> think that address independent and endpoint independent mapping
> behavior with endpoint dependent filtering behavior counts as punching
> holes then I disagree with you.

Establishing persistent state on an ISP infrastructure device is punching a
hole. It doesn't matter if that is a nat, or a STUN relay, the fact that a
customer locked it down will raise the potential for contention, and in fact
creates a routing entry that is not under the ISP's control. 

> 
> Why will ISPs support this?  Because their customers voip phones and
> games will want it.

They are more likely to want to force the phone traffic through a call
control point so they can count bits and bill minutes. 

I am willing to conceded on the behave point because client side actions
really don't matter, but I want to see multiple people running mta's and
independent web servers on the nat'd IETF network, with active connection
attempts to them from the outside. Nobody can physically configure the most
public nat, and no signaling of it is allowed because it is operated by a
third party that doesn't trust you. If you want a real indication of future
problems, run real services from behind the magic solution and document its
complete failure.

Tony 



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