 put all the background material into their heads. Oh, two days, three hours, or two minutes. This is going to be a problem to cover this area in 20 minutes without you having all the background. But I'll do my best. IPv6, simple, beautiful. If you connect to the FOSTA network, you run IPv6 only. You're happy. Things work mostly. But more things work this year than last year. But this is fairly simple. If you move your stuff and you port it to IPv6, both server and client, things will just work. It's just more bits on the IP packets, DNS, TCP, UDP, everything works like before. No problems. This was the world we saw in the mid-'90s when we said that, well, IPv4 is dying so fast, so it's going to be gone before year 2000. No. But at FOSTA, at least, it's gone. So I'm not going to spend much time on this. You all know IPv6, right? You all use IPv6 networks, right? Cool. This is where we get into trouble. We have two stacks. We have the old legacy dying, creepy, scary, insecure IPv4 network, and we have the IPv6 network. And we end up in situations where the client wants to connect to a server and suddenly have the choice of two different paths. We have two different protocols bringing us from point A to point B. This is like putting my wife behind the wheel and trying to explain, you can go this way and that way, and she's going to block and like, what? And then I'm not saying, go that way. We did that in the RCCs. We said, go IPv6. If you have IPv6, IPv4, go IPv6. This turned into a problem. Microsoft have done a lot of good things with IPv6. They actually, in Windows released, enable IPv6 for every single computer through automatic tunnels. So your Windows desktop believed it had IPv6. Firewall blocked it. Sites that actually published IPv6 DNS records for the same hostname got into trouble because the browser said, Google's not reachable. Facebook not reachable, which wasn't very good for marketing, didn't help the brands when everyone thought the servers was down. So they immediately disabled IPv6, which is not what we wanted. The solution to all of this is happy eyeballs. In the ITF, we created a standard specification saying, you should not start with IPv6 and then when you fail, move to IPv4. You should connect to both. IPv6 could give it a few milliseconds head start, right? But connect to both, mostly at the same time. And the first that responds, you keep that connection close to other one and you'll be happy. The users will be happy. The marketing people will happy. And we can safely migrate to IPv6. So the browser vendors, they implemented all of this. On June 6th, a few years ago, we tested live on the internet. Facebook, Microsoft, Google, everyone turned on IPv6 on the same host names and nothing happened. All browsing succeeded. Everyone was happy in their eyes. Marketing people was happy and we had IPv6 back in DNS. Happy eyeballs, connecting at the same time, not doing it serially. And continuing on the session that opened first. That's great. Well, on mobile phones, I frequently see that we have multiple interfaces. So now we have IPv4 and possibly IPv6 on the mobile cell phone network. And then we have Wi-Fi, whoo, should we set up four connections? 10, where's the limit? I have devices with four SIM cards and Wi-Fi. So the new world is giving us problems. And what happens, what we see is that on mobile networks that I add IPv6, the IPv4 network is suddenly behind a net, a carrier-grade, professional, high-end, cool net. Not the small-end family, home-rooter stuff you have at home. This is a professional carrier-grade net, which makes it no fucking better. You're right. Real-time protocols and that doesn't love each other. But that's not the end of it. They have session management on the network. They're adding a lot of boxes to manage stuff, to make your experience better, which practically kills everything you want to do real-time because to make things better, they close down IP flows to give room for new IP flows, to make new users happy. So your concurrent session in the background to your XMP server, go, your web socket, crash, burn. No fun at all. So we see that the IPv4 network is quickly dying. We have cell phones in production use in the national public radio where I spend a lot of time these days. We're moving heavily towards IPv6, which gives us a very clear path for the live broadcast audio directly from that device to our studio. The IPv4 network, everyone complains. But what we see with these mobile apps is that networks come and go. Suddenly the network you're using and you're having so much fun with, wow, it disappears. But another one, yet showed up. That wasn't really bad. Going back, this is making life really, really hard to have live, real-time connections, bi-directional. So happy eyeballs, well, that's the start. But we really need to focus on this in SIP. We need to have session resumption like the previous speaker talked about with XMPP. We need to be able to move our sessions in multimedia. That's called eyes. There's some cool stuff in eyes, Sal mentioned it. But of course, the internet is leaving IP. We're moving everything on top of HTTP, right? And that's all the problem with happy eyeballs. Everything is good and dandy and we're getting the new versions. Everything is sexy. One protocol for us all. For those of you who doesn't believe that religion, we still have good old SIP. What about VoIP, right? So the browser vendors sold us years ago. The SIP vendors sold us, moving to the next slide. XMPP, while TCP based have the same problems as HTTP. Haven't seen any discussion about solving this. I hope they cleaned up their own mess. Oh, where about to see? In the core spec says, we're dual stack. How many have tested that? And in some specs, I ask, oh, what about IPv6 or dual stack? We'll take that later. Okay, when? RC3261, which is 140 pages of fun, stated early SIP works with both IPv4 and IPv6. So we should be good, right? I mean, come on, this was in 2002. Camelio supports IPv6 from day one in our code. Staying happy. Do we have a problem in SIP? Tested it at SIPP. I've been testing numerous times. We have issues with finding the best media path but there are standards. Setting up a connection to signaling. Try happy eyeballs over UDP fellows. Give a solution to that. Finding the quickest connection where we have a connection less protocol. Ooh. Setting up the best connection between users. So this is rather fun. I ended up with this conclusion. Yeah, we do have a problem. Someone is gonna fix it. Oops, someone is me. Hey, join me in fixing this. Oops, guess not. So I started writing some ITF documents. I got actually a few people on board helping you write those and getting it through the whole process. So we have one RC now and we have two more drafts coming on how to fix this in SIP. What we discovered while testing was that IPv4 devices with single stacks crashed and burned because in SIP we have IP addresses everywhere in the messages and we injected IPv6 addresses here and there and their software burned. So even if you're not porting your software to IPv6 you need to watch out when you have these protocols because we're sending addresses inside. Also, when I said in my DNS that, hey, I prefer if you connect to me over IPv6 in my SRV records, the first priority was IPv6 only. The second was IPv4 and IPv6. Many implementations crashed and burned because they couldn't really understand that first priority and they didn't understand that they should fail over to the second priority. And that's covered in the RFC. You're all going home to read that I actually wrote. So crashes, no connections, that's fun. Yeah. For media, we have eyes and eyes have IPv6 additions. You have dual stacks. And the default role is if you're IPv6 only you have to help those poor, poor, poor pieces of code out there that doesn't support this by going to a turn server and applying for one of these IPv4 legacy addresses. So you have to help others. Have I seen this in WebRTC? No. The biggest problem I had was in one of the core RFCs that was a little over. So people came to me and said, well, the RFC says I should ask for IPv4 or IPv6 and ask for one. Five years of fighting the war and changing that to an and, but we did it. We changed that RFC. So where are we? SIP, one RFC published, one SIP forum document, ITF drafts in process. We're making progress, progress. XMPP, I have the same happy eyeballs problems. I haven't seen any, don't need any RFCs but the implementations need to test. I haven't seen that. WebRTC should work. Sounds promising, right? Yeah, we have work to do. And I believe there are many, many other protocols out there that have this problem but people haven't really tested, haven't considered the impact of dual stack fully. I think in SIP we're actually way ahead of a lot of protocols. So you may ask yourself, is this for real? Yes. Many mobile carriers around the globe started in the US but actually now in Sweden as well our carrier in the radio added IPv6. We have dual stacks in all our office mobile phones. So everything's journalists out there, dual stack. So that's cool. At the same time they actually added a carrier grad NAT and every week they keep modifying the session timers for that NAT, which is fun because then I have to modify the KIPA lives in my Kamilu server, which keeps me busy. So they're adjusting their stuff. They don't want to occupy, as more people get on board with this dual stack server the carrier grad NAT allocates memory for all the sessions and they don't want to keep them in memory. So they went down from five minutes to three minutes and now recently to one minute. And they also have a session limitation. We haven't found that and they don't want to tell us but they have confirmed they have a limitation on the number of concurrent IPv4 sessions and they're properly adjusting that as well. So this is fun. We discovered that we have those little access points connecting to cell data. They still run NAT even though the network runs NAT. So in those cases, if we use IPv4 we have dual NATs. What can be better than a single NAT? Yeah, two NATs in the same session. We're happy. And that little mobile pack, by the way, had a SIP helper application, an application level gateway that Iñaki so loves. So removing everything, all the media to IPv6 as fast as we can. So we're really pushing our vendors and that's the tough problem. They are not ready for this. Oh, we tested IPv6 in our lab and it works. Okay, have you tested this, this, this? Oh, I wasn't aware of that. Thanks God I can point to ITF documents and real stuff in the SIP forum. Not just being me, even though I wrote them. Open source, Camille, you have issues with this. Asterisk has issues, free switch, most likely I have not sold this. And the same thing I think goes for a lot of these. We need to solve the happy eyeballs problems and I need you guys to help me with UDP because that's the missing draft. You're drafted, right? It's getting painful because this is in production. It's now, really. It exists in a lot of products. We have a lot of theories. Move to TCP and you can do happy eyeballs. Fix the eye stuff and you're ready. You also need to look because a lot of your applications, even though they're SIP, WebRTCX and PP, they use HTTP or LDAP or something else. All of these TCP connection protocols, they will have happy eyeballs problems as soon as you add IPv6 to the DNS entry. So this is now, build a testbed, fix your applications. Thank you. Oh, I see questions. What's your SC number? I can look you up and read it. Sal, my assistant will find it soon. I think 7948. I should have it engraved here. Proud author of. Yeah, so last year, thank to Apple, PgC, for pushing to IPv6 and everything, everyone was scared of getting kicked off the app store, right? One of the things I didn't mention is, not the worst, I was single stack even, IPv6 to those camellias or whatever doing IPv4 only. And they have not 64-bit support to solve everything. And then obviously it fails HTTP and all that sort of stuff. And I think, is there any way to comment on the IPv6 to IPv4 or? To be honest, I haven't started testing that because I've been so fully occupied with this. We said at the last snippet where PgSIP was actually involved, we said that we need to install NAT64 in our town. This has been so painful, so it's been enough. But you're right, we probably need to look into that as well. Especially with DNSSEC and other things, NAT64 can be interesting. More questions? We got two more minutes, so. You're happy, you're going to read all the documentation, the AI downloaded. We are all happy eyeballs. You're happy eyeballs. Stay in this room and the rest of the documentation will be downloaded at five o'clock or something into your extra memory. Thank you. In two days' time. Great, that's pretty usual. Thank you. Thanks, Ali. You're welcome. Yeah, it made me think about certain things and how we should do connects and HTTP as well. We should preferably publish both addresses. And Jingle has the same set of problems as we have with media. I mean, since you're lucky enough to have TCP, I mean, then you can do the happy eyeballs. And I'm fortunate enough to live in an environment where most of my peers do IPv6 well or not at all. And my home connection is very reliable with IPv6. So it might be IPv6 by the provider.