**Session Date/Time:** 18 Mar 2026 06:00

This is a complete verbatim transcript of the 6man Working Group session held during IETF 119 in Brisbane, Australia.

**Speaker 1:** Hi, guys. 

**Jen Linkova:** Okay. Welcome to 6man. Can you hear me okay?

**Speaker 3:** Yes.

**Jen Linkova:** Yes, we can hear you. Okay. Good, because I'm bit far away. So, welcome to 6man. So, unfortunately, neither Bob nor I could be in China, so apologies for that. So we'll be doing it remotely. Erik Vyncke kindly agreed to sit in the chairs’ chair and be physically present in the room for us. Thanks a lot, Erik. So, what do we have today? Note Well. Please take a look at this. Slides should be available on the Datatracker, so I don't expect people to read all of this right now, but as usual, please behave in a professional manner, respect each other, if you have any complaints talk to people responsible like ombudsman team and so on. Yes, again, by when you registered to IETF, you kind of agreed to IETF guidelines, which again were outlined in Note Well and yeah, we expect people to behave. Meeting tips. Yes, if you are in the room, keep your phone silent. Remote participants, yeah, advised to keep your audio and video, especially audio, turned off unless you're actually presenting. I was going to say people who are in the remote room in Tokyo, use the QR code to scan, but Erik already did that. So, yes, and please use the tool, either onsite or for a client, to join the queue because now, yeah, with people being remote and in two, in two different rooms, it would be otherwise really hard for us to track the queue. So, again, we this time didn't get our volunteer to take minutes, so we decided to use automation for this. So we’ll see how well automated meeting minutes generation would do, and yeah, we can review them later and see how accurate it is. So, important announcement. We have a leadership change for 6man. Eric Kline is leaving us as responsible AD. It's his last session as responsible AD today. I don't know should I congratulate you or just, or just say you'll be missed. And we have another Erik because apparently being Erik is a requirement for being an responsible AD for 6man. Erik Vyncke is our new AD. So, thanks, Erik, welcome, Erik. 

*(Applause)*

**Eric Kline:** Yeah, I've just, I'd just add that I think we've really enjoyed working with Erik and I'm sure we're going to really enjoy working with Erik. 

**Jen Linkova:** No doubts. So, we were told, but haven't experienced it first-hand, that poor people who are actually in China could not enjoy IPv6 mostly, unlike people who are on the remote side in Tokyo. So, unfortunately, yeah, I was told that people are getting legacy protocols, legacy addresses on their devices still, so this is a big change comparing to previous IETFs, unfortunately, but we're looking forward to Vienna, I guess, when we can again do the dog food and demonstrate how well IPv6 works. So, agenda. We have four working group drafts. We have four presentations about more than four drafts, which are individual ones. Since the last meeting, we have not published anything. We still have three documents sitting in RFC Editor Queue because of MISREF. Two of them are because of SNAC and one of them is waiting for another draft in INTER AREA. For SNAC, I know there is some discussion about what to do with this, and one of the suggestions is to put a SNAC draft, make it informational instead of normative reference for RA-Flag, which will unblock RA-Flag and unblock 6724bis update as well. But I know that Erik probably has an opinion on this. Go on, Erik. Well, my opinion was that it— to Erik, you're in the queue, you should join the queue. Okay. Erik who is in the queue, please go on. I think you can pronounce it Érik or something. My French pronunciation is not good. 

**Erik Vyncke:** Yeah, so first, as I'm responsible as well for SNAC Working Group, so I'm kind of ashamed to be in this situation to be honest. Changing a reference from normative into informative will of course clear up the 6man queue and the draft will be published anytime soon. Now to do this, I will have to check with the other Area Directors, but I think I need to get the agreement of the IESG to change such an important component of a draft. So we need to remove the draft from the RFC Editor Queue, submit a revised ID. I guess Jen Linkova will be happy to do it, this is the router RA-Flag, but then to do the change I need to get the agreement of the IESG. But I think it will be doable. 

**Eric Kline:** So I’ll just, so my sort of view on this is that the document says, "this flag, the way you use it is defined in this other document." The document itself is not dependent in any way on what's in that other document. That's why I think this could be informative. And, you know, eventually this would get cleared up on its own, but it's, you know, been 452 days so far. So, I think, personally, I think it would be good to clear this up. I would also wonder— I mean, I think it's good for the— well, I'd like to see if anyone in the working group has an opinion. But, you know, to certainly get discussed in the IESG, but maybe this could just be, we could just ask the RFC Editor to make the change without having to recycle the documents. 

**Erik Vyncke:** Yeah, I think— I wouldn't try to pull the document back. I would ask the RFC Editor to make a change if you want to make a change. I think that, yeah, you could make sense that for the RA-Flag that it's informative. I feel like it is normative for 6724bis though, because the treatment of the prefix is important given— in order to understand its sorting in the ranking and the— in order to understand the behavior that's described in 6724bis. If I recall correctly. 

**Jen Linkova:** But I— if I recall correctly, I need to double check, I thought that 6724bis refers to RA-Flag, not to SNAC draft. I think it's dependencies on RA-Flag, but I need to double check. 

**Eric Kline:** Well, if that's the case, it's referring to the prefix where you get the prefix that you then sort in the correct, in the correct place. But I think the treatment of that prefix is what's important, the context of that in 6724bis, and I think that kind of feels normative to me. So. But I will not be the responsible AD. I quote point one, "any RIO or PIO that is delivered in RA, you know, must be ignored." That is what 6724bis says, so it has normative text that refers specifically to this flag in the RA. 

**Jen Linkova:** In the flag, not the SNAC itself. The idea is if we can unblock RA-Flag draft by making reference to SNAC draft informative, then RA-Flag can be published and this unblocks 6724bis, and we do not want dependency on the big SNAC draft because actually it doesn't matter for both drafts, right, all these details about SNAC. 

**Eric Kline:** I mean, the right— yeah, the right thing is to maybe push harder on SNAC to see what's what's holding things up because, you know, the document has been very, very near being finished for a quite a long time. 

**Eric Kline:** Yeah, we certainly agree with that and have been trying to do that. Okay, so I guess, yeah, we can discuss between AD and the chairs. So, next one. We sent to IESG, SLAAC-RENUM. However, as far as I know there are people who might have comments on this. The document is kind of out of the working group last call, but has not yet entered IETF last call because Erik is like providing his feedback. So, we'd like to hear like if you have any like comments on this, we can talk about this now. Erik. 

**Erik Vyncke:** So Eric Vyncke, I am already the responsibility for this specific draft, right? It's an agreement between Eric Kline and myself. During my AD review, I've put a couple of points, and one point if you remember is when a prefix is been no more active, how many RAs are sent. And the original document says for the expected lifetime, remaining lifetime, we are sending RAs. And Lorenzo, I think this was you commented correctly, if we do it, we will be basically burning the batteries of many mobile device. So, that’s an important decision and I want to get the working group consent on this change. Right, because that's not like changing a comma somewhere. So that's the reason why I wanted to get this discussion maybe here. 

**Eric Kline:** Yes. Yeah, and and I think one thing that's sort of somewhat complicates this is because, you know, I think unfortunately that, you know, what this draft is doing is I think it's just, I think it's just basically invoking some behavior that was written in a V6OPS draft, which I think kind of didn't have standing to change any protocol implementations, right? So, because there's a lot of SLAAC renum draft and I think that's what it says, but in any case, yeah, no, I, just for the record, this is harmful and I think we shouldn't do it. It will definitely— there is like literally almost a billion devices in the field where this will sort of break the RA filtering if it becomes commonplace. We, we should not do this, or we should not at least do it lightly without discussion. I think, you know, we should find a— you know, we could have a better way to, you know, we definitely do want to ensure this stuff gets deprecated, but, you know, sending, you know, 10 RAs once every second, you know, should be enough for that, right? Instead of just sending it for a week or an hour or something. 

**Jen Linkova:** So Lorenzo, so basically your preference would be to go and discuss this draft again, right? So you do not think it's ready to be advanced? 

**Eric Kline:** Not as is, no, it's harmful. No, we cannot, no. 

**Jen Linkova:** Okay, in this case may I ask you, may I volunteer you as a reviewer for the next round of the last call because I think the problem is it was— the group was very quiet during the last call and some substantial comments came a bit later. So if you can avoid this next time, it would be beneficial and would save some time for responsible AD. 

**Eric Kline:** Yeah, sorry for catching this later, as soon as I, because I, yeah. Yes, you can both do. Okay, I'll micromanage you and make sure you get it. Okay. And May is possibly, he had also, yeah. 

**Speaker 3:** So we have Brian in the queue. 

**Brian:** Yeah, can you hear me? 

**Jen Linkova:** Yes. 

**Brian:** Okay, so I basically wanted to say I think that Lorenzo is absolutely right about this. It can possibly be fixed in the text with a "should unless" type construction or something like that, but but I think there really has to be an an off-ramp for the devices with small batteries. 

**Speaker 3:** Yeah, and make that clear. 

**Jen Linkova:** Okay, so it looks like, yeah, we need to do another round of review on this. Okay, that's. 

**Speaker 3:** So Eric, so will, will you then send this back? 

**Erik Vyncke:** This is the process, right? So I will send it back to the working group, so you can change this section, do another working group last call and on we go. Sorry for the process, but I think the change is important. Eric, he don't seems to agree. Revised ID needed. 

**Jen Linkova:** Okay, so. Okay, so we have a document in the last call currently for SRv6-SID List. So yeah, if you care about SRv6, please take a look. Ah, oh sorry, it's already, sorry, left working group last call, waiting for the write-up. Sorry, need coffee. And we recently actually adopted a draft about sub-link scope multicast after two adoption calls because first one was missed by most of the audience. 

**Eric Kline:** If the sid-list document needs a shepherd, I can volunteer to be your shepherd after I— in another hour or two. 

**Speaker 3:** Are we going to take you up on that? 

**Jen Linkova:** Yeah, thank you, Erik. So someone now has free time. Eric's existence was partially my fault anyway, so. Okay. Good. So, this just a standard last slide standard reminder that 6man often gets requests to review or present some drafts which actually solving problem for other working groups. Quite often it's SPRING, but not necessarily, and we normally would like to get a confirmation from those working groups' chairs that it's actually a problem worth solving because quite often this working group just doesn't have enough expertise to deal with this. This actually concludes the chair slide, but I know that David was going to say something, so please go ahead, David. 

**David Schinazi:** Actually on topic for the slide here. David Schinazi. The working group draft for 802.11 FMS will need a liaison statement, so sorry for bringing bureaucracy, I will figure out what to do there and where to go and that's coming at some point I guess. 

**Speaker 3:** Okay, well just let us know if we can help. 

**Jen Linkova:** Okay. Cool. So, now we can go to the first presentation of today, which is YANG data model. Jen, do you see the queue? Oh, sorry, no I don't. 

**Suresh Krishnan:** Hey, hi, hi Jen. Suresh. Hey, Bob. So, the, the background for this is right, so the FMS stuff that David was talking about is already an optional feature in 802.11, so they kind of need some kind of indication from us that if it needs to move from away from optional, right? Like if it's just like a fairly good thing to do, but we, they need something from the IETF. So, um, if like David like kind of works with you to craft something, I'll ship it off to IEEE afterwards from the IAB liaison coordination. So that's the goal for this thing. Just to set the background on like why it's needed, it's to move from an optional feature to something more than that, like maybe even a recommended feature or something. 

**Jen Linkova:** Yeah, thanks, Suresh. So, the first presentation is Fun with YANG model for Neighbor Discovery. Fun, are you online? 

**Fan Yang:** Yeah. 

**Jen Linkova:** Cool, so do you like to request slides or do you want just to have a voice control and I'll be moving slides for you? 

**Fan Yang:** You can put on the slide for me and I will just do the voice. 

**Jen Linkova:** Okay. 

**Fan Yang:** Thanks. Hello everyone, this is Fan Yang from China Telecom and I'm presenting the update of YANG data model for IPv6 neighbor discovery on behalf of the other authors. Next. Okay. First it's a recap about what this model is covered. Basically this draft covers the additional configuration and management of IPv6 ND and related functions that are not included in the existing IETF YANG models such as IETF IP, IETF IPv6 unicast routing and so on. And the [draft-ietf-6man-ipv6-neighbor-discovery-yang] model covers the functions like the IPv6 address resolution, redirect, proxy NA, NUD, DAD and other statistics things. Next. And thanks to the chairs for for the YANG doctor review and some thanks to the YANG doctor for the detail comment, and we've made some updates based on the review comment and here is the main changes since the last version. You can see the changes are highlighted in blue in the model. First we remove the some nodes like the leaves enabling dynamic address resolution and NUD, since they are more like a fundamental protocol mechanism or behavior rather than configurable parameters. And we also remove the specific types for proxy NA, so as they are more like implementation specific things and not defined in RFC. And we tend to keep the YANG model to a minimum subset for easier future augmentations by vendors. So proxy NA is now simplified into a single enable and disable leaf. We also enlarge the default and ranges for reachable time and NS interval with the definition in RFC 4861. And we unify some of the units into plural form. We also change the types of statistics leaves from YANG counter 32 to 64 for the consistency with the statistics defined in YANG module IETF interfaces. And we add some description to clarify that the per-interface stay-out overrides the global value. And we add constraints that auto-resolve is only valid when enhanced DAD is enabled, and age is only valid when the neighbor entry is dynamic. We've also added an updated reference for some of the nodes. In, we updated the corresponding text in the document about the YANG model changes. Next. And next step we would like to request a working group last call as the document has been stable for a while and we've addressed the latest comment from the YANG doctor early reviews. And comments are welcome. Any questions? 

**Eric Kline:** Why, why remove the, the enabled nud thing? I think that is like a sysctl that you see on Linux interfaces, for example. Can you disable nud? I'm not sure. Let me check, yes. 

**Fan Yang:** So there's reachable time that you can set to zero, which would probably do something. Yeah, I have made some added some description about it that this reachable time can't be set into zero. It's unrecommended. But we didn't set any like constraint for it. 

**Eric Kline:** Maybe I'm thinking of a, of a, of an interface flag where you can actually, when you configure an interface you can say don't do DAD. `IFF_NODAD`, yes. Yes. I'm confusing that with, with. `DAD_DISABLED`, yes. But not this is, yeah, disabling NUD. No. Nevermind. Thank you. 

**Jen Linkova:** Okay, so I guess, yeah, it would be great if people could review this, but then yeah the chairs will probably issue the last call because it— I read it like I think one revision ago and it was in the good shape, so I guess yeah we shall progress. 

**Eric Kline:** Yeah, and and we did do the, we did do the YANG doctor review. 

**Jen Linkova:** Mhm. Mhm. 

**Eric Kline:** Yeah, so we will, we will, you know, after IETF start a working group last call. 

**Fan Yang:** Okay, thank you. 

**Jen Linkova:** Awesome. Thank you. So, okay, so the next presentation is OAM capabilities. Let me get the slides. Okay, go. 

**Xiao Min:** Hello, yeah. Yeah. Hi everyone, I'm Xiao Min from ZTE. This presentation is on IPv6 query for enabled in-situ OAM capabilities. This is a recap of this draft. This draft defines the ICMPv6 extensions to achieve IOAM capabilities discovery in IPv6 networks. This draft is a companion document of RFC 9359 developed in IPPM Working Group. And this draft uses [draft-ietf-intarea-icmp-query] as the foundation for extension. For the node IOAM information query mechanism, this draft defines five IOAM capabilities objects. Since last IETF, there was a major change in this draft. The basis of this draft was changed from RFC 4620 to [draft-ietf-intarea-icmp-query]. And welcome Ron Bonica to be a new co-author of this draft. There are some follow-up updates due to the major change of the basis. First one, this draft does not update RFC 4620 and RFC 4884 anymore, so this tag is removed in the latest draft. Second one, terms were changed due to the change of basis. For example, node IOAM request reply were changed to IOAM query request response, just to align with the basis draft. Third one, the formats of the IOAM query request response are simplified. And the fourth one, there is ICMP extension structure was added to the IOAM query request, and within this ICMP extension structure, there are two objects. One is IOAM query object, another is a pad object. For the third one and the fourth one, I’ll elaborate in the next two slides. This slide is elaboration of the third update. The formats of the IOAM query request response, they are simplified in the latest version of this draft. On the left side is the original message format. On the right side is the latest format of the two messages, IOAM query request and IOAM query response. On the right side, the message formats are simplified, are more simple than the original one. The, all the two messages have the common ICMP header and just one ICMP extension structure containing one or more objects, so that’s more elegant, I think. This the elaboration on the fourth update, that in the ICMP query request, we add a new ICMP extension structure and within this structure there are two objects, IOAM query object and a pad object. The IOAM query object, it carries the IOAM namespace ID. It's like a question to the responder what kind of information is queried. And the second object is a pad object. It contains the extra padding bytes. That's used to make sure that the ICMP response package would never be larger than the ICMP request message. This slide shows the examples for the IOAM query request and IOAM query response. On the left side is the IOAM query request, right side is the IOAM query response. On the left side, there are two objects contained in the message. For the IOAM query object, there's a namespace ID, just one namespace ID in the payload. And for the pad object, there is extra padding. For the IOAM query response, there are also two objects. All the two objects are IOAM capabilities objects. First one is IOAM tracing capabilities objects, second one is the IOAM Proof of Transit capabilities objects. So all the two objects are the queried information responding to the querier. Okay next steps. As I said, there was a major change in the latest version of this draft, so the authors ask for more review and comments. And we have already received some comments on the mailing list and I think I've replied to that to address that comments. If there's more comments, please speak up now or send to the mailing list. And we'll revise this draft to improve it. And we are waiting for another basis draft, [draft-ietf-intarea-icmp-query] to progress first because that's the basis of this draft. So after that, I think we'll ask for working group last call on this draft. So that's it. Thank you. 

**Jen Linkova:** Okay. Thank you. So, I have not been following INTAREA draft. In which state is it currently? 

**Xiao Min:** Sorry, you mean INTAREA draft, ICMP Query? 

**Jen Linkova:** Yes. 

**Xiao Min:** Yes, this draft is on the agenda of this INTAREA session. 

**Jen Linkova:** Okay, so it's not in the last call or anything. Okay. So okay, just to confirm, you do not want to do last call on this one yet, right? You can do a few more iterations while we're waiting for INTAREA anyway, right? 

**Xiao Min:** Yeah, we'll wait for the INTAREA draft to go first because that's the basis of this draft. Yeah. 

**Jen Linkova:** Okay. Yeah, so in this case, yeah, I would suggest— would like to see like more people reading it because I have feeling that the mailing list was quiet regarding this draft. Okay. Thank you. So, anyone in the queue? Any questions, comments? Okay. So, then we move to the next. Thanks. 

**Xiao Min:** Okay, thank you. 

**Jen Linkova:** Thanks. So, the next one is what? Ah. Okay, stop sharing. Why? Hold on, sorry. My, wait. Oh, it was not me, right? Okay. Xiao, can you please stop sharing your slides? Ah, I can— I think I can do it, yeah. Ebox slides. Okay. Forgot how to do this. Okay. Next one. Jie, do you want me to move your slides or you going to take control? 

**Jie Dong:** Yeah, I can control it. 

**Jen Linkova:** Okay, cool. 

**Jie Dong:** Thank you. Okay, good afternoon everyone. this is Jie Dong from Huawei. I'm going to give an update on this [draft-ietf-6man-enhanced-vpn-vtn-id] on the carrying network resource related information using the IPv6 extension header, on behalf of my co-authors. Firstly, some background recap. The network resource partition, or called NRP, is a set of network resources allocated on a connected set of links in the underlay network, and this concept was introduced in the RFC 9543, the network slice framework. An NRP can be used to carry or support one or a group of network slice service or enhanced VPN services as described in the RFC 9732. So this document introduce a new hop-by-hop option to carry this ID called network resource related information including the identifier of the NRP in the IPv6 packets, so that it can be used by the transit nodes to determine the NRP a packet belongs to, and NRP specific packet processing and forwarding can be performed on each hop along the path. Also this hop-by-hop option is extensible so that it can be used for other network resource related semantics and functions in the future. So this is the— the latest revision is to address the comments received during last IETF meeting and also after the meeting on the mailing list. So here is the encoding of this new option. It is a hop-by-hop option for the network resource related information. The format has been stable for a while and there are already multiple implementations which proved its viability. We can see it basically has a flags field and currently we have the first flag defined to indicate whether it’s a strict match or when there’s a— no matching ID in the transit node, what it will be the behavior. And the context type field is to indicate the semantics of and the length of the NR ID in the end of this option. When the CT field is zero, we call it a four-octet network-wide NRP selector ID. And it can also be used for other semantic functions when you define a new context type. So here are the discussions happening during the last IETF meeting, also on the mailing list. The first thing is whether we should generalize this option for more semantics or it just to to keep it for the NRP or network slice case. And the feedback is that due to the limited number of the remaining hop-by-hop and DOH option code points, generalization may be needed in the future, so we can reuse this field for other related functions and semantics. And the current encoding leaves room for this kind of future extensions. And the second thing we discussed on the list is the— whether what would be the length of this identifier in the IPv6 data plane, especially when used for the NRP selector ID. There was a comment about whether we should provide a lightweight encoding with a shorter NRP selector ID. Well, we think the majority of the feedback is to make the ID length 32-bit. because this can provide us a single encoding that can be enough both for the current use cases, but can also support the use cases in the future. We think if a different encoding is really needed, maybe it can be specified in a future document by defining a new flag or a new context type, which is allowed with this current encoding. And in this draft we also add some text about the management of the NRP selector ID in the deployments, and to provide some suggestion about how the NRP selector ID should be assigned and and managed to allow the easier interoperability. So here is the updates in this version, it's just we add some suggestion about the NRP selector ID allocation in deployments. Okay, for the next steps, I think we would like to request for the working group last call because I think all the comments have been addressed, and the code point early allocation has also been requested, which would be useful for the interoperation between different vendors. Okay. Thank you. 

**Greg Mirsky:** So we have Greg in the queue. Yes, thank you. Um, so as I understand, the TEAS working group defined different options for NRP selector length. And in MPLS data plane, there is— in MPLS working group, there is a proposal using MPLS network action to support the different form sizes. So should that in IPv6 be the same capability of expressing a different spaces, not only 32 bits? So I think that if what you propose, if you can go back to the format that you propose for the extension header? Yeah. Yes. So what length signifies here? 

**Jie Dong:** Sorry, can you repeat? 

**Greg Mirsky:** So the length in this encoding, it signifies the 32 bits, or it signifies that the NR ID length? Because as you— as reflected in this case, one can assume that the proposal is only for 32 bits. But TEAS working group defined different lengths of NRP selector ID. 

**Jie Dong:** You are talking about TEAS or MPLS working group? 

**Greg Mirsky:** No, I'm talking about TEAS. 

**Jie Dong:** Yeah, but TEAS didn't give any specific suggestion about the length of this ID, just said a minimum should be— 

**Greg Mirsky:** No, I think the TEAS clearly gave several options of different lengths. 

**Jie Dong:** I don't think so. That is— the options was provided in the MPLS encoding, but that is not what TEAS proposed. TEAS— what TEAS said is the encoding and length of the ID is subject to the protocol specific data plane protocol like for IPv6 it's belongs to 6man to define. 

**Greg Mirsky:** Right. And TEAS suggested several lengths, and MPLS working group using MNA, MPLS network actions, allows for that. So I think that it will be helpful if in IPv6 we have the same capability, which will simplify the mapping between IPv6 and MPLS domains, if that needs to be. 

**Eric Kline:** Yeah, let's take this discussion to the list. 

**Greg Mirsky:** Of course. Thank you. 

**Jie Dong:** Yeah, my quick answer is this encoding allows you to have other lengths defined in the future, just 32-bit is the length what was being discussed and agreed in the mailing list and in the previous meeting. 

**Greg Mirsky:** Okay, that is good. And I think that it will be good if the document explains how that can be done. 

**Jie Dong:** Sure, we can do add some description about how this can be extended. 

**Jen Linkova:** Okay, yeah, thank you. So I guess yeah we can continue this on the list just for sake of time. Erik. 

**Erik Vyncke:** Ah, yeah, I think I'm was feeling very much the same as what Greg was just saying. I think I recall from earlier in the week at the MPLS meeting, they were talking about how big these IDs should be in their data plane, and 32 bits was proposed to be too big, and that maybe it should be something smaller. Regardless, it feels like this shouldn't be a decision that 6man should make. It feels like it should be a reference to some other document from some other working group and we just say, "Because we have a flexible length for the option type here, we just prefer to somebody else that defines what that value should be." I don't— it just feels weird that we're like weirdly choosing a value for for something that's not originating from this group. So, but thank you. 

**Eric Kline:** Adrian. 

**Adrian Farrel:** Adrian Farrel. I'm MPLS co-chair and I'm technical advisor to TEAS. So, as far as I'm aware, the IP data plane, the IPv6 data plane is not MPLS. This is a data plane encoding to carry a piece of information, and the MPLS working group is also doing a data plane encoding to carry a piece of information. Neither of them is limiting any of that. The TEAS working group has said, "You need at least eight bits." I reckon eight fits into 32. So this working group just needs to work out: how can we carry a lump of data around? All right, we're done. 

**Jie Dong:** Thank you. 

**Jen Linkova:** Okay. So I guess yeah it looks like some more work here is needed if I understand the discussion correctly. We’ll continue discussion on the list. Thank you very much. Next presentation is node requirements, Tim. Tim, can you try again? Yeah. Yes. So, but I'm not giving you control, right, or you getting it? You can do it either way. If you want to control it, that's fine. Yeah, I can control it, it's easier for some reason, yeah. Okay. 

**Tim Chown:** Okay, so to catch everyone up, this is IPv6 node requirements, this is the third revision we're trying to get through of this, so this is [draft-ietf-6man-rfc8504-bis]. I think we've presented on this three times to the working group. It's a working group document as well. You can go to the next slide. Thanks. Okay, so we didn't get a revision out before, the authors were a little slow, we apologize. We didn't get a revision out before this IETF, but we do have, I've documented everything here, the bullet points for the changes we want to make to 03. So we're going to make them right after this meeting. We figured at this point we might as well wait and see if anybody had anything additional they wanted added or other things to work out. So 03 changes. The first one there is for SCVB to added, it's part of the DNS section, we had a request for that. So we're going to do that. Add 9872 to the translation prefixes. We had a discussion on the mailing list after the last IETF. It started in the last IETF, went to this. So we're going to add, I think it's a should statement for that one. 6724bis, this is, you know, this is you saw earlier was on the 6man docket of things in the editor's queue. We need to update our text to match that. We just been waiting for that document to go through. So it's not blocking us, we're not done yet, but it something we need to actually do. The fourth bullet here is about our one of our favorite subjects, PMTU. So for this one, Gorry sent some comments on list, and this is what we're adding, some additional text for 9868 and saying, "Hey, there's another document here you should do this as an additional option for MTU." So that's that one. While Gorry was looking at that, he noticed an interesting oversight: we don't have any mention of DiffServ for the DSCP section. So there's a couple of edits in the ECN and we want to add DiffServ as a reference to the DSCP section. So these are all relatively, I think all of these have been discussed on the mailing list, they are just the updates we need to make. And then we have a couple bigger items next we need to talk about a little bit. So go ahead, yeah. So, 8504 added text for a little bit of protection for extension headers, excessive extension headers in particular. We, when we started this draft, we removed some of that text and updated it to talk about EH limits. Since then, that draft has become dead, it's no longer being worked on. So because of that, we were kind of in a, not a tricky situation, but we're, we have to figure out what we want to do. So what the authors have discussed, and, you know, I think later on Tom is going to present on some of the EH stuff, so we'll obviously be listening to that, but this document's, you know, getting towards the end of our how many revisions we want to make. So we think the best move forward is to go back to revert to the 8504, the original text the working group agreed to when 8504 came out. And so I mean, obviously if there's a discussion and a clear direction, we might do something different, but right now, um, we think that's the most prudent step to take. So we're going to revert that text back to the 8504 text with no other changes to it is the current plan. Next slide. Yeah, so we have a couple of references we have to update. These are pretty straightforward. We have to— DHCP became an internet standard, so 9915 we have to update. CE Router is going to working group last call after— this meeting, there was a couple of updates, but that one will get done before this one, so we should just update— we don't say anything great in this document about those, well DHCP we have a lot to say about, CE Router we don't, other than pointing people to it, so we'll just point them to the right document, which is good. Next one. So these are the three that we have left over that are, I'll say, newer and very new in these cases, they're all fairly new in the V6 space. Right now there's no references to them. I don't think we'd want to make any of these super normative, it might just be, "Hey, these exist in the world," and we wanted to get working group feedback. So neighbor discovery considerations, registering self-generated address, and the last one, you know, the working group talked about earlier was SLAAC-RENUM that I think we, it sounds like it's going back to the working group. Again, I think if that document gets turned around quickly, I, I don't think that should prevent us from mentioning it in this document as something we can support. So we're going to keep an eye on that one. I think our intention is, depending on when that document lands, is to incorporate that unless someone in the working group thinks very differently about that. We should hopefully know more about that in a month or two. Okay, so I think we're closing in. I think if we do all those 03 changes and wait for a couple of documents that are already in the queue, I think we're going to be ready for working group last call definitely before the next IETF, would be our goal here. If not, to have the working group last call ready for IETF 126 is currently where we're at. The noise around this document has sort of died down a little bit, so I think that's a good sign for us to be able to push this document over the edge. So that's kind of where we're at. But if there's any questions. 

**Jen Linkova:** Any comments, questions, suggestions? What else do we want to require from the node? No. Okay. 

**Eric Kline:** Listen, what I wanted to say is it makes the the dependency that this introduces makes it even more urgent to clear these MISREFs, the 6724bis MISREF in particular. Because it would be a real shame if this got hung up on a MISREF. 

**Tim Chown:** Yeah, no, we we're trying to be careful to avoid that for sure. Um, and the one that we have to include is default address selection that's been hanging out for a little bit. So we'll have a move for that one. 

**Eric Kline:** Yeah, when, when we get to the point of doing working group last call, let's take a close look at that and see what MISREFs there might be and because yeah we we don't want it to be sitting around for years. 

**Tim Chown:** No. Agreed. 

**Erik Vyncke:** Just quickly, I think that you would want to refer to RFC 8899 for datagram PLPMTUD and not just 9869. 

**Tim Chown:** Okay. Thank you. Yep, we'll take a look at that. Thank you for that. There I have the direct— it's in the issue, I have the text that we were going to change, I will confirm that we get that right. Thank you. 

**Jen Linkova:** Okay. So we joined the queue. So thank you Tim, we look forward to the next revision. Now let's have some fun. We have a presentation for which the author— co-author— could both of them could not be here. So I'm gonna present the draft. 

**Eric Kline:** Oh, they, they're not here? 

**Jen Linkova:** No, no, no, they— they have both found something much more interesting called routing security. So they all— they both there. So I'm gonna pretend I am Warren or Jeff, whatever you prefer. It's gonna be interesting, I'm going to present something I'm not completely agree with. So let me try. Because the purpose here I guess to raise some awareness in the group, make sure people pay attention and express their opinion, because it's a very short draft, so easy to read, easy to have opinion. So, there is a draft which been posted recently. Yes. Yes, I see comments in the chat. Yes, not my slides, right? That's why it's not in Comic Sans. So, what this draft is proposing is that we currently have a single address for loopback in IPv6, but in IPv4 we have much more, and apparently some applications even trying to use it in IPv4. For example, I was told that some applications could— like in some cases developers run multiple copies of the application, all binding to different addresses on loopback, sending some traffic and like doing some testing. So apparently proposal is to have a bigger loopback prefix in IPv6. And so it could be used for, yeah, purposes like that. But actually I don't think we need to actually go into use cases if I understand correctly. The proposal is just to ask IANA for a bigger prefix, which will be actual loopback prefix. Yeah, so the packets are supposed to be sent to the loopback interface and back, so kind of exactly copying the behavior of ::1. The draft currently propose ::/96, and I’ll have personally comment on that after. Because, yeah, because of this slide. So the problem with the current proposal is that it's gonna include unspecified address, which is I think very much different from loopback. So the draft is— draft currently has some text about that, and yeah, and it suggests some special treatment of unspecified address versus the rest of the prefix. So, the draft actually discusses other potential candidates for that prefix, right, and but I think we need to again separate the problem statement: "we want a prefix for loopback," from specific suggestion about which prefix to use, right? Because I think we can discuss it separately. So, again, I'm sorry, I'm— I just read this draft again this morning, I just first time I see those slides. So, it would be really nice to hear the working group opinion, and I'm going to hijack the queue and just say that I do agree with problem statement that it might be nice to have additional prefix, but I definitely very much dislike the idea of mixing it with unspecified address, because unspecified address has completely different properties. And if the only reason for having— for suggesting this prefix is to include the actual current loopback, ::1, I guess it should not be a problem, we probably need to get a ask IANA for some nicer prefix to be like to be used as loopback. So, I’ll shut up here and we can open the queue. Eric. 

**Erik Vyncke:** So Warren or Jeff, why /96 and not /64? Not it's really to copy the 32 bits of IPv4, right? 96 it is. 

**Jen Linkova:** I— again, I'm just a messenger. I'm not going to answer any questions here, right? Because I— I might can just let my imagination runs wild, but again, Erik, I my understanding is actually it's not on the slides yet, I forgot, thanks for reminding. Authors asked for adoption call, right? So I think what we would probably should focus here is that do you think it's worth adopting and talking about what exact prefix we want later, right? Because we all might have like different prefixes, different preferences on how that prefix should look like, right? But I think it's implementation details versus do we actually want a new prefix. 

**Erik Vyncke:** Fair enough, thank you. 

**Jen Linkova:** And you are in the same building with Warren and Jeff, so you can find them and ask them why /96, or ask it on the list. That's obvious by the way why /96 because if we still have the IPv4-mapped IPv6 address space which is ::ffff:0:0/96, so you have to stop it, you couldn't include that if you go larger than /96. 

**Eric Kline:** Only if you use this specific prefix. For general prefix use /64, right? If we talk about some other. Okay, cool. Brian. 

**Brian Carpenter:** Yeah, I think there's an underlying question here. The word loopback does not describe most of the usage of this space. It's just a carry-over from from some very sloppy thinking in IPv4-land when they discovered this block of address space which they could use to label interfaces because it was otherwise free, and they started calling it loopback when it was really, you know, addresses for virtual interfaces. And I don't see why the IPv6 community would just automatically take that over, that sloppy thinking, because it makes a few things more convenient in the code. So I have a fairly strong feeling that the premise of the whole thing is not properly described in the document. And once you get that description fixed, I don't understand why it needs to be called loopback space rather than extra space for virtual interfaces. And I don't understand why it matters at all where it is in the unicast space. I mean, it could be anywhere in the unicast space as far as I could see. And I'm worried, I think Jen is as well, that putting putting it into a place where it actually overlaps with the unspecified address is just inviting bugs and unfindable operational mistakes because people getting the two functions confused. And in this case we'd actually be getting three functions confused, two of which are called loopback. That's all I wanted to rant. 

**Eric Kline:** Okay. Ron. 

**Ron Bonica:** I think I might be saying the same thing Brian just said in a different way. Today I can assign multiple addresses to loopback. If I want, I can put them in the same prefix, and I can advertise that prefix into the IGP as a prefix as opposed to individual /128s. Given that I can do all the things that this draft might enable in the first place already, what advantage is there of making this semantic global as opposed to just something I do inside my network? I'm not seeing why the draft is really needed. 

**Jen Linkova:** Sorry, could you say that again? 

**Ron Bonica:** My— my understanding is, from reading the draft, that the purpose is to make sure those packets never leave the host, right? They never appear on the network. 

**Jen Linkova:** Sorry, could you say that again? 

**Ron Bonica:** I— my understanding is, again I am assuming, that the purpose is to ensure that a dedicated prefix is needed to make sure those packets never leave the host, right? They never appear on the network and if for some reason they do, it would be easier to filter. 

**Eric Kline:** Okay. David. 

**David Schinazi:** I think this is also going a little bit in Brian's direction. The draft doesn't say specifically how these addresses behave for the local network stack. And they will differ on most stacks in that they are not actual addresses on the loopback interface if the network stack has these things. So if if that is added as description, I think this also makes more clear what the purpose here is and whether this makes sense or not. So it just needs more details. 

**Eric Kline:** Lorenzo. 

**Lorenzo Colitti:** Yeah, I I do think there is value in— there's there's value in loopback address especially— okay, so supporting loopback address especially doesn't have a lot of cost because we have to support ::1 indefinitely because it's whatever, in you know whichever, you know, it has been there in the since the nineties, right. Extending the space does seem useful. I've seen a lot of code that basically in IPv4 can use different loopback addresses. You can run stuff on loopback, you're guaranteed to be able to run stuff on loopback on multiple addresses on the same port, and you can't do that in IPv6, and it's something that, like, occasionally causes problems for porting stuff. Um, it seems funny that, you know, given the amount of address space that we have, we can't have more than one address. It's sort of ironic, right? So I think um there is an like you know IPv4 has like all of this bountiful like you know /8, right. It there is a there is one thing that's valuable about using the proposed prefix is the existing loopback address is already inside it. And so we can just have one block which is loopback block and you can say this block is just well-known. I mean, I do think it needs to be well-known and and we already have a well-known block, it just happens to be a /128. So, you know, I guess another way of putting it is if we were to pick this block, we would only have, you know, kind of one block of loopback addresses and of course yes, the the zero address would have to be inside it. Um, it may be worth mentioning that in that in um that on certain stacks like BSD-derived stacks, connect to 0.0.0.0 actually means connect to loopback. Um, yes this is implemented in, you know, for example in the Linux stack. There's like like there's actually lines of code for that. So, um, that's obviously not a possible to implement so there's some history there where. Um, I don't have very strong feelings. I do think this is useful, and yeah, I don't have very strong feelings on the prefix. Um, that's a great bikeshedding opportunity I'm sure. 

**Jen Linkova:** Suresh. 

**Suresh Krishnan:** Thanks Jen. So I think what I'm going to say is like total speculation, but I'm going to say it because both Warren and Jeff didn't turn up. So one of the things the loopback block is used in V4 right now is like when IANA comes up with a new gTLD, right? Like so imagine like there's some random stuff you're trying to resolve and it's going to become a proper gTLD, they return a record with 127.0.53.53, right? Like so um then like somebody will figure out like "hey this foo.bar I'm resolving which resolves to nothing could get resolved to something else," right? So if you want the equivalent V6 functionality this could be useful. So just to answer like David, right? It's not clear what the goal is, but that could be one use in addition to all the other uses people identified. I'm not saying that's a good idea, actually I'm not saying it's a good idea for sure, but like I think that could be a potential use for a larger block in addition to all the other uses people identified. Thanks. 

**Erik Vyncke:** So I know that the queue is blocked, but just to reply to my dear friend Suresh, IANA changed their mind. This may be not public yet, right? But talk to Andy Newton, the ICANN AD, he just told me yesterday— okay, it was at the social so we get both get a drink, but he said that ICANN stop this proposal. They will only do what they call controlled disruption in delegating the zone only on IPv4, not on IPv6 for until something is coming out of 6man. So there is no real urgency anymore to fix it. 

**Eric Kline:** Okay. Thank you. So I think we're— I think we're done on this for now, and at least my take from the discussion is I don't think we're ready for doing adoption. I think the draft needs to be clearer about what it's intending to do. 

**Jen Linkova:** Yes, that's my feeling as well. So I guess we'll ask the authors to review the recording, and we'll I'll convey some of the messages from here, and it looks like at least the new revision will be needed and then we can talk about adoption. Okay. Right. Thank you, Bob. So the next topic is equally exciting exciting. Tom is going to talk about deprecating IPv6 extension headers. Okay let me stop slides. Tom, are you online? 

**Tom Herbert:** Yep. 

**Jen Linkova:** Cool, do you want to get control of the slides? 

**Tom Herbert:** Sure. Would you present them or? 

**Jen Linkova:** Okay I can present them, no problem. I just ask if you want to present or I can present. 

**Tom Herbert:** Oh no. 

**Jen Linkova:** Okay. Hold on. Here we are. 

**Tom Herbert:** Oh, there they are. Okay, so I'm going to talk a little bit about some work that I've been doing and actually with Justin Ormont. There's actually four drafts here even though the headline was three. So we added one that Justin had been working on, so I'm working on with him, working with him on that now. So the problem, I think it's pretty well known in the working group, the story of extension headers. Originally they were defined, very few restrictions and there wasn't a lot of thought to security, obviously 20, 30 years ago. It was a different world back then, but now we know that there's a lot of security issues and especially on the internet. So we're looking at ways to to mitigate the issues. And also it's also well known that extension headers are dropped at high rates on the internet. And as Tim said, there's no fix for this on the horizon, EH Limits didn't make it. So the net effect is extension headers, at least in my opinion, are probably more of a security liability than a benefit, especially on the internet. And that's pretty much what we're going to focus on today. So the first draft that I want to talk about is pretty straightforward. We want to enforce the number of occurrences and the ordering of extension headers that is recommended in RFC 8200. And if you look at the text, it's actually highly recommended that sending hosts abide by the order and the number of occurrences. So the order is well-formed, number of occurrences, all extension headers can be sent once except for destination options. So we want to, or proposing, that we would allow both host and intermediate destinations through the routing header to enforce the ordering. So if they are enforcing ordering and they receive a packet that violates either the ordering or the number of occurrences, then they would drop the packet and they may send an ICMP RFC 1883 sort of message. It's pretty obvious why this is needed. RFC 8504, for instance, like Tim said, has some mitigations for extension headers, but those are primarily for destination and hop-by-hop options. This one is really for all the extension headers. So someone could load up a single packet with a bunch of fragments, routing headers, destination options, what have you, and that makes for a great denial of service attack. So the idea here is we want to limit that and constrain it. And since RFC 8200 already kind of highly recommends it, we think it's a pretty clean fix and an update to RFC 8200. The next one is what I call obsoleting extension headers on the internet. So this goes back to the high loss rates that we're seeing on the internet and the fact that with these high loss rates, it's unlikely that we could ever actually define any meaningful extension headers. Now security-wise, ESP is okay since it's secure, but the other ones are fundamentally insecure, especially to receive off the network. So hop-by-hop options and routing header, pretty obvious why those are really risky to accept into a network from an untrusted source. They target the network infrastructure. So something like routing header, for instance, it's explicit that SRv6 must be constrained inside a routing domain. And then hop-by-hop options, they have a similar property. So hop-by-hop hop-by-hop options potentially target network infrastructure. So this probably pretty well known and and done regularly today is to drop those, prevent them from coming in the network. Fragmentation, the issues are well known and I think that accepting fragments from the internet is also pretty risky. I think that's generally understood. AH basically obsolete, so we don't have to worry about that one. So the only one that really leaves to consider is destination options. So destination options, they are end-to-end information. And the belief is that they are— since we're sending plain text— that in itself is a risk. And this is particularly going to be problematic when we're using a secure transport layer such as QUIC, where QUIC goes out of its way to encrypt as much of the packet as possible. If we turn around and are using destination options, basically that's a way to to kind of undermine the security of QUIC. Now there is a counterargument that destination options may have their own security, and that's true, but the problem with that is that doesn't prevent somebody from inserting random destination options in the path, and they can do that without really any detection. So we think that disallowing destination options from the internet, considering that there is risk to it and there's really no well-defined use cases for it, is reasonable. Okay, so that's the first two. The third is more of a mitigation for the first one. So if we're dropping extension headers on that we're receiving from the internet, then that also means that source can't really send them if the destination is to the internet. And the problem becomes that we may want to use something like hop-by-hop and routing header from the source to the egress router of a limited domain, and then when it gets to the internet, we want to basically remove those headers from the packet. So this idea, I did present on 6man, I think it was a couple of years ago, and I think it's a good mitigation if we allow these egress routers to basically drop hop-by-hop and routing headers. So hop-by-hop can be dropped basically because RFC 8200 now makes it somewhat optional for nodes to process them. So if you drop it, nobody's really missing anything. Routing headers make sense to drop if we're at the last node in the list, and the routing header really is inert at that point. So the idea is when a packet comes to an egress router, we would look and see if there's a hop-by-hop option and a routing header with exhausted list, and if there is, we can optionally remove those from the packet. Now this is obviously contrary to RFC 8200 that says we're not allowed to remove extension headers in flight, but one of the nice points about this is unlike inserting extension headers, which can cause MTU problems because when we insert an extension header in flight we can actually increase the MTU above the minimum MTU and then the whole flow becomes basically untenable. In this case, since we're removing data from the packet, we're not actually increasing the MTU so we think the MTU problems that insertion would cause are mitigated. The last one, this one might be a little more controversial because there is some nice work on using destination options before the routing header. But what we noticed was, if you recall back a couple years ago when SRv6 was being developed, segment routing header does have its own options. So instead of using destination options for segment routing, they put options within the routing header. And that actually has some interesting advantages because now we're locating the routing header options with the routing header itself. If we put options in destination options before the routing header with the intent that these affect the routing header, then we're kind of distributing information, decentralizing it. We're requiring forward-looking information. So for instance when we're processing routing header or destination option headers, until we get to the routing header we don't actually know they're destination options before the routing header. So if there's information in there that might be useful to a potential routing header, somehow we now have to either save it or when we get to the routing header we may have to go back and process the destination options. So it's a little bit messy implementation-wise. Um, so I would say this one if we can do it, it's a nice simplification. It also helps the the first draft that we proposed in the number of occurrences because this would basically say that all extension headers can occur at most once per packet. Fewer moving parts, it's simplification and like I said, it avoids the the ambiguities and forward processing of destination options before the routing header. And that is all I have. 

**Eric Kline:** And we have three people in the queue. Lorenzo. 

**Lorenzo Colitti:** Go. Uh, for fragmentation, we can't deprecate it without saying there is no path to working DNS on the internet, because DNS relies on fragmentation. I think that's that's not even a protocol issue, it’s an operational issue, it’s needed today and it by and large it does appear to work, or it works in a lot of places. So I I don't think we can deprecate that. Um, nor can we drop it. Um, there's other stuff that is unused. I do like the point around, you know, plain text stuff in the packet should not be used to communicate data. It should really only be used to communicate sort of operational stuff that really needs to be in the sort of like IP layer, of which there is not many. Um, HBH is used locally for for MLD and things like that. You're not proposing that we deprecate that on the internet. But yeah, fragmentation we can't get rid of fragmentation. 

**Tom Herbert:** Makes sense. Uh, do you know what the drop rates are in fragmentation? I thought that that was still non-zero also. 

**Lorenzo Colitti:** I think if you if you, you know, I think this is something that we could sort of maybe do using some RIPE Atlas probe or something. I mean, I think if you talk to a well-known DNS server like 8.8.8.8 and and you send it fragmented queries, I think for like large parts of internet, it will work. 

**Tom Herbert:** Okay. 

**Lorenzo Colitti:** So I, you know, that’s something we would test, but yeah. So I think I know also we can ask the operators of DNS servers what happens when, you know, operators drop fragments. I think they notice, so. 

**Tom Herbert:** Well, maybe if it's ingress that that could be controlled at just the DNS servers, but I still imagine that um basically uh cloud providers and such might be motivated to actually drop drop packets with fragment fragment headers. But of course, you know, we'll have to see the data on it. 

**Eric Kline:** Okay, David. 

**David Schinazi:** David Schinazi. Um, first the part that I do appreciate about this is that we're acknowledging the fact that the network boundary exists and there's firewalls that drop these things, which I don't think we have done enough until this point. Um, however, um specifically for destination options, one, I don't understand what the benefit and actual even impact is of saying it's deprecated on the internet. Like that is a different perspective than saying a firewall or other devices exist that will drop these things. It is also a different thing from saying these boxes are allowed to drop these things. Like, it's it's unclear what is the actual effect of. 

**Tom Herbert:** Well, okay, so the the name might be a little strong. Um, everything's optional, but the problem that I see is we're what, 30 years into this and the loss rates of even destination options, they're still well over 10%. And if I'm an application developer, that that makes it not usable. And the problem is if we persist in this mode where it's allowed um and we don't acknowledge these drops, the longer we go the the greater the chance it becomes a security risk more than anything. There's no serious application use of it, but do we want to continue to allow it just in case somebody ever figures out a use for it and they fix the problems of the dropping, when if on the other hand it still is a denial-of-service attack vector. So obsolete may be a little bit strong of a word, and everything's optional, but the thing is, if it's optional to drop on the internet for anyone, then from an application developer point of view, if I want it to work everywhere and anyone's dropping it, basically means it's unusable to me from an application point of view. So it's kind of like it's it's all or nothing. It's hard to have something that only works halfway and get beneficial use out of it. 

**Eric Kline:** Okay, so we we are out of time, so let's get through the rest of the queue, but just let people talk and then we can take the discussion to the list. So, Ron. 

**Ron Bonica:** First I'd like to support the first draft. The ordering and number of occurrences in 8200 should be "musts." Next, I'd like to oppose all of all of the other drafts. Um, everything that comes after the routing header, AH, fragmentation, destination, is a conversation between two consenting IP layers: the one at the beginning of the path, the one at the end of the path. Um, intermediate nodes have nothing to say about those options, they shouldn't even be looking at them. If they drop them, shame on them. 

**Tom Herbert:** Okay, but they shouldn't, but the problem is they do, and that's why, but they do. It's security, right? 

**Eric Kline:** Okay but Tom, let's not let's not have the debate right now, we're running out of time. 

**Ron Bonica:** Yeah, and if you feel that the information in those is sensitive, then it should use encryption. The next is for the draft that removes RH and HBH from a packet. I believe a middle box has no business removing things from packets because it may change the semantic of the packet. A middle box may drop a packet if it doesn't want to forward it because it feels that it harms its infrastructure, but it has no business changing the semantic of a packet. 

**Tom Herbert:** Okay. 

**Eric Kline:** Let's get to the next person. 

**Speaker 13:** Yeah, the if you do allow the removal of headers at say the edge of a limited domain, uh there's an unfortunate interaction with probe packets with PLPMTUD or its datagram version and uh that should at least be noted. 

**Tom Herbert:** Okay. 

**Tal Mizrahi:** Tal Mizrahi, Huawei. So I just want to go back to the destination options and I wonder if there's any up-to-date data out there that actually supports the destination options are being filtered. And I think even if 10% of the routers or middle boxes are filtering destination options, I don't think that means we need to deprecate. If anything, maybe we need to make sure that if implementations are doing the wrong thing, maybe they need to change and they need to do the right thing. 

**Tom Herbert:** Well, we we did try that with EH Limits, but that was um that didn't go very far, so uh if if it fixes itself, that's great. But I haven't seen the data that shows there's any movement and it doesn't seem like there's a real plan to fix it. 

**Tal Mizrahi:** Thanks. 

**Eric Kline:** Well, it would be good to get more data. 

**Jen Linkova:** Okay, so I'm gonna abuse my power with one comment just as individual and one comment as a chair. So, I second Lorenzo point that drop rate will actually depend on what you looking at because to and like from DNS servers, for example, I permit fragments. I might not permit them from random destinations. So when you measure that, you need to be careful uh because yeah, you might measure some like average which actually doesn't represent actual user experience. So, with the chair's hat on, draft about deprecating them on internet. I'm a bit confused because it looks like what you describing is a filtered policy, which is operational concern. It should be— it's not a protocol change, I believe. It should be up to the limited domain operator to decide what they filter and what they not. So I'm not even convinced it's actually in scope for 6man. Maybe I'm wrong, so I'll if my co-chair or responsible AD disagree please let me know. 

**Eric Kline:** All right. Well, Tom, thank you. I think we're done, I think we can take this to the list. I don't think we're ready to adopt these. There did seem to be support for the clarification of the the option and order, so we should take a look at that, but um we can do that afterwards. Thank you. 

**Jen Linkova:** Yeah, thank you, Bob. So the next, we'll talk about DNS64 functionality in RA. Chenhao, are you online? 

**Chenhao:** Hello? Hello? Hi, Bob. 

**Jen Linkova:** Yes, we can hear you. Yes. 

**Chenhao:** Okay. Uh just a Chenhao from China Telecom on behalf of authors to present this updates to DNS64 functionality advertisement for DNS RA option. Uh, first was— what’s new in this version. Uh we got clarity of the problem statement. In this revision, we have added detailed use case to illustrate some deployment scenarios and clarified the relationships with existing technologies. Uh we hope this ah to be avoided being understood as a replacement. We hope these additions make the intent and applicability of the proposal clearer. Uh use case one is coexistence of IPv6-only and dual-stack users on the same network. Uh some operators may wish to gradually migrate users from dual-stack to IPv6-only without relying on APN isolation or separate network slices. So in this scenario, IPv6-only users require DNS64 to access IPv4-only content while dual-stack users will should continue using standard DNS. Uh if both user groups share the same network, the operator needs a mechanism to selectively provide DNS64 server addresses only to IPv6-only hosts. Use case two is phased roll-out of DNS64 service. Uh some operators often roll out a new service gradually to manage risk and validate the performance. Uh so with RDNSS alone, all users receive the same DNS server addresses, so this will make the phased roll-out difficult. Uh so this solution is allows operators to control which host receive DNS64 resolver information based on the network policies. Use case three. Uh multiple DNS server tiers with different capabilities. Uh we have deployed have DNS standard DNS and DNS64 capable system deployed in our network. So with RDNSS alone, all users will receive the same DNS. Relationship with PREF64 option. Uh I know this is very you familiar with this draft. Uh prefix64 option enables host-side synthesis and DNS64 option enables network-side DNS64 selection. Operators may choose to deploy prefix64 alone, only, or DNS64 option only, or both. Neither option replaces other, they serve different operational needs. Relationship with RDNSS. Uh so this is this is a standard mechanism for distributing DNS server address. Uh so IPv6-only hosts can cannot distinguish DNS64 capable resolver from standard ones. dual-stack dual-stack hosts may unintentionally use DNS64 resolvers increasing load on NAT64 gateway. Uh this is a example we want to introduce a T flag to indicate that the DNS is DNS64 capable. Uh what's next? We would thanks all the authors who have provided comments and feedback, and to move this work forward, so we will seek broader input and contributions from working group and and and we want to know it's ready for the working group call. Thank you. 

**Jordi Palet:** Jordi Palet. I am not really convinced about the need of this. Um, basically I could copy my email to yesterday V6OPS regarding the other document that you presented, and I think there are sufficient tools in 3GPP specifications uh to to do this without the need for for an extra flag or whatever. Um, I am not opposed, but I really think it's not necessary. Maybe we need to clarify what are the differences that you see in your 4G versus 5G deployment as I just responded earlier this morning. And see what, if something is missing, what is missing to to achieve that. The reality is that I have done mobile IPv6-only deployments in both 4G and 5G, and I didn't encounter the problems that you are having. Uh basically the point was a single APN, and the devices are able to negotiate uh an IPv4-only PDP context, an IPv6-only or a dual stack, and both both all them can perfectly work with just a single APN, so you don't need that APN isolation that you are looking for. Um, even more, the DNS64 server could be configured to exclude for the DNS synthesis to specific clients in different ways. So again, you don't need a flag because it can be done as per today existing DNS servers, at least the one I am more used, Bind, you can do by several ways: ACLs, RSPL, um not RSPL, RPZ zone, I don't remember the name of that protocol, but there are there are different different ways. It's true, and I sent a message a few minutes ago to both V6OPS and 6man, that we have a problem with Apple, but that's a specific vendor problem, not a protocol problem in my opinion. Thank you. 

**Chenhao:** Thank you. Uh I will give a response you. Uh actually we have we have deployed the DNS standard DNS and DNS64 system deployed in our network. That’s maybe three years ago, at that time we we all think the method way to do IPv6-only just use the SLAT and DNS64, so we we did we did that. And now the I I know that the in IETF must think will use the prefix64 and other ways to do that, but we we want to use our already deployed the the systems. We won't we don't want to waste it. So this is our one one reason to do that. 

**Jen Linkova:** Yeah, hi. I read the draft and even after your presentation I'm still very much confused, so maybe you can unconfuse me. So most of your use cases repeat that you are going to send this new option to some types of clients and the other RDNSS option without this flag set to another type of clients. So why do they need the flag then? Why you cannot just send— why you cannot send one type of clients DNS64 addresses and to other clients like normal addresses? So I think we need to better understand what exactly the clients are supposed to do when they see the T flag, because I don't think it's clear from the draft why they need to know if this server is DNS64 or not. Right? It looks like you already have an ability to provide different clients different DNS servers, so I guess you can provide them once servers which they need, so DNS64 for IPv6-only clients and normal DNS to normal client. So behavior of T flag is not specified in your proposal, so I am not sure how it's going to be used. 

**Chenhao:** Just want to clarify that this is an option, not the the only way to achieve the you said the achieve the deployment. 

**Erik Vyncke:** Chen, it looks like you are frozen. No, no, I'm just listening, I'm just listening. So well, I guess we can take it on list, but as I said, yeah, okay, we need to clarify what exactly this option does. I guess Lorenzo is next on the queue, I'll remove myself. 

**Lorenzo Colitti:** Yeah, I I don't see an operational need here because um the the operational scenario we're talking about is that the carrier or the the network operator is able to control what RA options it sends to a given client. Um, if the operator is able to control what options it sends to any given client, then it can simply like either send the DNS64 option, sorry, the DNS64 servers, or the regular servers, the dual stack ones, the ones that don't do synthesis. So this what you want to do is already possible today. And this solution that you're proposing requires that the operator can already do can already do it this other way, whereas your solution also requires hosts to change to understand this new option. So so again, what you're trying to do is possible today, the operator can just control the RA, the addresses that it sends in the RA. And the other thing is I don't understand is like, why would the host care if the server if a DNS server is DNS64 or not? You're talking about something that requires the host to write code. The host can easily detect whether a DNS64 server is a DNS64 server by just doing a DNS lookup and seeing if the address is synthesized. So it can like do a lookup for `ipv4only.arpa` and see if it gets a V6 address. If it does, then it's a DNS64 server, if it doesn't, then it isn't. So it's not clear whether even, you know, why would the host even need to know this. So one thing I would uh you you might have more success if if you believe there's a real there's an operational need here, you might have a somewhat more success trying to convince the operational community, let's say in V6OPS, of what that operational need is, and then if there is consensus, then you could come to 6man and and design a solution. Uh but right now I'm not seeing it. And the other thing is like many operators have already successfully rolled out IPv6-only in many countries without needing this option. So that's another reason why I think, you know, there's already ways to do what you want. No. 

**Chenhao:** Okay, I got it. I will get a consensus from V6OPS and have I will take the question to there. All right. 

**Eric Kline:** Yeah, I would wanted mostly to say the same as Lorenzo said. Uh, it's um I don't think that this particular solution actually is a good solution for the use case you have and that the use case you have can be much better implemented with existing stuff. Also, the chance of getting this idea deployed in major operating systems is pretty low and takes a lot of time. So either you have a different use case where this really makes sense, or I would really suggest that um to look into the existing options. 

**Chenhao:** Okay, thank you. Uh I think last time you have mentioned the time issue. Uh I think this this solution is about the long-term solutions, not the short-term. I think this maybe the next um important factor. Thank you. 

**Eric Kline:** Okay, well, Chenhao, thank you very much. I mean, my take from listening from the discussion is I think you need to make a stronger case for why this is needed because I think the document isn't making that clear. 

**Jen Linkova:** Yes, thanks. Thank you for presenting. Last presentation for today is error handling in SRv6 networks. Okay, hold on, let me do this. Chenhao, can you please stop sharing your slides? I think I can do it, yeah. Ebox slides. Okay. Forgot how to do this. Okay. Next one. Jie, do you want me to move your slides or you going to take control? 

**Balaji Venkat Venkataswami:** Yeah, I can control it. 

**Jen Linkova:** Okay, cool. 

**Balaji Venkat Venkataswami:** Okay. Thank you. Okay, so what I'm presenting here, this is a new draft recently posted. Um, this is about ICMP error handling for VPN networks in case you are using SRv6. and on behalf of my co-author, I will present this. Next slide please. So what we are proposing here, to define the ICMP error handling in SRv6-based virtual private networks, and we are proposing a solution that changes only the ingress edge node behavior. Uh the goal what we would like to achieve with this solution is to provide the transport network visibility for the VPN endpoints. So this is the usual ping traceroute stuff that we intend to do from VPN endpoints as well. And uh it is not only about visibility, but we also intend to support the finding the broken link or node inside the transport network, so within the SRv6 domain. Being able to point to the network location where there is an issue. Um next slide please. Uh I think the the challenge for VPN traffic is well known. Um the P nodes inside your domain, inside the transport network, they are not aware of VPNs, so they cannot root VPN-specific ICMP error messages. In case of SRv6 P nodes may be IPv6-only, so they are not aware of IPv4. uh and if you have VPN service like VPNv4, then they cannot be acting on on those uh traffic. Uh the essence of the solution is that we have described in the draft an ICMP processing function on the edge node, on the ingress P node. Uh this solution does not involve the egress P node, and we are doing it by intention, because uh you are using this tools in order to find any forwarding issues towards your egress points. If that is not reachable and you are involving that node in your troubleshooting tool, then you are in trouble because you will not have the feedback from the network. Uh next slide please. So, uh I think this this issue is well known, we have discussed a lot in MPLS networks for example. Uh in case of MPLS there is a a special encapsulation because we are using a label stack, uh and there are some restrictions regarding what you can find out on a P node about the traffic, for for which your TTL expires. Uh the case for SRv6 is somewhat different, because there we have a full-blown IPv6 header. We have a source IP field. So inside the network on a P node you can determine where is the ingress of my SRv6 tunnel. So that restriction that applies for MPLS, it doesn't apply for SRv6 networks. So this is why we thought that it it is interesting to uh use this fact and gain from that when creating a solution for VPN traffic in SRv6 domain. Uh next slide please. This slide is summarizing the concept what we are proposing, and there are practically three major steps how you are dealing with a with a traceroute for example on the network. Uh the first step what we are proposing is on the ingress P node. Uh so this is where you are creating the VPN encapsulation. Uh you can do it using the uniform model and when you are doing this encapsulation, you can add VPN specific information to the encapsulated packet. That that means that in the source IP of the outer encapsulation, you can place a VPN specific SID, which is representing the egress P node. Then your packet is sent towards the network, the encapsulated one, and the next step happen on the P node where your for example your hop limit expires. This node will be the originator of the ICMP error message, and and that node can apply the standard RFC 4443 operation and can send back an ICMP error message to the originator, and this is what you have in the source IP address of the invoking packet, and you can send it back to the ingress P node. And the third step of the solution is on the on the ingress P node again, where the ICMP error message is processed, and then you will find out based on the source IP which VPN that packet belongs to and then after modification you can send to the original inner packet source the ICMP error message. So the the draft is describing in detail how this ICMP error message processing function act and we are describing the method in detail how to forward this ICMP error message. Uh the next slides will just show what happens inside the network. So this is an SRv6 domain, and Host A would like to traceroute to Host B, and it is sending a packet towards the network. On the next slide we can see what happens at the edge node. It will encapsulate in an SRv6 tunnel the original packet, and as you can see with underscore, in the source IP there will be a PE1 specific and VPN specific SID used. Uh the next slide is showing that you are just propagating over the network, and let's assume that at P2 your hop limit will expire. Uh so on that node what we can see on the next slide, this ICMP error message will be generated and inside the payload you will have the invoking packet including the SRv6 header and the original packet sent by Host A. This packet can be sent directly back to PE1, and next slide is showing that on PE1 you have all the information to find out which VPN Host A is sitting, and then you can send the ICMP error message after some processing and modification to Host A. The main advantage here is that uh if there is any issue between P2 node and the PE2 node at the egress edge node, you are not affected by that and you will be able to to provide the traceroute up to the point where there are issues inside the SRv6 domain. This is just in detail describing, I will not go through it, please read the draft if you are interested in all the details. So we can skip this slide and go to the next one. Uh which is just summarizing the benefit of the solution. So it is compliant to the existing standards and it is not involving and not adding additional complexity to P nodes and it is not involving the egress P node. Uh and we can eliminate the shortcomings of MPLS-like solution because the ingress P egress P node are not involved and you can directly localize the field points in the network. Uh the solution makes also the P node service agnostic, and it allow to to build them IPv6-only. Uh one side effect is highlighted in the in the last bullet point, because the ICMP processing is moved to the ingress P node, you can have some additional manipulation of the ICMP error message which can be VPN-specific for some of the VPNs you might want to have full visibility of the of the network for some others maybe not. So this is something what you can also control by this method. And the next slide is just summarizing the next steps. So there were already a lot of discussion on the 6man and also on the Spring mailing links, so we are very happy about that and thanks for all the all the good feedbacks. Uh we think that there is need for some more discussions, there were also comments regarding complex multi-level encapsulation scenarios which we think might not be related only to VPN scenarios, this is something what can happen for non-VPN scenarios as well. Uh and we would like also to highlight that there is an alternative draft which is involving the P node and the egress PE to provide a solution for VPN and it is something based on the MPLS solution what we what we are using in MPLS network. Uh so that's it, so we are happy to to share this idea and seeking for further comments and discussion. 

**Jen Linkova:** Suresh. 

**Suresh Krishnan:** Yeah, thank you, Balaji. So I did read the draft and I'm not sure like what 6man aspects are in the draft. So I think it's fairly related to SPRING. I think you should probably be in SPRING. I don't know if you have a slot this Friday in SPRING, but I think that probably belongs there because it it doesn't require any code points or doesn't change any ICMP behavior, so I I don't see the connection here. Thank you. 

**Ron Bonica:** I like this draft a lot for two reasons. Um, first it doesn't do what MPLS did**Ron Bonica:** MPLS forwarded to the tunnel egress, it did that because it had to. It didn't have a path backwards. In this case, you do have a path backwards, and by using that, you remove the obligation to change the functionality of the P node. Um, that said, Suresh may be right. This might belong in SPRING, but I think for the purpose of keeping the P node pure, maybe the best thing we could all do is show up in SPRING to support this draft. 

**Balaji Venkat Venkataswami:** Okay. Thank you. 

**Jen Linkova:** Yeah, as a the chair's hat on, yes, I agree with what's been said. I think it's a kind of, you know, gray area. I believe this draft is presented here based on suggestion from SPRING chairs, so we might need to continue the discussion between SPRING and 6man chairs about where it belongs, right? Because it kind of describes what you do with ICMPv6, so I guess it could be seen as a 6man area, right? Yes. So like I I think we can talk about this, but I think the most— I've never was supporting the idea of bureaucracy preventing the good work to be done, right? So if it’s a problem needs to be solved which needs to be solved, I guess we can find a good home for it, right? Either in one group or another. So I think uh it as a chair I would like to see opinions on the technical part of the draft and we can talk about where it belongs SPRING or here later, we I am quite sure we can sort it out. Either group will want indication from the other one. Yeah. Yeah, like yeah. 

**Erik Vyncke:** Thanks Erik. Okay, so for now we have just shared all the comments on both list in order to facilitate facilitate those discussions and we are happy to to have a conclusion on that. Thank you. 

**Eric Kline:** That’s very good. Thank you. 

**Jen Linkova:** Thank you. And it looks like we are like perfectly on time. 

**Eric Kline:** I think we're done. 

**Jen Linkova:** Thank you very much for everyone who made it happen. Like so we kept it on time, nice discussion. We continue on the mailing list, I believe chairs have some action items. Thank you Erik for being in the room. 

**Erik Vyncke:** And thank you for the AD, Eric, for four years or six years of dedication to IPv6, right? 

*(Applause)*

**Jen Linkova:** Yes, see you, see you in Vienna. Bye bye. 

**Speaker 1:** Bye. 

**Speaker 2:** Bye.

**Speaker 3:** See you people, bye. Bye. 

**Speaker 4:** Bye. Thank you. 

**Speaker 5:** Bye, San Jose. Bye.

**Eric Kline:** Bye.

**Jen Linkova:** I think we are done. 

*(Room chatter)*