[ih] History question -- multi-homing

[Brian E Carpenter]

On 12-Sep-26 04:14, Joseph Touch via Internet-history 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.
> 
> 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.

Very true, and not in the least a historical problem. IPv6 has made this problem much worse.

     Brian

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