 So, hello everybody. Thank you for coming. I did not expect a full room, so thank you very much. I actually do not see an empty seat, which is quite surprising because this talk is supposed to be about teaching people about IPv6. And it's quite worrying that I have to teach this to you. So, thank you so much. I presented this last week at LinuxCon and apparently the guys doing servers aren't as interested in IPv6 as embedded people, and especially on IoT, and I guess that we all understand what the challenges of IoT are. I've been reading research about how many devices we're going to see in the IoT world. Every time I read one, the number increases. So, it started with a couple billion and then it was 10 billion, and then I was reading about 20 billion devices, and then somebody says 40 billion. It's like we're just trying to sell for the highest price. So, the last number I heard was 50 billion devices expected by 2020. So before we get there, let me just present myself. So, my name is Thiago Maciere. I started contributing to Open Source in 1999. It was with a little more advanced technology than that typewriter. That's me in 1982. As you can see from this timeline, IPv6 started getting developed way back when. Some of you might have never lived before IPv6 actually started being developed. I started contributing to Open Source as a matter of coincidence in 1999 when I was applying for internship and the company was applying for said, what do you want to work on? And I searched a couple of things. What could I do? And I decided I'm going to do an IPv6 capable web browser. Mozilla at the time already had IPv6 support in 2000, so I decided to work on the KDE browser at the time, the new browser Conqueror. That led me to become a KDE developer. That led me to work on Qt. That led me to my job at Intel. And then interestingly, led me to IoT and talking about IPv6 all over again. So today I work for the Open Source Technology Center at Intel based out of Portland, Oregon, United States. So let's do a quick check here. We all know that IPv6 exists so that we don't have the problems of IPv4 exhaustion. When is that exhaustion? Does anybody care me to give me a year? Which year should that question mark be? Never? No. Two years ago. Anybody else? 2015? Anybody wants to give a different number? So the actual answer is four years ago, five years ago. 2011 was when the Internet assigned numbers and assigned numbers and assigned, what is it again? Internet assigned numbers authority. Yes. I confused with ICANN which also has a couple of similar names. They ran out of their blocks. So IANA gives the blocks to the registrars, to the local operators, the local, as in one in Europe, one in the United States, one in Latin America, one in Africa, one in Asia. The same year, the Asia one ran out. So they only have the ability to exchange if somebody returns something. Now, they just don't have any more blocks. They're in low contention mode. Latin America went, sorry, the next one was Europe in 2013. Latin America 2014. The United States and Canada and Mexico and Caribbean, so North America mostly, went in 2015. So if you want to get a full block now, you have to go to Africa. That's the only place we have left. And they're expected to exhaust in 2019. So clearly, we have to do IPv6. I'm going to do a brief overview of IPv6. I don't know how many of you do know it. How many of you have an IPv6 connection anywhere? Okay. So how many of you have seen an IPv6 address? Okay. Great. How many of you have programmed for IPv6? Okay. About a third of you. It's encouraging. So just to level off knowledge, all of us, apparently, almost all of us have seen IPv6. It increases the address size. But it's more than that. For example, it brings, let me just point out the presentation will be available online. You can take a picture of me. We're being filmed actually, so you can watch again later. But you don't have to take pictures of the slides because they will be available online. Feel free to if you want to though. Multicasting was made mandatory with IPv6. And IPv4 was optional. There are a number of technologies we've built along the years with v4 today that depend on multicasting. But it wasn't mandatory. So it's possible to have a stack of IPv4 that doesn't have it. In IPv6, it's mandatory. It increases the minimum transmitter unit that each link layer needs to support. Why is that important? It actually means that I have less requirements on the application sending anything to be able to support small packets. So if I'm sending about a kilobyte, so this number was chosen so that if my data, my payload is about a kilobyte with some overhead of an encryption and everything else, it will still fit comfortably. So if I'm sending about a kilobyte of data in my packet, in my datagram, I know that it will arrive. It is required to arrive in terms of fragmentation. It might get lost for other reasons, but it won't get stopped by a router along the way because it can't transmit enough. So like I'm showing here, fragmentation is only done at origin, never by routers along the way. Why is fragmentation important for routers? Now routers have actually, they're simpler because they don't have to do the fragmentation along the way. They can only assume that if it fits, I'll send. If it doesn't fit, I'll send an error back. Privacy extensions were designed from the beginning. It's interesting that the privacy extensions that we know today as IPsec were created for IPv6 and then later added to IPv4. Jumbo packets, it's unlikely we're ever going to use them today, but for the future. IP address, as many of you, as most of you have seen, I'm not going to spend a lot of time on this. We just compress them. The interesting thing then is that the local host and any host addresses are much simpler. So we just have the all-zeros address means any host. It's used for a lot of things in application protocols. It means that any address on my machine can also mean the default route. So zero slash zero means anybody, the default. Whereas the one bit set, the lowest bit set, means local host. So it's actually much easier to write those addresses. The two addresses that you probably ever are going to write in IPv6 are these two. So they made it simpler. The rest, as you saw, aren't so simple. It's technically possible, but nobody does NAT on IPv6. Why? Well, we have so many bits. Might as well use them. So the idea is that in any network that is using IPv6, I'm going to connect with globally routable addresses. Let me just make a distinction. Addressable from anywhere in the world, so a unique IP address does not mean I have to be reachable from anybody in the world. There's such a thing as firewall. So if I have a lot of devices in my room, and we're talking IoT, so imagine every light bulb here has an IP address. It's unique in the world. But do I want people connecting anybody from the world sending packets to the light bulbs? No. That doesn't make sense. We do security anyway. So there's such a thing as the unique local addresses. I'm not going to get too much into this. They're kind of like the RFC 1918 private addresses for V4, except that they're expected that you never use them to connect to the outside world. So I'm not going to spend too much time on this. The interesting thing happened to me here was that on Monday when I arrived at this hotel, I tried to connect to my VPN that connects to my home address. I have IPv6 at home, but that's not the point. Look at what happened. For those of you who can sit here in the front, can see this. Look at what happened with the IP addresses of the hotel's network and my own network at home. It's the same. So I connected to the VPN. For you in the back, trust me, it's the same. What happened was that I connected the VPN and it connects IPv6. So I had my email working. My server has IPv6. I could access Google because Google has IPv6. I'm on Google Plus, so I can access Google Plus as well. But Skype at the bottom was turning the wheel. I said, well, it will connect eventually. It didn't. And I was browsing some other thing that just didn't load. And then I realized a few minutes later that it was because there was a conflict of address of the VPNs. So this is what we need to fix with IPv6. That's broken with V4. We need to fix with IPv6. And interestingly, I was browsing with IPv6 and hadn't noticed the problem. Another interesting thing about IPv6 is the so-called stateless address auto configuration. The way it works is that it enables devices to operate in a network without the need for a DHCP client. More importantly, the server does not need to know who's there. That's what's called stateless. Now, if a router is present, so what happens is that there's a communication between client and router. Who's a router here? The router sends, I'm a router. And in that packet, it includes a couple of extra bits of information, including the prefix. So automatically, I can configure my address. The packet can also contain some information saying, hey, go fetch some information from the DHCP as well. We don't have to ask for an address on the DHCP, but you can get extra information like which domain should I search, which are my Windows SMB servers, network time protocol. So that kind of information does not come on the regular router announcement. It can come from the DHCP. But since you're not actually transacting to get an IP address, it's still stateless. The way it works is that you take the interfaces MAC address. There's a side modification to make it 64-bit. You create the interface identifier by flipping one bit, and then automatically you merge it with the prefixes. So every single device that turns on IPv6, even if it doesn't get a router announcement, will configure an address like this. It's derived from the Ethernet MAC address. Hold your question. I know what you're going to ask. But here, what I want to point out in this slide is I said you get this one whether there's a router in your network or not. The consequence of this is that if I have two IPv6 devices in the same network, they talk to each other, period. I don't need a router. So when I'm developing my IoT devices that are local network, by the way, I'm working on the Open Connectivity Foundation as part of my Intel job, we mostly need local connectivity to other devices in the same network. I get it. I don't need to configure anything. I don't depend on having a DHCP server. I don't need you to do anything. So my tiniest devices automatically can talk to everybody else. The moment that there is a router, I get a prefix from the router and you can see from this slide, where's my mouse? Yeah. That it's actually the same ending of it, right? And now you can ask your question. So it's derived from the MAC address. You probably have a question. Oh, yeah. That's not the question I was expecting, but that's a good question anyway. So the question was what happens with devices that don't have Ethernet? Well, every device has, all the radio technologies, all the communication technologies have some kind of identification, so you can find each other in a network. The example here is given for Ethernet or Wi-Fi that uses this. Bluetooth has MAC addresses as well. Let me give you an example one that doesn't. So you take 15.4, 802.15.4. The address is only 16 bits. So the way that it's going to work, there's a protocol describing how to run IPv6 on top of 802.15.4. It says, well, you're going to do the same thing, right? Except it only has 16 bits and you don't flip this extra bit. Only so that you don't have a bunch of zeros in between. So you're only going to have the ending part of it with meaningful information. It becomes interesting because now I know even if I have addresses, if I know my prefixes, I know how many zeros are in between and I only need to transmit the ending anyway. So that gives us extra header compression possibilities. I'm going to get this at the very end of the presentation. So the question I was expecting you to ask was what happens about my privacy, right? So what happens because now my address actually is trackable, right? Because it's the same thing depending on which network I connected. So this was foreseen a long time ago and the one here on the left Linux has had for, I don't know, time immemorial. It's called a temporary random address. Defined by that RFC, it means that whenever I connect, it randomly generates an IP address for me. It's random, 63 bits of randomness. It needs to flip that bit which you saw before to indicate that it's not based on a MAC address, it's not a permanent address, it's temporary. So 63 bits of randomness every time I connect to a network. So you can't see me anymore. More than that, it actually rotates every 12 hours or it can be configured. So even if I'm connected to the same network for a long time, you can't track me because I'm changing my addresses. It's random. Like I said, this is supported on Linux, has been for a long time. Network manager defaults to it if I'm not mistaken. If you just turn it on. There's another functionality which is the one on the right which is a stable but opaque. Let me explain. It means that often when I'm connected to a network, I acquire resources on that network. So I need other devices to find me. But I don't want you to know that I'm me if I go to another network. So what it does is that it has a pseudo random function that is any could be any but it just describes one in the RFC that is based on the SSID for example of the network you connected to, a secret that you have locally and some other information. You match those together, you get again 63 bits of pseudo random now. You still contract me across different networks. But if I connect to the same network, I get the same IP address again. And that allows me to restore my resources that I had before. As an example, suppose that you have a network area storage in your home network. And in that network, in that network, of course, you configured an ACL. Let's suppose the ACL is based on IP address instead of a credential. So you want to be able to restore your address every time you connect to that network, in your home network. But you go to other networks you don't care. You just don't want them to know that you're you. Why is that? Well suppose that we have now different types of devices. If I have my phone in my pocket, I walk into this store and that store, I don't want them to know that I'm me to track that I like these two things, whatever they are. Any questions here? This is important. How does it sustain? What is the network identifier? So the specifically in the RFC, it talks about SSIDs of wireless networks. So you take the SSID, it's usually a fixed thing for any given network. And you can use that. Now you could have different things. On an Ethernet, it might be difficult because you don't have an SSID. You could take, for example, the address of the router in that network. So you send a router request. When you get the router reply, the router announcement, you know which address it is. So you can say, well, this is my network ID and I'll use that as a stable. So it doesn't have to store anything. It could. So a stateful storage network manager could store it. It doesn't have to because as long as it can find again that identifier, this SSID, a router address or whatever, it can recreate the original address. What is done currently in Linux? It does SSIDs. It does nothing for Ethernet. So this thing simply, it will generate the same address for all Ethernet networks. It's coming only. I don't have an M1.2 for example. My machine still has 1.0. I haven't looked into more details. Maybe they'll do something. Now, what is a DHCP for then? Why do I need DHCP for? Now DHCP is used to actually acquire networks, not acquire IP addresses. So routers are expected to do DHCP to other routers. So in my home network, for example, I only have one, but this is an example. You have your inbound, your border router. This is a border between your network and the world. It does a prefix delegation request to your ISP and the ISP gives you as many networks as you requested. In this case here, the slash 62 means I asked for a prefix of 62 bits, that is 4 networks of 64 bits. So this router assigned one network a given prefix and delegated to another router a prefix that it sent again. So I have 3 networks in this particular example. All of them with 64 bits. This is the standard length of the network address now. So I can do what I just showed about charge generation. But I have 3 networks in this particular case. I can tell you I've never actually tried to request from my ISP more than one. They may not support it because I'm a residential customer. But I can get one. So in my home network at home, my router automatically gets a network of IPv6 addresses. So all my devices when they log into my network at home, my Wi-Fi, my Linux laptop, my phone, most of my devices are not all of them. Some of them don't have IPv6. They automatically acquire a globally routable IP address. So the question is, I'm putting it this way, what is the standard prefix length and why am I sitting a lot about 48? Here's the thing. So if you're a residential customer, usually they gave you a 64. So you can do prefix delegation of 64 and up. So this example is doing a prefix delegation of a 62 and a 63. If you go, for example, for your telephone company and say, I want IPv6 connection, by default they'll give you a 48 without prefix delegation. So you don't have the DHCP. It's just a static assignment. So you get 16 bits of networks, 65,536 possible networks of 64 bits each. So that's the standard set in the RFC that says unless the customer asks for more, give them a prefix of 48. So usually this is expected to be the way when you go to your telephone company, your ISP, your higher ISP, you're not a residential customer, and you ask for static assignment because you're going to run servers, for example. You can't have this changing behind the scenes. They'll give you a 48-bit prefix. And then you can assign to different 65,000 networks each of 64-bit lengths. Now I've seen the 56 before. I just don't remember in which scenarios they recommend it. So you see we have 128 bits. Let's use them. So you see that the networks, each network is 64 bits in length. And then you give people 65,000 networks. And that still leaves a lot behind. And interestingly as well, the global internet is three bits, two and three, which means that there's still a lot of internet. So only 12.5% of the possible address space has been assigned. There's still a lot left in case we need to expand. There was a question in the back? So I'm going to repeat the joke. Somebody said the same thing about four billion addresses. But you see the world population is seven billion. If we try to assign all the IPv6 addresses to the entire planet, including water surface, I think the number is something like 500 trillion addresses per square centimeter. I believe we've got enough time to figure out the next one if you need to. Now your serious question was, do I really get 64-bit prefixes in my whole network? Yes, you do. This is the standard length for anything that is not point-to-point. So if you establish a PPP connection, it's point-to-point, you get one. But usually that comes with also a prefix delegation for whatever you might have behind you. So the reason for that is that we don't want you to have 18 quadrillion addresses, devices in your network. It's more than that. It's quintillion. Two to the 64. Your network is going to break down if you have that many. The reason for having this many addresses is really the ability to use them with stateless. The number of collisions is very small and to be able to do randomness. So the 64-bit is for that. You don't need two to the 64 devices in your network. You got it? Oh, good question. What happens with collisions because they might happen? So IPv6 is designed around the moment that the device comes up. It does what's called the duplicate address detection. So it assumes it's going to get the address, sends a packet to the link-layer resolution saying, who's got this address? And waits about three seconds. If nobody replies, it assumes there's nobody else. Because if there is somebody, it will just try something different. In the random case, it's easy. I'll just regenerate it. With the stable one, what it will do is it has a nonce. It increments the nonce from one to two. Reduce the shall one, for example, and then it's completely different. And then it restarts duplicate address detection. This is on Wi-Fi and Ethernet. When you have low power networks, for example, they designed duplicate address detection differently. So usually on low power networks, a mesh, you register yourself with a router. And the moment that you do the right, a router tells you, oh, no, somebody else has it already. So find something different. So they change the duplicate address so that detection, so that you can actually do it and avoid duplication. That, of course, requires cooperation. So you still can have malicious devices trying to hijack. That's a different story. I'm going to briefly talk about the casts. So Unicast is the one we all know. It is one to one. It's what we have had since timing memorial in the internet. My sender here, the blue one, is trying to reach the green one. It sends to its address. The multicast, most of you have probably heard about, it is one to many in the sense of I want to reach all in a group. Where is this used? The example is what we're doing with the Open Connectivity Foundation. I want to find all my toasters. So I send to everybody in that group that contains all the toasters and ask, who's a toaster here? Ideally, we would have a group of only toasters. But the thing is that usually those queries are slightly more complex as in, list me all the toasters that are in the kitchen. And you could do a couple of interesting things. Remember how many bits we have there? We can actually do bloom filters inside the IP address. That would be interesting. The other example, this is something that appeared only in IPv6. It's called the Elicast. It's one to any. As in, I want to reach any of you. It doesn't matter which one. Usually the one that you find this most commonly is routers and DNS servers. So the router address, there's a defined address for all the anycast routers in a network, which is the one that contains all zeros in a network. So if I want to find a router and didn't receive the router advertisement, what I can do is simply send to that address and hopefully it arrives. It's not very much widely used. Okay, so let's talk about programming. Any questions in the previous section? So that's a very good question. So you're telling me that one of the advantages of having to be behind an app is that I can actually reach the server I have in my network because the address doesn't change. Right, because it's one of those RFC 1918 addresses. Now, if all my devices have IPv6 globally routable addresses and I move or my ISP changes my prefix, then all of them changed. How can I reach them again? This is the thing I didn't mention. It's the unique local address. Actually, I might have an example of it. Give me one second. No, where is my shell? Here we go. It went somewhere. Yeah, here. Oh, we had it. Here we just minimize this thing. Here we go. So when I connected to the network, here's when I had connected to my home network. Let me even increase the font size. So you see the IPv4 I got. This was my globally routable address I got via my ISP there. Notice this one here, right? So this one looks different. So this is my unique local prefix in my network at home. So there's an RFC, I don't remember which one now, that incentivizes all the routers in our house or at least one router to establish a unique local address. That one stays permanent inside my house. If I move or my ISP changes my prefix, that one doesn't. So I can still do local services in my network with a stable addressing even if I'm getting renumbered outside. So yeah, so the way this works is there's these, so these eight bits, the first eight bits of the address are reserved for unique local addresses. The next 40 bits are random. So you select it. When you install your router, it automatically generates one for you. So OpenWRT does it. It automatically generates those 40 bits of addresses of randomness. And then you have the 16 bits of the network. So remember, this was a 48-bit prefix. My home network, I only have one. So I got a zero here, right? And then this address is probably the same one as this. This is a PPP connection, so that's why it's weird. So yeah, so this one is based on the MAC address. Right, look at that. This one here is the random one, which is repeated on both prefixes. Yes, yes. So as you can see in this example, my net, my this interface here has one, two, three, four, five IPv6 addresses plus the IPv4 one. When I'm at home, it actually has a sixth one, which it obtains via DHCP. It should have another one, but the DHCP client is actually broken on Linux. DHCP client is broken. Anyway, let me just restore this and go back to the presentation. Where's the presentation? Here. So what I wanted, that actually leads me to the next topic, which was I needed to see here. So there is more than one IP address on your device, even on each interface. One of the biggest programming mistakes you can make is to assume there's only one. If you design your application, if you design your protocol based on there's only one, it's pretty much stable as long as my application is running, you're wrong. You can't do this. You have to assume that you have more than one, so your API has to do that, your protocol has to do that, and you have to assume it changes. Now, of course, TCP connections need to have an endpoint. So what it does is that when it's time to change to a new one, it marks that as obsolete, it will still receive the packets, but it will start sending with a new address. So actually, that's the next slide. I'm talking to the wrong slide. So don't assume anything about the address. Please use high-level API as much as you can. Don't try to use the low-level. And use the IPv6 API as much as you can because of dual stack. So this is the slide I want you to know when you're developing. So let's talk about the bad assumptions. First one, obvious. Do not assume that it's an int32 because it's not. So a lot of old code assumes that it can store an IP address in just 32 bits. That needs to go. The other one was what I just mentioned, which is don't assume that there's only one meaningful assigned address to each device. There's no such thing. As you saw in my example, I had one IPv4, five IPv6, and usually my network actually had six and should have been seven. And that's not assuming if I'm connected 12 hours, it will actually rotate the random ones, so it's a lot more. So your application needs to be able to deal with that. Assume that they are able to change. And the other thing is stop using if config, please. The correct tool for this is the IP from the IP route package. Another mistake is to assume something about the address itself. Let's look at the example of a URL. A URL is a scheme, host, port, path, query, and fragment, right, with a couple of dividers. So the column double slash, the column, the first slash, the question mark, and the hash mark. Now, I'm constructing this URL with HTTP. There's my host name, and port 80 and path slash. Does anybody see a problem? They have too many columns. This will not pass. The correct way is this. There's an extra set of brackets that you add to the URL. Now, most URL APIs know how to construct this, so don't try to construct it by hand. Please don't write the code that constructs it by hand. Use libraries as much as possible. I'm just using this as an example. So how do I store an IP address, right? So instead of storing in a UN32, just use the structures that we have from the operating system, right? So there is the internet socket address. This is the usual one from IPv4. There is the IPv6 one over there. And if you just want to put everything in a union, you use this guy here called storage for a good reason. It's big enough to hold IPv4 and IPv6, and UNIX sockets. So you put this one in a union, you cast it as necessary. You use the first field, which is the family. My mouse went away. Where's my mouse? Here we go. The family, and the family will tell you which one it is. So it's basically meant to be used variably. Resolving an address couldn't actually be simpler with IPv6. With IPv4, you get host by name. Who has used get other info? Yeah? I need more of you to do that. Thank you for doing so. But the way it works is that it's actually a very nice API. For those of you in the back who can't see it, I even don't know the HTTP port. I just put HTTP here. It will find it for me that it's port 80. This is a simple example. You can look it up when you get the application from the presentation. What it is doing is that it initializes a couple of information from to pet hotel, get other info, get other info. One of them is this interesting one called address configuration, which tells get other info, don't bother looking up IPv6 if my machine doesn't have IPv6. So if you're in the current scenario where most configurations don't have it, it doesn't even look up. There's one problem I just recently found out. If you're writing a network of demons, something that starts very early, and if you don't have any IP address yet because your application started early, this thing returns empty. So you have to be careful there. And it can do for both connecting out and receiving sockets in. So let's look at the example of what you do to the reverse of it. So this example before it just called a random function that took the address info. What this is doing is doing the reverse and printing it. So get, it's actually not doing a reverse lookup. It just says, give me the string representation of it. So I never actually have to parse IPv6 or v4 or whatever they're going to come up with the future. And it printed. I ran this example on chat.freenode.net and it listed a lot of things. I ran it on came.net, which is the BSD stack for IPv6. Unfortunately, you're not going to be able to see it from here, but trust me, when you see, when I say that the order when I ran this on the hotel network and when I ran it with my VPN on is different. One of them had IPv6 first, the other had IPv4 first. Why is that? It's because on one of the networks, I do have a globally routed IP address. So I should connect the IPv6. If I don't have it, then you're supposed to follow this order. So when you're using the API as I'm describing, you take all of this. If you're connecting to free node, for example, you're going to try all of the IPv4 addresses before you get to IPv6 if you don't have IPv6 addresses. If you do have IPv6 addresses, it's reversed and you try IPv6 first. More than that, the spec that controls this also asks for ordering according to regions. So if I have an European IPv6 address, it will list first the European box. How do I connect out socket and connect, right? Here's the interesting thing. All I need to do is already there in the structure I got from a get address info. I don't need to remember that it is AFI NAT or AFI 96 and then SOC stream. What is the third parameter again of socket? That was SOC stream. So what's the third one? It is the protocol. So what should I pass there to get TCP connection? IP protocol or zero. So I don't care. This is just, right? It's already in the structure for me. You remembered. I guess most of you guys, the rest didn't. I'm going to connect again. It's all there. Right? And same thing for receiving connections. It's already there. An interesting thing is that if you're going to write a server, do it in IPv6 because you turn on this feature called IPv6 v6 only. You turn it off, sorry. You turn off the only. You receive connections from IPv4. They just look slightly different. So this is an IPv6 address called v4 mapped. So you get an incoming connection from this type of address. So your client is IPv4. Your server is v6 and doesn't care. So please, please write IPv6 servers as most as you can. Just be careful with one detail. ACLs and white lists and black lists, you need to be able to match this properly. So if you have, for example, an ACL saying allow this or disallow a certain range, make sure that they match the v6 with container v4 mapped address. What's their question? So do you want to buy one v4 and one v6? You can choose. So if your application is able to listen on multiple sockets and still work, one way to do this is to turn on the v6 only and bind a socket on v4, one on v6. You might want to do this if you want to bind to specific interface or specific addresses. The thing is that many applications are not designed that way. They can open one socket to receive. If they do that, this feature, the dual stack here, allows you to receive from anybody. So you're not wrong. It's just that there are two ways. In your case, you probably are not subject to the problem of the ACL that I just mentioned because you're going to be receiving IPv4 via the v4 socket. Oh, I see what you mean. You want to bind to loopback only. Bind to the IPv6 loopback on v6 dual stack. I believe it's possible. Let me just understand afterwards with you. I believe there's a way. Okay. So since we're running more or less out of time, I'm just going to go briefly over a couple of things you can do only with IPv6. So like I said, you can do real addresses for your entire network. Well, now we are IoT here. Guys, we need to be able to have a lot of devices connected. Think of this way. How many devices are you going to have on a smart home as an example? 50, 100, 200 devices in a couple of years. On IPv4, think of your router at home. Think of the configuration page of IPv4. What is the range of DHCP that it usually comes pre-configured with? 50 to 100? So think about it this. We're going to have a problem with IPv4 and IoT in your home networks within three years. These devices need to be IPv6. For big companies, how many of you have done trace route over the internet and got private addresses along the way from your ISP? Because they're out of it, now you can have globally routable addresses for all the network elements. Just don't forget your firewall rules, please. It's IP6 tables, not IP tables, or the new one NF tables. Replace your broadcast with multicast. Broadcast is interesting in IPv4, but it sends to everybody. So you connect to the Wi-Fi here and you're getting Windows network announcements. This is not a Windows machine. I don't even have Samba running, but I'm getting the darn thing, because it's a broadcast. So use multicast, not broadcast. And use it on IPv4 if you have to design it as well. The interesting ones we need to talk about the variable scope here is link local. So don't route this. And realm local for IoT is important because that's what a mesh network is going to use. So it's not the radio link, but the mesh is a realm. There is a couple of extra APIs I'm not going to go over into. You can read the RFC. The Linux API is a copy and paste from the RFC. It allows you to get extra information from your packet. So as an example, which interface it came on, or very important for co-op, is the packet that I received, was the packet that I received, sent to multicast or sent to unicast. If it was sent to multicast and don't have the reply, I'm silent. If it was unicast to me and I don't have the resource, I reply with an error 404 not found. You get what's important. And finally, six low pan. I mentioned the beginning. It is basically AVv6 over 15.4. And what they did is that they designed the entire API to access the link with IPv6. There's no such thing that you need to do below. So Bluetooth has HCI and a couple of other things. 15.4, especially six low pan, directly IPv6. It maps one to one. So the 16 bits of address map into the link local IPv6 address. It's been adopted by both the thread group for 15.4. It's 15.4 so functionality and as well for the Bluetooth for IPv6 over IPSP called six low over BLA. Are there more questions? Do you have out of band information that the IP changed? Sorry, do you want to receive this in an application? Do you want to? So this is the application trying to receive this information. It's not to talk about protocol to the clients. So the way to do this is operating system specific on Linux AF net link. So you open net link socket. On the net link socket the kernel tells you the IP address has changed. The temporary one expired. Here's the new one. Here's a list of addresses. These are the obsolete ones. These are the current ones. The net link interface, which is the one that IP route to uses, is very, very powerful. So what you're saying, no, no, hold on. So if you do a bind, you bind to a specific, you can bind to the any address in which case you're going to receive to all of them. If you need to communicate out to a client, you need to do the AF net link. Now you can actually bind it to a specific address or when you connect to a client on TCP, for example, you bind to a specific address, not the any address. If that's the case, your address is not going to change. While that connection persists, it doesn't change. So the kernel will keep that address. It ref counts every address that was temporary. It will keep that one forever. Now it might not be preferred anymore. It's obsolete. It will not use it anymore to send new connections, but it will accept things in coming to it. Was there another one? Okay, great. Thank you. One more. So I'm going to repeat the question. The question is, I'm not going to get globally routable IP addresses when I connect to cell phone networks. By the way, that really depends on which provider you have. Mine still gives me a globally routable IPv4. It depends on the region. And for example, mine is an American carrier. They have more addresses available to them. If you're here in Europe or if you're in China, yes, it's going to be a challenge to get a globally routable. The whole idea of IPv6 is that, yes, you do get a globally routable IP address. There were a number of transition technologies that they were expecting to figure out so that we could assign you only IPv6 to your phone or to whatever is at the end of your network and still allow you to reach IPv4 world. So while Facebook hasn't changed yet to IPv6, you would need to do this translation. There are a number of NAT444, NAT64, a number of technologies that you can look up on the internet, transition technologies that would allow an IPv6 host, especially those that get at the end of a cell phone connection, that have only IPv6 to reach the IPv4 world. For now, it is really RFC1918 ports, IP addresses that are assigned to you. It could get worse. I've seen many carriers talking about having double NAT because they just don't have, even with the reserve addresses on IPv4, they don't have enough. Anything urgent? Okay, so I'm here until tomorrow afternoon. Thank you so much for coming. You can contact me and I'm happy to answer questions. Thank you for coming.