Special NANOG/ARIN Feature Presentation [Archived]

Draft Transcript - Wednesday, 15 October 2008

Note: This transcript may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting.

What Would Jon have Done About the Addressing Challenges Currently Facing Us?

MR. PLZAK: If those of you that are standing in back could please take your seats, we would like to get this started with probably one of the most unique events you may ever attend in your participation in Internet gatherings.

This morning – by the way, I’m Ray Plzak. I’m the president and CEO of ARIN. And this is a back-to-back week of NANOG and ARIN meetings. And this presentation/panel discussion this morning is jointly sponsored by ARIN and NANOG.

Over the next few days, in the ARIN meeting, we will be discussing several policies that have profound implications for the way address space is managed going forward. With the impending depletion of IPv4 address space, the free pool, we are faced with a critical juncture in the life of the Internet.

A similar type of crisis existed some time ago, which was the genesis of producing IPv6, and how, as many of you know, the IPv6 solution has not taken off in terms of adoption. So we are faced with a crisis, I guess to a certain extent, of our own making.

So the panel this morning, and Rodney will discuss the panel as far as – and introduce the members to you, is here to discuss what Jon would have done with this. Because back in that earlier point in time, Jon was instrumental in moving us forward. And so I would like that, if you could, those of you that have not planned on staying around for the rest of the week and have just been here in the beginning of the week to register to be a remote participant in the policy discussions later this week. And that information is on the ARIN website.

And I’m certain that our panelists will provide some insights to the problems that exist that we can certainly put into the policy discussions that will be occurring.

So with that, I’d like to turn it over to Rodney Joffe.

MR. JOFFE: Thanks, Ray. And good morning all of you. I’m glad there’s a lot of faces I see that we had earlier on in the week, so that’s one of the neat things.

I’m really thrilled to have been able to convince Ray and Betty to let me put on this panel and invite these people. These are people that obviously have affected all of us in one way or the other over the years. Many of you may not know who they are. Hopefully, many of you do. What I will tell you is that every one of you has a job as a result of work that these guys have done. There is something that they have done that you deal with every day.

But I guess the first thing we should do is, you know, ask who is Jon? One of the things that I’ve noticed is that over the years folks who come into the industry have no idea who Jon Postel is. I’ve seen a couple of times on some of the lists people will say Jon Postel, who is he?

So in a nutshell, you may remember this. When Jon passed away 10 years ago tomorrow, which is why we’re doing it this week, tomorrow will be 10 years since Jon died, there was, you know, news around the world. There was a headline that was picked up and it was actually a result of, I think, an article in The Economist in the early – in the mid-’90s. Jon was known as “god of the Internet.” So some of you may recognize the picture, hopefully, from the (off mike). But he was obviously more than that.

He was born in ‘43, died in 1998, October 16th. For many of us over here who were fortunate enough to know him, he was friend, you know, first and foremost. He was the RFC editor. So those of you who deal with RFCs, Jon was the RFC editor for many, many years.

He was IANA, so the predecessor to ICANN, you guys involved in addressing. Everyone used to have to go to Jon to convince him to make changes in terms of addressing or to one of the people who worked for him. He was a referee, probably the best referee we ever had.

Probably the best way of describing him is the ultimate shepherd. Jon made things worked and everyone trusted Jon.

So the panel today are people who’ve all worked with Jon, but they’ve all been involved in the addressing issues at different stages. You know, you can see as you look down here there are gray beards and there are a couple of folks that, you know – obviously Lixia without a beard, but – and no gray hair. So this is a range of people from the very earliest days. I think that Bob I remember seeing, Bob Braden. He started his career in the ’50s with computing. So – I didn’t even know computers existed then, but Bob was involved in the ’50s. And Danny was involved in the very beginning with the ISI. And I think the section (off mike) Jon’s office at ISI, there’s two people who shared the floor, I think, at some stage and have both been involved with the same division that Jon was involved in.

Danny Cohen, some of you may know from Miracom and Miranet, which was the thing that really impressed me, but he’s done many, many other things. But he’s been involved in the issue of IP and TCP and he’s infamous for a couple of things, and he’ll probably tell you that a little later. But, you know, he’s one of the people that gets blamed regularly for where we are today. I think he said this morning at breakfast, you know, he won one and he lost one, and he’ll tell us what those were.

Van Jacobsen many of you know because of congestion control. You know, I don’t think any of us has, you know, not used some of the software and some of the techniques that he developed and wrote about. However, he also is the guy who is accused of coming up with the idea of NAT. So if any of you have any issue with NAT, this is your opportunity to get some of your own back. Paul you know from a couple things. I think, Paul, you were involved also with SMTP. But DNS, you know, Paul, you know, is, in 1983, at Berkeley, I guess. Sorry, ISI, at ISI, but with the creation of DNS. So any of you that get upset by, you know, DNS and where it is today, you can blame him.

And finally, Lixia, who actually was involved with a panel in the mid-’90s. She actually chaired a group that I think the IAB or the IASG put together to once again deal with this looming problem with addressing and IPng and the next generation.

So these are all people who were relevant at different times, but with the same problem. So the problem that we may think that we’re dealing with today is not new. It actually has existed for a long, long time. And hopefully, we’ll get some wisdom from, you know, Bob Hinden, who is the moderator, who was also involved in the very beginning with the various working groups and I think chaired part of IPng.

So these people, although you may not be aware of some of them, they absolutely are involved in the problem that we’re dealing with today. They thought about it, you know, 25 years ago and 15 years ago and 10 years ago. And they, hopefully, will help us accept where we are and give us some direction based on history.

MR. JOFFE: So let’s talk about what Jon would have done. I’ll hand it over now to Bob Hinden, who’s going to try and herd these guys for the rest of the panel. Thanks. Bob.

MR. HINDEN: Thank you. Yeah, I was quite honored to be asked to try to moderator this panel, though I think it may be, you know, the usual thing of herding cats. I’ll do a very quick introduction, which I’m doing now, and then the individual people will speak: Danny, Van, Lixia, Paul, Bob Braden. And then I’ll talk a bit at the end and then we’ll have some time for a discussion.

We would – you know, if you have questions or strong disagreements with what people say, you know, I think you can come up to the mikes during the talk, but I’ll still try to manage the overall time, so we won’t – be able to do some of that. I don’t know how well these – my colleagues here will be able to keep to the schedule.

So at that, yeah, Danny asked me to do a very brief introduction to him. I’ve asked the other folks to introduce themselves when they speak.

But Danny – well, in the bio he sent me, Danny takes the blame for not convincing Jon and Vint to make IPv for variable length addressing, so he blames himself for the situation we’re in now. I’m not sure it’s so simple, but he can talk about that.

Internet Addressing

So with that, why doesn’t Danny come up and do your talk?

MR. COHEN: Thank you both. Slide No. 1.

MR. HINDEN: Yeah, we should bring up the slides.

MR. COHEN: I asked Bob to introduce me by saying that I’m a member of the (off mike) Society, which I am, by the way.

How many engineers does it take? Okay, we can start now. The question that we were asked was what would Jon have done about the current – I hate the word “current” because it moves – about the addressing challenges we have now? And I’ll tell you what Jon would say about it and tell you what I would say about it. Next slide, please.

We have a number shortage. Now, it’s not that there are no numbers in the world. There are lots of numbers in the world. But the problem is that we’re running out of addresses, and we are not the first to have these problems. The telephone system had exactly the same problem, but they attacked it differently. Both problems, the ones we have and the ones they have, are the caused by the way we use the addresses, not by the quantities. It’s not that we have 2-to-the-72 computers now. It’s not that there are 10-to-the-10 telephones in North America. It is the way we use the address space, not the quantity.

The North American Numbering Plan, or NANP, when it was defined it left a factor of 6 by insisting that telephone area codes don’t start with 0 or 1 and the second digit must be 0 or 1. And by relaxing those rules, there was immediately a 6X addition. In addition to that, not all area codes are full such that the telephone system had lots of room to grow, and we should adopt something similar to that. Next slide, please.

So the system that is used in telephones in North America is fixed-length addresses, 10 digits. What we do in networking is slightly different. The first address – the first time we had the notion of address in a packet was in the ARPANET. In the ARPANET we have 8 bits for an address. So 8 bits per 6 for the size or IP number and 4 for the host. This was really looking forward because we thought that it would be 10, maybe 20, but sure not more than 30 hosts. But in spite of that, they assigned 6 bits for hosts and – I’m sorry, 6 bits for IP number and 2 for hosts. The idea was that maybe someplace will have two computers, like MIT, they might have two computers on the network, but we allowed for four even by having 2 bits (off mike) so that we never run out of (off mike) address space.

We sure did. So our reaction was to multiply it by four. Instead of 8 bits, we went to 32 bits in IPv4. When we ran out of addresses – and the reason we ran out of addresses, again, is not because we have too many computers, but because the way we have to use address space – we multiplied it by 4 and got 32 bits. When we see a problem with 32 bits, we multiply it by 4 and we get 128 bits, or better known as IPv6. And let me predict that the next time we go to 512 bits address and we call it IPv8 or maybe IPv9 by that time. And this process can continue ad infinitum as long as we stick – we insist on fixed-length addresses. Next slide, please.

So there must be some Moore Law for addresses, which looks like that: A log of something versus the year. Next, please.

So the other approach is the variable lengths (off mike). And it is – and obviously it is extensible variable-length addresses, which is sort of like what we have in DNS and URL. And the idea is that we can develop and change the address in every region independent.

A good example is the global telephone system. The global telephone system, each country can change the number of digits in the telephone address and they don’t have to tell anyone else and they don’t depend on anyone else. Again, it is like DNS. Thank you, Paul, by the way, for thinking about it.

The problems, the difference between the fixed- and the variable-length, the variable-length addressing needs more smarts per node. Smarts were very expensive 30 years ago. Today they are very cheap. Next, please.

I’d like to bring you an example. Think about the hotel and you want to call someone in the hotel room. The person can – some hotels have direct inward dialing and you can dial directly the 10-digit number and get to the room. Well, this is the way most of us in our offices have it.

The other (off mike) is to have more than one step. Like the entire hotel is one number and you call this number and then the operator asks you which room do you want to talk to, and you do step 2. The problem with the 2-step is that instead of giving you 10 digits, they have to give you 14 digits to find my extension inside the organization.

But the entire organization used only 1 instead of 10,000 entries in the address space and it is much better handled like that. Next, please.

Okay. So the question is why IPv4 has fixed-length addresses. And I really don’t want to answer it because I don’t like to spread the blame.

Next slide, please. So what I believe Jon would have done was to advocate variable-length addressing. It’s too late for v4 and v6, but this is what we should have done.

And before leaving, I’d just like to show two more slides, one is very personal. Next slide, please. This is Mt. Whitney, the place that Jon loved to hike there. And every year he would take a vacation and spend a few days around Mt. Whitney.

And the last thing before I leave, I told you that I’ll tell you what I would have said if I were asked about the addressing. Next slide, please.

Thank you.

LNAT - Large scale IP via Network Address Translation

MR. PLZAK: Van Jacobsen is next.

MR. JACOBSEN: I have to correct something Rodney said. I didn’t invent NAT. I’m not sure who invented it. I know that Paul Francis, who was then Paul Sukiya, wrote the original RFC on that. But I am guilty of proposing NAT as a transition plan to whatever we did to run out of IP addresses and also saying, hey, and you might also use it as a way of solving the address shortage problem. And I’m actually here today to publicly apologize for that. It’s just a massively bad idea.

The title that’s up there is the title of a paper that I wrote in 1991 about how you could use a NAT-like approach for transitioning to bigger addresses. And it was presented at an IAB workshop in 1992, start of 1992, that Jon had convened to talk about the shortage of addresses issues.

It was a terrible paper. This was the first paragraph. It says that, hey, we’re running out of addresses because we have a success disaster.

We’ve got two choices: Either we make the addresses bigger or we make them have local meaning.

If you have local meaning, then you don’t need as many. You can have a lot of addresses globally, but you reuse the space, some kind of spatial reuse.

This was the second paragraph. It’s an eye chart; you don’t need to read it. There was one thing that I got right that’s completely obvious, that people aren’t going to change. They’re – IP addresses work for them. They’re going to keep using them. They’ve got lots of other things to do besides renumbering. And so when you roll out a new system, you better have a transition plan because the old addresses are going to be used until you take them out of people’s cold, dead hands. You’re stuck with them. And the transition plan is probably going to involve some kind of address translation. So this is obvious.

This was the particular model that was used in that paper. Again, it’s another eye chart and you really don’t care. It worked by basically hooking the DNS – you make an addressing domain. It doesn’t have too many hosts in it, 10,000 or 100,000 scale hosts, but you give it the entire 32- bit address space. So you give it a billion addresses and that means that it’s got lots of bits to use to describe the state for talking to things outside of it. And you want to do that to have a lot – a small number of physical things going into a large virtual address space, so that you don’t have to keep cycling the state. Putting a whole network behind one IP address is really stupid because you have to steal the ports and do other things to keep the state information. You can solve that problem by embedding a small physical space into a big virtual space, and then you do translation at the border, like NAT always does. And in this case, you use a request to the route DNS for the names, which are globally unique, to set up the translation tables.

So I presented this model. In this case, I happen to know what Jon thought. He did a good job controlling his enthusiasm. His architectural sense was certainly much better than mine. The reason that he was not particularly enthusiastic was NAT really fundamentally violates some of the core assumptions of the Internet, the end-to-end principle, and that core assumption is what keeps the core simple.

Now, NANOG people toil every day to keep the Internet running. And so saying that the core is simple is, you know, a bit of an overstatement. But if you didn’t have the end-to-end principle, if you didn’t have a fairly well controlled state and no edge state in the core of the network, it would go from tolerable to a disaster. And this is really well described by Randy Bush and Dave Meyer in RFC- 3439, which is well worth a read and I’m not going to try and repeat it. The thing is if you do NAT, you’ve got this very detailed edge granularity state that’s sitting inside the core, sitting at the borders that you have to use to translate. That state may cycle fairly quickly. No matter what it’s a lot of detail, but you have to have it right and you have to have it right multiple hops through the core. It’s really hard to manage. It’s really hard to debug. It’s really easy to break.

You’ve got a second issue when you deploy NATs that addresses show up a lot of places besides in the sourcing destination of packets. Now, my feeling is this is a massive protocol design error.

It comes about because you want to do out-of-band signaling.

So something like setting up a VoIP call, SIP, the signaling path, wants to talk about the media path, but it doesn’t want to be in the media path. So it sends the addresses saying I’m going to call you from this IP address to your IP address on these ports. So it puts transport information inside the data part of a packet, not in the header part of a packet. But that means that if you change the addressing information along the path, what’s inside the data part of the packet doesn’t agree with what’s in the header of the packet and things don’t work. So to bridge protocols that do out-of-band signaling you have to put in application-level gateways. They have to understand the end-to-end protocols inside the core of the network.

This is really hard to do. It breaks privacy models, breaks protection models, breaks authentication, data integrity models. And it makes these new middle boxes devices that you have to rendezvous with inside the network.

So there’s no actual need to do this, right. It’s – my feeling is when a protocol engineer does signaling by putting network-level addresses inside of a packet instead of some sort of higher level identifier that identifies the call, they’ve just demonstrated they’re incompetent and they should be shot. I mean, so we’ve got a lot of spares. There’s many people in the world.

So I think that’s all I had to say other than I’m sorry. Don’t do NAT.

What Did Jon Say About How to Handling the Addressing Challenges That Would Face Us One Day?

MR. PLZAK: Lixia.

MS. ZHANG: So I apologize. You know, I didn’t really work with Jon for a very long time. I couldn’t guess even what he would have done today. But what I can tell you is what he did say during the short time I actually worked with him.

You know, people say that for your career it’s not as important how big your brain is if you’re being in the right place at the right time. That’s what I did.

I landed in MIT back in 1981. And, of course, you know, in that place you got a chance to meet Jon. However, the only time I actually worked with him very closely was the next story I’m going to tell you.

So give you a little background. Back in 1994, you know, I think the (off mike) working group just got established before the fall ITF meeting. And at that time, you know, multihoming was coming up very quickly. Routing scalability had always been a concern and multihoming just made it, you know, a much bigger concern. And consequently, a few proposals were on the table to say now we’re going to develop a new protocol. How are we going to do the address assignment to make the routing scalability work better?

That’s also the year I got elected to be on the IAB. And you know what the IAB normally do, you know, fixing the thing. The IAB decided to set up a small study group looking to this issue of how we should structure IPv6 address to handle this stuff, especially given the various proposals on the table. That, I’m going to show you later, was really all the different colors of the design space.

Now they’re very close. So this is actually the slides I found thanks to Google on the Internet. I long lost it myself. I can see that the group started in the early ‘95 with my first time in the Danvers ITF. By the way, that’s not a typo. That’s not Denver. It’s Danvers in Massachusetts.

And in the next I shall show you who were on this study group. So Jon was one of the six members. When I showed the slide to Rodney this morning, I instantly noticed the last bullet. And said, yeah, of course, this study group members would have very different opinions. So I hope that you notice that, too. And me as an organizer, you could tell that I was facing a very challenging job.

One thing I want to tell you that Jon cared a lot about IPv6. He was very busy, but when I contacted him to be part of this study group, you know, he willingly agreed to serve and he attended all the meetings. We had eight conference calls spread over three months. And at the – so the slide I showed you was after three months of study we gave an interim report in the July IETF.

So the proposals on the table that were investigated are the following three. The one is we just follow IPv4, do provider-based addressing assignments.

And the next one is Dave Clark’s proposal. For people who are interested in the details, I put you the (off mike) of that message he sent to the IPng meeting list. You can, again, you know, Google will get you there.

Then Steve (off mike) also had a proposal about Metro-based addressing, and there’s a pointer to his slides, the summary. I want to also mention that the map-and-encap idea was floating around at that time, too. I think credit to Bob here, he actually loaded it up in RFC-1955, just shortly after, but that was not seriously discussed in our study group.

So I got the eight meeting minutes and found some quotes from Jon about his position with regard to all the various proposals. The very first thing he said, guys, you know, you call this group like an addressing structure study group. You’re really solving the routing problem.

And about the issue of the IP address coupling with the transferred IPs and Jon made a very clear statement. He said that, you know, transfer layer ID is not really an issue that’s burning, that we have to solve it s today. You need to first figure out what you’re going to do with routing. And once we decide what to do for the IP addresses, then the transfer people are going to figure out what they will do about the transfer ID issues. I think that’s really a very clear insight.

Thirteen years down the road, I believe that it’s still not very clear in many people’s minds about which problem should go first and get solved. Which problem, that’s just a follow-up.

And this really directly quotes. Only one thing I’m not exactly sure was about the word of “must.” For those people who worked with Jon, you know, he was a very soft-spoken person, who wasn’t that assertive. So it must be that when I was taking notes I put my own emotion into the notes- taking.

But Jon was very firm about avoiding circular dependency. He repeated this position several times through our eight meetings. He said that we must avoid circular dependency. He believed that any solution to the routing problem that depends on information one has to gather from DNS is one example of such circular dependency. He stated again and again that we must not depend on the DNS to operate the core.

I think that’s just I quote something that Van said earlier. Jon was very firm on the architectural principles. He said that it’s very important to keep the uniqueness property of the IP addresses and it’s very important to keep the source and destination addresses intact as they go from the source to the destinations.

So I was just going to stop my short report of what I learned from Jon during that three- month study group lifetime, but, well, I cannot help myself. So I’m going to quote some of the things.

This was the minutes taken out of that plenary talk. I think it’s also I quote some of previous people’s – I mean, especially Van’s talk.

That is you can say whether this is right or wrong, but the fact is up till now – this was back in ‘95 – the IP address has served as an invariant, unique identification for the end host. And let’s not mention about whether it is we use it or not. So the fact is that as a result, nobody today has a clear – has a complete list of all the possible places in the protocol architecture that have the IP address hard-wired or embedded.

So contradicting to some people’s belief that we number and just (off mike), all you need are some kind of wonderful tools. The dynamically changing IP addresses as required by provider-based assignment, changes the architecture we used to know and causes serious problems. I want to underline the following three words: At the user ends. And that’s the thing I think Jon also expressed a very strong feeling about that.

So I will just end up here.

MR. PLZAK: Thank you, Lixia.

What would Jon have done about the addressing challenges currently facing us?

MR. PLZAK: Paul Mockapetris.

MR. MOCKAPETRIS: Hi. Thanks. I think I’m here in the role of having known Jon because I really didn’t have that much to do with the various addressing issues, so I’m going to be an amateur about that. I reported to John for a while. He reported to me for a while. I don’t think either of us were very good at that reporting relationship, but we got along just fine. I’m going to take a little slant about this that I think is different from kind of the ultimate solution.

What would Jon say? Well, I think what Jon would say is, well, you have to figure that out.

You know, sort of you have to think about that problem, have to figure out what to do. And I think the problem that we have today, and I think Jon would agree with me, is we ought to get this IPv6 puppy on the road so we can figure out what to do next.

So, you know, what’s the worse that could happen? People could sell IPv4 addresses. Well, the world hasn’t ended. I don’t think that’s what’s causing the financial crisis and addresses are being sold, so there’s no big problem there.

I think what could happen is that URLs could become sort of the new addresses. Google chromes the world. And what I mean by that is I was very surprised to have my kids go to this charter school and the teacher said, you know, I told your boys to use the Google bar instead of the direct addressing bar on the web browsers and they’re not listening to you. And I said, so let me see, you’re telling them not to use domain names, right?

I mean, one of the things that could happen here is that we could just end up in a world where everything goes through port 80 and URLs are out there and the mapping happens behind the scenes and we end up in sort of a walled garden that we built ourselves out of the Internet. I don’t think that’s where we want to go.

And it’s kind of interesting that there’s lots of people that they teach these days you just click on links. You don’t need domain names or addresses, you just click on these links. And I think this is actually sort of the world we could come to if we don’t kind of move this all along. You know, and Google could become the new ICANN by selling, you know, sort of links and search terms as opposed to domain names. I think another thing that could happen is we had sort of a red-blue split, like we do politically here in the U.S., where there’s some IPv6 areas, some IPv4 areas and imperfect translation.

And I think the thing that would really annoy both me and Jon is we’ll miss out on things we never know. If we managed to clean up the architecture and be able to have the addresses, I mean, I’m not convinced that the Internet is going to melt down if we don’t have these addressing principles restored, but I think we’re going to miss a lot of the future we might have enjoyed otherwise.

And so that’s why I think it’s important to try and figure this out.

So I think the first step is to figure out how to make IPv6 more attractive because I think that the large address space that it uses, if we correctly think about it, will last for several lifetimes, and we could disagree with that. And frankly, I think that those of you that are in the Internet world ought to realize that your work doesn’t last forever. I get this question all the time about do you think DNS is going to last forever? And I say no. You know, if you want something that’s going to have a few hundred years’ life span, you know, start writing music and compete with Mozart because the IP technology is all going to get replaced.

So I think what we need to do to make IPv6 more attractive and get this along is have a plan. I was – I got upstaged by Jon yesterday. He had his plan. You write the plan in the passive tense, so it’s not really clear who’s saying it. That was another great Jon technique that kind of – you know, there’s never an active thing, so you can say X says that you should do Y. It was decided that X should happen is sort of the style.

We need to finish our homework. You know, there’s a lot of things that don’t work with IPv6, mostly the supporting stuff. I’m all for using researchers and the government as lab rats. Make people exist on IPv6 networks so that they’re forced to work it out. There’s more radical messages – measures.

Historical precedent. It turns out that I spent almost two years at a company called @Home that was doing Internet over cable. And this was one of the great addressing controversies at the time although I didn’t know it. I only found out about it a year later. Because what happened was on, like, my fifth day, I was told, well, we need an IP address for every cable customer in the world and we’ve got our lawyers all queued up and we’re ready to go. We’ll go make them give us a big block of addresses. I said, well, why don’t I go talk to Jon about this? Okay?

And so I went in and I said Jon, you know, the cable guys need a lot of addresses and they have a lot of lawyers and they have a lot of money and they buy congressmen just like the telecos and so forth. So, you know, telling them they can have two Class Cs isn’t going to work.

So what Jon said was, he said, well, what do they want?

And I said, well, a Class A to start. And he said, well, I don’t know about that. So we did this compromise where nobody had ever sub-netted a Class A before.

So he says, well, I’ll give you the first chunk of a Class A. You can lie to the cable guys and say that they have it all, but in reality we’ll just dribble it out. Right? And, you know, we’ll see how it goes.

So, you know, we’ll give you this big swath of land that’s unclaimed. When you try and use this little chunk, you’re probably going have to debug a lot of routers and other things, and so forth. So, you know, Jon kind of dangled the carrot of this big chunk of address space out there in return for debugging some of the technical problems.

I think, you know, you’ve got this address space in v6 and you ought to be thinking about using it kind of more creatively there in order to get people to solve the problems. You could play this game again. It was really kind of interesting.

So after we kind of made this deal, you know, I was reading later, you know, as I was, you know, ego Googling myself, Paul Mockapetris, and it says, you know, Internet criminal has, you know, sweetheart deal with Jon Postel to get infinite address space. You know, which really isn’t what had happened, you know. And then there’s, you know, a variety of back and forth. It was just so fun to read about that, you know, how I had done all these evil things six months before.

At any rate, I think there’s other things that we ought to think about fixing along with this addressing stuff. I think that one of the biggest crimes we’ve committed, and I think Jon would agree with me, is that we have this notion that the MTU is in – measured in bits, not in time. You know, if what we did is we scaled the size of the MTU to the size of the link speed, you know, instead of having Ethernet packets that take – that are much smaller than ATM cells were when ATM was in its heyday, right, we need to get bigger MTUs.

I mean, the DNS suffers because, oh, gee, these digital signatures are too big. I mean, the transmission rates are huge these days. That shouldn’t be a problem. You know, we ought to think about scaling some of the other things along with the addresses.

You know, so I think the more speculative dimension is how do we use the resources of the address space and IPv6 to encourage its adoption and get things moving along. I think we ought to ask ICANN to let these new TLDs be IPv6 only, though. That might be a fun thing to do.

You know, but this gets back to the, you know, recruiting of the lab rats and getting the current generation along so we can learn by the evolution. Because I think that – you know, I believe that protocols advance, and I believe Jon did, too. You build stuff, you try it out, you see what happens, and you move on. You don’t, you know – intelligent design where you have these 13- and 15-year life spans for the design of IPv6 and DNS-sec and stuff like that is really not the way we should be evolving things. I may have gotten the years wrong by a little bit.

All right. Your idea goes here. You know, Warren Buffett, I was reading his book, I thought he had a lot to say about this problem. You know, his mentor, Ben Graham, said you can get into way more trouble with a good idea than a bad idea. And Warren explained that because you forget that the good idea has limits. Okay? I think we’ve got a great idea here. I think we ought to understand how we can leverage it in very limited ways and move forward rather than having a huge hit.

And I think that’s sort of the third thing is, you know, life is like a snowball. You’ve got to find a really long hill that’s covered with wet snow and you start rolling the snow. And I think that’s the kind of approach we should use in getting v6 and its addressing out there.

I think long term, this is going to offend some other people, we ought to think about, you know, IPv6 addresses as something that we translate into the routing via whatever infrastructure we want. Right now I think part of the problem with addresses is that we’re trying to figure out how to allocate them and we’re trying to figure out how to aggregate them and all that other kind of stuff. Maybe what we need is a layer of indirection between the address and how it gets routed and we need to think about paying for that. We can argue about that later.

Okay. So putting it all together, remember, you’ve got to start at the top of the snowy hill. We ought to figure out the easy places to deploy IPv6 and the easy places to motivate people to do it and start rolling up the ball from there rather than at the bottom.

Nobody said it would be easy. You know, you’ve got to make it as easy as possible. You got to simplify this stuff. And I think that, you know, IPv6 and, you know, the new address allocation mechanisms are a little bit like global warming. It’s going to happen if for no other reason than the unpleasantness. We’ve ought to figure out how to do it with as little pain as possible and perhaps stop some of the excesses.

The only thing I think that’s going to change this, although, you know, I think it’s going to take a long time, is whether somebody comes along with something like IPv9 or the next generation after it. So it may be unpleasant, but that’s the truth. And I think that we ought to do the evolutionary experiments now so we can think about what v9 will be like.

Thanks very much.

What Would Jon Do[about running out of IPv4 Addresses]?

MR. PLZAK: Bob.

MR. BRADEN: Hi. So I’m here sort of under false pretenses. Although I joined the TCPIP Research Group in 1978, shortly after it started, I haven’t actually been myself deeply involved in the addressing aspects. So I’m going to go full circle and go back to the beginning and find out how we got where we are now.

And I want to note that in answering the question what Jon would do, there are actually two different Jons. There’s the Jon who was the Internet guru, who would be concerned about practical issues and political issues and the reality, and then there was Jon the researcher, who liked to play with neat ideas. And they might very well come up with different answers.

So the fact is running out of address space was never a big issue. I can’t even – I can hardly remember its being discussed in any of early meetings. There were a lot of other problems: Making TCP work at all, making routers work, interfacing LANs when they came along, when it was no longer the case that all networks in the world were ARPANET clones, the battle with X.25 and OSI for supremacy, making congestion control work. But Van came riding in and solved that one for us, fortunately. But running out of address space was not a problem.

So what I want you to take away from this slide is, if you go back to the Cerf/Kahn paper, 1974, and up through, in fact, through 1981, network addresses were 8 bits. And they were 8 bits because we could not imagine there would ever be 256 ARPANET clones in the world. The PCs had not been invented. LANs were invented, but were not in wide use.

It’s interesting that in August ‘77, Jon wrote an IEN commenting on Version 2 in which he proposed that addresses be variable-length in 4-bit chunks and that the forwarding be hop by hop, essentially source routed. And that’s an idea which I think surfaced then and died immediately.

So by the time we got to TCP Version 3, variable-length addresses and octet chunks came. But the text still said the first 8 bits will be the network address. And TCP 4 was the same issue. If you read the latest header formats in ‘78, the 32- bit fixed-length addresses appeared, but it still assumed the first byte was to be a network number. And again, in the first – the first separate specification of the Internet protocol is in August ‘79. And interestingly, the assigned numbers, I guess maybe the first assigned numbers document by Postel, RFC-776, network numbers were still 8 bits and he defined how those 8 bits were to be used and be mapped.

By nine months later the second assigned numbers, RFC-790, had classes A, B, and C. So in that time people had realized that maybe we needed some structure in the address space. But the research group, although they invented the class system, did not invent CIDR. If they had thought that exhausting the address space would be a problem, they probably would have, because it’s a kind of natural extension of class addressing that computer scientists would have thought of.

So I’m going to tell all, Danny. I distinctly remember the meeting where Jon and Danny were pushing for variable-length IP addresses. And Vint Cerf, who was at that point the ARPANET – the ARPA program manager and was, in fact, leading our effort, which was interesting, said no. It’s – variable-length addresses are too hard to implement.

Probably too inefficient. I don’t remember that argument, but, after all, this was the days of MIDI computers and they weren’t very fast. And I remember John grumbled from the back of the room and I believe Danny fumed, but that was the story.

Now, it’s important to understand the background of this. Vint was carrying on guerilla warfare within the Department of Defense at that point, trying to prevent OSI from completely killing TCPIP. And so he had real reason to be concerned about the implementability of TCPIP. And so I believe that was his argument and it carried a lot of weight.

So what would John do? I said it first.

MR. PLZAK: Can I just add to that? He actually – his writings, he did actually work.

MR. BRADEN: Yes.

MR. PLZAK: We are here today as a result.

MR. BRADEN: Yes, that’s entirely true. In fact, I think it went through three stages. The DOD accepted TCPIP, then they accepted OSI and replaced TCPIP, and then they said, oh, well, you can have either. And since there were no implementations of OSI in the world and lots of implementations of TCPIP, that settled the issue.

So I said at the beginning I had no idea what Jon would do, but I lied. I believe that what Jon the pragmatist would do would be to push for IPv6, which has been discussed by many others here, or else we ought to all need to find another line of work. It’s possible that he would consider reintroducing variable-length addresses.

Notice that if we had done variable-length addressing in the beginning, then all the places where IP addresses appear in application layer protocols would have to deal with variable-length addresses, and so there would be no horrendous transition. No NATs would be necessary, no application layer gateways and all that stuff. We would just be able to expand the address space and everything would still work. But, unfortunately, history didn’t work out that way.

Thank you.

Closing Thoughts

MR. PLZAK: So I’m going to add my own thoughts, though I’m with our esteemed panel, I’m going to work hard to try, hopefully, say something intelligent after so much good stuff has been said.

I would note that I think I’m the only one who actually has a gray beard up here. I thought we were supposed to all have gray beards, though Lixia has a very good excuse.

So I was first involved in the Internet after – before it was defined. I did some at the end – started working on this stuff at the end of the ARPANET and beginning of the Internet when I was at BBN, and worked with Jon and the folks at ISI. You know, we were in Boston and out here in L.A. and got to have lots of great meetings up in the ISI tower with a great view of Marina Del Ray. I always liked that. So it was very – it was, you know – we had no idea what the Internet was going to turn into.

One thing I particularly remember about Jon, and actually as I think about it, it says a lot, after one of the meetings he gave me a ride back to LAX so I could fly home. And I think there had been a – recently been an earthquake out here.

And, you know, one thing I noticed is he had an earthquake – you know, emergency earthquake kit in the back of his car. And so I think Jon was always very prepared for things that would happen. And, you know, I think that in some sense, you know, it was a very practical thing, not a theoretical thing.

And as one of the earlier speakers said, you know, I think he would want us just to go ahead and implement.

Where I got involved in this was, you know, in the IETF, at least. You know, we started to see that v4 was having address problems. I think at the time it was really running out of what we then called Class B addresses, but, you know, we could start to see there was a problem and did realize we needed to do something about it. I think in hindsight, for a lot of reasons and including NAT, our timing was a bit off. It wasn’t quite so pressing. But I think we’ve also discovered it took quite a lot of time to actually build something new.

We probably suffered by making it more complex than it had to be. But, you know, in today’s Internet, getting something deployed everywhere is actually pretty hard. And at least I’m personally terrified of thinking we have time to start over again with that.

Another thing is that, you know, before IP sort of happened and became ubiquitous, we ran this other protocol on what was the ARPANET and a few other nets called NCP. And there was actually a transition from NCP to TCP. And some of us actually still have the buttons to show we survived it. And, you know, just as a note to how different the world was, this happened basically, you know, in the ARPANET before turning off the – I don’t think they were called ports, but links that supported NCP. And so we basically made it so you had to use TCP. And there was a couple of test days and a couple of – maybe a test week before that. But that’s how the transition happened. I don’t think we can do this again. But, on the other hand, that’s at least one model for the way it was done then. And Jon was clearly involved in that.

So my last sort of thought here was that – and Bob alluded to this as well, that when we started working on IPv6 IPng, the world was pretty different and the notion that the TCPIP Internet was going to become large and important and commercial and successful was still a pretty radical idea because it didn’t have the supportive governments. It didn’t have the support of, you know, what was the business. You know, AT&T I think wanted to build a network out of IPX or something like that and which had nice long addresses, but very short network parts.

And so, you know, the thing Vint did behind the scenes at ARPA and other people did, and some vendors who implemented it as part of their networking stack, like Sun, actually had a big impact on this. But it certainly wasn’t – it wasn’t at all guaranteed that TCPIP was going to be successful and become the information super highway.

You know, and then the ATM folks came along and thought all problems were going to be solved with ATM. And so, you know, it was a very different world.

And so, in some sense, I think even defining IPng was actually helpful. Because one of the big criticisms at the time was that TCPIP didn’t have a future, was going to run out of addresses. And so I think by even defining IPng IPv6, we actually helped move the world to the Internet and made it possible that, you know, we are all here today having this nice, you know, nice kind of discussion. It’s much nicer to have success problems than, you know, all be working on ATM or something.

And so my conclusion is that, you know, if Jon was here to say what we should do, I think he would just say we need to move forward with what we have and not – you know, it’s – the time for debate is over. We need to now deploy it and solve the problems.

Open Microphone

MR. PLZAK: So with that, I’d like to open this up to questions for the panel. I’ll try to moderate, so please come to the mics.

MR. MANNING: Bob.

MR. BRADEN: Yes.

MR. MANNING: We used to talk –

MR. BRADEN: Introduce yourself. I know who you are.

MR. MANNING: Bill Manning. A couple years ago I was sitting in a large (off mike) with Dave Favre. And Dave was educating me as Dave does to pretty much anybody who sits down with him. And he said, you know what we should do is about every decade or so we should pull out all the failed bad ideas and re-examine them to see if the assumptions still hold true, because they might actually be the best ideas. So the idea of variable-length addresses seemed perhaps not the best idea at the time. Being fatalistic and just moving forward without actually doing the interesting rethinking about how to solve problems in a novel way seems maybe pedestrian to me. I think that the variable- length addressing thing is actually very cool and might actually solve the problems in the longer term than just making these bigger and bigger.

So for the panel, are bigger addresses really the way to go or should we make things (off mike)?

MR. PLZAK: Anybody want to take a cut at that?

MR. COHEN: Yeah. I think we have two examples for variable-length addressing. One of (off mike) are the URLs, which are variable lengths. And the other one is global telephone system. Not the U.S. telephone system, which is fixed, 10-digit, but the global (off mike). And the global telephone system sometimes (off mike). It worked very well for many years (off mike).

So again, it you should not sound this crazy (off mike) 15 years ago, 30 years ago.

MS. ZHANG: I think I talked to someone. I talked to someone (off mike) and it’s way too early to (off mike) in public without giving the question he asked.

This is the dilemma. That is for every successful system, if they are successful, they’re going to grow beyond the dreams of the designers. So (off mike) conversation is not (off mike). So now we need to compare (off mike) by the time we (off mike) IPv6 address, what are they going to do? So between now and then, we should (off mike).

MR. HINDEN: I want to throw out that you can view an IPv6 address as 128 bits upper length. So it’s a variable-length address with a maximum being 16 bytes. And you can do that, you can do variable-length addresses. It’s a hell of a lot of space. And you can do an address assignment plan along the lines that Danny suggested where the use of the bits inside the address is variable. You just have to do like the phone system does where you fix the top level and each level of the address tells you how the lower levels were structured, and the levels are interpreted. I dial a country code. Country codes have to be interpreted the same all over the world, but the rest of the addresses (off mike) to that country and it’s got it’s own internal conventions. And that’s something that you’ve got (off mike) bits (off mike) in 1986. The discussions so far have been in this (off mike) and special addressing plan (off mike) top level Internet (off mike) Metro and the Metro (off mike) and all the rest of it. But the discussion so far has been, well, we’ve got this 128-bit pie. Let’s figure out how to chop up the whole thing rather than doing more variable ideas of interpretation of particular fields of particular parts of the hierarchy.

MR. MOCKAPETRIS: I guess the question of whether or not variable-length addresses are something we should be worrying about now, to me it’s not the most important thing. I think that the (off mike) addresses are big enough so that several generations (off mike) all be temporary.

I think that if you take a look at, you know, the phone company as an example. Yeah, these variable-length addresses are the same. But, for example, all of the phone companies of the world, pretty much country-by-country, have totally different systems for how they do number reportability. They have totally different systems about how they may route mobile phone calls. Part of the problem with addresses is that we’re combining the way that addresses are allocated with the way that packets are routed. And frankly, I think we ought to think about just splitting it out:

Have addresses be the things that are allocated out and then have another layer of indirection, which may or may not be there. There are maps to some identifier, which you used to do the routing, so that you have that additional layer of flexibility.

But I think, you know, regardless of how you want to approach the problem, I think that the challenges for addressing (off mike) of the network would increasingly (off mike) the populations and lie elsewhere rather than whether we’re running out with this (off mike) v6.

MR. PLZAK: Anything else? Okay. Next, Vince.

MR. VINCENT: My name’s Vince (off mike). I currently work for Cisco, but I was one of those people with – pulling arrows out of his behind back on January 1, 1983, also.

But just to follow up on what Paul said yesterday. He said what I was going to say before I asked for the microphone. I think the focus on whether 128 bits is enough or whether we need variable-length addresses kind of misses the point.

Basically we have a problem right now, which is that you have, you know, you have combined the locater and identifier semantics into one numbering space. And you can’t get things to scale both topologically for routing purposes and non- topologically for identification purposes in one numbering space. So if we don’t figure out some way to split that up, we’re not going to be able to scale the system.

Everyone likes to refer to the phone numbering system as an example of how they did this right with the variable-length number of digits. And that was actually great and that was actually true 20 years ago when things were strictly, you know, geographically assigned. But with the advent of number portability, those numbers are no longer routing identifiers. They are now used as an index into a database that then maps to a real topological, you know, (off mike) locater thing. We really need to learn from that example. You know, that why some people are talking about ID locater stuff for the last the years. I encourage the members of the panel and the members of the audience to take a look at some of that research because it’s really kind of important.

And the whole debate over IPv6, number of bits, et cetera, again, kind of misses the point.

MR. COHEN: It was a beautiful paper that Jon (off mike) wrote, I don’t know, 20, 30, 40, 50 years ago about names, addresses, routing.

MR. VINCENT: And if you want the reference to that paper, go look at (off mike) home page. Because he actually has a bunch of references to that paper and a bunch of others that talk about exactly this issue. And this is really fundamental to networking.

MR. COHEN: Would you please repeat where to find it? Because I thought it was great pre- Google.

MR. VINCENT: Oh, yes. No, like I said, Google on (off mike) page and he has references on his page to that paper. And it’ll tell you how to find that paper and some other related papers on that topic.

MR. COHEN: And I recommend to everyone to read it. It’s beautifully written.

MR. VINCENT: Thank you.

MR. RYAN: Thank you. My name is Steve Ryan. I’m ARIN’s counsel. And I’d like to have each of the panelists give a yes/no as to what Jon would do about people who wish to monetize and sell their legacy address space. And if you could also just comment on how Jon would view such people.

MR. COHEN: (off mike) tell you what Jon would say because he’d say the FCC probably doesn’t allow (off mike).

MR. PLZAK: No one’s going to touch that? I mean, I don’t want to get in the way of a good conversation.

MR. MOCKAPETRIS: I mean, I think John wouldn’t have liked it. But, you know, I think that it’s a little bit late to start that battle about – you know, I was talking to somebody that in the addressing boards, you know, in Watergate they said follow the money. I think, you know, (off mike) say follow the address blocks. There’s lots of criminals. But, you know, we’re better at creating the next generation than we are at having war crimes trials, so let’s move on.

MR. PLZAK: All right. Let me ask it in a different way. So who here in this room is willing to give back their IPv4 addresses?

SPEAKER: The U.S. Government already has.

MR. PLZAK: Has, yes.

MR. CHRISTELL: Hi. I’m Todd (off mike) from (off mike). Thank you guys for the panel. It’s been fantastic. I observed three facts that seem to be in broad consensus that don’t congeal for me, so I want to take comments on that.

Fact number one is we should go ahead and get about the business of doing IPv6. Finish up the implementations, move to it. People seem to think that was a good idea, practical, what we need to do.

Fact number two is IPv4 and IPv6 are just different protocols that don’t talk to each other and they’re on the wire incompatible. In fact, number three is NATs are evil.

Could you guys discuss those three facts, please? Thank you.

MR. PLZAK: Well, I’ll start I guess. So yeah, I think NATs are evil. I mean, they’re not going to go away any time soon and they may be useful as part of the transition. But I hope if we pick up transition schemes that use NATs that there’s a way to transition away from it and it doesn’t become permanent.

Yeah, I think we should move forward with IPv6, and I forget your second question.

MR. CHRISTELL: Well, it’s just really a question about the fact that there’s no plausible transition plan to v6. There’s a reason people aren’t using it. It’s because it doesn’t talk to the Internet. And the only way to make the non-Internet part that we want people to move to talk to the Internet part that’s already full of the people and the content they want to talk to, there’s only one plausible solution that people started trying to roll out, which is NAT-based. So – and the history of NATs is once you roll them out, you don’t roll them back, right? It’s not like people are ready to rip out all the NATs they’ve put in or, you know – and all the comments about why NAT’s evil, everybody agrees with that and understands it.

And yet NAT sort of saved the v4 Internet because we didn’t get around to doing something else in the meantime.

So is NAT the only solution to a transition plan? Is there any – on the first part of that, if we’re going to just roll out v6, aren’t we just going to end up doing NAT (off mike) as opposed to v6?

MR. PLZAK: Go ahead.

MS. ZHANG: Okay. I’ll answer the second question, the third question, the first question.

So it took a while how to (off mike) to activate v6. I was wondering, were you here for the last two days? (off mike), right, exactly on that topic.

SPEAKER: No, (off mike).

MS. ZHANG: Yes. So you must (off mike) talking to people and, therefore, missed the presentation.

The second thing is about NAT. I honestly (off mike) that they wanted NAT (off mike) up. I was a strong opponent, but years have passed by. I realize what I didn’t understand about NATs. So recently (off mike) paper. You can just Google on my name and (off mike) point to my page (off mike). I think the first or the second entry point to that paper. The paper is a retrospective view of NAT. It reflects my personal position of what I have learned.

Regarding IPv6, I think (off mike) if you want to keep the current of IP architecture, then we are out of (off mike). No options. No.

MR. PLZAK: Anyone else want to answer?

MR. MOCKAPETRIS: Yeah. I mean, I think what I want to say here is that, you know, we’re not going to have NAT control like some places have gun control and, you know, kind of run around and say, you know, you’re not allowed to possess a NAT anymore. You know, it’s incumbent upon us to create an IT world that’s better than the compressed IPv4 world. And it may be that the commercial forces that are out there that want to turn the Internet into a walled garden of advertising, you know, will kind of get their way.

I think, you know, we have to create a better future here and we have to think about using a combination of carrots and sticks. Carrots are futures that you can implement on the v6 that aren’t available on v4 and sticks are things like NSF could say, well, all you researchers that want to contemplate the future 15 years out, use IPv6 exclusively or, you know, have 20 percent less funding and pay for your own networking. You know, things like that, need more lab rats, to get out and actually debug this. Because nothing like actually using stuff serves to debug that. Papers don’t help. It’s actually using it that helps.

It’s going to be a long slog. I think that address exhaustion may provide eventually the spur that’s needed to create the tipping point and all like that. It would be nicer if we could think about other services and applications that would move that along sooner.

MR. PLZAK: Anyone else? Any other questions?

MR. COHEN: This is an answer to a question that was not asked.

I find that there are three major great innovations in the CCNS we have in is the Internet. The first one is the success of IP because in RFC-791 there’s no distinct performance measure. It doesn’t say anything about how big the packets are. It doesn’t say anything about how many bits per second and technology. This separation of technology and performance for the protocol is what is probably the secret to the success of IP.

The second thing is the layering. And the third thing is that IP say that if you put addressee on the packet, it will by magic arrive to this address. IP doesn’t tell you how to route and how do that. And I think that if you’re lucky, that separate groups work on IP, TCP, some of the people who worked on routing and delivery, and actually delivering the packets. IPv6 doesn’t believe in it, in the separation. And it’s interesting to see why.

MR. PLZAK: Bob.

MR. BRADEN: One other comment I’d like to make. TCPIP succeeded – well, if TCPIP had – if it had had to grow under a commercial basis solely, I don’t think it would ever have happened. It happened because the federal government supported and nurtured it until it was ready to be transitioned to commercial use. And someone once or twice today suggested that the IPv6 promulgation would be aided if the government formed test cells and got the stuff debugged and shielded it until it was ready for much more broader distribution. I think we should think about that analogy.

MR. CASSIMIRE: Thank you. Nigel Cassimire from the Caribbean Telecommunications Union.

I heard a comment from one of the panel, I forget which one, that it was too late to get into putting some hierarchy into the IPv6. And I was – we have so many v6 numbers and so few users (off mike) there should still be a way to find – (off mike) be able to find a way to find some hierarchyinto the use of it and it may have benefits for routing, scaling, and so on.

So I just wanted – I’m just trying to (off mike) a statement that it’s too late to do it and if that could be explained a bit little more.

MR. PLZAK: No. Well, I think Dan was suggesting that you could actually do variable- length addressing inside the 128-bit address. And, in fact, you know, if you notice, the allocations are all, you know, in one block. And the intent of that was to allow other things to happen in the future once we know what those are.

MR. ROTH: (off mike) Owen Roth, (off mike). I apologize, it’s my first NANOG and first ARIN so I may have missed this from previous years. But it seems to me that we’ve been talking about how NATs are bad because they confuse the packet headers and they just are confusing to look at to troubleshoot, and IPv6 is good because it’s easier to look at. And we would have liked to have variable-length IPs using some other components (off mike) variable. It seems to me that’s kind of what NAT is.

So I’ve heard a lot about why we need to move to IPv6 over the last couple of days. I’d say maybe two-thirds of the presentations have been on that, so, yes, we have heard a lot about that.

What I didn’t hear this time around is why NAT is so bad. And I was wondering if there are perhaps a year or papers that I could look into more. I know it’s kind of (off mike).

MR. HINDEN: Take a look at (off mike), like on No. 3495, Dave.

SPEAKER: Yeah, something like that.

MR. HINDEN: Dave (off mike) Randy Bush wrote a great RFC expanding on the Internet architectural principles and –

SPEAKER: (off mike)

MR. HINDEN: 3439, sorry. And it talks about, from a very high level of general systems theory, why you want to keep some (off mike) in the core, why you want to follow the end-to-end principle, why you don’t want get coupling between different subsystems that tie together the DNS and the addressing the routing. And the problem with NAT is it ties together all of those subsystems and it – there’s a thing that you can consider either a bug or a feature. If you do this thing, if you have a problem that involves signaling, like telephony signaling, like FTP trying to negotiate where the data is going to go over a control connection, you end up talking about addresses at an application level. And if the interior of the network is translated in addresses, it can’t translate those because it doesn’t know how the application’s encoded them. So you start putting in application (off mike) gateways, but now you can’t do a useful security model because you’ve got to expose everything you’re talking about to the network, and you’ve got to involve the core to understand every application as you make new applications, so you can’t do something like the web.

And so that coupling, in any system, tends to make the system brittle. And with geographic scale systems, like world-scale systems like the Internet, it should really cause lots of fear and trembling. A huge architectural success of the Internet is the end-to-end principle pushed all the (off mike) out to the edge and let the core be simple enough so that we were able to scale it up to the size it is today.

MR. VEST: Hi. My name is Tom Vest. I’m going to ask a silly question and, hopefully, it will reveal something useful.

I found it very interesting that you conceded that Jon did some things in order to further the adoption of v4 over competing technologies. And so it sort of implies that there was a strong conviction that the TCPIP was a preferable technology, would actually be better for perhaps everybody, for some – you know, for his vision of the future than competing alternatives. And that that vision required some non – purely – some decisions, some actions which were not explicitly tied to specific technologies. We made the same sort of implication when we were talking about dealing with the (off mike) for cable ads, same things.

So it’s interesting, we’re kind of maybe facing a situation where a similar set of choices needs to be made. And where maybe some policy matters may have to be decided in advance, which would ultimately dictate which way we’ll go technologically. So, I mean, I think – so now, with the benefit of 15 years of hindsight, is the world better? Do we still think the world was better because we went with TCPIP over OSI or some alternatives? Was the call it the political or the institutional choice, was that the right choice? And was the fact that some perhaps not purely engineering decisions and actions had to be undertaken to cause that to happen, were those good actions? Thanks.

MR. MOCKAPETRIS: I mean, I don’t think we get a definitive proof because we don’t get to run the experiment. Right? But I think one of the important things to do is to try and figure out what the lessons are that we should have learned over the last 25 years of the Internet era that have a bearing in the future.

So, for example, the fact that there’s all of these different protocols and these different ways to encode data, was that all just, you know, kind of leading up to XML or, you know, I think what we should learn out of the last 25 years is the subject that should be addressed and addressed independently of parties because we’re so happy about the 25 years and just recording the history for historical – history’s sake. I think we should try and do more of that. But, you know, until somebody tries to attack those kinds of issues, I don’t think we’ll know.

MR. BRADEN: Well, those who remember history remember the IAB meeting in Kobe, which the IAB decided in their wisdom that OSI have evolved to the point where it was functionally equivalent to TCPIP or could be made so. But that’s (off mike) history.

But the TCPIP came about because the federal government, the Department of Defense, put in money. And money is what was the issue here, I think. They put in money and got together a bunch of smart people and said – they didn’t say – tell them what to do, but they just said do something. Figure out how to connect networks together, and it happened.

SPEAKER: Okay, last question.

MR. FAULKNER: My name is Craig Faulkner from Layer Technologies. I’ve heard a lot about NAT/no NAT. And I was wondering if there was any discussion about just having dual stacks on everything to where IPv4 could gradually atrophy and IPv6 could gradually grow in a more calm fashion.

MR. BRADEN: Well, that – so that was the original ITF transition scheme, but the problem is that we seem to – the idea was you get that done before you run out of v4 addresses, and I don’t think anyone believes that’s going to happen anymore.

So on that note, I think we’ll wrap up. And Ray was going to do some closing remarks and get you on to the next session.

MR. PLZAK: Thanks, Bob. And I personally want to thank the panel for taking time out of their schedules to be with us this morning. Comments that I gathered from people in the audience so far is that they really enjoyed your presentations and it was good to see all of you together again.

So with that, I’d like to conclude this session. And we will begin the ARIN meeting at 11 a.m. in this room. So for those of you that can stay on that hadn’t originally planned to do so, please do so. Otherwise, please join us remotely. And with that, I will say thank you very much.

Sponsors