[ih] History question -- multi-homing

[Joseph Touch]

On Sep 11, 2026, at 9:08 AM, John Day <jeanjour at comcast.net> wrote:
> It doesn’t need a router (no relay) if the device is the destination. It does need to participate in the routing algorithm to advertise what it is connected to.

Destinations are not the issue, sources are.

If a device has two sources, they’re either ships in the night or need to be connected to a router to decide which path to use on the way out.

Multiple sources applies whether using two interfaces or a single one with multiple addresses.

The rules in 1122 for outgoing packet source address selection are just a router with a hardcoded forwarding table.

Joe

>> On Sep 11, 2026, at 10:57, Joe Touch via Internet-history <internet-history at elists.isoc.org> wrote:
>> 
>> Hi John (et al.),
>> 
>>> On Sep 10, 2026, at 5:12 PM, John Shoch via Internet-history <internet-history at elists.isoc.org> wrote:
>>> In a recent post John Day raised an interesting question on
>>> multi-homing.  There were a couple of quick historical replies and I
>>> was also going to offer a bit of aditional history, but then realized
>>> the original question raises a bunch of complicated issues.
>>> A.  Some thoughts:
>>> 1.  In the simple case, multi-homing means a device with multiple
>>> network connections.  We usually think of this as connections to
>>> different networks, but it could also be multiple connections within
>>> one network (a device in a cell phone network is multi-homed to
>>> different cell sites, switching dynamically).
>>> Yet the broader question is, what do you try to do with it?
>> 
>> Any device with more than one network connection ends up internally needing the equivalent of a router. Every problem I’ve seen stems from either not recognizing this reality or trying to actively avoid it.
>> 
>>> 2.  At the edge, or for a client, multi-homing usually provides some
>>> redundancy or failover.
>> 
>> Or multiple concurrent paths. Yes, just like any router with multiple links does.
>> 
>>> 3.  At a server multi-homing can also provide improved service or performance.
>> 
>> Servers are not different from clients. In both cases they provide the same capabilities - that of a router and multiple paths.
>> 
>>> So, to discuss "multi-homing" we may need a bit more context -- what
>>> problem are we trying to solve?
>> 
>> IMO, the lack of the equivalent of a router in most host systems.
>> 
>> Although I’m sure it was discussed before, my first experience with it  in 1997 is documented here:
>> https://www.ieee-icnp.org/1997/papers/1997-30.pdf
>> 
>> We have similar problems with how middleboxes (NATs and tunnel devices) behave; few systems recognize that a tunnel device must follow host rules on the tunneled side and router rules on the other, as described in detail here:
>> https://www.strayalpha.com/pubs/isi-tr-711.pdf
>> 
>> Joe
>> 
>> 
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> -
>> Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history