| those protocols embed the ip address since (a) it's much easier to get
| at than a hostname (which will map to an ip address) and (b) the local
| ip address that it's passing isn't expected to change in the next few
| minutes.

The change is spatial rather than temporal, in the case of NAT.
That's one of NAT's goals - the system "inside" the NAT never
knows its addresses change.  As a result, protocols which do this:

	sender (configured as 10.0.0.6): hi, please reply to 10.0.0.6
			passes through NAT
	receiver sees from 192.158.16.21: "hi, please reply to 10.0.0.6"
			sends reply to 10.0.0.6, never gets reply

are broken.  Instead they should do this:

	sender (configured as 10.0.0.6): hi, please reply to my.domain.com
			passes through NAT
	receiver sees from 192.158.16.21: "hi, please reply to my.domain.com"
			does DNS lookup on my.domain.com, sees 192.158.16.21
			sends reply to 192.158.16.21

this is the only difference between a NAT-unfriendly and NAT-friendly protocol.
		
| ftp has been "fixed", talk could also be "fixed", but dcc
| would be a different matter entirely.

Why?   Can't the initiator of a DCC session figure out its canonical DNS name?

| also...if *both* ends are using
| nat...active vs. passive wrt ftp isn't really much of an argument.

Why?  If receiver's NAT sees "hi, please send a reply to my.domain.com",
and rewrites 192.158.16.21 to 10.0.0.8 (note subtle difference), then
receiver still sees the same request, does the same DNS lookup, but this
time gets "my.domain.com. IN A 10.0.0.8" from the nameserver that cooperates
with the NAT.   

By contrast, the NAT-unfriendly protocol's "10.0.0.6" might have
gruesome side-effects if that's a real machine "inside" the receiver's
NAT addressing scope.

| imho, nat devices shuld come with the warning that some things will be
| broken by the use of this.  tough noogies.

Yes, I agree.  And we can stop calling NAT all sorts of evil names,
complaining about how it breaks the Internet's end2end model, violates
data intregity, and so on.   Then I shut up. :) :) 

	Sean.