Good morning. I'd like to welcome you to session 809 on Thursday, Advanced Mac OS X Networking. We're going to talk a little bit about how to work with the new networking features that are in Jaguar on your CD, including IPsec and IPv6. So with that, I'd like to introduce Vincent Lubet, manager of CoreOS Networking. Thank you. Thank you.

Before going into IPv6 and IPsec, we'll talk a little bit about performance, NKE network kernel extensions, world of quotients, and then we'll go into IP, the big new feature of the Core OS, networking. So let's get to it. So at this level you are really in the Core OS in Darwin.

All the application environment can take advantage of many of those features. So performance. So again if you came into the session, you would have seen that the The overview session, the networking overview session, and also just during the keynote, Avi said the biggest impact on performance is polling. So it's really a plea for application developers not to poll. So it uses all the CPUs for multitasking systems like Mac OS X. It still cycles away from other processes.

It has implications for autonomy of portables. And for those of you who are still using the Open Transport API, I mean, there's a very relatively easy way to use Open Transport is to use Sync Idle Event. And just remember that Sync Idle Event is a form of polling.

So you should really avoid, I mean, in addition of trying to get away from Open Transport APIs, if you can, but if you still need, for example, to have your application run on 9 and 10, the same binary run on 9 and 10, you should try to get, I mean, to use other form of Open Transport modes. So what should you do? I mean, you should either block or be event-driven. And blocking is the... The typical model for a server using sockets is to span a new thread for each new connection and all the calls are made blocking.

It's very efficient. If you have maybe a more complex application, the client application that can use many simultaneous connections, you should be event-driven. There are many ways, depending on what kind of APIs you're using. There are many facilities to do that. For sockets, BSD sockets, we have the select system code that allows to multiplex and wait for events on multiple file descriptors at once.

It can be a mix of any kind of file descriptor, sockets being one, but it can be a mix of regular files. For open transport, to get the best out of open transport, especially in Mac OS X, you should use the asynchronous mode from within your notifier. There are some applications that are using asynchronous mode, but they, for example, when they get the event, they just signal a main thread or cooperative threads, and that adds context-switching, which hurts performance. For the higher-level APIs, they are all integrated in the run loop or a run loop. Usually, you shouldn't have to... That's being taken care of by the implementation of those APIs.

So a word about open transport. So that's the truth. Open transport on Mac OS X is kind of slow. It works well for, in simple case, you know, you have one endpoint. But because we need to emulate the different execution level of the traditional Mac OS, that means default task, interrupt time, and things like that.

We do that in the background, in threads, in worker threads in the background. But the communication between, you know, the main API context and the worker threads in the background adds additional context switches. So on... If you have just a simple application that just uses only one endpoint, that's okay. But as you add endpoints, the combination of all those context switches and the managing of all those endpoints will add up and cost CPU usage. There are also other facts. The fact that lookups, name lookups, for example, are serialized.

That also adds a significant impact on performance. Usually we say there's a typical 10-15% impact on performance for... But that's really an average. I mean, if you have a very simple usage scenario, just using one endpoint, for example, you can get relatively high throughput and not much worse CPU usage compared to socket. Always a little bit more. But as you add, you use many more endpoints and other kind of providers, the toll on the CPU usage is greater and greater.

So, open transport is fine in simple case, but if you have an application that is network-intensive, that makes use of a lot of...access a lot of the... A lot of resources on the network. You should really think about using other APIs, BSD or even other higher-level APIs if you can.

Another important factor for performance is buffer size. You have to find a good compromise between too small and too big. and so it affects and also again if you come from, application comes from open transport online, you need not to have to watch very much about those, for example, the socket buffer size or the equivalent for open transport. On the BSD system, BSD-based system, it's much more important. And so by default, for example, for TCP socket, you, TCP socket can hold up to 32K of data buffered in the kernel. And usually that's enough, I mean.

Except if you want to have very high performance, maybe on very low latency link like gigabit, maybe you should think to add that a bit, maybe double or triple that. But also what's very important that affects direct impact on the performance of your application is the size of the buffer you pass to send and receive calls. So the worst we can see is that reading or writing white byte at a time.

So for example, if you need to pass something, you have a protocol that you need to pass, the easiest way of course is to, for example, if you receive an HTTP message, to pass one byte at a time. But you should avoid that. You should have an intermediate buffer when you read by several K at a time.

And also we've seen recently, I've added the fact that the socket receive buffer in the BSD implementation is directly, is really directly affects the TCP window size that is advertised to the other side. So if you don't empty, if you don't read fast enough or if you do read too few bytes at a time, you will, the stack will close the window size.

That means that instead of having a nice streaming of data, the other side will stop sending for a while and so you will have hiccups. And so that's why you should try to, when you... When you have an event on a socket, you should try to empty it as much as you can.

Okay, so kind of to sum up, so the idea here is to minimize latency to have the best streaming, to have the best throughput. So cooperative thread should be avoided because usually that means that you are serialized with other lengthy activity and it's really one thread at a time can run and it's cooperative.

So you could be doing, your application could be doing something very, very expensive and data would accumulate in the socket buffer. And on the other hand, we've seen there's a socket and we've seen very recently an example of that. In the socket, you can use a flag called message.

I think it's the wait all option. That means that, for example, the receive call will not return until you get all the data you've asked for. If you ask, for example, if you ask for a very large amount of data, which is more or less the size of the socket receive buffer size, that means that you will not empty and not have a nice flow. So the window size, the TCP window size will go down to zero.

And those are kind of extreme, extreme case of bad throughput. It's just because there was some code that were just using this flag and it was just, I think, a copy and paste. But you can use that, but you can use that for amount of a buffer that is much smaller than the socket receive buffer size, which is 32k by default.

And also, disk I/O can also affect network I/O. So you should try to-- To apply the same rules, sometimes people say the download is slow, but it's because maybe there are some disk operations that are serialized with the networking. You should watch that.

that you can use to watch for, I mean, the different parameters for performance.

So, for example, I've listed a few of them. TOP allows you to watch various statistics, like CPU usage and memory usage. FS usage is very nice because it allows you to see, for example, if you're using network RU and disk RU, it lists, it gets you a trace of all the hardware related system calls. So you can see, for example, you can see from your application what are those calls and how big they are, how much data is returned.

Also, sample is a nice tool. It gets you kind of a statistical graph of, I mean, statistical view of your call graph. So you can see, for example, if you're polling, you will see that you have the same kind of piece of code that is called all the time.

And also this word here, I think it's kind of also a word of caution is that sometimes people optimize, try to optimize so much that certainly the application is very, I mean, has great performance, but it comes at the price of efficiency. That means that certainly it works well if the application runs alone in the system, but it's not very efficient because it uses too much resources like memory or CPU or things like that.

So you should try to find also a right balance between performance and efficiency. And in session 906, Friday morning, there's a performance session that goes into much more detail. So that if you're interested in getting the most performance at the lowest cost possible, you should attend this session.

Now a totally different subject, a word about network kernel extensions. Network kernel extensions, or NKE in short, allows to extend network services and allows you either to trap data in the kernel or just add new functionality. So we've added that years ago, the ability to add dynamically new services in the kernel. It's dynamic, you don't need to recompile the kernel and things like that. So it's great, but if you're developing a network kernel extension, you should be aware of that running in the kernel comes with a lot of responsibilities.

So the first one, and that's certainly something that we stress over and over and over because it's very important. In the kernel, there is no real API, especially for NKs. So D and it's the same for file system extension. So if you use the I/O Kit, you are safe.

But otherwise, for the BSD side of the kernel, there is no real APIs. We expose all the mechanism, the implementation details. That's really where you hook up in the kernel. So as we add functionalities, that may change at any time. And also there's something that we're aware of, and that the headers do not... do not make clear what is private and what is public.

And so we are seeing a lot of kernel extensions that are using, for example, symbols they shouldn't use. And it's understandable because that was not very well documented. We are planning to remedy that fact. But the big, big message here is that we cannot guarantee backwards or forwards compatibility in the case. So, I mean, if you're developing... if you're developing a network... a kernel extension, especially an NK, you should be prepared to release update in lockstep with Apple. So it's a big burden.

So why do we, why does we have to change that? Because for bug fixes, I mean, the very first, the very first software update of Mac OS X, that means Mac OS X 0.1, a year ago, had to fix a problem. We had to change, for example, the size of the socket structure, so, which is used by many, many NKE.

And we were just lucky that there weren't any NKE shipping at that time, but otherwise it could have had a big impact. We also had new functionality. For example, this year with Jaguar, we're introducing IPsec and IPv6. That means that all the NKEs that are looking into the TCP control block will have to, may break because the structure, an IP address, I mean, all the, everywhere you have an IP address, IP is, the size has changed because it can be an IPv4 or an IPv6 address, which is much larger. So the size of the structure has increased. And also sometimes just for, to, for performance enhancement, we need to change the way things are implemented to be more efficient.

So, kind of the message here is that we recommend that you should avoid to To develop NKs when possible. They are alternatives. For example, if you are writing a network interface, you should really use the I/O Kit. You have the IO Networking family for Ethernet-like interfaces or IO Serial family for PPP, where in fact, that's the classic example where you pretend, for example, your device pretends to work. It pretends to be a serial device, a pseudo-serial device, and do the inframing. That's not new. A lot of drivers were like that already on Mac OS 8 and 9. That's really the recommended way. If you do that, do not depend on the BSD.

So that's the most important. So if you need to talk between the kernel and maybe your controller in user space, something like that, you should use the I/O Kit User Client API. It's also something that's very well, that has nice abstraction layer, so that's something we recommend. And sometimes we have always the question, so I need to add new network protocols.

And if this protocol is to be used only by one application, we recommend that you implement, in fact, the protocol in user space. We have a socket called PF-NDRV for network drivers that allows to capture datagram directly and get them in user space directly. So it's the recommended way if you don't want to provide a network protocol that would be available for all the application but you have kind of vertical solution.

So, but if you still, if you need to develop an NKE, there are a number of rules you should follow. For example, the first one is do strip global symbols. As we are adding features, for example, we are adding IP with IPsec, we've added a bunch of crypto modules.

And we've seen that, for example, DES is kind of common, is in common use. Hey, we got the BSD implementation and it's used, and it clashes with some, already some third-party extension. So, make, I mean, really, you should really export only two symbols from NKE, that you start and stop module. Everything else you should strip. And there are various ways of doing that. There's a strip command, or you can... You can use the, that you can run at, when you, on your executable, you can also declare a symbol private extern. It's kind of an addition from Apple.

Another rule should be is that you should just treat all the BSD, all the kernel-side data structures as opaque data structure. Do not go down on the reference. Use accessors, and if there are no accessors, please let us know what you need. Because those structures, they change size all the time.

In the kernel there's a socket layer which is used by many network file systems. Usually, if you look at the implementation of NFS, that's where it plugs into the kernel. It's the same for AFP. It's a nice layer. It mimics more or less the user-lens socket layer and we don't expect it to change that drastically.

Just still a word of caution, as it is, we are fixing that as much as we can. In the headers you see a lot of accessors that are still macros, and of course that's not good for binary compatibility because we are changing that. If you find some, just let us know and we'll try to fix them.

So again, on Jaguar, because of IPv6 and IPsec, the TCP/IP control blocks, the layout of the structure has changed. We have also new mbuf routines to isolate your code from the details of the implementation. So a lot of the existing macro, Mac OS X dot one, are just macro and they just reference internal data structures. And as we go and as we want certainly to improve performance in this area, we'd like to move away from the way it is implemented today. And we cannot do that today because it breaks all the NKE.

We've done also, following the feedback from a few developers, we've changed the way the socket connect call is intercepted and also the accept connect call. You should watch that and make sure that it should work. For example, the connect call, it didn't work before, so you couldn't do something that worked.

The NKE manager is deprecated. We have a new kernel event protocol in the PF system that allows you to create control stream between your NKE and the and something, a controller in user space. And also something new is that interface can be detached in Jaguar. So that was a loss for, for example, a USB device or PCI network device to be cleanly detached. And there was a problem. It was not possible before that. Thank you.

Okay, so you will see on the developer SDK we've started to clean up the headers, especially the kernel headers. So kind of the rule is that do not reference anything that does not appear in a public header. So we've cleaned up a bunch of headers. I mean, most of them really are headers for, for example, for network protocols. We don't implement, you know, the ISO protocol and things like that. But really, if you don't see a symbol in the public header, do not use it.

It's relatively easy because we have Darwin, we're open source, so you can see, go into Darwin and see how the kernel works. So that's great. I mean, it can certainly help you into your understanding what you should do. But that doesn't mean that because a symbol is globally accessible, because it's exported by the kernel, it's not stripped, that it is an API. Certainly it can be an SPI, which means a system API.

We are also, as Apple is getting, One of our goals is to reduce the size of the kernel and put more functionality in kernel extensions. We reserve the right to have system APIs, things that can communicate between the kernel and some kernel extensions. But we can do that easily because as we bring a new system, we will ship and rebuild everything at once, the kernel and our kernel extensions.

We cannot build your kernel extensions, so you shouldn't use that. And also something to... Here is that things that are built for Jaguar, in fact, here it's more backward compatibility, but if you build your NK on Jaguar, it won't run on previous system because of the changes we've made.

So really, so the last slide is that we are trying to solve that problem. So we would like to come up with a more sustainable, real API if you want in the kernel. So there are things you should do. I mean, you should use the command nm to list, for example, the global symbols you export.

And you will see that, I mean, typically, kernel extension export hundreds of symbols, and they will clash. They may clash at any time with a new feature added to the kernel. So you should use, if you need to export global symbols, you should use a prefix. I mean, for example, something with the name of your company or something like that.

Also, there's the kegslot command. You can use that to check for common mistakes. So there's a number of rules that we are enforcing for kernel extension as a whole in Jaguar. So things you could get away with in Mac OS 10.1 won't work anymore. For example, permissions of your executable and things like that.

So if you're developing an NKE, really, you should work with us with developer relation and DTS. We need to know who you are so that we can work together and make the transition and the release of new system as painless as possible. With that, I would like to call Josh Graessley, who's going to talk about IPsec in Jaguar.

Good morning. I'm going to give you a brief overview of IPSec and what we've got in Jaguar. Why are we interested in IPSec? IPSec gives us a way to securely communicate over the Internet. We can prevent eavesdropping. We can authenticate the origin of traffic. This also lets us -- IPSec is also based on IETF standards, so we can interoperate with other platforms out there. IPSec also gives us a foundation for building virtual private networks. It gives us some protocols. It's important, however, to note that IPSec is not a virtual private network. There's a lot of pieces missing, so it's a third-party opportunity.

What exactly is IPSec? IPSec gives us per-packet authentication and encryption using a set of protocols. It works with any IP protocol. If you can put an IP header in front of it and put it out on the wire, it'll work with IPSec. It's transparent to applications. The applications don't necessarily have to be rewritten to make use of this. IPsec is also host-to-host. The authentication and encryption are based on hosts, not on users. So if you have multiple users on a given host, it does nothing to discern the difference between traffic sent from one user as opposed to another user.

IPSec is comprised of three protocols. There's authentication header, encapsulated secure payload, and IP compression. Authentication header is used to authenticate the packets so we can find out where the packets came from. Encapsulated secure payload gives us some encryption, and IP compression compresses the packets. The authentication header gives us--validates the originator. It'll detect modifications. It'll also detect duplicates, so we can do some duplicate suppression.

It supports multiple algorithms. In Jaguar, we have support for HMAC-MD5, HMAC-SHA1, and a few others. Encapsulated Security Payload encrypts the payload. It doesn't encrypt the IP header, it just encrypts the payload. It can also be used to authenticate the payload. This gives us protection against wiretaps and products like EtherPeak and people using TCP dump.

We do support encapsulated security payload, supports multiple algorithms. In Jaguar we have support for Triple DES, AES, Blowfish, and a few others. IP compression lets you compress the IP payload before you actually encrypt it. This is kind of important because if you encrypt something, it makes it really difficult to compress if your encryption is any good.

The implementation uses Zlib in the kernel. Zlib wasn't really intended to be used in the kernel. It allocates a lot of memory. It's kind of an expensive operation. IP comp isn't widely used, and if you don't need to use it, we recommend against using it for now. In Jaguar, we only support the inflate-deflate algorithm, although the protocol does allow for multiple algorithms.

IPSec can operate in two modes. There's tunnel mode and transport mode. In tunnel mode, we can securely tunnel traffic between two networks or between a host and a network. This is commonly used for VPNs. Transport mode lets us secure communications between two different hosts or any number of hosts.

So we've got these great protocols to encrypt and authenticate traffic. The kernel needs a way to know what traffic should be encrypted and how it should be encrypted. We use security policies to define a filter that defines what level of processing is going to apply to what traffic. We use a filter based on a few selectors, such as the source and destination addresses or ports or even the IP protocol.

This security policy also defines what level of processing will occur, whether the traffic is allowed to bypass IPSec, whether IPSec is required, whether IPSec is used, or whether the traffic should just be discarded. If the policy is set to require or use IPSec, it will also specify which protocol should be used: ESP, AH, or IP Comp. And it will also specify the mode: tunnel mode or transport mode.

The security policy doesn't give us everything, though. We still need an algorithm and a key. We have security associations to keep track of that. The security policy gives us a general, "This is the traffic that should be using IPsec and this is the protocol." But when communicating with a specific host, we need to know a key that's unique to that host and maybe a different algorithm that's unique to that host.

A security association lets us do that, and it does it in one direction only. In order to encrypt traffic to one host, we may need at least two security associations: one for traffic sent to the host and one for traffic coming back from that host to us. Security Association does keep track of the algorithm and the key. It can also have timeouts, so you can have keys expire for better security.

Setting up security associations would be a real pain to do manually, so there's Internet Key Exchange, or Ike, which lets you authenticate... Ike will communicate with a remote host and authenticate the keys... Sorry. Will securely communicate with a remote host and authenticate the remote host using either pre-shared keys, certificates, or Kerberos. And it will then negotiate an algorithm, whether it's an encryption algorithm or an authentication algorithm, and it will exchange any keys.

In Mac OS X, we've got two APIs for setting the IPSec stuff. We've got the PFKey socket, which lets you open a socket and then set security policies and security associations. You can also receive notifications when there's a security association that's missing or when somebody sets a policy or an association. It requires root privileges for pretty obvious reasons. IPsec Policy Socket Option lets you set the policy on a per-socket basis. Your application can use this. This does not require root unless you're trying to bypass IPsec.

In Jaguar, we have two tools. We've got SetKey and Raccoon. SetKey is a tool that lets you manually set security policies and security associations. And Raccoon is a daemon that implements Ike. It'll exchange the keys if a security association is missing. And then it'll create the security associations. Raccoon does not run by default as we ship. And I'm going to give you a quick demo of IPSec running on Jaguar.

So I'm going to go ahead and launch Etherpeak. Actually, I've already got Etherpeak running. And we're going to go ahead and bring up Internet Explorer. And we're going to load a page on the other demo machine running here. And if we go ahead and look at the packet, we can actually see a lot of the transaction. We can see the get, the get, and if we keep going, we can probably see the contents of the page. Which is not too useful if you're really interested in security. So we can come along here and we can go ahead and set our policy.

We'll try that again. Clear the packets. And this time it used Ike to try and negotiate the keys.

We have all of the data is encrypted using ESP and we can no longer see the contents of the web page. So with that, I'd like to bring up Laurent to talk about IPv6.

So, a little bit more about the IPv6 auto-configuration. It's an Apple-talk-like ease-of-use, you know, ease-of-setup for IP. Those link local addresses that you have, this is a little bit for support for HADOC networking and home networking where you don't have a router and you can still have IP addresses. Some of this has been ported back, if you want, in the v4 space where you get those 169 addresses for the auto-configuration.

IPv6 came with this first and it's designed from the start. In our case, it's all done in the kernel where basically we're going to try to get the link local address based on your MAC address. All this fits very well. This afternoon, there was a rendezvous session, but this fits very well with the ideas behind a rendezvous where basically you don't have to do any configuration. It doesn't solve any of the DNS problem, the IPv6 per se. It just solves the address side of the problem here with getting link local addresses.

So, a little diagram about how auto-configuration works. We got here, let's say, a little setting with two machines and one printer. And first, by the fact that they're just connected together, each of them will get a guaranteed unique link local address, which is made by each of the device here running IPv6, assuming the printer is IPv6. So they can all communicate together through this address. And the scope of this address, they cannot, of course, do anything else.

They just communicate in between. Let's say in this case, the case of the convention center, we got a site local address, in which case we can communicate at a little bit of a higher level. We can cross the link local boundary because we have a router here, which gives us a site local address. But we still cannot get to the internet because this is just a local address.

Now, the router is sending us a routing advertisement telling us, you know, giving us some address, some global addresses, in which case we'll acquire those addresses automatically and we'll form an address based on our MAC address from the prefix the router is sending, which will give us global connectivity to the internet.

So, IPv6 in Mac OS X. So, you probably heard the session before. Our implementation of IPsec and IPv6 is based on the FreeBSD CAME stack, which means that we have in the kernel, in the Darwin kernel, we have a stack which is pretty close to what is in FreeBSD 4.4 now, and it's based from the work from CAME.

And we'll see a little bit of the details of that for Mac OS X in Jaguar. So, all this is on your CD, on your Jaguar CD. IPv6 is turned on. You have the link local addresses, and if I start a router here, you're all going to get, my machine is going to be overloaded, but you're all going to get a global address. So, a lot of the mechanisms are in there. We still have some work to do on some applications, things like this, but the basic kernel parts are all in IPsec. in Jaguar right now.

The stack itself is a support for transitions. We have what we call a dual stack implementation, which means that we don't have IPv6 or IPv4. We have two stacks. You can have IPv6 and IPv4 running at the same time. If you have an IPv4 address, that's fine. IPv6 can still work and vice versa.

Another thing for transitions that we have in Jaguar is a 624. 624 is an IPv6 tunnel over IPv4. What it means is that it can give you global IPv6 connectivity even if you only have an IPv4 address. That's a good way for people like us to test things to see if the application is working fine with IPv6 and so on. What it does is that it's going to call to... Once it's configured, it's called the device STF.

It will use your IPv4 address, your globally accessible IPv4 address, and then call to a router which will route this IPv6 address to the global IPv6 net. This is embedded in IPv4 packets, so you don't need to have IPv6 all the way. Let your machine be part of a bigger IPv6 network.

If you don't have all the links being IPv6, that's an interesting way. The IPv6 routing is part of what we have in Mac OS X. You could potentially turn this into a full IPv6 router. Another thing that we have in there is the auto-configuration and the neighbor discovery. Turn by default on your CDs is listening for router advertisement. If there is a router advertising prefixes, we'll pick up the address.

We'll use that as a configuration and we'll use this as a router or default router to the IPv6 world. That's something which is in Jaguar. In Jaguar also, one caveat is the DNS for IPv6. We're doing the DNS resolution over V4. There is no DNS over V6 in Jaguar at this point.

That's a little bit of a limitation. What happens is that you can get... Let's say you're looking up an address like mymachine at apple.com. If your DNS is configured with Quad Air Records, it will send back information about the IPv6 addresses configured for the Quad Air Records as well as the IPv4 addresses. Then in your program, you can choose which address you want to use to communicate with the other side. If you can go through this, you can go through the six.

Some of the tools that we have in Jaguar, ifconfig, right now that's the only way you'll see that you're on IPv6 is if you go in the terminal and do an ifconfig-a, you'll see the fe80 and something at the last 64 bits that looks like your Mac address with an ffe inside. That's not going to show up in the control panel. You need to do ifconfig. You can also do a man-ifconfig. We updated the man page for those tools and add yourself an IPv6 address.

Or you can also configure the tunnels, IPv4 to v6 tunnels through ifconfig. Ping6, which, you know, like ping, lets you ping hosts. There is a difference here that this is a way I saw was installed at Jaguar on their PowerBooks here. Is that if I do a multicast ping, I can tell, you know, everybody.

Who has an IPv6 address is going to respond. And there is some way to do a multicast ping on the link to see who has IPv6 addresses. Trace route 6, you know, same thing as trace route to see. Netstat has been updated. It's going to show if you do a netstat-rn, it's going to show your route with IPv6. Route, also to add your route. TCP dump, which actually in the CD doesn't work. One of the libraries is not working for IPv6. But it's there also. And RT-SOL, which is for the router solicitation. Some of the apps also are v6-aware.

SSH, FTP, Telnet. All those, I think there are still some bugs on your CD. And they are, all those are open source. So you can go on Darwin and look at what they are doing. And they are a good source of protocol independent implementation. Because let's, in the case of SSH or FTP or Telnet, they work the same executable.

It's working for both v4 and v6. And they have some example in there, you know, showing how they decide which address and which, you know, protocol to use if they use v4 or v6, depending of what the DNS is getting So on that, for you, for developers, what you should be aware, even if you're not thinking right now about getting IPv6 completely implemented in your application, what you should be aware of. Of course, that IPv6 addresses are bigger. They're 128 bits instead of 32 bits. So all your structure, all the assumption you might be doing, thinking, ah, all I'm going to get is a 4-byte address.

They're not going to work because in the list of addresses you'll get, you may get and you will get the link local address, which is 128 bits. So that's one of the things. It's on the CD. It's like we've been catching a few mistakes in our code where people were making assumptions about the length of the addresses they were getting back. So nowadays, it's true for v4, but to a lesser extent.

But now with IPv6 interfaces, when you're looking at interfaces, they have multiple addresses. So you cannot do things like identifying an interface by its address. Because you have multiple addresses and they are auto-configured in many cases. So the address might change because the router advertised something else. So don't identify an interface by its address.

You cannot, as I said, you cannot assume the AFI net length, you know, 32 bits. You have a new function and there's a good man page on this one, which is called getIF adders. And this is the new way of sorting through the addresses you're going to get. That gives you a table back with all the addresses of all the interfaces.

And as we mentioned before, address can be auto-configured. There is multiple scopes for addresses. And there is rules and there is macros and tools to decide which address is the best to use in which circumstances. To that, if you're interested in looking at this, there is a basic BSD API, the RFC 2553, which talk about the IPv4 binary compatibility. All those functions work for v4. And one of the goals there was everything that has been compiled for v4 still works with v6 in there. However, you don't take advantage of the v6 functionality.

and Alex Schroeder. The RFC gives some very good advice about IPv6, IPv4 independent programming. You can know what the caveats are here and what to do to get your application or protocol independent. GetAdderInfo is now the new main address independent API. This is what lets you choose v4, v6 and you get to use it instead of getOsByName. getOsByName only works, it still works, but only works for v4. It won't be able because it assumes AFInet lens for addresses. Look at GetAdderInfo.

GetAdderInfo is a bit of a complex API. It does a lot of things, but this is a new API which is address independent. It would work for all of us. It would work with v6 and v4. Check the JaguarMan pages for the new resolver calls. GetNameInfo, getIPnodeByName, inetp2n and inetn2pr is the main one. They are all more or less based or there are some specific duty function over GetAdderInfo. Those are the new calls.

And also if you're trying to do an application which, you know, take advantage of the IPv6 features, you get a more advanced API, the RFC2292 is describing it, and lets you do, you know, some of the new cool stuff with multicast and IPv6 or access to the raw IPv6, you know, sockets.

And for the higher level API, you can use CF Networks. CF Networks is IPv6 aware and depending, you know, if the address you're trying to resolve has any IPv6, it will deal with that and that will make things much simpler for you so you don't have to worry about it.

And for more details about the protocol independence, this is the right URL in the CAME.net newsletter. It talks about what to do for getting your tools or your daemons or, you know, being able-- If you're a listener, don't use a socket or in, use a socket or storage in which case you will receive a connection for V4 and for V6 and you don't have to worry about it. If you're using something, you know, just for V4, you won't be able to get V6 sockets.

So with that, the roadmap for today. So the Darwin roadmap, that was Monday. Darwin kernel yesterday morning. Managing kernel extension, where some of the things Vincent was talking about are also in details, was yesterday morning. Tomorrow morning, developing for performance. That's another thing that you might be interested in.

Or on the CoreOS Networking Feedback Forum tomorrow afternoon. Another thing which is not in this roadmap here, but we need to add, is the ZeroConf, or AKA rendezvous, this afternoon at 2 p.m. And I think the location changed. It's now in the main hall in Hall 2. So instead of whatever room it was in. So it's in the big hall. So it's in the main hall here. Who to contact? Tom. Tom Weyer is your contact.

And Vincent is our manager here. For more information, for Kame IPsec and IPv6, you can go on the kame.net. It's got a very good page with pointers to a lot of things. FreeBSD out-tools. And it tells you a little bit of demos that Josh did. How to do that.

You know, we got some cool tools. They're a little bit complex to configure. But once you get the hang of it, you know, it's pretty cool. Some other performance tip. The perf book on the developer.apple.com page. And some Darwin programming documentation in the tech pubs. So with that, I'll call back Tom for the QA. Thanks.