Markdown Version | Session Recording
Session Date/Time: 23 May 2024 14:00
SNAC
Summary
The SNAC Working Group held its fourth interim meeting, focusing on resolving open GitHub issues. Key discussions revolved around the explicit definition of Router Advertisement (RA) contents in an appendix, handling "mixed-mode" devices that function as both stub routers and home routers, and the appropriate values for various RA fields like Cur Hop Limit, Reachable Time, and Retrans Timer. Ambiguity in existing RFCs regarding certain RA field usages led to an action item to consult the 6man WG. An issue with the proposed security considerations text was identified, and a consistent naming convention for RA flags was adopted.
Key Discussion Points
- RA Content Appendix: Discussion centered on creating an appendix to list all RA contents sent by a stub router, including rationale.
- Concern was raised regarding potential contradictions between appendix text and normative text in the main document.
- A sense of those present indicated that the appendix should list RA elements and refer to specific sections in the main document for detailed descriptions and rationale, rather than duplicating information.
- "Mixed-Mode" Router Behavior: Extensive discussion occurred regarding devices that act as both a stub router (e.g., connecting to a Thread network) and a home router (e.g., providing connectivity to an ISP).
- For a pure stub router, the RA
Router Lifetimefield should always be zero, as it is not a default router. - In the "mixed-mode" scenario (e.g., an Eero router with Thread), the
Router Lifetimemight be non-zero if the device is also acting as a default home router. - A key question was whether this "mixed-mode" use case falls within the scope of the current SNAC document, or if it requires a separate specification or references to existing RFCs like RFC 7084.
- Proposed behavior: If a stub router detects an RFC 7084 router on a "stub network" (e.g., by observing RAs without the stub router bit set), it should then cease advertising routes or prefixes on that network and on its infrastructure link for that network. This behavior is not yet explicitly documented.
- For a pure stub router, the RA
- RA Field Values (
Cur Hop Limit,Reachable Time,Retrans Timer):Cur Hop Limit: It was agreed that setting this field to zero (unspecified) is appropriate for a stub router.Reachable TimeandRetrans Timer: Significant ambiguity was found in RFC 4861 regarding how these values are used by hosts, especially when set to zero by a stub router. Concern was raised about correct host behavior if stub routers are the only RA senders and advertise zero.
- RA Flag Naming Convention: A proposal for a consistent naming convention for RA flags (e.g.,
L flag bit (on-link prefix)) was accepted to enhance clarity and searchability within the document. - Security Considerations: The current draft text for the security considerations section was challenged. It was noted that the text placed requirements on operators of infrastructure networks, which is outside the scope of a document defining stub router behavior. It was also pointed out that the potential issue (unwanted RAs on a network) is not unique to stub routers, as RFC 7084 routers already send RAs.
Decisions and Action Items
- RA Content Appendix: The appendix will list RA elements and refer to normative sections in the main document for detailed descriptions, rather than duplicating explanatory text within the appendix itself.
- RA
Reachable TimeandRetrans TimerValues:- The values for these fields in the draft will be marked as "TBD".
- Action Item: Ted T. composed and sent an email to the 6man WG during the meeting to seek clarification on the proper use and recommended values for these fields in Router Advertisements.
- RA Flag Naming: The proposed consistent naming convention, e.g.,
L flag bit (on-link prefix), will be applied to all RA flags throughout the document. - "Mixed-Mode" Router Behavior:
- Action Item: The document needs to clarify the behavior of stub routers when they detect a managed network (e.g., a network with an existing RFC 7084 router). Ted T. added a note to the relevant GitHub issue tracker for this.
- Security Considerations: The existing security considerations text needs revision to align with the scope of the SNAC document.
- Issue Assignments: Ted T. assigned himself the "State machine for N64" issue. Further assignments for open PRs and issues will be coordinated offline.
Next Steps
- Revise the "Security Considerations" section.
- Apply the agreed-upon RA flag naming convention consistently throughout the document.
- Incorporate feedback from the 6man WG regarding
Reachable TimeandRetrans Timervalues once received. - Continue progress on pending pull requests and open GitHub issues.
- The next meeting is scheduled in two weeks.