Standard protocol(s) to advertise alternative internet gateways to local, already DHCP-configured network

Question

Setup

Imagine a run-of-the-mill home network with a bunch of devices connected to a router that acts as an internet gateway and DHCP server.

Now one of these devices sometimes possesses its own, independent connection to the internet (e.g. via 5G). It can allow the other devices to use this connection if configured appropriately (allowing packet forwarding & setting up the necessary routes), but in order for them to actually do so, their users have to manually disable/override the settings obtained via DHCP and set the independently internet-connected device's IP address as their new gateway address instead.

My question

Is there a standard protocol that allows a device to advertise its ability to act as an (alternative) internet gateway to other devices on the local network, ideally in a way that is understood (and displayed to the user e.g. in a GUI) by the default networking software of most "common" Linux distributions (Ubuntu, Fedora, Debian, ...)?

Considered so far

Approaches I've thought of and why they don't work or are incomplete:

• DHCP can't be used because all devices are already DHCP-configured and won't re-attempt DHCP discovery until reboot / loss of connection. Even if they did, you'd be competing with the router's DHCP server. As DHCP works by the principle of "first to answer wins", it would mainly come down to luck.
• Advertising services on the local network in general is possible via DNS-SD (part of the zeroconf protocols), and I already use mDNS (also part of zeroconf) to ease the process of finding out the independently internet-connected device's dynamically assigned IP address. But I didn't find "internet gateway" or anything like that in the list of RFC 2782 service types, so it doesn't look like this particular use case is something people are using it for.
• Windows's Internet Connection Sharing, which builds on UPnP, seems relevant to this use case, but I don't think Linux distributions support it and can't find much information about it compared to the zeroconf suite (in particular regarding service types).

Answer 1

Is there a standard protocol that allows a device to advertise its ability to act as an (alternative) internet gateway to other devices on the local network,

No, not for "regular" DHCP-configured devices.

Usually fail-over between two gateways is done in a way that's completely (or mostly) invisible to hosts:

1. either by reassigning the gateway IP address to the new router (only requiring an ARP announcement with the new MAC),
2. or by using a fail-over protocol such as VRRP or CARP to allow both gateways share "virtual" IP and MAC addresses,
3. or by using a single gateway that handles failover internally between two uplinks.

Option #3 might be the most common in your situation – plenty of home gateways have basic "dual uplink" (Ethernet plus 4G/5G) fail-over support built in, and there are many that support the same with multiple Ethernet uplinks (e.g. one uplink goes to your fiber/cable modem and another to your existing 5G modem).

ideally in a way that is understood (and displayed to the user e.g. in a GUI) by the default networking software of most "common" Linux distributions (Ubuntu, Fedora, Debian, ...)?

No, there isn't.

Except if your network primarily consists of Wi-Fi users, in which case this would just be two SSIDs (i.e. the default situation where both gateways have separate Wi-Fi networks) and users could switch to 5G by switching Wi-Fi networks.

(For Ethernet, something could be built using VLANs, managed switches, and a local webapp with a 'Put me in the other VLAN' button… but that's way beyond "run of the mill home network". Would be much simpler to physically reconnect the Ethernet cable.)

DHCP can't be used because all devices are already DHCP-configured and won't re-attempt DHCP discovery until reboot / loss of connection.

Devices will re-attempt DHCP discovery whenever they fail to renew their current DHCP lease (unless you configured it to be infinite or something). With the DHCP server configured to offer 30-minute leases, hosts will renew them every 15 minutes; if the current server doesn't respond, they will try to discover a new server at around 25-28 minutes.

Even if they did, you'd be competing with the router's DHCP server. As DHCP works by the principle of "first to answer wins", it would mainly come down to luck.

DHCP supports delaying offers. When hosts retransmit their DHCPDISCOVER queries (for example, if the main gateway isn't offering anything), they indicate in the packet how long they've been trying to acquire an address. It is possible to configure a DHCP server so that it would only send offers if the host has been trying without success for at least X seconds.

(For example, in RouterOS, this is the delay-threshold= option under /ip/dhcp-server.)

So you could actually have both gateways offer DHCP – if the main gateway is working it'll be the only one to immediately offer a lease and that's what all hosts will pick up; if the main gateway is offline, hosts will keep retrying until eventually they get an offer from the second gateway.