6MAN

Summary

The 6MAN Working Group met at IETF 126. The session was chaired by Jen Linkova and Bob Hinden (participating remotely). The working group discussed the status of active documents, the unblocking of Cluster 525, coordination with other working groups (such as Savnet and SNAC), and several working group and individual drafts. Key draft presentations covered 802.11 multicast optimizations, sub-link scoped multicast addressing, IPv6 node requirements updates, loopback address prefix expansion, flow label load balancing for RDMA, and ICMP error handling in SRv6 VPN networks.

Key Discussion Points

WG Status and Document Updates

Slide Deck: 00_Chairs_Slides
Cluster 525 Unblocked: The long-standing block in Cluster 525 was resolved by moving the simple SNAC router advertisement flag from a normative reference to an informative reference.
SLAAC Renumbering: draft-ietf-6man-slaac-renum is currently in Working Group Last Call (WGLC), with mailing list discussions ongoing.
Dormant and Expired WG Drafts: The chairs highlighted long-expired WG documents (e.g., the 4291bis draft, which has been inactive for nine years). Jordi Palet Martinez suggested sending separate emails to the list for each dormant draft to ask if any participants wish to take them over before officially removing them as WG documents on September 1st.
Coordination with Other Working Groups: Jen Linkova reiterated that 6MAN encourages problem-statement validation and solution agreement in originating working groups (e.g., SNAC, Savnet, Spring) before protocol modifications are standardized in 6MAN. Joel Halpern (Savnet co-chair) agreed that 6MAN should not spend time evaluating solutions before Savnet completes its architecture/problem definition phases.

Working Group Drafts

IPv6 wants 802.11 Flexible Multicast Service

Draft: draft-ietf-6man-ieee80211-fms
Presenter: David Lamparter
Slide Deck: IPv6 wants 802.11 Flexible Multicast Service
Discussion:
- The draft addresses IPv6 Neighbor Discovery Router Advertisement (RA) packet loss over Wi-Fi due to sleep-cycle mismatch. Wi-Fi chipsets often sleep through multicast intervals (DTIM) when the multiplier is configured too low (e.g., hostapd default of 2 versus chipset power-save thresholds of 5).
- The presenter discussed using Flexible Multicast Service (FMS) or Directed Multicast Service (DMS) defined in IEEE 802.11.
- Jerome Henry (remote) commented that FMS has negotiation overhead when multiple clients join/leave, making it less ideal for dense environments, whereas DMS is already part of the Wi-Fi Alliance power-save certification.
- Lorenzo Colitti raised a question on whether DMS supports buffering packets for hundreds of milliseconds to save battery.
- Éric Vyncke noted the existing liaison between the IETF and IEEE, suggesting this issue be added to the sync tracking list.

Sub-Link Scoped IPv6 Multicast Addressing

Draft: draft-ietf-6man-sub-link-scope-multicast
Presenter: David Lamparter
Slide Deck: Sub-Link Scoped IPv6 Multicast Addressing
Discussion:
- The draft exposes Layer 2 Ethernet multicast groups (defined in IEEE 802.1Q) to limit the propagation of IPv6 discovery protocols (such as LLDP) to the immediate physical wire, avoiding traversal of bridges/switches.
- The presenter highlighted that this is simple to implement (requiring about 31 lines of code in the Linux kernel) and does not define new Ethernet behaviors.
- Chairs encouraged more reviews of the draft.

IPv6 Node Requirements

Draft: draft-ietf-6man-rfc8504-bis
Presenter: Bob Hinden
Slide Deck: IPv6 Node Requirements
Discussion:
- Extension Headers: Since the EH limits draft did not progress, the authors reverted the text to the original RFC 8504 wording. Ron Bonica questioned if the clause "a host may disallow unknown options" contradicts RFC 8200. Tim Chown clarified that this is for end-host protection, not forwarding, and the default remains to accept. Justin Iurman suggested referencing this text in draft-ietf-6man-eh-occurrences.
- PMTUD: Added references to explicit RFCs based on feedback from Gorry Fairhurst.
- NAT64/Pref64 Discovery: Discussed how to handle RFC 7050. Lorenzo Colitti and Jordi Palet Martinez noted that RFC 7050 should be deprecated or updated to favor RFC 8781 (RA option). Jen Linkova recommended pointing to RFC 9872 to handle Pref64 discovery rules without repeating text.
- Default Address Selection: The authors plan to update the document to point to the updated default address selection bis draft (RFC 6724-bis).

Individual Drafts

The IPv6 Loopback Address Prefix

Draft: Individual draft presented by Warren Kumari (loopback prefix expansion)
Presenter: Warren Kumari
Slide Deck: 04_The IPv6 Loopback Address Prefix
Discussion:
- The draft proposes expanding the loopback space from a single /128 address to a /96 prefix.
- To avoid stalling on "numerology" debates, the draft leaves the specific prefix allocation up to IANA.
- Lorenzo Colitti noted that the selected prefix must have a clearly defined interface index length in accordance with RFC 4291.
- Éric Vyncke and the chairs supported moving the document forward to a WG adoption call.

IPv6 Flow Label Load Balancing for RDMA

Draft: Individual draft presented by Joanne (China Telecom)
Presenter: Joanne
Slide Deck: slides-126-6man-ipv6-flowlabel-load-balancing-rdma-01
Discussion:
- The draft proposes hashing ROCEv2 Queue Pair (QP) numbers to populate the IPv6 flow label, enabling better ECMP load balancing for RDMA flows and mitigating elephant flow congestion.
- Jen Linkova asked for clarification on whether the flow label is modified by an intermediate switch or the sending host. Joanne clarified that the ingress node performs the modification.
- Ron Bonica and Lorenzo Colitti noted that if the sending host writes the flow label, it is private behavior that does not require standardization, pointing to RFC 7098. Tim Chown suggested explicitly defining "elephant flow" in the draft's terminology.

ICMP Error Handling in SRv6 Networks

Drafts:
1. draft-varhal-6man-icmp-srv6-vpn (Presented by Balazs Varga)
2. draft-ali-6man-srv6-vpn-icmp-error-handling-04 (Presented by Zafar Ali)
Slide Decks:
- 06_ICMP Error Handling for VPNs in SRv6 Networks: draft-varhal-6man-icmp-srv6-vpn
- 07_draft-ali-6man-srv6-vpn-icmp-error-handling-04
Discussion:
- Both drafts address situations where transit (P) routers in an SRv6 network are VPN-unaware and cannot natively route ICMP errors back to the source Customer Edge (CE) device.
- Balazs Varga's proposal modifies the source IP address of the encapsulated packet at the ingress PE to make it VPN-specific, allowing returned ICMP messages to be parsed.
- Zafar Ali's proposal copies the outer destination address (VPN SID) of the transit packet to forward the ICMP error to the egress PE, which then routes it back to the CE (replicating MPLS VPN ICMP-routing behavior).
- Jen Linkova pointed out that the source address in Zafar's packet layout slide showed the ingress PE address, which would constitute spoofing. Zafar agreed the source address should be the local P-router address and committed to updating the draft.
- Ron Bonica suggested generalizing the mechanism to all IP-in-IP tunnels instead of limiting the scope to SRv6. Zafar Ali argued that implementers require SRv6-specific details.
- Joel Halpern (Spring co-chair) noted that Spring WG chairs have requested the authors of both drafts to merge their work. He agreed that Spring should align on the architectural approach before 6MAN handles any protocol or behavior specifics.

Decisions and Action Items

Action Item: Chairs to send individual messages to the mailing list for each long-dormant WG draft (including the 4291bis document) to see if there is any interest in reviving them before September 1st.
Action Item: Bob Hinden and Tim Chown to publish draft-ietf-6man-rfc8504-bis (-04) with updated references (including RFC 6724-bis and DHCPv6) and request Working Group Last Call.
Action Item: Authors of draft-varhal-6man-icmp-srv6-vpn and draft-ali-6man-srv6-vpn-icmp-error-handling-04 to merge their drafts and align on an architectural approach in the Spring Working Group before bringing it back to 6MAN.
Decision: Chairs will issue a Working Group adoption call for the IPv6 Loopback Address Prefix draft.

Automatic IETF Minutes