**Session Date/Time:** 20 Jul 2026 14:30

[00:01:07] **Jen Linkova**: Okay. Good afternoon. Welcome to I p v six working group. Here on the screen, you can see Bob who could not be with us in person today. He prefers to be in Hawaii doing some sailing stuff. I think it's a good hint where is the next summer IETF should be next time. Alright? Okay. Here is our I p v six mascot, and I'm Jen. So, note well, please take a look at this. I am not going to read it to you because you should not suffer for too long from my accent. So slides are available. Please read it if you are not familiar with the context content. So, basically, what Note Well was saying is that you already agreed to follow IETF guidelines when you register, and we expect you to behave professional, be nice to each other, even if you disagree technically with what's being said. Some useful tips. First of all, if you are not on Meetecho already, please scan the QR code, which used to be on that screen. You can find in the entrance on the room, or you can just go to the agenda, find the on-site tool, and use it. First of all, you're going to need this if you join in the microphone queue. And secondly, I I suspect that that microphone might be turning off. Ah, thank you. Yes. As Kim pointed out, QR code is actually available on the microphone. So if you don't know where to find the QR code, it's there. And, yeah, when you join the microphone queue, please use the on-site tool and join the queue. It would help drastically so chairs could manage the queue. And secondly, the QR code scanning is actually replaced blue sheets for those who remember those things. People who are remote, please keep your microphone and audio video off unless you are presenting. And yes, please put your mobiles on silent mode. Okay. So, next. Yeah. Standard sync. I guess you already know how to get the Meetecho. You probably don't need the direct link because, yeah, you can get there from that agenda. I did ask for minutes taker, but then we decide I think we can just to give such a popular thing as AI another try and see how well it could take minutes for us. Because anywhere, right, you if you said something on the mic, you should check minutes minutes later to make sure it's been captured correctly. Yeah. We all should be using the most recent version of IP protocol and should not be using the legacy one anymore. And as far as I know, even Microsoft Windows devices might start using v six mostly. So, if you have a Windows laptop, please let me know how it goes. I'm very much curious. Agenda. So, we are going to we as chair is going to talk a bit about documents and how we operate. And and then we have three working group drafts to talk about. It's been a last minute shuffling of the order because David asked to be to present at the beginning of the session. And then we're going to have four individual drafts. By the way, the last two drafts, as you might see, look very similar to each other. That's why the last ten minutes, we probably might spend on discussing those drafts together. So, I'll remind you later about when those drafts are presented, I suggest you can ask clarifying questions about the draft specifically after the draft presented. And then, can talk about the differences and how they work together after both drafts have been presented. So, we've been doing? Are we making any progress? Well, we haven't published anything, but it looks like the famous cluster five to five has been unblocked. The story was we had a number of drafts which were waiting for a snack document. They got stuck in the normative references. It's been unblocked by moving a Snack Simple from normative to informative for array flag, which also unblocked 6724 and also another draft from v six ops. We have another draft sitting, again, waiting for reference in RFCQ. And another draft is for segment ID clarification, is waiting for RFC editors. There are two drafts waiting for write up. One of them is mine. By the way, I did If you are one of the authors of this draft, I mean, ipv6-neighbor-discovery-yang, I did send you two emails asking for some clarifications for write ups. So, please take a look if you have not seen my mail. So, we have one draft which is still in the working group last call, is SLAAC Renum. As far as I know as far as I can see, there is some discussion going on in the mailing list, so we do hope, fingers crossed, to make some progress on it. Zafar, you have questions about what I said?

[00:07:28] **Zafar Ali**: No. I wanted to mention the same thing. For the first half on this list, there are significant comments that are already addressed and concerns. So, there is some discussion going on with the authors, but, the convergence is not happening. And, they this like, there are certain things that they say that the working group agreed that we can do this, and I want to bring that topic up is is is what it what it means when the author said the working group agreed they can do what changes have been proposed, and how the chair would like to take that comment and and progress. Because as such, there are serious concern. This is something to be done in hardware, and the current encoding is is is is super complex and is not consistent with what discussion has happened. Also, went in the in the route which is not consistent with what discussion was happening. And there's also a 32 bit ID with the context that somebody can hijack and put something like application ID in it and all. So so that could be a bit concern for privacy and and and that point of view also. So I think we need to check is how because like, authors are willing to work with the comment, but they're also concerned what would the working group do if I would make that change at this stage. So, anyway.

[00:08:56] **Jen Linkova**: Okay, thank you. I know there is some discussion going on, yes, so we'll continue on this. Okay. So, what are the documents this working group is working on? So, we have three active documents which are presented today. However, there is a number of active documents which are not presented, and we have not seen recent updates. I'd just like to remind the authors that we'd like to hear what the plans are for those documents if the authors still have energy to work on them. However, we have three interesting documents. We have one document which is still active. It has not expired because it's been updated a couple of times recently, but those updates do not actually change the content of the document. Yes. And so, the first document is basically what I call dormant, right? So, no changes. Authors keep it active, but does not seem to be any actual work happening. And there are two documents which I expired but officially still belong to 6man. Yeah. I want to expire for nine years, 09/04/2016. So my proposal is that unless someone object to this, and please raise your objections before September 1, the date was chosen randomly, we are going to eliminate those documents from the six month working group. So, putting them back to individual documents and then because it looks to me, it looks to the chairs that nobody is actually willing to work on them, which means the status as working group document is not actually correct. If someone is willing to pick that work up, we can always go through call to adoption again and do this. So, yeah, Tim, are you joining the queue?

[00:11:07] **Tim Chown**: Yes. Sorry, Tim Chang. Yes. I'm trying to. My question was whether you can very quickly summarize what the point of the 4291bis was. Was there must have been a reason for it. Has that completely gone away, presumably, since it's been dead for nine years?

[00:11:21] **Jen Linkova**: I I don't remember what happened yesterday. You just asked me what happened nine years ago. You are interested, we can yeah. I I should have prepared short summary, I will like, probably Bob remembers something.

[00:11:36] **Bob Hinden**: Yeah. But

[00:11:36] **Jen Linkova**: I like will make

[00:11:40] **Bob Hinden**: what what I at least I remember is can you hear me okay?

[00:11:44] **Jen Linkova**: Yes.

[00:11:45] **Bob Hinden**: Good. What I remember is that the working group completed it and advanced to the IESG, but there was, comments on in the IETF call about how prefixes were represented and, you know, who should do that and so forth. And it was it was essentially, couldn't reach ITF consensus. So it sort of stopped. There were a lot of other, I think, good changes in that document, but it doesn't seem to yeah. I'm I'm not sure that the thing that caused it to be blocked would change.

[00:12:30] **Jen Linkova**: Georgia?

[00:12:31] **Jordi Palet Martinez**: Maybe for each of these documents before doing the the September 1 thing, you should send for each of them, not not one for all, a message to the list asking if some other people want to take over, and if possible, what were the issues like what just Bob mentioned. So we can take a a more, let's say, informed decision about what to do, which is document.

[00:13:00] **Jen Linkova**: Okay. Yeah. Why I do not see the queue on my screen?

[00:13:10] **Bob Hinden**: Ron is next.

[00:13:11] **Jen Linkova**: Ron. Ron. I'm the queue. I found the queue.

[00:13:16] **Ron Bonica**: Ron Bonica, HP. Quick question about the reflection draft that's sitting in a missing reference state with the RFC editor. The missing reference is to RFC 33, 8335 BIS. That document appears to be stalled. Would it be okay if the authors of reflection referenced RFC 8335, made whatever changes we need to make to make the reference work and push it out of RFC editor queue.

[00:13:45] **Jen Linkova**: I see. Like, I I just do not remember. Do you does your draft need anything from the biz or just a three three five? I just don't remember what kind of normative reference is there.

[00:13:55] **Ron Bonica**: There is one paragraph about something that BIS clears up that the draft could do perfectly well without.

[00:14:04] **Jen Linkova**: I can see responsible AD coming to the mic.

[00:14:10] **Eric Vyncke**: Hi. Eric Vyncke, responsible AD, both for this and for the RFC 8335 bis, which is in, if not mistaken. Right? The BIS document is waiting for revised ID for two hundred days or something like that, so should be addressable. Now I remember somehow I don't know whether you check run today or whatever, but I remember that the the BIS was useful for this document. From I I I did not prepare anything. Right? So that's yeah. But I would prefer to apply pressure from the six man document to the interior document so they can move forward. Right? Because then you actually need tooth plates out of my chairs.

[00:14:53] **Jen Linkova**: Okay, Ron. I think we can talk offline, but I suspect we both know who the authors of the bees are. So, maybe the authors could do something.

[00:15:04] **Ron Bonica**: I confess.

[00:15:08] **Jen Linkova**: Okay. Yeah. Important thing. Just a reminder, we show this slide every time. IPv6 is very important. A lot of other technologies from other working groups are using it. So, every time another technology requires some changes in IPv6 protocol, such as, oh, I need a new option or I need a new bit somewhere, right, we kind of have not a problem, but interesting situation when the draft coming to six men might be actually proposing something to solve a problem which is in the charter of another working group. And as a result of it, sometimes the discussion around the draft might be not about what is this option like, is the proposed option format or bit as a correct approach, but about the problem statement and if the solution proposed is the correct one. And sometimes, this working group might not be the best place to have this discussion. So, as a result, to save working group time and energy, we are trying to apply the following logic. If the the certain draft requires changes in IPv6 protocol, we first would like the original working group or at least the chairs to to tell us that the working group considers this problem worth solving and solution being correct. So, normally, it means another working group needs to adopt the draft, right? And then, after that working group decides on how to solve the problem, we can implement the required protocol changes. It happens quite a lot in sprint, obviously, right, because SRv6 needs some changes in v six, but I do see it in cases of other working groups as well. And it's not like we do not like to take work in in six man. It just we'd like to make sure the solution itself is discussed by the people who have context and have expertise and interested in what is being discussed. Eric.

[00:17:22] **Eric Vyncke**: Why this noise when I come to the mic?

[00:17:25] **Jen Linkova**: Oh, I'm happy.

[00:17:27] **Eric Vyncke**: Ah, okay. Anyway, Tim Winter is there. Right? So that's exactly what we are doing in the working group. We they are pushing basically all the definition and the semantics of an option into the other working group. And then the issue is not even consulted or, basically, we extend the working group passcode. You may want to say a few more words, Tim, if you want.

[00:17:52] **Bob Hinden**: Yeah. I mean, that's that's how the group has basically run for the last, I wanna say, five years is that we let other working groups do the actual work, and then they run it by us. It makes more sense because the options you know, in our case, they're pretty well defined. I think six man I think there are places where things are very well defined, and I think those are fine to do, but obviously, there are some spots where things are not so well defined, and that's where we end up in trouble.

[00:18:15] **Jen Linkova**: Yeah. We will mostly put on this slide because we do receive a lot of agenda requests from other about the drafts, which are not even adopted, and sometimes that other working groups are not even fully aware of the proposed solution and even about the problem itself. Right? And I see that sometimes we do not want to waste too much of the working group time here yet.

[00:18:38] **Ted Lemon**: Ted Lemon, so just to clarify, does this mean that if we were to do something similar to the router advertisement the SNAC router advertisement flag again, we probably would not do it as a six man working group document?

[00:18:49] **Jen Linkova**: No. We can do it a similar way to do we did it with a ray flag, but with a ray flag, as a good example, it was already a SNAC document being adopted. So, SNAC group already decided we want to do this, and you came to us with just a very short one page draft saying, we need a we need a bit, and we already know we need it. So, please define that bit for us. We happily did that. Right? So, easy.

[00:19:15] **Bob Hinden**: Just checking.

[00:19:16] **Jen Linkova**: But we did not we did not need to discuss how exactly this flag is going to be used, is it the right thing to do, and so on. It's all been uploaded to snack is what I'm trying to say. Sorry if I wasn't clear.

[00:19:28] **Ted Lemon**: No worries. We may have another one coming. That's why I

[00:19:30] **Jen Linkova**: asked. Okay.

[00:19:33] **Ron Bonica**: DNSSD this time.

[00:19:35] **Bob Hinden**: And, Jen, you you might wanna talk about the the request we got from, what was it, Savi, where the it was basically a protocol draft, but the work the savvy working group had not is not at the point where they were looking for technical solutions yet as I understood it.

[00:19:54] **Jen Linkova**: Yeah. There was another example here when a certain drafts came talking about the ICMP changes to solve a problem while the whole working group is still in the architecture phase and problem state no problem statement phase, not even architecture phase.

[00:20:10] **David Lamparter**: Right.

[00:20:10] **Jen Linkova**: So they were like few steps behind, so it was definitely too early to discuss the solution and just another example. Yeah. Okay. And Just

[00:20:24] **Joel Halpern**: to close the loop on that last bit as the Savnet co chair. Yeah. Savnet was the working group. Savnet working group is very carefully tiered in how it is supposed to work on things. There is no way we are going to be agreeing on solutions approaches even at this stage of the effort. So taking up six man time on evaluating a solution is distinctly premature, and we very much appreciate your checking with us on that. Thank you.

[00:20:51] **Jen Linkova**: Great. Thank you for that comment. And I think this is the last chair slide, so we can now finally go to talk about actual drafts. So, David, it normally takes a while for me. You have preferences on which one you talk

[00:21:10] **Tim Chown**: first? First.

[00:21:13] **Jen Linkova**: Okay. Eleven one first. You want clicker, I can do it voice control.

[00:21:19] **Lorenzo Colitti**: I can do it.

[00:21:20] **Jen Linkova**: Okay. Because this takes longer, and now I need to do a few more clicks. What do want?

[00:21:26] **David Lamparter**: Hi. I'm, and we're here to talk about 80211 and F p v six again. Let's do a quick status update first in case you've looked at this before. I did the main change that has happened since before was that I've tried to figure out where this would need to go if it were to go forward. The we don't really have a liaison to the Wi Fi lines. We don't have one to eight to two eleven either, but this can be figured out. I know roughly what direction I would need to take this in. I did get some feedback where now I'm I wanna be sure what exactly I'm carrying somewhere before I go start that, so let's maybe try to figure that out first. This is a Groundhog Day thing. Definitely, we've we've discussed this before. We are talking about I p v six doing RAs on multicast and that then being multicast on Wi Fi on layer two. If you lose enough of those, you lose I p v six, and then, yeah, you don't have I p v six. Some devices, they just decided I p v six doesn't work, they don't don't even try anymore. Sometimes it's intermittent. We've discussed this multiple times before. You can see the list here on drafts and, actually one RFC that talked about this before. Right. Why is this a problem? It's a problem because power is expensive, and it's too much to be waking up every point one second. Point one second is the default beacon interval. You don't get multicast every beacon. There's a multiplier for that, and that multiplier is configured in the AP. The client can't do anything about it. It it's it needs to live with what it's given unless you have either FMS or DMS. So those are two things in 802.11. I'll get to that a bit later. In the previous attempts that we've taken here at looking at this, neither FMS nor DMS have received a lot of attention. That's the main reason I brought it this time. All in all, this is a is summarized all into numbers. Five is what apparently most WiFi chipsets have decided is acceptable as a minimum multiplier to wake up at. That's multiplied by point one second, so that's point five seconds. If you have a multiplier that is lower, I. E. More frequent, DTIM messages on your beacons, the chipset, not even the host, the chipset decides that that's too much power, and it will just sleep through those beacons and not get the multicast traffic. It's a little hard to figure this number out. The way to get that number is basically you buy devices and you see how they behave in the real world. This is not really documented anywhere. The other number here is two, which is the default value in both OpenWRT and host APD. Host APD matters a lot because any cheap AP is just host APD. And, obviously, two is less than five. So in this combination, you lose two thirds of multicast traffic. You can't do five if the multiplier is two. You need to do six in that case because you can't do the like, you can't do an an an odd interval. But this is the problem in a nutshell. We we lose two thirds of I p v of of of layer two WiFi multicast, which if I p v six arrays are transported over that, that's two thirds of arrays. First thing, yeah, we can absolutely try to change those numbers. I've contacted the OpenWrt people. I will try to get that done. I believe it's been tried before. For host APD, I know people have tried, doing that. Host AP is hard to get things into. I have not tried that one. I'm I probably won't try that one because that's not a field that I really do stuff in. Either way, I don't think the numbers are the real problem here. It's we need to specify something in a way that is guaranteed to work. I I don't think we can be relying on things to be configured correctly by someone somewhere, which may or may not happen. And also we've tried this. We've documented this before that this needs to work and you may need to configure things in a certain way and I it doesn't seem to be working, otherwise I wouldn't be standing here. I don't think it's a valid argument either to say that it's fine on enterprise WiFi. I'm well aware that wireless controllers do all kinds of things with, arrays or just neighbor discovery in general, so you will not see these problems on your corporate Wi Fi. The wireless controller does all kinds of magic. It will generally convert things to unicast, for example, and that's that's the the solution done by people who know what they're doing. They know that because they have the knowledge, but we should have things in specifications that documents these things, not just rely on things being carried around. The 802.11 side has two things in the specification that are relevant to this. There is FMS and DMS. FMS was specifically designed for this issue. It allows a station to request that multicast traffic is delivered less frequently, so you have to wake up less often. Like, you pick an interval, you can say five instead of two, for example, and then the AP buffers the multicast packets and then sends them out at that agreed upon, less frequent interval. It's a negotiation. The AP needs to have the same number for everybody that is associated on the AP, so it needs to match for all the clients. But as far as I understand, the protocol would work if only it were implemented. It was specifically designed to address this. Question right now or

[00:27:23] **Lorenzo Colitti**: clarification. So if if an if a number is decided and a new client arrives and asks for something different, what happens? Nothing?

[00:27:30] **David Lamparter**: So either the AP decides to change the number for everybody, and then it needs to notify everybody. I think there's a part in the protocol where the AP can push a new value to all to every to all the associated to all the stations that are on the FMS stream for the one thing. I would need to check the details. I would assume 802.11 knows how to specify a protocol, and they took care of this. There there's gotta be something for that. DMS is kind of a cousin of the same thing in it has a lot of the same protocol elements, but instead of changing the multicast, interval, it allows the client or station to explicitly request some traffic to be converted to unicast, which is already the AP can do that by itself, but this allows the client to ask for it and receive the agreement from the AP that this is happening without just assuming that it might happen automatically. And that very so the end result of that behavior is already common in enterprise Wi Fi. A lot of, multicast, like, or two multicast is converted to unicast, by the AP or by the controller on its own logic without the client being involved with that. But then the client doesn't know the fa that, and in theory, the client in that case still needs to do the normal wake ups. It's just that if this is in use, doing that is less bad because it's also unicast conversion going on so you don't lose the packets. This is in the well, software is maybe not quite right. This is between software and firmware. Needs to be implemented on both the AP and the station. It will definitely take years take years to get this shipped if if this were declared mandatory or whatever else right now. So this is not an immediate fix either. In theory, we can change IPv6. We can set more RAs. We can send RSs. We can do IPv8. We can have an AI figure out the solution. I I don't disagree. I don't agree with these. That's a separate question. I do think we should maybe try multiple things at at the same time here and just see which one actually works at the end. The main thing here is it's still broken. I We haven't tried the the 802.11 side yet. I don't know which of the two is the better thing to do here. Maybe DMS is better, maybe FMS is better, maybe both, maybe neither, maybe both of these are stupid ideas. Either way, 802.11 and or the Wi Fi lines would need to do something about that, And this document is, at the end of the day, intended to just go there, be a liaison statement to the WiFi lines and or 80211, tell them this is a problem. I had tried to put this more like, hello, we have a problem and not like, hello, we want this specific solution. The people who know the most about this are there and not here, I would say. And that's it on this document. Questions?

[00:30:50] **Bob Hinden**: Who's Jerome?

[00:30:54] **David Lamparter**: I'm here.

[00:30:57] **Jerome Henry**: On the screen. Yes. Hi. I'm Jerome from from Cisco. Thanks a lot. I mean, this is interesting presentation. And can can you hear me okay? I I see you're trying to yeah. Can you hear me okay? Yeah. Okay. Perfect. You know, a lot of, you know, thoughts come to my mind when when I when I see see this contribution. First, you know, I Tripoli designed standards. Right? So FMS is in the standard. DMS is in the standard. So, you know, if you go tell them, hey. We have a problem. And as you say, if we tell them, hey. Maybe we should do DMS or FMS, they'll tell you, well, it's there. Just just tell people to use it. You know, we're not meditating any implementation behavior. So I'm wondering if I triple e is the right direction. The Wi Fi Alliance, of course, they have certification programs as you know where, you know, group of companies get together and say, these features together will make an interesting combo that will call voice enterprise management, QoS, you know, Wi Fi six, whatever. The thing is that FMS, you know, is a very bad protocol. You know, remember, it was designed in 2008. That was Wi Fi five, a two two dot 11 n. Back then, you had, like, 10 stations per AP. And so as you say, you know, the question was brought by Lorenzo as well. As soon as multiple stations come in and out and start to negotiate stuff, you have a bunch of overhead that starts appearing because everybody's going to be negotiating something different. So it's gonna be a bit a bit messy. Essentially, it's because, as you know, as you say, multicast is not good on shared mediums. So that's the fundamental problem. DMS may be interesting, but, you know, it's already in the Wi Fi Alliance certification. It's in the power safe certification. So it's already there. So people who want to implement that feature can implement DMS, and they don't, which is, you know, where where I wanted to go, which is, you know, my my thinking that I actually might not be the right place, Wi Fi Alliance might be, but because it's a combination of companies more than the sort of the from the IETf, what would be more useful is, you know, some, you know, captures or numbers that show that there is actually a problem because what you seem to be scrubbing seem to be what station vendors are implementing. So it seems to be that the issue would be to do something there more than implementing your general protocol that the APs should do. So, you know, it seems that, you know, having more more data and going to, you know, enterprises that are in the Wi Fi lines might be an interesting approach to actually raise the the issue more more than the DSM? Just just a just a thought.

[00:33:34] **David Lamparter**: Right. I think I understood most of that. I so I can tell you even so DMS and FMS are both not implemented in host APD, so the cheap APs are not going to have it regardless of, like I don't know which part of the Wi Fi line certifications includes this. I think you said that, but I didn't understand it. If if we can get somehow to get this implemented, that's what I'm trying to get to somehow. I will also say that this behavior that the chipsets do to sleep through the DTM intervals, I don't think this is specification compliant. Like, I think It is. It is? Like, just randomly lose

[00:34:20] **Jerome Henry**: They have absolutely the right to decide. Absolutely. Yes. Yes.

[00:34:24] **David Lamparter**: Okay. If you can send me a a point or something on that, like

[00:34:28] **Jerome Henry**: 3Point266 in the standard. I can send you that number. Yeah. 3266 specifies it specifically. Yeah.

[00:34:34] **Bob Hinden**: Yeah. Okay. Cool. Thank you.

[00:34:39] **Lorenzo Colitti**: I'm Alright. Writing down 3266. I'll go look it up. So, yeah, I do I do agree with the sentiment here. I think the other thing one thing to keep in mind, of course, is it will take a long time. I guess one I I do I do think that FMS is is just seems really clunky and having, you know yeah. But DMS might be a good idea. And if we could you know, it's possible that device manufacturers could get at least could try to lean on their chipset device vendors to at least request it. And then at least there would be some some amount of demand. Do you happen to know if DMS allows buffering for hundreds of milliseconds? Because that's what you need here.

[00:35:24] **David Lamparter**: I don't know how long the buffers are if you enable it. I think it just gets treated as normal Unicast traffic and whatever like, however however much you keep for that would also apply

[00:35:35] **Lorenzo Colitti**: to wake up in hundred milliseconds anyway for it to receive unicast. I mean, of course, it's faster because, like, the the rate is higher and but I think my point is if it doesn't end up saving battery, then you we'd still have a problem. Right? Mhmm. So I think

[00:35:48] **David Lamparter**: that's worth looking. I wish I could test it, but I don't have an implementation that I can

[00:35:52] **Bob Hinden**: test. Yeah.

[00:35:54] **Lorenzo Colitti**: And I I do read, like, you know, going to to to Wi Fi Alliance saying we have a problem is better, but I think Wi Fi Alliance just does a certification, so they won't know the answer. Eight zero two to 11 might be the better people actually to ask because they would tell you, we designed it for this purpose and it has these properties. But then we'd have to go to the Wi Fi Alliance to make it sort of request required.

[00:36:17] **David Lamparter**: Yeah. It is kind of in the middle or both. We do have

[00:36:22] **Lorenzo Colitti**: a laser meter too. We we should probably say, look. You know, please recommend the technology for this purpose.

[00:36:27] **Zafar Ali**: Yeah. That

[00:36:32] **Eric Vyncke**: So you said that host APD effectively blocks the implementation for all these smaller access points. Right? And it's hard to get things in the host APD. And do we think it's easier to go this route versus trying to convince them that they're breaking the entire industry? I

[00:36:55] **David Lamparter**: don't know how to really an so I don't know that much about the host AP project as a whole. I have the outside observation that things do get implemented, but it takes time, and it's hard to influence from the outside. Like, if you send a patch, it's not guaranteed that anything much happens to it. But, I mean, I I also don't wanna like, this is mostly one person, still who con who's controlling the project. They do seem to be doing a pretty good job in terms of host AP does support a lot of things. This is just one of the thing the few things that aren't there. Yeah.

[00:37:34] **Eric Vyncke**: It's keeping them being evil, but more because the problem itself is between layer two and layer three, and it's kind of tricky problem because in in my experience, it it's kind of hard to understand what the problem is pretty often because if you're focused on one layer, you you're not looking at the other layer. So maybe maybe maybe that's that's something.

[00:37:53] **David Lamparter**: So for the clients so the host AP project also has the client side. And And for that, it's purely in the supplicant as far as I understand it. So there there is no firmware or even kernel change involved, I think. Like, take this with a grain of salt. For the AP side, you probably need some firmware interface or something that doesn't that might not currently exist because if if like, the firmware needs to know to do that particular thing with the multicast frame, but I would also suspect that it should already be there. I this is in in the level of detail that I just don't have, unfortunately.

[00:38:31] **Eric Vyncke**: So allow me to join the queue even after, Eric Vyncke. Just to augment what the other Eric just said, there is a official liaison between IEEE and IATf. There is even a call two, three weeks before every IATf meeting where we track about 30 or 40 specific issue. I will add your draft to the list. But as my colleague, Jerome Murray, said, it's not really an actually pretty issue. I think it's a Wi Alliance. But Wi Fi Alliance was quite active here for other project, mostly linked to identity. So they know we exist and so on. But I think getting numbers could be very useful. Yep.

[00:39:10] **David Lamparter**: I will try my best.

[00:39:11] **Jen Linkova**: Okay. Yeah. We are

[00:39:16] **David Lamparter**: How are we time wise?

[00:39:18] **Jen Linkova**: Not very well, but I'll we have

[00:39:21] **David Lamparter**: some spare. The timer is not there.

[00:39:23] **Jen Linkova**: Yes. Correct. Cool. Hold on. I'll give you slight control for.

[00:39:27] **David Lamparter**: K. More multicast. Yay. I'm still. Let's, again, first do a quick status summary. If you've looked at this before, you can just zone out. Content wise, it hasn't really changed. Mostly, I've been trying to figure out with AYANA what the actual update is to the multicast address space registry, for this draft. It's a little bit tricky because for multicast addresses, there's this variable scope thing where addresses can be, l well, allocated, assigned for all of the scopes, then it gets imported, and that makes things a little bit nontrivial in the IANA, operations of the whole registry. It's still open what to do with MLD for this. Why this is a question. If you haven't looked at this yet, then this will make sense later. This will also be presented in PIM on, Wednesday, I believe. And yeah. Actual content of this, there are some layer two multicast groups that have specific behavior specified by the layer two technology. I care about ethernet. That's what this is designed for essentially. The three relevant groups are listed here. They just propagate less than normal broadcast on Ethernet. Eight zero two one q is what defines those. I wish I could give you the page number for the current version. I could not download that one. I saw there's page number one ninety two in the previous version of the draft, and those I would like to expose. There's been multiple ITF documents that were heading in the direction of using LDP for discovery and establishing neighbors and that have kind of triggered this because the point of LDP or the normally, the benefit of LDP is that it does not traverse a switch. Like, you basically, you stay on the cable, and that you can use that both as a security property as well as if you have a VXLAN or some overlay network. It can be quite useful, to have the discovery not go into the actual overlay network. You could look at these three documents. I'm not sure what the status is. I think, yeah, I'm I'm not sure if all of them are progressing, but it doesn't really matter. Short version, there is I p v six multicast address ranges that have a mapping defined that makes them use these already existing, layer two multicast groups, so you can use them for I p v six. These three are the ones that I'm expecting to be useful. Specifically, the bottom one is the one that is really relevant here. The slightly longer version of the entire thing is how this works. We defined in r c twenty four sixty four. You probably saw the thirty three thirty three prefix at some point looking at some p caps or wireshark output or something. That's how normally a IPv6 multicast address gets mapped to some layer two ethernet multicast group. It's really just the last four bytes that get copied over into the multicast address for ethernet. And this has only received one update ever, which was to allow also putting it in unicast, which actually relates to our previous discussion. So this is right. So this takes, a currently reserved combination of, bits in the first part of the multicast address, f f two two, that co like, the combination of those flag bits currently makes no sense. And it defines that these, this range is used to map to something that is specific to the lower layer, and then there is a new registry for the lower layer technology. There's only one item right now. This draft is only documenting behavior for Ethernet. But a different technology at some point might want to expose something that that technology already has, and, that would be a different item in that registry, and it would have different groups with different behavior. The mapping rule that goes with this for Ethernet is quite simple. The whole o one eighty c two range is exposed. I didn't feel the need to make this more specific or anything, and this seems perfectly fine, but technical details. By by logic, more or less, the scope that the packets to a group like this go out on can only ever be less than the link scope that I p v six has because if if the scope were somehow greater, that would be the link scope. Again, like, it it doesn't make sense for this to somehow be larger. That's also why this document is called sub link scope. Also, this is existing behavior. This is not specifying somehow new, multicast behavior for Ethernet or anything like that. And I also want to point out, because I've gotten that feedback, these three groups specifically are not specified for use with this this some Ethernet bridge whatever protocol. They are specified in terms of their behavior in 802.1Q. That is not the case for some of the other groups in that same table, but these three ones that I've pointed at and that are mentioned in the document are, in a general sense, defined in 802.1Q. I think this also, explains what, how this relates to I triple e activity. This is just defining a way to make use of an existing feature. I do think this still needs to also go to liaison just to in this case, I hope this is mostly to make them aware and allow them to just, you know, provide input if necessary, but this is, I think, much less involved. Famous last words. It's As an idea, this is trivial. It is 31 lines of code in the Linux journal. I will actually demonstrate this today at the hack- hackathon happy demo whatever hour, which is in two hours or something. It works. If you are more interested in the why of this, you can pull up the one twenty four presentation, or you can just ask me. And, I think that's it for this document. Questions?

[00:46:19] **Jen Linkova**: Okay. Wow. Thanks. So, okay. Hold on. Many raise your hand if you have read the document. Oh, okay. Okay. Three. So, a few people are aware. I would really like to get the chairs would really like to get more reviewers and feedback on this. Yeah. We obviously can just go for the last call, and then people will start start reading it. Right? So, yeah, okay. We'll take it offline on what the next trip is, but my impression is it's actually in rather good shape currently. Right?

[00:46:54] **David Lamparter**: It is relatively simple. I I do think if anything, the question is if there's enough interest. If there's not enough interest, then

[00:47:00] **Jen Linkova**: It's supposed to be we have we have we have adopted it. So I clearly remember this group expressing the support and the interest for this document. Maybe those people are not in the room or they're just too busy with reading emails. But thank you, David. We'll continue working on it. Thanks. So It

[00:47:17] **Bob Hinden**: sounds to me like it may be time to do a working group last call and find out.

[00:47:22] **Jen Linkova**: Yeah. Okay. So next presentation is note requirements. I'm trying to get the slides. Yeah. Click. Click. Okay. Yes.

[00:47:45] **Bob Hinden**: Hi, everybody. I'm here to talk about node requirements with my coauthors, Tim, who's in the room, and John, who couldn't be here. But we have an update for you guys. So I'm gonna start with this extension headers. I love talking about extension headers. So so, originally, eighty five zero four had text. It looks very much like this, and by very much, it's this exact text. So I'm gonna show two slides about this really quickly. Deal here is we tried to update it when we did the first biz version of this draft, and we tried to say, hey. There'll be new RFCs. We had limits. For those who have been tracking this, limits did not go through. It ended up being it's a dead draft now. So we thought the best thing to do at this point for the working group was to go back to the text that was in eighty five zero four. So here it is. So in full disclosure, we've it's the same text. I think people should see it because the deal here is if there's been any changes since the last time we printed this, people should take a look at it. I will say this is very much guardrails. There's a lot of shoulds here. I don't think there's anything we're not forcing anything new. This is the text that's been around for, you know, multiple extension headers. Yeah. Here's the next. This is all one paragraph in the document. And so o three o two does not have this. O three does, and it was just a copy and paste. So this is really you know, I don't expect people to read this right now and have comments on it. This is really everyone go read this text and make sure you're still cool with it. If you have any comments, you know, we'll take them. But at this point, it's just a I thought I wanted to point it out to make sure that everyone knows, yeah, we're switching this back to what it was before. No changes at the moment. Okay. So other changes we made in o three.

[00:49:39] **Zafar Ali**: And by

[00:49:39] **Bob Hinden**: the way, so Ron Ron, did you have a qualifying question on this?

[00:49:43] **Bob Hinden**: Yeah. Please. If you could go back to the last slide.

[00:49:50] **Ron Bonica**: Yeah. A host may was no. I thought I just saw a paragraph on a host may disallow unknown, options.

[00:50:02] **Bob Hinden**: Yep. You did. Okay.

[00:50:05] **Ron Bonica**: Isn't that a change to 8200?

[00:50:09] **Bob Hinden**: Oh, boy. So I do not think this is a change to 8200, but like I said, this is how this has always been written.

[00:50:18] **Ron Bonica**: So you could explain why it's not a change to 8,200.

[00:50:22] **Bob Hinden**: Well, so it's a good question. This has been an open thing that we've we've we've we've won around this a little bit in the past. Right now, eighty two hundred and eighty five zero four, they're supposed to work together. I Ron, this is a great question. I have to go back and look at the remind remind myself what we did with this one. It says a host may disallow unknown options in destination or hop by hop options in particular.

[00:50:49] **Ron Bonica**: Yeah. Disallowed, I mean, means discard the packet. Is that what it means?

[00:50:53] **Bob Hinden**: It means to be configured to do that. Yes. I would Yeah. That's how I would take that.

[00:50:58] **Ron Bonica**: And if that's the case, we have to think about backwards compatibility for an implementation that was written the day after 8200 was written

[00:51:06] **Bob Hinden**: Right.

[00:51:06] **Ron Bonica**: Before '85.

[00:51:07] **Bob Hinden**: Right. The next sentence has sort of always been our get out. Right? This should be configurable where the default is to accept unknown options, but a host to protect itself might decide that those things are evil and should be shot.

[00:51:18] **Ron Bonica**: To me, that means that you can configurably violate 8,200.

[00:51:23] **Bob Hinden**: Well, I mean, you could configure a lot of things to violate 8,200. Right? I mean, go nuts. Like, I hear what you're saying. I we've had this text for a while. I think you're it's an interesting point. But, yeah, I mean, this is what we've had.

[00:51:36] **Ron Bonica**: I think we agree on the facts. We disagree on the

[00:51:39] **Bob Hinden**: Yes. Oh. I think politics of it. I will say we've drifted into a gray area. I will admit that for sure.

[00:51:46] **Tim Chown**: Yeah. Tim Chan is is co author of this. So the reason this text has come back because of what happened with the age limits. This text has been there in eighty five zero four since 2019. It's been around for quite some time and agreed by the record group and after 8200 was published, therefore, eighty five zero four. And this text is all about protecting the end host, the receiving host, not what happens with forwarding on the path or the sort of things that Brian's draft and other draft speak about. And the default is here to process them as per f 200. So it's an additional protection. Yes. I get what you're saying that it's but it's it's there as a protection. That's that's the point.

[00:52:27] **Ron Bonica**: Is there a problem with contradicting a document of hire

[00:52:33] **Bob Hinden**: status? So I I'll say this. Right? When we went through this the first go around, right, 82 was already prayed when we did 80 05/2004. So it wasn't caught then. That doesn't mean it's not wrong. I think we can talk about this. I don't think the intention was to change what 8200 says here. We're we're just giving host a way that they might configure themselves to not all to protect themselves from extension headers was my memory of this. So I I hear you know, if you could, Ron, send me a note on 6man so I don't forget this, and I'll I'll log a story for this, and we can talk about I don't have super strong feelings about this, and maybe this is one of those things that's changed since we printed this. Yeah. I was thinking the same thing, Tim. That this paragraph might disappear. It might be what happens, but send me a note, and we'll talk talk it through. Hold

[00:53:20] **Jen Linkova**: on. Question. So we're explicitly talking about host here, not mode?

[00:53:25] **Bob Hinden**: Yes. This is very explicit. Most of these protections are for the end of device, not for forwarding. That's a that's a good distinction to make. Okay. Any other things on extension headers before I move on? I love extension headers. Alright. Justin. Oh, okay. This will be fun.

[00:53:49] **Justin Iurman**: Yeah. Justin Yaron, six wind.

[00:53:51] **Joel Halpern**: I think

[00:53:52] **Justin Iurman**: we could just borrow this paragraph and put it in the extension of the occurrence draft because we are updating 8,200.

[00:53:59] **Bob Hinden**: Right.

[00:54:00] **Justin Iurman**: That would simplify things. Right? I guess.

[00:54:02] **Bob Hinden**: Yeah. Know, that was one of the things, obviously, it we'll get to the end of I'll cut to the end of the spoiler alert here is we're gonna say we're ready for working group last call at the end of this. And so that's where I think your draft's gonna be behind us. So I think that, yeah, I think it's a good starting spot. I'll say that. I think this text is good starting spot for that discussion for sure. Okay. Okay. We got some easy I got some layups here. So this is PMTUD. We added some stuff before. Gory, I think, was the one who reviewed this and said, hey. You should be a little more explicit. So we are now. I don't think this is earth shattering anyone in the room. We'll just say, hey. Go go read these RFCs. This is actually what we mean by those things. So I think it's minor, but we did make the change. Alright. This was an oops, and this has been here for a while. So we have some ECN stuff. We didn't have diff serve in the doc, so we put diff serve in there. I don't think this is anything major, but this should have been added probably if we added ECN. So it's there now. That's the text we added. Alright. Keep going. Good. Okay. Perf-six-four in router advertisements. Okay. So we had seventy fifty. I have some more questions about seventy fifty later. This was the text we used to have for this. We've updated it to say, may support this, and Lorenzo's gonna get up.

[00:55:36] **Lorenzo Colitti**: Is it there some other document that says should not do $70.50 somewhere?

[00:55:40] **Bob Hinden**: So we I was telling Tim before this. We we've been around this mulberry bush a bunch of times with what to do with the seventy fifty text. I think later, I reference a different RFC, and I'll I'll jump to that, the newer one, the one from the last one. The last one about this topic, I think, might just be the move here for us to say this is the latest information that says go to a 87, 81. The thing I think when we originally wrote this text was for the local synthesis part of this, but I'm I'll defer to others on this topic is where I'm at with this.

[00:56:14] **Lorenzo Colitti**: Def definitely, we must at least remove the should. Okay. Definitely remove it.

[00:56:18] **Zafar Ali**: We we definitely took

[00:56:19] **Bob Hinden**: out the should for sure. We took out should and said, hey. Do eighty seven eighty one, and they may do it. I'm guessing the may is for older implementations that need this.

[00:56:28] **Lorenzo Colitti**: But So there's a variety of things. We must remove the should. Then we could say we can say nothing about seventy fifty, or we can say may support seventy fifty or say should not support seventy fifty.

[00:56:38] **Jordi Palet Martinez**: Well But at least

[00:56:39] **Lorenzo Colitti**: removing the should for seventy fifty, yeah, we should.

[00:56:41] **Bob Hinden**: Yeah. I I I'd be okay going silent on July if the working group's cool with that, but it's not clear to me the working group's cool with that. So yeah.

[00:56:51] **Eric Vyncke**: We don't do him anymore. Eric Vynckee. Just heads up and a warning. Uppercase should is BCP 14. Yeah. It's for inter operation. And when you write a should, there's a clear guidance that you need to explain. If you don't do the should, what will be the consequence? So, basically Yeah. Really think a lot, why not using a must? You can use a must unless.

[00:57:16] **Bob Hinden**: Yeah. So the text above has a little bit of that, Eric, but I'm I'm in agreement with you here. This is one I think we could probably write a little bit more about why it's a should, but the I didn't include the paragraph above this. There's a paragraph above this that talks a little bit about why you would wanna do this.

[00:57:29] **Eric Vyncke**: And this one should be easy to do. I should. But the other should as well documented. Fair. In the same.

[00:57:35] **Bob Hinden**: Yeah. I heard.

[00:57:36] **Tim Chown**: Yeah. Tim China. There's a difference between implementing and using Yes. As as well, you might want to. But there is that RFC 98 something something Yes. That one. Talks about this, and that's the thing we could

[00:57:47] **Bob Hinden**: That's the one I have later in this. I promise that one's late.

[00:57:49] **Tim Chown**: But Tim and I have had a discussion about this. And in a way, we're kind of thinking, well, should we just say nothing? Because as soon as you mention it, you get a lot of opinions. But I think we have to say something. And the question is, where is the long term future of 7050? There's a are there gonna be things around that will need it indefinitely, or can we push harder now? But I think you've got a slide later anyway.

[00:58:11] **Bob Hinden**: I do. I mean, I what I'm hearing right now from the working group is yank seven 7050, so I think that's what we're gonna do.

[00:58:18] **Jen Linkova**: Okay. Let me say yes. We published ninety eight seventy two Yeah. Which says should do array option and may fall back to seventy fifty if it doesn't support it. However, there is disclaimer saying we do not apply that requirement to mobile devices, and the reason is some mobile operators were very, very explicit that they don't want to do pref6-four, and they are very happy with seventy fifty. So, basically, making seventy fifty optional would break devices in mobile environment. So, maybe what you can do, you can just like, you you can just refer to ninety eight seventy two. You can just say the device the device must discover prefix for some like, not six for prefix somehow. There is a ninety eight seventy two which describes the current recommendations for doing this and just avoid all this problem altogether. Right? Yep. The the only problem would be, I think, that RFC is informational, so it's gonna be a downref.

[00:59:36] **Bob Hinden**: Well right. Yeah. Let me

[00:59:39] **Jen Linkova**: But I think it's, like, manageable.

[00:59:41] **Bob Hinden**: Yeah. I'll take a look. Well, Tim and I'll we have a ticket for this. We'll go look at this and come up with the right thing, hopefully.

[00:59:49] **Jen Linkova**: Yeah. Yeah. Because I just don't think it makes sense to repeat the same text from the same like, the same text in multiple receive on how to discover the same thing. Because if we eventually want to update ninety eight seventy two, For example, if we invent another shiny, beautiful way to discover pref six four, we might just point all other RFCs to that one. Yeah.

[01:00:12] **Bob Hinden**: I mean, I think this whole section, my memory of this is we say at the top of this that, hey, if you're doing transition mechanisms, you're gonna wanna go read these things. I think we can say that and get ourselves out of this should make discussion and say, go read these documents and make the decision on your own if you're a v six node, which might be the smartest thing for us to do.

[01:00:30] **Jen Linkova**: Because I just realized what if I'm in theory have a device which I just configure with prefix for stratigly. I don't know, like, servers or something. Right? Yeah. We, like we we need to say the device should support discovery and how it discover?

[01:00:46] **Bob Hinden**: Right. I I think that's the thing we might wanna just say in this case. Hey, Jordy. I

[01:00:53] **Jordi Palet Martinez**: think there is a bigger problem with seventy fifty. My experience is that many operators implement seventy fifty or not implement it at all because through the three GPP specifications, they can already announce the DNS, which has already DNS 64 support. And the bad thing is that the seventy fifty was was updated by 08/08/1980, if I recall correctly, and this is not being done. So what happens is that, actually, seventy fifty alone doesn't work or doesn't work correctly. And in most of the implementations of I p v six in, mobile networks are not using r c eight eight eight zero. So if we mention seventy fifty, I will suggest that we should also mention eight eight eight zero, not just seventy fifty. Even if it's updating the that document, but the people don't realize that.

[01:01:59] **Bob Hinden**: Yeah. I

[01:01:59] **Jordi Palet Martinez**: mean I think there is something really broken there, and I I really think we should deprecate seventy fifty, actually.

[01:02:06] **Jen Linkova**: Okay. If you may wish to convince mobile operators to do array option.

[01:02:16] **Bob Hinden**: Yeah.

[01:02:21] **Lorenzo Colitti**: Not to not to bring up another problem, but, like, this doesn't actually do anything. Right? It's like support should support f r f c at seven eight one. And then okay. I learned in the pref six four. What do I do? Log it to stdair? Like, am I supposed to synthesize? Am I supposed to do

[01:02:37] **Bob Hinden**: Well, I mean right. So the the original was to perform for v six address synthesis in v six only environment. Right? So we we try to be we try to deal with that problem. We can argue about whether we do it the right way or not. But we tried to be clear that we weren't

[01:02:53] **Lorenzo Colitti**: Is it is is how to perform local address synthesis defined in any RFC? No. I just just say, like, this is a require this is standard strike document. Right? Yeah. We because, like, eighty seven eighty one says, like, here's the format of an RA option that you can look at. And and that's fine. Right? You can implement that, but it doesn't say what you're supposed to do with it. Anyway, just I I'm I just, like, don't wanna rat hole here, but it it it

[01:03:17] **Bob Hinden**: like I said, I I think our goal here is to tell people if you're interested in this, go read these things, right, from the general mode requirement document would be my that's

[01:03:28] **Jordi Palet Martinez**: what men's what Lorenzo just mentioned is one additional problem. How local host can do cell synthesis or local synthesis is described in, RFC seven which which the DNS documents, sixty one forty seven, I think, or 40 yeah. DNS 64. Okay? It's described there. The problem is that we are using three different terminologies. We are using a stop, a stop synthesis, local synthesis, self synthesis. So it's really confusing for many people.

[01:04:05] **Bob Hinden**: Yeah. I yeah. I mean, this is you know, we're talking about we wanna mention that this exists, and nodes should go read this stuff, I think, is really the goal of node requirements when it comes to these things. I I get leery of us trying to tell people what to do in these scenarios.

[01:04:22] **Lorenzo Colitti**: I mean, '61 c '47 talks about the DNS six four Nope. Which in this in this situation doesn't exist. So I think all of this text is kinda not really yeah. I don't think this is defined anywhere.

[01:04:37] **Bob Hinden**: Mean,

[01:04:37] **Lorenzo Colitti**: we should define it.

[01:04:38] **Bob Hinden**: But

[01:04:38] **Bob Hinden**: Yeah. I have to go back and read the whole section. I I think, really, here, what we were talking about is trying to do v six only and and some of the things people might wanna go look at is my memory of this. But I will I clearly need to expand this text before we we'll take another look at this section for sure. Thanks, guys. This is like I said Resolve revolt.

[01:04:59] **Eric Vyncke**: It's mentioned

[01:05:00] **Bob Hinden**: a specific stat resolver revolt. Okay. We made some we made some other minor changes. We had some SVCP. Someone gave us some we added those as DNS records that should should be there. We removed limits for the reasons I discussed at the beginning. Those were just minor changes. Pending updates. So we have a couple things going on here. DHCP v six, I feel awkward about this as an author of that document. I forgot that we we don't have it in this document, so we're gonna fix that. It'll be ninety nine fifteen for sure. It needs to be updated to that. So this document will point to that. I'll make that update this week. CE Router, I think Brian Carpenter pointed this out. I can't remember on which doc. I think he pointed it out on 7084. They both reference each other, oddly enough. Seventy eighty four points to general node requirements, and general node requirements points to 7084. They're both going to work in group last call very soon, so I think we're gonna be fine. But they should both update and point to the Biz versions of each other. That's okay. There's a couple of other minor issues we have listed. I put the issue tracker here. If you're really into this, it's on GitHub under Tim's account. We have issues there. Feel free to torture us with more if you want. It's up to you. So the they're there. Some of the other things I did wanna talk about for the working group in this document. One of them, I think we heard today, default address selection is finishing its update, and we'll get a new RFC number. Do we wanna update to that as a working group was one of our questions? I'll start with that one. Do we wanna say, hey. You should do the latest one. I don't see any reason not to except for I'm wondering about implementations a little bit with this one.

[01:06:56] **Lorenzo Colitti**: We had this discussion at some early six man, and I think Ted Lemon was like, you should say must even if nobody implements it. And I think I would agree with that.

[01:07:06] **Bob Hinden**: Okay. For

[01:07:06] **Lorenzo Colitti**: what's worth, we're Android's implementing this, at least. Okay.

[01:07:11] **Bob Hinden**: The update. You're doing

[01:07:13] **Lorenzo Colitti**: the least there's gonna be one.

[01:07:14] **Joanne**: Okay.

[01:07:15] **Lorenzo Colitti**: Six seven twenty four bis. Bis.

[01:07:18] **Bob Hinden**: Yeah. Okay.

[01:07:19] **Lorenzo Colitti**: I think the non local ULA is really important. So but

[01:07:22] **Bob Hinden**: That's okay. I'm getting thumbs up. Okay. So that one we'll put in. I I'm not scared of this one. I I just wanted to make sure the group's cool, so we'll add that one. It sounds like it's clearing through the it's going through the RFC editor too, so that's a good one. That one's easy. Slack renum. What do we wanna do with this one? I know this is also going through.

[01:07:40] **Jen Linkova**: It is in the last call. However, I'm trying to remember what yeah. Okay. So, see, a Slack renum is going to the last call. I know like, it's in the last call. So there is a few things which we need to discuss. I mean, review is going to discuss with the authors this week, hopefully. So, I can't explain how much I'd like to move this document forward. So we'll put a lot of effort into it this week.

[01:08:07] **Bob Hinden**: Okay. I mean, I the answer for node requirements might be not not this rev. Maybe in a future one, as we all know, eventually, we have to pick this document up again as things get updated. So we're just down this is where we're down to the last you know, whatever is currently in flight and how we wanna handle them. And six re num I'm sorry. Slack re num was one of the ones that is clearly in flight, and it's been in flight, and we weren't sure how to touch it. I think if no one has super strong feelings, I'm tempted for that one because it does have some changes in it that we just let it lie for this go. But if people had super strong feelings, please send something to the mailing list or jump up to the mic like my coauthor is.

[01:08:50] **Tim Chown**: Yeah. Tim Chen, I think oops. I think the Slack re num work is good, and I think we should capture that in essentially the guidance that node requirements is to Yep. Implement it. So it'd be a shame to I mean, they could still find it, of course, but it would be nice to have it in there as something that they would be more likely to look at. And, certainly, the 6724 update is the same thing. Yep. It'd be nice to have the ULA benefits Yep. In there as well.

[01:09:15] **Bob Hinden**: Okay. Heard.

[01:09:19] **Lorenzo Colitti**: I mean, I think it's the only concern with Slack, Renum, would be, like, you know, the the fear of getting stuck in Misra for a while. But, I mean, Jen's right. We we need to get that out. I mean, like well, I suppose we disagree on that particular issue, but I I feel that it's really important to allow zero RA zero valid lifetime RAs out. And, yeah, we disagree on that issue.

[01:09:44] **Zafar Ali**: Okay.

[01:09:45] **Lorenzo Colitti**: For for, while I'm here for the for the synthesis stuff, what you could say for for for the document concretely is you could say eighty seven eighty one is required, and nodes are supposed to understand the array option and somehow make it available to user space or to apps.

[01:10:01] **Bob Hinden**: Okay.

[01:10:01] **Lorenzo Colitti**: And then that's because otherwise, if you talk about synthesis, that's involving a bunch of other things like the system resolver. Yeah.

[01:10:08] **Bob Hinden**: Yeah. Okay. That might be our way out here. Thanks, Lorenzo.

[01:10:10] **David Lamparter**: Because otherwise, it's it's you have

[01:10:12] **Lorenzo Colitti**: to specify something that's unspecified, and, yeah, it turns into

[01:10:15] **Bob Hinden**: a mess. Okay. Okay. So oh, go ahead, Jen.

[01:10:22] **Jen Linkova**: I no. No. You you can use I just put myself on the queue so I don't forget because

[01:10:28] **Bob Hinden**: I really want to

[01:10:29] **Jen Linkova**: say something. And I Yeah.

[01:10:30] **Bob Hinden**: That's fair. Okay. So I think based on the feedback we got today, I didn't hear anything that terrifies me. We're gonna put out a draft o four this week, and then we think it's ready for a working group last call. I think we've had enough time with this doc, and it's time for

[01:10:45] **Eric Vyncke**: it to go

[01:10:45] **Bob Hinden**: to working group last call from the author's perspective. Good. Yeah.

[01:10:50] **Jen Linkova**: I Jenny, caller, no hats on. I'd like to I'm I'm sorry, but I might open a small can of worms here. I had interesting discussion with some routing vendors this week, And I was pointed out that there is a certain AYANA registry for special IPv6 addresses, and some of them, for example, are not supposed to be forwardable.

[01:11:17] **Bob Hinden**: Oh, boy.

[01:11:18] **Jen Linkova**: And apparently, no vendors which produce some nodes are not aware or at least not required to do anything about that. And so is there what do you think about how can we make a node comply with properties of special addresses? I mean,

[01:11:42] **Zafar Ali**: right. We

[01:11:43] **Bob Hinden**: So I I have some experience with this, unfortunately. So my my my quick answer to this is there are lots of test programs that exist in the world that, deal with this problem and making sure that devices properly add those addresses. There's two things that happen with routers in my experience. One of them is that they allow knobs based on customer feedback to make questionable decisions, but the default is typically what you would expect. But, occasionally, people make decisions that they want to forward specific addresses for operator requested reasons is how I will put this. So from from node requirements, I think, you know, we wanna stay away from that part of it. I think there are plenty of wonderful compliance test programs that exist in the world that can test those things and tell you that you actually do it per word. I think my gentle reminder here is that if people customers wanna do something, they're gonna ask their vendor, and their vendor at some point is just going to be like, sure. If you wanna do this, go ahead. Buyer beware situation. That's basically been my experience with the situation you are discussing, is that we've had people come in and allow forwarding different addresses for various reasons. So I don't think node requirements needs to say anything about that because it's covered in the other RFCs that cover address forwarding. Forty two ninety one, for example, or pick your favorite one. Does that answer your question, Jen?

[01:13:24] **Jen Linkova**: Yes. I just wanted to bring it to the group attendee and the author attendee. I actually don't even have opinion on that. I just tell you.

[01:13:31] **Bob Hinden**: No. I in general, I think node requirements I mean, like, the US gov profile, for example, is based on node requirements, but it doesn't go into that level of detail. It just says you should do forty two ninety one that has all the wonderful text about address types. Hey,

[01:13:45] **Ron Bonica**: Ron. May maybe it would be a good idea to protect vendors a little bit to say, if you're gonna break a rule, at least make it configurable?

[01:13:54] **David Lamparter**: Yeah. Yeah.

[01:13:57] **Bob Hinden**: I'm trying to think I I'd have to go back and look. I don't remember if we've done this anywhere else in this document. That's a good question, Ron. Let me let me check that. My my experience with this is, yeah, if you're gonna do the you know, if it's not a default slash what we expect, you should do the right thing.

[01:14:14] **Ron Bonica**: Yeah. Maybe it should be a great big global. Yeah. For any any rule you're gonna break, If you're gonna break it, only do it when you've configured it to break it. And with permission only.

[01:14:28] **Bob Hinden**: Yeah. Yeah. Okay. That's a good point. Okay. Yeah. I think that's, you know, from our perspective, think we're ready for working group last call on this document. And we can do it again in ten years.

[01:14:41] **Jen Linkova**: Perfect. Thank you very much. Yes. So, we'll wait for next version and then, guess, issue working group last call. And I would really, really ask people to read this because it's a very important document. Right? If you do not read it, do not complain later. As it knows, do not do what you want.

[01:14:58] **Bob Hinden**: I promise, this is not as long as some of them actually. It's relatively short. It just points to a lot of stuff.

[01:15:03] **Jen Linkova**: Thank you. Okay. As this okay. We're done with working group documents. We should start talking about individual drafts. The first individual draft on agenda was actually Jeff, but I do not oh, you're in the room. Thank you, Jeff. I am getting the slides up, and I'm getting clicker for you.

[01:15:37] **Bob Hinden**: Is that the clicker?

[01:15:38] **Jen Linkova**: Yeah.

[01:15:38] **Warren Kumari**: It's only three slides. Hi. My name is Warren Kamari. This is a draft that I think you first saw in Shenzhen. It doesn't say much. It's basically a proposal to increase the loopback single slash one twenty eight address in v six with a larger prefix. The draft proposes a slash 96 prefix for that purpose. That's the proposal. The last time we presented it, we actually did suggest a particular prefix. The discussion of the proposal wasn't whether the idea of a prefix was good good or bad, but a long discussion about numerology. Numerology managed to get us absolutely nowhere. Quite frankly, it's not a discussion I certainly wish to have speaking as Warren, and my co author, Jeff, is not keen on it either. So the way this works is simply a proposal says, make it bigger, make it a slash 96, and quite frankly, leave the numerology to Ayanna. It's not my problem. And if it wants to be your problem, go speak to Ianna, not to me. I don't care. Today's request that you adopt this as a working draft. That's it.

[01:16:54] **Lorenzo Colitti**: Lorenzo, clearly discussion on numerology, I'll walk away. No. No. No. Let me let me be very careful what I say then. Please ensure that whatever prefix is selected has a clearly defined interface index length because four two nine one says, according to the first three if if if, you know, all interface identifiers except ones that start with zero zero zero binary have 64 bit interface IDs. So if your prefix is slash 96, then you you're kind of, like, in conflict with that. If it's if it's in that zero zero zero space, then you can't have an interface index because your interface index is undefined. And so I I think yeah. Sorry. I didn't I didn't say pick any specific prefix, but there are these these things that you have to work around.

[01:17:46] **Warren Kumari**: It's a numerology comment. Talk to Diana.

[01:17:49] **Jen Linkova**: No. It's a property of your prefix, not a it's a property of your prefix, not exact prefix.

[01:17:54] **Warren Kumari**: I think you think a slash 96 is the wrong number? No. Okay. Fine.

[01:18:00] **Jen Linkova**: Got it.

[01:18:00] **Eric Vyncke**: Next. So Irvin, responsibility for this. So adopting the draft without a specific prefix, I'm all set. Right? There's no problem. But before it comes to the energy IESG and the last call, I think we need to get all the requirement for such a prefix, pretty much like Lorenzo said, but listing. So the working group needs because the experience running a p v six network is not Ayanna, and they are pretty good. Right? They are nice people, but it's in v six ops and here. So we need to get all the requirement for this prefix.

[01:18:33] **Warren Kumari**: Joy of this process that we're all enduring with such, you know, enthusiasm is the first, the working group adopts the bloody thing. Then we can talk about requirements, etcetera, to help Diana guide itself in numerology, and then it goes to working group last call. So you're leaping ahead by a couple of process steps. I'm not disputing them, but I'm saying it's over and above exactly what's going on right now.

[01:18:59] **Eric Vyncke**: As I said, I have nothing against adoption right now. Fine. And, actually, as an individual, a supporter. Thank you.

[01:19:06] **Jen Linkova**: Okay. Great. So we'll issue the adoption call. Thank you very much, sir.

[01:19:10] **Bob Hinden**: Thank you.

[01:19:12] **Jen Linkova**: Okay. Next. Sorry. I'm multitasking, and I'm not very good at it, apparently. Okay. So now we have flow labels. Okay. Let me get the slides up. Flow label. What happens? Sorry. Ah, great. So do we Joanne, are you in online in the room? Oh, cool. Do you'd like to take the slide slide control?

[01:20:07] **Bob Hinden**: Hear me?

[01:20:07] **Jen Linkova**: Yeah. I can hear you. Do you want to get the slide control? I will gonna give you Yeah.

[01:20:12] **Zafar Ali**: Thank you.

[01:20:13] **Jen Linkova**: Okay. Hold on. Yes.

[01:20:17] **Joanne**: Okay. Okay. Okay. I can see the button. Thank you. So hello, everyone. This is Joanne from China Telecom. Today, I'm going to talk about the solution for the our rocky v two flow level low balancing method based on the I p v six flow label. Okay. I touched the button, and it doesn't move.

[01:20:50] **Jen Linkova**: No. It's actually I can see the slides moving. You're current on the problem statement.

[01:20:55] **Joanne**: Okay. Perhaps I have never issues. So from my side, I speed nothing happened. Okay. It's fine. This is in the second page.

[01:21:06] **Jen Linkova**: We're in the problem statement here, slide number two.

[01:21:09] **Joanne**: Oh, okay. Thank you. So first of all, we're gonna talk about the problem statement because AI HPC workload very, very heavily relied on the work we choose for high throughput, low latency data transfer. But, however, multiple parallel at this any session from the from the send host may use to send we may use to send five trombone. And the traditional UMP hash based on the five trombone may may not identify different DNA session. So it will send it as a single throat, which will result in the elephant froze all hash on the sand sand pass and will it went it will it went lead to the network congestions, packet loss, and significant performance degradation. Okay. Next device. So we our solution is to use the QP number to identify the different IDNs sessions. In the first steps, we just need to first is the the two QP paired number. One is destination q p and the other one. Another one is source q p p. We use it as the entropy entropy and combine with other entropy to hash to generate a flow label to I p v six, which may create the necessary difference that five trauma cannot provide. So here is the details for the full label generation process. First of all, we we we use two QP pair and I p v six adjust to combine hash together with the algorithm CRC 32, which is a fast, however, friendly algorithm to generate the 32 bits CRC has your results. And then we take the only lower 20 bits of them to write it into the logistics for label, which finally can't do the can let the network device to the ECP. Oh, sorry. For the implementation implementation point is performed by the ingress network device, which can transparent and host operating system and applications and, of course, hardware. So the benefits is the we can achieve the five grand for low balancing and reduce network congestions and also improve our throughput. For the con for the security considerations, modify it only we only modified o p IPv6 for labeled, and we're not out IP address on the bottom bar or something else. And standard security considerations will front We are priced from the r c at $26.37. Okay. That's all for our con contributions. And the next day, we would ask for more reviews and comments and to improve the draft together. Thank you.

[01:25:17] **Jen Linkova**: Thank you. So I'll put myself in the queue with no hats on. I did read the draft, and I was a bit confused. So which device actually does this to flow label? Is it the same device which creates a pv6 packet, or it's some intermediate device which forwardings routings the packet?

[01:25:40] **Joanne**: It's from the so, it's from the ingress e ingress node device.

[01:25:46] **Jen Linkova**: So, basically, it's a device which forms an IPv6 packet?

[01:25:51] **Zafar Ali**: Yeah.

[01:25:53] **Jen Linkova**: Okay. So, because I think your draft would benefit greatly from explaining this clearly because the abstract says about routers and switches modifying flow label which confuse the readers and gives impressions that actually some intermediate devices receiving IPv6 packet from neighbors going to do something with the flow label in the past. And this is like huge difference, so I think it needs to be clarified, especially for people who are not familiar with technology. Thank you.

[01:26:22] **Joanne**: Okay. Thank you. Thank you for your point. We will clarify in the next version.

[01:26:34] **Lorenzo Colitti**: Lorenzo, clearly, I am confused about whether this is the same as RFC seven zero nine eight, which defines slow balancing on the on the flow label. Is it the same as seven zero nine eight?

[01:26:48] **Joanne**: Sorry? For which RFC? The one zero nine eight?

[01:26:53] **Lorenzo Colitti**: Seven zero the RFC seven zero nine eight defines load balancing on the flow label. So that's already an RFC. Right? Is it is what you propose the same as RFC seven zero nine eight, or is it different?

[01:27:04] **Joanne**: I'm not sure about because I I I didn't re read the RFC seven zero nine eight, but I need to check out later.

[01:27:15] **Lorenzo Colitti**: Yeah. Well, you should read it then because that's it it provides a way to node balance, and I suppose you could extend that to ACMP. I the other question I have is why can't the packets be emitted with different clearly, you clearly, if you're using eCMP, you probably have separate flows because otherwise, you'll have reordering within a flow, which is probably going to impact performance. So just a question, like, why can't you change the source port?

[01:27:52] **Joanne**: Do you mean you mean in some kind in some scenario, it will not hit soft soft q p. Right?

[01:28:04] **Lorenzo Colitti**: Your your first slide said that the five tuple is always the same, but that that seems like a bad design. Right? If you go to the first slide

[01:28:16] **Joanne**: Yeah. Please go ahead.

[01:28:18] **Lorenzo Colitti**: If you go to the first slide, it says the five tuple is always the same.

[01:28:25] **Joanne**: First slide.

[01:28:30] **Jen Linkova**: Maybe we can take it. This is my limit, please. Yeah. Okay.

[01:28:33] **Ron Bonica**: Thank you. Ron Bonica, HPE. I'd like to first answer Lorenzo's question. This is mostly overlapping with the RFC, but there is one point of difference. He talks about how to generate flow labels. That doesn't need to be standardized. It's a purely private behavior on the part of the source. So the the question here is what needs to be standardized that isn't already?

[01:29:06] **Joanne**: The the main idea is to use the two different QP test, the more intrepid intrepid. So this is what we want to standardize.

[01:29:18] **Ron Bonica**: That's that's a purely private behavior. It doesn't need to be standardized. You can do it and not tell anyone about it.

[01:29:24] **Jen Linkova**: Yeah. Ron, I I agree. So I didn't make that comment because it wasn't clear for me if it's intermediate host or source. But, yes, a host which forms the packet can put whatever they want into flow label, obviously. It could be an informational or even maybe BCP for hosts. Right? Just to document the implementation model.

[01:29:47] **Tim Chown**: Tim Chan, just a very minor point. Can you, in your draft, clarify in your You've got a section of terminology that an elephant flow is a flow, is data where it's the the identical five tuple. Some people don't have that same definition, but I think that's what you mean. So if you can state it, that would be useful.

[01:30:06] **Joanne**: Okay. Thank you.

[01:30:11] **Lorenzo Colitti**: Just so that I understand, is the idea that this can be done either by the same host as a part of basically underlay adding an underlay packet to do the overlay, or it can be done by a different like, by for example, by the router that's receiving your packet and the router is adding the underlay as well. Is that is that the intent?

[01:30:40] **Joanne**: I'm sorry. I can't hear clearly.

[01:30:44] **Lorenzo Colitti**: Oh, my audio is not good?

[01:30:49] **Joanne**: For now, yes. Okay.

[01:30:51] **Lorenzo Colitti**: So my I was asking whether you're intending this to be done by as a part of overlay networking. So if a device is emitting the ROTv2 packet and then something is adding overlay and that's computing the flow label, or is that for the very initial origin of the very initial process that create the packet itself. So is it for the overlay, or is it for the initial process, or is it for both?

[01:31:31] **Joanne**: I think it's for the for both.

[01:31:36] **Jen Linkova**: May I just like, I suggest we take it maybe offline just for the sake of time, and it looks like multiple people are confused about what what device actually does this. So as I say, it would be Yeah. I would suggest you post post a new version clarifying this to unconfuse all of us, and then we can discuss the next steps.

[01:32:00] **Joanne**: Okay. Thank you.

[01:32:02] **Jen Linkova**: Thank you.

[01:32:03] **Joanne**: Got

[01:32:03] **Jen Linkova**: it. Okay. So now we're going now we're going to talk about ICMP. I'm getting slides up. Slide clicker. Sorry. Too many okay. Hold on. Okay. Slide control.

[01:32:31] **Balazs Varga**: Thank you. My name is Balazs Varga from Ericsson, and I would like to present on behalf of the authors this ICMP error handling draft. There are reasons why there are two drafts on this. So unfortunately, we think that on the SRv6 VPN scenarios, if we are looking to the observability, there are lacking capabilities. And the two drafts that will be presented are focusing on these scenarios in order to fill those gaps. There is a different focus in the two drafts. The draft I will speak here about is about how to find the location if you have a failure in the SRv6 network, which prohibits the connection connectivity over the VPN network. And the intent is to provide transport network visibility to the VPN endpoints by the ping and traceroute. Regarding the solution, we just intend to provide the basic tool in order to cope with such situation. And in our draft, it is out of scope to cover complex scenarios where you have multiple technologies, you are using multiple encapsulation in the SRv6 network. If we are looking to a VPN environment, the challenge, if you would like to provide detailed information about the path, is that the p nodes are not VPN aware. So they don't know where to route the ICM pair or messages which are VPN specific. Furthermore, p nodes can be also IPv6 only. So if you are providing VPNs with IPv4, IPv6, the p nodes, if they are I p v six only, of course, they will not be able to generate ICMP error messages for I p v four endpoints. The essence of the solution is that let's focus on the error free part of the connectivity, and let's use that in order to provide the feedback for the endpoints. So the ingress p, this is here that we have defined and updated encapsulation that is affected the source IP address that is used for the encapsulation in order to be VPN specific. And then the ICMP error message is received back, then the ICMP processing function on this ingress age node. This is also something we we propose to change. The p nodes inside the network, they they are service unaware, and they are doing the standard RFC forty four forty three operation. So there are no changes on the p nodes. And we are also not involving the egress p node. We are trying to find issues towards the ingress p node. So that is the primary reason why don't why we don't want it to involve those nodes in the ICMP error handling. This slide is just summarizing who is doing that. Who who is doing what if if a packet is transported over the network. The ingress PE node, it will do a VPN packet encapsulation according to the uniform model, and it will add this VPN specific information in the source IP address. The P nodes are just doing the standard ICMP error operation. There are no changes here at all. And the ingress P will receive the ICMP error message, and it will process it and make it forwarding according to the VPN based on the information that is already in that packet. So we are proposing an updated ICMP error message processing on the ingress node and and a method to to modify and forward ICMP error messages in a VPN specific way to the endpoints inside the VPN. The current version is version o two. There were some editorial changes. And from the technical perspective, the main item that we have changed is to adding reference to section eight of RFC 20 four-seventy three, which is dealing with the IPv6 tunnel error reporting and processing. And the text was also highlighted where our deviation from this RFC. This is where we think definitely some further work will be needed. We have received a lot of comments on list, both in the six man and the spring list. So many thanks for that. And this is what we intend to have as a next step as well. So further feedbacks are very welcome, especially regarding the VPN failures scenarios we intend to cover here and the expected behavior. And just in the note, I have also pointed to draft, which is focusing on a somewhat different problem statement, how to check the paths over the network, and that's it, practically.

[01:37:59] **Jen Linkova**: Okay. Cool. So as I said, maybe unless there are clarifying questions just for this draft, right, we can hear the second presentation and then talk about because I personally have few comments which relates to both of them. So, yeah. So, so far yep. Now, okay. Clicker slides.

[01:38:21] **Zafar Ali**: Thank you.

[01:38:22] **Jen Linkova**: Yeah. Hold on. Okay. Clicker.

[01:38:29] **Zafar Ali**: So this is the draft that we started and implemented for ICMP error handling, and thanks for setting the stage. The the while the board draft talks about or handle the same base, which is the ICMP error in a services VPN, The use case is slightly different, so just highlight that. There's one more thing is that there is a six man I say it's a spring presentation that that we're gonna do joint, And we have discussed and agreed to merge the drafts and then produce one one draft and and forward that because these are complementary procedures. So so from a problem statement point of view, the context is really a services VPN. So if you have in this draft, what we the previous draft that we talked about is is about the trace route and finding where the problem is. But this draft is more generalized in the sense that if you have a packet that was originally delivered as c one and is is the context is a services VPN. And there is an ICMP error. For example, the ICMP error could be the path the MTU value exceeded, and then you have to send that that that packet back to c one. So this this is a generic solution to that problem. But obviously, the assumption is that this is a VPN context and the provider is willing to share that information with the customer. So that's the underlying assumption obviously, otherwise these packets, these these ICMP error that are generated in the core are not to be supposed to be delivered to the customer device. So that's the base assumption to start with. The c's may be IPv6 or IPv4 cable, but the most important point here to note that in the network, in the VPN scenarios, the context, the VPN information, how to forward that packet back to the source CE or the CE is available only at the PE nodes and is not in the middle on the network. So p node doesn't know how to forward that packet. P node just know to to either send it back to a PE node that can forward that packet towards the CE. The PE node doesn't have that information. For this draft, the approach taken is take the same approach, same problem, same solution. MPLS has the same MPLS VPN has the same problem, is that if you have an n if you have an ICMP error and you are allowed to send it to the customer device, then you will, from the p node where the error happens, because p node doesn't know how to forward, but it actually let the packet go forward towards the egress PE, who knows how to send that packet back to the invoking CE. So so that is the same notion that is extended here in this draft that the p node can actually let the packet go, which exceed the the thing, let the packet or the part of the packet go towards the egress p who can actually then send it to the invoking city. And that's really is is is the core of this. So you don't need a VPN context at the invoking or at the ingress PE or egress PE. There are no changes required at any of the PE sites. There's only changes required at the p node to be able to let the packet forward towards. Okay? So and the rest information from the egress PE as well as on the ingress PE is really their forwarding information. Their their regular VPN forwarding, everything else happened in the data plane. And I explained further. So I use an example which is a traceroute example. It's easier to comprehend, to to illustrate the solution, but it is applicable to any ICMP error. It's not limited to traceroute. So let's take an example. A CE one created a trace route probe to with a hop limit of two. And that's the packet. Looks like it is a trace route from CE one to CE two. When it comes to the ingress PE, ingress PE applies the regular IP services encapsulation to this packet, which is what is highlighted in a red box, and which is actually to say that this packet to go to p e two VPN sit. That is encapsulation that is applied, and the only thing that happened to the customer packet is that the hop limit got decreased to that packet because it's a uniform model, so the hop limit got copied from the incoming packet to the provider header.

[01:44:34] **Bob Hinden**: Okay?

[01:44:36] **Zafar Ali**: So in this case, this packet will have an ICMP exception at p one. And p one is the device that needs to create an ICMP error for the CE one, so what it needs to happen is that this error which is the lower packet, focus on the lower packet with a box in it, This is p one telling that there is an ICMP error, and it needs to go to c e one, but because p one doesn't know how to forward, it puts in the original VPN CID where the packet was going towards. So it copies that p e two VPN SID in the outer DA. So from then on, this packet goes regular forwarding towards the p e two. P e two also do the forwarding lookup on this packet like any other packet, and it finds out that it needs to go to c one and it it it has forwarding information how to forward with normal VPN SIP processing, and the packet goes through the data path towards the CE one. So essentially, the MPLS does with MPLS, we do the exact same thing. So same operational experience for the service provider. And there are yeah. So the main point to note here is that the node the only node that need change is the p node, which because it cannot forward the packet towards the CE, it uses the incoming packet destination of VPN sit to complete the rest of the forwarding. Okay. So, yeah, this is fine. I think the main next step is really where presenting, co presenting these drafts in the spring and we will merge because the things are complementary here. We are trying to find out if the data part is intact, how do we use the data part to send the packet or probe or packet ICMP error towards the CE, and in the other draft is like more like finding if there is brokerage in the pack data package for that. So now I think it'd be a good time to ask for any questions, comments.

[01:47:16] **Jen Linkova**: Yeah. I have questions about specifically your draft before we go into discuss the whole ICMP process and stuff. First of all, clarifying question. Did I get it right that p router will be spoofing the source address in this case, in the outer header? The source address of this packet which it sends towards p two will be actually not p one source address, but p e one address. Is it like some source address spoofing happening here?

[01:47:45] **Zafar Ali**: No. So so the the source address, if you look at the packet that is is in front of you, source address is the is the actually, it is the p one source address. It's not p e one. It's the p one source address because he's the one sending, is the destination address that he uses from the packet. This point we can clarify. The source address, is it local source address? Because if this packet happen to have another ICMP error, you really want it to be intercepted by people.

[01:48:20] **Jen Linkova**: Because I don't think it's what your slide said, and it's not what the draft says. It says that source SA is p u one. Right?

[01:48:28] **Zafar Ali**: Yeah. So I think this is what we need to fix. The SA is p one. There's no reason to move to use this as the this is this is a fix that we do in the next revision because there's no reason for it to pick somebody else's address. It is his address because if there's a further ICM error, we want it to get to p one, not p one.

[01:48:51] **Jen Linkova**: Yes. Okay. So quick I know time was over, but quick question. If I understand correctly, you're looking through the whole packet to find the most inner header, right, at some point of time. What happened if c one already sent you a tunneled packet, which already had IP 19 encapsulation? Would it cause any problem or not?

[01:49:13] **Zafar Ali**: No, it would not cause any problem, and in fact, draft does cover that and talks about it. Let's say, for instance, you have an FRR and the packet has another FRR header, the way that the packet processing happens is that is from the packet, which is where you need to send the payload. From payload to the packet, which is the the gray packet here, the header of that packet, and if that, based on that address, is the decision is made in terms of where to pick up the PE two where the packet can be forwarded. So it's the last SID after that. So it picks up happen. So if there are other headers ahead of it, they are not looked in.

[01:49:56] **Jen Linkova**: Okay. Thank you. Ron, is it like clarifying question for this draft specifically? Yes. Okay. Quick.

[01:50:03] **Ron Bonica**: Okay. It seems that this strategy is applicable to any kind of IP and IP tunnel. I p v four over I p v six, I p v six over I p v four, GRE, you name it. Why is the scope limited to s r v six?

[01:50:20] **Zafar Ali**: So, Arun, we did talk about this, and and you suggested the generalization draft as well. We are happy to have the generalization draft progress. But but here, the implementer that wrote this draft or doing it for a customer that had this problem and we solve it together and your company is involved in this HPE, did the implementation, it'd be good to have this SRv6 specific because then it also gives implementer a view on how to to to implement this procedure and all for SRv6 only. There could separately be a separate draft in in the area about generalization and and this way of doing it because MPLS did it. It is totally applicable to other other tunneling technology.

[01:51:07] **Ron Bonica**: If the generic draft is specific enough, why does this one need to exist? The need for its existence points to a problem in the generic one.

[01:51:16] **Zafar Ali**: No. I I I I think this needs to exist because this does explain clearly for implementing how to do it. Because I asked the same question to you when you wrote the draft. I don't know how UDP tunneling work, and you need to explain to me packet by packet how it will work. Maybe then down the road, you wrote that draft and it's so abstract that nobody else can implement it because implementer need these kind of level of details.

[01:51:44] **Ron Bonica**: And let's fix I the generic draft.

[01:51:46] **Zafar Ali**: And and and and and and I'll be honest with you, Les. If if you ask me if you give me generic draft and ask me to implement for other tunneling, I don't know. I mean, I need some some some some reference and what to do, what is going on detail. I think this draft this draft and what we talked about with the other draft, they stand on their own. If there is a generic draft that we write, we are happy to go out I mean, to collaborate on that and all, but both can go. These are the shifts in the night.

[01:52:22] **Jen Linkova**: Okay. So now I think we might want to talk about both drafts in general, and I have a question for authors of both drafts. Right? First of all, I'm still I'm a bit confused about how it is supposed to work when you have two ways to process the same ICMP in like, how is it going to be configurable one of the 14 competence way to process ICMP? We're going to use on a on a given network and leave it to operator, or how do you guys see it working?

[01:52:59] **Zafar Ali**: So the implementation, this is this is really there are two things here. Right? The the node where you have this ICMP error is really depends on that local decision on that node or local implementation. Let's say if you have a classic node that has not implemented, is there a node which is a brown node, had not implemented this procedure which is in draft- then it will then what what was the other draft? It will be the ICMP error will be sent back to this PE one, and the PE one will process and the other draft become important to use. And and we will, in the next revision, we will clarify, but in this revision, it's very clear what is the policies and how these these are picked up. So we will further clarify those policies. But I'll let Varga talk.

[01:53:52] **Balazs Varga**: Yeah. So there are differences in the encapsulation. In our draft, on the ingress PE, we have modified the source address. And based on the source address, if you know the SRv6 structure, and you are a SRv6 node, so you should know that structure, You will be able to identify whether a VPN specific seed is in the source address or not. If not, then this method can be used. If it is there, then you can use the other methods. So that that that is an easy way to to decide locally on the received packet if the hop limit expire, how to behave. So this is what what Zafar mentioned, that these are ships in the night from that perspective, that you can make distinguish what type of packet you have received.

[01:54:48] **Jen Linkova**: Which I'm just wondering if this needs to be somehow documented and they like, it could be an accurate kind of generic document saying, this is how you process ICMP, and it could be two paths which you're taking based on something. Right? Because for unprepared reader, this looks very conflicting. Right? And interaction between those two, I think, needs to be somehow documented.

[01:55:14] **Balazs Varga**: I I I fully agree. So on merging the two draft, there is a lot of work to do. One of is definitely that.

[01:55:22] **Zafar Ali**: Yeah. Thank you.

[01:55:27] **Bob Hinden**: One

[01:55:34] **Lorenzo Colitti**: quick question. Like, this would be happening on p one. Right? That means p one needs to be aware of s r v six, which the whole point a big part of s r v six is that middle nodes don't. So I don't know it is working.

[01:55:51] **Zafar Ali**: Yeah. So the I think this is where things this draft and along with the draft, well, her is also takes care of the cases when the p node doesn't is not SRv6 aware. Okay? So in that cases, in those cases, ICMP error always go to the ingress PE. So that's why we are covering all the cases. This is one case. The other case is when you have a node which is not a service cable and is is a is a is a node which is already deployed, and all it does, it pushed in working packet, copied in working packet and the ICMP error to the ingress PE. And in that case, the ingress PE does the processing of sending this packet back to the CE. And so these all three cases are there. This this case is already there in the draft that you talked about, in our draft as well, in the other draft as well. And we are going to make sure that I mean, this is this is, like, two different ways of doing the solution when you have capability versus not capability. But we we address both cases.

[01:57:07] **Lorenzo Colitti**: K. Should we settle on one and just do one?

[01:57:12] **Zafar Ali**: The the the thing is this that there is it depends. There are advantages and disadvantages, and this gets into the weeds of the detail that not in all cases, one method work because you have to put in I mean, let's say for instance, we take the other draft, you have to put in the source address which actually act as a hint on which v r f the packet belongs to. So you can actually look at the ingress p and then look up for that packet on how to forward. In the other methodology, we rely on the existing forwarding table, not putting a special source address. So there are pros and cons. That's why we are we are it's it's not one size fit all. There are pros and cons, so it's it's the implementation choice. Thank you.

[01:58:12] **Eric Vyncke**: So Eric Vyncke is responsible AD here. I love the capture. They said don't say ingress PE. They say ingress PE because I think they are French PE, American PE, Chinese PE and so on. Anyway, those two drafts are presented at year at sixman, but the arguments I hear in the queue are basically ready to spring. So I know I'm looking at you, Joel. Should those draft be done in spring rather? At at least there will be con consultation between the two working groups for sure. Right?

[01:58:49] **Joel Halpern**: It is not accident that there is a presentation scheduled in spring and specifically that spring is the one that asked that the authors merge. Now I didn't because I'm recused for obvious reasons. But, yes, the spring chairs would like to see one draft and then we will determine whether there's interest but the protocol changes, whichever set of protocol changes, have to be done here once SRV6 once spring has agreed on what approach we want to document. But Spring can't make the protocol changes. We don't own that. But the philosophy and approach, we can agree on in Spring so that six so six men doesn't have to spin their wheels waiting for us to know what we're doing.

[01:59:34] **Eric Vyncke**: So just to be clear, the spring charter prevents protocol modification. That's correct? Yeah. Okay. Understood.

[01:59:42] **Zafar Ali**: I think there's one thing that I'd like to mention is that there's not no protocol extension to this, but I'll let yeah.

[01:59:52] **Jen Linkova**: Yeah. So, I would like to ask, I'm not even see I don't even see this as actually a protocol change, because we're talking about a router behavior, which is kind of gray area. I do not think we change any bits in the protocols, right? We're doing some ICMP processing on device, which in the worst case scenario could go to inter area, but I do not see how it changes I p v six as a protocol. So, I kind of sitting on the fence here, but whatever however we classify this, it I feel like it's a bit too early to talk in six months about this. Right? So, I think Sprint needs to decide how you want the routers to behave, and then we can talk which working group specifies how SRv6 routers process ICB.

[02:00:40] **Joel Halpern**: So Joel Halpern again, as Spring co chair, but also as a co author on the draft. So I've got both sides and get myself confused. I agree with you that Spring needs to deal with it first. No problem. Whether this is a protocol change or a behavior change and therefore whether it belongs in six man or int area, we can we are we're all good at working that one out. We can we can sort it out. I don't think Savnet can I don't think Spring, sorry, Spring can mandate that the behavioral changes that we would that either draft need on its own? But the philosophy and approach to how it works for segment routing, Spring can take care of first, and then we'll bring it somewhere.

[02:01:27] **Jen Linkova**: Beautiful. Thank you very much. You want to say something? Okay. Thank you. This concludes the session. We're perfectly almost perfectly on time. Thank you very much. We'll see you in November.

[02:01:41] **Bob Hinden**: In San Francisco.