Mark S. Miller wrote:
> At 02:31 PM 1/12/99 , Ben Laurie wrote:
> >email@example.com wrote:
> >> >Hang on - no networking API has a notion of hosts _or_ interfaces. They
> >> >have a notion of IP numbers, surely?
> >> Yes, but the IP number is 1-1 with some particular interface.
> >I'm afraid not. A single interface can have multiple IPs.
> [?] So what does "interface" mean?
> I had been assuming that "IPs per host" and "interfaces per host" were the
> same concept. Since they're different, Java's API indeed seems to have no
> concept of "interface", but should I care? What other concepts go with
> "interface" rather than IP address?
IP address and interface are different, but not in a way that is generally interesting to a program. An interface corresponds to an actual bit of hardware that connects to a physical network, and in IP address corresponds to logical hardware and logical networks (which may share the physical infrastructure). So the fact that there is more than one IP per host is interesting, but how they correspond to physical interfaces is not, usually, unless you are a security architect (which I am).
> >> >From the *inside*, there is only one host. When you enumerate all of the
I don't know. The only packages I've ever seen that do this are network
analysis packages, and they are never portable. Normally, you do things
the other way around (that is, either listen on all addresses, or listen
to particular ones configured by the sysadmin). I guess the interesting
question is "why do you want all the IP addresses of your own host"?
> >> IP addresses of a given machine, you get all of them without regard to host
> >> name.
> >> The host name returned by 'getLocalHost()' is referred to as the
> >> "canonical" host name. There is only one per machine.
> >Although this is technically correct, in a sense, I refer you to, for
> >example, the sendmail documentation to see that in real life it is not
> >as simple as this.
> > I say in a sense because to some extent it is up to the system
> >administrator to decide which hostname is "canonical", and that decision
> >may actually depend on the application to which the information is being
> [?] But how can I find all the IP addresses of my own host?
> That's my real question. I know y'all aren't steeped in the Java API, but
> how would you do this portably in C? Looking at
I don't know. The only packages I've ever seen that do this are network analysis packages, and they are never portable. Normally, you do things the other way around (that is, either listen on all addresses, or listen to particular ones configured by the sysadmin). I guess the interesting question is "why do you want all the IP addresses of your own host"?
> does anything similar suggest itself?
> Until I hear otherwise, I'll proceed with the previously described
> and then use the hostname in
> under what conditions might this code fail? Are there any reasons to
> prefer one of these ways to get the local supposedly-canonical hostname.
If I have a multihomed host, I usually give it different names on the different nets, so this method completely fails to discover all the IP addresses of such a host.
> >> It's also why a rash of products are now figuring out how to tunnel through
> >> HTTP. Prediction: pretty soon http will be disabled by all sensible
> >> firewalls.
> >I really doubt this is likely. However, sensible firewall admins _also_
> >dictate how HTTP can be used. Using it to tunnel is abuse from where I'm
> If they disable http, then folks (including us) will tunnel over whatever's
> allowed. If they allow protocol X, but try to prevent its use for
> tunnelling, the tunnelling will become more subtle. In such an arms race,
> steganography wins.
In a secure environment, the software is examined as well as the protocols permitted. You would never get to tunnel something I didn't want in a secure enviroment I ran, because you wouldn't be allowed to run the software in the first place. Anyone who tries to control functionality by packet filtering alone is on to a loser :-)
> Given the nature of E's security, I believe E's tunnelling through an
> organization's firewalls can't compromise any actually security of the
> organization. When an organization comes to realize the futility of most
> firewall policies, perhaps they'll be more receptive to distributed
> capabilities as an alternative.
This may be true, but I don't think most firewall policies are futile. If I let you choose your own capabilities, surely distributed capabilities are just as "futile" as firewall policies?
-- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi