Re: cleanest way to get outside IP address
Re: cleanest way to get outside IP address
- Subject: Re: cleanest way to get outside IP address
- From: james woodyatt <email@hidden>
- Date: Thu, 8 Jan 2009 14:14:37 -0800
On Jan 8, 2009, at 11:52, Nicolas Berloquin wrote:
I'm looking for the cleanest or prefered way to get the "outside" IP
adress of a host on a network,
from the said host. For example a mac behind a NAT router.
First, we need to set some expectations. Quoting now from the Holy
Scripture, i.e. RFC 3424 "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF)" section 2 "Architectural issues affecting
UNSAF Systems":
Any users of these workarounds should be aware that specific
technical issues that impede the creation of a general solution
include:
- 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).
- specifically because it is impossible to tell where address
realms are bounded ("inside" or "outside", "private" or "public",
or several "private" realms routing traffic), an address can only
be determined relative to one specific point in the network. If the
UNSAF service that reflected an UNSAF client's address is in a
different NAT-masqueraded subnet from some other service X that the
client wishes to use, there is _no_ guarantee that the client's
"perceived" address from the UNSAF partner would be the same as the
address viewed from the perspective of X. (See Appendix C).
- absent "middlebox communication (midcom)", there is no usable way
to let incoming communications make their way through a middlebox
(NAT, firewall) under proper supervision. By circumventing the NAT,
UNSAF mechanisms may also (inadvertently) circumvent security
mechanisms. The particular danger is that internal machines are
unwittingly exposed to all the malicious communications from the
external side that the firewall is intended to block. This is
particularly unacceptable if the UNSAF process is running on one
machine which is acting on behalf of several.
- proposed workarounds include the use of "ping"-like address
discovery requests sent from the UNSAF client (initiator) to the
UNSAF server (listener), to which the listener responds with the
transport address of the initiator - in the address realm of the
listener. However, with connection-less transports, e.g. UDP, IPsec
ESP, etc., an UNSAF process must take care to react to changes in
NAT bindings for a given application flow, since it may change
unpredictably.
- if the UNSAF client uses periodic retries to refresh/reevaluate
the address translation state, both the UNSAF client and the UNSAF
server are required to maintain information about the presumed
state of the communication in order to manage the address illusion.
- since the UNSAF server is not integrated with the middlebox, it
can only operate on the assumption that past behavior is a
predictor of future behavior. It has no special knowledge of the
address translation heuristic or affecting factors.
- the communication exchange is made more "brittle" by the
introduction of other servers (UNSAF servers) that need to be
reachable in order for the communication to succeed - more boxes
that are "fate sharing" in the communication.
If we knew why you feel the need to invent another UNSAF method, then
we might be able to help you choose the best workaround for the core
Internet architecture problem you're encountering. Your initial
message doesn't communicate enough information.
(Note: the reference to MIDCOM in the RFC language should probably be
read as a generic abstraction for UPnP IGD and NAT-PMP, and not as a
reference to the actual MIDCOM protocol, which nobody uses.)
--
james woodyatt <email@hidden>
member of technical staff, communications engineering
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden