Subject: RE: IPv6 Comment
To: Sean Doran <>
From: David Stanhope <>
List: current-users
Date: 09/01/2000 15:53:53
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.


-----Original Message-----
[]On Behalf Of Sean Doran
Sent: Friday, September 01, 2000 12:50 PM
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 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

| 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

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

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.

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