[Snac] Handling multiple AIL-interfaces in a single SNAC router
Esko Dijk <esko.dijk@iotconsultancy.nl> Mon, 13 April 2026 16:13 UTC
Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: snac@mail2.ietf.org
Delivered-To: snac@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 249B0DB659D9 for <snac@mail2.ietf.org>; Mon, 13 Apr 2026 09:13:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776096809; bh=wNYLXnsXft2qTD/31E6bS/cc50bnm2gI+ar7fw1Uhyc=; h=Date:To:From:Subject; b=MOzUSFQfC5QnakeFEILjXhtX2uRHgdzuJpILsVenG9/FHojDlSsBoME0SiA+Bn5Lz BEPZvxyXePOFxVfpc2cTwMLAc0JJpLC2yjNtGdpFQbH1DPEfGdG4IWX4hSrlHCqL2P KklOAj0+PXA4dQeouVNRbAdUv8usFmKvfaqMMCBY=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=iotconsultancy.nl
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gte0lCMlQgeh for <snac@mail2.ietf.org>; Mon, 13 Apr 2026 09:13:28 -0700 (PDT)
Received: from dane.soverin.net (dane.soverin.net [185.233.34.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 72929DB656FA for <snac@ietf.org>; Mon, 13 Apr 2026 09:12:31 -0700 (PDT)
Received: from smtp.soverin.net (unknown [10.10.4.100]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4fvXVc3p3tz125r for <snac@ietf.org>; Mon, 13 Apr 2026 16:12:24 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4fvXVc1zRPzC1 for <snac@ietf.org>; Mon, 13 Apr 2026 16:12:24 +0000 (UTC)
Authentication-Results: smtp.soverin.net; dkim=pass (2048-bit key; unprotected) header.d=iotconsultancy.nl header.i=@iotconsultancy.nl header.a=rsa-sha256 header.s=soverin1 header.b=oxc/Rl80; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=soverin1; t=1776096744; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Zmr/O4+Az8ycuzV3CkVI0F7+ghW2e1Aw1PYaIQnvsag=; b=oxc/Rl80L/AgrTxadN0j27FoNiDL30aKnKTXi3n3F+8p4EEXPzvA+c9F39nxG+reKQVqbs yzq324fNSMY0StIKMnQj88j20IC1MIoB6ZPwt13aErk09zGIfzbP8jV6bk8HaQ/hgnpS0E Gert+4furiDyFnp3pKjt9aZgAeDhdDzUBjSbwUBAkSdrDrGjA9aGldbZGExx44eVd1Ebxd /i80hdDWncI4hU9+x8+bTm6BurblL/XK+4kHPxc8JBGPVfjXob87DqK4Ud88wE+KONCkLu e7ofJEo9+ogRB42w7vPnm8bNQyfC/m6XqPY4DiqErfwG2FhYE0+C/ziFrPku2A==
X-CM-Envelope: MS4xfE3/t1ZlpSkkGYfcMQlp1vM7qUkU4FVf3FMFUWSFHo1227IPPOlmR7wEn8iISC1Ct7q8EYzZBlM5UguyqfwxJlOkDlGP/yqekLuv8bK303s0w+RS22uK Lx+klsgV1DfWRGh6m9hgsfw+tF0+oR+DzTSuccmJ/AAmWvZ6Kg1Yo3iYLfqcWJMzuXEubaCxo4UFRWP7spvzZIcSu8IL11Yv+ByHq1N4AeTwCgNdIY5dLXeZ 9Er3FMTsvhff2m5pbAwxLoHr4okhgSOT23o/eCw1VcruEJSr/Nb1Mn5ey5YLHdH7
X-Soverin-Id: 019d879d-9240-7e01-97c9-1c1108e5a707
Message-ID: <ed392ae6-8127-451d-a25d-0f273c49e2b9@iotconsultancy.nl>
Date: Mon, 13 Apr 2026 18:12:23 +0200
MIME-Version: 1.0
Content-Language: en-US
To: "snac@ietf.org" <snac@ietf.org>
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Spampanel-Class: ham
Message-ID-Hash: LSHQ2HVKRAEEPNUAKKBP33HP4JKPR2SG
X-Message-ID-Hash: LSHQ2HVKRAEEPNUAKKBP33HP4JKPR2SG
X-MailFrom: esko.dijk@iotconsultancy.nl
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Snac] Handling multiple AIL-interfaces in a single SNAC router
List-Id: "Mailing list for discussing problems relating to the automatic connection of stub networks to existing infrastructure networks. " <snac.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/snac/1obBiqgYIw8SSL4DfdxJxQ5q1AA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/snac>
List-Help: <mailto:snac-request@ietf.org?subject=help>
List-Owner: <mailto:snac-owner@ietf.org>
List-Post: <mailto:snac@ietf.org>
List-Subscribe: <mailto:snac-join@ietf.org>
List-Unsubscribe: <mailto:snac-leave@ietf.org>
Hi all, This item was triggered by a private mail exchange with Ted about Github issue #152 (Clarify the one-DNS-zone-per-AIL requirement). He said I should take it to the list, so here goes :) What was intended by the draft is now clear to me at least, and I've submitted a text change to clarify the intention of the existing draft: https://github.com/ietf-wg-snac/draft-ietf-snac-simple/commit/5a8f66178a8db6968aab53bd9673b138bd46b3d7 (accidentally this was pushed to main instead of creating a PR. ) So the idea we had already for a while in SNAC-simple is that a single SNAC router can have multiple AIL interfaces, hence connections to multiple AILs. This is written in various places in the draft. Ted suggested this situation may go beyond what we want to address in SNAC-simple -- after all, it's multiple AILs and that complicates things. Even though it's not as problematic as multiple SNAC routers each connected to different AILs! To have a placeholder for this discussion I created now: https://github.com/ietf-wg-snac/draft-ietf-snac-simple/issues/180 Do we see any issues or complexities with having multiple AIL interfaces on one SNAC router? From my viewpoint: 1. For IPv6 routability, I didn't see any issue: the SNAC router receives a packet and determines the right AIL to forward it to based on IP address. 2. For IPv4 routability (via NAT64), the routability looks ok but the draft would need to detail how to apply the rules of Section 6 for the multiple AILs case. These are currently written as if there's a single AIL which is called "infrastructure". 3. For host and service discoverability, multiple AILs implies creating multiple DNS domains (each mapping to the .local of one AIL) and also may require a technique (supported via a Discovery Proxy) that allows a stub network client to unicast a single DNS query referencing a single domain, which then gets proxied into the multiple DNS zones i.e. executed as mDNS on all AILs. This is similar to how RFC 8766 says to query on both IPv4 and IPv6 based on a single unicast query. Also the naming of these multiple DNS zones may be a topic (marked "WG TBD" currently in the draft.) We may decide to either tackle these details, or update the draft to limit the scope to a single AIL only. best regards Esko
- [Snac] Handling multiple AIL-interfaces in a sing… Esko Dijk
- [Snac] Re: Handling multiple AIL-interfaces in a … Michael Richardson
- [Snac] Re: Handling multiple AIL-interfaces in a … Esko Dijk
- [Snac] Re: Handling multiple AIL-interfaces in a … Ted Lemon
- [Snac] Re: Handling multiple AIL-interfaces in a … Esko Dijk
- [Snac] Re: Handling multiple AIL-interfaces in a … Esko Dijk
- [Snac] Re: Handling multiple AIL-interfaces in a … Michael Richardson
- [Snac] Re: Handling multiple AIL-interfaces in a … Michael Richardson
- [Snac] Re: Handling multiple AIL-interfaces in a … Ted Lemon
- [Snac] Re: Handling multiple AIL-interfaces in a … Esko Dijk
- [Snac] Re: Handling multiple AIL-interfaces in a … Ted Lemon