**Session Date/Time:** 09 May 2024 14:00

# [SNAC](../wg/snac.html)

## Summary

The SNAC working group met to discuss the status of the `draft-st-rouer-ra-flag` document and address open issues and pull requests on the main SNAC specification document. Key discussions included seeking 6MAN adoption for the RA flag draft, refining the topology deployment scenarios appendix, and clarifying behavior regarding the L-bit in Router Advertisements and IPv4-only host communication. Several pull requests were merged, and new action items were identified.

## Key Discussion Points

### RA Flag Document (`draft-st-rouer-ra-flag-02`)

*   **Status Update**: The authors had uploaded an updated version of the draft after the previous IETF meeting, and it was ready for a request for adoption by the 6MAN working group.
*   **Adoption Request**: The chairs suggested that SNAC authors/chairs formally request 6MAN adoption. Jonathan, an author, confirmed the draft was ready and that the Working Group Last Call (WGLC) had completed without action items. Previous discussions about the bit placement (whether it would be an extension bit or not) were concluded with the understanding that 6MAN would decide.
*   **Early Allocation**: The group also agreed to request early allocation for the bit once the draft is adopted. It was noted that 6MAN typically only makes early allocation requests after a draft's adoption.

### Document Issue Handling (GitHub Pull Requests)

The working group reviewed and discussed several open issues and pull requests related to the main SNAC specification document.

*   **Topology Deployment Scenarios (PR #52)**:
    *   **Introduction Statement**: Kieran suggested adding a high-level statement to the introduction about stub router deployment scenarios. Consensus was to add text to the "Usability Goal" subsection, stating that stub routers can be attached to any network, but some configurations might not work as intended.
    *   **"Unmanaged Network"**: Discussion on whether a stub router needs to detect the presence of RA guard or port-based access control. The sense of those present was that it is out of scope for the technical specification and more an operational concern. The document should state that if such mechanisms are in place, the stub router's functionality might be limited (e.g., only NAT64 works), and that MDNS advertising unreachable services is a potential outcome.
    *   **"Managed Network"**:
        *   The term "properly managed" was adjusted to "managed" to avoid subjective judgment.
        *   Esco raised a specific scenario: a managed network using DHCPv6 for addressing but lacking RA guard, where a stub router might introduce SLAAC for a ULA prefix. Ted clarified that while this might not be the operator's intention, it's not a new problem as any unauthorized device could cause this (e.g., mobile tethering). The operator would need to implement RA guard or filtering to prevent such behavior.
        *   Discussion on potential ULA prefix conflicts if the managed network already uses its own ULA prefix. Ted explained that under current and proposed IPv6 address selection rules (including rule 5.5 and updated ULA behavior discussed in 6MAN), this is unlikely to cause operational problems for end users, though unexpected traffic might be observed by the operator.
    *   **"Unmanaged Non-Home Network"**: The group discussed the distinction between unmanaged home networks and other unmanaged scenarios (e.g., small business, public Wi-Fi). It was concluded that these scenarios are operationally very similar to unmanaged home networks with guest network isolation features. A note about the guest network scenario for unmanaged home networks will be added, and other unmanaged networks will refer back to this.
    *   **Decision**: The pull request was deemed ready for merging after text refinement, and it will close the associated issues (e.g., #52).

*   **Clarify Text as Needed (PR #55)**: This pull request, also fixing issue #33, was reviewed and merged.

*   **L-bit/A-bit Behavior (Issues #51 and #56)**:
    *   Esco noted existing text that allowed clearing the L-bit if technology required it, which led to confusion.
    *   Discussion ensued on the implications of not setting the L-bit (on-link bit) for SLAAC (e.g., how Neighbor Discovery and DAD would function). No practical use case for a stub router operating in such a Layer 2 environment where ND is unsupported was identified.
    *   **Decision**: Add text clarifying that the behavior of SNAC stub networks when connecting to Layer 2 networks where Neighbor Discovery is not supported (and therefore the L-bit cannot be set, but the A-bit could be) is out of scope for this document. This closes issues #51 and #56.

*   **Terminology (PR #60)**: This pull request, clarifying definitions of "node" and "host", was reviewed and merged.
    *   **IPv4-only Host Communication**: A discussion arose regarding IPv4-only hosts on the infrastructure network (not the stub network) and their ability to communicate with stub network devices. Ted clarified that such hosts would generally be unable to *initiate* communication with devices on the stub network, as communication would rely on NAT64 for outbound connections only.

## Decisions and Action Items

*   **RA Flag Document Adoption**: Jonathan (an author) will send an email to the 6MAN working group mailing list to request adoption and early allocation for `draft-st-rouer-ra-flag-02`.
*   **Topology Appendix (PR #52)**: Ted will finalize the text, including additions for managed network scenarios and unmanaged guest networks, and then merge the pull request. This will close associated issues.
*   **L-bit/A-bit Clarification**: Text will be added to the document stating that Layer 2 networks where Neighbor Discovery is not supported (and thus the L-bit cannot be set) are out of scope. This will resolve issues #51 and #56.
*   **Terminology**: PR #60 was merged, addressing terminology clarifications.
*   **New Issue**: An issue will be opened to discuss changing the term "stub router" to "SNAC router" throughout the document.
*   **Contributor Access**: Working group chairs will grant GitHub contributor access to individuals who wish to submit pull requests.

## Next Steps

The next SNAC working group meeting is planned for two to three weeks from now, subject to IETF scheduling minimums. Participants are encouraged to review open issues and submit pull requests.