Markdown Version | Session Recording

Session Date/Time: 20 Jun 2024 14:00

SNAC

Summary

This was the sixth and likely final virtual interim meeting for the SNAC Working Group before the face-to-face meeting in Vancouver. The session focused on reviewing and resolving open GitHub issues, aiming to prepare the draft for the upcoming submission deadline (July 8th). Significant progress was made on clarifying router advertisement (RA) behavior, IPv4 reachability, DHCPv6 Prefix Delegation (PD) conditions, and establishing a security considerations section. Multiple pull requests were merged during the meeting, substantially reducing the backlog of open issues.

Key Discussion Points

• Issue 36: Router Advertisements on Stub Network
  • The group reviewed a pull request related to router advertisement behavior on the stub network, specifically concerning the changes to terminology.
  • The changes were deemed complete. A participant volunteered to kick off the pull request and verify the XML generation, allowing the issue to be closed.
• Issue 37: DHCPv6 PD Renew/Rebind Conditions
  • Initial discussion was deferred due to a participant's absence but resumed later with their presence.
  • The group discussed the behavior of a SNAC router when the adjacent infrastructure link changes or a delegated prefix cannot be renewed.
  • It was noted that, especially for constrained networks like Thread, changing the prefix on the stub network can be expensive and should be avoided unless strictly necessary.
  • Consensus indicated that the SNAC router should continue using a delegated prefix until its lease expires, even if network conditions change or renewal attempts initially fail. If renewal persistently fails and the T2 rebind interval specified in RFC 8415bis Section 21.4 has been reached, the SNAC router should deprecate the non-renewable prefix and fall back to advertising a ULA prefix (if available).
  • New text reflecting this behavior was drafted and merged, referencing RFC 8415bis.
• Explicit State Machine for Stub Router On-Link Prefix
  • A standing action item to add an explicit state machine for the stub router's on-link prefix was acknowledged but not discussed in detail during this session, as it was not yet drafted.
• Editorial Issues (e.g., Consistent Terms, Capitalization)
  • Several trivial editorial issues (e.g., using consistent terms, capitalization) were identified as suitable for offline resolution by volunteers.
• Issue 40: Security Considerations Section
  • The document was found to be missing a security considerations section.
  • A proposed text addition from an open pull request was reviewed and merged, officially adding this crucial section to the document.
• Issue 41: Decide on Stub Router Flag Bit Position
  • It was noted that a previous call for options on this topic had already received sufficient "yes" votes, indicating a consensus within the working group. The issue remains open but no further discussion was needed.
• Issue 42: Change "Stub Router" to "SNAC Router"
  • This was identified as a trivial editorial change, suitable for offline implementation without requiring a full working group review.
• Issue 58: IPv4 Host Communication with Stub Hosts
  • Discussion centered on clarifying the document's introductory text regarding IPv4 reachability for SNAC hosts.
  • Participants discussed the distinction between "reachability" (the ability to send packets) and "communication" (successful bi-directional exchange), particularly concerning potential security implications. The group noted that SNAC's primary goal is to provide reachability.
  • It was clarified that the document's scope is to enable this reachability, assuming security filtering would be handled at the edge (e.g., by an RFC 7844 router) and not directly within the SNAC/infrastructure interface definition.
  • New paragraphs were drafted to explain how SNAC enables IPv4 services and connectivity for stub hosts, while explicitly avoiding over-specification of security frameworks within this document's scope. This text was merged.
• Remove Text Allowing the L Flag to be Zero
  • A pull request addressing this point was reviewed. The change involved explicitly stating that both the A flag and the L flag in router advertisements must be set, aligning with previous group agreements.
  • This change was merged.
• Issue 60: Stub Router Required to Stop Sending RAs when in State Suitable
  • The existing text implying that RAs should stop in State Suitable was identified as incorrect or misleading.
  • The group discussed the general behavior of sending RAs across different SNAC router states.
  • It was clarified that the SNAC router is expected to send RAs during all states except State Unknown.
  • Two independent conditions for RA inclusion were identified:
    1. Advertising a reachable (i.e., not link-scoped, or "realm local" as per Thread's specific definition in RFC 7346) prefix on the SNAC network.
    2. Maintaining and advertising any deprecated prefixes to ensure graceful transition for hosts.
  • New text clarifying these points was drafted and merged, providing more detailed guidance on RA generation and handling of deprecated prefixes.

Decisions and Action Items

• Decisions:
  • Pull requests related to issues 36, 37, 40, 58, 60, and the removal of text allowing the L flag to be zero were reviewed and merged.
  • The working group agreed that the SNAC router should continue using a DHCPv6 PD delegated prefix until its lease expires, even if renewal fails, only triggering deprecation and ULA fallback after the T2 rebind interval has been reached.
• Action Items:
  • A participant will kick off the pull request for Issue 36 (Router Advertisements on stub network).
  • Ted will continue working on the explicit state machine for the stub router's on-link prefix.
  • Volunteers are encouraged to address trivial editorial issues (e.g., consistent terms, capitalization, changing "stub router" to "SNAC router") offline before the submission deadline.
  • General Protocol: Participants are asked to assign any issue they intend to work on to themselves before creating a pull request, to avoid accidental duplicate work or conflicts.

Next Steps

• Submission Deadline: The IETF submission cut-off for new drafts is July 8th.
• Pre-submission Check-in: The working group aims to have a final virtual check-in on Thursday, July 4th. The goal is to ensure all straightforward editorial changes and any remaining quick fixes are completed and merged before the deadline.
• Document Submission: The working group plans to upload the latest version of the draft before the July 8th deadline. A participant other than the main editor may handle the final submission.
• Next Meeting: The next formal meeting of the SNAC Working Group will be face-to-face in Vancouver.