Subject: RE: IP network address assignments/allocations information?

From: Paul Ferguson <[email-masked]>
Date: Tue, 30 Nov 1999 07:10:05 -0500

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.

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.  :-)

Cheers,

- paul

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.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 30 Nov 1999 14:00:01 +0000 (GMT)

On Tue, 30 Nov 1999, Paul Ferguson wrote:

> device and Real PLayer works just fine for me.

There are a number of different types of NAT - which the NAT working
group has described. These break application assumptions to a greater
or lesser extent.

notice that Tony said 'a world', not 'the world'.

> I've only found a

Again, you don't specify the kind of NAT implementation.

I don't believe applications are functionally deficient if they happen
to require bidirectional NAT or twice NAT along with a DNS ALG to
function properly; rather, it's the NAT implementation that's
clearly deficient.

http://www.ietf.org/html.charters/nat-charter.html

L.

> >applications such as Real Player won't work without real-time manual 

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 30 Nov 1999 14:00:01 +0000 (GMT)

L.

---

From: Daniel Senie <[email-masked]>
Date: Tue, 30 Nov 1999 09:15:21 -0500

> 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.

> applications themselves are functionally deficient and should be

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.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com

---

From: Daniel Senie <[email-masked]>
Date: Tue, 30 Nov 1999 09:15:21 -0500

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 30 Nov 1999 11:33:26 -0800

Bottom line, NAT or changing destination addresses on the fly breaks the 
end-to-end nature of Internetworking. This is true not only for IP, for for 
other protocols as well. Some may recall older DECNET IV networks that 
exceeded the maximim ~65K nodes. We had to come up with a scheme to make 
that work and it was ugly.

Even though we are not in the same situation as DECNET IV (we still have a 
lot of addresses available), we are (for other reasons already discussed) 
stuck with this NAT situation for the foreseeable future. It does 
absolutely no good to complain about the state of the world. It is what it 
is and all the complaining by the IETF won't change it.

It would do a lot of good to find a way to dig ourselves out of this 
situation. The Internet isn't going to stop growing and there will be 
future applications that require or desire a heck of a lot of public IP 
addresses. Other future applications may compromise some useful feature to 
be "NAT Friendly". This is not a good thing.

So we need to find a way to bridge ourselves to a new addressing 
architecture. IPv6 is one such architecture, but getting there is very, 
very difficult. So we need some alternative solutions in the meantime. And 
we need to continue to reassess how we might transition to such an 
architecture. The Internet will not stop changing so we need to be fluid in 
our transition schemes.

The IETF, IAB and IRTF are struggling with this and there is no neat short 
term fix. The NAT WG and the NGTRANS WG are a couple of places (I'm sure 
there are others) where folks are trying to help things along and we would 
appreciate your support.

P.S. Let me take this public moment to ask (beg!) for review of
draft-ietf-nat-protocol-complications-01.txt which I'm editing. If
you know of any particular protocol that has difficulty with basic
Network Address Translation, please send me the info in the format
of the above draft.

- Matt Holdrege - NAT WG co-chair

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 30 Nov 1999 11:33:26 -0800