WEBVTT 00:00.000 --> 00:09.800 There was two of them, right? 00:09.800 --> 00:15.760 Yeah, yeah, so we got three of them, uh, 00:15.760 --> 00:20.840 one of them, right? 00:20.840 --> 00:25.320 Yeah, I think, yes, okay. 00:25.320 --> 00:30.280 So yeah, I'm going to do a talk on IPv6. 00:30.280 --> 00:32.560 That's just the people are coming coming in here. 00:32.560 --> 00:35.480 And IPv6, I'm Kubernetes. 00:36.480 --> 00:38.680 Let's get started. 00:38.680 --> 00:40.840 So that's all who am I. 00:40.840 --> 00:42.520 I'm from North Norway. 00:42.520 --> 00:46.080 I work as a platform engineer that's up. 00:46.080 --> 00:48.080 That's all those things. 00:48.080 --> 00:50.400 I'll take a little first call and come out in norming. 00:50.400 --> 00:55.000 I have all the CNC certifications, a lot of them. 00:55.880 --> 01:00.360 Yeah, I'm using IPv6 at home since like 2013. 01:00.360 --> 01:03.360 So I know how my own SNL. 01:03.360 --> 01:06.160 Yeah, kind of for nerd. 01:06.160 --> 01:13.640 So let's first talk about IPv4 or the legacy IP. 01:13.640 --> 01:17.760 It's basically a corner that we're in protocol today. 01:17.760 --> 01:20.120 It was standardized in like 19 then. 01:20.120 --> 01:23.080 The eighties, it's been around for a while. 01:23.160 --> 01:27.160 Most of you are probably pretty familiar with it. 01:27.160 --> 01:33.160 You know, pretty standard IP of like the SML and 32 bits. 01:33.160 --> 01:37.400 The biggest issue with like before today is it's ice. 01:37.400 --> 01:40.400 There are four, three billion others as well. 01:45.840 --> 01:49.000 And as you can last and the current wall population, 01:49.000 --> 01:51.520 we just like, yeah, a lot, a lot more people. 01:51.520 --> 01:56.160 And most people also have multiple devices and so yeah. 01:56.160 --> 02:00.160 And the work going for that is today is we come for something called not. 02:00.160 --> 02:06.240 It's basically like way to hide multiple users behind the same IP. 02:06.240 --> 02:11.160 This brings a lot of complexity, a lot of limitations. 02:11.160 --> 02:14.800 And it's not really a little bit of work, but it's kind of back 02:14.800 --> 02:20.960 that it had to do because of the outcome of IP addresses. 02:20.960 --> 02:25.680 So we're starting with IPv6 now. 02:25.680 --> 02:28.560 For providers like the red, the red, the red, the 32, 02:28.560 --> 02:32.080 started charging for the big IP for addresses. 02:32.080 --> 02:34.960 More and more ISP and I was just starting to record care 02:34.960 --> 02:40.560 right now, especially means that we have multiple layers of not. 02:40.560 --> 02:44.880 It's even more complexity, so it brings a lot of issues as well. 02:44.880 --> 02:46.560 And if you're having a lot of them, the users 02:46.640 --> 02:49.760 bind the same external IP. 02:49.760 --> 02:53.360 And also have things like services that are red, red limits, 02:53.360 --> 02:57.120 like the Docker with IR, we have hospitals for IPv4 address, 02:57.120 --> 03:00.720 if you don't authenticate. 03:00.720 --> 03:01.760 So it's going to be interesting. 03:01.760 --> 03:07.440 You have all the users behind the same external IPv4 address. 03:07.440 --> 03:11.120 And yeah, they also if you want to get them out of the day, 03:11.120 --> 03:15.680 this is the repo, if you want to get them out of here. 03:15.680 --> 03:22.400 The queue is like 500 days plus sort of time. 03:22.400 --> 03:24.240 You can see it's growing and growing. 03:24.240 --> 03:26.800 Growing, so basically, we are out of IPv4, 03:26.800 --> 03:27.600 public addresses. 03:27.600 --> 03:30.240 We have to buy it to film something today. 03:30.240 --> 03:33.680 And it's quite expensive. 03:33.680 --> 03:36.160 So the fix is basically IPv6. 03:36.160 --> 03:39.040 It was implemented in the first draft, 03:39.040 --> 03:41.360 it was in 1998, so it's for something new, 03:41.360 --> 03:43.280 new, actually. 03:43.280 --> 03:45.440 There are a lot of new things about IPv6, 03:45.440 --> 03:50.880 but the biggest one and the most important one is the larger address space. 03:50.880 --> 03:55.200 So I have 120 bits, because if you don't know, 03:55.200 --> 03:59.200 basically, the bitmap knows that that's a lot of larger. 03:59.200 --> 04:03.920 So this is the number of IPv4 address for three billion around. 04:03.920 --> 04:06.640 This is the number of people in the world currently, 04:06.640 --> 04:10.400 at least my last day, Google said so. 04:10.400 --> 04:15.360 So pocket-pocket metric, and this is the number of IPv6 addresses. 04:15.360 --> 04:20.560 It's quite a lot larger, and that's something 04:20.560 --> 04:26.240 going to run out of anything soon, and who can probably sustain us a lot of 04:26.240 --> 04:28.240 years into the future. 04:28.240 --> 04:33.680 And that's going to try to pronounce the number, but it's a lot of larger. 04:33.680 --> 04:35.600 Also, some visitors say, significantly, 04:35.600 --> 04:39.040 when this is in the space, it's not like this time. 04:39.040 --> 04:43.200 It's a lot of data that I've before, and I've just 04:43.200 --> 04:46.320 huge circle of being IPv6 address. 04:46.320 --> 04:53.920 So it's quite a lot bigger address space. 04:53.920 --> 04:55.520 So yeah, it's based on hack-fax, 04:55.520 --> 04:57.200 there's a lot of the annotations are going to do 04:57.200 --> 05:00.000 into the details here, how to do it, but it's 05:00.000 --> 05:04.720 yeah, some of you have probably seen an IPv6 address. 05:04.720 --> 05:08.560 There's basically no need for not to extend their address space. 05:08.560 --> 05:11.520 There's still some can be so not here and there, but at least 05:11.600 --> 05:19.040 but extending the space, there's basically no need. 05:19.040 --> 05:23.280 This is the stats from Google from yesterday, I think. 05:23.280 --> 05:27.920 They're close to 50% adoption. 05:27.920 --> 05:32.560 So under users are slowly getting there. 05:32.560 --> 05:35.600 It's a list in the last five years that we've not got 20% 05:35.600 --> 05:41.360 increased, so hopefully it will continue at that speed, at least for a while. 05:41.360 --> 05:44.880 So we're like, then under users are getting there. 05:44.880 --> 05:55.680 And also bedroom is likely a 71% this is quite good above average. 05:55.680 --> 05:58.560 So the issue is, I'm on a vision site, 05:58.560 --> 06:02.400 lots of talking, lots of innovations, websites. 06:02.400 --> 06:07.760 Like, on a vision banking is like 19% support IPv6. 06:07.840 --> 06:10.480 I think this is just the front page. 06:10.480 --> 06:16.560 It was just like the very basic IPv6 support. 06:16.560 --> 06:20.320 So now even IPv6, I think it's like 25% major website 06:20.320 --> 06:23.520 or the six public services, 50%. 06:23.520 --> 06:25.760 But if you also take into account that there's actually a lot of 06:25.760 --> 06:30.800 say that public services needs to be IPv6 already. 06:30.800 --> 06:35.520 If the option is kind of that, if there's a lot that says that you have to do it. 06:35.600 --> 06:38.960 And like the biggest one, if you are the developer, 06:38.960 --> 06:43.600 it's like, it doesn't still support IPv6. 06:43.600 --> 06:52.320 And this is kind of sad for shame on all of them. 06:52.320 --> 06:55.120 This basically means that you need to run dual stack. 06:55.120 --> 07:01.040 You need to support both IPv6 and IPv4 for a while. 07:01.040 --> 07:03.440 So if I have something called dual stack, 07:03.440 --> 07:08.400 means that for an both, you don't want to have an IPv4 on IPv6 address. 07:08.400 --> 07:10.080 And we can use it either. 07:10.080 --> 07:12.240 So if it depends depending on what your destination is, 07:12.240 --> 07:16.720 just the destination is, you can use IPv4 or IPv6. 07:16.720 --> 07:23.440 But this means that you need to have a DNS record for all the services you want to use in both. 07:23.440 --> 07:29.280 More than operating systems prefer IPv6 or IPv4, but it's not guaranteed. 07:29.920 --> 07:34.800 Sometimes it is preferred to use IPv4 even if you have an IPv6 connection. 07:36.400 --> 07:38.240 And that's a lot of complexity. 07:38.240 --> 07:40.000 It's usually not certainly had two stacks. 07:41.280 --> 07:42.720 You need to secure both of them. 07:42.720 --> 07:45.680 You need to think about security products and however we use 07:45.680 --> 07:47.120 and everything for both of the stacks. 07:47.760 --> 07:52.880 And for other things, you might end up with some traffic on IPv4 and IPv6 and yeah. 07:53.920 --> 07:56.480 It's more complex. 07:57.440 --> 08:00.720 For clients, this is mostly still needed. 08:01.920 --> 08:04.480 Unless you have something called IPv6 mode, 08:04.480 --> 08:07.200 it is actually an in-use on the Wi-Fi here. 08:07.200 --> 08:14.320 So if you have an iPhone, you can actually see that you don't get the superware IPv4 address. 08:15.120 --> 08:20.640 And there are a few people who only get the public IPv6 address here on your iPhone with this supercure. 08:21.600 --> 08:23.760 For services, it's supposed to undo service. 08:23.760 --> 08:29.200 This is still needed since it's only around 50% support IPv6. 08:30.480 --> 08:32.640 And the service that mostly talked each other, 08:33.760 --> 08:36.400 then why do you need both stacks if you have a database server, 08:36.400 --> 08:38.560 it's supposed to talk to the back-and-series. 08:38.560 --> 08:42.880 But the value of the database server needs to have up before on IPv6. 08:43.920 --> 08:45.920 There's little need for it. 08:46.880 --> 08:49.920 So getting into Kubernetes, 08:51.200 --> 08:54.480 at V6 only Kubernetes has been supported for OI. 08:59.040 --> 09:01.120 It's basically means that the pod-runner service 09:01.760 --> 09:03.440 on an IPv6 address, 09:04.560 --> 09:08.560 do you stack with the implement on the Wi-Fi there in Kubernetes 1.23, 09:09.600 --> 09:12.880 which means that every pod begots an IP from each family. 09:12.880 --> 09:16.160 So we have basically a dual stack, so as we mentioned, 09:17.120 --> 09:21.120 and then communicate the service as can be declared as a single or dual stack support for them. 09:24.320 --> 09:28.160 And now we also means that each pod have an IPv6 address, 09:29.440 --> 09:31.120 can be a public IPv6 address. 09:31.680 --> 09:35.440 That means that it's basically still needed to think about the curators since it's 09:36.720 --> 09:39.360 public IPv6 address, but there's no need for not. 09:39.440 --> 09:43.200 So you can basically have an end-to-end connectivity behind the pod, 09:43.200 --> 09:46.560 then do an user for the service. 09:50.160 --> 09:53.920 This talk is mostly about how running your own method setups, 09:53.920 --> 09:57.920 but the mention of, like, the mention of the support units in the cloud providers, 09:58.960 --> 10:02.800 like Amazon, yes, the support dual stack for OIL, 10:03.840 --> 10:05.360 and it's a beast support dual stack, 10:05.360 --> 10:07.200 and as sure support dual stack with kind of them, 10:07.280 --> 10:09.120 we are nothing in the way it's in there. 10:10.720 --> 10:14.720 And there's, like, mixed method in the providers, 10:14.720 --> 10:16.560 and not everything is supported always, 10:16.560 --> 10:19.200 and you can find bugs that are supported, 10:19.200 --> 10:22.320 that's the existing IPv4, and there's still some issues, 10:22.320 --> 10:24.720 but that is, that is, you sort of do support it. 10:27.120 --> 10:29.440 So yeah, a mention of public prefix. 10:31.280 --> 10:34.000 You're going to also know, IPv6 on a private prefix, 10:34.000 --> 10:36.560 can I basically have the same as we have in IPv4, 10:36.560 --> 10:42.320 and RFC-1918, that means that you need some sort of 10:42.320 --> 10:44.720 not those some sort of proxy or something, 10:44.720 --> 10:47.520 to, like, outside of your network, 10:48.640 --> 10:51.840 but it brings a lot of going into the details. 10:53.200 --> 10:55.680 To talk public prefix, basically, 10:55.680 --> 10:58.800 you need to get the public prefix from your ISP, your private provider, 10:58.800 --> 11:03.120 or some sort of, have a prefix, or a locator to you. 11:03.520 --> 11:07.520 And then we divide that prefix up into multiple smaller prefix x, 11:07.520 --> 11:11.520 and then we will allow the locator to configure it in the Kubernetes. 11:13.520 --> 11:17.520 And then we need to route subnet to the nodes using BGP, 11:19.520 --> 11:21.520 most of the CNI support it. 11:22.800 --> 11:26.960 And there's a error, because I'm going to issue the security open by default. 11:28.320 --> 11:32.960 So if you just deploy a coupon cluster with a public app, 11:33.040 --> 11:36.320 with six prefix x, and we have no fervor between all the ports 11:36.320 --> 11:39.360 have direct connectivity to internet portways. 11:40.000 --> 11:42.560 So you can, I have someone from the internet 11:42.560 --> 11:46.720 talk to a port without anything between them. 11:46.720 --> 11:49.680 So you need to have some fervores or something between there as well. 11:51.600 --> 11:52.720 We've got a private prefix. 11:55.760 --> 11:58.880 I mentioned here, we sort of, as well, isolated clusters between, 11:58.880 --> 12:01.600 that we don't need to have some BGP supports. 12:01.600 --> 12:04.960 If I have a home lab, it can be difficult to have BGP support 12:04.960 --> 12:11.360 on a home router perhaps, so you can do run a private prefix. 12:12.560 --> 12:16.560 It can use the disk use of the uniquely local addresses, 12:18.160 --> 12:20.400 like everything I've done it to not be before. 12:23.280 --> 12:26.400 But that means that we need to use not, or process, 12:26.400 --> 12:28.080 or something like that, so it's their own access. 12:29.040 --> 12:31.040 So then they will do the stuck in Kubernetes. 12:32.320 --> 12:35.680 This is not just on the different components, 12:35.680 --> 12:38.320 they can plug cube on the deploy cluster. 12:39.360 --> 12:45.440 Yes, they find prefixes to the APS server and controller and proxy. 12:46.320 --> 12:50.080 And it should be supported underneath CNI support. 12:51.120 --> 12:56.960 And CNI is just standard for how container networking in Kubernetes works. 12:57.920 --> 13:00.720 So they find software to get an IP address and connectivity. 13:01.520 --> 13:06.160 Also, we see what IPv6 features are available. 13:07.920 --> 13:17.520 I'm using CNI, with EBP support, or based on EBP F. 13:18.400 --> 13:20.800 The support IPv6 only and the stack clusters, 13:21.600 --> 13:25.680 the new IPv6 are load balancing, provide. 13:26.720 --> 13:29.520 So I have a tool called Hubbell that provide flow of visibility, 13:29.520 --> 13:35.680 so you can see IPv6 traffic are going in in internally and outside of it, cluster. 13:38.880 --> 13:40.640 So I'm doing stack monitor services. 13:41.920 --> 13:45.840 You can basically as mentioned, we can basically define newompos servers to be 13:46.000 --> 13:47.680 single stack, or pure stack. 13:49.440 --> 13:51.120 CNI can't go into the details, so that's all. 13:52.800 --> 13:55.840 So yeah, and as you talk, perhaps, 13:55.840 --> 13:57.840 it's IPv6 only. 13:57.840 --> 14:01.440 I've been running it for all islands from the cluster, 14:01.440 --> 14:05.840 and it works if it removes IPv4 at all. 14:05.840 --> 14:07.040 It's quite good. 14:07.920 --> 14:10.480 Removing nothing, if you're on a public prefix, 14:10.480 --> 14:13.280 so that it's already about anything there. 14:14.080 --> 14:16.640 Each port gets a globally unique IP, 14:16.640 --> 14:18.720 so if you have a lack of input clusters, 14:18.720 --> 14:23.360 you can pair them without any worries that the IDRs and IP overlap. 14:24.480 --> 14:28.240 And we have an connectivity that's out and it's translation layers. 14:30.080 --> 14:36.160 So IPv6 services, enabling it in Selium is just something that 14:36.160 --> 14:39.120 exists in enable to true, when I before enable to pause. 14:40.080 --> 14:47.200 And you set the IPv6 under the multiple IPv6 and you can get started. 14:47.200 --> 14:48.320 It's simple as that. 14:49.920 --> 14:55.520 I have a small, I can install it using KKS and Selium. 14:55.520 --> 14:59.600 I don't have to publish the slides after all, so we can get it in there. 15:00.880 --> 15:04.320 This is basically using nothing on that IPv6. 15:04.320 --> 15:07.840 You can run it on laptop or it can have a small VM, 15:08.080 --> 15:08.960 without any worries. 15:11.360 --> 15:23.120 Kind of small, I guess, but you can see that each port here has some IPv6 address on 15:23.120 --> 15:26.320 or the services system of the six address. 15:29.520 --> 15:31.120 Then talking to IPv6, 15:31.120 --> 15:35.680 before only there is this, as we mentioned, like services like GitHub, 15:35.680 --> 15:36.960 doesn't support IPv6. 15:38.560 --> 15:44.720 So you feel like you're just going to talk to things like GitHub. 15:44.720 --> 15:47.120 You need to have some sort of layer between. 15:47.920 --> 15:52.320 It can be a bad proxy like screen, or it can be a register like hardware, 15:52.320 --> 15:56.400 that can be put to the cache, or it can be something called a 6-4. 15:57.120 --> 15:59.760 This is better, nothing can trigger. 15:59.840 --> 16:02.080 It got pretty complete, but at least, 16:03.920 --> 16:12.880 and that basically means that you can have a client on IPv6 only talk to IPv4 services. 16:17.440 --> 16:20.640 Doing it in production, like I've been like the small startup, 16:20.640 --> 16:23.840 where there was like to do it and everyone is happy, 16:24.560 --> 16:28.720 we have a larger enterprise, so there's a lot of the first, 16:28.720 --> 16:32.240 and getting the first of all in a session of work can be a lot of the work, 16:32.240 --> 16:34.480 because people are preferring to see other IPv4. 16:35.120 --> 16:36.960 They don't let it down, they don't like it. 16:38.160 --> 16:41.440 For them, it's new and complex, and they don't see the mini-meat for it, 16:43.440 --> 16:48.480 especially large, and enterprises have a big pool of IPv4, 16:48.480 --> 16:51.280 or the first, like they don't see the needle at all. 16:54.240 --> 16:57.120 Many apps and libraries use a Zoom scenario before address, 16:57.120 --> 17:01.840 so it's like, it crashes when it starts up because it doesn't find them up before address, 17:01.840 --> 17:06.240 kind of, come in to see, and then it services, 17:06.240 --> 17:10.320 especially in the cloud providers, like some of them own a support IPv4, 17:10.320 --> 17:15.840 so you can stack again, and a lot of tooling like behind an IPv6 support 17:15.840 --> 17:19.680 it won't support IPv4, and there's a lot of issues like that. 17:19.760 --> 17:23.600 So yeah, we thought, I don't think I'm done, 17:23.600 --> 17:26.800 if there's any questions, I have a few minutes left, I think. 17:37.680 --> 17:38.480 Anyone? 17:39.440 --> 17:40.240 Thank you. 17:48.800 --> 17:53.520 You shared on a previous slide that you suggested using a slash 60, 17:53.520 --> 17:58.400 prefix, and then that would allow you to have 16 apps with the next sample, 17:58.400 --> 18:02.560 but yeah, okay, my question is going to be, how would you feel, 18:02.560 --> 18:06.480 and don't shoot me for asking, if you use something small, 18:06.480 --> 18:10.560 slash 64 for a node, if you've got one service running, 18:10.560 --> 18:12.000 I don't think it's going to be any issue. 18:12.000 --> 18:15.360 I'd go for something with the Docker documentation, 18:15.360 --> 18:17.760 you used to say, use a slash 86. 18:17.760 --> 18:21.280 Yeah, the IPv6 support kind of won't 18:21.280 --> 18:25.280 support the network, go smaller on a slash 64, 18:25.280 --> 18:28.880 that's like, so I love this a lot of this discussion around it, 18:28.880 --> 18:34.000 doesn't mention also on a slash 64, it's mostly seen as like one public, 18:34.080 --> 18:38.080 I prefer a rest in terms of like things like a writing, 18:38.080 --> 18:40.320 limiting, and that's one of the things. 18:40.320 --> 18:42.080 There's also done if it's having something to hold, 18:42.080 --> 18:47.120 but you can go smaller, there's no issues, you can go smaller. 18:47.120 --> 18:50.640 Another example is also, say, that you should go smaller, 18:50.640 --> 18:55.520 this is just the way I deployed a cluster error, but yeah. 18:57.360 --> 19:01.520 And a slash 60, like my seems like a lot of IP addresses, 19:01.520 --> 19:03.920 if you have like a slash 29 as an enterprise, 19:03.920 --> 19:07.840 you have like billions of like six or six this. 19:07.840 --> 19:10.400 So you can go way, way, way, be your experience without the 19:10.400 --> 19:13.600 and not using it in your network address space. 19:17.600 --> 19:18.320 Don't know where they're. 19:18.320 --> 19:32.640 So thank you for your thought. 19:32.640 --> 19:36.480 A very naive question, maybe. 19:36.480 --> 19:43.360 Although I do like IP version 4, I prefer it to IP version, 19:43.360 --> 19:47.920 sorry, IP version 6, before IP version 4. 19:48.000 --> 19:51.440 And normally if you have operating Kubernetes class, 19:51.440 --> 19:54.240 you put a low balance and front of it. 19:54.240 --> 19:58.160 So you normally not directly accessing the notes or the pots. 19:58.160 --> 20:04.000 So besides being modern, what is actually the benefits? 20:04.000 --> 20:09.520 Because in for IP version 4, I still have, 20:09.520 --> 20:14.560 I still have like with a tens slash 8, I have an alpha IP addresses for my pots, 20:15.520 --> 20:20.320 and to be honest, there's like there's no, 20:20.320 --> 20:24.080 we shouldn't go and change all the clusters, that is only it today. 20:24.080 --> 20:28.480 And you just like I mentioned, I just want to complex it in. 20:28.480 --> 20:32.960 So running the stack clusters might not be benefit for because they're 20:32.960 --> 20:34.640 basically none. 20:34.640 --> 20:38.480 And I didn't mention like how do we get sounds in the cluster, 20:38.480 --> 20:42.320 because there's no low balance or support boats at an or CBN, 20:42.320 --> 20:44.640 that is from the support posts, both stacks. 20:46.320 --> 20:50.720 But all of the benefits I've seen, if I did have to cluster, 20:50.720 --> 20:55.600 and I have bring two clusters together. 20:57.040 --> 20:59.200 And they were running the same IP space. 21:00.240 --> 21:01.840 That really fixed the learning. 21:01.840 --> 21:06.320 And IP-6 cluster, mostly, if for an at least different public, 21:06.320 --> 21:09.120 you are guaranteed that you put this in it. 21:09.280 --> 21:13.520 So for example, if you do a wire god mash, 21:13.520 --> 21:15.760 we see a bit between two Kubernetes addresses, 21:15.760 --> 21:18.720 you don't have the issue of de-caching IP range, 21:18.720 --> 21:20.000 which is depending on yes. 21:20.000 --> 21:20.400 Yes. 21:20.400 --> 21:23.840 Okay, okay, this is something I understand. 21:23.840 --> 21:25.600 Okay, and there you also have the benefit, 21:25.600 --> 21:30.400 you don't have not on these two IP-6 other services. 21:31.200 --> 21:35.120 But yeah, we can do one more question real quick, 21:35.120 --> 21:38.720 but can the next speaker please show up at the front? 21:40.080 --> 21:43.520 Thank you, and so two quick questions. 21:43.520 --> 21:48.320 One of them, so you talked about the routing for 21:48.320 --> 21:50.720 Delicate while showing the prefix at the pods. 21:50.720 --> 21:55.120 Have you investigated whether you can use the HPV6PD 21:55.120 --> 21:58.480 to automate that so you don't have to fath with manually setting routes? 22:00.080 --> 22:03.440 I haven't invested enough, but on the various new thing being, 22:03.440 --> 22:06.720 if they go to get the payload or within the nodes, 22:07.680 --> 22:10.320 so if I notice I'll start with this year, 22:10.320 --> 22:13.920 and all of them are advertising your prefix, 22:13.920 --> 22:18.160 but they haven't invested enough so using the HPV6PD on this. 22:18.160 --> 22:19.840 I don't know. 22:19.840 --> 22:21.360 And the other one was you made mentioned, 22:21.360 --> 22:26.400 met six, six, why when it shouldn't be used at all? 22:29.040 --> 22:32.400 If you're there, it's like, because you have to route the prefix 22:32.400 --> 22:34.800 into nodes somehow, using something like, 22:35.120 --> 22:40.720 using each HPV, and then if you don't have that support, 22:40.720 --> 22:43.440 it's like on your new laptop, you don't have to run, 22:43.440 --> 22:48.240 just don't know if it's there, we have a public prefix on your own. 22:48.240 --> 22:49.760 So using them directly, not six, six. 22:51.120 --> 22:52.400 Yeah, I guess. 22:54.400 --> 22:56.560 Sorry for the rush, thank you very much everyone. 22:58.400 --> 22:58.960 Thank you.