Session Date/Time: 16 Mar 2026 01:00
Shi-Ping Xiao: Okay, good morning folks. It's 9 o'clock, so let's start. Welcome to IETF 125 in China, and welcome to the v6ops session. This is Shi-Ping Xiao, and my co-chair Nick is online. Ron is our technical advisor, and Mad is our AD. So, first I will read the Note Well. By participating in the IETF, you agree to follow IETF processes and policies. If you are aware of any IETF contribution that is covered by patents or patent applications that are owned or controlled by you or your sponsor, you must disclose the fact and not participate in the discussion. As a participant in or attendee to any IETF activity, you acknowledge that written, audio, video, and photographic records of meetings may be made public. Personal information that you provide in the IETF will be handled in accordance to IETF privacy statement. As a participant or attendee, you agree to work respectfully with other participants. Please contact the Omuds team if you have questions or concerns about this. And as a reminder, we work as individuals. Please be nice to each other.
Shi-Ping Xiao: So, housekeeping issues. Please scan the QR code to sign the blue sheet if you haven't done so. Please use your mobile to get into the Meetecho queue before walking to the mic.
Shi-Ping Xiao: So, today we have a full agenda. Four working group drafts and six individuals will take up all the 120 minutes. I would like to remind the speakers to please observe the time.
Speaker 1: Question, sorry from remote room. Can you speak close to the mic, please? We can hear remote people okay but it's hard to hear you.
Shi-Ping Xiao: Oh, okay. Thank you for the feedback. So, regarding the working group status, from a draft perspective or from the attendee perspective, I think that everything is normal. And since the previous IETF, we have a number of achievements. I think that one of them is that we publish or we reclassify RFC 7757 from Proposed Standard to a Full Standard. We also lift two RFCs from Informational to Proposed Standard. We published RFC 9898, the ND consideration for IPv6 deployment. We made big progress on the C-level node behavior and recommendation. It’s now in RFC editor queue. The MD—the [draft-ietf-v6ops-framework-md-ipv6only-underlay]—passed working group last call and is waiting for shepherd write-up. And then the [draft-ietf-v6ops-6mops], the [draft-ietf-v6ops-ipv6-app-testing], I think that they received a lot of attention, and also the 7915-bis, the [draft-ietf-v6ops-rfc7915-bis], the 6146-bis, the [draft-ietf-v6ops-rfc6146-bis] are adopted. And we will hopefully progress them quickly. And also we achieved one milestone and deleted two which we believe, you know, according to our discussion with AD, we believe that are already largely achieved in the past. So, we will continue to call for everybody to contribute to the new milestones and also help to contribute to Brian's IPv6 textbook. So, I think that this is it. We will move on to the first presentation by Jen. Jen, the floor is yours.
01-Jen_Linkova-draft-ietf-v6ops-nat64-wkp-1918
Jen Linkova: Hello. I requested the slide control, can you give it to me? Okay. I have them, right? Hold on. Ah, what happened? Sorry. Let me try again. Okay. So, okay. You control the slides then. Okay, so this is second time we're presenting this. We presented it last time on very short notice. A draft which suggests us to allow to use Well-Known NAT64 Prefix to represent non-global IPv4 address space. Next slide, please. Well, as usual, right, it's a problem when you present something which is already adopted. I don't know how much I need to go into background which we discussed before. But just a quick recap. RFC 6052, which defines addressing scheme for translators, all translators from v4 to v6—so it applies to both CLAT, PLAT and so on—explicitly says that Well-Known Prefix must not be used to represent non-global v4 address space and translators must drop those packets. It actually leads to operational issues in various deployment scenarios for v6-only, especially for networks like enterprises or v6-mostly public Wi-Fis and so on. We discussed it in more detail in Montreal. So you can see the slides from the last session. So next slide, please.
Jen Linkova: So yeah, a typical scenario just to remind you, right? If I'm deploying v6-mostly, for example, like at IETF network, right? I normally would expect to provide a single NAT64 prefix, either through PRE64 RA option or through 7050. But that means that I cannot use that Well-Known Prefix if I also want hosts to use NAT64 to talk to internal hosts, right? I would need to use public network-specific prefix which is inconvenient. So next slide, please.
Jen Linkova: So yeah, in a nutshell, this is a very short draft which proposes relaxing this "must not represent" and "must drop". So translators are allowed to use 64:ff9b::/96 to represent private address space and they are allowed to process such a packet, so they must not drop them by default. So, fun fact, eight years ago Fred Baker filled a re-errata for 6052 and he suggested just removing the whole paragraph which talks about those restrictions. That errata was rejected saying it's basically a substantial change to the RFC, so if we want to do this, we need to update 6052. It's exactly what we are doing now eight years later. Next slide, please. And actually next slide. So yeah, so what we've done since adoption. So yeah, there's been some discussion on the list. Thank you, Med, for your feedback. We tried to find a wording for the new text which is not breaking existing stuff but still allows translation—translators to use Well-Known Prefix. So idea is that obviously the opposite of "must not be used", we now say "it may be used". Well-Known Prefix may be used to represent those packets, and translators must not drop them unless they are configured so. Because again, as we discussed many times in mailing list, this is a policy decision. If I want to use my 64:ff9b::/96 to provide access to v4-only services using private address space, that's my policy decision. If I don't, I will create a NAT rule which—or firewall rule which blocks this. So what we are suggesting is that translators must be able to translate those packets, they must not drop them unless there is a policy which tells them not to translate. And we do not want to change the default behavior for existing implementations because maybe some operators rely on it currently. So suggestion is that implementations should have a configuration knob to control that behavior. This is obviously mostly applies to PLAT cases, but we need to remember that that restriction also applies to CLAT, and CLAT implementations are mostly unmanaged, right? So your mobile phone, you're not going to have configuration knobs to control the CLAT behavior. So we want devices like mobile phones to translate it by default and then on PLAT side you might use your configuration to control are we going to drop those packets or permit them. Next slide, please.
Jen Linkova: Yeah, so what's also changed. We extended text in operational consideration. We reiterate, re-emphasize that it's a policy decision, translate or not translate in this case. And we discuss existing behavior saying that yes, it might be implementations which already translate in which case we change nothing for them, and implementations which do not translate by default, we just want them to—for managed cases—to start translating. Yeah, and we also explain a little bit in more details why using network-specific prefix is not always convenient for operators. Next slide, please.
Jen Linkova: So yeah, security considerations. We're saying yes, so some operators may be—might be relying on the current default behavior, on the current "must drop" as a security feature. So suggestion is that for existing managed implementations, do not change the default behavior, just introduce the configuration knob to control it. And administrators are advised to have an explicit policies to define what should be translated and what should not. Next slide. Well, it's basically it. It's a short draft. Wording I believe it's straightforward and it's in a good shape. So maybe we shall consider last call for this or any—any other comments on this? Thank you.
Shi-Ping Xiao: Any comments?
Momoka Williams: Yeah, Momoka Williams, Orange. Thank you, Jen, I would say, for the new revision of the draft. I think that you have captured, I would say, the main points there about the impact of operational considerations and also the implementations. I personally don't like, I would say, the way the current default is—is—I would prefer if it is reverted. But I understand the point that you want to focus more on the—on the CLAT one, which is—which is not that managed. So if we don't have—if we have the current, I would say, default behavior it is more straightforward for this one. And I also think that you—you have, I would say, balanced that part when you discuss it in the—in the operational consideration to say that stick—existing implementation did not need to change if they just have, I would say, the relaxed behavior, they just continue like this. I think I—I can convince myself to—um, yeah, to—to say that this is reasonable. There is just one point that I think that that will be really worth to be clarified or at least documented somewhere is the—I know at least for the—the NAT64, I know that the behavior there is that the default is to—is to drop unless there is a relaxed policy. So for that one, I think that's—um, it is really clear and this is captured already on the draft. But what I am really missing is the current behavior of the CLAT because some of the implementation I am aware of, they don't even have this restriction of what we are discussing here in the draft. Um, yeah, just if you can have, I would say, a paragraph somewhere there or just to touch on—on that one, that will be real—really useful for we can have, I would say, the full—the full picture. Thank you, Jen, again for working on this.
Jen Linkova: Cool. So yeah, to answer this, yes, uh, as far as I know, yes, there are implementations of CLAT which just ignore this illustration, and some of them don't ignore them, right? So that's—that's one of the reason we've seen inconsistency from operational perspective, right? You never know how your unmanaged device is going to behave. So that's why we want to have a clear instructions. Actually, remember that Fred Baker's re-errata suggested just removing the paragraph and not saying anything. And I think it might not be a good idea because we want a clear instructions for implementers to say you should—you must treat those packets as normal packets unless you have policy. But yeah, I agree we can add some text about that, yeah.
Shi-Ping Xiao: Nick?
Nick: So I agree. Um, I like the changes that you've made and I've always kind of felt like this was a policy decision that was sort of forced. Um, I do—I do have the same experience that the behavior across CLATs is inconsistent. So I do think that clear instructions would be useful there. Um, but overall, I think, you know, perhaps adding some, you know, some examples that could even be removed before publication would be useful. And I do think it's probably ready, you know, with that—with that caveat.
Jen Linkova: Cool, Nick. I know that you did some testing, right? So you have some—some operational data. I'll ping you probably, yeah, to add some of it to the draft. Cool.
Nick: Yeah, I can do—I can do a PR, um, if you want me to. I have—I have a bunch of some of that data. So.
Shi-Ping Xiao: Thomas? No? Thomas, are you speaking or...? I guess Thomas, if you are in the queue, ask your question. Okay.
Jen Linkova: Uh, Shi-Ping, could you please again speak close to the mic because it's still a bit hard to hear you when you are too far away from the microphone?
Shi-Ping Xiao: Okay, thank you.
Jen Linkova: Okay, thanks.
Shi-Ping Xiao: Okay then, then we move on to the next—Jordi, it's you.
02-1 Jordi Palet - rfc6146-bis
Jordi Palet: Okay, so, um, the first—I have two documents in this block. The first one is the RFC 6146-bis. Um, it—it passed the working group adoption call. Clicker. Um, so if it works—it is not working. Yeah, now. Um, from the previous version, this document has no changes at all. So basically is the same that was approved for the—for the working group adoption. Um, what we did in the previous version was basically resolving two erratas. Uh, none of those erratas was creating any interoperability issues. Um, updated the references. Now the original authors have been contacted because previously they were not responding because a failure in the data tracker that the contact email for the authors was not really working. Um, but one of the authors is not responding, so—so he's not anymore author of this version of the document, but is still mentioned in the acknowledgment section for the previous authors. Um, added an implementation status section and IANA consideration section, which basically is just updating the reference to this document. Um, it's too slow. Okay. I am not sure now. Yeah. So what we need to do basically is if there are any new inputs from the working group, and then I think it's ready for the last call. That's it.
Shi-Ping Xiao: Any—any comments? [Silence]
02-2 Jordi Palet - rfc7915-bis
Jordi Palet: Yeah, okay. So this is the second document. Uh, this is SIIT, which is RFC 7915. Um, in this case, if the slide moves, come on, why is so slow? Um, in this case there was a minor typo, I think it was one—one typo, um, that has been corrected. That's the only difference with the previous version before the working group adoption call. Uh, and in the previous version, I resolved one errata. Uh, again, this errata would not create any interoperability issues. Updated reference and in this case, all the original authors have been contacted, they have their mic open. [Audio glitches] In the remote. Um, so what is missing here? Because the v6ops ICMP extension x-LAT v6-only source is obsoleting 6791 and is replacing there a reference—we need to replace a reference to 6791 with the new RFC, which I think has already passed IESG, right? Not yet? It's—it's in that—that moment. Okay. And then we need to update references in 7915 in sections 5.1 and 5.2 to incorporate the changes that are proposed by this—this document. Um, we will also include a reference to the document itself, an explanation of—of the reason for that, um, and confirm that there is no backward compatibility before proceeding to full standard. Um, I will need to update also the implementation report. However, uh, I am not sure we will have already implementations of this quite soon. So probably there is nothing to do and before—because there is no interoperability or backward interoperability issue should—should not be a problem in my opinion. And I think that's it. So in a matter of days or weeks, maximum, I think days, I can publish version 01. Uh, I'll—I'll wait anyway a few days at least in case there are any new inputs and then I think it will be ready also for last call. So, inputs, comments?
Momoka Williams: Yeah, um, thank you Jordi for—for carrying on this work. I think that we will need to wait for the new revision of the draft from Jen and David because, um, at least in the—my review there is some points that I think that's maybe impacting the interoperability there. So I would wait for that one before you, I would say, you—you release the new revision, and then we can do the full assessment once we have that text sent to the IESG and so on. But overall, yes.
Jordi Palet: Okay.
Shi-Ping Xiao: Okay, if there's no more comments we will move on to the next one.
03 Tim Winters - Basic Requirements for IPv6 Customer Edge Routers
Tim Winters: Tim? Hey, can you guys hear me?
Shi-Ping Xiao: Yes. I will run the slides for you.
Tim Winters: Okay. I won't turn on my video, I don't know if that's part of the problem or what's going on but I'll—let's see if we can keep going. Okay. Okay, so it's the entire venue. All right. So I will—I will do what I can then. Um, so for this revision of it, um, what we did was we added an additional requirement on the second slide. I don't know if you're on it, I can't see. There we go. Perfect. We added an M/O flag check and really what we're asking for here is that home CPEs don't change the stateful configuration when the flags flip off. Um, this is sometimes people have misconfigured things or M/O flags are changing, if you have DHCP you should just keep it. Um, is really all we're saying here, we're not making any other crazy M/O things. Um, this draft already has a couple of things about M/O flags. So, just contributing to that. Okay. Um, this one for 06, it's pretty straightforward. Uh, we had one note, somebody noted, uh, the original version of this draft has "most hosts are capable of Slack", we should change it and just say they "can do Slack". So we're going to do that. Um, there was a really good request from somebody that we should add the ability to do DoH and DoT, which is DNS over TLS or DNS over HTTPS. I think those should both be, you know, they're not musts in this case, we just want to call out that yes, they—they can be done and um, I think we should make these shoulds actually. Um, there's—there's a lot of good reason to do these. So we're going to add those. Um, there was a request from Dan Wing to add additional text about why RA Guard is in there and I think—or why RA Guard is disabled by default. [Silence] Now I can't even control the slide. Can you guys still hear me?
Speaker 2: I can hear you remotely.
Tim Winters: Okay, that's good. Oh, great. First—first slot of the first—first session in the IETF. Yep. So, yep, the slide six, um, I think that had everything in it. Basically, we're going to make all those changes. If anyone has any additional comments, I think this is ready for working group last call. Um, I see Med's in the queue. Hopefully, I'll be able to hear him. Go ahead, Med.
Momoka Williams (Med): Yeah, thank you Tim. I think there—there is one point that we need to—to—to discuss before moving to working group last call is what we will be do—we will be doing for the RFC 9818 because I—I think that that one, um, already updates the one that you are obsoleting. So maybe just absorb that one in—in this document. So yeah, I think that you—whatever the outcome that you will be deciding, um, it would be good at least to have that discussion on—on the group.
Tim Winters: Well, I have good news for you, we already did that in 05, 04 actually we did it. So we've absorbed that draft into this one, so all the LPD requirements from that draft are in this draft now.
Momoka Williams (Med): Okay, thank you. Thank you Tim. Sorry I didn't look through the new—the latest version. Thanks.
Tim Winters: Yeah, no worries.
Shi-Ping Xiao: So Tim, I think that we will wait for the 06 version before we discuss working group last call.
Tim Winters: Yeah, I think that makes perfect sense. I'll probably post it this week and then we can kick off—um, we'll kick it off from there.
Shi-Ping Xiao: Lorenzo?
Lorenzo Colitti: Um, one minor point which is, um, when you say a change in the M/O bits must not result in, you know, the client stopping the—the CPE stopping the—the DHCPv6 client, I think you'll need to be a lot more specific about when you want them to actually stop it. Because if I read the text that you put on the screen a few slides ago, I would basically be like, "Oh, I've seen an M-bit like in 1985, great, I'll leave the client on all the time." So, um, yeah. I don't know if you can go back one slide, yeah.
Tim Winters: Yeah, well so if you go back one slide, you'll see that my suggestion now is that we just have DHCP on all the time. IANA is a little bit different but you're—you're want to get PD, right? So we always want to have the DHCP client sending stuff. And so the—the M-bit's a little different but the O-bit is also thrown in there and so...
Lorenzo Colitti: Is it—is it harmful to ask for IANA, do you think?
Tim Winters: No, it is not, in my opinion, because you—they can just send back "no address available", you know. This was a little bit different originally when we—when we did the World v6 Launch and all of that, we had a lot of trouble with people not handling stateful DHCP issues. We don't see that much anymore where they can't handle if they get a PD but don't get an IANA. We've done a good job addressing that.
Lorenzo Colitti: I mean I've definitely seen like, uh, I think it was—I think it was some Juniper MX that got confused if you asked for an IANA and an IAPD in the same—for the same IAD, it just like lost its mind. So maybe yeah, so maybe that's why we can't turn on IANA all the time. But if we—so I agree that we should just—just ask for PD all the time. That's fine. I guess the question is like do we need to put in an IANA option in there? And if we—if we don't leave IANA on all the time, then we'll have to figure out like the text that you... you know, can someone move the slides back please? Who's controlling the slides? Is it Shi-Ping? Go back or—at least one slide. I will tell you to—more. Yeah. You know, if we—if we keep this text or something like it, then we need to figure out what to do with IANA requests.
Tim Winters: Well, so right, so my reading of this, Lorenzo, is this flag is to when they change. So if you get it set and then it switches to false that you shouldn't drop your current DHCP information. That's all this is saying here, we're not making other...
Lorenzo Colitti: And then you lose link, do you?
Tim Winters: Well, when you lose link, you would—all the flags, all your RA stuff falls out of your head, right?
Lorenzo Colitti: Right, right, right. But you don't write that here.
Tim Winters: No, but that's an ND thing, that's not a CPE router thing.
Lorenzo Colitti: Ay, ay, ay. I don't—I don't know that you can write... anyway, so I—I guess we just need to rely on this. You know, just maybe tighten the... I mean like, I—I would say assume—assume a sort of like not very competent implementer just in case, and then, you know, you would maybe say like for clarity like the—the—the... because we also need to decide, if you lose link, should you stop it? I mean if I'm an implementer, do I need to stop it when I lose link? I don't know, maybe.
Tim Winters: When you lose link, you're in DHCP, right? When you lose link and you come back, you have to do a re-bind, right? To make sure that your server's still there.
Lorenzo Colitti: And do I re-bind the—okay what, do I also DHCP confirm the M—the—you know, how do I know if I lost link if it's the same RA?
Tim Winters: Yeah, you have to do—right. So you do all that jazz, right? So in DHCP land you have to do a re-bind because PD doesn't do confirm. So you send a re-bind with both the IANA and the PD. And that should just work. For Slack, it's a little bit different, you—you basically just send an RS out and make sure that your router gives you back everything so you relearn it. So that—that would be my...
Lorenzo Colitti: My point is we probably want to do this a lit—we want to like, you know, put a little more care than just "must not". Another thing I wanted to say though is, um, the Slack Renum stuff as it is, I believe it's harmful and we shouldn't do it. Um, there's a discussion in sort of—it's sort of in the wrong place, it's on—on the response to the AD review thread of the draft that's currently—it well, just came out of 6man. What that says...
Tim Winters: 6renum. Okay.
Lorenzo Colitti: Yeah, so what—so because 6renum is actually parts of 6renum are already in RFC that came out of v6ops and I don't think we noticed the issues there. But what—like the gist of it is what it says what—what—what the text says is when you—uh, when you lose some config information like a PIO, you must keep—uh, advertising that PIO in all future RAs until the lifetime is expired. What that means is if you have a—if you have a link flap and you get several prefixes, your RA becomes like huge and it like has all of these old things that have not yet expired but are sort of... and so that is very harmful to the hardware filtering that, you know, mobile devices do today because that—that filtering has to operate in literally 1 or 2 or 3 or 4 kilobytes of RAM. And it'll basically blow out the hardware filter.
Tim Winters: Okay. I don't—I can't remember how much we... there were some updates to the CPE draft, Lorenzo. I'll have to look to see how much of that we took.
Lorenzo Colitti: Yeah, anyway, so this is being discussed in the—in sort of in the 6man.
Tim Winters: Yeah, okay. I'll be there but yeah, we'll keep my—my eyes open and we'll do the right thing here.
Lorenzo Colitti: The—the other thing I think we should say is—and this may sound a bit radical—um, must not accept any lifetime shorter than 180, period. Non-zero.
Tim Winters: Uh, that's a bit—that's a bit radical.
Lorenzo Colitti: I yeah, but you know, I've seen CPEs like ad-advance—announce like RAs with lifetimes of 12 seconds. I mean, you can sometimes be misconfigured that way.
Tim Winters: Yeah, I have one in my lab that does 5 seconds.
Lorenzo Colitti: Yeah, so by the way, Android will just drop those. If you're less than 180 it just doesn't work. I—I think we can talk about we have the defaults. I think 180—send text, Lorenzo. We can talk about this. I—my general feeling from operators is 180 is a little too long, but I—I'd be happy to talk about this with some operators.
Lorenzo Colitti: I guess maybe this is not the place. Yeah, okay.
Tim Winters: I mean v6ops is the place. We need to—but we need to talk to how people are oper—you know, we want to talk to the—the operators of the world to figure out what they are doing, not...
Lorenzo Colitti: I mean, I think they're probably doing that to—for Slack Renum to work. Right, so...
Tim Winters: Okay. So you know that there are operators that use less than 180 by design?
Lorenzo Colitti: Yes. Yeah, let's talk offline, I guess. Thanks.
Tim Winters: Yeah.
Shi-Ping Xiao: Okay, so we move on. I think Jordi, it's you.
05-1 Jordi Palet - IPv6 Prefix Assignment to end-users
Jordi Palet: I'll run the slide for you. Next. Okay. Um, so we had the discussion on this document in the previous meeting. Next one, please. Um, just to recall about what—what is about, there have been many ideas about point-to-point links. Also we had the RIPE 690 BCOP, which is Best Current Operational Practices. Next one, please. Um, and this document is trying to respond to several questions like: what is the correct size for the point-to-point links? How to number the point-to-point links? What pool to use for the point-to-point links? What prefix size should be assigned to customers or to end-sites? Uh, and should the customer prefix be persistent, which is what we call static in IPv4. Next, please. So, um, the changes that I did in the document considering the previous discussion in the list and also in the meeting itself is incorporating some text about PPPoE and IPoE deployments, which was not there or it was not clear enough. Uh, clarification about persistency versus privacy. There was a bit of discussion about persistency is not good because privacy, etc., etc. Um, there was an input very good, I think, about address reputation related to persistency or non-persistency. Uh, I removed it because there was also a comment that there should not be so much normative text, uh, or even it must not be a BCP. So I think the compromise is removing all the normative uppercase language and relaxed the BCP summary. I think that resolves the—the question. And then, uh, added the recommendation for publishing prefix lengths based in another document that is being discussed in v6ops working group. Um, next, please. So, questions. I am not sure how many people read the new version, uh, any new inputs, uh, and then asking for working group adoption. Anyone has read the document and seen the differences with the previous one? I don't see too many people saying yes or no. I think I—I really captured all the previous discussion, so I hope that I resolved all the—all the issues, including your inputs, Eric.
Eric Vyncke: Yeah, and thank you as I joined the queue. Just a big suggestions: when you adopt it, change the title because the title right now is quite unclear. It's too—too generic, right? Make it very specific for...
Jordi Palet: Any specific suggestions for title?
Eric Vyncke: Like "Prefix for End User" or something like this.
Jordi Palet: Okay.
Shi-Ping Xiao: Yes, I also support the adoption of this one. I think that RIPE may have some documents that's similar but for other regions. I think that such a document will be useful, so.
Jordi Palet: Yeah, actually this document is being used by all the registries more or less or referenced, in the sense that they refer to the RIPE BCOP 690. But of course that document was published, I think, 10 years ago already. So I think some of the updates that I included in the document are very relevant today, so—so that makes sense as well.
Michael: Hi. Um, you keep putting the polls up without the name of the draft. I have no idea what I'm voting for, um, because you may have moved on. So please don't do that, just "Adoption" or "To Be Whatever", just—not—you need the name of the document somehow in the poll or it's too confusing.
Shi-Ping Xiao: Okay, I thought that now we are talking about Jordi's draft, so adoption is about Jordi's draft.
Michael: Yes, yes, but—but then I see four polls behind that and I have no idea what they're for or what the results were, right?
Shi-Ping Xiao: Okay, fine. Yeah. Okay, so we move on to your next presentation, Jordi. You need the close the poll again. Yeah.
05-02 Jordi Palet - IPv6-only Terminology Definition
Jordi Palet: Okay, so this is another long discussion for ages. Uh, this is a new version which actually very few changes to the previous one. Um, and I want to—to—to have a small discussion about what I heard from different people. Next, please. Basically, the—the idea of this document is that the people is getting confused when we say "IPv6-only", "IPv4-only", "dual stack", "IPv6-mostly", okay? So some people understand that we are talking about the full network, okay? Most of the time, for example. And typically is not the case because you can have a service provider that has a dual stack core, dual stack upstreams, but they have only, for example, residential IPv6-only and maybe IPv6-only also in the mobile, okay? But at the end is a problem of context. And I think Shi-Ping mentioned it may be clear—more clear to use scope. So basically the main change in the document is I changed most of the text that was using context to scope. Um, next, please. So the discussion in the—in the different meetings, because I think the last time I presented this was in Dublin last year or previous year, um, and we had also several times discussion in the list about this and also in corridors and so on. And most people really agree that this should be defined. There—there should be a clear definition so there is no confusion. And many people mentioned that in other working groups they have also documents with definitions, okay? Because that helps to have a common understanding in other documents. Um, so the thing is that some people want to define each possible case. I think, for example, uh, one of the co-chairs sent a very—very strict definition of they—what they are using in tenders. Uh, but I think that's impossible. If we try to define every possible case it's no end. So I believe, and—and some people agree and I think it was actually a suggestion from—from Bob Hinden, it seems better to define only the basic and then apply by scope, okay? So in a previous version of the document, or two previous versions of the document, I have many, many definitions. But now I have just four or something like that, which is basically "IPv6-only", "IPv4-only", "dual stack" and "IPv6-mostly". I think that's it. If we define just that and we apply that to every specific scope, then I think it's easy that we can agree. If we try to fix all possible definitions, then is no way. Um, so that's basically the discussion that we should have either here if we had time or—or in the list. But I think that's—that's the only possible way to progress. Uh, next, please. Um, and—and just for example, well, one of the basic definitions is "native". Native means that IP packet run directly over a layer 2 logical link layer interface. For example, IEEE 802, uh, without any—anything at layer 3 being encapsulated within an IP packet of another IP protocol. That—that's a basic, very, very basic definition. Again, if we agree on that, probably we agree in the rest. Next, please. Um, and then if we take the example of "IPv6-only", IPv6-only in a given scope means that only IPv6 is native in that scope. IPv4 is not configured, neither managed in that scope, even if it may be transported or encapsulated on top of IPv6. Okay? So that's—that's another basic, very basic definition. Again, if we can agree on this, then we are done. Next, please. Um, so that's it basically. Uh, I don't think we have time for discussion because all the network interruptions. But if we can have this discussion in the list, uh, I think we can—we can find a common very, very basic agreement of those definitions. Again, not trying to define every possible case because that will not work. But at least the basics: native, IPv6-only, IPv4-only, dual stack and IPv6-mostly. And that's what we have today in version 10 of the document. And if we agree on that, then we can go for working group adoption as well.
Shi-Ping Xiao: Thank you. Brian?
Brian Carpenter: Yeah, hi. Jordi. Listen, I like this version a lot better. I think your introduction of the scope notion is correct, it's the right way to clarify. Uh, I just had a quick glance at the text itself, not your slides, and I think one point that is still not necessarily clear to a reader who is a bit new to the topic is that even in "IPv6-only" so-called situation, the applications can still see a dual stack API. And I know that's not the main point of the document, but I think it's a kind of reassurance that people might want to see, you know, you can always have a dual stack API at the app—at the application layer, whatever the IPv6-only status of the other scopes is.
Jordi Palet: I am not sure I correctly understood anything from here, the audio is terrible. Uh, you understood something or you can read the script, maybe? If not—if not, I will read the script later and—and respond in the list or—or you can say in the list because from here I cannot read the script.
Brian Carpenter: Sorry about that. Uh, I had a lot of—yeah, no, it's not your fault. I think the audio is terrible. In the previous presentations also I could not understand almost anything. There is—there is a lot of echo here and... Okay, let's—let's take it to the list then. Thank you.
Shi-Ping Xiao: Thank you.
04 Zhang Wei - Measurement and Analysis of IPv6 Interface Identifier Patterns in the Real World
Shi-Ping Xiao: [Segment previously skipped, now re-inserted based on slide titles provided]. Are you here? Next slide.
Zhang Wei: Let's dive into the results, starting with servers. In previous RFC, low-byte patterns were heavily dominant, over 56% for web and 92% for mail. Uh, today you can see low-byte has dropped to about 8% for web. That means simple linear scanning is less effectively today. However, scanning is not dead. Thanks to our new methodology, we discovered that nearly 48% of web servers are actually seed-similar. Meaning they follow non-random organizational templates. As a result, target generation algorithms remain a highly viable reconnaissance vectors. However, moving to client devices, we have great news for the IETF community. Using our longitudinal tracking data from 2013 to 2024, you can see a clear trend. The use of traditional EUI-64 addresses has dropped to just over 1%, while randomized pattern dominates the landscape. This proves that the standards like RFC 8981 are overwhelmingly and successfully deployed by modern operating systems. Consequently, end-user tracking via MAC addresses is largely mitigated. However, the victory is not complete. While core infrastructure routers understandably continue to rely on low-byte patterns for management, we found a critical blind spot at the network edge: Customer Premises Equipment or CPE. As you can see, about 18% still defaults to IEEE EUI-64 addresses. This is alarming because it acts as a persistent super-cookie for the entire home network, exposing the hardware vendors' OUI and enabling persistence tracking of end-users. To wrap up, here are our main takeaways. First, we must update our threat models because the previous RFC statistics are significantly outdated. And second, for server deployment, we must move beyond security by obscurity. Algorithmic scanning can easily expose manual configurations. And finally, and most importantly, we urge the network operators and IETF community to push hardware vendors to enforce RFC 8064 and deprecate EUI-64 on edge devices. We need to close this massive privacy gap. That concludes my presentation. You can find all the detailed data and methodology in our draft. We are actively seeking feedback and comments from the working group. Thank you very much.
Shi-Ping Xiao: Any comments? Well, if not, we go back to Tim's presentation. Okay, thank you. Wait, we have one person. Lorenzo's in the queue. Oh, why we don't see it here?
Lorenzo Colitti: Yeah, uh, so I had a question about your sort of conclusion on the, you know, that the EUI-64 configuring EUI-64 on the home gateway you say is a privacy issue, yes?
Zhang Wei: Uh, you said the client or CPE routers?
Lorenzo Colitti: The CPE. You say that using EUI-64 in the CPE is a privacy issue.
Zhang Wei: Oh, yes. Uh, there are—there are some research about the—this issue. Uh, if—if your CPE routers use the EUI-64—use EUI-64 addresses, when—if you use like prefix rotation, but the—the ID of the CPE is—uh, is fixed. So attackers can track the—the whole—the entire home network.
Lorenzo Colitti: So you mean that they can do traceroute to the home network prefix and they will see the—the IP address of the—of the CPE, the northbound address? That's the threat?
Zhang Wei: Uh, yeah. Uh, if the client user use the prefix rotation or the—the client address use the random address, but the—but because the CPE routers use the fixed ID, so it still can tracking the home—the entire home network.
Lorenzo Colitti: So how does the attacker get the fixed IP address of the CPE?
Zhang Wei: Uh, the attacker can sniffer the network traffic or the other—or the other methods, but...
Lorenzo Colitti: But the address of the CPE is not in the network traffic. You can't sniff it. It's not in the packets. Only the source address of the actual user's devices is in the packets. The CPE IP address is not in the packets. I mean you can traceroute to the user, yes, but that means—but like that doesn't work if the CPE is using IANA to do the northbound interface, right?
Zhang Wei: Uh, I forgot the—the whole detail. Uh, but you can see a paper. Uh, I remember the title is "A Bad Apple"—I don't—I don't forget the name. Uh, there is a research paper.
Lorenzo Colitti: It's okay. I think like maybe you can have an offline discussion with Lorenzo. And now we—we need to move on.
Zhang Wei: Uh, yeah. Okay, thank you.
06 JING ZHAO-IPv6 Network Deployment Monitoring and Analysis
Jing Zhao: Hi everyone. I'm Jing Zhao from China Unicom. Today, I'm on behalf of my team to introduce our draft "IPv6 Network Deployment Monitoring and Analysis". Well, first I will introduce the updates after IETF 124. In the last meeting, we resolved some comments. The first is what data collection method are used, and the second is how to consider existing method. So based on the comments, we update our draft. Um, well, about the IPv6 end-to-end monitoring and analysis architecture, it includes three layers. The first is data collection layer. Integration with existing network management systems can provide daily-level monitoring data through the standard interfaces. And the architecture leverage mature standard collection mechanism such as Telemetry, Netconf, YANG, and so on to ensure uniform data format and meet high-frequency traffic monitoring requirements. And the next layer is intelligent analysis layer. Dynamic traffic attribute: identify the regions with low IPv6 and high IPv4 deployment rate. So deploy a correlation analysis plan to identify which specific subsystems or to the problem comes from. And can achieve the user-level topology reconstruction: map service chains, rebuild end-to-end topologies and support segmented latency pocket loss diagnosis. And the visualization layer can provide metric-based visual presentations. And the architecture also can provide data support for the adoption and advancement of existing IPv6 deployment method. And most current systems rely on localized index analysis. So for more comprehensive presentation of the IPv6 and IPv4 deployment details and root cause analysis of IPv6 deployment bottlenecks, so we have newly defined a complete set of key performance metrics. Well, based on the architecture and metrics, we developed a platform. We demonstrate the platform UI and key use cases in Hackathon to validate the draft. So, well, next step if you are interested in the draft and have suggestion on how we can enhance our draft, please reach out to us. And we want to call some comments: what did we miss? Any comments? Well, if not, you can always send the comments to the list later. And we move on to the next speaker. Thank you.
07 Chenhao Ma - Considerations of Gradual IPv6-only Deployment in 5G Mobile Networks
Chenhao Ma: Hello everyone. This is Chenhao Ma from China Telecom. Uh, on behalf of all authors I will present this documentation. Uh, this is the third time I present this documentation. First, I want to show the document core objective review. The purpose of this draft is to explore how to gradually and incrementally deploy 464XLAT-based IPv6-only technology in 3GPP 5G networks. So, and this draft is based on our operational experience, analyzing the challenges encountered and discussing potential solutions. It includes IPv6-based network side configuration and Option 108 method and delivering Pref64 and DNS64 via Router Advertisement. So, the key content of this update is: there is some comments about why we should use the APN isolation method. So we add a section to discuss this method and some of its advantages and complexity. So here we describe this method: PDP context and APN isolation method. We dive into how to leverage inherent 3GPP APN or DNN in 5G mechanisms to assign different logical networks to various per-users groups. And we also added deployment scenario analysis. So elaborate on specific value of this solution in scenarios like coexistence of IPv6-only and dual-stack users and phased roll-out of DNS64 services and multiple DNS server tiers. So pilot lessons. The APN isolation approach. In earlier trials, we attempted to control the scope of the IPv6-only environment by assigning dedicated APNs to individual users. For example, we gave IPv6-only users "received-ipv6-only.apn" while regular users use the default dual-stack APN. Here we encounter some issues. First is high operational burden required per-user subscription data modification, making dynamic adjustment is very difficult. A significant number of existing terminals in the market do not support CLAT functionality. However, operators currently lack effective discovery mechanism to determine whether a given terminal is CLAT-capable. So without such visibility, it is risky to provision IPv6-only APNs for users as this may lead to a service failure. Moreover, users may switch terminals from a CLAT-enabled device to a non-CLAT-enabled device during the lifecycle of a subscription and this may lead to a service failure. Next slide. So next we will continue to seek feedback, and we hope this draft will be adopted as working group draft and welcome new input on what other deployment pain points should be included. And we want to know our lessons learned if broadly applicable. Thank you.
Momoka Williams (Med): Thank you for—for writing this draft. I have just one clarification question. What is specific to 5G here in this document? Because I would say the main point that you—you have presented so far are valid for the 4G and the other releases in 3GPP. So is there something which is really specific here?
Chenhao Ma: Uh, the draft will mainly focus on the mobile network and for now we think the 5G, we already deployed in our mobile network, and we think this is a long-term solution for mobile network for 4G, 5G or 6G or all of the mobile network.
Momoka Williams (Med): Yeah, my point is actually from an architecture standpoint there is no big difference, I would say. Whether you are using UPF or using the PDN gateway or you call it GGSN or whatever name you—it's I would say it's the same architectural, the same issues about how you will be provisioning the APNs, whether you will be using, I would say, IPv6-only or dual-stack one. It's the same, I would say, problems we have, I would say, considered for the deployment for the 4G and the other version before. So I think it will be really good if we—if you proceed here is and you insist to—to mention the 5G is to—to focus on, I would say, aspects that are really specific to this—to this version and—and release. Otherwise, uh, it will be—it will be really difficult, I would say, to assess the added value of this document. This is the first point I would like to make on this one. The other one is, for example, you are mentioning making some recommendation on some of the support of—of the functions at the network layer. This is not something that we can do here in the IETF because it's something which belongs to the 3GPP, because we are not defining the extensions, I would say, on what the UPF functions need to be—to be done. So we need to be careful on I would say on how we are framing, I would say, the—the—the consideration. Is it just for analysis that you are conducting or recommendation? So clarifying that—that goal will be also helpful.
Chenhao Ma: Yes. I think that the draft is for—we want this draft to be a guideline for IETF to—uh, to deploy this IPv6-only technology. It’s for recommendation, not a standard.
Momoka Williams (Med): Yeah, but we can't do the recommendation, for example, for the support of the Pref64 Router Advertisement, we cannot do it here in the IETF because if you want that function to be supported, you need I would say to go at least in the 3GPP and to say, "Yeah guys, there for the UPF part, we need to have, I would say, this option be supported." So it's actually the question about the applicability of the recommendation. Is it here the appropriate audience for that one, or is it I would say the actions are on the 3GPP side?
Chenhao Ma: I would say that this draft most—most content is about IETF, not on 3GPP. There only the solution I present today is about 3GPP but not—defining this function, just to let—let you know why we—why we will proposal a new RA DNS64 option to do this work. So I think the most work is here in IETF. I will add some more detail.
Shi-Ping Xiao: I recommend that you have a conversation with Med to understand his points better. And now I think Chongfeng you are next.
Chongfeng: Hello everyone, Chongfeng from China Telecom, actually one of the co-authors of this draft. Uh, 5G is one of the important case of IPv6-only deployment and this provides guidelines for IPv6-only deploying large-scale network. There are many kind of special cases. So I think this work is very valuable and because it's based on our experience and deployment operation. And for the question of Med, I think that this draft is yeah, is related to 5G because it is related to the 5G core network. And the 5G core network is different from 4G, yeah, you know that. But as Chenhao mentioned, we do not do any specific requirement to 3GPP mobile network, we just consider how to deploy IPv6-only in this case. We do not need to, maybe we can send a liaison to them but we do not need for them to do extra work for this—for this draft. That's my comments. Thank you.
Jordi Palet: Jordi Palet. Um, I have participated in several deployments of IPv6-only in 4G and also some of them with 5G, and my recommendation, and I believe what most of the operators are doing, is a single APN for all kind of customers. Never mind they are dual stack or IPv4-only or IPv6-only. Um, I think—I think that's the way to go because as you mentioned, if you force the customer when they change the mobile phone to change the APN, that adds complexity and I don't think that's—that's a good solution. So echoing also what Med mentioned, I—I don't think there are any differences applicable to this in regards—when moving from 4G to 5G. So maybe it's—it's necessary to clarify that in the document. What are the differences that ask you to do the deployment in a different way?
Chenhao Ma: Okay, first I want to—I don't understand how you can just provide one APN to all users, because in our market we—we have already default configured as IPv6—as dual stack. This is in our—in our China Telecom. So we have to update the APN—move a sort of dual stack users to IPv6-only users. So we have this situation, not from scratch to just give them—give them IPv6-only APN. We don't—we can't do that. Because we already set configured as dual stack APN. Uh, second, I think the—we in this draft we have mentioned the architecture to deploy the—this IPv6-only technology. We have roaming challenges which is not in 4G, they just local breakout—uh, deploy the local block—local breakout policy. But in 5G, this—this is one different thing. Another problem is the equipments don't have—like Apple iOS, they don't enable CLAT function. Uh, I don't think this problem don't exist in—for abroad or in other countries.
Jordi Palet: Yeah, I think there are different questions here. One is if the APN is properly configured, the APN is able to serve v4-only PDP, v4/v6 PDP and v6-only PDP. Okay? So depending on the configuration of the—of the user device, uh, that will work automatically if the APN is properly configured. Now, what you mentioned about Apple and the lack of CLAT, that's true. That's—that's Apple problem. You need to work with your Apple liaison in each region to agree with them to update the operator profile so they provide the CLAT. So only then uh, you will have the IPv6-only functionality and, if you need that, uh, the CLAT for the tethering, because in Apple the CLAT is not available by default because they are using Happy Eyeballs to do an equivalent function to the—to the CLAT. So instead of that for the tethered devices, you need a real CLAT. But that's more, let's say, not a technical problem, it's more a commercial problem with Apple, but it's not really a technical problem.
Chenhao Ma: I want to—I also have some information to share with you. I did have a talk with Apple in China, they said they must update their system to enable the CLAT function, not just—it's not a simple way. So this problem is exist in...
Chongfeng: Yeah, Apple is just one issues, and—and this draft also concerned about roaming from IPv6-only capabilities domain to IPv6-incapable domains. So it also concerned about this case because you know IPv6 are not being widely deployment in mobile network, right? So we need consideration, need to consider the roaming issues, yeah. And also we concerned about the APN issue, APN single APN. Actually large operators often provide multiple APNs, not only China Telecom but also provide such as T-Mobile because you know that they provide IPv6-only to some customer where IPv6-only but maybe some—some customer do not because they use function phone, they do not support IPv6-only. So they should provide dual stack APNs to this customer. So there's multiple type APNs in the mobile network.
Jordi Palet: Yeah, roaming is another typical problem and again, it's—it's problem of how you manage the agreements with your roaming partners and if you decide to enable or not a dual stack or IPv6-only on the roaming partners. But again, I don't think, and I—I believe that's what Med was trying to say, I don't think from this perspective there are differences before between 4G and 5G. So I don't think there is anything new in terms of deploying IPv6-only or dual stack or IPv4-only between the two technologies. Uh, maybe what is missing in the document is a clear explanation about what are the difference and if there is something really that need to be done in—in IETF.
Chenhao Ma: Okay, I will add a section to describe...
Shi-Ping Xiao: Yes, I think that the world has a lot of experience deploying 464XLAT already. So I think that maybe it would be good for—for you folks to, you know, get together and, you know, get some experience and also update the draft. But we need to move on now. Okay, thank you.
08 Jiaming Ye 08-slide-draft-yc-ipv6-for-ioa
Shi-Ping Xiao: Okay, so we move on to our last presentation. Why the last presentation change to this one? The name is right here, but you know... well, this is a break-new situation. Oh, I think that we still have a few minutes. So can you quickly send your PDF again? Yesterday, I ran all the slides and they are okay, don't know why. Okay, I will invite Jordi to... [Glitch in presentation display] Are you selling or Jordi? Eric, are you selling or Jordi is selling? I think it's Eric. Okay. Yes. So Jiaming.
Jiaming Ye: Hi everyone. It's Jiaming from China Mobile. Very happy to give this presentation and share some of my thoughts on the capabilities and future requirement of IPv6 for the Internet of AI Agent. As we all know, AI Agent is an intelligent entity that senses its environment, reasons about goals and acts autonomously to complete—to get things down. And in IOA, they autonomously discover, interact and collaborate with humans, other agent and tools. This will drive the Internet to become more smart and self-sufficient. It is projected that the number of agent will reach hundreds of billions in the near future. Next slide. However, constrained by the limited address space, IPv4 struggle to support the secure end-to-end connectivity among massive number of AI agent. So the evolution to IPv6 is a must. It has vast address space, end-to-end connectivity and some built-in functionalities like SLACC and SRv6. Next slide. Next slide, thank you. This draft will analyze the foundational capabilities that IPv6 can provide for the IOA at the current stage and further explores the evolutionary requirement that IOA imposed on the future of—of IPv6 development. Next slide.
Jiaming Ye: So the evolution to IPv6 is not merely a technological upgrade but also a fundamentally enabler for the large-scale development of agent. IPv6 is a 128-bit address and offers many, many addresses. In IOA, vast number of agent need exact addresses for intercommunication, and therefore IPv6 will enable the assignment of global unicast addresses to agent or sensors and eliminate the need for address reuse. Therefore IPv6 fundamentally resolved the addressing problem of agent. And the adoption of IPv6 also eliminates the dependence on NAT and empowers agent point-to-point coordination and direct orchestration without reliance on the intermediate nodes for forwarding or address translation and reduce the overhead of connection establishment and session lookup introduced by NAT, therefore minimizing communication latencies. Next slide.
Jiaming Ye: For some agent operating in dynamic environment like mobile device, drone, connected vehicles, they heavily depend on mobility for frequently switching between different network access point. Therefore, SLACC will come into play and enable devices to autonomously generate IPv6 addresses upon connecting to a network and thereby equipping agent with the capabilities for a rapid network attachment and dynamically re-addressing without manual intervention. IPv6 also enhance network intelligence and programmability and providing a fundamental for remote management and path optimization of agent. No matter deterministic path control or application-aware traffic steering, it all help agent communicate more efficiently and more reliably and with high performance. Next slide.
Jiaming Ye: And IPv6 cover IOA basics like addressing and service assurance, but for complex agent interaction, IPv6 should be further improved in security. Back in IPv4, NAT accidentally hid the internal devices from the outside and protecting them from direct attacks. While the disappearance of NAT make agent directly exposed to the public network and are globally addressable. So we need to established an advanced security for the IPv6-based IOA, like fine-grained firewall policy, ACLs, identity authentication to control access based on identity, monitor behavior and detect anomalies. Then temporary addresses—these privacy extensions help protect a topological location and identify—identity from being exposed to information collector. But for some agent, they require long-life session to achieve the state synchronization and task continuity. So we need more smart address management like dynamically selecting address type based on task sensitivity and communication patterns, or setting fixed identifiers at the application layer that are independent from addresses. Next slide.
Jiaming Ye: Third, new attacks are emerging that explore IPv6-specific features. For example, IPv6 gives tons of address—addresses. It means hard to scan, but more agent and IOA devices also means more attack sources and being used to amplify attacks. The problem is the old traffic analyzing and scrubbing tools are originally designed for IPv4. If are used for IPv6, they may face performance issues. In addition, there are some attacks aimed at SRv6 like forging super-long section—segment list, path loop causing bandwidth exhaustion and traffic amplification. Therefore we need to enhance threat defense from three perspectives. First, refine the threat detection rules and improve traffic scrubbing performance for IPv6-specific attacks, and accelerate the design and the development of IPv6 security mechanism. Finally, introduce AI-driven real-time traffic analysis system to adaptively learn behavior and rapidly identify anomalies and boosting defense accuracy and responsiveness. Next slide.
Jiaming Ye: Finally, the current monitoring system provide insufficient support for IPv6 like inconsistent handling of packets, insufficient utilization of specific fields, or temporary address hindering traceability. So we need build a comprehensive IPv6 native network observability to ensure continuous agent visibility and timely anomaly detection. Next slide. So that's all my presentation. Any question?
Shi-Ping Xiao: Hello, Jen, you are the first.
Jen Linkova: Yeah, Jen Linkova. First of all, I'm a bit confused about SRv6 here. So you basically trying to say that any network for AI agent would need to implement SRv6? Is it like mandatory mechanism? Because I looked at the draft and I feel like we should not probably dictate how to build the network, right? What routing mechanism should be used? I might want to use MPLS, I might want to use SR-MPLS or whatever, right? Especially if your communication requires to be outside of limited domain, right? Because SRv6 across the Internet might be interesting. Uh, secondly, I am not sure about the point of long-lived sessions. If you think that you need sessions which should live longer than valid lifetime of an address, you just need to maybe provide recommendations what kind of valid lifetimes should be configured on the network like that, right? So strictly speaking, there is no problem for address to become deprecated, right? It's gonna still gonna be used for communication for existing sessions. So maybe yeah, maybe that section of your draft just need more guidance about what lifetime settings such networks need to have, instead of just being generic and saying that you might have problem with temporary addresses. Thanks.
Shi-Ping Xiao: Jen's first point is why you talking about SRv6? Because she feel that, you know, SRv6 or MPLS or anything can be okay. Her second point is about the long-lived session. If you have any comments, I think that you can if you have any feedback you can do it now or maybe you want to take it to the list?
Jiaming Ye: In my opinion, this draft is just analyze and reasoning based on the current situation, but we say basically in IOA, IPv6 I think it's mainly for the addressing and service assurance. That's my thought. So and if you any question—if you have any question we can talk it later, maybe in the mail list.
Shi-Ping Xiao: Okay, Eric.
Eric Vyncke: Eric Vyncke, Cisco. It looks like it's quite a broad scope document, going in many direction. But there is one direction that I was kind of shocked when I see the slide is that you say "the absence of NAT made IPv6 not secure". And for me this is a shocking argument because NAT for me is not a security feature.
Jiaming Ye: That's just my opinion.
Eric Vyncke: I think IPv4 it's intentionally provide a obscurity for—for insecurity. But if we use IPv6 and the agent will be exposed to the public network compared to the IPv4, it's—it's a slight insecure.
Eric Vyncke: No, what you just said is a firewall thing. It's not a NAT thing, right? For sure, exposing addresses to the outside could be a security issue, but you fix it by a firewall, not by a NAT. Again, this may be religion. Thank you.
Shi-Ping Xiao: Any more comments? Well, if not, we conclude this presentation and also conclude our meeting today. We have quite a few situations today, but with everybody's support and patience, we manage to go over all the presentations. So I really want to thank you for your contribution, for your support and for your patience. Thank you. [Applause]