Table of Contents
- Meeting Called to Order
- Regional PDP Report
- Internet Number Resource Status Report
- 2008-4 Minimum Allocation in the Caribbean Region
- IPv6 Routing Table Report
- IPv6 Penetration Study
- 2008-3: Community Networks IPv6 Allocation
- IANA Activities Report
- RIR Update - AFRINIC
- 2008-2: IPv4 Transfer Policy Proposal - Recent PPML Survey Results
MR. PLZAK: Welcome to Los Angeles. I want to point out real quick for those who are movie buffs and want to do a little play along, as you go through this thing, all these background billboards that you see are Academy Award winning movies. I'm not going to give you any prize for picking out what year and what they won the award for, but you're welcome to try it as you go along.
So, first of all, let's look at who is here. Well, from the Board of Trustees we have John Curran, Scott Bradner -- he's out there someplace.
Lee Howard, the treasurer, due to personal circumstances, is unable to be here with us.
Of course, I'm here. Bill Manning is right there with the Bills shirt on. And Paul Vixie's sitting up here, and Bill Woodcock, who I think was -- right now, had to be pulled out for an important business matter.
From the Advisory Council, they're all here except for Alec Peterson. Alec, at the last minute, had to change his plans and so he's not able to be here today. I won't name them off because you'll have ample opportunity to find them and to talk with them later on. From the Number Council we have three people, Martin Hannigan, and Louie Lee, and Jason Schiller.
Point of information, Louie is the current chair of the Address Council. So, he's kind of dual head and he's from our region, plus he's also the chair of that group of cats. I'm not going to name all of the RIR colleagues here because we have quite a few -- we both have staff and board members. APNIC -- there's the APNIC folks, and the RIPE NCC folks.
And from AFRINIC and from LACNIC -- so, to all of our colleagues, welcome. Glad you could make it here to be with us at this meeting.
From the staff -- the director, Susan Hamlin, and Mary K. Lee, and Leslie Nobile. Mark Kosters, and Bob Stratton, and also then, we have Nate Davis, Cathy Handley. Richard Jimmerson is not here. He's at the Internet Two conference, representing us there. And, of course, I'm here as part of the staff.
So, first of all, let's welcome our first- timers. Yesterday they had a luncheon. They met the elected members of the Board, and the AC, and from the Numbers Council. They learned about ARIN.
And we are now going to have a prize drawing. We had them fill out a survey and so, if one of them is present in the room and I draw their name, they are going to get this little -- what is this?
SPEAKER: It's a solar-powered recharger.
MR. PLZAK: It's a solar-powered recharger. Okay?
SPEAKER: It's green.
MR. PLZAK: It's green, so I guess we continue to find more innovative ways to find things to give out. So here we go.
Lee Ellis. Okay, let's -- those in the room, applaud and welcome our remote participants. Okay, we are running a pilot program during this meeting to enhance the participation of those that are unable to attend in person. And so, in addition to the traditional webcast, we're doing a few new things.
First of all, anyone that is a registered participant will be able to access a window which will show them a running transcript of what is being said.
The second thing is that there will be a number of jabber rooms set up to do several different things. The first one is the community chat, where members can cross-talk with each other -- as far as what's going on in the meeting, and so on.
There will be some enforcement of an AUP there, although it should be that -- it should be very light, if anything (off mike) really happened.
And then, the next thing is that, on stage -- in fact, Matt Pounsett's the first person to do this -- so, Matt, would you raise your hand? The person sitting in that position will actually be the virtual microphone for the people that are remotely participating. Folks can go into that chat room -- registered participants -- can go in that chat room and pose question. So, when we open the floor for comments and questions, those persons that are remote -- that wish to do so -- can put a question in the chat room.
Matt, raising his hand, will indicate this person, at that queue. And so, the chair will actually have another microphone to recognize, as he goes around and moderates the discussion.
Then, the last room is -- as you know, for every policy we look for some kind of gauge of consensus. And so, we will have a special room for registered participants where they can show their preference -- the yeses and nos -- to the chair's question. And so, when you see a count -- as a result of the shows of hands -- it will be a combined combination of the total number of people who are participating both here and remotely, and then the number of people that said yes or no to the chair's various questions.
Now, as I said, this is the pilot program. We hope it goes very, very smoothly. It may slow things down slightly as far as the room -- as the counts go, but I don't think so.
But we are very interested in any comments that we can get back regarding how this works. So, there's the experience of the folks that are doing this themselves. There's also the experience of the people in the room, as far as how that interface is working. So any comments that you can give us as we move forward, that would be great.
Now, when you come to an ARIN meeting, you get to do a lot of things. And one of the thing is that we continually ask you to fill out little survey forms -- that we do raffles in the Cyber Café. Well, the persons that are participating remotely will be able to do the same thing. So, they will have the ability to put their name in the hat and get drawn out. And if they're the ones that get to spin the wheel, they'll get to do that.
So, our eventual goal is to make remote participation as much as like an ARIN meetings as it can be. Obviously, you won't be able to virtually to the social, at least not this year. Maybe next year. We'll see how technology works. But that's the goal.
We're also looking at expanding things so that those that remotely participate, actually register do participate. They will receive the same things that people in the meeting receive. So, they'll receive the t-shirt, or whatever the vendor giveaways are. We may especially that t-shirt, so it says remote participant -- something like that, we don't know. We're still working those out.
But the idea is to broaden our participation by making the remote experience as much like the in-room experience, as possible.
Now, in a minute I'm going to go through this meeting packet. Well, on the remote participation site there is a virtual meeting packet that is downloadable, so people can download all the materials that you have here in the room.
So, who's here? Well, we have a total of 194 people, distributed as you can see. We've got 25 people, so far, signed up as remote, and 61 first-timers. And we have 45 people from outside the region -- and you can see the regional distribution from the rest of them.
Let's, first of all now, thank our sponsors, CGR and Los Nettos.
So, let me go through this participant packet. We just finished an interesting session of an hour and a half. What John would have done? Well, in you packet, you will find a letter written by Vint Cerf called, "Remembering John." This is Vint's latter -- and so it will be available on online, and website, but this is a nice printed copy for you to take with you.
So, in addition to that -- on the left- hand side -- you see information about the election -- for 2008 -- for the Board of Trustees and the Advisory Council.
Let me say a few words about elections. Elections are very, very important. And we are in a period of transition. ARIN is transitioning. The region is transitioning. A lot of things are going on. So, if there's any theme that goes through this entire meeting this week, it's going to be transition. The policy proposals are transitional in nature. What happens is going to cause ARIN, the organization -- from a staffer structure -- to transition over the next five years or so. So, there's a lot of things that are going on.
The way ARIN does its business, in terms of transaction. There's going to be some transitions in there. Of course, IPv4 goes away -- we'll have different policies about how we're going to deal with the recovered address space, and so forth. So, a lot of things happening.
So it's very important for you to vote because the Board and the AC that you elect is going to be intimately involved in these things. You're electing people for three-year terms. And so, if you are not the designated member representative for your organization -- well, let's just start that over. If you are, please vote. If you are not, and you're not sure who it is -- we have an Election Help Desk set up outside. Please stop by and find out.
So it's very, very important. So I won't say too much more on this -- other than, please vote.
You will also find, on the left side of the packet, a flyer describing our secured log-in. This is something new we've rolled out and I'll have a slide later which talks about a demo we're going to do on this tomorrow.
And the last thing on that side is -- from time to time we report to you our ability to meet our service level commitment to you. And so, the Service Level Commitment Report is there as well.
Moving to the right side of the packet, There's a reminder of the secure log-in demo. You'll find the ARIN meeting packet -- the program, if you will. I guess we could always put someone outside and roll their sleeves up, and sit there and say: Programs. Programs. You can't tell a player without a program, but this is the program of things that are going to happen.
And then, we have a discussion guide which lists all of the policy proposals, the policy proposal process, and there's also a page in the back for you to jot down a few notes. And the last thing is the ARIN Number Resource Policy Manual. So, that's what's all in your meeting packet. The thing that I didn't show you is the t-shirt, which you should have all received when you picked up your registration material. It's very important. It's been put together for you, and we hope it's helpful.
The Cyber Café is where we take our breaks. It's a place for you to get connected with -- and do some networking with -- fellow meeting participants. You can actually watch the presentations from there. And you can get an awful lot of good information. We've got some literature racks out there, and people there for you to talk about. Now, it's a little further away because of the configuration of this hotel. And it's actually the top of the stairs, in the Heinsburgen Room. That's where we're going to be doing all the drawings, and that's where the beginning of the afternoon break, all the breaks will be held.
So, as I said, we conduct surveys, so complete a survey card. And after each break -- at each break, beginning of this afternoon, we'll draw two names. And, remember, you've got to be present to win, if you're here. And, if you're a remote participant, you've got to be online to win. So, you have to be present to win.
We also have a meeting survey. We have two versions of that. We have a survey version for the persons that are here in the room, and we have a survey version for those persons that are participating remotely.
Again, complete the meeting survey and you'll be entered to win an 8-gigabyte Microsoft Zune. The winner will be announced at 5:00 p.m. on Friday, October 24th, on the ARIN website.
Now, if you don't win a prize during one of the Cyber Café survey drawings, or you didn't win the First-timer Award -- excuse me, you will be entered at first-timer (off mike) and survey people will all be entered into this drawing for the consolation prize. And you will note that the consolation prize is the best prize of them all.
So, if -- in a way, if you still lose, you still have a chance to win big. So please make sure that you enter those surveys and keep on doing it. And the winner will be announced on Monday, the 27th of October.
So, we have a few help desks. We have the registration help desk, hours are shown. And you can also meet with them by appointment. Make that appointment by sending e-mail to hostmaster@ARIN.net.
Billing? You can schedule an appointment with them sending a message to fsd.help@ARIN.net. And the Advisory Council will be running a help desk, and this is actually a chance for you to talk to Advisory Council members about the way things work, specific concerns you might have about a particular policy proposals, ideas you might have for new policy, anything that you would want to talk to them about. You can also do it by appointment, and you send a message to AC.help@ARIN.net.
So, you want to find an AC member at lunch? Well, here's a picture of them. And if you can't remember all their shiny, smiling, handsome and pretty faces, we've actually marked them for you. This time it will be balloons. So, when you see balloons at a table, that means there's an AC member there. So, if you want to chat and have lunch with an AC member, that's how you find one and -- what are you trying to say, Cathy? Cathy doesn't want -- there's something she obviously is embarrassed to talk about, so we'll talk about it later.
Okay. But anyway -- remember, the AC is here for you. They're an Advisory Council and they provide the advice to the board, but they need to know what the community is thinking, so they can put together strong advice for the board.
The social is tonight. It's going to be at Universal Studios City Walk from 6:00 to 10:00 p.m. You get to play billiards with the Board. You get to bowl with your favorite AC person. You get to rock out on Guitar Hero with the ARIN directors.
Of course, you can do all of that by yourself. You don't have to do it with those folks, if you don't want, but --
We have build-your-own-burger bar, there's assorted gourmet pizzas, there's an ice cream station, there's a free-play game room. That's where you go and use all those real trick and fancy games without having to pump money into them. As I said, there's bowling and billiards. We have a fantasy casino, and there's much, much more because this is Universal City Studio Walk. But there's plenty for you to do tonight.
And a reminder. These are the rules of the road. These are actually adopted rules of parliamentary procedure -- we just use the football referee to give you an idea what these things are about. They are explained in your discussion guide, and the chair will enforce them.
So, what's on the agenda today? Well, the standard reports for terms for the updates from the various regional registries -- global staff's report. And then we've got two IPv6 reports. One is an IPv6 routing table report, which is based upon work that's done by Gert Döring, in the RIPE NCC region. And we also have a report on the latest IPv6 penetration survey.
Now, as you recall, if you were with us in Denver or happened to see it on a website. We did a survey like this earlier in the year and we did it just in the ARIN region. This time we expanded the scope and we've run global. And we've asked each of our fellow registries to participate.
And so, we now have some -- a better global view of what happened. And so that will be presented this afternoon as well. And that information will be available on our website and will be distributed to the other registries for them to use as they see fit in promoting and distributing.
We'll have activity reports from the Number Resource Organization. We have an IETF activities report, an IANA activities report.
We've kind of grouped the agenda items here -- from the standpoint of looking at what goes on. The first set is definitely about transitions, in terms of how we do business in allocating IP addresses, in general. And the last several -- also, for example, the minimum allocation in the Caribbean region is also a transitioning type of a proposal, because this is a developing part of the ARIN region. And so, that deals with that -- in this matter of WHOIS.
I will note that several years ago WHOIS was a hot button topic for us. It got sort of subsumed by what's going on with IPv4 addresses. This is not an issue that's going to go away. I'm certain that privacy issues will rise right back up to discussions. And so, we should be geared to move ahead with those discussions.
So, there's the Internet2 netcast. I mentioned that Richard was there representing us. The netcast from the Internet Two will be shown here in the Moroccan Room on the mezzanine level on Wednesday and Thursday. That's today and tomorrow.
The agenda items and times are available at the ARIN website as shown here. Remember there's a two- hour time difference between here and there, so plan accordingly.
We will have a demo of our secure web login tomorrow afternoon, after the policy meeting.
So, we have implemented this, it's this feature on our website. So stick around and you can get a brief demonstration on how to create an account, linking two points, and managing some of your info.
So, at the head table you will see the names on the cards in front of you here. And we have John, Bill, Bill, Leo, Paul, Matt, and -- when I get back over there -- me.
So, now, on with the show. And the first item of business, actually, is not on the agenda as written in your handout. I'm going to ask the ARIN general counsel to come up and please make a -- or say a few words, as far as what's been going on lately in the legal world. So, Steve?
MR. RYAN: Thank you. The first brief report is, we haven't been sued recently -- so we're not in litigation. Nor have we sued anyone recently. So we're not in litigation. I did want to say that -- I just want to give you a brief report on the status of the legacy resource, the Legacy RSA. Right now we have signed over 140 Legacy Registration Services Agreements,and 350 (including the 140) are in process. So we have a very large number that will be signed in the near future.
So, on the Legacy RSA, we are doing something that makes people very happy, which is we're doing one-off changes when we think they're appropriate. We are working on the language of that individually, with each of the persons who is interested in signing an LRSA. And to date, we've reached agreement with every single party that has addressed us about proposed changes. So I think that process is working well and I think, actually, we're seeing an accelerating number of parties that are interested in that process.
So, I'll be sitting -- it's like law school, if you get here real early you get the back row. I got here late. I'm going to be sitting over here on the left, and if anybody wants to talk with me during this meeting today -- about the LRSA. Tomorrow I will be here early, and in the back of the room, in my appropriate place from law school.
Second, I wanted to indicate that approximately in January, we're going to roll out an entirely new RSA. And the RSA will be the first fundamental top-to-bottom review that we're going to do looking at every sentence, and every clause, and every paragraph, to see if it's A, necessary. B, could be worded even more felicitously than it currently is.
Of course, the mellifluous phrasing of the current RSA is legend in the community, and it is a state of perfection. But we may be able to improve even on its erudition, if you will. But what I think what we're going to aim for is -- to the degree that we can shorten, simplify, and make more clear, the concepts and language. We're going to do that. We're also going to create a commentary.
So, for example, I've met an awful lot of people who don't understand why we have the bankruptcy clause in there. And, you know, I think what we're going to do, is do an FAQ-type commentary -- that will ride side by side with the RSA -- that may help people understand why a particular clause is there.
Now, we're still -- when we get to the end of that process -- we're not intending this rewrite to actually increase the rights of ARIN. In other words, it's not a backdoor attempt to create a new set of rights. And while that will be the new RSA going forward, once announced to the community for new resources, no one will have to change from their current RSA. But we are going to provide an opportunity if you wanted to change to the current RSA for probably a three- to six-month period after we announce it. If you like it better, but no one will have to do that if you're working under an existing RSA.
So, I wanted to give you that update. I actually would welcome anyone who wants to come over and talk about what might be in that new RSA versus the current language, which, of course, is very beautiful. But if you have an equally beautiful suggestion that's more modern, we'd welcome it.
So, I'm not going to take any questions, but if there are any issues regarding ARIN's legal positions or our legal activity, I'm looking forward to seeing you during the break. I'm here to help, by the way. That's what auditors and lawyers say. We're here to help. And I'm here to help.
MR. PLZAK: Thank you, Steve. And, of course, I guess you could always shoot pool with Steve tonight at the social, as well. Anyway -- so now, let's now get started. The first report is the regional PDP report presented by Einar. Einar?
MR. BOHLIN: Thank you, Ray. Yes, I'm Einar Bohlin, the policy analyst at ARIN. And this is the PDP report.
So, at a higher level, if you went to all of the RIR's pages -- websites -- you could find a page about their policy proposals. And this page would tell you how many they have and what status they're in. They could be simply under discussion, last call, recently adopted, recently implemented. There's different stages.
So I went to those pages and right now there's about 31 proposals being discussed at all five RIRs. And I broke it down into five categories, as you can see. And I'll start with -- I'll mention a couple of the proposals in each of these things. I'm going to start at "other" at about 9:00, here.
So, there's four other proposals. There's two proposals at the APNIC region about NIRs. There's a proposal in the RIPE region about establishing relationships with end-users, which the RIPE region doesn't have yet. It's an indirect relationship. And the proposal parentheses shows you which ones are going to be discussed this week at the ARIN meeting, so we have one proposal about the resource review process.
Moving on to directory services. RIPE has a proposal about their Internet routing registry. It's a proposal to deploy resource PKI, and sign their data. And we have the proposal that Ray mentioned about WHOIS integrity. There are three proposals at the APNIC region about ASNs. There's one about establishing documentation prefixes -- not prefixes, but numbers. There is one about the 4- byte ASN awareness. It's to -- I think folks should know by now that starting January 1st, 4-byte ASNs are going to be issued by default. And all you have to do on January 1st is say, I prefer 2-byte. So the proposal folks would have to explain why the 4- byte doesn't work.
And, the last ASN proposal is, how to display them? Should they be displayed using a dot as a separator, or simply as an integer.
And the category of IPv6, there's one proposal still in the category of promotion. It's a workaround to the 200 customers in a certain number of years requirement. Similar to the ARIN policy which says, 200 customers in five years or be a known ISP. And that's moving forward in APNIC.
There are some assignment proposals. Two have gone forward in the LACNIC region, to allow end users to get IPv6 assignments. One for folks that already have the 4-space, and one for brand new requesters.
And the RIPE region is working still on their IPv6 PI policy, but it's kind of been hindered by the relationship, or the contract proposal, that's in the other category. RIPE region still has ULA Central active as a proposal. And there's a couple of allocation proposals -- we have the community networks proposal. and LACNIC has a proposal about allowing ISPs to do traffic engineering. Their policy requires the single aggregate to be announced and only the single aggregate.
And last, but not least -- IPv4, which is definitely a growing category, with 10 items about depletion. So the global policy proposal about what IANA should do with the last 5 /8s -- that they should issue one to each of the RIRs -- is moving forward, and it's still in a couple RIRs, but definitely progressing.
Then there are a few proposals about what to do with that space. We have a proposal here that proposes what to do with a portion of that last /8.
LACNIC already moved something forward and made a decision. And it's also being discussed -- what to do with the last /8 -- at APNIC. There's an assignment proposal -- RIPE is looking at adding ENOM to their (off mike) casting policy, so that ENOM folks can get v4 assignments. And there are a few v4 allocation policies, including ARIN's Caribbean policy proposal to lower the minimum to a 22.
Here's -- this chart shows the seven proposals that are going to be discussed here at ARIN. And it shows you if such a thing has been proposed, or discussed, at the other RIRs.
Two of these are the transfer proposal and, of course, they've been discussed at APNIC and in the RIPE region. I just mentioned the 2008-5 is what someone's proposing here that we ought to do in the ARIN region, with a portion of our last /8. And I mention it's in -- it's actually moved -- it's in last call at APNIC, and it was adopted by the LACNIC folks. And the last one there, the 2008-7 -- something similar was adopted in the APNIC region a couple of years ago.
So, I mentioned that the RIRs have a page where you can find information about their proposals. That's the first five links here. The last document, the NRO link, is a comparison overview. For example, if you'd like to know what the RIR's minimum assignment -- IPv4 assignment prefix size is instead of going to all five RIRs and digging for that information, you could go to this document and use the table contents, go to v4 assignments, and side by side, you could see what the different RIRs assignment policy was.
That's it. Thank you.
MR. PLZAK: Any quick questions for Einar? Okay, thanks, Einar.
The next report will be the Internet Number Resource Status report, presented by director of Registration Services, Leslie Nobile.
MS. NOBILE: Okay, good morning everyone. Okay, the Internet Number Resource Status report.
This is prepared quarterly by the five RIRs. It's the joint statistics of all the RIRs, it tells the status of IPv6, IPv4, and autonomous system numbers. Unfortunately, we were unable to coordinate and get this one updated for the third quarter, so these stats are current as of June 30th.
So we'll start with IPv4 address space. This is the status of the entire global pool of v4 addresses.
Starting with the top pie on the left, I'm looking in the gray space, IANA reserved. It's probably the most interesting portion of this for most of you. There's 39 /8s left in the IANA reserves -- in the global pool of addresses for IANA to issue to the RIRs. There's -- looking above, in the green -- there's 35 /8s that are not available to be issued. They've been held for special purposes by IETF and IANA. There are 91 /8s that were issued in the pre-RIR days. These were issued by the early registries. The IANA, the SRINIC, DODNIC, and the InterNIC.
This is where most of the legacy address space resides. And then, the RIRs have been issued /8s, collectively, by the IANA. And the breakout further of that is just below. And you can see that ARIN has been issued 29 /8s by the IANA; APNIC, 28; RIPE NCC, 26; LACNIC, 6; and AFRINIC, 2.
So, I added this slide in here. This is not usually part of this, but at the last meeting someone said, well, where does all that legacy space reside? Can you, you know, tell us about what the RIRs are doing, we know where that is, but we don't know where the legacy space resides. So, we produce two slides here -- two pies, two donuts, whatever.
We did -- on the left, the graph shows legacy space, including the Class As. So, 73 percent -- a little over 73 percent resides in the ARIN region. And you can see the rest: RIPE NCC region, 12; APNIC, 4; et cetera, et cetera. But when we looked at the Class As, there's 41 of them that have been issued and about 25 percent of those went to one organization, which is the U.S. Department of Defense. They have nine. So, we thought, let's take those out. Let's remove it. It kind of skews the data. We'll just look at the class B and C addresses, so when you do that, it's slightly different. But, as expected, most of the legacy space resides within the U.S. -- within the ARIN region.
This is the IPv4 space issued by each of the RIRs to the customers over the years. We've gone back as far as 1999 and just tracked it up through June 30th of 2008. Really, growth up and down -- early growth in the ARIN region, and then, just quite a mix in the middle years there. And in recent years, we've seen quite a bit of growth in the APNIC region and in the RIPE NCC region. You can see them in yellow and in green.
Last year, the five RIRs together issued almost 14 /8s together. So, v4 space usage is increasing, particularly in APNIC and in RIPE. In ARIN it's been pretty linear, pretty flat growth over the years. And it seems to be the trend for this year, as well.
This is a cumulative -- it's the same slide, but the cumulative amount of space that we've each issued to our customers over the last nine years or so -- with both RIPE and APNIC issuing more space, cumulatively, than ARIN has.
ASN assignments. Early on ARIN was issuing quite a few ASNs. That has steadily decreased over the years, but the trend has sort of reversed in the RIPE region. They are now issuing more ASNs than any of the five RIRs.
A cumulative look at that, with ARIN issuing most of the ASNs still, although RIPE is growing fast.
Okay, so, we're going to look at the IPv6 address space. This is the total pool, the /0s. Total pool. The /3 has been reserved and set aside by global unicast by IETF. So, IANA holds 506 /12s right now in the v6 pool, which they will be issuing to the RIRs. In 2006, there was a global policy passed and it said that IANA would issue each of the five RIRs a single /12 for their customer growth. So, you'll see that up on the right.
Prior to that, IANA was issuing space to the RIRs in smaller chunks. So they took a single /12 and was issuing /23s to each of the RIRs. You can see that RIPE got 15; APNIC got 7 of them; ARIN, 5; LACNIC, 1; and AFRINIC, 1. And three were set aside for special purpose.
This shows the growth trend since v6 was issued, starting in 1999. We thought there would be a lot of growth early on, but that really tapered off 2003/2004, except in the RIPE region, where we saw continued growth. And then 2005 and 2006, everything went down again. It's just been very unpredictable. Every year has been something different.
However, 2007 and 2008, we're seeing some real clear growth in the RIPE region. They are issuing more IPv6 address space than any of the other RIRs. We've seen some growth in the ARIN region, as well. LACNIC region, as you can see, is growing, as well. APNIC has been pretty flat over the last couple of years.
So, this looks at the number of allocations that we've each made, and you can see RIPE has made almost a thousand allocations, just single allocations: AFRINIC, 46; LACNIC, 143; APNIC, 384; and ARIN, 433. But when you look in terms of the total /32s that account for -- /32 being the minimum allocation size, the picture is very, very different. And what it indicates is that some of the larger RIRs are issuing much larger allocations than single /32s. They're issuing /20s, /21s, /22s. ARIN, recently also, has joined the crowd and we've issued several very large allocations. So, that accounts for those large numbers on the right side.
This is where -- these are links to the RIR's stats. All the RIRs have them. The NRO has them. The IANA has all the historical data -- and that's a good site to go to for statistics. And that is all I have. Are there any questions?
Okay. Thank you.
MR. PLZAK: May I assume there are no questions in the queue?
SPEAKER: Not yet.
MR. PLZAK: Okay, thanks. We are now on to our first policy proposal of the meeting, 2008-4, The Minimum Allocation in the Caribbean Region. This was introduced in May of this year. It's been discussed twice at the sector meetings that have been held: One in Kingston, and the other in Nassau. And it's been revised; the current version is in August of this year.
No discussion of a similar proposal in any of the regions. The text is in your guide, and it's also available online. Basically, what this does is -- it lowers the minimum allocation to a /22, for ISPs in Caribbean region. The shepherds are Heather and Matt. Staff sees no -- from a legal perspective -- no liability risk. We have some comments and concerns and, basically, it does not include end users, so we're just saying, is this a fair consideration?
And, from a staff perspective, impact is minimal from the terms of resources. We could do it within 90 days. The assessment that was done is available at this URL. So far there's been some discussion on the PPML, and some comments are that lowering this barrier would tend to facilitate the achievement of effective competition in the Caribbean.
Attempts to define special areas, are bound to be wrong, complicated, or unfair. So, no support for special geographical areas. And so, should the language be ARIN service region, not including the U.S. and Canada. In other words, another way of defining who gets this.
So, Policy Proposal 2008-4, I believe, Paul? You're going to present it. Okay, please come up.
MR. ANDERSEN: All right, good morning. As a little bit of history -- so, this policy comes out of some discussions that occurred back in the ARIN meeting in Denver -- during the open policy hour. There, there were some concerns identified that currently exist in the Caribbean sector. The fact that a lot of countries in that region -- there is still either is or is a de facto monopoly existing. And this makes it very difficult for a lot of ISPs to -- they're trying to start up or grow to obtain address space -- either because, first of all, there isn't another provider to multi-home and because they are smaller markets, they can't meet the policy thresholds for an allocation right now, which would be a /20.
So, there was some thoughts that we -- you know, some of the benefits, if there was a specific policy, it allows competition, more choices for end users in those areas. It lowers the barriers to further multi-homing as more organizations come and, of course, increases participation in ARIN.
So, after that discussion, Cathy and myself decided to draft a policy and when we were trying to think of what the text would look like, we remembered that there's some precedence to this. Back in 2003, when the sub-Saharan Africa was still part of the ARIN region, before it moved over to AFRINIC, there was a policy proposed back then that was eventually passed to drop that allocation.
So, this text, which is the current one, is effectively -- is that policy back from 2003, with simply now using the term Caribbean portion of the region. The idea of the text is to lower -- specifically target organizations that are not multihoming, to lower the allocation from a /20 to a /22. I would point out also that it's come to attention that there is text discussing the multihome organization, but this text here that I'll highlight, is actually -- is current ARIN policy right now. So, it is a little bit redundant, but it's in there for now.
So there's been some feedback on PPML regarding this policy. One is that we should change the policy to enumerate the countries that are actually covered by the policy. But the authors really feel that we don't want to do that kind of micromanaging. We really feel that's staff's job to enumerate those countries. There's also been a lot of discussion whether or not we should add other areas, sparsely populated areas. And while we have no problem with having such a proposal, we really think that should be a new proposal -- it can use the same text. But we don't have to lose another cycle to add these regions. And, based on our discussions with staff, our understanding is there has not been any request from those areas that aren't identified in this proposal, for change. However, the Caribbean sector -- members there have expressed concerns to staff to lower that.
And with that, (off mike), I don't think.
MR. CURRAN: Thank you, Paul. Okay. Good morning. We've reached that point for discussion on this policy proposal. So, the microphones are open. I'm going to remind everyone that the rules for the microphones, we take them in round robin order as people are available at them. Please state your name and the affiliation clearly. I'd like to identify whether you're in favor or against the proposal. If you can at least start your comments that way? I'd ask everyone, comment on it, but to the extent that you've already commented, wait until others have had a chance before taking a second stance at the microphone. All of the microphones are open. Thank you.
Yes, front and back.
MR. FARMER: David Farmer, University of Minnesota. I'm in favor of the proposal with some modifications.
I'm concerned with the definition of the region. I've sent out on the list -- it says Caribbean region -- that the staff interprets that as including Bermuda, and the Bahamas, and Turks and Caicos. A precise definition of Caribbean doesn't necessarily include those from a geographic region.
There's political definitions you can use, but they may or may not include other pieces.
I proposed a solution of adding "Atlantic" to it, which would then clarify that. And bring in any of the other inhabited islands that was mentioned before.
MR. CURRAN: Okay. Unchanged, would you be in favor of the proposal?
MR. FARMER: Undecided.
MR. CURRAN: Okay, thank you. Next, at the microphones center rear?
MR. HANNIGAN: Martin Hannigan, Bahamas TEL. I think that the word Caribbean is all over the island, so I would be surprised if we weren't part of the Caribbean. And I think that anything south of Florida that's defined as being part of the ARIN region is intended to be included in this policy, at least from my understanding. I don't know about Bermuda, though. It's a good point. Bermuda's kind of east, it's not south of Florida.
But I support this proposal and thank you.
MR. CURRAN: Okay, thank you. Okay, center rear mike, yeah?
SPEAKER: They're an ARIN advisory council member. I am in favor of the intent of this proposal, but I believe it is a mistake to not just to enumerate the countries to which -- and the islands to which it is supposed to apply.
MR. CURRAN: Okay, as written you would not advance it because of that flaw?
SPEAKER: I believe that that flaw can be fixed relatively trivially without changing the intent of it.
MR. CURRAN: Okay, thank you. Yes, far right?
MR. CASSIMIRE: Nigel Cassimire, Caribbean Telecommunications Union. And we have stated before, at (off mike) meetings and was, on the list, support for this proposal. Hearing some of the comments being put -- personally, I really do not have difficulty, if the intent of this proposal is also relevant in other sections, or trying to enumerate the countries to which it applies, and so on.
But certainly, what we would like to have is progress towards adoption of the proposal from the Caribbean. From the Caribbean's point of view, because -- you know -- it was mentioned by the presenter that Caribbean nations and stakeholders, in fact, have expressed some concern about the current allocation policies which this would help to solve for us.
So, what I'm hearing is general support for the intent and maybe some little bells and whistles in terms of making it,more specific in terms of the countries it covers, and so on. Which, already, I'm not at difficulty with, but I would support it as written. And I don't think that the comments I've heard should prevent it from going forward, if even at some later stage we seek to expand it or make it a little more precise. Thank you.
MR. CURRAN: Thank you. Center rear microphone?
MR. WILLIAMSON: David Williamson, Tellme Networks. I support this policy as written, entirely. I think waiting six months to clarify some details is not in the best interests of ARIN or our Caribbean members.
I would like to see clarification of, you know, the geography involvement, at some point. It could be something as simple as just a reference on the countries list, on the ARIN website. Just put an asterisk next to the ones that are the Caribbean region, as expected by staff, and identify those as the Caribbean region. I just would like to see, you know, that kind of clarification of geography, but I don't see any reason to delay for that purpose.
MR. CURRAN: Okay, anyone who is -- setting aside the specification of the region and clarity involved, is there anyone who would like to speak against the intent of this proposal? Anyone who thinks the proposal to change the boundary is a bad idea for this region? I really need to solicit people from both sides, but I can't seem to find anyone for the other side.
Okay. Any one further like to comment on this policy proposal? Okay. Thank you very much. I'd like to thank our presenters. Okay. At this time it comes to the point where we ask people to give us a show of hands, so that the AC can have that guidance in doing their job. So I'm going to make sure that our polling system is ready. Okay. On Policy Proposal 2008-4, Minimum Allocation in the Caribbean Region, all those in favor of the policy, raise your hand.
All remote participants also vote, if you're in favor. Nice and high.
Okay. Thank you. All those opposed to Policy Proposal 2008-4, raise your hand now.
MR. CURRAN: Okay, thank you. Tabulation is happening. While we're waiting for tabulation, I'll sing for everyone. No.
On the matter of Policy Proposal 2008-4: Number of participants, 142; in favor, 64; against, 0. Thank you. This will be provided to the Advisory Council for their deliberations.
Back to you, Ray.
MR. PLZAK: Thank you, John. Okay, that takes care of this morning's business. And actually, we're a little bit ahead of schedule but that's great. So just a reminder, the Cyber Café is where you can take a break, get connected and watch presentations, and so forth.
Remember that it is located at the top of the stairs, in the Heinsbergen Room. And remember, we'll be doing surveys.
Reminder on the help desk hours. And since this is a lunch, you have an opportunity to find an AC member. Here's their smiling faces again. Just look for the balloons and you'll find them. And, remember, they're here for you. So, let's thank once again our sponsors CGR and Los Nettos.
And security -- please take your valuables with you. This general session room is not locked and there is no security. So, we'll see you back here at 1:30 for this afternoon's activities. Thank you very much.
(Whereupon, at 11:56 a.m., a recess was taken.)
MR. PLZAK: Hope everyone had a good lunch. And we'll get ready for this afternoon.
Okay, first of all, a reminder about the social. It's tonight. And a reminder of the rules of the road. When I do the announcements later on today I'll tell you some more details about the logistics of how to get to the social and back. But reminder about the rules of the road as far as things go, and the chair will enforce them.
And the head table. You can see their names spread across here. We have John, Paul -- actually, Bill, Scott. Marla is the -- look for a microphone, wherever she went -- and then me.
MR. PLZAK: So, anyway, so we're on to the first event of the afternoon. It's going to be a report presented by Cathy Aronson. It's the work of Gert Döring of the RIPE NCC region. And it's a report about the IPv6 routing tables. So, Cathy.
MS. ARONSON: Howdy. It's always so much fun to be right after lunch because everyone is kind of comatose. It's really great.
So, I just saw Gert probably added some things in the slides I haven't actually seen yet because he tends to like to do that just for fun. But, he's been doing this work since I think 1998- ish. And I think I've been presenting it in other regions since then. And I sometimes think that that might make it so that I understand some of the slides better and I don't have to ask him 150 questions every time. But he's always really patient and he answers me anyway. So it's really kind of nice.
Let's see. How does this work? Okay, wait, I want to go to -- okay. Have we reached 1,000 prefixes yet? Last time it was no, but yay, we have. So the v6 running table has actually exceeded 1,000 prefixes, which is just totally exciting.
SPEAKER: And then they dropped down again.
MS. ARONSON: What?
SPEAKER: And then dropped down again.
MS. ARONSON: Yeah, but that's only -- yeah, well, we'll talk more about that. Okay, let's see.
So this is sort of an overview. There is some pictures. There's some trends. There's some numbers. There's a lot of really interesting things that shouldn't be happening. And it's kind of cool because at NANOG, Richard talked about the routing database, and there's some information in here about the v6 version of the routing database which seems to be just as messed up as the v4 version of the routing database.
So this is the, you know, all you can eat graph, you know, from 2002 to January of 2008, up and to the right. There's some interesting things.
Oh, he did add a slide I haven't seen before. Great.
There's some interesting things that have been happening that we'll talk about on some later slides. People have been leaking. There's a whole bunch of Korean stuff that's been leaked through some of the U.S. research networks. Shame on you. So that makes some of these little blips in the graph. And then there are some trends. It looks like it might be getting steeper. We might be getting more v6 out there maybe in the routing table because it was kind of flat, and then it got a little steeper, and then it got a little steeper.
Oops, wrong way. Sorry. This is per RIR regions, so like ARIN is green. And the little bleepy thing in the ARIN region and in the APNIC region were some leaks of /48s. And you can see that RIPE still has the most volume of v6 addresses in the routing table.
This is for the last 24 months. It really is starting to get steeper. Let's see. Am I going backwards? Is that the problem? I'm going backwards. There we go.
So this is per country and the RIPE region because Gert's from RIPE, so he always broke it out by country. So you can see that Germany has the majority of the address space over there. And this is for APNIC. The little dash stuff is some stuff that got leaked, and the Korean in pink -- there's lots of more specifics that got leaked into the routing table. It's really -- it's sort of like v4 before we started filtering.
And in ARIN the country statistics aren't super useful because it's all squished down at the bottom. But that's broke down by country.
Let's see. And then this is LACNIC. And this looks kind of freakish, but if you look at the difference in the scale of the number of prefixes, when a few go away in the LACNIC region it makes a big huge stair step thing because there's only like 20. You know, the scale is 20 instead of like 300.
So, AS numbers visible in the routing table. The way this works is there's 776 origin only and then the number that's in parentheses is on 5-4-2008. That was like the last measurement he did. So there are 1,109 unique AS numbers in the routing table, and then there's 776 origin only. And there's no more -- finally, thanks, Bill Manning, there's no more 6-bone address space being advertised.
There's 917 ASs that originate in one prefix, and then there's various others that are announcing more. Let's see.
SPEAKER: I can fix that for you, Cathy.
MS. ARONSON: I know you can. And you will, right? Because I love giving you a hard time for having that advertisement.
So what are some of the reasons why people are announcing more than one prefix? Some people are still announcing in the beginning the minimum allocation was a /35, and then it became a /32. And some people, you know, they got slid up to a /32, so some people are still advertising both -- the longer and the shorter. There are some places that are advertising the more specifics of the Internet exchanges. People buy other networks and then announce their specific routes. And there's a whole lot of PI /48s being advertised individually.
A little bit of sidetrack, and this actually follows on from some stuff we talked about at the open policy hour. There actually are people using 32-bit AS numbers, but if you don't have the right software, you can't see them. So at the top you can see, you know, 2.3, 2.7, and on the bottom they just show up as 2, 3, 4, 5, 6. So if you have 2, 3, 4, 5, 6 in your AS paths, you should try to maybe upgrade your software so that you can actually see that it's what the AS number really is.
Let's see. This is a breakdown of the number of different kind of prefixes. So there's a whole lot of /32s going on. And we'd expect that because that's the allocation.
There's also though 384 global /48s, which is a trend that's pretty interesting. And there's a breakdown by region. And then there's some other stuff in between. Some people have gotten bigger allocations than a /32, as well, and those are above.
This graph -- I've been talking about this graph since 1998, and I still have a hard time explaining it. But there's two measurement points in time, one in 2008 and one in 2007, and those are the -- that's the amount. And then the little bar thing that goes up is how much it fluctuates throughout the year. So some of these, like for a /40, there were -- let's pick one that's easier. For a /64, there was like one, but at one point in time there were 10. So that kind of gives you a little bit of an idea of each kind of breakdown of prefix and then how much it fluctuates. He calls that an experimental slide. So if you have any input, we'd appreciate that.
This is a breakdown of allocation per region. And what's interesting is even though RIPE has a significant, you know, the most allocated, it's still -- percentage of the membership, it's pretty consistent with the other regions. Everybody's around the, you know, mid teens of the percentage of their members that get address space.
And this doesn't include micro allocations. Let's see. And of the 949 -- there are only 949 allocations visible on the routing table, which is like 40 percent of what's actually -- 45 percent of what's actually allocated, which kind of stinks.
So this is a really interesting graph. The solid purplish -- is it purplish? The one that's to the left in each year is what was allocated that year. And then the little dashed ones are for the subsequent years -- how many of those that were allocated that year were advertised.
So a good year to look at would be like 2004. So there were like 200 and some allocations made, and in any of the subsequent years there were less than half actually showing up in the routing table. And like for 2008, there was a whole bunch of them allocated. And there's only 150 of those in the routing table. So it's really pretty abysmal. People are either -- I'm not sure whether people are speculating, or not ready to advertise, or just getting it as a check off list on their deployment schedule, or what. But a lot of it is not getting advertised even over an allotted time. Because even in 2002 there were 100 and some prefixes allocated and less than 100 are still on the routing table even this year.
Let's see, allocated versus routed in each region. So in the ARIN region there's 459 allocations, and 183 of them are visible in the routing table. And what I like is of the critical infrastructure blocks you'd think that they would be really critical. Less than half of them are in the routing table. And it's the same for the other regions. So in RIPE there's, you know, 1,052 allocations given to LIRs, and half of them are in the routing table.
If anybody has any idea why that is, it would be great to hear.
And then this is our speculation about why. Are they early adopters and they lost interest? I kind of like that one. Are they getting ready for the future but not ready yet. Using them internally? Maybe. And it doesn't really reflect whether it's commercial or academic.
It seems pretty uniform, like what's in the routing table.
And if there was just a delay, like, okay, I got a block and I'm not quite deployed yet, but why would you get a block in 1997 and still not advertise it in 2008? I don't really know.
Let's see. These are notable allocations, new PI blocks that were given out to various places.
So in APNIC there were nine new PI blocks, and in LACNIC there were four.
None of the -- it also says how many are in the BGP. There were 51 /48s given out -- PI blocks given out by ARIN. And what's really cool about it is that they're all being advertised, I think, in the next slide. In one of the next slides they're all being advertised as /48s from the same router and not a block. So it's like the same exact path but they're individual /48s.
There's also some very large allocations that have been seen. They're listed at the bottom.
So you might want to check if you actually are filtering, that you're letting those in.
There were some really interesting leaks. Indonesia leaked 16 /36s and 256 /40s over New Year's, which is pretty cool. And it seems like people are still not filtering what they give transit to, so people are readvertising those to whoever will listen. So it's really sort of like before we did filtering.
There's a lot of -- what is this one? There was a lot of leaked more specifics to HENET, and those Korean more specifics that we saw on the block where it went like in a big jump were a whole bunch of more specifics that got leaked that weren't filtered.
And it seems like a lot of the research networks don't have necessarily the best connectivity to the v6 network. And so there's a lot of like really long paths through tunnels and a lot of leaking going on that's really causing some disruptions. And the Korean network only has Internet II as transit, so like there's just a lot of -- a lot of filtering should be happening that isn't, basically.
And then this is what I was talking about. There's 34 /48s that are being advertised that are all from the same router, the same hop, the same everything, that could actually be an aggregate, but they're not. Nobody really knows why.
Oh, this one is really great. So, they got allocated 2-6-07:F350, but they decided to leave the 0 off. So for a while they are advertising the completely incorrect prefix because the zero is actually significant. Oops. So the zero actually makes a difference. I know they're long, but anyway.
This is the route objects in the RIPE database compared to the routes in the routing table. And it's not necessarily that there is a 1:1 mapping between the route objects and the actual prefixes. We'll talk about that in a minute. But for the first time we actually have more objects than we do routing prefixes in the routing table. It used to be that there were way less. So people are starting to actually put stuff in the routing database. But as you'll see it's not necessarily accurate.
So there are 492 BGP routes in the RIPE region and 630 route objects. And they don't match.
So there are 43 route objects for things in other RIRs that aren't even in, you know, the RIPE region.
And there's a bunch of multiple route objects for the same thing. The same kind of thing that Richard talked about at NANOG.
So here's the breakdown. So there are 358 prefixes where the route object matches. There are 125 where there isn't one. And there's a bunch where they don't match. So there's, you know, I guess if you wanted to use it to filter it would be pretty hard.
And then there's other region entries, and they're pretty messed up, too.
So, he always like to add this slide. It's really easy to add your route object. This is what it looks like so you can probably add it.
Let's see. And then these are just some references. Does anybody have any questions? Does anybody know why, like, people would get address space five years before they need it and not put it in the routing table? Heather.
MS. SCHILLER: I don't have an answer to your question, but I had one of my own. Back on -- and the slide doesn't matter so much, but slide 13 you talked about /35s to /32s. And I found out recently that ARIN converted all of the legacy /35s to /32s. And I was wondering if any of the staff from the other RIRs could let us know if they did the same or if those are still listed as /35s.
MS. ARONSON: Because it used to be a choice, right? You could either choose to get a /32 or not.
MS. SCHILLER: I think /35 was the minimum allocation window.
MS. ARONSON: Right. It got changed.
MS. SCHILLER: It got changed up. And then my understanding was you had a choice about whether you wanted to move into a /32. But ARIN staff just went ahead and upgraded everyone. So I wasn't sure if all the other RIRs had.
MR. CURRAN: Leslie, do you want to respond?
MS. NOBILE: I do for ARIN staff. We actually sent notification to every person who had a /35 giving them the option and telling them that if they didn't choose we would upgrade them to /32s.
MR. HUSTON: Geoff Huston, APNIC. We did much the same but I'm not sure what the consultation process was. But basically the /35s got additional space and they were given space to get them up to /32s.
SPEAKER: Any other RIRs?
SPEAKER: Actually, when (off mike) was established we already were established /32. The /35s that were allocated in our region were originated by ARIN. But I do believe -- I was not at that time, but I do believe there was a process.
And those same organizations have already /32. Some of them are still announcing the /35s. Yes.
MR. CURRAN: Any other RIRs want to --
SPEAKER: Is Owen next?
MR. DELONG: I think so. Owen DeLong, ARIN AC, Vusion. Vusion has a /48 that we're not announcing yet because, well, getting it through engineering that we actually need them to put the product on IPv6s is harder than one might think. DeLong Consulting has a /48 that we will announce as soon as we can get a provider that will announce it.
MS. ARONSON: How long have you had them though?
MR. DELONG: About a year and a half now.
MS. ARONSON: Okay. Aaron?
MR. HUGHES: I'd like to make a couple of comments.
MS. ARONSON: Yeah, you have to say who you are first.
MR. HUGHES: Sorry, hi, I'm Aaron Hughes, representing lots of companies.
I've noticed the turning up BGP v6 peering. A lot of people have problems with leaking prefixes and it has to do with some different syntax in CISCO specifically, and a couple of bugs in some of the old standard access lists. So I've had conversations with several people who have turned up peering and letting them know that they're doing this. And they go, oh, wow, it's just a little bit different than we expected it to be. And they correct it.
But a lot of people aren't really watching the table very carefully. So they're not talking back to their peers, and they don't really care if they're leaking transit because it's not that much traffic and it's only 1,100 prefixes. They'll start noticing soon enough.
And the other issue is in terms of the number of allocations or the number of /32s that have been allocated and not been announced is right now it's still very difficult to get your providers to announce v6. And if you're just doing it with peering, which is perfectly fine, it's not stable enough to start adding -- assigning secondaries to your customers and start dual stacking them because, you know, the small number of peers you can get makes it much more likely that you're going to go off the net. And there are only a few people out there that are actually willing to provide transit over peering fabrics these days.
So I think it's all the edge providers are waiting for 701, and 1239, and a few others to start transiting them everywhere.
MS. ARONSON: Okay, thanks.
MR. HUGHES: Just an opinion.
MR. SINATRA: Just to follow up on the same point.
MS. ARONSON: Michael, who are you?
MR. SINATRA: Michael Sinatra, UC Berkeley. To follow up on the same point, you do see cases where you have -- because we don't have a ubiquity of IPv6 transit service available, you see places that have their own address. They are announcing it to peers but they don't have any transit. And a really good example of this is actually, I believe, Hexago. So if you go to www.ipv6book.ca, ironically enough you will see that it's advertising a quad A record and you probably can't get to it over v6. And that's an example.
MS. ARONSON: Interesting.
MR. SINATRA: They just can't get transit. So they're peering. They actually have the kahunas to actually put their website on v6, but most people can't get to it. And depending on where you look, you may not be seeing that.
MS. ARONSON: Yeah, this point of view is only from Europe, so that could be. I think Randy is next. No? Oh, Leo.
MR. BICKNELL: Leo Bicknell, ISC. Randy likes to go last.
A couple of interesting perspectives I think that explain some of this behavior. One is I know of several companies that got a /35 or a /32, you know, some number of years ago. Used that in a lab with tunnels. And the entire purpose of it at that point in time was to beat up vendors to ship gear that supported IPv6 properly.
Those networks then got gear that support IPv6. Most of them are actually in pretty good shape from a hardware perspective. The lab was torn down, and they are now waiting for the business case to redeploy that network as an actual IPv6 service.
So I think that explains some of the ones that were gotten a long time ago. Might have even been visible a long time ago and have now disappeared. And it's kind of like why does this person have a five year old prefix they're not using?
The other interesting thing that comes up is looking at the critical infrastructure and micro allocations. I think most of the people playing in that space are being very forward thinking, and that they are also thinking across their whole line. So, for instance, we operate sites in 45 different countries around the world. We are making our IPv6 plans for all of them because that's where we need to be. The reality is in some of those v6s ubiquitous and we can get nine transit providers, and in others it may be 20 years. But when we go to RIRs, we're going to make bulk requests for what we need for all of them because it just makes sense. It's less paperwork for us; less for them.
So I think when you see a lot of these /48s and stuff, that's not a trend that's going to continue over the long haul. That's these people being forward thinking, getting what they need, and hopefully in another year or two that will really kind of drop off back into the noise.
MS. ARONSON: Randy? I think there's no one else so that makes you last.
MR. BUSH: Randy Bush, IAJ. You know, we looked at some of the same statistics over the last decades for IPv4. I wonder, can we compare? I have a feeling we're not inventing too many new bugs here. Too many new screw ups. We're just doing it in IPv6 now.
MS. ARONSON: No, it seems like the screw ups seem to be the same. But I could ask Gert. I mean, he probably has looked at that.
MR. BUSH: You know, it's like the delay to announcement. Just we'll feel it's a little worse, but I really -- I think you could quantify it. You could actually look. It would just be interesting.
MS. ARONSON: Okay, cool. Heather?
MS. SCHILLER: Heather Schiller again. I still would really appreciate hearing from RIPE and AFRNIC.
MS. ARONSON: Oh, about the /35?
MS. SCHILLER: /35 to /32.
MS. ARONSON: Does anybody from RIPE or APNIC want to --
MS. SCHILLER: AFRINIC. Geoff talked about APNIC.
MS. MATIC: (off mike). We had a long time project, long before the time I started, where people got allocated, because we had reserved space.
So they got allocated altogether /32. It was also advised (off mike).
MS. SCHILLER: But they were all upgraded?
MS. MATIC: Yes.
SPEAKER: I think they were all changed.
MR. SEKIKUBO: AFRINIC never gave any /35s or /32s.
MS. ARONSON: Oh, great. Thank you.
MR. PLZAK: Thank you, Cathy. The next report is going to be done by K.C. It's the latest IPv6 penetration study. And I think there were over 1,000 participants in this survey. K.C.
MS. CLAFFY: I was really nervous about giving this talk but Cathy totally calmed me down because there's nothing in her talk that disagrees with anything in the surveys at least.
We did the survey -- a similar survey. Where do I point this? At you? Forward? Great. I broke it already. I just barely touched it. There you go. Push it hard?
Sorry. So we did a survey similar to this one in April -- March. We did the survey in March.
I presented the results in April at the last meeting. That was ARIN region only. And so this survey is building on that survey, trying to learn from the mistakes because frankly I had zero experience writing surveys before this, and I'm learning a lot. Unfortunately, on-the-job training here.
I'm going to skip this first slide. I'm going to go through these slides pretty fast because we don't have a lot of time.
This new survey -- well, the surveys in general were in response to the fact that it's really difficult to measure IPv6. And I think we've seen this in the last couple of days, so this is kind of a related work slide on all the different activities trying to measure IPv6. I'm not going to go through that stuff in detail. You've heard about them in previous talks. You can go look them up. I put Google down there because I just saw a Google trend, kind of IPv4 versus IPv6 trends linked from Geoff's blog about IPv6 actually. And I just saw it yesterday.
But I suspect that since Vint said Monday that Google is doing a lot of IPv6 -- supporting IPv6 -- that we could just ask Google to post trends of IPv6 to their website. To their Google6 website over the years. And that would be also a good baseline.
But in any event, lots of measurement activity spans a couple of -- three orders of magnitude in absolute numbers of v6 penetration. So that makes a scientist kind of squirmy. It makes me kind of squirmy anyway.
But I do want to mention because -- who was it this morning that talked about research -- talked about research and government being able to bridge the gap here a little bit. There is quite a bit of activity in that going on to the extent that resources and budgets allow. And, in fact, I met with a guy who's in charge of -- one of the guys in charge of putting IPv6 support into DREN, which is Defense Research and Education Network for DOD. And they claim to be one of the few agencies that, in fact, made the IPv6 deadline for OMB in June of this year. They turned it off right after that, of course, but they're one of the few that made it.
And they're spending a lot of time. Ron Broersma has given talks at Joint Tech meetings. They're spending a lot of time trying to go through exactly what works and what doesn't in IPv6. So the URL at the bottom that you can't read, but you download the slides later and look up that URL. You may find it depressing about v6 because it short of shows a lot of problems that they're still finding in v6, but you'll kind of be cheered up about the U.S. Government putting some resources into figuring out what the problems are.
So here's the bottom line about all this "science" -- scientific measurement activity going in in v6. We don't even have a rigorous definition of what it means to be using IPv6 yet, so that really gets us off on a weak footing. And of course, just like many other -- or you could say any other -- Internet data questions, there's a strong incentive not to provide access to data even if the data does exist. In the case of IPv6, often the data doesn't exist. Internet II is a classic example. Research and education network for the academic community or any community wants to be able to measure v6, has vendor hardware in its network that isn't capable of doing net flow for v6. So we don't know how much v6 traffic is on the research backbone for the academic community. You could call that a technical issue. You could call that an economic issue. You could call that a user demand issue.
So what do people do instead? Well, as we've seen this week, you find some dataset under the couch that looks like it might be marginally related and then you throw some liberal assumptions in there and you decide that that's a measurement -- metric for v6 gross or penetration. Or you fall back to whatever your trusted ideology is on whether v6 is going to happen or not. And you don't worry about data. You hope for the best or you try to work on the obstacles to getting actual measurement of v6. And a lot of people I know are working on all four of these at the same time, myself included.
So what we trying to do instead in the meantime in parallel is a census kind of activity through the RIR channels. Now, remember, the first one we didn't do through the RAR channels. That was good because we had a lot to learn and at least we're a little bit better this time, although I would say that there's still a lot of things in the survey I wasn't happy with the way the questions were worded. We had 350 respondents from the ARIN region in March. And we had over 1,000 in September when we expanded the scope to all the regions. So that's great news to me. And I really think we should kind of use this as the ground zero or data point one on being able to build history and draw trends.
Let me give you the caveats first. I'm afraid I'm going to spend the rest of this talk, like more than half of it, on the caveats and a tiny bit on the actual data because surveys are squishy.
I've been reluctant to do surveys my entire career because of their squishiness, but after watching how people are measuring IPv6, I decided maybe surveys aren't that squishy anymore.
The biggest caveat for the survey is we -- I'm cringing as I say this -- we couldn't tell, and this is our fault for wording it this way, although you guys have to decide how you want to fix this in the future. We don't know how many people responded from a given organization. This is particularly problematic for the very large organizations, like maybe Comcast had five people respond, and that will be counted as five very large organizations, which you don't want to do that.
It isn't such a big problem with the small/medium organizations because it's less likely that there will be multiple people responding, but in the future I believe we need to do something like what Arbor does, which is make sure that only one survey goes out to each company.
Of course, I think Randy made a comment yesterday about the size of the microscope to measure v6 traffic, and there's obviously methodological problems with measuring v6 actively or passively. But surveys have their own set of methodological problems that go into disciplines that I have no training in whatsoever. So, that's another caveat. There's certainly an incentive to not be completely open about your data here, although we provide the ability to anonymize yourself. You don't have to say who you are, which is why we also can't tell how many people responded from an organization.
Forty percent of the respondents did not say what organization they were from; 60 percent did, approximately. So that limits the utility. You can't figure out where the root of our problem is with the point of v6. We'll take what we can get right now and leave it as an exercise to the Board to figure out how to fix that later.
And the other big caveat is that because we expanded the scope this year, drawing trends between March and September, really difficult. Really, don't do it. You did check a box -- by the way, let me interrupt myself for a second. I'm going to have to ballpark this, but how many people filled out the survey? Okay, wow, not many. What are the rest of you guys doing? Good grief. You can come to a meeting but you can't fill out a survey? This is ridiculous. Sorry, okay, tantrum over.
You did check a box, if you filled it out, that said what region you were from. So we can do a little bit of categorization by region, and I'll show you some of that. But in general, overall trends, very difficult to draw between six months -- and I'll talk more about that in a second.
Okay, so here's the way I will present these results. First, I will give four slides on who responded. Forget about what their answers were. Just what the demographics of the population that responded were. Then, I will give some slides on what they said about their v6 activities as a function of these four parameters -- are they more likely to be doing v6 if they're a different size company or if they're government versus education versus commercial? And then I'll talk about what they checked off as their motivations, their hurdles to deploying it, their plans for the future, and their expectations. And then some quotes are thrown in here, which I probably won't have time to go through.
Who responded? Remember, this is just who responded, not who is using v6. This is just who answered the survey at all. Although, I admit a bias. Did I not mention it earlier? You're probably more likely to fill out this survey if you have some time to think about IPv6. So already there's a bias there toward people that are v6 conscious. But given that, this one is about the same as last survey in March. Over three-quarters are for profit and then there's some noise in there that I wouldn't worry about. And 25 percent nonprofit.
Where do they come from? Well, the RIPE region really puts us to shame here because on the first time at bat we got twice as many responses from Europe as we did from the ARIN region, North American region. And so you can see on the right is the specific country they mentioned, if they mentioned a company, and the U.S. is at the top, of course, because Europe is a bunch of different countries. But Europe taken together had maybe almost twice as many. Not that many. Almost twice as many respondents as the U.S. And a reasonable number in Asia and other places in the world proportional to their activity.
We allowed people to also check that they operate in more than one region. So make a note, this is not where they get their addresses. This is where they have operations. And so they can check as many as they want. That's why the green histogram at the bottom is adding up to more than the blue histogram at the top.
How big are the companies that responded? This is the slide that makes me squirmy because there's a very large issue. And there's 103 respondents from very large companies, but I have no way to reverse engineer how many companies that really was. So we'll fix that somehow next time. I don't know how yet. And the bottom one is size of company by region. Nothing earth shattering there.
A lot more respondents from small companies, perhaps to be expected.
Where did the respondents get their addresses from? Again, RIPE region is overwhelmingly represented here. I think that's great. I mean, good for RIPE. APNIC and ARIN are about the same, and then maybe what you'd expect. Again, nothing surprised me here in terms of where the respondents were getting their addresses from.
Okay, so that's it for who responded. That was your sort of level set of who is answering this survey. Obviously, it was nobody in this room, but it was a few people. There are 20 of you maybe.
So what did they say about what kind of IPv6 they were doing? What kind of activity they were doing? What was their motivation? What do they expect to need next year? I took out that slide, so skip the fourth point. And what's their strategy for the next phase of growth?
So this is a slide that shouldn't go in the New York Times or anything because, again, bias of expansion of the scope of the region, but you can see we had a lot more percent of respondents have an IPv6 allocation than did when we surveyed ARIN region only in March. If I were to take this just North America region and compare those, it was still a jump. Maybe a 10 percent jump. Not a 20 percent jump like you see here. But pretty impressive. Also consistent with Cathy's slide. There are a lot of people that are getting allocations that aren't routing them.
Does the type of organization you are affect whether you're going to get v6? We saw this last survey, too, and this is pretty consistent with the last survey -- you are more likely to get IPv6 if you have resources. If you have resources, you're more likely to get IPv6 resources. And also, if you are not forced to be cutting costs and everything. Right? So the commercial is way over on the left with state government. Those people are the ones whose budgets are under the most pressure.
Education is on the right; dot-orgs, nonprofits, next to it; and then research and development, local government, federal government. So, still quite a bit of penetration in terms of allocations. And again, in terms of allocations, and again, in terms of who responded to the survey.
From which RIR did you get your allocation, if you did get an allocation? Again, we see approximately the same. To me this means -- and again, accepting these are people who responded to the survey -- the RIRs are actually doing a pretty good job of getting the word out. Maybe that's not surprising given how much coverage there is of the topic. But I don't think you can call out any RIR here to say, oh, they're really not making an effort. They're really all making an effort, and they're really all having an impact.
Why are people getting v6 if you're getting v6? Oh, you can't even read that, can you?
Okay, let me read them real quick. Well, I don't really like these options anyway, so maybe that's why I made it a small font. Number one is you want to be ahead of the game. Number two is you want to make sure v6 is supported in your products. Three, customer demand. Four, other, which includes research. I should have made a research category, but I didn't. Number five, can't get enough IPv4 addresses. And six is government mandate. I added six, government mandate, because so many people -- well, so many is probably five -- it seemed like a lot in the March survey -- put government mandate. Wrote it in other because I didn't have government mandate as an option. This time I put it as an option, and I was surprised that it wasn't more, to be honest. And I actually also did a slide, which I'm not going to present on motivation by region to see if you were more likely to be motivated by a government mandate if you were in the U.S. where we know there's a DOD mandate. You see a little bit of emphasis on that, but not very much.
So there's a lot of people -- and again, these are kind of squishy. The top two maybe overlap a little bit. And there was quite a few more people that answered the top answer -- want to be ahead of the game -- than answered number two in March. Again, in the ARIN region. So that suggests that maybe people are realizing they need to have IPv6 supported in their products. So that also is a potentially piece of good news.
Hurdles. We expanded this number of hurdles you could check because last time we only had a few. We taxonomized it in a more coarse way -- just said vendor support -- and this time we blew up vendor support into many kinds of vendor support.
There wasn't a box that wasn't checked in the survey. Everybody said -- in fact, the quote at the bottom you can't read virtually, every box could be checked. This is dual stack support, lack of expertise, lack of support from transit providers, lack of support from end users, problems with legacy apps, cost of hardware, and then a bunch of vendor support issues.
This is the slide where it's potentially a goldmine for the registries to look at the free form answers that we let people put in because you can really sense people's frustration with trying to convert to IPv6. So, here's a couple of quotes that you can't read. I won't read them all, but I'll read a couple of them.
We don't see the point. If you're going to run dual stack anyway, choose something decent.
V6 is, in our opinion, one of the more crappier protocols, just like IPv4, and it doesn't bring anything to switch from crap to crap. Now, the interesting thing is this position was espoused by some of the people I most greatly respect. They worded it in a classier way, but they espoused this position until like a year ago. And now they're full team ahead on IPv6. So, there is some evidence that maybe the right things aren't being explained about why v6 is really needed. It's not to help -- it's not so that you can have more addresses yourself or to help your immediate problems. It's a systemic thing, and this is why we're all having these conversations for so long.
And then the bottom one is really the overarching theme here -- why spend the money if there is no extra profit? And this is why always when there's a commercial versus noncommercial distinction, the noncommercials have stronger likelihood of having v6 activity or v6 deployment. That's no surprise for us by this time.
Does size affect what your hurdles are? Yeah, it does, a little bit. If you're big, your hurdles are less likely to be that you can't hire expertise and that you can't get transit. If you're small, you have trouble with everything. If you're big, you trouble is that there's no demand. But you've got everything else worked out or you're on your way. That's what this slide -- to me, the blue -- the light blue, which is dual support for v4 and v6 -- so dual stack or application support -- to me that is a euphemism for a demand. There's no user demand. If you're turned IPv6 on and then you turned it back off again, like DREN, why did you turn it off again?
So this is another potential piece of good news, although, you know, I'm worried about extracting trends, but user demand was the biggest here. Obviously, I would expect that. Other is methodologically problematic. Sorry about this, but a lot of people when they had -- got to fill out what other meant, they said we don't have -- we never turned it on, which shouldn't be in the slide.
And I should go and extract all of those, but I didn't have time. So other is not that high. Let's not worry about it for now.
Technical problems as a reason for turning off v6 was a more popular reason in March. So you could interpret this, and I interpret it, as saying people are working out the technical problems. There is some progress. It may be slow and you may need a fine microscope to measure it, but the user demand remains the overwhelmingly biggest reason to not retain IPv6 support if you ever turned it on.
SPEAKER: One more that I wanted to add to the list that I've noticed. People don't mention it very often, but when you're talking to people that are dual stack, frequently they don't monitor it as well as they do v4, so the quality of service is much lower. And you have to shut them off because they forget to monitor their own v6 dual stacks.
MS. CLAFFY: Yeah. Network management support is listed in -- whenever you gave people an opportunity to just say what are the issues, network management support would be one of them. But maybe we should get Kevin to come up at the end and talk about ESnet, because ESnet seems to have gotten through these issues. And I think DREN is also working through a lot of these issues. And some of this is just going to be about documenting. I think Randy made a really good point. It's not like we didn't have these issues for v4. It's just when we were all ramping up on v4, we didn't have a backup.
If we didn't get v4 working, we didn't have IP pockets going back and forth. So the whole incentive structure is quite different.
What kind of v6 are you doing? Are you doing native or tunneled -- I'm sorry, are you doing routing versus DNS middleware type stuff for applications? And this is again if you have IPv6. So don't read this as 90 percent of the people have v6. This is if you have v6 services at all, what kind of v6 services do you have? The vast majority of the people are doing ping, right? They're just getting BGP working. All right. That's good. That's the first step. And then a few people are doing DNS web and e-mail applications. But, fewer.
There was not a big distinction across regions for that. I did the work for you and I'm not going to show you the slide.
Moving toward the future now. What do people expect to get next year or expect to request next year? I didn't do this math, and I didn't get ARIN to do this math because I'm doing these slides with too little time. But I promise we'll get this data to you. I suspect the answer to the question -- the question is do the RIRs have this much address space to give out next year to satisfy everybody's expected needs? And I suspect the answer is no. Well, the /8 thing over on the left that 14 people requested /8, that doesn't sound right to me. I think that's serving noise. That's five people from Comcast or something. I don't know.
But the histogram on the right is pretty interesting. I mean, I think that's useful. Oh, by the way, I should have said earlier the raw numbers -- the numbers at the top are raw numbers of respondents, and the percent is on the Y-axis. And then the bottom is IPv6. So that's sort of expected. You can see the policy modes of /32 and /48. So this is an unfinished slide I should say.
MR. CURRAN: Just for question, the bar for requests are numerical count of requests for a block of that size expected. That's not the equivalent of /8s or anything.
MS. CLAFFY: That's right. That's correct. The number of that prefix size request.
MR. CURRAN: You don't happen to know the area under the curve?
MS. CLAFFY: I can get that for you. I don't have it now, but that's a great question.
MR. CURRAN: Just curious.
MS. CLAFFY: I would like to know that, too.
What are people planning to do for the next phase, whatever that is? You know, whether you're a v6 believer or not. This question really cheered me up, I have to say. I'm going to reveal my bias here, but you guys probably already know it anyway. I'm an academic. Most people are actually planning to transition to IPv6. Now, you know, again, if they weren't, they probably didn't fill out the survey, so I understand all that. Some people are still in the wait and see. You would expect that. But very few people are actually planning on there being a market. That's good because I think the market has a whole bunch of problems to be worked out, and I skipped over it in the first slide but we threw up our hands violently in the air once on that.
Okay, I'm going to -- to the extent that people are planning to transition to IPv6, let me also cheer you up again, maybe, unless you have stock in some of these companies, on the capital allocation issue. So in 2005, I gave a slide on why v6 deployment wasn't happening. And I showed you -- oh, damn it, you can't see -- okay, I'll read the numbers. Can you see the colors at least? What I showed you as earning per share and market cap for the companies that you would need to be converting to IPv6 -- the big telecom players -- and then I contrasted it with the vendors or the -- how shall I say -- people who make their money at the edge.
On the left, all of the first column is in the red. Meaning, in 2005, all these companies -- these infrastructure companies were in the red if you could even find their stock symbol. Today every one of those companies, which may be because they're not that company anymore -- it may be because they got bought -- every one of them has positive earnings per share. Some of them have lower market caps; every one of them has positive earnings per share, which means there is capital for v6 that there wasn't three years ago. Good sign. Very good sign. Maybe not good sign for the price of your cable bill because that means competition is going away, but a good sign for v6 deployment opportunities.
And then on the right you saw -- I was just amazed at Google's earnings per share. It's an order of magnitude more than anybody else, so really, they could just pay for everybody to get to v6, right? Good news on the right side of the graph in general.
Well, and I should point out, these stock -- these numbers are lower than they probably were two weeks ago because of the crash, because I did this last night at midnight. Today's numbers or yesterday's numbers.
What do we want to do next? There's a lot of things I'd like to do next. I wish I had more time and stuff. I'd like to do more analysis of this data. Answer John's question. Hopefully you guys will come to the mike and ask more questions and we can dig through an answer. I want to solicit some feedback on the next survey. Other things you want to add to it. We need to figure out what to do about the multiple respondents per organization. We had a lot of people volunteering to follow up with us and donate other kinds of data for us, so we have a lot of follow up work to do. That was very impressive to see as well.
We're going to -- CAIDA is going to increase its own IPv6 active probe capabilities.
Everybody wants a skitter graph of IPv6. We've done a couple of IPv6 skitter graphs. They've been unsatisfying. Although they do show v6, but we just don't have very many IPv6 capable probe boxes right now. Six, I believe, and that's probably upper limit. So if you want to support IPv6 active probing of the addresses we can find in the routing table, come find me.
Increasing traffic analysis. So there's some really interesting questions to ask assuming you could get traffic data, which you usually can't get. But we have little tiny sample points we can get of how much traffic is using addresses that are under the RIR regime versus legacy, versus legacy with RSA. Sort of what percent of the traffic you can see on the Internet is really participating in the RIR consensus about how to treat IP addresses. I'm fascinated by this question. We've done a little bit of digging but need time.
Address ownership analysis. I'm going to show a slide that I showed last time. Economic analysis, I just showed you a little bit of that. I think it would be worth keeping tabs on the economic health of the industry such as we can. And some workshops. And I'll mention this on the next slide, too. I have two more slides left.
This is a pretty graph. It's in white background to point out that it's old. It's from my 2005 talk. It's literally three years old, and I have not updated it. And I'd like to update it, or someone at ARIN to update it. Somebody should update this graph. This shows where allocations are going. Are allocations going to people that already have allocations? Or are allocations going to new folks that don't have allocations yet? And you can see through 2005 -- for those of you who don't remember this slide when I presented it then -- there is a bit of a tendency for allocations to be going already to organizations that already have allocations. My greatest fear about establishing a market is that -- zoom all the way up -- all the allocations will go to very few players with capital.
So that's one thing that I'd like to see done. And then I'll make a plug for this workshop idea instead. I made this suggestion in '05, and I even more strongly want to make it now because I've been listening to people as much as I can listen, except for the PPML, which I totally admit I cannot keep up with. Sorry. There's a lot of thinking going on about this topic. Actually, quite intelligent thinking, not to try to over flatter you all because you guys know I'll criticize you if I think you're off.
But there's a lot of thinking going on here that isn't being distilled into a sort of coherent -- I would say papers because I'm an ivory tower academic and we get -- our currency is publications and stuff. It's not clear to me what the right medium is, but I believe that we need to distill our knowledge a little bit better. And I'm happy to support that mission if I can, since I'm pushing it. And you could even have a workshop in San Diego where, I swear, it's warmer than it is in this hotel.
But there's this guy, Peter Schwartz, who wrote a book called the Art of the Long View. If you haven't read it, I recommend it for thinking about long term shifts in society and economics and stuff. And he talks about the importance of not necessarily trying to predict the future, but try to paramatize the future. Understand what are the factors that are going to play into how things change in the future, and what are the levers that you can manipulate, and what can't you manipulate.
So I'm just going to leave you with that. I think a workshop would be useful -- especially output of the workshop. Not having a workshop and then not producing something, whether it's a paper or something else.
Okay, that's all I've got. Thanks.
MR. CURRAN: Any questions?
MS. CLAFFY: I need questions. Yeah, I need questions. Kevin, yippee.
MR. OBERMAN: Maybe not. Kevin Oberman, ESnet. You made the statement that only DOD managed to meet the OMB mandate.
MS. CLAFFY: Yeah, that's not true.
MR. OBERMAN: But, in fact, as far as I know, I know DOE did. I believe OMB has claimed that every government agency did.
MS. CLAFFY: Oh, really?
MR. OBERMAN: And, of course, if you read what was mandated, many of them translated that into if I can ping from inside my network to anything outside my network with an IPv6 packet and get an answer back, I passed.
MS. CLAFFY: Right.
MR. OBERMAN: That's a mighty low back.
MS. CLAFFY: Right.
MR. OBERMAN: In fact, we had some of our DOE sites come on and say we need to be configured for IP. And as soon as they pinged, they said thank you very much. We're done.
MS. CLAFFY: Yeah, okay, so I should backpedal a little bit on that. I got the information from the DREN guys who -- I think what they said was consistent with what you just said, which is the bar was lowered considerably on what it meant to meet the mandate. And then everybody met it. There's a lot of that going around in federal agency funding frameworks. I see it at other places, too.
Actually, I meant to make a more positive point, which is the government -- maybe it's not the primary factor on v6 deployment, but the government activity is helping. It's really quite -- and in fact, to the extent that you can find thorough studies of what are the problems with v6, there's government money in that government somewhere. You can trace it back, particularly the DREN and the DOE stuff. So I couldn't say more strongly.
I heard that Bob Braden was implying that we should just make academics not allowed to use v4 anymore. I don't think that's the right approach, but I do think it's underutilized. The academic community is underutilized. The U.S. Government stuff is underutilized. I think we're all coming out of a decade of distress of the government, but the reality is the government is making progress in a lot of these areas that the free market hasn't made progress in. Like, you guys are probably aware of Doug Maughan's recent -- again, OMB mandate to get the dot-gov signed by next year, which is just phenomenal. I never thought I'd see something like this. It's not always a thing of beauty if you care about the security of the DNS.
MR. CURRAN: Just one little thing, Kevin. I do believe that OMB sometime shortly will give more detailed summary of the results from June 30th. If I listen, that's what I hear. So, that might be forthcoming because there's a question of what level and what did we learn by doing, and all that that's currently running around some of the federal discussions.
MS. CLAFFY: Thanks for making that comment. So I should say I don't know the exact details and I was just parroting hearsay on what I thought was true about federal agency meeting the OMB Mandate. Don't take my word for that. Don't quote me.
Any other questions? Come on, there's got to be other questions. I'll be around the rest of the day but not tomorrow if other people have questions. Thanks.
MR. CURRAN: Thank you.
MR. PLZAK: Thanks, KC.
MR. PLZAK: Now we're on to our policy -- first policy proposal of the afternoon. This is Policy Proposal 2008-3, Community Networks IPv6 Allocation.
As proposed in March of this year -- it's been discussed in three meetings so far, the ARIN meeting in Denver, Kingston, and Nassau. And community consensus has been to revise it. It was revised once in August and again in September. There is no similar discussion any other region.
It provides for an IPv6 /48 or larger assignment to a community network that has 100 users and a plan to doubling the number of users within a year.
The shepherds are Lea and Stacy. Staff -- there's no legal liability risk. Some concerns: There's no language -- no modification to Section 184.108.40.206b is necessary. Some small language tweaks to proposal for sections 220.127.116.11 thru 3.
Minimal time to implement, probably about 120 days. Not much discussion. None in favor, none against, no real comments. So, I will now turn it over to Lea, who will present the proposal. Lea?
MS. ROBERTS: Okay. Do I have to press something here?
Okay. This slide deck was actually prepared by Joshua King, the author of the proposal.
And I'll be presenting it on his behalf. So, basically, one of the sticking points when this proposal was originally presented was the concern over just what is a community network? So, the definition has been somewhat clarified to: a network which provides services to a certain geographical area as an alternative or supplement to normal ISP service. It's usually associated with a nonprofit organization or even a loosely collected group of individuals. But it's operated for the general benefit of the residents of that area for little or no cost.
So he's included along here in the next set of slides some examples of various community networks that are part of supporting this proposal.
So, while many of us think of community networks as perhaps using wireless, it's actually a full range of technologies including fiber optics, legacy coaxial, and perhaps even custom, homebuilt optical links.
Many services are provided: public access as well as wireless, people exchange media among themselves, provide intranet services, perhaps link into the local library, and so forth.
But most of them are operated by community organizations such as co-ops, non -- you know, regular nonprofit organizations, 501(c)(3) in the US or their equivalent elsewhere, and universities.
So, as to why they need IPv6, many of them already support v6, but want to have their own address space in order to simplify the network management and architecture using a, you know, fixed set of unique addresses for their sites and not having to do any kind of address translation. That enables them to facilitate the communication among themselves for content, production, hosting, and so forth.
One of the things that community networks do is kind of put together their own kind of infrastructure. So all sorts of different devices are used, as you can see here, and moved around the network as needed, providing a multiple-link network inside the community. So any particular node isn't necessarily vital to the continued operation of the network.
So, they like to think they're doing research and development on inexpensive open-source technologies and would like to add IPv6 as the next wave of innovation in these networks.
So, in response to the feedback from the original presentation of this at the previous ARIN meeting in Denver, they've tried to tighten the definition in the new proposal of what a community network consists of. One of the things is that community networks are usually largely volunteer maintained. And so the proposal indicates that at least half the staff should be volunteers.
And the concern was also that organizations who may not really be community networks would try and skate in under this policy. So there's a financial hurdle or actually a financial cap on what a community network would consist of. And in the current proposal, it's a $250,000 annual revenue, with the assumption that anyone that had more revenue than that should probably be able to use the regular process.
And also, as part of tightening the criteria, the proposal specifies that a community network must be either a nonprofit organization, be sponsored by a nonprofit, or be sponsored by a university so that there's a limit on who would be ultimately accountable for the community network.
So the purpose of this proposal is to simplify the process of getting address space for the community network segment of the populace, now that IPv6 space is becoming available in general network areas.
It would like to see the possibility of fee changes for community networks once they exist, although they realize that's not part of the policy process.
And would like to provide to ARIN the discretion of actually, you know, deciding if an applicant is a community network, since coming up with a fixed definition can be rather difficult. Specifically, the proposal is not trying to provide a way for just any organization to easily achieve address space through this policy, nor does it believe that the address space assigned would have routability. It may have only some kind of limited, local routability, but even that would be an advantage over having a real, non-routable space.
So in response to the staff feedback from the assessment on October 8th, Josh has put together some new wording that he hopes is more or less conforming to what the staff requested. That's here on the next -- this slide and the next two after this. Presumably these are posted, so if you want to read them. I won't go to the trouble of reading them. They're on the agenda as part of the presentation.
I guess it's another three slides. Anyway, the one additional bullet item for this presentation is that there was significant support from this proposal during the sector meetings in the Caribbean, where the attendees there felt that it would be a valuable tool for them to establishing community networks, which they often have to support educational outreach in areas where there's limited communications structure. So, this policy is made for that sort of small community, who wants to work in their own interest. And the community networks -- one of the things that was learned is many of the community networks in the Caribbean might be sponsored by a for-profit university. Thus the language was modified to include universities, whether or not they're nonprofit, as the possible sponsors for community networks.
So, if there are any questions, this is the time.
MR. CURRAN: Please turn on the mic. Thank you. You can leave this microphone on, actually, really. Microphones are open for questions. Far right microphone.
MS. DAILEY: Hi, I'm Dharma Dailey from the Ethos Group. And as I was at the meeting last year this time, asking about community networks, of course I'm in favor of this proposal, at least the outcomes that we hope to get out of the proposal.
My colleague Gareth Sherman, TeleCommunities Canada, which is an NGO up in Canada that represents a lot of community networks including a lot of remote networks, is in favor of this proposal as it stands. But he did bring up one concern and that is the growth requirement where many networks may be -- existing community networks may be looking at this proposal as an opportunity to provide new services. So if there's -- I don't know where Josh got the wording for the expansion of 200 or the requirement of 100 persons, but that's something that Gareth would like addressed.
MR. CURRAN: And do you know the suggestion for addressing it?
MS. DAILEY: I'll go -- IM -- Gareth and ask him.
MR. CURRAN: Okay, thank you. Okay. Center front microphone.
MR. CRANDALL: Hi, my name is Marc Crandall. I'm with Google.
Quick question. What happens if someone that receives this allocation loses their nonprofit status or no longer qualifies for it later on down the road after they received the allocation?
MR. CURRAN: So, I can take -- historically, we haven't had a case where an organization that received an allocation disqualified. I don't think that happens very often.
Leslie, are you? Do we have cases where people no longer meet the current criteria for their existing allocation?
MS. NOBILE: No, and there's no policy to really go back and check on that. So, if they get -- once you get your allocation, if you don't come back to ARIN, there's really no way for us to know what happens.
MR. CRANDALL: And I guess if that hasn't happened and if there's no way of checking, isn't really a concern at this point. So, if it's not, it's not. But just is something to think about.
MR. CURRAN: It's certainly something to think about. It certainly poses the question if an organization comes back. If they don't come back, I don't know any way that ARIN would necessarily know that that change ever occurred.
MR. CRANDALL: Thanks.
MR. CURRAN: Would you be in favor or against the proposal?
MR. CRANDALL: Neutral, right now.
MR. CURRAN: Okay. Thank you. Center rear microphone. Heather.
MS. SCHILLER: Heather Schiller, Verizon Business. And if I understand correctly, this actually -- it sounds like it makes it more restrictive and difficult for community networks than ISPs? Because ISPs have to show a plan for assigning -- making 200 assignments in 5 years? And it sounds like community networks will have to show a plan to make 100 assignments immediately and double to 200 within a year? That seems more restrictive. Was that intentional?
MS. ROBERTS: I don't believe that the numbers are supposed to reflect assignments, but rather the number of participants in the community network, who may or may not be getting some kind of assignment.
MS. SCHILLER: Yeah, I'm not sure I understand the difference.
MS. ROBERTS: Well, the difference is that the topologies of community networks are varied, so it may be that there's a wireless space with -- that's omni directional with a number of participants that might all be one subnet. So they would have one allocation for 20 or 50 participants connected to that site.
MS. SCHILLER: Sure, but I don't think -- so, in the existing ISP policy, it doesn't make any statement about what size the assignments have to be. So, if you, you know, put out a /48 and say this is for anyone who happens to drive by, and you have the potential to have 65,000 users? That seems like you would meet the requirement under the ISP policy.
I'm just saying that it seems like they meet -- would meet all the requirements under the existing policy, so I'm not sure that I understand why we need new policy. I understand from the original policy what their goals were, but in this policy, I'm sort of not seeing what the benefit is.
They should -- it sounds like they should be able to qualify under the existing policy, as well.
MR. CURRAN: Okay, thank you, Heather.
MR. CURRAN: And Heather? On that assumption that they qualify or not, would you be for or against this proposal?
MS. SCHILLER: I would like for someone to clarify whether they would qualify under the existing policy. Maybe -- it's hard for -- I'm sure it's hard for ARIN staff to --
MR. CURRAN: Right.
MS. SCHILLER: But they've done the staff assessment to look at, you know, at the policy. So, if ARIN staff thought that an organization that applied today under this, would they also qualify under the ISP policy?
MR. CURRAN: The question is, is that -- the question to the staff is, is this policy redundant with existing policy.
MS. SCHILLER: Mm-hmm.
MR. CURRAN: Okay. Leslie, can you? I know it's not an easy question. Can you get together and discuss that?
That may take a while to look at.
MR. LEIBRAND: I could try to address that.
MR. CURRAN: Okay, go ahead.
MR. LEIBRAND: Scott Leibrand, ARIN AC. The way I read the 18.104.22.168d, it says they must have a plan for making at least 200 end site assignments.
A site is a lot different than a user. If NANOG.org applies as a community network on the basis that they have a room full of 250 people that they want to be able to provide v6 connectivity to, leaving aside financial stuff, they would probably qualify as under 200 users. They certainly wouldn't qualify as 200 sites.
So, I can definitely see cases where this Community Networks Policy would allow community networks to qualify that don't qualify under the ISP policy.
MR. CURRAN: Which would mean your interpretation would be those users using the service don't constitute individual sites through their use. Okay.
MR. LEIBRAND: Right. If you're in a -- if you're part of a DHC people or an auto configuration, you're a user, you're a node, but you're not a site.
SPEAKER: Okay. Thank you.
MR. CURRAN: How do you feel about the policy, Scott?
MR. LEIBRAND: I support the policy.
MR. CURRAN: Okay, center rear. Jason.
MR. SCHILLER: Jason Schiller, UUNET/Verizon Business/NRO NC. I am not opposed to the policy. However, I'm not sure that it's needed, like Heather.
I'd like to actually talk about the end site definition that Scott just mentioned because I did not read it that way, at all, and I would like to understand how ARIN staff would interpret that particular point. If I was to apply as an ISP, saying I have a wireless network and I have 200 customers that roam on to my network weekly, would I qualify for a /32 as an ISP?
MR. CURRAN: Go ahead, Leslie, yeah. Yeah, could you answer that?
MS. NOBILE: So, the way we interpret it right now is 200 end sites must have a plan for making -- or having 200 end site customers, I guess, or end user customers. We don't really distinguish what they are as long as they, you know -- it's a customer, an end user customer, is what we call an end site, so. I don't think that helps, but.
MR. SCHILLER: I'm sorry, but can you be very clear. If I said I have 200 customers that roam onto my wireless network, is that yes, I qualify because a customer is an end site? Because that's what I heard, and I'm not sure that's what you said.
MS. NOBILE: I wasn't that clear. Yeah, that would be 200 customers, 200 end sites. Yeah.
MS. ROBERTS: Well, that's not how I interpret it, quite honestly. And I think the -- I mean, we have -- what I understand, the LIR kind of thing, is you're actually providing to your end customers, you know, more than a /64. So, that's my -- just my own personal interpretation --
MR. CURRAN: So --
MS. ROBERTS: It's not like a DSL customer. If you have 200 people dial in and get a /64, that's not the same as an end site.
MR. CURRAN: So the question that comes up is the ambiguity in the current policy with regards to what an end site is, could render this not necessary. Now, these folks came forth and their interpretation was they couldn't claim the end sites, I presume, because that's why they're here asking for a policy.
SPEAKER: Some could and some couldn't.
MR. CURRAN: I guess the question that comes up is, is this based on whether that end site is a permanent site or a temporary site?
I'm wondering, Leslie, the question would be if those same 200 users were in this room connected wirelessly as end users, are those, you know, is my laptop a site or not? What is ARIN's interpretation? This does bring up a pretty big hole that we should clarify one way or the other at some point. What's ARIN's interpretation of a site?
Does it have to be a dedicated installation? Or does it have to be more than a single machine to be a site?
MS. NOBILE: You know, this is -- yeah, this is -- it's hard to answer. Two hundred distinctive customers. If it was -- we've never faced this situation, John. I'm not even sure. I can't even -- I mean, we usually hear there's this organization, that organization. They list customer sites. I haven't really ever been approached and --
MR. CURRAN: Okay. So, I guess the question is going to have to be -- there're two great ones here. First one is this may be redundant, and we don't know. And there's probably some policy work to clearly state what the current policy is regarding end site. And when that's done, we'll know whether this is redundant. But presuming it's not redundant, this would pose a relaxation to current policy.
On that assumption, would you be for it, Jason? Having this addition to the current policy?
MR. SCHILLER: I'm sorry, John, I didn't catch what you meant by relaxation.
MR. CURRAN: If the current end site definition --
MR. SCHILLER: I just didn't catch what you meant.
MR. CURRAN: If the current end site definition does not allow this type of access, would you be in favor of allowing these allocations, this policy?
MR. SCHILLER: I think I would, but I do also have one additional clarification. And that's with regard to how we measure utilization of transient users like modems. So my second question would be if I have a wireless network and over the course of a year, on average one new person roams onto my network, can I claim that I have 300 unique users? Or is it something that's measured statistically, the average number of users I have on at a given time or at a peak time? How do we deal with this today with modems, for example?
MR. CURRAN: I do not know whether ARIN's dealt with modems recently. We don't seem to have requests coming in talking about modems.
MR. SCHILLER: Well, historically, how have we dealt with modems? Because isn't it statistically how many ports do you have and what percentage is typically consumed at?
MS. ROBERTS: Well, I think typically in, you know, in the past, modems have been more like hosts, right? So they count as an address in your address pool. But I don't know that they're a subnet. I mean, they probably are in the future. Right now they're a /64, theoretically, if they aren't a /128, in the policy as written, I guess. So I would, you know, I would say that they're -- that, you know, the users implied participants in the network and don't necessarily have anything to do with the network topology in this proposal. Whereas in a LIR, it's much more, you know, a set of subnets allocated to a customer.
MR. CURRAN: Right. So, Jason, would you propose a clarification to this to make it clear the way you think it should read?
MR. SCHILLER: I guess the point I'm trying to get at is if there's a wireless network that has 200 customers that are going to be on the network at a given time, or over a reasonable period of time like a day or a week, I don't see an issue with it. But if we're talking over some long period of time, over a year I have 200 unique subscribers, that doesn't particularly sound like good justification to me.
MR. CURRAN: Got it.
MR. SCHILLER: That's the point I'm trying to make.
MR. CURRAN: Got it.
MR. SCHILLER: So I would like some clarity on how we measure the number of customers on the wireless network.
MR. CURRAN: And what's your suggestion for that clarity?
MR. SCHILLER: Either at peak time or over a 24-hour period, or even over a one-week period, average number of unique subscribers.
MR. CURRAN: Okay. And if that's where this goes, would you then be in support of the policy?
MR. SCHILLER: Yes.
MR. CURRAN: Okay. Good. Next microphone. Far right.
MR. DELONG: Owen DeLong, ARIN AC. I support the policy pretty much as written. There are a number of community networks that have been faced with the idea that the current allocation policy which allows for them to be an ISP with 200 sites or 200 distinct organizations that they have made reassignments to -- being the language that I understood to be mostly what was relevant -- pretty much meant that they had to have organizations downstream and not individuals, and that those organizations needed to be completely independent entities. And so, for example, certain large enterprises couldn't be considered an ISP for the various divisions and business units within their enterprise, even, for purposes of meeting that 200 test.
Most community networks are looking more to get an assignment that they can use to sort of nebulously do -- not necessarily reallocation, but have the ability to shift where their network connects to various other providers and such, relatively easily, without having to completely re-architect the whole network because there are lots of pieces that are under various different administrative controls and redoing all of that is actually a hard problem to solve.
So, I think that, you know, number one, what they really need more fits in the assignment criteria that the allocation criteria, especially in the fee structure because most community networks are nowhere near being able to afford ARIN allocation fees. And also in terms of the way that they actually use it. Although they are sort of doing reassignments, they're not really acting as an ISP doing reassignments in the traditional sense of the word. They're not likely to be swipping. They're not likely to be issuing things larger than a 64. And mostly they're kind of building a cooperative backbone with a lot of different entities that are cooperating to try and help build something that's relatively community minded.
I'm involved in a couple of these projects in the Bay Area and I would like to see the community help these projects succeed. Thank you.
MR. CURRAN: Okay. Thank you. Far left microphone.
MR. RICH: Yurie Rich, Command Information. I don't support the proposal, and it might be from a lack of understanding. My concern is, is that by trying to go through this process of defining a community network, that we open a Pandora's box for special fee reductions for individual group types that could eventually bloat the policies with all kinds of definitions.
So, I think the intention here is good, I'm just -- I wouldn't support the policy as written. Perhaps if there was a broader category, that it was more inclusive for nonprofits.
There's also the technical piece, maybe that I'm missing, that if these community networks have upstream connectivity, why can't they get a /48 from their provider? And then their cost of connectivity should come with that /48, rather than having to pay ARIN for a PI space. Maybe I'm missing something.
MR. CURRAN: Do you want to address that, Lea?
MS. ROBERTS: I can certainly speak to that, some, because I've talked to Josh about it. The connectivity for community networks often comes and goes, and is from different providers. So the -- building a structure that's stable and allows them to route out through whatever the current external connectivity is, I mean, presumably they would still get a provider-assigned prefix for external connectivity except through -- except like in the case of the Caribbean where they were talking about if they had this kind of address space for community networks and there's an ISP on the island, they might be able to exchange among several different community networks without having to go to provider-assigned addresses.
But certainly all the cases that I've talked about with Josh, they were talking about the -- there's no expectation that this /48 that they got as a part of this policy would go into the (off mike). They understand that they would need to have another provider -- or multiple providers, and that's the other possibility -- to get external connectivity, which would propagate through this structure built throughout this set of addresses.
MR. CURRAN: Okay. Good answer. Center front.
MR. WOODCOCK: Bill Woodcock, ARIN Board, speaking just for myself. I'm intensely sympathetic with and supportive of the people doing this. This is very hard work and, you know, I've been there. And I just can't support the policy because I feel like this is going at it backwards. If we have a problem that affects people who are building community networks, it's also affecting everyone else. And hacking in a special case to solve it for one subpart of the community is not the way we want to be doing policy, I don't think. I think if there's a problem, we need to address it cleanly, uniformly, and not with a special case.
MR. CURRAN: So you would be against this as written? Okay. Center rear.
MR. OBERMAN: Kevin Oberman, ESnet. Just a minor note. I think maybe Jason needed more coffee, or less lunch, or combination thereof. Clearly, doing it on -- trying to assess the utilization on an average over any period of time is not a practical way to do it. It's got to be the maximum over a period of time. Otherwise, it -- whatever your peak time is, like, you know, four in the afternoon or eight at night or something, you're going to run out of address space. So, I just -- I think he was looking at it slightly incorrectly there.
And for what it's worth, at the moment I am opposed to the proposal as it stands.
MR. CURRAN: Understood. Far right microphone?
MR. BICKNELL: Leo Bicknell, ISC, ARIN AC. I am definitely still concerned of the definition that has been chosen here. I think -- largely I agree with Woody's comments, that if there's a larger problem here, we need to fix it. And I think some of the discussion here has kind of brought up the problem in this definition. It seems like there are an awful lot of things that at least I don't feel are community networks, and NANOG may be one of them. I don't know if they make a quarter million dollars a year and I don't know if they're really a nonprofit, but they have lots of volunteers who help with stuff and, you know. I can think of at least 20 or 30 things like that that don't seem to me to be community networks in the sense that the authors have thought of them, but may meet this definition. And, more importantly, if the definition exists, the various people organizing them may structure them to meet the definition.
So, I feel that we're still not very tight around what a community network is. And so for that reason, I can't support the proposal.
MR. CURRAN: Okay. Understood. We have a question. Go ahead.
MS. AZINGER: Marla Azinger, Frontier Communications. I am on the Advisory Council, as well. I don't support this policy. There's -- Pandora's box got open when we did PI. It's open. And this is actually, I think, one of the examples of how Pandora got open with that.
Moving past that, I don't support this because it's just too loose. The management of the address space, abuse management, there's too much with how this is written that is very questionable and could be technically a lot of issues with networking. And they have to get transit anyway. My company puts together municipalities all the time. And they never complain about the fact that they have to come to us to get the address space. Not one of them has asked me, can you help me get it from ARIN directly?
So, I don't support this policy.
MR. CURRAN: Okay. Far left microphone.
MR. GRUNDEMANN: Chris Grundemann, TW Telecom. I think that the policy as written is very cumbersome, and has a lot of problems, and maybe is redundant. But I think the idea of what's going on here is very important to address. I think that these community networks are really low-hanging fruit as far as starting the ball rolling for IPv6.
I think that there're probably a lot of garages out there and a lot of guys clinking around with software in their house, that if they had IPv6 connectivity, this may be a good way to get it, could help. You know, going back to this morning, the Warren Buffett quote with the snowballs, I think this is a hill. And maybe if this policy is not the answer, maybe it's just ARIN outreach and ARIN working with these organizations directly to say, hey, we can fit you in under the current policy and get you this space or...
I think something needs to be done here, though.
MR. CURRAN: Center rear microphone.
MR. SCHILLER: Jason Schiller, UUNET/Verizon Business/NRO NC. Two comments, quickly.
My first comment, with regard to measuring the number of subscribers, you asked what were some metrics that you might suggest. One was to look at the unique number of subscribers over a one-week period. With regard to peak and average, what I was suggesting was maybe looking at the peak number of unique users at your peak hour, every day, and averaging that across, you know, a 7-day period or a 30-day period and looking at the average of the peak hour over a period of time. So that's what I was trying to indicate when I was talking about average and peak together.
MR. CURRAN: Okay.
MR. SCHILLER: Sorry if that was not clear.
MR. CURRAN: Okay.
MR. SCHILLER: The other thing I wanted to respond to was that ease of management has never been an acceptable justification for IP addresses. So I'm not sure why we would consider that now.
MR. CURRAN: Okay. Excellent point. Do you want to respond, Lea?
MS. ROBERTS: In answer -- yeah, just in answer to that, I think that's completely understandable in the IPv4 space. I think it's less defensible in the IPv6 space.
MR. CURRAN: Okay. Far right microphone.
MS. DAILEY: Dharma Dailey, the Ethos Group. I just wanted to clarify the outcomes that the community network community is looking for. And that is a low cost and simplified process. Like something that makes it easy for groups that are very, very low resource groups, primarily volunteer groups, to be able to provide services that are really targeted in specific localities. And the kind of groups that we're talking about, the reason that it's hard to define them is because the groups that I'm here representing, they are ad hoc in nature. In a lot of cases, they are scrappy and getting connectivity from different places. They are legacy groups, like TeleCommunities Canada which comes out of the freenets and is still providing dial up and, in some cases, VoIP service and things like that to really remote communities like Ninivid, and rural islands in British Columbia, and so forth. And there are also people in metropolitan areas that are looking for ways to create community services using IP technologies.
And so that's kind of the drive behind that. Part of the drive is to be able to create new services, like -- somebody was saying that -- to be able to innovate, have the opportunity to have that play space to innovate, is one of the things that is driving some of the folks that are behind this.
As far as the wording goes, I mean, I defer to this community as to what the best way to achieve those outcomes are. But those are the outcomes that we're looking for.
MR. CURRAN: Okay. Thank you. Far left microphone.
MR. GAGLIANO: Hi, my name is Roque Gagliano with LACNIC. I'm concerned about that this policy because of the main idea behind it, this policy, looks to me is portability. Are you going to open the door for the, you know, this direction for the all other organization which doesn't meet the current policy?
You now, what if for some nonprofit organization they claim for the /48 from the ARIN because they (off mike) they're on their own network.
MR. CURRAN: Okay. Is that a question?
MR. GAGLIANO: I'm concerned about, you know, if (off mike) approve of this proposal, you know, if somebody else start asking for the same kind of (off mike) --
MR. CURRAN: Right.
MR. GAGLIANO: We have to open the door for them, too, for the fairness. So, do we think about that kind of (off mike) consequences? I think that's my question.
MR. CURRAN: So because of the risk of that, you would be -- you would not be in favor of this because of the fact that we may open the door to many other exceptions like this?
MR. GAGLIANO: Yes.
MR. CURRAN: Okay. Thank you. Center front.
MS. ARONSON: Hi. Cathy Aronson, ARIN AC. This is for IPv6, right? I ask this, like, three times to people on chat just to make sure. But it seems to me that we should be trying to, like, facilitate people to do IPv6. And I'm not sure if I'm for or against this proposal. But we'll give a /48 to a cell phone, but we won't give a /48 to a community network. So I'm really confused. I mean, I know it's PI and I know -- but --
MR. CURRAN: I'm guessing that you are in favor of this proposal, Cathy, to encourage v6 deployment?
SPEAKER: (off mike) confused.
MR. CURRAN: Confused, okay. Thank you. Far right microphone.
MR. SINATRA: Michael Sinatra, UC Berkeley. I agree with Cathy in just about all of her sentiment. And I have one other thing to say, which is that -- this is slightly off topic, but it's kind of an operational issue -- if you have the IP address 22.214.171.124, you're announcing yourself as an IPv6 router, please stop doing that.
You're running 6 to 4; you're running yourself as a to 4 relay, please stop doing that because it's breaking our IPv6 connectivity. And yes, I do support the idea of the proposal. Thanks.
SPEAKER: What was the last octet?
MR. CURRAN: Yes, repeat the information -- point of information.
SPEAKER: 164.158, those were the last two octets. 158 was the last octet.
MR. CURRAN: Okay. Rear microphone.
MR. FARMER: David Farmer, University of Minnesota. There are some valid concerns going around in the discussion. But I didn't hear them say they want numbers for portability, I heard them say they want numbers for the stability of the network that they're using in the local community. They may also have globally routed numbers that they would use for global access. But if you're changing your global access all the time, there's a valid concern for a stable, local-only address.
Now, there's been other solutions to that problem, local, you know, the global (off mike) various other scopes and other things, we've deprecated a lot of those kind of other solutions. Having a unique, globally unique address seems like a valid mechanism for creating that stability in the local environment in light of instability in the global connectivity.
MR. CURRAN: So, as a result, you would be in favor of the proposal? Is that what you're -- because of the stability it provides in the local environment?
MR. FARMER: I think I'm -- I am most definitely in favor of providing resources to communities' networks. Whether I'm in favor of this mechanism to do it, I'm yet to be decided.
MR. CURRAN: Okay. Center front microphone.
MR. RHETT: Hi. Jo Rhett, Silicon Valley Colo. Three comments, real quick. I agree with David in the sense that I am in favor of the idea. Also, likewise, we have got many stupider reasons to give a 48 to somebody than this. Finally, I'd like to address the slippery slope. I don't believe in slippery slopes. Everything gets evaluated on its merit. You know, when we gave women the right to vote, squirrels don't vote today. There are no slippery slopes, you know?
MR. CURRAN: Okay. Good analogy.
MR. RHETT: I just hate hearing that whole argument because it's always brought up over ridiculous things, so.
MR. CURRAN: Okay. Well spoken. Far right mic.
MR. RHETT: No correlation between women and squirrels, please. That was just...
MR. CURRAN: I think you're probably better off done now. Far right microphone.
MR. DURAND: Alain Durand, Comcast. I'm not in support of this proposal. If it was about providing stable addresses that could be routed as PI, I might have been in support. But if it really is about providing stability in case of an outage of another provider, and if they have addresses from another provider, we have those unique local addresses that nobody really likes. But in that particular case, it could be perfectly acceptable to use this. So although I have a lot of sympathy for community networks, I think that I will not support this proposal.
MR. CURRAN: Okay. Thank you.
MS. ROBERTS: I'd like to clarify, Alain.
MR. CURRAN: Oh, do you want to respond?
MS. ROBERTS: That I think the -- while it's not explicitly for PI, there are cases where they could get a set of local connectivity from a cooperating ISP, which is why they don't want to use ULA.
MR. CURRAN: Far right mic.
MR. DELONG: Owen DeLong, ARIN AC. A lot of the community networks that I am familiar with are not looking to have this as a stable set of addresses to put behind a weird assortment of NATs.
They are looking for this to have a stable set of addresses that they can use with whatever upstream connectivity they can or can't get at any given, particular time, which varies greatly over the course of a few weeks, let alone a few years, when you're trying to do this kind of thing. Sometimes, you know, the guy at Google has an extra port on him router and can be friendly to you this week, but three months later his manager changes and they go, well, what's this? You'd better unplug that now.
So, you know, one day you'll have four or five upstreams that are more than happy to help, and another day you're lucky if you can get, you know, somebody's wireless card to forward your addresses into the router that they happen to be able to give your prefix to. Such is the nature of community networks. But having stable addresses that you can use that it doesn't matter when you add or delete an upstream as long as you have at least one upstream at any given time is a feature, and one that is desperately needed by these organizations to better do what they're trying to do.
MR. CURRAN: Thank you. Okay, any other speakers for or against the proposal? Please come to the mics. I'll be closing the mics shortly. Last chance.
Microphones are closed. Thank you, Lea.
MS. ROBERTS: Thank you.
MR. CURRAN: Okay. In order to help the AC in their deliberations, we ask for a show of hands regarding these policy proposals. So, I'm going to make sure my polling mechanism is up and running. Okay.
I'm going to ask for one show of hands on this policy proposal. I'm going to ask for everyone in favor and then everyone against. And this includes not only people in the room, but remote participants.
So, with respect to the policy proposal, Policy Proposal -- here it comes; thank you -- 2008- 3, Community Networks IPv6 Allocation, everyone in favor raise your hand now.
Nice and high. This is the exercise portion of our program. Nice and high.
Okay. We have a show of hands. Thank you.
Everyone against Policy Proposal 2008-3 raise your hand.
Higher. One hand per person. Thank you. Tabulation is going on right now. Do you want to give guidance on what we're going to do after this? Okay. The envelope, please. On Policy Proposal 2008-3, number of participants, both in the room and remote, 143; in favor, 26; against, 23.
Thank you. This will be provided to the Advisory Council for their deliberations.
Back to you, Ray.
SPEAKER: My question is do you include the remote participation numbers when you read us those?
MR. CURRAN: Yes.
SPEAKER: Are you --
MR. CURRAN: What you're hearing, total participants is the number of participants that are online and in the room at the time. The show of hands, you're hearing the number of shown hands, both online and here, that said one way or the other.
SPEAKER: So you've got that in real time. Okay, thank you.
SPEAKER: It's real time.
SPEAKER: It's all real time.
MR. PLZAK: Okay. We are going to move the AFRINIC report until after the break. So we will take a break right now and please be back here at one half hour from now, which would be 3:45. Thank you.
MR. PLZAK: Okay, let's get started. Welcome back. We had drawings for the two surveys we did so far today, one from this morning and one this afternoon. And so Todd Christell is the winner of a digital luggage scale.
And Bill Darte -- actually, he can put this in use tonight. He won a do-it-yourself drinking straw. So, we get to watch that, so. What we'll do is, we'll go ahead and do the IANA report, then we'll do the AFRINIC report. So, I'd like to call on Barbara Roseman to do the IANA activities report. Barbara?
MS. ROSEMAN: Okay. Hello, everyone. Can I -- yeah, that's what I was going to ask. (off mike), great, thank you. Great. Just to give you a little overview of what I'm going to talk about today, a brief rundown of what's left in the IPv force base. Some activities we've been doing to XML-ize our registries. An update on the multicast registries. And then a small discussion about AS numbers. And at the very end some discussion about the DNSSEC work that's going on.
As you can see, there's not much left in IPv4. We're down to 39 free /8s. As some of you know from conversations that Leo and I have done over the past couple years, some of those networks are not completely what we would consider clean. They have been used by people for various purposes, and we've been doing a lot of publicizing that we will be handing out these networks. And that if anyone is using an unallocated network, they need to get off of it before it actually does get allocated.
The IPv4 rate of consumption has, as Cathy pointed out in her earlier slides about v6, it has gone up and down. There's no real consistency over the past couple of years. We anticipate that '08 is going to be a smaller number of allocations. The RIRs have collectively agreed amongst themselves to some slightly different procedures in requesting /8s from IANA. And that has led to a reduction in the number of /8s that we're giving out over time.
Since the last meeting, we've published two registries as XML registries. The IPv4 space registry and the AS numbers registry. And when we converted the AS numbers registry, we also did some other changes and introduced a few errors, unfortunately, which several people in the community were very helpful in helping us track down and fix.
For multicast, we're developing an XML format for the v4 and v6 registries. We're working with the MBONED work group -- working group. And there is an RFC -- an update to RFC-3171 that you can go take a look at if you're interested in the definitions that are being created. We're trying to clarify the rules for assignment of multicast space as this has been very problematic over the years. It's not that people don't get their space, it's that the criteria for assigning it has just not been very clear.
With the AS numbers -- excuse me -- we worked with the NRO to update the AS number registry to reflect the authoritative WHOIS server for each AS number. And since the last meeting one block of 16 bit AS numbers have been allocated. We expect to be instructed to update the AS number registry to use a different format for notation as per one of the IATF drafts that's out there. And again, the draft is referenced here so if you want to go take a look at it and see if you have any comments.
For DNSSEC, many of you know that last week the Department of Commerce introduced a notice of inquiry. An NOI. Regarding signing the root zone. And there are two proposals -- actual written proposals -- as part of that announcement. One from ICANN and one from VeriSign. And as part of their NOI, they have also listed several other scenarios besides the two that are proposed that could possibly be used for signing the zone.
It's an interesting discussion if you're interested in DNSSEC. If you're not focused on DNSSEC, it's kind of arcane and difficult to follow what the differences are. But if DNSSEC is something that you are interested in, if you're concerned about how the root gets signed and who holds the keys and who manages that process, then I think it's worth your time to go and look this up, read the documents, and send in your comments.
We did submit the proposal to sign the production DNS root. We've had a non-production sign zone available for over a year since June of last year. And if you want to go take a look at our announcement about this which also includes our proposal, the URL is there at the bottom.
And that's it. Any questions? Thank you.
MR. PLZAK: Thank you, Barbara.
MR. PLZAK: I'd like to now call on Badru to come up and give the AFRINIC report?
MR. NTEGE: Good afternoon, everybody. Just give you a quick glance at AFRINIC. We have a budget this year of $1.5 million. We've built -- we've increased our headcount. We have 12 members fulltime staff. Membership has increased as well to about 470 members with an increase of 53 this year.
We had one global policy approved this year, and this year gives us three years of actual operation.
We have got a new management structure, we've got a few new members in the team. We now have a communications area manager looks after the training and the outreach work we do. Joining the team this year, again, is -- I mean a new join is CTO, who is Alen Alina. I think he's known to most of you. He's been in the industry for quite some time.
A bit of the numbers for this year. As you can see, in terms of membership we've been consistently growing. The allocations we've actually kind of -- the numbers have changed drastically this year. We're also trying to get to the understanding -- the bottom of that. But take- up this year has not been as it has been in previous years.
Training activities. We've been doing a lot of training over the -- as you can see, the map kind of shows all the areas that we've actually done some training. The white places are areas we've yet to do some training in. But we've actually covered up to 34 training sessions since 2005.
206 has been -- I mean, IPv6 has been our main focus in the last two years and we've done a number of trainings in that. We are -- basically our main goal is to cover the whole continent over the next year. So, all those -- next year when we do this, I'm sure the whole continent will be colored.
Policies and activates. Over the last two years, we've -- I mean, 2008 -- 7 -- 2008, those are the policies that we've actually adopted. Not much number of global policies included in there.
We've gone into a little of a -- that was a corporation in terms of building the Internet growth on the continent. We've got relationships with the AFTLD. They're actually being supported by AFRINIC at the moment. AFNIC -- we continue to give AFIC financial support, and obviously we do a back- to-back meetings in the middle -- in the first part of the year.
We've also started working a lot with AU, which is African -- the University, and also AFRIN, which is a research and educational network. We're doing a lot of work on the v6 and BGP training, as you can see there.
Africa has also joined the 6 Deploy Consortium, which is basically an EU project and we're one of the 13 organizations working with that. Which is mainly aimed at -- support of IPv6 deployment in the continent.
Outreach activities. We had a booth at ITU in Cairo this year. We're also planning a booth at the upcoming ICA Cairo meeting. Internet Governance Workshop for regulators and policy makers, the (off mike) -- actually, that's where Ideal is at the moment.
Ongoing fellowships, we have five fellowships offered to AFRINIC in this year, 2008. Ten fellowships for AFNIC, one fellowship for IETF.
We also carried out the first training event in -- 6 deploy training event -- in Nairobi in June of this year. Which is actually very successful and got a lot of coverage.
AFRINIC 18 Rabat was quite successful in Morocco. We had 190 participants from countries, so actually -- we're actually covering a lot more of the continent at the moment. And you can see the breakdown over there.
In terms of sectors, we had about 20 percent coming from new education, 15 percent coming from the telecoms. The governments this year actually went up in participations. Governments and regulators, we had about 11 percent of that of the 190 people coming from that sector. And the 10 percent coming from the ISPs.
So four policies were discussed in Rabat. And we also had two new board members elected to the board. Thank you very much. I'll take any questions.
MR. PLZAK: Thank you. Any questions? Thank you.
MR. PLZAK: Okay, now we move on to Policy Proposal 2008-2. Now, you will note that we have -2 and -6 grouped together. Actually, 2 will be discussed first. But 6 is similar, so chair may decide to move around a little bit at his discretion.
So, Policy Proposal 2008-2: IPv4 Transfer Policy Proposal. First proposed in February of this year, it's been discussed in three public policy meetings. In Denver at ARIN 21, and also at the sector meetings in Kingston and Nassau.
It's been revised. The current version is as of September of this year. There are two policy proposals similar in that they apply the transfers that are under discussion in the APNIC and RIPE NCC regions.
Basically, this allows an organization to transfer IPv4 addresses to an organization with a need for addresses and creates a listing service. The shepherds are Scott and Stacey. Staff assessment -- counsel from a standpoint of risk sees -- it believes passage is better for ARIN than continuing the current policy.
Staff has some comments and concerns. In other words, thinks that something has got to be done with the existing transfer policy. And a proposed text change in resource holder ownership should be improved -- needs to be fixed. And they turned the text registered for use within the ARIN service area needs some clarification.
It would take us more than 180 days to put this into practice once it becomes a policy because of new processes. We're going to have to do some significant staff training. We're going to have to do some -- probably get some more hardware and software. We're going to have to do a new template.
The listing service is something we'd have to figure out how to do.
So. Six in favor, six against is kind of the drift on the discussion. So, a lot of ambiguity there, I guess. A lot of -- a few people saying a lot of things. And I won't go through the comments here. And we invite you if you haven't seen these comments to go read the archives. It's a fun archive to read.
And so, with that, I will turn it over to Scott who is going to present the proposal.
MR. LEIBRAND: All right. So, you guys wanted a simpler transfer policy proposal. You also got a simpler slide deck.
Some history on this. This was originally proposed by the advisory council in response to a workshop where the Board asked us to look at various options. Disclaimer: The AC is divided on this, just like everybody else. So, we're not pushing this on you. We're trying to figure out if there's community consensus for something. And if so, for what.
This has been discussed at previous meetings. I'm sure that anyone who's been involved for more than a couple months is well aware of most of that discussion, so I won't go over it in any detail. But I will mention that this has also been discussed at the Caribbean sector meetings. So, we get some more input from that group that is only slightly overlapping with what comes from here.
Summarizing some of the votes that have gone on with -- at previous meetings. In Denver, the question of whether to continue working on a relaxed transfer policy was put with a consensus in favor of that. Consensus in favor of retaining a need-based qualification, and not quite as much of a consensus, but still good plurality in favor of doing something before IANA runs out of space.
Kingston Caribbean sector meeting, same questions were asked. You got about half as many votes on both sides. But the proportions were about the same.
The survey. The AC put together a list of questions to ask of the community, posted a link to that on PPML. Got 202 responses. I forgot to bring my discussion guide up here, but page 6 and 7 have all of the results of that and they're also available online. So, I didn't try to put them in the slide deck.
Those questions were also asked of the Caribbean sector meeting at Nassau, and the results of that are available in the transcript of that meeting. I didn't try to summarize those.
So, what's new? Why are we back with this proposal and what have we changed? Mostly, it's simplified. We took out a bunch of text that wasn't strictly necessary. Removed some restrictions that there wasn't a lot of consensus for and that didn't seem completely necessary. Tried to preserve the restrictions that there was consensus for, and keep the most essential stuff.
Rationale. I -- this is -- none of this is new. But basically the idea here is to allow people who will continue to need IPv4 addresses after the free pool is exhausted to continue getting them somehow. And to improve the efficiency overall of allowing people who can move to v6 to do so. And people who can't move quite as fast to do so a little bit later.
Again, incentive to put space to the most efficient use.
What's allowed? You still do need to do need-based qualification. You just can't whatever addresses you want to buy. There's -- this is not a wide-open free market. You still have to go to ARIN, get qualification, they'll give you the go- ahead to get space and then you can go out and transfer it.
There's some restrictions in place to try and prevent speculation. So, you can't get space and immediately turn around and try to flip it.
There are restrictions around arbitrary deaggregation. The idea is that we don't want to take a /8 and divvy it up into a bunch /22s and flip the table. But at the same time, there's going to be more demand for /22s than there are for /14s. So, there will be -- need to be some level of deaggregation. So, the current policy proposal gives ARIN staff discretion about what exactly to allow as far as deaggregation and provide some suggestions on how -- what that initially might be.
Other restrictions? This is an ARIN policy. We don't really want to make it an effective global policy, so we're trying to restrict it to the ARIN service area.
The RSA BETA is a little bit different than it was last time. And you only need to have an RSA on the organization who is transferring the space to somebody else if you intend to keep some of it. So, if you're a legacy holder, you've got some space, and you want to transfer it all there's no need to worry about an RSA at that point because you're not going to have the space for more than a few more days until you transfer it. So, there'll probably be some terms and conditions around the actual transfer. That's ARIN operational practice.
But the only need for an RSA or an LRSA is for someone who plans to keep space. So, that's the recipient and the transferor -- in the lingo -- if they intend to keep a portion of it.
There is a restriction that you can't keep coming back every two weeks for more space. You need to get enough for at least 6 months, up to 12 months or maybe a little more for CIDR rounding if you want. The idea there is to try and avoid more fragmentation, deaggregation.
Minimum allocation sizes /22 and /20 currently apply. However, there are Class Cs out there, they will be allowed to be transferred but they can't be deaggregated. If there's two contiguous Class Cs that make up a /23 it can be transferred as a /23, not as 2 /24s.
So, that's the quick overview of what the policy is and does. And now we get to the fun part of actually talking about it. So I'm going to let John decide how we're going to do that.
MR. CURRAN: Sure. You can stay right there. Microphones are open for comments on Policy Proposal 2008-2. Okay? Far right microphone.
MR. BICKNELL: Leo Bicknell here as an ARIN AC member. We have heard a lot of comments on this from a very small number of individuals repeating the same thing over and over again. And I would very much as an AC member like to hear input from people who have not previously posted on PPML or spoke at the meeting.
And if all you have to say is, I'm confused, that is actually very useful. We need to know why you're not speaking if you're not speaking.
Or, what your opinion is. So, please. Come up to the mike.
MR. CURRAN: Okay. Far left microphone.
MR. FREEDMAN: Avi Freedman with Akaami. I'm in favor of something like this proposal in some form. I have two questions about this proposal as stated.
One is, what would ARIN be able to do about someone deaggregating the space for themselves or actually, you know, trying to SWIP it away. What would the -- other than take back -- take back or public shaming or hanging or something like that.
Second question is, how is there any process in place to make sure that a corporation -- and this may be a current question -- a corporation can't set up many sub-corporations or related or seemingly unrelated corporations to violate the -- you know, 6-month -- you know, do many -- you know, one per -- special purpose corporation per address space.
So, those are my two questions.
MR. CURRAN: Do you want to take the first and I'll take the second? Okay.
MR. LEIBRAND: The first question was about deaggregation. We're not trying to say you can't aggregate TE or you can't announce TEs more specifics. All we're saying is, we don't want to fill the table with top-level allocated from ARIN prefixes that cannot be aggregated any better.
So, to put a finer point on it, if you get a /22 under this transfer policy and you want to announce that with more specifics -- we can do that today, we're not changing anything there. All we're saying is that we're not going to encourage you to go get a /24 and then come back 3 weeks later and get another disc until you get a /24 that you couldn't aggregate if you wanted to.
MR. FREEDMAN: I'm confused.
MR. LEIBRAND: Okay.
MR. CURRAN: Well, and also that -- while there would be limited deaggregation -- and that's allowed by the policy, if you showed up and you said, I want to -- the deaggregation can't be infinite. So you can't show up with a /24 and end up with a handful of -- end up with 255 transfers of /32s to 250 organizations.
MR. LEIBRAND: Oh, I thought it was getting at I can't get a 16 and then basically SWIP out -- cell SWIP out the, you know, the 24s in there.
SPEAKER: This has nothing to do with SWIP.
SPEAKER: Nothing to do -- literally, we're changing the registration entry for a piece of the block.
MR. FREEDMAN: Okay, got it.
MR. CURRAN: Now, on the second question, ARIN deals routinely with organizations that, for one reason or another, think they can create shells or permutations and it's already common practice to address fraud and to pierce those shells as they show up in requests. So, Leslie or Steve could speak to it if you want more detail. But there's a bit of experience in handling that already.
MR. LEIBRAND: There's actually a clause in the policy proposal -- I believe it's still there -- that says basically if you have multiple organizations that are under the same ownership, you have to tell ARIN about it and ARIN will evaluate that according to their normal processes and do the right thing.
MR. CURRAN: Okay. Far right mike?
MR. SINATRA: Michael Sinatra, UC Berkley. I actually haven't commented on this in PPML, and I've some follow up to Leo's question as to why not. There are a few reasons. I agree with the comments that this is one of those things that's sort of going to happen. There's going to be buying and selling of IPv4 addresses after the free pool is exhausted. There's not going to be much we can do about that. It is good for ARIN to get involved in the process and regulate it in some way. I don't know how well it's going to work. I don't know which of the policies that are being considered are going to be better. I don't know how heavy or lightweight to make them.
I am concerned about the routing table. I don't know how we're going to be able to control it.
I don't think I will be -- my organization is interested in buying or selling anyone's IP addresses, so I'm not that interested in it from a personal perspective. But certainly from an operational perspective, I think it becomes very interesting. I just don't know -- and I am a little bit confused. I just don't know what is going to be the best policy and whether any of these policies are actually going to work.
MR. CURRAN: Okay. Far left microphone.
MR. LOCH: Yeah, Kevin Loch with Carpathian Hosting.
You mentioned in there there would be some rules against sub -- what we might call subdividing like you would subdivide property into smaller blocks. But you didn't specify what the minimum size would be. Did you have a minimum size in mind?
MR. LEIBRAND: The minimum size is defined elsewhere in policy currently. That's a 22 and a 20. The only exception to that is if there's a block that's already smaller because it's legacy -- it can be transferred --
MR. LOCH: Sure --
MR. LEIBRAND: -- as a pool resource.
MR. LOCH: Grandfathered in.
MR. LEIBRAND: Right.
MR. LOCH: My recommendation -- I've posed it before -- would be definitely don't allow anyone to subdivide below /20. Which, if everything was subdivided to /20 you'd -- you know, from the start -- there'd be 1 million routes as probably the maximum order of magnitude we ever want to think about dealing with.
MR. LEIBRAND: The recommendation -- which is not part of policy but it's a recommendation to staff as to how they might approach it -- is to start out by allowing 4 bits of deaggregation. So, if you have a /8 you can make it a /12. If you have a /16 you can make it a /20. But we know that this is going to be a moving target and we know that staff has got lots of smart people and good advisors and they'll come up with something that works and writing that into policy with a yearly time to change it is probably not a good idea.
MR. LOCH: All right, thanks.
MR. CURRAN: Okay, thank you. Center rear mike.
MR. BUSH: Randy Bush, IJ. I'm concerned about the inability to buy number of pieces and aggregate them. I subscribe to Lucy's model that transfer -- the transfer market's going to flush the stuff out in the first couple of years. And that means 2, 3 years down the pike if I need and actually really need a /24 and all I can get is 2 /25, I think you precluded that. Am I correct?
MR. LEIBRAND: Are you referring to 2 adjacent 25s that you happen to be able to get --
MR. BUSH: No. I need so much space. I don't care if they're adjacent or not. I need 256 bits.
MR. LEIBRAND: Right now, the assumption in the policy --
MR. BUSH: Or, pardon me. 4 bits -- 8 bits. 256 hosts.
MR. LEIBRAND: Right now, the assumption in the policy is that there will be larger aggregates available at a price. That price will probably be a higher per IP than smaller --
MR. BUSH: I -- I'm saying, I don't -- I'm not sure that's a safe assumption. And given that, I'm just wondering about that and how you --
MR. LEIBRAND: I agree with you that at some point, that assumption will cease to hold --
MR. BUSH: And Lucy's prediction, that I agree with, said that's going to be shorter than we think.
MR. LEIBRAND: Okay.
MR. CURRAN: Let me ask Randy -- and you know I'm going to do it -- given that this policy doesn't take that need into consideration, would you still be for it or against it?
MR. BUSH: Oh, I think I'm generally for it. I'm just, you know --
MR. CURRAN: Okay.
MR. BUSH: Considering the last policy session, picking nits seems to be very serious occupation here, so.
MR. CURRAN: Randy, my only comment would be that if that turns out to be the case --
MR. BUSH: You'll fix it.
MR. CURRAN: -- a proposal to change this last bullet point would probably --
MR. BUSH: You'll fix it.
MR. CURRAN: Yeah, yep. Okay. Actually, on and back again center rear mike.
MR. DURAND: Alain Durand, Comcast. First I wanted to course around this point is, let's say that I want a /12 and only thing I can get is a bunch of /60. And with this proposal, I cannot transfer anything, right?
SPEAKER: You could transfer 1 /16, or --
MR. DURAND: Yeah. So, it's not going to fit my needs, right?
SPEAKER: Right and if -- in that case, I think your work on getting v6 would be a really good thing.
MR. DURAND: Sure. But if I still need the /16 --
MR. BUSH: We just had this discussion, that was my point. (off mike) he'll fix it.
MR. DURAND: My point is -- going a comment I made on the mailing list, this proposal is not going to solve a problem.
Now, the reason that I came to microphone is, Dan Alexander asked a question on the PPML mailing list a few weeks ago and I have not seen any real answer to it. And I would like to ask again the question in this room.
Assuming that something like 2008-5 is going to be presented tomorrow, gets adopted, like we reserve a part of the last /8 for people doing IPv6 and you have to justify how it helps you to do IPv6.
And the IETF defined some kind of transition mechanism that works so that you can deploy your v6 networks, only assign 6 addresses to your nodes, and have a mechanism to enable those nodes to access the v4 INTERNET. So, if you have those two things, reserving address space for that and the mechanism, do you still think you need a transfer proposal like this?
I would like to ask this question around.
MR. CURRAN: Okay. So -- and I want to be clear, but I also don't want to divide the discussion into a sub-discussion.
If I understand what you're saying, you're saying given that there could be a reservation of a set of addresses and a mechanism through the IETF to allow some sort of transparent backward access, do we still need this policy proposal? So you're -- in light of what you think is happening, does this room still feel this is necessary is the question?
MR. DURAND: Yes. That's my question.
MR. CURRAN: Okay. Anyone who wants to speak on the topic of, will this still be necessary even in light of a more transparent backward access to v4, please get to the microphones. It's certainly an aspect of the need for this policy proposal.
MR. LEIBRAND: If no one else wants to speak to that, I will.
MR. CURRAN: Okay.
MR. LEIBRAND: My own personal opinion is that NAT-PT or equivalent will be very good for access networks. It won't necessarily help the content shops. I think content is probably going to have to be dual stack for a while, and so in my own opinion for that reason alone continued availability of v4 addresses for certain segments of the community will be essential.
MR. CURRAN: Okay. Anyone else wants to speak on that? Microphones remain open -- microphones remain -- well, go ahead. Owen?
MR. DELONG: Owen DeLong here, an AC. I don't think this is necessary even without 2008-5. I don't think that we'll actually see the market provide more than about a three to six months supply, and even in a best-case scenario maybe a year's supply of addresses. I think it'll be a lot less than that, actually. And I think that there are a whole lot of real problems with the way this could affect how we view addressing going forward in v6 from a financial economical model perspective. That I think that the cure as proposed is substantially worse than the disease. And certainly 2008-5, I think, provides us a better way forward than transfers.
MR. CURRAN: Okay. Jo, do you want to talk on interaction of 2008-5?
MR. RHETT: I just wanted to address the issue as far as working in content provider networks. Almost no content provider network that I have talked to has any plans for v6 at this point in time. So, yeah. The need for addresses for content providers is probably going to be very real.
I, unfortunately, work at one of those shops that has no plan going forward. However, the good news is, my boss has pointed out that his check will be writing the million dollar checks for new line cards when he's proved wrong. So.
MR. CURRAN: Given the need that you see apparent in those types of shops, you'd be for this policy proposal?
SPEAKER: No, no, no. I am simply stating that I don't think that the availability of IPv8 translation is going to solve the IP address shortage. That's --
MR. CURRAN: IPv6 translation --
SPEAKER: Yes, sorry.
MR. CURRAN: -- will not.
SPEAKER: Just want to keep the --
MR. CURRAN: Sure --
SPEAKER: I'm going to keep my comment neither in support yet in support or against. I just want to say, there will be an IPv4 crunch.
MR. CURRAN: Okay, thank you. Center front microphone. Go ahead.
MR. SCHNIZLEIN: John Schnizlein, Internet Society. I appreciate the efforts of staff to -- and the advisory council to respond to the comments along the way. Specifically regarding the change from the provider of address space not needing to have a contract signed. That looks like progress.
The question it opens is, how do you then verify that they are the legitimate holders of that address space, so that I can't start transferring space that I happen to find because I have better snoopers than you.
MR. CURRAN: So the question is -- and this might be one for counsel -- the question is, given this policy proposal, how do we know that we won't be transferring address space that someone may not have a true pedigree for and tries to sell through this process.
MR. RYAN: So, let me illustrate the answer to that by looking at what happens if you don't adopt a policy like this or like 6 or don't do that.
You literally have people out there who are doing things that have no consistency with our policy. In other words, they don't comport with any of our policies. You don't have ARIN's registration service staff pouring over the documentations to evaluate whether they have title to the beneficial use of those numbers that they're seeking to transfer. And you don't have a very expensive lawyer looking at it.
MR. CURRAN: So, does that address your question?
MR. SCHNIZLEIN: No, that really does not address the question. The -- I certainly appreciate that issue. That helps motivate the entire transfer process.
An earlier version of this policy proposal required that the party providing the address be already in the system. So, the metaphor was a little bit like car titles. Where the state provides the -- for the transfer of title registrations, but it won't do that if you don't hold title. And with this change -- which was, I must note, in response to comments on the list -- that the one provision that provided that the provider of the address space held title is now gone. And I'm concerned that you've lost that essential piece.
MR. CURRAN: Well, do you want to respond again, counsel?
MR. RYAN: Yeah, let me see if I can respond. I think in effect, the policy contemplates that we would not complete a transfer if we weren't satisfied about the good title right to beneficial use of the transferor. The transferor is the person giving it, transferee is the recipient.
SPEAKER: Is that in there? Is it still in there?
MR. LEIBRAND: Comment to what's in the policy proposal, which is, it's not. But it's considered operational policy that ARIN is going to do the right thing, like they always do.
MR. RYAN: Yeah. I think it's more than implicit, first of all, if you read 833. The last sub-bullet of that. You know, if -- the language says there must be no dispute as to the status of the IPv4 block or regarding the allocation or assignment of such block to the transferor.
So -- even if those -- to tell you the truth, even if that language wasn't there, I can't imagine that we would do that, because otherwise we might be rewarding a hijacker. And I don't think we're going to do that is the answer.
As long as I'm here, I just want to say something. I think you people need to think real carefully about passing a transfer policy of whatever flavor you want unless you want all of the market and conduct that will occur to be outside of the preview of the RIR community. We are going to reach a position where the system reaches some resources and a lot of resources are outside of the system. And, you know, I think you better think real carefully about it, because it's going to cost a ton of money in legal expenses and litigation to have the current transfer policy be the current policy of the community with the challenges we have coming up. I think -- I'm not suggesting that this policy is correct or that 6 is correct. But I am suggesting to you, and you ought to listen to me -- the Ryan children are going to be the major beneficiary if you don't change policies and send (off mike).
MR. CURRAN: Okay. Did -- did I -- Bill, did you want to comment directly on that?
MR. WOODCOCK: Yeah, just two things. First of all --
SPEAKER: And you are?
MR. WOODCOCK: Bill Woodcock, ARIN Board, and I guess I'm still not speaking for the Board. But -- the constituency of ARIN and the RIR is generally is people who use addresses. One of our concerns is making sure that people can still use them, because we want people to be able to afford them in the future, people who need them.
In order to make that happen, you want the smallest number of buyers and the largest number of sellers. Right? So in general, what we want to do is we want to restrict the buyers to only people who have a legitimate need.
We already have a process for figuring out legitimate need. We don't really want to restrict sellers too much. Obviously, we want them to be legitimate. We don't want to create a tidal problem, but in general I don't see a need to overload that side of the policy.
Also, in general, I don't think any problems that might exist with this particular policy are a lack of kitchen sinks. So, I think --
MR. CURRAN: Okay. All right. Microphones remain open, I want to go to the rear mike.
MR. GASHINSKY: Igor with Yahoo. I just want to address a couple of issues that I heard before.
So, first of all question of content providers using IPv6. Just because we aren't talking about what our deployment plans are doesn't mean we don't have deployment plans. It just means that we aren't talking about them. Just want to point that out very carefully.
SPEAKER: Will you still need v4?
MR. GASHINSKY: Absolutely. And we foresee the need for v4 for decades to come. Because IPv6 connectivity is so fragmented, and so underperforming. It's going to be decades before we start to remove v4 addresses from our servers.
And the other part is, does -- if we do -- if reserve the last /8 for transition mechanisms, do we still need this policy? Yes. Because transition mechanisms -- NAT, PT, or whatnot -- do not address all the needs.
MR. CURRAN: Okay. So, despite transition, despite stealth v6 efforts, you would be for this policy? You think it's still needed?
MR. GASHINSKY: I am not decided if I am for this particular policy. But we absolutely need a transfer policy.
MR. CURRAN: Okay, thank you. Center front, Tom?
MR. VEST: Thanks. Tom Vest. Actually, maybe first a procedural point. I object to the explicit bracketing of the question. Any of the questions in terms of this or the status quo. If today is the very last public policy that we'll ever have again, then that's a fine way to frame this issue. If today is not the last day, if we're going to meet again tomorrow, if you anticipate ever meeting again, then I suggest that we -- that you do not limit yourself to an imagination to the two -- the binary possibility of running stupidly headlong into the wall or rushing into what is on the table right now. So, that's a procedural request or suggestion.
Now, a more substantive thing. If proposals are approved, then very shortly accountants and attorneys are going to have to figure out the treatment of these new assets in all kinds of contexts. Has ARIN prepared any guidance for them? Should this be treated as an asset, as a service? Do you intend for ARIN policy to take precedence or property law to take precedence in cases of bankruptcies, inheritances, import/export rules, merger and acquisition requirements, FTI requirements. Has any consideration been given to these? And is it generally the case that property law is going to prevail? What happens when there's conflict between ARIN resource policy requirements and property laws, which of course vary quite a lot across national jurisdictions.
MR. CURRAN: As fun as it might be to answer that question, I'm going to ask counsel to go for it.
MR. RYAN: So, let me ask you all -- let me pose something to all of you who are public companies. If you start to think of these things as assets you could monetize, then under Sarbanes-Oxley you better get them on your books. And if you don't have them on your books the day that you sell them, then there's going to be questions asked afterwards as to when you monetize the asset and what it counts for.
So, you can't play this card only on side of asking about the asset if you're going to think of it as a monetizeable asset. Let me pose the answer on the property issue.
IP numbers are not property. The legal regime that covers IP property does not create a right to own those numbers. What we are talking about here is a transfer of the beneficial right to use them. They do not belong to the person who's transferring them, they don't belong to the person who's receiving them. That's the legal regime that we live under, and there's nothing inconsistent in that regime in the draft policy in my review, nor with policy 6. Nor with the current policy at ARIN.
I don't think we've trespassed the property issue.
MR. VEST: Can I just follow up? Does that -- is that a substantive difference? Would -- in that case -- would the prevailing legal regime for whatever the non-property status of number resources -- would that present any conflicts potentially? Would ARIN resource usage policies in -- conflict with any moments in cases of bankruptcies, inheritances, cross-border -- you know, MNA or sales transactions?
MR. RYAN: If we go to a bankruptcy, the argument that ARIN would pose to a judge is it's not a Ford LTD, Your Honor. It's not something that you can -- you can't sell it like a Lincoln Town Car. It happens to be -- the analogy we've always used with Judges, and they get it, is we take out a credit card and we say, Your Honor, there's numbers on the credit card. You're entitled to use those numbers from the bank but you're buying the service of the credit card. Not the numbers themselves.
Now, to date that's been successful. If we lose a case where a Court decides that numbers are more like domain names as the law developed on domain names, then there'll be a very different meeting here if that happens. And I think one of the things that everyone needs to consider in this debate is protecting the stewardship of the legal theory that underscores our current system.
The United States Congress has made phone numbers legally something different. In other words, there's a legal regime. Another alternative if we screw it up is that they will fix it for us, okay? The Congress of the United States will step in and address this issue for this portion of our service region, or the Canadian Parliament or the Parliament's of the Caribbean Islands that are part of our region. So we could end up with a regime that is created by statute or regulation outside of the community's current control.
MR. CURRAN: Okay. Tom, to answer your procedural question, it is -- this is the discussion of the policy proposal on the table. And the topic isn't, is it this one or is it nothing forever. It truly is, is -- are you in favor of this one? If you're not in favor of this one, that could be that you wish to talk about others in the future or propose an alternative, or -- but when we asked to make the guidance clear from the floor, we're asking in particular, are you for advancing this particular one as opposed to doing nothing or having another one advance at some later date.
So, I ask you, are you in favor of this particular Policy Proposal 2008-2?
MR. VEST: Well, I am not particular favor of this (off mike).
MR. CURRAN: Okay, thank you. Rear microphone, center.
MS. AZINGER: Marla Azinger, Frontier Communications. First and foremost, I respect everybody's opinion on this. I took a year and a half looking at this and it was really hard for me to decide what side of the coin I'm on. And I wrote my own transfer policy to grasp that concept, which is why I have respect for everybody has a good point.
But that said, I'm ready for tomatoes to be thrown at me because I am going to step forward and actually say I am against this policy. I don't think it's the right one. I do think there are other ways we could do this. And yes, I am working on it. And some other people are, too.
So, I'm not just stepping forward and saying no, not this. And then walking away.
So, why. First, if you needed policy that is this so detailed it kind of puts up a red flag for me. There's something wrong if you've got so much in a policy to begin with.
The other thing is, this is what I had to go to heart with for me. I'm an engineer, I've worked for the same company for six or seven years.
I'm losing track of time, sorry, forgive me. But I have seen three different CEOs go through the company. And CEOs and marketing and sales, they kind of switch out a lot. Their main goal is to get a profit and leave.
And the problem that causes in engineering is if you suddenly say we can transfer and sell our address space, the v4 space, they're going to start saying, hey. Let's start putting that in your network. Where really to an engineer, it does not belong there. It's a bad place to put it, but they're going to say, we don't care. We want to sell it, we can make a profit, let's sell these addresses.
So, that would cause a big internal battle within several networks. You may not be familiar with it, but take it from me. With other subjects, I've been there. And it's not a fun battle to go through. My network itself is actually upgrading right now to be v6 compatible and ready. We're doing dual stack so, yes. We will still need v4 space. And yes, I'm going to be doing the system of where, okay. Now we can use v6 here with these customers. Now we can use v6 here on our internal network. So now I can use the v4 for these other customers that I still need the v4 for.
So, my numbers -- yeah. I'm going to be adding more use of v6. At the same time, I'm recycling the v4 space I do have.
At the same time that my company would have the battle of selling off v4 space, they're not going to want to be selling it -- or, buying it. Excuse me. We're not going to be wanting to buy IP address space. Instead, we are going to be looking forward to go to the v6. But the problem with that is, with the argument that's going to go on in the engineering and marketing and sales, it's going to take focus off of moving forward to v6. And I don't like that.
The other thing is, I don't foresee this actually getting us much further with having more v4 space to play with. It's really not going to make that big of a difference. And to go through all of this and put people in the position of having engineering issues, it's not the right move, in my opinion.
So, I will be working on some other alternatives. And I think that was my last point.
Yeah, okay. Thanks.
MR. CURRAN: Okay. Microphones remain open. Center rear mike.
MR. ALEXANDER: Dan Alexander, Comcast, ARIN Advisory Council. I don't necessarily object to the details of this transfer policy. And whether or not they should happen. The main point or issue I have with this proposal is the immediate timetable for implementation.
And to clarify the PPML post that was mentioned earlier that I had put out, it wasn't to advocate any particular other policy or protocol or anything. It was going to try and point out that we still have potentially two years of supply of v4 addresses that the RIRs can allocate to people under the existing regime.
For us to immediately open this door and allow all the potential negative implications of this new model right now, when we can still readily serve the community as we have done, I think is jumping the gun. Because there is any -- a large number of things that can happen in the next two years that could potentially render this useless. And -- or not necessary. I shouldn't say useless. And those two options, backwards compatibility and rationing of the last 8, were two of those that I offered up, so.
MR. CURRAN: So you wouldn't be against it given the huge potential for downside and the fact that we may be opening it up prematurely.
MR. ALEXANDER: And I'm not saying that we do nothing and wait for the two years to see what happens. There are a lot of policies that have to be put in place between now and then. My only point is, I don't want to open this Pandora's Box next week.
MR. CURRAN: Okay.
MR. LEIBRAND: Question, follow-up question, Dan. If this policy were to get ratified by the board of trustees and go into effect in 180 days or whatever staff needs, do you anticipate that it would actually get used? That people would actually choose to pay for space instead of getting it free from ARIN? Even though they have to go through the same qualification?
What's the -- to put a fine point on it, what exactly do you think would be bad about having this policy available before exhaustion?
MR. ALEXANDER: One of the concerns there and it could be an unfortunate -- you know, point of ignorance or a lack of knowledge -- but, it's highly likely that if this was allowed, someone would end up buying space that they could have readily got from ARIN for free. And an organization would profit from that. Which isn't the intent of what we're trying to do.
MR. CURRAN: Okay. Thank you. Microphones remain open. Center rear.
MR. DURAND: Alain Durand, Comcast. Wanted to clarify a point about 2008-5. This is not only about NET-PT. The proposal is actually on purpose vague on what you can use it for. You have to justify to the ARIN staff how this is going to help your v6 deployment.
So if you are a content provider and need some v4 space on some of your server, to enable you to serve your v6, then you could use 2008-5. But more on this tomorrow.
MR. CURRAN: Yeah, I was going to say. That's a separate topic for this one. Okay, far left mike.
MR. RICH: Yurie Rich, Command Information. I don't think I necessarily support the proposal. And I get it maybe from a lack of understanding.
And maybe this is something that counsel can answer. ARIN sort of legitimizes this process of one organization selling their IP address space to another organization. Doesn't that sort of go against the whole thought process that this isn't property?
If that organization can get rid of that space, that they didn't really need it in the first place, it seems like we're legitimizing a process that we're adamantly opposed today but it's convenient for something in the future. It seems at odds with me, so.
MR. CURRAN: And counsel can address. I can say at a high level, at present ARIN will fight a transfer of address space from one organization to another that doesn't comply with the current transfer policy. So, if we adopt a transfer policy which allows that, it is in some ways a reversal of position.
That doesn't make the addresses property, but it simply says, our transfer policy now allows them to have the right to use them to be transferred when it never did in the past.
Does that answer it? Or do you want counsel. Because I can --
SPEAKER: But you still have to pay for it, though, right?
MR. CURRAN: Oh -- well, that would be between two parties that we're not one of. I mean, Party A talks to Party B. We don't know if there's something being paid there.
SPEAKER: You need to use the microphone.
MR. CURRAN: Ah. So the question is, on a going forward basis, would the receiving party still be paying registration services fees. Is that your question? No. What is your question?
SPEAKER: Please us the microphone.
SPEAKER: Can't hear you.
SPEAKER: People out there in audio land --
MR. CURRAN: Remote participants are out there.
MR. RICH: Sorry. Still, Company A has sold -- transferred this block to Company B. And for us to say, well we don't know if they got paid or not is naive. We know that they paid for the asset. They paid for the IP block. And my mind, we sort of legitimized that that is an asset that can be bought or sold. Whether they have such issues or not, it doesn't really matter.
To me, it seems like we have been legitimized that this is property, that it can be bought and sold.
MR. CURRAN: I don't know what -- counsel said earlier, the act of allowing that transfer, that right to use, doesn't per say create property.
But -- Steve, do you want to talk about it more specifically?
MR. RYAN: I think I'd be restating what I've previously said. Now, let me just ask the corollary question of the room. When somebody shows up who -- Company A has sold it to Company B outside of our system under our current rule, when Company B wants to change the registration statement, what are we supposed to do? What do you expect of ARIN under those circumstances? Our current rule does not permit us to do that.
So, think about the implications of a world where lots of this is occurring and you have no way of addressing that. The community needs to address the policy of what happens then.
MR. CURRAN: Thank you, Steve. Do you want to get in line, Owen?
MR. DELONG: Sure.
MR. CURRAN: Do you want to -- okay. All right, we're going back over that way bit by bit. Center rear.
MR. POUNSETT: Matt Pounsett, CIRA and the Advisory Council.
I'm one of those people who started out actually being in favor of this when we first started talking about it. Leaning towards being in favor of it, anyway. And over time I've kind of come to the conclusion that I don't think this -- any sort of liberalized transfer policy is a good idea.
The big reason being -- well, it comes down to it's sort of a cost benefit analysis. That this is a really complicated proposal, but it needs -- we've discovered that it needs to be, right? There are all kinds of things that we -- in talking about this, we've come to realize kind of need to be controlled or bounded somehow. And in order to do those things, there -- we have to have this, you know, fairly long piece of text.
And I think that it's taking -- it's going to take so much effort, number one, to finish flushing it out and get it through the system and make it an actual policy. And then on top of that, there's all the work that has to go into actually setting up markets that -- whether ARIN's directly involved in the, you know, arranging the transfers or not in running some sort of listing service -- that work still has to be done by somebody.
And it's a huge amount of effort for the industry in general. Both here in the policy process and the implementation later that could be much better spent on actually working towards v6. And would -- so, I tend to think now that stuff like 2008-5 is a much better way to spend our time than to continue looking at something like this.
MR. CURRAN: Okay. Far right microphone.
MR. BICKNELL: Leo Bicknell, ARIN Advisory Council, ISC.
I want to go back to Scott's question directed at Dan as to the potential danger if this goes into effect immediately. And what I want to say there is, not a lot of the commenter have talked about this aspect, but there's two aspects to what we're doing here.
One is the creation of a policy. Whether we pass this or not or other proposals, we change the policy process.
The other part of what ARIN is doing here is helping people plan how the transition works. John gave a great talk yesterday or before, whenever it was, on a plan to move forward. One of the things that all companies hopefully are doing right now, or at least most of them, is developing a plan for how they're going to move forward.
If this were to exist today, even if no one uses it for five years, it will affect the plans that companies make. Because they now know that it is an available option that they can count on and not some theoretical thing that may be passed in the future. So by having it available today, it would absolutely change the planning process that is going on at these companies.
I'm not actually sure if that's a net positive or a net negative, but I think there is a very significant impact into the discussions that would be had and how they choose to move forward.
MR. CURRAN: Okay, very good. You were next in the queue, Owen. Go ahead.
MR. DELONG: Owen DeLong, ARIN AC. I've got a few different points I want to address. First of all, I'm not sure about right to use being kind of the right thing to call what ARIN does. As I understand it, we don't really control how people configure routers. And the right to use a set of numbers comes primarily from the fact that somebody who has access to configure a router somewhere that other people have routers they're willing to believe, puts the prefix into BGP and, you know, somehow everybody miraculously believes that.
To the best of my knowledge, ARIN as an organization has no control over that whatsoever, directly. It's merely the fact that ISPs happen to listen to us that makes that happen.
What ARIN provides as I understand it is merely a registration service. In fact, I think that's what we call Leslie's group, Registration Services. Where we basically assure you that the IANA, the ICANN, and the other RIRs that cooperate with us will not issue that same number that we've issued you to somebody else. And that's about it. You know, there's IN-ADDR. and there's WHOIS that goes along with that. But in terms of what anybody else uses the same number for without your control or our control or whatever, we -- it's not like we can send the INTERNET police after them. There is not such organization.
In terms of what happens if we do pass this transfer policy. Well, we've now legitimized some unknown amount of deaggregation of the address space in favor of distributing it to lots of potentially disparate parties with no routing relationship with an unknown impact on the routing table. And ISPs can't point to ARIN and say, you know, your purchase of that address space may be well and good but it's not registered in the database so we don't have to recognize it.
On the other hand, if we don't pass a transfer policy and there is a black market and the black market gets out of hand to a point where the routing table cannot support the transferred address blocks in the routing table and ISPs have to choose what to filter, it's a whole lot easier for them to say, well. Look. You don't seem to actually have title or, you know, registration of this address space to you in the ARIN database or in any other RIR database. And so we're going to stop announcing that for you now. And, you know, we can give you a prefix or you can move to v6 or, you know, whatever solution they're able to provide for you.
But continuing to advertise those black market routes, if they become too much for the routing table to sustain becomes much easier to terminate if they aren't legitimized. And I think that might be a good thing.
MR. CURRAN: Just to be clear, with respect to being in favor or opposed to this policy --
MR. DELONG: I am diametrically opposed to this policy.
MR. CURRAN: Okay, thank you. Center front.
MR. RHETT: Jo Rhett, Silicon Valley Coalition. For a long time, I looked at all these policies and kind of had to say me, myself in my job, I don't have to care. Because if we do run out of IPs, I simply say we can take you as a customer if you have IPs.
Then I realized something the more I heard it, and it was specifically highlighted to me when somebody at NANOG told me that their boss came to them and said, so when we run out of IPs and they become really valuable, there'll be a market we could sell to of people who can't get their IPs recognized by ARIN, right?
What the lawyer just said -- sorry, I've forgotten his name --
MR. RHETT: -- was something that I had actually paraphrased to a number of people a couple of weeks ago. I don't think we have a choice. The problem I'm going to be facing -- we do have a potentiality of routing table growth with a deaggregation policy.
We have a real problem in that no matter what, none of the big iron is prepared to do the kind of let me check with ARIN to see if I should accept this prefix. And we're not going to have it in 18 months, I seriously doubt we're going to have it in 36 months.
We're going to be facing a massive problem and people who chose to monetize by selling connectivity to the people who have the legal black market transfers. And that's going to become an operational risk that everybody who works on a router is going to be facing.
So, it's hard for me to say I love this policy. To be perfectly honest, I kind of wish that we could get a team of lawyers into the room to tell us about these policies in great detail. Because I think this is where it's all going to end up one way or the other. And we're going to have to do something.
MR. CURRAN: So you may not --
MR. RHETT: I wish I had a more clear answer.
MR. CURRAN: You may not be for or against this particular one, but you believe we're going to need to do something?
MR. RHETT: We're going to have to do something.
MR. CURRAN: Okay.
MR. RHETT: I do want to say that I also agree that we should not do anything until ARIN cannot offer that space to the person. Like, it has to come to the point that I don't have a 22 to give you before we should allow a transfer.
MR. CURRAN: Okay. Bill, you want to respond?
MR. MANNING: That's -- yes. That's kind of like saying I don't need the oxygen tank to be dropped down to me 35 meters below the water when I've run out of air. If we wait until they're gone before we attempt to create a policy, we're screwed.
MR. RHETT: And that I absolutely agree with. I think we need a policy that takes effect at the time that we need the air. But I think we need that tank on our back before we get there.
MR. CURRAN: Okay. I am closing the mikes very shortly. If you want to comment on this today, as opposed to tomorrow which will be -- we'll open up with the same topic. But if you need to speak tonight, just to feel better, the microphones are open now and closing shortly.
Okay. Center rear.
MR. SCHILLER: Jason Schiller, UUnit, Verizon, NRO-NC. I'm opposed to this particular policy and in general I'm opposed to a transfer policy that's very liberal.
I think the worst thing that we can do is have a very liberal transfer policy. But that's not what I wanted to talk about.
I wanted to respond to Steve Ryan's question of, what should we do if there is a black market for address space? And address space changes hands and someone asks ARIN to update the contact information.
I think it is valuable to have correct contact information. I think it's important so that we can troubleshoot routing issues so that we can contact the people who are actually routing this base. I think it's useful to have correct reverse DNS.
So, I think ARIN should maintain appropriate records for the stability. And the security of the Internet. I think it might also be valuable to point out to people that this is an address block that has been transferred in this manner, flag it in some sort of way. Publish it on some list somewhere. So that people can decide to do with it what they please, whether that's route it, or not.
MR. CURRAN: Okay.
MR. SCHILLER: I also wanted to respond to something Owen said, which was about unknown deaggregation levels. When Scott was explaining this policy, he said that the recommendation to ARIN staff was to allow 4 bits of deaggregation, which would be a 16-fold increase in the number of prefixes in the routing table for this base that's transferred.
And I have a question for Scott about that bits. That doesn't seem to be written into the policy, it doesn't seem to be written into the justification. Is this unofficial advice that's going to be given to ARIN, is this the current best practice that ARIN would be upwarding under today? Where does this 4 bits come from? And if you think that that's the appropriate level of deaggregation, would you be willing to specifically write that into something somewhere?
MR. LEIBRAND: I believe it is written in as a recommendation. Let me find it.
MR. CURRAN: Okay, while you're looking that up -- yeah. Why don't you look that up. Thank you, Jason, and he'll get your answer as he looks it up, right?
I am closing the microphones, by the way. If you're not presently in a queue, do not enter the microphone queue.
MR. LEIBRAND: Okay. So, it says in the rationale that a suggested starting point is to allow transferors to subdivide an IPv4 block into up to 4 smaller blocks on CIDR bit boundaries provided minimum allocation ties.
MR. CURRAN: So presently only in the rationale, not in the policy text.
SPEAKER: And 2 bits, not 4.
MR. CURRAN: And 2 bits, not 4.
MR. SCHILLER: Sorry. My bit math is bad.
MR. CURRAN: Okay. All right. Far left mike.
MR. CLAUSSEN: Hi, Kent Claussen from Enhanced Telecom. I'm in favor of this policy. And in a liberal transfer policy that we're going to need to have in the future from the sheer sense that we -- we're going to have run out. We know that. That's foreseen, we've seen that for a while.
A black market is going to emerge, and I think as much as ARIN can be involved in that market and keep records accurate, it's a very good thing.
I think also we're probably going to see a shift in the view of IP assets from what counsel was speaking earlier, oh, it's just a right to use to more of a domain based where it's actual property.
And back to his analogy before of their numbers on the credit card. If I lost my credit card today and I called the credit card company and they said, oh, well, sorry, we have no more credit card numbers to give you. That would definitely change the view of how those numbers are viewed. And I think that's something to be keeping in mind here. And we definitely need to have ARIN involved in this process, whatever shape. And if we think we can do an end runaround a possible black market by having a strict transfer policy, the market will just emerge outside of ARIN.
MR. CURRAN: Yup, thank you.
MR. CLAUSSEN: Thank you.
MR. CURRAN: Final speaker? Center rear mike.
MR. POUNSETT: Matt Pounsett, Advisory Council and CIRA.
For those that don't recognize my company name, we're the dot-CA domain registry, the Canadian top-level domain.
I just wanted to make a hopefully quick comment about the whole property thing, because I'd like to stop talking about it.
In Canada we still operate under the -- what is it? -- legal regime, I think was the term you used, Steve. That domain names are not property. Domain names are transferred back and forth for money in Canada every day. In fact, some of the wealthiest domainers in the world are Canadian. And yet we still operate under the rules that what we're -- what people are paying the registry for are services, period. They do not own the domains. And that works fine. So, I don't see why it needs to be a problem in the IP addressing realm.
MR. CURRAN: Okay, thank you. This concludes today's discussion of this policy. And we're going to pick up with this first thing tomorrow after an evening of relaxation.
So, Ray, back to you.
MR. PLZAK: Thanks, John.
(Whereupon, at 5:01 p.m., the PROCEEDINGS were adjourned.)