ARIN XXI Public Policy Meeting
Draft Transcript
Monday, 7 April 2008

"This transcript of the meeting 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."

Table of Contents

Meeting Called to Order

MR. PLZAK: Good morning. Hey, we're awake. Good. Welcome to Denver. Welcome to ARIN XXI. The characters you see on the slide are actually part of the public art of Denver. If you wander around Denver, you will see all these things someplace out in the open, so if you get a chance to get out and away, avail yourself of it. We'll be showing you more of these figures as we go through the presentation this morning. So first of all, who's here? Well, we have the Board of Trustees, John Curran, Scott Bradner. Lee Howard is not here today; he had a last-minute personal matter he had to deal with. I'm here. Bill Manning, somewhere out there. Paul Vixie, up here, and Bill Woodcock, out there someplace. Ah, there he is. Okay, we have the Advisory Council, they are all here. So if I could have them all stand up please. And later on I'll tell you how I can find them.

MS. ARONSON: We're all right here.

MR. PLZAK: No, when you're not in this room sitting at a stage where they can actually throw stuff at you, they still will have to be able to find you. Anyway, so they are all here. I'm not going to go through the names, but please take advantage and talk with them. They want to talk with you. The NRO Numbers Council, three people, would they stand please? Jason, Marty, and Louis Lee. Okay. And all the RIR colleagues, you don't have to stand, but there's a lot of them here. We had an RIR board meeting -- not a real meeting, it was a workshop, if you will, on Saturday, so we've got people here from all the boards. All the RIR CEOs are here, so this is your chance to talk to people from the other regions to get a better feel and idea of what's going on in the other regions. And staff is here, all the directors, would they stand, please? And they also would like to meet and talk with you. And we do have one new addition to the staff, and that's Cathy Handley. She's our Executive Director for Government Affairs and Public Policy. She used to work with the Department of Commerce.

So let's welcome our first-timers. (Applause) They met the members of the board and the chair of the board and the chair of the AC and people from the Numbers Council staff yesterday at a first-timers luncheon, and they learned some things about ARIN and went through things yesterday. And they now get a chance to win something, so they completed a survey and so now we have a drawing for a prize. So you've got to be present to win. So Tom Byrnes -- Jim Byrnes? Okay. Jennifer Wagner. Too much foosball, I think. Ah, here she is. (Applause) And here it comes. No, it's not coffee. And it is a set of speakers. Jason. Okay, going on with who's here. Here's our attendance stats. We had 155 people registered, distributed as shown. Also, we've had 35 remote participants registered, and we have 55 people as first-timers. So welcome. Our sponsor, WildBlue. (Applause)

Now, you've all received a packet when you checked in at the registration desk. It's got a lot of things in it, and on the right-hand side, you'll see the discussion guide, which has the policy proposals and the policy process in it. You'll find a copy of the Number Resource Manual. You'll find the meeting program. And you also will find an errata sheet to two of the policy proposals. This reflects changes that were made after the policy proposal text was published. You'll see a little flyer, that says, "Get a Handle on IPv6." We did the pre-game show for it yesterday, and the main event will be on Tuesday. This will be an IPv6-only network. Give you an opportunity to go out and see if you can find sites that are -- which sites are IPv6 only. For example, you can go to the ARIN IPv6 site and see ARIN's WHOIS and so forth there, and anybody else you want to check out and see what your competitors are doing, it's a good opportunity. On the left-hand side, you see some information about other things that are going on. One of the things is we have Project X, which actually is a -- I'll go into it a little while later, but it's a demo of what we're working on for the improved website for interaction. You'll also see a call for reminding you you have a duty to vote and participate in the ARIN 2008 elections, and we've also included an update on our service levels. We have a service level commitment, and we periodically report to the community how we're doing. So if you have questions on any of those matters and so forth, please grab a member of the staff and we'd be glad to talk with you more about it. So the IPv6, the pre-game show was a success. A reminder is that the event -- the main event is from 5:00 to 6:00. As we said in the announcement, anybody that participates, we will have a small little goodie to give you. And you also should have a ticket, probably available soon, which is your ticket to the Project Live X demo. It'll take place in this room at 1:00 both today and tomorrow. That's the last half-hour of the lunch period.

Now, as always, we have the Cyber Café. This is your place to take a break, get connected. You can watch presentations there and you can get information, which leads me to surveys. We will be asking you questions throughout the meeting, and we do this in the form of little paper surveys. And to help you to be motivated to participate, we bribe you, because everyone that submits a survey gets put into a drawing for prizes, and there is a prize drawing at each morning and afternoon break. There are two names drawn at each break. You must be present to win. If your name is drawn, then you either get the chance to play the Wheel of Fortune or Plinko to determine what prize that you're going to win. At the end, we will have a meeting survey, and the prize for that is an Optimus Mini Three Keyboard. We'll announce the winner of the meeting survey on April 18th on the ARIN website. So there are a lot of opportunities for you to participate in surveys and give us feedback and information that we're looking for. But there are a lot of people that aren't going to win anything. Well, it ain't over until the swag is in the bag, guys. So we have a consolation prize. Any first-timer or Cyber Café. entry or meeting survey person that didn't win a prize at the appropriate drawing is placed into a drawing for a consolation prize. The consolation prize is this Apple TV. In the end, you can win by losing, okay? How about an "ah" to go with that "oh?" Beautiful. Okay. So that winner will also be announced on the 18th of April on the ARIN website.

We have three help desks. We have the billing help desk, the registration services help desk, and the Advisory Council will be conducting a help desk as well, and the dates and times are shown there. The registration services and Advisory Council, in addition to regular hours, are also available by appointment as is the billing is only by appointment. And if you want to make an appointment, send e-mail to the appropriate place. But, I've said before, if you want to find an AC member at lunch, that's a good time to get them, when they're feeding, you know, at the waterhole and so forth. Well, we tagged them. So at lunch, each AC member will have a tag sitting like this on a pole at the table where they're sitting, so if you would like to sit down at lunch with an AC member to discuss something, this is how you find them. Okay? It's a good chance for you to network with the AC and to provide your input into the policy process, your feelings, and so forth, so please have a good lunch with an AC member. They're friendly, they don't bite. Well, not all of them, not much. And those that do, not much. But bottom line is, they're here for you.

So foosball last night, third place trophy went to Scott and Scott. The second place trophy went to Oscar and Tom. The first place trophy went to Phil and Nick. (Applause) And the most coveted trophy, bringing up the rear, went to Nigel and Bernadette. (Applause) So congratulations to all of our trophy winners, and we hope you all come back next year. For those of you that want to practice up a little bit for next year, there will be foosball tables at the social for you to sharpen your skills a little more, or to seek revenge for that bad shot that happened where someone did something to you. So the social is "Death for Dinner." We're going to paint the town red. It's going to be a murder mystery. So was it Richard in the Cyber Café. with a Cat 5 Cable. Find out tonight. There's going to be food and beverage. There will be a buffet dinner, two open bars. We'll have a signature cocktail called the "Crime of Passion." For entertainment, we'll have a DJ and dancing. We have a game room. We'll have the "Death for Dinner" murder mystery play. And for those of you that are interested in basketball, I believe we're going to have a big-screen TV there for you to watch the Final Four. So something for everybody, I hope. We hope you're there tonight. It's a good chance to network with the people that are here at the meeting and have a good time.

On to the business of the meeting. We have rules. They're explained in your meeting packet. And I'm not going to go through them, just remember there's 10 of them. It's designed to give everyone the rights that they have, which is the right to speak, the right to be heard. So it's just as important for you to have the freedom to express yourself, but it's just as important for the person who's expressing themselves to be heard. And that's what these rules are designed to do, and the chair will enforce them. Let's look at what's going on. We'll have our regular reports from the RIRs, global stats, a Regional Policy Development Process Report, reports from the NRO Executive Council, the IETF activity report, and a report from IANA. Looking at the agenda, there are three proposals that are related to the IPv4 depletion. There are two that are related to IPv6; plus, there's also the IPv6 main event tomorrow afternoon at 5:00. We've got three other proposals that don't fit into those two categories. And we've got some special reports -- one on Internet governance activities, one's a result of a IPv6 penetration study. As most of you are aware, a while back, we conducted a survey of how IPv6 is being used, and this will be the report of the results of that survey. Then we have an interesting talk this morning about the adoption through the lens of economic security, IPv6. And then Tuesday afternoon will be a discussion led by Scott on the revised IRPEP. And a reminder, Wednesday morning is the members meeting. It's open to all. So don't miss the Project X Live Demo. Don't miss the IPv6 Main Event. And don't miss the social tonight. So at the head table this morning, we've got John, Scott -- in for Lee is Paul Vixie down there, not to be confused with the other Paul who has the privilege of sitting next to Cathy, and Dan.

Regional PDP Report

MR. PLZAK: And so now on with the show. And the first item of business is the Regional Policy Development Report. That will be presented by Einar.

MR. BOHLIN: Thank you, Ray. Good morning, everyone. I'm Einar Bohlin, the policy analyst at ARIN. And this is the Regional PDP Report, the Policy Development Process Report.

MR. BRADNER: Pretend you like the microphone.

MR. BOHLIN: Thank you. This is a worldwide look at all the proposal activity at all 5 RIRs, and so there's about 25 right now, different proposal themes. We've got it broken down into four categories: ASN, other, IPv4, and v6. And within those themes, we have some sub-themes or sub-topics. So I'll just go quickly through these. The ASN proposal is the global proposal about allocations from the IANA to the RIRs. And I think, it's recently been sent to the ICANN board, and the next step for that is the ICANN board to review it and adopt it. The other category is things such as directory services or policy development processes. In the v4 category, there are about -- well, there's nine proposals. The number in parenthesis are ARIN proposals that we're going to see here at this meeting this week, so if I go back to Other for a second, there are two proposals in that category, there are four proposals in the v4 depletion category, which is about the run-out of the IANA free pool. One of those proposals that we don't have, just to mention, was that APNIC recently, and it concerned the creation of an additional /8 to add kind of to the RFC 1918 private network space. And in the APNIC region that was discussed, and it was ultimately abandoned, and they suggested that it go more through the IETF process perhaps. There was a proposal also at the APNIC region about the minimum allocation size, and it looks like they're moving their minimum down to a /22. If we go to v6, the most number of proposals is about the topic of promoting the adoption of IPv6. We have two of those on our agenda this week. A couple other ones in there, there's two at the RIPE -- in the RIPE region, one of them would have the RIPE NCC allocate v6 space to every existing LIR, and it would also -- there's another proposal that would have the RIPE NCC assign v6 base to every INET number holder. And that's kind of RIPE-speak, so translate that into ARIN language, it would have -- a similar proposal would have ARIN assign v6 space to everyone in WHOIS, and allocate v6 space to everyone in WHOIS. I think that's it for this slide.

These are the eight policy proposals that are on the agenda this week. The purpose of this slide is to show you what kind of discussion, if any, might be happening outside the ARIN region. So for example, the top proposal there is the global proposal about the end of the IANA free pool. And it's a global proposal and it's under discussion at all five RIRs. The second proposal there, the transfer policy proposal, has a similar proposal in the APNIC region and the RIPE region, and they are discussing this idea in LACNIC, although there is no formal proposal as of yet. The third item is the cooperative distribution of the end of the IPv4 free pool. This is sort of an inter-RIR proposal. It would require at least two RIRs to adopt it for it to work, and it was recently presented at APNIC and abandoned. It will be presented at AfriNIC and at the next RIPE meeting. And the rest of the proposals, the other five there, are ARIN-only proposals. They're not really being discussed outside of our region. Here's some references. If you want to see really what's being discussed at the other RIRs, you can go to these sites and find a list of their proposals and what state they're in, are they under discussion, last call, withdrawn, abandoned, et cetera, and I'd like to point out the last item there, which is the policy comparison overview. The other day, somebody asked me what was the minimum allocation size at LACNIC? And I sent them to the LACNIC site. And then I remembered a better thing to do, when they called me and they said they found that, what's the minimum size for RIPE, I thought a better thing to send them to is this comparison document. Because if you want to be able to compare RIRs' policies very easily, you can go to this document and see, for example, all five RIRs' minimum allocation size or their initial allocation criteria. It's a very nice document, and we update that about four times a year. Thank you.

MR. PLZAK: Anyone have any questions of Einar? Okay, thanks, Einar.

Internet Number Resource Status Report

MR. PLZAK: The next report is the Internet Number Resource Status Report, presented by Leslie.

MS. NOBILE: Good morning, everyone. This is the NRO Joint Status Report. It is all five of the RIRs, who compile their statistics together and show them in a side-by-side format, as well as giving current status on v4, v6, and ASN numbers. It's prepared quarterly, so this was just updated on the 31st of March. We're going to start by looking at the total IPv4 address space and the status of each of the /8s. If you look at the left, the doughnut or the pie on the left, that's the total space. I'd start with a green, the not available space, there's 35 /8s held by IANA and the ITF for special purpose. There's 16 multicast, 16 experimental, and one each for private use, loopback, and local identification. If you go up to the left, you'll see central registry space. Ninety-one /8s were issued prior to the establishment of the RIRs. This was issued by the DODNIC, the SRINIC, the early days of IANA. Moving down to the blue, the RIRs in total have 89 /8s issued to them that they are currently issuing to their customers or have issued. So if you look at the bottom pie, the breakout of how the /8s to the RIRs are broken up, you can see how many /8s each of the RIRs have currently or have issued previously. Moving to the gray part of the pie, which is probably most interesting for most people, it shows that there's currently 41 /8s left in the IANA reserves. That is space that the IANA will issue to the RIRs for the RIRs to issue to their customers. So 41 left out of 256. This slide shows the IPv4 allocations from the RIRs to their customers, to the LIRs, and it's allocations only, not assignments. We started in '99. We took a slice from '99 through 2007, and you can see the growth trends up and down. The thing to take out of this, for me anyway, is the growth currently is in the APNIC region. APNIC and RIPE have been issuing more IPv4 space than any of the other three RIRs, particularly APNIC over the last year. They issued more than 4 /8s to their customers. That's the first time any of the RIRs have issued that much space. This is just this first quarter. We broke it out because it was getting lost in the previous slides, so this just basically supports what we've seen since 2007, with APNIC issuing much of the v4 space.

This is another way of looking at that slide. It's a cumulative total since 1999, how much space each of the RIRs have allocated to their customers, to their ISP LIR customers. And you'll notice that since '99, this cumulative total, APNIC and RIPE both have issued more space than ARIN. Previously, it was flip-flopped and ARIN had issued more v4 space, but at this point, the other two RIRs, the two larger RIRs, are issuing more space. This is the ASN assignments from RIRs. It says to LIRs -- this is actually incorrect. I have to get this changed. I'm sorry. It's to all of our customers. It's ASN assignments to all customers. It's end-users and ISPs. Again, up and down, ARIN was previously issuing quite a few ASNs. We've pretty much become static over the past few years, but the RIPE region has increased their ASN assignments, and the other regions, pretty static. A little bit of growth in APNIC and LACNIC as far as ASN assignments go. Again, this is just the first quarter, pretty much supports the previous slide. And this is the cumulative total, so ASN assignments. ARIN has issued more ASNs than any of the RIRs, but RIPE is following close behind.

This is a look at the total IPv6 address space. We started on the very left with the total pool. A /3 of the space is actually global unicast space that the IANA holds in reserve. That consists of 506 /12s. If you look to the right, each of the RIRs received a /12 in October 2006 as a result of a global policy. In addition, from that little blue slice, if you look below, prior to getting these /12s, the IANA was issuing /23s to each of the RIRs on an as-needed basis. So you can see that RIPE had gotten 15 /23s, APNIC 7, ARIN 5, AfriNIC 1, LACNIC 1, and 3 had been reserved or set aside for special purpose. Most of this space, most of these /23s, came from the larger /12s. When IANA did issue us the space, they gave us each a /12 based on what we had been previously issued in 23s.

This slide shows our allocations to our LIRs' ISPs, since '99, which was when we first started issuing v6 space, and again, kind of up-and-down growth. There was steady growth for a while and then a little bit of a decrease in some of the regions, but the large green bar is showing where much of the demand is for IPv6, and that is in the RIPE region. We're also seeing, though, an increase in LACNIC. If you look from 2005, 2006, and 2007, there's been quite a bit of growth in v6. In the LACNIC region and ARIN in 2007, we basically -- we more than doubled the amount of allocations we issued in v6 over 2006. So we've seen quite an increase in our requests in our region. Again, just the first quarter of 2008, with RIPE NCC issuing quite a bit of the v6 allocations. And this is the cumulative total. So we did two things here. On the left pie, it pretty much supports what we showed, cumulative total of number of allocations. And it's pretty consistent with what we saw, RIPE issuing more, APNIC and ARIN pretty even in the number of allocations, followed by LACNIC and AfriNIC. But when you look on the right, we actually counted the number of /32s that have been allocated, and when you look at that, it's pretty clear that RIPE and APNIC are issuing very large allocations, much larger than the typical minimum allocation size of /32, so there's many times when they're issuing /25s, /22s, /28s, and that counts for those large green and yellow areas. AfriNIC, LACNIC, and ARIN have issued very few allocations larger than a /32.

All of these stats are on the websites here. The raw data is on the links below, and the RIR stats, this presentation, is kept on the NRO site. And that's all I have. Are there any questions?

MR. LEWIS: (inaudible) numbers in the future (inaudible).

SPEAKER: Get closer to the mic.

MR. LEWIS: (inaudible) also associated with (inaudible).

MR. PLZAK: Just to be clear, Ed. You want to see the legacy address space broken out by region where it's residing?

MR. LEWIS: Right, (inaudible) years ago and I think each RIR should (inaudible).

MR. PLZAK: Well, the ERX project was revolved around distributing the DNS responsibility. Okay. But I just want to make sure that what you want to see, by region, is the legacy address space that's resident in that region.

MR. LEWIS: Right.

MR. PLZAK: Okay.

MS. NOBILE: Thank you.

RIR Update - AfriNIC

MR. PLZAK: We're zooming right along. Adiel, you're up. Next is the first of the RIR reports. This is the AfriNIC report presented by its CEO. And so, bon jour, mon ami.

MR. AKPLOGAN: Thank you, Ray. I will quickly take you through our activity report. It's a brief report on what happened in our region during the last few months. Since we started our activity, training has been one of our priorities, because we need to raise more awareness among our community around IP resource management, so this is how the map of the region looked like in terms of training coverage. What you have in orange is a country where we already had training activity. And our training program has evolved also a bit. We have added some other technical training such as DNSSEC and IPv6 to our training program. So we have LIR, IPv6, and our DNSSEC training. What we have in green are countries where we are planning to have training this year. We already started, actually. A few of them are becoming orange, also. So mainly, our goal is to cover the whole continent both on LIR training, and more importantly, IPv6 training. The result of this training activity and awareness activity is also seen in the growth in our membership, growth in terms of membership, also growth in term of allocation in the region. So since 2005, that we start our activity, we have more than 100 percent growth in our membership. Those new members are mainly new operators, but also people who were using IP address from their upstream provider and now are moving to become LIRs. And this remark is being accentuated this year. We are also seeing a very big growth since 2008.

This chart shows the IPv6 growth in the region since 2005, again, since AfriNIC started activity. This is up to December 2007. This year, we have allocated about 10 new IPv6 prefixes in the region, which also shows the interest that we are getting in the region in terms of IPv6. But one of the issues which is still there is the real usage of the IPv6 that have been allocated by AfriNIC. We are now at around 30 percent announcement of the prefixes allocated from the region, which is not that bad, but we want to -- we are working to increase this number by providing a direct support to LIR on how they can set up just like in (inaudible) how they can work with their upstream to announce their prefixes.

We have also reviewed our fee schedules since last year. We have -- for instance, for IPv6, we have renewed the waiver of the fee for IPv6 allocations to already existing LIR. We have also rearranged the fee for new LIR. That's our only IPv6 user. This category is mainly for legacy IPv4 holders that want now to have IPv6 address so they have to become LIR, and we have also set up a special fee structure for them. We had also some discussion with the academic and research sector in our region. And we have applied since 2008, January, a discount for allocation and mainly assignment to education and research network. More generally, we have reviewed also our fee schedule for LIR, mainly reducing for small area.

For those of you who were at the Durbin meeting, we have launched our LIR portal, "MyAfriNIC," which is an online tool to allow members to access and manage our resource. Since then, we have had success in the usage because up to now, we have about 200 people registered to use MyAfriNIC, which is way more than 60 percent of our membership, all our members. This portal also allows members to pay their bill online directly by credit card, and we are working now to improve this first version of MyAfriNIC and add (inaudible) future, which has been asked by users. But globally, it is helping, and where it's helping also is the new member process, because the MyAfriNIC portal improved the new member process, which makes a few thing automated. And since January, we have noticed that the membership, at least the request to become a member, has grown, and it will probably have an effect in our growth.

Policy in our region, a few policies have been ratified recently by the board. The new policy development process, we have now reviewed our policy development process to make it simpler, and have -- one of the main things we have set up is the moderator group, which is a group of people volunteering from the community that show -- moderate the discussion online and also try to initiate policy and help members to participate to the policy development process. The global policy about ASN allocation from IANA to RIR has also been ratified by the board. Two policies have been withdrawn from the discussion. The global policy for allocation of the remaining IPv4 space, the first version of this policy has been withdrawn, but the new one has been introduced on the mailing list recently. There are two policies that -- for that, the use of the latest /8 block from IANA to RIR. There is still the IPv6 (inaudible) central policy which is still on, not withdrawn yet, so that is it. I know that there are a few policies that are coming before our meeting in Rabat next month. That is it.

A few information about our upcoming meeting. The next meeting will be in Rabat from the 31st of May to the 6th of June. It is a meeting that we have every year back-to-back with AfNOG, which is the African Network Operator Group. Our second meeting this year will be in Addis Ababa, Ethiopia. And it will be back-to-back with our fourth African IPv6 Day, and it's scheduled to be from the 8th to the 12th November of this year, so you are all invited to that meeting. That's it. Is there any question? I will be happy to answer. No. Thank you. (Applause)

IPv6 Penetration Study

MR. PLZAK: We are way ahead of schedule. So kc, are you ready? You have a lot of time, so you can talk real slow. Okay, how many of you would like to see kc get her speech rate down to 100 words per minute?

MS. CLAFFY: I know. Me, too.

MR. PLZAK: So this is a -- I'll let kc explain the purpose of the survey and so forth, but some very interesting results, I think, that you're going to see here, and some interesting insights that she has to offer. kc?

MS. CLAFFY: How many people in the room filled out the survey? Okay, so the survey may not at all reflect the statistics of the people in the room if we've surveyed you. How many organizations represented here are profit versus non-profit? Profit first. I mean by design, not by implementation. Okay, so that's still less than half. So as Ray said, ARIN and I put together a survey a month ago, sent it out, gave two weeks for responses. We thought if you weren't going to respond in two weeks, you probably weren't going to respond, so the good news is we did get some empirical data. The bad news is I kind of learned that we need to rewrite the survey better. But the good news is, you guys really taught us how to write a survey because you put a lot of responses in the "Other," make a comment here, that really explain how we should have written the questions differently, if we should have written the questions differently.

So the survey was sent out March 10th, got responses by March 24th, so again, we didn't have a lot of time to do analysis on this stuff. But fortunately, the survey software that ARIN used, called "Survey Monkey," does a lot of the work for you. So we sort of extracted the big picture of questions that we could extract, and more importantly, as I mentioned before, we got a lot of better ideas about how to rewrite this survey to get better answers next time. So 347 people responded. Only 247 or so made it back past question 5, that actually has an allocation from ARIN or participating IPv6. So I will just go through an overview of the survey. I already went through the dates and the goals. I'll give a demographics of who was responding to the survey and again, the two goals were sort of captures from date on penetration. Now, you guys may be aware that a few -- last year, Brad and the measurement group at CAIDA tried to do our own measurements, active measurements of IPv6 reach ability, and Brad may have posters. Brad, do you have posters? Brad's busy. Do you have posters? So we did some posters that we'll hand out that is similar to the AS core posters that we've done in the past, but we compare our IPv4 measurement to the IPv6 measurement. Unfortunately, it turns out to be pretty hard to measure IPv6, as you all are probably well aware, more than I am even, the same ways that you measure V4, because the address space is enormous and you don't really have a set of target destinations to do "probing to," "given to," but we did "probing to" all the prefixes that were allocated by ARIN. So that's sort of the measurement side, and to be honest, the results of how many people were at a point in v6 from observable measurements that we could take from outside, from the periphery. Where we measured was kind of disappointing, so we spoke with ARIN and decided maybe there's some other way we can get measurement data or empirical data about IPv6 deployment. Because we're pretty sure there's deployment out there, we just can't see from ICMP or whatever tracer kind of activity we're doing. So that's one of the goals of this survey, and the other one is just to capture community input on what are the hurdles to deploying v6 if you're not deploying. I've done informal surveys over the last two years when I come to the meetings and ask you guys in the hallway, okay, what's really going on? Why aren't you deploying v6? And I can't say there are a lot of surprises in the responses to this survey. Some of them codified what I had learned from you guys before, put some empirical data underneath it, and there were a couple of things that hadn't captured before.

Who responded to the survey? So we had 75 percent of the respondents, again, this is the 350 number, the big number, 75 percent were in profit and 26 percent were non-profit, and we broke down the profit and non-profit further into these categories listed here. So a vast majority of non-profit is obviously the dot-coms, but there were representatives of others in there. And again, some of these questions, we will word better next time, because you have some things like some government in the for-profit category, but that means they're serving the government, serving government customers, because the question was ambiguous. And then non-profit, again, the vast majority of the non-profit respondents were education,.edu sites, and then some.gov sites and some other folks.

So this is the sort of gun-shy picture of who's deploying v6 and what kind of v6 are they deploying if they're participating in v6 now? And if they're not, but they're planning to, how far in the future are they planning to deploy v6? So the kinds of v6 deployment we queried about were: Are you doing it internally? Are you participating in IPv6 peering? Are you providing transit? DNS services? Supporting desktops v6? Supporting web services, hosting services, e-mail services, and cable? So we ordered this in order of who's actually deploying v6 now. And the other bars in this chart are deploying it in the next six months, the next one year, one to two years, more than two years, and then no plans to deploy it at all. So here's the unsurprising part of this: If you are participating in v6 deployment, you're probably just doing it internally right now and testing it on your own just to make sure things are working. And we allowed people to respond in free form, you know, later on in the survey, if you're not deploying v6 or if you've participated in one kind of deployment, but haven't extended it to providing it to the outsiders, why not? And a lot of the responses were, well, we don't have upstream transit, or there's business logistics we haven't been able to figure out to get the coordination with other ISPs, but internally we're deploying and everything's working. I was surprised. There were quite a few people that were participating internally. Again, this is the kind of stuff we're never going to capture with measurements that CAIDA's able to do from the outside. Peering, a little bit less, but still quite a bit of peering. Transit, even less, and then the hosting. That is the content providers, DNS host content services, DNS hosting, desktop web services were the middle tier of participation and deployment. And then the very last people who were even thinking about v6 at all is anybody that serves residential end-users or, really, the little guy. I guess I kind of would have answered that if somebody pressed me on the issue, but it's pretty stark data here. In fact, that cable DSL, the little purple in the cable DSL, is really survey noise, and you should just assume that the answer is zero there. Nobody who provides cable and DSL services to end-users is thinking about IPv6. The one person who responded there is a university who provides DSL customer service to home customers. He may be in the room. They may be in the room. And then I went through and tried to figure out which parameters matter. Are you more likely to deploy v6 if you were in one of these subcategories: One, profit or non-profit; two, size of your company; number three, if you're an ISP or an end user, an end receiver of the allocation? Does anybody have any guesses about whether any of these parameters matter? And if so, which ones? You can't say if I told you last night, by the way, but anybody who I didn't talk to last night. No? Nobody has any idea? Come on, you guys are on the pulse of the Internet here. If you don't know -- all right, that's good. That's good we did a survey.

So we divided these three parameters, right, profit/non-profit, size or your company, and whether you're an ISP or not, whether you're providing network provision service. And then I divided them into this graph. So these three separate sets of bar charts here are really the three separate parameters. On the left, profit or non-profit. Now, in this graph, unlike the other graph, we're just -- the top is 100 percent. We didn't plot the actual absolute values. However, we put the absolute value in parenthesis at the bottom that you can barely see, and it's order of 200 respondents total. Again, 100 of them had no IPv6 allocation and never got past question 5. Here, I see that profit/non-profit actually matters. You're twice as likely to deploy IPv6 if you're a non-profit, and that includes .edu sites. So I was actually surprised to see a lot more educational IPv6 deployment than I expected and government, which I was not so surprised by, because I know about the DoD mandate and such, and in fact, that was cited in the responses as to why we're deploying IPv6. In the second one, it looks like there's no real correlation between the size of your company and whether you're likely to deploy v6, and the third one also, it seems kind of iffy. To be honest, I don't trust the amount of data that we had here, especially in later questions, but it looks like not too much of a difference whether you're an end user, that is an end receiver of an allocation from ARIN or a network service provider on whether you're deploying IPv6. I'm sorry, that was for internal IPv6, so that was the very left-most bar on the first bar chart that I showed you. The second type of deployment we wanted to look at, too. In terms of deploying IPv6 transit, are you more likely to deploy IPv6 if you're profit, non-profit, small, big -- small, medium, big company, or a network service provider or an end user, end receiver of an allocation? Okay, and again, interestingly enough, the results are consistent here. You're more choice is more likely to be deploying IPv6 transit if you're a non-profit. Size of your company doesn't seem to make a big difference, and whether you're an ISP or not doesn't seem to make any statistical difference there. Third, web IPv6. Do you have an IPv6 reachable website, assuming you had IPv6 transit? So a lot of people would say I have an IPv6 reachable website, but I don't have transit for it. Again, consistent. In fact, very consistent with the internal deployment, more than twice as likely to deploy if you're a non-profit. Size of your company doesn't seem to have much of an impact, although small and large companies are more likely to be playing than the medium-sized companies. And ISPs and end user, again, I wouldn't trust that data because of the low number of respondents. Cable/DSL, again, stark difference here. Again, nobody's thinking about providing cable and DSL deployment for IPv6. Now, maybe that makes sense because those are the eyeballs and the eyeballs don't really need to be supported until the content's out there, and maybe that's consistent with what John Curran thinks is going to happen in the deployment transition, I don't know. None of this stuff, by the way, is inconsistent with his Internet draft on when people should deploy anything, so we might be on track with John's plan.

If you're not deploying v6 or if you tried it and you stopped deploying v6, what are the hurdles that you consider in your deployment? Now here, we let people pick more than one, check more than one box, right, but just order them in the rank order of how many people checked the box. Now, a lot of these categories you might merge into one, like we don't have a business case for it. There are a lot of things underneath the number 1 that you might argue about business case, but let's -- like user demand, but we'll go through this. The biggest category by far is business case, and in 2005, when I gave a talk up here about this similar thing, I called it incentive. The two real reasons that people aren't deploying v6 is they don't have incentive and they don't have capital. Now, the slide I shot up two and a half years ago was of the for-profit companies that were deploying v6, and I showed all the numbers in red that said, look, these guys aren't even making positive earnings. So why do we think they're going to spend their money on IPv6? That is particularly consistent with what we're seeing here, which is that in fact, the for-profit companies are not as likely to be deploying v6 as the non-profit companies. Business Case No. 1, vendor support, back office, and we've got quite a few detailed responses on what that means, what vendor support they're not getting. So that might be useful for ARIN to codify a list of things that the ARIN members say are not being supported by the vendors. No. 3 surprised me because I guess maybe it's the kind of people I talk to at ARIN, but I didn't get a lot of education as the reason that we weren't deploying -- as a hurdle to deploying v6. Now, you could argue that education isn't really incentive because you could put a person on at the top and get them trained up, or education might be capital because if you thought it were important, if you had a business case, you could buy a person. But nonetheless, education was on here quite a bit, more than it can be written off as negligible. So there might be a role for ARIN there, too, although my perception is that ARIN's pushing pretty hard on the outreach. User demand is really business case. Upstream transit is, again, to the extent that you can point to a third party and say, hey, it's not my fault, they're not giving me what I need to do. IPv6, there's quite a bit of that. Dual stack interoperability, multi-homing, so those two were really technical issues. And again, the lesser of the hurdles, or the technical hurdles. That may not surprise folks. Allocation policy, very few number of people that said the allocation policy is the reason I can't get an IPv6 allocation, and some of the people that did say that wrote in the free field that they really haven't tried in a year. So I know that ARIN has been responsive to the fact that allocation was considered difficult a couple of years ago, and so this needs to be retaken with folks who have tried recently, I think. And then performance, meaning IPv6 performance, on my routers isn't as strong as IPv4. That's hard to believe at this point, because plenty of people responded in the free form fields that performance is not a problem at all. And then, again, hurdles to getting an allocation. If you haven't even gotten an allocation yet, why not? No. 1, really you could call it incentive. It's not a priority, we haven't gotten around to it yet. No. 2, we don't have the infrastructure to support it. You could really call that incentive, too, or business case. Same with "Do not see the need." No. 4 is upstream transit doesn't support v6. No. 5 is the economics. And No. 6 is the policy issue, cannot get an allocation. And then there were a bunch of things in "Other" that really when you drill down and look at them, they belong in one of the other categories. People just didn't want to commit. And then there were a bunch of free form.

And I really want to thank, I guess not the people in the room, because very few of you filled out this survey, but next time we do this survey, please fill it out and please feel free to put comments in the "Other" thing because those were really helpful. And also, if you want questions answered that you didn't see reflected in this survey, in these survey responses, talk to me or Nate or send mail or we can discuss it on the ARIN discuss list on what you would like to see answered. But here, let me tell you three of the interesting quotes. This one sort of really had me stop dead in my tracks because it's quite consistent with what some of you guys have been telling me in the hallway, and yet I never see it up on stage. I never see it set up on stage. "We've actually seen a decline in the perceived need for v6 over the last few years. Very few have bothered with implementation. Those like us who previously had started to contemplate plans have basically shelved them because there isn't a push for it from users or upstream ISPs. There isn't a demand for its services." I think that's a typo and it's over IPv6, "Other technologies seem to have diminished the need; NAT, virtual hosting, too many other projects that have a much higher priority. The only place with any sense of gloom and doom about not implementing IPv6, quite frankly, is on the ARIN PPML list. I don't get the same urgency from any of my colleagues at other institutions or from our providers. It's that simple." Respondent No. 8. And then let me just do the other side of that, which talks immediately about the technical issues, the vendor support issues. "Management support for v6 is in name only right now. Sure, v6 addresses an ACLs supported in IOS, but you have to purchase the expensive, advanced IP services images, not the regular base one. Even then, supports from command line only, no GUI support for an IT guy who wears multiple hats, who can't all be command line jockeys. Lastly," and then we go jump right back to incentive, "why should I go to the trouble of implementing IPv6 if none of the big guys has yet? If neither CISCO, Microsoft, Intel believe in IPv6 enough to have quad-As published, why should I?" And then the last of the quotes that I pulled out, "Our customer base is all either not ready or not capable of v6. Our back one is ready, but the business drivers are not present." Very consistent with what I have been hearing for the last couple of years and what you guys would probably say. And that's all I have for reporting on this survey. I guess I can open it up to questions. And the "Survey Monkey" software is really pretty nice because you can filter on who answered yes to this question and what did those people answer to this next set of questions. So I can even answer more questions that you might have now without doing another survey, probably.

MR. HUGHES: Hi kc, Aaron Hughes. One comment about the size of company, and I think it's actually relevant about why lots of companies don't have quad-A records. Your.org, and I think Google, did a study on this where they inserted a .gif that was v6 and they found that .038 percent of users have broken v6 and look up the quad-A record and can't get to the site, which may not be a big deal for a lot of us small sites, but for someone like Google, .038 percent would cause a lot of screaming.

MS. CLAFFY: Yeah. A few billion dollars, right? A minute? Right. Yeah.

MR. HUGHES: I just think it's relevant for the size of company issue. In fact, Steve Wilcox did a presentation on it at GPF last week as to why they weren't adding quad-A records.

MS. CLAFFY: As to why?

MR. HUGHES: Why they weren't adding quad-A records to "www." Instead, they created IPv6.google.com because of that brokenness.

MS. CLAFFY: Yeah, it's interesting. I guess there's an IPv6.google.com you can reach now only if you have IPv6 connectivity. Do folks know about that? And you can't reach it over IPv4. And Google actually had a workshop that you may have seen about, they put it all -- the video all online. Vint Cerf was the MC. It was sited from Circle ID as a blog kind of thing. And I actually found it a pretty interesting workshop because the guy who was in charge of, like, getting Google working, the Google IPv6 working, Lorenzo, who was at RIPE for many years, actually, got up and just was into the faces of the people that were trying to push IPv6 deployment, saying do you seriously want me to put up an IPv6 service that's really billions of dollars an hour, or whatever, millions of dollars an hour -- he didn't have numbers on that -- and tell my upper management, that oh, yeah, we need to be on the blazing trail and make sure this stuff is out because if we lead, others will follow? It's not a good argument, it turns out, with upper management at Google.

MR. LEIBRAND: Scott Leibrand. ARIN AC Internap. I'd like to challenge your interpretation of the cable/DSL stuff.

MS. CLAFFY: Oh, good.

MR. LEIBRAND: I got the impression from my vague recollection of the survey that we were asking everyone if they were deploying cable and DSL, not asking cable and DSL providers if they were deploying v6. And I think the distinction is that you have a whole bunch of people who just don't do cable and DSL, so those numbers look really low; whereas if you were to look at the companies that actually do cable and DSL and see whether they're doing v6, I think you'd get a picture that doesn't lead to your interpretation of cable and DSL providers are not going to v6, but rather just the fact that cable and DSL providers didn't respond to the survey.

MS. CLAFFY: Fair enough. Exactly. And we could drill down to a little more of that. Yeah, that's a very good point.

SPEAKER: The first graph just wasn't normalized --

MS. CLAFFY: Well, yeah. That's true, the first graph wasn't normalized, but I'm not sure that really -- I mean, he still has a point. We did not drill down to find out which cable/DSL companies --

SPEAKER: Right. Is that one (inaudible)?

MR. BRADNER: Use the microphone, Bill, for people out there in audioland.

MS. CLAFFY: He's saying this is not normalized. So really, this is the number of respondents. But I accept what you're saying is that we didn't drill down first and say, are you a cable/DSL provider, and then have you answer these questions. What we said was are you doing IPv6 at all, no matter who you are, if you're a university, no matter who you are, are you providing cable/DSL services over IPv6? Now that may be a bizarre question to be asking in the aggregate. You may want to only be asking that question of cable/DSL providers. And again, we learned a lot about how to do this survey better, but this still looks pretty negligible to me. If there are cable and DSL providers in the room who would like to provide some empirical data to this discussion, it would be welcome. Yes?

MR. GROVES: Hi. I wanted to make a comment -- oh, sorry, my name is Rich Groves. I'm with Microsoft. I wanted to make a comment on your performance as a disincentive portion of the survey. Internally at Microsoft, we've seen quite a bit of performance issues based on IPv6 extension headers, on any transit traffic across any box that we have internally, whether it be Brand Name X, that's what I'll just say, so I'm surprised.

MS. CLAFFY: You're surprised that it's so low?

MR. GROVES: I'm surprised that it's so low.

MS. CLAFFY: Yes, I think that you're dealing with a small sample of people who have actually deployed with v6 or gotten to the point where they can measure a performance issue. That would be my guess now. Because a bunch of performance issues will not happen internally that will happen once you let anybody else get involved. Right. Yes?

MR. DeLONG: Owen DeLong, Juniper Network. (inaudible) participated actually more in the survey since I represent multiple organizations who have differing levels of IPv6 (inaudible) due to (inaudible). I was only able to (inaudible). So is there a way that we can deal with that?

MS. CLAFFY: That's a great idea. That's a great idea. We'll do that. Well, you mean you couldn't fill it out twice?

MR. DeLONG: Right.

MS. CLAFFY: Yeah, all right. Fair enough. Next? Yes?

MR. SHANNON: Tim Shannon from DISA. Were any of your respondents concerned about security? I don't see it on the form.

MS. CLAFFY: There was one free form response that mentioned security, and yes, I don't think we got it in the --

MR. SHANNON: So what you're saying is --

MS. CLAFFY: There were -- I think there were a couple of responses that mentioned security.

MR. SHANNON: But it doesn't seem to be a big hurdle.

MS. CLAFFY: Well, it would be in vendor support back office. People said security in IPv6 is not nearly up to IPv4 capabilities. So that's where it would fall into there. Yes, we did have to do some consolidation, so it wasn't -- security wasn't isolated as a reason enough as much as the bottom one on this slide. So we aggregated.

MR. SHANNON: All right. Thank you.

MR. HUGHES: Just a comment on topic. I did quite a bit of consulting adding v6, and I find that people start to get very afraid when you talk about adding v6 dual stack into their LAN environments where they're "NATed." They decide that when you tell them they actually need to patch their boxes and these machines are going to be publicly accessible, et cetera, they have high concerns about security even though they're already effectively reachable.

MS. CLAFFY: Yes. I mean, I guess, you know, some of the patterns of what we're seeing with v6, and particularly the fact that non-profit government and edu is more likely to deploy it first and put the investment and resources in, is not so far off from the IPv4. It's exactly how IPv4 was supplied. It was government and education first, and we tested it out on us. We got some security stuff built in before Commerce was willing to come in. So we may be seeing some of that pattern happen in IPv6 for the same reasons. Is that it? Okay. So definitely come talk to me if you think -- if there's other stuff you think of later in the day, or talk to Nate. He and I are working on this together. Thank you. (Applause)

2007-21: PIv6 for legacy holders with RSA and efficient use

MR. PLZAK: In our never-ending quest to keep you paying attention to agenda, we're going to make a shuffle. We're going to now have a discussion of Policy Proposal 2007-21, PIv6 space for legacy holders with RSA. And so if I can get the slides up here. Thank you, Erika. So here's a brief history of the proposal. It was introduced in July of last year, and you can see what has happened so far. It had been adopted, but the board, when they looked at it, remanded it back to the AC to facilitate further discussion regarding a policy text. The policy text is in the meeting packet. Since then, it has been revised and has had a new staff and legal assessment, and the current version is as of the 11th of March. The table on the lower right-hand side is something we've decided to include in these summaries, which shows you the relationship of this policy to any other relevant discussions in the other regions. And as you can see, this policy is only being discussed in the ARIN region. So the understanding of the proposal is that it makes direct assignments of IPv6 space available to any organization with an efficiently utilized v4 assignment or allocation covered by an RSA. The shepherds for this are Suzanne Woolf and Owen DeLong. From the assessment of the staff, legal liability, none. Staff doesn't have any real issues or concerns over implementation, some software tools. We could do it within 30 to 90 days after ratification by the board. Not much discussion. Nobody in favor. Nobody against it. No real comments, even though there were seven posts by two people. So with that, I'll turn it over to Scott for the presentation, and then John will take on the discussion.

MR. LEIBRAND: I'm going to go over this fairly quickly because we did this last time, so I'll just give the overview. The problem as it was presented is that current policy allows you to get a IPv6 PI assignment only if you qualify for an IPv4 /22. Many legacy networks with 23s and 24s don't qualify for 22s. Without changes to the policy, these networks are discouraged from adopting v6 and encouraged to stick with their v4 where they've got PI instead of having to go with PAv6. Other considerations into the way we wrote this, there's still a lot of legacy assignments not covered by the RSA. Some of those may not be efficiently utilized, so therefore, the policy change is the blue part, which would be to allow an additional "or" clause to allow you to get IPv6 PI space if you demonstrate efficient utilization of all of your IPv4 assignments and allocations, each of which must be covered by a current ARIN RSA. That could be the regular RSA or the legacy RSA. The rationale for that is to stop discouraging IPv6 adoption by early v4 adopters, encourage efficient use of legacy space and return of unneeded space by requiring the efficient use clause, and encourage adoption of the legacy RSA by requiring an RSA on the v4 space before you can use it to get v6.

The history is the interesting part. As Ray already mentioned, we presented this at Albuquerque. A loophole was found in the text. It said "a" allocations instead of "all" allocations. We attempted to fix that on the floor of the meeting. During last call -- actually, right after the meeting, I looked at that a little bit more and said even that change doesn't quite close the loophole quite. So I posted a revised text to PPML, but these changes were not included in the version sent to the board or the version last call, I can't remember exactly, but there were discrepancies in the text, so the board remanded it back to the AC. The AC basically decided that because of the changes, we should bring it back to the meeting and make sure that this is still what everyone agreed to and there's no substantial changes and no change in the community consensus. So the question is, does anyone have any questions or comments on the proposal as a whole or on the changes to the wording since last time, and is there still consensus for this?

MR. OBERMAN: Kevin Oberman with ESnet. I'm a little curious about the numbers on how many people posted about this comments, because I did post a question about it, received a number of answers from several different people, so I don't know how there could have only been two people who posted comments to PPML on this. But in any case --

MR. LEIBRAND: I think that was after a certain cutoff date.

MR. OBERMAN: That may be. In any case, several people -- I posted a question as to whether the statement must be covered by a current ARIN RSA meant just the RSA or the LRSA. Several people responded to me saying that, gee, they found that confusing, too, but they thought it meant most, including one from the AC who said that's what the AC thought.

MR. LEIBRAND: I believe I responded to you as well, and that is indeed the intent.

MR. OBERMAN: And I think that could trivially be clarified by changing the "a" current to "any" current just to make it really clear we mean RSA, LRSA, or any other RSA that ARIN may decide to use down the road.

MR. LEIBRAND: The problem we got into last time was with changing the text of the proposal on the floor of the meeting, so we've been explicitly instructed that the proposal text is frozen at this point. Scott has a clarification to that.

MR. BRADNER: The proposal text is frozen as in that we can't change it on the fly. That doesn't mean that you can't advise the AC that this wording would be better and the AC can consider that when they meet.

MR. OBERMAN: I would hope the AC would consider this, because it clearly does confuse some people, I think.

MR. LEIBRAND: So you want to change "a" current ARIN RSA to "any" current ARIN RSA?

MR. OBERMAN: Yes, just so it clearly covers the LRSA and any other RSA that ARIN may come up with down the road.

MR. LEIBRAND: Okay. I think that's a -- my personal opinion is that's a minor enough change that that's probably something we can do after this meeting when the ARIN AC meets to discuss it and then that can go to last call. Thank you for the suggestion.

MR. OBERMAN: Clearly, this is a trivial change, it's just a very minor clarification.

MR. LEIBRAND: Yes. Thank you.

SPEAKER: (inaudible) are you speaking for or against it?

MR. OBERMAN: Excuse me, I forgot about that minor detail. I have not yet reached a decision on this, but probably for it.

MR. CURRAN: Microphones are open. Any other discussion on 2007-21? No? Thank you very much. (Applause) Good morning, everyone. In order that the AC can better do its job, I am often asked to coordinate a show of hands, which gives the AC some judgment as to the support of the proposal that they'll use in making their judgment to recommend it to the Board of Trustees. We did discuss what is a predominantly editorial change, and I think people recognize that that is something that can be accommodated in the process. So I'm going to ask for a show of hands for people who support this policy proposal. Then I'm going to ask for a show of hands for people who oppose the policy proposal. Is everyone ready? I see my counters are gathered. Yes. All those in favor of advancing Policy Proposal 2007-21, please raise your hand. Nice and high. Nice and high, almost done. Don't give up yet. We have a count. Okay. All those opposed, please raise your hand. All those opposed, raise your hand. Okay. Thank you. On the matter of 2007-21, number of people in the room, 131. In favor, 63. Against, 2. Thank you very much.

MR. PLZAK: We are going to now have the break. And so we'll take the coffee break, and you'll be called back in the room when you hear the bell tolling. So the bell will be tolling for thee.

IPv6 Adoption Through the Lens of Economics of Security

MR. PLZAK: Hello. Computer. There we go. Welcome back. Okay. From now until lunch, we're going to have a presentation by Jean Camp. And I'll let her give you some background as far as what's going on. She's from Indiana University. And so, Jean? It's all yours.

MS. CAMP: Thanks. Can I hold this?

MR. PLZAK: It's on a wire. Hey, have we got a cordless mic? Grab one.

MS. CAMP: I'm just really --

SPEAKER: Just talk. Just talk.

MS. CAMP: Hello? Yeah. I'm just really bad at standing still and talking at the same time. So I decided to do a study of IPv6 diffusion. This is about -- it's maybe the beginning of the academic year. I have not been as deeply involved in this as you have, but I thought, oh, this is interesting. IPv6 is going to run out, so let's look at a diffusion study and see what it tells us. And I looked around. There were a lot of arguments, but there weren't many studies. And obviously, because that's -- there's not a lot of diffusion, so there's not a lot of data. So what we did was we did -- we went to ARIN's site, and there's route views and there's all these great sources of information, and we looked at -- we started with 60 months of data, and I'm sure you're all shocked at my finding. Is everybody shocked that IPv4 is going to exhaustion? Completion, I'm sorry. IPv4 completion will occur before -- I know, you're all shocked. And I'll give you a minute to stand up and recover. But I think that the range of this and the reasons for this, that I'm asserting for this, all come from economics of security, because you have some of the same problems. There are -- I was talking to kc in the back about why people don't secure their machines. So in my neighborhood, now all my neighbors have kind of secured their wireless, but they never patch their machines. These are the same people that are going out and buying a Prius to stop global warming, and they wash out their cat food cans. I mean, these are good people, right? But they're not -- they are. I mean, what's grosser than washing out your cat food can? Don't answer. (Laughter) And -- but they don't secure their machines and they're perfectly happy to be part of, you know, spam and botnets, because they don't see it. So I see some of the same problems when I looked at this diffusion. So one of the big problems is, as kc said, and I'm sure you're all aware, incentive alignment. What's in it for me?

But there's a lot of other things going on. I think that there are network effects. When I say network effects, I mean that in the economic term, not -- think of -- so network effects mostly come from the studies of the railroads' diffusion, the diffusion of railroads. So network externalities, and externality is just something that's not included in the price. So one of the early concepts of externalities is if your railroad ran by my wheat field, and it was steam powered and caught my wheat field on fire, that was a negative externality. And some parallels, I want to talk a little bit about the literature in patching, the literature in privacy, and how people look at security cost versus benefits. And I'm sure I don't need to tell you to interrupt if you have a question. So network effects, there are intrinsic benefits. That is my benefit. So if I buy a computer and I never connected to the network, I can do presentations, I can analyze data. Right? I can do -- before there were networks, there were big computers that would do complex models. There is an intrinsic value in a computer. You can buy a computer now, at home, not connected to the Internet, and use it to play games and have a wonderful time. So the intrinsic benefits are those benefits that are derived from a good -- basically, even if nobody else adopts it. And I think -- I saw a lot of that in kc's slide where she said, what are you using internally? Instead of NATs, we're using all these other things. We like having individually addressable devices. For some companies, you know, I don't know -- I'm doing this workshop on insider threats, and if you're interested in that, please give me your card. There are still, you know, openings. The -- you get these things where the people who run their networks are saying, well, we have this perfect firewall, and inside we have our NATs, and we know every device that's inside and we trust them. And out there is the scary, bad Internet. Now, I'm not arguing this is the case, I'm saying you have a lot of people whose company's mental model is that, right? So for companies who've moved beyond that, who realize they don't know where the boundary is, they need to know when you attach a new device, like, for example, oh, why would I think of a picture frame? And they need to be aware of the devices on their own networks. That's a benefit they get even if nobody else adopts it.

Network benefits are from IPv6 adoption. That's the benefit I get if you adopt it. And it seems that, in IPv6, that while you can have the intrinsic benefits, the network benefits accrue to late adopters. Right? Who had the first fax machine and how useful was it -- is basically the question we have here. And if I invest tremendously in securing my machine, if every Tuesday, every second Tuesday, I sit down and I patch my machine, I get benefits. I get benefits that protect my passwords. I don't have a key logger. I have less spyware. But you know what? My neighbor gets the benefit that I'm not spamming him. And you get the benefit that I'm not participating in a distributed denial of service attack. Okay? So not everybody who could benefit from patching adopts patching. Not everybody who could benefit from IPv6 adopts IPv6. How applicable are the findings? How can we take some of the findings about why people don't patch and bring them to diffusion issues of IPv6? So I think a huge amount of it is visibility, but it's also perceived benefit. One of the problems with patching is the externality part. Right? I patch, I benefit. But you benefit, too, and you don't pay me. You can pay me; I'll accept payments. I keep a nice network at home. But, there's no structure for you to pay me. So Andy Osmet said, what we need are either subsidies -- we need to say, if you're going to patch, you need to be subsidized. We need mandates: Patch or else. Right? And you need to actually stop bundling. So one reason users don't patch is -- so maybe you want that security patch, but you don't want to break iTunes. Or you like the way you busted iTunes. Or you don't want to install this new helpful spyware. So unbundling is one way to help patching, is to give people only the security patches, and not the security patches and all the other stuff you're trying to force them to adopt. Lucianne Soleil said what we have is a lack of standardization. When you get a patch, you don't know what you're getting. So if you buy an IPv6 product, is it absolutely the case that you know what you're getting? Do you know how interoperable it will be? Do you know what options have been implemented? There is a need for testing. I talked to the guy who runs patching for IBM. He says, we get a patch, we take three weeks. We know we're vulnerable for three weeks, because it is better to be vulnerable for three weeks than it is to put a patch on our entire network and break everything. Right? I mean, that's a choice to be vulnerable. Also, every network is unique, and there's a tremendous concern for local technical hacks. Right?

Michael Froomkin talks about privacy. The risks are invisible. How many people counted the cameras that they passed on the way here? Right? I mean, yes, your privacy was decreased. How many of you saw any kind of data protection statement with any camera? You didn't see the camera, right? What are you going to say? Enter this space, you will be videotaped. You have to sign a release at a conference. You could be having a discussion in an airport that you think is private. So the risks to privacy are invisible. I ran this experiment on this kind of security enhancing human interface thing called Net Trust. It's really cool; I love it. And I ran it with a bunch of -- I ran it with CS undergraduates and they liked it. And then I ran it with some community members and they all said -- they filled out the surveys and they said I never share information on the Internet. Never. And then, at the bottom, they were like, oh, yes, I shop all the time. I shop for my grandchildren. I shop for my, you know, my nephews, and my sister has this website. And, you know, as a researcher, you have to accept that that's their perception. Although as a person, you want to go up and hit them with something and say how do you think they know where to ship it if you don't tell them who you are? I mean, they think they're totally private, and they're not doing anything, and they're not taking any risk at all. Just because they're shopping on the Internet is not -- there's no privacy issue there. They only enter their credit card where they want to. Similarly, I -- the risks aren't very visible. What is going to happen at IPv4 -- should I say completion or exhaustion?

SPEAKER: Depletion.

MS. CAMP: Depletion? Do we like -- is that? I just don't want to pick any -- I mean, I'm happy to pick some fights, but I don't want to pick any involuntarily. So the risks are invisible. I -- gosh, they'll run out of IPv4 addresses somehow, and that won't hurt me. Right? Yeah, sure that means that maybe heavy-handed regulation or there'll be big market distortions or we'll have more serious problems, but they're invisible and unknown. The costs are immediate. If I don't shop on the Internet -- and I love Bloomington, Indiana -- if I don't shop on the Internet, I'm going to have to drive to Chicago to shop. Right? That is an immediate, visible issue. And then there are other parallels in privacy. So how many people here regularly read privacy policies? I do. I do. And do you know why I do? Because it's my research, and I publish some of the things I say. And then I'll go to my student's -- the popular student websites, I'll read the privacy policies, and they're all like, they don't do that. But it's a lemons market. I mean, even if I read the privacy policy, you don't know what they actually do. You can read a privacy policy. You don't know the jurisdiction. I mean, if you read many of these privacy policies, they're masteries of wordsmith. We may share information. We might. Over tea and watercress. But merchants can't prove their privacy policies. They can't prove they won't change. Network service providers, you can't prove the value of IPv6. You can't walk up to me and say, all right, for every machine you put on IPv6, you are going to get to $27.14, in the next 7 years, with a 3 percent -- you can't prove it. There is a lack of information in both cases.

So Aquisti did this thing -- so, everybody knows future risks are discounted, right? I mean, so you have an immediate risk and you have a future risk. And there's -- you know, a dollar, in the same way a dollar today is worth more than a dollar next week, even absent currency rate changes, a risk today is more risky than a risk next week. So it's normal to discount risk. But if you look at privacy risks, not only do people discount them over time, but the farther off it is, the more they discount it. Right? So it's called -- a "hyperbolic discounting" means you discount the risk at a rate that increases. So people are discounting these risks, but it's like, oh, that's, you know, that's a long time from now. That's -- we're not worried about that. And the risk of depletion, or any kind of security risk -- security risks certainly see this. Right? I'm not going to be subject to identity theft because -- and then you insert some magical thinking, is actually what we're talking about here. And in general, costs are visible. People find the standard complicated. They worry that there's a lack of interoperability. That if I buy -- if I use your IPv6 stack, will it work with my IPv6 stack? The thing about a technology that's not widely diffused is it's not hugely mature across a wide range of network situations. And what's going to happen if I do this? Will my routing table explode? Will there be routing storms? What'll it cost? And then there's a huge other benefit that's very easy to overlook, that is very well-documented, and that is, you lose tacit knowledge. Everybody here is proud of what -- of knowing how to do what they do. Right? We're all proud of our knowledge and our abilities. And one of the things you have to think about when you have diffusion in and a new technology, is you're telling people that their mastery over the old technology is no longer either potentially as valuable or even valuable. So you have, what, two generations of IPv4 network engineers. And you're saying, no, we're going to get rid of that. All that NAT stuff you learned, that horrible semester you spent in EE327 or whatever it was, you don't need that, so. And similarly, the costs are visible; the benefits are invisible. There can be a long-term advantage in tacit knowledge. You'll be the first one on your block to know how to really configure IPv6. But it's uncertain. Overall network benefit -- might be security. You can't capture that. You can't capture that by adopting it early. And new commercial opportunities aren't quantifiable. What is the commercial opportunity in ubiquitous computing for in-home health care of an increasingly elder population? Who knows? Right now, it's in a research stage. And it's a place where you're going to have a lot of devices. And you may or may not want them to be network addressable.

So I am going to do the ultimate academic duck and cover, and tell you I am giving you this number with a reference, so don't ask me about it. Rowe estimates IPv6 adoption would cost about 25 billion over 25 years. I think that's kind of low. I'm just going to go way out on a limb here and say that doesn't seem like that much. And he talks about personnel costs, again, the tacit knowledge. What you know, it's not valuable anymore. Sorry. But we've got this cool new standard. And the discrepancy between cost and expected benefits burns early adopters. So this is all security things. IPv6 can also increase security vulnerabilities. So Andy Osmet, who I referenced before, says there's a problem -- is milk like -- is code like milk? Does it curdle? Does it -- as code gets older, is it more and more and more broken and stinky? Or is it like wine? You want to have old code that has been tested and proven. So his finding is that milk is like wine. I mean, no, milk is not like wine. Don't get confused and get drunk for breakfast and blame me. Okay. Code is like wine, that as you mature your code base, you get a lot fewer errors. And you get a lot fewer vulnerabilities in the code per line of code, and you also get a lot less misconfiguration due to inexperience. People just learn how to use it. Right? And if you're an early adopter, you're getting early code. You're getting the early code base. You're getting this year's -- you know, Cabernet. So I decided to look at diffusion, and I'd like to say, before I put these graphs up, that a picture is worth a thousand words. And these pictures are worth a thousand caveats because the data is very sparse, and I will feel completely free to agree with you that it is not entirely a guess. Okay? So we looked at two kinds of models. One, kc graciously -- and I didn't know she was going to do this -- started with the survey. But what you'd normally do is you go across -- you know, an industry. So if you want to look at fax machines, you say, oh, let's look at firm-specific diffusion. You compare characteristics of adopters and then late adopters. But that usually requires a pretty significant level of adoption. And then there's an S-curve macroeconomic model which takes aggregates over time. It implicitly integrates network effects and different types of adopters, and it's much better at a macro level. The Probit model, you need to have a lot of data, basically. You look at what industry you're in, you look at firm -- all the things she looked at. So she did that. And it's very hard to do with small numbers, to try to do some real correlations. And also, when we actually looked at the data, we found there were basically two firms. There was .gov and .net. Right? Governments adopted it, some network services adopted it, and everything else was drowned out. Now, if you want to go back to economics of security, the good part of it means the people who are arguably most informed about IPv6 -- that is, the network service providers -- are the people who are adopting it. Right? Compare that to something like screensavers with spyware. Right? The network service providers aren't adopting those; home users are adopting it. So the fact that home users aren't in the lead is not really a problem. We're saying that the most informed parties are least concerned about the uncertainty, which is absolutely what you want. The negative is how do you determine what factors are really driving adoption. It's a little early in the adoption cycle for that. So the S-curve model is nice. It's not really an S, because obviously, you don't go back in time. It's more like a kind of a transistor response curve. And it says there's a non-constant rate of adoption. And that imbeds improvements in technology quality. That says if you adopt IPv6 this moment, if you adopted next year, you could get improved quality. So it talks about tacit knowledge innovators, in fact, early adopters and then laggers, and the assumption is there'll be some refuseniks. I mean, wire line telephony never got to 99 percent in the United States. Right? So I'm sure there are businesses without fax machines. I haven't ever worked with one. So here was the question I started with. Given current adoption rates, when might IPv6 have real domestic market penetration?

So we did three things. We did kind of a best fit, which turned out -- you know, kind of pessimistic because it assumes there is no exogenous influence on the demand for IPv6. Well, my understanding is that around 2011, 2012, right, there's going to be a tremendous exogenous influence on the demand for IPv6 because there won't be any IPv4. Right? I mean, this is like the demand for synthetic rubber. The demand for synthetic rubber was nothing until there was this unfortunate little horrible, tragic global war thing and we didn't have natural war -- natural rubbers, and then synthetic rubber. Best case assumes a tipping point, and it's the most optimistic we can do given current data. I mean, this is -- I'll tell you how we used the data and -- you know, no making things up. So we did two datasets. The first, we did IP addresses and routes, and we compared routes as advertised. And then we did system numbers, because I thought that was a better comparison. Right? I mean, routes, you can have more IPv6 routes for fewer systems. Does that make sense? So we did the route comparison first, and then we did the system numbers. And it's true that you can't resolve a real world uncertainty with models, but you can bound uncertainty, and you can say something about what is happening and what the limits are. So the bounds are pretty big, I'm warning you in advance. We have some very large error bars. And -- but I think you might find it interesting. So the route count was your standard model. What we found was at about 4 percent, our secondary coefficient started to dominate; it went a little linear. And it occurs in -- and serious adoption occurs in about 2019. Now the thing is, the route -- I was happy with this because I thought 2019 was pretty good, but the data's not that clean. And also, this -- you see how it's low at the bottom? That's the coefficient of innovators. And then this, as it goes exponential there, that is the coefficient of followers. That is a really high coefficient, historically. That is incredibly high compared to things like fax machines, automobiles, even e-mail. Okay? But even with that, it's maybe too little, too late. You know, my understanding is at the current rate of adoption, IPv6 will be 20 percent diffused in 18 years. Now, because of that second coefficient, which is really high, you could say 80 percent in 22 years. This is not going to make anybody dance with happiness. The analysis doesn't address possible exogenous forces. Right? And so I list two forces that are completely defendable here. That is, IPv6 depletion. Right? Good. Depletion. And then supply pull -- what?

SPEAKER: You mean v4 depletion.

MS. CAMP: Sorry, v4 depletion. That's not as bad as getting drunk in the morning by confusing milk with wine. IPv4 depletion, and then there's this demand push which can give you an exogenous force. And there's a supply pull, and the DoD says they are going to adopt IPv6. And that's a case of supply pull. So if you look at, for example -- so, there's a case study about how IBM diffused the fax machine. They used it internally and then they demanded their suppliers use it. Okay. That is a kind of exogenous force we're talking about. So if you say -- you know, the DoD really does adopt by 2010, and we also looked at 2012, and -- you know, there's -- and we all learn to get along, it still doesn't occur until 2019. And in fact, some of the -- I did the route data, and then I took later data and did the ASN data, and there was a little drop, a very small drop, that would make that not fit. So -- but the forcing function says let's make the DoD -- let's say the DoD adopts and we have a big push. Right? So we have a supply pull, we have everything. Then the most optimistic that can be extrapolated from the current data is 80 percent in 8 years. And if you want to say anything less than eight years, you are just totally making things up. Okay? And this is very optimistic. And one of the things I thought about after this is, well, let's look at IPv4, IPv6 routes over time. You can see at the end, there's a little upturn. So basically, we're saying, in our most optimistic, we fit the curve so that that gives us our followers' coefficient. And this is very, very optimistic. And then we said -- this is since I presented this last, so -- the ASN count with the best fit. So we did -- we have a very good follower coefficient.

We did a best estimate with curve fit, and we found that the result was somewhere between 40 years and 220 years. Which is why I didn't use error bars, because you'd just have a big line with error bars all the way across it and you couldn't see what was going on. So these are our estimates, standard deviation one way or the other. So I think we were all comfortable in knowing that in the next 220 years, IPv6 was going to be adopted. But that made me say which months matter? So let's go back to the fax machine. The first fax machine was demonstrated in the United Kingdom in the 19th century -- the first telephotography was done, the first thing that we would recognize as a fax machine. So the early demonstration was at the -- you know, the Proceedings, the National Academy of Sciences in the UK. The first machine that did a fax was in 1902. And then the first transcontinental fax was around '56. So what if what I'm doing with this data is the Internet equivalent of modeling from 1859? Right? This could be a problem. So what we did was we said, well, you see the little bump there? The negative? This causes data problems. This is part of the data problem. So I looked at the data -- 6bone project termination, I think? Does that seem reasonable? And this is -- honestly, that actually is a guess, because I'm just saying the data went down, and at the same time, this happened. So I'm, you now, just -- but I think it's reasonable. So what if we truncated the data to the five-month window? Because 6bone said, okay, there are public IPv6 addresses, we can say this is where adoption's starting because we are working in Internet time. So maybe I was looking at the last century. So let's cut it -- let's use the ASN count -- let's cut it to the last six months and vary the follower coefficient. Remember, there's this coefficient, which is the innovator coefficient; and this coefficient, which is the follower coefficient. If you were in my class, I'd throw something at you for not -- so it's best estimate with curved fit, best possible results are on the left, is the coefficient, right? So we have the follower coefficient plus one standard deviation. All right? That's the best possible -- truncated the data, six years. We still got six years, which is not entirely optimal. And then we went the other way and we said, okay, 70 years, which is better than 220. Right? We're in this century. So the route data, the worst case, gave us about 20 years. But then we looked at the route data and we said there's a real problem because I was comparing -- you know, maybe not apples to oranges -- maybe, I don't know, cows to rabbits, in terms of their proliferation -- worst case, 20 years. Best case, eight years. And that eight years means you truncate the data, you do one standard deviation of the coefficient, and you have an exogenous force. So you know -- and the autonomous networks, the individual networks, no duplicates. So it's arguably a better fit because we're comparing -- you know, apples and apples. That gives us a worst case of 200 years. So -- and then I went back and I said this is mental. So what's going on that you would get this kind of number? We dropped the data up to the -- and we dropped the dataset, and then we did -- you can get by doing one standard deviation of the coefficient; that is, you'll get 200 years. But this 2014 means truncating the data to six months and doing one standard deviation of coefficient larger. That is to say, if you push for less than six years, I don't see how you could do it. I mean, this is standard deviation, best possible picture, we get six years. And is it the case that we will still be allocating IPv4 addresses in six years? Yeah? I mean, the question is will you have -- will ARIN have a nice -- so I think that this illustrates a problem.

Why so long? Is this a market failure, or a technical failure, which is a great slide bullet to have for libertarian engineers. I just love putting that up there. Thank you for indulging me. Misaligned incentive structure. Right? At the individual level, you have the loss of tacit knowledge and expertise, and you have testing costs at the institutional and individual level. There can be a lack of information. Network externalities argue against early adoption. Maybe it will be six years, but six years says there's a tipping point, and we are almost there. Are we almost at a tipping point? Right? That, I can't answer. That -- you can answer that better than I can. What is the tipping point? So why so long? Well, the market's not really good at rationally addressing long-term risk versus near-term cost. Right? There has been study after study after study that says -- you know, if you go -- if you have an office and you put in a gym and on-site day care, you're going to make your money back by massive increased employee loyalty and reduced sick time. Does everybody here work in a place with a gym and on-site day care? I mean, this is not unique. The incentive alignment at the institutional level also isn't great, because there are some counterincentives to adopt. Do you want to test, in your company, the new software? Right? You know, do you want this year's Cab or do you want to wait until somebody else tests it? You want there to be a little more adoption. In fact, if there is, as some people say, the ability to lock out new entrants, it would be absolutely mental of you to adopt. Now, I don't know if that's true. That is not -- I'm just saying if that is perceived, then you could be seen as acting against shareholder interest. And in that case, there's a direct map to the use of security. Right? What does security get used for? Does it get used to prevent your machine from being a botnet? No, it gets used to make sure you don't use somebody else's printer cartridge. Right? Am I right? So what can you do? Well, you can do government support of adoption. I'm just saying these are things that have been tried in security. Right?

Subsidies can decrease adoption cost. You can increase incentives for production. You can support production. You can demand -- so like IBM did with the fax, they said, all right, we're going to use the fax internally, and then our suppliers have to use the fax. Could you get Wal-Mart to use IPv6? Do you think Wal-Mart and their suppliers -- would that make a difference? Right? I mean, maybe the DoD isn't where you want to push. But maybe it is. The DoD could do the same thing. They can do fines, tax credits, tech support for technical standards and requirements. There are many things you can do. This is my understanding in the state of the world from the literature. I have not done any studies on IPv6 diffusion in China. And if anybody wants to run up after this talk and say here's your funding, do that. I'll do that. But what they're doing is they're doing incentives, they're doing funding, they're doing contractual obligations in government contracts. You know, there are other areas where you get contractual obligations. You must pay union wages. You must not outsource more than X percent. You must have an environmental impact statement. You could see, you must have 10 percent of your machines, your devices, IPv6 ready.

So there's a great 2004 final report on the IPv6 task force, and I had to quote this, "Imperceptible." That's a great word, "imperceptible." On a global scale, I have been -- I came into this kind of neutral, like, IPv6, IPv4 with workarounds. I mean, maybe I'm being like the atheist at the revival, but I'll say, I didn't really care. But I have come to -- it is now my opinion that IPv6 adoption benefits outweigh costs hugely because of innovation potential for all the devices. But in the U.S. and Europe, particularly the IPv4 infrastructure says we're going to have a high switching cost, we've got people who've got the IPv4 addresses, we've got the least incentive, and -- let me see, is this an American or international? Should I skip this? I'll skip this. I'll be polite. So the U.S. IPv6 adoption rate's not comparable to the international rate. If I could get this same data, if I could get some good data on China and Korea, I think that would be a good comparison. High switching cost and low perceived benefits, right? I think that government support could include -- encourage more timely adoption, but maybe not. I mean, did you notice I didn't say government support will encourage more timely adoption? Because I haven't necessarily seen that happening in security. Right? What's encouraged adoption in security? Two things: Visa and MasterCard saying you've got to do this on your website, and insurance, cyberinsurance. The insurance companies say here's the list of things you want to do if you want to be insured. So what should government do? And IPv4 depletion will vary. Here are some questions that come from an economics kind of policy background. How much can you unbundle IPv6? Can you have 10 years of saying this is going to be strictly renumbering, everything else is going to work, you're not going to have any -- I'm sorry, you're not going to have any of the features? Or will the rejection of the features and the unbundling of the features hurt adoption? So I think that's an open question. Emerging services. There are huge emerging services. How many people read that paper about the pacemaker? You know, they use Bluetooth for the pacemaker, so they encrypt the signals going, but they don't use device authentication. So you can't read the signal when I tell your pacemaker to stop. Isn't that a helpful security feature? I mean, it seems like there are a lot of IPv strengths if you don't unbundle, if you kept it fully bundled, and there's a tremendous need. Why not pay adopters? Why not? They're doing something that's a benefit. You don't have to just give them money. Right? You can certify individual IPv6 engineers. So look at what CISSP did. CISSP, they developed an exam. They said this is what you have to know about security. And then they went out and they said -- you know, Jean Spafford (?), here is your certification because you are such a senior security person. Right? And they gave it away to the best people until people wanted it. So that -- I mean, that model has worked. And also, usability matters. Okay? Network engineers are people, too. All right? And you can do -- I know, isn't that sweet?

You could do some formal studies of IPv6 configuration. Why is it that all these users have bad IPv6 configuration? Look, it's true, sometimes it's because people are stupid. Like the warning on the toothpick thing: Don't stick it in your eye. All right? That's for stupid people. But we're not talking about people who are sticking toothpicks in their eye. We're talking about investing seriously in usability as a way to assist the engineers with the transactions -- with the transition and the consumers with the adoptions. Take interaction design as seriously as you take issues of pricing, because a bad interaction is a price increase. Right? And also, again, you have this tacit knowledge feature, that you don't want people to feel like -- you know, we're taking away all your old knowledge and now, oh -- you know, everybody likes to feel thwarted, right? So these are things from InfoSeCon, which is Computer Security and Economics. While there've been some total cost of ownership case studies, what's the mobility cost? What's the security cost? I mean, I would say that right now, individuals are just waking up to the risk, not only of insider threat, but the risk in other infrastructures. So in Spain, they had actual train crashes. Did you guys read about this? Because they didn't authenticate their switches. You can't -- you know, you don't want to NAT the train switches in Spain. Right? Every train switch. They had a teenager who figured out he could change them with his remote control. He rewired his remote control and he would walk to school and he'd change it. Look, isn't that cool? Can you see yourself doing that when you were 14? Come on, admit it. You were 14. Yeah, well. And then two trains ran into each other. This is not -- you know, you can see this is not good.

There are -- people are becoming more aware of the security cost in the physical infrastructure. And, of course, pricing with coexistence. You've got to plan for pricing transition. You can build a market and that market can be absolutely self-sustaining, and prevent instead of enable adoption. Right? And if you do build a market, what are you going to build the market in? What's really scarce? Right? Are the addresses scarce? Are the entries scarce? How are you going to price? And who prices and who clears, and what's the bundle of rights that you get? These are not easy questions. So if you -- I referenced a lot of work. I referenced Osmet, Anderson. There's some nice, wonderfully readable stuff http://infosecon.net, (inaudible) InfoSec and eCon stuck together. And then these are the two students who have been working on this with me. So I hope my time wasn't too horribly off.

MR. CURRAN: Plenty of time. You even have time for questions. Microphones are open.

MS. CAMP: Who wants to debate the statement, "Network engineers are people, too?"

MR. CURRAN: Center microphone in the back.

MR. HUGHES: Hi, Aaron Hughes here. A couple of comments. One -- you know, the fax machine was a very different kind of thing because we still had the postal mail service. Nobody was saying -- you know, in three years, postal mail's going to stop working, so you need to adopt the fax machine. And I assure you, if postal mail stopped, everybody would buy a fax machine. In this case, we have that kind of incentive where, I think -- the graphs that you're doing are based on not running out of v4 space, and when that day happens, people will adopt because they really won't have much of a choice. And there are a ton of incentives out there. Government incentives right now include things like being able to be on the GSA Schedule, still taking those dollars. That's a nice one. I don't see that they've implemented a lot of dual stacking. I certainly don't see a lot of quad-A records out there on government sites. But I do see on the contracts now: Check this box, yes, you're able to supply v6 or you're v6 compliant. And in terms of commercial incentives right now, a big one I see out there is free transit. There's a couple of big IPv6 providers giving free transit. Happy to move those bits. Peering requirements go down. I can peer with larger providers on v6 than I can peer with on v4. And I also think that it's a fairly simple thing to implement v6 unbundled. It's easy to dual stack and not add quad-A records until the end. That's it.

MS. CAMP: And so I think many of those are at least fairly recent. And I think that's one reason why we could do the truncated data. But still, if you want to get to six years, you're going to have to have a significant -- you know, we're talking entire standard deviation to have that kind of --

MR. HAIN: Tony Hain, Cisco. I have some foggy brain cells that recall a similar thread of conversation of why IPv4 would never take off, that SNA would rule the world. And I was wondering if you'd had a chance to go back and review some of the discussions from the early '90s about why SNA would continue to rule the world, and look at that and see what kind of real rate happened in terms of the transition from SNA to v4, as one place of comparison. And another, it looked like all of your conversation is about the routing system, and the transition of the routing system, which --

MS. CAMP: Yes.

MR. HAIN: Could occur fairly quickly if people chose to do it. So you know, it's a choice question. I wonder how much of that is actually driven by the IN systems (?) and the diffusion curve in the IN systems, which I don't think you have covered here much at all. And, in fact, if we start -- if we say, if it's an IN system-driven thing, then the diffusion of the IN systems actually started about six years ago, seven years ago. So maybe we've got a running start on your curve that is buried in where we're looking. And so there's a couple of places I think would be good to look at in terms of comparing to a historical event. You know, comparing to the fax machine is actually comparing to the IN system, and you don't really get the network effect until you get the IN system. Comparing the routing is a little different. And I think that actually goes more to the SNA question, and how do you actually -- you know, flip that over. That was a fairly short curve, as I recall. It was less than 10 years.

MS. CAMP: Thanks. No, I just wanted to say I think there are other things, like if you look at DRAM adoptions, because there, you're not talking about adopting a different thing. So the fax machine was really a substitute for couriers, not for U.S. Mail. Couriers were so expensive. But when we did the long tail, shortening the tail is what got a quicker diffusion. So if we lengthen the tail, we're going to get larger final diffusion numbers.

MR. CURRAN: Yes, Paul.

MR. WILSON: Hi.

SPEAKER: Is that working?

MR. WILSON: Paul Wilson from APNIC. I just wanted to comment on a couple things. One was the part of your presentation in which you said, as a lot of people do, that there are special incentives for IPv6 in Asian countries, and that Asian countries have been demonstration sites or successful in some way in v6 deployment. That's not really true anymore. The Japanese government did have specific tax incentives for a while on IPv6 -- some aspects of IPv6 adoption -- but they don't anymore, so I'm told. And I'm not aware of any other country where those sorts of incentives exist. There has been a lot of promotion of the importance of IPv6 as something that should be adopted in the national interest in those countries. And it's true to say that in many countries of the region, the government actually is influential. So the government will say something like that and people will listen. However, the adoption codes are still not reflecting that, and I hear as many people in my part of the world say, as I do here, that v6 adoption is something that people will do when they have to do it. And they're ready for it, they're smart enough to know about it, and to do a little bit of planning, and that planning may be underestimated.

But it actually is a conscious decision that we really don't have to do it yet. And so, as I say, I think the address allocation curves are not showing anything special in the Asia-Pacific region with being like other parts of the world, up and down, no -- from year to year -- no revolutionary allocation rates happening yet at all. I wanted to just make one other point, which is about how you're doing these projections. And I think the curves are interesting, but -- I just mean, the curves' reality doesn't follow -- a curve -- you try to fit a curve to reality. And I'm just again, wondering what sort of parallels you might look at in terms of actually trying to test your curves against similar situations. So maybe there's a parallel that can't be tested historically yet, but it may be that others have done work in this area. And I see on TV in the hotel here that there's a fair bit of promotion at the moment about the deprecation of analogue TV in the U.S. That, I guess, will come -- it's different in that it will come at a particular date. But there must be, at the moment, I guess, some interesting speculation going on as to how many people are buying the little analogue conversion boxes. And -- you know, that being one way to transition versus, say, another, more expensive way, which is to buy yourself a big flat-screen TV and do it properly. And maybe there are some parallels there. But as has been said before, I'm not sure that faxes, for instance, are necessarily a good parallel. We might look at other more recent technology changes. And one that came up in conversation with Ben Edelman last night was this current transition we're seeing to flat-screen monitors from CRTs. And, I mean, I would say that the transition that we're seeing there -- and that's completely optional -- is extremely rapid. And I don't know if anyone's tried to lay their CRT monitor on their footpath, likely, but no one picks them up if you do.

MS. CAMP: If you look at the -- all right. There was a Nobel Prize in economics for the guy who proved that railroads were the same as canals, and that if we hadn't had the transcontinental railroad, we would've had the transcontinental canal. So you know, economics can go to these kind of insane extremes of believing that the technology itself doesn't matter. And I -- you know, I mean, obviously -- you know, the great canal through Death Valley wasn't going to happen. But that being said, this diffusion curve has been very widely tested. Yes, it's a -- you know, it's this classic diffusion model. And it's not just faxes, it's e-mail, it's the adoption of FTP, it's the adoption of IP4, it's the adoption of -- you know, Beanie Babies and Pet Rocks, and anything else kind of follows this pattern fairly well. And I'm not saying that in six years, we're going to have this adoption. I'm saying that if you use a very well proven model, and the data that are available, you're not going to get to adoption before depletion unless you have this -- a miracle occurs. Right? And then you can also look at other -- what I would call exogenously-driven adoptions, like synthetic rubber. You know? When the Allies no longer had access to rubber plantations, did a great job with synthetic rubber. The diffusion of radar in the military, right? If organizations come up against extreme necessity, they will certainly diffuse quickly. But it's not like IPv4 will stop working. And your television is going to stop working if you are only using over-the-air broadcast. And there are going to be a lot of people with analogue TVs because -- I don't know if you've seen this ad, this is one of my favorite ads, although my favorite ad is the bipolar medication.

But we won't go there -- because the entire ad is a list of terrible things that will happen to you if you take it. Your cable company is taking care of you. Your TV will still work. So even when you have mandates, you have market participants that enable and profit off of people not adopting the mandates.

MR. CURRAN: Okay. Center microphone.

MR. POUNSETT: Matt Pounsett. I'm from the .ca Registry and the ARIN Advisory Council. I'm not sure how much this influenced the graphs that you're -- or the curves that you're using, but there seem to be a lot of stress on loss of tacit knowledge, which I don't think is really a factor here. There's a fair bit of new knowledge that people need to deal with IPv6 versus IPv4, but most of what people know about IPv4 continues to be useful in the IPv6 world. To use an analogy from a -- you know, different place: If we we're all mechanics, we're moving from one type of car to another, not from cars to planes. There really is -- yeah, there really isn't a lot of loss of knowledge there. So I'm not sure if that affected the curves you're using much, or not, but it doesn't really seem, to me, to be a factor.

MS. CAMP: So it didn't affect the curves we're using. What affected the curves we're using tremendously is our start date. And if you picked an exogenous forcing function -- which what we picked as our forcing function -- which is to say, we just say it happens, and then add that as an asserted point -- is DoD adoption at different time periods. And one of the reasons I started to stress tacit knowledge is -- kc said, in the question and answer to kc, somebody gave a number of how much it could cost Google. You know, Google has IPv6, but you can't reach it because people are misconfiguring. And the people who are adopting now are the leaders. So you know, it's not hard to learn how to read either, but we still have one in five illiterate adults in the U.S. It's not necessarily the difficulty of obtaining the knowledge. So my emphasis in this particular day on tacit knowledge was a response to the question and answer and the previous information. But no, it did not affect the curves at all.

SPEAKER: All right.

MS. CAMP: So I appreciate your thoughts on it.

MR. CURRAN: Okay. Far right microphone? Leo.

MR. BICKNELL: Leo Bicknell, ARIN AC, ISC. A comment and a request for a future presentation. So the comment would be, I think perhaps relying on the public data that you seem to have relied on may be a disservice to the actual efforts that are going on. Because a number of large companies are doing an awful lot to look at IPv6 and consider deployment, and are specifically not doing it in a way that is visible externally to those companies. Specifically, when you look at large cable and DSL providers, there's a perception, if you look from the outside, that they're not doing a whole lot. And if you talk with them, they're doing a whole lot internally, they're just not ready to release it yet. So if you look at routes or -- you know, number of systems you can reach, or any of those metrics, the numbers for them are zero today. But that doesn't mean that they don't have a plan that in a year or 2 or 5, it could well be 20 or 30 million subscribers. So I think the public data has a bit of a problem in that respect, that it's underreporting certain segments of the ISP population. And I think perhaps a way to get around that -- and this is kind of the request for a future presentation -- is I've seen some interesting graphs -- I know one was in Forbes magazine because it's the one I can find online -- where people have taken these sorts of curves and displayed them for a technology over time.

How long did it take us to get the telephone, the washing machine, the fax machine, the DVD player, Internet? And the one thing I noticed about all of these things is the technology that was invented in 1900 has a very flat curve. And often -- you know, for the telephone line, it took 80 years to get to 95 percent penetration. When you look at the IPv4 Internet compared to that, it's a nearly vertical line on the same time scale. And technology, as it comes later and later, whether we're talking Blu-ray versus DVD, or any of these things, gets more and more vertical. And so the interesting thing, to me, would be to take a graph like that and look at the change in the rate of the adoption. And then project what is likely to be the rate for IPv6, which should be even steeper based on that metric.

SPEAKER: (inaudible).

MR. BICKNELL: That too. Obviously, it can't go on forever. But it would make things like your 70- or 200-year thing even more absurd when viewed in that model. And there's no one right answer here. But that might help eliminate some of the error bar function going on here.

MS. CAMP: Well, I agree that network service industries should absolutely share more data so that people can make more informed decisions. And I'm going to go ahead and say that -- you know, the California Disclosure Law, before it got passed, the lobbyists were saying, oh, we don't ever lose data, we don't need this kind of data notification act. You just don't appreciate how good we are. And then after the law was passed, the lobbyists were like, well, people are bothered. They get these things three a day, you know? So more -- without good information, it's hard to make good decisions, and I agree that that information is probably flawed. But for somebody who studies 19th century technology, that 70-year made sense. And I was talking to one of my colleagues who does diffusion studies, who basically said, six years, eight years, what -- did you check your software? Can I see these numbers? You know, because the 6 and 8 years is absolutely Internet time, and I agree with you that we see the difference between a 60-year and a 6-year, so it is possible. But I put -- I wanted to put the other standard deviation there, because I didn't want to say, oh, and if we have one standard deviation towards happiness will be in six years without showing you an idea about how much error there was in this public data. And I think more data would be great. I think it could help more -- if you could get, like, one of the ISACs, which are industry-specific, to share within this industry, IPv6 data. I mean, maybe you already do that but you didn't share it with me. That might be a great help, because these incident security analysis centers have really improved investment in security, so.

MR. CURRAN: Okay. Far left microphone. Bill.

MR. MANNING: Bill Manning, ARIN Board of Trustees, EP.net, and USC, and two or three other hats. Very interesting presentation. Thank you. I have a couple of questions, one of which is, you treat IPv6 diffusion as a homogenous activity across all industry sectors, which is not the case. It would be interesting to see it actually broken down by certain types of sectors, because I think that in some sectors, diffusion has gone much, much faster and is much more broadly deployed than in other sectors. So that would be something that would be interesting, to see if you could break that down. The second was, I heard conflicting data coming out of your mouth.

MS. CAMP: That's called uncertainty. I mean, I didn't want to put this up and say, and then God came down and carved this diffusion curve. You know, I wanted to really give you a sense of the things that I felt like I could assert, and those things that I felt I couldn't.

MR. MANNING: So let me drill down a little bit here, because Scott's actually there, so he's responsible for v6 if anybody is. All right.

MS. CAMP: Busted.

MR. MANNING: When does IPv4 -- what was the term you used -- exhaust, deplete, become no longer useful?

MS. CAMP: I understand that there -- I understood after I first wrote this -- and I have really just finished this, I mean, this -- and I wouldn't say I'm finished with it -- that I said -- that I kept saying exhaustion. And then in fact, Vint Cerf said to me don't say exhaustion. And I was like, oh -- you know, so I realized that I'm trying to use the word that doesn't pick unnecessary fights.

MR. MANNING: Right. We're not killing the last tuna here. Right? We're not making IPv4 extinct. You have also said that it's going to continue on and be useful for some period of time. And so the dividing line is to where you actually draw the start of the transition away from IPv4, and when IPv4 becomes statistically nonsignificant. That was not clear to me where that occurs, and what the characterization of where you put that line. Why did you pick it?

MS. CAMP: Oh. I picked the line so -- first of all, when we used a long tail, we got a very, very slow diffusion. And then I tried to -- so you get 220 years, you've got to say, 'Pbththth!'. Right? I mean, some findings just don't pass the moist noise of derision test. And so there must -- you know, there's got to be something else happening, and so how do you deal with this? One, you look at the diffusion. So that was my example of the IBM thing, is that you don't do fax machines from 1900, maybe we shouldn't be doing IPv6 from 2004. And that is why I picked -- when the 6bone went kind of -- dropped off, because for one thing, there was a definite drop in the data that appeared to correlate with that. And that seemed to be a very bad -- it was causing problems. It was causing -- and that's part of what was causing our huge tail. So that's why I chose that. I looked at the data, and I tried to look at the larger environment, and make an informed choice. So the data that I think we have is the innovator data, which is why the follower data has such large uncertainty. And if a year from now, we have a nice upturn -- you know, I showed you the graph and it has a little upturn -- if we have a really nice upturn, that uncertainty is going to significantly decrease. And I agree with you: How do you know when you start? Well, one thing we did is we just ran a bunch of simulations and saw which ones, like I said, passed the 'Pbththth!' test.

MR. CURRAN: Okay. We actually have a question from the table up here. Paul Vixie.

MR. VIXIE: Yes, I do. I'm wanting clarification on an implication of what you said. It certainly seems that, from what you've said, you can justify that the longer IPv4 lasts, the longer it will be before serious deployment of v6 begins. And that sounds like a no brainer in this audience. But I heard a nonlinear relationship, where if we find a way to squeak another -- you know, N = six months of life out it, I don't know, markets or revocations, or -- you know, whatever it is, that could push serious deployment of v6 off by more than six months.

MS. CAMP: Okay. So I did not mean to say the longer v4 lasts, the longer IPv6 adoption will take. I