Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Aug 1995 17:16:25 +0100 (BST)
From:      Paul Richards <paul@netcraft.co.uk>
To:        wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman)
Cc:        paul@FreeBSD.ORG, pete@puffin.pelican.com, current@FreeBSD.ORG
Subject:   Re: workaround for talk's address problem
Message-ID:  <199508081616.RAA04464@server.netcraft.co.uk>
In-Reply-To: <9508081503.AA02688@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Aug 8, 95 11:03:20 am

next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Garrett Wollman who said
> 
> <<On Tue, 8 Aug 1995 11:32:10 +0100 (BST), Paul Richards <paul@netcraft.co.uk> said:
> 
> > When in_pcbconnect gets called, I think what's happening is that the
> > decision about the local addr is made by ifa_ifwithnet, since the
> > destination address is an ip address aliased on this host it finds
> > an ifaddr struct that has a match and it returns that as the local
> > address.
> 
> Yes.  This is what it is supposed to do.

I know that, I was just setting the scene :-)

> 	2) In normal multi-homed environments, this is precisely what
> 	   you want to do, since you want queries sent on one wire to
> 	   get replies on the same wire without going through extra
> 	   router hops as would be required otherwise.

Not necessarily. You're assuming a "normal multi-homed envirnment"
is one with two interfaces where you need to do this. That's not
always the case any more and even in that situation, you still might
not want the local addr set to the primary address of the interface, you
may still want the outgoing packet to be marked as from one particular
address for that interface. The aliased address is likely to be
on the same subnet as the primary address otherwise the interface would
never see packets for the alias. there wouldn't be anything wrong in that
case of having packets leave the interface with the aliased address since
return packets will still come back to that particular interface and it's
aliased to accept them.

Multi-homed these days increasingly means having more than one ip
address aliased to the same interface and not for the reasons that the code
was originally written for but to allow multiple DNS domains to map to
the same physical host while still being able to determine which DNS
domain a particular packet is for, vis WEB servers.

The code as it is know is trying to 

> 
> You have two possible solutions:
> 
> 	1) Don't let people use Web browsers on your server machine.
> 
> 	2) Modify the browser source code to bind to a specific
> 	   address (perhaps whatever is returned by gethostname()).

This isn't an option. I'd have to modify every possible client that
could be used and that assumes I have source in the first place.

> 
> > We could check the destination address and if
> > it's actually an aliased address on this host
> 
> There is no distinction between various different sorts of interface
> addresses.  If you delete the address that was ifconfig'ed first, then
> the interface's primary address becomes whatever was added next, and
> so on down through the line.

So? The code as it stands now was written in order to determine which
address to assign to the local side so that packets could return
to the correct interface. It's out of date and needs to be revised since
that's not the only reason for a host having multiple ip addresses.
I've got several ip addresses allocated to the same interface and it's
the only interface on the box.

> 
> Remember that this code was originally designed to support multiple
> logical IP subnets on a single wire.

I know what it was originally for. I'm trying to make it work better
in today's environment where virtual host services are becoming
more common.

-- 
  Paul Richards, Bluebird Computer Systems. FreeBSD core team member. 
  Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
  Phone: 0370 462071 (Mobile), +44 1222 457651 (home)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508081616.RAA04464>