Session Date/Time: 20 Jul 2026 14:30
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: Tim Winters
- 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 Geoff Huston (loopback
prefix expansion)
- Presenter: Geoff Huston
- 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 Jiayuan Hu
- Presenter: Jiayuan Hu
- 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:
draft-varhal-6man-icmp-srv6-vpn (Presented by Balazs Varga)draft-ali-6man-srv6-vpn-icmp-error-handling-04 (Presented by
Zafar Ali)
-
Slide Decks:
-
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: 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.