Re: IP network address assignments/allocations information?

Daniel Senie <dts@senie.com> Tue, 30 November 1999 14:30 UTC

Received: by ietf.org (8.9.1a/8.9.1a) id JAA21646 for ietf-outbound.10@ietf.org; Tue, 30 Nov 1999 09:30:03 -0500 (EST)
Received: from senie.com (anise.senie.com [199.125.85.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14145 for <ietf@ietf.org>; Tue, 30 Nov 1999 09:15:23 -0500 (EST)
Received: from senie.com (anise.senie.com [199.125.85.28]) by senie.com (8.8.7/8.8.7) with ESMTP id JAA31710 for <ietf@ietf.org>; Tue, 30 Nov 1999 09:15:23 -0500
Message-ID: <3843DBF9.C8332938@senie.com>
Date: Tue, 30 Nov 1999 09:15:21 -0500
From: Daniel Senie <dts@senie.com>
Organization: Amaranth Networks Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: IP network address assignments/allocations information?
References: <4.2.2.19991130070348.00a254f0@lint.cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Paul Ferguson wrote:
> 
> Hi Tony,
> 
> Well, the statement below is not true -- I sit behind a NAT/PAT
> device and Real PLayer works just fine for me. I've only found a
> couple of applications that will not work for me (e.g. ICQ, NTP,
> SNMP), but then again, I'm not a gamer so I can't speak to the
> broader range of applications that it _does_ break.

Real added features to their protocol which permit it to work around
most anything. These include using TCP instead of UDP if UDP doesn't
work (probably how you're getting your streams, if you look at the
statistics).

I have found NTP (ok, SNTP) actually works fine through the NAPT
implementation I use. A very large percentage of the protocols used by
actual end users really do work, provided the servers are out on the
public network.

> 
> In any event, I've always personally been of the opinion that
> if applications don't work in the face of NAT, then the
> applications themselves are functionally deficient and should be
> fixed.  :-)

Indeed. While some in the IETF have stomped their feet and railed about
how bad NAT is architecturally (something I suspect most folks concede)
they've somehow believed it would be possible to offer a better solution
and get NAT eliminated before it's widely deployed. Reality: it's
extremely widely deployed, and must be taken into consideration when
designing protocols. Those, like Real, who find ways to make their
protocols work with NAT clearly will do better than those who do not.

I've have thought I'd get a lot of feedback on the draft I've been
working on in this area, draft-ietf-nat-app-guide-02.txt, but that's not
been the case. New protocols should, in my opinion, provide descriptions
of how they work or don't work with NAT. If there is a reason why they
aren't going to work (carriage of port or address information), a
description of how to build an Application Layer Gateway (ALG) should be
provided.

We are at a crossroads where architectural purity has intersected
operational reality.

> At 10:44 AM 11/29/1999 -0800, Tony Hain (Exchange) wrote:
> 
> >1) Yes ... We have been forced into a world of NAT where simple
> >applications such as Real Player won't work without real-time manual
> >intervention at the NAT.


-- 
-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.            http://www.amaranthnetworks.com