Session Date/Time: 24 Jul 2026 07:00
[00:00:06] Nick Buraglio: Be nice to each other, and let's do some good work. Housekeeping. So if you're in the room, please scan the code before you come up to the microphone. That way we can get the queue managed better. And like I said, we have a very full agenda, so the the more efficient we can be, the better. Same for folks that are joining remotely. You're obviously already in the queue. You're already in the logged in, so please join the queue if you wanna ask a question.
[00:00:40] Chenyi Hou: Here
[00:00:41] Nick Buraglio: is our agenda. Like I said, it's very full. We have a presentation this time. We can try to get back to doing that. Then we have one, three, four, five, six working group drafts, four individual drafts. Then as we have time if we have time, there's a handful of as time permits IDs that we want to go over. We have completed WGLC for 6146 bis. It's going to the ISG for publication as an Internet standard. We've issued WGLC for the NAT64 well known prefix prefix draft that was out, and we've adopted the I p v six only definition, into a working group document. So those are the updates since the last meeting for the working group. And as always, our call for contribution for important works, Brian Carpenter's book. If you're interested in working on that, there's a GitHub repo. It's got pretty good circulation at this point. It's being used as a textbook, I believe, at this upcoming semester in one one or two universities in the Africa region. So if you're interested in contributing to the I p v six textbook, it's open source. There's GitHub repo. Go read it. Do some PRs, and we can we can merge that into the existing text if you're interested. Alright. I think we'll get get to our first presentation.
[00:02:24] Shuping Peng: I want to take this time to remind all the speakers to, you know, observe the time, especially if you have more than 10 slides.
[00:02:36] Philip Thiesel: Yeah. Hello. My name is Philip Thiesl. I'm with SAP. And today I wanted to talk about how to upgrade a giant to IPv6. I have spent my last five years, two years in part time, three years in full time on managing the technical side of getting IPv6 ready. And when I started 2021 looking at this issue, the request was more or less, oh, we have grown concern of RFC1918 space depletion. And we have somewhat of 9,000 Kubernetes clusters in the same RFC1918 prefix. Let's see whether we should go for IPv6 as a replacement. And at that point in time, SAP had been an early adopter somewhat. We added IPv6 support in the upper runtime 2004. And most on prem products support some sort of IPv6. But as the customer base did not really use IPv6, it was not too well tested. And only a few test infrastructures had remained from the initial boom of enabling IPv6. On the other hand, the acquisitions and cloud businesses were at the point that they said no IPv6 because those were delivering much more time pressure and they said, Oh, IPv6 is optional. Nobody cares about. So, to make this a little bit more difficult, we have a multi cloud strategy that allows our customers for at least a bunch of prime products to choose the infrastructure provider. So that means, for example, if you want to book SAP RISE, you can get it on our own SAP cloud infrastructure, AWS, GCP, Azure, and Alibaba Cloud. And therefore, we have to do the adoption for all these platforms. In addition to local offerings in many countries with other infrastructure partners and sovereign cloud infrastructures for governmental purposes. So, how to get this kind of zoo to IPv6? What you need is a strong motivation. And this strong motivation is an IPv6 demand management can't ignore. In this case, The U. S. Governmental mandate for IPv6 only came quite handy. With this very large customer and the clear deadline and more than 200 products affected, you have a large enough risk that even top management cares about IPv6, at least for a while. So for those who have not worked with that mandate so far, a little hint. It requires actions and decisions to enable products being IPv6 only ready. But this is really hard to manage in a big company because you have a lot of parties and people and teams involved in getting IPv6 ready. And they usually don't care about networking protocols. And to make it even worse, the regulation is phrased as an indirect regulation. So it does not say companies have to do IPv6. It says everything the US government buys needs to support IPv6. And it's IPv6 only ready, which does not meet any usual compliance framework. The usual way of taking this in would be through someone at these agencies who has no idea about IPv6 has to put us into their call for tenders. And some salespeople who usually have no idea of IPv6 have to take this in as a requirement. And as a central programme, we try to bridge that and directly transfer the requirements of the IPv6 only mandate into internal standardization to make sure that we have actually a document that's easy to understand for our developers. And the key question for this is at which vantage point is IPv6 really required? So looking at the NIST profiles, SP 500, two hundred-67A, this one is only partially helpful because it's not written as a standard developers usually follow. It's written as a template for call for tenders. And so, what we did is we defined an internal product standard saying the whole portfolio supports IPv6 without functional regressions, irrespectively whether the customer environment is IPv4 only, dual stack or IPv6 only. That means customer can access all SaaS applications, integrations work seamlessly with any customer endpoint, and on premise products work in any IP based network environment. What's not on the slide is we explicitly rule out that we won't require anyone to use NAT six point So an IPv6 only or how we now have this strict IPv6 only customer should be able to work with us without any modifications. So but before you can test the actual products, you have a lot of internal infrastructure you have to upgrade. Developers need IPv6 in the access networks and offices. And development and test landscapes need IPv6 support. And while I had a lot of fear in the beginning that this could be an issue, in the end talking to our office network people said, oh, we have to add an IPv6 support. We we can't do this. We're the middle or we're planning a rollover of our whole address deck. So I asked them, So could you just fold that in into the hardware rollover if you're replacing anything anyway? And they said, Oh, have to think about that. And a week later they came back, Oh yes, we do it. And this is also one of the biggest recommendations I can give to anyone who wants to deploy IPv6 at large corporations. Don't try an ambitious timeline. Try to look where are processes where a lot of stuff is touched and try to fold in IPv6 rollout at exactly these places. The other important part is you have to get it into run times and random environments. And we have a lot of these. We have the ABAP environment, which is the most famous for the applications. We have Cloud Foundry as container runtime. And we have Kubernetes, our own our own Kubernetes based runtime. And for all these, most of these are part some of these are open source backed. And we made sure that also these get updated. And the lesson learned there is, so Agv6 is pretty mature across most language run times. But there's especially gaps in documentation. So if you look at the Python documentation, you find that most examples are v4 only and you have to dig a little bit to understand how to get them v six ready. There are surprising defaults like Java still prefers IPv4 over IPv6. And the state of happy apples heavily varies. In the end, what we have found out is most code just worked fine when we actually updated the run time environment and had a little bit of documentation. So, we have only had only a few products that actually found bugs. Most just tests and said, oh we're done. That was six support heavily differs by the different cloud providers. And that's really a pain because you get if you're doing multi cloud, that's not only multi pane, but it becomes even more painful if you have to account for the different IPv6 environments. And finally, fixing IPv6 issues in open source is key. But especially in the Kubernetes ecosystem, there are surprisingly many gaps and up streaming changes. It's usually much more difficult than just fixing them and build the PRs. So in the end, my takeaway is getting IPv6 ready is not a technical problem. It's usually an organisational challenge. And you have to be good with people to roll up IPv6, not with bytes. So where's SAP today? We delivered IPv6 to those federal government customers. I think except a few regressions, really done with that. We have a few front runner products that support IPv6 also to regular customers. That's SAP Concur. And that's the BTP Connectivity and Destination Services, which are, yeah, more or less the crown jewels where most of the global business would break down if these were down. We now offer IPv6 as an optional features for the SAP Business Suite in the RISE offering. And we added happy eyeball support to our other platform. We're currently looking into how to get this to other public cloud customers, especially for BTP and HANA Cloud. And with this, I have no time to take questions, I guess.
[00:12:37] Nick Buraglio: If there's any questions from this, we can take it to the
[00:12:39] Shuping Peng: list. Excellent. Jordan, you are next.
[00:12:58] Nick Buraglio: I can't I can't see the queue. You
[00:13:01] Jordi Palet Martínez: Okay. So, this one is going to be very quick. This document was adopted by the working group, I think, about two or three months ago after the last, I think, after the last meeting. Basically, in short, the document is looking at different aspects about recommendations for point to point links and it's more or less following what we already have in RIPE as BCOP-six 90, okay? So we answer different questions regarding the size of the point to point links, how we number them, etcetera, etcetera. What have been the main two changes? I think in the last two versions, that's why I used the two colors. We incorporated some comments about PPPoE, IPoE, clarifications about persistency versus privacy, adverse reputation. We'll remove it uppercase normative language and relax it, the BCP summary. There are also some recommendations for publishing prefix lengths according to one of the documents in OPS AWG. There is also a change in the title. It was initially end users, now it's N Sites because actually we're talking about N Sites more than end users. And then some additional information about prefix persistency and mitigation reference to temporary address extensions. So what is the situation? Well, still open for questions. Any new inputs? I am not sure if people has read the latest version. I really think it's almost ready for last call, but I really think we need some new people or people that already has read previous versions to provide some some new inputs. And I think that's that's it. So this one was quick. How many people has read the last version? A few. So new inputs. If not, we go back to the list, maybe asking for specific questions or
[00:15:39] Nick Buraglio: Any questions on this one? I would encourage folks to give it a read and do some more discussion on the list.
[00:15:47] Shuping Peng: Yeah. In general, we need more reviewers. And sometimes in a working group last call, we don't even get the five reviewers. So please.
[00:16:00] Nick Buraglio: Alright.
[00:16:01] Jordi Palet Martínez: So we save it some time.
[00:16:04] Nick Buraglio: Please read in comment.
[00:16:05] Jordi Palet Martínez: Next one. Okay. This document is a document that we started a long time ago. It was already adopted as working group item, but the solution was not the easier one. Okay? So, basically, the problem is that the same that when you have CDNs and caches in I p v four with CGNAT, there are optimizations so the traffic don't necessarily go through the c g NAT all the time. Okay? So here, when we deploy either MAPT or four six four x latt, we have a similar situation. We have, for example, all IPTVs that are IPv4 only or even set top boxes or whatever. And if we just do the regular deployment of MAP-T or four six four x LAT, the traffic will be translated in the CP to I p v six from I p v four to I p v six, and then traverse the network and go again translate it to I p v four. And this is ridiculous because the c g the CDN or the are already dual stack. Okay? Let me show the picture. So this is a typical deployment. So normally, the traffic, if the origin host is IPv6 will go like that. But if we have an I p v four only host like an I p v I I p v four only IPTV, it will get two translations. So it don't makes too much sense because this is overloading in accessory, the NAT 64 box. Okay? So what we're going to do is something similar to this because we already get the stateless translation of the CPE. Well, typically a stateless translation from IPv4 to IPv6, we want to keep using the resulting synthetized IPv4 address. Okay? So, originally, we were studying three approaches. The first approach was DNS routing based. And in the previous versions of the document, we don't have the 4a record. Okay? We discussed that with CDN operators, and they told us they really don't want to do this. And I am guessing that part of the reason they didn't wanted to do this is because they were not able to use, at least not according to standard, nineteen eighteen IPv4 addresses in the NAT64. But now this is changing. So because this is changing, it looks like this approach can be much better than the other ones. So this will be the result. We have a direct path without passing through the NAT 64. Okay? Now the other two approaches were and I am go not going to to go into the details, were using a CLAT DNS proxy explicit address mapping table. And the other approach was, if this works, a CLAT provider explicit address mapping table. But these two approaches were really complex, and it means modifying the CP. With the approach number one, we don't need to change anything. We just need the CDN operators to deploy quad a records using if they are using, in that deployment, the well known prefix, using the nineteen eighteen addresses. Okay? So the question here, and and it's almost done, is, okay. I just mentioned this. The question here is, if we have CDL or catch operators looking at this document, if they can confirm if they will agree with this approach. Okay? So that's that's the basic question we need to answer. Because the obvious recommendation now is let's do approach number one instead of approach number two that we were recommending before. Of course, this depends on the on passing the the well known prefix nineteen eighteen document that that I think is being presented later as well or not anymore. It there was a new version yesterday, I think, Warren, for your document. You you send the last version yesterday. So that that will go into the last call now, I guess. Yeah. Okay. So it depends on that, but I think it should not be a problem. Now I have one open question here. Assuming the operators agree that this is a good approach, I mean, CDN operators or the catcher operators, I think we should split the document actually in two documents. I think we should split the document in one informational document, which is almost what we have today, and then a BCP for approach number one. This is an open question that I am I am asking to the to the working group. But, again, we still depend on at least some CDN and catch operators telling us, yes. We are happy to do that. They are actually doing for CGM, which not for four four, so it should not be a problem. And I think that's it.
[00:22:07] Nick Buraglio: Alright. Got a couple questions.
[00:22:09] Ondřej Caletka: Hey. Charlie, first, thing, I really didn't get the part with quote a records because you are talking about, I p v four only device traversing the CLAT device in your CPE. So where exactly is the need for any quote a record? It's only the routing thing, isn't it?
[00:22:29] Jordi Palet Martínez: Yeah. You're right. If we don't we don't even need the quote a record. Yeah. That's that's something I put in the in the in the slides. I am not sure if I put that in the in the in the document, but it's it's not even needed. Well, maybe maybe they prefer to do that for clarity or I don't know. But, yeah, probably it's not even needed. I need to think about that.
[00:22:51] Ondřej Caletka: So the other thing for the sixth that I I would just shut it down. I feel like the option number three is actually the most, like, usable part in the long term, I think. It will be nice if there will be some sort of provisioning protocol, be it DHCPv6 option or some HTTP endpoint, whatever, that would make the CPE download the explicit address mapping. Because if you are running a CDN node in your network as ISP, you know exactly which endpoints you should map to which end point. So you should just provision it to CPEs and be done with it.
[00:23:25] Jordi Palet Martínez: Well, I was thinking it's better the the approach too, but but I recall we have lots of discussions with CDN operators, and they said that not. And in any case, it needs modifying the CPEs. And you know what it means modifying a CPE? No way. Okay. Right? We don't get fieldwork updates for CPEs, for things like that. The the CPE vendors, most of the time, they don't care.
[00:23:57] Andriy Yurchenko: Andy Yershenka. So I happen to maintain a kernel module that might be used in at least some of the CPEs to do the translation. And two points. So A, in that kernel module already can install the static mapping entries. And about the provisioning, as far as I remember, back in the day in softwares, there was tons of DHCP options already defined. And the FMR, as far as I remember, in MapT, or it was more generically defined as S46 rule or something like that, that's already there. So if the support is lacking, that's the standard is nonconformance, which is a different thing than implementing something new. So maybe it's worth looking at that and just bring that, to conformance.
[00:24:39] Jordi Palet Martínez: Yeah. The problem is not a standard part. The problem is deployment or or field work updates to CPs. You know?
[00:24:48] Andriy Yurchenko: Yeah. Yeah. But it's maybe there already. Yeah. It's worth just testing and seeing whether it's there. It might be.
[00:24:54] Nick Buraglio: Jen?
[00:24:55] Jen Linkova: Despite the company in my branch, I do not operate CDNs. I have no idea if anyone actually would do that. So I was curious if you tried and practiced any of this.
[00:25:07] Jordi Palet Martínez: Not this approach because we discovered in previous conversations that that CDNs were not happy with that. But now that we can use or we will be able to use private IP for addresses, which is a well known prefix, things change. And the fact is that CDNs are doing this, which private addresses in IP before. So
[00:25:31] Jen Linkova: So if I understand correctly, the first option is just your CLN just translates, and as long as your server has 64 ff-9b before address configured on its interface, it will just work, right, if you're routed correctly. The question is, yeah, if you control the servers, yeah, it might work. I'm not sure, like again, it would be really nice to see some proof of concept that is deployment of option number one. Right?
[00:26:00] Eric Vyncke: Eric? Yeah. I'm sorry. I'm very confused about how you think this can possibly work. Can you go back to the arc one of the architecture slides?
[00:26:09] Jordi Palet Martínez: Which one?
[00:26:10] Eric Vyncke: Just about any of them. I think I just need to see this. Yeah. So that's that's fine. Yeah. This one right here. So if I understand this correctly, the CE you you want the CE to take the public before address of the dual cast service and not and and use the public quad a of the dual stack service, not the DNS six four address? The
[00:26:37] Jordi Palet Martínez: not actually, if the CDN is using private IP for addresses, the synthesis of the will create a well known prefix with the private address. Oh, this is only
[00:26:50] Eric Vyncke: for CDNs that are within the operator's network?
[00:26:53] Jordi Palet Martínez: The CDNs, are already doing that with private addresses for IPv4, So we don't need to do anything.
[00:27:00] Eric Vyncke: So the I p v six Internet here on your diagram is being is not I see. That that that's that's
[00:27:07] Jordi Palet Martínez: It's not passing through Internet. It's it's the direct connection in the in the ISP infrastructure.
[00:27:13] Eric Vyncke: I see. Because as far as I was concerned, I cannot tell how the CE is supposed to know that the I p v four smart TV didn't use DNS over to look up a service that truly was v four only. And then, you know but I think you I see what you're doing. You're not you're not using the public cloud a of the of the DNS of the Google stack service. That makes that makes a
[00:27:33] Andriy Yurchenko: lot more sense. Thank you. Okay.
[00:27:35] Nick Buraglio: Alright. We're we're over time now. So I think
[00:27:37] Jordi Palet Martínez: Yep.
[00:27:38] Nick Buraglio: There's someone else in the queue, but I think we're gonna need to take it to the list.
[00:27:45] Jordi Palet Martínez: And the last one, this was adopted as working group item in the last few weeks. So we published already the first version as working group item. The problem, again, not not repeating, is the clear definitions of I p v four only, I p v six only, etcetera. Okay? And the idea is not to define all the possibilities because that's impossible. We already learned the lessons in previous versions across the number of years working on this, but instead going to the basic very, very basic definitions and then making sure that we state the scope. Okay? So if we talk about access network or core network or BGP or whatever. We we always need to specify the scope. An example of I p v six only is is here in the slides. I am not going to read it. And what have been the main changes? Well, there is an overall text review in even some reordering of some text. Additional scope qualification, somebody suggested that we should specify also if it's data control plane or bot. API scope clarification. The idea here is not expected to be I p v six only by now, so recommended to be dual stack. And I added a lot of diagrams with short of explanation of each one. And I think that's it. So I didn't got any new responses in the list since the since we published this version. So, again, as in the in in the first document I presented today, I think it's almost ready for last call, but, again, I really think we need some new review from the working group. And that's it. How many people has read the last version? None. Or I don't see any hands. Really, really need some someone else to read that. Thank you.
[00:30:07] Nick Buraglio: So I would also encourage folks to read this. I have yet to read the newest version, but with, you know, no hats, I think this is important, and I'm glad you're working on it. I would also encourage other folks to take a look. It's a hard it's a hard problem that I've run into in working on this kind of thing. And so having something to reference is would be would have been very, very nice.
[00:30:35] Ondřej Caletka: Andrei Todka, I I read this and I looked at the examples. One thing I have an issue with is that there's an example of I p v six mostly network that has two hosts, And both hosts are according to the definition of this terminology called dual stack even though one is using I p v six only generating only I p six packets and having c dot inside of it, while the other issues is generating native v four and v six packets. So I think there should be some way how to discriminate because there are two different modes of operations. And if we both call them dual stack, we are just losing this precision four. I
[00:31:16] Jordi Palet Martínez: I think I thought about that. And the problem here is that, initially, the host is dual stack, and then it becomes working as I p v six only. So it's it's a special case, but we can we can see if we can improve that.
[00:31:31] Ondřej Caletka: So maybe, like, improve a scope saying that applications are dual stack because they c v four and v six connectivity, but the network interface is v six only. Well, actually,
[00:31:41] Jordi Palet Martínez: because we are talking about the scope, you can say that according to the actual document.
[00:31:46] Eric Vyncke: Okay.
[00:31:46] Jordi Palet Martínez: You just can extend the scoping. Let's say, I am not sure if in English is correct, but you can extend the scoping as much as as you want to make it very, very precise. Thank you.
[00:32:01] Nick Buraglio: Tim?
[00:32:01] Tim Chown: Hi, Tim Chan. You just led into my question nicely. Can you use a word other than scope? Because I think people going from v four to v six
[00:32:08] Jordi Palet Martínez: Okay. Don't really understand scope is
[00:32:11] Tim Chown: a new thing to them.
[00:32:12] Jordi Palet Martínez: I think I started with context. I think she then suggested the scope,
[00:32:17] Tim Chown: but Yeah. Don't can don't use that because then
[00:32:20] Jordi Palet Martínez: Okay. So which which one you suggest or
[00:32:22] Warren Kumari: you want to think about it? Else. Maybe context? I don't know. I have to think
[00:32:26] Jordi Palet Martínez: of it. Context. I was using context, but
[00:32:29] Tim Chown: Yeah. Don't use
[00:32:30] Jordi Palet Martínez: Well, we can discuss later on. Yeah. I mean, I am fine either way. I am not native English, so I am not sure which one is the best. That's it.
[00:32:42] Nick Buraglio: Alright.
[00:32:42] Shuping Peng: Yep.
[00:32:45] Jordi Palet Martínez: Thank you.
[00:32:46] Nick Buraglio: Alright.
[00:32:59] Philip Thiesel: Hey, if you have heard my previous presentation, you now see one of the outcomes from that. Because as we a lot of people in doing IPv6 testing, we now have at least a body of ideas on how it is. So if you haven't read the draft yet, it basically is targeted to be a BCP on how to test applications for IPv6 only readiness. So the target is really it should work IPv6 only. For classic applications, as well as service or cloud applications, it lays out basic connectivity scenarios you should test or at least consider for testing. How to test intermediaries, name resolution, how to test for partially broken connectivity, common test strategies, and common sources of IPv6 related failures and misbehavior. And after having read this, developer should have an idea what testing for IPv6 only readiness of an application means. So since the last the draft is relatively young. Last year in Montreal, it got presented, got adopted in December. We have now a 0.1 version after the working group feedback. And as we don't in this, we did the following changes like a section on testing name resolution issues. We extended the text on testing with partially broken connectivity. Some people suggested also doing a little bit more on testing without IPV for loopback addresses, which is difficult on Linux. But you get into similar scenarios based on some socket sys controls. Considerations for addresses as data and change the term true IPv6 only according to the nomenclature of the last document presented by Jordi to IPv6 only strict. So, we did not get too much feedback on the mailing list, but and therefore I hope we could get this document perhaps towards last call this year. So one of the so two figures I got about the general scope. Matt suggested also to talk about benchmarking and performance aspects. And I would be happy to take input on that one, whether you think it's necessary or whether it's a good idea to just focus the document only on the functional testing aspects. We got some feedback that there should be some considerations on customer support. Not sure how that fits in, but I'm happy to take suggestions how to do that. And there are two other things. So do we need more on the common IPv6 testing issues? So Frank Martin suggested us having some text about forgetting to listen on IPv6. I already have a PR for that one. And with that, we can also look about testing against IPv6-only listen assist control options. And the other question is whether we want to have more deployment considerations. But I think this is better Frank's draft about data center deployments is the better place for these kind of considerations. So with that, I had asked the working group a few questions. I'm happy to take input on that. And finally, I would love to see whether you think we should try to get it towards that working group last call soon.
[00:37:24] Tim Winters: Tim Winners, QA Cafe. So for performance, what are you guys thinking? That was my only question. Are you actually measuring what are you measuring for performance? Like, throughput? What are we talking here?
[00:37:35] Philip Thiesel: So we did not measure performance at all because we just focused on functional testing. And my experience is that performance, I've never seen a case where an application implementation really screwed up performance when getting enabled with IPv6. That happens a lot in the deployment of an infrastructure landscape, but not so much in the application itself.
[00:38:04] Tim Winters: Okay. That's what I was curious of. My second comment here is about control traffic and management traffic. What we've been seeing a lot lately with v six only networks is only one of the two will work. Only one of the two will work. And I know you guys, I looked for mention of it, but I didn't see any mention of just be careful that your control and the control traffic for an application goes on a different path than the data path. And so sometimes people make very poor choices that that you can control the app, but it doesn't actually do the thing you want it to do over v six. I I looked for it. I couldn't find it anywhere. You guys have, like, user interface stuff. That's all great, but might be something to talk about. It seems to be something that people are missing on the regular at the moment.
[00:38:51] Philip Thiesel: I think it's yeah. I understand where you're coming from. Yeah. How to discuss that? Yeah.
[00:38:58] Tim Winters: I mean, I'll I'll leave that to you guys. It's just this is really just a food for thought thing. Go if there there might be something you can say that's little bit more strict because that's the common problem I've been encountering.
[00:39:07] Philip Thiesel: Yeah. I totally get that.
[00:39:12] NIC.br Representative: Hello. Good morning. From Nick. Br. As I as I told you a couple times, this draft is a 100% necessary as someone has who use it to cheat to teach for developers and also who is struggling with companies who are developing software. This is the kind of content that they need to care about because I p v six is in no functional requirements for Internet connected applications. So this is a very important draft. By the way, I sent in the list a tool that I'm trying to develop to make it easier to translate what's in this draft for developers and teams and also system administrators who are trying to test one application if they are a p p I p v six capable or not. If you are interested, just check there the trial from the last update in the draft. And I I didn't see before this this considerations on customer support. I can try to to get something maybe included in the draft, gather some maybe troubleshooting in in something for applications. And that's it.
[00:40:32] Tom Hill: Thank you very much.
[00:40:35] Tim Chown: Hi, Tim Chang. The front microphone is in the scone working group, and the rear microphone QR code is in v six ops. Just very confusing. Well, I put my hand up before. It was getting I thought I thought Nick was putting my hand down, but it was the scone chairs putting my hand down because I wasn't so what's the question? Yeah. So I think this is really good. I think one of the ways you could maybe split it a bit more, looking from the point of view of what we're trying to do in terms of getting software development better with with better v six support, is maybe split the focus a bit into what those in the IT department setting up an infrastructure for the application testing might do and what the people doing application testing might do. Because you've got some bits in there that talk about, you know, making sure the c lattice disabled for v six only, that sort of thing. So I think maybe there's something along those lines you could look at. The other thing, as you said in your first talk, is the variability if you're trying to test various cloud platforms or Kubernetes. There are issues, and I think, yeah, having those documented well would be good. I think some of those are are in here. But I think overall, it's it's a really nice document, and we should certainly take it forward. It's just maybe there are some ways of reorganizing it might help. And, yes, the 6724, I know from bitter experience, there are some of those that do 3484, 07/24. Some have done some of the drafts, 6024 update stuff, and some do completely their own things. So that's a a minefield. So I'm sure Tim Tim too behind me would agree.
[00:42:06] Philip Thiesel: Yeah. I think 6724 is really something that surprises a lot of application developers You one or the other need a lot of insights and a lot of experimentations to, in the end, at least in my experience, always come to the conclusion, yes, it makes sense how it was set up in 6,724. At least the stuff that's surprising for application testing. But it takes a while until you get to that point.
[00:42:37] Tim Chown: Yeah. And the other final thing I was going to say I was thrown out by the scone thing. The final thing I was gonna say was there was a really nice project done by Aaron a couple of two or three years ago, a sort of a v six only test box as a service. And that that was very interesting. I think Nick's aware of that. But it was only available to people in the Aran region. We couldn't get hold of it, for example. But that sort of thing might be a useful thing to develop and make available more globally, I think.
[00:43:05] Nick Buraglio: Alright. I put a poll up real quick.
[00:43:09] Alex: Alex, it's one question. There are some cases when you install an application in a dual stack environment, and then you want to reconfigure the application to a single stack like v six all the environment. And in some cases, the applications fail to to capture the change. And, for example, they may have some IP address configured in in in the config. It might be interesting to see a test scenario where you start with your own environment and switch to v six only strict in in the document. Otherwise, the document is great.
[00:43:41] Philip Thiesel: Interesting question. But the question is so in bigger environment, how common is that? So I would usually envision that when when you make such a drastic medical change, we at least restart the machine and then would also start with a fresh code.
[00:43:56] Eric Vyncke: You you do,
[00:43:57] Alex: but then still the application can have this v four only set somewhere. Just food for thought. Thank you.
[00:44:06] Nick Buraglio: Alright. Thanks. Timer?
[00:44:25] Eric Vyncke: Oh, yes.
[00:44:32] Ondřej Caletka: Hello. I'm Andre, and I would like to talk about filtering address records in stub resolvers, which is which is a draft that I wrote. Here, it's basically this very simple thing that many operating systems or applications are not doing what they queries if they think they don't have IPv6 connectivity. It's also written in some RFCs like the Happy Eyeballs v2 or so. The problem is, what is actually IPC connectivity? And it apparently different platforms have different opinions. Some things like, I have default IPC connectivity if I have default route on default interface, but not on some software like VPN. Some platforms consider default route on VPN also as IPv6 connectivity, but that's still not enough because they also split VPNs. You might have just a few I p v six prefixes delivered via VPN on your computer, but the rest of your computer can be IPA four only. So does is this I p v six connectivity? And in my opinion, yes, it is. So, basically, the purpose of this draft is that simple. Like, if your computer can reach any, at least single I p v six address that can possibly appear in DNS, then your computer should do query queries. Because otherwise, you cannot really use I p v six only networks, I p v six only VPNs because, well, you will never discover them because of because of the computers not doing the query queries. So what is new in this version is explanation why actually it is beneficial to do this filtering, not to do query queries at some point in time. The biggest issue is, of course, that DNS is UDP based protocol. And, of course, the amount of brokenness of things on the Internet is always bigger than you can even imagine. So not only that networks are suffering from packet loss, which is impacting UDP based protocols a lot, but there are also DNS reclusive resolvers that drop queries to unknown query type for them, like, what a. So if you ask what a and the response of the DNS resolver is silent, and you are doing proper, ordering and dual stack, you have to wait until the timeout before you can, go further, and this will be user notifiable delay. So that is why that is why, like, not doing query queries, if you are sure that you are not on the network that supports v six, is beneficial for the user. However, there are standards like Happy Eyeballs, at least 2.0, 3.0 now in development, that do asynchronous processing, which will sort of eliminate this user perceived problems. Also, there is this draft about multi query queue types where you can do one DNS transaction asking for multiple query types. And, of course, in that case, you can always ask for everything because it should not matter. So in my case, the the the draft is going in a positive way. So it's basically telling how you should do the filtering properly. It's not doing it only for core a records, but also for a records. Wrong terminology. Sorry about that. Pure IP six only network is actually IP six only strict. And deals with the four six four x slots and not six four, and also proposes two algorithms how to figure out whether you have roots to IPv6 or not, either looking into routing table or looking into IP addresses, and stressing mostly that not just default route, not just default interface should be considered for the purpose of this filtering. Important thing to say here is that most of the stuff here is also part of the HAPI ABOS 3.0, at least the changes there for accommodating v six only networks. So this is sort of like supplementary draft only for for systems where a Happy Eyeballs v3 would be super complex because it's mostly dealing about SVC B records for encrypted client hello and things like that. But this filtering of code a, where is this something that hits you even if you just want to SSH to an I p v six only network, I p s six only server that is switchable via VPN, and it just doesn't work. So I'm trying to keep these things small and focused. As I said, Happy Eyeballs is solving the same thing. It definitely needs more input. Yeah. Last call probably not yet, but yeah. Eventually, I would not like to, you know, put everything but the kitchen sink inside, but just keep it on this level.
[00:49:34] Jen Linkova: Jenning Gova. First of all, full disclosure, I have not read the last version of your draft. But following based on the extensive discussion we had in v6ops, my understanding is part of the problem is that in general, in most of the cases, you do not want to resolve through one interface and send traffic through another. Right? But in some cases, you might need two. And that's the reason that the recent the most recent version of draft defines, like, uses the term PVD. Right? Because I I'm a bit concerned when you say any route on any interface because I'm not sure what's gonna happen, like, with mobile network connection and Wi Fi and all that kind of stuff. So I think maybe maybe what would be beneficial in general for the industry if we start, like, doing more work in the PVD area and define, like, how this multi home host is multiple interface should actually behave. Right? Because if I'm right, you're trying to solve the VPN problem mostly. Right? And maybe you need to explicitly say about we talk about VPN and explain, like, how VPN needs to be done. I'm not even sure it should be done in v six ops. Right? Because if you generalize too much, I'm afraid it might be unexpected side effects. Right? And, again, I I think we need to make sure whatever is your draft proposal inconsistent is consistent with. Right? Otherwise, we're going to see some unexpected side effects.
[00:51:16] Ondřej Caletka: It is consistent, yeah, in that sense. It's okay. But, yes, like the provisioning domain thing is, yeah, exactly the part of complexity that I would prefer to avoid, but maybe it's unavoidable.
[00:51:32] Nick Buraglio: So Nick Beralio. Yes, Nick. No hat. The VPN problem is very real. I have had complaints of that as recently as Wednesday. So I think it would be a good idea to maybe deal with those complexities within, you know, the the draft. And I also full disclosure, I have not read the last version of it either, Or if I did, it was long enough ago that I don't remember the details. But I do think that that is a legitimate problem that that does need to be solved, and I think there's a some possibility for that here. So
[00:52:10] Jordi Palet Martínez: Thank you.
[00:52:11] Cloudflare Representative: Hi. Cloudflare, not on the operations side. Can in their first or second slide, it's just some confusion that I want to sort out. You said if the address is in the DNS and in principle, I love this idea. I haven't read the draft, but that part confuses me. Why should it a, you don't know if it's in the DNS until you do the query. I would think it's just anything that's publicly routable.
[00:52:39] Ondřej Caletka: Yeah. Yeah. I know what you mean. If if it is other space that can appear in the DNS.
[00:52:44] Jordi Palet Martínez: If it
[00:52:44] Tim Winters: can't appear.
[00:52:45] Ondřej Caletka: Well, because because because that's basically the thing. Because if you have I p six capable hosts, you always have link local addresses on all interfaces. They shouldn't appear in DNS, so you should ignore it.
[00:52:55] Cloudflare Representative: Yes. No. It's the can appear, I think, that I missed it.
[00:52:58] Ondřej Caletka: But but, basically, basically, the point is even if it's this ULA prefix, that's something that can appear in global DNS, and you should if you just see ULA addresses on our interfaces, I think your computer still should do query queries. Understood.
[00:53:11] Shuping Peng: Thank
[00:53:11] Nick Buraglio: you. So anecdotally, the problem that I just described that was reported again Wednesday, we have a sort of an ugly hack that essentially when the VPN interface comes up, runs a script, that it just populates a ULA address onto that interface, which seems to solve some of these problems. It's fairly ugly, but it does work.
[00:53:34] Tim Winters: Mhmm.
[00:53:36] Ondřej Caletka: Yeah. VPNs are really tricky part in this sense because there's, like, thousands of different setups including, like, where the DNS is resolved. Is it the global DNS? Is it the v p DNS over VPN? And is it full to no split tunnel? So, yeah, I don't think there would be ever document documenting all possible ways how DNS can fail sorry, VPN can fail.
[00:54:02] Nick Buraglio: Alright. Any more questions? Thank you.
[00:54:07] Tim Winters: Thank you. Okay. I'm here to talk about 7,084 I p v six routers on behalf of my authors, Jordy, Gabor, and Ben. Okay. So there's a new version of this. I think last IETF, I got up here and said we were almost ready for working group last call. We added some stuff. So some of it we got were comments on the list, and then we got a couple pieces of feedback during the last ITF. So couple of things we did. One of them was administrative. RFC9018, which is doing PD on the LAN side. We obsoleted that. It seems like a new one. Why would we obsolete it? Basically, we took all the text, and it now is in seventy eighty four to give them one place to look instead of two. I think Ted pointed out v six hosts are capable of Slack. Should be should be. This was one of those this was in the original 6024. It just never got updated, so we fixed that. L 21 is RA guard. We had some comments about why it was off by default, And so we added some text to say, hey. Snack and unmanaged routers. There's a bunch of scenarios you do not want RA guard on for by default. So we did all those changes. This was a change we made, be a little more explicit about ULAs. So the original text I have is up there, the old one. It's pretty simplistic. We gave a little bit more on the should side of this to explain to people why it's a should and how you should go off and do this. Okay. This one. My fault on this one. I wrote this up. We got some emails about this, about supporting DOE, and we've seen it in some home gateways, definitely. And so we thought, yeah. We'll add it. And I forgot to put the words in the DNS proxy functionality. So there's a lot of confusion around this. My fault. This one's on me. So I fixed it. It now says I v v six router should implement the DNS proxy functionality of DOE and may support DOT. That's basically what we've been seeing. There are some routers out there that do DOT, but DOH is way more popular. So I I think we I think that addressed a bunch of the comments on list. I'm hoping if anyone has any comments on that, please come on up. Okay. I hate these flags. So the MNO flag. There is a new WAA 12 that I'm getting rid of that has the text below. I think this all belongs in one place, just to be clear. What we've been starting to see is home gateways who get an m flag set to one start doing DHCP, and then there's a flap for whatever reason, whether it's a second router or a confusion and the m flag changes to zero and it dumps its entire DHCP and then restarts the entire process over again, over and over and over. Please don't do that. So I added text. This text, actually, I basically stole from the original neighbor discovery that says don't do this, and I made some modern some minor modifications to it and said, hey. If a flag changes, don't dump your DHCP table. If you got one, just keep DHCP on. In particular, with home gateways, PD, you basically need PD to do anything. So turning off DHCP is a really bad idea. I did talk to some operators who still want the ability to kill DHCP, and so that's why I didn't say just ignore the MNO flags. Boy, did I want to. But I've talked to a couple of people that said, don't do that. So I didn't. So that's the situation there. I I don't think this is a major change. It's just we should get this fixed in there. So the battery's dead or it doesn't like me anymore? Or both. Or both. Both could be true. Alright. So this is one that came out of 7084bis. So those who haven't been watching, DNS has been going through a little bit of an update. We added two new requirements. I think we got these from comments. I think there was a presentation about Ripe about some of this, So we tried to cover both of those. If implementing DNS proxy, the CE router must support I p v six when resolving or forwarding DNS traffic. So what happens here is some gateways have made some really interesting choices when they proxy, And they on the LAN side, they're using v six, and on the LAN side, they switch it to v four. That's questionable. So we suggested they not do that and use v six whenever possible. This is one of those weird oddities that, yes, I've seen it. It's a little more prevalent than I would like, so that's why it's there. The other one is we added r five and r six are about the size. This is about fragmentation on DNS. You can go read those individual ones. I didn't call them out directly. But this is saying, hey. Don't don't try to avoid fragmenting DNS whenever possible. And so this is suggesting that the CE routers, again, when performing queries, does all the right things to avoid fragmentation in DNS. We had a couple reference updates. This came up in six man when we did node requirements. So for this node requirements points to this doc. That doc points to this doc. So we're gonna update them both and have them both point to the Biz versions. They're both very close to going to working group last call, which is nice. So we're gonna do that everywhere. And then the other one we missed, I don't know what I was doing. Ninety nine fifteen is DHCPv6. We should as a standard, there are no major changes, but we should always point to 99 fifteens. We're gonna make that change. And I think that's everything I have on the list. We're ready for working group last call this time. We're gonna put out any comments from this one, make any changes, and then we're ready to go to working group last call with this doc. Really, this time, I'm not joking. Okay.
[01:00:34] Stefan Ubbink: Hello. Stefan Lebink, SIDN. Can you go back one slide?
[01:00:39] Tim Winters: I can't. Sorry. Lost control.
[01:00:42] Stefan Ubbink: So there was the mention of the proxy must support I p v six, and I was wondering if that should be a capital must.
[01:00:50] Tim Winters: Yes. Yes. It should. Okay. Agreed.
[01:00:53] Tim Chown: Thank you.
[01:00:54] Tim Winters: Yeah. I wrote this up. I haven't put it in the actual doc. Thank you. I will make sure that that's a capital must. Absolutely.
[01:01:08] Tim Chown: Hi, Tim Chown. This isn't the multicast question you're expecting. It's a more general one about multicast.
[01:01:15] Eric Vyncke: Okay.
[01:01:16] Tim Chown: If we see opportunistic use of multicast from media over quick relays, might happen, should we be thinking about multicast requirements in here? At the moment, there's one paragraph about multicast that says something like the CPE may act as an MLD to b two proxy. It may be a multicast zone boundary, and that's it. Those are low lowercase mays.
[01:01:41] Tim Winters: Yep. They're 100% lowercase mays.
[01:01:44] Tim Chown: It also says in the introductory text about being a ULA, you effectively as well. And then there are musts about that. Yep. So is that something that maybe multicast will never happen in in v six residential networks? Or is that something you should put in here, or is that something that should be a separate document that could maybe include other scenarios for opportunistic SSM from mock relays that might go into campuses that's more interesting to me? Yeah. How should we handle this? I think we need to write it down somewhere.
[01:02:12] Tim Winters: Yeah. For, you know, 7084 has always been very, very quiet about MLD. And in this case, yeah, MLD. I'll I'll avoid the I g m p problem. But for multicast and v six, we've just operators traditionally don't want it to cross any boundaries. Right? They want it to stay in either the home net or on their side, or they wanna be totally in charge of it, which is why the text is very, very, very loose. I'm not sure that's the place to do this, mostly because this is for customer edge routers. I think it's a different conversation when you're talking proliferating into the network. But at the edge boundary, I think we're in a weird spot where yeah. And this comes up. Right? I mean, there are definitely operators who love their have multicast applications, you know, the biggest one being IPTV and making sure that certain things work the way that they want. But my experience with that is it's not standard, and they want it to work the way that they want, not standardized yet. So I don't think we're there yet. I think it's a little late in this process to do it, but it's an interesting thought. I'm not, you know support for multicast and home gateways is a bad it's it's not great. So that's something that I think we could work on. And then the proxy functionality is very different.
[01:03:23] Tim Chown: Okay. Yeah. I mean, my interest in that is with sort of campus type.
[01:03:26] Tim Winters: Yeah. I can see that. Looking at that. But
[01:03:27] Tim Chown: yeah. Just just curious. Yeah.
[01:03:33] Unidentified: The fix to the DOE requirement text, should that say should support DNS proxy with DO, or should it say if DNS proxy is implemented, it should support DO?
[01:03:45] Tim Winters: Oh, boy. That's a good question. I I think it's the I think if they do DNS proxy, they well, which one do you want it to be? I'm open to suggestions.
[01:03:57] Unidentified: Well, it's it's if it's doing DNS pro d h c proxy. I think as written, it's kind of sort of implies that you should be doing DNS proxy, and it should have DO.
[01:04:09] Tim Winters: Okay. Gotcha. We'll fix that. Cool. Okay. I think I'm good. I'm gonna slowly back away. Thanks, everybody.
[01:04:43] Shuping Peng: So I'm next to talk about enhanced deal stack. The purpose is to help enterprise deploy IPv6. And here's why. I feel that current the current deal stack does not work as well as it cook or it suit. Ideally, your stacks work like this. Because before you deploy it, I p v four already working there. And therefore, after you deploy your stack, if I p v six work, then it's used. If I p v six does not work, you also continue to use I p v four. And the user should then perceive any performance disturbance. And if this is the way, then I p v six deployment will become fairly low risk and and therefore easy. But it's not the case because currently, a dual stack host select the I p v six and I p v four based on the sixty seven twenty four rules. Although the rules work most of the time, sometimes when I p v six doesn't work, it may still be preferred. And as a result, the user may be some service disturbance. And for the network deployer, for the I p v six deployer, in order to avoid this from happening, He will have to do a lot of upfront validation. And then also face the judgment moment when he turn on switch on I p v six. And therefore, this is a little risky. Because of that because of that, mainly small and media enterprise are reluctant to deploy I p v six because they feel that they have to do a lot of work. It's a still risky, but, you know, they don't really need a technique need address. So, you know, they they don't have the motivation. And this is what enhance the o stack objective is to bring the o stack to this, like, ITO operating state, meaning that, well, when you deploy it, if I p v six works, it's used. Otherwise, you know, you continue to use I p v four. And therefore, you know, it's relatively easy to start. And also to provide data when IPv6 is not selected. Why? So that the deployer can go to identify the problem and fix the problem and move on. We believe that this is important. Otherwise, it will take a long time for small and medium enterprise to adopt I p v six. So how are we going to achieve this? We propose three enhancement to dual stack. And the the first one is being v6-only OS or platform implementation profile. Happy eyeball has brought the traditional deal stack, a big step towards enhanced deal stack. But we believe that something can still be added. One is OS implementation profile because currently, happy eyeball doesn't specify the implementation location. And therefore, you can do it. You can implement it at the application or you can implement it at the OS. But if you implement it at the application, then other application does not benefit for long gig. So if we can put it in the OS or in the platform, then, you know, more application can benefit from it. This is the the purpose. Because there are mainly existing application. They don't use the happy eyeball API. And therefore, you know, they cannot benefit from happy eyeball. For example, they continue to use the get address info connect function. And therefore, the second enhancement is, like, we propose some improvement to get address info and the connect function. Basically, the connect function will provide the performance stats for the get address info to consider when they, you know, order the I p v six and I p four before address pair. They can take performance into consideration so that hopefully, they will avoid it. You know, if I p v six does not work, it can avoid it to to avoid, you know, performance disturbance. And the third one is this data. Like, well, if I p v six is not used, then, you know, provide the data so that to support the problem identification and fix it. So this mechanism are somewhat defined in the draft, but I recognize that we are the operation people who are not the the software developer. So we seek OS and software developer to, you know, help define the refine the mechanism. We also have incremental deployment approach because we recognize that if we want to get all three enhancement, it may take time. But, you know, this doesn't prevent you from start. So the key point is that we propose to divide enterprise host into the early adopters and critical host. So the early adopters can be the users who can tolerate certain, you know, performance disturbance to to experience IP problem, IPv6 problem, and help a fixed problem. And the critical one, maybe, for example, your executives or, you know, the servers, etcetera. They they you know, you you you don't want to fix that. So the early adopters can be only partially, you know, enhanced your stack capable. It doesn't need to have all three. It may be, you know, for example, which is just a happy eyeball or the and the error reporting mechanism, maybe they can they can start. This way, after you start, you you monitor, you know, for example, your whether I v six is used, you know, the I p v six traffic is that the fallback rate, you you fix problem. So effectively, these turn these change the existing IPv6 deployment model from very, you know, workload, your front heavy workload. You have to do all the, you know, a lot of validation work before you switch on I p v six and then also a big risky into a gradual enablement monitoring and ramification processes. We believe that this will make it easier for for small and medium enterprise to to deploy I p v six. And in the last slide, where I want to kind of like address some of the known concern. For example, one of the concern is that, oh, lack of enterprise IPv6 adoption is mostly about lack of motivation. It's not about technology or or difficulty. But we want to say that technology difficulty does affect the motivation. So, you know, the more difficult to to to do usually, you know, the less motivation people will have. We also want to say that there are certain organization. They already decided to deploy I p v six. So they do have the motivation. But because I p v six deployment is quite difficult, as a result that they suffer and they they decided to roll back. So enhance your stack. If you can reduce difficulty, it will definitely, you know, help in these cases in these cases. Another argument against it is that, well, it's mostly about manager support Manager support. You know, because it's not a technical issue, so EDS may not help. I would like to say that manager support, manager generally don't care. It's not that they have a bias against I p v six. It's just that they don't care. So if you say that, oh, you know, because I want to deploy I p v six, I need your support on this, on that, you know, resources. Then they they will not support you because they don't care. But, you know, if it's relatively easy for you to to do, you ask for very little support or even, you know, no support. Then they they not block you either. So from this perspective, I think that it's still it can still help. And the the last one is that, oh, the the network or the mini traders, they just don't want to change because it's addiction not work for them. Because, you know, they don't want to learn, you know, complex IPv6. But again, you know, if we can make it easy to to to to learn, you know, easier, then I think that they may have some more motivation to change. And therefore, I think that overall, we believe that, you know, it's helpful. It's helpful despite the the the skepticism. And therefore, I hope we move from, you know, asking the why part to the how part. Like, you know, Eric, Philip, kind of like providing comments on the on the mechanism, certain mechanism. Yes. I like to discuss the mechanisms. And again, you know, I ask people to to review the draft, and especially if you have enterprise I p v six deployment experience and software development experience, please help to define or refine the mechanism and possibly become co author. Thank you. Questions?
[01:16:06] Philip Thiesel: Philip Thiesel. I have not a question, but few comments here. And first, the draft is a mixed bag of things. And I think if one one or two of these things should be successful, it would make sense, at least from my perspective, to fend them out and discuss them separately because it's it's really an architecture of things that don't belong together. So let's start with the idea of, yeah, changing the current socket API in a way that makes something of happy eyeballs light. I would call myself as a happy eyeballs enthusiast. As we spent a lot of time discussing all the details and what you could do wrong with happy eyeballs, That's definitely a very dangerous path on the one hand. And on the other hand, it's a path where the chance that actual operating system implementers would take up that idea of changing the behavior of get other info is practically zero. So I think that's damned to fail if you really ask about the operating systems vendors to do that. Even if you go into the classic network programming book, they tell you the pattern is you get other info and then loop over the results and fail back. So the solution that works in 90% of the case would be lowering the connection time out, which would already work for badly breaking IPv6. In the next step, this still needs people fixing their code to do that loop. And you have a lot of documentation, especially in the Python world left, that just uses the first one of the reply of get other info. And I think now adding another hack on top of that is not a good way, and it breaks the assumptions of the API. So that's my primary concern about the technical solution. On the management side, I would say that things are even that more dire because management big corporations is usually tasked for short term gains. And let's be honest, we all know that IPv6 is a long term game. It's an ultramarathon. And you won't finish that in a good water. So there's a bias against IPv6 and we have should rather focus on still explaining why it's worth the effort than to make it look less like what it is? Thank you.
[01:19:09] Shuping Peng: Thank you, Filip. So I will just quickly state three points. The first point is that we are going to write draft in six main to propose some update to IFC sixty seven twenty four. And because the OS company have already implement sixty seven twenty four, if, you know, we have an update. I think that guys maybe that's a chance that get it also get implemented. And this is also, you know, talk about in in happy working group. We will we'll we'll see. Tom?
[01:19:50] Tom Hill: Thank you, Shupang. Tom Hill from BT. I think we tried this at some point in the past, or I think Microsoft tried this in Windows, and it it was not particularly helpful. They sort of did a test and remembered whether v six worked or not, and then remembered that for a month before doing another test, and it was altogether a bad idea. So I'm not sure it was the something we want to repeat. But perhaps more philosophically and more fundamentally, I think you're running a very significant risk here of reinforcing the ideology that I p v six is hard and difficult, and it's not. But you have to have you you have to be as an organization, you have to have thought, need to put the effort into this. We can't skip a few steps, and it will work okay. So we we we don't I don't think we want to reinforce that minimum effort that particularly enterprises will make. I don't think we want to encourage them to say, it's okay. We've checked the box. It's done. We can move on. We don't have to listen to people talking to us about this I p v six thing again. So that's that's certainly more of a philosophical point, but I think the the trouble is is that if you reinforce how that that this is hard, that will keep being the status quo in enterprises. And and I think we need to change that rather than help.
[01:21:18] Tim Winters: Tom, I I I
[01:21:19] Shuping Peng: would say this. I think that get Louis a similar concern. And I really believe that for the people in this room in v six op, maybe it's not so hard. But I think that from many of the enterprise network administrator, it's really hard. It's really hard. And I think that we have to acknowledge a problem. Every time we acknowledge a problem, maybe there is some concern. But still, I feel that if we we do nothing, maybe it will take a very long time for the SMEs to adopt IPv6.
[01:21:58] Philip Thiesel: I have to stress something he just said. And, IPv6 is not that hard for the corporate network operators and for the application developers. It's not that hard. What is really, really hard is being brave enough to decide to get going. Picks a steel heart. Once you're on your way and doing this stuff. I've had nobody in the company after that project that told me, Oh gosh, it was harder than I anticipated. But I had hundreds of people telling me, Oh shit, we discussed much longer about how hard it is than the stuff I actually needed to do.
[01:22:59] Shuping Peng: Warren? Yeah,
[01:23:05] Warren Kumari: Warren Kumari, Google. I mean making assertions that it's not hard
[01:23:10] Ondřej Caletka: and then looking at the amount
[01:23:11] Warren Kumari: of deployment numbers, something is not matching up here. Sure. It might, I can just comment that, you know, it's scary to get going but once you get going it's really easy. It's really easy for some set of people who've got a bunch of V six knowledge but there's a huge number of small enterprises where the people don't really know what they don't know yet. I did, you know, especially if their network is currently really messy and there are a lot of enterprises, especially small ones, where they don't even know how many servers they are, they don't really quite
[01:23:56] Philip Thiesel: know where a router
[01:23:57] Warren Kumari: is, and any change for them is hard. Making this less hard, Jen's going to disagree with me.
[01:24:06] Jen Linkova: Jen, go enterprise operator who deployed v six. BGP is hard, ISPF is hard, VXLAN is hard. Right? Cloud, I can't even I don't even want to think about it. Right? People using what they need to use and the reason enterprises don't do v six is they perfectly happy without it. And no get other whatever info changes will change that.
[01:24:34] Warren Kumari: Warren Kumari again. I mean, yes. What Jen said, those things are hard, but a huge number of enterprises aren't doing those things because they're hard. Right? Because they don't need them. They also, for many cases, they think they don't need this either. So we shouldn't make it, oh my god, it's really scary, but we should point out these are the pitfalls you might fall into. Here's how not to fall into them.
[01:25:02] Shuping Peng: Okay. Thank you for your comments.
[01:25:10] Jen Linkova: Yes. Hello. Last minute addition to the agenda because this time we broke our standard and we got six months before v six ops, and when you have v six ops on Friday, during the week, you people come up with some crazy ideas over caution. So, remember Slack? Remember Slack renum? And I think this group published RFC about all this renumbering issue and how especially home deployments suffer from renumbering. And now there is a follow-up draft in six men about how improve slack remembering events by tweaking timers. So, that draft is actually still in the six men last call because the authors and reviewers are discussing for hours about what to do about network and devices dropping multicast and how many multicast arrays in a given period of time is enough and how short this period of time should be and is it going to be raised to the bottom when network sends more multicast and device drops more multicast and so on. And as a six man chair, I wanted to this draft to progress. So I was like, how long we're discuss this and can we add another like sticky tape or band aid on top of this? So if the main problem is that multicast arrays are dropped and the problem we are trying to solve is renumbering when a router wants to propagate some changes in the information. Can we just send those arrays as unicast? I don't like, again, I don't know if it's a good idea or not and it's definitely not a silver bullet which supposed to solve every single problem. I was thinking about it more like there's no Swiss cheese stove when you put another layer hoping that holes do not align. So, I posted zero zero very quickly and that one pager was just saying, okay, just look in your neighbor discovery table, look at all link local neighbors which are reachable or stale and just send unicast array with configuration change information which you want to propagate quickly. Then I think few people pointed out that we actually can just convert l three multicast to all host to Ethernet unicast doing more or less the same logic. Right? Obviously, enterprise networks often actually do it on the WiFi level. Right? You you can configure your Wi Fi controller to do multicast to unicast conversion and it's supposed to help. So, I don't know basically what's the right approach here or maybe we can again combine different things. Based on the review, obviously, there are some fine details we need to tune in the draft. For example, obviously, do not send everything together and spread them, do something about links and again, enterprise networks probably do not need this because your Wi Fi stuff does this. It's more about like small CP stuff, small networks. And I actually think this network does not do the conversion, at least based on what I see in the packet capture. So, they've been I see Andrew is trying to go to the queue, but yes, we did discuss it on the list. Can we just send array always as unicast? The question the problem is, right, if you're talking about layer three unicast, it's a problem because if it's if you are in your router, you don't know who your neighbors are. Right? So you definitely need to keep l three multicast to all host. Maybe the right solution, as we discussed, just to fix Wi Fi thing and just always enforce APs to convert multicast to unicast to all neighbors, which actually means we instead of writing all of this, we need to write one pager and go to Wi Fi people. Right? And sort this. I am, like, open to suggestions. Maybe we can do multiple things in the same time and so on. So, questions?
[01:29:51] Andriy Yurchenko: And, in the business of converting arrays to Unicast for ten years, I think the first the concern is maybe not so big because the host, when it comes up, normally sends router solicitation. And a lot of those can be already unicast. But there is another thing that I I kinda didn't see too much in the draft, which is if we do send if we do send it to I p v six unicast, then we might inadvertently trigger the NED. And if we are doing flash change, that there probably should be more text.
[01:30:28] Jen Linkova: Zero two actually talks about this and that's the reason why second option is actually better. When you still have l three multicast send as l two unicast, it would avoid all of this and, apparently, as there are other benefits. Again, this draft, the zero two actually talks about that stuff. But, again, right, about new host, no, it's not about new hosts coming, it's about you reboot the router, it gets a new prefix from PD, right? It will not solve in this case because the new routers comes up, it has no idea what's going on or you plug in your router. The good thing is actually that if we plug in a new router in addition to existing stuff, your host can use the old stuff. If all routers disappear and only new stuff coming up, your host probably lost network connectivity and then they will start doing something about that. Like devices like Android will just fall off the network and reconnect and so on. Again, it is not a silver bullet, it's not going to solve the problem. I think about it more like an optimization which based on what Slack renamed talks about seem to be a problem. Right? And how we can make it more reliable. Again, maybe we just need to talk to Wi Fi people and tell, please always convert multicast to unicast. I don't know why it's not a default. I have no idea. Is it hard to do? Is it not recommended as a corner cases? Why do Wi Fi access points don't do it all the time?
[01:31:57] Andriy Yurchenko: Yeah. I mean, to add one more comment about the optimization, the optimizations that are kind of corner cases, which this would be tend to be broken. So that's where I would say it would be interesting to see whether we can make maybe all our race follow this scheme. Because I think there's no fundamental problem with it.
[01:32:24] Ondřej Caletka: Jean. Just one point here because you are proposing to do this only when something significant changes in the array, like a renumbering of network. That also means that, by definition, if you are a numbering network, all running sessions will break because the network is renumbering. Like so so it's already very disruptive.
[01:32:46] Jen Linkova: It's not necessary case. I might add the new prefix. I might change timers. It might be I I do have a feature request for a certain network vendor. So when I do commit on configuration impacting array, I want a new array to be scheduled immediately and sent, it does not necessary I remove the old prefix and new one. It could be anything which changes content of the array. Well, it it doesn't mean you necessary break the new stuff. Maybe your old stuff still works. Right? And but I want to renumber, and I don't want to wait for, like, hours and hours for all sessions.
[01:33:20] Ondřej Caletka: Well, that was basically my point. So I'm thinking if if you are, like if if the point here is to make sure that everybody on the network hears the new array because there are important updates in it, then I think it's actually a reasonable compromise to send even hundreds of unicast packets on the network to make it because because the network is probably being disrupted anyway.
[01:33:43] Jen Linkova: And, like, to be honest, it means one packet per client. Right?
[01:33:47] Ondřej Caletka: Yeah.
[01:33:48] Jen Linkova: Is it like a big if if if your router cannot send one packet per client, I think we have a bigger problem here.
[01:33:57] Eric Vyncke: Eric, So good job. Go for it. Same command as Andrew. You may want to think as well to send the multicast array first.
[01:34:06] Jen Linkova: Like, draft currently saying, do do this in addition to whatever you're doing. It does not specify the order because I don't know if it's beneficial or not to over specify here. And if there are preferences and reasons to do that, I'm happy too. If not, I'm trying to be as, like let's say, I'm trying to be a list restrictive.
[01:34:32] Tim Winters: I already made my comments on list. You did ask whether it's worth doing this versus going to to fix eight to eleven. I think that's not the question. I think at this point, we just do everything and we see what works. That's that's what will somehow get us to it.
[01:34:48] Jen Linkova: So okay. So do you like me to go to, like, to talk to Liza, or you going to do that? Or we can do it together?
[01:34:55] Tim Winters: Let's yeah. Let's talk about it afterwards. Tim Winners, QA cafe. So a couple things here. I I generally like exploring this idea. I think we should be real careful with the scope. The only other thing I'm gonna say here is CPEs traditionally keep the RA stuff far, far away from the ND stuff. So it's gonna be really hard to pair those two together and have it look up all the caches and send it out. I mean, it's doable, but it's not a a typical flow for most home gateways.
[01:35:28] Jen Linkova: Okay. That's a valuable feedback. Yeah. I again, yes, it's thank you. Yeah. I would like to hear from implementers because I Lorenzo pointed out, array DVD has a similar theme, but you need to specify all neighbors in the config, and then it never sends a multicast. I'm I'm I I don't know if you can kind of mix Yeah. I think it's crossbones.
[01:35:46] Tim Winters: I think there's some things to explore here. I I think we should explore.
[01:35:51] Jen Linkova: But you still think it's useful. Right? So it's not a bad idea, the leg don't, like
[01:35:57] Tim Winters: I'm not gonna go that. I I think there's some things to think about with our AGuard. I think in general, we should talk about this, and we should continue to work on it. So I don't think it's a bad idea. No.
[01:36:08] Lorenzo Colitti: Lorenzo Clooney. I yo. Obviously, we do need to do this to solve this problem. Unfortunately, I actually think this is not the right solution, unfortunately, because it's easy and it seems to make sense. But I think it like, one issue that we have is for something like snack, right, you don't have the neighbors in your in your neighbor table. Right? So you have all of these issues, and we're, like, you're putting all of these workarounds. I mean, I think if we think we can influence so the other thing is that you've all these you've got all of these deployments like what I have at home. I have a home router, and I have, like, these, like, mesh Wi Fi boxes. They're not the ones sending the RAs. So I think if we wanna do something, we, Android, are gonna try to fix some of the hosts, but it'll take years. But I think if we wanna do something, we should basically go to eight zero two to 11 and say, look, we give up. For these packets, just send the BUNICAST. Because because because, like, no. Even DMS. Right? DMS is like, oh, now I have to implement this thing, and then, like, everything's gonna be buggy, and I have these state overflows, and then sometimes it's not gonna work. And I like I just think, you know, we should just say, look, look, eight zero two to 11. These are critical packets. Just always send them unicast. Because the nice thing is that the AP does have the the list of of MAC addresses. So I think we're better off, unfortunately, just writing a document that says that.
[01:37:39] Jen Linkova: Okay. So, like, because my knowledge of Wi Fi is much more limited than I'd like it to be. Is there any disadvantages of doing that conversion? Why it's not a default? Because nobody has asked for it or because there is, like, issues with that? That's I don't know, and I don't know if people could tell me.
[01:37:59] Lorenzo Colitti: Because it doesn't break a p v four?
[01:38:02] Jen Linkova: So nobody asked for it. Okay. Yeah. That's fine. That's good answer. Yeah. If it's the case
[01:38:06] Lorenzo Colitti: And also, it it it, like, seems to work well enough that no one thinks to fix it. And it's yeah. Even now, if the timers are right, it mostly works right.
[01:38:19] Tim Chown: Tim Chang? So I think Lorenzo's answer is the practical pragmatic thing. I would just point out though that if you want to tell a host over Unicast about changes to the network and the network it's in, there's always DHCPv6 reconfigure.
[01:38:33] Jen Linkova: Who are you again? Anyone has a pen? I write it down. Okay. Thank you. Okay. Well, like, again, it's six month document. So, like, next time, we'll talk about it on six month. Thank you.
[01:39:07] Tsinghua University Representative: Good morning, everyone. My name is from Tsinghua University. Today, I will talk about, observation on the whole package query, IPv6, and the external header in the Internet, and where and why they are failed. We just got the time now.
[01:39:23] Jordi Palet Martínez: By the way of
[01:39:25] Tsinghua University Representative: background, IPv6 is certain header sites between the basic layer and up layer protocols. And an embedding key feature will keep the basic layer simply. They are widely used for mobility, security, and routing. While they are handling us also introduce security risk, handling can be, light traffic pass by filters or price denial of service vectors. This gap between, intended functionality and the real world handling, motivated this study. Two question requirement open. First, how reliable different extension headers travels real words, and what caused the package to drop? Second, whenever, whenever extension headers can be used to get past fail words rules, Exchanging works report drops rates but not the underlying mechanic or security implications. The mathematic combine two approach, pass travel measurements, send a proper and record the last responding notes, indicate where package are dropped. Comparative analysis contrasts under pro probers with exchanger header probers to and for where filtering occur and whatever exchanger header pass by in the filter. Measurements are carrying out with new travel, a large scale mathematic measurements across the Internet. For the step, 11 common external header tabs are tasks, and the target sets over covers three point seven point three million slash 48 perfect cross near 24,000 years and 17 industrial centers. All measurements are in from the single white white points in an educational network in Beijing, giving broad coverage of global IPv6 pass. Unreachable, the destination operation and the automated fragment headers now reach the destination close to standard TCP and UDP traffic. We have fragments out and loads handers remind more heavy filtered. The near parts of some extension header favor deploying extension header basic technologies, but the same property that malicious extension header traffic travels network, although almost as well as normal package. Broken down by industrial to construction from policy, traffic constructions, media, manufacturing, fix permissive policies. So some external header even cross even exceed the baseline reachable. We all risk the exports. Governments enforce the strict TCP filter for narrowing all extension headers,
[01:43:11] Tim Winters: which is a
[01:43:12] Tsinghua University Representative: sector but constructor IPv6 evolution. House care by contractor is protocol neutral with minimal filtering. On the security side, if extension header pass filters, they may be used to bypass fail works, map handler network, or rich protect service. A partition a partial bypass in the is denying as destinations that block standard pro probers but accept the extension header pro index extension header, like traffic slip path passed as a fail work use. The scary the scary is significance. Rosaliv 5,000 AS exhibits potential bypass significance. The effect is more pronounced for I TCP and UDP rather than ICMP, and it's been every industrial sectors exempt. Indicates a widespread rather than isolated issue. It can be speculated that there are several contribution factors. Some maybe, contributes to implementory bugs in the in how the thread extension headers. Others may stem from, misconfiguration, pattern rep reputation in the control control the tasks. In addition, IPsec policy may be configured to permissively, and newer extension header tabs are frequently left on handle and forward without inspection. One cons concern case is related to the pattern. In a observation campus network two edge, bias by four, we can say the two edge router extension, classical ex extension headers fails. The Fair Work is back to only the first layer, header. And if the it isn't not TCP or UDP, the package is permitted. TCP SSH connecting the is inside extension header, therefore, passed without expectation expectation of the inner payload. We offer some suggestion. First, the firewall should expect the full extension header train before applies ACLS. So deep, it's back to courier those risks. Selective selective filtering can limit the tabs, the list, and the number of extension headers. A layer approach apply a deep inspection to inspections to permitted extension headers, authorized blocking stop evasion, and but also handouts IPv6 evolution. So the goal is met is evasions without a forward closing extension header deployment. Thank you for your patience.
[01:46:58] Eric Vyncke: Eric Vane, no special hat except that I spend multiple times doing similar stuff, pretty much like the guy behind me, and I will talk about you just then. So first thing, normally, when you are in the room, you need to scan the QR code to be in the list of participants, and I was unable to find you. That's a detail. On the slide two, you say that firewall do not cannot process packets with extension headers. The older firewalls I know for five or seven years now can simply skip. It's different from some high speed router, high speed switch for sure. You may want to consider, if you continue your research, to compare it with existing research that has been done by several people in this room. Will you use another suggestions for improvement? I mean, the single vantage point located in single geography is pretty limiting. You should at least one vantage point per continent. It will help a lot to get much more accurate result and useful result. May also suggest that using SSH and SNMP that are typically management protocol that could be blocked on purpose by some firewall. Right? So using those for the probing is most probably not the the correct. It is introduce a bias. And lastly, the guy behind me and myself, he wrote r s c ninety five eleven, which basically contains some old when you do probing like this, if somebody detects it, they can relate. It's not a dose, but it's basically a scientific research. Did you use it? Yes. Okay. Perfect then. Thank you.
[01:48:47] Tsinghua University Representative: Thank you for your comments. I will to add vantage points, and I will to compare with current research.
[01:49:00] Unidentified: Justin. So I concur with Eric. All the remarks are were were good. One more comment. I think here, are using the small size for the extension headers. Right? So what you are actually measuring here is the best case, and this is why you have some good results, let's say. So I suspect that if you increase the size of specific extension headers, you would see the results decreasing. Right?
[01:49:38] Shuping Peng: Okay. Okay. Thank you.
[01:49:47] Jen Linkova: Somehow.
[01:49:52] Jordi Palet Martínez: Hello? Can you hear me?
[01:49:55] Shuping Peng: Yes.
[01:49:56] Jordi Palet Martínez: Hello?
[01:49:58] Chenyi Hou: Good morning, everyone. This is China Hou from China Telecom. On behalf of author's president, this individual draft considering so interested of every Sony department in five g mobile networks. Next slide. I oh, first of all, it's a document core objective review. This draft is to bridge the gap between standards and the deployments. And also, this is the value of this draft. We I we did a research for relevant RFCs. RFC seventy four forty five analyzes some failure cases in I p v six roaming scenarios. Well, I will say sixty four and fifty nine provides an overview of I p v six in the three d p p. I will load the packet up system. So there is there are gonna have a dedicated document that addresses 5G IPv6-only deployment from an operator's perspective. And also, to draft this to address the real world deployment changes, how to gather the network to know if you use the prototype only and how to ensure IPv6 service continue to run these scenarios and gradually go out without impacting production traffic. And then the cluster drive was the industry consensus. Next slide. And now it's the third two zero three version. What we have updated, first, it's a title. We removed the word gradual to make it more general. And the target audience, we added five g basic basic concepts related to IP for broader community. For deployment approaches, we now focused on focusing on PCL based and based and added a DLN isolation for testing. So in for operation consideration, we add a new section six to and to talk about the organizational challenges, Netfix four performance, and IP way for our services. For for five g concepts, we add a new section three. It talks about five g device concepts, DLN PDOs, session, and the roaming model modes.
[01:52:56] Philip Thiesel: Next slide.
[01:53:02] Chenyi Hou: Here here, we bring up two department solution for further discussion. As we know, PCL is a 3PP specific control plane signaling. In PCO based solution, UE signal signals the IPv6-only capability with or PCO, but there is no ITF or 3PP standards to define the parameters or procedures is enterprise specific. And for our AI based solution is what we want to advertise a prefix, say, for such information where there are a. So and we can reuse some existing tools. So note that that we don't talk about a basic protocol about RA or PCO based solution. Just draft just the document, the information, what we have about five g IPv6 only deployment. This topic is for open discussion. I think here we have some work, maybe have some work to do. For PCO based solution parts, we maybe need to define the basic parameter and the procedures. And if we think AI based solution is the good direction, and we need to define some corresponding mechanisms. Next slide. Here, why we we comment to to our best approach? My point is that IP release, the matters should be handled as IP layer. And this this will help us simplify deployments and the implementation of all those among other domains and ultimately makes the deployment easier. Here, I also released some advantages, including the access agnostic. So we we will have a unified framework works across the cellular or Wi Fi fixed satellite or and other advantages of control plane, decode. No three d b core signaling dependence. SMi4 doesn't need to know UE capability. Dynamic updates, net of this for prefix change pro propagated with RA. There is no PDU section service establishment needed. And also by including sharing and observe. Next slide. I can't see. Mhmm. There are some questions we received on our responses. I think this will help her make the document clearly. First of all, I q six only is actually referring to four six four x lite. I think it's only with the IPv4 ASR service. And select like functionality can be provided in other ways, and we will add a note in the terminology section. Not all UE supports to select could be clarified further, including vendor policy from wire per five g devices, etcetera. So we will use one of the explanation to cover the various factors, including wonder policy choices from wire and the device generation. Section 5.1 says no standard defense to PCO based parameters. Is this no standard, or what the tool about it that just to mention the in the previous slide, so I don't have repeat it. Mister and slasher 64 previous sharing explanation, and we will add a subseq add a text on this. Next slide. So thanks to value valuable input from o v six ops. It's special to Jordan, Matt. We seem that this is dropped to use the drop of the target is informational, and we welcome more discussions on five g episode only department copies. I think that the structure of the draft is good enough, maybe good enough, and we hope can be adopted as a worker group trust and serve as useful beverage. Thank you.
[01:58:22] Jordi Palet Martínez: Jordi Palette. I think that this document is taking a good shape. I think we should adopt as a working group item. It's a very important work. I think also we need to work with the liaison with 3GPP to either do a PCO profile for NAT64 or the array or bot. I am not sure how hard that will be with FreeGPP, but I think it's something that we need to sort out because it's one of the problem that we have with deployment of IPv6 in mobile operators. It looks they are relying on RFC7084, but in an incomplete way because they forget that it was updated by RFC eight eight eight zero. So it's it's not really working as expected.
[01:59:22] Jen Linkova: Yeah. I am glad to see that some of our operators might be interested in pref six four. And, yes, and I guess three GBP and and more importantly, I guess the vendor then equipment vendors here need to be informed. I suspect because, like, we already have RA options, so all all I think needs to be done is for equipment which sends RA to support this, and I guess it should come from the customers. Right? So, yeah, please ask them, and I guess we'll start. And probably, eventually, mobile operators will move in that direction.
[01:59:57] Chenyi Hou: Okay. Thank you.
[02:00:01] Nick Buraglio: Alright. Well, we ended with one minute to spare. For the as time permits drafts, please take the discussions to the mailing list so we can continue talking about those. And, yeah, do have any any closing comments? If not, this concludes v six ops for IETf-one twenty six. Thank you.
[02:00:28] Shuping Peng: Thank you for your participation.
[02:01:48] Nick Buraglio: We moved from, like, an
[02:01:49] Shuping Peng: open source to a VPN.