Subject: Re: IPv6 Comment
To: Sean Doran <>
From: Andrew Brown <>
List: current-users
Date: 09/01/2000 16:01:01
>| 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 hi, please reply to
>			passes through NAT
>	receiver sees from "hi, please reply to"
>			sends reply to, never gets reply
>are broken.  Instead they should do this:
>	sender (configured as hi, please reply to
>			passes through NAT
>	receiver sees from "hi, please reply to"
>			does DNS lookup on, sees
>			sends reply to
>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
>| vs. passive wrt ftp isn't really much of an argument.
>Why?  If receiver's NAT sees "hi, please send a reply to",
>and rewrites to (note subtle difference), then
>receiver still sees the same request, does the same DNS lookup, but this
>time gets " IN A" 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 "" 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

>| 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" >-----|             * "ah!  i see you have the internet (Andrew Brown)                that goes *ping*!"       * "information is power -- share the wealth."