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.

It's me, so before going into IPv6 and IPsec, we'll talk a little bit about performance, NKE network kernel extensions, words of caution, 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, the overview session, 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 system like Mac OS X. It's really, it still cycles away from other processes. It has its own 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 a 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 nine and 10, the same binary run on nine 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, kind of the way that a lot of Unix application and tools are written, because usually they just, I mean the typical model for example for a server using sockets is to span a new thread for each new connection and all the calls are blocking. It's very efficient. If you have a more, maybe a more complex application, the client application that can use many simultaneous connections, you should be event driven. And there are many ways depending on what kind of APIs you're using. There are many facilities to do that. So for sockets, BSD sockets, we have the select system code that allows to multiplex and wait for events on multiple file descriptor at once. And can be a mix of any kind of file descriptor, sockets being one, but can be also file, regular files.

For open transport, I mean, to get the best out of open transport, especially on Mac OS X, you should use the asynchronous mode from within your notifier. I mean, 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. And for the higher level APIs, they're all integrated in the run loop or a run loop. So usually you shouldn't have to, I mean, 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 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 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. So there are also other facts. The fact that lookups, name lookups, for example, are serialized. that also adds, you know, that also has a significant impact on performance. So 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, that the toll on the CPU usage is greater and greater. So OpenTransport is fine. in simple case, but if you're really, if you have an application that is network intensive, that makes use of a lot of, access a lot of the, 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. So 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 don't have to watch very much about those, for example, the socket buffer size or the equivalent for open transport.

On a BSD system, BSD-based system, it's much more important. And so by default, for example, for TCP socket, TCP socket can hold up to 32K of data buffered in the kernel. And usually that's enough. I mean, it's... So 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 parse something, you have a protocol that you need to parse. The easiest way, of course, is to, for example, if you receive an HTTP message, is to parse one byte at a time, you know. But you should avoid that. You should have an intermediate buffer when you read by several key 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 the really the directly, the 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 for, or if you do read too few bytes at a time, 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. You will have hiccups. That's why you should try to, 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 wait all, 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. Those are kind of 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 buffer that is much smaller than the socket received 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. And you should watch that. And it's kind of, we have many tools to 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 RU-related system cores. 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 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 world here, I think it's kind of also a world 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 that if you're interested the most performance at the lowest cost possible, you should attend this session.

No, totally different subject. Word about network kernel extensions. So 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 and 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 a 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 the, 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, 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 it 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 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, 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 add 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 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. There are alternatives. For example, if you are writing a network interface, really, you should really use the I/O Kit. So you have the I/O networking family for Ethernet-like interfaces, or I/O serial family for PPP, where, in fact, that's the classic example where you pretend for example your device pretends to be a serial serial device, a pseudo-serial device and do the end framing that's not new, I mean a lot of lot of drivers were like that already on Mac OS 8 and 9 so that's really the recommended way and if you do that do not depend on on the BSD so 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 IPv6, 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 NK that you start and stop module. Everything else you should strip. And there are various way of doing that. There's a strip command or you can use, that you can run at, when you're 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.

So in the kernel there's a socket layer which is kind of okay, it's used by many network file systems. So usually, I mean if you look for the implementation of NFS, that's where it plugs into the kernel. It's the same for AFP. And that's a nice layer. It mimics more or less the user and 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. A lot of, we have 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, and I mean, 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, macro s10.1, are just macro and they just reference internal data structures and as we go and as we want 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. So you should watch that and make sure that it should work. I mean, the connect, 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 kind of create control stream between your NKE and the protocol. 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, USB device of PCI network device to be cleanly detached.

There was a problem. It was not possible before that. Thank you. Uh... - 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 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 mean a system API. We are also, as Apple is getting more and more and more and more, 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 keg_slot command 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 to let, I mean, 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 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. Thank you. 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. time. We do support encapsulated security payload, supports multiple algorithms.

In Jaguar, we have support for TripleDes, AES, Blowfish, and a few others. Yes. 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.

I'M NOT SURE IF I'M GOING TO BE ABLE TO DO THAT. 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. times. 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. And then this security policy also defines what level of processing will occur, whether the traffic's 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'll also specify which protocol should be used, ESP, AH, or IP Comp. And it will also support-- 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. So we have security associations to keep track of that. The security policy gives us sort of 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. And a security association lets us do that, and it does it in one direction only. So 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. The 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 a 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. Hopefully you see that right here. It's using Isocom. And yeah. We have all of the data is encrypted using ESP, and we can no longer see the contents of the web page. And... So with that, I'd like to bring up Laurent to talk about IPv6.

Okay, so I'm gonna talk a little bit about IPv6 and the implementation we have in Jaguar now. So on your CD, you have IPsec and IPv6. So a little bit first, we'll talk about the motivation for having something like IPv6 in the system. So as you probably heard, there is a problem with the address, the gross problem of the internet and the fact that a lot of people don't have enough IPv4 addresses. That's one of the motivations for IPv6, is that there are bigger IPv6 addresses, and that's for the address space exhaustion. Also another problem with IPv4 right now is the fact that there is a routing meltdown.

All the top-level routers need to learn about a huge number of routes. IPv6, in the way it basically manages addresses, has a solution for this by aggregation of addresses. That's something for the routing meltdown. Also one of the big problems, and I know everybody has been having issues with that, is the NAT And the necessity in IPv4 to have, because there isn't enough IPv4 addresses to have NATs, and the NATs is breaking a little bit the end-to-end connectivity model of IP, and that everybody has to do a bunch of skanky things to go through NATs. And IPv6 is supposed to solve this because everybody can have globally routed addresses, so you don't need those address translation things. Another motivation for IPv6 are international markets.

This is because IPv4 addresses are rare, and some countries have very, very few IPv4 addresses. I heard that China or India have less IPv4 addresses than places like Apple. So that's one of the big motivations. why IPv6 is probably not as important in the US as it may be in Asia or in Europe. Also, even if some of those standards have already been used in IPv4, IPv6 mandates those standards like IPsec. IPsec is the implementation that Josh just showed.

It's working also on IPv6. That's part of the IPv6 standard. The multicast use is standard in IPv6. the auto-configuration mechanisms are. We'll talk about this a little bit more in details. That's the other motivation for IPv6. Going through that, here is the new IP header. Just a reminder here is that IPv6 is only a change in the IP layer. The TCP, UDP, or whatever protocol you have on top of that are pretty much unchanged, besides the fact that, as we're going to see, the addresses are bigger with v6, but the only thing that changes is the IP layer for IPv6. If you remember the IPv4 header where you have a lot of fields here, it's pretty much streamlined. We got a version number in which, in our case here, it's version 6. We got the class and the flow labels, which are not completely clear now exactly their usage, but it's for some traffic shaping and all the quality of service things. It's built in there. We get the payload length, which is much bigger here, which is 16-bit. We get the next header field. There is no option headers in the IPv6 packet. This is something that routers like, Because basically for simple packets, you don't have to look for options.

You get something which is called the next header, which is going to tell you the offset of where you're going to find the option in there. So in that case, where a simple packet, where there's no options, the next header will point to the TCP header or to the UDP header, whatever you have behind. we get the hop count, which is the same thing as we had in V4. We got those two big fields here, the source and destination addresses, which are 128 bits, which means they are four times bigger than they were in V4. What that gives us is now our IPv6 addresses are 128 which means that now we have, instead of 4 billion addresses, we get 340 and a zillion. So this is quite a few addresses, so we shouldn't run out of addresses soon. That's a theory, at least. So the other thing about the IPv6 addresses is the addressing architecture embeds a lot of things in there. So you get part of the routing, which is in there, a little bit like the phone system, where you get your ARIA code and your phone number in there. The IPv6 addresses have the same kind of meaning in them. So that's why it solves part of the routing meltdown problem. Because in your IP address, in itself, you know basically where the next exchange is, if you want, or the next big router. So there is an address structure, and we get different type of addresses. We get the unicast addresses pretty much like your IPv4 address, which is one-to-one addresses. And we get the local use addresses, the link local addresses. If you boot a Jaguar, you'll see that if you do an IF config, you'll see that you have an FE80 IPv6 address. It's a link local address, which is only valid on your link, and it's done at boot time. Those are part of the address range that you'll have with IPv6. Of course, you have the multicast addresses. The multicast has been standardized, and there is a lot of new things, and a lot of new things yet to be discovered with it in IPv6. So multicast is a big part of IPv6. In the address architecture, another thing is that we have a scope of addresses. It's pretty much standard for IPv6 to have multiple addresses. You'll always have a link local address. You might have a site local address. Site local addresses, let's say we have an address which is only valid in the field of this convention center. It's not going to be routable anywhere else. It's not going to get outside, but it lets you go through routers inside the convention center. You have global addresses which are globally routed and let you access everything all over the world.

Here we see that on the 16 bytes of these addresses, we get eight which are globally administrated. That's one of the ways you can do it, and eight that are locally administrated. ICMP also changed for IPv6. IP was used for a lot of things in v4, and now in v6, it's got more use also. One of the things is that it's used for error messages and, you know, echo request and reply pretty much the same way as it is for IPv4. The difference is also used for the multicast listener discovery. So ICMP v6 is working with multicast, and you can ping a multicast group here, or you can also use it to discover multicast agents around.

The neighbor discovery, the ARP, there is no ARP in IPv6. The ARP protocol has been folded under the IPv6 protocol, and it's done by doing neighbor discovery, which are specialized CMP packets, where basically you're asking, okay, here's this IP address, IPv6 address, who is the owner of this, and it works pretty much like ARP, but it's been folded into one protocol, so there is no, the IP protocol and the ARP protocol, it's all IPv6, and now the ARP packets, if you want, are through the ICMP. And it's also used for router discovery. One of the things you can do is do a router solicitation, and when you come up here on this floor, your machine can, they are listening for router advertisement, but they can also ask for a router, "Is there a router here? Give me my configuration." And for the prefix discovery, which is those eight octets of globally-administrated address we were talking about. That's a change also. But again, it's a change under UDP and TCP.

uh... so a little bit more about the i_p_v_ six of the configuration it's an apple book like is of use uh... you know is upset a four four eight friday uh... 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. Well, some of this has been ported back, if you want, in the v4 space where you get those 169 addresses for the auto-configuration.

But 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. And all this fits very well. I mean, this afternoon there is a rendezvous session, but this fits very well with the ideas behind 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 linked local addresses.

A little diagram about how auto-configuration works. We get here, let's say, a little setting with two machines and one printer. 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. They can all communicate together through this address. The scope of this address, it cannot, of course, do anything else. It just communicates in between. Let's say in this case, the case of the convention center, we get 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. We still cannot get to the internet because this is just a 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 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 Jaguar right now.

It's available in Jaguar. The caveat here is that it's available for developer and advanced users. You probably know that we have the configuration, the system configuration framework and a lot of things through the control panel and some way to dynamically learn about addresses going, when you're doing some mobility things and leaving your pro book, changing location and all those addresses are required and everything. Right now, IPv6 is not hooked up to the system configuration framework yet, but that's something we'll have probably in the future. Right now in Jaguar, it's for you developers and for advanced users.

For developers, so you can rev your application to be aware of IPv6 addresses to the new way of getting IP addresses that may not be IPv4 addresses, for one thing. and then to take advantage of IPv6 if there is an IPv6 address or if you want to take advantage of the new feature of IPv6. So it's based on the open source work from Kame. So we've been working with Kame, and we're still working with people there in Japan. It's a standard for the BSD implementation. The Kame stack is one of the best IPv6 implementations out there. And the good thing is that there is a lot of information on this different forums, the CAME website, or all the BSD. It's in that BSD, free BSD, I think open BSD, all of them. So what we provide in Jaguar is a kernel, the kernel as IPv6 and IPSec turned on, some common line tools, headers, and libraries.

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 embedded in IPv4 packets, so you don't need to have IPv6 all the way. Let your machine be part of the bigger IPv6 network, even 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, so 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. Turned by default on your CDs is listening for router advertisements. If there is a router advertising prefix, we'll pick up the address, we'll use that as a configuration, and we'll use this as a route or a default route to the IPv6 world. So 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.

But what happens is that you can get, let's say you're looking up an address like, you know, [email protected], and your DNS, if your DNS is configured with Quad-A records, it will send back information about the IPv6 addresses configured for the Quad-A records as well as the IPv4 addresses. And then in your program you can choose which address you wanna use to communicate with the other side. And if you can go through v6, you can go through v6.

So 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 dash a, you'll see the fe80 and something at the last 64 bits that looks like your MAC address with an ff, fe inside. And 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. Ping 6, which like ping, let you ping host. There is a difference here, that this is a way I saw was installed a Jaguar on their PowerBooks here, is that if I do a multicast ping, I can tell everybody who has an IPv6 address is gonna respond. and there is some way to do a multicast ping on the link to see who has IPv6 addresses. Trace route six, same thing as trace route to see.

Netstat has been updated, it's gonna show if you do a netstat-rn, it's gonna show your route with IPv6. Route, also to add your route. TCP dump, which actually on 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. I think there are still some bugs on your CD. And all those are open source, so you can go on Darwin and look at what they're doing, and they're a good source of protocol independent implementation, because in the case of SSH or FTP or Telnet, They work, the same executable is working for both v4 and v6, and they have some example in there showing how they decide which address and which protocol to use, if they use v4 or v6, depending on what the DNS is getting them back.

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. 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 identify 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 AF in it lands, you know, 32 bit. You have a new function and there's a good man page on this one, which is called get IF adder. And this is the new way of sorting through the addresses you're gonna get. That's give 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 function.

functionality. Also, this RFC gives some very good advice about IPv6, IPv4 independent programming, so you can know what the caveats are here and what to do to get your application or protocol independent. GatherInfo 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. So 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 and would work with V6 and V4. Check the JaguarMan pages for the new resolver calls. Get name info, get IP node by name, INet P2N and INet N2PR is the main one. They're all more or less based or there are some specific duty function over getAllergyInfo. So those are the new call.

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

networks is IPv6 aware and depending, 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. 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. 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 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. and 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 zero conf or aka rendezvous this afternoon at 2:00 p.m. and I think the location changed. It's now in the main hall in hall two. So instead of whatever room it was in. So it's in the big hall here. Who to contact? Tom? Tom? 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, you know, 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 there. They're a little bit complex to configure but once you get the hang of it, it's pretty cool. Some other performance tips, 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. Thank you.