Session Date/Time: 09 Sep 2025 15:00

SNAC

Summary

The SNAC working group met to continue live editing, resolve outstanding issues, and review pull requests. Key discussions revolved around clarifying diagrams, simplifying M-bit flag handling in Router Advertisements (RAs), refining prefix selection criteria (ULA vs. GUA), and the scope of SNAC for multi-Access Infrastructure Link (AIL) and constrained network use cases. Several pull requests were reviewed, with some merged and others leading to new action items for further refinement or new proposals. The group also decided to continue with weekly interim meetings instead of a formal session at the upcoming IETF in Montreal.

Key Discussion Points

Diagram Clarification (PR 96): Discussion on the illustration of SNAC router topologies, specifically to clearly depict two SNAC routers on a single stub network and to add "plus signs" at network connection points for clarity.
Net64 Draft (PR): The first draft for Net64 was postponed as it requires the completion of the RA state machine, which is currently under development.
Constrained Sub SNAC Router / Multi-AIL Use Cases (PR, Issues 139, 115):
- The group discussed the advertising of specific routes versus default routes, particularly in constrained networks like Thread where advertising many routes is not sustainable.
- A proposal was made for non-constrained stub networks (e.g., Wi-Fi) to advertise all routes, but for constrained ones, only specific routes.
- For complex multi-AIL scenarios, especially in constrained environments, it was suggested that a separate document might be necessary as the current SNAC simple approach cannot adequately address all routing challenges (e.g., cyclical behavior, communication between routers about reachable prefixes).
- A participant proposed that a router advertising a Global Unicast Address (GUA) prefix on a stub network should also advertise a default route. A router not advertising a GUA prefix should only advertise a default route if the observed GUA prefix is routable via that router (akin to BCP38).
- A need for a new state machine specifically for managing prefixes on the stub network was identified, distinct from the AIL prefix management.
M-bit Flag Handling (PR, Issue 111):
- Previous discussions in Madrid and Bangkok highlighted the complexity and potential failure modes of elaborate M-bit handling mechanisms.
- The group agreed to simplify the M-bit handling: SNAC routers should repeat the M-bits received from the most recent valid infrastructure RA. If no valid RA is available (e.g., after a restart or RA expiration), the M-bits should default to zero.
- The existing pull request (111) which proposed an extensive appendix example for a complex copying behavior was deemed no longer necessary due to the simpler approach.
Hardcoded 64 Prefix Length (PR): A suggestion to clarify that /64 prefixes are suitable for Stateless Address Autoconfiguration (SLAAC) and consistent with current implementations, referencing RFC 4291 Section 2.5.1.
Timeout-Based Prefix Selection Criteria (PR): The discussion confirmed that if a choice must be made between a GUA and a Unique Local Address (ULA) for delegation, the GUA should be prioritized if it meets the minimum 30-minute lifetime requirement, aligning with the document's goal of internet connectivity.
ULA Prefix Generation (Issue from Fernando, RFC 9415/9416): A participant raised a point about ULA generation needing to comply with RFC 9415 (Category 3 algorithm). The group discussed whether these informational RFCs apply, concluding that if SNAC identifiers are intended to be stable rather than "transient numeric identifiers," then RFC 9415 might not be directly applicable.
Motivation Section (Issue from Fernando): A comment suggested adding more user motivation. The group acknowledged the existing motivations but decided to clarify in the introduction that the document addresses problems by using the internet protocol to avoid bridging incompatible media, which would not work.
"Beacon" Terminology: Discussion on replacing the term "beacon" with "periodic multicast RA" for clarity and to avoid confusion with link-layer beacons.

Decisions and Action Items

Decision: Update the diagram in Pull Request 96 to clearly show two SNAC routers on a single stub network and add "plus signs" at network connection points.
- Action: Darren to tweak the diagram for PR 96.
Decision: For the constrained sub SNAC router use case, update the document to describe the proposed behavior (advertise everything for non-constrained networks, specific routes for constrained).
- Action: Ted to write the new state machine for managing prefixes on the stub network.
- Decision: Postpone the multi-AIL use case for constrained networks to a potential future document.
Decision: Reject the current Pull Request 111 (M-bit flag) and adopt a simpler M-bit handling mechanism: repeat the last valid M-bits received from an infrastructure RA, defaulting to zero if no valid RA is present or on restart.
- Action: Darren to create a new Pull Request with minimal text implementing the simplified M-bit handling.
Decision: Merge the Pull Request fixing a typo related to "advertisements."
Decision: Merge the Pull Request aligning closing tags for the 30-minute value.
Decision: Apply the suggestion to the Pull Request concerning /64 prefix length.
- Action: Darren to update the Pull Request for the hardcoded /64 prefix question to reference RFC 4291 Section 2.5.1 and then merge it.
Decision: Merge the Pull Request for timeout-based prefix selection, reflecting the preference for GUA over ULA for internet connectivity.
Decision: Change terminology from "neighbor table" to "IPv6 neighbor cache."
- Action: Ted to implement this terminology change.
Decision: Close the issue regarding a lack of architectural diagram, as it is addressed by Darren's PR.
- Action: Darren to confirm Wi-Fi section fixes in Kieran's PR.
Decision: Use "multicast RA" instead of "beacon" for consistency.
- Action: Esco to make text changes for consistent capitalization and to replace "beacon" with "periodic multicast RA."
Decision: Close the issue regarding attaching stub networks to stub networks as out of scope for the current document.
Action: Ted to address the remaining work on prefix selection criteria (Issue 105) within the stub network state machine.
Action: Ted to draft text for the motivation section to clarify that the document uses IP to solve problems related to bridging incompatible media.
Action: Esco to submit a Pull Request with proposed text clarifying the meaning of the A-bit in Router Advertisements (Issue 123).
Action: Ted to address router unreachability detection and clarifying SNAC router behavior within the RA state machine.
Action: Ted to address Fernando's comment on RA processing requirements within the RA state machine.
Action: Esco to reply to Fernando regarding the applicability of RFC 9415/9416 to ULA prefix generation, focusing on whether SNAC identifiers are considered "transient."
Decision: Close Issue 139 (Multi-AIL) as it overlaps with other discussions and the conclusion to potentially handle it in a separate document.

Next Steps

Continue with weekly interim meetings throughout September to complete the document. The Chair will schedule these meetings.
Individual action items, particularly the development of the stub network and RA state machines by Ted, and various text clarifications and PR updates by Darren and Esco, are critical for progressing the document.
Future consideration of complex multi-AIL scenarios for constrained networks may warrant a new IETF document.