[Snac] Re: Handling multiple AIL-interfaces in a single SNAC router

[Ted Lemon <[e-mail]>]

The SOHO case you refer to is precisely what snac-complicated is supposed to address, so definitely out of scope for snac-simple.

> On 14 Apr 2026, at 20:17, Michael Richardson <[e-mail]> wrote:
> 
> 
> Esko Dijk <[e-mail]> wrote:
>> On 4/13/26 21:16, Michael Richardson wrote:
>>>> router can have multiple AIL interfaces, hence connections to multiple
>>>> AILs. This is written in various places in the draft. Ted suggested
>>> 
>>> Are/do these multiple AILs link up to a single ISP/Infrastructure router?
>>> Or different ones?
> 
>> The common case will be the same CE router, connected to the same ISP: this
>> is a Wi-Fi plus Ethernet case.
> 
> Unless this CE is one of mine, wouldn't the WiFi and Ethernet be bridged by
> the CE, so it's really all one AIL in that case?
> 
>> Another, not so common case is when a user has connected the two interfaces
>> to different ISPs.  For example, user has a Wi-Fi travel router used as an
>> "internet backup" for cases when the regular ISP (accessed preferably via
>> e.g. Ethernet) fails. Hotspot is turned on. Then, the SNAC router sees the
>> SSID appear, connects via Wi-Fi, and finds IPv4 and/or IPv6 internet
>> connectivity via that AIL. Its internet access now should be routed via the
>> Wi-Fi AIL while the discovery of IoT devices or printers etc. on the Ethernet
>> AIL should still continue.
> 
> Okay, I accept this.
> 
> I guess I'd think it was more sensible to plug the travel router into my LAN,
> where the existing CE would bridge it to the existing WiFi, bringing all my
> house back online.  Of course, that results in dualing DHCPv4 servers, but
> IPv6 ought to work fine.  The existing CE *ought* to withdraw it's GUA v6
> prefixes via a zero-lifetime RA when it sees it has no uplink.
> Of course, if it's the CE that fails, then the bridging won't work, OTH, there won't
> be dualing DHCPv4 servers.
> 
> {I don't know if any actually do.  For me, that would be undesired, as I'd
> lose local routing during the three-times weekly outages of PPPoE
> thanks to incumbent telco incompetence  (aka enemy action IMHO. I'm not with
> incumbent telco, but they "own" the wires, and control the PPPoE PAD redirector)
> Mind you, I use a statically delegated v6-prefix rather than a PD
> one... because PD wasn't implemented when we started.  I actually get a PD
> one too, but ignore it.}
> 
>> In both cases, the SNAC router has 2 AILs active at the same time so it's not
>> an either-or situation.
> 
> We did go through this (multiple-uplinks, multiple CE) extensively in HOMENET
> ages ago, and this certainly was a situation which a lot of people cared
> about.  But, still not fully solved.
> 
>>> So my Thread doorbell ("stub network client") that wants to *print* the
>>> picture it took, can look up printer.local, and this turns into multiple mDNS
>>> queries, one on each AIL?
>>> Is that what this means?
> 
>> Yes, so the printer can be found on either AIL (e.g. Wi-Fi or Ethernet). And
>> on either IPv4 or IPv6.
> 
> If the SNAC router is the only device connected to both AIL, is it doing
> enough DNS-SD and/or mDNS collision helping so that the two printer.local
> have found themselves unique names?   Like, what if there are answers from
> both AIL?
> Or maybe this is all really irrelevant to SNAC??  (... as the doorbells should just
> use the printers in the nearby ICE van)
> 
>>>> We may decide to either tackle these details, or update the draft to limit
>>>> the scope to a single AIL only.
> 
>>> I think the scope should be limited. This is snac-simple, and I thought it
>>> was done.  Maybe some thinking goes into snac-many-garlic (AIL = French for Garlic)
>>> such that if we go there, it doesn't break something else.
> 
>> Simple as in 1 AIL sounds good here. In botanical French and older recipes,
>> apparently multiple ail is written as "aulx". (Les aulx.) Not so simple!
> 
> aulx. . o O ( "C> COPY myletter.txt AUX:" ... Amiga could do same. )
> 
>> Some considerations why 1 AIL may be a perfectly fine limitation:
> 
>> - for the common case of Wi-Fi + Ethernet and same ISP, the CE router may be
>> already doing the bridging of the links or the proxying of mDNS between
>> links. So if the SNAC router only uses Ethernet for discovery, it will also
>> find a service/host on Wi-Fi.
> 
> +100
> 
>> - vendors may extend SNAC-simple with their own solution for multiple AILs
>> (as Ted commented on the Github issue), even when SNAC-simple doesn't
>> define that.
> 
> okay.
> I also wonder about multi-tenant Small-Office IoT situations.
> Like, the hair dresser and talent agent occupy the front and back of a
> streetfront, but do not share Internet with the web designer/building owner
> who lives upstairs.   But, they all should be able to adjust lighting, heat,
> and the like.  Being reasonable friends, there are no authorization
> complexities.  (No they don't share printers, there is no routing)
> 
> So they get the highend SNAC-router that can plug into three AIL,
> perhaps via USB ethernets.   That seems like a reasonable thing to me.
> 
> From what I am understanding there is nothing that keeps the SNAC-router from
> offering it's generated ULA on more than one AIL.  There are probably
> subtle complexities when one AIL has an infrastructure v6 prefix and another
> does not.
> And... first PD wins with hystersis to avoid frequent renumbers of the Stub
> Network?   Does the delegated prefix from AIL-1 get RIO's onto the other AIL?
> 
>> - for the case of Ethernet + "backup Wi-Fi" earlier in my mail, the discovery
>> only has to work on one AIL (Ethernet) not on the other because typically
>> there's nothing to discover there. (Think phone Wi-Fi hotspot with client
>> isolation.)
> 
>> - two Ethernet "uplink" / AIL ports is very rare for a non-CE-router device
> 
> +1
> 
> I'm not hearing a huge argument for new text for snac-simple.
> It's been enough months since I've been immersed in the document, that I am
> having to go back to make sure I'm using the right terms.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> **       My working hours and your working hours may be different.         **
> ** Please do not feel obligated to reply outside your normal working hours **
> 
> 
> 
> 
> -- 
> Snac mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]