SNAC

Summary

The SNAC Working Group met to progress open issues and pull requests for draft-ietf-snac-simple (Automatically Connecting Stub Networks to Unmanaged Infrastructure) during its Working Group Last Call (WGLC) period. The discussion focused on refining prefix selection logic, clarifying the limitations of link-layer bridging in the introduction, and addressing the complexities of multi-link (multi-AIL) configurations.

Key Discussion Points

Selection of Best DHCPv6-PD Prefix (Issue 99)

Discussion: The group discussed how a Stub Network Access Consumer (SNAC) router should behave when multiple prefixes (GUA and ULA) are available or when multiple SNAC routers are present.
Technical Detail: Jonathan Hui noted that if a GUA is already being advertised on the stub network, other routers should not attempt DHCPv6-PD. In the event of a timing race where multiple GUAs are advertised, the numerically lowest prefix should be retained, and others should be withdrawn via an RA with a lifetime of zero.
Multi-AIL Context: Esko Dijk mentioned that current text forbids operation under multi-AIL scenarios to maintain simplicity. The group discussed the difficulty of detecting multi-AIL across different technologies (e.g., Thread vs. Wi-Fi).
Draft Context: Concerns were raised regarding draft-ietf-snac-simple providing enough detail on when to release or refrain from requesting prefixes to avoid exhausting infrastructure pools.

Introduction and Motivation Clarification (Issue 101)

Discussion: Éric Vyncke suggested clarifying why standard bridging is insufficient for stub networks, specifically citing incompatible MAC address lengths (e.g., IEEE 802.15.4 vs. IEEE 802.11).
Outcome: Jonathan Hui submitted a PR to split "Incompatible Media" and "Inconsistent Availability" into separate bullet points. The text now explicitly states that bridging is often impossible due to incompatible layer-2 framing and addressing.

Router Unreachability Detection (Issue 107)

Discussion: The group reviewed whether specific requirements for recording router state (based on related IPv6-ops work) should be mandated.
Consensus: The sense of those present was that specifying internal implementation details for state recording is unnecessary. The issue will be closed without changing the draft, as it is considered an implementation detail.

Maintenance of Addressability (Issue 109 & 110)

Discussion: The group discussed requirements for SNAC routers to join specific multicast groups (All-Routers and Solicited-Node) on both the Adjacent Infrastructure Link (AIL) and the stub network.
Decision: Ted Lemon and Jonathan Hui agreed that if Neighbor Discovery/RAs are used on the stub network, the SNAC router must join these groups on the stub interface as well.
M and O Bits: Regarding the copying of M (Managed Address Configuration) and O (Other Configuration) bits from infrastructure RAs, Ted Lemon argued that the draft must remain explicit to ensure stale or expired RAs are not used to populate these bits in the SNAC router's own RAs.

Multi-AIL Constraints (Section 5)

Discussion: Esko Dijk had previously added a "MUST" requirement to prevent multi-AIL configurations. However, Ted Lemon and Jonathan Hui noted that accurately detecting this state is technically difficult and potentially out of scope.
Decision: The group decided to convert the "MUST" requirement into a warning. The text will state that connecting multiple SNAC routers to different AILs is out of scope and not supported by draft-ietf-snac-simple.

Decisions and Action Items

Decision: Approved and merged PR for Issue 101 (Intro bridging clarification).
Decision: Approved and merged PR for Issue 109 (Multicast group joining on stub interface).
Action Item: Jonathan Hui to finalize text for Issue 99 regarding prefix selection and withdrawal logic.
Action Item: Esko Dijk to update Section 5 to change the multi-AIL "MUST" to a warning and mark the scenario as out of scope.

Next Steps

The authors will merge the remaining agreed-upon PRs and submit draft-ietf-snac-simple-10.
Darren Dukes will notify the mailing list of these changes to ensure the working group can review the updated text before the WGLC concludes (target date: May 15th).
Authors and contributors are reminded to disclose any relevant patents as per IETF process during the WGLC.

Automatic IETF Minutes