Bill Studenmund <wrstuden@netbsd.org> writes:

>> That's almost, but not quite, what is needed here.  If you specify 
>> -ifa, the packet is sent out on that interface.  We want to send on 
>> interface A while using some address from interface B. 
>
> Do we necessarily want that? I'd be happy with going out an interface that 
> that address is on.

In my situation at home, I certainly want it.  My main system doubles
as router/firewall and service provider for my laptop, my wife's
Windows box, &c.  Its primary, official, address is connected to my
inside network, and there's a /30 glue network on the outside, tying
it to my ISP's backbone.  I have no control over that side.

 Inside network: 193.71.27.0/27
    Main system: 193.71.27.8, barsoom.hamartun.priv.no
Outside network: 81.0.129.40/30
     My address: 81.0.129.41, c51008129.inet.catch.no

I'd rather not be connecting to services around the world as
"c51008129.inet.catch.no" -- especially while claiming to be
"barsoom.hamartun.priv.no".  For the services that can be configured
with an explicit source address, I've already bound them to the
proper, official, address of the machine.  For certain other services,
I've had to learn not to use that machine, instead connecting from,
say, the laptop, which properly originates on my own network.

> Another optioon would be that the -ifa and -ifp parameters could
> both be set such that we indicate we use address X out iface Y, when
> address X is on iface Z.

That would be very nice.  At the moment, that's a degenerate
configuration that can't be set up, and whose behavior is undefined.
Allowing it, and defining its effect, should do no harm, I'd think.

-tih
-- 
Don't ascribe to stupidity what can be adequately explained by ignorance.