A better fix for many of the NAT unfriendly protocols is to not send
the address as either a numeric or DNS name, but instead use 'getpeername'
at the receiver side, which will get the translated address. The sender
behind the NAT box only knows its local IP address anyway and wouldn't
know what name to use, since it would need to use the DNS entry for
the outside address.

Another problem which is harder to fix is that these protocols send
port-numbers in the data. The only real way to fix this is to change
the way the protocols work.

The real issue with IPv6 seems to be that there is no reasonable way to
migrate to it in an elegant fashion. The enhanced address space and
features would be great, but how do you get there from here in a way
that benefits you immediately.

Dave

-----Original Message-----
From: current-users-owner@netbsd.org
[mailto:current-users-owner@netbsd.org]On Behalf Of Sean Doran
Sent: Friday, September 01, 2000 12:50 PM
To: atatat@atatdot.net
Cc: current-users@netbsd.org
Subject: Re: IPv6 Comment



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