Sean wrote:
>My contention is that NAT-unfriendly protocols are broken,
>and should be fixed to use DNS names rather than IP addresses
>in the data stream.

I'm sorry, but I can not let this slide without a comment.
There are protocols out there that are "NAT-unfriendly" where
there is no DNS vs IP issue.  

Consider rpc2 (the underlying protocol for Coda):

   a) it is UDP based (which means NAT mappings are temporary at best
	and could easily send a reply packet to the wrong machine with
	several hosts sending to the same ip/port.)

   b) it has a "side effect" transport where a UDP packet is sent back
	on a different port number than the original packet and thus
	the NAT box would have no record of a UDP packet sent on that
	port and would have no clue as to where to forward the packet.
	
	One could tell the NAT box to always send the UDP packets on
	this one port to a particular machine behind the NAT box, but
	then all other machines loose.  So, because of the use of a
	single port number for these side effects, you can have the
	maximum number of coda sites behind the NAT box as there are
	unique IP used on the "internet" side of the NAT box.

	For me in my home, that translates to ONE coda capable machine
	behind the NAT box.  Not very nice.

Note, this has nothing to do with IP numbers in the data stream!  So
this can't be a DNS vs IP issue.  The "remote" rpc2 responds to the
NAT output IP.  The problem is that with a single ip/port number, 
it can talk to one machine for side effects.  And to my knowledge, 
there is not enough information for an ALG either.  

-- 
Phil Nelson                       NetBSD: http://www.netbsd.org
e-mail: phil@cs.wwu.edu           Coda: http://www.coda.cs.cmu.edu
http://cs.wwu.edu/faculty/nelson