UDP, TCP, and NAT (was...)

[Thomas Charron]

On 7/15/07, Ben Scott <dragonhawk at gmail.com> wrote:
> On 7/13/07, Thomas Charron <twaffle at gmail.com> wrote:
> > ...  UDP is by DEFINITION connectionless, and TCP is by DEFINITION
> > connection oriented!
>   Um... I just wrote exactly that.  (See the first sentence of the
> paragraph you just quoted.)  Am I just not explaining myself clearly
> enough, or are you not reading what I'm writing, or what?  :)

  Semantics.  I always consider something that has something
inherently as something that falls out of the wash naturally, as
opposed to a prestated requirement.

> > ... I'm saying that the automatic UDP port forwarding of NAT boxes
> > isn't standardized anywhere ...
>   Totally incorrect.  RFC-2663 (1999) covers UDP in this way, as does
> RFC-3022 (2001).  The original NAT RFC, RFC-1631 (1994) is about
> one-to-one NAT, and thus doesn't cover this for TCP *or* UDP.

  Woah nelly.  RFC 2663 actually does specifically state that this
functionality shouldn't work this way.  It uses the 'out' of
Application Level Gateways.

'Address translations performed by NAT are session based and would
   include translation of incoming as well as outgoing packets belonging
   to that session. Session direction is identified by the direction of
   the first packet of that session (see sec 2.5).'

'However, there is no deterministic way of recognizing the start of a
   UDP based session or any non-TCP session. A heuristic approach would
   be to assume the first packet with hitherto non-existent session
   parameters (as defined in section 2.3) as constituting the start of
   new session.'

  There isn't a definition there which states 'Port Address
Translation should occur.'

'In this setup, only TCP/UDP sessions are allowed and must originate
   from the local network.  However, there are services such as DNS that
   demand inbound access.  There may be other services for which an
   organization wishes to allow inbound session access.  It is possible
   to statically configure a well known TU port service [RFC 1700] on
   the stub router to be directed to a specific node in the private
   network.'

  Note their definitions of session parameters.

>   Those are all "Informational" RFCs (not "Standards Track"), but if
> you want to make that argument, then *all* aspects of NAT are "not
> standardized anywhere".

  No arguements there.  Lots of informal RFCs should have been moved
to standards track a long time ago.

> > Some may argue that it's a really bad idea in general.
>   This is the Internet.  Some will argue about anything.  Look at us.  :)

  Poopoo head!

>   That's a completely unsubstantiated claim.  I suspect it's actually
> true, but I can think of no way to check it.  Can you?

  I'll just call RMS and ask him.  He'll know.  ;-)

  While not being able to substantiate the point, it can be inferred
simply because a TCP session cannot be spontaneously created, aka,
requires that 'connect' call, it's easier for applications to function
correctly in a NAT environment.

>   I can make this (mostly philosophical) point, though: DNS is the
> most important application protocol on the Internet.  When DNS stops
> working, pretty much everything else on today's Internet stops
> working.  And DNS over UDP works just fine across NAT without specific
> support for DNS in that NAT implementation.  I'm not sure what that
> means in practical terms, but it must count for something.  ;-)

Aww common.  I know lots of people who access machines by IP...

Okokok, so maybee its just us nerds...  :-)

And your right.  But that's based on the infered implementation which
people have used in the past.  Hell, the RFCs mention Application
Level Gateways all over the place, and specify IP Masq in the old
Linux kernels as the case in point.  ;-)

>   I suppose it's true that, in the case of streaming A/V, one
> generally wants the control channel to be connection-oriented and
> reliable, while one wants the content channel(s) to be real-time, so I
> guess it's more likely that one will end up with a TCP control channel
> and UDP content channels.  But that's even more of an assumption than
> the "UDP responses come in on the same port" assumption.  :)

  I snipped out a whole lot, because your right in very point, but
your last sentence is really the 'Most Right' of any of it.  I mean,
they're correct in my opinion, but I could see how other conclusions
could be come to.  :-)

THE END

-- 
-- Thomas