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

that might be the only difference, but in the second case, the
"receiver" not not "never get a reply", but rather "receive a rst"
from the nat gateway.  that is, of course, unless the nat gateway sees
that the domain name was passed out and knows to expect an inbound
connection to that address.

...which is a *LOT* worse, because then you'd have to either (a) embed
hostnames in the kernel, or (b) move the nat stuff into userspace.
nevermind the fact that you'd have to teach the nat to recognize
domain names either way.

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

not reliably, no.

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

i'm of the opinion that a dns alg is a silly thing.  it's a clumsy
bandaid on an inelegant hack.

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

which implies either (a) nat is also in use on the receiver's end or
(b) the receiver has bigger problems that just not being able to dcc
someone...

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

wait...i forgot if we were arguing for or against nat.  i'm definitely
against it.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."