[ih] History question -- multi-homing

[John Day]

> On Sep 11, 2026, at 12:14, Joseph Touch <touch at strayalpha.com> wrote:
> 
> 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.

Not really.  They are all addressed to the same address, the destination.
> 
> 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.

That is two possibilities.
> 
> Multiple sources applies whether using two interfaces or a single one with multiple addresses.

Correct. Regardless of the interface, they are delivered to the address.
> 
> The rules in 1122 for outgoing packet source address selection are just a router with a hardcoded forwarding table.

O, that sort of stuff!  I was referring to how it worked when it was done right.

John
> 
> 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