Outbound interface

[Jan Danielsson]

Hello,

Is it entirely up to the routing to determine which interface/wire to
send out a packet on?

Say we have the following network configuration:

bge0: 192.168.1.42
bge1: 10.0.0.13

(No route between the networks)

.. and a program which sets up sockets:

s1 = socket()
s2 = socket()
bind(s1, 192.168.1.42)
bind(s2, 10.0.0.13)

.. and later does:

sendto(s1, "Hello", 10.0.0.17)

Can one assume that this packet will leave through bge1, even though
it's is "bound" to the "name" of bge0?

I must admit that I would have guessed that bind():ing would have
some kind of bearing on outbound interface, but from what I'm reading,
sendto() simply chucks the packet further down the network stack and
then it's up to the routing code to sort out where to pass it on
(ignoring the actual socket handle from which it came). So bind is
essentially only used to stamp the source-field (in the case of sending)
before pushing packets out the door?

[Mouse]

Post by Jan Danielsson
Is it entirely up to the routing to determine which interface/wire to
send out a packet on? [...]
I must admit that I would have guessed that bind():ing would have
some kind of bearing on outbound interface, [...]

See RFC 1122 section 3.3.4.2. You are seeing a dissonance between the
strong-ES model your guessing expects and the partially-strong
partially-weak model NetBSD actually implements.

There appears to have been a discussion back in 2005 on more or less
this topic; it mentions even earlier discussion. See the "default
route and private networks" thread in the tech-net archives for 2005-04
(beginning "04/13/2005", presumably meaning 2005-04-13).

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by Mouse

Post by Jan Danielsson
Is it entirely up to the routing to determine which interface/wire to
send out a packet on? [...]
I must admit that I would have guessed that bind():ing would have
some kind of bearing on outbound interface, [...]

See RFC 1122 section 3.3.4.2. You are seeing a dissonance between the
strong-ES model your guessing expects and the partially-strong
partially-weak model NetBSD actually implements.

Note, though, that even if NetBSD did implement a strong-ES model it still
wouldn't send the packet out the bge0 interface; it would drop it instead.
You need to route on the destination address and if the only route you
have to the destination is through bge1 then either the packet is leaving
the box through bge1 or it is going no where. I think the former is generally
more useful behavior. Implementing a "perfect" strong-ES model requires a
separate routing table per interface, something which NetBSD doesn't do (but
which would be a quite useful configuration option to have available, for this
and for other uses).

I would also object to the notion that a local address on an interface "names"
that interface in any useful way. While I admit this is arguable, and is
slightly less clear for ethernet interfaces because of additional constraints
related to the use of ARP, in general the only practical function of a local
address on an interface is to provide a default for local address selection
procedures, in particular one which maximizes the probability that the recipient
of the packets you send will know a route back to you. Because this is all the
local interface address really does it is not unreasonable to configure the
same local address on many interfaces, to configure local addresses not
associated with any interface (generally implemented by adding them to the
loopback) or to operate interfaces with no local address configured (which
you might do if the fallback default local address selection provided a
useful result). A local address may hence "name" more than one interface,
or no interface, and an interface is not guaranteed to have a local address
"name", which really suggests that the local address doesn't "name" anything
in a useful way. An interface name is actually "bge0", or some software
equivalent (like the if_index), since that does unambiguously name something.

Given this, I would argue that all bind()ing a local address to a socket does for
outbound packets is to override the kernel's most-likely-to-succeed selection of
a local address with one of your own choosing. It alters nothing else, the
outbound routing to a destination still is what it is. You are permitted to
do this if it is useful to you, but you are on your own if you do since you
are in effect overriding what would generally be expected to be the "best"
local address to pick with something else.

Dennis Ferguson
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Daniel Carosone]

Post by Dennis Ferguson
Note, though, that even if NetBSD did implement a strong-ES model it still
wouldn't send the packet out the bge0 interface; it would drop it instead.

Yep. Contrast, though, with binding a listening socket, and sending
reply packets in such a model. From rough memory, I think they are
required to leave the same interface the original packets arrived
on. Regardless od speculation on unimplemented features, though..

Post by Dennis Ferguson
Given this, I would argue that all bind()ing a local address to a socket does for
outbound packets is to override the kernel's most-likely-to-succeed selection of
a local address with one of your own choosing.

Multicast is a good illustration here: your packet may indeed even
leave on multiple interfaces, and you often want to expicitly select
an official address (such as a routed loopback or public address you
want replies directed to) as the source.

--
Dan.