• Robert Hinden's home page
• IPng charter at IETF
• IPng Working Group page developed by Robert Hinden

In short, he is uniquely qualified, or overqualified, perhaps, to talk to us today about IP Version 6. And I'm very pleased to welcome Robert Hinden to the program. Welcome.

RH: Thank you. Glad to be here.

RH: From Sunnyvale, California.

RH: Got back last night, yes.

RH: I think everyone's feet hurt. The show seems to get bigger and bigger every year.

RH: I actually found it to be a little less interesting than some of the previous ones. I didn't think there was that much there that was very new or exciting. More wireless 802.11 stuff and a lot of EPM stuff, but I didn't see any breakthrough products.

to do is to get other people to write most of the documents, but try to make sure they're consistent in quality and form with each other.

RH: Yes, that's correct. In 1990, '91, going into '92, the IETF realized that there was going to be a problem with addresses running out. You know, some people thought it was going to happen very soon, other people though it would happen later, but there was a fundamental problem. A lot of effort went into trying to decide what to do next.

(Commercial break)

RH: Yes. I think that was the the thing which got us all started.

We came to understand later as we thought about it that there were actually a lot more constraints to growth. We were concerned with building a much bigger Internet. There's a lot of other things that you also have to deal with that move the technology from one that still sort of requires experts, to one which --this is an image I like to use-- my mother could use. And there are a lot of other things you need to do at the same time.

RH: Well, one is making it auto configure, making it so that you don't have to do a lot of hand complicated configuration in both servers and individual machines. So you can just plug them into the network and have them get addresses and work.

RH: Yes. I tend to call this plug and play internetworking. V4 has gotten better in that respect, but it's still very hard, it still requires servers, and it's very error prone. And this is, I think, one of the real features of IPv6.

The other way to think about this is to think about what the Internet will become. Because right now it largely consists of PC's and Mac's and laptops connected to routers and servers. But as it grows we're going to see more sort of small appliance style devices, PDAs, like putting IP in phones.

RH: Right. And then essentially all devices that use electricity, because we sort of realize we can control them better and save energy. Just make them more efficient.

And in all those kind of devices, there's not going to be a keyboard. It's not a conventional computer, making them plug and play becomes very essential.

RH: Right. I call this transition. It was important that it become as easy to deploy as possible. It's a very interesting problem in that you could argue the Internet is, or is becoming, the largest sort of network that there is or has been. And it's been of course wonderfully successful.

And the question is, how do you transition to a new protocol something that big and decentralized and has no owner or authority? A lot of thought and effort has gone into making the transition as easy as possible. This is essential to the technology itself.

RH: No, not at all. Actually, I think it's one of the strengths.

We were all new at doing this. I would give Steve Deering, who's currently at Cisco, most of the architectural credit for the work.

We had a very strong notion that IP in general and Ipv4 specifically had a very strong, powerful architecture. And we were not trying to do a radical change of that architecture. We wanted to build on top of that. We got rid of a few things that didn't work well. There's a few things that we thought were clear improvements based on experience, but we weren't trying to introduce something that was a whole new paradigm. We wanted something that was very similar but just improved, as if it were a new version. It's not a radically different, scary new thing. It's an incremental change, like the new version of an application, to which some new important features were added.

RH: I've just heard the word science experiment.

RH: I think any time you do something new, there's an element of experiment in it. We're all participating in that experiment. No one has done this before.

RH: I think the Internet is being used in ways that no one -- I suspect this is true for Bob Cahn, who really invented it, and who will freely admit it-- could foresee. They had no idea it would become this big or used for as many things.

RH: I've been working in IP since I worked at Bolt, Beranek, and Newman

in the late Seventies. It was originally designed for defense, military applications. We wanted something that was very simple but very robust and made very little demands on the underlying technology. And maybe this is hindsight, but I think in some ways this is a really good approach to make something work in large scale. It's very simple and flexible and this made it easy to grow into something very large.

But I don't think any of us had any idea it would be this successful or this large.

RH: I don't think there are any. Version 4 has proved very well that it can run really over any kind of media. IP over everything. So I don't think that's an area that there's been any new ground covered.

Addressing is a very key issue, and it was certainly the original incentive. The whole configuration area I another place where IPv4 has had problems. Trying to explain how to allocate addresses and which range of hosts to use and which is the broadcast address and all of that… That's extremely complicated stuff. So that's an area of problems.

I mentioned options. It turned out the option field was too small to be able to be useful be used for security. And that's been a limitation.

Some of these I liked quite a bit before. I don't think it's broken in any way. I just think the address field was too small.

RH: Right. And that means you get more than four times as many addresses, two to the 228th. And I think that's actually a number that most people really can't understand. It's just beyond anything we deal with.

The calculation that I did to try to help people with this was to try to figure out how many addresses that is per square meter on the whole plant.

RH: Well, the number you get from just doing the raw calculation is also very big. I don't remember the number. But there was a paper written by Christian Weedem. He looked at assignment efficiencies of different networks. He looked at the different telephone networks and the Internet and some others, and came up with sort of a range.

So I took the most conservative rang. Applied to the current Internet, IPv4, we would have been out of addresses three or four or five years ago. So we conclude we truly do much better than that today. Came out with a number like 1,500 addresses per square meter. And that covers not just where people live but also the mountains and the oceans and the poles.

So my take on this is that this is an address space that we an use even fairly inefficiently, and still have way more addresses than we're ever going to need, at least while we're on this planet. Maybe when we go around the galaxy, we'll have to do something else. But that will be a nice problem to have.

RH: No problem at all.

(Commercial break)

RH: Yes. There are actually two big wins for having bigger addresses. One is the obvious one of being able to address more things and being able to create more efficient structures, so you get more efficient top-over routing. But one less obvious wins is how you get the auto configuration to be very easy.

We actually borrowed an idea from Novell's IPX, which has been very successful about ease of use, ease of configuration. They had that built in. And we do this very simple technique of creating an interface identifier from the MAC address that's on every Ethernet interface --

RH: Right. The 48-bit MAC address. And then putting this interface identifier together with a prefix obtained from the router advertisement. As a result you automatically get a global address. And it's a very simple technique. It's a proven idea based on IPX's great success in this area. And you couldn't do that in IPv4. You can't get 48 bits into 32 bits and have anything left over for a prefix for addressing.

RH: Yes, that's correct. We've taken what's been introduced in IPv4 under CIDR [Classless Interdomain Routing] to move away from the addressing classes. In v6 we just started that way. So the notion is that there is just a prefix, and we have an assignment strategy or plan that differentiates between the public or provider part of the Internet and the particular organization's part of the Internet.

We wanted to make sure that every organization that connected the Internet obtained enough addresses. So that independently of who the provider is or providers that you connect to, you always get enough address space to have 64,000 subnets. This is more than all organizations today have, except for the few lucky organizations that were connected to the Internet a long time ago, and for most organizations this is much more than you would ever need. And if you should need more, then it's easy to get two prefixes or multiple prefixes.

RH: Eventually you get a block of addresses. And inside of that block, an organization gets enough to have up to 64,000 different subnets, or, in this case, links. The problem we have today is that you go to your provider and ask for some addresses, and they give you a little. And then when you run out you have to go back and ask for more. All that goes away. Organizations will get enough addresses to meet their needs without having to be dependent on their provider for more addresses.

RH: Well, this is hard to talk about without pictures. This depends on who the provider is and how big they are. We now have this two or three-tiered environment where we have some very large providers like GTE or MCI or Uunet, etc… Hope I don't offend someone by leaving someone out. And then we have a lot of other providers who don't have large geographic scope, you know, continents or many, say, in the U.S., across the U.S., but are more local. And a lot of these tend to connect to one of these other providers. And so it depends a lot on which one of those you are.

But we've designed it to make it possible for providers to grow as well. A top level provider will be able to have more customers than all subnets in IPv4 can handle. So it will be possible for providers to have much bigger businesses than they is possible with IPV4.

RH: It addresses it in a couple ways. There's an opportunity here to start over again before aggregation suffers a lot from -- addresses were initially assigned so that they didn't aggregate at all. They were allocated sequentially. It didn't matter where you were or who you were connected to.

Version 6 addresses are really designed to be assigned based on the real network topology. In the example we used before, with top level and next level providers, the next level provider will always have addresses that live beneath the top level provider, so it will be trivial to aggregate them into the block of top level addresses.

We've designed this based on the experience we've had with IPv4 about how we want aggregation to work.

There's another other thing that we've done that's also very important. In IPV4, almost all host implementations really only know how to deal with one prefix.

Version 6 was designed so that if you want to be multi-homed, you get multiple prefixes. Ipv4 requires prefixes be routed locally in order to have multi-homed hosts. And what this means is that it's not aggregated anymore.

So multi-homing in IPv4 makes routing less efficient. But in v6, we designed it such that organizations and hosts, all the nodes can deal with having multiple concurrent prefixes. All of these prefixes still aggregate very well and the routing tables are kept as small as possible.

RH: Right.

RH: Right.

RH: Well, in some ways the header is actually much simpler. You mentioned addresses. We made the addresses four times bigger. But we were able to keep the header to be only twice as big. So it went from 20 to 40 bytes. It didn't get four times as big. And we did that by taking some things out that weren't needed. And we moved to a separate header things that weren't used very often, or were used optionally, such as fragmentation.

So the result was that we were able to simplify the header. And so if you look at it you'll notice it's a lot simpler. It has much better alignment, which makes it easier for computers to look at it and parse it. There's not as much bit assignment.

The early results on performance show that even though it's bigger, at least when a processor is forwarding, you can forward it just about as fast. And I think that's a pretty good outcome. Having this vastly increased address space and larger addresses, but keeping performance just about the same.

RH: Yes.

RH: Yes. Instead of having options which live inside the Internet header, which had its own problems based on performance, we have the options live in their own headers. And this makes it actually much easier to extend and you don't have the size limitation that you had with IP before. So you can build new kinds of applications, particularly security, with potentially large keys that you can carry very well.

And this approach is starting to be now used in IPv4, particularly in the new security work called IPSEC -its all being done with extension headers. So that notion in some degree is being moved back into version 4.

RH: It is possible. We certainly have two types of extension headers. One has its own identity, like the security ones. And then we have another type that has end to end and hop by hop options. So you can also define them in there. And in those options there's the ability to specify what behavior there is. It's mostly for hop by hop, where the receiving node doesn't know how to process it, whether it needs to drop it or whether it can just ignore it.

So we've tried to make the facility as extendable as possible to allow new things to be done.

RH: Well, in some sense you can, essentially you're creating another protocol that runs over IP. And, yes. And this should make it very easy.

RH: Actually not. We mostly built a framework. There hasn't been sort of a long list of new ones.

Probably the most important one I can think of relates to mobility. And the IP V6 mobility spec, the work is almost standard now, uses this facility. In mobility there's this notion of triangle problem where you have an address where you used to be, your home address. And then you have an address where you currently are on the Internet. And in IP V4 the way they did mobility is there was always a triangle. So traffic always had to go back to the home first. But by introducing the new option that all nodes are required to support, you can eliminate the triangle.

So once you establish communication with someone who wants to communicate with you, the traffic doesn't have to go back to your home agent. It can go directly to source destination.

(Commercial break)

RH: It's gone very quickly.

RH: I think quality of service in the whole networking space has been played up a lot, perhaps played up too much. I'm still a pretty big fan of best effort. But maybe that's another topic for another time.

We've included two flavors of things in IPv6. One is a flow label that allows for fine grain flow identification. The notion behind this is, if a particular application needs a particular kind of service, once that's set up in the network you can put bits in the flow label to identify this flow, and so the routers along the way can know how to handle it.

The other thing we've done is what's being called differentiated services in the IETF, which is the notion of sort of a more coarser grained kind of service. It's not a great analogy, but it's like the difference between sending a package via the regular second class mail or first class mail or next day air. Not everyone can define their own delivery service. TNC: Now, as an example, you have values that mark a packet with priority levels ranging from uncharacterized to the highest priority.

RH: The only thing routers need to do is to forward the packets. But routers that know how to do handle this information will be able to provide different services.

The exact definition of these bits is now being done in the differentiated services working group in the IETF.

RH: Right. This has always been the classical problem with having these bits in the header. But the big difference here is the notion that these bits can be set by routers along the way. Routers between the organization and the provider will set the bits the appropriate way, based on what the organization has contracted with the provider. It might be useful for that router to know what end host wanted, but it's really going to be what the organization is going to pay for that will matter.

RH: It's a good question. And there's a lot of chicken and egg problem here. Let's talk about products, because we've been talking about technology.

Most vendors who ship products in volume are working on IP V6. There are a few products out now, and a lot of people are starting to make product announcements. We'll probably see more products this year and into next year.

The most recent activity we've seen, and this may be very essential has been the work Microsoft has been doing. They've recently released a prototype for Windows NT that's available now. And they've also done a thing that's unusual for Microsoft. They've released a source code for that implementation. I can't make any product announcement for them, but I've talked to the product group several times now, and they're very interested in providing IPv6 in a upcoming version of Windows --not the version coming out this year, but I would assume in the following version.

So essentially, I think individual organizations need to look at this as something they need to be following. Once the products they use support it, they should be trying it out. No one can turn it on now, because there's not enough products. But I think in about a year there will be enough products.

One of the things we've done that, you know, avoiding the mistake that the OSI community made with trying to deploy CLNP, is that all vendors doing IP V6 are just including it as normal software upgrades. You're not going to have to buy it. You won't have to pay extra money. So it becomes a feature that you can turn on when you want to.

And I think the big win for most organizations will be in the ease of use space. And we're also seeing people, as part of transition, building translators that can translate between IPv4 and IPv6. I suspect we'll see people starting to deploy V6 in their organizations and then put translators at the edge to talk to the rest of the Internet who hasn't converted to IP V6.

RH: Yes, that's a very good point. The 6Bone has been created as a sort of a test vehicle for IPv6. It's now running all over the world. I just have to check my mail. There was just a new country introduced. There's in the order of about 30 sites in about 30 different countries. Let me see who the latest country was… We just added LITNET in Lithuania. The 34th country to join the 6Bone.

The thing that I've found most exciting about 6Bone work is nobody is telling anyone what to do here. There are no government requirements or laws here. People are doing this because they find it interesting, they find it worthwhile to get experience with it and to participate in creating it.

It's a community that has the notion of building a much bigger Internet. And it's been very exciting to see other people. If it was just me and other document authors doing this, you can't get very far. The part I find very gratifying is to see other people join in and pick up pieces and develop them and try it out themselves. And there are many public implementations And on just about every platform TNC: How about well-known applications? Are they going to need upgrading? The most obvious one is DNS. Very quickly, we only have a few seconds left, Bob.

RH: Yes. There are some very nice simple extensions to DNS. One of those new features is to make it easier of renumber or change providers, so that instead of having to change all your DNS records you only have to change a single record.

TNC: What is the status of the specification right now?

RH: All the core specifications are in the first stage of IETF's standards process, proposed standards. We have recently submitted them for the next step, called draft standard. And I expect the IESG to ratify that in the next number of months.

RH: Well, thank you. I enjoyed having the opportunity.