**Session Date/Time:** 18 Mar 2026 03:30

Sure, here's a transcript of the video:

**Dhruv Dhody:** Hello, everyone. Welcome to IAB Open. I'm Dhruv, and this is Ying-Zhen. I'm your new incoming IAB Chair. We also have Tommy, who is online. Tommy, can you say hi, or is this too awkward a time for you?

**Tommy Pauly:** No, very happy. Hi, everyone.

**Dhruv Dhody:** Yay, so Tommy is our outgoing IAB Chair. Tommy, would you like to say something?

**Tommy Pauly:** Sure. Mainly, I've been very happy to be on the IAB for the past six years, and I'm really looking forward to seeing where the incoming and continuing IAB is going to take it. Really excited to have Dhruv chairing us, and really excited that we're continuing these open meetings. I think this is a great way for the community and the IAB to have a dialogue, and yeah, thanks, everyone, for being here.

**Dhruv Dhody:** Thank you. Please join us at the plenary when we will say goodbye to our outgoing members from our leadership. 

So, let's start the meeting. This is the [Note Well](https://datatracker.ietf.org/meeting/125/materials/slides-125-iabopen-welcome-and-status-update-00). Yes, this is IAB Open, but this we still follow the IETF Note Well. By registering to this meeting and joining us either online or in person, you have already agreed to these terms. If you have any questions, clarifications on what that means—the various different RFCs that are linked—please ask us and anybody from the leadership, who can easily explain to you what this means for you. But please follow them and agree to these terms.

What is IAB Open? As Tommy was just saying, this is an activity for us from the IAB to come and share things that we are doing with the community. This could be technical and architectural topics, which you can see from our agenda. We also are the body that is responsible for all the liaison relationships, so we always have an update, and this time also we have that. Our goal is to increase the visibility of IAB work, and also an opportunity for the community to give feedback to us as we continue our activities and start new activities at the same time.

Please reach out to us. Email is the best. When you send us a message on iab@iab.org, it goes to all the NomCom-elected IAB members, plus the liaisons, the IARTF chairs, some secretariat staff—so be aware of that. You can also reach out to an individual IAB member if that's needed. For topics where we need to discuss bigger architectural discussions, the list that we use is the architecture-discuss list, and for liaison-related queries, liaison-coordination@iab.org is the one that you should use. And we also had a liaison coordination hour this week. Continue to engage with us on these matters.

This is an update of our documents. We have some workshop report. We also have our workshop report on our agenda, which is brand new, recently completed in December. We adopted a document out of the EDM technical program, which is the IAB protocol greasing, so we will be doing some work there. And of course, we continue to work on the liaison documents, 4052bis and 4053bis, and once we have completed the IAB process, we will give this to Roman, who will complete the process at the IETF as this is a BCP document that needs to be published under the IETF stream.

So, some updates. In the past at the IAB Open, you might have heard about us—heard us talk about—the WSIS+20 process. We wanted to share the update with the community. The outcome at the UN General Assembly was adopted, and by consensus, in December last year. We, as technical community and as IAB, asked for permanent mandate for IGF, which we could share has been secured, and the multi-stakeholder model reaffirmed, as well as the role of the technical community in this multi-stakeholder model has been clearly established. Now we have to do the hard work and, as a technical community, continue to engage in that process, which we had asked for and which has been done.

Apart from that, one activity that IAB does is outreach. We have a new outreach coordinator, which is Yaroslav, sitting right there, so if you have ideas on outreach, reach out to Yaroslav or the whole IAB. The two activities that we wanted to highlight was the one in the past ICANN meeting in Mumbai. We did multiple sessions, we reached out to the Government Advisory Committee (the GAC), the ALAC (which is the end-user community), as well as a "how it works" the IETF session more targeted towards fellows and newcomers and folks in general who are interested in understanding how IETF works and how IETF fits in the whole internet ecosystem that we have built. Apart from that, we reach out to operator communities at various venues. In the past, we have done at RIPE and NANOG. This time we went to APRICOT and APNIC, and Warren gave a presentation on what's happening at the IETF, what is the new topics, what are the BoFs, and how to get more operators engaged in our IETF processes. So, these are the updates based on outreach and our IG process. And with that, let me pass this on to Ying-Zhen.

**Ying-Zhen Qu:** So, this is the agenda for today's meeting. Although we only have a one-hour session, we do have some very interesting talks. After this, we'll have a liaison update from M3AAWG by Bron, and Jason and Tommy will do a workshop report for the IP Geolocation Workshop. And after that, we'll have an invited talk from Xing Li, and hopefully you all enjoy the—all these talks. Any question about the agenda? Anything we need to add? Okay, if not...

So, the IAB has two Help Desk sessions at this IETF. If you missed the one that on Monday already happened, we do have another one on Thursday. So, you can come to us, ask anything about IAB or anything IETF-related, or you just want to chat about IETF. 

So, we have a EDM technical program, which is not meeting this time, but you can look at the draft and look at their work progress. And with that, I think we are going to our liaison update.

**Bron Gondwana:** All right, thank you. I am lazy, so I just copied Barry's slides and scrubbed out some items. So, if we could go to—oh, I've got a clicker! Fantastic. Thank you. Hi, I'm Bron Gondwana. I am your liaison to M3AAWG. I'll talk a bit about what M3AAWG is, and I'm here to answer any questions as well. So, I'll get through this fairly quickly and then pop up with your questions. 

I've got the date wrong, but it's that date somewhere in the world. 

All right. [M3AAWG](https://datatracker.ietf.org/meeting/125/materials/slides-125-iabopen-m3aawg-liaison-summary-00) has a long and complex name, and basically it's an email anti-abuse and texting anti-abuse as well working group. It is very different from IETF in that M3AAWG is a closed environment, so to speak. What happens at M3AAWG stays at M3AAWG. The idea being that you don't want to let your adversaries know all of the techniques you're using to try and block their bad behavior. Also, for a lot of the members at M3AAWG, they might have roadmaps about new features that they don't necessarily want the world's press to be talking about before they're published. So, M3AAWG publishes a bunch of best practices about email and it talks a lot about standards that are developed here at the IETF. 

All right, I'll skip through these. You can download the slides later. There's a lot of members from a lot of different places. There's a few of us who are at IETF who go to M3AAWG. There's quite a few people from M3AAWG who I encourage to come to IETF and work on the specs, and a lot of it is about the stuff we develop here gets used out in the real world by a lot of people who are at M3AAWG. So, they get to see how IETF specs work in reality. Some of the work that's happening here at the IETF started in discussions at M3AAWG, and then we said that should be taken to the IETF—that's something that fits in existing work that the IETF's doing. There are probably five or six regular M3AAWGers here at IETF at the moment. 

All right. Obviously, AI is a big topic at M3AAWG as well. It's a big topic everywhere this year, and there's a lot of stuff, particularly in the IANA space as well, where registrations happen. All right. I'll skip through these slides fairly quickly, too. M3AAWG publishes best practices on how a lot of the stuff we do here is used. It's definitely worth going to the published documents. This stuff is available to everybody. What happens in the M3AAWG meetings does stay at M3AAWG, but M3AAWG does publish its best practices for everybody. So, if you're doing anything developing in these spaces, it's definitely worth looking at the best practices published by the people using them. 

All right. And that's what I've got here. So, does anyone have any questions about what's happening at M3AAWG?

**Dhruv Dhody:** Any questions for Bron? 

Well, thank you. 

**Bron Gondwana:** There you go. And I'd like to finish by saying thanks to Barry for the slides and for having been the M3AAWG liaison for many years. I hope to do as well as you did. Thank you. 

**Dhruv Dhody:** Thank you. Oh, spoke too soon. All right. 

**Speaker 1:** I am—I'm sorry, I had no time to connect to—to the agenda. So, pleased to meet you. That's really a long time I didn't go to M3AAWG, but it was a good moment of my life, so I really enjoyed being there. One thing I don't know how M3AAWG evolved, sorry, a bit loud. Are you—are you dealing as well with SMS issues and so on, or is it just mail, or just for me to know?

**Bron Gondwana:** Mail, SMS, RCS, all the "shaken and stirred" stuff has definitely been an area of a lot of discussion at M3AAWG and a lot of the—the other kind of abuse that goes over the top of it, too, so some of the—the attacks that are happening on individuals, the scams and spams and stuff are definitely big topics. 

**Speaker 1:** No, that's good to know. So, I'm SG17 Chair, so I'm new Chair, so I have a question four that is dealing with spam and so on and which is in the context of ITU an interesting one. There is something we recently discovered, which is the SMS Blaster problem. Is this something that you—you have identified as well in M3AAWG?

**Bron Gondwana:** I don't do much in the SMS space myself, but there are groups at M3AAWG working in that, yes. 

**Speaker 1:** Okay. So, we—this is a very amazing attack. I mean, people basically creating an infrastructure that they can put in a backpack, on a bike, on a car, and they move around in the city, and it's an SMS Blaster. And we got that in Geneva, we got that in London, and we all have a very bad feeling about what is really the intention behind in the long term. So, okay. Thank you. 

**Bron Gondwana:** Thank you. 

**Dhruv Dhody:** Thanks. Anyone else before I run away? No? Thank you. 

**Jason Livingood:** All right, ready? All right, thank you. I'm Jason Livingood, and we also have Tommy on the online remotely, and we're going to talk about the recent [IP Geolocation Workshop](https://datatracker.ietf.org/meeting/125/materials/slides-125-iabopen-ip-geo-workshop-report-00). I threw in the Meetecho chat a link to the document if you'd like to take a look at that and give us any feedback. 

So, we had a workshop in December. It was virtual across multiple days, and we focused each day—each of those three days—on three distinct topics. The first day really went over the use cases for publishing, discovery, and consuming IP geolocation data. This is used extensively today, so we wanted to really understand what all the use cases were, and I would say we were surprised by the variety of those use cases—very creative uses, I would say. Then we talked about areas for improvement, so essentially within the existing system of IP geolocation, are there things we could do to optimize it, to improve it marginally? And then the third day was really the out-of-the-box thinking day, which was, are there better ways to solve this problem that aren't rooted in a particular approach that we've used today? So, what does that look like? 

And so the first question is, you know, why were we talking about this? IP addresses, you know, as they were originally conceived, were to support routing of packets from source to destination, not to carry geographic meaning. But there is now extensive assumptions about geographic location associated with IP addresses. It is widespread and it's ingrained deeply in the way the web and other applications work today. And so we explored that, and that's documented quite a bit in the report, so worth looking at that. 

Just to touch on some of these things. Why is IP address geolocation used today? Some of these things are around optimization of the user experience or network behavior. So, there might be some language and regional settings that are established based upon where a destination thinks you actually are based on your IP. But also things like finding relevant nearby content. So, for example, you might say, "Oh, I want to find pizza near me." Well, you want to be presented with results that are actually near you, not in some faraway city. Of course, it's used extensively for things like content delivery networks, where the CDN is trying to give you an answer to a DNS query, for example, that is for cache that is very close to you geographically or in network distance. So, that's used very extensively. 

And then there are a bunch of things that are enforcement-related, and these aren't necessarily like law enforcement per se. In some cases, it's related to contract enforcement. So, as an example, video streaming on the web is a pretty big use case, obviously, and content, let's say a movie, is licensed for viewing in a particular country. And so you have to do some validation of where is the user trying to consume that—does it comply with the rights licensing for whatever that movie happened to be or TV program, you know, like live sports event and so on. There are also legal and compliance-related things, like this particular content is allowed to be viewed in a particular location versus is not, and that has to be enforced. Some of you may see this today. For example, I noticed some of the AI agents I was trying to go to or sites said, "Oh, sorry, it's not licensed in this jurisdiction, not available here." So, that's an example. 

And then, of course, disaster relief and law enforcement. There are some emerging use cases around emergency alerting, you know, where it's like, "Hey, there's a tornado coming through this area," and, you know, can we present those alerts to IP addresses that are in a particular location and some law enforcement things. 

So, current mechanisms, they're really a couple of RFCs you can look at these today. We have a CSV format. There are some other organizations, SVTA, that are using a JSON format, and so, you know, they're very similar in the information that they convey, but it's just sort of a formatting question. But 8005 is out there, and one of the esteemed authors is here in the front row. And 9632 adds discovery and authentication, which were, you know, good incremental changes. And apart from that, there is just this enormous amount of sort of bespoke activity that happens. You have a lot of very diverse GeoIP providers. They tend to serve very different marketplaces with very specific use cases, but they're adding a lot of their own metadata to that information. 

And in addition, what was also interesting to us is that they've sort of assigned, I guess you could say, sort of trust or confidence levels in some of the location information associated with IP addresses, because they've learned over time certain sources that they're pulling information from are more or less trustworthy. And so, you know, there's some level of trust and confidence there, so it's not a binary like "this is true" or "not true," it's sort of degrees of trust. And so that was very interesting to learn about. 

But we also found that a lot of the existing mechanisms have trouble when an IP address tends to be shared widely and doesn't neatly map to a location. And so this might be in two primary cases that you see today. One would be a CGNAT. You might be on a mobile network and using a CGNAT, and it might not be the correct location because your traffic might be tunneled up to a CGNAT where you're then exiting through a node. Or it may be through mask and proxies that you're exiting through, you know, like Apple Private Relay and something like that. Or, most interestingly, you might be using a LEO ISP service like a Starlink, and you're constantly coming down through different exit nodes and you're sharing IP addresses across a very wide swath of the sky, so to speak. 

So, we also found that there was a lot of things that IP geolocation could actually mean, and this caused a lot of the confusion around, you know, how it's sometimes perhaps misused or tries to be used in a way but causes a problem. Sometimes it means a physical user location, or a physical location of a home, or an egress location. So, that could be egress from an enterprise or ISP network locally in a city or something. Could be the location of network infrastructure like a server cache or data center, or it could be a regulatory jurisdiction. That could be like a state or a geographic region. 

So, we have a very long list of gaps and issues. I encourage you to take a look at them for the sake of brevity, you know, summarized in these four bullets here. There are a bunch of privacy and security issues. You know, IP addresses, you know, and users consenting to their location being revealed, you know, that's a sort of a gray area. Of course, one of the things that was mentioned in the report or discussed briefly is that there's much richer location data that comes out of mobile devices and applications, so some of that location data is being derived in other ways now, where it might have been different in other ways previously. Of course, issues with the Geofeed format. So, we had sort of these CSV formats and JSON formats, and then people modifying those to sort of standard, you know, to extend them. 

And then deployment and ecosystem issues. We found, very interestingly, and we occasionally have seen this when you've come to a different IETF meeting, where you have sort of this delay issue. Even though the IETF has updated its CSV file of Geofeed data and that information may be picked up by a list provider, that list provider may have different rules for determining once the IP is seen again when they decide to update their feed. And so, for example, I've seen this at prior meetings here where it's like, "Oh, it shows your location being like the prior IETF meeting." And so you have this even though that list was updated months prior, so that was often an issue that came up as a pain point. And then location issues where there's this gray area between regions and states and where exactly are you, and that causes lots of issues and can be very frustrating for end users in particular. 

So, why change? You know, there are some obvious gaps that we talked about. In addition, it was very clear that Starlink and future LEO networks are really stretching the notion of location of IP addresses because of the way that IP addresses are shared in those networks. And there are a whole rich set of research papers that were very interesting have been presented, you know, at IRTF like through ANRP and other venues, which were really exploring this. So, really interesting work there. There are also evolving regulatory requirements that add additional pressure on providers to have accuracy, especially when it comes to compliance for those things. And the bar for security and privacy continues to move forward, of course. 

So, in terms of future directions for change, there was a clear need to update the Geofeed formats. We've talked about CSV and JSON being the two primary ones, but it's clear also that there are some tweaks to the formatting there in each one of those areas that can improve things. But also there were I think at least three and they're at the end of the report suggestions, maybe four, three or four suggestions on entirely new mechanisms for conveying geographic data in the midst of a packet exchange or inside of a user session that could be potentially be authenticated, could rely on user consent, or could just be, you know, more accurate and modern and not relying on IP address information. 

So, the bottom line coming out of the workshop was that IP geolocation is by no means going away, no more or less than NAT is going away. So, how can we optimize the existing system through some incremental improvement? But at the same time, there are some entirely new mechanisms that could be standardized that could be even better for future applications to be built upon. 

And that's it. Any questions? 

**Dhruv Dhody:** Yes, people in the queue. Yes, Eric, go ahead. 

**Eric Rescorla:** Yeah, Jason, I'm frankly kind of disappointed to hear you describe the consent issue as a gray area. Um, you know, it seems to me like the IETF has leaned in pretty heavily on security and privacy, and the idea that you can be unconsensually located, you know, and have a permanent location permanent address that like reflects your location and your identity is a serious bug in the IETF architecture, the internet architecture that's existed since the beginning of time and one that we are attempting to fix with technology like Mask. And sort of like the answer that, like, what we're going to do is invent new mechanisms to disclose this information consensually—like, we've already run this experiment other times with things like privacy sandbox, and the answer is not that people stop using the old mechanism, is that they use both mechanisms and the thing is worse. So, what I would like to hear from the IAB, which is in charge of the architecture, is some thinking about how to remove this privacy hole, not about how to create new privacy holes. And, you know, why don't you answer that problem and then we can discuss that approach to the situation because we—I mean, I feel like that's exactly the story that one heard about things like privacy sandbox, which was that we were going to eventually get rid of third-party cookies, but in the meantime we had to create new mechanisms for tracking people. So, like, I really don't think that's a good way to think about the problem. The problem that we think about the problem is break-before-make, not make-before-break. And I'll get off the stage, I see a lot of people behind me, but... 

**Tommy Pauly:** Could I respond to that? Because I agree totally that—and this is something where, you know, not everyone in the workshop but a lot of people in the workshop were bringing up these privacy and consent fundamental problems. I think two of the things that came out and I think it's reflected in the report, you know, one, it's not only for the future directions, but even for the people who just want to do geolocation for other reasons, having more consent and intent would be a good thing. And I think there's enough evidence that the use cases that people have are not going to be going away. And so in order to wean things off of using IP geolocation, we need to have some mechanisms to satisfy these use cases—if it's like someone for enforcement of something needs a way to validate this—to replace that IP geolocation such that at least it can be consent-based. And then I think that's where also things like Mask would then come in that like you can then ramp up the usage of things that obfuscate the IP geolocation and reduce the quality of that and remove it. But I don't think there's a way to just say, you know what, this is just going to—the use cases are going to go away and people are going to not have to deal with it anymore. 

**Eric Rescorla:** Well, I agree use cases aren't going away, but I guess what I hear is we're not going to work on the problem that is the important part and we're instead going to work on making the problem worse. And so what I want to hear from the IAB is what they're going to do to actually resolve this problem as opposed to creating new mechanisms. And like why don't you answer that problem and then we can discuss that approach to the situation. Because we—I mean, I feel like that's exactly the story that one heard about things like privacy sandbox, which was that we were going to eventually get rid of third-party cookies, but in the meantime we had to create new mechanisms for tracking people. So, like, I really don't think that's a good way to think about the problem. The problem that we think about the problem is break-before-make, not make-before-break. And I'll get off the stage, I see a lot of people behind me, but... 

**Jason Livingood:** Yeah, as we move on, I'll just say the notion of location that we discussed and that is really used today in this industry is fairly coarse-grained. It's not a distinct street address or vertical location in a building. It's like a city—you know, something along those lines. But yeah. Next up? 

**Mallory Knodel:** Mallory Knodel. I briefly scanned the report, so thank you for writing it. I think it is an important area of work. I'm definitely on Ecker's side where I think this has to be solved. But I'm not going to necessarily speak to that or repeat what he said. I wanted to answer the question about where this work should go. I looked desperately to find participation from the RIRs in this workshop. I see RIPE, but mostly because they have RIPE Atlas, it seems, not because the ASO is taking any—well, maybe that's a question. Have you looked at this from the ASO side, from the numbers side? What are they doing about it? Because I feel if we're talking about fine-grained versus coarse-grained, that's certainly one way to go, because also I'll say I love to see cooperation between, like, regional bodies and the IETF more, I don't think that happens enough, and also because they are jurisdictionally placed to deal with some of the thornier use cases like law enforcement and so on and so forth, because they're, you know, policy-related more contextually aware, right? So, just seems to me to be a really obvious gap, and I was super surprised to not see anyone from AFRINIC or APNIC or anything on that on that list. 

**Dhruv Dhody:** I'll disagree on the APNIC part. We do have more people participate than were presenting papers or had accepted papers. So, we did have a number of RIRs in attendance to participate in the discussion. They just weren't presenters, which I think may indicate that they don't have ready solutions per se. But we did agree—I agree and I think we agree that it's good to have them involved. 

**Mallory Knodel:** I think the RIRs don't necessarily have solutions. They also have a lot of pain, right? AFRINIC has a lot of pain around, um, regional allocation of IP space, and RIPE as well. I mean, hello, Ukraine-Russia, right? So, maybe it would be worth engaging them on some problem space that they're seeing on the numbering side to come to the into the middle about solutions. 

**Dhruv Dhody:** Mallory, point taken. We continue to engage with all of them, and in fact in most of the program committees we saw this topic bubbling up and we will continue to engage. Next, please. 

**Speaker 2:** So, if you want to build something new, of course you have to get the requirements right. And I see this space very hard to define in terms of requirement, especially around the consent and issue that has already popped up as the hard one. There are multiple cases, real-use cases, in which users want to be located to get a better service, whatever. There are cases in which the service provider wants to locate the users and maybe the user doesn't, so maybe the a way to deny the consent. There are maybe cases in which the service operator wants to locate the user and the user does not have the legal right to object, especially when the service provider needs to locate the user to apply the appropriate set of policy rules and regulation. And I'm not sure you can find a way to keep the three use cases together, but if you don't, then you will design a a system that will get pushback, especially from maybe the policy community. So, make sure, I'd say, that you talk to the policy community and the regulators as one of the set of the stakeholders if you want to design something. 

**Speaker 3:** Yeah, I mean, I want to reinforce something that Ecker said, is that we are not going to get a good system by building a good system. If we build a good system, as Ecker said, people will keep using the bad system because it's easier, just like saying that we're going to get rid of cookies because we have something else or whatever. So, I think the only way to make this system evolve is to burn it to the ground. And to make damn sure that we have as many ways as possible to inject noise, falsehood, whatever, re-number the networks, whatever you want, but we should study that. We should study how do we make that thing just impossible to make work right so that people are forced to do the right thing. And that should be the work for the IAB, I think. 

**Speaker 4:** I see time is over, so I'll make this very brief. I think from an architectural principle, the principle we're striving for here is that geolocation data and routing information are completely distinct, and the mechanisms you use to reveal your location should require your consent, and the mechanisms which are used to query that location should require your consent. Those, I think, are architectural principles that could be articulated by the Internet Architecture Board and could be the basis of work—or are already, I think, the basis of work like Mask. I will point out we have tried this in the past. GeoPriv was an effort I was involved with for many years, and it was frustrated by requirements from e-911 and other places that location be attested to by trusted entities as opposed to asserted by individuals for variety of reasons. I think the—there is very little chance of us making that architectural principle plain without then facing a great deal of friction in doing the work. But I think it's worth facing that friction and doing the work. Thanks. 

**Speaker 5:** I think the problem is to be split between IPv6 and IPv4. As for the scarcity of IPv4 addresses, majority cases are with NATting, so geolocation can arrive only to the legislation and is suitable to the direct usage, while for IPv6 theoretically it is possible to arrive at more precise position, but then there is the issue of privacy. I'm trying to drive the issue—the problem of source privacy, so this has to be linked to the consent of users to allow the precise location. Thank you. 

**Dhruv Dhody:** Thanks for all the input. We are still discussing this on architecture-discuss list. Please give your feedback, read the report, and thank you for an excellent discussion. And let's move to our next invited talk, Professor Xing Li, who was a past IAB member, and since we are in the region, it was really good for us to have him. 

**Xing Li:** So, good morning. Okay, so this is my talk. It's some kind of high-level thinking, actually. 

Okay, actually I'm working for internet for more than 30 years, and we built three networks. First is actually the first internet national backbone in China, which called CERNET, as we from IP over X.25 to 100G WDM things. And second, actually because there are about 320 million students in China, so when we start CERNET, we don't think we have enough IPv4 address, so we started IPv6 back to 1997. And one thing actually we did a good solution, that's a single stack IPv6. By that time people talk about dual stack. However, we think we should do something different. And it's quite lucky we did that decision because like software IPv4 over IPv6 and later translation technologies on top of this IPv6-only. And so about 10 years for CERNET, 10 years for CERNET2. And now CERNET2 is IPv6-only still, and we are building the third network called CERNET3 or FITI (Future Internet Testing Bed), which is also a IPv6-only backbone. However, because we are facing the problem of walled garden. 

So, actually CERNET2 consist of 4k backbones, independently individual atomic systems. So we are thinking the application layer like Facebook or WeChat, they are walled gardens in the application layer. Probably for network layer we should do something. So that's the things that's ongoing project. 

And so talk about resilience, back to the Paul Baran's report, centralized, decentralized, and distributed. My belief is only fully distributed can support resilience, or at least decentralized is better. And I really enjoyed IRTF working group Decentralization. 

Also, then the internet architecture that's IAB's job, hourglass. And actually it's quite interesting, like connectionless, best effort, end-to-end. Should we still keep this or improve? Actually, for example, SRv6, if every hop has a SRv6 segment, then probably back to connection-oriented things, right? And also best effort, where the AI require high quality or something like that. So... 

And CDN. So, people talk about my students ask me still end-to-end works, and CDN and those kind of things. I told my student they still end-to-end but there are two segments, to the cloud, user to the clouds, and servers to the cloud. So, still it's end-to-end. 

Another things like take about this layered structure. There are two things in the AI age, my understanding. One is the two revolution of the tools. Each layer we can use LLM to improve the performance or whatever the functionality. But more important, people talk about seven layers model, right, OSI. However, in my lecture, I told my students there are eight layers because above application, the below humans, there's AI layer. So... 

Anyway, another things actually the current public internet, especially last year there are some big giants, I cannot mention the names, but they are resilience killers, right? That cause several problems. So probably IAB we should find those kind of bottleneck and try to improve that for improving the resilience. 

And so, second thing is the trust, like SSH is one-time trust, right? And heretical or centralized, that's DNS, DNSSEC, and BGP actually quite interesting, that's the some kind of web of trust. It's distributed. However, we try to improve the routing security as RPKI, we need trust anchors, even that's five trust anchors in each RIR, but still that's some kind of heretical case. And web, actually that's the forest of CA and we heavily rely on TLS. So, actually I believe probably fully distributed like blockchain, I don't know, but there's some ideas. However, I like the idea of forest of trust, and I like the idea of Professor Lishang Zhang talk. The names should be global, but trust can be local, so forest, that's probably the way to go. 

And next thing is the internet fragmentation. Actually, the original idea is from Vint Cerf's report, IGF report, and I really like that report. So in my way to present, there are technical fragmentations. Actually, IPv4 and IPv6 not compatible, that's actually introduced some kind of fragmentation technically. Also DNS, like it's quite, quite important in control plane and hijacking of the DNS or those kind of things. However, even if think in a wide sense, the new gTLDs is some kind of fragmentation. Technically, it's unique. However, for example, my university, Tsinghua University .edu .cn, it's unified, no problem. However, because new gTLD, Tsinghua.ai, is that Tsinghua University or others? So probably semantically it's not—breaks the uniqueness. Whatever. And security, there are firewalls, right? And governmental fragmentation, geopolitics or those kind of thing. And commercial fragmentation, that's walled garden basically, those kind of thing. And AI, the computational ability and data buyers and regulations, they are introduced the fragmentation. My belief is single internet connect everywhere. However, in reality, we have to fight against those kind of things as engineer. 

And one thing for so I was in IAB back to Snowden event in 2013. I believe that's the only plenary session in the morning session, that's because there are five questions and actually that's the time IETF really push HTTPS. And if you take a look of the pictures, I was on the stage. I actually said some different voices because if it's every HTTPS, then actually in the old days clear text, then gateway or whatever great firewall can reset TCP session, so non-sensitive words can through pass. However, HTTPS there's no way to real-time decryption, so fragment everything. So... anyway, but I believe the HTTPS is a good solution because currently. However, that's the thing introduce fragmentation. 

And for technical V4/V6, actually I mentioned earlier CERNET2 is IPv6-only. So actually we really work on translation technology. Three things, one is 4 and 6 are not compatible, so you cannot use destination address as V4 and source address is V6. However, through translator, you can see the real IPv6 can talk to real IPv4, but the real IPv6 actually think the other side is IPv6, but by translation that's a mirror of the real IPv4. Using IPv6 to present IPv4 is quite easy because a subnet is 62 bits, but the public internet address global internet IPv4 address is 32 bits. However, how to represent IPv6 in IPv4 world based on algorithm, not the net states? It's not difficult. However, subset of the IPv6, that's the RFC 6052 and RFC 7915, those kind of thing. I feel quite good because based on those translation technology that's NAT64, 464XLAT, MAP-T, those kind of things. And actually the current modern operating systems, those kind of translation technologies build in. Android, iOS, macOS. Where I don't know Microsoft is saying to intro I mean build into the Windows last March. However, it's still not reality. If somebody from Microsoft I would like to talk. 

Okay, I'm the EE background. So, actually we do the linear translation between V4 and V6. That's the thing I mentioned the 6052. However, we did some nonlinear or one direction mapping. We do non-station remapping, which is privacy address or something. Recently, actually we did crypto-based mapping for addresses. That's interesting. My grandchild already, my the final master students, he asked me to do mapping. So, I told him we did all those kind of things. So, how about AI-based mapping? And he later came to me and said we can use language model to do mapping. I was surprised. I thought, okay, address is not really language model. It's overkill. However, he insist and we publish paper. Actually, the whole things is before ChatGPT introduced. However, when his graduation, he try to publish we try to publish a paper. The original title is IPv6 translation or something like that. I told him it's not good. So, later we change to IPv6 Transformers. So, that's the current paper title. Anyway. 

So, the AI challengers, I believe the network performance training, actually it's R-M-A. So, influence, that's important. And fragmentation, actually for access if you try to access OpenAI, it's double firewalls. In China, it's blocked. However, the China IP address is blocked by OpenAI, as the earlier presents. And centralization, actually AI was controlled by big, big giants, right? And agents, that's for people you have the ID, you have the face, you have fingerprints. However, for agents, we don't know. And so, I believe it's quite important like in internet the cartoon on 30 years ago, on the internet nobody knows you are a dog, and currently nobody knows you are robot. 

So, two things, actually I believe AI agents need IPv6 address because it's servers, not clients, right? And for internet we really not want everything use cloud to relay, we want end-to-end. So, I was surprised there are no much talk on IPv6 related to AI agents. That's the thing I believe IPv6 important in network layer. Another is the trust, and my feeling is important is the trust we should use DNSSEC, and actually I really push IPv6 address certificates, and luckily enough Let's Encrypt announce they can do automatic sign of the IPv6 addresses. 

Okay, so because of those kind of fragmentation we engineers cannot really convince the politicians or others to change mind. However, I believe our job is try to okay, my idea is back to the beginning of the internet. So, network of networks. Whatever the geopolitics or national disaster. If the servers inside a network and the clients inside network and robots, then internet should work. However, DNS actually they are the resolving chain broken things, we should solve that. And RPKI if it's isolated, so we still need a mechanism to do back to the beginning of the networks. 

And another thing actually in my mind I like to call it impossible triangle. Because resilience, trust, and controllable, because the government like to control internet. This is a impossible triangle. We can do distributed and well maybe blockchain or something to make resilience and trustable a reality. And if it's heretical thing, then controllable and trust is okay. But if it's fully mashed, then distributed resilience is impossible. So, maybe that's a one of the fundamental problems IETF should work or researchers should work. 

And so IPv6 again, originally internet for connecting machines, then mobile internet is for connecting people. And we originally think IPv6 is for IoT internet of things. But after ChatGPT, my only belief is actually the more users of the internet is robots, not our human beings. And so uniqueness, we have to keep the distributed nature of the internet and maintain the uniqueness of the address, names, and protocol parameters. That's our job. 

Finally, actually in RFC considerations, originally it's none, later we have security considerations, IANA translations, and IETF is working on human rights considerations. My suggestion or my feeling is starting from now we should put AI considerations in every published RFC. Thank you very much. Any questions? 

**Dhruv Dhody:** Questions, please. 

**Speaker 6:** So, thank you, Professor Li. I think very good presentation. I have a question about IPv6. You just mentioned IPv6 will be important for agent network. So, except the address number, do you—can you give some more benefit about the IPv6 for agent internet? 

**Xing Li:** Oh, okay. Actually, my idea is quite simple. Like agent, then basically it's some kind of HTTP or HTTP servers. However, you need some kind of even self-signed thing. So you can use HTTPS with some kind of address certificate. Now, that's your agent, not hijacked agents use that thing. Another thing, IPv6 address certificate's advantage is it's naturally coupled with routing. So inside your network, if you can make the certificate trustable, then even the outside connection is break broken, still you can make connectivities. And DNS certificate, maybe we need double certificates, DNS certificate for names and IP address certificate for routing. That's my idea, and our research group is working on this. 

**Dhruv Dhody:** Any other questions? None? Then we can go to the open mic session. If anybody has any other concerns, please come. 

**Speaker 7:** Yes, so stay on stage. Just sorry. It's the question for you. Yes. Also again, I think it's a very good presentation. Um, so on the path that is relating to AI, and we've just done the Catalyst BoF just before. You have a point on on the fragmentation on centralization. I forget which slide it is. And again, when we discussed about what should the IETF do here, I expressed the first point about the fact that it's more complex, we are not just dealing with machines to machines, it's intelligence to intelligence. And I'm really concerned we have not yet identified those issues like centralization enough. What I—what I'm afraid of is that when we're going to make some technological choice, we it's very difficult to understand how we map those requirements you put in your slides versus our design. And one problem I have is that we have never formalized a theory of design that could help create the mapping between what you have on your slides and what we're going to do from a bottom-up perspective. And I think we should we should start to work on methodology here to materialize what you show in terms of concrete requirements for for standardization. That's just a comment. 

**Xing Li:** Yeah, I believe I think this is important. Yeah. 

**Speaker 7:** Okay. Thank you. 

**Dhruv Dhody:** James, is this a question for Xing Li or open mic? Either way, please come and speak. 

**James:** Okay, thank you very much. So, it's it's a question, and I think perhaps if the speaker could answer, that will be lovely. So, still on AI and I mean the AI agents, so to say. So, I just want to find out if the speaker will be able to tell us if AI agents can actually affect the operation of DNS system. Is there anything you want to talk about on it? Thank you. 

**Xing Li:** Yes. Okay. Yes. I believe when using robots or agents rather than human being, okay, DNS is the thing actually it's easiest to keep the uniqueness, so I believe DNS is very important even for robots. However, I also try to add IPv6 address certificates, so work together, that's my belief in DNS or DNS extension for robots is very important and then in conjunction with the address. So, that's my belief or my idea. Maybe not correct, I don't know. 

**James:** Okay, so sorry. Just to see for that clarification. So what I'm trying to say is that can AI agents, can they impact on DNS system, either positively or negatively? 

**Dhruv Dhody:** I think in this one minute that we have, I think let's take this discussion to architecture-discuss list. There is lot of discussion about this in the IETF. Watch the recordings of Catalyst BoF and continue this discussion. But let's close the meeting. Thanks, everyone. Thanks for participating. IAB is always available for you to give us feedback, send our queries, and thank you for attending. 

**Ying-Zhen Qu:** Thank everybody's attention. And it's my first time to chair the IAB Open. Hope see you guys next time.