[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: IP network address assignments/allocations information?
From:       Valdis.Kletnieks () vt ! edu
Date:       1999-11-30 23:25:24
[Download RAW message or body]


On Tue, 30 Nov 1999 13:37:33 PST, "Tony Hain (Exchange)" said:
> This is the kind of BS that keeps these debates running. NAT problems exist
> anytime a connection originates on the public side and there is not a
> preexisting clear mapping to the private side. I didn't pick on Real Player

I said:
> Well.. Urm... TCP and UDP both assume that one endpoint is talking
> directly in real time to another endpoint.  The NAT problems only
> start when the protocol carries IP address/port information (such
> as the FTP 'PORT' command), and the NAT isn't aware of that protocol's
> translation requirements (If you see *this* at offset 80 of *that*
> packet, smash it to read *foobar* instead).

I think we're actually saying the same thing here, and are violently
in agreement, from different viewpoints. A 'pre-existing clear
mapping' is what the NAT needs in order to do the datastream
manipulations needed.  Of course, if there exists such a mapping, but
your NAT is older or for other reasons doesn't understand/implement
it, you're still stuck.

I meant "the problems only start" in the context of the breakage a NAT
renders on a single connection that is assuming it's able to make an
unmangled, unmodified end-to-end connection.  If the NAT is able to
handle the translation, the connection still suceeds.  If the NAT
doesn't do it, the connection loses.  As Keith Moore pointed out in
http://www.cs.utk.edu/~moore/what-nats-break.html there are other
contexts *outside* that context that NAT has an impact on...

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech


[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]