IETF Logo Mail Archive

[Snac] Why is an AIL prefix with only the "P" flag set suitable?

Esko Dijk <esko.dijk@iotconsultancy.nl> Tue, 18 November 2025 13:16 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 CABBB8BB8098 for <snac@mail2.ietf.org>; Tue, 18 Nov 2025 05:16:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=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 XXUrZVclX8wA for <snac@mail2.ietf.org>; Tue, 18 Nov 2025 05:16:45 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [185.233.34.146]) (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 CFA1A8BB808A for <snac@ietf.org>; Tue, 18 Nov 2025 05:16:45 -0800 (PST)
Received: from smtp.soverin.net (c04cst-smtp-sov01.int.sover.in [10.10.4.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 4d9lW96xPjz6X for <snac@ietf.org>; Tue, 18 Nov 2025 13:16:37 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4d9lW90Z9KzFB for <snac@ietf.org>; Tue, 18 Nov 2025 13:16:37 +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=P7Ro5pyD; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=soverin1; t=1763471797; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ikPtf9P7sGih6CET1+SrSVhAzCRWIjDXY+vMYfOzlYU=; b=P7Ro5pyDIs+oe2RCsRmQoAAhUwawEZ531ivBBWmr91FxagOSwE3+1JMYb2NBC9wRPVBS6n i8rR8uWBMrmbs/IgiIfYUOELcd9IuVedLW/bURobyMzmriY/DlhBoQSPFJ7yRK912biNS2 WCs6zCU64Uw7L5GB1DTqtet4eDr9MRZhMtzKHeFxeLV28n/2g9Y+dv7LU6acokyLmIBt3R YpV+iX1lwWInI01efZKERuaW42coOFOE2dHIgdvnSAB84j5/Lxl55Cd3wtzadW9NpVFLy3 jJtuvJjRC65SP374XX04UxfXDu2iyVjvTE2Bal98q1KVn6vYFfrmAMs1UNQEpQ==
X-CM-Envelope: MS4xfONyPB1NO68VcFZD3FMIOMgeVf+I/FUCYxvzlGfXua0ytKbNfDpEFFz/wFclU6MdLujQZFO5pPA8kZk1WmYA8IP04j3Y9oMwBD9ccho8R++gtD3Ct/Vo Ab/5h7/9pus/8vg9YOQPt2TM2pMX5DhxqWeFAwBwEXQPtbn1PdKUvzewyGIFKglRSCEL2d2PKpVYdg==
X-CM-Analysis: v=2.4 cv=d/oPyQjE c=1 sm=1 tr=0 ts=691c71b5 a=ASbY8W0BbCDwi/dCwKPOHQ==:117 a=ASbY8W0BbCDwi/dCwKPOHQ==:17 a=3Cmw36idhNzC94vK:21 a=r77TgQKjGQsHNAKrUKIA:9 a=lTrhJCJeAAAA:8 a=aKxRBhPAVqAjCUSaSIYA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=Rn6cnfX44RklNmFZLa4A:9 a=T62ttFHQAigvmzYn:21 a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10 a=msQidb1V7qGuAPALg0EV:22
X-Soverin-Id: 019a971c-2b08-794a-81da-bcc564f67469
Content-Type: multipart/alternative; boundary="------------IOYqOWypVIpsPu3E19U8pzjo"
Message-ID: <13441f45-57bf-48ea-9814-4d65214113a7@iotconsultancy.nl>
Date: Tue, 18 Nov 2025 14:16:39 +0100
MIME-Version: 1.0
Content-Language: en-US
To: snac@ietf.org
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
Organization: IoTconsultancy.nl
X-Spampanel-Class: ham
Message-ID-Hash: DSRMR4KMCJOHSV6WDCMNOQADDEBWIYJD
X-Message-ID-Hash: DSRMR4KMCJOHSV6WDCMNOQADDEBWIYJD
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] Why is an AIL prefix with only the "P" flag set suitable?
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/5cq8cpBXoA4ec-e8mQ4Hq_t6dp4>
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,

quick question here on a topic that I know we've discussed before - but 
I still don't understand this.

In Section 5.1.1, we say that a prefix with the "A" flag not set and the 
"P" flag set is suitable. So the SNAC router doesn't have to publish its 
ULA prefix in a PIO to serve devices on the AIL.

Now there can be various mDNS devices on the AIL that don't support DHCP 
(so no DHCP-PD client functionality). RFC 8504 lists DHCPv6 based 
address allocation as not mandatory; and it for sure doesn't say that 
DHCPv6-PD would be recommended or even mandatory.

There may also be devices that don't know about the P flag semantics.
If the CE router in this cases advertises an on-link prefix with only 
"P" flag set, then all of these services become unreachable for devices 
in the stub network.
This goes against the SNAC goals we have.  So why did we define it like 
this?

regards
Esko


-- 
*IoTconsultancy.nl* | Email/Teams: esko.dijk@iotconsultancy.nl | +31 6 
2385 8339

v2.46.0 | Report a Bug | By Email | System Status