Session Date/Time: 07 Oct 2024 14:00

SNAC

Summary

The SNAC Working Group addressed several open issues, leading to technical clarifications and editorial changes in the draft. Key discussions centered on the definition of "suitable prefixes" in the context of DHCPv6 Prefix Delegation (PD) per device, ensuring SNAC routers correctly interpret network advertisements. The group also clarified the expected prefix length requested by SNAC routers and refined the distinction between a SNAC router and a Customer Edge (CE) router. Several pull requests were merged, and new action items were assigned for further document refinement.

Key Discussion Points

Stub Network Terminology: A pull request was discussed to change instances of "SNAC Network" to "stub Network." The rationale is that "stub Network" is a generic term, while "SNAC router" is the specific entity. Creating a new term for the network itself was deemed unnecessary.
Net64 State Machine: The editor, Ted, acknowledged an outstanding action item to provide a state machine for Net64. He noted a recent vacation but committed to working on it soon, leveraging its synergy with implementation review.
PD per Device and Usable Prefixes:
- The group discussed how SNAC routers determine "suitable on-link prefixes" when operating in a DHCPv6 PD per device (P-flag) environment, especially if the Autoconfiguration (A-bit) is not set.
- Concern was raised about legacy IoT or Android devices that might not support DHCPv6 PD per device or DHCPv6 Identity Association (IA).
- It was argued that Matter devices likely support IA, and Android devices could receive firmware updates. The primary scenario for PD per device is managed enterprise networks, not typical home networks where ISPs usually prefer SLAAC.
- A change was proposed to consider a prefix "suitable" if the P-flag is set, even if the A-flag is zero, to prevent SNAC routers from unnecessarily advertising their own prefixes.
IA_PD Prefix Hint:
- The discussion revolved around whether SNAC routers "SHOULD" or "MUST" request a specific prefix length using IA_PD.
- It was highlighted that a SNAC router is generally not a Customer Edge router. For devices in the home, requesting a /64 prefix length is preferred. Requesting larger prefixes (e.g., /60 or /48) for aggregation is complex and can lead to address waste or non-sequential allocations. It is simpler and more robust to request multiple /64s if needed (e.g., for multiple interfaces).
SNAC Router vs. Customer Edge Router Clarification:
- The relationship between SNAC routers and Home Gateways/CE routers was discussed. A CE router can have stub router functionality, but it is not considered a SNAC router, nor would it set the SNAC router flag in its Router Advertisements (RAs).
- A SNAC router is defined as opportunistically connecting to infrastructure, whereas a CE router is the infrastructure.
- A scenario was explored where a SNAC router connects to a stub network served by a CE router (e.g., Wi-Fi). If the SNAC router sees an RA on its southbound (stub) interface that does not have the SNAC router flag set, it should interpret that network as an infrastructure network and refrain from performing its own stub router functions (e.g., advertising its own prefix).
- This distinction will be clarified in the document, particularly in the glossary and a future state machine.
RA Requirements for Beacons vs. Unicast: It was confirmed that unicast Router Advertisements (RAs) are expected to have the same contents as RA beacons. RFC 4861 allows for multiple RAs but does not encourage different values, and no technical reason was identified to diverge from consistent content.

Decisions and Action Items

Decision: Merged the pull request changing "SNAC Network" to "stub Network" (Issue closed).
Decision: Modified the definition of "suitable on-link prefixes" to include prefixes with the P-flag (PD per device) set, even if the A-flag (autoconfiguration) is zero. (Issue #38 closed via PR merge).
Action Item (Ted): Create text/PR to update the "suitable on-link prefixes" definition (completed and merged in meeting).
Decision: Changed the specification for SNAC routers to MUST request a stub network prefix with a length of /64 when using IA_PD. (Issue #90 closed via PR merge).
Decision: Closed the issue regarding the RA flag bit position, as the current text correctly points to the defining draft. (Issue closed).
Decision: Added text to the glossary of the SNAC document to clarify that a SNAC router is not a Customer Edge router.
Action Item (Ted): Create a pull request for the glossary clarification regarding SNAC router vs. CE router (completed in meeting).
Decision: Closed the issue regarding RA requirements for beacons vs. unicast, as existing document text addresses it. (Issue closed).
Action Item (Jonathan): Create an initial diagram illustrating the general solution, showing infrastructure, a home router, stub routers, and stub networks (including multiple stub routers). (Issue #75).
Decision: Merged an editorial fix to the state machine text (line 458) concerning the "State begin advertising" transition. (Issue #73 closed via PR merge).

Next Steps

Ted will continue work on the Net64 state machine and the stub router on-link prefix state machine. These will be discussed at the next meeting.
Jonathan will provide an initial diagram for issue #75.
Cosmetic and minor editorial changes will be addressed.
The group will reconvene in Dublin to continue discussions and review pending work.