6MAN Working Group - IETF 122

Friday, 21 March 2025, 09:30-11:30 (GMT+7)
Room: Sala Thai Ballroom

Chairs: Bob Hinden, Jen Linkova

Minute taker: Yao Liu

Jabber Room: 6man@jabber.ietf.org
Meetecho (Full Client):
https://meetings.conf.meetecho.com/ietf122/?session=33813

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

Friday, 21 March 2025, 09:30-11:30 (GMT+7)

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

Working Group Drafts

Internet Control Message Protocol (ICMPv6) Reflection

https://datatracker.ietf.org/doc/html/draft-mh-6man-icmpv6-reflection
Speaker: Ron Bonica, 15 min.

Ron： Already has implementation. Ask for WG last call

Zafar：What the draft does not specify is that currently when we do trace
route, the specification allows a copy of the invoking packet to be sent
back which does have the content of the packet as it is modified in
flight, and many implementations at present are using that method for
the debugging purposes that you are trying to solve here. So it would be
good to have the description of an alternate way that people are doing
it. Trace Route, when the TTL expires, an ICMP error with time exceed or
other ICMP error can send a copy of the invoking packet back to the
sender, which sender can then use to see how the packet was modified in
flight and get the information that you're trying to do using this.

Ron: Are you saying that it would be the original data field?

Zafar: It is the copy of the invoking packet

Ron: I don't know of any extension object yet that will send back the
entire packet. There is an original data field, but the original data
field in many cases is only something like 64 bytes long, it doesn't
include the entire packet. And in many cases, it would actually violate
security policy to send that back. For instance, in many cases, you
don't want to expose what your NATs were doing.

Zafar: Those security problems exist in your draft too, you should have
a fair description of that in your draft. another comment, do you need
all of these options, or you can just say that is up to the responding
node to provide the content back based on the local policies. Because
there's a security issue at the transit node where you're trying to get
the information of the packet from.

Ron: The reason is that we didn't want the size of the response to be
greater than the size of the probe, so we wanted to make sure that for
everything you asked for, you had to send some zero bytes to make sure
the probe would always be exactly the same size as the response.

Zafar: Does the feature brings complexity? It is always assumed that
based on the datagram possible in the response, things would be put in.

ACTION: Chairs will start working group last call.

Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Event

https://datatracker.ietf.org/doc/html/draft-ietf-6man-slaac-renum
Speaker: Fernando Gont, 20 min.

Suresh: I did look at the new text and I'm happy with the change that
shows what is getting updated.

Lorenzo: If you take the default parameters that are suggested, the new
default parameters, what level of packet loss will result in the device
disconnecting?

Fernando: I don't remember. What we did do was to use values that were
even larger or more loss resilient than the recommendations that you had
in the RFC that was described in the topic.

Lorenzo: We should probably update that. Maybe that shouldn't block Last
Call. I think we need to figure out, whatever we put here will be put in
by router vendors and if 50% packet loss will result in devices
disconnecting, we need to change these values.

Fernando: We have the default, it's an increase of what the specs say
nowadays. There's also this tables that we have produced so that folks
can override that value if they wish. Valid comment. Could be addressed
as part of the WG Last Call feedback.

Ted:I would like to see this go to Last Call now. We may find that we
need to do a follow-on or something like that anyway, but not having any
guidance at all or leaving the guidance the way it presently is I think
is not the right thing. Also, this is a good time for me to do a Last
Call review and make sure that I don't see anything that needs to be
tweaked.

Bob: For the Working Group Last Call, it would be a good way to get more
people to review it and comment. We will plan on doing that next week.

ACTION: Chairs will start working group last call.

IPv6 Node Requirements

https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc8504-bis
Speaker: Tim Winters, 20 min

Bob: The EH limits document was sumitted as informational, so it'll be a
little more complicated.

Tim: It's just telling people there's the information for extension
header limits. We'll have to massage that text correctly and do the
right things.

Éric Vyncke:Why you are adding the informational extension header limits
there. I would frankly prefer not mention it at all.

Tim: I don't know what we want to do with that text. One option is we
can just leave that text alone, but it does kind of stand out as a
little odd.

Éric: We need to to review the current text. But I would not like to see
hard limits or minimum hard limits.

Lorenzo: RFC8028 tries to do something reasonable,it's just written in a
way that's impossible to understand and implement. If anyone has
implementation of RFC8082 please speak up.

Jen: Based on the recent email thread which Fernando and I participated
in, I started feeling that we have different understandings of what
exactly RFC8028 suggests.
My reading is it's necessary to implement source just routing and send
the same packet of the existing flow when you already have a source
address, to send it to the right next hop. It has nothing to do with
selecting the source address and so on, but I suspect we have different
reasons.
Maybe we need a (new?) document, most likely not this document, talking
about in general the host behavior of multihome environment and what we
expect it to do, and what should the implementation details be hidden
from the network? Which we do not need to specify, but what behavior we
expect.

Tim: Node requirements is not the place to hash out multiprefix. So one
thing we could do is just wait until the last minute and see what
happens in the working group with V6OPS and 6MAN documents about this
problem.

Bob: This might be a good place to write down what we have, to clarify
what we think the RFC says.

Lorenzo: I think RFC8028 starts going wrong in the 7th line: "The
selection of the source address is done before the first hop router for
that packet is chosen..."

David: If this reference is RFC8028, it should also reference errata
7009 on this which fixes that exact sentence

Jen: I think 8028 kind of specifies implementation details, but what we
really need this document or maybe a separate one because it might be
the reference requirements. How do we expect the device to behave? How
it chooses the behavior, is implementation specific, but on the other
hand, I've heard there are some implementations of rule 5.5 in some
operating systems so I would love to hear from those implementers how
exactly they did it. Do they support what RFC8028 suggests? Do they do
something different, which ends up in the same behavior?

Tim: They do something different. We've tested this. We've had some
experiment with this, and it's slightly different than what RFC8028
suggests. They've come up with slightly different algorithms to deal
with this problem, or at least the four implementations of 5.5 that I'm
aware of. A lot more clients supporting 5.5, I don't remember offhand.

Ted Lemon: I write a note to our testing department about the fact that
I don't know how this works and maybe we should add some tests.

Jen: I'm very, very serious to finally to get to the Hackathon next time
to test 5.5 and multihoming environment. You are welcome to join in
Madrid.

Lorenzo: I think the 5.5 implementations we have kind of work and
probably address some subset of the use cases that would be addressed if
you implemented something like RFC8028, assuming you read the errata.
And I don't know that anyone implements that actually for real.
As a group we need to figure out two things. We need to figure out
what's supposed to work, and we need to figure out what does work today.
Much as I would love to put this stuff in there, I just think it's
premature.

Tim: My instinct here is to wait. We've got a couple of updates to do,
so I think we can sort of slow-roll this and see if we're lucky at the
hackathon in Madrid, we sort out what we want to do and we can write it
down, and if not, we'll address it down the line. I'll talk with the
other authors and see what we think.

Lorenzo: Do OSs like Linux implement PLPMTUD?

Tim: It's not on by default. You can do it. It's there. But you have to
put all the bits.

Jen: I will encourage people to read it because I think it's a
fundamental work. If later your laptop or phone does not work as well as
you want it on V6 only network, do not complain, maybe we just missed
something in this draft. Please read it.

Active Individual Drafts

Clarifying SRv6 SID List Processing

https://datatracker.ietf.org/doc/html/draft-farrel-6man-sidlist-clarification

Speaker: Adrian Farrel, 10 min

Erik: (AD hat on)Thank you for looking at this, for doing this. Maybe I
am the only one or maybe we are the only two who care.
(AD hat off)I think updates makes sense. Can you remind me the meaning
of the Segments Left when there's a REPLACE-CSID. Does that remain
pointed at the REPLACE-CSID until it's fully consumed?

Adrian: Yes.

Erik: Because we did have an errata that I think Joel filed to clarify
that segments left refers to the number of 128-bit segments in the entry
list.

Adrian: I think segments left really means segment list entries left.

Erik: Exactly. If you feel like throwing that into the document, as
well, I wouldn't object to that, either.

Bob: It's worth clarifying because it had to be clarified. It makes
sense to me that what's in the destination address, the field of an IPv6
header should be an IPv6 address. Seems fairly simple.
I don't personally object to doing it here, but I don't have a strong
opinion at the moment on whether it's standard track or informational.

Adrian: I think that's just a process thing. If we do an update to a
standards track, I think we have to do standards track.

Jen: (Chair hats on) Maybe we need to talk to SPRING chairs and ADs. We
obviously would like to hear the group opinion, but in parallel I guess
we'll talk about and find out if there are any strong opinions about
where this work belongs. This work needs to be done, and it's a kind of
work that aligns. I do not think it matters as long as it's done, but we
can find the best home for it here.

Nick Buraglio(from the chat):Clarification is important. I don't have a
strong opinion on where it goes, but should be reviewed by at least
SPRING

Adrian: We'll tidy up the document and make sure it's seen by both
working groups and beyond that it's just process.

Jen: I think the documents should be reviewed by both groups, which
group officially owns it to be decided, but I'm sure it will find a
home.

Suresh: I personally think 6MAN has a closer connection to this draft
since it's mainly about RFC8754, but we can go talk to SPRING about it.
And at least maybe ask for a slot next time or send a pointer to the
list and talk about it.
But I think the SPRING side of the story is done. If you look at the
SRv6 compression draft that got us into this thing, it actually has the
update, and has some text already. So I personally prefer it to be in
6MAN, but no strong feelings about it. And maybe a combined Last Call or
something like that might be easier instead of pushing a draft.

Adrian: The beneficiaries of this will all be SPRING.

Jen: We might separate the discussion about who reviews it vs who
officially owns it.

Alvaro: I believe if this work is going to be done, it should be done
here, because it updates RFC8754. I just want to point out that when the
compression work was going on, we, SPRING, consulted 6MAN several times
on different things, around RFC8200 and RFC8754, etc. And one of the
questions that we asked, was about whether compression should update any
of these documents. And both times we walked away with, no. we would go
as we are. And the compression document made it through the IESG without
an update. It feels like this wasn't part of the original process, so on
the one hand, I'm not going to stand in front of the group with this
document, but I don't think it is necessary.
SPRING hat on, yes, please discuss it with SPRING, if it's going to go
forward. It is your document, it's your working group.

Adrian: It's interesting that there is an individual idea of approaching
SPRING that makes another variation on what's in the SID list, so what's
there is not an IPv6 address, and that's the encryption draft.

ACTION: Chairs will followup with SPRING chairs and AD regarding who should own document and intented status.

Using Prefix-Specific Link-Local Addresses to Improve SLAAC Robustness

https://datatracker.ietf.org/doc/html/draft-link-6man-gulla
Speaker: Jen Linkova, 10 min.

David: In RFC4861, section 6.3.6. It says the policy for selecting
routers from the default router list is as follows: Routers that are
reachable or probably reachable should be preferred over routers whose
reachability is unknown or suspect. I think that answers the whole bunch
of things that you just said. And you should just reference that.

Jen: If you look in the email thread Fernando started, he believes in
this case, it would apply for per prefix set of next Hops.

David: Of course. It's per next Hop.

Jen: If you have prefix 1 with next Hops a,b, prefix 2 with next Hop c
and d, you would prefer one of two, if only one of them is reachable for
each prefix, but you might not go to look at other next Hops for other
prefix. I think it's minor clarification to RFC8028. We all agree it
should be like that. But it might be read differently. So I understand
that you mean, but I think it would be worth clarifying the text.

David: Definitely need something about this. Let's put it that way.
Second, you said that it must be disabled by default. A little biased
as an implementer because I would give it a little bit of trust to the
people writing the code for this and hope that they don't just add an
infinite amount of link-local addresses and keep spamming things, and
this one must be disabled by default. I guess it's fine. I would rather
do something sensible when I write code for this.

Jen: You probably heard that it was some document issued recently about
using "must" and "should" because we have to justify the should, I would
like to hear your suggestions, in which case you should enable and in
which you should disable it. It might be enabled still if you think that
interface might be prone to flesh renumbering. If you know you have the
DHCP client and on this interface you put addresses from BGP prefix,
then it actually makes sense to enable by default. But I would love to
hear from implementers.

David: About the sending RAs with the prefix lifetime as 0, if I
implement this on a Linux router of some type, I can send RAs from a
link-local address that is no longer configured on the system, in
theory. I'm not entirely sure that's a good idea. Because there will be
no DAD for that address anymore as theoretically someone else could
claim that address. It's a theoretical concern. However, might still be
a good idea and maybe we should look at that, discuss that a little bit,
and come to agreement on that.

Jen: Looking forward to the discussion.

Lorenzo: The lifetime zero address isn't really a problem. You can send
a zero lifetime RA from any link-local address. And that will just
clobber the lifetime. That's how it works.

Jen: So use stable address which I'm suggesting, which is not tied to
any prefix and just stays.

Lorenzo: You can also use the new one if you only have one.

Jen: But if you know the prefix, I do not see the problem.

Lorenzo: I don't think it's mentioned in the draft, but this would make
it easier to support multi-prefix, multi-homing with one router , maybe
you should say that in draft.

Jen: I don't think it does.

Lorenzo: If you don't do it like this, it probably means you have to
withdraw the routes and so on. Probably quite difficult. So this would
make it easier, for every upstream you have, effectively you are making
a virtual router. You could try to cast it instead of being multi
local-link address, you could say virtual router, that's what kind of
vrrp says. But you've already written it. I think it's the same.
One thing I wanted to say though is that you're focusing on
reachability. But there are other options, what you're kind of trying to
do is trying to basically say: well you're not invalidating these old
options sent by this old thing that's no longer there, but you're not
preferring them anyway. So when there's renumbering event, the host will
say, that thing is technically still has a non-zero lifetime but it came
from someone who's not there anymore. And because I have to prefer the
new thing, I have to use the new router and the new source prefix. But
that doesn't extend to any other options like the DNS server or the
pref64(?), And that's kind of a nice hack, but we ought to say something
about that. e.g, if the previous link-local address router advertises a
DNS server that's off link, and then you sort of renumber, and now you
have the new link-local address, you still have to invalidate the old
DNS. Otherwise, hosts will keep using it or could keep using it.

Jen: It's a very good point but I think we kind of starting getting into
unchartered territory of what host needs to do in multi-home, all the
information you get from different routers. It's basically PvD. We
probably need to defin what host needs to do in general. Do we need to
tie DNS pref64 options to a router and invalidate all options when
router disappears or not. Maybe we do. But I think it's exactly what we
need to define for multi-homing, multi-router host behavior.
I agree, we have been focusing on address, but information about DNS and
other MTUs at the end of the day, which every router advertises, you
might be invalid if you switch to another router.

Lorenzo: This is kind of a nice hack which relies on stuff that is
already written in the RFCs when people implement the RFCs, it will
start working. But note this doesn't help you for DNS, and as Fernando's
draft, we basically have to invalidate the information of we know what
it is. So that's kind of okay. Doesn't help the roaming case.

Jen: I don't know if you require anywhere to map DNS information to
router advertising. Most likely no.

Lorenzo: Not written anywhere, no.

Jen: I suspect that it's even harder than rule 5.5 when you need to
remember which router advertise which prefix. And you might want to
remember which router advertises DNS pref64 and other stuff. That's why
in (who's?) draft in v6ops, which basically says if you start seeing
inconsistent information, it's like configuration error. And you do see
a lot 4 prefix and not 6/4 pairs. And that's it.

Lorenzo: It's all very ad hoc. What you should try to do maybe is see if
you can write this in terms of implicit PVds. You could say, it's now
like each link-local address is not implicit pvd. It might work better
from a text and readability perspective. Try to look at that.

Tom Hill: I have a wonderful use case that thing suits so very well. I
would be happy to see this adopted. One thing that we need to test in
the situation where you have a single router with a fixed line up link
and a mobile up link and you want to failover from one to the other, and
they've got different prefix delegations, we're going to have to test
the interaction between valid lifetimes to zero and preferred lifetimes
to zero. And figuring out the order in which when do you advertise a
zero, when do you remove the address in which order. Thinking about the
DNS resolver we'll have on that device, whether we use a separate
address for that, for example. So I think it's quite an interesting
idea.

Jen: That's why the draft has a section about stable address, e.g, if
you want to advertise the router as DNS resolver, you do not want to
change it all the time. That's why there's a section, you might have a
stable, proper, normal link-local address, doesn't change no matter what
prefixes. I agree. We shall talk about that.

Tom: That's going to be great. We can test that.

Philip: Quick note about the DNS bundling case. I feel we end up that we
have to do the same magic as rule 5.5 for DNS too, because we have DNS
views. We have a lot of weird setups with CDNs that might react quite
differently based on where the query comes from. So in the end, we end
up to do everything we will need the same as rule 5.5 also for DNS and
bundling to it the prefix.

Jen: Basically, we can converge on implicit PVD behavior.

Send/CGA for OMNI Links

https://datatracker.ietf.org/doc/html/draft-templin-6man-omni3
Speaker: Fred L. Templin, 5 min.

Éric :Do you want to make a SEND bis document updating the crypto in it?

Fred: I'm not authoritative enough to say RFC3971 can't be used as it is
with the different encryption alternatives. I don't know.

Éric: Strongly object about your last request, i.e, reinstate SEND in
IPv6 Node Requirements, we should not be back in IPv6 node requirement.
Cisco had the SEND code in iOS router and we had to remove it because
nobody was using it, I think it's a clear message.

Fred: We have a use case for it.

Éric: It does not prevent you to use SEND.

David Lamparter: Much of what Eric just said. I would like to ask for
actual implementation and operational experience. Do you have some setup
that is running with this using SEND? If yes, can you put together two
slides next time you present this on how that went and if there were any
experiences from that? And I also don't see why SEND would be in the
node requirements, just for specifically the fact that this mesh routing
setup wants or needs to use SEND, because the node requirements are for
everyone, and we are talking about a very specific use case here.

Timothy Winters: To echo about what Eric and David said. As author of
bis, we talked about this and don't think SEND should stay there just
for this use case. We've had enough runs at this. There's not enough
running existing code, so we think it should be removed.

Fred: So I'm not ready to publish code yet, but that's in the plans.
When we get to the point that we are publishing code, is that something
you would consider at that point?

Tim: No, we think this is a special use case, it's beyond node
requirements. We don't want general nodes implementing that. It's not a
message we want to send to people at this point.

Philip: Speaking as someone who is currently in the face of rolling out
a lot of IPv6 stuff internally, and we're feeling a lot of pain from
security recommendations that are outdated, old, and very hard to
implement. If we would add SEND again to the node requirements, this
would really, really hurt people who actually try to implement IPv6 now
because this security department would say, there's the secure
mechanism, please use it. And I then you end up in a very very bad
situation. So I strongly oppose reinstating SEND anywhere.

Fred: I don't think we're necessarily going to say that the SEND must be
implemented by IPv6 nodes. I think there's language that could be used
to say it's used for cases like the OMNI link. I don't think it's a MUST
that I'm asking for.

Tim: The issue is going to be things like the NIST, US Government
profile and other governments read node requirements very very
carefully. And if we don't remove this, somebody is going to say you
have to do this, and that is why we should take it out. It shouldn't be
there because that's what will 100% happen. Some profile or some other
documents will look at node requirements and say SEND has to be
implemented for security reasons, and we say people read, they don't.
That will end very poorly.

Fred: Not everything in the requirements is a must or even a should.

Tim: I agree, but I don't think we're couching this as a solution
anymore. I'm on the other side of this.

Bob: That's exactly what node requirements does, it's the requirements
for what should be in every node. So it's not the place to put optional
things.

Jen: How general is your node? Because node requirements is about
average IPv6 only node. If you have a special case when OMNI is used, I
do not think we need to add the burden of implementing it to every other
single node. There are other issues which are not in node requirement,
but they may be implemented by nodes which need them, that's fine. I'm
still not sure why you think every single node around needs to do this.
Are you going to take a random laptop, Android or iPhone, and make them
use this or not?

Fred: Not every node needs to implement OMNI, very few nodes do. But the
ones that do, really need to have this kind of mechanism.

Jen: Why can't you have OMNI node requirements in form of RFC or RFP you
give to a vendor. It looks to me like it's a separate set of
requirements. I don't even know what else OMNI requires. Maybe there are
some other additional protocol requirements which are not applicable to
random node.
Chair's hat on, feel like there have been a lot of arguments against
this. If you think it should be there, we definitely need to understand
better why.

Tobias Fiebig: If we put things into documents, it might be picked up by
other people, especially security stuff, it can be very hard to get rid
of them if we figure out they might not been the right thing to put in
there and that kind of requirements language at certain point of time.
Or if we are dealing with people who do not really understand BCP 14
which also sadly happens a lot for security people and policy makers, so
I would like to strengthen that point because we currently have same
issue with BCP 194(?).

If Time Allows

Deterministic Routing Header

https://datatracker.ietf.org/doc/html/draft-pb-6man-deterministic-crh
Speaker: Shaofu Peng, 5 min.

Zafar Ali: CRH is experimental. You're mentioning your draft being
standard track. It should be experimental. And also there is some
overlapping work in the source routing area for this problem space.

Shaofu: OK, will modify it.

Jen: Chair's hat on. When there is a problem and solution which belongs
to another group, and you're proposing some IPv6 modification to solve
it. We'd like to get feedback from detnet group or at least the chairs
to comfirm this is a problem worth solving. And then we'll be happy to
work on implementation details for the solution because I am not sure we
shall discuss the problem and the solution here because I'm not sure
whether it's necessary.

Problem Statement with Aggregate Header Limit

https://datatracker.ietf.org/doc/html/draft-liu-6man-aggregate-header-limit-proble

Speaker: Yao Liu, 5 min.

Éric: Nice idea. Your describe AHL as until the inner-most transport
header. Not all packets contain transport header. Sometimes it contains
frame or another IP packets so you need to change your wording there.
On the two first options for AHL collecting, I'm afraid if you send to a
third party the AHL, it allows network reconnaissance and maybe getting
some information about what kind of operating system are the nodes
there. I understand it's useful, but it's as well for bad actors maybe.
Their security consideration must be explained there.

Yao: Will refine the draft as suggested.

Extending ICMPv6 for SRv6-related Information Validation

https://datatracker.ietf.org/doc/html/draft-liu-6man-icmp-verification
Speaker: Yao Liu, 5 min.

Bob: Discussion should be on the list, but we would need to hear from
SPRING whether they would like us to pursue this.
Yao: Used to present in SPRING, the suggestion is to go to 6MAN.
Bob: But they have to tell us they think they need something like this.

Terminal Identity Authentication Based on Address Label

https://datatracker.ietf.org/doc/html/draft-guan-6man-ipv6-id-authentication

Speaker: Kexian Liu, 5 min.

(The presenter wasn't in the room nor on online on Meetecho)