In this case, the protocol that I am implementing uses STUN <http://
www.faqs.org/rfcs/rfc3489.html> (with some small variations) when one
end is behind a NAT. This generally takes care of any problems like
this.
However, in some cases, the machine will not be NATed and will be
required to report it's address appropriately.
For the record, this general problem is described in gory detail by
"IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across
Network Address Translation", i.e. <ftp://ftp.rfc-editor.org/in-notes/
rfc3424.txt>.
In particular, I would recommend paying close attention to what the
bulleted paragraph in section two is trying to tell us all:
--> there *is* no unique "outside" to a NAT - it may be impossible to
tell where the target endpoint is with respect to the initiator;
how does an UNSAF client find an appropriate UNSAF server to
reflect its address? (See Appendix C).
Anyone hoping to understand the general case should read this RFC
carefully, as it describes in detail all the ways a protocol can and
will be broken by network address translation if one insists on
carting around IPv4 addresses and transport identifiers in protocols,
e.g. port numbers, IPsec security parameter identifiers, GREv1 call
identifiers, etc. If, after reading this RFC and understanding the
unavoidable limitations, one still feels it necessary to play this
game, then one is invited to consider volunteering to be the
delegated responder here for the inexhaustible stream of questions
from people who want to know how to play along.
That said, there are a lot of ways to do broken things that are still
not broken enough to be completely useless. While there is no good
solution to the general case problem, it is a true fact that not
everything worth doing is worth doing well. Just don't let my
executive management hear me say that.
—
james woodyatt <email@hidden>
member of technical staff, cpu software
