Re: IP of a connected Mac
Re: IP of a connected Mac
- Subject: Re: IP of a connected Mac
- From: "Justin C. Walker" <email@hidden>
- Date: Mon, 6 Jan 2003 14:16:11 -0800
On Monday, January 6, 2003, at 01:28 PM, Joshua Graessley wrote:
On Monday, January 6, 2003, at 11:37 AM, Justin Walker wrote:
On Monday, Jan 6, 2003, at 11:23 US/Pacific, Smith Kennedy wrote:
That's true, and it is unfortunate that the code snippet I threw out
there won't return the "default" interface. Seems like a logical
thing for that method to return, but the documentation says it will
be "an arbitrary Internet address of the receiver".
It's hard to define the default interface. There really is no such
thing. The best that can be done (I think) is to select the interface
pointed to by the default route. That may not be the one desired, of
course, wherein lies the rub.
There really needs to be a library layer that translates "the pile of
interfaces and assigned network addresses" to a list ordered by some
set of criteria. Determining that criteria will take some time and
thought. The world of multihoming is a fairly new one for most users,
and for most developers.
It's even more complicated than that though. Addresses have different
scope. An IPv4LL address is only valid on the local link. In addition,
a 10.x.x.x or 192.168.x.x address is only valid on that local network.
Depending on what other host you're trying to contact, you may want to
pick any number of addresses. Network setups can get fairly
complicated. For example, at home, I've got 5 static IP addresses. One
of those addresses is assigned to an AirPort base station that then
turns around and shares it using NAT, creating 10.0.1.x. A server has
both a 10.0.1.x address and a global address. This makes it easier to
communicate directly with hosts behind the NAT and on the internet.
Depending on which address you pick, the global one or the 10.0.1.x
one, you can communicate with different hosts.
Right. I swept all that under the 'criteria' rug, but these 'scope'
issues are just one tip of the iceberg.
Many of our laptops ship with built-in and airport. In some locations,
it is not unlikely that both will be active at the same time. For
example, at work, I have a wired connection and a wireless one. If I
want to communicate with another host that is on both the wired and
wireless networks, it would be preferable to use the wired one but
there is no for most of the software to know that.
Related to this, just to let the cat out of the bag a little bit, is
that with today's simple-minded multihoming mechanisms, one can easily
deal with one 'default' route (to the "Internet"); other interfaces can
provide routes to locally-attached systems (i.e., on the subnet
associated with a given non-default interface). There's no way, for
example, to have a "rich" subinternet on one interface and the Internet
on another (e.g., a small office with multiple lans and a PPP or DSL
link to the outside world).
Given today's technology, one has to run a routing protocol and provide
a routing protocol handler (routed[shudder], gated, zebra). This puts
the problem solution in the realm of Trained Professionals. In
addition, as soon as you introduce routing protocols, connecting to an
ISP becomes dicey, because the ISP may be running its own routed
"intranet", and your information and its might not mix well. Routing
leaks are a constant source of headaches in the real world, and getting
the hapless home/small-office networking staff involved is a no-win deal.
In general, it's best to send all addresses to remote host and let the
host decide which address to connect to. The only tricky part is making
sure you don't forward an address beyond it's scope. It's fine to send
an IPv4LL address in an IPv4 link-local multicast, but not a site-local
multicast. A 10.x.x.x or 192.168.x.x address should not be forwarded
off of the network for which that address is valid.
The other tricky part, if I understand what you mean, is that there's
probably no software today on "the remote host" that's capable of
sorting through that list and picking the right address. Not to mention
that there's currently no good way to send that list.
Cheers,
Justin
--
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics | When LuteFisk is outlawed
| Only outlaws will have
| LuteFisk
*--------------------------------------*-------------------------------*
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.