Minutes IETF124: 6man: Fri 14:30
minutes-124-6man-202511071430-01

Meeting Minutes IPv6 Maintenance (6man) WG
Date and time 2025-11-07 14:30
Title Minutes IETF124: 6man: Fri 14:30
State Active
Other versions markdown
Last updated 2025-11-14

minutes-124-6man-202511071430-01

6MAN Working Group - IETF 124 Montreal

Friday, 7 November 2025, 09:30-11:00 (GMT-5)

Room: Lauier
Chairs: Bob Hinden, Jen Linkova
Minute taker:Yao Liu
Jabber Scribe: N/A

Jabber Room: 6man@jabber.ietf.org

Meetecho (Full Client):
https://meetings.conf.meetecho.com/ietf124/?session=34596

Meetecho (Onsite Tool):
https://meetings.conf.meetecho.com/onsite124/?session=34596

Agenda Friday, 7 November 2025, 09:30-11:00 (GMT-5)

  • Introduction, Agenda Review, and Document Status , Chairs, 10 min.

Working Group Drafts

Active Individual Drafts

If Time Allows

Introduction, Agenda Review, and Document Status , Chairs, 10 min.

Discussion about draft-ietf-6man-icmpv6-reflection
Bill: The icmpv6 reflection document has a normative reference to
8335bis in intarea, 8335bis is stuck in WG LC due to not enough support.
If we want to proceed the icmpv6 reflection doc, it would be great to
have support for that WG LC in intarea.

Discussion about RFC6724bis
Tim: There's a potential rfc6724-bis-bis, whether to update the existing
document or put in a new document.
Lorenzo: Maybe first to try to write some texts to see if it makes
sense, then see if it could be put into rfc6724bis.
Jen: Base on the discussion in HAPPY yesterday, maybe some updates of
RFC6724 are needed again. Maybe start with what we want to achieve and
if there's a need to update RFC6724, we may just do another quick
revision before it gets published.
Jen: I took an action item of drafting something which could be
discussed here or in happy or in both and when we agree on what we're
trying to achieve, we can see what exactly we need to write in which
document.

Discussion about the draft-ietf-6man-eh-limits
Eliot Lear (ISE): The document has been submitted to the ISE. It can't
be handled in it's current form.
Bob: Breaking it into several documents might be a better approach. Put
the host side and the router side in different documents.
Eliot: I'm expecting the work to continue here.
Timothy: I think it's something we need to work on. Is that what we're
not doing and we're going to work on this in different ways?
Jen: Yes, nobody said we shouldn't work on the problem.
Tim: There's good stuff in there about protecting a node from excessive
hop-by-hop options,it is useful to have a standalone RFC. Pulling out
the protection from excessive HBHs is good.
Suresh: A main concern is this document is trying to specify the minimum
thing you should support. But by setting this minimum thing, you're kind
of ossifying this thing and then it becomes a new maximum.

About ICANN request
Jordi: I'm going to have a draft not only about IPv6，but also for the
IPv4 address. I don't think 127 is the right one.
Jen: It does look like something intarea may want to consider. It
doesn't look like IPv6 specific.

Clarifying SRv6 SID List Processing, draft-ietf-6man-sidlist-clarification , Adrian Farrel / Suresh Krisnan, 10 min.

No comments.

[Chairs Note] Not too many people raised hands after being asked who
had read the document. Need more review. Probably also good to get some
feedback from the Spring w.g.

Carrying Network Resource (NR) related Information in IPv6 Extension Header, draft-ietf-6man-enhanced-vpn-vtn-id , Jie Dong, 10 min.

Suresh: Want fixed-length NRP-ID. Concerns about the context extension
part.
Zafar: 32-bit NRP-ID is too large, security concerns about hijack risk.
Perfer to fixed-length, shorter and generic ID, should be hardware
friendly. MPLS is also discussing about NRP-ID, it will be important to
have some synergy on NRP ID across data planes.
Chongfeng: 32-bit NRP-ID makes sense in the long term.

[Chairs Note:] Needs more work before doing w.g. last call.

YANG Data Model for IPv6 Neighbor Discovery, draft-ietf-6man-ipv6-neighbor-discovery-yang , Fan Zhang, 10 min.

Jen: The draft requires some input from operators or people who use it.
Read it and comment.

IPv6 Query for Enabled In-situ OAM Capabilities, draft-ietf-6man-icmpv6-ioam-conf-state, Xiao Min, 10 min.

Request for WG last call.
Jen: Need more people to read it and comment.

IPv6 Node Requirements, draft-ietf-6man-rfc8504-bis , Tim Winters, 15 min.

Lorenzo: A question about 7050, don't we have another document in v6ops
that says don't do it?

Jen: The v6ops document differentiate at least in cases of mobile VS
non-mobile hosts. If we include mobile devices here, it might be a bit
early to say "should not" because it would break mobile devices. However
we also should say that it should use pref6 for discovery from RA
because v6ops recommends that to use first. We don't want to have
conflict between different documents here.
Lorenzo: I guess the pref64 option is already there. That definitely is
a should.

Jen:For the sake of progressing this document, it's fine to remove text
for eh-limits-draft.

Jen:As the author of the two v6ops document mentioned, very confused
about the prefix discovery slide, is it a may or should?
Tim: Will sync up with the v6ops.

Lorenzo: Another potential document to consider is ?, it is an RFC now.

David: The DA in draft-ietf-dhc-dhcpv4-over-dhcpv6-ra, it's about relay
agents, the draft is inapplicable for this.

Jen: Have we discussed the P flag support?
Tim: We don't have the P flag, will add an issue about that.

[Chairs Note:] Probably ready for w.g. last call before or at the next
IETF meeting.

Sub-Link Scoped IPv6 Multicast Addressing, draft-equinox-6man-sub-link-scope-multicast , David 'equinox' Lamparter, 10 min.

Michael: It's useful. This exactly what we want to do for grasp
discoveries. Please adopt it.
Stig: It's useful. Could it be used in IGMP for MLD snooping?
David: Maybe. The problem is there isn't currently a group in ethernet
that corresponds to MLD snooping because that's not necessarily a
function that's enabled in all the switches.
Erik: Why not just use link local?
David: The problem I'm trying to address is that there's no way to
request the different scope from the upper layer.If I do a packet
socket, I couldn't just send an IPv6 packet with a different destination
multicast MAC address. That would work, but that means I need to bypass
the IPv6 stack because the IPv6 stack doesn't have this mapping for a
group address to this ethernet MAC.
Jen: Adoption call?
David: Let's make an adoption call.

[ACTION:] Chairs will start an adoption call.

Compact Routing Header (CRH) Helper Option, draft-bonica-6man-crh-helper-opt , Ron Bonica, 5 min.

Jen: Like the idea of doing it in an experimental way.
(from the chat) Michael Richardson: If this CRH helper has no IANA
Considerations, does it even need an RFC number in order to do the
experiement?

Ron: Asked for an adoption call.

Updates to DNS64 Functionality Advertisement for DNS RA Option, draft-ma-6man-ra-dns64-flag , Chenhao Ma, 5 min.

Philipp: Changing RA options in a deployment at least takes 4-5 years to
be usable. If you really have this use case, you may just take the
resolvor, whether it's DNS64 capable, then either filter it or filter
the DNS64. The suggestion is to fix the way DNS64 is handled in the UA
instead of introducing a new option.
Ted: You have to make changes both in the router and the host to make it
work. Why not just use the pref64 option or IPv4-only,i.e, RFC7050
solution?
Lorenzo: I don't see the usecases at all. Just a new bit in the option
doesn't seem to do anything useful. It tells new hosts that some servers
are different, those hosts already have the pref64 options, so they can
already do synthesis themselves. This is implemented in major operating
systems already so that's a solved problem.
Jen: Not clear what the use case is, why not use the existing solutions.

ICMP Error Handling in SRv6 based VPN Networks, draft-ali-6man-srv6-vpn-icmp-error-handling , Zafar Ali, 5 min.

Ron: This works for IPv6-in-IPv6 and IPv4-in-IPv4, might be the wrong
WG.
Zafar: We can collaborate.
Bob: If the focus is SRv6, then we will need to hear from the SPRING
chairs, but if it is more about general internet area, then it may be
more related with intarea. You should work on this and decide what you
want to do.

Meeting Adjourned